From nobody Fri Oct 1 07:05:11 2021 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 4028C3A0DEE; Fri, 1 Oct 2021 07:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlTrVWfxF7VV; Fri, 1 Oct 2021 07:05:01 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2131.outbound.protection.outlook.com [40.107.93.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD78F3A0DE9; Fri, 1 Oct 2021 07:05:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DTC3OLbSFOOiG/LF62WdV4OXApfKC4pBJ/e9RUJy6az422MG/KmHuz2kzah+8OVnTzsfbNoMWNuuGdte9s2kgQdnNGRggnjZbjvdqawj7XDQ5QkXNZYxUowqRFrowIS5D3ka8pLr0GrbS7GCZdm+G/iafJUgpGDTiXTkmh8P12FO+O6rWibC+ENIH4jNPpoW3nuAK1e8cECKhOkBSadUR2ayC+tdbT+fIdfxhavSnbnL6NNs6KYmV/8zhArGqia6SQKwnG8Tn6ykqSpZrgimV78BpdHkEUuxrC/ShmNM8DlNxCxrI+GlkXnoGONZEOfixCxDNuJH/dEKStWb0wCjbQ== 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=0s5KpFTnkJkWZv1EW5VSn49/6rB1bT8TMJw1oYskwLg=; b=EUL1PgM3h+lU/zT896SOc//aoqJDzaggLJ12W1r1Z9oznmk1Rj8WzbQYsQBkU9+1YOLlXaWqdoYuOrkJYRW3PFoLt5uE24N14Lp6vIo08S2tBRihLEE3dLswb36Vg33JepoHCgNQPP1XXoKYB7jnsq3bwW99tJXhmpyG9p0oGdMEzU+8s32mBPpZFbMv9uyv2VBsKvCZmTSRk5WLdx2DzD+NCP6Bpe5/ync3RmEq5OjuhCBJahu444qwCh36LF1zYVX7lzgU5qaFOnWhCLIu0w2N+Rz/psg0U7apv+qd+ZASi9BctSJSPaWur7eJDx/kvf0ndcS3SwwKyeuhV3dz/Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0s5KpFTnkJkWZv1EW5VSn49/6rB1bT8TMJw1oYskwLg=; b=sjQlc+1BfFqWXJrdZ45cHpb+fPWVl4Oep5ROPzwWX6LVJL8XWumlZzVt0dpvhhxlGUMfVgOb3Pn9pmtTiWrbSL98GKef10AFRk8GeQqXCnDUhYGrXFYO9JdifxAYbDUc0h+PpIuHHTfSTm3BOTOPgpMWMM1YKBCxx3gwVFYix2Y= Received: from DM6PR13MB4204.namprd13.prod.outlook.com (2603:10b6:5:16d::19) by DM6PR13MB2604.namprd13.prod.outlook.com (2603:10b6:5:145::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.7; Fri, 1 Oct 2021 14:04:49 +0000 Received: from DM6PR13MB4204.namprd13.prod.outlook.com ([fe80::3d76:9c5e:9266:2c57]) by DM6PR13MB4204.namprd13.prod.outlook.com ([fe80::3d76:9c5e:9266:2c57%2]) with mapi id 15.20.4587.011; Fri, 1 Oct 2021 14:04:48 +0000 From: James Guichard To: SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQ== Date: Fri, 1 Oct 2021 14:04:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1dfc797a-c265-4244-7dec-08d984e46e6e x-ms-traffictypediagnostic: DM6PR13MB2604: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: TrON+zfCex+XMVZHNzxRt7mW0xQI4eqH9yKXwqITVruVfwKiMTbvtKj6oO5ZyaH185bDCTzyzgcfN9UDt8Y5YMgvwBp3rLG1aGostoPS0iQT4DqWXLC7KwHvRz8lDFHGLqN4B6S8wmhApR0tvjgaX8yQoDu6WMnpa27gFLw0ZLZ1ZWFH8o+BiiNPae2/KZV4U9Bg96yU03UUWb/3yt1CBrDQ/21+BprPOCCBgQJrBZdjt0isv8r9KGDtCwF1oBXG42qu6B/15DkHjYkuKPKPvZNVhyo0YcTi9H2EVzto1xv7axYEXo9KeMjUqVn5e9ISre4gUw/vdAvmWwI2ivxwH18PpDDIkuw4VOSG8A8hy3l/uupZivMRSDRrVN8bfuJdd0+r9cXwYVI3YRWXIRCagfV+0GGsjoSW5PPNkWf/dU9bHeDy2LlviIF5DCZMqMzin5IcnIk1AyCKEEBmwU2agF6NofIVWsch4YHt+QG0mfaDKNoz2aaw3m0o5Ith4hxGd8UyxVTqnDNjfvGN6z4ula9f/3zai+nk4p5pw0ozJvokFXDM/F+Y7Tsy54R/4ulYns+nKg+NbspFFzbBf6IvpDez9qIly+ZHYP9j7pwjaecPw4kgrFy12l+IJ6WAiU8ntx9dElaFU+jR2GRH+745PSz1/tVmMswEDujrOzwN3A89ZZMpNxeGsM+MNyo6jF9eh/w6fcjuytCIZUUyco2Kaad9Drtg1NCSUfR3DLIMnr7axsTLLQ9A8ediFN3UsL9pLwHSvkN5kvkSJchiXuvNhBqM5/hSMKjzQiA7oaSPq64= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR13MB4204.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(6916009)(38100700002)(5660300002)(508600001)(8936002)(71200400001)(76116006)(66476007)(64756008)(66446008)(316002)(38070700005)(66556008)(186003)(122000001)(8676002)(33656002)(966005)(52536014)(7696005)(166002)(55016002)(86362001)(83380400001)(2906002)(4326008)(9686003)(66946007)(450100002)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?sNa8tTgiMyTAaXT/V8MEiIWkDGzLHRnOQunqo7KQz0lxmk7KP882AbWesP6T?= =?us-ascii?Q?yw9EHTbxYB5Nswii+FaYrnckR9NE4CNwSmW+FO5/lu35MoImCpUQMfR1E0Tk?= =?us-ascii?Q?NLsc8L+bIiHGm/mMMVxYUS+xozTLYJkRF5DN36xajQ9q/d8wkGllhH6f6HAf?= =?us-ascii?Q?Y1n6qhph1y0Jqt60Z9Dti1kun2UtRvI0xN66I1SSuyXvO6MJeYQPx9qCwTj6?= =?us-ascii?Q?Ftn0jd/+TAulMorGtFQmVdEVgYc3vCl7BVHbNchQs5+o9wzlqPz+ILJA03Xp?= =?us-ascii?Q?N1CpodDpxh/lw3NQxQ3hIEYpJGFuPhncKcQnh6Y06r2jsng3dRudud8HmKZU?= =?us-ascii?Q?0IYaadjv38LgytyfDothBSXo2jKPbTn1JCeW1R1utuTQFXlk+iKia1hNP9Rn?= =?us-ascii?Q?TOEPWnyRdsnEZrdcHRTvZaN8ibTAOMPkWncjwWhb+31NPj/dV7jnPq7nYbqH?= =?us-ascii?Q?Rzii42zaHjAv7AeBBeS4Zl1yupF9aqEUyJSjkWHV+EXwxy5WS74Sp6Lebgst?= =?us-ascii?Q?U5nsRE0spZ7ARuBHQMs+iz1iYhiOLvzwv5AUlDkD+qV1gt1ajBR3Y+8apZA9?= =?us-ascii?Q?nuVRQ7c7zFPNOKA9IAdXfa+IVWiLkbZ1NxBxuptsOIUfznFD5MsZjuIpxRPD?= =?us-ascii?Q?NJ00FNY7ohTIvLalL+/9nT9Zt2AwsY5SQl67jPa8dYWE+HwK609KY/EIjk0T?= =?us-ascii?Q?qyxXM7qLMSQEGPvRty7iN0wh5BGsekgZRzKZU8WTVEywCQzlr++qe+6b0v+b?= =?us-ascii?Q?4wyTGK6ZRAWCExPmf85skffHrgSJ+Ui1Qvfi7DSApLbKoCc2Ax9KUuGdA7CV?= =?us-ascii?Q?r6kylhaoy88v8hE4NVcSLv03J2ip1wUV0Txh2h+RDhxK5z8FAgZ8Ga2VyZcJ?= =?us-ascii?Q?sx5Osi4zGCRcn8hIIq5DWZHEGHmPckTcoUibmxya20+jZWpCyXaANtnmHDX8?= =?us-ascii?Q?TO4ExpAQkrZlxGGjBT20nJZ0RMfs2A7e7vMyXDc5N3+atVnKwkOrQxTB5IQL?= =?us-ascii?Q?e9OsdMD5nvD0QeoSvKHennYu8LwkDAApPXcU3BgetAaVemQDG8lJ4JQX2Z5U?= =?us-ascii?Q?+kK8TdrAfryMIMLeSu/MuLS2pOHDbtcU4V37mnnJzZvILztS2c1+que60xoV?= =?us-ascii?Q?DBIgPAjfqd32yj6mTze/72luzF1InbjvE8bC+SKmcNE7PXlIPMz53Qmbx841?= =?us-ascii?Q?53VWVqHLqSYbJ01gyE3OqTPEJZS+XYdzPBc4vLdU3/UVMsWgYd8xvfUq902A?= =?us-ascii?Q?cIN5v7T1EGNnEYPmxuTPBwe1kvDnUuazGxeccLgtawq/7eBKuSaFLR8WX2MB?= =?us-ascii?Q?QMgbf+geRDiGda1Hcz8EN0mr/hVmcOCdkGhMmHuRuONk8dwfzvFArGTDvwkJ?= =?us-ascii?Q?HfOrv39STymeZvze+nkV/GA4zMS/?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR13MB4204AEAF9D0F44DA0E4E0C4CD2AB9DM6PR13MB4204namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR13MB4204.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1dfc797a-c265-4244-7dec-08d984e46e6e X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2021 14:04:48.9151 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yj0jQ7Tnl1cLNxCzqs+/2aIBlCZ8ZshgHZ2hAi23cwrKSKFMq51qj5/3RZgwbn00BEiIWn9Xihsdkw/3Za5faA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR13MB2604 Archived-At: Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 01 Oct 2021 14:05:08 -0000 --_000_DM6PR13MB4204AEAF9D0F44DA0E4E0C4CD2AB9DM6PR13MB4204namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_DM6PR13MB4204AEAF9D0F44DA0E4E0C4CD2AB9DM6PR13MB4204namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear WG:

 

The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

 

The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors.
  2. The document is a “living” document; it m= ay change as it goes through review and analysis by the SPRING working grou= p.
  3. All open discussion points raised on our mailing list= MUST be addressed BEFORE said document is allowed to progress from the wor= king group to publication. A list of these discussion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
  4. If this document is adopted by the working group, the= chairs specify as part of the adoption call that the following text descri= bing an open issue be added to the document in the above-described open issues section:
    • "Given th= at the working group has said that it wants to standardize one data plane s= olution, and given that the document contains multiple SRv6 EndPoint behavi= ors that some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

 

Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

--_000_DM6PR13MB4204AEAF9D0F44DA0E4E0C4CD2AB9DM6PR13MB4204namp_-- From nobody Fri Oct 1 07:11:58 2021 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 A38BE3A0DFB; Fri, 1 Oct 2021 07:11:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHF2WPaY2VwO; Fri, 1 Oct 2021 07:11:50 -0700 (PDT) Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2113.outbound.protection.outlook.com [40.107.220.113]) (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 1E2083A0DF6; Fri, 1 Oct 2021 07:11:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KmRqw5Cv4rgrsLKtvzRLhlNPBQyr3EmnD9PyhB2jjH1oqLCTOo/UFch8teVHkdpI0srn2U5bPpQtXgqL7D+SBNUbyFaG6jKYaibiqERgVKd75Ij9pvsc9ICLk+iWkcMY68ZpHfkZiZu9dB/X938G5+kToww+Lj9f5jhAeHI8s1OgPDObcSvuS5Avrk8kYXJaHKOR5GoKl7tuV8Qh1WDScmW10yG++AzBif1EhUDNcj/AFZxVp4yybRWd878kE345GWZ1H4tvsmfWeJWdu9J8TukwmLOuzuryu+7Y7jZukIvoAz5joTqWmPuLHaRlIfrVNbwLfbwtckipqVovuZzu4Q== 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=Nukgq5Xg3REan7aAIakV+6mTDFRIOzEAx9PIpDpkMzo=; b=KUBcc/Lk7Qm86zQMKGdQoLVIeVKpsiQlclpOWgSNKkXTqONRRJyqxAWBOU2I5Pbgbf0YKSj3H+cceWppLJJ9fU6LP8oOty25M3Yz9Y9cqnEHzuzRfksYR4G9eyCdy+vlm/Gcf4rl+PEb1yfiGmspeLhUNffydhkWJ8Z1u++PR/Zhj2IYJbXTsDYm62N0g5OAAeSTexS6Z5dnCYLo2IDK9uPzZRQDUYH7IUrVw1+Ky0d4aEdfpQZi/e+H8FyR7Clhr/VB1b0hG5NJPOmjDx+c2eu5ZoxyxJCA/MhU7JCvqj1REunsKNKgdqv/xTrQhYVk5TlJh/L4x5pTHBjXZMOxBA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Nukgq5Xg3REan7aAIakV+6mTDFRIOzEAx9PIpDpkMzo=; b=TPCgfxmUJFxRbvPZNmT0jUq9UAxolTDpa50o9BT/Jwi+5uPxYZuPoRyg48yFhPrbugrw4iRUvd82xje8BUWhZAhA3JzkFojJsL7R5gUk1nQ9Mflsosfm9Pki9i/vH7ywVcWacdfO4ZbPsNE7QpFEzoXcMmIw3sdIsqPu5rZl9Ao= Received: from BY3PR13MB5044.namprd13.prod.outlook.com (2603:10b6:a03:362::22) by BYAPR13MB2229.namprd13.prod.outlook.com (2603:10b6:a02:c3::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.11; Fri, 1 Oct 2021 14:11:47 +0000 Received: from BY3PR13MB5044.namprd13.prod.outlook.com ([fe80::2480:c433:fd3d:7357]) by BY3PR13MB5044.namprd13.prod.outlook.com ([fe80::2480:c433:fd3d:7357%6]) with mapi id 15.20.4587.009; Fri, 1 Oct 2021 14:11:46 +0000 From: Huaimo Chen To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQAAjBjc Date: Fri, 1 Oct 2021 14:11:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 666a8ce5-5011-da7e-7af2-16ed41b0f772 authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 44370ce4-5c1b-479b-1d67-08d984e56763 x-ms-traffictypediagnostic: BYAPR13MB2229: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fvBIGv2niX2amc7cX9zKuK+oHjvKvLrw/2gksmE2tMgC8kmcVmtgN2K9Orq/R6s412Y7rY+fFZVKKeaRbrJWLCp65/JNwquhBZ1pRLyOhbt/P2YAIBeMRv+4vwGZN0DNP+hW6OggAbYg3D4+M2zjsubznP0LNdSdU3+ndVQRTYhfsHmRJjbSwBkSjLgY4xVrUPXk//Lv/fjm2MB7feaokhG/3Kb8dRkTajM0Kxf+4zqDFV+dDI3M3xV42zs6SCWXIXHKY3Z2TFkyUvAusRzJJoUJg4GU/Czznj+vNG4ewCkn7eQgDb9MqYqbAqwQRG+WkxuiSVrKwafOP3bHC8hqv8cEDk7luhStnaQPyDVGaqTN9c8UKY/VL79FrysrXnvyP86YL6FnFwLV04V1GLneJ4Do3fWKL+9MVY7gWZxNbgqL1BKpYWgBe+xSTBzsGJJ61xSnWXbEnNeU56w1Xj3XFDfMnFVrGqcP/ykYcdXn8M6PKtc+7T+D6tuHHSmihHuo04j5bCsskqmX8Kz1GHDrJaVWxkLa1CwlO6E/oAAfOq4TE/sRMamZhzSBYcNZ863n4wvpx3tAAx99gxVA0gL8Z6pSsxqfmdO51wrlgO+PlbTCz88eMGmxkoI53Fq8y83e6u1oB1rUvK6muz/6WL2uw1sj7/M9olaDgqQmx7K6JjZunz7HeYQl2TFbP4Xh8V7AYbRrScGzGMD71mgf2LsX+RSvmaLa/XCP4k2Npku1ehi+LCFJOGxPhXu98kTVEcRBBLCFqJxC5wsethSU2NmulugC3mseh7QZeeuhysqwUvE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB5044.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(44832011)(66946007)(508600001)(66476007)(64756008)(66556008)(66446008)(33656002)(966005)(38100700002)(71200400001)(166002)(8936002)(8676002)(2906002)(91956017)(38070700005)(122000001)(110136005)(76116006)(86362001)(4326008)(83380400001)(53546011)(6506007)(19627405001)(316002)(52536014)(450100002)(5660300002)(7696005)(186003)(9686003)(55016002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?oLyg5yd2vX5wXru2eBftG8pdZ9O8fCZNP3sznPU9gW2X8GAiVPLWfRyG?= =?Windows-1252?Q?/ujppkxQZKUsFQWfdCtSr0ESvwAX43piwR+NwQvAVM2uiv2p3YR/H0Vx?= =?Windows-1252?Q?uY2RpU2czQo8SLKMg1/SpmRKMFcR7iElyG3qP1RG/xcAQeTPeLD8pdKy?= =?Windows-1252?Q?LAkGvdz9u9OroF/Zk5evTcBFegmsYNxI3GEImMGLFBnI7Z+K6/Fa4Wax?= =?Windows-1252?Q?a4HhNgro0FoJHPiBEE21LJdCMPzpFUmdBAXKp0F/kawsWu8D7uRjVKDI?= =?Windows-1252?Q?iTo0/UQfpCsxiI5VE//pKm5tVDcEb41TkmmCaZRThxsSRQfk5z7Q8ioA?= =?Windows-1252?Q?wR3xVE6wKTlUdHuufft1EQrM8UoDFjEl47O6wj3Wsf+mVxIztwcCuf+o?= =?Windows-1252?Q?0aocX2LhEfxDnLrV92mYKrU6XUSlKe8ID2U+sUW4LlXCU7ar1jeIZ/4D?= =?Windows-1252?Q?439B6W+glqfdxQekCSmvsC3av6dAEymd96Bj6FwIh4+OBUNHmf4R1BXO?= =?Windows-1252?Q?jGkbvF2XPSXwp3xKKrK7V5BVkHFx8XAx8eHc9kTmvYIjnIxnPskp4x4z?= =?Windows-1252?Q?bw+1VB9p12EHWEoROhSbBsytPkSxNPdLZ2jHcV4Zuw4vWnPbrFqp3Upy?= =?Windows-1252?Q?QOgPn6EYNKTOeDvEVRQ3IjgS8ChorbloQnofnjo3MlPx2emPGtiXw8UP?= =?Windows-1252?Q?6sPPJVVtOavU1pogJ2A7TpYzFMYA3n7/iA/wGfv2k8PXoFI9ZAaIo+D1?= =?Windows-1252?Q?73OAAU19edXj1hOI2dlXvgF/+7jmW7LbrK9homoG7NRYFAhpdMlR6uVs?= =?Windows-1252?Q?vJ8MkFgoKRn/JqY/tUxvciyG+Sas/h6QGrTnlZMrEsusLdLYsnKX86ay?= =?Windows-1252?Q?H0fJxIdoaY1ux2htq5DkuPNkeJucK8Cmf6Ce6cPcTV71acYFAgu762pF?= =?Windows-1252?Q?HUHnelndqIBhaRRPbWfxM8boxLy6PQx2rDgQCWbhokGc41S4s6RyUCYp?= =?Windows-1252?Q?k5D9LgJUlUH2WCcf26psZdkR3pfjtjsnYAsXTermxyHdwvgxpaFiLs2U?= =?Windows-1252?Q?K0vO/yHyJYpMndZjrc6lM6Atfc3sghXbKVzE8k/Rn+FJ7wL8jYGktcZj?= =?Windows-1252?Q?uUqi2+fGmu2Jo3egq7KEdR+xweyco0xnRYwi7LeqdasFhu/AuiOGN+cJ?= =?Windows-1252?Q?mICtIbctbcAXi5i3ARhd1E2TM5G7j24MG4UvQc6+Q62L0o/AkXYHtZXC?= =?Windows-1252?Q?RqD9XQQtSdZUf27qoJLEBHyLruXQxZkU5y75f6bY1TxznV8PJ9lcofX8?= =?Windows-1252?Q?TcybY/paTS1gy/ZyZgCaLevKrfUNW5TavjkUlmATueTGcqfMFUKt/txV?= =?Windows-1252?Q?KMQJ8itZVdO+6pSsNdfxjuXZuu7pIgmdYE0b+mgon3JGBC6bYDPCNa3g?= =?Windows-1252?Q?uDu2sCs1X9/gmZRGTsOzAJdAOAmUkcEWQ//aGSa7DVAu4DnnrEJDWZSs?= =?Windows-1252?Q?581reHqB?= Content-Type: multipart/alternative; boundary="_000_BY3PR13MB5044E83399E03ECA3FAE57E3F2AB9BY3PR13MB5044namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB5044.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 44370ce4-5c1b-479b-1d67-08d984e56763 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2021 14:11:46.2888 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FYEqK1XUJunmliRIaQZ8AZOEqk9KSaNss9PoQ13NlDmoq7aiuoIjHsYk347zEI9PvJWLHEip7Cf9LrRnSGCTtw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2229 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 01 Oct 2021 14:11:56 -0000 --_000_BY3PR13MB5044E83399E03ECA3FAE57E3F2AB9BY3PR13MB5044namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Everyone, I support the adoption of this document. Best Regards, Huaimo ________________________________ From: spring on behalf of James Guichard Sent: Friday, October 1, 2021 10:04 AM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as = the basis for its compression standardization work. That is part of what th= is email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelin= es as follows. By expressing support for adoption of this document you are = fully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a =93living=94 document; it may change as it goes thr= ough review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_BY3PR13MB5044E83399E03ECA3FAE57E3F2AB9BY3PR13MB5044namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Everyone,

    I support the adoption of this document.

Best Regards,
Huaimo
From: spring <spring-bou= nces@ietf.org> on behalf of James Guichard <james.n.guichard@futurewe= i.com>
Sent: Friday, October 1, 2021 10:04 AM
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/
 

Dear WG:

 

The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression.

 

The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document that has multiple SRv6 Endp= oint behaviors.
  2. The document is a =93living=94 document; it may change as it goes through r= eview and analysis by the SPRING working group.
  3. All open discussion points raised on our mailing list MUST be addressed BEF= ORE said document is allowed to progress from the working group to publicat= ion. A list of these discussion points will be documented in the WG documen= t and maintained by the document editor in conjunction with the chairs.
  4. If this document is adopted by the working group, the chairs specify as par= t of the adoption call that the following text describing an open issue be = added to the document in the above-described open issues section:
    • "Given that the working group has said that it wants to standardize on= e data plane solution, and given that the document contains multiple SRv6 E= ndPoint behaviors that some WG members have stated are multiple data plane = solutions, the working group will address whether this is valid and coherent with its one data plane solution object= ive.".

 

Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

--_000_BY3PR13MB5044E83399E03ECA3FAE57E3F2AB9BY3PR13MB5044namp_-- From nobody Fri Oct 1 09:05:30 2021 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 929B43A0CFD; Fri, 1 Oct 2021 09:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8hg_mPP-FgI; Fri, 1 Oct 2021 09:05:20 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 555C23A0CED; Fri, 1 Oct 2021 09:05:20 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id s17so35768538edd.8; Fri, 01 Oct 2021 09:05:20 -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=0iXsX3cxXkP+du5kqfnPXdht+Sen2DO+ze7JcA4ImaM=; b=m9VfTPNWx7RcbG2JIqpliIsMhgvjrs3tky7wq/2CI+uAQIVmqD8ZLDtoyUFvaNwsnz +ngRB/HM88bNP2SEhUE9J3v6z2mTiKnr7/fNieHZEQzzDIksnAoIt0dtaQUpMU89xkXG IxNnqEcpQuM5er65HTwV277JUrJsxe3NMiNeDbBAScPsA8tBdoyRLq+1MYXPK7E0LVZU Bd4bsis8khlGBzs+TpFsG/JrnlyE02dVsGxw8F8HSvMZc9Uo3XTY239VMURYyaViWSHs es0J/lZ6CnnoulHn33g6iHJkcDW6JxuNuX/OfozK/AyEeVJD0Kcjzj/YGN+wK+B2NhPP OMyA== 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=0iXsX3cxXkP+du5kqfnPXdht+Sen2DO+ze7JcA4ImaM=; b=4nnsK/0nbfUcrbMSbnTVtBVj9yxw/LuBpuEX6S8QsNRZLWhhbKo/vyqacJ9zot25lS zLGJMgJfKC9Z66/nVy8o+Li/LuUi3s67osyfgI535DOIZ9veEARcivYBW6BOYaEGA/F3 97bZdJy2s7ohJY50qlX4MLS5xynsB82J9jW6nPq1jCftyvMUONenBV5i+rRmHvDT9s17 hoXVwJb+Q3HglLJsECuZ8H7TsZYiFdBehS+dxwL5XcyjbOcs9E3rqMfAr8V8lYzIHhRJ Gx7FJUSUShncvh90llDizrYOPEXAyfFpru3UDPbgDsUWkXVe2ltibKvwPLW+XNXM1JmC JHfQ== X-Gm-Message-State: AOAM531dazUS6uqhu3JvNcfRQXQpWuVZhKDB95P2HmpgOuN2X/RjRVK2 7hWFcyTdrbh8dKtQRGyxyWMWG6Cj0aCeefJl4Jlb5HHq48JoMQ== X-Google-Smtp-Source: ABdhPJxhANN05vv+Q3ThsxAVEmmFtnMr11jmP1DwFSThzeXDJhWd0BsFxquUHRKc1jdjsVqP2D4J7rMb62V41LNKZ8w= X-Received: by 2002:a05:6402:1e88:: with SMTP id f8mr14929398edf.126.1633104317017; Fri, 01 Oct 2021 09:05:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Fri, 1 Oct 2021 09:05:05 -0700 Message-ID: To: James Guichard Cc: SPRING WG , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b2732005cd4cbafb" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 01 Oct 2021 16:05:26 -0000 --000000000000b2732005cd4cbafb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear WG Chairs, I have a question about the proposed note to be added if the document is adopted by the SPRING WG: Given that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this is valid and coherent with its one data plane solution objective. It seems that there's some logical contradiction in the note. On one hand, it acknowledges that the WG unanimously supported adoption of one and only one data plane solution to compress SRv6 SIDs. Also, the note recognizes that the draft, as many WG participants stressed in the discussion, describes at least two different data plane solutions. Given that, I am puzzled by the phrase "whether this is valid and coherent with its one data plane solution objective". It seems as contradiction - two solutions are not coherent with the agreement to standardize a single solution. Perhaps the note can be more clear about how the WG will achieve "its one data plane solution objective". Regards, Greg ------------------------------ > *From:* spring on behalf of James Guichard < > james.n.guichard@futurewei.com> > *Sent:* Friday, October 1, 2021 10:04 AM > *To:* SPRING WG > *Cc:* spring-chairs@ietf.org > *Subject:* [spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > > Dear WG: > > > > The chairs would like to express their appreciation for all the responses > received to our emails with reference to how the working group wishes to > move forward with respect to a solution for SRv6 compression. > > > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > as the basis for its compression standardization work. That is part of wh= at > this email attempts to confirm. > > > > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging > that: > > > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change = as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the working > group to publication. A list of these discussion points will be docume= nted > in the WG document and maintained by the document editor in conjunctio= n > with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text describin= g an > open issue be added to the document in the above-described open issues > section: > - "Given that the working group has said that it wants to > standardize one data plane solution, and given that the document co= ntains > multiple SRv6 EndPoint behaviors that some WG members have stated a= re > multiple data plane solutions, the working group will address wheth= er this > is valid and coherent with its one data plane solution objective.". > > > > Please consider the above guidelines as you decide on whether to support > or not this WG adoption. Please express clearly your reasoning for > support/non-support as well as any open discussion points you would like > addressed should the document be adopted into the working group. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --000000000000b2732005cd4cbafb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear WG Chairs,
I have a question about the= proposed note to be added if the document is adopted by the SPRING WG:
Give= n that the working group has said that it wants to standardize one data pla= ne solution, and given that the document contains multiple SRv6 EndPoint be= haviors that some WG members have stated are multiple data plane solutions,= the working group will address whether this is valid and coherent with its= one data plane solution objective.
It seems that there&#= 39;s some logical contradiction in the note. On one hand, it acknowledges t= hat the WG unanimously supported adoption=C2=A0of one and only one data pla= ne solution to compress SRv6 SIDs. Also, the note recognizes that the draft= , as many WG participants stressed in the discussion, describes at least tw= o different data plane solutions. Given that, I am puzzled by the phrase &q= uot;whether this is valid and coherent with its one data plane solution obj= ective". It seems as contradiction=C2=A0- two solutions are not=C2=A0c= oherent with=C2=A0the agreement to standardize a single solution. Perhaps t= he note can be more clear about how the WG will achieve "its one data = plane solution objective".

Regards,
Greg<= br>

=
From= : spring <spring-bounces@ietf.org> on behalf of James Guichard <james.n.guicha= rd@futurewei.com>
Sent: Friday, October 1, 2021 10:04 AM
To: SPRING WG <spring@ietf.org>
Cc: spri= ng-chairs@ietf.org <spring-chairs@ietf.org>
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-sr= h-compression/
=C2=A0

Dear WG:

=C2=A0

The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression.

=C2=A0

The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

=C2=A0

Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

=C2=A0

  1. The SPRING working group is adopting a document that has multiple SRv6 Endp= oint behaviors.
  2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change as it go= es through review and analysis by the SPRING working group.
  3. All open discussion points raised on our mailing list MUST be addressed BEF= ORE said document is allowed to progress from the working group to publicat= ion. A list of these discussion points will be documented in the WG documen= t and maintained by the document editor in conjunction with the chairs.
  4. If this document is adopted by the working group, the chairs specify as par= t of the adoption call that the following text describing an open issue be = added to the document in the above-described open issues section:
    • "Given that the working group has said that it wants to standardize on= e data plane solution, and given that the document contains multiple SRv6 E= ndPoint behaviors that some WG members have stated are multiple data plane = solutions, the working group will address whether this is valid and coherent with its one data plane solution object= ive.".

=C2=A0

Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group.

=C2=A0

Thanks!

=C2=A0

Jim, Bruno & Joel

=C2=A0

=C2=A0

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--000000000000b2732005cd4cbafb-- From nobody Fri Oct 1 11:07:20 2021 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 A04693A0EF6; Fri, 1 Oct 2021 11:07:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=KmVPnGgH; dkim=pass (1024-bit key) header.d=juniper.net header.b=Ywd1dp5U 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 c_5quVo3B0Ar; Fri, 1 Oct 2021 11:07:12 -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 459DB3A0EE9; Fri, 1 Oct 2021 11:07:12 -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 SMTP id 191Dt6Vb010182; Fri, 1 Oct 2021 11:07:09 -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=zNXa1sRYUdC9ixztm+nzfDXljL+prPNm1RHpKb1KdZQ=; b=KmVPnGgHSH0vh/QtRL1UaTvmbcet0LdV7fyzEvTh3pQUlHB2grEa8ryRI9UdHJ8pgC8R XutpTFgMI8jmBeFMRnZ2FVu+EokjM9NiAVMX/2xU+jW6l9/9LRUlpMu7uTaEpBD/Z7dj f3CJs/NGkewBx1+XwPArwe/yDoxn5BB6/HNRjIsGP/zXkqMWt6QWtW2aX+EXtvKFhbse EIUcse7z6Cw/exZZmHABD4bs+gJC0k4TY34VaSR3kL+zu4GAhMGUsaO7VzkkNtQo1NT+ daTZtQG/td8AC1gvnm2nCTAoTlCQ3oFwMEwqqCHVL/OWSn4IQ3c+Ltm9HbADQziqOEAf KQ== Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2171.outbound.protection.outlook.com [104.47.56.171]) by mx0a-00273201.pphosted.com with ESMTP id 3be3mvrjts-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 01 Oct 2021 11:07:09 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HrMR7R1IuJDAa6YJoxhc2eWjbs/AS+61/yeCNl1ZT+wKlBUcXz6UTngUqR1C8oiS1sa871HwNj0w8HLdiwBQtLk06x37t7DvdxnO8fJDmbVb+UTBOUXMxWq8Lc1Crr931w0VX+x305Id/bN9iVIN9QZJEeCHLbpvsqdpOxZD33foZrd2noJnIoyassV1hkX0tw22qhNDZiENouziRUWo4ZtfvILLAk21A+bCP21HhJfxcbvcN9V60XAFGILRYkBzGzKPAzwUbOf1ApAislE6NoNZXhL9USHYtOq/SWatOT7d3MJCkNdfawZ488t7Wnc+sqxT4VzrlagNRCMZEwmDkw== 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=zNXa1sRYUdC9ixztm+nzfDXljL+prPNm1RHpKb1KdZQ=; b=bLyO0Bw83UDqOMvbJJrdjbmN7XeDsDN3B7QX3SjDwceBSYK1DtY2tUEyc1uSL2hNgvDAbZ5vy6VlxX7YOE1aCq5GBfGz1mn7Y/7nlZaeGXgm5T5nj88yQQnESlL4K487xM0tAgMmc31IehwwWfWd8+n/ECp6MuJWoQh+ec9tP/H+GyLCY5aeJoGw4ld6iJP+UoafYyIu3byPTUoebNTfxcdzT93BKJdRuWzfUM6BJGdY5yBjKvQ50Me/yVeDjLlQGuWPG1FgxDViwYxh+qKk5zD18VTwRsLmQ+k7TH0kGJYVAqOSKpzh/L1V/pPqc0E7FFQXnhriHIUPcFStdtrH7Q== 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=zNXa1sRYUdC9ixztm+nzfDXljL+prPNm1RHpKb1KdZQ=; b=Ywd1dp5UyNb+w+C0BEpw6HiLS85ievvr0wzJO3b6j5cOF51TjbOQwj467nlVcLlLe9b52UWpYc8aXMU/75Dr49z7s3x285rFYw8VeLxP+Sw0IIaTC6KheoEfIw8ELGHXI6ESnxZ0793UTSTyBbo8t60+GcrH4R7pmkFTKLr887M= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by MN2PR05MB6976.namprd05.prod.outlook.com (2603:10b6:208:188::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.9; Fri, 1 Oct 2021 18:07:07 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4587.009; Fri, 1 Oct 2021 18:07:07 +0000 From: Ron Bonica To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQAH0rRw Date: Fri, 1 Oct 2021 18:07:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-01T18:07:05Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=fc97332a-b1f3-480d-b685-d69b122bdec4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2c6f8b8e-c9bc-42a3-33b1-08d9850647f0 x-ms-traffictypediagnostic: MN2PR05MB6976: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zH8EkI0IQZoZ498lwbeMqNx+ZUlvt7hwDVATH3hUUgcnj51Cj7umC6mS3xKdXl/Q95iGV2FTy7DqDEG3LSSac1uWr1JH2kppdsNKU4IS+O92Tc3OSOsK0SWUVwnuY51/HbDNsRZQk9MSF1VxUTOiaVfy6GsUU1So5rNfkwbi4fzRGgF11+Mv8+gx5YYgk4ZILSHKIHfCujabE0AS5bdFtwwKNcYhZLZXAe+OXxmWCfRpeWBAGkSqeI56RjLhtniwBE45MquwY6XCjoLfibB6U7yskPVgTuZqTST5pzKTqNMTNS0xF91u4k8QogoJq0DEgX2opX5HsYomg20xKMbtYjOL6vqJJ+WiQ6HgALQU1mMiYaSngGl9y869dvlaqPnHrsF7f0IZo98rUZ/vB+xIAFpznOa2S6TSJVyghpWTnGFIm7FrM3O5UNChHO4xw0rJ/HVF16Q5zlxk2ZZ7yejug8Ibn05HN5ROjPhp6xCticDnpJ9l6rQ82Vj3RLlIpRla28wYTmup5TSfCn1Bh/Lsh9Jpg0p6nN9v6bULlJsNj0lo0Nd1GKZsAV11hgLBBcpo4ClUNJbedK89GlyR1xuxqGTtVjAjMgjmMMZEo/qD31vubcxH5A28z/WIWnZxvxOpblXyiEnQp5bcJUDEAUPl192Le+wAd2cddiJngsTdlq5u8K05M6c081QgVQ/x7Dhn/KYkhjIMM/ybDnd0Be0svCLPxAZrgkZYnlNlBFGfyx1gZS9wAkSS4xTuKkwZLqf8BmfcS/VrhoBnG7u1aW40T1+q3DbMKHLSDxXcVrBRdKc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(5660300002)(166002)(7696005)(83380400001)(9686003)(110136005)(2906002)(316002)(8676002)(26005)(76116006)(66946007)(4326008)(53546011)(966005)(6506007)(186003)(52536014)(66476007)(33656002)(122000001)(66556008)(64756008)(66446008)(38100700002)(86362001)(55016002)(71200400001)(508600001)(38070700005)(8936002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?GB8NMRBz3FjpKX/NMIMvTZ2ED3PPV6fJWF2iCAWKEHx+A8kOCMIxB6ylgFIF?= =?us-ascii?Q?uwM8W5DA12njhiQjYn17uTyS+MHn9pBDXv3xFrmXU45CxqwTegr2sIhjR7S/?= =?us-ascii?Q?AUcixxtFvPFxeJ+cJbNv74M9yX0WxGlGusSLrNEx1YgG5wlGMjJTvryD3V2B?= =?us-ascii?Q?uM56VgyCy4tsmrxv/2VfZG/mV/+ieiQwEP3DHNWeyRQWXdvsRUjkagHF1CDr?= =?us-ascii?Q?kh5Q3rQC1X5tW0h/+IaxFsc3zRXl/70FWj+WSO960O2Y4QT+shRx9s3xnY4d?= =?us-ascii?Q?J1r1UWPhTx02bH/NqBDSdxKulF3xb8Y1PVJF+cMj4/xU2Fbq4YfxGL5kQJ96?= =?us-ascii?Q?69KXauM2LtW/Kdh54jPG46OarE6250kfRCZjB4Gz+BGBnMGhsidKgdgsFZ+D?= =?us-ascii?Q?uTr6WWLeS05Zg81cxoX29+PSh3dmLCwB6Bnf+pKwhMuJvFvrSxPSxhRlC+ch?= =?us-ascii?Q?3JVvUlRHfnMMh6eEyzFuWZsGn8wxDZ3L2UU8AaEw32B2/urx/0HdcxC8Ci3y?= =?us-ascii?Q?MKr2bzrZ0T7L2Cbcgv03uQCRr8MmPhP8MGuNJ39vNunuvSBkdZkjjD0cE2QJ?= =?us-ascii?Q?WMPeyXzvabSc097VtDE5LGzNiD7eqenGeS994GcfnhFiTnVgFzKMoOjqJTo6?= =?us-ascii?Q?nENFTe8egui9e/OtNAFuJx/bl9P4cYlwqn7sb/HnGFHUPFA77fnl5b2GOhVV?= =?us-ascii?Q?kVAaEnD4hrOWDjA/J1cnJ4Jo6p5NhT1sD4XOcjuMc66Uu+TUVL0tsKBHIRKV?= =?us-ascii?Q?5dsT00zdidOXphArz714ubpGlJ/A0LC9opdlPHlO04vQmqjBbb8r/t9qDAoI?= =?us-ascii?Q?CTtIbnOL+xMLx4hj0wsxEMGfAABa9Lv7UVGlkY/m7qYKnJF/5mPISyM0dMub?= =?us-ascii?Q?N32QLi227RWb+arD8wDC8CpmM/2qo3WO0Mba5nzIbFclSNNkZDhTc5FDemkJ?= =?us-ascii?Q?JV4lkYZ8r2hVlh5RNgh+ErylZ5UFi2uczYVhm7zCRpQiMaGQTe2yykpEdShI?= =?us-ascii?Q?xNbkNM/6R1rrswnYRf52YB8rBeKnEQRWRN6B3jIHvK1X7Qr9PPo7n6jkF5FI?= =?us-ascii?Q?s/rVqb8Sd0akhhUxKQEOcp0GuUblNUs3KLOavOaglPEhYAUdJSzDx2huaPRQ?= =?us-ascii?Q?SdiHlDBVI0Ky/aF9tOe/WzwDChKFBM4tfcZu1pSgVLQoDKIH2LkMzNbyXhij?= =?us-ascii?Q?800zk7GqZ19iG490dMECvf4HMZSF5QU+DxL13404GPyS68UyH59lSYlvn5NN?= =?us-ascii?Q?M7JHZzqAGufnNfCMqx7KqUsc+WQbfQPT+oyj6ovUtnAG0JooZkds4MQrZXFd?= =?us-ascii?Q?QCFxKDOm1QX0llXkAH/i1znB?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR05MB5316BC55F635637B84F27A24AEAB9BL0PR05MB5316namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2c6f8b8e-c9bc-42a3-33b1-08d9850647f0 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2021 18:07:07.0319 (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: oPbV/llEIWoCT8NpvSZqXCxodLPdMLUSsyBRMEr6umjTcZr0HLURg4R1UbzQR0YscM74dv3EflijSFOxjJgLXw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6976 X-Proofpoint-ORIG-GUID: iFHjo4UZijKO4kt9nZb-dbmrj85-mdwB X-Proofpoint-GUID: iFHjo4UZijKO4kt9nZb-dbmrj85-mdwB X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-01_04,2021-10-01_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 bulkscore=0 lowpriorityscore=0 suspectscore=0 adultscore=0 malwarescore=0 phishscore=0 clxscore=1011 priorityscore=1501 spamscore=0 impostorscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110010129 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 01 Oct 2021 18:07:18 -0000 --_000_BL0PR05MB5316BC55F635637B84F27A24AEAB9BL0PR05MB5316namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Chairs, I strongly object to the adoption of this draft. I also note that this is a very strange adoption call. The WG has indicated= a preference for a single forwarding plane behavior. However, bullets #1 a= nd #4 in the Call for Adoption suggest that the WG has yet to address wheth= er the draft satisfies its single behavior objective. If the draft does not satisfy the single behavior objective, two of the thr= ee behaviors specified in the draft will need to be removed. This is a weak= starting point for a standards track RFC. Furthermore, neither this WG nor 6man has determined whether all three beha= viors are compliant with RFC 4291. It seems to me that one is while the oth= er two are not. Finally, I question the benefit of adopting this draft *before* the above m= entioned questions are answered. This is not a rhetorical question. A respo= nse from the chairs would be appreciated. = Ron Juniper Business Use Only From: spring On Behalf Of James Guichard Sent: Friday, October 1, 2021 10:05 AM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ [External Email. Be cautious of content] Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardizat= ion work. That is part of what this email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as follows. By expressing support for a= doption of this document you are fully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_BL0PR05MB5316BC55F635637B84F27A24AEAB9BL0PR05MB5316namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Chairs,<= /span>

 

I strongly object t= o the adoption of this draft.

 

I also note that th= is is a very strange adoption call. The WG has indicated a preference for a= single forwarding plane behavior. However, bullets #1 and #4 in the Call f= or Adoption suggest that the WG has yet to address whether the draft satisfies its single behavior objective. =

 

If the draft does n= ot satisfy the single behavior objective, two of the three behaviors specif= ied in the draft will need to be removed. This is a weak starting point for= a standards track RFC.

 

Furthermore, neithe= r this WG nor 6man has determined whether all three behaviors are compliant= with RFC 4291. It seems to me that one is while the other two are not.

 

Finally, I question= the benefit of adopting this draft *before* the above mentioned que= stions are answered. This is not a rhetorical question. A response from the= chairs would be appreciated.

 

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;            &nb= sp;            =       Ron

 

 

 

Juniper Business Use Only

From: spring <spring-bounces@ietf.org> = On Behalf Of James Guichard
Sent: Friday, October 1, 2021 10:05 AM
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

 

<= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

 

Dear WG:

 

The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

 

The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors.
  2. The document is a “living” document; it m= ay change as it goes through review and analysis by the SPRING working grou= p.
  3. All open discussion points raised on our mailing list= MUST be addressed BEFORE said document is allowed to progress from the wor= king group to publication. A list of these discussion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
  4. If this document is adopted by the working group, the= chairs specify as part of the adoption call that the following text descri= bing an open issue be added to the document in the above-described open issues section:
    • "Given th= at the working group has said that it wants to standardize one data plane s= olution, and given that the document contains multiple SRv6 EndPoint behavi= ors that some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

 

Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

--_000_BL0PR05MB5316BC55F635637B84F27A24AEAB9BL0PR05MB5316namp_-- From nobody Fri Oct 1 12:33:29 2021 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 AE5EE3A0776 for ; Fri, 1 Oct 2021 12:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=X+9lox3u; dkim=pass (1024-bit key) header.d=juniper.net header.b=XFjsNvvJ 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 a_sP2APHpYqI for ; Fri, 1 Oct 2021 12:33:22 -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 855953A077E for ; Fri, 1 Oct 2021 12:33:22 -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 SMTP id 191E7SMZ012325 for ; Fri, 1 Oct 2021 12:33:20 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=SJNK9Kybbqd8QR1+WrSOngG3eip1sA+Ic8zs2pmfU74=; b=X+9lox3uxbksPYfITtzMvh3TGL0HGOBg4PICNXJxVzCJg4P2OMpSyOdxTy4uQG4fFBkQ /U3B2tHdSnNTrrP/d2pYC1+a0azyuxFqiPZG1ogbQu3ow4aJmDBlVkJhRaBGHrM1JVs8 lyCnzgTb44ICrHOnDZ1tlXjvyC57ZzTaLcC8414CDzuN/9tPZXrFuoNTifAEkR0BlQe1 HZuERd0VI5uJXpEoxC8d6hFqIVawguqpCCRqR2tVzRbDKRw9UTmM05eGW+qEXuPPfkEn ICPflIOR8vFWf9tLjkim8t+etBzVVJyR7Uf74TTHSfxDqFc2Xsk4RTsy4pM/VhY+e3ud 2g== Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2101.outbound.protection.outlook.com [104.47.55.101]) by mx0b-00273201.pphosted.com with ESMTP id 3be3te0q6e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 01 Oct 2021 12:33:20 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EpSlnqce4EXkyx8kRFCiJ53XScNP8TjZnYZO5F+1mx7U9zylhXF0QTkyP4HcXObEHYnEE0IT3ZdA0cxTZf6o1PgzBII5CdcZSuYiEgZSM755RMA10C/Tect88w7pYM+D8KDy/qK82zbJwaEneiD19RVL+/INShE/1ZBq2Rs3OBeApZfSvZsCGBUEz8PdP6Uyhvn4FvxEPTFlv/Ae8gbawPYNeeAePSNg60P0eM1+zkL0gKsiteBBO0szE3XNr4NJ9ZqRdEiVpWTEB3P+4q++ND6dTeHkln6neEVbzGANIqiezoBQQKpDaoLVPL+BTxSggEQexm+UR7n3E6Uhb82XfA== 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=SJNK9Kybbqd8QR1+WrSOngG3eip1sA+Ic8zs2pmfU74=; b=UX9d/KgiQdexuqsa3Q1cv11AAn5i0XEPdD71RUMawZvMCL6ITkahX7VZ5nB1msN+UFocUjxT+5NtoWVg4sVGF7scTVCALlN/96M8xPj8EhSaXgbKucWUmD2D1GWwh1mjdSpgIGHc3JzSf2+38T9F38nIf3dW0qzxLCvNzJGxzTpwTWBtbAWk20mYwX715khgQb4VeNaPL0hIs6HrHJ0IzbkvBPQ1sYeX9jQA8+BWD1J5M6VxFrIZ3q6TiOUsEohw1Ln6VUGxOecpQxjSoo0AenVMOzSVecq9hZ+TX188zfgGsMp9nq/TfjfkH3uV1izFdOShIe1jKsYy5PNg+uM0ig== 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=SJNK9Kybbqd8QR1+WrSOngG3eip1sA+Ic8zs2pmfU74=; b=XFjsNvvJZq+sp5OFeT8PUIkIOwu3dmBuOuuR7wz3GrCoRaU9dkofNVrh08Bed3PkLZtbBy4bvBAfZGEc6OhIMX6CxxPpTjlVa2iimvH15oh05Xj8+y1Jnjub/KKOcIxit+Vn5lcaDdMHQImW4dDpFHi/Rsv1eNnkqaFiq0jBkG0= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by BL0PR05MB4658.namprd05.prod.outlook.com (2603:10b6:208:29::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.9; Fri, 1 Oct 2021 19:33:18 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4587.009; Fri, 1 Oct 2021 19:33:18 +0000 From: Ron Bonica To: SPRING WG Thread-Topic: CSID Question Thread-Index: Ade2+c1KozTuOJAoRFyi9icelIkpNw== Date: Fri, 1 Oct 2021 19:33:17 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-01T19:33:16Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=417dddd8-c85e-4d98-828e-1b3ae185c2cc; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ba5c3d8b-8e1a-4157-9cc0-08d985125206 x-ms-traffictypediagnostic: BL0PR05MB4658: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VE6HjVCntQ5AQQ8UoQFKzg1v9uNIE0iw53RfKKEmShV1bJpStt55BV3mGoaurfsPl73ZXFEUf/D/S2JCyOIq3h7T0dnAz0xOu0SgnwmcCsGYbVjChz49r9xpgZSswRTAEynomuOcQLH8ftIKa+DbACnzU2v6VTQ3PhSugWKDTGPFjn2SZuELNOaa+AZo0Ehd+VQnh0uazXpiMPeIJnUEbDZCtsfFc6I+Fk0mUc1F1svEyC2vS1Erho30WYt5jKPUdRgpU9us9QzHrCKQTo3OiAOkvPxBNEaltDtJvbFByfCKLq6H5opaPcxe8gRDGkM4VqCN3PBTEp9Wdm43s2uiyrMBjVxn3tBghOodd80Y0XKhRJWcB4u1srBAJaSeTcFWwGEJvFeEBMuDrAWCnJfCP/XvsW7uKduAmFVff6M7HU/QFe+1A7Kw3XThmuv0JM5Y45jt1+pP3m/xhYhVLEdC9PwzqIjbTUqV1oFCnd1tLvMLmxpIqXrkWQ18LCmkwvtGodKQX01QwUTsKRftV7MeO2NPjSOqAPKioqK31y0vEx4Z4j72t9i4NI5hWPSBcvZITtkOiQUMN1h/NYHImlwT1V5WJhoLpSv1P2SaHhXZ9d/iT9mZP1T6UdjaYcjMnjyjk4bHZ3RFBwQJaZVZLv93mObnGJ9ventlQ0+vLLxLAM8LrgE00eCOLpxGo4Rh0RNI97FPjeC9WJVDFnK6K1HoSg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(5660300002)(26005)(6506007)(55016002)(8676002)(66556008)(7696005)(316002)(76116006)(9686003)(52536014)(86362001)(38100700002)(122000001)(7116003)(64756008)(186003)(71200400001)(8936002)(33656002)(66446008)(4744005)(38070700005)(6916009)(66476007)(3480700007)(2906002)(66946007)(508600001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?GNaZuiveZ+dHJpLWh/liQ01rZqmD72zQEgLU5L2ne1ZrDokez6ECilJ6N3aN?= =?us-ascii?Q?SsUL4LYG4imKPf56MGENfuvbCN36n1Ld/CqXjpCtMjdXFckqok6AgcLzrdcx?= =?us-ascii?Q?Oa2lACkV4EpHyd4pucrVE16XhWpjrpPi7SBHy8Shu50Zjs1OVGFOSKJMo5lv?= =?us-ascii?Q?GqjxHl9DtRLlxrjSRToHhaf2wVf2pVj1j0h782HwfkyuQGq2cn5qNddmgiMT?= =?us-ascii?Q?X5BGrK147HCmyGGvTV0hOpNZgq9AuOcuxPUcOeAv19fcoLaCJl51cHK52OlW?= =?us-ascii?Q?C4SMr4Nx9hVtuNPEpObswua2flAKPwEi7+kPZVLaqdZmDel0n2q5BfU8qHaZ?= =?us-ascii?Q?25boMdAbYyYc8mu7LAZdUGovW/RhUXRmU9uYb5xTePCn9KA3OImGNK1LhXrK?= =?us-ascii?Q?h7XAJX/qi435c0giOePmjUAKIPj2cfvXBITzR0GXzXKwL9TK4Y77nBmR3iYZ?= =?us-ascii?Q?z/Dzy7/kLtZXYNHmhrgEirGMOt1pYljX/GWIJXk7bseEaYNMjSdyzu1VqnmR?= =?us-ascii?Q?1JLhiL1rvBT+orf+5yQEZbmdA+PuuV9MYu42gkzrTg8GTYIsRY8ldnc7Q8N9?= =?us-ascii?Q?kT7GgK71yVoUoT8yV1itaOlsb1MI1mJa1v/KRL429+098xeQVTug+nN7ma8q?= =?us-ascii?Q?2+nEB7h2YSYx3Ye0wBfsCIW2MIJDFX35UY8pOIQmzLy7fnUU03wIqPxBESuz?= =?us-ascii?Q?7rku12/nLskE2emZhb459borvLVCqIpuypDPJGrCTivEY89JG3p0Uuz3PFLl?= =?us-ascii?Q?1/QV9fLOgy0xXsimxc0cIqQ+hSofqqiTI726g9wBGoN1SrMcg1eEQ8BbJLus?= =?us-ascii?Q?w3DOGGJwPgmsQeC9HmH+0UCO+IQRRo+UOCEslgxJn3Dol98HwTmcg6ZNj2yn?= =?us-ascii?Q?oi9HcUEZO0nghEHgEc0epQGY4QDp4h63H2GrMvS2qy7ZdKT5+4/1Kaz571xS?= =?us-ascii?Q?Kb+4RQSW+9QneFlmCqBpYTTQgiYsfAYH/HV6h3tylMnlqLzepFxBnf2iXKek?= =?us-ascii?Q?GGkDxUn7umvpKRHJrXOj8V7hw8dmKou5CDv0l1FjCFMb232BZTDwHINDuPLo?= =?us-ascii?Q?iFzfmk5heX6rlkUD4dUsc4N/F9PlApEXywLhtvfF+pOF5QqNYbDCe++bMgon?= =?us-ascii?Q?Gz2NntGn+bfyd00GtsR88VVKVLtbpy4R1mKLPbOXo/t51jNShTiPHZxjStq2?= =?us-ascii?Q?A2I8V1vm/C6mYGkETSomo6r4GUZENoA5MccLyNF2IptZOQINznyIWP3Z9AT3?= =?us-ascii?Q?rvrdnDOB/pYfQyAfwGuf1GX20LLy9MoOfBJ1Mamp24ylSSAR2rGWIagW51+d?= =?us-ascii?Q?vrju6M/KY5Hq1Yve+syXwe8Z?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR05MB5316659C505F9BFBE915D59BAEAB9BL0PR05MB5316namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ba5c3d8b-8e1a-4157-9cc0-08d985125206 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2021 19:33:17.9837 (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: ls/VP14Tjl8mjoI2fM5Ceym46B6ia5yI438BK8thnb25wrFrtXrdMkaI5NHQuvaOXBwxcK84iPyUDFdL0jgK7A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB4658 X-Proofpoint-ORIG-GUID: opS-psd00ot7VS1o4ThYhHMwcFWMDBgp X-Proofpoint-GUID: opS-psd00ot7VS1o4ThYhHMwcFWMDBgp X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-01_05,2021-10-01_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 mlxlogscore=954 priorityscore=1501 adultscore=0 clxscore=1015 phishscore=0 suspectscore=0 malwarescore=0 lowpriorityscore=0 mlxscore=0 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110010138 Archived-At: Subject: [spring] CSID Question 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, 01 Oct 2021 19:33:28 -0000 --_000_BL0PR05MB5316659C505F9BFBE915D59BAEAB9BL0PR05MB5316namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CSID Authors, Assume that an SR path contains segments 1 through 8. Segments 1, 3, 5, and= 7 are END SIDs that use Next-C-SID (i.e., uSID). Segments 2, 4, and 6 are = END SIDs that use Replace-C-SID. Segment 8 is and END.DX4 SID. Please provide an example that shows us: * What the SRH looks like as it arrives at the first segment endpoint * What the IPv6 Destination Address looks like at each segment endpoint= , including information required to parse the Destination Address = Ron Juniper Business Use Only --_000_BL0PR05MB5316659C505F9BFBE915D59BAEAB9BL0PR05MB5316namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

CSID Authors,<= /o:p>

 

Assume that an SR p= ath contains segments 1 through 8. Segments 1, 3, 5, and 7 are END SIDs tha= t use Next-C-SID (i.e., uSID). Segments 2, 4, and 6 are END SIDs that use R= eplace-C-SID. Segment 8 is and END.DX4 SID.

 

Please provide an e= xample that shows us:

 

  • What the SRH looks like as it arrive= s at the first segment endpoint
  • What the IPv6 Destination Address looks like at each segm= ent endpoint, including information required to parse the Destination Addre= ss

 

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;             =             &nb= sp;            =             &nb= sp;            =            Ron<= /o:p>

 


Juniper Business= Use Only

--_000_BL0PR05MB5316659C505F9BFBE915D59BAEAB9BL0PR05MB5316namp_-- From nobody Fri Oct 1 13:21:28 2021 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 A79703A095A for ; Fri, 1 Oct 2021 13:21:25 -0700 (PDT) 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, 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=liquidtelecom.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 aWdl-uvn_A0l for ; Fri, 1 Oct 2021 13:21:20 -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 91F693A0954 for ; Fri, 1 Oct 2021 13:21:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquidtelecom.com; s=mimecast20210406; t=1633119676; 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=0FDUdfUApQexTsQsmoDc8FcPr/QJzTQGT6LGZ0U69Oc=; b=B8K/0UHQLzwsK9oJBDVnIljLVIrt+AtKrYiwrE7UqvTPm82bFhw0gy+McuVf/dyoAe8K21 Lsd1BkSHlJA/ca+Mxg7/BDvrm8kSuvxPv07AEgTR/QruN05T81CG35xgJ5GceCttEv2IRU 0tclTk3kG2jdcLM1hEdQ2KgKO3unU6w= Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03lp2051.outbound.protection.outlook.com [104.47.9.51]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-105-Z87TEca5OqG4Iz_sKeyukA-1; Fri, 01 Oct 2021 21:21:14 +0100 X-MC-Unique: Z87TEca5OqG4Iz_sKeyukA-1 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com (2603:10a6:20b:346::6) by AS8PR03MB7889.eurprd03.prod.outlook.com (2603:10a6:20b:420::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.14; Fri, 1 Oct 2021 20:21:13 +0000 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9]) by AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9%5]) with mapi id 15.20.4566.019; Fri, 1 Oct 2021 20:21:13 +0000 From: Andrew Alston To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQANZx9M Date: Fri, 1 Oct 2021 20:21:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b27bcd6a-1360-44e8-38e6-08d9851903a5 x-ms-traffictypediagnostic: AS8PR03MB7889: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: sG6mgJVHzmLlokBuyvxBJQMIOgPKA51vusFsiwUQKETOk8VtEJ0zfqYdJlMfgQni79hrhDTLvd4GL+KSMy8fkyG2TxYrBFcVL9b0kS3XEXyvHP8O2vknrKs4Rfes9ojbByUtejhvaR2WdpZZWJFZ2av+hGcOUiA7MosG2iN274EVIrI7IdxX6QtQnuW1aTA1k6vLwxEyXD5TR2S899AEdjR/KiUfHC1XlzimhlFVCm69N1QVNgdwNGv+7fq+XMTnSvg6Q+4z7YBvVb6jz09CCjqLqHjiLyVgjRbrVP6j60b2HISD/GpdNvQVN7zCoOGt33Q5bI3GWfDFrZoxC3sspLsaMGvukgJOyYBWfzfFlWcArBgi9zyVegYWW4GjimHph4u3ISWa9/0bn1isAVEOkOladQSq618XtYGuFVBMMZBm0Mhn1Guh93AA3LDzEVPXN+Op+ObXOBQaj7QHVZvJez3L2AZx1TIAmrEkCvUuP2/bUWDoxxhdqK8L14leGAPi/RMOewODt/4ry/voEgt46FVpAbzzhYcVWsMZsNhEyx4eNIHIAcZP4y27A3gDGwJ8TyMvCwqUP8qsxv01CCasDBedshgZPOuy4sm8JzKNwIV0dMvXPUzm94qz0x2lyTxphI1d4Gbb9WPzJkbvA2rofjizADWME6MWY2TZyGWDIvWMXsGJLSz5inXAfKAMPwcLJu/FdXR1/DsEgEnm3Hebzkzi9zyyGlGNLBaHmf+I2NCx3g6jwNKa2jsRWPA7y6OzvDttipa1vfiXT7o3sdsjmTeiq/mv1BFTHZjfKfrK48k= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR03MB7622.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66556008)(66476007)(66946007)(508600001)(2906002)(64756008)(66446008)(86362001)(110136005)(38070700005)(8936002)(8676002)(6506007)(53546011)(122000001)(76116006)(91956017)(316002)(38100700002)(33656002)(966005)(186003)(4326008)(5660300002)(71200400001)(166002)(55016002)(7696005)(9686003)(83380400001)(52536014); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?1PMnomQhPhVVV9TffNj9qUYXKSUYMeKS+HgimjMfYVeKjQ3z2gqo7SdX?= =?Windows-1252?Q?d/qx/2GJ7BFeR4sUrk2K1iN0SqGxomqq6JgC40KqFyf+fxuBFB44cmeA?= =?Windows-1252?Q?Sk/sirmM60BMRQAxbh3obwZn42UsAZWLjlOFUaUIyV1yY69zh/cZv75C?= =?Windows-1252?Q?MJ2LX0WI0FWdaJ4hfdPz93KJMAv7y5NpuZKDAGkt0Dfw0x6XZ+xyrtr6?= =?Windows-1252?Q?3kX+yG2UMTghPEHr+jEEtHlFix8SZhCUbCRwunlg2Iq6AmnR9EEGvsCA?= =?Windows-1252?Q?BzCha+em6e/THXTc0vXixWOeS6qoui19EhgCHAb/Pe8R9vdWJO1d2wVk?= =?Windows-1252?Q?pKj+sD0atpmwKIVzxRpyoSBBTMwlDI3eDtqRHW8r77aFEHfN7GQ7obvu?= =?Windows-1252?Q?wxl05DvwNW559P/iVEtiLY1m0H69aUMAPIC66akFvRlCMAzsVczf/s/8?= =?Windows-1252?Q?VOe7D+L85iAEOmd/S47doOsO2jbPzy6iu5pilD/NxAwc+0L44hBpGBE9?= =?Windows-1252?Q?Fp6RmhbtNXH/l1QF6CbJyZqtEbb/Q11tRKQb8JBzky1bc0hwcLDEGqnj?= =?Windows-1252?Q?7Kkf7vVcsTs7yKl1HpuZOY19rRosxk/LrDs0M1plrBhMbTI4j0M+wAFJ?= =?Windows-1252?Q?tl1I9244yTfUu490My0vvdhYxGJuZzBtZ8XU69KrNzClMXZFjtLsUlwH?= =?Windows-1252?Q?+1FH5rOEeKvaiYCAJ+W345amuYJvG+WEvxTbgmk0LminCAcoWTmN4wBa?= =?Windows-1252?Q?IeKiWa8lWO/zXqPQkidPAFtZ1SOLGSUxcwodq0S/u5B2p3GhI5kqEEJ9?= =?Windows-1252?Q?TUu+fnFHhoeah3e3aDu8enKGNOSVG9jf9kOfhA7S9zgNls0oqLOveLHZ?= =?Windows-1252?Q?eANQRSCeGbo99+akeGGw7D+LJUJAvxIZsmLQNiaJMJCKRj4eoGLko+iD?= =?Windows-1252?Q?6PI0cktXBbsGGKqLzSxMEvbAyqd5iME9+0APnXJRcTuXAT5ywYeibfAr?= =?Windows-1252?Q?fp/C9F9UaTq27NHxX1wgnpAoMBGlIWV22yGcfqWjTIVAZknhMhi0n/nx?= =?Windows-1252?Q?otR/6LMb0yg2S0oemEOLpL/XVrLgH3vlykwK4yI+ZHubuEH5TeIbf3pX?= =?Windows-1252?Q?dPsBN4Y+O2XeAH6WkUYYL3x9cYGk4jR6v9hpCvy5YVdFcpM/5+8FJRqx?= =?Windows-1252?Q?sSqJGNxv0wV8eEYNbQB8WXppY/25mdq107MFmTG0XCjz/wB0Zq0HWlmc?= =?Windows-1252?Q?cs4qa8Fe6ZsvgVuiCOrZ1zmyhgetZixBnsqr3PvdYQDPSMViy9rCpn8m?= =?Windows-1252?Q?BCt8LBwFnpPSSOieJ43sQSdsrXyi+74jbdmz9LalPY+7wNr1KR7Np58J?= =?Windows-1252?Q?5zsOZK3BFID1+qGix0s6A28s5n6hLKUrpzpCeuGD/u0s3Pa7P2WdZUfL?= =?Windows-1252?Q?BctbRtLxhUnHKHXLaJYDJecrf/3UX3fVvwwr0t9xM2IDCPkT72BZqsn9?= =?Windows-1252?Q?fbExhAtn?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB7622.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b27bcd6a-1360-44e8-38e6-08d9851903a5 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2021 20:21:12.9769 (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: vR7p01cq1AU4HKpLi6shMoDMuPsHHaTMAL3Lc/hUjf/UGyqyFvNYzo1iAR+VOWpYln2TXa6SSlAmh2fhcJIoOUyyjuiYQmrY0CBwk1YQi7Q= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7889 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquidtelecom.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_AS8PR03MB7622225AA75F05DD54B2234AEEAB9AS8PR03MB7622eurp_" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 01 Oct 2021 20:21:26 -0000 --_000_AS8PR03MB7622225AA75F05DD54B2234AEEAB9AS8PR03MB7622eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Sorry =96 but =96 I=92m a little confused here. Because the way I look at this =96 the working group clearly stated that th= ey wished for a single behavior =96 and this =96 does not deliver that =96 = it is two separate behaviors. As such =96 I see this call for adoption =96= irrespective of the merits or lack thereof of the draft, as a clear defian= ce of the stated will of the working group. This is simply does not fit into the definition of bottom up approach in my= opinion =96 and if this is the way that the chairs wish to proceed =96 the= n the only way to do that and still fit within the bottom up approach is to= first ask this working group for its consensus to deviate from the single = behacvior approach that the working group agreed to. As such =96 I must strongly and unequivocally object to this call for adop= tion Andrew From: spring on behalf of James Guichard Date: Friday, 1 October 2021 at 17:05 To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as t= he basis for its compression standardization work. That is part of what thi= s email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guideline= s as follows. By expressing support for adoption of this document you are f= ully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a =93living=94 document; it may change as it goes thr= ough review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_AS8PR03MB7622225AA75F05DD54B2234AEEAB9AS8PR03MB7622eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Sorry =96 but =96 I=92m a little confused here.

 

Because the way I look at this =96 the working group clearly stated t= hat they wished for a single behavior =96 and this =96 does not deliver tha= t =96 it is two separate behaviors.  As such =96 I see this call for adoption =96 irrespective of the merits or lack thereo= f of the draft, as a clear defiance of the stated will of the working group= .

 

This is simply does not fit into the definition of bottom up approach= in my opinion =96 and if this is the way that the chairs wish to proceed = =96 then the only way to do that and still fit within the bottom up approach is to first ask this working group for i= ts consensus to deviate from the single behacvior approach that the working= group agreed to.

 

As such =96 I must  strongly and unequivocally object to this ca= ll for adoption

 

Andrew

&nbs= p;

From: spring <spring-b= ounces@ietf.org> on behalf of James Guichard <james.n.guichard@future= wei.com>
Date: Friday, 1 October 2021 at 17:05
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

 

The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a sol= ution for SRv6 compression.

 

The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document = that has multiple SRv6 Endpoint behaviors.
  2. The document is a =93livi= ng=94 document; it may change as it goes through review and analysis by the= SPRING working group.
  3. All open discussion point= s raised on our mailing list MUST be addressed BEFORE said document is allo= wed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maint= ained by the document editor in conjunction with the chairs.
  4. If this document is adopt= ed by the working group, the chairs specify as part of the adoption call th= at the following text describing an open issue be added to the document in the above-described open issues section:
    • "Given that the working group has said that it wants to standar= dize one data plane solution, and given that the document contains multiple= SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution obj= ective.".

 

Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open d= iscussion points you would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

--_000_AS8PR03MB7622225AA75F05DD54B2234AEEAB9AS8PR03MB7622eurp_-- From nobody Fri Oct 1 13:30:58 2021 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 4C1253A0982 for ; Fri, 1 Oct 2021 13:30:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 lggVMcVuinca for ; Fri, 1 Oct 2021 13:30:51 -0700 (PDT) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 693183A097A for ; Fri, 1 Oct 2021 13:30:51 -0700 (PDT) Received: by mail-ua1-x930.google.com with SMTP id t36so7548254uad.4 for ; Fri, 01 Oct 2021 13:30:51 -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=krLxf+YZ29rNOSpZtUOBmvMprekfAMBUDCf8cGP2c/A=; b=YqDdygz0k90JRi4QvDVBMAxp7/eZGhxxmsYFNFcbKOSN7xLN7/weDqHwQm1dzCGSGr txxc64a1Td6w+DVcYCuZ9oohO4bbbewhXoEB7529kNibmdMpiU9K37/L6FLbpOJn364B 9kqJjIup2Nf3hv5+g5TbhARGMh7chEve3eK4L6k6S8lG5CD86DfPix2og5V6oNzkIVgG zmYIoHIrVbDdm5UOm6oXdRji93aZg1dRpp/jZqJvkkj9gPIXwa5xw972UVQeNX3LXLZQ jrueAE8jUTYgYlYowWFSbzIbcq9bSO7wZ8F1i0aSUadOfGNRjQapGVSKD5OQzOQ79nnd FLUA== 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=krLxf+YZ29rNOSpZtUOBmvMprekfAMBUDCf8cGP2c/A=; b=MlDjnPFtS2ncZhNAbYD4mIh8JjW/Zhz1DydMmGdzThem5yMP4Ar/4Z5cRqnCFCi9st jUa6Fs6Ybpfylreg1Y4Cc8Ck6BlnFsSufur9shFvkbgvchAOXgk152Hoxd1YW6VB2R+Q ee1Y/RlMxQzZE7OHqqgPz7Ma5q0VpdDYEahtEx9bZiRPrW6Xeas3ZKbe2IxPKjaH8LEG ldD9GGMTImhq5WVs2aVxCyrnPw5WSeyGjI2nwrBVIPsieSFLDODPlPDwHfbQokXpKtpc LRLHazolK3L3a/uiHFygrJFbwV5haeL0VJkmuRVPhYXUjGHCVQaTzv2HfXIuj3kkmwDG X7Ug== X-Gm-Message-State: AOAM532HaRrbXVm77KrGmf9Yyc4EXuviIP9HwRJuveuz5e8jxrhjxPBy EMvdetybP6DY1YgxhVtbo6DpxoMTIS0mYSNF+N+ROg== X-Google-Smtp-Source: ABdhPJyjw6iT5lfPNdzQrZqlDdEr7YAoEwn2Let2KjUVvXgM8kQ9xI5przQo7jilQSpvCSYBAyGgDMyb5fq3bVjvhfg= X-Received: by 2002:ab0:7254:: with SMTP id d20mr12427723uap.116.1633120249622; Fri, 01 Oct 2021 13:30:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Fri, 1 Oct 2021 22:31:37 +0200 Message-ID: To: Ron Bonica Cc: SPRING WG Content-Type: multipart/alternative; boundary="0000000000005acb6b05cd5070ab" Archived-At: Subject: Re: [spring] CSID Question 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, 01 Oct 2021 20:30:57 -0000 --0000000000005acb6b05cd5070ab Content-Type: text/plain; charset="UTF-8" Hi Ron, Have you read this draft ? Quote from it: It is recommended for ease of operation that a single compressed encoding flavor be used in a given SRv6 domain. However, in a multi- domain deployment, different flavors can be used in different domains. On Fri, Oct 1, 2021 at 9:33 PM Ron Bonica wrote: > CSID Authors, > > > > Assume that an SR path contains segments 1 through 8. Segments 1, 3, 5, > and 7 are END SIDs that use Next-C-SID (i.e., uSID). Segments 2, 4, and 6 > are END SIDs that use Replace-C-SID. Segment 8 is and END.DX4 SID. > > > > Please provide an example that shows us: > > > > - What the SRH looks like as it arrives at the first segment endpoint > - What the IPv6 Destination Address looks like at each segment > endpoint, including information required to parse the Destination Address > > > > > Ron > > > > Juniper Business Use Only > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --0000000000005acb6b05cd5070ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ron,

Have you read this=C2=A0draft ?= =C2=A0

Quote from it:=C2=A0

   It is recommended for ease of operation that a single compresse=
d
   encoding flavor be used in a given SRv6 domain.  However, in a multi-
   domain deployment, different flavors can be used in different
   domains.

On Fri, Oct 1, 2021 at 9:33 PM Ron Bonica <rbonic= a=3D40juniper.net@dmarc.iet= f.org> wrote:

CSID Authors,<= u>

=C2=A0<= /span>

Assume that an SR pat= h contains segments 1 through 8. Segments 1, 3, 5, and 7 are END SIDs that = use Next-C-SID (i.e., uSID). Segments 2, 4, and 6 are END SIDs that use Rep= lace-C-SID. Segment 8 is and END.DX4 SID.

=C2=A0<= /span>

Please provide an exa= mple that shows us:

=C2=A0<= /span>

  • What the SRH looks like as it arri= ves at the first segment endpoint
  • What the IPv6 Destination Address looks like at ea= ch segment endpoint, including information required to parse the Destinatio= n Address

=C2=A0<= /span>

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Ron

=C2=A0<= /span>


Juniper Business Use Only

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--0000000000005acb6b05cd5070ab-- From nobody Fri Oct 1 13:35:09 2021 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 2160C3A0A27; Fri, 1 Oct 2021 13:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=T3Lw+4Ru; dkim=pass (1024-bit key) header.d=juniper.net header.b=TDvGwxBd 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 JrY0jljBrOjA; Fri, 1 Oct 2021 13:34:54 -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 797613A09E7; Fri, 1 Oct 2021 13:34:53 -0700 (PDT) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 191JWV0w029271; Fri, 1 Oct 2021 13:34:53 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=ZgPlM034wOhLTwH0nRnZEFfpt4Q+qoQcVnxQHhT3wsQ=; b=T3Lw+4Ru00vfmUu7Mx7o2TLuaRypSDKbuTsFXqwJI6fyc0iIxUrrqIYCl/qyNXnEM1S0 re/iY/pIub2Obl6nZABueIQstBgf0Va5y/Q2WYUMFwovGBN5W14+K4rTrnPe8NIb/SnC kFI+sQ+0gk6EjWcwfQWOfHwHV9zjVIiRBkwjcZgy/01rldb3Je4LfOEtrT+DBu7cE8li iR3w3C5gGn4gJDlcweYoZHqZhA9qyZ9hL5hCYDP5hnnPcD5pefuupd3S6YbmP9vNJAT/ Cj7yUYaHplWuA21QiK/OgpRJb61BRG/JWRmzqX1zk2i3nfTOzmnzvMThuY/UViqngpKs IQ== Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2168.outbound.protection.outlook.com [104.47.55.168]) by mx0a-00273201.pphosted.com with ESMTP id 3be8k202wm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 01 Oct 2021 13:34:52 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iev0IPuTOHkjYeSSaBa6m9Z4zK+f9/5XLHrOWA7MgI57gBKOAyYvndjsDm77CYfZLFgiAARg8dYZUyvq8rHHlfvm/0c/H0t7sHppbkg2AdTE7HWoA31LFKvO9ZYYOdCUhFvb9lP9eZysGRme6hhgA6KCtxB/omuCXdWIGHgI6D+rxQkX2oMSxzu/8WLKSeU5j3GHQ2U8+r3LHfcA2uaewuiVvGlnh/8zobBTY2Hq/GTaxoDj/2YAhe+/o01Cau+jg6VHK8kpk5WWHI3K8FkGhSUQWPWGOWQ5rO61/ss3bfJJAvvmAYwO0rcTO3tuI1qSqLyO7JXR5P38Xl2DMaJeOg== 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=ZgPlM034wOhLTwH0nRnZEFfpt4Q+qoQcVnxQHhT3wsQ=; b=Uzwcq/JGSQoqhrYxh2SA5bvSNOlNOs6skDIYaj3EC10gWiiXg4Yw4gUmXvOF0J7ZCyAzohrrU1zs6P46oD2gs1bl1DLUznhnuQImONAcqstH5w7jBbHB2m3gSOC4H9yXkco2HfFrCcaRvFzeJTaonFb+noUaGoqObLJiMp+ERuxj2D2JerqbJQ4U/2XRCCH57l1XVIU158FYYiIsg5uvnxb+EGb96x2DVdGGH/qdlZHTstRKGKslfMPftKYPBvFS1hmWQ5yY7AfFAC0mOfSReoSPRLzsmiB5yFvFmtEHAbn3QyLwnOLgdW6+XHo83HUIia7j/wEjen2CX5mw2WXqUw== 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=ZgPlM034wOhLTwH0nRnZEFfpt4Q+qoQcVnxQHhT3wsQ=; b=TDvGwxBdZfXEH4htwcA3sYcNERLl0LSdIUEhSMeKKt2muyF8keVRYheVP+8mz4gBcI+/x1qeil0k+NoTy6oZ32UlMnhrNu2mYP+j93yt0a4qHy5ZnsI+v07GPRzO18VMNXzQ94vQHX/lCekWF5nnyZvlw+KhIZJ0Mqa+lcsHS8s= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by BL0PR05MB5217.namprd05.prod.outlook.com (2603:10b6:208:88::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.11; Fri, 1 Oct 2021 20:34:50 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4587.009; Fri, 1 Oct 2021 20:34:50 +0000 From: Ron Bonica To: "6man@ietf.org" <6man@ietf.org> CC: SPRING WG Thread-Topic: draft-filsfilscheng-spring-srv6-srh-compression-02 Thread-Index: Ade3AXyWK2NzAamgSlCvJ497z/5RLw== Date: Fri, 1 Oct 2021 20:34:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-01T20:34:49Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=2d4e6758-5224-40c7-a45e-bf48b4ff636a; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 341830a9-4000-4c48-0cf8-08d9851aeaf3 x-ms-traffictypediagnostic: BL0PR05MB5217: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5236; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JPglE3aHApe1neuL0ugf/+KlUCdGSTJJ4j7Js7XUI/2hZtZr2Ms5laLPv0PWiYeevNyMIVM1y9b3PWgdhABecCbeukhb1rWjketdPu0O2DczJdGkKnspDMtwEEedMqSf2tm8S/bWwnZXzPtGhVQnYSGPIQNq7iZvVyEzJWcNxXWUKKMcrfH8FRqmVdiR9oHHYRCv6ghereFQIPpxw9BhzL3qZGBPvphDU5PFY+h2P5iLnsQZvD/h8IBTf4h9ZKcrk75vBFFFwana80AutpaGLAASqtdmCfB09mlxTmJACp7Dy9WRAbr4h9SEc/hWDDe0IklQV5d0yjJlV/NQWvEPhz49L05K+sM+ItgGJO+IT1qCARdWlkZdccBcgKd/OFahCbmlXdYPgZatt419BZJo5FNcWrIJ180o388mNvpl6gzP+Pif2D9i5+4ZxewHCCXwhstPBWMIpW1CmbRYupUIQjenEPNEKfFO/WbPp4VEh4xVg0WwDULbo1EgyWmSvaiFHFJL53XxCaAp6jHqaVsY9VJgjt9EI7eQ9IOzTNAbOuBYnXTeu8LcNH02mGN4iA/RX6Q/LJ615TQjYmlk8FFmGiNw7TKTUoFtK9RUadRx0uN9z2tS4HfEVEXkE1FuMszr+wvNVkAj2xsbb2Ar2IYKjnvyt328BuJHWz0CWm/BZplDM98BtPH4T9JozVIDkNSRlkYES8tP1VIV6f6WHXwr2w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(6916009)(4744005)(2906002)(66476007)(66556008)(66446008)(64756008)(66946007)(5660300002)(52536014)(7696005)(316002)(508600001)(86362001)(9686003)(76116006)(26005)(33656002)(71200400001)(186003)(55016002)(4326008)(8676002)(450100002)(38100700002)(122000001)(38070700005)(8936002)(6506007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?+7PbogBk9UE/BCSloWyEwSQlo+4e6FN5NhYxo7NjVRrlj6Fuh3vhPSmonGMw?= =?us-ascii?Q?DCyx4OSZqIhT00n5o5tk44tIj4HstDpKs+OBXpsPw9eDPxyFW2Ze1KzlLk6R?= =?us-ascii?Q?3PCxPUp5vqE5sgtf7Bjv4QGB9CaCJlmkWy97QYlQ3SlVOhiu2gFe5eABSbH6?= =?us-ascii?Q?obzrZt3KOHTjRHEXn+S2h2KeOitDRRVdmLTAS5Xsc2uSpgFOgxnBAE+1mT1S?= =?us-ascii?Q?VmWVfuaOvLYA0KVzcaDRxCVffhAShWBOqL6/D72WeBTOfrvlQtYkSF06txEO?= =?us-ascii?Q?o3gBzKQq4Yt9RUbCxDJDcVPEmdhWjmJUiDRps4HmkyFIUdDXnl+cw3k9PLs2?= =?us-ascii?Q?07dqNyij4gYNvkFt/XLaHQWxkwrKbNpCn+c66tjhH9jNeEIHGFCio9ul1LeQ?= =?us-ascii?Q?4UTfUoEvkG8NDzF8kTbRImJGTMjEWtJrTYywP3UM4ENxZDNaQm/8E9Ci1Sr1?= =?us-ascii?Q?PiQ5sPGN4UXtz8uteFyR1rli5bsC7awWbHI/RKQQyMnmmADcAS/Kk2Z6wAZr?= =?us-ascii?Q?RLTCELBePl1EEZ8HxN87OqVEbM1nYplcr+O6P/O8Et0qc7bSTr9HNNdf9QKD?= =?us-ascii?Q?9Tsx4T1xGf3caa20bsFKKQfFzgCgAn3wz5+XVMIkodmdqaosR5bPEcfO4TeQ?= =?us-ascii?Q?88W93ivw1Ikc8jBuUPHu7T/kJXIdZ97kMk3Y7+Z6TG3qMUqLWZ4zVK3CNJ6R?= =?us-ascii?Q?gKMo2h3gwWWHV9Jc+hKmGgjhLMGB5HB28TKNY8xOl3LtCHKIRUccM1TNLBYY?= =?us-ascii?Q?uoDVGhBBjS8DbFYyZ5Z2IT/nla5DXVraNORsfCa82kIjOQwLZ+HtdlortRVb?= =?us-ascii?Q?xJ//czpeKm5Td5yiwIfxD2wor+ccVBUP7uJRRPM4T1C2o+QCLd8j/yslP+vq?= =?us-ascii?Q?exSSJF0RaQw68bPNeFOogycuGZQd61qtz1S/d9P64Je0JKURrcx8sIdFiQxa?= =?us-ascii?Q?+qaDUKCyfat7JVZhlf+YMZ+zJExVmdvo8c8FHlpj/IqMFORGUmWUykFdWz0E?= =?us-ascii?Q?TZ1K2TnFxtGvKxUpynN+1SIZx9BDHsXYZGPcl8MMvS266US+SLaYWjWTzNcG?= =?us-ascii?Q?2a6zA246JxHpwWr9WGWeLHfksAKz/fMsHU5/fXZrecPSeuozKeF3MfwUkCPo?= =?us-ascii?Q?eqNDtkLd2CqDDzYsehzqWcQyLH6XUsdnL9SMuPsrkEKbAF1C17xhiHYShuD+?= =?us-ascii?Q?WtGAtZ5NNsyaDWTTTZO/teJyHadfwrOQavliZn5eCT9gNgOqUqMibpKpPCBV?= =?us-ascii?Q?V3cSD+BsSWKiQM9nhP2i8zgNzHxIzKUU8Mkly/bUY44SKw4rOMVNBdTFoV2F?= =?us-ascii?Q?CIYhbMDPmuYNUIX1ZYAaQYUe?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR05MB53162B04FDEFC64060FCFF57AEAB9BL0PR05MB5316namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 341830a9-4000-4c48-0cf8-08d9851aeaf3 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2021 20:34:50.5817 (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: uebWooBiwpi3al/3HJHsA4K92E6FWvktsU4i1bXPZWXP2HeZWLrHeoVfUfa/DAbH1TN7fww0ooikRhO5E1vZIw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5217 X-Proofpoint-GUID: jZZ78mwftMr4Sjfv4xdtxH5EaeMTWeVh X-Proofpoint-ORIG-GUID: jZZ78mwftMr4Sjfv4xdtxH5EaeMTWeVh X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-01_05,2021-10-01_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 phishscore=0 clxscore=1011 lowpriorityscore=0 adultscore=0 mlxscore=0 mlxlogscore=739 spamscore=0 bulkscore=0 suspectscore=0 malwarescore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110010143 Archived-At: Subject: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 01 Oct 2021 20:35:07 -0000 --_000_BL0PR05MB53162B04FDEFC64060FCFF57AEAB9BL0PR05MB5316namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new SID= types that can occupy the Destination Address field of an IPv6 header. See= Sections 4.1, 4.2, and 4.3 of the draft for details. The SPRING WG has issued a call for adoption for this draft. It is not clear that these SID types can be harmonized with the IPv6 addres= sing architecture. Does anyone have an opinion? = Ron Juniper Business Use Only --_000_BL0PR05MB53162B04FDEFC64060FCFF57AEAB9BL0PR05MB5316namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

Draft-filsfilscheng= -spring-srv6-srh-compression-02 introduces three new SID types that can occ= upy the Destination Address field of an IPv6 header. See Sections 4.1, 4.2,= and 4.3 of the draft for details.

 

The SPRING WG has i= ssued a call for adoption for this draft.

 

It is not clear tha= t these SID types can be harmonized with the IPv6 addressing architecture.<= o:p>

 

Does anyone have an= opinion?

 

   &= nbsp;           &nbs= p;            &= nbsp;            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =    Ron

 


Juniper Business= Use Only

--_000_BL0PR05MB53162B04FDEFC64060FCFF57AEAB9BL0PR05MB5316namp_-- From nobody Fri Oct 1 13:44:12 2021 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 AA5043A09D3 for ; Fri, 1 Oct 2021 13:44:09 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=liquidtelecom.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 YXLr_QtcudBq for ; Fri, 1 Oct 2021 13:44:04 -0700 (PDT) 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 2CD233A09D1 for ; Fri, 1 Oct 2021 13:44:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquidtelecom.com; s=mimecast20210406; t=1633121041; 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=fRMKtqTxPigIEfqlA9c7AXiR4ICRXwqmkbG1eJ0CBjg=; b=pVS3H/Nsf1rfyhfYGkZDIBT+prKwIizKBIoe42BbU+pMZHsNNvRoDpxVAPU28tykF1+NCI QzMIJPIhJhy7m4sh8NZsQvjW+Z3s3VxTY1h9n3/xP3Y3/hdk4bm57mTuqzxUyPrIdfa1D6 eJ+SvHqjJ2rXC0bNZxdGOLnan0NPQp8= Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04lp2052.outbound.protection.outlook.com [104.47.12.52]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-40-jZsqlc-FNJqK1wzftNFTOQ-1; Fri, 01 Oct 2021 21:43:58 +0100 X-MC-Unique: jZsqlc-FNJqK1wzftNFTOQ-1 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com (2603:10a6:20b:346::6) by AS8PR03MB7985.eurprd03.prod.outlook.com (2603:10a6:20b:428::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4523.16; Fri, 1 Oct 2021 20:43:57 +0000 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9]) by AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9%5]) with mapi id 15.20.4566.019; Fri, 1 Oct 2021 20:43:57 +0000 From: Andrew Alston To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQANZx9MAADOxzs= Date: Fri, 1 Oct 2021 20:43:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ffa55bf9-5ecc-43c3-28d6-08d9851c3092 x-ms-traffictypediagnostic: AS8PR03MB7985: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: DeOxDQdFnu6ASlOv6e/mqzfIH4rQtK4I7I+3weNn3SQOlzkBqZsDETp6OZPTYKDcSop7IkesDsvdA4yCW9N75lR9Y6i0JRLboY99ZBxYbVZ0A4N+D/NA0rD2ZlKBghYfFGEAgUJjOwer2b/4JNGV/JL2e5h23Xa3y034F4foac+oaook4rMvrJmhgEwAlxSV9ufSLhggpU4t+XijwXkQnB0znFh98NUqZ4XC+lmOqZ4w7n7lL56s1CmMGhShhg1XISSy4dfR1xHGZa1iLRpWOAlbkrHeY/hYDGHoVO1IsYboOtQt2AzOfabGA8W62lbnZAz7I+AO1tUWeT/WKCOslFS01Uco0uqs7x7e9JnFnHrsnsxQUqiib3z23be+FTgCbwS11NOWtWI0rF3ESIvECWCeOB8vWAr2I0qxf4PG+ssCgczVcI7WL3hcFXYyPAWPakkkETVwVSWaeU6u50sv6Qx8x2FaURsogJ3oVSOaK+532bZdJ+lAFh1l+7z/BgVHu/2DeNAliro9GoHFFU9dFhdWOWe8LNTZ0iHsHwnz6EQXbOEHMN54NqPY7LTQiDpZNSCXlP7Z/eWweyglTg5WH9lAFoh+iTcrLtmgaNlcGobNCKN7gBnvFuFxqHH4i6OcJPQZ32fqDF+ej42jY1+Tu7y6uvxMZCiTINFbcFgHyCjWmFojz4X3J7lV8SfQwJp+7EYw1DUtjoqbCUMkJtGN7GAm8k9fDv568clGwvBZo0p4CbikG14wF7Y0b25dxHv4ST9RLilOOMMyQjvlesUX3vyBxBVvCWkKchTsHIbjq8Q= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR03MB7622.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(38070700005)(2906002)(966005)(7696005)(6506007)(66946007)(508600001)(66556008)(66476007)(186003)(83380400001)(91956017)(76116006)(55016002)(5660300002)(2940100002)(53546011)(33656002)(316002)(110136005)(8936002)(38100700002)(122000001)(52536014)(86362001)(4326008)(8676002)(71200400001)(64756008)(166002)(66446008)(9686003); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?7A1DSAw+Z3QxXu9ptLEDYyyCvKuEUvCvwk2osTT3NoQcERAKQreywwYf?= =?Windows-1252?Q?KsxkWd3+zA3W+w5cjINbWUIE3HHJo9GL/VU+iu/iV4kMmLu3PjP0Uurm?= =?Windows-1252?Q?HtGAty+CWjLUuyt/6uBLWCjclUf5LYmNmEM50KrN0rUvEt8xhOw8ZEDV?= =?Windows-1252?Q?qrZAXV/lqRozuHwLXnJMrh2TbsCRAFnEXZ56yc2hnlWrr9liK3xeyBsB?= =?Windows-1252?Q?a/emA7za3OlksZwAa5/4BJ+MwI8z2KA3UFmazvfZ0MyL3PSMGQgN1HjD?= =?Windows-1252?Q?RpxPuI7pgKixRAkkdzkCBsbxdt6wlTzaGdIBIYkB2sw9ZCZOqm5aYzpv?= =?Windows-1252?Q?2zilm0DsH+cpCHy58PgAY/GaLw8A9KGkXU8MMHDHuzpLKS20kMEzdYnC?= =?Windows-1252?Q?rNVFyFiSRbG4ZDqGzMNp1BBahAhg3i4aKKNobb93pmq2X7G0Jryh2guP?= =?Windows-1252?Q?PokSBPnT9AHjhRR6S/iclSvJDOuR+UftnpuY91BqEDmyu9j6+M+D4KA7?= =?Windows-1252?Q?FUrENc7EPR8bl5qFhIeK+1dME73R3clsTzP1pI9oJzgC6XIXbLyCBPUd?= =?Windows-1252?Q?INcUJE6YAqrmX6c3pSSnmDx8um2A7zjkwO9cvaXqk7o+O/kntV6U4XfF?= =?Windows-1252?Q?t3UCbA0OG93b7h93DraZZfwcT8KYw28iRMhsg7Cyo1gGqiPHPv/1A99v?= =?Windows-1252?Q?i3z76SHf4SLk/0pJYVVzx8+JacOm2RTWkGioDGLCFz0MWKzHdHBkl3J5?= =?Windows-1252?Q?a3JqM9HUe8fXvkZ3KpRRdRqIC7/8btAvopA52ByIc+IerrmW+YaxdQ0Y?= =?Windows-1252?Q?FEXy5py6vPaxeceUb3nFQfa8d2MwZt8aqvaABrV/2KQgYVGWcjjGbaa3?= =?Windows-1252?Q?YA+tnVlH6EWzRxFBYl0y3nqujes/qtI5CePUam0rlWd51jEuridkk/vy?= =?Windows-1252?Q?Dkjq8u4S0KL7VSHDP+TxhO1fkFwup6kGziI9PcXiAPlgNTduoXO+7VpD?= =?Windows-1252?Q?jIRu+VKqiT0Bywork+SXXW+/Ni6JPBynPpJz0OHFThkYdyNhIN7J1TEL?= =?Windows-1252?Q?ZhQVOZJWkSj83aVX3gZFtouCnvFOEctmIMepuJG0jGgWMRVvVOu7YE5K?= =?Windows-1252?Q?X6JaOJx3444v5w0nbirZDK5kt3wHKFibT+qmKFOHCAYDg434vXwQE/LD?= =?Windows-1252?Q?ZafnVV1k0XYZZzgTxFBIr/6XuA24GUDJCeSoopFV+pilDAdmgfvTL5VS?= =?Windows-1252?Q?7bPB1kIrizdMrK2qZMOFaKnH/rNNJzoei6jo5RJx8Md1UXZ+VJRBgmsC?= =?Windows-1252?Q?BFKjPPMzSUNgLcTz7vhrjH8973n0qeSdKhCoepI02vCB/2x93tRofXRR?= =?Windows-1252?Q?ykocb6ARPnP1izPFzDawD3xt1G6RWWpT1JhdK+0WQUqsTZCfam9yg60z?= =?Windows-1252?Q?1cLnhJBiI2C5T/fqBNWEoJFzXEMpUMEAAkC1uTIjI1ZPh2cFe2EU5keX?= =?Windows-1252?Q?0WBf+nST?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB7622.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ffa55bf9-5ecc-43c3-28d6-08d9851c3092 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2021 20:43:56.9273 (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: quB65Eh9EQaf79K91tsLElEzHfgx8b5LaGYLabgUKzLyzDvBjWgOr1jqJvy9SXXv5fruCtxMkv0M1+l84yYEcraNUQpeFD86j1853E7SoB0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7985 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquidtelecom.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_AS8PR03MB7622767A3EE5A9BA0E6F374AEEAB9AS8PR03MB7622eurp_" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 01 Oct 2021 20:44:10 -0000 --_000_AS8PR03MB7622767A3EE5A9BA0E6F374AEEAB9AS8PR03MB7622eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Just to add to this, I am one of the people who clearly stated that I didn=92t think a single so= lution was the right answer here =96 and I stated my reasoning clearly on t= his list. I still believe that =96 however =96 I recognize that the founda= tion of the IETF is found in the bottom up consensus approach =96 and when = the working group has demonstrated such clear consensus =96 to defy that = =96 is to defy what makes the IETF the IETF. So =96 While I still believe in multiple solutions =96 irrespective of that= =96 I find this call appalling =96 because as much as I believe in multipl= e solutions =96 the working group consensus should be sacrosanct. Andrew From: Andrew Alston Date: Friday, 1 October 2021 at 23:21 To: James Guichard , SPRING WG Cc: spring-chairs@ietf.org Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/draft-fi= lsfilscheng-spring-srv6-srh-compression/ Sorry =96 but =96 I=92m a little confused here. Because the way I look at this =96 the working group clearly stated that th= ey wished for a single behavior =96 and this =96 does not deliver that =96 = it is two separate behaviors. As such =96 I see this call for adoption =96= irrespective of the merits or lack thereof of the draft, as a clear defian= ce of the stated will of the working group. This is simply does not fit into the definition of bottom up approach in my= opinion =96 and if this is the way that the chairs wish to proceed =96 the= n the only way to do that and still fit within the bottom up approach is to= first ask this working group for its consensus to deviate from the single = behacvior approach that the working group agreed to. As such =96 I must strongly and unequivocally object to this call for adop= tion Andrew From: spring on behalf of James Guichard Date: Friday, 1 October 2021 at 17:05 To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as t= he basis for its compression standardization work. That is part of what thi= s email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guideline= s as follows. By expressing support for adoption of this document you are f= ully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a =93living=94 document; it may change as it goes thr= ough review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_AS8PR03MB7622767A3EE5A9BA0E6F374AEEAB9AS8PR03MB7622eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Just to add to this,

 

I am one of the people who clearly stated that I didn=92t think a sin= gle solution was the right answer here =96 and I stated my reasoning clearl= y on this list.  I still believe that =96 however =96 I recognize that the foundation of the IETF is found in the bottom up = consensus approach =96 and when the working group has demonstrated such cle= ar consensus =96 to defy that =96 is to defy what makes the IETF the IETF.<= o:p>

 

So =96 While I still believe in multiple solutions =96 irrespective o= f that =96 I find this call appalling =96 because as much as I believe in m= ultiple solutions =96 the working group consensus should be sacrosanct.

 

Andrew

 

&nbs= p;

From: Andrew Alston <A= ndrew.Alston@liquidtelecom.com>
Date: Friday, 1 October 2021 at 23:21
To: James Guichard <james.n.guichard@futurewei.com>, SPRING WG= <spring@ietf.org>
Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/d= raft-filsfilscheng-spring-srv6-srh-compression/

Sorry =96 but =96 I=92m a little confused here.

 

Because the way I look at this =96 the working group clearly stated t= hat they wished for a single behavior =96 and this =96 does not deliver tha= t =96 it is two separate behaviors.  As such =96 I see this call for adoption =96 irrespective of the merits or lack thereo= f of the draft, as a clear defiance of the stated will of the working group= .

 

This is simply does not fit into the definition of bottom up approach= in my opinion =96 and if this is the way that the chairs wish to proceed = =96 then the only way to do that and still fit within the bottom up approach is to first ask this working group for i= ts consensus to deviate from the single behacvior approach that the working= group agreed to.

 

As such =96 I must  strongly and unequivocally object to this ca= ll for adoption

 

Andrew

&nbs= p;

From: spring <spring-b= ounces@ietf.org> on behalf of James Guichard <james.n.guichard@future= wei.com>
Date: Friday, 1 October 2021 at 17:05
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

 

The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a sol= ution for SRv6 compression.

 

The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document = that has multiple SRv6 Endpoint behaviors.
  2. The document is a =93livi= ng=94 document; it may change as it goes through review and analysis by the= SPRING working group.
  3. All open discussion point= s raised on our mailing list MUST be addressed BEFORE said document is allo= wed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maint= ained by the document editor in conjunction with the chairs.
  4. If this document is adopt= ed by the working group, the chairs specify as part of the adoption call th= at the following text describing an open issue be added to the document in the above-described open issues section:
    • "Given that the working group has said that it wants to standar= dize one data plane solution, and given that the document contains multiple= SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution obj= ective.".

 

Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open d= iscussion points you would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

--_000_AS8PR03MB7622767A3EE5A9BA0E6F374AEEAB9AS8PR03MB7622eurp_-- From nobody Fri Oct 1 13:53:22 2021 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 72F633A0A40 for ; Fri, 1 Oct 2021 13:53:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 eWK7yKLkhOKa for ; Fri, 1 Oct 2021 13:53:15 -0700 (PDT) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 683A13A0A3D for ; Fri, 1 Oct 2021 13:53:15 -0700 (PDT) Received: by mail-vs1-xe33.google.com with SMTP id l19so12828100vst.7 for ; Fri, 01 Oct 2021 13:53:15 -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=7aPmoJxsfnEeOZy99c/PxAXZjNQoVBmqFLkP0M4+cVE=; b=AGbGecTekXYIMfDg55+3EKeYmR+ShL7cegvs+xPqnwdYr75OUWgd8LhJUzHUOK/Ma7 5sKn9RrtAiXhWRquDAr5u+i22rdRwJHJj3dcu+HL6vidaF5tJMXqAhJchQnAii3kTjXp DiQ0NfjTqo2vOV8PW3cmDP4DY2tBD27yPonT1rV3ORTBXKFB7HXCAIh9fTrjc5dVkcq8 M6H2+druPk21l1+VU0gYYxeQMiy3l7GkKu/D74e+tbAOWkxnYS0lY1VjI2oaZytxii5f HdjANYPWzC/mS6q9dz4p4l4KYf8vuTD5ffGwTNrG+DRyxdk5gd0y2cTEgSVQH8nvhXuG GExg== 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=7aPmoJxsfnEeOZy99c/PxAXZjNQoVBmqFLkP0M4+cVE=; b=DeEemQo1/JvhTp/fna60jI5EZMm8bFDUgk4LuAeUK2EB9MIS/w9JUWXTo/VKw5N4h2 wjzSDyqSVgjfgtA7THQ8bfzdqAUAoMHozir/V9J6dnxznTppC3PBLb+cAu8uK3qdVZHe JfOgp8E9LSHgJzP+VFP3UhCLhZT15eY09nhWgv3QVMX3foPRMkSrui/CjdKHcmjYDgKz 3Ln4M9pEi1DB5tGbCojUWCZVlu8u4iD1XKGtbCHRZdakLTwX3hXGeW6Ke9A5v/7Q38j9 f3hlYEiswPG88MgOToIcU6OLDix9A3E/paEpd6vwexT4Wf4kiVANKyZsQusOsZjsP7sP bZzQ== X-Gm-Message-State: AOAM532VIMj5bLqw43Om0WJvIo5iiutUT7avIcRJuooqRFsvQCx3tjak zlfVBKu2b1X3YFcHMJFVs1kNA22xOAemWHFLloC8AwK8sE18Dg== X-Google-Smtp-Source: ABdhPJyerF5rX6VZUPFqDRYKNzh5nkFKfbxOfz3SJ31xXuxF6aMo0/Sy+CvNAN9eaIKoxv50fUzRA5PTbujelEE8vCg= X-Received: by 2002:a67:ab48:: with SMTP id k8mr3832225vsh.30.1633121593670; Fri, 01 Oct 2021 13:53:13 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Fri, 1 Oct 2021 22:54:01 +0200 Message-ID: To: SPRING WG Cc: James Guichard , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007798f905cd50c07d" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 01 Oct 2021 20:53:21 -0000 --0000000000007798f905cd50c07d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable All, As agreed by WG and reiterated by chairs during this adoption call WG agreed for a single data plane solution. That means that the proposed solution MUST be fully compliant with the specifications in [RFC8402], [RFC8754] and [RFC8986]. To me it does not mean that only a single flavor of the encoding within the above bounds must be allowed. It would be pretty bad and innovation killing to support one interpretation of encoded bits and never consider alternative one. Just think that in modern data plane customer in his domain may download P4 code and setup forwarding as he seems fit. Yes on the other hand ASICs may not have that flexibility - well they may not always be used in programmable networks. I am under the impression that standardizing RFC8986 which supports many flavors and behaviours on a single SRv6 data plane with well defined SRH we agreed that networks can move forward from the current monolith to flexible forwarding. The document in question only adds two more flavors. I hope regardless how it end up with the SPRING gates will not be closed forever for other proposals with new flavors on how to interpret Locator, Function and Argument bits in the SRH (yet still bounded by [RFC8402], [RFC8754] and [RFC8986]). For the WG call I support the adoption. Kind regards, Robert On Fri, Oct 1, 2021 at 10:21 PM Andrew Alston wrote: > Sorry =E2=80=93 but =E2=80=93 I=E2=80=99m a little confused here. > > > > Because the way I look at this =E2=80=93 the working group clearly stated= that > they wished for a single behavior =E2=80=93 and this =E2=80=93 does not d= eliver that =E2=80=93 it > is two separate behaviors. As such =E2=80=93 I see this call for adoptio= n =E2=80=93 > irrespective of the merits or lack thereof of the draft, as a clear > defiance of the stated will of the working group. > > > > This is simply does not fit into the definition of bottom up approach in > my opinion =E2=80=93 and if this is the way that the chairs wish to proce= ed =E2=80=93 then > the only way to do that and still fit within the bottom up approach is to > first ask this working group for its consensus to deviate from the single > behacvior approach that the working group agreed to. > > > > As such =E2=80=93 I must strongly and unequivocally object to this call = for > adoption > > > > Andrew > > > > *From: *spring on behalf of James Guichard < > james.n.guichard@futurewei.com> > *Date: *Friday, 1 October 2021 at 17:05 > *To: *SPRING WG > *Cc: *spring-chairs@ietf.org > *Subject: *[spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > Dear WG: > > > > The chairs would like to express their appreciation for all the responses > received to our emails with reference to how the working group wishes to > move forward with respect to a solution for SRv6 compression. > > > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > as the basis for its compression standardization work. That is part of wh= at > this email attempts to confirm. > > > > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging > that: > > > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change = as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the working > group to publication. A list of these discussion points will be docume= nted > in the WG document and maintained by the document editor in conjunctio= n > with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text describin= g an > open issue be added to the document in the above-described open issues > section: > - "Given that the working group has said that it wants to > standardize one data plane solution, and given that the document co= ntains > multiple SRv6 EndPoint behaviors that some WG members have stated a= re > multiple data plane solutions, the working group will address wheth= er this > is valid and coherent with its one data plane solution objective.". > > > > Please consider the above guidelines as you decide on whether to support > or not this WG adoption. Please express clearly your reasoning for > support/non-support as well as any open discussion points you would like > addressed should the document be adopted into the working group. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --0000000000007798f905cd50c07d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

As agreed by WG and reiterated=C2= =A0by chairs during this adoption call WG agreed=C2=A0for a single data pla= ne solution.=C2=A0

That means that the proposed so= lution MUST be=C2=A0 fully compliant with the specifications in [RFC8402], = [RFC8754] and [RFC8986].

To me it does not mea= n that only a single flavor of the=C2=A0encoding within the above bounds mu= st be allowed.=C2=A0

It would be pretty bad and in= novation killing to support one interpretation of encoded bits and never co= nsider alternative one. Just think that in modern data plane customer in hi= s domain may download P4 code and setup forwarding as he seems fit.=C2=A0

Yes on the other hand ASICs may not have that flexi= bility - well they may not always be used in programmable networks.=C2=A0

I am under the impression=C2=A0that standardizing R= FC8986 which supports many flavors and behaviours on a single SRv6 data pla= ne with well defined SRH we agreed that networks can move forward from the = current monolith to flexible forwarding.=C2=A0

The= document in question only adds two more flavors. I hope regardless how it = end up with the SPRING gates will not be closed forever for other proposals= with new flavors on how to interpret=C2=A0Locator, Function and Argument b= its in the SRH (yet still bounded by=C2=A0 [RFC8402], [RFC8754] and [RFC8986]).=C2=A0 =C2=A0

= For the WG call I support the adoption.=C2=A0

Kind= regards,
Robert


On Fri, Oct 1, 2021 at 10:21 PM And= rew Alston <Andrew.Alston=3D40liquidtelecom.com@dmarc.ietf.org> wrote:

Sorry =E2=80=93 but =E2=80=93 I= =E2=80=99m a little confused here.

=C2=A0

Because the way I look at this = =E2=80=93 the working group clearly stated that they wished for a single be= havior =E2=80=93 and this =E2=80=93 does not deliver that =E2=80=93 it is t= wo separate behaviors.=C2=A0 As such =E2=80=93 I see this call for adoption =E2=80=93 irrespective of the merits or lack = thereof of the draft, as a clear defiance of the stated will of the working= group.

=C2=A0

This is simply does not fit int= o the definition of bottom up approach in my opinion =E2=80=93 and if this = is the way that the chairs wish to proceed =E2=80=93 then the only way to d= o that and still fit within the bottom up approach is to first ask this working group for i= ts consensus to deviate from the single behacvior approach that the working= group agreed to.

=C2=A0

As such =E2=80=93 I must =C2=A0= strongly and unequivocally object to this call for adoption

=C2=A0

Andrew

=C2=A0

Dear WG:

=C2=A0

The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a sol= ution for SRv6 compression.

=C2=A0

The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

=C2=A0

Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

=C2=A0

  1. The SPRING working group is adopting a docume= nt that has multiple SRv6 Endpoint behaviors.
  2. The document is a = =E2=80=9Cliving=E2=80=9D document; it may change as it goes through review = and analysis by the SPRING working group.
  3. All open discussion= points raised on our mailing list MUST be addressed BEFORE said document i= s allowed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maint= ained by the document editor in conjunction with the chairs.
  4. If this document is= adopted by the working group, the chairs specify as part of the adoption c= all that the following text describing an open issue be added to the document in the above-described open issues section:<= /li>
    • = "Given that the working group has said that it wants to standardize on= e data plane solution, and given that the document contains multiple SRv6 E= ndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution obj= ective.".

=C2=A0

Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open d= iscussion points you would like addressed should the document be adopted into the working group.

=C2=A0

Thanks!

=C2=A0

Jim, Bruno & Joel=

=C2=A0

=C2=A0

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--0000000000007798f905cd50c07d-- From nobody Fri Oct 1 13:55:07 2021 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 2F8973A0A4A; Fri, 1 Oct 2021 13:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 cJmRLnK9ceNl; Fri, 1 Oct 2021 13:55:00 -0700 (PDT) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0: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 5925E3A0A40; Fri, 1 Oct 2021 13:55:00 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id l6so7063929plh.9; Fri, 01 Oct 2021 13:55:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=kweHyE0Bv+eqbNhOpv5aty/LKaYnFrgQOCtU2e24JAQ=; b=o47z+S0F+98Sl/HATYyK07xo199YuU7dpG8IMNId+E8mtzw7I1EIYGyHnPTXC0x2Aw /6mBH03ySGkH5cKVIwzw6W8x3xj82NCtubltUt44LzCJanE1w9zuCTfxuUNIUH9XRWNc EarP9LbePlK1Q1AjAQqKgZ2G2mdXTta7g7l/8tQNJX4F0ruJHsn8EXHDsxkYqTrxvBLj 3LHNx4YfnYpE+SoI6Ipe1DgL2Uz4SQ+iEFNDgZp+tbz8HJrl8wsHgzMMmQXh5dqJ9Q5j ywgCdoJcXrJ3Sd4grRLpe5lQEsImYV44l7d5YFLGdbl5Wlq8bs0Eg5Oeepq5DQqsI1jW WOEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=kweHyE0Bv+eqbNhOpv5aty/LKaYnFrgQOCtU2e24JAQ=; b=oTfcsyvqgGOim9MJR1DnrUEQ0h8YVIHIonSIELxlzpWZ09b+RNuagTZilo2acYttrd yLee3NF5xPfA3f+R/y3PCgYktQMt5M13VP7OD+4A9ScfwRIqFmdwhDJlaR3B0/XMvrv1 rPgGwncCP4rGw+waeICjev9uReCgBMUxaJ86nB/IIsX0SmfFzLeR9Ptyx7H2gRkvPDNH odwfiqenAc8TUqzccPzEE+pCUUxpFL0HzdfG2lDW6f4vA+K+hlv2LJNMwQuC/TDWWVhy R/kBCS4X8aznc6JTWKoONpCmCQgIFuHaFqVbLejfGf7amwOiiQ5wnPaL1XD16qMOKQ9x Jb0A== X-Gm-Message-State: AOAM532T/wr0VpAIt7G0yJfppQP0gh4D5hhMW/4CsJIUPRkcKNNKGJFt CZ3KAb2IjHTIioi0qQLzCgLEJcFGA0256A== X-Google-Smtp-Source: ABdhPJz34e43qx2MvWVxj3rCuEUnUtKONJT9CNknSQ+c4zOjxAq3/odR8UYVnsVZsBgTees0PBkDbQ== X-Received: by 2002:a17:90a:6b01:: with SMTP id v1mr22294014pjj.6.1633121699072; Fri, 01 Oct 2021 13:54:59 -0700 (PDT) Received: from smtpclient.apple (c-67-169-103-239.hsd1.ca.comcast.net. [67.169.103.239]) by smtp.gmail.com with ESMTPSA id x22sm7089076pff.197.2021.10.01.13.54.58 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Oct 2021 13:54:58 -0700 (PDT) Sender: Tony Li From: Tony Li Message-Id: <03B8E50C-B8FA-4DCB-A4E4-91C33590E57C@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_D8966074-9F00-41A2-B508-6B94A63774C7" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Fri, 1 Oct 2021 13:54:57 -0700 In-Reply-To: Cc: James Guichard , SPRING WG , "spring-chairs@ietf.org" To: Andrew Alston References: X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 01 Oct 2021 20:55:06 -0000 --Apple-Mail=_D8966074-9F00-41A2-B508-6B94A63774C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 I object to the adoption. Tony > On Oct 1, 2021, at 1:43 PM, Andrew Alston = wrote: >=20 > Just to add to this, > =20 > I am one of the people who clearly stated that I didn=E2=80=99t think = a single solution was the right answer here =E2=80=93 and I stated my = reasoning clearly on this list. I still believe that =E2=80=93 however = =E2=80=93 I recognize that the foundation of the IETF is found in the = bottom up consensus approach =E2=80=93 and when the working group has = demonstrated such clear consensus =E2=80=93 to defy that =E2=80=93 is to = defy what makes the IETF the IETF. > =20 > So =E2=80=93 While I still believe in multiple solutions =E2=80=93 = irrespective of that =E2=80=93 I find this call appalling =E2=80=93 = because as much as I believe in multiple solutions =E2=80=93 the working = group consensus should be sacrosanct. > =20 > Andrew > =20 > =20 > From: Andrew Alston > > Date: Friday, 1 October 2021 at 23:21 > To: James Guichard >, SPRING WG > > Cc: spring-chairs@ietf.org = > > Subject: Re: WG Adoption call for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = > Sorry =E2=80=93 but =E2=80=93 I=E2=80=99m a little confused here. > =20 > Because the way I look at this =E2=80=93 the working group clearly = stated that they wished for a single behavior =E2=80=93 and this =E2=80=93= does not deliver that =E2=80=93 it is two separate behaviors. As such = =E2=80=93 I see this call for adoption =E2=80=93 irrespective of the = merits or lack thereof of the draft, as a clear defiance of the stated = will of the working group. > =20 > This is simply does not fit into the definition of bottom up approach = in my opinion =E2=80=93 and if this is the way that the chairs wish to = proceed =E2=80=93 then the only way to do that and still fit within the = bottom up approach is to first ask this working group for its consensus = to deviate from the single behacvior approach that the working group = agreed to. > =20 > As such =E2=80=93 I must strongly and unequivocally object to this = call for adoption > =20 > Andrew > =20 > From: spring on behalf of James Guichard = > Date: Friday, 1 October 2021 at 17:05 > To: SPRING WG > Cc: spring-chairs@ietf.org > Subject: [spring] WG Adoption call for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ >=20 > Dear WG: > =20 > The chairs would like to express their appreciation for all the = responses received to our emails with reference to how the working group = wishes to move forward with respect to a solution for SRv6 compression. > =20 > The apparent inclination of the working group is to use = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = as the basis for its compression standardization work. That is = part of what this email attempts to confirm. > =20 > Because of the above the chairs would like to issue a 2-week WG call = for adoption ending October 15th for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = but with some clear guidelines as follows. By expressing = support for adoption of this document you are fully aware of and are = acknowledging that: > =20 > The SPRING working group is adopting a document that has multiple SRv6 = Endpoint behaviors. > The document is a =E2=80=9Cliving=E2=80=9D document; it may change as = it goes through review and analysis by the SPRING working group. > All open discussion points raised on our mailing list MUST be = addressed BEFORE said document is allowed to progress from the working = group to publication. A list of these discussion points will be = documented in the WG document and maintained by the document editor in = conjunction with the chairs. > If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open = issue be added to the document in the above-described open issues = section: > "Given that the working group has said that it wants to standardize = one data plane solution, and given that the document contains multiple = SRv6 EndPoint behaviors that some WG members have stated are multiple = data plane solutions, the working group will address whether this is = valid and coherent with its one data plane solution objective.". > =20 > Please consider the above guidelines as you decide on whether to = support or not this WG adoption. Please express clearly your reasoning = for support/non-support as well as any open discussion points you would = like addressed should the document be adopted into the working group. > =20 > Thanks! > =20 > Jim, Bruno & Joel > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --Apple-Mail=_D8966074-9F00-41A2-B508-6B94A63774C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

+1

I object to the adoption.

Tony


On Oct 1, 2021, at 1:43 PM, Andrew Alston = <Andrew.Alston=3D40liquidtelecom.com@dmarc.ietf.org> = wrote:

Just to add to = this,
 
I am one of the = people who clearly stated that I didn=E2=80=99t think a single solution = was the right answer here =E2=80=93 and I stated my reasoning clearly on = this list.  I still believe that =E2=80=93 however =E2=80=93 I = recognize that the foundation of the IETF is found in the bottom up = consensus approach =E2=80=93 and when the working group has demonstrated = such clear consensus =E2=80=93 to defy that =E2=80=93 is to defy what = makes the IETF the IETF.
 
So =E2=80=93 While I still believe in multiple = solutions =E2=80=93 irrespective of that =E2=80=93 I find this call = appalling =E2=80=93 because as much as I believe in multiple solutions = =E2=80=93 the working group consensus should be sacrosanct.
 
Andrew
 
 
From: Andrew Alston <Andrew.Alston@liquidtelecom.com>
Date: Friday, 1 October 2021 = at 23:21
To: James Guichard <james.n.guichard@futurewei.com>, SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
Subject: Re: WG Adoption call = for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/

Sorry =E2=80=93 = but =E2=80=93 I=E2=80=99m a little confused here.
 
Because the way I look at this =E2=80=93 the = working group clearly stated that they wished for a single behavior =E2=80= =93 and this =E2=80=93 does not deliver that =E2=80=93 it is two = separate behaviors.  As such =E2=80=93 I see this call for adoption = =E2=80=93 irrespective of the merits or lack thereof of the draft, as a = clear defiance of the stated will of the working group.
 
This is simply does not fit into the = definition of bottom up approach in my opinion =E2=80=93 and if this is = the way that the chairs wish to proceed =E2=80=93 then the only way to = do that and still fit within the bottom up approach is to first ask this = working group for its consensus to deviate from the single behacvior = approach that the working group agreed to.
 
As such =E2=80=93 I must  strongly and = unequivocally object to this call for adoption
 
Andrew
 

From: spring <spring-bounces@ietf.org> on behalf of James Guichard = <james.n.guichard@futurewei.com>
Date: Friday, 1 October 2021 = at 17:05
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
Subject: [spring] WG Adoption = call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/

Dear WG:
 
The chairs would like to express their = appreciation for all the responses received to our emails with reference = to how the working group wishes to move forward with respect to a = solution for SRv6 compression.
 
The apparent inclination of the working group = is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ as the basis for its = compression standardization work. That is part of what this email = attempts to confirm.
 
Because of the above the chairs would like to = issue a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ but with some clear = guidelines as follows. By expressing support for adoption of this = document you are fully aware of and are acknowledging that:
 
  1. The = SPRING working group is adopting a document that has multiple SRv6 = Endpoint behaviors.
  2. The = document is a =E2=80=9Cliving=E2=80=9D document; it may change as it = goes through review and analysis by the SPRING working group.
  3. All open discussion points = raised on our mailing list MUST be addressed BEFORE said document is = allowed to progress from the working group to publication. A list of = these discussion points will be documented in the WG document and = maintained by the document editor in conjunction with the chairs.
  4. If this document is adopted = by the working group, the chairs specify as part of the adoption call = that the following text describing an open issue be added to the = document in the above-described open issues section:
    • "Given that the working = group has said that it wants to standardize one data plane solution, and = given that the document contains multiple SRv6 EndPoint behaviors that = some WG members have stated are multiple data plane solutions, the = working group will address whether this is valid and coherent with its = one data plane solution objective.".
 
Please consider = the above guidelines as you decide on whether to support or not this WG = adoption. Please express clearly your reasoning for support/non-support = as well as any open discussion points you would like addressed should = the document be adopted into the working group.
 
Thanks!
 
Jim, Bruno & Joel
 
 
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

= --Apple-Mail=_D8966074-9F00-41A2-B508-6B94A63774C7-- From nobody Fri Oct 1 13:58:46 2021 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 D520A3A0A7E for ; Fri, 1 Oct 2021 13:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=aKnUkBoF; dkim=pass (1024-bit key) header.d=juniper.net header.b=bmw8xmLV 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 4STSXH4Untww for ; Fri, 1 Oct 2021 13:58:39 -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 C8B623A0A8C for ; Fri, 1 Oct 2021 13:58:38 -0700 (PDT) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 191KcdDX027386; Fri, 1 Oct 2021 13:58:37 -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=2pLXinN1GngvdYYD/FmhSW0lUwIhj5xiVlf5pLSwWUQ=; b=aKnUkBoFtVnXNZJzrliJiyBFGRUggzAnZIx2M2P4RrBghJ0+ro64lAaCTamCEFuSaGxs dwP3XpgDR/PG/vRsypa9HTGq6xM07Ul1dpfO7uJt8SGdb1lWopC2WkwLtq2168P9o9ay 4EB1olww/o34oxljXvh9ZcLt6a44hMAAElGba2Wj4BhTffcqS9yJWzLOIMUSD75zKiMW ViRJjWG9FFHSfYN2THYIkkYC8IjltaMfzkcdQrCA+Bt70ty8tjCDJRdaheOCrsqbj0LP YDsp5kJJjo7zPgYSmOs0gxer1Pb5hdGGDKp97AtwayvxxZMkxVJpXt8mGH8vSmRJyyt5 tg== Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2049.outbound.protection.outlook.com [104.47.66.49]) by mx0b-00273201.pphosted.com with ESMTP id 3be05rsb9h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 01 Oct 2021 13:58:37 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Uav5zAYOryo7ero1LcQ+Vr7rvLc0PUZtx1kafcKx/NireYOkedSlVv/x7m8yICH4mn2lDJb6ZGdwzCkMX+dSC6rD/6+UroMsNGk5oM03qQwJr5hrtfMHCfdL8groBE2Pg24rwuvM1y9UIZ4hy4bl0vtm+Vt0G5kaxJdZgS8oBRq7aysGrPF2RkTKdqbpEQf/5TjU5GL06fvclqGTF94LcP1YdqLx2fxoH55ZHQZVWYyGKBgUI3pEbBSRloXBIRRBsRkEi7DkNHJoIYK1PoZFGEs0D0weIqUfc5J1qQNvCOxaAxU2Uc0yo9WU31XJerRGYkv3tlBn2u0FeuPYTGYg2g== 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=2pLXinN1GngvdYYD/FmhSW0lUwIhj5xiVlf5pLSwWUQ=; b=IzJDyr1hB0vfhbGz9oHFYot0u1fJjJY7mIg3kwCPaTDukUKifrhROyrJk+boq5DN/umcfFH58YYXQ8hxgK+R2bbtNvWBPzIhE4uXu8Wy8rRO8FmK9DwplNYi6hHxd+W6zSZuwl34nZpDijAMfwRn3xQl3l/HBDYfx0ctI1t3PH+ND9W0frxiCsdMxuAxrc4zr7yLq7H9inMET4Soou6Spt6SQa89Gev528TQDETBnfP5KklMkObEzQjljKfJgfPkLS8GE+gvDypHDVVdRA0A6MJ0sMNOODix+8M3B/ZYl8qquqBConKJinX6tbe6MHESYesm4coMMS1MdoTtEnrE3w== 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=2pLXinN1GngvdYYD/FmhSW0lUwIhj5xiVlf5pLSwWUQ=; b=bmw8xmLVGnC8FFjbSVQgNS55rZCIyPKaiqg1HfYokn7nyKjlfR7AMBWr7D6ci0fvwxSXo4Cxbte9iWmU4v1SYNUSMSTA2Xp5accYpOGVCBlv2e4L9ilKd8MOpINqkgeL+BkNUZ3sEBiIadbDyCYT/unKRdi5PW4+T8oBXtRxTPM= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by BL0PR05MB5076.namprd05.prod.outlook.com (2603:10b6:208:83::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.7; Fri, 1 Oct 2021 20:58:34 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4587.009; Fri, 1 Oct 2021 20:58:34 +0000 From: Ron Bonica To: Robert Raszuk CC: SPRING WG Thread-Topic: [spring] CSID Question Thread-Index: Ade2+c1KozTuOJAoRFyi9icelIkpNwACYe+AAAAh62A= Date: Fri, 1 Oct 2021 20:58:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-01T20:58:33Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=440c7f07-3a61-4992-ac94-8853cfe6bb47; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1ed4e9bb-6980-4e24-8b97-08d9851e3bc1 x-ms-traffictypediagnostic: BL0PR05MB5076: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: E0EXg6mRq0MVDJ2mGDq1ulLjqEd+uNxrdekJFvcK1XuwWfS69qHn4SCbUEnJ39kTUXwxn2/G8ENI7+S5cJTbUe1nZ7JqoMC6SygsVN4fEtWDmOoXF52lXUa6/XMU2i0yJFgLYETGD3cnwDK8dwDE2lNYS+yYFQ5LFFIOX8ux1prsOni0cH1Ml/duibpCyM8eNb7zHEpaRcEbR6qTxPuKBWZ0APJv/ufNUKQWF8fD6h5qnnx3cL4DvUTeZWPyAjmvr+3ugBRPLDA8vE2wqTjLrLGKzvOyfIlyDRtnlhfGKPx5kdBf5db4MDSv+ndGbBGF4Q/VV3fWdVICXEd68HgrD84TO8yhliHluSMphPhssorgAV8CnkJoFpZ7kcJLN9213CSxwX83xllHET0oapZp2+hyDPkLW3dRWfuE1N3BgOUnDJWTp5Xj21gOwdHOGxIOdNeqcghvVIHE1BcVnqr6E/RBZg2T1p/EV++YQQzEfR9zt01h27c34Xtyu+FUGXeEh9ceTJXo9w9SglxMrB/3wicNXwMAam/1NhRnK+5q7JZ+kVkX4jX3dK/zzbXpq2lfTn+dJLnYaBgxTiazBgjM5j2AIa40u1+nVxyZFkPeLzl6msVEV7Ou9dUYSJxg/bfZXxQTlyi+gFc0izsYZIQz4CveXfsP55BEjpQLbYyKDv9O3o6zemfpIvYw9qRieC/cKM8GlA/+fktdy/lJhohcQPluMhdehzUDWWIOL6GhHRMKic7sv6V7fvthEiQpyrUpvSYq529iwL/Wi1pbPWsFmKkYAA8U4B8m6+oYS+uNnM4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66946007)(8676002)(33656002)(66476007)(5660300002)(76116006)(316002)(166002)(966005)(6916009)(66556008)(38070700005)(508600001)(52536014)(26005)(122000001)(55016002)(4326008)(86362001)(7696005)(9686003)(53546011)(8936002)(186003)(38100700002)(6506007)(66446008)(71200400001)(64756008)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Y1pLY2tyb0NGWWRERFlLV2EyZ3QzNXhZOEUzUFdxd00za0ExcGRSV0QrdUVG?= =?utf-8?B?cXRKcGluQit2a3kxVU9Wdm1NOEl6YmpwbEpyQ2hPR1ZoUkxMRUZKeldhNWhn?= =?utf-8?B?eHZQZGQ0WFl4THdxak1rSVRUeEdFaDltd21ZRUNuVTQ5WDJHNEk2aGQxL2Vp?= =?utf-8?B?MC9nWnU5K3YzdDZiTjR5bXphUVZDMlkvdXVFWmVYN1ZlcVZhbFZlWWVKblA4?= =?utf-8?B?aGUxa3loYTlhU3FtVGtlU2RzM3NYRzI2QWdjN1gxb0J4SUwwTkxKWnhZQ3VS?= =?utf-8?B?RC8vcit0emo4ZStUTGNMMSt0VTJBQmo4b3JVQ3c3Rk8wcVZlOVRoaE1zMEZN?= =?utf-8?B?K1VLRVNrbWRGcFFXL3p3Mm0wR2lKSkRVcEZWRk5WWGhWSUJEeHBpTDAzdDR5?= =?utf-8?B?MGF4THVBdlVZYXdFMkY0bHd4aXJrZWdNaHRvdlFaaFRCN21yMzBuU0VRdmlQ?= =?utf-8?B?Qzg0dnphSXAxalRYTVdubkN6K1ZNNEl3bHA4bzVnUkZhR1RJK3J1L0VFd0Rp?= =?utf-8?B?alZKWHdJOHhEeVBLMFQ3U0ZWYXcrWlFXa0VxaGdFMG9ENkdpZklyeUptMTJa?= =?utf-8?B?Z09RRjBKanhUYjN0TjVLSEV1M2g4QTFFTG1haFk4aUpoODNYRVJJYmlMVXdB?= =?utf-8?B?eHQ4ZWpkdEpFRXRrZnZyb044K1FFTlBXMXlYRzFXbDNOMmpqb2RaeWdXNXJF?= =?utf-8?B?VCtFTTNYMG9YTTNzUDRpMWQ2c1NMZVFWeVpNcXo5b3ZkbnZYRVBMYWpCaFo4?= =?utf-8?B?b2pVVjBTeTBnK2RMM3pXY3FLMVpvU09nOXltNjNFLzVtQVJ5a0VvYWkxRXRk?= =?utf-8?B?L3kxSTJBMUl0Sk1NdkJXOFRMdUlmUDA1VG1TbUR0bDJUWEV4cHVZeGVCZy9V?= =?utf-8?B?eXErdnU1MStENHVSYVo2RXlmaG9qVk1hdnNheGpUeVZ0c21IZnU0NEdTdElD?= =?utf-8?B?eGhoa29ieXFMamNQQ0syY2hlTjhIU2Q5QXJabUt1UGwxNVFNT1lUSDZQOU16?= =?utf-8?B?b1JDakdVOU1sNSs4M3hvaHJLdEQxeFlBWjlzSkQrelB2SmtwN2hYSGV5RE9o?= =?utf-8?B?OTB2cmRSYVh3Q2d4eG0rYnVNMXAvRi9HUU1Ybk50eFBpMEtEQ3F3dmtEamN6?= =?utf-8?B?QzQ3VFcrbVFvWnU3b1dURFQyWkpIMEhZbG5rZmRGYWljNWRETHpZVm5FdnZN?= =?utf-8?B?VVJhYnFWQ0JKV2trdzdqdC9tb2wxVnUrMFpNRE9sWDNiWU9VekdhOHlVWUZH?= =?utf-8?B?VnNIZnVIMDlNb1pjUmRxYUJ3UytJODNXNFBValEvNUYvMUR6NnUrMVcyQ2Ry?= =?utf-8?B?Sk9hTlF0NVZTdkFBRURPNk4wMWZEcTl5Z0kxT1kxRU0weVA3MEtpVE4zVkhR?= =?utf-8?B?VTNrRm1ZRjdiTzU0aFpKNisyTW9NSW12UFZMRGc0dkY4RUtxVnJpaXlQK0wr?= =?utf-8?B?eXl5M1VRckJ6aWdveENsNTlpUUdGT2JoZEZQUmM5TE80SkNicnVEZ0lWNE1Q?= =?utf-8?B?OTZIT0pxaDJGOU45N2NvU2c0czJ2OEJEbjlabGN0YlRSUTlML2NWaEhYVFMv?= =?utf-8?B?bVhJTkk0V052SElTUEZJRStQNi94MmFJV3ZSWWtmN240NStNTDB3YldzaWl0?= =?utf-8?B?UUJnbDBRNGJFb0NPU2IxdG41aytzL0NvNlgxUW9SaDI3Q0pmMmk3ZEFCZlJp?= =?utf-8?B?OWV3NFgwUktXbDZtcWdwNVY0aXhWQk1SRzFLWDJBTXdVSUdBMjN0bllRQ1do?= =?utf-8?Q?f6znlcpy7lsZj4Gly2fDv3aqUVd9byGpFPr3pdz?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR05MB531627B8F2F345E073EDF5D4AEAB9BL0PR05MB5316namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1ed4e9bb-6980-4e24-8b97-08d9851e3bc1 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2021 20:58:34.6069 (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: mHSVArUEOX/sd3P3zOslS5N+Wq/n+GCs+rjxFq4QrEQY4gjjHvqAA2JQE01oNgHkzBbT4TEsJTyMXVO+dyDq5g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5076 X-Proofpoint-ORIG-GUID: aOurRMxM8qqiSVn3g6njgz1A5aRQyZhk X-Proofpoint-GUID: aOurRMxM8qqiSVn3g6njgz1A5aRQyZhk X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-01_05,2021-10-01_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1015 spamscore=0 priorityscore=1501 lowpriorityscore=0 mlxlogscore=999 impostorscore=0 phishscore=0 adultscore=0 bulkscore=0 mlxscore=0 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110010146 Archived-At: Subject: Re: [spring] CSID Question 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, 01 Oct 2021 20:58:45 -0000 --_000_BL0PR05MB531627B8F2F345E073EDF5D4AEAB9BL0PR05MB5316namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9iZXJ0LA0KDQpJIGRvIHJlbWVtYmVyIHRoYXQgcXVvdGUuIEFuZCB0aGF0IGlzIGV4YWN0bHkg d2h5IEkgYXNrIHRoZSBxdWVzdGlvbiENCg0KSWYgTkVYVC1DLVNJRCBhbmQgUkVQTEFDRS1DLVNJ RCBhcmUgaW5jb21wYXRpYmxlIHdpdGhpbiBhIGRvbWFpbjoNCg0KDQogICogICBDYW4gd2Ugc2F5 IHRoYXQgdGhleSBhcmUgYSBzaW5nbGUgYmVoYXZpb3IgPw0KICAqICAgQ2FuIHdlIGp1c3RpZnkg Ym90aCBiZWNhdXNlIGVhY2ggaXMgb3B0aW1pemVkIGZvciBhIGRpZmZlcmVudCBraW5kIG9mIG5l dHdvcms/DQogICogICBDYW4gd2UganVzdGlmeSBhbm90aGVyIGJlaGF2aW9yIGVpdGhlciBiZWNh dXNlIGl0IGlzIG9wdGltaXplZCBmb3IgeWV0IGFub3RoZXIgdHlwZSBvZiBuZXR3b3JrIG9yIGJl Y2F1c2UgaXQgZG9lcyByZWxhdGl2ZWx5IHdlbGwgaW4gYWxsIG5ldHdvcmsgdHlwZXM/DQoNCkhv d2V2ZXIsIGlmIHRoaXMgaXMganVzdCBhbiDigJxlYXNlIG9mIG9wZXJhdGlvbuKAnSB0aGluZywg YXMgc3RhdGVkIGluIHRoZSBkcmFmdCwgdGhlIGF1dGhvcnMgYXJlIG9ibGlnZWQgdG8gYW5zd2Vy IG15IHF1ZXN0aW9uLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg Um9uDQoNClAuUy4gUmVzdCBhc3N1cmVkIHRoYXQgSSBoYXZlIHJlYWQgdGhlIGRyYWZ0LiBIb3dl dmVyLCB5b3VyIGNvbmNlcm4gaXMgZ3JlYXRseSBhcHByZWNpYXRlZCDwn5iJDQoNCg0KDQoNCkp1 bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkNCkZyb206IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6 dWsubmV0Pg0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDEsIDIwMjEgNDozMiBQTQ0KVG86IFJvbiBC b25pY2EgPHJib25pY2FAanVuaXBlci5uZXQ+DQpDYzogU1BSSU5HIFdHIDxzcHJpbmdAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gQ1NJRCBRdWVzdGlvbg0KDQpbRXh0ZXJuYWwgRW1h aWwuIEJlIGNhdXRpb3VzIG9mIGNvbnRlbnRdDQoNCkhpIFJvbiwNCg0KSGF2ZSB5b3UgcmVhZCB0 aGlzIGRyYWZ0ID8NCg0KUXVvdGUgZnJvbSBpdDoNCg0KDQogICBJdCBpcyByZWNvbW1lbmRlZCBm b3IgZWFzZSBvZiBvcGVyYXRpb24gdGhhdCBhIHNpbmdsZSBjb21wcmVzc2VkDQoNCiAgIGVuY29k aW5nIGZsYXZvciBiZSB1c2VkIGluIGEgZ2l2ZW4gU1J2NiBkb21haW4uICBIb3dldmVyLCBpbiBh IG11bHRpLQ0KDQogICBkb21haW4gZGVwbG95bWVudCwgZGlmZmVyZW50IGZsYXZvcnMgY2FuIGJl IHVzZWQgaW4gZGlmZmVyZW50DQoNCiAgIGRvbWFpbnMuDQoNCk9uIEZyaSwgT2N0IDEsIDIwMjEg YXQgOTozMyBQTSBSb24gQm9uaWNhIDxyYm9uaWNhPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5v cmc8bWFpbHRvOjQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCkNTSUQgQXV0 aG9ycywNCg0KQXNzdW1lIHRoYXQgYW4gU1IgcGF0aCBjb250YWlucyBzZWdtZW50cyAxIHRocm91 Z2ggOC4gU2VnbWVudHMgMSwgMywgNSwgYW5kIDcgYXJlIEVORCBTSURzIHRoYXQgdXNlIE5leHQt Qy1TSUQgKGkuZS4sIHVTSUQpLiBTZWdtZW50cyAyLCA0LCBhbmQgNiBhcmUgRU5EIFNJRHMgdGhh dCB1c2UgUmVwbGFjZS1DLVNJRC4gU2VnbWVudCA4IGlzIGFuZCBFTkQuRFg0IFNJRC4NCg0KUGxl YXNlIHByb3ZpZGUgYW4gZXhhbXBsZSB0aGF0IHNob3dzIHVzOg0KDQoNCiAgKiAgIFdoYXQgdGhl IFNSSCBsb29rcyBsaWtlIGFzIGl0IGFycml2ZXMgYXQgdGhlIGZpcnN0IHNlZ21lbnQgZW5kcG9p bnQNCiAgKiAgIFdoYXQgdGhlIElQdjYgRGVzdGluYXRpb24gQWRkcmVzcyBsb29rcyBsaWtlIGF0 IGVhY2ggc2VnbWVudCBlbmRwb2ludCwgaW5jbHVkaW5nIGluZm9ybWF0aW9uIHJlcXVpcmVkIHRv IHBhcnNlIHRoZSBEZXN0aW5hdGlvbiBBZGRyZXNzDQoNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb24NCg0KDQoNCkp1bmlwZXIgQnVz aW5lc3MgVXNlIE9ubHkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmlu Z0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5n PGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc3ByaW5nX187ISFORXQ2eU1hTy1nayFVTF9Mc1RFV3V5YnRld2NJSFgyRndycXR3 UzNHOTdraTN0ekhUOHBHeUdjeDJoUFdZWmZyaVNtZUc3NXV3UDdsJD4NCg== --_000_BL0PR05MB531627B8F2F345E073EDF5D4AEAB9BL0PR05MB5316namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSBF bW9qaSI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkxhdG87DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQg MyAyIDM7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpNb25hY287fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1h dHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3Jh cGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJn aW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1h cmdpbi1sZWZ0Oi41aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1u YW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ bXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xh czt9DQpwLmdtYWlsLW0tMzU2NTc4MDMxMTM1NjcxNzkyNG1zb2xpc3RwYXJhZ3JhcGgsIGxpLmdt YWlsLW0tMzU2NTc4MDMxMTM1NjcxNzkyNG1zb2xpc3RwYXJhZ3JhcGgsIGRpdi5nbWFpbC1tLTM1 NjU3ODAzMTEzNTY3MTc5MjRtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOmdtYWls LW1fLTM1NjU3ODAzMTEzNTY3MTc5MjRtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQpwLm1zaXBmb290ZXIzMGIzZDUzOCwgbGkubXNpcGZvb3RlcjMw YjNkNTM4LCBkaXYubXNpcGZvb3RlcjMwYjNkNTM4DQoJe21zby1zdHlsZS1uYW1lOm1zaXBmb290 ZXIzMGIzZDUzODsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlk OjUwMjkzNDUzNTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTIwOTkzNzU5NDQ7fQ0KQGxpc3Qg bDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4w aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo1NjMyMjAyMTk7DQoJbXNvLWxpc3QtdHlwZTpoeWJy aWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjk1NTgyOTU4MCAtNzQ3NzE2MjM2IDY3Njk4Njkx IDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3 Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MTY7DQoJbXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglt c28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6 bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXci O30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjg1Mzc2MjIzNTsNCgltc28t bGlzdC10ZW1wbGF0ZS1pZHM6MTIzNTkwNDM3ODt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0 LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzDQoJe21zby1s aXN0LWlkOjg2NjkxNzQwNzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6NjQwMDI3Njk2O30NCkBs aXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQi PlJvYmVydCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPkkgZG8g cmVtZW1iZXIgdGhhdCBxdW90ZS4gQW5kIHRoYXQgaXMgZXhhY3RseSB3aHkgSSBhc2sgdGhlIHF1 ZXN0aW9uITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+SWYgTkVY VC1DLVNJRCBhbmQgUkVQTEFDRS1DLVNJRCBhcmUgaW5jb21wYXRpYmxlIHdpdGhpbiBhIGRvbWFp bjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjE0LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHVsIHN0 eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij5DYW4gd2Ugc2F5IHRoYXQgdGhleSBhcmUgYSBz aW5nbGUgYmVoYXZpb3IgPzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8z Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+Q2FuIHdlIGp1c3RpZnkgYm90aCBiZWNh dXNlIGVhY2ggaXMgb3B0aW1pemVkIGZvciBhIGRpZmZlcmVudCBraW5kIG9mIG5ldHdvcms/PG86 cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTQuMHB0Ij5DYW4gd2UganVzdGlmeSBhbm90aGVyIGJlaGF2aW9yIGVpdGhlciBiZWNh dXNlIGl0IGlzIG9wdGltaXplZCBmb3IgeWV0IGFub3RoZXIgdHlwZSBvZiBuZXR3b3JrIG9yIGJl Y2F1c2UgaXQgZG9lcyByZWxhdGl2ZWx5IHdlbGwgaW4gYWxsIG5ldHdvcmsgdHlwZXM/PG86cD48 L286cD48L3NwYW4+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxNC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij5Ib3dldmVyLCBpZiB0 aGlzIGlzIGp1c3QgYW4g4oCcZWFzZSBvZiBvcGVyYXRpb27igJ0gdGhpbmcsIGFzIHN0YXRlZCBp biB0aGUgZHJhZnQsIHRoZSBhdXRob3JzIGFyZSBvYmxpZ2VkIHRvIGFuc3dlciBteSBxdWVzdGlv bi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjE0LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtSb248 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjE0LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPlAuUy4gUmVzdCBhc3N1 cmVkIHRoYXQgSSBoYXZlIHJlYWQgdGhlIGRyYWZ0LiBIb3dldmVyLCB5b3VyIGNvbmNlcm4gaXMg Z3JlYXRseSBhcHByZWNpYXRlZA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LHNhbnMtc2VyaWYiPiYjMTI4 NTIxOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJt c2lwZm9vdGVyMzBiM2Q1MzgiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW46MGluO3RleHQt YWxpZ246Y2VudGVyIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6YmxhY2si Pkp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8 L2I+IFJvYmVydCBSYXN6dWsgJmx0O3JvYmVydEByYXN6dWsubmV0Jmd0OyA8YnI+DQo8Yj5TZW50 OjwvYj4gRnJpZGF5LCBPY3RvYmVyIDEsIDIwMjEgNDozMiBQTTxicj4NCjxiPlRvOjwvYj4gUm9u IEJvbmljYSAmbHQ7cmJvbmljYUBqdW5pcGVyLm5ldCZndDs8YnI+DQo8Yj5DYzo8L2I+IFNQUklO RyBXRyAmbHQ7c3ByaW5nQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Nw cmluZ10gQ1NJRCBRdWVzdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEyLjBwdDtiYWNrZ3JvdW5kOiNGRkVCOUMiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0xhdG8mcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+W0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250 ZW50XTxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkg Um9uLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhhdmUg eW91IHJlYWQgdGhpcyZuYnNwO2RyYWZ0ID8mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UXVvdGUgZnJvbSBpdDombmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzo4LjBwdCA4LjBwdCA4LjBwdCA4LjBwdCI+DQo8cHJlIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDo4LjI1cHQ7bWFyZ2luLWJvdHRvbTo3 LjlwdDttYXJnaW4tbGVmdDo4LjI1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJl YWstYWxsO2JveC1zaXppbmc6Ym9yZGVyLWJveDtib3JkZXItcmFkaXVzOjRweDtvdmVyZmxvdzph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpNb25hY287Y29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyBJdCBpcyByZWNvbW1lbmRlZCBmb3IgZWFzZSBvZiBvcGVy YXRpb24gdGhhdCBhIHNpbmdsZSBjb21wcmVzc2VkPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDo4LjI1cHQ7bWFy Z2luLWJvdHRvbTo3LjlwdDttYXJnaW4tbGVmdDo4LjI1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dv cmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTpNb25hY287Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBlbmNvZGluZyBmbGF2b3IgYmUg dXNlZCBpbiBhIGdpdmVuIFNSdjYgZG9tYWluLiZuYnNwOyBIb3dldmVyLCBpbiBhIG11bHRpLTxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBp bjttYXJnaW4tcmlnaHQ6OC4yNXB0O21hcmdpbi1ib3R0b206Ny45cHQ7bWFyZ2luLWxlZnQ6OC4y NXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6TW9uYWNvO2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgZG9tYWluIGRlcGxveW1lbnQsIGRpZmZlcmVudCBmbGF2b3JzIGNhbiBiZSB1c2VkIGlu IGRpZmZlcmVudDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6OC4yNXB0O21hcmdpbi1ib3R0b206Ny45cHQ7bWFy Z2luLWxlZnQ6OC4yNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6TW9uYWNvO2NvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsgZG9tYWlucy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIE9jdCAxLCAy MDIxIGF0IDk6MzMgUE0gUm9uIEJvbmljYSAmbHQ7cmJvbmljYT08YSBocmVmPSJtYWlsdG86NDBq dW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZyI+NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZzwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+Q1NJRCBBdXRob3JzLDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxNC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPkFzc3VtZSB0aGF0 IGFuIFNSIHBhdGggY29udGFpbnMgc2VnbWVudHMgMSB0aHJvdWdoIDguIFNlZ21lbnRzIDEsIDMs IDUsIGFuZCA3IGFyZSBFTkQgU0lEcyB0aGF0IHVzZSBOZXh0LUMtU0lEIChpLmUuLCB1U0lEKS4g U2VnbWVudHMgMiwgNCwgYW5kIDYNCiBhcmUgRU5EIFNJRHMgdGhhdCB1c2UgUmVwbGFjZS1DLVNJ RC4gU2VnbWVudCA4IGlzIGFuZCBFTkQuRFg0IFNJRC48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTQuMHB0Ij5QbGVhc2UgcHJvdmlkZSBhbiBleGFtcGxlIHRoYXQgc2hv d3MgdXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJnbWFpbC1tLTM1NjU3ODAzMTEzNTY3MTc5MjRt c29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzYiPg0KPHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPldoYXQgdGhlIFNSSCBsb29rcyBsaWtlIGFzIGl0IGFy cml2ZXMgYXQgdGhlIGZpcnN0IHNlZ21lbnQgZW5kcG9pbnQ8L3NwYW4+PG86cD48L286cD48L2xp PjxsaSBjbGFzcz0iZ21haWwtbS0zNTY1NzgwMzExMzU2NzE3OTI0bXNvbGlzdHBhcmFncmFwaCIg c3R5bGU9Im1zby1saXN0OmwyIGxldmVsMSBsZm82Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTQuMHB0Ij5XaGF0IHRoZSBJUHY2IERlc3RpbmF0aW9uIEFkZHJlc3MgbG9va3MgbGlrZSBhdCBl YWNoIHNlZ21lbnQgZW5kcG9pbnQsIGluY2x1ZGluZyBpbmZvcm1hdGlvbiByZXF1aXJlZCB0byBw YXJzZSB0aGUgRGVzdGluYXRpb24gQWRkcmVzczwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtSb248L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW46MGluO3RleHQtYWxpZ246 Y2VudGVyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOmJsYWNrIj5KdW5pcGVy IEJ1c2luZXNzIFVzZSBPbmx5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPGJyPg0Kc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmdfXzshIU5FdDZ5TWFPLWdrIVVMX0xzVEVXdXlidGV3 Y0lIWDJGd3JxdHdTM0c5N2tpM3R6SFQ4cEd5R2N4MmhQV1laZnJpU21lRzc1dXdQN2wkIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8 L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BL0PR05MB531627B8F2F345E073EDF5D4AEAB9BL0PR05MB5316namp_-- From nobody Fri Oct 1 14:07:47 2021 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 725503A0B12 for ; Fri, 1 Oct 2021 14:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 cZPDapGRikOE for ; Fri, 1 Oct 2021 14:07:41 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 A35053A0AFE for ; Fri, 1 Oct 2021 14:07:41 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id o124so12879279vsc.6 for ; Fri, 01 Oct 2021 14:07:41 -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=Y1ufOk2btTdQLUkFu/e4heoedGgTOrUM9zWTDeWGomI=; b=ebt5KHgMq5BnNUSSbUOTUt6rDiEWjSvrGlqE0ZnJjX2V2CbCwbMxkW+DYb62UVKU0A VWZfg9P4lzdTLLYs3XVtrCzTk5GTDPuNKERmpZZEyk2pgb/smAky+6PRpA35iFVnazC6 AbbECo5tLkc2mJzaYCYFK6oFeLJEN0fGJtc8GcivUv0g0gNvLlw0/ojFOlwRmHAMojbg ut3KcfyRIPSRO+k48l7G16Ab7vw27BvH2XnOAmlPZ5YokyQazP8oLE7NlehS0Uq+IFJX TDUUyNfZkyw+si3H9b0yEDToBZWlkn0hZTHRcBeOFS76MI7DWViEALs9LuYeOe6bFJ0d C3xA== 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=Y1ufOk2btTdQLUkFu/e4heoedGgTOrUM9zWTDeWGomI=; b=u8T4fXSJrjCKUXDiS+zSwMehmDq42SiVpO9nRXtDPi9IPHPX6r2XKuEQdEwo+BG20f 8Ki1rOao5on2AhJmW1ac8iZ1X+JSSKCTjDXt2tqRcrQEOjbamHu6TaX2rTv0zQ1a76za OnnxOx/zGZPm5uhtkH2G2Hv/ZbHGDaoU7cB6QgrM2qXdxFkPWYfM08laRurX4CZlx7DK H7ZT6kz0qJyRHW6MDBn4tzDX0y57UygMgrVQRoQz50yXsjHa322oBa+T/4XK60OKabeT RKcE2lbeA0g+9MfNDIKHhvz8h24N6hBlMblu53jWQnSvhntGXLivcKWf4tfKXx3wexfd whEA== X-Gm-Message-State: AOAM530sRdMdzuwcC4NuJ8QgXUD6cxihrj8aJRlL0vJdPEfLN5ss7Y6x EGD9rlLdHUKzgSGujuhF25kZtJ0zIesZnqLv3tkeAHDT1hiSig== X-Google-Smtp-Source: ABdhPJy7eGsrWEFEMBvDJOjZ7jf3BZr5CWDZ00lZYJn7ktWq3cD2XKE92NXXHcBYHm7K2GOfgLiy0/xiayQQMMQA02Q= X-Received: by 2002:a67:cf41:: with SMTP id f1mr6606289vsm.1.1633122460388; Fri, 01 Oct 2021 14:07:40 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Fri, 1 Oct 2021 23:08:28 +0200 Message-ID: To: Ron Bonica Cc: SPRING WG Content-Type: multipart/alternative; boundary="0000000000002061cf05cd50f4ca" Archived-At: Subject: Re: [spring] CSID Question 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, 01 Oct 2021 21:07:47 -0000 --0000000000002061cf05cd50f4ca Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Ron, - Can we say that they are a single behavior ? No. And neither RFC8986 defines a single behavior or single flavor. Yet the bounds are clearly set what is the SRv6 data plane. For some strange reason I am observing here an attempt to squeeze different data plane into the room which is not compliant to [RFC8402], [RFC8754] and [RFC8986]. Do you think anyone will be so naive to accept it ? Now I am going to rest assured and enjoy the rest of this show. Best, Robert On Fri, Oct 1, 2021 at 10:58 PM Ron Bonica wrote: > Robert, > > > > I do remember that quote. And that is exactly why I ask the question! > > > > If NEXT-C-SID and REPLACE-C-SID are incompatible within a domain: > > > > - Can we say that they are a single behavior ? > - Can we justify both because each is optimized for a different kind > of network? > - Can we justify another behavior either because it is optimized for > yet another type of network or because it does relatively well in all > network types? > > > > However, if this is just an =E2=80=9Cease of operation=E2=80=9D thing, as= stated in the > draft, the authors are obliged to answer my question. > > > > > Ron > > > > P.S. Rest assured that I have read the draft. However, your concern is > greatly appreciated =F0=9F=98=89 > > > > > > > > Juniper Business Use Only > > *From:* Robert Raszuk > *Sent:* Friday, October 1, 2021 4:32 PM > *To:* Ron Bonica > *Cc:* SPRING WG > *Subject:* Re: [spring] CSID Question > > > > *[External Email. Be cautious of content]* > > > > Hi Ron, > > > > Have you read this draft ? > > > > Quote from it: > > > > It is recommended for ease of operation that a single compressed > > encoding flavor be used in a given SRv6 domain. However, in a multi- > > domain deployment, different flavors can be used in different > > domains. > > > > On Fri, Oct 1, 2021 at 9:33 PM Ron Bonica 40juniper.net@dmarc.ietf.org> wrote: > > CSID Authors, > > > > Assume that an SR path contains segments 1 through 8. Segments 1, 3, 5, > and 7 are END SIDs that use Next-C-SID (i.e., uSID). Segments 2, 4, and 6 > are END SIDs that use Replace-C-SID. Segment 8 is and END.DX4 SID. > > > > Please provide an example that shows us: > > > > - What the SRH looks like as it arrives at the first segment endpoint > - What the IPv6 Destination Address looks like at each segment > endpoint, including information required to parse the Destination Addr= ess > > > > > Ro= n > > > > > > Juniper Business Use Only > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > --0000000000002061cf05cd50f4ca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ron,

  • Can= we say that they are a single behavior ?

No. And neither RFC8986 defines a single behavior or single flavor.= Yet the bounds are clearly=C2=A0set what is the SRv6 data plane.=C2=A0

For some strange=C2=A0reason I am observi= ng here an attempt to squeeze different data plane into the room which is n= ot compliant=C2=A0to [RFC8402], [RFC8754] and [RFC8986]. Do you think anyon= e will be so naive to accept it ?=C2=A0

Now I = am going=C2=A0to rest assured and enjoy the=C2=A0rest of this show.=C2=A0

Best,
Robert

On Fri, = Oct 1, 2021 at 10:58 PM Ron Bonica <rbonica@juniper.net> wrote:

Robert,=

=C2=A0<= /span>

I do remember that qu= ote. And that is exactly why I ask the question!

=C2=A0<= /span>

If NEXT-C-SID and REP= LACE-C-SID are incompatible within a domain:

=C2=A0<= /span>

  • Can we say tha= t they are a single behavior ?
  • Can we justify both because each = is optimized for a different kind of network?
  • Can we justify ano= ther behavior either because it is optimized for yet another type of networ= k or because it does relatively well in all network types?

=C2=A0<= /span>

However, if this is j= ust an =E2=80=9Cease of operation=E2=80=9D thing, as stated in the draft, t= he authors are obliged to answer my question.

=C2=A0<= /span>

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Ron

=C2=A0<= /span>

P.S. Rest assured tha= t I have read the draft. However, your concern is greatly appreciated =F0=9F=98=89

=C2=A0<= /span>

=C2=A0<= /span>

=C2=A0

Juniper Business Use Only<= u>

From: Robert Raszuk <robert@raszuk.net>
Sent: Friday, October 1, 2021 4:32 PM
To: Ron Bonica <rbonica@juniper.net>
Cc: SPRING WG <spring@ietf.org>
Subject: Re: [spring] CSID Question

=C2=A0

[External Email. Be cautious of content]

=C2=A0

Hi Ron,

=C2=A0

Have you read this=C2=A0draft ?=C2=A0<= /p>

=C2=A0

Quote from it:=C2=A0

=C2=A0

=C2=A0=C2=A0 It is recommended for ease of operation that a=
 single compressed
=C2=A0=C2=A0 encoding flavor be used i=
n a given SRv6 domain.=C2=A0 However, in a multi-

=C2=A0=C2=A0 domain deployment, differ=
ent flavors can be used in different


=C2=A0=C2=A0 domains.

=C2=A0

On Fri, Oct 1, 2021 at 9:33 PM Ron Bonica <rbonic= a=3D40jun= iper.net@dmarc.ietf.org> wrote:

CSID Authors,<= u>

=C2=A0<= u>

Assume that an SR pat= h contains segments 1 through 8. Segments 1, 3, 5, and 7 are END SIDs that = use Next-C-SID (i.e., uSID). Segments 2, 4, and 6 are END SIDs that use Replace-C-SID. Segment 8 is and END.DX4 SID.<= u>

=C2=A0<= u>

Please provide an exa= mple that shows us:

=C2=A0<= u>

  • What the SRH looks like as it arrives at the= first segment endpoint
  • What the IPv6 Destination Address looks like= at each segment endpoint, including information required to parse the Dest= ination Address

=C2=A0<= u>

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Ron

=C2=A0<= u>

=C2=A0

Juniper Business Use Only

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

--0000000000002061cf05cd50f4ca-- From nobody Fri Oct 1 16:26:20 2021 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 92A5F3A0FBA; Fri, 1 Oct 2021 16:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8zvpff9mGFoo; Fri, 1 Oct 2021 16:26:13 -0700 (PDT) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 F3DBC3A0DE4; Fri, 1 Oct 2021 16:26:12 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id 145so9228238pfz.11; Fri, 01 Oct 2021 16:26:12 -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=cpkV6lwos6AmhWExNwBEiyWeN/omBOvoDNq6qQy3Qnc=; b=osBM+ddp0gkhqYTNuYUY0ZAa8wsgGwI7b0n1btxYeAb/YvW7c+tUM6qzxQTW+vA1v0 uhBv89LtsqX2oLLVnga7l35kogRKal2Am5F5fCxkn4jsvZiA8sTVXrMi067DtekEbxrg Vc+DEgP5tqob1Y5cxlhdIW3W//nxYjSt1c5XinRl5RbUHG/WwX6U/lJ0gWVKxJZbiwdB GDzUFT/I+CVvMLDlv6j7+Y662BfR6tHLgGhfvNqB5QpeGWbXWO4WS6Jqq4IUdzdDS82P u1eIFH9/KhFIlpcw0rQFlDlX1hEBTXLna3cQeZcMFKYXvCpqjQHPaXeJ9KxGm8DXrHtN qOQw== 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=cpkV6lwos6AmhWExNwBEiyWeN/omBOvoDNq6qQy3Qnc=; b=AqRVnoOzf1gAWWQ3S9W3tu4xU2cq8/UDM74brmtJaO7K0SpkJcIggxS9BQzrs9Hebk mZbvE3LrHFbj1kUvYyE39zjOiXDPMoWo1OvNoh7m60L5FdLXtm8v2BZs/ob884Y1vuvF qzcKKWPGPyhjnqkmxaw6tlHCoVEKrVtvyFSTGEAh9LX87v8KFG9H1KVlFfQvHEaOpm2+ pZtgkvaFEIbFHjdUZgDFBB53Dzis1MDbXcytLJf+bTpRetKutcQCs3lv5OtNRd2W1NQE 9xBK77XpPHSpYFmvbF2p9U/Xb2RAJdUkkQDYjX2rfXA5bgEAGyDeTAxBoDJSsFbJVlQo GoQw== X-Gm-Message-State: AOAM533O0P5zhPOyXKaX+DrTuSzL8grOS0QQUCHiuoMIOx8FKHb7YhIW HKxMouq+o0B/30L1XAReeacOC2tRTqhV9MHTPuF0DNPG X-Google-Smtp-Source: ABdhPJyGYv2O7JxysA1MU3SuPaqY65Niw6yFALYTHiDaksBQOlVQbBbaxZ2WFEOfoLJgYyFRWx7WugmYQRKcw9et2Gs= X-Received: by 2002:a63:f5c:: with SMTP id 28mr563857pgp.243.1633130772036; Fri, 01 Oct 2021 16:26:12 -0700 (PDT) MIME-Version: 1.0 References: <03B8E50C-B8FA-4DCB-A4E4-91C33590E57C@tony.li> In-Reply-To: <03B8E50C-B8FA-4DCB-A4E4-91C33590E57C@tony.li> From: Gyan Mishra Date: Fri, 1 Oct 2021 19:26:01 -0400 Message-ID: To: Tony Li Cc: Andrew Alston , James Guichard , SPRING WG , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="00000000000089ff4f05cd52e3b5" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 01 Oct 2021 23:26:19 -0000 --00000000000089ff4f05cd52e3b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear WG chairs, I agree with Greg Mirsky that the adoption guidelines are confusing and contradictory. Bullet #1 states that by expressing support for adoption the WG member is agreeing to adoption of a document that has multiple SRv6 compression solutions. On the other hand bullet #4 states that if the draft is adopted that the following text excerpt below should be added to as an open issue issues section. - "Given that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple S= Rv6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coherent with its one data plane solution objective.". This sentence is very confusing as the WG chairs agree that the WG has consensus on a single solution to avoid interoperability, and the WG chairs acknowledge that some WG members feel that the multiple flavors are actually multiple solutions, how is it possible that the WG would address that this is as valid and coherent with one date plane solution as the objective. The valid and coherent part of how a multiple data plane solution or flavor meets the single data plane objective is contradictory. I believe what is stated here by the chairs is exactly what should have been cleared up prior to the adoption call, but now as the adoption call has started would be cleared up during the adoption call process. This is somewhat of a chess game as to which way to have proceeded, but I think getting this cleared up prior to the call for adoption would have been better for the WG. All WG members that feel strongly that the two endpoint flavors are two distinctly different solutions will stick to their guns and support not adopting the document. All WG members that are Ok with two solutions versus a single SRV6 compression solution will chose to adopt the draft. The down side of not resolving this issue prior to adoption call is that there is a chance the many that felt strongly for a single solution as risk of interoperability issues as all vendors due to cost may not want to implement multiple compression solutions and may not all pick the same compression solution. So there could be a unanimous vote to not adopt as this goes against the WG consensus on a single data plane solution. I agree that is not a major risk going this route as the draft would be kicked back to the authors to revise and pick one of the flavors to put forward for adoption. The flip side is we are back to the drawing board with the DT on WG consensus on a compression solution to agree to for an adoption call. Kind Regards Gyan On Fri, Oct 1, 2021 at 4:55 PM Tony Li wrote: > > +1 > > I object to the adoption. > > Tony > > > On Oct 1, 2021, at 1:43 PM, Andrew Alston < > Andrew.Alston=3D40liquidtelecom.com@dmarc.ietf.org> wrote: > > Just to add to this, > > I am one of the people who clearly stated that I didn=E2=80=99t think a s= ingle > solution was the right answer here =E2=80=93 and I stated my reasoning cl= early on > this list. I still believe that =E2=80=93 however =E2=80=93 I recognize = that the > foundation of the IETF is found in the bottom up consensus approach =E2= =80=93 and > when the working group has demonstrated such clear consensus =E2=80=93 to= defy that > =E2=80=93 is to defy what makes the IETF the IETF. > > So =E2=80=93 While I still believe in multiple solutions =E2=80=93 irresp= ective of that =E2=80=93 > I find this call appalling =E2=80=93 because as much as I believe in mult= iple > solutions =E2=80=93 the working group consensus should be sacrosanct. > > Andrew > > > > *From: *Andrew Alston > *Date: *Friday, 1 October 2021 at 23:21 > *To: *James Guichard , SPRING WG < > spring@ietf.org> > *Cc: *spring-chairs@ietf.org > *Subject: *Re: WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > Sorry =E2=80=93 but =E2=80=93 I=E2=80=99m a little confused here. > > Because the way I look at this =E2=80=93 the working group clearly stated= that > they wished for a single behavior =E2=80=93 and this =E2=80=93 does not d= eliver that =E2=80=93 it > is two separate behaviors. As such =E2=80=93 I see this call for adoptio= n =E2=80=93 > irrespective of the merits or lack thereof of the draft, as a clear > defiance of the stated will of the working group. > > This is simply does not fit into the definition of bottom up approach in > my opinion =E2=80=93 and if this is the way that the chairs wish to proce= ed =E2=80=93 then > the only way to do that and still fit within the bottom up approach is to > first ask this working group for its consensus to deviate from the single > behacvior approach that the working group agreed to. > > As such =E2=80=93 I must strongly and unequivocally object to this call = for > adoption > > Andrew > > > *From: *spring on behalf of James Guichard < > james.n.guichard@futurewei.com> > *Date: *Friday, 1 October 2021 at 17:05 > *To: *SPRING WG > *Cc: *spring-chairs@ietf.org > *Subject: *[spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > Dear WG: > > The chairs would like to express their appreciation for all the responses > received to our emails with reference to how the working group wishes to > move forward with respect to a solution for SRv6 compression. > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > as the basis for its compression standardization work. That is part of > what this email attempts to confirm. > > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging th= at: > > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change = as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the working > group to publication. A list of these discussion points will be docume= nted > in the WG document and maintained by the document editor in conjunctio= n > with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text describin= g an > open issue be added to the document in the above-described open issues > section: > - "Given that the working group has said that it wants to > standardize one data plane solution, and given that the document co= ntains > multiple SRv6 EndPoint behaviors that some WG members have stated a= re > multiple data plane solutions, the working group will address wheth= er this > is valid and coherent with its one data plane solution objective.". > > > Please consider the above guidelines as you decide on whether to support > or not this WG adoption. Please express clearly your reasoning for > support/non-support as well as any open discussion points you would like > addressed should the document be adopted into the working group. > > Thanks! > > Jim, Bruno & Joel > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --00000000000089ff4f05cd52e3b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear WG chairs,
I agree with Greg Mirsky that the adoption guideli= nes are confusing and contradictory. =C2=A0=C2=A0
Bullet =C2=A0#1 states that by expressing support= for adoption the WG member is agreeing to adoption of a document that has = multiple SRv6 compression solutions. =C2=A0

On the other hand bullet #4 states that if the draft is= adopted that the following text excerpt below should be added to as an ope= n issue issues section. =C2=A0


  • "Given that the working group = has said that it wants to standardize one data plane solution, and given th= at the document contains multiple SRv6 EndPoint behaviors that some WG memb= ers have stated are multiple data plane solutions, the working group will a= ddress whether this is valid and coherent with its one data plane solution = objective.".

This sentence is very confusing as the WG chairs agree that the WG has = consensus on a single solution to avoid interoperability, and the WG chairs= acknowledge that some WG members feel that the multiple flavors are actual= ly multiple solutions, how is it possible that the WG would address that th= is is as valid and coherent with one date plane solution as the objective.= =C2=A0 The valid and coherent part of how a multiple data plane solution or= flavor meets the single data plane objective is contradictory.

=C2=A0I believe what is stated here= by the chairs is exactly what should have been cleared up prior to the ado= ption call, but now as the adoption call has started =C2=A0would be cleared= up during the adoption call process.=C2=A0 This is somewhat of a chess gam= e as to which way to have proceeded, but I think getting this cleared up pr= ior to the call for adoption would have been better for the WG.

All WG members that feel strongly t= hat the two endpoint flavors are two distinctly different solutions will st= ick to their guns and support not adopting the document.

All WG members that are Ok with two soluti= ons versus a single SRV6 compression solution will chose to adopt the draft= . =C2=A0

The down side o= f not resolving this issue prior to adoption call =C2=A0is that there is a = chance the many that felt strongly for a single solution as risk of interop= erability issues as all vendors due to cost may not want to implement multi= ple compression solutions and may not all pick the same compression solutio= n. =C2=A0

So there could= be a unanimous vote to not adopt as this goes against the WG consensus on = a single data plane solution.

I agree that is not a major risk going this route as the draft would = be kicked back to the authors to revise and pick one of the flavors to put = forward for adoption. =C2=A0=C2=A0

The flip side is we are back to the drawing board with the DT on= WG consensus on a compression solution to agree to for an adoption call.

Kind Regards=C2=A0
<= div dir=3D"auto">
Gyan

On Fri, Oct 1, 2021 = at 4:55 PM Tony Li <tony.li@tony.li> wrote:



On Oct 1, 2021, at 1:43 PM, Andrew Alston <Andrew.Alston=3D40liquidtelecom.com@dmarc.ietf.org> wrote:
Just to add to this,
=C2=A0
I am one of the people who clearly stated that I didn=E2=80=99t think a= single solution was the right answer here =E2=80=93 and I stated my reason= ing clearly on this list.=C2=A0 I still believe that =E2=80=93 however =E2= =80=93 I recognize that the foundation of the IETF is found in the bottom u= p consensus approach =E2=80=93 and when the working group has demonstrated = such clear consensus =E2=80=93 to defy that =E2=80=93 is to defy what makes= the IETF the IETF.
=C2=A0
<= span lang=3D"EN-US" style=3D"font-family:Calibri,sans-serif">So =E2=80=93 W= hile I still believe in multiple solutions =E2=80=93 irrespective of that = =E2=80=93 I find this call appalling =E2=80=93 because as much as I believe= in multiple solutions =E2=80=93 the working group consensus should be sacr= osanct.
= =C2=A0
Andrew=
=C2=A0
=C2=A0

From:= =C2=A0Andrew Alston <Andrew.Alston@liquidtelecom.com><= br>Date:=C2=A0Friday, 1 October 2021 at 23:21To:=C2=A0James Guichard <james.n.guicha= rd@futurewei.com>, SPRING WG <spring@ietf.org>
Cc:=C2=A0spring-chairs@ietf.org=C2=A0<spring-chairs@ietf.org>
Subject:=C2=A0Re: WG Adoption call for=C2=A0https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/

Sorry =E2=80=93 but =E2=80=93 I= =E2=80=99m a little confused here.
=C2=A0=
Because the way I look at this =E2=80=93 the working group clearly stated = that they wished for a single behavior =E2=80=93 and this =E2=80=93 does no= t deliver that =E2=80=93 it is two separate behaviors.=C2=A0 As such =E2=80= =93 I see this call for adoption =E2=80=93 irrespective of the merits or la= ck thereof of the draft, as a clear defiance of the stated will of the work= ing group.
=C2=A0
This is simply does not= fit into the definition of bottom up approach in my opinion =E2=80=93 and = if this is the way that the chairs wish to proceed =E2=80=93 then the only = way to do that and still fit within the bottom up approach is to first ask = this working group for its consensus to deviate from the single behacvior a= pproach that the working group agreed to.
=
=C2=A0
As such =E2=80=93 I must =C2=A0strongly and unequivocally object to= this call for adoption
=C2=A0=
Andrew
<= u style=3D"font-family:Calibri,sans-serif">=C2=A0

From:=C2=A0= sp= ring <spring-bounces@ietf.org> on beha= lf of James Guichard <james.n.guichard= @futurewei.com>
Date:= =C2=A0Friday, 1 O= ctober 2021 at 17:05
To:=C2=A0SPRING WG <<= a href=3D"mailto:spring@ietf.org" target=3D"_blank" style=3D"font-family:Ca= libri,sans-serif">spring@ietf.org>
Cc:=C2=A0spring-chairs@ietf.org <spring-chairs@ietf.org>
Subject:=C2= =A0[spring] WG Adoption call for https://datatracker.ietf.org= /doc/draft-filsfilscheng-spring-srv6-srh-compression/<= /u>

Dear WG:
<= /u>=C2=A0
The chairs would like= to express their appreciation for all the responses received to our emails= with reference to how the working group wishes to move forward with respec= t to a solution for SRv6 compression.
=C2=A0
The apparent inclination of the working group is to use=C2=A0https://datatracker.ietf.org/doc/draft-filsfilscheng-spri= ng-srv6-srh-compression/= =C2=A0as the basis for its compression standardization work. That is= part of what this email attempts to confirm.
=C2=A0
Because of the above the chairs would like to issue a 2-week WG= call for adoption ending October 15th=C2=A0= for=C2=A0https://datatracker.ietf.org/doc/draft= -filsfilscheng-spring-srv6-srh-compression/=C2=A0but with some clear guidelines as follows. = By expressing support for adoption of this document you are fully aware of = and are acknowledging that:=
=C2=A0
  1. The SPRING working group is adopting a document that has multiple= SRv6 Endpoint behaviors.
  2. The document is a =E2=80=9Cliving= =E2=80=9D document; it may change as it goes through review and analysis by= the SPRING working group.<= u style=3D"font-family:Calibri,sans-serif">
  3. All open discussion points raised= on our mailing list MUST be addressed BEFORE said document is allowed to p= rogress from the working group to publication. A list of these discussion p= oints will be documented in the WG document and maintained by the document = editor in conjunction with the chairs.
  4. If this document is a= dopted by the working group, the chairs specify as part of the adoption cal= l that the following text describing an open issue be added to the document= in the above-described open issues section:
    • "G= iven that the working group has said that it wants to standardize one data = plane solution, and given that the document contains multiple SRv6 EndPoint= behaviors that some WG members have stated are multiple data plane solutio= ns, the working group will address whether this is valid and coherent with = its one data plane solution objective.".
=C2=A0
Please consider the above guidelines as you decide on = whether to support or not this WG adoption. Please express clearly your rea= soning for support/non-support as well as any open discussion points you wo= uld like addressed should the document be adopted into the working group.
=C2=A0
Thanks!=
=C2=A0
Jim, Bruno & Joel
=C2=A0
=C2=A0
__________________________________________= _____
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listin= fo/spring

______________= _________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--
--00000000000089ff4f05cd52e3b5-- From nobody Fri Oct 1 16:58:46 2021 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 2B6513A03EE; Fri, 1 Oct 2021 16:58:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56RBJQ0zRSX6; Fri, 1 Oct 2021 16:58:23 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 4C3A83A0366; Fri, 1 Oct 2021 16:58:23 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id x7so38952728edd.6; Fri, 01 Oct 2021 16:58:23 -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; bh=7ekB7VJ10ukp+Hc8Xjh3WsJ3l4ltd7b8jakLAnDj+Zw=; b=kK8wLVyegvDiMBip1Y/D7wvmcVsTv0CXhi5kPbAbE57MPJ/eTDdSKHkjsbFohA+d1D 03QsHF03nQb1D26MEa10EspKdbgxjzOM3NbjuB8o1VHkcd50pIlBYbcRpclzpedl4xd0 8YWFJkCi+TSDeKfcnOQWbUr8zMKqQ6p7MwP2G+xVNBmFfe0WyXmTT0e/JTQ7VqFkq6bz OKaPIRztWp/YFibCs4rncG7+uTE5a6W5U9LgZuFxvKXoXEblxtRYgByRiEq3XNlHrQ5s taQZMOSpQfCbtMqHk6tMyZWegPI1ULfy+8a0L3fLQaIhnJ0LM3H4CxhTwwfhvCMLaud8 oV/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; bh=7ekB7VJ10ukp+Hc8Xjh3WsJ3l4ltd7b8jakLAnDj+Zw=; b=ClDBSsqOAPSJspBz2TKPKpVbopTxLaaXT0nAbAXAEPIZkhpG3j6V6BBVqM0fOs0FuX sswsE5ZTJflymz5swmUo9Z5hyXS80CVJAaUUkTCa0JXX0tYDl/F1klJK0IJkvPvq2i/R mqhzDPtrrulq3tH2svttAtW8xGIV7esG/GYzTni269eO+3VsGmziCYCb3iYMhVqWiKex qiBdlc+XSEIJEbMquCEDpUZ822o4Vk+y1f4rTC5Ac8z512VdTu2pHsmDOYEeWlT8l/yA 6AbTk83MwE/NThahHJYT31sabOQMZE96eBF8/dhKlStiN01LxlwKK1wrAK9D8gNMYS9w lY9A== X-Gm-Message-State: AOAM532/tHvSnQcIGNT0ampVPnFfG5MNtAuE4HFhvzymLLAPU7MIGkU3 SvPkXLP0giAXhGHYuHvbaO2SIWIepihVZK+mcIxtHfUlGkg= X-Google-Smtp-Source: ABdhPJzmwEJP/2xRM7ha4NAZZH2Ix+W0YEJpAwxz4bMk0dd6dFDSaeTdeIguL+tJywybUDvtsen36QKprXZ4TG9XeBA= X-Received: by 2002:a17:907:a425:: with SMTP id sg37mr967021ejc.131.1633132700440; Fri, 01 Oct 2021 16:58:20 -0700 (PDT) MIME-Version: 1.0 References: <163313187206.24807.8239560308568623975@ietfa.amsl.com> In-Reply-To: <163313187206.24807.8239560308568623975@ietfa.amsl.com> From: Greg Mirsky Date: Fri, 1 Oct 2021 16:58:09 -0700 Message-ID: To: rtg-bfd WG , MPLS Working Group , spring Content-Type: multipart/alternative; boundary="0000000000007b1ed305cd5356ee" Archived-At: Subject: [spring] Fwd: New Version Notification for draft-mirsky-bfd-mpls-demand-10.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, 01 Oct 2021 23:58:29 -0000 --0000000000007b1ed305cd5356ee Content-Type: text/plain; charset="UTF-8" Dear All, the update in this version describes the benefits of using BFD for multipoint networks (RFCs 8562 and 8563) over p2p MPLS LSP. Because RFC 8562 updated the BFD state machine, actors avoid the Init state and do not use the three-way handshake to advance the BFD session to the Up state. Thus, the value of My Discriminator, used by MultipointTail do demultiplex BFD sessions, must be provisioned by other means, e.g., using an extension to an IGP protocol. An unsolicited notification from a MultipointTail that detected failure of the BFD session to the MultipointHead can be used as described in the draft. Your comments, questions, and suggestions are welcome. I ask for consideration of adopting this document. It describes a new mechanism (complementary to RFC 5884) that can be used to detect failures in MPLS and SR-MPLS networks. Regards, Greg ---------- Forwarded message --------- From: Date: Fri, Oct 1, 2021 at 4:44 PM Subject: New Version Notification for draft-mirsky-bfd-mpls-demand-10.txt To: Greg Mirsky A new version of I-D, draft-mirsky-bfd-mpls-demand-10.txt has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-mirsky-bfd-mpls-demand Revision: 10 Title: BFD in Demand Mode over Point-to-Point MPLS LSP Document date: 2021-10-01 Group: bfd Pages: 6 URL: https://www.ietf.org/archive/id/draft-mirsky-bfd-mpls-demand-10.txt Status: https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/ Html: https://www.ietf.org/archive/id/draft-mirsky-bfd-mpls-demand-10.html Htmlized: https://datatracker.ietf.org/doc/html/draft-mirsky-bfd-mpls-demand Diff: https://www.ietf.org/rfcdiff?url2=draft-mirsky-bfd-mpls-demand-10 Abstract: This document describes procedures for using Bidirectional Forwarding Detection (BFD) in Demand mode to detect data plane failures in Multiprotocol Label Switching (MPLS) point-to-point Label Switched Paths. The IETF Secretariat --0000000000007b1ed305cd5356ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear All,
the update in this version describes the ben= efits of using BFD for multipoint networks (RFCs 8562 and 8563) over p2p MP= LS LSP. Because RFC 8562 updated the BFD state machine, actors avoid the In= it state and do not use the three-way handshake to advance the BFD session = to the Up state. Thus, the value of My Discriminator, used by MultipointTai= l do demultiplex BFD sessions, must be provisioned by other means, e.g., us= ing an extension to an IGP protocol. An unsolicited notification from a Mul= tipointTail that detected failure of the BFD session to the MultipointHead = can be used as described in the draft.=C2=A0

Your = comments, questions, and suggestions are welcome.
I ask for consi= deration of adopting this document. It describes a new mechanism (complemen= tary to RFC 5884) that can be used to detect failures in MPLS and SR-MPLS n= etworks.

Regards,
Greg

---------- Forwarded= message ---------
From: <internet-drafts@ietf.org>
Date: Fri, O= ct 1, 2021 at 4:44 PM
Subject: New Version Notification for draft-mirsky= -bfd-mpls-demand-10.txt
To: Greg Mirsky <gregimirsky@gmail.com>



A new version of I-D, draft-mirsky-bfd-mpls-demand-10.txt
has been successfully submitted by Greg Mirsky and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mirsky-bfd-mpls-demand<= br> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A010
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 BFD in Demand Mode over Point-to-P= oint MPLS LSP
Document date:=C2=A0 2021-10-01
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 bfd
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 6
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/archive/id/draft-mirsky-bfd-mpls-demand-1= 0.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mirsky-bfd-mpls-demand/
Html:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/archive/id/draft-mirsky-bfd-mpls-demand-= 10.html
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mirsky-bfd-mpls-demand Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-mirsky-bfd-mpls-dema= nd-10

Abstract:
=C2=A0 =C2=A0This document describes procedures for using Bidirectional For= warding
=C2=A0 =C2=A0Detection (BFD) in Demand mode to detect data plane failures i= n
=C2=A0 =C2=A0Multiprotocol Label Switching (MPLS) point-to-point Label Swit= ched
=C2=A0 =C2=A0Paths.




The IETF Secretariat


--0000000000007b1ed305cd5356ee-- From nobody Fri Oct 1 21:55:58 2021 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 5E3C13A0771; Fri, 1 Oct 2021 21:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.001, HDRS_MISSP=0.001, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dxjsxrehrsg; Fri, 1 Oct 2021 21:55:49 -0700 (PDT) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id 0547F3A074D; Fri, 1 Oct 2021 21:55:46 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.17]) by rmmx-syy-dmz-app07-12007 (RichMail) with SMTP id 2ee76157e6404c9-21619; Sat, 02 Oct 2021 12:55:31 +0800 (CST) X-RM-TRANSID: 2ee76157e6404c9-21619 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from CMCC-PC (unknown[111.167.15.133]) by rmsmtp-syy-appsvr09-12009 (RichMail) with SMTP id 2ee96157e6415bb-5b91f; Sat, 02 Oct 2021 12:55:30 +0800 (CST) X-RM-TRANSID: 2ee96157e6415bb-5b91f MIME-Version: 1.0 x-PcFlag: 511210f1-3fff-4969-93c2-22b12f80c8fa_5_45322 X-Mailer: PC_RICHMAIL 2.8.8 Date: 02 Oct 2021 12:55:32 +0800 From: =?utf-8?B?WWlzb25nIExpdQ==?= To: =?utf-8?B?SmFtZXMgR3VpY2hhcmQ=?=, =?utf-8?B?U1BSSU5HIFdH?= Cc: spring-chairs Message-ID: <202110021255323466813813@chinamobile.com> Content-Type: multipart/Alternative; boundary="----=_001_NextPart-828153483_=----" Archived-At: Subject: [spring] =?utf-8?q?RE=EF=BC=9A__WG_Adoption_call_for_https=3A//d?= =?utf-8?q?atatracker=2Eietf=2Eorg/doc/draft-filsfilscheng-spring-srv6-srh?= =?utf-8?q?-compression/?= 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, 02 Oct 2021 04:55:55 -0000 This is a multi-part message in MIME format. ------=_001_NextPart-828153483_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQ1IaSBDaGFpcnMgJmFtcDsgV0csDQ0NDQ1JIHN0cm9uZ2x5IHN1cHBvcnQgdGhlIGFkb3B0aW9u IGNhbGwuIFJlZ2FyZGluZyBjaGFpcidzIG5vdGUgaW4gdGhlIGVtYWlsLCBJIHdvdWxkIGxpa2Ug dG8gcG9pbnQgdGhhdCB0aGUgbmV0d29yayBwcm9ncmFtbWluZyBtb2RlbCAoUkZDODk5NikgYnkg bmF0dXJlIGRlZmluZXMgbXVsdGlwbGUgYmVoYXZpb3JzLiBDU0lEIGhhcyBhIHNpbmdsZSBTUnY2 IGJhc2VkIGRhdGEgcGxhbmUgdGhhdCBkZWZpbmVzIHRoZSBuZXh0IGFuZCByZXBsYWNlIGJlaGF2 aW9ycyBjb25zaXN0ZW50IHdpdGggdGhlIG5ldHdvcmsgcHJvZ3JhbW1pbmcgcGFyYWRpZ20uDQ0N DQ1DU0lEJ3MgbmV4dCBhbmQgcmVwbGFjZSBiZWhhdmlvcnMgaGF2ZSBiZWVuIHZlcmlmaWVkIGJ5 IGludGVyb3BlcmFiaWxpdHkgdGVzdCBpbiBDaGluYSBtb2JpbGUgbGFib3JhdG9yeSBhbmQgdGhl cmUgaXMgbm8gcHJvYmxlbSB3aXRoIHRoZSBpbnRlcndvcmtpbmcgb2YgdGhlIHR3byBiZWhhdmlv cnMgb24gdGhlIENTSUQgZGF0YXBsYW5lLg0NDQ0NQmVzdCBSZWdhcmRzDQ1ZaXNvbmcNDQ0NDQ0N DQ0NIA0NDQ3lj5Hku7bkuro6IEphbWVzIEd1aWNoYXJkDQ3ml7bpl7Q6IDIwMjEvMTAvMDEo5pif 5pyf5LqUKTIyOjA0DQ3mlLbku7bkuro6IFNQUklORyBXRzsNDeaKhOmAgeS6ujogc3ByaW5nLWNo YWlyczsNDeS4u+mimDogW3NwcmluZ10gV0cgQWRvcHRpb24gY2FsbCBmb3IgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgt Y29tcHJlc3Npb24vIA0NIA0NRGVhciBXRzogDQ0gIA0NVGhlIGNoYWlycyB3b3VsZCBsaWtlIHRv IGV4cHJlc3MgdGhlaXIgYXBwcmVjaWF0aW9uIGZvciBhbGwgdGhlIHJlc3BvbnNlcyByZWNlaXZl ZCB0byBvdXIgZW1haWxzIHdpdGggcmVmZXJlbmNlIHRvIGhvdyB0aGUgd29ya2luZyBncm91cCB3 aXNoZXMgdG8gbW92ZSBmb3J3YXJkIHdpdGggcmVzcGVjdCB0byBhIHNvbHV0aW9uIGZvciBTUnY2 IGNvbXByZXNzaW9uLiAgDQ0gIA0NVGhlIGFwcGFyZW50IGluY2xpbmF0aW9uIG9mIHRoZSB3b3Jr aW5nIGdyb3VwIGlzIHRvIHVzZSAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vIGFzIHRoZSBiYXNp cyBmb3IgaXRzIGNvbXByZXNzaW9uIHN0YW5kYXJkaXphdGlvbiB3b3JrLiBUaGF0IGlzIHBhcnQg b2Ygd2hhdCB0aGlzIGVtYWlsIGF0dGVtcHRzIHRvIGNvbmZpcm0uIA0NICANDUJlY2F1c2Ugb2Yg dGhlIGFib3ZlIHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBpc3N1ZSBhIDItd2VlayBXRyBjYWxs IGZvciBhZG9wdGlvbiBlbmRpbmcgT2N0b2JlciAxNXRoIGZvciAgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJl c3Npb24vIGJ1dCB3aXRoIHNvbWUgY2xlYXIgZ3VpZGVsaW5lcyBhcyBmb2xsb3dzLiBCeSBleHBy ZXNzaW5nIHN1cHBvcnQgZm9yIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgeW91IGFyZSBmdWxs eSBhd2FyZSBvZiBhbmQgYXJlIGFja25vd2xlZGdpbmcgdGhhdDogIA0NICAgVGhlIFNQUklORyB3 b3JraW5nIGdyb3VwIGlzIGFkb3B0aW5nIGEgZG9jdW1lbnQgdGhhdCBoYXMgbXVsdGlwbGUgU1J2 NiBFbmRwb2ludCBiZWhhdmlvcnMuIFRoZSBkb2N1bWVudCBpcyBhIOKAnGxpdmluZ+KAnSBkb2N1 bWVudDsgaXQgbWF5IGNoYW5nZSBhcyBpdCBnb2VzIHRocm91Z2ggcmV2aWV3IGFuZCBhbmFseXNp cyBieSB0aGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAuIEFsbCBvcGVuIGRpc2N1c3Npb24gcG9pbnRz IHJhaXNlZCBvbiBvdXIgbWFpbGluZyBsaXN0IE1VU1QgYmUgYWRkcmVzc2VkIEJFRk9SRSBzYWlk IGRvY3VtZW50IGlzIGFsbG93ZWQgdG8gcHJvZ3Jlc3MgZnJvbSB0aGUgd29ya2luZyBncm91cCB0 byBwdWJsaWNhdGlvbi4gQSBsaXN0IG9mIHRoZXNlIGRpc2N1c3Npb24gIHBvaW50cyB3aWxsIGJl IGRvY3VtZW50ZWQgaW4gdGhlIFdHIGRvY3VtZW50IGFuZCBtYWludGFpbmVkIGJ5IHRoZSBkb2N1 bWVudCBlZGl0b3IgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgY2hhaXJzLiBJZiB0aGlzIGRvY3Vt ZW50IGlzIGFkb3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAsIHRoZSBjaGFpcnMgc3BlY2lmeSBh cyBwYXJ0IG9mIHRoZSBhZG9wdGlvbiBjYWxsIHRoYXQgdGhlIGZvbGxvd2luZyB0ZXh0IGRlc2Ny aWJpbmcgYW4gb3BlbiBpc3N1ZSBiZSBhZGRlZCB0byB0aGUgZG9jdW1lbnQgaW4gdGhlIGFib3Zl LWRlc2NyaWJlZCAgb3BlbiBpc3N1ZXMgc2VjdGlvbjogIkdpdmVuIHRoYXQgdGhlIHdvcmtpbmcg Z3JvdXAgaGFzIHNhaWQgdGhhdCBpdCB3YW50cyB0byBzdGFuZGFyZGl6ZSBvbmUgZGF0YSBwbGFu ZSBzb2x1dGlvbiwgYW5kIGdpdmVuIHRoYXQgdGhlIGRvY3VtZW50IGNvbnRhaW5zIG11bHRpcGxl IFNSdjYgRW5kUG9pbnQgYmVoYXZpb3JzIHRoYXQgc29tZSBXRyBtZW1iZXJzIGhhdmUgc3RhdGVk IGFyZSAgbXVsdGlwbGUgZGF0YSBwbGFuZSBzb2x1dGlvbnMsIHRoZSB3b3JraW5nIGdyb3VwIHdp bGwgYWRkcmVzcyB3aGV0aGVyIHRoaXMgaXMgdmFsaWQgYW5kIGNvaGVyZW50IHdpdGggaXRzIG9u ZSBkYXRhIHBsYW5lIHNvbHV0aW9uIG9iamVjdGl2ZS4iLiAgDQ0gIA0NUGxlYXNlIGNvbnNpZGVy IHRoZSBhYm92ZSBndWlkZWxpbmVzIGFzIHlvdSBkZWNpZGUgb24gd2hldGhlciB0byBzdXBwb3J0 IG9yIG5vdCB0aGlzIFdHIGFkb3B0aW9uLiBQbGVhc2UgZXhwcmVzcyBjbGVhcmx5IHlvdXIgcmVh c29uaW5nIGZvciBzdXBwb3J0L25vbi1zdXBwb3J0IGFzIHdlbGwgYXMgYW55IG9wZW4gZGlzY3Vz c2lvbiBwb2ludHMgeW91IHdvdWxkIGxpa2UgYWRkcmVzc2VkIHNob3VsZCB0aGUgZG9jdW1lbnQg IGJlIGFkb3B0ZWQgaW50byB0aGUgd29ya2luZyBncm91cC4gDQ0gIA0NVGhhbmtzISANDSAgDQ1K aW0sIEJydW5vICZhbXA7IEpvZWwgDQ0gIA0N ------=_001_NextPart-828153483_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable <=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->
Hi=20Chairs=20&a= mp;=20WG,

I=20strongly=20support= =20the=20adoption=20call.=20Regarding=20chair's=20note=20in=20the=20email,= =20I=20would=20like=20to=20point=20that=20the=20network=20programming=20mod= el=20(RFC8996)=20by=20nature=20defines=20multiple=20behaviors.=20CSID=20has= =20a=20single=20SRv6=20based=20data=20plane=20that=20defines=20the=20next= =20and=20replace=20behaviors=20consistent=20with=20the=20network=20programm= ing=20paradigm.

CSID's=20next=20and=20replace=20behaviors=20have= =20been=20verified=20by interoperability=20test <= span=20style=3D=22font-family:=20=E5=BE=AE=E8=BD=AF=E9=9B=85=E9=BB=91;=22>i= n=20China=20mobile=20laboratory=20and=20there=20is=20no=20problem=20with=20the=20inte= rworking=20of=20the=20two=20behaviors=20on=20the=20CSID=20dataplane.=

Best=20RegardsYisong
=
 
=E5=8F=91=E4=BB=B6= =E4=BA=BA:=20Jame= s=20Guichard=E6=97=B6=E9=97=B4:=202021/10/01(=E6=98=9F= =E6=9C=9F=E4=BA=94)22:04=E6=94=B6=E4=BB=B6=E4=BA=BA:=20SPRING=20WG;= =E6=8A=84=E9=80=81=E4=BA=BA:=20spring-chairs;=E4=B8=BB=E9=A2=98:=20=5Bspring=5D= =20WG=20Adoption=20call=20for=20https://datatracker.ietf.org/doc/draft-fils= filscheng-spring-srv6-srh-compression/=0A=0ADear=20WG:

=0A 

=0AThe=20chairs=20would= =20like=20to=20express=20their=20appreciation=20for=20all=20the=20responses= =20received=20to=20our=20emails=20with=20reference=20to=20how=20the=20worki= ng=20group=20wishes=20to=20move=20forward=20with=20respect=20to=20a=20solut= ion=20for=20SRv6=20compression.=0A

=0A 

=0AThe=20apparent= =20inclination=20of=20the=20working=20group=20is=20to=20use=20=0Ahttps://datatracker.ietf.org/doc/draft-filsfilscheng-spring= -srv6-srh-compression/=20as=20the=20basis=20for=20its=20compression=20s= tandardization=20work.=20That=20is=20part=20of=20what=20this=20email=20atte= mpts=20to=20confirm.

=0A&nb= sp;

=0ABecause=20of=20the=20above=20t= he=20chairs=20would=20like=20to=20issue=20a=202-week=20WG=20call=20for=20ad= option=20ending=20October=2015th=20for=0A=0Ahttps://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh= -compression/=20but=20with=20some=20clear=20guidelines=20as=20follows.= =20By=20expressing=20support=20for=20adoption=20of=20this=20document=20you= =20are=20fully=20aware=20of=20and=20are=20acknowledging=20that:=0A

=0A 

=0A=0AThe=20SPRING=20working=20group=20is=20adopting=20a=20document=20= that=20has=20multiple=20SRv6=20Endpoint=20behaviors.=0AThe=20document=20is=20a=20=E2=80=9Cliving=E2=80=9D=20do= cument;=20it=20may=20change=20as=20it=20goes=20through=20review=20and=20ana= lysis=20by=20the=20SPRING=20working=20group.=0AAll=20open=20discussion=20points=20raised=20on=20our=20mailing= =20list=20MUST=20be=20addressed=20BEFORE=20said=20document=20is=20allowed= =20to=20progress=20from=20the=20working=20group=20to=20publication.=20A=20l= ist=20of=20these=20discussion=0A=20points=20will=20be=20documented=20in=20t= he=20WG=20document=20and=20maintained=20by=20the=20document=20editor=20in= =20conjunction=20with=20the=20chairs.=0AIf=20this=20document=20is=20adopted=20by=20the=20working=20group,=20the= =20chairs=20specify=20as=20part=20of=20the=20adoption=20call=20that=20the= =20following=20text=20describing=20an=20open=20issue=20be=20added=20to=20th= e=20document=20in=20the=20above-described=0A=20open=20issues=20section:=0A= =22Given=20that=20the=20working=20group=20has=20said=20that=20it=20wants=20= to=20standardize=20one=20data=20plane=20solution,=20and=20given=20that=20th= e=20document=20contains=20multiple=20SRv6=20EndPoint=20behaviors=20that=20s= ome=20WG=20members=20have=20stated=20are=0A=20multiple=20data=20plane=20sol= utions,=20the=20working=20group=20will=20address=20whether=20this=20is=20va= lid=20and=20coherent=20with=20its=20one=20data=20plane=20solution=20objecti= ve.=22.=0A=0A&n= bsp;

=0APlease=20consider=20the=20abo= ve=20guidelines=20as=20you=20decide=20on=20whether=20to=20support=20or=20no= t=20this=20WG=20adoption.=20Please=20express=20clearly=20your=20reasoning= =20for=20support/non-support=20as=20well=20as=20any=20open=20discussion=20p= oints=20you=20would=20like=20addressed=20should=20the=20document=0A=20be=20= adopted=20into=20the=20working=20group.

=0A 

=0AThanks=21

=0A 

=0AJim,=20Bruno=20&=20Joel

=0A 

=0A=  

=0A=0A=0A=0A ------=_001_NextPart-828153483_=------ From nobody Sat Oct 2 00:20:30 2021 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 001D13A0A55; Sat, 2 Oct 2021 00:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 t2y8yDpHsiKR; Sat, 2 Oct 2021 00:20:23 -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 B84683A0913; Sat, 2 Oct 2021 00:20:21 -0700 (PDT) Received: from DAG2EX03-BASE.srv.huawei-3com.com ([10.8.0.66]) by h3cspam02-ex.h3c.com with ESMTP id 1927K1rb006250; Sat, 2 Oct 2021 15:20:01 +0800 (GMT-8) (envelope-from qiuyuanxiang@h3c.com) Received: from DAG2EX06-IDC.srv.huawei-3com.com (10.8.0.69) by DAG2EX03-BASE.srv.huawei-3com.com (10.8.0.66) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Sat, 2 Oct 2021 15:20:01 +0800 Received: from DAG2EX06-IDC.srv.huawei-3com.com ([::1]) by DAG2EX06-IDC.srv.huawei-3com.com ([fe80::843a:43af:f00:d3c9%9]) with mapi id 15.01.2242.012; Sat, 2 Oct 2021 15:20:01 +0800 From: Qiuyuanxiang To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade3W8PiM1gcGPqoSzyOMemf93x5Pw== Date: Sat, 2 Oct 2021 07:20:01 +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.99.152.247] x-sender-location: DAG2 Content-Type: multipart/alternative; boundary="_000_ea82f2d5a3634b08898ca0c5ae9c0a4dh3ccom_" MIME-Version: 1.0 X-DNSRBL: X-MAIL: h3cspam02-ex.h3c.com 1927K1rb006250 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 02 Oct 2021 07:20:28 -0000 --_000_ea82f2d5a3634b08898ca0c5ae9c0a4dh3ccom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSB1bmRlcnN0YW5kIHRoYXQgQ1NJRCBkcmFmdCBkZWZpbmVzIHRoZSBORVhUIGFuZCBSRVBMQUNF IGJlaGF2aW9ycywgYnV0IHRoZXkgcHJlc2VudCBhIHNpbmdsZSBTUnY2IGRhdGEgcGxhbmUgYmFz ZWQgc29sdXRpb24uDQpJIHRvdGFsbHkgc3VwcG9ydCB0aGUgYWRvcHRpb24gY2FsbC4NCg0KDQq3 orz+yMs6IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEphbWVz IEd1aWNoYXJkDQq3osvNyrG85DogMjAyMcTqMTDUwjHI1SAyMjowNQ0KytW8/sjLOiBTUFJJTkcg V0cgPHNwcmluZ0BpZXRmLm9yZz4NCrOty806IHNwcmluZy1jaGFpcnNAaWV0Zi5vcmcNCtb3zOI6 IFtzcHJpbmddIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLw0K DQpEZWFyIFdHOg0KDQpUaGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gZXhwcmVzcyB0aGVpciBhcHBy ZWNpYXRpb24gZm9yIGFsbCB0aGUgcmVzcG9uc2VzIHJlY2VpdmVkIHRvIG91ciBlbWFpbHMgd2l0 aCByZWZlcmVuY2UgdG8gaG93IHRoZSB3b3JraW5nIGdyb3VwIHdpc2hlcyB0byBtb3ZlIGZvcndh cmQgd2l0aCByZXNwZWN0IHRvIGEgc29sdXRpb24gZm9yIFNSdjYgY29tcHJlc3Npb24uDQoNClRo ZSBhcHBhcmVudCBpbmNsaW5hdGlvbiBvZiB0aGUgd29ya2luZyBncm91cCBpcyB0byB1c2UgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmct c3J2Ni1zcmgtY29tcHJlc3Npb24vIGFzIHRoZSBiYXNpcyBmb3IgaXRzIGNvbXByZXNzaW9uIHN0 YW5kYXJkaXphdGlvbiB3b3JrLiBUaGF0IGlzIHBhcnQgb2Ygd2hhdCB0aGlzIGVtYWlsIGF0dGVt cHRzIHRvIGNvbmZpcm0uDQoNCkJlY2F1c2Ugb2YgdGhlIGFib3ZlIHRoZSBjaGFpcnMgd291bGQg bGlrZSB0byBpc3N1ZSBhIDItd2VlayBXRyBjYWxsIGZvciBhZG9wdGlvbiBlbmRpbmcgT2N0b2Jl ciAxNXRoIGZvciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmls c2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8gYnV0IHdpdGggc29tZSBjbGVhciBn dWlkZWxpbmVzIGFzIGZvbGxvd3MuIEJ5IGV4cHJlc3Npbmcgc3VwcG9ydCBmb3IgYWRvcHRpb24g b2YgdGhpcyBkb2N1bWVudCB5b3UgYXJlIGZ1bGx5IGF3YXJlIG9mIGFuZCBhcmUgYWNrbm93bGVk Z2luZyB0aGF0Og0KDQoNCiAgMS4gIFRoZSBTUFJJTkcgd29ya2luZyBncm91cCBpcyBhZG9wdGlu ZyBhIGRvY3VtZW50IHRoYXQgaGFzIG11bHRpcGxlIFNSdjYgRW5kcG9pbnQgYmVoYXZpb3JzLg0K ICAyLiAgVGhlIGRvY3VtZW50IGlzIGEgobBsaXZpbmehsSBkb2N1bWVudDsgaXQgbWF5IGNoYW5n ZSBhcyBpdCBnb2VzIHRocm91Z2ggcmV2aWV3IGFuZCBhbmFseXNpcyBieSB0aGUgU1BSSU5HIHdv cmtpbmcgZ3JvdXAuDQogIDMuICBBbGwgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyByYWlzZWQgb24g b3VyIG1haWxpbmcgbGlzdCBNVVNUIGJlIGFkZHJlc3NlZCBCRUZPUkUgc2FpZCBkb2N1bWVudCBp cyBhbGxvd2VkIHRvIHByb2dyZXNzIGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAgdG8gcHVibGljYXRp b24uIEEgbGlzdCBvZiB0aGVzZSBkaXNjdXNzaW9uIHBvaW50cyB3aWxsIGJlIGRvY3VtZW50ZWQg aW4gdGhlIFdHIGRvY3VtZW50IGFuZCBtYWludGFpbmVkIGJ5IHRoZSBkb2N1bWVudCBlZGl0b3Ig aW4gY29uanVuY3Rpb24gd2l0aCB0aGUgY2hhaXJzLg0KICA0LiAgSWYgdGhpcyBkb2N1bWVudCBp cyBhZG9wdGVkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLCB0aGUgY2hhaXJzIHNwZWNpZnkgYXMgcGFy dCBvZiB0aGUgYWRvcHRpb24gY2FsbCB0aGF0IHRoZSBmb2xsb3dpbmcgdGV4dCBkZXNjcmliaW5n IGFuIG9wZW4gaXNzdWUgYmUgYWRkZWQgdG8gdGhlIGRvY3VtZW50IGluIHRoZSBhYm92ZS1kZXNj cmliZWQgb3BlbiBpc3N1ZXMgc2VjdGlvbjoNCiAgICAgKiAgICJHaXZlbiB0aGF0IHRoZSB3b3Jr aW5nIGdyb3VwIGhhcyBzYWlkIHRoYXQgaXQgd2FudHMgdG8gc3RhbmRhcmRpemUgb25lIGRhdGEg cGxhbmUgc29sdXRpb24sIGFuZCBnaXZlbiB0aGF0IHRoZSBkb2N1bWVudCBjb250YWlucyBtdWx0 aXBsZSBTUnY2IEVuZFBvaW50IGJlaGF2aW9ycyB0aGF0IHNvbWUgV0cgbWVtYmVycyBoYXZlIHN0 YXRlZCBhcmUgbXVsdGlwbGUgZGF0YSBwbGFuZSBzb2x1dGlvbnMsIHRoZSB3b3JraW5nIGdyb3Vw IHdpbGwgYWRkcmVzcyB3aGV0aGVyIHRoaXMgaXMgdmFsaWQgYW5kIGNvaGVyZW50IHdpdGggaXRz IG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uIG9iamVjdGl2ZS4iLg0KDQpQbGVhc2UgY29uc2lkZXIg dGhlIGFib3ZlIGd1aWRlbGluZXMgYXMgeW91IGRlY2lkZSBvbiB3aGV0aGVyIHRvIHN1cHBvcnQg b3Igbm90IHRoaXMgV0cgYWRvcHRpb24uIFBsZWFzZSBleHByZXNzIGNsZWFybHkgeW91ciByZWFz b25pbmcgZm9yIHN1cHBvcnQvbm9uLXN1cHBvcnQgYXMgd2VsbCBhcyBhbnkgb3BlbiBkaXNjdXNz aW9uIHBvaW50cyB5b3Ugd291bGQgbGlrZSBhZGRyZXNzZWQgc2hvdWxkIHRoZSBkb2N1bWVudCBi ZSBhZG9wdGVkIGludG8gdGhlIHdvcmtpbmcgZ3JvdXAuDQoNClRoYW5rcyENCg0KSmltLCBCcnVu byAmIEpvZWwNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQqxvtPKvP68sMbkuL28/rqs09DQwruq yP28r83FtcSxo8Pc0MXPoqOsvfbP3tPat6LLzbj4yc/D5rXY1rfW0MHQs/YNCrXEuPbIy7vyyLrX 6aGjvfvWucjOus7G5Mv7yMvS1MjOus7Qzsq9yrnTw6OosPzAqLWrsrvP3tPayKuyv7vysr+31rXY 0LnCtqGiuLTWxqGiDQq78smit6KjqbG+08q8/tbQtcTQxc+ioaPI57n7xPq07crVwcuxvtPKvP6j rMfrxPrBory0tee7sLvy08q8/s2o1qq3orz+yMuyosm+s/2xvg0K08q8/qOhDQpUaGlzIGUtbWFp bCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZy b20gTmV3IEgzQywgd2hpY2ggaXMNCmludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50 aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZQ0KaW5mb3Jt YXRpb24gY29udGFpbmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGlt aXRlZCB0bywgdG90YWwgb3IgcGFydGlhbA0KZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBk aXNzZW1pbmF0aW9uKSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGludGVuZGVkDQpyZWNpcGll bnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KYnkgcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkg YW5kIGRlbGV0ZSBpdCENCg== --_000_ea82f2d5a3634b08898ca0c5ae9c0a4dh3ccom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I understand that CSID draft defines the NEXT and REPLACE behavio= rs, but they present a single SRv6 data plane based solution.

I totally support the adoption call.

 

 

=B7=A2=BC=FE=C8=CB:= spring [mailto:spring-bounces@ietf.org] =B4=FA=B1=ED James Guichard
=B7=A2=CB=CD=CA=B1=BC=E4:= 2021=C4=EA10=D4=C21=C8=D5 22:05
=CA=D5=BC=FE=C8=CB: SPRING WG <spring@ietf.org>
=B3=AD=CB=CD: spring-chairs@ietf.org
=D6=F7=CC=E2: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-fils= filscheng-spring-srv6-srh-compression/

 

Dear WG:

 

The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a sol= ution for SRv6 compression.

 

The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document that has multiple SRv6 = Endpoint behaviors.
  2. The document is a =A1=B0living=A1=B1 document; i= t may change as it goes through review and analysis by the SPRING working g= roup.
  3. All open discussion points raised on our mailing= list MUST be addressed BEFORE said document is allowed to progress from th= e working group to publication. A list of these discussion points will be documented in the WG document and maintained by the document edito= r in conjunction with the chairs.
  4. If this document is adopted by the working group= , the chairs specify as part of the adoption call that the following text d= escribing an open issue be added to the document in the above-described open issues section:
    • "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution obj= ective.".

 

Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open d= iscussion points you would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

-------------------------------------------------= ---------------------------------------------------------------------------= ---------
=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=D0=C2=BB=AA= =C8=FD=BC=AF=CD=C5=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7= =A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6
=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE= =C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0= =A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6= =A1=A2=B8=B4=D6=C6=A1=A2
=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2= =A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4= =FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB= =B2=A2=C9=BE=B3=FD=B1=BE
=D3=CA=BC=FE=A3=A1
This e-mail and its attac= hments contain confidential information from New H3C, 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! --_000_ea82f2d5a3634b08898ca0c5ae9c0a4dh3ccom_-- From nobody Sat Oct 2 00:25:40 2021 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 144993A0A62; Sat, 2 Oct 2021 00:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hTfYuyFn_mKX; Sat, 2 Oct 2021 00:25:33 -0700 (PDT) Received: from unicom145.biz-email.net (unicom145.biz-email.net [210.51.26.145]) (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 9C19B3A0A63; Sat, 2 Oct 2021 00:25:30 -0700 (PDT) Received: from ([58.210.9.219]) by unicom145.biz-email.net ((LNX1044)) with ASMTP id VHB00024; Sat, 02 Oct 2021 15:25:24 +0800 Received: from [192.168.43.175] ([49.93.127.169]) (envelope-sender ) by 192.168.25.7 with ESMTP for ; Sat, 02 Oct 2021 15:24:54 +0800 Sender: chengw@centecnetworks.com X-WM-Sender: chengw@centecnetworks.com X-WM-AuthFlag: YES X-WM-AuthUser: chengw@centecnetworks.com User-Agent: Microsoft-MacOutlook/16.53.21091200 Date: Sat, 02 Oct 2021 15:24:53 +0800 From: WEI CHENG To: James Guichard , CC: Message-ID: <7900C456-80A6-43AC-B18E-9FB51438A635@centecnetworks.com> Thread-Topic: [spring] WG Adoption call forhttps://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ References: <2b016157e9f37ff-00055.Richmail.00003070741421410951@chinamobile.com> In-Reply-To: <2b016157e9f37ff-00055.Richmail.00003070741421410951@chinamobile.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3716033094_1595084642" tUid: 20211002152524d5f17679707329aa8dcffb1c982cdcc3 X-Abuse-Reports-To: service@corp-email.com Abuse-Reports-To: service@corp-email.com X-Complaints-To: service@corp-email.com X-Report-Abuse-To: service@corp-email.com Archived-At: Subject: Re: [spring] WG Adoption call forhttps://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 02 Oct 2021 07:25:39 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3716033094_1595084642 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Dear WG: =20 I support the adoption of CSID draft. From chips design angels, I would lik= e to add that CSID defines next and replace behaviors that are consistent wi= th the SRv6 network programming RFC8996. =20 Thanks ! --- CENTEC Wei Cheng =20 ---=E9=82=AE=E4=BB=B6=E5=8E=9F=E6=96=87--- =E5=8F=91=E4=BB=B6=E4=BA=BA=EF=BC=9AJames Guichard =E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9ASPRING WG =E6=8A=84=E9=80=81=EF=BC=9A"spring-chairs@ietf.org" =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2021-10-01 22:12:53 =E4=B8=BB=E9=A2=98=EF=BC=9A[spring] WG Adoption call forhttps://datatracker.ietf.org/doc/draf= t-filsfilscheng-spring-srv6-srh-compression/ Dear WG: =20 The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to move= forward with respect to a solution for SRv6 compression.=20 =20 The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis = for its compression standardization work. That is part of what this email at= tempts to confirm. =20 Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsfi= lscheng-spring-srv6-srh-compression/ but with some clear guidelines as follo= ws. By expressing support for adoption of this document you are fully aware = of and are acknowledging that:=20 =20 The SPRING working group is adopting a document that has multiple SRv6 Endp= oint behaviors.=20 The document is a =E2=80=9Cliving=E2=80=9D document; it may change as it goes through r= eview and analysis by the SPRING working group.=20 All open discussion points raised on our mailing list MUST be addressed BEF= ORE said document is allowed to progress from the working group to publicati= on. A list of these discussion points will be documented in the WG document = and maintained by the document editor in conjunction with the chairs.=20 If this document is adopted by the working group, the chairs specify as par= t of the adoption call that the following text describing an open issue be a= dded to the document in the above-described open issues section: "Given that the working group has said that it wants to standardize one dat= a plane solution, and given that the document contains multiple SRv6 EndPoin= t behaviors that some WG members have stated are multiple data plane solutio= ns, the working group will address whether this is valid and coherent with i= ts one data plane solution objective.". =20 Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/non= -support as well as any open discussion points you would like addressed shou= ld the document be adopted into the working group. =20 Thanks! =20 Jim, Bruno & Joel =20 =20 --B_3716033094_1595084642 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Dear WG:

 

I support the adoption of C= SID draft. From chips design angels, I would like to add that CSID defines n= ext and replace behaviors that are consistent with the SRv6 network programm= ing RFC8996.

 

Thanks !

---

CENTEC

Wei Ch= eng

 

---=E9=82=AE=E4=BB=B6=E5=8E=9F= =E6=96=87---
=E5=8F= =91=E4=BB=B6=E4=BA=BA=EF=BC=9AJames Guichard <james.n.guichard@future= wei.com>
=E6=94=B6=E4=BB=B6=E4=BA=BA=EF=BC=9ASPRING WG <spring@ietf.org>
=E6=8A=84=E9=80=81=EF=BC=9A"spring-chairs@ietf.or= g" <spring-chairs@ietf.org>
=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4=EF=BC=9A2021-10-01 22:12:53
<= span style=3D'font-family:=E5=AE=8B=E4=BD=93'>=E4=B8=BB=E9=A2=98=EF=BC=9A[spring] WG= Adoption call forhttps://datatracker.ietf.org/doc/draft-fil= sfilscheng-spring-srv6-srh-compression/

De= ar WG:

 <= /o:p>

The chairs would like to= express their appreciation for all the responses received to our emails wit= h reference to how the working group wishes to move forward with respect to = a solution for SRv6 compression.

 

The apparent inclination of the working group is to use h= ttps://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compress= ion/ as the basis for its compression standardization work. That is part= of what this email attempts to confirm.

 

Because of the above the chairs would like to issue a 2-week WG ca= ll for adoption ending October 15th for https://d= atatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/= but with some clear guidelines as follows. By expressing support for adopti= on of this document you are fully aware of and are acknowledging that: =

 

  1. The SPRING wo= rking group is adopting a document that has multiple SRv6 Endpoint behaviors= .
  2. The document is a =E2=80=9Cliving=E2=80=9D docu= ment; it may change as it goes through review and analysis by the SPRING wor= king group.
  3. All open discussion point= s raised on our mailing list MUST be addressed BEFORE said document is allow= ed to progress from the working group to publication. A list of these discus= sion points will be documented in the WG document and maintained by the docu= ment editor in conjunction with the chairs.
  4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open issu= e be added to the document in the above-described open issues section:<= /o:p>
    • "Given that the working group has said that it w= ants to standardize one data plane solution, and given that the document con= tains multiple SRv6 EndPoint behaviors that some WG members have stated are = multiple data plane solutions, the working group will address whether this i= s valid and coherent with its one data plane solution objective.".=

 <= /o:p>

Please consider the abov= e guidelines as you decide on whether to support or not this WG adoption. Pl= ease express clearly your reasoning for support/non-support as well as any o= pen discussion points you would like addressed should the document be adopte= d into the working group.

 

Thank= s!

 

Jim, Bruno & Joel

 <= /p>

 

--B_3716033094_1595084642-- From nobody Sat Oct 2 04:51:24 2021 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 BA2F23A04BC; Sat, 2 Oct 2021 04:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0eEjB1GrIh4; Sat, 2 Oct 2021 04:51:16 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 EEFE83A041A; Sat, 2 Oct 2021 04:51:15 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id v11so345059pgb.8; Sat, 02 Oct 2021 04:51:15 -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=VSZOkZM454qBTpkrF18ooCnYfJJgg2jQzVejxNEIgQQ=; b=EPDdFPEStnooGMyzfjbqIlDQJi0fTp09K/JEcf7SGPfacTPnZOu/+yExy86mu/xHp/ IylP6KOUwYA7RXsjpwNt6k/pBuoqZ96bRtnsKVorn5Jhk6v6YQUFg8QCzNOUEoa/+7tj lRa6qNddRb8q5D8CqC4uxIdMdUISRVR2PKGLv7sBDzdfLsjdAxsyayiG+uAsQzHy1vYF EerUW5EUcgulETLFUJdtla1JLJFqYtxqavCJJnwhoi5eKnythRqBU20Gufwn7Cg2WgtD Mmy70gmZ2jZCL1czlJn+mrUsrvl9m3kTHTaeIhnuxuS0MyGB1HQ3LknfUv8OjY+4NbIu DWRw== 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=VSZOkZM454qBTpkrF18ooCnYfJJgg2jQzVejxNEIgQQ=; b=fgpiTI8yLnMdE19NVc/q/0Zs5NSyl9u15xMgVBuZji7lSTmm/Y9oeNV6NY+f/j5J8A MaIS+JIht44xsTStdnDRk0+NbtKVDTBCoih7rQ6b1+/q7xlkIfxwMzOfDD2F+/d3jEIH 2FGp4AtHY1JQz+5lmnyu3nNpg7WkydB7xeejIBI72KhFuPo9hOefAFlq20JrolR/9JjB jckkG707taXqMrJZDzwMlzk4zTEZJ4ZVrgn87YD7an/YwYFRdd4nEfTqMxfUDAzIJTqf 6LqjG6EKytr8SDBBQb8X3Q7fUNSZ9LYZK4T/J4ycHiMPTEDAc8Qnwng5oDpJ24bDACjl /Elg== X-Gm-Message-State: AOAM533i7wANVeb/8wiob0VnxfHl2xCH9OMDmDFUb8W+vlCoQz1XrCF/ f12hSrq9eeoKTaU7ZNJMzuCtNbDNj5CtyYl7nxs+QtoS X-Google-Smtp-Source: ABdhPJw20XqyVUzFqRCEji4B/50ktHb7t+uoYkS15lNejFjKbCn+74MNpc0WlMvw1M/wgoDXjkeGTKG1sxXtBTm/qSE= X-Received: by 2002:aa7:9a51:0:b0:43d:f0b0:532a with SMTP id x17-20020aa79a51000000b0043df0b0532amr14944693pfj.76.1633175474988; Sat, 02 Oct 2021 04:51:14 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Sat, 2 Oct 2021 07:51:04 -0400 Message-ID: To: "Darren Dukes (ddukes)" Cc: SPRING WG , "srcomp@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000ae8c505cd5d4c91" Archived-At: Subject: Re: [spring] [srcomp] compression analysis draft question on proposals analyzed 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, 02 Oct 2021 11:51:21 -0000 --0000000000000ae8c505cd5d4c91 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Darren! On Mon, Sep 27, 2021 at 1:23 PM Darren Dukes (ddukes) wrote: > Was: Re: [spring] > draft-filsfilscheng-spring-srv6-srh-compression-02#section-4.1.1 > > > > I=E2=80=99m sending this note to redirect this question to the srcomp DT = for an > editorial fix, when the team meets next. > > > > For the DT: > > Each proposal, introduced in section 1, discusses how it supports 16-bit > and 32-bit SIDs. However, Gyan=E2=80=99s question indicates this could be= more > clearly stated in the analysis draft to help readers less familiar with a > proposal. As such, section 1 can be improved accordingly. > > > > Darren > > > > On 2021-09-24, 1:32 PM, "spring" wrote: > > > > Gyan, > > > > You raise a very good point. In the analysis document, Tables 1 through 6 > and Tables 12 through 15 each contain only one column for the CSID. They = do > not indicate whether the number in that column were calculated using the > NEXT-C-SID, REPLACE-C-SID, or NEXT-AND-REPLACE-C-SID. (That is, the do no= t > indicate whether they were calculated using uSID, G-SID, or a combination > of both). > > > > Each of these tables should be modified, so that the CSID column is > replaced by three columns (NEXT-C-SID, REPLACE-C-SID, and > NEXT-AND-REPLACE-C-SID). > > > > If the numbers in these columns are different from one another, this may > inform our discussion about whether NEXT-C-SID, REPLACE-C-SID, and > NEXT-AND-REPLACE-C-SID are different behaviors or different flavors of a > behavior. > > > > > Ron > > > > > > > > Juniper Business Use Only > > *From:* spring *On Behalf Of *Gyan Mishra > *Sent:* Friday, September 24, 2021 9:56 AM > *To:* SPRING WG ; > draft-filsfilscheng-spring-srv6-srh-compression@ietf.org; > spring-chairs@ietf.org > *Subject:* Re: [spring] > draft-filsfilscheng-spring-srv6-srh-compression-02#section-4.1.1 > > > > *[External Email. Be cautious of content]* > > > > Dear Spring Authors > > > > Please respond to this question the WG has related to which of the three > SRv6 forwarding mechanisms called flavors was inclusive of the compressi= on > analysis draft. > > > > The Analysis draft is ambiguous as to which SRv6 forwarding plane flavor > was part of the analysis. > > > > This is a critical question that has come up by the WG and Chairs, and > answering this question will help pave the way to an adoption call for > C-SID. > > > > Kind Regards > > > > Gyan > > > > On Sun, Sep 19, 2021 at 3:33 PM Gyan Mishra wrote= : > > Dear Authors > > > > After having a few discussions on threads related to the SRv6 compression > analysis draft results, as well as WG coming to consensus on a single SRv= 6 > compression solution, a few critical questions have come up related to > C-SID draft that requires clarification by the authors. > > > > The C-SID draft has 3 compression solutions below and is a combination of > the two drafts below which introduces 2 of the 3 compression solutions wi= th > the C-SID draft introduction of yet a 3rd compression solution. > > > > Which of the 3 C-SID draft compression solutions was included as part of > the DT analysis draft results and conclusion? > > > > This is a critical question that needs to be answered for clarification o= n > the C-SID draft solution. > > > > As the WG has consensus on a single solution we need to have clarificatio= n > from the authors which of the 3 compression solutions was included in the > analysis. > > > > The three solutions are very different and all would yield different > analysis results. > > > > I understand the authors have called the each solution a endpoint flavor > which I see from the IANA codepoint allocations, however each flavor is a > different solution. > > > > https://www.iana.org/assignments/segment-routing/segment-routing.xhtml > > > > > So the WG as stated would like a single solution so now we need feedback > from the authors which of the three solutions or endpoint flavors was par= t > of the DT analysis draft that the authors would like to put forward as th= e > single compression solution. > > > > C-SID is a combination of the two drafts below: > > > > Combination of the two drafts below: > > > > G-SID - Generalized SID =E2=80=9CREPLACE-C-SID=E2=80=9D > > > https://datatracker.ietf.org/doc/html/draft-cl-spring-generalized-srv6-fo= r-cmpr-03 > > > > > SRv6 uSID micro-segment =E2=80=9C NEXT-C-SID=E2=80=9D > > > https://datatracker.ietf.org/doc/html/draft-filsfils-spring-net-pgm-exten= sion-srv6-usid-10 > > > > > Kind Regards > > > > > > Gyan > > -- > > > > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com * > > *M 301 502-1347* > > > > -- > > > > > *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 > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --0000000000000ae8c505cd5d4c91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Thanks Darren!

On Mon, Sep 27, 2021 at= 1:23 PM Darren Dukes (ddukes) <ddukes=3D40cisco.com@dmarc.ietf.org> wrote:

Was: Re: [spring] draft-filsfil= scheng-spring-srv6-srh-compression-02#section-4.1.1

=C2=A0

I=E2=80=99m sending this note t= o redirect this question to the srcomp DT for an editorial fix, when the te= am meets next.

=C2=A0

For the DT:

Each proposal, introduced in se= ction 1, discusses how it supports 16-bit and 32-bit SIDs. However, Gyan=E2= =80=99s question indicates this could be more clearly stated in the analysi= s draft to help readers less familiar with a proposal.=C2=A0 As such, section 1 can be improved accordingly.<= /u>

=C2=A0

Darren

=C2=A0

On 2021-09-24, 1:32 PM,= "spring" <spring-bounces@ietf.org> wrote:

=C2=A0

Gyan,

=C2=A0

You raise a very good point. In the analysis docum= ent, Tables 1 through 6 and Tables 12 through 15 each contain only one colu= mn for the CSID. They do not indicate whether the number in that column were calculated using the NEXT-C-SID, REPLACE-C-= SID, or NEXT-AND-REPLACE-C-SID. (That is, the do not indicate whether they = were calculated using uSID, G-SID, or a combination of both).=

=C2=A0

Each of these tables should be modified, so that t= he CSID column is replaced by three columns (NEXT-C-SID, REPLACE-C-SID, and= NEXT-AND-REPLACE-C-SID).

=C2=A0

If the numbers in these columns are different from= one another, this may inform our discussion about whether NEXT-C-SID, REPL= ACE-C-SID, and NEXT-AND-REPLACE-C-SID are different behaviors or different flavors of a behavior.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ron

=C2=A0

=C2=A0

=C2=A0

Juniper Business= Use Only

From: spring <spring-bounces@ietf.org> On Behalf Of Gyan Mishra
Sent: Friday, September 24, 2021 9:56 AM
To: SPRING WG <spring@ietf.org>; draft-filsfilscheng-spring-s= rv6-srh-compression@ietf.org; spring-chairs@ietf.org
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compressio= n-02#section-4.1.1

=C2=A0

[External Email. Be cautious of content]=

=C2=A0

De= ar Spring Authors=C2=A0

=C2=A0

Pl= ease respond to this question the WG has related to which of the three SRv6= forwarding mechanisms called =C2=A0flavors was inclusive of the compressio= n analysis draft.

=C2=A0

Th= e Analysis draft is ambiguous as to which SRv6 forwarding plane flavor was = part of the analysis.

=C2=A0

Th= is is a critical question that has come up by the WG and Chairs, and answer= ing this question will help pave the way to an adoption call for C-SID. =C2= =A0

=C2=A0

Ki= nd Regards=C2=A0

=C2=A0

Gy= an

=C2=A0

On= Sun, Sep 19, 2021 at 3:33 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

De= ar Authors

=C2=A0

Af= ter having a few discussions on threads related to the SRv6 compression ana= lysis draft results, as well as WG coming to consensus on a single SRv6 com= pression solution, a few critical questions have come up related to C-SID draft that requires clarification by the aut= hors.

=C2=A0

Th= e C-SID draft has 3 compression solutions below and is a combination of the= two drafts below which introduces 2 of the 3 compression solutions with th= e =C2=A0C-SID draft introduction of yet a 3rd compression solution.

=C2=A0

Wh= ich of the 3 C-SID draft compression solutions was included as part of the = DT analysis draft results and conclusion?

=C2=A0

Th= is is a critical question that needs to be answered for clarification on th= e C-SID draft solution.

=C2=A0

As= the WG has consensus on a single solution we need to have clarification fr= om the authors which of the 3 compression solutions was included in the ana= lysis. =C2=A0

=C2=A0

Th= e three solutions are very different and all would yield different analysis= results.

=C2=A0

I = understand the authors have called the each solution a endpoint flavor whic= h I see from the IANA codepoint allocations, however each flavor is a diffe= rent solution. =C2=A0

=C2=A0

https://www.iana.= org/assignments/segment-routing/segment-routing.xhtml

=C2=A0

So= the WG as stated would like a single solution so now we need feedback from= the authors which of the three solutions or endpoint flavors was part of t= he DT analysis draft that the authors would like to put forward as the single compression solution.

=C2=A0

C-SID is a combi= nation of the two drafts below:

=C2=A0=

Combination of t= he two drafts below:

=C2=A0=

G-SID - Generali= zed SID =E2=80=9CREPLACE-C-SID=E2=80=9D

=C2=A0=

SRv6 uSID micro-= segment =E2=80=9C= =C2=A0NEXT-C-SID=E2=80=9D

=C2=A0=

Kind Regards=C2= =A0

=C2=A0=

=C2=A0

Gy= an

--=

=

Gyan Mishra

Network Solutions Architect=C2=A0

Email gyan.s.mishr= a@verizon.com

M 301 502-1347

=C2=A0

--=

=

Gyan Mishra

Network Solutions Architect=C2=A0

Email gyan.s.mishr= a@verizon.com

M 301 502-1347

=C2=A0

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--
--0000000000000ae8c505cd5d4c91-- From nobody Sat Oct 2 06:39:25 2021 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 43BD73A0C59 for ; Sat, 2 Oct 2021 06:39:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=hpdYyz16; dkim=pass (1024-bit key) header.d=juniper.net header.b=RbH29CAo 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 GIaxrcgGQ09T for ; Sat, 2 Oct 2021 06:39:18 -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 5EA513A0C57 for ; Sat, 2 Oct 2021 06:39:18 -0700 (PDT) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 192BkZCv008502; Sat, 2 Oct 2021 06:39:17 -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=RRzX209wMDqQhHf7BAGEqwRSriOTDxISmnp3YvphmAE=; b=hpdYyz16qQzHh6hpBHMaE7SMG1ZljMzAMuAXVjyOelpxOdDIW7ijgJHH9JL+ODPCU8A8 MC4oMfzxOHIvCzjXPfcfYs3HKvTsnx8BQ91SUReMxC06nFJHtMmRvnF7oBfv8Fw5EBCC g8OaDhPM5tFRdd71g6lInNSfr52r60n6bshSSj6BAbjyoprRu8LmueY0OMVzJ7QFsz5f IzEtUixODZ207n+aG58o4muGVD5lI/q4aDJkA4T9u2KH9bad6OMCRAmJDKAarTqIm0Dy FqXTjWOPBVSdDOn1UYsCP5KmK9A1f6VflkS3In5/YMGwmZa4F4tMZaIPOeTqqv9EcU/C Ww== Received: from nam04-bn8-obe.outbound.protection.outlook.com (mail-bn8nam08lp2040.outbound.protection.outlook.com [104.47.74.40]) by mx0b-00273201.pphosted.com with ESMTP id 3bep02g4y9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 02 Oct 2021 06:39:17 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ljd0w4wiw0P2sUMdUGYgBKrdEIhJcEQ22DCELBOjEudHu4jmXSPWjUq1RNNJ+scxTMAnX3ZRaoF1A51UkEf7Q9aZk6svgdw3jg3PFLIam38ZuMQC605JY09LuJDwnbtER4m7PqhJdPEVsj2+02GDBaucs+UaJzcbWLOMBl6U6J99fuL8g9se+jedIbOGrbw9DCXwdvEy+beE0zAl8qNkMj05gkP6qyjfPhQvYF6XEcgp7vcOGTA246FOd+ngbSWLqf7rc46K4iw37Z9eWztz4DjzC85SCbSXWhPTxsQ/QCayBRT+XGi2gGBZ2ayCOtwjSppFQX52hg7xVhb1mPRQbg== 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=RRzX209wMDqQhHf7BAGEqwRSriOTDxISmnp3YvphmAE=; b=U6VXvEY4k/HgwAh1SA++3P+lkda5ZXn6laS9/KKAvGzAkL+0bpmhcMvx0I8OvprD2EddcicYrGXSA6tOFHruRR59vXJziZSiBQ4hK5H/OJPoxlXdI8N3LefE7mTXBmpIyTmWLjoPpQlQGu/V2ohCnNNno0vEpfp/sHnhnT7Kc9wvhEpQ9VQoTx+Z2T7q5MjCTrE79M1pqV1qR8o5i0N9tsXkJtKGAqhmKVY5/gSXmiyLnNe5R9Sa54itppQctecMJMUoeBpu8HSmrz3PCvZKz5emX+VsCYpF5jG/QwUfMb9J8l31StBzpisgfWttHLSSwcXRQKw+SLHH0BiW4ZjI+g== 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=RRzX209wMDqQhHf7BAGEqwRSriOTDxISmnp3YvphmAE=; b=RbH29CAoXQkvpqHUzBilwI/E9X+fZdE/YPNjkw1h9Wh8eNG9C96S8RQQgqDpZs4hblM2/+fgmC61iCOMIJXV9bD6hQaxaJ8XbvMC+wrgbx3GavmISs9wAnyBSGRIUD+o/qtOXtVUQI0bjRXwHL7DiZVTNPUynjSEYSxGUSqRZ8E= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by MN2PR05MB7117.namprd05.prod.outlook.com (2603:10b6:208:18d::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.11; Sat, 2 Oct 2021 13:39:15 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4587.009; Sat, 2 Oct 2021 13:39:14 +0000 From: Ron Bonica To: Robert Raszuk CC: SPRING WG Thread-Topic: [spring] CSID Question Thread-Index: Ade2+c1KozTuOJAoRFyi9icelIkpNwACYe+AAAAh62AAASeMAAAimjWa Date: Sat, 2 Oct 2021 13:39:14 +0000 Message-ID: <5449C581-4F7F-4C49-BE77-072802E4FF05@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0476948d-7346-484f-fa1e-08d985aa0677 x-ms-traffictypediagnostic: MN2PR05MB7117: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zz6q4hHxoHKJoSwvW/IUt0eL0WebOjZBmMpupvMfJY9pd49RfAHPyZiMwpiuMIoc3RxRA5H/TatiaaXaaN0CDaHWH84KKTmsHUvpHWoYoaHWbXuXbRtgnDCbdAqv+PogIInhc6vE+IZqokz6WirQ76pZCPT0GWqCNZrPybZWEU7NX5inClKlTIx8I5K3fH0JHQwSeuIz5rjXD0m30phB0gp1KGwbm4ZLpRmCkyk+pCE93yXe+Q4mifmyEeNMiP0r0vS83iwq+i4cV36cS6SSkdeMj/XTEZtMi2PGGO1Zo7BhB/V9B57zyWXRi+mHtMBLzx2ulIVTqf+rCfq+fJk26/LN/i8KoZxt0Kx6AYtMeEvY9+KLUItJgU95hvePFBJFcEz42PPXIl44D1WJ1S53t63MLxvphQDYmO29yYzvw2y0qSB73qg7Lco6WB5idEy/cDdbHabuxOrIQhbjpo18GjhzhqxL/wg1AWCTuYttCN4RU73PAV+xGZNUxnDba7xTGAUgNRPUYJgkiRKa3JJX/FNLwwk7gIRfAL45Je8CDG6kh77wgC30aNIgzWw9rhXeW65t5Kn8889WUiMpeg3st2FWVErpgfMqHFCl06DHxuShD4f5M4dG5mdtn4TdVcWX0eU59mz978zZWECCd0ufX6LnIl5lFhCueoeH/tj3/E7UGUfLrEfajeW26UQ0IiMFMGXrdZy+rgvxdCihib0aBMD/SN/7ylrw/lw4kj2UxGD4a9+htNLjZJ3ojZDWjWMYXbp1zab+y5EDo2kvnomOWH4k7fo9/6DzTOH2RqqTJes+UYf2+jew6V8gJ+pvZdOA x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(508600001)(4326008)(966005)(36756003)(6916009)(26005)(8676002)(186003)(8936002)(6506007)(6512007)(53546011)(6486002)(316002)(71200400001)(122000001)(66946007)(76116006)(38100700002)(66446008)(166002)(2906002)(66476007)(66556008)(64756008)(86362001)(2616005)(33656002)(5660300002)(38070700005)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MjRJeUhGZXNyYTNCbVFXMmJNRmhGVjZYdC9POGd6VTVkanNFWkNpbXd2NVkx?= =?utf-8?B?M1dZV0YvNjFoWnJKbDk0YVZGNVpCMFRneDJaT0o1R3lscUUyNlV1MFNnRGpC?= =?utf-8?B?NHFOcExrUElsNDRSMkI2emhUNGpPOEtFUTVXSHkzRGN6VEp6ckQ0NC9rbEg4?= =?utf-8?B?eW02aVdZNzhCNW5xQ2ZiOC9WZ281ZGx4eGplUThCbncrdWFVdFpPSG1hbjRB?= =?utf-8?B?aTNVNmhsVHBuNGtRcFVYM0g3WTdFZ2ZzTG9QSEtrSS9GMEM1N0VmWGo3STdo?= =?utf-8?B?elhuMUZuL2wybXRLN1JBSWZVeE1lQVNpamJSTFU0b0Q4MXNNM3JSOHFZQTdI?= =?utf-8?B?bFhFdTBzVk5tZ2RFVE4xREhUMU1HZDFZYkNOd0VGMnp1dGpqOHo0MEo1RmxE?= =?utf-8?B?SkhhUS90RUk4eDNEOCtseTM5aGI2MmorUXJTMEF2QkVsTkFwQm5YUVZMdjNl?= =?utf-8?B?TUkzdFhjcmlwZ0IwcXVVMCtHMll2a3kxbEdtVlBXWDRuM3VvVW9NNGRnM1Zw?= =?utf-8?B?SGxPaDJySWJHMG1wV3dBODFCQkdXODl2M05ORHoycm02TG5qQUdPZ3Bjd0Iy?= =?utf-8?B?elZzMytUMGFQMGRtS0RFUVZMOEdoWXp2Rk5MTTF6RFdTYjVreTVMWStQWXc5?= =?utf-8?B?djRqZTlBejhWdVZrZS9QRlZ0VnlUazV6bEpUL3pPSjlzVHJ0L2llT2Jha3h6?= =?utf-8?B?WXh5KytZazlWRStnMXU2UUFWdTdlMXp4cE9VR3dPSDFLWHcvbzlna0dUZ1dS?= =?utf-8?B?N1NKWXlvTUtDbFFnWHB4dEYwY3UreHlGYWFqWFViOFk2RU5ncGNYcyt5bnpy?= =?utf-8?B?dHB6cm5lcTBGblhLb0lKRmFlOUtoVVovZlJoY25PTlgzN1FRVHlqbEVNR1JG?= =?utf-8?B?NmlxSjhZOVhwaGU0dXJRRE01aldxaGpxRnBOaHVWZ2lmWmZ4Yi81TWRCSDZ3?= =?utf-8?B?SHo1a2lOa2QrVXN2NDl4Tmc3dDlhaDlOM0dLLyszaTBDYVkxK2RyYU9LZ08w?= =?utf-8?B?ZzB2QkVMMm5MQlVRenFSSTN5T2pib2M0N3FQMFMrcGhxcEY5ZmhWUnBzQVZY?= =?utf-8?B?U0VxY3BRS0R3T2huRzZwTnVibENpNmhXMWVFb2FzSXVoK1B5Uit1akI2bkJv?= =?utf-8?B?K1JEMm8vM2owV1hWclFtZ3YyVFF1em1yMUJQQ2UyNFpyTVJUeW1OSHBST2JT?= =?utf-8?B?UWdieStGN0szRVk1MjZoZHhrVjZWZzlQcXJ0Q25hT3l6bVMwamxqU2krKzJa?= =?utf-8?B?SFdmaVRLNUNHWWl1aDJwcUZhUW1QcVFRdHJKZldXWHJQZzltRUR0L2VIdnZ2?= =?utf-8?B?U2dZdFc2a1JUYy9DbHBmYjUyc2wrWks5MVVSSHRJeUl5c1c4N3BlN3JLVHJh?= =?utf-8?B?eGpGWkZyR1M4UlVrOEVwTSt5emxPSHdWbGw5bGYvYjF0Z1hwTXRIOE1HSmFJ?= =?utf-8?B?U0VjYjlyelUwV0JGUzFzVStoblN0aGc2Rmp6QjFhcVhwRU9sR2Y0blE2Yjgx?= =?utf-8?B?bnJCcnBiblYzV2I2NnFHcThwdlhRd25tTGRrcUdSeEhhTUpyZU5WZTVKQ0V0?= =?utf-8?B?UVN2Y1BobXBSWGh1VWZ6UXpnSngzU1JzRWxjQmVuallSWm1MREVDSHRpUmRK?= =?utf-8?B?cG9CSElEc0taU095L1dDWG82c3ZUN3FQNUpJSXVoTjlHbWo3TEIva0V2Z2c1?= =?utf-8?B?KzFMOEtWWjE4UVFXd0twOVU3Qlk0ODZ1NHJtcG9odXVtNGszSW9YRkFDelZR?= =?utf-8?Q?X2dYMemVM6eXRbnRIXVVBw3JiqfutFXf07vLt3h?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_5449C5814F7F4C49BE77072802E4FF05junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0476948d-7346-484f-fa1e-08d985aa0677 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2021 13:39:14.7287 (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: eSdPNcdTtBavx7Ue0Ht33daTJ303t21D/GzQujI+/GpkiSREulP56sR53ttjiTkmAep7JCE6VQpqMLWAQJ111A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB7117 X-Proofpoint-GUID: yxSdoBAU_Sg0PnbV0oEnSxljKri_VH-Y X-Proofpoint-ORIG-GUID: yxSdoBAU_Sg0PnbV0oEnSxljKri_VH-Y X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-02_04,2021-10-01_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1011 mlxlogscore=999 spamscore=0 bulkscore=0 malwarescore=0 impostorscore=0 mlxscore=0 priorityscore=1501 suspectscore=0 phishscore=0 adultscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110020101 Archived-At: Subject: Re: [spring] CSID Question 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, 02 Oct 2021 13:39:24 -0000 --_000_5449C5814F7F4C49BE77072802E4FF05junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Rm9sa3MsDQoNCk5vdyB0aGF0IFJvYmVydCBhbmQgSSBoYXZlIHByb3ZpZGVkIHNvbWUgZW50ZXJ0 YWlubWVudCwgY291bGQgc29tZW9uZSBhbnN3ZXIgdGhlIHRlY2huaWNhbCBxdWVzdGlvbiB0aGF0 IGluaXRpYXRlZCB0aGlzIHRocmVhZD8NCg0KRG9lcyB0aGUgZG9jdW1lbnQgcmVjb21tZW5kIGFn YWluc3QgdXNpbmcgTmV4dC1DLVNJZCBhbmQgUmVwbGFjZS1DLVNpZCBpbiB0aGUgc2FtZSBkb21h aW4gIGZvciBlYXNlIG9mIG9wZXJhdGlvbiBvciBiZWNhdXNlIHRoZXkgZG9u4oCZdCB3b3JrIHdl bGwgdG9nZXRoZXI/IElmIHRoZSBmb3JtZXIsIHBsZWFzZSBwcm92aWRlIHRoZSBleGFtcGxlIGRl c2NyaWJlZCBiZWxvdy4NCg0KICAgICAgICAgICAgICBSb24NCg0KDQoNClNlbnQgZnJvbSBteSBp UGhvbmUNCg0KT24gT2N0IDEsIDIwMjEsIGF0IDU6MDcgUE0sIFJvYmVydCBSYXN6dWsgPHJvYmVy dEByYXN6dWsubmV0PiB3cm90ZToNCg0K77u/DQoNCltFeHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlv dXMgb2YgY29udGVudF0NCg0KDQpIaSBSb24sDQoNCg0KICAqICAgQ2FuIHdlIHNheSB0aGF0IHRo ZXkgYXJlIGEgc2luZ2xlIGJlaGF2aW9yID8NCg0KTm8uIEFuZCBuZWl0aGVyIFJGQzg5ODYgZGVm aW5lcyBhIHNpbmdsZSBiZWhhdmlvciBvciBzaW5nbGUgZmxhdm9yLiBZZXQgdGhlIGJvdW5kcyBh cmUgY2xlYXJseSBzZXQgd2hhdCBpcyB0aGUgU1J2NiBkYXRhIHBsYW5lLg0KDQpGb3Igc29tZSBz dHJhbmdlIHJlYXNvbiBJIGFtIG9ic2VydmluZyBoZXJlIGFuIGF0dGVtcHQgdG8gc3F1ZWV6ZSBk aWZmZXJlbnQgZGF0YSBwbGFuZSBpbnRvIHRoZSByb29tIHdoaWNoIGlzIG5vdCBjb21wbGlhbnQg dG8gW1JGQzg0MDJdLCBbUkZDODc1NF0gYW5kIFtSRkM4OTg2XS4gRG8geW91IHRoaW5rIGFueW9u ZSB3aWxsIGJlIHNvIG5haXZlIHRvIGFjY2VwdCBpdCA/DQoNCk5vdyBJIGFtIGdvaW5nIHRvIHJl c3QgYXNzdXJlZCBhbmQgZW5qb3kgdGhlIHJlc3Qgb2YgdGhpcyBzaG93Lg0KDQpCZXN0LA0KUm9i ZXJ0DQoNCg0KT24gRnJpLCBPY3QgMSwgMjAyMSBhdCAxMDo1OCBQTSBSb24gQm9uaWNhIDxyYm9u aWNhQGp1bmlwZXIubmV0PG1haWx0bzpyYm9uaWNhQGp1bmlwZXIubmV0Pj4gd3JvdGU6DQpSb2Jl cnQsDQoNCkkgZG8gcmVtZW1iZXIgdGhhdCBxdW90ZS4gQW5kIHRoYXQgaXMgZXhhY3RseSB3aHkg SSBhc2sgdGhlIHF1ZXN0aW9uIQ0KDQpJZiBORVhULUMtU0lEIGFuZCBSRVBMQUNFLUMtU0lEIGFy ZSBpbmNvbXBhdGlibGUgd2l0aGluIGEgZG9tYWluOg0KDQoNCiAgKiAgIENhbiB3ZSBzYXkgdGhh dCB0aGV5IGFyZSBhIHNpbmdsZSBiZWhhdmlvciA/DQogICogICBDYW4gd2UganVzdGlmeSBib3Ro IGJlY2F1c2UgZWFjaCBpcyBvcHRpbWl6ZWQgZm9yIGEgZGlmZmVyZW50IGtpbmQgb2YgbmV0d29y az8NCiAgKiAgIENhbiB3ZSBqdXN0aWZ5IGFub3RoZXIgYmVoYXZpb3IgZWl0aGVyIGJlY2F1c2Ug aXQgaXMgb3B0aW1pemVkIGZvciB5ZXQgYW5vdGhlciB0eXBlIG9mIG5ldHdvcmsgb3IgYmVjYXVz ZSBpdCBkb2VzIHJlbGF0aXZlbHkgd2VsbCBpbiBhbGwgbmV0d29yayB0eXBlcz8NCg0KSG93ZXZl ciwgaWYgdGhpcyBpcyBqdXN0IGFuIOKAnGVhc2Ugb2Ygb3BlcmF0aW9u4oCdIHRoaW5nLCBhcyBz dGF0ZWQgaW4gdGhlIGRyYWZ0LCB0aGUgYXV0aG9ycyBhcmUgb2JsaWdlZCB0byBhbnN3ZXIgbXkg cXVlc3Rpb24uDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb24N Cg0KUC5TLiBSZXN0IGFzc3VyZWQgdGhhdCBJIGhhdmUgcmVhZCB0aGUgZHJhZnQuIEhvd2V2ZXIs IHlvdXIgY29uY2VybiBpcyBncmVhdGx5IGFwcHJlY2lhdGVkIPCfmIkNCg0KDQoNCg0KSnVuaXBl ciBCdXNpbmVzcyBVc2UgT25seQ0KRnJvbTogUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5u ZXQ8bWFpbHRvOnJvYmVydEByYXN6dWsubmV0Pj4NClNlbnQ6IEZyaWRheSwgT2N0b2JlciAxLCAy MDIxIDQ6MzIgUE0NClRvOiBSb24gQm9uaWNhIDxyYm9uaWNhQGp1bmlwZXIubmV0PG1haWx0bzpy Ym9uaWNhQGp1bmlwZXIubmV0Pj4NCkNjOiBTUFJJTkcgV0cgPHNwcmluZ0BpZXRmLm9yZzxtYWls dG86c3ByaW5nQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBDU0lEIFF1ZXN0aW9u DQoNCltFeHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF0NCg0KSGkgUm9uLA0K DQpIYXZlIHlvdSByZWFkIHRoaXMgZHJhZnQgPw0KDQpRdW90ZSBmcm9tIGl0Og0KDQoNCiAgIEl0 IGlzIHJlY29tbWVuZGVkIGZvciBlYXNlIG9mIG9wZXJhdGlvbiB0aGF0IGEgc2luZ2xlIGNvbXBy ZXNzZWQNCg0KICAgZW5jb2RpbmcgZmxhdm9yIGJlIHVzZWQgaW4gYSBnaXZlbiBTUnY2IGRvbWFp bi4gIEhvd2V2ZXIsIGluIGEgbXVsdGktDQoNCiAgIGRvbWFpbiBkZXBsb3ltZW50LCBkaWZmZXJl bnQgZmxhdm9ycyBjYW4gYmUgdXNlZCBpbiBkaWZmZXJlbnQNCg0KICAgZG9tYWlucy4NCg0KT24g RnJpLCBPY3QgMSwgMjAyMSBhdCA5OjMzIFBNIFJvbiBCb25pY2EgPHJib25pY2E9NDBqdW5pcGVy Lm5ldEBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZz4+ IHdyb3RlOg0KQ1NJRCBBdXRob3JzLA0KDQpBc3N1bWUgdGhhdCBhbiBTUiBwYXRoIGNvbnRhaW5z IHNlZ21lbnRzIDEgdGhyb3VnaCA4LiBTZWdtZW50cyAxLCAzLCA1LCBhbmQgNyBhcmUgRU5EIFNJ RHMgdGhhdCB1c2UgTmV4dC1DLVNJRCAoaS5lLiwgdVNJRCkuIFNlZ21lbnRzIDIsIDQsIGFuZCA2 IGFyZSBFTkQgU0lEcyB0aGF0IHVzZSBSZXBsYWNlLUMtU0lELiBTZWdtZW50IDggaXMgYW5kIEVO RC5EWDQgU0lELg0KDQpQbGVhc2UgcHJvdmlkZSBhbiBleGFtcGxlIHRoYXQgc2hvd3MgdXM6DQoN Cg0KICAqICAgV2hhdCB0aGUgU1JIIGxvb2tzIGxpa2UgYXMgaXQgYXJyaXZlcyBhdCB0aGUgZmly c3Qgc2VnbWVudCBlbmRwb2ludA0KICAqICAgV2hhdCB0aGUgSVB2NiBEZXN0aW5hdGlvbiBBZGRy ZXNzIGxvb2tzIGxpa2UgYXQgZWFjaCBzZWdtZW50IGVuZHBvaW50LCBpbmNsdWRpbmcgaW5mb3Jt YXRpb24gcmVxdWlyZWQgdG8gcGFyc2UgdGhlIERlc3RpbmF0aW9uIEFkZHJlc3MNCg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbg0K DQoNCg0KSnVuaXBlciBCdXNpbmVzcyBVc2UgT25seQ0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRm Lm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9zcHJpbmc8aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmdfXzshIU5FdDZ5TWFPLWdrIVVMX0xzVEVX dXlidGV3Y0lIWDJGd3JxdHdTM0c5N2tpM3R6SFQ4cEd5R2N4MmhQV1laZnJpU21lRzc1dXdQN2wk Pg0K --_000_5449C5814F7F4C49BE77072802E4FF05junipernet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpG b2xrcywNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk5vdyB0aGF0IFJvYmVydCBhbmQgSSBoYXZl IHByb3ZpZGVkIHNvbWUgZW50ZXJ0YWlubWVudCwgY291bGQgc29tZW9uZSBhbnN3ZXIgdGhlIHRl Y2huaWNhbCBxdWVzdGlvbiB0aGF0IGluaXRpYXRlZCB0aGlzIHRocmVhZD88L2Rpdj4NCjxkaXY+ PGJyPg0KPC9kaXY+DQo8ZGl2PkRvZXMgdGhlIGRvY3VtZW50IHJlY29tbWVuZCBhZ2FpbnN0IHVz aW5nIE5leHQtQy1TSWQgYW5kIFJlcGxhY2UtQy1TaWQgaW4gdGhlIHNhbWUgZG9tYWluICZuYnNw O2ZvciBlYXNlIG9mIG9wZXJhdGlvbiBvciBiZWNhdXNlIHRoZXkgZG9u4oCZdCB3b3JrIHdlbGwg dG9nZXRoZXI/IElmIHRoZSBmb3JtZXIsIHBsZWFzZSBwcm92aWRlIHRoZSBleGFtcGxlIGRlc2Ny aWJlZCBiZWxvdy48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBSb248L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOzxicj4NCjxicj4NCjxkaXYgZGlyPSJsdHIiPlNlbnQgZnJvbSBteSBpUGhvbmU8 L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPk9uIE9j dCAxLCAyMDIxLCBhdCA1OjA3IFBNLCBSb2JlcnQgUmFzenVrICZsdDtyb2JlcnRAcmFzenVrLm5l dCZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPu+7vw0KPHA+PC9wPg0KPGRpdiBzdHlsZT0i YmFja2dyb3VuZC1jb2xvcjojRkZFQjlDOyB3aWR0aDoxMDAlOyBib3JkZXItc3R5bGU6IG5vbmU7 IGJvcmRlci1jb2xvcjojOUM2NTAwOyBib3JkZXItd2lkdGg6MXB0OyBwYWRkaW5nOjJwdDsgZm9u dC1zaXplOjEwLjVwdDsgbGluZS1oZWlnaHQ6MTJwdDsgZm9udC1mYW1pbHk6J0xhdG8nOyBjb2xv cjpibGFjazsgdGV4dC1hbGlnbjogbGVmdDsgZm9udC13ZWlnaHQ6Ym9sZCI+DQo8c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siIDs9IiIgZm9udC13ZWlnaHQ6Ym9sZDs9IiI+W0V4dGVybmFsIEVtYWls LiBCZSBjYXV0aW91cyBvZiBjb250ZW50XTwvc3Bhbj48L2Rpdj4NCjxicj4NCjxwPjwvcD4NCjxk aXY+DQo8ZGl2IGRpcj0ibHRyIj4NCjxkaXY+SGkgUm9uLDxicj4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyIgc3R5bGU9Im1hcmdpbi1ib3R0b206MGlu O21hcmdpbi10b3A6MGluIj4NCjxsaSBzdHlsZT0ibWFyZ2luOjBpbjtmb250LXNpemU6MTFwdDtm b250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTRw dCI+Q2FuIHdlIHNheSB0aGF0IHRoZXkgYXJlIGEgc2luZ2xlIGJlaGF2aW9yID88L3NwYW4+PC9s aT48L3VsPg0KPGRpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk5vLiBBbmQgbmVpdGhlciBS RkM4OTg2IGRlZmluZXMgYSBzaW5nbGUgYmVoYXZpb3Igb3Igc2luZ2xlIGZsYXZvci4gWWV0IHRo ZSBib3VuZHMgYXJlIGNsZWFybHkmbmJzcDtzZXQgd2hhdCBpcyB0aGUgU1J2NiBkYXRhIHBsYW5l LiZuYnNwOzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkZv ciBzb21lIHN0cmFuZ2UmbmJzcDtyZWFzb24gSSBhbSBvYnNlcnZpbmcgaGVyZSBhbiBhdHRlbXB0 IHRvIHNxdWVlemUgZGlmZmVyZW50IGRhdGEgcGxhbmUgaW50byB0aGUgcm9vbSB3aGljaCBpcyBu b3QgY29tcGxpYW50Jm5ic3A7dG8gW1JGQzg0MDJdLCBbUkZDODc1NF0gYW5kIFtSRkM4OTg2XS4g RG8geW91IHRoaW5rIGFueW9uZSB3aWxsIGJlIHNvIG5haXZlIHRvIGFjY2VwdCBpdCA/Jm5ic3A7 PGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Ob3cgSSBhbSBnb2luZyZuYnNw O3RvIHJlc3QgYXNzdXJlZCBhbmQgZW5qb3kgdGhlJm5ic3A7cmVzdCBvZiB0aGlzIHNob3cuJm5i c3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5CZXN0LDwvZGl2Pg0KPGRpdj5Sb2Jl cnQ8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4NCjxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBGcmksIE9j dCAxLCAyMDIxIGF0IDEwOjU4IFBNIFJvbiBCb25pY2EgJmx0OzxhIGhyZWY9Im1haWx0bzpyYm9u aWNhQGp1bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+cmJvbmljYUBqdW5pcGVyLm5ldDwvYT4m Z3Q7IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBz dHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2Io MjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBsYW5nPSJFTi1VUyI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB0Ij5Sb2Jl cnQsPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxNHB0Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0cHQiPkkgZG8gcmVt ZW1iZXIgdGhhdCBxdW90ZS4gQW5kIHRoYXQgaXMgZXhhY3RseSB3aHkgSSBhc2sgdGhlIHF1ZXN0 aW9uITx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTRwdCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB0Ij5JZiBORVhU LUMtU0lEIGFuZCBSRVBMQUNFLUMtU0lEIGFyZSBpbmNvbXBhdGlibGUgd2l0aGluIGEgZG9tYWlu Ojx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTRwdCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHVs IHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgc3R5bGU9Im1hcmdpbi1s ZWZ0OjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB0Ij5DYW4gd2Ugc2F5IHRoYXQgdGhl eSBhcmUgYSBzaW5nbGUgYmVoYXZpb3IgPzx1PjwvdT48dT48L3U+PC9zcGFuPjwvbGk+PGxpIHN0 eWxlPSJtYXJnaW4tbGVmdDowaW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTRwdCI+Q2FuIHdl IGp1c3RpZnkgYm90aCBiZWNhdXNlIGVhY2ggaXMgb3B0aW1pemVkIGZvciBhIGRpZmZlcmVudCBr aW5kIG9mIG5ldHdvcms/PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9saT48bGkgc3R5bGU9Im1hcmdp bi1sZWZ0OjBpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB0Ij5DYW4gd2UganVzdGlmeSBh bm90aGVyIGJlaGF2aW9yIGVpdGhlciBiZWNhdXNlIGl0IGlzIG9wdGltaXplZCBmb3IgeWV0IGFu b3RoZXIgdHlwZSBvZiBuZXR3b3JrIG9yIGJlY2F1c2UgaXQgZG9lcyByZWxhdGl2ZWx5IHdlbGwg aW4gYWxsIG5ldHdvcmsgdHlwZXM/PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9saT48L3VsPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB0Ij48dT48L3U+Jm5i c3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjE0cHQiPkhvd2V2ZXIsIGlmIHRoaXMgaXMganVzdCBhbiDigJxlYXNlIG9mIG9w ZXJhdGlvbuKAnSB0aGluZywgYXMgc3RhdGVkIGluIHRoZSBkcmFmdCwgdGhlIGF1dGhvcnMgYXJl IG9ibGlnZWQgdG8gYW5zd2VyIG15IHF1ZXN0aW9uLjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTRwdCI+PHU+PC91 PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxNHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Um9uPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB0Ij48dT48L3U+ Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjE0cHQiPlAuUy4gUmVzdCBhc3N1cmVkIHRoYXQgSSBoYXZlIHJlYWQgdGhl IGRyYWZ0LiBIb3dldmVyLCB5b3VyIGNvbmNlcm4gaXMgZ3JlYXRseSBhcHByZWNpYXRlZA0KPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTRwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBV SSBFbW9qaSZxdW90OyxzYW5zLXNlcmlmIj7wn5iJPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTRwdCI+PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB0Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0cHQiPjx1 PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1Pjwv dT4mbmJzcDs8dT48L3U+PC9wPg0KPHAgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbjowaW47 dGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6N3B0O2NvbG9yOmJsYWNr Ij5KdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlci1yaWdodDpub25lO2JvcmRlci1ib3R0b206bm9uZTtib3Jk ZXItbGVmdDpub25lO2JvcmRlci10b3A6MXB0IHNvbGlkIHJnYigyMjUsMjI1LDIyNSk7cGFkZGlu ZzozcHQgMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUm9iZXJ0 IFJhc3p1ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9i bGFuayI+cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRh eSwgT2N0b2JlciAxLCAyMDIxIDQ6MzIgUE08YnI+DQo8Yj5Ubzo8L2I+IFJvbiBCb25pY2EgJmx0 OzxhIGhyZWY9Im1haWx0bzpyYm9uaWNhQGp1bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+cmJv bmljYUBqdW5pcGVyLm5ldDwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBTUFJJTkcgV0cgJmx0Ozxh IGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0 Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NwcmluZ10gQ1NJRCBRdWVz dGlvbjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImxpbmUtaGVpZ2h0OjEycHQ7YmFja2dyb3VuZDpyZ2IoMjU1LDIzNSwxNTYpIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpMYXRvLHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPltFeHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF08dT48L3U+PHU+ PC91Pjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNwOzx1 PjwvdT48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFJvbiwgPHU+ PC91Pjx1PjwvdT48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHU+PC91PiZuYnNw Ozx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IYXZlIHlv dSByZWFkIHRoaXMmbmJzcDtkcmFmdCA/Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlF1b3RlIGZyb20gaXQ6Jm5ic3A7PHU+ PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48 L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjox cHQgc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRkaW5nOjhwdCI+DQo8cHJlIHN0eWxlPSJtYXJn aW4tcmlnaHQ6OC4yNXB0O21hcmdpbi1ib3R0b206Ny45cHQ7bWFyZ2luLWxlZnQ6OC4yNXB0O2Jh Y2tncm91bmQ6cmdiKDI1NSwyNTMsMjQ1KTt3b3JkLWJyZWFrOmJyZWFrLWFsbDtib3gtc2l6aW5n OmJvcmRlci1ib3g7Ym9yZGVyLXJhZGl1czo0cHg7b3ZlcmZsb3c6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6TW9uYWNvO2NvbG9yOmJsYWNrIj4mbmJzcDsm bmJzcDsgSXQgaXMgcmVjb21tZW5kZWQgZm9yIGVhc2Ugb2Ygb3BlcmF0aW9uIHRoYXQgYSBzaW5n bGUgY29tcHJlc3NlZDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLXJpZ2h0OjguMjVwdDttYXJnaW4tYm90dG9tOjcuOXB0O21hcmdpbi1sZWZ0OjguMjVwdDti YWNrZ3JvdW5kOnJnYigyNTUsMjUzLDI0NSk7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ok1vbmFjbztjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7IGVuY29kaW5nIGZsYXZvciBiZSB1c2VkIGluIGEgZ2l2ZW4gU1J2NiBkb21haW4u Jm5ic3A7IEhvd2V2ZXIsIGluIGEgbXVsdGktPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tcmlnaHQ6OC4yNXB0O21hcmdpbi1ib3R0b206Ny45cHQ7bWFyZ2lu LWxlZnQ6OC4yNXB0O2JhY2tncm91bmQ6cmdiKDI1NSwyNTMsMjQ1KTt3b3JkLWJyZWFrOmJyZWFr LWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6TW9uYWNvO2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZG9tYWluIGRlcGxveW1lbnQsIGRpZmZlcmVudCBmbGF2 b3JzIGNhbiBiZSB1c2VkIGluIGRpZmZlcmVudDx1PjwvdT48dT48L3U+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0ibWFyZ2luLXJpZ2h0OjguMjVwdDttYXJnaW4tYm90dG9tOjcuOXB0O21hcmdp bi1sZWZ0OjguMjVwdDtiYWNrZ3JvdW5kOnJnYigyNTUsMjUzLDI0NSk7d29yZC1icmVhazpicmVh ay1hbGwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ok1vbmFjbztj b2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGRvbWFpbnMuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9w cmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+ Jm5ic3A7PHU+PC91PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g RnJpLCBPY3QgMSwgMjAyMSBhdCA5OjMzIFBNIFJvbiBCb25pY2EgJmx0O3Jib25pY2E9PGEgaHJl Zj0ibWFpbHRvOjQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj40 MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PHU+PC91Pjx1PjwvdT48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXItdG9wOm5vbmU7Ym9yZGVyLXJp Z2h0Om5vbmU7Ym9yZGVyLWJvdHRvbTpub25lO2JvcmRlci1sZWZ0OjFwdCBzb2xpZCByZ2IoMjA0 LDIwNCwyMDQpO3BhZGRpbmc6MGluIDBpbiAwaW4gNnB0O21hcmdpbjo1cHQgMGluIDVwdCA0Ljhw dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTRwdCI+Q1NJRCBBdXRob3JzLDwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTRwdCI+Jm5ic3A7PC9zcGFu Pjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxNHB0Ij5Bc3N1bWUgdGhhdCBhbiBTUiBwYXRoIGNvbnRhaW5zIHNlZ21lbnRzIDEg dGhyb3VnaCA4LiBTZWdtZW50cyAxLCAzLCA1LCBhbmQgNyBhcmUgRU5EIFNJRHMgdGhhdCB1c2Ug TmV4dC1DLVNJRCAoaS5lLiwgdVNJRCkuIFNlZ21lbnRzIDIsIDQsIGFuZCA2IGFyZSBFTkQgU0lE cyB0aGF0IHVzZSBSZXBsYWNlLUMtU0lELiBTZWdtZW50IDggaXMgYW5kIEVORC5EWDQNCiBTSUQu PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxNHB0Ij4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0cHQiPlBsZWFzZSBwcm92 aWRlIGFuIGV4YW1wbGUgdGhhdCBzaG93cyB1czo8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0cHQiPiZuYnNwOzwv c3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjE0cHQiPldoYXQgdGhlIFNSSCBsb29rcyBsaWtlIGFzIGl0IGFycml2ZXMg YXQgdGhlIGZpcnN0IHNlZ21lbnQgZW5kcG9pbnQ8L3NwYW4+PHU+PC91Pjx1PjwvdT48L2xpPjxs aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0cHQiPldoYXQgdGhlIElQdjYgRGVzdGluYXRpb24g QWRkcmVzcyBsb29rcyBsaWtlIGF0IGVhY2ggc2VnbWVudCBlbmRwb2ludCwgaW5jbHVkaW5nIGlu Zm9ybWF0aW9uIHJlcXVpcmVkIHRvIHBhcnNlIHRoZSBEZXN0aW5hdGlvbiBBZGRyZXNzPC9zcGFu Pjx1PjwvdT48dT48L3U+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxNHB0Ij4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0cHQiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtSb248L3NwYW4+ PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjE0cHQiPiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPHAgYWxpZ249ImNlbnRlciIgc3R5 bGU9Im1hcmdpbjowaW47dGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 N3B0O2NvbG9yOmJsYWNrIj5KdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5PC9zcGFuPjx1PjwvdT48 dT48L3U+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc3ByaW5nIG1haWxp bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LmNvbS92My9fX2h0dHBzOi93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmdfXzsh IU5FdDZ5TWFPLWdrIVVMX0xzVEVXdXlidGV3Y0lIWDJGd3JxdHdTM0c5N2tpM3R6SFQ4cEd5R2N4 MmhQV1laZnJpU21lRzc1dXdQN2wkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8L2E+PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_5449C5814F7F4C49BE77072802E4FF05junipernet_-- From nobody Sat Oct 2 07:00:12 2021 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 D73C53A0D6F; Sat, 2 Oct 2021 07:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V2QhwP_Tj2rm; Sat, 2 Oct 2021 07:00:02 -0700 (PDT) Received: from unicom145.biz-email.net (unicom145.biz-email.net [210.51.26.145]) (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 2EA393A0D6B; Sat, 2 Oct 2021 06:59:59 -0700 (PDT) Received: from ([58.210.9.219]) by unicom145.biz-email.net ((LNX1044)) with ASMTP id WPK00155; Sat, 02 Oct 2021 21:59:55 +0800 Received: from [192.168.1.16] ([117.80.33.246]) (envelope-sender ) by 192.168.25.7 with ESMTP for ; Sat, 02 Oct 2021 21:59:23 +0800 Sender: chengw@centecnetworks.com X-WM-Sender: chengw@centecnetworks.com X-WM-AuthFlag: YES X-WM-AuthUser: chengw@centecnetworks.com User-Agent: Microsoft-MacOutlook/16.53.21091200 Date: Sat, 02 Oct 2021 21:59:22 +0800 From: WEI CHENG To: Yisong Liu , James Guichard , SPRING WG CC: spring-chairs Message-ID: <80A426AE-9DB7-461C-B5D8-859A7FB7454B@centecnetworks.com> Thread-Topic: [spring] =?UTF-8?B?UkXvvJpXRw==?= Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3716056762_637878053" tUid: 202110022159550946b1578062789bff0fecc1fa00e490 X-Abuse-Reports-To: service@corp-email.com Abuse-Reports-To: service@corp-email.com X-Complaints-To: service@corp-email.com X-Report-Abuse-To: service@corp-email.com Archived-At: Subject: Re: [spring] =?utf-8?q?RE=EF=BC=9AWG_Adoption_call_for_https=3A//dat?= =?utf-8?q?atracker=2Eietf=2Eorg/doc/draft-filsfilscheng-spring-srv6-srh-c?= =?utf-8?q?ompression/?= 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, 02 Oct 2021 14:00:09 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3716056762_637878053 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Chairs & WG, =20 I support the adoption of CSID draft. From chips design angels, I would lik= e to add that CSID defines next and replace behaviors that are consistent wi= th the SRv6 network programming RFC8996. =20 Best Regards Wei Cheng =20 =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: Yisong Liu =E6=97=A5=E6=9C=9F: 2021=E5=B9=B410=E6=9C=882=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=85=AD =E4=B8=8B=E5=8D=8812:55 =E6=94=B6=E4=BB=B6=E4=BA=BA: James Guichard , SPRING WG =E6=8A=84=E9=80=81: spring-chairs =E4=B8=BB=E9=A2=98: [spring] RE=EF=BC=9A WG Adoption call for https://datatracker.ietf.org/do= c/draft-filsfilscheng-spring-srv6-srh-compression/ =20 Hi Chairs & WG, =20 I strongly support the adoption call. Regarding chair's note in the email, = I would like to point that the network programming model (RFC8996) by nature= defines multiple behaviors. CSID has a single SRv6 based data plane that de= fines the next and replace behaviors consistent with the network programming= paradigm. =20 CSID's next and replace behaviors have been verified by interoperability te= st in China mobile laboratory and there is no problem with the interworking = of the two behaviors on the CSID dataplane. =20 Best Regards Yisong =20 =E5=8F=91=E4=BB=B6=E4=BA=BA: James Guichard =E6=97=B6=E9=97=B4: 2021/10/01(=E6=98=9F=E6=9C=9F=E4=BA=94)22:04 =E6=94=B6=E4=BB=B6=E4=BA=BA: SPRING WG; =E6=8A=84=E9=80=81=E4=BA=BA: spring-chairs; =E4=B8=BB=E9=A2=98: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draf= t-filsfilscheng-spring-srv6-srh-compression/ Dear WG: =20 The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to move= forward with respect to a solution for SRv6 compression.=20 =20 The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis = for its compression standardization work. That is part of what this email at= tempts to confirm. =20 Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsfi= lscheng-spring-srv6-srh-compression/ but with some clear guidelines as follo= ws. By expressing support for adoption of this document you are fully aware = of and are acknowledging that:=20 =20 The SPRING working group is adopting a document that has multiple SRv6 Endp= oint behaviors.=20 The document is a =E2=80=9Cliving=E2=80=9D document; it may change as it goes through r= eview and analysis by the SPRING working group.=20 All open discussion points raised on our mailing list MUST be addressed BEF= ORE said document is allowed to progress from the working group to publicati= on. A list of these discussion points will be documented in the WG document = and maintained by the document editor in conjunction with the chairs.=20 If this document is adopted by the working group, the chairs specify as par= t of the adoption call that the following text describing an open issue be a= dded to the document in the above-described open issues section: "Given that the working group has said that it wants to standardize one dat= a plane solution, and given that the document contains multiple SRv6 EndPoin= t behaviors that some WG members have stated are multiple data plane solutio= ns, the working group will address whether this is valid and coherent with i= ts one data plane solution objective.". =20 Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/non= -support as well as any open discussion points you would like addressed shou= ld the document be adopted into the working group. =20 Thanks! =20 Jim, Bruno & Joel =20 =20 --B_3716056762_637878053 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Chairs & WG,=

 

I support the adoption of CSID draft. From chips design = angels, I would like to add that CSID defines next and replace behaviors tha= t are consistent with the SRv6 network programming RFC8996.

 

Best Regards

Wei Cheng

 

=  

=E5=8F=91=E4=BB=B6=E4=BA=BA: Yisong Liu <liuyisong@chinamobile.com>=E6=97=A5=E6=9C=9F: 2021=E5=B9=B410=E6=9C=882=E6=97=A5 =E6=98=9F=E6=9C=9F=E5=85=AD =E4=B8=8B=E5=8D=8812:55
=E6=94=B6=E4=BB=B6=E4=BA=BA: = James Guichard <james.n.guichard@futurewei.com>, SPRING WG <sp= ring@ietf.org>
=E6=8A=84=E9=80=81: spring-chairs <spring-chairs@ietf.org>
=E4=B8=BB=E9=A2=98: [spring] RE=EF= =BC=9A WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfi= lscheng-spring-srv6-srh-compression/

=

 

<= p class=3DMsoNormal>Hi Chairs & WG,

 

I strongly support t= he adoption call. Regarding chair's note in the email, I would like to point= that the network programming model (RFC8996) by nature defines multiple beh= aviors. CSID has a single SRv6 based data plane that defines the next and re= place behaviors consistent with the network programming paradigm.

 

CSID's next and replace b= ehaviors have been verified by interoperability test in China mobi= le laboratory and there is no problem with the interworking of the two behav= iors on the CSID dataplane.

 

Best Regards

Yisong=

 

=

=E5=8F=91=E4=BB=B6=E4=BA=BA: James Guichard

= =E6=97=B6=E9=97=B4: 2021/10/01(=E6=98=9F=E6=9C=9F=E4=BA=94)22:04<= o:p>

=E6=94=B6=E4=BB=B6=E4=BA=BA: = SPRING WG;

=

=E6=8A=84=E9=80=81=E4=BA=BA: spring-chairs;

=E4=B8=BB=E9=A2=98: [spring] WG Adoption call for https://datatracke= r.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

 

The chairs would like to express their appreciation for all the response= s received to our emails with reference to how the working group wishes to m= ove forward with respect to a solution for SRv6 compression.

 

The= apparent inclination of the working group is to use https:/= /datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardization work. That is part of wh= at this email attempts to confirm.

<= o:p> 

Because of the above the chair= s would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilsch= eng-spring-srv6-srh-compression/ but with some clear guidelines as follo= ws. By expressing support for adoption of this document you are fully aware = of and are acknowledging that:

 

  1. The SPRING working group is adopt= ing a document that has multiple SRv6 Endpoint behaviors. =
  2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change as it goes throu= gh review and analysis by the SPRING working group.
    3. <= li class=3DMsoListParagraph style=3D'mso-list:l0 level1 lfo3'>A= ll open discussion points raised on our mailing list MUST be addressed BEFOR= E said document is allowed to progress from the working group to publication= . A list of these discussion points will be documented in the WG document an= d maintained by the document editor in conjunction with the chairs.
  3. If this document is adopted by the working group, the chairs = specify as part of the adoption call that the following text describing an o= pen issue be added to the document in the above-described open issues sectio= n:
    1. "Given that the working group h= as said that it wants to standardize one data plane solution, and given that= the document contains multiple SRv6 EndPoint behaviors that some WG members= have stated are multiple data plane solutions, the working group will addre= ss whether this is valid and coherent with its one data plane solution objec= tive.".

 <= /o:p>

Please consider the above guidelines as y= ou decide on whether to support or not this WG adoption. Please express clea= rly your reasoning for support/non-support as well as any open discussion po= ints you would like addressed should the document be adopted into the workin= g group.

 

Thanks!

&nb= sp;

Jim, Bruno & Joel

 

 

--B_3716056762_637878053-- From nobody Sat Oct 2 18:03:14 2021 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 42C3E3A08E7 for ; Sat, 2 Oct 2021 18:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 W7TTWYuldHkZ for ; Sat, 2 Oct 2021 18:03:07 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 4E36F3A08C7 for ; Sat, 2 Oct 2021 18:03:06 -0700 (PDT) Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id 8C1734F2934325F9ADFA for ; Sun, 3 Oct 2021 09:03:04 +0800 (CST) Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 7471165BD8AE877810B6; Sun, 3 Oct 2021 09:03:04 +0800 (CST) Received: from kjyxapp05.zte.com.cn ([10.30.12.204]) by mse-fl1.zte.com.cn with SMTP id 193133ij077645; Sun, 3 Oct 2021 09:03:03 +0800 (GMT-8) (envelope-from liu.aihua@zte.com.cn) Received: from mapi (kjyxapp06[null]) by mapi (Zmail) with MAPI id mid13; Sun, 3 Oct 2021 09:03:02 +0800 (CST) Date: Sun, 3 Oct 2021 09:03:02 +0800 (CST) X-Zmail-TransId: 2b08615901462bce471e X-Mailer: Zmail v1.0 Message-ID: <202110030903029947713@zte.com.cn> In-Reply-To: <5449C581-4F7F-4C49-BE77-072802E4FF05@juniper.net> References: BL0PR05MB5316659C505F9BFBE915D59BAEAB9@BL0PR05MB5316.namprd05.prod.outlook.com, CAOj+MMG2hRhCvZd8ifTM=sSgkdW+09oK+ORMqQ47dJ-0QwnaxA@mail.gmail.com, BL0PR05MB531627B8F2F345E073EDF5D4AEAB9@BL0PR05MB5316.namprd05.prod.outlook.com, CAOj+MMGWEwEdhqi1wEJj2hu3FKLdVKA=xt0XxNvsPw-Z5-p3ww@mail.gmail.com, 5449C581-4F7F-4C49-BE77-072802E4FF05@juniper.net Mime-Version: 1.0 From: To: Cc: , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl1.zte.com.cn 193133ij077645 Archived-At: Subject: Re: [spring] =?utf-8?q?CSID_Question?= 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, 03 Oct 2021 01:03:13 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgUm9uLA0KDQoNCllvdSByYWlzZWQgYW4gaW50ZXJlc3RpbmcgcXVlc3Rpb24sIGJ1dCBJIHRo aW5rIGl0IG1pZ2h0IGJlIGFscmVhZHkgZGlzY3Vzc2VkIGluIHRoZSBEVC4gSW4gbXkgdW5kZXJz dGFuZGluZywgdGhpcyBxdWVzdGlvbiBpcyBqdXN0IG1vcmUgcmVsYXRlZCB0aGUgdXNlY2FzZXMg YW5kIHJlcXVpcmVtZW50cyBidXQgdGhlIHNvbHV0aW9ucy4gSW4gYSBTUnY2IGRvbWFpbiwgdGhl IGhlYWRlciBjb21wcmVzc2lvbiBlZmZlY3Rpb24gZGVwZW5kcyBvbiB0aGUgU0lEIGluZm9ybWFp b24gcmVkdW5kZW5jaWVzIGR1ZSB0byB0aGUgcmVhc29uYWJsZSBTSUQgcGxhbm5pbmcgd2l0aCB0 aGUgU1J2NiBjb21wYXRpYmxlIHNvbHV0aW9uLiBJIHRoaW5rIGl0J3MgbWVhbmxlc3MgdG8gY29t cHJlc3MgdGhlIFNSdjYgaGVhZGVyIGluIHRoZSBjYXNlIG9mIHJhbmRvbSBTSUQgZm9ybWF0LiBC ZXNpZGVzIG90aGVyIHNvbHV0aW9uIHdpdGhvdXQgZW5nb3V0aCBTUnY2IGNvbXBhdGlibGUgc3Vj aCBhcyBVbmlmaWVkIFNJRCBjb3VsZCBiZSB1c2VkIHRvIHJlc29sdmUgdGhlIHVzZWNhc2UgeW91 IG1lbnRpb25lZC4gSSBiZWxpZXZlIHRoYXQgaGFkIGJlZW4gZGlzY3Vzc2VkIGFuZCBjb21wYXJl ZCB3aXRoaW4gdGhlIERUIGFuZCB0aGUgb25lIHNvbHV0aW9uIGNvbXBhdGlibGUgd2l0aCBTUnY2 IGlzIHByZWZlcnJlZCwgdGhhdCBpcyB0aGUgQ1NJRCBkcmFmdC4NCg0KDQoNCg0KDQoNCkJlc3Qg UmVnYXJkcywNCg0KDQpBaWh1YQ0KDQoNCg0KDQoNCg0KDQrljp/lp4vpgq7ku7YNCg0KDQoNCuWP keS7tuS6uu+8mlJvbkJvbmljYQ0K5pS25Lu25Lq677yaUm9iZXJ0IFJhc3p1azsNCuaKhOmAgeS6 uu+8mlNQUklORyBXRzsNCuaXpSDmnJ8g77yaMjAyMeW5tDEw5pyIMDLml6UgMjE6MzkNCuS4uyDp opgg77yaUmU6IFtzcHJpbmddIENTSUQgUXVlc3Rpb24NCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5n QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0K DQogRm9sa3MsDQogTm93IHRoYXQgUm9iZXJ0IGFuZCBJIGhhdmUgcHJvdmlkZWQgc29tZSBlbnRl cnRhaW5tZW50LCBjb3VsZCBzb21lb25lIGFuc3dlciB0aGUgdGVjaG5pY2FsIHF1ZXN0aW9uIHRo YXQgaW5pdGlhdGVkIHRoaXMgdGhyZWFkPw0KDQogRG9lcyB0aGUgZG9jdW1lbnQgcmVjb21tZW5k IGFnYWluc3QgdXNpbmcgTmV4dC1DLVNJZCBhbmQgUmVwbGFjZS1DLVNpZCBpbiB0aGUgc2FtZSBk b21haW4gIGZvciBlYXNlIG9mIG9wZXJhdGlvbiBvciBiZWNhdXNlIHRoZXkgZG9u4oCZdCB3b3Jr IHdlbGwgdG9nZXRoZXI/IElmIHRoZSBmb3JtZXIsIHBsZWFzZSBwcm92aWRlIHRoZSBleGFtcGxl IGRlc2NyaWJlZCBiZWxvdy4NCg0KICAgICAgICAgICAgICAgUm9uDQoNCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgDQogDQogDQpTZW50IGZyb20gbXkgaVBob25lDQoNCg0KIE9uIE9j dCAxLCAyMDIxLCBhdCA1OjA3IFBNLCBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldD4g d3JvdGU6DQogDQogDQoNCu+7vw0KDQoNCg0KW0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBv ZiBjb250ZW50XQ0KDQogDQoNCg0KDQpIaSBSb24sDQogDQoNCiBDYW4gd2Ugc2F5IHRoYXQgdGhl eSBhcmUgYSBzaW5nbGUgYmVoYXZpb3IgPw0KDQoNCiBOby4gQW5kIG5laXRoZXIgUkZDODk4NiBk ZWZpbmVzIGEgc2luZ2xlIGJlaGF2aW9yIG9yIHNpbmdsZSBmbGF2b3IuIFlldCB0aGUgYm91bmRz IGFyZSBjbGVhcmx5IHNldCB3aGF0IGlzIHRoZSBTUnY2IGRhdGEgcGxhbmUuIA0KDQoNCg0KIEZv ciBzb21lIHN0cmFuZ2UgcmVhc29uIEkgYW0gb2JzZXJ2aW5nIGhlcmUgYW4gYXR0ZW1wdCB0byBz cXVlZXplIGRpZmZlcmVudCBkYXRhIHBsYW5lIGludG8gdGhlIHJvb20gd2hpY2ggaXMgbm90IGNv bXBsaWFudCB0byBbUkZDODQwMl0sIFtSRkM4NzU0XSBhbmQgW1JGQzg5ODZdLiBEbyB5b3UgdGhp bmsgYW55b25lIHdpbGwgYmUgc28gbmFpdmUgdG8gYWNjZXB0IGl0ID8gDQogDQoNCiBOb3cgSSBh bSBnb2luZyB0byByZXN0IGFzc3VyZWQgYW5kIGVuam95IHRoZSByZXN0IG9mIHRoaXMgc2hvdy4g DQoNCiBCZXN0LA0KUm9iZXJ0DQoNCiANCg0KIA0KDQpPbiBGcmksIE9jdCAxLCAyMDIxIGF0IDEw OjU4IFBNIFJvbiBCb25pY2EgPHJib25pY2FAanVuaXBlci5uZXQ+IHdyb3RlOg0KIA0KDQoNClJv YmVydCwNCg0KDQogDQoNCg0KSSBkbyByZW1lbWJlciB0aGF0IHF1b3RlLiBBbmQgdGhhdCBpcyBl eGFjdGx5IHdoeSBJIGFzayB0aGUgcXVlc3Rpb24hDQoNCg0KIA0KDQoNCklmIE5FWFQtQy1TSUQg YW5kIFJFUExBQ0UtQy1TSUQgYXJlIGluY29tcGF0aWJsZSB3aXRoaW4gYSBkb21haW46DQoNCg0K IA0KDQpDYW4gd2Ugc2F5IHRoYXQgdGhleSBhcmUgYSBzaW5nbGUgYmVoYXZpb3IgPw0KDQpDYW4g d2UganVzdGlmeSBib3RoIGJlY2F1c2UgZWFjaCBpcyBvcHRpbWl6ZWQgZm9yIGEgZGlmZmVyZW50 IGtpbmQgb2YgbmV0d29yaz8NCg0KQ2FuIHdlIGp1c3RpZnkgYW5vdGhlciBiZWhhdmlvciBlaXRo ZXIgYmVjYXVzZSBpdCBpcyBvcHRpbWl6ZWQgZm9yIHlldCBhbm90aGVyIHR5cGUgb2YgbmV0d29y ayBvciBiZWNhdXNlIGl0IGRvZXMgcmVsYXRpdmVseSB3ZWxsIGluIGFsbCBuZXR3b3JrIHR5cGVz Pw0KDQoNCiANCg0KDQpIb3dldmVyLCBpZiB0aGlzIGlzIGp1c3QgYW4g4oCcZWFzZSBvZiBvcGVy YXRpb27igJ0gdGhpbmcsIGFzIHN0YXRlZCBpbiB0aGUgZHJhZnQsIHRoZSBhdXRob3JzIGFyZSBv YmxpZ2VkIHRvIGFuc3dlciBteSBxdWVzdGlvbi4NCg0KDQogDQoNCg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFJvbg0KDQoNCiANCg0KDQpQLlMuIFJlc3QgYXNzdXJl ZCB0aGF0IEkgaGF2ZSByZWFkIHRoZSBkcmFmdC4gSG93ZXZlciwgeW91ciBjb25jZXJuIGlzIGdy ZWF0bHkgYXBwcmVjaWF0ZWQg8J+YiQ0KDQoNCiANCg0KDQogDQoNCg0KIA0KDQoNCkp1bmlwZXIg QnVzaW5lc3MgVXNlIE9ubHkNCg0KDQoNCkZyb206IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6 dWsubmV0PiANCiBTZW50OiBGcmlkYXksIE9jdG9iZXIgMSwgMjAyMSA0OjMyIFBNDQogVG86IFJv biBCb25pY2EgPHJib25pY2FAanVuaXBlci5uZXQ+DQogQ2M6IFNQUklORyBXRyA8c3ByaW5nQGll dGYub3JnPg0KIFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBDU0lEIFF1ZXN0aW9uDQoNCg0KDQoNCiAN Cg0KDQpbRXh0ZXJuYWwgRW1haWwuIEJlIGNhdXRpb3VzIG9mIGNvbnRlbnRdDQoNCg0KIA0KDQoN CkhpIFJvbiwNCg0KDQogDQoNCg0KSGF2ZSB5b3UgcmVhZCB0aGlzIGRyYWZ0ID8gDQoNCg0KDQog DQoNCg0KUXVvdGUgZnJvbSBpdDogDQoNCg0KDQogDQoNCg0KICAgSXQgaXMgcmVjb21tZW5kZWQg Zm9yIGVhc2Ugb2Ygb3BlcmF0aW9uIHRoYXQgYSBzaW5nbGUgY29tcHJlc3NlZCAgICBlbmNvZGlu ZyBmbGF2b3IgYmUgdXNlZCBpbiBhIGdpdmVuIFNSdjYgZG9tYWluLiAgSG93ZXZlciwgaW4gYSBt dWx0aS0gICAgZG9tYWluIGRlcGxveW1lbnQsIGRpZmZlcmVudCBmbGF2b3JzIGNhbiBiZSB1c2Vk IGluIGRpZmZlcmVudCAgICBkb21haW5zLiANCg0KDQoNCiANCg0KDQpPbiBGcmksIE9jdCAxLCAy MDIxIGF0IDk6MzMgUE0gUm9uIEJvbmljYSA8cmJvbmljYT00MGp1bmlwZXIubmV0QGRtYXJjLmll dGYub3JnPiB3cm90ZToNCg0KDQoNCkNTSUQgQXV0aG9ycywNCg0KDQogDQoNCg0KQXNzdW1lIHRo YXQgYW4gU1IgcGF0aCBjb250YWlucyBzZWdtZW50cyAxIHRocm91Z2ggOC4gU2VnbWVudHMgMSwg MywgNSwgYW5kIDcgYXJlIEVORCBTSURzIHRoYXQgdXNlIE5leHQtQy1TSUQgKGkuZS4sIHVTSUQp LiBTZWdtZW50cyAyLCA0LCBhbmQgNiBhcmUgRU5EIFNJRHMgdGhhdCB1c2UgUmVwbGFjZS1DLVNJ RC4gU2VnbWVudCA4IGlzIGFuZCBFTkQuRFg0IFNJRC4NCg0KDQogDQoNCg0KUGxlYXNlIHByb3Zp ZGUgYW4gZXhhbXBsZSB0aGF0IHNob3dzIHVzOg0KDQoNCiANCg0KV2hhdCB0aGUgU1JIIGxvb2tz IGxpa2UgYXMgaXQgYXJyaXZlcyBhdCB0aGUgZmlyc3Qgc2VnbWVudCBlbmRwb2ludA0KDQpXaGF0 IHRoZSBJUHY2IERlc3RpbmF0aW9uIEFkZHJlc3MgbG9va3MgbGlrZSBhdCBlYWNoIHNlZ21lbnQg ZW5kcG9pbnQsIGluY2x1ZGluZyBpbmZvcm1hdGlvbiByZXF1aXJlZCB0byBwYXJzZSB0aGUgRGVz dGluYXRpb24gQWRkcmVzcw0KDQoNCiANCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQoNCg0KIA0KDQoNCiANCg0KDQpKdW5p cGVyIEJ1c2luZXNzIFVzZSBPbmx5DQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQogc3ByaW5nIG1haWxpbmcgbGlzdA0KIHNwcmluZ0BpZXRm Lm9yZw0KIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5n --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MTZweDtmb250LWZh bWlseTrlvq7ova/pm4Xpu5EsTWljcm9zb2Z0IFlhSGVpOyI+PGJyPjwvcD48cCBzdHlsZT0iZm9u dC1zaXplOjE2cHg7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buRLE1pY3Jvc29mdCBZYUhlaTsiPkhp IFJvbiw8L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxNnB4O2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7 kSxNaWNyb3NvZnQgWWFIZWk7Ij5Zb3UgcmFpc2VkIGFuIGludGVyZXN0aW5nIHF1ZXN0aW9uLCBi dXQgSSB0aGluayBpdCBtaWdodCBiZSBhbHJlYWR5IGRpc2N1c3NlZCBpbiB0aGUgRFQuIEluIG15 IHVuZGVyc3RhbmRpbmcsIHRoaXMgcXVlc3Rpb24gaXMganVzdCBtb3JlIHJlbGF0ZWQgdGhlIHVz ZWNhc2VzIGFuZCByZXF1aXJlbWVudHMgYnV0IHRoZSBzb2x1dGlvbnMuIEluIGEgU1J2NiBkb21h aW4sIHRoZSBoZWFkZXIgY29tcHJlc3Npb24gZWZmZWN0aW9uIGRlcGVuZHMgb24gdGhlIFNJRCBp bmZvcm1haW9uIHJlZHVuZGVuY2llcyBkdWUgdG8gdGhlIHJlYXNvbmFibGUgU0lEIHBsYW5uaW5n IHdpdGggdGhlIFNSdjYgY29tcGF0aWJsZSBzb2x1dGlvbi4gSSB0aGluayBpdCdzIG1lYW5sZXNz IHRvIGNvbXByZXNzIHRoZSBTUnY2IGhlYWRlciBpbiB0aGUgY2FzZSBvZiByYW5kb20gU0lEIGZv cm1hdC4gQmVzaWRlcyBvdGhlciBzb2x1dGlvbiB3aXRob3V0IGVuZ291dGggU1J2NiBjb21wYXRp YmxlIHN1Y2ggYXMgVW5pZmllZCBTSUQgY291bGQgYmUgdXNlZCB0byByZXNvbHZlIHRoZSB1c2Vj YXNlIHlvdSBtZW50aW9uZWQuJm5ic3A7SSBiZWxpZXZlIHRoYXQgaGFkIGJlZW4gZGlzY3Vzc2Vk IGFuZCBjb21wYXJlZCB3aXRoaW4gdGhlIERUIGFuZCB0aGUgb25lIHNvbHV0aW9uIGNvbXBhdGli bGUgd2l0aCBTUnY2IGlzIHByZWZlcnJlZCwgdGhhdCBpcyB0aGUgQ1NJRCBkcmFmdC48L3A+PHAg c3R5bGU9ImZvbnQtc2l6ZToxNnB4O2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kSxNaWNyb3NvZnQg WWFIZWk7Ij48YnI+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTZweDtmb250LWZhbWlseTrlvq7o va/pm4Xpu5EsTWljcm9zb2Z0IFlhSGVpOyI+QmVzdCBSZWdhcmRzLDwvcD48cCBzdHlsZT0iZm9u dC1zaXplOjE2cHg7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buRLE1pY3Jvc29mdCBZYUhlaTsiPkFp aHVhPC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTZweDtmb250LWZhbWlseTrlvq7ova/pm4Xpu5Es TWljcm9zb2Z0IFlhSGVpOyI+PGJyPjwvcD48ZGl2PjxkaXYgY2xhc3M9InpoaXN0b3J5Um93IiBz dHlsZT0iZGlzcGxheTpibG9jayI+PGRpdiBjbGFzcz0iemhpc3RvcnlEZXMiIHN0eWxlPSJ3aWR0 aDogMTAwJTsgaGVpZ2h0OiAyOHB4OyBsaW5lLWhlaWdodDogMjhweDsgYmFja2dyb3VuZC1jb2xv cjogI0UwRTVFOTsgY29sb3I6ICMxMzg4RkY7IHRleHQtYWxpZ246IGNlbnRlcjsiIGxhbmd1YWdl LWRhdGE9Ikhpc3RvcnlPcmdUeHQiPuWOn+Wni+mCruS7tjwvZGl2PjxkaXYgaWQ9Inp3cml0ZUhp c3RvcnlDb250YWluZXIiPjxkaXYgY2xhc3M9ImNvbnRyb2wtZ3JvdXAgemhpc3RvcnlQYW5lbCI+ PGRpdiBjbGFzcz0iemhpc3RvcnlIZWFkZXIiIHN0eWxlPSJwYWRkaW5nOiA4cHg7IGJhY2tncm91 bmQtY29sb3I6ICNGNUY2Rjg7Ij48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeVNl bmRlclR4dCI+5Y+R5Lu25Lq677yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUi PlJvbkJvbmljYTxyYm9uaWNhPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+PC9yYm9uaWNh PTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+PC9zcGFuPjwvZGl2PjxkaXY+PHN0cm9uZyBs YW5ndWFnZS1kYXRhPSJIaXN0b3J5VE9UeHQiPuaUtuS7tuS6uu+8mjwvc3Ryb25nPjxzcGFuIGNs YXNzPSJ6cmVhZFVzZXJOYW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyI+Um9iZXJ0IFJhc3p1 azxyb2JlcnRAcmFzenVrLm5ldD47PC9yb2JlcnRAcmFzenVrLm5ldD48L3NwYW4+PC9kaXY+PGRp dj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlDQ1R4dCI+5oqE6YCB5Lq677yaPC9zdHJv bmc+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7Ij5T UFJJTkcgV0c8c3ByaW5nQGlldGYub3JnPjs8L3NwcmluZ0BpZXRmLm9yZz48L3NwYW4+PC9kaXY+ PGRpdj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlEYXRlVHh0Ij7ml6Ug5pyfIO+8mjwv c3Ryb25nPjxzcGFuIGNsYXNzPSIiPjIwMjHlubQxMOaciDAy5pelIDIxOjM5PC9zcGFuPjwvZGl2 PjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5U3ViamVjdFR4dCI+5Li7IOmimCDv vJo8L3N0cm9uZz48c3BhbiBjbGFzcz0ienJlYWRUaXRsZSI+PHN0cm9uZz5SZTogW3NwcmluZ10g Q1NJRCBRdWVzdGlvbjwvc3Ryb25nPjwvc3Bhbj48L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSJ6aGlz dG9yeUNvbnRlbnQiPjxkaXY+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+c3ByaW5nJm5ic3A7bWFpbGluZyZuYnNwO2xpc3Q8YnI+c3ByaW5nQGlldGYu b3JnPGJyPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPGJyPjxi cj4gICBGb2xrcyw8YnI+IDxkaXY+Tm93IHRoYXQgUm9iZXJ0IGFuZCBJIGhhdmUgcHJvdmlkZWQg c29tZSBlbnRlcnRhaW5tZW50LCBjb3VsZCBzb21lb25lIGFuc3dlciB0aGUgdGVjaG5pY2FsIHF1 ZXN0aW9uIHRoYXQgaW5pdGlhdGVkIHRoaXMgdGhyZWFkPzwvZGl2Pjxicj4gPGRpdj5Eb2VzIHRo ZSBkb2N1bWVudCByZWNvbW1lbmQgYWdhaW5zdCB1c2luZyBOZXh0LUMtU0lkIGFuZCBSZXBsYWNl LUMtU2lkIGluIHRoZSBzYW1lIGRvbWFpbiAmbmJzcDtmb3IgZWFzZSBvZiBvcGVyYXRpb24gb3Ig YmVjYXVzZSB0aGV5IGRvbuKAmXQgd29yayB3ZWxsIHRvZ2V0aGVyPyBJZiB0aGUgZm9ybWVyLCBw bGVhc2UgcHJvdmlkZSB0aGUgZXhhbXBsZSBkZXNjcmliZWQgYmVsb3cuPC9kaXY+PGJyPiA8ZGl2 PiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBSb248L2Rp dj48YnI+IDxkaXY+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7PGJyPiA8YnI+IDxkaXYgZGlyPSJsdHIiPlNlbnQgZnJvbSBteSBpUGhvbmU8L2Rp dj48ZGl2IGRpcj0ibHRyIj48YnI+IDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPk9uIE9jdCAxLCAy MDIxLCBhdCA1OjA3IFBNLCBSb2JlcnQgUmFzenVrICZsdDtyb2JlcnRAcmFzenVrLm5ldCZndDsg d3JvdGU6PGJyPiA8YnI+IDwvYmxvY2txdW90ZT48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRl Ij48ZGl2IGRpcj0ibHRyIj7vu788cD48YnI+PC9wPjxkaXYgc3R5bGU9ImJhY2tncm91bmQtY29s b3I6I0ZGRUI5Qzsgd2lkdGg6MTAwJTsgYm9yZGVyLXN0eWxlOiBub25lOyBib3JkZXItY29sb3I6 IzlDNjUwMDsgYm9yZGVyLXdpZHRoOjFwdDsgcGFkZGluZzoycHQ7IGZvbnQtc2l6ZToxMC41cHQ7 IGxpbmUtaGVpZ2h0OjEycHQ7IGZvbnQtZmFtaWx5OidMYXRvJzsgY29sb3I6YmxhY2s7IHRleHQt YWxpZ246IGxlZnQ7IGZvbnQtd2VpZ2h0OmJvbGQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ W0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XTwvc3Bhbj48L2Rpdj48YnI+ IDxwPjxicj48L3A+PGRpdj48ZGl2IGRpcj0ibHRyIj48ZGl2PkhpIFJvbiw8YnI+IDwvZGl2Pjxi cj4gPGRpdj48dWwgdHlwZT0iZGlzYyIgc3R5bGU9Im1hcmdpbi1ib3R0b206MGluO21hcmdpbi10 b3A6MGluIiBjbGFzcz0iIGxpc3QtcGFkZGluZ2xlZnQtMiI+PGxpPjxwPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTRwdCI+Q2FuIHdlIHNheSB0aGF0IHRoZXkgYXJlIGEgc2luZ2xlIGJlaGF2aW9y ID88L3NwYW4+PC9wPjwvbGk+PC91bD48ZGl2Pjxicj4gPGRpdj5Oby4gQW5kIG5laXRoZXIgUkZD ODk4NiBkZWZpbmVzIGEgc2luZ2xlIGJlaGF2aW9yIG9yIHNpbmdsZSBmbGF2b3IuIFlldCB0aGUg Ym91bmRzIGFyZSBjbGVhcmx5Jm5ic3A7c2V0IHdoYXQgaXMgdGhlIFNSdjYgZGF0YSBwbGFuZS4m bmJzcDs8L2Rpdj48L2Rpdj48L2Rpdj48YnI+IDxkaXY+Rm9yIHNvbWUgc3RyYW5nZSZuYnNwO3Jl YXNvbiBJIGFtIG9ic2VydmluZyBoZXJlIGFuIGF0dGVtcHQgdG8gc3F1ZWV6ZSBkaWZmZXJlbnQg ZGF0YSBwbGFuZSBpbnRvIHRoZSByb29tIHdoaWNoIGlzIG5vdCBjb21wbGlhbnQmbmJzcDt0byBb UkZDODQwMl0sIFtSRkM4NzU0XSBhbmQgW1JGQzg5ODZdLiBEbyB5b3UgdGhpbmsgYW55b25lIHdp bGwgYmUgc28gbmFpdmUgdG8gYWNjZXB0IGl0ID8mbmJzcDs8YnI+IDwvZGl2Pjxicj4gPGRpdj5O b3cgSSBhbSBnb2luZyZuYnNwO3RvIHJlc3QgYXNzdXJlZCBhbmQgZW5qb3kgdGhlJm5ic3A7cmVz dCBvZiB0aGlzIHNob3cuJm5ic3A7PC9kaXY+PGJyPiA8ZGl2PkJlc3QsPC9kaXY+PGRpdj5Sb2Jl cnQ8L2Rpdj48YnI+IDwvZGl2Pjxicj4gPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxkaXYgZGly PSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBGcmksIE9jdCAxLCAyMDIxIGF0IDEwOjU4IFBN IFJvbiBCb25pY2EgJmx0OzxhIGhyZWY9Im1haWx0bzpyYm9uaWNhQGp1bmlwZXIubmV0IiB0YXJn ZXQ9Il9ibGFuayI+cmJvbmljYUBqdW5pcGVyLm5ldDwvYT4mZ3Q7IHdyb3RlOjxicj4gPC9kaXY+ PGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4 IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVm dDoxZXgiPjxkaXYgbGFuZz0iRU4tVVMiPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxNHB0Ij5Sb2JlcnQsPC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0cHQiPiZuYnNwOzwvc3Bhbj48L3A+PHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB0Ij5JIGRvIHJlbWVtYmVy IHRoYXQgcXVvdGUuIEFuZCB0aGF0IGlzIGV4YWN0bHkgd2h5IEkgYXNrIHRoZSBxdWVzdGlvbiE8 L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTRw dCI+Jm5ic3A7PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjE0cHQiPklmIE5FWFQtQy1TSUQgYW5kIFJFUExBQ0UtQy1TSUQgYXJlIGluY29tcGF0 aWJsZSB3aXRoaW4gYSBkb21haW46PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjE0cHQiPiZuYnNwOzwvc3Bhbj48L3A+PHVsIHN0eWxlPSJtYXJn aW4tdG9wOjBpbiIgdHlwZT0iZGlzYyIgY2xhc3M9IiBsaXN0LXBhZGRpbmdsZWZ0LTIiPjxsaT48 cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0cHQiPkNhbiB3ZSBzYXkgdGhhdCB0aGV5IGFyZSBh IHNpbmdsZSBiZWhhdmlvciA/PC9zcGFuPjwvcD48L2xpPjxsaT48cD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjE0cHQiPkNhbiB3ZSBqdXN0aWZ5IGJvdGggYmVjYXVzZSBlYWNoIGlzIG9wdGltaXpl ZCBmb3IgYSBkaWZmZXJlbnQga2luZCBvZiBuZXR3b3JrPzwvc3Bhbj48L3A+PC9saT48bGk+PHA+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB0Ij5DYW4gd2UganVzdGlmeSBhbm90aGVyIGJlaGF2 aW9yIGVpdGhlciBiZWNhdXNlIGl0IGlzIG9wdGltaXplZCBmb3IgeWV0IGFub3RoZXIgdHlwZSBv ZiBuZXR3b3JrIG9yIGJlY2F1c2UgaXQgZG9lcyByZWxhdGl2ZWx5IHdlbGwgaW4gYWxsIG5ldHdv cmsgdHlwZXM/PC9zcGFuPjwvcD48L2xpPjwvdWw+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxNHB0Ij4mbmJzcDs8L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTRwdCI+SG93ZXZlciwgaWYgdGhpcyBpcyBqdXN0 IGFuIOKAnGVhc2Ugb2Ygb3BlcmF0aW9u4oCdIHRoaW5nLCBhcyBzdGF0ZWQgaW4gdGhlIGRyYWZ0 LCB0aGUgYXV0aG9ycyBhcmUgb2JsaWdlZCB0byBhbnN3ZXIgbXkgcXVlc3Rpb24uPC9zcGFuPjwv cD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0cHQiPiZuYnNw Ozwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox NHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Um9uPC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjE0cHQiPiZuYnNwOzwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB0Ij5QLlMuIFJlc3QgYXNzdXJlZCB0aGF0IEkgaGF2 ZSByZWFkIHRoZSBkcmFmdC4gSG93ZXZlciwgeW91ciBjb25jZXJuIGlzIGdyZWF0bHkgYXBwcmVj aWF0ZWQgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTRwdDtmb250LWZhbWlseTomcXVv dDtTZWdvZSBVSSBFbW9qaSZxdW90OyxzYW5zLXNlcmlmIj7wn5iJPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTRwdCI+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjE0cHQiPiZuYnNwOzwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB0Ij4mbmJzcDs8L3NwYW4+PC9wPjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzwvcD48cCBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7bWFyZ2lu OjBpbjsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6N3B0O2NvbG9yOmJsYWNrIj5KdW5pcGVyIEJ1 c2luZXNzIFVzZSBPbmx5PC9zcGFuPjwvcD48ZGl2PjxkaXYgc3R5bGU9ImJvcmRlci1yaWdodDpu b25lO2JvcmRlci1ib3R0b206bm9uZTtib3JkZXItbGVmdDpub25lO2JvcmRlci10b3A6MXB0IHNv bGlkIHJnYigyMjUsMjI1LDIyNSk7cGFkZGluZzozcHQgMGluIDBpbiI+PHAgY2xhc3M9Ik1zb05v cm1hbCI+PHN0cm9uZz5Gcm9tOjwvc3Ryb25nPiBSb2JlcnQgUmFzenVrICZsdDs8YSBocmVmPSJt YWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0iX2JsYW5rIj5yb2JlcnRAcmFzenVrLm5l dDwvYT4mZ3Q7IDxicj4gPHN0cm9uZz5TZW50Ojwvc3Ryb25nPiBGcmlkYXksIE9jdG9iZXIgMSwg MjAyMSA0OjMyIFBNPGJyPiA8c3Ryb25nPlRvOjwvc3Ryb25nPiBSb24gQm9uaWNhICZsdDs8YSBo cmVmPSJtYWlsdG86cmJvbmljYUBqdW5pcGVyLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPnJib25pY2FA anVuaXBlci5uZXQ8L2E+Jmd0Ozxicj4gPHN0cm9uZz5DYzo8L3N0cm9uZz4gU1BSSU5HIFdHICZs dDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5n QGlldGYub3JnPC9hPiZndDs8YnI+IDxzdHJvbmc+U3ViamVjdDo8L3N0cm9uZz4gUmU6IFtzcHJp bmddIENTSUQgUXVlc3Rpb248L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMnB0O2JhY2tn cm91bmQ6cmdiKDI1NSwyMzUsMTU2KSI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTpMYXRvLHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPltFeHRlcm5hbCBF bWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF08L3NwYW4+PC9zdHJvbmc+PC9wPjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkg Um9uLDwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+PGRpdj48cCBjbGFzcz0iTXNv Tm9ybWFsIj5IYXZlIHlvdSByZWFkIHRoaXMmbmJzcDtkcmFmdCA/Jm5ic3A7PC9wPjwvZGl2Pjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwvcD48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPlF1 b3RlIGZyb20gaXQ6Jm5ic3A7PC9wPjwvZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwv cD48ZGl2PjxkaXYgc3R5bGU9ImJvcmRlcjoxcHQgc29saWQgcmdiKDIwNCwyMDQsMjA0KTtwYWRk aW5nOjhwdCI+PHByZSBzdHlsZT0ibWFyZ2luLXJpZ2h0OjguMjVwdDttYXJnaW4tYm90dG9tOjcu OXB0O21hcmdpbi1sZWZ0OjguMjVwdDtiYWNrZ3JvdW5kOnJnYigyNTUsMjUzLDI0NSk7d29yZC1i cmVhazpicmVhay1hbGw7Ym94LXNpemluZzpib3JkZXItYm94O2JvcmRlci1yYWRpdXM6NHB4O292 ZXJmbG93OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ok1v bmFjbztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IEl0IGlzIHJlY29tbWVuZGVkIGZvciBlYXNl IG9mIG9wZXJhdGlvbiB0aGF0IGEgc2luZ2xlIGNvbXByZXNzZWQ8L3NwYW4+PC9wcmU+IDxwcmUg c3R5bGU9Im1hcmdpbi1yaWdodDo4LjI1cHQ7bWFyZ2luLWJvdHRvbTo3LjlwdDttYXJnaW4tbGVm dDo4LjI1cHQ7YmFja2dyb3VuZDpyZ2IoMjU1LDI1MywyNDUpO3dvcmQtYnJlYWs6YnJlYWstYWxs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpNb25hY287Y29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyBlbmNvZGluZyBmbGF2b3IgYmUgdXNlZCBpbiBhIGdpdmVuIFNS djYgZG9tYWluLiZuYnNwOyBIb3dldmVyLCBpbiBhIG11bHRpLTwvc3Bhbj48L3ByZT4gPHByZSBz dHlsZT0ibWFyZ2luLXJpZ2h0OjguMjVwdDttYXJnaW4tYm90dG9tOjcuOXB0O21hcmdpbi1sZWZ0 OjguMjVwdDtiYWNrZ3JvdW5kOnJnYigyNTUsMjUzLDI0NSk7d29yZC1icmVhazpicmVhay1hbGwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ok1vbmFjbztjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7IGRvbWFpbiBkZXBsb3ltZW50LCBkaWZmZXJlbnQgZmxhdm9ycyBj YW4gYmUgdXNlZCBpbiBkaWZmZXJlbnQ8L3NwYW4+PC9wcmU+IDxwcmUgc3R5bGU9Im1hcmdpbi1y aWdodDo4LjI1cHQ7bWFyZ2luLWJvdHRvbTo3LjlwdDttYXJnaW4tbGVmdDo4LjI1cHQ7YmFja2dy b3VuZDpyZ2IoMjU1LDI1MywyNDUpO3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpNb25hY287Y29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyBkb21haW5zLjwvc3Bhbj48L3ByZT4gPC9kaXY+PC9kaXY+PC9kaXY+PHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PC9wPjxkaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmks IE9jdCAxLCAyMDIxIGF0IDk6MzMgUE0gUm9uIEJvbmljYSAmbHQ7cmJvbmljYT08YSBocmVmPSJt YWlsdG86NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwanVu aXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8L3A+PC9kaXY+PGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlci10b3A6bm9uZTtib3JkZXItcmlnaHQ6bm9uZTtib3JkZXItYm90dG9t Om5vbmU7Ym9yZGVyLWxlZnQ6MXB0IHNvbGlkIHJnYigyMDQsMjA0LDIwNCk7cGFkZGluZzowaW4g MGluIDBpbiA2cHQ7bWFyZ2luOjVwdCAwaW4gNXB0IDQuOHB0Ij48ZGl2PjxkaXY+PHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB0Ij5DU0lEIEF1dGhvcnMsPC9z cGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0cHQi PiZuYnNwOzwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxNHB0Ij5Bc3N1bWUgdGhhdCBhbiBTUiBwYXRoIGNvbnRhaW5zIHNlZ21lbnRzIDEgdGhy b3VnaCA4LiBTZWdtZW50cyAxLCAzLCA1LCBhbmQgNyBhcmUgRU5EIFNJRHMgdGhhdCB1c2UgTmV4 dC1DLVNJRCAoaS5lLiwgdVNJRCkuIFNlZ21lbnRzIDIsIDQsIGFuZCA2IGFyZSBFTkQgU0lEcyB0 aGF0IHVzZSBSZXBsYWNlLUMtU0lELiBTZWdtZW50IDggaXMgYW5kIEVORC5EWDQgIFNJRC48L3Nw YW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTRwdCI+ Jm5ic3A7PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjE0cHQiPlBsZWFzZSBwcm92aWRlIGFuIGV4YW1wbGUgdGhhdCBzaG93cyB1czo8L3NwYW4+ PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTRwdCI+Jm5i c3A7PC9zcGFuPjwvcD48dWwgdHlwZT0iZGlzYyIgY2xhc3M9IiBsaXN0LXBhZGRpbmdsZWZ0LTIi PjxsaT48cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0cHQiPldoYXQgdGhlIFNSSCBsb29rcyBs aWtlIGFzIGl0IGFycml2ZXMgYXQgdGhlIGZpcnN0IHNlZ21lbnQgZW5kcG9pbnQ8L3NwYW4+PC9w PjwvbGk+PGxpPjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTRwdCI+V2hhdCB0aGUgSVB2NiBE ZXN0aW5hdGlvbiBBZGRyZXNzIGxvb2tzIGxpa2UgYXQgZWFjaCBzZWdtZW50IGVuZHBvaW50LCBp bmNsdWRpbmcgaW5mb3JtYXRpb24gcmVxdWlyZWQgdG8gcGFyc2UgdGhlIERlc3RpbmF0aW9uIEFk ZHJlc3M8L3NwYW4+PC9wPjwvbGk+PC91bD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjE0cHQiPiZuYnNwOzwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Um9uPC9zcGFuPjwvcD48cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0cHQiPiZuYnNwOzwvc3Bhbj48L3A+PHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPjxwIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtt YXJnaW46MGluOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3cHQ7Y29sb3I6YmxhY2siPkp1bmlw ZXIgQnVzaW5lc3MgVXNlIE9ubHk8L3NwYW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPSJNc29O b3JtYWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy PiBzcHJpbmcgbWFpbGluZyBsaXN0PGJyPiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4gPGEgaHJlZj0iaHR0cHM6 Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zcHJpbmdfXzshIU5FdDZ5TWFPLWdrIVVMX0xzVEVXdXlidGV3Y0lIWDJGd3JxdHdTM0c5N2tp M3R6SFQ4cEd5R2N4MmhQV1laZnJpU21lRzc1dXdQN2wkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8L2E+PC9wPjwvYmxvY2txdW90 ZT48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+PC9kaXY+ PC9ibG9ja3F1b3RlPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pjxw Pjxicj48L3A+PC9kaXY+ --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Sat Oct 2 18:13:08 2021 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 E97103A08D7; Sat, 2 Oct 2021 18:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 L-6yC6FwIZxm; Sat, 2 Oct 2021 18:13:00 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 DB56D3A08CF; Sat, 2 Oct 2021 18:12:58 -0700 (PDT) Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id 181129F9EAC860F494FF; Sun, 3 Oct 2021 09:12:57 +0800 (CST) Received: from kjyxapp01.zte.com.cn ([10.30.12.200]) by mse-fl2.zte.com.cn with SMTP id 1931Ct5Y073536; Sun, 3 Oct 2021 09:12:55 +0800 (GMT-8) (envelope-from liu.aihua@zte.com.cn) Received: from mapi (kjyxapp06[null]) by mapi (Zmail) with MAPI id mid13; Sun, 3 Oct 2021 09:12:55 +0800 (CST) Date: Sun, 3 Oct 2021 09:12:55 +0800 (CST) X-Zmail-TransId: 2b086159039755ee79bd X-Mailer: Zmail v1.0 Message-ID: <202110030912554837727@zte.com.cn> In-Reply-To: References: DM6PR13MB4204AEAF9D0F44DA0E4E0C4CD2AB9@DM6PR13MB4204.namprd13.prod.outlook.com Mime-Version: 1.0 From: To: Cc: , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl2.zte.com.cn 1931Ct5Y073536 Archived-At: Subject: Re: [spring] =?utf-8?q?WG_Adoption_call_for_https=3A//datatracker=2E?= =?utf-8?q?ietf=2Eorg/doc/draft-filsfilscheng-spring-srv6-srh-compression/?= 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, 03 Oct 2021 01:13:05 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgQ2hhaXJlcyBhbmQgV0csDQoNCg0KSSBzdXBwb3J0IHRvIGFkb3B0aW9uIHRoaXMgZHJhZnQu IEFzIHdlIGtub3duLCB0aGUgZHJhZnQgaGFzIGJlZW4gZGlzY3Vzc2VkIGluIHRoZSBEVCBmb3Ig bW9yZSB0aGFuIDIgeWVhcnMuIFRoZSByZXF1aXJlbWVudCBkcmFmdCBoYXMgYmVlbiBhY2NlcHRl ZCBhbmQgYWRvcHRlZCBieSBXRy4gVGhlIHNvbHV0aW9uIGNvbXBhdGlibGUgd2l0aCB0aGUgc3Rh bmRhcmQgU1J2NiBpcyBwcmVmZXJyZWQgZm9yIHRoZSBTUnY2IGNvbXByZXNzaW9uLCB0aGF0IGlz IHRoZSBzb2x1dGlvbiBwcm92aWRlZCBieSB0aGlzIGRyYWZ0LiBBbmQgSSB0aGluayB0aGUgc29s dXRpb24gcHJvcG9zZWQgYnkgdGhpcyBkcmFmdCBpcyBqdXN0IG9uZSBzb2x1dGlvbiB3aXRoIDIg Zmxhdm9ycywgd2hpY2ggc2hhcmUgdGhlIHNhbWUgU1J2NiBwcm9jZXNzZXMuIFRoZSBwcm92aWRl ci91c2VyIGNvdWxkIHVzZSB0aGUgZmxhdm9ycyBhY2NvcmRpbmcgdG8gdGhlaXIgU0lEIHBsYW5u aW5nLCBqdXN0IGxpa2UgdXNpbmcgb3RoZXIgZmxhdm9ycy4NCg0KDQoNCg0KDQoNCkJlc3QgcmVn YXJkcywNCg0KDQpBaWh1YQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCuWOn+Wni+mCruS7tg0KDQoN Cg0K5Y+R5Lu25Lq677yaSmFtZXNHdWljaGFyZA0K5pS25Lu25Lq677yaU1BSSU5HIFdHOw0K5oqE 6YCB5Lq677yac3ByaW5nLWNoYWlyc0BpZXRmLm9yZzsNCuaXpSDmnJ8g77yaMjAyMeW5tDEw5pyI MDHml6UgMjI6MDcNCuS4uyDpopgg77yaW3NwcmluZ10gV0cgQWRvcHRpb24gY2FsbCBmb3IgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmct c3J2Ni1zcmgtY29tcHJlc3Npb24vDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQoNCiANCg0K RGVhciBXRzoNCg0KDQogDQoNCg0KVGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGV4cHJlc3MgdGhl aXIgYXBwcmVjaWF0aW9uIGZvciBhbGwgdGhlIHJlc3BvbnNlcyByZWNlaXZlZCB0byBvdXIgZW1h aWxzIHdpdGggcmVmZXJlbmNlIHRvIGhvdyB0aGUgd29ya2luZyBncm91cCB3aXNoZXMgdG8gbW92 ZSBmb3J3YXJkIHdpdGggcmVzcGVjdCB0byBhIHNvbHV0aW9uIGZvciBTUnY2IGNvbXByZXNzaW9u Lg0KDQoNCiANCg0KDQpUaGUgYXBwYXJlbnQgaW5jbGluYXRpb24gb2YgdGhlIHdvcmtpbmcgZ3Jv dXAgaXMgdG8gdXNlIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNm aWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyBhcyB0aGUgYmFzaXMgZm9yIGl0 cyBjb21wcmVzc2lvbiBzdGFuZGFyZGl6YXRpb24gd29yay4gVGhhdCBpcyBwYXJ0IG9mIHdoYXQg dGhpcyBlbWFpbCBhdHRlbXB0cyB0byBjb25maXJtLg0KDQoNCiANCg0KDQpCZWNhdXNlIG9mIHRo ZSBhYm92ZSB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gaXNzdWUgYSAyLXdlZWsgV0cgY2FsbCBm b3IgYWRvcHRpb24gZW5kaW5nIE9jdG9iZXIgMTV0aCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Np b24vIGJ1dCB3aXRoIHNvbWUgY2xlYXIgZ3VpZGVsaW5lcyBhcyBmb2xsb3dzLiBCeSBleHByZXNz aW5nIHN1cHBvcnQgZm9yIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgeW91IGFyZSBmdWxseSBh d2FyZSBvZiBhbmQgYXJlIGFja25vd2xlZGdpbmcgdGhhdDoNCg0KDQogDQoNClRoZSBTUFJJTkcg d29ya2luZyBncm91cCBpcyBhZG9wdGluZyBhIGRvY3VtZW50IHRoYXQgaGFzIG11bHRpcGxlIFNS djYgRW5kcG9pbnQgYmVoYXZpb3JzLg0KDQpUaGUgZG9jdW1lbnQgaXMgYSDigJxsaXZpbmfigJ0g ZG9jdW1lbnQ7IGl0IG1heSBjaGFuZ2UgYXMgaXQgZ29lcyB0aHJvdWdoIHJldmlldyBhbmQgYW5h bHlzaXMgYnkgdGhlIFNQUklORyB3b3JraW5nIGdyb3VwLg0KDQpBbGwgb3BlbiBkaXNjdXNzaW9u IHBvaW50cyByYWlzZWQgb24gb3VyIG1haWxpbmcgbGlzdCBNVVNUIGJlIGFkZHJlc3NlZCBCRUZP UkUgc2FpZCBkb2N1bWVudCBpcyBhbGxvd2VkIHRvIHByb2dyZXNzIGZyb20gdGhlIHdvcmtpbmcg Z3JvdXAgdG8gcHVibGljYXRpb24uIEEgbGlzdCBvZiB0aGVzZSBkaXNjdXNzaW9uIHBvaW50cyB3 aWxsIGJlIGRvY3VtZW50ZWQgaW4gdGhlIFdHIGRvY3VtZW50IGFuZCBtYWludGFpbmVkIGJ5IHRo ZSBkb2N1bWVudCBlZGl0b3IgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgY2hhaXJzLg0KDQpJZiB0 aGlzIGRvY3VtZW50IGlzIGFkb3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAsIHRoZSBjaGFpcnMg c3BlY2lmeSBhcyBwYXJ0IG9mIHRoZSBhZG9wdGlvbiBjYWxsIHRoYXQgdGhlIGZvbGxvd2luZyB0 ZXh0IGRlc2NyaWJpbmcgYW4gb3BlbiBpc3N1ZSBiZSBhZGRlZCB0byB0aGUgZG9jdW1lbnQgaW4g dGhlIGFib3ZlLWRlc2NyaWJlZCBvcGVuIGlzc3VlcyBzZWN0aW9uOg0KDQoiR2l2ZW4gdGhhdCB0 aGUgd29ya2luZyBncm91cCBoYXMgc2FpZCB0aGF0IGl0IHdhbnRzIHRvIHN0YW5kYXJkaXplIG9u ZSBkYXRhIHBsYW5lIHNvbHV0aW9uLCBhbmQgZ2l2ZW4gdGhhdCB0aGUgZG9jdW1lbnQgY29udGFp bnMgbXVsdGlwbGUgU1J2NiBFbmRQb2ludCBiZWhhdmlvcnMgdGhhdCBzb21lIFdHIG1lbWJlcnMg aGF2ZSBzdGF0ZWQgYXJlIG11bHRpcGxlIGRhdGEgcGxhbmUgc29sdXRpb25zLCB0aGUgd29ya2lu ZyBncm91cCB3aWxsIGFkZHJlc3Mgd2hldGhlciB0aGlzIGlzIHZhbGlkIGFuZCBjb2hlcmVudCB3 aXRoIGl0cyBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiBvYmplY3RpdmUuIi4NCg0KDQogDQoNCg0K UGxlYXNlIGNvbnNpZGVyIHRoZSBhYm92ZSBndWlkZWxpbmVzIGFzIHlvdSBkZWNpZGUgb24gd2hl dGhlciB0byBzdXBwb3J0IG9yIG5vdCB0aGlzIFdHIGFkb3B0aW9uLiBQbGVhc2UgZXhwcmVzcyBj bGVhcmx5IHlvdXIgcmVhc29uaW5nIGZvciBzdXBwb3J0L25vbi1zdXBwb3J0IGFzIHdlbGwgYXMg YW55IG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgeW91IHdvdWxkIGxpa2UgYWRkcmVzc2VkIHNob3Vs ZCB0aGUgZG9jdW1lbnQgYmUgYWRvcHRlZCBpbnRvIHRoZSB3b3JraW5nIGdyb3VwLg0KDQoNCiAN Cg0KDQpUaGFua3MhDQoNCg0KIA0KDQoNCkppbSwgQnJ1bm8gJiBKb2Vs --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MTZweDtmb250LWZh bWlseTrlvq7ova/pm4Xpu5EsTWljcm9zb2Z0IFlhSGVpOyI+PGJyPjwvcD48cCBzdHlsZT0iZm9u dC1zaXplOjE2cHg7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buRLE1pY3Jvc29mdCBZYUhlaTsiPkhp IENoYWlyZXMgYW5kIFdHLDwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE2cHg7Zm9udC1mYW1pbHk6 5b6u6L2v6ZuF6buRLE1pY3Jvc29mdCBZYUhlaTsiPkkgc3VwcG9ydCB0byBhZG9wdGlvbiB0aGlz IGRyYWZ0LiBBcyB3ZSBrbm93biwgdGhlIGRyYWZ0IGhhcyBiZWVuIGRpc2N1c3NlZCBpbiB0aGUg RFQgZm9yIG1vcmUgdGhhbiAyIHllYXJzLiBUaGUgcmVxdWlyZW1lbnQgZHJhZnQgaGFzIGJlZW4g YWNjZXB0ZWQgYW5kIGFkb3B0ZWQgYnkgV0cuIFRoZSBzb2x1dGlvbiBjb21wYXRpYmxlIHdpdGgg dGhlIHN0YW5kYXJkIFNSdjYgaXMgcHJlZmVycmVkIGZvciB0aGUgU1J2NiBjb21wcmVzc2lvbiwg dGhhdCBpcyB0aGUgc29sdXRpb24gcHJvdmlkZWQgYnkgdGhpcyBkcmFmdC4gQW5kIEkgdGhpbmsg dGhlIHNvbHV0aW9uIHByb3Bvc2VkIGJ5IHRoaXMgZHJhZnQgaXMganVzdCBvbmUgc29sdXRpb24g d2l0aCAyIGZsYXZvcnMsIHdoaWNoIHNoYXJlIHRoZSBzYW1lIFNSdjYgcHJvY2Vzc2VzLiBUaGUg cHJvdmlkZXIvdXNlciBjb3VsZCB1c2UgdGhlIGZsYXZvcnMgYWNjb3JkaW5nIHRvIHRoZWlyIFNJ RCBwbGFubmluZywganVzdCBsaWtlIHVzaW5nIG90aGVyIGZsYXZvcnMuPC9wPjxwIHN0eWxlPSJm b250LXNpemU6MTZweDtmb250LWZhbWlseTrlvq7ova/pm4Xpu5EsTWljcm9zb2Z0IFlhSGVpOyI+ PGJyPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE2cHg7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buR LE1pY3Jvc29mdCBZYUhlaTsiPkJlc3QgcmVnYXJkcyw8L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZTox NnB4O2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kSxNaWNyb3NvZnQgWWFIZWk7Ij5BaWh1YTwvcD48 cCBzdHlsZT0iZm9udC1zaXplOjE2cHg7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buRLE1pY3Jvc29m dCBZYUhlaTsiPjxicj48L3A+PGRpdiBjbGFzcz0iek1haWxTaWduIiB1bm9uYW1lY2g9IuWImOeI seWNjjEwMDI0OTk5IiB1bm9uYW1lZW49ImxpdSBhaWh1YTEwMDI0OTk5Ij48L2Rpdj48ZGl2IGNs YXNzPSJ6TWFpbEZyb20iPjwvZGl2PjxkaXY+PGRpdiBjbGFzcz0iemhpc3RvcnlSb3ciIHN0eWxl PSJkaXNwbGF5OmJsb2NrIj48ZGl2IGNsYXNzPSJ6aGlzdG9yeURlcyIgc3R5bGU9IndpZHRoOiAx MDAlOyBoZWlnaHQ6IDI4cHg7IGxpbmUtaGVpZ2h0OiAyOHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiAj RTBFNUU5OyBjb2xvcjogIzEzODhGRjsgdGV4dC1hbGlnbjogY2VudGVyOyIgbGFuZ3VhZ2UtZGF0 YT0iSGlzdG9yeU9yZ1R4dCI+5Y6f5aeL6YKu5Lu2PC9kaXY+PGRpdiBpZD0iendyaXRlSGlzdG9y eUNvbnRhaW5lciI+PGRpdiBjbGFzcz0iY29udHJvbC1ncm91cCB6aGlzdG9yeVBhbmVsIj48ZGl2 IGNsYXNzPSJ6aGlzdG9yeUhlYWRlciIgc3R5bGU9InBhZGRpbmc6IDhweDsgYmFja2dyb3VuZC1j b2xvcjogI0Y1RjZGODsiPjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5U2VuZGVy VHh0Ij7lj5Hku7bkurrvvJo8L3N0cm9uZz48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSI+SmFt ZXNHdWljaGFyZDxqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20+PC9qYW1lcy5uLmd1aWNo YXJkQGZ1dHVyZXdlaS5jb20+PC9zcGFuPjwvZGl2PjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRh PSJIaXN0b3J5VE9UeHQiPuaUtuS7tuS6uu+8mjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJ6cmVhZFVz ZXJOYW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyI+U1BSSU5HIFdHPHNwcmluZ0BpZXRmLm9y Zz47PC9zcHJpbmdAaWV0Zi5vcmc+PC9zcGFuPjwvZGl2PjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1k YXRhPSJIaXN0b3J5Q0NUeHQiPuaKhOmAgeS6uu+8mjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJ6cmVh ZFVzZXJOYW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyI+c3ByaW5nLWNoYWlyc0BpZXRmLm9y ZzxzcHJpbmctY2hhaXJzQGlldGYub3JnPjs8L3NwcmluZy1jaGFpcnNAaWV0Zi5vcmc+PC9zcGFu PjwvZGl2PjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5RGF0ZVR4dCI+5pelIOac nyDvvJo8L3N0cm9uZz48c3BhbiBjbGFzcz0iIj4yMDIx5bm0MTDmnIgwMeaXpSAyMjowNzwvc3Bh bj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeVN1YmplY3RUeHQiPuS4 uyDpopgg77yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVGl0bGUiPjxzdHJvbmc+W3Nwcmlu Z10gV0cgQWRvcHRpb24gY2FsbCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vPC9zdHJvbmc+ PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXYgem1haWxidXNpbmVzcz0iYnVzaW5lc3NFeHRlcm5hbCI+ PC9kaXY+PGRpdiBjbGFzcz0iemhpc3RvcnlDb250ZW50Ij48ZGl2Pl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPnNwcmluZyZuYnNwO21haWxpbmcmbmJz cDtsaXN0PGJyPnNwcmluZ0BpZXRmLm9yZzxicj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NwcmluZzxicj48YnI+ICAgPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj48cCBj bGFzcz0iTXNvTm9ybWFsIj5EZWFyIFdHOjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjaGFpcnMg d291bGQgbGlrZSB0byBleHByZXNzIHRoZWlyIGFwcHJlY2lhdGlvbiBmb3IgYWxsIHRoZSByZXNw b25zZXMgcmVjZWl2ZWQgdG8gb3VyIGVtYWlscyB3aXRoIHJlZmVyZW5jZSB0byBob3cgdGhlIHdv cmtpbmcgZ3JvdXAgd2lzaGVzIHRvIG1vdmUgZm9yd2FyZCB3aXRoIHJlc3BlY3QgdG8gYSBzb2x1 dGlvbiBmb3IgU1J2NiBjb21wcmVzc2lvbi48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgYXBwYXJl bnQgaW5jbGluYXRpb24gb2YgdGhlIHdvcmtpbmcgZ3JvdXAgaXMgdG8gdXNlIDxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5n LXNydjYtc3JoLWNvbXByZXNzaW9uLyIgdGFyZ2V0PSJfYmxhbmsiPiBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21w cmVzc2lvbi88L2E+IGFzIHRoZSBiYXNpcyBmb3IgaXRzIGNvbXByZXNzaW9uIHN0YW5kYXJkaXph dGlvbiB3b3JrLiBUaGF0IGlzIHBhcnQgb2Ygd2hhdCB0aGlzIGVtYWlsIGF0dGVtcHRzIHRvIGNv bmZpcm0uPG86cD48L286cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVjYXVzZSBvZiB0aGUgYWJvdmUgdGhlIGNoYWly cyB3b3VsZCBsaWtlIHRvIGlzc3VlIGEgMi13ZWVrIFdHIGNhbGwgZm9yIGFkb3B0aW9uIGVuZGlu ZyBPY3RvYmVyIDE1PHN1cD50aDwvc3VwPiBmb3IgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJl c3Npb24vIiB0YXJnZXQ9Il9ibGFuayI+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLzwvYT4gYnV0 IHdpdGggc29tZSBjbGVhciBndWlkZWxpbmVzIGFzIGZvbGxvd3MuIEJ5IGV4cHJlc3Npbmcgc3Vw cG9ydCBmb3IgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCB5b3UgYXJlIGZ1bGx5IGF3YXJlIG9m IGFuZCBhcmUgYWNrbm93bGVkZ2luZyB0aGF0OjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0 YXJ0PSIxIiB0eXBlPSIxIiBjbGFzcz0iIGxpc3QtcGFkZGluZ2xlZnQtMiI+PGxpPjxwPlRoZSBT UFJJTkcgd29ya2luZyBncm91cCBpcyBhZG9wdGluZyBhIGRvY3VtZW50IHRoYXQgaGFzIG11bHRp cGxlIFNSdjYgRW5kcG9pbnQgYmVoYXZpb3JzLjwvcD48bzpwPjwvbzpwPjwvbGk+PGxpPjxwPlRo ZSBkb2N1bWVudCBpcyBhIOKAnGxpdmluZ+KAnSBkb2N1bWVudDsgaXQgbWF5IGNoYW5nZSBhcyBp dCBnb2VzIHRocm91Z2ggcmV2aWV3IGFuZCBhbmFseXNpcyBieSB0aGUgU1BSSU5HIHdvcmtpbmcg Z3JvdXAuPC9wPjxvOnA+PC9vOnA+PC9saT48bGk+PHA+QWxsIG9wZW4gZGlzY3Vzc2lvbiBwb2lu dHMgcmFpc2VkIG9uIG91ciBtYWlsaW5nIGxpc3QgTVVTVCBiZSBhZGRyZXNzZWQgQkVGT1JFIHNh aWQgZG9jdW1lbnQgaXMgYWxsb3dlZCB0byBwcm9ncmVzcyBmcm9tIHRoZSB3b3JraW5nIGdyb3Vw IHRvIHB1YmxpY2F0aW9uLiBBIGxpc3Qgb2YgdGhlc2UgZGlzY3Vzc2lvbiAgcG9pbnRzIHdpbGwg YmUgZG9jdW1lbnRlZCBpbiB0aGUgV0cgZG9jdW1lbnQgYW5kIG1haW50YWluZWQgYnkgdGhlIGRv Y3VtZW50IGVkaXRvciBpbiBjb25qdW5jdGlvbiB3aXRoIHRoZSBjaGFpcnMuPC9wPjxvOnA+PC9v OnA+PC9saT48bGk+PHA+SWYgdGhpcyBkb2N1bWVudCBpcyBhZG9wdGVkIGJ5IHRoZSB3b3JraW5n IGdyb3VwLCB0aGUgY2hhaXJzIHNwZWNpZnkgYXMgcGFydCBvZiB0aGUgYWRvcHRpb24gY2FsbCB0 aGF0IHRoZSBmb2xsb3dpbmcgdGV4dCBkZXNjcmliaW5nIGFuIG9wZW4gaXNzdWUgYmUgYWRkZWQg dG8gdGhlIGRvY3VtZW50IGluIHRoZSBhYm92ZS1kZXNjcmliZWQgIG9wZW4gaXNzdWVzIHNlY3Rp b246PC9wPjxvOnA+PC9vOnA+PC9saT48dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJk aXNjIiBjbGFzcz0iIGxpc3QtcGFkZGluZ2xlZnQtMiI+PGxpPjxwPiJHaXZlbiB0aGF0IHRoZSB3 b3JraW5nIGdyb3VwIGhhcyBzYWlkIHRoYXQgaXQgd2FudHMgdG8gc3RhbmRhcmRpemUgb25lIGRh dGEgcGxhbmUgc29sdXRpb24sIGFuZCBnaXZlbiB0aGF0IHRoZSBkb2N1bWVudCBjb250YWlucyBt dWx0aXBsZSBTUnY2IEVuZFBvaW50IGJlaGF2aW9ycyB0aGF0IHNvbWUgV0cgbWVtYmVycyBoYXZl IHN0YXRlZCBhcmUgIG11bHRpcGxlIGRhdGEgcGxhbmUgc29sdXRpb25zLCB0aGUgd29ya2luZyBn cm91cCB3aWxsIGFkZHJlc3Mgd2hldGhlciB0aGlzIGlzIHZhbGlkIGFuZCBjb2hlcmVudCB3aXRo IGl0cyBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiBvYmplY3RpdmUuIi48L3A+PG86cD48L286cD48 L2xpPjwvdWw+PC9vbD48cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD48 cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgY29uc2lkZXIgdGhlIGFib3ZlIGd1aWRlbGluZXMg YXMgeW91IGRlY2lkZSBvbiB3aGV0aGVyIHRvIHN1cHBvcnQgb3Igbm90IHRoaXMgV0cgYWRvcHRp b24uIFBsZWFzZSBleHByZXNzIGNsZWFybHkgeW91ciByZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9u LXN1cHBvcnQgYXMgd2VsbCBhcyBhbnkgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyB5b3Ugd291bGQg bGlrZSBhZGRyZXNzZWQgc2hvdWxkIHRoZSBkb2N1bWVudCAgYmUgYWRvcHRlZCBpbnRvIHRoZSB3 b3JraW5nIGdyb3VwLjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyE8bzpwPjwvbzpwPjwvcD48 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9y bWFsIj5KaW0sIEJydW5vICZhbXA7IEpvZWw8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48cD48 YnI+PC9wPjwvZGl2Pg== --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Sat Oct 2 21:13:30 2021 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 0B9C63A097B; Sat, 2 Oct 2021 21:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4CZotXL6DjIg; Sat, 2 Oct 2021 21:13:10 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0: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 9BECF3A09FD; Sat, 2 Oct 2021 21:13:10 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id 75so13327415pga.3; Sat, 02 Oct 2021 21:13:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=HivYyxYVY8ZQDE4XlA6FyZOmjA9tKTpgS9Z4wP7OC48=; b=PHVfqmok2jbDxsPfaFR/SIr3jApdtKMo252LlojURVOmxC8IZ8XaT7rgwSwmRNxLkU wWw9x+48hAUEwBCUU94bL74enUFHUcZrPdfF9+vrvDmGevtlmrs+vvtBBDvMRtnQfo/t wi9Y+bCIBPj4TjHvNIUibr25x+fWijJkSlFZSYHuydFFLWwN9yRfO/n/4Z55T5gI726R k7BwctGvF8caIJIjRbl6WGRc4/w1hfCqoe+fwR4u27R4TrDR11oH/JuXGlz3mdUTs5Mc lCBB8gXniID3Ah3WoUlzysniyo8kN5SOMcY8II5fxWPqWZ96hi3ojvnQCwOM8XdoURga u5IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=HivYyxYVY8ZQDE4XlA6FyZOmjA9tKTpgS9Z4wP7OC48=; b=UtoNhQfecXJJUHdEawqX8H+2Ven3LJLAYOXEDEWoEMhZU7JnSdfKeDyhqK74l9eDzb /eKN2tj6T/iDci5aAje1jEt1OFmDkcYtiIc0EDC8Q+9WTWC+sLUh8mR9X0DJ5bRUMEui 1X/kGHdDraG9gp+vagPH68zm4cMWS/GetomRUq5A4oJd3N0uyX7YRfcXOzsie3f/cF8E N9jAV7bGHBlxllKcwOmJJJcIvhdybq/UxUqx1y06Q+iD9F8qGzoWXzanIIVcZRGWAdP9 o85WbNqPGOcIz9E9MWANG+kuwUM9fm8B4xz1IBYEhhWNhFZnBh9NziTg5K7JhYJ/Ed18 cw6A== X-Gm-Message-State: AOAM533LPOIovpNLfK6CC/5C92zQDOSIAZ72i3NnLtNzFL1s+/za/Ilu iqhi8pGa4lM/z1tJEh2B2Ozv3GlN0/5ZDg== X-Google-Smtp-Source: ABdhPJzPHtjG8puIJUwP49iAyktywjM6vIvoiVOAP9Z6+kog7QN5z4F2wxS1D/GRlx+sdJHuiKjKDQ== X-Received: by 2002:aa7:9739:0:b0:449:56c4:4268 with SMTP id k25-20020aa79739000000b0044956c44268mr18001430pfg.43.1633234389691; Sat, 02 Oct 2021 21:13:09 -0700 (PDT) Received: from ?IPv6:2406:e003:11aa:d701:80b2:5c79:2266:e431? ([2406:e003:11aa:d701:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id v7sm9176615pjk.37.2021.10.02.21.13.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 Oct 2021 21:13:09 -0700 (PDT) To: Ron Bonica , "6man@ietf.org" <6man@ietf.org> Cc: SPRING WG References: From: Brian E Carpenter Message-ID: <6d4eff6d-6fdc-992e-3a01-13bce8b05cd0@gmail.com> Date: Sun, 3 Oct 2021 17:13:04 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 03 Oct 2021 04:13:15 -0000 Ron,=20 The first sentence cites RFC8402 which unambiguously describes SR as a limited domain protcol (limited to an "SR domain", that is.) So within such a domain, this describes using 128 bit quantities called Segment Identifiers that in some cases, but apparently not in the formats= defined here, has the same structure as an IP address. Does that harm the Internet, even if it leaks? It might disappoint the sender, as any sender of a bogus packet is disappointed, but apart from t= hat, who is damaged? Regards Brian Carpenter On 02-Oct-21 09:34, Ron Bonica wrote: > Folks, >=20 > =C2=A0 >=20 > Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new=20 SID types that can occupy the Destination Address field of an IPv6 header= =2E See Sections 4.1, 4.2, and 4.3 of the draft for details. >=20 > =C2=A0 >=20 > The SPRING WG has issued a call for adoption for this draft. >=20 > =C2=A0 >=20 > It is not clear that these SID types can be harmonized with the IPv6 ad= dressing architecture. >=20 > =C2=A0 >=20 > Does anyone have an opinion? >=20 > =C2=A0 >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Ron >=20 > =C2=A0 >=20 >=20 > Juniper Business Use Only >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Sun Oct 3 01:11:47 2021 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 9210A3A0BDD; Sun, 3 Oct 2021 01:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KOQEXCEdEOJl; Sun, 3 Oct 2021 01:11:35 -0700 (PDT) Received: from h3cspam01-ex.h3c.com (smtp.h3c.com [60.191.123.56]) (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 AEDB23A0BDF; Sun, 3 Oct 2021 01:11:32 -0700 (PDT) Received: from DAG2EX08-IDC.srv.huawei-3com.com ([10.8.0.71]) by h3cspam01-ex.h3c.com with ESMTP id 1938BIaJ072182; Sun, 3 Oct 2021 16:11:18 +0800 (GMT-8) (envelope-from linchangwang.04414@h3c.com) Received: from DAG2EX07-IDC.srv.huawei-3com.com (10.8.0.70) by DAG2EX08-IDC.srv.huawei-3com.com (10.8.0.71) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Sun, 3 Oct 2021 16:11:20 +0800 Received: from DAG2EX07-IDC.srv.huawei-3com.com ([::1]) by DAG2EX07-IDC.srv.huawei-3com.com ([fe80::5840:dd59:199d:711a%9]) with mapi id 15.01.2242.012; Sun, 3 Oct 2021 16:11:20 +0800 From: linchangwang To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade4LQEolf0Evl2pTT26Gwew2AlmNg== Date: Sun, 3 Oct 2021 08:11:20 +0000 Message-ID: <7f28d4e380a145ba9eae7addc2ba1beb@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: multipart/alternative; boundary="_000_7f28d4e380a145ba9eae7addc2ba1bebh3ccom_" MIME-Version: 1.0 X-DNSRBL: X-MAIL: h3cspam01-ex.h3c.com 1938BIaJ072182 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 03 Oct 2021 08:11:43 -0000 --_000_7f28d4e380a145ba9eae7addc2ba1bebh3ccom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBXRzoNCg0KICAgICBJIHN0cm9uZ2x5IHN1cHBvcnQgdGhlIGFkb3B0aW9uLg0KV2UgaW1w bGVtZW50ZWQgdGhlIEMtU0lEIHNvbHV0aW9uLCBhbmQgaXQgd29ya3MgdmVyeSB3ZWxsLiBGcm9t IGFuIGRlc2lnbiBlbmdpbmVlcnMgcGVyc3BlY3RpdmUsIENTSUQgaXMgYSBzaW5nbGUgU1J2NiBi YXNlZCBkYXRhIHBsYW5lIHNvbHV0aW9uLg0KVGhlIGRyYWZ0IGlzIHJlYWR5IGZvciB0aGUgV0cg YWRvcHRpb24uDQoNClRoYW5rcyENCg0KQ2hhbmd3YW5nIExpbg0KDQpOZXcgSDNDLg0KDQq3orz+ yMs6IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEphbWVzIEd1 aWNoYXJkDQq3osvNyrG85DogMjAyMcTqMTDUwjHI1SAyMjowNQ0KytW8/sjLOiBTUFJJTkcgV0cN CrOty806IHNwcmluZy1jaGFpcnNAaWV0Zi5vcmcNCtb3zOI6IFtzcHJpbmddIFdHIEFkb3B0aW9u IGNhbGwgZm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxz Y2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLw0KDQpEZWFyIFdHOg0KDQpUaGUgY2hh aXJzIHdvdWxkIGxpa2UgdG8gZXhwcmVzcyB0aGVpciBhcHByZWNpYXRpb24gZm9yIGFsbCB0aGUg cmVzcG9uc2VzIHJlY2VpdmVkIHRvIG91ciBlbWFpbHMgd2l0aCByZWZlcmVuY2UgdG8gaG93IHRo ZSB3b3JraW5nIGdyb3VwIHdpc2hlcyB0byBtb3ZlIGZvcndhcmQgd2l0aCByZXNwZWN0IHRvIGEg c29sdXRpb24gZm9yIFNSdjYgY29tcHJlc3Npb24uDQoNClRoZSBhcHBhcmVudCBpbmNsaW5hdGlv biBvZiB0aGUgd29ya2luZyBncm91cCBpcyB0byB1c2UgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24v IGFzIHRoZSBiYXNpcyBmb3IgaXRzIGNvbXByZXNzaW9uIHN0YW5kYXJkaXphdGlvbiB3b3JrLiBU aGF0IGlzIHBhcnQgb2Ygd2hhdCB0aGlzIGVtYWlsIGF0dGVtcHRzIHRvIGNvbmZpcm0uDQoNCkJl Y2F1c2Ugb2YgdGhlIGFib3ZlIHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBpc3N1ZSBhIDItd2Vl ayBXRyBjYWxsIGZvciBhZG9wdGlvbiBlbmRpbmcgT2N0b2JlciAxNXRoIGZvciBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNy aC1jb21wcmVzc2lvbi8gYnV0IHdpdGggc29tZSBjbGVhciBndWlkZWxpbmVzIGFzIGZvbGxvd3Mu IEJ5IGV4cHJlc3Npbmcgc3VwcG9ydCBmb3IgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCB5b3Ug YXJlIGZ1bGx5IGF3YXJlIG9mIGFuZCBhcmUgYWNrbm93bGVkZ2luZyB0aGF0Og0KDQoNCiAgMS4g IFRoZSBTUFJJTkcgd29ya2luZyBncm91cCBpcyBhZG9wdGluZyBhIGRvY3VtZW50IHRoYXQgaGFz IG11bHRpcGxlIFNSdjYgRW5kcG9pbnQgYmVoYXZpb3JzLg0KICAyLiAgVGhlIGRvY3VtZW50IGlz IGEgobBsaXZpbmehsSBkb2N1bWVudDsgaXQgbWF5IGNoYW5nZSBhcyBpdCBnb2VzIHRocm91Z2gg cmV2aWV3IGFuZCBhbmFseXNpcyBieSB0aGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAuDQogIDMuICBB bGwgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyByYWlzZWQgb24gb3VyIG1haWxpbmcgbGlzdCBNVVNU IGJlIGFkZHJlc3NlZCBCRUZPUkUgc2FpZCBkb2N1bWVudCBpcyBhbGxvd2VkIHRvIHByb2dyZXNz IGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAgdG8gcHVibGljYXRpb24uIEEgbGlzdCBvZiB0aGVzZSBk aXNjdXNzaW9uIHBvaW50cyB3aWxsIGJlIGRvY3VtZW50ZWQgaW4gdGhlIFdHIGRvY3VtZW50IGFu ZCBtYWludGFpbmVkIGJ5IHRoZSBkb2N1bWVudCBlZGl0b3IgaW4gY29uanVuY3Rpb24gd2l0aCB0 aGUgY2hhaXJzLg0KICA0LiAgSWYgdGhpcyBkb2N1bWVudCBpcyBhZG9wdGVkIGJ5IHRoZSB3b3Jr aW5nIGdyb3VwLCB0aGUgY2hhaXJzIHNwZWNpZnkgYXMgcGFydCBvZiB0aGUgYWRvcHRpb24gY2Fs bCB0aGF0IHRoZSBmb2xsb3dpbmcgdGV4dCBkZXNjcmliaW5nIGFuIG9wZW4gaXNzdWUgYmUgYWRk ZWQgdG8gdGhlIGRvY3VtZW50IGluIHRoZSBhYm92ZS1kZXNjcmliZWQgb3BlbiBpc3N1ZXMgc2Vj dGlvbjoNCiAgICAgKiAgICJHaXZlbiB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBzYWlkIHRo YXQgaXQgd2FudHMgdG8gc3RhbmRhcmRpemUgb25lIGRhdGEgcGxhbmUgc29sdXRpb24sIGFuZCBn aXZlbiB0aGF0IHRoZSBkb2N1bWVudCBjb250YWlucyBtdWx0aXBsZSBTUnY2IEVuZFBvaW50IGJl aGF2aW9ycyB0aGF0IHNvbWUgV0cgbWVtYmVycyBoYXZlIHN0YXRlZCBhcmUgbXVsdGlwbGUgZGF0 YSBwbGFuZSBzb2x1dGlvbnMsIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYWRkcmVzcyB3aGV0aGVy IHRoaXMgaXMgdmFsaWQgYW5kIGNvaGVyZW50IHdpdGggaXRzIG9uZSBkYXRhIHBsYW5lIHNvbHV0 aW9uIG9iamVjdGl2ZS4iLg0KDQpQbGVhc2UgY29uc2lkZXIgdGhlIGFib3ZlIGd1aWRlbGluZXMg YXMgeW91IGRlY2lkZSBvbiB3aGV0aGVyIHRvIHN1cHBvcnQgb3Igbm90IHRoaXMgV0cgYWRvcHRp b24uIFBsZWFzZSBleHByZXNzIGNsZWFybHkgeW91ciByZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9u LXN1cHBvcnQgYXMgd2VsbCBhcyBhbnkgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyB5b3Ugd291bGQg bGlrZSBhZGRyZXNzZWQgc2hvdWxkIHRoZSBkb2N1bWVudCBiZSBhZG9wdGVkIGludG8gdGhlIHdv cmtpbmcgZ3JvdXAuDQoNClRoYW5rcyENCg0KSmltLCBCcnVubyAmIEpvZWwNCg0KDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQqxvtPKvP68sMbkuL28/rqs09DQwruqyP28r83FtcSxo8Pc0MXPoqOsvfbP 3tPat6LLzbj4yc/D5rXY1rfW0MHQs/YNCrXEuPbIy7vyyLrX6aGjvfvWucjOus7G5Mv7yMvS1MjO us7Qzsq9yrnTw6OosPzAqLWrsrvP3tPayKuyv7vysr+31rXY0LnCtqGiuLTWxqGiDQq78smit6Kj qbG+08q8/tbQtcTQxc+ioaPI57n7xPq07crVwcuxvtPKvP6jrMfrxPrBory0tee7sLvy08q8/s2o 1qq3orz+yMuyosm+s/2xvg0K08q8/qOhDQpUaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRz IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uIGZyb20gTmV3IEgzQywgd2hpY2ggaXMN CmludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMg bGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZQ0KaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVp biBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFy dGlhbA0KZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBieSBwZXJz b25zIG90aGVyIHRoYW4gdGhlIGludGVuZGVkDQpyZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4g SWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlcg0KYnkgcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCENCg== --_000_7f28d4e380a145ba9eae7addc2ba1bebh3ccom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Dear WG:

 

     I strongly support the adoption.

We implemented the C-SID solution, an= d it works very well. From an design engineers perspective, CSID is a singl= e SRv6 based data plane solution.

The draft is ready for the WG adoptio= n.

 

Thanks!

 

Changwang Lin

 

New H3C.

 

=B7=A2=BC=FE=C8=CB: spring = [mailto:spring-bounces@ietf.org] =B4=FA= =B1=ED James Guichard
=B7=A2= =CB=CD=CA=B1=BC=E4: 2021=C4=EA10=D4=C21=C8=D5 22:05
=CA=D5=BC=FE=C8=CB: SPRING WG
=B3=AD=CB=CD: spring-chairs@ietf.org
=D6=F7=CC=E2: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-fils= filscheng-spring-srv6-srh-compression/

 

Dear WG:

 

The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a sol= ution for SRv6 compression.

 

The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document that has multiple SRv6 = Endpoint behaviors.
  2. The document is a =A1=B0living=A1=B1 document; i= t may change as it goes through review and analysis by the SPRING working g= roup.
  3. All open discussion points raised on our mailing= list MUST be addressed BEFORE said document is allowed to progress from th= e working group to publication. A list of these discussion points will be documented in the WG document and maintained by the document edito= r in conjunction with the chairs.
  4. If this document is adopted by the working group= , the chairs specify as part of the adoption call that the following text d= escribing an open issue be added to the document in the above-described open issues section:
    • "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution obj= ective.".

 

Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open d= iscussion points you would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

-------------------------------------------------= ---------------------------------------------------------------------------= ---------
=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=D0=C2=BB=AA= =C8=FD=BC=AF=CD=C5=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7= =A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6
=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE= =C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0= =A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6= =A1=A2=B8=B4=D6=C6=A1=A2
=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2= =A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4= =FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB= =B2=A2=C9=BE=B3=FD=B1=BE
=D3=CA=BC=FE=A3=A1
This e-mail and its attac= hments contain confidential information from New H3C, 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! --_000_7f28d4e380a145ba9eae7addc2ba1bebh3ccom_-- From nobody Sun Oct 3 04:56:08 2021 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 692283A084B; Sun, 3 Oct 2021 04:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 sDGzh80aUGpX; Sun, 3 Oct 2021 04:55:59 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E137E3A0848; Sun, 3 Oct 2021 04:55:57 -0700 (PDT) X-Envelope-To: 6man@ietf.org Received: from crumpet.local ([194.88.241.230]) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 193BtmwB090649 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Oct 2021 12:55:50 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host [194.88.241.230] claimed to be crumpet.local To: Brian E Carpenter Cc: Ron Bonica , "6man@ietf.org" <6man@ietf.org>, SPRING WG References: <6d4eff6d-6fdc-992e-3a01-13bce8b05cd0@gmail.com> From: Nick Hilliard Message-ID: Date: Sun, 3 Oct 2021 12:55:47 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.49 MIME-Version: 1.0 In-Reply-To: <6d4eff6d-6fdc-992e-3a01-13bce8b05cd0@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 03 Oct 2021 11:56:04 -0000 Brian E Carpenter wrote on 03/10/2021 05:13: > Does that harm the Internet, even if it leaks? It might disappoint the > sender, as any sender of a bogus packet is disappointed, but apart from that, > who is damaged? in the smaller sense, limited domain leakage will happen and if the destination addresses of packets are routinely changed, then this provides the opportunity for potentially serious data leakage. It would be a good idea to note this in the security section of the draft. It would be a mistake, I think, to dismiss this as a configuration issue and then claim that the ietf is not in the business of telling people not to make mistakes. It's more a case of an existing failsafe mechanism being removed entirely. This is a poor idea from both an engineering design point of view and in multiple senses from the point of view of the principle of least astonishment. In the bigger scheme of things, it's becoming difficult to reconcile whether srv6 is strictly compatible with ipv6. It's understandable to want to declare the existence of a limited domain, throw everything in there, apply a different set of rules and claim that it's all ok, but there is now a wedge firmly jammed in between rfc8200 and srv6, which is being prised open further by drafts like this which introduce more, and more substantial semantic incompatibilities. Rather than concentrating on this draft, it would be a better idea for the ietf to ask where does this path lead that we are going down. There's no issue developing a protocol like SRv6 at the ietf, but if drafts of this sort are progressed as-is, it looks likely that that at a certain point, the differences between SRv6 and rfc8200 will be large enough that it's going to cause pain points for them to share a common code point of 6 in the IANA IP version number registry. This would be in noone's benefit. Nick From nobody Sun Oct 3 06:17:41 2021 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 65C793A0931; Sun, 3 Oct 2021 06:17:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 XHPU2kEAjprv; Sun, 3 Oct 2021 06:17:24 -0700 (PDT) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 26FA53A0922; Sun, 3 Oct 2021 06:17:24 -0700 (PDT) Received: by mail-wm1-x32f.google.com with SMTP id z184-20020a1c7ec1000000b003065f0bc631so16595686wmc.0; Sun, 03 Oct 2021 06:17:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=Ot55QdL5/sDHeQASHgy2DMotBNLuhNmK7IzCGeo0iMg=; b=fU7IY9jUlAKFXl+trvR3z1SZO7CNQ6MIOdLHmk/rG89s/dKGLOJnNmDVuRnuNxy40D zXIEGLf0JfsUjFk5z7HTu64k3wCT7uNZSKqhQ9FCRdp5lJCoLmnybwW1BTF4dmPddZwF omlocEsSWsE+djF1BJaSwUbcVzOGLV8viT0Mzv461bxKwFxFb8KuDx8YFTtrPSHdgJ7Z FIy89cA5HlUU9UYS0R01bM1DHDlnU33FDvT+k2CGWSQ9hZZrLzI8KT8Uf0N+vT8aQao7 ZxMGgJGoMk0lFn2F1DL6cfgy3HpGiQHz8h8DeI7iP3Rqp14xfHJDtiRFPXSJbpUu9yZR QoEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=Ot55QdL5/sDHeQASHgy2DMotBNLuhNmK7IzCGeo0iMg=; b=qa0jgCW6GxqIQv0NVGrtkGj7vbDR2LLswCeJPXkp6aoSSMPEYbArhVjXV1t94U877b YNqwicjzzzm18rHhLzswRtQqeRLSdLsuMIyGyZG1hNe8ie4jUwfrHkMrIxdfBkGrrtdp FyMTicwDu7/Gxko+Wyl5kWQ/7Wwyu6GmE1xgR47IE+4pD2bzhqt1NYnyQqwV8Vq6YRP4 iStOelRp9GtRoxvJn4IgIiKsuwXRGfddN6sWIP2tHIFMVsU1ugQAPJMA1Uxx1SjgJ7Vr Av6wR32DP2vkH13o/ntWSfneVRBfIvPhy4b6yujaEQDYWNx3VKnlB1rB2UrQUgWtXWff VHPQ== X-Gm-Message-State: AOAM533bYL3dseV/FPxiovKEpRz0UGS82mhiGjbgKBue/iQVYzHbIdwP 1dTx+IW5cflcebl9StI8BNk5prDxuww= X-Google-Smtp-Source: ABdhPJzNsUdn5IJ6y+0w/twwyR324rWb+qb3ot7zH/POQ0GKOMENsfcW6Ys242ED1gGwqvVpQZEdSQ== X-Received: by 2002:a1c:a512:: with SMTP id o18mr13772310wme.162.1633267042105; Sun, 03 Oct 2021 06:17:22 -0700 (PDT) Received: from smtpclient.apple (188.30.215.253.threembb.co.uk. [188.30.215.253]) by smtp.gmail.com with ESMTPSA id d129sm14546791wmd.23.2021.10.03.06.17.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 03 Oct 2021 06:17:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Mike Simpson Mime-Version: 1.0 (1.0) Date: Sun, 3 Oct 2021 14:17:18 +0100 Message-Id: <95AE1DB8-4FA1-47A6-BFCE-73248C6074EC@gmail.com> References: <6d4eff6d-6fdc-992e-3a01-13bce8b05cd0@gmail.com> Cc: Ron Bonica , 6man@ietf.org, SPRING WG In-Reply-To: <6d4eff6d-6fdc-992e-3a01-13bce8b05cd0@gmail.com> To: Brian E Carpenter X-Mailer: iPhone Mail (19A344) Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 03 Oct 2021 13:17:31 -0000 Given that every time a vendor suggests altering the fundamentals of the ipv= 6 header the reason given for not just using encapsulation and therefore avo= iding upsetting the 2 decades worth of running kit is to save the few bytes o= f overhead it would produce.=20 1) Do we not have enough bogus packets on the internets.=20 And=20 2) just because you can=E2=80=99t define the =E2=80=9Charm it will cause=E2=80= =9D doesn=E2=80=99t mean that it=E2=80=99s not going to cause harm.=20 Man generally seems quite fallible imho.=20 > On 3 Oct 2021, at 05:13, Brian E Carpenter w= rote: >=20 > =EF=BB=BFRon,=20 >=20 > The first sentence cites RFC8402 which unambiguously describes SR as a > limited domain protcol (limited to an "SR domain", that is.) >=20 > So within such a domain, this describes using 128 bit quantities called > Segment Identifiers that in some cases, but apparently not in the formats > defined here, has the same structure as an IP address. >=20 > Does that harm the Internet, even if it leaks? It might disappoint the > sender, as any sender of a bogus packet is disappointed, but apart from th= at, > who is damaged? >=20 > Regards > Brian Carpenter >=20 >> On 02-Oct-21 09:34, Ron Bonica wrote: >> Folks, >>=20 >> =20 >>=20 >> Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new=20= > SID types that can occupy the Destination Address field of an IPv6 header.= See Sections 4.1, 4.2, and 4.3 of the draft for details. >>=20 >> =20 >>=20 >> The SPRING WG has issued a call for adoption for this draft. >>=20 >> =20 >>=20 >> It is not clear that these SID types can be harmonized with the IPv6 addr= essing architecture. >>=20 >> =20 >>=20 >> Does anyone have an opinion? >>=20 >> =20 >>=20 >> = Ron >>=20 >> =20 >>=20 >>=20 >> Juniper Business Use Only >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >>=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sun Oct 3 07:26:49 2021 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 C103A3A0AD1 for ; Sun, 3 Oct 2021 07:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 MEEhOWKeyzyL for ; Sun, 3 Oct 2021 07:25:37 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 549153A0ADF for ; Sun, 3 Oct 2021 07:25:35 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id v4so2022852vsg.12 for ; Sun, 03 Oct 2021 07:25:35 -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=Z/Ckc2e9a4W2CsmT4ZeyIR7wVLRi3tQVOVX1UBiw1No=; b=Qg4Jutvpasbm66hHDrdvtc+cyEWZv6OGsWzkDN3rvQFARK4mPeK/FTm8H4SGN8pZln MFHlx1Wi+y1721ghWvOJhYKqgib+z6+xjmJqAflu62pr9D0HVCWcfjDXu5yWyKiLWuXl mFrfR6KJOj2vnI1rH+UEtcbFfypXuSzOT1lLjyFD1EwlpWKR1obeagc07e4cZcnhQak9 6Tbkmq1su8OH6v2quImjryIY+Hwon3A+24+aYMrcqPEwcVM1amKjH24vBHSO6ezkpu5S mBipbXaICzOOzGHR5OAfCNWM2v09gn3qbaFPxuwWC5pghhHJbsZWCbVOC4vJgWqI1c9c rdyw== 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=Z/Ckc2e9a4W2CsmT4ZeyIR7wVLRi3tQVOVX1UBiw1No=; b=uZ6YKB7q0e00MGNXfsw9Rlh+dDaKL45Y5MfxPs9lTa+ii8e4dQJbLdngHqy63ksoCq SroAZs7lkaJfH+1sbBiw8yi/JCTtx/imQbGCF9q61I3gMiQ+wncJtt30J1LxcRbZSMvP 1ggaDznWQ0ZYuA3g715Df55cafDBXPZsnLrGHKhdjijlRky+Zt371q3DCnUMeYAD45EC QPjZH3o++YBNbf5wm2V0VVs3AcXw+FXMAOPxEtxOezfeGlPWmP/4Eu8b0Wy+FMTFBy1D +5Zj4X/kYqA2iHJfmU4bwexkx1U31C+s7PLUlfd9iZ7tKDdSBCcb6PxeYHTXU8Ra1N+G e4Sg== X-Gm-Message-State: AOAM532SomDQlqZbiZtv5vROZpzZQMBE742G1O/YCrNv5KlUF2BVSZCP 8Z4DF+8Qc0Ju329Gfw+NXsJ00xQzh7XCVDGamiwT+w== X-Google-Smtp-Source: ABdhPJxa6P5KPE+WCQDPFkw4S6Sz7LQSpFRptkTmVJPMr43t7nr9KyfjHEsSMB6Dh/j0+60+duQYJ0LCv5BUQ6dOuSE= X-Received: by 2002:a67:ab48:: with SMTP id k8mr7400636vsh.30.1633271134725; Sun, 03 Oct 2021 07:25:34 -0700 (PDT) MIME-Version: 1.0 References: <6d4eff6d-6fdc-992e-3a01-13bce8b05cd0@gmail.com> <95AE1DB8-4FA1-47A6-BFCE-73248C6074EC@gmail.com> In-Reply-To: <95AE1DB8-4FA1-47A6-BFCE-73248C6074EC@gmail.com> From: Robert Raszuk Date: Sun, 3 Oct 2021 16:25:25 +0200 Message-ID: To: Mike Simpson , Ron Bonica , Nick Hilliard Cc: SPRING WG , 6man <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000ceb8bd05cd73919d" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 03 Oct 2021 14:25:44 -0000 --000000000000ceb8bd05cd73919d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Mike, > for not just using encapsulation Please kindly note that SRv6 (and all discussions about SRv6) already happen in the *encapsulated header* - not in the native header of the packet. Nick, As to the concerns of "escaping packets" - this draft is no more of a concern then RFC8986. Ron, As to the concerns of purity violation of IPv6 addressing - this draft is also no more of a concern then RFC8986. Thx, R. On Sun, Oct 3, 2021 at 3:17 PM Mike Simpson wrote= : > Given that every time a vendor suggests altering the fundamentals of the > ipv6 header the reason given for not just using encapsulation and therefo= re > avoiding upsetting the 2 decades worth of running kit is to save the few > bytes of overhead it would produce. > > 1) Do we not have enough bogus packets on the internets. > And > 2) just because you can=E2=80=99t define the =E2=80=9Charm it will cause= =E2=80=9D doesn=E2=80=99t mean > that it=E2=80=99s not going to cause harm. > > Man generally seems quite fallible imho. > > > On 3 Oct 2021, at 05:13, Brian E Carpenter > wrote: > > > > =EF=BB=BFRon, > > > > The first sentence cites RFC8402 which unambiguously describes SR as a > > limited domain protcol (limited to an "SR domain", that is.) > > > > So within such a domain, this describes using 128 bit quantities called > > Segment Identifiers that in some cases, but apparently not in the forma= ts > > defined here, has the same structure as an IP address. > > > > Does that harm the Internet, even if it leaks? It might disappoint the > > sender, as any sender of a bogus packet is disappointed, but apart from > that, > > who is damaged? > > > > Regards > > Brian Carpenter > > > >> On 02-Oct-21 09:34, Ron Bonica wrote: > >> Folks, > >> > >> > >> > >> Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three ne= w > > SID types that can occupy the Destination Address field of an IPv6 > header. See Sections 4.1, 4.2, and 4.3 of the draft for details. > >> > >> > >> > >> The SPRING WG has issued a call for adoption for this draft. > >> > >> > >> > >> It is not clear that these SID types can be harmonized with the IPv6 > addressing architecture. > >> > >> > >> > >> Does anyone have an opinion? > >> > >> > >> > >> > Ron > >> > >> > >> > >> > >> Juniper Business Use Only > >> > >> > >> -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> -------------------------------------------------------------------- > >> > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000ceb8bd05cd73919d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mike,

> for not just using encaps= ulation=C2=A0

Please kindly note that SRv6 (an= d all discussions about SRv6) already happen in the *encapsulated header* -= not in the native header of the packet.=C2=A0

Nic= k,

As to the concerns of "escaping packets&qu= ot; - this draft is no more of a concern then RFC8986.=C2=A0

=
Ron,

As to the concerns of purity viola= tion of IPv6 addressing - this draft is also no more of a concern then RFC8= 986.=C2=A0

Thx,
R.

<= div>




<= div>


On Sun, Oct 3, 2021 at 3:17 PM Mike Simpson &= lt;mikie.simpson@gmail.com&g= t; wrote:
Given = that every time a vendor suggests altering the fundamentals of the ipv6 hea= der the reason given for not just using encapsulation and therefore avoidin= g upsetting the 2 decades worth of running kit is to save the few bytes of = overhead it would produce.

1) Do we not have enough bogus packets on the internets.
And
2) just because you can=E2=80=99t define the =E2=80=9Charm it will cause=E2= =80=9D doesn=E2=80=99t mean that it=E2=80=99s not going to cause harm.

Man generally seems quite fallible imho.

> On 3 Oct 2021, at 05:13, Brian E Carpenter <brian.e.carpenter@gmail.com&g= t; wrote:
>
> =EF=BB=BFRon,
>
> The first sentence cites RFC8402 which unambiguously describes SR as a=
> limited domain protcol (limited to an "SR domain", that is.)=
>
> So within such a domain, this describes using 128 bit quantities calle= d
> Segment Identifiers that in some cases, but apparently not in the form= ats
> defined here, has the same structure as an IP address.
>
> Does that harm the Internet, even if it leaks? It might disappoint the=
> sender, as any sender of a bogus packet is disappointed, but apart fro= m that,
> who is damaged?
>
> Regards
>=C2=A0 =C2=A0Brian Carpenter
>
>> On 02-Oct-21 09:34, Ron Bonica wrote:
>> Folks,
>>
>>=C2=A0
>>
>> Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces thre= e new
> SID types that can occupy the Destination Address field of an IPv6 hea= der. See Sections 4.1, 4.2, and 4.3 of the draft for details.
>>
>>=C2=A0
>>
>> The SPRING WG has issued a call for adoption for this draft.
>>
>>=C2=A0
>>
>> It is not clear that these SID types can be harmonized with the IP= v6 addressing architecture.
>>
>>=C2=A0
>>
>> Does anyone have an opinion?
>>
>>=C2=A0
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Ron
>>
>>=C2=A0
>>
>>
>> Juniper Business Use Only
>>
>>
>> ------------------------------------------------------------------= --
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mai= lman/listinfo/ipv6
>> ------------------------------------------------------------------= --
>>
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--000000000000ceb8bd05cd73919d-- From nobody Sun Oct 3 10:19:40 2021 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 EC5E33A08C4; Sun, 3 Oct 2021 10:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.328 X-Spam-Level: X-Spam-Status: No, score=-1.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, INVALID_MSGID=0.568, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 e_G8SUn8nuc0; Sun, 3 Oct 2021 10:19:30 -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 B2E5A3A08B6; Sun, 3 Oct 2021 10:19:29 -0700 (PDT) Received: from fraeml745-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HMr9l1Y5lz67Lx4; Mon, 4 Oct 2021 01:16:43 +0800 (CST) Received: from kwepeml100006.china.huawei.com (7.221.188.192) by fraeml745-chm.china.huawei.com (10.206.15.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Sun, 3 Oct 2021 19:19:23 +0200 Received: from kwepeml500003.china.huawei.com (7.221.188.182) 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.8; Mon, 4 Oct 2021 01:19:21 +0800 Received: from kwepeml500003.china.huawei.com ([7.221.188.182]) by kwepeml500003.china.huawei.com ([7.221.188.182]) with mapi id 15.01.2308.008; Mon, 4 Oct 2021 01:19:21 +0800 From: "Yangfan(Fan,IP Standards)" To: James Guichard , SPRING WG CC: spring-chairs Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQBrvGgV Date: Sun, 3 Oct 2021 17:19:21 +0000 Message-ID: AFF6EC51-731F-4DD9-AF7F-B25EE073665E References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_AFF6EC51731F4DD9AF7FB25EE073665E_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 03 Oct 2021 17:19:36 -0000 --_000_AFF6EC51731F4DD9AF7FB25EE073665E_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3ByaW5nLA0KDQpJIGhhdmUgcmVhZCB0aGUgZHJhZnQsIGFuZCBJIHRoaW5rIGl0IGlzIHdl bGwtd3JpdHRlbiBhbmQgbWF0dXJlIGVub3VnaCB0byBiZSBhZG9wdGVkLiBDU0lEIGNhbiBiZSBh IGdvb2QgYmFzaXMgZm9yIFNSdjYgY29tcHJlc3Npb24sIGxldCdzIGFkb3B0IGl0IGFuZCBtb3Zl IGZvcndhcmQuIE1vcmUgaXNzdWVzIGNhbiBiZSBhZGRyZXNzZWQgaW4gdGhlIHN0YW5kYXJkIHBy b2dyZXNzLg0KDQpCZXN0IHJlZ2FyZHMsDQpGYW4NCg0KDQrlj5Hku7bkurrvvJpKYW1lcyBHdWlj aGFyZCA8amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPg0K5pS25Lu25Lq677yaU1BSSU5H IFdHIDxzcHJpbmdAaWV0Zi5vcmc+DQrmioTigIPpgIHvvJpzcHJpbmctY2hhaXJzIDxzcHJpbmct Y2hhaXJzQGlldGYub3JnPg0K5pe24oCD6Ze077yaMjAyMS0xMC0wMSAyMjowNjowNw0K5Li74oCD 6aKY77yaW3NwcmluZ10gV0cgQWRvcHRpb24gY2FsbCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Np b24vDQoNCkRlYXIgV0c6DQoNClRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBleHByZXNzIHRoZWly IGFwcHJlY2lhdGlvbiBmb3IgYWxsIHRoZSByZXNwb25zZXMgcmVjZWl2ZWQgdG8gb3VyIGVtYWls cyB3aXRoIHJlZmVyZW5jZSB0byBob3cgdGhlIHdvcmtpbmcgZ3JvdXAgd2lzaGVzIHRvIG1vdmUg Zm9yd2FyZCB3aXRoIHJlc3BlY3QgdG8gYSBzb2x1dGlvbiBmb3IgU1J2NiBjb21wcmVzc2lvbi4N Cg0KVGhlIGFwcGFyZW50IGluY2xpbmF0aW9uIG9mIHRoZSB3b3JraW5nIGdyb3VwIGlzIHRvIHVz ZSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNw cmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8gYXMgdGhlIGJhc2lzIGZvciBpdHMgY29tcHJlc3Np b24gc3RhbmRhcmRpemF0aW9uIHdvcmsuIFRoYXQgaXMgcGFydCBvZiB3aGF0IHRoaXMgZW1haWwg YXR0ZW1wdHMgdG8gY29uZmlybS4NCg0KQmVjYXVzZSBvZiB0aGUgYWJvdmUgdGhlIGNoYWlycyB3 b3VsZCBsaWtlIHRvIGlzc3VlIGEgMi13ZWVrIFdHIGNhbGwgZm9yIGFkb3B0aW9uIGVuZGluZyBP Y3RvYmVyIDE1dGggZm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZp bHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyBidXQgd2l0aCBzb21lIGNs ZWFyIGd1aWRlbGluZXMgYXMgZm9sbG93cy4gQnkgZXhwcmVzc2luZyBzdXBwb3J0IGZvciBhZG9w dGlvbiBvZiB0aGlzIGRvY3VtZW50IHlvdSBhcmUgZnVsbHkgYXdhcmUgb2YgYW5kIGFyZSBhY2tu b3dsZWRnaW5nIHRoYXQ6DQoNCg0KICAxLiAgVGhlIFNQUklORyB3b3JraW5nIGdyb3VwIGlzIGFk b3B0aW5nIGEgZG9jdW1lbnQgdGhhdCBoYXMgbXVsdGlwbGUgU1J2NiBFbmRwb2ludCBiZWhhdmlv cnMuDQogIDIuICBUaGUgZG9jdW1lbnQgaXMgYSDigJxsaXZpbmfigJ0gZG9jdW1lbnQ7IGl0IG1h eSBjaGFuZ2UgYXMgaXQgZ29lcyB0aHJvdWdoIHJldmlldyBhbmQgYW5hbHlzaXMgYnkgdGhlIFNQ UklORyB3b3JraW5nIGdyb3VwLg0KICAzLiAgQWxsIG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgcmFp c2VkIG9uIG91ciBtYWlsaW5nIGxpc3QgTVVTVCBiZSBhZGRyZXNzZWQgQkVGT1JFIHNhaWQgZG9j dW1lbnQgaXMgYWxsb3dlZCB0byBwcm9ncmVzcyBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIHRvIHB1 YmxpY2F0aW9uLiBBIGxpc3Qgb2YgdGhlc2UgZGlzY3Vzc2lvbiBwb2ludHMgd2lsbCBiZSBkb2N1 bWVudGVkIGluIHRoZSBXRyBkb2N1bWVudCBhbmQgbWFpbnRhaW5lZCBieSB0aGUgZG9jdW1lbnQg ZWRpdG9yIGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIGNoYWlycy4NCiAgNC4gIElmIHRoaXMgZG9j dW1lbnQgaXMgYWRvcHRlZCBieSB0aGUgd29ya2luZyBncm91cCwgdGhlIGNoYWlycyBzcGVjaWZ5 IGFzIHBhcnQgb2YgdGhlIGFkb3B0aW9uIGNhbGwgdGhhdCB0aGUgZm9sbG93aW5nIHRleHQgZGVz Y3JpYmluZyBhbiBvcGVuIGlzc3VlIGJlIGFkZGVkIHRvIHRoZSBkb2N1bWVudCBpbiB0aGUgYWJv dmUtZGVzY3JpYmVkIG9wZW4gaXNzdWVzIHNlY3Rpb246DQogICAgICogICAiR2l2ZW4gdGhhdCB0 aGUgd29ya2luZyBncm91cCBoYXMgc2FpZCB0aGF0IGl0IHdhbnRzIHRvIHN0YW5kYXJkaXplIG9u ZSBkYXRhIHBsYW5lIHNvbHV0aW9uLCBhbmQgZ2l2ZW4gdGhhdCB0aGUgZG9jdW1lbnQgY29udGFp bnMgbXVsdGlwbGUgU1J2NiBFbmRQb2ludCBiZWhhdmlvcnMgdGhhdCBzb21lIFdHIG1lbWJlcnMg aGF2ZSBzdGF0ZWQgYXJlIG11bHRpcGxlIGRhdGEgcGxhbmUgc29sdXRpb25zLCB0aGUgd29ya2lu ZyBncm91cCB3aWxsIGFkZHJlc3Mgd2hldGhlciB0aGlzIGlzIHZhbGlkIGFuZCBjb2hlcmVudCB3 aXRoIGl0cyBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiBvYmplY3RpdmUuIi4NCg0KUGxlYXNlIGNv bnNpZGVyIHRoZSBhYm92ZSBndWlkZWxpbmVzIGFzIHlvdSBkZWNpZGUgb24gd2hldGhlciB0byBz dXBwb3J0IG9yIG5vdCB0aGlzIFdHIGFkb3B0aW9uLiBQbGVhc2UgZXhwcmVzcyBjbGVhcmx5IHlv dXIgcmVhc29uaW5nIGZvciBzdXBwb3J0L25vbi1zdXBwb3J0IGFzIHdlbGwgYXMgYW55IG9wZW4g ZGlzY3Vzc2lvbiBwb2ludHMgeW91IHdvdWxkIGxpa2UgYWRkcmVzc2VkIHNob3VsZCB0aGUgZG9j dW1lbnQgYmUgYWRvcHRlZCBpbnRvIHRoZSB3b3JraW5nIGdyb3VwLg0KDQpUaGFua3MhDQoNCkpp bSwgQnJ1bm8gJiBKb2VsDQoNCg0K --_000_AFF6EC51731F4DD9AF7FB25EE073665E_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hh cnNldD1XaW5kb3dzLTEyNTIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNy b3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+DQo8IS0tDQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgifQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpDYWxpYnJpfQ0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWZ9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxh aW5UZXh0DQoJe21hcmdpbjowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZn0NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFn cmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWZ9DQpzcGFuLkVt YWlsU3R5bGUxNw0KCXtmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe2ZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmfQ0KLk1zb0NocERlZmF1bHQNCgl7Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWZ9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGlufQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbn0NCnVs DQoJe21hcmdpbi1ib3R0b206MGlufQ0KLS0+DQo8L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFw OmJyZWFrLXdvcmQiPg0KPHN0eWxlIHR5cGU9InRleHQvY3NzIj4NCjwhLS0NCioNCgl7fQ0KYm9k eQ0KCXtmb250LWZhbWlseTpDYWxpYnJpfQ0KLS0+DQo8L3N0eWxlPg0KPGRpdj4NCjxkaXYgaWQ9 ImZvY3VzIj4NCjxkaXY+SGkgU3ByaW5nLDxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8ZGl2PkkgaGF2ZSByZWFkIHRoZSBkcmFmdCwgYW5kIEkgdGhpbmsgaXQgaXMgd2Vs bC13cml0dGVuIGFuZCBtYXR1cmUgZW5vdWdoIHRvIGJlIGFkb3B0ZWQuIENTSUQgY2FuIGJlIGEg Z29vZCBiYXNpcyBmb3IgU1J2NiBjb21wcmVzc2lvbiwgbGV0J3MgYWRvcHQgaXQgYW5kIG1vdmUg Zm9yd2FyZC4gTW9yZSBpc3N1ZXMgY2FuIGJlIGFkZHJlc3NlZCBpbiB0aGUgc3RhbmRhcmQgcHJv Z3Jlc3MuPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkJlc3QgcmVnYXJk cyw8L2Rpdj4NCjxkaXY+RmFuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PjwvZGl2Pg0KPGRpdiBuYW1lPSJBbnlPZmZpY2Ut QmFja2dyb3VuZC1JbWFnZSIgc3R5bGU9ImJvcmRlci10b3A6MXB4IHNvbGlkICNCNUM0REY7IHBh ZGRpbmc6OHB4Ij4NCjxkaXYgc3R5bGU9IndvcmQtYnJlYWs6YnJlYWstYWxsIj48Yj7lj5Hku7bk urrvvJo8L2I+SmFtZXMgR3VpY2hhcmQgJmx0O2phbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNv bSZndDs8L2Rpdj4NCjxkaXYgc3R5bGU9IndvcmQtYnJlYWs6YnJlYWstYWxsIj48Yj7mlLbku7bk urrvvJo8L2I+U1BSSU5HIFdHICZsdDtzcHJpbmdAaWV0Zi5vcmcmZ3Q7PC9kaXY+DQo8ZGl2IHN0 eWxlPSJ3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PGI+5oqE4oCD6YCB77yaPC9iPnNwcmluZy1jaGFp cnMgJmx0O3NwcmluZy1jaGFpcnNAaWV0Zi5vcmcmZ3Q7PC9kaXY+DQo8ZGl2IHN0eWxlPSJ3b3Jk LWJyZWFrOmJyZWFrLWFsbCI+PGI+5pe24oCD6Ze077yaPC9iPjIwMjEtMTAtMDEgMjI6MDY6MDc8 L2Rpdj4NCjxkaXYgc3R5bGU9IndvcmQtYnJlYWs6YnJlYWstYWxsIj48Yj7kuLvigIPpopjvvJo8 L2I+W3NwcmluZ10gV0cgQWRvcHRpb24gY2FsbCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24v PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRlYXIgV0c6PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGNoYWlycyB3 b3VsZCBsaWtlIHRvIGV4cHJlc3MgdGhlaXIgYXBwcmVjaWF0aW9uIGZvciBhbGwgdGhlIHJlc3Bv bnNlcyByZWNlaXZlZCB0byBvdXIgZW1haWxzIHdpdGggcmVmZXJlbmNlIHRvIGhvdyB0aGUgd29y a2luZyBncm91cCB3aXNoZXMgdG8gbW92ZSBmb3J3YXJkIHdpdGggcmVzcGVjdCB0byBhIHNvbHV0 aW9uIGZvciBTUnY2IGNvbXByZXNzaW9uLg0KPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGFwcGFyZW50IGluY2xpbmF0aW9uIG9m IHRoZSB3b3JraW5nIGdyb3VwIGlzIHRvIHVzZSA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVz c2lvbi8iPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNj aGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vPC9hPiBhcyB0aGUgYmFzaXMgZm9yIGl0 cyBjb21wcmVzc2lvbiBzdGFuZGFyZGl6YXRpb24gd29yay4gVGhhdCBpcyBwYXJ0IG9mIHdoYXQg dGhpcyBlbWFpbCBhdHRlbXB0cyB0byBjb25maXJtLjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlY2F1c2Ugb2YgdGhlIGFib3ZlIHRo ZSBjaGFpcnMgd291bGQgbGlrZSB0byBpc3N1ZSBhIDItd2VlayBXRyBjYWxsIGZvciBhZG9wdGlv biBlbmRpbmcgT2N0b2JlciAxNTxzdXA+dGg8L3N1cD4gZm9yDQo8YSBocmVmPSJodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNy aC1jb21wcmVzc2lvbi8iPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt Zmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vPC9hPiBidXQgd2l0aCBz b21lIGNsZWFyIGd1aWRlbGluZXMgYXMgZm9sbG93cy4gQnkgZXhwcmVzc2luZyBzdXBwb3J0IGZv ciBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IHlvdSBhcmUgZnVsbHkgYXdhcmUgb2YgYW5kIGFy ZSBhY2tub3dsZWRnaW5nIHRoYXQ6DQo8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 L3A+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiI+DQo8bGkg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW4iPlRoZSBTUFJJ Tkcgd29ya2luZyBncm91cCBpcyBhZG9wdGluZyBhIGRvY3VtZW50IHRoYXQgaGFzIG11bHRpcGxl IFNSdjYgRW5kcG9pbnQgYmVoYXZpb3JzLg0KPC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW4iPlRoZSBkb2N1bWVudCBpcyBhIOKAnGxpdmluZ+KA nSBkb2N1bWVudDsgaXQgbWF5IGNoYW5nZSBhcyBpdCBnb2VzIHRocm91Z2ggcmV2aWV3IGFuZCBh bmFseXNpcyBieSB0aGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAuDQo8L2xpPjxsaSBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbiI+QWxsIG9wZW4gZGlzY3Vzc2lv biBwb2ludHMgcmFpc2VkIG9uIG91ciBtYWlsaW5nIGxpc3QgTVVTVCBiZSBhZGRyZXNzZWQgQkVG T1JFIHNhaWQgZG9jdW1lbnQgaXMgYWxsb3dlZCB0byBwcm9ncmVzcyBmcm9tIHRoZSB3b3JraW5n IGdyb3VwIHRvIHB1YmxpY2F0aW9uLiBBIGxpc3Qgb2YgdGhlc2UgZGlzY3Vzc2lvbiBwb2ludHMg d2lsbCBiZSBkb2N1bWVudGVkDQogaW4gdGhlIFdHIGRvY3VtZW50IGFuZCBtYWludGFpbmVkIGJ5 IHRoZSBkb2N1bWVudCBlZGl0b3IgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgY2hhaXJzLg0KPC9s aT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW4iPklm IHRoaXMgZG9jdW1lbnQgaXMgYWRvcHRlZCBieSB0aGUgd29ya2luZyBncm91cCwgdGhlIGNoYWly cyBzcGVjaWZ5IGFzIHBhcnQgb2YgdGhlIGFkb3B0aW9uIGNhbGwgdGhhdCB0aGUgZm9sbG93aW5n IHRleHQgZGVzY3JpYmluZyBhbiBvcGVuIGlzc3VlIGJlIGFkZGVkIHRvIHRoZSBkb2N1bWVudCBp biB0aGUgYWJvdmUtZGVzY3JpYmVkIG9wZW4gaXNzdWVzDQogc2VjdGlvbjoNCjx1bCB0eXBlPSJk aXNjIiBzdHlsZT0ibWFyZ2luLXRvcDowaW4iPg0KPGxpIGNsYXNzPSJNc29QbGFpblRleHQiIHN0 eWxlPSIiPiZxdW90O0dpdmVuIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHNhaWQgdGhhdCBp dCB3YW50cyB0byBzdGFuZGFyZGl6ZSBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiwgYW5kIGdpdmVu IHRoYXQgdGhlIGRvY3VtZW50IGNvbnRhaW5zIG11bHRpcGxlIFNSdjYgRW5kUG9pbnQgYmVoYXZp b3JzIHRoYXQgc29tZSBXRyBtZW1iZXJzIGhhdmUgc3RhdGVkIGFyZSBtdWx0aXBsZSBkYXRhIHBs YW5lIHNvbHV0aW9ucywNCiB0aGUgd29ya2luZyBncm91cCB3aWxsIGFkZHJlc3Mgd2hldGhlciB0 aGlzIGlzIHZhbGlkIGFuZCBjb2hlcmVudCB3aXRoIGl0cyBvbmUgZGF0YSBwbGFuZSBzb2x1dGlv biBvYmplY3RpdmUuJnF1b3Q7LjwvbGk+PC91bD4NCjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBjb25zaWRlciB0 aGUgYWJvdmUgZ3VpZGVsaW5lcyBhcyB5b3UgZGVjaWRlIG9uIHdoZXRoZXIgdG8gc3VwcG9ydCBv ciBub3QgdGhpcyBXRyBhZG9wdGlvbi4gUGxlYXNlIGV4cHJlc3MgY2xlYXJseSB5b3VyIHJlYXNv bmluZyBmb3Igc3VwcG9ydC9ub24tc3VwcG9ydCBhcyB3ZWxsIGFzIGFueSBvcGVuIGRpc2N1c3Np b24gcG9pbnRzIHlvdSB3b3VsZCBsaWtlIGFkZHJlc3NlZCBzaG91bGQgdGhlIGRvY3VtZW50DQog YmUgYWRvcHRlZCBpbnRvIHRoZSB3b3JraW5nIGdyb3VwLjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyE8L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KaW0sIEJydW5v ICZhbXA7IEpvZWw8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_AFF6EC51731F4DD9AF7FB25EE073665E_-- From nobody Sun Oct 3 12:01:05 2021 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 8626F3A0B89; Sun, 3 Oct 2021 12:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OomKQ9OtVkQt; Sun, 3 Oct 2021 12:00:49 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 8732E3A0B67; Sun, 3 Oct 2021 12:00:49 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id x8so2423376plv.8; Sun, 03 Oct 2021 12:00:49 -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=ijKUAuNlc4uoXhPe//soSZ2VJieBk1TFfL+OdU2ejvA=; b=mmMe8jW7R+0wg+SBqdH//CippkVKSkZT8uWEilns4fjUdQHeLXjffRDakzTKNYtiv2 hLmnLGEc4KU1zeFGQOjARc396QrY4bwH1w5uLW/eEkRtLHEiXSOcjwnzdNTHp7UHjnO7 gYV0g+nsuvejgfSyaMGGuvBWXr6h4HO+G3M0783kWz/GXVTd14qsnWxrx1X6/YHIrY1y BL0OUNCQtzuIpqN8E0BnXGeCAdP7dTjP4SojgP96iyOz8U95BN9w6geOsfc+o0IXvIly sror0v54sMmev2iEL/FSHP89Ao17OAdVlvaCxmINRW1c8VIrFE7kVSOTvbIIf2Y8EpaX MTRA== 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=ijKUAuNlc4uoXhPe//soSZ2VJieBk1TFfL+OdU2ejvA=; b=zgWzO+7EsjQnClP6qPAfnY8Wb7Al3S4p84NoBMCcP5SNZdRQTBFpnH5GF+UrjuGN/9 2TfbBISOhoIEr/0IuZrzF5ulEbq/7FGXxU6vkwg9DOy66Y5fOTWByM6aHq+ttPm9xFWF OlGnSy+yzz/r2UcepbqAbAxx2z7R2iq4O2mjqWTUy939H0jFocPwcItIaHyebqs/Eoc9 5NHLno/5209TZ184KIX1mdFDMx1WmVKS+7lxyjHlwPWqPTLyaSiHgIq5iyi3LgbxkW4N 44rS1byfvk8oS903HWy+UIRv49eMwa2fdo6iMYGuV/Up3Xrnvh4XsjNut9sQNxZTsP6m eCug== X-Gm-Message-State: AOAM532s22Idhllxli/gZc0UzhiHS7wGxuhjnYOMBmEf1KX+vRrV1u6w C2l6MEzsHhwcWeKCN6CMR6ns3e6f/DcEUO88Pjo= X-Google-Smtp-Source: ABdhPJzfiNMy4wPJSoLDYDNgGON8kPPk0gyteJkOdFXgymKkfbIXtOWIRcolXE6Uff9AFwvhAsm1czMHbmIYbvxWgvk= X-Received: by 2002:a17:90a:4306:: with SMTP id q6mr32340147pjg.202.1633287648658; Sun, 03 Oct 2021 12:00:48 -0700 (PDT) MIME-Version: 1.0 References: <202110021255323466813813@chinamobile.com> In-Reply-To: <202110021255323466813813@chinamobile.com> From: Gyan Mishra Date: Sun, 3 Oct 2021 15:00:37 -0400 Message-ID: To: Yisong Liu Cc: James Guichard , SPRING WG , spring-chairs Content-Type: multipart/alternative; boundary="0000000000001d47ab05cd776adb" Archived-At: Subject: Re: [spring] =?utf-8?q?RE=EF=BC=9A_WG_Adoption_call_for_https=3A//da?= =?utf-8?q?tatracker=2Eietf=2Eorg/doc/draft-filsfilscheng-spring-srv6-srh-?= =?utf-8?q?compression/?= 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, 03 Oct 2021 19:00:59 -0000 --0000000000001d47ab05cd776adb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yisong The main goal for operators is interoperability. As interoperability is the key reason for a single SRv6 compression solution that we have WG consensus and is desired. Continued details of the interoperability study should be added to the draft as the study progresses. One key detail that is missing is forwarding efficiency and scalability using NEXT-C-SID and REPLACE-C-SID interoperability using 16 bit SID. As NEXT-CSID uSID Container Micro Segment shift flavor using GIB/LIB for ultra scale SRv6 compression solution is recommended for 16 bit SID and REPLACE-C-SID G-SID G-SID Container based solution is recommended for 32 bit SID. Of all the requirements as stated, the encapsulation header size is the primary objective for operators to eliminate MSD issues with optimal forwarding and state efficiencies. At this time in order for Next and Replace solutions to be interoperable keeping in mind requirements for optimal forwarding and state efficiency 32 bit SID would be the lowest common denominator which should be stated as the baseline result of the analysis draft on CSID overall 2 prong solution. CSID draft: https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh-c= ompression-02#section-11 Bottom of section 11: The interoperability was validated for the following scenario: o Packet forwarding through a traffic engineering segment list combining, in the same SRH ([RFC8754 ]), SRv6 SIDs bound to an endpoint behavior with the NEXT-C-SID flavor and SRv6 SIDs bound to an endpoint behavior with the REPLACE-C-SID flavor. Further interoperability testing is ongoing and will be reported in this document as the work progresses. King Regards Gyan On Sat, Oct 2, 2021 at 12:56 AM Yisong Liu wrote: > Hi Chairs & WG, > > I strongly support the adoption call. Regarding chair's note in the email= , > I would like to point that the network programming model (RFC8996) by > nature defines multiple behaviors. CSID has a single SRv6 based data plan= e > that defines the next and replace behaviors consistent with the network > programming paradigm. > > CSID's next and replace behaviors have been verified by interoperability > test in China mobile laboratory and there is no problem with the > interworking of the two behaviors on the CSID dataplane. > > Best Regards > Yisong > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: James Guichard > =E6=97=B6=E9=97=B4: 2021/10/01(=E6=98=9F=E6=9C=9F=E4=BA=94)22:04 > =E6=94=B6=E4=BB=B6=E4=BA=BA: SPRING WG ; > =E6=8A=84=E9=80=81=E4=BA=BA: spring-chairs ; > =E4=B8=BB=E9=A2=98: [spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > Dear WG: > > > > The chairs would like to express their appreciation for all the responses > received to our emails with reference to how the working group wishes to > move forward with respect to a solution for SRv6 compression. > > > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > as the basis for its compression standardization work. That is part of wh= at > this email attempts to confirm. > > > > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging > that: > > > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change = as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the working > group to publication. A list of these discussion points will be docume= nted > in the WG document and maintained by the document editor in conjunctio= n > with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text describin= g an > open issue be added to the document in the above-described open issues > section: > - "Given that the working group has said that it wants to > standardize one data plane solution, and given that the document co= ntains > multiple SRv6 EndPoint behaviors that some WG members have stated a= re > multiple data plane solutions, the working group will address wheth= er this > is valid and coherent with its one data plane solution objective.". > > > > Please consider the above guidelines as you decide on whether to support > or not this WG adoption. Please express clearly your reasoning for > support/non-support as well as any open discussion points you would like > addressed should the document be adopted into the working group. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > _______________________________________________ > 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* --0000000000001d47ab05cd776adb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi=C2=A0Yisong

The main goal for operators is interoper= ability.=C2=A0 As interoperability is the key reason for a single SRv6 comp= ression solution that we have WG consensus and is desired. =C2=A0

Continued details of the interoperabilit= y study =C2=A0should be added to the draft as the study progresses.

One key detail that is missing is forw= arding efficiency and scalability using NEXT-C-SID and REPLACE-C-SID intero= perability using 16 bit SID. =C2=A0

As NEXT-CSID uSID Container Micro Segment shift flavor using GIB/LIB f= or ultra scale =C2=A0SRv6 compression solution is recommended for 16 bit SI= D and REPLACE-C-SID G-SID G-SID Container based solution is recommended for= 32 bit SID.

<= /div>
Of all the require= ments as stated, the encapsulation header size is the primary objective for= operators to eliminate MSD issues with optimal forwarding and state effici= encies.=C2=A0

=
At this time in o= rder for Next and Replace solutions to be interoperable keeping in mind req= uirements for optimal forwarding and state efficiency 32 bit SID would be t= he lowest common denominator which should be stated as the baseline result = of the analysis draft on CSID overall 2 prong solution.

CSID draft:
Bottom of section 11:


=C2=A0 =C2=A0The interope= rability was validated for the following scenario:
   o  Packet forwarding through a traffic engineering segment list
      combining, in the same SRH ([RFC8754]), SRv6 SIDs bound to an
      endpoint behavior with the NEXT-C-SID flavor and SRv6 SIDs bound
      to an endpoint behavior with the REPLACE-C-SID flavor.

   Further interoperability testing is ongoing and will be reported in
   this document as the work progresses.

King Regards=C2=A0

Gyan
On Sat, Oct 2, 2021 at 12:56 AM Yisong Liu <liuyisong@chinamobile.com> wro= te:
Hi Chairs & WG,<= /div>

I = strongly support the adoption call. Regarding chair's note in the email= , I would like to point that the network programming model (RFC8996) by nat= ure defines multiple behaviors. CSID has a single SRv6 based data plane tha= t defines the next and replace behaviors consistent with the network progra= mming paradigm.

C= SID's next and replace behaviors have been verified by=C2=A0interoperabili= ty test=C2=A0in China mobile laboratory and there is no problem with the interworking of = the two behaviors on the CSID dataplane.

Be= st Regards
Yisong
=C2=A0
=E5=8F=91=E4=BB=B6=E4=BA=BA: James Guichard
=E6=94=B6=E4=BB=B6=E4=BA=BA: SPRING= WG;
=E6=8A=84=E9=80=81=E4=BA=BA: spring-chairs;

Dear WG:

=C2=A0

The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

=C2=A0

The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

=C2=A0

Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

=C2=A0

  1. The SPRING working group is adopting a docume= nt that has multiple SRv6 Endpoint behaviors.
  2. The document is a =E2=80= =9Cliving=E2=80=9D document; it may change as it goes through review and an= alysis by the SPRING working group.
  3. All open discussion points= raised on our mailing list MUST be addressed BEFORE said document is allow= ed to progress from the working group to publication. A list of these discu= ssion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
  4. If this document is adopte= d by the working group, the chairs specify as part of the adoption call tha= t the following text describing an open issue be added to the document in t= he above-described open issues section:
    • "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

=C2=A0

Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

=C2=A0

Thanks!

=C2=A0

Jim, Bruno & Joel

=C2=A0

=C2=A0

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--
--0000000000001d47ab05cd776adb-- From nobody Sun Oct 3 13:02:11 2021 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 5957A3A0BC6; Sun, 3 Oct 2021 13:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OM9cpe5Mx3qj; Sun, 3 Oct 2021 13:01:40 -0700 (PDT) Received: from mail-pj1-x1030.google.com (mail-pj1-x1030.google.com [IPv6:2607:f8b0:4864:20::1030]) (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 A03BC3A0BB6; Sun, 3 Oct 2021 13:01:40 -0700 (PDT) Received: by mail-pj1-x1030.google.com with SMTP id pg10so9613173pjb.5; Sun, 03 Oct 2021 13:01:40 -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=kJqDTWQD4F+vuN0oWXIe6529m2udL8vaQF6mfRaisHo=; b=lJSd2g8PKIUMiu1au+9D2/LRtjTaFFLXbNUlahM8X4Wr47LEhta3E26dYJSb5asVu+ 0Fe5Iom7uGTh+rZvpQre4bn0IT1UjxEM2p2o1lPYzKvhzuTf0MoLKNa4KUeDDm1S3CXi 5kHmiDTEXhkKWV3SwmrzHPNVYTr9p1bmB+OTq8QJVShzS98+PifDXPwiBQeb6wtUNqW8 l58dQ9t0e3tEQRKyXHtwFXsrhJpGJPzvFgxZkiYOtURyS/P7Y6MbnTw7PwqttD9Ko/SJ AINEE+HZZELR9PV5POTCggOLKdQZBVnOWG8Chfps2z1XbYZQNEqKmZSet5N7K1gyIbl5 Fn/Q== 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=kJqDTWQD4F+vuN0oWXIe6529m2udL8vaQF6mfRaisHo=; b=tPVhLlTxWC8FmozFo3gYtbQNQoncbGn0L5AtPUbTrcNoJ82hjVLemTzKK73PcCIUsv Iumf5zNUV0x1vY8Ieh0OvxHu8OjzjppT9U7cKp1eKXZJsDn/GPceSGGEiSWCQuMQNMLQ /MdT1R0uuEVWxLzAmuMcjHo/jRQ7PlG5eWeDSVlJIkiQzP3xByVz86M3lsFqN2NZ8RHH UEZ5907z1hHAQgSLLpc8NIPEtJHUiWCSyULAZh9v6W2r92HIKzp6WD4HczsMvNbewiPq 9/581ETD0Rk8yHH7Q59fh0n8Ykrzvge5P1rwIszABYxBSeSWbfy1Hv4zpQ0Jn+McZ08I eo+Q== X-Gm-Message-State: AOAM532I7r67f3B3a9kChD6COeb+qtitC4PedxLnKc8EJOqKRqR5IbTp W7aNi+X/R4orfmZVdVfuZl9EUauA8rpOnUWt0jkQb3xY X-Google-Smtp-Source: ABdhPJwaCbqzVasOOiksEJObnrUAB8SZ9d2W17alpo1ziWNQ1AWqWUoikjaE62BxYElYDYH3ooXAihw+L+8yv6fo1KY= X-Received: by 2002:a17:90b:1642:: with SMTP id il2mr26236744pjb.167.1633291299848; Sun, 03 Oct 2021 13:01:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Sun, 3 Oct 2021 16:01:28 -0400 Message-ID: To: "Darren Dukes (ddukes)" Cc: SPRING WG , "srcomp@ietf.org" Content-Type: multipart/alternative; boundary="000000000000be043205cd784396" Archived-At: Subject: Re: [spring] [srcomp] compression analysis draft question on proposals analyzed 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, 03 Oct 2021 20:01:55 -0000 --000000000000be043205cd784396 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Darren & Authors In addition to that editorial fix can we take below into account and addressed in the draft. The main goal for operators is interoperability. As interoperability is the key reason for a single SRv6 compression solution that we have WG consensus and is highly desired. Continued details of the interoperability study should be added to the draft as the study progresses to section 11. One key detail that is missing is forwarding efficiency and scalability using NEXT-C-SID and REPLACE-C-SID interoperability using 16 bit SID. As NEXT-CSID uSID Container Micro Segment shift flavor using GIB/LIB for ultra scale SRv6 compression solution is recommended for 16 bit SID and REPLACE-C-SID G-SID G-SID Container based solution is recommended for 32 bit SID. Of all the requirements as stated, the encapsulation header size is the primary objective for operators to eliminate MSD issues, keeping in mind maximizing header reduction at optimal forwarding at line rate and state efficiencies. At this time in order for Next and Replace solutions to be interoperable keeping in mind requirements for optimal forwarding and state efficiency 32 bit SID would be the lowest common denominator between the two solutions which should be stated as the baseline result of the analysis draft and added to interoperability section. Verbiage should state that with the CSID overall 2 prong next and replace SID solution that in reality the 32 bit SID would be the optimal lowest common denominator recommended SID length for interoperability. The draft should be updated to make more homogeneous between the two solutions. Also if it=E2=80=99s possible that uSID GIB/LIB concept can be applied to G= -SID solution to optimize the hardware forwarding and start efficiency to make 16 bit SID viable and recommended G-SID / Replace SID solution. As stated the primary goal is optimal header size reduction to tackle MSD issues with interoperability taken into account as CSID is a 2 solution -> solution. Kind Regards Gyan On Mon, Sep 27, 2021 at 1:23 PM Darren Dukes (ddukes) wrote: > Was: Re: [spring] > draft-filsfilscheng-spring-srv6-srh-compression-02#section-4.1.1 > > > > I=E2=80=99m sending this note to redirect this question to the srcomp DT = for an > editorial fix, when the team meets next. > > > > For the DT: > > Each proposal, introduced in section 1, discusses how it supports 16-bit > and 32-bit SIDs. However, Gyan=E2=80=99s question indicates this could be= more > clearly stated in the analysis draft to help readers less familiar with a > proposal. As such, section 1 can be improved accordingly. > > > > Darren > > > > On 2021-09-24, 1:32 PM, "spring" wrote: > > > > Gyan, > > > > You raise a very good point. In the analysis document, Tables 1 through 6 > and Tables 12 through 15 each contain only one column for the CSID. They = do > not indicate whether the number in that column were calculated using the > NEXT-C-SID, REPLACE-C-SID, or NEXT-AND-REPLACE-C-SID. (That is, the do no= t > indicate whether they were calculated using uSID, G-SID, or a combination > of both). > > > > Each of these tables should be modified, so that the CSID column is > replaced by three columns (NEXT-C-SID, REPLACE-C-SID, and > NEXT-AND-REPLACE-C-SID). > > > > If the numbers in these columns are different from one another, this may > inform our discussion about whether NEXT-C-SID, REPLACE-C-SID, and > NEXT-AND-REPLACE-C-SID are different behaviors or different flavors of a > behavior. > > > > > Ron > > > > > > > > Juniper Business Use Only > > *From:* spring *On Behalf Of *Gyan Mishra > *Sent:* Friday, September 24, 2021 9:56 AM > *To:* SPRING WG ; > draft-filsfilscheng-spring-srv6-srh-compression@ietf.org; > spring-chairs@ietf.org > *Subject:* Re: [spring] > draft-filsfilscheng-spring-srv6-srh-compression-02#section-4.1.1 > > > > *[External Email. Be cautious of content]* > > > > Dear Spring Authors > > > > Please respond to this question the WG has related to which of the three > SRv6 forwarding mechanisms called flavors was inclusive of the compressi= on > analysis draft. > > > > The Analysis draft is ambiguous as to which SRv6 forwarding plane flavor > was part of the analysis. > > > > This is a critical question that has come up by the WG and Chairs, and > answering this question will help pave the way to an adoption call for > C-SID. > > > > Kind Regards > > > > Gyan > > > > On Sun, Sep 19, 2021 at 3:33 PM Gyan Mishra wrote= : > > Dear Authors > > > > After having a few discussions on threads related to the SRv6 compression > analysis draft results, as well as WG coming to consensus on a single SRv= 6 > compression solution, a few critical questions have come up related to > C-SID draft that requires clarification by the authors. > > > > The C-SID draft has 3 compression solutions below and is a combination of > the two drafts below which introduces 2 of the 3 compression solutions wi= th > the C-SID draft introduction of yet a 3rd compression solution. > > > > Which of the 3 C-SID draft compression solutions was included as part of > the DT analysis draft results and conclusion? > > > > This is a critical question that needs to be answered for clarification o= n > the C-SID draft solution. > > > > As the WG has consensus on a single solution we need to have clarificatio= n > from the authors which of the 3 compression solutions was included in the > analysis. > > > > The three solutions are very different and all would yield different > analysis results. > > > > I understand the authors have called the each solution a endpoint flavor > which I see from the IANA codepoint allocations, however each flavor is a > different solution. > > > > https://www.iana.org/assignments/segment-routing/segment-routing.xhtml > > > > > So the WG as stated would like a single solution so now we need feedback > from the authors which of the three solutions or endpoint flavors was par= t > of the DT analysis draft that the authors would like to put forward as th= e > single compression solution. > > > > C-SID is a combination of the two drafts below: > > > > Combination of the two drafts below: > > > > G-SID - Generalized SID =E2=80=9CREPLACE-C-SID=E2=80=9D > > > https://datatracker.ietf.org/doc/html/draft-cl-spring-generalized-srv6-fo= r-cmpr-03 > > > > > SRv6 uSID micro-segment =E2=80=9C NEXT-C-SID=E2=80=9D > > > https://datatracker.ietf.org/doc/html/draft-filsfils-spring-net-pgm-exten= sion-srv6-usid-10 > > > > > Kind Regards > > > > > > Gyan > > -- > > > > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com * > > *M 301 502-1347* > > > > -- > > > > > *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 > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --000000000000be043205cd784396 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Darren & Authors=C2=A0

In addition to that editorial fix can we = take below into account and addressed in the draft.
=

The main goal for operators is interoperability.=C2=A0 As in= teroperability is the key reason for a single SRv6 compression solution tha= t we have WG consensus and is highly desired. =C2=A0
Continued details of the interoperabili= ty study =C2=A0should be added to the draft as the study progresses to sect= ion 11. =C2=A0

On= e key detail that is missing is forwarding efficiency and scalability using= NEXT-C-SID and REPLACE-C-SID interoperability using 16 bit SID. =C2=A0

As NEXT-CSID uSID Co= ntainer Micro Segment shift flavor using GIB/LIB for ultra scale =C2=A0SRv6= compression solution is recommended for 16 bit SID and REPLACE-C-SID G-SID= G-SID Container based solution is recommended for 32 bit SID.

Of all the requirements as st= ated, the encapsulation header size is the primary objective for operators = to eliminate MSD issues, keeping in mind maximizing header reduction at opt= imal forwarding at line rate and state efficiencies.=C2=A0

At this time in order for Next an= d Replace solutions to be interoperable keeping in mind requirements for op= timal forwarding and state efficiency 32 bit SID would be the lowest common= denominator between the two solutions which should be stated as the baseli= ne result of the analysis draft and added to interoperability section. =C2= =A0


The draft= should be updated to make more homogeneous between the two solutions. =C2= =A0

As stated the primary goal is optimal header size reduction t= o tackle MSD issues with interoperability taken into account as CSID is a 2= solution -> solution.

Kind Regards=C2=A0

Gya= n

On Mon, Sep 27= , 2021 at 1:23 PM Darren Dukes (ddukes) <ddukes=3D40cisco.com@dmarc.ietf.org>= ; wrote:

Was: Re: [spring] draft-filsfil= scheng-spring-srv6-srh-compression-02#section-4.1.1

=C2=A0

I=E2=80=99m sending this note t= o redirect this question to the srcomp DT for an editorial fix, when the te= am meets next.

=C2=A0

For the DT:

Each proposal, introduced in se= ction 1, discusses how it supports 16-bit and 32-bit SIDs. However, Gyan=E2= =80=99s question indicates this could be more clearly stated in the analysi= s draft to help readers less familiar with a proposal.=C2=A0 As such, section 1 can be improved accordingly.<= /u>

=C2=A0

Darren

=C2=A0

On 2021-09-24, 1:32 PM, &= quot;spring" <spring-bounces@ietf.org> wrote:

=C2=A0

Gyan,

=C2=A0

You raise a very good point. In the analysis document,= Tables 1 through 6 and Tables 12 through 15 each contain only one column f= or the CSID. They do not indicate whether the number in that column were calculated using the NEXT-C-SID, REPLACE-C-= SID, or NEXT-AND-REPLACE-C-SID. (That is, the do not indicate whether they = were calculated using uSID, G-SID, or a combination of both).=

=C2=A0

Each of these tables should be modified, so that the C= SID column is replaced by three columns (NEXT-C-SID, REPLACE-C-SID, and NEX= T-AND-REPLACE-C-SID).

=C2=A0

If the numbers in these columns are different from one= another, this may inform our discussion about whether NEXT-C-SID, REPLACE-= C-SID, and NEXT-AND-REPLACE-C-SID are different behaviors or different flavors of a behavior.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ron

=C2=A0

=C2=A0

<= /u>=C2=A0

Juniper Business U= se Only

F= rom: spring <spring-bounces@ietf.org> On Behalf Of Gyan Mishra
Sent: Friday, September 24, 2021 9:56 AM
To: SPRING WG <spring@ietf.org>; draft-filsfilscheng-spring-s= rv6-srh-compression@ietf.org; spring-chairs@ietf.org
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compressio= n-02#section-4.1.1

<= /u>=C2=A0

[External Email. Be cautious of content]

<= /u>=C2=A0

Dear= Spring Authors=C2=A0

<= /u>=C2=A0

Plea= se respond to this question the WG has related to which of the three SRv6 f= orwarding mechanisms called =C2=A0flavors was inclusive of the compression = analysis draft.

<= /u>=C2=A0

The = Analysis draft is ambiguous as to which SRv6 forwarding plane flavor was pa= rt of the analysis.

<= /u>=C2=A0

This= is a critical question that has come up by the WG and Chairs, and answerin= g this question will help pave the way to an adoption call for C-SID. =C2= =A0

<= /u>=C2=A0

Kind= Regards=C2=A0

<= /u>=C2=A0

Gyan=

<= /u>=C2=A0

On S= un, Sep 19, 2021 at 3:33 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:<= /u>

Dear= Authors

<= /u>=C2=A0

Afte= r having a few discussions on threads related to the SRv6 compression analy= sis draft results, as well as WG coming to consensus on a single SRv6 compr= ession solution, a few critical questions have come up related to C-SID draft that requires clarification by the aut= hors.

<= /u>=C2=A0

The = C-SID draft has 3 compression solutions below and is a combination of the t= wo drafts below which introduces 2 of the 3 compression solutions with the = =C2=A0C-SID draft introduction of yet a 3rd compression solution.

<= /u>=C2=A0

Whic= h of the 3 C-SID draft compression solutions was included as part of the DT= analysis draft results and conclusion?

<= /u>=C2=A0

This= is a critical question that needs to be answered for clarification on the = C-SID draft solution.

<= /u>=C2=A0

As t= he WG has consensus on a single solution we need to have clarification from= the authors which of the 3 compression solutions was included in the analy= sis. =C2=A0

<= /u>=C2=A0

The = three solutions are very different and all would yield different analysis r= esults.

<= /u>=C2=A0

I un= derstand the authors have called the each solution a endpoint flavor which = I see from the IANA codepoint allocations, however each flavor is a differe= nt solution. =C2=A0

<= /u>=C2=A0

<= /u>=C2=A0

So t= he WG as stated would like a single solution so now we need feedback from t= he authors which of the three solutions or endpoint flavors was part of the= DT analysis draft that the authors would like to put forward as the single compression solution.

<= /u>=C2=A0

C-SID is a combinati= on of the two drafts below:<= /u>

=C2=A0

Combination of the t= wo drafts below:

=C2=A0

G-SID - Generalized = SID =E2=80=9CREPLACE-C-SID=E2=80=9D

=C2=A0

SRv6 uSID micro-segm= ent =E2=80=9C=C2=A0NEXT-C-SID=E2=80=9D

=C2=A0

Kind Regards=C2=A0

=C2=A0

<= /u>=C2=A0

Gyan=

-- <= u>

= =

= Gyan Mishra

Net= work Solutions Architect=C2=A0

Email gyan.s.mishra@verizon.com

M 3= 01 502-1347=

<= /u>=C2=A0

-- <= u>

= =

= Gyan Mishra

Net= work Solutions Architect=C2=A0

Email gyan.s.mishra@verizon.com

M 3= 01 502-1347=

<= /u>=C2=A0

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

=

Gyan Mishra

Network Solutions Architect=C2=A0<= /p>

Email gyan.s.mishra@ver= izon.com<= br>

M 301 502-1347


--000000000000be043205cd784396-- From nobody Sun Oct 3 15:31:46 2021 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 7A7EB3A0CD4; Sun, 3 Oct 2021 15:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IN5vn58xUphy; Sun, 3 Oct 2021 15:31:32 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 A6A823A0CD2; Sun, 3 Oct 2021 15:31:32 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id h3so4121972pgb.7; Sun, 03 Oct 2021 15:31: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 :cc; bh=6OKucVdEJ/zn4cx234AtnabwS67DCYzj18JX4/S9Cfo=; b=Z9+WbCf7SDzVAf5fV1CEa7eYRe7AACc+eOZd87I0dahzS79LLyP/F7lnKk7ix+QWLk tQAmBhe/XY20bD4dp6UYzqp1cxz6cawMCKzTTYPzIUw/dFtAMzVZpOm79dkKD5U1kEo2 qtQxoAxQBjHK1toufa6HMozDvdsE8TIKJU9/cPMbnHOafsbR6W0YFtJbcRMVXcTGxJA9 vGCS/yP9/NGOjwKDSJpE2j9rE/RdU+KGCbl7HPwBqcCv7R9c3ur9GoOeQ2fPTK0axMhy iezH74ha5cH+/ojbfgNmEqXct/CXUwi6RoWZtDBbXedl0hApsmydlRpeq8QzkWCuEv45 iTGQ== 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=6OKucVdEJ/zn4cx234AtnabwS67DCYzj18JX4/S9Cfo=; b=FkOUlRM3NGMcpHxf5xe4QJEQL2Ul+FZMffhOl+iNLRETjw0lP6DW+K2XAnuqurRFNb piRoZXQyKmUwzWP4ZpS424ncYVtjR2XkPmY/8zAQcmpZx4tEOVX2/52hSS9wBl+zQ1jZ CkUOM8wwYZ2YBRg+pJ1ygJ/DT5o6N7DXqDti2kTPUybNZ1CjYX4wxd0arnSgm5M9yklY TOzevXLH2rOuXLcVvFIcgWSPpPAxmS10WWvcf3tDx4wTGuvPfRRqCY/bGOyYONjz8mq1 /cNLESl430Xo/N1omrmIV+B/Nm0Xc81eZHkqxYp8iWVxvaMiE+MR4/nlqYk2+1fuyiUK qRPw== X-Gm-Message-State: AOAM530J7XqvY82It2tv4TizfTnDi2Qtf8xRg+SXFu6BgqICpbT+Wn1b TulRpb+uPVW90T7fKozjkz/rEztepbFsVtgcVpA= X-Google-Smtp-Source: ABdhPJyKPy4Vmi14ujOgUDVnvuRzVn4rg8qiX+640YR4mqIbCf5Q7VfTcIVEChVovchbviqvDcyEWbsRHuFfFRtDh4I= X-Received: by 2002:a62:5b45:0:b0:44b:e0f2:4fba with SMTP id p66-20020a625b45000000b0044be0f24fbamr21393734pfb.54.1633300291691; Sun, 03 Oct 2021 15:31:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Sun, 3 Oct 2021 18:31:20 -0400 Message-ID: To: "Darren Dukes (ddukes)" Cc: SPRING WG , "srcomp@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b2aa4d05cd7a5bd9" Archived-At: Subject: Re: [spring] [srcomp] compression analysis draft question on proposals analyzed 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, 03 Oct 2021 22:31:40 -0000 --000000000000b2aa4d05cd7a5bd9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Darren, Chengli & Authors In the update please also state what the advantages and disadvantages compare and contrast of having both solutions together in a single unified solution. What does that offer and bring to the table from a compression standpoint value add that one has over the other. Look at it from the requirements draft POV. Are there some general or corner cases where you would want to deploy replace and not next and vice versa. Given the two solutions why would an operator deploy next and not replace solution and vice versa. Kind Regards Gyan On Sun, Oct 3, 2021 at 4:01 PM Gyan Mishra wrote: > Hi Darren & Authors > > In addition to that editorial fix can we take below into account and > addressed in the draft. > > The main goal for operators is interoperability. As interoperability is > the key reason for a single SRv6 compression solution that we have WG > consensus and is highly desired. > > Continued details of the interoperability study should be added to the > draft as the study progresses to section 11. > > One key detail that is missing is forwarding efficiency and scalability > using NEXT-C-SID and REPLACE-C-SID interoperability using 16 bit SID. > > As NEXT-CSID uSID Container Micro Segment shift flavor using GIB/LIB for > ultra scale SRv6 compression solution is recommended for 16 bit SID and > REPLACE-C-SID G-SID G-SID Container based solution is recommended for 32 > bit SID. > > Of all the requirements as stated, the encapsulation header size is the > primary objective for operators to eliminate MSD issues, keeping in mind > maximizing header reduction at optimal forwarding at line rate and state > efficiencies. > > At this time in order for Next and Replace solutions to be interoperable > keeping in mind requirements for optimal forwarding and state efficiency = 32 > bit SID would be the lowest common denominator between the two solutions > which should be stated as the baseline result of the analysis draft and > added to interoperability section. > > Verbiage should state that with the CSID overall 2 prong next and replac= e > SID solution that in reality the 32 bit SID would be the optimal lowest > common denominator recommended SID length for interoperability. > > The draft should be updated to make more homogeneous between the two > solutions. > > Also if it=E2=80=99s possible that uSID GIB/LIB concept can be applied to= G-SID > solution to optimize the hardware forwarding and start efficiency to make > 16 bit SID viable and recommended G-SID / Replace SID solution. > > As stated the primary goal is optimal header size reduction to tackle MSD > issues with interoperability taken into account as CSID is a 2 solution -= > > solution. > > Kind Regards > > Gyan > > On Mon, Sep 27, 2021 at 1:23 PM Darren Dukes (ddukes) 40cisco.com@dmarc.ietf.org> wrote: > >> Was: Re: [spring] >> draft-filsfilscheng-spring-srv6-srh-compression-02#section-4.1.1 >> >> >> >> I=E2=80=99m sending this note to redirect this question to the srcomp DT= for an >> editorial fix, when the team meets next. >> >> >> >> For the DT: >> >> Each proposal, introduced in section 1, discusses how it supports 16-bit >> and 32-bit SIDs. However, Gyan=E2=80=99s question indicates this could b= e more >> clearly stated in the analysis draft to help readers less familiar with = a >> proposal. As such, section 1 can be improved accordingly. >> >> >> >> Darren >> >> >> >> On 2021-09-24, 1:32 PM, "spring" wrote: >> >> >> >> Gyan, >> >> >> >> You raise a very good point. In the analysis document, Tables 1 through = 6 >> and Tables 12 through 15 each contain only one column for the CSID. They= do >> not indicate whether the number in that column were calculated using the >> NEXT-C-SID, REPLACE-C-SID, or NEXT-AND-REPLACE-C-SID. (That is, the do n= ot >> indicate whether they were calculated using uSID, G-SID, or a combinatio= n >> of both). >> >> >> >> Each of these tables should be modified, so that the CSID column is >> replaced by three columns (NEXT-C-SID, REPLACE-C-SID, and >> NEXT-AND-REPLACE-C-SID). >> >> >> >> If the numbers in these columns are different from one another, this may >> inform our discussion about whether NEXT-C-SID, REPLACE-C-SID, and >> NEXT-AND-REPLACE-C-SID are different behaviors or different flavors of a >> behavior. >> >> >> >> >> Ron >> >> >> >> >> >> >> >> Juniper Business Use Only >> >> *From:* spring *On Behalf Of *Gyan Mishra >> *Sent:* Friday, September 24, 2021 9:56 AM >> *To:* SPRING WG ; >> draft-filsfilscheng-spring-srv6-srh-compression@ietf.org; >> spring-chairs@ietf.org >> *Subject:* Re: [spring] >> draft-filsfilscheng-spring-srv6-srh-compression-02#section-4.1.1 >> >> >> >> *[External Email. Be cautious of content]* >> >> >> >> Dear Spring Authors >> >> >> >> Please respond to this question the WG has related to which of the three >> SRv6 forwarding mechanisms called flavors was inclusive of the compress= ion >> analysis draft. >> >> >> >> The Analysis draft is ambiguous as to which SRv6 forwarding plane flavor >> was part of the analysis. >> >> >> >> This is a critical question that has come up by the WG and Chairs, and >> answering this question will help pave the way to an adoption call for >> C-SID. >> >> >> >> Kind Regards >> >> >> >> Gyan >> >> >> >> On Sun, Sep 19, 2021 at 3:33 PM Gyan Mishra >> wrote: >> >> Dear Authors >> >> >> >> After having a few discussions on threads related to the SRv6 compressio= n >> analysis draft results, as well as WG coming to consensus on a single SR= v6 >> compression solution, a few critical questions have come up related to >> C-SID draft that requires clarification by the authors. >> >> >> >> The C-SID draft has 3 compression solutions below and is a combination o= f >> the two drafts below which introduces 2 of the 3 compression solutions w= ith >> the C-SID draft introduction of yet a 3rd compression solution. >> >> >> >> Which of the 3 C-SID draft compression solutions was included as part of >> the DT analysis draft results and conclusion? >> >> >> >> This is a critical question that needs to be answered for clarification >> on the C-SID draft solution. >> >> >> >> As the WG has consensus on a single solution we need to have >> clarification from the authors which of the 3 compression solutions was >> included in the analysis. >> >> >> >> The three solutions are very different and all would yield different >> analysis results. >> >> >> >> I understand the authors have called the each solution a endpoint flavor >> which I see from the IANA codepoint allocations, however each flavor is = a >> different solution. >> >> >> >> https://www.iana.org/assignments/segment-routing/segment-routing.xhtml >> >> >> >> >> So the WG as stated would like a single solution so now we need feedback >> from the authors which of the three solutions or endpoint flavors was pa= rt >> of the DT analysis draft that the authors would like to put forward as t= he >> single compression solution. >> >> >> >> C-SID is a combination of the two drafts below: >> >> >> >> Combination of the two drafts below: >> >> >> >> G-SID - Generalized SID =E2=80=9CREPLACE-C-SID=E2=80=9D >> >> >> https://datatracker.ietf.org/doc/html/draft-cl-spring-generalized-srv6-f= or-cmpr-03 >> >> >> >> >> SRv6 uSID micro-segment =E2=80=9C NEXT-C-SID=E2=80=9D >> >> >> https://datatracker.ietf.org/doc/html/draft-filsfils-spring-net-pgm-exte= nsion-srv6-usid-10 >> >> >> >> >> Kind Regards >> >> >> >> >> >> Gyan >> >> -- >> >> >> >> >> *Gyan Mishra* >> >> *Network Solutions Architect * >> >> *Email gyan.s.mishra@verizon.com * >> >> *M 301 502-1347* >> >> >> >> -- >> >> >> >> >> *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 >> > -- > > > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mishra@verizon.com * > > > > *M 301 502-1347* > > -- *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --000000000000b2aa4d05cd7a5bd9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Darren, Chengli & Authors=C2=A0

In the update please also s= tate what the advantages and disadvantages compare and contrast of having b= oth solutions together in a single unified solution.

What does that offer and bring to the table fr= om a compression standpoint value add that one has over the other.=C2=A0 Lo= ok at it from the requirements draft POV.

=
Are there some general or corner cases where you would wa= nt to deploy replace and not next and vice versa.
Given the two solutions why would an operator dep= loy next and not replace solution and vice versa.

Kind Regards=C2=A0

Gyan

On Sun, Oct 3, 20= 21 at 4:01 PM Gyan Mishra <haya= busagsm@gmail.com> wrote:
Hi=C2=A0Darren & Authors=C2=A0

=
In addition to that editorial fix can we take below into = account and addressed in the draft.

The main goal for op= erators is interoperability.=C2=A0 As interoperability is the key reason fo= r a single SRv6 compression solution that we have WG consensus and is highl= y desired. =C2=A0

Continued details of the interoperability study =C2=A0should be added to t= he draft as the study progresses to section 11. =C2=A0
<= br>
One key detail that is missing is for= warding efficiency and scalability using NEXT-C-SID and REPLACE-C-SID inter= operability using 16 bit SID. =C2=A0

As NEXT-CSID uSID Container Micro Segment shift flavor= using GIB/LIB for ultra scale =C2=A0SRv6 compression solution is recommend= ed for 16 bit SID and REPLACE-C-SID G-SID G-SID Container based solution is= recommended for 32 bit SID.

Of all the requirements as stated, the encapsulation header siz= e is the primary objective for operators to eliminate MSD issues, keeping i= n mind maximizing header reduction at optimal forwarding at line rate and s= tate efficiencies.=C2=A0

At this time in order for Next and Replace solutions to be interope= rable keeping in mind requirements for optimal forwarding and state efficie= ncy 32 bit SID would be the lowest common denominator between the two solut= ions which should be stated as the baseline result of the analysis draft an= d added to interoperability section. =C2=A0

Verbiage should state that with t= he =C2=A0CSID overall 2 prong next and replace SID solution that in reality= the 32 bit SID would be the optimal lowest common denominator recommended = SID length for interoperability.

The draft should be updated to make more hom= ogeneous between the two solutions. =C2=A0
Also if it=E2=80=99s possible that= uSID GIB/LIB concept can be applied to G-SID solution to optimize the hard= ware forwarding and start efficiency to make 16 bit SID viable and recommen= ded G-SID / Replace SID solution.

As= stated the primary goal is optimal header size reduction to tackle MSD iss= ues with interoperability taken into account as CSID is a 2 solution -> = solution.

Kind Regards= =C2=A0

Gyan

On Mon, Sep 27, 2= 021 at 1:23 PM Darren Dukes (ddukes) <ddukes=3D40cisco.com@dmarc.ietf.org> w= rote:

Was: Re: [spring] draft-filsfil= scheng-spring-srv6-srh-compression-02#section-4.1.1

=C2=A0

I=E2=80=99m sending this note t= o redirect this question to the srcomp DT for an editorial fix, when the te= am meets next.

=C2=A0

For the DT:

Each proposal, introduced in se= ction 1, discusses how it supports 16-bit and 32-bit SIDs. However, Gyan=E2= =80=99s question indicates this could be more clearly stated in the analysi= s draft to help readers less familiar with a proposal.=C2=A0 As such, section 1 can be improved accordingly.<= /u>

=C2=A0

Darren

=C2=A0

On 2021-09-24, 1:32 PM, &= quot;spring" <spring-bounces@ietf.org> wrote:

=C2=A0

Gyan,

=C2=A0

You raise a very good point. In the analysis document,= Tables 1 through 6 and Tables 12 through 15 each contain only one column f= or the CSID. They do not indicate whether the number in that column were calculated using the NEXT-C-SID, REPLACE-C-= SID, or NEXT-AND-REPLACE-C-SID. (That is, the do not indicate whether they = were calculated using uSID, G-SID, or a combination of both).=

=C2=A0

Each of these tables should be modified, so that the C= SID column is replaced by three columns (NEXT-C-SID, REPLACE-C-SID, and NEX= T-AND-REPLACE-C-SID).

=C2=A0

If the numbers in these columns are different from one= another, this may inform our discussion about whether NEXT-C-SID, REPLACE-= C-SID, and NEXT-AND-REPLACE-C-SID are different behaviors or different flavors of a behavior.

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ron

=C2=A0

=C2=A0

<= /u>=C2=A0

Juniper Business U= se Only

F= rom: spring <spring-bounces@ietf.org> On Behalf Of Gyan Mishra
Sent: Friday, September 24, 2021 9:56 AM
To: SPRING WG <spring@ietf.org>; draft-filsfilscheng-spring-s= rv6-srh-compression@ietf.org; spring-chairs@ietf.org
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compressio= n-02#section-4.1.1

<= /u>=C2=A0

[External Email. Be cautious of content]

<= /u>=C2=A0

Dear= Spring Authors=C2=A0

<= /u>=C2=A0

Plea= se respond to this question the WG has related to which of the three SRv6 f= orwarding mechanisms called =C2=A0flavors was inclusive of the compression = analysis draft.

<= /u>=C2=A0

The = Analysis draft is ambiguous as to which SRv6 forwarding plane flavor was pa= rt of the analysis.

<= /u>=C2=A0

This= is a critical question that has come up by the WG and Chairs, and answerin= g this question will help pave the way to an adoption call for C-SID. =C2= =A0

<= /u>=C2=A0

Kind= Regards=C2=A0

<= /u>=C2=A0

Gyan=

<= /u>=C2=A0

On S= un, Sep 19, 2021 at 3:33 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:<= /u>

Dear= Authors

<= /u>=C2=A0

Afte= r having a few discussions on threads related to the SRv6 compression analy= sis draft results, as well as WG coming to consensus on a single SRv6 compr= ession solution, a few critical questions have come up related to C-SID draft that requires clarification by the aut= hors.

<= /u>=C2=A0

The = C-SID draft has 3 compression solutions below and is a combination of the t= wo drafts below which introduces 2 of the 3 compression solutions with the = =C2=A0C-SID draft introduction of yet a 3rd compression solution.

<= /u>=C2=A0

Whic= h of the 3 C-SID draft compression solutions was included as part of the DT= analysis draft results and conclusion?

<= /u>=C2=A0

This= is a critical question that needs to be answered for clarification on the = C-SID draft solution.

<= /u>=C2=A0

As t= he WG has consensus on a single solution we need to have clarification from= the authors which of the 3 compression solutions was included in the analy= sis. =C2=A0

<= /u>=C2=A0

The = three solutions are very different and all would yield different analysis r= esults.

<= /u>=C2=A0

I un= derstand the authors have called the each solution a endpoint flavor which = I see from the IANA codepoint allocations, however each flavor is a differe= nt solution. =C2=A0

<= /u>=C2=A0

<= /u>=C2=A0

So t= he WG as stated would like a single solution so now we need feedback from t= he authors which of the three solutions or endpoint flavors was part of the= DT analysis draft that the authors would like to put forward as the single compression solution.

<= /u>=C2=A0

C-SID is a combinati= on of the two drafts below:<= /u>

=C2=A0

Combination of the t= wo drafts below:

=C2=A0

G-SID - Generalized = SID =E2=80=9CREPLACE-C-SID=E2=80=9D

=C2=A0

SRv6 uSID micro-segm= ent =E2=80=9C=C2=A0NEXT-C-SID=E2=80=9D

=C2=A0

Kind Regards=C2=A0

=C2=A0

<= /u>=C2=A0

Gyan=

-- <= u>

=

= Gyan Mishra

Net= work Solutions Architect=C2=A0

Email gyan.s.mishra@verizon.com

M 3= 01 502-1347=

<= /u>=C2=A0

-- <= u>

=

= Gyan Mishra

Net= work Solutions Architect=C2=A0

Email gyan.s.mishra@verizon.com

M 3= 01 502-1347=

<= /u>=C2=A0

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

<= a href=3D"http://www.verizon.com/" style=3D"padding-bottom:1em;display:inli= ne-block;color:rgb(17,85,204)" target=3D"_blank">

Gyan Mishra

N= etwork Solutions Architect=C2=A0

Email = gyan.s.mishra@verizon.com

M 301 502-1347


--
--000000000000b2aa4d05cd7a5bd9-- From nobody Mon Oct 4 06:33:13 2021 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 D16403A05A4; Mon, 4 Oct 2021 06:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7Oqxn6NtGGm; Mon, 4 Oct 2021 06:32:56 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 406AC3A03F8; Mon, 4 Oct 2021 06:32:56 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id q205so20229261iod.8; Mon, 04 Oct 2021 06:32: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=9EWMmaLjUl7tcYNdtdoweb8BMT9MlKPpHygkfMHRklI=; b=areIfVMWaDv6QyZvb+SLiTqVTtNjRLhI6udRCA7F/X9FPNNo93T2MLzM7kk7M5Dk2/ qMifResViYlucse7qBxkE1VuIhQfiTGNudUwbi/AL5bnqx/Tphv6GTA//ycQwoABz+V1 RIx3gCqKvr059HVu/+iOBM8gKnqcoHpWKjh7fGoIJZpTd98sjINoNZWAGszwJHPfvpwc wO+VB5C6sX9vWbbSLwahsv1Det45lQeq3l1+75xa8yOzVtQg8ZjqcaCerTbto3UOzvTf 0ILZyEe1knRs83NwTJI7gfCRcpd4jIp6XVDJrgNK7w7SHHIImpEkF0YqQlKf0hdoUrNh 7beQ== 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=9EWMmaLjUl7tcYNdtdoweb8BMT9MlKPpHygkfMHRklI=; b=BPJMRhY4dkLETJuDzxh3DNeIExk9veUddfRPBAdK8l5nQnaqUnG5BGdl4Oq1rF4ylg kZwAQYg3eyajJE9ZlBJH+cgh5ExzKxt4Idrn9ffoOKLV8FFfo9QkvthR0S/0aWs2SbxL RTLn8p4UFClg7ymJtEG57ExsBt/lyxdQUtCpCwiQLfeI4pNl6972/a6PTURrfbf4hnVy 6qBn4081gGJq1eyj97p4vi/SF+UMYKYybCmQex286OQGFbDhVtU+K9XgspqdkriNUuX2 0PIVe5sx0cYZO7m5//7zszpDroU+SXvd4ddKcmdPicc1/HJ2tEM49EPx9UW1r7Mv1+CJ /eOA== X-Gm-Message-State: AOAM531oFpuUYUCcrSY02HpE3++BKOMgslKZAdsJ00TbPI+WljIp8Ixy adIp09qwFWtF0gVE75A6aJtH+FGb/X1q8yfwlYjFz3QATo0W/w== X-Google-Smtp-Source: ABdhPJxS9lweu5KYNgS++rlCGpc0t2kJpdzemm1qidl4HxFtD5k+8+ND8jeDn5s2SjA9sVv4GKD9L+zdCgJhRuEw4f0= X-Received: by 2002:a6b:7a0a:: with SMTP id h10mr9488017iom.20.1633354375322; Mon, 04 Oct 2021 06:32:55 -0700 (PDT) MIME-Version: 1.0 References: <6d4eff6d-6fdc-992e-3a01-13bce8b05cd0@gmail.com> In-Reply-To: <6d4eff6d-6fdc-992e-3a01-13bce8b05cd0@gmail.com> From: Tony Przygienda Date: Mon, 4 Oct 2021 15:32:19 +0200 Message-ID: To: Brian E Carpenter Cc: Ron Bonica , "6man@ietf.org" <6man@ietf.org>, SPRING WG Content-Type: multipart/alternative; boundary="00000000000055639005cd86f315" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 04 Oct 2021 13:33:01 -0000 --00000000000055639005cd86f315 Content-Type: text/plain; charset="UTF-8" Taking this new "philosophy of limited domain" to its bitter conclusion A is Internet Standard B is also Internet Standard for "Limited Domain" that violates A C is also Internet Standard for "Limited Domain" that violates A D is also Internet Standard for "Limited Domain" that violetes C so by transitive chain D violates C and hence A but not B. Hence D and B can be deployed together (maybe) but not any other combination. So what purposes will IETF serve. To define 4 different "standards" that have "limited domain violation dependencies" amongst each other but based on algebra closure can sometimes be deployed together. And we will track this and call that "standards" ? Really ? --- tony On Sun, Oct 3, 2021 at 6:13 AM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Ron, > > The first sentence cites RFC8402 which unambiguously describes SR as a > limited domain protcol (limited to an "SR domain", that is.) > > So within such a domain, this describes using 128 bit quantities called > Segment Identifiers that in some cases, but apparently not in the formats > defined here, has the same structure as an IP address. > > Does that harm the Internet, even if it leaks? It might disappoint the > sender, as any sender of a bogus packet is disappointed, but apart from > that, > who is damaged? > > Regards > Brian Carpenter > > On 02-Oct-21 09:34, Ron Bonica wrote: > > Folks, > > > > > > > > Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new > SID types that can occupy the Destination Address field of an IPv6 header. > See Sections 4.1, 4.2, and 4.3 of the draft for details. > > > > > > > > The SPRING WG has issued a call for adoption for this draft. > > > > > > > > It is not clear that these SID types can be harmonized with the IPv6 > addressing architecture. > > > > > > > > Does anyone have an opinion? > > > > > > > > > Ron > > > > > > > > > > Juniper Business Use Only > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --00000000000055639005cd86f315 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Taking this new "philosophy of limited domain&qu= ot; to its bitter conclusion

A is Internet Standar= d
B is also Internet Standard for "Limited Domain"= that violates A
C is also Internet Standard for "Limit= ed Domain" that violates A
D is also Internet Standard f= or "Limited Domain" that violetes C

= so by transitive chain D violates C and hence A but not B. Hence D and B ca= n be deployed together (maybe) but not any other combination.

So what purposes will IETF serve. To define 4 different &q= uot;standards" that have "limited domain violation dependencies&q= uot; amongst each other but based on algebra closure can sometimes be deplo= yed together. And we will track this and call that "standards" ? = Really ?

--- tony





On Sun, Oct 3, 2021 at 6:13 AM = Brian E Carpenter <brian.= e.carpenter@gmail.com> wrote:
Ron,

The first sentence cites RFC8402 which unambiguously describes SR as a
limited domain protcol (limited to an "SR domain", that is.)

So within such a domain, this describes using 128 bit quantities called
Segment Identifiers that in some cases, but apparently not in the formats defined here, has the same structure as an IP address.

Does that harm the Internet, even if it leaks? It might disappoint the
sender, as any sender of a bogus packet is disappointed, but apart from tha= t,
who is damaged?

Regards
=C2=A0 =C2=A0Brian Carpenter

On 02-Oct-21 09:34, Ron Bonica wrote:
> Folks,
>
> =C2=A0
>
> Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three ne= w
SID types that can occupy the Destination Address field of an IPv6 header. = See Sections 4.1, 4.2, and 4.3 of the draft for details.
>
> =C2=A0
>
> The SPRING WG has issued a call for adoption for this draft.
>
> =C2=A0
>
> It is not clear that these SID types can be harmonized with the IPv6 a= ddressing architecture.
>
> =C2=A0
>
> Does anyone have an opinion?
>
> =C2=A0
>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Ron
>
> =C2=A0
>
>
> Juniper Business Use Only
>
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
> -------------------------------------------------------------------- >

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--00000000000055639005cd86f315-- From nobody Mon Oct 4 08:09:57 2021 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 C25653A08AF; Mon, 4 Oct 2021 08:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u6UIsSXmhl9L; Mon, 4 Oct 2021 08:09:48 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2099.outbound.protection.outlook.com [40.107.223.99]) (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 191813A08B9; Mon, 4 Oct 2021 08:09:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bNti8mXI9tbUjAOtMzp9S/sTSSHC88OevRJMo5iBR7l46E3+QY+Lyyiq9P6gdfjyIzXTd+KcWXED/hAbfGDeVBPPPvBD/SceNxXG9j6jf/71lxEJTiUq3k3Xc9Pmm4Y4lZfEdUNnQihCEUF+QGlJz5v1OHzhMiKQ+0G5Z5oEoZTvsTiA9rhYygwVpk/5lOspsMlbaPQAKYMm2ZFERhuEMzgwdFx+yV2/+CxSHLfZidOnxJ8rL9iqs/LVZ39Uivdg/xELb4Kf5FyKNv/nTe5cPeA+zu/iW8ApeW5WuFw+wQPXUsinvWrAe8Oz2yziDX4gy4L4JmuJ9tUeqP4hN+1ukA== 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=+UrcNUPxEYrAGE8H9zYep+jI0CwvGkiIfPxPTjv9SBQ=; b=A43RTUgMnYqcDXbk9dl0qXj/qvbfBiiuJ6mmq6NSfCw1uIZU91D/NVFQdrAyitXz1TgLfl0lur62XoDosh6MaFsBW+I36BOhR+R0FgzdI95xEZeg7DeXdKe11B57wXCFpAW3W0oaarZfoVK7Qx2uGlGfe5VuPHzkKpmkYDCfgTWUNVhY5BhOfQcTzUnfYVBarUdl1+ssShCURYMoQScea/yzwA0rwYPR8XivJqCxGPeHMeQEqNHIse/uplR6n6N5UM86/Yof57Dc5j+OGJygjvOJEj1ZpAkhhFkPtsVmOao8Aj5VP2mKqlIVFpdNFZVPyixsDehw7EmQViuUGtCZuA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+UrcNUPxEYrAGE8H9zYep+jI0CwvGkiIfPxPTjv9SBQ=; b=TT0rjgEY95lt2CwiIWuzJikeEiw8fUsM2ZJTMA11x60irlqVFTbxOhNKummP4OnqRYsp6DwGo0rXlBtsdIPXcJniKoPET8Aiu2ZqGCGVYUeGlCHf+CM6swCi5HIX1NfgEMZOlzOfV1zszucDcOxED6MmyOw9iatK/1JSUPJZOz4= Received: from MN2PR13MB4206.namprd13.prod.outlook.com (2603:10b6:208:a0::26) by MN2PR13MB2735.namprd13.prod.outlook.com (2603:10b6:208:f2::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.7; Mon, 4 Oct 2021 15:09:37 +0000 Received: from MN2PR13MB4206.namprd13.prod.outlook.com ([fe80::35dd:899b:b1e8:bbdd]) by MN2PR13MB4206.namprd13.prod.outlook.com ([fe80::35dd:899b:b1e8:bbdd%7]) with mapi id 15.20.4587.017; Mon, 4 Oct 2021 15:09:37 +0000 From: James Guichard To: Andrew Alston , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQANZx9MAIq9EbA= Date: Mon, 4 Oct 2021 15:09:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: liquidtelecom.com; dkim=none (message not signed) header.d=none;liquidtelecom.com; dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 10681fd1-78db-43a4-757c-08d98748fb9e x-ms-traffictypediagnostic: MN2PR13MB2735: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RHMBh8LuIUQimJqRHidGE0gInPDQrMckXYKDvOjE3K5o7itcANdpQmdSEx07nYNbTpnHsHXhAOuMSbVgBMMc7Ucj7fI2nKQy/bo8Bu4VSGef4ZRZyxKmFhiHZ5DUr/mNVx+7ktV2Zi0Km3sq/A2sa1GGnpJJlj/vbkXrmsNYg3AJIJP1A3LJStvIxo34+zzF39GvSk4dCZlXqDOtZUwEKi83n+QEbpN1SY+GC4CppH5iO2RWyshAi4Pd2qrwfOp1QtoYu1vEBWYD9Inwb8KsnuvaLlzNeSDhaZd1eG3a1Z5GpZ8f5qtJq5I4HlndLxjg4lLl8/nbLNtNC3w9z1rt2phMV/dEKCBRiwMw2h+Ma3mrSUTIouRokYZtFoY4C+Qa46g129AWfrMy/KYdy03dOSsCbW+MvsC5Pz7Cu8OHADWdQvM2/eaKMbwvehKhequnk3TEE9ImreRxWq46LJcXEkd7mogIFT5ILpo4fSEXCBsVrNZ7PcaSHYlIzd2sGoZwF0fw86FqW4R+3AGWa2jv4NVMHKCG/+I2Jqbqx4d+iyobGQxmCany2MmqeDwClWKQsA4NLLNPTC12IRwY6/xKWS+SFhKdl6UmUmf5gPG0FCpt8Gk9gYGkAm1gyuoKqYwxQPPc8U5KCrLM35irEiCIFEHBuCQ6xNAEth4dk1K7KXHTvyUw07xR+gdJjQLv87nP2Wz6UTOJqHgwcMCBh+RUx12G81UdXKhi6unJAsdRct3bWlmbDkxMbujfCFBZNG8UAIQZItfS9968v1nJPrRLt7jcIbn77YMH3EQkK2gGfuA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB4206.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(76116006)(966005)(55016002)(6506007)(4326008)(166002)(38070700005)(2906002)(9686003)(508600001)(110136005)(316002)(66946007)(66556008)(66476007)(38100700002)(53546011)(86362001)(186003)(5660300002)(8676002)(71200400001)(66446008)(33656002)(83380400001)(8936002)(7696005)(64756008)(122000001)(52536014); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?5US0xPu2VmgzZnaijfrwTFo492na58xMhF3jVt1TpCZjncN2dzDGFrQ83oLZ?= =?us-ascii?Q?4LrJ5YsamMZlG16TW5l9m4H6UdsLyT9aBzr5lNtpc92wdEXIzV6k2cZCe3jQ?= =?us-ascii?Q?LAr1bulM+3P6wL8jfhrqdk8IYS3iF8wzSqtwyWicGpCbej56gkPhAuhs2jzm?= =?us-ascii?Q?H7sWizg/DwbzYZkYrdgrOdw0dBXAxrBUf49GGezeogBDWNYLCyDiw8E476Ba?= =?us-ascii?Q?8LPlQUNR2xsAw9eZEjdfli8Q9gnzRtuEMDdddFYorAn+x+Pg6/8MoadyyVn5?= =?us-ascii?Q?ZxebGCi7TxnqLoeEaIK6f5w5otscCxw6duZlkdmZpleu8M7HV4cuwvDOUzlD?= =?us-ascii?Q?pTXenCc5buiIUO8c/jwIupdqkqILSTdBdgAYTvMnnmnHbKgXMN8x+iATE5lE?= =?us-ascii?Q?LP0r9TqsBooV2o5LJnXPF0BnQWwuj82XcToNzjfpkGUVr0oRuGZAII1yCZy4?= =?us-ascii?Q?pw64KUfBttbWTbaZmEt9UkISGMD+Gut3HIko5K4QWvzFM340ry1V/ZGKyd6v?= =?us-ascii?Q?ZCk0ABWJxgbEqYJkeMO3t0d/cxotfUPQykRlS0+hNcuYrCr8e4XUWc8b8EkB?= =?us-ascii?Q?j41m4EWLUfj4Un6hYJaN0vCTt2qLGeUiMZE40N4lhqVHL/iwt8rZrolFtsw/?= =?us-ascii?Q?xSJXxOg/KMc8+6kfkKVfjgE6WW2zzA8+ys0xejoc9j8c8nKdl5aAm475Yk0D?= =?us-ascii?Q?ble2oC39Tvs0V0CXW2H4uL64fJ4xqJ8zhtZ41jBmqemRKjaGcLWNrjf9OaKS?= =?us-ascii?Q?7EOoeoNnlqlQa4taY1f+z4ueyypSghfyBPGkDqpS9J0al28SwjUVNwcY1bZG?= =?us-ascii?Q?ao5/vx09uco5sddYLRzBCHi6DpSoqsRIHE3Y+Y8v8Oc9NOs09QpBImBne8Rj?= =?us-ascii?Q?wwbgxLwJbDETwfenTm1PURTmNrBTjlwiXthB5vHPZoiMhYOIJq4iY9EhyWae?= =?us-ascii?Q?vDMb39ZNh+pAHa8BNcTqah3alAanKm25q8+/GVcCDBcXltqCU5dZmlW3Y26E?= =?us-ascii?Q?rA2yXKgNkCjbAR8faPnbsik4/IX+CbmaiYTGd10cXZg/7gKcSIIgZjnp+pLX?= =?us-ascii?Q?hdiGMeX7NnYU91pVfZXUx7gQZaTlMMJONoEnR0e2enWMBLpNvMIf7CdtSlcM?= =?us-ascii?Q?SffySt3w17PZFdBUgqdqOcmssEQf/COf7UaHUnP6QovCLGvTvrELCPJN+C5Y?= =?us-ascii?Q?HJy5JnbYpBHpceFLzkHM0ervf6hbfQbflqdJJiXxPiRMaH6T8bmOjzkCLvco?= =?us-ascii?Q?tJktHYGi3cgFm99lAp1o7J13LPBT+BweywWxDFA82FAcxojFw9fNx76TlvvY?= =?us-ascii?Q?FcVwfttb8lyOT0DJMl9nTdIu+EgP9vd622vR0Qwf3Yq+sgqeyM0ZnUGkzVGS?= =?us-ascii?Q?ccdYwKkZS+pkJqB+slmqsmwhidZQ?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR13MB42061CF898FF40E416DF5688D2AE9MN2PR13MB4206namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB4206.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 10681fd1-78db-43a4-757c-08d98748fb9e X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2021 15:09:37.7117 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: PHp8kA1653Zl9gC9B/NztTBTmN86BgcxD5wJdhTZQK5PtJhP+NGoIlGnXKtEKO93YbAJ1jsq1KEfHup5GiW8yA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB2735 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 04 Oct 2021 15:09:54 -0000 --_000_MN2PR13MB42061CF898FF40E416DF5688D2AE9MN2PR13MB4206namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andrew, As stated in our email of September 9th, the chairs communicated that the w= orking group reached rough (quite clear) consensus for standardizing one da= ta plane solution to compress segment routing over IPv6. In addition to thi= s there was an inclination toward using the CSID document as the basis for = our work in this area. The chairs recognized that there was however disagre= ement as to whether this document, having multiple SRv6 EndPoint behaviors,= could be considered consistent with the working group consensus for a sing= le data plane solution. This issue quite clearly needed to be addressed, an= d the chairs, recognizing that the working group is keen to make progress i= n this area, had the option of trying to resolve the issue prior to issuing= an adoption call, or give the working group the opportunity to express the= ir opinions as part of a call for adoption. Those who feel that we need to resolve the consistency issue before adoptio= n, as with those who think this is not a good basis for the WG work, are fr= ee and expected to object to the WG adopting the document. That is distinct= from objecting to the chairs issuing the adoption call. In essence, the chairs have combined the question of when to resolve consis= tency and the question of whether this document is a good basis for the WG = into one call. Yours, Jim, Bruno & Joel From: Andrew Alston Sent: Friday, October 1, 2021 4:21 PM To: James Guichard ; SPRING WG Cc: spring-chairs@ietf.org Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/draft-fi= lsfilscheng-spring-srv6-srh-compression/ Sorry - but - I'm a little confused here. Because the way I look at this - the working group clearly stated that they= wished for a single behavior - and this - does not deliver that - it is tw= o separate behaviors. As such - I see this call for adoption - irrespectiv= e of the merits or lack thereof of the draft, as a clear defiance of the st= ated will of the working group. This is simply does not fit into the definition of bottom up approach in my= opinion - and if this is the way that the chairs wish to proceed - then th= e only way to do that and still fit within the bottom up approach is to fir= st ask this working group for its consensus to deviate from the single beha= cvior approach that the working group agreed to. As such - I must strongly and unequivocally object to this call for adopti= on Andrew From: spring > on b= ehalf of James Guichard > Date: Friday, 1 October 2021 at 17:05 To: SPRING WG > Cc: spring-chairs@ietf.org > Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardization work. That is part= of what this email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear g= uidelines as follows. By expressing support for adoption of this document y= ou are fully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_MN2PR13MB42061CF898FF40E416DF5688D2AE9MN2PR13MB4206namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andrew,

 

As stated in our email of September 9th, the chairs = communicated that the working group reached rough (quite clear) consensus f= or standardizing one data plane solution to compress segment routing over I= Pv6. In addition to this there was an inclination toward using the CSID document as the basis for our work in= this area. The chairs recognized that there was however disagreement as to= whether this document, having multiple SRv6 EndPoint behaviors, could be c= onsidered consistent with the working group consensus for a single data plane solution. This issue quite clearly= needed to be addressed, and the chairs, recognizing that the working group= is keen to make progress in this area, had the option of trying to resolve= the issue prior to issuing an adoption call, or give the working group the opportunity to express their opinions = as part of a call for adoption.

 

Those who feel that we need to resolve the consisten= cy issue before adoption, as with those who think this is not a good basis = for the WG work, are free and expected to object to the WG adopting the doc= ument. That is distinct from objecting to the chairs issuing the adoption call.

 

In essence, the chairs have combined the question of= when to resolve consistency and the question of whether this document is a= good basis for the WG into one call.

 

Yours,

 

Jim, Bruno & Joel

 

 

From: Andrew Alston <Andrew.Alston@liquidt= elecom.com>
Sent: Friday, October 1, 2021 4:21 PM
To: James Guichard <james.n.guichard@futurewei.com>; SPRING WG= <spring@ietf.org>
Cc: spring-chairs@ietf.org
Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/d= raft-filsfilscheng-spring-srv6-srh-compression/

 

Sorry – but – I’m a little confuse= d here.

 

Because the way I look at this – the working g= roup clearly stated that they wished for a single behavior – and this= – does not deliver that – it is two separate behaviors.  = As such – I see this call for adoption – irrespective of the me= rits or lack thereof of the draft, as a clear defiance of the stated will of th= e working group.

 

This is simply does not fit into the definition of b= ottom up approach in my opinion – and if this is the way that the cha= irs wish to proceed – then the only way to do that and still fit with= in the bottom up approach is to first ask this working group for its consensus to deviate from the single behacvior appro= ach that the working group agreed to.

 

As such – I must  strongly and unequivoca= lly object to this call for adoption

 

Andrew

 

From: spring <<= a href=3D"mailto:spring-bounces@ietf.org">= spring-bounces@ietf.org> on behalf of James Guichard <james.n.guichard@fu= turewei.com>
Date: Friday, 1 October 2021 at 17:05
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org <= spring-chairs@ietf.org>
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfi= lscheng-spring-srv6-srh-compression/

Dear WG:

 

The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

 

The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors.
  2. The document is a “living” document; it m= ay change as it goes through review and analysis by the SPRING working grou= p.
  3. All open discussion points raised on our mailing list= MUST be addressed BEFORE said document is allowed to progress from the wor= king group to publication. A list of these discussion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
  4. If this document is adopted by the working group, the= chairs specify as part of the adoption call that the following text descri= bing an open issue be added to the document in the above-described open issues section:
    • "Given th= at the working group has said that it wants to standardize one data plane s= olution, and given that the document contains multiple SRv6 EndPoint behavi= ors that some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

 

Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

--_000_MN2PR13MB42061CF898FF40E416DF5688D2AE9MN2PR13MB4206namp_-- From nobody Mon Oct 4 08:13:53 2021 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 520ED3A08C5; Mon, 4 Oct 2021 08:13:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_REMOTE_IMAGE=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZldIbz30xTLy; Mon, 4 Oct 2021 08:13:45 -0700 (PDT) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2135.outbound.protection.outlook.com [40.107.243.135]) (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 305E33A08BE; Mon, 4 Oct 2021 08:13:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hbON1eve5XUyR2ny88hyW8bs54w20M7ZFH4uC/nBDXCvl1iQVi1lCLaDl/86x4LqkeZBruC3AVR03mX4bw7PyWQW7Y5v2hXVDcX2rc6xDpvWgK4J86k/EsZAC2jyW4W0bzaihsSWK8QjEW9vEjf5hNVpqEBrhHVbLvg4ivckMjRImS01BhpTl7yH6lpYoIIDkJ20QdSnKQm876oD2aYYq9qLRcNNp8Bb4juTYS2AiJUEg9c8IjDNc3z4PAd3hyvJVmnmqHTpCp36bZwH1TKVvNIjrpVg2uJZ4acs/2R8Uiz27gNLsiReJdWSwCiZixaMbfE+k0rtJh8ID/prSauopw== 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=dkRbBoiwuSSwyLucvdQ4yEC+fVmj4BLyIUbvjdwLuAI=; b=MFjd4aknf+a0bVrK5WDoEly47MxxWg0XFd/oaYDI1gYDwQZHrsklg3TZca7qr7Ei8r+1YGZACEzmRY5q+xEtd9ujF06zZJ1MPxVQo6rnYIBQ6mTbGXfs2nAzBAFbJqcTBdaWtByDo0b/ofM4y74f2lyjpkKO+oZwrpMPkf4tESASgtAusFXK7IS/D2HnexPcX/AuP3C72Z4xTS9B/J/VZDAXATkoWmu/8/xGNH/HjBapCXlflxOsAZaiBF7iBi1inZ71M4oDuJoiMO+Z4R9ji5d3qVyx3mBHVeWtifg9QlcQhy203+sy2rVdughvFj0u2NRySuvmyLgAwAZEgcPlfA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dkRbBoiwuSSwyLucvdQ4yEC+fVmj4BLyIUbvjdwLuAI=; b=EdNGhdhbwKRogZdatjHk9DcVQjgIbvfWmG4xPhvLzQl5KinDIq6IDZTyK643RsCNQ8XZjoFtrXRZ4jqfro77xi/gFbNpTinQSnygdn6sn71u0CK0qVgtp9y0szeM0xSLGnOxDB7XdpsTCSPVLJLm3FeelH695Ne4i/8QLEnNhzA= Received: from MN2PR13MB4206.namprd13.prod.outlook.com (2603:10b6:208:a0::26) by BLAPR13MB4658.namprd13.prod.outlook.com (2603:10b6:208:323::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.7; Mon, 4 Oct 2021 15:13:41 +0000 Received: from MN2PR13MB4206.namprd13.prod.outlook.com ([fe80::35dd:899b:b1e8:bbdd]) by MN2PR13MB4206.namprd13.prod.outlook.com ([fe80::35dd:899b:b1e8:bbdd%7]) with mapi id 15.20.4587.017; Mon, 4 Oct 2021 15:13:41 +0000 From: James Guichard To: Gyan Mishra , Tony Li CC: Andrew Alston , SPRING WG , "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQANZx9MAADOxzsAAHjagAAFRqSAAIV5d/A= Date: Mon, 4 Oct 2021 15:13:41 +0000 Message-ID: References: <03B8E50C-B8FA-4DCB-A4E4-91C33590E57C@tony.li> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 362ecc9f-4d1c-4f20-344e-08d987498cfe x-ms-traffictypediagnostic: BLAPR13MB4658: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XpTe60UMTbcI+oGz07Ij4/vKJG4L8mzzntjpXGnzwCwqmzzJx7d0f/04G7zwdr+dCD+XK48XsghavVutxIAxtPQs2FW9VTVE+fPSBpLnXJPGipsXT8YBk2Oj6T/RJR0DQeopP+rnQgrjICBXeoefmAGJhpaQPgBTyCBFTH1uuEDMgOGgUofqLhBzyG10QO6oovi0+csat+A1vf7wPhB8V9YwqwUQ6p5tvQpJPlbfX+W8dD/6NfLFsn975koBauz9HHeYpLlOEE6IbS9nLaHwzePTNposeAMeGYeVYjE/YpBZHsd3thBfl3/gee6fUjEvWjDshnnE36cBSd2L0MstLT0tUHJhO+d12UTVB37gpYvxCdPEKS0S5doFCo1X7SxNTc/Zf4cWWBnJGhLOh/h57eGxTMBK4pu8S8ndckt00UcDpp5kDZ5EpaEIZuZmKthf+0fRdVA8gLbQhb7fyvlFqlInAxo/tgBgrByNXAy20LZSki5ENh9PDJzphDiETH+Qw0WI9DYHtFp5riKJSmUoJqu8vC+0EnLbB5WP4kUSCzIpqNLGSO6jjKJ0jCg2SGnHSE5/u980ncIjxUlodbhcOa7hlkDxX+z2zJ/HmK4Kl294Ag/CU+wuhoUmSGiANIRF6qPNee0T4AdVvuDUjpTXtbviebxPj7dBsj7SiGxOFAauDunP33t/+iJFYZ5zBtgte8LO16+HuXrMLqP+sWmy6XSKpDDcRB/nCGIwiRu6/aQ5NW88BTrZRL2CMBcrg7gTqP0eRBb+PS9KdAnbKlkgf+RIivpUNfzxy4em9QFpYrnTZTD008DLUtMZ5WjnCj4zT4Z5GUWshHjtatVIRKVQ5Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR13MB4206.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(40140700001)(5660300002)(66946007)(66556008)(38100700002)(316002)(186003)(86362001)(53546011)(122000001)(52536014)(9326002)(66446008)(33656002)(8676002)(71200400001)(83380400001)(7696005)(64756008)(8936002)(66476007)(55016002)(966005)(76116006)(9686003)(508600001)(54906003)(110136005)(38070700005)(166002)(6506007)(4326008)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?t/vWrGKbQJC6CCKjIkSwGG2DchFnxkBjXyEambvFXyM3S3/G7IFAX9Cu/PpD?= =?us-ascii?Q?q7sY7QPgJBtcOp78yNd+6l2/byFvDfm54QclgZa4KFeJAjkY5h31IXyJGAEH?= =?us-ascii?Q?4ABLOuttCFN62b417akFW5+2QYHFnhd6IVkY11/jZOLNv9klNljWJncNDyuk?= =?us-ascii?Q?1EDC6vA3/UUeDC8BWOmTk0jcj469Zy69rYWofhATUiArbBCTq1LOMZSs/j3g?= =?us-ascii?Q?VfKTcR5gUHQpAFk+WT53LwiKdvfKxYg2B8i8fHkr4aCovzmQyw+FDosxuLrk?= =?us-ascii?Q?OpQ3I6F0AkR/EfJbpZZwrbsfNOrdzcUmFzXJ4+LJ8CjRksA3hyiOfnk2TzRX?= =?us-ascii?Q?IdvKW9mpDR0uAmuRvAKm9tzVJ/NDKgBAKqjGP8rCROsRQeOCAej/cGl4Sz4n?= =?us-ascii?Q?3dSA+N+m+pnNzG2M9+2GT1X7bMFmZmGLRIXWtsb49s0BuS+2iL1VsqhuDJiR?= =?us-ascii?Q?8W2WFj1u5t3TrJcvSHv6sLkJu2g+jIda2fyNrLK8W+NEJiWN4VAVJS58Ns6l?= =?us-ascii?Q?3uzD0CiZWvriNWynafzaNP9IfyLXwuRcwzBuYGtUcVZNZXy3fe8XzFG4184X?= =?us-ascii?Q?2n+Zcz/Raw2mq3KFzSynOXTSHCjGCdIJLbciT4UqfcZ10fe9yrgcgWiQ/ENq?= =?us-ascii?Q?ok3m05VPsWv7IVhZfMmZqZPPddMiJiEaddnyHbu6xx9tbxKtGo91hN16Lf6u?= =?us-ascii?Q?mPoH0B97OQbJCOoaY9mreVW041XcZyRqNYtT0zbAgMkZUe2GgFlw0Ys0o4LD?= =?us-ascii?Q?M9xNy2MDVQp5X4MPjQWf8xO/+fbIYOtOz789Hrau7M05hRvJA/qc+YUuHzpS?= =?us-ascii?Q?nwdvAwfrzpiFm7SjBrx5PkFuAUkrXliEL4PquAUYRkCmYGd962AJldU51pdG?= =?us-ascii?Q?ndmpDLB/Tmb3cHyklW8bP1z7oFIaDtaat9QDKHhOFC59n5kOU73Q0Ci2T4lS?= =?us-ascii?Q?9faW73o8l0gh7KtX6nxism1TB8cQIPEi+Uu1EL4zs48pc3+Nh9C1quh3ZPQg?= =?us-ascii?Q?0BlsZENzAIDebBSIRcIvdNgM/tQYpJZOjcK/g0xHwmGiSydFAfoJAUo8HQCn?= =?us-ascii?Q?rGXibXFvQD9Q7FkEEGtBc7c3Af6VwtYX71e2PYjYIsH6gecSauWTz7Ip1XAW?= =?us-ascii?Q?hEE3PZuTHOzb8fvapaPm6hDbkgrbtMDeUDAQ6Z6HFYKwd+3aV3td5J4ix3Gi?= =?us-ascii?Q?41XJ/Kv8QHhy9C8bAE0IGAnGIZPTHe5cDg6VKnI5R125/wWAfqO61R8NKPUY?= =?us-ascii?Q?yWEZT+vdx1a1WJDR3j7zm/D9byMsuAPEb1UciGBGTpFM0NseyYhfmUE5UR5d?= =?us-ascii?Q?zIUtQfLVZXfWzURvd3arLlv3PB+PnvifYYtZLmi4iyZP2WjQ56MciXJc2j9K?= =?us-ascii?Q?sra19Yi+Y/6IzeP9i735MlMD4C+1?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR13MB420666FE6C32E75472999B44D2AE9MN2PR13MB4206namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MN2PR13MB4206.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 362ecc9f-4d1c-4f20-344e-08d987498cfe X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2021 15:13:41.7108 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yB6SxfnNFdsbdx7kMT+5L5/KLcVxfNCQNxuhLXutPtj0yQgcs4J70SDhHhv8doQ0W7Sb16xGkUfClBnXFDeoUA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR13MB4658 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 04 Oct 2021 15:13:51 -0000 --_000_MN2PR13MB420666FE6C32E75472999B44D2AE9MN2PR13MB4206namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Gyan, Please see the chairs response to the email from Andrew Alston. Yours, Jim, Bruno & Joel. From: Gyan Mishra Sent: Friday, October 1, 2021 7:26 PM To: Tony Li Cc: Andrew Alston ; Jam= es Guichard ; SPRING WG ; = spring-chairs@ietf.org Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ Dear WG chairs, I agree with Greg Mirsky that the adoption guidelines are confusing and con= tradictory. Bullet #1 states that by expressing support for adoption the WG member is = agreeing to adoption of a document that has multiple SRv6 compression solut= ions. On the other hand bullet #4 states that if the draft is adopted that the fo= llowing text excerpt below should be added to as an open issue issues secti= on. * "Given that the working group has said that it wants to standardize o= ne data plane solution, and given that the document contains multiple SRv6 = EndPoint behaviors that some WG members have stated are multiple data plane= solutions, the working group will address whether this is valid and cohere= nt with its one data plane solution objective.". This sentence is very confusing as the WG chairs agree that the WG has cons= ensus on a single solution to avoid interoperability, and the WG chairs ack= nowledge that some WG members feel that the multiple flavors are actually m= ultiple solutions, how is it possible that the WG would address that this i= s as valid and coherent with one date plane solution as the objective. The= valid and coherent part of how a multiple data plane solution or flavor me= ets the single data plane objective is contradictory. I believe what is stated here by the chairs is exactly what should have be= en cleared up prior to the adoption call, but now as the adoption call has = started would be cleared up during the adoption call process. This is som= ewhat of a chess game as to which way to have proceeded, but I think gettin= g this cleared up prior to the call for adoption would have been better for= the WG. All WG members that feel strongly that the two endpoint flavors are two dis= tinctly different solutions will stick to their guns and support not adopti= ng the document. All WG members that are Ok with two solutions versus a single SRV6 compress= ion solution will chose to adopt the draft. The down side of not resolving this issue prior to adoption call is that t= here is a chance the many that felt strongly for a single solution as risk = of interoperability issues as all vendors due to cost may not want to imple= ment multiple compression solutions and may not all pick the same compressi= on solution. So there could be a unanimous vote to not adopt as this goes against the WG= consensus on a single data plane solution. I agree that is not a major risk going this route as the draft would be kic= ked back to the authors to revise and pick one of the flavors to put forwar= d for adoption. The flip side is we are back to the drawing board with the DT on WG consens= us on a compression solution to agree to for an adoption call. Kind Regards Gyan On Fri, Oct 1, 2021 at 4:55 PM Tony Li > wrote: +1 I object to the adoption. Tony On Oct 1, 2021, at 1:43 PM, Andrew Alston > wrote: Just to add to this, I am one of the people who clearly stated that I didn't think a single solu= tion was the right answer here - and I stated my reasoning clearly on this = list. I still believe that - however - I recognize that the foundation of = the IETF is found in the bottom up consensus approach - and when the workin= g group has demonstrated such clear consensus - to defy that - is to defy w= hat makes the IETF the IETF. So - While I still believe in multiple solutions - irrespective of that - I= find this call appalling - because as much as I believe in multiple soluti= ons - the working group consensus should be sacrosanct. Andrew From: Andrew Alston > Date: Friday, 1 October 2021 at 23:21 To: James Guichard >, SPRING WG > Cc: spring-chairs@ietf.org > Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/draft-fi= lsfilscheng-spring-srv6-srh-compression/ Sorry - but - I'm a little confused here. Because the way I look at this - the working group clearly stated that they= wished for a single behavior - and this - does not deliver that - it is tw= o separate behaviors. As such - I see this call for adoption - irrespectiv= e of the merits or lack thereof of the draft, as a clear defiance of the st= ated will of the working group. This is simply does not fit into the definition of bottom up approach in my= opinion - and if this is the way that the chairs wish to proceed - then th= e only way to do that and still fit within the bottom up approach is to fir= st ask this working group for its consensus to deviate from the single beha= cvior approach that the working group agreed to. As such - I must strongly and unequivocally object to this call for adopti= on Andrew From: spring > on b= ehalf of James Guichard > Date: Friday, 1 October 2021 at 17:05 To: SPRING WG > Cc: spring-chairs@ietf.org > Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardization work. That is part o= f what this email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear g= uidelines as follows. By expressing support for adoption of this document y= ou are fully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email] Gyan Mishra Network Solutions Architect Email gyan.s.mishra@verizon.com M 301 502-1347 --_000_MN2PR13MB420666FE6C32E75472999B44D2AE9MN2PR13MB4206namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Gyan,

 

Please see the chairs response to the email from And= rew Alston.

 

Yours,

 

Jim, Bruno & Joel.

 

From: Gyan Mishra <hayabusagsm@gmail.com&g= t;
Sent: Friday, October 1, 2021 7:26 PM
To: Tony Li <tony.li@tony.li>
Cc: Andrew Alston <Andrew.Alston=3D40liquidtelecom.com@dmarc.ietf= .org>; James Guichard <james.n.guichard@futurewei.com>; SPRING WG = <spring@ietf.org>; spring-chairs@ietf.org
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.= org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

 

 

Dear WG chairs,

 

I agree with Greg Mirsky that the adoption guideline= s are confusing and contradictory.   

 

Bullet  #1 states that by expressing support fo= r adoption the WG member is agreeing to adoption of a document that has mul= tiple SRv6 compression solutions.  

 

On the other hand bullet #4 states that if the draft= is adopted that the following text excerpt below should be added to as an = open issue issues section.  

 

 

  • "Given that the working group has said that it wants to standardize on= e data plane solution, and given that the document contains multiple SRv6 E= ndPoint behaviors that some WG members have stated are multiple data plane = solutions, the working group will address whether this is valid and coherent with its one data plane solution object= ive.".

 

This sentence is very confusing as the WG chairs agr= ee that the WG has consensus on a single solution to avoid interoperability= , and the WG chairs acknowledge that some WG members feel that the multiple= flavors are actually multiple solutions, how is it possible that the WG would address that this is as valid and coh= erent with one date plane solution as the objective.  The valid and co= herent part of how a multiple data plane solution or flavor meets the singl= e data plane objective is contradictory.

 

 I believe what is stated here by the chairs is= exactly what should have been cleared up prior to the adoption call, but n= ow as the adoption call has started  would be cleared up during the ad= option call process.  This is somewhat of a chess game as to which way to have proceeded, but I think getting this cle= ared up prior to the call for adoption would have been better for the WG.

 

All WG members that feel strongly that the two endpo= int flavors are two distinctly different solutions will stick to their guns= and support not adopting the document.

 

All WG members that are Ok with two solutions versus= a single SRV6 compression solution will chose to adopt the draft.  

 

The down side of not resolving this issue prior to a= doption call  is that there is a chance the many that felt strongly fo= r a single solution as risk of interoperability issues as all vendors due t= o cost may not want to implement multiple compression solutions and may not all pick the same compression solution. =  

 

So there could be a unanimous vote to not adopt as t= his goes against the WG consensus on a single data plane solution.

 

I agree that is not a major risk going this route as= the draft would be kicked back to the authors to revise and pick one of th= e flavors to put forward for adoption.   

 

The flip side is we are back to the drawing board wi= th the DT on WG consensus on a compression solution to agree to for an adop= tion call.

 

Kind Regards 

 

Gyan

 

On Fri, Oct 1, 2021 at 4:55 PM Tony Li <tony.li@tony.li> wrote:

 

+1

 

I object to the adoption.

 

Tony

 



On Oct 1, 2021, at 1:43 PM, Andrew Alston <Andrew.Alston=3D40liquidtelecom.com@dmarc.ietf.org> wrote:

 

Just to add to this,

 

I am one of the people who clearly stated that I did= n’t think a single solution was the right answer here – and I s= tated my reasoning clearly on this list.  I still believe that –= however – I recognize that the foundation of the IETF is found in the bottom up consensus approach – and when the working gro= up has demonstrated such clear consensus – to defy that – is to= defy what makes the IETF the IETF.

 

So – While I still believe in multiple solutio= ns – irrespective of that – I find this call appalling – = because as much as I believe in multiple solutions – the working grou= p consensus should be sacrosanct.

 

Andrew

 

 

From: Andre= w Alston <Andrew.Alston@liquidtelecom.com= >
Date: Friday, 1 October 2021 at 23:21
To: James Guichard <james.n.guichard@= futurewei.com>, SPRING WG <spring@ietf.org<= /a>>
Cc: spring-chairs@ietf.org <<= a href=3D"mailto:spring-chairs@ietf.org" target=3D"_blank">spring-chairs@ietf.org>
Subject: Re: WG Adoption call for https://data= tracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Sorry – but – I’m a little confuse= d here.

 

Because the way I look at this – the working g= roup clearly stated that they wished for a single behavior – and this= – does not deliver that – it is two separate behaviors.  = As such – I see this call for adoption – irrespective of the me= rits or lack thereof of the draft, as a clear defiance of the stated will of th= e working group.

 

This is simply does not fit into the definition of b= ottom up approach in my opinion – and if this is the way that the cha= irs wish to proceed – then the only way to do that and still fit with= in the bottom up approach is to first ask this working group for its consensus to deviate from the single behacvior appro= ach that the working group agreed to.

 

As such – I must  strongly and unequivoca= lly object to this call for adoption

 

Andrew

 

From: sprin= g <spring-b= ounces@ietf.org> on behalf of James Guichard <james.n.guichard@futurewei= .com>
Date: Friday, 1 October 2021 at 17:05
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/

Dear WG:

 

The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

 

The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-s= pring-srv6-srh-compression/ as the basis for its compression standardization work. That is part of what t= his email attempts to confirm.

 

Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ but with some clear guidelines as follows. By expressing support for adoption = of this document you are fully aware of and are acknowledging that:

 

  1. The SPRING workin= g group is adopting a document that has multiple SRv6 Endpoint behaviors.
  2. The= document is a “living” document; it may change as it goes thro= ugh review and analysis by the SPRING working group.
  3. All open discussion poin= ts raised on our mailing list MUST be addressed BEFORE said document is all= owed to progress from the working group to publication. A list of these dis= cussion points will be documented in the WG document and maintained by the document editor in conjunction wi= th the chairs.
  4. If this document is adopted by the working group, the chairs s= pecify as part of the adoption call that the following text describing an o= pen issue be added to the document in the above-described open issues section:
    • "Given that = the working group has said that it wants to standardize one data plane solu= tion, and given that the document contains multiple SRv6 EndPoint behaviors= that some WG members have stated are multiple data plane solutions, the working group will address whether this is valid= and coherent with its one data plane solution objective.".=

 

Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

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

 

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

--

=

Gyan Mishra=

Network Solutions Architect&nb= sp;

Email gyan.s.mishr= a@verizon.com

M 301 = 502-1347

 

--_000_MN2PR13MB420666FE6C32E75472999B44D2AE9MN2PR13MB4206namp_-- From nobody Mon Oct 4 08:18:05 2021 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 C01783A08C5 for ; Mon, 4 Oct 2021 08:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=eWytfqMz; dkim=pass (1024-bit key) header.d=juniper.net header.b=gg31civ8 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 5AGV37aDKdkW for ; Mon, 4 Oct 2021 08:17:58 -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 21A143A08C4 for ; Mon, 4 Oct 2021 08:17:58 -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 SMTP id 194EjlpD026594; Mon, 4 Oct 2021 08:17:56 -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=sjl/43UcPzUXc7TuPPz8sEnKj6nMQqXvjzdRVrmI4U0=; b=eWytfqMzxhUPuu9S8zdsTNhQwonIR8Q7FC+baoI/lJsWToEeyFR496430SpOI5SNNf7T 8dwDqRKNE9WCPLvBZJc6Kw4f8yx8K8/ydfLym3aSkgwCYIoFEwB+0ky2ev/cHiDTrSqM XEvCJJ1vn+nwax9LOUBGBKLeSw7gcWzs3MDVVt+jj4fx5uuDljH4fyiyKf03xodI6aaG fOBg+0e3wqyoDmYoorFOqd1DKl5liZ8kSfiLFugrES6COUtHkGTVH1SNL18E7Uotw29V v3hWSWOXQKTDtMFSx55jhhG8ZSrpcJo3037NIz3yXQrCuI+j3OuoDcThdFfK1ju6l/Gd HQ== Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2170.outbound.protection.outlook.com [104.47.57.170]) by mx0b-00273201.pphosted.com with ESMTP id 3bfuxc0x6x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Oct 2021 08:17:55 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=C1dyLoxd/Shbw+PJOyp0QIKEotjWz1jGmGwpU4WEvS6CAvZX49c7zJpfHGAhCdrhrE/G4c2s3AFMzRxuguUT/VY6fXCjVAvJnk6cC3zD9aME10QwuAg8mV2/RWUfkejpHgRiV2VLsvQ2g9rZmMj8zZOZk90t/ToMc0Ijjvx1w1bp8XCFECGxOfumdZRGEcakiVA+fmx4xvz99YcV4m0/pGmVrpZE4FPVIzsZ2WapxNPuSd7ZquRihxY2fXjbmAistPq685zyskCTwBD1lvLoV2cI02tlrkUzfzjPumramo9/t7kouUMxTz8jFxiZw7Xdv7YQrkmgp8Jgfors2IjsQA== 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=sjl/43UcPzUXc7TuPPz8sEnKj6nMQqXvjzdRVrmI4U0=; b=L3hYWSO7DswxViEb/joh3+8TGFb2uehA4C6SZY7jZVjiiO/DAkBTCh1YbL+g4hu3ldIGPlU30I+OX4fKyg2FqekzARzQCccLiIZweRG22dkk9CzZVrtPyEB5bc4pNbZvId0RDpsBG2DBRhzW9CEWfnhKOjiQ+YcLB8bmcZz/H74tONFPMHaqYGQ2oNO5SEhY32+Zq10sNbjltPNesOqX4onDEe7r3ZNwsuPJpj1PmN1VfRIv/K80JyfHF1Hh2IXdCHP35bYQMmhNr8coziOj6w3GExeIX90V22+adDg/ef6/Mdps4kTYV8Jn9PUZGCOq7uDUwfoQpShcqUjHFFU94Q== 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=sjl/43UcPzUXc7TuPPz8sEnKj6nMQqXvjzdRVrmI4U0=; b=gg31civ8kOj8cV6XIwm2ngk+IlM9D5MDHzQ3xCBVV/sHAJiwYHkr9u4a206LVSCLGnQ18QtQC9+XrPKJgU1jThvK0EjvurqiPjF6R0zQSkj1OG6P4afNcmP5W5N2T1jyj/ETid37fiOxJ+DLoldP3CXDb6TEGN5mt5PmUN9xeq8= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by BL0PR05MB4740.namprd05.prod.outlook.com (2603:10b6:208:58::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.9; Mon, 4 Oct 2021 15:17:51 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4587.016; Mon, 4 Oct 2021 15:17:51 +0000 From: Ron Bonica To: "liu.aihua@zte.com.cn" CC: "robert@raszuk.net" , "spring@ietf.org" Thread-Topic: Re:[spring] CSID Question Thread-Index: Ade2+c1KozTuOJAoRFyi9icelIkpNwACYe+AAAAh62AAASeMAAAimjWaABfhlgAAT7Ud0A== Date: Mon, 4 Oct 2021 15:17:50 +0000 Message-ID: References: BL0PR05MB5316659C505F9BFBE915D59BAEAB9@BL0PR05MB5316.namprd05.prod.outlook.com, CAOj+MMG2hRhCvZd8ifTM=sSgkdW+09oK+ORMqQ47dJ-0QwnaxA@mail.gmail.com, BL0PR05MB531627B8F2F345E073EDF5D4AEAB9@BL0PR05MB5316.namprd05.prod.outlook.com, CAOj+MMGWEwEdhqi1wEJj2hu3FKLdVKA=xt0XxNvsPw-Z5-p3ww@mail.gmail.com, 5449C581-4F7F-4C49-BE77-072802E4FF05@juniper.net <202110030903029947713@zte.com.cn> In-Reply-To: <202110030903029947713@zte.com.cn> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-04T15:17:49Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=b4ee20e5-355e-4931-9311-b6b2129e8e4d; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: zte.com.cn; dkim=none (message not signed) header.d=none;zte.com.cn; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1960d18b-909d-4477-a141-08d9874a21a2 x-ms-traffictypediagnostic: BL0PR05MB4740: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FznrsNVlJzhEQU1BZcLWidpT3ZbJmDg4Zl81UEFyUznlk5EOQW2u/g9TxKZ3mmqJSruKEXPqGNbUdDGfrv6/0o77GujHTJio3Y6SIssNyF7A5KNU5EewqvqRefW1bTzzs8LRQDvs2etIv9mIemghg3AfcnpaumneLmYfJvFW6yWS5iIVbrxa7MDb2IiKg5WS1d/nu6143DOykILPGTVYWgFQt624bFryN+4T79BDAFSHSSLSKURuNdYVpfJY0RHPUpO28nk76LmP5lqar+bu0oDWzNw04vGlXSCDqGI+hmjiCKxEdyF8VPaQkpep2tnXQeQsTAvZWdWNkhG5lt1MDu5tAgBg6ptFkIsnHeTRrOmNdstGRhuNf9bJ4h4YTow1MKgvYVMJPdb0OINLpi8tFURDKaMLRpsKkan34jRV2ucbCL5gZIF/GxbxxO3l7JyKt/4Gyl5ZU/ccQGLvi73LzJoyAMRUz5WdM2WLUdqTpIbKqKKzgHgCTYox5K9gNm2hF3UAW+hyh0AzPe3rhNIEbsjC92ZhOvgwkC8acbG02hd2vD5XEggcsWd3dv49tXgASHi/yUaa2Hov7j32kuzkOXMBkmCFdmr+UWDjO5u+0s7icljgmz3OtfU2JhQFia0NqKIK5d8RIVXMcloqOYWpdiT5YToR+YDxbHrS9hvJ0HPyZgLcaqt6yM+XLRLwkTQ99Ix6GhnFxhgBySVKv6g773SJf0idJmb+whjopIdjrPuUoFde+EWHlDywAhdi5W7XAW67YWHuMfb80EFjMFPJKmT8StVgbA8hedlsupk33Kk= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(7696005)(55016002)(86362001)(316002)(166002)(966005)(54906003)(8936002)(5660300002)(53546011)(2906002)(6506007)(6916009)(9686003)(186003)(33656002)(4326008)(76116006)(8676002)(122000001)(52536014)(66446008)(26005)(38100700002)(66476007)(508600001)(38070700005)(71200400001)(66556008)(66946007)(64756008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: DJDa0/CnMP5SvMBCEooYpObBlk8Quj/pGdZ1g4RO5n5W4fJ54tKRNl4tzz8BmfvzquGpxFQlVTCjxqHQkyJ/VaSXv0WcuVnsZTZAjXBcsN7e+nXfUqtnn315+ACQ0zps316tyktoyGJVdK0YIML1yNu6/yqXptbZPi83y5XU5QY0SDlkdmaE2NOTakKGfDftks4X5PSbK9nDVDzemPba2xzsgFqcEOis0PSJzfBzXFZMe0mwRmn/EC1VynWKDENkyIHeI7kWkwlMyGMGkm6fBZikENGUdvVHD7O9d6ep6FFhUeDf5g5QslG7t91yQZA98T0XfVOSBjwOSJ+JvNw59lx1/QhG1+UvvGTpcrWSmvvtQgi8haxUZ7sfut7ZmyIYPbbYPnvKe6IsAI5xBbSfsDYtnUBqdK6lbLj2QqpPxrvsB/j4NObKd3tnJyqOSZlCx7Dv+5HT8BRsgq3tj42XNvZ1qnZPGIONeF1jS7ZhISL/CQuKc1i6qsla36s/iJkWeauqxCwPm/A+c5AfUniSRw3vyqsVcl/PBs+rLXkxlbkFU2FiO01BvUXyOLcUL0nVl3zPk3HyIBbkbD9om+IAmHfx2zFjigTgbKy3H4SVtHe2+aiGnnGOD+BX/m9e+xtKftvEWAitFen0858Rt2sijU5OMXGFoW2epewQtsjjS+eInH7K3mruPemej9p+yAEVWTfrNpz9TFYAcWMBXwTZpYdtadwQNxJwWpMJNlNoxBc= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR05MB531657D410BFABF2264ABE1AAEAE9BL0PR05MB5316namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1960d18b-909d-4477-a141-08d9874a21a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2021 15:17:50.9262 (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: iAe15cY0uJWoP5aziliuy+L4xT4WiCAqX75bQ/5tXT2SjIalInrxo1DL0TgKEslf0umHAVmlblJ4VaFFsJWaGw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB4740 X-Proofpoint-GUID: hZcTOAXd_L4ESgR2LWiHjyHzGjpYjoyh X-Proofpoint-ORIG-GUID: hZcTOAXd_L4ESgR2LWiHjyHzGjpYjoyh X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-04_04,2021-10-04_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 bulkscore=0 mlxlogscore=999 adultscore=0 malwarescore=0 spamscore=0 suspectscore=0 impostorscore=0 phishscore=0 priorityscore=1501 clxscore=1011 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110040105 Archived-At: Subject: Re: [spring] CSID Question 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, 04 Oct 2021 15:18:04 -0000 --_000_BL0PR05MB531657D410BFABF2264ABE1AAEAE9BL0PR05MB5316namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWlodWEsDQoNCkkgZG9u4oCZdCByZWNhbGwgdGhpcyBiZWluZyBkaXNjdXNzZWQgaW4gdGhlIGRl c2lnbiB0ZWFtLCBidXQgbXkgbWVtb3J5IG1heSBiZSBmYWlsaW5nIG1lLiBUaGUgZGVzaWduIHRl YW0ga2VwdCBtZXRpY3Vsb3VzIG1pbnV0ZXMgKCBodHRwczovL21haWxhcmNoaXZlLmlldGYub3Jn L2FyY2gvYnJvd3NlL3NyY29tcC8gKSBhbmQgaXQgd291bGQgYmUgdmVyeSBoZWxwZnVsIG9mIHlv dSBjb3VsZCBwb2ludCBtZSB0aGUgbWVldGluZyB3aGVyZSB0aGlzIHdhcyBkaXNjdXNzZWQuDQoN CkkgYWdyZWUgdGhhdCBpdCB3b3VsZCBiZSBkaWZmaWN1bHQgdG8gZmluZCBhIHVzZS1jYXNlIHdo ZXJlIGJvdGggRy1TSUQgYW5kIHVTSUQgYXJlIGJvdGggcmVxdWlyZWQuIEhvd2V2ZXIsIEkgYXNr IHRoZSBxdWVzdGlvbiBmb3IgdGhlIGZvbGxvd2luZyByZWFzb25zOg0KDQoNCiAgKiAgIFRvIGRl dGVybWluZSB3aGV0aGVyIEctU0lEIGFuZCB1U0lEIGFyZSBkaWZmZXJlbnQgYmVoYXZpb3JzLiBJ ZiB0aGV5IGRvbuKAmXQgd29yayB3ZWxsIHRvZ2V0aGVyIGluIGEgc2luZ2xlIGRvbWFpbiwgaXQg d291bGQgYmUgZGlmZmljdWx0IHRvIGFyZ3VlIHRoYXQgdGhleSBhcmUgYSBzaW5nbGUgYmVoYXZp b3INCiAgKiAgIFRvIGRldGVybWluZSB3aGV0aGVyIHRoZXkgYXJlIGJvdGggbmVlZGVkLg0KICAq ICAgVG8gZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIEMtU0lEIGVuY2Fwc3VsYXRpb24gb3ZlcmhlYWQg cmVkdWN0aW9uIHN0YXRpc3RpY3MgcmVwb3J0ZWQgaW4gdGhlIGFuYWx5c2lzIGRvY3VtZW50IHJl ZmxlY3QgdVNJRCBvbmx5LCBHLVNJRCBvbmx5LCBvciBhIGNvbWJpbmF0aW9uIG9mIGJvdGgNCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb24NCg0KDQoNCg0KSnVuaXBlciBCdXNp bmVzcyBVc2UgT25seQ0KRnJvbTogbGl1LmFpaHVhQHp0ZS5jb20uY24gPGxpdS5haWh1YUB6dGUu Y29tLmNuPg0KU2VudDogU2F0dXJkYXksIE9jdG9iZXIgMiwgMjAyMSA5OjAzIFBNDQpUbzogUm9u IEJvbmljYSA8cmJvbmljYUBqdW5pcGVyLm5ldD4NCkNjOiByb2JlcnRAcmFzenVrLm5ldDsgc3By aW5nQGlldGYub3JnDQpTdWJqZWN0OiBSZTpbc3ByaW5nXSBDU0lEIFF1ZXN0aW9uDQoNCltFeHRl cm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF0NCg0KDQoNCg0KSGkgUm9uLA0KDQpZ b3UgcmFpc2VkIGFuIGludGVyZXN0aW5nIHF1ZXN0aW9uLCBidXQgSSB0aGluayBpdCBtaWdodCBi ZSBhbHJlYWR5IGRpc2N1c3NlZCBpbiB0aGUgRFQuIEluIG15IHVuZGVyc3RhbmRpbmcsIHRoaXMg cXVlc3Rpb24gaXMganVzdCBtb3JlIHJlbGF0ZWQgdGhlIHVzZWNhc2VzIGFuZCByZXF1aXJlbWVu dHMgYnV0IHRoZSBzb2x1dGlvbnMuIEluIGEgU1J2NiBkb21haW4sIHRoZSBoZWFkZXIgY29tcHJl c3Npb24gZWZmZWN0aW9uIGRlcGVuZHMgb24gdGhlIFNJRCBpbmZvcm1haW9uIHJlZHVuZGVuY2ll cyBkdWUgdG8gdGhlIHJlYXNvbmFibGUgU0lEIHBsYW5uaW5nIHdpdGggdGhlIFNSdjYgY29tcGF0 aWJsZSBzb2x1dGlvbi4gSSB0aGluayBpdCdzIG1lYW5sZXNzIHRvIGNvbXByZXNzIHRoZSBTUnY2 IGhlYWRlciBpbiB0aGUgY2FzZSBvZiByYW5kb20gU0lEIGZvcm1hdC4gQmVzaWRlcyBvdGhlciBz b2x1dGlvbiB3aXRob3V0IGVuZ291dGggU1J2NiBjb21wYXRpYmxlIHN1Y2ggYXMgVW5pZmllZCBT SUQgY291bGQgYmUgdXNlZCB0byByZXNvbHZlIHRoZSB1c2VjYXNlIHlvdSBtZW50aW9uZWQuIEkg YmVsaWV2ZSB0aGF0IGhhZCBiZWVuIGRpc2N1c3NlZCBhbmQgY29tcGFyZWQgd2l0aGluIHRoZSBE VCBhbmQgdGhlIG9uZSBzb2x1dGlvbiBjb21wYXRpYmxlIHdpdGggU1J2NiBpcyBwcmVmZXJyZWQs IHRoYXQgaXMgdGhlIENTSUQgZHJhZnQuDQoNCg0KDQpCZXN0IFJlZ2FyZHMsDQoNCkFpaHVhDQoN Cg0K5Y6f5aeL6YKu5Lu2DQrlj5Hku7bkurrvvJpSb25Cb25pY2ENCuaUtuS7tuS6uu+8mlJvYmVy dCBSYXN6dWs7DQrmioTpgIHkurrvvJpTUFJJTkcgV0c7DQrml6Ug5pyfIO+8mjIwMjHlubQxMOac iDAy5pelIDIxOjM5DQrkuLsg6aKYIO+8mlJlOiBbc3ByaW5nXSBDU0lEIFF1ZXN0aW9uDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxp bmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KDQpGb2xrcywNCk5vdyB0aGF0 IFJvYmVydCBhbmQgSSBoYXZlIHByb3ZpZGVkIHNvbWUgZW50ZXJ0YWlubWVudCwgY291bGQgc29t ZW9uZSBhbnN3ZXIgdGhlIHRlY2huaWNhbCBxdWVzdGlvbiB0aGF0IGluaXRpYXRlZCB0aGlzIHRo cmVhZD8NCg0KRG9lcyB0aGUgZG9jdW1lbnQgcmVjb21tZW5kIGFnYWluc3QgdXNpbmcgTmV4dC1D LVNJZCBhbmQgUmVwbGFjZS1DLVNpZCBpbiB0aGUgc2FtZSBkb21haW4gIGZvciBlYXNlIG9mIG9w ZXJhdGlvbiBvciBiZWNhdXNlIHRoZXkgZG9u4oCZdCB3b3JrIHdlbGwgdG9nZXRoZXI/IElmIHRo ZSBmb3JtZXIsIHBsZWFzZSBwcm92aWRlIHRoZSBleGFtcGxlIGRlc2NyaWJlZCBiZWxvdy4NCg0K ICAgICAgICAgICAgICBSb24NCg0KDQpTZW50IGZyb20gbXkgaVBob25lDQoNCk9uIE9jdCAxLCAy MDIxLCBhdCA1OjA3IFBNLCBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86 cm9iZXJ0QHJhc3p1ay5uZXQ+PiB3cm90ZToNCu+7vw0KDQoNCltFeHRlcm5hbCBFbWFpbC4gQmUg Y2F1dGlvdXMgb2YgY29udGVudF0NCg0KDQoNCkhpIFJvbiwNCg0KDQogICogICBDYW4gd2Ugc2F5 IHRoYXQgdGhleSBhcmUgYSBzaW5nbGUgYmVoYXZpb3IgPw0KDQpOby4gQW5kIG5laXRoZXIgUkZD ODk4NiBkZWZpbmVzIGEgc2luZ2xlIGJlaGF2aW9yIG9yIHNpbmdsZSBmbGF2b3IuIFlldCB0aGUg Ym91bmRzIGFyZSBjbGVhcmx5IHNldCB3aGF0IGlzIHRoZSBTUnY2IGRhdGEgcGxhbmUuDQoNCkZv ciBzb21lIHN0cmFuZ2UgcmVhc29uIEkgYW0gb2JzZXJ2aW5nIGhlcmUgYW4gYXR0ZW1wdCB0byBz cXVlZXplIGRpZmZlcmVudCBkYXRhIHBsYW5lIGludG8gdGhlIHJvb20gd2hpY2ggaXMgbm90IGNv bXBsaWFudCB0byBbUkZDODQwMl0sIFtSRkM4NzU0XSBhbmQgW1JGQzg5ODZdLiBEbyB5b3UgdGhp bmsgYW55b25lIHdpbGwgYmUgc28gbmFpdmUgdG8gYWNjZXB0IGl0ID8NCg0KTm93IEkgYW0gZ29p bmcgdG8gcmVzdCBhc3N1cmVkIGFuZCBlbmpveSB0aGUgcmVzdCBvZiB0aGlzIHNob3cuDQoNCkJl c3QsDQpSb2JlcnQNCg0KDQpPbiBGcmksIE9jdCAxLCAyMDIxIGF0IDEwOjU4IFBNIFJvbiBCb25p Y2EgPHJib25pY2FAanVuaXBlci5uZXQ8bWFpbHRvOnJib25pY2FAanVuaXBlci5uZXQ+PiB3cm90 ZToNClJvYmVydCwNCg0KSSBkbyByZW1lbWJlciB0aGF0IHF1b3RlLiBBbmQgdGhhdCBpcyBleGFj dGx5IHdoeSBJIGFzayB0aGUgcXVlc3Rpb24hDQoNCklmIE5FWFQtQy1TSUQgYW5kIFJFUExBQ0Ut Qy1TSUQgYXJlIGluY29tcGF0aWJsZSB3aXRoaW4gYSBkb21haW46DQoNCg0KICAqICAgQ2FuIHdl IHNheSB0aGF0IHRoZXkgYXJlIGEgc2luZ2xlIGJlaGF2aW9yID8NCiAgKiAgIENhbiB3ZSBqdXN0 aWZ5IGJvdGggYmVjYXVzZSBlYWNoIGlzIG9wdGltaXplZCBmb3IgYSBkaWZmZXJlbnQga2luZCBv ZiBuZXR3b3JrPw0KICAqICAgQ2FuIHdlIGp1c3RpZnkgYW5vdGhlciBiZWhhdmlvciBlaXRoZXIg YmVjYXVzZSBpdCBpcyBvcHRpbWl6ZWQgZm9yIHlldCBhbm90aGVyIHR5cGUgb2YgbmV0d29yayBv ciBiZWNhdXNlIGl0IGRvZXMgcmVsYXRpdmVseSB3ZWxsIGluIGFsbCBuZXR3b3JrIHR5cGVzPw0K DQpIb3dldmVyLCBpZiB0aGlzIGlzIGp1c3QgYW4g4oCcZWFzZSBvZiBvcGVyYXRpb27igJ0gdGhp bmcsIGFzIHN0YXRlZCBpbiB0aGUgZHJhZnQsIHRoZSBhdXRob3JzIGFyZSBvYmxpZ2VkIHRvIGFu c3dlciBteSBxdWVzdGlvbi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIFJvbg0KDQpQLlMuIFJlc3QgYXNzdXJlZCB0aGF0IEkgaGF2ZSByZWFkIHRoZSBkcmFmdC4g SG93ZXZlciwgeW91ciBjb25jZXJuIGlzIGdyZWF0bHkgYXBwcmVjaWF0ZWQg8J+YiQ0KDQoNCg0K DQpKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQpGcm9tOiBSb2JlcnQgUmFzenVrIDxyb2JlcnRA cmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KU2VudDogRnJpZGF5LCBPY3Rv YmVyIDEsIDIwMjEgNDozMiBQTQ0KVG86IFJvbiBCb25pY2EgPHJib25pY2FAanVuaXBlci5uZXQ8 bWFpbHRvOnJib25pY2FAanVuaXBlci5uZXQ+Pg0KQ2M6IFNQUklORyBXRyA8c3ByaW5nQGlldGYu b3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtzcHJpbmddIENTSUQg UXVlc3Rpb24NCg0KW0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XQ0KDQpI aSBSb24sDQoNCkhhdmUgeW91IHJlYWQgdGhpcyBkcmFmdCA/DQoNClF1b3RlIGZyb20gaXQ6DQoN Cg0KICAgSXQgaXMgcmVjb21tZW5kZWQgZm9yIGVhc2Ugb2Ygb3BlcmF0aW9uIHRoYXQgYSBzaW5n bGUgY29tcHJlc3NlZA0KDQogICBlbmNvZGluZyBmbGF2b3IgYmUgdXNlZCBpbiBhIGdpdmVuIFNS djYgZG9tYWluLiAgSG93ZXZlciwgaW4gYSBtdWx0aS0NCg0KICAgZG9tYWluIGRlcGxveW1lbnQs IGRpZmZlcmVudCBmbGF2b3JzIGNhbiBiZSB1c2VkIGluIGRpZmZlcmVudA0KDQogICBkb21haW5z Lg0KDQpPbiBGcmksIE9jdCAxLCAyMDIxIGF0IDk6MzMgUE0gUm9uIEJvbmljYSA8cmJvbmljYT00 MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGp1bmlwZXIubmV0QGRtYXJjLmll dGYub3JnPj4gd3JvdGU6DQpDU0lEIEF1dGhvcnMsDQoNCkFzc3VtZSB0aGF0IGFuIFNSIHBhdGgg Y29udGFpbnMgc2VnbWVudHMgMSB0aHJvdWdoIDguIFNlZ21lbnRzIDEsIDMsIDUsIGFuZCA3IGFy ZSBFTkQgU0lEcyB0aGF0IHVzZSBOZXh0LUMtU0lEIChpLmUuLCB1U0lEKS4gU2VnbWVudHMgMiwg NCwgYW5kIDYgYXJlIEVORCBTSURzIHRoYXQgdXNlIFJlcGxhY2UtQy1TSUQuIFNlZ21lbnQgOCBp cyBhbmQgRU5ELkRYNCBTSUQuDQoNClBsZWFzZSBwcm92aWRlIGFuIGV4YW1wbGUgdGhhdCBzaG93 cyB1czoNCg0KDQogICogICBXaGF0IHRoZSBTUkggbG9va3MgbGlrZSBhcyBpdCBhcnJpdmVzIGF0 IHRoZSBmaXJzdCBzZWdtZW50IGVuZHBvaW50DQogICogICBXaGF0IHRoZSBJUHY2IERlc3RpbmF0 aW9uIEFkZHJlc3MgbG9va3MgbGlrZSBhdCBlYWNoIHNlZ21lbnQgZW5kcG9pbnQsIGluY2x1ZGlu ZyBpbmZvcm1hdGlvbiByZXF1aXJlZCB0byBwYXJzZSB0aGUgRGVzdGluYXRpb24gQWRkcmVzcw0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgUm9uDQoNCg0KDQpKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3By aW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzxodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0 cHM6L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZ19fOyEhTkV0NnlNYU8tZ2sh VUxfTHNURVd1eWJ0ZXdjSUhYMkZ3cnF0d1MzRzk3a2kzdHpIVDhwR3lHY3gyaFBXWVpmcmlTbWVH NzV1d1A3bCQ+DQoNCg0K --_000_BL0PR05MB531657D410BFABF2264ABE1AAEAE9BL0PR05MB5316namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IlNlZ29lIFVJIEVtb2ppIjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkxhdG87DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDM7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2Ut MToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNaWNy b3NvZnQgSmhlbmdIZWkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATWljcm9zb2Z0IEpoZW5nSGVpIjt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJNaWNyb3NvZnQgWWFIZWkiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDIg MiA0IDIgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATWljcm9zb2Z0IFlhSGVp Ijt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJcGFub3NlLTE6 MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpNb25hY287 DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJ Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIi Ow0KCW1hcmdpbjowaW47DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1z b0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGlu Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6 LjVpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4u enJlYWR1c2VybmFtZQ0KCXttc28tc3R5bGUtbmFtZTp6cmVhZHVzZXJuYW1lO30NCnNwYW4uRW1h aWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KcC5tc2lwZm9vdGVy MzBiM2Q1MzgsIGxpLm1zaXBmb290ZXIzMGIzZDUzOCwgZGl2Lm1zaXBmb290ZXIzMGIzZDUzOA0K CXttc28tc3R5bGUtbmFtZTptc2lwZm9vdGVyMzBiM2Q1Mzg7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICov DQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDozNzU3NDEwNjA7DQoJbXNvLWxpc3QtdGVtcGxhdGUt aWRzOjE2MjE4MDk0Nzg7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo0NDYwNDQz NTI7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjIwMTQ0ODg2NzY7fQ0KQGxpc3QgbDE6bGV2ZWwx DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs Mg0KCXttc28tbGlzdC1pZDo1NTY5Mzk3NjQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjEyOTA4NTkyMzggNDA5OTk0MDcwIDY3Njk4NjkxIDY3Njk4Njkz IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30N CkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0 LWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6NjUxMDU4MDA1Ow0KCW1zby1saXN0LXRlbXBs YXRlLWlkczoxMDM5OTQ4MDc4O30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6 bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K dWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPkFpaHVhLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjE0LjBwdCI+SSBkb27igJl0IHJlY2FsbCB0aGlzIGJlaW5nIGRpc2N1c3NlZCBp biB0aGUgZGVzaWduIHRlYW0sIGJ1dCBteSBtZW1vcnkgbWF5IGJlIGZhaWxpbmcgbWUuIFRoZSBk ZXNpZ24gdGVhbSBrZXB0IG1ldGljdWxvdXMgbWludXRlcyAoDQo8YSBocmVmPSJodHRwczovL21h aWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJvd3NlL3NyY29tcC8iPmh0dHBzOi8vbWFpbGFyY2hp dmUuaWV0Zi5vcmcvYXJjaC9icm93c2Uvc3Jjb21wLzwvYT4gKSBhbmQgaXQgd291bGQgYmUgdmVy eSBoZWxwZnVsIG9mIHlvdSBjb3VsZCBwb2ludCBtZSB0aGUgbWVldGluZyB3aGVyZSB0aGlzIHdh cyBkaXNjdXNzZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij5J IGFncmVlIHRoYXQgaXQgd291bGQgYmUgZGlmZmljdWx0IHRvIGZpbmQgYSB1c2UtY2FzZSB3aGVy ZSBib3RoIEctU0lEIGFuZCB1U0lEIGFyZSBib3RoIHJlcXVpcmVkLiBIb3dldmVyLCBJIGFzayB0 aGUgcXVlc3Rpb24gZm9yIHRoZSBmb2xsb3dpbmcgcmVhc29uczo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIg dHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDowaW47bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzEiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTQuMHB0Ij5UbyBkZXRlcm1pbmUgd2hldGhlciBHLVNJRCBhbmQgdVNJRCBhcmUgZGlmZmVyZW50 IGJlaGF2aW9ycy4gSWYgdGhleSBkb27igJl0IHdvcmsgd2VsbCB0b2dldGhlciBpbiBhIHNpbmds ZSBkb21haW4sIGl0IHdvdWxkIGJlIGRpZmZpY3VsdCB0byBhcmd1ZSB0aGF0DQogdGhleSBhcmUg YSBzaW5nbGUgYmVoYXZpb3I8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMiBsZXZlbDEgbGZv MSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPlRvIGRldGVybWluZSB3aGV0aGVyIHRo ZXkgYXJlIGJvdGggbmVlZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwyIGxldmVsMSBs Zm8xIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+VG8gZGV0ZXJtaW5lIHdoZXRoZXIg dGhlIEMtU0lEIGVuY2Fwc3VsYXRpb24gb3ZlcmhlYWQgcmVkdWN0aW9uIHN0YXRpc3RpY3MgcmVw b3J0ZWQgaW4gdGhlIGFuYWx5c2lzIGRvY3VtZW50IHJlZmxlY3QgdVNJRCBvbmx5LCBHLVNJRCBv bmx5LCBvciBhIGNvbWJpbmF0aW9uDQogb2YgYm90aDxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91 bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjE0LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJvbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i bXNpcGZvb3RlcjMwYjNkNTM4IiBhbGlnbj0iY2VudGVyIiBzdHlsZT0ibWFyZ2luOjBpbjt0ZXh0 LWFsaWduOmNlbnRlciI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOmJsYWNr Ij5KdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206 PC9iPiBsaXUuYWlodWFAenRlLmNvbS5jbiAmbHQ7bGl1LmFpaHVhQHp0ZS5jb20uY24mZ3Q7IDxi cj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgT2N0b2JlciAyLCAyMDIxIDk6MDMgUE08YnI+DQo8 Yj5Ubzo8L2I+IFJvbiBCb25pY2EgJmx0O3Jib25pY2FAanVuaXBlci5uZXQmZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiByb2JlcnRAcmFzenVrLm5ldDsgc3ByaW5nQGlldGYub3JnPGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOltzcHJpbmddIENTSUQgUXVlc3Rpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMi4wcHQ7YmFja2dyb3VuZDojRkZF QjlDIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtM YXRvJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPltFeHRlcm5hbCBFbWFpbC4gQmUgY2F1 dGlvdXMgb2YgY29udGVudF08bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZx dW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkm cXVvdDssc2Fucy1zZXJpZiI+SGkgUm9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhl aSZxdW90OyxzYW5zLXNlcmlmIj5Zb3UgcmFpc2VkIGFuIGludGVyZXN0aW5nIHF1ZXN0aW9uLCBi dXQgSSB0aGluayBpdCBtaWdodCBiZSBhbHJlYWR5IGRpc2N1c3NlZCBpbiB0aGUgRFQuIEluIG15 IHVuZGVyc3RhbmRpbmcsIHRoaXMgcXVlc3Rpb24gaXMganVzdCBtb3JlIHJlbGF0ZWQgdGhlIHVz ZWNhc2VzIGFuZCByZXF1aXJlbWVudHMgYnV0IHRoZQ0KIHNvbHV0aW9ucy4gSW4gYSBTUnY2IGRv bWFpbiwgdGhlIGhlYWRlciBjb21wcmVzc2lvbiBlZmZlY3Rpb24gZGVwZW5kcyBvbiB0aGUgU0lE IGluZm9ybWFpb24gcmVkdW5kZW5jaWVzIGR1ZSB0byB0aGUgcmVhc29uYWJsZSBTSUQgcGxhbm5p bmcgd2l0aCB0aGUgU1J2NiBjb21wYXRpYmxlIHNvbHV0aW9uLiBJIHRoaW5rIGl0J3MgbWVhbmxl c3MgdG8gY29tcHJlc3MgdGhlIFNSdjYgaGVhZGVyIGluIHRoZSBjYXNlIG9mIHJhbmRvbSBTSUQg Zm9ybWF0Lg0KIEJlc2lkZXMgb3RoZXIgc29sdXRpb24gd2l0aG91dCBlbmdvdXRoIFNSdjYgY29t cGF0aWJsZSBzdWNoIGFzIFVuaWZpZWQgU0lEIGNvdWxkIGJlIHVzZWQgdG8gcmVzb2x2ZSB0aGUg dXNlY2FzZSB5b3UgbWVudGlvbmVkLiZuYnNwO0kgYmVsaWV2ZSB0aGF0IGhhZCBiZWVuIGRpc2N1 c3NlZCBhbmQgY29tcGFyZWQgd2l0aGluIHRoZSBEVCBhbmQgdGhlIG9uZSBzb2x1dGlvbiBjb21w YXRpYmxlIHdpdGggU1J2NiBpcyBwcmVmZXJyZWQsIHRoYXQgaXMgdGhlDQogQ1NJRCBkcmFmdC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWYiPkJlc3Qg UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJp ZiI+QWlodWE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7bGluZS1o ZWlnaHQ6MjEuMHB0O2JhY2tncm91bmQ6I0UwRTVFOSI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOiMxMzg4RkYiPuWOn+Wnizwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IEpoZW5nSGVpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzEzODhGRiI+6YKu5Lu2PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMTM4 OEZGIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IGlkPSJ6d3JpdGVIaXN0b3J5Q29udGFp bmVyIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJi YWNrZ3JvdW5kOiNGNUY2RjgiPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O01pY3Jvc29mdCBKaGVuZ0hlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj7lj5Hku7bk urrvvJo8L3NwYW4+PC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkdXNlcm5hbWUiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Um9uQm9uaWNhPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNG NUY2RjgiPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZx dW90Oztjb2xvcjpibGFjayI+5pS25Lu25Lq677yaPC9zcGFuPjwvc3Ryb25nPjxzcGFuIGNsYXNz PSJ6cmVhZHVzZXJuYW1lIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPlJvYmVydCBSYXN6dWs7 PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNGNUY2RjgiPjxzdHJvbmc+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjpibGFjayI+5oqE6YCB5Lq6 77yaPC9zcGFuPjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJ6cmVhZHVzZXJuYW1lIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPlNQUklORyBXRzs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0Y1 RjZGOCI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1 b3Q7O2NvbG9yOmJsYWNrIj7ml6U8L3NwYW4+PC9zdHJvbmc+PHN0cm9uZz48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4N Cjwvc3Bhbj48L3N0cm9uZz48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtN UyBHb3RoaWMmcXVvdDs7Y29sb3I6YmxhY2siPuacnzwvc3Bhbj48L3N0cm9uZz48c3Ryb25nPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPg0KPC9zcGFuPjwvc3Ryb25nPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjpibGFjayI+77yaPC9zcGFuPjwvc3Ryb25n PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MjAyMTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOmJsYWNrIj7lubQ8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4xMDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOmJsYWNrIj7mnIg8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4wMjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290 aGljJnF1b3Q7O2NvbG9yOmJsYWNrIj7ml6U8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij4NCiAyMTozOTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiNGNUY2RjgiPjxzdHJvbmc+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjpibGFjayI+5Li7PC9z cGFuPjwvc3Ryb25nPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+DQo8L3NwYW4+PC9zdHJvbmc+PHN0cm9u Zz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IEpoZW5nSGVpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPumimDwvc3Bhbj48L3N0cm9uZz48c3Ryb25nPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPg0KPC9zcGFuPjwvc3Ryb25nPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjpibGFjayI+77yaPC9zcGFuPjwvc3Ryb25nPjxz dHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+UmU6IFtzcHJpbmddIENTSUQgUXVlc3Rpb248L3NwYW4+PC9zdHJv bmc+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCnNwcmluZyZuYnNwO21haWxpbmcmbmJzcDtsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nIj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzwvYT48YnI+DQo8YnI+DQpGb2xrcyw8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3cgdGhhdCBSb2JlcnQg YW5kIEkgaGF2ZSBwcm92aWRlZCBzb21lIGVudGVydGFpbm1lbnQsIGNvdWxkIHNvbWVvbmUgYW5z d2VyIHRoZSB0ZWNobmljYWwgcXVlc3Rpb24gdGhhdCBpbml0aWF0ZWQgdGhpcyB0aHJlYWQ/PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRvZXMgdGhlIGRvY3VtZW50IHJl Y29tbWVuZCBhZ2FpbnN0IHVzaW5nIE5leHQtQy1TSWQgYW5kIFJlcGxhY2UtQy1TaWQgaW4gdGhl IHNhbWUgZG9tYWluICZuYnNwO2ZvciBlYXNlIG9mIG9wZXJhdGlvbiBvciBiZWNhdXNlIHRoZXkg ZG9u4oCZdCB3b3JrIHdlbGwgdG9nZXRoZXI/IElmIHRoZSBmb3JtZXIsIHBsZWFzZSBwcm92aWRl IHRoZSBleGFtcGxlIGRlc2NyaWJlZCBiZWxvdy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7IFJvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlNlbnQgZnJvbSBteSBpUGhvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+T24gT2N0IDEsIDIwMjEsIGF0IDU6MDcgUE0sIFJvYmVydCBSYXN6dWsgJmx0Ozxh IGhyZWY9Im1haWx0bzpyb2JlcnRAcmFzenVrLm5ldCI+cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJn aW4tcmlnaHQ6LjVpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDouNWluO21hcmdpbi1i b3R0b206LjAwMDFwdCI+DQrvu78gPG86cD48L286cD48L3A+DQo8cD48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMi4wcHQ7YmFj a2dyb3VuZDojRkZFQjlDIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtMYXRvJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPltFeHRlcm5hbCBF bWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF08bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cD48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhp IFJvbiw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjE0LjBwdCI+Q2FuIHdlIHNheSB0aGF0IHRoZXkgYXJlIGEgc2luZ2xlIGJlaGF2aW9yID88L3Nw YW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm8uIEFuZCBu ZWl0aGVyIFJGQzg5ODYgZGVmaW5lcyBhIHNpbmdsZSBiZWhhdmlvciBvciBzaW5nbGUgZmxhdm9y LiBZZXQgdGhlIGJvdW5kcyBhcmUgY2xlYXJseSZuYnNwO3NldCB3aGF0IGlzIHRoZSBTUnY2IGRh dGEgcGxhbmUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Gb3Igc29tZSBzdHJhbmdlJm5ic3A7cmVhc29uIEkgYW0gb2JzZXJ2aW5n IGhlcmUgYW4gYXR0ZW1wdCB0byBzcXVlZXplIGRpZmZlcmVudCBkYXRhIHBsYW5lIGludG8gdGhl IHJvb20gd2hpY2ggaXMgbm90IGNvbXBsaWFudCZuYnNwO3RvIFtSRkM4NDAyXSwgW1JGQzg3NTRd IGFuZCBbUkZDODk4Nl0uIERvIHlvdSB0aGluayBhbnlvbmUgd2lsbCBiZSBzbyBuYWl2ZSB0byBh Y2NlcHQgaXQgPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5O b3cgSSBhbSBnb2luZyZuYnNwO3RvIHJlc3QgYXNzdXJlZCBhbmQgZW5qb3kgdGhlJm5ic3A7cmVz dCBvZiB0aGlzIHNob3cuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkJlc3QsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Sb2JlcnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBG cmksIE9jdCAxLCAyMDIxIGF0IDEwOjU4IFBNIFJvbiBCb25pY2EgJmx0OzxhIGhyZWY9Im1haWx0 bzpyYm9uaWNhQGp1bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+cmJvbmljYUBqdW5pcGVyLm5l dDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBp biAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+Um9iZXJ0LDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxNC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPkkgZG8gcmVtZW1iZXIg dGhhdCBxdW90ZS4gQW5kIHRoYXQgaXMgZXhhY3RseSB3aHkgSSBhc2sgdGhlIHF1ZXN0aW9uITwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxNC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPklmIE5FWFQtQy1T SUQgYW5kIFJFUExBQ0UtQy1TSUQgYXJlIGluY29tcGF0aWJsZSB3aXRoaW4gYSBkb21haW46PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjE0LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHVsIHR5cGU9 ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZvMyI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+Q2FuIHdlIHNheSB0aGF0IHRoZXkgYXJl IGEgc2luZ2xlIGJlaGF2aW9yID88L3NwYW4+PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzMiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxNC4wcHQiPkNhbiB3ZSBqdXN0aWZ5IGJvdGggYmVjYXVzZSBlYWNoIGlzIG9wdGltaXplZCBm b3IgYSBkaWZmZXJlbnQga2luZCBvZiBuZXR3b3JrPzwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDEgbGZvMyI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjE0LjBwdCI+Q2FuIHdlIGp1c3RpZnkgYW5vdGhlciBiZWhhdmlvciBlaXRo ZXIgYmVjYXVzZSBpdCBpcyBvcHRpbWl6ZWQgZm9yIHlldCBhbm90aGVyIHR5cGUgb2YgbmV0d29y ayBvciBiZWNhdXNlIGl0IGRvZXMgcmVsYXRpdmVseSB3ZWxsIGluIGFsbCBuZXR3b3JrIHR5cGVz Pzwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPkhv d2V2ZXIsIGlmIHRoaXMgaXMganVzdCBhbiDigJxlYXNlIG9mIG9wZXJhdGlvbuKAnSB0aGluZywg YXMgc3RhdGVkIGluIHRoZSBkcmFmdCwgdGhlIGF1dGhvcnMgYXJlIG9ibGlnZWQgdG8gYW5zd2Vy IG15IHF1ZXN0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4w cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDtSb248L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQu MHB0Ij5QLlMuIFJlc3QgYXNzdXJlZCB0aGF0IEkgaGF2ZSByZWFkIHRoZSBkcmFmdC4gSG93ZXZl ciwgeW91ciBjb25jZXJuIGlzIGdyZWF0bHkgYXBwcmVjaWF0ZWQNCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSBFbW9qaSZxdW90 OyxzYW5zLXNlcmlmIj4mIzEyODUyMTs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij4mbmJzcDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTQuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgYWxpZ249ImNlbnRlciIgc3R5bGU9 Im1hcmdpbjowaW47dGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4w cHQ7Y29sb3I6YmxhY2siPkp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHk8L3NwYW4+PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvc3Ryb25nPiBSb2JlcnQgUmFzenVrICZsdDs8 YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRhcmdldD0iX2JsYW5rIj5yb2JlcnRA cmFzenVrLm5ldDwvYT4mZ3Q7DQo8YnI+DQo8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNlbnQ6PC9zcGFuPjwvc3Ryb25nPiBG cmlkYXksIE9jdG9iZXIgMSwgMjAyMSA0OjMyIFBNPGJyPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Ubzo8L3NwYW4+PC9z dHJvbmc+IFJvbiBCb25pY2EgJmx0OzxhIGhyZWY9Im1haWx0bzpyYm9uaWNhQGp1bmlwZXIubmV0 IiB0YXJnZXQ9Il9ibGFuayI+cmJvbmljYUBqdW5pcGVyLm5ldDwvYT4mZ3Q7PGJyPg0KPHN0cm9u Zz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5DYzo8L3NwYW4+PC9zdHJvbmc+IFNQUklORyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmlu Z0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5TdWJqZWN0Ojwvc3Bhbj48L3N0cm9uZz4gUmU6IFtzcHJpbmddIENTSUQgUXVlc3Rp b248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO2xpbmUtaGVpZ2h0 OjEyLjBwdDtiYWNrZ3JvdW5kOiNGRkVCOUMiPg0KPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtMYXRvJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2siPltFeHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF08L3NwYW4+PC9z dHJvbmc+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkhpIFJvbiw8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IYXZlIHlvdSByZWFkIHRoaXMmbmJz cDtkcmFmdCA/Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5RdW90ZSBmcm9tIGl0OiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6OC4wcHQgOC4wcHQgOC4wcHQgOC4wcHQi Pg0KPHByZSBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6NTIuNXB0 O21hcmdpbi1ib3R0b206Ny45cHQ7bWFyZ2luLWxlZnQ6NjQuMDVwdDtiYWNrZ3JvdW5kOiNGRkZE RjU7d29yZC1icmVhazpicmVhay1hbGw7Ym94LXNpemluZzpib3JkZXItYm94O2JvcmRlci1yYWRp dXM6NHB4O292ZXJmbG93OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O01vbmFjbyZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 IEl0IGlzIHJlY29tbWVuZGVkIGZvciBlYXNlIG9mIG9wZXJhdGlvbiB0aGF0IGEgc2luZ2xlIGNv bXByZXNzZWQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjUyLjVwdDttYXJnaW4tYm90dG9tOjcuOXB0O21hcmdp bi1sZWZ0OjY0LjA1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNb25hY28mcXVv dDssc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBlbmNvZGluZyBmbGF2b3IgYmUgdXNl ZCBpbiBhIGdpdmVuIFNSdjYgZG9tYWluLiZuYnNwOyBIb3dldmVyLCBpbiBhIG11bHRpLTwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjtt YXJnaW4tcmlnaHQ6NTIuNXB0O21hcmdpbi1ib3R0b206Ny45cHQ7bWFyZ2luLWxlZnQ6NjQuMDVw dDtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01vbmFjbyZxdW90OyxzZXJpZjtjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7IGRvbWFpbiBkZXBsb3ltZW50LCBkaWZmZXJlbnQgZmxhdm9y cyBjYW4gYmUgdXNlZCBpbiBkaWZmZXJlbnQ8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjUyLjVwdDttYXJnaW4t Ym90dG9tOjcuOXB0O21hcmdpbi1sZWZ0OjY0LjA1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQt YnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtNb25hY28mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBkb21h aW5zLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBGcmksIE9jdCAxLCAyMDIxIGF0IDk6MzMgUE0gUm9u IEJvbmljYSAmbHQ7cmJvbmljYT08YSBocmVmPSJtYWlsdG86NDBqdW5pcGVyLm5ldEBkbWFyYy5p ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc8L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGlu IDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdo dDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPkNTSUQgQXV0aG9ycyw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTQuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij5Bc3N1bWUgdGhhdCBh biBTUiBwYXRoIGNvbnRhaW5zIHNlZ21lbnRzIDEgdGhyb3VnaCA4LiBTZWdtZW50cyAxLCAzLCA1 LCBhbmQgNyBhcmUgRU5EIFNJRHMgdGhhdCB1c2UgTmV4dC1DLVNJRCAoaS5lLiwgdVNJRCkuIFNl Z21lbnRzIDIsIDQsIGFuZCA2DQogYXJlIEVORCBTSURzIHRoYXQgdXNlIFJlcGxhY2UtQy1TSUQu IFNlZ21lbnQgOCBpcyBhbmQgRU5ELkRYNCBTSUQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjE0LjBwdCI+UGxlYXNlIHByb3ZpZGUgYW4gZXhhbXBsZSB0aGF0IHNob3dz IHVzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjx1 bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPldoYXQgdGhlIFNSSCBsb29r cyBsaWtlIGFzIGl0IGFycml2ZXMgYXQgdGhlIGZpcnN0IHNlZ21lbnQgZW5kcG9pbnQ8L3NwYW4+ PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwx IGxmbzQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPldoYXQgdGhlIElQdjYgRGVz dGluYXRpb24gQWRkcmVzcyBsb29rcyBsaWtlIGF0IGVhY2ggc2VnbWVudCBlbmRwb2ludCwgaW5j bHVkaW5nIGluZm9ybWF0aW9uIHJlcXVpcmVkIHRvIHBhcnNlIHRoZSBEZXN0aW5hdGlvbiBBZGRy ZXNzPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O1Jvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBhbGlnbj0iY2Vu dGVyIiBzdHlsZT0ibWFyZ2luOjBpbjt0ZXh0LWFsaWduOmNlbnRlciI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+SnVuaXBlciBCdXNpbmVzcyBVc2UgT25seTwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc3By aW5nIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly91 cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z cHJpbmdfXzshIU5FdDZ5TWFPLWdrIVVMX0xzVEVXdXlidGV3Y0lIWDJGd3JxdHdTM0c5N2tpM3R6 SFQ4cEd5R2N4MmhQV1laZnJpU21lRzc1dXdQN2wkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8L2E+PG86cD48L286cD48L3A+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHA+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BL0PR05MB531657D410BFABF2264ABE1AAEAE9BL0PR05MB5316namp_-- From nobody Mon Oct 4 08:27:53 2021 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 9F5853A091B for ; Mon, 4 Oct 2021 08:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=liquidtelecom.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 nGUZd7kxjhy7 for ; Mon, 4 Oct 2021 08:27:37 -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 43FCB3A08ED for ; Mon, 4 Oct 2021 08:27:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquidtelecom.com; s=mimecast20210406; t=1633361251; 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=ew07CEIG2kODYnBZ/9DLaDHSdi95g7MuymPvbmQDeHs=; b=uRT16vMRuyVuVEwIYA7iU++Zb3hpEPJsJtfL40U4Wr7qv4lUudmgZBe9e/EC9J5MLMiM4a F87rNyOQHtC/YqGLBL9GhgOWCt9yfbWOrqgaZgW05peOAnvzDAjufgMfXKaBQ/yNpzdmVx RuR9DCjwJBZSmVKRUskH9/+bjK3nFmQ= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp2050.outbound.protection.outlook.com [104.47.1.50]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-227-gYApjHFCO4afWwf5RZsmXw-2; Mon, 04 Oct 2021 16:27:30 +0100 X-MC-Unique: gYApjHFCO4afWwf5RZsmXw-2 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com (2603:10a6:20b:346::6) by AS8PR03MB7639.eurprd03.prod.outlook.com (2603:10a6:20b:34b::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.15; Mon, 4 Oct 2021 15:27:28 +0000 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9]) by AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9%5]) with mapi id 15.20.4566.022; Mon, 4 Oct 2021 15:27:28 +0000 From: Andrew Alston To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQANZx9MAIq9EbAAAcTcQA== Date: Mon, 4 Oct 2021 15:27:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ffdd2a17-d5b8-4bdb-3d1a-08d9874b79e9 x-ms-traffictypediagnostic: AS8PR03MB7639: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: bsc/14UAbMaon+M9r/yfMrQKSV8+4WlSHBOzUe8UWOQJGKlZresKOF8ls+szq3ZplaUSeCaqK3tDbVW367f4hcpjfxTYmypJRRqAmAAY5tnCi44U0/+lgeF6raM8JKQ1TQwyhHgwX37gQBKPcQeDV9RN7blwvWWn+DOhCbHgFHaJwUGWw1tEp9medveCK8cIZI/CUjaXy83Mf13ODwei0teOHfzCgNbL1AnLOeenMLVSxqI1JkPKkVL+/wtMLyi+a6Dmz1E4ARIdYegELfVaFD9BY4nPANYUR1hoaZAzJXpMCQPVneDZXg78TU7gFnoOTQFpJr+rGl7H85eJpOWGpmMThqx4qzZhnq9f3WIO9OqsxVRSJhsUhNCVOCbd0YERA9a0/FoN7rRVCxLI9DxHcJormxq3undAdVoa4wXBlO8GuAZ/okHwZW5Y8j2QHaYdEgMZjIi3gnq1bgO+z/YOWiW/jXEvC4qbriG6ELi/ZjhIBkYqY9hR/+Z5siH12aLzcECvsyq++bmmJuVlSN6aNwWC44sB501oXJpn+HBLMbDbTVwIHxKaz3diMxqP2TUut1b3DymAVUcjbkz/n5mZMuzXS8GJVCKunWyJwA6bBEjPXLGEWN5SmNMZGYPIYYzXFDmiaC5Ruqig1v59LyXWPzauMdydy0sFWCaMEsjhaWR/zmfm+epahAkIZrnmRAIL79SRNEkh0gGZXEH87cG5cX/rsNZjukrgcVr1e2zickVKLZP8MEIaLOh912dj7VMTb0ki8xjocWD5d7lUZn4w7ID6f9h0SlQprgT5meAOpdr6QL88DpQUspJ0QvrP8qrRGYCWnWMH7ryWfhmz6nHJ7Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR03MB7622.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(33656002)(83380400001)(122000001)(9686003)(55016002)(71200400001)(186003)(38100700002)(166002)(38070700005)(2906002)(64756008)(66446008)(66556008)(7696005)(76116006)(966005)(6506007)(110136005)(4326008)(66946007)(316002)(52536014)(8936002)(8676002)(5660300002)(86362001)(53546011)(508600001)(66476007); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?iy/NLV92lPE2ipU2uLrn2jpFcUIjM9EqOdySl4FTlnf45341sZzGbbvEEJPe?= =?us-ascii?Q?vmtW+8k+PabeLdBnh7nT8ZiC28iYxHiyG2PYEYggayFFyZwKPl74qTZiUOJZ?= =?us-ascii?Q?s9Az/975jt6K0v3L3/UsRWwIk13Bitmy2SrsmxdxQhLmEdlW6GzEMpAciclj?= =?us-ascii?Q?UM8v34Z7QIjetJxYzbAMRkZSEBNErF33GVdNLVRPBz1cxrCojl2p0GsdiuNs?= =?us-ascii?Q?WTsUuw5E2VrXEdKHroyvd5qVinqE6ljT5St7nWp8bK/1F7vRPY8KZMGWGPvt?= =?us-ascii?Q?ZphJkX37G9YdK1tZIGJhPFXKjz87T2vAp/KjqNFmGoqHq+oV1tIhPeVi1cQJ?= =?us-ascii?Q?PDFrOxgGQQJQayQekYPVLBiPGvdOpSGJl7DggSL7BQPgStMkJvGnu3BTLQvU?= =?us-ascii?Q?excH8+CNWhd6s5aTc2BJyK8ZjXIBz3KfcdFHZYUPnqChn0WXqYQh73ssqti2?= =?us-ascii?Q?Nc8F2eMVi6hzEMV9KxtlSA/L6UAL7EvRfT1cDHCP0CRvV/FDAJsGVcmp0SHM?= =?us-ascii?Q?teRAGYvqdFcXMkKMMhVfj5d6q+N2lzpSToawDdu72YGdIsIvtJBB4TXKHIxr?= =?us-ascii?Q?AQUiAjRRE5yLucmshZJBaC13WVJ2MQAmTtgodPTwsDzWeitd8Dcrj9lkLjVQ?= =?us-ascii?Q?xJc2Lxk8lO3rFzhOcG6IBBZ9IvNNy/rkYDhoBqjMBJvdGrCpmKuP/exJmWGi?= =?us-ascii?Q?ZpLSawB6/Meji6aYRIesBDL9AR2dm+G6yVFO4bHfOibdt5kcdTbbD7G8tlpB?= =?us-ascii?Q?+Ntt2ANdtQW88AWHLg0wvUKDjfc6t47nrDbwc6Lcc9CuZI1EczM9ajgu+axx?= =?us-ascii?Q?TjnVIVSKP/e56Xwad+cpNtSPYAz8/aq5vbfZ6QRz+nYyJQy+STFFGHIXGltg?= =?us-ascii?Q?ReP3KvBPYTVdpp6qNSxQnJSswgkLRyz54BkHim12MUDqG9FP50HpwyFL3JX3?= =?us-ascii?Q?UjTnqF2eNDSzrf1GaxawycVz/8+9653Ops8dOMp7sfDmshbGJP7BdVnbHcbJ?= =?us-ascii?Q?4YbBlldCgfcDz0E6TYY7WVYpo+gIk3DfQfd0WhN0LlQpjW53AANYQyHxWx7J?= =?us-ascii?Q?4dnkzPI3uZxrM6IPPNsKV6MLBlEmb0eFN8CQ/wKyZBWPsi1QmCbkAiOLRKf7?= =?us-ascii?Q?TWUiswhagl62iNLetEnmdyQwWXgP0fCDPs61TsXiitskm+eIdLi52sBSPFEQ?= =?us-ascii?Q?R/ThEuWGdNYrlISsn27uUNnIJ1HY/P0F3JNtQrQ1n8JReLJ+wd90XiYztvM6?= =?us-ascii?Q?t+txN+pahxa/44teHnDt8iOupnD5sfwEZyLKspy7R0rwQHFph2U0ronSrvQJ?= =?us-ascii?Q?hYZ8hrFFNSJUMJhiL/qFBeF+9qF7fxnbZFc4AmzZloHZxJT9fhgy0Scot4tO?= =?us-ascii?Q?XA0AHsI=3D?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB7622.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ffdd2a17-d5b8-4bdb-3d1a-08d9874b79e9 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2021 15:27:28.3617 (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: 9e2Mdv4bipqXPzP996/kzomi19DrIF1LD1AJI8i2RzodNd7rSbCDVUgvccbKuUWuet+k0SMHbJzbjhzlppytcOqJASWwQpaKjG5Bwe/LkPY= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7639 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquidtelecom.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_AS8PR03MB76228E83511258F424159D44EEAE9AS8PR03MB7622eurp_" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 04 Oct 2021 15:27:45 -0000 --_000_AS8PR03MB76228E83511258F424159D44EEAE9AS8PR03MB7622eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Jim, Sorry - but - if the working group said one solution - and you acknowledge = that there is an issue as to if this represents one or multiple solutions -= but proceed to call for adoption anyway - on the basis that this can be re= solved post adoption - you create a very problematic solution if it is deci= ded these are two solutions. Because you will have adopted something if de= fiance of an already reached consensus at this point. The issue has to be = resolved before hand. For the record - I will support multiple solutions - as I always have - but= - again - if there is disagreement over if this represents one solution or= multiple - and the working group has said use ONE - then pure reasoning st= ands that the issue of if this is one or multiple has to be resolved - and = if we decide it is two solutions - then a further working group consensus c= all needs to be made to determine if we are going to stick with the origina= l decision. I would also like to hear the thoughts on multiple data plane solutions in = this regard from the working group chairs in 6man and the relevant AD's. I= point to the spring charter which explicitly states that work that modifie= s or extends a data plane has to be done with the agreement of the AD's and= working group chairs of the relevant area that holds the data plane (in th= is case 6man), and so - can we get some feedback there before this is adopt= ed as to - if they view this as a single option - or multiple - and if they= support this combination as we are proposing. Thanks Andrew From: James Guichard Sent: Monday, October 4, 2021 6:10 PM To: Andrew Alston ; SPRING WG Cc: spring-chairs@ietf.org Subject: RE: WG Adoption call for https://datatracker.ietf.org/doc/draft-fi= lsfilscheng-spring-srv6-srh-compression/ Andrew, As stated in our email of September 9th, the chairs communicated that the w= orking group reached rough (quite clear) consensus for standardizing one da= ta plane solution to compress segment routing over IPv6. In addition to thi= s there was an inclination toward using the CSID document as the basis for = our work in this area. The chairs recognized that there was however disagre= ement as to whether this document, having multiple SRv6 EndPoint behaviors,= could be considered consistent with the working group consensus for a sing= le data plane solution. This issue quite clearly needed to be addressed, an= d the chairs, recognizing that the working group is keen to make progress i= n this area, had the option of trying to resolve the issue prior to issuing= an adoption call, or give the working group the opportunity to express the= ir opinions as part of a call for adoption. Those who feel that we need to resolve the consistency issue before adoptio= n, as with those who think this is not a good basis for the WG work, are fr= ee and expected to object to the WG adopting the document. That is distinct= from objecting to the chairs issuing the adoption call. In essence, the chairs have combined the question of when to resolve consis= tency and the question of whether this document is a good basis for the WG = into one call. Yours, Jim, Bruno & Joel From: Andrew Alston > Sent: Friday, October 1, 2021 4:21 PM To: James Guichard >; SPRING WG > Cc: spring-chairs@ietf.org Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/draft-fi= lsfilscheng-spring-srv6-srh-compression/ Sorry - but - I'm a little confused here. Because the way I look at this - the working group clearly stated that they= wished for a single behavior - and this - does not deliver that - it is tw= o separate behaviors. As such - I see this call for adoption - irrespectiv= e of the merits or lack thereof of the draft, as a clear defiance of the st= ated will of the working group. This is simply does not fit into the definition of bottom up approach in my= opinion - and if this is the way that the chairs wish to proceed - then th= e only way to do that and still fit within the bottom up approach is to fir= st ask this working group for its consensus to deviate from the single beha= cvior approach that the working group agreed to. As such - I must strongly and unequivocally object to this call for adopti= on Andrew From: spring > on b= ehalf of James Guichard > Date: Friday, 1 October 2021 at 17:05 To: SPRING WG > Cc: spring-chairs@ietf.org > Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardization work. That is part= of what this email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear g= uidelines as follows. By expressing support for adoption of this document y= ou are fully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_AS8PR03MB76228E83511258F424159D44EEAE9AS8PR03MB7622eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Jim,

 

Sorry – but – if the working group said = one solution – and you acknowledge that there is an issue as to if th= is represents one or multiple solutions – but proceed to call for ado= ption anyway – on the basis that this can be resolved post adoption – you create a very problematic solution if it is decided t= hese are two solutions.  Because you will have adopted something if de= fiance of an already reached consensus at this point.  The issue has t= o be resolved before hand.

 

For the record – I will support multiple solut= ions – as I always have – but – again – if there is= disagreement over if this represents one solution or multiple – and = the working group has said use ONE – then pure reasoning stands that = the issue of if this is one or multiple has to be resolved – and if we d= ecide it is two solutions – then a further working group consensus ca= ll needs to be made to determine if we are going to stick with the original= decision.

 

I would also like to hear the thoughts on multiple d= ata plane solutions in this regard from the working group chairs in 6man an= d the relevant AD’s.  I point to the spring charter which explic= itly states that work that modifies or extends a data plane has to be done with the agreement of the AD’s and worki= ng group chairs of the relevant area that holds the data plane (in this cas= e 6man), and so – can we get some feedback there before this is adopt= ed as to – if they view this as a single option – or multiple – and if they support this combination as we are= proposing.

 

Thanks

 

Andrew

 

 

From: James Guichard <james.n.guichard@fut= urewei.com>
Sent: Monday, October 4, 2021 6:10 PM
To: Andrew Alston <Andrew.Alston@liquidtelecom.com>; SPRING WG= <spring@ietf.org>
Cc: spring-chairs@ietf.org
Subject: RE: WG Adoption call for https://datatracker.ietf.org/doc/d= raft-filsfilscheng-spring-srv6-srh-compression/

 

Andrew,

 

As stated in our email of September 9th, the chairs = communicated that the working group reached rough (quite clear) consensus f= or standardizing one data plane solution to compress segment routing over I= Pv6. In addition to this there was an inclination toward using the CSID document as the basis for our work in= this area. The chairs recognized that there was however disagreement as to= whether this document, having multiple SRv6 EndPoint behaviors, could be c= onsidered consistent with the working group consensus for a single data plane solution. This issue quite clearly= needed to be addressed, and the chairs, recognizing that the working group= is keen to make progress in this area, had the option of trying to resolve= the issue prior to issuing an adoption call, or give the working group the opportunity to express their opinions = as part of a call for adoption.

 

Those who feel that we need to resolve the consisten= cy issue before adoption, as with those who think this is not a good basis = for the WG work, are free and expected to object to the WG adopting the doc= ument. That is distinct from objecting to the chairs issuing the adoption call.

 

In essence, the chairs have combined the question of= when to resolve consistency and the question of whether this document is a= good basis for the WG into one call.

 

Yours,

 

Jim, Bruno & Joel

 

 

From: Andrew Alston <Andrew.Alston@liquidtelecom.com>
Sent: Friday, October 1, 2021 4:21 PM
To: James Guichard <james.n.guichard@futurewei.com>; SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org=
Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/

 

Sorry – but – I’m a little confuse= d here.

 

Because the way I look at this – the working g= roup clearly stated that they wished for a single behavior – and this= – does not deliver that – it is two separate behaviors.  = As such – I see this call for adoption – irrespective of the me= rits or lack thereof of the draft, as a clear defiance of the stated will of th= e working group.

 

This is simply does not fit into the definition of b= ottom up approach in my opinion – and if this is the way that the cha= irs wish to proceed – then the only way to do that and still fit with= in the bottom up approach is to first ask this working group for its consensus to deviate from the single behacvior appro= ach that the working group agreed to.

 

As such – I must  strongly and unequivoca= lly object to this call for adoption

 

Andrew

 

From: spring <<= a href=3D"mailto:spring-bounces@ietf.org">= spring-bounces@ietf.org> on behalf of James Guichard <james.n.guichard@fu= turewei.com>
Date: Friday, 1 October 2021 at 17:05
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org <= spring-chairs@ietf.org>
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfi= lscheng-spring-srv6-srh-compression/

Dear WG:

 

The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

 

The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors.
  2. The document is a “living” document; it m= ay change as it goes through review and analysis by the SPRING working grou= p.
  3. All open discussion points raised on our mailing list= MUST be addressed BEFORE said document is allowed to progress from the wor= king group to publication. A list of these discussion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
  4. If this document is adopted by the working group, the= chairs specify as part of the adoption call that the following text descri= bing an open issue be added to the document in the above-described open issues section:
    • "Given th= at the working group has said that it wants to standardize one data plane s= olution, and given that the document contains multiple SRv6 EndPoint behavi= ors that some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

 

Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

--_000_AS8PR03MB76228E83511258F424159D44EEAE9AS8PR03MB7622eurp_-- From nobody Mon Oct 4 08:30:22 2021 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 0DF4B3A08DE; Mon, 4 Oct 2021 08:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 xjSBoFxUMZt6; Mon, 4 Oct 2021 08:30:13 -0700 (PDT) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-he1eur04on072b.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0d::72b]) (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 80F403A08FF; Mon, 4 Oct 2021 08:29:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q2cbOS9Y8xpCJVszt4pwnnbWZ2vyly3lYgAyd43AXK4ZHl/oc2Juy2bFZiHEp6BYmMFoEo2e0s+3vEoIU90CY51gXpkRMg3dRM6h8hQue0VO9pQ/wcxqJBawXikkcfhBl8HMBjPWiWTGXGBV8i7NDyttyPrUTSNTkWNMJByqZceM5MOjBMTd0mQCQDRUEm6UHKMjISfxfz/KtkocFSjhkQ+fQihrswUUZw8T7xM9upLWCE+Q9l3+rvfyz878Eyl8fJqTpFbet2D1ggvqiMVUxVEr175ha+7Zk4MEkszFrPR5gIgCIe3aqWBlym5i0aQJjZgTo+QxDkWYa4B6qnh0Kg== 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=v3BTIPTTsyulD62jRosfsTsQEPp2W9jXeufA1kfEwis=; b=XlTlvP0r9UlGeXHzfkIoI46/ttg2j6zmAjHy8H0wSJglMXhtYVPNglomJ7kyW5MxWxatGqnUOkwYHCdIGRFgyncpk/yCyq965ESfVNCw0H246D9R/ZKg3hF5N4pJmCWbcu/lHKz7Lm3JRV75pBPEjQ+xGmbzIOGbPNpNaGIoUlusl8i6AO+E7unRoTHewwJc1cj6LfsqrYGIZUprsmn1U2wvSwbgTzJ9YU2WF3HJT7MDnjLeSzb8YErisl78NBj3tHSDTPkU0BsxUDOtWlFTWz7XKSAG/6RMzw7OEJExDEtFotX1azUoRHqLBX+wmPW4LhHe5DAAR9oWj4erdi4RsQ== 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=v3BTIPTTsyulD62jRosfsTsQEPp2W9jXeufA1kfEwis=; b=P1rIsXwhnbNbIBIeNk8phBC7mFoG0EVhwtTpUkxwtmxJlvniwFwAEwUN52Ua/vIExXN7svKOM4mD3HibYC4DjBsmV07muVS2lD8f5SK1c4UqoH7qiwzi3g8ekpKO1I/n+J9r0n0TMewc3EWkOAruCfN4LQu4IG9/ndFK5Fw1qHc= Received: from DB7PR07MB4506.eurprd07.prod.outlook.com (2603:10a6:5:2c::17) by DB9PR07MB7883.eurprd07.prod.outlook.com (2603:10a6:10:2a5::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.9; Mon, 4 Oct 2021 15:29:30 +0000 Received: from DB7PR07MB4506.eurprd07.prod.outlook.com ([fe80::883a:de64:2582:238d]) by DB7PR07MB4506.eurprd07.prod.outlook.com ([fe80::883a:de64:2582:238d%7]) with mapi id 15.20.4587.016; Mon, 4 Oct 2021 15:29:30 +0000 From: "Henderickx, Wim (Nokia - BE/Antwerp)" To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQCZ3uH+ Date: Mon, 4 Oct 2021 15:29:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 519033c8-e844-4e4e-ef9c-08d9874bc23b x-ms-traffictypediagnostic: DB9PR07MB7883: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZTrbO8monbIGUCS9FLqr8dPamjQW0oGlxUomu1P2JZ+eh3N16bMnQgKgLyVh1gbyRuw+to+GoAUrpRP7kqQjL+3VKQDKO8//wgnm67zKCEr2Esgcbp2U7S4EgXHLYEOwv+WNHmhpEU4PLW1+YioDxVJx8SKPRkVwwSSbumjCNSKVHf/Fh8ATy3MdE1zBbqqyDGEtBZG5/0eG23c4OGfxwZ/297zTBYLErXlPzFYK2qe+xp50ROnblLcPdHYwI6rq0GICN6F+cybzNSrljhA+HuVtR3HEC8woOlNlaU6A6XBz5pKifr7BBsfITPRrxALceUHqlVQzoTIutNVpjhq2gnsHew7aVWtYCS0CKJQi66TF5Ar4aHEoBHAQQFdijuym7iKr58iWOixmSsnfAUmPKhbQmBFMlalj4wkFDgCyFMmy09BUsrXtfFa6riCs+tOA3s9YKawDHT73pRYwCmCsAyeZuBSuBqvY7YdqZ9d7ExJGQIS4Ox88Evm0Uuns4lcJCEHZJepF9qqt2JeXZ79AnZ951JE+qSdETZ0nZmEsFdvuMwJpsVl34dE4JSCQ5fsoStVoHmwBCShdZyrqQfPc9+ITigTQE4BF3U3v9cjo4ak2DxBxRXhaxhq5P2Ks5DBlUmfpm+q6peRK6dqMXHokVPhlKV14ZGccQ0kb2iQncWwPDl9nGc4t513t1FWJdNqYbCH+Bk4qdeVTtnsHY6jOTknjSA+a0u0y36LQ5uvMszEla6QgBwm+ZS1Mv5/1pBTzlRLTa/aFWiQyKrWk+m81gy2WiWSDXH8iWRxXjQj6zN8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR07MB4506.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(508600001)(122000001)(66446008)(55236004)(53546011)(66476007)(186003)(91956017)(76116006)(8936002)(64756008)(6506007)(7696005)(110136005)(316002)(33656002)(5660300002)(66946007)(71200400001)(52536014)(66556008)(26005)(8676002)(38100700002)(4326008)(966005)(166002)(83380400001)(9686003)(38070700005)(86362001)(2906002)(55016002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?/uwXdFLjp0GUiYQIdVzhWujHt8chEH1GOM//WI87BZo73qky6ijwG0/9?= =?Windows-1252?Q?avGOWSoPQtPQy6sQV6fcbH1kWc/FCLhV1GhF22DJVahkeiYbhdOamFF8?= =?Windows-1252?Q?c5v80a18FiBbPQCiDfVxzchLhHiymORG4R1/tWj6rUBvlDlyLV79M5TA?= =?Windows-1252?Q?+UUmSzX33DRkd5hEjV9smlhsFixYTMrl+jNUJrQ/8lw1q0+vH92Zbxkb?= =?Windows-1252?Q?KGmPKt6L3Biy5yBp5bEcCDtgyWmxN7C7ZqkejdHa0/O7m/aIqs4+9aE8?= =?Windows-1252?Q?B3Oqo+q/jTWaToVEGbzIytDnRVFFmaIBFUv1NMpxh7h3U05a8ffXuikM?= =?Windows-1252?Q?cL6mOe4LFYM7z8IrMiGFzXsaQQ/XXtyOkRe/XONJoCc/yMdhzUqn0ABb?= =?Windows-1252?Q?DJcWNLR9bHfUeTDRInlhwFYp2ciKi0nwUgTuvqywyv4w9PYei+Hl7JvN?= =?Windows-1252?Q?0KkktkdMu1PV+YuGa9T/kUp9XH8uHNaAS4ZdNpaImTvcOtTlcNfEIOin?= =?Windows-1252?Q?ooH5KWzcK5dRDJfzK50+ckbE/XQWLuw2pB94b7ZuWKzaNYP02iEUpWfL?= =?Windows-1252?Q?Qk+o+szVyrMcyM0EaLg9aZfAQu+QUoLmT/RWp+gcyHY8dbOZdGHCdUvv?= =?Windows-1252?Q?kHW89xlr3eb+eYVfqcLVCLaoHodgRmqdjMt56I3AML41CzVA4bQ1A237?= =?Windows-1252?Q?doGV79b0H1MacZ6AZakIZS8u7CmLYQgB2Jlu/ZKIQt0/mrnhBQFBMrOG?= =?Windows-1252?Q?T9N2ndTvsUm15oM9Sj69WkBAtMsxkLahqqkFjTfPgLceQk3488PG7GSr?= =?Windows-1252?Q?n+vBrTBb72NLIX4Uw4zchUlvUTDqYbEJQbdmNxGjKbtDfir1Lwu1/o49?= =?Windows-1252?Q?yZwhNPLlxJAmZ3FcWr4vTC1TbTpk6OEg1yLHyGwmjYTcR9z5pzlr8dHp?= =?Windows-1252?Q?oRzs4KYijkRz7uTQa2whtRRsCNXr8WKKDpWyX8llfPa5ylipp07Y4Adm?= =?Windows-1252?Q?e1pOt7yymIfXHKzLOCz33LeG4Tq3MvrZbwsPs+6MUBlG7HNxBBbXCnHW?= =?Windows-1252?Q?4sPALqF7/yneG6HCQQtWDNEgu/bH9IBMtF7xSxaJ5BaoK6n1d5P0LWFL?= =?Windows-1252?Q?+KOOkL39BfHAu6DKno4bEz3WOrdcrPQZ9wlHxHqX8xvmFJd8iu5dQ6eR?= =?Windows-1252?Q?coK/SOJbSZYla2ymcMdHWngg0HGBJmEGPS9vFxqIJVD2kGjwxmdE7H2p?= =?Windows-1252?Q?nCFpkNbHr78d/vvwFTmrV1+xMycq4RCf2JqFka0RLkvYn+mcGZCvkCNK?= =?Windows-1252?Q?fQgYEX9ZyspbS2rxzf4PPXPUOauDSc8YwydwtC0qDVmmk61tKykv1oj7?= =?Windows-1252?Q?e5Vy1DRGlf7MAinI5XQninRT23NQxrlq1qJO24rq/zBQJITUd4LR37Wf?= =?Windows-1252?Q?BURN0VUi6wM2UbkIiTXtVg=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DB7PR07MB4506AF1CC9CD5797B079A2BA83AE9DB7PR07MB4506eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB7PR07MB4506.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 519033c8-e844-4e4e-ef9c-08d9874bc23b X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2021 15:29:29.9621 (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: 8tj2mvfz0QxhBROUUr2QMmvBawrLqG06BfqS2KwP5XVD7T1fNz/EzzkmG3z6UtHS5OI0n4N746dJDQF5kdEFmxUNYPC2ruQyEv3BCSWktCA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR07MB7883 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 04 Oct 2021 15:30:20 -0000 --_000_DB7PR07MB4506AF1CC9CD5797B079A2BA83AE9DB7PR07MB4506eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I support the adoption for the following reasons: 1. If you look at the analysis, CSID has the best attributes for the com= pressed SRv6 solution in IETF. 2. Adopting a WG means we put in some guidance on the direction of IETF.= Even we still need to discuss more on the different behaviors in CSID; In = my view it can happen when we progress the CSID doc in the WG. 3. We have spent already substantial amount of time and effort on this = and it is time to move forward and have decisions. From: spring on behalf of James Guichard Date: Friday, 1 October 2021 at 16:05 To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a =93living=94 document; it may change as it goes thr= ough review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_DB7PR07MB4506AF1CC9CD5797B079A2BA83AE9DB7PR07MB4506eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I support the adoption for the following reasons:

 

  1. If you look= at the analysis, CSID has the best attributes for the compressed SRv6 solu= tion in IETF.
  2. Adopting a WG means we put in some guidance on the= direction of IETF. Even we still need to discuss more on the different beh= aviors in CSID; In my view it can happen when we progress the CSID doc in the WG.=
  3.  We have spent already substantial amount of time and effort on= this and it is time to move forward and have decisions.<= /li>

&nbs= p;

From: spring <spring-b= ounces@ietf.org> on behalf of James Guichard <james.n.guichard@future= wei.com>
Date: Friday, 1 October 2021 at 16:05
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

 

The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a sol= ution for SRv6 compression.

 

The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document = that has multiple SRv6 Endpoint behaviors.
  2. The document is a =93livi= ng=94 document; it may change as it goes through review and analysis by the= SPRING working group.
  3. All open discussion point= s raised on our mailing list MUST be addressed BEFORE said document is allo= wed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maint= ained by the document editor in conjunction with the chairs.
  4. If this document is adopt= ed by the working group, the chairs specify as part of the adoption call th= at the following text describing an open issue be added to the document in the above-described open issues section:
    • "Given that the working group has said that it wants to standar= dize one data plane solution, and given that the document contains multiple= SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution obj= ective.".

 

Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open d= iscussion points you would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

--_000_DB7PR07MB4506AF1CC9CD5797B079A2BA83AE9DB7PR07MB4506eurp_-- From nobody Mon Oct 4 08:48:33 2021 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 F08C03A0918; Mon, 4 Oct 2021 08:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3FVzwDe_hM7; Mon, 4 Oct 2021 08:48:25 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 80F933A0902; Mon, 4 Oct 2021 08:48:18 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id r18so66419057edv.12; Mon, 04 Oct 2021 08:48: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=2VGEm28/idvGP2pESLUcllqCpZiHYH0WldOVB4f9ud8=; b=TI/SBJ5KgMiSxKvrFoEhO5ALi20xq9HKYNiaX2R+ZOzq3sYgnyj4BTQ1RJd2K/2TtI 5cgGjkfDwat+QM2m+QII8KioSq46vmFZ2q4x4KMBdsTiqo62esbuYOyz/vwh/rczAuxX ynjXJW26tW1yQYzDeYTowmZJaO3d1jO67gQl/uNl70THpH1E/8NzQ0N0tOcFp5tWJxub J3/iV8TEzp6Y1TipxkDS3G46qbiwRq8458gfbf7CyRJkEcM7jb5X/yNOfd82Rt1Pi64J VCKsx+pwXePpY/XXEQgilH17sjeSQzFXOVrErAhnkXYwSA2zMQCnl08bbgNF87gIKBIU B+4g== 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=2VGEm28/idvGP2pESLUcllqCpZiHYH0WldOVB4f9ud8=; b=kb9QV2FR0IlKdK/L6WiXWb9baL1SP2BdYDfr4S9SFeUPLkc6ODP7OywbW/vP3yDOv0 B1CAu6yxYgqvGTMR3qqbCKB1PC16fw2HvaJdeK/ZhBCJKJIqhQ3sDVFY57noFvTo/xj9 GqWoOlPodwlZV+b2/x7WN7MA7EZofrXNyoGIMIw4YglP4GsBPvWjKg6AwBb+CYGQzRWz ia2Hmu2FjLFbda8IYuIgEdhVUeE/rSAQeqpIHvrphZtOBTtdzXcyAh7CFESjvzE7Z5dt lOD9VdRSxZR4DiYm/UkqZqIW8JOt0FKY8EM0LqKBuAfMpLqI0x+jr+BqLQjNu6IRtvH7 Zxyg== X-Gm-Message-State: AOAM531JZYhvU9cLwj1B76uLS4d0rLbkGK8Atlo5yQukieH1rsRGiYlq JnyyliX8H2WlAzh0zbgKdJAkBn0Z5+WrnBQ3i+BBdj10ZjI= X-Google-Smtp-Source: ABdhPJxmFMKbxRroB3VBIix2H5hN3DLl1TtLgactRPjYa7+WTV9OvL0ToLn1tygGIvLH6/86zaWm2QhpdlPqFLm8KpQ= X-Received: by 2002:a17:906:369a:: with SMTP id a26mr17576555ejc.539.1633362405892; Mon, 04 Oct 2021 08:46:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Mon, 4 Oct 2021 08:46:34 -0700 Message-ID: To: James Guichard Cc: Andrew Alston , SPRING WG , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000fe280905cd88d131" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 04 Oct 2021 15:48:30 -0000 --000000000000fe280905cd88d131 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Jim, thank you for the detailed explanation of the considerations the WG Chairs went through before starting the WG AP. As I understand it, the C-SID proposal integrates two mechanisms that were presented to the SPRING WG and thoroughly discussed as separate drafts. These are uSID and GSRv6. Looking at the list of the requirements and the analysis of CSID, I believe that it is safe to conclude that, as components of C-SID, uSID and GSRv6 are conformant to all the requirements. If that is the case, has anyone in the WG considered that the WG may adopt either uSID or SRv6 document as the basis of the standard compressing SRv6 SID? (Yes, I thought about that and I am kinda in favor of the idea). Regards, Greg On Mon, Oct 4, 2021 at 8:10 AM James Guichard < james.n.guichard@futurewei.com> wrote: > Andrew, > > > > As stated in our email of September 9th, the chairs communicated that the > working group reached rough (quite clear) consensus for standardizing one > data plane solution to compress segment routing over IPv6. In addition to > this there was an inclination toward using the CSID document as the basis > for our work in this area. The chairs recognized that there was however > disagreement as to whether this document, having multiple SRv6 EndPoint > behaviors, could be considered consistent with the working group consensu= s > for a single data plane solution. This issue quite clearly needed to be > addressed, and the chairs, recognizing that the working group is keen to > make progress in this area, had the option of trying to resolve the issue > prior to issuing an adoption call, or give the working group the > opportunity to express their opinions as part of a call for adoption. > > > > Those who feel that we need to resolve the consistency issue before > adoption, as with those who think this is not a good basis for the WG wor= k, > are free and expected to object to the WG adopting the document. That is > distinct from objecting to the chairs issuing the adoption call. > > > > In essence, the chairs have combined the question of when to resolve > consistency and the question of whether this document is a good basis for > the WG into one call. > > > > Yours, > > > > Jim, Bruno & Joel > > > > > > *From:* Andrew Alston > *Sent:* Friday, October 1, 2021 4:21 PM > *To:* James Guichard ; SPRING WG < > spring@ietf.org> > *Cc:* spring-chairs@ietf.org > *Subject:* Re: WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > > > Sorry =E2=80=93 but =E2=80=93 I=E2=80=99m a little confused here. > > > > Because the way I look at this =E2=80=93 the working group clearly stated= that > they wished for a single behavior =E2=80=93 and this =E2=80=93 does not d= eliver that =E2=80=93 it > is two separate behaviors. As such =E2=80=93 I see this call for adoptio= n =E2=80=93 > irrespective of the merits or lack thereof of the draft, as a clear > defiance of the stated will of the working group. > > > > This is simply does not fit into the definition of bottom up approach in > my opinion =E2=80=93 and if this is the way that the chairs wish to proce= ed =E2=80=93 then > the only way to do that and still fit within the bottom up approach is to > first ask this working group for its consensus to deviate from the single > behacvior approach that the working group agreed to. > > > > As such =E2=80=93 I must strongly and unequivocally object to this call = for > adoption > > > > Andrew > > > > *From: *spring on behalf of James Guichard < > james.n.guichard@futurewei.com> > *Date: *Friday, 1 October 2021 at 17:05 > *To: *SPRING WG > *Cc: *spring-chairs@ietf.org > *Subject: *[spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > Dear WG: > > > > The chairs would like to express their appreciation for all the responses > received to our emails with reference to how the working group wishes to > move forward with respect to a solution for SRv6 compression. > > > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > as the basis for its compression standardization work. That is part of wh= at > this email attempts to confirm. > > > > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging > that: > > > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change = as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the working > group to publication. A list of these discussion points will be docume= nted > in the WG document and maintained by the document editor in conjunctio= n > with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text describin= g an > open issue be added to the document in the above-described open issues > section: > - "Given that the working group has said that it wants to > standardize one data plane solution, and given that the document co= ntains > multiple SRv6 EndPoint behaviors that some WG members have stated a= re > multiple data plane solutions, the working group will address wheth= er this > is valid and coherent with its one data plane solution objective.". > > > > Please consider the above guidelines as you decide on whether to support > or not this WG adoption. Please express clearly your reasoning for > support/non-support as well as any open discussion points you would like > addressed should the document be adopted into the working group. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --000000000000fe280905cd88d131 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Jim,
thank you for the detailed explanation of the = considerations the WG Chairs went through before starting the WG AP. As I u= nderstand it, the C-SID proposal integrates two mechanisms that were presen= ted to the SPRING WG and thoroughly discussed as separate drafts. These are= uSID and GSRv6. Looking at the list of the requirements and the analysis o= f CSID, I believe that it is safe to conclude that, as components of C-SID,= uSID and GSRv6 are conformant to all the requirements. If that is the case= , has anyone in the WG considered that the WG may adopt either uSID or SRv6= document as the basis of the standard compressing SRv6 SID? (Yes, I though= t about that and I am kinda in favor of the idea).

Regards,
Greg

On Mon, Oct 4, 2021 at 8:10 AM James Guichard= <james.n.guichard@fut= urewei.com> wrote:

Andrew,

=C2=A0

As stated in our email of September 9th, the chairs = communicated that the working group reached rough (quite clear) consensus f= or standardizing one data plane solution to compress segment routing over I= Pv6. In addition to this there was an inclination toward using the CSID document as the basis for our work in= this area. The chairs recognized that there was however disagreement as to= whether this document, having multiple SRv6 EndPoint behaviors, could be c= onsidered consistent with the working group consensus for a single data plane solution. This issue quite clearly= needed to be addressed, and the chairs, recognizing that the working group= is keen to make progress in this area, had the option of trying to resolve= the issue prior to issuing an adoption call, or give the working group the opportunity to express their opinions = as part of a call for adoption.

=C2=A0

Those who feel that we need to resolve the consisten= cy issue before adoption, as with those who think this is not a good basis = for the WG work, are free and expected to object to the WG adopting the doc= ument. That is distinct from objecting to the chairs issuing the adoption call.

=C2=A0

In essence, the chairs have combined the question of= when to resolve consistency and the question of whether this document is a= good basis for the WG into one call.

=C2=A0

Yours,

=C2=A0

Jim, Bruno & Joel

=C2=A0

=C2=A0

From: Andrew Alston <Andrew.Alston@liquidtelecom= .com>
Sent: Friday, October 1, 2021 4:21 PM
To: James Guichard <james.n.guichard@futurewei.com>; SPRING WG &l= t;spring@ietf.org&= gt;
Cc: spri= ng-chairs@ietf.org
Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-com= pression/

=C2=A0

Sorry =E2=80=93 but =E2=80=93 I=E2=80=99m a little c= onfused here.

=C2=A0

Because the way I look at this =E2=80=93 the working= group clearly stated that they wished for a single behavior =E2=80=93 and = this =E2=80=93 does not deliver that =E2=80=93 it is two separate behaviors= .=C2=A0 As such =E2=80=93 I see this call for adoption =E2=80=93 irrespecti= ve of the merits or lack thereof of the draft, as a clear defiance of the stated will of th= e working group.

=C2=A0

This is simply does not fit into the definition of b= ottom up approach in my opinion =E2=80=93 and if this is the way that the c= hairs wish to proceed =E2=80=93 then the only way to do that and still fit = within the bottom up approach is to first ask this working group for its consensus to deviate from the single behacvior appro= ach that the working group agreed to.

=C2=A0

As such =E2=80=93 I must =C2=A0strongly and unequivo= cally object to this call for adoption

=C2=A0

Andrew

=C2=A0

From: spring <spring-bounces@ietf.org> on behalf of James Guichard <james.n.guichard@futurewei.com>
Date: Friday, 1 October 2021 at 17:05
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org <spring-chair= s@ietf.org>
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

=C2=A0

The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

=C2=A0

The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

=C2=A0

Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

=C2=A0

  1. The SPRING working group is adopting a document that has multiple = SRv6 Endpoint behaviors.
  2. The document is a =E2=80=9Cliving=E2=80=9D docu= ment; it may change as it goes through review and analysis by the SPRING wo= rking group.
  3. All open discussion points raised on our mailin= g list MUST be addressed BEFORE said document is allowed to progress from t= he working group to publication. A list of these discussion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
  4. If this document is adopted by the working grou= p, the chairs specify as part of the adoption call that the following text = describing an open issue be added to the document in the above-described open issues section:
    • "Given that the = working group has said that it wants to standardize one data plane solution= , and given that the document contains multiple SRv6 EndPoint behaviors tha= t some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

=C2=A0

Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

=C2=A0

Thanks!

=C2=A0

Jim, Bruno & Joel

=C2=A0

=C2=A0

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--000000000000fe280905cd88d131-- From nobody Mon Oct 4 08:48:44 2021 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 7CA2E3A0938 for ; Mon, 4 Oct 2021 08:48:34 -0700 (PDT) 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, 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, 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 fTbph-s9kpF0 for ; Mon, 4 Oct 2021 08:48:30 -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 C94103A090D for ; Mon, 4 Oct 2021 08:48:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquid.tech; s=mimecast20210406; t=1633362502; 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=Ld37viX8RQ2CistDBJcT1FWNgJ6oF82y88+sWEjTP6k=; b=a9tbXbc2jQivSpXfJuGGp4JjAylLJiqp527TOBgyfPU0mt9s6Ou6SpqSOGRB+6FVzjXuT+ J4RmDHdM7rDpzhhltO21qsq2ReTe0VAZ13svMd6T9u6LU02z5CdED5r8WdF5rUbQJgSDZh hNnuvE+uVPh2/xIiJ84Ew7o6Dsfg6ps= Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-db3eur04lp2054.outbound.protection.outlook.com [104.47.12.54]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-209-Kz5NoPL2M6CZC-XUOcvQrQ-1; Mon, 04 Oct 2021 16:48:21 +0100 X-MC-Unique: Kz5NoPL2M6CZC-XUOcvQrQ-1 Received: from DB7PR03MB4059.eurprd03.prod.outlook.com (2603:10a6:5:33::13) by DB6PR0301MB2136.eurprd03.prod.outlook.com (2603:10a6:4:49::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.14; Mon, 4 Oct 2021 15:48:19 +0000 Received: from DB7PR03MB4059.eurprd03.prod.outlook.com ([fe80::f063:14c2:ad5:1ed9]) by DB7PR03MB4059.eurprd03.prod.outlook.com ([fe80::f063:14c2:ad5:1ed9%5]) with mapi id 15.20.4544.026; Mon, 4 Oct 2021 15:48:19 +0000 From: Daniam Henriques To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQCa1+Fy Date: Mon, 4 Oct 2021 15:48:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 2907f6a4-0c96-2731-456c-671cc331d5cb x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8ef9f951-982e-4e4b-09e9-08d9874e635c x-ms-traffictypediagnostic: DB6PR0301MB2136: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: QSLAi6Yo+R+qmIa3byc4EH0/lPh2nY2vZuBiVacOgm9HI0dadkZGfzJ21dbvyozzTiNpb0aGl/IpNGQ+jxZgIPg3dY7xC7CQ2PmEZJZtN0HuIh7K8ZGV0UObzx0gnkw5gSq8ysF2HZ9Kl8lEq79ihNioofGPPhjgXlINRDts98E1rpqBbyApyokMz9Sy824tSISr98TepQSB2bjJqTQWGyDwEhUxoj5Zx1jt7tQY/GDZKYDh5fcKvB37wX6NxEsYZfCgn9FfDigQD6nG6Y8kMqMIoYMC9J5pquPbSmJIcusGPudeV0mZ62w5gVhT64AIN27ZAjSWfWs6svQ61yYpavl35nq++TmmebNKRYcip+mRC3CRgFzo1Fqs/NnGkX1JJucxd24Pn+qyydZP9T2e4yA6o2oyuVz/AjpX1A7Lbe/7zpLhwBQjA/RsNj0NvNRKVl5lYbrIAlkouqWPKEMsHxedSy1j3I5vcfc8quKD/5gluzp0XxyDYtQ7V4WYetMWwqs2qYzuLRDYMshIEsF5cCC7c+sfbmiO/beDeHED6IQtX1MKXSEiMbKr2Lu/lbCn1KX7T75rqIuCJnskGnqFR992B0EvB+OWUXAFM5FvY6D16Q8pPiWPBezCBVnocnQV/kvUc0vtx9RjI8rFbF+b78jxydXuTkJWhAamRcTCIJ6LuxSMRsEkU36gCaQmAlrv2DPhlEMnAucW7yyDRx0Kn7ikOpnDcW1jhVtUhKO/0StTriEcKowaul+NoGKgNxjTSlJyGhjG++su1xN0UNJa35lSa5UfV1vUSwD/tyh61KM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR03MB4059.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(38070700005)(7696005)(52536014)(66446008)(8676002)(316002)(44832011)(66556008)(9686003)(76116006)(19627405001)(91956017)(66476007)(19627235002)(66946007)(33656002)(8936002)(64756008)(5660300002)(110136005)(55016002)(186003)(4326008)(86362001)(2906002)(83380400001)(6506007)(508600001)(53546011)(55236004)(38100700002)(71200400001)(26005)(122000001)(166002)(966005); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?c4cjclpo1JrrU9GnJUtyNn/AmKaaIBi8PR18sKt48zJSilVOaVtOKZZz?= =?Windows-1252?Q?UIk6NBrQoxv0M59jhdz6WRPvIhMsEYwzJen3dlyJCASoVQcXUbbpRhhj?= =?Windows-1252?Q?iosKFzTLKM97Sz4dpmcUu/NOwp+ReDCz+R9Priv+s4WD37Z8nuuODOI9?= =?Windows-1252?Q?9JtALbrMArLk4tK2sQiw6NOjgSvKiW3LhWM1LpBaqOEFC8As5Oskvp7s?= =?Windows-1252?Q?2a8ji3JBKqeUlBmQJtSUDQzwNB/n58sdHb+fGmm8Y5PBAtkK2ajnKrNF?= =?Windows-1252?Q?r5wM2Y1hBN7lp45aYQMfrKBgfNzF30glUmtibnV467HJzwTYojweXpY5?= =?Windows-1252?Q?QgnzO9PbniViMsorU7a/yp2V7CizP8RG6fLlgB+GiPg4vQxLObjTdvI5?= =?Windows-1252?Q?JG596fbNSsyWaqficgxgLbSe2uLzpIlAPjeHBuVkrdbRXbV/8c8Pws4E?= =?Windows-1252?Q?lZCXPaVKHFGknIl0pecL7oETy/PKpmcAAduB3H/WRJOAeY9d4kWI8CKZ?= =?Windows-1252?Q?f21Topbvuno5lNz2ltthw6efKBtFCVwTQ3lDxSGpEhLNug3fMxKeyWOP?= =?Windows-1252?Q?XGFEPKIyMXgIWld0MWcy82fx++SRk1KE4i18R7rR/8uZiTATtf3FvkYg?= =?Windows-1252?Q?OrhcOmYydkPg/vXtFza6PB5rqEeb73Y4w5+O1WP2Ew1dXS37hQNUY0/M?= =?Windows-1252?Q?W7c9QwNOlHNKSXY/3+ZYzudaRQH+NS0GMfpEDrxGMdIYU7XXSGREBcJ2?= =?Windows-1252?Q?kkXKD4oxsKex2o8mR57WlgOJSKJnBHE5gHqG3ZnT4QKjd/NTgZIrZp4T?= =?Windows-1252?Q?PiaLzCs4Kjkt7g8OErR3AGRntxsUJQAfrDtbrpFU4424yjF/8Dh6mQZj?= =?Windows-1252?Q?HsngSqeEPClC6JOIB8M3FnNPM2nyDtcJMEyqyFeiw9QGnKzGbEfClWPM?= =?Windows-1252?Q?d0qt6+c3RW6OXtDWx6T8y5mlTJShKAY4AX0hMSMidRjUt5ZGzUVXgDOi?= =?Windows-1252?Q?ifKmoBobtd4Xne3ZwU+4VEMKde5kggHOFyavwlpJv9Mj0R8BXUragUzS?= =?Windows-1252?Q?kyq9knTjMMzA+rm2ohAo/sBZ1Hk/TYxgXpzU2BQBgsce27rSUDmZJRKS?= =?Windows-1252?Q?cInt7ghwmrwpQ9YMDM4vSE1BsmMf7/Y0/bl3KH5PNb2epSI/82RoNStR?= =?Windows-1252?Q?N1Ok6el32f+f7u4MjOmjpp2gGFGxcU+jijJseUsdtFStqP2mokjFqDMM?= =?Windows-1252?Q?g2FlXmwlQQNuy/gA6aJxkpmckeeK2mYd0qACikO9pvZY6HJtwplCTW6A?= =?Windows-1252?Q?zlfD9++FTJMZH+f2hTbUcEKZ2ETvNPSZzlvTuILd0rHgRlV5OPkEoIVO?= =?Windows-1252?Q?TVfaeGugZ07IroCMWSibMZVX1d1DvzEF9U/waeE4sVfAHx8xTihr5vhc?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquid.tech X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB7PR03MB4059.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8ef9f951-982e-4e4b-09e9-08d9874e635c X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2021 15:48:19.0222 (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: VESrZ/H0NNc47ORREN2Z0NTMkkvfhD6sBcKcHnkWKuOhf7dYoxqMr5iPd2Q2jnwqMjpHDiYi91N4cilv/bJFTzY2pNTBX35UAMze1rXllv9jF0ykm0Rc7DHnXsAowZEo X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0301MB2136 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=daniam.henriques@liquid.tech X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquid.tech Content-Language: en-GB Content-Type: multipart/alternative; boundary="_000_DB7PR03MB40599EC8ED4ABE66787380E188AE9DB7PR03MB4059eurp_" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 04 Oct 2021 15:48:36 -0000 --_000_DB7PR03MB40599EC8ED4ABE66787380E188AE9DB7PR03MB4059eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi All My foremost concern regarding the adoption to this draft relates to timing = and progressing the call for adoption while there are several unaddressed a= nd serious concerns that have been raised. While the WG recently reached consensus around the adoption of one and only= one data plane solution and we are already discussing solutions which requ= ire multiple data plane solutions, perhaps we need to consider that, while = not ideal for some, having multiple data plane options provides us the best= solution going forward. In this regard I believe it is important to note t= hat all the compression mechanisms that have been proposed thus far make ce= rtain design decisions and are ultimately a compromise of flexibility, feat= ure support, simplicity, etc. Is limiting ourselves to one and only one dat= a-plane option the best for everyone going forward? Do we perhaps need to r= evisit earlier discussions around one/more data plane options before procee= ding further? I also believe Ron's point regarding RFC 4291 compliance is something that = should be investigated by this WG/6MAN before adoption and not something wh= ich should only be considered later. Regards, Daniam ________________________________ From: spring on behalf of James Guichard Sent: 01 October 2021 16:04 To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as t= he basis for its compression standardization work. That is part of what thi= s email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guideline= s as follows. By expressing support for adoption of this document you are f= ully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a =93living=94 document; it may change as it goes thr= ough review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel This email disclaimer applies to the original email, all attachments and an= y subsequent emails sent by Liquid Telecom. This email contains valuable bu= siness information that is privileged, confidential and/or otherwise protec= ted from disclosure, intended only for the named person or entity to which = it is addressed. If you are not the intended recipient of this email and yo= u received this e-mail in error, any review, use, dissemination, distributi= on, printing or copying of this e-mail is strictly prohibited and may be un= lawful and/or an infringement of copyright. Please notify us immediately of= the error and permanently delete the email from your system, retaining no = copies in any media. No employee or agent is authorized to conclude any bin= ding agreement on behalf of Liquid Telecom with another party or give any w= arranty by email without the express written confirmation by an authorized = representative or a director of Liquid Telecom. Nothing in this email shall= be construed as a legally binding agreement or warranty or an offer to con= tract. Liquid Telecom will not be responsible for any damages suffered by t= he recipient as a result of the recipient not taking cognizance of this pri= nciple. Liquid Telecom accepts no liability of whatever nature for any loss= , liability, damage or expense resulting directly or indirectly from the ac= cess of any files which are attached to this message. Any email addressed t= o Liquid Telecom shall only be deemed to have been received once receipt is= confirmed by Liquid Telecom orally or in writing. An automated acknowledgm= ent of receipt will not suffice as proof of receipt by the Liquid Telecom. = This email disclaimer shall be governed by the laws of South Africa. --_000_DB7PR03MB40599EC8ED4ABE66787380E188AE9DB7PR03MB4059eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
Hi All

My foremost concern regarding the adoption to this draft relates to timing = and progressing the call for adoption while there are several unaddressed a= nd serious concerns that have been raised.

While the WG recently reached consensus around t= he adoption of one and only one data plane solution and we are already disc= ussing solutions which require multiple data plane solutions, perhaps we ne= ed to consider that, while not ideal for some, having multiple data plane options provides us the best solution= going forward. In this regard I believe it is important to note that all t= he compression mechanisms that have been proposed thus far make certain des= ign decisions and are ultimately a compromise of flexibility, feature support, simplicity, etc. Is limiting= ourselves to one and only one data-plane option the best for everyone goin= g forward? Do we perhaps need to revisit earlier discussions around one/mor= e data plane options before proceeding further?

I also believe Ron's point regarding RFC 4291 compliance is something that = should be investigated by this WG/6MAN before adoption and not something wh= ich should only be considered later.

Regards,
Daniam
From: spring <spring-bou= nces@ietf.org> on behalf of James Guichard <james.n.guichard@futurewe= i.com>
Sent: 01 October 2021 16:04
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/
 

Dear WG:

 

The chairs would like to express their appreciatio= n for all the responses received to our emails with reference to how the wo= rking group wishes to move forward with respect to a solution for SRv6 comp= ression.

 

The apparent inclination of the working group is t= o use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs would like to issu= e a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING worki= ng group is adopting a document that has multiple SRv6 Endpoint behaviors.
  2. The documen= t is a =93living=94 document; it may change as it goes through review and a= nalysis by the SPRING working group.
  3. All open di= scussion points raised on our mailing list MUST be addressed BEFORE said do= cument is allowed to progress from the working group to publication. A list= of these discussion points will be documented in the WG document and maintained by the document editor in conjunction wi= th the chairs.
  4. If this doc= ument is adopted by the working group, the chairs specify as part of the ad= option call that the following text describing an open issue be added to th= e document in the above-described open issues section:
    • "Given that the working group = has said that it wants to standardize one data plane solution, and given th= at the document contains multiple SRv6 EndPoint behaviors that some WG memb= ers have stated are multiple data plane solutions, the working group will address whether this is valid and coherent with its= one data plane solution objective.".

 

Please consider the above guidelines as you decide= on whether to support or not this WG adoption. Please express clearly your= reasoning for support/non-support as well as any open discussion points yo= u would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

Thi= s email disclaimer applies to the original email, all attachments and any s= ubsequent emails sent by Liquid Telecom. This email contains valuable busin= ess information that is privileged, confidential and/or otherwise protected from disclosure, intended only for the named pe= rson or entity to which it is addressed. If you are not the intended recipi= ent of this email and you received this e-mail in error, any review, use, d= issemination, distribution, printing or copying of this e-mail is strictly prohibited and may be unlawful and/o= r an infringement of copyright. Please notify us immediately of the error a= nd permanently delete the email from your system, retaining no copies in an= y media. No employee or agent is authorized to conclude any binding agreement on behalf of Liquid Telecom w= ith another party or give any warranty by email without the express written= confirmation by an authorized representative or a director of Liquid Telec= om. Nothing in this email shall be construed as a legally binding agreement or warranty or an offer to con= tract. Liquid Telecom will not be responsible for any damages suffered by t= he recipient as a result of the recipient not taking cognizance of this pri= nciple. Liquid Telecom accepts no liability of whatever nature for any loss, liability, damage or expense re= sulting directly or indirectly from the access of any files which are attac= hed to this message. Any email addressed to Liquid Telecom shall only be de= emed to have been received once receipt is confirmed by Liquid Telecom orally or in writing. An automated = acknowledgment of receipt will not suffice as proof of receipt by the Liqui= d Telecom. This email disclaimer shall be governed by the laws of South Afr= ica. --_000_DB7PR03MB40599EC8ED4ABE66787380E188AE9DB7PR03MB4059eurp_-- From nobody Mon Oct 4 08:50:53 2021 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 B6C403A091E; Mon, 4 Oct 2021 08:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 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, 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=CiTManlg; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QXmRba8l 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 La1dJCU_SfZF; Mon, 4 Oct 2021 08:50:09 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F8303A0972; Mon, 4 Oct 2021 08:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18857; q=dns/txt; s=iport; t=1633362609; x=1634572209; h=from:to:cc:subject:date:message-id:mime-version; bh=IUCFimV2qsKej1rGJ4I2SjlADOWu81oOeu1R/5mbYbk=; b=CiTManlgjVw1BvkZj+/ATsp8x0sYlKolf7ufiYICA86Kpklr6IpstX/w rv6NDE7SiAT0grB3b0zC6TanJgqrw4SbFsvr8eXiQomKmy0t+LHfISdT5 +1ZAudLm/ahCpHzzq9P+9dnbFb+BUjjrqIU7DRV084nOSqP2lHC2cOOMl s=; IronPort-PHdr: =?us-ascii?q?A9a23=3AqQ93uRJmoEBIGdVGedmcuYMyDhhOgF28FgAI9?= =?us-ascii?q?oc9hq1Dc+Ko+JGxdEDc5PA4iljPUM2b7v9fkOPZvujmXnBI+peOtn0OMfkuH?= =?us-ascii?q?x8IgMkbhUosVciCD0CoIuP2cjY3A8lDElRi+iLzPU1cAs2rYVrUrzW75iITH?= =?us-ascii?q?ROqMw1zK6z1F4fegt7x2fq1/sjYYh5Dg3y2ZrYhRCg=3D?= IronPort-Data: =?us-ascii?q?A9a23=3AhtxPPaJiPkv08mG0FE+RGpclxSXFcZb7ZxGr2?= =?us-ascii?q?PjKsXjdYENS1zAOyDZNWG+HOq7ZZGqmL98lbN7j9h4P75DSx9NrHAYd+CA2R?= =?us-ascii?q?RqmiyZq6fd1j6vI0qj7wvTrFCqL1O1DLImdRCwIZiWE/E70auC99SMUOZygH?= =?us-ascii?q?9IQNsaVYkideic8IMsRoUoLd98R2uaEs/Dga+++kYuaT/nkBbOQ82Uc3lT4R?= =?us-ascii?q?E60gEgHUPza4Fv0t7GlDBxBlAe2e3I9VPrzKUwtRkYUTLW4HsbiLwrC5Kuy8?= =?us-ascii?q?mWc9BA3B5b8yvDwc1YBRfjZOg3mZnh+Avf5xEMd4H1plP9napLwam8P49mNt?= =?us-ascii?q?8J4zNRlvp2rQgBvNarJ8AgYe0kEQnklZv0ap9crJlD666R/1XbuaGP2wvNhS?= =?us-ascii?q?Uo2NIwC4c52DH1As/sCJ1gldQiZhuS56LO2Vucqgd4sROHpNYYSoTdmiz7ED?= =?us-ascii?q?P0mSIrPa6vX+cJC0Sg9h4ZFGvO2WiazQVKDdzzaaBFJf1wQEp97xb/ujXjke?= =?us-ascii?q?Doeo1WQzZfbKlP7lGRZuIUB+vKKEjBSefhoow=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3Aot3PMaAs2wLU4PblHegBsceALOsnbusQ8z?= =?us-ascii?q?AXPh9KKCC9I/b3qynxppsmPEfP+UsssHFJo6HmBEDyewKhyXcV2/heAV7GZm?= =?us-ascii?q?nbUQSTXfpfBOfZsljd8k7Fh69gPMVbAtJD4bTLZDAQ56uXkWrIcerIq+P3lp?= =?us-ascii?q?xA8N2ut0uFOjsaEp2IgT0JbjqzIwlTfk1rFJA5HJ2T6o5svDy7Y0kaacy9Gz?= =?us-ascii?q?0sQ/XDj8ejruOnXTc2QzocrCWehzKh77D3VzKC2A0Fbj9JybA+tUDYjg3C4L?= =?us-ascii?q?m5uf3T8G6e64aT1eUVpDLS8KoGOCW+sLlTFtwqsHfvWG1VYczGgNnympD31L?= =?us-ascii?q?9lqqiVn/5qBbUN15qYRBDKnfKq4Xi67N7rgEWSlGNxRhDY0JbErXsBerp8bc?= =?us-ascii?q?gySGqp12Mw+N57y65FxGSfqt5eCg7Bhj3045zSWwhtjVfcmwturQc/tQ0VbW?= =?us-ascii?q?IlUs4akWXfxjIjLL4QWCbhrIw3GuhnC8/RoP5QbFOBdnjc+m1i2salUHg/Fg?= =?us-ascii?q?qPBhFqgL3b7xFG2HRii0cIzs0WmXkNsJo7Vplf/uzBdqBljqtHQMMaZb90QO?= =?us-ascii?q?0BXcy0AGrQRg+kChPfHX33UKUcf37doZ/+57s4oOmsZZwT1ZM33I/MVVtJ3F?= =?us-ascii?q?RCM34Gyff+laGj1yq9NFlVcQ6duP221qIJzIEUHoCbQhFrYGpe5vednw=3D?= =?us-ascii?q?=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A5CQC7IVth/5JdJa1aHQEBAQEJARI?= =?us-ascii?q?BBQUBghmBITAjLgd3WjcxhEeDSAOFOYgIA5VmhQaBQoERA1QLAQEBDQEBNwo?= =?us-ascii?q?EAQGEfRmCKgIlOBMBAgQBAQESAQEFAQEBAgEGBIERE4U7CCUNhkIBAgEDEgs?= =?us-ascii?q?GChMBASwLAREBCBEDAQIkBwIEMB0KBAENBRsHgk8BgX5XAy8BDqUuAYE6Aoo?= =?us-ascii?q?feoExgQGCCAEBBgQEgUpBgn8YgjUDBoE6gwCEEwEBhxccgUlEgRUnDBCCZz6?= =?us-ascii?q?CYwIDgSMFARIBQQ2CazeCDCKKAi9CZAQbOCACWRaBAioRKZUQiHONS5IqCoM?= =?us-ascii?q?wgTKJEpQgBSyDZ4tqlzyHE48SjEmYcgIEAgQFAg4BAQaBeCRpcHAVOyoBgj5?= =?us-ascii?q?RGQ+DPopiDBYVGYMihRSFSnQCNgIGAQoBAQMJlXEBAQ?= X-IronPort-AV: E=Sophos;i="5.85,346,1624320000"; d="scan'208,217";a="849033847" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Oct 2021 15:50:05 +0000 Received: from mail.cisco.com (xbe-rcd-001.cisco.com [173.37.102.16]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 194Fo3RW003440 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 4 Oct 2021 15:50:05 GMT Received: from xfe-aln-003.cisco.com (173.37.135.123) by xbe-rcd-001.cisco.com (173.37.102.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 4 Oct 2021 10:50:03 -0500 Received: from xfe-aln-001.cisco.com (173.37.135.121) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 4 Oct 2021 10:50:02 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) 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.792.15 via Frontend Transport; Mon, 4 Oct 2021 10:50:02 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AoMI8E/k+/60GEOPrRdq1bbupGcbkDqqk3RpmRlX8WNDPeyzK/80XKPdvoPMsSlFQ3QvxAHYyu2+9tnitn9axwGVO6e0A7SRnM2fzKXYgvoNDKYSceOX/LVVun2eSdQW9Q3aReq5Nv9X4Fs2YyZLL5MX7THuNtYz5SUKHzRP6mFqrBOD9fn/x263j+HR8WTDQP4ukYzE5ykaCHFAblyHDtxXoNQsc5KEvb2Tjw1ohsEbbpqV5GnhlwpgupvkTN0mVcemyVK3+SD5E9bC5q2inQw9ppK6RtBmGJsa9ibnR0qIj8zIFSKXfbbCRhda6r4sm1N87Hg2hdirozS0FMJpKg== 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=IUCFimV2qsKej1rGJ4I2SjlADOWu81oOeu1R/5mbYbk=; b=Hj4iHV/EgUY6bpCkSpoThZXAEpC95JP8DzWvqVb8VsQk70qpZ9bFuFbsen/IU+df0IFs64T7ombPtKYks/c51Z0oblfwl5J/kKmyKP982VqOxyMbHfjBl/D/+u2XrFHKxbYLxA0QMjKo9YfdQdDJmBRTZFt1w/bsdQJJv8/K5TBRRYwJtq4YuPkP50huFb2E3Uv99jnT6TWyT+y4fVz+7c6/S+o/qMZpRwUCURXBRq8p69TYvqSO5AZKS9PAqldhFQqUdZ+Ik4LUNCf+UpEkHpVAtGJMOnsUV2zGsuFaGfb9vZdMiDMm/g2D+WNttofE6soL7qxAWLtsNMENyv9XmQ== 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=IUCFimV2qsKej1rGJ4I2SjlADOWu81oOeu1R/5mbYbk=; b=QXmRba8l8AuqsReTFn+xoxCDW6gSvsXH5dvVQsf5EuDuUuLpo23i5A3WViJqqUVoP1EtlYBf7IuX8flcRUcY4QAjesqA65u5cvj5gSCtzggYAEoTHCrWUaZrny5oFo9rgfFp39p7+k1MQxtF5F5JgJ1K9QVWbLx5ys1Yh8NTKM4= Received: from DM6PR11MB4692.namprd11.prod.outlook.com (2603:10b6:5:2aa::11) by DM6PR11MB2809.namprd11.prod.outlook.com (2603:10b6:5:c5::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.14; Mon, 4 Oct 2021 15:50:01 +0000 Received: from DM6PR11MB4692.namprd11.prod.outlook.com ([fe80::b41a:1b9a:17dc:4b7f]) by DM6PR11MB4692.namprd11.prod.outlook.com ([fe80::b41a:1b9a:17dc:4b7f%7]) with mapi id 15.20.4566.022; Mon, 4 Oct 2021 15:50:01 +0000 From: "Zafar Ali (zali)" To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" , "Zafar Ali (zali)" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: AQHXuTd9ijIiTOMLDkGipCqWUcImCA== Date: Mon, 4 Oct 2021 15:50:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.53.21091200 authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 27104bf3-0643-40a2-883b-08d9874ea05e x-ms-traffictypediagnostic: DM6PR11MB2809: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 97qOPx+3zRPWk2u7yBpKUhxjCy/rRFj/l2YVb9EA1VI56rwQ1iN+5Bk9nfNk99o+u6acmi663itmhxnQSrWKkOnPMCoe/117+9HJkkhHHTfN7u2F7+qYXXM5fkgbV9lIFdaDEd+y7gTWo0i3c8ycW7EYCYlPMkwjVdnMq0jvMBISrTsw7NM4Jalp4BXLrkU/Akm9tjEZhSYAR5DleVifDl3BiJvAucdlSPKgYI6rYDPdp0R169Aa5hDfJwTR3p0DaE83lZr9aV4mZn+UTJ+5DCNYiB/5W8r8U1Hw/+1IYuudTyOBsaXg1g5bH26X9m1rAKZeJ5xdnQpGt9gxrqAvEz+7yX/iTDewqRcwLVHmzaEFpUQtxqxN/9oJnqmtgzsuJtF7E0tKSMyZFcXChqIP56+ZUm2o9Rj7vtJUlCpNnQXzUowpVqeEIuBzjWxIxvzdPyXuxXmphvHqdkegYc5JjBs9XMa7td+n80Jq7Hk8WHlWheZOyCdPBvwoL1L33Or4REZSsqntpITDfHyY/O+c+S6lQ2MKG+nEMuFgTq3FO5kJcq/zCGCR7g7r7SaOzfev1wXKpbBoP4oq3bGvPzxgvZ64EhFDDxi0RM7GFESaWwAc/O0ap+2FmU7OfBqbvOZRrfS8HXaJ+eKaH0xFDBy/+W72KVi+ow3qEI+tj49EIXVtRfRaaurULkARayYD3NL4FpUA2INl3hMMEDRch3idjCQUbuZVfDhBf5WPAza8FiLSuWRhKt3ZixmigZcpVKfO7I6kNea+L0BD6msmDNv7KDhykGP0Pkybkg6c+wupnVTNr8sgP9DnsIku2/uNOtkP x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB4692.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(53546011)(66556008)(83380400001)(64756008)(66476007)(66446008)(76116006)(8936002)(2616005)(5660300002)(86362001)(33656002)(508600001)(36756003)(8676002)(38070700005)(122000001)(38100700002)(66946007)(6486002)(6506007)(110136005)(91956017)(2906002)(166002)(966005)(54906003)(26005)(4326008)(107886003)(71200400001)(6512007)(186003)(316002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Z256TDJGWEU3c0VXeUJLK3VnUUNGTFBHWG5CaWxBT0lvcGVhL0doUFMxS2xU?= =?utf-8?B?SkxPeEJOWkdUbkFweUVmYUYrUS9jc2gzM09GazJ4L0xjd3NIdVA2K3dxRFg5?= =?utf-8?B?bzF6bUlNcExvK2FLQ3QzSXFTY2ZjSlo1dXhQZGtub2hoWGxjOGNjT0N6aEZz?= =?utf-8?B?TjlmNnFWU2tPcWF1cThvS0g3TXV0N3NoTHJUWmtjLzRGbFFNaXNzd2QvQmVR?= =?utf-8?B?M0dPRW5SYWlJRWNPZTV2c3RHM0drTGtLR1RncGh1ajIvenBuS2t2cUxKTkkr?= =?utf-8?B?UWFleTE1N2FLSnhlUm9FNjRZWndZdk95aEt1NDZSNEVVU3RPZ0Jsc1o4R2pI?= =?utf-8?B?dVpGbjRyN2YranZEdWFRTFJTbWVZcUtzejhTSlZ4eEVqcGZyNW9reDhxakUz?= =?utf-8?B?NzhNTXBHejRzTGYzU2RSSlNyV2hBMjF6QVp0cEJhR3pKUVV0VngvNGpNR3Mw?= =?utf-8?B?RFlHYVJlT0VzOGxSVjFDV2w3cy8xMmhhS0laM0o0Q0t3dUFLd21HSjU4Q1ZZ?= =?utf-8?B?dlMzTzRyVzQrVW5qcEYwWmkvOGVPWjRZdkE4d0JKc1duMlBNRVJESnZVY1h1?= =?utf-8?B?QmdHUlVLRHYzSzN1WnYwd1Y0ejVQd0xGd0pua3ZKWlJJQ096ZEVCbFlVNXdx?= =?utf-8?B?ZlpFRTVOVEFESmZkNzhaQXJwc1FDMDVXSnhqYVJlTFd3NGRhUEZNdTB5TlpR?= =?utf-8?B?QmprRjFhbHU1VHFkVE5hNGdsR0pocVZZT3FXVGNWaEdBZlJkQkcwSEdmcUg4?= =?utf-8?B?TXNMTzVnOHZxclhXQW9PYWVRRDFMS2lzTU1JVUNKVTBiVm81QzB4RFFvMEVJ?= =?utf-8?B?WU15dXZYY2ljR1h1V2VDUG1VaUM4OW92Ym95L2tHczZXcHZJOGIzdFkra3ha?= =?utf-8?B?VXFMalFRSXNvVk1Pa2JSaWg0SllZUEFSZ1ZhRERGcGNvRWJwaVNjaVNGM2ZX?= =?utf-8?B?c0pUb2s5TEtwcWJJdGdyaTU2OFVpdDRuNGFSODNySUxDSmx3RDlDNjlIZ0U0?= =?utf-8?B?UGtGRnRNMGIyWHArZE5BNkVtZGF0bXJiTDcweVRwcmhWdjBlTFpyWHowYVU3?= =?utf-8?B?WVFPVFViTjFWSXdlMVZsL3VSQjFDaXovRVVSMG1Rdzd6SXNDcTB3T0Z0ZnBG?= =?utf-8?B?V0puYmpla2l3SjBlU1RaeVRBTEdtRjNCVnRwMktOcVB6OUlua1JBWGpqd3Jq?= =?utf-8?B?dkJhTmR0dFpYdzFNL1oxWjhlQkNMUE51d0ZNN2hrRVlJUURzNlAyeGtuWFUz?= =?utf-8?B?aUxZWlhGRnc1KzJlL0J0QmQ4UDQ4bFU4cGtJdVdIV1NoTVJpMFg0aFR3VjRl?= =?utf-8?B?MjhoUWJJaXhwRWlCQ01rOHYxREtiZUUwMkR5akp2REdWbkJ3a2VxTitPZXRG?= =?utf-8?B?VHlybnhKWk01dXg1UThBZnpwVGVnT2pDRGdhcnBva2pFY3h3VE9zZVJXNG1a?= =?utf-8?B?ZzR3ekRMcWNHdkUzQ3I1ZitvU0VLV2p4d0hGYlNQMnNhaU1zYmVyT0V3Nll1?= =?utf-8?B?VlYwOE4yekcrV0EwcDJ1SlovYVJvOHZoY0tNL1JVVkl5eU9Eb2NQOWM3MU5G?= =?utf-8?B?WDRySnA5QWozWHJxRHBCK2UwdkRzRVNGalZyeE40VHFLLzVTL2lweGVKSUVN?= =?utf-8?B?NXdOVHFTV0pVSHJEOGhEY0srZUVPaVhEY3lGYWlwYjg4QXZqQk1BRGpZdWdF?= =?utf-8?B?bFhXUDdqbXlLNVo3aXpIclZ3eklQaGZJWHVhUndGSmp5ZStyVU5kTHM2aVRG?= =?utf-8?B?OURTN2hZRDBJa0Z4cksxZkZyR2N4QW4zSHlRL2xwQXBYM3hlajdmQ3B6Zkpp?= =?utf-8?B?YTk1QWNVcmJmbE9BaHJoQT09?= Content-Type: multipart/alternative; boundary="_000_BA3D1F1FDF914463BFEEECCCF9C79E22ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB4692.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 27104bf3-0643-40a2-883b-08d9874ea05e X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2021 15:50:01.5652 (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: r631AsKVcMQ9vfB4YPbtS1TnHxbN8jMuWfy1NVEv1fsWX3M+qiSSWGb67bKlxk5q X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2809 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xbe-rcd-001.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 04 Oct 2021 15:50:21 -0000 --_000_BA3D1F1FDF914463BFEEECCCF9C79E22ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBXRyBhbmQgdGhlIGNoYWlycywNCg0KSSBzdHJvbmdseSBzdXBwb3J0IHRoZSBhZG9wdGlv biBjYWxsDQoNCkFib3V0IHRoZSBtYXR0ZXIgaW4gdGhlIGVtYWlsLCB0aGUgV0cgaGFzIGRlZmlu ZWQgYSBzaW5nbGUgZGF0YSBwbGFuZSBzb2x1dGlvbiwgaS5lLiwgU1J2NiAoUkZDODQwMiwgUkZD ODc1NCwgYW5kIFJGQzg5ODYpLg0KU1J2NiBhcyBwZXIgdGhlIGluaGVyZW50IG5hdHVyZSBvZiB0 aGUgbmV0d29yayBwcm9ncmFtbWluZyBtb2RlbCAoUkZDODk5NikgYWxyZWFkeSBkZWZpbmVzIG11 bHRpcGxlIHN0YW5kYXJkaXplZCBiZWhhdmlvcnMuDQpDbGVhcmx5LCBDU0lEIGlzIGEgc2luZ2xl IHNvbHV0aW9uIGJhc2VkIG9uIHRoZSBTUnY2IGRhdGEgcGxhbmUuDQoNClRoYW5rcw0KDQpSZWdh cmRzIOKApiBaYWZhcg0KDQoNCkZyb206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+ IG9uIGJlaGFsZiBvZiBKYW1lcyBHdWljaGFyZCA8amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWku Y29tPg0KRGF0ZTogRnJpZGF5LCBPY3RvYmVyIDEsIDIwMjEgYXQgMTA6MDUgQU0NClRvOiBTUFJJ TkcgV0cgPHNwcmluZ0BpZXRmLm9yZz4NCkNjOiAic3ByaW5nLWNoYWlyc0BpZXRmLm9yZyIgPHNw cmluZy1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbc3ByaW5nXSBXRyBBZG9wdGlvbiBjYWxs IGZvciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5n LXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8NCg0KRGVhciBXRzoNCg0KVGhlIGNoYWlycyB3 b3VsZCBsaWtlIHRvIGV4cHJlc3MgdGhlaXIgYXBwcmVjaWF0aW9uIGZvciBhbGwgdGhlIHJlc3Bv bnNlcyByZWNlaXZlZCB0byBvdXIgZW1haWxzIHdpdGggcmVmZXJlbmNlIHRvIGhvdyB0aGUgd29y a2luZyBncm91cCB3aXNoZXMgdG8gbW92ZSBmb3J3YXJkIHdpdGggcmVzcGVjdCB0byBhIHNvbHV0 aW9uIGZvciBTUnY2IGNvbXByZXNzaW9uLg0KDQpUaGUgYXBwYXJlbnQgaW5jbGluYXRpb24gb2Yg dGhlIHdvcmtpbmcgZ3JvdXAgaXMgdG8gdXNlIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyBhcyB0 aGUgYmFzaXMgZm9yIGl0cyBjb21wcmVzc2lvbiBzdGFuZGFyZGl6YXRpb24gd29yay4gVGhhdCBp cyBwYXJ0IG9mIHdoYXQgdGhpcyBlbWFpbCBhdHRlbXB0cyB0byBjb25maXJtLg0KDQpCZWNhdXNl IG9mIHRoZSBhYm92ZSB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gaXNzdWUgYSAyLXdlZWsgV0cg Y2FsbCBmb3IgYWRvcHRpb24gZW5kaW5nIE9jdG9iZXIgMTV0aCBmb3IgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29t cHJlc3Npb24vIGJ1dCB3aXRoIHNvbWUgY2xlYXIgZ3VpZGVsaW5lcyBhcyBmb2xsb3dzLiBCeSBl eHByZXNzaW5nIHN1cHBvcnQgZm9yIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgeW91IGFyZSBm dWxseSBhd2FyZSBvZiBhbmQgYXJlIGFja25vd2xlZGdpbmcgdGhhdDoNCg0KDQoxLiAgICAgICBU aGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAgaXMgYWRvcHRpbmcgYSBkb2N1bWVudCB0aGF0IGhhcyBt dWx0aXBsZSBTUnY2IEVuZHBvaW50IGJlaGF2aW9ycy4NCg0KMi4gICAgICAgVGhlIGRvY3VtZW50 IGlzIGEg4oCcbGl2aW5n4oCdIGRvY3VtZW50OyBpdCBtYXkgY2hhbmdlIGFzIGl0IGdvZXMgdGhy b3VnaCByZXZpZXcgYW5kIGFuYWx5c2lzIGJ5IHRoZSBTUFJJTkcgd29ya2luZyBncm91cC4NCg0K My4gICAgICAgQWxsIG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgcmFpc2VkIG9uIG91ciBtYWlsaW5n IGxpc3QgTVVTVCBiZSBhZGRyZXNzZWQgQkVGT1JFIHNhaWQgZG9jdW1lbnQgaXMgYWxsb3dlZCB0 byBwcm9ncmVzcyBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIHRvIHB1YmxpY2F0aW9uLiBBIGxpc3Qg b2YgdGhlc2UgZGlzY3Vzc2lvbiBwb2ludHMgd2lsbCBiZSBkb2N1bWVudGVkIGluIHRoZSBXRyBk b2N1bWVudCBhbmQgbWFpbnRhaW5lZCBieSB0aGUgZG9jdW1lbnQgZWRpdG9yIGluIGNvbmp1bmN0 aW9uIHdpdGggdGhlIGNoYWlycy4NCg0KNC4gICAgICAgSWYgdGhpcyBkb2N1bWVudCBpcyBhZG9w dGVkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLCB0aGUgY2hhaXJzIHNwZWNpZnkgYXMgcGFydCBvZiB0 aGUgYWRvcHRpb24gY2FsbCB0aGF0IHRoZSBmb2xsb3dpbmcgdGV4dCBkZXNjcmliaW5nIGFuIG9w ZW4gaXNzdWUgYmUgYWRkZWQgdG8gdGhlIGRvY3VtZW50IGluIHRoZSBhYm92ZS1kZXNjcmliZWQg b3BlbiBpc3N1ZXMgc2VjdGlvbjoNCg0KwrcgICAgICAgICAiR2l2ZW4gdGhhdCB0aGUgd29ya2lu ZyBncm91cCBoYXMgc2FpZCB0aGF0IGl0IHdhbnRzIHRvIHN0YW5kYXJkaXplIG9uZSBkYXRhIHBs YW5lIHNvbHV0aW9uLCBhbmQgZ2l2ZW4gdGhhdCB0aGUgZG9jdW1lbnQgY29udGFpbnMgbXVsdGlw bGUgU1J2NiBFbmRQb2ludCBiZWhhdmlvcnMgdGhhdCBzb21lIFdHIG1lbWJlcnMgaGF2ZSBzdGF0 ZWQgYXJlIG11bHRpcGxlIGRhdGEgcGxhbmUgc29sdXRpb25zLCB0aGUgd29ya2luZyBncm91cCB3 aWxsIGFkZHJlc3Mgd2hldGhlciB0aGlzIGlzIHZhbGlkIGFuZCBjb2hlcmVudCB3aXRoIGl0cyBv bmUgZGF0YSBwbGFuZSBzb2x1dGlvbiBvYmplY3RpdmUuIi4NCg0KUGxlYXNlIGNvbnNpZGVyIHRo ZSBhYm92ZSBndWlkZWxpbmVzIGFzIHlvdSBkZWNpZGUgb24gd2hldGhlciB0byBzdXBwb3J0IG9y IG5vdCB0aGlzIFdHIGFkb3B0aW9uLiBQbGVhc2UgZXhwcmVzcyBjbGVhcmx5IHlvdXIgcmVhc29u aW5nIGZvciBzdXBwb3J0L25vbi1zdXBwb3J0IGFzIHdlbGwgYXMgYW55IG9wZW4gZGlzY3Vzc2lv biBwb2ludHMgeW91IHdvdWxkIGxpa2UgYWRkcmVzc2VkIHNob3VsZCB0aGUgZG9jdW1lbnQgYmUg YWRvcHRlZCBpbnRvIHRoZSB3b3JraW5nIGdyb3VwLg0KDQpUaGFua3MhDQoNCkppbSwgQnJ1bm8g JiBKb2VsDQoNCg0K --_000_BA3D1F1FDF914463BFEEECCCF9C79E22ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNv UGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxh aW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28t bGlzdC1pZDoxNDM0MDI0ODk7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjQxMDgzMTAzODt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMQ0KCXttc28tbGlz dC1pZDo3NTE2OTkzOTM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi03MjE2NTQ3NzYgNjc2OTg3MDMgNjc2OTg2ODkgNjc2OTg3MTUgNjc2OTg3MDMgNjc2 OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDE6bGV2 ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRl bnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpA bGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZl bDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13 cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkRlYXIgV0cgYW5kIHRoZSBjaGFpcnMsIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIHN0cm9uZ2x5IHN1cHBvcnQgdGhlIGFkb3B0aW9uIGNhbGw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QWJvdXQgdGhlIG1hdHRlciBpbiB0aGUgZW1haWwsIHRoZSBXRyBoYXMgZGVmaW5lZCBh IHNpbmdsZSBkYXRhIHBsYW5lIHNvbHV0aW9uLCBpLmUuLCBTUnY2IChSRkM4NDAyLCBSRkM4NzU0 LCBhbmQgUkZDODk4NikuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNS djYgYXMgcGVyIHRoZSBpbmhlcmVudCBuYXR1cmUgb2YgdGhlIG5ldHdvcmsgcHJvZ3JhbW1pbmcg bW9kZWwgKFJGQzg5OTYpIGFscmVhZHkgZGVmaW5lcyBtdWx0aXBsZSBzdGFuZGFyZGl6ZWQgYmVo YXZpb3JzLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DbGVhcmx5LCBD U0lEIGlzIGEgc2luZ2xlIHNvbHV0aW9uIGJhc2VkIG9uIHRoZSBTUnY2IGRhdGEgcGxhbmUuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rczxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5SZWdhcmRzIOKApiBaYWZhciZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFj ayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPnNwcmluZyAmbHQ7c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBv ZiBKYW1lcyBHdWljaGFyZCAmbHQ7amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tJmd0Ozxi cj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIE9jdG9iZXIgMSwgMjAyMSBhdCAxMDowNSBBTTxicj4N CjxiPlRvOiA8L2I+U1BSSU5HIFdHICZsdDtzcHJpbmdAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6 IDwvYj4mcXVvdDtzcHJpbmctY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDtzcHJpbmctY2hhaXJz QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bc3ByaW5nXSBXRyBBZG9wdGlvbiBj YWxsIGZvciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2No ZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDouNWluIj5EZWFyIFdHOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZSBjaGFp cnMgd291bGQgbGlrZSB0byBleHByZXNzIHRoZWlyIGFwcHJlY2lhdGlvbiBmb3IgYWxsIHRoZSBy ZXNwb25zZXMgcmVjZWl2ZWQgdG8gb3VyIGVtYWlscyB3aXRoIHJlZmVyZW5jZSB0byBob3cgdGhl IHdvcmtpbmcgZ3JvdXAgd2lzaGVzIHRvIG1vdmUgZm9yd2FyZCB3aXRoIHJlc3BlY3QgdG8gYSBz b2x1dGlvbiBmb3IgU1J2NiBjb21wcmVzc2lvbi4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPlRoZSBhcHBh cmVudCBpbmNsaW5hdGlvbiBvZiB0aGUgd29ya2luZyBncm91cCBpcyB0byB1c2UNCjxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3By aW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88L2E+ IGFzIHRoZSBiYXNpcyBmb3IgaXRzIGNvbXByZXNzaW9uIHN0YW5kYXJkaXphdGlvbiB3b3JrLiBU aGF0IGlzIHBhcnQgb2Ygd2hhdCB0aGlzIGVtYWlsIGF0dGVtcHRzIHRvIGNvbmZpcm0uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+QmVjYXVzZSBvZiB0aGUgYWJvdmUgdGhlIGNoYWlycyB3b3VsZCBsaWtlIHRv IGlzc3VlIGEgMi13ZWVrIFdHIGNhbGwgZm9yIGFkb3B0aW9uIGVuZGluZyBPY3RvYmVyIDE1PHN1 cD50aDwvc3VwPiBmb3INCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyI+DQpodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1z cnY2LXNyaC1jb21wcmVzc2lvbi88L2E+IGJ1dCB3aXRoIHNvbWUgY2xlYXIgZ3VpZGVsaW5lcyBh cyBmb2xsb3dzLiBCeSBleHByZXNzaW5nIHN1cHBvcnQgZm9yIGFkb3B0aW9uIG9mIHRoaXMgZG9j dW1lbnQgeW91IGFyZSBmdWxseSBhd2FyZSBvZiBhbmQgYXJlIGFja25vd2xlZGdpbmcgdGhhdDoN CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEg bGV2ZWwxIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+VGhlIFNQUklORyB3b3JraW5nIGdyb3VwIGlzIGFkb3B0aW5nIGEgZG9jdW1l bnQgdGhhdCBoYXMgbXVsdGlwbGUgU1J2NiBFbmRwb2ludCBiZWhhdmlvcnMuDQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4w aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NCjwhW2lmICFz dXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9 ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoZSBkb2N1bWVu dCBpcyBhIOKAnGxpdmluZ+KAnSBkb2N1bWVudDsgaXQgbWF5IGNoYW5nZSBhcyBpdCBnb2VzIHRo cm91Z2ggcmV2aWV3IGFuZCBhbmFseXNpcyBieSB0aGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAuDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj4N CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkFs bCBvcGVuIGRpc2N1c3Npb24gcG9pbnRzIHJhaXNlZCBvbiBvdXIgbWFpbGluZyBsaXN0IE1VU1Qg YmUgYWRkcmVzc2VkIEJFRk9SRSBzYWlkIGRvY3VtZW50IGlzIGFsbG93ZWQgdG8gcHJvZ3Jlc3Mg ZnJvbSB0aGUgd29ya2luZyBncm91cCB0byBwdWJsaWNhdGlvbi4gQSBsaXN0IG9mIHRoZXNlIGRp c2N1c3Npb24gcG9pbnRzIHdpbGwgYmUgZG9jdW1lbnRlZCBpbiB0aGUgV0cgZG9jdW1lbnQgYW5k IG1haW50YWluZWQNCiBieSB0aGUgZG9jdW1lbnQgZWRpdG9yIGluIGNvbmp1bmN0aW9uIHdpdGgg dGhlIGNoYWlycy4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBs ZXZlbDEgbGZvMyI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 SWdub3JlIj40LjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZx dW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT5JZiB0aGlzIGRvY3VtZW50IGlzIGFkb3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3Jv dXAsIHRoZSBjaGFpcnMgc3BlY2lmeSBhcyBwYXJ0IG9mIHRoZSBhZG9wdGlvbiBjYWxsIHRoYXQg dGhlIGZvbGxvd2luZyB0ZXh0IGRlc2NyaWJpbmcgYW4gb3BlbiBpc3N1ZSBiZSBhZGRlZCB0byB0 aGUgZG9jdW1lbnQgaW4gdGhlIGFib3ZlLWRlc2NyaWJlZCBvcGVuIGlzc3VlcyBzZWN0aW9uOjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjEuNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDIgbGZvMyI+DQo8IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+JnF1b3Q7R2l2ZW4g dGhhdCB0aGUgd29ya2luZyBncm91cCBoYXMgc2FpZCB0aGF0IGl0IHdhbnRzIHRvIHN0YW5kYXJk aXplIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uLCBhbmQgZ2l2ZW4gdGhhdCB0aGUgZG9jdW1lbnQg Y29udGFpbnMgbXVsdGlwbGUgU1J2NiBFbmRQb2ludCBiZWhhdmlvcnMgdGhhdCBzb21lIFdHIG1l bWJlcnMgaGF2ZSBzdGF0ZWQgYXJlIG11bHRpcGxlIGRhdGEgcGxhbmUgc29sdXRpb25zLA0KIHRo ZSB3b3JraW5nIGdyb3VwIHdpbGwgYWRkcmVzcyB3aGV0aGVyIHRoaXMgaXMgdmFsaWQgYW5kIGNv aGVyZW50IHdpdGggaXRzIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uIG9iamVjdGl2ZS4mcXVvdDsu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+UGxlYXNlIGNvbnNpZGVyIHRoZSBhYm92ZSBndWlkZWxpbmVzIGFz IHlvdSBkZWNpZGUgb24gd2hldGhlciB0byBzdXBwb3J0IG9yIG5vdCB0aGlzIFdHIGFkb3B0aW9u LiBQbGVhc2UgZXhwcmVzcyBjbGVhcmx5IHlvdXIgcmVhc29uaW5nIGZvciBzdXBwb3J0L25vbi1z dXBwb3J0IGFzIHdlbGwgYXMgYW55IG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgeW91IHdvdWxkIGxp a2UNCiBhZGRyZXNzZWQgc2hvdWxkIHRoZSBkb2N1bWVudCBiZSBhZG9wdGVkIGludG8gdGhlIHdv cmtpbmcgZ3JvdXAuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+VGhhbmtzITxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkpp bSwgQnJ1bm8gJmFtcDsgSm9lbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BA3D1F1FDF914463BFEEECCCF9C79E22ciscocom_-- From nobody Mon Oct 4 09:02:27 2021 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 437993A0976 for ; Mon, 4 Oct 2021 08:29:23 -0700 (PDT) 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, 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, 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 Tn-KS0kWXMw4 for ; Mon, 4 Oct 2021 08:29:17 -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 C2E0F3A0991 for ; Mon, 4 Oct 2021 08:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquid.tech; s=mimecast20210406; t=1633361346; 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=RBNsnJfWJJ2VZ8MRmNpS7nsPyaNHjBbzQYDbIt7WP2U=; b=Nc0ZvQ7GWWvfASJ1bVXOqwnejiyoKWoVWsoesGgiIybp1kHhHxLqx9dHL9L0gSFJ3/qkrt rOMYzeNx7GQSztquII1H3mFVy9zm0kphei6V20UhHlxb6RSPF/fr08fFVxx07vmkwMUias 3QnTAAsGwOsEorKqFyU4NU0d2hsTzOY= Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05lp2176.outbound.protection.outlook.com [104.47.17.176]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-171-G-AjZxQsNbaOtm3Emh8svA-1; Mon, 04 Oct 2021 16:28:01 +0100 X-MC-Unique: G-AjZxQsNbaOtm3Emh8svA-1 Received: from DB7PR03MB4059.eurprd03.prod.outlook.com (2603:10a6:5:33::13) by DB3PR0302MB3274.eurprd03.prod.outlook.com (2603:10a6:8:8::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.19; Mon, 4 Oct 2021 15:27:59 +0000 Received: from DB7PR03MB4059.eurprd03.prod.outlook.com ([fe80::f063:14c2:ad5:1ed9]) by DB7PR03MB4059.eurprd03.prod.outlook.com ([fe80::f063:14c2:ad5:1ed9%5]) with mapi id 15.20.4544.026; Mon, 4 Oct 2021 15:27:58 +0000 From: Daniam Henriques To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQCYxk2K Date: Mon, 4 Oct 2021 15:27:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 547f7cb3-7d2f-a245-c38a-13b489e978b7 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c96ac102-c140-42e5-0f77-08d9874b8bf0 x-ms-traffictypediagnostic: DB3PR0302MB3274: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: wPsvF9G6+7eew9cRBy0Ybrxb4ek7djdc/xvf4dR3ttLXVcJelt7Kp9zqhvTQvZFUD5gpdjXP9jkch+6sVR+73Xd9iwmTr/SemhVbPyfQqtQgNh78kMqoXoRlRYSiDJLjQkf2qK/oX9DvLVAY4XwU1YRY/7jy5VdNhyFn9aAnR8NuSFDPnK5Fi8OlrCHBpfIuLHtQpBugZ5uzoz0IV8jaWxg8IaqlCuOGLJo9Y5Z0iywOd/fvy0ozLrdosc65SYFJ67qlT6r/Kxx5lEZFkN4smNO9Y9xACunOD2F9RmSPHpFUOHCzdSrSdnb7/9xz1gyV2xZKBRxtyBTNEu/leIdGRpxL9/VwEeBPLghtVn+LUYDoAkGa6KxHneBufLsyZ2pgg0HBaJSfY3CmhlZgbot/EY8136u7xzCsbFdvyMwN1Eiz/zFQlsQgN1mJPurJAf5UQP7iYn+P2bT8fNjFcp+4IRHmvnKLzVEDgiZyuSgegraC5sUZspgKzChUZHHXiYqJuCLNjKywH93/Gsle6aWjmL+MV4JuwysVAUtOYFtFFspJy5ueExA0aLZe6F3bGAqdhu4xrmWH/8naiRzhor6UCnN63GnXyHe9J/e0+z4gfmFlgdnbJRdaKalYNc547wXGC01YJ9N1W4b8YTPrS3Ycu0ZlicLIxQEUPOVoMEa+kKEQFDgi3WbpvgbMt/tc8qtZPEP+ntKUXV8hCKasKLwsm32ZtIILnr3F/oX7n8TfbMLlH/nA04l732VuwKjYbrX1My/Uzp0VU5kdPMglL2mX430bvDnwJIt3/tRAnrJMROQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR03MB4059.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(7696005)(83380400001)(33656002)(38070700005)(55236004)(186003)(19627405001)(53546011)(71200400001)(4326008)(8676002)(498600001)(5660300002)(55016002)(44832011)(166002)(966005)(9686003)(52536014)(122000001)(66446008)(91956017)(76116006)(66556008)(110136005)(2906002)(86362001)(66476007)(26005)(64756008)(66946007)(8936002)(6506007)(38100700002); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?8GY2hB4Ntyu24/JvnP2+TArhrdGg2Mh7RXcjqqCmGOsUKR5c1wWxFd5D?= =?Windows-1252?Q?leEx151WKtAEnURb4NBpkkl+CyX0qI9pfeR6ScVJINb9ahOpvxm+VK/2?= =?Windows-1252?Q?Oz7ouT2xogY+JkLpxDXhU69D0gfo+40+ua5rAnFt2aw7FaIf9wd1pIR2?= =?Windows-1252?Q?1VPaXUK/56RecHJlG1zGnkCGQNdhEbtGxAd8759DaNLAFioA4J439rwy?= =?Windows-1252?Q?cyqgPyNP9DzalbMjJQXepFCmsg++WDl9yTIghJS/dVnFAqBnC4r4DJNZ?= =?Windows-1252?Q?n/rcANTscop2691WTAjrMqNoWvKcG4SVuxTjudJ1jUzZHMgu2e/PVVXf?= =?Windows-1252?Q?dsNp+UVn0Jb27ASeVRIyEjAT67SQGagOKmk4U7HEgaWN5BtE5hz9O5Ts?= =?Windows-1252?Q?gY8k42QDbfP225zYANXjWsUWj1ONAL3omKKchxxeOr/CswLJhz4tKnWc?= =?Windows-1252?Q?Ejeiz0+R3kQ08yLo6cffFeMQM2hyRgGMmoG1iCH/yCJMCOOG7AFbwwVf?= =?Windows-1252?Q?TFBD5CbZ/Yumw37VzNDHroVPkK9X3FouwkU6BRkat5BGFvoggcNoVJeP?= =?Windows-1252?Q?rBSVNZrnp0q2UN6e1HVsnBjoLMgST41yDexATYX+W9ziXFKFwwcmBtvo?= =?Windows-1252?Q?kCECRlBo+TO0vZfO67a/PDN91bVpsyjdkVSg9yIHUquU/dn/GdnByjPR?= =?Windows-1252?Q?ifJjpxulOpd3dd2uoVkRYW+hV8iqVs4tCR/SuTKmvqjoJugbsjHYh4Fo?= =?Windows-1252?Q?bBWeBDYiltQm9r5jpgdoxa2wCEGlSIp9jcVUDWOfs3HqGh5dZxY9CkK3?= =?Windows-1252?Q?Ljw+obwc1yaJnKIL7iUU/d/PDD6sbTTnbyw/akS5Xm2iSptQqLNoUAra?= =?Windows-1252?Q?BXgAusyc2GtkiE6Ynn5AS3pHyYooxalVbso28nb/YiFg0f9ZGk8rx3Dc?= =?Windows-1252?Q?HjhWfFbLPW+6wHH8/RLNOpPzCyCbV22uw5DeqQ9lpv5XF8ugf/VbQ2mg?= =?Windows-1252?Q?W2CwCmi7xn7UE/Cyr/24U+2t/R60BlWyHef9rYmJnN0EMsLzcnQi9K/7?= =?Windows-1252?Q?cjeD9MMAgk4oiNSLWVLjBlDokQH+62FZab2/Tg3Fcp3NQNM/oa16Jvwe?= =?Windows-1252?Q?0To1Fm2Jh1mEzM7GHKQoX5DuDQERdbyrx7GecAo+Uu8ZBUJr9mJmVdVD?= =?Windows-1252?Q?KrDZ+jf6xh6FR3R46jIEKnu97c6dSXN3jmgOT9/aMoXvl7eNfxqnbUyi?= =?Windows-1252?Q?yCeyyGDwuGNZgxincPzd5vQToN5Y8seUvOcd7TriArkexi+lWpjXl8Hg?= =?Windows-1252?Q?Raok0M5iLWewll6KdaA/A0ysYtyYemajDA2vEl7qNJdy3YarAMh6uerk?= =?Windows-1252?Q?0jtfTFFzn2Nm4g5PuDhcnY1ECZjYftjpZKzeUug7xd3ce++25jFZNiW6?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquid.tech X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DB7PR03MB4059.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c96ac102-c140-42e5-0f77-08d9874b8bf0 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2021 15:27:58.8459 (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: 3BAL+3Covu9FpKWeiNKz2Db0yFW+/vfWGSnrAiW/NMKQsl8xGuHxs1Z27kO1lVoTEcn7kNalcJ/Lxpdy5hHRUFIQnbAxQPl4zR6xFdkDkRreqCCCg+hi0HfnkIDOokgs X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0302MB3274 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=daniam.henriques@liquid.tech X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquid.tech Content-Language: en-GB Content-Type: multipart/alternative; boundary="_000_DB7PR03MB4059AE1EF77C16D4E850570C88AE9DB7PR03MB4059eurp_" Archived-At: X-Mailman-Approved-At: Mon, 04 Oct 2021 09:02:17 -0700 Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 04 Oct 2021 15:29:31 -0000 --_000_DB7PR03MB4059AE1EF77C16D4E850570C88AE9DB7PR03MB4059eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi All My foremost concern regarding the adoption to this draft relates to timing = and progressing the call for adoption while there are several unaddressed a= nd serious concerns that have been raised. While the WG recently reached consensus around the adoption of one and only= one data plane solution and we are already discussing solutions which requ= ire multiple data plane solutions, perhaps we need to consider that, while = not ideal for some, having multiple data plane options provides us the best= solution going forward. In this regard I believe it is important to note t= hat all the compression mechanisms that have been proposed thus far make ce= rtain design decisions and are ultimately a compromise of flexibility, feat= ure support, simplicity, etc. Is limiting ourselves to one and only one dat= a-plane option the best for everyone going forward? Do we perhaps need to r= evisit earlier discussions around one/more data plane options before procee= ding further? I also believe Ron's point regarding RFC 4291 compliance is something that = should be investigated by this WG/6MAN before adoption and not something wh= ich should only be considered later. Regards, Daniam ________________________________ From: spring on behalf of James Guichard Sent: 01 October 2021 16:04 To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as t= he basis for its compression standardization work. That is part of what thi= s email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guideline= s as follows. By expressing support for adoption of this document you are f= ully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a =93living=94 document; it may change as it goes thr= ough review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel This email disclaimer applies to the original email, all attachments and an= y subsequent emails sent by Liquid Telecom. This email contains valuable bu= siness information that is privileged, confidential and/or otherwise protec= ted from disclosure, intended only for the named person or entity to which = it is addressed. If you are not the intended recipient of this email and yo= u received this e-mail in error, any review, use, dissemination, distributi= on, printing or copying of this e-mail is strictly prohibited and may be un= lawful and/or an infringement of copyright. Please notify us immediately of= the error and permanently delete the email from your system, retaining no = copies in any media. No employee or agent is authorized to conclude any bin= ding agreement on behalf of Liquid Telecom with another party or give any w= arranty by email without the express written confirmation by an authorized = representative or a director of Liquid Telecom. Nothing in this email shall= be construed as a legally binding agreement or warranty or an offer to con= tract. Liquid Telecom will not be responsible for any damages suffered by t= he recipient as a result of the recipient not taking cognizance of this pri= nciple. Liquid Telecom accepts no liability of whatever nature for any loss= , liability, damage or expense resulting directly or indirectly from the ac= cess of any files which are attached to this message. Any email addressed t= o Liquid Telecom shall only be deemed to have been received once receipt is= confirmed by Liquid Telecom orally or in writing. An automated acknowledgm= ent of receipt will not suffice as proof of receipt by the Liquid Telecom. = This email disclaimer shall be governed by the laws of South Africa. --_000_DB7PR03MB4059AE1EF77C16D4E850570C88AE9DB7PR03MB4059eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
Hi All

My foremost concern regarding the adoption to this draft relates to timing = and progressing the call for adoption while there are several unaddressed a= nd serious concerns that have been raised.

While the WG recently reached consensus around the adoption of on= e and only one data plane solution and we are already discussing solutions = which require multiple data plane solutions, perhaps we need to consider that, while not ideal for some, hav= ing multiple data plane options provides us the best solution going forward= . In this regard I believe it is important to note that all the compression= mechanisms that have been proposed thus far make certain design decisions and are ultimately a compromise of = flexibility, feature support, simplicity, etc. Is limiting ourselves to one= and only one data-plane option the best for everyone going forward? Do we = perhaps need to revisit earlier discussions around one/more data plane options before proceeding further?<= /span>

I also believe Ron's point regarding RFC 4291 compliance is something that = should be investigated by this WG/6MAN before adoption and not something wh= ich should only be considered later.

Regards,
Daniam

From: spring <spring-b= ounces@ietf.org> on behalf of James Guichard <james.n.guichard@future= wei.com>
Sent: 01 October 2021 16:04
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/
 

Dear WG:

 

The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression.

 

The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document that has multiple SRv6 Endp= oint behaviors.
  2. The document is a =93living=94 document; it may change as it goes through r= eview and analysis by the SPRING working group.
  3. All open discussion points raised on our mailing list MUST be addressed BEF= ORE said document is allowed to progress from the working group to publicat= ion. A list of these discussion points will be documented in the WG documen= t and maintained by the document editor in conjunction with the chairs.
  4. If this document is adopted by the working group, the chairs specify as par= t of the adoption call that the following text describing an open issue be = added to the document in the above-described open issues section:
    • "Given that the working group has said that it wants to standardize on= e data plane solution, and given that the document contains multiple SRv6 E= ndPoint behaviors that some WG members have stated are multiple data plane = solutions, the working group will address whether this is valid and coherent with its one data plane solution object= ive.".

 

Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

Thi= s email disclaimer applies to the original email, all attachments and any s= ubsequent emails sent by Liquid Telecom. This email contains valuable busin= ess information that is privileged, confidential and/or otherwise protected from disclosure, intended only for the named pe= rson or entity to which it is addressed. If you are not the intended recipi= ent of this email and you received this e-mail in error, any review, use, d= issemination, distribution, printing or copying of this e-mail is strictly prohibited and may be unlawful and/o= r an infringement of copyright. Please notify us immediately of the error a= nd permanently delete the email from your system, retaining no copies in an= y media. No employee or agent is authorized to conclude any binding agreement on behalf of Liquid Telecom w= ith another party or give any warranty by email without the express written= confirmation by an authorized representative or a director of Liquid Telec= om. Nothing in this email shall be construed as a legally binding agreement or warranty or an offer to con= tract. Liquid Telecom will not be responsible for any damages suffered by t= he recipient as a result of the recipient not taking cognizance of this pri= nciple. Liquid Telecom accepts no liability of whatever nature for any loss, liability, damage or expense re= sulting directly or indirectly from the access of any files which are attac= hed to this message. Any email addressed to Liquid Telecom shall only be de= emed to have been received once receipt is confirmed by Liquid Telecom orally or in writing. An automated = acknowledgment of receipt will not suffice as proof of receipt by the Liqui= d Telecom. This email disclaimer shall be governed by the laws of South Afr= ica. --_000_DB7PR03MB4059AE1EF77C16D4E850570C88AE9DB7PR03MB4059eurp_-- From nobody Mon Oct 4 09:20:18 2021 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 EF4BE3A0981; Mon, 4 Oct 2021 09:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H7maAzkU28aa; Mon, 4 Oct 2021 09:20:00 -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 63E703A0A22; Mon, 4 Oct 2021 09:19:59 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id om12-20020a17090b3a8c00b0019eff43daf5so325419pjb.4; Mon, 04 Oct 2021 09:19:59 -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=pe4U1uP/rFAKToHBNzxqvH0gtq5Upz383wqp6HBHv44=; b=qtHfWMXoKXIGAUQx9rTIgnYZ3V3ErPxFMM2y36AGSzpKBrxLLXogwFc3idlhjuh0xQ iMS43xK4ma9LB8tE+rYkQzhLJJ1fGawitUMvfhdPpyiSqm3M58r+xp1tJqJIS/aCp04N SWiZnJQMHkrGxsRrU7dsxaHikiGuOmIL0SCxwf88wUWsztfTXXzs3QgJQ7/ipLuvkuoR tLTqubjsiCgbfTl67z0rQzUE/ExDTUF6uhy+jqiEUoaWoi+B/CByudL1Tm+2CtsT/TuV slndrG5pgagifcnBJCOqDPN3buh5Q7j11SSV+ViCC9vNAwgGM4vQtY0/XACI8tZQIFGg 3Mhw== 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=pe4U1uP/rFAKToHBNzxqvH0gtq5Upz383wqp6HBHv44=; b=2NCD/io7MDVXZvEXH8rIecpEdaelPB1fs2dNemIDywgBjnjZoZjPsgW8T4dyPx5b5A xPcwxfcaThDLrWWLnVCkQRQXX9mcQz6RhOX9u3VlA+bTa2CiQEKopxFTRfZm/ridJ+0v neK8WDVDxQ+3gvqGt5w+HkJPO9Q89cG1FD1mXxJagbqoV4G5FdPi+kfxDxZZiP7/PYOz f3iMWGorbDW/22yFJT1ippwnyPtxzlX6Dl4z2gS/hG1LjWLYAQeZ8Q4hrosqPkm03jaF d/1ynFWSdDWzpgGqI6Cv6VWEnzUUNTnnCcI+cWFfeEW6Rxz+tgye34KcQYY808C6tIqB QSpw== X-Gm-Message-State: AOAM533SR6Pr8ePRyLSUyBpDTQUwt2DJg6wAQUSXrSKErn0REZkn65Qc MxgmpLl4Ek8F3VOjGGds3z/CiYjmKhGwv579Nkc= X-Google-Smtp-Source: ABdhPJxO+eZcp44Q5sCMLnxQra4V4xPYij9CTPSAYWuQfl6iXXKwRq32Kka2QARcDM+1qbtcdA90aFwR0LJuJZ+7AZU= X-Received: by 2002:a17:90a:4306:: with SMTP id q6mr37632597pjg.202.1633364398250; Mon, 04 Oct 2021 09:19:58 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Mon, 4 Oct 2021 12:19:47 -0400 Message-ID: To: Greg Mirsky Cc: Andrew Alston , James Guichard , SPRING WG , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bf241e05cd8948f9" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 04 Oct 2021 16:20:15 -0000 --000000000000bf241e05cd8948f9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable +1 =E2=80=9CIf that is the case, has anyone in the WG considered that the WG m= ay adopt either uSID or SRv6 document as the basis of the standard compressing SRv6 SID? (Yes, I thought about that and I am kinda in favor of the idea).=E2=80= =9D On Mon, Oct 4, 2021 at 11:48 AM Greg Mirsky wrote: > Hi Jim, > thank you for the detailed explanation of the considerations the WG Chair= s > went through before starting the WG AP. As I understand it, the C-SID > proposal integrates two mechanisms that were presented to the SPRING WG a= nd > thoroughly discussed as separate drafts. These are uSID and GSRv6. Lookin= g > at the list of the requirements and the analysis of CSID, I believe that = it > is safe to conclude that, as components of C-SID, uSID and GSRv6 are > conformant to all the requirements. If that is the case, has anyone in th= e > WG considered that the WG may adopt either uSID or SRv6 document as the > basis of the standard compressing SRv6 SID? (Yes, I thought about that an= d > I am kinda in favor of the idea). > > Regards, > Greg > > On Mon, Oct 4, 2021 at 8:10 AM James Guichard < > james.n.guichard@futurewei.com> wrote: > >> Andrew, >> >> >> >> As stated in our email of September 9th, the chairs communicated that th= e >> working group reached rough (quite clear) consensus for standardizing on= e >> data plane solution to compress segment routing over IPv6. In addition t= o >> this there was an inclination toward using the CSID document as the basi= s >> for our work in this area. The chairs recognized that there was however >> disagreement as to whether this document, having multiple SRv6 EndPoint >> behaviors, could be considered consistent with the working group consens= us >> for a single data plane solution. This issue quite clearly needed to be >> addressed, and the chairs, recognizing that the working group is keen to >> make progress in this area, had the option of trying to resolve the issu= e >> prior to issuing an adoption call, or give the working group the >> opportunity to express their opinions as part of a call for adoption. >> >> >> >> Those who feel that we need to resolve the consistency issue before >> adoption, as with those who think this is not a good basis for the WG wo= rk, >> are free and expected to object to the WG adopting the document. That is >> distinct from objecting to the chairs issuing the adoption call. >> >> >> >> In essence, the chairs have combined the question of when to resolve >> consistency and the question of whether this document is a good basis fo= r >> the WG into one call. >> >> >> >> Yours, >> >> >> >> Jim, Bruno & Joel >> >> >> >> >> >> *From:* Andrew Alston >> *Sent:* Friday, October 1, 2021 4:21 PM >> *To:* James Guichard ; SPRING WG < >> spring@ietf.org> >> *Cc:* spring-chairs@ietf.org >> *Subject:* Re: WG Adoption call for >> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-com= pression/ >> >> >> >> Sorry =E2=80=93 but =E2=80=93 I=E2=80=99m a little confused here. >> >> >> >> Because the way I look at this =E2=80=93 the working group clearly state= d that >> they wished for a single behavior =E2=80=93 and this =E2=80=93 does not = deliver that =E2=80=93 it >> is two separate behaviors. As such =E2=80=93 I see this call for adopti= on =E2=80=93 >> irrespective of the merits or lack thereof of the draft, as a clear >> defiance of the stated will of the working group. >> >> >> >> This is simply does not fit into the definition of bottom up approach in >> my opinion =E2=80=93 and if this is the way that the chairs wish to proc= eed =E2=80=93 then >> the only way to do that and still fit within the bottom up approach is t= o >> first ask this working group for its consensus to deviate from the singl= e >> behacvior approach that the working group agreed to. >> >> >> >> As such =E2=80=93 I must strongly and unequivocally object to this call= for >> adoption >> >> >> >> Andrew >> >> >> >> *From: *spring on behalf of James Guichard < >> james.n.guichard@futurewei.com> >> *Date: *Friday, 1 October 2021 at 17:05 >> *To: *SPRING WG >> *Cc: *spring-chairs@ietf.org >> *Subject: *[spring] WG Adoption call for >> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-com= pression/ >> >> Dear WG: >> >> >> >> The chairs would like to express their appreciation for all the response= s >> received to our emails with reference to how the working group wishes to >> move forward with respect to a solution for SRv6 compression. >> >> >> >> The apparent inclination of the working group is to use >> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-com= pression/ >> >> as the basis for its compression standardization work. That is part of w= hat >> this email attempts to confirm. >> >> >> >> Because of the above the chairs would like to issue a 2-week WG call for >> adoption ending October 15th for >> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-com= pression/ >> >> but with some clear guidelines as follows. By expressing support for >> adoption of this document you are fully aware of and are acknowledging >> that: >> >> >> >> 1. The SPRING working group is adopting a document that has multiple >> SRv6 Endpoint behaviors. >> 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change= as it goes >> through review and analysis by the SPRING working group. >> 3. All open discussion points raised on our mailing list MUST be >> addressed BEFORE said document is allowed to progress from the workin= g >> group to publication. A list of these discussion points will be docum= ented >> in the WG document and maintained by the document editor in conjuncti= on >> with the chairs. >> 4. If this document is adopted by the working group, the chairs >> specify as part of the adoption call that the following text describi= ng an >> open issue be added to the document in the above-described open issue= s >> section: >> - "Given that the working group has said that it wants to >> standardize one data plane solution, and given that the document c= ontains >> multiple SRv6 EndPoint behaviors that some WG members have stated = are >> multiple data plane solutions, the working group will address whet= her this >> is valid and coherent with its one data plane solution objective."= . >> >> >> >> Please consider the above guidelines as you decide on whether to support >> or not this WG adoption. Please express clearly your reasoning for >> support/non-support as well as any open discussion points you would like >> addressed should the document be adopted into the working group. >> >> >> >> Thanks! >> >> >> >> Jim, Bruno & Joel >> >> >> >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --000000000000bf241e05cd8948f9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

+1=C2=A0

=
=E2=80=9CIf that is the case, has anyone in the WG consid= ered that the WG may adopt either uSID or SRv6 document as the basis of the= standard compressing SRv6 SID? (Yes, I thought about that and I am kinda i= n favor of the idea).=E2=80=9D
--
--000000000000bf241e05cd8948f9-- From nobody Mon Oct 4 09:22:49 2021 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 513343A0976; Mon, 4 Oct 2021 09:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 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, 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=DdL2660h; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=t8pZKDiI 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 0ZtJvUhIzHu4; Mon, 4 Oct 2021 09:22:42 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 163D63A0772; Mon, 4 Oct 2021 09:22:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14035; q=dns/txt; s=iport; t=1633364562; x=1634574162; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=xUOzUWvvU0iA3vh6ZNhCEObDrp/pxdlSjohBPzpw13o=; b=DdL2660ht3rmLnHRS6KI9L+eD6ToGTBCj74o2dgQX2eMrpXVUWyPkNzZ y4J2hV4LeaxOy1T0uQULfdticB18CO5FpHkhUhOysQbjJciYMdfH8l1kD eGaS7nn718IpFlE0aqAE9KJMKRMTGKrhZ6Gz8nwKjP+NfclV61r889IAw 8=; IronPort-PHdr: =?us-ascii?q?A9a23=3Axipvsxd1051IjSQrzEbK7d2RlGM/V4qcDmcuA?= =?us-ascii?q?tIPha9Sb76u4JnjekfY4KYlgFzIWNDd7PRJw6rTvrv7UGMNqZCGrDgZcZNKW?= =?us-ascii?q?hNE7KdenwEpDMOfT0GuKvnsYn80AdhfTlJ68nD9Ok9QS47yYlTIqSi06jgfU?= =?us-ascii?q?hz0KQtyILHzHYjfx8S63uy/4dvdeQJN0TG8erh1ah6xqFa5iw=3D=3D?= IronPort-Data: =?us-ascii?q?A9a23=3A0AsAlqsaU12LO7CF/nKT4lu8LufnVJxcMUV32?= =?us-ascii?q?f8akzHdYApBsoF/qtZmKWHXPKnbNGD0L9wkPd+z/R4Ou5XQzYBhGVNo/ngxR?= =?us-ascii?q?HwbgMeUXt7xwmUckM+xwmwvdK/shiknQoGowPscEzmM+39BDpC79SMljPnQG?= =?us-ascii?q?uKmYAL5EnkZqTFMGX9JZS1Lw4bVsqYw6TSIK1vlVeHa+qUzC3f9s9JACV/43?= =?us-ascii?q?orYwP9ZUFsejxtD1rA2TagjUFYzDBD5BrpHTU26ByOQroW5goeHq+j/ILGRp?= =?us-ascii?q?gs1/j83Ad+j1738aEBPG+eUNgmVgX0QUK+n6vRAjnVtieBga7xNMgEO12rhc?= =?us-ascii?q?9NZkL2hsbS+QgMgMoXHmf8WVF9TFCQW0ahuqeObfCDl65TIp6HBWz62qxl0N?= =?us-ascii?q?2ktJZcZ/OkyCmFH9OYDADEAch7FgPi5qJqgUvNtgMsLLcT3MsUYoH4I5TPQC?= =?us-ascii?q?Ps9B5aFTLjL7t9RxjsYiN1SAOzTeMcYLzFoaXz9j7dnUrsMIIg1kOHtjX7lf?= =?us-ascii?q?ngB8RSepLE85C7YywkZ7VQkC/KNEvTieCmfthzwSrr6wlnE?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AJuH4/KATpg6EGK7lHegOsceALOsnbusQ8z?= =?us-ascii?q?AXPh9KKCC9I/b3qynxppsmPEfP+UkssHFJo6HmBEDyewKjyXcV2/hRAV7GZm?= =?us-ascii?q?nbUQSTXfpfBOfZsljd8mjFh5JgPMRbAuhD4b/LfCJHZK/BiWHSebtNsbr3kp?= =?us-ascii?q?xAx92uskuFJjsaDZ2Imj0JcjpzZXcGPTWua6BJcKa0145inX6NaH4XZsO0Cj?= =?us-ascii?q?0uRO7YveDGk5rgfFovGwMnwBPmt0Lq1JfKVzyjmjsOWTJGxrkvtULflRbi26?= =?us-ascii?q?mlu/anjjfBym7o6YhMkteJ8KoAOCXMsLlRFtzfsHfuWG1TYczFgNnzmpD31L?= =?us-ascii?q?8eqqiJn/7nBbUq15qeRBDvnfKn4XiQ7N9n0Q6T9bbfuwq4nSQ8LwhKV/aoQu?= =?us-ascii?q?liA0bkAgMbzaJB+bMO0GSDu5VNCxTc2Cz7+tjTThlv0lG5uHw4jIco/jFiuK?= =?us-ascii?q?YlGfRsRLYkjQlo+VY7bVXHwZFiFPMrANDX5f5Qf1/fZ3fFvnN3yNjpWngoBB?= =?us-ascii?q?+JTkULp8TQilFt7T9E5lpdwNZakmYL9Zo7RZUB7+PYMr5wnLULSsMNd6pyCO?= =?us-ascii?q?oIXMPyAG3QRhDHNn6UPD3cZe06EmOIr4Sy7KQ+5emsdpBNxJwumI7ZWFcdrm?= =?us-ascii?q?I2c1KGM7zH4HSKyGGFfIyZZ0Wi9ihz3ekNhlTMfsucDcTYciFdryKJmYRqPv?= =?us-ascii?q?Hm?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D0AQAbKVth/5NdJa1aHQEBAQEJARI?= =?us-ascii?q?BBQUBQIFIBQELAYEgMCMuB3daNzGIDwOFOYgIA5VmhQaBQoERA1QLAQEBDQE?= =?us-ascii?q?BNwoEAQGEfQKCQgIlNwYOAQIEAQEBEgEBBQEBAQIBBgSBEROFOwglDYZCAQE?= =?us-ascii?q?BAQMSCxATAQEsCwEPAgEIEQMBAiQLMh0IAQEEAQ0FCBMHglCBflcDLwEOpTY?= =?us-ascii?q?BgToCih94gTOBAYIIAQEGBASBSkGCfxiCNQMGgToBgn+EE4ZyJxyBSUSBFAF?= =?us-ascii?q?Dgmc+gmMCA4EjBQESASMeBgeDIoIMIooBL0JkBBs4IAJZFkk5KhEpkX2MBo1?= =?us-ascii?q?LkioKgzCBMokSlD0Ug2eLapc8hxOPEoxJmHICBAIEBQIOAQEGgXclaXBwFTu?= =?us-ascii?q?CaVEZD4M+imIMFhUZgyKFFIVKdAI2AgYLAQEDCZVxAQE?= X-IronPort-AV: E=Sophos;i="5.85,346,1624320000"; d="scan'208,217";a="944502203" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Oct 2021 16:22:39 +0000 Received: from mail.cisco.com (xbe-aln-006.cisco.com [173.36.7.21]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 194GMdah007355 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 4 Oct 2021 16:22:39 GMT Received: from xfe-rtp-005.cisco.com (64.101.210.235) by xbe-aln-006.cisco.com (173.36.7.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 4 Oct 2021 11:22:39 -0500 Received: from xfe-rtp-003.cisco.com (64.101.210.233) by xfe-rtp-005.cisco.com (64.101.210.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 4 Oct 2021 12:22:38 -0400 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-003.cisco.com (64.101.210.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Mon, 4 Oct 2021 12:22:38 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Zy8E9Och044Em9xBmae+fXw73l9/GO3k4dfsykFCabWvvXlYTE/+ZMkPlG+zUZmNeJnMz9XGUx3SDbgkjMTsOwpdDkK53nvS6A2PuhMPZjxo0xzj9D2DkTeq8hZp1tpzzWoHl5R27tWPFb/95Svnxr+kvpV52Ww4C8A7r6qxPlGzi0xZHrLIVeqZbEhd7P/k6j42QDjeyvBYe9PGjt8RbnQ+mzMuBVKUSxWgPIqkyZ59S8Eos8UK8nid4iU25/QWIcVooPPpKZ4PKQRQEuIbTjZSRPm27fBTVVgDXcWwZ2ELjPSEkRLJNKlx7JBePhjJDrrIMC4EEC36QGp2v6JmIg== 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=p+leciV0ikB3wOAjsBG4jpZ61W2gCqwcteQ6YHq5QhA=; b=LMxmRV5hkVtWh6ou1U34TUquTuAA/UAm8Y1pVTI1LNDH48+2nLTXMNVtBuRkDcDAsjCQMg1T+LAK2wO9uCC8GTj9kphOomwjzFXnlK351o0q90yNs1aBcTz9y3zs0fW2j9bKBlShsk4H+3yeqzuSyzziCiWf59vyX7COXcf2sqxssfiSA08FGa2GUWjZE0FhCm7rlWCYdUdzd0aOEka3tnDh6h5uQpHPSE/co/anYbWvtYFCTtS7pLVNrdr5RdNgMWY1LABvLdyhwroGNiVWBq5q0IAExPEuMCXIXRaw+LkiqRVIYl6Hf1me1/7fo7zWlPz6LFuGItPan9G7BowYMQ== 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=p+leciV0ikB3wOAjsBG4jpZ61W2gCqwcteQ6YHq5QhA=; b=t8pZKDiI3lqFXAtb6CgzZzLxoUdVyI8+yhzSt37Xq0OqT20RbOHfagXTuoSjBUSjAGolpMsxDlvsnmy4t00HkIgjveipldr63v+h7uBinzqSmucXW0NtAfFpiF1T5DCMXRx4RpjklULFGRNxIPbnwVbHbSsBT6q/LelCxC81R28= Received: from CO6PR11MB5650.namprd11.prod.outlook.com (2603:10b6:5:35a::9) by CO6PR11MB5585.namprd11.prod.outlook.com (2603:10b6:5:356::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.14; Mon, 4 Oct 2021 16:22:37 +0000 Received: from CO6PR11MB5650.namprd11.prod.outlook.com ([fe80::6071:7cb6:d30e:b0d]) by CO6PR11MB5650.namprd11.prod.outlook.com ([fe80::6071:7cb6:d30e:b0d%4]) with mapi id 15.20.4566.022; Mon, 4 Oct 2021 16:22:37 +0000 From: "Francois Clad (fclad)" To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQCb3SEM Date: Mon, 4 Oct 2021 16:22:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7bc4a6c9-f9c8-4952-7c1c-08d987532e38 x-ms-traffictypediagnostic: CO6PR11MB5585: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: vAs08Kvx6l7+GCKELMkcE4uwdIhy1hwiJGh+dX06xJ/D2jpO5vKVLSLqugauxanf5a/60REePQ4+gnw/stMEhzGoGRE/lKRmnZCAZVi5TroQQ4BZeJyq8xZxeB2AW9vSNo0YW/YwxGDY/1Wi2sASykNoQC44EGAIhDP+krR9j/CbYaNGp0Y0pgRKDDvmO8rk9RD/c1SWbL1y4cNwEaO8ujBNxcY4l5DwmOFVEnQkwKFW+7xT0jMC62RbE7kGXExj6u7aiPMR2vWMn/KFoa3Uj+RG9/Tzpe0PEc1Z30vuUvZd9oJb76JXmm9duJmbitSYY/Gb2Ol82dl+jLMbSUrXmeeH+PWpNGUwWM/tz/+p75WwT7eUJ03SIxjqI3q9eYOwyhgqsSl0L/Rl/dJvRQtuD/A00qwpsZA1NXIQUP9FWWcALujUbdYzErgUxbuc1l1VOrt+ohi9Nkd0vAXp6CFC1V6BbH1PKNqgZzPg1XLIaIP/m3lHsNGrcM83PLhFP1QBO82cMLf3eDT7niNTs6UCCgA+A8iMWskeNatn7CkzLDO5TUM5GUiIhW6zAbWZdFQLETccqd8hd/bKsa9iOOOo20dIlzkNCxGK0hcbChiFSepdvVjWnFw3aMtFEbuIpBklHEjDd8LNhZdTwYP2Y8LWm2i9IVq0vLY1LahgWKGJx/GKpfT56pE1declerKyHFwvgCS6avlI6mJxDqV7EiI6RQwhW9nCniCT0qup8ysUxw9diCegsgHCcrpPPfRMCXU2u+O/j2z7rHAiPrRvTmAGOZX15jSUS6YETI7F/y+Dcns= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR11MB5650.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(8676002)(52536014)(9686003)(508600001)(186003)(53546011)(6506007)(86362001)(55016002)(166002)(33656002)(5660300002)(4326008)(83380400001)(91956017)(110136005)(7696005)(38100700002)(66556008)(8936002)(966005)(2906002)(122000001)(66946007)(38070700005)(76116006)(64756008)(71200400001)(66446008)(316002)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?38J/UD0zsSBGY6NhWbTHwaI/8scmWwZZQzB0k5UvJAniAegsPNmg0v83?= =?Windows-1252?Q?nzkDDyMGigxz6YlQy/jX6YgW7ykB7SYlXCOU6KEOYpiAICs9j/x9n5dG?= =?Windows-1252?Q?VAzRoOtwbaRlEDRJzQNZZAfHQDGcPK+fEmE/uqJBgyuRqVwHX5cngMsr?= =?Windows-1252?Q?7cywfLIRRl43Ne6NY60kl5iX9UNUEO87QeoRuTld2ZqHGdeoFdJShTky?= =?Windows-1252?Q?iB26Hd4qoo9eyOCmIIdTpRPcYWp/KLh14FQI3s03jlRlXVOLr5YSbBIN?= =?Windows-1252?Q?eoLZ7sOA6mmtoF4q3YBd+lAFGLNqp/lhbpVzIxMNx8eZAzodHxQuCn43?= =?Windows-1252?Q?QK5Cwf3NyfF3q7YgHqQbQGICL6kbjDl0kobJjdf+ujyMYzgnAdSlnnF0?= =?Windows-1252?Q?iumkeDxfyHpLw1ekwnuDmFxL1vbhUogj9jTauyd9+yHTuRWbUsI7XgQv?= =?Windows-1252?Q?7kt5NgW2TRYffZqUII23vk/VXD5aySXR6aAvI/24mqs6Za1h8PGw3it+?= =?Windows-1252?Q?AsogCQMFSksPku7ZOgUI8eCz8/hfWDOAQVoCjT0UNk6ieAWqvUfYacYc?= =?Windows-1252?Q?M/pYKia4sTy41SLyeuN2jJCwVgQXzqpx3OvLwQUhRjy+DFLVdKe7rjKj?= =?Windows-1252?Q?+QbXnlhq403PSg65Qt5Nan6M/BOaMu4L9D3UXEygeAbkhOgooaZgRhN3?= =?Windows-1252?Q?ZIiLsDtpdsfW26Ch9axemPIQkncv0yVAGI/TXObKE4uDDhfpKOkO9c79?= =?Windows-1252?Q?oDzvqDPUArpgpOZ0pPb819K3Nt3+M/MvH/Qe+wi9WqhE0gWW4/wJrMcL?= =?Windows-1252?Q?7NcKYsrH8FYa9gysBXMydB3VI0cMyElw0pSNLO55Vzc5Kv/y5SMttqhq?= =?Windows-1252?Q?pO/4HwvrVqvdpzIG2Ckdts7/OGceZUUNJTui8PkVWqtBPiEQfSA/jqdd?= =?Windows-1252?Q?nj6xVPYrLDxGExMSC3HE8SRh2EMS3WMkBYUCH7RZGzgadFjrlU8clNjZ?= =?Windows-1252?Q?C0Si9GHsfADsYt77sroN0VSuPJlMof8V/CFJi+AEf6qc++fWBrr4ugPG?= =?Windows-1252?Q?DjQ71JMQbBLh+ohrSfmhTO1S/RelhbuxJmK5JAkuyB2V+oesMgMXjeii?= =?Windows-1252?Q?yop+JKkAKaQOWvsku7RlRCwHkOxJWrWev5sDFN1Efxl7NKRC2FzOxnVW?= =?Windows-1252?Q?fd6T5JYD3vJJQ7fm6t6qyewJKTOFWrro7bDLX8a//VEZ7MraXUM/5tWK?= =?Windows-1252?Q?OYGVNiF4qWLxmImXUshjt4u9w0ajm6uxD2KVlmILuoykbT2PofGHn4DE?= =?Windows-1252?Q?8s7kmyiQDYOSKXlZ7Z7LBPV54myeET2xYW/lAw1jQZJhQNAaHWxvXnld?= =?Windows-1252?Q?kU9C0G7xJQ1SZfnD9BxP9WmkTnhtQHA9w1ndsScpSO5wPVKBHfPYK+xY?= =?Windows-1252?Q?NuNA0PB19x20t6nrB59OQN1+iu5/dJzp9ma7WZ1b6ey6ug94pKv89n+f?= =?Windows-1252?Q?uNOlERm/YkqXU1r2BnCvg7slLK0PmQ=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO6PR11MB5650F077EC5CD03F9FCB20D2ACAE9CO6PR11MB5650namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO6PR11MB5650.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7bc4a6c9-f9c8-4952-7c1c-08d987532e38 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2021 16:22:37.5382 (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: 3EsH/Qs1RG3qxndTY4H5v1EALwqVT4HoLi7ab/TUFLLxcfFZHXYREumaHXINP5ST X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR11MB5585 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.21, xbe-aln-006.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 04 Oct 2021 16:22:48 -0000 --_000_CO6PR11MB5650F077EC5CD03F9FCB20D2ACAE9CO6PR11MB5650namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I support the working group adoption. The C-SID solution described in this I-D builds on the SRv6 data plane defi= ned in RFC 8754 and 8986 to provide a flexible, SRv6-native compression sol= ution. It has been implemented by several vendors, with interoperability te= sting reported in section 11. Furthermore, the SRComp design team analysis demonstrated that this solutio= n meets all the compression requirements and provides the best data plane e= fficiency among all the evaluated solutions. Thanks, Francois From: spring on behalf of James Guichard Date: Friday, 1 October 2021 at 16:05 To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a =93living=94 document; it may change as it goes thr= ough review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_CO6PR11MB5650F077EC5CD03F9FCB20D2ACAE9CO6PR11MB5650namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I support= the working group adoption.

&nbs= p;

The C-SID= solution described in this I-D builds on the SRv6 data plane defined in RF= C 8754 and 8986 to provide a flexible, SRv6-native compression solution. It= has been implemented by several vendors, with interoperability testing reported in section 11.

&nbs= p;

Furthermo= re, the SRComp design team analysis demonstrat= ed that this solution meets all the= compression requirements and provides the best data plane efficiency among= all the evaluated solutions.

&nbs= p;

Thanks,

Francois<= o:p>

&nbs= p;

From: spring <spring-b= ounces@ietf.org> on behalf of James Guichard <james.n.guichard@future= wei.com>
Date: Friday, 1 October 2021 at 16:05
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

 

The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a sol= ution for SRv6 compression.

 

The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document = that has multiple SRv6 Endpoint behaviors.
  2. The document is a =93livi= ng=94 document; it may change as it goes through review and analysis by the= SPRING working group.
  3. All open discussion point= s raised on our mailing list MUST be addressed BEFORE said document is allo= wed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maint= ained by the document editor in conjunction with the chairs.
  4. If this document is adopt= ed by the working group, the chairs specify as part of the adoption call th= at the following text describing an open issue be added to the document in the above-described open issues section:
    • "Given that the working group has said that it wants to standar= dize one data plane solution, and given that the document contains multiple= SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution obj= ective.".

 

Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open d= iscussion points you would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

--_000_CO6PR11MB5650F077EC5CD03F9FCB20D2ACAE9CO6PR11MB5650namp_-- From nobody Mon Oct 4 09:49:33 2021 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 2ADDC3A09D0; Mon, 4 Oct 2021 09:49:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fDwoQekW6hNQ; Mon, 4 Oct 2021 09:49:24 -0700 (PDT) Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (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 4ABAA3A09BE; Mon, 4 Oct 2021 09:49:24 -0700 (PDT) Received: by mail-pg1-x536.google.com with SMTP id v11so4523303pgb.8; Mon, 04 Oct 2021 09:49:24 -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=9+PmI39WBg6kGOUrdVpLuPL3ykKz39q0lmDMeqxqqYQ=; b=UCQSQugyr4Z50ydWSJ0B2aAZcCm0RYy37obvrqa6YluwNh5sPorsQIsFnDA5SJMihU N1JoU3YcEYXPLzgkRSMl1Ryd08hoCw+/KDs3JDkYeYPERqzaY73sOTCIl1f+g8b8aq99 s72xJez8nIic1LOqIHdKVY32P0yJ47pNemKPN6VTciMTyevWbtQMOwYNyY8LdqARTRcE pDlnuK4FkS5U4wkoAYAuuBh9xLDY9UeXCRgWE2MPm0TXUkV6doB0aRN/58ultcR+liAi UUi/vX+Q5C9cbj/twp5EhUOfGe+Aps/EC9SgyveARMfjy3ebQIUDqd+Hadmly6dxlawR CUYQ== 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=9+PmI39WBg6kGOUrdVpLuPL3ykKz39q0lmDMeqxqqYQ=; b=hy3A7QwnkWZR+NU5Hvt3A/RTrIzAusU3g3yuL5BDP5hGQN+viwJ50XnSpeYOeYxgSj upwUNy124BIioS0qTEr9gP0G/wL6JRFqtAjLt2p/kzBw7Pc9q+gsTres5G5wLHWJZ7AW rW3ORFAxDjtJdRHjdLuwkfMVwF841h9nK1JCf9aFKZ0k44YvQVjyrhVroOYnN5D7eS3e bkF51Xe/Xez1M3bMysh2Pwa8PH2FfAy2/ZHARIROcvbjjvVLtlYOzOC+tLZWAsTVa3UA fcwxUwVkIsKfOJ4H3Jx2RfGSFk1Qg0+7P6bD+Da2MrC2faRe3zbyAWH3C9O4tt7bA0Z7 dfcA== X-Gm-Message-State: AOAM532CxRK/EeDIcT7g1/ImRvXnBlnRJauFcketyUwPoRjp5g02moTu L7pyHJi2OB9B+WOvoLQDzoiqJWRjDZhIgXi1svlzEzVF X-Google-Smtp-Source: ABdhPJz1fzen7CF7foyAsA9obmwIB187EUyZqb9lJ014VeZe5z/p4tHR42xKGcRiMcOtcZaALtSpLoinoS197/h81xg= X-Received: by 2002:aa7:8c43:0:b0:44c:4f90:1c68 with SMTP id e3-20020aa78c43000000b0044c4f901c68mr10050896pfd.76.1633366163243; Mon, 04 Oct 2021 09:49:23 -0700 (PDT) MIME-Version: 1.0 References: <03B8E50C-B8FA-4DCB-A4E4-91C33590E57C@tony.li> In-Reply-To: From: Gyan Mishra Date: Mon, 4 Oct 2021 12:49:12 -0400 Message-ID: To: James Guichard Cc: Andrew Alston , SPRING WG , Tony Li , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f2c3ea05cd89b177" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 04 Oct 2021 16:49:31 -0000 --000000000000f2c3ea05cd89b177 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Chairs Was there any there any thoughts of maybe issue an adoption call for the G-SRv6 draft itself or uSID draft itself as an option, one or the other or separate adoption call for both drafts as they are both SRv6 compliant and can stand on their own independently and clearly meet all the compression requirements. That would have taken care of the CSID 2 flavor and the one data plane solution WG consensus dilemma call. I think the big question is what does combining the two distinctly different solutions from two different vendors, how that makes sense from an POV of an operator and industry standpoint. Unless one can benefit from the other or if their are inter dependencies between the two that one is not a complete solution without benefit from the other. That is not the case here. Kind Regards Gyan On Mon, Oct 4, 2021 at 11:13 AM James Guichard < james.n.guichard@futurewei.com> wrote: > Hi Gyan, > > > > Please see the chairs response to the email from Andrew Alston. > > > > Yours, > > > > Jim, Bruno & Joel. > > > > *From:* Gyan Mishra > *Sent:* Friday, October 1, 2021 7:26 PM > *To:* Tony Li > *Cc:* Andrew Alston ; > James Guichard ; SPRING WG < > spring@ietf.org>; spring-chairs@ietf.org > *Subject:* Re: [spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > > > > > Dear WG chairs, > > > > I agree with Greg Mirsky that the adoption guidelines are confusing and > contradictory. > > > > Bullet #1 states that by expressing support for adoption the WG member i= s > agreeing to adoption of a document that has multiple SRv6 compression > solutions. > > > > On the other hand bullet #4 states that if the draft is adopted that the > following text excerpt below should be added to as an open issue issues > section. > > > > > > - "Given that the working group has said that it wants to standardize > one data plane solution, and given that the document contains multiple= SRv6 > EndPoint behaviors that some WG members have stated are multiple data = plane > solutions, the working group will address whether this is valid and > coherent with its one data plane solution objective.". > > > > This sentence is very confusing as the WG chairs agree that the WG has > consensus on a single solution to avoid interoperability, and the WG chai= rs > acknowledge that some WG members feel that the multiple flavors are > actually multiple solutions, how is it possible that the WG would address > that this is as valid and coherent with one date plane solution as the > objective. The valid and coherent part of how a multiple data plane > solution or flavor meets the single data plane objective is contradictory= . > > > > I believe what is stated here by the chairs is exactly what should have > been cleared up prior to the adoption call, but now as the adoption call > has started would be cleared up during the adoption call process. This = is > somewhat of a chess game as to which way to have proceeded, but I think > getting this cleared up prior to the call for adoption would have been > better for the WG. > > > > All WG members that feel strongly that the two endpoint flavors are two > distinctly different solutions will stick to their guns and support not > adopting the document. > > > > All WG members that are Ok with two solutions versus a single SRV6 > compression solution will chose to adopt the draft. > > > > The down side of not resolving this issue prior to adoption call is that > there is a chance the many that felt strongly for a single solution as ri= sk > of interoperability issues as all vendors due to cost may not want to > implement multiple compression solutions and may not all pick the same > compression solution. > > > > So there could be a unanimous vote to not adopt as this goes against the > WG consensus on a single data plane solution. > > > > I agree that is not a major risk going this route as the draft would be > kicked back to the authors to revise and pick one of the flavors to put > forward for adoption. > > > > The flip side is we are back to the drawing board with the DT on WG > consensus on a compression solution to agree to for an adoption call. > > > > Kind Regards > > > > Gyan > > > > On Fri, Oct 1, 2021 at 4:55 PM Tony Li wrote: > > > > +1 > > > > I object to the adoption. > > > > Tony > > > > > > On Oct 1, 2021, at 1:43 PM, Andrew Alston < > Andrew.Alston=3D40liquidtelecom.com@dmarc.ietf.org> wrote: > > > > Just to add to this, > > > > I am one of the people who clearly stated that I didn=E2=80=99t think a s= ingle > solution was the right answer here =E2=80=93 and I stated my reasoning cl= early on > this list. I still believe that =E2=80=93 however =E2=80=93 I recognize = that the > foundation of the IETF is found in the bottom up consensus approach =E2= =80=93 and > when the working group has demonstrated such clear consensus =E2=80=93 to= defy that > =E2=80=93 is to defy what makes the IETF the IETF. > > > > So =E2=80=93 While I still believe in multiple solutions =E2=80=93 irresp= ective of that =E2=80=93 > I find this call appalling =E2=80=93 because as much as I believe in mult= iple > solutions =E2=80=93 the working group consensus should be sacrosanct. > > > > Andrew > > > > > > *From: *Andrew Alston > *Date: *Friday, 1 October 2021 at 23:21 > *To: *James Guichard , SPRING WG < > spring@ietf.org> > *Cc: *spring-chairs@ietf.org > *Subject: *Re: WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > > Sorry =E2=80=93 but =E2=80=93 I=E2=80=99m a little confused here. > > > > Because the way I look at this =E2=80=93 the working group clearly stated= that > they wished for a single behavior =E2=80=93 and this =E2=80=93 does not d= eliver that =E2=80=93 it > is two separate behaviors. As such =E2=80=93 I see this call for adoptio= n =E2=80=93 > irrespective of the merits or lack thereof of the draft, as a clear > defiance of the stated will of the working group. > > > > This is simply does not fit into the definition of bottom up approach in > my opinion =E2=80=93 and if this is the way that the chairs wish to proce= ed =E2=80=93 then > the only way to do that and still fit within the bottom up approach is to > first ask this working group for its consensus to deviate from the single > behacvior approach that the working group agreed to. > > > > As such =E2=80=93 I must strongly and unequivocally object to this call = for > adoption > > > > Andrew > > > > *From: *spring on behalf of James Guichard < > james.n.guichard@futurewei.com> > *Date: *Friday, 1 October 2021 at 17:05 > *To: *SPRING WG > *Cc: *spring-chairs@ietf.org > *Subject: *[spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > > Dear WG: > > > > The chairs would like to express their appreciation for all the responses > received to our emails with reference to how the working group wishes to > move forward with respect to a solution for SRv6 compression. > > > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > as > the basis for its compression standardization work. That is part of what > this email attempts to confirm. > > > > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > but > with some clear guidelines as follows. By expressing support for adoption > of this document you are fully aware of and are acknowledging that: > > > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change = as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the working > group to publication. A list of these discussion points will be docume= nted > in the WG document and maintained by the document editor in conjunctio= n > with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text describin= g an > open issue be added to the document in the above-described open issues > section: > > > - "Given that the working group has said that it wants to standardize > one data plane solution, and given that the document contains multi= ple SRv6 > EndPoint behaviors that some WG members have stated are multiple da= ta plane > solutions, the working group will address whether this is valid and > coherent with its one data plane solution objective.". > > > > Please consider the above guidelines as you decide on whether to support > or not this WG adoption. Please express clearly your reasoning for > support/non-support as well as any open discussion points you would like > addressed should the document be adopted into the working group. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > -- > > > > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com * > > *M 301 502-1347* > > > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --000000000000f2c3ea05cd89b177 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Dear Chairs=C2=A0

Was there any there any thoughts of= maybe issue an adoption call for the G-SRv6 draft itself or uSID draft its= elf as an option, one or the other or separate adoption call for both draft= s as they are both SRv6 compliant and can stand on their own independently = and clearly meet all the compression requirements.
<= br>
That would have taken care of the CSID 2 flavor = and the one data plane solution WG consensus dilemma call. =C2=A0

I think the big question is what = does combining the two distinctly different solutions from two different ve= ndors, how that makes sense from an POV of an operator and industry standpo= int.=C2=A0 Unless one can benefit from the other or if their are inter depe= ndencies between the two that one is not a complete solution without benefi= t from the other. =C2=A0

That is not the case here.

Kind Regards=C2=A0

G= yan

On Mon, Oct 4, 2021 at 11:48 AM Greg= Mirsky <gregimirsky@gmail.com<= /a>> wrote:

On Mon, Oct 4, 2021 at 8:10 AM James Guichard <james.n.guichard@futur= ewei.com> wrote:

Andrew,

=C2=A0

As stated in our email of September 9th, the chairs = communicated that the working group reached rough (quite clear) consensus f= or standardizing one data plane solution to compress segment routing over I= Pv6. In addition to this there was an inclination toward using the CSID document as the basis for our work in= this area. The chairs recognized that there was however disagreement as to= whether this document, having multiple SRv6 EndPoint behaviors, could be c= onsidered consistent with the working group consensus for a single data plane solution. This issue quite clearly= needed to be addressed, and the chairs, recognizing that the working group= is keen to make progress in this area, had the option of trying to resolve= the issue prior to issuing an adoption call, or give the working group the opportunity to express their opinions = as part of a call for adoption.

=C2=A0

Those who feel that we need to resolve the consisten= cy issue before adoption, as with those who think this is not a good basis = for the WG work, are free and expected to object to the WG adopting the doc= ument. That is distinct from objecting to the chairs issuing the adoption call.

=C2=A0

In essence, the chairs have combined the question of= when to resolve consistency and the question of whether this document is a= good basis for the WG into one call.

=C2=A0

Yours,

=C2=A0

Jim, Bruno & Joel

=C2=A0

=C2=A0

From: Andrew Alston <Andrew.Alston@liquidtelecom= .com>
Sent: Friday, October 1, 2021 4:21 PM
To: James Guichard <james.n.guichard@futurewei.com>; SPRING WG &l= t;spring@ietf.org&= gt;
Cc: spri= ng-chairs@ietf.org
Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-com= pression/

=C2=A0

Sorry =E2=80=93 but =E2=80=93 I=E2=80=99m a little c= onfused here.

=C2=A0

Because the way I look at this =E2=80=93 the working= group clearly stated that they wished for a single behavior =E2=80=93 and = this =E2=80=93 does not deliver that =E2=80=93 it is two separate behaviors= .=C2=A0 As such =E2=80=93 I see this call for adoption =E2=80=93 irrespecti= ve of the merits or lack thereof of the draft, as a clear defiance of the stated will of th= e working group.

=C2=A0

This is simply does not fit into the definition of b= ottom up approach in my opinion =E2=80=93 and if this is the way that the c= hairs wish to proceed =E2=80=93 then the only way to do that and still fit = within the bottom up approach is to first ask this working group for its consensus to deviate from the single behacvior appro= ach that the working group agreed to.

=C2=A0

As such =E2=80=93 I must =C2=A0strongly and unequivo= cally object to this call for adoption

=C2=A0

Andrew

=C2=A0

From: spring <spring-bounces@ietf.org> on behalf of James Guichard <james.n.guichard@futurewei.com>
Date: Friday, 1 October 2021 at 17:05
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org <spring-chair= s@ietf.org>
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

=C2=A0

The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

=C2=A0

The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

=C2=A0

Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

=C2=A0

  1. The SPRING working group is adopting a docume= nt that has multiple SRv6 Endpoint behaviors.
  2. The document is a =E2=80= =9Cliving=E2=80=9D document; it may change as it goes through review and an= alysis by the SPRING working group.
  3. All open discussion points= raised on our mailing list MUST be addressed BEFORE said document is allow= ed to progress from the working group to publication. A list of these discu= ssion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
  4. If this document is adopte= d by the working group, the chairs specify as part of the adoption call tha= t the following text describing an open issue be added to the document in t= he above-described open issues section:
    • "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

=C2=A0

Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

=C2=A0

Thanks!

=C2=A0

Jim, Bruno & Joel

=C2=A0

=C2=A0

_______________________________________________
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

On Mon, Oct 4, 2021 at 11:13 AM James Guichard <james.n.guichard@futurewei.com> wr= ote:

Hi Gyan,

=C2=A0

Please see the chairs response to the email from And= rew Alston.

=C2=A0

Yours,

=C2=A0

Jim, Bruno & Joel.

=

=C2=A0

From: Gyan Mishra <hayabusagsm@gmail.com>
Sent: Friday, October 1, 2021 7:26 PM
To: Tony Li <tony.li@tony.li>
Cc: Andrew Alston <Andrew.Alston=3D40liquidtelecom.com@dmarc.ietf.or= g>; James Guichard <james.n.guichard@futurewei.com>; SPRING WG &l= t;spring@ietf.org&= gt;; spring-cha= irs@ietf.org
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/

=C2=A0

=C2=A0

Dear WG chairs,

=C2=A0

I agree with Greg Mirsky that the adoption guideline= s are confusing and contradictory. =C2=A0=C2=A0

=C2=A0

Bullet =C2=A0#1 states that by expressing support fo= r adoption the WG member is agreeing to adoption of a document that has mul= tiple SRv6 compression solutions. =C2=A0

=C2=A0

On the other hand bullet #4 states that if the draft= is adopted that the following text excerpt below should be added to as an = open issue issues section. =C2=A0

=C2=A0

=C2=A0

  • "Given that the working group has said that it wants to standardize on= e data plane solution, and given that the document contains multiple SRv6 E= ndPoint behaviors that some WG members have stated are multiple data plane = solutions, the working group will address whether this is valid and coherent with its one data plane solution object= ive.".

=C2=A0

This sentence is very confusing as the WG chairs agr= ee that the WG has consensus on a single solution to avoid interoperability= , and the WG chairs acknowledge that some WG members feel that the multiple= flavors are actually multiple solutions, how is it possible that the WG would address that this is as valid and coh= erent with one date plane solution as the objective.=C2=A0 The valid and co= herent part of how a multiple data plane solution or flavor meets the singl= e data plane objective is contradictory.

=C2=A0

=C2=A0I believe what is stated here by the chairs is= exactly what should have been cleared up prior to the adoption call, but n= ow as the adoption call has started =C2=A0would be cleared up during the ad= option call process.=C2=A0 This is somewhat of a chess game as to which way to have proceeded, but I think getting this cle= ared up prior to the call for adoption would have been better for the WG.

=C2=A0

All WG members that feel strongly that the two endpo= int flavors are two distinctly different solutions will stick to their guns= and support not adopting the document.

=C2=A0

All WG members that are Ok with two solutions versus= a single SRV6 compression solution will chose to adopt the draft. =C2=A0

=C2=A0

The down side of not resolving this issue prior to a= doption call =C2=A0is that there is a chance the many that felt strongly fo= r a single solution as risk of interoperability issues as all vendors due t= o cost may not want to implement multiple compression solutions and may not all pick the same compression solution. = =C2=A0

=C2=A0

So there could be a unanimous vote to not adopt as t= his goes against the WG consensus on a single data plane solution.

=C2=A0

I agree that is not a major risk going this route as= the draft would be kicked back to the authors to revise and pick one of th= e flavors to put forward for adoption. =C2=A0=C2=A0

=C2=A0

The flip side is we are back to the drawing board wi= th the DT on WG consensus on a compression solution to agree to for an adop= tion call.

=C2=A0

Kind Regards=C2=A0

=C2=A0

Gyan

=C2=A0

On Fri, Oct 1, 2021 at 4:55 PM Tony Li <tony.li@tony.li> wrote= :

=C2=A0

+1

=C2=A0

I object to the adoption.

=C2=A0

Tony

=C2=A0



On Oct 1, 2021, at 1:43 PM, Andrew Alston <Andrew.Alston=3D40liquidtelecom.com@dmarc.ietf.org> wrote:=

=C2=A0

Just to add to this,

=C2=A0

I am one of the people who clearly stated that I did= n=E2=80=99t think a single solution was the right answer here =E2=80=93 and= I stated my reasoning clearly on this list.=C2=A0 I still believe that =E2= =80=93 however =E2=80=93 I recognize that the foundation of the IETF is found in the bottom up consensus approach =E2=80=93 and when the working g= roup has demonstrated such clear consensus =E2=80=93 to defy that =E2=80=93= is to defy what makes the IETF the IETF.

=C2=A0

So =E2=80=93 While I still believe in multiple solut= ions =E2=80=93 irrespective of that =E2=80=93 I find this call appalling = =E2=80=93 because as much as I believe in multiple solutions =E2=80=93 the = working group consensus should be sacrosanct.

=C2=A0

Andrew

=C2=A0

=C2=A0

From:=C2=A0Andre= w Alston <Andrew.Alston@liquidtelecom.com= >
Date:=C2=A0Friday, 1 October 2021 at 23:21
To:=C2=A0James Guichard <james.n.guichard@= futurewei.com>, SPRING WG <spring@ietf.org<= /a>>
Cc:=C2=A0spring-chairs@ietf.org=C2=A0<<= a href=3D"mailto:spring-chairs@ietf.org" target=3D"_blank">spring-chairs@ietf.org>
Subject:=C2=A0Re: WG Adoption call for=C2=A0https://data= tracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Sorry =E2=80=93 but =E2=80=93 I=E2=80=99m a little c= onfused here.

=C2=A0

Because the way I look at this =E2=80=93 the working= group clearly stated that they wished for a single behavior =E2=80=93 and = this =E2=80=93 does not deliver that =E2=80=93 it is two separate behaviors= .=C2=A0 As such =E2=80=93 I see this call for adoption =E2=80=93 irrespecti= ve of the merits or lack thereof of the draft, as a clear defiance of the stated will of th= e working group.

=C2=A0

This is simply does not fit into the definition of b= ottom up approach in my opinion =E2=80=93 and if this is the way that the c= hairs wish to proceed =E2=80=93 then the only way to do that and still fit = within the bottom up approach is to first ask this working group for its consensus to deviate from the single behacvior appro= ach that the working group agreed to.

=C2=A0

As such =E2=80=93 I must =C2=A0strongly and unequivo= cally object to this call for adoption

=C2=A0

Andrew

=C2=A0

From:=C2=A0sprin= g <spring-b= ounces@ietf.org> on behalf of James Guichard <james.n.guichard@futurewei= .com>
Date:=C2=A0Friday, 1 October 2021 at 17:05
To:=C2=A0SPRING WG <spring@ietf.org>
Cc:=C2=A0spring-chairs@ietf.org <spring-chairs@ietf.org>
Subject:=C2=A0[spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/

Dear WG:

=C2=A0

The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

=C2=A0

The apparent inclination of the working group is to = use=C2=A0https://datatracker.ietf.org/doc/draft-filsfilscheng-s= pring-srv6-srh-compression/=C2=A0as the basis for its compression standardization work. That is part of what t= his email attempts to confirm.

=C2=A0

Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th=C2=A0for=C2=A0= https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/=C2=A0but with some clear guidelines as follows. By expressing support for adoption = of this document you are fully aware of and are acknowledging that:<= u>

=C2=A0

  1. The SPRING working group is adopting a document tha= t has multiple SRv6 Endpoint behaviors.
  2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change a= s it goes through review and analysis by the SPRING working group.
  3. All open discussion points raised on our = mailing list MUST be addressed BEFORE said document is allowed to progress = from the working group to publication. A list of these discussion points wi= ll be documented in the WG document and maintained by the document editor in conjunction wi= th the chairs.
  4. If this document i= s adopted by the working group, the chairs specify as part of the adoption = call that the following text describing an open issue be added to the docum= ent in the above-described open issues section:
    • "Given that the working group has said that it= wants to standardize one data plane solution, and given that the document = contains multiple SRv6 EndPoint behaviors that some WG members have stated = are multiple data plane solutions, the working group will address whether this is valid= and coherent with its one data plane solution objective.".<= /u>

=C2=A0

Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

=C2=A0

Thanks!

=C2=A0

Jim, Bruno & Joel

=C2=A0

=C2=A0

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

=C2=A0

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

--

= <= /span>

Gyan Mishra

Network Solutions Architect=C2=A0

Email gyan.s.mishr= a@verizon.com

M 301 = 502-1347

=C2=A0

--
--000000000000f2c3ea05cd89b177-- From nobody Mon Oct 4 09:55:15 2021 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 931523A0966 for ; Mon, 4 Oct 2021 09:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ig7IxarEbbdi for ; Mon, 4 Oct 2021 09:55:07 -0700 (PDT) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 0C8533A0965 for ; Mon, 4 Oct 2021 09:55:07 -0700 (PDT) Received: by mail-ed1-x532.google.com with SMTP id r18so67204562edv.12 for ; Mon, 04 Oct 2021 09:55:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=0Ay9eQB1GU0CLWy9VZmE+ATZpqjwNtXTK0omTlKGtV0=; b=mC8ZLMvX2KZ7yz70xs+Af4Zgevk+CqRNba8j5IZgJjJQcFJkVogWmYDyp6kTFnnOTj FqhN/gdGPZ/8EpggHJupSe5z6fy00jJX9qeYFAt3wBdeeFd5NogIvdCeY2t5dGVJqCqG SRjc5vXTKkSI2yHzT0aE1doN5jmSl5lTd90X3I+s0A4EchSdAmT1/1QyL9JvftNHZ4uI 6IKHWb9blRQNdwRfrSTc30y9yqQrklenmFH/skkllk+D1oM7gIMBiP3DvU2NAPcLPGmx yoL7Qky1VD0wz1Xn9g60HKfj1t5NB3qs1WUNizY1qunAPbaxfb+QmRMgXv0ltgDu5RW6 BtIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=0Ay9eQB1GU0CLWy9VZmE+ATZpqjwNtXTK0omTlKGtV0=; b=S/RlVT9dl4J9kbpgfOevfOaIjBYbuMVwoAnBtpOMQccwSxgWL8XlGN4lsC0nDOzyJD SneWTY5gquIrMq4G9ARu4shkA8bWodZ3W+2rDymQk4niEF4ahAd4bbsB8r7vH/igd/im ezeHnpMspCo4EreT8orr2+mlEd2uUVz4q/FrguETMv7Yh76PlVXTlRX6gU5ibBwQ+ZwQ 2pLWWwIlKNW2vjVxC4KkU/R3H5QHOL8WI+nElQ2P/cMX2aLlMVScvuao1BQJv+S+DrJc ONN31UDVk7eqGQhO7mfnT4PIQAP+dmclr1648pM4YwkWH0qOCqe4fT01nfw/Jo57BeGp wdOg== X-Gm-Message-State: AOAM531lw2TnPjsOEQb41rLEIdrbYC4xzXnVJL2vsLRD58IkeLwY/b+F hyTbXCao1bWJNOt1sxZ7eLaASl6QIJY= X-Google-Smtp-Source: ABdhPJydfbBBIJFYXoSaJf092HPnOCSvcvFCyJhGlDwFCqdbbqJlid+7PqJ+dnhV+zaO/lVjCcSkBw== X-Received: by 2002:a17:907:9870:: with SMTP id ko16mr1311326ejc.99.1633366480986; Mon, 04 Oct 2021 09:54:40 -0700 (PDT) Received: from smtpclient.apple ([2001:67c:1270:0:cd82:2893:7a11:7a16]) by smtp.gmail.com with ESMTPSA id kw10sm6667531ejc.71.2021.10.04.09.54.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Oct 2021 09:54:40 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Mike Simpson Mime-Version: 1.0 (1.0) Date: Mon, 4 Oct 2021 17:54:35 +0100 Message-Id: <760EAEA2-91D5-443A-BA76-5CE970E0687E@gmail.com> References: <195e9542-c87d-c912-01e4-4b25b6c35e97@lear.ch> Cc: SPRING WG In-Reply-To: <195e9542-c87d-c912-01e4-4b25b6c35e97@lear.ch> To: Eliot Lear X-Mailer: iPhone Mail (19A344) Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 04 Oct 2021 16:55:13 -0000 Nope. I have no opinion on SRH. If it solves some networks problem or improv= es functionality then it should proceed through standards to production.=20 My issue will always be that causing control plane punts and possible except= ions in old code in other peoples networks because you want to violate RFC82= 00, want to save the overhead of encapsulation and haven=E2=80=99t specified= a workable mechanism to insure no leakage of your malformed packets out of y= our administrative domain is selfish at best.=20 Anyone can do whatever they like on their network but it used to be that it w= as beholden on us to be good neighbours. We should stop creating tools that c= ontain =E2=80=9Cspew =E2=80=98bogus=E2=80=99 packets onwards=E2=80=9D settin= gs.=20 > On 4 Oct 2021, at 05:22, Eliot Lear wrote: >=20 > =EF=BB=BFAs Robert wrote, I think your issue is not with this draft, but w= ith SRH. >=20 >> On 04.10.21 02:26, Michael Simpson wrote: >> Generally it's any proposition that violates RFCs that are in place in lo= ng deployed hardware but where there is no sufficient mechanism to not leak t= he packets onto other peoples networks >>=20 >> In this instance its a knee jerk response to "what=E2=80=99s the worst th= at could happen" after 40 years experience on connected networks, not that p= restel was that connected. >>=20 >>>> On 3 Oct 2021, at 15:22, Eliot Lear wrote: >>>=20 >>> I'm struggling to understand whether your issue is with this draft or wi= th any extension header. >>>=20 >>> Eliot >>>=20 >>> On 03.10.21 15:17, Mike Simpson wrote: >>>> Given that every time a vendor suggests altering the fundamentals of th= e ipv6 header the reason given for not just using encapsulation and therefor= e avoiding upsetting the 2 decades worth of running kit is to save the few b= ytes of overhead it would produce. >>>>=20 >>>> 1) Do we not have enough bogus packets on the internets. >>>> And >>>> 2) just because you can=E2=80=99t define the =E2=80=9Charm it will caus= e=E2=80=9D doesn=E2=80=99t mean that it=E2=80=99s not going to cause harm. >>>>=20 >>>> Man generally seems quite fallible imho. >>>>=20 >>>>=20 >>>>> On 3 Oct 2021, at 05:13, Brian E Carpenter >>>>> wrote: >>>>>=20 >>>>> =EF=BB=BFRon, >>>>>=20 >>>>> The first sentence cites RFC8402 which unambiguously describes SR as a= >>>>> limited domain protcol (limited to an "SR domain", that is.) >>>>>=20 >>>>> So within such a domain, this describes using 128 bit quantities calle= d >>>>> Segment Identifiers that in some cases, but apparently not in the form= ats >>>>> defined here, has the same structure as an IP address. >>>>>=20 >>>>> Does that harm the Internet, even if it leaks? It might disappoint the= >>>>> sender, as any sender of a bogus packet is disappointed, but apart fro= m that, >>>>> who is damaged? >>>>>=20 >>>>> Regards >>>>> Brian Carpenter >>>>>=20 >>>>>=20 >>>>>> On 02-Oct-21 09:34, Ron Bonica wrote: >>>>>> Folks, >>>>>>=20 >>>>>> =20 >>>>>> Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three n= ew >>>>>>=20 >>>>> SID types that can occupy the Destination Address field of an IPv6 hea= der. See Sections 4.1, 4.2, and 4.3 of the draft for details. >>>>>=20 >>>>>> =20 >>>>>> The SPRING WG has issued a call for adoption for this draft. >>>>>>=20 >>>>>> =20 >>>>>> It is not clear that these SID types can be harmonized with the IPv6 a= ddressing architecture. >>>>>>=20 >>>>>> =20 >>>>>> Does anyone have an opinion? >>>>>>=20 >>>>>> =20 >>>>>> = Ron >>>>>>=20 >>>>>> =20 >>>>>>=20 >>>>>> Juniper Business Use Only >>>>>>=20 >>>>>>=20 >>>>>> -------------------------------------------------------------------- >>>>>> IETF IPv6 working group mailing list >>>>>>=20 >>>>>> ipv6@ietf.org >>>>>>=20 >>>>>> Administrative Requests: >>>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>>>=20 >>>>>> -------------------------------------------------------------------- >>>>>>=20 >>>>>>=20 >>>>> -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list >>>>>=20 >>>>> ipv6@ietf.org >>>>>=20 >>>>> Administrative Requests: >>>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>>=20 >>>>> -------------------------------------------------------------------- >>>>>=20 >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>>=20 >>>> ipv6@ietf.org >>>>=20 >>>> Administrative Requests: >>>> https://www.ietf.org/mailman/listinfo/ipv6 >>>>=20 >>>> -------------------------------------------------------------------- >>>>=20 >>>>=20 >>=20 >=20 From nobody Mon Oct 4 10:00:01 2021 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 6FE9D3A0966 for ; Mon, 4 Oct 2021 09:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.986 X-Spam-Level: X-Spam-Status: No, score=-1.986 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=liquidtelecom.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 WRKpoHfXPCdr for ; Mon, 4 Oct 2021 09:59:53 -0700 (PDT) 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 C33843A09BE for ; Mon, 4 Oct 2021 09:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquidtelecom.com; s=mimecast20210406; t=1633366785; 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=CDQNCEb6Bqvu5pXxBezPi4S+qev/uF/fe6lPcrAxHvM=; b=J0eDKv2cMNNjKJNNyEk6ZQ0tVw0mtYDbK80u6CrpuMo8HMc2F2vyJ2+kXuz5mFXxc2sKa5 KT6+6TcPug6GrfINWogKMljXy5xEXmHO7gzjDpCIPw8b3IMrppkkoHAWaAWAmb2tEeaR4H yTPJcq6i0VPfFhpO4RPr23NaG2SzA5E= Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05lp2112.outbound.protection.outlook.com [104.47.18.112]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-180-Yj97bzO-OoiloSLlr5hFjQ-1; Mon, 04 Oct 2021 17:59:42 +0100 X-MC-Unique: Yj97bzO-OoiloSLlr5hFjQ-1 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com (2603:10a6:20b:346::6) by AS8PR03MB7602.eurprd03.prod.outlook.com (2603:10a6:20b:34d::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.16; Mon, 4 Oct 2021 16:59:40 +0000 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9]) by AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9%5]) with mapi id 15.20.4566.022; Mon, 4 Oct 2021 16:59:40 +0000 From: Andrew Alston To: Gyan Mishra , James Guichard CC: SPRING WG , Tony Li , "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQANZx9MAADOxzsAAHjagAAFRqSAAIV5d/AAA4qHAAAGpsKA Date: Mon, 4 Oct 2021 16:59:40 +0000 Message-ID: <502AD3A7-7352-471C-B17F-0DBD57B771D7@liquidtelecom.com> References: <03B8E50C-B8FA-4DCB-A4E4-91C33590E57C@tony.li> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.53.21091200 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 69242393-7a6e-4bb6-48e8-08d987585b40 x-ms-traffictypediagnostic: AS8PR03MB7602: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: j3OcIJfqgiIY5LEiDvuD7/HdfcxlgOROPhrKwrr8m4MqcW76U8I1Hcu+KblAxLEQtqkRL2M9W8BTjXOpgXSg1Qv51d0MOQNb24QP0fu09ffSGKU1uae3TaGhrx7Z0w1Ue20Ilm7K2719WHAltRZm/fURYVuvWIWhAis8Epg5+q5342SjBh7gJUQejOWvhFtMDJCT5B/GU1TBdgVgzqwl2DDOOXa1wGxfEftGSefKG7bLnG/heVev64ccSRxQCk0pAp5kwXlbWkCRqwq6loEOzVyjsui9jvlkFL74pTTNwOp12f9dv7/cwNk13hSsTjAjwQV7rIKmv2tsoKDIDHSldnY/5aQhJ9OKTSyOb2M3x6ena4WYTbzTYTIFUu4EkRppTaTPje1f6HGW9jM6YIkgi39vyryy3i6hTY2q/akjxcyc0unMfFLjbtLMTUWLRUaN+sm2Pg5d6cm5uJ5PxWTxEYICVZxZg/blZWg343QM8jduuJfhAtjbhgu/QPeLOaXln13TWUduLbh10cJqKyXo+U535E7Jk3Hz5yW57oCc084GxMqwKvD7+4EeiAM/8C2W5h43cdJaR6wQDGRQABzTxkBiKHgFBp1n6PoRMyIEl+6r5GZWB6wcG+EI/+FnyrT/Q4Awj4Q1pWl5uy8pf8d9J/yhapLSpeZwXYJMfdOz1YD/OSb+9samrCeNEu/9LGbbD+AW7IkbOHbq5zBYdwl++5MBcyf/9tKap2QIlRQESSZvIRx+f3glTF9TGe0O+PJX36FnORpzSdAUiZypdSRBU7y6gqA/qtdXFtGKJQoIDhy4Aqxjed66X4xRhqqi9iqh+FEyO6yioq8tzCNxGlHkZFs8KS41F9PXLae30jdp5s4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR03MB7622.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(30864003)(6512007)(2906002)(966005)(83380400001)(66556008)(5660300002)(8936002)(8676002)(66476007)(66946007)(54906003)(110136005)(86362001)(508600001)(66446008)(166002)(64756008)(38070700005)(186003)(6486002)(2616005)(316002)(6506007)(91956017)(36756003)(40140700001)(33656002)(4326008)(53546011)(71200400001)(122000001)(38100700002)(76116006)(45980500001); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dE9GSWtwcTYxVXhtdHlldVhrNCtVWjZBc3BybVEvanBlcEdRTGNaOTFkenRS?= =?utf-8?B?TFZyS1hYdnRNY3FCTExsSkN0R3l3bk13d3Fva3JUaittU0lSTDVMakpKaG9E?= =?utf-8?B?SDhjeDF2enRxRWlxam9ZWGs4cFRnRHRFY2M3bWcwcVpuRXZQNHUxRjBXazhG?= =?utf-8?B?a245U1NpbzF0THFzREFKK1pSUHhEQjIrV1ljc3M5NTBFOGZVTUFZMTZwOTVO?= =?utf-8?B?SmVQa0ExRlV6UVZEK3BXSklMRmJFSlZ4aFVrQ1Z5STVuTTlDcC9UaWxlRU9v?= =?utf-8?B?UHdmM1hFVTZXaHlTZW02L0l6bG9ZbUEwTE1jRlZSbGFSQkUzbmM2ZTZOK2Mx?= =?utf-8?B?YUE3NldwSVpNUlhxamFodzZ3VlN4K24ybXVrUEpKVitZVnEyTmU4Z0RVdUhD?= =?utf-8?B?eUlOL0NIOGJxeGtJZnN6RWdyN0NFa2J6eE1vbjdqSlNjQ1lIY0ZaZitPaUFB?= =?utf-8?B?YmVmamhhWHNYcTFEa3R0ZjVVb24vaGo5dERJRkswTGd5QXMyUVVRcEp2a29p?= =?utf-8?B?T0ExdkZuM002Znh0RzMxQnNSbHd1dkdaSzNHdFFpYTVlN2hXczNFZ1lmSzg1?= =?utf-8?B?d0Q1SHpIWjFQRUFxK243bWN4M2FwNXovdGxyNEs0MmNCTUJGSTBKc2EzTkZM?= =?utf-8?B?S2tQQ1RJZXBBWjQvS2gwOWRwL2kyME5LTG5FM0Uxa09IUU81VlBzSEVMbk85?= =?utf-8?B?Q3JaWEFNeFlqVGljU1dOb2Evb2I0b0UyMWUzL3hwd09OUlBkR05yZGJGMitJ?= =?utf-8?B?QkNYdU8rNEpnR2tlUkJTb2w4TG1UKzZ1Qkp6RVVacjNGY1YwRGRCdFRoM1dk?= =?utf-8?B?bEF5WjN1MmpuRDN6a0JSYVRyMEtRNTJBcE5ER1NoTFp1NncwcHJlcFdkMGFk?= =?utf-8?B?Qi9QWFFoWDNPU3VHUEtEZDJjRXBjTkJMWW5yWTYrakpCZlBDREdDd3VSS2Za?= =?utf-8?B?cFkrbVh4Qy85bW10ZXVnQzRrTWhCZ3p6VEtCNDRRaHRYQ2xLR2o5UHBPYXJh?= =?utf-8?B?Y2FZRUwzZXNUVUg1WWJ3dXc4UE9XTnNHQVBIMnpwREd4cVVGZGF4UFVCRXhW?= =?utf-8?B?T1NONEJMYUNmVVl1N0VwelZIVTd3clpYTEJORVhyaUlwUDBkUnI3Rm4wMm1Q?= =?utf-8?B?TnlhOUcwNHVuODU5TEFtUkE3OXFMaEpVNnR1WnNPNkw1YkwvL0c0cHBHUEtN?= =?utf-8?B?elBqazY3QW9nczZkYWtvQ0h0UkZWWnRkVnVNVm00dUZTN1NsS1FxaldWaUJs?= =?utf-8?B?S2MzMzJoZmtrNDMwWnJjSG5mbCtlNnFSc0R4OXFuRzVyOExyUTVoNWNsVHVW?= =?utf-8?B?Qi9vdnQ5THNxUFZ1OHo3Sk5PMHNMWm1Idnd1TlJHOUk5Ri9CVFhuTXRXZE44?= =?utf-8?B?RjFqSTFOcklDOXBtRW9zaHFaeDFvSUNuWUlWLzk4MGZnT0duSU9KQ1UvajJ3?= =?utf-8?B?aVdjZ2VLQnNFYWFEajZWcGVYMGVNdTZkc0psTEpldUJLZVVWNVMweWpxVjdZ?= =?utf-8?B?MC9wc3BUQjVqWmRMdEVBd0VMb0xPdkhPYTUzRkFLQUdZS29LNFZjRForQUhO?= =?utf-8?B?d0doWUxLcGNhQnVaNWl6M3VldWxaRWpDUkJFUklNbDkrbk9xOU5kbHpkazBC?= =?utf-8?B?ZUd0SFB6bFFVNmhYV0xIdzY3OTdlQlpoeHMzKy9PMzduR3JJMWpTU1RFWHYw?= =?utf-8?B?aHRDWC9QKzduU05qdC9vL3BGU1ZjOGR6MzAvSEJCKzk3b3FQYWpzbjQ1MHFC?= =?utf-8?B?QTZjSThEbVV2K2hIWlhVL3F6RklKWkVnWVZtNmgwNFMyT1VRYVpPQlFDOUhC?= =?utf-8?B?SkRpdHlUVzJQN0VaK2F6ZENzakxmcGpoVWZMTjRlTXhodTlGeUpZM0V0aG1q?= =?utf-8?Q?YG9JrCFvB0pNi?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB7622.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 69242393-7a6e-4bb6-48e8-08d987585b40 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2021 16:59:40.6401 (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: g3erYfnnDCuIVIiCRhGKlMWSailpXpK7KMPiP54wFZn5GH8XeyeY6+JvprB0+29zwRWK+g4unfRnaL7VzSkVqN6F/sgCkHCW/Uuo22PqvIQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7602 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquidtelecom.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Language: en-GB Content-Type: multipart/alternative; boundary="_000_502AD3A77352471CB17F0DBD57B771D7liquidtelecomcom_" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 04 Oct 2021 16:59:59 -0000 --_000_502AD3A77352471CB17F0DBD57B771D7liquidtelecomcom_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SSB3b3VsZCBzdXBwb3J0IHNwbGl0dGluZyB0aGVzZSDigJMgcHJvdmlkaW5nIHRoZXJlIHdhcyBj b25zZW5zdXMgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgdmlhIGEgc2VwYXJhdGUgY29uc2Vuc3VzIGNh bGwgdG8gY2hhbmdlIHRoZSB3ZyBjb25zZW5zdXMgb24gc2luZ2xlIHNvbHV0aW9uLg0KDQpJIHdv dWxkIGFsc28gYXNrIHRoYXQgd2UgbG9vayBjbG9zZWx5IGF0IHRoZSB3b3JraW5nIGdyb3VwIGNo YXJ0ZXIgaW4gdGhlIGNvbnRleHQgb2YgZWFjaCBzb2x1dGlvbiDigJMgYmVjYXVzZSDigJMgbXkg cmVhZGluZyBvZiB0aGlzIGlzIHRoYXQgaXQgaXMgb25seSB1U0lEIHRoYXQgcnVucyBpbnRvIGNo YXJ0ZXIgaXNzdWVzIOKAkyBhcyBzdWNoIGctc3J2NiBjb3VsZCBwcm9jZWVkIG9uIGl0cyBvd24g d2hpbGUgYWdyZWVtZW50IHdhcyByZXF1ZXN0ZWQgZnJvbSB0aGUgcmVsZXZhbnQgcGVvcGxlIGFz IHBlciB0aGUgc3ByaW5nIGNoYXJ0ZXIgZm9yIHVTSUQuICBJZiBhbmQgd2hlbiBzdWNoIGFncmVl bWVudCBpcyBnaXZlbiDigJMgdVNJRCBjb3VsZCB0aGVuIGJlIGFkb3B0ZWQgYXMgYSBzZWNvbmQg b3B0aW9uIGluIGxpbmUgd2l0aCB0aGUgY29uc2Vuc3VzIGdyYW50ZWQgaW4gc3RlcCBvbmUgaWYg dGhlIHdvcmtpbmcgZ3JvdXAgZmVlbHMgdGhhdCB0aGVyZSBpcyBncm91bmRzIGZvciB0d28gc29s dXRpb25zLg0KDQpUaGlzIGF0IGxlYXN0IGFsbG93cyB1cyB0byBwcm9ncmVzcyB3aXRob3V0IGEg c3RhbGUgbWF0ZQ0KDQpBbmRyZXcNCg0KDQpGcm9tOiBHeWFuIE1pc2hyYSA8aGF5YWJ1c2Fnc21A Z21haWwuY29tPg0KRGF0ZTogTW9uZGF5LCA0IE9jdG9iZXIgMjAyMSBhdCAxOTo0OQ0KVG86IEph bWVzIEd1aWNoYXJkIDxqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20+DQpDYzogQW5kcmV3 IEFsc3RvbiA8QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT4sIFNQUklORyBXRyA8c3By aW5nQGlldGYub3JnPiwgVG9ueSBMaSA8dG9ueS5saUB0b255LmxpPiwgInNwcmluZy1jaGFpcnNA aWV0Zi5vcmciIDxzcHJpbmctY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzcHJpbmdd IFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLw0KDQoNCkRlYXIg Q2hhaXJzDQoNCldhcyB0aGVyZSBhbnkgdGhlcmUgYW55IHRob3VnaHRzIG9mIG1heWJlIGlzc3Vl IGFuIGFkb3B0aW9uIGNhbGwgZm9yIHRoZSBHLVNSdjYgZHJhZnQgaXRzZWxmIG9yIHVTSUQgZHJh ZnQgaXRzZWxmIGFzIGFuIG9wdGlvbiwgb25lIG9yIHRoZSBvdGhlciBvciBzZXBhcmF0ZSBhZG9w dGlvbiBjYWxsIGZvciBib3RoIGRyYWZ0cyBhcyB0aGV5IGFyZSBib3RoIFNSdjYgY29tcGxpYW50 IGFuZCBjYW4gc3RhbmQgb24gdGhlaXIgb3duIGluZGVwZW5kZW50bHkgYW5kIGNsZWFybHkgbWVl dCBhbGwgdGhlIGNvbXByZXNzaW9uIHJlcXVpcmVtZW50cy4NCg0KVGhhdCB3b3VsZCBoYXZlIHRh a2VuIGNhcmUgb2YgdGhlIENTSUQgMiBmbGF2b3IgYW5kIHRoZSBvbmUgZGF0YSBwbGFuZSBzb2x1 dGlvbiBXRyBjb25zZW5zdXMgZGlsZW1tYSBjYWxsLg0KDQpJIHRoaW5rIHRoZSBiaWcgcXVlc3Rp b24gaXMgd2hhdCBkb2VzIGNvbWJpbmluZyB0aGUgdHdvIGRpc3RpbmN0bHkgZGlmZmVyZW50IHNv bHV0aW9ucyBmcm9tIHR3byBkaWZmZXJlbnQgdmVuZG9ycywgaG93IHRoYXQgbWFrZXMgc2Vuc2Ug ZnJvbSBhbiBQT1Ygb2YgYW4gb3BlcmF0b3IgYW5kIGluZHVzdHJ5IHN0YW5kcG9pbnQuICBVbmxl c3Mgb25lIGNhbiBiZW5lZml0IGZyb20gdGhlIG90aGVyIG9yIGlmIHRoZWlyIGFyZSBpbnRlciBk ZXBlbmRlbmNpZXMgYmV0d2VlbiB0aGUgdHdvIHRoYXQgb25lIGlzIG5vdCBhIGNvbXBsZXRlIHNv bHV0aW9uIHdpdGhvdXQgYmVuZWZpdCBmcm9tIHRoZSBvdGhlci4NCg0KVGhhdCBpcyBub3QgdGhl IGNhc2UgaGVyZS4NCg0KS2luZCBSZWdhcmRzDQoNCkd5YW4NCg0KT24gTW9uLCBPY3QgNCwgMjAy MSBhdCAxMToxMyBBTSBKYW1lcyBHdWljaGFyZCA8amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWku Y29tPG1haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20+PiB3cm90ZToNCkhpIEd5 YW4sDQoNClBsZWFzZSBzZWUgdGhlIGNoYWlycyByZXNwb25zZSB0byB0aGUgZW1haWwgZnJvbSBB bmRyZXcgQWxzdG9uLg0KDQpZb3VycywNCg0KSmltLCBCcnVubyAmIEpvZWwuDQoNCkZyb206IEd5 YW4gTWlzaHJhIDxoYXlhYnVzYWdzbUBnbWFpbC5jb208bWFpbHRvOmhheWFidXNhZ3NtQGdtYWls LmNvbT4+DQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMSwgMjAyMSA3OjI2IFBNDQpUbzogVG9ueSBM aSA8dG9ueS5saUB0b255LmxpPG1haWx0bzp0b255LmxpQHRvbnkubGk+Pg0KQ2M6IEFuZHJldyBB bHN0b24gPEFuZHJldy5BbHN0b249NDBsaXF1aWR0ZWxlY29tLmNvbUBkbWFyYy5pZXRmLm9yZzxt YWlsdG86NDBsaXF1aWR0ZWxlY29tLmNvbUBkbWFyYy5pZXRmLm9yZz4+OyBKYW1lcyBHdWljaGFy ZCA8amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPG1haWx0bzpqYW1lcy5uLmd1aWNoYXJk QGZ1dHVyZXdlaS5jb20+PjsgU1BSSU5HIFdHIDxzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmlu Z0BpZXRmLm9yZz4+OyBzcHJpbmctY2hhaXJzQGlldGYub3JnPG1haWx0bzpzcHJpbmctY2hhaXJz QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzcHJpbmddIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5n LXNydjYtc3JoLWNvbXByZXNzaW9uLzxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbj4NCg0KDQpEZWFy IFdHIGNoYWlycywNCg0KSSBhZ3JlZSB3aXRoIEdyZWcgTWlyc2t5IHRoYXQgdGhlIGFkb3B0aW9u IGd1aWRlbGluZXMgYXJlIGNvbmZ1c2luZyBhbmQgY29udHJhZGljdG9yeS4NCg0KQnVsbGV0ICAj MSBzdGF0ZXMgdGhhdCBieSBleHByZXNzaW5nIHN1cHBvcnQgZm9yIGFkb3B0aW9uIHRoZSBXRyBt ZW1iZXIgaXMgYWdyZWVpbmcgdG8gYWRvcHRpb24gb2YgYSBkb2N1bWVudCB0aGF0IGhhcyBtdWx0 aXBsZSBTUnY2IGNvbXByZXNzaW9uIHNvbHV0aW9ucy4NCg0KT24gdGhlIG90aGVyIGhhbmQgYnVs bGV0ICM0IHN0YXRlcyB0aGF0IGlmIHRoZSBkcmFmdCBpcyBhZG9wdGVkIHRoYXQgdGhlIGZvbGxv d2luZyB0ZXh0IGV4Y2VycHQgYmVsb3cgc2hvdWxkIGJlIGFkZGVkIHRvIGFzIGFuIG9wZW4gaXNz dWUgaXNzdWVzIHNlY3Rpb24uDQoNCg0KDQogICogICAiR2l2ZW4gdGhhdCB0aGUgd29ya2luZyBn cm91cCBoYXMgc2FpZCB0aGF0IGl0IHdhbnRzIHRvIHN0YW5kYXJkaXplIG9uZSBkYXRhIHBsYW5l IHNvbHV0aW9uLCBhbmQgZ2l2ZW4gdGhhdCB0aGUgZG9jdW1lbnQgY29udGFpbnMgbXVsdGlwbGUg U1J2NiBFbmRQb2ludCBiZWhhdmlvcnMgdGhhdCBzb21lIFdHIG1lbWJlcnMgaGF2ZSBzdGF0ZWQg YXJlIG11bHRpcGxlIGRhdGEgcGxhbmUgc29sdXRpb25zLCB0aGUgd29ya2luZyBncm91cCB3aWxs IGFkZHJlc3Mgd2hldGhlciB0aGlzIGlzIHZhbGlkIGFuZCBjb2hlcmVudCB3aXRoIGl0cyBvbmUg ZGF0YSBwbGFuZSBzb2x1dGlvbiBvYmplY3RpdmUuIi4NCg0KVGhpcyBzZW50ZW5jZSBpcyB2ZXJ5 IGNvbmZ1c2luZyBhcyB0aGUgV0cgY2hhaXJzIGFncmVlIHRoYXQgdGhlIFdHIGhhcyBjb25zZW5z dXMgb24gYSBzaW5nbGUgc29sdXRpb24gdG8gYXZvaWQgaW50ZXJvcGVyYWJpbGl0eSwgYW5kIHRo ZSBXRyBjaGFpcnMgYWNrbm93bGVkZ2UgdGhhdCBzb21lIFdHIG1lbWJlcnMgZmVlbCB0aGF0IHRo ZSBtdWx0aXBsZSBmbGF2b3JzIGFyZSBhY3R1YWxseSBtdWx0aXBsZSBzb2x1dGlvbnMsIGhvdyBp cyBpdCBwb3NzaWJsZSB0aGF0IHRoZSBXRyB3b3VsZCBhZGRyZXNzIHRoYXQgdGhpcyBpcyBhcyB2 YWxpZCBhbmQgY29oZXJlbnQgd2l0aCBvbmUgZGF0ZSBwbGFuZSBzb2x1dGlvbiBhcyB0aGUgb2Jq ZWN0aXZlLiAgVGhlIHZhbGlkIGFuZCBjb2hlcmVudCBwYXJ0IG9mIGhvdyBhIG11bHRpcGxlIGRh dGEgcGxhbmUgc29sdXRpb24gb3IgZmxhdm9yIG1lZXRzIHRoZSBzaW5nbGUgZGF0YSBwbGFuZSBv YmplY3RpdmUgaXMgY29udHJhZGljdG9yeS4NCg0KIEkgYmVsaWV2ZSB3aGF0IGlzIHN0YXRlZCBo ZXJlIGJ5IHRoZSBjaGFpcnMgaXMgZXhhY3RseSB3aGF0IHNob3VsZCBoYXZlIGJlZW4gY2xlYXJl ZCB1cCBwcmlvciB0byB0aGUgYWRvcHRpb24gY2FsbCwgYnV0IG5vdyBhcyB0aGUgYWRvcHRpb24g Y2FsbCBoYXMgc3RhcnRlZCAgd291bGQgYmUgY2xlYXJlZCB1cCBkdXJpbmcgdGhlIGFkb3B0aW9u IGNhbGwgcHJvY2Vzcy4gIFRoaXMgaXMgc29tZXdoYXQgb2YgYSBjaGVzcyBnYW1lIGFzIHRvIHdo aWNoIHdheSB0byBoYXZlIHByb2NlZWRlZCwgYnV0IEkgdGhpbmsgZ2V0dGluZyB0aGlzIGNsZWFy ZWQgdXAgcHJpb3IgdG8gdGhlIGNhbGwgZm9yIGFkb3B0aW9uIHdvdWxkIGhhdmUgYmVlbiBiZXR0 ZXIgZm9yIHRoZSBXRy4NCg0KQWxsIFdHIG1lbWJlcnMgdGhhdCBmZWVsIHN0cm9uZ2x5IHRoYXQg dGhlIHR3byBlbmRwb2ludCBmbGF2b3JzIGFyZSB0d28gZGlzdGluY3RseSBkaWZmZXJlbnQgc29s dXRpb25zIHdpbGwgc3RpY2sgdG8gdGhlaXIgZ3VucyBhbmQgc3VwcG9ydCBub3QgYWRvcHRpbmcg dGhlIGRvY3VtZW50Lg0KDQpBbGwgV0cgbWVtYmVycyB0aGF0IGFyZSBPayB3aXRoIHR3byBzb2x1 dGlvbnMgdmVyc3VzIGEgc2luZ2xlIFNSVjYgY29tcHJlc3Npb24gc29sdXRpb24gd2lsbCBjaG9z ZSB0byBhZG9wdCB0aGUgZHJhZnQuDQoNClRoZSBkb3duIHNpZGUgb2Ygbm90IHJlc29sdmluZyB0 aGlzIGlzc3VlIHByaW9yIHRvIGFkb3B0aW9uIGNhbGwgIGlzIHRoYXQgdGhlcmUgaXMgYSBjaGFu Y2UgdGhlIG1hbnkgdGhhdCBmZWx0IHN0cm9uZ2x5IGZvciBhIHNpbmdsZSBzb2x1dGlvbiBhcyBy aXNrIG9mIGludGVyb3BlcmFiaWxpdHkgaXNzdWVzIGFzIGFsbCB2ZW5kb3JzIGR1ZSB0byBjb3N0 IG1heSBub3Qgd2FudCB0byBpbXBsZW1lbnQgbXVsdGlwbGUgY29tcHJlc3Npb24gc29sdXRpb25z IGFuZCBtYXkgbm90IGFsbCBwaWNrIHRoZSBzYW1lIGNvbXByZXNzaW9uIHNvbHV0aW9uLg0KDQpT byB0aGVyZSBjb3VsZCBiZSBhIHVuYW5pbW91cyB2b3RlIHRvIG5vdCBhZG9wdCBhcyB0aGlzIGdv ZXMgYWdhaW5zdCB0aGUgV0cgY29uc2Vuc3VzIG9uIGEgc2luZ2xlIGRhdGEgcGxhbmUgc29sdXRp b24uDQoNCkkgYWdyZWUgdGhhdCBpcyBub3QgYSBtYWpvciByaXNrIGdvaW5nIHRoaXMgcm91dGUg YXMgdGhlIGRyYWZ0IHdvdWxkIGJlIGtpY2tlZCBiYWNrIHRvIHRoZSBhdXRob3JzIHRvIHJldmlz ZSBhbmQgcGljayBvbmUgb2YgdGhlIGZsYXZvcnMgdG8gcHV0IGZvcndhcmQgZm9yIGFkb3B0aW9u Lg0KDQpUaGUgZmxpcCBzaWRlIGlzIHdlIGFyZSBiYWNrIHRvIHRoZSBkcmF3aW5nIGJvYXJkIHdp dGggdGhlIERUIG9uIFdHIGNvbnNlbnN1cyBvbiBhIGNvbXByZXNzaW9uIHNvbHV0aW9uIHRvIGFn cmVlIHRvIGZvciBhbiBhZG9wdGlvbiBjYWxsLg0KDQpLaW5kIFJlZ2FyZHMNCg0KR3lhbg0KDQpP biBGcmksIE9jdCAxLCAyMDIxIGF0IDQ6NTUgUE0gVG9ueSBMaSA8dG9ueS5saUB0b255LmxpPG1h aWx0bzp0b255LmxpQHRvbnkubGk+PiB3cm90ZToNCg0KKzENCg0KSSBvYmplY3QgdG8gdGhlIGFk b3B0aW9uLg0KDQpUb255DQoNCg0KT24gT2N0IDEsIDIwMjEsIGF0IDE6NDMgUE0sIEFuZHJldyBB bHN0b24gPEFuZHJldy5BbHN0b249NDBsaXF1aWR0ZWxlY29tLmNvbUBkbWFyYy5pZXRmLm9yZzxt YWlsdG86QW5kcmV3LkFsc3Rvbj00MGxpcXVpZHRlbGVjb20uY29tQGRtYXJjLmlldGYub3JnPj4g d3JvdGU6DQoNCkp1c3QgdG8gYWRkIHRvIHRoaXMsDQoNCkkgYW0gb25lIG9mIHRoZSBwZW9wbGUg d2hvIGNsZWFybHkgc3RhdGVkIHRoYXQgSSBkaWRu4oCZdCB0aGluayBhIHNpbmdsZSBzb2x1dGlv biB3YXMgdGhlIHJpZ2h0IGFuc3dlciBoZXJlIOKAkyBhbmQgSSBzdGF0ZWQgbXkgcmVhc29uaW5n IGNsZWFybHkgb24gdGhpcyBsaXN0LiAgSSBzdGlsbCBiZWxpZXZlIHRoYXQg4oCTIGhvd2V2ZXIg 4oCTIEkgcmVjb2duaXplIHRoYXQgdGhlIGZvdW5kYXRpb24gb2YgdGhlIElFVEYgaXMgZm91bmQg aW4gdGhlIGJvdHRvbSB1cCBjb25zZW5zdXMgYXBwcm9hY2gg4oCTIGFuZCB3aGVuIHRoZSB3b3Jr aW5nIGdyb3VwIGhhcyBkZW1vbnN0cmF0ZWQgc3VjaCBjbGVhciBjb25zZW5zdXMg4oCTIHRvIGRl ZnkgdGhhdCDigJMgaXMgdG8gZGVmeSB3aGF0IG1ha2VzIHRoZSBJRVRGIHRoZSBJRVRGLg0KDQpT byDigJMgV2hpbGUgSSBzdGlsbCBiZWxpZXZlIGluIG11bHRpcGxlIHNvbHV0aW9ucyDigJMgaXJy ZXNwZWN0aXZlIG9mIHRoYXQg4oCTIEkgZmluZCB0aGlzIGNhbGwgYXBwYWxsaW5nIOKAkyBiZWNh dXNlIGFzIG11Y2ggYXMgSSBiZWxpZXZlIGluIG11bHRpcGxlIHNvbHV0aW9ucyDigJMgdGhlIHdv cmtpbmcgZ3JvdXAgY29uc2Vuc3VzIHNob3VsZCBiZSBzYWNyb3NhbmN0Lg0KDQpBbmRyZXcNCg0K DQpGcm9tOiBBbmRyZXcgQWxzdG9uIDxBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPG1h aWx0bzpBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPj4NCkRhdGU6IEZyaWRheSwgMSBP Y3RvYmVyIDIwMjEgYXQgMjM6MjENClRvOiBKYW1lcyBHdWljaGFyZCA8amFtZXMubi5ndWljaGFy ZEBmdXR1cmV3ZWkuY29tPG1haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20+Piwg U1BSSU5HIFdHIDxzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4+DQpDYzog c3ByaW5nLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nLWNoYWlyc0BpZXRmLm9yZz4gPHNw cmluZy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZy1jaGFpcnNAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogUmU6IFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLzxo dHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmRyYWZ0LWZpbHNmaWxzY2hlbmct c3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uJTJGJmRhdGE9MDQlN0MwMSU3Q2phbWVzLm4uZ3Vp Y2hhcmQlNDBmdXR1cmV3ZWkuY29tJTdDMjVkYTM2NTAwYjlkNDVhNzEyNTAwOGQ5ODUzMmRiYzAl N0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MwJTdDNjM3Njg3Mjc1Nzgx NjA3NjU5JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlq b2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmc2RhdGE9cmFl bGlQRGRBRTNYV2VWT1ZBVVZRQURvMFFabkIlMkZGYkpGNTNpQTVNMUJRJTNEJnJlc2VydmVkPTA+ DQpTb3JyeSDigJMgYnV0IOKAkyBJ4oCZbSBhIGxpdHRsZSBjb25mdXNlZCBoZXJlLg0KDQpCZWNh dXNlIHRoZSB3YXkgSSBsb29rIGF0IHRoaXMg4oCTIHRoZSB3b3JraW5nIGdyb3VwIGNsZWFybHkg c3RhdGVkIHRoYXQgdGhleSB3aXNoZWQgZm9yIGEgc2luZ2xlIGJlaGF2aW9yIOKAkyBhbmQgdGhp cyDigJMgZG9lcyBub3QgZGVsaXZlciB0aGF0IOKAkyBpdCBpcyB0d28gc2VwYXJhdGUgYmVoYXZp b3JzLiAgQXMgc3VjaCDigJMgSSBzZWUgdGhpcyBjYWxsIGZvciBhZG9wdGlvbiDigJMgaXJyZXNw ZWN0aXZlIG9mIHRoZSBtZXJpdHMgb3IgbGFjayB0aGVyZW9mIG9mIHRoZSBkcmFmdCwgYXMgYSBj bGVhciBkZWZpYW5jZSBvZiB0aGUgc3RhdGVkIHdpbGwgb2YgdGhlIHdvcmtpbmcgZ3JvdXAuDQoN ClRoaXMgaXMgc2ltcGx5IGRvZXMgbm90IGZpdCBpbnRvIHRoZSBkZWZpbml0aW9uIG9mIGJvdHRv bSB1cCBhcHByb2FjaCBpbiBteSBvcGluaW9uIOKAkyBhbmQgaWYgdGhpcyBpcyB0aGUgd2F5IHRo YXQgdGhlIGNoYWlycyB3aXNoIHRvIHByb2NlZWQg4oCTIHRoZW4gdGhlIG9ubHkgd2F5IHRvIGRv IHRoYXQgYW5kIHN0aWxsIGZpdCB3aXRoaW4gdGhlIGJvdHRvbSB1cCBhcHByb2FjaCBpcyB0byBm aXJzdCBhc2sgdGhpcyB3b3JraW5nIGdyb3VwIGZvciBpdHMgY29uc2Vuc3VzIHRvIGRldmlhdGUg ZnJvbSB0aGUgc2luZ2xlIGJlaGFjdmlvciBhcHByb2FjaCB0aGF0IHRoZSB3b3JraW5nIGdyb3Vw IGFncmVlZCB0by4NCg0KQXMgc3VjaCDigJMgSSBtdXN0ICBzdHJvbmdseSBhbmQgdW5lcXVpdm9j YWxseSBvYmplY3QgdG8gdGhpcyBjYWxsIGZvciBhZG9wdGlvbg0KDQpBbmRyZXcNCg0KRnJvbTog c3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0 Zi5vcmc+PiBvbiBiZWhhbGYgb2YgSmFtZXMgR3VpY2hhcmQgPGphbWVzLm4uZ3VpY2hhcmRAZnV0 dXJld2VpLmNvbTxtYWlsdG86amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPj4NCkRhdGU6 IEZyaWRheSwgMSBPY3RvYmVyIDIwMjEgYXQgMTc6MDUNClRvOiBTUFJJTkcgV0cgPHNwcmluZ0Bp ZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPj4NCkNjOiBzcHJpbmctY2hhaXJzQGlldGYu b3JnPG1haWx0bzpzcHJpbmctY2hhaXJzQGlldGYub3JnPiA8c3ByaW5nLWNoYWlyc0BpZXRmLm9y ZzxtYWlsdG86c3ByaW5nLWNoYWlyc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBbc3ByaW5nXSBXRyBB ZG9wdGlvbiBjYWxsIGZvciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1m aWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88aHR0cHM6Ly9uYW0xMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRy YWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZkcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNy aC1jb21wcmVzc2lvbiUyRiZkYXRhPTA0JTdDMDElN0NqYW1lcy5uLmd1aWNoYXJkJTQwZnV0dXJl d2VpLmNvbSU3QzI1ZGEzNjUwMGI5ZDQ1YTcxMjUwMDhkOTg1MzJkYmMwJTdDMGZlZThmZjJhM2Iy NDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMCU3QzYzNzY4NzI3NTc4MTYxNzY1MyU3Q1Vua25v d24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pC VGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJnNkYXRhPXhvN09yUlVLRDRKUXRBaDIl MkJrb2pQUzlaVXVvb0x2RkFaYUE2S0dFMGVLTSUzRCZyZXNlcnZlZD0wPg0KRGVhciBXRzoNCg0K VGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGV4cHJlc3MgdGhlaXIgYXBwcmVjaWF0aW9uIGZvciBh bGwgdGhlIHJlc3BvbnNlcyByZWNlaXZlZCB0byBvdXIgZW1haWxzIHdpdGggcmVmZXJlbmNlIHRv IGhvdyB0aGUgd29ya2luZyBncm91cCB3aXNoZXMgdG8gbW92ZSBmb3J3YXJkIHdpdGggcmVzcGVj dCB0byBhIHNvbHV0aW9uIGZvciBTUnY2IGNvbXByZXNzaW9uLg0KDQpUaGUgYXBwYXJlbnQgaW5j bGluYXRpb24gb2YgdGhlIHdvcmtpbmcgZ3JvdXAgaXMgdG8gdXNlIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXBy ZXNzaW9uLzxodHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmRyYWZ0LWZpbHNm aWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uJTJGJmRhdGE9MDQlN0MwMSU3Q2ph bWVzLm4uZ3VpY2hhcmQlNDBmdXR1cmV3ZWkuY29tJTdDMjVkYTM2NTAwYjlkNDVhNzEyNTAwOGQ5 ODUzMmRiYzAlN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MwJTdDNjM3 Njg3Mjc1NzgxNjE3NjUzJTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdN REFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAm c2RhdGE9eG83T3JSVUtENEpRdEFoMiUyQmtvalBTOVpVdW9vTHZGQVphQTZLR0UwZUtNJTNEJnJl c2VydmVkPTA+IGFzIHRoZSBiYXNpcyBmb3IgaXRzIGNvbXByZXNzaW9uIHN0YW5kYXJkaXphdGlv biB3b3JrLiBUaGF0IGlzIHBhcnQgb2Ygd2hhdCB0aGlzIGVtYWlsIGF0dGVtcHRzIHRvIGNvbmZp cm0uDQoNCkJlY2F1c2Ugb2YgdGhlIGFib3ZlIHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBpc3N1 ZSBhIDItd2VlayBXRyBjYWxsIGZvciBhZG9wdGlvbiBlbmRpbmcgT2N0b2JlciAxNXRoIGZvciBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmlu Zy1zcnY2LXNyaC1jb21wcmVzc2lvbi88aHR0cHM6Ly9uYW0xMS5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZk b2MlMkZkcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbiUyRiZk YXRhPTA0JTdDMDElN0NqYW1lcy5uLmd1aWNoYXJkJTQwZnV0dXJld2VpLmNvbSU3QzI1ZGEzNjUw MGI5ZDQ1YTcxMjUwMDhkOTg1MzJkYmMwJTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZl ZGMlN0MxJTdDMCU3QzYzNzY4NzI3NTc4MTYyNzY1MSU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhl eUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZD STZNbjAlM0QlN0MxMDAwJnNkYXRhPTNzV2N2dVczTUJEeDVOODJOM2ZPaTQzREMybzJmdnVJR1lG USUyQmUweHBFWSUzRCZyZXNlcnZlZD0wPiBidXQgd2l0aCBzb21lIGNsZWFyIGd1aWRlbGluZXMg YXMgZm9sbG93cy4gQnkgZXhwcmVzc2luZyBzdXBwb3J0IGZvciBhZG9wdGlvbiBvZiB0aGlzIGRv Y3VtZW50IHlvdSBhcmUgZnVsbHkgYXdhcmUgb2YgYW5kIGFyZSBhY2tub3dsZWRnaW5nIHRoYXQ6 DQoNCg0KICAxLiAgVGhlIFNQUklORyB3b3JraW5nIGdyb3VwIGlzIGFkb3B0aW5nIGEgZG9jdW1l bnQgdGhhdCBoYXMgbXVsdGlwbGUgU1J2NiBFbmRwb2ludCBiZWhhdmlvcnMuDQogIDIuICBUaGUg ZG9jdW1lbnQgaXMgYSDigJxsaXZpbmfigJ0gZG9jdW1lbnQ7IGl0IG1heSBjaGFuZ2UgYXMgaXQg Z29lcyB0aHJvdWdoIHJldmlldyBhbmQgYW5hbHlzaXMgYnkgdGhlIFNQUklORyB3b3JraW5nIGdy b3VwLg0KICAzLiAgQWxsIG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgcmFpc2VkIG9uIG91ciBtYWls aW5nIGxpc3QgTVVTVCBiZSBhZGRyZXNzZWQgQkVGT1JFIHNhaWQgZG9jdW1lbnQgaXMgYWxsb3dl ZCB0byBwcm9ncmVzcyBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIHRvIHB1YmxpY2F0aW9uLiBBIGxp c3Qgb2YgdGhlc2UgZGlzY3Vzc2lvbiBwb2ludHMgd2lsbCBiZSBkb2N1bWVudGVkIGluIHRoZSBX RyBkb2N1bWVudCBhbmQgbWFpbnRhaW5lZCBieSB0aGUgZG9jdW1lbnQgZWRpdG9yIGluIGNvbmp1 bmN0aW9uIHdpdGggdGhlIGNoYWlycy4NCiAgNC4gIElmIHRoaXMgZG9jdW1lbnQgaXMgYWRvcHRl ZCBieSB0aGUgd29ya2luZyBncm91cCwgdGhlIGNoYWlycyBzcGVjaWZ5IGFzIHBhcnQgb2YgdGhl IGFkb3B0aW9uIGNhbGwgdGhhdCB0aGUgZm9sbG93aW5nIHRleHQgZGVzY3JpYmluZyBhbiBvcGVu IGlzc3VlIGJlIGFkZGVkIHRvIHRoZSBkb2N1bWVudCBpbiB0aGUgYWJvdmUtZGVzY3JpYmVkIG9w ZW4gaXNzdWVzIHNlY3Rpb246DQoNCiAgICAgKiAgICJHaXZlbiB0aGF0IHRoZSB3b3JraW5nIGdy b3VwIGhhcyBzYWlkIHRoYXQgaXQgd2FudHMgdG8gc3RhbmRhcmRpemUgb25lIGRhdGEgcGxhbmUg c29sdXRpb24sIGFuZCBnaXZlbiB0aGF0IHRoZSBkb2N1bWVudCBjb250YWlucyBtdWx0aXBsZSBT UnY2IEVuZFBvaW50IGJlaGF2aW9ycyB0aGF0IHNvbWUgV0cgbWVtYmVycyBoYXZlIHN0YXRlZCBh cmUgbXVsdGlwbGUgZGF0YSBwbGFuZSBzb2x1dGlvbnMsIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwg YWRkcmVzcyB3aGV0aGVyIHRoaXMgaXMgdmFsaWQgYW5kIGNvaGVyZW50IHdpdGggaXRzIG9uZSBk YXRhIHBsYW5lIHNvbHV0aW9uIG9iamVjdGl2ZS4iLg0KDQpQbGVhc2UgY29uc2lkZXIgdGhlIGFi b3ZlIGd1aWRlbGluZXMgYXMgeW91IGRlY2lkZSBvbiB3aGV0aGVyIHRvIHN1cHBvcnQgb3Igbm90 IHRoaXMgV0cgYWRvcHRpb24uIFBsZWFzZSBleHByZXNzIGNsZWFybHkgeW91ciByZWFzb25pbmcg Zm9yIHN1cHBvcnQvbm9uLXN1cHBvcnQgYXMgd2VsbCBhcyBhbnkgb3BlbiBkaXNjdXNzaW9uIHBv aW50cyB5b3Ugd291bGQgbGlrZSBhZGRyZXNzZWQgc2hvdWxkIHRoZSBkb2N1bWVudCBiZSBhZG9w dGVkIGludG8gdGhlIHdvcmtpbmcgZ3JvdXAuDQoNClRoYW5rcyENCg0KSmltLCBCcnVubyAmIEpv ZWwNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K c3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5v cmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzxodHRwczov L25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYl MkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmcmZGF0YT0wNCU3QzAx JTdDamFtZXMubi5ndWljaGFyZCU0MGZ1dHVyZXdlaS5jb20lN0MyNWRhMzY1MDBiOWQ0NWE3MTI1 MDA4ZDk4NTMyZGJjMCU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRjJTdDMSU3QzAl N0M2Mzc2ODcyNzU3ODE2Mjc2NTElN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3 TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdD MTAwMCZzZGF0YT0zRWJlcVpDQzhWdSUyQjhoNTZDVzZONVolMkJ1RDAwTjJzdiUyQkx6aWhySDdm NmlFJTNEJnJlc2VydmVkPTA+DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRv OnNwcmluZ0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3ByaW5nPGh0dHBzOi8vbmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRm1haWxtYW4lMkZsaXN0aW5mbyUyRnNwcmlu ZyZkYXRhPTA0JTdDMDElN0NqYW1lcy5uLmd1aWNoYXJkJTQwZnV0dXJld2VpLmNvbSU3QzI1ZGEz NjUwMGI5ZDQ1YTcxMjUwMDhkOTg1MzJkYmMwJTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5 MWZlZGMlN0MxJTdDMCU3QzYzNzY4NzI3NTc4MTYzNzY0MSU3Q1Vua25vd24lN0NUV0ZwYkdac2Iz ZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENK WFZDSTZNbjAlM0QlN0MxMDAwJnNkYXRhPWs4WHptM1BLRVdEZCUyRkV5T1VFb2x1ajNram1UaGtM ajdlTExsbVBKcUlaWSUzRCZyZXNlcnZlZD0wPg0KLS0NCg0KW0ltYWdlIHJlbW92ZWQgYnkgc2Vu ZGVyLl08aHR0cHM6Ly9uYW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJs PWh0dHAlM0ElMkYlMkZ3d3cudmVyaXpvbi5jb20lMkYmZGF0YT0wNCU3QzAxJTdDamFtZXMubi5n dWljaGFyZCU0MGZ1dHVyZXdlaS5jb20lN0MyNWRhMzY1MDBiOWQ0NWE3MTI1MDA4ZDk4NTMyZGJj MCU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRjJTdDMSU3QzAlN0M2Mzc2ODcyNzU3 ODE2Mzc2NDElN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pR SWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZzZGF0YT1m ZmxPQVF2WlhRMWYzJTJCQ29PaWNTZ2REdiUyQjd3ZEtDUDR2Y1owaGF5QjFCQSUzRCZyZXNlcnZl ZD0wPg0KDQpHeWFuIE1pc2hyYQ0KDQpOZXR3b3JrIFNvbHV0aW9ucyBBcmNoaXRlY3QNCg0KRW1h aWwgZ3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbTxtYWlsdG86Z3lhbi5zLm1pc2hyYUB2ZXJpem9u LmNvbT4NCg0KTSAzMDEgNTAyLTEzNDcNCg0KLS0NCg0KW0ltYWdlIHJlbW92ZWQgYnkgc2VuZGVy Ll08aHR0cDovL3d3dy52ZXJpem9uLmNvbT4NCg0KR3lhbiBNaXNocmENCg0KTmV0d29yayBTb2x1 dGlvbnMgQXJjaGl0ZWN0DQoNCkVtYWlsIGd5YW4ucy5taXNocmFAdmVyaXpvbi5jb208bWFpbHRv Omd5YW4ucy5taXNocmFAdmVyaXpvbi5jb20+DQoNCk0gMzAxIDUwMi0xMzQ3DQoNCg== --_000_502AD3A77352471CB17F0DBD57B771D7liquidtelecomcom_ Content-Type: text/html; charset=UTF-8 Content-ID: <86931C82621D3A439FEA811CF3E90AEB@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkhlbHZldGljYTsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAw O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6 MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpHZW9yZ2lhOw0KCXBhbm9zZS0xOjIgNCA1IDIgNSA0IDUgMiAzIDM7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm0tNTQ0MzU3MjAxNzcyMzA5NTM1NW02MjEwNDY2MzY0MTAwNjYzNTg2bXNvcGxhaW50ZXh0LCBs aS5tLTU0NDM1NzIwMTc3MjMwOTUzNTVtNjIxMDQ2NjM2NDEwMDY2MzU4Nm1zb3BsYWludGV4dCwg ZGl2Lm0tNTQ0MzU3MjAxNzcyMzA5NTM1NW02MjEwNDY2MzY0MTAwNjYzNTg2bXNvcGxhaW50ZXh0 DQoJe21zby1zdHlsZS1uYW1lOm1fLTU0NDM1NzIwMTc3MjMwOTUzNTVtNjIxMDQ2NjM2NDEwMDY2 MzU4Nm1zb3BsYWludGV4dDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21z by1saXN0LWlkOjI4MjkyMjc1MTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTUyMDUwMzA7fQ0K QGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTA5ODcxNDY4NjsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6MTA4MzM0NTM5NDt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjQ7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjE4MDkwODM5NTk7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjE3ODI1OTExNDt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4w cHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDI6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTow Y207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iZW4tS0UiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSB3b3VsZCBzdXBwb3J0IHNwbGl0dGluZyB0aGVz ZSDigJMgcHJvdmlkaW5nIHRoZXJlIHdhcyBjb25zZW5zdXMgaW4gdGhlIHdvcmtpbmcgZ3JvdXAg dmlhIGEgc2VwYXJhdGUgY29uc2Vuc3VzIGNhbGwgdG8gY2hhbmdlIHRoZSB3ZyBjb25zZW5zdXMg b24gc2luZ2xlIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgd291 bGQgYWxzbyBhc2sgdGhhdCB3ZSBsb29rIGNsb3NlbHkgYXQgdGhlIHdvcmtpbmcgZ3JvdXAgY2hh cnRlciBpbiB0aGUgY29udGV4dCBvZiBlYWNoIHNvbHV0aW9uIOKAkyBiZWNhdXNlIOKAkyBteSBy ZWFkaW5nIG9mIHRoaXMgaXMgdGhhdCBpdCBpcyBvbmx5IHVTSUQgdGhhdCBydW5zIGludG8gY2hh cnRlciBpc3N1ZXMNCiDigJMgYXMgc3VjaCBnLXNydjYgY291bGQgcHJvY2VlZCBvbiBpdHMgb3du IHdoaWxlIGFncmVlbWVudCB3YXMgcmVxdWVzdGVkIGZyb20gdGhlIHJlbGV2YW50IHBlb3BsZSBh cyBwZXIgdGhlIHNwcmluZyBjaGFydGVyIGZvciB1U0lELiZuYnNwOyBJZiBhbmQgd2hlbiBzdWNo IGFncmVlbWVudCBpcyBnaXZlbiDigJMgdVNJRCBjb3VsZCB0aGVuIGJlIGFkb3B0ZWQgYXMgYSBz ZWNvbmQgb3B0aW9uIGluIGxpbmUgd2l0aCB0aGUgY29uc2Vuc3VzIGdyYW50ZWQgaW4NCiBzdGVw IG9uZSBpZiB0aGUgd29ya2luZyBncm91cCBmZWVscyB0aGF0IHRoZXJlIGlzIGdyb3VuZHMgZm9y IHR3byBzb2x1dGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhpcyBhdCBs ZWFzdCBhbGxvd3MgdXMgdG8gcHJvZ3Jlc3Mgd2l0aG91dCBhIHN0YWxlIG1hdGU8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BbmRyZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj5HeWFuIE1pc2hyYSAmbHQ7aGF5YWJ1c2Fnc21AZ21haWwuY29tJmd0Ozxicj4NCjxiPkRh dGU6IDwvYj5Nb25kYXksIDQgT2N0b2JlciAyMDIxIGF0IDE5OjQ5PGJyPg0KPGI+VG86IDwvYj5K YW1lcyBHdWljaGFyZCAmbHQ7amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tJmd0Ozxicj4N CjxiPkNjOiA8L2I+QW5kcmV3IEFsc3RvbiAmbHQ7QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29t LmNvbSZndDssIFNQUklORyBXRyAmbHQ7c3ByaW5nQGlldGYub3JnJmd0OywgVG9ueSBMaSAmbHQ7 dG9ueS5saUB0b255LmxpJmd0OywgJnF1b3Q7c3ByaW5nLWNoYWlyc0BpZXRmLm9yZyZxdW90OyAm bHQ7c3ByaW5nLWNoYWlyc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtz cHJpbmddIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5EZWFyIENoYWlycyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5XYXMgdGhlcmUgYW55IHRoZXJlIGFueSB0aG91Z2h0cyBvZiBtYXli ZSBpc3N1ZSBhbiBhZG9wdGlvbiBjYWxsIGZvciB0aGUgRy1TUnY2IGRyYWZ0IGl0c2VsZiBvciB1 U0lEIGRyYWZ0IGl0c2VsZiBhcyBhbiBvcHRpb24sIG9uZSBvciB0aGUgb3RoZXIgb3Igc2VwYXJh dGUgYWRvcHRpb24gY2FsbCBmb3IgYm90aCBkcmFmdHMgYXMgdGhleSBhcmUgYm90aCBTUnY2IGNv bXBsaWFudCBhbmQgY2FuIHN0YW5kIG9uDQogdGhlaXIgb3duIGluZGVwZW5kZW50bHkgYW5kIGNs ZWFybHkgbWVldCBhbGwgdGhlIGNvbXByZXNzaW9uIHJlcXVpcmVtZW50cy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhdCB3b3VsZCBoYXZl IHRha2VuIGNhcmUgb2YgdGhlIENTSUQgMiBmbGF2b3IgYW5kIHRoZSBvbmUgZGF0YSBwbGFuZSBz b2x1dGlvbiBXRyBjb25zZW5zdXMgZGlsZW1tYSBjYWxsLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGUgYmlnIHF1 ZXN0aW9uIGlzIHdoYXQgZG9lcyBjb21iaW5pbmcgdGhlIHR3byBkaXN0aW5jdGx5IGRpZmZlcmVu dCBzb2x1dGlvbnMgZnJvbSB0d28gZGlmZmVyZW50IHZlbmRvcnMsIGhvdyB0aGF0IG1ha2VzIHNl bnNlIGZyb20gYW4gUE9WIG9mIGFuIG9wZXJhdG9yIGFuZCBpbmR1c3RyeSBzdGFuZHBvaW50LiZu YnNwOyBVbmxlc3Mgb25lIGNhbiBiZW5lZml0IGZyb20gdGhlIG90aGVyIG9yIGlmIHRoZWlyDQog YXJlIGludGVyIGRlcGVuZGVuY2llcyBiZXR3ZWVuIHRoZSB0d28gdGhhdCBvbmUgaXMgbm90IGEg Y29tcGxldGUgc29sdXRpb24gd2l0aG91dCBiZW5lZml0IGZyb20gdGhlIG90aGVyLiAmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhh dCBpcyBub3QgdGhlIGNhc2UgaGVyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+S2luZCBSZWdhcmRzJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkd5YW48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE9jdCA0LCAyMDIx IGF0IDExOjEzIEFNIEphbWVzIEd1aWNoYXJkICZsdDs8YSBocmVmPSJtYWlsdG86amFtZXMubi5n dWljaGFyZEBmdXR1cmV3ZWkuY29tIj5qYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb208L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNt IDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SGkgR3lhbiw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5QbGVhc2Ugc2VlIHRoZSBjaGFpcnMgcmVzcG9uc2UgdG8g dGhlIGVtYWlsIGZyb20gQW5kcmV3IEFsc3Rvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5Zb3Vy cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5KaW0sIEJydW5vICZhbXA7IEpvZWwuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gR3lh biBNaXNocmEgJmx0OzxhIGhyZWY9Im1haWx0bzpoYXlhYnVzYWdzbUBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5oYXlhYnVzYWdzbUBnbWFpbC5jb208L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8 L2I+IEZyaWRheSwgT2N0b2JlciAxLCAyMDIxIDc6MjYgUE08YnI+DQo8Yj5Ubzo8L2I+IFRvbnkg TGkgJmx0OzxhIGhyZWY9Im1haWx0bzp0b255LmxpQHRvbnkubGkiIHRhcmdldD0iX2JsYW5rIj50 b255LmxpQHRvbnkubGk8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gQW5kcmV3IEFsc3RvbiAmbHQ7 QW5kcmV3LkFsc3Rvbj08YSBocmVmPSJtYWlsdG86NDBsaXF1aWR0ZWxlY29tLmNvbUBkbWFyYy5p ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwbGlxdWlkdGVsZWNvbS5jb21AZG1hcmMuaWV0Zi5v cmc8L2E+Jmd0OzsgSmFtZXMgR3VpY2hhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpqYW1lcy5uLmd1 aWNoYXJkQGZ1dHVyZXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5qYW1lcy5uLmd1aWNoYXJkQGZ1 dHVyZXdlaS5jb208L2E+Jmd0OzsNCiBTUFJJTkcgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJp bmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0OzsNCjxh IGhyZWY9Im1haWx0bzpzcHJpbmctY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3By aW5nLWNoYWlyc0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzcHJpbmdd IFdHIEFkb3B0aW9uIGNhbGwgZm9yIDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uIiB0 YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1m aWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88L2E+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ RGVhciBXRyBjaGFpcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+SSBhZ3JlZSB3aXRoIEdyZWcgTWlyc2t5IHRoYXQgdGhlIGFkb3B0aW9uIGd1 aWRlbGluZXMgYXJlIGNvbmZ1c2luZyBhbmQgY29udHJhZGljdG9yeS4gJm5ic3A7Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+QnVsbGV0 ICZuYnNwOyMxIHN0YXRlcyB0aGF0IGJ5IGV4cHJlc3Npbmcgc3VwcG9ydCBmb3IgYWRvcHRpb24g dGhlIFdHIG1lbWJlciBpcyBhZ3JlZWluZyB0byBhZG9wdGlvbiBvZiBhIGRvY3VtZW50IHRoYXQg aGFzIG11bHRpcGxlIFNSdjYgY29tcHJlc3Npb24gc29sdXRpb25zLiAmbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiB0aGUgb3RoZXIg aGFuZCBidWxsZXQgIzQgc3RhdGVzIHRoYXQgaWYgdGhlIGRyYWZ0IGlzIGFkb3B0ZWQgdGhhdCB0 aGUgZm9sbG93aW5nIHRleHQgZXhjZXJwdCBiZWxvdyBzaG91bGQgYmUgYWRkZWQgdG8gYXMgYW4g b3BlbiBpc3N1ZSBpc3N1ZXMgc2VjdGlvbi4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBjbTt3b3JkLXNwYWNpbmc6 MXB4IiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0ibS01NDQzNTcyMDE3NzIzMDk1MzU1bTYyMTA0 NjYzNjQxMDA2NjM1ODZtc29wbGFpbnRleHQiIHN0eWxlPSJjb2xvcjojMzEzMTMxO21hcmdpbi10 b3A6MGNtO21hcmdpbi1ib3R0b206MGNtO21zby1saXN0OmwyIGxldmVsMSBsZm8xO2ZvbnQtc2l6 ZTowLjkxNjY2NjY4NjUzNDg4MTZyZW0iPg0KPHNwYW4gbGFuZz0iRU4tVVMiPiZxdW90O0dpdmVu IHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHNhaWQgdGhhdCBpdCB3YW50cyB0byBzdGFuZGFy ZGl6ZSBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiwgYW5kIGdpdmVuIHRoYXQgdGhlIGRvY3VtZW50 IGNvbnRhaW5zIG11bHRpcGxlIFNSdjYgRW5kUG9pbnQgYmVoYXZpb3JzIHRoYXQgc29tZSBXRyBt ZW1iZXJzIGhhdmUgc3RhdGVkIGFyZSBtdWx0aXBsZSBkYXRhIHBsYW5lIHNvbHV0aW9ucywgdGhl IHdvcmtpbmcNCiBncm91cCB3aWxsIGFkZHJlc3Mgd2hldGhlciB0aGlzIGlzIHZhbGlkIGFuZCBj b2hlcmVudCB3aXRoIGl0cyBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiBvYmplY3RpdmUuJnF1b3Q7 LjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPlRoaXMgc2VudGVuY2UgaXMgdmVyeSBjb25mdXNpbmcgYXMgdGhlIFdHIGNoYWlycyBhZ3Jl ZSB0aGF0IHRoZSBXRyBoYXMgY29uc2Vuc3VzIG9uIGEgc2luZ2xlIHNvbHV0aW9uIHRvIGF2b2lk IGludGVyb3BlcmFiaWxpdHksIGFuZCB0aGUgV0cgY2hhaXJzIGFja25vd2xlZGdlDQogdGhhdCBz b21lIFdHIG1lbWJlcnMgZmVlbCB0aGF0IHRoZSBtdWx0aXBsZSBmbGF2b3JzIGFyZSBhY3R1YWxs eSBtdWx0aXBsZSBzb2x1dGlvbnMsIGhvdyBpcyBpdCBwb3NzaWJsZSB0aGF0IHRoZSBXRyB3b3Vs ZCBhZGRyZXNzIHRoYXQgdGhpcyBpcyBhcyB2YWxpZCBhbmQgY29oZXJlbnQgd2l0aCBvbmUgZGF0 ZSBwbGFuZSBzb2x1dGlvbiBhcyB0aGUgb2JqZWN0aXZlLiZuYnNwOyBUaGUgdmFsaWQgYW5kIGNv aGVyZW50IHBhcnQgb2YgaG93IGEgbXVsdGlwbGUNCiBkYXRhIHBsYW5lIHNvbHV0aW9uIG9yIGZs YXZvciBtZWV0cyB0aGUgc2luZ2xlIGRhdGEgcGxhbmUgb2JqZWN0aXZlIGlzIGNvbnRyYWRpY3Rv cnkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7SSBiZWxpZXZlIHdoYXQgaXMgc3RhdGVkIGhlcmUgYnkgdGhlIGNoYWlycyBpcyBleGFj dGx5IHdoYXQgc2hvdWxkIGhhdmUgYmVlbiBjbGVhcmVkIHVwIHByaW9yIHRvIHRoZSBhZG9wdGlv biBjYWxsLCBidXQgbm93IGFzIHRoZSBhZG9wdGlvbiBjYWxsIGhhcyBzdGFydGVkDQogJm5ic3A7 d291bGQgYmUgY2xlYXJlZCB1cCBkdXJpbmcgdGhlIGFkb3B0aW9uIGNhbGwgcHJvY2Vzcy4mbmJz cDsgVGhpcyBpcyBzb21ld2hhdCBvZiBhIGNoZXNzIGdhbWUgYXMgdG8gd2hpY2ggd2F5IHRvIGhh dmUgcHJvY2VlZGVkLCBidXQgSSB0aGluayBnZXR0aW5nIHRoaXMgY2xlYXJlZCB1cCBwcmlvciB0 byB0aGUgY2FsbCBmb3IgYWRvcHRpb24gd291bGQgaGF2ZSBiZWVuIGJldHRlciBmb3IgdGhlIFdH LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkFs bCBXRyBtZW1iZXJzIHRoYXQgZmVlbCBzdHJvbmdseSB0aGF0IHRoZSB0d28gZW5kcG9pbnQgZmxh dm9ycyBhcmUgdHdvIGRpc3RpbmN0bHkgZGlmZmVyZW50IHNvbHV0aW9ucyB3aWxsIHN0aWNrIHRv IHRoZWlyIGd1bnMgYW5kIHN1cHBvcnQgbm90IGFkb3B0aW5nIHRoZSBkb2N1bWVudC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5BbGwgV0cgbWVt YmVycyB0aGF0IGFyZSBPayB3aXRoIHR3byBzb2x1dGlvbnMgdmVyc3VzIGEgc2luZ2xlIFNSVjYg Y29tcHJlc3Npb24gc29sdXRpb24gd2lsbCBjaG9zZSB0byBhZG9wdCB0aGUgZHJhZnQuICZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRo ZSBkb3duIHNpZGUgb2Ygbm90IHJlc29sdmluZyB0aGlzIGlzc3VlIHByaW9yIHRvIGFkb3B0aW9u IGNhbGwgJm5ic3A7aXMgdGhhdCB0aGVyZSBpcyBhIGNoYW5jZSB0aGUgbWFueSB0aGF0IGZlbHQg c3Ryb25nbHkgZm9yIGEgc2luZ2xlIHNvbHV0aW9uIGFzIHJpc2sgb2YgaW50ZXJvcGVyYWJpbGl0 eQ0KIGlzc3VlcyBhcyBhbGwgdmVuZG9ycyBkdWUgdG8gY29zdCBtYXkgbm90IHdhbnQgdG8gaW1w bGVtZW50IG11bHRpcGxlIGNvbXByZXNzaW9uIHNvbHV0aW9ucyBhbmQgbWF5IG5vdCBhbGwgcGlj ayB0aGUgc2FtZSBjb21wcmVzc2lvbiBzb2x1dGlvbi4gJm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+U28gdGhlcmUgY291bGQgYmUgYSB1 bmFuaW1vdXMgdm90ZSB0byBub3QgYWRvcHQgYXMgdGhpcyBnb2VzIGFnYWluc3QgdGhlIFdHIGNv bnNlbnN1cyBvbiBhIHNpbmdsZSBkYXRhIHBsYW5lIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkkgYWdyZWUgdGhhdCBpcyBub3Qg YSBtYWpvciByaXNrIGdvaW5nIHRoaXMgcm91dGUgYXMgdGhlIGRyYWZ0IHdvdWxkIGJlIGtpY2tl ZCBiYWNrIHRvIHRoZSBhdXRob3JzIHRvIHJldmlzZSBhbmQgcGljayBvbmUgb2YgdGhlIGZsYXZv cnMgdG8gcHV0IGZvcndhcmQgZm9yIGFkb3B0aW9uLg0KICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBmbGlwIHNpZGUg aXMgd2UgYXJlIGJhY2sgdG8gdGhlIGRyYXdpbmcgYm9hcmQgd2l0aCB0aGUgRFQgb24gV0cgY29u c2Vuc3VzIG9uIGEgY29tcHJlc3Npb24gc29sdXRpb24gdG8gYWdyZWUgdG8gZm9yIGFuIGFkb3B0 aW9uIGNhbGwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+S2luZCBSZWdhcmRzJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+R3lhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+T24gRnJpLCBPY3QgMSwgMjAyMSBhdCA0OjU1IFBNIFRvbnkg TGkgJmx0OzxhIGhyZWY9Im1haWx0bzp0b255LmxpQHRvbnkubGkiIHRhcmdldD0iX2JsYW5rIj50 b255LmxpQHRvbnkubGk8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPisxPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPkkgb2JqZWN0IHRvIHRoZSBhZG9wdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5Ub255PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi Pk9uIE9jdCAxLCAyMDIxLCBhdCAxOjQzIFBNLCBBbmRyZXcgQWxzdG9uICZsdDs8YSBocmVmPSJt YWlsdG86QW5kcmV3LkFsc3Rvbj00MGxpcXVpZHRlbGVjb20uY29tQGRtYXJjLmlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+QW5kcmV3LkFsc3Rvbj00MGxpcXVpZHRlbGVjb20uY29tQGRtYXJjLmll dGYub3JnPC9hPiZndDsNCiB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiPkp1c3QgdG8gYWRkIHRvIHRoaXMsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBhbSBvbmUgb2YgdGhlIHBlb3Bs ZSB3aG8gY2xlYXJseSBzdGF0ZWQgdGhhdCBJIGRpZG7igJl0IHRoaW5rIGEgc2luZ2xlIHNvbHV0 aW9uIHdhcyB0aGUgcmlnaHQgYW5zd2VyIGhlcmUg4oCTIGFuZCBJIHN0YXRlZCBteSByZWFzb25p bmcgY2xlYXJseSBvbiB0aGlzIGxpc3QuJm5ic3A7IEkNCiBzdGlsbCBiZWxpZXZlIHRoYXQg4oCT IGhvd2V2ZXIg4oCTIEkgcmVjb2duaXplIHRoYXQgdGhlIGZvdW5kYXRpb24gb2YgdGhlIElFVEYg aXMgZm91bmQgaW4gdGhlIGJvdHRvbSB1cCBjb25zZW5zdXMgYXBwcm9hY2gg4oCTIGFuZCB3aGVu IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBkZW1vbnN0cmF0ZWQgc3VjaCBjbGVhciBjb25zZW5zdXMg 4oCTIHRvIGRlZnkgdGhhdCDigJMgaXMgdG8gZGVmeSB3aGF0IG1ha2VzIHRoZSBJRVRGIHRoZSBJ RVRGLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi PlNvIOKAkyBXaGlsZSBJIHN0aWxsIGJlbGlldmUgaW4gbXVsdGlwbGUgc29sdXRpb25zIOKAkyBp cnJlc3BlY3RpdmUgb2YgdGhhdCDigJMgSSBmaW5kIHRoaXMgY2FsbCBhcHBhbGxpbmcg4oCTIGJl Y2F1c2UgYXMgbXVjaCBhcyBJIGJlbGlldmUgaW4gbXVsdGlwbGUgc29sdXRpb25zIOKAkyB0aGUN CiB3b3JraW5nIGdyb3VwIGNvbnNlbnN1cyBzaG91bGQgYmUgc2Fjcm9zYW5jdC48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5BbmRyZXc8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIu MHB0Ij5Gcm9tOiZuYnNwOzwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5BbmRyZXcgQWxzdG9uICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmV3LkFs c3RvbkBsaXF1aWR0ZWxlY29tLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjojMDU2M0MxIj5BbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tPC9zcGFuPjwvYT4mZ3Q7 PGJyPg0KPGI+RGF0ZTombmJzcDs8L2I+RnJpZGF5LCAxIE9jdG9iZXIgMjAyMSBhdCAyMzoyMTxi cj4NCjxiPlRvOiZuYnNwOzwvYj5KYW1lcyBHdWljaGFyZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmph bWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDU2M0MxIj5qYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb208L3NwYW4+PC9h PiZndDssIFNQUklORyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDU2M0MxIj5zcHJpbmdAaWV0Zi5vcmc8 L3NwYW4+PC9hPiZndDs8YnI+DQo8Yj5DYzombmJzcDs8L2I+PGEgaHJlZj0ibWFpbHRvOnNwcmlu Zy1jaGFpcnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzA1 NjNDMSI+c3ByaW5nLWNoYWlyc0BpZXRmLm9yZzwvc3Bhbj48L2E+Jm5ic3A7Jmx0OzxhIGhyZWY9 Im1haWx0bzpzcHJpbmctY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwNTYzQzEiPnNwcmluZy1jaGFpcnNAaWV0Zi5vcmc8L3NwYW4+PC9hPiZndDs8 YnI+DQo8Yj5TdWJqZWN0OiZuYnNwOzwvYj5SZTogV0cgQWRvcHRpb24gY2FsbCBmb3ImbmJzcDs8 YSBocmVmPSJodHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmRyYWZ0LWZpbHNm aWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uJTJGJmFtcDtkYXRhPTA0JTdDMDEl N0NqYW1lcy5uLmd1aWNoYXJkJTQwZnV0dXJld2VpLmNvbSU3QzI1ZGEzNjUwMGI5ZDQ1YTcxMjUw MDhkOTg1MzJkYmMwJTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMCU3 QzYzNzY4NzI3NTc4MTYwNzY1OSU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdM akF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0Mx MDAwJmFtcDtzZGF0YT1yYWVsaVBEZEFFM1hXZVZPVkFVVlFBRG8wUVpuQiUyRkZiSkY1M2lBNU0x QlElM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6 IzA1NjNDMSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNj aGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPlNvcnJ5IOKAkyBidXQg4oCTIEni gJltIGEgbGl0dGxlIGNvbmZ1c2VkIGhlcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+QmVjYXVzZSB0aGUgd2F5IEkgbG9vayBhdCB0aGlzIOKA kyB0aGUgd29ya2luZyBncm91cCBjbGVhcmx5IHN0YXRlZCB0aGF0IHRoZXkgd2lzaGVkIGZvciBh IHNpbmdsZSBiZWhhdmlvciDigJMgYW5kIHRoaXMg4oCTIGRvZXMgbm90IGRlbGl2ZXIgdGhhdCDi gJMgaXQgaXMgdHdvIHNlcGFyYXRlDQogYmVoYXZpb3JzLiZuYnNwOyBBcyBzdWNoIOKAkyBJIHNl ZSB0aGlzIGNhbGwgZm9yIGFkb3B0aW9uIOKAkyBpcnJlc3BlY3RpdmUgb2YgdGhlIG1lcml0cyBv ciBsYWNrIHRoZXJlb2Ygb2YgdGhlIGRyYWZ0LCBhcyBhIGNsZWFyIGRlZmlhbmNlIG9mIHRoZSBz dGF0ZWQgd2lsbCBvZiB0aGUgd29ya2luZyBncm91cC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlzIGlzIHNpbXBseSBkb2VzIG5vdCBmaXQg aW50byB0aGUgZGVmaW5pdGlvbiBvZiBib3R0b20gdXAgYXBwcm9hY2ggaW4gbXkgb3BpbmlvbiDi gJMgYW5kIGlmIHRoaXMgaXMgdGhlIHdheSB0aGF0IHRoZSBjaGFpcnMgd2lzaCB0byBwcm9jZWVk IOKAkyB0aGVuIHRoZSBvbmx5IHdheQ0KIHRvIGRvIHRoYXQgYW5kIHN0aWxsIGZpdCB3aXRoaW4g dGhlIGJvdHRvbSB1cCBhcHByb2FjaCBpcyB0byBmaXJzdCBhc2sgdGhpcyB3b3JraW5nIGdyb3Vw IGZvciBpdHMgY29uc2Vuc3VzIHRvIGRldmlhdGUgZnJvbSB0aGUgc2luZ2xlIGJlaGFjdmlvciBh cHByb2FjaCB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGFncmVlZCB0by48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5BcyBzdWNoIOKAkyBJIG11c3Qg Jm5ic3A7c3Ryb25nbHkgYW5kIHVuZXF1aXZvY2FsbHkgb2JqZWN0IHRvIHRoaXMgY2FsbCBmb3Ig YWRvcHRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj5BbmRyZXc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5Gcm9tOiZu YnNwOzwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij5zcHJpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnNwcmluZy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsNCiBvbiBiZWhhbGYg b2YgSmFtZXMgR3VpY2hhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGZ1 dHVyZXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5qYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5j b208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6Jm5ic3A7PC9iPkZyaWRheSwgMSBPY3RvYmVyIDIwMjEg YXQgMTc6MDU8YnI+DQo8Yj5UbzombmJzcDs8L2I+U1BSSU5HIFdHICZsdDs8YSBocmVmPSJtYWls dG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPiZn dDs8YnI+DQo8Yj5DYzombmJzcDs8L2I+PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1jaGFpcnNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmctY2hhaXJzQGlldGYub3JnPC9hPiAmbHQ7PGEg aHJlZj0ibWFpbHRvOnNwcmluZy1jaGFpcnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJp bmctY2hhaXJzQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiZuYnNwOzwvYj5bc3By aW5nXSBXRyBBZG9wdGlvbiBjYWxsIGZvciA8YSBocmVmPSJodHRwczovL25hbTExLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5p ZXRmLm9yZyUyRmRvYyUyRmRyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXBy ZXNzaW9uJTJGJmFtcDtkYXRhPTA0JTdDMDElN0NqYW1lcy5uLmd1aWNoYXJkJTQwZnV0dXJld2Vp LmNvbSU3QzI1ZGEzNjUwMGI5ZDQ1YTcxMjUwMDhkOTg1MzJkYmMwJTdDMGZlZThmZjJhM2IyNDAx ODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMCU3QzYzNzY4NzI3NTc4MTYxNzY1MyU3Q1Vua25vd24l N0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJ NklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFtcDtzZGF0YT14bzdPclJVS0Q0SlF0QWgy JTJCa29qUFM5WlV1b29MdkZBWmFBNktHRTBlS00lM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0i X2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxz Y2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLzwvYT48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkRlYXIgV0c6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGNoYWlycyB3b3VsZCBsaWtl IHRvIGV4cHJlc3MgdGhlaXIgYXBwcmVjaWF0aW9uIGZvciBhbGwgdGhlIHJlc3BvbnNlcyByZWNl aXZlZCB0byBvdXIgZW1haWxzIHdpdGggcmVmZXJlbmNlIHRvIGhvdyB0aGUgd29ya2luZyBncm91 cCB3aXNoZXMgdG8gbW92ZSBmb3J3YXJkDQogd2l0aCByZXNwZWN0IHRvIGEgc29sdXRpb24gZm9y IFNSdjYgY29tcHJlc3Npb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+VGhlIGFwcGFyZW50IGluY2xpbmF0aW9uIG9mIHRoZSB3b3JraW5nIGdy b3VwIGlzIHRvIHVzZSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmFtMTEuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3Jn JTJGZG9jJTJGZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24l MkYmYW1wO2RhdGE9MDQlN0MwMSU3Q2phbWVzLm4uZ3VpY2hhcmQlNDBmdXR1cmV3ZWkuY29tJTdD MjVkYTM2NTAwYjlkNDVhNzEyNTAwOGQ5ODUzMmRiYzAlN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNh MWQ1NTkxZmVkYyU3QzElN0MwJTdDNjM3Njg3Mjc1NzgxNjE3NjUzJTdDVW5rbm93biU3Q1RXRnBi R1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFX d2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRhPXhvN09yUlVLRDRKUXRBaDIlMkJrb2pQ UzlaVXVvb0x2RkFaYUE2S0dFMGVLTSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjojMDU2M0MxIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88L3Nw YW4+PC9hPiZuYnNwO2FzDQogdGhlIGJhc2lzIGZvciBpdHMgY29tcHJlc3Npb24gc3RhbmRhcmRp emF0aW9uIHdvcmsuIFRoYXQgaXMgcGFydCBvZiB3aGF0IHRoaXMgZW1haWwgYXR0ZW1wdHMgdG8g Y29uZmlybS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj5CZWNhdXNlIG9mIHRoZSBhYm92ZSB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gaXNzdWUg YSAyLXdlZWsgV0cgY2FsbCBmb3IgYWRvcHRpb24gZW5kaW5nIE9jdG9iZXIgMTU8c3VwPnRoPC9z dXA+Jm5ic3A7Zm9yJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9uYW0xMS5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmcl MkZkb2MlMkZkcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbiUy RiZhbXA7ZGF0YT0wNCU3QzAxJTdDamFtZXMubi5ndWljaGFyZCU0MGZ1dHVyZXdlaS5jb20lN0My NWRhMzY1MDBiOWQ0NWE3MTI1MDA4ZDk4NTMyZGJjMCU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2Ex ZDU1OTFmZWRjJTdDMSU3QzAlN0M2Mzc2ODcyNzU3ODE2Mjc2NTElN0NVbmtub3duJTdDVFdGcGJH WnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3 aUxDSlhWQ0k2TW4wJTNEJTdDMTAwMCZhbXA7c2RhdGE9M3NXY3Z1VzNNQkR4NU44Mk4zZk9pNDNE QzJvMmZ2dUlHWUZRJTJCZTB4cEVZJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMwNTYzQzEiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLzwvc3Bh bj48L2E+Jm5ic3A7YnV0DQogd2l0aCBzb21lIGNsZWFyIGd1aWRlbGluZXMgYXMgZm9sbG93cy4g QnkgZXhwcmVzc2luZyBzdXBwb3J0IGZvciBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IHlvdSBh cmUgZnVsbHkgYXdhcmUgb2YgYW5kIGFyZSBhY2tub3dsZWRnaW5nIHRoYXQ6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8b2wgc3Rh cnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZl bDEgbGZvMiI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+VGhlIFNQUklORyB3b3JraW5nIGdyb3VwIGlz IGFkb3B0aW5nIGEgZG9jdW1lbnQgdGhhdCBoYXMgbXVsdGlwbGUgU1J2NiBFbmRwb2ludCBiZWhh dmlvcnMuPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0OmwwIGxldmVsMSBsZm8yIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgZG9jdW1lbnQgaXMg YSDigJxsaXZpbmfigJ0gZG9jdW1lbnQ7IGl0IG1heSBjaGFuZ2UgYXMgaXQgZ29lcyB0aHJvdWdo IHJldmlldyBhbmQgYW5hbHlzaXMgYnkgdGhlIFNQUklORyB3b3JraW5nIGdyb3VwLjxvOnA+PC9v OnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEg bGZvMiI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+QWxsIG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgcmFp c2VkIG9uIG91ciBtYWlsaW5nIGxpc3QgTVVTVCBiZSBhZGRyZXNzZWQgQkVGT1JFIHNhaWQgZG9j dW1lbnQgaXMgYWxsb3dlZCB0byBwcm9ncmVzcyBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIHRvIHB1 YmxpY2F0aW9uLiBBIGxpc3Qgb2YgdGhlc2UgZGlzY3Vzc2lvbiBwb2ludHMgd2lsbCBiZSBkb2N1 bWVudGVkIGluIHRoZSBXRyBkb2N1bWVudCBhbmQgbWFpbnRhaW5lZA0KIGJ5IHRoZSBkb2N1bWVu dCBlZGl0b3IgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgY2hhaXJzLjxvOnA+PC9vOnA+PC9zcGFu PjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8 c3BhbiBsYW5nPSJFTi1VUyI+SWYgdGhpcyBkb2N1bWVudCBpcyBhZG9wdGVkIGJ5IHRoZSB3b3Jr aW5nIGdyb3VwLCB0aGUgY2hhaXJzIHNwZWNpZnkgYXMgcGFydCBvZiB0aGUgYWRvcHRpb24gY2Fs bCB0aGF0IHRoZSBmb2xsb3dpbmcgdGV4dCBkZXNjcmliaW5nIGFuIG9wZW4gaXNzdWUgYmUgYWRk ZWQgdG8gdGhlIGRvY3VtZW50IGluIHRoZSBhYm92ZS1kZXNjcmliZWQgb3BlbiBpc3N1ZXMgc2Vj dGlvbjo8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvb2w+DQo8b2wgc3RhcnQ9IjQiIHR5cGU9IjEi Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBs ZXZlbDIgbGZvMyI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+JnF1b3Q7R2l2ZW4gdGhhdCB0aGUgd29y a2luZyBncm91cCBoYXMgc2FpZCB0aGF0IGl0IHdhbnRzIHRvIHN0YW5kYXJkaXplIG9uZSBkYXRh IHBsYW5lIHNvbHV0aW9uLCBhbmQgZ2l2ZW4gdGhhdCB0aGUgZG9jdW1lbnQgY29udGFpbnMgbXVs dGlwbGUgU1J2NiBFbmRQb2ludCBiZWhhdmlvcnMgdGhhdCBzb21lIFdHIG1lbWJlcnMgaGF2ZSBz dGF0ZWQgYXJlIG11bHRpcGxlIGRhdGEgcGxhbmUgc29sdXRpb25zLCB0aGUgd29ya2luZw0KIGdy b3VwIHdpbGwgYWRkcmVzcyB3aGV0aGVyIHRoaXMgaXMgdmFsaWQgYW5kIGNvaGVyZW50IHdpdGgg aXRzIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uIG9iamVjdGl2ZS4mcXVvdDsuPG86cD48L286cD48 L3NwYW4+PC9saT48L3VsPg0KPC9vbD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5QbGVhc2UgY29u c2lkZXIgdGhlIGFib3ZlIGd1aWRlbGluZXMgYXMgeW91IGRlY2lkZSBvbiB3aGV0aGVyIHRvIHN1 cHBvcnQgb3Igbm90IHRoaXMgV0cgYWRvcHRpb24uIFBsZWFzZSBleHByZXNzIGNsZWFybHkgeW91 ciByZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9uLXN1cHBvcnQNCiBhcyB3ZWxsIGFzIGFueSBvcGVu IGRpc2N1c3Npb24gcG9pbnRzIHlvdSB3b3VsZCBsaWtlIGFkZHJlc3NlZCBzaG91bGQgdGhlIGRv Y3VtZW50IGJlIGFkb3B0ZWQgaW50byB0aGUgd29ya2luZyBncm91cC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MhPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SmltLCBCcnVubyAmYW1w OyBKb2VsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFp bHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2su Y29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZtYWlsbWFuJTJGbGlzdGluZm8l MkZzcHJpbmcmYW1wO2RhdGE9MDQlN0MwMSU3Q2phbWVzLm4uZ3VpY2hhcmQlNDBmdXR1cmV3ZWku Y29tJTdDMjVkYTM2NTAwYjlkNDVhNzEyNTAwOGQ5ODUzMmRiYzAlN0MwZmVlOGZmMmEzYjI0MDE4 OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MwJTdDNjM3Njg3Mjc1NzgxNjI3NjUxJTdDVW5rbm93biU3 Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2 SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRhPTNFYmVxWkNDOFZ1JTJCOGg1 NkNXNk41WiUyQnVEMDBOMnN2JTJCTHppaHJIN2Y2aUUlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzwv YT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNw cmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL25hbTExLnNhZmVsaW5rcy5w cm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZt YWlsbWFuJTJGbGlzdGluZm8lMkZzcHJpbmcmYW1wO2RhdGE9MDQlN0MwMSU3Q2phbWVzLm4uZ3Vp Y2hhcmQlNDBmdXR1cmV3ZWkuY29tJTdDMjVkYTM2NTAwYjlkNDVhNzEyNTAwOGQ5ODUzMmRiYzAl N0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MwJTdDNjM3Njg3Mjc1Nzgx NjM3NjQxJTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlq b2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRh PWs4WHptM1BLRVdEZCUyRkV5T1VFb2x1ajNram1UaGtMajdlTExsbVBKcUlaWSUzRCZhbXA7cmVz ZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc3ByaW5nPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4t LQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPjxh IGhyZWY9Imh0dHBzOi8vbmFtMTEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwJTNBJTJGJTJGd3d3LnZlcml6b24uY29tJTJGJmFtcDtkYXRhPTA0JTdDMDElN0NqYW1l cy5uLmd1aWNoYXJkJTQwZnV0dXJld2VpLmNvbSU3QzI1ZGEzNjUwMGI5ZDQ1YTcxMjUwMDhkOTg1 MzJkYmMwJTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMCU3QzYzNzY4 NzI3NTc4MTYzNzY0MSU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURB aUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFt cDtzZGF0YT1mZmxPQVF2WlhRMWYzJTJCQ29PaWNTZ2REdiUyQjd3ZEtDUDR2Y1owaGF5QjFCQSUz RCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj48c3BhbiBzdHlsZT0iY29sb3I6IzExNTVDQzti b3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbSI+PGltZyBib3JkZXI9IjAi IHdpZHRoPSI4MSIgaGVpZ2h0PSIxOCIgc3R5bGU9IndpZHRoOi44NDM3aW47aGVpZ2h0Oi4xODc1 aW4iIGlkPSJtXy01NDQzNTcyMDE3NzIzMDk1MzU1X3gwMDVmX3gwMDAwX2kxMDI1IiBzcmM9ImNp ZDp+V1JEMDAwMS5qcGciIGFsdD0iSW1hZ2UgcmVtb3ZlZCBieSBzZW5kZXIuIj48L3NwYW4+PC9z cGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbSI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5HeWFuIE1pc2hyYTwvc3Bhbj48L2I+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46MGNtIj48aT48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDss c2VyaWY7Y29sb3I6YmxhY2siPk5ldHdvcmsgU29sdXRpb25zIEFyY2hpdGVjdCZuYnNwOzwvc3Bh bj48L2k+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46MGNtIj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+RW1h aWwNCjxhIGhyZWY9Im1haWx0bzpneWFuLnMubWlzaHJhQHZlcml6b24uY29tIiB0YXJnZXQ9Il9i bGFuayI+Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbTwvYT48L3NwYW4+PC9pPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2Vv cmdpYSZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+TSAzMDEgNTAyLTEzNDc8L3NwYW4+PC9pPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMjIyMjIiPjxhIGhyZWY9Imh0dHA6Ly93 d3cudmVyaXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzIyMjIy Mjt0ZXh0LWRlY29yYXRpb246bm9uZSI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxMTU1Q0M7Ym9yZGVy OnNvbGlkIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20iPjxpbWcgYm9yZGVyPSIwIiB3aWR0 aD0iODEiIGhlaWdodD0iMTgiIHN0eWxlPSJ3aWR0aDouODQzN2luO2hlaWdodDouMTg3NWluIiBp ZD0iX3gwMDAwX2kxMDI1IiBzcmM9ImNpZDp+V1JEMDAwMS5qcGciIGFsdD0iSW1hZ2UgcmVtb3Zl ZCBieSBzZW5kZXIuIj48L3NwYW4+PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBzdHlsZT0ibWFyZ2luOjBjbTttc28tbGluZS1oZWlnaHQtYWx0OjkuNzVwdCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPkd5YW4gTWlzaHJhPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgc3R5bGU9Im1hcmdpbjowY207bXNvLWxpbmUtaGVpZ2h0LWFsdDo5Ljc1cHQiPjxpPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LHNlcmlmO2NvbG9yOmJs YWNrIj5OZXR3b3JrIFNvbHV0aW9ucyBBcmNoaXRlY3QmbmJzcDs8L3NwYW4+PC9pPjxzcGFuIHN0 eWxlPSJjb2xvcjojMjIyMjIyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFy Z2luOjBjbTttc28tbGluZS1oZWlnaHQtYWx0OjkuNzVwdCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OyxzZXJpZjtjb2xvcjpi bGFjayI+RW1haWwNCjxhIGhyZWY9Im1haWx0bzpneWFuLnMubWlzaHJhQHZlcml6b24uY29tIiB0 YXJnZXQ9Il9ibGFuayI+Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbTwvYT48L3NwYW4+PC9pPjxz cGFuIHN0eWxlPSJjb2xvcjojMjIyMjIyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206 MTIuMHB0O21hcmdpbi1sZWZ0OjBjbTttc28tbGluZS1oZWlnaHQtYWx0OjkuNzVwdCI+DQo8aT48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7R2VvcmdpYSZxdW90OyxzZXJpZjtjb2xvcjpi bGFjayI+TSAzMDEgNTAyLTEzNDc8L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_502AD3A77352471CB17F0DBD57B771D7liquidtelecomcom_-- From nobody Mon Oct 4 10:10:58 2021 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 718B23A09E8; Mon, 4 Oct 2021 10:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=D9lHZaGL; dkim=pass (1024-bit key) header.d=juniper.net header.b=Y3obk4nt 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 0Y-HD_BRD7Vo; Mon, 4 Oct 2021 10:10:30 -0700 (PDT) Received: from mx0b-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 88F2E3A09E1; Mon, 4 Oct 2021 10:10:30 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 194EjetV002953; Mon, 4 Oct 2021 10:10:28 -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=Hq1yFPcdIlIh3EDqv5uc5FA7oNiMMZO75U8zasjZqoI=; b=D9lHZaGLwEzbTALiMjEPSHWTZyaXUKHzagMhSEyQ0q6V6bvOFjYHBBF37dMU+z9kYALu FhUesezp6iCGw3Yj9/l5JifJTpJKFty2tLGttJyUuEL/kHUZR47NALED47xpsUQ+tEQg M72wslYE8N/sc6AmvH+i3RyAnYowXG6X5D6xyMBZhfp3A6riBTAmxUODm3UwvMQlHDkB TbpTJT2yy1Le08k7rTxAOwVSSv1kIcMQ4Ctc4Y6/bHhMF+VI2Vrnyx88/T9uAYLod4a1 jn1IKtDyR21YhhiHBvwXAFhUvq5+WgFGqY2R96T+bTbcOQKpSFG0BP4ggAO7c85qd1Py NQ== Received: from nam04-dm6-obe.outbound.protection.outlook.com (mail-dm6nam08lp2043.outbound.protection.outlook.com [104.47.73.43]) by mx0a-00273201.pphosted.com with ESMTP id 3bg1c70h9w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Oct 2021 10:10:28 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MNDP7Y28kgXfKELqoeYzV3bS0xew9igktXS8jJQIPTCpD/j4nvQhwSFkjcK31d0O1H/LX/qwcT/oNmF7/1Fl5i2N7EvprtCNxy5JcaIvnXXZztXCAJTlco/IOiBon8G1wFuxqU/oiJoWSymj3YcEf/p6MsHgbqgiZVsi3yTKITOaMABSFQqDBDatMrJHZOsYf4+mf2DeNGoG6ZxE4Z1v8RkQRx1l3lcEXNRZ98HD37lDqtOVChlB+kG+XH1nMu2QGD1TcSgHuaM0q9flWOZ7Vjty1esY/ry4/r0kPgtHagqBLE+1Z1AtzgrG9uTnkligKI3F3aQVHNvNEYq2hMgtaQ== 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=Hq1yFPcdIlIh3EDqv5uc5FA7oNiMMZO75U8zasjZqoI=; b=Yy9/MnINzvdY1QGnBjqgccXYkOryBq0mQIstv8GizHsV51X/ZDlQNILA2UILiUgZXzUQN6ljit4ggxt8fY6qzmcWMMsCD3je6Nv/RUs37bWUxJT+riwbT94iUXj05HxUtNvxADQTIHs0DZdkNhusimUnnn64zGKR7vtfD7NgcxRA2YlLR5E+mLNDjRkJeVl/YylckX1FFz25ik37pKv3FnCnQ5rjwsru2reH6shK4uoTUIawA6TVBbH5n2aCwFkgIiAvrZaoBixsscxqPJ/hc4GqzNChssjGvLvqm42wNOVyKsFEGd7hXGIVXZhuVHFJg2HcQNPdinT6MgAZc6dikw== 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=Hq1yFPcdIlIh3EDqv5uc5FA7oNiMMZO75U8zasjZqoI=; b=Y3obk4ntL3H1z6FD7a+8oK4IcZq2CSO+UG4DAHrlhy5z0Ss37bPVLOKin809mTto0WRuwgABiGkw7EmiHNnkz+9KZYM/WSguMleOjTkv95x+fBSR1rpifGCasQginXPBjYNg1+b75+TDEXez0qmbcRRqcbBaSlr0vhY1sJXQ8Ig= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by BL0PR05MB5105.namprd05.prod.outlook.com (2603:10b6:208:82::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.16; Mon, 4 Oct 2021 17:10:23 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4587.016; Mon, 4 Oct 2021 17:10:23 +0000 From: Ron Bonica To: Gyan Mishra , "Darren Dukes (ddukes)" CC: "srcomp@ietf.org" , SPRING WG Thread-Topic: [spring] [srcomp] compression analysis draft question on proposals analyzed Thread-Index: AQHXs8Ra50F8CwoW906pGS4CWV970Ku/oAUAgAN9XqA= Date: Mon, 4 Oct 2021 17:10:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-04T17:10:22Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=b67116e5-5cc4-4cc5-b853-d253aa713198; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 49f8edb0-745f-43fa-f906-08d98759da81 x-ms-traffictypediagnostic: BL0PR05MB5105: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4502; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7F30k7DLprX5MpJrrz97Lf4B1mCd4wGy9/tSvabmHoMtYMnqcIvf2SHg4NvHVfMYwpLxxJZJOGWbrFbb6hdV3tPMNEYOYvDLq8ZFSK87VPYTzHp0K+A+COz2ahqr69fgATS4yIr8Ltc8WyQN+nE6nb4h1IXgblVxUeNbrj+ZRE11KKIMV6EZi30Spyb4QWNEi6jnls7ZB1MGetekpuHFLyTTjukx8Ndz1dv0ToJC69ATvp5iL792h2+7JLspreG9gLp9lxz/Jw+k5KMFHI5QHcFjBPv3W4O6tsnP2IyMgc4SllHFlqsQtPkD2rAimyIREbjgJ+YbEakFL2gQwZNwXc2Eu9dAxNPzw6CHa7y/E+9r48kK3oJL6gzHAS9soSo+htSe5+LvVgcvs6InAIhOQjqHey5LuvqbSCKa72KKZvGsl76wGNHQkf6YiK/I1l/2f8ctC6ye7MB1+dIn3sZfRBfm9E5JLsH9DwcRnbmpIZFAjpmi3FTFjHwJ7xDtX+otHuf5kVpCJF8dGSMhkmT+zHWMM80W2Ew+YpCJT5v4vAbAvOgTBKQg7u2oj9DxJRoApyzpQnKp+Tt0dlqS/sp83DpBC24yyWEuxqCrOKK06WlTmXZq2lDoe2hWyL4UHXtHXrsWekyEa8CClQEKy8z0fnaNLy+fkjOBzIprdUgs+xpvT8G1SygrwhKKK7b3G4fBVtdr8ffvWATCvgY0mee0gZU3Sfv8WKAa4qEWHOXoob7XRtIYARxgLwRs3JI99RH6YtsSic+hW8Ipgsrbk5SjojuixwkqbXavh+kToztC8EshT172wM1BQcNGGHRd0bObaP+Csbvdt+unn8f2wQbVsA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66556008)(64756008)(66446008)(86362001)(66476007)(66946007)(166002)(7696005)(71200400001)(966005)(8936002)(122000001)(508600001)(38100700002)(316002)(38070700005)(26005)(110136005)(5660300002)(55016002)(8676002)(186003)(2906002)(4326008)(83380400001)(53546011)(33656002)(6506007)(54906003)(76116006)(40140700001)(9686003)(52536014); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: T5KiJXbUoNcdAHofL0Vg/ZyEuGc8ZYPzoASqM+sno1pVBwI6X8bQxs7yTlV7DSdlY4Nrq+Ms8beYc0lj0SOZDRMcBVFsuxrNOul6ffh2kuNSCuQvfXnEDTvBeV00AhHeRDKF8ZaskD/EeiDFYwjq8C3wcq/pVamXI2bVcsgcX5CS0r9r/2STXbmCzlkbggi8sSfRLdGRYQ4+5Js0TL7mC8It6ly4eAmX0iu51oSDVPSK2fqVbBkqDJwRnCieke5PBD5BrI2P9AB8Til6dP2E4VXIxWG3vyB2CuS1ksMyor5C4i0CiWvCv/YNBLCFlBvt02wLOQbuGIr2SheCBldi3d1PPvbugAP4yw99Z7N2RQpCtLOzhVI2dnB9NxxGY8hhaFNCS92PrGlut53M3aRGnPpHE2O6lf0cA/LqLGD63dtw8K9uuy3sz4jbenqdxA7IFwoSrpvn9Tf4y4HIf9DHHLr+7KG0vBxe40OGKTWsCTBLD9p6r9QJHIJGs7tM9aHDLZdUBEmWZnNCBupSRoeu8dtBNiDWvJ3suo+Jbd/A9KCAsEDe0lrYnZ6YP2yCcIlaxXLsaQDbpg8V+A9BtZjHwQwqtc+nGxmlLXs8HeU9nMzKbsD1A/BTxXNMuHAHT9/9JX5cHvT5hr4m3yIOc5WZ+sLSh0I3V5du4seyHdV44Xd/jrFc7ZDastLEHzPBGdwVnNNPVWVjzk/cFjtmA0LSJw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR05MB531651A259CAB89166E29675AEAE9BL0PR05MB5316namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 49f8edb0-745f-43fa-f906-08d98759da81 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2021 17:10:23.6026 (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: eVY6HMwUBzHd+FdYuAXi+Bza/vg3lDq+NXVRP1mhuzZE8fDrdCngEaWpl6gvqdKvAMfof6RDz30axR2ADjvs9w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5105 X-Proofpoint-ORIG-GUID: cOY3qqeWwsf8ln8AkXknxedWNb_IUkQ8 X-Proofpoint-GUID: cOY3qqeWwsf8ln8AkXknxedWNb_IUkQ8 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-04_05,2021-10-04_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 impostorscore=0 clxscore=1011 lowpriorityscore=0 mlxlogscore=999 bulkscore=0 adultscore=0 malwarescore=0 mlxscore=0 spamscore=0 phishscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110040117 Archived-At: Subject: Re: [spring] [srcomp] compression analysis draft question on proposals analyzed 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, 04 Oct 2021 17:10:36 -0000 --_000_BL0PR05MB531651A259CAB89166E29675AEAE9BL0PR05MB5316namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable And more specifically, all of the tables in Section A.2 will be modified, r= eplacing the C-SID column with one column for NEXT-C-SID, one column for RE= PLACE-C-SID, and one column for NEXT-AND-REPLACE-C-SID Ron Juniper Business Use Only From: spring On Behalf Of Gyan Mishra Sent: Saturday, October 2, 2021 7:51 AM To: Darren Dukes (ddukes) Cc: srcomp@ietf.org; SPRING WG Subject: Re: [spring] [srcomp] compression analysis draft question on propo= sals analyzed [External Email. Be cautious of content] Thanks Darren! On Mon, Sep 27, 2021 at 1:23 PM Darren Dukes (ddukes) > wrote: Was: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02#sectio= n-4.1.1 I'm sending this note to redirect this question to the srcomp DT for an edi= torial fix, when the team meets next. For the DT: Each proposal, introduced in section 1, discusses how it supports 16-bit an= d 32-bit SIDs. However, Gyan's question indicates this could be more clearl= y stated in the analysis draft to help readers less familiar with a proposa= l. As such, section 1 can be improved accordingly. Darren On 2021-09-24, 1:32 PM, "spring" > wrote: Gyan, You raise a very good point. In the analysis document, Tables 1 through 6 a= nd Tables 12 through 15 each contain only one column for the CSID. They do = not indicate whether the number in that column were calculated using the NE= XT-C-SID, REPLACE-C-SID, or NEXT-AND-REPLACE-C-SID. (That is, the do not in= dicate whether they were calculated using uSID, G-SID, or a combination of = both). Each of these tables should be modified, so that the CSID column is replace= d by three columns (NEXT-C-SID, REPLACE-C-SID, and NEXT-AND-REPLACE-C-SID). If the numbers in these columns are different from one another, this may in= form our discussion about whether NEXT-C-SID, REPLACE-C-SID, and NEXT-AND-R= EPLACE-C-SID are different behaviors or different flavors of a behavior. = Ron Juniper Business Use Only From: spring > On B= ehalf Of Gyan Mishra Sent: Friday, September 24, 2021 9:56 AM To: SPRING WG >; draft-filsfilschen= g-spring-srv6-srh-compression@ietf.org; spring-chairs@ietf.org Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02#se= ction-4.1.1 [External Email. Be cautious of content] Dear Spring Authors Please respond to this question the WG has related to which of the three SR= v6 forwarding mechanisms called flavors was inclusive of the compression a= nalysis draft. The Analysis draft is ambiguous as to which SRv6 forwarding plane flavor wa= s part of the analysis. This is a critical question that has come up by the WG and Chairs, and answ= ering this question will help pave the way to an adoption call for C-SID. Kind Regards Gyan On Sun, Sep 19, 2021 at 3:33 PM Gyan Mishra > wrote: Dear Authors After having a few discussions on threads related to the SRv6 compression a= nalysis draft results, as well as WG coming to consensus on a single SRv6 c= ompression solution, a few critical questions have come up related to C-SID= draft that requires clarification by the authors. The C-SID draft has 3 compression solutions below and is a combination of t= he two drafts below which introduces 2 of the 3 compression solutions with = the C-SID draft introduction of yet a 3rd compression solution. Which of the 3 C-SID draft compression solutions was included as part of th= e DT analysis draft results and conclusion? This is a critical question that needs to be answered for clarification on = the C-SID draft solution. As the WG has consensus on a single solution we need to have clarification = from the authors which of the 3 compression solutions was included in the a= nalysis. The three solutions are very different and all would yield different analys= is results. I understand the authors have called the each solution a endpoint flavor wh= ich I see from the IANA codepoint allocations, however each flavor is a dif= ferent solution. https://www.iana.org/assignments/segment-routing/segment-routing.xhtml So the WG as stated would like a single solution so now we need feedback fr= om the authors which of the three solutions or endpoint flavors was part of= the DT analysis draft that the authors would like to put forward as the si= ngle compression solution. C-SID is a combination of the two drafts below: Combination of the two drafts below: G-SID - Generalized SID "REPLACE-C-SID" https://datatracker.ietf.org/doc/html/draft-cl-spring-generalized-srv6-for-= cmpr-03 SRv6 uSID micro-segment " NEXT-C-SID" https://datatracker.ietf.org/doc/html/draft-filsfils-spring-net-pgm-extensi= on-srv6-usid-10 Kind Regards Gyan -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email] Gyan Mishra Network Solutions Architect Email gyan.s.mishra@verizon.com M 301 502-1347 -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email] 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 -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email] Gyan Mishra Network Solutions Architect Email gyan.s.mishra@verizon.com M 301 502-1347 --_000_BL0PR05MB531651A259CAB89166E29675AEAE9BL0PR05MB5316namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

And more specifical= ly, all of the tables in Section A.2 will be modified, replacing the C-SID = column with one column for NEXT-C-SID, one column for REPLACE-C-SID, and on= e column for NEXT-AND-REPLACE-C-SID

 

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;         Ron=

 

 

 

Juniper Business Use Only

From: spring <spring-bounces@ietf.org> = On Behalf Of Gyan Mishra
Sent: Saturday, October 2, 2021 7:51 AM
To: Darren Dukes (ddukes) <ddukes=3D40cisco.com@dmarc.ietf.org>= ;
Cc: srcomp@ietf.org; SPRING WG <spring@ietf.org>
Subject: Re: [spring] [srcomp] compression analysis draft question o= n proposals analyzed

 

<= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

 

 

Thanks Darren!

 

On Mon, Sep 27, 2021 at 1:23 PM Darren Dukes (ddukes= ) <ddukes=3D40cisco.com@dm= arc.ietf.org> wrote:

Was: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-= 02#section-4.1.1

 

I’m sending this note to redirect this question to the srcom= p DT for an editorial fix, when the team meets next.

 

For the DT:

Each proposal, introduced in section 1, discusses how it supports = 16-bit and 32-bit SIDs. However, Gyan’s question indicates this could= be more clearly stated in the analysis draft to help readers less familiar with a proposal.  As such, section 1 ca= n be improved accordingly.

 

Darren

 

On 2021-09-24, 1:32 PM, "spring" <spring-bounces@ietf.o= rg> wrote:

 

Gyan,

 

You raise a very good point. In the analys= is document, Tables 1 through 6 and Tables 12 through 15 each contain only = one column for the CSID. They do not indicate whether the number in that co= lumn were calculated using the NEXT-C-SID, REPLACE-C-SID, or NEXT-AND-REPLACE-C-SID. (That is, the do not indicate wh= ether they were calculated using uSID, G-SID, or a combination of both).

 

Each of these tables should be modified, s= o that the CSID column is replaced by three columns (NEXT-C-SID, REPLACE-C-= SID, and NEXT-AND-REPLACE-C-SID).

 

If the numbers in these columns are differ= ent from one another, this may inform our discussion about whether NEXT-C-S= ID, REPLACE-C-SID, and NEXT-AND-REPLACE-C-SID are different behaviors or di= fferent flavors of a behavior.

 

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

 

 

 

Juniper Business Use Only

From: spring <spring-bounces@ietf.org> On Behalf Of Gyan Mishra
Sent: Friday, September 24, 2021 9:56 AM
To: SPRING WG <spring@ietf.org>; draft-filsfilscheng-spring-srv6-srh-compression@ietf.org; spring-chairs@ietf.org
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compressio= n-02#section-4.1.1

 

[External Email. Be cautious of content]

 

Dear Spring Authors 

 

Please respond to this question the WG has related to which of the three SR= v6 forwarding mechanisms called  flavors was inclusive of the compress= ion analysis draft.

 

The Analysis draft is ambiguous as to which SRv6 forwarding plane flavor wa= s part of the analysis.

 

This is a critical question that has come up by the WG and Chairs, and answ= ering this question will help pave the way to an adoption call for C-SID. &= nbsp;

 

Kind Regards 

 

Gyan

 

On Sun, Sep 19, 2021 at 3:33 PM Gyan Mishra <hayabusagsm@gmail.com> wrote:

Dear Authors

 

After having a few discussions on threads related to the SRv6 compression a= nalysis draft results, as well as WG coming to consensus on a single SRv6 c= ompression solution, a few critical questions have come up related to C-SID= draft that requires clarification by the authors.

 

The C-SID draft has 3 compression solutions below and is a combination of t= he two drafts below which introduces 2 of the 3 compression solutions with = the  C-SID draft introduction of yet a 3rd compression solution.

 

Which of the 3 C-SID draft compression solutions was included as part of th= e DT analysis draft results and conclusion?=

 

This is a critical question that needs to be answered for clarification on = the C-SID draft solution.

 

As the WG has consensus on a single solution we need to have clarification = from the authors which of the 3 compression solutions was included in the a= nalysis.  

 

The three solutions are very different and all would yield different analys= is results.

 

I understand the authors have called the each solution a endpoint flavor wh= ich I see from the IANA codepoint allocations, however each flavor is a dif= ferent solution.  

 

 

So the WG as stated would like a single solution so now we need feedback fr= om the authors which of the three solutions or endpoint flavors was part of= the DT analysis draft that the authors would like to put forward as the si= ngle compression solution.

 

C-SID is a combination of the two drafts below:

 

Combination of the two drafts below:<= o:p>

 

G-SID - Generalized SID “REPLACE-C-SID”

 

SRv6 uSID micro-segment “ NEXT-C-SID”

 

Kind Regards <= /p>

 

 

Gyan

--

Gya= n Mishra

Networ= k Solutions Architect 

Email gyan.s.mishra@verizon.com

M 301 = 502-1347

 

--

Gya= n Mishra

Networ= k Solutions Architect 

Email gyan.s.mishra@verizon.com

M 301 = 502-1347

 

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

--

Gyan Mishra=

Network Solutions Architect&nb= sp;

Email gyan.s.mishr= a@verizon.com

M 301 = 502-1347

 

--_000_BL0PR05MB531651A259CAB89166E29675AEAE9BL0PR05MB5316namp_-- From nobody Mon Oct 4 10:32:13 2021 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 9A5913A0970; Mon, 4 Oct 2021 10:32:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 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, 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=ZU23dXyV; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=WJredAO7 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 VI6vlca0zvcO; Mon, 4 Oct 2021 10:32:05 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BF943A0963; Mon, 4 Oct 2021 10:32:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17554; q=dns/txt; s=iport; t=1633368725; x=1634578325; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QzFVd/HGRNQiBMgoUSpBx06WQuQtIGB5TGSbNlcPYHM=; b=ZU23dXyVlbPZnzJ7ZbOqDhcyPRqWhQwEOLt6xoWbxmuNwNItOjM+fPFT K36R47gyYDSBhaxAsfIb7CiJvpICJ6R1UszvNfvaXsBe79YwEtXf+A3PU bl8DXjlfeJ9KrGe9p3nMkpPYcWfloBp3F8cD+N/KBjZ+Jn29TYVWBuukw E=; IronPort-PHdr: =?us-ascii?q?A9a23=3AvD6qKh3MZi63s8svsmDPTVBlVkEcU/3cMBMJ9?= =?us-ascii?q?4AqlL9PNK+k+seqME/e4KBri1nEFcXe5ulfguXb+6bnRSQb4JmHvXxDFf4EV?= =?us-ascii?q?xIMhcgM2QB1BsmDBB71MeL3dSElEcUEX1hgrDm3NEFPE5P4YFvf6nS58T8VH?= =?us-ascii?q?ED5Mgx4buT4E4LflYK5zee3rpbSeA5PwjG6ZOAaEQ=3D=3D?= IronPort-Data: =?us-ascii?q?A9a23=3AX5fKE6nEWaoV8zyZcs+MYXfo5gxUJERdPkR7X?= =?us-ascii?q?Q2eYbSJt1+Wr1GztxIdXjyEM6mDY2Okc4t0a4+38UMCvcXUnddjTwVvqS9hQ?= =?us-ascii?q?1tH+JHPbTi7wugcHM8zwvUuxyuL1u1GAjX7BJ1yHiK0SiuFaOC79CAkjf3QH?= =?us-ascii?q?NIQNcadUsxPbV48IMseoUoLd94R2uaEsPDha++/kYqaT/73YDdJ7wVJ3lc8s?= =?us-ascii?q?Mpvnv/AUMPa41v0tnRmDRxCUcS3e3M9VPrzLonpR5f0rxU9IwK0ewrD5OnRE?= =?us-ascii?q?mLx5RwhDJaulaz2NxNMSb/JNg/IgX1TM0SgqkEd/WppjeBqb7xFNBg/Zzahx?= =?us-ascii?q?7idzP1VvpW1QB0oOoXHmf8WVF9TFCQW0ahuqeaYeyHu75LIp6HBWz62qxl0N?= =?us-ascii?q?2ktJZcZ/OkyCmFH9OYDADEAch7FgPi5qJqgUvNtgMsLLcT3MsUYoH4I5TPQC?= =?us-ascii?q?Ps9B5aFTLjL7t9RxjsYiN1SAOzTeMcYLzFoaXz9j7dnUrsMIIg1kOHtjX7lf?= =?us-ascii?q?ngG7lmUvqEwpWPUyWRMPHHWGIK9UrS3qQ99xy50fl77wlk=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3ADw+LFK9YUD+Dhdcyv4Juk+F6db1zdoMgy1?= =?us-ascii?q?knxilNoENuE/BwxvrBoB1E73DJYW4qKQ4dcdDpAtjmfZquz+8K3WBxB8biYO?= =?us-ascii?q?CCgguVxe5ZnPDfKlHbakjDH6tmpNtdmstFeZ3N5DpB/LzHCWCDer5KqrTqgc?= =?us-ascii?q?PY59s2jU0dMD2CAJsQiTuRfzzranGeMzM2fKbReqDsgvZvln6FQzA6f867Dn?= =?us-ascii?q?4KU6zovNvQjq/rZhYAGloO9BSOpSnA0s+4LzGomjMlFx9fy7Yr9mbI1ybj4L?= =?us-ascii?q?+4jv29whjAk0fO8pVtnsf7wNcrPr3PtiFVEESotu+bXvUnZ1SwhkFynAhp0i?= =?us-ascii?q?dyrDD4mWZlAy200QKIQoj6m2q35+Cq6kde15ar8y7pvZKkm72ieNr/YPAx2b?= =?us-ascii?q?6wtXDimhcdVZhHodF29nPcuJxNARzamiPho9DOShFxj0Kx5WEviOgJkhVkIM?= =?us-ascii?q?YjgZJq3MciFXluYd099ePBmfcaOfgrCNuZ6OddcFucYXyctm5zwMa0VnB2Gh?= =?us-ascii?q?udWEANtsGczjATxRlCvgQl7d1amm1F+IM2SpFC6eiBOqN0lKtWRstTaa5mHu?= =?us-ascii?q?8OTca+F2SISxPRN2CZJ0jhCcg8Sj7wgo+y5K9w6PCheZQOwpd3kJPdUElAvW?= =?us-ascii?q?p3YE7qAd3m5uwCzvkMehT1Yd3J8LAR23FUgMyIeFPbC1z0dLl1qbrTnxw2OL?= =?us-ascii?q?yuZ8qO?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D0AQBYOVth/51dJa1aHQEBAQEJARI?= =?us-ascii?q?BBQUBQIFIBQELAYEgMCMuB3daNzGIDwOFOYgIA5psgUKBEQNUCwEBAQ0BATc?= =?us-ascii?q?KBAEBhH0CgkICJTcGDgECBAEBARIBAQUBAQECAQYEgREThTsIJQ2GQgEBAQE?= =?us-ascii?q?DEgsQEwEBLAsBDwIBCBEEAQEkCzIdCAEBBAENBQgTB4JQgX5XAy8BDqViAYE?= =?us-ascii?q?6AoofeIEzgQGCCAEBBgQEgUpBgn8YgjUDBoE6AYJ/hBOGciccgUlEgRVDgmc?= =?us-ascii?q?+gmMCA4EjBQESASMrgyKCDCKKAgEvQmQBAxs4IAJZCgyBAioRKZF9jAaNS5I?= =?us-ascii?q?qCoMwikSUPRSDZ4tqlzyHE48SjEmYcgIEAgQFAg4BAQaBdyUrPnBwFTuCaVE?= =?us-ascii?q?ZD4M+imIMFhUZgyKFFIVKdDgCBgsBAQMJlXEBAQ?= X-IronPort-AV: E=Sophos;i="5.85,346,1624320000"; d="scan'208,217";a="917219663" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Oct 2021 17:32:03 +0000 Received: from mail.cisco.com (xbe-rcd-007.cisco.com [173.37.102.22]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 194HW2nh030473 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 4 Oct 2021 17:32:03 GMT Received: from xfe-aln-001.cisco.com (173.37.135.121) by xbe-rcd-007.cisco.com (173.37.102.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Mon, 4 Oct 2021 12:32:02 -0500 Received: from xfe-aln-003.cisco.com (173.37.135.123) 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.792.15; Mon, 4 Oct 2021 12:32:02 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Mon, 4 Oct 2021 12:32:02 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iNspbYPGWc+Ioyu0Gc7tkIkPz8TgkK6oxrry6yhG1uteAwLRIMK7qSWLX9JS7DoGx+lWxFRPib/RncZ6Ya8x8BbcL7Pj7lnXcCB3UihZ68lh4o4wan+a1eh16wJNkPusg60veSk7roPNvUIu8PbHZkCoCsjJPdfRKL6AC6jv7w9C+kvNi73cNClEapi1AK9lJUCt9Ex9MW6fyMmjLQDiZSrToD+Ee5ssMdOHuqKRtIW3r6qMQYa9IbSjrgrYmdDXaSroFBstuGvFqVnI+GXaM/RQxiKXKIL43KKRnD6KzRO8qw8p0UgXSfEU1dQvXnmww3rACVZIB901VLAHh71H8Q== 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=AH2W6IkaQ5xbZlx1hU7zHgpShYJmnQzth1SJFQ1spJs=; b=iDh9iugrgPiZtXGya5epCFyMMHlGapc1oDnNZhJJQfeY8WisV2oUJSyYSYnkv4wGX/V40iUWH4mElbDxhCY4xWIAAZQp6fBjV33aAc1UaxzXJc0TbcAPEVlt7nVpcQyB8p0sSXQ1aMcfvXOa++YcowTROkteZgSJCh5QVSx87r+q7L8ynTkT503s5v6Ce4PUIs2O3a0PuSwcEZWXcv7OTPxC0d8/dXIV+p0bL+EFsR5uvoGtLg6G3uCW8QLybz+Xlj5FotlOuvPmGdP/bLZ2y8C/kNf2SrfqR8A5T6FQzssNvZ2rlJJ6goLNtp4xgXrq6++kGFKsGUtdElI7D23eeQ== 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=AH2W6IkaQ5xbZlx1hU7zHgpShYJmnQzth1SJFQ1spJs=; b=WJredAO7yufOmA1T3eXOg86HxjjpysXXbcUd4jAFdVQAKS8z6fjZGNcbfMD4DNx6/Q7TRPjkJ9+2X+ZUF0ALdOBZxDdRQRI4Nt0VDCbi+h2zW1km1imdBQF4yv6naLn7e6mxNhcnz9dJZAiSz4RouVX9xZG9RZK2D5gxTOIuJj4= Received: from DM8PR11MB5719.namprd11.prod.outlook.com (2603:10b6:8:10::6) by DM5PR11MB0059.namprd11.prod.outlook.com (2603:10b6:4:62::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4544.18; Mon, 4 Oct 2021 17:32:01 +0000 Received: from DM8PR11MB5719.namprd11.prod.outlook.com ([fe80::e961:f09d:c3df:eec1]) by DM8PR11MB5719.namprd11.prod.outlook.com ([fe80::e961:f09d:c3df:eec1%6]) with mapi id 15.20.4566.022; Mon, 4 Oct 2021 17:32:01 +0000 From: "Pablo Camarillo (pcamaril)" To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQCeJTAA Date: Mon, 4 Oct 2021 17:32:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3340d87b-d274-4f1c-9e26-08d9875ce007 x-ms-traffictypediagnostic: DM5PR11MB0059: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Xv9v47Co09WosptwcTrMOAp0/bigw8BL9UzXKxgJkIV2vJxmGN3fuxVsJHqsL13l61j4OffalUYrPW3zwz/eO8i9pWE725E4jdovoPXsMl1j/UJ1kMNN5eKtxJpPwG8WIb78CCY0QbXg00WNkofHouEXoKduQkm4gVHy8DXlNWZYQWncZ6D+D4yVjG8bpEN40jsiBX4OFvUZIRvvL/GZCY72C8KbJgZdWzilkSsbazNXQacAm15IRoWFUvefN15YXCsS51JqZsJxbSd6wtCXQH1kkl6W4ecMfAyouls7AeFDXXZ5k1T6+rVJD4G476BieALHsAtA4QSxDGjsKmW5K3LE46sqp47bRihJcOyrZrBreNBP1s6GDn8S+STKoCQSM4KyJTtny1srAn3nIXJzRUxvfrX9ShdscjjwQV8rPnULbl0GO8ZudX08SD+fpSVKk0KnZse/V/i5s3bY/SKnC3VQEyYO+6ATuMxdbS4KXUUiQ7z7biM4d5QSHDJDzT0QNQ4nBioHEO225N6+IjG+i6poHlqdxjniXKRvwAt/wPFh03Mmy4nfP+Rc/7cP/1IOnTFmA3UokYvmjlpqB6F5P934Yj4m/uZt6yWttS2kYYgUh+fcbIy7dysMCpPKxPhmDpuCvWMbeL4kgkWRMwWWiloKGr+Z9lP/IVF2DkKUNk+nfy3xXoK0yuoRmK8x7E8VBeLoR4e2txuxtEpRtKZUlPFE39e4GTQp8dRyRAojmRfZdUOilHHwGpiHHrzpfG0maw8lK9lHpVGLS3jp0W5dz0SlDCDiuP4Vxde2Lmclthc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM8PR11MB5719.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(966005)(53546011)(6506007)(316002)(38100700002)(122000001)(5660300002)(166002)(38070700005)(110136005)(4326008)(86362001)(66946007)(76116006)(66476007)(71200400001)(7696005)(83380400001)(508600001)(8676002)(2906002)(66446008)(64756008)(186003)(66556008)(8936002)(9686003)(26005)(52536014)(33656002)(55016002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?DgoKAawxBVYV2TuGg8soL8qKApnN8VnkmVvrNRVQ1OtvqqAtvyLpRWhhpVXf?= =?us-ascii?Q?dcD8slKcj6q7Nnqs6HxxEvvRvT+7YAMNjb+DUPqVhcI6ptcn7eylxPpG4XiI?= =?us-ascii?Q?YJITf/uCNtro6yIHrS5YkvNpwILD/uTKHYAJryWOVPthshxTZlyslYrtefB0?= =?us-ascii?Q?zAwo9lwVcByYe0Ta/0pkG9zljTOJeVfbkHIlUpPuwJy/dJ9ZjpFntGk59lHN?= =?us-ascii?Q?Qi/TGkHz1XztRavZ9JNSm/I6CvusA4JejFzeozDQsWQUwCijxq/zJ2ggCa38?= =?us-ascii?Q?1pdTL/vSa0/sEC8Ei1gbkxZTNMUqRfnvO11qP11+u/j3oeGrDv5slx9zhHoJ?= =?us-ascii?Q?3nofP6neVpZu/OBOBlHxoJHtPRogklLwWwQR9lDvHRnEf+vYcMCGvHRNyZtD?= =?us-ascii?Q?ki48GeS1JZE42zBCq47FrCYYsXzo/QqDYEaWYEZMFtoK/WGDpz+TwtdGoAdA?= =?us-ascii?Q?v0YMAT9AbyTB9xMvoyBlFY2RqvAu5nqmyudLb2SR2a2PBQVUMLJY9ZlbGmtd?= =?us-ascii?Q?gi4+ScbyVgQ8TzQQqFaLQZjjG9WrCoLwH3pWL4YlJjg1c1Y5zOQYgPqKUcso?= =?us-ascii?Q?FdJ4fdJlkZDSGSyYqV1R4/SEksV5++OvpwR9ijxgqyTuoTxF+3ca1H3a5Ayi?= =?us-ascii?Q?5WMRIAnxE1VWi1PPRZ7ygv3qW62KSjq12YzMIs4E83tXwG+zsgFVqscd9A2K?= =?us-ascii?Q?USDy5jpku8W7Y4j88hHoYE6ZBVIs9B9GhrAhdrg46rMZr9eTzG4J7A9FNJNS?= =?us-ascii?Q?0e9+OPUO7ZsduqURJTlnpWBNNcVdtPJZgkHYITJoXpaVtk62zzvQOOsKChPv?= =?us-ascii?Q?2kUmkKa4QkXy0emz1f5r61T6Z9VEoPo2kVeyQyn3z3ycDCvZxTIbpPVVR1qa?= =?us-ascii?Q?10QgiB3UG8h38itzctiR9cyl4oRSl+LHLhyeD7f84nc0zIvCVCjIl8lLFdio?= =?us-ascii?Q?XSRVEU25NK98DACffsNcTA8oAtrhRrrEWhn/d7Tqd/WWYhpjToS3o2pYr+qo?= =?us-ascii?Q?RnHEDTFA9iy7Whvz7tXYOItL7AiqXjkkDEDgfImhGhq26n/mlNkh/upv+5nz?= =?us-ascii?Q?Q6PZy9hcJtZsFgu/za9ZsXEVpzOJ6IzF4ytI9lux8csaZovedbWvBVJP0PqJ?= =?us-ascii?Q?qkGuyyxMnAD96PorW9ziBWQPQpX6056DpBAyb6Vx7XSMdXsN6pHn0ptJI71r?= =?us-ascii?Q?0oRER4TzjiIV0WILQ+9GFJKltFqLPH8q0KLsNMfnZnbGnWuH6zDPrWIVFp/J?= =?us-ascii?Q?N3QnjR3vaXwio7Gq9tsKxyG8ancrbtPEJ3FQvwp0Ui90pbUnsTwOOd5efnAQ?= =?us-ascii?Q?alBHHH30VcsH5ugD9b0Grxu/?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM8PR11MB5719868719840728F04A360EC9AE9DM8PR11MB5719namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM8PR11MB5719.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3340d87b-d274-4f1c-9e26-08d9875ce007 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2021 17:32:01.3628 (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: zYhUl+QAGObdLANRU2dQYcGr4ysZgwYM+Th3VgaidGB38PyN6JbdLXBZiSqx13JwAuHXhBfEWymBf59CXKxsdA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB0059 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.22, xbe-rcd-007.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 04 Oct 2021 17:32:11 -0000 --_000_DM8PR11MB5719868719840728F04A360EC9AE9DM8PR11MB5719namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We all have witnessed the thorough work of the Design Team throughout the p= ast year. They worked hard, presented their progress, asked multiple times = for WG feedback, and incorporated it into their documents. As per their ana= lysis CSID is the best compression proposal. Additionally, for the past few years we have defined a single dataplane sol= ution, called SRv6. It has been deployed by many operators, and a reasonabl= e number of routing platforms support it (2021 EANTC showcased Cisco, Huawe= i, Juniper, and Nokia devices). RFC8986 already defines 36 different behavi= ors. This document, CSID, is a single SRv6-based solution that only defines addi= tional behaviors with the next and replace flavors. Therefore, I support the adoption of CSID. Regards, Pablo. From: spring On Behalf Of James Guichard Sent: viernes, 1 de octubre de 2021 16:05 To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_DM8PR11MB5719868719840728F04A360EC9AE9DM8PR11MB5719namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi, 

  We all have witnessed th= e thorough work of the Design Team throughout the past year. They worked ha= rd, presented their progress, asked multiple times for WG feedback, and inc= orporated it into their documents. As per their analysis CSID is the best compression proposal.  

  Additionally, for the pa= st few years we have defined a single dataplane solution, called = SRv6. It has been deployed by many operators, and a reasonable number of ro= uting platforms support it (2021 EANTC showcased Cisco, Huawei, Juniper, and Nokia devices). RFC8986 already defines 36 dif= ferent behaviors. 

This document, CSID, is a singl= e SRv6-based solution that only defines additional behaviors with= the next and replace flavors. 

  Therefore, I support the= adoption of CSID.&n= bsp;

 

Regards,

Pablo.

 

From: spring <spring-bounces@ietf.org> On Behalf Of James Guichard
Sent: viernes, 1 de octubre de 2021 16:05
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

 

Dear WG:

 

The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a sol= ution for SRv6 compression.

 

The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document = that has multiple SRv6 Endpoint behaviors.
  2. The document is a “= living” document; it may change as it goes through review and analysi= s by the SPRING working group.
  3. All open discussion point= s raised on our mailing list MUST be addressed BEFORE said document is allo= wed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maint= ained by the document editor in conjunction with the chairs.
  4. If this document is adopt= ed by the working group, the chairs specify as part of the adoption call th= at the following text describing an open issue be added to the document in the above-described open issues section:
    • "Given that the working group has said that it wants to standar= dize one data plane solution, and given that the document contains multiple= SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution obj= ective.".

 

Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open d= iscussion points you would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

--_000_DM8PR11MB5719868719840728F04A360EC9AE9DM8PR11MB5719namp_-- From nobody Mon Oct 4 13:05:09 2021 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 6903B3A0B8D; Mon, 4 Oct 2021 13:05:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 H0farit31Oa1; Mon, 4 Oct 2021 13:05:01 -0700 (PDT) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B704C3A0BA8; Mon, 4 Oct 2021 13:05:00 -0700 (PDT) Received: by mail-pj1-x1036.google.com with SMTP id v19so12379526pjh.2; Mon, 04 Oct 2021 13:05:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=etz07QHiKeOQqTLxluWTQ+B9zCy2f2BEcDyVj4qcWt4=; b=iI2f8C5HXcFAvfmtb5vdZTBskgiCcdrbPCdX1maMqAdLKYWDMTFkndNmdnDr4bc8Cx 0ywAeaeasJRHq8X2N0iohMSH0e6xmkCGrWG92/uVmS1lOrUyIVIaUEFP2AYQ6ldw2QWM 2YJb10lqD6NZ+PjsPez8JSAeOkMBDVLvBu3qXFQWbB3thRzUKjuMT+Hfjf90/XrTDoUQ wOXej8Dg48Wtdpye0OQBum4MC+G5hXJ+MmAMKLibjXPr4BIAYmf9BVp5QawCj81sppo8 7TMtVtt6pfA/tu3NkPwuYl5Y+dTQxnIfTGEdqGO0FEXA5Sdqm7LNqd2uH9dTe2IsX/JQ UEbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=etz07QHiKeOQqTLxluWTQ+B9zCy2f2BEcDyVj4qcWt4=; b=MMFQ0MvGjXo+VBEKdt/tlp+nsj1Nbgvc8AxKfx5aKJHEgmtvCKxoklKn82gOAaY6As 8P4Fdi67qRgFfztigd/9nLStTliRztHRkT2uL2O6qq7y4Z9+fyf4jg1pd2uyUmvMNecS vqEe1plx61jCUQKScMqy+19aW79LuKy1spALu9MCrLkmnMmOfHn+pp+wILx/x0NQDAsb VGeIEWyEyDwe6+BQVsXxG4nOQbDqUX3atllJuq8nSwqSdsPz3jJF7frFrb5lTVlkpJGj e8vsM1n/86oc5dhcOcFaPySUm10+/ktlnzC5AsX8A45W9nFsUiZLy8MQ4y+hEwCH6yla IPZA== X-Gm-Message-State: AOAM530oN1JvcJ/dqAHZNHN25ZJaaHOwjI4wTaxgJFbEDYWyJ0xUY0ro 5Ql/POglrzfE8huN5zK7GJ1A/xkESNLgkw== X-Google-Smtp-Source: ABdhPJxhrt0d0CRFGEU644UH4n5t7Ql5zzDtYevxU9BmgM1uTHoeejGqTt7e+vOwhhNKKO724Zdg2g== X-Received: by 2002:a17:90a:14c4:: with SMTP id k62mr32097344pja.154.1633377899702; Mon, 04 Oct 2021 13:04:59 -0700 (PDT) Received: from ?IPv6:2406:e003:11aa:d701:80b2:5c79:2266:e431? ([2406:e003:11aa:d701:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id e1sm15806740pgi.43.2021.10.04.13.04.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Oct 2021 13:04:59 -0700 (PDT) To: Tony Przygienda Cc: Ron Bonica , "6man@ietf.org" <6man@ietf.org>, SPRING WG References: <6d4eff6d-6fdc-992e-3a01-13bce8b05cd0@gmail.com> From: Brian E Carpenter Message-ID: Date: Tue, 5 Oct 2021 09:04:54 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 04 Oct 2021 20:05:07 -0000 Tony, On 05-Oct-21 02:32, Tony Przygienda wrote: > Taking this new "philosophy of limited domain" to its bitter conclusion= >=20 > A is Internet Standard > B is also Internet Standard for "Limited Domain" that violates A > C is also Internet Standard for "Limited Domain" that violates A > D is also Internet Standard for "Limited Domain" that violetes C >=20 > so by transitive chain D violates C and hence A but not B. Hence D and = B can be deployed together (maybe) but not any other combination. >=20 > So what purposes will IETF serve. To define 4 different "standards" tha= t have "limited domain violation dependencies" amongst each other but bas= ed on algebra closure can sometimes be deployed together. And we will tra= ck this and call that "standards" ? Really ? There's an attempted analysis of this issue at https://www.rfc-editor.org= /rfc/rfc8799.html#name-the-scope-of-protocols-in-l (which is not, of cour= se, an IETF document). Brian >=20 > --- tony >=20 >=20 >=20 >=20 >=20 > On Sun, Oct 3, 2021 at 6:13 AM Brian E Carpenter > wrote: >=20 > Ron, >=20 > The first sentence cites RFC8402 which unambiguously describes SR a= s a > limited domain protcol (limited to an "SR domain", that is.) >=20 > So within such a domain, this describes using 128 bit quantities ca= lled > Segment Identifiers that in some cases, but apparently not in the f= ormats > defined here, has the same structure as an IP address. >=20 > Does that harm the Internet, even if it leaks? It might disappoint = the > sender, as any sender of a bogus packet is disappointed, but apart = from that, > who is damaged? >=20 > Regards > =C2=A0 =C2=A0Brian Carpenter >=20 > On 02-Oct-21 09:34, Ron Bonica wrote: > > Folks, > > > > =C2=A0 > > > > Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces thr= ee new > SID types that can occupy the Destination Address field of an IPv6 = header. See Sections 4.1, 4.2, and 4.3 of the draft for details. > > > > =C2=A0 > > > > The SPRING WG has issued a call for adoption for this draft. > > > > =C2=A0 > > > > It is not clear that these SID types can be harmonized with the I= Pv6 addressing architecture. > > > > =C2=A0 > > > > Does anyone have an opinion? > > > > =C2=A0 > > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Ron > > > > =C2=A0 > > > > > > Juniper Business Use Only > > > > > > -----------------------------------------------------------------= --- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ip= v6 > > -----------------------------------------------------------------= --- > > >=20 > -------------------------------------------------------------------= - > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6=20 > -------------------------------------------------------------------= - >=20 From nobody Mon Oct 4 14:00:20 2021 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 9F7E23A0C2A; Mon, 4 Oct 2021 14:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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, 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=KrhE71uJ; dkim=pass (1024-bit key) header.d=juniper.net header.b=j8mYecrP 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 bxttrnK4nyHo; Mon, 4 Oct 2021 14:00:12 -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 1DFC93A0C19; Mon, 4 Oct 2021 14:00:12 -0700 (PDT) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 194HJLU5029247; Mon, 4 Oct 2021 14:00:09 -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-transfer-encoding : mime-version; s=PPS1017; bh=rm5Ei2CsAtpR4ZJV3EVYhsn6TuKJUJz2Tyym/L7fqvQ=; b=KrhE71uJ3DMUeGC/kh6vrLR9vRGuEVK7lRSCWdgvSWX3DyRtnkijEJi2MtbDw7zVhlce jKICWBzIk6EEcc0zpXWjGDXdDVU/SGWNf9opOPwL8ESU1Oh/t45gvjwN746U4yqB620q BwaKYdQogiyN9cInzuFUQh96KWwuekgoPGljNsddxGc5Wp6HmNhUOKFH2WarKsZ7firR MOygY1c5d5ZLPTiUDo6W3fft7UW504uNoePTaubYk0lx078LxfNm6vqzoaYH1nMCX3vz CSwfoa9UxMsIaT1cEMDpZsgjDY2lnGboKeofcKVQO/4kctKG+IznX17y6E9Jo7JBIFIi 3w== Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2170.outbound.protection.outlook.com [104.47.57.170]) by mx0a-00273201.pphosted.com with ESMTP id 3bg5wkrb7e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 04 Oct 2021 14:00:09 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NHh2RgEKlPO1fV1WzCUPL5z4lJ2XwmGFcFbwg2Pm4JbjlutoZb2YtQ6xsynu0Fn3LaVKELPDzvh1Uq/KEZo9K1r+dPZJPMqDOle49OQuUyifJHh2MFqobECCIU3hiCvY+m+b4s3qbt/Y/K3zg9BiSsL90nuNI99iD68CQ1J5RzoIJosGYx1AHfakaqVAqz3VC9pg63lQmSaeX9akDE724S0c/mV68XIvyzp/KSJw0mIRL90nBnR3vwx9FHw+prutbH7aKwCW+XEI8N/5pJdV9RIva3EWHMdgCMR2BNi+cCNWFPjr8fgkO9CEp5xiNjg6pSjNB+0FLS4iKPW3UTd6+w== 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=rm5Ei2CsAtpR4ZJV3EVYhsn6TuKJUJz2Tyym/L7fqvQ=; b=BkhpryHt12cYUbPLNBXzAOwZ1Bo5vt4VXJpHSfWBDrhvfv+PilkdnPtJaPxyB9q7PzXn+EUY4Vm18gzy1K57FQlWrPrUBeiZkl+BExtWajvQMfZXE1yC1tVCbkTJwB6gommBdtZiYsT9YAVyh90nViP1kntcj216Y0mkP94cqzpm1QnWuXU7NOkU4f3ZzcOUE6q3tiTSAcnJShIue+U0c3LVHGfDH46VYVgSHpcmwdL3CQysGET7ihA9Lp0ZVZ3IwC9qHl+Q09TVFM8xekpbeh7qsFP66g3m4vDQ+PcXQSoNhuDY+TYTIjepZArto6wh4fev5yNyHFnjDGHD45inpQ== 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=rm5Ei2CsAtpR4ZJV3EVYhsn6TuKJUJz2Tyym/L7fqvQ=; b=j8mYecrPJFRuMVyp5wzHf8OLqlzvRuu+605aB89ogpXlYWBhyMfLMBp7lG23BfdsjGZLijNoEchHpLbtI8UTsKdR8LFRje8xcjS6OHX8HzSJ6uyyTaDTjS5V+u8+a0NL9P2r8ZzyMLn+doCgp4D5RhLsfjV0Wm/UyWUdKag+T1w= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by BLAPR05MB7329.namprd05.prod.outlook.com (2603:10b6:208:29f::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.9; Mon, 4 Oct 2021 21:00:06 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4587.016; Mon, 4 Oct 2021 21:00:06 +0000 From: Ron Bonica To: Brian E Carpenter , Tony Przygienda CC: "6man@ietf.org" <6man@ietf.org>, SPRING WG Thread-Topic: draft-filsfilscheng-spring-srv6-srh-compression-02 Thread-Index: Ade3AXyWK2NzAamgSlCvJ497z/5RLwBC3mUAAEXSsIAADbX4AAABv53g Date: Mon, 4 Oct 2021 21:00:06 +0000 Message-ID: References: <6d4eff6d-6fdc-992e-3a01-13bce8b05cd0@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-04T21:00:05Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=22550c08-c1ec-44e3-a243-950a4d3f9709; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5ea7fd58-7488-48af-b305-08d98779f1ca x-ms-traffictypediagnostic: BLAPR05MB7329: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9zCesVsaTWJ1xSITahdcIvaOqHMaLTz4tHiFbJBKvjrsleKmC1CbU2tBfnQ02PVjrWOb7mFjsFDLbbZ44+3xMYI2e5PjSpDqNiwCOC0zTjOW9pfpkX1fR46tBfYucyOlvMdzg17DiOBz5fq5tZuSPh0FcHOFEMyijKMnMba9sVNUJQ64P5CdcDK6+7ElrzvPKsSYzS3F+MZC1trinFoMGrUfm0Wny7Dy0LERlnG8qzEvM5+ivws0uyOWx3/oocNMLSegwWTdOwbQAnTk51JGw6cxT55b1ssXrFcUxUEgHUzrf93kbLa1iG6pXHDlgMTjRUmOZcdnFvACt4RW4cPUZq+FlReX6PEkiAmtaKgOLkmlfpTEWwXTxg0W6yx3ij+PJTk4DnxPfrY9fHPBZnk1tel+0INQZgj9S+4IZZ8OvE6whSjlsnZtaEskkmsLvbKgYSA5WP0EtaAgjJSHU+mwBDiK1Lxn0aQ4JNdoGgs16nGEGG9vXUDkjtgYSz8gAeKlBkVxIhGuOimhnrFR/fVTN54QoSYyeLhSuMU4SthaN1acZM8P42+jpT43qPJaH1lpYB8d/j+HNqbd2lNENcm51yqGXCMEM7rULJNVrWbFOa9fYIKo/wxKDedSXTwZvH7YOKeuASCOW4W6V+Ks3yg3SpDJRkedmQr2Rpii6RUkiZGgoQ0QipBFewnrdwZ/pCdEgDvM/D7ud1uVJPf2jjSv2nf9DFds55vcZs/q0DRtzgc6Z6wS5Wi79QCs7gqH8Q8NcEoH0yxvw6RvkLYfvEnSWJ49/P5r2QDz6lnYj+J5mbU045NVia4IhFKNhkJ2ka/rSrIF4KnWS7aVL2VxkS6V4g== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(2906002)(66946007)(186003)(66476007)(54906003)(52536014)(53546011)(6506007)(38070700005)(7696005)(76116006)(9686003)(33656002)(8676002)(55016002)(316002)(66556008)(8936002)(66574015)(4326008)(66446008)(508600001)(38100700002)(966005)(86362001)(71200400001)(83380400001)(122000001)(26005)(110136005)(64756008)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?dzlDNlFoM3dzdDB6QUUrMXB0QkZwc3F6UC9MM0EvSUJYM2xEZkc5S1VOd1Qv?= =?utf-8?B?ejVsUGgzbHhRaGV3cXRwNUhhT2hmNmVjUU9kUkhGNEVMbmZUMWNUUkV4Z2R5?= =?utf-8?B?aU5kZXRFQkc0alYyc0JoZFlZSkkzMkZ5aExlTXhyOWlGK2xpbXM3SjhNU0dB?= =?utf-8?B?bnllVklhaHZWMW5zNDU2cEtwbUx4aEFiYkhUWXUwT05SM3hwbUNCV1E4M0Ur?= =?utf-8?B?R24wenV0ZDFQWW1qaExtUkhDSGhDbU5JTVFYRGNBNkl2MlFMZlRrTHl5QXhm?= =?utf-8?B?bFhTVk1qUXlrRkljNWJReVZTR290cHprS3l3MHM0dmRIOFNwNTBrZGN5SEMw?= =?utf-8?B?YXlweFV4a3Z3TmdKdC91K0JyTFJ2bUY4VXFYNTc0anRPZCtxYmNOUGpwYzUz?= =?utf-8?B?cTF5a3VML3pCVDVDRG0xeVJINU10TTI2em82UGEwOW1DK3ZwU0NEc2tYaXMy?= =?utf-8?B?dlVVejgvSjNjRnBsbVl2c2Rjb05BWGhqOWlKYzUxVjUwd1MxdTZmYkZoVHhP?= =?utf-8?B?Q1c5MEdhSmJBRUpKd3ZNWlRiNG9zUGRFT2ZXV1Y0OGliTzJMSkVJSXIyZ1F1?= =?utf-8?B?S0xvend4My9XeHdVcFprNUlZQmtTZTBaK2VQa3FqZXBwMHRBN0FNSkVEWWhn?= =?utf-8?B?UStzRW93Z1k0VkFLQ0xWZHVhdUUrM0ZvUWlHNy83YzF3RjlQNEJqODQ0VGh2?= =?utf-8?B?MHZ6SUlaRzEvWWVIaFNacjdtbk1HR0xtNnBvOHplOHdxU05FYkxyTWR5bzlr?= =?utf-8?B?WjJXbDQvNXN5VlROZXZKeTBIWlNTM1ZVYzUwN1BYWkxudlM4QnJyZkhkZkpQ?= =?utf-8?B?QUE2MmIxNFNQWE5iNzBmbFl2RXplZTBhbWFIenc5SkJSMXRZd2tMa3RhbE8x?= =?utf-8?B?aFZVQzJqRDEzdHNwMDkxRUZNbkc1ckl6OEthblhFMnVhQjVxRE53Z2tnOUU5?= =?utf-8?B?eUZOWjg0NUc3NHdUdHFpc2tmWW1KM0M3UmJycGpPWjVUN2VmM1JUcWlZeXor?= =?utf-8?B?TWFHSm5lUElNU2JOQlc0NHRGMDhGWi8zL3BhVTMxaDkwcURJaWpZcjFpcEY5?= =?utf-8?B?YnpGU1orcWVQS3hUUitkSEovdHNTQllXYmxzMkJWWEhkb3J2bEVRa0RCL3VR?= =?utf-8?B?SmNwc1hiZnJDSU9NNmdUd0FiN0JpYlNmSk5oWXRNeFUydUxkbHIrOG9MdWVE?= =?utf-8?B?VHpFNEV5cVUxQm1Nc2JxSjZBZkZBYmg4MmRuTTJGZmZZQ1BKTGsraVVPZ3cv?= =?utf-8?B?ekVRYjEyK3l5WFdISllpckE4aG5lWE52UkJkOC95ZlR5VElHWlBtS2dkeHZX?= =?utf-8?B?OGJOam5Cb2pPNEJrZ0VLbGNSUUg1aXRzLzdFeUJXU1VEVkM4WlR6dDBDSFJL?= =?utf-8?B?UkNFSFVCcm5XWDlZMVNTSHNVWWRKckg2Qk9nY2EvNGhlSjdXMFZSYjVVU1ZC?= =?utf-8?B?dVpHQzRjaFllcGs5RUMrTG02S0VDRlkvYnZJWVZkQUJ3dmZiOWREalJiaytQ?= =?utf-8?B?bGZkYVVIQU95M0g4UzFtV3NmdGc3Qk01K1JYTnRwS0hCZ3gwNHg5NFpaVTdB?= =?utf-8?B?RnpTVTVTU1BwQy9oNTZpcTduRDhabTZEU1p5QVhmYkdhVmZIWHYrajk0Y0c5?= =?utf-8?B?NExVNkdzNi9LM0haL3dLNHlTVTFGakJUQTBNRENocGh6dFhIR0lBM3o3TTJJ?= =?utf-8?B?aXlaMis3amJXMU1aY3E2QmUzeHp3Z1pNM045Z2FOVHd6Uk5OYnJQNnZMaWpD?= =?utf-8?Q?Xk0cgtjIZpkm7zO5Ic1DJhQLRgMwMdXMtoLbhrz?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5ea7fd58-7488-48af-b305-08d98779f1ca X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2021 21:00:06.5722 (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: Yc122vfyBnQaQpx1iElAJnpHhov3oZ3monzKd1sCUXpXNH/zSzLPmjyM5LHqtVTt5IFveqKqDxz9CCJYCuEj8A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR05MB7329 X-Proofpoint-GUID: SR6DYtajso63NI_WEY1aNzjBmRuWE-Nr X-Proofpoint-ORIG-GUID: SR6DYtajso63NI_WEY1aNzjBmRuWE-Nr X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-04_05,2021-10-04_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 mlxlogscore=999 adultscore=0 clxscore=1011 malwarescore=0 lowpriorityscore=0 priorityscore=1501 suspectscore=0 spamscore=0 phishscore=0 impostorscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110040140 Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 04 Oct 2021 21:00:18 -0000 QnJpYW4sDQoNCklzIHRoZXJlIGFueSBsaW1pdCB0byB0aGUgZGVncmVlIHRoYXQgb25lIEludGVy bmV0IFN0YW5kYXJkIGNhbiB2aW9sYXRlIGFub3RoZXIsIHNvIGxvbmcgYXMgdGhhdCB2aW9sYXRp b24gaXMgY29uc3RyYWluZWQgdG8gYSBsaW1pdGVkIGRvbWFpbj8NCg0KRm9yIGV4YW1wbGUsIGlm IEkgd2FudGVkIHRvIHJlZHVjZSB0aGUgc2l6ZSBvZiBJUHY2IGhlYWRlciBieSBzaHJpbmtpbmcg dGhlIHNvdXJjZSBhbmQgZGVzdGluYXRpb24gYWRkcmVzc2VzIHRvIDY0IGJpdHMgZWFjaCwgd291 bGQgdGhhdCBiZSBPSz8NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIFJvbg0KDQoNCg0KSnVuaXBlciBCdXNpbmVzcyBVc2Ug T25seQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQnJpYW4gRSBDYXJwZW50 ZXIgPGJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4gDQpTZW50OiBNb25kYXksIE9jdG9iZXIg NCwgMjAyMSA0OjA1IFBNDQpUbzogVG9ueSBQcnp5Z2llbmRhIDx0b255c2lldGZAZ21haWwuY29t Pg0KQ2M6IFJvbiBCb25pY2EgPHJib25pY2FAanVuaXBlci5uZXQ+OyA2bWFuQGlldGYub3JnOyBT UFJJTkcgV0cgPHNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBkcmFmdC1maWxzZmlsc2No ZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi0wMg0KDQpbRXh0ZXJuYWwgRW1haWwuIEJl IGNhdXRpb3VzIG9mIGNvbnRlbnRdDQoNCg0KVG9ueSwNCk9uIDA1LU9jdC0yMSAwMjozMiwgVG9u eSBQcnp5Z2llbmRhIHdyb3RlOg0KPiBUYWtpbmcgdGhpcyBuZXcgInBoaWxvc29waHkgb2YgbGlt aXRlZCBkb21haW4iIHRvIGl0cyBiaXR0ZXIgDQo+IGNvbmNsdXNpb24NCj4NCj4gQSBpcyBJbnRl cm5ldCBTdGFuZGFyZA0KPiBCIGlzIGFsc28gSW50ZXJuZXQgU3RhbmRhcmQgZm9yICJMaW1pdGVk IERvbWFpbiIgdGhhdCB2aW9sYXRlcyBBIEMgaXMgDQo+IGFsc28gSW50ZXJuZXQgU3RhbmRhcmQg Zm9yICJMaW1pdGVkIERvbWFpbiIgdGhhdCB2aW9sYXRlcyBBIEQgaXMgYWxzbyANCj4gSW50ZXJu ZXQgU3RhbmRhcmQgZm9yICJMaW1pdGVkIERvbWFpbiIgdGhhdCB2aW9sZXRlcyBDDQo+DQo+IHNv IGJ5IHRyYW5zaXRpdmUgY2hhaW4gRCB2aW9sYXRlcyBDIGFuZCBoZW5jZSBBIGJ1dCBub3QgQi4g SGVuY2UgRCBhbmQgQiBjYW4gYmUgZGVwbG95ZWQgdG9nZXRoZXIgKG1heWJlKSBidXQgbm90IGFu eSBvdGhlciBjb21iaW5hdGlvbi4NCj4NCj4gU28gd2hhdCBwdXJwb3NlcyB3aWxsIElFVEYgc2Vy dmUuIFRvIGRlZmluZSA0IGRpZmZlcmVudCAic3RhbmRhcmRzIiB0aGF0IGhhdmUgImxpbWl0ZWQg ZG9tYWluIHZpb2xhdGlvbiBkZXBlbmRlbmNpZXMiIGFtb25nc3QgZWFjaCBvdGhlciBidXQgYmFz ZWQgb24gYWxnZWJyYSBjbG9zdXJlIGNhbiBzb21ldGltZXMgYmUgZGVwbG95ZWQgdG9nZXRoZXIu IEFuZCB3ZSB3aWxsIHRyYWNrIHRoaXMgYW5kIGNhbGwgdGhhdCAic3RhbmRhcmRzIiA/IFJlYWxs eSA/DQoNClRoZXJlJ3MgYW4gYXR0ZW1wdGVkIGFuYWx5c2lzIG9mIHRoaXMgaXNzdWUgYXQgaHR0 cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9y ZmM4Nzk5Lmh0bWwqbmFtZS10aGUtc2NvcGUtb2YtcHJvdG9jb2xzLWluLWxfXztJdyEhTkV0NnlN YU8tZ2shVEF1aVh2UEEwNDFiXzhKN3p0a0tCTlZiNDJWNjRsV3Y5dlpEaERLU3FhYlppdWhJaVNF M2ZhR0c3eTA2Z0daZSQgICh3aGljaCBpcyBub3QsIG9mIGNvdXJzZSwgYW4gSUVURiBkb2N1bWVu dCkuDQoNCiAgIEJyaWFuDQoNCj4NCj4gLS0tIHRvbnkNCj4NCj4NCj4NCj4NCj4NCj4gT24gU3Vu LCBPY3QgMywgMjAyMSBhdCA2OjEzIEFNIEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBl bnRlckBnbWFpbC5jb20gPG1haWx0bzpicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+PiB3cm90 ZToNCj4NCj4gICAgIFJvbiwNCj4NCj4gICAgIFRoZSBmaXJzdCBzZW50ZW5jZSBjaXRlcyBSRkM4 NDAyIHdoaWNoIHVuYW1iaWd1b3VzbHkgZGVzY3JpYmVzIFNSIGFzIGENCj4gICAgIGxpbWl0ZWQg ZG9tYWluIHByb3Rjb2wgKGxpbWl0ZWQgdG8gYW4gIlNSIGRvbWFpbiIsIHRoYXQgaXMuKQ0KPg0K PiAgICAgU28gd2l0aGluIHN1Y2ggYSBkb21haW4sIHRoaXMgZGVzY3JpYmVzIHVzaW5nIDEyOCBi aXQgcXVhbnRpdGllcyBjYWxsZWQNCj4gICAgIFNlZ21lbnQgSWRlbnRpZmllcnMgdGhhdCBpbiBz b21lIGNhc2VzLCBidXQgYXBwYXJlbnRseSBub3QgaW4gdGhlIGZvcm1hdHMNCj4gICAgIGRlZmlu ZWQgaGVyZSwgaGFzIHRoZSBzYW1lIHN0cnVjdHVyZSBhcyBhbiBJUCBhZGRyZXNzLg0KPg0KPiAg ICAgRG9lcyB0aGF0IGhhcm0gdGhlIEludGVybmV0LCBldmVuIGlmIGl0IGxlYWtzPyBJdCBtaWdo dCBkaXNhcHBvaW50IHRoZQ0KPiAgICAgc2VuZGVyLCBhcyBhbnkgc2VuZGVyIG9mIGEgYm9ndXMg cGFja2V0IGlzIGRpc2FwcG9pbnRlZCwgYnV0IGFwYXJ0IGZyb20gdGhhdCwNCj4gICAgIHdobyBp cyBkYW1hZ2VkPw0KPg0KPiAgICAgUmVnYXJkcw0KPiAgICAgICAgQnJpYW4gQ2FycGVudGVyDQo+ DQo+ICAgICBPbiAwMi1PY3QtMjEgMDk6MzQsIFJvbiBCb25pY2Egd3JvdGU6DQo+ICAgICA+IEZv bGtzLA0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPiBEcmFmdC1maWxzZmlsc2No ZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi0wMiBpbnRyb2R1Y2VzIHRocmVlIG5ldw0K PiAgICAgU0lEIHR5cGVzIHRoYXQgY2FuIG9jY3VweSB0aGUgRGVzdGluYXRpb24gQWRkcmVzcyBm aWVsZCBvZiBhbiBJUHY2IGhlYWRlci4gU2VlIFNlY3Rpb25zIDQuMSwgNC4yLCBhbmQgNC4zIG9m IHRoZSBkcmFmdCBmb3IgZGV0YWlscy4NCj4gICAgID4NCj4gICAgID4NCj4gICAgID4NCj4gICAg ID4gVGhlIFNQUklORyBXRyBoYXMgaXNzdWVkIGEgY2FsbCBmb3IgYWRvcHRpb24gZm9yIHRoaXMg ZHJhZnQuDQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+IEl0IGlzIG5vdCBjbGVh ciB0aGF0IHRoZXNlIFNJRCB0eXBlcyBjYW4gYmUgaGFybW9uaXplZCB3aXRoIHRoZSBJUHY2IGFk ZHJlc3NpbmcgYXJjaGl0ZWN0dXJlLg0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAgPg0KPiAgICAg PiBEb2VzIGFueW9uZSBoYXZlIGFuIG9waW5pb24/DQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+ DQo+ICAgICA+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgUm9uDQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+DQo+ICAgICA+IEp1bmlw ZXIgQnVzaW5lc3MgVXNlIE9ubHkNCj4gICAgID4NCj4gICAgID4NCj4gICAgID4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gICAgID4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+ICAgICA+ IGlwdjZAaWV0Zi5vcmcgPG1haWx0bzppcHY2QGlldGYub3JnPg0KPiAgICAgPiBBZG1pbmlzdHJh dGl2ZSBSZXF1ZXN0czogaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Nl9fOyEhTkV0NnlNYU8tZ2shVEF1aVh2UEEwNDFi XzhKN3p0a0tCTlZiNDJWNjRsV3Y5dlpEaERLU3FhYlppdWhJaVNFM2ZhR0c3NFhVb3NVRyQgIDxo dHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pcHY2X187ISFORXQ2eU1hTy1nayFUQXVpWHZQQTA0MWJfOEo3enRrS0JOVmI0MlY2 NGxXdjl2WkRoREtTcWFiWml1aElpU0UzZmFHRzc0WFVvc1VHJCA+DQo+ICAgICA+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+ICAgICA+DQo+DQo+ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAgICAgSUVURiBJUHY2IHdvcmtp bmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+ICAgICBpcHY2QGlldGYub3JnIDxtYWlsdG86aXB2NkBp ZXRmLm9yZz4NCj4gICAgIEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiANCj4gaHR0cHM6Ly91cmxk ZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2 Ng0KPiBfXzshIU5FdDZ5TWFPLWdrIVRBdWlYdlBBMDQxYl84Sjd6dGtLQk5WYjQyVjY0bFd2OXZa RGhES1NxYWJaaXVoSWlTRTNmDQo+IGFHRzc0WFVvc1VHJA0KPGh0dHBzOi8vdXJsZGVmZW5zZS5j b20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjZfXzshIU5F dDZ5TWFPLWdrIVRBdWlYdlBBMDQxYl84Sjd6dGtLQk5WYjQyVjY0bFd2OXZaRGhES1NxYWJaaXVo SWlTRTNmYUdHNzRYVW9zVUckID4NCj4gICAgIA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0K From nobody Mon Oct 4 14:16:00 2021 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 75B863A0C55 for ; Mon, 4 Oct 2021 14:15:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 yYlqoMXra2_e for ; Mon, 4 Oct 2021 14:15:46 -0700 (PDT) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (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 271003A0C56 for ; Mon, 4 Oct 2021 14:15:46 -0700 (PDT) Received: by mail-ua1-x929.google.com with SMTP id e7so4183815ual.11 for ; Mon, 04 Oct 2021 14:15:46 -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=Kaee9kIdbeWK3ueIB6UN+tDn/O35LS2mjX1BLBCQTdA=; b=RvMiM/I+32U+QzpF27TBiR3PPvDDfr9DEPnUxy2wxYnhd/lQodwq0emtB7zZ4d7PCQ ufwlnOY8iNt3s6nOTdOl41/W8EZNqQoZ2lBtu6VGzP/YrqmVN2xStKNBsVrclM0XdXOC 1LEEw7V7GFKIEPDJPbplXuN0m4D5Mte21eb/d1Cs8tRDU1p3scoXZftQqfDRJWvbRCRW akBsLUrXVD44kUiJRfngCo1QGq5s+RyRzKK35C/ISSQcUx1saASWWy01JX6O96O9PILh 9LDqYuh31MRkv95pICxtj0Z0YcisDGAxGQe1TVRzwk/ard852n7ATCL3LzR/iCmw0ISj DQag== 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=Kaee9kIdbeWK3ueIB6UN+tDn/O35LS2mjX1BLBCQTdA=; b=7PhGaIqCnJqN/K7OVqij0i3Z5TMCfot9iwkAFYrLeOxZN7aRwRolr1T8NPDYTs7nd+ bKhFiz7QFF25HhfmFd9Po+Zw5vZiw894yRHVJn0GjUuDUC8YJ1QCXeaPL02iJRWzxt1P QvX/XkwfAUjLKMfrxiXzm9KAUFlUkYtqtR36ejFHXY/Z4qRsEhaEgWaVqOc1dwhiLCPW 4t33zgK+zYuxLD0WlOs5mXBluqL/EdSetIVcByD+Nt/SElQ89qKKWwGcd1QFQd5MbekQ pZ+uTShU/FURlyeC1tuM4lphRhJXhMVudQndSphf0BGCiz82cMjzGu/LZqr1KLzj5O6L 7d6Q== X-Gm-Message-State: AOAM532V48bsidBJW7fhCNaa9FnNXZ+h7ALXs5tHFnrb2dy8FxmYpGF2 V32RsDUL8b5ZsivtrUTkSkr5Z/HpqwH9za09gxesXQ== X-Google-Smtp-Source: ABdhPJyS6E2++pUv6u/LnHUXoE4eFx9OAEJw5ifw8eHC/1nBJ906XKeVi471NYccQZLjIOU6/Q+HbRCo0QwWUN6VoFs= X-Received: by 2002:ab0:6ed4:: with SMTP id c20mr5024761uav.108.1633382144999; Mon, 04 Oct 2021 14:15:44 -0700 (PDT) MIME-Version: 1.0 References: <6d4eff6d-6fdc-992e-3a01-13bce8b05cd0@gmail.com> In-Reply-To: From: Robert Raszuk Date: Mon, 4 Oct 2021 23:15:36 +0200 Message-ID: To: Ron Bonica Cc: Brian E Carpenter , Tony Przygienda , SPRING WG , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="0000000000008917be05cd8d6a98" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 04 Oct 2021 21:15:52 -0000 --0000000000008917be05cd8d6a98 Content-Type: text/plain; charset="UTF-8" Hi Ron, Your below example has nothing to do with Internet Standard violation. You are free to define new ethertype and new IP header format any time you wish to do so. Obviously it can not be called IPv6 any more as it is not compatible with IPv6 IP header format. Main reason why SRv6 has chosen to use IPv6 is to make architecture practically deployable and to make sure SR packets can be forwarded by legacy nodes not SRv6 aware. Best, Robert. On Mon, Oct 4, 2021 at 11:00 PM Ron Bonica wrote: > Brian, > > Is there any limit to the degree that one Internet Standard can violate > another, so long as that violation is constrained to a limited domain? > > For example, if I wanted to reduce the size of IPv6 header by shrinking > the source and destination addresses to 64 bits each, would that be OK? > > > Ron > > --0000000000008917be05cd8d6a98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ron,

Your below example h= as nothing=C2=A0to do with Internet Standard violation.=C2=A0
You are free to define new ethertype and new IP header format a= ny time you wish to do so.=C2=A0

Obviously it can = not be called IPv6 any more as it is not compatible with IPv6 IP header for= mat.=C2=A0

Main reason why SRv6 has chosen to use = IPv6 is to make architecture=C2=A0practically deployable and to make sure S= R packets can be forwarded by legacy nodes not SRv6 aware.=C2=A0
=
Best,
Robert.


On Mon, Oct 4, 2021 = at 11:00 PM Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org> wrote:
Brian,

Is there any limit to the degree that one Internet Standard can violate ano= ther, so long as that violation is constrained to a limited domain?

For example, if I wanted to reduce the size of IPv6 header by shrinking the= source and destination addresses to 64 bits each, would that be OK?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ron

--0000000000008917be05cd8d6a98-- From nobody Mon Oct 4 14:18:06 2021 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 151413A0C5C for ; Mon, 4 Oct 2021 14:18:05 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=liquidtelecom.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 Sz_ZsGCLsevr for ; Mon, 4 Oct 2021 14:17:59 -0700 (PDT) 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 5AE713A0C56 for ; Mon, 4 Oct 2021 14:17:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquidtelecom.com; s=mimecast20210406; t=1633382277; 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; bh=bo/Z9Xy0CeVQ/SjwXHfyPVdyizijRdDfYXpCuQciWss=; b=QNshoBR/nYW6e9cCepCEOHh7LzU8CWlRQxopFVOoqMSWgDGTfuxvglESgtyOLZYS3yziLx un6xdbZ2ZqpCNLvsGOW6nAO3+tr4qzT3RynyxaDM2V3cG5cYiJvx28C9qd6rF+ksf9NWFu RSilajonLQTwiX/xhIL9IS1CYUVkqJo= Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-he1eur02lp2056.outbound.protection.outlook.com [104.47.5.56]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-26-3NhQrTemOja9LA63TdAaLA-1; Mon, 04 Oct 2021 22:17:55 +0100 X-MC-Unique: 3NhQrTemOja9LA63TdAaLA-1 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com (2603:10a6:20b:346::6) by AS8PR03MB7798.eurprd03.prod.outlook.com (2603:10a6:20b:349::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.19; Mon, 4 Oct 2021 21:17:54 +0000 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9]) by AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9%5]) with mapi id 15.20.4566.022; Mon, 4 Oct 2021 21:17:53 +0000 From: Andrew Alston To: Ron Bonica , Brian E Carpenter , Tony Przygienda CC: SPRING WG , "6man@ietf.org" <6man@ietf.org> Thread-Topic: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 Thread-Index: AQHXuWVLmLBHkCjhBkCaDrWG9sKcEw== Date: Mon, 4 Oct 2021 21:17:53 +0000 Message-ID: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.53.21091200 msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-04T21:00:05Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=22550c08-c1ec-44e3-a243-950a4d3f9709; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f29fa76d-fcc2-4007-2f7b-08d9877c6dea x-ms-traffictypediagnostic: AS8PR03MB7798: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: mKQUHFclXcMJZrxBfrRgCql4LWQJjGkpet2XMp3vWl/TgaJAvdGHt2jNg/C+RpNkWeJuFIfEGhmCefm8mbO4oV0KSacAGq8SXvF018+5JwAiw5IVBy33xXW9ludJbyVHLRsP2YHA5gWpWbQV+3y3q72zwvyQ7UUkvy2T76iEaNVnJYDygoDcjKQxMQPfnOOMbI4AalTROuvFMAt995D7lsMryQbJsDdbJxinv0WcXKTeLZAWEj3LjZhCbppoNsXXJ3XkMRlLrn0Ixa2en1s1uOgBv0WbhVJy9hdh4dzDB2wyPGJdEv8R3rmFc7nHT/qUvUeRZg2UG4f4vI9Q2CrdN/2182zn/w4+C85st5V+KjyD9MrIln0vtlRlAxt0RnaBjktBZylGiMMGZ4MFMTHTgJRt8GfRjdZPt8gXPH/nkxEgQphcMdeyx4BxxIfHGSnqXrhgUmEIPiMwvLSuWCZFvN84G07MIVP/G/fAlewSHNn7Eqjg9omY1UmOrBluH7iGWE6vuV1m+ceDbx9xL+2zwqGX120GHBWqc4Pu09uvfabawpLEpRrdSIrsDBWc47g1GuHNGlShyC4n6z18ZN+AqOA/Ay5g5FTcVaZKAgTsWMlNbXSzFYLx0sgNiZME8Ahr4cBTEOx4ZHp7MKLZ89aYZghziHGuvGhcCBTxGSKpsvcbRGD3xrOzrsXXUchUgR4wy+uCC5JZ9IM/QbVJzFv0uOuY4iRpAWubvgr3F/qETHO9CZLzC1K8f4FpMJoCMUeQOiag2Lf+KdLOBBSlOBvc+4YPoqGeo56tEjLIk+o0flS/7WdwBzAilNfkT6kgopWiv4JFhh8cUs2qiqaokvDj24HlDcKz32xtIYoZLH279k4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR03MB7622.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(54906003)(5660300002)(4326008)(83380400001)(110136005)(38070700005)(66574015)(966005)(6486002)(66446008)(8936002)(66556008)(71200400001)(2616005)(76116006)(38100700002)(91956017)(66476007)(8676002)(53546011)(36756003)(64756008)(316002)(122000001)(86362001)(6512007)(186003)(508600001)(2906002)(6506007)(166002)(66946007)(33656002)(45980500001); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MnN2UERSR3Y2VmtJTWZiWW5IRmdKTFc1YW1rc3E0Uml6RzAyQU5VUVZabWo3?= =?utf-8?B?SVJPYzRzcndYTUZBSE94NGNoZlBUY3RzQmpjQUltT25FWGdJSUlucENIcjFO?= =?utf-8?B?bFBaVkVvMityZ1lkOE8rVDlzVXVOQVl5cSt3M1RONWZJaDJFdVdqRmRrMDg3?= =?utf-8?B?UUdZWVJIb0dLVlFYZVJwdGExU0Y1b1VrSk1PN2tzUWNidkJTclptVjFTSHpi?= =?utf-8?B?alJEWlJ0Q0tIcW1kbDVVTXZyM2E1anBMMmtkMmQ4ZTJ0Z1NBY1RaVERoSGds?= =?utf-8?B?dzZVaERONUl6VmFCVnIybVZlZll0U1lWUlhvUkw3eW0rZjNBeVg1YUJ6NlNJ?= =?utf-8?B?cjdMMHk4MXMrSzBtNmt0Q3lYRGh5Yk53a2Fpdy9ZN0ZYTXc4WENadk5TZGVs?= =?utf-8?B?UWxNY1F2dXQ1QXZ3d1hETFROU2RGL2VDSnd1eEtjdmdnUGRXcjFYWWExWmdj?= =?utf-8?B?SUd2SHZqbHdZUlQ5RDZHZngxRWpCRHArd1B4T0trT2JOUWpiZXNtWUw1dDVU?= =?utf-8?B?ZHdPNXg0U0JsdUI0T2t2ZWFkcFNqcDkrRXhqWVg2SXhTMkJralUwSTdEL2tR?= =?utf-8?B?ZW04L3c3cW1ETVpaSk9TdTFjcFRCU0lGT0NBSGRWNXhrdjgyZkduak9RSkF1?= =?utf-8?B?NXllczRWTmY1ZnZHMTM3TzU1cjAvZGpwRUd6Y01pb0taUzQxa3FYN2dTSUJP?= =?utf-8?B?a0FlWTFRVXY3LzdNY1dKSjdiOW40SWlGS2R3NGpqOUJlNm45L2xkWUR5dG16?= =?utf-8?B?U1RqU0JxNGpQUzV5NThlNG02TmYzUzlWb0Z3QVZHYVRHTk4rTmd6TWZlWDJr?= =?utf-8?B?QnRDNzBxL2xoVU8zSWlscjkrRWRud1ZoSE9peVZlbXpMWXlRS1lMWk5Gdndy?= =?utf-8?B?eTZ3Z1dkdmo0aElEd2RmelAxNzdHTWp3eVgzREZFNmlPM0s5d0xyNXdEQ3h5?= =?utf-8?B?cmltaXhsSjFDcUtoYUJYTDZSOHQxWVNHQ00zK1lOSVIrT3p2V1NsbW9SaFRJ?= =?utf-8?B?dSs4REpMNGhqVXlrYW1QZ1BONTdqUCtKVXFyVDBuNC9pS3hMNzF3WFE0NFZx?= =?utf-8?B?MnBMY0VCM1U3eWtlNEE4enhid21RNVNnUTMvbVpISUJnc3Z0SUEreGhENHRv?= =?utf-8?B?czNTekhnc1ZVL3pkdWM3eWE3YmtmNGdmVXhXV0ZlVUhKWjdQREcwWDNJYkZh?= =?utf-8?B?SzRqbHdWTnpNaEdEbGxmQ081OHFJSzZpQkhjaDl0aDlpM3prMVVqdW5nOEJC?= =?utf-8?B?djVJelBTSWhyT1ZXNjJzWnF2SXlsMGlqQlBoOWFPMmRYcFBueEtFcEZtNENG?= =?utf-8?B?c1dMUERSTXpKTldERDVCZDhWTmw1dG1sV1FhZnlzRjRkbHJqc2tRZERpNEdE?= =?utf-8?B?NkVPbXREN093ZlFGVWdhR1dnRXBoSzhxSmtpRjd6bkVIVlZwSUU5cEFKMW02?= =?utf-8?B?MmZhUWVvc1hHbytuZWtucmlpczl6MVFMVlFadUlnakswMXY5M05aYjE0NTh3?= =?utf-8?B?dHE0eFpLeVpNU05ad3pZWGZRWEhsRDZBb2ExSjF0RGRnUE94OWoxSzdvbEhX?= =?utf-8?B?UWsrUERYMEd4MmZWMWFPY1pvZHVxRnEwYWkzV2ovcXFkV0lxQk9yRGVmcmZj?= =?utf-8?B?RmtQRFg2MmNKTUE1bCs4dXVjYno5aENHNldWakhXdlpONlUvOGpSUUZZM0sw?= =?utf-8?B?Mm5adldvY0VFK2VZNE1nYmNOZXh1elBpM090SjRSemwxUnFKbFpuRStLdWpi?= =?utf-8?B?SmdOd2lQUU16RU8xL0tjbFFoUDlyeFVXcHVJWUhPN2pKS29XUEdTRjNjeXhI?= =?utf-8?B?Y0h4bXBpbVZkZ0swc0V1RWFYeUd5alVEZnlaSjg1Yk5CYXByQ2FSM25Qd2ZR?= =?utf-8?Q?c32DcN2VWULcU?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB7622.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f29fa76d-fcc2-4007-2f7b-08d9877c6dea X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2021 21:17:53.8199 (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: ZD+moCFgW0mm6s4uzxlywzTnSbKWdev3LKdhR74U5FNv19PLTkhvehRzh2D0UhbBCVsSh6IJrqzNtuGZZTzuS7/8cWq60DSwAgdGTeBrXxc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7798 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquidtelecom.com X-Mimecast-Spam-Score: 1 X-Mimecast-Originator: liquidtelecom.com Content-Language: en-GB Content-Type: multipart/alternative; boundary="_000_B7D0D755E6FB447794D4DAF2526CCBE5liquidtelecomcom_" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 04 Oct 2021 21:18:05 -0000 --_000_B7D0D755E6FB447794D4DAF2526CCBE5liquidtelecomcom_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 QXMgYW4gb3BlcmF0b3IgSSBoYXZlIHRvIGFkbWl0IOKAkyBJIGFsd2F5cyBoYXZlIHNsaWdodCBj b25jZXJucyB3aGVuIHBlb3BsZSBzdGFydCByZWZlcnJpbmcgdG8gdGhlc2UgbGltaXRlZCBkb21h aW4gYXBwbGljYXRpb25zIOKAkyBhbmQgaGVyZSBpcyB3aHkuDQoNCk1hbnkgbmV0d29ya3Mg4oCT IGluY2x1ZGluZyB0aGUgb25lIEkgcnVuIGF0IHRoZSBtb21lbnQg4oCTIGFyZSBzZWdyZWdhdGVk IGZvciBhIGhvc3Qgb2YgcmVhc29ucy4gIFNlcGFyYXRlIElHUCBsZXZlbHMg4oCTIGEgZmV3IEFT TuKAmXMg4oCTIEJHUCBsYWJlbGVkIHVuaWNhc3Qgc3RpdGNoaW5nIGV0YyBldGMuICBBbGwgb2Yg dGhlc2UgbmV0d29ya3MgaG93ZXZlciBhcmUgdW5kZXIgY2VudHJhbCBjb250cm9sIOKAkyBhbmQg d2hlcmUgbmVjZXNzYXJ5IHdlIHN0aXRjaCBhY3Jvc3MgdGhlIGJvdW5kYXJpZXMgKGJncCBsYWJl bGVkIHVuaWNhc3QsIGJpbmRpbmcgU0lE4oCZcyBldGMpLg0KDQpUaGlzIG5ldHdvcmsgc3BsaXR0 aW5nIGFuZCBzZWdyZWdhdGlvbiBpcyBuZWNlc3Nhcnkg4oCTIGJ1dCB0aGUgcXVlc3Rpb24gdGhl biBiZWNvbWVzIOKAkyBob3cgZG8gd2UgZGVmaW5lIHRoZSBkb21haW4uICBZZXMg4oCTIHRlY2hu aWNhbGx5IHdlIGNvdWxkIHNheSB3aXRoaW4gYSBzaW5nbGUgYXV0b25vbW91cyBzeXN0ZW0uICBX ZSBjb3VsZCBzYXkgd2l0aGluIGEgc2luZ2xlIElHUCBhcmVhIOKAkyBtYW55IGRpZmZlcmVudCB3 YXlzIHRvIGRlZmluZSB0aGlzIOKAkyBidXQgaW4gcmVhbGl0eSDigJMgZWFjaCB0aW1lIHdlIGhh dmUgdG8gY3Jvc3Mgc3VjaCBhIGJvdW5kYXJ5IOKAkyB3ZSBoYXZlIHRvIGZpbmQgYSB3YXkgdG8g c3RpdGNoIOKAkyB0byBpbnRlci1vcGVyYXRlIOKAkyBhbmQgdG8gbWFrZSBib3RoIHNpZGVzIG9m IHRoZSBuZXR3b3JrIHRhbGsgdG8gZWFjaCBvdGhlci4gIEVhY2ggdGltZSB3ZSBpbnRyb2R1Y2Ug bWV0aG9kcyB0aGF0IGFyZSBpbmNvbXBhdGlibGUgd2l0aCBlYWNoIG90aGVyIOKAkyB0aGUgY29t cGxleGl0eSBncm93cyDigJMgYW5kIHRoZSBtb3JlIHBvc3NpYmlsaXR5IG9mIGxlYWthZ2UgYmV0 d2VlbiB0aG9zZSBkb21haW5zIG9mIHRoaW5ncyB0aGF0IG1heSBkbyBoYXJtIGdyb3dzIOKAkyBi ZWNhdXNlIHVubGlrZSBhIHRydWx5IGV4dGVybmFsIGJvdW5kYXJ5LCB0aGUgY29udHJvbHMgYmV0 d2VlbiDigJxpbnRlcm5hbOKAnSBib3VuZGFyaWVzIGFyZSBvZnRlbiBtb3JlIGxvb3NlbHkgZGVm aW5lZCBmb3IgYSBob3N0IG9mIHJlYXNvbnMuDQoNCkZvciB0aGlzIHJlYXNvbiBJIHJlYWxseSBw cmVmZXIgdG8gYXZvaWQgdGhlc2Ug4oCcbGltaXRlZOKAnSBkb21haW4gc2NlbmFyaW9zIHRoYXQg b3V0cmlnaHQgdmlvbGF0ZSBvdGhlciBzdGFuZGFyZHMg4oCTIGJlY2F1c2UgaXQgY2FuIOKAkyBh bmQgZG9lcyDigJMgY3JlYXRlIGNvbXBsZXhpdHkgaW4gbGFyZ2UgbmV0d29ya3MgdGhhdCBieSBu ZWNlc3NpdHksIGJ1dCBpdCB0ZWNobmljYWwsIGdlby1wb2xpdGljYWwsIG9yZ2FuaXphdGlvbmFs IG9yIG90aGVyIHJlYXNvbiwgaGF2ZSBoYWQgdG8g4oCcc3BsaXTigJ0gdGhlIGRvbWFpbiDigJMg YnV0IHN0aWxsIHdhbnQgdGhlIGVuZCB0byBlbmQgZnVuY3Rpb25hbGl0eS4NCg0KVGhhbmtzDQoN CkFuZHJldw0KDQoNCkZyb206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJl aGFsZiBvZiBSb24gQm9uaWNhIDxyYm9uaWNhPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+ DQpEYXRlOiBUdWVzZGF5LCA1IE9jdG9iZXIgMjAyMSBhdCAwMDowMA0KVG86IEJyaWFuIEUgQ2Fy cGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+LCBUb255IFByenlnaWVuZGEgPHRv bnlzaWV0ZkBnbWFpbC5jb20+DQpDYzogU1BSSU5HIFdHIDxzcHJpbmdAaWV0Zi5vcmc+LCAiNm1h bkBpZXRmLm9yZyIgPDZtYW5AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gZHJhZnQt Zmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24tMDINCg0KQnJpYW4sDQoN CklzIHRoZXJlIGFueSBsaW1pdCB0byB0aGUgZGVncmVlIHRoYXQgb25lIEludGVybmV0IFN0YW5k YXJkIGNhbiB2aW9sYXRlIGFub3RoZXIsIHNvIGxvbmcgYXMgdGhhdCB2aW9sYXRpb24gaXMgY29u c3RyYWluZWQgdG8gYSBsaW1pdGVkIGRvbWFpbj8NCg0KRm9yIGV4YW1wbGUsIGlmIEkgd2FudGVk IHRvIHJlZHVjZSB0aGUgc2l6ZSBvZiBJUHY2IGhlYWRlciBieSBzaHJpbmtpbmcgdGhlIHNvdXJj ZSBhbmQgZGVzdGluYXRpb24gYWRkcmVzc2VzIHRvIDY0IGJpdHMgZWFjaCwgd291bGQgdGhhdCBi ZSBPSz8NCg0KUm9uDQoNCg0KDQpKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJw ZW50ZXJAZ21haWwuY29tPg0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDQsIDIwMjEgNDowNSBQTQ0K VG86IFRvbnkgUHJ6eWdpZW5kYSA8dG9ueXNpZXRmQGdtYWlsLmNvbT4NCkNjOiBSb24gQm9uaWNh IDxyYm9uaWNhQGp1bmlwZXIubmV0PjsgNm1hbkBpZXRmLm9yZzsgU1BSSU5HIFdHIDxzcHJpbmdA aWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1z cmgtY29tcHJlc3Npb24tMDINCg0KW0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250 ZW50XQ0KDQoNClRvbnksDQpPbiAwNS1PY3QtMjEgMDI6MzIsIFRvbnkgUHJ6eWdpZW5kYSB3cm90 ZToNCj4gVGFraW5nIHRoaXMgbmV3ICJwaGlsb3NvcGh5IG9mIGxpbWl0ZWQgZG9tYWluIiB0byBp dHMgYml0dGVyDQo+IGNvbmNsdXNpb24NCj4NCj4gQSBpcyBJbnRlcm5ldCBTdGFuZGFyZA0KPiBC IGlzIGFsc28gSW50ZXJuZXQgU3RhbmRhcmQgZm9yICJMaW1pdGVkIERvbWFpbiIgdGhhdCB2aW9s YXRlcyBBIEMgaXMNCj4gYWxzbyBJbnRlcm5ldCBTdGFuZGFyZCBmb3IgIkxpbWl0ZWQgRG9tYWlu IiB0aGF0IHZpb2xhdGVzIEEgRCBpcyBhbHNvDQo+IEludGVybmV0IFN0YW5kYXJkIGZvciAiTGlt aXRlZCBEb21haW4iIHRoYXQgdmlvbGV0ZXMgQw0KPg0KPiBzbyBieSB0cmFuc2l0aXZlIGNoYWlu IEQgdmlvbGF0ZXMgQyBhbmQgaGVuY2UgQSBidXQgbm90IEIuIEhlbmNlIEQgYW5kIEIgY2FuIGJl IGRlcGxveWVkIHRvZ2V0aGVyIChtYXliZSkgYnV0IG5vdCBhbnkgb3RoZXIgY29tYmluYXRpb24u DQo+DQo+IFNvIHdoYXQgcHVycG9zZXMgd2lsbCBJRVRGIHNlcnZlLiBUbyBkZWZpbmUgNCBkaWZm ZXJlbnQgInN0YW5kYXJkcyIgdGhhdCBoYXZlICJsaW1pdGVkIGRvbWFpbiB2aW9sYXRpb24gZGVw ZW5kZW5jaWVzIiBhbW9uZ3N0IGVhY2ggb3RoZXIgYnV0IGJhc2VkIG9uIGFsZ2VicmEgY2xvc3Vy ZSBjYW4gc29tZXRpbWVzIGJlIGRlcGxveWVkIHRvZ2V0aGVyLiBBbmQgd2Ugd2lsbCB0cmFjayB0 aGlzIGFuZCBjYWxsIHRoYXQgInN0YW5kYXJkcyIgPyBSZWFsbHkgPw0KDQpUaGVyZSdzIGFuIGF0 dGVtcHRlZCBhbmFseXNpcyBvZiB0aGlzIGlzc3VlIGF0IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20v djMvX19odHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZjODc5OS5odG1sKm5hbWUtdGhl LXNjb3BlLW9mLXByb3RvY29scy1pbi1sX187SXchIU5FdDZ5TWFPLWdrIVRBdWlYdlBBMDQxYl84 Sjd6dGtLQk5WYjQyVjY0bFd2OXZaRGhES1NxYWJaaXVoSWlTRTNmYUdHN3kwNmdHWmUkPGh0dHBz Oi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZmMvcmZj ODc5OS5odG1sKm5hbWUtdGhlLXNjb3BlLW9mLXByb3RvY29scy1pbi1sX187SXchIU5FdDZ5TWFP LWdrIVRBdWlYdlBBMDQxYl84Sjd6dGtLQk5WYjQyVjY0bFd2OXZaRGhES1NxYWJaaXVoSWlTRTNm YUdHN3kwNmdHWmUkPiAod2hpY2ggaXMgbm90LCBvZiBjb3Vyc2UsIGFuIElFVEYgZG9jdW1lbnQp Lg0KDQpCcmlhbg0KDQo+DQo+IC0tLSB0b255DQo+DQo+DQo+DQo+DQo+DQo+IE9uIFN1biwgT2N0 IDMsIDIwMjEgYXQgNjoxMyBBTSBCcmlhbiBFIENhcnBlbnRlciA8YnJpYW4uZS5jYXJwZW50ZXJA Z21haWwuY29tIDxtYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwuY29tPj4gd3JvdGU6DQo+ DQo+IFJvbiwNCj4NCj4gVGhlIGZpcnN0IHNlbnRlbmNlIGNpdGVzIFJGQzg0MDIgd2hpY2ggdW5h bWJpZ3VvdXNseSBkZXNjcmliZXMgU1IgYXMgYQ0KPiBsaW1pdGVkIGRvbWFpbiBwcm90Y29sIChs aW1pdGVkIHRvIGFuICJTUiBkb21haW4iLCB0aGF0IGlzLikNCj4NCj4gU28gd2l0aGluIHN1Y2gg YSBkb21haW4sIHRoaXMgZGVzY3JpYmVzIHVzaW5nIDEyOCBiaXQgcXVhbnRpdGllcyBjYWxsZWQN Cj4gU2VnbWVudCBJZGVudGlmaWVycyB0aGF0IGluIHNvbWUgY2FzZXMsIGJ1dCBhcHBhcmVudGx5 IG5vdCBpbiB0aGUgZm9ybWF0cw0KPiBkZWZpbmVkIGhlcmUsIGhhcyB0aGUgc2FtZSBzdHJ1Y3R1 cmUgYXMgYW4gSVAgYWRkcmVzcy4NCj4NCj4gRG9lcyB0aGF0IGhhcm0gdGhlIEludGVybmV0LCBl dmVuIGlmIGl0IGxlYWtzPyBJdCBtaWdodCBkaXNhcHBvaW50IHRoZQ0KPiBzZW5kZXIsIGFzIGFu eSBzZW5kZXIgb2YgYSBib2d1cyBwYWNrZXQgaXMgZGlzYXBwb2ludGVkLCBidXQgYXBhcnQgZnJv bSB0aGF0LA0KPiB3aG8gaXMgZGFtYWdlZD8NCj4NCj4gUmVnYXJkcw0KPiBCcmlhbiBDYXJwZW50 ZXINCj4NCj4gT24gMDItT2N0LTIxIDA5OjM0LCBSb24gQm9uaWNhIHdyb3RlOg0KPiA+IEZvbGtz LA0KPiA+DQo+ID4NCj4gPg0KPiA+IERyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3Jo LWNvbXByZXNzaW9uLTAyIGludHJvZHVjZXMgdGhyZWUgbmV3DQo+IFNJRCB0eXBlcyB0aGF0IGNh biBvY2N1cHkgdGhlIERlc3RpbmF0aW9uIEFkZHJlc3MgZmllbGQgb2YgYW4gSVB2NiBoZWFkZXIu IFNlZSBTZWN0aW9ucyA0LjEsIDQuMiwgYW5kIDQuMyBvZiB0aGUgZHJhZnQgZm9yIGRldGFpbHMu DQo+ID4NCj4gPg0KPiA+DQo+ID4gVGhlIFNQUklORyBXRyBoYXMgaXNzdWVkIGEgY2FsbCBmb3Ig YWRvcHRpb24gZm9yIHRoaXMgZHJhZnQuDQo+ID4NCj4gPg0KPiA+DQo+ID4gSXQgaXMgbm90IGNs ZWFyIHRoYXQgdGhlc2UgU0lEIHR5cGVzIGNhbiBiZSBoYXJtb25pemVkIHdpdGggdGhlIElQdjYg YWRkcmVzc2luZyBhcmNoaXRlY3R1cmUuDQo+ID4NCj4gPg0KPiA+DQo+ID4gRG9lcyBhbnlvbmUg aGF2ZSBhbiBvcGluaW9uPw0KPiA+DQo+ID4NCj4gPg0KPiA+IFJvbg0KPiA+DQo+ID4NCj4gPg0K PiA+DQo+ID4gSnVuaXBlciBCdXNpbmVzcyBVc2UgT25seQ0KPiA+DQo+ID4NCj4gPiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiA+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiA+IGlwdjZA aWV0Zi5vcmcgPG1haWx0bzppcHY2QGlldGYub3JnPg0KPiA+IEFkbWluaXN0cmF0aXZlIFJlcXVl c3RzOiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pcHY2X187ISFORXQ2eU1hTy1nayFUQXVpWHZQQTA0MWJfOEo3enRrS0JO VmI0MlY2NGxXdjl2WkRoREtTcWFiWml1aElpU0UzZmFHRzc0WFVvc1VHJDxodHRwczovL3VybGRl ZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2 X187ISFORXQ2eU1hTy1nayFUQXVpWHZQQTA0MWJfOEo3enRrS0JOVmI0MlY2NGxXdjl2WkRoREtT cWFiWml1aElpU0UzZmFHRzc0WFVvc1VHJD4gPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19o dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjZfXzshIU5FdDZ5TWFPLWdr IVRBdWlYdlBBMDQxYl84Sjd6dGtLQk5WYjQyVjY0bFd2OXZaRGhES1NxYWJaaXVoSWlTRTNmYUdH NzRYVW9zVUckPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lwdjZfXzshIU5FdDZ5TWFPLWdrIVRBdWlYdlBBMDQxYl84Sjd6 dGtLQk5WYjQyVjY0bFd2OXZaRGhES1NxYWJaaXVoSWlTRTNmYUdHNzRYVW9zVUckPiA+DQo+ID4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gPg0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJRVRGIElQdjYgd29ya2luZyBn cm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRmLm9yZyA8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+ DQo+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOg0KPiBodHRwczovL3VybGRlZmVuc2UuY29tL3Yz L19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2PGh0dHBzOi8vdXJs ZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lw djY+DQo+IF9fOyEhTkV0NnlNYU8tZ2shVEF1aVh2UEEwNDFiXzhKN3p0a0tCTlZiNDJWNjRsV3Y5 dlpEaERLU3FhYlppdWhJaVNFM2YNCj4gYUdHNzRYVW9zVUckDQo8aHR0cHM6Ly91cmxkZWZlbnNl LmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Nl9fOyEh TkV0NnlNYU8tZ2shVEF1aVh2UEEwNDFiXzhKN3p0a0tCTlZiNDJWNjRsV3Y5dlpEaERLU3FhYlpp dWhJaVNFM2ZhR0c3NFhVb3NVRyQ8aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Nl9fOyEhTkV0NnlNYU8tZ2shVEF1aVh2 UEEwNDFiXzhKN3p0a0tCTlZiNDJWNjRsV3Y5dlpEaERLU3FhYlppdWhJaVNFM2ZhR0c3NFhVb3NV RyQ+ID4NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmcN Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPg0KDQo= --_000_B7D0D755E6FB447794D4DAF2526CCBE5liquidtelecomcom_ Content-Type: text/html; charset=UTF-8 Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcy LjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJlbi1LRSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BcyBhbiBvcGVyYXRvciBJIGhhdmUgdG8gYWRtaXQg4oCT IEkgYWx3YXlzIGhhdmUgc2xpZ2h0IGNvbmNlcm5zIHdoZW4gcGVvcGxlIHN0YXJ0IHJlZmVycmlu ZyB0byB0aGVzZSBsaW1pdGVkIGRvbWFpbiBhcHBsaWNhdGlvbnMg4oCTIGFuZCBoZXJlIGlzIHdo eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5NYW55IG5ldHdvcmtzIOKAkyBpbmNs dWRpbmcgdGhlIG9uZSBJIHJ1biBhdCB0aGUgbW9tZW50IOKAkyBhcmUgc2VncmVnYXRlZCBmb3Ig YSBob3N0IG9mIHJlYXNvbnMuJm5ic3A7IFNlcGFyYXRlIElHUCBsZXZlbHMg4oCTIGEgZmV3IEFT TuKAmXMg4oCTIEJHUCBsYWJlbGVkIHVuaWNhc3Qgc3RpdGNoaW5nIGV0YyBldGMuJm5ic3A7IEFs bCBvZiB0aGVzZQ0KIG5ldHdvcmtzIGhvd2V2ZXIgYXJlIHVuZGVyIGNlbnRyYWwgY29udHJvbCDi gJMgYW5kIHdoZXJlIG5lY2Vzc2FyeSB3ZSBzdGl0Y2ggYWNyb3NzIHRoZSBib3VuZGFyaWVzIChi Z3AgbGFiZWxlZCB1bmljYXN0LCBiaW5kaW5nIFNJROKAmXMgZXRjKS4mbmJzcDsNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoaXMgbmV0d29yayBzcGxpdHRpbmcgYW5kIHNlZ3Jl Z2F0aW9uIGlzIG5lY2Vzc2FyeSDigJMgYnV0IHRoZSBxdWVzdGlvbiB0aGVuIGJlY29tZXMg4oCT IGhvdyBkbyB3ZSBkZWZpbmUgdGhlIGRvbWFpbi4mbmJzcDsgWWVzIOKAkyB0ZWNobmljYWxseSB3 ZSBjb3VsZCBzYXkgd2l0aGluIGEgc2luZ2xlIGF1dG9ub21vdXMgc3lzdGVtLiZuYnNwOw0KIFdl IGNvdWxkIHNheSB3aXRoaW4gYSBzaW5nbGUgSUdQIGFyZWEg4oCTIG1hbnkgZGlmZmVyZW50IHdh eXMgdG8gZGVmaW5lIHRoaXMg4oCTIGJ1dCBpbiByZWFsaXR5IOKAkyBlYWNoIHRpbWUgd2UgaGF2 ZSB0byBjcm9zcyBzdWNoIGEgYm91bmRhcnkg4oCTIHdlIGhhdmUgdG8gZmluZCBhIHdheSB0byBz dGl0Y2gg4oCTIHRvIGludGVyLW9wZXJhdGUg4oCTIGFuZCB0byBtYWtlIGJvdGggc2lkZXMgb2Yg dGhlIG5ldHdvcmsgdGFsayB0byBlYWNoIG90aGVyLiZuYnNwOyBFYWNoDQogdGltZSB3ZSBpbnRy b2R1Y2UgbWV0aG9kcyB0aGF0IGFyZSBpbmNvbXBhdGlibGUgd2l0aCBlYWNoIG90aGVyIOKAkyB0 aGUgY29tcGxleGl0eSBncm93cyDigJMgYW5kIHRoZSBtb3JlIHBvc3NpYmlsaXR5IG9mIGxlYWth Z2UgYmV0d2VlbiB0aG9zZSBkb21haW5zIG9mIHRoaW5ncyB0aGF0IG1heSBkbyBoYXJtIGdyb3dz IOKAkyBiZWNhdXNlIHVubGlrZSBhIHRydWx5IGV4dGVybmFsIGJvdW5kYXJ5LCB0aGUgY29udHJv bHMgYmV0d2VlbiDigJxpbnRlcm5hbOKAnQ0KIGJvdW5kYXJpZXMgYXJlIG9mdGVuIG1vcmUgbG9v c2VseSBkZWZpbmVkIGZvciBhIGhvc3Qgb2YgcmVhc29ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5Gb3IgdGhpcyByZWFzb24gSSByZWFsbHkgcHJlZmVyIHRvIGF2b2lkIHRoZXNl IOKAnGxpbWl0ZWTigJ0gZG9tYWluIHNjZW5hcmlvcyB0aGF0IG91dHJpZ2h0IHZpb2xhdGUgb3Ro ZXIgc3RhbmRhcmRzIOKAkyBiZWNhdXNlIGl0IGNhbiDigJMgYW5kIGRvZXMg4oCTIGNyZWF0ZSBj b21wbGV4aXR5IGluIGxhcmdlIG5ldHdvcmtzIHRoYXQNCiBieSBuZWNlc3NpdHksIGJ1dCBpdCB0 ZWNobmljYWwsIGdlby1wb2xpdGljYWwsIG9yZ2FuaXphdGlvbmFsIG9yIG90aGVyIHJlYXNvbiwg aGF2ZSBoYWQgdG8g4oCcc3BsaXTigJ0gdGhlIGRvbWFpbiDigJMgYnV0IHN0aWxsIHdhbnQgdGhl IGVuZCB0byBlbmQgZnVuY3Rpb25hbGl0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BbmRyZXc8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAw Y20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj5zcHJpbmcgJmx0O3NwcmluZy1ib3VuY2VzQGlldGYub3Jn Jmd0OyBvbiBiZWhhbGYgb2YgUm9uIEJvbmljYSAmbHQ7cmJvbmljYT00MGp1bmlwZXIubmV0QGRt YXJjLmlldGYub3JnJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCA1IE9jdG9iZXIgMjAy MSBhdCAwMDowMDxicj4NCjxiPlRvOiA8L2I+QnJpYW4gRSBDYXJwZW50ZXIgJmx0O2JyaWFuLmUu Y2FycGVudGVyQGdtYWlsLmNvbSZndDssIFRvbnkgUHJ6eWdpZW5kYSAmbHQ7dG9ueXNpZXRmQGdt YWlsLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPlNQUklORyBXRyAmbHQ7c3ByaW5nQGlldGYub3Jn Jmd0OywgJnF1b3Q7Nm1hbkBpZXRmLm9yZyZxdW90OyAmbHQ7Nm1hbkBpZXRmLm9yZyZndDs8YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtzcHJpbmddIGRyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5n LXNydjYtc3JoLWNvbXByZXNzaW9uLTAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJyaWFuLDxicj4NCjxicj4NCklzIHRoZXJlIGFueSBsaW1p dCB0byB0aGUgZGVncmVlIHRoYXQgb25lIEludGVybmV0IFN0YW5kYXJkIGNhbiB2aW9sYXRlIGFu b3RoZXIsIHNvIGxvbmcgYXMgdGhhdCB2aW9sYXRpb24gaXMgY29uc3RyYWluZWQgdG8gYSBsaW1p dGVkIGRvbWFpbj88YnI+DQo8YnI+DQpGb3IgZXhhbXBsZSwgaWYgSSB3YW50ZWQgdG8gcmVkdWNl IHRoZSBzaXplIG9mIElQdjYgaGVhZGVyIGJ5IHNocmlua2luZyB0aGUgc291cmNlIGFuZCBkZXN0 aW5hdGlvbiBhZGRyZXNzZXMgdG8gNjQgYml0cyBlYWNoLCB3b3VsZCB0aGF0IGJlIE9LPzxicj4N Cjxicj4NClJvbjxicj4NCjxicj4NCjxicj4NCjxicj4NCkp1bmlwZXIgQnVzaW5lc3MgVXNlIE9u bHk8YnI+DQo8YnI+DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCkZyb206IEJyaWFu IEUgQ2FycGVudGVyICZsdDticmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20mZ3Q7IDxicj4NClNl bnQ6IE1vbmRheSwgT2N0b2JlciA0LCAyMDIxIDQ6MDUgUE08YnI+DQpUbzogVG9ueSBQcnp5Z2ll bmRhICZsdDt0b255c2lldGZAZ21haWwuY29tJmd0Ozxicj4NCkNjOiBSb24gQm9uaWNhICZsdDty Ym9uaWNhQGp1bmlwZXIubmV0Jmd0OzsgNm1hbkBpZXRmLm9yZzsgU1BSSU5HIFdHICZsdDtzcHJp bmdAaWV0Zi5vcmcmZ3Q7PGJyPg0KU3ViamVjdDogUmU6IGRyYWZ0LWZpbHNmaWxzY2hlbmctc3By aW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLTAyPGJyPg0KPGJyPg0KW0V4dGVybmFsIEVtYWlsLiBC ZSBjYXV0aW91cyBvZiBjb250ZW50XTxicj4NCjxicj4NCjxicj4NClRvbnksPGJyPg0KT24gMDUt T2N0LTIxIDAyOjMyLCBUb255IFByenlnaWVuZGEgd3JvdGU6PGJyPg0KJmd0OyBUYWtpbmcgdGhp cyBuZXcgJnF1b3Q7cGhpbG9zb3BoeSBvZiBsaW1pdGVkIGRvbWFpbiZxdW90OyB0byBpdHMgYml0 dGVyIDxicj4NCiZndDsgY29uY2x1c2lvbjxicj4NCiZndDs8YnI+DQomZ3Q7IEEgaXMgSW50ZXJu ZXQgU3RhbmRhcmQ8YnI+DQomZ3Q7IEIgaXMgYWxzbyBJbnRlcm5ldCBTdGFuZGFyZCBmb3IgJnF1 b3Q7TGltaXRlZCBEb21haW4mcXVvdDsgdGhhdCB2aW9sYXRlcyBBIEMgaXMgPGJyPg0KJmd0OyBh bHNvIEludGVybmV0IFN0YW5kYXJkIGZvciAmcXVvdDtMaW1pdGVkIERvbWFpbiZxdW90OyB0aGF0 IHZpb2xhdGVzIEEgRCBpcyBhbHNvIDxicj4NCiZndDsgSW50ZXJuZXQgU3RhbmRhcmQgZm9yICZx dW90O0xpbWl0ZWQgRG9tYWluJnF1b3Q7IHRoYXQgdmlvbGV0ZXMgQzxicj4NCiZndDs8YnI+DQom Z3Q7IHNvIGJ5IHRyYW5zaXRpdmUgY2hhaW4gRCB2aW9sYXRlcyBDIGFuZCBoZW5jZSBBIGJ1dCBu b3QgQi4gSGVuY2UgRCBhbmQgQiBjYW4gYmUgZGVwbG95ZWQgdG9nZXRoZXIgKG1heWJlKSBidXQg bm90IGFueSBvdGhlciBjb21iaW5hdGlvbi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBTbyB3aGF0IHB1 cnBvc2VzIHdpbGwgSUVURiBzZXJ2ZS4gVG8gZGVmaW5lIDQgZGlmZmVyZW50ICZxdW90O3N0YW5k YXJkcyZxdW90OyB0aGF0IGhhdmUgJnF1b3Q7bGltaXRlZCBkb21haW4gdmlvbGF0aW9uIGRlcGVu ZGVuY2llcyZxdW90OyBhbW9uZ3N0IGVhY2ggb3RoZXIgYnV0IGJhc2VkIG9uIGFsZ2VicmEgY2xv c3VyZSBjYW4gc29tZXRpbWVzIGJlIGRlcGxveWVkIHRvZ2V0aGVyLiBBbmQgd2Ugd2lsbCB0cmFj ayB0aGlzIGFuZCBjYWxsIHRoYXQgJnF1b3Q7c3RhbmRhcmRzJnF1b3Q7ID8gUmVhbGx5DQogPzxi cj4NCjxicj4NClRoZXJlJ3MgYW4gYXR0ZW1wdGVkIGFuYWx5c2lzIG9mIHRoaXMgaXNzdWUgYXQg PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3LnJmYy1lZGl0 b3Iub3JnL3JmYy9yZmM4Nzk5Lmh0bWwqbmFtZS10aGUtc2NvcGUtb2YtcHJvdG9jb2xzLWluLWxf XztJdyEhTkV0NnlNYU8tZ2shVEF1aVh2UEEwNDFiXzhKN3p0a0tCTlZiNDJWNjRsV3Y5dlpEaERL U3FhYlppdWhJaVNFM2ZhR0c3eTA2Z0daZSQiPg0KaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9f X2h0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL3JmYy9yZmM4Nzk5Lmh0bWwqbmFtZS10aGUtc2Nv cGUtb2YtcHJvdG9jb2xzLWluLWxfXztJdyEhTkV0NnlNYU8tZ2shVEF1aVh2UEEwNDFiXzhKN3p0 a0tCTlZiNDJWNjRsV3Y5dlpEaERLU3FhYlppdWhJaVNFM2ZhR0c3eTA2Z0daZSQ8L2E+ICh3aGlj aCBpcyBub3QsIG9mIGNvdXJzZSwgYW4gSUVURiBkb2N1bWVudCkuPGJyPg0KPGJyPg0KQnJpYW48 YnI+DQo8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLS0gdG9ueTxicj4NCiZndDs8YnI+DQomZ3Q7PGJy Pg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBTdW4sIE9jdCAzLCAyMDIx IGF0IDY6MTMgQU0gQnJpYW4gRSBDYXJwZW50ZXIgJmx0O2JyaWFuLmUuY2FycGVudGVyQGdtYWls LmNvbSAmbHQ7bWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbSZndDsmZ3Q7IHdyb3Rl Ojxicj4NCiZndDs8YnI+DQomZ3Q7IFJvbiw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGUgZmlyc3Qg c2VudGVuY2UgY2l0ZXMgUkZDODQwMiB3aGljaCB1bmFtYmlndW91c2x5IGRlc2NyaWJlcyBTUiBh cyBhPGJyPg0KJmd0OyBsaW1pdGVkIGRvbWFpbiBwcm90Y29sIChsaW1pdGVkIHRvIGFuICZxdW90 O1NSIGRvbWFpbiZxdW90OywgdGhhdCBpcy4pPGJyPg0KJmd0Ozxicj4NCiZndDsgU28gd2l0aGlu IHN1Y2ggYSBkb21haW4sIHRoaXMgZGVzY3JpYmVzIHVzaW5nIDEyOCBiaXQgcXVhbnRpdGllcyBj YWxsZWQ8YnI+DQomZ3Q7IFNlZ21lbnQgSWRlbnRpZmllcnMgdGhhdCBpbiBzb21lIGNhc2VzLCBi dXQgYXBwYXJlbnRseSBub3QgaW4gdGhlIGZvcm1hdHM8YnI+DQomZ3Q7IGRlZmluZWQgaGVyZSwg aGFzIHRoZSBzYW1lIHN0cnVjdHVyZSBhcyBhbiBJUCBhZGRyZXNzLjxicj4NCiZndDs8YnI+DQom Z3Q7IERvZXMgdGhhdCBoYXJtIHRoZSBJbnRlcm5ldCwgZXZlbiBpZiBpdCBsZWFrcz8gSXQgbWln aHQgZGlzYXBwb2ludCB0aGU8YnI+DQomZ3Q7IHNlbmRlciwgYXMgYW55IHNlbmRlciBvZiBhIGJv Z3VzIHBhY2tldCBpcyBkaXNhcHBvaW50ZWQsIGJ1dCBhcGFydCBmcm9tIHRoYXQsPGJyPg0KJmd0 OyB3aG8gaXMgZGFtYWdlZD88YnI+DQomZ3Q7PGJyPg0KJmd0OyBSZWdhcmRzPGJyPg0KJmd0OyBC cmlhbiBDYXJwZW50ZXI8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiAwMi1PY3QtMjEgMDk6MzQsIFJv biBCb25pY2Egd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IEZvbGtzLDxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBEcmFmdC1maWxzZmlsc2No ZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi0wMiBpbnRyb2R1Y2VzIHRocmVlIG5ldzxi cj4NCiZndDsgU0lEIHR5cGVzIHRoYXQgY2FuIG9jY3VweSB0aGUgRGVzdGluYXRpb24gQWRkcmVz cyBmaWVsZCBvZiBhbiBJUHY2IGhlYWRlci4gU2VlIFNlY3Rpb25zIDQuMSwgNC4yLCBhbmQgNC4z IG9mIHRoZSBkcmFmdCBmb3IgZGV0YWlscy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVGhlIFNQUklORyBXRyBoYXMgaXNzdWVkIGEg Y2FsbCBmb3IgYWRvcHRpb24gZm9yIHRoaXMgZHJhZnQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEl0IGlzIG5vdCBjbGVhciB0aGF0 IHRoZXNlIFNJRCB0eXBlcyBjYW4gYmUgaGFybW9uaXplZCB3aXRoIHRoZSBJUHY2IGFkZHJlc3Np bmcgYXJjaGl0ZWN0dXJlLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyBEb2VzIGFueW9uZSBoYXZlIGFuIG9waW5pb24/PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFJvbjxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyBKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5PGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyAmZ3Q7 IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyBpcHY2 QGlldGYub3JnICZsdDttYWlsdG86aXB2NkBpZXRmLm9yZyZndDs8YnI+DQomZ3Q7ICZndDsgQWRt aW5pc3RyYXRpdmUgUmVxdWVzdHM6IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMv X19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjZfXzshIU5FdDZ5TWFP LWdrIVRBdWlYdlBBMDQxYl84Sjd6dGtLQk5WYjQyVjY0bFd2OXZaRGhES1NxYWJaaXVoSWlTRTNm YUdHNzRYVW9zVUckIj4NCmh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjZfXzshIU5FdDZ5TWFPLWdrIVRBdWlYdlBBMDQx Yl84Sjd6dGtLQk5WYjQyVjY0bFd2OXZaRGhES1NxYWJaaXVoSWlTRTNmYUdHNzRYVW9zVUckPC9h PiAmbHQ7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Nl9fOyEhTkV0NnlNYU8tZ2shVEF1aVh2UEEwNDFi XzhKN3p0a0tCTlZiNDJWNjRsV3Y5dlpEaERLU3FhYlppdWhJaVNFM2ZhR0c3NFhVb3NVRyQiPmh0 dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lwdjZfXzshIU5FdDZ5TWFPLWdrIVRBdWlYdlBBMDQxYl84Sjd6dGtLQk5WYjQyVjY0 bFd2OXZaRGhES1NxYWJaaXVoSWlTRTNmYUdHNzRYVW9zVUckPC9hPg0KICZndDs8YnI+DQomZ3Q7 ICZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLTxicj4NCiZndDsgSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0PGJy Pg0KJmd0OyBpcHY2QGlldGYub3JnICZsdDttYWlsdG86aXB2NkBpZXRmLm9yZyZndDs8YnI+DQom Z3Q7IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiA8YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v dXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lwdjYiPg0KaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaXB2NjwvYT48YnI+DQomZ3Q7IF9fOyEhTkV0NnlNYU8tZ2shVEF1 aVh2UEEwNDFiXzhKN3p0a0tCTlZiNDJWNjRsV3Y5dlpEaERLU3FhYlppdWhJaVNFM2Y8YnI+DQom Z3Q7IGFHRzc0WFVvc1VHJDxicj4NCiZsdDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29t L3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2X187ISFORXQ2 eU1hTy1nayFUQXVpWHZQQTA0MWJfOEo3enRrS0JOVmI0MlY2NGxXdjl2WkRoREtTcWFiWml1aElp U0UzZmFHRzc0WFVvc1VHJCI+aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Nl9fOyEhTkV0NnlNYU8tZ2shVEF1aVh2UEEw NDFiXzhKN3p0a0tCTlZiNDJWNjRsV3Y5dlpEaERLU3FhYlppdWhJaVNFM2ZhR0c3NFhVb3NVRyQ8 L2E+ICZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7PGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzcHJp bmcgbWFpbGluZyBsaXN0PGJyPg0Kc3ByaW5nQGlldGYub3JnPGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmciPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPC9hPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B7D0D755E6FB447794D4DAF2526CCBE5liquidtelecomcom_-- From nobody Mon Oct 4 14:54:44 2021 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 550933A0C61; Mon, 4 Oct 2021 14:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bell.ca 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 Xks8oqsISQiG; Mon, 4 Oct 2021 14:54:33 -0700 (PDT) Received: from ESA1-Wyn.bell.ca (esa1-wyn.bell.ca [67.69.243.161]) (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 C59F23A0C5D; Mon, 4 Oct 2021 14:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1633384473; x=1664920473; h=from:to:cc:date:message-id:mime-version:subject; bh=0GfDOvaLlDxVUgja8LFX0BIy/TaIvYTZLDpwX5Cb6Uk=; b=WDQc65bhK8FdonkfUWy7huNBgmiT99JHuWO4h0xWKLSAdkskJEebbi9w zx8pd5g30myRdI2VAjuS9wa9Rl938h4ZdMrECOeixe7GyJsAwUwpfLhPz VD7xLlIpGisIjthUtdwgmBETd0EW5c2VeGT15VmzBrkmAi1WoPJmAEkl+ rr2DZ9iHXyZwGsdli4Q9uC9hcHzlPH+2LCYtGCJfCpGz3Y8uydOpZASJ7 XagNdYr02e1adGqlfGZ0qgRczlTdXz9fJGbxXvTvYw0ClzdYRmSHkB+iE Kd3Y91durGLoLjO4rKBZkCele0ajiinLZ5gjlfzDenEGv9PNIn66DFHpB Q==; IronPort-SDR: X8GZ9a0xORbaJtPT3o6i0EXMoAOhGIdVG+59MLnXtbdt8e/lSVYAZWDYI9uHyo856NpHxEBLmL bwcY/rGVOUiQ== Received: from dm5cch-d00.bellca.int.bell.ca (HELO DG1MBX02-WYN.bell.corp.bce.ca) ([198.235.102.30]) by esa01corp-wyn.bell.corp.bce.ca with ESMTP; 04 Oct 2021 17:54:30 -0400 Received: from DG1MBX04-WYN.bell.corp.bce.ca (2002:8eb6:120e::8eb6:120e) by DG1MBX02-WYN.bell.corp.bce.ca (2002:8eb6:120c::8eb6:120c) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Mon, 4 Oct 2021 17:54:30 -0400 Received: from DG1MBX04-WYN.bell.corp.bce.ca ([fe80::3409:329a:cc17:c939]) by DG1MBX04-WYN.bell.corp.bce.ca ([fe80::3409:329a:cc17:c939%22]) with mapi id 15.00.1497.018; Mon, 4 Oct 2021 17:54:30 -0400 From: "Voyer, Daniel" To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: [EXT][spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: AQHXuWpoWkD3gfXwMEmJFeeQeppARQ== Date: Mon, 4 Oct 2021 21:54:30 +0000 Message-ID: <71EFCBC8-A8A6-4A0F-A30F-2EB0C9760D3F@bell.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.53.21091200 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.28.239.64] Content-Type: multipart/alternative; boundary="_000_71EFCBC8A8A64A0FA30F2EB0C9760D3Fbellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 04 Oct 2021 21:54:39 -0000 --_000_71EFCBC8A8A64A0FA30F2EB0C9760D3Fbellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBoYXZlIHJlYWQgdGhlIGRyYWZ0IGFuZCBoaWdobHkgc3VwcG9ydHMgaXQgZm9yIGFkb3B0aW9u Lg0KDQoNCiAgMS4gIFdoZW4gbG9va2luZyBhdCB0aGUgYW5hbHlzaXMgZnJvbSB0aGUgRFQsIENT SUQgbWF0Y2hlcyBhbGwgcmVxdWlyZW1lbnRzIGZvciBTUnY2Ow0KICAyLiAgV2UgY3VycmVudGx5 IGhhdmUgaXQgZGVwbG95ZWQgaW4gcHJvZHVjdGlvbjsNCiAgMy4gIFdl4oCZdmUgZG9uZSBpbnRl cm9wICBiL3cgdmVuZG9ycyBpbiBvdXIgbGFiLg0KDQpUaGFua3MsDQpkYW4NCg0KDQpGcm9tOiBz cHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgSmFtZXMgR3VpY2hh cmQgPGphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbT4NCkRhdGU6IEZyaWRheSwgT2N0b2Jl ciAxLCAyMDIxIGF0IDEwOjA1IEFNDQpUbzogU1BSSU5HIFdHIDxzcHJpbmdAaWV0Zi5vcmc+DQpD YzogInNwcmluZy1jaGFpcnNAaWV0Zi5vcmciIDxzcHJpbmctY2hhaXJzQGlldGYub3JnPg0KU3Vi amVjdDogW0VYVF1bc3ByaW5nXSBXRyBBZG9wdGlvbiBjYWxsIGZvciBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21w cmVzc2lvbi8NCg0KRGVhciBXRzoNCg0KVGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGV4cHJlc3Mg dGhlaXIgYXBwcmVjaWF0aW9uIGZvciBhbGwgdGhlIHJlc3BvbnNlcyByZWNlaXZlZCB0byBvdXIg ZW1haWxzIHdpdGggcmVmZXJlbmNlIHRvIGhvdyB0aGUgd29ya2luZyBncm91cCB3aXNoZXMgdG8g bW92ZSBmb3J3YXJkIHdpdGggcmVzcGVjdCB0byBhIHNvbHV0aW9uIGZvciBTUnY2IGNvbXByZXNz aW9uLg0KDQpUaGUgYXBwYXJlbnQgaW5jbGluYXRpb24gb2YgdGhlIHdvcmtpbmcgZ3JvdXAgaXMg dG8gdXNlIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hl bmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyBhcyB0aGUgYmFzaXMgZm9yIGl0cyBjb21w cmVzc2lvbiBzdGFuZGFyZGl6YXRpb24gd29yay4gVGhhdCBpcyBwYXJ0IG9mIHdoYXQgdGhpcyBl bWFpbCBhdHRlbXB0cyB0byBjb25maXJtLg0KDQpCZWNhdXNlIG9mIHRoZSBhYm92ZSB0aGUgY2hh aXJzIHdvdWxkIGxpa2UgdG8gaXNzdWUgYSAyLXdlZWsgV0cgY2FsbCBmb3IgYWRvcHRpb24gZW5k aW5nIE9jdG9iZXIgMTV0aCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vIGJ1dCB3aXRoIHNv bWUgY2xlYXIgZ3VpZGVsaW5lcyBhcyBmb2xsb3dzLiBCeSBleHByZXNzaW5nIHN1cHBvcnQgZm9y IGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgeW91IGFyZSBmdWxseSBhd2FyZSBvZiBhbmQgYXJl IGFja25vd2xlZGdpbmcgdGhhdDoNCg0KDQogIDEuICBUaGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAg aXMgYWRvcHRpbmcgYSBkb2N1bWVudCB0aGF0IGhhcyBtdWx0aXBsZSBTUnY2IEVuZHBvaW50IGJl aGF2aW9ycy4NCiAgMi4gIFRoZSBkb2N1bWVudCBpcyBhIOKAnGxpdmluZ+KAnSBkb2N1bWVudDsg aXQgbWF5IGNoYW5nZSBhcyBpdCBnb2VzIHRocm91Z2ggcmV2aWV3IGFuZCBhbmFseXNpcyBieSB0 aGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAuDQogIDMuICBBbGwgb3BlbiBkaXNjdXNzaW9uIHBvaW50 cyByYWlzZWQgb24gb3VyIG1haWxpbmcgbGlzdCBNVVNUIGJlIGFkZHJlc3NlZCBCRUZPUkUgc2Fp ZCBkb2N1bWVudCBpcyBhbGxvd2VkIHRvIHByb2dyZXNzIGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAg dG8gcHVibGljYXRpb24uIEEgbGlzdCBvZiB0aGVzZSBkaXNjdXNzaW9uIHBvaW50cyB3aWxsIGJl IGRvY3VtZW50ZWQgaW4gdGhlIFdHIGRvY3VtZW50IGFuZCBtYWludGFpbmVkIGJ5IHRoZSBkb2N1 bWVudCBlZGl0b3IgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgY2hhaXJzLg0KICA0LiAgSWYgdGhp cyBkb2N1bWVudCBpcyBhZG9wdGVkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLCB0aGUgY2hhaXJzIHNw ZWNpZnkgYXMgcGFydCBvZiB0aGUgYWRvcHRpb24gY2FsbCB0aGF0IHRoZSBmb2xsb3dpbmcgdGV4 dCBkZXNjcmliaW5nIGFuIG9wZW4gaXNzdWUgYmUgYWRkZWQgdG8gdGhlIGRvY3VtZW50IGluIHRo ZSBhYm92ZS1kZXNjcmliZWQgb3BlbiBpc3N1ZXMgc2VjdGlvbjoNCiAgICAgKiAgICJHaXZlbiB0 aGF0IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBzYWlkIHRoYXQgaXQgd2FudHMgdG8gc3RhbmRhcmRp emUgb25lIGRhdGEgcGxhbmUgc29sdXRpb24sIGFuZCBnaXZlbiB0aGF0IHRoZSBkb2N1bWVudCBj b250YWlucyBtdWx0aXBsZSBTUnY2IEVuZFBvaW50IGJlaGF2aW9ycyB0aGF0IHNvbWUgV0cgbWVt YmVycyBoYXZlIHN0YXRlZCBhcmUgbXVsdGlwbGUgZGF0YSBwbGFuZSBzb2x1dGlvbnMsIHRoZSB3 b3JraW5nIGdyb3VwIHdpbGwgYWRkcmVzcyB3aGV0aGVyIHRoaXMgaXMgdmFsaWQgYW5kIGNvaGVy ZW50IHdpdGggaXRzIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uIG9iamVjdGl2ZS4iLg0KDQpQbGVh c2UgY29uc2lkZXIgdGhlIGFib3ZlIGd1aWRlbGluZXMgYXMgeW91IGRlY2lkZSBvbiB3aGV0aGVy IHRvIHN1cHBvcnQgb3Igbm90IHRoaXMgV0cgYWRvcHRpb24uIFBsZWFzZSBleHByZXNzIGNsZWFy bHkgeW91ciByZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9uLXN1cHBvcnQgYXMgd2VsbCBhcyBhbnkg b3BlbiBkaXNjdXNzaW9uIHBvaW50cyB5b3Ugd291bGQgbGlrZSBhZGRyZXNzZWQgc2hvdWxkIHRo ZSBkb2N1bWVudCBiZSBhZG9wdGVkIGludG8gdGhlIHdvcmtpbmcgZ3JvdXAuDQoNClRoYW5rcyEN Cg0KSmltLCBCcnVubyAmIEpvZWwNCg0KDQo= --_000_71EFCBC8A8A64A0FA30F2EB0C9760D3Fbellca_ Content-Type: text/html; charset="utf-8" Content-ID: <52FC5674A5B5714BAB1BFF980817EBA4@exchange.bell.ca> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFp blRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowY207DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLk1zb0xpc3RQYXJh Z3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1z dHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0 Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjI0MDk5MjA2NDsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6MTM5MTQ3MDAyMjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjY1NDY0NDcxNzsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE4NTQzNzIyMCAtMTAwMjk1ODI0MiA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5 ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjM7 DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DqDsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNv LWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2 ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjc1MTY5OTM5MzsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTcyMTY1NDc3NiA2NzY5ODcwMyA2NzY5 ODY4OSA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcx MyA2NzY5ODcxNTt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpy b21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDQN Cgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30N CkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJp Z2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDI6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwyOmxl dmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQt aW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxNjY4NzU0MDA4Ow0KCW1z by1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNjc0NzEwNTM0IC0x NjUwODEyMDg2IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3 Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwzOmxldmVsMQ0KCXttc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2lu LWxlZnQ6NTQuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgltYXJnaW4tbGVmdDo5 MC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVmdDoxMjYuMHB0 Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1s ZWZ0OjE2Mi4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjE5 OC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVmdDoyMzQuMHB0 Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1s ZWZ0OjI3MC4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDgNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCW1hcmdpbi1sZWZ0OjMw Ni4wcHQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgltYXJnaW4tbGVmdDozNDIuMHB0 Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0K CXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIgbGlu az0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBoYXZl IHJlYWQgdGhlIGRyYWZ0IGFuZCBoaWdobHkgc3VwcG9ydHMgaXQgZm9yIGFkb3B0aW9uLiA8bzpw Pg0KPC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGNtIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7bXNvLWxpc3Q6 bDMgbGV2ZWwxIGxmbzUiPldoZW4gbG9va2luZyBhdCB0aGUgYW5hbHlzaXMgZnJvbSB0aGUgRFQs IENTSUQgbWF0Y2hlcyBhbGwgcmVxdWlyZW1lbnRzIGZvciBTUnY2OzxvOnA+PC9vOnA+PC9saT48 bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDoxOC4wcHQ7bXNv LWxpc3Q6bDMgbGV2ZWwxIGxmbzUiPldlIGN1cnJlbnRseSBoYXZlIGl0IGRlcGxveWVkIGluIHBy b2R1Y3Rpb247PG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjE4LjBwdDttc28tbGlzdDpsMyBsZXZlbDEgbGZvNSI+V2XigJl2ZSBk b25lIGludGVyb3AgJm5ic3A7Yi93IHZlbmRvcnMgaW4gb3VyIGxhYi48bzpwPjwvbzpwPjwvbGk+ PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+ZGFuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPnNwcmluZyAmbHQ7c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBv ZiBKYW1lcyBHdWljaGFyZCAmbHQ7amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tJmd0Ozxi cj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIE9jdG9iZXIgMSwgMjAyMSBhdCAxMDowNSBBTTxicj4N CjxiPlRvOiA8L2I+U1BSSU5HIFdHICZsdDtzcHJpbmdAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6 IDwvYj4mcXVvdDtzcHJpbmctY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDtzcHJpbmctY2hhaXJz QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bRVhUXVtzcHJpbmddIFdHIEFkb3B0 aW9uIGNhbGwgZm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNm aWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5EZWFyIFdHOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGNo YWlycyB3b3VsZCBsaWtlIHRvIGV4cHJlc3MgdGhlaXIgYXBwcmVjaWF0aW9uIGZvciBhbGwgdGhl IHJlc3BvbnNlcyByZWNlaXZlZCB0byBvdXIgZW1haWxzIHdpdGggcmVmZXJlbmNlIHRvIGhvdyB0 aGUgd29ya2luZyBncm91cCB3aXNoZXMgdG8gbW92ZSBmb3J3YXJkIHdpdGggcmVzcGVjdCB0byBh IHNvbHV0aW9uIGZvciBTUnY2IGNvbXByZXNzaW9uLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUg YXBwYXJlbnQgaW5jbGluYXRpb24gb2YgdGhlIHdvcmtpbmcgZ3JvdXAgaXMgdG8gdXNlDQo8YSBo cmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5n LXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8iPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24v PC9hPiBhcyB0aGUgYmFzaXMgZm9yIGl0cyBjb21wcmVzc2lvbiBzdGFuZGFyZGl6YXRpb24gd29y ay4gVGhhdCBpcyBwYXJ0IG9mIHdoYXQgdGhpcyBlbWFpbCBhdHRlbXB0cyB0byBjb25maXJtLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+QmVjYXVzZSBvZiB0aGUgYWJvdmUgdGhlIGNoYWlycyB3b3VsZCBs aWtlIHRvIGlzc3VlIGEgMi13ZWVrIFdHIGNhbGwgZm9yIGFkb3B0aW9uIGVuZGluZyBPY3RvYmVy IDE1PHN1cD50aDwvc3VwPiBmb3INCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyI+ DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNw cmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88L2E+IGJ1dCB3aXRoIHNvbWUgY2xlYXIgZ3VpZGVs aW5lcyBhcyBmb2xsb3dzLiBCeSBleHByZXNzaW5nIHN1cHBvcnQgZm9yIGFkb3B0aW9uIG9mIHRo aXMgZG9jdW1lbnQgeW91IGFyZSBmdWxseSBhd2FyZSBvZiBhbmQgYXJlIGFja25vd2xlZGdpbmcg dGhhdDoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8b2wgc3R5bGU9Im1h cmdpbi10b3A6MGNtIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDIgbGV2ZWwxIGxmbzMiPjxz cGFuIGxhbmc9IkVOLVVTIj5UaGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAgaXMgYWRvcHRpbmcgYSBk b2N1bWVudCB0aGF0IGhhcyBtdWx0aXBsZSBTUnY2IEVuZHBvaW50IGJlaGF2aW9ycy4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MGNtO21zby1saXN0OmwyIGxldmVsMSBsZm8zIj48c3BhbiBsYW5nPSJFTi1VUyI+ VGhlIGRvY3VtZW50IGlzIGEg4oCcbGl2aW5n4oCdIGRvY3VtZW50OyBpdCBtYXkgY2hhbmdlIGFz IGl0IGdvZXMgdGhyb3VnaCByZXZpZXcgYW5kIGFuYWx5c2lzIGJ5IHRoZSBTUFJJTkcgd29ya2lu ZyBncm91cC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwyIGxldmVsMSBsZm8zIj48c3Bh biBsYW5nPSJFTi1VUyI+QWxsIG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgcmFpc2VkIG9uIG91ciBt YWlsaW5nIGxpc3QgTVVTVCBiZSBhZGRyZXNzZWQgQkVGT1JFIHNhaWQgZG9jdW1lbnQgaXMgYWxs b3dlZCB0byBwcm9ncmVzcyBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIHRvIHB1YmxpY2F0aW9uLiBB IGxpc3QNCiBvZiB0aGVzZSBkaXNjdXNzaW9uIHBvaW50cyB3aWxsIGJlIGRvY3VtZW50ZWQgaW4g dGhlIFdHIGRvY3VtZW50IGFuZCBtYWludGFpbmVkIGJ5IHRoZSBkb2N1bWVudCBlZGl0b3IgaW4g Y29uanVuY3Rpb24gd2l0aCB0aGUgY2hhaXJzLg0KPG86cD48L286cD48L3NwYW4+PC9saT48bGkg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6 bDIgbGV2ZWwxIGxmbzMiPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB0aGlzIGRvY3VtZW50IGlzIGFk b3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAsIHRoZSBjaGFpcnMgc3BlY2lmeSBhcyBwYXJ0IG9m IHRoZSBhZG9wdGlvbiBjYWxsIHRoYXQgdGhlIGZvbGxvd2luZyB0ZXh0IGRlc2NyaWJpbmcgYW4g b3BlbiBpc3N1ZSBiZSBhZGRlZCB0byB0aGUNCiBkb2N1bWVudCBpbiB0aGUgYWJvdmUtZGVzY3Jp YmVkIG9wZW4gaXNzdWVzIHNlY3Rpb246IDxvOnA+PC9vOnA+PC9zcGFuPg0KPHVsIHN0eWxlPSJt YXJnaW4tdG9wOjBjbSIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5 bGU9Im1zby1saXN0OmwyIGxldmVsMiBsZm8zIj48c3BhbiBsYW5nPSJFTi1VUyI+JnF1b3Q7R2l2 ZW4gdGhhdCB0aGUgd29ya2luZyBncm91cCBoYXMgc2FpZCB0aGF0IGl0IHdhbnRzIHRvIHN0YW5k YXJkaXplIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uLCBhbmQgZ2l2ZW4gdGhhdCB0aGUgZG9jdW1l bnQgY29udGFpbnMgbXVsdGlwbGUgU1J2NiBFbmRQb2ludCBiZWhhdmlvcnMgdGhhdCBzb21lIFdH IG1lbWJlcnMNCiBoYXZlIHN0YXRlZCBhcmUgbXVsdGlwbGUgZGF0YSBwbGFuZSBzb2x1dGlvbnMs IHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYWRkcmVzcyB3aGV0aGVyIHRoaXMgaXMgdmFsaWQgYW5k IGNvaGVyZW50IHdpdGggaXRzIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uIG9iamVjdGl2ZS4mcXVv dDsuPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPC9saT48L29sPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5QbGVhc2UgY29uc2lkZXIg dGhlIGFib3ZlIGd1aWRlbGluZXMgYXMgeW91IGRlY2lkZSBvbiB3aGV0aGVyIHRvIHN1cHBvcnQg b3Igbm90IHRoaXMgV0cgYWRvcHRpb24uIFBsZWFzZSBleHByZXNzIGNsZWFybHkgeW91ciByZWFz b25pbmcgZm9yIHN1cHBvcnQvbm9uLXN1cHBvcnQgYXMgd2VsbCBhcyBhbnkgb3BlbiBkaXNjdXNz aW9uIHBvaW50cyB5b3Ugd291bGQgbGlrZSBhZGRyZXNzZWQNCiBzaG91bGQgdGhlIGRvY3VtZW50 IGJlIGFkb3B0ZWQgaW50byB0aGUgd29ya2luZyBncm91cC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRo YW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkppbSwgQnJ1bm8gJmFtcDsgSm9lbDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_71EFCBC8A8A64A0FA30F2EB0C9760D3Fbellca_-- From nobody Mon Oct 4 18:45:20 2021 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 2E1C83A0DFC; Mon, 4 Oct 2021 18:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0USbbOj-MI1G; Mon, 4 Oct 2021 18:44:08 -0700 (PDT) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 53DEE3A0DF9; Mon, 4 Oct 2021 18:44:08 -0700 (PDT) Received: by mail-pj1-x102e.google.com with SMTP id np13so2869664pjb.4; Mon, 04 Oct 2021 18:44:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4gTpZAhpOtu3fJSt5athrM7hNOhB9eYLxFbdt2URyzk=; b=TwcV4XbGNdgkyHDkwlJqsMPmXaujayNzb4Ri3UVLwSZ4ltManQHqqQGPju+Tmesh5e jd2chh7+1hNgYHc/iR0EVoA8D2rrZ5cYNcE8BIZLTe1oEIMW/Q3bXebI5ygyQjvivLYF kluQ0H9vyOAysR4VEP5JXavzRcXSYEAojfzZbQAft2Y+hJ1umnud4xQE40EnDsjyZoxP So1BbWU03r2zvw3ot82A5JaVAjnnXNkLcE1IENjYF0k++b9V2y8j+ejFoMEhmy+Q1Kw8 t248M/OeQhd1UQ8sgqYU8upmvF5+tchyPE3L8Rzzkfpn6N2PU7f5Ra2jTgdgcL0ORESt DbqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4gTpZAhpOtu3fJSt5athrM7hNOhB9eYLxFbdt2URyzk=; b=0jK5BGmln1hv9vsBBe5VpgYH8oR2G2MCO6tfiSPWVOB4/xdyu7L5NtjHTlKj7kSfkr 1XFEZs9hiA9f1zR8Gdsc6KrX3LHc8ji6K7iUxuEBKoaWNH8TcmrhFpd9z4nPreQxNuCZ b78RiRT2J4DgJVWZzDnLiv+wx7tWMvVEFJI+A9R21RbOj0AMrjuDqXbzWlnRJbiOEhBy us+ykIpHGZWOuOOeeOG0Vd+/2K6x3kNbr6qn1WLF+5pFVL9aFxtkQs1OvjEKmHrM4JaH NK2GbX8MUwPJbsKY+cwYEEiZ4XnGQ+52uQaXv3+tmysuBKjWaG7aqKeUEdLiVx1YrzWD TViA== X-Gm-Message-State: AOAM533/EzTW7IBeGbrTD2Itd+cwpaJ/T0QxDJ2LxA0baNsGPlf+CEiu 86oi+dCVJb9EuR6bb9FO2AzS/4dvwQeUtg== X-Google-Smtp-Source: ABdhPJxbn5rcnffTlmbrT3AZeoO4/Liq51+4/NOQkeFj+etom7JfJugk2Zrpf+6pWck7hAPYG37KYw== X-Received: by 2002:a17:90b:4b48:: with SMTP id mi8mr499591pjb.26.1633398247556; Mon, 04 Oct 2021 18:44:07 -0700 (PDT) Received: from ?IPv6:2406:e003:11aa:d701:80b2:5c79:2266:e431? ([2406:e003:11aa:d701:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id b10sm9268124pfl.200.2021.10.04.18.44.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Oct 2021 18:44:06 -0700 (PDT) To: Robert Raszuk , Ron Bonica Cc: Tony Przygienda , SPRING WG , "6man@ietf.org" <6man@ietf.org> References: <6d4eff6d-6fdc-992e-3a01-13bce8b05cd0@gmail.com> From: Brian E Carpenter Message-ID: Date: Tue, 5 Oct 2021 14:44:02 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 05 Oct 2021 01:44:14 -0000 On 05-Oct-21 10:15, Robert Raszuk wrote: > Hi Ron, >=20 > Your below example has nothing=C2=A0to do with Internet Standard violat= ion.=C2=A0 >=20 > You are free to define new ethertype and new IP header format any time = you wish to do so.=C2=A0 >=20 > Obviously it can not be called IPv6 any more as it is not compatible wi= th IPv6 IP header format.=C2=A0 >=20 > Main reason why SRv6 has chosen to use IPv6 is to make architecture=C2=A0= practically deployable and to make sure SR packets can be forwarded by le= gacy nodes not SRv6 aware.=20 Isn't that the point of Ron's question? If the format of the DA field of = a packet doesn't conform to the IPv6 address architecture, how can you ca= ll it an IPv6 packet, or expect the "legacy" node to do anything sensible= ? I have no intention of studying this work in detail, but if some present = or future SID format happens to start with the bytes 0xfe80, a "legacy" n= ode will certainly not forward a packet in which that SID occupies the DA=20 space. I use the word "legacy node" because you do, but actually you mean "norma= l IPv6 node". SRV6 is the new kid on the block. More below... >=20 > Best, > Robert. >=20 >=20 > On Mon, Oct 4, 2021 at 11:00 PM Ron Bonica > wrote: >=20 > Brian, >=20 > Is there any limit to the degree that one Internet Standard can vio= late another, so long as that violation is constrained to a limited domai= n? >=20 > For example, if I wanted to reduce the size of IPv6 header by shrin= king the source and destination addresses to 64 bits each, would that be = OK? There is serious work on shortened addresses, I believe, but that work in= cludes specifying what happens at the domain boundary. Apart from that, I= 've already cited my generic analysis of the question. https://www.rfc-editor.org/rfc/rfc8799.html#name-the-scope-of-protocols-i= n-l I wouldn't have co-authored that document if the IETF wasn't already stan= dardizing quite a number of such protocols. As far as I know, there is no=20 IETF or IAB document that takes a position on whether this is good, bad, = or neutral. Brian >=20 > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=20 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ron >=20 From nobody Tue Oct 5 00:10:08 2021 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 CD4043A0818 for ; Tue, 5 Oct 2021 00:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 CTj9sORwa3_S for ; Tue, 5 Oct 2021 00:10:00 -0700 (PDT) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 5FCC13A0819 for ; Tue, 5 Oct 2021 00:10:00 -0700 (PDT) Received: by mail-ua1-x92b.google.com with SMTP id e7so4927972ual.11 for ; Tue, 05 Oct 2021 00:10:00 -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=u+ppY9VI1ejV861r+tWcXJOaUNK/XWAfR2JaHGRjmwY=; b=WMAkFFi0F26IDl2c5STYe/uGAqTxGrG6BSR4GK7lTPxfzssu6JSaaC9PvpBsCatson TsGIAF3HGNNPprL42yYTMBs7Bne+aqOPfc+dZvkddPD7mMWIiMZ3X1AY/4h1ynl3sjpA HDXxlmyjwt/gv2hF5UlW2slgR5KlT0ITqi6o2/ricBxWE4+FGziyTcQSZJT/jQgIasPU m3kruKPWhIkgMLRzO3bkiFrL8T+9JdXpKuSjse3xxaDINeS/hgTWISwJXMMCYlRgs06r Ch8TKWrdgAmRm5s/fevH7Tx2AYNE02hlOCRsudzVMPNiD5UUa6CvMaejlCUlwCSdEbe4 4bDA== 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=u+ppY9VI1ejV861r+tWcXJOaUNK/XWAfR2JaHGRjmwY=; b=xHOcQsqamE2Pba8epc/SE046NDA6nBxw4uYbuzm1InQzcIWBYEXNA/q7qHx7P2bTS4 tSzCBzgFP8v9w6YPo7tr0Eapj27hEIscsEUMFDS7HCXdB8nX26m8wEoh3gRlt5REfqhR XI6vo/w092ChDjKqyUAuJt/72WTUE+Y90pgBOwUcQKdRb9+oc3wW2ZLcma8aVaFOhcZ5 Rcj1Cq21gt2rrhAb+JGG7G3W5UoIhZNk8yXPsAjKr+9tzoALW/7By8yGyQlZQl5CugD8 ULWE23BxeNVagcwetp0eWl5nGXuQV+HsNgpmCDr/jbnJO+FqrxTgVlDoMS4IrmwDsZ/p oizw== X-Gm-Message-State: AOAM533IwYJewUL5R4RmtMuYu80nOUHcOoLR+IiGQRP/TsRaZK+UbYYD x4yr+vcKUKi/fqHEULzSnjwqz80UJWGUjlBrVQMKdA== X-Google-Smtp-Source: ABdhPJysJXgc8Fd/Q/3moFUlTJGO0lqKlCf2Y8nBrW4HIJiUKpyDVJHxt3Kxr3lMLsHaloHSn/NCTE+c/WXOtNd5yeM= X-Received: by 2002:a05:6130:3a7:: with SMTP id az39mr2895231uab.8.1633417798922; Tue, 05 Oct 2021 00:09:58 -0700 (PDT) MIME-Version: 1.0 References: <6d4eff6d-6fdc-992e-3a01-13bce8b05cd0@gmail.com> In-Reply-To: From: Robert Raszuk Date: Tue, 5 Oct 2021 09:09:50 +0200 Message-ID: To: Brian E Carpenter Cc: Ron Bonica , SPRING WG , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000ace47c05cd95b782" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 05 Oct 2021 07:10:06 -0000 --000000000000ace47c05cd95b782 Content-Type: text/plain; charset="UTF-8" Hi Brian, Thank you - yes by legacy I meant not upgraded one - no different meaning intended. As far as conforming to addressing architecture sorry to say but to me this is red herring. Sure address must be a legal address - no question. But what bits in the address mean is really up to the person allocating them. I can have perfectly valid set of IPv4 addresses which each assigned to different loopback of my node. Then each loopback is configured with completely different behaviour to the packets arriving to it. What matters for routing is the prefix - what matters for actually processing are the remaining bits. Same for IPv6. Kind regards, Robert On Tue, Oct 5, 2021 at 3:44 AM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 05-Oct-21 10:15, Robert Raszuk wrote: > > Hi Ron, > > > > Your below example has nothing to do with Internet Standard violation. > > > > You are free to define new ethertype and new IP header format any time > you wish to do so. > > > > Obviously it can not be called IPv6 any more as it is not compatible > with IPv6 IP header format. > > > > Main reason why SRv6 has chosen to use IPv6 is to make > architecture practically deployable and to make sure SR packets can be > forwarded by legacy nodes not SRv6 aware. > > Isn't that the point of Ron's question? If the format of the DA field of a > packet doesn't conform to the IPv6 address architecture, how can you call > it an IPv6 packet, or expect the "legacy" node to do anything sensible? > > I have no intention of studying this work in detail, but if some present > or future SID format happens to start with the bytes 0xfe80, a "legacy" > node will certainly not forward a packet in which that SID occupies the DA > space. > > I use the word "legacy node" because you do, but actually you mean "normal > IPv6 node". SRV6 is the new kid on the block. > > More below... > > > > > Best, > > Robert. > > > > > > On Mon, Oct 4, 2021 at 11:00 PM Ron Bonica 40juniper.net@dmarc.ietf.org > wrote: > > > > Brian, > > > > Is there any limit to the degree that one Internet Standard can > violate another, so long as that violation is constrained to a limited > domain? > > > > For example, if I wanted to reduce the size of IPv6 header by > shrinking the source and destination addresses to 64 bits each, would that > be OK? > > There is serious work on shortened addresses, I believe, but that work > includes specifying what happens at the domain boundary. Apart from that, > I've already cited my generic analysis of the question. > > https://www.rfc-editor.org/rfc/rfc8799.html#name-the-scope-of-protocols-in-l > > I wouldn't have co-authored that document if the IETF wasn't already > standardizing quite a number of such protocols. As far as I know, there is > no > IETF or IAB document that takes a position on whether this is good, bad, > or neutral. > > Brian > > > > > > > > Ron > > > > --000000000000ace47c05cd95b782 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Brian,

Thank you - yes by legacy I m= eant not upgraded one - no different meaning intended.=C2=A0

=
As far as conforming to addressing architecture sorry to say but= to me this is red herring. Sure address must be a legal address - no quest= ion. But what bits in the address mean is really up to the person allocatin= g them.=C2=A0

I can have perfectly valid set of IP= v4 addresses which each assigned=C2=A0to different loopback of my node. The= n each loopback is configured with completely different behaviour to the pa= ckets arriving to it.=C2=A0

What matters for routi= ng is the prefix - what matters for actually processing are the remaining b= its. Same for IPv6.=C2=A0

Kind regards,
= Robert


On Tue, Oct 5, 2021 at 3:44 AM Brian E Carpenter= <brian.e.carpenter@gmail= .com> wrote:
On 05-Oct-21 10:15, Robert Raszuk wrote:
> Hi Ron,
>
> Your below example has nothing=C2=A0to do with Internet Standard viola= tion.=C2=A0
>
> You are free to define new ethertype and new IP header format any time= you wish to do so.=C2=A0
>
> Obviously it can not be called IPv6 any more as it is not compatible w= ith IPv6 IP header format.=C2=A0
>
> Main reason why SRv6 has chosen to use IPv6 is to make architecture=C2= =A0practically deployable and to make sure SR packets can be forwarded by l= egacy nodes not SRv6 aware.

Isn't that the point of Ron's question? If the format of the DA fie= ld of a packet doesn't conform to the IPv6 address architecture, how ca= n you call it an IPv6 packet, or expect the "legacy" node to do a= nything sensible?

I have no intention of studying this work in detail, but if some present or= future SID format happens to start with the bytes 0xfe80, a "legacy&q= uot; node will certainly not forward a packet in which that SID occupies th= e DA
space.

I use the word "legacy node" because you do, but actually you mea= n "normal IPv6 node". SRV6 is the new kid on the block.

More below...

>
> Best,
> Robert.
>
>
> On Mon, Oct 4, 2021 at 11:00 PM Ron Bonica <rbonica=3D40juniper.net@dmarc.ie= tf.org <mailto:40juniper.net@dmarc.ietf.org>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Brian,
>
>=C2=A0 =C2=A0 =C2=A0Is there any limit to the degree that one Internet = Standard can violate another, so long as that violation is constrained to a= limited domain?
>
>=C2=A0 =C2=A0 =C2=A0For example, if I wanted to reduce the size of IPv6= header by shrinking the source and destination addresses to 64 bits each, = would that be OK?

There is serious work on shortened addresses, I believe, but that work incl= udes specifying what happens at the domain boundary. Apart from that, I'= ;ve already cited my generic analysis of the question.
https://www.rfc-editor.o= rg/rfc/rfc8799.html#name-the-scope-of-protocols-in-l

I wouldn't have co-authored that document if the IETF wasn't alread= y standardizing quite a number of such protocols. As far as I know, there i= s no
IETF or IAB document that takes a position on whether this is good, bad, or= neutral.

=C2=A0 =C2=A0Brian

>
>=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ron
>

--000000000000ace47c05cd95b782-- From nobody Tue Oct 5 01:39:15 2021 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 692033A0905; Tue, 5 Oct 2021 01:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 G9EWUV-8r3u6; Tue, 5 Oct 2021 01:38:19 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 95C053A0900; Tue, 5 Oct 2021 01:38:19 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id h129so23455740iof.1; Tue, 05 Oct 2021 01:38:19 -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=LITy7P7HSZpXXbTa+wIUX+9w5dad18BIqDIzCBbPseQ=; b=WatEqnGftAWTn27CZxWho2p5PCrm5aTms4l9J0k9eV+h1OUvTLPE0GsStOQa8IpZiw zmGg02PpmaGvE9bW8JZOIMc6z2LRC9mJ/XxajcBfXGdt3Lmm8hVvOylSw5LESkiXGzyP NtPd+nfE8BQ/AxAL+s3DTDONEyj9JvS532EnnTfZ1lNQuSHNKtE5zHRVJHrpVdWFeLo9 nDRD/UCyORp+aMruBr4QK1egACujrL8OBxYwScQskj6hYtX4aQE8fVnZvqjbWtMF/giW ZvzzKIo5LhfIfhsvDD5YreKL9UHVtYrvtc4rvlulMoGuAD4hjQrLu2697qRp1ZLIQgom RlDA== 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=LITy7P7HSZpXXbTa+wIUX+9w5dad18BIqDIzCBbPseQ=; b=BAsFY5zf0jsEh1qKL6DOtwXHOBvo9dpgERlXPeBAC3xTT46MQoVof8eaLXiQ1faYsp mT9Ssol68RbRfiGoqAQUXOa0XhDyU/XLS4Q4hKysc4v0vQW6rpG+PIaaNO7GPBbA55rR i01cvgMw8UlqdJ3mZmJSy0TWu/bUrRv/ZWuvuCpNUs8Ql15nld6s0Lt3ObxaJammUnSZ 6yQaDwXh0kwRfV8274TSMXjpZeRMWmOkf0ErkM3uSPpe+Z0DIKynFIwiAoeCssBGjGXa 4cQT2uotYkFAUM/fESregtYJ5h252I2dK1jjyhu+LPFDpU4QbUcRgAX6up1dVhUICc7D R9/A== X-Gm-Message-State: AOAM5321o7muVIyKYlG1FpJVxz7v7gKULojISomfZi6DH0PWOti4wWAp zMeFW+uKoJxS+PoEPbMpZUiw/WrlGCrW64AwwMk= X-Google-Smtp-Source: ABdhPJyFnZf/TGTLPONo4D/VJKOJBxErm9ndtAwNglsjrrRlQp/k2DB3B9wVR+Elw6NWxlefGYoPkCv35ZyRL/47ma4= X-Received: by 2002:a6b:f302:: with SMTP id m2mr1410361ioh.180.1633423098589; Tue, 05 Oct 2021 01:38:18 -0700 (PDT) MIME-Version: 1.0 References: <6d4eff6d-6fdc-992e-3a01-13bce8b05cd0@gmail.com> In-Reply-To: From: Tony Przygienda Date: Tue, 5 Oct 2021 10:37:43 +0200 Message-ID: To: Robert Raszuk Cc: Brian E Carpenter , Ron Bonica , SPRING WG , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="0000000000008f37a405cd96f38f" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 05 Oct 2021 08:38:25 -0000 --0000000000008f37a405cd96f38f Content-Type: text/plain; charset="UTF-8" On Tue, Oct 5, 2021 at 9:10 AM Robert Raszuk wrote: > Hi Brian, > > Thank you - yes by legacy I meant not upgraded one - no different meaning > intended. > > As far as conforming to addressing architecture sorry to say but to me > this is red herring. Sure address must be a legal address - no question. > But what bits in the address mean is really up to the person allocating > them. > unfortunately not. otherwise the postal service would have never worked in the first place. The semantic concepts (and their semiotics) of names/addresses & routes predate the internet by a couple of millenia and did not shift much and we won't most likely shift them (and as side quip the illusion of "flat" addresses as in MAC has proven unscalable yet again ;-). I recommend in the context of networking the seminal 70s paper by Schoh from Xerox. on top you're logically contradicting yourself in the same sentence, if anybody can assign any semantics to an address in the same space because "they allocate it" then no'one can judge what is legal and what isn't And all this here is not the case of intelligence showing by holding two contradicting ideas in one's head, this here is simply enshrining two or more contradicting "standards" in one standards body @ which point in time the term "standards" quickly starts to lose its meaning in first place. well, I said my piece, up to IAB and so on to worry about what's happening here really ... -- tony --0000000000008f37a405cd96f38f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Oct 5, 2021 at 9:10 AM Robert= Raszuk <robert@raszuk.net> = wrote:
Hi Brian,

Thank you - yes by legacy I meant not= upgraded one - no different meaning intended.=C2=A0

As far as conforming to addressing architecture sorry to say but to me t= his is red herring. Sure address must be a legal address - no question. But= what bits in the address mean is really up to the person allocating them.= =C2=A0

unfortunately not. other= wise the postal service would have never worked in the first place. The sem= antic concepts (and their semiotics) of names/addresses & routes predat= e the internet by a couple of millenia and did not shift much and we won= 9;t most likely shift them (and as side quip the illusion of "flat&quo= t; addresses as in MAC has proven unscalable yet again ;-). I recommend in = the context of networking the seminal 70s paper by Schoh from Xerox.

=C2=A0on top you're logically contradicting you= rself in the same sentence, if anybody can assign any semantics to an addre= ss in the same space because "they allocate it" then no'one c= an judge what is legal and what isn't

And= all this here is not the case of intelligence showing by holding two contr= adicting ideas in one's head, this here is simply enshrining two or mor= e contradicting "standards" in one standards body @ which point i= n time the term "standards" quickly starts to lose its meaning in= first place.

well, I said my piece, up to IA= B and so on to worry about what's happening here really ...
<= div>
-- tony
--0000000000008f37a405cd96f38f-- From nobody Tue Oct 5 01:48:02 2021 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 4A1BA3A0908 for ; Tue, 5 Oct 2021 01:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NO_DNS_FOR_FROM=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lapishills-com.20210112.gappssmtp.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 P0MEDJHK-fya for ; Tue, 5 Oct 2021 01:47:54 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 4ED163A08FF for ; Tue, 5 Oct 2021 01:47:53 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id dj4so76063592edb.5 for ; Tue, 05 Oct 2021 01:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lapishills-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UU+QoyvqFgHxELTBZ0xCXdRJhbWnv/VgNWPLKYpsF6U=; b=WjJarsUTGw/TQ8SMsa8+WEiW2aXSk0qB2BIhGUHv9SbXNXVHzTsenWCJ9UqkQJAxIZ D6ccBk+7z1jpXne0BkAM/Ff+oLa9fRolBd94soB8Jmqc23QS8Dq8AdBXkQrf7CKT5T/4 pOEGrUCKirT+vLqrOaWSD4T7FNTEXZ563HD9QFYEd7vDse8ARGBJshk9GpTxR054c40D FDZxRn/MhJHCowgVeQtGqNVCnPXo7TgQci9a5kl+Mkvmz10Rj4P65imweCUHb7R2ktYR BzIyZZx1QGbcvcVWofy6bSeIeDG/rLJtsxMApfMvy2KJ3aYrl1ESwGqLuX3mHXBo0UqD QcRw== 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=UU+QoyvqFgHxELTBZ0xCXdRJhbWnv/VgNWPLKYpsF6U=; b=jkecKPX34sALd4WD7UAFBnXfm8awB50ufCZ4+LTEVLDKPfoyPeYSG3uNYmISePYH2R z5DHo1/pAezI/7iz7bc1jArG4g/9pmtZ1iY1FDGcEjglgmr+pCgSjIFuecEQslkGuzFl eBneGknfqVUUotSUDOPtJ6qLZecxzaXYkDqIqXmjSDu+Pppip0VTBQEjIXAeJYbNYwCd 3rEpl6YyW1GW45KHXzhjQV4TDfFYJLJD2vzZ2gOjemmz+PJV8uHO+phW4Yk0XSr7h7cV QHCuUXneXJM2lfPhQUJaX2rirABeKjd+T9JtH/+i8vdgxLenl1UpEw2LMIxpEhoUXKvP ujOg== X-Gm-Message-State: AOAM5323a9XFyHcz2nTwIf8LH16RheEW4dA94CzA9YpbU8TKsjw2jbaG Soj1xArXNvkRNvt1Ng01/pgBljHkhEEAWRr24pYlqQ== X-Google-Smtp-Source: ABdhPJyuyRw3FLQtKUbKc62d7ssmk4TlIDeHIpu4B19oSiuYnLGYs7Xv2kmUTMBqrH1YJa1+oguWhQRMTHctrF3FhI4= X-Received: by 2002:a17:906:280d:: with SMTP id r13mr15752539ejc.22.1633423670661; Tue, 05 Oct 2021 01:47:50 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dirk Steinberg Date: Tue, 5 Oct 2021 11:47:39 +0300 Message-ID: To: James Guichard Cc: SPRING WG , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a894c305cd9715d1" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 05 Oct 2021 08:48:00 -0000 --000000000000a894c305cd9715d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, I strongly support the adoption call for the CSID SRv6 compression proposal= . We have tested both SRv6 and CSID-based SRv6 compression in the lab and I definitely see a lot of value in the compressed SID list option that is provided by CSID for certain use cases. The outstanding aspect of CSID is that it seamlessly integrates into the SRv6 network programming framework [RFC 8986], thereby extending the existing SRv6 dataplane in a compatible manner without introducing a new dataplane. The proposal just introduces new endpoint flavors within the existing framework, it is just an application of RFC 8986. For this same reason I am not worried about the fact that two different endpoint flavors are described in the draft, although I would expect that eventually one variant will probably dominate real-world deployments. This would make life easier for operators, but even if that should not turn out to be the case it would still not be catastrophic. The network programming framework provides opportunity for operators to deploy the network programs which suit their needs, and this would just be an example of this freedom o= f choice and opportunity to innovate. Cheers Dirk On Fri, Oct 1, 2021 at 5:05 PM James Guichard < james.n.guichard@futurewei.com> wrote: > Dear WG: > > > > The chairs would like to express their appreciation for all the responses > received to our emails with reference to how the working group wishes to > move forward with respect to a solution for SRv6 compression. > > > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > as the basis for its compression standardization work. That is part of wh= at > this email attempts to confirm. > > > > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging > that: > > > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change = as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the working > group to publication. A list of these discussion points will be docume= nted > in the WG document and maintained by the document editor in conjunctio= n > with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text describin= g an > open issue be added to the document in the above-described open issues > section: > - "Given that the working group has said that it wants to > standardize one data plane solution, and given that the document co= ntains > multiple SRv6 EndPoint behaviors that some WG members have stated a= re > multiple data plane solutions, the working group will address wheth= er this > is valid and coherent with its one data plane solution objective.". > > > > Please consider the above guidelines as you decide on whether to support > or not this WG adoption. Please express clearly your reasoning for > support/non-support as well as any open discussion points you would like > addressed should the document be adopted into the working group. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --000000000000a894c305cd9715d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I strongly=C2=A0support the ado= ption call for the CSID SRv6 compression proposal.

We have tested both SRv6 and CSID-based SRv6 compression in the lab
<= div>and I definitely see a lot of value in the compressed SID list option t= hat
is provided by CSID for certain use cases.

The outstanding aspect of CSID is that it seamlessly integrates into= the
SRv6 network programming framework [RFC 8986], thereby exten= ding
the existing SRv6 dataplane=C2=A0in a compatible manner with= out introducing
a new dataplane. The=C2=A0proposal just introduce= s new endpoint flavors
within the existing framework, it is just = an application of RFC 8986.

For this same reason I= am not worried about the fact that two different=C2=A0
endpoint = flavors are described=C2=A0in the draft, although I would expect that
=
eventually one variant will probably dominate real-world deployments.<= /div>
This would make life easier for operators, but even if that shoul= d not turn
out to be the case it would still not be catastrophic.= The network programming
framework provides opportunity for opera= tors to deploy the network programs
which suit their needs, and t= his would just be an example of this freedom of
choice and opport= unity to innovate.

Cheers
Dirk

On F= ri, Oct 1, 2021 at 5:05 PM James Guichard <james.n.guichard@futurewei.com> wrote:

Dear WG:

=C2=A0

The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

=C2=A0

The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

=C2=A0

Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

=C2=A0

  1. The SPRING working group is adopting a document that has multiple= SRv6 Endpoint behaviors.
  2. The document is a =E2=80=9Cliving=E2=80=9D doc= ument; it may change as it goes through review and analysis by the SPRING w= orking group.
  3. All open discussion points raised on our maili= ng list MUST be addressed BEFORE said document is allowed to progress from = the working group to publication. A list of these discussion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
  4. If this document is adopted by the working gro= up, the chairs specify as part of the adoption call that the following text= describing an open issue be added to the document in the above-described open issues section:
    • "Given that the= working group has said that it wants to standardize one data plane solutio= n, and given that the document contains multiple SRv6 EndPoint behaviors th= at some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

=C2=A0

Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

=C2=A0

Thanks!

=C2=A0

Jim, Bruno & Joel

=C2=A0

=C2=A0

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--000000000000a894c305cd9715d1-- From nobody Tue Oct 5 03:11:18 2021 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 476223A09D5 for ; Tue, 5 Oct 2021 03:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 0NJnImF4vQNY for ; Tue, 5 Oct 2021 03:10:08 -0700 (PDT) Received: from mail-ua1-x92c.google.com (mail-ua1-x92c.google.com [IPv6:2607:f8b0:4864:20::92c]) (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 B82E93A09D4 for ; Tue, 5 Oct 2021 03:10:08 -0700 (PDT) Received: by mail-ua1-x92c.google.com with SMTP id i8so14445493uae.7 for ; Tue, 05 Oct 2021 03:10:08 -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=cCxNYzjqIKbNPKRZgjFFzToIg4Ju32XMmbp8xO9iPAI=; b=davOy1MdYkkgEJDJv8cDJL8V0ihTCw4QAMsxH1qIFtuAZ7XXfB2sR5AeXnIK0BYJtv Cw5NK3EW7JDU2QGZfahGdMT0DJqwph83qBkVfC0nPB7QQL7vFEDhM194cxnxMyElqrAn Hv+QtKjem9eBTC7rSVQnTz2OYIXhg85rmJvupj7D+L5MXPFVmToOHLpTBjMWp9ueg00w g//ClJ2RHDLpkpr+FSAbehvsa+r8H344q4VAQN6IyJIBiPEfxreRBsox9pljEw7tx9QR TNZeCuGEt0iW4ROxC1L0ebcxDBVtkh5CRbOjiouBNrqt1B2BrqLRmFcITgzYpMZWQ+Uv DT6w== 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=cCxNYzjqIKbNPKRZgjFFzToIg4Ju32XMmbp8xO9iPAI=; b=1lT1lzgIA7rL4ikyir0q1k1biBUIpaFrc1j6AViDvtClaPaHU9pZy64pvfN+Ms8oRc ot1UBzMG6Oj9o0v72nx8H6jA6Vsl1J0J1Gmj9vDKspNcuqfXrUmg+ddnKHlYF23eTL/0 MQwjyJweEShHq/r/+8BVaHvPfsZ4yWtAtxyuGjJIL8oXNwHPsV7ySd+YvnlsUsnjNW3P PAwn3lHyIVE2eAokF3Z4DmZw7loJXpSSdCRRKm4mgE7Yq0zDMKiFR/Rikgn7/rxAM3iW 1YTjg5ocm9wUh3KDcPF/JY5y+KzWtFX7byfQgPn2wpiIoGMeSdf28kl4RwwnPPdThBsT 4LWQ== X-Gm-Message-State: AOAM53168Ih5pzliTG7ejYdeVRbJvHZOTbOomX6UWBHoG56wiobx0P+P zWAZZdCSL4jNIZn1LACGU4wtBtrIV7Ii1TaMyckdyg== X-Google-Smtp-Source: ABdhPJxBXuABnL+MXt81cEHL1igyY3H3AyBfUpENeCdGOd0g22rmjx9TMZLyomsKkSRVzZY6sZU3YnsyLQm8rItrS9A= X-Received: by 2002:a05:6130:3a7:: with SMTP id az39mr3241627uab.8.1633428607264; Tue, 05 Oct 2021 03:10:07 -0700 (PDT) MIME-Version: 1.0 References: <6d4eff6d-6fdc-992e-3a01-13bce8b05cd0@gmail.com> In-Reply-To: From: Robert Raszuk Date: Tue, 5 Oct 2021 12:09:59 +0200 Message-ID: To: Tony Przygienda Cc: Brian E Carpenter , Ron Bonica , SPRING WG , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000e6f9e705cd983bcc" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 05 Oct 2021 10:10:16 -0000 --000000000000e6f9e705cd983bcc Content-Type: text/plain; charset="UTF-8" Tony, I am afraid you missed my point :( Any IP address can be split into routable part and non routable part (or perhaps to be more correct globally routable part and locally routable part). So I am not contradicting myself at all stating that if I got /24 or /64 from RIR and I advertise those to attract traffic and I can do whatever I want with the remaining 8 or 64 bits. Remember ISDN or better E.164 numbers ? My number is is my base number and extension - DDI or DID. If I assign DDI to fax or voice mail or phone in the kitchen has no bearing on the telephone network, rest of the number to reach me. Besides all that we are taking here about encapsulated packets anyway - so even how I make sure the prefix or locator are advertised and installed in the FIBs should be not a concern to any of my neighbors. If my encapsulated packets leak (or as some say escape) and I use legal prefix assigned by RIR as part of the DST address there are bunch of tools deployed today which should drop it right there on the other edge. Best, R. On Tue, Oct 5, 2021 at 10:38 AM Tony Przygienda wrote: > > > On Tue, Oct 5, 2021 at 9:10 AM Robert Raszuk wrote: > >> Hi Brian, >> >> Thank you - yes by legacy I meant not upgraded one - no different meaning >> intended. >> >> As far as conforming to addressing architecture sorry to say but to me >> this is red herring. Sure address must be a legal address - no question. >> But what bits in the address mean is really up to the person allocating >> them. >> > > unfortunately not. otherwise the postal service would have never worked in > the first place. The semantic concepts (and their semiotics) of > names/addresses & routes predate the internet by a couple of millenia and > did not shift much and we won't most likely shift them (and as side quip > the illusion of "flat" addresses as in MAC has proven unscalable yet again > ;-). I recommend in the context of networking the seminal 70s paper by > Schoh from Xerox. > > on top you're logically contradicting yourself in the same sentence, if > anybody can assign any semantics to an address in the same space because > "they allocate it" then no'one can judge what is legal and what isn't > > And all this here is not the case of intelligence showing by holding two > contradicting ideas in one's head, this here is simply enshrining two or > more contradicting "standards" in one standards body @ which point in time > the term "standards" quickly starts to lose its meaning in first place. > > well, I said my piece, up to IAB and so on to worry about what's happening > here really ... > > -- tony > --000000000000e6f9e705cd983bcc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tony,

I am afraid you missed my point := (=C2=A0

Any IP address can be split into routable = part and non routable part (or perhaps to be more correct globally routable= part and locally routable part).=C2=A0

So I am no= t contradicting myself at all stating that=C2=A0if I got /24 or /64 from RI= R and I advertise those to attract traffic and I can do whatever I want wit= h the remaining 8 or 64 bits.=C2=A0

Remember ISDN = or better E.164 numbers ? My number is is my base number and extension - DD= I or DID. If I assign DDI to fax or voice mail or phone in the kitchen has = no bearing on the telephone network, rest of the number to reach me.=C2=A0<= /div>

Besides all that we are taking here about encapsul= ated packets anyway - so even how I make sure the prefix or locator are adv= ertised and installed in the FIBs should be not a concern=C2=A0to any of my= neighbors. If my encapsulated packets leak (or as some say escape) and I u= se legal prefix assigned by RIR as part of the DST address there are bunch = of tools deployed today which should drop it right there on the other edge.= =C2=A0

Best,
R.


<= div class=3D"gmail_quote">
On Tue, Oct= 5, 2021 at 10:38 AM Tony Przygienda <tonysietf@gmail.com> wrote:


On Tue, Oct 5= , 2021 at 9:10 AM Robert Raszuk <robert@raszuk.net> wrote:
Hi Brian,

<= div>Thank you - yes by legacy I meant not upgraded one - no different meani= ng intended.=C2=A0

As far as conforming to address= ing architecture sorry to say but to me this is red herring. Sure address m= ust be a legal address - no question. But what bits in the address mean is = really up to the person allocating them.=C2=A0

unfortunately not. otherwise the postal service would have = never worked in the first place. The semantic concepts (and their semiotics= ) of names/addresses & routes predate the internet by a couple of mille= nia and did not shift much and we won't most likely shift them (and as = side quip the illusion of "flat" addresses as in MAC has proven u= nscalable yet again ;-). I recommend in the context of networking the semin= al 70s paper by Schoh from Xerox.

=C2=A0on to= p you're logically contradicting yourself in the same sentence, if anyb= ody can assign any semantics to an address in the same space because "= they allocate it" then no'one can judge what is legal and what isn= 't

And all this here is not the case of i= ntelligence showing by holding two contradicting ideas in one's head, t= his here is simply enshrining two or more contradicting "standards&quo= t; in one standards body @ which point in time the term "standards&quo= t; quickly starts to lose its meaning in first place.

well, I said my piece, up to IAB and so on to worry about what'= ;s happening here really ...

-- tony
--000000000000e6f9e705cd983bcc-- From nobody Tue Oct 5 04:26:52 2021 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 01F073A0763 for ; Tue, 5 Oct 2021 04:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 P5eKipYGE6ZY for ; Tue, 5 Oct 2021 04:26:44 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 C7ADA3A074D for ; Tue, 5 Oct 2021 04:26:43 -0700 (PDT) Received: from mse-fl1.zte.com.cn (unknown [10.30.14.238]) by Forcepoint Email with ESMTPS id 8EB9A7492F2346370274; Tue, 5 Oct 2021 19:26:38 +0800 (CST) Received: from kjyxapp01.zte.com.cn ([10.30.12.200]) by mse-fl1.zte.com.cn with SMTP id 195BQY0M087799; Tue, 5 Oct 2021 19:26:34 +0800 (GMT-8) (envelope-from liu.aihua@zte.com.cn) Received: from mapi (kjyxapp06[null]) by mapi (Zmail) with MAPI id mid13; Tue, 5 Oct 2021 19:26:34 +0800 (CST) Date: Tue, 5 Oct 2021 19:26:34 +0800 (CST) X-Zmail-TransId: 2b08615c366ae7acacfc X-Mailer: Zmail v1.0 Message-ID: <202110051926344703051@zte.com.cn> In-Reply-To: References: BL0PR05MB5316659C505F9BFBE915D59BAEAB9@BL0PR05MB5316.namprd05.prod.outlook.com, CAOj+MMG2hRhCvZd8ifTM=sSgkdW+09oK+ORMqQ47dJ-0QwnaxA@mail.gmail.com, BL0PR05MB531627B8F2F345E073EDF5D4AEAB9@BL0PR05MB5316.namprd05.prod.outlook.com, CAOj+MMGWEwEdhqi1wEJj2hu3FKLdVKA=xt0XxNvsPw-Z5-p3ww@mail.gmail.com, 5449C581-4F7F-4C49-BE77-072802E4FF05@juniper.net, 202110030903029947713@zte.com.cn, BL0PR05MB531657D410BFABF2264ABE1AAEAE9@BL0PR05MB5316.namprd05.prod.outlook.com Mime-Version: 1.0 From: To: Cc: , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl1.zte.com.cn 195BQY0M087799 Archived-At: Subject: Re: [spring] =?utf-8?q?CSID_Question?= 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, 05 Oct 2021 11:26:50 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgUm9u77yMDQoNCg0KRm9yIHlvdXIgcXVlc3Rpb25zLCBmcm9tIG15IHBvaW50IG9mIHZpZXcs IG1pZ2h0IGJlIGEgbGl0dGxlIGRldmlhdGlvbiB3aXRoIHB1cnBvc2Ugb2YgdGhlIEMtU0lEIHNv bHV0aW9uLiBBcyBJIHVuZGVyc3RhbmQsIHRoZSBTUnY2IGhlYWRlciBjb21wcmVzc2lvbiBkZXBl bmRzIG9uIHRoZSByZWR1bmRlbmNpZXMgb2YgU0lEIGluZm9ybWF0aW9uLCBhbmQgdGhlIEMtU0lE IHNvbHV0aW9uIHByb3ZpZGVzIDIgZmxhdm9ycyBmb3IgY29tcHJlc3Npb24sIGhvdyB0byB1c2Ug dGhlbSBhbHNvIGRlcGVuZGluZyBvbiB0aGUgU1J2NiBzZWxmLCBzdWNoIGFzIFNJRCBmb3JtYXQs IGp1c3QgbGlrZSBvdGhlcnMgZmxhdm9ycyBvZiBTUnY2IHByb2dyYW1taW5nLg0KDQoNCkJ1dCBJ IGFncmVlIHRoZSBXRyBtaWdodCBmaW5kIG91dCBhIGJldHRlciBvbmUgYmFzZWQgb24gdGhlIEMt U0lEIGRyYWZ0LCBJIHRoaW5rIGl0IGlzIGEgZ29vZCBzdGFydCB0byBhZG9wdCB0aGUgQy1TSUQg ZHJhZnQuDQoNCg0KDQoNCg0KDQpCZXN0IHJlZ2FyZHMsDQoNCg0KQWlodWENCg0KDQoNCg0KDQoN Cg0K5Y6f5aeL6YKu5Lu2DQoNCg0KDQrlj5Hku7bkurrvvJpSb25Cb25pY2ENCuaUtuS7tuS6uu+8 muWImOeIseWNjjEwMDI0OTk5Ow0K5oqE6YCB5Lq677yacm9iZXJ0QHJhc3p1ay5uZXQ7c3ByaW5n QGlldGYub3JnOw0K5pelIOacnyDvvJoyMDIx5bm0MTDmnIgwNOaXpSAyMzoxOA0K5Li7IOmimCDv vJpSRTogUmU6W3NwcmluZ10gQ1NJRCBRdWVzdGlvbg0KDQoNCg0KDQpBaWh1YSwNCg0KDQogDQoN Cg0KSSBkb27igJl0IHJlY2FsbCB0aGlzIGJlaW5nIGRpc2N1c3NlZCBpbiB0aGUgZGVzaWduIHRl YW0sIGJ1dCBteSBtZW1vcnkgbWF5IGJlIGZhaWxpbmcgbWUuIFRoZSBkZXNpZ24gdGVhbSBrZXB0 IG1ldGljdWxvdXMgbWludXRlcyAoIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9i cm93c2Uvc3Jjb21wLyApIGFuZCBpdCB3b3VsZCBiZSB2ZXJ5IGhlbHBmdWwgb2YgeW91IGNvdWxk IHBvaW50IG1lIHRoZSBtZWV0aW5nIHdoZXJlIHRoaXMgd2FzIGRpc2N1c3NlZC4NCg0KDQogDQoN Cg0KSSBhZ3JlZSB0aGF0IGl0IHdvdWxkIGJlIGRpZmZpY3VsdCB0byBmaW5kIGEgdXNlLWNhc2Ug d2hlcmUgYm90aCBHLVNJRCBhbmQgdVNJRCBhcmUgYm90aCByZXF1aXJlZC4gSG93ZXZlciwgSSBh c2sgdGhlIHF1ZXN0aW9uIGZvciB0aGUgZm9sbG93aW5nIHJlYXNvbnM6DQoNCg0KIA0KDQpUbyBk ZXRlcm1pbmUgd2hldGhlciBHLVNJRCBhbmQgdVNJRCBhcmUgZGlmZmVyZW50IGJlaGF2aW9ycy4g SWYgdGhleSBkb27igJl0IHdvcmsgd2VsbCB0b2dldGhlciBpbiBhIHNpbmdsZSBkb21haW4sIGl0 IHdvdWxkIGJlIGRpZmZpY3VsdCB0byBhcmd1ZSB0aGF0IHRoZXkgYXJlIGEgc2luZ2xlIGJlaGF2 aW9yDQoNClRvIGRldGVybWluZSB3aGV0aGVyIHRoZXkgYXJlIGJvdGggbmVlZGVkLg0KDQpUbyBk ZXRlcm1pbmUgd2hldGhlciB0aGUgQy1TSUQgZW5jYXBzdWxhdGlvbiBvdmVyaGVhZCByZWR1Y3Rp b24gc3RhdGlzdGljcyByZXBvcnRlZCBpbiB0aGUgYW5hbHlzaXMgZG9jdW1lbnQgcmVmbGVjdCB1 U0lEIG9ubHksIEctU0lEIG9ubHksIG9yIGEgY29tYmluYXRpb24gb2YgYm90aA0KDQoNCiANCg0K DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbg0KDQoNCiANCg0KDQogDQoNCg0K IA0KDQoNCkp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkNCg0KDQoNCkZyb206IGxpdS5haWh1YUB6 dGUuY29tLmNuIDxsaXUuYWlodWFAenRlLmNvbS5jbj4gDQogU2VudDogU2F0dXJkYXksIE9jdG9i ZXIgMiwgMjAyMSA5OjAzIFBNDQogVG86IFJvbiBCb25pY2EgPHJib25pY2FAanVuaXBlci5uZXQ+ DQogQ2M6IHJvYmVydEByYXN6dWsubmV0OyBzcHJpbmdAaWV0Zi5vcmcNCiBTdWJqZWN0OiBSZTpb c3ByaW5nXSBDU0lEIFF1ZXN0aW9uDQoNCg0KDQoNCiANCg0KDQpbRXh0ZXJuYWwgRW1haWwuIEJl IGNhdXRpb3VzIG9mIGNvbnRlbnRdDQoNCg0KIA0KDQogDQoNCkhpIFJvbiwNCg0KWW91IHJhaXNl ZCBhbiBpbnRlcmVzdGluZyBxdWVzdGlvbiwgYnV0IEkgdGhpbmsgaXQgbWlnaHQgYmUgYWxyZWFk eSBkaXNjdXNzZWQgaW4gdGhlIERULiBJbiBteSB1bmRlcnN0YW5kaW5nLCB0aGlzIHF1ZXN0aW9u IGlzIGp1c3QgbW9yZSByZWxhdGVkIHRoZSB1c2VjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGJ1dCB0 aGUgc29sdXRpb25zLiBJbiBhIFNSdjYgZG9tYWluLCB0aGUgaGVhZGVyIGNvbXByZXNzaW9uIGVm ZmVjdGlvbiBkZXBlbmRzIG9uIHRoZSBTSUQgaW5mb3JtYWlvbiByZWR1bmRlbmNpZXMgZHVlIHRv IHRoZSByZWFzb25hYmxlIFNJRCBwbGFubmluZyB3aXRoIHRoZSBTUnY2IGNvbXBhdGlibGUgc29s dXRpb24uIEkgdGhpbmsgaXQncyBtZWFubGVzcyB0byBjb21wcmVzcyB0aGUgU1J2NiBoZWFkZXIg aW4gdGhlIGNhc2Ugb2YgcmFuZG9tIFNJRCBmb3JtYXQuIEJlc2lkZXMgb3RoZXIgc29sdXRpb24g d2l0aG91dCBlbmdvdXRoIFNSdjYgY29tcGF0aWJsZSBzdWNoIGFzIFVuaWZpZWQgU0lEIGNvdWxk IGJlIHVzZWQgdG8gcmVzb2x2ZSB0aGUgdXNlY2FzZSB5b3UgbWVudGlvbmVkLiBJIGJlbGlldmUg dGhhdCBoYWQgYmVlbiBkaXNjdXNzZWQgYW5kIGNvbXBhcmVkIHdpdGhpbiB0aGUgRFQgYW5kIHRo ZSBvbmUgc29sdXRpb24gY29tcGF0aWJsZSB3aXRoIFNSdjYgaXMgcHJlZmVycmVkLCB0aGF0IGlz IHRoZSBDU0lEIGRyYWZ0Lg0KDQogDQoNCkJlc3QgUmVnYXJkcywNCg0KQWlodWENCg0KIA0KDQoN CuWOn+Wni+mCruS7tg0KDQoNCg0K5Y+R5Lu25Lq677yaUm9uQm9uaWNhDQoNCg0KDQrmlLbku7bk urrvvJpSb2JlcnQgUmFzenVrOw0KDQoNCg0K5oqE6YCB5Lq677yaU1BSSU5HIFdHOw0KDQoNCg0K 5pelIOacnyDvvJoyMDIx5bm0MTDmnIgwMuaXpSAyMTozOQ0KDQoNCg0K5Li7IOmimCDvvJpSZTog W3NwcmluZ10gQ1NJRCBRdWVzdGlvbg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KIHNwcmluZyBtYWlsaW5nIGxpc3QNCiBzcHJpbmdAaWV0 Zi5vcmcNCiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KIA0K IEZvbGtzLA0KDQoNCk5vdyB0aGF0IFJvYmVydCBhbmQgSSBoYXZlIHByb3ZpZGVkIHNvbWUgZW50 ZXJ0YWlubWVudCwgY291bGQgc29tZW9uZSBhbnN3ZXIgdGhlIHRlY2huaWNhbCBxdWVzdGlvbiB0 aGF0IGluaXRpYXRlZCB0aGlzIHRocmVhZD8NCg0KDQoNCiANCg0KDQpEb2VzIHRoZSBkb2N1bWVu dCByZWNvbW1lbmQgYWdhaW5zdCB1c2luZyBOZXh0LUMtU0lkIGFuZCBSZXBsYWNlLUMtU2lkIGlu IHRoZSBzYW1lIGRvbWFpbiAgZm9yIGVhc2Ugb2Ygb3BlcmF0aW9uIG9yIGJlY2F1c2UgdGhleSBk b27igJl0IHdvcmsgd2VsbCB0b2dldGhlcj8gSWYgdGhlIGZvcm1lciwgcGxlYXNlIHByb3ZpZGUg dGhlIGV4YW1wbGUgZGVzY3JpYmVkIGJlbG93Lg0KDQoNCg0KIA0KDQoNCiAgICAgICAgICAgICAg Um9uDQoNCg0KDQogDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClNl bnQgZnJvbSBteSBpUGhvbmUNCg0KDQoNCiANCg0KDQpPbiBPY3QgMSwgMjAyMSwgYXQgNTowNyBQ TSwgUm9iZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ+IHdyb3RlOg0KDQoNCg0K77u/DQoN CiANCg0KDQpbRXh0ZXJuYWwgRW1haWwuIEJlIGNhdXRpb3VzIG9mIGNvbnRlbnRdDQoNCg0KIA0K DQogDQoNCg0KSGkgUm9uLA0KDQoNCg0KIA0KDQpDYW4gd2Ugc2F5IHRoYXQgdGhleSBhcmUgYSBz aW5nbGUgYmVoYXZpb3IgPw0KDQoNCiANCg0KDQpOby4gQW5kIG5laXRoZXIgUkZDODk4NiBkZWZp bmVzIGEgc2luZ2xlIGJlaGF2aW9yIG9yIHNpbmdsZSBmbGF2b3IuIFlldCB0aGUgYm91bmRzIGFy ZSBjbGVhcmx5IHNldCB3aGF0IGlzIHRoZSBTUnY2IGRhdGEgcGxhbmUuIA0KDQoNCg0KDQoNCiAN Cg0KDQpGb3Igc29tZSBzdHJhbmdlIHJlYXNvbiBJIGFtIG9ic2VydmluZyBoZXJlIGFuIGF0dGVt cHQgdG8gc3F1ZWV6ZSBkaWZmZXJlbnQgZGF0YSBwbGFuZSBpbnRvIHRoZSByb29tIHdoaWNoIGlz IG5vdCBjb21wbGlhbnQgdG8gW1JGQzg0MDJdLCBbUkZDODc1NF0gYW5kIFtSRkM4OTg2XS4gRG8g eW91IHRoaW5rIGFueW9uZSB3aWxsIGJlIHNvIG5haXZlIHRvIGFjY2VwdCBpdCA/IA0KDQoNCg0K IA0KDQoNCk5vdyBJIGFtIGdvaW5nIHRvIHJlc3QgYXNzdXJlZCBhbmQgZW5qb3kgdGhlIHJlc3Qg b2YgdGhpcyBzaG93LiANCg0KDQoNCiANCg0KDQpCZXN0LA0KDQoNCg0KUm9iZXJ0DQoNCg0KDQog DQoNCg0KDQogDQoNCg0KT24gRnJpLCBPY3QgMSwgMjAyMSBhdCAxMDo1OCBQTSBSb24gQm9uaWNh IDxyYm9uaWNhQGp1bmlwZXIubmV0PiB3cm90ZToNCg0KDQoNClJvYmVydCwNCg0KDQogDQoNCg0K SSBkbyByZW1lbWJlciB0aGF0IHF1b3RlLiBBbmQgdGhhdCBpcyBleGFjdGx5IHdoeSBJIGFzayB0 aGUgcXVlc3Rpb24hDQoNCg0KIA0KDQoNCklmIE5FWFQtQy1TSUQgYW5kIFJFUExBQ0UtQy1TSUQg YXJlIGluY29tcGF0aWJsZSB3aXRoaW4gYSBkb21haW46DQoNCg0KIA0KDQpDYW4gd2Ugc2F5IHRo YXQgdGhleSBhcmUgYSBzaW5nbGUgYmVoYXZpb3IgPw0KDQpDYW4gd2UganVzdGlmeSBib3RoIGJl Y2F1c2UgZWFjaCBpcyBvcHRpbWl6ZWQgZm9yIGEgZGlmZmVyZW50IGtpbmQgb2YgbmV0d29yaz8N Cg0KQ2FuIHdlIGp1c3RpZnkgYW5vdGhlciBiZWhhdmlvciBlaXRoZXIgYmVjYXVzZSBpdCBpcyBv cHRpbWl6ZWQgZm9yIHlldCBhbm90aGVyIHR5cGUgb2YgbmV0d29yayBvciBiZWNhdXNlIGl0IGRv ZXMgcmVsYXRpdmVseSB3ZWxsIGluIGFsbCBuZXR3b3JrIHR5cGVzPw0KDQoNCiANCg0KDQpIb3dl dmVyLCBpZiB0aGlzIGlzIGp1c3QgYW4g4oCcZWFzZSBvZiBvcGVyYXRpb27igJ0gdGhpbmcsIGFz IHN0YXRlZCBpbiB0aGUgZHJhZnQsIHRoZSBhdXRob3JzIGFyZSBvYmxpZ2VkIHRvIGFuc3dlciBt eSBxdWVzdGlvbi4NCg0KDQogDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFJvbg0KDQoNCiANCg0KDQpQLlMuIFJlc3QgYXNzdXJlZCB0aGF0IEkgaGF2ZSByZWFk IHRoZSBkcmFmdC4gSG93ZXZlciwgeW91ciBjb25jZXJuIGlzIGdyZWF0bHkgYXBwcmVjaWF0ZWQg 8J+YiQ0KDQoNCiANCg0KDQogDQoNCg0KIA0KDQoNCkp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkN Cg0KDQoNCkZyb206IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PiANCiBTZW50OiBG cmlkYXksIE9jdG9iZXIgMSwgMjAyMSA0OjMyIFBNDQogVG86IFJvbiBCb25pY2EgPHJib25pY2FA anVuaXBlci5uZXQ+DQogQ2M6IFNQUklORyBXRyA8c3ByaW5nQGlldGYub3JnPg0KIFN1YmplY3Q6 IFJlOiBbc3ByaW5nXSBDU0lEIFF1ZXN0aW9uDQoNCg0KDQoNCiANCg0KDQpbRXh0ZXJuYWwgRW1h aWwuIEJlIGNhdXRpb3VzIG9mIGNvbnRlbnRdDQoNCg0KIA0KDQoNCkhpIFJvbiwNCg0KDQogDQoN Cg0KSGF2ZSB5b3UgcmVhZCB0aGlzIGRyYWZ0ID8gDQoNCg0KDQogDQoNCg0KUXVvdGUgZnJvbSBp dDogDQoNCg0KDQogDQoNCg0KICAgSXQgaXMgcmVjb21tZW5kZWQgZm9yIGVhc2Ugb2Ygb3BlcmF0 aW9uIHRoYXQgYSBzaW5nbGUgY29tcHJlc3NlZCAgICBlbmNvZGluZyBmbGF2b3IgYmUgdXNlZCBp biBhIGdpdmVuIFNSdjYgZG9tYWluLiAgSG93ZXZlciwgaW4gYSBtdWx0aS0gICAgZG9tYWluIGRl cGxveW1lbnQsIGRpZmZlcmVudCBmbGF2b3JzIGNhbiBiZSB1c2VkIGluIGRpZmZlcmVudCAgICBk b21haW5zLiANCg0KDQoNCiANCg0KDQpPbiBGcmksIE9jdCAxLCAyMDIxIGF0IDk6MzMgUE0gUm9u IEJvbmljYSA8cmJvbmljYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPiB3cm90ZToNCg0K DQoNCkNTSUQgQXV0aG9ycywNCg0KDQogDQoNCg0KQXNzdW1lIHRoYXQgYW4gU1IgcGF0aCBjb250 YWlucyBzZWdtZW50cyAxIHRocm91Z2ggOC4gU2VnbWVudHMgMSwgMywgNSwgYW5kIDcgYXJlIEVO RCBTSURzIHRoYXQgdXNlIE5leHQtQy1TSUQgKGkuZS4sIHVTSUQpLiBTZWdtZW50cyAyLCA0LCBh bmQgNiBhcmUgRU5EIFNJRHMgdGhhdCB1c2UgUmVwbGFjZS1DLVNJRC4gU2VnbWVudCA4IGlzIGFu ZCBFTkQuRFg0IFNJRC4NCg0KDQogDQoNCg0KUGxlYXNlIHByb3ZpZGUgYW4gZXhhbXBsZSB0aGF0 IHNob3dzIHVzOg0KDQoNCiANCg0KV2hhdCB0aGUgU1JIIGxvb2tzIGxpa2UgYXMgaXQgYXJyaXZl cyBhdCB0aGUgZmlyc3Qgc2VnbWVudCBlbmRwb2ludA0KDQpXaGF0IHRoZSBJUHY2IERlc3RpbmF0 aW9uIEFkZHJlc3MgbG9va3MgbGlrZSBhdCBlYWNoIHNlZ21lbnQgZW5kcG9pbnQsIGluY2x1ZGlu ZyBpbmZvcm1hdGlvbiByZXF1aXJlZCB0byBwYXJzZSB0aGUgRGVzdGluYXRpb24gQWRkcmVzcw0K DQoNCiANCg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgUm9uDQoNCg0KIA0KDQoNCiANCg0KDQpKdW5pcGVyIEJ1c2luZXNzIFVzZSBP bmx5DQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQogc3ByaW5nIG1haWxpbmcgbGlzdA0KIHNwcmluZ0BpZXRmLm9yZw0KIGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5n --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MTZweDtmb250LWZh bWlseTrlvq7ova/pm4Xpu5EsTWljcm9zb2Z0IFlhSGVpOyI+PGJyPjwvcD48cCBzdHlsZT0iZm9u dC1zaXplOjE2cHg7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buRLE1pY3Jvc29mdCBZYUhlaTsiPkhp IFJvbu+8jDwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE2cHg7Zm9udC1mYW1pbHk65b6u6L2v6ZuF 6buRLE1pY3Jvc29mdCBZYUhlaTsiPkZvciB5b3VyIHF1ZXN0aW9ucywgZnJvbSBteSBwb2ludCBv ZiB2aWV3LCBtaWdodCBiZSBhIGxpdHRsZSBkZXZpYXRpb24gd2l0aCBwdXJwb3NlIG9mIHRoZSBD LVNJRCBzb2x1dGlvbi4gQXMgSSB1bmRlcnN0YW5kLCB0aGUgU1J2NiBoZWFkZXIgY29tcHJlc3Np b24gZGVwZW5kcyBvbiB0aGUgcmVkdW5kZW5jaWVzIG9mIFNJRCBpbmZvcm1hdGlvbiwgYW5kIHRo ZSBDLVNJRCBzb2x1dGlvbiBwcm92aWRlcyAyIGZsYXZvcnMgZm9yIGNvbXByZXNzaW9uLCBob3cg dG8gdXNlIHRoZW0gYWxzbyBkZXBlbmRpbmcgb24gdGhlIFNSdjYgc2VsZiwgc3VjaCBhcyBTSUQg Zm9ybWF0LCBqdXN0IGxpa2Ugb3RoZXJzIGZsYXZvcnMgb2YgU1J2NiBwcm9ncmFtbWluZy48L3A+ PHAgc3R5bGU9ImZvbnQtc2l6ZToxNnB4O2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kSxNaWNyb3Nv ZnQgWWFIZWk7Ij5CdXQgSSBhZ3JlZSB0aGUgV0cgbWlnaHQgZmluZCBvdXQgYSBiZXR0ZXIgb25l IGJhc2VkIG9uIHRoZSBDLVNJRCBkcmFmdCwgSSB0aGluayBpdCBpcyBhIGdvb2Qgc3RhcnQgdG8g YWRvcHQgdGhlIEMtU0lEIGRyYWZ0LjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE2cHg7Zm9udC1m YW1pbHk65b6u6L2v6ZuF6buRLE1pY3Jvc29mdCBZYUhlaTsiPjxicj48L3A+PHAgc3R5bGU9ImZv bnQtc2l6ZToxNnB4O2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kSxNaWNyb3NvZnQgWWFIZWk7Ij5C ZXN0IHJlZ2FyZHMsPC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTZweDtmb250LWZhbWlseTrlvq7o va/pm4Xpu5EsTWljcm9zb2Z0IFlhSGVpOyI+QWlodWE8L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZTox NnB4O2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kSxNaWNyb3NvZnQgWWFIZWk7Ij48YnI+PC9wPjxk aXY+PGRpdiBjbGFzcz0iemhpc3RvcnlSb3ciIHN0eWxlPSJkaXNwbGF5OmJsb2NrIj48ZGl2IGNs YXNzPSJ6aGlzdG9yeURlcyIgc3R5bGU9IndpZHRoOiAxMDAlOyBoZWlnaHQ6IDI4cHg7IGxpbmUt aGVpZ2h0OiAyOHB4OyBiYWNrZ3JvdW5kLWNvbG9yOiAjRTBFNUU5OyBjb2xvcjogIzEzODhGRjsg dGV4dC1hbGlnbjogY2VudGVyOyIgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeU9yZ1R4dCI+5Y6f5aeL 6YKu5Lu2PC9kaXY+PGRpdiBpZD0iendyaXRlSGlzdG9yeUNvbnRhaW5lciI+PGRpdiBjbGFzcz0i Y29udHJvbC1ncm91cCB6aGlzdG9yeVBhbmVsIj48ZGl2IGNsYXNzPSJ6aGlzdG9yeUhlYWRlciIg c3R5bGU9InBhZGRpbmc6IDhweDsgYmFja2dyb3VuZC1jb2xvcjogI0Y1RjZGODsiPjxkaXY+PHN0 cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5U2VuZGVyVHh0Ij7lj5Hku7bkurrvvJo8L3N0cm9u Zz48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSI+Um9uQm9uaWNhPHJib25pY2FAanVuaXBlci5u ZXQ+PC9yYm9uaWNhQGp1bmlwZXIubmV0Pjwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3Vh Z2UtZGF0YT0iSGlzdG9yeVRPVHh0Ij7mlLbku7bkurrvvJo8L3N0cm9uZz48c3BhbiBjbGFzcz0i enJlYWRVc2VyTmFtZSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZTsiPuWImOeIseWNjjEwMDI0OTk5 Ozwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeUNDVHh0Ij7m ioTpgIHkurrvvJo8L3N0cm9uZz48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9ImRp c3BsYXk6IGlubGluZTsiPnJvYmVydEByYXN6dWsubmV0PHJvYmVydEByYXN6dWsubmV0Pjs8L3Jv YmVydEByYXN6dWsubmV0Pjwvc3Bhbj48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9 ImRpc3BsYXk6IGlubGluZTsiPnNwcmluZ0BpZXRmLm9yZzxzcHJpbmdAaWV0Zi5vcmc+Ozwvc3By aW5nQGlldGYub3JnPjwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlz dG9yeURhdGVUeHQiPuaXpSDmnJ8g77yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9IiI+MjAyMeW5tDEw 5pyIMDTml6UgMjM6MTg8L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhp c3RvcnlTdWJqZWN0VHh0Ij7kuLsg6aKYIO+8mjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJ6cmVhZFRp dGxlIj48c3Ryb25nPlJFOiBSZTpbc3ByaW5nXSBDU0lEIFF1ZXN0aW9uPC9zdHJvbmc+PC9zcGFu PjwvZGl2PjwvZGl2PjxkaXYgY2xhc3M9InpoaXN0b3J5Q29udGVudCI+PGRpdj48bWV0YSBodHRw LWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+ PG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVy ZWQgbWVkaXVtKSI+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+PG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgPjwvbzpzaGFwZWRlZmF1bHRzPjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij48 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgPjwvbzppZG1hcD48L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj48cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+QWlodWEsPG86cD48L286cD48 L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPkkgZG9u4oCZdCByZWNhbGwgdGhpcyBiZWluZyBk aXNjdXNzZWQgaW4gdGhlIGRlc2lnbiB0ZWFtLCBidXQgbXkgbWVtb3J5IG1heSBiZSBmYWlsaW5n IG1lLiBUaGUgZGVzaWduIHRlYW0ga2VwdCBtZXRpY3Vsb3VzIG1pbnV0ZXMgKCA8YSBocmVmPSJo dHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJvd3NlL3NyY29tcC8iIHRhcmdldD0i X2JsYW5rIj5odHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvYnJvd3NlL3NyY29tcC88 L2E+ICkgYW5kIGl0IHdvdWxkIGJlIHZlcnkgaGVscGZ1bCBvZiB5b3UgY291bGQgcG9pbnQgbWUg dGhlIG1lZXRpbmcgd2hlcmUgdGhpcyB3YXMgZGlzY3Vzc2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTQuMHB0Ij5JIGFncmVlIHRoYXQgaXQgd291bGQgYmUgZGlmZmljdWx0IHRv IGZpbmQgYSB1c2UtY2FzZSB3aGVyZSBib3RoIEctU0lEIGFuZCB1U0lEIGFyZSBib3RoIHJlcXVp cmVkLiBIb3dldmVyLCBJIGFzayB0aGUgcXVlc3Rpb24gZm9yIHRoZSBmb2xsb3dpbmcgcmVhc29u czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxNC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48dWwgc3R5bGU9 Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIiBjbGFzcz0iIGxpc3QtcGFkZGluZ2xlZnQtMiI+ PGxpPjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij5UbyBkZXRlcm1pbmUgd2hldGhl ciBHLVNJRCBhbmQgdVNJRCBhcmUgZGlmZmVyZW50IGJlaGF2aW9ycy4gSWYgdGhleSBkb27igJl0 IHdvcmsgd2VsbCB0b2dldGhlciBpbiBhIHNpbmdsZSBkb21haW4sIGl0IHdvdWxkIGJlIGRpZmZp Y3VsdCB0byBhcmd1ZSB0aGF0ICB0aGV5IGFyZSBhIHNpbmdsZSBiZWhhdmlvcjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD48L2xpPjxsaT48cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+VG8g ZGV0ZXJtaW5lIHdoZXRoZXIgdGhleSBhcmUgYm90aCBuZWVkZWQuPG86cD48L286cD48L3NwYW4+ PC9wPjwvbGk+PGxpPjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij5UbyBkZXRlcm1p bmUgd2hldGhlciB0aGUgQy1TSUQgZW5jYXBzdWxhdGlvbiBvdmVyaGVhZCByZWR1Y3Rpb24gc3Rh dGlzdGljcyByZXBvcnRlZCBpbiB0aGUgYW5hbHlzaXMgZG9jdW1lbnQgcmVmbGVjdCB1U0lEIG9u bHksIEctU0lEIG9ubHksIG9yIGEgY29tYmluYXRpb24gIG9mIGJvdGg8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PC9saT48L3VsPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTQuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSb248bzpw PjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxNC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxwIGNsYXNz PSJtc2lwZm9vdGVyMzBiM2Q1MzgiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjttYXJnaW46MGlu OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+SnVuaXBlciBCdXNp bmVzcyBVc2UgT25seTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Ryb25nPkZyb206PC9zdHJvbmc+IGxpdS5h aWh1YUB6dGUuY29tLmNuICZsdDtsaXUuYWlodWFAenRlLmNvbS5jbiZndDsgPGJyPiA8c3Ryb25n PlNlbnQ6PC9zdHJvbmc+IFNhdHVyZGF5LCBPY3RvYmVyIDIsIDIwMjEgOTowMyBQTTxicj4gPHN0 cm9uZz5Ubzo8L3N0cm9uZz4gUm9uIEJvbmljYSAmbHQ7cmJvbmljYUBqdW5pcGVyLm5ldCZndDs8 YnI+IDxzdHJvbmc+Q2M6PC9zdHJvbmc+IHJvYmVydEByYXN6dWsubmV0OyBzcHJpbmdAaWV0Zi5v cmc8YnI+IDxzdHJvbmc+U3ViamVjdDo8L3N0cm9uZz4gUmU6W3NwcmluZ10gQ1NJRCBRdWVzdGlv bjxvOnA+PC9vOnA+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJsaW5lLWhlaWdodDoxMi4w cHQ7YmFja2dyb3VuZDojRkZFQjlDIj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0xhdG8mcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ W0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XTxvOnA+PC9vOnA+PC9zcGFu Pjwvc3Ryb25nPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD48 ZGl2PjxkaXY+PHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD48cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZiI+SGkgUm9uLDxvOnA+PC9vOnA+PC9z cGFuPjwvcD48cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZiI+WW91IHJhaXNlZCBhbiBpbnRlcmVz dGluZyBxdWVzdGlvbiwgYnV0IEkgdGhpbmsgaXQgbWlnaHQgYmUgYWxyZWFkeSBkaXNjdXNzZWQg aW4gdGhlIERULiBJbiBteSB1bmRlcnN0YW5kaW5nLCB0aGlzIHF1ZXN0aW9uIGlzIGp1c3QgbW9y ZSByZWxhdGVkIHRoZSB1c2VjYXNlcyBhbmQgcmVxdWlyZW1lbnRzIGJ1dCB0aGUgIHNvbHV0aW9u cy4gSW4gYSBTUnY2IGRvbWFpbiwgdGhlIGhlYWRlciBjb21wcmVzc2lvbiBlZmZlY3Rpb24gZGVw ZW5kcyBvbiB0aGUgU0lEIGluZm9ybWFpb24gcmVkdW5kZW5jaWVzIGR1ZSB0byB0aGUgcmVhc29u YWJsZSBTSUQgcGxhbm5pbmcgd2l0aCB0aGUgU1J2NiBjb21wYXRpYmxlIHNvbHV0aW9uLiBJIHRo aW5rIGl0J3MgbWVhbmxlc3MgdG8gY29tcHJlc3MgdGhlIFNSdjYgaGVhZGVyIGluIHRoZSBjYXNl IG9mIHJhbmRvbSBTSUQgZm9ybWF0LiAgQmVzaWRlcyBvdGhlciBzb2x1dGlvbiB3aXRob3V0IGVu Z291dGggU1J2NiBjb21wYXRpYmxlIHN1Y2ggYXMgVW5pZmllZCBTSUQgY291bGQgYmUgdXNlZCB0 byByZXNvbHZlIHRoZSB1c2VjYXNlIHlvdSBtZW50aW9uZWQuJm5ic3A7SSBiZWxpZXZlIHRoYXQg aGFkIGJlZW4gZGlzY3Vzc2VkIGFuZCBjb21wYXJlZCB3aXRoaW4gdGhlIERUIGFuZCB0aGUgb25l IHNvbHV0aW9uIGNvbXBhdGlibGUgd2l0aCBTUnY2IGlzIHByZWZlcnJlZCwgdGhhdCBpcyB0aGUg IENTSUQgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9wPjxwPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2Vy aWYiPkJlc3QgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHA+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNh bnMtc2VyaWYiPkFpaHVhPG86cD48L286cD48L3NwYW4+PC9wPjxwPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2PjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRlcjtsaW5lLWhlaWdodDoyMS4wcHQ7YmFj a2dyb3VuZDojRTBFNUU5Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGlj JnF1b3Q7O2NvbG9yOiMxMzg4RkYiPuWOn+Wnizwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7TWljcm9zb2Z0IEpoZW5nSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzEzODhG RiI+6YKu5Lu2PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjojMTM4OEZGIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PGRpdiBpZD0iendyaXRlSGlzdG9yeUNvbnRhaW5lciI+PGRpdj48ZGl2PjxkaXY+ PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0Y1RjZGOCI+PHN0cm9uZz48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IEpoZW5nSGVpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPuWPkeS7tuS6uu+8mjwvc3Bhbj48L3N0cm9uZz48c3BhbiBj bGFzcz0ienJlYWR1c2VybmFtZSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Sb25Cb25pY2E8 L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImJhY2tncm91bmQ6I0Y1RjZGOCI+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOmJsYWNrIj7mlLbku7bkurrvvJo8L3Nw YW4+PC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkdXNlcm5hbWUiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Um9iZXJ0IFJhc3p1azs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2 PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0Y1RjZGOCI+PHN0 cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9y OmJsYWNrIj7mioTpgIHkurrvvJo8L3NwYW4+PC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkdXNl cm5hbWUiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+U1BSSU5HIFdHOzwvc3Bhbj48L3NwYW4+ PG86cD48L286cD48L3A+PC9kaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFj a2dyb3VuZDojRjVGNkY4Ij48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtN UyBHb3RoaWMmcXVvdDs7Y29sb3I6YmxhY2siPuaXpTwvc3Bhbj48L3N0cm9uZz48c3Ryb25nPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPiA8L3NwYW4+PC9zdHJvbmc+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOmJsYWNrIj7mnJ88L3NwYW4+PC9zdHJvbmc+ PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj4gPC9zcGFuPjwvc3Ryb25nPjxzdHJvbmc+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjpibGFjayI+77yaPC9zcGFu Pjwvc3Ryb25nPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+MjAyMTwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOmJsYWNrIj7lubQ8L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4xMDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOmJsYWNrIj7mnIg8L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4wMjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOmJsYWNrIj7ml6U8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4gIDIxOjM5PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxkaXY+PHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91bmQ6I0Y1RjZGOCI+PHN0cm9uZz48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O2NvbG9yOmJsYWNrIj7kuLs8 L3NwYW4+PC9zdHJvbmc+PHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4gPC9zcGFuPjwvc3Ryb25nPjxzdHJv bmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBKaGVuZ0hlaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj7popg8L3NwYW4+PC9zdHJvbmc+PHN0cm9uZz48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OmJsYWNrIj4gPC9zcGFuPjwvc3Ryb25nPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O01TIEdvdGhpYyZxdW90Oztjb2xvcjpibGFjayI+77yaPC9zcGFuPjwvc3Ryb25nPjxz dHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+UmU6IFtzcHJpbmddIENTSUQgUXVlc3Rpb248L3NwYW4+PC9zdHJv bmc+PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3Jt YWwiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPiBz cHJpbmcmbmJzcDttYWlsaW5nJm5ic3A7bGlzdDxicj4gPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+IDxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nIiB0YXJnZXQ9Il9i bGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8L2E+PGJy PiA8YnI+IEZvbGtzLDxvOnA+PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm93 IHRoYXQgUm9iZXJ0IGFuZCBJIGhhdmUgcHJvdmlkZWQgc29tZSBlbnRlcnRhaW5tZW50LCBjb3Vs ZCBzb21lb25lIGFuc3dlciB0aGUgdGVjaG5pY2FsIHF1ZXN0aW9uIHRoYXQgaW5pdGlhdGVkIHRo aXMgdGhyZWFkPzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+RG9lcyB0aGUgZG9jdW1l bnQgcmVjb21tZW5kIGFnYWluc3QgdXNpbmcgTmV4dC1DLVNJZCBhbmQgUmVwbGFjZS1DLVNpZCBp biB0aGUgc2FtZSBkb21haW4gJm5ic3A7Zm9yIGVhc2Ugb2Ygb3BlcmF0aW9uIG9yIGJlY2F1c2Ug dGhleSBkb27igJl0IHdvcmsgd2VsbCB0b2dldGhlcj8gSWYgdGhlIGZvcm1lciwgcGxlYXNlIHBy b3ZpZGUgdGhlIGV4YW1wbGUgZGVzY3JpYmVkIGJlbG93LjxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IFJvbjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs8bzpwPjwvbzpwPjwvcD48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlbnQgZnJvbSBt eSBpUGhvbmU8bzpwPjwvbzpwPjwvcD48L2Rpdj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+PGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+PHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5PbiBPY3QgMSwgMjAyMSwg YXQgNTowNyBQTSwgUm9iZXJ0IFJhc3p1ayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6 dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD48L2Jsb2NrcXVvdGU+PC9kaXY+PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjUuMHB0O21hcmdpbi1yaWdodDouNWluO21hcmdp bi1ib3R0b206MGluO21hcmdpbi1sZWZ0Oi41aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij7vu788 bzpwPjwvbzpwPjwvcD48cD48bzpwPiZuYnNwOzwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibGluZS1oZWlnaHQ6MTIuMHB0O2JhY2tncm91bmQ6I0ZGRUI5QyI+PHN0cm9uZz48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtMYXRvJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPltFeHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2Yg Y29udGVudF08bzpwPjwvbzpwPjwvc3Bhbj48L3N0cm9uZz48L3A+PHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+PHA+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48ZGl2 PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgUm9uLDxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHVsIHR5cGU9ImRp c2MiIGNsYXNzPSIgbGlzdC1wYWRkaW5nbGVmdC0yIj48bGk+PHA+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxNC4wcHQiPkNhbiB3ZSBzYXkgdGhhdCB0aGV5IGFyZSBhIHNpbmdsZSBiZWhhdmlvciA/ PC9zcGFuPjwvcD48bzpwPjwvbzpwPjwvbGk+PC91bD48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm8uIEFuZCBu ZWl0aGVyIFJGQzg5ODYgZGVmaW5lcyBhIHNpbmdsZSBiZWhhdmlvciBvciBzaW5nbGUgZmxhdm9y LiBZZXQgdGhlIGJvdW5kcyBhcmUgY2xlYXJseSZuYnNwO3NldCB3aGF0IGlzIHRoZSBTUnY2IGRh dGEgcGxhbmUuJm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PC9kaXY+PHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFs Ij5Gb3Igc29tZSBzdHJhbmdlJm5ic3A7cmVhc29uIEkgYW0gb2JzZXJ2aW5nIGhlcmUgYW4gYXR0 ZW1wdCB0byBzcXVlZXplIGRpZmZlcmVudCBkYXRhIHBsYW5lIGludG8gdGhlIHJvb20gd2hpY2gg aXMgbm90IGNvbXBsaWFudCZuYnNwO3RvIFtSRkM4NDAyXSwgW1JGQzg3NTRdIGFuZCBbUkZDODk4 Nl0uIERvIHlvdSB0aGluayBhbnlvbmUgd2lsbCBiZSBzbyBuYWl2ZSB0byBhY2NlcHQgaXQgPyZu YnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm93IEkgYW0gZ29pbmcmbmJzcDt0 byByZXN0IGFzc3VyZWQgYW5kIGVuam95IHRoZSZuYnNwO3Jlc3Qgb2YgdGhpcyBzaG93LiZuYnNw OzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVzdCw8bzpwPjwvbzpwPjwvcD48L2Rp dj48ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJvYmVydDxvOnA+PC9vOnA+PC9wPjwvZGl2Pjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPjxkaXY+PGRpdj48cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBGcmksIE9jdCAxLCAyMDIxIGF0IDEwOjU4IFBNIFJvbiBCb25pY2EgJmx0OzxhIGhy ZWY9Im1haWx0bzpyYm9uaWNhQGp1bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+cmJvbmljYUBq dW5pcGVyLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPjxkaXY+PGRpdj48cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij5Sb2JlcnQsPC9zcGFu PjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxNC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij5JIGRvIHJlbWVtYmVyIHRoYXQg cXVvdGUuIEFuZCB0aGF0IGlzIGV4YWN0bHkgd2h5IEkgYXNrIHRoZSBxdWVzdGlvbiE8L3NwYW4+ PG86cD48L286cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjE0LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPklmIE5FWFQtQy1TSUQgYW5kIFJF UExBQ0UtQy1TSUQgYXJlIGluY29tcGF0aWJsZSB3aXRoaW4gYSBkb21haW46PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox NC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48dWwgdHlwZT0iZGlzYyIgY2xhc3M9 IiBsaXN0LXBhZGRpbmdsZWZ0LTIiPjxsaT48cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBw dCI+Q2FuIHdlIHNheSB0aGF0IHRoZXkgYXJlIGEgc2luZ2xlIGJlaGF2aW9yID88L3NwYW4+PC9w PjxvOnA+PC9vOnA+PC9saT48bGk+PHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPkNh biB3ZSBqdXN0aWZ5IGJvdGggYmVjYXVzZSBlYWNoIGlzIG9wdGltaXplZCBmb3IgYSBkaWZmZXJl bnQga2luZCBvZiBuZXR3b3JrPzwvc3Bhbj48L3A+PG86cD48L286cD48L2xpPjxsaT48cD48c3Bh biBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+Q2FuIHdlIGp1c3RpZnkgYW5vdGhlciBiZWhhdmlv ciBlaXRoZXIgYmVjYXVzZSBpdCBpcyBvcHRpbWl6ZWQgZm9yIHlldCBhbm90aGVyIHR5cGUgb2Yg bmV0d29yayBvciBiZWNhdXNlIGl0IGRvZXMgcmVsYXRpdmVseSB3ZWxsIGluIGFsbCBuZXR3b3Jr IHR5cGVzPzwvc3Bhbj48L3A+PG86cD48L286cD48L2xpPjwvdWw+PHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4w cHQiPkhvd2V2ZXIsIGlmIHRoaXMgaXMganVzdCBhbiDigJxlYXNlIG9mIG9wZXJhdGlvbuKAnSB0 aGluZywgYXMgc3RhdGVkIGluIHRoZSBkcmFmdCwgdGhlIGF1dGhvcnMgYXJlIG9ibGlnZWQgdG8g YW5zd2VyIG15IHF1ZXN0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48 L286cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0 LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO1Jvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBw dCI+UC5TLiBSZXN0IGFzc3VyZWQgdGhhdCBJIGhhdmUgcmVhZCB0aGUgZHJhZnQuIEhvd2V2ZXIs IHlvdXIgY29uY2VybiBpcyBncmVhdGx5IGFwcHJlY2lhdGVkIDwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjE0LjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSBFbW9qaSZxdW90Oyxz YW5zLXNlcmlmIj7wn5iJPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0 Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD48cCBzdHlsZT0idGV4dC1hbGlnbjpjZW50ZXI7bWFyZ2luOjBpbjsi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6YmxhY2siPkp1bmlwZXIgQnVzaW5l c3MgVXNlIE9ubHk8L3NwYW4+PG86cD48L286cD48L3A+PGRpdj48ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbiI+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvc3Ryb25n PiBSb2JlcnQgUmFzenVrICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQiIHRh cmdldD0iX2JsYW5rIj5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7IDxicj4gPHN0cm9uZz48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TZW50 Ojwvc3Bhbj48L3N0cm9uZz4gRnJpZGF5LCBPY3RvYmVyIDEsIDIwMjEgNDozMiBQTTxicj4gPHN0 cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Ubzo8L3NwYW4+PC9zdHJvbmc+IFJvbiBCb25pY2EgJmx0OzxhIGhyZWY9Im1haWx0bzpy Ym9uaWNhQGp1bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+cmJvbmljYUBqdW5pcGVyLm5ldDwv YT4mZ3Q7PGJyPiA8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPkNjOjwvc3Bhbj48L3N0cm9uZz4gU1BSSU5HIFdHICZsdDs8YSBo cmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYu b3JnPC9hPiZndDs8YnI+IDxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+U3ViamVjdDo8L3NwYW4+PC9zdHJvbmc+IFJlOiBbc3By aW5nXSBDU0lEIFF1ZXN0aW9uPG86cD48L286cD48L3A+PC9kaXY+PC9kaXY+PHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bGlu ZS1oZWlnaHQ6MTIuMHB0O2JhY2tncm91bmQ6I0ZGRUI5QyI+PHN0cm9uZz48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtMYXRvJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6YmxhY2siPltFeHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF08L3Nw YW4+PC9zdHJvbmc+PG86cD48L286cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBSb24sPG86 cD48L286cD48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD48 ZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGF2ZSB5b3UgcmVhZCB0aGlzJm5ic3A7ZHJhZnQg PyZuYnNwOzxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+PGRpdj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlF1b3RlIGZyb20gaXQ6 Jm5ic3A7PG86cD48L286cD48L3A+PC9kaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD48ZGl2PjxkaXYgc3R5bGU9ImJvcmRlcjpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6OC4wcHQgOC4wcHQgOC4wcHQgOC4wcHQiPjxwcmUgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjUyLjVwdDttYXJnaW4tYm90dG9tOjcuOXB0O21hcmdp bi1sZWZ0OjY0LjA1cHQ7YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2Jv eC1zaXppbmc6Ym9yZGVyLWJveDtib3JkZXItcmFkaXVzOjRweDtvdmVyZmxvdzphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtNb25hY28mcXVvdDss c2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBJdCBpcyByZWNvbW1lbmRlZCBmb3IgZWFz ZSBvZiBvcGVyYXRpb24gdGhhdCBhIHNpbmdsZSBjb21wcmVzc2VkPC9zcGFuPjxvOnA+PC9vOnA+ PC9wcmU+IDxwcmUgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjUy LjVwdDttYXJnaW4tYm90dG9tOjcuOXB0O21hcmdpbi1sZWZ0OjY0LjA1cHQ7YmFja2dyb3VuZDoj RkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtNb25hY28mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyBlbmNvZGluZyBmbGF2b3IgYmUgdXNlZCBpbiBhIGdpdmVuIFNSdjYgZG9tYWluLiZu YnNwOyBIb3dldmVyLCBpbiBhIG11bHRpLTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPiA8cHJlIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDo1Mi41cHQ7bWFyZ2luLWJv dHRvbTo3LjlwdDttYXJnaW4tbGVmdDo2NC4wNXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJy ZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7TW9uYWNvJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZG9tYWlu IGRlcGxveW1lbnQsIGRpZmZlcmVudCBmbGF2b3JzIGNhbiBiZSB1c2VkIGluIGRpZmZlcmVudDwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPiA8cHJlIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGlu O21hcmdpbi1yaWdodDo1Mi41cHQ7bWFyZ2luLWJvdHRvbTo3LjlwdDttYXJnaW4tbGVmdDo2NC4w NXB0O2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TW9uYWNvJnF1b3Q7LHNlcmlmO2Nv bG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZG9tYWlucy48L3NwYW4+PG86cD48L286cD48L3ByZT4g PC9kaXY+PC9kaXY+PC9kaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD48ZGl2PjxkaXY+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PbiBGcmksIE9jdCAxLCAyMDIx IGF0IDk6MzMgUE0gUm9uIEJvbmljYSAmbHQ7cmJvbmljYT08YSBocmVmPSJtYWlsdG86NDBqdW5p cGVyLm5ldEBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjQwanVuaXBlci5uZXRAZG1h cmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD48L2Rpdj48YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0Ij48ZGl2PjxkaXY+PHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+Q1NJRCBBdXRob3Jz LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTQuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+PHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+QXNzdW1lIHRoYXQg YW4gU1IgcGF0aCBjb250YWlucyBzZWdtZW50cyAxIHRocm91Z2ggOC4gU2VnbWVudHMgMSwgMywg NSwgYW5kIDcgYXJlIEVORCBTSURzIHRoYXQgdXNlIE5leHQtQy1TSUQgKGkuZS4sIHVTSUQpLiBT ZWdtZW50cyAyLCA0LCBhbmQgNiAgYXJlIEVORCBTSURzIHRoYXQgdXNlIFJlcGxhY2UtQy1TSUQu IFNlZ21lbnQgOCBpcyBhbmQgRU5ELkRYNCBTSUQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTQuMHB0Ij5QbGVhc2UgcHJvdmlkZSBhbiBleGFtcGxlIHRoYXQgc2hvd3MgdXM6 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxNC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48dWwgdHlwZT0i ZGlzYyIgY2xhc3M9IiBsaXN0LXBhZGRpbmdsZWZ0LTIiPjxsaT48cD48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjE0LjBwdCI+V2hhdCB0aGUgU1JIIGxvb2tzIGxpa2UgYXMgaXQgYXJyaXZlcyBhdCB0 aGUgZmlyc3Qgc2VnbWVudCBlbmRwb2ludDwvc3Bhbj48L3A+PG86cD48L286cD48L2xpPjxsaT48 cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+V2hhdCB0aGUgSVB2NiBEZXN0aW5hdGlv biBBZGRyZXNzIGxvb2tzIGxpa2UgYXQgZWFjaCBzZWdtZW50IGVuZHBvaW50LCBpbmNsdWRpbmcg aW5mb3JtYXRpb24gcmVxdWlyZWQgdG8gcGFyc2UgdGhlIERlc3RpbmF0aW9uIEFkZHJlc3M8L3Nw YW4+PC9wPjxvOnA+PC9vOnA+PC9saT48L3VsPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Um9uPC9z cGFuPjxvOnA+PC9vOnA+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxNC4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD48cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPjxwIHN0eWxlPSJ0ZXh0LWFsaWduOmNlbnRl cjttYXJnaW46MGluOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtjb2xvcjpibGFjayI+ SnVuaXBlciBCdXNpbmVzcyBVc2UgT25seTwvc3Bhbj48bzpwPjwvbzpwPjwvcD48L2Rpdj48L2Rp dj48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPiBzcHJpbmcgbWFpbGluZyBsaXN0PGJyPiA8YSBocmVmPSJtYWls dG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjxi cj4gPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmdfXzshIU5FdDZ5TWFPLWdrIVVMX0xzVEVXdXlidGV3 Y0lIWDJGd3JxdHdTM0c5N2tpM3R6SFQ4cEd5R2N4MmhQV1laZnJpU21lRzc1dXdQN2wkIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8 L2E+PG86cD48L286cD48L3A+PC9ibG9ja3F1b3RlPjwvZGl2PjwvZGl2PjwvZGl2PjwvZGl2Pjwv YmxvY2txdW90ZT48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9kaXY+PC9k aXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PHA+PG86cD4mbmJzcDs8L286cD48L3A+PC9kaXY+ PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PHA+PGJyPjwv cD48L2Rpdj4= --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From atulumello@cnit.it Tue Oct 5 07:51:06 2021 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 135383A1009; Tue, 5 Oct 2021 07:51:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id belOtN9EeiTU; Tue, 5 Oct 2021 07:51:00 -0700 (PDT) Received: from mail.cnit.it (mail.cnit.it [217.9.64.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7B943A1010; Tue, 5 Oct 2021 07:50:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.cnit.it (Postfix) with ESMTP id 0D0B540234; Tue, 5 Oct 2021 16:50:55 +0200 (CEST) X-Virus-Scanned: by cnit.it Received: from mail.cnit.it ([127.0.0.1]) by localhost (mail.cnit.it [127.0.0.1]) (amavisd-new, port 10026) with LMTP id En13oQBSti1Q; Tue, 5 Oct 2021 16:50:54 +0200 (CEST) Received: from DESKTOPPGLQO19 (net-2-38-102-41.cust.vodafonedsl.it [2.38.102.41]) by mail.cnit.it (Postfix) with ESMTPSA id D12714009A; Tue, 5 Oct 2021 16:50:54 +0200 (CEST) From: "angelo tulumello" To: "'James Guichard'" , "'SPRING WG'" Cc: References: In-Reply-To: Date: Tue, 5 Oct 2021 16:50:55 +0200 Message-ID: <002701d7b9f8$66e72010$34b56030$@cnit.it> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01D7BA09.2A710180" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEEWQJbPMHwJZ19hgzfqnce2skSI61q8Onw Content-Language: it Archived-At: X-Mailman-Approved-At: Tue, 05 Oct 2021 08:03:56 -0700 Subject: [spring] R: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 05 Oct 2021 14:55:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0028_01D7BA09.2A710180 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Dear All, =20 I support the adoption of the CSID draft. =20 CSID adds the NEXT and REPLACE flavors to the END behavior but remains = thoroughly coherent with the SRv6 specification described in RFC8996. As = such, I think that CSID is consistent with the single SRv6 dataplane = objective.=20 =20 As evidence of this, interoperability experiments have been performed = involving various dataplanes (P4, eBPF, VPP, linux network stack, etc.), = which show that CSID can be implemented as a single dataplane solution. = Moreover, I worked on the P4 implementation and adding the support for = CSID to existing SRv6 implementation has been a straightforward task, = without requiring new dataplane primitives, thanks to the CSID = consistency to the SRv6 specification. =20 Best regards, =20 Angelo Tulumello =20 Da: spring Per conto di James Guichard Inviato: venerd=C3=AC 1 ottobre 2021 16:05 A: SPRING WG Cc: spring-chairs@ietf.org Oggetto: [spring] WG Adoption call for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ =20 Dear WG: =20 The chairs would like to express their appreciation for all the = responses received to our emails with reference to how the working group = wishes to move forward with respect to a solution for SRv6 compression.=20 =20 The apparent inclination of the working group is to use = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ as the basis for its compression standardization work. That is = part of what this email attempts to confirm. =20 Because of the above the chairs would like to issue a 2-week WG call for = adoption ending October 15th for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ but with some clear guidelines as follows. By expressing = support for adoption of this document you are fully aware of and are = acknowledging that:=20 =20 1. The SPRING working group is adopting a document that has multiple = SRv6 Endpoint behaviors.=20 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change as = it goes through review and analysis by the SPRING working group.=20 3. All open discussion points raised on our mailing list MUST be = addressed BEFORE said document is allowed to progress from the working = group to publication. A list of these discussion points will be = documented in the WG document and maintained by the document editor in = conjunction with the chairs.=20 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open = issue be added to the document in the above-described open issues = section: * "Given that the working group has said that it wants to standardize = one data plane solution, and given that the document contains multiple = SRv6 EndPoint behaviors that some WG members have stated are multiple = data plane solutions, the working group will address whether this is = valid and coherent with its one data plane solution objective.". =20 Please consider the above guidelines as you decide on whether to support = or not this WG adoption. Please express clearly your reasoning for = support/non-support as well as any open discussion points you would like = addressed should the document be adopted into the working group. =20 Thanks! =20 Jim, Bruno & Joel =20 =20 ------=_NextPart_000_0028_01D7BA09.2A710180 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Dear All,

 

I support the adoption of the CSID = draft.

 

CSID adds the NEXT and REPLACE = flavors to the END behavior but remains thoroughly coherent with the = SRv6 specification described in RFC8996. As such, I think that CSID is = consistent with the single SRv6 dataplane objective. =

 

As evidence of this, = interoperability experiments have been performed involving various = dataplanes (P4, eBPF, VPP, linux network stack, etc.), which show that = CSID can be implemented as a single dataplane solution. Moreover, I = worked on the P4 implementation and adding the support for CSID to = existing SRv6 implementation has been a straightforward task, without = requiring new dataplane primitives, thanks to the CSID consistency to = the SRv6 specification.

 

Best = regards,

 

Angelo = Tulumello

 

Da: spring = <spring-bounces@ietf.org> Per conto di James = Guichard
Inviato: venerd=C3=AC 1 ottobre 2021 = 16:05
A: SPRING WG <spring@ietf.org>
Cc: = spring-chairs@ietf.org
Oggetto: [spring] WG Adoption call for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/

 

Dear WG:

 

The chairs would like to express their appreciation for all = the responses received to our emails with reference to how the working = group wishes to move forward with respect to a solution for SRv6 = compression.

 

The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-sp= ring-srv6-srh-compression/ as the basis for its compression = standardization work. That is part of what this email attempts to = confirm.

 

Because of the above the chairs would like to issue a = 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-sp= ring-srv6-srh-compression/ but with some clear guidelines as = follows. By expressing support for adoption of this document you are = fully aware of and are acknowledging that:

 

  1. The = SPRING working group is adopting a document that has multiple SRv6 = Endpoint behaviors.
  2. The = document is a =E2=80=9Cliving=E2=80=9D document; it may change as it = goes through review and analysis by the SPRING working group. =
  3. All = open discussion points raised on our mailing list MUST be addressed = BEFORE said document is allowed to progress from the working group to = publication. A list of these discussion points will be documented in the = WG document and maintained by the document editor in conjunction with = the chairs.
  4. If = this document is adopted by the working group, the chairs specify as = part of the adoption call that the following text describing an open = issue be added to the document in the above-described open issues = section:
    • "Given that the working group has said = that it wants to standardize one data plane solution, and given that the = document contains multiple SRv6 EndPoint behaviors that some WG members = have stated are multiple data plane solutions, the working group will = address whether this is valid and coherent with its one data plane = solution objective.".

 

Please consider the above = guidelines as you decide on whether to support or not this WG adoption. = Please express clearly your reasoning for support/non-support as well as = any open discussion points you would like addressed should the document = be adopted into the working group.

 

Thanks!

 

Jim, Bruno & = Joel

 

 

------=_NextPart_000_0028_01D7BA09.2A710180-- From nobody Tue Oct 5 08:11:36 2021 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 378E63A07A2; Tue, 5 Oct 2021 08:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 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, 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=A7A3v3e7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=gH9Stpt1 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 xDS8BhFQa9Xe; Tue, 5 Oct 2021 08:11:27 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BFE53A079B; Tue, 5 Oct 2021 08:11:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17075; q=dns/txt; s=iport; t=1633446687; x=1634656287; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TxKYb/DLh3PBG/YVldrwQTu24yW3pCTz9wba7KXFs7Y=; b=A7A3v3e7Sc18/tlQMvVzTHATK5VHuMQokzvqtqlyt0VhUiepa8ezZZ20 nSjER0TMMZZ+xMIVbKrFb8aGnVs3vZV5r7I8ZpJ6CgSgSTwnuTATG01/r PdJ7IZ2CYPOQYQ6fPvmi7ZL0CgJHUHcuTp1VA7Ptn3bjiWQM40BGuS8/h k=; IronPort-PHdr: =?us-ascii?q?A9a23=3AOp4SZhPLT0JtfoOgMl8l6nfhWUAX0o4cdiYb9?= =?us-ascii?q?4Y6kb9Rf6Xl9JPnbwTT5vRo2VnOW4iTq/dJkPHfvK2oX2scqY2Av3YPfN0pN?= =?us-ascii?q?VcFhMwakhZmDJuDDkv2f/D3czEgEdtPVRlu+HToeURQEdz1MlvVpHD65DUOG?= =?us-ascii?q?xL5YAxyIOm9GoPbg8mtke6o/JiGaARTjz37arR3f32L?= IronPort-Data: =?us-ascii?q?A9a23=3AoYh9fKOiklr/vpjvrR1ulcFynXyQoLVcMsEvi?= =?us-ascii?q?/4bfWQNrUoi1DJRymAcXGvSOf2KNmKneNwkO9i3oEwF75XQm9BkTHM5pCpnJ?= =?us-ascii?q?55oRWUpJjg4wn8dtEp+F+WbJK5cx5hYOoSowPwcFCeG/071auW59xGQ6InRL?= =?us-ascii?q?lbCIL+cUsxObVcMpBcJ0XqPqsZh6mJaqYHR7zCl4bsel/bi1GqNgFaYBI67B?= =?us-ascii?q?5Wr83uDtNyq0N8RU8dXifpj5DcynFFNZH4TyD3YEpf2fmVUNrbSq+fr1rq1+?= =?us-ascii?q?CbS+A0gT4njmbfgeUpMSbnXVeSMoiMJAO753V4T/Wprj/1T2Pk0MS+7jx2Sn?= =?us-ascii?q?Mp42txlvp2rQgBvNarJ8AgYe0kEQnwhbfAeoNcrJlD666R/1XbuaGP2wvNhS?= =?us-ascii?q?Uo2NIwC4c52DH1As/sCJ1gldQiZhuS56LO2Vucqgd4sROHpNYYSoTdmiz7ED?= =?us-ascii?q?P0mSIrPa6vX+cJC0Sg9h4ZFGvO2WiazQVKDdzzaaBFJf1wQEp97xqGjh2L0d?= =?us-ascii?q?HtTr1f9mEb+2ECLpCQZ7VQnGIG9lgS2ePho?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AWOwtn6F6aM26wKSBpLqFSpHXdLJyesId70?= =?us-ascii?q?hD6qkvc31om52j+fxGws516fatskdvZJkh8erwX5VoMkmsi6KdgLNhfItKOT?= =?us-ascii?q?OHhILGFvAY0WKP+UyEJ8S6zJ8g6U4CSdk/NDSTNykBsS+S2mDReLxMrKjlgc?= =?us-ascii?q?KVbKXlvgpQpGpRGsddBnJCe36m+zpNNXB77PQCZf6hz/sCgwDlVWUcb8y9CH?= =?us-ascii?q?VAdfPEvcf3mJXvZgNDLwI76SGV5AnYq4LSIly95FMzQjlPybAt/SzuiAri/J?= =?us-ascii?q?iutPm911v1y3LT1ZJLg9Hso+EzRvBky/JlbwkEuDzYI7iJaIfy+gzdZ9vfsW?= =?us-ascii?q?rCpeO85yvI+f4Ds085MFvF+icFkDOQoQrGo0WSuWNwx0GT+/AQgFkBepZ8bU?= =?us-ascii?q?UzSGqF16NohqAO7Itbm22erJZZFhXGgWD04MXJTQhjkg6urWMlivN7tQ0TbW?= =?us-ascii?q?IyUs4bkWUkxjIeLH7AJlOM1Kk3VO11SM3M7vdfdl2XK3jfo2l02dSpGnA+BA?= =?us-ascii?q?2PTEQOstGcl2E+pgE382IIgMgE2nsQ/pM0TJdJo+zCL6RzjblLCssbd7h0Cu?= =?us-ascii?q?sNSda+TmbNXRXPOmSPJkmPLtBKB1vd75rspLkl7uCjf5IFiJM0hZTaSVtd8X?= =?us-ascii?q?U/fkr/YPf+lKGjMiq9CVlVeA6dhP22y6IJz4EUdYCbRxFrEmpe4fdIi89vdv?= =?us-ascii?q?HmZw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CpAACvalxh/5ldJa1aHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUcFAQELAYEgMCMuB3daNzGIDwOFOYgIA5psgS4UgREDVAs?= =?us-ascii?q?BAQENAQE3CgQBAYIIgnUCgkQCJTYHDgECBAEBARIBAQUBAQECAQYEgREThTs?= =?us-ascii?q?IJQ2GQgEBAQEDEgsQEwEBLAsBDwIBCBEDAQIkCzIdCAEBBAENBQgTB4JQgX5?= =?us-ascii?q?XAy8BDqUcAYE6AoofeIEzgQGCCAEBBgQEgToCDkGCfxiCNQMGgToBgn+EE4Z?= =?us-ascii?q?yJxyCDYEVQ4JnPoJjAQECAYEjBQESASMeDYMiggwiihgvQmQEGzYCIAJZFoE?= =?us-ascii?q?CKhECDhmRLFeMAY1LkioKgzCKRJEMgzEUg2eLapc8hxOPEoxJmHICBAIEBQI?= =?us-ascii?q?OAQEGgWgEMGlwcBU7gmlRGQ+DPopiDBYVGYMihRSFSnQCNgIGCwEBAwmTLS2?= =?us-ascii?q?CFwEB?= X-IronPort-AV: E=Sophos;i="5.85,349,1624320000"; d="scan'208,217";a="849578500" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Oct 2021 15:11:25 +0000 Received: from mail.cisco.com (xbe-aln-005.cisco.com [173.36.7.20]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 195FBPYN028144 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 5 Oct 2021 15:11:25 GMT Received: from xfe-aln-004.cisco.com (173.37.135.124) by xbe-aln-005.cisco.com (173.36.7.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 5 Oct 2021 10:11:25 -0500 Received: from xfe-rcd-005.cisco.com (173.37.227.253) 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.792.15; Tue, 5 Oct 2021 10:11:24 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) 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.792.15 via Frontend Transport; Tue, 5 Oct 2021 10:11:24 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dnVEzsod88DZ/a34WR14ZseCpmlLFLwOZ1AKpCIdvNf74x0AZJZEAX51YFKopfb8k4aBTW+Noh8aIfG7HIhw8lzN2ixzoRQ1cgaNEHZVErpvbmMaITnA2wK76Q59u1rvDsQ/8DJC7FlNGwn+9JQyQdRPdNjNg7ED5L6WFP2L2fmxgLWT+AKn2DI0aYgZNSg3k6aftQRAjXmJlWrYL6YfgodkuacI3YcEYCm4WIdt4KmtFLhN/LcD74J4fMP+tGNonH59yJ+h1LGlTCwMRtpDbYryItKk0I0TP1MMO1yCp5pvRVGVzgXJxdZ8Hy8zGBOwc11VoZXE6ZuZGHz+hZjOzw== 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=xCdgkt2+EO1qtsucnu9bp3If5Rw2eJiTS8E38mg7ZrI=; b=Bqo+eaqs3zIdITce1hVStRGYkr59ADW7YuSu5NQJ0CMQnZxJAso/UCLmYThSubEe9W5yRwmw/dskBBde4UEdQNtzlg9JOyDH3jJ6bUK5/aUaUV5VTxMB26Sg+t0a/lXKSh3z85aW0xwfkxiWdfnf7SQh5BBLblO6ZAkPytM/dOL9GrJnr9SLiplOzj/naDB6JpUXEU3xjyWB8aI9yxjHpebdTva5D2ni3TFpDsBUpTfhTv7zY0gZsKkUIG7JnOR6A79MRZHoUWyTas9HH4F9gWJusmOmyMJH9dDV8c5uVzvPE05K2Q8YGAljustQDneYIgjkm13QPl5LVTbh+ENlYg== 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=xCdgkt2+EO1qtsucnu9bp3If5Rw2eJiTS8E38mg7ZrI=; b=gH9Stpt1HjgA9kBW9nQz72TsVsdG4v4tlChT4j2byq6+r5UBLmm3OBKcwm1GZbXvwTKYnpUy/i3NxccP1cvCFPa9+skz123grymEG//FpCUAgAjENNwirZDLYHYMDIBGBv9GQWxGVYQGs5nUG62iPtponbsF35CuD7N6NpTcFWY= Received: from BL3PR11MB5700.namprd11.prod.outlook.com (2603:10b6:208:33f::22) by MN2PR11MB4479.namprd11.prod.outlook.com (2603:10b6:208:17b::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.17; Tue, 5 Oct 2021 15:11:23 +0000 Received: from BL3PR11MB5700.namprd11.prod.outlook.com ([fe80::e071:703e:5db2:4df]) by BL3PR11MB5700.namprd11.prod.outlook.com ([fe80::e071:703e:5db2:4df%7]) with mapi id 15.20.4566.022; Tue, 5 Oct 2021 15:11:23 +0000 From: "Kamran Raza (skraza)" To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQDLqIZy Date: Tue, 5 Oct 2021 15:11:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 624c6b9d-973f-4fb3-0341-08d98812650f x-ms-traffictypediagnostic: MN2PR11MB4479: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: csxJQWIOoRfT/ASnjvrT3EUWs1AR7GE18S1k+2QRDXRVXmPFn6dfH5UFAyGkHySJ3lnU9rrmOIWtq17FWgE2xgkqvmzAwEpOhGVoquRL0biMytek+9V9EEtvH2H0/qUXXrlSyyZOvb5Qh837Gmz6+uMF1sV6K/huSwh3reBIgY3R3AQq6c5JuaLYYYwKNeUfPqnmn2UgWC8V8TMzjaPLm6MG8Lw3D0YVaPW46I5tXADG8NdEGnYuu4GyUZJD+2srxanKUJujySlPusbqPKL6Lkf5T5ziDWQlTVAN7d3n0QbPrPUGGK4qNkguPPSd11sOV90ecCA+fVJ/OfRHCRdcTM1VFFfF1Gyk/aWjhJ/nhwm0otToHU3TLisDueoX0oEDQVIqRfWmR1kY1Ae0J3wei1iUkIKRw3HdKGhOqS+TkTCefmGh+4BFSbOxzeSPlxyvrWuH1EPleyWJITKpLqvPlXy6yZpOe23Ru49MNkY19pk6rIDlbpZGnxXhDkp39KfsRngNtZw52uh2CgjWaY2zI39ZbwrPTW5CXVuyBw0NxGLd5EAi17kYlFewiekMgM/kREkAg14FWcXXy+5sdvvVFWUFXLh0rnv/ndF0fmRl43sLdMmrk/fncVRL3Lz0amL6XEQeVZiYqLAWRcPylXvdFX3fJ6TDGM0twXd3LrOIhaW9qIh+WvNdSbpBZBYVlIXGN8bLdJLYhXu6nT2SaWlJY9yJH/ClSHGiE1qyU1F2uVv1FG6XEY/2dXRytGTji/U05jO5FQWV6+CTd9HrleLaatvoc/ePsOJLUDqoYJWybymhvOrYWtRbqgwlAgh/tOhJ x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL3PR11MB5700.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(66446008)(186003)(66946007)(2906002)(508600001)(122000001)(966005)(33656002)(83380400001)(5660300002)(38100700002)(66556008)(64756008)(9686003)(66476007)(26005)(53546011)(6506007)(316002)(110136005)(4326008)(86362001)(166002)(8676002)(7696005)(71200400001)(55016002)(52536014)(8936002)(38070700005)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?rxsZj89tc+h7vdDh5iWfgH9t14qH/bc3pawqjuwS2L1BW26PVXShEjrh?= =?Windows-1252?Q?3A4SHRdHSWhG0ijAg5ny9qUZxyKYo5DX0Q/Z0NrVRQ1cPAAHOoQJiq45?= =?Windows-1252?Q?cOxe20Oo/WDEW3EOaElnzy37R8ylN8aPdsvuU2zGB3s+XGc0ra4gpH8T?= =?Windows-1252?Q?tdfMP2WxubzBOtJcAip2yBWXEbNc2GsYHcJO2zXHAuzwXGR70qHBCi7j?= =?Windows-1252?Q?XPFqeZMVrA1Azt7DzhelZlhMYDKrwarKflkDeyMgjBdvx8RUYTMSHiAQ?= =?Windows-1252?Q?7TFs5AcFWUh/LvqvJRAogqpqZVeDPXUFTcKmHgPSIqMTZZz6J75OXyEs?= =?Windows-1252?Q?GueuHNmGR5OtO0Ftlq4Mmbb78lq/0iWvI/R/yOw/8VOs/Q6WT2uI0f82?= =?Windows-1252?Q?Pc4/dQQgvRipkwNqXX9Dq5UblQzc6iG5NdXscIygc1+orlA1a64HVtkD?= =?Windows-1252?Q?dhd5ayvev72T9xZTkDTHgNhkGZf5HgnEqujBehb0LhlkLNRBsljeTNOk?= =?Windows-1252?Q?Ci/VNLJRu3eX/XH8WH/vXouCFeLMTPVh2ATeJwyxJo904axT7EYGfke+?= =?Windows-1252?Q?gSzNKz81WNXXjocPfCC1edxxxrt6vkMTP+cVH9APR+Ud10w4U/HfALwM?= =?Windows-1252?Q?E2yiLffvBLLnlTZhoFs/xfC0JGlBoc6Jx9+MHeE8dNb4BranlaDs61jL?= =?Windows-1252?Q?sLCrkK6UCwoGQZGnQRNZPeyPvY+CiP0naeDFGutlwpeYTay8exF8q0hx?= =?Windows-1252?Q?GwL31ynLIvLL38XUg8at58CfIXG/LUCLvPYidTG5AN/+3k5YHf/JKVOM?= =?Windows-1252?Q?vRmh9uVbeMvXBIserCBvGyp22gYjXvtjB4w7APP5NmXrIbMwCxMZ1nee?= =?Windows-1252?Q?XIy4byq7X7K4t/n4vangAajM7LRTkVXF3tLW+iVQSCA+WgvRK+Kgl2FL?= =?Windows-1252?Q?GpAgqpYV89vb9NT3vFYzDJr+vkiXfudweImVq2el9hjl2nUVnQtrG1bE?= =?Windows-1252?Q?nNge5ZuspKY02p5nW3HJauudz6mUKAxBy/TvTk3w0KkO5fkAqYKC4pjG?= =?Windows-1252?Q?GRN+08oKDYPzDawLSfEuIYcxx3GduT+vvqNe5dvwI/n29FJryDvI+lv2?= =?Windows-1252?Q?zf7fIVEvySwTP6wyXevxKustvd7TZ+L/233d1v/nmKpGwLHfHcbD4t31?= =?Windows-1252?Q?ODmrpEtjFW6APRPrHeetVvheC4n2bIWBeNwIfXxcvsckvARhxJQIlKZm?= =?Windows-1252?Q?Mv7yrE3kPKaBvYUbXT/7U5TebZsJVZY/8qTnQ/3uWAgsiMW6pDuYWfPd?= =?Windows-1252?Q?ZpmUtVe/zZP9+pc738NiNEh93Moa1dJlp0S0konE74/Aw5nrfHL6pan8?= =?Windows-1252?Q?Rdholu5qtt/2eM8iR8jgLmZOfrOyEcC7MW4xKrbBPJqPtv8rxqYqDitP?= =?Windows-1252?Q?TmHYInAsCTByvhrj/bQy6Q=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL3PR11MB5700EDBBC7DC3AD27B151B9DD0AF9BL3PR11MB5700namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL3PR11MB5700.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 624c6b9d-973f-4fb3-0341-08d98812650f X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2021 15:11:23.3776 (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: TikitZS17pmQP9gZgPl0Q5Q3ewcNACwY3xGxhE1a3Py3jjecS7mK56qCLXbpxlDGJu7u4SjWrJG0Tg6irJLE9g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4479 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xbe-aln-005.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 05 Oct 2021 15:11:34 -0000 --_000_BL3PR11MB5700EDBBC7DC3AD27B151B9DD0AF9BL3PR11MB5700namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I fully support the working group adoption of this doc, and would like to h= ighlight: * There are already several hardware/vendor implementations for CSID wi= th line rate performance. * As described in the section 11 of the CSID draft, the = interoperability of Next-CSID and Replace-CSID has been validated last year= at China Mobile using Cisco=92s ASR9000 hardware, Cisco=92s XRv9000 softwa= re, and Huawei=92s NE40E/N5000E hardware implementations. In this interop, = the implementations were verified with a mix of Next-CSID and Replace-CSID = in the same SRH. * Thanks to the single SRv6 dataplane solution, the Next/Replace CSIDs = work seamlessly. Thanks, Kamran From: spring on behalf of James Guichard Date: Friday, October 1, 2021 at 10:05 AM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a =93living=94 document; it may change as it goes thr= ough review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_BL3PR11MB5700EDBBC7DC3AD27B151B9DD0AF9BL3PR11MB5700namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

 

I fully support the working group adoption of this d= oc, and would like to highlight:

 

  • There are already several hardware/vendor = implementations for CSID with line rate performance.

 

  • As described in the section 11 of the CSID draft, the interoperability of Next-CSID and Replace-CSID has been= validated last year at China Mobile using Cisco=92s ASR9000 hardware, Cisco=92s XRv9000 software, and Huawei=92s NE40E/N5000E ha= rdware implementations. In this interop, the implementations were verified with = a mix of Next-CSID and Replace-CSID in the same SRH.

 

  • Thanks to the single SRv6 dataplane soluti= on, the Next/Replace CSIDs work seamlessly.

 

Thanks,

Kamran

 

 

From: spring <spring-b= ounces@ietf.org> on behalf of James Guichard <james.n.guichard@future= wei.com>
Date: Friday, October 1, 2021 at 10:05 AM
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

 

The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a sol= ution for SRv6 compression.

 

The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document = that has multiple SRv6 Endpoint behaviors.
  2. The document is a =93livi= ng=94 document; it may change as it goes through review and analysis by the= SPRING working group.
  3. All open discussion point= s raised on our mailing list MUST be addressed BEFORE said document is allo= wed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maint= ained by the document editor in conjunction with the chairs.
  4. If this document is adopt= ed by the working group, the chairs specify as part of the adoption call th= at the following text describing an open issue be added to the document in the above-described open issues section:
    • "Given that the working group has said that it wants to standar= dize one data plane solution, and given that the document contains multiple= SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution obj= ective.".

 

Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open d= iscussion points you would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

--_000_BL3PR11MB5700EDBBC7DC3AD27B151B9DD0AF9BL3PR11MB5700namp_-- From nobody Tue Oct 5 08:38:26 2021 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 1DD283A08FF; Tue, 5 Oct 2021 08:38:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=qHd3Lyhb; dkim=pass (1024-bit key) header.d=juniper.net header.b=LTFKcEpQ 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 D0lLu2pEk2fk; Tue, 5 Oct 2021 08:38:19 -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 E0EE03A0900; Tue, 5 Oct 2021 08:38:19 -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 SMTP id 195B616J025819; Tue, 5 Oct 2021 08:38:14 -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=aZ+isWczDUPUfU12jfYm//RICR1m7TlKq3DLRJic98k=; b=qHd3LyhbKAV/Nap8p022aH6Ra7fYck8eIh7FUDt3XULcKLDT6o0QX1BidIplK/VgEWoA iSka/UqhTT7Bs6irTZAwN9vexS7lyg3FGIpJsTu1l5sTYVyRwndAr6dNsPlsZRAzoisG p3UienvKoKIICwMkQUk+t3gOmZWhX1fGaIgdrJKmjsbVOJ+xPqjffBT5gPJUezMw5bXz Al0JG0hoyPC2Xg7LHlUsQoCAhSOXsCltmsjUKCiC70uI1/xJxWBuEPGA/WyhvYPExGzX 2eXxcgRKYyHAjuz+tOeCZD0KZAeaYji9etiT7e+3FWStBogixHdoVj1rk2hae56Da28E 4w== Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2175.outbound.protection.outlook.com [104.47.56.175]) by mx0a-00273201.pphosted.com with ESMTP id 3bgnhmrta0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 Oct 2021 08:38:13 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SgB1A/iwytTU+wMC7WDhNZcD8GEGy33ity8L41IH+OPrA6JwKw7U4BYhOlZwjn+Mz2ObMiECogzvMJkxFbXMxxIHZuTx9iK30dvwie4JJq4h5iEJqHHDZ/GiOBjtZ39E4k1dPi6r7DpP/QiWDg4WqNRzpHMA/QNrlrFRLjlVrlHjDlKAPJVIVkEGf6WHmfq85c7z5Qw4ty1Vj6bmyDCUlZOb2qi+1XiP4SbIANve20lTI+7V1fbglDVzip1Azwry7ZPc+pEpfvCQfvl18kYxDIuuXEPE50d6S7RSI80mJrlpkvPEBvRB2tDClGMSrG9ao9VJ3a4vzysNjr77xfWPbg== 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=aZ+isWczDUPUfU12jfYm//RICR1m7TlKq3DLRJic98k=; b=PV7q7T4sMLXfXY1Bi0Rct6PJHjJeGpdnaw+ZQO+XdJ4QL4sV1kRDafZDaMTJ3+QDD8fX4DlF9rjFWGaYkXyaA90kUXEq9jMfJIyRdOnygiBogdAvUczUcJl4DXrwct+YpoKPV2zVzBORTrnRF8AKU3Xj9sUe5Mw66sYAIlKOrj9OeuA+CnatDtHUgyhKlgh2vd1EBaUgydXpJgJK1DKQ/4Ls0aYIU8mbNeQAoCAdGH6NZjRUyKnBhSYogge3M6AxIDCK7VPM5fJ3W9ZJP8ofJ2L6X3yGbdmK6GkTFCwjZ/SS7OMOrYdfW5GK55plg27bvvcQ2UzuI7GI6tr0BAcPkw== 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=aZ+isWczDUPUfU12jfYm//RICR1m7TlKq3DLRJic98k=; b=LTFKcEpQd1MfkKj1tPEjMZwZfs35R7iITgTsyXpElXLvHS07O4J06lh3UZXL9sUiPIpJjsSUg+S96drnzxLCqM/PJqiI4gLuWOXZrzk0FxyB6QQmA661LA1iTIUqnwS6nkhTI9EweOk+73vquy00b33Y7uR6dHTPRvibOnD4gDM= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by MN2PR05MB6990.namprd05.prod.outlook.com (2603:10b6:208:193::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.16; Tue, 5 Oct 2021 15:38:10 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4587.018; Tue, 5 Oct 2021 15:38:10 +0000 From: Ron Bonica To: "Pablo Camarillo (pcamaril)" , James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQCeJTAAAC58nBA= Date: Tue, 5 Oct 2021 15:38:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-05T15:38:08Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=5ac9bcaf-2ea1-4176-a003-8ffbeafbebdf; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d2153138-bf30-428c-6117-08d9881622fa x-ms-traffictypediagnostic: MN2PR05MB6990: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3044; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oFvFB+yjLmosL5E5XKtpzKP0fDQeK2gNNJayGFGkcp1qHqL0oPyNEL+E5O6JoOyZ1WGXvg0NN8GH01D+rtOggdy6sZ5SK5vBd56EMw6WW7EoC1uwsdqZgoHn295M4UorW2fIxdjV/qHySGrB6nZFwyAxUoVMZ/KDKG2BEm0tbrCFNVq/7lwVGgq+mCTFYNLg4Ot3WF7YKKN+uQeV8zzx+Dj1KHdkrYwG5kQXYd2ZonYS40IJHwPNg0vpP12H7AGqlUX+IxanT527+um1B2sE5nasi5Z96tZRzgWOWnfNcZPQesXz7t8t6RXSSTP6nQhxOJ/oC9XUM6G21w6TaMZzV4vY4NN4FBZocPpKkhqg/jKx/Bx2hZR7rcFAsLeb3J/dlc5vqLkesEatjv5laK8hAhzbyen8/uZNA+io4GqX7DTCpYQo2kLfhgfG3IbAl0aoT3onsFuwUa2vIxg5SCi5a/hOOb3xKRY5gRN4dY6l4PSF+4PrmSwkC0lYCopMtNdUVvMdBtXn0CNCijOpI1lVAxIgtfDPxku89ba31M0CGqukQhwjWf4ivlldX3FX4LxWoqisqPkozB3cfQHxMq4KbRnlJDMO7h7UsoNQo5xkZonDKDVliRmPiMRwTJjAVV++RwAVibrKyxhwr5Q3f+wXwI2theLDmIlTjkj1urqBXRc/TDpQWLqB6O5DXCXNcwTFVc6qw8gWnV47bw0quQ8pjePhDIwrkIDWegDQWthWrvZT2zk+1gt5QCGkHMhpy4A5A4i4JoEQqenw0U0Brzkqr5NLRcVmJ/guPPjsqiDt4Ds= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(966005)(8936002)(66446008)(53546011)(55016002)(64756008)(66556008)(66476007)(7696005)(8676002)(508600001)(122000001)(33656002)(2906002)(86362001)(4744005)(38100700002)(6506007)(66946007)(38070700005)(186003)(76116006)(26005)(71200400001)(110136005)(5660300002)(4326008)(9686003)(52536014)(316002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?edbXGuP8jetoELKgVgniyv7QET5T8Wo4W5K9ukDw8qDSNt+UBqjREMtEQKHX?= =?us-ascii?Q?e4vLHldwsjLaPCWDImmakzuyvTUrPhn3d5aezzZPk3mXAe7NyJ97kivIvnZx?= =?us-ascii?Q?4Xxh3Jy+M94eZtdVwPxeIBV/WJFQ5qRQHzriEa+I+IuHQd1cVToFMa6kaizB?= =?us-ascii?Q?zZrRHsboq+yPDGbR1pp8Hv/H77+DzrWVHKYp6z/PrAr6DqS+o9ANtS2IpCnR?= =?us-ascii?Q?3B3Wafv1b/1MJCI/d7e1OD+j5JzoFRCavhwl96kCBrpr8Y+A5/wLjXM3INED?= =?us-ascii?Q?9nevyGkFe7EyWVCaokdmEOPi0OmeOOJaahQ4rR9AelWdYuOsNi97XSvdSMK3?= =?us-ascii?Q?gh8vWRbFRB8ngluPXaCEaBmbRs9bwqgDtv4ImWJrt9mkpVVm/091TcnscHfp?= =?us-ascii?Q?f96d0i5BjxFSfttZjbBf+waZI1SJFzW/YjAfoBM90TqcrXLYhuwNfD4iGp/O?= =?us-ascii?Q?5jTKWkGJCmw4yl9gJxLoh9+qaIGJvsw/DmT1VdWu8yVn/xwaP6be8GvUy1SW?= =?us-ascii?Q?vC25UhMjuVWkmh/BbiOiu5EgSVdUbRt5t39onnSq44KbWqd2gfigkl8/lXUj?= =?us-ascii?Q?nQ4qljjEKUrFPI5RI2EMRSWxGEOtdj00erKThkO9OtaUMPx/E0PjKjodUHRS?= =?us-ascii?Q?o3N8xPlmaq3ZYk5SI8X6+qqSWOQD8AogjCySx0Gex39EK+gphB+0tM0vntC6?= =?us-ascii?Q?FOjCBU04AnH/S3BEY/hn+8Gz5hlNN08sg6qedWy7zdKjF3KTegMwul9eVw2m?= =?us-ascii?Q?h27KCDawKVNag0cT7F+aD3CWKNiBkpWLzee1ewiCoKwl/jVVgxJO/wk8aAwe?= =?us-ascii?Q?8oYnjoCWH4Ednf4g/0lMaNKCBpo5XfGLdgyYGgJwTiDv1h+MbMbwEleakEBX?= =?us-ascii?Q?zPifoRNg7QG2OFxTvOs8v/JhIV2qxXI4YGWSPR4JZW8qRxeQVgfUpU0jS6DQ?= =?us-ascii?Q?qQpt+5MVJKybgL7+FbmR4X1EGz0eZU7cE2mZhbNRdfS0NRf61FvzWcRY8T0I?= =?us-ascii?Q?4UT8580M9pW+a/A2SkbhxpiFXfFua0Ut8+/jMN9meuM3iQp0TVceJqQEVmNo?= =?us-ascii?Q?+EswLyCmRjJaOPT7PCFsJ0bsLEVXF/z24SaJUbqTQRqqm1h47npCBa7FW4Ar?= =?us-ascii?Q?P7ZZB1cdxWQ3yUQAxdKIz5TthayWnhKK/IgVB5fg6bKVGrSia39xwnffnxH+?= =?us-ascii?Q?i40PVFAdETo1L7XzVayh8bo41GGpMQ8ttDlRpLAQKowif8GlJlh2M7j1G4kO?= =?us-ascii?Q?QA0ZTp+X6PwC5ul5L4JepAx3IL2wz6FD8WlnsP8p4tez7cU8d8ULVFhHI7Z6?= =?us-ascii?Q?BltIdElzrUYJYOrwJDBTZhyr?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR05MB531610C8939F7E0C741E165AAEAF9BL0PR05MB5316namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d2153138-bf30-428c-6117-08d9881622fa X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2021 15:38:10.4889 (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: hi4OivM77BAWBJ7/+cu7lU1upb0IZ3UlLZV8U3HIrciuyg+ZX3YtJ7oj5RyiRPEyMvP9x5GQHcrt9wap2HdlEw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6990 X-Proofpoint-ORIG-GUID: Uda5dFW8pYxDU9UxjGeqD2AGrL87l_84 X-Proofpoint-GUID: Uda5dFW8pYxDU9UxjGeqD2AGrL87l_84 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-05_02,2021-10-04_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 lowpriorityscore=0 phishscore=0 mlxlogscore=999 priorityscore=1501 suspectscore=0 mlxscore=0 adultscore=0 malwarescore=0 spamscore=0 clxscore=1011 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110050092 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 05 Oct 2021 15:38:25 -0000 --_000_BL0PR05MB531610C8939F7E0C741E165AAEAF9BL0PR05MB5316namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pablo, The WG has expressed a strong preference for having a single compression *b= ehavior*. Why is it OK to ignore that preference because RFC 8986 has 36 di= fferent behaviors? Ron Juniper Business Use Only From: spring On Behalf Of Pablo Camarillo (pcamar= il) Sent: Monday, October 4, 2021 1:32 PM To: James Guichard ; SPRING WG Cc: spring-chairs@ietf.org Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ RFC8986 already defines 36 different behaviors. This document, CSID, is a single SRv6-based solution that only defines addi= tional behaviors with the next and replace flavors. --_000_BL0PR05MB531610C8939F7E0C741E165AAEAF9BL0PR05MB5316namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Pablo,

 

The WG has expresse= d a strong preference for having a single compression *behavior*. Wh= y is it OK to ignore that preference because RFC 8986 has 36 different beha= viors?

 

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;      Ron

 

 

 

Juniper Business Use Only

From: spring <spring-bounces@ietf.org> = On Behalf Of Pablo Camarillo (pcamaril)
Sent: Monday, October 4, 2021 1:32 PM
To: James Guichard <james.n.guichard@futurewei.com>; SPRING WG= <spring@ietf.org>
Cc: spring-chairs@ietf.org
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.= org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

 

RFC8986 already defines 36 different behaviors.=  

This document, CSID, is a single SRv6-based solution= that only defines additional behaviors with the next and replace= flavors. 

 

 

--_000_BL0PR05MB531610C8939F7E0C741E165AAEAF9BL0PR05MB5316namp_-- From nobody Tue Oct 5 09:58:54 2021 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 02BBA3A0D9B; Tue, 5 Oct 2021 09:58:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=oUiKsHkj; dkim=pass (1024-bit key) header.d=juniper.net header.b=hFgZtTPi 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 dDAFflT4AWuU; Tue, 5 Oct 2021 09:58:47 -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 0578A3A0D99; Tue, 5 Oct 2021 09:58:46 -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 SMTP id 195B6KNA026009; Tue, 5 Oct 2021 09:58:46 -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=RrvZtMQ6tbDIsxBdnDVjjsWqsrLPBn+y8G1t4SzKrfs=; b=oUiKsHkj6vaganK9SpOiBJMJBAOeQtu/aJhJfOrvNoU2nYEwd6kq3SURqrpBXOb4QPBS VTnE1O3T5k6vKThBmKsUhbKrX7MJCMMV0nSnv9qEXO3mMdDz1j+CcgmcM9gseCV0/UR+ t2+70p1vIQgfNUFJcYhKzYL92Pw51bo6f4SKCu9fnuXM0pklKnODHl2gZZHnh1GTxEnU hNoWXKN6ZzMvNq+fzsbsqNXxtiuov3LYf0tO6jlzL/K9MpPwFSw4uCWxN9H/vG5zcjPz tJpFuDIBEt9zCTu+fRWb4ZmNIhx0OsNQWVhyC4KmXiGVx5sWMNc8hPHvFCWbqqaO+VEk 7Q== Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2103.outbound.protection.outlook.com [104.47.55.103]) by mx0a-00273201.pphosted.com with ESMTP id 3bgnhms0x1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 Oct 2021 09:58:46 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eWvxMUfJw2HCSk+ZgR59QU+t+Z0H90mAsXrc+0oFyLw/u/ZamxEaQru+M8qHirGMiAvNy16QMCZDqFnuU1PsfUM3addyGQTQ2tPbZSbb4QNDNLsZC0WCAQKYDnT4MPjBhaZsvpQhZJY8I7eZEKxbBdreh5zAeH/Ysx9mjDSqqvvUfo27AViRXSHKIha0X/xmkRD8rn1CYs0hEAbp8JRRx8NyqRN7uiRBu30fPRW4kqA9jL5UFZFCmnCJkWfxM6jewNZy8p1x+IPu0VvI3qXjfJgbj3nOz7XNGaAPXKalORVwpOY226vxRYLfOKWdg5T3NKolynETfbUolkXC9ckINA== 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=RrvZtMQ6tbDIsxBdnDVjjsWqsrLPBn+y8G1t4SzKrfs=; b=XILsL9kOgBDJxiIYLDixglzeBlM/m9xz0YUtHYDXkRuir0JWuKJ3Jibsl1TgcTjqqpW+5L1tb8bXKpspfcRooK5dzJ3fPrWjuoLhQ1C+j2kijSereO7gLgegaq/xkioDrmoA0Q0LqBzyLiAmvq+7HmVVv5wKqmD6mi+/dN8nlO989FkuK0ap95fXuQumtOrr+e06ID1cKz9ECHqvCLfngnvLy2qIcMMFFnd/jaJ+VECAUuHKAPkwrmWwPRA8PNqA6SPgFbnjQmI8hj39H8JdocP9kNNaOhylrRWTuEP5ros0g4QEOT9f2bUFsKNGdZ6uWsIL6YpBuWdCEQQXAFW8og== 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=RrvZtMQ6tbDIsxBdnDVjjsWqsrLPBn+y8G1t4SzKrfs=; b=hFgZtTPiWoc7YcEMyPQSOjM+K9iH9TzCqmNeI7axm/zTQTRBHaS8hMwoyW4WIhAtBU6Hdz854KzbPlhHyLLETaQM3oafSQtCaxjKvX1u+npc7oU7dPmqRnnaFfQ5IQVnP0izX5x3yImAZZh1wNv8YFP04/K4aE4aJDWAdFO7mrQ= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by BL0PR05MB5137.namprd05.prod.outlook.com (2603:10b6:208:87::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.16; Tue, 5 Oct 2021 16:58:41 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4587.018; Tue, 5 Oct 2021 16:58:40 +0000 From: Ron Bonica To: "6man@ietf.org" <6man@ietf.org> CC: SPRING WG Thread-Topic: draft-filsfilscheng-spring-srv6-srh-compression-02 Thread-Index: Ade3AXyWK2NzAamgSlCvJ497z/5RLwC/aCkQ Date: Tue, 5 Oct 2021 16:58:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-05T16:58:35Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=2d4e6758-5224-40c7-a45e-bf48b4ff636a; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa899d9a-fdb4-4cd9-8373-08d9882161c4 x-ms-traffictypediagnostic: BL0PR05MB5137: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: B2EsSZrLk6AaCTYdvmQSsnYf+qfVmL8/Wgd0MTxUOmg4nZYIdIrWr90swoBaXG6ngpPo/cuZPawfWT1Mngohi6D7uj3aiuf4HMtHVtWD8tJK2ix1xTFRBodpgX/WsqUdkM+9bex2qbdFBqloxR0QXJrTeQToXR7xH27v4L7iVMnAyARnu3hSmO+h1TbxOLBKA7IuuuAhx4qH7hwnyzqk8ntMvSon/+Q/t6hvJMggYFVGNo0YNORHIkOd8XLCsPa6+/WF26YFdIs130xmiwcYpx7DljJTb/xttWTZ2drcknvgKWIGqCctDvXVV6oLN0+6XpqDgbCHwfwLZkZV9CZMJXJPVUXgflGw9Ef//pSj0BlbKmubxUtziz/f/StMa8zKKKeBwzs4ap2E80/4ap1v9im1wRJSSxLGm5AB+Hc20E0JHOleGMM0SKvwzcTmMihQzNDXSM8I427Va+VvdHhvSzkYelEnaw09Q2pfPmyHgw1UZ1SxUt0YqBB/lreVXImq6/Ftqkurn8Txmta3Cj8aKY0iwmIrynbsg6SHtw7zaFjwKichTn2meupNw6bMSNk5MLKJzxtsOxP0X1AKXsYbDg0bGnCEGofEC1k7vZTi/NIa6umzkEq81I/GyxwBnRL9wFarR+nyiScbagP+/VpkURuw9cD8LG6khySLZ9CA4+Y7xvQmTD/SLrP2N0ib5B5A/kgRMTPOdXWz6alYKi1uwQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66446008)(9686003)(6916009)(53546011)(64756008)(55016002)(66556008)(76116006)(6506007)(86362001)(4326008)(33656002)(7696005)(66476007)(52536014)(450100002)(66946007)(5660300002)(316002)(26005)(8676002)(508600001)(2906002)(122000001)(71200400001)(8936002)(38100700002)(186003)(83380400001)(38070700005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?WQYX+CYtpRo4BjaoIbWKcNrCXoKsN62qViQ7U63n5Ld5pJM7K/WKzEJJZKKc?= =?us-ascii?Q?2Nwk4bXho1GBY9euVgVHwiGdND9Narw65oLXh5h2JtQT5hR98XEGZKvenAGh?= =?us-ascii?Q?YjrkXxfe9SFAKpv9FrM/IeMG/ABTAVDrXz9WitsiiSmVu4lWaxGaLzcdj771?= =?us-ascii?Q?Mecwg+Dtc9irKX60+cEs4Ln9sD67+bNCFRSTuRrKAeMfYPCty+uE7X0zwlWP?= =?us-ascii?Q?jyedD3GDY/5MIo7SF4EG1VR0/B4h8rTI8cYEQ8oTEZyKoRD1ww1xNoDMAznQ?= =?us-ascii?Q?32JW+qd+cDovTwGclevt+QxsLwAIF1mDEc9QcU57IOpN3U2HL+aNkRzP7Awg?= =?us-ascii?Q?VLJ4SaXeLZn7GlgcNxEVqzJiKMzIUhENmTu3t/gGpwvu2VWn/CfBgx8FZFUA?= =?us-ascii?Q?oP7O+1I+uNAUr2Ykd8splNjEdCiv2/sCjxsGlyDj+wZPUkHYJ3/yqfvnYZWK?= =?us-ascii?Q?ZAfap8iWRlEuqRv8CYSHyIKcQclfYrRasg0d/kKwzEWurUG8RRsrYx7CL6g7?= =?us-ascii?Q?0g1ac0xu5W2SB/RBYTKJirgZv2jkYoa41/PQtAV3VyIZSdwMAttiHEfE/9/G?= =?us-ascii?Q?DiE7RvQrjJeGhRKCrx6pVoJpt0FyuidXIV8DrQfOoR8ZH85rV8dLogYknT0A?= =?us-ascii?Q?MlfeDUcDmX76O3rVyn5DPWbBnk+KkIUiZqp1CaGUXDqzGMktrkkGsCrkNxU6?= =?us-ascii?Q?QkCul8hvFju6o+Z8L37PmyaRwuw0Ho0OJdsQFJqeWSUok/UeG6nGIUs2vNSP?= =?us-ascii?Q?byI0IFt+owXIm+ZDgRHjWeW5gSr9hOJTX/XSwY1Dz3ZvI+YuteqhTulNG92f?= =?us-ascii?Q?8oaCBuq/LBb9emOk1M/PvXVe0GVtvwSiWXwL1eHFe6DmTsbqxON8TAc1NNqV?= =?us-ascii?Q?gpD0Ggo9GXg1Q2lYCk7ngJaxANsNexRhDDa61/FnGlPfuyu2pYdKhFYOp9Wc?= =?us-ascii?Q?icDQwHXu6RbJewVUT4+9XpaXjCRvR3h3IBRW+skx8U4iKK6/+1QyhHC3JXI0?= =?us-ascii?Q?yAAopT+OuT2rN7lzEbAmHcdTMdRSOWg97VTl8iydH6L/tITQHw8wxM8YNoSA?= =?us-ascii?Q?0BFcOJuLzLinNV3oO0NRWxhrrtn7tLgxgFiJkuKk16qMcG23iVvoitJwr6zH?= =?us-ascii?Q?7W/ga9Sh75NuxDFcx/+vxAcGqnKy3Go5qYW4g0kqIGejiQCG2n2E16GIlnF2?= =?us-ascii?Q?zEe81+QlYhRsIsewrLzUQfcfBQKY+vW9+/suhWj7UOmL1fe31/1mPeUahbeX?= =?us-ascii?Q?gBCF9put8GGPeQEFiLpB+9k1fFmXnxksb9Be9hTRjcYTl8EVWKw/MCxSj9Qt?= =?us-ascii?Q?SY1BtsyTDp6m/bqcZgnHJUiZ?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR05MB5316159E7DB26292DDB32E75AEAF9BL0PR05MB5316namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fa899d9a-fdb4-4cd9-8373-08d9882161c4 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2021 16:58:40.3623 (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: Fn0v5/8nle48k6v5qrvbVzyln1zvieTzdoDzq0r/4vT+w2O9PgMJ3EPNp2XfvqsH2+FnUh4S5oauUagc3AICNQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5137 X-Proofpoint-ORIG-GUID: gfWaD2cECm4WOx1DkLM0Lxtz9otwJr2n X-Proofpoint-GUID: gfWaD2cECm4WOx1DkLM0Lxtz9otwJr2n X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-05_03,2021-10-04_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 lowpriorityscore=0 phishscore=0 mlxlogscore=999 priorityscore=1501 suspectscore=0 mlxscore=0 adultscore=0 malwarescore=0 spamscore=0 clxscore=1015 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110050101 Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 05 Oct 2021 16:58:53 -0000 --_000_BL0PR05MB5316159E7DB26292DDB32E75AEAF9BL0PR05MB5316namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, In a private communication, someone asked for specific references to RFCs 8= 200 and 4291 that were difficult to harmonize with draft-filsfilscheng-spri= ng-srv6-srh-compression. References follow: Section 3 of RFC 8200 ----------------------------- "The Destination Address field of the IPv6 header contains the "128-bit add= ress of the intended recipient of the packet (possibly not the ultimate rec= ipient, if a Routing header is present). See [RFC4291] and Section 4.4." Section 2 of RFC 4291 ----------------------------- "IPv6 addresses are 128-bit identifiers for interfaces and sets of interfac= es (where "interface" is as defined in Section 2 of [RFC8200])". Section 2 of RFC 8200 ------------------------------ * An interface is "a node's attachment to a link" * A link is "a communication facility or medium over which nodes can co= mmunicate at the link layer, i.e., the layer immediately below IPv6." So, an IPv6 Destination Address represents a single thing that is instantia= ted on a single node. According to draft-filsfilscheng-spring-srv6-srh-compression-02, A Compress= ed-SID container (C-SID container) is "an entry of the SRH Segment-List fie= ld (128 bits) that contains a sequence of C-SIDs." A C-SID is "a C-SID is = a short encoding of a SID in SRv6 packet that does not include the SID bloc= k bits (locator block)." According to RFC 8896, a SID identifies an instruction on a node. And finally, according to draft-filsfilscheng-spring-srv6-srh-compression-0= 2, an SRv6 node can copy a container C-SID to the Destination Address fiel= dd of theIPv6 header. When this happens, the IPv6 Destination Address doesn't represent a single = thing on a single node. It represents an entire SR path. = Ron Juniper Business Use Only From: Ron Bonica Sent: Friday, October 1, 2021 4:35 PM To: 6man@ietf.org Cc: SPRING WG Subject: draft-filsfilscheng-spring-srv6-srh-compression-02 Folks, Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new SID= types that can occupy the Destination Address field of an IPv6 header. See= Sections 4.1, 4.2, and 4.3 of the draft for details. The SPRING WG has issued a call for adoption for this draft. It is not clear that these SID types can be harmonized with the IPv6 addres= sing architecture. Does anyone have an opinion? = Ron Juniper Business Use Only --_000_BL0PR05MB5316159E7DB26292DDB32E75AEAF9BL0PR05MB5316namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

In a private commun= ication, someone asked for specific references to RFCs 8200 and 4291 that w= ere difficult to harmonize with draft-filsfilscheng-spring-srv6-srh-compres= sion. References follow:

 

Section 3 of RFC 82= 00
-----------------------------

“The Destinat= ion Address field of the IPv6 header contains the “128-bit address of= the intended recipient of the packet (possibly not the ultimate recipient,= if a Routing header is present).  See [RFC4291] and Section 4.4.”

 

Section 2 of RFC 42= 91

-------------------= ----------

“IPv6 address= es are 128-bit identifiers for interfaces and sets of interfaces (where &qu= ot;interface" is as defined in Section 2 of [RFC8200])”.

 

Section 2 of RFC 82= 00

-------------------= -----------

  • An interface is “a node's atta= chment to a link”
  • A link is “a communication facility or medium over which no= des can communicate at the link layer, i.e., the layer immediately below IP= v6.”

 

So, an IPv6 Destina= tion Address represents a single thing that is instantiated on a single nod= e.

 

According to draft-= filsfilscheng-spring-srv6-srh-compression-02, A Compressed-SID container (C= -SID container) is “an entry of the SRH Segment-List field (128 bits)= that contains a sequence of C-SIDs.” A C-SID is “a  C-SID is a short encoding of a SID in SRv6 packet that d= oes not include the SID block bits (locator block).”

 

According to RFC &n= bsp;8896, a SID identifies an instruction on a node.

 

And finally, accord= ing to draft-filsfilscheng-spring-srv6-srh-compression-02, an SRv6 node can= copy a container C-SID to the  Destination Address fieldd of theIPv6 = header.

 

When this happens, = the IPv6 Destination Address doesn’t represent a single thing on a si= ngle node. It represents an entire SR path.

 

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     Ron

 

 

 

Juniper Business Use Only

From: Ron Bonica
Sent: Friday, October 1, 2021 4:35 PM
To: 6man@ietf.org
Cc: SPRING WG <spring@ietf.org>
Subject: draft-filsfilscheng-spring-srv6-srh-compression-02

 

Folks,

 

Draft-filsfilscheng= -spring-srv6-srh-compression-02 introduces three new SID types that can occ= upy the Destination Address field of an IPv6 header. See Sections 4.1, 4.2,= and 4.3 of the draft for details.

 

The SPRING WG has i= ssued a call for adoption for this draft.

 

It is not clear tha= t these SID types can be harmonized with the IPv6 addressing architecture.<= o:p>

 

Does anyone have an= opinion?

 

   &= nbsp;           &nbs= p;            &= nbsp;            &nb= sp;            =             &nb= sp;            =             &nb= sp;            =    Ron

 

 

Juniper Business Use Only

--_000_BL0PR05MB5316159E7DB26292DDB32E75AEAF9BL0PR05MB5316namp_-- From nobody Tue Oct 5 11:08:00 2021 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 654743A12FB; Tue, 5 Oct 2021 11:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, 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 QCs-8-i41Udb; Tue, 5 Oct 2021 11:06:19 -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 272DD3A12E8; Tue, 5 Oct 2021 11:06:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4HP5B24Ld1z1nsgd; Tue, 5 Oct 2021 11:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1633457178; bh=OzO4stgoab27Rt9Rczozxh63H5sPjCw6OQFPwb499mA=; h=Date:Subject:References:To:From:In-Reply-To:From; b=cBieibKVidGJ6krAXot+U0TSDIeR7QbSv7sQL/qiccPaS6/ry1jpnvDe62KWxs4c5 spgHEHFaUH7CEEoDw1o3evrgIexH9OA7xpWK8rBbM2M2Xw2PyBQv4SqG4XJB7ryhIL Pqjas4akL5M+yhB9L3JVYIreFzAdsVm7bCVLWScY= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.22.111] (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 4HP5B20Lv0z1nvNG; Tue, 5 Oct 2021 11:06:17 -0700 (PDT) Message-ID: Date: Tue, 5 Oct 2021 14:06:16 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2 References: <163345625018.19151.3254408211366822883@ietfa.amsl.com> Content-Language: en-US To: "sfc@ietf.org" , "lisp@ietf.org" , "spring@ietf.org" From: "Joel M. Halpern" In-Reply-To: <163345625018.19151.3254408211366822883@ietfa.amsl.com> X-Forwarded-Message-Id: <163345625018.19151.3254408211366822883@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [spring] Fwd: Second Call for Nominations 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, 05 Oct 2021 18:06:26 -0000 Please, help the nomcom. Yours, Joel -------- Forwarded Message -------- Subject: Second Call for Nominations Date: Tue, 05 Oct 2021 10:50:50 -0700 From: NomCom Chair 2021 Reply-To: ietf@ietf.org To: IETF Announcement List CC: ietf@ietf.org Hello IETF Community! Only one week to go and we need everyone's HELP with nominations. If you go to https://datatracker.ietf.org/nomcom/2021/nominate/ you will notice that: - INT, TSV, OPS, and ART have only ONE accepted nomination so far - Other positions are not that much better: 2 or 3 accepted nominations is not a lot (TRUST, LLC, Routing, Security) - Neither are 10 accepted nominations for 6 open IAB positions Oh, and nominations close in one week: Monday October 11. Please take some 10 minutes today (or make it a fun weekend assignment) to think about someone who would be a good candidate and nominate them using the above link. Of course, self-nominations are encouraged! For full information, please refer to the previous Call for Nominations here: https://datatracker.ietf.org/nomcom/ann/350147/ Thanks, Gabriel Montenegro IETF NomCom Chair 2021-22 nomcom-chair-2021 at ietf dot org _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce From nobody Tue Oct 5 11:56:39 2021 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 8C0B53A0875; Tue, 5 Oct 2021 11:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=D9LLTGRn; dkim=pass (1024-bit key) header.d=juniper.net header.b=bs0sV7bU 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 QapykajCjGbW; Tue, 5 Oct 2021 11:56:30 -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 ED1903A0874; Tue, 5 Oct 2021 11:56:29 -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 SMTP id 195BtDhS030238; Tue, 5 Oct 2021 11:56:27 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=f+4LTu/PIs4fnI11cisPctcO5fU8mvOWVaX8khA4vyg=; b=D9LLTGRnPKlA2Yr0dh9/G+q8Ok4SWZ0qYRHc01VT+ajQ1hg/SSiROni09d/k08Nb/QhS vNPm7dMCHyW9TwUhz7O9o5NThtc/v70nynjPrc6F+E3gO8mdc0wIGqgiPAnnqAjXpXq/ Yjk9fGoZvrzRmBsv2GMq9CB/jqIIq3Ij9OnHoBWikkZRK0hUUWCcldOM0egz24rVetAU AdqEy8KQTgJwkM87qScUMeMfWT1nJMdCYmOH9+eMHXLAIzqJfsHbrNMME5tvQOa0ZCxP Hh1PSOpFUHoM4gSsnmOu+WOR6GjLUOQdiTrsQUyn5O9VDGVGHjn3KIsJ5qZQofo/DoCp FA== Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2109.outbound.protection.outlook.com [104.47.70.109]) by mx0a-00273201.pphosted.com with ESMTP id 3bgp8ph69f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 Oct 2021 11:56:26 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MqPUCmjHkMjrrzSN//gpGYK2+gBJdnLb+upkb7eve38XwvmbiO7WoQi4SE4xbwFWwhLrK/Mh939hzo9YWeShbR8Um5PYsIhECwG9MQHo1wharKop7AlO89AP5IZkWzmy1KZoIvw3KBrPex2K736dcyLNt2cwIQ5FWsjExHlClTXYFutlzea1aG9XuiLnk9tXDRmsDVpuOL6Ms3pW5P8pvaUnYpQCS+XuIU825HHfgJixboIQyWRsKHaOzp4OBBCyXp5+y878f0z3IWNaJVg7masBZnE20+tXVzeWbSTigl0S0bGbjhmLpyEla9X5wEQH9WNO71o2TNIDex95Fz1yag== 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=f+4LTu/PIs4fnI11cisPctcO5fU8mvOWVaX8khA4vyg=; b=SCNCImZNcgxgCPNQbWEuelYhOYIT60xyluoM/+RytpZCrAqgtWLCYYfyEZCG30aPWx3ePEJdqxVE8ItOFGzPyBBtRdMPQS+MDjcO8aDseHVhyep3H8JQ72xqv0PV4pHJEkDroYEQ5yUsEFL45zsetIU+1YcUPDGHFBEy4o+jj8k/ZepsM8RPqsn5RWzQb7AnlaBzHyYLnVKj32ve4u/ie2y3/mAk1HZl3GbM9mSr2qeqoPAxNuC4ddEVKJgyP3PcZQ91oPXhlaGnhzJui8+mozBsAnwkoKF9MKzFWDZ1mlcZDGDbSpuPNVRXBVrzwjLUShJfv/cyn6LHniG13QAP7A== 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=f+4LTu/PIs4fnI11cisPctcO5fU8mvOWVaX8khA4vyg=; b=bs0sV7bUdpnmBp1IhAuJQ/ub8tBLuc8xkXk5AKMyNECG87tTF/eCBbWxw2AVdkRY5gX5lH9HC5yyM0izR4D9VEvmnST7H7b8QEKYZBGRVq8vCkqIeyzetKV7DWuMbmKhcrWQL2x+t+36OGOyIR4vP2oi089qzA1pJsfEYIGofMo= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by BL0PR05MB5139.namprd05.prod.outlook.com (2603:10b6:208:8e::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.11; Tue, 5 Oct 2021 18:56:10 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4587.018; Tue, 5 Oct 2021 18:56:10 +0000 From: Ron Bonica To: James Guichard , "EXT-Andrew.Alston@liquidtelecom.com" , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-rv6-srh-compression/ Thread-Index: Ade6Gc5twcBDTqA5QLSPvTjX+JvbKw== Date: Tue, 5 Oct 2021 18:56:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-05T18:56:07Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=cb540479-0624-482f-bde4-680b11adf467; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4d92cc3f-1285-40ff-379b-08d98831cbb6 x-ms-traffictypediagnostic: BL0PR05MB5139: x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DIn/4IIUCQ5Cxrpe3hh0SllD+8WX/lgqVUZxBjv5ph4dwxllNOdZbC5bWwXTxPi0hNSr1wX6H8L1TLGGwOup2uE9NcQQyVomeAZgOcJUVtuYbf1lAZiCddoAUO+faV7w9HRnx5PJgd/8z3sUXAWYJ2zSe9DfeYHSVhp3CVFrdXNCEC5nDWqcmlCo8Ey5P11HjLzsxkbHKt9Nsw6K7EIGpMfe/90kr23o17vCqYyERgFMBsMy5JbL2mrzpiY0mwG49in3XIOPbDy0JfYEOTNJYmQjsEje/vncqyeCf5oa61wT2/lPUcCZpoAoNU7o9tSh576pU9fPA+KtRBFF0qgBsWvcRxf75n1nZ/s9BGXFyucLB1372JV1x5JqTniZZ47dmM19WFNqGOBDCl6XHXdRXgcJLvvGLM8xX8Ss4wwc/aAZLhdpYb/QY+hBZVovYNqaPJ4naXYtx7vDJCNTdZ0BG51qRYCxe4r1NUDRdZJTgjrR1g0CTtKzjSvsrrjrNCu6+Aa+7DqOyuafEaJKOz24oLuqUKp8a1YqbBYxBC2d7Tv127BelKFVEDhJx/2kS4bNG+QDP2cGHr0c8wgW1JtWUWfEQV44bDTVnJLju4lyJnB56lih3rCPykIe07JGoWhxlkJxoCLFrNse0fZgRCF470fKDuoIvIjjAGKyNThyhzLx0WChX4/oCyGvZUNCTh3r744hds7OHtBBuu2hRjeYoDDABGGiNfkXwHm3Pd9iUIG97mFuGcJcQ9g0AzfLnCeaoxBZAB/V+1sPo24Paics+L1hqdhLTkk9Pr+yfwRLNr9r1TmNgNoGrY04hWVkCw75hE5DO08D1s08AT65IpOO873/svabTqq+yulEEg+H2EE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(4326008)(186003)(64756008)(66446008)(53546011)(5660300002)(52536014)(6506007)(66946007)(66556008)(66476007)(26005)(38070700005)(7696005)(166002)(86362001)(71200400001)(38100700002)(316002)(83380400001)(508600001)(8676002)(8936002)(2906002)(76116006)(110136005)(9686003)(122000001)(33656002)(55016002)(966005)(491001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?AC1ddl/kmodtrrQRdZLXDL+I1++13/zJTZ4tCG49m/afu4MLpfYC40MRcgBP?= =?us-ascii?Q?OtuaPsqNNyLWGWBQKy1Jmwet4Q6i7qxrCe67jYmgi01sk35p5GoYFirjcg/x?= =?us-ascii?Q?aP2aMC/9lRmzJCTJ6ViBZmQdYO/PB3WgExVjUa0lYduoXINRQ5NI58GqWeUs?= =?us-ascii?Q?PWnU1AdADpHg1sU3z8sJgyigHLngbjwQrzJZpyRJR0upZkabMb8++MAEMEAG?= =?us-ascii?Q?vlnvJF0FOXVKJbxlc6tGC3O3pFSypatB8PujcV71Npndou7VxUi0BtrDEPe5?= =?us-ascii?Q?BTzB0NuysDqWR9I+/MIaTNfTubfLJ6mE856fFXbfwIbw0avDbKMSkaCwiJAS?= =?us-ascii?Q?mjmp+05EdfIwo2hxZOBG5NOVNUBeek6wjlhuMimZwDwtkQJ9bt3mi9C7NIC2?= =?us-ascii?Q?I6NxEWNUyoVuCslPEHKbvoyEx9v6oW5buQ6ObP/YsI9/WzFkrPIxaGmVKtQh?= =?us-ascii?Q?UJFVVzMssjD5HVs6xkXOEV4hH4PUk2/nkHACWwUcn23Q55taGkWI2SotcTy9?= =?us-ascii?Q?8hIMkWOOlP8A6px56rMm2RjxIRHISFUV+luUUmgkw9jK6lsE20xrxS+XlWCW?= =?us-ascii?Q?OnNQOWBQHRT2MTNTziLUu42ibUGkDm379TsPv2B2rGpCF+isSuNdmrTkuMyR?= =?us-ascii?Q?lWrp4CTVR8of8XO7R6NuBZpwB7gkeTIAd4mrbY6lzIqRQ2GuQbzsbDva117E?= =?us-ascii?Q?EGEJiItXooAQ8ky6dCsnzsPYykJ6w00rYubCIdUUt87b6IJs2vep2YOK+bhs?= =?us-ascii?Q?esTIdwHfth1K6VTfgISIPuDkc/Hc0y1iYJmnkA5gLQ0KksYBLRc6nuikUuJz?= =?us-ascii?Q?fmJO0aHH4AlF1bY05NVM/Is+S+P1DO98lWksH3OSqNF/JROnOn54QvJoHcyN?= =?us-ascii?Q?dFZolL+U0R97pl3G7mwu9SiCwC7DfjFnioe1vzMf2LBoCO3Ejmm4uOPC/APQ?= =?us-ascii?Q?k64RISIiILJ0nvXVEmRriCXUgNB3JEAaiLB8xPkA3CmpBNkQWpkvV/SOmo7M?= =?us-ascii?Q?1OgF2QE5bkwv4udSBmZ3PJJpNe8Jx34qulLRA6NbE36Bhp2+LcpQ8vi0FFlL?= =?us-ascii?Q?GpVGiRjajxqeRy5Ni5lhzGD/qRQvFqDEDvR3gDUvdwdoM2IYXDWmWXyKYudM?= =?us-ascii?Q?lfMdTlCXTAbIN9O8612TnoY3jfrrHujfnn+08pVKuR4L7IurSkmkIezKENEs?= =?us-ascii?Q?IokJRSdFsFII7LwDCE0EVAcA2ZuO9gtbSyQiUGbSGI+oHY/Az8oLxWens163?= =?us-ascii?Q?zxsbDElxWHQabQtPCC3i0DeVhj/L8mhoACAevK6bTsGn6yl7dW8ZMaUjzXeP?= =?us-ascii?Q?YcvoyPj767y0L/e1JVHINbiG?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR05MB531649CDEF0008E96B88C61CAEAF9BL0PR05MB5316namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4d92cc3f-1285-40ff-379b-08d98831cbb6 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2021 18:56:10.0508 (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: lQeeLza2U8YBA3Y6o5/QBCcERxt2CuT4YfjwSHx+qy88RjiJflxWsP5p3tXxbB5EHQ9nyItrt4lOqxA9vQpTNQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5139 X-Proofpoint-ORIG-GUID: ULwWwgjExybQFNN1JvlaVcOb_rfIj8IZ X-Proofpoint-GUID: ULwWwgjExybQFNN1JvlaVcOb_rfIj8IZ X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-05_03,2021-10-04_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 mlxlogscore=999 bulkscore=0 adultscore=0 clxscore=1015 impostorscore=0 spamscore=0 mlxscore=0 phishscore=0 lowpriorityscore=0 priorityscore=1501 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110050111 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-rv6-srh-compression/ 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, 05 Oct 2021 18:56:37 -0000 --_000_BL0PR05MB531649CDEF0008E96B88C61CAEAF9BL0PR05MB5316namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim, The call for adoption has already been posted. There is no way to put that = toothpaste back into its tube. However, I strongly recommend against such c= alls for adoption in the future. Normally, the authors of a document are encouraged to answer technical ques= tions as a condition of adoption. Bullet points 1, 2, and 4 in the call for= adoption defer that requirement until WG last call. Could this be why tech= nical questions are not being addressed during the call for adoption. In some extreme conditions, it may be necessary to modify the usual call fo= r adoption procedure. But these exceptional conditions have not been articu= lated. It is unfortunate that two of the three working group chairs are also co-au= thors of the draft. While there may not have been any impropriety, the appe= arance of impropriety is difficult to avoid. = Ron Juniper Business Use Only From: spring On Behalf Of James Guichard Sent: Monday, October 4, 2021 11:10 AM To: EXT-Andrew.Alston@liquidtelecom.com ; = SPRING WG Cc: spring-chairs@ietf.org Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ [External Email. Be cautious of content] Andrew, As stated in our email of September 9th, the chairs communicated that the w= orking group reached rough (quite clear) consensus for standardizing one da= ta plane solution to compress segment routing over IPv6. In addition to thi= s there was an inclination toward using the CSID document as the basis for = our work in this area. The chairs recognized that there was however disagre= ement as to whether this document, having multiple SRv6 EndPoint behaviors,= could be considered consistent with the working group consensus for a sing= le data plane solution. This issue quite clearly needed to be addressed, an= d the chairs, recognizing that the working group is keen to make progress i= n this area, had the option of trying to resolve the issue prior to issuing= an adoption call, or give the working group the opportunity to express the= ir opinions as part of a call for adoption. Those who feel that we need to resolve the consistency issue before adoptio= n, as with those who think this is not a good basis for the WG work, are fr= ee and expected to object to the WG adopting the document. That is distinct= from objecting to the chairs issuing the adoption call. In essence, the chairs have combined the question of when to resolve consis= tency and the question of whether this document is a good basis for the WG = into one call. Yours, Jim, Bruno & Joel From: Andrew Alston > Sent: Friday, October 1, 2021 4:21 PM To: James Guichard >; SPRING WG > Cc: spring-chairs@ietf.org Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/draft-fi= lsfilscheng-spring-srv6-srh-compression/ Sorry - but - I'm a little confused here. Because the way I look at this - the working group clearly stated that they= wished for a single behavior - and this - does not deliver that - it is tw= o separate behaviors. As such - I see this call for adoption - irrespectiv= e of the merits or lack thereof of the draft, as a clear defiance of the st= ated will of the working group. This is simply does not fit into the definition of bottom up approach in my= opinion - and if this is the way that the chairs wish to proceed - then th= e only way to do that and still fit within the bottom up approach is to fir= st ask this working group for its consensus to deviate from the single beha= cvior approach that the working group agreed to. As such - I must strongly and unequivocally object to this call for adopti= on Andrew From: spring > on b= ehalf of James Guichard > Date: Friday, 1 October 2021 at 17:05 To: SPRING WG > Cc: spring-chairs@ietf.org > Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as = the basis for its compression standardization work. That is part of what th= is email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as f= ollows. By expressing support for adoption of this document you are fully a= ware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_BL0PR05MB531649CDEF0008E96B88C61CAEAF9BL0PR05MB5316namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jim,

 

The call for adopti= on has already been posted. There is no way to put that toothpaste back int= o its tube. However, I strongly recommend against such calls for adoption i= n the future.

 

Normally, the autho= rs of a document are encouraged to answer technical questions as a conditio= n of adoption. Bullet points 1, 2, and 4 in the call for adoption defer tha= t requirement until WG last call. Could this be why technical questions are not being addressed during the call fo= r adoption.

 

In some extreme con= ditions, it may be necessary to modify the usual call for adoption procedur= e. But these exceptional conditions have not been articulated.

 

It is unfortunate t= hat two of the three working group chairs are also co-authors of the draft.= While there may not have been any impropriety, the appearance of improprie= ty is difficult to avoid.

 

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;    Ron

 

 

 

Juniper Business Use Only

From: spring <spring-bounces@ietf.org> = On Behalf Of James Guichard
Sent: Monday, October 4, 2021 11:10 AM
To: EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtele= com.com>; SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.= org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

 

<= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

 

Andrew,

 

As stated in our email of September 9th, the chairs = communicated that the working group reached rough (quite clear) consensus f= or standardizing one data plane solution to compress segment routing over I= Pv6. In addition to this there was an inclination toward using the CSID document as the basis for our work in= this area. The chairs recognized that there was however disagreement as to= whether this document, having multiple SRv6 EndPoint behaviors, could be c= onsidered consistent with the working group consensus for a single data plane solution. This issue quite clearly= needed to be addressed, and the chairs, recognizing that the working group= is keen to make progress in this area, had the option of trying to resolve= the issue prior to issuing an adoption call, or give the working group the opportunity to express their opinions = as part of a call for adoption.

 

Those who feel that we need to resolve the consisten= cy issue before adoption, as with those who think this is not a good basis = for the WG work, are free and expected to object to the WG adopting the doc= ument. That is distinct from objecting to the chairs issuing the adoption call.

 

In essence, the chairs have combined the question of= when to resolve consistency and the question of whether this document is a= good basis for the WG into one call.

 

Yours,

 

Jim, Bruno & Joel

 

 

From: Andrew Alston <Andrew.Alston@liquidtelecom.com>
Sent: Friday, October 1, 2021 4:21 PM
To: James Guichard <james.n.guichard@futurewei.com>; SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org=
Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/

 

Sorry – but – I’m a little confuse= d here.

 

Because the way I look at this – the working g= roup clearly stated that they wished for a single behavior – and this= – does not deliver that – it is two separate behaviors.  = As such – I see this call for adoption – irrespective of the me= rits or lack thereof of the draft, as a clear defiance of the stated will of th= e working group.

 

This is simply does not fit into the definition of b= ottom up approach in my opinion – and if this is the way that the cha= irs wish to proceed – then the only way to do that and still fit with= in the bottom up approach is to first ask this working group for its consensus to deviate from the single behacvior appro= ach that the working group agreed to.

 

As such – I must  strongly and unequivoca= lly object to this call for adoption

 

Andrew

 

From: spring <<= a href=3D"mailto:spring-bounces@ietf.org">= spring-bounces@ietf.org> on behalf of James Guichard <james.n.guichard@fu= turewei.com>
Date: Friday, 1 October 2021 at 17:05
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org <= spring-chairs@ietf.org>
Subject: [spring] WG Adoption call for https://dat= atracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

 

The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

 

The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors.
  2. The document is a “living” document; it m= ay change as it goes through review and analysis by the SPRING working grou= p.
  3. All open discussion points raised on our mailing list= MUST be addressed BEFORE said document is allowed to progress from the wor= king group to publication. A list of these discussion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
  4. If this document is adopted by the working group, the= chairs specify as part of the adoption call that the following text descri= bing an open issue be added to the document in the above-described open issues section:
    • "Given th= at the working group has said that it wants to standardize one data plane s= olution, and given that the document contains multiple SRv6 EndPoint behavi= ors that some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

 

Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

--_000_BL0PR05MB531649CDEF0008E96B88C61CAEAF9BL0PR05MB5316namp_-- From nobody Tue Oct 5 11:58:24 2021 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 EF7903A0889; Tue, 5 Oct 2021 11:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 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, 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=EXa9RF60; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=NAYLtiWV 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 k-J4hCelHjXY; Tue, 5 Oct 2021 11:58:17 -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 CD46B3A0888; Tue, 5 Oct 2021 11:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15240; q=dns/txt; s=iport; t=1633460296; x=1634669896; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aXk8HAe8L3FXt5/yB4g8b3jPqXTN6AoZ41oPrsU3Yf4=; b=EXa9RF60iPYaHMfECn4ALLQHdk5J07gL2Ekt0VuytW1yOLrV62bWqv7H F9+NVAHPX7YEhJoFkFvcVj7oANMt8y52GgoHs5K6OaIq9BZJD0DMhLvxK lzF7v0QfN0MCE0SDFMlcEBIE7+blCOyiuTD4Oq1G5ErtRcLDgOxYmP32L E=; IronPort-PHdr: =?us-ascii?q?A9a23=3As92XvhOulwW0Cb7fSKcl6nfjWUAX0o4cdiYZ7?= =?us-ascii?q?5M9gPRPf7ituZP4Mx+X6fZsiQrPWoPWo7JBhvHNuq/tEWoH/d6asX8EfZANM?= =?us-ascii?q?n1NicgfkwE6RsLQD0r9Ia3maiUgF4JDWUNruXahPhsdFMP3fVaHpHq04HYbE?= =?us-ascii?q?Qn+MgwgIOPzF8bSgs272vr09YfUZlBDhSG2ZvV5KxDlxTg=3D?= IronPort-Data: =?us-ascii?q?A9a23=3ArXFeW6lrEXNGZbsguyn/5zzo5gx8JERdPkR7X?= =?us-ascii?q?Q2eYbSJt1+Wr1GztxIaXm2APvzcZjbwKYt/YNng/UlUucOEx9MwTAY6+HxhQ?= =?us-ascii?q?VtH+JHPbTi7wugcHM8zwvUuxyuL1u1GAjX7BJ1yHiK0SiuFaOC79CAkjfzQH?= =?us-ascii?q?NIQNcadUsxPbV48IMseoUoLd94R2uaEsPDha++/kYqaT/73YDdJ7wVJ3lc8s?= =?us-ascii?q?Mpvnv/AUMPa41v0tnRmDRxCUcS3e3M9VPrzLonpR5f0rxU9IwK0ewrD5OnRE?= =?us-ascii?q?mLx5RwhDJaulaz2NxZMSb/JNg/IgX1TM0SgqkEd/WppjeBqb7xFNBs/Zzahx?= =?us-ascii?q?7idzP1VvpW1QB0oOoXHmf8WVF9TFCQW0ahuqeaZcSbk7ZzLp6HBWz62qxl0N?= =?us-ascii?q?2ktJZcZ/OkyCmFH9OYDADEAch7FgPi5qJqgUvNtgMsLLcT3MsUYoH4I5TPQC?= =?us-ascii?q?Ps9B5aFTLjL7t9RxjsYiN1SAOzTeMcYLzFoaXzoeRdIPFYcAcdixOW1gHjnf?= =?us-ascii?q?icerl+JjaYy6nLYig18zLarN8DaEuFm7+09cl2wvGnK+SHyBQsXcYfZwjue+?= =?us-ascii?q?XXqjejK9R4Xkbk6TNWQnsOGSnXPmDZ75MUqaGaG?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AYIDqSKyHFJl6C143+HBFKrPxdegkLtp133?= =?us-ascii?q?Aq2lEZdPULSK2lfpGV8sjziyWatN9IYgBepTiBUJPwJk80hqQFn7X5XI3SHD?= =?us-ascii?q?UO3VHJEGgM1/qY/9SNIVyaygcZ79YdT0EcMqyyMbEZt7eB3ODQKb9Jq7PrnN?= =?us-ascii?q?HK9IXjJjVWPHxXgspbnmFE43OgYzVLrX59dOME/fSnl656jgvlXU5SQtWwB3?= =?us-ascii?q?EDUeSGjcbMjojabRkPAANiwBWSjBuzgYSKUSSw71M7aXdi0L0i+W/Kn0jS/a?= =?us-ascii?q?O4qcy2zRfayiv684lWot380dFObfb8z/T9aw+czjpAVr4RHYFqjwpF+d1HL2?= =?us-ascii?q?xayOUkli1QePibLUmhJV1d7yGdgTUImwxemkMKgWXo8UcL5/aJGQ7Tz6F69N?= =?us-ascii?q?1kmtyz0Tt9gDg06tM444qU2qAnfi/ojWDz4cPFWAptkVfxqX0+kfQLh3gaSo?= =?us-ascii?q?cGbqRNxLZvsH+9Pa1wVh4S0rpXXdWGzfusksp+YBefdTTUr2NvyNujUjA6GQ?= =?us-ascii?q?qHWFELvoiQ3yJNlH50wkMEzIhH901wuq4VWt1B/aDJI65onLZBQosfar98Hv?= =?us-ascii?q?4IRY+yBnbWSRzBPWqOKRDsFb0BOXjKt5nriY9Fq92CadgN1t8/iZ7BWFRXuS?= =?us-ascii?q?o7fF/vE9SH2NlR/hXEUAyGLH/QIwFlltBEU5jHNfvW2AG4OSQTevqb0rwi65?= =?us-ascii?q?fgKoOO0bptcojeEVc=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CEAAAmn1xh/5pdJa1aHQEBAQEJARI?= =?us-ascii?q?BBQUBggUIAQsBgSAwUQd3Dkw3MYRHg0gDhFlgiAgDlWaFBoEugSUDVAMIAQE?= =?us-ascii?q?BDQEBNwoEAQGEfQIXgi0CJTQJDgECBAEBARIBAQUBAQECAQYEgREThWgNhkI?= =?us-ascii?q?BAQEBAxILBgoTAQE3AQ8CAQYCEQQBASQEAwICAjAUCQgBAQQBDQUIEweCUIF?= =?us-ascii?q?+VwMvAQ6WE481AYE6AoofeoExgQGCCAEBBgQEgUpBgn8YgjUDBoE6AYJ/hBM?= =?us-ascii?q?BAYZwJxyBSUSBFUOCZz6CYwICAYFfKwmCYjeCDCKKGhGBRQRTBJgEiHONS5I?= =?us-ascii?q?qCoMwikSUPRSnDYcTjxKMSZhyAgQCBAUCDgEBBoFhO4FZcBWDJFEZD44gDBY?= =?us-ascii?q?VGYMihRSFSnQCNgIDAwEKAQEDCZVxAQE?= X-IronPort-AV: E=Sophos;i="5.85,349,1624320000"; d="scan'208,217";a="916863480" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Oct 2021 18:57:59 +0000 Received: from mail.cisco.com (xbe-aln-007.cisco.com [173.36.7.22]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 195IvxvF025934 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 5 Oct 2021 18:57:59 GMT Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xbe-aln-007.cisco.com (173.36.7.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 5 Oct 2021 13:57:59 -0500 Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 5 Oct 2021 13:57:58 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Tue, 5 Oct 2021 13:57:58 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Cg1s15zox2pLgYiYwHFVjl9go8MC9Ar5Thc797D7dqN91Wc8Ar8Q8/nML4VwsXZrwICthvRi11zXEgu8ZygU8Usr0KmYo/MtmAtr+isBRY1TAJhIXDYCXr0KC1XA1BwBManUajmKhanO1MYy844DCrL8JKHMjAIUDppalX7n0h6nLp8b6MNKPWpJ3pYKdUtbUuicEpzdac8HkxcgjGf0fOZgAEqW0ectDIZW1c4k1BR6gOfcy59zstPEJUuvEHvpHnhCrMFczS3vj82wNboQmnIGcFCiXgjBoEhOSWkLDxGqkjm2u6WIclGEn5BwQfMA9r0l0ddua6TavdXl83bDlQ== 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=aXk8HAe8L3FXt5/yB4g8b3jPqXTN6AoZ41oPrsU3Yf4=; b=AOi+BfMsmT7dLOSBYKB3487GbBSils5dRT21tgUNc9qnANM78Qy1hYd88/Tivg0IHTVD5gkt7qncz98h0rxaW5vJuGJYM0HrFfzpxZAc+fu8UKHo9FBPA3WrLjTfS7R6bC8dLCQkxFWjZPJWihc2lECt64mfJUPiYWpYtgB1yCuw3gX7qAP8LirbLspT7TWu/fbKKmWEyc0UskSzc+dQ2GedmX8OrqiX3uFhGNb92h+hV9aSUy5EGYimK3AwCtA8mmCmK/ubhOoZln1M7yY83asFmna2qWOQKLrTSJ+sxsDMtEAiKW/mp/0XVvoJ6y1QOfGBFlvX/zvMdja5WioZJQ== 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=aXk8HAe8L3FXt5/yB4g8b3jPqXTN6AoZ41oPrsU3Yf4=; b=NAYLtiWVdazqnEiWzuBR9qxgWulNkMqRzKVEAoQDwfFYDSOzBW5U5oQKSgMa/0KfAsM5A+btnV5V4lBZJPV2LEQMQ1FnrCPuUSj9S1k+oSQCH+ylqFPh1F5Uk4V4hBd93OcqGdx+EDh2luzCdiJoWLVyH2qdnXiEdwiIOvf/7UA= Received: from BN0PR11MB5726.namprd11.prod.outlook.com (2603:10b6:408:161::19) by BN6PR11MB1553.namprd11.prod.outlook.com (2603:10b6:405:e::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.18; Tue, 5 Oct 2021 18:57:55 +0000 Received: from BN0PR11MB5726.namprd11.prod.outlook.com ([fe80::6d7b:27b0:b24b:9553]) by BN0PR11MB5726.namprd11.prod.outlook.com ([fe80::6d7b:27b0:b24b:9553%4]) with mapi id 15.20.4566.022; Tue, 5 Oct 2021 18:57:55 +0000 From: "Pablo Camarillo (pcamaril)" To: Ron Bonica , James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQCeJTAAAC58nBAAAQ3tgA== Date: Tue, 5 Oct 2021 18:57:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-05T15:38:08Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=5ac9bcaf-2ea1-4176-a003-8ffbeafbebdf; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none;dmarc.ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 683cb084-ec6e-4dcf-0f45-08d988320a56 x-ms-traffictypediagnostic: BN6PR11MB1553: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:5516; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DnknL4dt7s8pFbx3sxvHGJz8PEYyrOScEVAsg9dKAWBOfhgQiu1kdSbQql7qJQDcFU5ZiNLAxLaQwJird3VYSg3vdwh7nYGpf1cEdZXgT0zl7RqKPcoSTKIkAuIRnk7oy2mEzgxCEKHh0mB0sNJflxI9ydZCpR0uzWTaxwAlYJCZo7+spC3GI69/isMr5FsB+dqYF7ZVqdSUCdrZX4f3XlQE9M2akUb32+rLFQuDDjFNkkUi/V3ckgmKSIo6skMPN/KmEfZH9nOyuOFj8mRj0F+s2hEf+tdjzG7RnUxA/97bFUPjsDIT15bzokxEd1iyYKNlT0pwSrCfj+S9ZWWFY+scxBUpEo8h4xByBR1yzn52ZZbR+i2QvkDU1Aa/P4eZq96PIwP6NYlzt6oSgyuu0OZDKenCLBeOSzanZbqlqYbkShrVtiF6aWk84hgR92Pb+bt6W060TiQLRyqYATWMcizPuH0/WqcfwdBJrtISgRD3JD7x2JjzysWMwCzwgULXbaPnwqGdrABKshkwNASAExLf7OkG+phrM9QRE+AEk0EhBPKfA56BBN6LsMjReeEGcXU3CsjabhqnJO3ptnN6bS8VHPbG2uP6V4GESV302jn1izF3wMu3xZ4J0QgIPQ/yuoPPx6InVb37k6rDp7UOZk7M17YXoRMgloASfyoeNh4J84k6o81BpfkxOy9H8AlmP7JgVgDDZYE7GAS94HFMUKCJegNwIAUcqpuP8TTqakOYNGy6hb5CIHwRaHZ1dM7rDsjmIX19PBD8TG1q9+4JzhajwWv7uIYBKOZCtqtdhWs= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN0PR11MB5726.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(2906002)(122000001)(38100700002)(83380400001)(7696005)(76116006)(9686003)(26005)(186003)(52536014)(71200400001)(38070700005)(8936002)(316002)(4326008)(8676002)(110136005)(6506007)(5660300002)(966005)(55016002)(66946007)(166002)(33656002)(66476007)(66556008)(64756008)(66446008)(508600001)(53546011)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WGtlWVN5enNML3NtdzlhVkhyQ1IvM3M3K2F0UTlGWGNrY2dNaE5ENTN0QWtw?= =?utf-8?B?NUhheU54UUZmUVFIRlVzNkdpMXI1eUlmdnJ0WlA0aE82ZDRhLzM1OTVTcmdY?= =?utf-8?B?NVI4UGpJb2RMaXVZaU5CaVI1OGNHUzQyQitha0RTTzNwc1ZiZkppM2pCb2E2?= =?utf-8?B?ejhaRHRWcS9aL0FaOGdjVm5NVkJxays0dEFaSWxOci85c2dpVEJURE02S0Fk?= =?utf-8?B?SkpmS1RucWZwakRIWWxJVVQweTZaRTFiSlE0eFFhb2NuQVVvWjJET3lOajdl?= =?utf-8?B?ZFBJZ3A2RWRsY0hueDZlMmdzL0lWSElWYnEyV2NSSThCb3dPQzF3b2tUV0hn?= =?utf-8?B?eGVSZzlIaUE0WHpGZXFVbTViT2VmNFpWMllKSjN6YlRSbkZNY1RWeUtvV0lK?= =?utf-8?B?d1ZIOFF6dlZ6OVdiWVh5OTFYYytyR2pWZlpheWxYMi8yUEMzSjRCRnBkQ1gz?= =?utf-8?B?ZktWZ2V6UDMxbGRGYlV3YUlIaDJ2akFYS25CZ2w2MG5RYm13OUFKZHlOdUZB?= =?utf-8?B?L1NpdVBoWjdBRDIrVXdiNlkzZ0loNlFHYk5GdXp3U0dYWWVjUmRyVFdvejJN?= =?utf-8?B?ZnV2ZXY2RlZORy9xVTZWdW13U212VEw3b0JXWUVqMGhkQTdIMW4xaVJZWUla?= =?utf-8?B?Z1VtYWRhaENEellTVFBONjIwVkZoL0hoQVJZSCtzTjZEVDUwUE9ycXB4K1o5?= =?utf-8?B?aXk2a1Bwby9RTUlCLzBjRG9TcVdnWmVHdmFaS3RvMkhDSVBpc1BMb1Yyajcy?= =?utf-8?B?L0wzQlIyK1dod096anlGaURwYnMzZzJaWlgzNDJvUFdKS3duYmp5YVRMb0N4?= =?utf-8?B?SVhSNWpEM2xjZStza2plSzQ2dEZ1VHlZa1RmcjJ4UE04b3RxM0RkaThaTndv?= =?utf-8?B?aDZLWTNlRGZDb2lENnlqekFjQmxtSEpQb0ZWZG92M3N3N1V1MSt6eGp3YTZy?= =?utf-8?B?eGdrYVZGRms4a2YrbVJGVXJGZHNHVllDb0tLbktDVk4yMHB1dzBhT3lTUVMr?= =?utf-8?B?SnA5d3plMWg2RWsxU05pY01iWnJCZWluTTZvN1AxUTVGSFZVUlVCZS8zZ1Nr?= =?utf-8?B?dUNlZHNzV1JTWHdTSFQxd1JPQTNZcDdmZGlkRjZ1eUY1QWJlVnlmQStHMC9G?= =?utf-8?B?WHZDeTBGbElJOHpCaXdRVFYwU1JqYkZGTTc5RHpackVMWCtsa1VzTDVRODF6?= =?utf-8?B?dUtiQkczNzBYTWcvajFOU1l3WFAvVVo1T1BrZ3RROWVBYk11STArR1BSS0pG?= =?utf-8?B?cHpxeGtFekdkSDBMZHRwUXdHMHZiMlVwdFRaRTZkWnNGTk9xbG41ZzM4b0ha?= =?utf-8?B?VnBZVHVGdm9FRER3LzVTSDlzQy96bllsbnZhdUkvSG1mN3M5ZVlrZXJaWWNz?= =?utf-8?B?Z3NhbzVYRkRtaC9IUm1hSkJlWnIxdGhkQnFMY09IV2x0Zm9RazN6c3NNanpo?= =?utf-8?B?NmMvNmdzVktRT3dqSDFQd3g4SmNPTFZZaFR4TUhqWXZkM1NyL1NYcXJ6TW5r?= =?utf-8?B?TllnV2xxekc3L2RhclI2RzFZK2hkRDdOQlljd0hYdjcrUFQxS3pRY01qS3lV?= =?utf-8?B?OXlLdER0aFJFaWRlNkJucTE0VHZSSnJGTHFUL2djV1lxMTdmT2NyVmc1bmt1?= =?utf-8?B?RDhKQWRTL3lKNVV2KytWcmNaUHdscm1UVyt5T1pKS09FdC9vMURCYnlhTk0w?= =?utf-8?B?WXd1YzdnVzFnTGlQSGRhMUJ5Z1ZHNjBFdnlRc1MvSHRVSlRaeWJCU0hKR2dS?= =?utf-8?Q?ilacekNjo6rdP2JpMagOILDoUF/fR6xeufG9LlS?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN0PR11MB57263566709BA15200E44CBAC9AF9BN0PR11MB5726namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN0PR11MB5726.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 683cb084-ec6e-4dcf-0f45-08d988320a56 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2021 18:57:55.0132 (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: Hz1iJOMpcVGdYJnQ3u7I1/aYmIPo/8e7OOYvOLDGMBqGPWjwPYkjTrsqZtjFp1j3VRF2sG227UH9MJJr1wlDmw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1553 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.22, xbe-aln-007.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 05 Oct 2021 18:58:23 -0000 --_000_BN0PR11MB57263566709BA15200E44CBAC9AF9BN0PR11MB5726namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9uLA0KDQpJIGJlbGlldmUgeW91ciBzdGF0ZW1lbnQgaXMgd3JvbmcuIFRoZSBXRyBoYXMgZXhw cmVzc2VkIHN0cm9uZyBwcmVmZXJlbmNlIGZvciBhIHNpbmdsZSBkYXRhIHBsYW5lIHNvbHV0aW9u Lg0KDQpGcm9tIHRoZSBjaGFpcnMgZW1haWxzOg0K4oCcR2l2ZW4gdGhhdCB0aGUgd29ya2luZyBn cm91cCBoYXMgc2FpZCB0aGF0IGl0IHdhbnRzIHRvIHN0YW5kYXJkaXplIG9uZSBkYXRhIHBsYW5l IHNvbHV0aW9uIOKApuKAnQ0K4oCcVGhlcmUgaXMgYSByb3VnaCAocXVpdGUgY2xlYXIpIGNvbnNl bnN1cyBmb3Igc3RhbmRhcmRpemluZyBvbmUgZGF0YXBsYW5lIHNvbHV0aW9u4oCm4oCdDQoNCkkg aG9wZSB3ZSBhbGwgYWdyZWUgdGhhdCBSRkM4OTg2IGlzIG5vdCBkZWZpbmluZyAzNiBkaWZmZXJl bnQgZGF0YXBsYW5lIHNvbHV0aW9ucy4g8J+YiQ0KDQpDaGVlcnMsDQpQYWJsby4NCg0KRnJvbTog Um9uIEJvbmljYSA8cmJvbmljYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPg0KU2VudDog bWFydGVzLCA1IGRlIG9jdHVicmUgZGUgMjAyMSAxNzozOA0KVG86IFBhYmxvIENhbWFyaWxsbyAo cGNhbWFyaWwpIDxwY2FtYXJpbEBjaXNjby5jb20+OyBKYW1lcyBHdWljaGFyZCA8amFtZXMubi5n dWljaGFyZEBmdXR1cmV3ZWkuY29tPjsgU1BSSU5HIFdHIDxzcHJpbmdAaWV0Zi5vcmc+DQpDYzog c3ByaW5nLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogUkU6IFdHIEFkb3B0aW9uIGNhbGwgZm9y IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3By aW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLw0KDQpQYWJsbywNCg0KVGhlIFdHIGhhcyBleHByZXNz ZWQgYSBzdHJvbmcgcHJlZmVyZW5jZSBmb3IgaGF2aW5nIGEgc2luZ2xlIGNvbXByZXNzaW9uICpi ZWhhdmlvciouIFdoeSBpcyBpdCBPSyB0byBpZ25vcmUgdGhhdCBwcmVmZXJlbmNlIGJlY2F1c2Ug UkZDIDg5ODYgaGFzIDM2IGRpZmZlcmVudCBiZWhhdmlvcnM/DQoNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJv bg0KDQoNCg0KDQpKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQpGcm9tOiBzcHJpbmcgPHNwcmlu Zy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4+IE9uIEJl aGFsZiBPZiBQYWJsbyBDYW1hcmlsbG8gKHBjYW1hcmlsKQ0KU2VudDogTW9uZGF5LCBPY3RvYmVy IDQsIDIwMjEgMTozMiBQTQ0KVG86IEphbWVzIEd1aWNoYXJkIDxqYW1lcy5uLmd1aWNoYXJkQGZ1 dHVyZXdlaS5jb208bWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbT4+OyBTUFJJ TkcgV0cgPHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPj4NCkNjOiBzcHJp bmctY2hhaXJzQGlldGYub3JnPG1haWx0bzpzcHJpbmctY2hhaXJzQGlldGYub3JnPg0KU3ViamVj dDogUmU6IFtzcHJpbmddIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNz aW9uLw0KDQoNClJGQzg5ODYgYWxyZWFkeSBkZWZpbmVzIDM2IGRpZmZlcmVudCBiZWhhdmlvcnMu DQoNClRoaXMgZG9jdW1lbnQsIENTSUQsIGlzIGEgc2luZ2xlIFNSdjYtYmFzZWQgc29sdXRpb24g dGhhdCBvbmx5IGRlZmluZXMgYWRkaXRpb25hbCBiZWhhdmlvcnMgd2l0aCB0aGUgbmV4dCBhbmQg cmVwbGFjZSBmbGF2b3JzLg0KDQoNCg0K --_000_BN0PR11MB57263566709BA15200E44CBAC9AF9BN0PR11MB5726namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgRW1vamkiOw0KCXBhbm9z ZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNl Z29lIFVJIjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu cGFyYWdyYXBoLCBsaS5wYXJhZ3JhcGgsIGRpdi5wYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLW5hbWU6 cGFyYWdyYXBoOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5tc2lw Zm9vdGVyMzBiM2Q1MzgsIGxpLm1zaXBmb290ZXIzMGIzZDUzOCwgZGl2Lm1zaXBmb290ZXIzMGIz ZDUzOA0KCXttc28tc3R5bGUtbmFtZTptc2lwZm9vdGVyMzBiM2Q1Mzg7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLm5vcm1hbHRleHRydW4NCgl7bXNvLXN0eWxl LW5hbWU6bm9ybWFsdGV4dHJ1bjt9DQpzcGFuLmVvcA0KCXttc28tc3R5bGUtbmFtZTplb3A7fQ0K c3Bhbi5FbWFpbFN0eWxlMjQNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCXBv c2l0aW9uOnJlbGF0aXZlOw0KCXRvcDowcHQ7DQoJbXNvLXRleHQtcmFpc2U6MHB0Ow0KCWxldHRl ci1zcGFjaW5nOjBwdDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFw OmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVMiPlJvbiwmbmJzcDsgPG86cD4NCjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGJlbGll dmUgeW91ciBzdGF0ZW1lbnQgaXMgd3JvbmcuIFRoZSBXRyBoYXMgZXhwcmVzc2VkIHN0cm9uZyBw cmVmZXJlbmNlIGZvciBhIHNpbmdsZSBkYXRhIHBsYW5lIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkZyb20gdGhlIGNoYWlycyBlbWFpbHM6DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj7igJxHaXZlbiB0aGF0IHRoZSB3b3JraW5nIGdy b3VwIGhhcyBzYWlkIHRoYXQgaXQgd2FudHMgdG8gc3RhbmRhcmRpemUgb25lIGRhdGEgcGxhbmUg c29sdXRpb24g4oCm4oCdDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij7igJxUaGVyZSBpcyBhIHJvdWdoIChxdWl0ZSBjbGVhcikgY29uc2Vuc3VzIGZvciBzdGFuZGFy ZGl6aW5nIG9uZSBkYXRhcGxhbmUgc29sdXRpb27igKbigJ0NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkkgaG9wZSB3ZSBhbGwgYWdyZWUgdGhhdCBSRkM4OTg2IGlzIG5vdCBkZWZp bmluZyAzNiBkaWZmZXJlbnQgZGF0YXBsYW5lIHNvbHV0aW9ucy4NCjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LHNh bnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiYjMTI4NTIxOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkNoZWVycywNCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlBhYmxvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJF Ti1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gUm9uIEJvbmljYSAmbHQ7 cmJvbmljYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnJmd0Ow0KPGJyPg0KPGI+U2VudDo8 L2I+IG1hcnRlcywgNSBkZSBvY3R1YnJlIGRlIDIwMjEgMTc6Mzg8YnI+DQo8Yj5Ubzo8L2I+IFBh YmxvIENhbWFyaWxsbyAocGNhbWFyaWwpICZsdDtwY2FtYXJpbEBjaXNjby5jb20mZ3Q7OyBKYW1l cyBHdWljaGFyZCAmbHQ7amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tJmd0OzsgU1BSSU5H IFdHICZsdDtzcHJpbmdAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBzcHJpbmctY2hhaXJz QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBXRyBBZG9wdGlvbiBjYWxsIGZvciBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmlu Zy1zcnY2LXNyaC1jb21wcmVzc2lvbi88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+UGFibG8sPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTQuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPlRoZSBXRyBoYXMg ZXhwcmVzc2VkIGEgc3Ryb25nIHByZWZlcmVuY2UgZm9yIGhhdmluZyBhIHNpbmdsZSBjb21wcmVz c2lvbiAqPGI+YmVoYXZpb3I8L2I+Ki4gV2h5IGlzIGl0IE9LIHRvIGlnbm9yZSB0aGF0IHByZWZl cmVuY2UgYmVjYXVzZSBSRkMgODk4NiBoYXMgMzYgZGlmZmVyZW50IGJlaGF2aW9ycz88bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0 LjBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJvbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjE0LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Im1zaXBmb290ZXIz MGIzZDUzOCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbjowY207dGV4dC1hbGlnbjpjZW50 ZXIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6Ymxh Y2siPkp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHk8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIGxhbmc9IkVOLVVTIj4gc3ByaW5nICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNw cmluZy1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBsYW5nPSJFTi1VUyI+c3ByaW5nLWJvdW5jZXNA aWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7DQo8Yj5PbiBCZWhhbGYg T2YgPC9iPlBhYmxvIENhbWFyaWxsbyAocGNhbWFyaWwpPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRh eSwgT2N0b2JlciA0LCAyMDIxIDE6MzIgUE08YnI+DQo8Yj5Ubzo8L2I+IEphbWVzIEd1aWNoYXJk ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNv bSI+PHNwYW4gbGFuZz0iRU4tVVMiPmphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbTwvc3Bh bj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDs7IFNQUklORyBXRyAmbHQ7PC9zcGFuPjxhIGhy ZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPjxzcGFuIGxhbmc9IkVOLVVTIj5zcHJpbmdAaWV0 Zi5vcmc8L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVTIj4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1jaGFpcnNAaWV0Zi5vcmciPjxzcGFuIGxhbmc9 IkVOLVVTIj5zcHJpbmctY2hhaXJzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1V UyI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBXRyBBZG9wdGlvbiBjYWxsIGZv ciA8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt Zmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vIj48c3BhbiBsYW5nPSJF Ti1VUyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVu Zy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vPC9zcGFuPjwvYT48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9InBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbjowY207dmVydGljYWwtYWxp Z246YmFzZWxpbmUiPjxzcGFuIGNsYXNzPSJub3JtYWx0ZXh0cnVuIj48c3BhbiBsYW5nPSJFTi1V UyI+UkZDODk4NiBhbHJlYWR5IGRlZmluZXMgMzYgZGlmZmVyZW50Jm5ic3A7YmVoYXZpb3JzLjwv c3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImVvcCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9InBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbjowY207dmVydGljYWwt YWxpZ246YmFzZWxpbmUiPjxzcGFuIGNsYXNzPSJub3JtYWx0ZXh0cnVuIj48c3BhbiBsYW5nPSJF Ti1VUyI+VGhpcyBkb2N1bWVudCwgQ1NJRCwgaXMgYSBzaW5nbGUgU1J2Ni1iYXNlZCBzb2x1dGlv biB0aGF0Jm5ic3A7b25seSZuYnNwO2RlZmluZXMgYWRkaXRpb25hbCBiZWhhdmlvcnMgd2l0aCB0 aGUgbmV4dCBhbmQgcmVwbGFjZSBmbGF2b3JzLjwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImVv cCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9InBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbjowY207dmVydGljYWwtYWxpZ246YmFzZWxpbmU7dXNlci1zZWxlY3Q6 IHRleHQ7LXdlYmtpdC11c2VyLWRyYWc6IG5vbmU7LXdlYmtpdC10YXAtaGlnaGxpZ2h0LWNvbG9y OiB0cmFuc3BhcmVudDtvdmVyZmxvdy13cmFwOiBicmVhay13b3JkO2ZvbnQta2VybmluZzogbm9u ZSI+DQo8c3BhbiBjbGFzcz0iZW9wIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9zcGFuPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0idXNlci1zZWxlY3Q6IHRleHQ7LXdlYmtpdC11 c2VyLWRyYWc6IG5vbmU7LXdlYmtpdC10YXAtaGlnaGxpZ2h0LWNvbG9yOiB0cmFuc3BhcmVudDtv dmVyZmxvdy13cmFwOiBicmVhay13b3JkO2ZvbnQta2VybmluZzogbm9uZSI+DQo8c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_BN0PR11MB57263566709BA15200E44CBAC9AF9BN0PR11MB5726namp_-- From nobody Tue Oct 5 12:43:13 2021 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 914DD3A0B45; Tue, 5 Oct 2021 12:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=WOnouglF; dkim=pass (1024-bit key) header.d=juniper.net header.b=V4uUHlFz 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 yFiBUWuqeUV7; Tue, 5 Oct 2021 12:43:05 -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 315573A0B4F; Tue, 5 Oct 2021 12:43:05 -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 SMTP id 195JAOYf025819; Tue, 5 Oct 2021 12:42:57 -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=3tpfZeDNGcXsY2ku1HrFllk3b2XZXDfIRJzJjaM8E2A=; b=WOnouglF+NH2u0XiU4bBwBD1FoHg6n+075EmbQTtgLWyX7C+qnYTHeepGWXWFmaTLfee 88hw4sgqlcnYquOycoD1QwoDwa+GECVcikQqJLkLNoXSFuOtSwtUPq36K9jvNI8ud5LS /rOxqLEB1azyv8CIxUuTj2wGirPEcMcA5oXZsE2wHxZgMwGySoDk4NpmQGCmCqvv+Vvx S+By2NNn2K+bhKRlVYaqDbu7f36Z8Qi3AQc6yWEhlj6w/65BP5MOLCEYm+7v7uK10vO2 edFUZy0/LnRDJgpKiivXq0EyA+npw3w60Urdj7HF3qAJGqbfQBAEj76bMpLnaDsysYwb 9g== Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2108.outbound.protection.outlook.com [104.47.70.108]) by mx0a-00273201.pphosted.com with ESMTP id 3bgnhmse28-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 05 Oct 2021 12:42:57 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SQmQic38PzjX9whBzOjwCQwZ5vy4StQqceiviiB216I/Wz/JOF8BMTwcq7QxuBEQTcihpSwKSheQGVsfrLFQp4zn3New0Fdy4WQc2VSGS99NwFNsLYk2JX287WoFP8bByegL0y6kv3YD3vqAyoYKyCIVP5I39SfkTASJSFsJG23WZNv1RfAlx/wJ8BI8mh4uSG+pkPj+gZvl/3Hygp9AyBNY2hNcy4uyfZF1xsHvWwyIMGEKRzN6NSrRKahd87gWysKHoCzTBj6h+/+p2jb6hB3KdmJGtPOP8gum4b6EwwRW7TxJkuO+9T9Ocxm0FQ041jiKZm5DHUXHRrLdIleZzA== 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=3tpfZeDNGcXsY2ku1HrFllk3b2XZXDfIRJzJjaM8E2A=; b=XNcamqB3uE4Q2xnIJe5vq9BfTDqSbNltDpCVLGpIKd0kfFNKEwcOuQWew3EB5CzDtbpXeRws9JNZH30pK7YAzyxg5kI//GM4k/m7Y59hmDS9S/K7vpT5aGONZ7C3W8nad+DHlLXeUsqu6EkuqSmpUa1OfJCfV5AKqjwhFJP8uhClnepF9NNPg0+D8pMbqWhxWhG32BsrP3hniioE/z7jNi1CV+HLv3OdhCH61XmXwpZx6Pk2GhbMCImLJCn1IIAQ4Lyf83XGX8yNNGz/ZEYPnpAYzp14VVwD/Ldr6vHAKay6CBGw4Tlq+MmdWLTBqtP2UmR5v33ZFbSp0eoJZAexVw== 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=3tpfZeDNGcXsY2ku1HrFllk3b2XZXDfIRJzJjaM8E2A=; b=V4uUHlFzkd+UdS+xxHDjPCVBcmgMGRbqKDWJ+iqrBl9kUE9IPcq83rNptH6mxGdt8+f9Hs1uw4p9Z6p/pkUPC619pCPh5QYhVkURry8U6avy/CRwOh/HFLHthNXRROgVxZyhhu2S5AAxcXiiPn7cpGYpFgXhU/CZlQZppTA+KX4= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by MN2PR05MB6958.namprd05.prod.outlook.com (2603:10b6:208:18f::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.12; Tue, 5 Oct 2021 19:42:55 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4587.018; Tue, 5 Oct 2021 19:42:55 +0000 From: Ron Bonica To: "Pablo Camarillo (pcamaril)" , James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQCeJTAAAC58nBAAAQ3tgAAHRGEg Date: Tue, 5 Oct 2021 19:42:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-05T19:42:53Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=5ac9bcaf-2ea1-4176-a003-8ffbeafbebdf; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2b303728-4c35-4e79-a416-08d988385381 x-ms-traffictypediagnostic: MN2PR05MB6958: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: P6oqIg4NuCljAZSJODWfvbHZZsQpBQqEN+jCQIH7vwVbppbRuN2iTxJ7D8DzkDuwv5st04PbGOviFURN4r2RPGXsEioSQofNFyIOmJzHJJyGEBEevvndUrufvAbtv8is9VNJ6AOVp+z58rRG0Rkfld0yqmOpFwtIDqsrLgG2StX+7H5/XHGMLqqxBh4Glri1zwmz69AUXcWoy36iZG917Lswf9jZ+tM+cZcEfpll9kE+F/AXjlWHIDZpPlaXkMlexaowlGj8OmE9y8WeVXCCjGufa0RGJuwmWObV+G1kfPDoB9p0lDLDcPH0AR5PVH+j/hr70P6F0QqSDbpQZZ3X3744GDLirI3ZFaFw50IWTvHmmRKWm+Bq1ZtraIRnnleahnqfsVm/d/mGYgWEboMObiO6Y16k8QOQ1ju2W0cxluWOzJZuDqM2fXZLWlJ+12FUhqMT/+zkFK5GRWV68Ech/SJoSvvACqvy/sEk/huXuKSIRO5IjjDv4FSLlIAtCJW6Ylfk4t44Ff87v8B6d49dETF9D+z4XOXnApOjXcnX+yTgrAiOv7eFelJS6im8povYEneJ+hogzGCA+Wn7nxA+vMvTH1HGvn6t5n18ijicO/vR9u6+6lvkEQlJnFPYB2DfflHjtmdFN0jygTE4ff9x0/bFEt0FP2ba+o1GH8sRCEW98Ne2g0HbEuVFMmlN9UdOQlWIg2Fd5nn8bjy09mckAHdozqRbMK9Wm0u2aDgJNqf0n5yJF4NTklU4yi4CPKUtl6JNBmFpddpPL2BFrYl9UeYpJv3P1iU938yOt36KFXA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(166002)(7696005)(316002)(9686003)(5660300002)(8676002)(2906002)(8936002)(110136005)(71200400001)(508600001)(26005)(186003)(66476007)(66446008)(64756008)(83380400001)(966005)(38100700002)(66946007)(122000001)(38070700005)(33656002)(55016002)(6506007)(53546011)(4326008)(66556008)(76116006)(86362001)(52536014); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eTVuMXg1SGM2S1h1V0pjMGx6WjN0VHJ2aU1RSGhnY0NkeitqL245RndHME5U?= =?utf-8?B?ZWM5OERvUm9DeERLSzRXMlk3emlqcGpiYkpwUlJHbThjWW9lZ09OU05heXlx?= =?utf-8?B?QUxhQU5TZGlEVlUvcnRheU9sUzBkMmJaSWUvQTFhUzV3Y202QVNhMEZxSjha?= =?utf-8?B?MzBUQ2pVaC9BMjNnQTZwTXhycERLRnZ4dk1iMTJRamZsNTl5WDVzZmp5eEQ2?= =?utf-8?B?RWlwcUxUZ3FMdkZ1OU9hTlZEN0ZXYTVtUHAyOEduSGlrMmpodERtV1M3WXR2?= =?utf-8?B?NTd0NUpGbHVqWFVnL0tBbjZVOFNnTFNjSGhONUp2UENoNnFHQXI4TEdCdVRM?= =?utf-8?B?SFlid1luQ2dvbENXUnRUUEd2cTBPUXVMSjJZbDVuNU1kaitON2NQUTgyNFJJ?= =?utf-8?B?ejBXVlVJaGxJYk5maFU1bFdXOWYwUnZLdllsV1pjdHFKeEphVGxrS1psazc2?= =?utf-8?B?OWlKNWZ1SDVySkMwcHJlL2UzOG45a1M3QkZka3pSeDIwbi85RGdzYkF4cE5w?= =?utf-8?B?NTZ4YlBoclNGSDAvUE92WDJoRXlaLzBpVWlNd1NMWkVieXUwVDRWdGRaV214?= =?utf-8?B?RkJudmNiU0huMkRlcmdpMWh5YWg2N0VYL0s0eWZDcXVLNDU0K3M2cFRSSVN4?= =?utf-8?B?aFhMUEp5WUhOc21nblpLVkJnRSs2QjBuL0tGdG96Ryt0dzZvUlZpL2FVUXF2?= =?utf-8?B?ck5PK29uQmE2WHBzTXpldngwbTJuK3FZT05lbVZDelQ3UFppZ0lZM1lxcW9a?= =?utf-8?B?Ti9Sd1dBb0l5TGZtMzN3TkQrcHlJUGVZY3BXazVLZjkwRXo4Q2t3QWdWajdn?= =?utf-8?B?cTFXdktNK1BkREg5QTNpYjlxbzZCRlpPdW5zUlIvYmtiSnFQYlhDYkV5US9G?= =?utf-8?B?eGRzNW5hSm1UeGhBdEExV293N2Q1cVJsakZLQUVtcVV2anVSTzJRbERabWx1?= =?utf-8?B?QXowUzJUd2Z0bVFFcDM2K09DQytaREZzdlFYT1VHSFBiT2wxMjEyMVdCMmt6?= =?utf-8?B?NStxSnBWcWEzNmN1bDg5RHZzd1JGMEdEK1o5MnMrekhIU3NyNTd1c29yR2wv?= =?utf-8?B?ZXNyTld3QTFoWUg4QjUxL2FOQ21xOE5nbURlajBCWU9Ra1BjVis0d0plRHBJ?= =?utf-8?B?NW1DVEYwQkJLWDNVWktCRGprOENDNnN6OTgxb1FzWmU4TVNLU0pmUlBEVmNZ?= =?utf-8?B?Qi9ta2ZpcnBBUUFmVHhKU2RYMk9qS0FsbmV2eVdlWUkzeGZEMGF1VUJ5aUFK?= =?utf-8?B?ZXQ1WUxVSUxYODMyWUVDTGlvbDhla1NyaWh1YUxBV21nWmxBMm0wODRxUjZO?= =?utf-8?B?TVZXdmFHUWJ3WTNjeGREMWJKUGhjOEVkZS95YTFaSlZjSGw0QXhuUWo2anlF?= =?utf-8?B?L1JOMFJpZnZSdG1ibUgzS1VBVnM4UEJLMXRFdzEwNEs3SzM2NDJlTjFUakN2?= =?utf-8?B?dUVoR1ZYS3NDSUJGUVlMOXp0eUp5Y0Z3a0pCWm52dDFLL1lUM1hTMFY3UUdM?= =?utf-8?B?OEpMdWVmM2RnTlJwZFRUSjM4UHRqY3dtMHJYcnFDSVZQR25hVVZGTmJGckp3?= =?utf-8?B?OXlvb0VwQUkzRDdaVGREVkQ3ZFlVRFFvb0c1SlpSK3FEeERHaFdCcHBXV3Av?= =?utf-8?B?MG9NbHVYaHR4Y1dMUWE2Y3NIRzZ1dVhJRUJxWDByejJRU0NXWDFHT1RLTVdy?= =?utf-8?B?NzNWd20vSUNFSDZHRDN2YjJXb1VHOW5vZDNFb0FhRjBuZDdpVis3bmxwZklN?= =?utf-8?Q?H/tN7JxyAKf89waG86fRE2K3JBirSA5TV/6E5ED?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR05MB53169700BE4620420B3F3BAEAEAF9BL0PR05MB5316namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2b303728-4c35-4e79-a416-08d988385381 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Oct 2021 19:42:54.8567 (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: PbH13jzJQeSiymBbvdFHu8xzAS6nnDRo3MghXwSqwpU5rRxZLCgr3PjoHxUoSeCbwMdmmhKcjMBzN05dJlVJFA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6958 X-Proofpoint-ORIG-GUID: CJmG_Lp7sfCNp_5T31OFjpgyQqmxd6lf X-Proofpoint-GUID: CJmG_Lp7sfCNp_5T31OFjpgyQqmxd6lf X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-05_04,2021-10-04_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 lowpriorityscore=0 phishscore=0 mlxlogscore=999 priorityscore=1501 suspectscore=0 mlxscore=0 adultscore=0 malwarescore=0 spamscore=0 clxscore=1015 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110050114 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 05 Oct 2021 19:43:10 -0000 --_000_BL0PR05MB53169700BE4620420B3F3BAEAEAF9BL0PR05MB5316namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGFibG8sDQoNCkFlIHlvdSBzdXJlPyBQbGVhc2UgbG9vayBhdCB0aGUgcXVlc3Rpb24gYXMgSm9l bCBhc2tlZCBpdCAoIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5n L25TMmduUV9qeHZwYm1jeHNfZDNKQWJVQ1QxSS8gKS4NCg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgUm9uDQoNCg0KDQoNCkp1bmlwZXIgQnVzaW5lc3MgVXNlIE9ubHkNCkZyb206IFBhYmxvIENh bWFyaWxsbyAocGNhbWFyaWwpIDxwY2FtYXJpbD00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4N ClNlbnQ6IFR1ZXNkYXksIE9jdG9iZXIgNSwgMjAyMSAyOjU4IFBNDQpUbzogUm9uIEJvbmljYSA8 cmJvbmljYUBqdW5pcGVyLm5ldD47IEphbWVzIEd1aWNoYXJkIDxqYW1lcy5uLmd1aWNoYXJkQGZ1 dHVyZXdlaS5jb20+OyBTUFJJTkcgV0cgPHNwcmluZ0BpZXRmLm9yZz4NCkNjOiBzcHJpbmctY2hh aXJzQGlldGYub3JnDQpTdWJqZWN0OiBSRTogV0cgQWRvcHRpb24gY2FsbCBmb3IgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1z cmgtY29tcHJlc3Npb24vDQoNCltFeHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVu dF0NCg0KUm9uLA0KDQpJIGJlbGlldmUgeW91ciBzdGF0ZW1lbnQgaXMgd3JvbmcuIFRoZSBXRyBo YXMgZXhwcmVzc2VkIHN0cm9uZyBwcmVmZXJlbmNlIGZvciBhIHNpbmdsZSBkYXRhIHBsYW5lIHNv bHV0aW9uLg0KDQpGcm9tIHRoZSBjaGFpcnMgZW1haWxzOg0K4oCcR2l2ZW4gdGhhdCB0aGUgd29y a2luZyBncm91cCBoYXMgc2FpZCB0aGF0IGl0IHdhbnRzIHRvIHN0YW5kYXJkaXplIG9uZSBkYXRh IHBsYW5lIHNvbHV0aW9uIOKApuKAnQ0K4oCcVGhlcmUgaXMgYSByb3VnaCAocXVpdGUgY2xlYXIp IGNvbnNlbnN1cyBmb3Igc3RhbmRhcmRpemluZyBvbmUgZGF0YXBsYW5lIHNvbHV0aW9u4oCm4oCd DQoNCkkgaG9wZSB3ZSBhbGwgYWdyZWUgdGhhdCBSRkM4OTg2IGlzIG5vdCBkZWZpbmluZyAzNiBk aWZmZXJlbnQgZGF0YXBsYW5lIHNvbHV0aW9ucy4g8J+YiQ0KDQpDaGVlcnMsDQpQYWJsby4NCg0K RnJvbTogUm9uIEJvbmljYSA8cmJvbmljYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPG1h aWx0bzpyYm9uaWNhPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+Pg0KU2VudDogbWFydGVz LCA1IGRlIG9jdHVicmUgZGUgMjAyMSAxNzozOA0KVG86IFBhYmxvIENhbWFyaWxsbyAocGNhbWFy aWwpIDxwY2FtYXJpbEBjaXNjby5jb208bWFpbHRvOnBjYW1hcmlsQGNpc2NvLmNvbT4+OyBKYW1l cyBHdWljaGFyZCA8amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPG1haWx0bzpqYW1lcy5u Lmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20+PjsgU1BSSU5HIFdHIDxzcHJpbmdAaWV0Zi5vcmc8bWFp bHRvOnNwcmluZ0BpZXRmLm9yZz4+DQpDYzogc3ByaW5nLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86 c3ByaW5nLWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBXRyBBZG9wdGlvbiBjYWxsIGZv ciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNw cmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8NCg0KUGFibG8sDQoNClRoZSBXRyBoYXMgZXhwcmVz c2VkIGEgc3Ryb25nIHByZWZlcmVuY2UgZm9yIGhhdmluZyBhIHNpbmdsZSBjb21wcmVzc2lvbiAq YmVoYXZpb3IqLiBXaHkgaXMgaXQgT0sgdG8gaWdub3JlIHRoYXQgcHJlZmVyZW5jZSBiZWNhdXNl IFJGQyA4OTg2IGhhcyAzNiBkaWZmZXJlbnQgYmVoYXZpb3JzPw0KDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBS b24NCg0KDQoNCg0KSnVuaXBlciBCdXNpbmVzcyBVc2UgT25seQ0KRnJvbTogc3ByaW5nIDxzcHJp bmctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBC ZWhhbGYgT2YgUGFibG8gQ2FtYXJpbGxvIChwY2FtYXJpbCkNClNlbnQ6IE1vbmRheSwgT2N0b2Jl ciA0LCAyMDIxIDE6MzIgUE0NClRvOiBKYW1lcyBHdWljaGFyZCA8amFtZXMubi5ndWljaGFyZEBm dXR1cmV3ZWkuY29tPG1haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20+PjsgU1BS SU5HIFdHIDxzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4+DQpDYzogc3By aW5nLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nLWNoYWlyc0BpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbc3ByaW5nXSBXRyBBZG9wdGlvbiBjYWxsIGZvciBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVz c2lvbi88aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24v X187ISFORXQ2eU1hTy1nayFYRmtpN3k0OWhxLV8xbjl3aXZaZGJBX0l1YU1RM1VUWXdGLUlSRVNE ZC01T0wtZFYtWndBVVVrU2N4R0dMU19kJD4NCg0KDQpSRkM4OTg2IGFscmVhZHkgZGVmaW5lcyAz NiBkaWZmZXJlbnQgYmVoYXZpb3JzLg0KDQpUaGlzIGRvY3VtZW50LCBDU0lELCBpcyBhIHNpbmds ZSBTUnY2LWJhc2VkIHNvbHV0aW9uIHRoYXQgb25seSBkZWZpbmVzIGFkZGl0aW9uYWwgYmVoYXZp b3JzIHdpdGggdGhlIG5leHQgYW5kIHJlcGxhY2UgZmxhdm9ycy4NCg0KDQoNCg== --_000_BL0PR05MB53169700BE4620420B3F3BAEAEAF9BL0PR05MB5316namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkgRW1vamkiOw0KCXBhbm9z ZS0xOjIgMTEgNSAyIDQgMiA0IDIgMiAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlNl Z29lIFVJIjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIgNCAyIDIgMzt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkxhdG87DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDM7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLnBhcmFncmFwaCwgbGkucGFyYWdyYXBoLCBkaXYucGFyYWdyYXBoDQoJe21zby1z dHlsZS1uYW1lOnBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBp bjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnAubXNpcGZvb3RlcjMwYjNkNTM4LCBsaS5tc2lwZm9vdGVyMzBiM2Q1MzgsIGRpdi5tc2lw Zm9vdGVyMzBiM2Q1MzgNCgl7bXNvLXN0eWxlLW5hbWU6bXNpcGZvb3RlcjMwYjNkNTM4Ow0KCW1z by1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5ub3JtYWx0ZXh0cnVuDQoJ e21zby1zdHlsZS1uYW1lOm5vcm1hbHRleHRydW47fQ0Kc3Bhbi5lb3ANCgl7bXNvLXN0eWxlLW5h bWU6ZW9wO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTQuMHB0Ij5QYWJsbyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxNC4wcHQiPkFlIHlvdSBzdXJlPyBQbGVhc2UgbG9vayBhdCB0aGUgcXVlc3Rpb24g YXMgSm9lbCBhc2tlZCBpdCAoDQo8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3Jn L2FyY2gvbXNnL3NwcmluZy9uUzJnblFfanh2cGJtY3hzX2QzSkFiVUNUMUkvIj4NCmh0dHBzOi8v bWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL25TMmduUV9qeHZwYm1jeHNfZDNK QWJVQ1QxSS88L2E+ICkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUm9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTQuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtc2lwZm9vdGVyMzBi M2Q1MzgiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW46MGluO3RleHQtYWxpZ246Y2VudGVy Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6YmxhY2siPkp1bmlwZXIgQnVz aW5lc3MgVXNlIE9ubHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFBhYmxvIENh bWFyaWxsbyAocGNhbWFyaWwpICZsdDtwY2FtYXJpbD00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9y ZyZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBPY3RvYmVyIDUsIDIwMjEgMjo1OCBQ TTxicj4NCjxiPlRvOjwvYj4gUm9uIEJvbmljYSAmbHQ7cmJvbmljYUBqdW5pcGVyLm5ldCZndDs7 IEphbWVzIEd1aWNoYXJkICZsdDtqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20mZ3Q7OyBT UFJJTkcgV0cgJmx0O3NwcmluZ0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IHNwcmluZy1j aGFpcnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFdHIEFkb3B0aW9uIGNhbGwg Zm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmct c3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjEyLjBwdDtiYWNrZ3JvdW5kOiNGRkVCOUMi PjxiPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtMYXRvJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPltFeHRlcm5hbCBFbWFpbC4g QmUgY2F1dGlvdXMgb2YgY29udGVudF08bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Sb24sJm5ic3A7IDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIGJlbGlldmUgeW91ciBzdGF0ZW1lbnQgaXMgd3JvbmcuIFRoZSBXRyBoYXMg ZXhwcmVzc2VkIHN0cm9uZyBwcmVmZXJlbmNlIGZvciBhIHNpbmdsZSBkYXRhIHBsYW5lIHNvbHV0 aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gcm9tIHRoZSBjaGFpcnMgZW1haWxzOiA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPuKAnEdpdmVuIHRoYXQgdGhlIHdvcmtp bmcgZ3JvdXAgaGFzIHNhaWQgdGhhdCBpdCB3YW50cyB0byBzdGFuZGFyZGl6ZSBvbmUgZGF0YSBw bGFuZSBzb2x1dGlvbiDigKbigJ0NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+4oCcVGhlcmUgaXMgYSByb3VnaCAocXVpdGUgY2xlYXIpIGNvbnNlbnN1cyBmb3Igc3RhbmRh cmRpemluZyBvbmUgZGF0YXBsYW5lIHNvbHV0aW9u4oCm4oCdDQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSBob3BlIHdlIGFsbCBhZ3JlZSB0aGF0IFJGQzg5ODYgaXMgbm90IGRlZmluaW5nIDM2 IGRpZmZlcmVudCBkYXRhcGxhbmUgc29sdXRpb25zLg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1NlZ29lIFVJIEVtb2ppJnF1b3Q7LHNhbnMtc2VyaWYiPiYjMTI4NTIxOzwvc3Bhbj4g PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycywgPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5QYWJsby48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBSb24gQm9uaWNhICZsdDs8YSBocmVm PSJtYWlsdG86cmJvbmljYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3JnIj5yYm9uaWNhPTQw anVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0Ow0KPGJyPg0KPGI+U2VudDo8L2I+IG1h cnRlcywgNSBkZSBvY3R1YnJlIGRlIDIwMjEgMTc6Mzg8YnI+DQo8Yj5Ubzo8L2I+IFBhYmxvIENh bWFyaWxsbyAocGNhbWFyaWwpICZsdDs8YSBocmVmPSJtYWlsdG86cGNhbWFyaWxAY2lzY28uY29t Ij5wY2FtYXJpbEBjaXNjby5jb208L2E+Jmd0OzsgSmFtZXMgR3VpY2hhcmQgJmx0OzxhIGhyZWY9 Im1haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20iPmphbWVzLm4uZ3VpY2hhcmRA ZnV0dXJld2VpLmNvbTwvYT4mZ3Q7OyBTUFJJTkcgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJp bmdAaWV0Zi5vcmciPnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBo cmVmPSJtYWlsdG86c3ByaW5nLWNoYWlyc0BpZXRmLm9yZyI+c3ByaW5nLWNoYWlyc0BpZXRmLm9y ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFdHIEFkb3B0aW9uIGNhbGwgZm9yIDxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmct c3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjE0LjBwdCI+UGFibG8sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTQuMHB0Ij5UaGUgV0cgaGFzIGV4cHJlc3NlZCBhIHN0cm9uZyBwcmVmZXJlbmNlIGZvciBo YXZpbmcgYSBzaW5nbGUgY29tcHJlc3Npb24gKjxiPmJlaGF2aW9yPC9iPiouIFdoeSBpcyBpdCBP SyB0byBpZ25vcmUgdGhhdCBwcmVmZXJlbmNlIGJlY2F1c2UgUkZDIDg5ODYgaGFzIDM2IGRpZmZl cmVudCBiZWhhdmlvcnM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0 Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUm9uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTQuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtc2lwZm9vdGVy MzBiM2Q1MzgiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW46MGluO3RleHQtYWxpZ246Y2Vu dGVyIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6YmxhY2siPkp1bmlwZXIg QnVzaW5lc3MgVXNlIE9ubHk8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IHNwcmlu ZyAmbHQ7PHNwYW4gbGFuZz0iRVMiPjxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRm Lm9yZyI+PHNwYW4gbGFuZz0iRU4tVVMiPnNwcmluZy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwv YT48L3NwYW4+Jmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5QYWJsbyBDYW1hcmlsbG8gKHBjYW1h cmlsKTxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE9jdG9iZXIgNCwgMjAyMSAxOjMyIFBNPGJy Pg0KPGI+VG86PC9iPiBKYW1lcyBHdWljaGFyZCAmbHQ7PHNwYW4gbGFuZz0iRVMiPjxhIGhyZWY9 Im1haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20iPjxzcGFuIGxhbmc9IkVOLVVT Ij5qYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb208L3NwYW4+PC9hPjwvc3Bhbj4mZ3Q7OyBT UFJJTkcgV0cgJmx0OzxzcGFuIGxhbmc9IkVTIj48YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYu b3JnIj48c3BhbiBsYW5nPSJFTi1VUyI+c3ByaW5nQGlldGYub3JnPC9zcGFuPjwvYT48L3NwYW4+ Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPHNwYW4gbGFuZz0iRVMiPjxhIGhyZWY9Im1haWx0bzpzcHJp bmctY2hhaXJzQGlldGYub3JnIj48c3BhbiBsYW5nPSJFTi1VUyI+c3ByaW5nLWNoYWlyc0BpZXRm Lm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NwcmluZ10g V0cgQWRvcHRpb24gY2FsbCBmb3IgPHNwYW4gbGFuZz0iRVMiPjxhIGhyZWY9Imh0dHBzOi8vdXJs ZGVmZW5zZS5jb20vdjMvX19odHRwczovZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZp bHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uL19fOyEhTkV0NnlNYU8tZ2sh WEZraTd5NDlocS1fMW45d2l2WmRiQV9JdWFNUTNVVFl3Ri1JUkVTRGQtNU9MLWRWLVp3QVVVa1Nj eEdHTFNfZCQiPjxzcGFuIGxhbmc9IkVOLVVTIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88L3Nw YW4+PC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0icGFyYWdy YXBoIiBzdHlsZT0ibWFyZ2luOjBpbjt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZSI+PHNwYW4gY2xh c3M9Im5vcm1hbHRleHRydW4iPlJGQzg5ODYgYWxyZWFkeSBkZWZpbmVzIDM2IGRpZmZlcmVudCZu YnNwO2JlaGF2aW9ycy48L3NwYW4+PHNwYW4gY2xhc3M9ImVvcCI+Jm5ic3A7PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDss c2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9InBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbjowaW47dmVydGljYWwtYWxpZ246YmFzZWxpbmUiPjxzcGFuIGNsYXNzPSJu b3JtYWx0ZXh0cnVuIj5UaGlzIGRvY3VtZW50LCBDU0lELCBpcyBhIHNpbmdsZSBTUnY2LWJhc2Vk IHNvbHV0aW9uIHRoYXQmbmJzcDtvbmx5Jm5ic3A7ZGVmaW5lcyBhZGRpdGlvbmFsIGJlaGF2aW9y cyB3aXRoIHRoZSBuZXh0IGFuZCByZXBsYWNlIGZsYXZvcnMuPC9zcGFuPjxzcGFuIGNsYXNzPSJl b3AiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW46MGluO3ZlcnRpY2FsLWFsaWduOmJh c2VsaW5lO3VzZXItc2VsZWN0OiB0ZXh0Oy13ZWJraXQtdXNlci1kcmFnOiBub25lOy13ZWJraXQt dGFwLWhpZ2hsaWdodC1jb2xvcjogdHJhbnNwYXJlbnQ7b3ZlcmZsb3ctd3JhcDogYnJlYWstd29y ZDtmb250LWtlcm5pbmc6IG5vbmUiPg0KPHNwYW4gY2xhc3M9ImVvcCI+Jm5ic3A7PC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9InVzZXItc2VsZWN0OiB0ZXh0Oy13ZWJraXQtdXNlci1kcmFnOiBub25lOy13ZWJr aXQtdGFwLWhpZ2hsaWdodC1jb2xvcjogdHJhbnNwYXJlbnQ7b3ZlcmZsb3ctd3JhcDogYnJlYWst d29yZDtmb250LWtlcm5pbmc6IG5vbmUiPg0KPG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BL0PR05MB53169700BE4620420B3F3BAEAEAF9BL0PR05MB5316namp_-- From nobody Tue Oct 5 13:23:44 2021 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 4D4F83A0CB8 for ; Tue, 5 Oct 2021 13:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 I1O5wQdm2ics for ; Tue, 5 Oct 2021 13:23:35 -0700 (PDT) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636FA3A0CBA for ; Tue, 5 Oct 2021 13:23:35 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id g8so1272210edt.7 for ; Tue, 05 Oct 2021 13:23:35 -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=XArlJ7w2uOgg0/speO1YY/JqELeA11s/bJ3RAqmayqE=; b=DPEQ2pMBCubpYFat8R0gw+YC7AD5o2kcMSTyMqipLXkg1rIy8pIWOMEZTHmCvfYEX1 0Q/1vA3aA9Q31cJ3ooZRrFotCZQRmmz+WQxZ/7ft3e7kkBck14G7RoJW6gDNQCmqCJ1B Zz+0okB1IYyjPD/a1fFQ7YkLvAcB51UiGrX/0IoSt+yFWwvfxjbf9LABREqC4RZNlMba 2FbgDugXD6BYbJm6Cy6dBctQFpM86iOU8gIald41tocNNy0HxBybdw3ChTamEwrsFYFm H4z9PSr5z/JdaD7uoyQUHtd30Cz9MmQRE6e5gZVleTHGFJaRdTT8iy+ArT7Uo9jmOx5a Hdkw== 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=XArlJ7w2uOgg0/speO1YY/JqELeA11s/bJ3RAqmayqE=; b=8IO9d4Ea0AjulGmpDG7LSkJLbZ+7Ge+PWMTCNujShR3/SOWG1TzN5AkmSFHDuL15tM 311vBp66H2LOGV2TgNrf0IetIWIBJ0gRqZ87JlGQRkzT9PkZnhF2Ab50+aHgA7Y93xtA 2sgRY6yBgwWFunUgN8IWRzZdeeQZsWGmQu0wD/ewJ2BhAnVAWlDFcsTgQE/5p8uF1pto FGiP244ayoM/Vnoj8XMQJ03iUUMY5q6FU1iFiNXIIFlER3WCSN9kWZrjgLZkoGo1Bs3M 9wHvQMjyDB7LqSVWq+IN0uv1Hl69UOhw+OA9m+PWEjpq/xjdh33OfJmA9D3KdDG75ZWv sXtg== X-Gm-Message-State: AOAM530Nvw5AqrRpaVM/yVBati/9Ejv3ZW0Y0M9Ljlv8FPHh3jUTzimx RlnAVCR/73nSKMQRsoYBafX6rQ2tp2HaYJBtIRFK7g== X-Google-Smtp-Source: ABdhPJzP457kdLyZf4vT5osSkvf31iPoWGIMtq5bfR+9UqLoXJzb9ZjAZ6oq7uxz3Zwo6swlLaezDBWH0asyr1RZUeA= X-Received: by 2002:a17:906:3281:: with SMTP id 1mr26776843ejw.167.1633465413231; Tue, 05 Oct 2021 13:23:33 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Tue, 5 Oct 2021 22:23:24 +0200 Message-ID: To: Ron Bonica Cc: James Guichard , SPRING WG , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b57d6405cda0cd65" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 05 Oct 2021 20:23:41 -0000 --000000000000b57d6405cda0cd65 Content-Type: text/plain; charset="UTF-8" Ron & SPRING WG chairs, Through this discussion we first have seen a debate if we need one or more data planes to compress SIDs in SRv6. WG clearly stated we need one. Following that we have observed a first terminology shift to see if asking how many solutions should be supported will work any better. To that many WG members clearly stated that they support one solution. Well please notice that the draft in question in its introduction states: Abstract This document defines a compressed SRv6 Segment List Encoding in the Segment Routing Header (SRH). *This solution* does not require any SRH data plane change nor any SRv6 control plane change. *This solution* leverages the SRv6 Network Programming model. So based on my understanding of English the entire draft talks about a single solution. Then suddenly a new question popped up: how many behaviours are acceptable. I bet number of folks including myself said "one" keeping in mind previous discussions and the definition of "one" meaning based on the SRv6 data plane in compliance to [RFC8402], [RFC8754] and [RFC8986]. Interestingly enough the draft in question defines not behaviours but flavors as new variants of the already defined behaviors in Standards Track RFCs. Namely it defines: 4.1. NEXT-C-SID Flavor 4.2. REPLACE-C-SID Flavor The newly defined behaviour End.XPS is optional. So if there is anything to ask here is to check if WG is ok with two flavors or not. I do not recall that question has ever been asked formally during the WG adoption call. With that let's note that optimal compressed SID size may be different network to network. One size does not fit all. Draft says: 6.1. C-SID Length The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A * C-SID length of 16-bit is recommended.* The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths. * A C-SID length of 32-bit is recommended.* While I personally think 8-bit should be an option, if we choose a single flavor we will introduce suboptimality for no good reason. Hardware capable of supporting any flavor clearly can do LPM on locator. Also hardware capable of supporting one flavor can support few other flavors as this is pretty much just an offset game. Kind regards, Robert On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica wrote: > Pablo, > > > > Ae you sure? Please look at the question as Joel asked it ( > https://mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ > ). > > > > > Ron > --000000000000b57d6405cda0cd65 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ron & SPRING WG chairs,

=
Through this discussion we first have seen a debate if we need o= ne or more data planes=C2=A0to compress SIDs in SRv6. WG clearly=C2=A0state= d we need one.=C2=A0

Following that we have observ= ed a first terminology shift to see if asking how many solutions should be = supported will work any better. To that many WG members clearly stated that= they support one solution.=C2=A0

Well please noti= ce that the draft in question in its introduction states:=C2=A0
<= br>
Abstract

=C2=A0 =C2=A0This document defines a compress= ed SRv6 Segment List Encoding in the
=C2=A0 =C2=A0Segment Routing Header= (SRH). =C2=A0This solution does not require any SRH
=C2=A0 =C2= =A0data plane change nor any SRv6 control plane change. =C2=A0This solut= ion
=C2=A0 =C2=A0leverages the SRv6 Network Programming model.

So based on my understanding of English the entire = draft talks about a single solution.=C2=A0

Then su= ddenly a new question popped=C2=A0up: how many behaviours are acceptable.= =C2=A0

I bet number of folks including myself said= "one" keeping in mind previous discussions and the definition of= "one" meaning based on the SRv6 data plane in compliance to [RFC= 8402], [RFC8754] and [RFC8986].

Interestingly enou= gh the draft in question defines not behaviours but flavors as new variants= of the already defined behaviors in Standards Track RFCs. Namely it define= s:=C2=A0

4.1.=C2=A0 NEXT-C-SID Flavor
4.2.=C2=A0 REPLACE-C-SID Flavor

The newly de= fined behaviour End.XPS is optional.=C2=A0

So if there is anything t= o ask here is to check if WG is ok with two flavors or not. I do not recall= that question has=C2=A0ever been asked formally during the WG adoption cal= l.=C2=A0

With that let's note that optimal com= pressed SID size may be different network to network. One size does not fit= all. Draft says:=C2=A0

6.1.=C2=A0 C-SID Length

=C2=A0 =C2=A0= The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. =C2=A0A=C2=A0 =C2=A0C-SID length of 16-bit is recommended.

=C2=A0 = =C2=A0The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths.<= br>=C2=A0 =C2=A0A C-SID length of 32-bit is recommended.

While I personally think 8-bit should be an option, if we= choose a single flavor we will introduce suboptimality for no good reason.= Hardware capable=C2=A0of supporting any flavor clearly can do LPM on locat= or. Also hardware capable of supporting one flavor can support few other fl= avors as this is pretty much just an offset game.=C2=A0

<= /div>
Kind regards,
Robert



On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica <rbonica=3D40juniper.net@dm= arc.ietf.org> wrote:
--000000000000b57d6405cda0cd65-- From nobody Tue Oct 5 14:36:30 2021 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 EAAEA3A08D9; Tue, 5 Oct 2021 14:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 HzQ_eYHVCR2U; Tue, 5 Oct 2021 14:36:21 -0700 (PDT) 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 4160A3A08CE; Tue, 5 Oct 2021 14:36:21 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id f9so1975388edx.4; Tue, 05 Oct 2021 14:36:21 -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=TZkjqou47HUl5Njcu5TI0KTM7ZlUmyZ+qKPD78rGcgI=; b=AzBVzAh31oOd+cBqtUoFnENr8SspQ8N3f27NY4muSu9r957GlW/Xvgbq904vlx39zd VrnE1UroStN54wm4nk4/b0XY8RypLEhhbOood7cfHH8bo2uN36qPmQ1WXvN35+1sSkiN lUNI13hFcgBaw0D3Hv+cM4BZKmHQC0xiWhv2ZS/cYb2AwFGtMmyC7ALOZq9/vJhf6xza zXp4RQVrrxsHD3W28l/BVkRN0tcBuniSZhfyJ20c2idGQtgf/cNJAG5Bw8fnD/MM2P/W IsQCEb/iyCAH1vgG53CEy0+gGgPojrzZYM20TqMyaGkG+snxeUU/aER3d6uP8ZphRBK/ WRcw== 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=TZkjqou47HUl5Njcu5TI0KTM7ZlUmyZ+qKPD78rGcgI=; b=KqEvXChHvt0T4VUnyXW5la/1LPuHp/OrwbNyP+AvyeA/rWiwHAg0vCRRejx2ss2KKq MAsVJQ4Yx+/zvovu7DHLpcATLR6pm9RYv6qqPO2sZC0fsk2uZBYJPxOHq2OF/IhxzbTW axpf9YRJTaxMyww58dp3BVg2Z1HjgWCiiulsqHs/kQ8+9cMcIcBoTjRuJLqmtyw7gzto m2UZ5gLehfQ5uCyWnOQVKqp7TEHC0aGWMBL1WeRggd6LUvzHxKuMpnypHLPCFm9tjoib ClEiBSHeI5os5yHIRNpseTkhllhalNn0xU4j0j4jAzhVZ+YfRdEAHjjvC2Fq4zbVqF/L sm5w== X-Gm-Message-State: AOAM531NizSecl5mpG6WEFrwS/ycD7Psxx+dvV2mk1OzLJIVMLBBjKVH Co0M8vAGBpW8bRlwaaPfWnY42yZjvcWtzgRKhTQ= X-Google-Smtp-Source: ABdhPJzzhz3VBFCJh7OQ6Crm/BFmoOtnoPuxp0oZHopDljq4QIaflzs1lr19zu6tvERU5s5T6kzTHvMliyd68iLfWV8= X-Received: by 2002:a05:6402:2790:: with SMTP id b16mr28686972ede.3.1633469779429; Tue, 05 Oct 2021 14:36:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Tue, 5 Oct 2021 14:36:07 -0700 Message-ID: To: Robert Raszuk Cc: Ron Bonica , James Guichard , SPRING WG , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f44e2a05cda1d1f4" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 05 Oct 2021 21:36:27 -0000 --000000000000f44e2a05cda1d1f4 Content-Type: text/plain; charset="UTF-8" Hi Robert, as I understand it, you believe everything that is written in the draft. I hope you can help me find an answer to one simple question: Can a node that supports this draft in its entirety, i.e., supports all "flavors" defined in the document, process received SRv6 packet with the SRH encoded according to the specification? So far, the proponents of the draft referred to "planning" how flavors of SRv6 SID compressed. To the best of my understanding, that is is a clear demonstration of the incompatibility between flavors defined in the CSID draft. Regardless of what is written in it. Regards, Greg On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk wrote: > Ron & SPRING WG chairs, > > Through this discussion we first have seen a debate if we need one or more > data planes to compress SIDs in SRv6. WG clearly stated we need one. > > Following that we have observed a first terminology shift to see if asking > how many solutions should be supported will work any better. To that many > WG members clearly stated that they support one solution. > > Well please notice that the draft in question in its introduction states: > > Abstract > > This document defines a compressed SRv6 Segment List Encoding in the > Segment Routing Header (SRH). *This solution* does not require any SRH > data plane change nor any SRv6 control plane change. *This solution* > leverages the SRv6 Network Programming model. > > So based on my understanding of English the entire draft talks about a > single solution. > > Then suddenly a new question popped up: how many behaviours are > acceptable. > > I bet number of folks including myself said "one" keeping in mind previous > discussions and the definition of "one" meaning based on the SRv6 data > plane in compliance to [RFC8402], [RFC8754] and [RFC8986]. > > Interestingly enough the draft in question defines not behaviours but > flavors as new variants of the already defined behaviors in Standards Track > RFCs. Namely it defines: > > 4.1. NEXT-C-SID Flavor > 4.2. REPLACE-C-SID Flavor > > The newly defined behaviour End.XPS is optional. > > So if there is anything to ask here is to check if WG is ok with two > flavors or not. I do not recall that question has ever been asked formally > during the WG adoption call. > > With that let's note that optimal compressed SID size may be different > network to network. One size does not fit all. Draft says: > > 6.1. C-SID Length > > The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A > * C-SID length of 16-bit is recommended.* > > The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths. > * A C-SID length of 32-bit is recommended.* > > While I personally think 8-bit should be an option, if we choose a single > flavor we will introduce suboptimality for no good reason. Hardware > capable of supporting any flavor clearly can do LPM on locator. Also > hardware capable of supporting one flavor can support few other flavors as > this is pretty much just an offset game. > > Kind regards, > Robert > > > > On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica 40juniper.net@dmarc.ietf.org> wrote: > >> Pablo, >> >> >> >> Ae you sure? Please look at the question as Joel asked it ( >> https://mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ >> ). >> >> >> >> >> Ron >> > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --000000000000f44e2a05cda1d1f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Robert,
as I understand it, you believe everything = that is written in the draft. I hope you can help me find an answer to one = simple question:
Can a node that supports this draft in its entirety, i= .e., supports all "flavors" defined in the document, process rece= ived SRv6 packet with the SRH encoded according to the specification?
=
So far, the proponents of the draft referred to "planning= " how flavors of SRv6 SID compressed. To the best of my understanding,= that is is a clear demonstration of the incompatibility between flavors de= fined in the CSID draft. Regardless of=C2=A0what is written in it.

Regards,
Greg

On Tue, Oct 5, 2021 at 1:24 P= M Robert Raszuk <robert@raszuk.net<= /a>> wrote:
<= div dir=3D"ltr">
Ron & SPRING WG chairs,

<= /div>
Through this discussion we first have seen a debate if we need on= e or more data planes=C2=A0to compress SIDs in SRv6. WG clearly=C2=A0stated= we need one.=C2=A0

Following that we have observe= d a first terminology shift to see if asking how many solutions should be s= upported will work any better. To that many WG members clearly stated that = they support one solution.=C2=A0

Well please notic= e that the draft in question in its introduction states:=C2=A0
Abstract

=C2=A0 =C2=A0This document defines a compresse= d SRv6 Segment List Encoding in the
=C2=A0 =C2=A0Segment Routing Header = (SRH). =C2=A0This solution does not require any SRH
=C2=A0 =C2=A0= data plane change nor any SRv6 control plane change. =C2=A0This solution=
=C2=A0 =C2=A0leverages the SRv6 Network Programming model.

So based on my understanding of English the entire dra= ft talks about a single solution.=C2=A0

Then sudde= nly a new question popped=C2=A0up: how many behaviours are acceptable.=C2= =A0

I bet number of folks including myself said &q= uot;one" keeping in mind previous discussions and the definition of &q= uot;one" meaning based on the SRv6 data plane in compliance to [RFC840= 2], [RFC8754] and [RFC8986].

Interestingly enough = the draft in question defines not behaviours but flavors as new variants of= the already defined behaviors in Standards Track RFCs. Namely it defines:= =C2=A0

4.1.=C2=A0 NEXT-C-SID Flavor
= 4.2.=C2=A0 REPLACE-C-SID Flavor

The newly defi= ned behaviour End.XPS is optional.=C2=A0

So if there is anything to = ask here is to check if WG is ok with two flavors or not. I do not recall t= hat question has=C2=A0ever been asked formally during the WG adoption call.= =C2=A0

With that let's note that optimal compr= essed SID size may be different network to network. One size does not fit a= ll. Draft says:=C2=A0

6.1.=C2=A0 C-SID Length

=C2=A0 =C2=A0Th= e NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. =C2=A0A
= =C2=A0 =C2=A0C-SID length of 16-bit is recommended.

=C2=A0 = =C2=A0The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths.<= br>=C2=A0 =C2=A0A C-SID length of 32-bit is recommended.

While I personally think 8-bit should be an option, if we= choose a single flavor we will introduce suboptimality for no good reason.= Hardware capable=C2=A0of supporting any flavor clearly can do LPM on locat= or. Also hardware capable of supporting one flavor can support few other fl= avors as this is pretty much just an offset game.=C2=A0

<= /div>
Kind regards,
Robert



On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica <rbonica=3D40juniper.net@dm= arc.ietf.org> wrote:
_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--000000000000f44e2a05cda1d1f4-- From nobody Tue Oct 5 14:40:38 2021 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 4AED13A0917; Tue, 5 Oct 2021 14:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 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, FREEMAIL_REPLY=1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 xPUfQuGjbaQH; Tue, 5 Oct 2021 14:40:31 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 790513A090F; Tue, 5 Oct 2021 14:40:31 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id r2so562862pgl.10; Tue, 05 Oct 2021 14:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=hlBH8PxHMT1Vam1puJ74D46CGsHtYM3sRB7mxa7Y0X0=; b=aivPREleLeI8wySKBsTjnFqNx8LQpnRHotDhBWWDsGzjVUZ5F9fnVNv/17dR5YGr93 fhAu1MEiiKYA0i4GgC4A/bY5ZdZPxOAjmU05KDPhF4XPo6IgHZJR4JFxbgJ8FndL+6bP XdzwRyWFZFEZhwgsDcchz+EkZ0gA2bMDsCecwmkHlO39Xw85ZNgoradJbywyOt70Jv3w EnfGSIvmRC45vqtvnC8TtrPwuf+G0l+0bOapukOpBf7JdU0rBZ3jDq6fG71wg+egOr8K M1TQ9ltQduZBmhYY6pMVve7pCiaOuwOlzKaj2ujlgofM1K04sRHRbb1H1Sq4vYrI0XR3 pIsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hlBH8PxHMT1Vam1puJ74D46CGsHtYM3sRB7mxa7Y0X0=; b=774aRQXqCyW1GP+sPo0dzV3L4z9A0lR7hvCKqeYw47aRUkgonIc/7aaLS5aS8dBhAP 2CRa+8Y0WJ1u0ld97H3je+UEaEMJ4lWQxtXMyaU9CIsA46Oqy0DIsfHKCOO8YzG/73MK cGXtj/VrLGbUFXzCoIfaEpQFI77xbnxlrJjIf6croaYk+xPOD8ktsfwfMCtTdIIZecqs 0e7OUFlsBGDbPbS+3HMFB+Li/qydxiHv9C20JD5ILVoIYnZQfLcRD4u8ckcf2cnTLFi9 HhuNvrTDVbCg4u2HYyrny3MsDM2wuxvM9x5lNQ/sAICHHW1fGnHyukftvcwCGL0o9AQU S1fw== X-Gm-Message-State: AOAM533/zlQURJp4AtVDgo857X7zM/h7+3kY6eJIhnTcxcAU+XT1UJmW 3E5id2/c5WUImKz/7qhu+haihpG+8cYP/w== X-Google-Smtp-Source: ABdhPJwFLf4r4rg7uvjH0SEOss4cCY2eTO2l2TvwvAWt9b1te2Smeoyt65YotK9CIV3b7OdHE1sUuQ== X-Received: by 2002:a05:6a00:1a4c:b0:44b:1fa6:532c with SMTP id h12-20020a056a001a4c00b0044b1fa6532cmr34323522pfv.64.1633470030398; Tue, 05 Oct 2021 14:40:30 -0700 (PDT) Received: from ?IPv6:2406:e003:11aa:d701:80b2:5c79:2266:e431? ([2406:e003:11aa:d701:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id q12sm19186388pgv.26.2021.10.05.14.40.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Oct 2021 14:40:29 -0700 (PDT) To: Robert Raszuk , Tony Przygienda Cc: Ron Bonica , SPRING WG , "6man@ietf.org" <6man@ietf.org> References: <6d4eff6d-6fdc-992e-3a01-13bce8b05cd0@gmail.com> From: Brian E Carpenter Message-ID: <8b8f2531-5ec6-d34e-4d67-409ff043a088@gmail.com> Date: Wed, 6 Oct 2021 10:40:24 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 05 Oct 2021 21:40:37 -0000 On 05-Oct-21 23:09, Robert Raszuk wrote: > Tony, >=20 > I am afraid you missed my point :(=C2=A0 >=20 > Any IP address can be split into routable part and non routable part (o= r perhaps to be more correct globally routable part and locally routable = part).=C2=A0 >=20 > So I am not contradicting myself at all stating that=C2=A0if I got /24 = or /64 from RIR and I advertise those to attract traffic and I can do wha= tever I want with the remaining 8 or 64 bits. Well, they are address bits, not semantic content, in the IP connectionle= ss datagram model invented in the late 1970s and slightly updated in the = 1990s. What you are describing is radically different. But nothing you wr= ote previously made it clear that you were talking about only part of the=20 128 bits. >=20 > Remember ISDN or better E.164 numbers ? My number is is my base number = and extension - DDI or DID. If I assign DDI to fax or voice mail or phone=20 in the kitchen has no bearing on the telephone network, rest of the numbe= r to reach me.=C2=A0 >=20 > Besides all that we are taking here about encapsulated packets anyway -=20 so even how I make sure the prefix or locator are advertised and installe= d in the FIBs should be not a concern=C2=A0to any of my neighbors. If my = encapsulated packets leak (or as some say escape) and I use legal prefix = assigned by RIR as part of the DST address there are bunch of tools deplo= yed today which should drop it right there on the other edge.=20 Indeed. I don't actually care what an SRV6 site does in private; but it's=20 like forgetting to switch your camera off during a Zoom session, or messi= ng up your BGP update: accidents will happen, and that's what the IETF sh= ould worry about. Brian >=20 > Best, > R. >=20 >=20 > On Tue, Oct 5, 2021 at 10:38 AM Tony Przygienda > wrote: >=20 >=20 >=20 > On Tue, Oct 5, 2021 at 9:10 AM Robert Raszuk > wrote: >=20 > Hi Brian, >=20 > Thank you - yes by legacy I meant not upgraded one - no differe= nt meaning intended.=C2=A0 >=20 > As far as conforming to addressing architecture sorry to say bu= t to me this is red herring. Sure address must be a legal address - no qu= estion. But what bits in the address mean is really up to the person allo= cating them.=C2=A0 >=20 >=20 > unfortunately not. otherwise the postal service would have never wo= rked in the first place. The semantic concepts (and their semiotics) of n= ames/addresses & routes predate the internet by a couple of millenia and = did not shift much and we won't most likely shift them (and as side quip = the illusion of "flat" addresses as in MAC has proven unscalable yet agai= n ;-). I recommend in the context of networking the seminal 70s paper by = Schoh from Xerox. >=20 > =C2=A0on top you're logically contradicting yourself in the same se= ntence, if anybody can assign any semantics to an address in the same spa= ce because "they allocate it" then no'one can judge what is legal and wha= t isn't >=20 > And all this here is not the case of intelligence showing by holdin= g two contradicting ideas in one's head, this here is simply enshrining t= wo or more contradicting "standards" in one standards body @ which point = in time the term "standards" quickly starts to lose its meaning in first = place. >=20 > well, I said my piece, up to IAB and so on to worry about what's ha= ppening here really ... >=20 > -- tony >=20 From nobody Tue Oct 5 14:41:53 2021 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 063063A0922 for ; Tue, 5 Oct 2021 14:41:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 f6nDEUaCRAxv for ; Tue, 5 Oct 2021 14:41:48 -0700 (PDT) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (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 E698E3A0931 for ; Tue, 5 Oct 2021 14:41:47 -0700 (PDT) Received: by mail-ua1-x932.google.com with SMTP id h4so327292uaw.1 for ; Tue, 05 Oct 2021 14:41:47 -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=zKNcSZZN/cNHcI3MI2mLEt+kEJsD7OG/djlP1MzQozQ=; b=KcXHC1AWjPv4ZJbS030UoUXa0MucMauO3eaeXyZJHZ9vd/QnLtJ+Eem2+XG8XI8s7A 8XKGz9ihpyUfppoYaA8Z+knPJLoyCU2KqivuoVkhlnxByTJL7bBv6/ZM3smoce34ohRC wGNNPpVYA9z6nfHi9+SdRGuq+XpCs/rojX0+F1PM4rKphccN6OUlIzzM3UCduVcQcE0v MpbT0LQWmX/MHRRaUZPdp1Y+wQQ5jqthJ9vDJTSF0O1WoSj2PFGzTLzs6d4Lv3+lnrR6 hDf/zvKfEmBWvtfKckt7ZkQN86fXJsgXOagcWp/vedMC7RAHDg/Kt2mV3w2FvMf4lbCj mFwA== 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=zKNcSZZN/cNHcI3MI2mLEt+kEJsD7OG/djlP1MzQozQ=; b=TewIKw8WgWO+9xQ6IBcWtXjzpuIumEyj0soWf9ySAZvx4COjgSwwVuDdClj4Jb19s9 omQSd+q5Oce8IR87Kipq5EegRH2VuTN9fSWpddFxL29ybX9hyYNrA+0dbB3t2kfJGYhq X3r1tCUd9tQm7yc4DbnvpPQw8UK+qg+LQXzpzZKIEdxrFgiMZo2bt/cwCwVA4D2sL4Xw A8AsAz+VunFpsysM1XPGDhxwQPy8cwzKT0VtxoPyUIAlTmucHsFUYUITBhDlPWvc8toY Rd7ifQ5b9A+PSF+PztAIBiylVAKxe+0c+CZcUKdEA3rktXjhXF7dRbRziWqWQASQNOGP ujYg== X-Gm-Message-State: AOAM530KwO82J6kp8qsaNs60w8/ioqUUtPZIl4GMoYGksIhiAiHodoVd nBCBMgnyoSCNOrBa2+HRHlfT1lvDCwhcRbUZrFp2GA== X-Google-Smtp-Source: ABdhPJxk9FZH2lM2a3jIFCH/o0X7WdzyxDyec5DgB9QX9kAm3KjX5MQCqk3lYz+ebGyj1JRDiHM6WZAlvyQQb/curHU= X-Received: by 2002:ab0:6f03:: with SMTP id r3mr5879788uah.40.1633470106038; Tue, 05 Oct 2021 14:41:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Tue, 5 Oct 2021 23:41:38 +0200 Message-ID: To: Greg Mirsky Cc: Ron Bonica , James Guichard , SPRING WG , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006c02b105cda1e5cb" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 05 Oct 2021 21:41:52 -0000 --0000000000006c02b105cda1e5cb Content-Type: text/plain; charset="UTF-8" Greg, SRH should have an equal size SIDs. That notion applies to compress SIDs. Mixing multiple flavors in a single domain node to node seems of no use to me. Within your domain you are subject to the domain architecture which is the key factor what compression scheme is chosen. Across domains (say you own N domains) the compressed SID size may vary. Does this answer your and maybe Ron's question ? Thx, R. On Tue, Oct 5, 2021 at 11:36 PM Greg Mirsky wrote: > Hi Robert, > as I understand it, you believe everything that is written in the draft. I > hope you can help me find an answer to one simple question: > > Can a node that supports this draft in its entirety, i.e., supports all > "flavors" defined in the document, process received SRv6 packet with the > SRH encoded according to the specification? > > So far, the proponents of the draft referred to "planning" how flavors of > SRv6 SID compressed. To the best of my understanding, that is is a clear > demonstration of the incompatibility between flavors defined in the CSID > draft. Regardless of what is written in it. > > Regards, > Greg > > On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk wrote: > >> Ron & SPRING WG chairs, >> >> Through this discussion we first have seen a debate if we need one or >> more data planes to compress SIDs in SRv6. WG clearly stated we need one. >> >> Following that we have observed a first terminology shift to see if >> asking how many solutions should be supported will work any better. To that >> many WG members clearly stated that they support one solution. >> >> Well please notice that the draft in question in its introduction states: >> >> Abstract >> >> This document defines a compressed SRv6 Segment List Encoding in the >> Segment Routing Header (SRH). *This solution* does not require any >> SRH >> data plane change nor any SRv6 control plane change. *This solution* >> leverages the SRv6 Network Programming model. >> >> So based on my understanding of English the entire draft talks about a >> single solution. >> >> Then suddenly a new question popped up: how many behaviours are >> acceptable. >> >> I bet number of folks including myself said "one" keeping in mind >> previous discussions and the definition of "one" meaning based on the SRv6 >> data plane in compliance to [RFC8402], [RFC8754] and [RFC8986]. >> >> Interestingly enough the draft in question defines not behaviours but >> flavors as new variants of the already defined behaviors in Standards Track >> RFCs. Namely it defines: >> >> 4.1. NEXT-C-SID Flavor >> 4.2. REPLACE-C-SID Flavor >> >> The newly defined behaviour End.XPS is optional. >> >> So if there is anything to ask here is to check if WG is ok with two >> flavors or not. I do not recall that question has ever been asked formally >> during the WG adoption call. >> >> With that let's note that optimal compressed SID size may be different >> network to network. One size does not fit all. Draft says: >> >> 6.1. C-SID Length >> >> The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A >> * C-SID length of 16-bit is recommended.* >> >> The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths. >> * A C-SID length of 32-bit is recommended.* >> >> While I personally think 8-bit should be an option, if we choose a single >> flavor we will introduce suboptimality for no good reason. Hardware >> capable of supporting any flavor clearly can do LPM on locator. Also >> hardware capable of supporting one flavor can support few other flavors as >> this is pretty much just an offset game. >> >> Kind regards, >> Robert >> >> >> >> On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica > 40juniper.net@dmarc.ietf.org> wrote: >> >>> Pablo, >>> >>> >>> >>> Ae you sure? Please look at the question as Joel asked it ( >>> https://mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ >>> ). >>> >>> >>> >>> >>> Ron >>> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> > --0000000000006c02b105cda1e5cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greg,

SRH should have an equal size SID= s. That notion applies to compress SIDs. Mixing multiple flavors in a singl= e domain node to node seems of no use to me. Within your domain you are sub= ject to the domain architecture=C2=A0which is the key factor=C2=A0what comp= ression scheme is chosen.=C2=A0

Across domains (sa= y you own N domains) the compressed SID size may vary.=C2=A0

=
Does this answer=C2=A0your and maybe Ron's question ?=C2=A0<= /div>

Thx,
R.


On Tue, Oct = 5, 2021 at 11:36 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Robert,
as I understand it, = you believe everything that is written in the draft. I hope you can help me= find an answer to one simple question:
Can a node that supports = this draft in its entirety, i.e., supports all "flavors" defined = in the document, process received SRv6 packet with the SRH encoded accordin= g to the specification?
So far, the proponents of the dra= ft referred to "planning" how flavors of SRv6 SID compressed. To = the best of my understanding, that is is a clear demonstration of the incom= patibility between flavors defined in the CSID draft. Regardless of=C2=A0wh= at is written in it.

Regards,
Greg
=

= On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk <robert@raszuk.net> wrote:
Ron & SPRING WG chairs,

Through this discu= ssion we first have seen a debate if we need one or more data planes=C2=A0t= o compress SIDs in SRv6. WG clearly=C2=A0stated we need one.=C2=A0

Following that we have observed a first terminology shift = to see if asking how many solutions should be supported will work any bette= r. To that many WG members clearly stated that they support one solution.= =C2=A0

Well please notice that the draft in questi= on in its introduction states:=C2=A0

Abstract
<= br>=C2=A0 =C2=A0This document defines a compressed SRv6 Segment List Encodi= ng in the
=C2=A0 =C2=A0Segment Routing Header (SRH). =C2=A0This solut= ion does not require any SRH
=C2=A0 =C2=A0data plane change nor any = SRv6 control plane change. =C2=A0This solution
=C2=A0 =C2=A0lever= ages the SRv6 Network Programming model.

So ba= sed on my understanding of English the entire draft talks about a single so= lution.=C2=A0

Then suddenly a new question popped= =C2=A0up: how many behaviours are acceptable.=C2=A0

I bet number of folks including myself said "one" keeping in mi= nd previous discussions and the definition of "one" meaning based= on the SRv6 data plane in compliance to [RFC8402], [RFC8754] and [RFC8986]= .

Interestingly enough the draft in question defin= es not behaviours but flavors as new variants of the already defined behavi= ors in Standards Track RFCs. Namely it defines:=C2=A0

<= div>4.1.=C2=A0 NEXT-C-SID Flavor
4.2.=C2=A0 REPLACE-C-SID Fla= vor

The newly defined behaviour End.XPS is opt= ional.=C2=A0

So if there is anything to ask here is to check if WG i= s ok with two flavors or not. I do not recall that question has=C2=A0ever b= een asked formally during the WG adoption call.=C2=A0

<= div>With that let's note that optimal compressed SID size may be differ= ent network to network. One size does not fit all. Draft says:=C2=A0
6.1.=C2=A0 C-SID Length

=C2=A0 =C2=A0The NEXT-C-SID flavor supports= both 16- and 32-bit C-SID lengths. =C2=A0A
=C2=A0 =C2=A0C-SID length= of 16-bit is recommended.

=C2=A0 =C2=A0The REPLACE-C-SID flavor= supports both 16- and 32-bit C-SID lengths.
=C2=A0 =C2=A0A C-SID len= gth of 32-bit is recommended.

While I pers= onally think 8-bit should be an option, if we choose a single flavor we wil= l introduce suboptimality for no good reason. Hardware capable=C2=A0of supp= orting any flavor clearly can do LPM on locator. Also hardware capable of s= upporting one flavor can support few other flavors as this is pretty much j= ust an offset game.=C2=A0

Kind regards,
Robert



_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--0000000000006c02b105cda1e5cb-- From nobody Tue Oct 5 15:05:42 2021 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 E789C3A0B83; Tue, 5 Oct 2021 15:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0zvwBALqw7I; Tue, 5 Oct 2021 15:05:29 -0700 (PDT) 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 576843A0B12; Tue, 5 Oct 2021 15:05:29 -0700 (PDT) Received: by mail-ed1-x52c.google.com with SMTP id v18so2054788edc.11; Tue, 05 Oct 2021 15:05:29 -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=gBkj2bWWOcguGPKoJ7iI16fV/ZLLm1UlO0lznuZQM/0=; b=MKdpkNbdEdwktPTeLDUkjrEi272I/E9lVJDBz968g8FtJ+ofrgYWdI3XiXAGGV89Da qqvf88ReO2HE7awvRW0osLUm+B0WQMFp7jsa1wlW/je4x8UNkAPK5Oa6npaY95JFP2do h4HvMhZNHZcighJuhcTY8yewnpPh7Lr2IGtOjLkNdCaV0XOapfgE1eFYwJ75z8/6tiBQ 2d75EO2QN5zIZqugLNpbwvRu3In+xqdKu1ElZYei3NOH1p+WsjO4WY1MMwW+wVFQuC08 j9zmXbjeII+eLNNoctH29k7hU4GMEsRnyRBzvU2ldxOxNIho7sA6VZgjJh6AOJlFvBCx cngg== 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=gBkj2bWWOcguGPKoJ7iI16fV/ZLLm1UlO0lznuZQM/0=; b=JY1vkwWeZ7ualKtfho8aywkUM9aK8q7SmNFyg9Mk2igm0sa+59Ek1srKCv+lwnf77y 7jjsiI0Wbo2pKKXLFZ5cgRQ7f3NoTtwz53w+nT6BJoUmk2Ik5DgGwWX75jizGYM5agYy fmozShgju450onfyk4U3zABvQy7VAdRxZ2BtYMbOHW9WqDENKV3vHbiHgmeMmOqvvM1+ m0yMPD3yHNCU0TT4KDo1XtuEzyoTFR74/7Zsi37IzB199DSdj5OKAJYUQVA/dyIzHOEq p9IfzwtZBnaKHnGYd3eKa3UDeNU8DFBK/Al1nxl0RCoLtnBO56taktAJBg/58xYk2/fG Ba4Q== X-Gm-Message-State: AOAM5318KIJdfDY79r7z39kLQe/54esoKSpptvca+LllY3RAoYq49xRu OiU86bVXEuQX9ccTiGN/A5P0wEIFpmJ45Zjnqj6jsy9a X-Google-Smtp-Source: ABdhPJzZtd+too36DEhGipsxjPFB2cLLNLq8eFEEruh3Rb99pch+h1CF8ce7n2+NDvPlcYkXKDYiWYWnk1juCwozFQc= X-Received: by 2002:aa7:d7d2:: with SMTP id e18mr7813368eds.126.1633471527613; Tue, 05 Oct 2021 15:05:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Tue, 5 Oct 2021 15:05:14 -0700 Message-ID: To: Robert Raszuk Cc: Ron Bonica , James Guichard , SPRING WG , spring-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000027791905cda23a1b" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 05 Oct 2021 22:05:39 -0000 --00000000000027791905cda23a1b Content-Type: text/plain; charset="UTF-8" Hi Robert, sorry, but it doesn't seem to address my concern. My question is not about mixing compression flavors in the same SRH (that is an interesting case of its own). I am asking how a node that supports all the flavors defined in the draft would parse an SRv6 packet with compressed SIDs in the SRH. The impression I've got so far, is that is not possible for a node to process a SID correctly without preconditions of "planning". In other words, a controller constructs the list on the assumption that each node supports one and only one flavor of CSID compression. Thus, I can conclude, that the defined flavors are mutually exclusive and thus are different data plane techniques of the SRv6 SID compression. Regards, Greg On Tue, Oct 5, 2021, 14:41 Robert Raszuk wrote: > Greg, > > SRH should have an equal size SIDs. That notion applies to compress SIDs. > Mixing multiple flavors in a single domain node to node seems of no use to > me. Within your domain you are subject to the domain architecture which is > the key factor what compression scheme is chosen. > > Across domains (say you own N domains) the compressed SID size may vary. > > Does this answer your and maybe Ron's question ? > > Thx, > R. > > > On Tue, Oct 5, 2021 at 11:36 PM Greg Mirsky wrote: > >> Hi Robert, >> as I understand it, you believe everything that is written in the draft. >> I hope you can help me find an answer to one simple question: >> >> Can a node that supports this draft in its entirety, i.e., supports all >> "flavors" defined in the document, process received SRv6 packet with the >> SRH encoded according to the specification? >> >> So far, the proponents of the draft referred to "planning" how flavors of >> SRv6 SID compressed. To the best of my understanding, that is is a clear >> demonstration of the incompatibility between flavors defined in the CSID >> draft. Regardless of what is written in it. >> >> Regards, >> Greg >> >> On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk wrote: >> >>> Ron & SPRING WG chairs, >>> >>> Through this discussion we first have seen a debate if we need one or >>> more data planes to compress SIDs in SRv6. WG clearly stated we need one. >>> >>> Following that we have observed a first terminology shift to see if >>> asking how many solutions should be supported will work any better. To that >>> many WG members clearly stated that they support one solution. >>> >>> Well please notice that the draft in question in its introduction >>> states: >>> >>> Abstract >>> >>> This document defines a compressed SRv6 Segment List Encoding in the >>> Segment Routing Header (SRH). *This solution* does not require any >>> SRH >>> data plane change nor any SRv6 control plane change. *This solution* >>> leverages the SRv6 Network Programming model. >>> >>> So based on my understanding of English the entire draft talks about a >>> single solution. >>> >>> Then suddenly a new question popped up: how many behaviours are >>> acceptable. >>> >>> I bet number of folks including myself said "one" keeping in mind >>> previous discussions and the definition of "one" meaning based on the SRv6 >>> data plane in compliance to [RFC8402], [RFC8754] and [RFC8986]. >>> >>> Interestingly enough the draft in question defines not behaviours but >>> flavors as new variants of the already defined behaviors in Standards Track >>> RFCs. Namely it defines: >>> >>> 4.1. NEXT-C-SID Flavor >>> 4.2. REPLACE-C-SID Flavor >>> >>> The newly defined behaviour End.XPS is optional. >>> >>> So if there is anything to ask here is to check if WG is ok with two >>> flavors or not. I do not recall that question has ever been asked formally >>> during the WG adoption call. >>> >>> With that let's note that optimal compressed SID size may be different >>> network to network. One size does not fit all. Draft says: >>> >>> 6.1. C-SID Length >>> >>> The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A >>> * C-SID length of 16-bit is recommended.* >>> >>> The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths. >>> * A C-SID length of 32-bit is recommended.* >>> >>> While I personally think 8-bit should be an option, if we choose a >>> single flavor we will introduce suboptimality for no good reason. Hardware >>> capable of supporting any flavor clearly can do LPM on locator. Also >>> hardware capable of supporting one flavor can support few other flavors as >>> this is pretty much just an offset game. >>> >>> Kind regards, >>> Robert >>> >>> >>> >>> On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica >> 40juniper.net@dmarc.ietf.org> wrote: >>> >>>> Pablo, >>>> >>>> >>>> >>>> Ae you sure? Please look at the question as Joel asked it ( >>>> https://mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ >>>> ). >>>> >>>> >>>> >>>> >>>> Ron >>>> >>> _______________________________________________ >>> spring mailing list >>> spring@ietf.org >>> https://www.ietf.org/mailman/listinfo/spring >>> >> --00000000000027791905cda23a1b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Robert,
sorry,=C2=A0 but it does= n't seem to address my concern. My question is not about mixing compres= sion flavors in the same SRH (that is an interesting case of its own). I am= asking how a node that supports all the flavors defined in the draft would= parse an SRv6 packet with compressed SIDs in the SRH. The impression I'= ;ve got so far, is that is not possible for a node to process a SID correct= ly without preconditions of "planning". In other words, a control= ler constructs the list on the assumption that each node supports one and o= nly one flavor of CSID compression. Thus, I can conclude, that the defined = flavors are mutually exclusive and thus are different data plane techniques= of the SRv6 SID compression.=C2=A0

Regards,
Greg

On Tue, Oct 5, 2021,= 14:41 Robert Raszuk <robert@raszuk= .net> wrote:
Greg,

SRH should have an equal size SIDs. That notion = applies to compress SIDs. Mixing multiple flavors in a single domain node t= o node seems of no use to me. Within your domain you are subject to the dom= ain architecture=C2=A0which is the key factor=C2=A0what compression scheme = is chosen.=C2=A0

Across domains (say you own N dom= ains) the compressed SID size may vary.=C2=A0

Does= this answer=C2=A0your and maybe Ron's question ?=C2=A0

<= /div>
Thx,
R.


On Tue, Oct 5, 2021 at 11:3= 6 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Robert,as I understand it, you believe everything that is written in the draft. = I hope you can help me find an answer to one simple question:
Can= a node that supports this draft in its entirety, i.e., supports all "= flavors" defined in the document, process received SRv6 packet with th= e SRH encoded according to the specification?
So far, the= proponents of the draft referred to "planning" how flavors of SR= v6 SID compressed. To the best of my understanding, that is is a clear demo= nstration of the incompatibility between flavors defined in the CSID draft.= Regardless of=C2=A0what is written in it.

Regards= ,
Greg

On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk <rober= t@raszuk.net> wrote:
Ron & SPRING WG chairs,

Through this discussion we first have seen a debate = if we need one or more data planes=C2=A0to compress SIDs in SRv6. WG clearl= y=C2=A0stated we need one.=C2=A0

Following that we= have observed a first terminology shift to see if asking how many solution= s should be supported will work any better. To that many WG members clearly= stated that they support one solution.=C2=A0

Well= please notice that the draft in question in its introduction states:=C2=A0=

Abstract

=C2=A0 =C2=A0This document define= s a compressed SRv6 Segment List Encoding in the
=C2=A0 =C2=A0Segment Ro= uting Header (SRH). =C2=A0This solution does not require any SRH
= =C2=A0 =C2=A0data plane change nor any SRv6 control plane change. =C2=A0= This solution
=C2=A0 =C2=A0leverages the SRv6 Network Programming mo= del.

So based on my understanding of English t= he entire draft talks about a single solution.=C2=A0

Then suddenly a new question popped=C2=A0up: how many behaviours are acc= eptable.=C2=A0

I bet number of folks including mys= elf said "one" keeping in mind previous discussions and the defin= ition of "one" meaning based on the SRv6 data plane in compliance= to [RFC8402], [RFC8754] and [RFC8986].

Interestin= gly enough the draft in question defines not behaviours but flavors as new = variants of the already defined behaviors in Standards Track RFCs. Namely i= t defines:=C2=A0

4.1.=C2=A0 NEXT-C-SID Flavor
<= /div>
4.2.=C2=A0 REPLACE-C-SID Flavor

The = newly defined behaviour End.XPS is optional.=C2=A0

So if there is an= ything to ask here is to check if WG is ok with two flavors or not. I do no= t recall that question has=C2=A0ever been asked formally during the WG adop= tion call.=C2=A0

With that let's note that opt= imal compressed SID size may be different network to network. One size does= not fit all. Draft says:=C2=A0

6.1.=C2=A0 C-SID Length

=C2= =A0 =C2=A0The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths.= =C2=A0A
=C2=A0 =C2=A0C-SID length of 16-bit is recommended.
<= br>=C2=A0 =C2=A0The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID= lengths.
=C2=A0 =C2=A0A C-SID length of 32-bit is recommended.

While I personally think 8-bit should be an opt= ion, if we choose a single flavor we will introduce suboptimality for no go= od reason. Hardware capable=C2=A0of supporting any flavor clearly can do LP= M on locator. Also hardware capable of supporting one flavor can support fe= w other flavors as this is pretty much just an offset game.=C2=A0
=

Kind regards,
Robert

=


On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica <rbonica= =3D40juniper.net@dmarc.ietf.org> wrote:
_______________________________________________
spring mailing list
spr= ing@ietf.org
https://www.ietf.org/mailman/listinfo/spring<= /a>
--00000000000027791905cda23a1b-- From nobody Tue Oct 5 15:07:53 2021 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 E384B3A0AF9 for ; Tue, 5 Oct 2021 15:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 YP-N5cDFdGXm for ; Tue, 5 Oct 2021 15:07:45 -0700 (PDT) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 7387E3A0B05 for ; Tue, 5 Oct 2021 15:07:45 -0700 (PDT) Received: by mail-vs1-xe33.google.com with SMTP id p2so809647vst.10 for ; Tue, 05 Oct 2021 15:07:45 -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=zK/f8SjeMuDFbbrQBjens/FLl/vofyEHNqz4Rb9wz2M=; b=W+fdt8wxAxwFKNoi8daWQiFphZEKchJwP9uB8mYj+paE8UsavrbDMmCjhpnGlhCUOZ EmgGTblavwzP7Gmg1zgS/AMwA3lNNzACzYXIDRZjByyqpXwHMXYkkAD+K/KeZNDCE531 TAC91R6Yaji2O2DE4ArJQbESq9uq5Zc1rcS4sw0dRJXDIwXIhwi3g6Uoz77/ym698E1P w1KenmFmHG3RfI7zcGazPuT1rH1OtFsPiqWWlLRSHOqScd9JNaE74Y6/uUxsI5Z4dpce VBXiyVLA3VBYM02Nn/mXKcc7+DDDhJglOWC0pUbIXxnOKtb3M2pDHPVJvUEGVDHaFAC7 LD4A== 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=zK/f8SjeMuDFbbrQBjens/FLl/vofyEHNqz4Rb9wz2M=; b=RDRdzf0Ku0sS1evRMp/CBAEHM1KLfNSKuCKuGSUtMMTpH8rwresa9mAMvqAx3oU7Bd S+6ZdOttr9le2T7ZZuJ/nO3e5B/KQCeYYjyCCZEVyn7UToDBOGj8Aapz+1KAEMFa2qzk vzsGs0yBRmoX6Tug2PlAnNhOd7RTLIALX8qDAcY8/pIkaC1viHJZCRFE40WcqJ9PRK2a As5jrPRWzqsBPuNMA7PWyCWNlKcwnoFfa1Jd2pI5HThcEjENPzXRDZ/N2DTcxLmhacS7 3olcealfO+ll5YmeRLwtn6lrelf0VMqmC9QDN3Hsu0gNUr/6LdyKkf1eUvjN7ng2h7h7 7CPQ== X-Gm-Message-State: AOAM530qtO9yNZOdkpeYsMQUtGzB37nO8zlUw57s0BipIiw6y0WO8C0H r4ded0RdXvUTx5l3q8f+7CPfN+CpDNcdV+0hgYg4wg== X-Google-Smtp-Source: ABdhPJyo8glAiqca5htTQMSSDNePPPcB69odYlmFLJhT9O234JOvIoK6clWJh2HUp2+uJFANPTIZ8Dt2zj+8cuToWJA= X-Received: by 2002:a67:2283:: with SMTP id i125mr4973433vsi.50.1633471664325; Tue, 05 Oct 2021 15:07:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Wed, 6 Oct 2021 00:07:36 +0200 Message-ID: To: Greg Mirsky Cc: Ron Bonica , James Guichard , SPRING WG , spring-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000004d9e3e05cda24269" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 05 Oct 2021 22:07:51 -0000 --0000000000004d9e3e05cda24269 Content-Type: text/plain; charset="UTF-8" To me the easiest option here is to simply configure on each node selected compression schema for the domain. Do you see anything wrong with it ? On Wed, Oct 6, 2021 at 12:05 AM Greg Mirsky wrote: > Hi Robert, > sorry, but it doesn't seem to address my concern. My question is not > about mixing compression flavors in the same SRH (that is an interesting > case of its own). I am asking how a node that supports all the flavors > defined in the draft would parse an SRv6 packet with compressed SIDs in the > SRH. The impression I've got so far, is that is not possible for a node to > process a SID correctly without preconditions of "planning". In other > words, a controller constructs the list on the assumption that each node > supports one and only one flavor of CSID compression. Thus, I can conclude, > that the defined flavors are mutually exclusive and thus are different data > plane techniques of the SRv6 SID compression. > > Regards, > Greg > > On Tue, Oct 5, 2021, 14:41 Robert Raszuk wrote: > >> Greg, >> >> SRH should have an equal size SIDs. That notion applies to compress SIDs. >> Mixing multiple flavors in a single domain node to node seems of no use to >> me. Within your domain you are subject to the domain architecture which is >> the key factor what compression scheme is chosen. >> >> Across domains (say you own N domains) the compressed SID size may vary. >> >> Does this answer your and maybe Ron's question ? >> >> Thx, >> R. >> >> >> On Tue, Oct 5, 2021 at 11:36 PM Greg Mirsky >> wrote: >> >>> Hi Robert, >>> as I understand it, you believe everything that is written in the draft. >>> I hope you can help me find an answer to one simple question: >>> >>> Can a node that supports this draft in its entirety, i.e., supports all >>> "flavors" defined in the document, process received SRv6 packet with the >>> SRH encoded according to the specification? >>> >>> So far, the proponents of the draft referred to "planning" how flavors >>> of SRv6 SID compressed. To the best of my understanding, that is is a clear >>> demonstration of the incompatibility between flavors defined in the CSID >>> draft. Regardless of what is written in it. >>> >>> Regards, >>> Greg >>> >>> On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk wrote: >>> >>>> Ron & SPRING WG chairs, >>>> >>>> Through this discussion we first have seen a debate if we need one or >>>> more data planes to compress SIDs in SRv6. WG clearly stated we need one. >>>> >>>> Following that we have observed a first terminology shift to see if >>>> asking how many solutions should be supported will work any better. To that >>>> many WG members clearly stated that they support one solution. >>>> >>>> Well please notice that the draft in question in its introduction >>>> states: >>>> >>>> Abstract >>>> >>>> This document defines a compressed SRv6 Segment List Encoding in the >>>> Segment Routing Header (SRH). *This solution* does not require any >>>> SRH >>>> data plane change nor any SRv6 control plane change. *This >>>> solution* >>>> leverages the SRv6 Network Programming model. >>>> >>>> So based on my understanding of English the entire draft talks about a >>>> single solution. >>>> >>>> Then suddenly a new question popped up: how many behaviours are >>>> acceptable. >>>> >>>> I bet number of folks including myself said "one" keeping in mind >>>> previous discussions and the definition of "one" meaning based on the SRv6 >>>> data plane in compliance to [RFC8402], [RFC8754] and [RFC8986]. >>>> >>>> Interestingly enough the draft in question defines not behaviours but >>>> flavors as new variants of the already defined behaviors in Standards Track >>>> RFCs. Namely it defines: >>>> >>>> 4.1. NEXT-C-SID Flavor >>>> 4.2. REPLACE-C-SID Flavor >>>> >>>> The newly defined behaviour End.XPS is optional. >>>> >>>> So if there is anything to ask here is to check if WG is ok with two >>>> flavors or not. I do not recall that question has ever been asked formally >>>> during the WG adoption call. >>>> >>>> With that let's note that optimal compressed SID size may be different >>>> network to network. One size does not fit all. Draft says: >>>> >>>> 6.1. C-SID Length >>>> >>>> The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A >>>> * C-SID length of 16-bit is recommended.* >>>> >>>> The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths. >>>> * A C-SID length of 32-bit is recommended.* >>>> >>>> While I personally think 8-bit should be an option, if we choose a >>>> single flavor we will introduce suboptimality for no good reason. Hardware >>>> capable of supporting any flavor clearly can do LPM on locator. Also >>>> hardware capable of supporting one flavor can support few other flavors as >>>> this is pretty much just an offset game. >>>> >>>> Kind regards, >>>> Robert >>>> >>>> >>>> >>>> On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica >>> 40juniper.net@dmarc.ietf.org> wrote: >>>> >>>>> Pablo, >>>>> >>>>> >>>>> >>>>> Ae you sure? Please look at the question as Joel asked it ( >>>>> https://mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ >>>>> ). >>>>> >>>>> >>>>> >>>>> >>>>> Ron >>>>> >>>> _______________________________________________ >>>> spring mailing list >>>> spring@ietf.org >>>> https://www.ietf.org/mailman/listinfo/spring >>>> >>> --0000000000004d9e3e05cda24269 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
To me the easiest option here is to simply configure on ea= ch node selected compression schema for the domain. Do you see anything wro= ng with it ?=C2=A0

On Wed, Oct 6, 2021 at 12:05 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
<= /div>
Hi= =C2=A0Robert,
sorry,=C2=A0 but it doesn't seem to addr= ess my concern. My question is not about mixing compression flavors in the = same SRH (that is an interesting case of its own). I am asking how a node t= hat supports all the flavors defined in the draft would parse an SRv6 packe= t with compressed SIDs in the SRH. The impression I've got so far, is t= hat is not possible for a node to process a SID correctly without precondit= ions of "planning". In other words, a controller constructs the l= ist on the assumption that each node supports one and only one flavor of CS= ID compression. Thus, I can conclude, that the defined flavors are mutually= exclusive and thus are different data plane techniques of the SRv6 SID com= pression.=C2=A0

Regards,=
Greg

On Tue, Oct 5, 2021, 14:41 Robert Raszuk = <robert@raszuk.ne= t> wrote:
Greg,

SRH should have an equal size SI= Ds. That notion applies to compress SIDs. Mixing multiple flavors in a sing= le domain node to node seems of no use to me. Within your domain you are su= bject to the domain architecture=C2=A0which is the key factor=C2=A0what com= pression scheme is chosen.=C2=A0

Across domains (s= ay you own N domains) the compressed SID size may vary.=C2=A0
Does this answer=C2=A0your and maybe Ron's question ?=C2=A0=

Thx,
R.


<= div class=3D"gmail_quote">
On Tue, Oct= 5, 2021 at 11:36 PM Greg Mirsky <gregimirsky@gmail.com> wrote= :
Hi Robert,
as I understand it, you believe everything that is writte= n in the draft. I hope you can help me find an answer to one simple questio= n:
Can a node that supports this draft in its entirety, i.e., sup= ports all "flavors" defined in the document, process received SRv= 6 packet with the SRH encoded according to the specification?
So far, the proponents of the draft referred to "planning" h= ow flavors of SRv6 SID compressed. To the best of my understanding, that is= is a clear demonstration of the incompatibility between flavors defined in= the CSID draft. Regardless of=C2=A0what is written in it.

Regards,
Greg

=
On Tue, Oct 5, 2021 at 1:24 PM Robert= Raszuk <robert@raszuk.net> wrote:
Ron & SP= RING WG chairs,

Through this discussion we first ha= ve seen a debate if we need one or more data planes=C2=A0to compress SIDs i= n SRv6. WG clearly=C2=A0stated we need one.=C2=A0

= Following that we have observed a first terminology shift to see if asking = how many solutions should be supported will work any better. To that many W= G members clearly stated that they support one solution.=C2=A0
Well please notice that the draft in question in its introduct= ion states:=C2=A0

Abstract

=C2=A0 =C2=A0Thi= s document defines a compressed SRv6 Segment List Encoding in the
=C2=A0= =C2=A0Segment Routing Header (SRH). =C2=A0This solution does not re= quire any SRH
=C2=A0 =C2=A0data plane change nor any SRv6 control plane = change. =C2=A0This solution
=C2=A0 =C2=A0leverages the SRv6 Netwo= rk Programming model.

So based on my understan= ding of English the entire draft talks about a single solution.=C2=A0
=

Then suddenly a new question popped=C2=A0up: how many b= ehaviours are acceptable.=C2=A0

I bet number of fo= lks including myself said "one" keeping in mind previous discussi= ons and the definition of "one" meaning based on the SRv6 data pl= ane in compliance to [RFC8402], [RFC8754] and [RFC8986].

Interestingly enough the draft in question defines not behaviours bu= t flavors as new variants of the already defined behaviors in Standards Tra= ck RFCs. Namely it defines:=C2=A0

4.1.=C2=A0 NEXT-= C-SID Flavor
4.2.=C2=A0 REPLACE-C-SID Flavor
The newly defined behaviour End.XPS is optional.=C2=A0

= So if there is anything to ask here is to check if WG is ok with two flavor= s or not. I do not recall that question has=C2=A0ever been asked formally d= uring the WG adoption call.=C2=A0

With that let= 9;s note that optimal compressed SID size may be different network to netwo= rk. One size does not fit all. Draft says:=C2=A0

6.1.=C2=A0 C-SID Le= ngth

=C2=A0 =C2=A0The NEXT-C-SID flavor supports both 16- and 32-bit= C-SID lengths. =C2=A0A
=C2=A0 =C2=A0C-SID length of 16-bit is recomm= ended.

=C2=A0 =C2=A0The REPLACE-C-SID flavor supports both 16- a= nd 32-bit C-SID lengths.
=C2=A0 =C2=A0A C-SID length of 32-bit is rec= ommended.

While I personally think 8-bit s= hould be an option, if we choose a single flavor we will introduce suboptim= ality for no good reason. Hardware capable=C2=A0of supporting any flavor cl= early can do LPM on locator. Also hardware capable of supporting one flavor= can support few other flavors as this is pretty much just an offset game.= =C2=A0

Kind regards,
Rober= t



<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Oct 5, 2021 at 9:43 PM Ron Bon= ica <rbonica=3D40juniper.net@dmarc.ietf.org> wrote:
=
_______________________________________________
spring mailing list
spr= ing@ietf.org
https://www.ietf.org/mailman/listinfo/spring<= /a>
--0000000000004d9e3e05cda24269-- From nobody Tue Oct 5 15:11:38 2021 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 806FB3A0B6B; Tue, 5 Oct 2021 15:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 pNqCH95EG38s; Tue, 5 Oct 2021 15:11:30 -0700 (PDT) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00CC73A0B66; Tue, 5 Oct 2021 15:11:29 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id g8so2172344edt.7; Tue, 05 Oct 2021 15:11:29 -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=E9burHMgkOwCSwh06FYHy+EVxmq+xkkbgOGie6G9oxs=; b=FgDvDvcR9t2qk9vyDCJ4Cm5QZTcG0eJtxBuiWmxeVZORx2ImYJCXWE5yvvUMV9CFiX l+BgqCbCIaI/wETkunDDHR7Ky+/Qc+47PzT2Fkzwq1Uqa2Rq3T+6zfKhN8s3j/SbLu/8 6N9x7aYb9eSXXd4icD9imipvAn8u9dX5UPrg1/HEuppNwYFQuD0N6coj+F0HlLr7Rki7 p6I+gkhzyAANeSOIHP9la65RZ3VupFS3vcM6IebYlBgHfNnWdkDugMhybNO2isXLCelj /jdkpymXeQVKHEMSUg5z5VOHmaIoxeJWjSTN5hZ5UDGPWZNx1JedC3PqfpP2RU324yiK nVkg== 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=E9burHMgkOwCSwh06FYHy+EVxmq+xkkbgOGie6G9oxs=; b=jfVqbpLUY+26NEV2pXaVjLgGG8lvi9mSJeR435t1aTnfYkpha2AxzJ6KojpVdTNKKY ha4a7SemAFW1E0IjPc+9kWqJihHCa1IGtFsmo0xJ8LuhL+f7GMTOsCO10izSkRCVMSyl oygdk0gi6eGn42oqPY2TmrdBjEhkCYvDu/iJNOcJBidLf+qMookUV+Uqcob0ItDhZ/gM pc0wjpJ7Cj29egMG9HwfDfYiFPIHA6esog34TXaVRBPZY+3/fnDJgPlh0FflonXwSPuR drlIiy3yrD2pfuKGLrL0i53hxBseBWKVt8Ph/J6WhlKD2VTfJsA1KzCPJGKIIlPh7RYp oEvQ== X-Gm-Message-State: AOAM530TMRJjZ62xMQ6Yg26ga2cvN6mqvv9ieTdMPCxVgnc485Wqf9t8 KAjJL4ZJ7KY3mT8q+pp8QPE1/Pc58eV/MI7dK0YObNAd X-Google-Smtp-Source: ABdhPJxVr2F5K3FRLu177+U+85a6LU0PTUw31gwZ8ROSD3fA8VkcMkSxSjUlsG3T4fdVU/j3ltjSOaIteYU3JFNSI1Q= X-Received: by 2002:a17:906:784:: with SMTP id l4mr27027210ejc.469.1633471888232; Tue, 05 Oct 2021 15:11:28 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Tue, 5 Oct 2021 15:11:16 -0700 Message-ID: To: Robert Raszuk Cc: Ron Bonica , James Guichard , SPRING WG , spring-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000a6160405cda24fad" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 05 Oct 2021 22:11:36 -0000 --000000000000a6160405cda24fad Content-Type: text/plain; charset="UTF-8" I am not asking how to deal with the fact that the mode cannot manage different flavors using just information that is in the packet. I am pointing that out and you are trying to avoid to acknowledge that the problem exists. That's your choice. Regards, Greg On Tue, Oct 5, 2021, 15:07 Robert Raszuk wrote: > To me the easiest option here is to simply configure on each node selected > compression schema for the domain. Do you see anything wrong with it ? > > On Wed, Oct 6, 2021 at 12:05 AM Greg Mirsky wrote: > >> Hi Robert, >> sorry, but it doesn't seem to address my concern. My question is not >> about mixing compression flavors in the same SRH (that is an interesting >> case of its own). I am asking how a node that supports all the flavors >> defined in the draft would parse an SRv6 packet with compressed SIDs in the >> SRH. The impression I've got so far, is that is not possible for a node to >> process a SID correctly without preconditions of "planning". In other >> words, a controller constructs the list on the assumption that each node >> supports one and only one flavor of CSID compression. Thus, I can conclude, >> that the defined flavors are mutually exclusive and thus are different data >> plane techniques of the SRv6 SID compression. >> >> Regards, >> Greg >> >> On Tue, Oct 5, 2021, 14:41 Robert Raszuk wrote: >> >>> Greg, >>> >>> SRH should have an equal size SIDs. That notion applies to compress >>> SIDs. Mixing multiple flavors in a single domain node to node seems of no >>> use to me. Within your domain you are subject to the domain >>> architecture which is the key factor what compression scheme is chosen. >>> >>> Across domains (say you own N domains) the compressed SID size may vary. >>> >>> Does this answer your and maybe Ron's question ? >>> >>> Thx, >>> R. >>> >>> >>> On Tue, Oct 5, 2021 at 11:36 PM Greg Mirsky >>> wrote: >>> >>>> Hi Robert, >>>> as I understand it, you believe everything that is written in the >>>> draft. I hope you can help me find an answer to one simple question: >>>> >>>> Can a node that supports this draft in its entirety, i.e., supports all >>>> "flavors" defined in the document, process received SRv6 packet with the >>>> SRH encoded according to the specification? >>>> >>>> So far, the proponents of the draft referred to "planning" how flavors >>>> of SRv6 SID compressed. To the best of my understanding, that is is a clear >>>> demonstration of the incompatibility between flavors defined in the CSID >>>> draft. Regardless of what is written in it. >>>> >>>> Regards, >>>> Greg >>>> >>>> On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk wrote: >>>> >>>>> Ron & SPRING WG chairs, >>>>> >>>>> Through this discussion we first have seen a debate if we need one or >>>>> more data planes to compress SIDs in SRv6. WG clearly stated we need one. >>>>> >>>>> Following that we have observed a first terminology shift to see if >>>>> asking how many solutions should be supported will work any better. To that >>>>> many WG members clearly stated that they support one solution. >>>>> >>>>> Well please notice that the draft in question in its introduction >>>>> states: >>>>> >>>>> Abstract >>>>> >>>>> This document defines a compressed SRv6 Segment List Encoding in the >>>>> Segment Routing Header (SRH). *This solution* does not require >>>>> any SRH >>>>> data plane change nor any SRv6 control plane change. *This >>>>> solution* >>>>> leverages the SRv6 Network Programming model. >>>>> >>>>> So based on my understanding of English the entire draft talks about a >>>>> single solution. >>>>> >>>>> Then suddenly a new question popped up: how many behaviours are >>>>> acceptable. >>>>> >>>>> I bet number of folks including myself said "one" keeping in mind >>>>> previous discussions and the definition of "one" meaning based on the SRv6 >>>>> data plane in compliance to [RFC8402], [RFC8754] and [RFC8986]. >>>>> >>>>> Interestingly enough the draft in question defines not behaviours but >>>>> flavors as new variants of the already defined behaviors in Standards Track >>>>> RFCs. Namely it defines: >>>>> >>>>> 4.1. NEXT-C-SID Flavor >>>>> 4.2. REPLACE-C-SID Flavor >>>>> >>>>> The newly defined behaviour End.XPS is optional. >>>>> >>>>> So if there is anything to ask here is to check if WG is ok with two >>>>> flavors or not. I do not recall that question has ever been asked formally >>>>> during the WG adoption call. >>>>> >>>>> With that let's note that optimal compressed SID size may be different >>>>> network to network. One size does not fit all. Draft says: >>>>> >>>>> 6.1. C-SID Length >>>>> >>>>> The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A >>>>> * C-SID length of 16-bit is recommended.* >>>>> >>>>> The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths. >>>>> * A C-SID length of 32-bit is recommended.* >>>>> >>>>> While I personally think 8-bit should be an option, if we choose a >>>>> single flavor we will introduce suboptimality for no good reason. Hardware >>>>> capable of supporting any flavor clearly can do LPM on locator. Also >>>>> hardware capable of supporting one flavor can support few other flavors as >>>>> this is pretty much just an offset game. >>>>> >>>>> Kind regards, >>>>> Robert >>>>> >>>>> >>>>> >>>>> On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica >>>> 40juniper.net@dmarc.ietf.org> wrote: >>>>> >>>>>> Pablo, >>>>>> >>>>>> >>>>>> >>>>>> Ae you sure? Please look at the question as Joel asked it ( >>>>>> https://mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ >>>>>> ). >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Ron >>>>>> >>>>> _______________________________________________ >>>>> spring mailing list >>>>> spring@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/spring >>>>> >>>> --000000000000a6160405cda24fad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am not asking how to deal with the fact that the mode c= annot manage different flavors using just information that is in the packet= . I am pointing that out and you are trying to avoid to acknowledge that th= e problem exists. That's your choice.=C2=A0

=
Regards,
Greg

On Tue, Oct 5, = 2021, 15:07 Robert Raszuk <robert@r= aszuk.net> wrote:
To me the easiest option here is to simply configure on each node = selected compression schema for the domain. Do you see anything wrong with = it ?=C2=A0

On Wed, Oct 6, 2021 at 12:05 AM Greg Mirsky <gregimirsky@gm= ail.com> wrote:
Hi=C2=A0Robert,
sorry,=C2=A0 but = it doesn't seem to address my concern. My question is not about mixing = compression flavors in the same SRH (that is an interesting case of its own= ). I am asking how a node that supports all the flavors defined in the draf= t would parse an SRv6 packet with compressed SIDs in the SRH. The impressio= n I've got so far, is that is not possible for a node to process a SID = correctly without preconditions of "planning". In other words, a = controller constructs the list on the assumption that each node supports on= e and only one flavor of CSID compression. Thus, I can conclude, that the d= efined flavors are mutually exclusive and thus are different data plane tec= hniques of the SRv6 SID compression.=C2=A0

Regards,
Greg

On Tue, Oct 5,= 2021, 14:41 Robert Raszuk <robert@raszuk.net> wrote:
Greg,
=
SRH should have an equal size SIDs. That notion applies to c= ompress SIDs. Mixing multiple flavors in a single domain node to node seems= of no use to me. Within your domain you are subject to the domain architec= ture=C2=A0which is the key factor=C2=A0what compression scheme is chosen.= =C2=A0

Across domains (say you own N domains) the = compressed SID size may vary.=C2=A0

Does this answ= er=C2=A0your and maybe Ron's question ?=C2=A0

= Thx,
R.


=
On Tue, Oct 5, 2021 at 11:36 PM Greg = Mirsky <gregimirsky@gmail.com> wrote:
Hi Robert,as I understand it, you believe everything that is written in the draft.= I hope you can help me find an answer to one simple question:
Ca= n a node that supports this draft in its entirety, i.e., supports all "= ;flavors" defined in the document, process received SRv6 packet with t= he SRH encoded according to the specification?
So far, th= e proponents of the draft referred to "planning" how flavors of S= Rv6 SID compressed. To the best of my understanding, that is is a clear dem= onstration of the incompatibility between flavors defined in the CSID draft= . Regardless of=C2=A0what is written in it.

Regard= s,
Greg

On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk <robert@raszuk.net> wrote:
Ron & SPRING = WG chairs,

Through this discussion we first have se= en a debate if we need one or more data planes=C2=A0to compress SIDs in SRv= 6. WG clearly=C2=A0stated we need one.=C2=A0

Follo= wing that we have observed a first terminology shift to see if asking how m= any solutions should be supported will work any better. To that many WG mem= bers clearly stated that they support one solution.=C2=A0

Well please notice that the draft in question in its introduction s= tates:=C2=A0

Abstract

=C2=A0 =C2=A0This doc= ument defines a compressed SRv6 Segment List Encoding in the
=C2=A0 =C2= =A0Segment Routing Header (SRH). =C2=A0This solution does not requir= e any SRH
=C2=A0 =C2=A0data plane change nor any SRv6 control plane chan= ge. =C2=A0This solution
=C2=A0 =C2=A0leverages the SRv6 Network P= rogramming model.

So based on my understanding= of English the entire draft talks about a single solution.=C2=A0

Then suddenly a new question popped=C2=A0up: how many behav= iours are acceptable.=C2=A0

I bet number of folks = including myself said "one" keeping in mind previous discussions = and the definition of "one" meaning based on the SRv6 data plane = in compliance to [RFC8402], [RFC8754] and [RFC8986].

Interestingly enough the draft in question defines not behaviours but fl= avors as new variants of the already defined behaviors in Standards Track R= FCs. Namely it defines:=C2=A0

4.1.=C2=A0 NEXT-C-SI= D Flavor
4.2.=C2=A0 REPLACE-C-SID Flavor

The newly defined behaviour End.XPS is optional.=C2=A0

So i= f there is anything to ask here is to check if WG is ok with two flavors or= not. I do not recall that question has=C2=A0ever been asked formally durin= g the WG adoption call.=C2=A0

With that let's = note that optimal compressed SID size may be different network to network. = One size does not fit all. Draft says:=C2=A0

6.1.=C2=A0 C-SID Length=

=C2=A0 =C2=A0The NEXT-C-SID flavor supports both 16- and 32-bit C-S= ID lengths. =C2=A0A
=C2=A0 =C2=A0C-SID length of 16-bit is recommende= d.

=C2=A0 =C2=A0The REPLACE-C-SID flavor supports both 16- and 3= 2-bit C-SID lengths.
=C2=A0 =C2=A0A C-SID length of 32-bit is recomme= nded.

While I personally think 8-bit shoul= d be an option, if we choose a single flavor we will introduce suboptimalit= y for no good reason. Hardware capable=C2=A0of supporting any flavor clearl= y can do LPM on locator. Also hardware capable of supporting one flavor can= support few other flavors as this is pretty much just an offset game.=C2= =A0

Kind regards,
Robert



On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica= <rbonica=3D40juniper.net@dmarc.ietf.org> wr= ote:
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listi= nfo/spring
--000000000000a6160405cda24fad-- From nobody Tue Oct 5 15:17:39 2021 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 9FF3C3A0B9E for ; Tue, 5 Oct 2021 15:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 0eeNMi0qDlpn for ; Tue, 5 Oct 2021 15:17:32 -0700 (PDT) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 266243A0B9C for ; Tue, 5 Oct 2021 15:17:32 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id p18so747582vsu.7 for ; Tue, 05 Oct 2021 15:17:32 -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=30xxQKaIBFIcs9bFSqTiDw4QV2b+02fQ0omzXhpflgk=; b=aKMGoiHwVoaEj2uW9TgS8nEKxCDBRBqTFsmV+igNv4UKxRezDGXL8EOuGM34UlwMBx oRCct1/pki5axNk1IXuZSd9EgBDsuwkbkK5H9VkfgodARoSSMmrzva6MctOlzUZJ9G7v J3fT3kZ6CThkJm42fJcy7TKPLRw7wlSlU+Bi0Y5Q2zyu2ReC/PEe2HzjY846Yv29SuRh Z4VHTiHQZGHo1k3MBexxJsGgLJSxuh7Q0C3N+FOzRxMDmmoPQbYG+rb8eJ4NpGL96Not lKmAHJpvwJyKuPXRg5Anjd1oT/xETViYE4NUoG/lS51xGuZS300W0Q2mx3LPZZaoZ0NE fhSw== 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=30xxQKaIBFIcs9bFSqTiDw4QV2b+02fQ0omzXhpflgk=; b=YYuQNcZ+kEBrx1ib/isjAL37fVPmP1wA2s+f/0Mbtq84NW6zZkJIPF9INVbfCaruG8 gitHK0FCeS6pvhY59ViyEP9lj3j/Zb8WLhEujC/MU86tMBnvRvwRCErRlPQNcYacATf2 NqoOEbvg3bLsFfYJDKcoR0KSD8yxzDWtLFuQK+5shz6vsZNK2sfd8p/B+vYEzHb1hbT+ G37qDT4tZFTl12pE8r1V4ot6ni4DLVlKhJxnEjteSxguh+hkp/y20tBrA7JDmohExsXU sto1qjW18UCR0FNjMLJAQVzl7coPbvUWXZkYS13w4Nz32NuOltK2X8+nlSNYiQrDyfIc wvMg== X-Gm-Message-State: AOAM532jioCc3QNCTlbsG0ivK4uDQAiSfmCMDJnpyq39CTnts/lNYL0i Zc86cTzQP6q5nQzbmWvFbY/QCXRdU8ehGWFF17FqhQ== X-Google-Smtp-Source: ABdhPJzhijOfqqxSkn6/HJJdQfyOYAZodVXleMEMwq2reQaIq9021Euc7h+MOQoKxYfBhFe7YeCxBUsWy11taalTbgo= X-Received: by 2002:a67:2283:: with SMTP id i125mr5032075vsi.50.1633472249819; Tue, 05 Oct 2021 15:17:29 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Wed, 6 Oct 2021 00:17:21 +0200 Message-ID: To: Greg Mirsky Cc: Ron Bonica , James Guichard , SPRING WG , spring-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000033915405cda265e9" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 05 Oct 2021 22:17:37 -0000 --00000000000033915405cda265e9 Content-Type: text/plain; charset="UTF-8" That's not the case. You can map locator prefix to specific compression schema used as an example ... This is pure implementation choice - I would say vendor's secret sauce. On Wed, Oct 6, 2021 at 12:11 AM Greg Mirsky wrote: > I am not asking how to deal with the fact that the mode cannot manage > different flavors using just information that is in the packet. I am > pointing that out and you are trying to avoid to acknowledge that the > problem exists. That's your choice. > > Regards, > Greg > > On Tue, Oct 5, 2021, 15:07 Robert Raszuk wrote: > >> To me the easiest option here is to simply configure on each node >> selected compression schema for the domain. Do you see anything wrong with >> it ? >> >> On Wed, Oct 6, 2021 at 12:05 AM Greg Mirsky >> wrote: >> >>> Hi Robert, >>> sorry, but it doesn't seem to address my concern. My question is not >>> about mixing compression flavors in the same SRH (that is an interesting >>> case of its own). I am asking how a node that supports all the flavors >>> defined in the draft would parse an SRv6 packet with compressed SIDs in the >>> SRH. The impression I've got so far, is that is not possible for a node to >>> process a SID correctly without preconditions of "planning". In other >>> words, a controller constructs the list on the assumption that each node >>> supports one and only one flavor of CSID compression. Thus, I can conclude, >>> that the defined flavors are mutually exclusive and thus are different data >>> plane techniques of the SRv6 SID compression. >>> >>> Regards, >>> Greg >>> >>> On Tue, Oct 5, 2021, 14:41 Robert Raszuk wrote: >>> >>>> Greg, >>>> >>>> SRH should have an equal size SIDs. That notion applies to compress >>>> SIDs. Mixing multiple flavors in a single domain node to node seems of no >>>> use to me. Within your domain you are subject to the domain >>>> architecture which is the key factor what compression scheme is chosen. >>>> >>>> Across domains (say you own N domains) the compressed SID size may >>>> vary. >>>> >>>> Does this answer your and maybe Ron's question ? >>>> >>>> Thx, >>>> R. >>>> >>>> >>>> On Tue, Oct 5, 2021 at 11:36 PM Greg Mirsky >>>> wrote: >>>> >>>>> Hi Robert, >>>>> as I understand it, you believe everything that is written in the >>>>> draft. I hope you can help me find an answer to one simple question: >>>>> >>>>> Can a node that supports this draft in its entirety, i.e., supports >>>>> all "flavors" defined in the document, process received SRv6 packet with >>>>> the SRH encoded according to the specification? >>>>> >>>>> So far, the proponents of the draft referred to "planning" how flavors >>>>> of SRv6 SID compressed. To the best of my understanding, that is is a clear >>>>> demonstration of the incompatibility between flavors defined in the CSID >>>>> draft. Regardless of what is written in it. >>>>> >>>>> Regards, >>>>> Greg >>>>> >>>>> On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk >>>>> wrote: >>>>> >>>>>> Ron & SPRING WG chairs, >>>>>> >>>>>> Through this discussion we first have seen a debate if we need one or >>>>>> more data planes to compress SIDs in SRv6. WG clearly stated we need one. >>>>>> >>>>>> Following that we have observed a first terminology shift to see if >>>>>> asking how many solutions should be supported will work any better. To that >>>>>> many WG members clearly stated that they support one solution. >>>>>> >>>>>> Well please notice that the draft in question in its introduction >>>>>> states: >>>>>> >>>>>> Abstract >>>>>> >>>>>> This document defines a compressed SRv6 Segment List Encoding in >>>>>> the >>>>>> Segment Routing Header (SRH). *This solution* does not require >>>>>> any SRH >>>>>> data plane change nor any SRv6 control plane change. *This >>>>>> solution* >>>>>> leverages the SRv6 Network Programming model. >>>>>> >>>>>> So based on my understanding of English the entire draft talks about >>>>>> a single solution. >>>>>> >>>>>> Then suddenly a new question popped up: how many behaviours are >>>>>> acceptable. >>>>>> >>>>>> I bet number of folks including myself said "one" keeping in mind >>>>>> previous discussions and the definition of "one" meaning based on the SRv6 >>>>>> data plane in compliance to [RFC8402], [RFC8754] and [RFC8986]. >>>>>> >>>>>> Interestingly enough the draft in question defines not behaviours but >>>>>> flavors as new variants of the already defined behaviors in Standards Track >>>>>> RFCs. Namely it defines: >>>>>> >>>>>> 4.1. NEXT-C-SID Flavor >>>>>> 4.2. REPLACE-C-SID Flavor >>>>>> >>>>>> The newly defined behaviour End.XPS is optional. >>>>>> >>>>>> So if there is anything to ask here is to check if WG is ok with two >>>>>> flavors or not. I do not recall that question has ever been asked formally >>>>>> during the WG adoption call. >>>>>> >>>>>> With that let's note that optimal compressed SID size may be >>>>>> different network to network. One size does not fit all. Draft says: >>>>>> >>>>>> 6.1. C-SID Length >>>>>> >>>>>> The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. >>>>>> A >>>>>> * C-SID length of 16-bit is recommended.* >>>>>> >>>>>> The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID >>>>>> lengths. >>>>>> * A C-SID length of 32-bit is recommended.* >>>>>> >>>>>> While I personally think 8-bit should be an option, if we choose a >>>>>> single flavor we will introduce suboptimality for no good reason. Hardware >>>>>> capable of supporting any flavor clearly can do LPM on locator. Also >>>>>> hardware capable of supporting one flavor can support few other flavors as >>>>>> this is pretty much just an offset game. >>>>>> >>>>>> Kind regards, >>>>>> Robert >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica >>>>> 40juniper.net@dmarc.ietf.org> wrote: >>>>>> >>>>>>> Pablo, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Ae you sure? Please look at the question as Joel asked it ( >>>>>>> https://mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ >>>>>>> ). >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Ron >>>>>>> >>>>>> _______________________________________________ >>>>>> spring mailing list >>>>>> spring@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/spring >>>>>> >>>>> --00000000000033915405cda265e9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's not the case. You can map locator=C2=A0prefix t= o specific compression schema used as an example ... This is pure implement= ation choice - I would say vendor's secret sauce.=C2=A0

On Wed, Oct 6, 2= 021 at 12:11 AM Greg Mirsky <gr= egimirsky@gmail.com> wrote:
I am not asking how to deal with the f= act that the mode cannot manage different flavors using just information th= at is in the packet. I am pointing that out and you are trying to avoid to = acknowledge that the problem exists. That's your choice.=C2=A0

Regards,
Greg<= /div>

On Tue, Oct 5, 2021, 15:07 Robert Raszuk <robert@raszuk.net> wrote:
To me the e= asiest option here is to simply configure on each node selected compression= schema for the domain. Do you see anything wrong with it ?=C2=A0

=
On Wed, Oc= t 6, 2021 at 12:05 AM Greg Mirsky <gregimirsky@gmail.com> wrot= e:
Hi=C2=A0Robert,
sorry,=C2=A0 but it doesn't seem = to address my concern. My question is not about mixing compression flavors = in the same SRH (that is an interesting case of its own). I am asking how a= node that supports all the flavors defined in the draft would parse an SRv= 6 packet with compressed SIDs in the SRH. The impression I've got so fa= r, is that is not possible for a node to process a SID correctly without pr= econditions of "planning". In other words, a controller construct= s the list on the assumption that each node supports one and only one flavo= r of CSID compression. Thus, I can conclude, that the defined flavors are m= utually exclusive and thus are different data plane techniques of the SRv6 = SID compression.=C2=A0

R= egards,
Greg

On Tue, Oct 5, 2021, 14:41 Robert = Raszuk <robert@raszuk.net> wrote:
Greg,

SRH = should have an equal size SIDs. That notion applies to compress SIDs. Mixin= g multiple flavors in a single domain node to node seems of no use to me. W= ithin your domain you are subject to the domain architecture=C2=A0which is = the key factor=C2=A0what compression scheme is chosen.=C2=A0

=
Across domains (say you own N domains) the compressed SID size m= ay vary.=C2=A0

Does this answer=C2=A0your and mayb= e Ron's question ?=C2=A0

Thx,
R.


On Tue, Oct 5, 2021 at 11:36 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Robert,
as I understand it= , you believe everything that is written in the draft. I hope you can help = me find an answer to one simple question:
Can a node that support= s this draft in its entirety, i.e., supports all "flavors" define= d in the document, process received SRv6 packet with the SRH encoded accord= ing to the specification?
So far, the proponents of the d= raft referred to "planning" how flavors of SRv6 SID compressed. T= o the best of my understanding, that is is a clear demonstration of the inc= ompatibility between flavors defined in the CSID draft. Regardless of=C2=A0= what is written in it.

Regards,
Greg

On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk <robert@raszuk.= net> wrote:
Ron & SPRING WG chairs,
<= br>
Through this discussion we first have seen a debate if we nee= d one or more data planes=C2=A0to compress SIDs in SRv6. WG clearly=C2=A0st= ated we need one.=C2=A0

Following that we have obs= erved a first terminology shift to see if asking how many solutions should = be supported will work any better. To that many WG members clearly stated t= hat they support one solution.=C2=A0

Well please n= otice that the draft in question in its introduction states:=C2=A0

Abstract

=C2=A0 =C2=A0This document defines a compr= essed SRv6 Segment List Encoding in the
=C2=A0 =C2=A0Segment Routing Hea= der (SRH). =C2=A0This solution does not require any SRH
=C2=A0 = =C2=A0data plane change nor any SRv6 control plane change. =C2=A0This so= lution
=C2=A0 =C2=A0leverages the SRv6 Network Programming model.

So based on my understanding of English the enti= re draft talks about a single solution.=C2=A0

Then= suddenly a new question popped=C2=A0up: how many behaviours are acceptable= .=C2=A0

I bet number of folks including myself sai= d "one" keeping in mind previous discussions and the definition o= f "one" meaning based on the SRv6 data plane in compliance to [RF= C8402], [RFC8754] and [RFC8986].

Interestingly eno= ugh the draft in question defines not behaviours but flavors as new variant= s of the already defined behaviors in Standards Track RFCs. Namely it defin= es:=C2=A0

4.1.=C2=A0 NEXT-C-SID Flavor
4.2.=C2=A0 REPLACE-C-SID Flavor

The newly d= efined behaviour End.XPS is optional.=C2=A0

So if there is anything = to ask here is to check if WG is ok with two flavors or not. I do not recal= l that question has=C2=A0ever been asked formally during the WG adoption ca= ll.=C2=A0

With that let's note that optimal co= mpressed SID size may be different network to network. One size does not fi= t all. Draft says:=C2=A0

6.1.=C2=A0 C-SID Length

=C2=A0 =C2= =A0The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. =C2=A0= A
=C2=A0 =C2=A0C-SID length of 16-bit is recommended.

=C2= =A0 =C2=A0The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengt= hs.
=C2=A0 =C2=A0A C-SID length of 32-bit is recommended.

While I personally think 8-bit should be an option, i= f we choose a single flavor we will introduce suboptimality for no good rea= son. Hardware capable=C2=A0of supporting any flavor clearly can do LPM on l= ocator. Also hardware capable of supporting one flavor can support few othe= r flavors as this is pretty much just an offset game.=C2=A0
<= br>
Kind regards,
Robert

=


On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org> wrote:
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listi= nfo/spring
--00000000000033915405cda265e9-- From nobody Tue Oct 5 15:20:39 2021 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 8256C3A0BB6; Tue, 5 Oct 2021 15:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 qgVH2XHU-aFf; Tue, 5 Oct 2021 15:20:31 -0700 (PDT) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 EEB6F3A0BB3; Tue, 5 Oct 2021 15:20:30 -0700 (PDT) Received: by mail-ed1-x529.google.com with SMTP id g10so2360526edj.1; Tue, 05 Oct 2021 15:20:30 -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=zpN9QldaiDDbHcWhz3vYWnxExAMeQfPSf6cCHtZm1h8=; b=B8+GYXreDBBNg592kBhqT1SK/zP9C3qdPuukVjEUYcugAosAHF0cQYPbAnwOiogjQx /bMeiIx5dL7hF7lYADVMANZwx2YOgr4LQsTY6UqsNEvTsqXOfn8LlsoqyVxpvqMSChVa L4X1m4gj2PBPAxNMaK98ioAI0qAR0XBgvx+mRtQuEH3roBAU5CKzEm8TNwslASo7opTh WoXOC6Kj2fCN2HxQqPDvVmpCSZPJUj33erTM1GlSPc1fhfdt0qeeisKaRoFrTr74xown ZhQ6WVg0ObG0MSSh0vGdoUETqwtVBgBIdMfyXrU1rLeGQhUJYybW00AcZJ+gsHLjjLSJ dsDA== 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=zpN9QldaiDDbHcWhz3vYWnxExAMeQfPSf6cCHtZm1h8=; b=3E5ewBShgFvX9D4sJfrDLLgB+jjjJP4IXpf5y3wBy5DoxaqzXK2pXZvWwj0LFz9WbN 6quNJ+YkZo40Kcb8MvHvVQtRvr/pGFQ+YDe3XtPT99kMTrFaBM9QIbwWECQoiT60FGvu fV0qX6WFxVZ5HDc9Q6VwzYQFOKQVaO+Wa7u2wFyTmWDAqydjVlQCYv510LWFQOVucuTx SesDLFp9jaimDwGy2OwHg+HEQA+hA2WozMnHZGaagzZJ4LNXKx0qmulFrBacUCBFlpQV knx4LnD1+++xF9e6Sk+pSvJHTsg5KjyvoTHgZEwX7cLePYwV8DQL1CYN5OT1B2BOXfP9 +3eQ== X-Gm-Message-State: AOAM530X4wGDZAR9LhQ/KfuNwBuQ2LmdBU6HZaCBwIUM2ZnU5MNB5XfU pQqd5mQKqyGpgs0N5vh4EXxmIhoHeXW5koS1VskyRzS/ X-Google-Smtp-Source: ABdhPJzedxF/6d56TYx3eBYM8HmZyXiXIfxaWwBmv6gYZtXmx15pyp7O0TkjRREngsPpR8ivIaFZgROnE4PCw29ZsXM= X-Received: by 2002:a17:906:60c3:: with SMTP id f3mr27232293ejk.561.1633472427410; Tue, 05 Oct 2021 15:20:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Tue, 5 Oct 2021 15:20:15 -0700 Message-ID: To: Robert Raszuk Cc: Ron Bonica , James Guichard , SPRING WG , spring-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000c9491205cda26f04" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 05 Oct 2021 22:20:37 -0000 --000000000000c9491205cda26f04 Content-Type: text/plain; charset="UTF-8" "Secret sauce" is another way to say not-interoperable. And that is exactly the point I am making. Regards, Greg On Tue, Oct 5, 2021, 15:17 Robert Raszuk wrote: > That's not the case. You can map locator prefix to specific compression > schema used as an example ... This is pure implementation choice - I would > say vendor's secret sauce. > > On Wed, Oct 6, 2021 at 12:11 AM Greg Mirsky wrote: > >> I am not asking how to deal with the fact that the mode cannot manage >> different flavors using just information that is in the packet. I am >> pointing that out and you are trying to avoid to acknowledge that the >> problem exists. That's your choice. >> >> Regards, >> Greg >> >> On Tue, Oct 5, 2021, 15:07 Robert Raszuk wrote: >> >>> To me the easiest option here is to simply configure on each node >>> selected compression schema for the domain. Do you see anything wrong with >>> it ? >>> >>> On Wed, Oct 6, 2021 at 12:05 AM Greg Mirsky >>> wrote: >>> >>>> Hi Robert, >>>> sorry, but it doesn't seem to address my concern. My question is not >>>> about mixing compression flavors in the same SRH (that is an interesting >>>> case of its own). I am asking how a node that supports all the flavors >>>> defined in the draft would parse an SRv6 packet with compressed SIDs in the >>>> SRH. The impression I've got so far, is that is not possible for a node to >>>> process a SID correctly without preconditions of "planning". In other >>>> words, a controller constructs the list on the assumption that each node >>>> supports one and only one flavor of CSID compression. Thus, I can conclude, >>>> that the defined flavors are mutually exclusive and thus are different data >>>> plane techniques of the SRv6 SID compression. >>>> >>>> Regards, >>>> Greg >>>> >>>> On Tue, Oct 5, 2021, 14:41 Robert Raszuk wrote: >>>> >>>>> Greg, >>>>> >>>>> SRH should have an equal size SIDs. That notion applies to compress >>>>> SIDs. Mixing multiple flavors in a single domain node to node seems of no >>>>> use to me. Within your domain you are subject to the domain >>>>> architecture which is the key factor what compression scheme is chosen. >>>>> >>>>> Across domains (say you own N domains) the compressed SID size may >>>>> vary. >>>>> >>>>> Does this answer your and maybe Ron's question ? >>>>> >>>>> Thx, >>>>> R. >>>>> >>>>> >>>>> On Tue, Oct 5, 2021 at 11:36 PM Greg Mirsky >>>>> wrote: >>>>> >>>>>> Hi Robert, >>>>>> as I understand it, you believe everything that is written in the >>>>>> draft. I hope you can help me find an answer to one simple question: >>>>>> >>>>>> Can a node that supports this draft in its entirety, i.e., supports >>>>>> all "flavors" defined in the document, process received SRv6 packet with >>>>>> the SRH encoded according to the specification? >>>>>> >>>>>> So far, the proponents of the draft referred to "planning" how >>>>>> flavors of SRv6 SID compressed. To the best of my understanding, that is is >>>>>> a clear demonstration of the incompatibility between flavors defined in the >>>>>> CSID draft. Regardless of what is written in it. >>>>>> >>>>>> Regards, >>>>>> Greg >>>>>> >>>>>> On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk >>>>>> wrote: >>>>>> >>>>>>> Ron & SPRING WG chairs, >>>>>>> >>>>>>> Through this discussion we first have seen a debate if we need one >>>>>>> or more data planes to compress SIDs in SRv6. WG clearly stated we need >>>>>>> one. >>>>>>> >>>>>>> Following that we have observed a first terminology shift to see if >>>>>>> asking how many solutions should be supported will work any better. To that >>>>>>> many WG members clearly stated that they support one solution. >>>>>>> >>>>>>> Well please notice that the draft in question in its introduction >>>>>>> states: >>>>>>> >>>>>>> Abstract >>>>>>> >>>>>>> This document defines a compressed SRv6 Segment List Encoding in >>>>>>> the >>>>>>> Segment Routing Header (SRH). *This solution* does not require >>>>>>> any SRH >>>>>>> data plane change nor any SRv6 control plane change. *This >>>>>>> solution* >>>>>>> leverages the SRv6 Network Programming model. >>>>>>> >>>>>>> So based on my understanding of English the entire draft talks about >>>>>>> a single solution. >>>>>>> >>>>>>> Then suddenly a new question popped up: how many behaviours are >>>>>>> acceptable. >>>>>>> >>>>>>> I bet number of folks including myself said "one" keeping in mind >>>>>>> previous discussions and the definition of "one" meaning based on the SRv6 >>>>>>> data plane in compliance to [RFC8402], [RFC8754] and [RFC8986]. >>>>>>> >>>>>>> Interestingly enough the draft in question defines not behaviours >>>>>>> but flavors as new variants of the already defined behaviors in Standards >>>>>>> Track RFCs. Namely it defines: >>>>>>> >>>>>>> 4.1. NEXT-C-SID Flavor >>>>>>> 4.2. REPLACE-C-SID Flavor >>>>>>> >>>>>>> The newly defined behaviour End.XPS is optional. >>>>>>> >>>>>>> So if there is anything to ask here is to check if WG is ok with two >>>>>>> flavors or not. I do not recall that question has ever been asked formally >>>>>>> during the WG adoption call. >>>>>>> >>>>>>> With that let's note that optimal compressed SID size may be >>>>>>> different network to network. One size does not fit all. Draft says: >>>>>>> >>>>>>> 6.1. C-SID Length >>>>>>> >>>>>>> The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. >>>>>>> A >>>>>>> * C-SID length of 16-bit is recommended.* >>>>>>> >>>>>>> The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID >>>>>>> lengths. >>>>>>> * A C-SID length of 32-bit is recommended.* >>>>>>> >>>>>>> While I personally think 8-bit should be an option, if we choose a >>>>>>> single flavor we will introduce suboptimality for no good reason. Hardware >>>>>>> capable of supporting any flavor clearly can do LPM on locator. Also >>>>>>> hardware capable of supporting one flavor can support few other flavors as >>>>>>> this is pretty much just an offset game. >>>>>>> >>>>>>> Kind regards, >>>>>>> Robert >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica >>>>>> 40juniper.net@dmarc.ietf.org> wrote: >>>>>>> >>>>>>>> Pablo, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Ae you sure? Please look at the question as Joel asked it ( >>>>>>>> https://mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ >>>>>>>> ). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Ron >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> spring mailing list >>>>>>> spring@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/spring >>>>>>> >>>>>> --000000000000c9491205cda26f04 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"Secret sauce" is another way to say not-intero= perable. And that is exactly the point I am making.

Regards,
Greg

<= div class=3D"gmail_quote">
On Tue, Oct= 5, 2021, 15:17 Robert Raszuk <robe= rt@raszuk.net> wrote:
That's not the case. You can map locator=C2=A0prefix to spec= ific compression schema used as an example ... This is pure implementation = choice - I would say vendor's secret sauce.=C2=A0

On Wed, Oct 6, 2021 = at 12:11 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
I am = not asking how to deal with the fact that the mode cannot manage different = flavors using just information that is in the packet. I am pointing that ou= t and you are trying to avoid to acknowledge that the problem exists. That&= #39;s your choice.=C2=A0

Regar= ds,
Greg

<= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Oct 5, 2021, 15:07 Robert Rasz= uk <robert@raszuk.net> wrote:
To me the easiest option here is to= simply configure on each node selected compression schema for the domain. = Do you see anything wrong with it ?=C2=A0

On Wed, Oct 6, 2021 at 12:05 AM Gr= eg Mirsky <gregimirsky@gmail.com> wrote:
<= 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">
Hi=C2=A0= Robert,
sorry,=C2=A0 but it doesn't seem to address my= concern. My question is not about mixing compression flavors in the same S= RH (that is an interesting case of its own). I am asking how a node that su= pports all the flavors defined in the draft would parse an SRv6 packet with= compressed SIDs in the SRH. The impression I've got so far, is that is= not possible for a node to process a SID correctly without preconditions o= f "planning". In other words, a controller constructs the list on= the assumption that each node supports one and only one flavor of CSID com= pression. Thus, I can conclude, that the defined flavors are mutually exclu= sive and thus are different data plane techniques of the SRv6 SID compressi= on.=C2=A0

Regards,
=
Greg

On Tue, Oct 5, 2021, 14:41 Robert Raszuk <= robert@raszuk.net> wrote:
Greg,

SRH = should have an equal size SIDs. That notion applies to compress SIDs. Mixin= g multiple flavors in a single domain node to node seems of no use to me. W= ithin your domain you are subject to the domain architecture=C2=A0which is = the key factor=C2=A0what compression scheme is chosen.=C2=A0

=
Across domains (say you own N domains) the compressed SID size m= ay vary.=C2=A0

Does this answer=C2=A0your and mayb= e Ron's question ?=C2=A0

Thx,
R.


On Tue, Oct 5, 2021 at 11:36 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Robert,
as I un= derstand it, you believe everything that is written in the draft. I hope yo= u can help me find an answer to one simple question:
Can a node t= hat supports this draft in its entirety, i.e., supports all "flavors&q= uot; defined in the document, process received SRv6 packet with the SRH enc= oded according to the specification?
So far, the proponen= ts of the draft referred to "planning" how flavors of SRv6 SID co= mpressed. To the best of my understanding, that is is a clear demonstration= of the incompatibility between flavors defined in the CSID draft. Regardle= ss of=C2=A0what is written in it.

Regards,
Greg

On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk <robert@raszuk.net> wrote:
Ron & SPRING= WG chairs,

Through this discussion we first have s= een a debate if we need one or more data planes=C2=A0to compress SIDs in SR= v6. WG clearly=C2=A0stated we need one.=C2=A0

Foll= owing that we have observed a first terminology shift to see if asking how = many solutions should be supported will work any better. To that many WG me= mbers clearly stated that they support one solution.=C2=A0

Well please notice that the draft in question in its introduction = states:=C2=A0

Abstract

=C2=A0 =C2=A0This do= cument defines a compressed SRv6 Segment List Encoding in the
=C2=A0 =C2= =A0Segment Routing Header (SRH). =C2=A0This solution does not requir= e any SRH
=C2=A0 =C2=A0data plane change nor any SRv6 control plane chan= ge. =C2=A0This solution
=C2=A0 =C2=A0leverages the SRv6 Network P= rogramming model.

So based on my understanding= of English the entire draft talks about a single solution.=C2=A0

Then suddenly a new question popped=C2=A0up: how many behav= iours are acceptable.=C2=A0

I bet number of folks = including myself said "one" keeping in mind previous discussions = and the definition of "one" meaning based on the SRv6 data plane = in compliance to [RFC8402], [RFC8754] and [RFC8986].

Interestingly enough the draft in question defines not behaviours but fl= avors as new variants of the already defined behaviors in Standards Track R= FCs. Namely it defines:=C2=A0

4.1.=C2=A0 NEXT-C-SI= D Flavor
4.2.=C2=A0 REPLACE-C-SID Flavor

The newly defined behaviour End.XPS is optional.=C2=A0

So i= f there is anything to ask here is to check if WG is ok with two flavors or= not. I do not recall that question has=C2=A0ever been asked formally durin= g the WG adoption call.=C2=A0

With that let's = note that optimal compressed SID size may be different network to network. = One size does not fit all. Draft says:=C2=A0

6.1.=C2=A0 C-SID Length=

=C2=A0 =C2=A0The NEXT-C-SID flavor supports both 16- and 32-bit C-S= ID lengths. =C2=A0A
=C2=A0 =C2=A0C-SID length of 16-bit is recommende= d.

=C2=A0 =C2=A0The REPLACE-C-SID flavor supports both 16- and 3= 2-bit C-SID lengths.
=C2=A0 =C2=A0A C-SID length of 32-bit is recomme= nded.

While I personally think 8-bit shoul= d be an option, if we choose a single flavor we will introduce suboptimalit= y for no good reason. Hardware capable=C2=A0of supporting any flavor clearl= y can do LPM on locator. Also hardware capable of supporting one flavor can= support few other flavors as this is pretty much just an offset game.=C2= =A0

Kind regards,
Robert



On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica= <rbonica=3D40juniper.net@dmarc.ietf.org= > wrote:
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/ma= ilman/listinfo/spring
--000000000000c9491205cda26f04-- From nobody Tue Oct 5 15:40:05 2021 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 E793C3A0C61 for ; Tue, 5 Oct 2021 15:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 MDaXoT3Dwn2h for ; Tue, 5 Oct 2021 15:39:57 -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 EE0523A0C78 for ; Tue, 5 Oct 2021 15:39:56 -0700 (PDT) Received: by mail-vs1-xe2a.google.com with SMTP id o124so905302vsc.6 for ; Tue, 05 Oct 2021 15:39:56 -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=5TokdLHemZv3fn2GbpjzewiqtDNYiGjPtSZZ/KvJiOM=; b=Erc4jJ99WdByZeYadmi5/JMVnQ5LwWMdlmvcndTniC185FhAikAQcTYmli6mMvexJz KSY7UKTn2xI3K+KXHBx64bAVU2e5VXjSWQcIstcdHd/mVTgUddJ4W+PFQD7D0+7hhxsl QXkJ/FuG4Snl32ly6taYGCv/q/KgCRWpOt4ZfYcs+otIkoHMnXL7vHCStUC97HymBnp5 jcs+fYuRX5vYOZXER2GpAw7uBlF2vXVAtRQq7ZfVhnaWTsR7wgSMxcGo6Aeexnumv/t/ 4M0M3xepv1O9NDI0BhK01jb11X+Gd/15+Adnf2yfNAKEMOEV4BOndF0e9a0NJbTBJyIX Y0nA== 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=5TokdLHemZv3fn2GbpjzewiqtDNYiGjPtSZZ/KvJiOM=; b=NJUI5E80l+ylgcBgYKzO4UaXNY9ujALfLxk4/3bTb28N5xaXOjMY9RR6G3oI+C0A3L 6pMjR/vcmWjKgMgu6ymrySBXQe6APLFSiaZIN3V1CWujL2bf0N+qTMmgO0oaaIYfNQV0 p3vPep/h1hXn4dnbuxnFh1N51g7kq46O72OKl6mkzQAXipqvx0Pf3e3zI3Cp5HoS3svW wiSRiuSbwgC2pqWkoigIzi+buTYmBWWYq7OrU7NRRIDaye8mepSXXHHRMdKpdCor0Huf lev3iBWpJQc/SeUnDdmfYbNFwmi6MyjiEPFaiXrICta8NrLT1ckJi8dShXtu0cjslaXP me7g== X-Gm-Message-State: AOAM532TF1H1JzOu7ToKeg2xapXm6qbOWDSQ8xlmBalBE7qqaVEhwrEf LdK/3Jkd83VHoAInW2RdVW3/7Yw3luonQrtP8NMyqA== X-Google-Smtp-Source: ABdhPJzc4dMHb+4WX7LkjM1DnnXkbPoxF3c45dGhunx+HfmY4Wfcd+p90gWCl8NASNDC1tLMeUndk8XnqT25CfBqqZg= X-Received: by 2002:a05:6102:2333:: with SMTP id b19mr4854274vsa.0.1633473595531; Tue, 05 Oct 2021 15:39:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Wed, 6 Oct 2021 00:39:47 +0200 Message-ID: To: Greg Mirsky Cc: Ron Bonica , James Guichard , SPRING WG , spring-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000069734d05cda2b508" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 05 Oct 2021 22:40:02 -0000 --00000000000069734d05cda2b508 Content-Type: text/plain; charset="UTF-8" Greg, When you receive any packet you do a LPM on the dst address. The result of that lookup reveals the secret on how to handle the packet further. What is non-interoperable here ? I see You would love to have a few bits next to the locator prefix to specify verbatim what to do with the packet ? What for ? To run out of those bits in no time and make a mess ? On Wed, Oct 6, 2021 at 12:20 AM Greg Mirsky wrote: > "Secret sauce" is another way to say not-interoperable. And that is > exactly the point I am making. > > Regards, > Greg > > On Tue, Oct 5, 2021, 15:17 Robert Raszuk wrote: > >> That's not the case. You can map locator prefix to specific compression >> schema used as an example ... This is pure implementation choice - I would >> say vendor's secret sauce. >> >> On Wed, Oct 6, 2021 at 12:11 AM Greg Mirsky >> wrote: >> >>> I am not asking how to deal with the fact that the mode cannot manage >>> different flavors using just information that is in the packet. I am >>> pointing that out and you are trying to avoid to acknowledge that the >>> problem exists. That's your choice. >>> >>> Regards, >>> Greg >>> >>> On Tue, Oct 5, 2021, 15:07 Robert Raszuk wrote: >>> >>>> To me the easiest option here is to simply configure on each node >>>> selected compression schema for the domain. Do you see anything wrong with >>>> it ? >>>> >>>> On Wed, Oct 6, 2021 at 12:05 AM Greg Mirsky >>>> wrote: >>>> >>>>> Hi Robert, >>>>> sorry, but it doesn't seem to address my concern. My question is not >>>>> about mixing compression flavors in the same SRH (that is an interesting >>>>> case of its own). I am asking how a node that supports all the flavors >>>>> defined in the draft would parse an SRv6 packet with compressed SIDs in the >>>>> SRH. The impression I've got so far, is that is not possible for a node to >>>>> process a SID correctly without preconditions of "planning". In other >>>>> words, a controller constructs the list on the assumption that each node >>>>> supports one and only one flavor of CSID compression. Thus, I can conclude, >>>>> that the defined flavors are mutually exclusive and thus are different data >>>>> plane techniques of the SRv6 SID compression. >>>>> >>>>> Regards, >>>>> Greg >>>>> >>>>> On Tue, Oct 5, 2021, 14:41 Robert Raszuk wrote: >>>>> >>>>>> Greg, >>>>>> >>>>>> SRH should have an equal size SIDs. That notion applies to compress >>>>>> SIDs. Mixing multiple flavors in a single domain node to node seems of no >>>>>> use to me. Within your domain you are subject to the domain >>>>>> architecture which is the key factor what compression scheme is chosen. >>>>>> >>>>>> Across domains (say you own N domains) the compressed SID size may >>>>>> vary. >>>>>> >>>>>> Does this answer your and maybe Ron's question ? >>>>>> >>>>>> Thx, >>>>>> R. >>>>>> >>>>>> >>>>>> On Tue, Oct 5, 2021 at 11:36 PM Greg Mirsky >>>>>> wrote: >>>>>> >>>>>>> Hi Robert, >>>>>>> as I understand it, you believe everything that is written in the >>>>>>> draft. I hope you can help me find an answer to one simple question: >>>>>>> >>>>>>> Can a node that supports this draft in its entirety, i.e., supports >>>>>>> all "flavors" defined in the document, process received SRv6 packet with >>>>>>> the SRH encoded according to the specification? >>>>>>> >>>>>>> So far, the proponents of the draft referred to "planning" how >>>>>>> flavors of SRv6 SID compressed. To the best of my understanding, that is is >>>>>>> a clear demonstration of the incompatibility between flavors defined in the >>>>>>> CSID draft. Regardless of what is written in it. >>>>>>> >>>>>>> Regards, >>>>>>> Greg >>>>>>> >>>>>>> On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk >>>>>>> wrote: >>>>>>> >>>>>>>> Ron & SPRING WG chairs, >>>>>>>> >>>>>>>> Through this discussion we first have seen a debate if we need one >>>>>>>> or more data planes to compress SIDs in SRv6. WG clearly stated we need >>>>>>>> one. >>>>>>>> >>>>>>>> Following that we have observed a first terminology shift to see if >>>>>>>> asking how many solutions should be supported will work any better. To that >>>>>>>> many WG members clearly stated that they support one solution. >>>>>>>> >>>>>>>> Well please notice that the draft in question in its introduction >>>>>>>> states: >>>>>>>> >>>>>>>> Abstract >>>>>>>> >>>>>>>> This document defines a compressed SRv6 Segment List Encoding in >>>>>>>> the >>>>>>>> Segment Routing Header (SRH). *This solution* does not require >>>>>>>> any SRH >>>>>>>> data plane change nor any SRv6 control plane change. *This >>>>>>>> solution* >>>>>>>> leverages the SRv6 Network Programming model. >>>>>>>> >>>>>>>> So based on my understanding of English the entire draft talks >>>>>>>> about a single solution. >>>>>>>> >>>>>>>> Then suddenly a new question popped up: how many behaviours are >>>>>>>> acceptable. >>>>>>>> >>>>>>>> I bet number of folks including myself said "one" keeping in mind >>>>>>>> previous discussions and the definition of "one" meaning based on the SRv6 >>>>>>>> data plane in compliance to [RFC8402], [RFC8754] and [RFC8986]. >>>>>>>> >>>>>>>> Interestingly enough the draft in question defines not behaviours >>>>>>>> but flavors as new variants of the already defined behaviors in Standards >>>>>>>> Track RFCs. Namely it defines: >>>>>>>> >>>>>>>> 4.1. NEXT-C-SID Flavor >>>>>>>> 4.2. REPLACE-C-SID Flavor >>>>>>>> >>>>>>>> The newly defined behaviour End.XPS is optional. >>>>>>>> >>>>>>>> So if there is anything to ask here is to check if WG is ok with >>>>>>>> two flavors or not. I do not recall that question has ever been asked >>>>>>>> formally during the WG adoption call. >>>>>>>> >>>>>>>> With that let's note that optimal compressed SID size may be >>>>>>>> different network to network. One size does not fit all. Draft says: >>>>>>>> >>>>>>>> 6.1. C-SID Length >>>>>>>> >>>>>>>> The NEXT-C-SID flavor supports both 16- and 32-bit C-SID >>>>>>>> lengths. A >>>>>>>> * C-SID length of 16-bit is recommended.* >>>>>>>> >>>>>>>> The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID >>>>>>>> lengths. >>>>>>>> * A C-SID length of 32-bit is recommended.* >>>>>>>> >>>>>>>> While I personally think 8-bit should be an option, if we choose a >>>>>>>> single flavor we will introduce suboptimality for no good reason. Hardware >>>>>>>> capable of supporting any flavor clearly can do LPM on locator. Also >>>>>>>> hardware capable of supporting one flavor can support few other flavors as >>>>>>>> this is pretty much just an offset game. >>>>>>>> >>>>>>>> Kind regards, >>>>>>>> Robert >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica >>>>>>> 40juniper.net@dmarc.ietf.org> wrote: >>>>>>>> >>>>>>>>> Pablo, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Ae you sure? Please look at the question as Joel asked it ( >>>>>>>>> https://mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ >>>>>>>>> ). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Ron >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> spring mailing list >>>>>>>> spring@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/spring >>>>>>>> >>>>>>> --00000000000069734d05cda2b508 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Greg,

When you receive any packet you d= o a LPM on the dst address. The result of that lookup reveals the secret on= how to handle the packet further.=C2=A0

What is n= on-interoperable here ? I see You would love to have a few bits next to the= locator=C2=A0prefix to specify=C2=A0verbatim what to do with the packet ? = What for ? To run out of those bits in no time and make a mess ?=C2=A0

On Wed, Oct 6, 2021 at 12:20 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
"Secret sauce&qu= ot; is another way to say not-interoperable. And that is exactly the point = I am making.

Regards,
Greg

On Tue, Oct 5, 2021, 15:17 Robert Raszuk <robert@raszuk.net>= wrote:
That's not the case. You can map locator=C2=A0prefix to specif= ic compression schema used as an example ... This is pure implementation ch= oice - I would say vendor's secret sauce.=C2=A0

On Wed, Oct 6, 2021 at 1= 2:11 AM Greg Mirsky <gregimirsky@gmail.com> wrote:
I am not = asking how to deal with the fact that the mode cannot manage different flav= ors using just information that is in the packet. I am pointing that out an= d you are trying to avoid to acknowledge that the problem exists. That'= s your choice.=C2=A0

Regards,<= /div>
Greg

On Tue, Oct 5, 2021, 15:07 Robert Raszuk &= lt;robert@raszuk.net> wrote:
To me the easiest option here is to sim= ply configure on each node selected compression schema for the domain. Do y= ou see anything wrong with it ?=C2=A0

<= div dir=3D"ltr" class=3D"gmail_attr">On Wed, Oct 6, 2021 at 12:05 AM Greg M= irsky <gregimirsky@gmail.com> wrote:
Hi=C2=A0Robe= rt,
sorry,=C2=A0 but it doesn't seem to address my con= cern. My question is not about mixing compression flavors in the same SRH (= that is an interesting case of its own). I am asking how a node that suppor= ts all the flavors defined in the draft would parse an SRv6 packet with com= pressed SIDs in the SRH. The impression I've got so far, is that is not= possible for a node to process a SID correctly without preconditions of &q= uot;planning". In other words, a controller constructs the list on the= assumption that each node supports one and only one flavor of CSID compres= sion. Thus, I can conclude, that the defined flavors are mutually exclusive= and thus are different data plane techniques of the SRv6 SID compression.= =C2=A0

Regards,
Greg

On Tue, Oct 5, 2021, 14:41 Robert Raszuk <robert@raszuk.net> wrote:
Greg,

SRH should = have an equal size SIDs. That notion applies to compress SIDs. Mixing multi= ple flavors in a single domain node to node seems of no use to me. Within y= our domain you are subject to the domain architecture=C2=A0which is the key= factor=C2=A0what compression scheme is chosen.=C2=A0

<= div>Across domains (say you own N domains) the compressed SID size may vary= .=C2=A0

Does this answer=C2=A0your and maybe Ron&#= 39;s question ?=C2=A0

Thx,
R.
=

On Tue, Oct 5, 2021 at 11:36 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Robert,
as I understan= d it, you believe everything that is written in the draft. I hope you can h= elp me find an answer to one simple question:
Can a node that s= upports this draft in its entirety, i.e., supports all "flavors" = defined in the document, process received SRv6 packet with the SRH encoded = according to the specification?
So far, the proponents of= the draft referred to "planning" how flavors of SRv6 SID compres= sed. To the best of my understanding, that is is a clear demonstration of t= he incompatibility between flavors defined in the CSID draft. Regardless of= =C2=A0what is written in it.

Regards,
Gr= eg

On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk <robert@raszuk.net> wrote:
Ron & SPRING WG c= hairs,

Through this discussion we first have seen a= debate if we need one or more data planes=C2=A0to compress SIDs in SRv6. W= G clearly=C2=A0stated we need one.=C2=A0

Following= that we have observed a first terminology shift to see if asking how many = solutions should be supported will work any better. To that many WG members= clearly stated that they support one solution.=C2=A0

<= div>Well please notice that the draft in question in its introduction state= s:=C2=A0

Abstract

=C2=A0 =C2=A0This documen= t defines a compressed SRv6 Segment List Encoding in the
=C2=A0 =C2=A0Se= gment Routing Header (SRH). =C2=A0This solution does not require any= SRH
=C2=A0 =C2=A0data plane change nor any SRv6 control plane change. = =C2=A0This solution
=C2=A0 =C2=A0leverages the SRv6 Network Progr= amming model.

So based on my understanding of = English the entire draft talks about a single solution.=C2=A0
Then suddenly a new question popped=C2=A0up: how many behaviour= s are acceptable.=C2=A0

I bet number of folks incl= uding myself said "one" keeping in mind previous discussions and = the definition of "one" meaning based on the SRv6 data plane in c= ompliance to [RFC8402], [RFC8754] and [RFC8986].

I= nterestingly enough the draft in question defines not behaviours but flavor= s as new variants of the already defined behaviors in Standards Track RFCs.= Namely it defines:=C2=A0

4.1.=C2=A0 NEXT-C-SID Fl= avor
4.2.=C2=A0 REPLACE-C-SID Flavor

=
The newly defined behaviour End.XPS is optional.=C2=A0

So if th= ere is anything to ask here is to check if WG is ok with two flavors or not= . I do not recall that question has=C2=A0ever been asked formally during th= e WG adoption call.=C2=A0

With that let's note= that optimal compressed SID size may be different network to network. One = size does not fit all. Draft says:=C2=A0

6.1.=C2=A0 C-SID Length
=
=C2=A0 =C2=A0The NEXT-C-SID flavor supports both 16- and 32-bit C-SID l= engths. =C2=A0A
=C2=A0 =C2=A0C-SID length of 16-bit is recommended.

=C2=A0 =C2=A0The REPLACE-C-SID flavor supports both 16- and 32-bi= t C-SID lengths.
=C2=A0 =C2=A0A C-SID length of 32-bit is recommended= .

While I personally think 8-bit should be= an option, if we choose a single flavor we will introduce suboptimality fo= r no good reason. Hardware capable=C2=A0of supporting any flavor clearly ca= n do LPM on locator. Also hardware capable of supporting one flavor can sup= port few other flavors as this is pretty much just an offset game.=C2=A0

Kind regards,
Robert



On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica <= ;rbonica=3D40juniper.net@dmarc.ietf.org= > wrote:
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/ma= ilman/listinfo/spring
--00000000000069734d05cda2b508-- From nobody Tue Oct 5 16:23:58 2021 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 DB0CC3A0CB7; Tue, 5 Oct 2021 16:23:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 AhH-sCUQt8Yc; Tue, 5 Oct 2021 16:23:49 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 301B23A0CB5; Tue, 5 Oct 2021 16:23:49 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id l7so2769021edq.3; Tue, 05 Oct 2021 16:23:49 -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=Ve3gF1+c+6VleaLZz/ZUs2xuJfkEvjcvhq9AasRVVi8=; b=RzR9jkKFCDETx1tzFCVZuFN0gyJ1ZdP9QXGc4WgGZW6l2gXGppNKSIw9duDtAV014o oqJliZShwjkT0vUyVcL4Si03TIazrIGnPCMbdjgm5my1WlkEvw9rgp0VabNKb9nUNCBx ZAD6A6FuiYJQJj2BMtr2a25ZdSYOpTYNPiMfCz5vu1OQz+uN0S5VMOesWWk1sLM1Abcb G+fiNvOyKIWoKlZ9WgC6fM3+E9ZJKzQu91vPf14Yy+S95HdrI3dVwHGc9xDpxRL1VGCV NHCumfTcwSVg9nQvT7f9QUR5FETsymAqJgVtk932hhTk8kIVt9lwAAzafMUKKNFQY1NE mgFA== 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=Ve3gF1+c+6VleaLZz/ZUs2xuJfkEvjcvhq9AasRVVi8=; b=WZXqRx0G14i9wm3fZKcTojUA5ypHrGA1URcloiqsYq5pup0IwzFX3yGhQMUkT871s2 RM6Ip25vLZY7Wt8KPPxLcGIVll+Fr1L4Id3hPfiw2H4ky/n4mHbgClF7Yl7BScTd/CtX bD/wc3Khb4R4M+gUxYL5qgUSD0DYchMe8gfqVQ37UBZT0QZoq9zWSocIwJ1D7MwzIT5G NiJ9pEC2OEM59z4eGlZst4fW9WkG3+3rOelv2+V01bk5X1rpniKcwqSLj10iOyQEStvg 5KEJNkR455Ultq+ib7gH3pUsK6dljH06MK4nTU6lvfLNghxKs1FDdYwo/+WuzBSU/xak XgeQ== X-Gm-Message-State: AOAM531Ax5Wv/JoRP5iR6OEbpfNVa+L/jpepzu2JVQxBxfmoBs94B3zl eLaQxIFfn6C5h4j9B72Jjk/7DRAHyjZ8dD6+Gm0= X-Google-Smtp-Source: ABdhPJwdu5HnTmVSkBNn8v34nE+XwQGFzsugziSWLOgl4xTtUBV1oj7JCp1n77H4bkK7eu6GG4+/VcvT+liiszWQG44= X-Received: by 2002:a05:6402:2790:: with SMTP id b16mr29298296ede.3.1633476226342; Tue, 05 Oct 2021 16:23:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Tue, 5 Oct 2021 16:23:34 -0700 Message-ID: To: Robert Raszuk Cc: Ron Bonica , James Guichard , SPRING WG , spring-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000003862a705cda35292" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 05 Oct 2021 23:23:54 -0000 --0000000000003862a705cda35292 Content-Type: text/plain; charset="UTF-8" Hi Robert, that is a more elegant way to mitigate the problem. But the fact that you need to use the control or management plane to disseminate the mapping between the particular flavor and corresponding prefix still tells me that in the data plane these flavors are distinct and incompatible entities, i.e., different data plane solutions to the SRv6 SID compression. Regards, Greg On Tue, Oct 5, 2021 at 3:39 PM Robert Raszuk wrote: > Greg, > > When you receive any packet you do a LPM on the dst address. The result of > that lookup reveals the secret on how to handle the packet further. > > What is non-interoperable here ? I see You would love to have a few bits > next to the locator prefix to specify verbatim what to do with the packet ? > What for ? To run out of those bits in no time and make a mess ? > > On Wed, Oct 6, 2021 at 12:20 AM Greg Mirsky wrote: > >> "Secret sauce" is another way to say not-interoperable. And that is >> exactly the point I am making. >> >> Regards, >> Greg >> >> On Tue, Oct 5, 2021, 15:17 Robert Raszuk wrote: >> >>> That's not the case. You can map locator prefix to specific compression >>> schema used as an example ... This is pure implementation choice - I would >>> say vendor's secret sauce. >>> >>> On Wed, Oct 6, 2021 at 12:11 AM Greg Mirsky >>> wrote: >>> >>>> I am not asking how to deal with the fact that the mode cannot manage >>>> different flavors using just information that is in the packet. I am >>>> pointing that out and you are trying to avoid to acknowledge that the >>>> problem exists. That's your choice. >>>> >>>> Regards, >>>> Greg >>>> >>>> On Tue, Oct 5, 2021, 15:07 Robert Raszuk wrote: >>>> >>>>> To me the easiest option here is to simply configure on each node >>>>> selected compression schema for the domain. Do you see anything wrong with >>>>> it ? >>>>> >>>>> On Wed, Oct 6, 2021 at 12:05 AM Greg Mirsky >>>>> wrote: >>>>> >>>>>> Hi Robert, >>>>>> sorry, but it doesn't seem to address my concern. My question is not >>>>>> about mixing compression flavors in the same SRH (that is an interesting >>>>>> case of its own). I am asking how a node that supports all the flavors >>>>>> defined in the draft would parse an SRv6 packet with compressed SIDs in the >>>>>> SRH. The impression I've got so far, is that is not possible for a node to >>>>>> process a SID correctly without preconditions of "planning". In other >>>>>> words, a controller constructs the list on the assumption that each node >>>>>> supports one and only one flavor of CSID compression. Thus, I can conclude, >>>>>> that the defined flavors are mutually exclusive and thus are different data >>>>>> plane techniques of the SRv6 SID compression. >>>>>> >>>>>> Regards, >>>>>> Greg >>>>>> >>>>>> On Tue, Oct 5, 2021, 14:41 Robert Raszuk wrote: >>>>>> >>>>>>> Greg, >>>>>>> >>>>>>> SRH should have an equal size SIDs. That notion applies to compress >>>>>>> SIDs. Mixing multiple flavors in a single domain node to node seems of no >>>>>>> use to me. Within your domain you are subject to the domain >>>>>>> architecture which is the key factor what compression scheme is chosen. >>>>>>> >>>>>>> Across domains (say you own N domains) the compressed SID size may >>>>>>> vary. >>>>>>> >>>>>>> Does this answer your and maybe Ron's question ? >>>>>>> >>>>>>> Thx, >>>>>>> R. >>>>>>> >>>>>>> >>>>>>> On Tue, Oct 5, 2021 at 11:36 PM Greg Mirsky >>>>>>> wrote: >>>>>>> >>>>>>>> Hi Robert, >>>>>>>> as I understand it, you believe everything that is written in the >>>>>>>> draft. I hope you can help me find an answer to one simple question: >>>>>>>> >>>>>>>> Can a node that supports this draft in its entirety, i.e., supports >>>>>>>> all "flavors" defined in the document, process received SRv6 packet with >>>>>>>> the SRH encoded according to the specification? >>>>>>>> >>>>>>>> So far, the proponents of the draft referred to "planning" how >>>>>>>> flavors of SRv6 SID compressed. To the best of my understanding, that is is >>>>>>>> a clear demonstration of the incompatibility between flavors defined in the >>>>>>>> CSID draft. Regardless of what is written in it. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Greg >>>>>>>> >>>>>>>> On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Ron & SPRING WG chairs, >>>>>>>>> >>>>>>>>> Through this discussion we first have seen a debate if we need one >>>>>>>>> or more data planes to compress SIDs in SRv6. WG clearly stated we need >>>>>>>>> one. >>>>>>>>> >>>>>>>>> Following that we have observed a first terminology shift to see >>>>>>>>> if asking how many solutions should be supported will work any better. To >>>>>>>>> that many WG members clearly stated that they support one solution. >>>>>>>>> >>>>>>>>> Well please notice that the draft in question in its introduction >>>>>>>>> states: >>>>>>>>> >>>>>>>>> Abstract >>>>>>>>> >>>>>>>>> This document defines a compressed SRv6 Segment List Encoding >>>>>>>>> in the >>>>>>>>> Segment Routing Header (SRH). *This solution* does not >>>>>>>>> require any SRH >>>>>>>>> data plane change nor any SRv6 control plane change. *This >>>>>>>>> solution* >>>>>>>>> leverages the SRv6 Network Programming model. >>>>>>>>> >>>>>>>>> So based on my understanding of English the entire draft talks >>>>>>>>> about a single solution. >>>>>>>>> >>>>>>>>> Then suddenly a new question popped up: how many behaviours are >>>>>>>>> acceptable. >>>>>>>>> >>>>>>>>> I bet number of folks including myself said "one" keeping in mind >>>>>>>>> previous discussions and the definition of "one" meaning based on the SRv6 >>>>>>>>> data plane in compliance to [RFC8402], [RFC8754] and [RFC8986]. >>>>>>>>> >>>>>>>>> Interestingly enough the draft in question defines not behaviours >>>>>>>>> but flavors as new variants of the already defined behaviors in Standards >>>>>>>>> Track RFCs. Namely it defines: >>>>>>>>> >>>>>>>>> 4.1. NEXT-C-SID Flavor >>>>>>>>> 4.2. REPLACE-C-SID Flavor >>>>>>>>> >>>>>>>>> The newly defined behaviour End.XPS is optional. >>>>>>>>> >>>>>>>>> So if there is anything to ask here is to check if WG is ok with >>>>>>>>> two flavors or not. I do not recall that question has ever been asked >>>>>>>>> formally during the WG adoption call. >>>>>>>>> >>>>>>>>> With that let's note that optimal compressed SID size may be >>>>>>>>> different network to network. One size does not fit all. Draft says: >>>>>>>>> >>>>>>>>> 6.1. C-SID Length >>>>>>>>> >>>>>>>>> The NEXT-C-SID flavor supports both 16- and 32-bit C-SID >>>>>>>>> lengths. A >>>>>>>>> * C-SID length of 16-bit is recommended.* >>>>>>>>> >>>>>>>>> The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID >>>>>>>>> lengths. >>>>>>>>> * A C-SID length of 32-bit is recommended.* >>>>>>>>> >>>>>>>>> While I personally think 8-bit should be an option, if we choose a >>>>>>>>> single flavor we will introduce suboptimality for no good reason. Hardware >>>>>>>>> capable of supporting any flavor clearly can do LPM on locator. Also >>>>>>>>> hardware capable of supporting one flavor can support few other flavors as >>>>>>>>> this is pretty much just an offset game. >>>>>>>>> >>>>>>>>> Kind regards, >>>>>>>>> Robert >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica >>>>>>>> 40juniper.net@dmarc.ietf.org> wrote: >>>>>>>>> >>>>>>>>>> Pablo, >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Ae you sure? Please look at the question as Joel asked it ( >>>>>>>>>> https://mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ >>>>>>>>>> ). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Ron >>>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> spring mailing list >>>>>>>>> spring@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/spring >>>>>>>>> >>>>>>>> --0000000000003862a705cda35292 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Robert,
that is a more elegant way to mitigate the = problem. But the fact that you need to use the control or management plane = to disseminate the mapping between the particular flavor and corresponding = prefix still tells me that in the data plane these flavors are distinct and= incompatible entities, i.e., different data plane solutions to the SRv6 SI= D compression.

Regards,
Greg
=
On Tue= , Oct 5, 2021 at 3:39 PM Robert Raszuk <robert@raszuk.net> wrote:
Greg,

When you re= ceive any packet you do a LPM on the dst address. The result of that lookup= reveals the secret on how to handle the packet further.=C2=A0
What is non-interoperable here ? I see You would love to have = a few bits next to the locator=C2=A0prefix to specify=C2=A0verbatim what to= do with the packet ? What for ? To run out of those bits in no time and ma= ke a mess ?=C2=A0

On Wed, Oct 6, 2021 at 12:20 AM Greg Mirsky <gregimirsky@gmail.co= m> wrote:
"Secret sauce" is another way to say not-inter= operable. And that is exactly the point I am making.

<= /div>
Regards,
Greg

=
On Tue, Oc= t 5, 2021, 15:17 Robert Raszuk <robert@raszuk.net> wrote:
That's not the case. = You can map locator=C2=A0prefix to specific compression schema used as an e= xample ... This is pure implementation choice - I would say vendor's se= cret sauce.=C2=A0

On Wed, Oct 6, 2021 at 12:11 AM Greg Mirsky <gregimi= rsky@gmail.com> wrote:
I am not asking how to deal with the fact t= hat the mode cannot manage different flavors using just information that is= in the packet. I am pointing that out and you are trying to avoid to ackno= wledge that the problem exists. That's your choice.=C2=A0

Regards,
Greg
<= /div>
O= n Tue, Oct 5, 2021, 15:07 Robert Raszuk <robert@raszuk.net> wrote:=
To me the easiest option here is to simply configure on each node selecte= d compression schema for the domain. Do you see anything wrong with it ?=C2= =A0

On Wed, Oct 6, 2021 at 12:05 AM Greg Mirsky <gregimirsk= y@gmail.com> wrote:
Hi=C2=A0Robert,
sorry,=C2=A0 = but it doesn't seem to address my concern. My question is not about mix= ing compression flavors in the same SRH (that is an interesting case of its= own). I am asking how a node that supports all the flavors defined in the = draft would parse an SRv6 packet with compressed SIDs in the SRH. The impre= ssion I've got so far, is that is not possible for a node to process a = SID correctly without preconditions of "planning". In other words= , a controller constructs the list on the assumption that each node support= s one and only one flavor of CSID compression. Thus, I can conclude, that t= he defined flavors are mutually exclusive and thus are different data plane= techniques of the SRv6 SID compression.=C2=A0

<= /div>
Regards,
Greg

=
On Tue, Oc= t 5, 2021, 14:41 Robert Raszuk <robert@raszuk.net> wrot= e:
Greg,

SRH should have an equal size SIDs. That notio= n applies to compress SIDs. Mixing multiple flavors in a single domain node= to node seems of no use to me. Within your domain you are subject to the d= omain architecture=C2=A0which is the key factor=C2=A0what compression schem= e is chosen.=C2=A0

Across domains (say you own N d= omains) the compressed SID size may vary.=C2=A0

Do= es this answer=C2=A0your and maybe Ron's question ?=C2=A0
Thx,
R.


On Tue, Oct 5, 2021 at 11= :36 PM Greg Mirsky <gregimirsky@gmail.com&g= t; wrote:
Hi Robert,
as I understand it, you believe everything that i= s written in the draft. I hope you can help me find an answer to one simple= question:
Can a node that supports this draft in its entirety, i= .e., supports all "flavors" defined in the document, process rece= ived SRv6 packet with the SRH encoded according to the specification?
=
So far, the proponents of the draft referred to "planning= " how flavors of SRv6 SID compressed. To the best of my understanding,= that is is a clear demonstration of the incompatibility between flavors de= fined in the CSID draft. Regardless of=C2=A0what is written in it.

Regards,
Greg

On Tue, Oct 5, 2021 at 1:24 P= M Robert Raszuk <robert@raszuk.net> wrote:
=
Ron & SPRING WG chairs,

Throug= h this discussion we first have seen a debate if we need one or more data p= lanes=C2=A0to compress SIDs in SRv6. WG clearly=C2=A0stated we need one.=C2= =A0

Following that we have observed a first termin= ology shift to see if asking how many solutions should be supported will wo= rk any better. To that many WG members clearly stated that they support one= solution.=C2=A0

Well please notice that the draft= in question in its introduction states:=C2=A0

Abs= tract

=C2=A0 =C2=A0This document defines a compressed SRv6 Segment L= ist Encoding in the
=C2=A0 =C2=A0Segment Routing Header (SRH). =C2=A0= This solution does not require any SRH
=C2=A0 =C2=A0data plane chang= e nor any SRv6 control plane change. =C2=A0This solution
=C2=A0 = =C2=A0leverages the SRv6 Network Programming model.

So based on my understanding of English the entire draft talks about = a single solution.=C2=A0

Then suddenly a new quest= ion popped=C2=A0up: how many behaviours are acceptable.=C2=A0
I bet number of folks including myself said "one" kee= ping in mind previous discussions and the definition of "one" mea= ning based on the SRv6 data plane in compliance to [RFC8402], [RFC8754] and= [RFC8986].

Interestingly enough the draft in ques= tion defines not behaviours but flavors as new variants of the already defi= ned behaviors in Standards Track RFCs. Namely it defines:=C2=A0
<= br>
4.1.=C2=A0 NEXT-C-SID Flavor
4.2.=C2=A0 REPLACE= -C-SID Flavor

The newly defined behaviour End.= XPS is optional.=C2=A0

So if there is anything to ask here is to che= ck if WG is ok with two flavors or not. I do not recall that question has= =C2=A0ever been asked formally during the WG adoption call.=C2=A0

With that let's note that optimal compressed SID size m= ay be different network to network. One size does not fit all. Draft says:= =C2=A0

6.1.=C2=A0 C-SID Length

=C2=A0 =C2=A0The NEXT-C-SID fl= avor supports both 16- and 32-bit C-SID lengths. =C2=A0A
=C2=A0 =C2= =A0C-SID length of 16-bit is recommended.

=C2=A0 =C2=A0The REPLA= CE-C-SID flavor supports both 16- and 32-bit C-SID lengths.
=C2=A0 = =C2=A0A C-SID length of 32-bit is recommended.

=
While I personally think 8-bit should be an option, if we choose a sin= gle flavor we will introduce suboptimality for no good reason. Hardware cap= able=C2=A0of supporting any flavor clearly can do LPM on locator. Also hard= ware capable of supporting one flavor can support few other flavors as this= is pretty much just an offset game.=C2=A0

Kin= d regards,
Robert



On= Tue, Oct 5, 2021 at 9:43 PM Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org> wrote:
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/ma= ilman/listinfo/spring
--0000000000003862a705cda35292-- From nobody Tue Oct 5 19:53:16 2021 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 A878E3A0954; Tue, 5 Oct 2021 19:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g4LHnihhrIjV; Tue, 5 Oct 2021 19:53:10 -0700 (PDT) Received: from mail-pj1-x1029.google.com (mail-pj1-x1029.google.com [IPv6:2607:f8b0:4864:20::1029]) (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 44F1A3A093B; Tue, 5 Oct 2021 19:53:10 -0700 (PDT) Received: by mail-pj1-x1029.google.com with SMTP id np13so1067437pjb.4; Tue, 05 Oct 2021 19:53:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=0s1zWmKL+gN9bHRti+wAVvpySdA+eevmPxN0Qxok+Nk=; b=qLfKXBhyf411CD9YrgsCIUpQCJ6ZL83Nt8Zk/oUaKTOR0IUx0QOvgSShIPnEAGXC3l hUoEvRPZvUFWjly3yrUsqrPGY1MGF+Ssl26arbmNL+WmsSc9FXFmTJUFQr2FJQLE3cbV M+BYyjFLe8TIx/7xiwCYE73p0osE/hh1YJtV15V0o483INoLuzPs1QAtyamhGjabja4y tZvat3VVVhaQAJduKC6lWfYmLx+N8BlleMJLp0DOlOWADjUAsfrM9s12TstsTgHqlBAl xfSGE50kS0cMHPSURORxaxgdE3JpWbtXUF+39VN4x9+X3P6bl/TVSYXXb9ZU217C2IkV MkkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=0s1zWmKL+gN9bHRti+wAVvpySdA+eevmPxN0Qxok+Nk=; b=eSm5g1pJu2gVZ9BI8xIfpuJT7H/YQgosXb0ahvrLPEWsiQecS0sIlbECpNYyXSvQlR 5Q0SDh5YSIScKVrPDdJxxzg7zKqrpFzcfJ+fH34Ps2C/ZIKyHL29BGLwezneRvkJaoAK aJ7ekfOLNRyfN6hdJp2dkn+aRVz04U9c4tlbGXlQVPeP7p4tsPqnegvtI5hHIbmE+sjz EcxMzEE/ONXDxGUmBolzVI74krM34H+Is3YO8RBQtMJo/piQeMx9hia1fsl7rpNSU4b3 AEd6Wgj/0viny5XaEqO+SHLYhmp1/HCfcGQSK+MXHyyvhLQc43c/Zmt00auytR/Sy9uT wtAA== X-Gm-Message-State: AOAM5305sO9yuQlw0aUQvBVDmTiPp75EZ+P4Y9dCrcED8zPNcryzcTQJ yVsV0zcGL8li8QgPig8d+OY= X-Google-Smtp-Source: ABdhPJxpH9YDhKp+RhxNiDSRsTQizLw38iNecEGV1cnbm26Y0F1x+xrB4vfIOZcMvyUPlYIKl6/JTw== X-Received: by 2002:a17:902:9b88:b0:13e:55b1:2939 with SMTP id y8-20020a1709029b8800b0013e55b12939mr8445245plp.80.1633488789458; Tue, 05 Oct 2021 19:53:09 -0700 (PDT) Received: from Ahmeds-MacBook-Pro-3.local (c-73-189-164-225.hsd1.ca.comcast.net. [73.189.164.225]) by smtp.gmail.com with ESMTPSA id t23sm14553942pgn.25.2021.10.05.19.53.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Oct 2021 19:53:09 -0700 (PDT) To: James Guichard , SPRING WG Cc: "spring-chairs@ietf.org" References: From: Ahmed Bashandy Message-ID: <369d2f7c-a242-8759-2ebd-6f2227c45cc6@gmail.com> Date: Tue, 5 Oct 2021 19:53:07 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EFAE7CFCBC3A2AB5EDC958AC" Content-Language: en-US Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 06 Oct 2021 02:53:15 -0000 This is a multi-part message in MIME format. --------------EFAE7CFCBC3A2AB5EDC958AC Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I support the adoption of this document. * The network programming model (RFC8986) defines multiple behaviors, CSID is just adding the next and replace flavors * The draft proposes a single SRv6 based data plane that defines next and replace behaviors. IMO that is consistent with RFC8986 * CSID has been recommended by the design team for SRv6 based compression * Interop was done. That is more evidence that CSID is a single data plane solution * IMO CSID is ready to become the basis for the SRv6 compression solution * Being an SRv6 data plane-based solution, CSID is coherent with the one data plane solution objective * CSID meets SRv6 compression requirements as single solution Thanks Ahmed On 10/1/21 7:04 AM, James Guichard wrote: > > Dear WG: > > The chairs would like to express their appreciation for all the > responses received to our emails with reference to how the working > group wishes to move forward with respect to a solution for SRv6 > compression. > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > as the basis for its compression standardization work. That is part of > what this email attempts to confirm. > > Because of the above the chairs would like to issue a 2-week WG call > for adoption ending October 15^th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging > that: > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a living document; it may change as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the > working group to publication. A list of these discussion points > will be documented in the WG document and maintained by the > document editor in conjunction with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text > describing an open issue be added to the document in the > above-described open issues section: > * "Given that the working group has said that it wants to > standardize one data plane solution, and given that the > document contains multiple SRv6 EndPoint behaviors that some > WG members have stated are multiple data plane solutions, the > working group will address whether this is valid and coherent > with its one data plane solution objective.". > > Please consider the above guidelines as you decide on whether to > support or not this WG adoption. Please express clearly your reasoning > for support/non-support as well as any open discussion points you > would like addressed should the document be adopted into the working > group. > > Thanks! > > Jim, Bruno & Joel > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --------------EFAE7CFCBC3A2AB5EDC958AC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

I support the adoption of this document.

  • The network programming model (RFC8986) defines multiple behaviors, CSID is just adding the next and replace flavors
  • The draft proposes a single SRv6 based data plane that defines next and replace behaviors. IMO that is consistent with RFC8986
  • CSID has been recommended by the design team for SRv6 based compression
  • Interop was done. That is more evidence that CSID is a single data plane solution
  • IMO CSID is ready to become the basis for the SRv6 compression solution
  • Being an SRv6 data plane-based solution, CSID is coherent with the one data plane solution objective
  • CSID meets SRv6 compression requirements as single solution


Thanks


Ahmed


On 10/1/21 7:04 AM, James Guichard wrote:

Dear WG:

The chairs would like to express their appreciation for all the responses received to our emails with reference to how the working group wishes to move forward with respect to a solution for SRv6 compression.

The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardization work. That is part of what this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that:

  1. The SPRING working group is adopting a document that has multiple SRv6 Endpoint behaviors.
  2. The document is a living document; it may change as it goes through review and analysis by the SPRING working group.
  3. All open discussion points raised on our mailing list MUST be addressed BEFORE said document is allowed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maintained by the document editor in conjunction with the chairs.
  4. If this document is adopted by the working group, the chairs specify as part of the adoption call that the following text describing an open issue be added to the document in the above-described open issues section:
    • "Given that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this is valid and coherent with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not this WG adoption. Please express clearly your reasoning for support/non-support as well as any open discussion points you would like addressed should the document be adopted into the working group.

Thanks!

Jim, Bruno & Joel


_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
--------------EFAE7CFCBC3A2AB5EDC958AC-- From nobody Tue Oct 5 20:28:11 2021 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 C0E033A0AE8; Tue, 5 Oct 2021 20:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 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, 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=O+Oa9Gqn; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=E4XE4O3F 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 3eEHq6IQhdTN; Tue, 5 Oct 2021 20:27:59 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D62763A0ADF; Tue, 5 Oct 2021 20:27:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18892; q=dns/txt; s=iport; t=1633490878; x=1634700478; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uiX7lTGVndbmoaFqWSwKXOdEBcx4eq1vPIKdYtdJZcA=; b=O+Oa9Gqnj1ZLXR2zAKOf/cv/THu608VnQJHgPyagFtY/BGuS58ZrQUvM iCE08BtNl24wxnvlHFjq4wS7pGyQyHHLjTyB15W/GAGEFzHqV61OEltqu XTmrqwLgdkQcbo5cMsUoUiFIAVwIs75aC/u8HrL+CtShVj4MRBNm5zT+B Y=; IronPort-PHdr: =?us-ascii?q?A9a23=3AmNQSQB//EDxWDP9uWDnoyV9kXcBvk7T5IgBT7?= =?us-ascii?q?YAo2PpCcaWmqpLlOkGXpfBgl0TAUoiT7fVYw/HXvKbtVS1lg96BvXkOfYYKW?= =?us-ascii?q?0oDjsMbzA0tHMDDDlf0f7bmaiUgF5FEU1lot3iwLUlSHpP4YFvf6n2/5DIfA?= =?us-ascii?q?FPxLw1wc+/0AYXVyc+w0rPaxg=3D=3D?= IronPort-Data: =?us-ascii?q?A9a23=3ABZfed6D9thQtzhVW/wnhw5YqxClBgxIJ4kV8j?= =?us-ascii?q?S/XYbTApDMk3mZSnWMWDT2GOazeZDHwcth1boy29EJT6JHQxtVmOVdlrnsFo?= =?us-ascii?q?1CmBibm6XV1Fqp7Vs+rBpWroHlPsoNON7EsEOhuFiWF/0/1b+C6xZVB/fjgq?= =?us-ascii?q?oTUWbas1h9ZHWeIeA954f5Ss7ZRbrxA2LBVMCvV0T/GmPAzDXf+s9JC3s343?= =?us-ascii?q?IrYwP9nlKyaVDr1JTXSb9gT1LPVvyF94J7yuciMw3XErol8RoZWRs7Zx72/u?= =?us-ascii?q?2je5RpoUJWuk63wdQsBRbu60Qqm0yUNHfP9xEkZ4HVvic7XN9JEAatTozmFg?= =?us-ascii?q?tN80/1GtIe7TkEiOaikdOE1AkUFSHggYPIakFPACT3l2SCJ9GXda2HtxfpGD?= =?us-ascii?q?UwqM8sf4OkfKT9L/PowKT0RYFaEne3e/V4RYoGAnew5J8XteYgYoHwll3fSD?= =?us-ascii?q?O0tRtbIRKCi2DOR5x9o7ugmIBoUT5NxheJTUSn9?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AJpVn86kLgmVtqEgda5CzvC9fR5jpDfN1iW?= =?us-ascii?q?dD5ihNYBxZY6Wkfp+V/cjzhCWbtN9OYh4dcIi7Sda9qXO1z+8T3WBjB8bdYO?= =?us-ascii?q?CGghrpEGgG1+vfKlLbalbDH4JmpMJdmu1FeaHN5DtB/IXHCWuDYqwdKbC8mc?= =?us-ascii?q?jC74qzvhQdLz2CKZsQkjuRYTzrdHGeMTM2fabRY6Dsn/avyQDQHUg/X4CePD?= =?us-ascii?q?0oTuLDr9rEmNbNehgdHSMq7wGIkHeB9KP6OwLw5GZdbxp/hZMZtUTVmQ3w4a?= =?us-ascii?q?uu99uhzAXH6mPV55NK3PP819p4AtCWgMR9EESotu/oXvUkZ1SxhkFynAid0i?= =?us-ascii?q?dyrDAKmWZ5Ay1H0QKXQohym2q35+Cv6kd115ao8y7ovZKqm72IeNt9MbsduW?= =?us-ascii?q?qcGSGptHbJe7pHof52Niuixuhq5R+splWP2/HYEx5tjUa6unwkjKoaiGFeS5?= =?us-ascii?q?IXbPtLoZUY5149KuZNIMvW0vFsLABVNrCQ2B+WSyLtU1nJ+m10hNC8VHU6GR?= =?us-ascii?q?mLBkAEp8yOyjBT2HR01VERysATlmoJsMtVcegL283UdqBz0L1eRM4faqxwQO?= =?us-ascii?q?8HXMusE2TIBRbBKnibL1jrHLwOf3jNt5n06rMo4/zCQu1G8LIi3JDaFF9Iv2?= =?us-ascii?q?87fEzjTcWIwZ1Q6xjIBH6wWDz8o/surKSReoeMDIYDFBfzCWzGv/HQ18n3M/?= =?us-ascii?q?erEspbYqgmdsMLBVGebrp04w=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AyCgBhF11h/5ldJa1agQmBWYEhMFE?= =?us-ascii?q?Hdw5MNzGIDwOFOYgIA5psgS4UgREDVAsBAQENAQFBBAEBhH0CgkQCJTYHDgE?= =?us-ascii?q?CBAEBARIBAQUBAQECAQYEgREThWgBDIZCAQEBAQMSCxATAQEuCQEPAgEIEQE?= =?us-ascii?q?DAQEeETIXBggBAQQOBQgaglCBflcDLwGkUQGBOgKKH3iBM4EBgggBAQYEBIU?= =?us-ascii?q?KGII1CYE6gwCEE4JzgwR7JxyBSUQmbkSCZz6EB0AkgymCLoosLiRRMgQvRS+?= =?us-ascii?q?TYhOMNp91CoMwnwEUpw2WJaU7AgQCBAUCDgEBBoFoBy2BWXAVO4JpURkPjiw?= =?us-ascii?q?Wg1CKXnQ4AgYLAQEDCZVxAQE?= X-IronPort-AV: E=Sophos;i="5.85,350,1624320000"; d="scan'208,217";a="945316574" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Oct 2021 03:27:41 +0000 Received: from mail.cisco.com (xbe-aln-006.cisco.com [173.36.7.21]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 1963Rf2j009442 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 6 Oct 2021 03:27:41 GMT Received: from xfe-rtp-005.cisco.com (64.101.210.235) by xbe-aln-006.cisco.com (173.36.7.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 5 Oct 2021 22:27:41 -0500 Received: from xfe-rcd-004.cisco.com (173.37.227.252) by xfe-rtp-005.cisco.com (64.101.210.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 5 Oct 2021 23:27:40 -0400 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-004.cisco.com (173.37.227.252) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Tue, 5 Oct 2021 22:27:40 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SRru3EiDTYCkF6YBpOENYHuakEjm5lf3reTHklltFAdEJZuvLQF5yeDmVVPCvMEG3h21eEvYf569o+0bSim3a5e1+Dp5oaMyqcISClOUsp9bh2hGbeCyeG/uRHAjweF70bmESjAHgVksIyejRnN3q6Z/9qwlZjFN0NGBvxH3ZiGqUc1I10uUCWZMJrmuvXfDSUReOd8jRqdbo6s4mjpOgQxftXlmKM5w7/d9Hhrg/OtOkVbrus1+ODRDptUxgsjQhbV+cJU+e83S30d3pWOxo9+wtkUEqrWC0S/RIkBrveVnBZUvKbqyotJ9WBY+xa//prqhh9k3Fo4VupOsIiGkxQ== 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=9cs1LqnrrEzyfFrtC9RNaI5frNPdD9D0buya6isp5lc=; b=CStJ0vh7/2NZGqndFanOFJDYC5psYnPQ01hrpyxlwFasG9J8bb6gmjhmjy+yHyxiW5i25GeZyIuL59BvkfEILZC4gWUy3fM5A1pNBI0hdSFr+LHEJoCBP6PFIGUNb7ug63qnKznAd94yLv8tWNnbFxe/0N446/mv8sYY1CEV7mrNy+WCTP4wfLjGlGLpKS8NFB4X9VhTfLJ/e2bu0yz9rQ+MW6fVNM8WYwRdH7qXfdZGyrC1+FGtPg3naJDpA+mWeuadQH1tBSmcWnrHnoJXxCDt5EYZT8DUp4VZIgXkwQLNV4GWnHe88+6L52d8tcxmMFdBFXkRtLOZGS3oBnkWmA== 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=9cs1LqnrrEzyfFrtC9RNaI5frNPdD9D0buya6isp5lc=; b=E4XE4O3FjuTIne13A5sX5VXuNzO4k9ExbcDzltV1PsZA5aZ6oAN26nIbtr/qPtm21QU4I8GHtwWy7DLOw0gq3JtUMFa3Iz7ggMhVusA5zL07AAslReqMBQqysqtPZlMGwCt/keaMTsKJiBE1u95kTU+KtrY79Ylj0YqpMENCINA= Received: from BN6PR11MB4081.namprd11.prod.outlook.com (2603:10b6:405:78::38) by BN6PR11MB1553.namprd11.prod.outlook.com (2603:10b6:405:e::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.18; Wed, 6 Oct 2021 03:27:34 +0000 Received: from BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::547a:c1c1:ef01:f46e]) by BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::547a:c1c1:ef01:f46e%3]) with mapi id 15.20.4566.022; Wed, 6 Oct 2021 03:27:34 +0000 From: "Darren Dukes (ddukes)" To: "6man@ietf.org" <6man@ietf.org> CC: SPRING WG Thread-Topic: draft-filsfilscheng-spring-srv6-srh-compression-02 Thread-Index: Ade3AXyWK2NzAamgSlCvJ497z/5RLwC/aCkQAAt0zYc= Date: Wed, 6 Oct 2021 03:27:33 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-05T16:58:35.0000000Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 759abb47-9916-4a58-4a08-08d988793ccc x-ms-traffictypediagnostic: BN6PR11MB1553: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: n3MsaA6uwHfd4b3222ESDUUW0TeZDHW23wMCw6ZnrOkGpe3YFBSMB8hoHJd3gz1Itdvwpj/z4GMdE4khZQyiC8ni8dUSg13ru4uEsT52e43uHPGOc/zxMLFYwU3eNS07kMBdpDtib+JctQp2l2ZnlfXErsYtqKP0opdFjG0Itrt5syz1DNOOdatmNq7krMlk0aF14W2VG1H/FjpyuXHFk6bp1B/JK9DFN4d/oxYibCibu6DBTqLxXCgZc1y/ZkWkQpwIAH0FJdXhqoafJiMrGFmnAaLKPzcspIHAkAD6YExY5g6IXoWYDXrKgFpMCze+hBgySZ4t+v1lbxbf6QO/gbAsTqkD9cyCfIUUczhAEgsd+8NpeBBwbXW/SQXJvkgKLeKyI3UmfKMKRW08iq3WblP9NfXsxsSFuzFrnVpMWItPtEwZFu3jA7Q/qak24Kl/tUbpip1MhB+AUeQaeibKCFxnTs2tMyYy3DdDVVA6qm6WIjoykoeZ9ALnPSsph4XZeisNjwsYuY1YV5fKtjgdbAytPDfh0zReixqxtdinE3ObYsPmu1ObYvoVZR+w7YvT38zMBboW5y4m+dLpKntOtWOj8VCleTQ/mzJ9zh7gW+deOqfLUffclwG+nT6V6FWfxFN+/yUPDWb/XAYmOD0Fq3oXsD+i5P9ICfF4S+mJNmKukZAxBQQIXzXc3GhN7PzCaEs4rbuSPQcANDfovPVKlQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB4081.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(2906002)(122000001)(91956017)(38100700002)(83380400001)(7696005)(76116006)(9686003)(450100002)(186003)(71200400001)(52536014)(38070700005)(316002)(8936002)(6916009)(4326008)(26005)(8676002)(66946007)(5660300002)(6506007)(55016002)(33656002)(66476007)(66446008)(64756008)(66556008)(508600001)(53546011)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?fqazDMznXw0m35AQcRbi4S83TSHIZ6YIfBNF3M7Jq22xq0OjWj5lDD62?= =?Windows-1252?Q?xVKGPoaC7g/kmF0sTXVvo2CUMnd6+nWA45BhhvHgVv/fC8MGXmjBMqKe?= =?Windows-1252?Q?no+BdDWoGY360Gm8iy2J/NHDHFQHTmfiIAMrISRH0Zji7KbbzY+GqIas?= =?Windows-1252?Q?HIJUmE9qaEFqTm8C3+nOHZbJaw1pwVjIE7UmcpPUJehkjPZDdma43q3w?= =?Windows-1252?Q?PGHeljeiCViy+gZc15d1Jzbb24GNqjX6cRWw112Jdo8PS6MJcLQnadRv?= =?Windows-1252?Q?aPPMhsUPfnodMrwObsnG+hBA1rkim+fENr7su1uh++RVwrYHAqCeQFEC?= =?Windows-1252?Q?Kdyz/TSIAMjYTfliZpDjs8QiMuS2lA45YDrOQbHMg843PTkLFbwlRDUD?= =?Windows-1252?Q?pspHqxOz4j2Y23m7YLwHVu+FKiotd558iFMYu4VVatLRgfIK7AQH2Gd1?= =?Windows-1252?Q?ZVi2lt482RBwtEK2wVD3unDV7zc8r9ovNaWfJTvoRD+KK69uGao+AA6y?= =?Windows-1252?Q?H2X4iLoSbUBfJBmSSAcZoOZk/g6HBMAlra/Teu/MweIQGxlUc7AFOOOw?= =?Windows-1252?Q?Ayqcm+jJBnjUN4/Vw8zCSJfofdUwwjmAA6fA/ybMN3yZ72Xfs973olgB?= =?Windows-1252?Q?2ryfM7MJqK7awXjOenv1EJKZpaaWzeOr/lRc1W7OC8sE+MSpWOEghSk2?= =?Windows-1252?Q?PDeLn+gjD9BqwaqD3RgyjK7KsGNtpOQKOuyMIezpXx4JH5hx8rg122tL?= =?Windows-1252?Q?LcJqXY7wpEKIgM1558eLOYWgeqcw4ECx+5gy6C3Xvdub1lMs65k0D7iv?= =?Windows-1252?Q?V6gg6594/gm1cxmG3OSldkdOor1UNNQ1mi9AVyyrofNqnE2v+Sxa0Dl8?= =?Windows-1252?Q?PCG9wcFd1Vbf7I/bOFif44uwTgdi77MX4+gke/ojmFIzqmxQsnMoAmHG?= =?Windows-1252?Q?0gJ0ozXgDbrJNxzgm7U3vl+knLIuBoyN66yTyGBGd3ZOUUoMlG/U92BA?= =?Windows-1252?Q?TkBdcNRXKeBUoHLbjqWfs+YgWxnHLV4sN+yUS2ZHfRWUWzzfriMEP9DU?= =?Windows-1252?Q?hVj6joTyyJqmDvaw9MHnHDzHCPxfmMV2OpZMQlDKrIJY1rZB5dXpzcmM?= =?Windows-1252?Q?3qYXnZgl5HaevzZ1RgGbDfCp69w/Y3WCTqD+bfn76GOrniRTadmoG5mF?= =?Windows-1252?Q?TwY+9+AgwRhz1dFkvbfFWHsiF2IzTL0naP042CHJIcYxK5x3k2XqiatT?= =?Windows-1252?Q?W2H5lmxHW5FkVWqFeooPEmMbh2y1/vGhdvWSGg23OvsSaij8I1WfPP3z?= =?Windows-1252?Q?72RpjlTxoL1jEV3kyD7vetT4HDZicn/30q/tZHyLfGpZfIXgU60SW4Dh?= =?Windows-1252?Q?jJRwo8u6wnrYqnyftRZ13+fbfTfwCC5ZIec0uy+trq+y9zM2BxMk3AYc?= =?Windows-1252?Q?UGxomujXrXYUlMr2gyFiXg=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN6PR11MB40811A0C4959E77D785AC5C9C8AF9BN6PR11MB4081namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN6PR11MB4081.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 759abb47-9916-4a58-4a08-08d988793ccc X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2021 03:27:33.9159 (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: 9i0kar5VoVTyONR9bZB/l6IP/LNe2IHoYVkBbxc5dodTB7JwRXXBMC38N6v1aCSgsFQbr3moi9dmxnSDuRORDw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1553 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.21, xbe-aln-006.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 06 Oct 2021 03:28:05 -0000 --_000_BN6PR11MB40811A0C4959E77D785AC5C9C8AF9BN6PR11MB4081namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi 6man, A CSID is an SRv6 SID. It utilizes the SRv6 SID format defined in= RFC8986 (not RFC8896) section 3 =93This document defines an SRv6 SID as co= nsisting of LOC[ator]:FUNCT[ion]:ARG[ument]=94. Darren On 2021-10-05, 12:59 PM, "spring" wrote: Folks, In a private communication, someone asked for specific references to RFCs 8= 200 and 4291 that were difficult to harmonize with draft-filsfilscheng-spri= ng-srv6-srh-compression. References follow: Section 3 of RFC 8200 ----------------------------- =93The Destination Address field of the IPv6 header contains the =93128-bit= address of the intended recipient of the packet (possibly not the ultimate= recipient, if a Routing header is present). See [RFC4291] and Section 4.4= .=94 Section 2 of RFC 4291 ----------------------------- =93IPv6 addresses are 128-bit identifiers for interfaces and sets of interf= aces (where "interface" is as defined in Section 2 of [RFC8200])=94. Section 2 of RFC 8200 ------------------------------ - An interface is =93a node's attachment to a link=94 - A link is =93a communication facility or medium over which nodes = can communicate at the link layer, i.e., the layer immediately below IPv6.= =94 So, an IPv6 Destination Address represents a single thing that is instantia= ted on a single node. According to draft-filsfilscheng-spring-srv6-srh-compression-02, A Compress= ed-SID container (C-SID container) is =93an entry of the SRH Segment-List f= ield (128 bits) that contains a sequence of C-SIDs.=94 A C-SID is =93a C-S= ID is a short encoding of a SID in SRv6 packet that does not include the SI= D block bits (locator block).=94 According to RFC 8896, a SID identifies an instruction on a node. And finally, according to draft-filsfilscheng-spring-srv6-srh-compression-0= 2, an SRv6 node can copy a container C-SID to the Destination Address fiel= dd of theIPv6 header. When this happens, the IPv6 Destination Address doesn=92t represent a singl= e thing on a single node. It represents an entire SR path. = Ron Juniper Business Use Only From: Ron Bonica Sent: Friday, October 1, 2021 4:35 PM To: 6man@ietf.org Cc: SPRING WG Subject: draft-filsfilscheng-spring-srv6-srh-compression-02 Folks, Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new SID= types that can occupy the Destination Address field of an IPv6 header. See= Sections 4.1, 4.2, and 4.3 of the draft for details. The SPRING WG has issued a call for adoption for this draft. It is not clear that these SID types can be harmonized with the IPv6 addres= sing architecture. Does anyone have an opinion? = Ron Juniper Business Use Only --_000_BN6PR11MB40811A0C4959E77D785AC5C9C8AF9BN6PR11MB4081namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi 6man, A CSID is an SRv6 SID.=   It utilizes the SRv6 SID format defined in RFC8986 (not RFC8896) sec= tion 3 =93This document defines an SRv6 SID as consisting of LOC[ato= r]:FUNCT[ion]:ARG[ument]=94. 

 

Darren

 

On 2021-10-05, 12:59 PM= , "spring" <spring-bounces@ietf.org> wrote:

 

Folks,

 

In a private communication, someone asked for spec= ific references to RFCs 8200 and 4291 that were difficult to harmonize with= draft-filsfilscheng-spring-srv6-srh-compression. References follow:

 

Section 3 of RFC 8200
-----------------------------

=93The Destination Address field of the IPv6 heade= r contains the =93128-bit address of the intended recipient of the packet (= possibly not the ultimate recipient, if a Routing header is present).  See [RFC4291] and Section 4.4.=94

 

Section 2 of RFC 4291

-----------------------------

=93IPv6 addresses are 128-bit identifiers for inte= rfaces and sets of interfaces (where "interface" is as defined in= Section 2 of [RFC8200])=94.

 

Section 2 of RFC 8200

------------------------------

-         An interface is =93a node's attachment to a link=94

-         A link is =93a communication facility or medium over which nodes can co= mmunicate at the link layer, i.e., the layer immediately below IPv6.=94

 

So, an IPv6 Destination Address represents a singl= e thing that is instantiated on a single node.

 

According to draft-filsfilscheng-spring-srv6-srh-c= ompression-02, A Compressed-SID container (C-SID container) is =93an entry = of the SRH Segment-List field (128 bits) that contains a sequence of C-SIDs.=94 A C-SID is =93a  C-SID is a short e= ncoding of a SID in SRv6 packet that does not include the SID block bits (l= ocator block).=94

 

According to RFC  8896, a SID identifies an i= nstruction on a node.

 

And finally, according to draft-filsfilscheng-spri= ng-srv6-srh-compression-02, an SRv6 node can copy a container C-SID to the =  Destination Address fieldd of theIPv6 header.

 

When this happens, the IPv6 Destination Address do= esn=92t represent a single thing on a single node. It represents an entire = SR path.

 

        &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            Ron<= o:p>

 

 

 

Juniper Business= Use Only

From: Ron Bonica
Sent: Friday, October 1, 2021 4:35 PM
To: 6man@ietf.org
Cc: SPRING WG <spring@ietf.org>
Subject: draft-filsfilscheng-spring-srv6-srh-compression-02

 

Folks,

 

Draft-filsfilscheng-spring-srv6-srh-compression-02= introduces three new SID types that can occupy the Destination Address fie= ld of an IPv6 header. See Sections 4.1, 4.2, and 4.3 of the draft for details.

 

The SPRING WG has issued a call for adoption for t= his draft.

 

It is not clear that these SID types can be harmon= ized with the IPv6 addressing architecture.

 

Does anyone have an opinion?

 

        &n= bsp;            = ;             &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          Ron

 

 

Juniper Business= Use Only

--_000_BN6PR11MB40811A0C4959E77D785AC5C9C8AF9BN6PR11MB4081namp_-- From nobody Tue Oct 5 20:57:46 2021 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 674783A0BDE; Tue, 5 Oct 2021 20:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=guR5TFr0; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=WbRciRHE 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 M6_xpD67hmHw; Tue, 5 Oct 2021 20:57:38 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15D223A0BDC; Tue, 5 Oct 2021 20:57:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13639; q=dns/txt; s=iport; t=1633492658; x=1634702258; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mkHTomUvbT2bYoG+l/KpCMnFhUGst+MfKA5PCIFtvao=; b=guR5TFr0kHuFPSwczmgFCPAJ0tmwcV3h4DwMaZYo556YbklrWayAqmQJ uZa5D21ff7+EfL7UGZloAsaRt6ispm8vDfVXBnfs0Zj1yUJpE4yeyQi1U KSx9HQSOq2YUBY8s78j9sm6ZxGUeBXgwE49+aq6hPqhCVkN90K3NcUn46 k=; IronPort-PHdr: =?us-ascii?q?A9a23=3A9uXlSRyuYYTVDhDXCzPBngc9DxPP853uNxUH9?= =?us-ascii?q?5lhjb9SIeyv/JXnaUrY4/glzFrERp7S5P8Mje3K+7vhVmoN7dfk0jgCfZVAW?= =?us-ascii?q?gVDhZAQmAotU9SMEl/mL7jsYjBpVMhHXUVuqne8N0UdEc3iZlrU93u16zNaG?= =?us-ascii?q?hj2OQdvYOrvHYuHhMWs3Of08JrWMG11?= IronPort-Data: =?us-ascii?q?A9a23=3AImcqwqve2NNzxy0XK3NIh9ss6OfnVNRcMUV32?= =?us-ascii?q?f8akzHdYApBsoF/qtZmKT+Gb/mNYGHycookPYm280wDucLcy9NgGldq/C82F?= =?us-ascii?q?i1AgMeUXt7xwmUckM+xwmwvdK/shiknQoGowPscEzmM+39BDpC79SMljPnQG?= =?us-ascii?q?+KnYAL5EnkZqTFMGX9JZS1Lw4bVsqYw6TSIK1vlVeHa+qUzC3f9s9JACV/43?= =?us-ascii?q?orYwP9ZUFsejxtD1rA2TagjUFYzDBD5BrpHTU26ByOQroW5goeHq+j/ILGRp?= =?us-ascii?q?gs1/j83Ad+j1738aEBPG/jZPBOFjTxdXK3Kbhpq/3NplP1kcqtHLx4K0V1ln?= =?us-ascii?q?PgpoDlJnZC8VAQkJYXHmf8WVF9TFCQW0ahuqeOecSLm6JzJp6HBWz62qxl0N?= =?us-ascii?q?2ktJZcZ/OkyCmFH9OYDADEAch7FgPi5qJqgUvNtgMsLLcT3MsUYoH4I5TPQC?= =?us-ascii?q?Ps9B5aFTLjL7t9RxjsYiN1SAOzTeMcYLzFoaXzoeRdIPFYcAcdixOW1gHjnf?= =?us-ascii?q?icerl+JjaYy6nLYig18zLarN8DaEvSQQs9YhFqwvGvd7Xn6RBcXKLSiJZCtm?= =?us-ascii?q?p63rvXEkSW+U4UIGfjhsPVrm1aUgGcUDXUruZKAiaHRoiaDtxh3cCT4IhYTk?= =?us-ascii?q?JU=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3At19F2q2Gaxt3sd7HxlujjAqjBRByeYIsim?= =?us-ascii?q?QD101hICG9Lfb4qyn+ppomPEHP5wr5AEtQ5uxpOMG7MBThHO1OkPcs1NaZLU?= =?us-ascii?q?jbUQ6TTL2KgrGSuAEIdxeOk9K1kJ0QD5SWa+eATWSS7/yKmjVQeuxIqLLsnc?= =?us-ascii?q?zY5pa9854ud3AWV0gK1XYeNu/vKDwPeOAwP+tBKHPz3LsimxOQPVAsKuirDH?= =?us-ascii?q?gMWObO4/fRkoj9XBIADxk7rCGTkDKB8tfBYlul9yZbdwkK7aYp8GDDnQC8zL?= =?us-ascii?q?6kqeuHxhjV0HKWx4hKmeHm1sBICKW3+4oow3TX+0OVjbZaKvq/VQMO0aeSAZ?= =?us-ascii?q?ER4YDxSiIbToBOArXqDzmISFXWqlLdOX0Vmg7fIBej8AveSIrCNWgH4w4rv/?= =?us-ascii?q?METvMfgHBQ4e2UmZg7rF6xpt5ZCwjNkz/64MWNXxZ2llCsqX5niuILiWdDOL?= =?us-ascii?q?FuJYO5gLZvt3+9Kq1wVh4SKbpXZ9VGHYXZ/rJbYFmaZ3fWsi1mx8GtRG06Gl?= =?us-ascii?q?ODTlIZssKY3jBKlDQhpnFoi/A3jzMF7tYwWpNE7+PLPuBhk6xPVNYfaeZ4CP?= =?us-ascii?q?0aScW6B2TRSVbHMX6UI17gCKYbUki956Lf8fEw/qWnaZYIxJw9lNDIV05Zr3?= =?us-ascii?q?c7fwb0BciHzPRwg1jwqaWGLH3QI+RlltZEU5HHNc/W2By4OSYTepGb0oci6+?= =?us-ascii?q?XgKoKOBK4=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BgCgBZHl1h/5hdJa1aHgEBCxIMQIF?= =?us-ascii?q?OC4EhMFEHd1o3MYgPA4U5iAiVaYUGglMDVAsBAQENAQE3CgQBAYR9AoJEAiU?= =?us-ascii?q?3Bg4BAgQBAQESAQEFAQEBAgEGBIERE4VoDYZDAgEDEgsjAQE3AQ8CAQg1BgQ?= =?us-ascii?q?HMhQRAgQBDQUIEweCUIF+VwMvAQ6kJAGBOgKKH3iBM4EBgggBAQYEBIE2ARN?= =?us-ascii?q?Bgn8YgjUDBoE6gwCEE4ZyJxyBSUSBFAFDgmc+gmMCAgGBXysJgxmCDCKLHQJ?= =?us-ascii?q?iBEMQL0wKWQ0YAjg6ngSfdQqDMIpEiBqFIocBFINnQosolzyHE48SjEmTf4R?= =?us-ascii?q?zAgQCBAUCDgEBBoF3JYFZcBU7gjUBATJRGQ+OIAwWFRmDIoUUhUp0AjYCBgs?= =?us-ascii?q?BAQMJlXEBAQ?= X-IronPort-AV: E=Sophos;i="5.85,350,1624320000"; d="scan'208,217";a="941821182" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Oct 2021 03:57:34 +0000 Received: from mail.cisco.com (xbe-aln-002.cisco.com [173.36.7.17]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 1963vYE7022450 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 6 Oct 2021 03:57:34 GMT Received: from xfe-rtp-003.cisco.com (64.101.210.233) by xbe-aln-002.cisco.com (173.36.7.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 5 Oct 2021 22:57:34 -0500 Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xfe-rtp-003.cisco.com (64.101.210.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 5 Oct 2021 23:57:33 -0400 Received: from NAM04-BN8-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.792.15 via Frontend Transport; Tue, 5 Oct 2021 23:57:33 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=RDBjSY2leEwHTiDcLIhLOTHxdmUhRADUgedkP5abHXRQlYa8GxcMpDV94w2hykTyVUs737xF5Cea1xYLIVpRrwjJLu6U5ZG9ILCQwbofG+pfOE3OuZVSCvxYTdM6wDmCLZBo6CQlKrvkK5T31HZz6VbVM5ne+xWeLA5UtQUbeSjw7+3Y4fi/+pNNZHUIoB0jrLAcbEgwnf3L6vJ+QDm2o2GxON6IkOra7je2Z0entWCT9XGpPp4MohzGDcknKBNbUa/nqPlAEBzYeKHliFX0s6lL4zOWpkPmgPiC6QMa7DnJQl8jCWEB5U1xyCdbDWM5AzH1tCCe5ygrXW+5ZB8FAw== 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=g1yf2ROk79navuoSBBFl/kJ5g9A1/ZvCRYvsTtkrz8I=; b=L1Kzv7TcQIiylc1yUZB2d4qy4GEWJdP9YlQKSJnrJ1pUxEHRnFL+urnyB6tkYN2eR6rawtbr67127s+ctj7aJ+NlDpkvcxX0iEcSk1Jd7HVBccnkw9YiYS87bovwwgbU0O4ks105DEgVKlRla9srLLIAQslEtukd/6YnQy3T0a87Kg+GIw4setKGwyL8cS64FC/G2IV37ZszFTgRf2k1uUHEFnJrvIQQdBQwcVbF4lCsMmjKG17OChfHTIrfOiO8GsRBZHT+c7P5jDDo8XVmdOr9e+fe2U19qkqT917Lkl8/eAKFE4b0xWCepRFLIwHqohMLCwX4VErCrfUXAd9GPw== 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=g1yf2ROk79navuoSBBFl/kJ5g9A1/ZvCRYvsTtkrz8I=; b=WbRciRHEKRjinuFtS/QhrmhE6YNW3hdiLRoXUcEBoNfvIg+jRTb8GklQU4zB3yus1hKwflk/ltARBAsufr+OR8zUEfKEeNbUsM9RZXszSue1Vv7CiwqY0cB7z6XGQdwByfhbEWKHRTAPFvnkByB6O2BYcwbHf9xjbdZn5F/6NlU= Received: from BN6PR11MB4081.namprd11.prod.outlook.com (2603:10b6:405:78::38) by BN6PR11MB1634.namprd11.prod.outlook.com (2603:10b6:405:c::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.14; Wed, 6 Oct 2021 03:57:32 +0000 Received: from BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::547a:c1c1:ef01:f46e]) by BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::547a:c1c1:ef01:f46e%3]) with mapi id 15.20.4566.022; Wed, 6 Oct 2021 03:57:32 +0000 From: "Darren Dukes (ddukes)" To: Robert Raszuk , Ron Bonica CC: James Guichard , SPRING WG , "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQCeJTAAAC58nBAAAQ3tgAAHRGEgAAHK+wAAAE2t4Q== Date: Wed, 6 Oct 2021 03:57:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 753f1cb7-c248-4bd6-dc1c-08d9887d6cd0 x-ms-traffictypediagnostic: BN6PR11MB1634: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ubevJLxtTGrGGrZrY1ZJTIRAf6pFaZu/z39EbbPAO6LFkUJeehjv1TZcuE/5wvmA4dMdqbzKiDP08QcchHOotX4kRa7X2cJgl6aRpSPiys7I1mMizjrhse38LsamCED+ByH7r6FMTzU8siMBjzA9ifxWP0l3KeZt9Im1c30300bwoVOYq7DHnWCxlloFeRvaYjD+xskd7wtmDmXtizUeWjmvKrApmY6NUMq6Gz9gf2MsjB09r6qKrr57N/0iGuS5yPwbQBE7XwUrqZNYUeDPb57hhS3EQBuzse06M0ggH36VtcFEtZivklc7TBPpeSxkiqU19Lxb94XqUOHK3KvuuerXmMsDTAAygEU7vo/4NIKlynXjS+4Lw335O7L4LTb37Y8/TmNlNnkOYfnqbRQh+nl1Ls1NzUSa+pdcxXJTESQ9wPqU1Wuj+GsZFT5nA4SotULBLPsQmBRX1MxyO6eFHusawT/VW4iHQZ9JCpH/+2ga59GEuAwS1Jvc39Z5CK52QXs88I0P/vCYWTGaJ7KIblxzxIg/JBbBTsbskXwLA1n18/pFv2Q06ohw81c+rmWNE02nl4thVVbLDkxaXVvMkjFfbtldkLl2X5pbrIJgrrVnvDEJhSc66cSVAI0Sn3d9hYy/GIPkmL9dg/ArlPCIEP5WKkhTYzTTkgrBnQs797WZ1nIngc/VeLk56x9f7xUXegyJr9zSFGJFbhStYwNi+SEwOoHH81BgBlczTB/LOoL9pI/AhktyO78sAK7IJrn9XoLyjjUjezpNLVVfOm7M1cbnHuJ5J4OkxC3LLLnyS0/F0Xqk9/wtbsQhRrCdCQ3Wxwc5zb1dpZUQBW6Frldq1w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB4081.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(83380400001)(38070700005)(6506007)(186003)(91956017)(76116006)(66476007)(66556008)(64756008)(26005)(66446008)(86362001)(53546011)(66946007)(38100700002)(9686003)(316002)(7696005)(55016002)(71200400001)(122000001)(8936002)(54906003)(110136005)(33656002)(966005)(508600001)(4326008)(2906002)(8676002)(166002)(5660300002)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?RQEvdHHl0cF7jTWHSXM6fbEwCR/jblPpRhdfSp8AmBfg7LXqSIO311e8?= =?Windows-1252?Q?Dm+fcErP5sjBF++OT2Cos4DZv8vtZjOqyJw2q/Ue7lFJcRpQJxwmnpxh?= =?Windows-1252?Q?LdQmXobRPmZ0m/IKa5hqLnv6kWZlXzvYU0cuut6dG5xm3SVsiHDIrGkU?= =?Windows-1252?Q?c8EEtY1ValCJUEDkqAdPZ0OIf7IbToRIwznUIZF43TE4hZ0xqzgb3c/7?= =?Windows-1252?Q?ZM5ai8oFAlkWgG4WcBy+ic2Hu8ENb6mvoS43xX1dNimA8mwoQXZ6p1//?= =?Windows-1252?Q?FyQ/hlFGw1Twsbv9HT2gym0U7GlZbhKqOmt7CiBT1Xayj0M41XZSSSlq?= =?Windows-1252?Q?XXIHWseGwgNDg4m1vYaRB8HocUrOwPSnVMoE5mac29J14DOwlxTsAU34?= =?Windows-1252?Q?TlYJUApnNApg7NnenpeXlTO41jgGUWGc8UulgrnifBcM+j4HzIRmgz+p?= =?Windows-1252?Q?tQOHZpjWWZVTGXfP0NAIR7SJkQIkRC4uuLnV4ZxB0/BAzX01s6FJn1jk?= =?Windows-1252?Q?X5DJgkraJBsSYxPDQHhGvL4OUQ5ZuqZxNrHmDFQFaVX6Lursw7pfQc1Y?= =?Windows-1252?Q?4aGtHPqHQSrk6A67foylv2qL5YB9h3/5s4PCLEtUvOH7JgJrsb5jMogJ?= =?Windows-1252?Q?rae7LnwIxD8FKkgLQ/M7mANiNs74+YkWCXG1/i2RCnxh3nyQ0EMJiM6U?= =?Windows-1252?Q?+KtwOiUHFDSIv/Ej/k6w7HOELTFcKKDFat4g8agNTIcIQXooIXQdCurn?= =?Windows-1252?Q?OVp47UCL2awZi39gpNczh/8lURNg/+2h5drkXd+6/1ZtN8U4o6v+j7CF?= =?Windows-1252?Q?YUvg01ns3sew0dwvls60YY669rKIn7WLDZq98KagRY6EpDgjUJxZUxSn?= =?Windows-1252?Q?5W5EgQwul9fnCdPMBXLFscInch7qSbjAv+dbAaix0DHEn19v5rLV50rn?= =?Windows-1252?Q?NphE2GvOzpH4UmnVKnSV5ct1BcI9jCjgcG1l5K8DKOUewXp9ZIIQAOtC?= =?Windows-1252?Q?RG3ipXYNSXNzYm9C9vbX0mYY8B8l/C9ZBenbPNvSlyajBBBkGVngYGnm?= =?Windows-1252?Q?Om6XoFsAIEmvmqQDvwQ7d2+F/bbzP7KiUiXzfd90FWIDcPCRh8QGQcwv?= =?Windows-1252?Q?czR4TnLv+YD9Youqi8+JaFyij7J3jgqHvSWJP6ev1v5CiuoEw1TMJpRY?= =?Windows-1252?Q?yUSESR3gBDyV18KydLIjHvQVvOzfTDKWrIBXj7Wakh1CIwcbcveAPODp?= =?Windows-1252?Q?24doq7I8lx3rdOjuv0HiYwzLKNlTedLgJjEXNHZOMsLS2NQ5yX576xBJ?= =?Windows-1252?Q?WqY6JIHSUmbUpUOnOhA5iJNvWv3Bl224mPeWokq0vuCFh3EVqtiD4yop?= =?Windows-1252?Q?2D6GFFd4IGGkkxueQCMUc+mvVZQY2npiX4S8vsrtgDMUl+FG8yfWBBvM?= =?Windows-1252?Q?7yEyqpLqB6q4kfcgqSSvEw=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN6PR11MB4081F3002B6C0D37508FA624C8AF9BN6PR11MB4081namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN6PR11MB4081.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 753f1cb7-c248-4bd6-dc1c-08d9887d6cd0 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2021 03:57:32.6023 (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: DUOQMgfLhFZHJeGITB0vv6476J1nZQgVNeCgBQDhoKpNGfyBPuxM+ImtMZ4z7FO9zVgMwV/AxhFJF4DqarqcYA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1634 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.17, xbe-aln-002.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 06 Oct 2021 03:57:43 -0000 --_000_BN6PR11MB4081F3002B6C0D37508FA624C8AF9BN6PR11MB4081namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Adding to this Robert, indeed SRv6 defines many behaviors. The question as= ked about a single =91behavior=92 could really only be interpreted as askin= g about single =91solution=92, as you understood, since a single =91behavio= r=92 in SRv6 is non-sensical. The requirements draft section 4.2 alone req= uires multiple behaviors be supported, and multiple compression levels in 4= .4.4. Darren On 2021-10-05, 4:24 PM, "spring" wrote: Ron & SPRING WG chairs, Through this discussion we first have seen a debate if we need one or more = data planes to compress SIDs in SRv6. WG clearly stated we need one. Following that we have observed a first terminology shift to see if asking = how many solutions should be supported will work any better. To that many W= G members clearly stated that they support one solution. Well please notice that the draft in question in its introduction states: Abstract This document defines a compressed SRv6 Segment List Encoding in the Segment Routing Header (SRH). This solution does not require any SRH data plane change nor any SRv6 control plane change. This solution leverages the SRv6 Network Programming model. So based on my understanding of English the entire draft talks about a sing= le solution. Then suddenly a new question popped up: how many behaviours are acceptable. I bet number of folks including myself said "one" keeping in mind previous = discussions and the definition of "one" meaning based on the SRv6 data plan= e in compliance to [RFC8402], [RFC8754] and [RFC8986]. Interestingly enough the draft in question defines not behaviours but flavo= rs as new variants of the already defined behaviors in Standards Track RFCs= . Namely it defines: 4.1. NEXT-C-SID Flavor 4.2. REPLACE-C-SID Flavor The newly defined behaviour End.XPS is optional. So if there is anything to ask here is to check if WG is ok with two flavor= s or not. I do not recall that question has ever been asked formally during= the WG adoption call. With that let's note that optimal compressed SID size may be different netw= ork to network. One size does not fit all. Draft says: 6.1. C-SID Length The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A C-SID length of 16-bit is recommended. The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths. A C-SID length of 32-bit is recommended. While I personally think 8-bit should be an option, if we choose a single f= lavor we will introduce suboptimality for no good reason. Hardware capable = of supporting any flavor clearly can do LPM on locator. Also hardware capab= le of supporting one flavor can support few other flavors as this is pretty= much just an offset game. Kind regards, Robert On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica > wrote: Pablo, Ae you sure? Please look at the question as Joel asked it ( https://mailarc= hive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ ). = Ron --_000_BN6PR11MB4081F3002B6C0D37508FA624C8AF9BN6PR11MB4081namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Adding to this Robert, indeed S= Rv6 defines many behaviors.  The question asked about a single =91beha= vior=92 could really only be interpreted as asking about single =91solution= =92, as you understood, since a single =91behavior=92 in SRv6 is non-sensical.  The requirements draft section 4.2 alone re= quires multiple behaviors be supported, and multiple compression levels in = 4.4.4.

 

Darren

 

On 2021-10-05, 4:24 PM,= "spring" <spring-bounces@ietf.org> wrote:

 

Ron & SPRING WG cha= irs,

 

Through this discussion= we first have seen a debate if we need one or more data planes to com= press SIDs in SRv6. WG clearly stated we need one. 

 

Following that we have = observed a first terminology shift to see if asking how many solutions shou= ld be supported will work any better. To that many WG members clearly state= d that they support one solution. 

 

Well please notice that= the draft in question in its introduction states: 

 

Abstract

   This document defines a compressed SRv6 Segment List Encoding = in the
   Segment Routing Header (SRH).  This solution does = not require any SRH
   data plane change nor any SRv6 control plane change.  = This solution
   leverages the SRv6 Network Programming model.

 

So based on my understa= nding of English the entire draft talks about a single solution. =

 

Then suddenly a new que= stion popped up: how many behaviours are acceptable. <= /p>

 

I bet number of folks i= ncluding myself said "one" keeping in mind previous discussions a= nd the definition of "one" meaning based on the SRv6 data plane i= n compliance to [RFC8402], [RFC8754] and [RFC8986].

 

Interestingly enough th= e draft in question defines not behaviours but flavors as new variants of t= he already defined behaviors in Standards Track RFCs. Namely it defines:&nb= sp;

 

4.1.  NEXT-C-SID F= lavor

4.2.  REPLACE-C-SI= D Flavor

 

The newly defined behav= iour End.XPS is optional. 

So if there is anything to ask here is to check if WG is ok with two flavor= s or not. I do not recall that question has ever been asked formally d= uring the WG adoption call. 

 

With that let's note th= at optimal compressed SID size may be different network to network. One siz= e does not fit all. Draft says: 

6.1.  C-SID Length

   The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengt= hs.  A
   C-SID length of 16-bit is recommended.

   The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID le= ngths.
   A C-SID length of 32-bit is recommended.

 

While I personally thin= k 8-bit should be an option, if we choose a single flavor we will introduce= suboptimality for no good reason. Hardware capable of supporting any = flavor clearly can do LPM on locator. Also hardware capable of supporting one flavor can support few other flavors as= this is pretty much just an offset game. 

 

Kind regards,

Robert

 

 

 

On Tue, Oct 5, 2021 at = 9:43 PM Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org> wrote:

Pablo,

 

Ae you sure? Please look at= the question as Joel asked it ( https://mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JA= bUCT1I/ ).

 

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

--_000_BN6PR11MB4081F3002B6C0D37508FA624C8AF9BN6PR11MB4081namp_-- From nobody Tue Oct 5 21:30:28 2021 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 ADEE13A0D3E; Tue, 5 Oct 2021 21:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 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, 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=Y9GaLLWa; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=hWM2QczQ 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 8krnL5rQHeQQ; Tue, 5 Oct 2021 21:30:18 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD80D3A0D2A; Tue, 5 Oct 2021 21:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14476; q=dns/txt; s=iport; t=1633494617; x=1634704217; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/hsBLff31yh8atWq0UYEv2pK+2T7EdsfqJdAgmEXf6M=; b=Y9GaLLWaRYjiUivasXfmk59pckyAHrr1q1pF0XjY1013NAYXm+UqQYLR PMJLcvGR1p/re5at9T65bPmuez/TuRyJJhhrW8jYG9UDY8yzSh2yn4zoV vmLbPB3pxnlZK32lfPbIwcvkBBSSMT1l6gWKw/si88wmXAZhrv6zyXaqU A=; IronPort-PHdr: =?us-ascii?q?A9a23=3AJQ7E5BM/30J2IpAYHxsl6nfhWUAX0o4cdiYb9?= =?us-ascii?q?4Y6kb9Rf6Xl9JPnbwTT5vRo2VnOW4iTq/dJkPHfvK2oX2scqY2Av3YPfN0pN?= =?us-ascii?q?VcFhMwakhZmDJuDDkv2f/D3czEgEdtPVRlu+HToeURQEdz1MlvVpHD65DUOG?= =?us-ascii?q?xL5YAxyIOm9GoPbg8mtke6o/JiGaARTjz37arR3f32L?= IronPort-Data: =?us-ascii?q?A9a23=3AuQPo4qAXlZS4rBVW//zhw5YqxClBgxIJ4kV8j?= =?us-ascii?q?S/XYbTApDMg3zQHmGoYDD2BOPfYY2v9KtF+bIqy8xtQvsOBx9M2OVdlrnsFo?= =?us-ascii?q?1CmBibm6XV1Fqp7Vs+rBpWroHlPsoNON7EsEOhuFiWF/0/1b+C6xZVB/fjgq?= =?us-ascii?q?oTUWbas1h9ZHWeIeA954f5Ss7ZRbrxA2LBVMCvV0T/GmPAzDXf+s9JC3s343?= =?us-ascii?q?IrYwP9nlKyaVDr1JTXSb9gT1LPVvyF94J7yuciMw3XErol8RoZWRs7Zx72/u?= =?us-ascii?q?2je5RpoU4njmbfgeUpMSbnXVeSMoiMJAO753V4T/WprjvZT2Pk0MS+7jx2Fk?= =?us-ascii?q?81yxc5lvp2rQgBvNarJ8AgYe0gETnolZPEcotcrJlD666R/1XbuaGP2wvNhS?= =?us-ascii?q?Uo2NIwC4c52DH1As/sCJ1gldQiZhuS56LO2Vucqgd4sROHpNYYSoTdmiz7ED?= =?us-ascii?q?P0mSIrPa6vX+cJC0Sg9h4ZFGvO2WiazQVKDdzzaaBFJf1wQEp97xb3ujXjke?= =?us-ascii?q?Doeo1WQzZfbKlP7lGRZuIUB+vKJEjBSefhoow=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AzQb/BKq5DKgDsNuV6HD67WUaV5uJL9V00z?= =?us-ascii?q?EX/kB9WHVpm5Oj9vxGzc506farslkssSkb6K+90KnpewK6yXcH2/huAV7CZn?= =?us-ascii?q?imhILMFuFfBOTZskbd8kHFh4tgPOJbAtRD4b7LfBhHZKTBkXOF+r8bqbHtms?= =?us-ascii?q?3F9ISurUuFDzsaFp2IhD0JbDpzZ3cGPDWucqBJbaZ0iPA3wwaISDAyVICWF3?= =?us-ascii?q?MFV+/Mq5ngj5T9eyMLABYh9U2nkS6owKSSKWna4j4uFxd0hZsy+2nMlAL0oo?= =?us-ascii?q?+5teug9xPa32jPq7xLhdrazMdZDsDksLlWFtyssHfsWG1SYczEgNkHmpDo1L?= =?us-ascii?q?/sqqiUn/4UBbU215oWRBDsnfKi4Xi67N9k0Q6S9bbRuwqSnSW+fkNhNyKE7r?= =?us-ascii?q?gpLicwLCEbzYxBOetwrhGknosSAhXakCvn4d/UExlsi0qvuHIn1fUelnpFTO?= =?us-ascii?q?IlGfJsRKEkjQho+a07bWjHAUEcYZ5TJdCZ4OwTfUKRbnjfsGUqyNuwXm4rFh?= =?us-ascii?q?PDRkQZoMSa3zVfgXg8liIjtYMit2ZF8Ih4R4hP5uzCPKgtnLZSTtUOZaY4AO?= =?us-ascii?q?saW8O4BmHEXBqJOmOPJlbsEr0BJhv22tLKyaRw4PvvdI0DzZM0lpiEWFREtX?= =?us-ascii?q?Qqc0arEsGK1I0jyGGEfIx8Z0Wl9ih63ek2hlTRfsufDcSzciFZryL7mYRsPi?= =?us-ascii?q?TyYYfGBK5r?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BqCgB/JV1h/5RdJa1agQmBWYEhMCM?= =?us-ascii?q?uB3daNzGIDwOFOYgIlWmFBoFCgREDVAsBAQENAQE3CgQBAYR9AoJEAiU3Bg4?= =?us-ascii?q?BAgQBAQESAQEFAQEBAgEGBIERE4U7CCUNhkMCAQMSCxATAQEsBQYBDwIBCDU?= =?us-ascii?q?GCzIlAQEEAQ0FCBMHglCBflcDLwEOpC0BgToCih94gTOBAYIIAQEGBASBSkG?= =?us-ascii?q?CfxiCNQMGgTqDAIQThnInHIFJRIEVQ4JnPoJjAgOBIwUBEgEjK4Miggwiiiw?= =?us-ascii?q?vQhdNBBsoDAQgAlkWgQICKBEpkX6MBo1LkioKgzCKRJQ9FINni2qXPIcTjxK?= =?us-ascii?q?MSZQQhGICBAIEBQIOAQEGgXclaXBwFTuCaVEZD1iCZopuFhUZgyKFFIVKdDg?= =?us-ascii?q?CBgsBAQMJlXEBAQ?= X-IronPort-AV: E=Sophos;i="5.85,350,1624320000"; d="scan'208,217";a="945331422" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Oct 2021 04:30:13 +0000 Received: from mail.cisco.com (xbe-aln-002.cisco.com [173.36.7.17]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 1964U5TV016811 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 6 Oct 2021 04:30:13 GMT Received: from xfe-rtp-003.cisco.com (64.101.210.233) by xbe-aln-002.cisco.com (173.36.7.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 5 Oct 2021 23:30:10 -0500 Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xfe-rtp-003.cisco.com (64.101.210.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 6 Oct 2021 00:30:10 -0400 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Wed, 6 Oct 2021 00:30:09 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PFO+Gr4+Kw8gBdPSaMJy8cSNYri29bpvwa9hht27v7l5qdIbpUxhYxse15hXr8skms5pNzLmqkiCUONwJwclIgNGOfVjZ7TbDi9a7LGofacYF1EUyG6yUVPGjgXVYWWFC5dcsQQ4G2mly9yQvhgeDYggdUeGyHUdwOmWxuI8ZZaGkiif7uUny5gtnKVHUstwCc0r+oBmszXDCrK0RRkvAec5aFiIvHNmCDyX/2OlehFzDoBpYOmHMclRdeijjBfLoPYV+H90PIZZK67eZfufbx5rr5+iQLVtaHvokztp6C4FSa5utZDgkzKnTcOPcjFpWJBiL2PwhkN+R6vjIzCo4A== 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=+6TU6pGgBzNPwxo/Hk0R0xO+0sc8yNBoCl718dJaxZY=; b=U9qbD/H4J/6k+8VIV50VjS8zp3RYpTpp2sGqTo1vjO8aNh2uQHnRXOdmsqOSF3Tq6whE9mQ75g0uALNdjKELcN1IcPY6zutfUQAMNhcgUDQXOrUzaAkRBCw/LilgUicC5wnkitAEcn1K0ibQBy+DbKU7LCImwF4FWzN3I/9qFJMuvkzDKHzYWXpJ4vvHlY4WxOkBdZ1al5A7sHJJ3FHn99ZDHG+0FYJeJSzLBEwcRJ4roKF3TX6vo5HUwakDHgOZsSG19yAn3A6RhCDH5tA4lj7ksaRuQpRUeKCRmnuD4ZIJGbHYJ2uhz6lipLl4O3fWRa4ZXuSghul++IWGHd7hvg== 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=+6TU6pGgBzNPwxo/Hk0R0xO+0sc8yNBoCl718dJaxZY=; b=hWM2QczQBnP6zPUQ7INMTPGkFBHbbCo2rTLNKMf1cqrWuF26aj55MHwGYWFyoNYSoJjMKEVDxEKlQL/eWK/EZDf0xcpfFkm33ASsO7KU3gf3KWBui3bKggovjwAd8OIW4QS0CC0vThZT2gtQZTdKYsfcv4KcuerkJYUcuXghktw= Received: from BN6PR11MB4081.namprd11.prod.outlook.com (2603:10b6:405:78::38) by BN6PR11MB4052.namprd11.prod.outlook.com (2603:10b6:405:7a::37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.16; Wed, 6 Oct 2021 04:30:04 +0000 Received: from BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::547a:c1c1:ef01:f46e]) by BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::547a:c1c1:ef01:f46e%3]) with mapi id 15.20.4566.022; Wed, 6 Oct 2021 04:30:04 +0000 From: "Darren Dukes (ddukes)" To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQDGDN5C Date: Wed, 6 Oct 2021 04:30:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 12c81839-0946-4964-213b-08d98881f813 x-ms-traffictypediagnostic: BN6PR11MB4052: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ILS5M6sqcBdVoAsffGbpGI1uabFyvswG8hOEWZGXQLp6gvG2X3reWNrXHwIW2I/x6MgadVifrFnnqaP+Xw/qmeDSxidwIb03mog2MSh+qcpPnBOdM0KqzSKF02kDyUX0ogAJJnKIvDnUXT0C/GRBtmF557t0vVIFy0MWU/+CVaf5ZjuFujO8DXi+2/UG29i/fdx0DxQYHKxT1SLa4Kk2HILAQwFJCSsZ6z+7LNFir1WqeVVgF6IU8gp+nn4qrDS/P/KmqslD/ImdjeZSNszYsn3Dy10Z0RVEgiWJdZdTTMDgwphLA1Lxxm6QTBuliPj7RV4YayshnTe2NgudBYqpNcZzF9Y2t6438Jkx2vd973Z+Lpqj3RzE6G/bPcAAyN2gkNgfbN5LWQz7+zqkZJY+jAmFMMjnN+UgnRIDIbr97Fi6FXXOkN63RwxH4kP3xVtUKz04VDtd9fnXk3LRA/0MRNvzQ95BAfHZLDm3K8jw/zTXWTz3hyxo8GkljXeNb04OmlCst8fGUirL5+gkPNmTr8iyg7o1YpY3jhzW09T76q7g++OnfOIOjpqPbVTFw+H83Tyu37Jg7fJp93+SrYQPuDxda/8qSxQRDJw8HRimnNwTmjptNHrYgrU34iEFI94wxiwritzNPRi64K2u0uRKcGo3nxJ9xLCcAkamSGZuVIbWFACIb85+Thv+WK0bG72z6tjwgwXaSsNPSNnLpXuCndjNE8/zs8Fy8ijiWBxIPCT0Gjs6EAYmEWNkmTvbucZ4EIKAkKNtJGeM8eKvPA6uHLT80mLr/0jkq/F7U674Law= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB4081.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(7696005)(8676002)(122000001)(52536014)(6506007)(53546011)(8936002)(33656002)(2906002)(110136005)(5660300002)(38100700002)(316002)(4326008)(186003)(26005)(76116006)(91956017)(9686003)(55016002)(66946007)(66446008)(64756008)(66556008)(66476007)(38070700005)(83380400001)(71200400001)(166002)(86362001)(966005)(508600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?c15k7cTk+dHPmUDmU0m9HkXjJkFZGyC9fNPGSogXQzrY4oPtx0216/bx?= =?Windows-1252?Q?aLjcuC7TcWNJklugYLLobUdrEW3o/fH4Fj0vjym91cyhA17kTlczzEsa?= =?Windows-1252?Q?kCrQq7t9pvagnM/oamQ4bpOyxPnfwhtrl226CPxSq4noOpWyShAYzEk0?= =?Windows-1252?Q?X/IfVvDCGgtOBIIVw9iO80EiDhLsQFEYhV/7tdDcb/kQWVVqF+vHNRJU?= =?Windows-1252?Q?vsaeLKMU2quOyAeilapV7im9GRWgw8M8ZLJLg7xMoJ/JdAea5OmUuzYY?= =?Windows-1252?Q?7ceHGgt4chQrUNTMYUhANQknqIFsSY54jm6rlXeVpoZpCJEB6UmkLL0J?= =?Windows-1252?Q?x/VBK+VQ++8HDj9BVwX2hBYpzPhYRTqhA9LvzfVpg3/ubfLPZ2E8vnU9?= =?Windows-1252?Q?Ktqt71KP2cn2X7it4p+zdNWQABXA1+Dn+twLevljyRYdwrq4dciODXCK?= =?Windows-1252?Q?2qz3CtEbKlkUt+NQXIwll1Y746nBICtFP+0S1juScEDUtzsTOAG+6Eif?= =?Windows-1252?Q?wGE0VX3Dkxkth5RusoBIYREnG8Z5HStUuOIbRi5yTg8ZfzAbqb+J62Nn?= =?Windows-1252?Q?7R8sVfNrNBFGZ44/y5waJUwx/EE5hlILzTKbZzJPAuzzpMUdfisQd3ar?= =?Windows-1252?Q?KXRIZ7DPio4rPsORC1nHsIbXFy+9xAyNbk393bfoAoxfa9adrAq9YVra?= =?Windows-1252?Q?rohDUttbK0RR1EkfAPC/YYjaUDxy2I8TaOVyMd+HtcEi2yHQJ07iJ9EN?= =?Windows-1252?Q?3n2Ly82t3j437xMxrPXJtqg8KgGPz3u90Ky4Ui3EZruwu7tjbRWTE0r2?= =?Windows-1252?Q?0t+P1HPPFBvR1ZyyT3K7FvSodsbszrBre0CAsaTW/7oxuPXVP1tmQf/U?= =?Windows-1252?Q?SR++WnkHao3JTZRnliyx7uNAkdpm5xZ/6/8zqzUpW3hZay0yaGxHWW/Q?= =?Windows-1252?Q?/VECqNZ12OJo3kCMun94dWnderYQiK2SZNfZEE0Bcf/PwG9do802R5XG?= =?Windows-1252?Q?fmiKD4REVkuPp52NnqkvsdJZ9ijS+5tAuN5y3FPIlDvreFw/iFqJDl5N?= =?Windows-1252?Q?pmsyG8WZdDfHL8NGA+4JxaPRWK6jwh1Xvf8H+PxZRrVlGRnFJVKVaIEG?= =?Windows-1252?Q?vqohVVWJnFqeJgXReKGj3UQIAfWQkBI7GTRK8At0CSSDNyHpWRDfkH+i?= =?Windows-1252?Q?ax8AFoD7+BzCS+SZMJn/n5P7Ia6ETPK04OMuW8X/FQxAjOlCFnvW8BP5?= =?Windows-1252?Q?LbyTZ87ySYCDmrWdXoEKSIPP0Jz/9nyECic+FVHVfT0IeCeQJIfG0bsh?= =?Windows-1252?Q?CMJGMtXDSI7F0MGs9xrHYV1svCK/fRw/2wUeVC8b8ro6YFWqD8YrIy7F?= =?Windows-1252?Q?eky51ZR3BV9175X8AVXmIYyJhKfyQn56F2ThwjRnZeSoEn7/iVaaezd9?= =?Windows-1252?Q?KaxyKE/pd7VpH22x7dMP3g=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN6PR11MB408146A7FE3F4C4ED9B8ED25C8AF9BN6PR11MB4081namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN6PR11MB4081.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 12c81839-0946-4964-213b-08d98881f813 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2021 04:30:04.2288 (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: ZCac9nKtCYAHMzIeeDKh0rzdseIi0Beyyq+4e041SjtjX8BIeD5ri8UvzNUZxs/ONGXJ6ochLRZkbgjxNesljA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB4052 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.17, xbe-aln-002.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 06 Oct 2021 04:30:25 -0000 --_000_BN6PR11MB408146A7FE3F4C4ED9B8ED25C8AF9BN6PR11MB4081namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I support the WG adoption of this draft. I=92ve spent a year and a half with the design team studying requirements a= nd analyzing all solutions to SRv6 SID list compression with multiple WG re= views and many hours of work. The CSID proposal is the strongest, and full= y based on the SRv6 data plane. Combined with the breadth of contributors, implementations and deployments = it makes a very good solution for the working group to adopt and progress. = I am certain there will be no shortage of interest nor energy to complete = it. Sincerely Darren On 2021-10-01, 10:05 AM, "spring" wrote: Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple = SRv6 Endpoint behaviors. 2. The document is a =93living=94 document; it may change as it goes = through review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be addr= essed BEFORE said document is allowed to progress from the working group to= publication. A list of these discussion points will be documented in the W= G document and maintained by the document editor in conjunction with the ch= airs. 4. If this document is adopted by the working group, the chairs speci= fy as part of the adoption call that the following text describing an open = issue be added to the document in the above-described open issues section: =B7 "Given that the working group has said that it wants to standar= dize one data plane solution, and given that the document contains multiple= SRv6 EndPoint behaviors that some WG members have stated are multiple data= plane solutions, the working group will address whether this is valid and = coherent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_BN6PR11MB408146A7FE3F4C4ED9B8ED25C8AF9BN6PR11MB4081namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

I support the WG adoption of th= is draft.

 

I=92ve spent a year and a half = with the design team studying requirements and analyzing all solutions to S= Rv6 SID list compression with multiple WG reviews and many hours of work.&n= bsp; The CSID proposal is the strongest, and fully based on the SRv6 data plane.

 

Combined with the breadth of co= ntributors, implementations and deployments it makes a very good solution f= or the working group to adopt and progress.  I am certain there will b= e no shortage of interest nor energy to complete it.

 

Sincerely

  Darren

 

 

On 2021-10-01, 10:05 AM= , "spring" <spring-bounces@ietf.org> wrote:

 

De= ar WG:

 

Th= e chairs would like to express their appreciation for all the responses rec= eived to our emails with reference to how the working group wishes to move = forward with respect to a solution for SRv6 compression.

 

Th= e apparent inclination of the working group is to use https://datatracker.ietf.org= /doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardization work. That is part of what this email attempts to confirm.=

 

Be= cause of the above the chairs would like to issue a 2-week WG call for adop= tion ending October 15th for https://datatracker.ietf.org= /doc/draft-filsfilscheng-spring-srv6-srh-compression/ but with some clear guidelines as follows. By expressing support for adoption of this document you are fu= lly aware of and are acknowledging that:

 

1= .   &= nbsp;   The SPRING working grou= p is adopting a document that has multiple SRv6 Endpoint behaviors.

2= .   &= nbsp;   The document is a =93li= ving=94 document; it may change as it goes through review and analysis by t= he SPRING working group.

3= .   &= nbsp;   All open discussion poi= nts raised on our mailing list MUST be addressed BEFORE said document is al= lowed to progress from the working group to publication. A list of these di= scussion points will be documented in the WG document and maintained by the document editor in conjunction wi= th the chairs.

4= .   &= nbsp;   If this document is ado= pted by the working group, the chairs specify as part of the adoption call = that the following text describing an open issue be added to the document i= n the above-described open issues section:

=B7         "Given that the wo= rking group has said that it wants to standardize one data plane solution, = and given that the document contains multiple SRv6 EndPoint behaviors that = some WG members have stated are multiple data plane solutions, the working group will address whether this is valid= and coherent with its one data plane solution objective.".=

 

Pl= ease consider the above guidelines as you decide on whether to support or n= ot this WG adoption. Please express clearly your reasoning for support/non-= support as well as any open discussion points you would like addressed should the document be adopted into the wo= rking group.

 

Th= anks!

 

Ji= m, Bruno & Joel

 

 

--_000_BN6PR11MB408146A7FE3F4C4ED9B8ED25C8AF9BN6PR11MB4081namp_-- From nobody Wed Oct 6 01:46:41 2021 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 1E1263A183A for ; Wed, 6 Oct 2021 01:46:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uniroma1.it 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 w3XY1PrvAkt0 for ; Wed, 6 Oct 2021 01:46:34 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 49C123A1837 for ; Wed, 6 Oct 2021 01:46:32 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id 134so1922090iou.12 for ; Wed, 06 Oct 2021 01:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniroma1.it; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KKwLrYgM38xXn4CT6JnfWY9u7eBN7XUfJWXyewpdhlM=; b=n6e/Fs+VY/dttXpvgSc5I1ZBTS9UBNXlkDD131iHA7PlDFQsXmDIZeUkj/19JHI4Zm S/1rtKxSEDKNp+gqlub8hFqO6v8nFG5s4ME2g55cQpetw2L971EA6Rmc8rzmeyMhp3SP Z3PqOI060RjS2dfLOS/6gMldpDUVEgiB8pk06JCm200E2ORPuaZOAhtUlyHDNWuHP3Al Sw6in4CKcL5TkQq1T6HRUFVYmoYjmPNvQ71HR31R2+KcbJ2orzVzVeafVh8T7qCTHihF lrN3HJHH0HGEZERYnRcUne5jAhhRkaBlUb3nH7l4CeprnfTgLblL63l4b5MH2l5Un0sZ WszQ== 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=KKwLrYgM38xXn4CT6JnfWY9u7eBN7XUfJWXyewpdhlM=; b=WGoctOxAdjQ1rgp5JRsAS+HyBcIDeVYSIwMTvRFvMBIEmwDQEiUzwVwWWsS0S6fLSp ZMp1bTso9fTJt86SL/R8dkVe/W1SqEL/Ol1CQJVE3at9CCjSWaKWLOHFr9hUSVEinVRa 4RfuUBhIjAKkA0mQFCkfHPj/Dtmd6E32LNlifvDBfsD6iMUch7bByEXKtVW3a41x86kQ RGy8SKqhauqSkcmjrW2PmyAYnozlGvMNivSjbiOGKVkOJCxo6yduIPzi3iScg8AYjK/J OPYKiMJXCqDcFEFTCzjhvfTsNevNZJP7+woOQIKnaTArqGFAtYTJFqVPxUJ+NIUCL1IL 6vVQ== X-Gm-Message-State: AOAM5330R5X5mXM4QkvKYnPm5MAqKmy3gP3nW+ixnmQ6I/q4SghPR+6e sDJV5Nasm6M1+aXXjDy0921XW11f7IAUk2qPGuJW9n22/uQU2boNznpvGPu1LA6+RYTEsylY6ps 8TTuHKe5LcvOgTMTt X-Google-Smtp-Source: ABdhPJxKS/lbSYzN+h6jiFkPEBerE6KHMdhbJMsRFThaHid+fm/WwujFPxFZRVWqnKoGFCIA3mJWeTJv3+nf1azj9V8= X-Received: by 2002:a6b:f915:: with SMTP id j21mr5557586iog.98.1633509991845; Wed, 06 Oct 2021 01:46:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Antonio Cianfrani Date: Wed, 6 Oct 2021 10:47:16 +0200 Message-ID: To: "Darren Dukes (ddukes)" Cc: James Guichard , SPRING WG , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cd254505cdab2efe" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 06 Oct 2021 08:46:40 -0000 --000000000000cd254505cdab2efe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support the WG adoption of the CSID draft. I understand that CSID draft defines multiple SRv6 behaviors, but they are based on a single SRv6 data plane solution. Kind regards, Antonio Cianfrani Il giorno mer 6 ott 2021 alle ore 06:30 Darren Dukes (ddukes) ha scritto: > I support the WG adoption of this draft. > > > > I=E2=80=99ve spent a year and a half with the design team studying requir= ements > and analyzing all solutions to SRv6 SID list compression with multiple WG > reviews and many hours of work. The CSID proposal is the strongest, and > fully based on the SRv6 data plane. > > > > Combined with the breadth of contributors, implementations and deployment= s > it makes a very good solution for the working group to adopt and progress= . > I am certain there will be no shortage of interest nor energy to complete > it. > > > > Sincerely > > Darren > > > > > > On 2021-10-01, 10:05 AM, "spring" wrote: > > > > Dear WG: > > > > The chairs would like to express their appreciation for all the responses > received to our emails with reference to how the working group wishes to > move forward with respect to a solution for SRv6 compression. > > > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > as the basis for its compression standardization work. That is part of wh= at > this email attempts to confirm. > > > > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging > that: > > > > 1. The SPRING working group is adopting a document that has > multiple SRv6 Endpoint behaviors. > > 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may chan= ge as it goes > through review and analysis by the SPRING working group. > > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the working > group to publication. A list of these discussion points will be documente= d > in the WG document and maintained by the document editor in conjunction > with the chairs. > > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text describing a= n > open issue be added to the document in the above-described open issues > section: > > =C2=B7 "Given that the working group has said that it wants to > standardize one data plane solution, and given that the document contains > multiple SRv6 EndPoint behaviors that some WG members have stated are > multiple data plane solutions, the working group will address whether thi= s > is valid and coherent with its one data plane solution objective.". > > > > Please consider the above guidelines as you decide on whether to support > or not this WG adoption. Please express clearly your reasoning for > support/non-support as well as any open discussion points you would like > addressed should the document be adopted into the working group. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --=20 ________________________________________________________ Le informazioni=20 contenute in questo messaggio di posta elettronica sono strettamente=20 riservate e indirizzate esclusivamente al destinatario. Si prega di non=20 leggere, fare copia, inoltrare a terzi o conservare tale messaggio se non= =20 si =C3=A8 il legittimo destinatario dello stesso. Qualora tale messaggio si= a=20 stato ricevuto per errore, si prega di restituirlo al mittente e di=20 cancellarlo permanentemente dal proprio computer. The information contained=20 in this e mail message is strictly confidential and intended for the use of= =20 the addressee only.=C2=A0 If you are not the intended recipient, please do = not=20 read, copy, forward or store it on your computer. If you have received the= =20 message in error, please forward it back to the sender and delete it=20 permanently from your computer system. --=20 Fai crescere i nostri giovani ricercatori dona il=C2=A05=C2=A0per=C2=A0mille=C2=A0alla=20 Sapienza *codice=C2=A0fiscale=C2=A080209930587* --000000000000cd254505cdab2efe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support the WG adoption of the CSID draft.
I underst= and that CSID draft defines multiple SRv6 behaviors, but they are based on = a single SRv6 data plane solution.
Kind regards,
Antoni= o Cianfrani

Il giorno mer 6 ott 2021 alle ore 06:30 Darren Dukes (dduk= es) <ddukes=3D40cisco.com@= dmarc.ietf.org> ha scritto:

I support the WG adoption of th= is draft.

=C2=A0

I=E2=80=99ve spent a year and a= half with the design team studying requirements and analyzing all solution= s to SRv6 SID list compression with multiple WG reviews and many hours of w= ork.=C2=A0 The CSID proposal is the strongest, and fully based on the SRv6 data plane.

=C2=A0

Combined with the breadth of co= ntributors, implementations and deployments it makes a very good solution f= or the working group to adopt and progress.=C2=A0 I am certain there will b= e no shortage of interest nor energy to complete it.

=C2=A0

Sincerely<= /p>

=C2=A0 Darren

=C2=A0

=C2=A0

On 2021-10-01, 10:05 AM, = "spring" <spring-bounces@ietf.org> wrote:

=C2=A0

Dear= WG:

<= /u>=C2=A0

The = chairs would like to express their appreciation for all the responses recei= ved to our emails with reference to how the working group wishes to move fo= rward with respect to a solution for SRv6 compression.

<= /u>=C2=A0

The = apparent inclination of the working group is to use https://da= tatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardization work. That is part of what this email attempts to confirm.=

<= /u>=C2=A0

Beca= use of the above the chairs would like to issue a 2-week WG call for adopti= on ending October 15th for https://da= tatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ but with some clear guidelines as follows. By expressing support for adoption of this document you are fu= lly aware of and are acknowledging that:

<= /u>=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The SPRING working group i= s adopting a document that has multiple SRv6 Endpoint behaviors.

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 The document is a =E2=80= =9Cliving=E2=80=9D document; it may change as it goes through review and an= alysis by the SPRING working group.

3.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 All open discussion points= raised on our mailing list MUST be addressed BEFORE said document is allow= ed to progress from the working group to publication. A list of these discu= ssion points will be documented in the WG document and maintained by the document editor in conjunction wi= th the chairs.

4.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If this document is adopte= d by the working group, the chairs specify as part of the adoption call tha= t the following text describing an open issue be added to the document in t= he above-described open issues section:

=C2=B7=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 "Given that the worki= ng group has said that it wants to standardize one data plane solution, and= given that the document contains multiple SRv6 EndPoint behaviors that som= e WG members have stated are multiple data plane solutions, the working group will address whether this is valid= and coherent with its one data plane solution objective.".<= /u>

<= /u>=C2=A0

Plea= se consider the above guidelines as you decide on whether to support or not= this WG adoption. Please express clearly your reasoning for support/non-su= pport as well as any open discussion points you would like addressed should the document be adopted into the wo= rking group.

<= /u>=C2=A0

Than= ks!

<= /u>=C2=A0

Jim,= Bruno & Joel

<= /u>=C2=A0

<= /u>=C2=A0

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

_= _______________________________________________________<= /div>Le informazioni contenute i= n questo messaggio di posta elettronica sono strettamente riservate e indir= izzate esclusivamente al destinatario. Si prega di non leggere, fare copia,= inoltrare a terzi o conservare tale messaggio se non si =C3=A8 il legittim= o destinatario dello stesso. Qualora tale messaggio sia stato ricevuto per = errore, si prega di restituirlo al mittente e di cancellarlo permanentement= e dal proprio computer.
The information contained in this e mail message is strictly confident= ial and intended for the use of the addressee only.=C2=A0 If you are not th= e intended recipient, please do not read, copy, forward or store it on your= computer. If you have received the message in error, please forward it bac= k to the sender and delete it permanently from your computer system.=


Fai = crescere i nostri giovani ricercatori
dona il=C2=A05=C2=A0per=C2=A0mille= =C2=A0alla Sapienza
= codice=C2=A0fiscale=C2=A080209930587
--000000000000cd254505cdab2efe-- From nobody Wed Oct 6 01:49:40 2021 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 714143A1849; Wed, 6 Oct 2021 01:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=D3rBsHfe; dkim=pass (1024-bit key) header.d=juniper.net header.b=B661O1C+ 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 j8WFSL4a6kF9; Wed, 6 Oct 2021 01:49:35 -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 4881E3A1847; Wed, 6 Oct 2021 01:49:35 -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 SMTP id 196836Mc011688; Wed, 6 Oct 2021 01:49:29 -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=OuTYkgyNugED4mEdLRjjE37cbSvTn4CulYmK4qpqz7s=; b=D3rBsHfeGASHfFpOxk970xcZONFdwEpoAafiVYlsXe2wG/lRIqS7G+LFAW0PRYqNq2Fl 9J0sau0TUY5v6VyxrrQOBQV3C/Zz9zMRfBdgvbQGLD9n4h0UQEXljVH+/KkxC+eNgEa8 FF3/tu6dZk8+dB/WUTeQdjcbLEmSHYAL1jms+Q7BQwp+qYiftOIQvuhr7fH4YVraF/ME sbG0Bp6NcqT0d4faLWa7YbDK9RuJfpTBRbSHy+clza2vQ2oNEGt6jYUHnwuFznhKKCAv iTVQJ5U6p4Q3UlJIwS1Isl7NEWT/eJ4DQLhKKrK6eU4IfFD9p1n6lFIOXnNw2DU6+uZG vQ== Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2170.outbound.protection.outlook.com [104.47.57.170]) by mx0a-00273201.pphosted.com with ESMTP id 3bh7xu82xe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Oct 2021 01:49:29 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hO9u+jNPOtz05dLNwhxfEz9ssPtW8nBLnBFEtSAGfc/94QgDl6ygnnwrTTyOR90b1HdFgg4qeci2wHqsHH2g63EdWaq12mrcztUD5QjMJw3A4uQjTfmSU9cSL732JlbJFgs5vE/3pCRDp4sB8IxcVIHHk6jTWbjC24tA4csRIkl+U80Gn9k0coFY/bb8aYhFbwBdVUP4RZn0vjFQmclX8jCxLBPMc3gx3eTn1v6wxuobmR96R/EuVl9/u6GE9XMUeklPHSRs3N24Zd55cx85g+/NTothUOA9dzER817agXd6xqYR4xVB07bWQF7PsqiLQYwF5RjYjWqcPkjcTndOVA== 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=OuTYkgyNugED4mEdLRjjE37cbSvTn4CulYmK4qpqz7s=; b=bLSuj+2xlVS4oFgqcQFXdiQNp1c/EqKPby/QujQezpkkv/BIFLXxGvelU/wAzRJ8FrvDXRg/vvR0kadQaoPUTdh/YsWK3ffBsI0lQ6BP/kMdVJLwpxDCrfukQ6vxW6xVFdG425u56vqxDb9xL7TpPeomKuk7Jv7MRJY7cs3clyTK06M9vWxt7Zmck3zf6R5zW2/9uuKbHg4Ufb9gbnwAbuWTOZ/baXg8Wf1Yc2aysh1JS+rcXL0OL1KL72KyyTtaNVcRF3L71bzB3dPrDv3z932O6Kh8UfI6OLL7Ag5Iu1uDDDGWdLAh+aJHdrVj8e9R+e9L46FMsQtfIZeDrTPzsQ== 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=OuTYkgyNugED4mEdLRjjE37cbSvTn4CulYmK4qpqz7s=; b=B661O1C+CkDtcWlHJXhUrhO5ZvO0TDxBGld2FOUMHgxSPBbp4korDt+lBdYjUiY5o8Xs5ACvvwWqpGvYhlXJBFtuCFTUdzSbOOIhX96aLfXdcTB0/Ua0DhPh2yc2LnD+XPEHX1B34npwnLl88CC2FFyoBHWFpbez1k5VSlwVnVo= Received: from CO1PR05MB8314.namprd05.prod.outlook.com (2603:10b6:303:fd::13) by MWHPR0501MB3884.namprd05.prod.outlook.com (2603:10b6:301:7a::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.9; Wed, 6 Oct 2021 08:49:27 +0000 Received: from CO1PR05MB8314.namprd05.prod.outlook.com ([fe80::f198:80ee:bd42:cb69]) by CO1PR05MB8314.namprd05.prod.outlook.com ([fe80::f198:80ee:bd42:cb69%6]) with mapi id 15.20.4587.017; Wed, 6 Oct 2021 08:49:27 +0000 From: Shraddha Hegde To: Ron Bonica , James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQAH0rRwAOjyHYA= Date: Wed, 6 Oct 2021 08:49:26 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-06T08:49:24Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=fc97332a-b1f3-480d-b685-d69b122bdec4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9f701175-9af6-4547-d820-08d988a63420 x-ms-traffictypediagnostic: MWHPR0501MB3884: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZcpYPrOYqGBj5pScNEUjSaCPBr/yGn/69QyoBd2TS8C1BdR5GzvuJnefa84S/OWRdNd1Q7i/czLeuj1CUYe024p2h5vwFPDlqIGARooBtZZWY2HKfxhwktU1OXVIt/M4XdVOFWMH77lNLqtn/PY4TM+oioAPpYUnNPaDxqeSYDWBd2oOGf7xQ4swkayMc6M37H+Tk+ACJVOGTxGbOJhqFoy3IbLbzEjGDe1p8h8NP94pn6Nr1KaxyX8EUMpTDcJnAhu29ao0mzLN/+0A4a59Z9USjUY2Q1fiHKorWYIkmmgUih/jfFmmFDG0URuVcQouls/36bRADu/0YB38mhMbCCWBzGDgHePekysHYvATzZHACrXT7w1tMwCWseWTL4MUkHLVxcyPEGgtV3PXdkPWrXwxjnu3QYX2z3S8FcghLZ2Dtxv352YI5H2eLaKO8Jtuw1dpWozONJyXEyF48K9TQjEgZeDXosKc0WNLrPs9W61XoX1fEAEAGI2bNm2LH0lXbRTUOnhWZPQ+a1bBhrCZkLi0wwpc9eiHTHuaqizIxvYsH7Oxl1QyWQX6aWQeWwxBspTtaFKxTGD6EZeqcYFnFQWOm7UNsn1AOE9yVztz0DXzxtV69jpNmB5OU5Nmi8X332oyQU5nLhfP9T5fGtVGMZSm+SHG2T3+2T91OeUQpbfLRZkOr5gBxX+fvNdqFdqifj7D/cS0M0gWTR8RM8LZHJ92D/au9DDd6fbmeMz4tMKD/J5VwKM6KggBirtB05cgU7+L0wMY8xEZWzr3LItman4FkkS6dDlgUJP1INTyKec= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR05MB8314.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(4326008)(316002)(110136005)(508600001)(53546011)(6506007)(5660300002)(2906002)(26005)(86362001)(8936002)(186003)(966005)(52536014)(122000001)(38100700002)(55016002)(66446008)(76116006)(66476007)(66556008)(9686003)(33656002)(64756008)(7696005)(38070700005)(71200400001)(83380400001)(166002)(66946007)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?gh+EVRC8okwmHJ5GRUn2crNJp+tQ/3tSGyoLukAVmfxllba/BHGZzUQQWJ7u?= =?us-ascii?Q?czCTfI2F+mK6kEazRsd4LLHa/SoCgd1oHxscvJV19Eos9RGJPnN1fL5+4/Fp?= =?us-ascii?Q?WCI4K3PhFc3/VdYaHN/wgkMDjL6DEmP9ozRG6HdfehUOeO4Tn+8D19CPOBA0?= =?us-ascii?Q?x688NrBE595SPhcaAk7QmwmEoEcwi/7MYXPoA2c6dWrMo7ku+QmMTIllLq42?= =?us-ascii?Q?Z2E8XtD/y2KPlMi3hrCE89BfFVGHmruYM+yHIhWtIzbc5uOvOwStsbiE5IZc?= =?us-ascii?Q?pSkkos6JXR7RjsX/9KAS2Wb0fCpdwZ56PXdEObvvabLGH2ECC6pjg7glXA2y?= =?us-ascii?Q?bUgSUU7+zy8rEsN+LLej9HKSd/W9dijh5aRXkoA9bHEf7OAQ4iXT5YC81TG7?= =?us-ascii?Q?JsYhfWOvD1K/ZToWDdGCkGUaMWe1Hp5rfr2fJJU+AsgYOToLP+gq4ATuhYCc?= =?us-ascii?Q?vJT435a8XPmxoPP2UO4XacwVma3WokMImtpUqKcM4/9UYpEiSZoRcGphYjt+?= =?us-ascii?Q?+hqw5VFWaWkMROg8lAvr8+pjX5I5qyuRxqBKcD1c6SHsFUXaFp1jeZHVooxn?= =?us-ascii?Q?7a9mzxozv5M4nAQBkGq9sZq+Y3wkn54nRDz09uTUhAU6okPg7KETrPx308wK?= =?us-ascii?Q?dZ76MtZ1BLMFPFrnB6X6JqeXEA9L9GQqrpv+t0SRL7/xMONMxGVZcc9RUjaK?= =?us-ascii?Q?z1dyCHDltZJsSK16ZB2TR5siNdIRpGED7PlAyqY70CdaM4DCJQKAYxJ9Bo+G?= =?us-ascii?Q?TfQhbQtRgnO4giBYZSzaqw1bwk2d+j2XFflr+wN3d8qA8oFMmLGnVfWTfAYo?= =?us-ascii?Q?HWa13f10u3SqrWF483y/xjubQ7uyCr5NAjX558vt2GmnSPHDKbW2VaWiXh0k?= =?us-ascii?Q?l4H1CiiQZjuheL7LR/hRBSFG0xzdQ9y8OB6yYwOkn5iNIZ3m49WpVILk2IoH?= =?us-ascii?Q?s57HHCCygWN9MAY7rcY2mm3oTveWNMO1TOhrYJ4k8hjOIOuaDbZQlS6TkE9K?= =?us-ascii?Q?in0vkOtpcYUMwsm2JSprArjskKMOyG1FP0v/vrhdyFaVY0157xB4QsMd9TNv?= =?us-ascii?Q?0g9YSmw/K/mfcpELO32NuTYxPkMt4cAsHEsN1mJVkyOMY1frf8wIfdQIW0G+?= =?us-ascii?Q?e8fphg5Vwp/bx4VVd0cRzcXyNEMUBnsC8j/T32XxMJaAaYQU64nTj6U7xjPw?= =?us-ascii?Q?ZlFqjsBc2arQD065xGBdP+YqvOZd+fwEa+eRlAuRCyX/T4mOPb3vLhPi2bsx?= =?us-ascii?Q?gnHF0+OmQal8WwK5uCQoKaUWz9bNOiMW4uooL4PfvYCr06/LEloLMDY5R8ce?= =?us-ascii?Q?n5HLaWH0KX85s1oHrDLRyh6f?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO1PR05MB8314EF8C35AAD8B611ADD403D5B09CO1PR05MB8314namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR05MB8314.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9f701175-9af6-4547-d820-08d988a63420 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2021 08:49:26.8489 (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: 08AgIK/USC6eV0sYGUglct7X2Z3qLu7TLrtgKJQmcKdxzw3tXfVBjuDaVOr5lDAoMvO9d16+wYvM6/ykXcKPnQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR0501MB3884 X-Proofpoint-GUID: QxWKhU9c45MSEnA-2Sh4nPYc2MdiDUON X-Proofpoint-ORIG-GUID: QxWKhU9c45MSEnA-2Sh4nPYc2MdiDUON X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-05_06,2021-10-04_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 phishscore=0 impostorscore=0 malwarescore=0 mlxlogscore=999 adultscore=0 lowpriorityscore=0 mlxscore=0 spamscore=0 clxscore=1011 suspectscore=0 priorityscore=1501 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110060056 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 06 Oct 2021 08:49:40 -0000 --_000_CO1PR05MB8314EF8C35AAD8B611ADD403D5B09CO1PR05MB8314namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I strongly object to the adoption of the draft. There are 3 different flavors defined in the draft and all three flavors have significant difference in the forwarding plane behaviours. I would prefer the discussion on whether WG wants to work on all these flavors or only one of them to precede the adoption. Rgds Shraddha Juniper Business Use Only From: spring On Behalf Of Ron Bonica Sent: Friday, October 1, 2021 11:37 PM To: James Guichard ; SPRING WG Cc: spring-chairs@ietf.org Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ [External Email. Be cautious of content] Chairs, I strongly object to the adoption of this draft. I also note that this is a very strange adoption call. The WG has indicated= a preference for a single forwarding plane behavior. However, bullets #1 a= nd #4 in the Call for Adoption suggest that the WG has yet to address wheth= er the draft satisfies its single behavior objective. If the draft does not satisfy the single behavior objective, two of the thr= ee behaviors specified in the draft will need to be removed. This is a weak= starting point for a standards track RFC. Furthermore, neither this WG nor 6man has determined whether all three beha= viors are compliant with RFC 4291. It seems to me that one is while the oth= er two are not. Finally, I question the benefit of adopting this draft *before* the above m= entioned questions are answered. This is not a rhetorical question. A respo= nse from the chairs would be appreciated. = Ron Juniper Business Use Only From: spring > On B= ehalf Of James Guichard Sent: Friday, October 1, 2021 10:05 AM To: SPRING WG > Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ [External Email. Be cautious of content] Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardizat= ion work. That is part of what this email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as follows. By expressing support for a= doption of this document you are fully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_CO1PR05MB8314EF8C35AAD8B611ADD403D5B09CO1PR05MB8314namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I strongly object to the adoption of the draft.=

 

 

There are 3 different flavors defined in the draft <= o:p>

and all three flavors have significant difference in=

the forwarding plane behaviours.

 

I would prefer the discussion on whether WG wants to= work on

all these flavors or only one of them to =

precede the adoption.

 

Rgds

Shraddha

 

 

Juniper Business Use Only

From: spring <spring-bounces@ietf.org> = On Behalf Of Ron Bonica
Sent: Friday, October 1, 2021 11:37 PM
To: James Guichard <james.n.guichard@futurewei.com>; SPRING WG= <spring@ietf.org>
Cc: spring-chairs@ietf.org
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.= org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

 

<= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

 

Chairs,<= /span>

 

I strongly object t= o the adoption of this draft.

 

I also note that th= is is a very strange adoption call. The WG has indicated a preference for a= single forwarding plane behavior. However, bullets #1 and #4 in the Call f= or Adoption suggest that the WG has yet to address whether the draft satisfies its single behavior objective. =

 

If the draft does n= ot satisfy the single behavior objective, two of the three behaviors specif= ied in the draft will need to be removed. This is a weak starting point for= a standards track RFC.

 

Furthermore, neithe= r this WG nor 6man has determined whether all three behaviors are compliant= with RFC 4291. It seems to me that one is while the other two are not.

 

Finally, I question= the benefit of adopting this draft *before* the above mentioned que= stions are answered. This is not a rhetorical question. A response from the= chairs would be appreciated.

 

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;            &nb= sp;            =       Ron

 

 

 

Juniper Business Use Only

From: spring <spring-bounces@ietf.org> On Behalf Of James Guichard
Sent: Friday, October 1, 2021 10:05 AM
To: SPRING WG <spring@ietf.org= >
Cc: spring-chairs@ietf.org=
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/

 

<= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

 

Dear WG:

 

The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

 

The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors.
  2. The document is a “living” document; it m= ay change as it goes through review and analysis by the SPRING working grou= p.
  3. All open discussion points raised on our mailing list= MUST be addressed BEFORE said document is allowed to progress from the wor= king group to publication. A list of these discussion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
  4. If this document is adopted by the working group, the= chairs specify as part of the adoption call that the following text descri= bing an open issue be added to the document in the above-described open issues section:
    • "Given th= at the working group has said that it wants to standardize one data plane s= olution, and given that the document contains multiple SRv6 EndPoint behavi= ors that some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

 

Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

--_000_CO1PR05MB8314EF8C35AAD8B611ADD403D5B09CO1PR05MB8314namp_-- From nobody Wed Oct 6 07:05:41 2021 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 96A033A1C69; Wed, 6 Oct 2021 07:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=d5U9MmnB; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=MC5rrtlH 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 qnezualI7-m7; Wed, 6 Oct 2021 07:05:30 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32ADE3A1C6E; Wed, 6 Oct 2021 07:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18323; q=dns/txt; s=iport; t=1633529130; x=1634738730; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=or1LyEhMxaI6uvqwjGCA74IkT4fAMhGY9uBVnI4izks=; b=d5U9MmnBfk9lrWxPsVHnU4d7qCnNPDpkGA+pfmrhYLMn/1VNQ/rdpcOx 8w3BfaeP++HX2DCK2GScS6l675Djhd4/knHEdw6zULQtSZv5gWdCFR+9w U1WFGeEftOLyONlE6okpDkhzipzvJKY8tlwknb/9NKEEveQptRaM8YV79 Y=; IronPort-PHdr: =?us-ascii?q?A9a23=3ABKdmXxTzJhnCZZLm3xmURBKfrtpso6HLVj580?= =?us-ascii?q?XJvo71Le6WnuZ/lOR+X6fZsiQrPWoPWo7JBhvHNuq/tEWoH/d6asX8EfZANM?= =?us-ascii?q?n1NicgfkwE6RsLQD0r9Ia3laiU7GIJJU1o2t32+OFJeTcD5YVCaq3au7DkUT?= =?us-ascii?q?xP4Mwc9Jun8FoPIycqt0OXn8JzIaAIOjz24MttP?= IronPort-Data: =?us-ascii?q?A9a23=3AHB+nBKpDLQbh67pHG/f7e2OyALBeBmKDZxIvg?= =?us-ascii?q?KrLsJaIsI4StFCztgarIBnSPfaPa2enKt4jPYu0/R9U65TRzdE1HQE9ri4yE?= =?us-ascii?q?ihDouPIVI+TRqvS04x+DSFioHqKZKzyU/GYRCwPZiKa9krF3oTJ9yEmjPjQH?= =?us-ascii?q?uSkUYYoBwgoLeNaYHZ54f5cs7ZRbr5A2bBVMivV0T/Ai5S31GyNg1aYBlkpB?= =?us-ascii?q?5er83uDihhdVAQw5TTSbdgT1LPXeuJ84Jg3fcldJFOgKmVY83LTegrN8F251?= =?us-ascii?q?juxExYFENiplPPwdVcHB++UNgmVgX0QUK+n6vRAjnVtieBga7xNMgEO12jhc?= =?us-ascii?q?9NZkL2hsbS+QgMgMoXHmf8WVF9TFCQW0ahuqeScfCPi6pXDp6HBWz62qxl0N?= =?us-ascii?q?2ktJZcZ/OkyCmFH9OYDADEAch7FgPi5qJqgUvNtgMsLLcT3MsUYoH4I5TPQC?= =?us-ascii?q?Ps9B5aFTLjL7t9RxjsYiN1SAOzTeMcYLzFoaXzoeRdIPFYcAcdixOW1gHjnf?= =?us-ascii?q?icerl+JjaYy6nLYig18zLarN8DaEvSQQs9YhFqwvGvd7Xn6RBcXKLS3xiCI/?= =?us-ascii?q?XOph/XUnjLTV4cbFbn+/flv6GB/bER75AY+T1C3p7yyjVSzHoMZIE0P8S1op?= =?us-ascii?q?q83nHFHh+LVB3WQyENodDZFBbK8y9EH1Tw=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AC+hEka3Z6xoMYMSQrs5y3wqjBRByeYIsim?= =?us-ascii?q?QD101hICG9Lfb4qyn+ppomPEHP5wr5AEtQ5uxpOMG7MBThHO1OkPcs1NaZLU?= =?us-ascii?q?jbUQ6TTL2KgrGSuAEIdxeOk9K1kJ0QD5SWa+eATWSS7/yKmjVQeuxIqLLsnc?= =?us-ascii?q?zY5pa9854ud3AWV0gK1XYeNu/vKDwPeOAwP+tBKHPz3LsimxOQPVAsKuirDH?= =?us-ascii?q?gMWObO4/fRkoj9XBIADxk7rCGTkDKB8tfBYlul9yZbdwkK7aYp8GDDnQC8zL?= =?us-ascii?q?6kqeuHxhjV0HKWx4hKmeHm1sBICKW3+4oow3TX+0OVjbZaKvq/VQMO0aeSAZ?= =?us-ascii?q?ER4YDxSiIbToBOArXqDzmISFXWqlLdOX0Vmg7fIBej8AveSIrCNWgH4w4rv/?= =?us-ascii?q?METvMfgHBQ4e2UmZg7rF6xpt5ZCwjNkz/64MWNXxZ2llCsqX5niuILiWdDOL?= =?us-ascii?q?FuJYO5gLZvt3+9Kq1wVh4SKbpXZ9VGHYXZ/rJbYFmaZ3fWsi1mx8GtRG06Gl?= =?us-ascii?q?ODTlIZssKY3jBKlDQhpnFoi/A3jzMF7tYwWpNE7+PLPuBhk6xPVNYfaeZ4CP?= =?us-ascii?q?0aScW6B2TRSVbHMX6UI17gCKYbUki956Lf8fEw/qWnaZYIxJw9lNDIV05Zr3?= =?us-ascii?q?c7fwb0BciHzPRwg1jwqaWGLH3QI+RlltZEU5HHNc/W2By4OSYTepGb0oci6+?= =?us-ascii?q?XgKoKOBK4=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BLAADIrF1h/5FdJa1aHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUUHAQELAYEgMFEHd1o3MYgOA4RZYIgJA4p0inKFBoEugSU?= =?us-ascii?q?DVAsBAQENAQEqAQwKBAEBhDhFAoJHAiU0CQ4BAgQBAQESAQEFAQEBAgEGBIE?= =?us-ascii?q?RE4VoDYZCAQEBAQMBARALIwEBLAsBDwIBCBEDAQIkBAchBgsUCQgCBAENBQg?= =?us-ascii?q?TB4JQgX5XAy8BDqMoAYE6AoofeIEzgQGCCAEBBgQEgTYBE0GCfw0LgjUDBoE?= =?us-ascii?q?6AYMAhBOCeIN9JxyBSUSBFAFDgWaBAT6CIUIBAQIBgV8eBgcJgxmCDCKKLHE?= =?us-ascii?q?CYgRDEC8sIApIEQsCGDo6ngWfD2cKgzCBMokTiBqFIn2GBRSDaUKLKpc9hxO?= =?us-ascii?q?PEoxKgz6QRYRzAgQCBAUCDgEBBoFhO4FZcBU7gjUBATJRGQ+IS4VVDBYVGYM?= =?us-ascii?q?ihRSFSnQCNgIGCwEBAwmVAgEB?= X-IronPort-AV: E=Sophos;i="5.85,350,1624320000"; d="scan'208,217";a="933535318" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Oct 2021 14:04:54 +0000 Received: from mail.cisco.com (xbe-rcd-001.cisco.com [173.37.102.16]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 196E4sDc013980 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 6 Oct 2021 14:04:54 GMT Received: from xfe-aln-001.cisco.com (173.37.135.121) by xbe-rcd-001.cisco.com (173.37.102.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 6 Oct 2021 09:04:54 -0500 Received: from xfe-aln-003.cisco.com (173.37.135.123) 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.792.15; Wed, 6 Oct 2021 09:04:53 -0500 Received: from NAM02-BN1-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Wed, 6 Oct 2021 09:04:53 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WIM1jnHYWcfVO5h5eQr4TA5ECv5Pm2gwbdn2P3Yl2ryeh/RtJJCqzM7jJQgmxSkyP9AjvB2D7mH8jV+G0unZHa9o/mc2Fup74IR+E5GMqTkpqXc+ePY+5A2Qs3i/QcwpNpEXZDzz68TA3sPsIxVdjuhlNJ82qiKKxPGp4k+5nraGneCOEmiaeWUHtDRNeGCmVnPt7SB/r+rzqX0b1g370noIiT2qIzOOii2tMse06CEq0XFP4PY+eSKKDDMqvB3i45HQ/0B24kgXmKbFCKmIBRnW6h6ofh3kuv61LzDXVIPMN/eEGT41XdMZHZRGxDmA0UdmSQkLp79/DbsprmEneA== 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=TSaWeGj0Am0S3/fd3aC1sAOWLM7k1f7SfL68USpWo8w=; b=AJWGO/s+30QENbZsTL7+a5b4mv+iQyMGfzZXZogEDjT8RScwMGyS2ko/R0SHuqdphNJiCbhnb31bi5UxLymHot6AU0+cSVaD4JjBd4JDbHWhxJmpk5kWAlQI0KogkVFiMYxotasEr19mv4UhAl4Dt/Hx857+K5cic0TonvtccTCCj9Qf7XOYbeXX8i3H47a3hh03767A0IRwqWEIM0gqOKNCkWLMGYEt4IoIHOZBiBJD6Nu5WjQKPRhCIhsgr0Jo6mGadyvHJ8VnuO7+zbj9KjfRCkeRQcHSj3IQL1wS8fKSS8k853vGS1cMQDvbO8O6EERfGP5phKnj6xrgV/hq4g== 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=TSaWeGj0Am0S3/fd3aC1sAOWLM7k1f7SfL68USpWo8w=; b=MC5rrtlHSlC/k0+fEGkwTjgX1FoqOrY4oonwc3Jie2/0RsVJPtcHRCZMzzSI+5pLv5td2MIuykwqgruQ4ZPxQbfMkWzytWunAEinOpX0lav/xQirKC6vr/NTkSLH78fuH1VZrSrFZKQEjm8SNspRWwwrAvLPReTp31BRcaqVRxw= Received: from CO6PR11MB5650.namprd11.prod.outlook.com (2603:10b6:5:35a::9) by CO6PR11MB5604.namprd11.prod.outlook.com (2603:10b6:303:138::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.19; Wed, 6 Oct 2021 14:04:52 +0000 Received: from CO6PR11MB5650.namprd11.prod.outlook.com ([fe80::6071:7cb6:d30e:b0d]) by CO6PR11MB5650.namprd11.prod.outlook.com ([fe80::6071:7cb6:d30e:b0d%4]) with mapi id 15.20.4566.023; Wed, 6 Oct 2021 14:04:52 +0000 From: "Francois Clad (fclad)" To: Greg Mirsky , Robert Raszuk CC: Ron Bonica , James Guichard , SPRING WG , "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQCeJTAAAC58nBAAAQ3tgAAHRGEgAAHK+wAAAookgAAiGUeH Date: Wed, 6 Oct 2021 14:04:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6951a8a3-c784-48fb-7d6b-08d988d244c5 x-ms-traffictypediagnostic: CO6PR11MB5604: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PyW13B4iyRclIioOO6mISuOrYTrjWCV4QlOP2p9SJ8xPDfOluMpVYv8xrc3vAIOKq7SaMPLXpCY7qWJMHD5d0+bJkf7XqJ3hYdSBDUFBY5dJ98KPkMrom2zXU4vky19NzPHQ8t8p4aCmu6RIx1XXwsRtLsf4Iew/uE9/X1qjnpjpUTTESPyOotVU6bNwYb68FmFmPLvJq5IVOJjx6xTeGvrUAU+S/FuEZKmURk964TSG+lqos5uoNXyNoGSrrl/QduoIXH9jzNaVd2cx4pyAPTT4JCnic7pjrimDzbVjJmeuqu2OWSV9ojRfPoriJouBHeLbucOBzgN8hKjCqyQmtZPHbgckJiiI+FyrGda6ItoWld6n8si3HyUHTxYzHMvt8z/eWHmT1bttBXm5vd5Ade0eS62CuSajX8h4/EegeWbns/RbxFQ43k1pRVTxqSywHNpaw0TOMg4Ri62SwMDoE43RMQqTeo5+IJ5/B3JrAV1lCN/sivTIA7BXPGCoWSWkBRe/UL129hgBlBd00NC2pUTDlP02IFFsHlI4P46hYwens1P6W+F70/p5oJjxhb/uci3XKeJXvPna3RKEsGLv35GJ0zhirGibHH+cuF4Tc3QRzXiN7ieZeu2vmXuqZcS03he8HmkXvkz3XlqNA3M7jaD76ChRpVudlE0QinWZoYNNw23jJESA/aNeMtZ5XZl0LkUewQN+hPnhw04hjQTeN0fNUxVmZrj+OWvi/+A19QGHc4iXh9FHd3lRYAGzR0vqcHME9htHyvaF/ezLAA+3tGVZ7LUJFGya/PedGJwH4JejMYGxUDbGGZNCv6r7Ho14dHrwFY5WUb5rNeP+kyVl+Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR11MB5650.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(64756008)(6506007)(966005)(66556008)(508600001)(110136005)(66446008)(66476007)(52536014)(2906002)(54906003)(76116006)(316002)(71200400001)(91956017)(66946007)(53546011)(4326008)(38070700005)(9686003)(55016002)(26005)(5660300002)(166002)(186003)(33656002)(8676002)(83380400001)(86362001)(7696005)(122000001)(8936002)(38100700002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?/A6xNOBORXfUKZMUx5FTPiHmm02nlLOR3lc+niMIK8soyGRvRj+t3R7eDaAx?= =?us-ascii?Q?CcD2Gk+q8Zhl7EpIohGMV92atlS+G7nf3xKeC/lpo35C9bxwhkFvi9Zn9luH?= =?us-ascii?Q?wvM2czP/Kx0HysCmyq9bev4BhyqMCefGdQ+Z8KhDFrbEBKk/vjuaiISata4u?= =?us-ascii?Q?rezRRad+ZR6Z3rq5qF3h7fZggEEWFKdvj8qlvHG+Mfp1/zkXE7GALM8deAxp?= =?us-ascii?Q?wWqmHTUQlNsKXHKRB0zxDM0vZCQ35OAygYQkxl9ppwqUePQ2iR473kStZeu4?= =?us-ascii?Q?G5iuznlPuPiLgrfY/vc8xzUVLmCaLHKCM4w+u37jtT1YJBt+g9Z0EQY5Mou2?= =?us-ascii?Q?Wb5VTaA26LlnzJRQ3MXnHqDeTFfSndA4zKVcl212G1B3DdjABsdGMIpLSCYZ?= =?us-ascii?Q?CCqukZGGx1BHeh+5J6X1wt0SfOlK5m2jfrjEki2WC9eNWsrxSCiNzig5G47O?= =?us-ascii?Q?4UNg84F3ERQU8HTgLOPJL+I2NSI0r78LgrcSII+L9dm4t7mKbWAs7nBu6Y6v?= =?us-ascii?Q?w2Xidul9VW4zokE612cZ9m7cTvTsWYcKKL6M4D47K/oL1Z3z8ejcRkdYNT2U?= =?us-ascii?Q?IrnBV/Q+SXOjrGNCfsWJoNVftp0ufsyXj+ScrBuXyuXLphQMWZphvQF/EnM7?= =?us-ascii?Q?LG4EjLjq9CTniyrtEEtnMNxaX3DsDDc3jPnRqcAaYYgwWnEvB/M7FtU09jWv?= =?us-ascii?Q?zBY+E1c3ZWVo+g1fDoYe97h2Y8FtmuOivTpJFN+eHrK6XSZ/F/xC6PQVqr5a?= =?us-ascii?Q?yiITbVyQo8cbFzEI+GTMKIPGVVSN6hzAKmfmlj8P5tu0OjHt3xWX3FYwhf54?= =?us-ascii?Q?GuUbwQIaD/1ETFO9L6AC9FCdMCnWy+LhaRCTfGjNRKSrdDqjGoV0OSdsXGqd?= =?us-ascii?Q?D0gWZhja/LO362dDhhYKlDHgm9xwJTxct1hV5pXUwnp/CO6FlXrN9dEOzbQp?= =?us-ascii?Q?G80uAS/jAgd3fkTE4NygrIbBf3f5Jdf1x3rn+9vstGCXeBZlvMAh6hc7fpB3?= =?us-ascii?Q?U3+qT3/SWDIQkAPptJnAKxYYVAyhZ27jI4iL8F4BnKcrpmZZ9hI4vOhnidhc?= =?us-ascii?Q?jqXZ9QOR+w8/7RhScTxhNib3Xzl5lCtPRKO7XfS4IhEnkPLLfxzawV493Twx?= =?us-ascii?Q?yQ9/a9j+00xVc2xA/k6XUOJ4tKzZpI7u85/K3VoB94G5FKanR0TZXy6FPPIa?= =?us-ascii?Q?3+3cKQJ/laYZaOBRUH1d9zy8jHNBEMNZg/RqAqmEs8MpEEPeXYgyudGAE5Ti?= =?us-ascii?Q?VdI3LSmuB/ou40fXN0Lm3wuaYbPRCEtQTgJdHtK/njpM0BAsxkhp6Fol27r5?= =?us-ascii?Q?6FnPyXmzKyZZoimV+BplLj8J+QhE8cGzjhsF3Q+vtITWrw=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO6PR11MB5650080ED84067C3943ACD66ACB09CO6PR11MB5650namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO6PR11MB5650.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6951a8a3-c784-48fb-7d6b-08d988d244c5 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2021 14:04:52.5300 (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: RnGrNW6781GMxXrpOOVabrMa5WcYyiOn5qY3j/TVKHEntb9TPa0jNN+/FEBAFVn4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR11MB5604 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xbe-rcd-001.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 06 Oct 2021 14:05:36 -0000 --_000_CO6PR11MB5650080ED84067C3943ACD66ACB09CO6PR11MB5650namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, A node that supports this draft in its entirety can instantiate SRv6 SIDs (= e.g., End and End.X SIDs) with any of the three C-SID flavors. In particular, a node can instantiate multiple SRv6 SIDs bound to different= C-SID flavors, possibly with different C-SID lengths. It can also instanti= ate SRv6 SIDs with behaviors and flavors defined in RFC 8986. As defined in Section 4.3 of RFC 8754 and again in Section 3 of RFC 8986, u= pon receiving an IPv6 packet with a destination address matching a FIB entr= y that represents one of these locally instantiated SIDs, the node processe= s the packet according to the behavior (and flavor(s)) (i.e. pseudocode) of= that SID. RFC 8754 and 8986 have already standardized these mechanisms and the C-SID = draft only leverages the same SRv6 dataplane to introduce new endpoint flav= ors for compression. Francois From: spring on behalf of Greg Mirsky Date: Tuesday, 5 October 2021 at 23:37 To: Robert Raszuk Cc: Ron Bonica , James Guichard , SPRING WG , spring-chairs@i= etf.org Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ Hi Robert, as I understand it, you believe everything that is written in the draft. I = hope you can help me find an answer to one simple question: Can a node that supports this draft in its entirety, i.e., supports all "fl= avors" defined in the document, process received SRv6 packet with the SRH e= ncoded according to the specification? So far, the proponents of the draft referred to "planning" how flavors of S= Rv6 SID compressed. To the best of my understanding, that is is a clear dem= onstration of the incompatibility between flavors defined in the CSID draft= . Regardless of what is written in it. Regards, Greg On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk > wrote: Ron & SPRING WG chairs, Through this discussion we first have seen a debate if we need one or more = data planes to compress SIDs in SRv6. WG clearly stated we need one. Following that we have observed a first terminology shift to see if asking = how many solutions should be supported will work any better. To that many W= G members clearly stated that they support one solution. Well please notice that the draft in question in its introduction states: Abstract This document defines a compressed SRv6 Segment List Encoding in the Segment Routing Header (SRH). This solution does not require any SRH data plane change nor any SRv6 control plane change. This solution leverages the SRv6 Network Programming model. So based on my understanding of English the entire draft talks about a sing= le solution. Then suddenly a new question popped up: how many behaviours are acceptable. I bet number of folks including myself said "one" keeping in mind previous = discussions and the definition of "one" meaning based on the SRv6 data plan= e in compliance to [RFC8402], [RFC8754] and [RFC8986]. Interestingly enough the draft in question defines not behaviours but flavo= rs as new variants of the already defined behaviors in Standards Track RFCs= . Namely it defines: 4.1. NEXT-C-SID Flavor 4.2. REPLACE-C-SID Flavor The newly defined behaviour End.XPS is optional. So if there is anything to ask here is to check if WG is ok with two flavor= s or not. I do not recall that question has ever been asked formally during= the WG adoption call. With that let's note that optimal compressed SID size may be different netw= ork to network. One size does not fit all. Draft says: 6.1. C-SID Length The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A C-SID length of 16-bit is recommended. The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths. A C-SID length of 32-bit is recommended. While I personally think 8-bit should be an option, if we choose a single f= lavor we will introduce suboptimality for no good reason. Hardware capable = of supporting any flavor clearly can do LPM on locator. Also hardware capab= le of supporting one flavor can support few other flavors as this is pretty= much just an offset game. Kind regards, Robert On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica > wrote: Pablo, Ae you sure? Please look at the question as Joel asked it ( https://mailarc= hive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ ). = Ron _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_CO6PR11MB5650080ED84067C3943ACD66ACB09CO6PR11MB5650namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,<= o:p>

&nbs= p;

A node th= at supports this draft in its entirety can instantiate SRv6 SIDs (e.g., End= and End.X SIDs) with any of the three C-SID f= lavors.

&nbs= p;

In partic= ular, a node can instantiate multiple SRv6 SIDs bound to different C-SID fl= avors, possibly with different C-SID lengths. It can also instantiate SRv6 = SIDs with behaviors and flavors defined in RFC 8986.

&nbs= p;

As define= d in Section 4.3 of RFC 8754 and again in Section 3 of RFC 8986, upon recei= ving an IPv6 packet with a destination address matching a FIB entry that re= presents one of these locally instantiated SIDs, the node processes the packet according to the behavior (and flavor(= s)) (i.e. pseudocode) of that SID.

&nbs= p;

RFC 8754 = and 8986 have already standardized these mechanisms and the C-SID draft onl= y leverages the same SRv6 dataplane to introduce new endpoint flavors for c= ompression.

&nbs= p;

&nbs= p;

Francois

&nbs= p;

From: spring <spring-b= ounces@ietf.org> on behalf of Greg Mirsky <gregimirsky@gmail.com><= br> Date: Tuesday, 5 October 2021 at 23:37
To: Robert Raszuk <robert@raszuk.net>
Cc: Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org>, James= Guichard <james.n.guichard@futurewei.com>, SPRING WG <spring@ietf= .org>, spring-chairs@ietf.org <spring-chairs@ietf.org>
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.= org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<= /p>

Hi Robert,

as I understand it, you believe everything that is w= ritten in the draft. I hope you can help me find an answer to one simple qu= estion:

Can a node that supports this draft in its entirety,= i.e., supports all "flavors" defined in the document, process re= ceived SRv6 packet with the SRH encoded according to the specification?

So far, the proponents of the draft referred to &quo= t;planning" how flavors of SRv6 SID compressed. To the best of my unde= rstanding, that is is a clear demonstration of the incompatibility between = flavors defined in the CSID draft. Regardless of what is written in it.

 

Regards,

Greg

 

On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk <robert@raszuk.net> wrote:

Ron & SPRING WG chairs,

 

Through this discussion we first have seen a debate = if we need one or more data planes to compress SIDs in SRv6. WG clearl= y stated we need one. 

 

Following that we have observed a first terminology = shift to see if asking how many solutions should be supported will work any= better. To that many WG members clearly stated that they support one solut= ion. 

 

Well please notice that the draft in question in its= introduction states: 

 

Abstract

   This document defines a compressed SRv6 Segment List Encoding = in the
   Segment Routing Header (SRH).  This solution does = not require any SRH
   data plane change nor any SRv6 control plane change.  = This solution
   leverages the SRv6 Network Programming model.

 

So based on my understanding of English the entire d= raft talks about a single solution. 

 

Then suddenly a new question popped up: how man= y behaviours are acceptable. 

 

I bet number of folks including myself said "on= e" keeping in mind previous discussions and the definition of "on= e" meaning based on the SRv6 data plane in compliance to [RFC8402], [R= FC8754] and [RFC8986].

 

Interestingly enough the draft in question defines n= ot behaviours but flavors as new variants of the already defined behaviors = in Standards Track RFCs. Namely it defines: 

 

4.1.  NEXT-C-SID Flavor

4.2.  REPLACE-C-SID Flavor

 

The newly defined behaviour End.XPS is optional.&nbs= p;

So if there is anything to ask here is to check if WG is ok with two flavor= s or not. I do not recall that question has ever been asked formally d= uring the WG adoption call. 

 

With that let's note that optimal compressed SID siz= e may be different network to network. One size does not fit all. Draft say= s: 

6.1.  C-SID Length

   The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengt= hs.  A
   C-SID length of 16-bit is recommended.

   The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID le= ngths.
   A C-SID length of 32-bit is recommended.

 

While I personally think 8-bit should be an option, = if we choose a single flavor we will introduce suboptimality for no good re= ason. Hardware capable of supporting any flavor clearly can do LPM on = locator. Also hardware capable of supporting one flavor can support few other flavors as this is pretty much just an of= fset game. 

 

Kind regards,

Robert

 

 

 

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

--_000_CO6PR11MB5650080ED84067C3943ACD66ACB09CO6PR11MB5650namp_-- From nobody Wed Oct 6 07:21:12 2021 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 AD0333A1C84 for ; Wed, 6 Oct 2021 07:21:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 SQJxZfLcfLXq for ; Wed, 6 Oct 2021 07:21:02 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (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 C676A3A1C85 for ; Wed, 6 Oct 2021 07:21:01 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) (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 opfednr22.francetelecom.fr (ESMTP service) with ESMTPS id 4HPc7Z2XDzz10XB for ; Wed, 6 Oct 2021 16:20:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1633530058; bh=mt+qDca+vl8gxE1fZWjUw6n1xrw1tpjpqRjo+/1hvnU=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=VCSL0AyH5NzY99wXq0C+EK3NFixp5ERN56Nz7KVilxZd/dTEoSE+iOSRiA0S88PYQ QMiBeUU3OnYDspoMX7+EgkXzewjXQr/KeAAmMonMZplzqFC59NTCCrvkDs7dMMC3SX XJTukZLYTJXwRI365raGf7uumQj9XFojmj1ZrDp6ghAYSPcePxLejygWCyk9hOkZFp aWLnMrZkVa4VsBELg374znpQX3381Xx5NlU1NRsROKeeVQGnETRyv7TjYou69n8EXZ LFGT8jjmZoNLEyxSiC70tVa68V78tY4liArhjOeBts2y4FLmwgBHFdWSrxuUXzisc4 fiLWTYYBwYzNw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr00.francetelecom.fr (ESMTP service) with ESMTPS id 4HPc7Z1sb3zDq7Y for ; Wed, 6 Oct 2021 16:20:58 +0200 (CEST) From: To: "spring@ietf.org" Thread-Topic: IPR Disclosure Cisco Systems, Inc.'s Statement about IPR related to draft-filsfilscheng-spring-srv6-srh-compression Thread-Index: AQHXuryMIBtHN5IKVEu6FXkusMkzhqvGBMZw Date: Wed, 6 Oct 2021 14:20:57 +0000 Message-ID: <23566_1633530058_615DB0CA_23566_234_19_53C29892C857584299CBF5D05346208A4CEED1D3@OPEXCAUBM43.corporate.adroot.infra.ftgroup> References: <163352969486.29888.2654308868674216045@ietfa.amsl.com> In-Reply-To: <163352969486.29888.2654308868674216045@ietfa.amsl.com> 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=2021-10-06T14:20:55Z; 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=; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2 x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [spring] FW: IPR Disclosure Cisco Systems, Inc.'s Statement about IPR related to draft-filsfilscheng-spring-srv6-srh-compression 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, 06 Oct 2021 14:21:10 -0000 DQoNCg0KT3JhbmdlIFJlc3RyaWN0ZWQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZy b206IElFVEYgU2VjcmV0YXJpYXQgPGlldGYtaXByQGlldGYub3JnPiANClNlbnQ6IFdlZG5lc2Rh eSwgT2N0b2JlciA2LCAyMDIxIDQ6MTUgUE0NClRvOiBkcmFmdC1maWxzZmlsc2NoZW5nLXNwcmlu Zy1zcnY2LXNyaC1jb21wcmVzc2lvbkBpZXRmLm9yZw0KQ2M6IGlwci1hbm5vdW5jZUBpZXRmLm9y Zw0KU3ViamVjdDogSVBSIERpc2Nsb3N1cmUgQ2lzY28gU3lzdGVtcywgSW5jLidzIFN0YXRlbWVu dCBhYm91dCBJUFIgcmVsYXRlZCB0byBkcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNy aC1jb21wcmVzc2lvbg0KDQpEZWFyIFdlaXFpYW5nIENoZW5nLCBDbGFyZW5jZSBGaWxzZmlscywg WmhlbmJpbiBMaSwgQnJ1bm8gRGVjcmFlbmUsIERlemhvbmcgQ2FpLCBEYW5pZWwgVm95ZXIsIEZy YW5jb2lzIENsYWQsIFNoYXkgWmFkb2ssIEppbSBHdWljaGFyZCwgTGl1IEFpaHVhLCBSb2JlcnQg UmFzenVrLCBDaGVuZyBMaToNCg0KDQpBbiBJUFIgZGlzY2xvc3VyZSB0aGF0IHBlcnRhaW5zIHRv IHlvdXIgSW50ZXJuZXQtRHJhZnQgZW50aXRsZWQgIkNvbXByZXNzZWQNClNSdjYgU2VnbWVudCBM aXN0IEVuY29kaW5nIGluIFNSSCINCihkcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNy aC1jb21wcmVzc2lvbikgd2FzIHN1Ym1pdHRlZCB0byB0aGUgSUVURg0KU2VjcmV0YXJpYXQgb24g MjAyMS0xMC0wNSBhbmQgaGFzIGJlZW4gcG9zdGVkIG9uIHRoZSAiSUVURiBQYWdlIG9mDQpJbnRl bGxlY3R1YWwgUHJvcGVydHkgUmlnaHRzIERpc2Nsb3N1cmVzIg0KKGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvaXByLzUxODQvKS4gVGhlIHRpdGxlIG9mIHRoZSBJUFIgZGlzY2xvc3VyZSBp cw0KIkNpc2NvIFN5c3RlbXMsIEluYy4ncyBTdGF0ZW1lbnQgYWJvdXQgSVBSIHJlbGF0ZWQgdG8N CmRyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uIg0KDQoNClRo YW5rIHlvdQ0KDQpJRVRGIFNlY3JldGFyaWF0DQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlm ZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl eiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4 cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVz IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwK T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRp c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMg bWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhh dmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Wed Oct 6 09:06:46 2021 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 7B5963A1EA3; Wed, 6 Oct 2021 09:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=im4dx92w; dkim=pass (1024-bit key) header.d=juniper.net header.b=c5qb4GFw 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 ITr8vSJ15UsM; Wed, 6 Oct 2021 09:06:31 -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 1D7403A1EA2; Wed, 6 Oct 2021 09:06:31 -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 SMTP id 19689WQ6022277; Wed, 6 Oct 2021 09:06:28 -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=nzKIZ6c4RZZvi33usqR+/leOs0TiJWuyz7cJNf9XoEg=; b=im4dx92wLjMXLBTj0cHzBod/bOcwCng8gz86bR9bd2SHmaG4dRaMfkKIRcfo6eg+7/QE uy0V83ggfvaLW/EhnkUyJsjaZYDkx9wfmIE0rUkKVQ6ZJRZavx1m0d7zIJSwAM0cO+lS uw9G8GKQ1NDxfcC2Sbyfr2L7k6NL104t3VI3rqzBYM9aZot4qwu67ysi9jZwkXbO3J8l mJrB7z1B3t98hIuYUsRA+dur451wyNRia3zsy4U6vu1ceOHXvlhKRvi6jJaSXW5EPQsD kfoVCCdwUcUzkGWyR9L7cKoNCInHHHH59XzgCaAFrAJUBtHDNvDShMXVdLrT8bTOX2tQ 5w== Received: from nam12-bn8-obe.outbound.protection.outlook.com (mail-bn8nam12lp2172.outbound.protection.outlook.com [104.47.55.172]) by mx0b-00273201.pphosted.com with ESMTP id 3bh81x12ty-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 06 Oct 2021 09:06:27 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FRDGr4Wd577L1uuzoF3lul9v/I4Be+ef1s96pItf5re07NXDsschw1p3JHlYEU4xq+RvKg26OhRfqeSPsFMgdleKi2xAGPzQWOO8FUnXIge61oL7Qk/dlxUXaMl8filg4JrcfN/UUnI75m6wNEUCWn2sMU/5esf6nxxE941/qkoSo9Ck9pUkTRDEGKSTjBe7sfvT2C/F/B+GvJq8h1+66ed12qyEcCosJ2Ciox42S3CiqRFdwtjlpgi8ripmXL7E7pbdnLKWdpKF2kc3QsVpcB8qfZI13Zx06mqRiG6Co8TdEn1SKD9jVwCmWgkg8n+z/8WLLMXSKc+MeUQZVyaQtA== 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=nzKIZ6c4RZZvi33usqR+/leOs0TiJWuyz7cJNf9XoEg=; b=feeiTKCKPgOlQ57oCWnvxQbDG8CU97f8UeUmIoEeZu3bU0i4rZIrrN4UrZ36fPoJJuA4r7ZTXYems2YGeqH/n2cTAgk9xvuMzXquVXh0MjDpwuPizNkTEhAIlTLV0jkjQZ1WuzSDpkTi94BadH0m3wbdfhk/ejz2/gksSDF/w/DZgXTvVE/XMIep1wbEJ2hxTMIpk1/KNJ4ybFauW+DjDNv3q6SEzQq3Hp1LtSZoA8MPPyEzpoQFV8aBEeOMyLDeTQdp4yev+kmBa33j9jp68da2egcLEfYN2ScRar4ugiTx5UxyNj6fIm+HTOlcbHrjRrBTHadebt4BH8ET8gPRkQ== 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=nzKIZ6c4RZZvi33usqR+/leOs0TiJWuyz7cJNf9XoEg=; b=c5qb4GFwCyemPtW28tvuCTmBFwzPmgu4/+fH1eBdu87BODCdhODczAxkqDdsbyJvrSoX4fsibuoewom1he62b4gmPrxaeRxcTpcS4+rKpYNtko5d0PkhNImtnRDHR8nWt35wz6cZ0RkMPQpViVuG6G6VhtXxDCBTM8MAOAh6iwI= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by BL0PR05MB4932.namprd05.prod.outlook.com (2603:10b6:208:2a::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.7; Wed, 6 Oct 2021 16:06:25 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4608.004; Wed, 6 Oct 2021 16:06:25 +0000 From: Ron Bonica To: Ahmed Bashandy , James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQDkW2yAABt8FUA= Date: Wed, 6 Oct 2021 16:06:25 +0000 Message-ID: References: <369d2f7c-a242-8759-2ebd-6f2227c45cc6@gmail.com> In-Reply-To: <369d2f7c-a242-8759-2ebd-6f2227c45cc6@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-06T16:06:23Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=f0a77825-3dc0-40c0-b328-c5c861b30de0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 25561604-8cea-4a2a-387b-08d988e33faa x-ms-traffictypediagnostic: BL0PR05MB4932: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0X4JpF3TDsLsDlvItZJT9RfZo0Kqv3phv87iFkVS1bCgcGJ/dzFTwldrc4LREkpmXYNh5Ady5al9f9ys3zv8U4QU7VRedj1Rt6/0CMHLhv3J86frEWz7cuOgZw3AfskwahB2sLqqZb74ltxVwyVaW6GnM+o3HryQy1x5jj1DT6oUEJBYrhpfjYChaP1q4ZIBw4pFpyJQp5GHI3OVGCVxlI+NlMBlqrHztdI3rxkq1U58lFUWzrvCvOLYh3dtM7nJ5qJZ0cyTCwpYFdenfU43JsGAYQ9bz6YYl33UjV408PKQZbz21wp4kUn/e5VyOMG8sG6I4UaFQMUbeOGYVQkvIbXqeR8JZZtV5Tqk85beVFw76vC7qKNqd7xE8TBuPG5AzW8WkkpMRKtYN4Xh/kgfM3IeLhFyHDX0zg0KS1f4OOCoJsjgPYbFMngy714Yc43NQqU6VOPSIvINRAnBCna56yOwIBALeIWwVX3Z6Hnn8oFdFCLxCRsfQPem+6e82O4m30PfyL2rY2ZrkNIRxlRfRRsrAGmY3vFgcv7Do990YbOt/brMcZAmqggnsakzzxO4mNkogzz/lGTtDrYx0hASxKuokwFlMLgO8OKYwGaGP/ipszIHfoRmBgZn1KC+AwYGKbo+DEeFBjV4hoYJlK42B4j1oEN9xV+wPByqa6Eu/cfJM78H/Xq6s+NcYQ6FibJelELTMWP8oW9p54Z6RsMbir5bmErqAltWydnYc/Mqft31naztudyVBpif8jpFor4p8jbuPdhmbvp4kVhVFuPwDl6gI0vwR69iAkw5OYzGu5VGZ16gEqjnkF4C0c74QwPW x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(86362001)(52536014)(966005)(7696005)(2906002)(66476007)(64756008)(5660300002)(4326008)(316002)(110136005)(26005)(166002)(55016002)(38070700005)(8936002)(186003)(71200400001)(83380400001)(66556008)(6506007)(53546011)(122000001)(66446008)(38100700002)(8676002)(9686003)(508600001)(33656002)(66946007)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?pgraiUZUdxvA1v7paDlZmrIlX8SS89+lU+Vg9rxNBhp76yu6KFKNbUrH3oxo?= =?us-ascii?Q?UsIMemROjJBI+RgecAIRg/s7EGkzsE1yehNG86XBijM4/PfC5P1WMv+LK/p7?= =?us-ascii?Q?ilNsFnoy0NqjCGb8W0pdvlOpP09kgQCynsuK6jz9U8TZahXjZ8uZ11g4EMru?= =?us-ascii?Q?N916RFdyHHfQbvZdjBOZ3Z/zih0IqYyLYnYpivklQl2EuELMNoU0ZeHixRrH?= =?us-ascii?Q?p6yj1GTCtKakUvkgzoJntE8W7bOAaPuXjGe5266z6QXoWSkU34FfVnorARqe?= =?us-ascii?Q?nZX6WBanwvL2nVLRCnuVl7qouSYlJ1rk7RaXzdf08TXJwyVd4bRatPHuGyJN?= =?us-ascii?Q?l4wug850qZbe5JIiLB/d/BgbSWVwcYGduzP3IHX17yXu8jOku+LNvl/JmO9z?= =?us-ascii?Q?yXwRbKaTDPdZnJBCSK0cf14jzKjkQIxcpPVdYwNaF2k/gFsgIQH940+t3wbU?= =?us-ascii?Q?gtpXa/AryHi/G+f9AOtIxFeTyp+0B/rTjTTsLpk6+a0cvpruq+GgQijfbkL3?= =?us-ascii?Q?iIPkFUyPl4lIwvu0I8KpIYIXQhbV7Ua9ihu5IvmMkJ3cMmUVTQQ8eSGQoV9v?= =?us-ascii?Q?RZMxyAVuNvuS6ZIePZP748VitbdkbjiR8PeiThMOiYRqH7SmWMQARQ1wPbIo?= =?us-ascii?Q?8jkbiSjGTmaf9e5hiDadOaDPqsF2X6cdc8ZGmajgwNhGuJXUPDdVXxunexmz?= =?us-ascii?Q?h6rx8lSv6jHYYckVLpbyxOGmmopT/c+HjCWsSaf3AKATYfBbqJ9naDNHrqgB?= =?us-ascii?Q?2hza61/PiwTvnxpx14CKHKunM9+yFrk5xUIexx1DQCq/RjajmtDX/yFkglfG?= =?us-ascii?Q?qHmhMlc2yyisFfbqXVwLeI29d8Wn5TDHHnGiI1hAW+4ZdWxto5ux48WHwjS7?= =?us-ascii?Q?b8VAGA6O/QjMt3XebDR6q+ZBlAHiUiem7iVcAW20SuflJxxpPwErP+cqGCVk?= =?us-ascii?Q?hYx+ZCxEaAdA5K3jJBHU0AZEZ31AX4jxIeVx5dH6A+gcKPVMQPaRG38QzJzp?= =?us-ascii?Q?r0I2rbrte98hyNqE4q742Q/fbrJj7tV/JblqMRWyVWRlnIx0GHDBgxq9Cz0Q?= =?us-ascii?Q?jlzNCNzwLoOI9cwQCL5uTJEN/e8oBDuwrVmutP+vFjWPJfxGoglMYLfWuvTI?= =?us-ascii?Q?pq+Uxxpz3EHArrEeDjPXs2gEQOJ6voLa0bnrAIJXS2X2SsAB7X8rh3T+MFCl?= =?us-ascii?Q?/pMW5YEvZsx4qTZ8owJHExvROU48+NkCzQR+V0up8oGfcF9KL2HHoyhrAyez?= =?us-ascii?Q?q7+MYl2dsnLN6zpx4BtDOmG6lc86sf/RecDFjeAH3dPxHcZNW4aYRlz5H28Z?= =?us-ascii?Q?K0cOFzi0AtgmOgB4AHLKPNn5?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR05MB53167513257DB7F5DDCFA56AAEB09BL0PR05MB5316namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 25561604-8cea-4a2a-387b-08d988e33faa X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2021 16:06:25.5360 (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: TYIAXgo4wuVskxdtgyT3W0hdJryiPZjmcpwrhsLkFtvulJIALJgavhinFVdHng5HVWmCfwnKy4wvmwSf1uocJg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB4932 X-Proofpoint-GUID: 6oU7ItAl2r4SK-iGrwO_eEaigxq8-3Qr X-Proofpoint-ORIG-GUID: 6oU7ItAl2r4SK-iGrwO_eEaigxq8-3Qr X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-06_04,2021-10-06_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 suspectscore=0 lowpriorityscore=0 spamscore=0 adultscore=0 impostorscore=0 phishscore=0 mlxscore=0 bulkscore=0 malwarescore=0 mlxlogscore=999 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110060101 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 06 Oct 2021 16:06:38 -0000 --_000_BL0PR05MB53167513257DB7F5DDCFA56AAEB09BL0PR05MB5316namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ahmed, I don't recall the DT recommending the CSID. In fact, the word "recommend" = does not appear anywhere in the analysis document. As a member of the DT, I don't recommend CSID. = Ron Juniper Business Use Only From: spring On Behalf Of Ahmed Bashandy Sent: Tuesday, October 5, 2021 10:53 PM To: James Guichard ; SPRING WG Cc: spring-chairs@ietf.org Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ [External Email. Be cautious of content] I support the adoption of this document. * The network programming model (RFC8986) defines multiple behaviors, C= SID is just adding the next and replace flavors * The draft proposes a single SRv6 based data plane that defines next a= nd replace behaviors. IMO that is consistent with RFC8986 * CSID has been recommended by the design team for SRv6 based compressi= on * Interop was done. That is more evidence that CSID is a single data pl= ane solution * IMO CSID is ready to become the basis for the SRv6 compression soluti= on * Being an SRv6 data plane-based solution, CSID is coherent with the on= e data plane solution objective * CSID meets SRv6 compression requirements as single solution Thanks Ahmed On 10/1/21 7:04 AM, James Guichard wrote: Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardizat= ion work. That is part of what this email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as follows. By expressing support for a= doption of this document you are fully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_BL0PR05MB53167513257DB7F5DDCFA56AAEB09BL0PR05MB5316namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ahmed,

 

I don’t recal= l the DT recommending the CSID. In fact, the word “recommend” d= oes not appear anywhere in the analysis document.

 

As a member of the = DT, I don’t recommend CSID.

 

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;            &nb= sp;        Ron

 

 

Juniper Business Use Only

From: spring <spring-bounces@ietf.org> = On Behalf Of Ahmed Bashandy
Sent: Tuesday, October 5, 2021 10:53 PM
To: James Guichard <james.n.guichard@futurewei.com>; SPRING WG= <spring@ietf.org>
Cc: spring-chairs@ietf.org
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.= org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

 

<= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

 

I support the adoption of this document.

  • The network programming model (RFC8986) defines multiple behaviors, CSID is= just adding the next and replace flavors
  • The draft proposes a single SRv6 based data plane that defines next and rep= lace behaviors. IMO that is consistent with RFC8986
  • CSID has been recommended by the design team for SRv6 based compression
  • Interop was done. That is more evidence that CSID is a single data plane so= lution
  • IMO CSID is ready to become the basis for the S= Rv6 compression solution
  • Being an SRv6 data plane-based solution, CSID is coherent with the one data plane solution objective
  • CSID meets SRv6 compression requirements as single solution
    • =

 

Thanks

 

Ahmed

 

On 10/1/21 7:04 AM, James Guichard wrote:=

Dear WG:

 

The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

 

The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors.
  2. The document is a “living” document; it m= ay change as it goes through review and analysis by the SPRING working grou= p.
  3. All open discussion points raised on our mailing list= MUST be addressed BEFORE said document is allowed to progress from the wor= king group to publication. A list of these discussion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
  4. If this document is adopted by the working group, the= chairs specify as part of the adoption call that the following text descri= bing an open issue be added to the document in the above-described open issues section:
    1. "Given th= at the working group has said that it wants to standardize one data plane s= olution, and given that the document contains multiple SRv6 EndPoint behavi= ors that some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

 

Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

 

_______________________________________________
spring mailing list
spring@ietf.org

https://www.ietf.org/mailman/listinfo/spring<=
/o:p>
--_000_BL0PR05MB53167513257DB7F5DDCFA56AAEB09BL0PR05MB5316namp_-- From nobody Wed Oct 6 10:19:36 2021 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 CC06A3A0768; Wed, 6 Oct 2021 10:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 n-W-D3ePV9qn; Wed, 6 Oct 2021 10:19:28 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 425E83A0763; Wed, 6 Oct 2021 10:19:28 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id dj4so12581596edb.5; Wed, 06 Oct 2021 10:19:28 -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=CqBYhW1sp42VM/Snejs2HcZseAqKWraaUdldbc7/W8I=; b=n2LGJQgScK1TsMhd+XxpP5wVEq6FbbSZPk60bUTpj4/y90lX4GVB1szqYveOTFM+l1 uQXctcD7XL9O1vh+27Z7HPzxAbyjcOQU0Vi3bCUy9e2zE8nkMp+PMohhLTDFsSX1GZ5q Qs9PW5PmgYADGtP1WJ1etGUlIQW4wfRJmsGMb5oZC7Z95po8ClW2KqFofOrUtUXLNmYN rL8IFA+uHySPQ8L7D5i3lqpfbuw2eupNhW8R8wnXAKq3/lYEVLpRD7SAukQ3EDiKwkMu jV+YoGo5LUtKF/yW3PsoS9Ws73AqYrtgoXH13zPl6qLkK+WyYW16VIoJQncE8Ifm2sL7 0y1w== 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=CqBYhW1sp42VM/Snejs2HcZseAqKWraaUdldbc7/W8I=; b=bCsoiFiuWyMRQfthGLfzNZUhySBv8Ybbk3nOW2saKPmAs+bati39FNySQE4/q+Y4nG C6M7Xwg3Axjo4dSSY3XfuLEBJkgbvjTc1tPDeKpjvVrutnOnyEz/clOmNyl1zzkVUSG5 4Rp8V4sS2aRLNr/OgHBuowD83uG5ibzQPHQfGAGSr+BzN8gE7Hqq78iS1+Mt0b14xx/F W1qDiyDbCFVC2gJXnEIVzGRQiy3iQtKRIRruCnWg8f/7IRJzvqo4eHLG81j4UsYRfH4C G47cq4+KMxnQe+A9EJAEBnCoiRtm2d2tMARvx+AjlaEy3zWL86APgUrAbV5joL1zBJOU Ztyw== X-Gm-Message-State: AOAM533WqMt8ycFJGa4DasT4G5DLVHTSKF+THm3lr8AX7QTgdlMqm6nF AEOdeX6j558XVfpQpcqkfQ6x1SKtN/3H+e5mM+CBHU4Hx3A= X-Google-Smtp-Source: ABdhPJw/ATRBwuAeaaw0RgUg4p72brQXIEdmsK+soQC1NVZ7BcBc/cWVdT2NDHTTDI75EIVEW1kYC3UY3QW8TcNGh80= X-Received: by 2002:a05:6402:1207:: with SMTP id c7mr33783030edw.342.1633540766417; Wed, 06 Oct 2021 10:19:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Wed, 6 Oct 2021 10:19:14 -0700 Message-ID: To: "Francois Clad (fclad)" Cc: Robert Raszuk , Ron Bonica , James Guichard , SPRING WG , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001bc73205cdb259c9" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 06 Oct 2021 17:19:35 -0000 --0000000000001bc73205cdb259c9 Content-Type: text/plain; charset="UTF-8" Hi Francois, thank you for the clarification. It is still not clear how a node selects which flavor of CSID to use on the next compressed CSID that may happen also be in the next CSID container. As I understand it, a CSID container must use the same flavor of compression but CSID containers with different compression flavors in the same SRH are allowed. Is that correct understanding? Regards, Greg On Wed, Oct 6, 2021 at 7:05 AM Francois Clad (fclad) wrote: > Hi Greg, > > > > A node that supports this draft in its entirety can instantiate SRv6 SIDs > (e.g., End and End.X SIDs) with any of the three C-SID flavors. > > > > In particular, a node can instantiate multiple SRv6 SIDs bound to > different C-SID flavors, possibly with different C-SID lengths. It can also > instantiate SRv6 SIDs with behaviors and flavors defined in RFC 8986. > > > > As defined in Section 4.3 of RFC 8754 and again in Section 3 of RFC 8986, > upon receiving an IPv6 packet with a destination address matching a FIB > entry that represents one of these locally instantiated SIDs, the node > processes the packet according to the behavior (and flavor(s)) (i.e. > pseudocode) of that SID. > > > > RFC 8754 and 8986 have already standardized these mechanisms and the C-SID > draft only leverages the same SRv6 dataplane to introduce new endpoint > flavors for compression. > > > > > > Francois > > > > *From: *spring on behalf of Greg Mirsky < > gregimirsky@gmail.com> > *Date: *Tuesday, 5 October 2021 at 23:37 > *To: *Robert Raszuk > *Cc: *Ron Bonica , James Guichard < > james.n.guichard@futurewei.com>, SPRING WG , > spring-chairs@ietf.org > *Subject: *Re: [spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > Hi Robert, > > as I understand it, you believe everything that is written in the draft. I > hope you can help me find an answer to one simple question: > > Can a node that supports this draft in its entirety, i.e., supports all > "flavors" defined in the document, process received SRv6 packet with the > SRH encoded according to the specification? > > So far, the proponents of the draft referred to "planning" how flavors of > SRv6 SID compressed. To the best of my understanding, that is is a clear > demonstration of the incompatibility between flavors defined in the CSID > draft. Regardless of what is written in it. > > > > Regards, > > Greg > > > > On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk wrote: > > Ron & SPRING WG chairs, > > > > Through this discussion we first have seen a debate if we need one or more > data planes to compress SIDs in SRv6. WG clearly stated we need one. > > > > Following that we have observed a first terminology shift to see if asking > how many solutions should be supported will work any better. To that many > WG members clearly stated that they support one solution. > > > > Well please notice that the draft in question in its introduction states: > > > > Abstract > > This document defines a compressed SRv6 Segment List Encoding in the > Segment Routing Header (SRH). *This solution* does not require any SRH > data plane change nor any SRv6 control plane change. *This solution* > leverages the SRv6 Network Programming model. > > > > So based on my understanding of English the entire draft talks about a > single solution. > > > > Then suddenly a new question popped up: how many behaviours are > acceptable. > > > > I bet number of folks including myself said "one" keeping in mind previous > discussions and the definition of "one" meaning based on the SRv6 data > plane in compliance to [RFC8402], [RFC8754] and [RFC8986]. > > > > Interestingly enough the draft in question defines not behaviours but > flavors as new variants of the already defined behaviors in Standards Track > RFCs. Namely it defines: > > > > 4.1. NEXT-C-SID Flavor > > 4.2. REPLACE-C-SID Flavor > > > > The newly defined behaviour End.XPS is optional. > > So if there is anything to ask here is to check if WG is ok with two > flavors or not. I do not recall that question has ever been asked formally > during the WG adoption call. > > > > With that let's note that optimal compressed SID size may be different > network to network. One size does not fit all. Draft says: > > 6.1. C-SID Length > > The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A > * C-SID length of 16-bit is recommended.* > > The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths. > * A C-SID length of 32-bit is recommended.* > > > > While I personally think 8-bit should be an option, if we choose a single > flavor we will introduce suboptimality for no good reason. Hardware > capable of supporting any flavor clearly can do LPM on locator. Also > hardware capable of supporting one flavor can support few other flavors as > this is pretty much just an offset game. > > > > Kind regards, > > Robert > > > > > > > > On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica 40juniper.net@dmarc.ietf.org> wrote: > > Pablo, > > > > Ae you sure? Please look at the question as Joel asked it ( > https://mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ > ). > > > > > Ron > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > --0000000000001bc73205cdb259c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Francois,
thank you for the clarification. It is st= ill not clear how a node selects which flavor of CSID to use on the next co= mpressed CSID that may happen also be in the next CSID container. As I unde= rstand it, a CSID container must use the same flavor of compression but CSI= D containers with different compression flavors in the same SRH are allowed= . Is that correct understanding?

Regards,
Greg

On Wed, Oct 6, 2021 at 7:05 AM Francois Clad (fclad) <fclad@cisco.com> wrote:

Hi Greg,

=C2=A0

A node that supports this draft in its entiret= y can instantiate SRv6 SIDs (e.g., End and End.X SIDs) with any of the three C-SID = flavors.

=C2=A0

In particular, a node can instantiate multiple= SRv6 SIDs bound to different C-SID flavors, possibly with different C-SID = lengths. It can also instantiate SRv6 SIDs with behaviors and flavors defin= ed in RFC 8986.

=C2=A0

As defined in Section 4.3 of RFC 8754 and agai= n in Section 3 of RFC 8986, upon receiving an IPv6 packet with a destinatio= n address matching a FIB entry that represents one of these locally instant= iated SIDs, the node processes the packet according to the behavior (and flavor(= s)) (i.e. pseudocode) of that SID.

=C2=A0

RFC 8754 and 8986 have already standardized th= ese mechanisms and the C-SID draft only leverages the same SRv6 dataplane t= o introduce new endpoint flavors for compression.

=C2=A0

=C2=A0

Francois

=C2=A0

Hi Robert,

as I understand it, you believe everything that is w= ritten in the draft. I hope you can help me find an answer to one simple qu= estion:

Can a node that supports this draft in its entirety,= i.e., supports all "flavors" defined in the document, process re= ceived SRv6 packet with the SRH encoded according to the specification?<= /u>

So far, the proponents of the draft referred to &quo= t;planning" how flavors of SRv6 SID compressed. To the best of my unde= rstanding, that is is a clear demonstration of the incompatibility between = flavors defined in the CSID draft. Regardless of=C2=A0what is written in it.

=C2=A0

Regards,

Greg

=C2=A0

On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk <robert@raszuk.net&g= t; wrote:

Ron & SPRING WG chairs,

=C2=A0

Through this discussion we first have seen a debate = if we need one or more data planes=C2=A0to compress SIDs in SRv6. WG clearl= y=C2=A0stated we need one.=C2=A0

=C2=A0

Following that we have observed a first terminology = shift to see if asking how many solutions should be supported will work any= better. To that many WG members clearly stated that they support one solut= ion.=C2=A0

=C2=A0

Well please notice that the draft in question in its= introduction states:=C2=A0

=C2=A0

Abstract

=C2=A0 =C2=A0This document defines a compressed SRv6 Segment List Encoding = in the
=C2=A0 =C2=A0Segment Routing Header (SRH). =C2=A0This solution does = not require any SRH
=C2=A0 =C2=A0data plane change nor any SRv6 control plane change. =C2=A0= This solution
=C2=A0 =C2=A0leverages the SRv6 Network Programming model.

=C2=A0

So based on my understanding of English the entire d= raft talks about a single solution.=C2=A0

=C2=A0

Then suddenly a new question popped=C2=A0up: how man= y behaviours are acceptable.=C2=A0

=C2=A0

I bet number of folks including myself said "on= e" keeping in mind previous discussions and the definition of "on= e" meaning based on the SRv6 data plane in compliance to [RFC8402], [R= FC8754] and [RFC8986].

=C2=A0

Interestingly enough the draft in question defines n= ot behaviours but flavors as new variants of the already defined behaviors = in Standards Track RFCs. Namely it defines:=C2=A0

=C2=A0

4.1.=C2=A0 NEXT-C-SID Flavor

4.2.=C2=A0 REPLACE-C-SID Flavor

=C2=A0

The newly defined behaviour End.XPS is optional.=C2= =A0

So if there is anything to ask here is to check if WG is ok with two flavor= s or not. I do not recall that question has=C2=A0ever been asked formally d= uring the WG adoption call.=C2=A0

=C2=A0

With that let's note that optimal compressed SID= size may be different network to network. One size does not fit all. Draft= says:=C2=A0

6.1.=C2=A0 C-SID Length

=C2=A0 =C2=A0The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengt= hs. =C2=A0A
=C2=A0 =C2=A0C-SID length of 16-bit is recommended.

=C2=A0 =C2=A0The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID le= ngths.
=C2=A0 =C2=A0A C-SID length of 32-bit is recommended.<= /p>

=C2=A0

While I personally think 8-bit should be an option, = if we choose a single flavor we will introduce suboptimality for no good re= ason. Hardware capable=C2=A0of supporting any flavor clearly can do LPM on = locator. Also hardware capable of supporting one flavor can support few other flavors as this is pretty much just an of= fset game.=C2=A0

=C2=A0

Kind regards,

Robert

=C2=A0

=C2=A0

=C2=A0

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

--0000000000001bc73205cdb259c9-- From nobody Wed Oct 6 10:20:57 2021 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 B2B793A0763; Wed, 6 Oct 2021 10:20:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oFEYlQrdgpg; Wed, 6 Oct 2021 10:20:50 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 891A73A074B; Wed, 6 Oct 2021 10:20:50 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id m21so3045963pgu.13; Wed, 06 Oct 2021 10:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=3gS0I+D/PYi0eFrJzAuEmEwrrYK24QmlpmUXnil3438=; b=fZV2i9bGa0LX6jlFojX05Nk0QxwjNGQSJin44kvDsyJvgbxvsbA3Ze9BTXH0Fj2zyq LzhxIueq/4ajqDLs5pPUWg33/I6CqbXsW2h+fMyH8HWXNRbEp/JSgM5IFiTV857CZ1SY +dXcfuwB7Kx+WPAFSDKP5IX/P6pa4BFNACtSoQMY0BdMfmkQJTQY4LRjRa2ji6adXa/x 4Lls7QTRhVGlIml/pucpckkPAnBkUiN1EBsO2SnFX1QpaV7inhTA3lnw+y8CrhoKRCQO 2RiS+dqVxXLVAVAeoNfT3alKxpp+FEMrzzWNkrk4ETCOU1XVY9zxZkAh/wpoD2Kc7lOR H02A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=3gS0I+D/PYi0eFrJzAuEmEwrrYK24QmlpmUXnil3438=; b=Qx/IiiqR8KIO/RIF5CMpWDDJWPBb7HhivCo0XxRameIolTQW24Zf2Mq4L1kf69Poce t1gDx9GAdd8lXSWeSAJtPUSFIobAIYHTzfm4UAxD3HVgemY0+BC9qhPR2CFsli70JDvy P7lMEr89uhd+p8hM8HBXQq5MGyeo32CXtvewv93nqJpaeMNjaH0lSLcI0pr2aHHf6MgU J0gR5+eosTZ1QeaXwwObe8VKctHPOp8rZs+9DDuNCSNlAKkO6o0zLbGcKGHKqydlDB0l RtqmBb3dt0GjZm02MTj7mXILE5vRwGE7JrInuxnz4gwtEVFmDxuUoOSPAEZHj6VkM65L wSQA== X-Gm-Message-State: AOAM530EZ8EYVJteGlk72Gp8931fFDCoo/hTrYGJEZKtFBTMMaMBXb0u ILOB1b1HZXerR6fO7my1/4+ziHvKjl0= X-Google-Smtp-Source: ABdhPJwFXVgiM4nNXCQm1g6wxFmTvmHQUTLIo0r3c+fTc/K9RhXUOy+oOBdNtMB0Pc0hRW6LTVlzpA== X-Received: by 2002:a63:2b03:: with SMTP id r3mr21669378pgr.188.1633540849406; Wed, 06 Oct 2021 10:20:49 -0700 (PDT) Received: from Ahmeds-MacBook-Pro-3.local (c-73-189-164-225.hsd1.ca.comcast.net. [73.189.164.225]) by smtp.gmail.com with ESMTPSA id z22sm20574445pgn.81.2021.10.06.10.20.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Oct 2021 10:20:49 -0700 (PDT) To: Ron Bonica , James Guichard , SPRING WG Cc: "spring-chairs@ietf.org" References: <369d2f7c-a242-8759-2ebd-6f2227c45cc6@gmail.com> From: Ahmed Bashandy Message-ID: <8f66b562-2887-6a35-52c5-1d5561ca74f5@gmail.com> Date: Wed, 6 Oct 2021 10:20:47 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8FEA7743CF20C2EDA7E5B3DC" Content-Language: en-US Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 06 Oct 2021 17:20:56 -0000 This is a multi-part message in MIME format. --------------8FEA7743CF20C2EDA7E5B3DC Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit If we take a look at the summary table in slide 17 in the DT presentation at last IETF https://datatracker.ietf.org/meeting/111/materials/slides-111-spring-srcomp-design-team-update-00 wecan see that CSID is the only column with *all blocks dark green*. Thanks Ahmed On 10/6/21 9:06 AM, Ron Bonica wrote: > > Ahmed, > > I dont recall the DT recommending the CSID. In fact, the word > recommend does not appear anywhere in the analysis document. > > As a member of the DT, I dont recommend CSID. > > Ron > > Juniper Business Use Only > > *From:* spring *On Behalf Of *Ahmed Bashandy > *Sent:* Tuesday, October 5, 2021 10:53 PM > *To:* James Guichard ; SPRING WG > > *Cc:* spring-chairs@ietf.org > *Subject:* Re: [spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > *[External Email. Be cautious of content]* > > I support the adoption of this document. > > * The network programming model (RFC8986) defines multiple > behaviors, CSID is just adding the next and replace flavors > * The draft proposes a single SRv6 based data plane that defines > next and replace behaviors. IMO that is consistent with RFC8986 > > * CSID has been recommended by the design team for SRv6 based > compression > * Interop was done. That is more evidence that CSID is a single data > plane solution > * IMO CSID is ready to become the basis for the SRv6 compression > solution > * Being an SRv6 data plane-based solution, CSID is coherent with the > one data plane solution objective > * CSID meets SRv6 compression requirements as single solution > > Thanks > > Ahmed > > On 10/1/21 7:04 AM, James Guichard wrote: > > Dear WG: > > The chairs would like to express their appreciation for all the > responses received to our emails with reference to how the working > group wishes to move forward with respect to a solution for SRv6 > compression. > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > as the basis for its compression standardization work. That is > part of what this email attempts to confirm. > > Because of the above the chairs would like to issue a 2-week WG > call for adoption ending October 15^th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > but with some clear guidelines as follows. By expressing support > for adoption of this document you are fully aware of and are > acknowledging that: > > 1. The SPRING working group is adopting a document that has > multiple SRv6 Endpoint behaviors. > 2. The document is a living document; it may change as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the > working group to publication. A list of these discussion > points will be documented in the WG document and maintained by > the document editor in conjunction with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text > describing an open issue be added to the document in the > above-described open issues section: > > 1. "Given that the working group has said that it wants to > standardize one data plane solution, and given that the > document contains multiple SRv6 EndPoint behaviors that > some WG members have stated are multiple data plane > solutions, the working group will address whether this is > valid and coherent with its one data plane solution > objective.". > > Please consider the above guidelines as you decide on whether to > support or not this WG adoption. Please express clearly your > reasoning for support/non-support as well as any open discussion > points you would like addressed should the document be adopted > into the working group. > > Thanks! > > Jim, Bruno & Joel > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > --------------8FEA7743CF20C2EDA7E5B3DC Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

If we take a look at the summary table in slide 17 in the DT presentation at last IETF

https://datatracker.ietf.org/meeting/111/materials/slides-111-spring-srcomp-design-team-update-00

we can see that CSID is the only column with *all blocks dark green*.


Thanks

Ahmed




On 10/6/21 9:06 AM, Ron Bonica wrote:

Ahmed,

I dont recall the DT recommending the CSID. In fact, the word recommend does not appear anywhere in the analysis document.

As a member of the DT, I dont recommend CSID.

Ron

Juniper Business Use Only

From: spring <spring-bounces@ietf.org> On Behalf Of Ahmed Bashandy
Sent: Tuesday, October 5, 2021 10:53 PM
To: James Guichard <james.n.guichard@futurewei.com>; SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

[External Email. Be cautious of content]

I support the adoption of this document.

  • The network programming model (RFC8986) defines multiple behaviors, CSID is just adding the next and replace flavors
  • The draft proposes a single SRv6 based data plane that defines next and replace behaviors. IMO that is consistent with RFC8986
  • CSID has been recommended by the design team for SRv6 based compression
  • Interop was done. That is more evidence that CSID is a single data plane solution
  • IMO CSID is ready to become the basis for the SRv6 compression solution
  • Being an SRv6 data plane-based solution, CSID is coherent with the one data plane solution objective
  • CSID meets SRv6 compression requirements as single solution

Thanks

Ahmed

On 10/1/21 7:04 AM, James Guichard wrote:

Dear WG:

The chairs would like to express their appreciation for all the responses received to our emails with reference to how the working group wishes to move forward with respect to a solution for SRv6 compression.

The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardization work. That is part of what this email attempts to confirm.

Because of the above the chairs would like to issue a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that:

  1. The SPRING working group is adopting a document that has multiple SRv6 Endpoint behaviors.
  2. The document is a living document; it may change as it goes through review and analysis by the SPRING working group.
  3. All open discussion points raised on our mailing list MUST be addressed BEFORE said document is allowed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maintained by the document editor in conjunction with the chairs.
  4. If this document is adopted by the working group, the chairs specify as part of the adoption call that the following text describing an open issue be added to the document in the above-described open issues section:
    1. "Given that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this is valid and coherent with its one data plane solution objective.".

Please consider the above guidelines as you decide on whether to support or not this WG adoption. Please express clearly your reasoning for support/non-support as well as any open discussion points you would like addressed should the document be adopted into the working group.

Thanks!

Jim, Bruno & Joel

_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring
--------------8FEA7743CF20C2EDA7E5B3DC-- From nobody Wed Oct 6 10:29:23 2021 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 2F9193A0863; Wed, 6 Oct 2021 10:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, 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 dncKnHq7IJLn; Wed, 6 Oct 2021 10:29:09 -0700 (PDT) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2137.outbound.protection.outlook.com [40.107.93.137]) (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 E5BAD3A081C; Wed, 6 Oct 2021 10:29:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=e4hEY71xl4gpsKucdEapRXvCvhKIYXJdul6xWheHjotq2MRiPdbPQUni++3jVuKzzVtJK/nOCQy5L1DcLBCcRr5SPnZEM4nqlcmt5YxmDZ0oCfoZ6Uw5JEFMsDbfL4E4IuA9Dxg3jbb9ibMy6sb+jshRr/l5KAhxF41nr/w2Pc9VssgIB0VbR0Cl7LJZFWJdkTnW0udaAqsmGESRaf2H88RYZz3v6IDVoeiFS1Ux9zo94wJPsWG/vsq0Ih7DgKwQKHXtGhvOOdE7KNBLtKfTHj0XsWGlZe3y1Iqm2wanLyWUuMEoi5dRtu6z3nqFyRUIcorbz7qwhwbhdLt7r4wEbQ== 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=dcdDendolDOFnALluL041tT8FASNIWDlJG9I84hvB6o=; b=EMiH6MSzHXiyb/AIRv8BXkzT5xfJOL3R3tWlc1M+1VHlC/AEp15biUOjYHcDKMxTSq8FUlPW4In9G/kPFhDUv7hg0o11X71xtabwmPGZnxhJPuDPv8dGcmVyk/Ss7px88vJTfOJMR0cKMnuEM5bwZVX61s6gUIzc+bbse6BvE1FsthmoYOL8NPx4YEwRDWaYtwhtGCZvKEGRcA19KH/x8xqfZN92OrsCmSD7GzPYRn9/QvEXIDnC7vSb5FFZ61KFp7mO1muzUkEAxyaB0J1Vs0Ch6ujsOBvsSsDawsusy33BkbLCBcxL/8rLYKUs/l+hbrr06conFRe3L/fqybi4Hg== 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=dcdDendolDOFnALluL041tT8FASNIWDlJG9I84hvB6o=; b=IshmZoPZku1KkH6ILNSVeVlhNi0Qb3+tDfF8rdydH45IRhTeSVS8gUbVke3nh3l4GZvRieayc2CER8hdAaDFSqReNvczXu3QvMdLF/LfCiC1RK+rozlo5pVxnckLXHMIoaqK9h0ZqSOL68uTUlviBEUjzxzqO1OTD38TXjIPR08= Received: from BY3PR08MB7060.namprd08.prod.outlook.com (2603:10b6:a03:36d::19) by BYAPR08MB4965.namprd08.prod.outlook.com (2603:10b6:a03:64::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.18; Wed, 6 Oct 2021 17:29:04 +0000 Received: from BY3PR08MB7060.namprd08.prod.outlook.com ([fe80::c481:f856:9121:e]) by BY3PR08MB7060.namprd08.prod.outlook.com ([fe80::c481:f856:9121:e%6]) with mapi id 15.20.4566.022; Wed, 6 Oct 2021 17:29:04 +0000 From: "Rabadan, Jorge (Nokia - US/Mountain View)" To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQEC40QF Date: Wed, 6 Oct 2021 17:29:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eb11e1ec-a071-4fba-2e37-08d988eecb80 x-ms-traffictypediagnostic: BYAPR08MB4965: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KI9S2fnME8ehtm2EOooILHWk3l+L40HFm6iXbKsVKdM+8pqRGwvEdyqpz+FT51MHIG+RwaQ+xVBtJgj5GprJslfNpdz3bsii9rUHrDNewbiSbdenuBh51V06aQOlH3POdczYE3ALWJJUgdeMWDRbH5cmM1ssMpNGJt19OnFT6093gWYOJAd2x7IqwYBChFLHd6aHEwX0g7kQVbDf+/3qOTrBFcszEljYpKO/IXn/n7Lq0w6Kj7CDqWkpC9/NeOJbTGVGR9MjAcXITGCMNXrQcFl0MNl9nltjvGlXlB1ubRuiR9w53EbA+nBHL2aHt8wZ2YBPinjNbO/123bbw3YHXRH3400uTVy4FXFUN/xOySE7mxLGq96F9P+6M6hl8rVewut35qlpPQMcYaekCCdhz+TmVooF5iz7n4wFbwyyjzfGruPoyv8CMbP70VXIaUAsRA3CiPUwKyrf+yefY0yp5LR7yVI1wrLQfFbSQ5ykfhCfglfoJGwbXeiRXDzwyNAht60/yXo9uH5kgTOLtVZkeokPXZuykvNwkb3aMT9pWLiKYgkWWz/y+WkkhwLma0U3XEsszgvRgIV/inF/x1fYOVTD/Zt9p1ThJi6ELQW0h0OVnvr7PddPgGQwvPi7d8SdetC0jS3RKpaz11cdF6ILe9h5FExt8sU9FdKwu3m+O5nQsyMUzMxaQhSUDn79Ahw/JbjxxXy5cdxd4XY/vhG3qlLiPpwqdkH4z8ctOLISVXHcu61ZLS4OmrfEdqNY2HykUW6I1pV2vuKpZpvSu475lXuxjdT83vxrmhLbGN39tDY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR08MB7060.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(9686003)(71200400001)(76116006)(64756008)(66556008)(91956017)(66446008)(5660300002)(55016002)(6506007)(66476007)(53546011)(66946007)(166002)(966005)(186003)(110136005)(316002)(7696005)(52536014)(86362001)(33656002)(26005)(38070700005)(83380400001)(8936002)(38100700002)(122000001)(4326008)(8676002)(508600001)(2906002)(9326002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?XdYOdxc6twPKVqNs5i+RtnXrFLiZP/uZyzjuqcdU9W8Loc+hCNqYXwx6?= =?Windows-1252?Q?cNqgVA842eznBd9e/jr5vcV+5akiuwm8GdwX2MEyVNs5R+MM4cQ13P6u?= =?Windows-1252?Q?GPxecczIoTgn1FTRMhPHJTooGkX1jGuaNReKrNP7hz2pWsAIv9SDZrEC?= =?Windows-1252?Q?7Vslg3vjfOGjm8KyTa1zqKrQGtAXhbmYcj4Msf775RZUcYeQqrJaKaVQ?= =?Windows-1252?Q?Tushe8dohhgA0GCK8cEa+ZqPPz1tBxNItqHubjd2P5U9PCV5VfECergB?= =?Windows-1252?Q?i0NUjAfs53e9iwCUrTynx/4kVePSKjmMwEfCAADepTcIGtCWOC1uflH7?= =?Windows-1252?Q?oHnXJbJ8SikpTCCyAKJ3m3jKFPpAIth0f25xOXrzSpla+XXPWXH50aob?= =?Windows-1252?Q?F9KNtAbZ2RgW1Wrpk7gBp+prVnS/qR9ne/zGvS1R2B+WWaUPn+m7yO58?= =?Windows-1252?Q?6SJ7xoXQnh9548/PI5ON7iQIQuP8cOm1mWbNx6kZgKY+hCCMMCy0ksu2?= =?Windows-1252?Q?Cj+qAHGYzt2tHst6PlzUqW2sIpdICgDmLwjJFqluFu1YHNRFiR+fNOiZ?= =?Windows-1252?Q?aGn4ZeyrmXNldP+IE9WRwctZyfslZyjyJwDIMOAHsQJHIxwhRV5/yHug?= =?Windows-1252?Q?3Ue7dbFLB7pVony2/qxBqLJfoYKr0I2M5EiO0CvHicTobqTmRtt1Kc+a?= =?Windows-1252?Q?mzA3CCDXG/Jl9v+Y+ER9wBK4xtmekUpiFjXETUWplvylTiv91Zme7yt6?= =?Windows-1252?Q?n+OjU2YweT0dS8/6MQFNPLlcXgro8bttuCIWC4qLDkm5XClAVFBgL54v?= =?Windows-1252?Q?BByKxKtx5XU0bAdxuxSaKwKAFhJhfgRTB/RZGyPlzFlJCj6A2f09pOA+?= =?Windows-1252?Q?+tzQRGk/B1H9EO16FfL7502EuW6+rnWHDC5+SfTRAWqRfvP/jZ5gDNqM?= =?Windows-1252?Q?xhNevzKsjVtJG+A5p5nBIqYuXCBiBnbHmA2Go/pLefLSsBWIO6gLCObO?= =?Windows-1252?Q?KV0m2u9Wka2229mbkEUVKNrK3sUfo+umDguuyN1aE9pCQFnAKJuVKUcz?= =?Windows-1252?Q?lDzGYa1oIxhOGGwazys0sBdTDj95b9RZW5ItP40iMR5+HpbdNUbjKvZ4?= =?Windows-1252?Q?WI18ZtYHGbGrktH3pQBM2UX2fuJ7poBbO1M79i8f6vZYlhIMovAiBttm?= =?Windows-1252?Q?2aFUCuf6V+5Xve6A6hpJgZ3Iq7z68SDXsZoxe0l5qZdIGQNzfQYP4yCN?= =?Windows-1252?Q?YR1/Ye/tWSbY//NPB5p9iy+UF1jVRyQISVDKBA5lbP+l3JxGlpQqbki2?= =?Windows-1252?Q?p+AB8K6wTjHTxCQXCUAG85pd8GYLtTfacHcehDGCYK5o4XlbBzanye92?= =?Windows-1252?Q?KlT7JGbnL5Hfc5WOvaOm+QlMQpiNS2yKUSthDBzYR9hZEe1VfX9UbYAe?= =?Windows-1252?Q?afEFF/WL/2ChIMvvZUhu5A=3D=3D?= Content-Type: multipart/alternative; boundary="_000_BY3PR08MB7060BE0D3E4A2E606B729997F7B09BY3PR08MB7060namp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR08MB7060.namprd08.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: eb11e1ec-a071-4fba-2e37-08d988eecb80 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Oct 2021 17:29:04.5463 (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: WeQBBvnVtmlYDpgnTjMtB5LbPG0VQjBmhybevA8OZM4ljINleffdNA8po5sQHCc+02RjQwdmInQvwt+gqz9jZQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB4965 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 06 Oct 2021 17:29:22 -0000 --_000_BY3PR08MB7060BE0D3E4A2E606B729997F7B09BY3PR08MB7060namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, I support this document for WG adoption, based on the results of the analys= is draft. Thanks. Jorge From: spring on behalf of James Guichard Date: Friday, October 1, 2021 at 4:05 PM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple = SRv6 Endpoint behaviors. 2. The document is a =93living=94 document; it may change as it goes = through review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be addr= essed BEFORE said document is allowed to progress from the working group to= publication. A list of these discussion points will be documented in the W= G document and maintained by the document editor in conjunction with the ch= airs. 4. If this document is adopted by the working group, the chairs speci= fy as part of the adoption call that the following text describing an open = issue be added to the document in the above-described open issues section: =B7 "Given that the working group has said that it wants to standar= dize one data plane solution, and given that the document contains multiple= SRv6 EndPoint behaviors that some WG members have stated are multiple data= plane solutions, the working group will address whether this is valid and = coherent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_BY3PR08MB7060BE0D3E4A2E606B729997F7B09BY3PR08MB7060namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi,

 

I support this document for WG adoption, based on the results of the anal= ysis draft.

 

Thanks.

Jorge

 

From: spring <spring-bounces@ietf.org> o= n behalf of James Guichard <james.n.guichard@futurewei.com>
Date: Friday, October 1, 2021 at 4:05 PM
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

 

The chairs would like t= o express their appreciation for all the responses received to our emails w= ith reference to how the working group wishes to move forward with respect = to a solution for SRv6 compression.

 

The apparent inclinatio= n of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above th= e chairs would like to issue a 2-week WG call for adoption ending October 1= 5th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

1.       The SPRING working group is adopting a document tha= t has multiple SRv6 Endpoint behaviors.

2.       The document is a =93living=94 document; it may cha= nge as it goes through review and analysis by the SPRING working group.

3.       All open discussion points raised on our mailing li= st MUST be addressed BEFORE said document is allowed to progress from the w= orking group to publication. A list of these discussion points will be docu= mented in the WG document and maintained by the document editor in conjunction with the chairs.

4.       If this document is adopted by the working group, t= he chairs specify as part of the adoption call that the following text desc= ribing an open issue be added to the document in the above-described open i= ssues section:

=B7&nbs= p;        "Given that the working group has said = that it wants to standardize one data plane solution, and given that the do= cument contains multiple SRv6 EndPoint behaviors that some WG members have = stated are multiple data plane solutions, the working group will address whether this is valid and coherent with its= one data plane solution objective.".

 

Please consider the abo= ve guidelines as you decide on whether to support or not this WG adoption. = Please express clearly your reasoning for support/non-support as well as an= y open discussion points you would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

--_000_BY3PR08MB7060BE0D3E4A2E606B729997F7B09BY3PR08MB7060namp_-- From nobody Wed Oct 6 11:26:36 2021 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 391AF3A0115 for ; Wed, 6 Oct 2021 11:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=uniroma2.it header.b=GER4j1Tc; dkim=pass (2048-bit key) header.d=uniroma2.it header.b=IyVUoFlw 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 6eOAF7yobrVa for ; Wed, 6 Oct 2021 11:26:28 -0700 (PDT) Received: from smtp.uniroma2.it (smtp.uniroma2.it [160.80.6.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 082A63A00E2 for ; Wed, 6 Oct 2021 11:26:25 -0700 (PDT) Received: from smtpauth-2019-1.uniroma2.it (smtpauth.uniroma2.it [160.80.5.46]) by smtp-2015.uniroma2.it (8.14.4/8.14.4/Debian-8) with ESMTP id 196IQHFX013057 for ; Wed, 6 Oct 2021 20:26:22 +0200 Received: from [192.168.1.85] (93-41-113-141.ip81.fastwebnet.it [93.41.113.141]) by smtpauth-2019-1.uniroma2.it (Postfix) with ESMTPSA id E7C8C1205A3 for ; Wed, 6 Oct 2021 20:26:12 +0200 (CEST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=uniroma2.it; s=ed201904; t=1633544773; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ipqqR3WhZ/WbYdNAf4ifLmXoQAjnCzKIg+3OBlXUq5I=; b=GER4j1Tcru5QDXgDtG/lHhWKICgM4OiN+h/MOlHDfKdS4PY9Kiz9urlHEDp7ZnOFmiJset BqguU6CknBBDYnBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniroma2.it; s=rsa201904; t=1633544773; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ipqqR3WhZ/WbYdNAf4ifLmXoQAjnCzKIg+3OBlXUq5I=; b=IyVUoFlwzc1S1wuvF3uZ7vhenLhPI/tt0pGSqCXmePhOx2cefaXUzhsNkudUygXphYrYPv 4tZt/KU7wFhFsEwICObU7tn0wufkkYei327gy0y3bDkeOGzb5j+CrjleyybRJIT9jdoVUf vaz4duzn9aSffmqAItI7zcSUFCiDnZv+b4g8rRTkCeDli1hJVfH/Ah+OLOT9If4Jp6ynFs c2ZsuQgPNydUffioQJsfayvKH3lZPs0G07FIxmENzQtpoMBLqkL9jCRn4vxTxmldEBOhdH 2AX2WCr0ziBXGZdWpXbhyYOmL2gvdtMU5heZm47ZM3bj+yKeUIBP0GVNZfQlxw== To: spring@ietf.org References: From: Stefano Salsano Message-ID: Date: Wed, 6 Oct 2021 20:26:01 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: it-IT Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.0 at smtp-2015 X-Virus-Status: Clean Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 06 Oct 2021 18:26:34 -0000 Hi, I support the adoption of draft-filsfilscheng-spring-srv6-srh-compression the draft is compliant with the RFC 8986 and adds two new flavors to the End behavior with my research team, I've been working on the design and implementation of the SRv6 network programming model (RFC 8986) on the Linux OS, we're currently implementing the framework to support the flavors defined in RFC 8986 from our point of view, the two new flavors clearly belong to the same SRv6 dataplane and can be implemented "side by side" in the SRv6 Linux implementation ciao Stefano Il 2021-10-01 16:04, James Guichard ha scritto: > Dear WG: > > The chairs would like to express their appreciation for all the > responses received to our emails with reference to how the working group > wishes to move forward with respect to a solution for SRv6 compression. > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > as the basis for its compression standardization work. That is part of > what this email attempts to confirm. > > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15^th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging > that: > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a living document; it may change as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the > working group to publication. A list of these discussion points will > be documented in the WG document and maintained by the document > editor in conjunction with the chairs. > 4. If this document is adopted by the working group, the chairs specify > as part of the adoption call that the following text describing an > open issue be added to the document in the above-described open > issues section: > * "Given that the working group has said that it wants to > standardize one data plane solution, and given that the document > contains multiple SRv6 EndPoint behaviors that some WG members > have stated are multiple data plane solutions, the working group > will address whether this is valid and coherent with its one > data plane solution objective.". > > Please consider the above guidelines as you decide on whether to support > or not this WG adoption. Please express clearly your reasoning for > support/non-support as well as any open discussion points you would like > addressed should the document be adopted into the working group. > > Thanks! > > Jim, Bruno & Joel > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > -- ******************************************************************* Stefano Salsano Professore Associato Dipartimento Ingegneria Elettronica Universita' di Roma Tor Vergata Viale Politecnico, 1 - 00133 Roma - ITALY http://netgroup.uniroma2.it/Stefano_Salsano/ E-mail : stefano.salsano@uniroma2.it Cell. : +39 320 4307310 Office : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435 ******************************************************************* From nobody Thu Oct 7 02:03:56 2021 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 E3B9B3A0C5F; Thu, 7 Oct 2021 02:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4XLJeYz_u-xy; Thu, 7 Oct 2021 02:03:37 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (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 0DFB73A0BB0; Thu, 7 Oct 2021 02:03:37 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id b20so22329070lfv.3; Thu, 07 Oct 2021 02:03:36 -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=62TWZz9p+rDZqkufY3nYBhvmnToRBHyHCeloJbjaFqQ=; b=Nk72onh2j1dEcCNfJDVkHLf+24log6fkgVbZzWiBdJKS54VEno8cc9KR+tgb/rU7Ug dFxDB/OZoZHYcEI4DTpHRpZhM+x8rruCaYtb+E80uwNQvNZ/XQKFqO9s5xmTpiOIW52g vHmfW8Nwv6QqF3KALY7hLnDj9Zu99y9EF4cBiaJ5Jh1MSAgojsR2MqqDqHkgIlGymKBF fMpdx9Aea/P1pNeuFu0/J5hBB873OqKAlnFRBPXivs7/rfI9H3zu2hkitPrHWCe0PhUJ 1upqkD4uTMdQILB1tBqWRRZNaaZeWWef3OUwQqVsqBZ0VBMlvcDQIAtFlvMXbFzeRh1F 5BRA== 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=62TWZz9p+rDZqkufY3nYBhvmnToRBHyHCeloJbjaFqQ=; b=cbxMMRmxMF41SoijaA4a1znjLIZ8lIsTmeoV32a5yC0uBbEMKwKUuXUBr03L8ercYx /Srx6vNMR0iUhS+b+gfz61LsKFkm0g4F/TIInAryu2cIQkNdl1jAk1XUva5RjKYlAy2K idZe/gm6lcDJcUEYlRBUQn69mz4dBZgtCMm3OUjsZTJxuEDMbKT/VAA+BfmVALf7xOVj BMM54UDuZQWpx79B21FR0Q0YPVl55NMG0QJBkrrEerNte8WtuyPHBdNrHWrspGVd3jE6 W1cj+4O4Ml3pZFIx2/VSMpiP2m78zOojEoMOtUdFDlZ/GbEx0ikIb3roFHyARiZAFOf6 loNw== X-Gm-Message-State: AOAM5329JN+PmbeTNUuvCsOlM/JM/YPd8cexqT2/hgFZ3a76+sxTYJDr ko78fg4KzpWfnNVYH/LRPZrKDYaLc0ift9ElTD/ZEkzx X-Google-Smtp-Source: ABdhPJwFWAafhGRMTQYBOaNZsApYQjHoCtAg4seGKjDBjsh33sY1ZYKb/yTUhCvsyaTOcfDTQ+1FSyGxdKM6pfsDBUc= X-Received: by 2002:a2e:a815:: with SMTP id l21mr3398282ljq.164.1633597414872; Thu, 07 Oct 2021 02:03:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eduard Metz Date: Thu, 7 Oct 2021 11:03:25 +0200 Message-ID: To: Ron Bonica Cc: "6man@ietf.org" <6man@ietf.org>, SPRING WG Content-Type: multipart/alternative; boundary="0000000000009e9a7705cdbf89d8" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 07 Oct 2021 09:03:53 -0000 --0000000000009e9a7705cdbf89d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Can the SID be viewed as the address of the "interface" to, in this case, the function that resides in a node? From a routing / forwarding point of view the group of functions is more similar to a network (represented by a prefix, rather than a single address), but still. For my understanding, apart from that the (definition of) SID may not be aligned with the literal text in below RFCs, what is the real problem? Are there any protocols that specifically rely on this definition of an IPv6 address? cheers, Eduard On Tue, Oct 5, 2021 at 6:59 PM Ron Bonica wrote: > Folks, > > > > In a private communication, someone asked for specific references to RFCs > 8200 and 4291 that were difficult to harmonize with > draft-filsfilscheng-spring-srv6-srh-compression. References follow: > > > > Section 3 of RFC 8200 > ----------------------------- > > =E2=80=9CThe Destination Address field of the IPv6 header contains the = =E2=80=9C128-bit > address of the intended recipient of the packet (possibly not the ultimat= e > recipient, if a Routing header is present). See [RFC4291] and Section 4.= 4.=E2=80=9D > > > > Section 2 of RFC 4291 > > ----------------------------- > > =E2=80=9CIPv6 addresses are 128-bit identifiers for interfaces and sets o= f > interfaces (where "interface" is as defined in Section 2 of [RFC8200])=E2= =80=9D. > > > > Section 2 of RFC 8200 > > ------------------------------ > > - An interface is =E2=80=9Ca node's attachment to a link=E2=80=9D > - A link is =E2=80=9Ca communication facility or medium over which nod= es can > communicate at the link layer, i.e., the layer immediately below IPv6.= =E2=80=9D > > > > So, an IPv6 Destination Address represents a single thing that is > instantiated on a single node. > > > > According to draft-filsfilscheng-spring-srv6-srh-compression-02, A > Compressed-SID container (C-SID container) is =E2=80=9Can entry of the SR= H > Segment-List field (128 bits) that contains a sequence of C-SIDs.=E2=80= =9D A C-SID > is =E2=80=9Ca C-SID is a short encoding of a SID in SRv6 packet that doe= s not > include the SID block bits (locator block).=E2=80=9D > > > > According to RFC 8896, a SID identifies an instruction on a node. > > > > And finally, according to > draft-filsfilscheng-spring-srv6-srh-compression-02, an SRv6 node can copy= a > container C-SID to the Destination Address fieldd of theIPv6 header. > > > > When this happens, the IPv6 Destination Address doesn=E2=80=99t represent= a single > thing on a single node. It represents an entire SR path. > > > > > Ron > > > > > > > > Juniper Business Use Only > > *From:* Ron Bonica > *Sent:* Friday, October 1, 2021 4:35 PM > *To:* 6man@ietf.org > *Cc:* SPRING WG > *Subject:* draft-filsfilscheng-spring-srv6-srh-compression-02 > > > > Folks, > > > > Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new > SID types that can occupy the Destination Address field of an IPv6 header= . > See Sections 4.1, 4.2, and 4.3 of the draft for details. > > > > The SPRING WG has issued a call for adoption for this draft. > > > > It is not clear that these SID types can be harmonized with the IPv6 > addressing architecture. > > > > Does anyone have an opinion? > > > > > = Ron > > > > > > Juniper Business Use Only > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --0000000000009e9a7705cdbf89d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Can the SID be viewed as the address of the "= ;interface" to, in this case, the function that resides in a node? Fro= m a routing / forwarding point=C2=A0of view the group of functions is more = similar to a network (represented by a prefix, rather than a single address= ), but still.

For my understanding, apart from tha= t the (definition of) SID may not be aligned with the literal text in below= RFCs, what is the real problem? Are there any protocols that specifically = rely on this definition of an IPv6 address?

cheers= ,
=C2=A0 Eduard

On Tue, Oct 5, 2021 at 6:59 PM Ron Bonica &l= t;rbonica=3D40juniper.net@d= marc.ietf.org> wrote:

Folks,<= /span>

=C2=A0<= /span>

In a private communic= ation, someone asked for specific references to RFCs 8200 and 4291 that wer= e difficult to harmonize with draft-filsfilscheng-spring-srv6-srh-compressi= on. References follow:

=C2=A0<= /span>

Section 3 of RFC 8200=
-----------------------------

=E2=80=9CThe Destinat= ion Address field of the IPv6 header contains the =E2=80=9C128-bit address = of the intended recipient of the packet (possibly not the ultimate recipien= t, if a Routing header is present).=C2=A0 See [RFC4291] and Section 4.4.=E2=80=9D

=C2=A0<= /span>

Section 2 of RFC 4291=

---------------------= --------

=E2=80=9CIPv6 address= es are 128-bit identifiers for interfaces and sets of interfaces (where &qu= ot;interface" is as defined in Section 2 of [RFC8200])=E2=80=9D.

=C2=A0<= /span>

Section 2 of RFC 8200=

---------------------= ---------

  • An interface is =E2=80=9Ca node'= s attachment to a link=E2=80=9D
  • A link is =E2=80=9Ca communication facility or medium = over which nodes can communicate at the link layer, i.e., the layer immedia= tely below IPv6.=E2=80=9D

=C2=A0<= /span>

So, an IPv6 Destinati= on Address represents a single thing that is instantiated on a single node.=

=C2=A0<= /span>

According to draft-fi= lsfilscheng-spring-srv6-srh-compression-02, A Compressed-SID container (C-S= ID container) is =E2=80=9Can entry of the SRH Segment-List field (128 bits)= that contains a sequence of C-SIDs.=E2=80=9D A C-SID is =E2=80=9Ca =C2=A0C-SID is a short encoding of a SID in SRv6 packet that= does not include the SID block bits (locator block).=E2=80=9D

=C2=A0<= /span>

According to RFC =C2= =A08896, a SID identifies an instruction on a node.

=C2=A0<= /span>

And finally, accordin= g to draft-filsfilscheng-spring-srv6-srh-compression-02, an SRv6 node can c= opy a container C-SID to the =C2=A0Destination Address fieldd of theIPv6 he= ader.

=C2=A0<= /span>

When this happens, th= e IPv6 Destination Address doesn=E2=80=99t represent a single thing on a si= ngle node. It represents an entire SR path.

=C2=A0<= /span>

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 Ron

=C2=A0<= /span>

=C2=A0<= /span>

=C2=A0

Juniper Business Use Only<= u>

From: Ron Bonica
Sent: Friday, October 1, 2021 4:35 PM
To: 6man@ietf.org=
Cc: SPRING WG <spring@ietf.org>
Subject: draft-filsfilscheng-spring-srv6-srh-compression-02

=C2=A0

Folks,<= /span>

=C2=A0<= /span>

Draft-filsfilscheng-s= pring-srv6-srh-compression-02 introduces three new SID types that can occup= y the Destination Address field of an IPv6 header. See Sections 4.1, 4.2, a= nd 4.3 of the draft for details.

=C2=A0<= /span>

The SPRING WG has iss= ued a call for adoption for this draft.

=C2=A0<= /span>

It is not clear that = these SID types can be harmonized with the IPv6 addressing architecture.=

=C2=A0<= /span>

Does anyone have an o= pinion?

=C2=A0<= /span>

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0Ron

=C2=A0<= /span>

=C2=A0

Juniper Business Use Only<= u>

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--0000000000009e9a7705cdbf89d8-- From nobody Thu Oct 7 03:14:35 2021 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 C96C23A0CB7; Thu, 7 Oct 2021 03:14:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 2qFQytbIRyA4; Thu, 7 Oct 2021 03:14:15 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178913A0CBA; Thu, 7 Oct 2021 03:14:14 -0700 (PDT) X-Envelope-To: spring@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 197AE7hR032386 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Oct 2021 11:14:08 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local To: Eduard Metz Cc: Ron Bonica , SPRING WG , "6man@ietf.org" <6man@ietf.org> References: From: Nick Hilliard Message-ID: <86741e64-eef2-6395-afd7-62764d9f5c41@foobar.org> Date: Thu, 7 Oct 2021 11:14:06 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.49 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 07 Oct 2021 10:14:17 -0000 Eduard Metz wrote on 07/10/2021 10:03: > For my understanding, apart from that the (definition of) SID may not be > aligned with the literal text in below RFCs, what is the real problem? the concept of an ipv6 destination address is deeply ingrained in the ipv6 protocol. So, looking at this from a deployment point of view, why does an expediency of the sort suggested in this draft justify changing the semantics of one of the cornerstones of the ipv6 protocol? The authors would need to justify this protocol modification on the same sort of basis that any other ID might be expected to do. E.g. for starters, including an analysis of how this would impact or potentially impact any other RFC which references or implicitly depends on currently-defined ipv6 addressing semantics. Nick From nobody Thu Oct 7 03:32:30 2021 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 734353A0DA3 for ; Thu, 7 Oct 2021 03:32:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 phiasCPTbJCV for ; Thu, 7 Oct 2021 03:32:07 -0700 (PDT) Received: from mail-vs1-xe2e.google.com (mail-vs1-xe2e.google.com [IPv6:2607:f8b0:4864:20::e2e]) (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 9CB213A0DA8 for ; Thu, 7 Oct 2021 03:32:07 -0700 (PDT) Received: by mail-vs1-xe2e.google.com with SMTP id o15so1386380vsr.13 for ; Thu, 07 Oct 2021 03:32:07 -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=m/rNDa8t3md1HGf6XOaitHzEih77kidOpCUAxAb0jKg=; b=MuB8uN6qK6ZZj3AkS6RnaSCFPU1lyGoLKN8Xar7qsk7OFQ6aWVPHJgkubHG8uFWeHj Vh0B44A3V84c3pPllQ67mB9ZXjsffL/SIDOkjuuM2mZQmz45wGHuAy+UhNE8qZBcCOpm i0XJvHekZpuE/ikuBFGkcz1SSnX17CLcOwK2bclZ0MAy67Yyq/0MA1VvcVZttzzVgm2s 6FNi/nIK/1uGV6SFC6P1wmYOYyK+PG22uBCNq0H9aXYSQEQjHzbLxZGnj2FxZdZCNQk3 BpvaiuNQFfn5DVnwG9GF55VR/inwEkZNBbgAgmoodXC0Lbk+RCBwrHnj9ieBz/xz/Bnf gwNg== 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=m/rNDa8t3md1HGf6XOaitHzEih77kidOpCUAxAb0jKg=; b=2L/KTdDcNkFvBEBpkj9BBiih4DWVUrNjDgpPF4SsMEWyLjJONJMBRmiALGTjTY1UEC mDRGLevXULNdPRXoE0HNn0nl1C2ctq4C2W4ptOKoh4H5rgqFmnPLkyx7b4AR/l/zjPip 3x/9VUpxfOkBuzFQ3lZktVl+YfXWI1zvudfWopaY0iOWX4K4VxNG/e1mRgzHy2TAFVbu vfmQk+lTIfBOqkA1GwxxVU/Sjrp4+5d1b82UkmByAZdBavidwYoEnLJ+csAbBQ4qUInP 45HEfPXcZxW4mueZpXtEVD+/PiKRODAaTO7e/uo6VVf9GZZOEAVUE6MHLdY7c1CMZ8kw c3wg== X-Gm-Message-State: AOAM530URJQz5+MIebByYBrDDM+ub5L1EijrVlGr/Gfrb/cvaKrsPDvE tJl0ZOE7TuPYwoR/xXfpvfFhI+5eIPO+YnB/RjM5Hg== X-Google-Smtp-Source: ABdhPJx+4t1RP1nsUhs+yGx0udcCQPItGp0sgkY3wFBa+3j5hRtALXrzASdG/rOYXD42Vh6MXUWj7tBSs3hoh+sYRQQ= X-Received: by 2002:a05:6102:2333:: with SMTP id b19mr3122976vsa.0.1633602726265; Thu, 07 Oct 2021 03:32:06 -0700 (PDT) MIME-Version: 1.0 References: <86741e64-eef2-6395-afd7-62764d9f5c41@foobar.org> In-Reply-To: <86741e64-eef2-6395-afd7-62764d9f5c41@foobar.org> From: Robert Raszuk Date: Thu, 7 Oct 2021 12:32:00 +0200 Message-ID: To: Nick Hilliard Cc: Eduard Metz , Ron Bonica , SPRING WG , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="0000000000003419a405cdc0c665" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 07 Oct 2021 10:32:14 -0000 --0000000000003419a405cdc0c665 Content-Type: text/plain; charset="UTF-8" Nick, Ok let's zoom on your point. *IPv6 Addressing Architecture RFC says: * IPv6 addresses are 128-bit identifiers for interfaces and sets of interfaces (where "interface" is as defined in Section 2 of [IPV6]). There are three types of addresses: Unicast: An identifier for a single interface. A packet sent to a unicast address is delivered to the interface identified by that address. So what is left to check is what the definition of the "interface" is. Some folks refer to the definition of the interface as stated verbatim in *RFC2460/RFC8200: * 2. Terminology interface - a node's attachment to a link. *However we all know that outside of IPv6, SRv6 there are many more types of interfaces which are not attached to any link. We use them every day. * *RFC7223* did decent job trying to capture what the interface means and divided the interfaces into system defined and user defined: 1.1. Terminology The following terms are used within this document: o system-controlled interface: An interface is said to be system- controlled if the system creates and deletes the interface independently of what has been explicitly configured. Examples are interfaces representing physical hardware that appear and disappear when hardware (e.g., a line card or hot-pluggable wireless interface) is added or removed. System-controlled interfaces may also appear if a certain functionality is enabled (e.g., a loopback interface might appear if the IP protocol stack is enabled). o user-controlled interface: An interface is said to be user- controlled if the creation of the interface is controlled by adding explicit interface configuration to the running configuration datastore and the removal of the interface is controlled by removing explicit interface configuration from the running configuration datastore. Examples are VLAN interfaces configured on a system-controlled Ethernet interface. So please let's consider reality here, not some badly defined dogmas from the stone age. And if we will, then the SRv6 destination address is the address of a special virtual interface in the system. The meaning of the bits outside of the routable prefix is up to the interface creator. If that single sentence is missing in any spec it can be added but to me this is obvious. Cheers, R. On Thu, Oct 7, 2021 at 12:14 PM Nick Hilliard wrote: > Eduard Metz wrote on 07/10/2021 10:03: > > For my understanding, apart from that the (definition of) SID may not be > > aligned with the literal text in below RFCs, what is the real problem? > > the concept of an ipv6 destination address is deeply ingrained in the > ipv6 protocol. So, looking at this from a deployment point of view, why > does an expediency of the sort suggested in this draft justify changing > the semantics of one of the cornerstones of the ipv6 protocol? > > The authors would need to justify this protocol modification on the same > sort of basis that any other ID might be expected to do. E.g. for > starters, including an analysis of how this would impact or potentially > impact any other RFC which references or implicitly depends on > currently-defined ipv6 addressing semantics. > > Nick > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --0000000000003419a405cdc0c665 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Nick,

Ok let's zoom on your point.= =C2=A0

IPv6=C2=A0=C2=A0Addressing Architecture = RFC says:=C2=A0

IPv6 a= ddresses are 128-bit identifiers for interfaces and sets of
=C2=A0 =C2= =A0interfaces (where "interface" is as defined in Section 2 of [I= PV6]).
=C2=A0 =C2=A0There are three types of addresses:

=C2=A0 = =C2=A0 Unicast: =C2=A0 An identifier for a single interface.=C2=A0 A packet= sent to a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unicas= t address is delivered to the interface identified
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by that address.
So what is left to check is what the definition of the "in= terface" is.=C2=A0

Some folks refer to the de= finition of the interface as stated=C2=A0verbatim in RFC2460/RFC8200:=C2= =A0

2.=C2=A0 Terminolo= gy

=C2=A0 =C2=A0interface =C2=A0 - a node's attachment to a link= .

However we all know that outside o= f IPv6, SRv6 there are many more types of interfaces which are not attached= to any link. We use them every day.=C2=A0

= RFC7223 did decent job trying to capture what the interface means and d= ivided the interfaces into system defined and user defined:=C2=A0

1.1.= =C2=A0 Terminology

=C2=A0 =C2=A0The following terms are used within = this document:

=C2=A0 =C2=A0o =C2=A0system-controlled interface: An = interface is said to be system-
=C2=A0 =C2=A0 =C2=A0 controlled if the s= ystem creates and deletes the interface
=C2=A0 =C2=A0 =C2=A0 independent= ly of what has been explicitly configured.=C2=A0 Examples
=C2=A0 =C2=A0 = =C2=A0 are interfaces representing physical hardware that appear and
=C2= =A0 =C2=A0 =C2=A0 disappear when hardware (e.g., a line card or hot-pluggab= le
=C2=A0 =C2=A0 =C2=A0 wireless interface) is added or removed.=C2=A0 S= ystem-controlled
=C2=A0 =C2=A0 =C2=A0 interfaces may also appear if a ce= rtain functionality is enabled
=C2=A0 =C2=A0 =C2=A0 (e.g., a loopback in= terface might appear if the IP protocol stack
=C2=A0 =C2=A0 =C2=A0 is en= abled).

=C2=A0 =C2=A0o =C2=A0user-controlled interface: An interface= is said to be user-
=C2=A0 =C2=A0 =C2=A0 controlled if the creation of = the interface is controlled by
=C2=A0 =C2=A0 =C2=A0 adding explicit inte= rface configuration to the running
=C2=A0 =C2=A0 =C2=A0 configuration da= tastore and the removal of the interface is
=C2=A0 =C2=A0 =C2=A0 control= led by removing explicit interface configuration from the
=C2=A0 =C2=A0 = =C2=A0 running configuration datastore.=C2=A0 Examples are VLAN interfaces<= br>=C2=A0 =C2=A0 =C2=A0 configured on a system-controlled Ethernet interfac= e.


So please let's c= onsider reality here, not some badly defined=C2=A0dogmas=C2=A0from the ston= e age.=C2=A0

And if we will, then the SRv6 des= tination address is the address of a special virtual interface in the syste= m. The meaning of the bits outside of the routable prefix is up to the inte= rface creator.=C2=A0

If that single sentence is mi= ssing in any spec it can be added but to me this is obvious.=C2=A0

Cheers,
R.


On Thu, Oct 7, 20= 21 at 12:14 PM Nick Hilliard <nick@fo= obar.org> wrote:
Eduard Metz wrote on 07/10/2021 10:03:
> For my understanding, apart from that the (definition of) SID may not = be
> aligned with the literal text in below RFCs, what is the real problem?=

the concept of an ipv6 destination address is deeply ingrained in the
ipv6 protocol.=C2=A0 So, looking at this from a deployment point of view, w= hy
does an expediency of the sort suggested in this draft justify changing the semantics of one of the cornerstones of the ipv6 protocol?

The authors would need to justify this protocol modification on the same sort of basis that any other ID might be expected to do.=C2=A0 E.g. for starters, including an analysis of how this would impact or potentially impact any other RFC which references or implicitly depends on
currently-defined ipv6 addressing semantics.

Nick

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
--------------------------------------------------------------------
--0000000000003419a405cdc0c665-- From nobody Thu Oct 7 03:47:55 2021 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 154D53A0DBF; Thu, 7 Oct 2021 03:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vW7Sy2uQVCnN; Thu, 7 Oct 2021 03:47:47 -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 0B0E13A0DBA; Thu, 7 Oct 2021 03:47:47 -0700 (PDT) Received: from fraeml702-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HQ7Gy3qYpz67Y1v; Thu, 7 Oct 2021 18:44:10 +0800 (CST) Received: from mscpeml500002.china.huawei.com (7.188.26.138) 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.2308.8; Thu, 7 Oct 2021 12:47:43 +0200 Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml500002.china.huawei.com (7.188.26.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Thu, 7 Oct 2021 13:47:42 +0300 Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2308.008; Thu, 7 Oct 2021 13:47:42 +0300 From: Vasilenko Eduard To: Robert Raszuk , Nick Hilliard CC: Ron Bonica , SPRING WG , "6man@ietf.org" <6man@ietf.org> Thread-Topic: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 Thread-Index: Ade3AXyWK2NzAamgSlCvJ497z/5RLwC/aCkQAFB7QYAAAnf1AAAAoAoAAAaRCeA= Date: Thu, 7 Oct 2021 10:47:42 +0000 Message-ID: <07de7dc0acaf467d84681e5caf7f9785@huawei.com> References: <86741e64-eef2-6395-afd7-62764d9f5c41@foobar.org> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.206.175] Content-Type: multipart/alternative; boundary="_000_07de7dc0acaf467d84681e5caf7f9785huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 07 Oct 2021 10:47:53 -0000 --_000_07de7dc0acaf467d84681e5caf7f9785huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGF0YSBwbGFuZSDigJxQcm9ncmFtbWFiaWxpdHnigJ0gaW4gcHJpbmNpcGxlIHNob3VsZCBiZSBk aXNjYXJkZWQNCklmIHRoZSBhZGRyZXNzIGlzIG9ubHkg4oCcYSBub2RlJ3MgYXR0YWNobWVudCB0 byBhIGxpbmvigJ0uDQpJIGRvIG5vdCB3YW50IHRvIG1lbnRpb24g4oCcbG9jYXRvcuKAnSBhbmQg 4oCcYXJndW1lbnTigJ0gYmVjYXVzZSBhbnkgcHJvZ3JhbW1hYmlsaXR5IGlzIGJsb2NrZWQgYnkg c3VjaCBhZGRyZXNzIGRlZmluaXRpb24uDQpJIGhvcGUgd2UgZG8gbm90IHdhbnQgdG8gbW92ZSBl dmVyeXRoaW5nIHRvIHRoZSBjb250cm9sIHBsYW5lIGFnYWluLg0KSXQgd2FzIGEgbmljZSBpZGVh IHRvIHNoaWZ0IHN0YXRlcyBmcm9tIHRoZSBjb250cm9sIHBsYW5lIGFuZCBmb3J3YXJkaW5nIHRh YmxlcyB0byB0aGUgcGFja2V0IGl0c2VsZi4NClRoZSBjYWxsIHRvIGZvbGxvdyDigJxhIG5vZGUn cyBhdHRhY2htZW50IHRvIGEgbGlua+KAnSBydWxlIGlzIHNvbWVob3cgZXF1aXZhbGVudCB0byDi gJxjbG9zZSBTUFJJTkcgd2figJ0uDQpFZC8NCkZyb206IGlwdjYgW21haWx0bzppcHY2LWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb2JlcnQgUmFzenVrDQpTZW50OiBUaHVyc2RheSwg T2N0b2JlciA3LCAyMDIxIDE6MzIgUE0NClRvOiBOaWNrIEhpbGxpYXJkIDxuaWNrQGZvb2Jhci5v cmc+DQpDYzogUm9uIEJvbmljYSA8cmJvbmljYT00MGp1bmlwZXIubmV0QGRtYXJjLmlldGYub3Jn PjsgU1BSSU5HIFdHIDxzcHJpbmdAaWV0Zi5vcmc+OyA2bWFuQGlldGYub3JnDQpTdWJqZWN0OiBS ZTogW3NwcmluZ10gZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Np b24tMDINCg0KTmljaywNCg0KT2sgbGV0J3Mgem9vbSBvbiB5b3VyIHBvaW50Lg0KDQpJUHY2ICBB ZGRyZXNzaW5nIEFyY2hpdGVjdHVyZSBSRkMgc2F5czoNCg0KSVB2NiBhZGRyZXNzZXMgYXJlIDEy OC1iaXQgaWRlbnRpZmllcnMgZm9yIGludGVyZmFjZXMgYW5kIHNldHMgb2YNCiAgIGludGVyZmFj ZXMgKHdoZXJlICJpbnRlcmZhY2UiIGlzIGFzIGRlZmluZWQgaW4gU2VjdGlvbiAyIG9mIFtJUFY2 XSkuDQogICBUaGVyZSBhcmUgdGhyZWUgdHlwZXMgb2YgYWRkcmVzc2VzOg0KDQogICAgVW5pY2Fz dDogICBBbiBpZGVudGlmaWVyIGZvciBhIHNpbmdsZSBpbnRlcmZhY2UuICBBIHBhY2tldCBzZW50 IHRvIGENCiAgICAgICAgICAgICAgIHVuaWNhc3QgYWRkcmVzcyBpcyBkZWxpdmVyZWQgdG8gdGhl IGludGVyZmFjZSBpZGVudGlmaWVkDQogICAgICAgICAgICAgICBieSB0aGF0IGFkZHJlc3MuDQoN ClNvIHdoYXQgaXMgbGVmdCB0byBjaGVjayBpcyB3aGF0IHRoZSBkZWZpbml0aW9uIG9mIHRoZSAi aW50ZXJmYWNlIiBpcy4NCg0KU29tZSBmb2xrcyByZWZlciB0byB0aGUgZGVmaW5pdGlvbiBvZiB0 aGUgaW50ZXJmYWNlIGFzIHN0YXRlZCB2ZXJiYXRpbSBpbiBSRkMyNDYwL1JGQzgyMDA6DQoNCjIu ICBUZXJtaW5vbG9neQ0KDQogICBpbnRlcmZhY2UgICAtIGEgbm9kZSdzIGF0dGFjaG1lbnQgdG8g YSBsaW5rLg0KDQpIb3dldmVyIHdlIGFsbCBrbm93IHRoYXQgb3V0c2lkZSBvZiBJUHY2LCBTUnY2 IHRoZXJlIGFyZSBtYW55IG1vcmUgdHlwZXMgb2YgaW50ZXJmYWNlcyB3aGljaCBhcmUgbm90IGF0 dGFjaGVkIHRvIGFueSBsaW5rLiBXZSB1c2UgdGhlbSBldmVyeSBkYXkuDQoNClJGQzcyMjMgZGlk IGRlY2VudCBqb2IgdHJ5aW5nIHRvIGNhcHR1cmUgd2hhdCB0aGUgaW50ZXJmYWNlIG1lYW5zIGFu ZCBkaXZpZGVkIHRoZSBpbnRlcmZhY2VzIGludG8gc3lzdGVtIGRlZmluZWQgYW5kIHVzZXIgZGVm aW5lZDoNCg0KMS4xLiAgVGVybWlub2xvZ3kNCg0KICAgVGhlIGZvbGxvd2luZyB0ZXJtcyBhcmUg dXNlZCB3aXRoaW4gdGhpcyBkb2N1bWVudDoNCg0KICAgbyAgc3lzdGVtLWNvbnRyb2xsZWQgaW50 ZXJmYWNlOiBBbiBpbnRlcmZhY2UgaXMgc2FpZCB0byBiZSBzeXN0ZW0tDQogICAgICBjb250cm9s bGVkIGlmIHRoZSBzeXN0ZW0gY3JlYXRlcyBhbmQgZGVsZXRlcyB0aGUgaW50ZXJmYWNlDQogICAg ICBpbmRlcGVuZGVudGx5IG9mIHdoYXQgaGFzIGJlZW4gZXhwbGljaXRseSBjb25maWd1cmVkLiAg RXhhbXBsZXMNCiAgICAgIGFyZSBpbnRlcmZhY2VzIHJlcHJlc2VudGluZyBwaHlzaWNhbCBoYXJk d2FyZSB0aGF0IGFwcGVhciBhbmQNCiAgICAgIGRpc2FwcGVhciB3aGVuIGhhcmR3YXJlIChlLmcu LCBhIGxpbmUgY2FyZCBvciBob3QtcGx1Z2dhYmxlDQogICAgICB3aXJlbGVzcyBpbnRlcmZhY2Up IGlzIGFkZGVkIG9yIHJlbW92ZWQuICBTeXN0ZW0tY29udHJvbGxlZA0KICAgICAgaW50ZXJmYWNl cyBtYXkgYWxzbyBhcHBlYXIgaWYgYSBjZXJ0YWluIGZ1bmN0aW9uYWxpdHkgaXMgZW5hYmxlZA0K ICAgICAgKGUuZy4sIGEgbG9vcGJhY2sgaW50ZXJmYWNlIG1pZ2h0IGFwcGVhciBpZiB0aGUgSVAg cHJvdG9jb2wgc3RhY2sNCiAgICAgIGlzIGVuYWJsZWQpLg0KDQogICBvICB1c2VyLWNvbnRyb2xs ZWQgaW50ZXJmYWNlOiBBbiBpbnRlcmZhY2UgaXMgc2FpZCB0byBiZSB1c2VyLQ0KICAgICAgY29u dHJvbGxlZCBpZiB0aGUgY3JlYXRpb24gb2YgdGhlIGludGVyZmFjZSBpcyBjb250cm9sbGVkIGJ5 DQogICAgICBhZGRpbmcgZXhwbGljaXQgaW50ZXJmYWNlIGNvbmZpZ3VyYXRpb24gdG8gdGhlIHJ1 bm5pbmcNCiAgICAgIGNvbmZpZ3VyYXRpb24gZGF0YXN0b3JlIGFuZCB0aGUgcmVtb3ZhbCBvZiB0 aGUgaW50ZXJmYWNlIGlzDQogICAgICBjb250cm9sbGVkIGJ5IHJlbW92aW5nIGV4cGxpY2l0IGlu dGVyZmFjZSBjb25maWd1cmF0aW9uIGZyb20gdGhlDQogICAgICBydW5uaW5nIGNvbmZpZ3VyYXRp b24gZGF0YXN0b3JlLiAgRXhhbXBsZXMgYXJlIFZMQU4gaW50ZXJmYWNlcw0KICAgICAgY29uZmln dXJlZCBvbiBhIHN5c3RlbS1jb250cm9sbGVkIEV0aGVybmV0IGludGVyZmFjZS4NCg0KDQpTbyBw bGVhc2UgbGV0J3MgY29uc2lkZXIgcmVhbGl0eSBoZXJlLCBub3Qgc29tZSBiYWRseSBkZWZpbmVk IGRvZ21hcyBmcm9tIHRoZSBzdG9uZSBhZ2UuDQoNCkFuZCBpZiB3ZSB3aWxsLCB0aGVuIHRoZSBT UnY2IGRlc3RpbmF0aW9uIGFkZHJlc3MgaXMgdGhlIGFkZHJlc3Mgb2YgYSBzcGVjaWFsIHZpcnR1 YWwgaW50ZXJmYWNlIGluIHRoZSBzeXN0ZW0uIFRoZSBtZWFuaW5nIG9mIHRoZSBiaXRzIG91dHNp ZGUgb2YgdGhlIHJvdXRhYmxlIHByZWZpeCBpcyB1cCB0byB0aGUgaW50ZXJmYWNlIGNyZWF0b3Iu DQoNCklmIHRoYXQgc2luZ2xlIHNlbnRlbmNlIGlzIG1pc3NpbmcgaW4gYW55IHNwZWMgaXQgY2Fu IGJlIGFkZGVkIGJ1dCB0byBtZSB0aGlzIGlzIG9idmlvdXMuDQoNCkNoZWVycywNClIuDQoNCg0K T24gVGh1LCBPY3QgNywgMjAyMSBhdCAxMjoxNCBQTSBOaWNrIEhpbGxpYXJkIDxuaWNrQGZvb2Jh ci5vcmc8bWFpbHRvOm5pY2tAZm9vYmFyLm9yZz4+IHdyb3RlOg0KRWR1YXJkIE1ldHogd3JvdGUg b24gMDcvMTAvMjAyMSAxMDowMzoNCj4gRm9yIG15IHVuZGVyc3RhbmRpbmcsIGFwYXJ0IGZyb20g dGhhdCB0aGUgKGRlZmluaXRpb24gb2YpIFNJRCBtYXkgbm90IGJlDQo+IGFsaWduZWQgd2l0aCB0 aGUgbGl0ZXJhbCB0ZXh0IGluIGJlbG93IFJGQ3MsIHdoYXQgaXMgdGhlIHJlYWwgcHJvYmxlbT8N Cg0KdGhlIGNvbmNlcHQgb2YgYW4gaXB2NiBkZXN0aW5hdGlvbiBhZGRyZXNzIGlzIGRlZXBseSBp bmdyYWluZWQgaW4gdGhlDQppcHY2IHByb3RvY29sLiAgU28sIGxvb2tpbmcgYXQgdGhpcyBmcm9t IGEgZGVwbG95bWVudCBwb2ludCBvZiB2aWV3LCB3aHkNCmRvZXMgYW4gZXhwZWRpZW5jeSBvZiB0 aGUgc29ydCBzdWdnZXN0ZWQgaW4gdGhpcyBkcmFmdCBqdXN0aWZ5IGNoYW5naW5nDQp0aGUgc2Vt YW50aWNzIG9mIG9uZSBvZiB0aGUgY29ybmVyc3RvbmVzIG9mIHRoZSBpcHY2IHByb3RvY29sPw0K DQpUaGUgYXV0aG9ycyB3b3VsZCBuZWVkIHRvIGp1c3RpZnkgdGhpcyBwcm90b2NvbCBtb2RpZmlj YXRpb24gb24gdGhlIHNhbWUNCnNvcnQgb2YgYmFzaXMgdGhhdCBhbnkgb3RoZXIgSUQgbWlnaHQg YmUgZXhwZWN0ZWQgdG8gZG8uICBFLmcuIGZvcg0Kc3RhcnRlcnMsIGluY2x1ZGluZyBhbiBhbmFs eXNpcyBvZiBob3cgdGhpcyB3b3VsZCBpbXBhY3Qgb3IgcG90ZW50aWFsbHkNCmltcGFjdCBhbnkg b3RoZXIgUkZDIHdoaWNoIHJlZmVyZW5jZXMgb3IgaW1wbGljaXRseSBkZXBlbmRzIG9uDQpjdXJy ZW50bHktZGVmaW5lZCBpcHY2IGFkZHJlc3Npbmcgc2VtYW50aWNzLg0KDQpOaWNrDQoNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQpJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCmlwdjZAaWV0Zi5v cmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K --_000_07de7dc0acaf467d84681e5caf7f9785huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBX b3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEu MGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyog TGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTg1MjkwNzkyMDsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEzNzk2MTY5ODg7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkRhdGEgcGxhbmUg4oCcUHJvZ3JhbW1hYmlsaXR54oCdIGluIHByaW5jaXBs ZSBzaG91bGQgYmUgZGlzY2FyZGVkPGJyPg0KSWYgdGhlIGFkZHJlc3MgaXMgb25seSDigJxhIG5v ZGUncyBhdHRhY2htZW50IHRvIGEgbGlua+KAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBkbyBub3Qg d2FudCB0byBtZW50aW9uIOKAnGxvY2F0b3LigJ0gYW5kIOKAnGFyZ3VtZW504oCdIGJlY2F1c2Ug YW55IHByb2dyYW1tYWJpbGl0eSBpcyBibG9ja2VkIGJ5IHN1Y2ggYWRkcmVzcyBkZWZpbml0aW9u LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5JIGhvcGUgd2UgZG8gbm90IHdhbnQgdG8gbW92ZSBldmVyeXRo aW5nIHRvIHRoZSBjb250cm9sIHBsYW5lIGFnYWluLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JdCB3YXMg YSBuaWNlIGlkZWEgdG8gc2hpZnQgc3RhdGVzIGZyb20gdGhlIGNvbnRyb2wgcGxhbmUgYW5kIGZv cndhcmRpbmcgdGFibGVzIHRvIHRoZSBwYWNrZXQgaXRzZWxmLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5U aGUgY2FsbCB0byBmb2xsb3cg4oCcYSBub2RlJ3MgYXR0YWNobWVudCB0byBhIGxpbmvigJ0gcnVs ZSBpcyBzb21laG93IGVxdWl2YWxlbnQgdG8g4oCcY2xvc2UgU1BSSU5HIHdn4oCdLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5FZC88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBp cHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5S b2JlcnQgUmFzenVrPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBPY3RvYmVyIDcsIDIwMjEg MTozMiBQTTxicj4NCjxiPlRvOjwvYj4gTmljayBIaWxsaWFyZCAmbHQ7bmlja0Bmb29iYXIub3Jn Jmd0Ozxicj4NCjxiPkNjOjwvYj4gUm9uIEJvbmljYSAmbHQ7cmJvbmljYT00MGp1bmlwZXIubmV0 QGRtYXJjLmlldGYub3JnJmd0OzsgU1BSSU5HIFdHICZsdDtzcHJpbmdAaWV0Zi5vcmcmZ3Q7OyA2 bWFuQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBkcmFmdC1maWxz Zmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi0wMjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5pY2ssPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PayBsZXQncyB6b29tIG9uIHlvdXIgcG9pbnQuJm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPklQdjYm bmJzcDsmbmJzcDtBZGRyZXNzaW5nIEFyY2hpdGVjdHVyZSBSRkMgc2F5czombmJzcDs8L2I+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibHVlIj5JUHY2IGFkZHJlc3NlcyBhcmUgMTI4LWJpdCBpZGVudGlmaWVy cyBmb3IgaW50ZXJmYWNlcyBhbmQgc2V0cyBvZjxicj4NCiZuYnNwOyAmbmJzcDtpbnRlcmZhY2Vz ICh3aGVyZSAmcXVvdDtpbnRlcmZhY2UmcXVvdDsgaXMgYXMgZGVmaW5lZCBpbiBTZWN0aW9uIDIg b2YgW0lQVjZdKS48YnI+DQombmJzcDsgJm5ic3A7VGhlcmUgYXJlIHRocmVlIHR5cGVzIG9mIGFk ZHJlc3Nlczo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7IFVuaWNhc3Q6ICZuYnNwOyBBbiBpZGVu dGlmaWVyIGZvciBhIHNpbmdsZSBpbnRlcmZhY2UuJm5ic3A7IEEgcGFja2V0IHNlbnQgdG8gYTxi cj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDt1bmljYXN0IGFkZHJlc3MgaXMgZGVsaXZlcmVkIHRvIHRoZSBpbnRlcmZhY2UgaWRlbnRpZmll ZDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDtieSB0aGF0IGFkZHJlc3MuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyB3aGF0IGlzIGxlZnQgdG8gY2hlY2sgaXMgd2hh dCB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgJnF1b3Q7aW50ZXJmYWNlJnF1b3Q7IGlzLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21l IGZvbGtzIHJlZmVyIHRvIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBpbnRlcmZhY2UgYXMgc3RhdGVk Jm5ic3A7dmVyYmF0aW0gaW4NCjxiPlJGQzI0NjAvUkZDODIwMDombmJzcDs8L2I+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjpibHVlIj4yLiZuYnNwOyBUZXJtaW5vbG9neTxicj4NCjxicj4NCiZuYnNwOyAmbmJz cDtpbnRlcmZhY2UgJm5ic3A7IC0gYSBub2RlJ3MgYXR0YWNobWVudCB0byBhIGxpbmsuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 dT5Ib3dldmVyIHdlIGFsbCBrbm93IHRoYXQgb3V0c2lkZSBvZiBJUHY2LCBTUnY2IHRoZXJlIGFy ZSBtYW55IG1vcmUgdHlwZXMgb2YgaW50ZXJmYWNlcyB3aGljaCBhcmUgbm90IGF0dGFjaGVkIHRv IGFueSBsaW5rLiBXZSB1c2UgdGhlbSBldmVyeSBkYXkuJm5ic3A7PC91PjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5SRkM3MjIzPC9iPiBk aWQgZGVjZW50IGpvYiB0cnlpbmcgdG8gY2FwdHVyZSB3aGF0IHRoZSBpbnRlcmZhY2UgbWVhbnMg YW5kIGRpdmlkZWQgdGhlIGludGVyZmFjZXMgaW50byBzeXN0ZW0gZGVmaW5lZCBhbmQgdXNlciBk ZWZpbmVkOiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymx1ZSI+MS4xLiZuYnNwOyBUZXJtaW5vbG9n eTxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtUaGUgZm9sbG93aW5nIHRlcm1zIGFyZSB1c2VkIHdp dGhpbiB0aGlzIGRvY3VtZW50Ojxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDtvICZuYnNwO3N5c3Rl bS1jb250cm9sbGVkIGludGVyZmFjZTogQW4gaW50ZXJmYWNlIGlzIHNhaWQgdG8gYmUgc3lzdGVt LTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbnRyb2xsZWQgaWYgdGhlIHN5c3RlbSBjcmVh dGVzIGFuZCBkZWxldGVzIHRoZSBpbnRlcmZhY2U8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBp bmRlcGVuZGVudGx5IG9mIHdoYXQgaGFzIGJlZW4gZXhwbGljaXRseSBjb25maWd1cmVkLiZuYnNw OyBFeGFtcGxlczxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGFyZSBpbnRlcmZhY2VzIHJlcHJl c2VudGluZyBwaHlzaWNhbCBoYXJkd2FyZSB0aGF0IGFwcGVhciBhbmQ8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyBkaXNhcHBlYXIgd2hlbiBoYXJkd2FyZSAoZS5nLiwgYSBsaW5lIGNhcmQgb3Ig aG90LXBsdWdnYWJsZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHdpcmVsZXNzIGludGVyZmFj ZSkgaXMgYWRkZWQgb3IgcmVtb3ZlZC4mbmJzcDsgU3lzdGVtLWNvbnRyb2xsZWQ8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyBpbnRlcmZhY2VzIG1heSBhbHNvIGFwcGVhciBpZiBhIGNlcnRhaW4g ZnVuY3Rpb25hbGl0eSBpcyBlbmFibGVkPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgKGUuZy4s IGEgbG9vcGJhY2sgaW50ZXJmYWNlIG1pZ2h0IGFwcGVhciBpZiB0aGUgSVAgcHJvdG9jb2wgc3Rh Y2s8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBpcyBlbmFibGVkKS48YnI+DQo8YnI+DQombmJz cDsgJm5ic3A7byAmbmJzcDt1c2VyLWNvbnRyb2xsZWQgaW50ZXJmYWNlOiBBbiBpbnRlcmZhY2Ug aXMgc2FpZCB0byBiZSB1c2VyLTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbnRyb2xsZWQg aWYgdGhlIGNyZWF0aW9uIG9mIHRoZSBpbnRlcmZhY2UgaXMgY29udHJvbGxlZCBieTxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7IGFkZGluZyBleHBsaWNpdCBpbnRlcmZhY2UgY29uZmlndXJhdGlv biB0byB0aGUgcnVubmluZzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IGNvbmZpZ3VyYXRpb24g ZGF0YXN0b3JlIGFuZCB0aGUgcmVtb3ZhbCBvZiB0aGUgaW50ZXJmYWNlIGlzPGJyPg0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgY29udHJvbGxlZCBieSByZW1vdmluZyBleHBsaWNpdCBpbnRlcmZhY2Ug Y29uZmlndXJhdGlvbiBmcm9tIHRoZTxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHJ1bm5pbmcg Y29uZmlndXJhdGlvbiBkYXRhc3RvcmUuJm5ic3A7IEV4YW1wbGVzIGFyZSBWTEFOIGludGVyZmFj ZXM8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyBjb25maWd1cmVkIG9uIGEgc3lzdGVtLWNvbnRy b2xsZWQgRXRoZXJuZXQgaW50ZXJmYWNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBwbGVhc2UgbGV0J3MgY29uc2lkZXIg cmVhbGl0eSBoZXJlLCBub3Qgc29tZSBiYWRseSBkZWZpbmVkJm5ic3A7ZG9nbWFzJm5ic3A7ZnJv bSB0aGUgc3RvbmUgYWdlLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQgaWYgd2Ugd2lsbCwgdGhlbiB0aGUgU1J2NiBkZXN0aW5h dGlvbiBhZGRyZXNzIGlzIHRoZSBhZGRyZXNzIG9mIGEgc3BlY2lhbCB2aXJ0dWFsIGludGVyZmFj ZSBpbiB0aGUgc3lzdGVtLiBUaGUgbWVhbmluZyBvZiB0aGUgYml0cyBvdXRzaWRlIG9mIHRoZSBy b3V0YWJsZSBwcmVmaXggaXMgdXAgdG8gdGhlIGludGVyZmFjZSBjcmVhdG9yLiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGF0 IHNpbmdsZSBzZW50ZW5jZSBpcyBtaXNzaW5nIGluIGFueSBzcGVjIGl0IGNhbiBiZSBhZGRlZCBi dXQgdG8gbWUgdGhpcyBpcyBvYnZpb3VzLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgT2N0IDcsIDIwMjEgYXQg MTI6MTQgUE0gTmljayBIaWxsaWFyZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5pY2tAZm9vYmFyLm9y ZyI+bmlja0Bmb29iYXIub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FZHVhcmQgTWV0eiB3cm90ZSBvbiAw Ny8xMC8yMDIxIDEwOjAzOjxicj4NCiZndDsgRm9yIG15IHVuZGVyc3RhbmRpbmcsIGFwYXJ0IGZy b20gdGhhdCB0aGUgKGRlZmluaXRpb24gb2YpIFNJRCBtYXkgbm90IGJlIDxicj4NCiZndDsgYWxp Z25lZCB3aXRoIHRoZSBsaXRlcmFsIHRleHQgaW4gYmVsb3cgUkZDcywgd2hhdCBpcyB0aGUgcmVh bCBwcm9ibGVtPzxicj4NCjxicj4NCnRoZSBjb25jZXB0IG9mIGFuIGlwdjYgZGVzdGluYXRpb24g YWRkcmVzcyBpcyBkZWVwbHkgaW5ncmFpbmVkIGluIHRoZSA8YnI+DQppcHY2IHByb3RvY29sLiZu YnNwOyBTbywgbG9va2luZyBhdCB0aGlzIGZyb20gYSBkZXBsb3ltZW50IHBvaW50IG9mIHZpZXcs IHdoeSA8YnI+DQpkb2VzIGFuIGV4cGVkaWVuY3kgb2YgdGhlIHNvcnQgc3VnZ2VzdGVkIGluIHRo aXMgZHJhZnQganVzdGlmeSBjaGFuZ2luZyA8YnI+DQp0aGUgc2VtYW50aWNzIG9mIG9uZSBvZiB0 aGUgY29ybmVyc3RvbmVzIG9mIHRoZSBpcHY2IHByb3RvY29sPzxicj4NCjxicj4NClRoZSBhdXRo b3JzIHdvdWxkIG5lZWQgdG8ganVzdGlmeSB0aGlzIHByb3RvY29sIG1vZGlmaWNhdGlvbiBvbiB0 aGUgc2FtZSA8YnI+DQpzb3J0IG9mIGJhc2lzIHRoYXQgYW55IG90aGVyIElEIG1pZ2h0IGJlIGV4 cGVjdGVkIHRvIGRvLiZuYnNwOyBFLmcuIGZvciA8YnI+DQpzdGFydGVycywgaW5jbHVkaW5nIGFu IGFuYWx5c2lzIG9mIGhvdyB0aGlzIHdvdWxkIGltcGFjdCBvciBwb3RlbnRpYWxseSA8YnI+DQpp bXBhY3QgYW55IG90aGVyIFJGQyB3aGljaCByZWZlcmVuY2VzIG9yIGltcGxpY2l0bHkgZGVwZW5k cyBvbiA8YnI+DQpjdXJyZW50bHktZGVmaW5lZCBpcHY2IGFkZHJlc3Npbmcgc2VtYW50aWNzLjxi cj4NCjxicj4NCk5pY2s8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCklFVEYgSVB2NiB3b3Jr aW5nIGdyb3VwIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzppcHY2QGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+aXB2NkBpZXRmLm9yZzwvYT48YnI+DQpBZG1pbmlzdHJhdGl2ZSBS ZXF1ZXN0czogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p cHY2IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lwdjY8L2E+PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_07de7dc0acaf467d84681e5caf7f9785huaweicom_-- From nobody Thu Oct 7 03:51:13 2021 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 891BF3A0DC6; Thu, 7 Oct 2021 03:51:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-QiNEuV4cAy; Thu, 7 Oct 2021 03:51:02 -0700 (PDT) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (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 5A6023A0DC0; Thu, 7 Oct 2021 03:51:02 -0700 (PDT) Received: by mail-lf1-x129.google.com with SMTP id m3so23349109lfu.2; Thu, 07 Oct 2021 03:51:02 -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=6dZFJu/Wkhl5hkLLLv0cYn0o/Rq4VXc5713cfWe7BGk=; b=T/WfjeJEv/hssYI+6bL9NIGlwQghg0V1db3mroeaSaKYCZNigzUCSw7+kWE8YcHOHU 7tcGfjhoQy+hGy71kY2WYwmC3c3xPYBMeOWervUwqL4xZzciStdnlGYCycemMwcsSNvC XSLOA7u4ch4AJ3xAi+dtAAOeGQR2uxlyCBjkok7I2x11QsgXv07mHSyxbSSu9hXSecyk YrP6ZrUq44x45+ZS99PBEQj148Ebj/+tOleHcaAIFou9RxAySAoiPPXdPgpg+htt/I/u Pj0HMp+ffMiGP1VCKUf5BnXufjQgoFiMzQ5LYoxD0cGcjnPwQ7TkL68PKPnV7Y3kctrJ LAIg== 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=6dZFJu/Wkhl5hkLLLv0cYn0o/Rq4VXc5713cfWe7BGk=; b=CUfpi01F1OsG9HEKTy1SiC539u/7KurZq35qjMTzyxALzdckmTB22UkvIl+iOOxIVk BvqZXiHRB2Xf4fZzXoEbFXOfYr61jHJlNmbwgfPu6CgqmKluHyV39xgToOz8LG/AZXJv t/w3iuZwJpF6c+m+MWAlQm2vHDlLoXJujr/WWMXQRJyAsuHLnab/bKUz/Upm2bAwcZ0+ k/KM/0mxFJ+Hoo/8uGvHmArtbRcOzTWQq4FM7RIVKkuW+zH3NvhjPOZK0d3XkA4Bd05K hem//sscoOm33rDDiS1TR0EqIMGgZWxtuFw01/BI12yhCJ5WCuCXJzOi2XsmJ1pRalUt IZRw== X-Gm-Message-State: AOAM532be1NUJsY4i/FNWGiXM9gq7nx5uEicwrdGfhA2EaqyCMQaAc3r 6r4uKul9zBTLGmI35lwamBYaUqto/6JatflXACM= X-Google-Smtp-Source: ABdhPJy6PhRmCS+b7MM0pa69qGi38Qn5n9JNFtS6nmFM3x8yrL8Wx0aTjWs6mi4wgaIr30TAh3qF3bDiJJFVbU0aGfQ= X-Received: by 2002:a19:48d1:: with SMTP id v200mr3650478lfa.47.1633603860016; Thu, 07 Oct 2021 03:51:00 -0700 (PDT) MIME-Version: 1.0 References: <86741e64-eef2-6395-afd7-62764d9f5c41@foobar.org> In-Reply-To: <86741e64-eef2-6395-afd7-62764d9f5c41@foobar.org> From: Eduard Metz Date: Thu, 7 Oct 2021 12:50:50 +0200 Message-ID: To: Nick Hilliard Cc: Ron Bonica , SPRING WG , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000c7b2ba05cdc1090d" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 07 Oct 2021 10:51:08 -0000 --000000000000c7b2ba05cdc1090d Content-Type: text/plain; charset="UTF-8" I honestly would like to understand if this discussion about fixing the wording (e.g. use a more abstract notion of interface / link), or if there are cases where things (may) break. I was hoping someone could point to examples? As pointed out by Robert not all types of interfaces used today fit the definitions, even loopback doesn't match nicely /Eduard On Thu, Oct 7, 2021 at 12:14 PM Nick Hilliard wrote: > Eduard Metz wrote on 07/10/2021 10:03: > > For my understanding, apart from that the (definition of) SID may not be > > aligned with the literal text in below RFCs, what is the real problem? > > the concept of an ipv6 destination address is deeply ingrained in the > ipv6 protocol. So, looking at this from a deployment point of view, why > does an expediency of the sort suggested in this draft justify changing > the semantics of one of the cornerstones of the ipv6 protocol? > > The authors would need to justify this protocol modification on the same > sort of basis that any other ID might be expected to do. E.g. for > starters, including an analysis of how this would impact or potentially > impact any other RFC which references or implicitly depends on > currently-defined ipv6 addressing semantics. > > Nick > --000000000000c7b2ba05cdc1090d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I honestly would like to underst= and if this discussion about fixing the wording (e.g. use a more abstract n= otion of interface / link), or if there are cases where things (may) break.= I was hoping someone could point to examples?

As = pointed out by Robert not all types of interfaces used today fit the defini= tions, even loopback doesn't match nicely

/Edu= ard

On Thu, Oct 7, 2021 at 12:14 PM Nick Hilliard <nick@foobar.org> wrote:
Eduard Metz wrote on 07/10/2021 10:03: > For my understanding, apart from that the (definition of) SID may not = be
> aligned with the literal text in below RFCs, what is the real problem?=

the concept of an ipv6 destination address is deeply ingrained in the
ipv6 protocol.=C2=A0 So, looking at this from a deployment point of view, w= hy
does an expediency of the sort suggested in this draft justify changing the semantics of one of the cornerstones of the ipv6 protocol?

The authors would need to justify this protocol modification on the same sort of basis that any other ID might be expected to do.=C2=A0 E.g. for starters, including an analysis of how this would impact or potentially impact any other RFC which references or implicitly depends on
currently-defined ipv6 addressing semantics.

Nick
--000000000000c7b2ba05cdc1090d-- From nobody Thu Oct 7 04:00:31 2021 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 2040F3A0DE1 for ; Thu, 7 Oct 2021 04:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 OZyN-Iva8Sz5 for ; Thu, 7 Oct 2021 04:00:18 -0700 (PDT) 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 068BA3A0DE5 for ; Thu, 7 Oct 2021 04:00:17 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id l22so3855888vsq.9 for ; Thu, 07 Oct 2021 04:00:17 -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=iWXqIbUVMheTGItnG0YShQ4uTGfqCc8MNJVvkLKMNfA=; b=cwvMEjKoI3n/JLV6aDgCis2xibCGeP79gFS4z7dPOM3hMx+nrt6mLL3arx4b5qs8Ts IuJxp6pbeTHJ3FsGmuvCxFDQpFq8e51WGnutPikbZV597c+cdBUfioheXbO9RS29rhUu LsdtKkUgTdClTAEPGi5IL06YpnmbhS1dbN7U5LsdzHvuWPPxmM01KtZBh9m7mZv0tw/V YUgu6lve9qstsPG3Kxn9telpGL/BEVqD/cJIbIM7Ny4epfGo0uz0BKCJAFmHIbr2Of6P jQyFMAMT/ls7zgaF4OA0qmzCnR93aXbQYfpo0AlYfeqD8afp8GE60qVdU5IWgOsaRpsX VmMA== 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=iWXqIbUVMheTGItnG0YShQ4uTGfqCc8MNJVvkLKMNfA=; b=mNxEysThVLw+Bj/aI0uLxfsxE0U/PDuQqSD0IjSmAt4FMoY7i7udxRjJ2uHm4j0M2O X6k8yOhbUhRzLNWWcR7Bx3ZaXJC4SlC3jmLi+a6tGfFc1yap1LNmjaazgXJlI3M3/alN W+LTefWZ0Rh3B8g/Q1ebpzEJK0n9DQMoPB83B3LX9s6ENbL6T4NDbiT4Z6iRy4mYj+W/ sqxHKZKflSKX7Tz9WaTIPHIAtpKjXbw1AyJ2dKqnqjur5Co3JlTF26jmGlIS5eg/dv49 VJpi3a5I/G0vCZsJs8gJ65t6e7FKzexfhcT3NW+rhPR1CvTDHvqPAF5MTIlQGhAMy3WC My7Q== X-Gm-Message-State: AOAM531WlPhLKULCp2Y/lX3yma92ulRLYCbXBuFVGkjK4r0QpKZQKpf3 DFVAw5gDioELcJRkBf5yBZ82PrjU8UBNOMRLDdTTqw== X-Google-Smtp-Source: ABdhPJxmgtlJ8bYneexBmeBW8ySpbTzJJZmmWZkCOsvHYPrRguqVM8LEN3EG0kmGQGiXdYCW3eYDMmtEsMXIODv8xY4= X-Received: by 2002:a67:d20e:: with SMTP id y14mr2987509vsi.5.1633604416839; Thu, 07 Oct 2021 04:00:16 -0700 (PDT) MIME-Version: 1.0 References: <86741e64-eef2-6395-afd7-62764d9f5c41@foobar.org> <07de7dc0acaf467d84681e5caf7f9785@huawei.com> In-Reply-To: <07de7dc0acaf467d84681e5caf7f9785@huawei.com> From: Robert Raszuk Date: Thu, 7 Oct 2021 13:00:11 +0200 Message-ID: To: Vasilenko Eduard Cc: Nick Hilliard , Ron Bonica , SPRING WG , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000f8354705cdc12a31" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 07 Oct 2021 11:00:24 -0000 --000000000000f8354705cdc12a31 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Indeed !!! Spot on. I would further extend your suggestion ... VLAN interfaces should be obsoleted, any form of tunneling should be considered an IPv6 spec violation, dial in interfaces should be considered evil, IPv4 in IPv6 etc ... and this is not only in routers but also in compute nodes. Only then we will have IPv6 address all in its purity attached to a physical links. Oh maybe someone say this is also to covers virtual links - ah then great as SR segment can be treated as a virtual link and if so are we all square now ? Best, R. On Thu, Oct 7, 2021 at 12:48 PM Vasilenko Eduard < vasilenko.eduard@huawei.com> wrote: > Data plane =E2=80=9CProgrammability=E2=80=9D in principle should be disca= rded > If the address is only =E2=80=9Ca node's attachment to a link=E2=80=9D. > > I do not want to mention =E2=80=9Clocator=E2=80=9D and =E2=80=9Cargument= =E2=80=9D because any > programmability is blocked by such address definition. > > I hope we do not want to move everything to the control plane again. > > It was a nice idea to shift states from the control plane and forwarding > tables to the packet itself. > > The call to follow =E2=80=9Ca node's attachment to a link=E2=80=9D rule i= s somehow > equivalent to =E2=80=9Cclose SPRING wg=E2=80=9D. > > Ed/ > > *From:* ipv6 [mailto:ipv6-bounces@ietf.org] *On Behalf Of *Robert Raszuk > *Sent:* Thursday, October 7, 2021 1:32 PM > *To:* Nick Hilliard > *Cc:* Ron Bonica ; SPRING WG < > spring@ietf.org>; 6man@ietf.org > *Subject:* Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-0= 2 > > > > Nick, > > > > Ok let's zoom on your point. > > > > *IPv6 Addressing Architecture RFC says: * > > > > IPv6 addresses are 128-bit identifiers for interfaces and sets of > interfaces (where "interface" is as defined in Section 2 of [IPV6]). > There are three types of addresses: > > Unicast: An identifier for a single interface. A packet sent to a > unicast address is delivered to the interface identified > by that address. > > > > So what is left to check is what the definition of the "interface" is. > > > > Some folks refer to the definition of the interface as stated verbatim in > *RFC2460/RFC8200: * > > > > 2. Terminology > > interface - a node's attachment to a link. > > > > *However we all know that outside of IPv6, SRv6 there are many more types > of interfaces which are not attached to any link. We use them every day. = * > > > > *RFC7223* did decent job trying to capture what the interface means and > divided the interfaces into system defined and user defined: > > > > 1.1. Terminology > > The following terms are used within this document: > > o system-controlled interface: An interface is said to be system- > controlled if the system creates and deletes the interface > independently of what has been explicitly configured. Examples > are interfaces representing physical hardware that appear and > disappear when hardware (e.g., a line card or hot-pluggable > wireless interface) is added or removed. System-controlled > interfaces may also appear if a certain functionality is enabled > (e.g., a loopback interface might appear if the IP protocol stack > is enabled). > > o user-controlled interface: An interface is said to be user- > controlled if the creation of the interface is controlled by > adding explicit interface configuration to the running > configuration datastore and the removal of the interface is > controlled by removing explicit interface configuration from the > running configuration datastore. Examples are VLAN interfaces > configured on a system-controlled Ethernet interface. > > > > > > So please let's consider reality here, not some badly defined dogmas from > the stone age. > > > > And if we will, then the SRv6 destination address is the address of a > special virtual interface in the system. The meaning of the bits outside = of > the routable prefix is up to the interface creator. > > > > If that single sentence is missing in any spec it can be added but to me > this is obvious. > > > > Cheers, > > R. > > > > > > On Thu, Oct 7, 2021 at 12:14 PM Nick Hilliard wrote: > > Eduard Metz wrote on 07/10/2021 10:03: > > For my understanding, apart from that the (definition of) SID may not b= e > > aligned with the literal text in below RFCs, what is the real problem? > > the concept of an ipv6 destination address is deeply ingrained in the > ipv6 protocol. So, looking at this from a deployment point of view, why > does an expediency of the sort suggested in this draft justify changing > the semantics of one of the cornerstones of the ipv6 protocol? > > The authors would need to justify this protocol modification on the same > sort of basis that any other ID might be expected to do. E.g. for > starters, including an analysis of how this would impact or potentially > impact any other RFC which references or implicitly depends on > currently-defined ipv6 addressing semantics. > > Nick > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --000000000000f8354705cdc12a31 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Indeed !!! Spot on.=C2=A0

I would further extend your suggestion ... VLAN interfaces should be obso= leted, any form of tunneling should be considered an IPv6 spec violation, d= ial in interfaces should be considered evil, IPv4 in IPv6=C2=A0 etc ... and= this is not only in routers=C2=A0but also in compute nodes.=C2=A0

Only then we will have IPv6 address all in its purity atta= ched to a physical links.=C2=A0

Oh maybe someone s= ay this is also to covers virtual links - ah then great as SR segment can b= e treated as a virtual link and if so are we all square now ?=C2=A0

Best,
R.


On Thu, Oct 7, 202= 1 at 12:48 PM Vasilenko Eduard <vasilenko.eduard@huawei.com> wrote:

Data plane =E2=80=9CProgrammability=E2=80=9D= in principle should be discarded
If the address is only =E2=80=9Ca node's attachment to a link=E2=80=9D.=

I do not want to mention =E2=80=9Clocator=E2= =80=9D and =E2=80=9Cargument=E2=80=9D because any programmability is blocke= d by such address definition.

I hope we do not want to move everything to = the control plane again.

It was a nice idea to shift states from the = control plane and forwarding tables to the packet itself.

The call to follow =E2=80=9Ca node's att= achment to a link=E2=80=9D rule is somehow equivalent to =E2=80=9Cclose SPR= ING wg=E2=80=9D.

Ed/

From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Thursday, October 7, 2021 1:32 PM
To: Nick Hilliard <nick@foobar.org>
Cc: Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org>; SPRING WG = <spring@ietf.org>; 6man@ietf.org=
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compressio= n-02

=C2=A0

Nick,

=C2=A0

Ok let's zoom on your point.=C2=A0=

=C2=A0

IPv6=C2=A0=C2=A0Addressing Architecture RFC says:= =C2=A0

=C2=A0

IPv6 addresses are 128-bi= t identifiers for interfaces and sets of
=C2=A0 =C2=A0interfaces (where "interface" is as defined in Secti= on 2 of [IPV6]).
=C2=A0 =C2=A0There are three types of addresses:

=C2=A0 =C2=A0 Unicast: =C2=A0 An identifier for a single interface.=C2=A0 A= packet sent to a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unicast address is d= elivered to the interface identified
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by that address.

=C2=A0

So what is left to check is what the definition of t= he "interface" is.=C2=A0

=C2=A0

Some folks refer to the definition of the interface = as stated=C2=A0verbatim in RFC2460/RFC8200:=C2=A0

=C2=A0

2.=C2=A0 Terminology

=C2=A0 =C2=A0interface =C2=A0 - a node's attachment to a link.

=C2=A0

However we all know that outside of IPv6, SRv6 th= ere are many more types of interfaces which are not attached to any link. W= e use them every day.=C2=A0

=C2=A0

RFC7223 did decent job trying to capture what= the interface means and divided the interfaces into system defined and use= r defined:=C2=A0

=C2=A0

1.1.=C2=A0 Terminology
=C2=A0 =C2=A0The following terms are used within this document:

=C2=A0 =C2=A0o =C2=A0system-controlled interface: An interface is said to b= e system-
=C2=A0 =C2=A0 =C2=A0 controlled if the system creates and deletes the inter= face
=C2=A0 =C2=A0 =C2=A0 independently of what has been explicitly configured.= =C2=A0 Examples
=C2=A0 =C2=A0 =C2=A0 are interfaces representing physical hardware that app= ear and
=C2=A0 =C2=A0 =C2=A0 disappear when hardware (e.g., a line card or hot-plug= gable
=C2=A0 =C2=A0 =C2=A0 wireless interface) is added or removed.=C2=A0 System-= controlled
=C2=A0 =C2=A0 =C2=A0 interfaces may also appear if a certain functionality = is enabled
=C2=A0 =C2=A0 =C2=A0 (e.g., a loopback interface might appear if the IP pro= tocol stack
=C2=A0 =C2=A0 =C2=A0 is enabled).

=C2=A0 =C2=A0o =C2=A0user-controlled interface: An interface is said to be = user-
=C2=A0 =C2=A0 =C2=A0 controlled if the creation of the interface is control= led by
=C2=A0 =C2=A0 =C2=A0 adding explicit interface configuration to the running=
=C2=A0 =C2=A0 =C2=A0 configuration datastore and the removal of the interfa= ce is
=C2=A0 =C2=A0 =C2=A0 controlled by removing explicit interface configuratio= n from the
=C2=A0 =C2=A0 =C2=A0 running configuration datastore.=C2=A0 Examples are VL= AN interfaces
=C2=A0 =C2=A0 =C2=A0 configured on a system-controlled Ethernet interface.<= /span>

=C2=A0

=C2=A0

So please let's consider reality here, not some = badly defined=C2=A0dogmas=C2=A0from the stone age.=C2=A0

=C2=A0

And if we will, then the SRv6 destination address is= the address of a special virtual interface in the system. The meaning of t= he bits outside of the routable prefix is up to the interface creator.=C2= =A0

=C2=A0

If that single sentence is missing in any spec it ca= n be added but to me this is obvious.=C2=A0

=C2=A0

Cheers,

R.

=C2=A0

=C2=A0

On Thu, Oct 7, 2021 at 12:14 PM Nick Hilliard <nick@foobar.org> = wrote:

Eduard Metz wrote on 07/10/2021 10:03:
> For my understanding, apart from that the (definition of) SID may not = be
> aligned with the literal text in below RFCs, what is the real problem?=

the concept of an ipv6 destination address is deeply ingrained in the
ipv6 protocol.=C2=A0 So, looking at this from a deployment point of view, w= hy
does an expediency of the sort suggested in this draft justify changing the semantics of one of the cornerstones of the ipv6 protocol?

The authors would need to justify this protocol modification on the same sort of basis that any other ID might be expected to do.=C2=A0 E.g. for starters, including an analysis of how this would impact or potentially impact any other RFC which references or implicitly depends on
currently-defined ipv6 addressing semantics.

Nick

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------=

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--000000000000f8354705cdc12a31-- From nobody Thu Oct 7 05:30:06 2021 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 AE94F3A122D; Thu, 7 Oct 2021 05:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 kv0j26dZqOxJ; Thu, 7 Oct 2021 05:29:57 -0700 (PDT) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (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 3998F3A1024; Thu, 7 Oct 2021 05:29:57 -0700 (PDT) Received: by mail-il1-x12a.google.com with SMTP id i11so5209858ila.12; Thu, 07 Oct 2021 05:29:57 -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=WS3tkSzjKyFPmHFg5E/VrVkfYpBd91uUJluKIEnz4Dw=; b=S9QVisiwpLbzE9Pv8bdgBoWN1uX4sDFXC475CczjBYLwHrXwkAyJ+OLlNznF7IEu1h hdaUowKHBjqr5bQgj2EnsNTwTScDdzaGGrKijvg6PuTND8q5jCuORCkSaju5prBg5DLE qmt21S4tKjBRI0xWKhJnVSWEMZkCqFR9bt3N6UW6gL6NlUn6zNTbXHeWRIxlGPT+j0sU wMSt37n/WqTIPShJJp7ZIi9Gt4bLh+jILlQngxsMxadOptCUbnul0aZFvNB+nPDNRiBD ux03D+8YI83kU9Ik4s15nJ3HMXf/ukV0o3dMhn5oXAQkKHFIE0XxM+K4JozlA9CPw4dn mhWw== 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=WS3tkSzjKyFPmHFg5E/VrVkfYpBd91uUJluKIEnz4Dw=; b=cghX9Mvm2GuOP5UHc6FfRG9wMNCJyyH5NGnWTJYVweurMHejzoShSju/nQsduQc25M pu11VUXaCzya1X1X/XieLkGAdGKTSkw2sHbMmQan72kpBXYT/qyJ2Z3B0AmP5cU2flcs 13BDfrUWsB/9Jl8b2nMRrI2iQ2Q/oaldPmT0e8ypoMYg+Z5cxPOsC2Zz+H9F0HwkSw/m QiGfn18u5F2mB2IecgNmjdZ9EYblmE/I/w/NF8bL45MTlSM+loWvNIwSJW8VMNg4mbQ6 tSSX/HkBjjtGSRIUoU8u+PpTq6BZG7iGlPQtId6T7vAYpP3Le3xuJxXitxZBy4fCGyEh XcmQ== X-Gm-Message-State: AOAM530d7G0XRLT9cn3A2m/pd9+X1zR6dHjzGGSJmG5P7HroM7DoFSrb 9l36ITO1deRlg8WzZ7hLiRPViu0rShSh+EoSbao= X-Google-Smtp-Source: ABdhPJyewF3CtSU8AAVwFjmhm/+6tTP3OEASqUxEdSm5tk9wXtxZ7ngbMUn0QXsDw7v0hr1KSmAK3iha0yXgX8HtLVM= X-Received: by 2002:a05:6e02:1a6d:: with SMTP id w13mr2872097ilv.203.1633609796417; Thu, 07 Oct 2021 05:29:56 -0700 (PDT) MIME-Version: 1.0 References: <86741e64-eef2-6395-afd7-62764d9f5c41@foobar.org> In-Reply-To: From: Mark Smith Date: Thu, 7 Oct 2021 23:29:29 +1100 Message-ID: To: Robert Raszuk Cc: Nick Hilliard , Ron Bonica , SPRING WG , "6man@ietf.org" <6man@ietf.org> Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 07 Oct 2021 12:30:03 -0000 On Thu, 7 Oct 2021 at 21:33, Robert Raszuk wrote: > > Nick, > > Ok let's zoom on your point. > > IPv6 Addressing Architecture RFC says: > > IPv6 addresses are 128-bit identifiers for interfaces and sets of > interfaces (where "interface" is as defined in Section 2 of [IPV6]). > There are three types of addresses: > > Unicast: An identifier for a single interface. A packet sent to a > unicast address is delivered to the interface identified > by that address. > > So what is left to check is what the definition of the "interface" is. > > Some folks refer to the definition of the interface as stated verbatim in RFC2460/RFC8200: > > 2. Terminology > > interface - a node's attachment to a link. > > However we all know that outside of IPv6, SRv6 there are many more types of interfaces which are not attached to any link. We use them every day. > Those other definitions don't matter, because they're not the IPv6 definitions of an interface, and IPv6 is what we're talking about here. That is the protocol you're saying you want to use. A SID by itself can have any definition you like - 20 bits, 128 bits, 1024 bits if you want. However, once you want to put a SID value into an IPv6 DA field, then the SID value is now required to comply with IPv6's definition of the DA field, and therefore the IPv6 addressing architecture in RFC4291. Same with the IPv6 definition of an interface. The IPv6 IID field isn't a free-for-all. There are reserved IID values that have semantics - https://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xhtml. You need to make sure your SID values that you're going to put into an IPv6 DA field don't collide with these IID values when they are put in the IPv6 DA field. That's what complying with a protocol specification means, and that is what you need to do if you're *using* a protocol. Protocol specifications naturally inhibit innovation, because they have to. That is the cost of having interoperability with existing implementations. If SPRING want to innovate without constraint, then don't try to use an existing, widely deployed, 26 year old protocol. Invent a new local domain protocol that best suits your requirements. Otherwise, compromise on your solutions and mechanisms such that they still achieve what you want to achieve, while also complying with the IPv6 protocol specifications. Regards, Mark. From nobody Thu Oct 7 06:19:56 2021 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 413513A1029 for ; Thu, 7 Oct 2021 06:19:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 K90OeFAw0uRF for ; Thu, 7 Oct 2021 06:19:45 -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 D92353A102B for ; Thu, 7 Oct 2021 06:19:44 -0700 (PDT) Received: by mail-vs1-xe36.google.com with SMTP id 188so6805076vsv.0 for ; Thu, 07 Oct 2021 06:19:44 -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=up867QevBx2Tr/SC6nBYmM6kJh5wGJTkSUuiFwRbCxs=; b=V0eEfTo5HgXz5ubhWTKNapFuf+XzEMYfqsuaeEb0uF2/SclD4nf8AUta5GXySkduft Jl1bUBt8F2GYBhCGKH6lGF9dGIm9/d1ee3jj60fNgvBLGHVryT9VXqikn+4gGGFI/Hq+ BEHeamAih9VpVyZwuxNNJ/JdmEu99ZTmJ3Q+wsrazZdLfj28BgxAMDOrRxSBBW9/nF/9 /+3ShOVQ5xWEHQp0ZHcI1R7tTrlap+KK8vYWh23ZS1X8CMeIqCvC2JhtFD7rJf8VsAlN V2WSp6i0WunpU+4LMS7pYKazqoeVgLpoAVS22rZzXK9aiOaAEPF729vnxukQdq0KrnOy 5GJw== 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=up867QevBx2Tr/SC6nBYmM6kJh5wGJTkSUuiFwRbCxs=; b=7A3vrFBezVRCY/I+S5IeuGOpbV6+ktWeP0rZZzHqVf5X83QnqKFDDgKIrVUFic7B5Y 1GlTKHHmPZlwi6wCzTZQ4RvWBGexTVdivYbKbyznoXomhjCS3X84Eg5B8faKG8fisxXm DKvV3CTEjeUXLVrdWcUAo1zaT7aesn2swwBMN0+/CFs6Zvn6ehyp97pXnQ5LNv0sVxUD uVDRIQD8iTH0REaBC740QNi66YgE8+po7vq4jL6lZfaRbYppSWJB3IKT2dmy+8bFhStI iy85Y43ejYmwAy/17jyDWLpEXNhGpH3XbsLAoJph/sbR+p6Z6oCXZBUCv9W/cOx2sqdz cfkQ== X-Gm-Message-State: AOAM531Z5hrJBo3X9x5DL033GhIp9uADzw0oNa5Vj+DLG3sD2hafD7tW xsbDRDnq/oqyXnQtQ+4U/NUn+Yn6RRAaQX8EkIpAyA== X-Google-Smtp-Source: ABdhPJzULA0J0dQVIFKpGRKktKHKjJxa//jkYSM9/RUOYe1LlVEk+cihjNTqnKIH17TgJ/zCivxoNNNroFtSL0qbHnU= X-Received: by 2002:a67:cf41:: with SMTP id f1mr4200412vsm.1.1633612783584; Thu, 07 Oct 2021 06:19:43 -0700 (PDT) MIME-Version: 1.0 References: <86741e64-eef2-6395-afd7-62764d9f5c41@foobar.org> In-Reply-To: From: Robert Raszuk Date: Thu, 7 Oct 2021 15:19:38 +0200 Message-ID: To: Mark Smith Cc: Nick Hilliard , Ron Bonica , SPRING WG , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000aa9a4305cdc31d6e" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 07 Oct 2021 13:19:51 -0000 --000000000000aa9a4305cdc31d6e Content-Type: text/plain; charset="UTF-8" Hi Mark, Ok the argument of IID space comes first time - I do apologies if I missed it and it was mentioned before. So the consequence of reserved IID space for application A in case of collision with any other application B may yield unexpected results. And that apparently is completely agnostic to the actual prefix of the address. But reading say RFC6543 such IIDs can be present only in link local addresses not real IPv6 "global" prefixes. So again we are safe. If there any case that IPv6 stacks are expected to perform any action based on the IIDs of the packets irrespective of the prefix/locator portion of the DST address in the packet header ? Thx, R. On Thu, Oct 7, 2021 at 2:29 PM Mark Smith wrote: > On Thu, 7 Oct 2021 at 21:33, Robert Raszuk wrote: > > > > Nick, > > > > Ok let's zoom on your point. > > > > IPv6 Addressing Architecture RFC says: > > > > IPv6 addresses are 128-bit identifiers for interfaces and sets of > > interfaces (where "interface" is as defined in Section 2 of [IPV6]). > > There are three types of addresses: > > > > Unicast: An identifier for a single interface. A packet sent to a > > unicast address is delivered to the interface identified > > by that address. > > > > So what is left to check is what the definition of the "interface" is. > > > > Some folks refer to the definition of the interface as stated verbatim > in RFC2460/RFC8200: > > > > 2. Terminology > > > > interface - a node's attachment to a link. > > > > However we all know that outside of IPv6, SRv6 there are many more types > of interfaces which are not attached to any link. We use them every day. > > > > Those other definitions don't matter, because they're not the IPv6 > definitions of an interface, and IPv6 is what we're talking about > here. That is the protocol you're saying you want to use. > > A SID by itself can have any definition you like - 20 bits, 128 bits, > 1024 bits if you want. However, once you want to put a SID value into > an IPv6 DA field, then the SID value is now required to comply with > IPv6's definition of the DA field, and therefore the IPv6 addressing > architecture in RFC4291. Same with the IPv6 definition of an > interface. > > The IPv6 IID field isn't a free-for-all. There are reserved IID values > that have semantics - > > https://www.iana.org/assignments/ipv6-interface-ids/ipv6-interface-ids.xhtml > . > You need to make sure your SID values that you're going to put into an > IPv6 DA field don't collide with these IID values when they are put in > the IPv6 DA field. > > That's what complying with a protocol specification means, and that is > what you need to do if you're *using* a protocol. > > Protocol specifications naturally inhibit innovation, because they > have to. That is the cost of having interoperability with existing > implementations. > > If SPRING want to innovate without constraint, then don't try to use > an existing, widely deployed, 26 year old protocol. Invent a new local > domain protocol that best suits your requirements. > > Otherwise, compromise on your solutions and mechanisms such that they > still achieve what you want to achieve, while also complying with the > IPv6 protocol specifications. > > > > Regards, > Mark. > --000000000000aa9a4305cdc31d6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Mark,

Ok the argument of IID space c= omes first time=C2=A0- I do apologies=C2=A0if I missed it and it was mentio= ned before.=C2=A0

So the consequence of reserved I= ID space for application A in case of collision with any other application = B may yield=C2=A0unexpected results. And that apparently is completely agno= stic to the actual prefix of the address.=C2=A0

Bu= t reading say RFC6543 such IIDs can be present only in link local addresses= not real IPv6 "global" prefixes. So again we are safe.=C2=A0

If there any case that IPv6 stacks are expected to pe= rform any action based on the IIDs of the packets irrespective of the prefi= x/locator portion of the DST address in the packet header ?=C2=A0

Thx,
R.


<= br>




=
On Thu= , Oct 7, 2021 at 2:29 PM Mark Smith <markzzzsmith@gmail.com> wrote:
On Thu, 7 Oct 2021 at 21:33, Robert Raszuk <= ;robert@raszuk.net> wrote:
>
> Nick,
>
> Ok let's zoom on your point.
>
> IPv6=C2=A0 Addressing Architecture RFC says:
>
> IPv6 addresses are 128-bit identifiers for interfaces and sets of
>=C2=A0 =C2=A0 interfaces (where "interface" is as defined in = Section 2 of [IPV6]).
>=C2=A0 =C2=A0 There are three types of addresses:
>
>=C2=A0 =C2=A0 =C2=A0Unicast:=C2=A0 =C2=A0An identifier for a single int= erface.=C2=A0 A packet sent to a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 unicast address= is delivered to the interface identified
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 by that address= .
>
> So what is left to check is what the definition of the "interface= " is.
>
> Some folks refer to the definition of the interface as stated verbatim= in RFC2460/RFC8200:
>
> 2.=C2=A0 Terminology
>
>=C2=A0 =C2=A0 interface=C2=A0 =C2=A0- a node's attachment to a link= .
>
> However we all know that outside of IPv6, SRv6 there are many more typ= es of interfaces which are not attached to any link. We use them every day.=
>

Those other definitions don't matter, because they're not the IPv6<= br> definitions of an interface, and IPv6 is what we're talking about
here. That is the protocol you're saying you want to use.

A SID by itself can have any definition you like - 20 bits, 128 bits,
1024 bits if you want. However, once you want to put a SID value into
an IPv6 DA field, then the SID value is now required to comply with
IPv6's definition of the DA field, and therefore the IPv6 addressing architecture in RFC4291. Same with the IPv6 definition of an
interface.

The IPv6 IID field isn't a free-for-all. There are reserved IID values<= br> that have semantics -
https://www.iana.org/ass= ignments/ipv6-interface-ids/ipv6-interface-ids.xhtml.
You need to make sure your SID values that you're going to put into an<= br> IPv6 DA field don't collide with these IID values when they are put in<= br> the IPv6 DA field.

That's what complying with a protocol specification means, and that is<= br> what you need to do if you're *using* a protocol.

Protocol specifications naturally inhibit innovation, because they
have to. That is the cost of having interoperability with existing
implementations.

If SPRING want to innovate without constraint, then don't try to use an existing, widely deployed, 26 year old protocol. Invent a new local
domain protocol that best suits your requirements.

Otherwise, compromise on your solutions and mechanisms such that they
still achieve what you want to achieve, while also complying with the
IPv6 protocol specifications.

<snip>

Regards,
Mark.
--000000000000aa9a4305cdc31d6e-- From nobody Thu Oct 7 09:17:24 2021 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 7CC613A0B4F; Thu, 7 Oct 2021 09:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, SPF_NONE=0.001, 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=ZQlY7ge2; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DI1oCdL6 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 kLXtyribOtJX; Thu, 7 Oct 2021 09:17:15 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADBF13A0B53; Thu, 7 Oct 2021 09:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28272; q=dns/txt; s=iport; t=1633623434; x=1634833034; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Q7eVBZCTatDzjiSjzYZyGpbAjMFfOUmBoebrf8W2XxU=; b=ZQlY7ge2G3vnbP6Wg1iYlrmw6V4V0CNmEW7Puqd9iFb8vEgU+0e1J4Eq sG+D/KpsFbC64tMXKVku4Dy9X1tUFRKnb/jJIeDXZbNGj0g71AMaLeCcb 2BKpxHAPva8UCacWWE1m/RHHLVEC9upfKyPy8c9m5YELt0Fgnrl/uBzlz w=; IronPort-PHdr: =?us-ascii?q?A9a23=3A4oU5Cx9b0oNO+/9uWD/oyV9kXcBvk7rxNw8Rr?= =?us-ascii?q?JEgjuEGfqei+sHkO0rSrbVogUTSVIrWo/RDl6LNsq/mVGBBhPTJsH0LfJFWE?= =?us-ascii?q?RNQj8IQkl8vBceEDQvwK/u5JyA/Fd5JAVli+XzzOENJGcH4MlvVpHD67TMbF?= =?us-ascii?q?hjlcwRvIeGgEY/JhMPx3Oe3qPXu?= IronPort-Data: =?us-ascii?q?A9a23=3Avzv0pKpU93hct5VMPTWYZ+KE6x5eBmKCZxIvg?= =?us-ascii?q?KrLsJaIsI4StFCztgarIBnXb6neNmvyKIskbNy/pk4B65TSzIQwSAFv+yo9F?= =?us-ascii?q?y9D8uPIVI+TRqvS04x+DSFioHqKZKzyU/GYRCwPZiKa9krF3oTJ9yEmjPjQH?= =?us-ascii?q?uWkU4YoBwgoLeNaYHZ54f5cs7ZRbr5A2bBVMivV0T/Ai5S31GyNg1aYBlkpB?= =?us-ascii?q?5er83uDihhdVAQw5TTSbdgT1LPXeuJ84Jg3fcldJFOgKmVY83LTegrN8F251?= =?us-ascii?q?juxExYFENiplPPwdVcHB+eKewOPkXFRHaOlh3CupARrjf19b6VaOBwR0mnX9?= =?us-ascii?q?zxy4I0lWZiYRwwtN6Hkk+UGWB4eGCZ7VUFD0O6cfSLk6ZPOlSUqdFOpmZ2CF?= =?us-ascii?q?noeJpUC++B4RGpO/P0CMxgMYwyNweWsz9qTUfF2h8IsBMjmII1ZvWtvpRnbB?= =?us-ascii?q?PMrWtbFBarX5NRY1S08rs5TAevEatUUaHxkaxGoSwdFPVEWA5trwL+qm3/+a?= =?us-ascii?q?zBC7lSYuYI75mHJx0pw3aTjdt3PdbSiX8Jfk1yEjnjP5HbkAVccOcD34TWf/?= =?us-ascii?q?32tg+7VhiDqcI0XHby8sPVthTWuKsY7YPENfUGwrf/8gUmkVpcGcwof+zElq?= =?us-ascii?q?u4580nDczU0ZDXgyFbsg/LWc4c4/zUG1Tyw?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A0grnxaitvYSizJSxWAA0ewaHvXBQX3h13D?= =?us-ascii?q?Abv31ZSRFFG/FwyPrOoB1L73HJYWgqN03IwerwR5VpQRvnhPlICPoqTMmftW?= =?us-ascii?q?jdySqVxeRZjbcKrAeQYBEWmtQtsJuINpIOdOEYbmIKzfoSgjPIaerIqePvmM?= =?us-ascii?q?vD6IuurAYOcegpUdAc0+4TMHf8LqQCfng/OXNPLuvk2iMonUvFRV0nKuCAQl?= =?us-ascii?q?UVVenKoNPG0Lj8ZwQdOhIh4A6SyRu19b/TCXGjr1QjegIK5Y1n3XnOkgT/6K?= =?us-ascii?q?nmmeq80AXg22ja6IkTsMf9y+FEGNeHhqEuW3fRY0eTFcFcso+5zXcISdKUmR?= =?us-ascii?q?AXeR730k4d1vFImjfsl6eO0EPQMkfboW0TAjTZuC6laDPY0LzErXQBepB8bU?= =?us-ascii?q?YzSGqE16Lm1+sMjZ6jlljpxKZ/HFfOmj/w6MPPUAwvnk2ooWA6mepWlHBHV5?= =?us-ascii?q?ACAYUh4LD30XklW6voJhiKorzP0dMee/309bJTaxeXfnrZtm5gzJilWWkyBA?= =?us-ascii?q?6PRgwHttaO2zZbkXhlxw9ArfZv0Uso5dY4Ud1J9u7EOqNnmPVHSdIXd7t0AK?= =?us-ascii?q?METdGsAmLATBrQOCaZIEjhFqsAJ3XRwqSHrIkd9aWvYtgF3ZEykJPOXBdRsn?= =?us-ascii?q?MzYVvnDYmU0JhC4nn2MS2AtPTWu4hjDr1Cy/PBrZbQQFi+oWEV4r2dSq8kc7?= =?us-ascii?q?/mst6ISeZrP8M=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CJAABMHF9h/5JdJa1aHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUYGAQELAYEgMFEHd1o3MYgOA4U5iAkDinSPeIEugSUDVAs?= =?us-ascii?q?BAQENAQEqAQwKBAEBhDlFAoJIAiU1CA4BAgQBAQESAQEFAQEBAgEGBIERE4V?= =?us-ascii?q?oDYZCAQEBAQMBARALIwEBLAsBDwIBCBEDAQIhAwQHIQYLFAkIAgQOBQgTB4J?= =?us-ascii?q?QgX5XAy8BDqELAYE6AoofeIEzgQGCCAEBBgQEgTYBE0GCfw0LgjUDBoE6AYM?= =?us-ascii?q?AhBOBHoVXJxyBSUSBFAFDgWaBAT6CIUIBAQIBgV8eBgcJgxmCDCKKTXECYgQ?= =?us-ascii?q?yERAvLCAKSBELAhg6Op4Knw9nCoMwgTOJE4gchSN9hgUUg2pCiyqXQIcTm1+?= =?us-ascii?q?DP5BGhHMCBAIEBQIOAQEGgWMBOIFZcBU7gjUBATJRGQ+IS4VVDBYVGYMihRS?= =?us-ascii?q?FSnQCNgIGCwEBAwmUcQEB?= X-IronPort-AV: E=Sophos;i="5.85,355,1624320000"; d="scan'208,217";a="934230752" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Oct 2021 16:17:12 +0000 Received: from mail.cisco.com (xbe-aln-003.cisco.com [173.36.7.18]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 197GHBM0030373 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 7 Oct 2021 16:17:11 GMT Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xbe-aln-003.cisco.com (173.36.7.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 7 Oct 2021 11:17:11 -0500 Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 7 Oct 2021 11:17:10 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Thu, 7 Oct 2021 11:17:10 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dQ8L5YzwWVMnPP7+KYwnAn2FiAsORfHTMFYvaRmZDMvUCqByVCi3eLs6Nt1zmLSqxivBEbWGaJwUPXhkOqg/egBK0i9zrDNuRvjloj2fkqz/7Ixivgb2o8++fyCZLRe4z2WbtdHOTdktVz9H7VVw34WdVXD7L2nbUaAU7hY8WY3llfzJwwNaeoNucJArAWoO8UUp5D2VOgBH+VDci9viHTWNBoSIjPPqD65dzUKFBlmPwL3dTIn+AVEBMLkXp/i2eJPzts/TrGHQjVu/hcraSuDskpVPsYK7wa/uENxhMp7CM7leeMQK9ix9an+omwgsrbzvVtroN3Xk3g48W+Ditg== 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=BkVD9IjkWmMBSL7h7mHV2t7ZLaF+tNfPHtZMuQg0QLo=; b=IRxRzsUxnyssC2bh5X7xIc+2IqLPNn4pRSgWiZkJZSvrZZWsX8cMXwS9rJWRDHFXosbFFAT2Zwx4XxjXc1OOUuRImsl+FphAThrAtQFNgGh0ZVYOyS7aWC7WlQalAQfLF8OfUARt1CyJci0ahnbhrO+Ax8vhi7mRANmWQRt4In0rQrwIGA8lErIuminRbI7284o7WcZPypKeunJqwnvtUj/a/qXb/M2x2ldY9BonqSFAi4MOtsFunUMMgCPZngOum/DJjWkyyyDFI8bIP7LbNwrhjOOFQxGKSV4WCN8XpzWnJBrHFTH/steV1GlMf37RcIVcJWJnCbI97tsIM4X5fQ== 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=BkVD9IjkWmMBSL7h7mHV2t7ZLaF+tNfPHtZMuQg0QLo=; b=DI1oCdL6788kmhWapFa1WNatKaU2fm+wU2zTiOcRnyVlqm5450nT73i6gFtPMApohKZyq1UqwKX/jJECKPZWCMQxCkp9M53n0mZLj+42kfEG3bxz35TQ1ktZP8gHRSs6XE8OdEYxztmJXBnYVJm1jMG+SCP06TPyTHHfjKYDdyg= Received: from CO6PR11MB5650.namprd11.prod.outlook.com (2603:10b6:5:35a::9) by CO6PR11MB5652.namprd11.prod.outlook.com (2603:10b6:5:35e::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.18; Thu, 7 Oct 2021 16:17:09 +0000 Received: from CO6PR11MB5650.namprd11.prod.outlook.com ([fe80::6071:7cb6:d30e:b0d]) by CO6PR11MB5650.namprd11.prod.outlook.com ([fe80::6071:7cb6:d30e:b0d%4]) with mapi id 15.20.4587.019; Thu, 7 Oct 2021 16:17:09 +0000 From: "Francois Clad (fclad)" To: Greg Mirsky CC: Robert Raszuk , Ron Bonica , James Guichard , SPRING WG , "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQCeJTAAAC58nBAAAQ3tgAAHRGEgAAHK+wAAAookgAAiGUeHAAc4nAAAMAjOBA== Date: Thu, 7 Oct 2021 16:17:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5a311cf6-01f5-4140-9612-08d989adea12 x-ms-traffictypediagnostic: CO6PR11MB5652: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: M53AYJFgm1EC+nziuXTj5Neoa3/lBe8gsAxp4mczYgiCJBcn9wmgGj+vCROYXgUhEsC4ZkOQUx7C/ZJqc/4RTYfNDooYVtWgYGlfOgesBek9q5YXYq2Bfnj5xl0gxZfrya+0Vj21GJCj/NFIHd+NHnMYrZdMia/CSvzeW84NRVd5NxGMkiuCCHqpJCDKuCuyZ8p7cPEn+VRHmR/iUr5ZuSLTwXoyu7t1ByGP27vmknM/e36PQ8mWWRYKJP4LVoM/YiHjH+AFuLoP/rvjba941iN5Lg3JgYd2uWeAH6B9WSy65FXXD+637ff4GEglvvGMRv6YcG5ucfXNxyNjKkW8QEoT3Fmd62xmA3lKW9Xu08uzE91JTtY+FIYplf3byxqArMkEYrlcUqa4MkUStTK3ZHQtEECiM8WlwLQ8+2NCe1J2dkklc83zEpKVibbBRh6i4O4KwvXrmhZr60YdNk0sArCYYBqVszy4XEpKZHMS43FkKJaDpUd5CwPWVrmVMnf1G3nZtYSCRRRJleta34WlO6WTmsnFD0NKhWawwWj/AT2Yq2nnNTS/rUIjwzXz4GBSbn3Oc+ORCTMwzzZxyqEEGDoGFNKlQWjqvdohlUUOIUYyj3Sn2SaV5/bYSjNpdUhnskmSr5i4V6kRAJMd5fBkbAJUUnpiH4FG4q6ccJClCBwm2j8nz+rdEzm6EDPnr4YUCL3GaoY+5oxulp97QdbpbU/MDy/TWoYWAwkVX1hSMGPkAGsc9+rJgildeGsIAEC+LB+/KicikJfHWLJVrTSSNNH/fSgMWhXEzqEFH9scWM2nFQOQs6gI2Sv0u4F/Ye8u1RCLpc0akKT7/oL/hBoHGg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR11MB5650.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(38100700002)(122000001)(71200400001)(66946007)(52536014)(508600001)(53546011)(6506007)(38070700005)(26005)(186003)(7696005)(91956017)(76116006)(64756008)(66476007)(66556008)(66446008)(8676002)(83380400001)(316002)(5660300002)(6916009)(2906002)(8936002)(4326008)(33656002)(86362001)(966005)(9686003)(55016002)(166002)(54906003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?88n95lgVoSIir9qVQjiaY//q79PRBsY/wn5X1ks4vIFSy2r9A8BGAJA2jvnh?= =?us-ascii?Q?RCHApl6O1y/rgPUJ57GZpdZA+WJVh5cXvgvPCBbV8W7XBlwyZHfkE0llwQF5?= =?us-ascii?Q?w8ytuQg2XUlkeN7+FHGw+l6WX1kiaVoEDdbkNYspg+gInZeF9TTbZf3QYdqo?= =?us-ascii?Q?rv/oRlKdQXlwka9tSmXJHkFA4FkChSHgrMBItRPSsxgJXrfdQKfQ2zGHqs8j?= =?us-ascii?Q?cHAvchooHi/UJeTG8njeuMcRrQYCTcvTPsZPk7Kj0Nc83YQfVDiG+Fbaf192?= =?us-ascii?Q?GWJwqT24bVinRzEmfTejNMvVeHrLKgL70G/XwfZ6XovvOPh9WiekprAwkUft?= =?us-ascii?Q?r6vtlAuv4rqiS+B03fbIvdhQUpuLXBtfPbIR0QtLYE7sZq2XUkEtcZLT8qnO?= =?us-ascii?Q?z1xqWzoixz1rO6nzgbKpmif1gMdzdV6QYgyhI4imIJkdIQvZ9YdyN+l852mf?= =?us-ascii?Q?5uot3uiGzbRHNo6pLMYtqukLbC2/wI1GVZCpW0iLXC5cxavlJFR5rUF/wKi5?= =?us-ascii?Q?4M2wwyIsRMfrfRYE6luDZtRglCy4mwcb6xqurmZF4T3tCbRtn46A57k8t6MA?= =?us-ascii?Q?WesCU5Ult7qaJ2dDVuAdmDA58pKJ6Pq75s51QB4Sfdo1ix0H7W4zDBtSr1+x?= =?us-ascii?Q?ph6Q5UhFNfsYue+4SGP2mKMLXVD4YkI+pPlVsO3e0d+Ls61gJ0u/rEHxLJMC?= =?us-ascii?Q?Cg5UxwShkSv3aPZia70GGm3NaS/1rrgLDeeU6aED+B++wRU75avTMaR9LU7K?= =?us-ascii?Q?uB0vrR6amCKONcw/xi877a6wFnQ6ukUQRLxXIq3g2/CAnsfE7zXTIWcpkdMq?= =?us-ascii?Q?Z57M8dipxk52v3G8IFXK93p/ZN2wDVdaGotPYsktDat93umfLfRSgPVO7Vdc?= =?us-ascii?Q?feRNqK3waYaHK3veZmSad8wDi3TLYG3Rv1iGQoHIZ/lEVaOo+WBCb7FCxTy7?= =?us-ascii?Q?+Gzgk6/LNQW4KE6t/pVK4XF+Tyy4RhUFQ75K2FDEmTcaXSC7kMwRNNnIvMkV?= =?us-ascii?Q?pqtHdaypKIXKdHnka+/kcWsV9z2oEVqDPsTaIcwd1xBCWOqvp1OgwA+wKzrA?= =?us-ascii?Q?0OlLHnA3XkiW7OG9Go10+LDcemYf6PbALH5FaK0ebzsnz5q7WVWB9z0I9WsE?= =?us-ascii?Q?nlbGLXG313eLrVVpzYQFR1mCc2hu4pWP0rMBHSYKjPAsjc/DOEZFGTmh9Keb?= =?us-ascii?Q?VZnMa79Ph5cnkD0TrE+c1U2bp3q/NfaqeXMMkqu0444lTI1jOhLIRdQ9Q4/h?= =?us-ascii?Q?4N5ujrAslxigUBMAKL49R5j71n8iTAl/H51p7QCjib9jGUhpRV1H+NkrRz5I?= =?us-ascii?Q?GuWNzq9jKdZbbYpmeBpWnAcBxp2diA7ZbCKNlOaZvSARxw=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO6PR11MB56507C80A718DB505DC97C73ACB19CO6PR11MB5650namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO6PR11MB5650.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5a311cf6-01f5-4140-9612-08d989adea12 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2021 16:17:09.6511 (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: xMXhGAZlvhfvTL94fmGC1pJzuar0X5hyZjEBnjClCjtbetUdW2BvzXoW4d+mvfDZ X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR11MB5652 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xbe-aln-003.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 07 Oct 2021 16:17:22 -0000 --_000_CO6PR11MB56507C80A718DB505DC97C73ACB19CO6PR11MB5650namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, It is the role of the SR Source Node [Section 3.1 of RFC 8754] to form the = segment list in the SRH. It learns about the available SIDs in the network = with their associated behavior and flavors via control plane and/or managem= ent plane protocols, as described in Section 8 of RFC 8986, and selects the= SIDs that are the most appropriate for the segment list. Each SR Segment Endpoint Node [Section 3.3 of RFC 8754] simply executes the= pseudocode of a locally instantiated SID when it receives a packet matchin= g that SID. The SR Segment Endpoint Node does not need to bother about the = behavior/flavor of the subsequent SRv6 SIDs. This SRv6 logic applies to the C-SID flavors as well. The choice of flavors= for the SIDs in the SID List is up to the SR Source Node. It is indeed possible to mix SIDs of different C-SID flavors in the same SR= H, and even in a single C-SID container. Thanks, Francois From: Greg Mirsky Date: Wednesday, 6 October 2021 at 19:19 To: Francois Clad (fclad) Cc: Robert Raszuk , Ron Bonica , James Guichard , SPRING WG= , spring-chairs@ietf.org Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ Hi Francois, thank you for the clarification. It is still not clear how a node selects w= hich flavor of CSID to use on the next compressed CSID that may happen also= be in the next CSID container. As I understand it, a CSID container must u= se the same flavor of compression but CSID containers with different compre= ssion flavors in the same SRH are allowed. Is that correct understanding? Regards, Greg On Wed, Oct 6, 2021 at 7:05 AM Francois Clad (fclad) > wrote: Hi Greg, A node that supports this draft in its entirety can instantiate SRv6 SIDs (= e.g., End and End.X SIDs) with any of the three C-SID flavors. In particular, a node can instantiate multiple SRv6 SIDs bound to different= C-SID flavors, possibly with different C-SID lengths. It can also instanti= ate SRv6 SIDs with behaviors and flavors defined in RFC 8986. As defined in Section 4.3 of RFC 8754 and again in Section 3 of RFC 8986, u= pon receiving an IPv6 packet with a destination address matching a FIB entr= y that represents one of these locally instantiated SIDs, the node processe= s the packet according to the behavior (and flavor(s)) (i.e. pseudocode) of= that SID. RFC 8754 and 8986 have already standardized these mechanisms and the C-SID = draft only leverages the same SRv6 dataplane to introduce new endpoint flav= ors for compression. Francois From: spring > on b= ehalf of Greg Mirsky > Date: Tuesday, 5 October 2021 at 23:37 To: Robert Raszuk > Cc: Ron Bonica >, James Guichard >, SPRING WG >, spring-chairs@ietf.org > Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ Hi Robert, as I understand it, you believe everything that is written in the draft. I = hope you can help me find an answer to one simple question: Can a node that supports this draft in its entirety, i.e., supports all "fl= avors" defined in the document, process received SRv6 packet with the SRH e= ncoded according to the specification? So far, the proponents of the draft referred to "planning" how flavors of S= Rv6 SID compressed. To the best of my understanding, that is is a clear dem= onstration of the incompatibility between flavors defined in the CSID draft= . Regardless of what is written in it. Regards, Greg On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk > wrote: Ron & SPRING WG chairs, Through this discussion we first have seen a debate if we need one or more = data planes to compress SIDs in SRv6. WG clearly stated we need one. Following that we have observed a first terminology shift to see if asking = how many solutions should be supported will work any better. To that many W= G members clearly stated that they support one solution. Well please notice that the draft in question in its introduction states: Abstract This document defines a compressed SRv6 Segment List Encoding in the Segment Routing Header (SRH). This solution does not require any SRH data plane change nor any SRv6 control plane change. This solution leverages the SRv6 Network Programming model. So based on my understanding of English the entire draft talks about a sing= le solution. Then suddenly a new question popped up: how many behaviours are acceptable. I bet number of folks including myself said "one" keeping in mind previous = discussions and the definition of "one" meaning based on the SRv6 data plan= e in compliance to [RFC8402], [RFC8754] and [RFC8986]. Interestingly enough the draft in question defines not behaviours but flavo= rs as new variants of the already defined behaviors in Standards Track RFCs= . Namely it defines: 4.1. NEXT-C-SID Flavor 4.2. REPLACE-C-SID Flavor The newly defined behaviour End.XPS is optional. So if there is anything to ask here is to check if WG is ok with two flavor= s or not. I do not recall that question has ever been asked formally during= the WG adoption call. With that let's note that optimal compressed SID size may be different netw= ork to network. One size does not fit all. Draft says: 6.1. C-SID Length The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A C-SID length of 16-bit is recommended. The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths. A C-SID length of 32-bit is recommended. While I personally think 8-bit should be an option, if we choose a single f= lavor we will introduce suboptimality for no good reason. Hardware capable = of supporting any flavor clearly can do LPM on locator. Also hardware capab= le of supporting one flavor can support few other flavors as this is pretty= much just an offset game. Kind regards, Robert On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica > wrote: Pablo, Ae you sure? Please look at the question as Joel asked it ( https://mailarc= hive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ ). = Ron _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_CO6PR11MB56507C80A718DB505DC97C73ACB19CO6PR11MB5650namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Greg,<= o:p>

&nbs= p;

It is the= role of the SR Source Node [Section 3.1 of RFC 8754] to form the segment l= ist in the SRH. It learns about the available SIDs in the network with thei= r associated behavior and flavors via control plane and/or management plane protocols, as described in Section 8= of RFC 8986, and selects the SIDs that are the most appropriate for the se= gment list.

&nbs= p;

Each SR S= egment Endpoint Node [Section 3.3 of RFC 8754] simply executes the pseudoco= de of a locally instantiated SID when it receives a packet matching that SI= D. The SR Segment Endpoint Node does not need to bother about the behavior/flavor of the subsequent SRv6 SIDs.<= o:p>

&nbs= p;

This SRv6= logic applies to the C-SID flavors as well. The choice of flavors for the = SIDs in the SID List is up to the SR Source Node.

&nbs= p;

It is ind= eed possible to mix SIDs of different C-SID flavors in the same SRH, and ev= en in a single C-SID container.

&nbs= p;

Thanks,

Francois<= o:p>

&nbs= p;

&nbs= p;

From: Greg Mirsky <gre= gimirsky@gmail.com>
Date: Wednesday, 6 October 2021 at 19:19
To: Francois Clad (fclad) <fclad@cisco.com>
Cc: Robert Raszuk <robert@raszuk.net>, Ron Bonica <rbonica= =3D40juniper.net@dmarc.ietf.org>, James Guichard <james.n.guichard@fu= turewei.com>, SPRING WG <spring@ietf.org>, spring-chairs@ietf.org = <spring-chairs@ietf.org>
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.= org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<= /p>

Hi Francois,

thank you for the clarification. It is still not cle= ar how a node selects which flavor of CSID to use on the next compressed CS= ID that may happen also be in the next CSID container. As I understand it, = a CSID container must use the same flavor of compression but CSID containers with different compression flavo= rs in the same SRH are allowed. Is that correct understanding?

 

Regards,

Greg

 

On Wed, Oct 6, 2021 at 7:05 AM Francois Clad (fclad)= <fclad@cisco.com> wrote:=

Hi Greg,

 

A node that supports this draft in its entirety can instantiate SR= v6 SIDs (e.g., End and End.X SIDs) with any of the three C-SID flavors.

 

In particular, a node can instantiate multiple SRv6 SIDs bound to = different C-SID flavors, possibly with different C-SID lengths. It can also= instantiate SRv6 SIDs with behaviors and flavors defined in RFC 8986.

 

As defined in Section 4.3 of RFC 8754 and again in Section 3 of RF= C 8986, upon receiving an IPv6 packet with a destination address matching a= FIB entry that represents one of these locally instantiated SIDs, the node processes the packet according to the = behavior (and flavor(s)) (i.e. pseudocode) of that SID.

 

RFC 8754 and 8986 have already standardized these mechanisms and t= he C-SID draft only leverages the same SRv6 dataplane to introduce new endp= oint flavors for compression.

 

 

Francois

 

From: spring <spring-bounces@ietf.o= rg> on behalf of Greg Mirsky <gregimirsky@gmail.com>
Date: Tuesday, 5 October 2021 at 23:37
To: Robert Raszuk <robert@raszuk.net>
Cc: Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org>, James Guic= hard <james.n.guichard@futurewei.com>, SPRING WG <spring@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/

Hi Robert,

as I understand it, you believe everything that is written in the = draft. I hope you can help me find an answer to one simple question:

Can a node that supports this draft in its entirety, i.e., support= s all "flavors" defined in the document, process received SRv6 pa= cket with the SRH encoded according to the specification?

So far, the proponents of the draft referred to "planning&quo= t; how flavors of SRv6 SID compressed. To the best of my understanding, tha= t is is a clear demonstration of the incompatibility between flavors defined in the CSID draft. Regardless of what is writ= ten in it.

 

Regards,

Greg

 

On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk <robert@raszuk.net> wrote:=

Ron & SPRING WG chairs,

 

Through this discussion we first have seen a debate if we need one= or more data planes to compress SIDs in SRv6. WG clearly stated = we need one. 

 

Following that we have observed a first terminology shift to see i= f asking how many solutions should be supported will work any better. To th= at many WG members clearly stated that they support one solution. 

 

Well please notice that the draft in question in its introduction = states: 

 

Abstract

   This document defines a compressed SRv6 Segment List Encoding = in the
   Segment Routing Header (SRH).  This solution does = not require any SRH
   data plane change nor any SRv6 control plane change.  = This solution
   leverages the SRv6 Network Programming model.

 

So based on my understanding of English the entire draft talks abo= ut a single solution. 

 

Then suddenly a new question popped up: how many behaviours a= re acceptable. 

 

I bet number of folks including myself said "one" keepin= g in mind previous discussions and the definition of "one" meanin= g based on the SRv6 data plane in compliance to [RFC8402], [RFC8754] and [RFC8986].

 

Interestingly enough the draft in question defines not behaviours = but flavors as new variants of the already defined behaviors in Standards T= rack RFCs. Namely it defines: 

 

4.1.  NEXT-C-SID Flavor

4.2.  REPLACE-C-SID Flavor

 

The newly defined behaviour End.XPS is optional. 

So if there is anything to ask here is to check if WG is ok with two flavor= s or not. I do not recall that question has ever been asked formally d= uring the WG adoption call. 

 

With that let's note that optimal compressed SID size may be diffe= rent network to network. One size does not fit all. Draft says: 

6.1.  C-SID Length

   The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengt= hs.  A
   C-SID length of 16-bit is recommended.

   The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID le= ngths.
   A C-SID length of 32-bit is recommended.

 

While I personally think 8-bit should be an option, if we choose a= single flavor we will introduce suboptimality for no good reason. Hardware= capable of supporting any flavor clearly can do LPM on locator. Also hardware capable of supporting one flavor can = support few other flavors as this is pretty much just an offset game. =

 

Kind regards,

Robert

 

 

 

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

--_000_CO6PR11MB56507C80A718DB505DC97C73ACB19CO6PR11MB5650namp_-- From nobody Thu Oct 7 09:43:51 2021 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 2C1CE3A0BCE; Thu, 7 Oct 2021 09:43:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVTMuVwTGT2t; Thu, 7 Oct 2021 09:43:43 -0700 (PDT) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 E319E3A0BCF; Thu, 7 Oct 2021 09:43:42 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id na16-20020a17090b4c1000b0019f5bb661f9so5597993pjb.0; Thu, 07 Oct 2021 09:43:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=AOteW0oNaVVJ19pFS3NeSoA3TMnTp2lht59y0BWaoJ4=; b=V9IEZi0uNfA3Ih/K9EsQQQee3CM6I6tX5H9wNFld+LQC5S9NsRIIhA/Tz2ng7B90SN xNPAm1onMEyAT+B7PMvNYx1aS8J4VOu5qCDTCJ0a4rtcY4VRxSPKJM/SCVLb/1UMq1AC Xj51JCdF6dAyO4uOyNvpb6ScBTIsdlC0jvaOv5VPDksz+9d8cVU+4hFwH5Mcb+2kxpqk rx+4o0bh377s/HYOoYPU7NyOHHgAJhFb+eh1rV6/mz9dxYRUs6e6+CguyDWlRIBMl9Ik vDEn6PAdT7hbONB3/wSrFTZTuC7m86u7bzj4tyb2A3fRixbFvJuiuYqpXICLVDjcJnrf LKkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=AOteW0oNaVVJ19pFS3NeSoA3TMnTp2lht59y0BWaoJ4=; b=QQDpOQthGwQ8Wkqbn3vaadtuhsm3EpmYFy8rzLBhXYk1GuV/EoTL7+iDKfTHDFRtvq nX4XhSS8LP4Acxp3xVEspRA5ocjCvJzP+WJpU6bBaQUZa9j0jdMomn86hULbMGPND6X9 FsTQF0/0thFOuYSxrTN8vIZrwotDw0xP2MGG4NHfthFg3cjs8ZH9QeimHZbHUNKP1wx/ 0lV0ad21V9suR01O9SpO8STjwIGhI/z3usvxYp7AqcHvyS46CodwitE0UsOYIihA7g3f gNyYHEWE/Y0qTMKBz325/kB1HIgFA9vb7TbeUCy925IVF+5fO9TOyOK8isoBIuMmqvId 5NfQ== X-Gm-Message-State: AOAM531nbkUmPoU2Rqxm0pB7zAUMFjKWec1gd3HEm1Gj0+WK/sUNY6j8 NPHE9CGVYrmcQENsSmfEyy0= X-Google-Smtp-Source: ABdhPJxUVKqFouZvMBpVBQgXPbq63EBGDn0QCrIITrJKsi5X8yKYqM7Ml/ybeYvvl5zrSweLOaZkFw== X-Received: by 2002:a17:90a:9b84:: with SMTP id g4mr4202866pjp.123.1633625022057; Thu, 07 Oct 2021 09:43:42 -0700 (PDT) Received: from smtpclient.apple ([66.129.239.11]) by smtp.gmail.com with ESMTPSA id c3sm13426pgw.74.2021.10.07.09.43.39 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Oct 2021 09:43:41 -0700 (PDT) From: Colby Barth Message-Id: <13C14888-A870-443E-8532-6631E5E0BD51@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_B60FBCB1-99A3-4589-A320-23EE39108C4E" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Thu, 7 Oct 2021 12:43:38 -0400 In-Reply-To: Cc: James Guichard , "EXT-Andrew.Alston@liquidtelecom.com" , SPRING WG , "spring-chairs@ietf.org" To: Ron Bonica References: X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-rv6-srh-compression/ 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, 07 Oct 2021 16:43:48 -0000 --Apple-Mail=_B60FBCB1-99A3-4589-A320-23EE39108C4E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 to Ron=E2=80=99s comments. =E2=80=94Colby=20 > On Oct 5, 2021, at 2:56 PM, Ron Bonica = wrote: >=20 > Jim, > =20 > The call for adoption has already been posted. There is no way to put = that toothpaste back into its tube. However, I strongly recommend = against such calls for adoption in the future. > =20 > Normally, the authors of a document are encouraged to answer technical = questions as a condition of adoption. Bullet points 1, 2, and 4 in the = call for adoption defer that requirement until WG last call. Could this = be why technical questions are not being addressed during the call for = adoption. > =20 > In some extreme conditions, it may be necessary to modify the usual = call for adoption procedure. But these exceptional conditions have not = been articulated. > =20 > It is unfortunate that two of the three working group chairs are also = co-authors of the draft. While there may not have been any impropriety, = the appearance of impropriety is difficult to avoid. > =20 > = Ron > =20 > =20 > =20 > Juniper Business Use Only > From: spring > On Behalf Of James Guichard > Sent: Monday, October 4, 2021 11:10 AM > To: EXT-Andrew.Alston@liquidtelecom.com = = >; SPRING WG > > Cc: spring-chairs@ietf.org > Subject: Re: [spring] WG Adoption call for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = > =20 > [External Email. Be cautious of content] > =20 > Andrew, > =20 > As stated in our email of September 9th, the chairs communicated that = the working group reached rough (quite clear) consensus for = standardizing one data plane solution to compress segment routing over = IPv6. In addition to this there was an inclination toward using the CSID = document as the basis for our work in this area. The chairs recognized = that there was however disagreement as to whether this document, having = multiple SRv6 EndPoint behaviors, could be considered consistent with = the working group consensus for a single data plane solution. This issue = quite clearly needed to be addressed, and the chairs, recognizing that = the working group is keen to make progress in this area, had the option = of trying to resolve the issue prior to issuing an adoption call, or = give the working group the opportunity to express their opinions as part = of a call for adoption. > =20 > Those who feel that we need to resolve the consistency issue before = adoption, as with those who think this is not a good basis for the WG = work, are free and expected to object to the WG adopting the document. = That is distinct from objecting to the chairs issuing the adoption call. > =20 > In essence, the chairs have combined the question of when to resolve = consistency and the question of whether this document is a good basis = for the WG into one call. > =20 > Yours, > =20 > Jim, Bruno & Joel > =20 > =20 > From: Andrew Alston >=20 > Sent: Friday, October 1, 2021 4:21 PM > To: James Guichard >; SPRING WG > > Cc: spring-chairs@ietf.org > Subject: Re: WG Adoption call for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = > =20 > Sorry =E2=80=93 but =E2=80=93 I=E2=80=99m a little confused here. > =20 > Because the way I look at this =E2=80=93 the working group clearly = stated that they wished for a single behavior =E2=80=93 and this =E2=80=93= does not deliver that =E2=80=93 it is two separate behaviors. As such = =E2=80=93 I see this call for adoption =E2=80=93 irrespective of the = merits or lack thereof of the draft, as a clear defiance of the stated = will of the working group. > =20 > This is simply does not fit into the definition of bottom up approach = in my opinion =E2=80=93 and if this is the way that the chairs wish to = proceed =E2=80=93 then the only way to do that and still fit within the = bottom up approach is to first ask this working group for its consensus = to deviate from the single behacvior approach that the working group = agreed to. > =20 > As such =E2=80=93 I must strongly and unequivocally object to this = call for adoption > =20 > Andrew > =20 > From: spring > on behalf of James Guichard = > > Date: Friday, 1 October 2021 at 17:05 > To: SPRING WG > > Cc: spring-chairs@ietf.org = > > Subject: [spring] WG Adoption call for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = > Dear WG: > =20 > The chairs would like to express their appreciation for all the = responses received to our emails with reference to how the working group = wishes to move forward with respect to a solution for SRv6 compression. > =20 > The apparent inclination of the working group is to use = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = as the basis for its compression standardization work. = That is part of what this email attempts to confirm. > =20 > Because of the above the chairs would like to issue a 2-week WG call = for adoption ending October 15th for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = but with some clear guidelines as follows. By expressing = support for adoption of this document you are fully aware of and are = acknowledging that: > =20 > The SPRING working group is adopting a document that has multiple SRv6 = Endpoint behaviors. > The document is a =E2=80=9Cliving=E2=80=9D document; it may change as = it goes through review and analysis by the SPRING working group. > All open discussion points raised on our mailing list MUST be = addressed BEFORE said document is allowed to progress from the working = group to publication. A list of these discussion points will be = documented in the WG document and maintained by the document editor in = conjunction with the chairs. > If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open = issue be added to the document in the above-described open issues = section: > "Given that the working group has said that it wants to standardize = one data plane solution, and given that the document contains multiple = SRv6 EndPoint behaviors that some WG members have stated are multiple = data plane solutions, the working group will address whether this is = valid and coherent with its one data plane solution objective.". > =20 > Please consider the above guidelines as you decide on whether to = support or not this WG adoption. Please express clearly your reasoning = for support/non-support as well as any open discussion points you would = like addressed should the document be adopted into the working group. > =20 > Thanks! > =20 > Jim, Bruno & Joel > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring = --Apple-Mail=_B60FBCB1-99A3-4589-A320-23EE39108C4E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1 = to Ron=E2=80=99s comments.

=E2=80=94Colby 

On Oct = 5, 2021, at 2:56 PM, Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org> = wrote:

Jim,
 
The call for adoption has already = been posted. There is no way to put that toothpaste back into its tube. = However, I strongly recommend against such calls for adoption in the = future.
 
Normally, the authors of a = document are encouraged to answer technical questions as a condition of = adoption. Bullet points 1, 2, and 4 in the call for adoption defer that = requirement until WG last call. Could this be why technical questions = are not being addressed during the call for adoption.
 
In some extreme conditions, it may = be necessary to modify the usual call for adoption procedure. But these = exceptional conditions have not been articulated.
 
It is unfortunate that two of the = three working group chairs are also co-authors of the draft. While there = may not have been any impropriety, the appearance of impropriety is = difficult to avoid.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;            &= nbsp;           &nb= sp;          Ron
 
 
 
Juniper Business Use = Only
From: spring <spring-bounces@ietf.org> On Behalf = Of James = Guichard
Sent: Monday, October 4, 2021 = 11:10 AM
To: EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>; SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org
Subject: Re: [spring] WG Adoption = call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/
 
[External Email. Be cautious of content]
 
Andrew,
 
As stated in our email of = September 9th, the chairs communicated that the working group reached = rough (quite clear) consensus for standardizing one data plane solution = to compress segment routing over IPv6. In addition to this there was an = inclination toward using the CSID document as the basis for our work in = this area. The chairs recognized that there was however disagreement as = to whether this document, having multiple SRv6 EndPoint behaviors, could = be considered consistent with the working group consensus for a single = data plane solution. This issue quite clearly needed to be addressed, = and the chairs, recognizing that the working group is keen to make = progress in this area, had the option of trying to resolve the issue = prior to issuing an adoption call, or give the working group the = opportunity to express their opinions as part of a call for = adoption.
 
Those who feel that we = need to resolve the consistency issue before adoption, as with those who = think this is not a good basis for the WG work, are free and expected to = object to the WG adopting the document. That is distinct from objecting = to the chairs issuing the adoption call.
 
In essence, the chairs have combined the = question of when to resolve consistency and the question of whether this = document is a good basis for the WG into one call.
 
Yours,
 
Jim, Bruno & Joel
 
 
From: Andrew Alston <Andrew.Alston@liquidtelecom.com> 
Sent: Friday, October 1, 2021 = 4:21 PM
To: James Guichard <james.n.guichard@futurewei.com>; SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org
Subject: Re: WG Adoption call = for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/
 
Sorry =E2=80=93 but =E2=80=93 I=E2=80=99m a = little confused here.
 
Because the way I look at = this =E2=80=93 the working group clearly stated that they wished for a = single behavior =E2=80=93 and this =E2=80=93 does not deliver that =E2=80=93= it is two separate behaviors.  As such =E2=80=93 I see this call = for adoption =E2=80=93 irrespective of the merits or lack thereof of the = draft, as a clear defiance of the stated will of the working group.
 
This is simply does not = fit into the definition of bottom up approach in my opinion =E2=80=93 = and if this is the way that the chairs wish to proceed =E2=80=93 then = the only way to do that and still fit within the bottom up approach is = to first ask this working group for its consensus to deviate from the = single behacvior approach that the working group agreed to.
 
As such =E2=80=93 I must =  strongly and unequivocally object to this call for adoption
 
Andrew
 

From: spring <spring-bounces@ietf.org> on behalf of James Guichard <james.n.guichard@futurewei.com>
Date: Friday, 1 October 2021 = at 17:05
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
Subject: [spring] WG Adoption = call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/

Dear = WG:
 
The chairs would like to = express their appreciation for all the responses received to our emails = with reference to how the working group wishes to move forward with = respect to a solution for SRv6 compression.
 
The apparent inclination = of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ as the basis for its = compression standardization work. That is part of what this email = attempts to confirm.
 
Because of the above the = chairs would like to issue a 2-week WG call for adoption ending October = 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ but with some clear = guidelines as follows. By expressing support for adoption of this = document you are fully aware of and are acknowledging that:
 
  1. The SPRING working group is adopting = a document that has multiple SRv6 Endpoint behaviors.
  2. The document is = a =E2=80=9Cliving=E2=80=9D document; it may change as it goes through = review and analysis by the SPRING working group.
  3. All open = discussion points raised on our mailing list MUST be addressed BEFORE = said document is allowed to progress from the working group to = publication. A list of these discussion points will be documented in the = WG document and maintained by the document editor in conjunction with = the chairs.
  4. If this document is adopted by the working group, the = chairs specify as part of the adoption call that the following text = describing an open issue be added to the document in the above-described = open issues section:
    • "Given that the working group = has said that it wants to standardize one data plane solution, and given = that the document contains multiple SRv6 EndPoint behaviors that some WG = members have stated are multiple data plane solutions, the working group = will address whether this is valid and coherent with its one data plane = solution objective.".
 
Please consider the above guidelines as you = decide on whether to support or not this WG adoption. Please express = clearly your reasoning for support/non-support as well as any open = discussion points you would like addressed should the document be = adopted into the working group.
 
Thanks!
 
Jim, Bruno & Joel
 
 
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

= --Apple-Mail=_B60FBCB1-99A3-4589-A320-23EE39108C4E-- From nobody Thu Oct 7 10:28:57 2021 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 EF2E23A0CAD; Thu, 7 Oct 2021 10:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=hIJertyw; dkim=pass (1024-bit key) header.d=juniper.net header.b=Y9/miyK4 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 8Z7364aKCYOG; Thu, 7 Oct 2021 10:28:48 -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 DE2D53A0CB1; Thu, 7 Oct 2021 10:28:48 -0700 (PDT) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 197HFKe7021892; Thu, 7 Oct 2021 10:28:43 -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=eFlomj0zuuVOzuzRMPQXilOA7h8vmvCeMOJOyFAuH2A=; b=hIJertywu67dxd99occ9wnMItiGcFwcyi1wESdRErA/ML0jF8c/Zy7E0ldapvnbxsrUp vWb4QKxxWBEHrV+PZnYV/WoKy5Di6CXGEWc5bJ1uw3kke1uBSjCYIGw8+T11uFn0jVGl P2G7ccIdbKxASQ7VlzbfS6ZN6XeXnVrvPImGEfhTH3w3c7mZKUwpyPRswCeEJQ5vDwoW L+Mb+hqLhqmUSEGVxpYzoXINdupNSn3g+P5q8es7RhNUN8YjhNdoySVUGH+foxrThUGs RnyIfXohusBycwuBLlfjtzWcwv0k5gaww/5HIZycrXWC6ZZWfNrdj3nCJ+Mwcch97w+k fQ== Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2170.outbound.protection.outlook.com [104.47.56.170]) by mx0a-00273201.pphosted.com with ESMTP id 3bj54r814p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 Oct 2021 10:28:43 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BNE/j6b6txY2jDwEq7HvdwIyFdMM32aEI4v3MCjyYGGMDayPk2YlxZ3WqVGEBtLAdan1TlaE5mDhspKUfMWQ8u57y0HI8lhG9RSIFTF0qkcJqC0gF9THy8HfMwtL5sILVhetswnnQZrnlG9ZTZOHboUmRRoGrzR2VQxzRoKDRihKGHoSU9JNabctRAwzvqOMC8qgBy4n66VKhR7L2asm1KXSXJcbL8GQ2jAu1Egbl/lLx53xAeIrDHK5n5anB/s7dpR7JSksc+pYaivGpO55MP/KyXRKivwL8U4drfcsmGAqQfuHjZ1mYdlm1SKlk//l7IMnAf6bt9ujQiu9laTD6g== 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=eFlomj0zuuVOzuzRMPQXilOA7h8vmvCeMOJOyFAuH2A=; b=Vf8LrjM+WkHZOAx/C1d6n+otjoDNZ7wZbTbDCRjIjL0gh4Lj+h6Irfnxz0FZCIZRt6mLN0bt7TSchuctMlWj+63ywlGRhhGqKN2alH5S9KQ2e2jqW25t6xb+FI90n4W2Mdsm12wihndqC3Dgt/ewf1acebDdhZG28UuCC2N1JMOGh6GcT0Ku/OgVqzmNP0AJoM6/Tj+7o3HNBKitUWkc7IUjIDNXRCURBP2xT9iNiQtz5z03z2//sxxkA1atcXoBI9u0sZlvbxm0CueXtqg0Hl9Ktoiu2NhE4Nzkqi9zB/ZwsbEJmf1spigPVPTT5vLwJEyj//TEcPQhf2BGkw9jpg== 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=eFlomj0zuuVOzuzRMPQXilOA7h8vmvCeMOJOyFAuH2A=; b=Y9/miyK402LkRpm+aTgnQ+GGh2gq/6sr3fpUp84HGcuhMYG4qUgWx0OkPsBfFkQb9B6DhCF4Hs/SjTTJC12UESGVyl/RJX414TncloiaMv5niCN4+yAHLWpYWbayhOSIc8bnSnAAuFCWJscNPgaqas0pn/V26/+DxUvIGFJ6suM= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by BL0PR05MB4658.namprd05.prod.outlook.com (2603:10b6:208:29::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.9; Thu, 7 Oct 2021 17:28:41 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4608.004; Thu, 7 Oct 2021 17:28:40 +0000 From: Ron Bonica To: "Darren Dukes (ddukes)" , Robert Raszuk CC: James Guichard , SPRING WG , "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQCeJTAAAC58nBAAAQ3tgAAHRGEgAAHK+wAAAE2t4QBcy6CQ Date: Thu, 7 Oct 2021 17:28:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-07T17:28:39Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=3b63744d-482a-4ff2-8b04-09990992a833; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ecea8f38-5ab2-46dd-d290-08d989b7e7b6 x-ms-traffictypediagnostic: BL0PR05MB4658: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: C8r+4phoGpcbY8rmlycxN5oaZsQ0z+AyUioEwrP3opbZqxKSsYUE1PwnELtvH7djvMz/rCu+oRmharC3IXQOQ+AbUL1K6cwthaM3rv28gXS8NyrL5WvVpcCp3rDVZZOJMN9OJrDKieyOFAwZC/wlQc87iUV///ssRywvBP/74DdT8LNI29U38tyX5XWD2zQDJGqQT0DZYs9PvSbgyEnk0txjPCJ5bnV8VO0ObOnOwCYbSrmTEmgp0ioZDKy9kgqexPBYdNsKQiP2VuLrtrq1Vo1sogFfCa9LQaIX/QdidLGQNYeaOgAENti3XVRWbAfV4DyQwqm1N+upZ3nvoh7UrSrZMV/CvRHxZkF+tkm0xpVBAhNYUtoAmqpZNn9F1WOXNMSUfVyehx/1u9WmlK4CA+GaJRfhBRj5/CZOkLmFiFdKqKhKDitLd8m4/oMuUioCeImw0NaCJ5qgnDnrQFa6AQb6uAAWsbdzPOzPjfHIM9R60vTfHQdkI96tj9ex5hep3buNF/oHOE9v1fbGmb7lYBV8bv9OAqUyOoWrAguvwONjDWoN7NYbi0MYl9P8lDX2ZBtzw6mv+2wmxK2jtFXSdE9z39DuabNtRYXpLA3Lvr1ZBqS5x9WNab0/+UUfhnEYmBp1ixCkAsOiJiBgjAZx/IkRWZZ7UCXq53G4yZyjjVCgH/tmSdyBIHZ0MT0ym1KtbPhHWsfo6Bt9+8C5v8yaqejehE7cgplHO5ktC5pfL5DeRS8Vm0hGTu/dIaO/5LCHVBN9Z+etfUvsdJnatRiP5gAg3X5eLywQFnBevyYsCCM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(4326008)(122000001)(66946007)(54906003)(71200400001)(186003)(316002)(38070700005)(9686003)(33656002)(8676002)(52536014)(64756008)(966005)(66476007)(6506007)(66556008)(8936002)(110136005)(53546011)(26005)(508600001)(83380400001)(7696005)(86362001)(66446008)(76116006)(38100700002)(5660300002)(55016002)(166002)(2906002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?2WZbm6VbIAytiR4L1jHAlSOsxw7MvePKbRqSeLmi0h4B5DkVqWoJXz4T2Zrf?= =?us-ascii?Q?zIl9Ns9DrcLMgfZ6MtuVv7vL/5YXql18RfL3P3Y0EIHupiDL/gdm01GOc/XE?= =?us-ascii?Q?tvZ6t/tOi4Vrom6vLfQFkYslOHZPE21oOOhCwBnm1Mbd9sp7RwP91SoOT8dI?= =?us-ascii?Q?7xJmAGd0mceoU3YiWoWd7Gq9e0sAbY6JOXjh5s7Lt8yeiAs6jegUHaos78aI?= =?us-ascii?Q?qqLoGOLNqhdd4ndRyo69w0fNAodhH/lRfSKL/81VrvF5eKoIBys9m44TobCw?= =?us-ascii?Q?RlC6tkOyWJyfa9IIO4KLH69biIhilghzrb7hx8CxkFpA1c56ynFvKSNldNDw?= =?us-ascii?Q?2H+Qieb8gpWgLj6/0Rw6FpGrxHSnnCaFeOCAc/4AFN64YT32ess5zgXsKmTg?= =?us-ascii?Q?9FjRkTgEVDLAf2tB4dbOvb/ELMlvGvV5NWffqfuuw4gO3dFnGrlg+FqrUtdf?= =?us-ascii?Q?uTuGWPP3e+TNuQV9ADOGtQzgacL0ioef2s05IjEgAtzDEiMIj4cM+G3QLswU?= =?us-ascii?Q?5TgpL0HjokMbSjsqdwUqytje3YAZxLZSVRi2auuyWvo3zs9rzI044w/Xzryr?= =?us-ascii?Q?rjGv7DC9wBkuE7RaNCOi76zRzk2ih6A9KSk9tGMKSOJ7/zUropD+9QMw2gz+?= =?us-ascii?Q?CKHnTp0PpLeMLG/zpVQo8g+1/mK7+kXHwSZXPQZJ7Cl1WXfMiwnWoytlqhNI?= =?us-ascii?Q?IpVCsYHUCV2IxQvR9qUYDcDXM9L89y4a5yM+bBYtjHeR52Cx88fuCMpS7taD?= =?us-ascii?Q?UztQNtWd47uj6GYp0xB1xlHW4Ny9cGnF9BPza7755+/GyUt+o1veJ2CV0Lkk?= =?us-ascii?Q?eQPcqrkQr/tyy4rEQScLZoP+elfy+qCQfJTa4U6Rpvy1pocpseG5cM3c5n2R?= =?us-ascii?Q?ptyr0+tx5DSYFNhbjbQcoNXzDtafAnsZofDLUxtslVfwKj4PW5TKeqoN4Spa?= =?us-ascii?Q?1Ln0TMbfS0l0ggH+RKYggTkQG5j9il2Ta46dDDRr+X/yOaCTLxn+hVfJ2Lq5?= =?us-ascii?Q?9gZG1jIIIawA3/HTzs9z8sQH3Rh/20lXsbp+NVFGnitHbT/nJt77eYkP7swv?= =?us-ascii?Q?u/0cH8ppTQZdhwT3h7+5/NPDZF3DF8iVdVZUKvgNxttgEe5mjjfN2VFpklTb?= =?us-ascii?Q?un08+wVGVEmi9pEUSVRLmm7CGKo4QccsaZ7QCHHB4XBEnmVWrci0hFsi0t04?= =?us-ascii?Q?Cesb3FO/BNy7pj7wIPxN8n6GR4KSJ7/Lj/JlA0DSVwY1gYQtfEwRVW0nfjbF?= =?us-ascii?Q?boB14Tpe63CUH4eLoFRaoiIfY2oSqerBorCF9M3zvngHaVYvhYvESo0njtca?= =?us-ascii?Q?DBubnzR9g35/BB8RCQY19wcs?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR05MB5316ABBF04B72965A1F65EC5AEB19BL0PR05MB5316namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ecea8f38-5ab2-46dd-d290-08d989b7e7b6 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2021 17:28:40.8195 (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: +14YWkpRq2h6EnFu05sqoqYf+CZqMHh9lQ13I0ww26+YJ9xxsm65eBdg2qNAyWCImS4g3etG4vCLKRQ8uSajxw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB4658 X-Proofpoint-ORIG-GUID: 7Eq5Dl7xOKC7FDHzVEQ290zf8w8DTImW X-Proofpoint-GUID: 7Eq5Dl7xOKC7FDHzVEQ290zf8w8DTImW X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-07_03,2021-10-07_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1015 priorityscore=1501 spamscore=0 mlxlogscore=999 phishscore=0 suspectscore=0 adultscore=0 bulkscore=0 impostorscore=0 mlxscore=0 malwarescore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110070113 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 07 Oct 2021 17:28:54 -0000 --_000_BL0PR05MB5316ABBF04B72965A1F65EC5AEB19BL0PR05MB5316namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks, We appear to dancing around the meaning of the words "solution", "behavior"= , and "flavor". While this dance is semantically elegant, it is neither pr= oductive nor uplifting. A better way to determine whether NEXT-C-SID and REPLACE-C-SID are both nee= ded is with a tiny bit more analysis. Specifically: * Determine whether NEXT-C-SID and a REPLACE-C-SID yield the same compr= ession efficiency. That is, update Table 12 through 15 in the analysis docu= ment, replacing the CSID column with a CSID NEXT-C-SID and a CSID REPLACE-C= -SID column. * Determine whether NEXT-C-SID and a REPLACE-C-SID are compatible with = one another. That is, provide an example where an SR path contains 8 segmen= ts. Odd numbered segments use NEXT-C-SID and even numbered segments use REP= LACE-C-SID. What does the packet look like when it arrives at the first seg= ment. How does it change at each subsequent segments. (Yes, I know that you= recommend against doing this for "operational simplicity". But we aren't t= rying to determine if it is simple. We are trying to determine if NEXT-C-SI= D and a REPLACE-C-SID work well together at all.) * Determine whether both are needed. That is, describe a use case where= one works well and another does not. I think that this will be much more productive than arguing about "flavors"= . That is, unless the flavor is "pumpkin spice". = Ron Juniper Business Use Only From: Darren Dukes (ddukes) Sent: Tuesday, October 5, 2021 11:58 PM To: Robert Raszuk ; Ron Bonica Cc: James Guichard ; SPRING WG ; spring-chairs@ietf.org Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ [External Email. Be cautious of content] Adding to this Robert, indeed SRv6 defines many behaviors. The question as= ked about a single 'behavior' could really only be interpreted as asking ab= out single 'solution', as you understood, since a single 'behavior' in SRv6= is non-sensical. The requirements draft section 4.2 alone requires multip= le behaviors be supported, and multiple compression levels in 4.4.4. Darren On 2021-10-05, 4:24 PM, "spring" > wrote: Ron & SPRING WG chairs, Through this discussion we first have seen a debate if we need one or more = data planes to compress SIDs in SRv6. WG clearly stated we need one. Following that we have observed a first terminology shift to see if asking = how many solutions should be supported will work any better. To that many W= G members clearly stated that they support one solution. Well please notice that the draft in question in its introduction states: Abstract This document defines a compressed SRv6 Segment List Encoding in the Segment Routing Header (SRH). This solution does not require any SRH data plane change nor any SRv6 control plane change. This solution leverages the SRv6 Network Programming model. So based on my understanding of English the entire draft talks about a sing= le solution. Then suddenly a new question popped up: how many behaviours are acceptable. I bet number of folks including myself said "one" keeping in mind previous = discussions and the definition of "one" meaning based on the SRv6 data plan= e in compliance to [RFC8402], [RFC8754] and [RFC8986]. Interestingly enough the draft in question defines not behaviours but flavo= rs as new variants of the already defined behaviors in Standards Track RFCs= . Namely it defines: 4.1. NEXT-C-SID Flavor 4.2. REPLACE-C-SID Flavor The newly defined behaviour End.XPS is optional. So if there is anything to ask here is to check if WG is ok with two flavor= s or not. I do not recall that question has ever been asked formally during= the WG adoption call. With that let's note that optimal compressed SID size may be different netw= ork to network. One size does not fit all. Draft says: 6.1. C-SID Length The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A C-SID length of 16-bit is recommended. The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths. A C-SID length of 32-bit is recommended. While I personally think 8-bit should be an option, if we choose a single f= lavor we will introduce suboptimality for no good reason. Hardware capable = of supporting any flavor clearly can do LPM on locator. Also hardware capab= le of supporting one flavor can support few other flavors as this is pretty= much just an offset game. Kind regards, Robert On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica > wrote: Pablo, Ae you sure? Please look at the question as Joel asked it ( https://mailarc= hive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ ). = Ron --_000_BL0PR05MB5316ABBF04B72965A1F65EC5AEB19BL0PR05MB5316namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks,

 

We appear to dancin= g around the meaning of the words “solution”, “behavior&#= 8221;, and “flavor”.  While this dance is semantically ele= gant, it is neither productive nor uplifting.

 

A better way to det= ermine whether NEXT-C-SID and REPLACE-C-SID are both needed is with a tiny = bit more analysis. Specifically:

 

  • Determine whether NEXT-C-SID and a R= EPLACE-C-SID yield the same compression efficiency. That is, update Table 1= 2 through 15 in the analysis document, replacing the CSID column with a CSID NEXT-C-SID and a CSID REPLACE-C-SID = column.
  • Determ= ine whether NEXT-C-SID and a REPLACE-C-SID are compatible with one another.= That is, provide an example where an SR path contains 8 segments. Odd numbered segments use NEXT-C-SID and even numbered segments use REPLACE-C-= SID. What does the packet look like when it arrives at the first segment. H= ow does it change at each subsequent segments. (Yes, I know that you recomm= end against doing this for “operational simplicity”. But we aren’t trying to determine if it is simple= . We are trying to determine if NEXT-C-SID and a REPLACE-C-SID work well to= gether at all.)
  • Determine whether both are needed. That is, describe a use case where on= e works well and another does not.

 

I think that this w= ill be much more productive than arguing about “flavors”. That = is, unless the flavor is “pumpkin spice”.

 

   &= nbsp;           &nbs= p;             =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =          Ron=

 

 

 

Juniper Business Use Only

From: Darren Dukes (ddukes) <ddukes=3D40ci= sco.com@dmarc.ietf.org>
Sent: Tuesday, October 5, 2021 11:58 PM
To: Robert Raszuk <robert@raszuk.net>; Ron Bonica <rbonica@= juniper.net>
Cc: James Guichard <james.n.guichard@futurewei.com>; SPRING WG= <spring@ietf.org>; spring-chairs@ietf.org
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.= org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

 

<= span lang=3D"EN-CA" style=3D"font-size:10.5pt;font-family:"Lato",= sans-serif;color:black">[External Email. Be cautious of content]=

 

Adding to this Robert, indeed SRv6 defines many beha= viors.  The question asked about a single ‘behavior’ could= really only be interpreted as asking about single ‘solution’, = as you understood, since a single ‘behavior’ in SRv6 is non-sen= sical.  The requirements draft section 4.2 alone requires multiple behaviors be su= pported, and multiple compression levels in 4.4.4.

 

Darren

 

On 2= 021-10-05, 4:24 PM, "spring" <spring-bounces@ietf.org> wrote:

 

Ron = & SPRING WG chairs,

 

Thro= ugh this discussion we first have seen a debate if we need one or more data= planes to compress SIDs in SRv6. WG clearly stated we need one.&= nbsp;

 

Foll= owing that we have observed a first terminology shift to see if asking how = many solutions should be supported will work any better. To that many WG me= mbers clearly stated that they support one solution. 

 

Well= please notice that the draft in question in its introduction states: =

 

Abst= ract

   This document defines a compressed SRv6 Segment List Encoding = in the
   Segment Routing Header (SRH).  This solution does = not require any SRH
   data plane change nor any SRv6 control plane change.  = This solution
   leverages the SRv6 Network Programming model.

 

So b= ased on my understanding of English the entire draft talks about a single s= olution. 

 

Then= suddenly a new question popped up: how many behaviours are acceptable= . 

 

I be= t number of folks including myself said "one" keeping in mind pre= vious discussions and the definition of "one" meaning based on th= e SRv6 data plane in compliance to [RFC8402], [RFC8754] and [RFC8986].

 

Inte= restingly enough the draft in question defines not behaviours but flavors a= s new variants of the already defined behaviors in Standards Track RFCs. Na= mely it defines: 

 

4.1.=   NEXT-C-SID Flavor

4.2.=   REPLACE-C-SID Flavor

 

The = newly defined behaviour End.XPS is optional. 

So if there is anything to ask here is to check if WG is ok with two flavor= s or not. I do not recall that question has ever been asked formally d= uring the WG adoption call. 

 

With= that let's note that optimal compressed SID size may be different network = to network. One size does not fit all. Draft says: 

6.1.  C-SID Length

   The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengt= hs.  A
   C-SID length of 16-bit is recommended.

   The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID le= ngths.
   A C-SID length of 32-bit is recommended.

 

Whil= e I personally think 8-bit should be an option, if we choose a single flavo= r we will introduce suboptimality for no good reason. Hardware capable = ;of supporting any flavor clearly can do LPM on locator. Also hardware capable of supporting one flavor can support few= other flavors as this is pretty much just an offset game. =

 

Kind= regards,

Robe= rt

 

 

 

On T= ue, Oct 5, 2021 at 9:43 PM Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org= > wrote:

Pablo,

 

Ae you sure? Please look at the question a= s Joel asked it ( https://mai= larchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ ).

 

       =             &nb= sp;            =             &nb= sp;            =             &nb= sp;           Ron<= o:p>

--_000_BL0PR05MB5316ABBF04B72965A1F65EC5AEB19BL0PR05MB5316namp_-- From nobody Thu Oct 7 10:41:24 2021 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 185493A0CC5; Thu, 7 Oct 2021 10:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=z0Fkpqas; dkim=pass (1024-bit key) header.d=juniper.net header.b=fwCcvMAQ 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 JkWfNPVjQJw9; Thu, 7 Oct 2021 10:41:16 -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 B6C673A0CC3; Thu, 7 Oct 2021 10:41:15 -0700 (PDT) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 197C98YG030943; Thu, 7 Oct 2021 10:41:10 -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=c37ieVglIdT4V6YJ4aw2TcEHHzWnlb7WyAFjAnFrRig=; b=z0Fkpqasb7PH40XqkYNIcHDutgq4XmHk6owWB+UxqjifUdA51kb1TQ7iCGg0ruxpzOjy NUeXwZH+Vuat/AyjLGcm6PHdT7iNDHEku2iRYnEeJuVQM2t8whpf4Ur3+uRVX4M775Uk NPODHbQMxgzqRMs2ry2eeuidOhJ5axTjHr3ab9j69Ino/mZi37oCrulvXlarmNb1btiX B+/dkhfJdbJ5M91h7W88NbEQgcHMJKTFecYn6SNQMkAF9EWPzYZCrITDMdnMnwg3agjY 6/kPN7XgKAw6vNmoBFopOp1m3MQCm3SqvCAiuj4xOeQuGCHSUuqe402sMDgxBnn4LYcQ 6A== Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2102.outbound.protection.outlook.com [104.47.58.102]) by mx0b-00273201.pphosted.com with ESMTP id 3bj0n4rq6t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 Oct 2021 10:41:10 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=njcqTCThNGxxJnREYQsKgTCLF1kj6MWRtwTHUamHk9KGIXVNlq6X4Cd2aUuwGRO35+Tpo70/Q+XvdJSMJW4pxjdOHFfampSjKFtdsa0ojT7RtwLkN9XDY0e0oRJ9BfNcVksdlWafsYhQIbY+5VuYi+ZT8j5HAFXwQUNL4vbQRtwcJCctOAS3RZjDagbvKHzpSmzh9YnixmGRQ1Qgx9gxhylqwuJjNbxjFBeTIhyU/RffdwObukCNa1ijGq6Gfplperp/bUjrcmox5S2mVlFE0gK8qvU8iER0gy4HfSFJf0q8YThCOWh2oa45gsYbNlkgBAYJ4V2IoPONws2BZM+0eg== 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=c37ieVglIdT4V6YJ4aw2TcEHHzWnlb7WyAFjAnFrRig=; b=BJ1E/rVaozmbqA93IW14xtMV1u8GEY1w1ehp1JM+hHlFuNVD/dvLFT25FqiKdWn3Ar0P/TeT4pwT9jht5nBkRsc7JxlSn8syRqenhb5PUz8WSd2oB2VDF1Kasg0uDyvRni9mUzRLtdhXB1XG1/xTCZnQ3nVZsPVEzPw5eyHgZeuVzXQtR5qKuXCe/kBBn0+sfj0pbGtWamIx4w6tuESIVJ1UUu6jR7nQcVqyxNgNNnQDUUtpFlPA9h2dCsHdDB1VIF7FuwwDVbPAR9UCGPJ/DyUlo0bqCds9dExsHk/+07hSiTENVbT55XrCf2umqpaUItZIiXCpDUQIXuoIfT6z5g== 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=c37ieVglIdT4V6YJ4aw2TcEHHzWnlb7WyAFjAnFrRig=; b=fwCcvMAQck/RrqtMc9y6/gkQx2LwLl0BwGyxli2OQyEed/LKav8V9NpuU4f/vnPdW29U+OrnGw2cPUGm+xscnzuIi4fSWoC4U0ud3qwP+5peON38cotcxnEFxw0T2VBbmAoXGc5GeLnTxszgg0TukivtXy6xMrM2prbeVOtIbg0= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by BLAPR05MB7474.namprd05.prod.outlook.com (2603:10b6:208:298::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.9; Thu, 7 Oct 2021 17:41:07 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4608.004; Thu, 7 Oct 2021 17:41:07 +0000 From: Ron Bonica To: Ahmed Bashandy , James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQDkW2yAABt8FUAAAtF3gAAywBbg Date: Thu, 7 Oct 2021 17:41:07 +0000 Message-ID: References: <369d2f7c-a242-8759-2ebd-6f2227c45cc6@gmail.com> <8f66b562-2887-6a35-52c5-1d5561ca74f5@gmail.com> In-Reply-To: <8f66b562-2887-6a35-52c5-1d5561ca74f5@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-07T17:41:05Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=593508cc-c2b5-4f3b-9084-08cf3458c72f; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3af5a89a-e9a5-49a4-c86d-08d989b9a4a2 x-ms-traffictypediagnostic: BLAPR05MB7474: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6rBvSOIVaRp1gI3Df4lxqVLZlN5btnFHmgxw8iU2ifsyAtvg2Necxc4P6eRMpkomzymjrzNsvVmZOVB2RMS2NVNdiVnMKZy3PdbsT2V+GQc70y31NQc5DdfCOpA5lsZ92VJFwNzoPvqkQdm4dCqyvfLjSVumYXg2tmhVOWfJDfUrvwLt3NKP7JaAY989M7rHHAL4Gcrz1JDGzZprF9+m5GHcWLilSo2M/BsJj01FwqhWRi02dX4MfwaY58R9MfRAHUO7lEfmzbkOoEWUmJjOaScgEgHCKxoXqrDQI2CCtNM+kUKJ1y0e2yxzbNOFtwvE4YOKoJW9fN/8On6EkBBFZVS83DP9btZVjffw0T2ex+c2EBQS/+r135LeDF8kuTqV0JN8X484wl/SBjtt814uETPH8XOWkaSEjc5EWPCOdgtQ81vGTfk4GQ68BNtUZSPyJUaoMrT7f/eXU3p7CvDs/uIgHa45SXvGlaOHpk3Z1uShHr7opuI3PKLhSrqaUq7m5STK+nmiF4Xbwdr6LVBFcC4BdZgflFexXn8OTszYHDhqio8/GcnAh3e9oLVg+11qzP5pMLjLBuptxmhWGWUF/OhCLFiukwpnClHqtl3u89g+7Hq4MQyg6Y21jQJ6wc8teyycbB5qvFMi35wCWCRv1JuBlvvMRgXuXh8QokMPG7feUQDpdHhq8EaaU+7Ts/w87RWl1CwQquwvOkwSIFNWjK2dzSLq5uQeDUpJ/K99P81EPci0m/HGQtBwUyTLsoEG4u+FQq8OW+Ormb/C7qxCQbjLY+Kc6F+axfNa/ByIjT7beCRXpJTDqjYO261S8wn5 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(4326008)(186003)(71200400001)(508600001)(5660300002)(110136005)(316002)(33656002)(86362001)(38070700005)(166002)(8676002)(76116006)(66946007)(6506007)(53546011)(7696005)(52536014)(9686003)(26005)(122000001)(2906002)(966005)(66476007)(66556008)(64756008)(66446008)(55016002)(38100700002)(8936002)(83380400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?b8B7SYJxFV2NdU9qI+L2H1Ja9MKJcvYlHnTYD3rGoMjjMR6V3lS2lo9oxcWy?= =?us-ascii?Q?cnvVdLEje/vA6oRlM9uK8bTDnncMONeK8lK3gS1PwXMnj1gYzZHOnxOOI5Xj?= =?us-ascii?Q?I360FGukI8wzcSPEoLuaJpbX3HJiypVwCWDHcd5myG/mASqShIY3AFyAjU8T?= =?us-ascii?Q?8Pfjgkm3oG6c52tkr8wUzIYo/m42UxgkyOsiNdsZJquxvmBeRAEJrzXwxeh5?= =?us-ascii?Q?gfhQakmVmt0osJkhua1tG4jDGNRyXcTkQ6GPfyTjmI1+XSkar6G3SrPTMdW7?= =?us-ascii?Q?BXCY87kOo2YWg9aSL4vOfGanPMkH/keGrwjMPMPUsPXlviwB491R5VEtyh4x?= =?us-ascii?Q?K8f5yrcg7e+6DgiKtHxnh+2YZ+4amn1EISBue8wWkMHWwOxg0p68ysr0zPL3?= =?us-ascii?Q?Ffb+jpUE4hz54geXeeFwncbBDW9TPeX6jfeNm+E/H36BQm4QTjNaXVdVcSRV?= =?us-ascii?Q?6/VTMBpJmKqxQFLaUN6YW9XVBfsxhB0bweFqkqXjJH/7Jmm2Dees14QZf9Lr?= =?us-ascii?Q?4juq+DGCglqEA9a9Fx7sw10AusmzWSYO/c5tErk7a/SJA1o5nxvsp+DoTJEi?= =?us-ascii?Q?ItO24FxBRFZs6uoatDvK3MpSxRY7FS5l8MC3XAv7uT37FsANX/v197K0eSDt?= =?us-ascii?Q?I492YrMYxe/XUvLhWicAKl0CYwCGuaWScbgbCWYhWRRODwZf/JTyIYPJcEcz?= =?us-ascii?Q?MkBsSYoF5XaJ0JOAoa5jBYsmIrHQuIL4fUgl09gppMRBqhGnAi9iD5fvH58J?= =?us-ascii?Q?8UbuV24Cu1cHNqkBmpdhZ0AY25IhVZkgqcaGp7XiLNBYt75WE6nbA5ZMDZZr?= =?us-ascii?Q?z622IxBcXTYAjQgKSihWkZrmvBo+FzOT07VIUYF4zQ1jdMjzgDoYJ38y93eU?= =?us-ascii?Q?SssKNl45/28LPvKgGpaI6NXoY6fijQ8hQEp6HCNZAHQs4v1kGG3yL+E1W2PX?= =?us-ascii?Q?st83H98FAU+NHEKviK6RDWRB92FVqGTPI50IoEsCwyCOyMK6SoS2mvf7RL8m?= =?us-ascii?Q?qgCuSuxJvv3VSw3ygaW6aMp8UbeK9yVjx0RkcGdS7pCDOvaoEtMi80hmasLo?= =?us-ascii?Q?2/NDmNLGVmCW7ocP/58zOqNfUtgo7fL3mQfim7dQe1DuQDl0RN+VxFCKndpU?= =?us-ascii?Q?M/yUhQhIcoOGY5HkjgdKGBm48trytS+Wi53+s1RYEpKLfunShCKNZqjBMzhr?= =?us-ascii?Q?+r9hHLbQAa/3KEDEQm2Q6yRrKjcCUx15OQmzTcr/LH9+yN/4/cbJQVOGBftf?= =?us-ascii?Q?+5p8K2coRXAVtsRI+4MgQm2DI/Ddp4fwuu+i9bm3KF3nnvv40UZyOEsjCwP1?= =?us-ascii?Q?he7sQMEwfYRnS9vhch0YxR+D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR05MB53166CC7361A41B5B4A2E41DAEB19BL0PR05MB5316namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3af5a89a-e9a5-49a4-c86d-08d989b9a4a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2021 17:41:07.2543 (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: dWtOU60unPT24eFHkL3Nz2twIjtBPnPJr5dJePLf54v7xZC7ixWwN+Tt+qxt9K59uHXv3ZfC1F226qKsZlKUxw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR05MB7474 X-Proofpoint-ORIG-GUID: SMLLariGiEx4mTvQd81nSeJlIk2mbXMe X-Proofpoint-GUID: SMLLariGiEx4mTvQd81nSeJlIk2mbXMe X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-07_03,2021-10-07_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 lowpriorityscore=0 phishscore=0 adultscore=0 bulkscore=0 spamscore=0 priorityscore=1501 clxscore=1015 malwarescore=0 impostorscore=0 suspectscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110070114 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 07 Oct 2021 17:41:21 -0000 --_000_BL0PR05MB53166CC7361A41B5B4A2E41DAEB19BL0PR05MB5316namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ahmed, That is a far cry from recommending anything. * If you take a look at the first page of that slide deck, the DT was t= asked with enumeration and analysis of requirements. The word "recommend" d= oes not appear on that page. * If you look at the third page of that slide deck, you will see that o= ne very important requirement (PS/BCP Compliance) was left for the relevant= WGs to determine. * If you look under the chart, you will see a note that says "All requi= rements are not equally important. The working group must decide which are = more significant." The WG needs to determine whether the requirements that = register a difference are significant. Ron Juniper Business Use Only From: Ahmed Bashandy Sent: Wednesday, October 6, 2021 1:21 PM To: Ron Bonica ; James Guichard ; SPRING WG Cc: spring-chairs@ietf.org Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ [External Email. Be cautious of content] If we take a look at the summary table in slide 17 in the DT presentation = at last IETF https://datatracker.ietf.org/meeting/111/materials/slides-111-spring-srcomp= -design-team-update-00 we can see that CSID is the only column with *all blocks dark green*. Thanks Ahmed On 10/6/21 9:06 AM, Ron Bonica wrote: Ahmed, I don't recall the DT recommending the CSID. In fact, the word "recommend" = does not appear anywhere in the analysis document. As a member of the DT, I don't recommend CSID. = Ron Juniper Business Use Only From: spring On B= ehalf Of Ahmed Bashandy Sent: Tuesday, October 5, 2021 10:53 PM To: James Guichard ; SPRING WG Cc: spring-chairs@ietf.org Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ [External Email. Be cautious of content] I support the adoption of this document. 1. The network programming model (RFC8986) defines multiple behaviors, C= SID is just adding the next and replace flavors 2. The draft proposes a single SRv6 based data plane that defines next a= nd replace behaviors. IMO that is consistent with RFC8986 1. CSID has been recommended by the design team for SRv6 based compressi= on 2. Interop was done. That is more evidence that CSID is a single data pl= ane solution 3. IMO CSID is ready to become the basis for the SRv6 compression soluti= on 4. Being an SRv6 data plane-based solution, CSID is coherent with the on= e data plane solution objective 5. CSID meets SRv6 compression requirements as single solution Thanks Ahmed On 10/1/21 7:04 AM, James Guichard wrote: Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardizat= ion work. That is part of what this email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as follows. By expressing support for a= doption of this document you are fully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_BL0PR05MB53166CC7361A41B5B4A2E41DAEB19BL0PR05MB5316namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ahmed,

 

That is a far cry f= rom recommending anything.

 

  • If you take a look at the first page= of that slide deck, the DT was tasked with enumeration and analysis of req= uirements. The word “recommend” does not appear on that page.
  • If you look at the third page of that slide deck, you will see that= one very important requirement (PS/BCP Compliance) was left for the releva= nt WGs to determine.
  • If you look under the chart, you will see a note that says “All re= quirements are not equally important. The working group must decide which a= re more significant.” The WG needs to determine whether the requirements tha= t register a difference are significant.

 

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     Ron

 

 

 

Juniper Business Use Only

From: Ahmed Bashandy <abashandy.ietf@gmail= .com>
Sent: Wednesday, October 6, 2021 1:21 PM
To: Ron Bonica <rbonica@juniper.net>; James Guichard <james= .n.guichard@futurewei.com>; SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.= org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

 

<= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

 

If we take a look at the summary table in slide 17 in = the DT presentation at last IETF

https://datatracker.ietf.org/meeting/= 111/materials/slides-111-spring-srcomp-design-team-update-00

we can see that CSID is the only column with= *all blocks dark green*.

 

Thanks

Ahmed

 

 

 

On 10/6/21 9:06 AM, Ron Bonica wrote:

Ahmed,<= /o:p>

 <= /o:p>

I don’t recal= l the DT recommending the CSID. In fact, the word “recommend” d= oes not appear anywhere in the analysis document.

 <= /o:p>

As a member of the = DT, I don’t recommend CSID.

 <= /o:p>

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;            &nb= sp;        Ron

 <= /o:p>

 

Juniper Business Use Only

From: spring <spring-bounces@ietf.org> On Behalf Of Ahmed Bashandy
Sent: Tuesday, October 5, 2021 10:53 PM
To: James Guichard <james.n.guichard@futurewei.com>; SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org=
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/

 

<= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

 

I support the adoption of this document.

  1. The network programming model (RFC8986) defines multiple behaviors, CSID is= just adding the next and replace flavors
  2. The draft proposes a single SRv6 based data plane that defines next and rep= lace behaviors. IMO that is consistent with RFC8986
  1. CSID has been recommended by the design team for SRv6 based compression
  2. Interop was done. That is more evidence that CSID is a single data plane so= lution
  3. IMO CSID is ready to become the basis for the S= Rv6 compression solution
  4. Being an SRv6 data plane-based solution, CSID is coherent with the one data plane solution objective
  5. CSID meets SRv6 compression requirements as single solution
    6. =

 

Thanks

 

Ahmed

 

On 10/1/21 7:04 AM, James Guichard wrote:=

Dear WG:

 

The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

 

The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors.
  2. The document is a “living” document; it m= ay change as it goes through review and analysis by the SPRING working grou= p.
  3. All open discussion points raised on our mailing list= MUST be addressed BEFORE said document is allowed to progress from the wor= king group to publication. A list of these discussion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
  4. If this document is adopted by the working group, the= chairs specify as part of the adoption call that the following text descri= bing an open issue be added to the document in the above-described open issues section:
    1. "Given th= at the working group has said that it wants to standardize one data plane s= olution, and given that the document contains multiple SRv6 EndPoint behavi= ors that some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

 

Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

 

_______________________________________________
spring mailing list
spring@ietf.org

https://www.ietf.org/mailman/listinfo/spring<=
/o:p>
--_000_BL0PR05MB53166CC7361A41B5B4A2E41DAEB19BL0PR05MB5316namp_-- From nobody Thu Oct 7 11:15:46 2021 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 071A43A0D4F; Thu, 7 Oct 2021 11:15:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBS2Tgv3GhzQ; Thu, 7 Oct 2021 11:15:33 -0700 (PDT) Received: from mail-ed1-x52b.google.com (mail-ed1-x52b.google.com [IPv6:2a00:1450:4864:20::52b]) (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 026123A0872; Thu, 7 Oct 2021 11:15:32 -0700 (PDT) Received: by mail-ed1-x52b.google.com with SMTP id d9so2531208edh.5; Thu, 07 Oct 2021 11:15: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 :cc; bh=JEixrYCqTKWeiR9DvYvqZ2G7yePKat3e0hhOv2wc34w=; b=FeL3dePPEY/nKbV8hOr5RwjyFqOC39Xql7K7v3lt1klN78UZgP1NSnJIaMm+VdyeD+ ubf34zoWNb5PtD8/JnoGNk3dQcUhF6YoUg9obP6y32BShnW5CPobQOfSCFoBAZV0g93Y 8Ir2yoMkFaXBvVUOoitT0uWftzDJO9l/kJnS3rD1fvQ6Gip0o4tYKoW976c41pOe21PE 88/t8xFrFWAt1qgGFMIPdcZMJrueMi2FUsMgoMtN6fiaYZEPvw/LonscNvtb99kUr8GR ahQ90ZsDcEFNNvl+9aFinwYXptSZ/XBtFH4zmz+s3qzn48BIRv75WJsce1Rvk32QXmLY 7JRQ== 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=JEixrYCqTKWeiR9DvYvqZ2G7yePKat3e0hhOv2wc34w=; b=gH9ppWVJYDUoqBUcwcpydvmMJ5GxLqOh+6g8hwobVVO7fM9u6tSxhINMgpynNY14Zq Uce7TuJAita3E4IHptOGLPt7mjpgZURtTDfNoDr7G2auOGAHHvgwQ52qdIkgWkAq4G50 rYJwjHRp3/WiyWA3f1QAPI514+vPQPo7TGw/VvlDNKVah3DF7QQzLZt8rZZSTl2quMFV DgRK+qp/CYmlV4zVCkmgjQk1kQ3mQ3ACLvPKI8tVNv265Pp+zZTLjk93LE9ClHAggm+t /FXxp/sqQZjbYPiNXdViu0JggzV7DtIjN97wtTlLXWLZXW4kK3hvdXuCoDVQiPhQhlwH 6rhQ== X-Gm-Message-State: AOAM530oJXPbic3sK93MlhBu5RLHuQIxTmk9Lp3ffqjaNnuPoIASVjBY TJWgw/qJBSRsYe1W8RAPE3OrNv7Rc4l4q62+Wry1vQFWOM8= X-Google-Smtp-Source: ABdhPJzWifEfzsEmoRsKP/KruIpXxyXpHkT8FRu+I2dgOx1hVgbdYxluOxtC73AxMoN8OsyjQjqm1pxVRV6AJRwqzJ4= X-Received: by 2002:a17:906:c302:: with SMTP id s2mr3479615ejz.499.1633630531172; Thu, 07 Oct 2021 11:15:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Thu, 7 Oct 2021 11:15:19 -0700 Message-ID: To: "Francois Clad (fclad)" Cc: Robert Raszuk , Ron Bonica , James Guichard , SPRING WG , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000813e5605cdc73fac" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 07 Oct 2021 18:15:42 -0000 --000000000000813e5605cdc73fac Content-Type: text/plain; charset="UTF-8" Hi Francois, thank you for your detailed response and confirming that C-SIDs of different flavors/behavior may be present in the same SRH and even the same CSID container. I've noticed Ron's proposal as I was trying to formulate my question. His proposal highlighted what I am trying to understand - the relationship between NEXT-C-SID and REPLACE-C-SID. I concur with Ron. The WG has adopted the compression analysis draft , and the updates and an additional analysis Ron proposed will keep the discussion and decision-making process on the firm technical foundation. Regards, Greg On Thu, Oct 7, 2021 at 9:17 AM Francois Clad (fclad) wrote: > Hi Greg, > > > > It is the role of the SR Source Node [Section 3.1 of RFC 8754] to form the > segment list in the SRH. It learns about the available SIDs in the network > with their associated behavior and flavors via control plane and/or > management plane protocols, as described in Section 8 of RFC 8986, and > selects the SIDs that are the most appropriate for the segment list. > > > > Each SR Segment Endpoint Node [Section 3.3 of RFC 8754] simply executes > the pseudocode of a locally instantiated SID when it receives a packet > matching that SID. The SR Segment Endpoint Node does not need to bother > about the behavior/flavor of the subsequent SRv6 SIDs. > > > > This SRv6 logic applies to the C-SID flavors as well. The choice of > flavors for the SIDs in the SID List is up to the SR Source Node. > > > > It is indeed possible to mix SIDs of different C-SID flavors in the same > SRH, and even in a single C-SID container. > > > > Thanks, > > Francois > > > > > > *From: *Greg Mirsky > *Date: *Wednesday, 6 October 2021 at 19:19 > *To: *Francois Clad (fclad) > *Cc: *Robert Raszuk , Ron Bonica 40juniper.net@dmarc.ietf.org>, James Guichard < > james.n.guichard@futurewei.com>, SPRING WG , > spring-chairs@ietf.org > *Subject: *Re: [spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > Hi Francois, > > thank you for the clarification. It is still not clear how a node selects > which flavor of CSID to use on the next compressed CSID that may happen > also be in the next CSID container. As I understand it, a CSID container > must use the same flavor of compression but CSID containers with different > compression flavors in the same SRH are allowed. Is that correct > understanding? > > > > Regards, > > Greg > > > > On Wed, Oct 6, 2021 at 7:05 AM Francois Clad (fclad) > wrote: > > Hi Greg, > > > > A node that supports this draft in its entirety can instantiate SRv6 SIDs > (e.g., End and End.X SIDs) with any of the three C-SID flavors. > > > > In particular, a node can instantiate multiple SRv6 SIDs bound to > different C-SID flavors, possibly with different C-SID lengths. It can also > instantiate SRv6 SIDs with behaviors and flavors defined in RFC 8986. > > > > As defined in Section 4.3 of RFC 8754 and again in Section 3 of RFC 8986, > upon receiving an IPv6 packet with a destination address matching a FIB > entry that represents one of these locally instantiated SIDs, the node > processes the packet according to the behavior (and flavor(s)) (i.e. > pseudocode) of that SID. > > > > RFC 8754 and 8986 have already standardized these mechanisms and the C-SID > draft only leverages the same SRv6 dataplane to introduce new endpoint > flavors for compression. > > > > > > Francois > > > > *From: *spring on behalf of Greg Mirsky < > gregimirsky@gmail.com> > *Date: *Tuesday, 5 October 2021 at 23:37 > *To: *Robert Raszuk > *Cc: *Ron Bonica , James Guichard < > james.n.guichard@futurewei.com>, SPRING WG , > spring-chairs@ietf.org > *Subject: *Re: [spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > Hi Robert, > > as I understand it, you believe everything that is written in the draft. I > hope you can help me find an answer to one simple question: > > Can a node that supports this draft in its entirety, i.e., supports all > "flavors" defined in the document, process received SRv6 packet with the > SRH encoded according to the specification? > > So far, the proponents of the draft referred to "planning" how flavors of > SRv6 SID compressed. To the best of my understanding, that is is a clear > demonstration of the incompatibility between flavors defined in the CSID > draft. Regardless of what is written in it. > > > > Regards, > > Greg > > > > On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk wrote: > > Ron & SPRING WG chairs, > > > > Through this discussion we first have seen a debate if we need one or more > data planes to compress SIDs in SRv6. WG clearly stated we need one. > > > > Following that we have observed a first terminology shift to see if asking > how many solutions should be supported will work any better. To that many > WG members clearly stated that they support one solution. > > > > Well please notice that the draft in question in its introduction states: > > > > Abstract > > This document defines a compressed SRv6 Segment List Encoding in the > Segment Routing Header (SRH). *This solution* does not require any SRH > data plane change nor any SRv6 control plane change. *This solution* > leverages the SRv6 Network Programming model. > > > > So based on my understanding of English the entire draft talks about a > single solution. > > > > Then suddenly a new question popped up: how many behaviours are > acceptable. > > > > I bet number of folks including myself said "one" keeping in mind previous > discussions and the definition of "one" meaning based on the SRv6 data > plane in compliance to [RFC8402], [RFC8754] and [RFC8986]. > > > > Interestingly enough the draft in question defines not behaviours but > flavors as new variants of the already defined behaviors in Standards Track > RFCs. Namely it defines: > > > > 4.1. NEXT-C-SID Flavor > > 4.2. REPLACE-C-SID Flavor > > > > The newly defined behaviour End.XPS is optional. > > So if there is anything to ask here is to check if WG is ok with two > flavors or not. I do not recall that question has ever been asked formally > during the WG adoption call. > > > > With that let's note that optimal compressed SID size may be different > network to network. One size does not fit all. Draft says: > > 6.1. C-SID Length > > The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A > * C-SID length of 16-bit is recommended.* > > The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths. > * A C-SID length of 32-bit is recommended.* > > > > While I personally think 8-bit should be an option, if we choose a single > flavor we will introduce suboptimality for no good reason. Hardware > capable of supporting any flavor clearly can do LPM on locator. Also > hardware capable of supporting one flavor can support few other flavors as > this is pretty much just an offset game. > > > > Kind regards, > > Robert > > > > > > > > On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica 40juniper.net@dmarc.ietf.org> wrote: > > Pablo, > > > > Ae you sure? Please look at the question as Joel asked it ( > https://mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ > ). > > > > > Ron > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > --000000000000813e5605cdc73fac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Francois,
thank you for your detai= led response and confirming that C-SIDs of different flavors/behavior=C2=A0= may be present in the same SRH and even the same CSID container. I've n= oticed Ron's proposal as I was trying to formulate my question. His pro= posal highlighted what I am trying to understand - the relationship=C2=A0be= tween NEXT-C-SID and REPLACE-C-SID. I concur with Ron. The WG has adopted t= he compression analysis draft, and the=C2=A0updates and an ad= ditional analysis Ron proposed will keep the discussion and decision-making= process on the firm technical foundation.

Regards= ,
Greg

On Thu, Oct 7, 2021 at 9:17 AM Francois Clad = (fclad) <fclad@cisco.com> wrot= e:

Hi Greg,

=C2=A0

It is the role of the SR Source Node [Section = 3.1 of RFC 8754] to form the segment list in the SRH. It learns about the a= vailable SIDs in the network with their associated behavior and flavors via control plane and/or management plane protocols, as described in Section 8= of RFC 8986, and selects the SIDs that are the most appropriate for the se= gment list.

=C2=A0

Each SR Segment Endpoint Node [Section 3.3 of = RFC 8754] simply executes the pseudocode of a locally instantiated SID when= it receives a packet matching that SID. The SR Segment Endpoint Node does not need to bother about the behavior/flavor of the subsequent SRv6 SIDs.<= u>

=C2=A0

This SRv6 logic applies to the C-SID flavors a= s well. The choice of flavors for the SIDs in the SID List is up to the SR = Source Node.

=C2=A0

It is indeed possible to mix SIDs of different= C-SID flavors in the same SRH, and even in a single C-SID container.

=C2=A0

Thanks,

Francois

=C2=A0

=C2=A0

From: Greg Mirsky <gregimirsky@gmail.com= >
Date: Wednesday, 6 October 2021 at 19:19
To: Francois Clad (fclad) <fclad@cisco.com>
Cc: Robert Raszuk <robert@raszuk.net>, Ron Bonica <rbonica=3D40juniper.net@dmarc.iet= f.org>, James Guichard <james.n.guichard@futurewei.com>, SPRING W= G <spring@ietf.org<= /a>>, spring= -chairs@ietf.org <spring-chairs@ietf.org>
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/

Hi Francois,

thank you for the clarification. It is still not cle= ar how a node selects which flavor of CSID to use on the next compressed CS= ID that may happen also be in the next CSID container. As I understand it, = a CSID container must use the same flavor of compression but CSID containers with different compression flavo= rs in the same SRH are allowed. Is that correct understanding?

=C2=A0

Regards,

Greg

=C2=A0

On Wed, Oct 6, 2021 at 7:05 AM Francois Clad (fclad)= <fclad@cisco.com> wrote:

Hi Greg,

=C2=A0

A node that supports this draft in its entirety can = instantiate SRv6 SIDs (e.g., End and End.X SIDs) with any of the three C-SID flavors. <= /u>

=C2=A0

In particular, a node can instantiate multiple SRv6 = SIDs bound to different C-SID flavors, possibly with different C-SID length= s. It can also instantiate SRv6 SIDs with behaviors and flavors defined in RFC 8986.

=C2=A0

As defined in Section 4.3 of RFC 8754 and again in S= ection 3 of RFC 8986, upon receiving an IPv6 packet with a destination addr= ess matching a FIB entry that represents one of these locally instantiated SIDs, the node processes the packet according to the = behavior (and flavor(s)) (i.e. pseudocode) of that SID.

=C2=A0

RFC 8754 and 8986 have already standardized these me= chanisms and the C-SID draft only leverages the same SRv6 dataplane to intr= oduce new endpoint flavors for compression.

=C2=A0

=C2=A0

Francois

=C2=A0

Hi Robert,

as I understand it, you believe everything that is w= ritten in the draft. I hope you can help me find an answer to one simple qu= estion:

Can a node that supports this draft in its entirety,= i.e., supports all "flavors" defined in the document, process re= ceived SRv6 packet with the SRH encoded according to the specification?<= /u>

So far, the proponents of the draft referred to &quo= t;planning" how flavors of SRv6 SID compressed. To the best of my unde= rstanding, that is is a clear demonstration of the incompatibility between flavors defined in the CSID draft. Regardless of=C2=A0what is writ= ten in it.

=C2=A0

Regards,

Greg

=C2=A0

On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk <robert@raszuk.net&g= t; wrote:

Ron & SPRING WG chairs,

=C2=A0

Through this discussion we first have seen a debate = if we need one or more data planes=C2=A0to compress SIDs in SRv6. WG clearl= y=C2=A0stated we need one.=C2=A0

=C2=A0

Following that we have observed a first terminology = shift to see if asking how many solutions should be supported will work any= better. To that many WG members clearly stated that they support one solution.=C2=A0

=C2=A0

Well please notice that the draft in question in its= introduction states:=C2=A0

=C2=A0

Abstract

=C2=A0 =C2=A0This document defines a compressed SRv6 Segment List Encoding = in the
=C2=A0 =C2=A0Segment Routing Header (SRH). =C2=A0This solution does = not require any SRH
=C2=A0 =C2=A0data plane change nor any SRv6 control plane change. =C2=A0= This solution
=C2=A0 =C2=A0leverages the SRv6 Network Programming model.

=C2=A0

So based on my understanding of English the entire d= raft talks about a single solution.=C2=A0

=C2=A0

Then suddenly a new question popped=C2=A0up: how man= y behaviours are acceptable.=C2=A0

=C2=A0

I bet number of folks including myself said "on= e" keeping in mind previous discussions and the definition of "on= e" meaning based on the SRv6 data plane in compliance to [RFC8402], [RFC8754] and [RFC8986].

=C2=A0

Interestingly enough the draft in question defines n= ot behaviours but flavors as new variants of the already defined behaviors = in Standards Track RFCs. Namely it defines:=C2=A0

=C2=A0

4.1.=C2=A0 NEXT-C-SID Flavor

4.2.=C2=A0 REPLACE-C-SID Flavor

=C2=A0

The newly defined behaviour End.XPS is optional.=C2= =A0

So if there is anything to ask here is to check if WG is ok with two flavor= s or not. I do not recall that question has=C2=A0ever been asked formally d= uring the WG adoption call.=C2=A0

=C2=A0

With that let's note that optimal compressed SID= size may be different network to network. One size does not fit all. Draft= says:=C2=A0

6.1.=C2=A0 C-SID Length

=C2=A0 =C2=A0The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengt= hs. =C2=A0A
=C2=A0 =C2=A0C-SID length of 16-bit is recommended.

=C2=A0 =C2=A0The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID le= ngths.
=C2=A0 =C2=A0A C-SID length of 32-bit is recommended.<= /p>

=C2=A0

While I personally think 8-bit should be an option, = if we choose a single flavor we will introduce suboptimality for no good re= ason. Hardware capable=C2=A0of supporting any flavor clearly can do LPM on locator. Also hardware capable of supporting one flavor can = support few other flavors as this is pretty much just an offset game.=C2=A0=

=C2=A0

Kind regards,

Robert

=C2=A0

=C2=A0

=C2=A0

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

--000000000000813e5605cdc73fac-- From nobody Thu Oct 7 11:23:07 2021 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 5812D3A0D60; Thu, 7 Oct 2021 11:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bell.ca 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 aHTkGNgWoj4x; Thu, 7 Oct 2021 11:22:57 -0700 (PDT) Received: from ESA1-Dor.bell.ca (esa1-dor.bell.ca [204.101.223.58]) (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 CE70F3A0D58; Thu, 7 Oct 2021 11:22:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bell.ca; i=@bell.ca; q=dns/txt; s=ESAcorp; t=1633630977; x=1665166977; h=from:to:cc:date:message-id:mime-version:subject; bh=iFCTHLXrY5WI95OBHuObpeXSBwbj3d0jqE6F6Lz3t0Q=; b=XlDRLxbCJbi7cYZnYKO9Qnl2C/izl8uGgpBTu13bttWH3CrK5kfxxs+1 iSgv1JXvQaTApTDUeI6PVTNn0sysl4hjQuQFLyz9J0iAR5hM5ers1DoDQ /+iQ2/Ga82SdYnxDP+UKzScQmRGWxMt4ZlNpV6yc5GcaMv9zVIeMhb6kh VAg8U1+zDO66Nhk+mMQMBePIb3Qhbdn0VPbKngBrde3Pbo0qhN5PM08BB TzwZ3SQRNlhWktMboc7DIEICoCD4mXFjPSat5xM5RNDb+9RyHQhU8tDVd GNuG8D3mwaRKOrXyC8TU76aoHvDmCsJYOiNN7dXRGSjBoZk061Oqpi+i4 w==; IronPort-SDR: gWcruD1xF6bK78owMz0AYrahgxNSqaoCEAUBffx5hKexbc0iBW/y9GhKHJPbjYPy23+KHNakJL sZvzkK8LofOw== Received: from dc5cmy-d00.bellca.int.bell.ca (HELO DG1MBX01-WYN.bell.corp.bce.ca) ([198.235.121.229]) by esa01corp-dor.bell.corp.bce.ca with ESMTP; 07 Oct 2021 14:22:54 -0400 Received: from DG1MBX04-WYN.bell.corp.bce.ca (2002:8eb6:120e::8eb6:120e) by DG1MBX01-WYN.bell.corp.bce.ca (2002:8eb6:120b::8eb6:120b) with Microsoft SMTP Server (TLS) id 15.0.1497.18; Thu, 7 Oct 2021 14:22:54 -0400 Received: from DG1MBX04-WYN.bell.corp.bce.ca ([fe80::d46c:dfac:2628:1852]) by DG1MBX04-WYN.bell.corp.bce.ca ([fe80::d46c:dfac:2628:1852%22]) with mapi id 15.00.1497.018; Thu, 7 Oct 2021 14:22:54 -0400 From: "Bernier, Daniel" To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: [EXT][spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: AQHXu6hYQi0Oc8rTd0KuAEMynwTBXQ== Date: Thu, 7 Oct 2021 18:22:54 +0000 Message-ID: <5F2843E0-2F4A-4AB9-AAF6-5E9AC089D42C@bell.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.53.21091200 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.28.239.79] Content-Type: multipart/alternative; boundary="_000_5F2843E02F4A4AB9AAF65E9AC089D42Cbellca_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 07 Oct 2021 18:23:03 -0000 --_000_5F2843E02F4A4AB9AAF65E9AC089D42Cbellca_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkFmdGVyIHJlLXJlYWRpbmcgdGhlIGRyYWZ0IEkgc3Ryb25nbHkgc3VwcG9ydCBpdHMg YWRvcHRpb24uDQoNCg0KICAxLiAgRm9sbG93aW5nIHRoZSBEZXNpZ24gVGVhbSB3b3JrIHN0cmVh bSwgQ1NJRCBwcm92ZXMgY29uZm9ybWFudCBhbmQgb3B0aW1hbC4NCiAgMi4gIEl0IGFsbG93cyBm b3IgdGhlIGZsZXhpYmlsaXR5IG9mIHNlbGVjdGluZyB0aGUgU1J2NiBkYXRhIHBsYW5lIGZsYXZv ciAoY29tcHJlc3NlZCBvciBub3QpIHdpdGhvdXQgY2hhbmdlcyB0byB0aGUgYXJjaGl0ZWN0dXJl Lg0KICAzLiAgSGFzIHByb3ZlbiBxdWl0ZSBlYXN5IHRvIGltcGxlbWVudCB3aXRoIG91ciBleGlz dGluZyBIVyBwbGF0Zm9ybXMgKGluIGEgbWF0dGVyIG9mIGhvdXJzIGZvciBzb21lIEFTSUNzKQ0K ICA0LiAgQXMgbXkgY29sbGVhZ3VlIERhbiBWb3llciBwb2ludGVkIG91dCwgd2Ugc3VjY2Vzc2Z1 bGx5IGRlcGxveWVkIGluIHByb2R1Y3Rpb24gd2l0aCBsaXZlIHRyYWZmaWMuICBBbmQgaW4gYSBt dWx0aS12ZW5kb3IgZW52aXJvbm1lbnQuDQoNClRoYW5rcywNCg0KRGFuIEINCg0KRnJvbTogc3By aW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEphbWVzIEd1aWNoYXJk IDxqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20+DQpEYXRlOiBGcmlkYXksIE9jdG9iZXIg MSwgMjAyMSBhdCAxMDowNSBBTQ0KVG86IFNQUklORyBXRyA8c3ByaW5nQGlldGYub3JnPg0KQ2M6 ICJzcHJpbmctY2hhaXJzQGlldGYub3JnIiA8c3ByaW5nLWNoYWlyc0BpZXRmLm9yZz4NClN1Ympl Y3Q6IFtFWFRdW3NwcmluZ10gV0cgQWRvcHRpb24gY2FsbCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJl c3Npb24vDQoNCkRlYXIgV0c6DQoNClRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBleHByZXNzIHRo ZWlyIGFwcHJlY2lhdGlvbiBmb3IgYWxsIHRoZSByZXNwb25zZXMgcmVjZWl2ZWQgdG8gb3VyIGVt YWlscyB3aXRoIHJlZmVyZW5jZSB0byBob3cgdGhlIHdvcmtpbmcgZ3JvdXAgd2lzaGVzIHRvIG1v dmUgZm9yd2FyZCB3aXRoIHJlc3BlY3QgdG8gYSBzb2x1dGlvbiBmb3IgU1J2NiBjb21wcmVzc2lv bi4NCg0KVGhlIGFwcGFyZW50IGluY2xpbmF0aW9uIG9mIHRoZSB3b3JraW5nIGdyb3VwIGlzIHRv IHVzZSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5n LXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8gYXMgdGhlIGJhc2lzIGZvciBpdHMgY29tcHJl c3Npb24gc3RhbmRhcmRpemF0aW9uIHdvcmsuIFRoYXQgaXMgcGFydCBvZiB3aGF0IHRoaXMgZW1h aWwgYXR0ZW1wdHMgdG8gY29uZmlybS4NCg0KQmVjYXVzZSBvZiB0aGUgYWJvdmUgdGhlIGNoYWly cyB3b3VsZCBsaWtlIHRvIGlzc3VlIGEgMi13ZWVrIFdHIGNhbGwgZm9yIGFkb3B0aW9uIGVuZGlu ZyBPY3RvYmVyIDE1dGggZm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyBidXQgd2l0aCBzb21l IGNsZWFyIGd1aWRlbGluZXMgYXMgZm9sbG93cy4gQnkgZXhwcmVzc2luZyBzdXBwb3J0IGZvciBh ZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IHlvdSBhcmUgZnVsbHkgYXdhcmUgb2YgYW5kIGFyZSBh Y2tub3dsZWRnaW5nIHRoYXQ6DQoNCg0KMS4gICAgICAgVGhlIFNQUklORyB3b3JraW5nIGdyb3Vw IGlzIGFkb3B0aW5nIGEgZG9jdW1lbnQgdGhhdCBoYXMgbXVsdGlwbGUgU1J2NiBFbmRwb2ludCBi ZWhhdmlvcnMuDQoNCjIuICAgICAgIFRoZSBkb2N1bWVudCBpcyBhIOKAnGxpdmluZ+KAnSBkb2N1 bWVudDsgaXQgbWF5IGNoYW5nZSBhcyBpdCBnb2VzIHRocm91Z2ggcmV2aWV3IGFuZCBhbmFseXNp cyBieSB0aGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAuDQoNCjMuICAgICAgIEFsbCBvcGVuIGRpc2N1 c3Npb24gcG9pbnRzIHJhaXNlZCBvbiBvdXIgbWFpbGluZyBsaXN0IE1VU1QgYmUgYWRkcmVzc2Vk IEJFRk9SRSBzYWlkIGRvY3VtZW50IGlzIGFsbG93ZWQgdG8gcHJvZ3Jlc3MgZnJvbSB0aGUgd29y a2luZyBncm91cCB0byBwdWJsaWNhdGlvbi4gQSBsaXN0IG9mIHRoZXNlIGRpc2N1c3Npb24gcG9p bnRzIHdpbGwgYmUgZG9jdW1lbnRlZCBpbiB0aGUgV0cgZG9jdW1lbnQgYW5kIG1haW50YWluZWQg YnkgdGhlIGRvY3VtZW50IGVkaXRvciBpbiBjb25qdW5jdGlvbiB3aXRoIHRoZSBjaGFpcnMuDQoN CjQuICAgICAgIElmIHRoaXMgZG9jdW1lbnQgaXMgYWRvcHRlZCBieSB0aGUgd29ya2luZyBncm91 cCwgdGhlIGNoYWlycyBzcGVjaWZ5IGFzIHBhcnQgb2YgdGhlIGFkb3B0aW9uIGNhbGwgdGhhdCB0 aGUgZm9sbG93aW5nIHRleHQgZGVzY3JpYmluZyBhbiBvcGVuIGlzc3VlIGJlIGFkZGVkIHRvIHRo ZSBkb2N1bWVudCBpbiB0aGUgYWJvdmUtZGVzY3JpYmVkIG9wZW4gaXNzdWVzIHNlY3Rpb246DQoN CsK3ICAgICAgICAgIkdpdmVuIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHNhaWQgdGhhdCBp dCB3YW50cyB0byBzdGFuZGFyZGl6ZSBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiwgYW5kIGdpdmVu IHRoYXQgdGhlIGRvY3VtZW50IGNvbnRhaW5zIG11bHRpcGxlIFNSdjYgRW5kUG9pbnQgYmVoYXZp b3JzIHRoYXQgc29tZSBXRyBtZW1iZXJzIGhhdmUgc3RhdGVkIGFyZSBtdWx0aXBsZSBkYXRhIHBs YW5lIHNvbHV0aW9ucywgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhZGRyZXNzIHdoZXRoZXIgdGhp cyBpcyB2YWxpZCBhbmQgY29oZXJlbnQgd2l0aCBpdHMgb25lIGRhdGEgcGxhbmUgc29sdXRpb24g b2JqZWN0aXZlLiIuDQoNClBsZWFzZSBjb25zaWRlciB0aGUgYWJvdmUgZ3VpZGVsaW5lcyBhcyB5 b3UgZGVjaWRlIG9uIHdoZXRoZXIgdG8gc3VwcG9ydCBvciBub3QgdGhpcyBXRyBhZG9wdGlvbi4g UGxlYXNlIGV4cHJlc3MgY2xlYXJseSB5b3VyIHJlYXNvbmluZyBmb3Igc3VwcG9ydC9ub24tc3Vw cG9ydCBhcyB3ZWxsIGFzIGFueSBvcGVuIGRpc2N1c3Npb24gcG9pbnRzIHlvdSB3b3VsZCBsaWtl IGFkZHJlc3NlZCBzaG91bGQgdGhlIGRvY3VtZW50IGJlIGFkb3B0ZWQgaW50byB0aGUgd29ya2lu ZyBncm91cC4NCg0KVGhhbmtzIQ0KDQpKaW0sIEJydW5vICYgSm9lbA0KDQoNCg== --_000_5F2843E02F4A4AB9AAF65E9AC089D42Cbellca_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNv UGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxh aW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9t OjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0 O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBs MA0KCXttc28tbGlzdC1pZDo3NDc1MDU1OTI7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMDk4 Mzc5NzMwO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjc1MTY5OTM5MzsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTcyMTY1NDc3NiA2NzY5ODcwMyA2 NzY5ODY4OSA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5 ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZl bDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwx OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoxMDg3MzEzNTI1Ow0K CW1zby1saXN0LXRlbXBsYXRlLWlkczoxNDQ1OTAzNDM0O30NCkBsaXN0IGwyOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDMNCgl7bXNvLWxpc3QtaWQ6MTU3MzE1MTM2NTsN Cgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTY1NTg4MTc3 MiA2NzY5ODcxMSA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2 NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlz dCBsMzpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsN Cgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVu dDotOS4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30N CkBsaXN0IGwzOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0K QGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6MTg2ODgzMTU1NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6LTIwMDYxMzgwNjt9DQpAbGlzdCBsNDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MzYu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30N CkBsaXN0IGw0OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDQ6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7 bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tQ0EiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHls ZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhpLCA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWZ0ZXIgcmUt cmVhZGluZyB0aGUgZHJhZnQgSSBzdHJvbmdseSBzdXBwb3J0IGl0cyBhZG9wdGlvbi48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPG9s IHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgc3RhcnQ9IjEiIHR5cGU9ImEiPg0KPGxpIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwzIGxldmVs MSBsZm82Ij5Gb2xsb3dpbmcgdGhlIERlc2lnbiBUZWFtIHdvcmsgc3RyZWFtLCBDU0lEIHByb3Zl cyBjb25mb3JtYW50IGFuZCBvcHRpbWFsLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDMgbGV2ZWwxIGxm bzYiPkl0IGFsbG93cyBmb3IgdGhlIGZsZXhpYmlsaXR5IG9mIHNlbGVjdGluZyB0aGUgU1J2NiBk YXRhIHBsYW5lIGZsYXZvciAoY29tcHJlc3NlZCBvciBub3QpIHdpdGhvdXQgY2hhbmdlcyB0byB0 aGUgYXJjaGl0ZWN0dXJlLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzYiPkhhcyBw cm92ZW4gcXVpdGUgZWFzeSB0byBpbXBsZW1lbnQgd2l0aCBvdXIgZXhpc3RpbmcgSFcgcGxhdGZv cm1zIChpbiBhIG1hdHRlciBvZiBob3VycyBmb3Igc29tZSBBU0lDcyk8bzpwPjwvbzpwPjwvbGk+ PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1s aXN0OmwzIGxldmVsMSBsZm82Ij5BcyBteSBjb2xsZWFndWUgRGFuIFZveWVyIHBvaW50ZWQgb3V0 LCB3ZSBzdWNjZXNzZnVsbHkgZGVwbG95ZWQgaW4gcHJvZHVjdGlvbiB3aXRoIGxpdmUgdHJhZmZp Yy4mbmJzcDsgQW5kIGluIGEgbXVsdGktdmVuZG9yIGVudmlyb25tZW50Lg0KPG86cD48L286cD48 L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcywgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRhbiBC PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5zcHJpbmcgJmx0O3Nwcmlu Zy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgSmFtZXMgR3VpY2hhcmQgJmx0O2ph bWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+RnJpZGF5 LCBPY3RvYmVyIDEsIDIwMjEgYXQgMTA6MDUgQU08YnI+DQo8Yj5UbzogPC9iPlNQUklORyBXRyAm bHQ7c3ByaW5nQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7c3ByaW5nLWNoYWly c0BpZXRmLm9yZyZxdW90OyAmbHQ7c3ByaW5nLWNoYWlyc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OiA8L2I+W0VYVF1bc3ByaW5nXSBXRyBBZG9wdGlvbiBjYWxsIGZvciBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNy aC1jb21wcmVzc2lvbi88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+RGVh ciBXRzo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBleHByZXNzIHRo ZWlyIGFwcHJlY2lhdGlvbiBmb3IgYWxsIHRoZSByZXNwb25zZXMgcmVjZWl2ZWQgdG8gb3VyIGVt YWlscyB3aXRoIHJlZmVyZW5jZSB0byBob3cgdGhlIHdvcmtpbmcgZ3JvdXAgd2lzaGVzIHRvIG1v dmUgZm9yd2FyZCB3aXRoIHJlc3BlY3QgdG8gYSBzb2x1dGlvbiBmb3INCiBTUnY2IGNvbXByZXNz aW9uLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBhcHBhcmVudCBpbmNsaW5hdGlvbiBvZiB0aGUgd29y a2luZyBncm91cCBpcyB0byB1c2UNCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyI+ DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNw cmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88L2E+IGFzIHRoZSBiYXNpcyBmb3IgaXRzIGNvbXBy ZXNzaW9uIHN0YW5kYXJkaXphdGlvbiB3b3JrLiBUaGF0IGlzIHBhcnQgb2Ygd2hhdCB0aGlzIGVt YWlsIGF0dGVtcHRzIHRvIGNvbmZpcm0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5CZWNhdXNlIG9mIHRoZSBh Ym92ZSB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gaXNzdWUgYSAyLXdlZWsgV0cgY2FsbCBmb3Ig YWRvcHRpb24gZW5kaW5nIE9jdG9iZXIgMTU8c3VwPnRoPC9zdXA+IGZvcg0KPGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmct c3J2Ni1zcmgtY29tcHJlc3Npb24vIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLzwvYT4gYnV0 IHdpdGggc29tZSBjbGVhciBndWlkZWxpbmVzIGFzIGZvbGxvd3MuIEJ5IGV4cHJlc3Npbmcgc3Vw cG9ydCBmb3IgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCB5b3UgYXJlIGZ1bGx5IGF3YXJlIG9m IGFuZCBhcmUgYWNrbm93bGVkZ2luZyB0aGF0Og0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0i RU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5n PSJFTi1VUyI+VGhlIFNQUklORyB3b3JraW5nIGdyb3VwIGlzIGFkb3B0aW5nIGEgZG9jdW1lbnQg dGhhdCBoYXMgbXVsdGlwbGUgU1J2NiBFbmRwb2ludCBiZWhhdmlvcnMuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm8zIj4NCjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9z cGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBkb2N1bWVudCBpcyBh IOKAnGxpdmluZ+KAnSBkb2N1bWVudDsgaXQgbWF5IGNoYW5nZSBhcyBpdCBnb2VzIHRocm91Z2gg cmV2aWV3IGFuZCBhbmFseXNpcyBieSB0aGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAuDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMSBsZm8z Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIj48c3BhbiBzdHlsZT0i bXNvLWxpc3Q6SWdub3JlIj4zLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3Nw YW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gbGFuZz0iRU4tVVMiPkFsbCBvcGVuIGRp c2N1c3Npb24gcG9pbnRzIHJhaXNlZCBvbiBvdXIgbWFpbGluZyBsaXN0IE1VU1QgYmUgYWRkcmVz c2VkIEJFRk9SRSBzYWlkIGRvY3VtZW50IGlzIGFsbG93ZWQgdG8gcHJvZ3Jlc3MgZnJvbSB0aGUg d29ya2luZyBncm91cCB0byBwdWJsaWNhdGlvbi4gQSBsaXN0IG9mIHRoZXNlIGRpc2N1c3Npb24g cG9pbnRzIHdpbGwgYmUgZG9jdW1lbnRlZA0KIGluIHRoZSBXRyBkb2N1bWVudCBhbmQgbWFpbnRh aW5lZCBieSB0aGUgZG9jdW1lbnQgZWRpdG9yIGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIGNoYWly cy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEg bGV2ZWwxIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMiPjxz cGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjQuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1 b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1VUyI+ SWYgdGhpcyBkb2N1bWVudCBpcyBhZG9wdGVkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLCB0aGUgY2hh aXJzIHNwZWNpZnkgYXMgcGFydCBvZiB0aGUgYWRvcHRpb24gY2FsbCB0aGF0IHRoZSBmb2xsb3dp bmcgdGV4dCBkZXNjcmliaW5nIGFuIG9wZW4gaXNzdWUgYmUgYWRkZWQgdG8gdGhlIGRvY3VtZW50 IGluIHRoZSBhYm92ZS1kZXNjcmliZWQgb3BlbiBpc3N1ZXMNCiBzZWN0aW9uOiA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MTA4LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMiBsZm8zIj4NCjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gbGFuZz0iRU4tVVMiPiZxdW90O0dpdmVuIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAg aGFzIHNhaWQgdGhhdCBpdCB3YW50cyB0byBzdGFuZGFyZGl6ZSBvbmUgZGF0YSBwbGFuZSBzb2x1 dGlvbiwgYW5kIGdpdmVuIHRoYXQgdGhlIGRvY3VtZW50IGNvbnRhaW5zIG11bHRpcGxlIFNSdjYg RW5kUG9pbnQgYmVoYXZpb3JzIHRoYXQgc29tZSBXRyBtZW1iZXJzIGhhdmUgc3RhdGVkIGFyZSBt dWx0aXBsZQ0KIGRhdGEgcGxhbmUgc29sdXRpb25zLCB0aGUgd29ya2luZyBncm91cCB3aWxsIGFk ZHJlc3Mgd2hldGhlciB0aGlzIGlzIHZhbGlkIGFuZCBjb2hlcmVudCB3aXRoIGl0cyBvbmUgZGF0 YSBwbGFuZSBzb2x1dGlvbiBvYmplY3RpdmUuJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+UGxlYXNl IGNvbnNpZGVyIHRoZSBhYm92ZSBndWlkZWxpbmVzIGFzIHlvdSBkZWNpZGUgb24gd2hldGhlciB0 byBzdXBwb3J0IG9yIG5vdCB0aGlzIFdHIGFkb3B0aW9uLiBQbGVhc2UgZXhwcmVzcyBjbGVhcmx5 IHlvdXIgcmVhc29uaW5nIGZvciBzdXBwb3J0L25vbi1zdXBwb3J0IGFzIHdlbGwgYXMgYW55IG9w ZW4gZGlzY3Vzc2lvbg0KIHBvaW50cyB5b3Ugd291bGQgbGlrZSBhZGRyZXNzZWQgc2hvdWxkIHRo ZSBkb2N1bWVudCBiZSBhZG9wdGVkIGludG8gdGhlIHdvcmtpbmcgZ3JvdXAuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVO LVVTIj5UaGFua3MhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5KaW0sIEJydW5vICZhbXA7IEpvZWw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_5F2843E02F4A4AB9AAF65E9AC089D42Cbellca_-- From nobody Thu Oct 7 12:36:13 2021 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 DB9BA3A0DF9; Thu, 7 Oct 2021 12:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=dO7pHkA6; dkim=pass (1024-bit key) header.d=juniper.net header.b=dr/ciLGw 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 J3rxZWUZjG68; Thu, 7 Oct 2021 12:35:52 -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 BCC3A3A0DF7; Thu, 7 Oct 2021 12:35:52 -0700 (PDT) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 197HFE64021466; Thu, 7 Oct 2021 12:35:48 -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=9lb2RITpDjsghc7Pg+c1b8panRN74WvLpQPLwhd/Q/o=; b=dO7pHkA69aOuQIGR+LVgX+u53L8Q3FovigsJYbZOrC0adyFRtNAWIb9GL6aU1PUmDgYa yCCZx+on7OEhCTsABvRoal2LdYwBpxIxB6AjvZr7VW3P8Vwbyb3eK+7LkXYm6Yax+s0n ODf1oEQNYOKsQueGRotvi4E2+ZoA8tMRorDFvSTk2O5b4PVl4fpCvWaFNpNYq9bvaxvA 8P8aOZ9QSGFnxu9oS2PaGKge5BS+H4F/57YiCSY57Y9u6dROYvEup3UYMl16dCJIHSDg o8IKF8fASToRdOfk++AA+5SjJPVvNbwE/ccabwMnBIjLzetcnEtbj0Kk4hEYiVJeD2FL cA== Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2169.outbound.protection.outlook.com [104.47.57.169]) by mx0a-00273201.pphosted.com with ESMTP id 3bj54r88r9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 07 Oct 2021 12:35:48 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n/hF58vhhYBxd4551D3fw6RUVpITa5QxP3ro2JvJceNwGCDKSPzqK48C+0M5PpbRejSFBY0VgABoZHJzXDVUdmw1y6pT9/C9Cxp2UfSAuSgVyksb7I4+FxZAW1oilT2yzW7pQsH65YS3Y0uuCAcxbefhdpBaHH2Bd5JO7xDDXjgGyCqIaYTXBMjvnq0ekon0cN+DzPPylJQfs8f+Em2IBO9JDbQObrC/STYU7gS+kgYQqmJL8zMbGCZKt0kQlWicqTzDF7TBXsRNANAysPtPpVaQPk/Xvmt/LTWFBeKEKdtgMuoI4/avZbNZNEcKZvySfWRhCmxMXqjUHqDDqOeaVg== 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=9lb2RITpDjsghc7Pg+c1b8panRN74WvLpQPLwhd/Q/o=; b=N13MybEZb7OG7asE8BscxkMAW8RgGjuggR8r3lpO4qa+1NA60+kfsGYXkO+3PrvZH2XmZ4CplvrnL18zbUmRn2Dvnk75X4wvbsuRqR9u/dy7ckTHaUhY0LalAcrGfs6X0620GDIiITXNtgWrZSQMs1OOrLXCv6PrFSoTIjHQo+ZFlfoEzjt1jKMemA9bshP4396lhVR+P9pC7FdSOIvnHzzjGvQJ7YH/jsVuWcT6x0AhmMVxYau6wc5h9+otYxN4ts9t9vWxwT16HAynLGZTGss5ydqPwsbA+jzu/tO5tlUrK9HmRy60sDTgCk8K9GdEZ81rJKGATS0ZtZ4UWgdKQA== 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=9lb2RITpDjsghc7Pg+c1b8panRN74WvLpQPLwhd/Q/o=; b=dr/ciLGwhYzrkdSDTwY6BI7HQe1bmLEv1T6F1TwMY/vr6CSQF4SsLLBNEY80IMPLqv7kAxLo1I8nHgYu4neDBZUME2hlqqEFaAvix9Zfr97V42dBXoJ4Bb8QyHY5njuPU6qYqK75lkDygatKPPmZcKBU+/Kj40GWxCqH2gvLhOY= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by BL0PR05MB5330.namprd05.prod.outlook.com (2603:10b6:208:60::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.11; Thu, 7 Oct 2021 19:35:44 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4608.004; Thu, 7 Oct 2021 19:35:44 +0000 From: Ron Bonica To: Eduard Metz CC: "6man@ietf.org" <6man@ietf.org>, SPRING WG Thread-Topic: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 Thread-Index: Ade3AXyWK2NzAamgSlCvJ497z/5RLwC/aCkQAFbElIAAFRrfwA== Date: Thu, 7 Oct 2021 19:35:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-07T19:35:43Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=fc515d67-35c1-4769-a168-8679822fbec6; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7666bde6-e730-446f-903e-08d989c9a7e2 x-ms-traffictypediagnostic: BL0PR05MB5330: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fTdARB9dcytnTsgNZ9ln8ukqFLWZo8ZCoKcIwU/3g95FyaqN9vdMKkcReRzP1yurWQT/KdSSX7tDfXE/klabRVg1oH72FibUC6F9RO7rGpgmsT1bHlrDKoE8SHs6FGDT6sohGt0DTsbEtYDrThkKa9Z6DZBPFKQxC90mdt/+Ey6BDR6iJYsr7KJIOueWala/f6fModV5Kk+Kqfh6Yknkm8uqVXcJXjIGC0BLWeY1ctem1bF6kr854YgfB8A89+WlsxPDO0bGlSTQd4lm7b7YDj78CVW5QKHasydidtoMTF9a4Gs0u/tbTdmYBidW+2CWxvVKz+eo/JOmWYPskEnhErp0nwtn2QC1Cbwi9jGkgzNEgqoBVmjETHG3oogCvtOGP9ev0RpfNp+htIiA0RBRz0MJvnWJhOCQhwAFMGVg3Gy2m6eqOfk4z1sOa+yLh/NxPBjbLLebs4YZsnoSW+SJJCy3ixY3kSHmQqIbi6g7YtQYdga9RfYr92mPemFcR+qXOnD8r0Ff7cCmu7MLk7Ist5SMglpKFYjKLHNLRlEJXX8ic5UFQXIKloZUGTeVRqnSY6aCkbTxGSxb7A997aVd3hMHZVRXfX1dI4qlSIOho+0GAEEU+43v8YjckRksS9VgPTl6w4dnc9v8MLTBcxtLhlsZgQgU9rokrlTy939xhxbllYiNrEH3uNRWJFc99cw/NSa3471tFRFAfiGYy0SaUw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(9686003)(8676002)(8936002)(55016002)(186003)(7696005)(53546011)(2906002)(6506007)(508600001)(38070700005)(52536014)(83380400001)(38100700002)(64756008)(122000001)(66946007)(54906003)(26005)(4326008)(66476007)(66556008)(66446008)(6916009)(71200400001)(5660300002)(316002)(86362001)(33656002)(76116006); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?QIq6XQwSxZJIgus8VGbgJS6m4L4H2NK8aex48W+sQQeNiySapC+MEbOVcusL?= =?us-ascii?Q?f9VBk3MXXdvE/uDSMAsp4uVuECn3r0K/S8c2Syj4p9wt9U+OJXKqAh5sqILN?= =?us-ascii?Q?SZlKChMsNx1z4hhQXyn6qFwyu9XkPPuE1WDu4tmjUxmXTtRuPiHk951ZL89W?= =?us-ascii?Q?3V435AoTWYq697oqC4ZLf2OyLheXngraIJWPcQORcbc6pjGB/xVITzKu/UXR?= =?us-ascii?Q?Khesfdw29Xc5OUVGLVCXTWGOqGtQqYHngtj+oq3Y7h0UPrNha35AlXsgB5cA?= =?us-ascii?Q?vJmLlWBDwPT9mxWqgsjd+OrrYspezCQe/vTCIFqol+FkZIhIx/w6hqxrPzSk?= =?us-ascii?Q?nFLG2uhpNcqSQL8k7hXfQ8quNGUTdeuxIoIuTqExK3lE53bbST1ndNtfQPsd?= =?us-ascii?Q?t1PZOVSZmzIw0xO7zokzmPmC/HUYbXqf0nWz70J0y4dWdrHFb5OIbyNUqePd?= =?us-ascii?Q?ztA4knMW/aAkWEeezIcrCWLz1wfPop6gW2fuvqUm+XssmXrzLvvNafn0ZwBa?= =?us-ascii?Q?GW7mo7jY8wuZxRr3Fy7nvSAeZ3HsEsyBBZkUGFAH3NOayH8MOgFPHvIJmHZ3?= =?us-ascii?Q?HzsPuymWdkDIF+hDPM2W5fqdE6/ZtczAZIas65TbUOC76ZRWkHq/E/c9MSJW?= =?us-ascii?Q?AjlEmH9nAqJhveEneB8/qE2YH9NLQ5tQk6I3vyJvR+jNWtHjjQbe2liID6rE?= =?us-ascii?Q?y8HW3TvkS6sIymonLaSOPniWcqJRayKrLzYYJbRTeYRaiMJPt8nm9FKBZ7zF?= =?us-ascii?Q?Fxdnd3rhZKBCLGQ6d4aAIBVyWrlZMMLc0Xob420bcCzBdLqLZlnTqFebCeIX?= =?us-ascii?Q?PhNNzNvdMwZ91YZtk3wM406Ws9gh0yuaDtmiku0sMJXUncokOVs5Yro8JSBR?= =?us-ascii?Q?Uaw9SIlr6ZL+jSmDmclhC5e5mrOpIY14cueXpoqzMOPONd6avrRREwZ40xmA?= =?us-ascii?Q?MxVYyy/xGncrfFCrPBZ5KXMW2s0wbBDAHhb5//qlqy8kPuRXgf1JKT4bK6Ul?= =?us-ascii?Q?/8FnH+IPfGIrku6rw8bIbEW+FcSNIXHpDroK9Dt/oJZLEtJ6alm2OXl3CETh?= =?us-ascii?Q?+d7h8t/95qO63qExHZUy51GOgw2aSZsUGbiqvgTnXbS0amc9MDe33v8jUmPp?= =?us-ascii?Q?WwwWoMsb2xQAAjkhnqKT1Wml0BzI/x7RG0LLC2pTwfdrWElukCtSEVzhAB+r?= =?us-ascii?Q?hi6uCWys6Ueo7sXYrW/SlYsSlhq558Jnks2TR2rQvxKBVbScPF3uB3G5sRCG?= =?us-ascii?Q?hHF26/dIpg+xpyQxDUt/KuId9fxdZdTYhoMXeD3iUIpHNgXFT9cdA0YixQUI?= =?us-ascii?Q?Z9d/8fDB7cvypyykvQ6rCRil?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR05MB53167D9938B87ADB6A9958CEAEB19BL0PR05MB5316namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7666bde6-e730-446f-903e-08d989c9a7e2 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2021 19:35:44.6361 (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: RT9Jw7G5zm+oBMkU4j8K1n/RN3qcLcZj0BhXC/hEYsoV5pMIAuV7jxd5/2b6C4mWg2h4407ZMxY3VM8ynzjxqg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5330 X-Proofpoint-ORIG-GUID: 3J3NK88vkIEB7NKsUza-824-f6N7LaMH X-Proofpoint-GUID: 3J3NK88vkIEB7NKsUza-824-f6N7LaMH X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-07_04,2021-10-07_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1011 priorityscore=1501 spamscore=0 mlxlogscore=999 phishscore=0 suspectscore=0 adultscore=0 bulkscore=0 impostorscore=0 mlxscore=0 malwarescore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110070126 Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 07 Oct 2021 19:35:57 -0000 --_000_BL0PR05MB53167D9938B87ADB6A9958CEAEB19BL0PR05MB5316namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Inline [RB] Ron Juniper Business Use Only From: Eduard Metz Sent: Thursday, October 7, 2021 5:03 AM To: Ron Bonica Cc: 6man@ietf.org; SPRING WG Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 [External Email. Be cautious of content] Can the SID be viewed as the address of the "interface" to, in this case, t= he function that resides in a node? From a routing / forwarding point of vi= ew the group of functions is more similar to a network (represented by a pr= efix, rather than a single address), but still. [RB] In RFC 8986, a classic SRv6 SID represents a *single* function that re= sides on a *single* node. If you like, you can even say that represents a *= single* interface to a *single* function that resides on a *single* node. By contrast, a Compressed SID Container (i.e., the 128-bit entity that is c= opied into the IPv6 Destination Address field) represents an entire SR Path= . Specifically, it represents *many* functions that reside on *many* nodes For my understanding, apart from that the (definition of) SID may not be al= igned with the literal text in below RFCs, what is the real problem? Are th= ere any protocols that specifically rely on this definition of an IPv6 addr= ess? [RB] We don't know if there are any protocols that rely on this definition = of the IPv6 address. And if we don't update RFC 4291 before violating it, w= e don't know if anybody might write such an application in the future. = Ron cheers, Eduard --_000_BL0PR05MB53167D9938B87ADB6A9958CEAEB19BL0PR05MB5316namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Inline [RB]

 

   &= nbsp;       Ron

 

 

Juniper Business Use Only

From: Eduard Metz <etmetz@gmail.com> Sent: Thursday, October 7, 2021 5:03 AM
To: Ron Bonica <rbonica@juniper.net>
Cc: 6man@ietf.org; SPRING WG <spring@ietf.org>
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compressio= n-02

 

<= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

 

 

Can the SID be viewed as the address of the "in= terface" to, in this case, the function that resides in a node? From a= routing / forwarding point of view the group of functions is more sim= ilar to a network (represented by a prefix, rather than a single address), but still.

 

[RB] In RFC 8986, a= classic SRv6 SID represents a *single* function that resides on a *= single* node. If you like, you can even say that represents a *si= ngle* interface to a *single* function that resides on a *single* node.

 

By contrast, a Comp= ressed SID Container (i.e., the 128-bit entity that is copied into the IPv6= Destination Address field) represents an entire SR Path. Specifically, it = represents *many* functions that reside on *many* nodes

 

 

For my understanding, apart from that the (definitio= n of) SID may not be aligned with the literal text in below RFCs, what is t= he real problem? Are there any protocols that specifically rely on this def= inition of an IPv6 address?

 

[RB] We don’t= know if there are any protocols that rely on this definition of the IPv6 a= ddress. And if we don’t update RFC 4291 before violating it, we don&#= 8217;t know if anybody might write such an application in the future.

 

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        Ron

 

 

cheers,

  Eduard

 

 

--_000_BL0PR05MB53167D9938B87ADB6A9958CEAEB19BL0PR05MB5316namp_-- From nobody Thu Oct 7 12:44:21 2021 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 D44703A0DF9; Thu, 7 Oct 2021 12:44:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 n0TpWf9erMLz; Thu, 7 Oct 2021 12:44:12 -0700 (PDT) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (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 C32E43A0DF7; Thu, 7 Oct 2021 12:44:12 -0700 (PDT) Received: by mail-pl1-x636.google.com with SMTP id x8so4574682plv.8; Thu, 07 Oct 2021 12:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=jXJfMm6WgCmGPI1qa44Zxh2syg3q09cQbkcjyrBCQmY=; b=fNVNXY/FPEharwcOYFFxMCLx2SwbnBOA+AUlXsU1O9ZIjlU2jt3pbOGbx2+9sK/aHJ 9jhqj/7oEfh+O5atrWGO9FrJN8Zf35hXSKWTrXp57+Z39sKEYCjDDqHQPycFSWrLVnbp T9PF2TcmpGA/cIRLibpNO7WBNj3Uq8II/xP9ys/oCFvRNcfKOwh5dBGjhMFxeplNaTLk Tinv4y/0LnVLLcENwRkAL4Wkb0GRfD/CtGqVAEgldRqwE0uDVxgNwGwlT6CIC77a0IJG i/ibXwAKK4E92+WwoHLcCdPcsyVZY2whXCrAxMcD0luAscBd3aXJNNfL9VbsKF9gRR3N 1QqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=jXJfMm6WgCmGPI1qa44Zxh2syg3q09cQbkcjyrBCQmY=; b=SkJJZnqx0KO4NIuKhUZeoMhQTJoIe8PVtPZmtg/gDhAKV1Xg1IPEg6b2oB4C9mMttl 9h8VlCHahU2SwKs4F981M9ugh6g5y0L7lLQA8JrkULxbsiHd8dpqwDvCbZoVevCIYiyc L/bGgnINGKEM8NEE5sK3aaqFL1YEHeKcObrzjM7IRiCXwh50Y639Sehm6COiiOGfl/wx 7VabLH9Kn5bFMP+uVWhZFN5jK/P/dSKEieg136kaPdxsd35inIteGWotiOk7HPc5emuX nmYJqXqvVmuyRGU1j35l0txMJ3ZtbzW+BHVZfqJLvTje9TJ+DIM+JPX5wZhCAZOWN15U z0WQ== X-Gm-Message-State: AOAM5317ktZHyKDZ8/v7wqV+2nNcUB0hVI+QLgErcymklkrDmZ4BdTZI xnWFrNQ6XCSGDOyVopRfi70= X-Google-Smtp-Source: ABdhPJzf/1UrjMkjhAHhuAmFHW4tEElUA5aUxzcoeLxf2g9IQ+Jeim29Tts8WnldlgqC4FmpjWNATw== X-Received: by 2002:a17:90b:30cb:: with SMTP id hi11mr7527390pjb.51.1633635851973; Thu, 07 Oct 2021 12:44:11 -0700 (PDT) Received: from smtpclient.apple ([66.129.239.10]) by smtp.gmail.com with ESMTPSA id c140sm238795pfc.31.2021.10.07.12.44.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Oct 2021 12:44:11 -0700 (PDT) From: Kireeti Kompella Message-Id: <53432209-37C2-42EB-AD8C-827A25A168F8@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8DE0AFEE-6EB5-49F3-ABDB-34B4A0114268" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Thu, 7 Oct 2021 12:44:10 -0700 In-Reply-To: Cc: Kireeti Kompella , James Guichard , "EXT-Andrew.Alston@liquidtelecom.com" , SPRING WG , "spring-chairs@ietf.org" To: Ron Bonica References: X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-rv6-srh-compression/ 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, 07 Oct 2021 19:44:19 -0000 --Apple-Mail=_8DE0AFEE-6EB5-49F3-ABDB-34B4A0114268 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 > On Oct 5, 2021, at 11:56, Ron Bonica = wrote: >=20 > Jim, > =20 > The call for adoption has already been posted. There is no way to put = that toothpaste back into its tube. However, I strongly recommend = against such calls for adoption in the future. > =20 > Normally, the authors of a document are encouraged to answer technical = questions as a condition of adoption. Bullet points 1, 2, and 4 in the = call for adoption defer that requirement until WG last call. Could this = be why technical questions are not being addressed during the call for = adoption. > =20 > In some extreme conditions, it may be necessary to modify the usual = call for adoption procedure. But these exceptional conditions have not = been articulated. > =20 > It is unfortunate that two of the three working group chairs are also = co-authors of the draft. While there may not have been any impropriety, = the appearance of impropriety is difficult to avoid. > =20 > = Ron > =20 > =20 > =20 > Juniper Business Use Only > From: spring > On Behalf Of James Guichard > Sent: Monday, October 4, 2021 11:10 AM > To: EXT-Andrew.Alston@liquidtelecom.com = = >; SPRING WG > > Cc: spring-chairs@ietf.org > Subject: Re: [spring] WG Adoption call for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = > =20 > [External Email. Be cautious of content] > =20 > Andrew, > =20 > As stated in our email of September 9th, the chairs communicated that = the working group reached rough (quite clear) consensus for = standardizing one data plane solution to compress segment routing over = IPv6. In addition to this there was an inclination toward using the CSID = document as the basis for our work in this area. The chairs recognized = that there was however disagreement as to whether this document, having = multiple SRv6 EndPoint behaviors, could be considered consistent with = the working group consensus for a single data plane solution. This issue = quite clearly needed to be addressed, and the chairs, recognizing that = the working group is keen to make progress in this area, had the option = of trying to resolve the issue prior to issuing an adoption call, or = give the working group the opportunity to express their opinions as part = of a call for adoption. > =20 > Those who feel that we need to resolve the consistency issue before = adoption, as with those who think this is not a good basis for the WG = work, are free and expected to object to the WG adopting the document. = That is distinct from objecting to the chairs issuing the adoption call. > =20 > In essence, the chairs have combined the question of when to resolve = consistency and the question of whether this document is a good basis = for the WG into one call. > =20 > Yours, > =20 > Jim, Bruno & Joel > =20 > =20 > From: Andrew Alston >=20 > Sent: Friday, October 1, 2021 4:21 PM > To: James Guichard >; SPRING WG > > Cc: spring-chairs@ietf.org > Subject: Re: WG Adoption call for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = > =20 > Sorry =E2=80=93 but =E2=80=93 I=E2=80=99m a little confused here. > =20 > Because the way I look at this =E2=80=93 the working group clearly = stated that they wished for a single behavior =E2=80=93 and this =E2=80=93= does not deliver that =E2=80=93 it is two separate behaviors. As such = =E2=80=93 I see this call for adoption =E2=80=93 irrespective of the = merits or lack thereof of the draft, as a clear defiance of the stated = will of the working group. > =20 > This is simply does not fit into the definition of bottom up approach = in my opinion =E2=80=93 and if this is the way that the chairs wish to = proceed =E2=80=93 then the only way to do that and still fit within the = bottom up approach is to first ask this working group for its consensus = to deviate from the single behacvior approach that the working group = agreed to. > =20 > As such =E2=80=93 I must strongly and unequivocally object to this = call for adoption > =20 > Andrew > =20 > From: spring > on behalf of James Guichard = > > Date: Friday, 1 October 2021 at 17:05 > To: SPRING WG > > Cc: spring-chairs@ietf.org = > > Subject: [spring] WG Adoption call for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = > Dear WG: > =20 > The chairs would like to express their appreciation for all the = responses received to our emails with reference to how the working group = wishes to move forward with respect to a solution for SRv6 compression. > =20 > The apparent inclination of the working group is to use = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = as the basis for its compression standardization work. = That is part of what this email attempts to confirm. > =20 > Because of the above the chairs would like to issue a 2-week WG call = for adoption ending October 15th = forhttps://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-co= mpression/ = but with some clear guidelines as follows. By expressing = support for adoption of this document you are fully aware of and are = acknowledging that: > =20 > The SPRING working group is adopting a document that has multiple SRv6 = Endpoint behaviors. > The document is a =E2=80=9Cliving=E2=80=9D document; it may change as = it goes through review and analysis by the SPRING working group. > All open discussion points raised on our mailing list MUST be = addressed BEFORE said document is allowed to progress from the working = group to publication. A list of these discussion points will be = documented in the WG document and maintained by the document editor in = conjunction with the chairs. > If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open = issue be added to the document in the above-described open issues = section: > "Given that the working group has said that it wants to standardize = one data plane solution, and given that the document contains multiple = SRv6 EndPoint behaviors that some WG members have stated are multiple = data plane solutions, the working group will address whether this is = valid and coherent with its one data plane solution objective.". > =20 > Please consider the above guidelines as you decide on whether to = support or not this WG adoption. Please express clearly your reasoning = for support/non-support as well as any open discussion points you would = like addressed should the document be adopted into the working group. > =20 > Thanks! > =20 > Jim, Bruno & Joel > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring = --Apple-Mail=_8DE0AFEE-6EB5-49F3-ABDB-34B4A0114268 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1

On Oct 5, 2021, at 11:56, Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org> = wrote:

Jim,
 
The call for adoption has already = been posted. There is no way to put that toothpaste back into its tube. = However, I strongly recommend against such calls for adoption in the = future.
 
Normally, the authors of a = document are encouraged to answer technical questions as a condition of = adoption. Bullet points 1, 2, and 4 in the call for adoption defer that = requirement until WG last call. Could this be why technical questions = are not being addressed during the call for adoption.
 
In some extreme conditions, it may = be necessary to modify the usual call for adoption procedure. But these = exceptional conditions have not been articulated.
 
It is unfortunate that two of the = three working group chairs are also co-authors of the draft. While there = may not have been any impropriety, the appearance of impropriety is = difficult to avoid.
 
          &nb= sp;            = ;            &= nbsp;           &nb= sp;            = ;            &= nbsp;           &nb= sp;          Ron
 
 
 
Juniper Business Use = Only
From: spring <spring-bounces@ietf.org> On Behalf = Of James = Guichard
Sent: Monday, October 4, 2021 = 11:10 AM
To: EXT-Andrew.Alston@liquidtelecom.com <Andrew.Alston@liquidtelecom.com>; SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org
Subject: Re: [spring] WG Adoption = call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/
 
[External Email. Be cautious of content]
 
Andrew,
 
As stated in our email of = September 9th, the chairs communicated that the working group reached = rough (quite clear) consensus for standardizing one data plane solution = to compress segment routing over IPv6. In addition to this there was an = inclination toward using the CSID document as the basis for our work in = this area. The chairs recognized that there was however disagreement as = to whether this document, having multiple SRv6 EndPoint behaviors, could = be considered consistent with the working group consensus for a single = data plane solution. This issue quite clearly needed to be addressed, = and the chairs, recognizing that the working group is keen to make = progress in this area, had the option of trying to resolve the issue = prior to issuing an adoption call, or give the working group the = opportunity to express their opinions as part of a call for = adoption.
 
Those who feel that we = need to resolve the consistency issue before adoption, as with those who = think this is not a good basis for the WG work, are free and expected to = object to the WG adopting the document. That is distinct from objecting = to the chairs issuing the adoption call.
 
In essence, the chairs have combined the = question of when to resolve consistency and the question of whether this = document is a good basis for the WG into one call.
 
Yours,
 
Jim, Bruno & Joel
 
 
From: Andrew Alston <Andrew.Alston@liquidtelecom.com> 
Sent: Friday, October 1, 2021 = 4:21 PM
To: James Guichard <james.n.guichard@futurewei.com>; SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org
Subject: Re: WG Adoption call = for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/
 
Sorry =E2=80=93 but =E2=80=93 I=E2=80=99m a = little confused here.
 
Because the way I look at = this =E2=80=93 the working group clearly stated that they wished for a = single behavior =E2=80=93 and this =E2=80=93 does not deliver that =E2=80=93= it is two separate behaviors.  As such =E2=80=93 I see this call = for adoption =E2=80=93 irrespective of the merits or lack thereof of the = draft, as a clear defiance of the stated will of the working group.
 
This is simply does not = fit into the definition of bottom up approach in my opinion =E2=80=93 = and if this is the way that the chairs wish to proceed =E2=80=93 then = the only way to do that and still fit within the bottom up approach is = to first ask this working group for its consensus to deviate from the = single behacvior approach that the working group agreed to.
 
As such =E2=80=93 I must =  strongly and unequivocally object to this call for adoption
 
Andrew
 

From: spring <spring-bounces@ietf.org> on behalf of James Guichard <james.n.guichard@futurewei.com>
Date: Friday, 1 October 2021 = at 17:05
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
Subject: [spring] WG Adoption = call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/

Dear = WG:
 
The chairs would like to = express their appreciation for all the responses received to our emails = with reference to how the working group wishes to move forward with = respect to a solution for SRv6 compression.
 
The apparent inclination = of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ as the basis for its = compression standardization work. That is part of what this email = attempts to confirm.
 
Because of the above the = chairs would like to issue a 2-week WG call for adoption ending October = 15th forhttps://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ but with some clear = guidelines as follows. By expressing support for adoption of this = document you are fully aware of and are acknowledging that:
 
  1. The SPRING working group is adopting = a document that has multiple SRv6 Endpoint behaviors.
  2. The document is = a =E2=80=9Cliving=E2=80=9D document; it may change as it goes through = review and analysis by the SPRING working group.
  3. All open = discussion points raised on our mailing list MUST be addressed BEFORE = said document is allowed to progress from the working group to = publication. A list of these discussion points will be documented in the = WG document and maintained by the document editor in conjunction with = the chairs.
  4. If this document is adopted by the working group, the = chairs specify as part of the adoption call that the following text = describing an open issue be added to the document in the above-described = open issues section:
    • "Given that the working group = has said that it wants to standardize one data plane solution, and given = that the document contains multiple SRv6 EndPoint behaviors that some WG = members have stated are multiple data plane solutions, the working group = will address whether this is valid and coherent with its one data plane = solution objective.".
 
Please consider the above guidelines as you = decide on whether to support or not this WG adoption. Please express = clearly your reasoning for support/non-support as well as any open = discussion points you would like addressed should the document be = adopted into the working group.
 
Thanks!
 
Jim, Bruno & Joel
 
 
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

= --Apple-Mail=_8DE0AFEE-6EB5-49F3-ABDB-34B4A0114268-- From nobody Thu Oct 7 12:47:04 2021 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 B32203A0E46; Thu, 7 Oct 2021 12:46:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0hPm9ZBHfTo3; Thu, 7 Oct 2021 12:46:48 -0700 (PDT) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 E4A0D3A0E02; Thu, 7 Oct 2021 12:46:47 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id oa12-20020a17090b1bcc00b0019f715462a8so5991528pjb.3; Thu, 07 Oct 2021 12:46:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=R2Y8uwVzX0cgOeeEl3DSxJ1NAfHXSOlRIK4rmjk2r+8=; b=HfOFq01/E6mkdhQw4e5I0ohDwC8CBl95Ll4ZZ7QQ7GceWHBxGttQqluogFQ4SA/cx4 v54ubMio3RVWIhes7erlASCXggvSL9nC7T4bIzx32hXfvjJey1DVgA5UPiW5DgHKAd8D RVDyWULtCaGeV8+iubCdqnsh60dndWoKMpQ7e4ggUunvkXJPogtvM+I5ChL+Zz1Q6bu8 7RTxl6M8efaoeRDrFt8DMwMawU6vK3XJE0OG6cW0f1tguzYh/VPjwxlIyL+H06KrOKuh FuTUdALbnksMRm9p6y9OJ2ctkNUYCsAfMQn5t7hY+tVgLyH2h1yoVvNrIIhijm7Y2dJX Oq7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=R2Y8uwVzX0cgOeeEl3DSxJ1NAfHXSOlRIK4rmjk2r+8=; b=ltg4nydE6JtJQ1z+3PJKQ36YUSFYSOPfkGJBiofx7pstUBnfG1tmWTPIVbNeTRioF6 XU+OnlxjH9NCs/eOruhPaqA6e5mQF/Z9IN+nGGpMewMLt9CJ8F/PiHvxGdZ6SyKQkEJ7 P7h5Zwft09lYanm/9UdyFI6Z0lQWol9bBiJSnEwCmBxC8idP1+8yLmY5YeuRi6ws5jEZ JwpXoSp5HDNhgmDvXOxGTIc5mrHixaKqzwV14GSJckjkxKaOl8Xjpvwe/y/DERUMMGXU asFY2PYEqK2AuWn4EoCRBIfjn87hUhDceTxw4Z6n+/aUqXIt1/nQLCSua/LOHdP5TSD2 ssEg== X-Gm-Message-State: AOAM533EwkVI6hTbOjrBrwKKQ0WRISdjQltXu57jv45d7UUu2RjryBWW IN4DccaOPr1/0ifrMBG/A4Y= X-Google-Smtp-Source: ABdhPJyQXKSF8vxJPk/rknjt9ym4RPVbkwssse2Ls7IZm2JScPWxjx9RhQNlyG3gJbqRP+WLZ81klg== X-Received: by 2002:a17:90a:3e0c:: with SMTP id j12mr7585623pjc.23.1633636007442; Thu, 07 Oct 2021 12:46:47 -0700 (PDT) Received: from smtpclient.apple ([66.129.239.10]) by smtp.gmail.com with ESMTPSA id u193sm139203pgc.34.2021.10.07.12.46.46 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Oct 2021 12:46:47 -0700 (PDT) From: Kireeti Kompella Message-Id: <89401BA1-D620-4843-9CC2-E606A1242BEC@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_8834F465-FAF5-44E3-804C-78AD7D45F2FE" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Thu, 7 Oct 2021 12:46:46 -0700 In-Reply-To: Cc: Kireeti Kompella , SPRING WG , "spring-chairs@ietf.org" To: James Guichard References: X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 07 Oct 2021 19:47:02 -0000 --Apple-Mail=_8834F465-FAF5-44E3-804C-78AD7D45F2FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I object to the adoption of this document as it currently stands. :K > On Oct 1, 2021, at 07:04, James Guichard = wrote: >=20 > Dear WG: > =20 > The chairs would like to express their appreciation for all the = responses received to our emails with reference to how the working group = wishes to move forward with respect to a solution for SRv6 compression. > =20 > The apparent inclination of the working group is to use = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = as the basis for its compression standardization work. That is = part of what this email attempts to confirm. > =20 > Because of the above the chairs would like to issue a 2-week WG call = for adoption ending October 15th = forhttps://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-co= mpression/ = but with some clear guidelines as follows. By expressing = support for adoption of this document you are fully aware of and are = acknowledging that: > =20 > The SPRING working group is adopting a document that has multiple SRv6 = Endpoint behaviors. > The document is a =E2=80=9Cliving=E2=80=9D document; it may change as = it goes through review and analysis by the SPRING working group. > All open discussion points raised on our mailing list MUST be = addressed BEFORE said document is allowed to progress from the working = group to publication. A list of these discussion points will be = documented in the WG document and maintained by the document editor in = conjunction with the chairs. > If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open = issue be added to the document in the above-described open issues = section: > "Given that the working group has said that it wants to standardize = one data plane solution, and given that the document contains multiple = SRv6 EndPoint behaviors that some WG members have stated are multiple = data plane solutions, the working group will address whether this is = valid and coherent with its one data plane solution objective.". > =20 > Please consider the above guidelines as you decide on whether to = support or not this WG adoption. Please express clearly your reasoning = for support/non-support as well as any open discussion points you would = like addressed should the document be adopted into the working group. > =20 > Thanks! > =20 > Jim, Bruno & Joel > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring = --Apple-Mail=_8834F465-FAF5-44E3-804C-78AD7D45F2FE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = object to the adoption of this document as it currently stands.

:K

On Oct = 1, 2021, at 07:04, James Guichard <james.n.guichard@futurewei.com> wrote:

Dear WG:
 
The chairs would like to express their = appreciation for all the responses received to our emails with reference = to how the working group wishes to move forward with respect to a = solution for SRv6 compression.
 
The apparent inclination of the working group is = to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ as the basis for its = compression standardization work. That is part of what this email = attempts to confirm.
 
Because of the above the = chairs would like to issue a 2-week WG call for adoption ending October = 15th forhttps://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ but with some clear = guidelines as follows. By expressing support for adoption of this = document you are fully aware of and are acknowledging that:
 
  1. The SPRING working group is adopting = a document that has multiple SRv6 Endpoint behaviors.
  2. The document is = a =E2=80=9Cliving=E2=80=9D document; it may change as it goes through = review and analysis by the SPRING working group.
  3. All open = discussion points raised on our mailing list MUST be addressed BEFORE = said document is allowed to progress from the working group to = publication. A list of these discussion points will be documented in the = WG document and maintained by the document editor in conjunction with = the chairs.
  4. If this document is adopted by the working group, the = chairs specify as part of the adoption call that the following text = describing an open issue be added to the document in the above-described = open issues section:
    • "Given that the working group has = said that it wants to standardize one data plane solution, and given = that the document contains multiple SRv6 EndPoint behaviors that some WG = members have stated are multiple data plane solutions, the working group = will address whether this is valid and coherent with its one data plane = solution objective.".
 
Please consider the above guidelines as you = decide on whether to support or not this WG adoption. Please express = clearly your reasoning for support/non-support as well as any open = discussion points you would like addressed should the document be = adopted into the working group.
 
Thanks!
 
Jim, Bruno & Joel
 
 
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

= --Apple-Mail=_8834F465-FAF5-44E3-804C-78AD7D45F2FE-- From nobody Thu Oct 7 12:55:27 2021 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 E96F73A0E19; Thu, 7 Oct 2021 12:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUZqXs9SE9d0; Thu, 7 Oct 2021 12:55:23 -0700 (PDT) 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 6E8553A0E0B; Thu, 7 Oct 2021 12:55:23 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id k23-20020a17090a591700b001976d2db364so6027065pji.2; Thu, 07 Oct 2021 12:55:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KzZpJ4DOEN1hacKn3ra5vFyVqxnqgH6sgLjeMaW6Jqg=; b=Lr2nZemVzDj1wFrJKt7CiOyV7XuFcspVMAsKbgRT0z3disjnVKfanMyxB6CK03T9i7 lz+FTz2Fn+1riWTldmN1dOIIuXKaerO1GwLQk/CKr+2fEGFdIdrLDWdCtzDx49sbEsWU ROHUfSkxMpF6NKkCbzmyIYa8QICHqX12GX4uNGHfPe0rGEabUmODjIP36CkXyDO+xvY5 XFtvpy7Ts+pSsQfaVDEoZlpHgBn0no9KzmNQmwvXQnhZrg76U8A2ziBHd0SU/YSgOzSJ D2KJ2Xewpfy0vmPMUf05ce8CXZRsV3gNT+jAuASkweDFGmVbZzKi24pDeIG9Lr0Xi2MB dZ5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KzZpJ4DOEN1hacKn3ra5vFyVqxnqgH6sgLjeMaW6Jqg=; b=ir72jWtNU5NT0+sfDJTZveNtBjuyFmJ4JaGH2cuk4FSMOgYganinkzYNAcKiIKGD+g Dv338IsyaaJrsoOpXvqRnZQXxIP4hxdA7Pg/2S/iLDXL1v5/BteGKWQO0bxfjtEIM1NA dbPeIhoWcxp5Q1EBeNeXcaPcwhbqeplxGqtQiqZE+EB7M0jMnxRk/HeQqZPmEe/Ck2pt GndwFJvWiCmlhVdhMeA99WPxMaXQ7+eWLQhDJSXS5QQ+kNJKzjWFl/jVfH0Ba2WeA8vR 7oTlqTyIJA4hI406VFhGZvslY64LUSP5VIffHj+5CTY64uMdDpD9swi1Cm/mZorjJGvj oU6w== X-Gm-Message-State: AOAM530BFf8ZGe6qOJQCm0WfjfKN8BB+nPA/gcKfOxuGLtw6bk6FXHGG XLTV/W31YMzB1qGL1lUVa7fZ7ypecMA= X-Google-Smtp-Source: ABdhPJxkAw6zhwAjhcuu2+I0jKT+0+rT/8Crw5R/cSoQ2RDiEc27zoUY1xc4ESsYfk8v6yGzL7QINA== X-Received: by 2002:a17:90a:cc13:: with SMTP id b19mr7081440pju.45.1633636522829; Thu, 07 Oct 2021 12:55:22 -0700 (PDT) Received: from smtpclient.apple ([66.129.239.11]) by smtp.gmail.com with ESMTPSA id g22sm264753pfj.15.2021.10.07.12.55.21 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Oct 2021 12:55:22 -0700 (PDT) From: Colby Barth Message-Id: <01EABD30-E7CF-47AC-976A-D410967BC5AE@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_398C81EF-DD56-4BFC-AFF6-98A23FD2994B" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Thu, 7 Oct 2021 15:55:20 -0400 In-Reply-To: <89401BA1-D620-4843-9CC2-E606A1242BEC@gmail.com> Cc: SPRING WG , "spring-chairs@ietf.org" To: James Guichard References: <89401BA1-D620-4843-9CC2-E606A1242BEC@gmail.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 07 Oct 2021 19:55:25 -0000 --Apple-Mail=_398C81EF-DD56-4BFC-AFF6-98A23FD2994B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I object to the adoption of this document in its current form. =E2=80=94Colby >> Dear WG: >> =20 >> The chairs would like to express their appreciation for all the = responses received to our emails with reference to how the working group = wishes to move forward with respect to a solution for SRv6 compression. >> =20 >> The apparent inclination of the working group is to use = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = as the basis for its compression standardization work. That is = part of what this email attempts to confirm. >> =20 >> Because of the above the chairs would like to issue a 2-week WG call = for adoption ending October 15th = forhttps://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-co= mpression/ = but with some clear guidelines as follows. By expressing = support for adoption of this document you are fully aware of and are = acknowledging that: >> =20 >> The SPRING working group is adopting a document that has multiple = SRv6 Endpoint behaviors. >> The document is a =E2=80=9Cliving=E2=80=9D document; it may change as = it goes through review and analysis by the SPRING working group. >> All open discussion points raised on our mailing list MUST be = addressed BEFORE said document is allowed to progress from the working = group to publication. A list of these discussion points will be = documented in the WG document and maintained by the document editor in = conjunction with the chairs. >> If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open = issue be added to the document in the above-described open issues = section: >> "Given that the working group has said that it wants to standardize = one data plane solution, and given that the document contains multiple = SRv6 EndPoint behaviors that some WG members have stated are multiple = data plane solutions, the working group will address whether this is = valid and coherent with its one data plane solution objective.". >> =20 >> Please consider the above guidelines as you decide on whether to = support or not this WG adoption. Please express clearly your reasoning = for support/non-support as well as any open discussion points you would = like addressed should the document be adopted into the working group. >> =20 >> Thanks! >> =20 >> Jim, Bruno & Joel >> =20 >> =20 >> _______________________________________________ >> 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 --Apple-Mail=_398C81EF-DD56-4BFC-AFF6-98A23FD2994B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
I object to the adoption of this document in its = current form.


=E2=80=94Colby

Dear WG:
 
The chairs would like to express their = appreciation for all the responses received to our emails with reference = to how the working group wishes to move forward with respect to a = solution for SRv6 compression.
 
The apparent inclination of the working group is = to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ as the basis for its = compression standardization work. That is part of what this email = attempts to confirm.
 
Because of the above the = chairs would like to issue a 2-week WG call for adoption ending October = 15th forhttps://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ but with some clear = guidelines as follows. By expressing support for adoption of this = document you are fully aware of and are acknowledging that:
 
  1. The SPRING working group is adopting = a document that has multiple SRv6 Endpoint behaviors.
  2. The document is = a =E2=80=9Cliving=E2=80=9D document; it may change as it goes through = review and analysis by the SPRING working group.
  3. All open = discussion points raised on our mailing list MUST be addressed BEFORE = said document is allowed to progress from the working group to = publication. A list of these discussion points will be documented in the = WG document and maintained by the document editor in conjunction with = the chairs.
  4. If this document is adopted by the working group, the = chairs specify as part of the adoption call that the following text = describing an open issue be added to the document in the above-described = open issues section:
    • "Given that the working group has = said that it wants to standardize one data plane solution, and given = that the document contains multiple SRv6 EndPoint behaviors that some WG = members have stated are multiple data plane solutions, the working group = will address whether this is valid and coherent with its one data plane = solution objective.".
 
Please consider the above guidelines as you = decide on whether to support or not this WG adoption. Please express = clearly your reasoning for support/non-support as well as any open = discussion points you would like addressed should the document be = adopted into the working group.
 
Thanks!
 
Jim, Bruno & Joel
 
 
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

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

= --Apple-Mail=_398C81EF-DD56-4BFC-AFF6-98A23FD2994B-- From nobody Thu Oct 7 12:55:50 2021 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 6A73E3A0E57; Thu, 7 Oct 2021 12:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5M5ccXU-LAF4; Thu, 7 Oct 2021 12:55:34 -0700 (PDT) Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) (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 B90BE3A0E2F; Thu, 7 Oct 2021 12:55:34 -0700 (PDT) Received: by mail-pg1-x52a.google.com with SMTP id r2so813088pgl.10; Thu, 07 Oct 2021 12:55:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GE8gkwfsrdF8PQbqzMzpRto5agC36/m5P2hVawIv9Us=; b=k/x3YOl514OaVZdk0r+afnBgi4YS3ZTvzjHkk4FGqStTjcbz0nHjbk62pZq4UJ5U8l u67VBrVL86gS0J4j73fHAgJ00/1FsltxdPLtclZd4W8PKqi2BVc71rGBwQe1XL+y4sHe qLUBy18yMliauXcl+jXPm54Jw1dpbqBcimBbNmIFLrqmETYS7eLgePbyKdk436pkHAku VoAoumLdSkUr3g+yiaZaMygDjwVuJ6dHx+ics3iWO1/fnGIyJdB+ROUmwCMgszLEdtqp sQbchwIJ4p2qSxtyfacjU7e7d0uoV6i0pw84KEC1XvaYaD8ljc4BRfvQvZa3202PAs6Y EW9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GE8gkwfsrdF8PQbqzMzpRto5agC36/m5P2hVawIv9Us=; b=Xv+PkAZOkRdDXnRLlywjkasXKhquVlLtriT+Zu4aTmTURuVYvjKN6yyFZRZ+3zZbzl 23S9BGRA5weIuzj9WODZbCIMzSc+MeHRUBWcslx1/cmOcvqQ6uC/hJkoFXwNbxMd/0qC 2QLNNawd/BS6BXcLcoAVa3WzyxEl85sKkA6NF3SABG0bdRJbgGvGMIFnrFgd/lB+PQuC QdyS4QuK8/167XfccX+4M3gc0jEEJYEgq15PT4j0yqrTTGQ3zDjo3U1eiDjXsuPDJ/6p Tk35F3zYVlBRw8dYaeUtJa9TYmdoe3cYUnxjbbH8AcRY4s4Km/hsZftbeglYKMvH3MDn 7dGA== X-Gm-Message-State: AOAM530kCPCEw2AKrU92nWeo+qaiWeCmDccY/CjSx4gLWGrP1P52ICwn fvAZjapVlqHgLJQ38Z8c8SKHJUBE3BU= X-Google-Smtp-Source: ABdhPJxMdLYcix76gZbC31Dkg5CZ0B0dzv95hjd4My7moSlxGkjoxIdh7kVvy2SzbUg559HFKUHhCw== X-Received: by 2002:a05:6a00:a1e:b0:44c:7602:e1ee with SMTP id p30-20020a056a000a1e00b0044c7602e1eemr6064988pfh.80.1633636532739; Thu, 07 Oct 2021 12:55:32 -0700 (PDT) Received: from smtpclient.apple ([66.129.239.10]) by smtp.gmail.com with ESMTPSA id y8sm213845pfe.217.2021.10.07.12.55.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Oct 2021 12:55:32 -0700 (PDT) From: Kireeti Kompella Message-Id: <2D3AD4E3-2C84-4F8D-9AF3-7D3330CC4311@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_90E9BA57-092F-4E02-BECD-F04FB1533810" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Thu, 7 Oct 2021 12:55:31 -0700 In-Reply-To: Cc: Kireeti Kompella , SPRING WG , "spring-chairs@ietf.org" To: James Guichard References: X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 07 Oct 2021 19:55:48 -0000 --Apple-Mail=_90E9BA57-092F-4E02-BECD-F04FB1533810 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I also object to WG chairs who are also co-authors of a draft = participating in the process of advancing the draft through the WG = process, whether it is WG adoption, WGLC or IETF LC. Look up =E2=80=9Crecuse=E2=80=9D in the dictionary. :K > On Oct 1, 2021, at 07:04, James Guichard = wrote: >=20 > Dear WG: > =20 > The chairs would like to express their appreciation for all the = responses received to our emails with reference to how the working group = wishes to move forward with respect to a solution for SRv6 compression. > =20 > The apparent inclination of the working group is to use = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = as the basis for its compression standardization work. That is = part of what this email attempts to confirm. > =20 > Because of the above the chairs would like to issue a 2-week WG call = for adoption ending October 15th = forhttps://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-co= mpression/ = but with some clear guidelines as follows. By expressing = support for adoption of this document you are fully aware of and are = acknowledging that: > =20 > The SPRING working group is adopting a document that has multiple SRv6 = Endpoint behaviors. > The document is a =E2=80=9Cliving=E2=80=9D document; it may change as = it goes through review and analysis by the SPRING working group. > All open discussion points raised on our mailing list MUST be = addressed BEFORE said document is allowed to progress from the working = group to publication. A list of these discussion points will be = documented in the WG document and maintained by the document editor in = conjunction with the chairs. > If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open = issue be added to the document in the above-described open issues = section: > "Given that the working group has said that it wants to standardize = one data plane solution, and given that the document contains multiple = SRv6 EndPoint behaviors that some WG members have stated are multiple = data plane solutions, the working group will address whether this is = valid and coherent with its one data plane solution objective.". > =20 > Please consider the above guidelines as you decide on whether to = support or not this WG adoption. Please express clearly your reasoning = for support/non-support as well as any open discussion points you would = like addressed should the document be adopted into the working group. > =20 > Thanks! > =20 > Jim, Bruno & Joel > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring = --Apple-Mail=_90E9BA57-092F-4E02-BECD-F04FB1533810 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = also object to WG chairs who are also co-authors of a draft = participating in the process of advancing the draft through the WG = process, whether it is WG adoption, WGLC or IETF LC.

Look up =E2=80=9Crecuse=E2=80=9D in the = dictionary.

:K

On Oct 1, 2021, at 07:04, James Guichard = <james.n.guichard@futurewei.com> wrote:

Dear WG:
 
The chairs would like to express their = appreciation for all the responses received to our emails with reference = to how the working group wishes to move forward with respect to a = solution for SRv6 compression.
 
The apparent inclination of the working group is = to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ as the basis for its = compression standardization work. That is part of what this email = attempts to confirm.
 
Because of the above the = chairs would like to issue a 2-week WG call for adoption ending October = 15th forhttps://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ but with some clear = guidelines as follows. By expressing support for adoption of this = document you are fully aware of and are acknowledging that:
 
  1. The SPRING working group is adopting = a document that has multiple SRv6 Endpoint behaviors.
  2. The document is = a =E2=80=9Cliving=E2=80=9D document; it may change as it goes through = review and analysis by the SPRING working group.
  3. All open = discussion points raised on our mailing list MUST be addressed BEFORE = said document is allowed to progress from the working group to = publication. A list of these discussion points will be documented in the = WG document and maintained by the document editor in conjunction with = the chairs.
  4. If this document is adopted by the working group, the = chairs specify as part of the adoption call that the following text = describing an open issue be added to the document in the above-described = open issues section:
    • "Given that the working group has = said that it wants to standardize one data plane solution, and given = that the document contains multiple SRv6 EndPoint behaviors that some WG = members have stated are multiple data plane solutions, the working group = will address whether this is valid and coherent with its one data plane = solution objective.".
 
Please consider the above guidelines as you = decide on whether to support or not this WG adoption. Please express = clearly your reasoning for support/non-support as well as any open = discussion points you would like addressed should the document be = adopted into the working group.
 
Thanks!
 
Jim, Bruno & Joel
 
 
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

= --Apple-Mail=_90E9BA57-092F-4E02-BECD-F04FB1533810-- From nobody Thu Oct 7 13:20:14 2021 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 DF0193A0E3C; Thu, 7 Oct 2021 13:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 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, 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=GZkSPFpq; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=bA5MExjs 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 F32rPlYuMOov; Thu, 7 Oct 2021 13:20:05 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 684093A0E2A; Thu, 7 Oct 2021 13:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14340; q=dns/txt; s=iport; t=1633637979; x=1634847579; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IRkUHhXJdITCOKkHsPNbTMCRSotvNTmq/e3vOC7TAhE=; b=GZkSPFpqMF/3R/X5QVVAUdsbRjS4qdPFo3tUI7MGxrNLvul+9flvj2Gc Xk3odOmdsWUqEgI95YQB9wshUv6lFJTgMrGS8P50rtRn5528XFV0/PwWB U/Rlf1pGSR+2vsDix/NPMEKRfFX2siRurBYcQKkGOFa02af83sGyt8JP+ c=; IronPort-PHdr: =?us-ascii?q?A9a23=3A/IOWyRUaPtAMpzWOEfBttFYm37jV8K0YAWYlg?= =?us-ascii?q?6HPw5pAb7i+5Zn9MU2Z7vJo3xfFXoTevvRDjeee86XtQncJ7pvJtnceOIdNW?= =?us-ascii?q?BkIhYRz/UQgDceJBFe9IKvsaCo3T8pfSEJ/8m62MA5eH8OtL1HXq2e5uDgVH?= =?us-ascii?q?Bi3PAFpJ+PzT4jVicn/1+2795DJJQtSgz/oarJpJxLwpgLU5aEr?= IronPort-Data: =?us-ascii?q?A9a23=3AMGNMbqK9U5SDXdF+FE+RG5clxSXFcZb7ZxGr2?= =?us-ascii?q?PjKsXjdYENS1DMHnDYbCDrVOqmDZzSnc412YIqx8BgG75PUn942Slcd+CA2R?= =?us-ascii?q?RqmiyZq6fd1j6vI0qj7wvTrFCqL1O1DLImdRCwIZiWE/E70auC+9SIUOZygH?= =?us-ascii?q?9IQNsaVYkideic8IMsRoUoLd98R2uaEs/Dga+++kYuaT/nkBbOQ82Uc3lT4R?= =?us-ascii?q?E60gEgHUPza4Fv0t7GlDBxBlAe2e3I9VPrzKUwtRkYUTLW4HsbiLwrC5Kuy8?= =?us-ascii?q?mWc9BA3B5b41L36aUYNBLXVOGBiiFIPBPPk2UcE93d0i/tlXBYfQR8/ZzGhh?= =?us-ascii?q?d94ztlNtLS7SBwiOevHn+F1vxxwTX4iZfUaqeKaSZS4mYnJp6HcSFP32+9vC?= =?us-ascii?q?k5zNo0R+/xsKWBD6fJeLyoCBjiYn/i3xr2TS+RwiIIkNsaDFIEWv3x7izefA?= =?us-ascii?q?usnSpDKWani68JEwS09mc1PW/3ZYqIkhZBHBPjbSwdENlFSA5UkkaL1wHL+a?= =?us-ascii?q?DZf7lmSoMIKD6Ho5FQZ+NDQ3BD9I7Rmnfloo3s=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AYv6WO61VXQs1YqEkgKAs0QqjBRByeYIsim?= =?us-ascii?q?QD101hICG9Lfb4qyn+ppomPEHP5wr5AEtQ5uxpOMG7MBThHO1OkPcs1NaZLU?= =?us-ascii?q?jbUQ6TTL2KgrGSuAEIdxeOk9K1kJ0QD5SWa+eATWSS7/yKmjVQeuxIqLLsnc?= =?us-ascii?q?zY5pa9854ud3AWV0gK1XYeNu/vKDwPeOAwP+tBKHPz3LsimxOQPVAsKuirDH?= =?us-ascii?q?gMWObO4/fRkoj9XBIADxk7rCGTkDKB8tfBYlul9yZbdwkK7aYp8GDDnQC8zL?= =?us-ascii?q?6kqeuHxhjV0HKWx4hKmeHm1sBICKW3+4oow3TX+0OVjbZaKvq/VQMO0aeSAZ?= =?us-ascii?q?ER4YDxSiIbToBOArXqDzmISFXWqlLdOX0Vmg7fIBej8AveSIrCNWgH4w4rv/?= =?us-ascii?q?METvMfgHBQ4e2UmZg7rF6xpt5ZCwjNkz/64MWNXxZ2llCsqX5niuILiWdDOL?= =?us-ascii?q?FuJYO5gLZvt3+9Kq1wVh4SKbpXZ9VGHYXZ/rJbYFmaZ3fWsi1mx8GtRG06Gl?= =?us-ascii?q?ODTlIZssKY3jBKlDQhpnFoi/A3jzMF7tYwWpNE7+PLPuBhk6xPVNYfaeZ4CP?= =?us-ascii?q?0aScW6B2TRSVbHMX6UI17gCKYbUki956Lf8fEw/qWnaZYIxJw9lNDIV05Zr3?= =?us-ascii?q?c7fwb0BciHzPRwg1jwqaWGLH3QI+RlltZEU5HHNc/W2By4OSYTepGb0oci6+?= =?us-ascii?q?XgKoKOBK4=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BWAAAaVl9h/5xdJa1aHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUUHAQELAYEgMCMuB3daNzGIDgOEWWCICYNbkg6FBoEuFIE?= =?us-ascii?q?RA1QLAQEBDQEBNwoEAQGEfgKCSAIlNAkOAQIEAQEBEgEBBQEBAQIBBgSBERO?= =?us-ascii?q?FOwglDYZDAgEDEgsQEwEBLAsBDwIBCDsLMiUCBAENBQgTB4JQgX5XAy8BDqE?= =?us-ascii?q?UAYE6AoofeIEzgQGCCAEBBgQEgUpBgn8YgjUDBoE6AYMAhBOGdRcQHIFJRIE?= =?us-ascii?q?VQ4JnPoJjAgOBIwUBEgEjK4MiggwiilMvQmQEGzggAlkWgQIqESmeCo1Mkio?= =?us-ascii?q?KgzCKRpRBFINqi2yXQIcTjxKMTZh4AgQCBAUCDgEBBoFhO2lwcBU7gmlRGQ+?= =?us-ascii?q?DPopiDBYVGYMihRSFSnQ4AgYBCgEBAwmUcQEB?= X-IronPort-AV: E=Sophos;i="5.85,355,1624320000"; d="scan'208,217";a="674004955" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Oct 2021 20:19:37 +0000 Received: from mail.cisco.com (xbe-rcd-006.cisco.com [173.37.102.21]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 197KJa5C004932 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 7 Oct 2021 20:19:37 GMT Received: from xfe-aln-004.cisco.com (173.37.135.124) by xbe-rcd-006.cisco.com (173.37.102.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 7 Oct 2021 15:19:36 -0500 Received: from xfe-rtp-002.cisco.com (64.101.210.232) 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.792.15; Thu, 7 Oct 2021 15:19:35 -0500 Received: from NAM12-DM6-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.792.15 via Frontend Transport; Thu, 7 Oct 2021 16:19:35 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oMF2+D/ypCPa3zEzXndQNMzPjhd9gfwhxZkJJD+zcKGhERscMPwVuIBDoXDQer0QDtf4eGEqlFiO7vH7dNdTOoAeE0IjySLBOW5qabvKJyY09DFQyF2vj84LOJInTrrHLi2bxz4z0puQEA5fpFyncq+gFh+b49Q5qvcdG63a74u2xQqPfauLjtopiY9Qeud33B7arnRO+zvACLqDKxZ+NDEIGIOo+V5soaJavYX8Ea8yspH1U+Ozwapp1fsnfokURVkbjsjquL1l2ECOzjHu+gqQ59Ilul7d1iMQqDepKH3o2tgOoRCuGZBltDkGGgsdTsAmTScQg8gTv4JZoeQsGw== 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=wY+95Wswii7It7P7kA1cS6F3Yq771ufGcBM72ItAbKU=; b=e1LqRAeD+nL5YZtyRRjx4fy0QUbSlYOc3YZoZzoxHAKnFA2lZZ0d5OnEvKsfgU9NLcbVz4SlKR/BcZkJE3bKTOxMfdeYSuIhOy+3bYbr9el1r7WbpqSaCUboJjvnWw+neCJgu1XDP3Gkf+GbPzalmKOilrnMhZC71UWm8pX5aqncUrav2Yc9klMA6G810q7yh2Fx8PvHRbfB4BGqDva8pRWUvBzuno61f66EC69m1BVnvHPI/sUF0Q4lYIG4z9Fpzs2tn49yT15012uT7Iqev7y0a7Flfajcr9nLnLvnBv4q/X2Odp7dTBCdFfQWGTtlLhuVB5QL8+BC1Xak+kq9rw== 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=wY+95Wswii7It7P7kA1cS6F3Yq771ufGcBM72ItAbKU=; b=bA5MExjs+R3cZ/U4FEHSfSGbHkLN8xYzYVv4CUtDBg4BnrN7WgBpDmH83J8q1zChdJdfz0pRaBoEV6AIKc4t2AhKiK0CkuDxtDX44Lnm+vVylx8dtbDafRsL2iLM9mlbxH3YJ5U2+rpf+fievVRIjblC53i4hOJIi2uNUoj3eGU= Received: from BL3PR11MB5731.namprd11.prod.outlook.com (2603:10b6:208:352::15) by MN2PR11MB3837.namprd11.prod.outlook.com (2603:10b6:208:f6::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.19; Thu, 7 Oct 2021 20:19:29 +0000 Received: from BL3PR11MB5731.namprd11.prod.outlook.com ([fe80::80a7:582:90b2:b20d]) by BL3PR11MB5731.namprd11.prod.outlook.com ([fe80::80a7:582:90b2:b20d%8]) with mapi id 15.20.4587.020; Thu, 7 Oct 2021 20:19:28 +0000 From: "Rakesh Gandhi (rgandhi)" To: "'James Guichard'" , "'SPRING WG'" CC: "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: AQHXu7ihe8qHDE+a+EOP+/ND/p9bjQ== Date: Thu, 7 Oct 2021 20:19:28 +0000 Message-ID: References: <002701d7b9f8$66e72010$34b56030$@cnit.it> In-Reply-To: <002701d7b9f8$66e72010$34b56030$@cnit.it> Accept-Language: en-CA, en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d812c3cf-6063-4071-c518-08d989cfc3fc x-ms-traffictypediagnostic: MN2PR11MB3837: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: u/r7bQBKuqhvHFmswHJ1xHQ1JYKAZtNAvmv9iXb941XNawzx1ot39ILjw+8Loxz9kr3bPQU51K94WbsSAMMAoXatv2xa1pdHiicd1gLKbOL4yjykBOJZr6/zLW8AUKMKLSKp6cJUq0FsTYZFurp+avsA3JyCma8iZFnsg18SFpiO+VpSwIr8h4dPvd1Cxj/hNDkqYYA2SsEBrJWROv8A8Z7NaUt4OeUp/rXX1QlSNB6V3KnvybktkzzlgSRjMGB4zkoMTlafg1GANSs9s6lLs0Wp8ipt2VO3WhrPWOrEyVd1oez4NrAB2g2Bd7wt1hRSrekCy3+0lvBsw9CFTvm5LZM+asfiMLmZ5yOARQkqroMCnG1I/S/KDpi+SkjO0G68Wq+ACGKe9yFj9N5FeNM/OnPefT7CJn8L+pNH25nq7tut2fbywxUw1hwg9uI5kzMZq+b9katnAlP5o/UtvrDFGWYIX5EuNgf1qOq6ztDM45sIsM62PTIyO/AHmb95Vk55I6aewSFVyUwaMw/iyCKvVjfRyswr1hg42Au6FgIHZtUtbTENtlu1/b0MTFPWgkvQZZdAiR5jh85hvkEPNmkGPclp7y6dsO78CX5Ja2SmyEYq8HAuy5cjvP/rb5Jm0nzbWhQxUPT76bb8SiBAteQ3Uv1uW3pjMecImk9x3ph17IChoRdH0fZqN8YO45cSj0cXX2I7hyMGirDJqTXO01g5Fh4ZynNtgb1SeWPg45f8JYlelaAT+detLvc+Va9KUUyj1+dGT52C42pbOAcE2GH7lTSAi8g6jHJDUrvTlWUrj6Y= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL3PR11MB5731.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(166002)(6506007)(38100700002)(26005)(316002)(83380400001)(7696005)(9686003)(122000001)(5660300002)(8676002)(33656002)(38070700005)(2906002)(64756008)(55016002)(966005)(8936002)(186003)(86362001)(52536014)(508600001)(71200400001)(76116006)(110136005)(4326008)(66556008)(66476007)(66946007)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?mSq/uxBMJMQLGEjfuDeSI90at5mNhJCyWgrRV7en0N89aZrjL5AXi1hY?= =?Windows-1252?Q?MEeVpHbDmmzDaxOE++hL/+ulJutvxBZYi//9LkGyxRBXAbQhIEDGdJLj?= =?Windows-1252?Q?6UwleJdRVmm7xbtNDZkIpUosPjPeM2dd6HJONa2EyLwh6fso/5NQwNRb?= =?Windows-1252?Q?USqQs04De4W6ctlD7um1+S73DKSEusc5pwaGLhwtQ7D7WflKCCl1+IRO?= =?Windows-1252?Q?cBtKPbOO01ABknGDWz7PsA8OWIFcG0CyXuVW13rWS1gAL5gWC9F5ocan?= =?Windows-1252?Q?RBGHscUfA91E/2LdY4pa0b85+QYEzSrSarjfDfiB47Ikuh7QX4kXWulL?= =?Windows-1252?Q?HBnG3YJppd0l89NVGXk0L80EbEpyady/g9uEcXGzTRbrDd8UOc7hX1Jy?= =?Windows-1252?Q?hN4yc6wNAFokQ2AHSf6xoTngRdj8SlFLENrnHEi/19em4DVBC1vqZC4X?= =?Windows-1252?Q?0XaXeCZZ4olmosKnCERp4+1NylRU8/+G9dvUsea0Jv5Y51YckyUcOB+q?= =?Windows-1252?Q?xOzefY6g9gGduhHIbRyYgrAVZev1lkdV1hoCH4sJUUD7+9AL1DFfGJZ2?= =?Windows-1252?Q?LEi4SeMuRL7XCAOPIDUdsHjVd/K8OkPy0YDZexiJwbI5ezaBxfcz25I5?= =?Windows-1252?Q?DhjlDm+G4aSgcHxg6Q0QZ7qtV7Gbi0+lGCiSMzqwrpu/YEB5AWKdNgSt?= =?Windows-1252?Q?9jD6d0kZAmHph7dDMtTXO/gh4k8rBKe8gW4boBwFb6uNsk5PU8FXXFIu?= =?Windows-1252?Q?5Aq9UpoboNgGrqgPxqqisSKG3eXnQi9NVzm2o7lQtTgCDMO7t52UNFEL?= =?Windows-1252?Q?GfGigbwOW1PvoWbuGRI/2ZEmBZV1eNYH924RqwD6emoe9vdi/X7AwV8C?= =?Windows-1252?Q?93jXxBxjfAu/UV/PrjPm6w9IJii6aJwS6tZsLu4nbd2IU/v9HRwVaNyE?= =?Windows-1252?Q?++t9vFMewMmTvGgavuahzX1LpRNk9Kg/REHV1lbbYcTUtyJq4dpcS7KY?= =?Windows-1252?Q?8yVvkzHUh1dzmu/11vwI6fb/GtJrGPJ4ae12MXJ5qP9KeDr3od9R4qhG?= =?Windows-1252?Q?kdnnnTsQNopzYG1/JpAFbb31XfjCUCZvko3XyPct+8O8woJJeVHlDuK7?= =?Windows-1252?Q?ydbjBkaLpSa2Px2TOQfPkBNAv40FjNhIo2vMyzjPp9dBEufGpZK9d0OL?= =?Windows-1252?Q?0y/aIbWEocYWfgoJHjWVumgnqIh0WLYcT+OBRlpiU8ktq3waq88T+yad?= =?Windows-1252?Q?DIxO7hkiXsLVf6ITfmkZMJ1YczJldjqvfaRWGHoPu/XOhUi+d8Z8+VRl?= =?Windows-1252?Q?KBQwemd6uQT6Fq0Aa2tXWKRbQiUwqfkA3CkXw6xBUdO8YlAHXJ3Qa46b?= =?Windows-1252?Q?Rvfh46OIlMxowycCIOnEzGBq9eVEa5XenRJZdyF/KWLpOoqQiVfQ4Mhq?= =?Windows-1252?Q?tRXscp1beaFjetoCGDo9NQ=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL3PR11MB57310518116237785A1E116EBFB19BL3PR11MB5731namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL3PR11MB5731.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d812c3cf-6063-4071-c518-08d989cfc3fc X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2021 20:19:28.7152 (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: Hek8DqlKqGlxspITDtSorJYtMPTpzioc6jM9fTuMxiI+kO4Ye51Q4XL3/wqP8/vSVf9L4F5THvj9r9De+spz4A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3837 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.21, xbe-rcd-006.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 07 Oct 2021 20:20:11 -0000 --_000_BL3PR11MB57310518116237785A1E116EBFB19BL3PR11MB5731namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Chairs, WG, Network programming model [RFC8986] defines multiple flavors of End, End.X,= and End.T SIDs. CSID draft builds on it with next and replace flavors for = these SIDs. The draft reports multivendor interop was done to show co-exist= ence of next and replace flavors. This is evidence that these flavors work = seamless using SRH based single data plane. I strongly support the adoption call. Thanks, Rakesh Da: spring James Guichard Inviato: venerd=EC 1 ottobre 2021 16:05 A: SPRING WG Cc: spring-chairs@ietf.org Oggetto: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a =93living=94 document; it may change as it goes thr= ough review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_BL3PR11MB57310518116237785A1E116EBFB19BL3PR11MB5731namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi Chair= s, WG,

&nb= sp;

Network = programming model [RFC8986] defines multiple flavors of End, End.X, and End= .T SIDs. CSID draft builds on it with next and replace flavors for these SI= Ds. The draft reports multivendor interop was done to show co-existence of next and replace flavors. This is evidenc= e that these flavors work seamless using SRH based single data plane.

 

I strongly support the adoption call.<= span style=3D"font-family:"Helvetica Neue Light";color:#0F0F0F"><= o:p>

 

Thanks,

Rakesh

 

 

Da: spring <spring-bounces@ietf.org> James Guichard
Inviato: venerd=EC 1 ottobre 2021 16:05
A: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org
Oggetto: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

 

Dear WG:

 

The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a sol= ution for SRv6 compression.

 

The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document = that has multiple SRv6 Endpoint behaviors.
  2. The document is a =93livi= ng=94 document; it may change as it goes through review and analysis by the= SPRING working group.
  3. All open discussion point= s raised on our mailing list MUST be addressed BEFORE said document is allo= wed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maint= ained by the document editor in conjunction with the chairs.
  4. If this document is adopt= ed by the working group, the chairs specify as part of the adoption call th= at the following text describing an open issue be added to the document in the above-described open issues section:
    • "Given that the working group has said that it wants to standar= dize one data plane solution, and given that the document contains multiple= SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution obj= ective.".

 

Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open d= iscussion points you would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

--_000_BL3PR11MB57310518116237785A1E116EBFB19BL3PR11MB5731namp_-- From nobody Thu Oct 7 14:02:12 2021 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 5274F3A090D; Thu, 7 Oct 2021 14:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 y8ABjNG1ILiU; Thu, 7 Oct 2021 14:02:04 -0700 (PDT) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 1299E3A0922; Thu, 7 Oct 2021 14:02:04 -0700 (PDT) Received: by mail-pf1-x42c.google.com with SMTP id m14so6362922pfc.9; Thu, 07 Oct 2021 14:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=sNy+eXomIBjyaAbCpMN/F9T757ss3uQKiMhU/bltWKQ=; b=iZM+uqLqtiqJyJJLZjGOT5BkXP8hNXED+MmO0P+6WWqQW3XxW4zrdcD9wk8kDY5RAc XrE2XAGUCnnIcksb7AtQ1bcBDmOdc+mqBdTyByTzYpo5rzZz1SVSNBe8ve4jJYTAaDwl n1zU0I1wLLTd2HHphDe9SSQ9s6eXd6iP4DJJPnW4Pqkt/MEe51GGXljMNMSdcl9oEF5b QJjizvYT3F7JK6optZZs3TPofUn4lsn2rR/YRa6gVU6/WFoijW8npv9703Xw7drBvSKM QiZe/lH1OFiLvL3PdRoikksl/XP+BURKJV3Z9O21IQ9ez2ALdLSGvbWViTg4YytDo1mt tV2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sNy+eXomIBjyaAbCpMN/F9T757ss3uQKiMhU/bltWKQ=; b=yhoc65aAG00TGggMAtBPC2iVwaComzn9S8h1micw6OS5nPfysacdS1qgX+ZX84jrct e9c1i7jlQ3M1E8rqnvJTl3lqLwRUNGC4cAREv5wOKxQPM5TmSkVXvZQfGfcuHGIgIyzt w0/Q1ur30YB+EUUIMVam/y0iwh1rRWjg6HQtZmzQxTvxM/ssASd7fv7oMfNeDC3Boxkp V3FMS0fe0ifidU7excgJlEcBKrQhiRL1WCVg87H+tWStctPiycWeBsIM4hKIlU41+QtK gW827s9V5QRBD5Uw021BxS8IowCto396p9uhAm3ijGIHg9OiJz5PHuV+KZz5seAer7m7 gd4A== X-Gm-Message-State: AOAM532POQRKtRbDi3vXKuCxxHHNTb8X3HTkhiQkF5WCdAYVRa7xpX1+ DH1t38yGR+MORBtljzgT6Pltc9io/f0= X-Google-Smtp-Source: ABdhPJwIaqM/5+isJkmSxV+cQj9wiSl6AY6ExXA7JC6DD2G+gMlGw5YDQJKmmvbMMQ++dIBF0YaPcg== X-Received: by 2002:a63:ff11:: with SMTP id k17mr1396587pgi.405.1633640523215; Thu, 07 Oct 2021 14:02:03 -0700 (PDT) Received: from ?IPv6:2406:e003:1018:b901:db7:d041:a2d:ce65? ([2406:e003:1018:b901:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id w7sm297895pfj.189.2021.10.07.14.02.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 07 Oct 2021 14:02:02 -0700 (PDT) To: Robert Raszuk , Nick Hilliard Cc: Ron Bonica , SPRING WG , "6man@ietf.org" <6man@ietf.org> References: <86741e64-eef2-6395-afd7-62764d9f5c41@foobar.org> From: Brian E Carpenter Message-ID: <07dbf672-7586-c80d-0091-0fe3f9ec922b@gmail.com> Date: Fri, 8 Oct 2021 10:01:58 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 07 Oct 2021 21:02:11 -0000 I'm less interested in the definition of an "interface" than I am in the = bits in an Interface Identifier (i.e. the bottom 64 bits of an address). There is a formal update of the addressing architecture on this very poin= t. https://www.rfc-editor.org/rfc/rfc7136.html#section-5 says: ...the method of generating IIDs for specific link types MAY define some local significance for certain bits. In all cases, the bits in an IID have no generic semantics; in other words, they have opaque values. In fact, the whole IID value MUST be viewed as an opaque bit string by third parties, except possibly in the local context. Note the references to "local". If all hosts on a link agree about some magic semantics in the IID, and even agree to call the whole address a SID, it's consistent with the addressing architecture *as long as it stays local*. And don't mess with the semantics of the top 64 bits. Regards Brian Carpenter On 07-Oct-21 23:32, Robert Raszuk wrote: > Nick, >=20 > Ok let's zoom on your point.=C2=A0 >=20 > *IPv6=C2=A0=C2=A0Addressing Architecture RFC says:=C2=A0* >=20 > IPv6 addresses are 128-bit identifiers for interfaces and sets of > =C2=A0 =C2=A0interfaces (where "interface" is as defined in Section 2 o= f [IPV6]). > =C2=A0 =C2=A0There are three types of addresses: >=20 > =C2=A0 =C2=A0 Unicast: =C2=A0 An identifier for a single interface.=C2=A0=20 A packet sent to a > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0unicast address = is delivered to the interface identified > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0by that address.= >=20 > So what is left to check is what the definition of the "interface" is.=C2= =A0 >=20 > Some folks refer to the definition of the interface as stated=C2=A0verb= atim in *RFC2460/RFC8200:=C2=A0* >=20 > 2.=C2=A0 Terminology >=20 > =C2=A0 =C2=A0interface =C2=A0 - a node's attachment to a link. >=20 > _However we all know that outside of IPv6, SRv6 there are many more typ= es of interfaces which are not attached to any link. We use them every da= y.=C2=A0_ >=20 > *RFC7223* did decent job trying to capture what the interface means and=20 divided the interfaces into system defined and user defined:=C2=A0 >=20 > 1.1.=C2=A0 Terminology >=20 > =C2=A0 =C2=A0The following terms are used within this document: >=20 > =C2=A0 =C2=A0o =C2=A0system-controlled interface: An interface is said = to be system- > =C2=A0 =C2=A0 =C2=A0 controlled if the system creates and deletes the i= nterface > =C2=A0 =C2=A0 =C2=A0 independently of what has been explicitly configur= ed.=C2=A0 Examples > =C2=A0 =C2=A0 =C2=A0 are interfaces representing physical hardware that=20 appear and > =C2=A0 =C2=A0 =C2=A0 disappear when hardware (e.g., a line card or hot-= pluggable > =C2=A0 =C2=A0 =C2=A0 wireless interface) is added or removed.=C2=A0 Sys= tem-controlled > =C2=A0 =C2=A0 =C2=A0 interfaces may also appear if a certain functional= ity is enabled > =C2=A0 =C2=A0 =C2=A0 (e.g., a loopback interface might appear if the IP=20 protocol stack > =C2=A0 =C2=A0 =C2=A0 is enabled). >=20 > =C2=A0 =C2=A0o =C2=A0user-controlled interface: An interface is said to=20 be user- > =C2=A0 =C2=A0 =C2=A0 controlled if the creation of the interface is con= trolled by > =C2=A0 =C2=A0 =C2=A0 adding explicit interface configuration to the run= ning > =C2=A0 =C2=A0 =C2=A0 configuration datastore and the removal of the int= erface is > =C2=A0 =C2=A0 =C2=A0 controlled by removing explicit interface configur= ation from the > =C2=A0 =C2=A0 =C2=A0 running configuration datastore.=C2=A0 Examples ar= e VLAN interfaces > =C2=A0 =C2=A0 =C2=A0 configured on a system-controlled Ethernet interfa= ce. >=20 >=20 > So please let's consider reality here, not some badly defined=C2=A0dogm= as=C2=A0from the stone age.=C2=A0 >=20 > And if we will, then the SRv6 destination address is the address of a s= pecial virtual interface in the system. The meaning of the bits outside o= f the routable prefix is up to the interface creator.=C2=A0 >=20 > If that single sentence is missing in any spec it can be added but to m= e this is obvious.=C2=A0 >=20 > Cheers, > R. >=20 >=20 > On Thu, Oct 7, 2021 at 12:14 PM Nick Hilliard > wrote: >=20 > Eduard Metz wrote on 07/10/2021 10:03: > > For my understanding, apart from that the (definition of) SID may=20 not be > > aligned with the literal text in below RFCs, what is the real pro= blem? >=20 > the concept of an ipv6 destination address is deeply ingrained in t= he > ipv6 protocol.=C2=A0 So, looking at this from a deployment point of=20 view, why > does an expediency of the sort suggested in this draft justify chan= ging > the semantics of one of the cornerstones of the ipv6 protocol? >=20 > The authors would need to justify this protocol modification on the=20 same > sort of basis that any other ID might be expected to do.=C2=A0 E.g.=20 for > starters, including an analysis of how this would impact or potenti= ally > impact any other RFC which references or implicitly depends on > currently-defined ipv6 addressing semantics. >=20 > Nick >=20 > -------------------------------------------------------------------= - > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6=20 > -------------------------------------------------------------------= - >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Thu Oct 7 21:04:51 2021 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 0F62C3A0779; Thu, 7 Oct 2021 21:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eoa6nZGR56C6; Thu, 7 Oct 2021 21:04:44 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 D3F553A0778; Thu, 7 Oct 2021 21:04:44 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id 5so9166926iov.9; Thu, 07 Oct 2021 21:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=IjX7Tgje+Pf0ESpMGG5e+Z8f7EWfCVA4srWzOTlphmM=; b=HOtjdU0gMxg3vZGdaLVS+h4APU542d6h8OT/dMP4gpjm1hg6VBssbSVyUAECgp7fsZ UyoZkAK0jVBdVkVVdyJmV5IisxdSQ7UxBw2bSD8kNJNwOzmdHMxXlf35s3KU3TkiQU+F WPK9BWK8Bx031aApYe8kH1P0JPePLXyqSzhDBGHJFNm+jn60r0ncYj5MWBOvC5EeKN4f avhghB8LNnOmabyiZVKtd6vyJzzHy6d0lIkXTU1pbjUxd1W6HC58DOOGKTh3dNzFEKVF qYxKTgJf13TecPeUwNs8aNRTFbRv6PVOeSbdPwzbQJYqTFHByYoOpfurKysZyDTJszaC Ozog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=IjX7Tgje+Pf0ESpMGG5e+Z8f7EWfCVA4srWzOTlphmM=; b=iST1w6g1ZwrvPyir3KqtPhx2fjKejv1abX8lW+DuMJOEQY7cVGptxb+8OePoFpFjIx R0q9x2WiON5wYPwKmtenyjAuqlBLZnGPZwO1tjxuF85VsBRuzz0u2jSiMnBegRSqE84r v+1nSTGejnTVptmEDQdwNyFAdHe7DlkpO+j0nzVtVYyjYUQ2W+wArf6INwvBUA2YI2CY LgPTBObmhvrq5qrO++LaJIZIDM82zsngM90X0+YoO1hhLoK9ec6NOyqaG05Mb/Hxd55u PZjXd2GXD1y7eA5xamT8oRbIBR2PBTXGyrDG94PX1GyLkbvTnew+BpoOKSeQLJHzp0nB zP+Q== X-Gm-Message-State: AOAM533T0ntU6EPJpcmpvqn8E+JA2rZbqPwS72X9PKsfRyPLICtbtk+w r0eXD6A5pQosyfi38G7rCLqyIAcOQqAQMg== X-Google-Smtp-Source: ABdhPJw+r23xM/2cUUJljFtMhcWWCgFsREf6fS/K3DMCbsFxRzEIBbXGlHN/bkwYXsddeJAr8W9tAg== X-Received: by 2002:a6b:8d8a:: with SMTP id p132mr1102794iod.96.1633665883930; Thu, 07 Oct 2021 21:04:43 -0700 (PDT) Received: from DM5PR1901MB2150.namprd19.prod.outlook.com ([2603:1036:4:9e::5]) by smtp.gmail.com with ESMTPSA id t5sm519611ilp.84.2021.10.07.21.04.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Oct 2021 21:04:43 -0700 (PDT) From: Tarek Saad To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQFKdpbc X-MS-Exchange-MessageSentRepresentingType: 1 Date: Fri, 8 Oct 2021 04:04:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_DM5PR1901MB21508833EA7E026658284A64FCB29DM5PR1901MB2150_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 08 Oct 2021 04:04:49 -0000 --_000_DM5PR1901MB21508833EA7E026658284A64FCB29DM5PR1901MB2150_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, I=92ve read this draft. It is proposing 2 different encodings schemes for c= ompressed sequence of SRv6 SIDs (and an optional behavior on border nodes).= . Although Section 4 makes a claim that different deployments usecase may dee= m one encoding scheme superior over the other, I could not glean in which c= ases a scheme would outperform the other and why? Or, why is the WG trying = to standardize both the two flavors -- keeping in mind the complex HW proce= dures evident by the proposed different pseudo codes in the draft. Also, are there concerns of misinterpreting (wrongfully decoding) a GSID se= quence for a C-SID-sequence (or vice-versa) for a received packet on border= nodes that may support both encoding flavors simultaneously? For these reasons, I think this it is still premature for this draft to be = adopted, and I oppose its adoption. Regards, Tarek From: spring on behalf of James Guichard Date: Friday, October 1, 2021 at 10:05 AM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a =93living=94 document; it may change as it goes thr= ough review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_DM5PR1901MB21508833EA7E026658284A64FCB29DM5PR1901MB2150_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hi all,<= /span>

 

I=92ve read this dr= aft. It is proposing 2 different encodings schemes for compressed sequence = of SRv6 SIDs (and an optional behavior on border nodes)..=

Although Section 4 = makes a claim that different deployments usecase may deem one encoding sche= me superior over the other, I could not glean in which cases a scheme would= outperform the other and why? Or, why is the WG trying to standardize both the two flavors -- keeping in mind th= e complex HW procedures evident by the proposed different pseudo codes in t= he draft.

 

Also, are there con= cerns of misinterpreting (wrongfully decoding) a GSID sequence for a C-SID-= sequence (or vice-versa) for a received packet on border nodes that may sup= port both encoding flavors simultaneously?

 

For these reasons, = I think this it is still premature for this draft to be adopted, and I oppo= se its adoption.

 

Regards,=

Tarek

 

 

From: spring <spring-b= ounces@ietf.org> on behalf of James Guichard <james.n.guichard@future= wei.com>
Date: Friday, October 1, 2021 at 10:05 AM
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:

 

The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a sol= ution for SRv6 compression.

 

The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document = that has multiple SRv6 Endpoint behaviors.
  2. The document is a =93livi= ng=94 document; it may change as it goes through review and analysis by the= SPRING working group.
  3. All open discussion point= s raised on our mailing list MUST be addressed BEFORE said document is allo= wed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maint= ained by the document editor in conjunction with the chairs.
  4. If this document is adopt= ed by the working group, the chairs specify as part of the adoption call th= at the following text describing an open issue be added to the document in the above-described open issues section:
    • "Given that the working group has said that it wants to standar= dize one data plane solution, and given that the document contains multiple= SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution obj= ective.".

 

Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open d= iscussion points you would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

--_000_DM5PR1901MB21508833EA7E026658284A64FCB29DM5PR1901MB2150_-- From nobody Fri Oct 8 01:00:56 2021 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 A4BCE3A1477; Fri, 8 Oct 2021 01:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fY3kxt9W6qtv; Fri, 8 Oct 2021 01:00:49 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (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 661FC3A1468; Fri, 8 Oct 2021 01:00:49 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id u18so35580326lfd.12; Fri, 08 Oct 2021 01:00:49 -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=sfGr3Nteo5JnJ2i4R5JOY6orTtaqhFxigpP6RE0N6Ko=; b=oAC5D3NVCn4D1LZR310XDwjK9A88P29Whr6m2ZiD9zg+Sl/v3/dugJSu1wfzaK+Y7k Q5kKyCd0IURZBLq/+Gufz7bRA+hCnETWzzn+lpokW0as9hnuE0UHXPYdFArgWa0JMtZZ hdahP0d6Qbm8nYzuZpJGSZPzNJ/7Fb8njzULsA15rd/D54LvGJJjIMrqXYxrmz4fwTT+ bshNKHlXbPaFB5kCnCuaGxMVOcJrP2IHJFBMjTitsQKohj4Pmt+fHDlFZiqUDzuoBdEF Ofv9yakpHB4nJghfG5cAgnZGQ0McVrNLwpTZkIXVjxx9uaBFM50CtFbLsJ27wlHWr5Ok kRPQ== 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=sfGr3Nteo5JnJ2i4R5JOY6orTtaqhFxigpP6RE0N6Ko=; b=Sj0DuG6aeXnK3WcSJbtnec8usMStJrUcTMGuk9gPp9Bpl37+m/v0RIhRWYq3MW7q99 XA7f8iZcJ6Jp5lTWThxlEPJBYNKwclEXwww8F3h7+gRiRNTazALJ58MDctBZm5wc+IBR rVZukfB7iy8S+RIxrTvouPGhHdwBhOYK9SxKUZANrnvpZ/tawYCa0QvOFZtPjKbjgegq htKmIkM5SX18ZEg6IimrRzNp0mheMJkUgFeH7uAc44XSETedJdo6XHZF6trf65Xlzl6Z eqsWQWfe2R1ZDL+g8Dky17p9Pp3o3ti1/DKm39xt0WSgbKlsydHKHYtmzt8ALx6arxS0 U0jg== X-Gm-Message-State: AOAM531Sh758etWpzHGtGDSbPrNxKKv601Ix/w5EWFftnL0xot5RIvB3 aatEhLldqGUXpY/dc73DbCo713JtXGWTklHnEZU= X-Google-Smtp-Source: ABdhPJwHJircI+YCx2FUPKXX6aQSyvZaSHzwlHGSx059ibrJD3CxntZO+3RnQ1jdalJcxvySS9nZzTQGe2+qQRszHjk= X-Received: by 2002:a05:651c:38b:: with SMTP id e11mr1958130ljp.385.1633680047212; Fri, 08 Oct 2021 01:00:47 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Eduard Metz Date: Fri, 8 Oct 2021 10:00:36 +0200 Message-ID: To: Ron Bonica Cc: "6man@ietf.org" <6man@ietf.org>, SPRING WG Content-Type: multipart/alternative; boundary="000000000000e40da005cdd2c6ea" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 08 Oct 2021 08:00:54 -0000 --000000000000e40da005cdd2c6ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable If it helps in clarifying updating the definitions may be in order. Anyway it seems more logical that an (IP) interface is defined by its address than the other way around. But I do not know the original intention of the text. I'm not sure I understand your point regarding many functions on many nodes. Isn't that the case only in combination with the SRv6 functions that are applied the 128-bit entity? And even then it only points to one function on one node at a time? cheers, Eduard On Thu, Oct 7, 2021 at 9:35 PM Ron Bonica wrote: > > > Inline [RB] > > > > Ron > > > > > > Juniper Business Use Only > > *From:* Eduard Metz > *Sent:* Thursday, October 7, 2021 5:03 AM > *To:* Ron Bonica > *Cc:* 6man@ietf.org; SPRING WG > *Subject:* Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-0= 2 > > > > *[External Email. Be cautious of content]* > > > > > > Can the SID be viewed as the address of the "interface" to, in this case, > the function that resides in a node? From a routing / forwarding point of > view the group of functions is more similar to a network (represented by = a > prefix, rather than a single address), but still. > > > > [RB] In RFC 8986, a classic SRv6 SID represents a **single** function > that resides on a **single** node. If you like, you can even say that > represents a **single** interface to a **single** function that resides > on a **single** node. > > > > By contrast, a Compressed SID Container (i.e., the 128-bit entity that is > copied into the IPv6 Destination Address field) represents an entire SR > Path. Specifically, it represents **many** functions that reside on * > *many** nodes > > > > > > For my understanding, apart from that the (definition of) SID may not be > aligned with the literal text in below RFCs, what is the real problem? Ar= e > there any protocols that specifically rely on this definition of an IPv6 > address? > > > > [RB] We don=E2=80=99t know if there are any protocols that rely on this d= efinition > of the IPv6 address. And if we don=E2=80=99t update RFC 4291 before viola= ting it, > we don=E2=80=99t know if anybody might write such an application in the f= uture. > > > > > Ron > > > > > > cheers, > > Eduard > > > > > > --000000000000e40da005cdd2c6ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

If it helps in clarifying updating the definition= s may be in order. Anyway it seems more logical that an (IP) interface is d= efined by its address than the other way=C2=A0around. But I do not know the= original intention of the text.

I'm not sure = I understand your point regarding many functions on many nodes. Isn't t= hat the case only in combination with the SRv6 functions that are applied t= he 128-bit entity? And even then it only points to one function on one node= at a time?

cheers,
=C2=A0 Eduard
<= div>

On Thu, Oct 7, 2021 at 9:35 PM Ron Bonica <rbonica@juniper.net> wrote:

=C2=A0<= /span>

Inline [RB]=

=C2=A0<= /span>

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ron

=C2=A0<= /span>

=C2=A0

Juniper Business Use Only<= u>

From: Eduard Metz <etmetz@gmail.com>
Sent: Thursday, October 7, 2021 5:03 AM
To: Ron Bonica <rbonica@juniper.net>
Cc: 6man@ietf.org= ; SPRING WG <sp= ring@ietf.org>
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compressio= n-02

=C2=A0

[External Email. Be cautious of content]

=C2=A0

=C2=A0

Can the SID be viewed as the address of the "in= terface" to, in this case, the function that resides in a node? From a= routing / forwarding point=C2=A0of view the group of functions is more sim= ilar to a network (represented by a prefix, rather than a single address), but still.

=C2=A0<= /span>

[RB] In RFC 8986, a c= lassic SRv6 SID represents a *single* function that resides on a *single* node. If you like, you can even say that represents a *sing= le* interface to a *single* function that resides on a *single* node.

=C2=A0<= /span>

By contrast, a Compre= ssed SID Container (i.e., the 128-bit entity that is copied into the IPv6 D= estination Address field) represents an entire SR Path. Specifically, it re= presents *many* functions that reside on *many* nodes

=C2=A0<= /span>

=C2=A0

For my understanding, apart from that the (definitio= n of) SID may not be aligned with the literal text in below RFCs, what is t= he real problem? Are there any protocols that specifically rely on this def= inition of an IPv6 address?

=C2=A0<= /span>

[RB] We don=E2=80=99t= know if there are any protocols that rely on this definition of the IPv6 a= ddress. And if we don=E2=80=99t update RFC 4291 before violating it, we don= =E2=80=99t know if anybody might write such an application in the future.

=C2=A0<= /span>

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ron

=C2=A0<= /span>

=C2=A0

cheers,

=C2=A0 Eduard

=C2=A0

=C2=A0

--000000000000e40da005cdd2c6ea-- From nobody Fri Oct 8 01:38:16 2021 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 16E923A1514; Fri, 8 Oct 2021 01:37:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbM6Xr9Y4XjE; Fri, 8 Oct 2021 01:37:47 -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 D07DE3A1510; Fri, 8 Oct 2021 01:37:46 -0700 (PDT) Received: from fraeml711-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HQhLQ58w6z67ssM; Fri, 8 Oct 2021 16:34:06 +0800 (CST) Received: from mscpeml500001.china.huawei.com (7.188.26.142) by fraeml711-chm.china.huawei.com (10.206.15.60) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Fri, 8 Oct 2021 10:37:42 +0200 Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml500001.china.huawei.com (7.188.26.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Fri, 8 Oct 2021 11:37:41 +0300 Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2308.008; Fri, 8 Oct 2021 11:37:41 +0300 From: Vasilenko Eduard To: Ron Bonica , Eduard Metz CC: SPRING WG , "6man@ietf.org" <6man@ietf.org> Thread-Topic: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 Thread-Index: Ade3AXyWK2NzAamgSlCvJ497z/5RLwC/aCkQAFB7QYAAFhVaAAAhiEzQ Date: Fri, 8 Oct 2021 08:37:41 +0000 Message-ID: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.205.228] Content-Type: multipart/alternative; boundary="_000_8d9d962c7c9d4130bdf7030ee09b5d09huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 08 Oct 2021 08:37:53 -0000 --_000_8d9d962c7c9d4130bdf7030ee09b5d09huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable ? By contrast, a Compressed SID Container (i.e., the 128-bit entity that is= copied into the IPv6 Destination Address field) represents an entire SR Pa= th. Specifically, it represents *many* functions that reside on *many* node= s But CSID is not an IP address, right? Why IP address rules should be applic= able to CSID? From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ron Bonica Sent: Thursday, October 7, 2021 10:36 PM To: Eduard Metz Cc: SPRING WG ; 6man@ietf.org Subject: RE: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 Inline [RB] Ron Juniper Business Use Only From: Eduard Metz > Sent: Thursday, October 7, 2021 5:03 AM To: Ron Bonica > Cc: 6man@ietf.org; SPRING WG > Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 [External Email. Be cautious of content] Can the SID be viewed as the address of the "interface" to, in this case, t= he function that resides in a node? From a routing / forwarding point of vi= ew the group of functions is more similar to a network (represented by a pr= efix, rather than a single address), but still. [RB] In RFC 8986, a classic SRv6 SID represents a *single* function that re= sides on a *single* node. If you like, you can even say that represents a *= single* interface to a *single* function that resides on a *single* node. By contrast, a Compressed SID Container (i.e., the 128-bit entity that is c= opied into the IPv6 Destination Address field) represents an entire SR Path= . Specifically, it represents *many* functions that reside on *many* nodes For my understanding, apart from that the (definition of) SID may not be al= igned with the literal text in below RFCs, what is the real problem? Are th= ere any protocols that specifically rely on this definition of an IPv6 addr= ess? [RB] We don't know if there are any protocols that rely on this definition = of the IPv6 address. And if we don't update RFC 4291 before violating it, w= e don't know if anybody might write such an application in the future. = Ron cheers, Eduard --_000_8d9d962c7c9d4130bdf7030ee09b5d09huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ø By contrast= , a Compressed SID Container (i.e., the 128-bit entity that is copied into = the IPv6 Destination Address field) represents an entire SR Path. Specifica= lly, it represents *many* functions that reside on *many* nodes

 

But CSID is not an IP = address, right? Why IP address rules should be applicable to CSID?

 

From: ipv6 [mailto:ipv6-bounces@ietf.org] = On Behalf Of Ron Bonica
Sent: Thursday, October 7, 2021 10:36 PM
To: Eduard Metz <etmetz@gmail.com>
Cc: SPRING WG <spring@ietf.org>; 6man@ietf.org
Subject: RE: [spring] draft-filsfilscheng-spring-srv6-srh-compressio= n-02

 

 

Inline [RB]

 

   &= nbsp;       Ron

 

 

Juniper Business Use Only

From: Eduard Metz <etmetz@gmail.com>
Sent: Thursday, October 7, 2021 5:03 AM
To: Ron Bonica <rbonica@ju= niper.net>
Cc: 6man@ietf.org; SPRING WG &l= t;spring@ietf.org>
Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compressio= n-02

 

<= span style=3D"font-size:10.5pt;font-family:Lato;color:black">[External Emai= l. Be cautious of content]

 

 

Can the SID be viewed as the address of the "in= terface" to, in this case, the function that resides in a node? From a= routing / forwarding point of view the group of functions is more sim= ilar to a network (represented by a prefix, rather than a single address), but still.

 

[RB] In RFC 8986, a= classic SRv6 SID represents a *single* function that resides on a *= single* node. If you like, you can even say that represents a *si= ngle* interface to a *single* function that resides on a *single* node.

 

By contrast, a Comp= ressed SID Container (i.e., the 128-bit entity that is copied into the IPv6= Destination Address field) represents an entire SR Path. Specifically, it = represents *many* functions that reside on *many* nodes

 

 

For my understanding, apart from that the (definitio= n of) SID may not be aligned with the literal text in below RFCs, what is t= he real problem? Are there any protocols that specifically rely on this def= inition of an IPv6 address?

 

[RB] We don’t= know if there are any protocols that rely on this definition of the IPv6 a= ddress. And if we don’t update RFC 4291 before violating it, we don&#= 8217;t know if anybody might write such an application in the future.

 

   &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;        Ron

 

 

cheers,

  Eduard

 

 

--_000_8d9d962c7c9d4130bdf7030ee09b5d09huaweicom_-- From nobody Fri Oct 8 02:00:14 2021 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 7A1013A15AF; Fri, 8 Oct 2021 02:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=ETZ5ecym; dkim=pass (1024-bit key) header.d=juniper.net header.b=k+LwFBfI 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 8bUfLTnhwsFz; Fri, 8 Oct 2021 02:00:07 -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 BA1573A15B0; Fri, 8 Oct 2021 02:00:07 -0700 (PDT) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1988kKBQ004117; Fri, 8 Oct 2021 02:00:04 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=gUbUD7NNufuhUOSX/LcvdKUNNPaOqe5WEYVpv24LUIk=; b=ETZ5ecympmpilzyd+TM6PUKGg7F2/DEbRss1574TF38y+tEPXkVXiV7vARssX34m1i4W ZaohsalYBXWpYSLJid4/fq75i8lo5EolOxm5IzB/MUbt4Zk9PGgSZvBhOYuGBL8RxOmQ xwCQd4h0DcBGLjIhrcE798X6dk76MrfINxftpx6jw+umlFAKn75k7z46izz5Do81Zt1e BkBvcxmh/+ujXQ36JGJ0SCG+kOkpYPLqp8Z+upAZxfu8nqspLSRCWPGxOXBAhyFjd0ei tReoy/zol4aJPEileYvhoVAWOnLr0gzPwifBTQTikV7eOuJc1TXkV5s7f3gtd7M5GsVo KQ== Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2100.outbound.protection.outlook.com [104.47.55.100]) by mx0a-00273201.pphosted.com with ESMTP id 3bjjry00mf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 08 Oct 2021 01:59:56 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=A7inEruuTbQhe7C3RnIKfPwWXwweUdYryHx5UEoFhPBw1sXRNj89oAeYiOrwafOL6gcmFc7Twy+zXGkX1X1S5i6npXfssHc8EFb3AuK31hK9cSN2K+yNnJwrrwHdI1wdLfcOegMPm48x55V4AiLdAdz7GyfsRf8HGJfvztMn/GdUCZulhZs+zbJyljtAHxqwzQ5Y7QF8NFvhgdBVtk9N87qs9hgfb3KrRGKioEOVKlEfiVlmkh5jb0Fns2TgbZ+9gIcNbvYvW7W6+VPIfEP/rIT42WqHxInHzHGwd9GZzg3G+Ywuxi2puRZtntwVArlWHu92Fzzm9peOLoOUBuiLmg== 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=gUbUD7NNufuhUOSX/LcvdKUNNPaOqe5WEYVpv24LUIk=; b=DXIklKCkv5d5q4F4vDZwaHh5sBwWnMiLgbYVu7xPSor/SZt+pcMhKF9k/k1V2aQqhP2hsZ2nolt4WmlyXQM0moxPWjis4FZ+PqTjs9VoTaHbOqeINDl9Fb9oIpEaw9eNcA6wSw0jujIbWrZ0AP0/X3x1RwhQVW+X6gK7hj9KYrvuraYVQ8rYG+QJlIqg5urLf5CX3FhLTI1X4yqchaO1vsgLGbZuvROvXwROCz4X2gh8rsWcH0ccsta3oaT4s+OY5+ORM6dE3q9YOBb15lAuXNRUa/HrDgRSFGkOK6TNEnGWH4imW6yfrQfAXMhKpAgDT3iHMbTg0XdT9ihQ0GwTxA== 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=gUbUD7NNufuhUOSX/LcvdKUNNPaOqe5WEYVpv24LUIk=; b=k+LwFBfI6JcSDszzkMWiXs5L3VIrCIADTi48k9WJA0cvZcHNQF/Yf1rjGV/45seHzQra3tfqJCwV5fgYTE/CPkKz/d05U7agsjpOI7DF5DGAEsJ9SGCgxFitGhILR5Qhp0AlamJv38+8MjtT76y5ISOImO06M60OWVeUTDGYfrg= Received: from PH0PR05MB7749.namprd05.prod.outlook.com (2603:10b6:510:2e::7) by PH0PR05MB7621.namprd05.prod.outlook.com (2603:10b6:510:20::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.15; Fri, 8 Oct 2021 08:59:55 +0000 Received: from PH0PR05MB7749.namprd05.prod.outlook.com ([fe80::2497:be95:715f:3b36]) by PH0PR05MB7749.namprd05.prod.outlook.com ([fe80::2497:be95:715f:3b36%5]) with mapi id 15.20.4587.018; Fri, 8 Oct 2021 08:59:55 +0000 From: Srihari Sangli To: Ron Bonica , James Guichard , "EXT-Andrew.Alston@liquidtelecom.com" , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-rv6-srh-compression/ Thread-Index: AQHXvCLcFjBOSPtP3Uqb6PG1Qhhcjw== Date: Fri, 8 Oct 2021 08:59:54 +0000 Message-ID: <4473DFC2-8CE5-4FAD-BDC9-15883F1F1AA6@juniper.net> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-05T18:56:07Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=cb540479-0624-482f-bde4-680b11adf467; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 user-agent: Microsoft-MacOutlook/16.53.21091200 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0df91953-a3aa-4bbf-4b45-08d98a39ff66 x-ms-traffictypediagnostic: PH0PR05MB7621: x-ld-processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wSnpYr+nbuT8+YyChxKbIEtRWvTIpydaJRFBAv3mJsAry9omH/iDKCXWAK26GqDjyDkYC8yxBNE6JXFwKX33zSxcusoL3iVDSrVDCL05zTHywCMmv24cE6QT8JJDiPHQAm1yJARUuoD5XZAdoMz1mqn4DVF3Vwtjo10LKY8pwBS/YjgIF3PIVmPGMG2wIN1taZNbAyMa70Zn/L4Oo4NhkcjBF51KbnJQBlP1xaWtaVUBWIbLNLavpod2AM/0GsEgyKrt6X3u7AColGCC9CRjqYiIxE2AAcUI4FCGZEThMgrjjZUTTmDzaxa+uXZSvzyLLg4P/NzGK6VzamDXUe41KWXYOCc1QEGMtGz/NDU9wS5wsse9SYqIoYnO8U3L6J400ovKkfZx7aA7XwBEREIzitu5QiqkRm/FmG94rZkXxGapFZVX1qqCDND3QKMnqmfbeyAMP4w0VrySZiwr6pI/xVlf91G2hpmmIIDFrn0Lagcqqwe57G5dtv5L4pQlF9Jp8qm3ekzCV8j8k3iC7ATl9880e008viBtXW4iwly27/B0CasB3iizCCMV23bJInMn+nb6RSPYbL3BG5ljYFDNXCRFoYmL7WOxZ69mr9nngN0r1JvNnSFuE7qc3/S1md6jdVuXwpY1UWhULh6evo8PAml8PlCjgZ6qZev9SeBC+SXoCOS4mwsVGJ2AxHTdM5zwHjudVp0MfIK5wtz4ewqPBshVTjnRr1ZOthj6xpNkuLdjoXPrM+ndnRDIYjpIYFZhfuCt5NC8CT3DntAIQzNxjWm3VXnSHbMuuQPiGSQU6c3DllWwsKK/CuVoT/BfvoQoZlnQIb4qUWPr+hHBvVVjdlWSQRnM9/HJJWqAb2cLr4rGMKOxkUPjcOntj+uhp+qg x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR05MB7749.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(4326008)(36756003)(91956017)(76116006)(316002)(33656002)(2906002)(5660300002)(83380400001)(71200400001)(66476007)(53546011)(66446008)(166002)(38100700002)(64756008)(66946007)(66556008)(8676002)(122000001)(6506007)(86362001)(38070700005)(2616005)(966005)(186003)(6486002)(6512007)(110136005)(26005)(508600001)(8936002)(45980500001)(491001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?czRvVSttSTRuTHBCMVJqeFp3clM0dy9QRTFXaHhYVitTcFkxY2YrSEczdkVt?= =?utf-8?B?dnlQR21NdDMzTXFFb0h2R1M4WHY4dFNIalZxK0h4U1VBaDZqZ0thbHB3azhq?= =?utf-8?B?eTVWTmE3WE1KakF2SU8yUno5R3kwVGRJMWl6M1pRUERWS0pkaUx0NDNKeDNJ?= =?utf-8?B?cSt4TVlLTFgwOVNFZElsUHV5MndVOGM2c3FRbWJBQ3I2OU50ZTVRMlcybmlQ?= =?utf-8?B?Q2duOVBSVDRHOFJ2aERtUDVFU3Zqb0tJK2RqWHM2REtORnlmaHlwWjg4QllM?= =?utf-8?B?ZHNCTm1lZ1Z3U01pS3MwWk1pQUlwYXMwYnpLSXcwUDJiUTBoUjdJNlZEeEVP?= =?utf-8?B?YU8vVENtRU9zSCtXZG0wb0xlcVZwbGxBQ1lUYVdFZXBhTHVlOG1Yc1hMd1BL?= =?utf-8?B?R2U3OHk2U0VEcmdPZi82amZxV3kvYm9mV2VicU1TWHY4T3B6WFMrQVdETTBy?= =?utf-8?B?SlRQamkrdERWb01CM3JKL3BaMjMxY0V2SldOdHlCZklUbG45SFdaS0thazkx?= =?utf-8?B?b2szd3RCTEg2SllPcWV3alRKMS9OcHZUQXhoN0FqR2hYa2FwWksvT3orRXhR?= =?utf-8?B?dVVWMWhTU2pqVWc2WjVrNlNwYUV5QXZBTnh2WFpqc3FKem1RTnlYRHJLN0tX?= =?utf-8?B?eFRacDlZSVBqVnRob1ZxTWkvbEx2MEtwcW8rcjNhY0ZsMDJLdUgvM2UzKzJp?= =?utf-8?B?MUhydHlNUU5UamdyRC9WQk8yNTFiMGFlakVyNjUrTkRyTjQxNXorWXk3Zjgx?= =?utf-8?B?MWZITFFSaExKMVVOOHFabTRuQVBSbTAreEd4WEJHT2lHRGF0bndCL3ZULzlo?= =?utf-8?B?aTJBREQxUks0MVhscm5uUHlrQVhvTGZYc3ZoSWUxRTMzN0wrRlhmV24wbWdk?= =?utf-8?B?MkFFUE02aHRsT3RWakxvZHlLL2F0azh1Z2E4M1V1TkJEUkJwM29IaDg2VTlo?= =?utf-8?B?ZEZ1Rlg1TDlBWWEwcFdPRzcyd3BRdVRybnNNeUtVdU9OYU5JTHFDbEtkcnhk?= =?utf-8?B?VnN6MzVwRCtFMFBOcTNHZklsM2RKeUQ1WU50TWp5dnVxd1BTSHB6MVlhOC9k?= =?utf-8?B?VFJWSTFGS2RYd2ljclo3OVFiSDZ3UjR2a2srbHFxbWdYZXBtTmZZQ25iYUVK?= =?utf-8?B?c2dGbXI5T3NqWUJiVGt2VHdhVU53ajVBL1BCNFJsL1VYUjgzMTBoeFZmTkU1?= =?utf-8?B?dFdzL05hckRwSnorL0FWRk5HT2d0QXZoZFZLRzJIKzg3QU9kZFZoRmlocmNl?= =?utf-8?B?cHRNaXVtNU14Zy9RVlpuUndiM050ODRJVjh6UThBMVlsNVBacEtDMmxSTks4?= =?utf-8?B?RU5RY0lqL3FsNnBkVmcwOEVLd0NoWGJGaHZuUUEyM3dNZGdudVVWbXE0clJ6?= =?utf-8?B?SUVjWllYdUlrakEzc2VxaStoV0h1b0krWlBVQlR2UGxjTDIwWXpJbkJvTXFr?= =?utf-8?B?NDFSeUVCQUJFa09EUTFobDg0REh0ejYraXdSME9RNEduTHdIeVFRSVlqUXR6?= =?utf-8?B?YzlCQm9VTENQU1lVVHhxRTFxTnl2VXpYaFRQL3ZpSDhHWEZjSWNvRThGQVRy?= =?utf-8?B?VWVWeC9DbWZCSXZBRGtxSnF1WUdOdHlWUUJncmdMRC9KeENlNmo1ZHZqTmg5?= =?utf-8?B?UDRNamV6UnBYay9heTI2bHZVdUZicHg0KzVRbEp6dHBtZXFMV0hidENVdyth?= =?utf-8?B?aXJzQVZsK1VReG5ocEZzU1RVdk9NclZkY2NYV2NHUnBHalVTdUNTbm9iV3Yx?= =?utf-8?B?eTgrcTV0c2NJeEpHWEVDU0VCcitGL0VsUzh1UkZsMSsrYjgrbE9oTW5uN2VR?= =?utf-8?B?aWM1VGsrMDlCSjdmQnJOUT09?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_4473DFC28CE54FADBDC915883F1F1AA6junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR05MB7749.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0df91953-a3aa-4bbf-4b45-08d98a39ff66 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2021 08:59:54.8684 (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: HvhFLd4Q5xJj9hA5MgOiT5qtFtx4d0I+M/Z0ForBK0yQ9qhFd6xXhbFcvUKeRvI2hXSeguyVXKBSJnsyYcwAuw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR05MB7621 X-Proofpoint-ORIG-GUID: jUWUtvL7S8MY8_4pDYO7IxmuPL-rHVVg X-Proofpoint-GUID: jUWUtvL7S8MY8_4pDYO7IxmuPL-rHVVg X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-08_02,2021-10-07_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 phishscore=0 mlxscore=0 malwarescore=0 bulkscore=0 suspectscore=0 spamscore=0 adultscore=0 mlxlogscore=999 impostorscore=0 clxscore=1011 priorityscore=1501 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110080053 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-rv6-srh-compression/ 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, 08 Oct 2021 09:00:13 -0000 --_000_4473DFC28CE54FADBDC915883F1F1AA6junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0Kc3JpaGFyaeKApg0KDQoNCk9uIDA2LzEwLzIxLCAxMjoyNiBBTSBzcHJpbmcgb24gYmVo YWxmIG9mIFJvbiBCb25pY2EgZnJvbSBzcHJpbmctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86c3By aW5nLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiByYm9uaWNhPTQwanVuaXBlci5uZXRA ZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOnJib25pY2E9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9y Zz4gc2FpZCA+DQoNCltFeHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF0NCg0K SmltLA0KDQpUaGUgY2FsbCBmb3IgYWRvcHRpb24gaGFzIGFscmVhZHkgYmVlbiBwb3N0ZWQuIFRo ZXJlIGlzIG5vIHdheSB0byBwdXQgdGhhdCB0b290aHBhc3RlIGJhY2sgaW50byBpdHMgdHViZS4g SG93ZXZlciwgSSBzdHJvbmdseSByZWNvbW1lbmQgYWdhaW5zdCBzdWNoIGNhbGxzIGZvciBhZG9w dGlvbiBpbiB0aGUgZnV0dXJlLg0KDQpOb3JtYWxseSwgdGhlIGF1dGhvcnMgb2YgYSBkb2N1bWVu dCBhcmUgZW5jb3VyYWdlZCB0byBhbnN3ZXIgdGVjaG5pY2FsIHF1ZXN0aW9ucyBhcyBhIGNvbmRp dGlvbiBvZiBhZG9wdGlvbi4gQnVsbGV0IHBvaW50cyAxLCAyLCBhbmQgNCBpbiB0aGUgY2FsbCBm b3IgYWRvcHRpb24gZGVmZXIgdGhhdCByZXF1aXJlbWVudCB1bnRpbCBXRyBsYXN0IGNhbGwuIENv dWxkIHRoaXMgYmUgd2h5IHRlY2huaWNhbCBxdWVzdGlvbnMgYXJlIG5vdCBiZWluZyBhZGRyZXNz ZWQgZHVyaW5nIHRoZSBjYWxsIGZvciBhZG9wdGlvbi4NCg0KSW4gc29tZSBleHRyZW1lIGNvbmRp dGlvbnMsIGl0IG1heSBiZSBuZWNlc3NhcnkgdG8gbW9kaWZ5IHRoZSB1c3VhbCBjYWxsIGZvciBh ZG9wdGlvbiBwcm9jZWR1cmUuIEJ1dCB0aGVzZSBleGNlcHRpb25hbCBjb25kaXRpb25zIGhhdmUg bm90IGJlZW4gYXJ0aWN1bGF0ZWQuDQoNCkl0IGlzIHVuZm9ydHVuYXRlIHRoYXQgdHdvIG9mIHRo ZSB0aHJlZSB3b3JraW5nIGdyb3VwIGNoYWlycyBhcmUgYWxzbyBjby1hdXRob3JzIG9mIHRoZSBk cmFmdC4gV2hpbGUgdGhlcmUgbWF5IG5vdCBoYXZlIGJlZW4gYW55IGltcHJvcHJpZXR5LCB0aGUg YXBwZWFyYW5jZSBvZiBpbXByb3ByaWV0eSBpcyBkaWZmaWN1bHQgdG8gYXZvaWQuDQoNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQoNCg0KDQoNCkp1bmlwZXIgQnVz aW5lc3MgVXNlIE9ubHkNCkZyb206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+IE9u IEJlaGFsZiBPZiBKYW1lcyBHdWljaGFyZA0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDQsIDIwMjEg MTE6MTAgQU0NClRvOiBFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSA8QW5kcmV3 LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT47IFNQUklORyBXRyA8c3ByaW5nQGlldGYub3JnPg0K Q2M6IHNwcmluZy1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBXRyBBZG9w dGlvbiBjYWxsIGZvciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxz Zmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8NCg0KW0V4dGVybmFsIEVtYWls LiBCZSBjYXV0aW91cyBvZiBjb250ZW50XQ0KDQpBbmRyZXcsDQoNCkFzIHN0YXRlZCBpbiBvdXIg ZW1haWwgb2YgU2VwdGVtYmVyIDl0aCwgdGhlIGNoYWlycyBjb21tdW5pY2F0ZWQgdGhhdCB0aGUg d29ya2luZyBncm91cCByZWFjaGVkIHJvdWdoIChxdWl0ZSBjbGVhcikgY29uc2Vuc3VzIGZvciBz dGFuZGFyZGl6aW5nIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uIHRvIGNvbXByZXNzIHNlZ21lbnQg cm91dGluZyBvdmVyIElQdjYuIEluIGFkZGl0aW9uIHRvIHRoaXMgdGhlcmUgd2FzIGFuIGluY2xp bmF0aW9uIHRvd2FyZCB1c2luZyB0aGUgQ1NJRCBkb2N1bWVudCBhcyB0aGUgYmFzaXMgZm9yIG91 ciB3b3JrIGluIHRoaXMgYXJlYS4gVGhlIGNoYWlycyByZWNvZ25pemVkIHRoYXQgdGhlcmUgd2Fz IGhvd2V2ZXIgZGlzYWdyZWVtZW50IGFzIHRvIHdoZXRoZXIgdGhpcyBkb2N1bWVudCwgaGF2aW5n IG11bHRpcGxlIFNSdjYgRW5kUG9pbnQgYmVoYXZpb3JzLCBjb3VsZCBiZSBjb25zaWRlcmVkIGNv bnNpc3RlbnQgd2l0aCB0aGUgd29ya2luZyBncm91cCBjb25zZW5zdXMgZm9yIGEgc2luZ2xlIGRh dGEgcGxhbmUgc29sdXRpb24uIFRoaXMgaXNzdWUgcXVpdGUgY2xlYXJseSBuZWVkZWQgdG8gYmUg YWRkcmVzc2VkLCBhbmQgdGhlIGNoYWlycywgcmVjb2duaXppbmcgdGhhdCB0aGUgd29ya2luZyBn cm91cCBpcyBrZWVuIHRvIG1ha2UgcHJvZ3Jlc3MgaW4gdGhpcyBhcmVhLCBoYWQgdGhlIG9wdGlv biBvZiB0cnlpbmcgdG8gcmVzb2x2ZSB0aGUgaXNzdWUgcHJpb3IgdG8gaXNzdWluZyBhbiBhZG9w dGlvbiBjYWxsLCBvciBnaXZlIHRoZSB3b3JraW5nIGdyb3VwIHRoZSBvcHBvcnR1bml0eSB0byBl eHByZXNzIHRoZWlyIG9waW5pb25zIGFzIHBhcnQgb2YgYSBjYWxsIGZvciBhZG9wdGlvbi4NCg0K VGhvc2Ugd2hvIGZlZWwgdGhhdCB3ZSBuZWVkIHRvIHJlc29sdmUgdGhlIGNvbnNpc3RlbmN5IGlz c3VlIGJlZm9yZSBhZG9wdGlvbiwgYXMgd2l0aCB0aG9zZSB3aG8gdGhpbmsgdGhpcyBpcyBub3Qg YSBnb29kIGJhc2lzIGZvciB0aGUgV0cgd29yaywgYXJlIGZyZWUgYW5kIGV4cGVjdGVkIHRvIG9i amVjdCB0byB0aGUgV0cgYWRvcHRpbmcgdGhlIGRvY3VtZW50LiBUaGF0IGlzIGRpc3RpbmN0IGZy b20gb2JqZWN0aW5nIHRvIHRoZSBjaGFpcnMgaXNzdWluZyB0aGUgYWRvcHRpb24gY2FsbC4NCg0K SW4gZXNzZW5jZSwgdGhlIGNoYWlycyBoYXZlIGNvbWJpbmVkIHRoZSBxdWVzdGlvbiBvZiB3aGVu IHRvIHJlc29sdmUgY29uc2lzdGVuY3kgYW5kIHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyIHRoaXMg ZG9jdW1lbnQgaXMgYSBnb29kIGJhc2lzIGZvciB0aGUgV0cgaW50byBvbmUgY2FsbC4NCg0KWW91 cnMsDQoNCkppbSwgQnJ1bm8gJiBKb2VsDQoNCg0KRnJvbTogQW5kcmV3IEFsc3RvbiA8QW5kcmV3 LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbTxtYWlsdG86QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxl Y29tLmNvbT4+DQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMSwgMjAyMSA0OjIxIFBNDQpUbzogSmFt ZXMgR3VpY2hhcmQgPGphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbTxtYWlsdG86amFtZXMu bi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPj47IFNQUklORyBXRyA8c3ByaW5nQGlldGYub3JnPG1h aWx0bzpzcHJpbmdAaWV0Zi5vcmc+Pg0KQ2M6IHNwcmluZy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRv OnNwcmluZy1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogV0cgQWRvcHRpb24gY2FsbCBm b3IgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1z cHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19o dHRwczovZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5n LXNydjYtc3JoLWNvbXByZXNzaW9uL19fOyEhTkV0NnlNYU8tZ2shV28yTDVZMU9WQUpiYnlEUFJa N2RXc290cUJoWS1MT05WOU5EVWNnNFNRNWJRNm5oOXlyWWJqdnhHcThJd3lNJD4NCg0KU29ycnkg 4oCTIGJ1dCDigJMgSeKAmW0gYSBsaXR0bGUgY29uZnVzZWQgaGVyZS4NCg0KQmVjYXVzZSB0aGUg d2F5IEkgbG9vayBhdCB0aGlzIOKAkyB0aGUgd29ya2luZyBncm91cCBjbGVhcmx5IHN0YXRlZCB0 aGF0IHRoZXkgd2lzaGVkIGZvciBhIHNpbmdsZSBiZWhhdmlvciDigJMgYW5kIHRoaXMg4oCTIGRv ZXMgbm90IGRlbGl2ZXIgdGhhdCDigJMgaXQgaXMgdHdvIHNlcGFyYXRlIGJlaGF2aW9ycy4gIEFz IHN1Y2gg4oCTIEkgc2VlIHRoaXMgY2FsbCBmb3IgYWRvcHRpb24g4oCTIGlycmVzcGVjdGl2ZSBv ZiB0aGUgbWVyaXRzIG9yIGxhY2sgdGhlcmVvZiBvZiB0aGUgZHJhZnQsIGFzIGEgY2xlYXIgZGVm aWFuY2Ugb2YgdGhlIHN0YXRlZCB3aWxsIG9mIHRoZSB3b3JraW5nIGdyb3VwLg0KDQpUaGlzIGlz IHNpbXBseSBkb2VzIG5vdCBmaXQgaW50byB0aGUgZGVmaW5pdGlvbiBvZiBib3R0b20gdXAgYXBw cm9hY2ggaW4gbXkgb3BpbmlvbiDigJMgYW5kIGlmIHRoaXMgaXMgdGhlIHdheSB0aGF0IHRoZSBj aGFpcnMgd2lzaCB0byBwcm9jZWVkIOKAkyB0aGVuIHRoZSBvbmx5IHdheSB0byBkbyB0aGF0IGFu ZCBzdGlsbCBmaXQgd2l0aGluIHRoZSBib3R0b20gdXAgYXBwcm9hY2ggaXMgdG8gZmlyc3QgYXNr IHRoaXMgd29ya2luZyBncm91cCBmb3IgaXRzIGNvbnNlbnN1cyB0byBkZXZpYXRlIGZyb20gdGhl IHNpbmdsZSBiZWhhY3Zpb3IgYXBwcm9hY2ggdGhhdCB0aGUgd29ya2luZyBncm91cCBhZ3JlZWQg dG8uDQoNCkFzIHN1Y2gg4oCTIEkgbXVzdCAgc3Ryb25nbHkgYW5kIHVuZXF1aXZvY2FsbHkgb2Jq ZWN0IHRvIHRoaXMgY2FsbCBmb3IgYWRvcHRpb24NCg0KQW5kcmV3DQoNCkZyb206IHNwcmluZyA8 c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPj4g b24gYmVoYWxmIG9mIEphbWVzIEd1aWNoYXJkIDxqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5j b208bWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbT4+DQpEYXRlOiBGcmlkYXks IDEgT2N0b2JlciAyMDIxIGF0IDE3OjA1DQpUbzogU1BSSU5HIFdHIDxzcHJpbmdAaWV0Zi5vcmc8 bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4+DQpDYzogc3ByaW5nLWNoYWlyc0BpZXRmLm9yZzxtYWls dG86c3ByaW5nLWNoYWlyc0BpZXRmLm9yZz4gPHNwcmluZy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRv OnNwcmluZy1jaGFpcnNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogW3NwcmluZ10gV0cgQWRvcHRpb24g Y2FsbCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNj aGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20v djMvX19odHRwczovZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmct c3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uL19fOyEhTkV0NnlNYU8tZ2shVWdIZkN1T08xaUxv c2FGUDJXaW13Wkcwd1pzOEs0TTIwN3dMMnM0WExqVkExN2NJd3RENk1FRWs0WTYzS3AwLSQ+DQpE ZWFyIFdHOg0KDQpUaGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gZXhwcmVzcyB0aGVpciBhcHByZWNp YXRpb24gZm9yIGFsbCB0aGUgcmVzcG9uc2VzIHJlY2VpdmVkIHRvIG91ciBlbWFpbHMgd2l0aCBy ZWZlcmVuY2UgdG8gaG93IHRoZSB3b3JraW5nIGdyb3VwIHdpc2hlcyB0byBtb3ZlIGZvcndhcmQg d2l0aCByZXNwZWN0IHRvIGEgc29sdXRpb24gZm9yIFNSdjYgY29tcHJlc3Npb24uDQoNClRoZSBh cHBhcmVudCBpbmNsaW5hdGlvbiBvZiB0aGUgd29ya2luZyBncm91cCBpcyB0byB1c2UgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2 Ni1zcmgtY29tcHJlc3Npb24vPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovbmFt MTEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyozQSoyRioyRmRh dGF0cmFja2VyLmlldGYub3JnKjJGZG9jKjJGZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2 Ni1zcmgtY29tcHJlc3Npb24qMkYmZGF0YT0wNCo3QzAxKjdDamFtZXMubi5ndWljaGFyZCo0MGZ1 dHVyZXdlaS5jb20qN0M1ZTBkMGZkYjg0NDA0YjUzNTE3MTA4ZDk4NTE5MDc1Zio3QzBmZWU4ZmYy YTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRjKjdDMSo3QzAqN0M2Mzc2ODcxNjQ4MTY0OTYwNTIqN0NV bmtub3duKjdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklp TENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wKjNEKjdDMTAwMCZzZGF0YT0qMkJWc0w5KjJCSGd5 aVFMYjcqMkZvQVk0MzdWZWs0YmhIV01ybDNLZG9UUGJBbkdVKjNEJnJlc2VydmVkPTBfXztKU1Vs SlNVbEpTVWxKU1VsSlNVbEpTVWxKU1VsSlEhIU5FdDZ5TWFPLWdrIVVnSGZDdU9PMWlMb3NhRlAy V2ltd1pHMHdaczhLNE0yMDd3TDJzNFhMalZBMTdjSXd0RDZNRUVrNGZOM08wZU0kPiBhcyB0aGUg YmFzaXMgZm9yIGl0cyBjb21wcmVzc2lvbiBzdGFuZGFyZGl6YXRpb24gd29yay4gVGhhdCBpcyBw YXJ0IG9mIHdoYXQgdGhpcyBlbWFpbCBhdHRlbXB0cyB0byBjb25maXJtLg0KDQpCZWNhdXNlIG9m IHRoZSBhYm92ZSB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gaXNzdWUgYSAyLXdlZWsgV0cgY2Fs bCBmb3IgYWRvcHRpb24gZW5kaW5nIE9jdG9iZXIgMTV0aCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJl c3Npb24vPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovbmFtMTEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyozQSoyRioyRmRhdGF0cmFja2VyLmll dGYub3JnKjJGZG9jKjJGZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJl c3Npb24qMkYmZGF0YT0wNCo3QzAxKjdDamFtZXMubi5ndWljaGFyZCo0MGZ1dHVyZXdlaS5jb20q N0M1ZTBkMGZkYjg0NDA0YjUzNTE3MTA4ZDk4NTE5MDc1Zio3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1 M2ExZDU1OTFmZWRjKjdDMSo3QzAqN0M2Mzc2ODcxNjQ4MTY1MDYwNDYqN0NVbmtub3duKjdDVFdG cGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFo YVd3aUxDSlhWQ0k2TW4wKjNEKjdDMTAwMCZzZGF0YT02N090MzJtSEVxejBKWENjMDEqMkJ1STZJ MVdQT3pyd3JDVEVwM3JwOWNWRTgqM0QmcmVzZXJ2ZWQ9MF9fO0pTVWxKU1VsSlNVbEpTVWxKU1Vs SlNVbEpTVSEhTkV0NnlNYU8tZ2shVWdIZkN1T08xaUxvc2FGUDJXaW13Wkcwd1pzOEs0TTIwN3dM MnM0WExqVkExN2NJd3RENk1FRWs0ZGluQzhSeSQ+IGJ1dCB3aXRoIHNvbWUgY2xlYXIgZ3VpZGVs aW5lcyBhcyBmb2xsb3dzLiBCeSBleHByZXNzaW5nIHN1cHBvcnQgZm9yIGFkb3B0aW9uIG9mIHRo aXMgZG9jdW1lbnQgeW91IGFyZSBmdWxseSBhd2FyZSBvZiBhbmQgYXJlIGFja25vd2xlZGdpbmcg dGhhdDoNCg0KDQoxLiAgICAgICBUaGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAgaXMgYWRvcHRpbmcg YSBkb2N1bWVudCB0aGF0IGhhcyBtdWx0aXBsZSBTUnY2IEVuZHBvaW50IGJlaGF2aW9ycy4NCg0K Mi4gICAgICAgVGhlIGRvY3VtZW50IGlzIGEg4oCcbGl2aW5n4oCdIGRvY3VtZW50OyBpdCBtYXkg Y2hhbmdlIGFzIGl0IGdvZXMgdGhyb3VnaCByZXZpZXcgYW5kIGFuYWx5c2lzIGJ5IHRoZSBTUFJJ Tkcgd29ya2luZyBncm91cC4NCg0KMy4gICAgICAgQWxsIG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMg cmFpc2VkIG9uIG91ciBtYWlsaW5nIGxpc3QgTVVTVCBiZSBhZGRyZXNzZWQgQkVGT1JFIHNhaWQg ZG9jdW1lbnQgaXMgYWxsb3dlZCB0byBwcm9ncmVzcyBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIHRv IHB1YmxpY2F0aW9uLiBBIGxpc3Qgb2YgdGhlc2UgZGlzY3Vzc2lvbiBwb2ludHMgd2lsbCBiZSBk b2N1bWVudGVkIGluIHRoZSBXRyBkb2N1bWVudCBhbmQgbWFpbnRhaW5lZCBieSB0aGUgZG9jdW1l bnQgZWRpdG9yIGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIGNoYWlycy4NCg0KNC4gICAgICAgSWYg dGhpcyBkb2N1bWVudCBpcyBhZG9wdGVkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLCB0aGUgY2hhaXJz IHNwZWNpZnkgYXMgcGFydCBvZiB0aGUgYWRvcHRpb24gY2FsbCB0aGF0IHRoZSBmb2xsb3dpbmcg dGV4dCBkZXNjcmliaW5nIGFuIG9wZW4gaXNzdWUgYmUgYWRkZWQgdG8gdGhlIGRvY3VtZW50IGlu IHRoZSBhYm92ZS1kZXNjcmliZWQgb3BlbiBpc3N1ZXMgc2VjdGlvbjoNCg0KwrcgICAgICAgICAi R2l2ZW4gdGhhdCB0aGUgd29ya2luZyBncm91cCBoYXMgc2FpZCB0aGF0IGl0IHdhbnRzIHRvIHN0 YW5kYXJkaXplIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uLCBhbmQgZ2l2ZW4gdGhhdCB0aGUgZG9j dW1lbnQgY29udGFpbnMgbXVsdGlwbGUgU1J2NiBFbmRQb2ludCBiZWhhdmlvcnMgdGhhdCBzb21l IFdHIG1lbWJlcnMgaGF2ZSBzdGF0ZWQgYXJlIG11bHRpcGxlIGRhdGEgcGxhbmUgc29sdXRpb25z LCB0aGUgd29ya2luZyBncm91cCB3aWxsIGFkZHJlc3Mgd2hldGhlciB0aGlzIGlzIHZhbGlkIGFu ZCBjb2hlcmVudCB3aXRoIGl0cyBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiBvYmplY3RpdmUuIi4N Cg0KUGxlYXNlIGNvbnNpZGVyIHRoZSBhYm92ZSBndWlkZWxpbmVzIGFzIHlvdSBkZWNpZGUgb24g d2hldGhlciB0byBzdXBwb3J0IG9yIG5vdCB0aGlzIFdHIGFkb3B0aW9uLiBQbGVhc2UgZXhwcmVz cyBjbGVhcmx5IHlvdXIgcmVhc29uaW5nIGZvciBzdXBwb3J0L25vbi1zdXBwb3J0IGFzIHdlbGwg YXMgYW55IG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgeW91IHdvdWxkIGxpa2UgYWRkcmVzc2VkIHNo b3VsZCB0aGUgZG9jdW1lbnQgYmUgYWRvcHRlZCBpbnRvIHRoZSB3b3JraW5nIGdyb3VwLg0KDQpU aGFua3MhDQoNCkppbSwgQnJ1bm8gJiBKb2VsDQoNCg0K --_000_4473DFC28CE54FADBDC915883F1F1AA6junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <64FDD4F8BB6301409A5011FD08A49D2A@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIFwoQm9keSBD U1wpIjsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkxhdG87DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDM7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFy IjsNCgltYXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBo LCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2lu LXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJn aW4tbGVmdDozNi4wcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBs YWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLm1z aXBmb290ZXIzMGIzZDUzOCwgbGkubXNpcGZvb3RlcjMwYjNkNTM4LCBkaXYubXNpcGZvb3RlcjMw YjNkNTM4DQoJe21zby1zdHlsZS1uYW1lOm1zaXBmb290ZXIzMGIzZDUzODsNCgltc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHls ZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0K CXRleHQtdHJhbnNmb3JtOm5vbmU7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBw dDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVm aW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjM2OTk2MjIzMjsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6LTk0Mzk3MTM5ODt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVs LXN0YXJ0LWF0OjQ7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjc1MTY5 OTM5MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTcy MTY1NDc3NiA2NzY5ODcwMyA2NzY5ODY4OSA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5 ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBw dDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3Qg bDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBs MTpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21h bi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMg0KCXttc28tbGlz dC1pZDoxMTQ3Mjc4Mzc5Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNDMzMDQ0MzAwO30NCm9s DQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLUlOIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIg c3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPisxPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c3JpaGFyaeKApiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1V UyI+T24gMDYvMTAvMjEsIDEyOjI2IEFNIHNwcmluZyBvbiBiZWhhbGYgb2YgUm9uIEJvbmljYSBm cm9tDQo8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciPnNwcmluZy1ib3Vu Y2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzpyYm9uaWNhPTQw anVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmciPnJib25pY2E9NDBqdW5pcGVyLm5ldEBkbWFyYy5p ZXRmLm9yZzwvYT4gc2FpZCAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2xpbmUtaGVp Z2h0OjEyLjBwdDtiYWNrZ3JvdW5kOiNGRkVCOUMiPg0KPGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0xhdG8mcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+W0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50 XTxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+Smlt LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBw dCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTQuMHB0Ij5UaGUgY2FsbCBmb3IgYWRvcHRpb24gaGFzIGFscmVhZHkgYmVlbiBwb3N0ZWQu IFRoZXJlIGlzIG5vIHdheSB0byBwdXQgdGhhdCB0b290aHBhc3RlIGJhY2sgaW50byBpdHMgdHVi ZS4gSG93ZXZlciwgSSBzdHJvbmdseSByZWNvbW1lbmQgYWdhaW5zdCBzdWNoIGNhbGxzIGZvciBh ZG9wdGlvbg0KIGluIHRoZSBmdXR1cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPk5vcm1hbGx5LCB0aGUgYXV0aG9ycyBv ZiBhIGRvY3VtZW50IGFyZSBlbmNvdXJhZ2VkIHRvIGFuc3dlciB0ZWNobmljYWwgcXVlc3Rpb25z IGFzIGEgY29uZGl0aW9uIG9mIGFkb3B0aW9uLiBCdWxsZXQgcG9pbnRzIDEsIDIsIGFuZCA0IGlu IHRoZSBjYWxsIGZvciBhZG9wdGlvbiBkZWZlcg0KIHRoYXQgcmVxdWlyZW1lbnQgdW50aWwgV0cg bGFzdCBjYWxsLiBDb3VsZCB0aGlzIGJlIHdoeSB0ZWNobmljYWwgcXVlc3Rpb25zIGFyZSBub3Qg YmVpbmcgYWRkcmVzc2VkIGR1cmluZyB0aGUgY2FsbCBmb3IgYWRvcHRpb24uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPklu IHNvbWUgZXh0cmVtZSBjb25kaXRpb25zLCBpdCBtYXkgYmUgbmVjZXNzYXJ5IHRvIG1vZGlmeSB0 aGUgdXN1YWwgY2FsbCBmb3IgYWRvcHRpb24gcHJvY2VkdXJlLiBCdXQgdGhlc2UgZXhjZXB0aW9u YWwgY29uZGl0aW9ucyBoYXZlIG5vdCBiZWVuIGFydGljdWxhdGVkLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij5JdCBpcyB1 bmZvcnR1bmF0ZSB0aGF0IHR3byBvZiB0aGUgdGhyZWUgd29ya2luZyBncm91cCBjaGFpcnMgYXJl IGFsc28gY28tYXV0aG9ycyBvZiB0aGUgZHJhZnQuIFdoaWxlIHRoZXJlIG1heSBub3QgaGF2ZSBi ZWVuIGFueSBpbXByb3ByaWV0eSwgdGhlIGFwcGVhcmFuY2Ugb2YgaW1wcm9wcmlldHkNCiBpcyBk aWZmaWN1bHQgdG8gYXZvaWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTQuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJtc2lwZm9vdGVyMzBiM2Q1MzgiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6MGNtO21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTowY207bWFyZ2luLWxlZnQ6 MzYuMHB0O3RleHQtYWxpZ246Y2VudGVyIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjcuMHB0O2NvbG9yOmJsYWNrIj5KdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkZyb206PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyI+IHNwcmluZyAmbHQ7c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8Yj5P biBCZWhhbGYgT2YgPC9iPkphbWVzIEd1aWNoYXJkPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwg T2N0b2JlciA0LCAyMDIxIDExOjEwIEFNPGJyPg0KPGI+VG86PC9iPiBFWFQtQW5kcmV3LkFsc3Rv bkBsaXF1aWR0ZWxlY29tLmNvbSAmbHQ7QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSZn dDs7IFNQUklORyBXRyAmbHQ7c3ByaW5nQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gc3By aW5nLWNoYWlyc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NwcmluZ10gV0cg QWRvcHRpb24gY2FsbCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt Zmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0O2xp bmUtaGVpZ2h0OjEyLjBwdDtiYWNrZ3JvdW5kOiNGRkVCOUMiPg0KPGI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0xhdG8mcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+W0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBj b250ZW50XTxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5BbmRyZXcsPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij5BcyBzdGF0ZWQgaW4gb3VyIGVtYWlsIG9mIFNlcHRlbWJlciA5dGgsIHRoZSBjaGFpcnMgY29t bXVuaWNhdGVkIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgcmVhY2hlZCByb3VnaCAocXVpdGUgY2xl YXIpIGNvbnNlbnN1cyBmb3Igc3RhbmRhcmRpemluZyBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiB0 byBjb21wcmVzcyBzZWdtZW50IHJvdXRpbmcNCiBvdmVyIElQdjYuIEluIGFkZGl0aW9uIHRvIHRo aXMgdGhlcmUgd2FzIGFuIGluY2xpbmF0aW9uIHRvd2FyZCB1c2luZyB0aGUgQ1NJRCBkb2N1bWVu dCBhcyB0aGUgYmFzaXMgZm9yIG91ciB3b3JrIGluIHRoaXMgYXJlYS4gVGhlIGNoYWlycyByZWNv Z25pemVkIHRoYXQgdGhlcmUgd2FzIGhvd2V2ZXIgZGlzYWdyZWVtZW50IGFzIHRvIHdoZXRoZXIg dGhpcyBkb2N1bWVudCwgaGF2aW5nIG11bHRpcGxlIFNSdjYgRW5kUG9pbnQgYmVoYXZpb3JzLCBj b3VsZA0KIGJlIGNvbnNpZGVyZWQgY29uc2lzdGVudCB3aXRoIHRoZSB3b3JraW5nIGdyb3VwIGNv bnNlbnN1cyBmb3IgYSBzaW5nbGUgZGF0YSBwbGFuZSBzb2x1dGlvbi4gVGhpcyBpc3N1ZSBxdWl0 ZSBjbGVhcmx5IG5lZWRlZCB0byBiZSBhZGRyZXNzZWQsIGFuZCB0aGUgY2hhaXJzLCByZWNvZ25p emluZyB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGlzIGtlZW4gdG8gbWFrZSBwcm9ncmVzcyBpbiB0 aGlzIGFyZWEsIGhhZCB0aGUgb3B0aW9uIG9mIHRyeWluZw0KIHRvIHJlc29sdmUgdGhlIGlzc3Vl IHByaW9yIHRvIGlzc3VpbmcgYW4gYWRvcHRpb24gY2FsbCwgb3IgZ2l2ZSB0aGUgd29ya2luZyBn cm91cCB0aGUgb3Bwb3J0dW5pdHkgdG8gZXhwcmVzcyB0aGVpciBvcGluaW9ucyBhcyBwYXJ0IG9m IGEgY2FsbCBmb3IgYWRvcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaG9zZSB3aG8gZmVlbCB0aGF0 IHdlIG5lZWQgdG8gcmVzb2x2ZSB0aGUgY29uc2lzdGVuY3kgaXNzdWUgYmVmb3JlIGFkb3B0aW9u LCBhcyB3aXRoIHRob3NlIHdobyB0aGluayB0aGlzIGlzIG5vdCBhIGdvb2QgYmFzaXMgZm9yIHRo ZSBXRyB3b3JrLCBhcmUgZnJlZSBhbmQgZXhwZWN0ZWQgdG8gb2JqZWN0IHRvIHRoZSBXRyBhZG9w dGluZw0KIHRoZSBkb2N1bWVudC4gVGhhdCBpcyBkaXN0aW5jdCBmcm9tIG9iamVjdGluZyB0byB0 aGUgY2hhaXJzIGlzc3VpbmcgdGhlIGFkb3B0aW9uIGNhbGwuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5JbiBl c3NlbmNlLCB0aGUgY2hhaXJzIGhhdmUgY29tYmluZWQgdGhlIHF1ZXN0aW9uIG9mIHdoZW4gdG8g cmVzb2x2ZSBjb25zaXN0ZW5jeSBhbmQgdGhlIHF1ZXN0aW9uIG9mIHdoZXRoZXIgdGhpcyBkb2N1 bWVudCBpcyBhIGdvb2QgYmFzaXMgZm9yIHRoZSBXRyBpbnRvIG9uZSBjYWxsLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+WW91cnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5KaW0sIEJydW5vICZhbXA7IEpvZWw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIj4gQW5kcmV3IEFsc3RvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOkFuZHJldy5BbHN0b25A bGlxdWlkdGVsZWNvbS5jb20iPkFuZHJldy5BbHN0b25AbGlxdWlkdGVsZWNvbS5jb208L2E+Jmd0 Ow0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgT2N0b2JlciAxLCAyMDIxIDQ6MjEgUE08YnI+ DQo8Yj5Ubzo8L2I+IEphbWVzIEd1aWNoYXJkICZsdDs8YSBocmVmPSJtYWlsdG86amFtZXMubi5n dWljaGFyZEBmdXR1cmV3ZWkuY29tIj5qYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb208L2E+ Jmd0OzsgU1BSSU5HIFdHICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJp bmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnNwcmlu Zy1jaGFpcnNAaWV0Zi5vcmciPnNwcmluZy1jaGFpcnNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBXRyBBZG9wdGlvbiBjYWxsIGZvciA8YSBocmVmPSJodHRwczovL3VybGRl ZmVuc2UuY29tL3YzL19faHR0cHM6L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxz Zmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi9fXzshIU5FdDZ5TWFPLWdrIVdv Mkw1WTFPVkFKYmJ5RFBSWjdkV3NvdHFCaFktTE9OVjlORFVjZzRTUTViUTZuaDl5cllianZ4R3E4 SXd5TSQiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNj aGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPlNvcnJ5IOKAkyBidXQg4oCTIEnigJltIGEgbGl0dGxlIGNvbmZ1c2VkIGhl cmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQi PjxzcGFuIGxhbmc9IkVOLVVTIj5CZWNhdXNlIHRoZSB3YXkgSSBsb29rIGF0IHRoaXMg4oCTIHRo ZSB3b3JraW5nIGdyb3VwIGNsZWFybHkgc3RhdGVkIHRoYXQgdGhleSB3aXNoZWQgZm9yIGEgc2lu Z2xlIGJlaGF2aW9yIOKAkyBhbmQgdGhpcyDigJMgZG9lcyBub3QgZGVsaXZlciB0aGF0IOKAkyBp dCBpcyB0d28gc2VwYXJhdGUgYmVoYXZpb3JzLiZuYnNwOyBBcyBzdWNoIOKAkyBJIHNlZSB0aGlz DQogY2FsbCBmb3IgYWRvcHRpb24g4oCTIGlycmVzcGVjdGl2ZSBvZiB0aGUgbWVyaXRzIG9yIGxh Y2sgdGhlcmVvZiBvZiB0aGUgZHJhZnQsIGFzIGEgY2xlYXIgZGVmaWFuY2Ugb2YgdGhlIHN0YXRl ZCB3aWxsIG9mIHRoZSB3b3JraW5nIGdyb3VwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBpcyBzaW1w bHkgZG9lcyBub3QgZml0IGludG8gdGhlIGRlZmluaXRpb24gb2YgYm90dG9tIHVwIGFwcHJvYWNo IGluIG15IG9waW5pb24g4oCTIGFuZCBpZiB0aGlzIGlzIHRoZSB3YXkgdGhhdCB0aGUgY2hhaXJz IHdpc2ggdG8gcHJvY2VlZCDigJMgdGhlbiB0aGUgb25seSB3YXkgdG8gZG8gdGhhdCBhbmQgc3Rp bGwgZml0IHdpdGhpbg0KIHRoZSBib3R0b20gdXAgYXBwcm9hY2ggaXMgdG8gZmlyc3QgYXNrIHRo aXMgd29ya2luZyBncm91cCBmb3IgaXRzIGNvbnNlbnN1cyB0byBkZXZpYXRlIGZyb20gdGhlIHNp bmdsZSBiZWhhY3Zpb3IgYXBwcm9hY2ggdGhhdCB0aGUgd29ya2luZyBncm91cCBhZ3JlZWQgdG8u PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIj5BcyBzdWNoIOKAkyBJIG11c3QgJm5ic3A7c3Ryb25nbHkgYW5kIHVu ZXF1aXZvY2FsbHkgb2JqZWN0IHRvIHRoaXMgY2FsbCBmb3IgYWRvcHRpb248bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4t VVMiPkFuZHJldzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlk ICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21h cmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48 L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5zcHJpbmcgJmx0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOnNw cmluZy1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+c3By aW5nLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZndDsNCiBvbiBiZWhhbGYgb2Yg SmFtZXMgR3VpY2hhcmQgJmx0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0ibWFp bHRvOmphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPmphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbTwvc3Bhbj48L2E+PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+ Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIDEgT2N0b2JlciAyMDIxIGF0IDE3OjA1PGJy Pg0KPGI+VG86IDwvYj5TUFJJTkcgV0cgJmx0Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PGEg aHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPnNwcmluZ0BpZXRmLm9yZzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jmd0Ozxicj4NCjxiPkNjOiA8L2I+ PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJtYWlsdG86c3ByaW5nLWNoYWlyc0Bp ZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPnNwcmluZy1jaGFpcnNAaWV0 Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiAmbHQ7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48YSBo cmVmPSJtYWlsdG86c3ByaW5nLWNoYWlyc0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQiPnNwcmluZy1jaGFpcnNAaWV0Zi5vcmc8L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZndDs8YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+W3NwcmluZ10gV0cgQWRvcHRpb24gY2FsbCBmb3IgPC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0 cHM6L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1z cnY2LXNyaC1jb21wcmVzc2lvbi9fXzshIU5FdDZ5TWFPLWdrIVVnSGZDdU9PMWlMb3NhRlAyV2lt d1pHMHdaczhLNE0yMDd3TDJzNFhMalZBMTdjSXd0RDZNRUVrNFk2M0twMC0kIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vPC9zcGFuPjwvYT48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5EZWFyIFdHOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBsYW5nPSJFTi1VUyI+VGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGV4cHJlc3MgdGhlaXIgYXBw cmVjaWF0aW9uIGZvciBhbGwgdGhlIHJlc3BvbnNlcyByZWNlaXZlZCB0byBvdXIgZW1haWxzIHdp dGggcmVmZXJlbmNlIHRvIGhvdyB0aGUgd29ya2luZyBncm91cCB3aXNoZXMgdG8gbW92ZSBmb3J3 YXJkIHdpdGggcmVzcGVjdCB0byBhIHNvbHV0aW9uIGZvcg0KIFNSdjYgY29tcHJlc3Npb24uIDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3Bh biBsYW5nPSJFTi1VUyI+VGhlIGFwcGFyZW50IGluY2xpbmF0aW9uIG9mIHRoZSB3b3JraW5nIGdy b3VwIGlzIHRvIHVzZQ0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBz Oi9uYW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzKjNBKjJG KjJGZGF0YXRyYWNrZXIuaWV0Zi5vcmcqMkZkb2MqMkZkcmFmdC1maWxzZmlsc2NoZW5nLXNwcmlu Zy1zcnY2LXNyaC1jb21wcmVzc2lvbioyRiZhbXA7ZGF0YT0wNCo3QzAxKjdDamFtZXMubi5ndWlj aGFyZCo0MGZ1dHVyZXdlaS5jb20qN0M1ZTBkMGZkYjg0NDA0YjUzNTE3MTA4ZDk4NTE5MDc1Zio3 QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRjKjdDMSo3QzAqN0M2Mzc2ODcxNjQ4MTY0 OTYwNTIqN0NVbmtub3duKjdDVFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpv aVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2TW4wKjNEKjdDMTAwMCZhbXA7c2RhdGE9 KjJCVnNMOSoyQkhneWlRTGI3KjJGb0FZNDM3VmVrNGJoSFdNcmwzS2RvVFBiQW5HVSozRCZhbXA7 cmVzZXJ2ZWQ9MF9fO0pTVWxKU1VsSlNVbEpTVWxKU1VsSlNVbEpTVWxKUSEhTkV0NnlNYU8tZ2sh VWdIZkN1T08xaUxvc2FGUDJXaW13Wkcwd1pzOEs0TTIwN3dMMnM0WExqVkExN2NJd3RENk1FRWs0 Zk4zTzBlTSQiPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2Zp bHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vPC9hPiBhcyB0aGUgYmFzaXMgZm9y IGl0cyBjb21wcmVzc2lvbiBzdGFuZGFyZGl6YXRpb24gd29yay4gVGhhdCBpcyBwYXJ0IG9mIHdo YXQgdGhpcyBlbWFpbCBhdHRlbXB0cyB0byBjb25maXJtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QmVjYXVz ZSBvZiB0aGUgYWJvdmUgdGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGlzc3VlIGEgMi13ZWVrIFdH IGNhbGwgZm9yIGFkb3B0aW9uIGVuZGluZyBPY3RvYmVyIDE1PHN1cD50aDwvc3VwPiBmb3INCjxh IGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovbmFtMTEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyozQSoyRioyRmRhdGF0cmFja2VyLmll dGYub3JnKjJGZG9jKjJGZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJl c3Npb24qMkYmYW1wO2RhdGE9MDQqN0MwMSo3Q2phbWVzLm4uZ3VpY2hhcmQqNDBmdXR1cmV3ZWku Y29tKjdDNWUwZDBmZGI4NDQwNGI1MzUxNzEwOGQ5ODUxOTA3NWYqN0MwZmVlOGZmMmEzYjI0MDE4 OWM3NTNhMWQ1NTkxZmVkYyo3QzEqN0MwKjdDNjM3Njg3MTY0ODE2NTA2MDQ2KjdDVW5rbm93bio3 Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2 SWsxaGFXd2lMQ0pYVkNJNk1uMCozRCo3QzEwMDAmYW1wO3NkYXRhPTY3T3QzMm1IRXF6MEpYQ2Mw MSoyQnVJNkkxV1BPenJ3ckNURXAzcnA5Y1ZFOCozRCZhbXA7cmVzZXJ2ZWQ9MF9fO0pTVWxKU1Vs SlNVbEpTVWxKU1VsSlNVbEpTVSEhTkV0NnlNYU8tZ2shVWdIZkN1T08xaUxvc2FGUDJXaW13Wkcw d1pzOEs0TTIwN3dMMnM0WExqVkExN2NJd3RENk1FRWs0ZGluQzhSeSQiPg0KaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgt Y29tcHJlc3Npb24vPC9hPiBidXQgd2l0aCBzb21lIGNsZWFyIGd1aWRlbGluZXMgYXMgZm9sbG93 cy4gQnkgZXhwcmVzc2luZyBzdXBwb3J0IGZvciBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IHlv dSBhcmUgZnVsbHkgYXdhcmUgb2YgYW5kIGFyZSBhY2tub3dsZWRnaW5nIHRoYXQ6DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4 dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAgaXMg YWRvcHRpbmcgYSBkb2N1bWVudCB0aGF0IGhhcyBtdWx0aXBsZSBTUnY2IEVuZHBvaW50IGJlaGF2 aW9ycy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6 bDEgbGV2ZWwxIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0iRU4tVVMi PjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQg JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5nPSJFTi1V UyI+VGhlIGRvY3VtZW50IGlzIGEg4oCcbGl2aW5n4oCdIGRvY3VtZW50OyBpdCBtYXkgY2hhbmdl IGFzIGl0IGdvZXMgdGhyb3VnaCByZXZpZXcgYW5kIGFuYWx5c2lzIGJ5IHRoZSBTUFJJTkcgd29y a2luZyBncm91cC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFuZz0i RU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBsYW5n PSJFTi1VUyI+QWxsIG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgcmFpc2VkIG9uIG91ciBtYWlsaW5n IGxpc3QgTVVTVCBiZSBhZGRyZXNzZWQgQkVGT1JFIHNhaWQgZG9jdW1lbnQgaXMgYWxsb3dlZCB0 byBwcm9ncmVzcyBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIHRvIHB1YmxpY2F0aW9uLiBBIGxpc3Qg b2YgdGhlc2UgZGlzY3Vzc2lvbiBwb2ludHMgd2lsbCBiZSBkb2N1bWVudGVkDQogaW4gdGhlIFdH IGRvY3VtZW50IGFuZCBtYWludGFpbmVkIGJ5IHRoZSBkb2N1bWVudCBlZGl0b3IgaW4gY29uanVu Y3Rpb24gd2l0aCB0aGUgY2hhaXJzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+NC48c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZd PjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB0aGlzIGRvY3VtZW50IGlzIGFkb3B0ZWQgYnkgdGhlIHdv cmtpbmcgZ3JvdXAsIHRoZSBjaGFpcnMgc3BlY2lmeSBhcyBwYXJ0IG9mIHRoZSBhZG9wdGlvbiBj YWxsIHRoYXQgdGhlIGZvbGxvd2luZyB0ZXh0IGRlc2NyaWJpbmcgYW4gb3BlbiBpc3N1ZSBiZSBh ZGRlZCB0byB0aGUgZG9jdW1lbnQgaW4gdGhlIGFib3ZlLWRlc2NyaWJlZCBvcGVuIGlzc3Vlcw0K IHNlY3Rpb246PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MSBsZXZlbDIgbGZvMyI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIj4mcXVvdDtHaXZlbiB0aGF0 IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBzYWlkIHRoYXQgaXQgd2FudHMgdG8gc3RhbmRhcmRpemUg b25lIGRhdGEgcGxhbmUgc29sdXRpb24sIGFuZCBnaXZlbiB0aGF0IHRoZSBkb2N1bWVudCBjb250 YWlucyBtdWx0aXBsZSBTUnY2IEVuZFBvaW50IGJlaGF2aW9ycyB0aGF0IHNvbWUgV0cgbWVtYmVy cyBoYXZlIHN0YXRlZCBhcmUgbXVsdGlwbGUNCiBkYXRhIHBsYW5lIHNvbHV0aW9ucywgdGhlIHdv cmtpbmcgZ3JvdXAgd2lsbCBhZGRyZXNzIHdoZXRoZXIgdGhpcyBpcyB2YWxpZCBhbmQgY29oZXJl bnQgd2l0aCBpdHMgb25lIGRhdGEgcGxhbmUgc29sdXRpb24gb2JqZWN0aXZlLiZxdW90Oy48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g bGFuZz0iRU4tVVMiPlBsZWFzZSBjb25zaWRlciB0aGUgYWJvdmUgZ3VpZGVsaW5lcyBhcyB5b3Ug ZGVjaWRlIG9uIHdoZXRoZXIgdG8gc3VwcG9ydCBvciBub3QgdGhpcyBXRyBhZG9wdGlvbi4gUGxl YXNlIGV4cHJlc3MgY2xlYXJseSB5b3VyIHJlYXNvbmluZyBmb3Igc3VwcG9ydC9ub24tc3VwcG9y dCBhcyB3ZWxsIGFzIGFueSBvcGVuIGRpc2N1c3Npb24NCiBwb2ludHMgeW91IHdvdWxkIGxpa2Ug YWRkcmVzc2VkIHNob3VsZCB0aGUgZG9jdW1lbnQgYmUgYWRvcHRlZCBpbnRvIHRoZSB3b3JraW5n IGdyb3VwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+SmltLCBCcnVu byAmYW1wOyBKb2VsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4473DFC28CE54FADBDC915883F1F1AA6junipernet_-- From nobody Fri Oct 8 03:02:43 2021 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 02B923A15FE; Fri, 8 Oct 2021 03:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkXwKPoXYKNU; Fri, 8 Oct 2021 03:02:34 -0700 (PDT) Received: from cmccmta2.chinamobile.com (cmccmta2.chinamobile.com [221.176.66.80]) by ietfa.amsl.com (Postfix) with ESMTP id B7B1D3A0CA9; Fri, 8 Oct 2021 03:02:33 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.13]) by rmmx-syy-dmz-app07-12007 (RichMail) with SMTP id 2ee76160172dd18-69f47; Fri, 08 Oct 2021 18:02:21 +0800 (CST) X-RM-TRANSID: 2ee76160172dd18-69f47 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from LAPTOP-C68G8FQH (unknown[223.104.39.117]) by rmsmtp-syy-appsvr07-12007 (RichMail) with SMTP id 2ee7616017298ab-bc108; Fri, 08 Oct 2021 18:02:21 +0800 (CST) X-RM-TRANSID: 2ee7616017298ab-bc108 Date: Fri, 8 Oct 2021 18:02:21 +0800 From: "gongliyan@chinamobile.com" To: "James Guichard" , spring Cc: spring-chairs References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.22.188[cn] Mime-Version: 1.0 Message-ID: <2021100818021955545720@chinamobile.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart862481244303_=----" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 08 Oct 2021 10:02:42 -0000 This is a multi-part message in MIME format. ------=_001_NextPart862481244303_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBDaGFpcnMgJiBXR++8jA0KDQpJIHN1cHBvcnQgdGhlIFdHIGFkb3B0aW9uIG9mIHRoaXMg ZHJhZnQuDQoNCkkgYmVsaWV2ZSB0d28gZmxhdm9ycyBhcmUgYmV0dGVyIGZvciBvcGVyYXRvcnM6 DQotIEludGVyb3BlcmF0aW9uIGJldHdlZW4gYm90aCBmbGF2b3JzIGhhcyBiZWVuIHZlcmlmaWVk IGluIENoaW5hIE1vYmlsZSBMYWIsIGFuZCBpdCB3b3JrcyB2ZXJ5IHdlbGwuDQotIEFzIGFuIG9w ZXJhdG9yIEkgd2FudCBmbGV4aWJpbGl0eSB0byBjaG9vc2UgZGlmZmVyZW50IGZsYXZvcnMgaW4g ZGVwbG95bWVudC4gDQoNCkl0IG1ha2VzIHNlbnNlIHRoYXQgb3BlcmF0b3JzIGhhdmUgdGhlIGFi aWxpdHkgdG8gY2hvb3NlIHdoZW4gdG8gaW5zdGFudGlhdGUgdGhlc2UgU0lEcyB0byBhY2hpZXZl IHRoZWlyIGRpZmZlcmVudCBnb2Fscy4NCg0KQmVzdCBSZWdhcmRz77yMDQpMaXlhbiBHb25nDQog DQpGcm9tOiBKYW1lcyBHdWljaGFyZA0KRGF0ZTogMjAyMS0xMC0wMSAyMjowNA0KVG86IFNQUklO RyBXRw0KQ0M6IHNwcmluZy1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFtzcHJpbmddIFdHIEFk b3B0aW9uIGNhbGwgZm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZp bHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLw0KRGVhciBXRzoNCiANClRo ZSBjaGFpcnMgd291bGQgbGlrZSB0byBleHByZXNzIHRoZWlyIGFwcHJlY2lhdGlvbiBmb3IgYWxs IHRoZSByZXNwb25zZXMgcmVjZWl2ZWQgdG8gb3VyIGVtYWlscyB3aXRoIHJlZmVyZW5jZSB0byBo b3cgdGhlIHdvcmtpbmcgZ3JvdXAgd2lzaGVzIHRvIG1vdmUgZm9yd2FyZCB3aXRoIHJlc3BlY3Qg dG8gYSBzb2x1dGlvbiBmb3IgU1J2NiBjb21wcmVzc2lvbi4gDQogDQpUaGUgYXBwYXJlbnQgaW5j bGluYXRpb24gb2YgdGhlIHdvcmtpbmcgZ3JvdXAgaXMgdG8gdXNlIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXBy ZXNzaW9uLyBhcyB0aGUgYmFzaXMgZm9yIGl0cyBjb21wcmVzc2lvbiBzdGFuZGFyZGl6YXRpb24g d29yay4gVGhhdCBpcyBwYXJ0IG9mIHdoYXQgdGhpcyBlbWFpbCBhdHRlbXB0cyB0byBjb25maXJt Lg0KIA0KQmVjYXVzZSBvZiB0aGUgYWJvdmUgdGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGlzc3Vl IGEgMi13ZWVrIFdHIGNhbGwgZm9yIGFkb3B0aW9uIGVuZGluZyBPY3RvYmVyIDE1dGggZm9yIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5n LXNydjYtc3JoLWNvbXByZXNzaW9uLyBidXQgd2l0aCBzb21lIGNsZWFyIGd1aWRlbGluZXMgYXMg Zm9sbG93cy4gQnkgZXhwcmVzc2luZyBzdXBwb3J0IGZvciBhZG9wdGlvbiBvZiB0aGlzIGRvY3Vt ZW50IHlvdSBhcmUgZnVsbHkgYXdhcmUgb2YgYW5kIGFyZSBhY2tub3dsZWRnaW5nIHRoYXQ6IA0K IA0KVGhlIFNQUklORyB3b3JraW5nIGdyb3VwIGlzIGFkb3B0aW5nIGEgZG9jdW1lbnQgdGhhdCBo YXMgbXVsdGlwbGUgU1J2NiBFbmRwb2ludCBiZWhhdmlvcnMuIA0KVGhlIGRvY3VtZW50IGlzIGEg 4oCcbGl2aW5n4oCdIGRvY3VtZW50OyBpdCBtYXkgY2hhbmdlIGFzIGl0IGdvZXMgdGhyb3VnaCBy ZXZpZXcgYW5kIGFuYWx5c2lzIGJ5IHRoZSBTUFJJTkcgd29ya2luZyBncm91cC4gDQpBbGwgb3Bl biBkaXNjdXNzaW9uIHBvaW50cyByYWlzZWQgb24gb3VyIG1haWxpbmcgbGlzdCBNVVNUIGJlIGFk ZHJlc3NlZCBCRUZPUkUgc2FpZCBkb2N1bWVudCBpcyBhbGxvd2VkIHRvIHByb2dyZXNzIGZyb20g dGhlIHdvcmtpbmcgZ3JvdXAgdG8gcHVibGljYXRpb24uIEEgbGlzdCBvZiB0aGVzZSBkaXNjdXNz aW9uIHBvaW50cyB3aWxsIGJlIGRvY3VtZW50ZWQgaW4gdGhlIFdHIGRvY3VtZW50IGFuZCBtYWlu dGFpbmVkIGJ5IHRoZSBkb2N1bWVudCBlZGl0b3IgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgY2hh aXJzLiANCklmIHRoaXMgZG9jdW1lbnQgaXMgYWRvcHRlZCBieSB0aGUgd29ya2luZyBncm91cCwg dGhlIGNoYWlycyBzcGVjaWZ5IGFzIHBhcnQgb2YgdGhlIGFkb3B0aW9uIGNhbGwgdGhhdCB0aGUg Zm9sbG93aW5nIHRleHQgZGVzY3JpYmluZyBhbiBvcGVuIGlzc3VlIGJlIGFkZGVkIHRvIHRoZSBk b2N1bWVudCBpbiB0aGUgYWJvdmUtZGVzY3JpYmVkIG9wZW4gaXNzdWVzIHNlY3Rpb246DQoiR2l2 ZW4gdGhhdCB0aGUgd29ya2luZyBncm91cCBoYXMgc2FpZCB0aGF0IGl0IHdhbnRzIHRvIHN0YW5k YXJkaXplIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uLCBhbmQgZ2l2ZW4gdGhhdCB0aGUgZG9jdW1l bnQgY29udGFpbnMgbXVsdGlwbGUgU1J2NiBFbmRQb2ludCBiZWhhdmlvcnMgdGhhdCBzb21lIFdH IG1lbWJlcnMgaGF2ZSBzdGF0ZWQgYXJlIG11bHRpcGxlIGRhdGEgcGxhbmUgc29sdXRpb25zLCB0 aGUgd29ya2luZyBncm91cCB3aWxsIGFkZHJlc3Mgd2hldGhlciB0aGlzIGlzIHZhbGlkIGFuZCBj b2hlcmVudCB3aXRoIGl0cyBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiBvYmplY3RpdmUuIi4NCiAN ClBsZWFzZSBjb25zaWRlciB0aGUgYWJvdmUgZ3VpZGVsaW5lcyBhcyB5b3UgZGVjaWRlIG9uIHdo ZXRoZXIgdG8gc3VwcG9ydCBvciBub3QgdGhpcyBXRyBhZG9wdGlvbi4gUGxlYXNlIGV4cHJlc3Mg Y2xlYXJseSB5b3VyIHJlYXNvbmluZyBmb3Igc3VwcG9ydC9ub24tc3VwcG9ydCBhcyB3ZWxsIGFz IGFueSBvcGVuIGRpc2N1c3Npb24gcG9pbnRzIHlvdSB3b3VsZCBsaWtlIGFkZHJlc3NlZCBzaG91 bGQgdGhlIGRvY3VtZW50IGJlIGFkb3B0ZWQgaW50byB0aGUgd29ya2luZyBncm91cC4NCiANClRo YW5rcyENCiANCkppbSwgQnJ1bm8gJiBKb2VsDQogDQogDQo= ------=_001_NextPart862481244303_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A=0A
Dear Chairs & WG=EF=BC=8C
<= div>
I support the WG adoption of this draft.

I believe two flavors are better for operators:
= - Interoperation between both flavors has been verified in China Mobile La= b, and it works very well.
- As an operator I want flexibility t= o choose different flavors in deployment. 

I= t makes sense that operators have the ability to choose when to instantiat= e these SIDs to achieve their different goals.
=0A

Best Regards=EF=BC=8C
Liyan Gong
=0A
 
Dat= e: 2021-10-01 22:04
Subje= ct: [spring] WG Adoption call for https://datatracker.ietf.org/do= c/draft-filsfilscheng-spring-srv6-srh-compression/
<= div class=3D"FoxDiv20211008172541219889">=0A=0A
=0A

Dear WG:

=0A

=  

=0A

The chairs would like to express= their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a so= lution for SRv6 compression.=0A

=0A

 

=0A

The apparent inclination of t= he working group is to use =0Ahttps://datatracker.ietf= .org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email= attempts to confirm.

=0A

 <= /o:p>

=0A

Because of the above the chairs would l= ike to issue a 2-week WG call for adoption ending October 15th = for=0A=0Ahttps://datatracker.ietf.org/doc/draft-filsfi= lscheng-spring-srv6-srh-compression/ but with some clear guidelines as= follows. By expressing support for adoption of this document you are full= y aware of and are acknowledging that:=0A

=0A

 

=0A
    =0A
  1. The SPRING working group is adopting a document that has multiple SR= v6 Endpoint behaviors.=0A
  2. The document is a =E2=80=9Cliving=E2=80=9D document; it may ch= ange as it goes through review and analysis by the SPRING working group.= =0A
  3. All open d= iscussion points raised on our mailing list MUST be addressed BEFORE said = document is allowed to progress from the working group to publication. A l= ist of these discussion=0A points will be documented in the WG document an= d maintained by the document editor in conjunction with the chairs.=0A
  4. If this document = is adopted by the working group, the chairs specify as part of the adoptio= n call that the following text describing an open issue be added to the do= cument in the above-described=0A open issues section:
      5. =0A
    • "Given that the working group has said that it wants to = standardize one data plane solution, and given that the document contains = multiple SRv6 EndPoint behaviors that some WG members have stated are=0A m= ultiple data plane solutions, the working group will address whether this = is valid and coherent with its one data plane solution objective.".
    =0A
=0A

 

=0APlease consider the above guidelines as you decide on= whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you= would like addressed should the document=0A be adopted into the working g= roup.

=0A

 

=0A

Thanks!

=0A

=  

=0A

Jim, Bruno & Joel=

=0A

 

=0A

 

=0A
=0A
=0A ------=_001_NextPart862481244303_=------ From nobody Fri Oct 8 03:29:57 2021 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 2C8DF3A1613; Fri, 8 Oct 2021 03:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=yU9KNknd; dkim=pass (1024-bit key) header.d=juniper.net header.b=IMq3WkH9 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 Ct6ZSsNNE3SZ; Fri, 8 Oct 2021 03:29:46 -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 7485F3A160C; Fri, 8 Oct 2021 03:29:46 -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 SMTP id 1986nqtL021568; Fri, 8 Oct 2021 03:29:44 -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=tAr/ZCQ1SHmTKcX51XwjXFNk/SJsDs/1+XXQII+SWWI=; b=yU9KNkndY6y9t1vOl7tVR/AlvtZQiwvjqRLiyU4eNRwQleOppL/3tQCrvMjM0xDYiOKF C16deRopQ5A4xovP1O/mVqAbqy3EDaLlVR93vbd1VykvhdQZuWZtfyAesggjMZrNE5F/ aOZOFtxIdftFSnRND8kmzLVjzHy/KpidaPna50/AEoEJ+1uqvrgWSdBU9NyLHJYAe2fQ iKMrqajL/odMu5+5s97PgpLqTOHrkwtcLCA0Rb4xuWm0DtLjB01OF6zHCzZoFSVwKS/f 0BrCxMhR5ROiues9oHBgSILEkTnkpt7jn7AajHtTCDEiOGKVWtP1zt6mesVji18jwrsR 0w== Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2174.outbound.protection.outlook.com [104.47.57.174]) by mx0b-00273201.pphosted.com with ESMTP id 3bjh2g8bw2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 08 Oct 2021 03:29:44 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PSzBSGT4IBIdo5qmIe8Wqspx1vEbriYTQQ7aQjgafKWTk+RfMf0kgwRvVk+LyoHf1grqErdSgy7Dx1mYyI86nyVIgwkH+RgqOrKbEPewUnSGZc+3+1WYoGZLF0Jxblyy3kPVvZWTsuocLT59ouu6QgV3pHtzSc7nra4QExNXp4A9Qxg4PFWEjDH8bCB15ULspQGvukfSOLvYyklYk6xm+I74n1z6v3iOgCcOPqGqxC3jC7QvccH6cz2pvrk+duK19SBzuch3sLNLd1SJBTGaQNGqx/1nQ/5sM4fjFtb+4pmzaARgz11RFWaZTt2mKDg1dGXE0GnYYNfGY3sHVs4TrA== 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=tAr/ZCQ1SHmTKcX51XwjXFNk/SJsDs/1+XXQII+SWWI=; b=dHaPMwnBKjWLtREC9jKIoIvi2NneFuGEOWnFoSNPolwt/rYffzPht+lBMkaadqKnxbIQHZnGXGY0msvdaOmHF07HCLG1FKlrmim1otg+l5uLVQyqVCF+/CHuAY8DMUE/+qS2JbRlXXnFBtyUzo5cApBsKfc7TMTyydk7h+uwLfAP5Dg3wZdY6aEnyxNvLfWnZCYC+yuB8mQiym2xQ+A1B6hDvzEn0LXFPdUXytJM2VKIEG3KF75Q9wadb/8IBCJ0WRGuS+98x6+rFla01zuCcMXujJ7MwgXBExtleOJ5s6nHPTe054mejy5TwniLbPNbzlrN96tPwUvM4CzW8pvcVA== 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=tAr/ZCQ1SHmTKcX51XwjXFNk/SJsDs/1+XXQII+SWWI=; b=IMq3WkH9XswthtfU6t5NF7X+9mIsEhhBqeToOLnPZYmSXJ7nKv8u1eytQ7nq05YJCMJeGg+M4pwD1cRDAt6tOhjrRJ9Ysv7SVBdHXqGZ9sF3TucHdL2fVAOWvX65zPVVgeJ4M9H5mOjbD6knQxIqy1kIy4hTSjYQMWh8YfVLbKU= Received: from PH0PR05MB7687.namprd05.prod.outlook.com (2603:10b6:510:2a::23) by PH0PR05MB7528.namprd05.prod.outlook.com (2603:10b6:510:25::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.15; Fri, 8 Oct 2021 10:29:41 +0000 Received: from PH0PR05MB7687.namprd05.prod.outlook.com ([fe80::509e:c6b2:5b8b:1074]) by PH0PR05MB7687.namprd05.prod.outlook.com ([fe80::509e:c6b2:5b8b:1074%7]) with mapi id 15.20.4587.016; Fri, 8 Oct 2021 10:29:41 +0000 From: Julian Lucek To: SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-rv6-srh-compression/ Thread-Index: AQHXvC9nUBMZzRzuakaOJBUUrvk8YQ== Date: Fri, 8 Oct 2021 10:29:41 +0000 Message-ID: <525AA018-DDDE-45F3-B025-AA2C37907946@juniper.net> References: <4473DFC2-8CE5-4FAD-BDC9-15883F1F1AA6@juniper.net> In-Reply-To: <4473DFC2-8CE5-4FAD-BDC9-15883F1F1AA6@juniper.net> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.53.21091200 msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-05T18:56:07Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=cb540479-0624-482f-bde4-680b11adf467; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b57e26c3-8bb5-4a2a-7c71-08d98a4689de x-ms-traffictypediagnostic: PH0PR05MB7528: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cqrgR56dwIcZfG99u7Rim7swlwxXaO97SFohWA4k75etEryKR9BanMofeSVXJ+BmVGIajqGsp0S6q4xNo360s3Mb7nnZtPXT9YxzCEcFpWgn4Fj0H9DMqUyxiGXH3wWTmwcH3RjEwiR71AtMZxm97abzK/Wrvh+b+UOpdz0q4Bma0ukwip0uNN8eJc9C7L214WksYBieJLZQ6zNG+eurM9HIfRcfmxjYYz2coi524PF0ljpPJBaUMaJeGJG+/MF28yHed9T4aFApUWsH/ZmydLzNAJWhxPqoAtbSdYhRXDQxsdaScxAm5ewke/OXS+DwVRNElWu5iYE1AdH/eEamGQ1K5Vp79OnvVK933VAjZXzjdViOiH387IWcImljm/RhWWMrun2yNrwjbsFfnplGUWwi+hx1sTl/MKdZN4CyXDuE/OkF84BOJj0Q9MCtvt4UAd/uzeNgKsOnDMCZfGO3x5sGVmOfRkw2DkjTmPC7RtMvL/mq3Hu7mkHQSV2d6oKROQeL006o/HOhrV8zHOVXJ5+GDPeyFWXrq8O0fGTBh/poj8bJs0kqCX5UDlMuFZuBRbcEoBV3t2K6XyvpwJif+rg4lfmPeHBkumYh+1vR2QpSgQ/ArD/+ct1hfGWJqmcnDKAVUVHEiInW50zCEGQlpLkJxj9EZSfUzkIyLnNOW5vulAkyWB02OrCOFVwrW4p2FvPFmrV/8GhNuzX/FctOnwDD0kUUJGX28SFTMG2aQHdSAsRp9isyWHkAJmL/Kkq6Jf2TDML1TipCuH2u/8hqRio3BpogL3S1zOlnFb/L1mJq+u4Aqk8r2O6eKrG4GoDKMNDqtouRmpfh56nGKPdsYcfc4+vcXksQVL9XTYLwOQE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR05MB7687.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(26005)(33656002)(45080400002)(83380400001)(86362001)(186003)(8676002)(966005)(450100002)(66946007)(38100700002)(76116006)(64756008)(91956017)(71200400001)(66446008)(5660300002)(38070700005)(66556008)(66476007)(2906002)(36756003)(6486002)(4326008)(6916009)(508600001)(6512007)(122000001)(53546011)(316002)(6506007)(8936002)(2616005)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?UTVmbnVCbFhTYzlPdUloL2x6V0NOb3JtcXgwa1hSUHU4MGI0YTVaNUhUVzI4?= =?utf-8?B?RDFFaXJ3ZFFuNzNWY283bWtHcDhVTVpDOU5VRkVWRjJxa0FTVWlhK2hlbzZa?= =?utf-8?B?cjRLNDRhWmJXOEUzSGkvQTI0OWNCUTFkTy9aTnF0S1VBbUdna0tZbXVLcVdw?= =?utf-8?B?SkF4UTUzam5IVEJrL0VzZjBIaDRpUUlUd1NwdTZ0YXgvaVBBTWxzbnR2SlFU?= =?utf-8?B?NlVHcTFzRzI3c2xFSHB0SERGOVZwUnpRc3FEUGN5SkkrdGVhUno3VDkwR09M?= =?utf-8?B?bVZGZlRtWHlITkhySVQ4aFU1WEh3TjZGVUlIV2JnZEZuTW1LS0tFOEZER254?= =?utf-8?B?SG5UTjBRcjFVM3NsV2wvV3RKbW5JOFZBMk4zQmZLQWhSbjRzTzY4bkJja0E3?= =?utf-8?B?NCtXaVVJOUJFbnQzMFFYVG9iNGxzQVVrSjN1VlEwd3h5SHJteGNTa3VKSVdM?= =?utf-8?B?REZqU2p1eDB3bHFUc1lrR2dldjBjdGMyaGFHS0piRWQwTU9wd0dVbUNodnFi?= =?utf-8?B?NTdoeUJtR0h2TnUvWlAxcHozcGJGcXQzMDltZVJ5a1JJYURiWGpXSG00ZDJ3?= =?utf-8?B?WGhlN2lYY2pEazN2NkZKSXBGVytPdC9sQmNRdWF2TmJkM1hIS1JDQktYRGFr?= =?utf-8?B?Z0svV2FCTWNTVi9EeitEbDFRWHA4ZFFWZmVLK2dHY00yVkF2MngwUFl1aDha?= =?utf-8?B?eHd6Vkhmck85YTkrQkluKzFYcVFlUmVFMW9mdGtXS0JNcEJhakg5Mjc4M1Vx?= =?utf-8?B?bUh0VkcrdTl2UlY0cFF4eHZBZVRKcWM4MzQ2WCtWS2JsZG9FVGhmVUFTZkZX?= =?utf-8?B?cnlOSEpYZjY4TFhoYTYxUm8wVEMwL3ZPbjlHZExLLzB2UVZJNUpvWTB4K1RI?= =?utf-8?B?RzMyOHRFZW0zRjRyZ3YwQ1o5UmtjMHlIa1JEOUxUanJhbllHck8wQVFsMEto?= =?utf-8?B?NTQ4eitzMXFTWWJzM2pCem5DOUVGWFovQ3VyRVo4WHgyTFI1a3pvRXBaNHRx?= =?utf-8?B?b05WQ0pLQkQrWnRZWDYxVTYrZTBuVy9Id0FlL3FHQVFESEVzRjIvcVd1N0NG?= =?utf-8?B?WWxjRnFXQk9MTEJ1RERJMjNWOHUwU05MUGRraGxvby9za083d1p4SVdBQUsw?= =?utf-8?B?N2h5aTVhMWxPaSt1SURGNzArZzVLb3krNkRHV2x2REVPT0JnVklsNGwwZTZh?= =?utf-8?B?ekE0ektQSEQ5S3ZyUSttSVNqRGIrcmVBeDljMG8vMGhFN1plNThnWExSc3ZN?= =?utf-8?B?SCtFV0JTc2pGZTYwSjBoaHZtekpISER4V3VKSlgwZ0N6R1pNaEFudGZ6MFZC?= =?utf-8?B?Q0dnb0RWQ2w3bWpSdW1TTmJxMDdYaEFJT2xKUDRVREZ0UkwvTHhKWFIzQkxy?= =?utf-8?B?SnNhVUp3YXVWeHBCWlRKakExZ2VTMkpBdUxQTlk5N0d0QU82MnVEOC9NSk1T?= =?utf-8?B?bTJJNzlKUGNWZENyY3hiQlRKSnd4MXhQQ21KdXBOdzluRVhtTi8rLzFKOE45?= =?utf-8?B?U3A5UkMvVGRXeXdmZWppcDY4OG5wTVpPY2UvQzRpc01KZ005VDRBYlkvUmFD?= =?utf-8?B?L2t3QVRsSldBbk40dmo2d2ZMZUdHU01sc1hRZTFMREMrd2R6RmZUb3JmbzRV?= =?utf-8?B?alpWYlNBY2c0bmR1ZEFpUStBT1pWTDVIcmZucUZNTVVnRTlJUG1PdUhaS0Jl?= =?utf-8?B?ZWtKcGdWSkZhaFVha2hSNC91YWR4dTM0UUQzajM0VlUxUERQdjJiWHlDb04v?= =?utf-8?B?U0dsc290b2tGblZBVGpRTnpCbENFcVY1QkpLMTdrUlNlNUhUR1lOY2lGMC9R?= =?utf-8?B?NEV1VTNCdlhmTC9odjM1UT09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR05MB7687.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b57e26c3-8bb5-4a2a-7c71-08d98a4689de X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2021 10:29:41.3884 (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: hWLruSaR3q5MSWEr2CEtJ6FirRVT+IIRqse8CfAWqO7YCSEVogvyBWL+Ucjb165alFE0OU401XDMjZa6Nf3eDg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR05MB7528 X-Proofpoint-ORIG-GUID: GzEH-rwlx2vrsFW5rtMmCnDsapNkq41k X-Proofpoint-GUID: GzEH-rwlx2vrsFW5rtMmCnDsapNkq41k X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-08_03,2021-10-07_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 bulkscore=0 phishscore=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 adultscore=0 spamscore=0 clxscore=1011 mlxlogscore=999 malwarescore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110080062 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-rv6-srh-compression/ 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, 08 Oct 2021 10:29:54 -0000 KzEgdG8gUm9u4oCZcyBjb21tZW50cw0KDQpKdWxpYW4NCg0KDQpPbiAwNi8xMC8yMSwgMTI6MjYg QU0gc3ByaW5nIG9uIGJlaGFsZiBvZiBSb24gQm9uaWNhIGZyb20gbWFpbHRvOnNwcmluZy1ib3Vu Y2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtYWlsdG86cmJvbmljYT00MGp1bmlwZXIubmV0QGRt YXJjLmlldGYub3JnIHNhaWQgPg0KDQpbRXh0ZXJuYWwgRW1haWwuIEJlIGNhdXRpb3VzIG9mIGNv bnRlbnRdDQoNCkppbSwNCg0KVGhlIGNhbGwgZm9yIGFkb3B0aW9uIGhhcyBhbHJlYWR5IGJlZW4g cG9zdGVkLiBUaGVyZSBpcyBubyB3YXkgdG8gcHV0IHRoYXQgdG9vdGhwYXN0ZSBiYWNrIGludG8g aXRzIHR1YmUuIEhvd2V2ZXIsIEkgc3Ryb25nbHkgcmVjb21tZW5kIGFnYWluc3Qgc3VjaCBjYWxs cyBmb3IgYWRvcHRpb24gaW4gdGhlIGZ1dHVyZS4NCg0KTm9ybWFsbHksIHRoZSBhdXRob3JzIG9m IGEgZG9jdW1lbnQgYXJlIGVuY291cmFnZWQgdG8gYW5zd2VyIHRlY2huaWNhbCBxdWVzdGlvbnMg YXMgYSBjb25kaXRpb24gb2YgYWRvcHRpb24uIEJ1bGxldCBwb2ludHMgMSwgMiwgYW5kIDQgaW4g dGhlIGNhbGwgZm9yIGFkb3B0aW9uIGRlZmVyIHRoYXQgcmVxdWlyZW1lbnQgdW50aWwgV0cgbGFz dCBjYWxsLiBDb3VsZCB0aGlzIGJlIHdoeSB0ZWNobmljYWwgcXVlc3Rpb25zIGFyZSBub3QgYmVp bmcgYWRkcmVzc2VkIGR1cmluZyB0aGUgY2FsbCBmb3IgYWRvcHRpb24uDQoNCkluIHNvbWUgZXh0 cmVtZSBjb25kaXRpb25zLCBpdCBtYXkgYmUgbmVjZXNzYXJ5IHRvIG1vZGlmeSB0aGUgdXN1YWwg Y2FsbCBmb3IgYWRvcHRpb24gcHJvY2VkdXJlLiBCdXQgdGhlc2UgZXhjZXB0aW9uYWwgY29uZGl0 aW9ucyBoYXZlIG5vdCBiZWVuIGFydGljdWxhdGVkLg0KDQpJdCBpcyB1bmZvcnR1bmF0ZSB0aGF0 IHR3byBvZiB0aGUgdGhyZWUgd29ya2luZyBncm91cCBjaGFpcnMgYXJlIGFsc28gY28tYXV0aG9y cyBvZiB0aGUgZHJhZnQuIFdoaWxlIHRoZXJlIG1heSBub3QgaGF2ZSBiZWVuIGFueSBpbXByb3By aWV0eSwgdGhlIGFwcGVhcmFuY2Ugb2YgaW1wcm9wcmlldHkgaXMgZGlmZmljdWx0IHRvIGF2b2lk Lg0KDQrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBSb24NCg0KDQoNCkp1bmlwZXIgQnVzaW5lc3MgVXNlIE9u bHkNCkZyb206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBK YW1lcyBHdWljaGFyZA0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDQsIDIwMjEgMTE6MTAgQU0NClRv OiBFWFQtQW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbSA8QW5kcmV3LkFsc3RvbkBsaXF1 aWR0ZWxlY29tLmNvbT47IFNQUklORyBXRyA8c3ByaW5nQGlldGYub3JnPg0KQ2M6IHNwcmluZy1j aGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBXRyBBZG9wdGlvbiBjYWxsIGZv ciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNw cmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8NCg0KW0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91 cyBvZiBjb250ZW50XQ0KDQpBbmRyZXcsDQoNCkFzIHN0YXRlZCBpbiBvdXIgZW1haWwgb2YgU2Vw dGVtYmVyIDl0aCwgdGhlIGNoYWlycyBjb21tdW5pY2F0ZWQgdGhhdCB0aGUgd29ya2luZyBncm91 cCByZWFjaGVkIHJvdWdoIChxdWl0ZSBjbGVhcikgY29uc2Vuc3VzIGZvciBzdGFuZGFyZGl6aW5n IG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uIHRvIGNvbXByZXNzIHNlZ21lbnQgcm91dGluZyBvdmVy IElQdjYuIEluIGFkZGl0aW9uIHRvIHRoaXMgdGhlcmUgd2FzIGFuIGluY2xpbmF0aW9uIHRvd2Fy ZCB1c2luZyB0aGUgQ1NJRCBkb2N1bWVudCBhcyB0aGUgYmFzaXMgZm9yIG91ciB3b3JrIGluIHRo aXMgYXJlYS4gVGhlIGNoYWlycyByZWNvZ25pemVkIHRoYXQgdGhlcmUgd2FzIGhvd2V2ZXIgZGlz YWdyZWVtZW50IGFzIHRvIHdoZXRoZXIgdGhpcyBkb2N1bWVudCwgaGF2aW5nIG11bHRpcGxlIFNS djYgRW5kUG9pbnQgYmVoYXZpb3JzLCBjb3VsZCBiZSBjb25zaWRlcmVkIGNvbnNpc3RlbnQgd2l0 aCB0aGUgd29ya2luZyBncm91cCBjb25zZW5zdXMgZm9yIGEgc2luZ2xlIGRhdGEgcGxhbmUgc29s dXRpb24uIFRoaXMgaXNzdWUgcXVpdGUgY2xlYXJseSBuZWVkZWQgdG8gYmUgYWRkcmVzc2VkLCBh bmQgdGhlIGNoYWlycywgcmVjb2duaXppbmcgdGhhdCB0aGUgd29ya2luZyBncm91cCBpcyBrZWVu IHRvIG1ha2UgcHJvZ3Jlc3MgaW4gdGhpcyBhcmVhLCBoYWQgdGhlIG9wdGlvbiBvZiB0cnlpbmcg dG8gcmVzb2x2ZSB0aGUgaXNzdWUgcHJpb3IgdG8gaXNzdWluZyBhbiBhZG9wdGlvbiBjYWxsLCBv ciBnaXZlIHRoZSB3b3JraW5nIGdyb3VwIHRoZSBvcHBvcnR1bml0eSB0byBleHByZXNzIHRoZWly IG9waW5pb25zIGFzIHBhcnQgb2YgYSBjYWxsIGZvciBhZG9wdGlvbi4NCg0KVGhvc2Ugd2hvIGZl ZWwgdGhhdCB3ZSBuZWVkIHRvIHJlc29sdmUgdGhlIGNvbnNpc3RlbmN5IGlzc3VlIGJlZm9yZSBh ZG9wdGlvbiwgYXMgd2l0aCB0aG9zZSB3aG8gdGhpbmsgdGhpcyBpcyBub3QgYSBnb29kIGJhc2lz IGZvciB0aGUgV0cgd29yaywgYXJlIGZyZWUgYW5kIGV4cGVjdGVkIHRvIG9iamVjdCB0byB0aGUg V0cgYWRvcHRpbmcgdGhlIGRvY3VtZW50LiBUaGF0IGlzIGRpc3RpbmN0IGZyb20gb2JqZWN0aW5n IHRvIHRoZSBjaGFpcnMgaXNzdWluZyB0aGUgYWRvcHRpb24gY2FsbC4NCg0KSW4gZXNzZW5jZSwg dGhlIGNoYWlycyBoYXZlIGNvbWJpbmVkIHRoZSBxdWVzdGlvbiBvZiB3aGVuIHRvIHJlc29sdmUg Y29uc2lzdGVuY3kgYW5kIHRoZSBxdWVzdGlvbiBvZiB3aGV0aGVyIHRoaXMgZG9jdW1lbnQgaXMg YSBnb29kIGJhc2lzIGZvciB0aGUgV0cgaW50byBvbmUgY2FsbC4NCg0KWW91cnMsDQoNCkppbSwg QnJ1bm8gJiBKb2VsDQoNCg0KRnJvbTogQW5kcmV3IEFsc3RvbiA8bWFpbHRvOkFuZHJldy5BbHN0 b25AbGlxdWlkdGVsZWNvbS5jb20+IA0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDEsIDIwMjEgNDoy MSBQTQ0KVG86IEphbWVzIEd1aWNoYXJkIDxtYWlsdG86amFtZXMubi5ndWljaGFyZEBmdXR1cmV3 ZWkuY29tPjsgU1BSSU5HIFdHIDxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KQ2M6IG1haWx0bzpz cHJpbmctY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogV0cgQWRvcHRpb24gY2FsbCBmb3Ig aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vX187ISFO RXQ2eU1hTy1nayFXbzJMNVkxT1ZBSmJieURQUlo3ZFdzb3RxQmhZLUxPTlY5TkRVY2c0U1E1YlE2 bmg5eXJZYmp2eEdxOEl3eU0kDQoNClNvcnJ5IOKAkyBidXQg4oCTIEnigJltIGEgbGl0dGxlIGNv bmZ1c2VkIGhlcmUuDQoNCkJlY2F1c2UgdGhlIHdheSBJIGxvb2sgYXQgdGhpcyDigJMgdGhlIHdv cmtpbmcgZ3JvdXAgY2xlYXJseSBzdGF0ZWQgdGhhdCB0aGV5IHdpc2hlZCBmb3IgYSBzaW5nbGUg YmVoYXZpb3Ig4oCTIGFuZCB0aGlzIOKAkyBkb2VzIG5vdCBkZWxpdmVyIHRoYXQg4oCTIGl0IGlz IHR3byBzZXBhcmF0ZSBiZWhhdmlvcnMuwqAgQXMgc3VjaCDigJMgSSBzZWUgdGhpcyBjYWxsIGZv ciBhZG9wdGlvbiDigJMgaXJyZXNwZWN0aXZlIG9mIHRoZSBtZXJpdHMgb3IgbGFjayB0aGVyZW9m IG9mIHRoZSBkcmFmdCwgYXMgYSBjbGVhciBkZWZpYW5jZSBvZiB0aGUgc3RhdGVkIHdpbGwgb2Yg dGhlIHdvcmtpbmcgZ3JvdXAuDQoNClRoaXMgaXMgc2ltcGx5IGRvZXMgbm90IGZpdCBpbnRvIHRo ZSBkZWZpbml0aW9uIG9mIGJvdHRvbSB1cCBhcHByb2FjaCBpbiBteSBvcGluaW9uIOKAkyBhbmQg aWYgdGhpcyBpcyB0aGUgd2F5IHRoYXQgdGhlIGNoYWlycyB3aXNoIHRvIHByb2NlZWQg4oCTIHRo ZW4gdGhlIG9ubHkgd2F5IHRvIGRvIHRoYXQgYW5kIHN0aWxsIGZpdCB3aXRoaW4gdGhlIGJvdHRv bSB1cCBhcHByb2FjaCBpcyB0byBmaXJzdCBhc2sgdGhpcyB3b3JraW5nIGdyb3VwIGZvciBpdHMg Y29uc2Vuc3VzIHRvIGRldmlhdGUgZnJvbSB0aGUgc2luZ2xlIGJlaGFjdmlvciBhcHByb2FjaCB0 aGF0IHRoZSB3b3JraW5nIGdyb3VwIGFncmVlZCB0by4NCg0KQXMgc3VjaCDigJMgSSBtdXN0IMKg c3Ryb25nbHkgYW5kIHVuZXF1aXZvY2FsbHkgb2JqZWN0IHRvIHRoaXMgY2FsbCBmb3IgYWRvcHRp b24NCg0KQW5kcmV3DQoNCkZyb206IHNwcmluZyA8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYu b3JnPiBvbiBiZWhhbGYgb2YgSmFtZXMgR3VpY2hhcmQgPG1haWx0bzpqYW1lcy5uLmd1aWNoYXJk QGZ1dHVyZXdlaS5jb20+DQpEYXRlOiBGcmlkYXksIDEgT2N0b2JlciAyMDIxIGF0IDE3OjA1DQpU bzogU1BSSU5HIFdHIDxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KQ2M6IG1haWx0bzpzcHJpbmct Y2hhaXJzQGlldGYub3JnIDxtYWlsdG86c3ByaW5nLWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6 IFtzcHJpbmddIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMv X19odHRwczovZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3By aW5nLXNydjYtc3JoLWNvbXByZXNzaW9uL19fOyEhTkV0NnlNYU8tZ2shVWdIZkN1T08xaUxvc2FG UDJXaW13Wkcwd1pzOEs0TTIwN3dMMnM0WExqVkExN2NJd3RENk1FRWs0WTYzS3AwLSQNCkRlYXIg V0c6DQoNClRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBleHByZXNzIHRoZWlyIGFwcHJlY2lhdGlv biBmb3IgYWxsIHRoZSByZXNwb25zZXMgcmVjZWl2ZWQgdG8gb3VyIGVtYWlscyB3aXRoIHJlZmVy ZW5jZSB0byBob3cgdGhlIHdvcmtpbmcgZ3JvdXAgd2lzaGVzIHRvIG1vdmUgZm9yd2FyZCB3aXRo IHJlc3BlY3QgdG8gYSBzb2x1dGlvbiBmb3IgU1J2NiBjb21wcmVzc2lvbi4gDQoNClRoZSBhcHBh cmVudCBpbmNsaW5hdGlvbiBvZiB0aGUgd29ya2luZyBncm91cCBpcyB0byB1c2UgaHR0cHM6Ly91 cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi9uYW0xMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzKjNBKjJGKjJGZGF0YXRyYWNrZXIuaWV0Zi5vcmcqMkZkb2MqMkZk cmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbioyRiZkYXRhPTA0 KjdDMDEqN0NqYW1lcy5uLmd1aWNoYXJkKjQwZnV0dXJld2VpLmNvbSo3QzVlMGQwZmRiODQ0MDRi NTM1MTcxMDhkOTg1MTkwNzVmKjdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMqN0Mx KjdDMCo3QzYzNzY4NzE2NDgxNjQ5NjA1Mio3Q1Vua25vd24qN0NUV0ZwYkdac2IzZDhleUpXSWpv aU1DNHdMakF3TURBaUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAq M0QqN0MxMDAwJnNkYXRhPSoyQlZzTDkqMkJIZ3lpUUxiNyoyRm9BWTQzN1ZlazRiaEhXTXJsM0tk b1RQYkFuR1UqM0QmcmVzZXJ2ZWQ9MF9fO0pTVWxKU1VsSlNVbEpTVWxKU1VsSlNVbEpTVWxKUSEh TkV0NnlNYU8tZ2shVWdIZkN1T08xaUxvc2FGUDJXaW13Wkcwd1pzOEs0TTIwN3dMMnM0WExqVkEx N2NJd3RENk1FRWs0Zk4zTzBlTSQgYXMgdGhlIGJhc2lzIGZvciBpdHMgY29tcHJlc3Npb24gc3Rh bmRhcmRpemF0aW9uIHdvcmsuIFRoYXQgaXMgcGFydCBvZiB3aGF0IHRoaXMgZW1haWwgYXR0ZW1w dHMgdG8gY29uZmlybS4NCg0KQmVjYXVzZSBvZiB0aGUgYWJvdmUgdGhlIGNoYWlycyB3b3VsZCBs aWtlIHRvIGlzc3VlIGEgMi13ZWVrIFdHIGNhbGwgZm9yIGFkb3B0aW9uIGVuZGluZyBPY3RvYmVy IDE1dGggZm9yIGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovbmFtMTEuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyozQSoyRioyRmRhdGF0cmFja2Vy LmlldGYub3JnKjJGZG9jKjJGZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29t cHJlc3Npb24qMkYmZGF0YT0wNCo3QzAxKjdDamFtZXMubi5ndWljaGFyZCo0MGZ1dHVyZXdlaS5j b20qN0M1ZTBkMGZkYjg0NDA0YjUzNTE3MTA4ZDk4NTE5MDc1Zio3QzBmZWU4ZmYyYTNiMjQwMTg5 Yzc1M2ExZDU1OTFmZWRjKjdDMSo3QzAqN0M2Mzc2ODcxNjQ4MTY1MDYwNDYqN0NVbmtub3duKjdD VFdGcGJHWnNiM2Q4ZXlKV0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJ azFoYVd3aUxDSlhWQ0k2TW4wKjNEKjdDMTAwMCZzZGF0YT02N090MzJtSEVxejBKWENjMDEqMkJ1 STZJMVdQT3pyd3JDVEVwM3JwOWNWRTgqM0QmcmVzZXJ2ZWQ9MF9fO0pTVWxKU1VsSlNVbEpTVWxK U1VsSlNVbEpTVSEhTkV0NnlNYU8tZ2shVWdIZkN1T08xaUxvc2FGUDJXaW13Wkcwd1pzOEs0TTIw N3dMMnM0WExqVkExN2NJd3RENk1FRWs0ZGluQzhSeSQgYnV0IHdpdGggc29tZSBjbGVhciBndWlk ZWxpbmVzIGFzIGZvbGxvd3MuIEJ5IGV4cHJlc3Npbmcgc3VwcG9ydCBmb3IgYWRvcHRpb24gb2Yg dGhpcyBkb2N1bWVudCB5b3UgYXJlIGZ1bGx5IGF3YXJlIG9mIGFuZCBhcmUgYWNrbm93bGVkZ2lu ZyB0aGF0OiANCg0KMS4gVGhlIFNQUklORyB3b3JraW5nIGdyb3VwIGlzIGFkb3B0aW5nIGEgZG9j dW1lbnQgdGhhdCBoYXMgbXVsdGlwbGUgU1J2NiBFbmRwb2ludCBiZWhhdmlvcnMuIA0KMi4gVGhl IGRvY3VtZW50IGlzIGEg4oCcbGl2aW5n4oCdIGRvY3VtZW50OyBpdCBtYXkgY2hhbmdlIGFzIGl0 IGdvZXMgdGhyb3VnaCByZXZpZXcgYW5kIGFuYWx5c2lzIGJ5IHRoZSBTUFJJTkcgd29ya2luZyBn cm91cC4gDQozLiBBbGwgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyByYWlzZWQgb24gb3VyIG1haWxp bmcgbGlzdCBNVVNUIGJlIGFkZHJlc3NlZCBCRUZPUkUgc2FpZCBkb2N1bWVudCBpcyBhbGxvd2Vk IHRvIHByb2dyZXNzIGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAgdG8gcHVibGljYXRpb24uIEEgbGlz dCBvZiB0aGVzZSBkaXNjdXNzaW9uIHBvaW50cyB3aWxsIGJlIGRvY3VtZW50ZWQgaW4gdGhlIFdH IGRvY3VtZW50IGFuZCBtYWludGFpbmVkIGJ5IHRoZSBkb2N1bWVudCBlZGl0b3IgaW4gY29uanVu Y3Rpb24gd2l0aCB0aGUgY2hhaXJzLiANCjQuIElmIHRoaXMgZG9jdW1lbnQgaXMgYWRvcHRlZCBi eSB0aGUgd29ya2luZyBncm91cCwgdGhlIGNoYWlycyBzcGVjaWZ5IGFzIHBhcnQgb2YgdGhlIGFk b3B0aW9uIGNhbGwgdGhhdCB0aGUgZm9sbG93aW5nIHRleHQgZGVzY3JpYmluZyBhbiBvcGVuIGlz c3VlIGJlIGFkZGVkIHRvIHRoZSBkb2N1bWVudCBpbiB0aGUgYWJvdmUtZGVzY3JpYmVkIG9wZW4g aXNzdWVzIHNlY3Rpb246DQrigKIgIkdpdmVuIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHNh aWQgdGhhdCBpdCB3YW50cyB0byBzdGFuZGFyZGl6ZSBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiwg YW5kIGdpdmVuIHRoYXQgdGhlIGRvY3VtZW50IGNvbnRhaW5zIG11bHRpcGxlIFNSdjYgRW5kUG9p bnQgYmVoYXZpb3JzIHRoYXQgc29tZSBXRyBtZW1iZXJzIGhhdmUgc3RhdGVkIGFyZSBtdWx0aXBs ZSBkYXRhIHBsYW5lIHNvbHV0aW9ucywgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhZGRyZXNzIHdo ZXRoZXIgdGhpcyBpcyB2YWxpZCBhbmQgY29oZXJlbnQgd2l0aCBpdHMgb25lIGRhdGEgcGxhbmUg c29sdXRpb24gb2JqZWN0aXZlLiIuDQoNClBsZWFzZSBjb25zaWRlciB0aGUgYWJvdmUgZ3VpZGVs aW5lcyBhcyB5b3UgZGVjaWRlIG9uIHdoZXRoZXIgdG8gc3VwcG9ydCBvciBub3QgdGhpcyBXRyBh ZG9wdGlvbi4gUGxlYXNlIGV4cHJlc3MgY2xlYXJseSB5b3VyIHJlYXNvbmluZyBmb3Igc3VwcG9y dC9ub24tc3VwcG9ydCBhcyB3ZWxsIGFzIGFueSBvcGVuIGRpc2N1c3Npb24gcG9pbnRzIHlvdSB3 b3VsZCBsaWtlIGFkZHJlc3NlZCBzaG91bGQgdGhlIGRvY3VtZW50IGJlIGFkb3B0ZWQgaW50byB0 aGUgd29ya2luZyBncm91cC4NCg0KVGhhbmtzIQ0KDQpKaW0sIEJydW5vICYgSm9lbA0KDQoNCg0K From nobody Fri Oct 8 04:03:16 2021 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 CE6103A1641; Fri, 8 Oct 2021 04:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.352 X-Spam-Level: X-Spam-Status: No, score=-2.352 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, 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 NShwNejtIf8h; Fri, 8 Oct 2021 04:03:08 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2128.outbound.protection.outlook.com [40.107.22.128]) (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 81D8F3A163D; Fri, 8 Oct 2021 04:03:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a58v1exWyWO2/QWlo7q8KygccftQrS3tHgZGVjO9UFSrp5SxVu1Rp2RsMo5CealFkZTKZYFmgJvudiusvOqomCfyyQYx80uKUTNNgIxfeALLK043tbrVSTu84/mLwk1DoTL+4H7LiGepMb2Y/H5bvI6U3V/QHZ5q2smmefdaTWOrC9TbOIe/hTHyuSznTYelVRdmoibUpZsyJd0Qm/UwL6HduzaNLgdq/VDm0XKfaKigZbD1uiYqSFDEmmRaM1HKTetbI2kffBUEFQkMXUnj8Jb/WLLlS1BB1R2bdAwNwhmGbvO3x/h5q3QoScCjxEnuPk99hfEYfHUV2kA/QOwrfQ== 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=nII1wtU+7WRH54o2KFlaaLaV4O4dBMTN8YoncZjv+g0=; b=NDJds62IqdYyjGXjRttCcMIGG0OKTlQ8ZmaTBqy1/DMm4KXc95UdT2shrR7zbVKSLN8JONQmdzeO7TN8gXEXEaE1iOqOpAvEWKixfv/Bd8AqqMf5ZwY9re7fFTZkr8eGACJ/7AMQ3Avw9UxmpY/INS1JZEge8FowxAm0Eb2eOLEnDGt+0BbWDOCDeDL0bzCthhH43NTor3TvuHbQWWm1Y78CsWeKz6in8xL8tfusC+pWD3PU9IogGj4voir3oEbeLf0pvFf9I9pDYCwQFumkAqn5/xe3IOnB+H8vCk3qUbgDOiHUx9YvS4w3QqXclTiRrhHJN78dBIAyW/V2h0LaJg== 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=nII1wtU+7WRH54o2KFlaaLaV4O4dBMTN8YoncZjv+g0=; b=muv9lW6XPCP7NA93Ls0xfSkee644CicaLY1QidL1bIEdlngR4jCH1imYBeP/wulu50eDwWb7n2s0J0VlDNz0roMaOvC5RPz9wdjOiiq++deGpNV8uyxaf3gPPqfgCPn9BSlEVSTlcHc0gN6Ivi/scZ5tnMDLy/pFWIiKiXjzDIY= Received: from AM8PR07MB8044.eurprd07.prod.outlook.com (2603:10a6:20b:3db::15) by AM9PR07MB7762.eurprd07.prod.outlook.com (2603:10a6:20b:307::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.13; Fri, 8 Oct 2021 11:02:59 +0000 Received: from AM8PR07MB8044.eurprd07.prod.outlook.com ([fe80::b0f2:52db:aee:c711]) by AM8PR07MB8044.eurprd07.prod.outlook.com ([fe80::b0f2:52db:aee:c711%7]) with mapi id 15.20.4566.007; Fri, 8 Oct 2021 11:02:59 +0000 From: "Sales, Bernard (Nokia - BE/Antwerp)" To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQFZ7emw Date: Fri, 8 Oct 2021 11:02:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=nokia.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 85261c51-572a-48f5-0847-08d98a4b3094 x-ms-traffictypediagnostic: AM9PR07MB7762: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5hOLsj/EdfKMm4dsLqS9RqML78eE6wz9TdBIrwvYx+dnUAVpxoKJJeyTfdfo5Qu+o8rUbyKuweTgHigToU8kiEl1zNEXvi7q9hSlR8WfCvuovnSS09B+jvStQUf2VPLKSoC9VmhdiQfvFFUe/BRhYM01lranuP90DJeIbLMXAUrSnk6WoUJ2W/eRKPUrP2eh4AaJbZtqD3+Wlj5gYqMA9WVBo/rJqP6KV0LwJTWMkFXKlbB+LpQSDRoc+T9FwC6X40chQ6mbW6ODVYCCAc0q9VFQL1P5M14ebhd7SLTGeZcLeqIgBUAVqgualmWD0chvibtbUPHAk9Jq+iUHFeI+mDQB7UDMMjWxJbi1Za7WJMYyF9itdW5lco5JwFUzRei8dEUQ7J6T6L7R7tP0/Tup8VBMsyD0oi0YauDIEz7iMEF90ybyF0TMPtSgFY4lcngZEPXMzW8KFFoqB7UAfoK3K1gr53xT0U4DMCuKuWooocfu7S6kxxCF008tuuHcHpbXk3nQCLp63YIHo/bVoUfhYeaDj5B7RHldIEZP0jYcsYkdSIUtACMuqp9vH83u/b5MiNYuQUGQZs1hpYMAkk1v6JPJlQQXfu/2m6JqKU/daF2yUPyaXBgjpZvOPBlwF+g6fojQwgnfUv1ARCD5dDi3eqW7POmod7m71U68AMqxJqh8i6oR66lgKJlM+G5CPNb4m6tG90ZFALOZnhpkA2DZ2rrrEcbspUI65gFFK/oY+YnG3Yvjzw0viaYiuAj+vcntGo3AADGgJq5fieWrcWJTO8CFf6181KtNs+4IfkqyRNI= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM8PR07MB8044.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(8936002)(7696005)(64756008)(86362001)(66446008)(186003)(6506007)(53546011)(66476007)(122000001)(38100700002)(66946007)(66556008)(966005)(166002)(76116006)(508600001)(33656002)(316002)(8676002)(4326008)(83380400001)(55016002)(2906002)(52536014)(9686003)(5660300002)(71200400001)(38070700005)(110136005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?P9Zzc8jXqDkPFLxG9QwwDJOW0p9ngIGGPfEkBwltMVSpMb7uxKWaoyhVO8+9?= =?us-ascii?Q?7XXYrmuOz8PjS1ihMJFMI9w5XImBkMFbzSi3lKRJGCqewllkdVhRpN4aLNuG?= =?us-ascii?Q?A/Tn4Vl+bMUY2zVXKbN0a11pUW2p+y+CBq9y5bDUgl9O3TCEvdJvyiV8SSXH?= =?us-ascii?Q?FbboRHr2RiHOyVO6nPVWuSExd7ygFM0XOdWAPzDhlOXQmwefFch49DG2+32+?= =?us-ascii?Q?9UrRgD8EOTaGPAaCpo5VuqXEFHXVTvlyXoMn1r7VYPS/MHvldzXvMHSsG9V+?= =?us-ascii?Q?LcJH7AJDH0E2B70j0miRXLA8RG0rtqV0oXRX641Csl5OD+H5frff3EZS+vmZ?= =?us-ascii?Q?JbQPTazO9gqx00UYTblzjGdAbxxZZSkUiHCLWcD2g31g7YsvGFK5jChqgjA/?= =?us-ascii?Q?ZBOTzMTR4QE+FNBbNi4ESixZcXzvdk6JxhmNGSvyBoLmUFSW7RLPoZJ7Kajn?= =?us-ascii?Q?F0/FHdQ/KovuVwyjsIfNeWjGCt+NJ2mYfWEC+H5I8V19pLOzswdJZCoRh71h?= =?us-ascii?Q?xC3kspCA9XGflwtfpSlZRlLJNCwWUPEakA/WDcKW+DmYHE04rGhLbnzvCspM?= =?us-ascii?Q?+PJ/GVQxS8K8qN19PMkrZ2/uvSwYqaF/ZPg787qCFmO0szKC3mWrCbvvdryu?= =?us-ascii?Q?YwxqK9zmJG7oZETRf8PlivEWDGEfldEPCd9c6MYPeD7JKD5DGJhsykWDXIkq?= =?us-ascii?Q?JKbO6seOxdk5LxrW0aD6V0tXQM1d+mvXh/aI//inFNmRq6zFbCVs986bcmNW?= =?us-ascii?Q?0YNvXmuoNhIhut5ibuSHmdEzYffRcOoBWv/oRMXU8o15stWuXRgIaaa5kwK8?= =?us-ascii?Q?oEVUrrdmxcT+B/P1RkC8c5NRpALaOmSFPTDjrTI82D3gBk4ANUic094oePan?= =?us-ascii?Q?qFHPKOIuZi06r4yEZi+xs69O3aSMUk2r0c7vVa4b3sM9VNW102UmGRSedYPB?= =?us-ascii?Q?OiQz4pvXjo1aAOtHf5kcJWDyXEQvPTSuCxvlkHZm9CgvPh3ie4hfnUGGaT2s?= =?us-ascii?Q?XcEv3tqxV7Lpm9tdGiLiXJZuPSCV3bE3VC/1eKQr/FX+0HfG1H11IuXGscPr?= =?us-ascii?Q?3dY11Dmxo1NCDSRFtE7UjklQX1uCUuMWrNDBBpUIydTHaSz7luap2eJ2Dsvv?= =?us-ascii?Q?/Jul4kXbEtZSKudRay/ONCj6X4VHtd/JvxjALWM09AFQrXEM7Bt/In3KK4zu?= =?us-ascii?Q?PIW6PhRH3VkIpKueuRozHmHczwzEFUnVjXRUwDgA+t/ZnDVPLxqkVR9A5goX?= =?us-ascii?Q?X1CbC48mz9tLc4G3rj9Cj9zVX8ggrmo+tT1M5ejA9vgFc40zltgRsJBP4G0v?= =?us-ascii?Q?9vUzR9E/p0cQdJjpseRhW2rIGmDqhCNYo6mbySnO55j4tAwYM4rluQk7M7Bs?= =?us-ascii?Q?YMjcglXPMXsuJCmj4B2dUB1pvpRI?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM8PR07MB8044702269CF8FBA62469F43FDB29AM8PR07MB8044eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM8PR07MB8044.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 85261c51-572a-48f5-0847-08d98a4b3094 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2021 11:02:59.0330 (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: hoEuVS1wAh1CD8utknDEeG4fqeVsQa0NWCZfgbHLPjlvsYq8zw9JD+t0T9Ph+3TwY0RDdIa2pmRTQWNYDfUMIw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR07MB7762 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 08 Oct 2021 11:03:14 -0000 --_000_AM8PR07MB8044702269CF8FBA62469F43FDB29AM8PR07MB8044eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I support the adoption of https://datatracker.ietf.org/doc/draft-filsfilsch= eng-spring-srv6-srh-compression/. Many Thanks, -- Brd From: spring On Behalf Of James Guichard Sent: Friday, October 1, 2021 4:05 PM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_AM8PR07MB8044702269CF8FBA62469F43FDB29AM8PR07MB8044eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

&nbs= p;

I support the adoption of https://datatracker.ietf.org= /doc/draft-filsfilscheng-spring-srv6-srh-compression/.

 

Many Thanks,<= /p>

 

-- Brd

 

From: spring <spring-bounces@ietf.org> On Behalf Of James Guichard
Sent: Friday, October 1, 2021 4:05 PM
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

 

Dear WG:

 

The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a sol= ution for SRv6 compression.

 

The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document = that has multiple SRv6 Endpoint behaviors.
  2. The document is a “= living” document; it may change as it goes through review and analysi= s by the SPRING working group.
  3. All open discussion point= s raised on our mailing list MUST be addressed BEFORE said document is allo= wed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maint= ained by the document editor in conjunction with the chairs.
  4. If this document is adopt= ed by the working group, the chairs specify as part of the adoption call th= at the following text describing an open issue be added to the document in the above-described open issues section:
    • "Given that the working group has said that it wants to standar= dize one data plane solution, and given that the document contains multiple= SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution obj= ective.".

 

Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open d= iscussion points you would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

--_000_AM8PR07MB8044702269CF8FBA62469F43FDB29AM8PR07MB8044eurp_-- From giulio.sidoretti@uniroma2.it Fri Oct 8 06:00:21 2021 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 57AC63A1712; Fri, 8 Oct 2021 06:00:21 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=uniroma2.it header.b=CsL+g0/3; dkim=pass (2048-bit key) header.d=uniroma2.it header.b=Kucn4fXh 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 J5qoeNAIFJIv; Fri, 8 Oct 2021 06:00:13 -0700 (PDT) Received: from smtp.uniroma2.it (smtp.uniroma2.it [160.80.6.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 B78223A170D; Fri, 8 Oct 2021 06:00:10 -0700 (PDT) Received: from smtpauth-2019-1.uniroma2.it (smtpauth.uniroma2.it [160.80.5.46]) by smtp-2015.uniroma2.it (8.14.4/8.14.4/Debian-8) with ESMTP id 198D017M013866; Fri, 8 Oct 2021 15:00:07 +0200 Received: from smtpclient.apple (host-80-183-113-211.business.telecomitalia.it [80.183.113.211]) by smtpauth-2019-1.uniroma2.it (Postfix) with ESMTPSA id B8235121E2E; Fri, 8 Oct 2021 14:59:56 +0200 (CEST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=uniroma2.it; s=ed201904; t=1633697996; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=riFARlNYhuOEJSiXykNP/NP1CZoob9XvFfmkcUNh2cg=; b=CsL+g0/3ZTrmor4V3YfyssOi/lZubv/+oTJfMiOECjJKBaGnKkbkSz/LyW3ZaMI1OC7NUw tj6WL4OevI392SAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniroma2.it; s=rsa201904; t=1633697996; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=riFARlNYhuOEJSiXykNP/NP1CZoob9XvFfmkcUNh2cg=; b=Kucn4fXhITBpfDDNh4MJ/gKuLYNrCwKaHnf6Cp8ehhi3kTGzham2O86ULiZTJXab0ROoGJ c9uPyF6STjUJGC84NzURzrY7qKtAJcDbK3x3vl372A26V53mhrCSvKdDUWZC3pMZ6H2m+5 t4UuLwT2shJJfeqGbH0Xw9y3r1IKR7yB9fIfuJ9UyrYI/1WJZ8APtjdb5IQpcpbGkBrXjf Y/3EAOpGXp2uS58nHvN5aiG3WXtuUntglzOZYhKLKlN2tpC08Tk9x/6AnO1kcjmFmJEwW5 3S+WBsGjAxOUj7xgCcaKs6FtlIgSEp6c/AFh8Q1Bvil1WAlDRSNgoeIEPoJOxw== From: Giulio Sidoretti Content-Type: multipart/alternative; boundary="Apple-Mail=_5CEF023D-5B5C-477B-8169-66B69F983427" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Fri, 8 Oct 2021 14:59:55 +0200 References: To: spring-chairs@ietf.org, spring@ietf.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.3654.100.0.2.22) X-Virus-Scanned: clamav-milter 0.100.0 at smtp-2015 X-Virus-Status: Clean Archived-At: X-Mailman-Approved-At: Fri, 08 Oct 2021 06:18:57 -0700 Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 08 Oct 2021 13:03:31 -0000 --Apple-Mail=_5CEF023D-5B5C-477B-8169-66B69F983427 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi WG, WG chairs, I support the WG adoption of the draft. I have been working with SRv6 as part of my PhD. My team focuses on SRv6 = implementation in Linux and other open source stacks like VPP, eBPF and = others. The CSID draft is compliant with RFC 8986. We read the documents = from the design team (DT) and we understand the benefit of the flavours = defined in the CSID draft for different deployments. Kind regards, Giulio Sidoretti > On 1 Oct 2021, at 16:04, James Guichard = wrote: >=20 > Dear WG: > =20 > The chairs would like to express their appreciation for all the = responses received to our emails with reference to how the working group = wishes to move forward with respect to a solution for SRv6 compression.=20= > =20 > The apparent inclination of the working group is to use = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = as the basis for its compression standardization work. That is = part of what this email attempts to confirm. > =20 > Because of the above the chairs would like to issue a 2-week WG call = for adoption ending October 15thfor = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = but with some clear guidelines as follows. By expressing = support for adoption of this document you are fully aware of and are = acknowledging that:=20 > =20 > The SPRING working group is adopting a document that has multiple SRv6 = Endpoint behaviors.=20 > The document is a =E2=80=9Cliving=E2=80=9D document; it may change as = it goes through review and analysis by the SPRING working group.=20 > All open discussion points raised on our mailing list MUST be = addressed BEFORE said document is allowed to progress from the working = group to publication. A list of these discussion points will be = documented in the WG document and maintained by the document editor in = conjunction with the chairs.=20 > If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open = issue be added to the document in the above-described open issues = section: > "Given that the working group has said that it wants to standardize = one data plane solution, and given that the document contains multiple = SRv6 EndPoint behaviors that some WG members have stated are multiple = data plane solutions, the working group will address whether this is = valid and coherent with its one data plane solution objective.". > =20 > Please consider the above guidelines as you decide on whether to = support or not this WG adoption. Please express clearly your reasoning = for support/non-support as well as any open discussion points you would = like addressed should the document be adopted into the working group. > =20 > Thanks! > =20 > Jim, Bruno & Joel > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring = --Apple-Mail=_5CEF023D-5B5C-477B-8169-66B69F983427 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = WG, WG chairs,

I support the WG adoption of the draft.

I have been working with = SRv6 as part of my PhD. My team focuses on SRv6 implementation in Linux = and other open source stacks like VPP, eBPF and others. The CSID draft = is compliant with RFC 8986. We read the documents from the design team = (DT) and we understand the benefit of the flavours defined in the CSID = draft for different deployments.

Kind regards,
Giulio = Sidoretti

On 1 Oct 2021, at 16:04, James Guichard = <james.n.guichard@futurewei.com> wrote:

Dear WG:
 
The chairs would like to express their = appreciation for all the responses received to our emails with reference = to how the working group wishes to move forward with respect to a = solution for SRv6 compression. 
 
The apparent inclination = of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ as the basis for its = compression standardization work. That is part of what this email = attempts to confirm.
 
Because of the above the = chairs would like to issue a 2-week WG call for adoption ending October = 15thfor https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ but with some clear = guidelines as follows. By expressing support for adoption of this = document you are fully aware of and are acknowledging that: 
 
  1. The SPRING working group is adopting = a document that has multiple SRv6 Endpoint behaviors. 
  2. The document is = a =E2=80=9Cliving=E2=80=9D document; it may change as it goes through = review and analysis by the SPRING working group. 
  3. All open = discussion points raised on our mailing list MUST be addressed BEFORE = said document is allowed to progress from the working group to = publication. A list of these discussion points will be documented in the = WG document and maintained by the document editor in conjunction with = the chairs. 
  4. If this = document is adopted by the working group, the chairs specify as part of = the adoption call that the following text describing an open issue be = added to the document in the above-described open issues section:
    • "Given that the = working group has said that it wants to standardize one data plane = solution, and given that the document contains multiple SRv6 EndPoint = behaviors that some WG members have stated are multiple data plane = solutions, the working group will address whether this is valid and = coherent with its one data plane solution objective.".
 
Please consider the above = guidelines as you decide on whether to support or not this WG adoption. = Please express clearly your reasoning for support/non-support as well as = any open discussion points you would like addressed should the document = be adopted into the working group.
 
Thanks!
 
Jim, Bruno & Joel
 
 
_______________________________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

= --Apple-Mail=_5CEF023D-5B5C-477B-8169-66B69F983427-- From nobody Fri Oct 8 07:30:37 2021 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 776923A08B6 for ; Fri, 8 Oct 2021 07:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=lab.dtag.de 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 sHrk68VoZGg3 for ; Fri, 8 Oct 2021 07:30:07 -0700 (PDT) Received: from darkmatter.lab.dtag.de (DarkMatter.lab.DTAG.de [194.25.1.34]) (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 4E9023A08A9 for ; Fri, 8 Oct 2021 07:30:06 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id AD7E7C02A9 for ; Fri, 8 Oct 2021 16:29:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lab.dtag.de; s=dkim; t=1633703365; h=from:subject:date:message-id:to:mime-version:content-type: content-transfer-encoding:in-reply-to:references; bh=6VkWH6mf6ReiIszQ7nNIEFWcfuyS1RFQsc3+hvTTObQ=; b=lJrqEnklulZV5vhMe4emrZmmtvPNYiebtWNUc5JET485h+pJV34bFwU2HhAG3SxsyaEV4l qwxiLQxxrosjWexgcGGK6WDKhcFyV1YnN2f6xD/1vi4B+RvgHcI/9qU7AVCLKehx5R31ol fIpY9THNKzdLEb1JP7ZEocIRg1jmzwta+jNyUbdTdLFNFmjG0EgoIGpquKHa42XH+Ze3oy C91cKB3ZLVas4N1rf4Nefxl+KSxFVqqMTqFeJgOkn0H1u1/dUoEUau0r+exr6Jc3TYux+w bjCzrI/MQx1cDNbphTAsRI8qXyjPYPrvIDWkpCn//u0qjNCsHBXG7UdVvwv1qA== To: spring@ietf.org References: From: Martin Horneffer Message-ID: <3645ab6f-233e-390c-02a3-52ea6273bb93@lab.dtag.de> Date: Fri, 8 Oct 2021 16:29:15 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Last-TLS-Session-Version: TLSv1.3 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 08 Oct 2021 14:30:14 -0000 Hello everyone, as I see it, the document fits well into the framework of RFC8986, it solved the problem, and does so in an efficient manner. Thus I support the adoption of this document. Best rergards, Martin Am 01.10.21 um 16:04 schrieb James Guichard: > Dear WG: > > The chairs would like to express their appreciation for all the > responses received to our emails with reference to how the working group > wishes to move forward with respect to a solution for SRv6 compression. > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > as the basis for its compression standardization work. That is part of > what this email attempts to confirm. > > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15^th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging > that: > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a living document; it may change as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the > working group to publication. A list of these discussion points will > be documented in the WG document and maintained by the document > editor in conjunction with the chairs. > 4. If this document is adopted by the working group, the chairs specify > as part of the adoption call that the following text describing an > open issue be added to the document in the above-described open > issues section: > * "Given that the working group has said that it wants to > standardize one data plane solution, and given that the document > contains multiple SRv6 EndPoint behaviors that some WG members > have stated are multiple data plane solutions, the working group > will address whether this is valid and coherent with its one > data plane solution objective.". > > Please consider the above guidelines as you decide on whether to support > or not this WG adoption. Please express clearly your reasoning for > support/non-support as well as any open discussion points you would like > addressed should the document be adopted into the working group. > > Thanks! > > Jim, Bruno & Joel > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > From nobody Fri Oct 8 07:47:38 2021 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 D8F1B3A0962 for ; Fri, 8 Oct 2021 07:47:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20210112.gappssmtp.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 84qLE0_QbdZg for ; Fri, 8 Oct 2021 07:47:23 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 0BF023A0917 for ; Fri, 8 Oct 2021 07:46:54 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id t16so15471741eds.9 for ; Fri, 08 Oct 2021 07:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lL2+DxQ7Fs+iK4+b1W0MuqcmRBpx5ZW/k5AYcyTpExk=; b=abCw53BNfgl5IJyesZJsqOISbQspj6gCYoOi5ptXDrQ42crOqts8P2alxE1ToBUOtI xxWAnQ0udu465nI9BxkUSB1ZLSZiEMYBcsnEZtdOylQ0aA69UD2mhS1I4v7ZwcpldJbV q2GY8EkYAp3lNBdeOYMOva0Hczt3qc69/YVI3tRlzMwvp79i8e5d4vLXw241WIaosBzY UZLPkIel0kXh6s908MWzpwnNcjtHyMkc4soH/oTAWH6Fiif++jfCQ5ur06xVdafMDe0G Tn0iiYO8kIS127pbCV7W/SZSnVLHd+ABgt6TR7w4uEpaViiD97V4DSwJFoYv78RAlSjt buEg== 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=lL2+DxQ7Fs+iK4+b1W0MuqcmRBpx5ZW/k5AYcyTpExk=; b=HRlvYLfwLwewSjXzhSw+hnwOP+tJWuXK9RVMIv6o1eYY5gB1aona/teULGR5FWMDjf moH+I63QMYFlY+E0cZUfWA2iNEZztrXwV5zu0Bt9kuXI0GB/31U8NcSEFv2DGPFXhD+8 vMwIs+9+y2yLcbNl570y1lJDIs2Kl2c7VKKG+pZFG8oQjJm6ErRaBDpA90ZiwxpjbDeD s/yUrSCUFa22yTdPv+9vmKyfUAmMgEZOlzvi0pzwokWO6iU25GlWqwYR2yU65GtdYvUZ HHnGwgbrhus+FJIjBecOKBHKU5eeuRCfaeylavwavEWJpU7WOaUg1nNPjlDdYeslgEGK 5Wew== X-Gm-Message-State: AOAM532Rk4BlIeSv5QS29i7PLVetyTcDh0hmFGTmpushwlj33jFpMI/Y jVZcNC10PHZGV5HU0ib/jTkA1W2D8yOYJAJ0zZlCDw== X-Google-Smtp-Source: ABdhPJxgm6NpXaGM+QejkAYudez2GXNRGcxdmJdGrMUa41XtWS4ByPwEhr9HUlXcB3389Bf6Kd5o2s63E2RwXotZ/5A= X-Received: by 2002:a50:e384:: with SMTP id b4mr15605129edm.314.1633704410859; Fri, 08 Oct 2021 07:46:50 -0700 (PDT) MIME-Version: 1.0 References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> In-Reply-To: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> From: Tom Herbert Date: Fri, 8 Oct 2021 07:46:39 -0700 Message-ID: To: Vasilenko Eduard Cc: Ron Bonica , Eduard Metz , SPRING WG , 6MAN <6man@ietf.org> Content-Type: multipart/alternative; boundary="00000000000013debf05cdd87392" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 08 Oct 2021 14:47:35 -0000 --00000000000013debf05cdd87392 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 8, 2021 at 1:38 AM Vasilenko Eduard wrote: > > =C3=98 By contrast, a Compressed SID Container (i.e., the 128-bit entity = that is copied into the IPv6 Destination Address field) represents an entire SR Path. Specifically, it represents *many* functions that reside on *many* nodes > > > > But CSID is not an IP address, right? Why IP address rules should be applicable to CSID? > Eduard, If the protocol is copying the CSI into the IPv6 Destination address the CSI MUST be an IP address because the Destination Address field in an IPv6 packet *contains* an IPv6 address. Overloading fields in the IPv6 header with other data would be non-conformant with the IPv6 standard (not just addresses, see the several attempts to structure flow label for instance). Frankly, this is one thing that I have found troubling with SrRv6. Sometimes it is portrayed as an alternative, shadow protocol to IPv6 that just happens to use the IPv6 protocol format for convenience instead of creating a new L3 protocol for its purposes. The rationalization for this seems to be that SRv6 is confined to limited domains, and within a limited domain we can safely redefine standard protocols in arbitrary ways-- note, there is no consensus that that philosophy is acceptable. Tom > > > From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ron Bonica > Sent: Thursday, October 7, 2021 10:36 PM > To: Eduard Metz > Cc: SPRING WG ; 6man@ietf.org > Subject: RE: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 > > > > > > Inline [RB] > > > > Ron > > > > > > Juniper Business Use Only > > From: Eduard Metz > Sent: Thursday, October 7, 2021 5:03 AM > To: Ron Bonica > Cc: 6man@ietf.org; SPRING WG > Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 > > > > [External Email. Be cautious of content] > > > > > > Can the SID be viewed as the address of the "interface" to, in this case, the function that resides in a node? From a routing / forwarding point of view the group of functions is more similar to a network (represented by a prefix, rather than a single address), but still. > > > > [RB] In RFC 8986, a classic SRv6 SID represents a *single* function that resides on a *single* node. If you like, you can even say that represents a *single* interface to a *single* function that resides on a *single* node. > > > > By contrast, a Compressed SID Container (i.e., the 128-bit entity that is copied into the IPv6 Destination Address field) represents an entire SR Path. Specifically, it represents *many* functions that reside on *many* nodes > > > > > > For my understanding, apart from that the (definition of) SID may not be aligned with the literal text in below RFCs, what is the real problem? Are there any protocols that specifically rely on this definition of an IPv6 address? > > > > [RB] We don=E2=80=99t know if there are any protocols that rely on this definition of the IPv6 address. And if we don=E2=80=99t update RFC 4291 bef= ore violating it, we don=E2=80=99t know if anybody might write such an applicat= ion in the future. > > > > Ron > > > > > > cheers, > > Eduard > > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --00000000000013debf05cdd87392 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Oct 8, 2021 at 1:38 AM Vasilenko Eduard <vasilenko.edua= rd@huawei.com> wrote:
>
> =C3=98 By contrast, a Compressed SID Container (i.e., the 128-bit enti= ty that is copied into the IPv6 Destination Address field) represents an en= tire SR Path. Specifically, it represents *many* functions that reside on *= many* nodes
>
>=C2=A0
>
> But CSID is not an IP address, right? Why IP address rules should be a= pplicable to CSID?
>
Eduard,

If the protocol is copying the CSI into the IPv6 Destination address the CS= I MUST be an IP address because the Destination Address field in an IPv6 pa= cket *contains* an IPv6 address. Overloading fields in the IPv6 header with= other data would be non-conformant with the IPv6 standard (not just addres= ses, see the several attempts to structure flow label for instance).

Frankly, this is one thing that I have found troubling with SrRv6. Sometime= s it is portrayed as an alternative, shadow protocol to IPv6 that just happ= ens to use the IPv6 protocol format for convenience instead of creating a n= ew L3 protocol for its purposes. The rationalization for this seems to be t= hat SRv6 is confined to limited domains, and within a limited domain we can= safely redefine standard protocols in arbitrary ways-- note, there is no c= onsensus that that philosophy is acceptable.

Tom

>=C2=A0
>
> From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Ron Boni= ca
> Sent: Thursday, October 7, 2021 10:36 PM
> To: Eduard Metz <etmetz@gmail.com>
> Cc: SPRING WG <spring@ietf.org>; 6man@ietf.org
> Subject: RE: [spring] draft-filsfilscheng-spring-srv6-srh-compression-= 02
>
>=C2=A0
>
>=C2=A0
>
> Inline [RB]
>
>=C2=A0
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ron
>
>=C2=A0
>
>=C2=A0
>
> Juniper Business Use Only
>
> From: Eduard Metz <etmetz@gmail.com>
> Sent: Thursday, October 7, 2021 5:03 AM
> To: Ron Bonica <rbonica@juniper.net>
> Cc: 6man@ietf.org; SPRING WG <spring@ietf.org>
> Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-= 02
>
>=C2=A0
>
> [External Email. Be cautious of content]
>
>=C2=A0
>
>=C2=A0
>
> Can the SID be viewed as the address of the "interface" to, = in this case, the function that resides in a node? From a routing / forward= ing point of view the group of functions is more similar to a network (repr= esented by a prefix, rather than a single address), but still.
>
>=C2=A0
>
> [RB] In RFC 8986, a classic SRv6 SID represents a *single* function th= at resides on a *single* node. If you like, you can even say that represent= s a *single* interface to a *single* function that resides on a *single* no= de.
>
>=C2=A0
>
> By contrast, a Compressed SID Container (i.e., the 128-bit entity that= is copied into the IPv6 Destination Address field) represents an entire SR= Path. Specifically, it represents *many* functions that reside on *many* n= odes
>
>=C2=A0
>
>=C2=A0
>
> For my understanding, apart from that the (definition of) SID may not = be aligned with the literal text in below RFCs, what is the real problem? A= re there any protocols that specifically rely on this definition of an IPv6= address?
>
>=C2=A0
>
> [RB] We don=E2=80=99t know if there are any protocols that rely on thi= s definition of the IPv6 address. And if we don=E2=80=99t update RFC 4291 b= efore violating it, we don=E2=80=99t know if anybody might write such an ap= plication in the future.
>
>=C2=A0
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ron
>
>=C2=A0
>
>=C2=A0
>
> cheers,
>
>=C2=A0 =C2=A0Eduard
>
>=C2=A0
>
>=C2=A0
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> = ipv6@ietf.org
> Administrative Requests: https://www.ietf.= org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
--00000000000013debf05cdd87392-- From nobody Fri Oct 8 07:59:03 2021 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 9F28E3A003C; Fri, 8 Oct 2021 07:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=OrbHv0UL; dkim=pass (1024-bit key) header.d=juniper.net header.b=ChQSYqPv 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 JO_MgVlMWH_w; Fri, 8 Oct 2021 07:58:55 -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 1617A3A0901; Fri, 8 Oct 2021 07:58:55 -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 SMTP id 1983kSQL027319; Fri, 8 Oct 2021 07:58:52 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=o93KEPKmjcEI3XCdVI6rqJREhbMR38ZUzM/2x2ALCZ0=; b=OrbHv0ULNhdDDWq8awU0nFl5jc3cpH+Ht9YD0sikfg2OAmSDZf/jPleNKpjuKahBy9cB ukCAR84bBcEB8BEYnWBzzDNwwsmSjxiWJwWyF8BHtRJeAvKJHI4fI8ktNIvCF1rTfdtI qwm9ZgvRjjAQoVcdHUzxyTW3geIX3L3mgIWLeNWca+PusNkH9P4gbH4mdHipxc+C7tCW aaTN5GZLqSSCgwr/uKB9UjsidpSCsGTnKxEVCOfoulWk02fL0a13mNesgQ1IOAmJ2HFJ Ji4yDLzzOv66X7paooVGrusYk1qAM9e4moh2vIT5Sjoaj8jA5V+kYEZ2ItUrAnZVoJK8 gA== Received: from nam04-bn8-obe.outbound.protection.outlook.com (mail-bn8nam08lp2043.outbound.protection.outlook.com [104.47.74.43]) by mx0a-00273201.pphosted.com with ESMTP id 3bjec1h6m5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 08 Oct 2021 07:58:52 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eTjHElGN5APJR3JFqk9oyD8mfgXOIEn4I77m3a19/l/MQCNwnsv/WFaoOPl//tyzoeWvr4nCVb3JuE8KbGuA6MkcLnq9XzS4zPYHX2f4e8AaJpW2cC38QLHoT5o4926IPxf/1H3W96q2sfGao8E3fyTCqWjuZRJFB12rEYF/juy6nLsi0pRJ0URXV0PMKWHECZ+hiLQ/00eTlBmf8vOjx2AeLOGohw9ve3b8FrbnQjPnEBENUpZv0q+7uhU73r/38qlfZQkrHzDzfRIna4KKvjcopZ4okxxsYDHdkqLL/J06znSo17FIHx50AMVk3miq0Kka7YABWbLE8xIp6s5j/Q== 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=o93KEPKmjcEI3XCdVI6rqJREhbMR38ZUzM/2x2ALCZ0=; b=g40kbkPSLKA6CD3NRrcCybAIQyox0d9fwPv8ofQJP3bdPfL8ZtiIilf3rNUnqxM2DqSMAsJIxm/NvREVG1vfDLRrp4tDDwaFOWJaugzNooeGsH35KjjCaGgHK9IHc8Ki/Q78CDWCXB+NK3xWeHZNIYdPWrAqHMZ29qJYOzcDP67GFiAM32ZxhyeQR5nlSoZ7FXntkIFMs8TL2ZQx0i3gLMYviVUopiLYh2+OAHAazFbubugVXSHaPcSup8HlMPpbV/sX/yMbi1diko7/I7588QDXXmdgIBTnSN9OmD60LO/bsAaTNRx/R2XRTJp2DBIkgCpjQkeq+NWzMGZZeA4H3A== 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=o93KEPKmjcEI3XCdVI6rqJREhbMR38ZUzM/2x2ALCZ0=; b=ChQSYqPvlXTqQPbP2q+RyF+dbJpPfwDFQjsmOFSh/3kj6nO8kjvgssMc6X1Lrtc28mCxQPHG3L+N9UK/2dx2i5FNRliDDN31LJQxgDMF/PyKreZ8zQ5ESvz2I/AO4EIZEiFlGPHpzSV1rzXwGhqmBZIVutnCMZJqmC1+j1Z4eFA= Received: from PH0PR05MB7749.namprd05.prod.outlook.com (2603:10b6:510:2e::7) by PH0PR05MB7670.namprd05.prod.outlook.com (2603:10b6:510:2a::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.13; Fri, 8 Oct 2021 14:58:50 +0000 Received: from PH0PR05MB7749.namprd05.prod.outlook.com ([fe80::2497:be95:715f:3b36]) by PH0PR05MB7749.namprd05.prod.outlook.com ([fe80::2497:be95:715f:3b36%5]) with mapi id 15.20.4587.018; Fri, 8 Oct 2021 14:58:49 +0000 From: Srihari Sangli To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: AQHXvFUA+b9kVLMmJku7IZ788mIUvA== Date: Fri, 8 Oct 2021 14:58:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=0a6e00bd-bf2f-4262-914a-0066d6f06d3a; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-08T14:56:35Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=Juniper Business Use Only;MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; user-agent: Microsoft-MacOutlook/16.53.21091200 authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9f8d3d94-196a-49bf-1ca2-08d98a6c231c x-ms-traffictypediagnostic: PH0PR05MB7670: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YjDV0iGcc3MWMnQltjrxba2KV/TGO9jtlxoAiaRCqgBJRZ5zWk+PkDi8hduTEowSYyW4ZjHxtohRTwvGBoIgelW3S5B/6wHBGvuokspW0SqN8OuoChJ1LlVq/GHV3B1VeicRkonFPlOPEYBEIVH0inS+MgAGJ1dLpSCI6iSWjpNoy1ev31OBVR/FKKIkcGnl9F02UbSpMldd50gUTOgMmk99PpEqZ8I02/6w5UKqZxx5/t4XChckUn57cXzRSZ+34vdC8zz6RAwTQcT+GBDTGET6aVf+ver6t+qN88Lf0IOaE81VXdBzN6XRlBs7KZ9Y1VHObGkXX9fCxYjFOjCm1GLYHHY/6V7wyW7jBSpOwkubXpZ/61tUtKR083xpqs+ZI92llHDNB3WI/NgEib0yV2D8lhpoLwkb9HSXfbXEl0LqmuNco6dF/3xSzJ6lafWKEWHFWIQzc8zzr9+JQr8NxfLhZp5/ZRwLBZrBgxVIt2aiTBoCby1TvTTQWpbVbDTkRvpXZzWfKTvOWCJX83QYNAIqUrhvPNbwQHfucceW6UyVe5bksLbPF9dmlTpZ7yG+SKrgugeBj3S1VDMldD7GnwdPlmYYvCBlIKy6bj+QL5Y6fCyXizBNbHLMp1mMsvj7OcLW0IAsOSVIFmzmHtSc/GWWSw7GEYfwzWgJFVHr4eG5BsjaNzxcsZpUr8JN3COTcN11uD3ggdEemWBoMAn/IH2QZd1tMjwwtoVSDb/13yj9OpYz62Sn1CL2JvFQFHlKTyLm8OMHA9bFEC4vv+K3RagYvB3PtaDwqK8F+x7RR8Rg4QTmvzqelzqzDMRRX6G5 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR05MB7749.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66446008)(166002)(66476007)(91956017)(2616005)(76116006)(66946007)(9326002)(83380400001)(36756003)(110136005)(6506007)(38070700005)(5660300002)(508600001)(316002)(966005)(8676002)(6512007)(66556008)(64756008)(2906002)(4326008)(26005)(38100700002)(6486002)(33656002)(86362001)(8936002)(186003)(71200400001)(122000001)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ay9MaGpqZURrRmprTUZPVGlkQ3JLaGJ5cXZ2ZHZsVlc2cWxJcFcwUGcrMCsx?= =?utf-8?B?M2xqN25tQmxIcnQ2a0drM2RFWjY1dzRBdUNQOElvNnpNcHBJcTZTTkdkalB1?= =?utf-8?B?TjNONGJpSmhsdUVpRXNkSWxhc0paTWR1c2hHSnNsY215bk1XUkl5SXpDTUdE?= =?utf-8?B?VGY3SzRHemtXazNwMXl3RllpK2xsbmNLUkk5VEpuN3ZKMFNQWFEvZTdZSHZl?= =?utf-8?B?aWp0aFFEdTM0VnExbEpIZWE4bGUxdWJiOUIyT1VSNXFBS2ROUFU3WERBbkFU?= =?utf-8?B?UG1jYzYvaC94aEt3blZZVmszNjJTUUF5L3ZSenJORnowWFFoM1ovUjhmbmZK?= =?utf-8?B?V3JBMllYVkVtcVQ1bDMvVjVxSVBZUWNJSUdwb3BnU0NmejgxQytQL25FK1V0?= =?utf-8?B?MERmQzBuV2kvc3hMTEM5UzhCRjZvNENuYzRQWitmUGJrTUplWHpxN0J5eXVn?= =?utf-8?B?RG9Mc3RrVzBPeHUxZDFPQk92YXltbVRXdzBZYW9NYVJNajdCanplbjJPTlBp?= =?utf-8?B?b1JwMGczS3RDVGVVY3ZKaEZJOVNkNUZTQmRId01SZ3pocWRzNDRMRklMQUkr?= =?utf-8?B?Yk9zZWRDTlc3OXhxV1JUemd2bit0TjZQQlBkV0FzMFBwK3ZtZVJnbk9iaEw3?= =?utf-8?B?UHIrZ2I5VHNEWFNKS05HMFhvK2ExYklBakZQUEw4NHdqbWRtOW9WQXo4Mzhz?= =?utf-8?B?SVZqRHowY0V2dVovYjVWUi9BRFFKenprZVBrM3VXanFBZ3doQlNXckpHOVc3?= =?utf-8?B?L2pVc3RGVWhOL09zbExUWnhoKzdvQnZUbGRyR3RCWkFmNlpDTUIxZzVEU1Yw?= =?utf-8?B?Q2ZTdjBJUkJHMS9vTDV2OXJxSzV4dHZUbEJSTkgrZ2Zac1ZUVWVnMGlQZmtv?= =?utf-8?B?TXVqOFBMUHFMR2dseU5pYkVjUitvdXNSMFlnQktrWVRONkg5TWtWVm5hRHEx?= =?utf-8?B?MmU3cXU4d3A2dEl2c1F0cXdFV0txR1UvQmxNVGRVWjBNR2VnVWVTeU5oSVFN?= =?utf-8?B?REZGa0Y0T29UdWM1dXNkaHEranhRYzE2MTlmQTIzKzVWUGNleTNsN2FYNzdk?= =?utf-8?B?aTVaLy8wam9LdUJDOE9SNSs1OFVnM0NvTVpUdWJaUEhEOGRNMHR0UkZ6UHd2?= =?utf-8?B?YXhWYUJ2SmhFU0J3S3JnVWp2SllxQ3dMTngybURoMVZ3MlppSTlkOWt6RmJs?= =?utf-8?B?VFdwdXVvNVhEbGEzZEltVWZOVm9XUkdzS1NDUGJjMExnaXF4MzhyL0RBVFZK?= =?utf-8?B?MGMwaGVuekV6dDdScktIWjErU21xU3lvenZCMm9aSFVkQmx6b0owVnJIbUxL?= =?utf-8?B?RVFOVlVZYWhUM2g3OGFRZVdMOEhXa2dvTUZSWEZDTWlPNVlBSHNFdU9wUW5E?= =?utf-8?B?TjVKRHpKNGlkWGpFOGM2a1I1d2ZBOWt4Y2xBNHIxNDVOck1laGFoZUFMOXVp?= =?utf-8?B?Z3ltK29UM0tFSlkvNWlKUkdMdlNEUGYyZGpIUHU0TlRabS81dGhjVnZvKyti?= =?utf-8?B?N1FUbEVkRUF3a09BWUd6Ny9ObzQyTGx4WVpVaVlmcXJzdFJuczMwbjh5SEpt?= =?utf-8?B?cjkzcUVrenVHUUFWUlg5d3htUzY3Zm9WUVdEcTVUcmd0bm1mcWNZblNYb2NU?= =?utf-8?B?bTN5Uit3VEN4T1ZieFN4MlFQK1VkZ2tuKytueCtRemorUlBiMUp0azlDSTlY?= =?utf-8?B?ZE1hS1l5NW90SFVIV1RDVHFoelQrTnMzZE5mMEtyc0h5d3FCNG9QNmx4VjhB?= =?utf-8?B?UmpORXNJaUVkK1BCUXMzaUtueFJvMW9BYnVON2JCK0xIWkJTSEV2VWMzQzdX?= =?utf-8?B?SG5CU2VKaTgrcmRhTFdydz09?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_F031E8C0ED2247439772E369C92AE493junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR05MB7749.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9f8d3d94-196a-49bf-1ca2-08d98a6c231c X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2021 14:58:49.8636 (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: gqinqbv8LKYGrubIBED9sA78GvHnfi17HWmWN/Z7hLy4exjunXCZQZPhMglTRdfB+7zO7B+6i9cfJxZYZVPNpg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR05MB7670 X-Proofpoint-ORIG-GUID: v4W6vdVx98jho9fpYs8xcwnZOvoT2Yoo X-Proofpoint-GUID: v4W6vdVx98jho9fpYs8xcwnZOvoT2Yoo X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-08_04,2021-10-07_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 impostorscore=0 mlxscore=0 bulkscore=0 suspectscore=0 phishscore=0 priorityscore=1501 adultscore=0 lowpriorityscore=0 spamscore=0 mlxlogscore=999 malwarescore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110080089 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 08 Oct 2021 14:59:01 -0000 --_000_F031E8C0ED2247439772E369C92AE493junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQ2hhaXJzLA0KDQpUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyAzIGJlaGF2aW91cnMgZm9y IFNJRCBhbmQgdGhpcyBpbiBjb250cmFkaWN0aW9uIHRvIHdoYXQgd2FzIGRpc2N1c3NlZCBvbiBT UFJJTkcgYWxpYXMgYWJvdXQgYWRvcHRpbmcgb25lIGJlaGF2aW91ciBmb3Igd2hpY2ggdGhlcmUg d2FzIG92ZXJ3aGVsbWluZyByZXNwb25zZS4NCg0KSSBzdHJvbmdseSBvYmplY3QgdGhlIGFkb3B0 aW9uIG9mIHRoaXMgZHJhZnQuDQoNCnNyaWhhcmnigKYNCg0KDQpPbiAwMS8xMC8yMSwgNzozNSBQ TSBzcHJpbmcgb24gYmVoYWxmIG9mIEphbWVzIEd1aWNoYXJkIGZyb20gc3ByaW5nLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgamFt ZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPG1haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGZ1dHVy ZXdlaS5jb20+IHNhaWQgPg0KDQpbRXh0ZXJuYWwgRW1haWwuIEJlIGNhdXRpb3VzIG9mIGNvbnRl bnRdDQoNCkRlYXIgV0c6DQoNClRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBleHByZXNzIHRoZWly IGFwcHJlY2lhdGlvbiBmb3IgYWxsIHRoZSByZXNwb25zZXMgcmVjZWl2ZWQgdG8gb3VyIGVtYWls cyB3aXRoIHJlZmVyZW5jZSB0byBob3cgdGhlIHdvcmtpbmcgZ3JvdXAgd2lzaGVzIHRvIG1vdmUg Zm9yd2FyZCB3aXRoIHJlc3BlY3QgdG8gYSBzb2x1dGlvbiBmb3IgU1J2NiBjb21wcmVzc2lvbi4N Cg0KVGhlIGFwcGFyZW50IGluY2xpbmF0aW9uIG9mIHRoZSB3b3JraW5nIGdyb3VwIGlzIHRvIHVz ZSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNw cmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88aHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0 dHBzOi9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmct c3J2Ni1zcmgtY29tcHJlc3Npb24vX187ISFORXQ2eU1hTy1nayFWcVE0LUY4M3Vyc1VTeEc2SXlN ZlFLTkphYU8tQmxNQklMb21NN0JrS0ZVamp1M29uTUNIYmdNTlFLYVd1SzQkPiBhcyB0aGUgYmFz aXMgZm9yIGl0cyBjb21wcmVzc2lvbiBzdGFuZGFyZGl6YXRpb24gd29yay4gVGhhdCBpcyBwYXJ0 IG9mIHdoYXQgdGhpcyBlbWFpbCBhdHRlbXB0cyB0byBjb25maXJtLg0KDQpCZWNhdXNlIG9mIHRo ZSBhYm92ZSB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gaXNzdWUgYSAyLXdlZWsgV0cgY2FsbCBm b3IgYWRvcHRpb24gZW5kaW5nIE9jdG9iZXIgMTV0aCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Np b24vPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uL19f OyEhTkV0NnlNYU8tZ2shVnFRNC1GODN1cnNVU3hHNkl5TWZRS05KYWFPLUJsTUJJTG9tTTdCa0tG VWpqdTNvbk1DSGJnTU5RS2FXdUs0JD4gYnV0IHdpdGggc29tZSBjbGVhciBndWlkZWxpbmVzIGFz IGZvbGxvd3MuIEJ5IGV4cHJlc3Npbmcgc3VwcG9ydCBmb3IgYWRvcHRpb24gb2YgdGhpcyBkb2N1 bWVudCB5b3UgYXJlIGZ1bGx5IGF3YXJlIG9mIGFuZCBhcmUgYWNrbm93bGVkZ2luZyB0aGF0Og0K DQoNCjEuICAgICAgIFRoZSBTUFJJTkcgd29ya2luZyBncm91cCBpcyBhZG9wdGluZyBhIGRvY3Vt ZW50IHRoYXQgaGFzIG11bHRpcGxlIFNSdjYgRW5kcG9pbnQgYmVoYXZpb3JzLg0KDQoyLiAgICAg ICBUaGUgZG9jdW1lbnQgaXMgYSDigJxsaXZpbmfigJ0gZG9jdW1lbnQ7IGl0IG1heSBjaGFuZ2Ug YXMgaXQgZ29lcyB0aHJvdWdoIHJldmlldyBhbmQgYW5hbHlzaXMgYnkgdGhlIFNQUklORyB3b3Jr aW5nIGdyb3VwLg0KDQozLiAgICAgICBBbGwgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyByYWlzZWQg b24gb3VyIG1haWxpbmcgbGlzdCBNVVNUIGJlIGFkZHJlc3NlZCBCRUZPUkUgc2FpZCBkb2N1bWVu dCBpcyBhbGxvd2VkIHRvIHByb2dyZXNzIGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAgdG8gcHVibGlj YXRpb24uIEEgbGlzdCBvZiB0aGVzZSBkaXNjdXNzaW9uIHBvaW50cyB3aWxsIGJlIGRvY3VtZW50 ZWQgaW4gdGhlIFdHIGRvY3VtZW50IGFuZCBtYWludGFpbmVkIGJ5IHRoZSBkb2N1bWVudCBlZGl0 b3IgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgY2hhaXJzLg0KDQo0LiAgICAgICBJZiB0aGlzIGRv Y3VtZW50IGlzIGFkb3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAsIHRoZSBjaGFpcnMgc3BlY2lm eSBhcyBwYXJ0IG9mIHRoZSBhZG9wdGlvbiBjYWxsIHRoYXQgdGhlIGZvbGxvd2luZyB0ZXh0IGRl c2NyaWJpbmcgYW4gb3BlbiBpc3N1ZSBiZSBhZGRlZCB0byB0aGUgZG9jdW1lbnQgaW4gdGhlIGFi b3ZlLWRlc2NyaWJlZCBvcGVuIGlzc3VlcyBzZWN0aW9uOg0KDQrCtyAgICAgICAgICJHaXZlbiB0 aGF0IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBzYWlkIHRoYXQgaXQgd2FudHMgdG8gc3RhbmRhcmRp emUgb25lIGRhdGEgcGxhbmUgc29sdXRpb24sIGFuZCBnaXZlbiB0aGF0IHRoZSBkb2N1bWVudCBj b250YWlucyBtdWx0aXBsZSBTUnY2IEVuZFBvaW50IGJlaGF2aW9ycyB0aGF0IHNvbWUgV0cgbWVt YmVycyBoYXZlIHN0YXRlZCBhcmUgbXVsdGlwbGUgZGF0YSBwbGFuZSBzb2x1dGlvbnMsIHRoZSB3 b3JraW5nIGdyb3VwIHdpbGwgYWRkcmVzcyB3aGV0aGVyIHRoaXMgaXMgdmFsaWQgYW5kIGNvaGVy ZW50IHdpdGggaXRzIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uIG9iamVjdGl2ZS4iLg0KDQpQbGVh c2UgY29uc2lkZXIgdGhlIGFib3ZlIGd1aWRlbGluZXMgYXMgeW91IGRlY2lkZSBvbiB3aGV0aGVy IHRvIHN1cHBvcnQgb3Igbm90IHRoaXMgV0cgYWRvcHRpb24uIFBsZWFzZSBleHByZXNzIGNsZWFy bHkgeW91ciByZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9uLXN1cHBvcnQgYXMgd2VsbCBhcyBhbnkg b3BlbiBkaXNjdXNzaW9uIHBvaW50cyB5b3Ugd291bGQgbGlrZSBhZGRyZXNzZWQgc2hvdWxkIHRo ZSBkb2N1bWVudCBiZSBhZG9wdGVkIGludG8gdGhlIHdvcmtpbmcgZ3JvdXAuDQoNClRoYW5rcyEN Cg0KSmltLCBCcnVubyAmIEpvZWwNCg0KDQoNCg0KSnVuaXBlciBCdXNpbmVzcyBVc2UgT25seQ0K --_000_F031E8C0ED2247439772E369C92AE493junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <682E786F406886489629C030CA53C5D5@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIFwoQm9keSBD U1wpIjsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2Zv bnQtZmFtaWx5OkxhdG87DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDM7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFy IjsNCgltYXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBo LCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2lu LXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJn aW4tbGVmdDozNi4wcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBs YWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFu LkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRh bnQ7DQoJY29sb3I6d2luZG93dGV4dDsNCgl0ZXh0LXRyYW5zZm9ybTpub25lO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlz dC1pZDo3NTE2OTkzOTM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi03MjE2NTQ3NzYgNjc2OTg3MDMgNjc2OTg2ODkgNjc2OTg3MTUgNjc2OTg3MDMgNjc2 OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2 ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWlu ZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGww OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDEN Cgl7bXNvLWxpc3QtaWQ6MTAzODM1NDUwODsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTM3Nzg0 ODM3Njt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21h cmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLUlOIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIgc3R5bGU9 IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkhlbGxvIENoYWlycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgMyBiZWhhdmlvdXJz IGZvciBTSUQgYW5kIHRoaXMgaW4gY29udHJhZGljdGlvbiB0byB3aGF0IHdhcyBkaXNjdXNzZWQg b24gU1BSSU5HIGFsaWFzIGFib3V0IGFkb3B0aW5nIG9uZSBiZWhhdmlvdXIgZm9yIHdoaWNoIHRo ZXJlIHdhcyBvdmVyd2hlbG1pbmcgcmVzcG9uc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkkgc3Ryb25nbHkgb2JqZWN0IHRo ZSBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ c3JpaGFyaeKApiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+T24gMDEvMTAvMjEsIDc6MzUgUE0gc3ByaW5nIG9uIGJlaGFs ZiBvZiBKYW1lcyBHdWljaGFyZCBmcm9tDQo8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNA aWV0Zi5vcmciPnNwcmluZy1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhy ZWY9Im1haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20iPmphbWVzLm4uZ3VpY2hh cmRAZnV0dXJld2VpLmNvbTwvYT4gc2FpZCAmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxl ZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 O2xpbmUtaGVpZ2h0OjEyLjBwdDtiYWNrZ3JvdW5kOiNGRkVCOUMiPg0KPGI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0xhdG8mcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+W0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBv ZiBjb250ZW50XTxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5EZWFyIFdHOjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+VGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGV4cHJlc3MgdGhlaXIgYXBwcmVjaWF0aW9u IGZvciBhbGwgdGhlIHJlc3BvbnNlcyByZWNlaXZlZCB0byBvdXIgZW1haWxzIHdpdGggcmVmZXJl bmNlIHRvIGhvdyB0aGUgd29ya2luZyBncm91cCB3aXNoZXMgdG8gbW92ZSBmb3J3YXJkIHdpdGgg cmVzcGVjdCB0byBhIHNvbHV0aW9uIGZvcg0KIFNSdjYgY29tcHJlc3Npb24uIDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+VGhlIGFwcGFyZW50IGluY2xpbmF0aW9uIG9mIHRoZSB3b3JraW5nIGdyb3VwIGlzIHRv IHVzZQ0KPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29t cHJlc3Npb24vX187ISFORXQ2eU1hTy1nayFWcVE0LUY4M3Vyc1VTeEc2SXlNZlFLTkphYU8tQmxN QklMb21NN0JrS0ZVamp1M29uTUNIYmdNTlFLYVd1SzQkIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNz aW9uLzwvYT4gYXMgdGhlIGJhc2lzIGZvciBpdHMgY29tcHJlc3Npb24gc3RhbmRhcmRpemF0aW9u IHdvcmsuIFRoYXQgaXMgcGFydCBvZiB3aGF0IHRoaXMgZW1haWwgYXR0ZW1wdHMgdG8gY29uZmly bS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkJlY2F1c2Ugb2YgdGhlIGFib3ZlIHRoZSBjaGFpcnMgd291bGQg bGlrZSB0byBpc3N1ZSBhIDItd2VlayBXRyBjYWxsIGZvciBhZG9wdGlvbiBlbmRpbmcgT2N0b2Jl ciAxNTxzdXA+dGg8L3N1cD4gZm9yDQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UuY29tL3Yz L19faHR0cHM6L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNw cmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi9fXzshIU5FdDZ5TWFPLWdrIVZxUTQtRjgzdXJzVVN4 RzZJeU1mUUtOSmFhTy1CbE1CSUxvbU03QmtLRlVqanUzb25NQ0hiZ01OUUthV3VLNCQiPg0KaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmct c3J2Ni1zcmgtY29tcHJlc3Npb24vPC9hPiBidXQgd2l0aCBzb21lIGNsZWFyIGd1aWRlbGluZXMg YXMgZm9sbG93cy4gQnkgZXhwcmVzc2luZyBzdXBwb3J0IGZvciBhZG9wdGlvbiBvZiB0aGlzIGRv Y3VtZW50IHlvdSBhcmUgZnVsbHkgYXdhcmUgb2YgYW5kIGFyZSBhY2tub3dsZWRnaW5nIHRoYXQ6 DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3 Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+DQo8IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgU1BSSU5HIHdvcmtpbmcg Z3JvdXAgaXMgYWRvcHRpbmcgYSBkb2N1bWVudCB0aGF0IGhhcyBtdWx0aXBsZSBTUnY2IEVuZHBv aW50IGJlaGF2aW9ycy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gbGFu Zz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjIuPHNwYW4gc3R5bGU9ImZv bnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBs YW5nPSJFTi1VUyI+VGhlIGRvY3VtZW50IGlzIGEg4oCcbGl2aW5n4oCdIGRvY3VtZW50OyBpdCBt YXkgY2hhbmdlIGFzIGl0IGdvZXMgdGhyb3VnaCByZXZpZXcgYW5kIGFuYWx5c2lzIGJ5IHRoZSBT UFJJTkcgd29ya2luZyBncm91cC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0x OC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gbGFuZz0iRU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPjMuPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBsYW5nPSJFTi1VUyI+QWxsIG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgcmFpc2VkIG9uIG91 ciBtYWlsaW5nIGxpc3QgTVVTVCBiZSBhZGRyZXNzZWQgQkVGT1JFIHNhaWQgZG9jdW1lbnQgaXMg YWxsb3dlZCB0byBwcm9ncmVzcyBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIHRvIHB1YmxpY2F0aW9u LiBBIGxpc3Qgb2YgdGhlc2UgZGlzY3Vzc2lvbiBwb2ludHMgd2lsbCBiZSBkb2N1bWVudGVkDQog aW4gdGhlIFdHIGRvY3VtZW50IGFuZCBtYWludGFpbmVkIGJ5IHRoZSBkb2N1bWVudCBlZGl0b3Ig aW4gY29uanVuY3Rpb24gd2l0aCB0aGUgY2hhaXJzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4 dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+DQo8IVtpZiAhc3VwcG9y dExpc3RzXT48c3BhbiBsYW5nPSJFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ NC48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB0aGlzIGRvY3VtZW50IGlzIGFkb3B0ZWQg YnkgdGhlIHdvcmtpbmcgZ3JvdXAsIHRoZSBjaGFpcnMgc3BlY2lmeSBhcyBwYXJ0IG9mIHRoZSBh ZG9wdGlvbiBjYWxsIHRoYXQgdGhlIGZvbGxvd2luZyB0ZXh0IGRlc2NyaWJpbmcgYW4gb3BlbiBp c3N1ZSBiZSBhZGRlZCB0byB0aGUgZG9jdW1lbnQgaW4gdGhlIGFib3ZlLWRlc2NyaWJlZCBvcGVu IGlzc3Vlcw0KIHNlY3Rpb246PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwOC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDtt c28tbGlzdDpsMCBsZXZlbDIgbGZvMyI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0K PC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGxhbmc9IkVOLVVTIj4mcXVvdDtH aXZlbiB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBzYWlkIHRoYXQgaXQgd2FudHMgdG8gc3Rh bmRhcmRpemUgb25lIGRhdGEgcGxhbmUgc29sdXRpb24sIGFuZCBnaXZlbiB0aGF0IHRoZSBkb2N1 bWVudCBjb250YWlucyBtdWx0aXBsZSBTUnY2IEVuZFBvaW50IGJlaGF2aW9ycyB0aGF0IHNvbWUg V0cgbWVtYmVycyBoYXZlIHN0YXRlZCBhcmUgbXVsdGlwbGUNCiBkYXRhIHBsYW5lIHNvbHV0aW9u cywgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhZGRyZXNzIHdoZXRoZXIgdGhpcyBpcyB2YWxpZCBh bmQgY29oZXJlbnQgd2l0aCBpdHMgb25lIGRhdGEgcGxhbmUgc29sdXRpb24gb2JqZWN0aXZlLiZx dW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBsZWFzZSBjb25zaWRlciB0aGUgYWJvdmUgZ3VpZGVsaW5l cyBhcyB5b3UgZGVjaWRlIG9uIHdoZXRoZXIgdG8gc3VwcG9ydCBvciBub3QgdGhpcyBXRyBhZG9w dGlvbi4gUGxlYXNlIGV4cHJlc3MgY2xlYXJseSB5b3VyIHJlYXNvbmluZyBmb3Igc3VwcG9ydC9u b24tc3VwcG9ydCBhcyB3ZWxsIGFzIGFueSBvcGVuIGRpc2N1c3Npb24NCiBwb2ludHMgeW91IHdv dWxkIGxpa2UgYWRkcmVzc2VkIHNob3VsZCB0aGUgZG9jdW1lbnQgYmUgYWRvcHRlZCBpbnRvIHRo ZSB3b3JraW5nIGdyb3VwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzITxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ SmltLCBCcnVubyAmYW1wOyBKb2VsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJyPg0KPHAgc3R5bGU9ImZvbnQtZmFtaWx5OkNh bGlicmk7Zm9udC1zaXplOjdwdDtjb2xvcjojMDAwMDAwO21hcmdpbjoxNXB0OyIgYWxpZ249IkNl bnRlciI+DQpKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5PGJyPg0KPC9wPg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_F031E8C0ED2247439772E369C92AE493junipernet_-- From nobody Fri Oct 8 08:23:13 2021 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 3AC5F3A00C3 for ; Fri, 8 Oct 2021 08:23:11 -0700 (PDT) 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, 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=liquidtelecom.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 Yilf3sX-OEor for ; Fri, 8 Oct 2021 08:23:05 -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 89F203A00D6 for ; Fri, 8 Oct 2021 08:23:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquidtelecom.com; s=mimecast20210406; t=1633706582; 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=s6c3yM8z32WSrEoet8oJ0W9GkSgQ2OdpowB+03FV9sg=; b=PsZVF4/NoqyCc9gLB21KCBU/ZsPd48qm0ZFvyMd6KNCVYklGqW6OvRBSJQxuVkLfP/Z6ns WM2i5Cj8clRcveBDdNukK9GM57d/DV4ULWDRT9xnrc9QiefzJUvMRsbaDWztp6UVk2aeRS mLfkqm7xXB0C5fBhRiLFGm+pbc5H/SI= Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02lp2059.outbound.protection.outlook.com [104.47.6.59]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-33-Q0eJFu5eO9afwY3HmGn4-w-1; Fri, 08 Oct 2021 16:23:00 +0100 X-MC-Unique: Q0eJFu5eO9afwY3HmGn4-w-1 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com (2603:10a6:20b:346::6) by AS8PR03MB7751.eurprd03.prod.outlook.com (2603:10a6:20b:406::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.19; Fri, 8 Oct 2021 15:22:58 +0000 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9]) by AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9%5]) with mapi id 15.20.4587.019; Fri, 8 Oct 2021 15:22:58 +0000 From: Andrew Alston To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQFirUfw Date: Fri, 8 Oct 2021 15:22:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 844e7bd9-dc31-4275-c04e-08d98a6f829a x-ms-traffictypediagnostic: AS8PR03MB7751: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: A3Wgt4eHWe8a5zE5tZkzvH39ySVSqNVRWdtrOjl3fwe+Kgj6FNUN0AfoQsLN6VoXi/2IX8OBgF98sy3TZyRJltyA+NstqstKBBudmCCXoLm8WENGzz6i1l5UEqXu3ntvBsrNKD/b8OdXFJmhh3VMNqUgxj4JlwAe3aAjL6CTl+VIkob2m51TIAZ9gfxMZqssSUky2DF+PRylOcDqIblUk+QWxYI3nvAblxwtnEyh8aYJLR7dTxCig1hg9udD8wJlqfXg5VnI5tAas+Myoi7+9IDkXgprSAgxPhwpxLmrnCD/dHSzjCmu/M0YwSqwDfR+L/5dILQrE/K8QLf7Q0Yq7BM5qSRU9yuUM8VpkyCLt/Zv2XXTJ8Ul5A9p5Zt7GChpkL7FfukqBGxnVXMPReZb5l1xztFs2IztFR2xsLxph6rL++e59Qu3JhYKArbks51jwq92CHVKsLxFiEfT/3l24sUZ9kkkL7Hf0sx/qLZhqW+9vC7O+WWgc6EUaigGGzr80vPfn+4foBe/9YDlJqvxvjiDGSI1QQOrZDmH1I5l9R6qGy3I25r3IZmJKHOv+58xHCSu+zPcXMpW+Oy7FOBrTOXiCKhzPlDpsmX6dFhwiXOw+RxJytDADC95zNYODyxreaOR3cxecDAemLotu166ooxblwDZt/F+Zpw7bUNtqVi1E2gJCIRfopkVwCHx2/XLBnbhMPsDfOm0QRG7pcxyVO+2/nKascat6E1Dj24jf4zLG7cbuXaHhoPkWHkkEw1S7Au2GkNwkDDJUaNClRNIhUlXIJZNnIZ8XPd5TTs8Tgw= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR03MB7622.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(7696005)(53546011)(4326008)(8676002)(110136005)(38100700002)(38070700005)(33656002)(52536014)(166002)(55016002)(83380400001)(9686003)(5660300002)(86362001)(71200400001)(6506007)(966005)(66476007)(66556008)(64756008)(8936002)(498600001)(2906002)(66946007)(76116006)(66446008)(186003)(122000001); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?ePmmD45DNshI4RO6XQOdOLONXyGZc9af2an/Xpg2Oyy5C5+1kX+RfmU0uxOv?= =?us-ascii?Q?243IlKCEyRD9sB4ejKLbchqnzZ3lo9N8i0cj5Xv5ZUWYJoX+rN3XwOjHxLlX?= =?us-ascii?Q?BV+QK/OArVCFH6NIT0J96BC7wBwZ0pjAI+frSNNn22Ii7sy8+0gtTcTdrzjW?= =?us-ascii?Q?SQtqUV1UhBOkbo3dpwQbePJEhgtxg3XH+EjHyxO0lZM1YCCvoj+4OtbqypNX?= =?us-ascii?Q?TREN/Z8G4u8mE+J53qgjljm2eQHO6QylfZnCAjCp3rECDNyBFWt4WXcwnzj8?= =?us-ascii?Q?y2uU2Qct7oQTwlpjiZ5TaXqwnQBvnmsq+0zhiFnGqF4If5mmrRg4d/YPFUYx?= =?us-ascii?Q?0Ry5c9IVhPqv2gmQtgiaXvnvbxeJMdt5nqEqZP3cu0dyRPt+cl7U49K1J47e?= =?us-ascii?Q?QNcM1iqHxeo8BzIgCgRiDlW4Mi3AwGKuY4ryPwLnn9ohOMWatx98dohtOdyE?= =?us-ascii?Q?ejW4cPzac19IDJmIcibcxH2WdgxR8Y6uCG1DBYzKT49xIsCuYq6w7A0C1VT8?= =?us-ascii?Q?8AAOUrqe4+mEom7Hkl4hTl6d2fW8eZUbLXt+ok6LsDkgP6WCsaYRAh5tXLaJ?= =?us-ascii?Q?g2/lvMSkzOax3fq1mzBcpZaeLVPRloBMCJR6Wxiw7y7TrNLaJZGLWVgDZ9fc?= =?us-ascii?Q?3nLm7IRrwlFtvYr4ofas+pb0BNDnOxnnjv/AzN3zTVlm30SzxHeoo2vjHzEY?= =?us-ascii?Q?A4cI8m8s+e+Tnl/gfhujjsGDB/ApSnYLJmhbozMhrxj0L496M+yOnY+BM5zp?= =?us-ascii?Q?FnYy+26DmZ0Xk8gvqOPGjTWVWwNVGZr+jCmKCH1QyTTWgRzUSkyPnipE7V0C?= =?us-ascii?Q?H82wklIXSlS2U2ebonkIb6K73Yu2KzVuoqoZa148pOv6Uffn1pQKnKI5Hzp2?= =?us-ascii?Q?zTfHepE9HFM1thOyo0RC/RSXRb41+D5LJPzA8SybY6M9NpjrYovb4IkGw6xH?= =?us-ascii?Q?6MgJ3cv3NtSQwI/rQIN/waNxql64ziXq3xsr1ZJeEYqBn2rrEPpcLNA9P/dr?= =?us-ascii?Q?k1h3i4pk+wVIah1Gm6kAX5PDXIUtpyPJuGa90BZYfArrPRvvDJl8kpAeyLEm?= =?us-ascii?Q?JYQM6oM3JCrz1kI2gHK72RF3x4eJHkWS0L3yI/Asya+j+OWM1Fjax6C7USVj?= =?us-ascii?Q?Wbz/7bsAOGZMhc37/OlRfI9nf+Dr2F9gUubv3xK//aT4GwmR2rOwNCBTgujI?= =?us-ascii?Q?8gr/iIpNb/erFliAxbB+bxctAJRlRhvgtmtvfrH1XX3ox8EIWFv8LHIrTtuQ?= =?us-ascii?Q?B5dLQgQhiiywp3SXP5CSoz30BftO5qr+wYocUhHYoVg6GB8WXqqmDxYBpmr+?= =?us-ascii?Q?oVuETVvaqOEvYUg371pYgB3wwTLzWR05H6FrxKSjao4ZqW6erAZwa8AdCuSf?= =?us-ascii?Q?ZmUspiA=3D?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB7622.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 844e7bd9-dc31-4275-c04e-08d98a6f829a X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2021 15:22:58.5235 (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: wyOeW1pP91HDwgPtUdey8EyoCsSJWPHS8RsgLC6eObRM1ufX3cgb7HWarRlIu2L4r1Za67jZOAIsRzLdiMbUH6TP8zLgerb7KltsBF1UOK4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7751 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquidtelecom.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_AS8PR03MB76229CE9459F38BAFBC81D90EEB29AS8PR03MB7622eurp_" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 08 Oct 2021 15:23:11 -0000 --_000_AS8PR03MB76229CE9459F38BAFBC81D90EEB29AS8PR03MB7622eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Figured I would weigh in here once again - and try and summarize the way I = see things. 1. The working group found consensus on a single behavior - this documen= t contains 3 - if that consensus is to be changed - let it be changed by th= e working group before we walk down this path. 2. The charter of the spring working group is very clear - it states: Any modification of -or extension to- existing architectures, data planes, = or control or management plane protocols should be carried out in the WGs r= esponsible for the architecture, data plane, or control or management plane= protocol being modified and in coordination with the SPRING WG, but may be= done in SPRING WG after agreement with all the relevant WG chairs and resp= onsible area directors. I have yet to see each agreement voiced by these parties. 1. There is technical dispute over the overloading of addresses and the = use of IPv6 addresses in this manner, and if the excuse of limited domain i= s valid to get away with this - this has not been resolved 2. Two out of the three working group chairs who are actively involved i= n calling for the adoption of this document are co-authors of said document= and have not recused themselves and stated they will not take part in deci= sions regarding its progression - the term - conflict of interest - was cre= ated for such situations 3. There have been suggestions on this list about splitting g-srv6 out -= so that it can proceed, since it does NOT seem to run afoul of (B) and the= n if the working group sees fit to agree to change the view on single behav= ior, the csid parts could be processed separately should the chairs and ad'= s involved in the INT group agree - this suggestion has never had a full re= sponse or a reason why this is either impractical or should not go ahead - = and under the definition of rough consensus therefore stands as an unaddres= sed issued. I am kinda shocked in a situation where almost any one of these points woul= d be sufficient to act as a blocker - we are still walking down this path -= I lament the lack of adherence to the bottom up approach that I am seeing = here, and the disregard shown towards clear conflicts of interest, particul= arly where there are scenarios under which we could all progress that would= resolve half of the issues above. Let us act in a way that is in adherence to the bottom-up approach, respect= s working group consensus, avoids conflicts of interest, follows the charte= r and eventually ends up in a place where distrust in the process is allowe= d to fester. Thanks Andrew From: spring On Behalf Of James Guichard Sent: Friday, October 1, 2021 5:05 PM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as t= he basis for its compression standardization work. That is part of what thi= s email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guideline= s as follows. By expressing support for adoption of this document you are f= ully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_AS8PR03MB76229CE9459F38BAFBC81D90EEB29AS8PR03MB7622eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

Figured I would weigh in here once again – and= try and summarize the way I see things.

 

  1. The working group found consensus on a single behavior – this d= ocument contains 3 – if that consensus is to be changed – let i= t be changed by the working group before we walk down this path.
  2. The charter of the spring working group is= very clear – it states:

Any modification of -or extension to- existin= g architectures, data planes, or control or management plane protocols shou= ld be carried out in the WGs responsible for the architecture, data plane, = or control or management plane protocol being modified and in coordination with the SPRING WG, but may be done in = SPRING WG after agreement with all the relevant WG chairs and responsible a= rea directors.

        &nbs= p;     I have yet to see each agreement voiced by these= parties.

  1. There is technical dispute over the overloading of addresses and the = use of IPv6 addresses in this manner, and if the excuse of limited domain i= s valid to get away with this – this has not been resolved
  2. Two out of the three working g= roup chairs who are actively involved in calling for the adoption of this d= ocument are co-authors of said document and have not recused themselves and stated they will not take part in decisions regarding its progression R= 11; the term – conflict of interest – was created for such situ= ations
  3. There have been suggestions on this list about = splitting g-srv6 out – so that it can proceed, since it does NOT seem= to run afoul of (B) and then if the working group sees fit to agree to change the view on single behavior, the csid parts could be processed s= eparately should the chairs and ad’s involved in the INT group agree = – this suggestion has never had a full response or a reason why this = is either impractical or should not go ahead – and under the definition of rough consensus therefore stands as an= unaddressed issued.

 

I am kinda shocked in a situation where almost any o= ne of these points would be sufficient to act as a blocker – we are s= till walking down this path – I lament the lack of adherence to the b= ottom up approach that I am seeing here, and the disregard shown towards clear conflicts of interest, particularly where th= ere are scenarios under which we could all progress that would resolve half= of the issues above.

 

Let us act in a way that is in adherence to the bott= om-up approach, respects working group consensus, avoids conflicts of inter= est, follows the charter and eventually ends up in a place where distrust i= n the process is allowed to fester.

 

Thanks

 

Andrew

 

From: spring <spring-bounces@ietf.org> = On Behalf Of James Guichard
Sent: Friday, October 1, 2021 5:05 PM
To: SPRING WG <spring@ietf.org>
Cc: spring-chairs@ietf.org
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

 

Dear WG:

 

The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

 

The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors.
  2. The document is a “living” document; it m= ay change as it goes through review and analysis by the SPRING working grou= p.
  3. All open discussion points raised on our mailing list= MUST be addressed BEFORE said document is allowed to progress from the wor= king group to publication. A list of these discussion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
  4. If this document is adopted by the working group, the= chairs specify as part of the adoption call that the following text descri= bing an open issue be added to the document in the above-described open issues section:
    • "Given th= at the working group has said that it wants to standardize one data plane s= olution, and given that the document contains multiple SRv6 EndPoint behavi= ors that some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

 

Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

--_000_AS8PR03MB76229CE9459F38BAFBC81D90EEB29AS8PR03MB7622eurp_-- From nobody Fri Oct 8 08:50:55 2021 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 28E4D3A00E5 for ; Fri, 8 Oct 2021 08:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 KJj1gllFbN2q for ; Fri, 8 Oct 2021 08:50:47 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (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 C8D7B3A0063 for ; Fri, 8 Oct 2021 08:50:46 -0700 (PDT) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) (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 opfednr26.francetelecom.fr (ESMTP service) with ESMTPS id 4HQt2D4MbNzyqC for ; Fri, 8 Oct 2021 17:50:44 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1633708244; bh=zULqNXPkQcqq3c/aTKuzFMTRxS/j+/GWGMo/BaTMfq8=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=k9FY6cbcZLgBSPlwZyq/3IpyQfncAxLlOiRvk8M21/lCmb+nQWcSNrlrHelPLo+qY 4GQrnHt/ujqK3CTJLGSmVLszizoGOiX+imNLcpiCWSodw0nixoKxI6n0QA4O9e+CAA 400Z3vpMdQayimtJLuuqhRu+dlZF7JqbrAZaYg0K6Xoj0SRuhIufdsq9+6fvxg8dqO O760Jw28iFoRrpQqlQF5z0TPZ/oECS8fpd9tMIUeYU3cJmgXfCHG++WrNiDZTjBzPy 84gPr5lSIdguQjU7ctDNs4gtn9DaW/HhyXLYdVyF8C0m1bLROprSvKCskoWJayL1zb B20KOUY37IqPQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr06.francetelecom.fr (ESMTP service) with ESMTPS id 4HQt2D3QFYzDq7q for ; Fri, 8 Oct 2021 17:50:44 +0200 (CEST) From: To: "spring@ietf.org" Thread-Topic: IPR declaration for draft-ietf-spring-mpls-path-segment Thread-Index: AQHXvFu31DLg0T565kW0tclosWmX7qvJP7Cg Date: Fri, 8 Oct 2021 15:50:43 +0000 Message-ID: <17049_1633708244_616068D4_17049_116_4_53C29892C857584299CBF5D05346208A4CEF3B9B@OPEXCAUBM43.corporate.adroot.infra.ftgroup> 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=2021-10-08T15:50:42Z; 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=; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2 x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A4CEF3B9BOPEXCAUBM43corp_" MIME-Version: 1.0 Archived-At: Subject: [spring] FW: IPR declaration for draft-ietf-spring-mpls-path-segment 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, 08 Oct 2021 15:50:52 -0000 --_000_53C29892C857584299CBF5D05346208A4CEF3B9BOPEXCAUBM43corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable From: Greg Mirsky Sent: Friday, October 8, 2021 5:47 PM To: James Guichard Cc: liu.aihua@zte.com.cn; royi.zigler@broadcom.com; spring-chairs@ietf.org;= draft-ietf-spring-mpls-path-segment@ietf.org Subject: Re: IPR declaration for draft-ietf-spring-mpls-path-segment Dear All, I am not aware of any undisclosed IPR related to this draft. Regards, Greg On Tue, Sep 21, 2021 at 5:43 AM James Guichard > wrote: Dear Authors/Contributors: As part of the WGLC for draft-ietf-spring-mpls-path-segment an acknowledgem= ent of IPR disclosure is expected to be completed. I have not yet seen a re= sponse from you with regards to this document. Please can you confirm wheth= er you are aware of any undisclosed IPR related to this document asap. Thanks! Jim Orange Restricted ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A4CEF3B9BOPEXCAUBM43corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

From: Greg Mirsky <gregimirsky@gmail.com>
Sent: Friday, October 8, 2021 5:47 PM
To: James Guichard <james.n.guichard@futurewei.com>
Cc: liu.aihua@zte.com.cn; royi.zigler@broadcom.com; spring-chairs@ie= tf.org; draft-ietf-spring-mpls-path-segment@ietf.org
Subject: Re: IPR declaration for draft-ietf-spring-mpls-path-segment=

 

Dear All,

I am not aware of any undisclosed IPR related to thi= s draft.

 

Regards,

Greg

 

On Tue, Sep 21, 2021 at 5:43 AM James Guichard <<= a href=3D"mailto:james.n.guichard@futurewei.com">james.n.guichard@futurewei= .com> wrote:

Dear Author= s/Contributors:

 =

As part of = the WGLC for draft-ietf-spring-mpls-path-segment an acknowledgement of IPR = disclosure is expected to be completed. I have not yet seen a response from you with regards to this document. Ple= ase can you confirm whether you are aware of any undisclosed IPR related to= this document asap.

 =

Thanks!

 =

Jim

 =

 =

 

Orange Restricted

______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A4CEF3B9BOPEXCAUBM43corp_-- From nobody Fri Oct 8 09:15:30 2021 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 3B4413A05A7; Fri, 8 Oct 2021 09:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBD00aKVD4TH; Fri, 8 Oct 2021 09:15:16 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2128.outbound.protection.outlook.com [40.107.237.128]) (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 AB7DB3A05E2; Fri, 8 Oct 2021 09:15:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DU4T3csVkIVi2ErLug/RLNciEnGoA8JNGs0f4zkWiExQa774fiabJM3+iP63TFwSd46vi7eJZkxmHcILNhGCab0NY36heVcIrCV34Fa7KTsaH0ubmVslCPogAIOlj2d4VmXkvjMkMjoQWQ4n02+YVYzFTZnEdKXUWNdTvIbxcvuBw3nxDIFz70t3rGiRabW5725C9XQIFHNeXn6vJk75HoV/jXhF/UCXkG+UVJiHeynsUXQ0Cw6BAyJv/oyAgTweV7Sf3CUq6lWegIzzI9QrupiwW7F1RC03Z9AsAZZCMblmeIgXD/SRBwrs30VxVpTzgaoeD9rOKgEhIFnDrO/1eg== 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=LupNC3aQOyNxpegol5Od4v9J1otlTPZbNiLJryQeSKk=; b=WHcdd851fCo0OXBcmGe2VoLrfBOxSWdCm90Ob27Kt9cP+CScay3E2EUlr5sUBaAjzzN6WhsKb/+r65DE3JlO63O/R0rfI0oByyUcfbXTIgify9yvViWntAqeGT4FJJtlFA0wikKelvJJmMO5wpNdZF2Ke0hvOiExjkyUQl3qT5dmDnG8e3O7PI9P+VGjudVhzge9KbaKwNV+HUPtjrSMjZrm5EAPbkrQo2VRQSDoSKuA5ybO/BHRfJaWb1wyN/2gH6Sdq4M4dyF0CuCTwVjVTnwdIwl0k8oJn/Pmg5KV8JGy5fbQ7FRcyHeVqGkrG7pTmB4sOI9NuTdHTV9pQdfTbA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LupNC3aQOyNxpegol5Od4v9J1otlTPZbNiLJryQeSKk=; b=UGw9/V276tZGayUqtFUW4NFPeeeBVsYDgWxq7H1vpyP+E5bU5pHH+XN6EqX+ZYvOAw92OeiuD5T7kB3jZoRWwH6ePDqC8nu71shn/a4kulyNl0kIOjHCLxRC14TqDSUrXJBgTUTjnwaWpns8UhOlBmRLDCBLNxHicKRZHNwVzXc= Received: from DM6PR13MB4204.namprd13.prod.outlook.com (2603:10b6:5:16d::19) by DM6PR13MB3371.namprd13.prod.outlook.com (2603:10b6:5:1cc::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.16; Fri, 8 Oct 2021 16:15:12 +0000 Received: from DM6PR13MB4204.namprd13.prod.outlook.com ([fe80::3d76:9c5e:9266:2c57]) by DM6PR13MB4204.namprd13.prod.outlook.com ([fe80::3d76:9c5e:9266:2c57%2]) with mapi id 15.20.4587.022; Fri, 8 Oct 2021 16:15:11 +0000 From: James Guichard To: Andrew Alston , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQFirUfwAAHlw2A= Date: Fri, 8 Oct 2021 16:15:11 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: liquidtelecom.com; dkim=none (message not signed) header.d=none;liquidtelecom.com; dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e51a1dbd-68c7-40fd-2e93-08d98a76ce2f x-ms-traffictypediagnostic: DM6PR13MB3371: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BNWir5xWLxceNDnvoUBkHGM4QbpRnKpRjw4OD7D3fvRI0UAfCrWTwftxDJm8aLcuWBe7WFrlDi09+f5eUQjFVya7b8uVHmswF0Tgt5FUaMeuKMkeq/RbMAH5QIEyLjrYG2OxN9ZfdFxoyBY3bkfzXZyUonQ+uANjkj7tXBDtxe2jm74RooscY7szLhkHbxxx9Z/y22HaSPpxxQ+42HdusL4YvOpf1/MnQu6rk5Sn5Zzk7hfrocdbeoG/94Ne2V+ax+6DI+O1XT0LcoaKYU4qKzekDgxzlAFAS8ChJzCHSxj0g8gRJ83J7+J7ZNNFJTWc7pFVi2WMPUQc+nR1wREq18qWreHBq3vqIqgK8QgN7BMzh8NXASSm/eeraZgVN2qALGEcXIPdV6zonoi5QtkuspP6pYt0SUhg0BCFzckFPCfDZPPC5Od+btUgWWXu6/Wg4AqYe5bMSMJbkIlhko2j4kytpJBWVFUPPAoE+Hq12mHzsH8TW5s6IRqs/1UNDmvouzQojIWvrPXBnr+YaL8qeJ5tWuPilBYDQPDICeo2MFMEgmoyE4s6xu+WI8jiaBhBPmQcofh50KbLXFIr9/mtj3C5lONtmpwOZmvN5LB3c1eOWgnz53UfUyQuakbifSG3HHCJC2myVidzWI2hoa8FrPYLJ1fvjw21jg/ZGJ2yhE+xxYO7kGp5MZn0662q+a7Jk/SSHSO0q2DBByCc4yjE1IOd1zSdQcfYW0ApcFHGyaN418qqmqlnMgK6aiKWEhkJqzUp9dHOBg616A6aad00BFqn3i4/MlZ3FE7YdZJdgi4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR13MB4204.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(76116006)(316002)(5660300002)(966005)(86362001)(8676002)(38100700002)(66946007)(33656002)(66476007)(122000001)(7696005)(38070700005)(166002)(53546011)(52536014)(83380400001)(2906002)(8936002)(66446008)(110136005)(9686003)(64756008)(6506007)(508600001)(4326008)(66556008)(71200400001)(55016002)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?m8D58O8KUIEWG8i4Og2GAswjpmgCxq/YHxfdVokeO5DbnXCLJs6bhd2+NLMv?= =?us-ascii?Q?Evj07mhTcg9H6VvgDFYf56Z7yT2FRqEfhmkvtEgPlHl5tILVQojV7hOnWk5m?= =?us-ascii?Q?PdyfJPlvGuAt4uQ6uEAzrZq3OUX5wVJl6CJtEUkZZ40Maw15mlAMt1jq57gB?= =?us-ascii?Q?Y0BlREwWjuiCCXALq5Cw22ExQzkFXKLxyC9j8HDixG+qv4EAm3YJlOOmUuXU?= =?us-ascii?Q?TxNGJGB2RvEEM/AIL/N39kaUlCK7i8Ux4fw18o5Un027c7POsYFIn5M24SA1?= =?us-ascii?Q?GZM+KRImvlknwDTZl4eQOgdG0+h1D+jSxpqa0es6iYNsRe8RKENaR7JbFNGB?= =?us-ascii?Q?8iwDZPEh3fXT2vyiGX0M5/rxWZQSF6fKveHLIFxgKynOWqpSN8FxzKJU9ZhF?= =?us-ascii?Q?UzPZvi/DdUadmAMxkKWlIxuSV5WfwP6eEQG8ob52hq+nEi1iNluoH/44753M?= =?us-ascii?Q?BoypPuMIaU99VxWbqXPKHXE5BuOkExzRdR0KlPGP+Mj37GDrE4p5XHx2OYyW?= =?us-ascii?Q?U3s2xLCu0izFgNcwQcgMpgOcOBtgf/b4cPd2doi78NrTQ4GyD+J/WsfHWRsy?= =?us-ascii?Q?CJ0kF+clL0SMmZdnZbjCXjWxZ1LsNmRlTgg9XcG0O4NEBK+u+dwDwNyUbEM/?= =?us-ascii?Q?B9G5jRuPGCYH3XeISoJ7wcvDWN+DclYnX5TV94Zemdj5v1L/bL5H3D4cPre0?= =?us-ascii?Q?rGsQx6o5Ji8PEa3ynMpMJBjwJAP5miD0n8kRD/x/8D8Bq9Lk8c24i26QunRT?= =?us-ascii?Q?IpiaszWmseqweNfAiEKbKQjZK9L2TIn6Pf2Pr52JR8iBpmL8qc1P3vDFmoIZ?= =?us-ascii?Q?g2QuGI5kivcd89+pf5/WpF1F+T7fKdqNUHO5U2nNJJs0zSvfITGp7c+RXHUy?= =?us-ascii?Q?YVxojoGnmDBsNjsZNBI9PNFWijofoWiSkArpAmKPR6pKdaIBTpXY2oPmY4Ny?= =?us-ascii?Q?nJAxqHmrB2pZLF5sieoGUB9P9G7SvCbd4ggmA8T7wJ+Kmf9UO9V9F4yWhA2W?= =?us-ascii?Q?I14xsx6o+Gygmn1ywGyBhO4p2jLgWMXCSrTthHkjxvgc6E7uRhL3TyDK7AI0?= =?us-ascii?Q?wMMpesVpHQnwebQyO78RmMA6HiKtHl751bGiUO89ryh2WGFDIrvpFEimkTD/?= =?us-ascii?Q?oNTyOI+MV7ROS5znzRvXrZo83A0Oixceeuo9tTi5+QVnzujRS2umefh8jt84?= =?us-ascii?Q?sOVe4qOggO8ABdd1QNu5I9WQawBg4VzbXGXEU6itk/ZKdxEvJSwpmRbNOYn+?= =?us-ascii?Q?dbbE0lq21bDpNfaHpjqaO0jQPkz1bk6tCu1uYU0GnaXtC6agPz1nFM4hJ8QR?= =?us-ascii?Q?TOCiVh9K3YtMzJKUHnP+/VopB7ucDypr4sf3PdX2o4lOEc5nknGRZO0FMuRw?= =?us-ascii?Q?cHc2CP72Lob5FV3Hej0l6gs4E35G?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR13MB4204153A33360C9024559F05D2B29DM6PR13MB4204namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR13MB4204.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e51a1dbd-68c7-40fd-2e93-08d98a76ce2f X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2021 16:15:11.8199 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: q++ENoipe7+gfQ+F7PI0mVrfAqn0gLuPT7kjMXMGS8NFYYZC75gtNm4bllQlk3IqiBZiM6z8+rbONCq6N0Ttwg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR13MB3371 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 08 Oct 2021 16:15:23 -0000 --_000_DM6PR13MB4204153A33360C9024559F05D2B29DM6PR13MB4204namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andrew, To your point D and in response to others that have expressed the same conc= ern. The chairs have already discussed this and are very aware of, and will conf= orm to, IETF process. As a co-author of the document in question I will of = course recuse myself from the decision process for adoption of the document= into the working group. This was never in question but let me make that po= int very clear now so that there is no further confusion or concern that th= e chairs will not follow standard procedures. Jim From: Andrew Alston Sent: Friday, October 8, 2021 11:23 AM To: James Guichard ; SPRING WG Cc: spring-chairs@ietf.org Subject: RE: WG Adoption call for https://datatracker.ietf.org/doc/draft-fi= lsfilscheng-spring-srv6-srh-compression/ Figured I would weigh in here once again - and try and summarize the way I = see things. 1. The working group found consensus on a single behavior - this documen= t contains 3 - if that consensus is to be changed - let it be changed by th= e working group before we walk down this path. 2. The charter of the spring working group is very clear - it states: Any modification of -or extension to- existing architectures, data planes, = or control or management plane protocols should be carried out in the WGs r= esponsible for the architecture, data plane, or control or management plane= protocol being modified and in coordination with the SPRING WG, but may be= done in SPRING WG after agreement with all the relevant WG chairs and resp= onsible area directors. I have yet to see each agreement voiced by these parties. 1. There is technical dispute over the overloading of addresses and the = use of IPv6 addresses in this manner, and if the excuse of limited domain i= s valid to get away with this - this has not been resolved 2. Two out of the three working group chairs who are actively involved i= n calling for the adoption of this document are co-authors of said document= and have not recused themselves and stated they will not take part in deci= sions regarding its progression - the term - conflict of interest - was cre= ated for such situations 3. There have been suggestions on this list about splitting g-srv6 out -= so that it can proceed, since it does NOT seem to run afoul of (B) and the= n if the working group sees fit to agree to change the view on single behav= ior, the csid parts could be processed separately should the chairs and ad'= s involved in the INT group agree - this suggestion has never had a full re= sponse or a reason why this is either impractical or should not go ahead - = and under the definition of rough consensus therefore stands as an unaddres= sed issued. I am kinda shocked in a situation where almost any one of these points woul= d be sufficient to act as a blocker - we are still walking down this path -= I lament the lack of adherence to the bottom up approach that I am seeing = here, and the disregard shown towards clear conflicts of interest, particul= arly where there are scenarios under which we could all progress that would= resolve half of the issues above. Let us act in a way that is in adherence to the bottom-up approach, respect= s working group consensus, avoids conflicts of interest, follows the charte= r and eventually ends up in a place where distrust in the process is allowe= d to fester. Thanks Andrew From: spring > On B= ehalf Of James Guichard Sent: Friday, October 1, 2021 5:05 PM To: SPRING WG > Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardization work. That is part of wh= at this email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some cle= ar guidelines as follows. By expressing support for adoption of this docume= nt you are fully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_DM6PR13MB4204153A33360C9024559F05D2B29DM6PR13MB4204namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andrew,

 

To your point D and in response to others that have = expressed the same concern.

 

The chairs have already discussed this and are very = aware of, and will conform to, IETF process. As a co-author of the document= in question I will of course recuse myself from the decision process for a= doption of the document into the working group. This was never in question but let me make that point very clear no= w so that there is no further confusion or concern that the chairs will not= follow standard procedures.

 

Jim

 

From: Andrew Alston <Andrew.Alston@liquidt= elecom.com>
Sent: Friday, October 8, 2021 11:23 AM
To: James Guichard <james.n.guichard@futurewei.com>; SPRING WG= <spring@ietf.org>
Cc: spring-chairs@ietf.org
Subject: RE: WG Adoption call for https://datatracker.ietf.org/doc/d= raft-filsfilscheng-spring-srv6-srh-compression/

 

Figured I would weigh in here once again – and= try and summarize the way I see things.

 

  1. The working group found consensus on a single behavior – this d= ocument contains 3 – if that consensus is to be changed – let i= t be changed by the working group before we walk down this path.
  2. The charter of the spring working group is= very clear – it states:

Any modification of -or extension to- existin= g architectures, data planes, or control or management plane protocols shou= ld be carried out in the WGs responsible for the architecture, data plane, = or control or management plane protocol being modified and in coordination with the SPRING WG, but may be done in = SPRING WG after agreement with all the relevant WG chairs and responsible a= rea directors.

        &nbs= p;     I have yet to see each agreement voiced by these= parties.

  1. There is technical dispute over the overloading of addresses and the = use of IPv6 addresses in this manner, and if the excuse of limited domain i= s valid to get away with this – this has not been resolved
  2. Two out of the three working g= roup chairs who are actively involved in calling for the adoption of this d= ocument are co-authors of said document and have not recused themselves and stated they will not take part in decisions regarding its progression R= 11; the term – conflict of interest – was created for such situ= ations
  3. There have been suggestions on this list about = splitting g-srv6 out – so that it can proceed, since it does NOT seem= to run afoul of (B) and then if the working group sees fit to agree to change the view on single behavior, the csid parts could be processed s= eparately should the chairs and ad’s involved in the INT group agree = – this suggestion has never had a full response or a reason why this = is either impractical or should not go ahead – and under the definition of rough consensus therefore stands as an= unaddressed issued.

 

I am kinda shocked in a situation where almost any o= ne of these points would be sufficient to act as a blocker – we are s= till walking down this path – I lament the lack of adherence to the b= ottom up approach that I am seeing here, and the disregard shown towards clear conflicts of interest, particularly where th= ere are scenarios under which we could all progress that would resolve half= of the issues above.

 

Let us act in a way that is in adherence to the bott= om-up approach, respects working group consensus, avoids conflicts of inter= est, follows the charter and eventually ends up in a place where distrust i= n the process is allowed to fester.

 

Thanks

 

Andrew

 

From: spring <spring-bounces@ietf.org> On Behalf Of James Guichard
Sent: Friday, October 1, 2021 5:05 PM
To: SPRING WG <spring@ietf.org= >
Cc: spring-chairs@ietf.org=
Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/

 

Dear WG:

 

The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

 

The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

 

Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

 

  1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors.
  2. The document is a “living” document; it m= ay change as it goes through review and analysis by the SPRING working grou= p.
  3. All open discussion points raised on our mailing list= MUST be addressed BEFORE said document is allowed to progress from the wor= king group to publication. A list of these discussion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
  4. If this document is adopted by the working group, the= chairs specify as part of the adoption call that the following text descri= bing an open issue be added to the document in the above-described open issues section:
    • "Given th= at the working group has said that it wants to standardize one data plane s= olution, and given that the document contains multiple SRv6 EndPoint behavi= ors that some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

 

Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

--_000_DM6PR13MB4204153A33360C9024559F05D2B29DM6PR13MB4204namp_-- From nobody Fri Oct 8 09:17:01 2021 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 A20CF3A05DE; Fri, 8 Oct 2021 09:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 H3T_XGkRBB0m; Fri, 8 Oct 2021 09:16:53 -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 C56E83A05A7; Fri, 8 Oct 2021 09:16:52 -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 opfedar24.francetelecom.fr (ESMTP service) with ESMTPS id 4HQtcM2VKVz5wNm; Fri, 8 Oct 2021 18:16:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1633709811; bh=bkixmGvnDvmo4IpnctxOLXZBFViXgusisv4xUcNerzI=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=DG2yXgi7VUwJXU9N5lr1xoAA0cFN4SfkCrFFcQoWdZgwuBWLcja8A3qPQ37WaB1kS Ay/YTybJC4cqMb/KLRJ1mjjAjNN7wt7g5rbAJ89VG0jnaZ010BLmCfTPoFX3Lo0+FY Ly3e5iOYlA9L0WBngOBuMOG6MIgA93LWvzuVmcV5lMvdrT2BxmigwKHnePguhren9n btzrU9IsaxRcsPgS3OEpSxpAngdMOd2bJdoFagX23nHa9KUwcpJnBqpL1G6NCBsg0t uUx61QYHQUD2MFtdHNkHF2qt+ach4p4rKEQuRM+527p5DlgNaqzpXU6116XJUAkhH1 vsVfmul+xXxsg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar04.francetelecom.fr (ESMTP service) with ESMTPS id 4HQtcM16zZz1xpK; Fri, 8 Oct 2021 18:16:51 +0200 (CEST) From: To: Kireeti Kompella , SPRING WG CC: "spring-chairs@ietf.org" , "Martin Vigoureux (martin.vigoureux@nokia.com)" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: AQHXu7VIAYyWLN0OQYGZaAvNV9N3davJQ+Fg Date: Fri, 8 Oct 2021 16:16:49 +0000 Message-ID: <10812_1633709811_61606EF3_10812_95_1_53C29892C857584299CBF5D05346208A4CEF3DCD@OPEXCAUBM43.corporate.adroot.infra.ftgroup> References: <2D3AD4E3-2C84-4F8D-9AF3-7D3330CC4311@gmail.com> In-Reply-To: <2D3AD4E3-2C84-4F8D-9AF3-7D3330CC4311@gmail.com> 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=2021-10-08T16:16:49Z; 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=; MSIP_Label_f47c794b-e3ab-43f0-9e0f-29fc3e503192_ContentBits=2 x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A4CEF3DCDOPEXCAUBM43corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 08 Oct 2021 16:16:59 -0000 --_000_53C29892C857584299CBF5D05346208A4CEF3DCDOPEXCAUBM43corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Kireeti, all, Being a co-author of draft-filsfilscheng-spring-srv6-srh-compression, I rec= use myself from assessing the WG consensus on this document. --Bruno Orange Restricted From: spring On Behalf Of Kireeti Kompella Sent: Thursday, October 7, 2021 9:56 PM To: James Guichard Cc: Kireeti Kompella ; SPRING WG ;= spring-chairs@ietf.org Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ I also object to WG chairs who are also co-authors of a draft participating= in the process of advancing the draft through the WG process, whether it i= s WG adoption, WGLC or IETF LC. Look up "recuse" in the dictionary. :K On Oct 1, 2021, at 07:04, James Guichard > wrote: Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th forhttps://datatracker.ietf.org/doc/draft-filsfi= lscheng-spring-srv6-srh-compression/ but with some clear guidelines as foll= ows. By expressing support for adoption of this document you are fully awar= e of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A4CEF3DCDOPEXCAUBM43corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Kireeti, all,

 

Being a co-author of draft-filsfilscheng-spring-srv6-srh-= compression, I recuse myself from assessing the WG consensus on this docume= nt.

 

--Bruno

 

 

 

Orange Restricted

From: spring <spring-bounces@ietf.org> On Behalf Of Kireeti Kompella
Sent: Thursday, October 7, 2021 9:56 PM
To: James Guichard <james.n.guichard@futurewei.com>
Cc: Kireeti Kompella <kireeti.ietf@gmail.com>; SPRING WG <s= pring@ietf.org>; spring-chairs@ietf.org
Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.= org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<= /p>

 

I also object to WG chairs who are also co-authors of a dra= ft participating in the process of advancing the draft through the WG proce= ss, whether it is WG adoption, WGLC or IETF LC.

 

Look up “recuse” in the dictionary.<= /span>

 

:K



On Oct 1, 2021, at 07:04, James Guichard <james.n.guichard@futurewei.com> = wrote:

 

Dear WG:

 

The chairs would like to express their appreciation for all= the responses received to our emails with reference to how the working gro= up wishes to move forward with respect to a solution for SRv6 compression.

 

 

Because of the above the chairs would like to issue a 2-wee= k WG call for adoption ending October 15th forhttps://datatracker.ietf= .org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ but with some clear guidelines as follows. By expressing support for adoption = of this document you are fully aware of and are acknowledging that:

 

  1. The SPR= ING working group is adopting a document that has multiple SRv6 Endpoint be= haviors.
  2. The doc= ument is a “living” document; it may change as it goes through = review and analysis by the SPRING working group.
  3. All ope= n discussion points raised on our mailing list MUST be addressed BEFORE sai= d document is allowed to progress from the working group to publication. A = list of these discussion points will be documented in the WG document and maintained by the document editor in conjunction wi= th the chairs.
  4. If this= document is adopted by the working group, the chairs specify as part of th= e adoption call that the following text describing an open issue be added t= o the document in the above-described open issues section:
    • "G= iven that the working group has said that it wants to standardize one data = plane solution, and given that the document contains multiple SRv6 EndPoint= behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this is valid= and coherent with its one data plane solution objective.".=

 

Please consider the above guidelines as you decide on wheth= er to support or not this WG adoption. Please express clearly your reasonin= g for support/non-support as well as any open discussion points you would like addressed should the document be adopted = into the working group.

 

Thanks!

 

Jim, Bruno & Joel

 

 

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

 

______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A4CEF3DCDOPEXCAUBM43corp_-- From nobody Fri Oct 8 09:23:14 2021 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 EF7603A05DE for ; Fri, 8 Oct 2021 09:23:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aelmans.eu 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 rAUv90traddx for ; Fri, 8 Oct 2021 09:23:06 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 C45B03A05E2 for ; Fri, 8 Oct 2021 09:23:05 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id 64so7114217uab.12 for ; Fri, 08 Oct 2021 09:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aelmans.eu; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=75gKYf7tJhnuzT9shZItT8a/ArbZxHwaR3PzZ02uLyI=; b=hy2KWSDxL1phWUZeyJBUJmXMWxFVhJD3sA/ynX6vy7YNdSilwuIUE7i0DsDX60tQu/ BOL3lwZSAi7sO6b5inUoouGpL5Bxq8XvykcBnQCzQN6oZ1Agv9S8R6FwnrJIE3m3DOsh kUU9JhAHNmMAsbXh/uWimOfED64381CygzxIRwskKUPzjQZFg85EoLJx83gHdydKhLWI UgD/BbCcJ3hYBKf9o8MIc8Ye/aoFe6N6VWca7GSOJjYzvOt8SxPyPTMpKfqx5KPA9n8+ GkU/aMyNiWwLqzDX2FooRRqiXn5exVlRuskeao43efyoEmGWgzAR5zsKvDrhFGNfWzLt bM3w== 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=75gKYf7tJhnuzT9shZItT8a/ArbZxHwaR3PzZ02uLyI=; b=RG5e8lWxrZXTbkKyNcdzPqtNRMGUztwH4Yuc8fWZeGnjBLu6Yrov2nOZd7SjLk2nTy AMnQrFg+ifAvTpTwL81eFTH5Jq2vRnKLFCZPmC8RC0SbXuYlrMNsaPJEyhl3onjnOyRA /woYUIGDIeqOktiO+eE9yyYQybnLWLBes4Hd99f6wi1msU3KcR/Jq4+OMqGDuaitdTC9 5kfpE9MPXq5J1s0NOmGwWcwC/w3kWurcHv1BZHLp9RBvx+XL90rvzjCd/dbxr2Z5oq9u KJtUXlUDZQhvPqglbI3D+p+c83xWPJpZt9Wl/8Kz417BsuNZUqCRSCuhUqk5QteLZBGO R4WQ== X-Gm-Message-State: AOAM533CJYldmxNQjsj3bV8gK/pU3j99SeIk+cyu4HNzgf/FGwWvhKX3 N6Gi0mhPrZpPhN6wlrBiErbnBh/6qgetiEyExsJAuQ== X-Google-Smtp-Source: ABdhPJyWEM3AKZxuDz18wQBK8UeBHKgiEK8lHlX9EvN89kIceiS/FMs4iDlHVTg4HdiNO7uP7Py1dLf/hAMwYrq8tlM= X-Received: by 2002:a9f:24c4:: with SMTP id 62mr3925669uar.95.1633710184081; Fri, 08 Oct 2021 09:23:04 -0700 (PDT) MIME-Version: 1.0 References: <03B8E50C-B8FA-4DCB-A4E4-91C33590E57C@tony.li> In-Reply-To: <03B8E50C-B8FA-4DCB-A4E4-91C33590E57C@tony.li> From: Melchior Aelmans Date: Fri, 8 Oct 2021 18:22:52 +0200 Message-ID: To: Tony Li Cc: Andrew Alston , James Guichard , SPRING WG , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000303e4c05cdd9cbf6" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 08 Oct 2021 16:23:12 -0000 --000000000000303e4c05cdd9cbf6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Agree with the objection. I don't see how this can progress in the current state and situation and decisions in this WG being made earlier on this. Thanks, Melchior On Fri, Oct 1, 2021 at 10:55 PM Tony Li wrote: > > +1 > > I object to the adoption. > > Tony > > > On Oct 1, 2021, at 1:43 PM, Andrew Alston < > Andrew.Alston=3D40liquidtelecom.com@dmarc.ietf.org> wrote: > > Just to add to this, > > I am one of the people who clearly stated that I didn=E2=80=99t think a s= ingle > solution was the right answer here =E2=80=93 and I stated my reasoning cl= early on > this list. I still believe that =E2=80=93 however =E2=80=93 I recognize = that the > foundation of the IETF is found in the bottom up consensus approach =E2= =80=93 and > when the working group has demonstrated such clear consensus =E2=80=93 to= defy that > =E2=80=93 is to defy what makes the IETF the IETF. > > So =E2=80=93 While I still believe in multiple solutions =E2=80=93 irresp= ective of that =E2=80=93 > I find this call appalling =E2=80=93 because as much as I believe in mult= iple > solutions =E2=80=93 the working group consensus should be sacrosanct. > > Andrew > > > > *From: *Andrew Alston > *Date: *Friday, 1 October 2021 at 23:21 > *To: *James Guichard , SPRING WG < > spring@ietf.org> > *Cc: *spring-chairs@ietf.org > *Subject: *Re: WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > Sorry =E2=80=93 but =E2=80=93 I=E2=80=99m a little confused here. > > Because the way I look at this =E2=80=93 the working group clearly stated= that > they wished for a single behavior =E2=80=93 and this =E2=80=93 does not d= eliver that =E2=80=93 it > is two separate behaviors. As such =E2=80=93 I see this call for adoptio= n =E2=80=93 > irrespective of the merits or lack thereof of the draft, as a clear > defiance of the stated will of the working group. > > This is simply does not fit into the definition of bottom up approach in > my opinion =E2=80=93 and if this is the way that the chairs wish to proce= ed =E2=80=93 then > the only way to do that and still fit within the bottom up approach is to > first ask this working group for its consensus to deviate from the single > behacvior approach that the working group agreed to. > > As such =E2=80=93 I must strongly and unequivocally object to this call = for > adoption > > Andrew > > > *From: *spring on behalf of James Guichard < > james.n.guichard@futurewei.com> > *Date: *Friday, 1 October 2021 at 17:05 > *To: *SPRING WG > *Cc: *spring-chairs@ietf.org > *Subject: *[spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > Dear WG: > > The chairs would like to express their appreciation for all the responses > received to our emails with reference to how the working group wishes to > move forward with respect to a solution for SRv6 compression. > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > as the basis for its compression standardization work. That is part of > what this email attempts to confirm. > > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging th= at: > > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change = as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the working > group to publication. A list of these discussion points will be docume= nted > in the WG document and maintained by the document editor in conjunctio= n > with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text describin= g an > open issue be added to the document in the above-described open issues > section: > - "Given that the working group has said that it wants to > standardize one data plane solution, and given that the document co= ntains > multiple SRv6 EndPoint behaviors that some WG members have stated a= re > multiple data plane solutions, the working group will address wheth= er this > is valid and coherent with its one data plane solution objective.". > > > Please consider the above guidelines as you decide on whether to support > or not this WG adoption. Please express clearly your reasoning for > support/non-support as well as any open discussion points you would like > addressed should the document be adopted into the working group. > > Thanks! > > Jim, Bruno & Joel > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --000000000000303e4c05cdd9cbf6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agree with the objection. I don't see how this can pro= gress in the current state and situation and decisions in this WG being mad= e earlier on this.

Thanks,
Melchior

On Fr= i, Oct 1, 2021 at 10:55 PM Tony Li <t= ony.li@tony.li> wrote:

+1
I object to the adoption.

Tony


On Oct 1, 2021, at 1:4= 3 PM, Andrew Alston <Andrew.Alston=3D40liquidtelecom.com@dm= arc.ietf.org> wrote:

Just to add to this,
=C2=A0
I am one of the people who= clearly stated that I didn=E2=80=99t think a single solution was the right= answer here =E2=80=93 and I stated my reasoning clearly on this list.=C2= =A0 I still believe that =E2=80=93 however =E2=80=93 I recognize that the f= oundation of the IETF is found in the bottom up consensus approach =E2=80= =93 and when the working group has demonstrated such clear consensus =E2=80= =93 to defy that =E2=80=93 is to defy what makes the IETF the IETF.<= u>
=C2=A0
So =E2=80=93 While I still believe in multiple solutions =E2= =80=93 irrespective of that =E2=80=93 I find this call appalling =E2=80=93 = because as much as I believe in multiple solutions =E2=80=93 the working gr= oup consensus should be sacrosanct.
=C2=A0
Andrew
=C2=A0
= =C2=A0

From:=C2=A0Andrew Alston <Andrew.Alston@liquidtelecom.com>= ;
Date:=C2=A0Friday, 1 October 2021 at 23:21
T= o:=C2=A0James Guichard <james.n.guichard@futurewei.com>, SPRING WG <spring@ietf.org>
Cc:=C2= =A0spring-chairs@ietf.o= rg=C2=A0<sprin= g-chairs@ietf.org>
Subject:=C2=A0Re: WG Adopt= ion call for=C2=A0https://datatracker.ietf.o= rg/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Sorry =E2=80=93 but =E2=80=93 I=E2=80=99m = a little confused here.
= =C2=A0
Because the way I look at this = =E2=80=93 the working group clearly stated that they wished for a single be= havior =E2=80=93 and this =E2=80=93 does not deliver that =E2=80=93 it is t= wo separate behaviors.=C2=A0 As such =E2=80=93 I see this call for adoption= =E2=80=93 irrespective of the merits or lack thereof of the draft, as a cl= ear defiance of the stated will of the working group.<= /div>
=C2=A0
T= his is simply does not fit into the definition of bottom up approach in my = opinion =E2=80=93 and if this is the way that the chairs wish to proceed = =E2=80=93 then the only way to do that and still fit within the bottom up a= pproach is to first ask this working group for its consensus to deviate fro= m the single behacvior approach that the working group agreed to.=
=C2=A0
As such =E2=80=93 I must =C2=A0strongly and unequivocally object= to this call for adoption
<= /u>=C2=A0
Andrew<= /div>
=C2=A0

From:=C2=A0spring <spring-bounces@ietf= .org> on behalf of James Guichard <james.n.guichard@futurewei.com>= ;
Date:=C2=A0Friday, 1 October 2021 at 17:05
T= o:=C2=A0SPRING WG <spring@ietf.org>
Cc:=C2=A0spring-chairs@iet= f.org <s= pring-chairs@ietf.org>
Subject:=C2=A0[spring]= WG Adoption call for https://datatrac= ker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

Dear WG:
= =C2=A0
The= chairs would like to express their appreciation for all the responses rece= ived to our emails with reference to how the working group wishes to move f= orward with respect to a solution for SRv6 compression.
=C2=A0
The apparent inclination of the working group is to use=C2=A0= https://datatracker.ietf.org/doc/draft-filsfilscheng-spri= ng-srv6-srh-compression/=C2=A0as the basis for its compres= sion standardization work. That is part of what this email attempts to conf= irm.
=C2=A0
Because of the above the chairs would like to issu= e a 2-week WG call for adoption ending October 15th=C2=A0<= /span>for=C2=A0https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/=C2=A0= but with some clear guidelines as follows. By expressing support for adopti= on of this document you are fully aware of and are acknowledging that:
=C2=A0
  • The SPRING working group is adopting a document that has multipl= e SRv6 Endpoint behaviors.
  • The do= cument is a =E2=80=9Cliving=E2=80=9D document; it may change as it goes thr= ough review and analysis by the SPRING working group.<= /li>
  • = All open discussion points raised on our mailing list = MUST be addressed BEFORE said document is allowed to progress from the work= ing group to publication. A list of these discussion points will be documen= ted in the WG document and maintained by the document editor in conjunction= with the chairs.
  • If this documen= t is adopted by the working group, the chairs specify as part of the adopti= on call that the following text describing an open issue be added to the do= cument in the above-described open issues section:
    • "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.".
    =C2=A0
    Please consider the above guidelines as you decide on whether to= support or not this WG adoption. Please express clearly your reasoning for= support/non-support as well as any open discussion points you would like a= ddressed should the document be adopted into the working group.
    =C2=A0
    Thanks!
    =C2= =A0
    Jim, Bruno & Joel
    =C2=A0
    =C2=A0
    • _______________________________________________<= br style=3D"font-family:Helvetica;font-size:14px;font-style:normal;font-var= iant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;= text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;tex= t-decoration:none">spring m= ailing list
    spring@ietf= .org
    https://www.ietf.org/mailman/listinfo/spring

    ______________________________________________= _
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --000000000000303e4c05cdd9cbf6-- From nobody Fri Oct 8 09:53:13 2021 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 31E613A0872; Fri, 8 Oct 2021 09:53:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.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 dJRlHtXdaCtU; Fri, 8 Oct 2021 09:53:06 -0700 (PDT) Received: from out0-147.mail.aliyun.com (out0-147.mail.aliyun.com [140.205.0.147]) (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 2B5913A0875; Fri, 8 Oct 2021 09:53:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1633711981; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=TJjAalzckIrbHAS9AyfPoKZSDxyWB+75N1p0ThV+gRY=; b=I+ijkkUojyYka4RasYb5Hruw8TbYuGYsPVOHjwTREVVviO7VQVhA93wAk7dzoZVMVtxdXAxAR1kr56oFrVKuSOvGUYTudyRtBO2iOhYwDTqQuRKdM8ow6CIvWnfYWIC9dzq3nstmzvY0FrAS/rgp7sikOyuVad2Zcwb3Zd9y/Dw= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R221e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=ay29a033018047212; MF=yitai.syc@alibaba-inc.com; NM=1; PH=DW; RN=3; SR=0; TI=W4_0.1.10_DEFAULT_0AC264F9_1633711345257_o7001c512t; Received: from WS-web (yitai.syc@alibaba-inc.com[W4_0.1.10_DEFAULT_0AC264F9_1633711345257_o7001c512t]) by ay29a011140100207.et135 at Sat, 09 Oct 2021 00:52:56 +0800 Date: Sat, 09 Oct 2021 00:52:56 +0800 From: "=?UTF-8?B?6IuP6L+c6LaFKOS7peazsCk=?=" To: "SPRING WG" , "spring" Cc: "spring-chairs@ietf.org" Reply-To: "=?UTF-8?B?6IuP6L+c6LaFKOS7peazsCk=?=" Message-ID: <0b8434e0-270c-438b-b6be-fd9ad29e3bf0.yitai.syc@alibaba-inc.com> X-Mailer: [Alimail-Mailagent revision 2][W4_0.1.10][DEFAULT][Chrome] MIME-Version: 1.0 References: x-aliyun-mail-creator: W4_0.1.10_DEFAULT_M3LTW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfMTVfNSkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzgxLjAuNDA0NC4xMzggU2FmYXJpLzUzNy4zNg==vN In-Reply-To: Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_88141_7f3cf6bd1700_61607768_c0d6cd" Archived-At: Subject: [spring] =?utf-8?b?5Zue5aSN77yaIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0?= =?utf-8?q?tps=3A//datatracker=2Eietf=2Eorg/doc/draft-filsfilscheng-spring?= =?utf-8?q?-srv6-srh-compression/?= 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, 08 Oct 2021 16:53:12 -0000 ------=ALIBOUNDARY_88141_7f3cf6bd1700_61607768_c0d6cd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgRGVhciBXR++8jAogICAgSSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0Lgog ICAgQm90aCBuZXh0IGFuZCByZXBsYWNlIGZsYXZvcnMgYXJlIGNvbnNpc3RlbnQgd2l0aCB0aGUg U1J2NiBuZXR3b3JrIHByb2dyYW1taW5nKFJGQyA4OTg2KWFuZCB1c2VzIFNSSCBiYXNlZCBkYXRh IHBsYW5lKFJGQyA4NzU0KSwgdGhlcmVmb3JlIEkgZG9uJ3QgY29uc2lkZXIgdGhlc2UgdHdvIGZs YXZvcnMgYXJlIHR3byBzb2x1dGlvbnMgYnV0IGZsZXhpYmlsaXRpZXMgZm9yIGRpZmZlcmVudCBz Y2VuYXJpb3MuIAogICAgUHJvY2VlZGluZyB3aXRoIENTSUQgd291bGQgaGVscCBjcmVhdGUgYSBy b2J1c3QgZWNvLXN5c3RlbSB3aGljaCB3ZSBjb3VsZCBsZXZlcmFnZS4KICAgIFRoYW5rcy4KCiAg ICAgICAgICBZdWFuY2hhbyBTdQogICAgICAgICAgQWxpQ2xvdWQgTmV0d29yayBEaXJlY3Rvcgog Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQrlj5Hku7bkurrvvJpKYW1lcyBHdWljaGFyZCA8amFtZXMubi5ndWljaGFyZEBm dXR1cmV3ZWkuY29tPgrlj5HpgIHml7bpl7TvvJoyMDIx5bm0MTDmnIgx5pelKOaYn+acn+S6lCkg MjI6MDUK5pS25Lu25Lq677yaU1BSSU5HIFdHIDxzcHJpbmdAaWV0Zi5vcmc+CuaKhOOAgOmAge+8 mnNwcmluZy1jaGFpcnNAaWV0Zi5vcmcgPHNwcmluZy1jaGFpcnNAaWV0Zi5vcmc+CuS4u+OAgOmi mO+8mltzcHJpbmddIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9u LwoKCkRlYXIgV0c6ClRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBleHByZXNzIHRoZWlyIGFwcHJl Y2lhdGlvbiBmb3IgYWxsIHRoZSByZXNwb25zZXMgcmVjZWl2ZWQgdG8gb3VyIGVtYWlscyB3aXRo IHJlZmVyZW5jZSB0byBob3cgdGhlIHdvcmtpbmcgZ3JvdXAgd2lzaGVzIHRvIG1vdmUgZm9yd2Fy ZCB3aXRoIHJlc3BlY3QgdG8gYSBzb2x1dGlvbiBmb3IgU1J2NiBjb21wcmVzc2lvbi4gClRoZSBh cHBhcmVudCBpbmNsaW5hdGlvbiBvZiB0aGUgd29ya2luZyBncm91cCBpcyB0byB1c2UgIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNy djYtc3JoLWNvbXByZXNzaW9uLyBhcyB0aGUgYmFzaXMgZm9yIGl0cyBjb21wcmVzc2lvbiBzdGFu ZGFyZGl6YXRpb24gd29yay4gVGhhdCBpcyBwYXJ0IG9mIHdoYXQgdGhpcyBlbWFpbCBhdHRlbXB0 cyB0byBjb25maXJtLgpCZWNhdXNlIG9mIHRoZSBhYm92ZSB0aGUgY2hhaXJzIHdvdWxkIGxpa2Ug dG8gaXNzdWUgYSAyLXdlZWsgV0cgY2FsbCBmb3IgYWRvcHRpb24gZW5kaW5nIE9jdG9iZXIgMTV0 aCBmb3IgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hl bmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyBidXQgd2l0aCBzb21lIGNsZWFyIGd1aWRl bGluZXMgYXMgZm9sbG93cy4gQnkgZXhwcmVzc2luZyBzdXBwb3J0IGZvciBhZG9wdGlvbiBvZiB0 aGlzIGRvY3VtZW50IHlvdSBhcmUgZnVsbHkgYXdhcmUgb2YgYW5kIGFyZSBhY2tub3dsZWRnaW5n IHRoYXQ6IAoKVGhlIFNQUklORyB3b3JraW5nIGdyb3VwIGlzIGFkb3B0aW5nIGEgZG9jdW1lbnQg dGhhdCBoYXMgbXVsdGlwbGUgU1J2NiBFbmRwb2ludCBiZWhhdmlvcnMuIApUaGUgZG9jdW1lbnQg aXMgYSDigJxsaXZpbmfigJ0gZG9jdW1lbnQ7IGl0IG1heSBjaGFuZ2UgYXMgaXQgZ29lcyB0aHJv dWdoIHJldmlldyBhbmQgYW5hbHlzaXMgYnkgdGhlIFNQUklORyB3b3JraW5nIGdyb3VwLiAKQWxs IG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgcmFpc2VkIG9uIG91ciBtYWlsaW5nIGxpc3QgTVVTVCBi ZSBhZGRyZXNzZWQgQkVGT1JFIHNhaWQgZG9jdW1lbnQgaXMgYWxsb3dlZCB0byBwcm9ncmVzcyBm cm9tIHRoZSB3b3JraW5nIGdyb3VwIHRvIHB1YmxpY2F0aW9uLiBBIGxpc3Qgb2YgdGhlc2UgZGlz Y3Vzc2lvbiBwb2ludHMgd2lsbCBiZSBkb2N1bWVudGVkIGluIHRoZSBXRyBkb2N1bWVudCBhbmQg bWFpbnRhaW5lZCBieSB0aGUgZG9jdW1lbnQgZWRpdG9yIGluIGNvbmp1bmN0aW9uIHdpdGggdGhl IGNoYWlycy4gCklmIHRoaXMgZG9jdW1lbnQgaXMgYWRvcHRlZCBieSB0aGUgd29ya2luZyBncm91 cCwgdGhlIGNoYWlycyBzcGVjaWZ5IGFzIHBhcnQgb2YgdGhlIGFkb3B0aW9uIGNhbGwgdGhhdCB0 aGUgZm9sbG93aW5nIHRleHQgZGVzY3JpYmluZyBhbiBvcGVuIGlzc3VlIGJlIGFkZGVkIHRvIHRo ZSBkb2N1bWVudCBpbiB0aGUgYWJvdmUtZGVzY3JpYmVkIG9wZW4gaXNzdWVzIHNlY3Rpb246CiJH aXZlbiB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBzYWlkIHRoYXQgaXQgd2FudHMgdG8gc3Rh bmRhcmRpemUgb25lIGRhdGEgcGxhbmUgc29sdXRpb24sIGFuZCBnaXZlbiB0aGF0IHRoZSBkb2N1 bWVudCBjb250YWlucyBtdWx0aXBsZSBTUnY2IEVuZFBvaW50IGJlaGF2aW9ycyB0aGF0IHNvbWUg V0cgbWVtYmVycyBoYXZlIHN0YXRlZCBhcmUgbXVsdGlwbGUgZGF0YSBwbGFuZSBzb2x1dGlvbnMs IHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYWRkcmVzcyB3aGV0aGVyIHRoaXMgaXMgdmFsaWQgYW5k IGNvaGVyZW50IHdpdGggaXRzIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uIG9iamVjdGl2ZS4iLgpQ bGVhc2UgY29uc2lkZXIgdGhlIGFib3ZlIGd1aWRlbGluZXMgYXMgeW91IGRlY2lkZSBvbiB3aGV0 aGVyIHRvIHN1cHBvcnQgb3Igbm90IHRoaXMgV0cgYWRvcHRpb24uIFBsZWFzZSBleHByZXNzIGNs ZWFybHkgeW91ciByZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9uLXN1cHBvcnQgYXMgd2VsbCBhcyBh bnkgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyB5b3Ugd291bGQgbGlrZSBhZGRyZXNzZWQgc2hvdWxk IHRoZSBkb2N1bWVudCBiZSBhZG9wdGVkIGludG8gdGhlIHdvcmtpbmcgZ3JvdXAuClRoYW5rcyEK SmltLCBCcnVubyAmIEpvZWwKCg== ------=ALIBOUNDARY_88141_7f3cf6bd1700_61607768_c0d6cd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iX19hbGl5dW5fZW1haWxfYm9keV9ibG9jayI+PGRpdiAgc3R5bGU9ImNsZWFy OmJvdGg7Ij48c3BhbiAgc3R5bGU9ImZvbnQtZmFtaWx5OlRhaG9tYSxBcmlhbCxTVEhlaXRpLFNp bVN1bjtjb2xvcjojMDAwMDAwO2ZvbnQtc2l6ZToxNC4wcHg7Ij5IaSBEZWFyIFdH77yMPC9zcGFu PjwvZGl2PjxkaXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+PHNwYW4gIHN0eWxlPSJmb250LWZhbWls eTpUYWhvbWEsQXJpYWwsU1RIZWl0aSxTaW1TdW47Y29sb3I6IzAwMDAwMDtmb250LXNpemU6MTQu MHB4OyI+Jm5ic3A7ICZuYnNwOyZuYnNwO0kmbmJzcDtzdXBwb3J0Jm5ic3A7dGhlJm5ic3A7YWRv cHRpb24mbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtkcmFmdC48YnIgPiZuYnNwOyAmbmJzcDsgQm90 aCZuYnNwO25leHQmbmJzcDthbmQmbmJzcDtyZXBsYWNlJm5ic3A7Zmxhdm9ycyZuYnNwO2FyZSZu YnNwO2NvbnNpc3RlbnQmbmJzcDt3aXRoJm5ic3A7dGhlJm5ic3A7U1J2NiZuYnNwO25ldHdvcmsm bmJzcDtwcm9ncmFtbWluZyhSRkMmbmJzcDs4OTg2KWFuZCZuYnNwO3VzZXMmbmJzcDtTUkgmbmJz cDtiYXNlZCZuYnNwO2RhdGEmbmJzcDtwbGFuZShSRkMmbmJzcDs4NzU0KSwmbmJzcDt0aGVyZWZv cmUmbmJzcDtJJm5ic3A7ZG9uJ3QmbmJzcDtjb25zaWRlciZuYnNwO3RoZXNlJm5ic3A7dHdvJm5i c3A7Zmxhdm9ycyZuYnNwO2FyZSZuYnNwO3R3byZuYnNwO3NvbHV0aW9ucyZuYnNwO2J1dCZuYnNw O2ZsZXhpYmlsaXRpZXMmbmJzcDtmb3ImbmJzcDtkaWZmZXJlbnQmbmJzcDtzY2VuYXJpb3MuJm5i c3A7PC9zcGFuPjwvZGl2PjxkaXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+PHNwYW4gIHN0eWxlPSJm b250LWZhbWlseTpUYWhvbWEsQXJpYWwsU1RIZWl0aSxTaW1TdW47Y29sb3I6IzAwMDAwMDtmb250 LXNpemU6MTQuMHB4OyI+Jm5ic3A7ICZuYnNwOyBQcm9jZWVkaW5nIHdpdGggQ1NJRCB3b3VsZCBo ZWxwIGNyZWF0ZSBhIHJvYnVzdCBlY28tc3lzdGVtIHdoaWNoIHdlIGNvdWxkIGxldmVyYWdlLjxi ciA+Jm5ic3A7ICZuYnNwOyBUaGFua3MuPC9zcGFuPjwvZGl2PjxkaXYgIHN0eWxlPSJjbGVhcjpi b3RoOyI+PHNwYW4gIHN0eWxlPSJjb2xvcjojMDAwMDAwO2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fu cy1zZXJpZjtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQtbGlnYXR1cmVzOm5vcm1hbDtm b250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6NDAwO3RleHQtYWxpZ246bGVmdDt0 ZXh0LWluZGVudDouMHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2lkb3dzOjI7dGV4dC1kZWNvcmF0 aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9yOmluaXRpYWw7ZmxvYXQ6bm9u ZTtmb250LXNpemU6MTQuMHB4O2Rpc3BsYXk6aW5saW5lOyI+PGJyID48L3NwYW4+PC9kaXY+PGRp diAgc3R5bGU9ImNsZWFyOmJvdGg7Ij48c3BhbiAgc3R5bGU9ImNvbG9yOiMwMDAwMDA7Zm9udC1m YW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1s aWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDo0MDA7 dGV4dC1hbGlnbjpsZWZ0O3RleHQtaW5kZW50Oi4wcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aWRv d3M6Mjt0ZXh0LWRlY29yYXRpb24tc3R5bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6 aW5pdGlhbDtmbG9hdDpub25lO2ZvbnQtc2l6ZToxNC4wcHg7ZGlzcGxheTppbmxpbmU7Ij4mbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFl1YW5jaGFvIFN1PC9zcGFuPjwvZGl2Pjxk aXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+PHNwYW4gIHN0eWxlPSJjb2xvcjojMDAwMDAwO2ZvbnQt ZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtmb250LXN0eWxlOm5vcm1hbDtmb250LXZhcmlhbnQt bGlnYXR1cmVzOm5vcm1hbDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7Zm9udC13ZWlnaHQ6NDAw O3RleHQtYWxpZ246bGVmdDt0ZXh0LWluZGVudDouMHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2lk b3dzOjI7dGV4dC1kZWNvcmF0aW9uLXN0eWxlOmluaXRpYWw7dGV4dC1kZWNvcmF0aW9uLWNvbG9y OmluaXRpYWw7ZmxvYXQ6bm9uZTtmb250LXNpemU6MTQuMHB4O2Rpc3BsYXk6aW5saW5lOyI+Jm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBbGlDbG91ZCBOZXR3b3JrIERpcmVjdG9y PC9zcGFuPjwvZGl2PjxkaXYgIHN0eWxlPSJjbGVhcjpib3RoOyI+PHNwYW4gIHN0eWxlPSJjb2xv cjojMDAwMDAwO2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtmb250LXNpemU6MTQuN3B4 O2ZvbnQtc3R5bGU6bm9ybWFsO2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6bm9ybWFsO2ZvbnQtdmFy aWFudC1jYXBzOm5vcm1hbDtmb250LXdlaWdodDo0MDA7dGV4dC1hbGlnbjpsZWZ0O3RleHQtaW5k ZW50Oi4wcHg7dGV4dC10cmFuc2Zvcm06bm9uZTt3aWRvd3M6Mjt0ZXh0LWRlY29yYXRpb24tc3R5 bGU6aW5pdGlhbDt0ZXh0LWRlY29yYXRpb24tY29sb3I6aW5pdGlhbDtmbG9hdDpub25lO2Rpc3Bs YXk6aW5saW5lOyI+Jm5ic3A7ICZuYnNwOzwvc3Bhbj48L2Rpdj48YmxvY2txdW90ZSAgc3R5bGU9 Im1hcmdpbi1yaWdodDouMHB4O21hcmdpbi10b3A6LjBweDttYXJnaW4tYm90dG9tOi4wcHg7Ij48 ZGl2ICBzdHlsZT0iY2xlYXI6Ym90aDsiPjxzcGFuICBzdHlsZT0iZm9udC1mYW1pbHk6VGFob21h LEFyaWFsLFNUSGVpdGksU2ltU3VuO2ZvbnQtc2l6ZToxNC4wcHg7Y29sb3I6IzAwMDAwMDsiPi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLTwvc3Bhbj48L2Rpdj48ZGl2ICBzdHlsZT0iY2xlYXI6Ym90aDsiPjxzcGFuICBzdHls ZT0iZm9udC1mYW1pbHk6VGFob21hLEFyaWFsLFNUSGVpdGksU2ltU3VuO2ZvbnQtc2l6ZToxNC4w cHg7Y29sb3I6IzAwMDAwMDsiPuWPkeS7tuS6uu+8mkphbWVzIEd1aWNoYXJkICZsdDtqYW1lcy5u Lmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20mZ3Q7PC9zcGFuPjwvZGl2PjxkaXYgIHN0eWxlPSJjbGVh cjpib3RoOyI+PHNwYW4gIHN0eWxlPSJmb250LWZhbWlseTpUYWhvbWEsQXJpYWwsU1RIZWl0aSxT aW1TdW47Zm9udC1zaXplOjE0LjBweDtjb2xvcjojMDAwMDAwOyI+5Y+R6YCB5pe26Ze077yaMjAy MeW5tDEw5pyIMeaXpSjmmJ/mnJ/kupQpIDIyOjA1PC9zcGFuPjwvZGl2PjxkaXYgIHN0eWxlPSJj bGVhcjpib3RoOyI+PHNwYW4gIHN0eWxlPSJmb250LWZhbWlseTpUYWhvbWEsQXJpYWwsU1RIZWl0 aSxTaW1TdW47Zm9udC1zaXplOjE0LjBweDtjb2xvcjojMDAwMDAwOyI+5pS25Lu25Lq677yaU1BS SU5HIFdHICZsdDtzcHJpbmdAaWV0Zi5vcmcmZ3Q7PC9zcGFuPjwvZGl2PjxkaXYgIHN0eWxlPSJj bGVhcjpib3RoOyI+PHNwYW4gIHN0eWxlPSJmb250LWZhbWlseTpUYWhvbWEsQXJpYWwsU1RIZWl0 aSxTaW1TdW47Zm9udC1zaXplOjE0LjBweDtjb2xvcjojMDAwMDAwOyI+5oqE44CA6YCB77yac3By aW5nLWNoYWlyc0BpZXRmLm9yZyAmbHQ7c3ByaW5nLWNoYWlyc0BpZXRmLm9yZyZndDs8L3NwYW4+ PC9kaXY+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7Ij48c3BhbiAgc3R5bGU9ImZvbnQtZmFtaWx5 OlRhaG9tYSxBcmlhbCxTVEhlaXRpLFNpbVN1bjtmb250LXNpemU6MTQuMHB4O2NvbG9yOiMwMDAw MDA7Ij7kuLvjgIDpopjvvJpbc3ByaW5nXSBXRyBBZG9wdGlvbiBjYWxsIGZvciBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNy aC1jb21wcmVzc2lvbi88L3NwYW4+PC9kaXY+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7Ij48c3Bh biAgc3R5bGU9ImZvbnQtZmFtaWx5OlRhaG9tYSxBcmlhbCxTVEhlaXRpLFNpbVN1bjtmb250LXNp emU6MTQuMHB4O2NvbG9yOiMwMDAwMDA7Ij48YnIgPjwvc3Bhbj48L2Rpdj48c3R5bGUgPiEtLSAg QGZvbnQtZmFjZXtmb250LWZhbWlseTpDYW1icmlhIE1hdGg7cGFub3NlLTE6MiA0IDUgMyA1IDQg NiAzIDIgNDt9e2ZvbnQtZmFtaWx5OkNhbGlicmk7cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fXAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWx7bWFyZ2luOi4waW47 Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7fXAuTXNvUGxh aW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHR7bXNvLXN0eWxlLXByaW9y aXR5Ojk5O21zby1zdHlsZS1saW5rOlBsYWluIFRleHQgQ2hhcjttYXJnaW46LjBpbjtmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjt9cC5Nc29MaXN0UGFyYWdy YXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaHttc28tc3R5bGUt cHJpb3JpdHk6MzQ7bWFyZ2luLXRvcDouMGluO21hcmdpbi1yaWdodDouMGluO21hcmdpbi1ib3R0 b206LjBpbjttYXJnaW4tbGVmdDouNWluO2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2Fs aWJyaSxzYW5zLXNlcmlmO31zcGFuLkVtYWlsU3R5bGUxN3ttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1jb21wb3NlO2ZvbnQtZmFtaWx5OkNhbGlicmksc2Fucy1zZXJpZjtjb2xvcjp3aW5kb3d0ZXh0 O31zcGFuLlBsYWluVGV4dENoYXJ7bXNvLXN0eWxlLW5hbWU6UGxhaW4gVGV4dCBDaGFyO21zby1z dHlsZS1wcmlvcml0eTo5OTttc28tc3R5bGUtbGluazpQbGFpbiBUZXh0O2ZvbnQtZmFtaWx5OkNh bGlicmksc2Fucy1zZXJpZjt9Lk1zb0NocERlZmF1bHR7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO31AcGFnZSBXb3JkU2VjdGlvbjF7c2l6 ZTo4LjVpbiAxMS4waW47bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO31kaXYuV29yZFNl Y3Rpb24xe3BhZ2U6V29yZFNlY3Rpb24xO317bXNvLWxpc3QtaWQ6NzUxNjk5MzkzO21zby1saXN0 LXR5cGU6aHlicmlkO21zby1saXN0LXRlbXBsYXRlLWlkczotNzIxNjU0Nzc2IDY3Njk4NzAzIDY3 Njk4Njg5IDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4 NzEzIDY3Njk4NzE1O317bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7bXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0O3RleHQtaW5kZW50Oi0uMmluO317bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0O21zby1sZXZlbC10ZXh0OlxGMEI3O21zby1sZXZlbC10YWItc3RvcDpub25lO21zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDt0ZXh0LWluZGVudDotLjJpbjtmb250LWZhbWlseTpT eW1ib2w7fXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTttc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0O3RleHQtaW5kZW50Oi05 LjBwdDt9e21zby1sZXZlbC10YWItc3RvcDpub25lO21zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDt0ZXh0LWluZGVudDotLjJpbjt9e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxv d2VyO21zby1sZXZlbC10YWItc3RvcDpub25lO21zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDt0ZXh0LWluZGVudDotLjJpbjt9e21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2Vy O21zby1sZXZlbC10YWItc3RvcDpub25lO21zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7 dGV4dC1pbmRlbnQ6LTkuMHB0O317bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7bXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0O3RleHQtaW5kZW50Oi0uMmluO317bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7bXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0O3RleHQtaW5kZW50Oi0uMmluO317bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6cm9tYW4tbG93ZXI7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7bXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpyaWdodDt0ZXh0LWluZGVudDotOS4wcHQ7fW9se21hcmdpbi1ib3R0b206LjBpbjt9 dWx7bWFyZ2luLWJvdHRvbTouMGluO30tLT48L3N0eWxlPjxkaXYgIGNsYXNzPSJXb3JkU2VjdGlv bjEiPjxwICBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIFdHOjwvcD48cCAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PC9wPjxwICBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY2hhaXJzIHdvdWxkIGxpa2Ug dG8gZXhwcmVzcyB0aGVpciBhcHByZWNpYXRpb24gZm9yIGFsbCB0aGUgcmVzcG9uc2VzIHJlY2Vp dmVkIHRvIG91ciBlbWFpbHMgd2l0aCByZWZlcmVuY2UgdG8gaG93IHRoZSB3b3JraW5nIGdyb3Vw IHdpc2hlcyB0byBtb3ZlIGZvcndhcmQgd2l0aCByZXNwZWN0IHRvIGEgc29sdXRpb24gZm9yIFNS djYgY29tcHJlc3Npb24uCjwvcD48cCAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PC9wPjxwICBj bGFzcz0iTXNvTm9ybWFsIj5UaGUgYXBwYXJlbnQgaW5jbGluYXRpb24gb2YgdGhlIHdvcmtpbmcg Z3JvdXAgaXMgdG8gdXNlIDxhICBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8iIHRhcmdl dD0iX2JsYW5rIj4KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2Zp bHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vPC9hPiBhcyB0aGUgYmFzaXMgZm9y IGl0cyBjb21wcmVzc2lvbiBzdGFuZGFyZGl6YXRpb24gd29yay4gVGhhdCBpcyBwYXJ0IG9mIHdo YXQgdGhpcyBlbWFpbCBhdHRlbXB0cyB0byBjb25maXJtLjwvcD48cCAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PC9wPjxwICBjbGFzcz0iTXNvTm9ybWFsIj5CZWNhdXNlIG9mIHRoZSBhYm92ZSB0 aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gaXNzdWUgYSAyLXdlZWsgV0cgY2FsbCBmb3IgYWRvcHRp b24gZW5kaW5nIE9jdG9iZXIgMTU8c3VwID50aDwvc3VwPiBmb3IKPGEgIGhyZWY9Imh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYt c3JoLWNvbXByZXNzaW9uLyIgdGFyZ2V0PSJfYmxhbmsiPgpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lv bi88L2E+IGJ1dCB3aXRoIHNvbWUgY2xlYXIgZ3VpZGVsaW5lcyBhcyBmb2xsb3dzLiBCeSBleHBy ZXNzaW5nIHN1cHBvcnQgZm9yIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgeW91IGFyZSBmdWxs eSBhd2FyZSBvZiBhbmQgYXJlIGFja25vd2xlZGdpbmcgdGhhdDoKPC9wPjxwICBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8L3A+PG9sICBzdGFydD0iMSIgdHlwZT0iMSIgc3R5bGU9Im1hcmdpbi10 b3A6LjBpbjsiPjxsaSAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVm dDouMGluOyI+VGhlIFNQUklORyB3b3JraW5nIGdyb3VwIGlzIGFkb3B0aW5nIGEgZG9jdW1lbnQg dGhhdCBoYXMgbXVsdGlwbGUgU1J2NiBFbmRwb2ludCBiZWhhdmlvcnMuCjwvbGk+PGxpICBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi4waW47Ij5UaGUgZG9jdW1l bnQgaXMgYSDigJxsaXZpbmfigJ0gZG9jdW1lbnQ7IGl0IG1heSBjaGFuZ2UgYXMgaXQgZ29lcyB0 aHJvdWdoIHJldmlldyBhbmQgYW5hbHlzaXMgYnkgdGhlIFNQUklORyB3b3JraW5nIGdyb3VwLgo8 L2xpPjxsaSAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDouMGlu OyI+QWxsIG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgcmFpc2VkIG9uIG91ciBtYWlsaW5nIGxpc3Qg TVVTVCBiZSBhZGRyZXNzZWQgQkVGT1JFIHNhaWQgZG9jdW1lbnQgaXMgYWxsb3dlZCB0byBwcm9n cmVzcyBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIHRvIHB1YmxpY2F0aW9uLiBBIGxpc3Qgb2YgdGhl c2UgZGlzY3Vzc2lvbgogcG9pbnRzIHdpbGwgYmUgZG9jdW1lbnRlZCBpbiB0aGUgV0cgZG9jdW1l bnQgYW5kIG1haW50YWluZWQgYnkgdGhlIGRvY3VtZW50IGVkaXRvciBpbiBjb25qdW5jdGlvbiB3 aXRoIHRoZSBjaGFpcnMuCjwvbGk+PGxpICBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi4waW47Ij5JZiB0aGlzIGRvY3VtZW50IGlzIGFkb3B0ZWQgYnkgdGhlIHdv cmtpbmcgZ3JvdXAsIHRoZSBjaGFpcnMgc3BlY2lmeSBhcyBwYXJ0IG9mIHRoZSBhZG9wdGlvbiBj YWxsIHRoYXQgdGhlIGZvbGxvd2luZyB0ZXh0IGRlc2NyaWJpbmcgYW4gb3BlbiBpc3N1ZSBiZSBh ZGRlZCB0byB0aGUgZG9jdW1lbnQgaW4gdGhlIGFib3ZlLWRlc2NyaWJlZAogb3BlbiBpc3N1ZXMg c2VjdGlvbjo8L2xpPjx1bCAgc3R5bGU9Im1hcmdpbi10b3A6LjBpbjsiPjxsaSAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+IkdpdmVuIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHNhaWQgdGhhdCBp dCB3YW50cyB0byBzdGFuZGFyZGl6ZSBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiwgYW5kIGdpdmVu IHRoYXQgdGhlIGRvY3VtZW50IGNvbnRhaW5zIG11bHRpcGxlIFNSdjYgRW5kUG9pbnQgYmVoYXZp b3JzIHRoYXQgc29tZSBXRyBtZW1iZXJzIGhhdmUgc3RhdGVkIGFyZQogbXVsdGlwbGUgZGF0YSBw bGFuZSBzb2x1dGlvbnMsIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYWRkcmVzcyB3aGV0aGVyIHRo aXMgaXMgdmFsaWQgYW5kIGNvaGVyZW50IHdpdGggaXRzIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9u IG9iamVjdGl2ZS4iLjwvbGk+PC91bD48L29sPjxwICBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 L3A+PHAgIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBjb25zaWRlciB0aGUgYWJvdmUgZ3VpZGVs aW5lcyBhcyB5b3UgZGVjaWRlIG9uIHdoZXRoZXIgdG8gc3VwcG9ydCBvciBub3QgdGhpcyBXRyBh ZG9wdGlvbi4gUGxlYXNlIGV4cHJlc3MgY2xlYXJseSB5b3VyIHJlYXNvbmluZyBmb3Igc3VwcG9y dC9ub24tc3VwcG9ydCBhcyB3ZWxsIGFzIGFueSBvcGVuIGRpc2N1c3Npb24gcG9pbnRzIHlvdSB3 b3VsZCBsaWtlIGFkZHJlc3NlZCBzaG91bGQgdGhlIGRvY3VtZW50CiBiZSBhZG9wdGVkIGludG8g dGhlIHdvcmtpbmcgZ3JvdXAuPC9wPjxwICBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+PHAg IGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyE8L3A+PHAgIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzwvcD48cCAgY2xhc3M9Ik1zb05vcm1hbCI+SmltLCBCcnVubyAmYW1wOyBKb2VsPC9wPjxwICBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8L3A+PHAgIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwv cD48L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdiA+PGJyID48L2Rpdj48L2Rpdj4= ------=ALIBOUNDARY_88141_7f3cf6bd1700_61607768_c0d6cd-- From nobody Fri Oct 8 10:04:02 2021 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 197613A0953; Fri, 8 Oct 2021 10:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sxi8KUQWUlv4; Fri, 8 Oct 2021 10:03:54 -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 79C443A094F; Fri, 8 Oct 2021 10:03:53 -0700 (PDT) Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HQvbL2bgGz67VLp; Sat, 9 Oct 2021 01:01:02 +0800 (CST) Received: from mscpeml500001.china.huawei.com (7.188.26.142) 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.8; Fri, 8 Oct 2021 19:03:49 +0200 Received: from mscpeml500001.china.huawei.com (7.188.26.142) by mscpeml500001.china.huawei.com (7.188.26.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Fri, 8 Oct 2021 20:03:49 +0300 Received: from mscpeml500001.china.huawei.com ([7.188.26.142]) by mscpeml500001.china.huawei.com ([7.188.26.142]) with mapi id 15.01.2308.008; Fri, 8 Oct 2021 20:03:49 +0300 From: Vasilenko Eduard To: Tom Herbert CC: Ron Bonica , Eduard Metz , SPRING WG , 6MAN <6man@ietf.org> Thread-Topic: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 Thread-Index: Ade3AXyWK2NzAamgSlCvJ497z/5RLwC/aCkQAFB7QYAAFhVaAAAhiEzQAAaps4AACvQ5MA== Date: Fri, 8 Oct 2021 17:03:49 +0000 Message-ID: <423b08d46294454d9a9625990ce52acb@huawei.com> References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.197.223] Content-Type: multipart/alternative; boundary="_000_423b08d46294454d9a9625990ce52acbhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 08 Oct 2021 17:03:59 -0000 --_000_423b08d46294454d9a9625990ce52acbhuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVG9tLA0KSXQgaXMgbm90IHJlbGF0ZWQgdG8gQ1NJRC4gQmVjYXVzZSBpdCBpcyBub3QgaW1w b3J0YW50IGhvdyBJUCBhZGRyZXNzIGlzIHByZXBhcmVkLCBpdCBzaG91bGQgYmUgSVAgYWRkcmVz cyBhdCB0aGUgdGltZSBvZiB3cml0aW5nIHRvIERBIGZpZWxkLiBBbmQgaXQgaXMuDQoNCllvdSBh cmUgYXNraW5nIG1vcmUgZ2VuZXJhbCBxdWVzdGlvbjogd2hhdCB3YXMgdGhlIGxlZ2FsIHJlYXNv biB0byB0cmVhdCBJUHY2IGFkZHJlc3MgYXMgTE9DOkZVTkNUOkFSRz8NClNvcnJ5LCBidXQgaXQg aXMgYSBsaXR0bGUgYml0IGxhdGUg4oCTIFJGQyA4OTg2IGlzIGFscmVhZHkgcHVibGlzaGVkLg0K RWR1YXJkDQpGcm9tOiBUb20gSGVyYmVydCBbbWFpbHRvOnRvbUBoZXJiZXJ0bGFuZC5jb21dDQpT ZW50OiBGcmlkYXksIE9jdG9iZXIgOCwgMjAyMSA1OjQ3IFBNDQpUbzogVmFzaWxlbmtvIEVkdWFy ZCA8dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tPg0KQ2M6IFJvbiBCb25pY2EgPHJib25pY2E9 NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZz47IEVkdWFyZCBNZXR6IDxldG1ldHpAZ21haWwu Y29tPjsgU1BSSU5HIFdHIDxzcHJpbmdAaWV0Zi5vcmc+OyA2TUFOIDw2bWFuQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtzcHJpbmddIGRyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3Jo LWNvbXByZXNzaW9uLTAyDQoNCg0KDQpPbiBGcmksIE9jdCA4LCAyMDIxIGF0IDE6MzggQU0gVmFz aWxlbmtvIEVkdWFyZCA8dmFzaWxlbmtvLmVkdWFyZEBodWF3ZWkuY29tPG1haWx0bzp2YXNpbGVu a28uZWR1YXJkQGh1YXdlaS5jb20+PiB3cm90ZToNCj4NCj4gw5ggQnkgY29udHJhc3QsIGEgQ29t cHJlc3NlZCBTSUQgQ29udGFpbmVyIChpLmUuLCB0aGUgMTI4LWJpdCBlbnRpdHkgdGhhdCBpcyBj b3BpZWQgaW50byB0aGUgSVB2NiBEZXN0aW5hdGlvbiBBZGRyZXNzIGZpZWxkKSByZXByZXNlbnRz IGFuIGVudGlyZSBTUiBQYXRoLiBTcGVjaWZpY2FsbHksIGl0IHJlcHJlc2VudHMgKm1hbnkqIGZ1 bmN0aW9ucyB0aGF0IHJlc2lkZSBvbiAqbWFueSogbm9kZXMNCj4NCj4NCj4NCj4gQnV0IENTSUQg aXMgbm90IGFuIElQIGFkZHJlc3MsIHJpZ2h0PyBXaHkgSVAgYWRkcmVzcyBydWxlcyBzaG91bGQg YmUgYXBwbGljYWJsZSB0byBDU0lEPw0KPg0KRWR1YXJkLA0KDQpJZiB0aGUgcHJvdG9jb2wgaXMg Y29weWluZyB0aGUgQ1NJIGludG8gdGhlIElQdjYgRGVzdGluYXRpb24gYWRkcmVzcyB0aGUgQ1NJ IE1VU1QgYmUgYW4gSVAgYWRkcmVzcyBiZWNhdXNlIHRoZSBEZXN0aW5hdGlvbiBBZGRyZXNzIGZp ZWxkIGluIGFuIElQdjYgcGFja2V0ICpjb250YWlucyogYW4gSVB2NiBhZGRyZXNzLiBPdmVybG9h ZGluZyBmaWVsZHMgaW4gdGhlIElQdjYgaGVhZGVyIHdpdGggb3RoZXIgZGF0YSB3b3VsZCBiZSBu b24tY29uZm9ybWFudCB3aXRoIHRoZSBJUHY2IHN0YW5kYXJkIChub3QganVzdCBhZGRyZXNzZXMs IHNlZSB0aGUgc2V2ZXJhbCBhdHRlbXB0cyB0byBzdHJ1Y3R1cmUgZmxvdyBsYWJlbCBmb3IgaW5z dGFuY2UpLg0KDQpGcmFua2x5LCB0aGlzIGlzIG9uZSB0aGluZyB0aGF0IEkgaGF2ZSBmb3VuZCB0 cm91Ymxpbmcgd2l0aCBTclJ2Ni4gU29tZXRpbWVzIGl0IGlzIHBvcnRyYXllZCBhcyBhbiBhbHRl cm5hdGl2ZSwgc2hhZG93IHByb3RvY29sIHRvIElQdjYgdGhhdCBqdXN0IGhhcHBlbnMgdG8gdXNl IHRoZSBJUHY2IHByb3RvY29sIGZvcm1hdCBmb3IgY29udmVuaWVuY2UgaW5zdGVhZCBvZiBjcmVh dGluZyBhIG5ldyBMMyBwcm90b2NvbCBmb3IgaXRzIHB1cnBvc2VzLiBUaGUgcmF0aW9uYWxpemF0 aW9uIGZvciB0aGlzIHNlZW1zIHRvIGJlIHRoYXQgU1J2NiBpcyBjb25maW5lZCB0byBsaW1pdGVk IGRvbWFpbnMsIGFuZCB3aXRoaW4gYSBsaW1pdGVkIGRvbWFpbiB3ZSBjYW4gc2FmZWx5IHJlZGVm aW5lIHN0YW5kYXJkIHByb3RvY29scyBpbiBhcmJpdHJhcnkgd2F5cy0tIG5vdGUsIHRoZXJlIGlz IG5vIGNvbnNlbnN1cyB0aGF0IHRoYXQgcGhpbG9zb3BoeSBpcyBhY2NlcHRhYmxlLg0KDQpUb20N Cg0KPg0KPg0KPiBGcm9tOiBpcHY2IFttYWlsdG86aXB2Ni1ib3VuY2VzQGlldGYub3JnPG1haWx0 bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgUm9uIEJvbmljYQ0KPiBTZW50 OiBUaHVyc2RheSwgT2N0b2JlciA3LCAyMDIxIDEwOjM2IFBNDQo+IFRvOiBFZHVhcmQgTWV0eiA8 ZXRtZXR6QGdtYWlsLmNvbTxtYWlsdG86ZXRtZXR6QGdtYWlsLmNvbT4+DQo+IENjOiBTUFJJTkcg V0cgPHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPj47IDZtYW5AaWV0Zi5v cmc8bWFpbHRvOjZtYW5AaWV0Zi5vcmc+DQo+IFN1YmplY3Q6IFJFOiBbc3ByaW5nXSBkcmFmdC1m aWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi0wMg0KPg0KPg0KPg0KPg0K Pg0KPiBJbmxpbmUgW1JCXQ0KPg0KPg0KPg0KPiAgICAgICAgICAgIFJvbg0KPg0KPg0KPg0KPg0K Pg0KPiBKdW5pcGVyIEJ1c2luZXNzIFVzZSBPbmx5DQo+DQo+IEZyb206IEVkdWFyZCBNZXR6IDxl dG1ldHpAZ21haWwuY29tPG1haWx0bzpldG1ldHpAZ21haWwuY29tPj4NCj4gU2VudDogVGh1cnNk YXksIE9jdG9iZXIgNywgMjAyMSA1OjAzIEFNDQo+IFRvOiBSb24gQm9uaWNhIDxyYm9uaWNhQGp1 bmlwZXIubmV0PG1haWx0bzpyYm9uaWNhQGp1bmlwZXIubmV0Pj4NCj4gQ2M6IDZtYW5AaWV0Zi5v cmc8bWFpbHRvOjZtYW5AaWV0Zi5vcmc+OyBTUFJJTkcgV0cgPHNwcmluZ0BpZXRmLm9yZzxtYWls dG86c3ByaW5nQGlldGYub3JnPj4NCj4gU3ViamVjdDogUmU6IFtzcHJpbmddIGRyYWZ0LWZpbHNm aWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLTAyDQo+DQo+DQo+DQo+IFtFeHRl cm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF0NCj4NCj4NCj4NCj4NCj4NCj4gQ2Fu IHRoZSBTSUQgYmUgdmlld2VkIGFzIHRoZSBhZGRyZXNzIG9mIHRoZSAiaW50ZXJmYWNlIiB0bywg aW4gdGhpcyBjYXNlLCB0aGUgZnVuY3Rpb24gdGhhdCByZXNpZGVzIGluIGEgbm9kZT8gRnJvbSBh IHJvdXRpbmcgLyBmb3J3YXJkaW5nIHBvaW50IG9mIHZpZXcgdGhlIGdyb3VwIG9mIGZ1bmN0aW9u cyBpcyBtb3JlIHNpbWlsYXIgdG8gYSBuZXR3b3JrIChyZXByZXNlbnRlZCBieSBhIHByZWZpeCwg cmF0aGVyIHRoYW4gYSBzaW5nbGUgYWRkcmVzcyksIGJ1dCBzdGlsbC4NCj4NCj4NCj4NCj4gW1JC XSBJbiBSRkMgODk4NiwgYSBjbGFzc2ljIFNSdjYgU0lEIHJlcHJlc2VudHMgYSAqc2luZ2xlKiBm dW5jdGlvbiB0aGF0IHJlc2lkZXMgb24gYSAqc2luZ2xlKiBub2RlLiBJZiB5b3UgbGlrZSwgeW91 IGNhbiBldmVuIHNheSB0aGF0IHJlcHJlc2VudHMgYSAqc2luZ2xlKiBpbnRlcmZhY2UgdG8gYSAq c2luZ2xlKiBmdW5jdGlvbiB0aGF0IHJlc2lkZXMgb24gYSAqc2luZ2xlKiBub2RlLg0KPg0KPg0K Pg0KPiBCeSBjb250cmFzdCwgYSBDb21wcmVzc2VkIFNJRCBDb250YWluZXIgKGkuZS4sIHRoZSAx MjgtYml0IGVudGl0eSB0aGF0IGlzIGNvcGllZCBpbnRvIHRoZSBJUHY2IERlc3RpbmF0aW9uIEFk ZHJlc3MgZmllbGQpIHJlcHJlc2VudHMgYW4gZW50aXJlIFNSIFBhdGguIFNwZWNpZmljYWxseSwg aXQgcmVwcmVzZW50cyAqbWFueSogZnVuY3Rpb25zIHRoYXQgcmVzaWRlIG9uICptYW55KiBub2Rl cw0KPg0KPg0KPg0KPg0KPg0KPiBGb3IgbXkgdW5kZXJzdGFuZGluZywgYXBhcnQgZnJvbSB0aGF0 IHRoZSAoZGVmaW5pdGlvbiBvZikgU0lEIG1heSBub3QgYmUgYWxpZ25lZCB3aXRoIHRoZSBsaXRl cmFsIHRleHQgaW4gYmVsb3cgUkZDcywgd2hhdCBpcyB0aGUgcmVhbCBwcm9ibGVtPyBBcmUgdGhl cmUgYW55IHByb3RvY29scyB0aGF0IHNwZWNpZmljYWxseSByZWx5IG9uIHRoaXMgZGVmaW5pdGlv biBvZiBhbiBJUHY2IGFkZHJlc3M/DQo+DQo+DQo+DQo+IFtSQl0gV2UgZG9u4oCZdCBrbm93IGlm IHRoZXJlIGFyZSBhbnkgcHJvdG9jb2xzIHRoYXQgcmVseSBvbiB0aGlzIGRlZmluaXRpb24gb2Yg dGhlIElQdjYgYWRkcmVzcy4gQW5kIGlmIHdlIGRvbuKAmXQgdXBkYXRlIFJGQyA0MjkxIGJlZm9y ZSB2aW9sYXRpbmcgaXQsIHdlIGRvbuKAmXQga25vdyBpZiBhbnlib2R5IG1pZ2h0IHdyaXRlIHN1 Y2ggYW4gYXBwbGljYXRpb24gaW4gdGhlIGZ1dHVyZS4NCj4NCj4NCj4NCj4gICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQo+DQo+DQo+DQo+DQo+DQo+IGNoZWVy cywNCj4NCj4gICBFZHVhcmQNCj4NCj4NCj4NCj4NCj4NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJ UHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+IGlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlw djZAaWV0Zi5vcmc+DQo+IEFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== --_000_423b08d46294454d9a9625990ce52acbhuaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFt ZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5IaSBUb20sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkl0IGlzIG5vdCByZWxhdGVkIHRvIENT SUQuIEJlY2F1c2UgaXQgaXMgbm90IGltcG9ydGFudCBob3cgSVAgYWRkcmVzcyBpcyBwcmVwYXJl ZCwgaXQgc2hvdWxkIGJlIElQIGFkZHJlc3MgYXQgdGhlIHRpbWUgb2Ygd3JpdGluZyB0byBEQSBm aWVsZC4gQW5kIGl0IGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+WW91IGFyZSBhc2tpbmcgbW9yZSBnZW5lcmFsIHF1ZXN0aW9uOiB3aGF0IHdhcyB0aGUgbGVn YWwgcmVhc29uIHRvIHRyZWF0IElQdjYgYWRkcmVzcyBhcyBMT0M6RlVOQ1Q6QVJHPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5Tb3JyeSwgYnV0IGl0IGlzIGEgbGl0dGxlIGJpdCBsYXRlIOKAkyBSRkMgODk4 NiBpcyBhbHJlYWR5IHB1Ymxpc2hlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+RWR1YXJkPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVG9tIEhlcmJlcnQgW21haWx0bzp0b21A aGVyYmVydGxhbmQuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgT2N0b2JlciA4LCAy MDIxIDU6NDcgUE08YnI+DQo8Yj5Ubzo8L2I+IFZhc2lsZW5rbyBFZHVhcmQgJmx0O3Zhc2lsZW5r by5lZHVhcmRAaHVhd2VpLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IFJvbiBCb25pY2EgJmx0O3Ji b25pY2E9NDBqdW5pcGVyLm5ldEBkbWFyYy5pZXRmLm9yZyZndDs7IEVkdWFyZCBNZXR6ICZsdDtl dG1ldHpAZ21haWwuY29tJmd0OzsgU1BSSU5HIFdHICZsdDtzcHJpbmdAaWV0Zi5vcmcmZ3Q7OyA2 TUFOICZsdDs2bWFuQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3Nwcmlu Z10gZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24tMDI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQpPbiBGcmksIE9j dCA4LCAyMDIxIGF0IDE6MzggQU0gVmFzaWxlbmtvIEVkdWFyZCAmbHQ7PGEgaHJlZj0ibWFpbHRv OnZhc2lsZW5rby5lZHVhcmRAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnZhc2lsZW5rby5l ZHVhcmRAaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IMOYIEJ5 IGNvbnRyYXN0LCBhIENvbXByZXNzZWQgU0lEIENvbnRhaW5lciAoaS5lLiwgdGhlIDEyOC1iaXQg ZW50aXR5IHRoYXQgaXMgY29waWVkIGludG8gdGhlIElQdjYgRGVzdGluYXRpb24gQWRkcmVzcyBm aWVsZCkgcmVwcmVzZW50cyBhbiBlbnRpcmUgU1IgUGF0aC4gU3BlY2lmaWNhbGx5LCBpdCByZXBy ZXNlbnRzICptYW55KiBmdW5jdGlvbnMgdGhhdCByZXNpZGUgb24gKm1hbnkqIG5vZGVzPGJyPg0K Jmd0Ozxicj4NCiZndDsmbmJzcDsgPGJyPg0KJmd0Ozxicj4NCiZndDsgQnV0IENTSUQgaXMgbm90 IGFuIElQIGFkZHJlc3MsIHJpZ2h0PyBXaHkgSVAgYWRkcmVzcyBydWxlcyBzaG91bGQgYmUgYXBw bGljYWJsZSB0byBDU0lEPzxicj4NCiZndDs8YnI+DQpFZHVhcmQsPGJyPg0KPGJyPg0KSWYgdGhl IHByb3RvY29sIGlzIGNvcHlpbmcgdGhlIENTSSBpbnRvIHRoZSBJUHY2IERlc3RpbmF0aW9uIGFk ZHJlc3MgdGhlIENTSSBNVVNUIGJlIGFuIElQIGFkZHJlc3MgYmVjYXVzZSB0aGUgRGVzdGluYXRp b24gQWRkcmVzcyBmaWVsZCBpbiBhbiBJUHY2IHBhY2tldCAqY29udGFpbnMqIGFuIElQdjYgYWRk cmVzcy4gT3ZlcmxvYWRpbmcgZmllbGRzIGluIHRoZSBJUHY2IGhlYWRlciB3aXRoIG90aGVyIGRh dGEgd291bGQgYmUgbm9uLWNvbmZvcm1hbnQNCiB3aXRoIHRoZSBJUHY2IHN0YW5kYXJkIChub3Qg anVzdCBhZGRyZXNzZXMsIHNlZSB0aGUgc2V2ZXJhbCBhdHRlbXB0cyB0byBzdHJ1Y3R1cmUgZmxv dyBsYWJlbCBmb3IgaW5zdGFuY2UpLjxicj4NCjxicj4NCkZyYW5rbHksIHRoaXMgaXMgb25lIHRo aW5nIHRoYXQgSSBoYXZlIGZvdW5kIHRyb3VibGluZyB3aXRoIFNyUnY2LiBTb21ldGltZXMgaXQg aXMgcG9ydHJheWVkIGFzIGFuIGFsdGVybmF0aXZlLCBzaGFkb3cgcHJvdG9jb2wgdG8gSVB2NiB0 aGF0IGp1c3QgaGFwcGVucyB0byB1c2UgdGhlIElQdjYgcHJvdG9jb2wgZm9ybWF0IGZvciBjb252 ZW5pZW5jZSBpbnN0ZWFkIG9mIGNyZWF0aW5nIGEgbmV3IEwzIHByb3RvY29sIGZvciBpdHMgcHVy cG9zZXMuDQogVGhlIHJhdGlvbmFsaXphdGlvbiBmb3IgdGhpcyBzZWVtcyB0byBiZSB0aGF0IFNS djYgaXMgY29uZmluZWQgdG8gbGltaXRlZCBkb21haW5zLCBhbmQgd2l0aGluIGEgbGltaXRlZCBk b21haW4gd2UgY2FuIHNhZmVseSByZWRlZmluZSBzdGFuZGFyZCBwcm90b2NvbHMgaW4gYXJiaXRy YXJ5IHdheXMtLSBub3RlLCB0aGVyZSBpcyBubyBjb25zZW5zdXMgdGhhdCB0aGF0IHBoaWxvc29w aHkgaXMgYWNjZXB0YWJsZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRvbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KJmd0OyZuYnNwOyA8YnI+DQomZ3Q7PGJyPg0KJmd0OyBGcm9tOiBpcHY2IFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPmlwdjYtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBSb24gQm9uaWNhPGJy Pg0KJmd0OyBTZW50OiBUaHVyc2RheSwgT2N0b2JlciA3LCAyMDIxIDEwOjM2IFBNPGJyPg0KJmd0 OyBUbzogRWR1YXJkIE1ldHogJmx0OzxhIGhyZWY9Im1haWx0bzpldG1ldHpAZ21haWwuY29tIiB0 YXJnZXQ9Il9ibGFuayI+ZXRtZXR6QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBDYzogU1BS SU5HIFdHICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+c3ByaW5nQGlldGYub3JnPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86Nm1hbkBpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPjZtYW5AaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBTdWJqZWN0OiBS RTogW3NwcmluZ10gZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Np b24tMDI8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyA8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNw OyA8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJbmxpbmUgW1JCXTxicj4NCiZndDs8YnI+DQomZ3Q7Jm5i c3A7IDxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgUm9uPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgPGJyPg0KJmd0Ozxicj4NCiZn dDsmbmJzcDsgPGJyPg0KJmd0Ozxicj4NCiZndDsgSnVuaXBlciBCdXNpbmVzcyBVc2UgT25seTxi cj4NCiZndDs8YnI+DQomZ3Q7IEZyb206IEVkdWFyZCBNZXR6ICZsdDs8YSBocmVmPSJtYWlsdG86 ZXRtZXR6QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmV0bWV0ekBnbWFpbC5jb208L2E+Jmd0 Ozxicj4NCiZndDsgU2VudDogVGh1cnNkYXksIE9jdG9iZXIgNywgMjAyMSA1OjAzIEFNPGJyPg0K Jmd0OyBUbzogUm9uIEJvbmljYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJib25pY2FAanVuaXBlci5u ZXQiIHRhcmdldD0iX2JsYW5rIj5yYm9uaWNhQGp1bmlwZXIubmV0PC9hPiZndDs8YnI+DQomZ3Q7 IENjOiA8YSBocmVmPSJtYWlsdG86Nm1hbkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPjZtYW5A aWV0Zi5vcmc8L2E+OyBTUFJJTkcgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgU3Vi amVjdDogUmU6IFtzcHJpbmddIGRyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNv bXByZXNzaW9uLTAyPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgPGJyPg0KJmd0Ozxicj4NCiZn dDsgW0V4dGVybmFsIEVtYWlsLiBCZSBjYXV0aW91cyBvZiBjb250ZW50XTxicj4NCiZndDs8YnI+ DQomZ3Q7Jm5ic3A7IDxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7IDxicj4NCiZndDs8YnI+DQom Z3Q7IENhbiB0aGUgU0lEIGJlIHZpZXdlZCBhcyB0aGUgYWRkcmVzcyBvZiB0aGUgJnF1b3Q7aW50 ZXJmYWNlJnF1b3Q7IHRvLCBpbiB0aGlzIGNhc2UsIHRoZSBmdW5jdGlvbiB0aGF0IHJlc2lkZXMg aW4gYSBub2RlPyBGcm9tIGEgcm91dGluZyAvIGZvcndhcmRpbmcgcG9pbnQgb2YgdmlldyB0aGUg Z3JvdXAgb2YgZnVuY3Rpb25zIGlzIG1vcmUgc2ltaWxhciB0byBhIG5ldHdvcmsgKHJlcHJlc2Vu dGVkIGJ5IGEgcHJlZml4LCByYXRoZXIgdGhhbiBhIHNpbmdsZSBhZGRyZXNzKSwNCiBidXQgc3Rp bGwuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgPGJyPg0KJmd0Ozxicj4NCiZndDsgW1JCXSBJ biBSRkMgODk4NiwgYSBjbGFzc2ljIFNSdjYgU0lEIHJlcHJlc2VudHMgYSAqc2luZ2xlKiBmdW5j dGlvbiB0aGF0IHJlc2lkZXMgb24gYSAqc2luZ2xlKiBub2RlLiBJZiB5b3UgbGlrZSwgeW91IGNh biBldmVuIHNheSB0aGF0IHJlcHJlc2VudHMgYSAqc2luZ2xlKiBpbnRlcmZhY2UgdG8gYSAqc2lu Z2xlKiBmdW5jdGlvbiB0aGF0IHJlc2lkZXMgb24gYSAqc2luZ2xlKiBub2RlLjxicj4NCiZndDs8 YnI+DQomZ3Q7Jm5ic3A7IDxicj4NCiZndDs8YnI+DQomZ3Q7IEJ5IGNvbnRyYXN0LCBhIENvbXBy ZXNzZWQgU0lEIENvbnRhaW5lciAoaS5lLiwgdGhlIDEyOC1iaXQgZW50aXR5IHRoYXQgaXMgY29w aWVkIGludG8gdGhlIElQdjYgRGVzdGluYXRpb24gQWRkcmVzcyBmaWVsZCkgcmVwcmVzZW50cyBh biBlbnRpcmUgU1IgUGF0aC4gU3BlY2lmaWNhbGx5LCBpdCByZXByZXNlbnRzICptYW55KiBmdW5j dGlvbnMgdGhhdCByZXNpZGUgb24gKm1hbnkqIG5vZGVzPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJz cDsgPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgPGJyPg0KJmd0Ozxicj4NCiZndDsgRm9yIG15 IHVuZGVyc3RhbmRpbmcsIGFwYXJ0IGZyb20gdGhhdCB0aGUgKGRlZmluaXRpb24gb2YpIFNJRCBt YXkgbm90IGJlIGFsaWduZWQgd2l0aCB0aGUgbGl0ZXJhbCB0ZXh0IGluIGJlbG93IFJGQ3MsIHdo YXQgaXMgdGhlIHJlYWwgcHJvYmxlbT8gQXJlIHRoZXJlIGFueSBwcm90b2NvbHMgdGhhdCBzcGVj aWZpY2FsbHkgcmVseSBvbiB0aGlzIGRlZmluaXRpb24gb2YgYW4gSVB2NiBhZGRyZXNzPzxicj4N CiZndDs8YnI+DQomZ3Q7Jm5ic3A7IDxicj4NCiZndDs8YnI+DQomZ3Q7IFtSQl0gV2UgZG9u4oCZ dCBrbm93IGlmIHRoZXJlIGFyZSBhbnkgcHJvdG9jb2xzIHRoYXQgcmVseSBvbiB0aGlzIGRlZmlu aXRpb24gb2YgdGhlIElQdjYgYWRkcmVzcy4gQW5kIGlmIHdlIGRvbuKAmXQgdXBkYXRlIFJGQyA0 MjkxIGJlZm9yZSB2aW9sYXRpbmcgaXQsIHdlIGRvbuKAmXQga25vdyBpZiBhbnlib2R5IG1pZ2h0 IHdyaXRlIHN1Y2ggYW4gYXBwbGljYXRpb24gaW4gdGhlIGZ1dHVyZS48YnI+DQomZ3Q7PGJyPg0K Jmd0OyZuYnNwOyA8YnI+DQomZ3Q7PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUm9uPGJyPg0KJmd0Ozxicj4N CiZndDsmbmJzcDsgPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsgPGJyPg0KJmd0Ozxicj4NCiZn dDsgY2hlZXJzLDxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwO0VkdWFyZDxicj4NCiZn dDs8YnI+DQomZ3Q7Jm5ic3A7IDxicj4NCiZndDs8YnI+DQomZ3Q7Jm5ic3A7IDxicj4NCiZndDs8 YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBJRVRGIElQdjYgd29ya2luZyBncm91cCBt YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzppcHY2QGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+aXB2NkBpZXRmLm9yZzwvYT48YnI+DQomZ3Q7IEFkbWluaXN0cmF0aXZlIFJl cXVlc3RzOiA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lw djYiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vaXB2NjwvYT48YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_423b08d46294454d9a9625990ce52acbhuaweicom_-- From nobody Fri Oct 8 10:12:31 2021 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 186303A0978; Fri, 8 Oct 2021 10:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, 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=E6qlO5V9; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=cstqTtTc 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 nFTwfbyYgzWA; Fri, 8 Oct 2021 10:12:21 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05CA23A097A; Fri, 8 Oct 2021 10:12:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34375; q=dns/txt; s=iport; t=1633713141; x=1634922741; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vFEOZ4F6cS6YtYQVYg7Jf3WgN7sbydHYuHD1d0OOOco=; b=E6qlO5V9qw1SiQ7DDAQrvh4mZVTWM019jkYure7IK+Dqah42oB/PvW7m 2GfP18v9jf/IVhlGUcDzzyhNPATXfkFdqVOjGxrbKpNkbLoHgllRUHBDt ONnxA+SV6fUE5IrSEttZ1j2+sRqXqGVV/sEofl8ws0BxGoM89g4ZnjL5r 0=; IronPort-PHdr: =?us-ascii?q?A9a23=3A2UvRjxWqVqPgLOZ4D6eFuLZdbj3V8K3gAWYlg?= =?us-ascii?q?6HPw5pBd62i+9LpO0mMrflujVqcW4Ld5roEjufNqKnvVCQG5orJq3ENdpFAF?= =?us-ascii?q?npnwcUblgAtGoiJXEv8KvO5YCkzHcAEX1hgrDm3NEFPE5P4YFvf6nS58T8VH?= =?us-ascii?q?ED5Mgx4buT4E4LflYK5zee3rpbSeA5PwjG6ZOAaEQ=3D=3D?= IronPort-Data: =?us-ascii?q?A9a23=3AgG+hWqNyj6Tmr2PvrR0/lcFynXyQoLVcMsEvi?= =?us-ascii?q?/4bfWQNrUoigmAFnTcdXTiPP66OZGamct1/OY2z/EsCscPcmt9hQHM5pCpnJ?= =?us-ascii?q?55oRWUpJjg4wn8dtEp+F+WbJK5cx5hYOoSowPwcFCeG/071aui59xGQ6InRL?= =?us-ascii?q?lbCIL+cUsxObVcMpBcJ0XqPqsZh6mJaqYHR7zCl4bsel/bi1GqNgFaYBI67B?= =?us-ascii?q?5Wr83uDtNyq0N8RU8dXifpj5DcynFFNZH4TyD3YEpf2fmVUNrbSq+frxbW9+?= =?us-ascii?q?CbS+A0gT4r81L36aUYNBLXVOGBiiFIPBPPk2UYE/3d0i/1gXBYfQR8/ZzGhk?= =?us-ascii?q?dt1wdllvp2rQgBvNarJ8AgYe0gDT3EgZ/YYodcrJlD666R/1XbuaGP2wvNhS?= =?us-ascii?q?Uo2NIwC4c52DH1As/sCJ1gldQiZhuS56LO2Vucqgd4sROHpNYYSoTdmiz7ED?= =?us-ascii?q?P0mSIrPa6vX+cJC0Sg9h4ZFGvO2T9ATbjxuZx2VP0VNJ1EWEJ8k2uGlmlHzd?= =?us-ascii?q?jRCoxSUqLY5pW/Jw2RZyr/nPcDJUsaDXtdInQCeq36u12vjDx4bMd2F0jmU2?= =?us-ascii?q?n2pj+7L2yj8Xeov+BeQnhJxqFSXwmpWAxoMWB7i+L+yi1W1XJRULEl8x8bnl?= =?us-ascii?q?oBqnGTDczU3d0TQTKa4gyMh?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AGWK5NKDXCi44Wm3lHegOsceALOsnbusQ8z?= =?us-ascii?q?AXPh9KKCC9I/b3qynxppsmPEfP+UkssHFJo6HmBEDyewKjyXcV2/hRAV7GZm?= =?us-ascii?q?nbUQSTXfpfBOfZsljd8mjFh5JgPMRbAuhD4b/LfCJHZK/BiWHSebtNsbr3kp?= =?us-ascii?q?xAx92uskuFJjsaDZ2Imj0JcjpzZXcGPTWua6BJcKa0145inX6NaH4XZsO0Cj?= =?us-ascii?q?0uRO7YveDGk5rgfFovGwMnwBPmt0Lq1JfKVzyjmjsOWTJGxrkvtULflRbi26?= =?us-ascii?q?mlu/anjjfBym7o6YhMkteJ8KoAOCXMsLlRFtzfsHfuWG1TYczFgNnzmpD31L?= =?us-ascii?q?8eqqiJn/7nBbUq15qeRBDvnfKn4XiQ7N9n0Q6T9bbfuwq4nSQ8LwhKV/aoQu?= =?us-ascii?q?liA0bkAgMbzaJB+bMO0GSDu5VNCxTc2Cz7+tjTThlv0lG5uHw4jIco/jFiuK?= =?us-ascii?q?YlGfRsRLYkjQlo+VY7bVXHwZFiFPMrANDX5f5Qf1/fZ3fFvnN3yNjpWngoBB?= =?us-ascii?q?+JTkULp8TQilFt7T9E5lpdwNZakmYL9Zo7RZUB7+PYMr5wnLULSsMNd6pyCO?= =?us-ascii?q?oIXMPyAG3QRhDHNn6UPD3cZe06EmOIr4Sy7KQ+5emsdpBNxJwumI7ZWFcdrm?= =?us-ascii?q?I2c1KGM7zH4HSKyGGFfIyZZ0Wi9ihz3ekNhlTMfsucDcTYciFdryKJmYRqPv?= =?us-ascii?q?Hm?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BXAABZe2Bh/4UNJK1aHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUUHAQELAYEgMFEHd1o3MYgOA4RZYIgJA4p0j3iBLoElA08?= =?us-ascii?q?FCwEBAQ0BASoBDAoEAQGEOUUCgkgCJTQJDgECBAEBARIBAQUBAQECAQYEgRE?= =?us-ascii?q?ThWgNhkIBAQEBAwEBEAsjAQEsBAcBDwIBCBEDAQIhAQIEByEGCxQJCAIEDgU?= =?us-ascii?q?IEweCUIF+VwMvAQ6hJwGBOgKKH3iBM4EBgggBAQYEBIE2ARNBgn8NC4I1Awa?= =?us-ascii?q?BOgGDAIQTgR6FVyccgUlEgRQBQ4FmgQE+giFCAQECAYFfHgYHCYMZggwiimE?= =?us-ascii?q?BcQIgQgQyERAvLCAFBUgRCwIYOjqeCp5nKGcKgzCBM4kTiByFI32GBRSDakK?= =?us-ascii?q?LKpdAhxObX4M/kDgOhHMCBAIEBQIOAQEGgWE7gVlwFTuCNQEBMlEZD4hLhVU?= =?us-ascii?q?MFhUZgyKFFIVKdAI2AgYLAQEDCZRxAQE?= X-IronPort-AV: E=Sophos;i="5.85,358,1624320000"; d="scan'208,217";a="934862361" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Oct 2021 17:12:18 +0000 Received: from mail.cisco.com (xbe-rcd-001.cisco.com [173.37.102.16]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 198HCIFK008568 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 8 Oct 2021 17:12:18 GMT Received: from xfe-aln-003.cisco.com (173.37.135.123) by xbe-rcd-001.cisco.com (173.37.102.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 8 Oct 2021 12:12:18 -0500 Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 8 Oct 2021 12:12:17 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) 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.792.15 via Frontend Transport; Fri, 8 Oct 2021 12:12:17 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=emTZ6MWr12iVjlBwENiugbAAILXP4EQ4mr/o0V3zUgQbpvxSOPbSbSMlzGfppjSwRd+Btm48KDYsMQCGajr3LRxsVpQal3DCdJgZKAK2jr+mIfWWkCs1G9Kw8La/3Sx5pCfhiyD05VfRkpsgqQrU62wi/9CFhypSBdB+L8f2fE/26BSkiEYLYSdyG0VyvStphp08EmpbvIZjVoSewGJX+0yWXEGMFaCtzCHdgB6ujKCQpH+XvpcDM433lKtgeas65UX1+U22mb00u+DAIfMvmF1viOZIbWnSEwlR6L6PefqcYIzwsBAy6+k+dkI0HhsX3pY+kd57UcGvmeLKo5OZpA== 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=UG46fzqMAwHB6o0x4uRNlJ6pPAWVZTA33AWUYHomIl8=; b=fVOa8EYMryLVtQisGdwuMDqBDEYvnBQgaVb1Z64CRSoBSYWOGoGZ20KWIghQ7ak1RNTuiFgJQBLKAptcOpsmj8o9vUPau6CmOx34UbGO2JsImtV+NRjg4+frcZiKfgxxM6c0JvIdl+XDuoH0P7aydIftnJd1s05U0QBCfbQQ7CF9M69QbLl6lUbRKxRlblVdHv84hpV0Kew77+/kqvsQ1sLKkOwrprNwo+vIJq1eDYn9r3Z0bDtm/ZyQmuZIKIxRg5o27zWVHn8ESQN/fbTjMKlBJfCzt4Ut3VOQ0ofMhJ6c+ajfKSWiN8AX0Vs+huSxhc8g0lfliSrctO4eTeyfAA== 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=UG46fzqMAwHB6o0x4uRNlJ6pPAWVZTA33AWUYHomIl8=; b=cstqTtTc5egI0Y4nwt3MqRmyjaoIrAqYQVSPP20dmTy4XA2qQpPuetDJ13hUmi+2yqyhMlwvNGcFpi3zkVdgLUpsQ6iNHDhDq/1tK4KUQIi9XjtyLBe3jvcProf8x+3L6IFRwbt492InQ8e5cxanCMK/50qQe/CN+vh+vdCcb8g= Received: from CO6PR11MB5650.namprd11.prod.outlook.com (2603:10b6:5:35a::9) by CO6PR11MB5587.namprd11.prod.outlook.com (2603:10b6:303:139::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.20; Fri, 8 Oct 2021 17:12:16 +0000 Received: from CO6PR11MB5650.namprd11.prod.outlook.com ([fe80::6071:7cb6:d30e:b0d]) by CO6PR11MB5650.namprd11.prod.outlook.com ([fe80::6071:7cb6:d30e:b0d%4]) with mapi id 15.20.4587.022; Fri, 8 Oct 2021 17:12:16 +0000 From: "Francois Clad (fclad)" To: Greg Mirsky CC: Robert Raszuk , Ron Bonica , James Guichard , SPRING WG , "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQCeJTAAAC58nBAAAQ3tgAAHRGEgAAHK+wAAAookgAAiGUeHAAc4nAAAMAjOBAAENzmAAC/Wf/0= Date: Fri, 8 Oct 2021 17:12:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d96cebbd-21e4-44ed-1b4b-08d98a7ec763 x-ms-traffictypediagnostic: CO6PR11MB5587: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: b6eYLXdutY5Zu7iTAYI1vjrWeCz10YDDlKwgMmruRuRGv4kodUqLFU6ZpSvVUF3gWvmBNy96FU9i99x725rVzpEV6fbwa1FisoHNu19/UTNkZm5oMiRP8B4Se0VcKd5nt4EM77CRojlcxy2Gg4Ek0H5rJbZ/QNpUxn099kkEkvRm9bcUfC737cUwUo43UK17A2ZbfWDlAccRSl/xwHyt+UFWWiHl+6SiTdOVyG5+RJem6bmW+HR2kqyHFPTKyjxpgoQEp9/PkkVm75DkIzTT6h52DIlG/sxG2Ba1H8Bt94m0G6gkFaJshnzAB7JkJkLojWVdUZEZZC1rXWQuNRZhy/86szMzzMIphH3mFjnEITJEs8jowJAxQ8PtePbeNqxFrWv4FxtTYhzcRKxSUJby8IsPFxwCEX4+MzHwGp2cnQqHx2J7bx8PkkOYYIeDO/Gw/juTrMJV4dHll+a+lxYMUdimNULIuZbYuilFYyzY5h9VUXPrBp4d0xzVujP1bSV8fZ9aQSLFFKiXQbp9LskjAzTmwL42vMohi2WInoSaxKToG2gdjzMqvSkuyoyn/piHky2SefpDoQUPBv0PvnHbjfV46MXSBd5JZyJl1wkHmFt10VsY3Dz0sbh00JckJsC+LyYMnl2xuOhsNrvjYozqpj86XwntZt7mneuCSvNgDVTN7Le0qE7SGOBSiMbi1Ogwd1N0FMnPddnxmSve92uoFCyCDW1P+wcTE+ZZcNJ1KrCxpjRTcD/Lu3OVHWHyRku5xiJIzqh2r2BB3AAwlSu2Zr6YGWV73SF+6PC1jxghSYIq1/okTcgt47uakgdKt7HEc5FBRsA651YdjP1Dn0eexw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR11MB5650.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(66946007)(66446008)(71200400001)(55016002)(9686003)(66476007)(91956017)(5660300002)(76116006)(66556008)(64756008)(508600001)(316002)(54906003)(966005)(166002)(6506007)(53546011)(7696005)(52536014)(6916009)(186003)(38070700005)(86362001)(2906002)(38100700002)(122000001)(4326008)(26005)(83380400001)(8676002)(8936002)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?+9esE1wVpdMGlwK5naW6bQaPIRN5IcEIDenLFkbkwKhHb8+zDPUidg7eiO2b?= =?us-ascii?Q?GiUJ7KCkCkHbDQebNuI1+NhOQ7EkgdE5d6JdUsNG4KUcrZbTzDMl4mwwXGpa?= =?us-ascii?Q?TJc6hKDKIuRq31D8pIXn6bqzVxCv+Ll6Mzvg54XlsWpUUgyG1lwZk8eo84+r?= =?us-ascii?Q?YIqVjGBiQMb99potPEVF1aams4rVGITHIsceOfz9U5Kj5PE/Eji3msAtrv1v?= =?us-ascii?Q?9qnN06Drk2MGFQTO3AQKNML8QGdoR2geSXPwuigDrcKGbcLL1//qn28xE8Ya?= =?us-ascii?Q?8bNd0xvr+Jc+L8ENokZBTndkaVD/1LYvb4Qr1Z96OYrDYb/0i+vox9X2y1mS?= =?us-ascii?Q?ByaUk5dHrNeX78BipAcepC6vs68Ypr2Fxl34L+F5C2PO0HzaAEqwRETXHKYN?= =?us-ascii?Q?NzksUgGIKgIuSbc3y577nEwaBMPq3pM/O9Lh7BGXkzIJ3OICIdepSKyrwrud?= =?us-ascii?Q?Pl2YeBeXp7yxBow68lH3H+8EKkVRpg/AHJ+Fv4vedKxDAEMxaaUHUGoe8TSw?= =?us-ascii?Q?nXLwNOK571i8l4FDdj+onJi9VDcDt+X6CRpwRh97GAVuGGwmUu0EWih01i08?= =?us-ascii?Q?kX7c8VJ4E5DOH027LIXtJzz29ZB43TVjRQXQhaKKJxFT5cbzDYMgHPneLwYJ?= =?us-ascii?Q?oIGs3s12Zq7OG7CKr1A3DXjvFXmSIBz6sve63C9+T3F9USArANvlZv8pc5W0?= =?us-ascii?Q?Zsw7E/Gh+5/sfGQjoKK/Lp9QJbXZRBxJLZmNZLbLL+BOCa2vDRR8KP9/Sq8o?= =?us-ascii?Q?d9UU+mGvWMyiYqIeQyqiyJOxAPgGhB11uOQBi7YJEUhL+q5oQl2H2fnh7B5r?= =?us-ascii?Q?Ic28Lj+foYHJKNVIJa/6i+IKLUkGz7wEKHMWkS5K0cycTq8BhwcxJ1q3G+PO?= =?us-ascii?Q?//dXCTGvyOhDkuK4LGQ1AnMEsAJ7pJMkEZe5h/q4Ba6mRGPa6N73gPAwRB+J?= =?us-ascii?Q?dE0Iu5hZPdPAuBowcqf8L1mET3WpuYT9PC9zPDeGFflzH25sXVVP6J8j4mfD?= =?us-ascii?Q?KdfGW8n5dQJ/G9sITUnMzKt2cA4IrpiS5J1crOglldwjyecupabyAcgELOZX?= =?us-ascii?Q?XpYNNuCkV11Lb4eN3cO96WwZZNawnESz8d2TtXG2Mrho5RFbKibzmpb7xZVV?= =?us-ascii?Q?UNG2yg2hiZNeHWbAJ1zBBqxrkmwvZ7+3UX3lqmG5kZ25UcMCzg13pwgwEsIP?= =?us-ascii?Q?NxJP5U3hxxA1JLr3gDAU0PQ+x92+OhyH5nF9RUnpaDvciPJR07/9//HjtrIo?= =?us-ascii?Q?fPV4/K4obPqzww8sLvgP6xLyH76epwjQyYqR7cVXI2tBFHOOQP3xzTaUzqA6?= =?us-ascii?Q?RwC3oTwf8hujtaLBWJE21IittGl7uEdaOPed5Jnq3wSCag=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO6PR11MB5650A1361A5F75A4827904EAACB29CO6PR11MB5650namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO6PR11MB5650.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d96cebbd-21e4-44ed-1b4b-08d98a7ec763 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2021 17:12:16.4124 (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: 6WXpY4PVkCg99NA1WIYFPb4wgmfR7YO7FE/JJDxfGUogOUwLMIt7iUtVZDVwUgId X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR11MB5587 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xbe-rcd-001.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 08 Oct 2021 17:12:28 -0000 --_000_CO6PR11MB5650A1361A5F75A4827904EAACB29CO6PR11MB5650namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Thank you for the confirmation. I am glad that the matter of combining C-SI= Ds of different flavors is clear now. Thanks, Francois From: Greg Mirsky Date: Thursday, 7 October 2021 at 20:15 To: Francois Clad (fclad) Cc: Robert Raszuk , Ron Bonica , James Guichard , SPRING WG= , spring-chairs@ietf.org Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ Hi Francois, thank you for your detailed response and confirming that C-SIDs of differen= t flavors/behavior may be present in the same SRH and even the same CSID co= ntainer. I've noticed Ron's proposal as I was trying to formulate my questi= on. His proposal highlighted what I am trying to understand - the relations= hip between NEXT-C-SID and REPLACE-C-SID. I concur with Ron. The WG has ado= pted the compression analysis draft, and the updates and an additional analy= sis Ron proposed will keep the discussion and decision-making process on th= e firm technical foundation. Regards, Greg On Thu, Oct 7, 2021 at 9:17 AM Francois Clad (fclad) > wrote: Hi Greg, It is the role of the SR Source Node [Section 3.1 of RFC 8754] to form the = segment list in the SRH. It learns about the available SIDs in the network = with their associated behavior and flavors via control plane and/or managem= ent plane protocols, as described in Section 8 of RFC 8986, and selects the= SIDs that are the most appropriate for the segment list. Each SR Segment Endpoint Node [Section 3.3 of RFC 8754] simply executes the= pseudocode of a locally instantiated SID when it receives a packet matchin= g that SID. The SR Segment Endpoint Node does not need to bother about the = behavior/flavor of the subsequent SRv6 SIDs. This SRv6 logic applies to the C-SID flavors as well. The choice of flavors= for the SIDs in the SID List is up to the SR Source Node. It is indeed possible to mix SIDs of different C-SID flavors in the same SR= H, and even in a single C-SID container. Thanks, Francois From: Greg Mirsky > Date: Wednesday, 6 October 2021 at 19:19 To: Francois Clad (fclad) > Cc: Robert Raszuk >, Ron Bonica= >, James Guichard >, SPRING WG >, spri= ng-chairs@ietf.org > Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ Hi Francois, thank you for the clarification. It is still not clear how a node selects w= hich flavor of CSID to use on the next compressed CSID that may happen also= be in the next CSID container. As I understand it, a CSID container must u= se the same flavor of compression but CSID containers with different compre= ssion flavors in the same SRH are allowed. Is that correct understanding? Regards, Greg On Wed, Oct 6, 2021 at 7:05 AM Francois Clad (fclad) > wrote: Hi Greg, A node that supports this draft in its entirety can instantiate SRv6 SIDs (= e.g., End and End.X SIDs) with any of the three C-SID flavors. In particular, a node can instantiate multiple SRv6 SIDs bound to different= C-SID flavors, possibly with different C-SID lengths. It can also instanti= ate SRv6 SIDs with behaviors and flavors defined in RFC 8986. As defined in Section 4.3 of RFC 8754 and again in Section 3 of RFC 8986, u= pon receiving an IPv6 packet with a destination address matching a FIB entr= y that represents one of these locally instantiated SIDs, the node processe= s the packet according to the behavior (and flavor(s)) (i.e. pseudocode) of= that SID. RFC 8754 and 8986 have already standardized these mechanisms and the C-SID = draft only leverages the same SRv6 dataplane to introduce new endpoint flav= ors for compression. Francois From: spring > on b= ehalf of Greg Mirsky > Date: Tuesday, 5 October 2021 at 23:37 To: Robert Raszuk > Cc: Ron Bonica >, James Guichard >, SPRING WG >, spring-chairs@ietf.org > Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ Hi Robert, as I understand it, you believe everything that is written in the draft. I = hope you can help me find an answer to one simple question: Can a node that supports this draft in its entirety, i.e., supports all "fl= avors" defined in the document, process received SRv6 packet with the SRH e= ncoded according to the specification? So far, the proponents of the draft referred to "planning" how flavors of S= Rv6 SID compressed. To the best of my understanding, that is is a clear dem= onstration of the incompatibility between flavors defined in the CSID draft= . Regardless of what is written in it. Regards, Greg On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk > wrote: Ron & SPRING WG chairs, Through this discussion we first have seen a debate if we need one or more = data planes to compress SIDs in SRv6. WG clearly stated we need one. Following that we have observed a first terminology shift to see if asking = how many solutions should be supported will work any better. To that many W= G members clearly stated that they support one solution. Well please notice that the draft in question in its introduction states: Abstract This document defines a compressed SRv6 Segment List Encoding in the Segment Routing Header (SRH). This solution does not require any SRH data plane change nor any SRv6 control plane change. This solution leverages the SRv6 Network Programming model. So based on my understanding of English the entire draft talks about a sing= le solution. Then suddenly a new question popped up: how many behaviours are acceptable. I bet number of folks including myself said "one" keeping in mind previous = discussions and the definition of "one" meaning based on the SRv6 data plan= e in compliance to [RFC8402], [RFC8754] and [RFC8986]. Interestingly enough the draft in question defines not behaviours but flavo= rs as new variants of the already defined behaviors in Standards Track RFCs= . Namely it defines: 4.1. NEXT-C-SID Flavor 4.2. REPLACE-C-SID Flavor The newly defined behaviour End.XPS is optional. So if there is anything to ask here is to check if WG is ok with two flavor= s or not. I do not recall that question has ever been asked formally during= the WG adoption call. With that let's note that optimal compressed SID size may be different netw= ork to network. One size does not fit all. Draft says: 6.1. C-SID Length The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A C-SID length of 16-bit is recommended. The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths. A C-SID length of 32-bit is recommended. While I personally think 8-bit should be an option, if we choose a single f= lavor we will introduce suboptimality for no good reason. Hardware capable = of supporting any flavor clearly can do LPM on locator. Also hardware capab= le of supporting one flavor can support few other flavors as this is pretty= much just an offset game. Kind regards, Robert On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica > wrote: Pablo, Ae you sure? Please look at the question as Joel asked it ( https://mailarc= hive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ ). = Ron _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_CO6PR11MB5650A1361A5F75A4827904EAACB29CO6PR11MB5650namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Greg,<= o:p>

    &nbs= p;

    Thank you= for the confirmation. I am glad that the matter of combining C-SIDs of dif= ferent flavors is clear now.

    &nbs= p;

    Thanks,

    Francois<= o:p>

    &nbs= p;

    From: Greg Mirsky <gre= gimirsky@gmail.com>
    Date: Thursday, 7 October 2021 at 20:15
    To: Francois Clad (fclad) <fclad@cisco.com>
    Cc: Robert Raszuk <robert@raszuk.net>, Ron Bonica <rbonica= =3D40juniper.net@dmarc.ietf.org>, James Guichard <james.n.guichard@fu= turewei.com>, SPRING WG <spring@ietf.org>, spring-chairs@ietf.org = <spring-chairs@ietf.org>
    Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.= org/doc/draft-filsfilscheng-spring-srv6-srh-compression/    <= /p>

    Hi Francois,

    thank you for your detailed response and confirming = that C-SIDs of different flavors/behavior may be present in the same S= RH and even the same CSID container. I've noticed Ron's proposal as I was t= rying to formulate my question. His proposal highlighted what I am trying to understand - the relationship between= NEXT-C-SID and REPLACE-C-SID. I concur with Ron. The WG has adopted the compression analysis draft, and the updates and an additional anal= ysis Ron proposed will keep the discussion and decision-making process on t= he firm technical foundation.

     

    Regards,

    Greg

     

    On Thu, Oct 7, 2021 at 9:17 AM Francois Clad (fclad)= <fclad@cisco.com> wrote:=

    Hi Greg,

     

    It is the role of the SR Source Node [Section 3.1 of RFC 8754] to = form the segment list in the SRH. It learns about the available SIDs in the= network with their associated behavior and flavors via control plane and/or management plane protocols, as descri= bed in Section 8 of RFC 8986, and selects the SIDs that are the most approp= riate for the segment list.

     

    Each SR Segment Endpoint Node [Section 3.3 of RFC 8754] simply exe= cutes the pseudocode of a locally instantiated SID when it receives a packe= t matching that SID. The SR Segment Endpoint Node does not need to bother about the behavior/flavor of the sub= sequent SRv6 SIDs.

     

    This SRv6 logic applies to the C-SID flavors as well. The choice o= f flavors for the SIDs in the SID List is up to the SR Source Node.

     

    It is indeed possible to mix SIDs of different C-SID flavors in th= e same SRH, and even in a single C-SID container.

     

    Thanks,

    Francois

     

     

    From: Greg Mirsky <gregimirsky@gmail.c= om>
    Date: Wednesday, 6 October 2021 at 19:19
    To: Francois Clad (fclad) <fclad@cisco.com>
    Cc: Robert Raszuk <robert@raszuk.net>, Ron Bonica <rbonica=3D40juniper.net@dmarc.iet= f.org>, James Guichard <james.n.guichard@futurewei.com>, SPRING WG <spring@= ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>
    Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/

    Hi Francois,

    thank you for the clarification. It is still not clear how a node = selects which flavor of CSID to use on the next compressed CSID that may ha= ppen also be in the next CSID container. As I understand it, a CSID container must use the same flavor of compressi= on but CSID containers with different compression flavors in the same SRH a= re allowed. Is that correct understanding?

     

    Regards,

    Greg

     

    On Wed, Oct 6, 2021 at 7:05 AM Francois Clad (fclad) <fclad@cisco.com> wrote= :

    Hi Greg,

     

    A node that supports this draft in its entirety can instantiate SR= v6 SIDs (e.g., End and End.X SIDs) with any of the three C-SID flavors.

     

    In particular, a node can instantiate multiple SRv6 SIDs bound to = different C-SID flavors, possibly with different C-SID lengths. It can also= instantiate SRv6 SIDs with behaviors and flavors defined in RFC 8986.

     

    As defined in Section 4.3 of RFC 8754 and again in Section 3 of RF= C 8986, upon receiving an IPv6 packet with a destination address matching a= FIB entry that represents one of these locally instantiated SIDs, the node processes the packet according to the = behavior (and flavor(s)) (i.e. pseudocode) of that SID.

     

    RFC 8754 and 8986 have already standardized these mechanisms and t= he C-SID draft only leverages the same SRv6 dataplane to introduce new endp= oint flavors for compression.

     

     

    Francois

     

    From: spring <spring-bounces@ietf.o= rg> on behalf of Greg Mirsky <gregimirsky@gmail.com>
    Date: Tuesday, 5 October 2021 at 23:37
    To: Robert Raszuk <robert@raszuk.net>
    Cc: Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org>, James Guic= hard <james.n.guichard@futurewei.com>, SPRING WG <spring@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>
    Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/

    Hi Robert,

    as I understand it, you believe everything that is written in the = draft. I hope you can help me find an answer to one simple question:

    Can a node that supports this draft in its entirety, i.e., support= s all "flavors" defined in the document, process received SRv6 pa= cket with the SRH encoded according to the specification?

    So far, the proponents of the draft referred to "planning&quo= t; how flavors of SRv6 SID compressed. To the best of my understanding, tha= t is is a clear demonstration of the incompatibility between flavors defined in the CSID draft. Regardless of what is writ= ten in it.

     

    Regards,

    Greg

     

    On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk <robert@raszuk.net> wrote:=

    Ron & SPRING WG chairs,

     

    Through this discussion we first have seen a debate if we need one= or more data planes to compress SIDs in SRv6. WG clearly stated = we need one. 

     

    Following that we have observed a first terminology shift to see i= f asking how many solutions should be supported will work any better. To th= at many WG members clearly stated that they support one solution. 

     

    Well please notice that the draft in question in its introduction = states: 

     

    Abstract

       This document defines a compressed SRv6 Segment List Encoding = in the
       Segment Routing Header (SRH).  This solution does = not require any SRH
       data plane change nor any SRv6 control plane change.  = This solution
       leverages the SRv6 Network Programming model.

     

    So based on my understanding of English the entire draft talks abo= ut a single solution. 

     

    Then suddenly a new question popped up: how many behaviours a= re acceptable. 

     

    I bet number of folks including myself said "one" keepin= g in mind previous discussions and the definition of "one" meanin= g based on the SRv6 data plane in compliance to [RFC8402], [RFC8754] and [RFC8986].

     

    Interestingly enough the draft in question defines not behaviours = but flavors as new variants of the already defined behaviors in Standards T= rack RFCs. Namely it defines: 

     

    4.1.  NEXT-C-SID Flavor

    4.2.  REPLACE-C-SID Flavor

     

    The newly defined behaviour End.XPS is optional. 

    So if there is anything to ask here is to check if WG is ok with two flavor= s or not. I do not recall that question has ever been asked formally d= uring the WG adoption call. 

     

    With that let's note that optimal compressed SID size may be diffe= rent network to network. One size does not fit all. Draft says: 

    6.1.  C-SID Length

       The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengt= hs.  A
       C-SID length of 16-bit is recommended.

       The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID le= ngths.
       A C-SID length of 32-bit is recommended.

     

    While I personally think 8-bit should be an option, if we choose a= single flavor we will introduce suboptimality for no good reason. Hardware= capable of supporting any flavor clearly can do LPM on locator. Also hardware capable of supporting one flavor can = support few other flavors as this is pretty much just an offset game. =

     

    Kind regards,

    Robert

     

     

     

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

    --_000_CO6PR11MB5650A1361A5F75A4827904EAACB29CO6PR11MB5650namp_-- From nobody Fri Oct 8 10:14:47 2021 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 7994D3A09B5; Fri, 8 Oct 2021 10:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 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, 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=VfyZ6zji; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0inmVjmO 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 y4LR_XXluwUT; Fri, 8 Oct 2021 10:14:40 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5696A3A09A1; Fri, 8 Oct 2021 10:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19503; q=dns/txt; s=iport; t=1633713279; x=1634922879; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=cl3yA9IirxOw2fIHzafQUUCrp2jJJ24ufAKiibrEHUA=; b=VfyZ6zjiRvrZ4eGPSlcuMjtjugUSW4/DeuCA3v1TD26dr52naT65m1EN w+BfY1HLvVxX37Dfttm2rIcgSbprsNON7hyUFtcN3iP9DyT3CS8F+9EJc kwxEVwcFAPsOWXkYNHmqzLsmXxd6GW9FaYWtLiK803lEimd3Wg1Bfg1fe U=; IronPort-PHdr: =?us-ascii?q?A9a23=3AlJqDOhf4JH1tftI1uN/pX8T2lGM/r4qcDmcuA?= =?us-ascii?q?tIPhLdHc6Dl9JPnbwTT5vRo2VnOW4iTq/dJkPHfvK2oX2scqY2Av3YPfN0pN?= =?us-ascii?q?VcFhMwakhZmDJuDDkv2f/HvZi0+Ws9FUQwt83SyK0MAHsH4ahXbqWGz6jhHH?= =?us-ascii?q?BL5OEJ1K+35F5SUgd6w0rW5+obYZENDgz/uCY4=3D?= IronPort-Data: =?us-ascii?q?A9a23=3AWW9apKj4kWBLZDuh4dthjc+GX161hxIKZh0uj?= =?us-ascii?q?C45NGQN5FlHY01jehtvD2HQPvjfNjGhLot1Otvko04C75aHy4M1SAdk/i49R?= =?us-ascii?q?CxjpJueD7x1DKtf0wB+jyH7ockOA/w2MrEsF+hpCC+BzvuRGuK59yAljfnYH?= =?us-ascii?q?uCU5NPsY0ideyc1EE/Ntjo78wIJqtYAbemRW2thi/uryyHsEAfNNwpPD44hw?= =?us-ascii?q?/nrRCWDExjFkGhwUlQWPZintbJF/pUfJMp3yaqZdxMUTmTId9NWSdovzJnhl?= =?us-ascii?q?o/Y1w0mBtXgmbHhfwhbBLXTJgOJzHFRXsBOgDAb+Xd0ifl9ZaFaMBsK49mKt?= =?us-ascii?q?4gZJNFlu5e0QAsBNazXk+NbWB5de817FfMZpOKfcSbj4KR/yGWDKRMA2c5GF?= =?us-ascii?q?1ksPIsXv+13CGBU7tQZJSwDKBeZiIqe26qhS+9jrsUuMMetO5kQ0llixDTUF?= =?us-ascii?q?rAgB5/eQq7K7MVU9Dktmt1UEOnTZowSbj8HRAjbahRDfFEaFLoxme6pgj/0d?= =?us-ascii?q?Dgwlb4/jcLb+EDJxwB3lbPqKteQK5qBRN5emQCToWeuwogwOTlCXPT39NZP2?= =?us-ascii?q?ivEajfzoB7G?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AQGs05qFQI6aZ4oHYpLqFSpHXdLJyesId70?= =?us-ascii?q?hD6qkvc31om52j+fxGws516fatskdvZJkh8erwX5VoMkmsi6KdgLNhfItKOT?= =?us-ascii?q?OHhILGFvAY0WKP+UyEJ8S6zJ8g6U4CSdk/NDSTNykBsS+S2mDReLxMrKjlgc?= =?us-ascii?q?KVbKXlvgpQpGpRGsddBnJCe36m+zpNNXB77PQCZf6hz/sCgwDlVWUcb8y9CH?= =?us-ascii?q?VAdfPEvcf3mJXvZgNDLwI76SGV5AnYq4LSIly95FMzQjlPybAt/SzuiAri/J?= =?us-ascii?q?iutPm911v1y3LT1ZJLg9Hso+EzRvBky/JlbwkEuDzYI7iJaIfy+gzdZ9vfsW?= =?us-ascii?q?rCpeO85yvI+f4Ds085MFvF+icFkDOQoQrGo0WSuWNwx0GT+/AQgFkBepZ8bU?= =?us-ascii?q?UzSGqF16NohqAO7Itbm22erJZZFhXGgWD04MXJTQhjkg6urWMlivN7tQ0TbW?= =?us-ascii?q?IyUs4bkWUkxjIeLH7AJlOM1Kk3VO11SM3M7vdfdl2XK3jfo2l02dSpGnA+BA?= =?us-ascii?q?2PTEQOstGcl2E+pgE382IIgMgE2nsQ/pM0TJdJo+zCL6RzjblLCssbd7h0Cu?= =?us-ascii?q?sNSda+TmbNXRXPOmSPJkmPLtBKB1vd75rspLkl7uCjf5IFiJM0hZTaSVtd8X?= =?us-ascii?q?U/fkr/YPf+lKGjMiq9CVlVeA6dhP22y6IJz4EUdYCbRxFrEmpe4fdIi89vdv?= =?us-ascii?q?HmZw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BXAAB9e2Bh/5FdJa1aHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUUHAQELAYEgMCMuB3daNzGIDgOEWWCICQOKdI94gS4UgRE?= =?us-ascii?q?DVAsBAQENAQE3CgQBAYR+AoJIAiU0CQ4BAgQBAQESAQEFAQEBAgEGBIERE4U?= =?us-ascii?q?7CCUNhkIBAQEBAxILEBMBASwLAQ8CAQgOAwMBAiQLIREdCAEBBAENBQgTB4J?= =?us-ascii?q?QgX5XAy8BDqEnAYE6AoofeIEzgQGCCAEBBgQEgUpBgn8NC4I1AwaBOgGDAIQ?= =?us-ascii?q?ThnUnHIFJRIEUAUOCZz6CIUICA4EjBQESASMeBgeDIoIMIopiL0IIXAQbOCA?= =?us-ascii?q?CWRZNBx8PKhEpngqNTJFDZwqDMIEziROOPIYFFINqi2yGRZB7hxOPEoxNgz+?= =?us-ascii?q?VOQIEAgQFAg4BAQaBYTtpcHAVO4JpURkPgz6KYgwWFRmDIoRZO4VKdAI2AgY?= =?us-ascii?q?LAQEDCZRxAQE?= X-IronPort-AV: E=Sophos;i="5.85,358,1624320000"; d="scan'208,217";a="674508649" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Oct 2021 17:14:36 +0000 Received: from mail.cisco.com (xbe-rcd-007.cisco.com [173.37.102.22]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 198HEakV009815 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 8 Oct 2021 17:14:36 GMT Received: from xfe-rtp-005.cisco.com (64.101.210.235) by xbe-rcd-007.cisco.com (173.37.102.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 8 Oct 2021 12:14:36 -0500 Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xfe-rtp-005.cisco.com (64.101.210.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 8 Oct 2021 13:14:35 -0400 Received: from NAM04-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Fri, 8 Oct 2021 12:14:35 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HM6L8OQ2rWKVQgAIt3zoforlljc4RcrQZP7Q3qHJV5J2Qd1MsXNaxsitoBDn7R2maCei5dQoU+eBjBKJRCrPQoIYE2Z6ABtMGcIwH3ezCGZgzxTGMnKRiQPFYtwSAs1QGLBfaTgyWViPsnMxc0S1mO+PRBWLnhApzUepQPnx+qsVdc1fWy7n+4LS/FyqchqrJfT+ko9FrvgiPIf+W8JJd9c4DXze5Q4CxdrRVqZ3KO6hmXgQYEbGJn16dNIliUxuvhNHe13MZ+7in2UcUdPQ0DWZV8Gq9lXNQvz6Ic87fViQuuDrgOeN7634tLkOJhdsEqCbJZVTGZPq38XeO7Rl3Q== 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=pXQ4p3SLHUmkzXS+y0KZu0g3mWm6P3p3g3PO3bjMVJM=; b=IJSgI6quLLPgoRpLvq0syj71qtv7+SsPWc8DGEx+vC8SNV5u9rk2hSKBfmB9Jo+jDixkpvxVNNPk9i9Q5HemWJxYehnDa9T2NXldZFMMkcXyrMNpBswpgIcxVk65kvZS01dYD/b2/x7KwL8LcSdDxYrlAlpQ00e7dmAzNCea/wS3pfZKpN2tJgl3AEjoM+UIfdEoZLbjaptQLGxo3Tf8eVYezKwfJ/RK3Z1rM/jwg25P+L7ZOKb3kBQBtpLXBKgpTmwaAA/p4MsXZEn4Q7CnmSDqaAO6afuOPrkKulmO3W12TwTUXZgd0cGNxt1cfXFWDEWlJLl6OFBjKFErcxDu6A== 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=pXQ4p3SLHUmkzXS+y0KZu0g3mWm6P3p3g3PO3bjMVJM=; b=0inmVjmOR4j635aPOyAqh7S+SQXdSIAPc4IHS6w7UWnJ3eTkgHKkheqZfxLmxcbWf+8nSV6xKKOYEAeFbM2A7Xv059jlE4Zsh4Y6Av8Kff7EJ7yxsxMBntMGSnbMxiPL1wUzdqA51hk5Ig30s3bP001GumfYdpbyP5k+ZXpE0co= Received: from CO6PR11MB5650.namprd11.prod.outlook.com (2603:10b6:5:35a::9) by CO6PR11MB5569.namprd11.prod.outlook.com (2603:10b6:303:139::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.18; Fri, 8 Oct 2021 17:14:32 +0000 Received: from CO6PR11MB5650.namprd11.prod.outlook.com ([fe80::6071:7cb6:d30e:b0d]) by CO6PR11MB5650.namprd11.prod.outlook.com ([fe80::6071:7cb6:d30e:b0d%4]) with mapi id 15.20.4587.022; Fri, 8 Oct 2021 17:14:32 +0000 From: "Francois Clad (fclad)" To: Tarek Saad , James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQFKdpbcABx8r/Y= Date: Fri, 8 Oct 2021 17:14:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5e793bc9-2644-4fd3-b261-08d98a7f1878 x-ms-traffictypediagnostic: CO6PR11MB5569: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0W0IHFxj+FyVDQxhqtNVqgW3Slfn1pVPJAMgNCLtISUsndsmRWFzV/cY5Fv38u/0U2s7hv0CbIkbvpGKcLIES+3V9ZUxlCTS0JytLyZWuL9Me5gvc05p6p8eMG4CZcVmG/Z8/wR1Ka9vrVzb1AbFOzgJF3Y5zxYhfNmz1SBDK8IDMuYw6jwsBUKI7Wd8kM64LGovdSdr9WHC9IFtXNyuEwrZXLD3f0z+P2UZw4WPFUnqHVT8RXiXT77e28jJSVqre7XonTZnxUeAusRvePdpEzkJboVFCZRiqzHzJ4ng5WCgOr0Lj0nPzUZEEYmFSv0LqRsYSYUMHz0hxPZY/zR+qsxkaSJDrBi6hNs1cJclKc964bUoRW0GzkZ6GBN/YbroeJrJUo/su6abd2bG7AGxqoE8WEHhBfFuUKeHJnw81gIbxIVLwUOwGLy5P1uX9b/GNQLJOj6n7ZosQYEh4qPPymjoZdSRj1NFGIL1mKgzXSke6IWos8w5PoYWukzocI1g4eAIWSj+ZAWZ5tQV9VhjjG/We1WjBK2TGKduno9ugYnwPnyr/nyn3xgaHAGoW1j3xFA8/yL0CO/HRliI2YzgeJWOIm51SecnsN8g4wPhieD8Lycj4dJmzAnfGpIAluay/j8xiwkLhY2BQfSfa+zJG1uYae+TSCy+lTWLoFxHMco4E+X1WdYbwgCstjjkvtTaj4YwJnd3nuHw32kPvvWMWDtel+fIfszgJviZ1MBa6FR7uCQv/1XoOfhg7QXZPKaqiCBh3uOOFaCN4kwmwhOyxZL4M2LheP///i6HxaN7sSA= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR11MB5650.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(55016002)(66476007)(66556008)(64756008)(9686003)(66446008)(26005)(76116006)(53546011)(66946007)(83380400001)(91956017)(6506007)(8936002)(86362001)(7696005)(316002)(8676002)(2906002)(186003)(52536014)(110136005)(5660300002)(122000001)(508600001)(38070700005)(38100700002)(966005)(4326008)(71200400001)(166002)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?mkO6Mod5qhU0cWhZvTg/3LsKwyVUubvy9SZs5XyKBO9WKUEgTeyWHtvv?= =?Windows-1252?Q?kgRWL9J4FqjzOLWp4tRdyy1VdnVI6CRnxsEvkiO4nGTqHV1QPOk7IUjm?= =?Windows-1252?Q?kYpeD2tJcgqvmPnYM/uSjmzmuIOktaMagBtEh7QqgWf1P311/EPakVSF?= =?Windows-1252?Q?lzOVJEJvmkjz11iSZGtyd9GGIZEcSdheZezMYiVYeZ5dVMIRA8P9Ldcv?= =?Windows-1252?Q?5Z4XdnjGJrkWJ6IFS+swFDsBegoAztLt/FmVb/WGVqCl6cHcM0wfp2th?= =?Windows-1252?Q?Rf/F3Zd598iNPkMHsTzcQBIdwnbjARN7Hx8enFkbQYgsExpdOES5BdiE?= =?Windows-1252?Q?C2OzZRZaj5lXNetc9Av5MUOB2LKu2YH6g38EQJVtZ/rwgLTMj05Yo7Os?= =?Windows-1252?Q?F7bdFiJkl5MBGTzXwAMCISPmyUbkLknMegCXNbe3oXarj/4+1U7F9vJv?= =?Windows-1252?Q?KqXrmJla3vnMN5eobB8+Hqfdwdb0ewCnU0tBOY7UCRu/EgRRARzy6wc2?= =?Windows-1252?Q?t43EV2jzExahAfVz+iH/7ffHMp7+G/PS8UU1dtuDPQ3XTDyKglBXXltZ?= =?Windows-1252?Q?kNmzM/J+2w5l0z1PgY2fSUYSySBn6G0HptK37pF19lTDp2pU/5OUWeza?= =?Windows-1252?Q?JQmeNQn4XocShz5MVxEbzeT+zAITFmx6fVM/30c33QG9VemmsDZXOCKB?= =?Windows-1252?Q?ABynqy3XlG/twcAoIUrqA91XawC3CdWQuMSrhIs5qfhFHsGmcjYNIFMj?= =?Windows-1252?Q?BaZlJaACKEAYI6fYTSMoYFArFMd1mgu8HOiWfcgV5W0DM9IwNVTGc+pA?= =?Windows-1252?Q?lN6JnU7cDLLyXeGjn1EaVnYROaAYvsaIvDMuQK7DBY6hIYnRJO26mypZ?= =?Windows-1252?Q?x855HbbOHkjRwgzrNjeAoX4PEfmhiaIwiRrZoHGHxYRUop1EFmSaRc/r?= =?Windows-1252?Q?rkgyF51lrTukBR3pLuu3lv/My0wMP3rusLZYLsiRR2SLH/Fw6seUwZTR?= =?Windows-1252?Q?npwY5pK6enyADqCTDwDqCScUHEjBchJ+uAyvMGeMB2RfgcxPK9gInbJw?= =?Windows-1252?Q?23liZ+DS3hQm5hWw9cM8ff7qYbm5+FfySl7BY76hbRbIBlvaKXo+m2SJ?= =?Windows-1252?Q?hAcQH7YQDgFqvtwzefYdDMrEn9hxwq/B8DUA7g21m9vNss/nhGzzCYR/?= =?Windows-1252?Q?wXfpn9CV5dDcKtU+wDP9gEK+5Ish6zptfFChWaLPXWNgjmm+H1dMO0MD?= =?Windows-1252?Q?k70L+JDZB738rMcmsdcrX7O0+UG0PzTN/DMAfWtXyfwi8I406ob/qkn6?= =?Windows-1252?Q?hw/GdjZ22ZFK5l9OcFkXV45dHqfSwHmiKYjqJg+tyJilH2rBX1IWad/t?= =?Windows-1252?Q?A8Gc2AQ26Hg873sRrlD96aom4z1j/wF42wS44nzUsGYZliUaoq+Q5w94?= =?Windows-1252?Q?0jlJz69SqdrCUSm1O7LAdg=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO6PR11MB56506762521C8E68EC2D4C11ACB29CO6PR11MB5650namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO6PR11MB5650.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5e793bc9-2644-4fd3-b261-08d98a7f1878 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2021 17:14:32.4862 (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: Ek/4NyuhXrkXZiJ6eGM7Tx88dsyvT+UEfgJFpT0DwjXzsebqpFfcXT1lkYAmUp+P X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR11MB5569 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.22, xbe-rcd-007.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 08 Oct 2021 17:14:46 -0000 --_000_CO6PR11MB56506762521C8E68EC2D4C11ACB29CO6PR11MB5650namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Tarek, I am assuming that the border node is an SR segment endpoint node in your q= uestion. This node processes the packet according to the behavior bound to the local= ly instantiated SID that was matched (see Section 4.3 of RFC 8754). There i= s no interpretation required. It is the responsibility of the SR source to make sure that the SIDs in the= Segment-List are used appropriately. This applies to all SRv6 SIDs, includ= ing those defined in RFC 8986. It is the same as ensuring that there is not= an End.DT4 SID in the middle of the Segment-List or that an End.X SID boun= d to the right interface is used. Thanks, Francois From: spring on behalf of Tarek Saad Date: Friday, 8 October 2021 at 06:06 To: James Guichard , SPRING WG Cc: spring-chairs@ietf.org Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ Hi all, I=92ve read this draft. It is proposing 2 different encodings schemes for c= ompressed sequence of SRv6 SIDs (and an optional behavior on border nodes).= . Although Section 4 makes a claim that different deployments usecase may dee= m one encoding scheme superior over the other, I could not glean in which c= ases a scheme would outperform the other and why? Or, why is the WG trying = to standardize both the two flavors -- keeping in mind the complex HW proce= dures evident by the proposed different pseudo codes in the draft. Also, are there concerns of misinterpreting (wrongfully decoding) a GSID se= quence for a C-SID-sequence (or vice-versa) for a received packet on border= nodes that may support both encoding flavors simultaneously? For these reasons, I think this it is still premature for this draft to be = adopted, and I oppose its adoption. Regards, Tarek From: spring on behalf of James Guichard Date: Friday, October 1, 2021 at 10:05 AM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a =93living=94 document; it may change as it goes thr= ough review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_CO6PR11MB56506762521C8E68EC2D4C11ACB29CO6PR11MB5650namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    Hi Tarek,=

    &nbs= p;

    I am assu= ming that the border node is an SR segment endpoint node in your question.<= o:p>

    &nbs= p;

    This node= processes the packet according to the behavior bound to the locally instan= tiated SID that was matched (see Section 4.3 of RFC 8754). There is no inte= rpretation required.

    &nbs= p;

    It is the= responsibility of the SR source to make sure that the SIDs in the Segment-= List are used appropriately. This applies to all SRv6 SIDs, including those= defined in RFC 8986. It is the same as ensuring that there is not an End.DT4 SID in the middle of the Segment-= List or that an End.X SID bound to the right interface is used.<= /span>

    &nbs= p;

    Thanks,

    Francois<= o:p>

    &nbs= p;

    From: spring <spring-b= ounces@ietf.org> on behalf of Tarek Saad <tsaad.net@gmail.com>
    Date: Friday, 8 October 2021 at 06:06
    To: James Guichard <james.n.guichard@futurewei.com>, SPRING WG= <spring@ietf.org>
    Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
    Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.= org/doc/draft-filsfilscheng-spring-srv6-srh-compression/    <= /p>

    Hi a= ll,

     

    I=92= ve read this draft. It is proposing 2 different encodings schemes for compr= essed sequence of SRv6 SIDs (and an optional behavior on border nodes)..

    Alth= ough Section 4 makes a claim that different deployments usecase may deem on= e encoding scheme superior over the other, I could not glean in which cases= a scheme would outperform the other and why? Or, why is the WG trying to standardize both the two flavors -- keepi= ng in mind the complex HW procedures evident by the proposed different pseu= do codes in the draft.

     

    Also= , are there concerns of misinterpreting (wrongfully decoding) a GSID sequen= ce for a C-SID-sequence (or vice-versa) for a received packet on border nod= es that may support both encoding flavors simultaneously?

     

    For = these reasons, I think this it is still premature for this draft to be adop= ted, and I oppose its adoption.

     

    Rega= rds,

    Tare= k

     

     

    From: spri= ng <spring-bounces@ietf.org> on behalf of James Guichard <james.n.= guichard@futurewei.com>
    Date: Friday, October 1, 2021 at 10:05 AM
    To: SPRING WG <spring@ietf.org>
    Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
    Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

    Dear WG:

     

    The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a sol= ution for SRv6 compression.

     

    The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

     

    Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

     

    1. The SPRING working group is adopting a document = that has multiple SRv6 Endpoint behaviors.
    2. The document is a =93livi= ng=94 document; it may change as it goes through review and analysis by the= SPRING working group.
    3. All open discussion point= s raised on our mailing list MUST be addressed BEFORE said document is allo= wed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maint= ained by the document editor in conjunction with the chairs.
    4. If this document is adopt= ed by the working group, the chairs specify as part of the adoption call th= at the following text describing an open issue be added to the document in the above-described open issues section:
      • "Given that the working group has said that it wants to standar= dize one data plane solution, and given that the document contains multiple= SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution obj= ective.".

     

    Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open d= iscussion points you would like addressed should the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    --_000_CO6PR11MB56506762521C8E68EC2D4C11ACB29CO6PR11MB5650namp_-- From nobody Fri Oct 8 10:35:01 2021 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 CF3853A0AE2; Fri, 8 Oct 2021 10:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.588 X-Spam-Level: X-Spam-Status: No, score=-9.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=a1rDczjg; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=XYIDXE9C 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 0C2-lkOJelVd; Fri, 8 Oct 2021 10:34:52 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A241A3A0AE0; Fri, 8 Oct 2021 10:34:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43192; q=dns/txt; s=iport; t=1633714492; x=1634924092; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wic/i5uS3W53q54WQfYR25ItAT9mjVVz9Buyru32G6A=; b=a1rDczjgGojSYR9qAm7fE3l0e876XrWfutOxJUyPndaeR1H7F/Vw0lRl 5Y1vl0yEQ0TaTvwfmpMJhOk93+ONSbyr8ldqSLqTDkV4GjAG1K7qxoDPx 92eBVuuqp54Eqm+/fyvNn3JQxtRqjYINtRzLtsaPEZhO5tb3A1vLxCZb/ I=; X-IPAS-Result: =?us-ascii?q?A0AdAAAlgGBh/4cNJK1XAxsBAQEBAQEBAQUBAQESAQEBA?= =?us-ascii?q?wMBAQGCBQYBAQELAYEgMCMuB3daEyQxhEeDRwOEWWCICQOKdI94gS4UgREDT?= =?us-ascii?q?wULAQEBDQEBKgEMCgQBAYQ5RQIXgjECJTQJDgECBAEBAQEDAgMBAQEBBQEBB?= =?us-ascii?q?QEBAQIBBgSBEROFOwglDYZCAQEBAQMBARALEBMBASwLAQ8CAQYCBwcDAwECI?= =?us-ascii?q?QECBAUCAh8GCxQGAwgCBAENBQgTB4JQgX5XAy8BDpFxjzUBgToCih9zCYEvg?= =?us-ascii?q?QGCCAEBBgQEgTYBAwIOQYJ/DQuCNQmBIxcBgwCEE4Z1JxyBSUSBFAFDgmc+g?= =?us-ascii?q?iFCAQECAYEjBQESASMVCQEFBwkICYJNGyCCDCKKYy9CZAQbNgEBBRsCOSAWN?= =?us-ascii?q?CYoHwsRAg4JEJEvD4xMjUyRQ2cKgzCBM4kTjjyCU4MyFINqi2yXQIcTjRKCA?= =?us-ascii?q?IIfii6DP5BDG4RbAgQCBAUCDgEBBjWBLDtpcHAVO4JpCUgZD4M+imIMBREVG?= =?us-ascii?q?YMihRRghGp0AjYCBgEKAQEDCZItLYIXAQE?= IronPort-PHdr: A9a23:bgZZTxY/IlchU9PbU02CpvP/LTAzhN3EVzX9orIojrtPduKo+JGxd EDc5PA4iljPUM2b7v9fkOPZvujmXnBI+peOtn0OMfkuHx8IgMkbhUosVciCD0CoI/vjbih8F 8NHBxdp+nihOh1TH8DzL1TZvny162sUHRPyfQp4L+j4AMjclcOyguuz4JbUJQ5PgWnVXA== IronPort-Data: A9a23:/6DvhaP4E10rdK3vrR39lsFynXyQoLVcMsEvi/4bfWQNrUom1TQCn WsXXWGPOaqDY2KnetF/OYqz8hlUusDTxt81TnM5pCpnJ55oRWUpJjg4wmPYZX76whjrFRo/h ykmh1qpwPkcFhcwnD/1WlTahSQ6hfzgqobUUraeY3kpHV88Ek/NtDo68wIHqt8w6TSGK1vlV ePa+6Uz73f8hlaYmkpNg06ygEsHUMba4Vv0jXRiDRx/h2IyolFOZH4pyQ5dGFOjKmVcNrbSq +8uV9hV9EuBl/smIovNfroW7iTmT5aKVTVihEa6VICQhykFuhYR8J0gLaAcYG1rkmSZrtZIn YAlWZyYEW/FP4XFnOAbFhJfCSw7Z+tN+aTMJj60tsn7I0/uKiS3ha4wShhte9RDp46bAkkWn RAcAD4GahmPr+m327m8DOJrg6zPKeG7ZNxO5Sg/lmyx4fAOZ56YbuLF9NZh3CoRo+xtIcbBJ PRIdm86BPjHS1gVUrsNM7olhP2pgHa6eD1RqUiOjas6/2aVyxZ+uJD2KMDUfNOiRMhJkACfv G2u12bwBxwBctrZxieE+XKlnOPnkz7nRZgfC7C5sPVthTW7wm0OGRwNUl20ifK5i0i3XtVVK kgZvCEpqMAa9EW6R9PgRBS3u3ussRsVWt4WGOo/gDxh0YLd5wKfQ2MDVDMEMpottdQ9Qnoh0 Vrhc87VOAGDeYa9ERq1nop4ZxvrUcTJBQfuvRM5cDY= IronPort-HdrOrdr: A9a23:qPXdmaEmZd7Hl7BNpLqFSpHXdLJyesId70hD6qkvc31om52j+f xGws516fatskdvZJkh8erwX5VoMkmsi6KdgLNhfItKOTOHhILGFvAY0WKP+UyEJ8S6zJ8g6U 4CSdk/NDSTNykBsS+S2mDReLxMrKjlgcKVbKXlvgpQpGpRGsddBnJCe36m+zpNNXB77PQCZf 6hz/sCgwDlVWUcb8y9CHVAdfPEvcf3mJXvZgNDLwI76SGV5AnYq4LSIly95FMzQjlPybAt/S zuiAri/JiutPm911v1y3LT1ZJLg9Hso+EzRvBky/JlbwkEuDzYI7iJaIfy+gzdZ9vfsWrCpe O85yvI+f4Ds085MFvF+icFkDOQoQrGo0WSuWNwx0GT+/AQgFkBepZ8bUUzSGqF16NohqAO7I tbm22erJZZFhXGgWD04MXJTQhjkg6urWMlivN7tQ0TbWIyUs4bkWUkxjIeLH7AJlOM1Kk3VO 11SM3M7vdfdl2XK3jfo2l02dSpGnA+BA2PTEQOstGcl2E+pgE382IIgMgE2nsQ/pM0TJdJo+ zCL6RzjblLCssbd7h0CusNSda+TmbNXRXPOmSPJkmPLtBKB1vd75rspLkl7uCjf5IFiJM0hZ TaSVtd8XU/fkr/YPf+lKGjMiq9CVlVeA6dhP22y6IJz4EUdYCbRxFrEmpe4fdIi89vdvHmZw == X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.85,358,1624320000"; d="scan'208,217";a="807971735" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Oct 2021 17:34:50 +0000 Received: from mail.cisco.com (xbe-aln-001.cisco.com [173.36.7.16]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 198HYoAU019415 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 8 Oct 2021 17:34:50 GMT Received: from xfe-aln-002.cisco.com (173.37.135.122) 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.792.15; Fri, 8 Oct 2021 12:34:50 -0500 Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 8 Oct 2021 12:34:49 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Fri, 8 Oct 2021 13:34:49 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IXSyhOCn4E3/KSieA0Lflvb2+IpAAQZdMM6Mbv3BB0ocvJ8CpCJ84Uu2zi54cZqBAJVbH7D/unbdPtzlIcGU1WWcPSUhp9/qRjAqUEVTKYCDzX6toqr5JAS6nq8IG70+RMfkgczNP3rE8tEV28yOwjMby5+wrwRDEQL1N2P9w7Va6mZsc2ooMp7aVWVCa/PcHaZMga+V2fiKeKSmjMi6l+gXaSbPvnQ1lp5HEgWEfcVn6OClblveZmiWMzxdCfjKuSeTpaHt1J0Zp7W6v5wHzfMT+bA8ffOv/LYRVbDnsCkCplfZtfMSlanTbiGAipbCQVLHjs3h1sP2PsbPZpPJJQ== 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=2BYVQiHgPQqc6z35c4Lcuwkcu2Se0z//cM3vHj8Bi6M=; b=l9le+MNY7EX2xmQf+YWj07A7wJFuseTSlHjBiEOieY9dZxd5sxVP9pLm68MU3ryiFSZApZDRyZi+HKNYuIQvQAB4ybmyyPWSnYxVqqiOqFa0VIcj/bHsMgt2I4cYNjUlaxHJvXSKrfVYiQ5q139w8u4Cqakf7shSUYerDnnctXUl4gxdmHFrOrq78ERfGNCuWjOkJccTwC1vTjQ5UvdI5TZy4fXNPaXohuOivzTH1lGE6dxJiT39UKj1e2MLmCgjdNx1Z7/M2c/unyqFtV4r+b/qn57UCP2vzVexx2Mq/EfF6T74ck6F6uuGiMU/BCiyu4xUVoUAqnf4ThYzBIgFCQ== 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=2BYVQiHgPQqc6z35c4Lcuwkcu2Se0z//cM3vHj8Bi6M=; b=XYIDXE9ChqyI3d8ApKclPINmRDtBUIGEm/+PD8rZ9X0DwZ+GS7Zh/CIJjQg7tVBi5ALfoNVnDL3YyeH1Rztpc4M+Ut0DrcebOHaW29qVuvoEBlGhxAYRLBNtgVkJHQRhVsQU8NRZtUxVALT7jcj0oS9eidnVkCpKTciPbWlXpV0= Received: from CO6PR11MB5650.namprd11.prod.outlook.com (2603:10b6:5:35a::9) by CO6PR11MB5650.namprd11.prod.outlook.com (2603:10b6:5:35a::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.19; Fri, 8 Oct 2021 17:34:48 +0000 Received: from CO6PR11MB5650.namprd11.prod.outlook.com ([fe80::6071:7cb6:d30e:b0d]) by CO6PR11MB5650.namprd11.prod.outlook.com ([fe80::6071:7cb6:d30e:b0d%4]) with mapi id 15.20.4587.022; Fri, 8 Oct 2021 17:34:48 +0000 From: "Francois Clad (fclad)" To: Gyan Mishra , Yisong Liu CC: James Guichard , SPRING WG , spring-chairs Thread-Topic: =?gb2312?B?W3NwcmluZ10gIFJFo7ogV0cgQWRvcHRpb24gY2FsbCBmb3IgaHR0cHM6Ly9k?= =?gb2312?B?YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1z?= =?gb2312?Q?pring-srv6-srh-compression/?= Thread-Index: AQHXuIkZ+9WEfJ+8e0+RaxE9rPcNb6vJYihF Date: Fri, 8 Oct 2021 17:34:48 +0000 Message-ID: References: <202110021255323466813813@chinamobile.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1c6ecc46-09f5-418a-0328-08d98a81ed30 x-ms-traffictypediagnostic: CO6PR11MB5650: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: w+XNQMBcMez5EjT9DcHjZPEoyRR+v8nNpMPsgsCGTwyV/NdtcWiLTrzFWJMt2T3tvEEbPegy3VnmNhxPChEIlVRhJYqnehWKEG63L8IqCHiiHIZM0rhPXkPl4doTPX3NP21dEULjd2atmOHQkhSU4SHa3fk0FTiNdZ9ipWQWyt0exPPO1SZN4TnGRLHJX2kyynOlTkUFLWDj09FUjen1WID1gToG5pCnkiqEws4JEHfQvkNB6dnZqp74sPeeHLC/156M3rRMwIB6jYN6FHCR89H5VcVMMuab+LCUB3Fjt/HLh8ASrU4WxrJ50chxlm6m+KkTBkVqFQtRD93luplZDcTylaoBW1fjZSaTDZQH9VZIjrVeKCTj0GNanLLFaf9kaKWHvGIgt9qE49yERXRBDqBIw84Axgm7J76cJGNYyBwsSUI5VGSYkZFFdxau6PfYD7hF/3dR5aNYH0Z8OJm2FUK0izywp1FOzhkolOhQOFsCxEpYnne4CuLTIQwZ+zqWl7C7w4GNqBHweE/DTli/i/utQdTDnKzI2gvCv/cYhpcFiclRtZISFefB+1ut2PuU40p5VTQn4Cq9Enfmi3qKLtC9ZrZSfn7VNWgzEOfsa7hi8cNYErX3HoHR7t2BIq83JsbaKkEdLsUAK6C1G2ymSUjJOVZK8vMJ6Rh+ztNGaeGcjrgCO9QbVYaOROIFRcHyFFUAhLqUNgOGt26FXyFNoX1ivkqNrHAmQ+AC7++r+GSypM0jedlfpAYxqzGbojQjYvWghFqoVoqrwi51bQvqv6A5tFXhOVZT0R44gHQ3cpunc7bH01quVuShEWCCQG4geAWXv3Nw26jLiV83oEAcUA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR11MB5650.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(966005)(26005)(6506007)(186003)(8936002)(53546011)(52536014)(508600001)(122000001)(110136005)(66946007)(91956017)(76116006)(7696005)(4326008)(64756008)(66556008)(66476007)(38070700005)(66446008)(86362001)(2906002)(316002)(166002)(71200400001)(54906003)(38100700002)(5660300002)(83380400001)(33656002)(55016002)(9686003)(40140700001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?gb2312?B?SWNNdlo5dm0ySXZ3eU83ZnZpQk9ZWUtsVFBFLzgwVUw3aXR3SFRiclhXdnpS?= =?gb2312?B?QXhhMXlzKzZUUTJNYmptQVRVL0dzSTBibFNlUG1MaWVNRnhzL1NxakYyQlc4?= =?gb2312?B?bk52ckV1eEhvTFhKZjZhZnpQckV1OXp2RnBwNHNrRUNhQ1JGSFZ1VjY1dCta?= =?gb2312?B?TGpkL3dQelhRZEI4clpyMXZhYlhCR3JwTW94VHVBYmNlZU02SzVXV004Z1Fq?= =?gb2312?B?azNZUytVcUlBTGpoejZKY3p1Z0x1MTl3VmkxNklselhQUDYzM3d6ck5RTDA1?= =?gb2312?B?TTRhRk4xdGhTRy91SVhKaU43eU84YStZZ0R0YlM4M1ZiL0R0OHo4S2kzRWtH?= =?gb2312?B?ZGtrWkdQcDVEREQ3K0JzcnVIVE91d29VL01tWVlINUx0R1BzeE5aQ291SzZT?= =?gb2312?B?bmMvNS9RR1A4ZEhtdURiVmdlVWNEM3M4bkhmbytOK2hMa3lNdGNyejR3bG5W?= =?gb2312?B?L282MjJYSWljYkhoT1FUWStucWNDR2NMdy90NmZ1dE54dEZOTHpJOFJCbXNa?= =?gb2312?B?aExGVDZ2WElTTVBLbEhJMi9iTjdGME8wM1RIbUMzMnh4Y2lkeFZQTzdpdHNU?= =?gb2312?B?eU9nL2tnNWxhU0NCWXdnY0YxYm55ZVV6emplZDhSYmNWZkdwNCtjQ1Y0aVRy?= =?gb2312?B?VUtWeHpnZWdkbjVLM2ptTkM2M2xFY3dXV2w5Q0VZelY4VGJNRm40eEltSVhI?= =?gb2312?B?eDh4TXBTcFJ5S3BJOW94ZUM2VVRXaEdPazZadUIxcW5NOFlRdEEzc1had29u?= =?gb2312?B?QTc3Vng5cld2QXNJbG4zZUpKSFpySFZUUjVhN0ZZRkdKcHBSa2pHMkdHWkpX?= =?gb2312?B?NVI1Ykk1cDVQemJjRURaUjlSVjJ1dmF0ZU1OYnAwOVc3andWc2MrOWtlcHhV?= =?gb2312?B?YlVHQld4a3JkdWN4SnFHYjNqSk5xMS8rVTZHN0hhTUdtQXhtOG5MN3JuTWl3?= =?gb2312?B?THBlNy9VOHRpRTNZTUJ0bHJhTWRtdjNyeExMdFZaSXdVdjRoZ2VyTjR1ZjJq?= =?gb2312?B?QnBicjVzeTNjNnJueE5LVG5rTDFxanNNeU8vdlBSeU1WSm84NXduQlZScmIy?= =?gb2312?B?QmtWa0RrUUNIVHNMdFdkV2w0YlRydmxJcjBwNDVPL0ttSGs2b2JndFBrNWp0?= =?gb2312?B?MHZOdnZYaUFObEMzMGtmeVcwenovbXRneUplekQ1eUs1cXIwc3BqM2VjMWFE?= =?gb2312?B?c0hrRGNJdXR6OHJFRnhDQmxvaEtNbG9OaER0ME9MUmQ2TWFCdHN0cm5UVXhJ?= =?gb2312?B?aEp5UjRQdEpYT05kSndJYTZHMXVOajNMSUZqL0FFenNUSTNHWWJMY2pqWCtk?= =?gb2312?B?L2loS2pxcWxRK2kyV3AxSTRYbFhVUDAvaklRNVpYNU5zY2lseXAzZml1Yk5i?= =?gb2312?B?NEIvaU9yd2NGNEd2SVMzZmovdmo0ck1IT05PQmVxOTZYS1ZVRFNwbTROdGNH?= =?gb2312?B?WVlFa0l6bkZabjVhTG9McjV4NGRzb1M3VFpacFNib1pNRVZvRy9DWVRjZFNo?= =?gb2312?B?WkJUanptWUxzS1psSlA0eVQ1VXJRcmFYa0tvUWxvMWFLTzgyeG16OVEzcTVL?= =?gb2312?B?R2QwRktrQjNSNnNNQVhLcnJSTTlCc3ZtSC9mamlRUVpudGdaYlVyZ0RrZFBV?= =?gb2312?B?RCtlZTlZVDJ5MDhmRkE4Z1lEWFYzTXlHQjFFZzhLSHFqOXJ5dEhKTk5HTUdl?= =?gb2312?B?NklDemR4cVJ1MHgyU1pTSVlUUmI3TEZMTzVDQUhZMzZTSDJLQXIrdUFrSVRE?= =?gb2312?B?NFVNN3dzaUs1Wm10OGVCd3UzZmhmbzVLb0hUR2R0cUhNazVDd1U2eHNYT09a?= =?gb2312?B?TURVakU2bDhVOVoxdGpZZz09?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO6PR11MB5650D7B5E26BF457D0FE4F54ACB29CO6PR11MB5650namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO6PR11MB5650.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1c6ecc46-09f5-418a-0328-08d98a81ed30 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2021 17:34:48.3241 (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: Mb+GabrdYNYLb2BonNc8i0CVxeW3I8LljHAXKxh0kt+Ue+1PQYEAs4G1wYNG4Gf8 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR11MB5650 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xbe-aln-001.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: Re: [spring] =?gb2312?b?UkWjuiBXRyBBZG9wdGlvbiBjYWxsIGZvciBodHRwczov?= =?gb2312?b?L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5n?= =?gb2312?b?LXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8=?= 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, 08 Oct 2021 17:34:59 -0000 --_000_CO6PR11MB5650D7B5E26BF457D0FE4F54ACB29CO6PR11MB5650namp_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgR3lhbiwNCg0KSXQgaXMgcG9zc2libGUgdG8gY29tYmluZSBTSURzIG9mIGRpZmZlcmVudCBD LVNJRCBmbGF2b3JzIGFuZCBDLVNJRCBsZW5ndGhzIGluIHRoZSBzYW1lIFNSSCwgYWxvbmcgd2l0 aCB0aG9zZSBkZWZpbmVkIGluIFJGQyA4OTg2IEFmdGVyIGFsbCwgdGhleSBsZXZlcmFnZSB0aGUg c2FtZSBTUnY2IGRhdGEgcGxhbmUuDQoNCkxldCBtZSBnaXZlIHlvdSBhbiBleGFtcGxlLg0KDQpB c3N1bWUgdGhhdCBhbiBTUiBzb3VyY2Ugbm9kZSB3YW50cyB0byBzZW5kIGEgcGFja2V0IG9udG8g YW4gU1IgcGF0aCB0aHJvdWdoIDEwIFNSIHNlZ21lbnQgZW5kcG9pbnQgbm9kZXMgKG5vZGVzIDEg dGhyb3VnaCAxMCksIGFuZCBoYXZlIGEgVlBOIHRlcm1pbmF0aW9uIGZvciBhIFZSRiAxMjMgb24g YSBsYXN0IFNSIHNlZ21lbnQgZW5kcG9pbnQgbm9kZSAxMS4NCg0KVGhlIFNSIHNvdXJjZSBub2Rl IHNlbGVjdHMgdGhlIHNlZ21lbnRzIGFzIGZvbGxvd3M6DQoNCiAgKiAgIE9uIG5vZGVzIDEgdGhy b3VnaCA1LCB0aGUgU0lEIDIwMDE6ZGI4OjA6MEswMTo6ICh3aXRoIEsgYmVpbmcgdGhlIG5vZGUg SUQpIGJvdW5kIHRvIEVuZCB3aXRoIE5FWFQtQy1TSUQgZmxhdm9yIGFuZCAxNi1iaXQgQy1TSUQg bGVuZ3RoLg0KICAqICAgT24gbm9kZXMgNiB0aHJvdWdoIDksIHRoZSBTSUQgMjAwMTpkYjg6MDow SzAwOjAwMDE6OiAod2l0aCBLIGJlaW5nIHRoZSBub2RlIElEKSBib3VuZCB0byBFbmQgd2l0aCBS RVBMQUNFLUMtU0lEIGZsYXZvciBhbmQgMzItYml0IEMtU0lEIGxlbmd0aC4NCiAgKiAgIE9uIG5v ZGUgMTAsIHRoZSBTSUQgMjAwMTpkYjg6MDoxMDAwOjAwMDE6OiBib3VuZCB0byBFbmQgKFJGQyA4 OTg2KS4NCiAgKiAgIE9uIG5vZGUgMTEsIGEgU0lEIDIwMDE6ZGI4OjA6MTEwMDpkMTIzOjogYm91 bmQgdG8gRW5kLkRUNCAoUkZDIDg5ODYpIGZvciBWUkYgMTIzLg0KDQpUaGUgU1Igc291cmNlIG5v ZGUgdGhlbiBzZW5kcyB0aGUgcGFja2V0IG9udG8gdGhlIFNSIHBhdGggYnkgcGVyZm9ybWluZyB0 aGUgSC5FbmNhcHMuUmVkIGJlaGF2aW9yIHdpdGg6DQoNCiAgKiAgIElQdjYgU291cmNlIEFkZHJl c3MgPSA8YW4gYWRkcmVzcyBvZiB0aGUgU1Igc291cmNlIG5vZGU+DQogICogICBJUHY2IERlc3Rp bmF0aW9uIEFkZHJlc3MgPSAyMDAxOmRiODowOjAxMDE6MDIwMTowMzAxOjA0MDE6MDUwMQ0KICAq ICAgU1JIID0NCiAgICAgKiAgIFNlZ21lbnRMaXN0WzBdID0gMjAwMTpkYjg6MDoxMTAwOmQxMjM6 Og0KICAgICAqICAgU2VnbWVudExpc3RbMV0gPSAxMDAwOjAwMDE6MDkwMDowMDAxOjA4MDA6MDAw MTowNzAwOjAwMDENCiAgICAgKiAgIFNlZ21lbnRMaXN0WzJdID0gMjAwMTpkYjg6MDowNjAwOjAw MDE6Og0KDQpUaGVyZWZvcmUsIHRoZXJlIGlzIG5vIG5vdGlvbiBvZiBsb3dlc3QgY29tbW9uIGRl bm9taW5hdG9yIGZvciBDLVNJRCBsZW5ndGguIEJhc2VkIG9uIHRoZSBkZXBsb3ltZW50IHJlcXVp cmVtZW50cywgYW4gb3BlcmF0b3IgaGFzIHRoZSBmbGV4aWJpbGl0eSB0byBzZWxlY3QgdGhlIFNS djYgU0lEIGZsYXZvciBhbmQgQy1TSUQgbGVuZ3RocyBvZiB0aGVpciBjaG9pY2UuDQoNCldlIGNh biB1cGRhdGUgdGhlIGRyYWZ0IHdpdGggdGhpcyB0eXBlIG9mIGlsbHVzdHJhdGlvbnMuDQoNClRo YW5rcywNCkZyYW5jb2lzDQoNCkZyb206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+ IG9uIGJlaGFsZiBvZiBHeWFuIE1pc2hyYSA8aGF5YWJ1c2Fnc21AZ21haWwuY29tPg0KRGF0ZTog U3VuZGF5LCAzIE9jdG9iZXIgMjAyMSBhdCAyMTowMQ0KVG86IFlpc29uZyBMaXUgPGxpdXlpc29u Z0BjaGluYW1vYmlsZS5jb20+DQpDYzogSmFtZXMgR3VpY2hhcmQgPGphbWVzLm4uZ3VpY2hhcmRA ZnV0dXJld2VpLmNvbT4sIFNQUklORyBXRyA8c3ByaW5nQGlldGYub3JnPiwgc3ByaW5nLWNoYWly cyA8c3ByaW5nLWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBSRaO6IFdH IEFkb3B0aW9uIGNhbGwgZm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLw0KDQpIaSBZaXNvbmcN Cg0KVGhlIG1haW4gZ29hbCBmb3Igb3BlcmF0b3JzIGlzIGludGVyb3BlcmFiaWxpdHkuICBBcyBp bnRlcm9wZXJhYmlsaXR5IGlzIHRoZSBrZXkgcmVhc29uIGZvciBhIHNpbmdsZSBTUnY2IGNvbXBy ZXNzaW9uIHNvbHV0aW9uIHRoYXQgd2UgaGF2ZSBXRyBjb25zZW5zdXMgYW5kIGlzIGRlc2lyZWQu DQoNCkNvbnRpbnVlZCBkZXRhaWxzIG9mIHRoZSBpbnRlcm9wZXJhYmlsaXR5IHN0dWR5ICBzaG91 bGQgYmUgYWRkZWQgdG8gdGhlIGRyYWZ0IGFzIHRoZSBzdHVkeSBwcm9ncmVzc2VzLg0KDQpPbmUg a2V5IGRldGFpbCB0aGF0IGlzIG1pc3NpbmcgaXMgZm9yd2FyZGluZyBlZmZpY2llbmN5IGFuZCBz Y2FsYWJpbGl0eSB1c2luZyBORVhULUMtU0lEIGFuZCBSRVBMQUNFLUMtU0lEIGludGVyb3BlcmFi aWxpdHkgdXNpbmcgMTYgYml0IFNJRC4NCg0KQXMgTkVYVC1DU0lEIHVTSUQgQ29udGFpbmVyIE1p Y3JvIFNlZ21lbnQgc2hpZnQgZmxhdm9yIHVzaW5nIEdJQi9MSUIgZm9yIHVsdHJhIHNjYWxlICBT UnY2IGNvbXByZXNzaW9uIHNvbHV0aW9uIGlzIHJlY29tbWVuZGVkIGZvciAxNiBiaXQgU0lEIGFu ZCBSRVBMQUNFLUMtU0lEIEctU0lEIEctU0lEIENvbnRhaW5lciBiYXNlZCBzb2x1dGlvbiBpcyBy ZWNvbW1lbmRlZCBmb3IgMzIgYml0IFNJRC4NCg0KT2YgYWxsIHRoZSByZXF1aXJlbWVudHMgYXMg c3RhdGVkLCB0aGUgZW5jYXBzdWxhdGlvbiBoZWFkZXIgc2l6ZSBpcyB0aGUgcHJpbWFyeSBvYmpl Y3RpdmUgZm9yIG9wZXJhdG9ycyB0byBlbGltaW5hdGUgTVNEIGlzc3VlcyB3aXRoIG9wdGltYWwg Zm9yd2FyZGluZyBhbmQgc3RhdGUgZWZmaWNpZW5jaWVzLg0KDQpBdCB0aGlzIHRpbWUgaW4gb3Jk ZXIgZm9yIE5leHQgYW5kIFJlcGxhY2Ugc29sdXRpb25zIHRvIGJlIGludGVyb3BlcmFibGUga2Vl cGluZyBpbiBtaW5kIHJlcXVpcmVtZW50cyBmb3Igb3B0aW1hbCBmb3J3YXJkaW5nIGFuZCBzdGF0 ZSBlZmZpY2llbmN5IDMyIGJpdCBTSUQgd291bGQgYmUgdGhlIGxvd2VzdCBjb21tb24gZGVub21p bmF0b3Igd2hpY2ggc2hvdWxkIGJlIHN0YXRlZCBhcyB0aGUgYmFzZWxpbmUgcmVzdWx0IG9mIHRo ZSBhbmFseXNpcyBkcmFmdCBvbiBDU0lEIG92ZXJhbGwgMiBwcm9uZyBzb2x1dGlvbi4NCg0KQ1NJ RCBkcmFmdDoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtZmls c2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24tMDIjc2VjdGlvbi0xMQ0KDQpC b3R0b20gb2Ygc2VjdGlvbiAxMToNCg0KDQogICBUaGUgaW50ZXJvcGVyYWJpbGl0eSB3YXMgdmFs aWRhdGVkIGZvciB0aGUgZm9sbG93aW5nIHNjZW5hcmlvOg0KDQoNCg0KICAgbyAgUGFja2V0IGZv cndhcmRpbmcgdGhyb3VnaCBhIHRyYWZmaWMgZW5naW5lZXJpbmcgc2VnbWVudCBsaXN0DQoNCiAg ICAgIGNvbWJpbmluZywgaW4gdGhlIHNhbWUgU1JIIChbUkZDODc1NDxodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL3JmYzg3NTQ+XSksIFNSdjYgU0lEcyBib3VuZCB0byBhbg0K DQogICAgICBlbmRwb2ludCBiZWhhdmlvciB3aXRoIHRoZSBORVhULUMtU0lEIGZsYXZvciBhbmQg U1J2NiBTSURzIGJvdW5kDQoNCiAgICAgIHRvIGFuIGVuZHBvaW50IGJlaGF2aW9yIHdpdGggdGhl IFJFUExBQ0UtQy1TSUQgZmxhdm9yLg0KDQoNCg0KICAgRnVydGhlciBpbnRlcm9wZXJhYmlsaXR5 IHRlc3RpbmcgaXMgb25nb2luZyBhbmQgd2lsbCBiZSByZXBvcnRlZCBpbg0KDQogICB0aGlzIGRv Y3VtZW50IGFzIHRoZSB3b3JrIHByb2dyZXNzZXMuDQoNCktpbmcgUmVnYXJkcw0KDQpHeWFuDQpP biBTYXQsIE9jdCAyLCAyMDIxIGF0IDEyOjU2IEFNIFlpc29uZyBMaXUgPGxpdXlpc29uZ0BjaGlu YW1vYmlsZS5jb208bWFpbHRvOmxpdXlpc29uZ0BjaGluYW1vYmlsZS5jb20+PiB3cm90ZToNCkhp IENoYWlycyAmIFdHLA0KDQpJIHN0cm9uZ2x5IHN1cHBvcnQgdGhlIGFkb3B0aW9uIGNhbGwuIFJl Z2FyZGluZyBjaGFpcidzIG5vdGUgaW4gdGhlIGVtYWlsLCBJIHdvdWxkIGxpa2UgdG8gcG9pbnQg dGhhdCB0aGUgbmV0d29yayBwcm9ncmFtbWluZyBtb2RlbCAoUkZDODk5NikgYnkgbmF0dXJlIGRl ZmluZXMgbXVsdGlwbGUgYmVoYXZpb3JzLiBDU0lEIGhhcyBhIHNpbmdsZSBTUnY2IGJhc2VkIGRh dGEgcGxhbmUgdGhhdCBkZWZpbmVzIHRoZSBuZXh0IGFuZCByZXBsYWNlIGJlaGF2aW9ycyBjb25z aXN0ZW50IHdpdGggdGhlIG5ldHdvcmsgcHJvZ3JhbW1pbmcgcGFyYWRpZ20uDQoNCkNTSUQncyBu ZXh0IGFuZCByZXBsYWNlIGJlaGF2aW9ycyBoYXZlIGJlZW4gdmVyaWZpZWQgYnkgaW50ZXJvcGVy YWJpbGl0eSB0ZXN0IGluIENoaW5hIG1vYmlsZSBsYWJvcmF0b3J5IGFuZCB0aGVyZSBpcyBubyBw cm9ibGVtIHdpdGggdGhlIGludGVyd29ya2luZyBvZiB0aGUgdHdvIGJlaGF2aW9ycyBvbiB0aGUg Q1NJRCBkYXRhcGxhbmUuDQoNCkJlc3QgUmVnYXJkcw0KWWlzb25nDQoNCreivP7IyzogSmFtZXMg R3VpY2hhcmQ8bWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbT4NCsqxvOQ6IDIw MjEvMTAvMDEo0MfG2s7lKTIyOjA0DQrK1bz+yMs6IFNQUklORyBXRzxtYWlsdG86c3ByaW5nQGll dGYub3JnPjsNCrOty83Iyzogc3ByaW5nLWNoYWlyczxtYWlsdG86c3ByaW5nLWNoYWlyc0BpZXRm Lm9yZz47DQrW98ziOiBbc3ByaW5nXSBXRyBBZG9wdGlvbiBjYWxsIGZvciBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1j b21wcmVzc2lvbi8NCkRlYXIgV0c6DQoNClRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBleHByZXNz IHRoZWlyIGFwcHJlY2lhdGlvbiBmb3IgYWxsIHRoZSByZXNwb25zZXMgcmVjZWl2ZWQgdG8gb3Vy IGVtYWlscyB3aXRoIHJlZmVyZW5jZSB0byBob3cgdGhlIHdvcmtpbmcgZ3JvdXAgd2lzaGVzIHRv IG1vdmUgZm9yd2FyZCB3aXRoIHJlc3BlY3QgdG8gYSBzb2x1dGlvbiBmb3IgU1J2NiBjb21wcmVz c2lvbi4NCg0KVGhlIGFwcGFyZW50IGluY2xpbmF0aW9uIG9mIHRoZSB3b3JraW5nIGdyb3VwIGlz IHRvIHVzZSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2No ZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8gYXMgdGhlIGJhc2lzIGZvciBpdHMgY29t cHJlc3Npb24gc3RhbmRhcmRpemF0aW9uIHdvcmsuIFRoYXQgaXMgcGFydCBvZiB3aGF0IHRoaXMg ZW1haWwgYXR0ZW1wdHMgdG8gY29uZmlybS4NCg0KQmVjYXVzZSBvZiB0aGUgYWJvdmUgdGhlIGNo YWlycyB3b3VsZCBsaWtlIHRvIGlzc3VlIGEgMi13ZWVrIFdHIGNhbGwgZm9yIGFkb3B0aW9uIGVu ZGluZyBPY3RvYmVyIDE1dGggZm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyBidXQgd2l0aCBz b21lIGNsZWFyIGd1aWRlbGluZXMgYXMgZm9sbG93cy4gQnkgZXhwcmVzc2luZyBzdXBwb3J0IGZv ciBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IHlvdSBhcmUgZnVsbHkgYXdhcmUgb2YgYW5kIGFy ZSBhY2tub3dsZWRnaW5nIHRoYXQ6DQoNCg0KICAxLiAgVGhlIFNQUklORyB3b3JraW5nIGdyb3Vw IGlzIGFkb3B0aW5nIGEgZG9jdW1lbnQgdGhhdCBoYXMgbXVsdGlwbGUgU1J2NiBFbmRwb2ludCBi ZWhhdmlvcnMuDQogIDIuICBUaGUgZG9jdW1lbnQgaXMgYSChsGxpdmluZ6GxIGRvY3VtZW50OyBp dCBtYXkgY2hhbmdlIGFzIGl0IGdvZXMgdGhyb3VnaCByZXZpZXcgYW5kIGFuYWx5c2lzIGJ5IHRo ZSBTUFJJTkcgd29ya2luZyBncm91cC4NCiAgMy4gIEFsbCBvcGVuIGRpc2N1c3Npb24gcG9pbnRz IHJhaXNlZCBvbiBvdXIgbWFpbGluZyBsaXN0IE1VU1QgYmUgYWRkcmVzc2VkIEJFRk9SRSBzYWlk IGRvY3VtZW50IGlzIGFsbG93ZWQgdG8gcHJvZ3Jlc3MgZnJvbSB0aGUgd29ya2luZyBncm91cCB0 byBwdWJsaWNhdGlvbi4gQSBsaXN0IG9mIHRoZXNlIGRpc2N1c3Npb24gcG9pbnRzIHdpbGwgYmUg ZG9jdW1lbnRlZCBpbiB0aGUgV0cgZG9jdW1lbnQgYW5kIG1haW50YWluZWQgYnkgdGhlIGRvY3Vt ZW50IGVkaXRvciBpbiBjb25qdW5jdGlvbiB3aXRoIHRoZSBjaGFpcnMuDQogIDQuICBJZiB0aGlz IGRvY3VtZW50IGlzIGFkb3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAsIHRoZSBjaGFpcnMgc3Bl Y2lmeSBhcyBwYXJ0IG9mIHRoZSBhZG9wdGlvbiBjYWxsIHRoYXQgdGhlIGZvbGxvd2luZyB0ZXh0 IGRlc2NyaWJpbmcgYW4gb3BlbiBpc3N1ZSBiZSBhZGRlZCB0byB0aGUgZG9jdW1lbnQgaW4gdGhl IGFib3ZlLWRlc2NyaWJlZCBvcGVuIGlzc3VlcyBzZWN0aW9uOg0KDQogICAgICogICAiR2l2ZW4g dGhhdCB0aGUgd29ya2luZyBncm91cCBoYXMgc2FpZCB0aGF0IGl0IHdhbnRzIHRvIHN0YW5kYXJk aXplIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uLCBhbmQgZ2l2ZW4gdGhhdCB0aGUgZG9jdW1lbnQg Y29udGFpbnMgbXVsdGlwbGUgU1J2NiBFbmRQb2ludCBiZWhhdmlvcnMgdGhhdCBzb21lIFdHIG1l bWJlcnMgaGF2ZSBzdGF0ZWQgYXJlIG11bHRpcGxlIGRhdGEgcGxhbmUgc29sdXRpb25zLCB0aGUg d29ya2luZyBncm91cCB3aWxsIGFkZHJlc3Mgd2hldGhlciB0aGlzIGlzIHZhbGlkIGFuZCBjb2hl cmVudCB3aXRoIGl0cyBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiBvYmplY3RpdmUuIi4NCg0KUGxl YXNlIGNvbnNpZGVyIHRoZSBhYm92ZSBndWlkZWxpbmVzIGFzIHlvdSBkZWNpZGUgb24gd2hldGhl ciB0byBzdXBwb3J0IG9yIG5vdCB0aGlzIFdHIGFkb3B0aW9uLiBQbGVhc2UgZXhwcmVzcyBjbGVh cmx5IHlvdXIgcmVhc29uaW5nIGZvciBzdXBwb3J0L25vbi1zdXBwb3J0IGFzIHdlbGwgYXMgYW55 IG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgeW91IHdvdWxkIGxpa2UgYWRkcmVzc2VkIHNob3VsZCB0 aGUgZG9jdW1lbnQgYmUgYWRvcHRlZCBpbnRvIHRoZSB3b3JraW5nIGdyb3VwLg0KDQpUaGFua3Mh DQoNCkppbSwgQnJ1bm8gJiBKb2VsDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9yZzxt YWlsdG86c3ByaW5nQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zcHJpbmcNCi0tDQoNCltodHRwOi8vc3M3LnZ6dy5jb20vaXMvaW1hZ2UvVmVyaXpvbldp cmVsZXNzL3Z6LWxvZ28tZW1haWxdPGh0dHA6Ly93d3cudmVyaXpvbi5jb20vPg0KDQpHeWFuIE1p c2hyYQ0KDQpOZXR3b3JrIFNvbHV0aW9ucyBBcmNoaXRlY3QNCg0KRW1haWwgZ3lhbi5zLm1pc2hy YUB2ZXJpem9uLmNvbTxtYWlsdG86Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNvbT4NCg0KTSAzMDEg NTAyLTEzNDcNCg0K --_000_CO6PR11MB5650D7B5E26BF457D0FE4F54ACB29CO6PR11MB5650namp_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

    Hi Gyan,<= o:p>

    &nbs= p;

    It is pos= sible to combine SIDs of different C-SID flavors and C-SID lengths in the s= ame SRH, along with those defined in RFC 8986 After all, they leve= rage the same SRv6 data plane.

    &nbs= p;

    Let me gi= ve you an example.

    &nbs= p;

    Assume that an SR s= ource node wants to send a packet onto an SR path through 10 SR segment end= point nodes (nodes 1 through 10), and have a VPN termination for a VRF 123 on a last SR segment endpoint node 11.

    &nbs= p;

    The SR so= urce node selects the segments as follows:

    • On nodes 1 through 5, the = SID 2001:db8:0:0K01:: (with K being the node ID) bound to End with NEXT-C-S= ID flavor and 16-bit C-SID length.
    • On nodes 6 through 9, the SID 2001:db8:0:0K= 00:0001:: (with K being the node ID) bound to End with REPLACE-C-SID flavor= and 32-bit C-SID length.
    • On node 10, the SID 2001:db8:0:1000:0001:: bound to E= nd (RFC 8986).<= /li>
    • On node 11, a SID 2001= :db8:0:1100:d123:: bound to End.DT4 (RFC 8986) for VRF 123.

    &nbs= p;

    The SR so= urce node then sends the packet onto the SR path by performing the H.Encaps= .Red behavior with:

    • IPv6 Source Address =3D &l= t;an address of the SR source node>
    • IPv6 Destination Address =3D 2001:db8:0:= 0101:0201:0301:0401:0501
    • SRH =3D
      • SegmentList[0] =3D 2001:db= 8:0:1100:d123::
      • SegmentList[1] =3D 1000:0001:0900:0001:0800:0001:0700:0001
      • Segment= List[2] =3D 2001:db8:0:0600:0001::

    &nbs= p;

    Therefore= , there is no notion of lowest common denominator for C-SID length. Based on the deployment requirement= s,<= span style=3D"mso-fareast-language:EN-US"> an operator has the flexibility to select the SRv6 SID flavor and C-SID lengt= hs of their choice.

    &nbs= p;

    We can up= date the draft with this type of illustrations.

    &nbs= p;

    Thanks,

    Francois<= o:p>

    &nbs= p;

    From: spring <spring-b= ounces@ietf.org> on behalf of Gyan Mishra <hayabusagsm@gmail.com><= br> Date: Sunday, 3 October 2021 at 21:01
    To: Yisong Liu <liuyisong@chinamobile.com>
    Cc: James Guichard <james.n.guichard@futurewei.com>, SPRING WG= <spring@ietf.org>, spring-chairs <spring-chairs@ietf.org>
    Subject: Re: [spring] RE    =A3=BA WG Adoption call for https://datat= racker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

     

    Hi Yisong

     

    The main goal for operators is interoperability.&nbs= p; As interoperability is the key reason for a single SRv6 compression solu= tion that we have WG consensus and is desired.  

     

    Continued details of the interoperability study &nbs= p;should be added to the draft as the study progresses.

     

    One key detail that is missing is forwarding efficie= ncy and scalability using NEXT-C-SID and REPLACE-C-SID interoperability usi= ng 16 bit SID.  

     

    As NEXT-CSID uSID Container Micro Segment shift flav= or using GIB/LIB for ultra scale  SRv6 compression solution is recomme= nded for 16 bit SID and REPLACE-C-SID G-SID G-SID Container based solution = is recommended for 32 bit SID.

     

    Of all the requirements as stated, the encapsulation= header size is the primary objective for operators to eliminate MSD issues= with optimal forwarding and state efficiencies. 

     

    At this time in order for Next and Replace solutions= to be interoperable keeping in mind requirements for optimal forwarding an= d state efficiency 32 bit SID would be the lowest common denominator which = should be stated as the baseline result of the analysis draft on CSID overall 2 prong solution.

     

    CSID draft:

    Bottom of section 11:

     

     

    =    The interoperability was validated for the following scenario:= 

    &nbs=
p;
       o  Packet forwardin=
g through a traffic engineering segment list
          combin=
ing, in the same SRH ([RFC8754])=
, SRv6 SIDs bound to an
          endpoi=
nt behavior with the NEXT-C-SID flavor and SRv6 SIDs bound
          to an =
endpoint behavior with the REPLACE-C-SID flavor.
     
       Further interoperability=
 testing is ongoing and will be reported in
       this document as the wor=
k progresses.

     

    King Regards 

     

    Gyan

    On Sat, Oct 2, 2021 at 12:56 AM Yisong Liu <liuyisong@chinamobile.com> w= rote:

    Hi Chairs & = WG,

     

    I strongly support the adoption c= all. Regarding chair's note in the email, I would like to point that the ne= twork programming model (RFC8996) by nature defines multiple behaviors. CSID has a single SRv6 based data plane that defines t= he next and replace behaviors consistent with the network programming parad= igm.

     

    CSID's next and replace behaviors= have been verified by interoperability test in China mobile laboratory and there is no proble= m with the interworking of the two behaviors on the CSID dataplane.<= /span>

     

    Best Regards

    Yisong

     

    =B7=A2=BC=FE= =C8=CB: James G= uichard

    =CA=B1=BC=E4: 2021/10/01(=D0=C7=C6=DA=CE=E5)22:04

    =CA=D5=BC=FE= =C8=CB: SPRING WG;

    =B3=AD=CB=CD= =C8=CB: spring-chairs;

    Dear WG:

     

    The chairs would like to express their apprec= iation for all the responses received to our emails with reference to how t= he working group wishes to move forward with respect to a solution for SRv6 compression.

     

    The apparent inclination of the working group= is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

     

    Because of the above the chairs would like to= issue a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

     

    1. The SPRING working group is adopting a document that h= as multiple SRv6 Endpoint behaviors.
    2. The document is a =A1=B0living=A1=B1 document; it may = change as it goes through review and analysis by the SPRING working group.
    3. All open discussion points raised on our mailing list = MUST be addressed BEFORE said document is allowed to progress from the work= ing group to publication. A list of these discussion points will be documen= ted in the WG document and maintained by the document editor in conjunction with the chairs. <= /li>
    4. If this document is adopted by the working group, the = chairs specify as part of the adoption call that the following text describ= ing an open issue be added to the document in the above-described open issu= es section:
      • "Given that the working group has said that it wa= nts to standardize one data plane solution, and given that the document con= tains multiple SRv6 EndPoint behaviors that some WG members have stated are= multiple data plane solutions, the working group will address whether this is valid and coherent with its one data pl= ane solution objective.".

     

    Please consider the above guidelines as you d= ecide on whether to support or not this WG adoption. Please express clearly= your reasoning for support/non-support as well as any open discussion points you would like addressed should the = document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

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

    --

    =

    Gyan Mishra=

    Network Solutions Architect&nb= sp;

    Email gyan.s.mishr= a@verizon.com

    M 301 = 502-1347

     

    --_000_CO6PR11MB5650D7B5E26BF457D0FE4F54ACB29CO6PR11MB5650namp_-- From nobody Fri Oct 8 11:05:43 2021 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 501A63A0C30; Fri, 8 Oct 2021 11:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=mFDcKyWy; dkim=pass (1024-bit key) header.d=juniper.net header.b=UmH3ez7h 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 6StYeBYWmNbb; Fri, 8 Oct 2021 11:05:36 -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 A2B873A0C35; Fri, 8 Oct 2021 11:05:36 -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 SMTP id 198FoXnD012611; Fri, 8 Oct 2021 11:05:34 -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=PHf9sXMW5kzn+8qphDtj/4jEBoaRd8NJG1PAW1lmcP0=; b=mFDcKyWy5bOMTdDweiZJQM3QJ/c0JN8xMkpENsx9N2HWZUTHqAAm9SBZdJXF2V3btnkX jBvrJ1H6gq9XoJ7oR/OoQGeR1JmBMJ0tA8XmvNSNCG/Cs9UvoqHA4zFNDb2fZW15uFN+ i0XfHp+i4jiwJOycTvPCtp7jS3aKODenP1FTY5pB9Jw7hdkxSS2HCRvTUd+rXuABZgD0 i8tWOmv/dKSqyFpmqo9h41HVjYP7C83YF77jwOMYEcZVI9lWyLD0N+KqP5RzE7YxwoYU ZT2vTnjHg/mwjpxZwQE7RPZdzuuMd2CJxc8lDBcV9Tjml7q4rkfM3/+BJ4BjHpMUO+6n OA== Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2174.outbound.protection.outlook.com [104.47.56.174]) by mx0a-00273201.pphosted.com with ESMTP id 3bjs0107p3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 08 Oct 2021 11:05:33 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ghn8tD8E6Ufxx0X43ADiBAuo/a3+8t1iuuHFB2u5x/XvQH1j1KALX9XEdsz7QcjqDBoL71HwIe36QRkVqVUBz5vHcb+4QUi87lp+VGdZ2n8SYYg3NwqPQCHGip76kylwDma/DoQu7gT62jc8LkB9+CbD9rcemLAR/VKyo6ObvSOOTXaAPuu4gfj80nCXmT1fRtLgaLIfuH5fQ8iNK21GmGBigtpr4Bi1+uv1WCAqz+n7wRZiFBxGHT3h8DXEJ2ibmijIOZPDUujCNIPbJ5cFlba5MoXHAOKH9lbshp+tW+a+sZ893GBEkUPhQI4vnGzMg7NeAV22HtJP/oHLIoD7FQ== 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=PHf9sXMW5kzn+8qphDtj/4jEBoaRd8NJG1PAW1lmcP0=; b=NI/dGG9G0g1wtnvS3Vyk4XQHNKKUVcHUJelSaHcvqfW6MIbQXi+PNSpokNFkMg0L5ONAa4x/xrbwDfm8dDhcVB1U2Xsl8wQvaoRzp/XHe1DsqYMoCnKFVP4V57E7B/hrkLCDcmatszWJAQ4E/BKvB8T/XPu4OasEQ5ncKze8Pn4xspHp/dTG5D7MWT34FumeHWQFMt8ac22zl8PgFf3u5QIufqiYxgZ1WhYFYTR3ljL5QF9YT39B05h6EFxmSDAFkwytE8s/dWXXjnNBfCN9oPwzAqz4nxlNL5vUOpRmex9VRlhpYJ4wFmxvuNb3r9GiqhZMNKjfzVgWkCAEOufodw== 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=PHf9sXMW5kzn+8qphDtj/4jEBoaRd8NJG1PAW1lmcP0=; b=UmH3ez7hxub593QfMR362jYN4rFNyubTnQwm8nYR0JEsWRpqRIZ0mNSRLYSEE+IGl6SkAjQ2ewuRAVnRrZBds7givYG/Hza6Wlc9Q4qHxY82eEXKSwJZXIKQKLLFmOQ0EPIMMtyaXwFesLX/rNNAQ0nvCEeLcjww9+ftJgGK1ys= Received: from SJ0PR05MB8693.namprd05.prod.outlook.com (2603:10b6:a03:393::20) by BYAPR05MB6503.namprd05.prod.outlook.com (2603:10b6:a03:e9::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.13; Fri, 8 Oct 2021 18:05:30 +0000 Received: from SJ0PR05MB8693.namprd05.prod.outlook.com ([fe80::dce8:9c76:251c:7c2d]) by SJ0PR05MB8693.namprd05.prod.outlook.com ([fe80::dce8:9c76:251c:7c2d%7]) with mapi id 15.20.4587.016; Fri, 8 Oct 2021 18:05:30 +0000 From: Parag Kaneriya To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQFouirg Date: Fri, 8 Oct 2021 18:05:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-IN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 251d7472-5837-4f40-47a6-08d98a86370f x-ms-traffictypediagnostic: BYAPR05MB6503: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: n8FBQvvVnAFL2/lMk51FwirgIwrIBz0HQp/FLEWNvkmcF3jfV3iTHzJWe2N+LhQPpoxpOsngJrg6MBCu+PFKFhTdQGbjJB15uXHlp27VMI/36LHGaTvPoDUrms44XGOzvAebhtbhQ50YbrfffBPaTSkjVJ7LzIyk3F2UwQfeb/PCvvMoKwCogVgFkXTP3+1ZQvpbLjWSVXBah/i0h05dgxr9agehWgZ4UEnIJxb8eMk+yS9YMl91NbZovuanuyfRPrdm9PjnSYHpHK8Kyqng5bztcgY/A3oQJJQujSzi9kmig7FTmaR43wbTxm0M+GfUpZ8MTHI3uXIGpFwCSR/AUB/4O04T1fiAaovxEfHF++HbGcEO+5U5UD1bKWa4FYPq0/dlzSAO3HuR6ZKuUKyMRlUuAZXM/mWsYElpWznny1bwfbZazFn2ag0bEqf8rtQnKY+zGdMre5j/w1PljjeL4+KMKjfUd1l4Hi8wur7iwp0/421GQsK9bp0meYkF4NlLM2Tsgmk8GbhPqk25bgXZTYiScEiH4tgh/wqa0zLN2eHGoYuP3Nki0s30ReJ7oZB1Sk9b496oGei1xiPn4PpQy0c7Mp6ypZyeHpmmWXrOa2t6MSrNZj62x4ZiKtz2nXP1IZE+PZvWejZVPaZ7skd2zANxoZbgGhAxs36jmQ6UShJQHGa3kEvqhkElhiOpxzKM8YzZtFMgmFN13ZFzBFFY2r4RqwhWTkzIJvgCfpchojQRZC/SneYlJuR/96XPrQbZekLaotKXconW9V8J6iq9xeweytVOcvw8xKlNo7TDjY0= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR05MB8693.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(52536014)(4326008)(7696005)(8936002)(66446008)(55016002)(64756008)(76116006)(508600001)(966005)(66556008)(6506007)(53546011)(71200400001)(86362001)(9686003)(316002)(110136005)(66946007)(66476007)(5660300002)(38070700005)(38100700002)(26005)(122000001)(83380400001)(33656002)(186003)(166002)(2906002)(8676002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?X436DcSvVarVHMDm1cRimCHIE37hEdZavMgW+JAqM6BI41VQPcY3ijG+Jpyk?= =?us-ascii?Q?qFLYMr+pahEilMXaMKI41r8F7L6TbV7mXl8iRJDiHWZEwEHOBVjI531vwOnd?= =?us-ascii?Q?XcUqKQ2+9Cf94DVhnaaxXKm30rtHsixwcHYheD8uZNu0O9tZ0qIAFFlcgbQb?= =?us-ascii?Q?ginz0RQcqh9RWG1f3PGCuWIO/Pr4+X0ZmdaCg6dwygnBtTeyZvzcaqD4AbBZ?= =?us-ascii?Q?+B0CkRNkTh7Lt8yd4+Wtb9tCBvOnEKlC1qJQuf0yN/ToQqq2prOfxRaWco/V?= =?us-ascii?Q?803I5zAq95+mHV9AdolJyD9nghOogb2QjJUZDbjkoT6zhRfOA3uKigvxhRWU?= =?us-ascii?Q?ic/EsDedYCCN4ElnKd7/1WPHjjErKhcdAIWQEdpF2WQmfQvLfW0rAGjjlMpY?= =?us-ascii?Q?4MlCycQ+RCHTe4TeSzERYVi7DDFtmXMmDdmYJToh16zU3zSFezKptwxMNya/?= =?us-ascii?Q?iFF+lUcauhNmnRVq5J2QRZf771nBOROsBz4fTjVZIrugYAXBX5XjjzxkXvEU?= =?us-ascii?Q?cGpe8nhsU2O0+7UFHbX3Q/YyyrJoYq4aJbYg/+I36xdokF2auW5hQ9zplHAR?= =?us-ascii?Q?oR55Fdzzt4kXl7j6foGZZMIIRIj6dwDvwDf8umQiGWlh2WQyBnGEwEsLkcEQ?= =?us-ascii?Q?eINIteu7sCnt7Xl9uJ1yrDXfiKXztKcAofz4jAfpvy89xF/+2JfBVkSLZU4e?= =?us-ascii?Q?byCSVkVzOf8YGqU7Jyc39Rw1+YMjlzrkV/vnpeBucp+RRk0V0GRmY0Ymqo5D?= =?us-ascii?Q?f/mq4sKQgdrcmsOgSnDJJijIbbfirs6iZxhnfadMsisLkInxjDBNwAL6djc1?= =?us-ascii?Q?JeuLSRCHpb87gxi7Ef5NA1TRKLpkvUClS3qwcqajjtmRHtu2zjwzgeQ9r/mO?= =?us-ascii?Q?4RRtzNA/nURbLA58A4IdXyVaoOhYh5Ho6aIcqsJI393Yj2Tb+WzSKnzXL7h1?= =?us-ascii?Q?22YO/vyOrw9naixXXWSe2+WzHS3DIOigZKyQKulr7O7ZfML3N4CNwBbZXgiy?= =?us-ascii?Q?9+LHCWffwfidh+rwFxRCgJf1bTATwTGfNjXqJcj4G542x0M6G8r+kgt0xkS5?= =?us-ascii?Q?kuv+LuFv4x6LxQypkfVnBzfDOC7GHcDGH8OQvJ1DrfHzyNZtu81i+3wPPqcl?= =?us-ascii?Q?aN0mD84L0KiEPtMfjgFTdEgVKAvJU//hqXwQ3SHwtOXCjWrg7hfEvVSHveDJ?= =?us-ascii?Q?Cjw8Dzq4AJA8Un4H9prl6tQGgXxlRSluywkoUDe+xn+Vc8jeO/nPg5cNq/zn?= =?us-ascii?Q?nr9El+PLcz4+Za1HDnIgou7W16PG9Qp6K0Bv2h9f7KKG2muRfYGx9dPFoFs2?= =?us-ascii?Q?bd6lOyQMn/I6EmhxNUVbfRQX?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SJ0PR05MB86939263E388AB99C368774FDFB29SJ0PR05MB8693namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR05MB8693.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 251d7472-5837-4f40-47a6-08d98a86370f X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2021 18:05:30.2300 (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: NzPg+rPa9BuFI+eJ1eKcYUm/odaL/KJ5D2dvJ5MLTao7DaztigmCZsbevTF7t9mioumXZA3JVgU/T+kdXljlFg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB6503 X-Proofpoint-GUID: ygeFI8TAFgfKUhDtXMLilcZibjo_ynsF X-Proofpoint-ORIG-GUID: ygeFI8TAFgfKUhDtXMLilcZibjo_ynsF X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-10-08_05,2021-10-07_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 lowpriorityscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 impostorscore=0 adultscore=0 clxscore=1011 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110080101 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 08 Oct 2021 18:05:42 -0000 --_000_SJ0PR05MB86939263E388AB99C368774FDFB29SJ0PR05MB8693namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I object the adoption of this document -Parag From: spring On Behalf Of James Guichard Sent: Friday, October 1, 2021 7:35 PM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ [External Email. Be cautious of content] Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardizat= ion work. That is part of what this email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as follows. By expressing support for a= doption of this document you are fully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_SJ0PR05MB86939263E388AB99C368774FDFB29SJ0PR05MB8693namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I object the adoption of this document

     

    -Parag

     

    From: spring <spring-bounces@ietf.org> = On Behalf Of James Guichard
    Sent: Friday, October 1, 2021 7:35 PM
    To: SPRING WG <spring@ietf.org>
    Cc: spring-chairs@ietf.org
    Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

     

    <= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

     

    Dear WG:

     

    The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

     

    The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

     

    Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

     

    1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors.
    2. The document is a “living” document; it m= ay change as it goes through review and analysis by the SPRING working grou= p.
    3. All open discussion points raised on our mailing list= MUST be addressed BEFORE said document is allowed to progress from the wor= king group to publication. A list of these discussion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
    4. If this document is adopted by the working group, the= chairs specify as part of the adoption call that the following text descri= bing an open issue be added to the document in the above-described open issues section:
      • "Given th= at the working group has said that it wants to standardize one data plane s= olution, and given that the document contains multiple SRv6 EndPoint behavi= ors that some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

     

    Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    --_000_SJ0PR05MB86939263E388AB99C368774FDFB29SJ0PR05MB8693namp_-- From nobody Fri Oct 8 11:37:38 2021 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 9457F3A0D60; Fri, 8 Oct 2021 11:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 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, 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=br+YY1vY; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=euL2jG4W 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 hTyh8134GYsE; Fri, 8 Oct 2021 11:37:24 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1952B3A0DCA; Fri, 8 Oct 2021 11:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16799; q=dns/txt; s=iport; t=1633718229; x=1634927829; h=from:to:cc:subject:date:message-id:mime-version; bh=JH0TjNoxa0FpXOBa2R7kcOnxIFIXSwY/zjW6mDDv2Xs=; b=br+YY1vYEoRAQntBzzbSgKRR3MljdcgS3ZkpCvFSOMrmp1N4tPibwCGW WVF7pXBq3tqOnfaXNhUKAdX56Mk2WZywzQ1+d9Y1CB4S1+/zoljLKZM97 gYXv3fZ7UD2xcuEybxytgGiujMeQvYv9+81ZL2qgINtpHliB3EvDCAGZ/ M=; IronPort-PHdr: =?us-ascii?q?A9a23=3AevWyPR+rE0pYhf9uWMfoyV9kXcBvk7vpIhMP5?= =?us-ascii?q?4UqivRFdaHwt5jhPUmK4/JrgReJWIjA8PtLhqLQtLyoQm0P55uN8RVgOJxBX?= =?us-ascii?q?hMIk4MaygonBsPWB1DnMeTncCE7Ws9FUQwt83SyK0MAHsH4ahXbqWGz6jhHH?= =?us-ascii?q?BL5OEJ1K+35F5SUgd6w0rW5+obYZENDgz/uCY4=3D?= IronPort-Data: =?us-ascii?q?A9a23=3AsxSCTquIYPPP5aONvdFguxByRufnVINcMUV32?= =?us-ascii?q?f8akzHdYApBsoF/qtZmKW/UPvzYN2f1c952PN6+/BkP7JCBm9NjTAo4qClgQ?= =?us-ascii?q?X4RgMeUXt7xwmUckM+xwmwvdK/shiknQoGowPscEzmM+39BDpC79SMljPnQF?= =?us-ascii?q?uKmYAL5EnkZqTFMGX9JZS1Lw4bVsqYw6TSIK1vlVeHa+qUzC3f9s9JACV/43?= =?us-ascii?q?orYwP9ZUFsejxtD1rA2TagjUFYzDBD5BrpHTU26ByOQroW5goeHq+j/ILGRp?= =?us-ascii?q?gs1/j83Ad+j1738aEBPHfjZPBOFjTxdXK3Kbhpq/3NplP1kcqtHLx4L0F1ln?= =?us-ascii?q?PgpoDlJnYevQA4mJKTTsO8cSBJfVSp5OMWq/ZeWfSbu4ZzDkRGun3zEhq8G4?= =?us-ascii?q?FsNFZYA4OdxDiRF9fUZMislbx2fiaSx2r3TYvJ0nMUlI+HqMZ8R/HZ6wlnxD?= =?us-ascii?q?/8jTIuFRePF+N5T3D4qiuhAAOrDfccGZDspZxPFCyCjkH9/5IkWhuykgDz0d?= =?us-ascii?q?CdV7Q3Trqss6G+Vxwt0uIUB+eH9IrSiLfi5VG7Bzo4ew1nEPw=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AIJ9PoKPe51ofS8BcT2z155DYdb4zR+YMi2?= =?us-ascii?q?TDiHoRdfUFSKKlfp6V88jzjSWE9Qr4WBkb6Le90dq7MA/hHP9OkMcs1NKZPD?= =?us-ascii?q?UO11HYV72KgbGSpgEIeBeOt9K1t50QCZSWYeeYZTMR4KqKg3jbLz9K+qjgzE?= =?us-ascii?q?ncv5an854bd3ASV0gP1XYcNi+rVmlNACVWD5swE5SRouBdoSC7RHgRZsOnQl?= =?us-ascii?q?EYQunqvbTw5dLbSC9DIyRixBiFjDuu5rK/OQOfxA0iXzRGxqpn2XTZkjb++r?= =?us-ascii?q?6ov5iAu1zhPi7ontZrcenau59+7f+3+48ow/LX+0CVjbFaKvi/VfYO0biSAR?= =?us-ascii?q?gR4YHxSlwbTrtOAjvqDx+ISF3WqlLdOPJE0Q6+9bde6kGT+/ARDQhKe/aoz+?= =?us-ascii?q?hiA2rkwltls9dm3K1R2WWF85JREBPbhSz4o8PFThdwiyOP0DAfeMMo/jRiuL?= =?us-ascii?q?ElGfRsRE0kjTdoOYZFGDi/5JEsEeFoAs2Z7PFKcUmCZ3ScumV02tSjUnk6Ax?= =?us-ascii?q?/DGyE5y4Co+ikTmGo8w1oTxcQZkHtF/JUhS4Nc7+CBNqhzjrlBQsIfcKo4Du?= =?us-ascii?q?YcRsm8DHDLXHv3QS+vCEWiELtCN2PGqpbx7rlw7Oa2eIYQxJ93g5jFWEMwjx?= =?us-ascii?q?96R6svM7z54HRvyGGDfIyQZ0We9ihu3ekPhlSnfsuZDcSqciFar/ed?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B+AAAVj2Bh/49dJa1aHQEBAQEJARI?= =?us-ascii?q?BBQUBggUIAQsBgSAwIy4Hd1o3MYRHg0cDhFlgiAkDlWaFBoEuFIERA1QLAQE?= =?us-ascii?q?BDQEBNwoEAQGEfhmCMQIlNAkOAQIEAQEBEgEBBQEBAQIBBgSBEROFOwglDYZ?= =?us-ascii?q?CAQIBAxILBgoTAQEsCwERAQgRAwECJAcCBDAdCgQBDQUbB4JPAYF+VwMvAQ6?= =?us-ascii?q?hRQGBOgKKH3qBMYEBgggBAQYEBIFKQYJ/GII1AwaBOgGDAIQTAQGHGhyBSUS?= =?us-ascii?q?BFScMEIJnPoJjAgOBIwUBEgFBDYJrN4IMIoppL0JkBBs4IAJZFoECKhEplRS?= =?us-ascii?q?Ido1MkioKgzCKRpQkBSyDaotsl0CHE48SjE2YeAIEAgQFAg4BAQaBYTtpcHA?= =?us-ascii?q?VOyoBgj5RGQ+DPopiDBYVGYMihRSFSnQCNgIGAQoBAQMJlHEBAQ?= X-IronPort-AV: E=Sophos;i="5.85,358,1624320000"; d="scan'208,217";a="946988864" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Oct 2021 18:37:07 +0000 Received: from mail.cisco.com (xbe-aln-007.cisco.com [173.36.7.22]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 198Ib7xg028047 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 8 Oct 2021 18:37:07 GMT Received: from xfe-rtp-003.cisco.com (64.101.210.233) by xbe-aln-007.cisco.com (173.36.7.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 8 Oct 2021 13:37:07 -0500 Received: from xfe-aln-005.cisco.com (173.37.135.125) by xfe-rtp-003.cisco.com (64.101.210.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 8 Oct 2021 14:37:06 -0400 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Fri, 8 Oct 2021 13:37:06 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QLiIRwvc2BVTBp1l5VU+iGgAvibJq3ni0XPN7uBpHMXzieKIlwEbXASyzR0eIx0XVkCeL94ac+r7Udduzp8197he66doXiNfP+uZUGQhZ1stf1BBI+PGTb6BiOlDeh+iF9PojLg8b6xGrrF1vVX6423RzXNidfi9+pl0dty0jS4LPE6n8vhrFKN3/3FKZC2Y3giE/9kUwX/q7H0ftFoIsX5eHRzBTkMT8xH1xWlCl3Xer1IsYbrR0tCWknuJlifK3avxoqemcKPfK+T6PRfXQG1E2TDJXNPITanng+aKwd5fbygxnFsrjXaALfjVwOJNEM0UYNxTrDOEoiPAcRY1gg== 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=JH0TjNoxa0FpXOBa2R7kcOnxIFIXSwY/zjW6mDDv2Xs=; b=fr4hRwUkcq7rZmosKX37dba0CqJ1fHXXkpOvABQJzRVNguM9OE2JU70QV1BWWFms/DJYvXVE/u1P3YJBNByjM1eoY2im3592qFQZd+w2NrAk+3Fx7MoSgCXJN4qhjMnOxy9H0VIYd7hU0bXeF2+ncwQfLmQ+qeq7OMrAlnZbQYMm9f9JFbXp94KAfnVDLGPT+yr12KNaavbvk4hSg63Zc6atS1U8h5K+bYg8o630j72UP5RcScrUlYYuX4LWgmtnVJPPPmBd3IiD5mY4RerVULxMLy3rPp/Uy8KLs7W05AODK+X++uTnoudtipWxFbsT6uEBZN9M7JZgGBohXmZDDw== 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=JH0TjNoxa0FpXOBa2R7kcOnxIFIXSwY/zjW6mDDv2Xs=; b=euL2jG4WEfTiilARPZVv8GFwNJeSC0NFgZDh2eBNEQPn8jE745mAIedkqo/kNA67ZKJwhU7BGD0JpoiAYtmgt6nHby9Nyjm88qrlje2yKJ8UoFV8dXP1htlE3fUVfj4OHy46lxbGjmECumof2CveOueONOlq3GKVgqbF8KnRPqM= Received: from BYAPR11MB2806.namprd11.prod.outlook.com (2603:10b6:a02:c7::12) by BY5PR11MB3974.namprd11.prod.outlook.com (2603:10b6:a03:183::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.18; Fri, 8 Oct 2021 18:37:04 +0000 Received: from BYAPR11MB2806.namprd11.prod.outlook.com ([fe80::c103:beda:2e7f:6664]) by BYAPR11MB2806.namprd11.prod.outlook.com ([fe80::c103:beda:2e7f:6664%5]) with mapi id 15.20.4566.022; Fri, 8 Oct 2021 18:37:04 +0000 From: "Swadesh Agrawal (swaagraw)" To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: AQHXvHN9/4v3Ibg7GEa+SCQbERNBfA== Date: Fri, 8 Oct 2021 18:37:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.53.21091200 authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3c97754d-1629-4d59-6794-08d98a8aa02a x-ms-traffictypediagnostic: BY5PR11MB3974: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CwOHiyR53kWgbOJCq1yIv/uMkENhmBpAQfLuTI1fyMmrC+34djmhSk8mdNtWc2wr0lqTk/sKJhOm0KFuVfduj7yhJwtHC/aEy3E6rWc+Y9KFY4UMpO6fMmpWrLlFjz+sZW1g1nUyxxvZDVpKbOcJODin0UOXDWhYDW1JAVxPqq5FABws4ZyA3CgbxgIqJ6k4cv6PxFYO6QkxjARicqNVxJRLnBHiOKUHiXOcsrBIu7dKj7hBpoYs+s/nl21GVYzjThmJdcOEVEGzAInGnK4zXXWTYvCQ+mAoPn+oDJdAcI+/gNWaYGtVxSkjNfjujeNAABLHVqV6IYWyqVXc/14TdgBbck+9XtBWaGJLPDOq77Soloh6N+Zw1GvKRViO0vwFKRgxXxlspKjzINfCWfjyfbqwDEW0BuTmr2nPX2FcKNEAKSkvY8tBuLuBy/b9qBfoUSETPHXuHXKKhTcwoLJHKlnN+MeWIZ4llni8knOpoGCiQj4Ji9x1itmwKV6XyPw1NnxLam1Lve3DL0q1bsPCZtkyq1qOzWavXeIjEfeZJpnqMd4lR+y2122J9zfyqzMiY5QOB54GoUaMj0XV1Bt1e6ouOIEFaR0l1WjfSccLoDhhbtMo6Xqdm9Bn6DRDiEGoHWx/wBAhYPAicH8DnWW0ommGggTZjl7odfhBWdp6iTY3ECyJa6ecMgqcoV56OyckB8JA6AAxn0WGMMtjwq5PU9S81fVvmtnr+5Wpd5u40HIgFdpoxMH6JgoC+InEU/k9P43IHNivIocmMWvYzHqxb9I4k+FkoXnclRjTqmWAmH4QEYZSt1IkFMnvCl04piIB x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2806.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(83380400001)(6512007)(8676002)(36756003)(4326008)(5660300002)(33656002)(2616005)(110136005)(508600001)(86362001)(316002)(38070700005)(8936002)(966005)(38100700002)(6486002)(122000001)(76116006)(6506007)(71200400001)(53546011)(66946007)(66476007)(2906002)(66446008)(186003)(66556008)(64756008)(166002)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ODNPR0pmS1Y0QUZMU0tVNzJZNnI5ZWRnQi9yeVovU3hlQUJpWEN6aWF0dmRH?= =?utf-8?B?Vm8yRFVPOVRsNlpXbDI2UEhMRSt1RFNPaGNQbkE4d0p3b1F5Uy9QempoWTla?= =?utf-8?B?Ym5MK09GZVZoMGFFMHFHNUM1YndEV0xnbjlJTUVRQ0ZyTXZNOEJHS3RUem5G?= =?utf-8?B?VzgxVmFZY2hJYTJRWnRCZ2ZtclFqOS9Bbk5ZT0thTjNRZ2tMUEIyVnVpRkYx?= =?utf-8?B?Y0FxVHRNVnFqWjNEVllXWXNpcDFoRUY5S3RXd01wRUdNZEozd0VYWG14WXBF?= =?utf-8?B?STBBZXBqYnM5ck1McDRhbUYrWVlQeXQxdjRlbDJxaGVQUVpSb1Ixb3RtTUJn?= =?utf-8?B?cW8xNjg0bkhES2I5QWlxN0YwKzVyU2FuREdqR2pDNkNVSlJBSXczc3ZaK2Ju?= =?utf-8?B?VzhHTWJLQzVzMk1idGdpRk8wUStrSEZPSFpMQ2gvTzVEQWtIcUkyWlNnTmhh?= =?utf-8?B?cGZ2d3ZuVkU4UEJWZlRpZW1EbHZzL2EwUlJCdnVKbkZybFRYL3ArUCs2N3Bz?= =?utf-8?B?U3JzZnU2R1dvU1Y4RFZydGtkT2pCdTNlK0hJT2VNdDlhK1NjT0VhNms0d1lP?= =?utf-8?B?VEFZZVJqT3c1NzFOWUdJUHdxQWIwdjlaY2g5dm5RVytuZDg5dVhyREd5cTlV?= =?utf-8?B?YjNJaTAzdTJocnRlcTNrR1pyWUhDVTRaaE40NU80a3pldzZnK3oxd0tUekVv?= =?utf-8?B?MGRyZWM0WjUvbmVTNTZib0tybjA1aGN6eGVpNFZ6MzVSU3puNEFjQk5Hei9U?= =?utf-8?B?WjRTUkVuK01MVHYxVGpSMWVtb25yZjI0cUFYRU45cW9VZ0hjR0ZUVHVXZFlR?= =?utf-8?B?NHJDTitFdFN2SmdXNWg1ZWtTK1d6V1pGcmxpQXovM0xCb05Ib3ovcSsvOFAx?= =?utf-8?B?M0FNbzdpNWdIT1dvQzRaR3J1QUhyQlZMbGRraDlTbWFLNVNYeHlvUHpaajdF?= =?utf-8?B?TkpiK3pTYWJGNCt1QnpXWXY0d2tydE1KT1NJSVN0VFdCOE9aQ3QwRnVDQUJF?= =?utf-8?B?VlJhZWQyYXNvdjlwclUvVXhNa1VBZnB1cnlRcmMvQ2pLeDA1N1V5VXkyY0ph?= =?utf-8?B?RTRTdDhwTVliWE1DNTVtajZSUTlJaW5vNnh3aCtxTTJVbEVwbEtySG1qYWU2?= =?utf-8?B?V1BjZUwzVzB6THVjTERIVlRRVGg1TE1yQU03UEphNW94cUV2VVRaZW5zV3k1?= =?utf-8?B?WlI5QlErL1lxN1lyc3NpUmpDRUNXMTFMbjA0azNoTVhFNlMwbHcya1F5Mmpk?= =?utf-8?B?QnNTejdsYjlwakdGNGVMWUZ4L21WVGJzSjE0aWZhTEZoY2xGbGMycEdSeEw2?= =?utf-8?B?TElOeFJ5bVVSRDNGYkpEWkVma0N0NjVZemcxVDlSMEJDTmVXSE1WaWo0RHZv?= =?utf-8?B?dVNxNEh5OEUrUVlpbHJEWG9ja0J0UlliSTBveG1WU09INkR1UVQ1NmNsNStu?= =?utf-8?B?ZEIzUk9FZG9uSTNDanVSK0N3WVBKWm5TakxHejdOOGxEbUVsR1hta1dLT254?= =?utf-8?B?WkhVek4xZC90cVJ0YUZ3UVVDcWdiQXRBVDBZZGJ4a1JZVDYyVmNmRkxJcC9K?= =?utf-8?B?bnRaY3VMeHduQzVEMG9hVU5wMU1QaUN6ZldxeUFBVzdxOGRyYS9qRDN2TkJ0?= =?utf-8?B?cE5MNUcyd05YTUM0MnFUdExzSmF3UkZ3bmJrdEIrb0MzT3lyV1hPNkdzM3dz?= =?utf-8?B?Vk51L25sNUlkUDdvZnJEbVBoZUpvU1poTWtTc0ZHeHBWN2lwc1kzdG9hQjBl?= =?utf-8?B?VHpNck9VOExrQkNpTFRuWVZOQzVLejkyNXZKbytlUUpPRko4WjN1SWZkbi9l?= =?utf-8?B?V21JbzdrOVAwdllQWHBqUjR3WGNlWTJYVFBheFh4bGdlUVFGWG5EMDNOaks2?= =?utf-8?Q?7grg7x/pAMRfU?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_FB94E2FBE29B41418A1981803B6B9BDAciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2806.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3c97754d-1629-4d59-6794-08d98a8aa02a X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2021 18:37:04.4590 (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: RtC2vvcWnMlP7spgiklr9dZZMRfWlkT0avOmEQ0pABrEAD6wc+NKPoSgifB5I7dR6D/xwnwmU4mE0QSAyQuFig== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR11MB3974 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.22, xbe-aln-007.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 08 Oct 2021 18:37:35 -0000 --_000_FB94E2FBE29B41418A1981803B6B9BDAciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2hhaXJzLCBXRywNCg0KUkZDODk4NiBkZWZpbmVzIG11bHRpcGxlIGZsYXZvcnMgZm9yIHRo ZSBFbmQsIEVuZC5YLCBhbmQgRW5kLlQgU0lEcy4gQ1NJRCBkcmFmdCBhZGRzIG5leHQgYW5kIHJl cGxhY2UgZmxhdm9ycyBmb3IgdGhlc2UgU0lEcyBmb3IgU1J2NiBjb21wcmVzc2lvbiBpbiBjb25m b3JtYW5jZSB0byBSRkM4OTg2LiBDU0lEIGlzIGEgc2luZ2xlIFNSdjYgYmFzZWQgZGF0YSBwbGFu ZSBzb2x1dGlvbg0KDQpJIHN0cm9uZ2x5IHN1cHBvcnQgdGhlIFdHIGFkb3B0aW9uIGNhbGwuDQoN ClJlZ2FyZHMNClN3YWRlc2gNCg0KDQpGcm9tOiBzcHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYu b3JnPiBvbiBiZWhhbGYgb2YgSmFtZXMgR3VpY2hhcmQgPGphbWVzLm4uZ3VpY2hhcmRAZnV0dXJl d2VpLmNvbT4NCkRhdGU6IEZyaWRheSwgT2N0b2JlciAxLCAyMDIxIGF0IDc6MDQgQU0NClRvOiBT UFJJTkcgV0cgPHNwcmluZ0BpZXRmLm9yZz4NCkNjOiAic3ByaW5nLWNoYWlyc0BpZXRmLm9yZyIg PHNwcmluZy1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbc3ByaW5nXSBXRyBBZG9wdGlvbiBj YWxsIGZvciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2No ZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8NCg0KRGVhciBXRzoNCg0KVGhlIGNoYWly cyB3b3VsZCBsaWtlIHRvIGV4cHJlc3MgdGhlaXIgYXBwcmVjaWF0aW9uIGZvciBhbGwgdGhlIHJl c3BvbnNlcyByZWNlaXZlZCB0byBvdXIgZW1haWxzIHdpdGggcmVmZXJlbmNlIHRvIGhvdyB0aGUg d29ya2luZyBncm91cCB3aXNoZXMgdG8gbW92ZSBmb3J3YXJkIHdpdGggcmVzcGVjdCB0byBhIHNv bHV0aW9uIGZvciBTUnY2IGNvbXByZXNzaW9uLg0KDQpUaGUgYXBwYXJlbnQgaW5jbGluYXRpb24g b2YgdGhlIHdvcmtpbmcgZ3JvdXAgaXMgdG8gdXNlIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyBh cyB0aGUgYmFzaXMgZm9yIGl0cyBjb21wcmVzc2lvbiBzdGFuZGFyZGl6YXRpb24gd29yay4gVGhh dCBpcyBwYXJ0IG9mIHdoYXQgdGhpcyBlbWFpbCBhdHRlbXB0cyB0byBjb25maXJtLg0KDQpCZWNh dXNlIG9mIHRoZSBhYm92ZSB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gaXNzdWUgYSAyLXdlZWsg V0cgY2FsbCBmb3IgYWRvcHRpb24gZW5kaW5nIE9jdG9iZXIgMTV0aCBmb3IgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgt Y29tcHJlc3Npb24vIGJ1dCB3aXRoIHNvbWUgY2xlYXIgZ3VpZGVsaW5lcyBhcyBmb2xsb3dzLiBC eSBleHByZXNzaW5nIHN1cHBvcnQgZm9yIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgeW91IGFy ZSBmdWxseSBhd2FyZSBvZiBhbmQgYXJlIGFja25vd2xlZGdpbmcgdGhhdDoNCg0KDQogIDEuICBU aGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAgaXMgYWRvcHRpbmcgYSBkb2N1bWVudCB0aGF0IGhhcyBt dWx0aXBsZSBTUnY2IEVuZHBvaW50IGJlaGF2aW9ycy4NCiAgMi4gIFRoZSBkb2N1bWVudCBpcyBh IOKAnGxpdmluZ+KAnSBkb2N1bWVudDsgaXQgbWF5IGNoYW5nZSBhcyBpdCBnb2VzIHRocm91Z2gg cmV2aWV3IGFuZCBhbmFseXNpcyBieSB0aGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAuDQogIDMuICBB bGwgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyByYWlzZWQgb24gb3VyIG1haWxpbmcgbGlzdCBNVVNU IGJlIGFkZHJlc3NlZCBCRUZPUkUgc2FpZCBkb2N1bWVudCBpcyBhbGxvd2VkIHRvIHByb2dyZXNz IGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAgdG8gcHVibGljYXRpb24uIEEgbGlzdCBvZiB0aGVzZSBk aXNjdXNzaW9uIHBvaW50cyB3aWxsIGJlIGRvY3VtZW50ZWQgaW4gdGhlIFdHIGRvY3VtZW50IGFu ZCBtYWludGFpbmVkIGJ5IHRoZSBkb2N1bWVudCBlZGl0b3IgaW4gY29uanVuY3Rpb24gd2l0aCB0 aGUgY2hhaXJzLg0KICA0LiAgSWYgdGhpcyBkb2N1bWVudCBpcyBhZG9wdGVkIGJ5IHRoZSB3b3Jr aW5nIGdyb3VwLCB0aGUgY2hhaXJzIHNwZWNpZnkgYXMgcGFydCBvZiB0aGUgYWRvcHRpb24gY2Fs bCB0aGF0IHRoZSBmb2xsb3dpbmcgdGV4dCBkZXNjcmliaW5nIGFuIG9wZW4gaXNzdWUgYmUgYWRk ZWQgdG8gdGhlIGRvY3VtZW50IGluIHRoZSBhYm92ZS1kZXNjcmliZWQgb3BlbiBpc3N1ZXMgc2Vj dGlvbjoNCiAgICAgKiAgICJHaXZlbiB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBzYWlkIHRo YXQgaXQgd2FudHMgdG8gc3RhbmRhcmRpemUgb25lIGRhdGEgcGxhbmUgc29sdXRpb24sIGFuZCBn aXZlbiB0aGF0IHRoZSBkb2N1bWVudCBjb250YWlucyBtdWx0aXBsZSBTUnY2IEVuZFBvaW50IGJl aGF2aW9ycyB0aGF0IHNvbWUgV0cgbWVtYmVycyBoYXZlIHN0YXRlZCBhcmUgbXVsdGlwbGUgZGF0 YSBwbGFuZSBzb2x1dGlvbnMsIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYWRkcmVzcyB3aGV0aGVy IHRoaXMgaXMgdmFsaWQgYW5kIGNvaGVyZW50IHdpdGggaXRzIG9uZSBkYXRhIHBsYW5lIHNvbHV0 aW9uIG9iamVjdGl2ZS4iLg0KDQpQbGVhc2UgY29uc2lkZXIgdGhlIGFib3ZlIGd1aWRlbGluZXMg YXMgeW91IGRlY2lkZSBvbiB3aGV0aGVyIHRvIHN1cHBvcnQgb3Igbm90IHRoaXMgV0cgYWRvcHRp b24uIFBsZWFzZSBleHByZXNzIGNsZWFybHkgeW91ciByZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9u LXN1cHBvcnQgYXMgd2VsbCBhcyBhbnkgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyB5b3Ugd291bGQg bGlrZSBhZGRyZXNzZWQgc2hvdWxkIHRoZSBkb2N1bWVudCBiZSBhZG9wdGVkIGludG8gdGhlIHdv cmtpbmcgZ3JvdXAuDQoNClRoYW5rcyENCg0KSmltLCBCcnVubyAmIEpvZWwNCg0KDQo= --_000_FB94E2FBE29B41418A1981803B6B9BDAciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNv UGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxh aW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28t bGlzdC1pZDo3NTE2OTkzOTM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOi03MjE2NTQ3NzYgNjc2OTg3MDMgNjc2OTg2ODkgNjc2OTg3MTUgNjc2OTg3MDMg Njc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1p bmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDENCgl7 bXNvLWxpc3QtaWQ6MTQzMjYyNjIwNjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTkwODE4NzQ5 ODt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0eWxlPSJ3b3Jk LXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5IaSBDaGFpcnMsIFdHLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5SRkM4OTg2IGRlZmluZXMgbXVsdGlwbGUgZmxh dm9ycyBmb3IgdGhlIEVuZCwgRW5kLlgsIGFuZCBFbmQuVCBTSURzLiZuYnNwO0NTSUQgZHJhZnQg YWRkcyBuZXh0IGFuZCByZXBsYWNlIGZsYXZvcnMgZm9yIHRoZXNlIFNJRHMgZm9yIFNSdjYgY29t cHJlc3Npb24gaW4gY29uZm9ybWFuY2UgdG8gUkZDODk4Ni4mbmJzcDtDU0lEIGlzIGEgc2luZ2xl IFNSdjYgYmFzZWQgZGF0YSBwbGFuZQ0KIHNvbHV0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPkkgc3Ryb25nbHkgc3VwcG9ydCB0aGUgV0cgYWRvcHRpb24gY2FsbC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+U3dhZGVzaDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+c3ByaW5nICZsdDtzcHJpbmctYm91 bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIEphbWVzIEd1aWNoYXJkICZsdDtqYW1lcy5u Lmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgT2N0 b2JlciAxLCAyMDIxIGF0IDc6MDQgQU08YnI+DQo8Yj5UbzogPC9iPlNQUklORyBXRyAmbHQ7c3By aW5nQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7c3ByaW5nLWNoYWlyc0BpZXRm Lm9yZyZxdW90OyAmbHQ7c3ByaW5nLWNoYWlyc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0 OiA8L2I+W3NwcmluZ10gV0cgQWRvcHRpb24gY2FsbCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Np b24vPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkRlYXIgV0c6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjaGFpcnMgd291bGQgbGlrZSB0 byBleHByZXNzIHRoZWlyIGFwcHJlY2lhdGlvbiBmb3IgYWxsIHRoZSByZXNwb25zZXMgcmVjZWl2 ZWQgdG8gb3VyIGVtYWlscyB3aXRoIHJlZmVyZW5jZSB0byBob3cgdGhlIHdvcmtpbmcgZ3JvdXAg d2lzaGVzIHRvIG1vdmUgZm9yd2FyZCB3aXRoIHJlc3BlY3QgdG8gYSBzb2x1dGlvbiBmb3IgU1J2 NiBjb21wcmVzc2lvbi4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgYXBwYXJlbnQgaW5j bGluYXRpb24gb2YgdGhlIHdvcmtpbmcgZ3JvdXAgaXMgdG8gdXNlIDxhIGhyZWY9Imh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYt c3JoLWNvbXByZXNzaW9uLyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88L2E+IGFzIHRoZSBi YXNpcyBmb3IgaXRzIGNvbXByZXNzaW9uIHN0YW5kYXJkaXphdGlvbiB3b3JrLiBUaGF0IGlzIHBh cnQgb2Ygd2hhdCB0aGlzIGVtYWlsIGF0dGVtcHRzIHRvIGNvbmZpcm0uPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkJlY2F1c2Ugb2YgdGhlIGFib3ZlIHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBp c3N1ZSBhIDItd2VlayBXRyBjYWxsIGZvciBhZG9wdGlvbiBlbmRpbmcgT2N0b2JlciAxNTxzdXA+ dGg8L3N1cD4gZm9yDQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8iPg0KaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2 Ni1zcmgtY29tcHJlc3Npb24vPC9hPiBidXQgd2l0aCBzb21lIGNsZWFyIGd1aWRlbGluZXMgYXMg Zm9sbG93cy4gQnkgZXhwcmVzc2luZyBzdXBwb3J0IGZvciBhZG9wdGlvbiBvZiB0aGlzIGRvY3Vt ZW50IHlvdSBhcmUgZnVsbHkgYXdhcmUgb2YgYW5kIGFyZSBhY2tub3dsZWRnaW5nIHRoYXQ6DQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0Omww IGxldmVsMSBsZm8zIj5UaGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAgaXMgYWRvcHRpbmcgYSBkb2N1 bWVudCB0aGF0IGhhcyBtdWx0aXBsZSBTUnY2IEVuZHBvaW50IGJlaGF2aW9ycy4NCjxvOnA+PC9v OnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPlRoZSBkb2N1bWVudCBpcyBhIOKAnGxpdmluZ+KA nSBkb2N1bWVudDsgaXQgbWF5IGNoYW5nZSBhcyBpdCBnb2VzIHRocm91Z2ggcmV2aWV3IGFuZCBh bmFseXNpcyBieSB0aGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAuDQo8bzpwPjwvbzpwPjwvbGk+PGxp IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0 OmwwIGxldmVsMSBsZm8zIj5BbGwgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyByYWlzZWQgb24gb3Vy IG1haWxpbmcgbGlzdCBNVVNUIGJlIGFkZHJlc3NlZCBCRUZPUkUgc2FpZCBkb2N1bWVudCBpcyBh bGxvd2VkIHRvIHByb2dyZXNzIGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAgdG8gcHVibGljYXRpb24u IEEgbGlzdCBvZiB0aGVzZSBkaXNjdXNzaW9uDQogcG9pbnRzIHdpbGwgYmUgZG9jdW1lbnRlZCBp biB0aGUgV0cgZG9jdW1lbnQgYW5kIG1haW50YWluZWQgYnkgdGhlIGRvY3VtZW50IGVkaXRvciBp biBjb25qdW5jdGlvbiB3aXRoIHRoZSBjaGFpcnMuDQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxl dmVsMSBsZm8zIj5JZiB0aGlzIGRvY3VtZW50IGlzIGFkb3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3Jv dXAsIHRoZSBjaGFpcnMgc3BlY2lmeSBhcyBwYXJ0IG9mIHRoZSBhZG9wdGlvbiBjYWxsIHRoYXQg dGhlIGZvbGxvd2luZyB0ZXh0IGRlc2NyaWJpbmcgYW4gb3BlbiBpc3N1ZSBiZSBhZGRlZCB0byB0 aGUgZG9jdW1lbnQgaW4gdGhlIGFib3ZlLWRlc2NyaWJlZA0KIG9wZW4gaXNzdWVzIHNlY3Rpb246 PG86cD48L286cD48L2xpPjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0K PGxpIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDIgbGZvMyI+ JnF1b3Q7R2l2ZW4gdGhhdCB0aGUgd29ya2luZyBncm91cCBoYXMgc2FpZCB0aGF0IGl0IHdhbnRz IHRvIHN0YW5kYXJkaXplIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uLCBhbmQgZ2l2ZW4gdGhhdCB0 aGUgZG9jdW1lbnQgY29udGFpbnMgbXVsdGlwbGUgU1J2NiBFbmRQb2ludCBiZWhhdmlvcnMgdGhh dCBzb21lIFdHIG1lbWJlcnMgaGF2ZSBzdGF0ZWQgYXJlDQogbXVsdGlwbGUgZGF0YSBwbGFuZSBz b2x1dGlvbnMsIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYWRkcmVzcyB3aGV0aGVyIHRoaXMgaXMg dmFsaWQgYW5kIGNvaGVyZW50IHdpdGggaXRzIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uIG9iamVj dGl2ZS4mcXVvdDsuPG86cD48L286cD48L2xpPjwvdWw+DQo8L29sPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2Ug Y29uc2lkZXIgdGhlIGFib3ZlIGd1aWRlbGluZXMgYXMgeW91IGRlY2lkZSBvbiB3aGV0aGVyIHRv IHN1cHBvcnQgb3Igbm90IHRoaXMgV0cgYWRvcHRpb24uIFBsZWFzZSBleHByZXNzIGNsZWFybHkg eW91ciByZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9uLXN1cHBvcnQgYXMgd2VsbCBhcyBhbnkgb3Bl biBkaXNjdXNzaW9uIHBvaW50cyB5b3Ugd291bGQgbGlrZSBhZGRyZXNzZWQgc2hvdWxkIHRoZSBk b2N1bWVudA0KIGJlIGFkb3B0ZWQgaW50byB0aGUgd29ya2luZyBncm91cC48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhbmtzITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KaW0sIEJydW5vICZh bXA7IEpvZWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_FB94E2FBE29B41418A1981803B6B9BDAciscocom_-- From nobody Fri Oct 8 13:21:35 2021 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 3A83D3A079D; Fri, 8 Oct 2021 13:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JC8M3wqabFME; Fri, 8 Oct 2021 13:21:25 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 33FD13A0788; Fri, 8 Oct 2021 13:21:25 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id i20so24346084edj.10; Fri, 08 Oct 2021 13:21:25 -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=DjGH3c4C+i/V3Rpu81TPpiZSyXLnyXAos8biXPVGipM=; b=XOOqiyZJmsN69/daWb4AFzJqKHZpRpKifMm9+TSQj+4ak4131SfGhM1bCeUign+Yby 21wNvIaAvu8O4NWF8Wm/qY3I6ieny2zcPta/LnOpkhmsagVBmG/So4eyWoZodOLTyUdp vqVOBLcDsfvaED+mMPQabVpQO3GCOZsn/inS/VVURjXanrZi+BAIm+aIpWJiEBPuOC8d 97DidhJwQ/WRFecdzskiZ114YOh/XclsBZAf4XbMV/PiRE48uVfik/R2ICBbIH16DXSY E1b4idlrJiFEVeBOiXkprkzg/BhLfpLrA9xs5IqNVoVEq+qHjavjTj8g+KQkoLxyri51 XoBA== 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=DjGH3c4C+i/V3Rpu81TPpiZSyXLnyXAos8biXPVGipM=; b=xVcwQIPPMIgg19+hssZT1Y67tPFI5l86U7O7NE1+yny8MdLgCBmdTbs9pSj26T0/FH RYyxmH6ZX0PZ+xCvlYJX39XZx1jEriEnxkp0l+hF/d6NbL3WiobHo+bDza0B+fqiDp1J EHbwdovT7/1d1eZbYtgw9fjBdVX7zvxyRtBN79zbLCUqDNLhlhV3/LxIKI7OfZ4aItOR fHTo8xcYHUxnaa0srAkqqbNhlCjbREi0X3frDqH6qE1TAvwmF7UwTsvsgSbLFPJKsjyW c4z2IdWRCmiQlQfkFb1LokD/qh5TF8pcx+G3SH5ZSCgTvchbqKsHgGB+LZmui7w1pHIs HGUQ== X-Gm-Message-State: AOAM531d8obO0YTUAgPJa1Pll1CsD5TJTY2WnOJyO7Q5zwMX7Q6jvgrx flivXZSge7x4Y4i0xHi9GDf6W3k/vnMban6BOtS6j8NE5Fw= X-Google-Smtp-Source: ABdhPJwmImamB31bcyUYzF2cRbh05TDxw7OW06dVeBNHz5Y+k2vFx4hmoPRV24lIkweQ1rAt+fsOBFAOnKfPvKbJBG0= X-Received: by 2002:a17:906:369a:: with SMTP id a26mr6559058ejc.539.1633724483364; Fri, 08 Oct 2021 13:21:23 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Fri, 8 Oct 2021 13:21:12 -0700 Message-ID: To: "Francois Clad (fclad)" Cc: Robert Raszuk , Ron Bonica , James Guichard , SPRING WG , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007dea7905cddd1fbe" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 08 Oct 2021 20:21:32 -0000 --0000000000007dea7905cddd1fbe Content-Type: text/plain; charset="UTF-8" Hi Francois, you've said that different flavors of C-SID can be present not only in the same SRH but also in the same C-SID container. The latter case got me thinking about several potential scenarios. Have to admit that I got stuck trying to understand how they can work. I hope you can help me out. Please consider the two cases described below. Consider, for all cases, that we are handling a container with entries A, B, C, and D, of some mix of NEXT-C-SID and REPLACE-C-SID flavors. Case 1: Suppose that A was the REPLACE-C-SID flavor C-SID and B is the NEXT-C-SID flavor. When A is processed, B will be copied into the IPv6 DA, retaining the prefix before A in the container. So far, so good. Then, when the packet arrives at the node that processes B, it will say "NEXT". The remaining bits will be? I thought zero, but actually, it will presumably be two bits with the value two? So the subsequent behavior will shift that two up? Even if the NEXT-C-SID flavor guesses that the two should be zero, it would skip C and D and pick up the entry from the next C-SID container in the SRH. So it seems to either work wrong or work oddly? Case 2: Suppose that A was the NEXT-C-SID flavor. So it simply shifts B, C, D upwards in the IPv6 DA. Suppose B is the REPLACE-C-SID flavor. It will interpret the upper bits of the C C-SID as the arg for selecting the position in the C-SID container to pull an entry from. It will also modify the C C-SID to perform the decrement it thinks it needs. It will then overwrite itself with the randomly chosen entry from the container. It seems that neither scenario works. At least, I cannot figure out how it can work. I would greatly appreciate it if you could have a look and clarify it for me. Regards, Greg On Fri, Oct 8, 2021 at 10:12 AM Francois Clad (fclad) wrote: > Hi Greg, > > > > Thank you for the confirmation. I am glad that the matter of combining > C-SIDs of different flavors is clear now. > > > > Thanks, > > Francois > > > > *From: *Greg Mirsky > *Date: *Thursday, 7 October 2021 at 20:15 > *To: *Francois Clad (fclad) > *Cc: *Robert Raszuk , Ron Bonica 40juniper.net@dmarc.ietf.org>, James Guichard < > james.n.guichard@futurewei.com>, SPRING WG , > spring-chairs@ietf.org > *Subject: *Re: [spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > Hi Francois, > > thank you for your detailed response and confirming that C-SIDs of > different flavors/behavior may be present in the same SRH and even the same > CSID container. I've noticed Ron's proposal as I was trying to formulate my > question. His proposal highlighted what I am trying to understand - the > relationship between NEXT-C-SID and REPLACE-C-SID. I concur with Ron. The > WG has adopted the compression analysis draft > , > and the updates and an additional analysis Ron proposed will keep the > discussion and decision-making process on the firm technical foundation. > > > > Regards, > > Greg > > > > On Thu, Oct 7, 2021 at 9:17 AM Francois Clad (fclad) > wrote: > > Hi Greg, > > > > It is the role of the SR Source Node [Section 3.1 of RFC 8754] to form the > segment list in the SRH. It learns about the available SIDs in the network > with their associated behavior and flavors via control plane and/or > management plane protocols, as described in Section 8 of RFC 8986, and > selects the SIDs that are the most appropriate for the segment list. > > > > Each SR Segment Endpoint Node [Section 3.3 of RFC 8754] simply executes > the pseudocode of a locally instantiated SID when it receives a packet > matching that SID. The SR Segment Endpoint Node does not need to bother > about the behavior/flavor of the subsequent SRv6 SIDs. > > > > This SRv6 logic applies to the C-SID flavors as well. The choice of > flavors for the SIDs in the SID List is up to the SR Source Node. > > > > It is indeed possible to mix SIDs of different C-SID flavors in the same > SRH, and even in a single C-SID container. > > > > Thanks, > > Francois > > > > > > *From: *Greg Mirsky > *Date: *Wednesday, 6 October 2021 at 19:19 > *To: *Francois Clad (fclad) > *Cc: *Robert Raszuk , Ron Bonica 40juniper.net@dmarc.ietf.org>, James Guichard < > james.n.guichard@futurewei.com>, SPRING WG , > spring-chairs@ietf.org > *Subject: *Re: [spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > Hi Francois, > > thank you for the clarification. It is still not clear how a node selects > which flavor of CSID to use on the next compressed CSID that may happen > also be in the next CSID container. As I understand it, a CSID container > must use the same flavor of compression but CSID containers with different > compression flavors in the same SRH are allowed. Is that correct > understanding? > > > > Regards, > > Greg > > > > On Wed, Oct 6, 2021 at 7:05 AM Francois Clad (fclad) > wrote: > > Hi Greg, > > > > A node that supports this draft in its entirety can instantiate SRv6 SIDs > (e.g., End and End.X SIDs) with any of the three C-SID flavors. > > > > In particular, a node can instantiate multiple SRv6 SIDs bound to > different C-SID flavors, possibly with different C-SID lengths. It can also > instantiate SRv6 SIDs with behaviors and flavors defined in RFC 8986. > > > > As defined in Section 4.3 of RFC 8754 and again in Section 3 of RFC 8986, > upon receiving an IPv6 packet with a destination address matching a FIB > entry that represents one of these locally instantiated SIDs, the node > processes the packet according to the behavior (and flavor(s)) (i.e. > pseudocode) of that SID. > > > > RFC 8754 and 8986 have already standardized these mechanisms and the C-SID > draft only leverages the same SRv6 dataplane to introduce new endpoint > flavors for compression. > > > > > > Francois > > > > *From: *spring on behalf of Greg Mirsky < > gregimirsky@gmail.com> > *Date: *Tuesday, 5 October 2021 at 23:37 > *To: *Robert Raszuk > *Cc: *Ron Bonica , James Guichard < > james.n.guichard@futurewei.com>, SPRING WG , > spring-chairs@ietf.org > *Subject: *Re: [spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > Hi Robert, > > as I understand it, you believe everything that is written in the draft. I > hope you can help me find an answer to one simple question: > > Can a node that supports this draft in its entirety, i.e., supports all > "flavors" defined in the document, process received SRv6 packet with the > SRH encoded according to the specification? > > So far, the proponents of the draft referred to "planning" how flavors of > SRv6 SID compressed. To the best of my understanding, that is is a clear > demonstration of the incompatibility between flavors defined in the CSID > draft. Regardless of what is written in it. > > > > Regards, > > Greg > > > > On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk wrote: > > Ron & SPRING WG chairs, > > > > Through this discussion we first have seen a debate if we need one or more > data planes to compress SIDs in SRv6. WG clearly stated we need one. > > > > Following that we have observed a first terminology shift to see if asking > how many solutions should be supported will work any better. To that many > WG members clearly stated that they support one solution. > > > > Well please notice that the draft in question in its introduction states: > > > > Abstract > > This document defines a compressed SRv6 Segment List Encoding in the > Segment Routing Header (SRH). *This solution* does not require any SRH > data plane change nor any SRv6 control plane change. *This solution* > leverages the SRv6 Network Programming model. > > > > So based on my understanding of English the entire draft talks about a > single solution. > > > > Then suddenly a new question popped up: how many behaviours are > acceptable. > > > > I bet number of folks including myself said "one" keeping in mind previous > discussions and the definition of "one" meaning based on the SRv6 data > plane in compliance to [RFC8402], [RFC8754] and [RFC8986]. > > > > Interestingly enough the draft in question defines not behaviours but > flavors as new variants of the already defined behaviors in Standards Track > RFCs. Namely it defines: > > > > 4.1. NEXT-C-SID Flavor > > 4.2. REPLACE-C-SID Flavor > > > > The newly defined behaviour End.XPS is optional. > > So if there is anything to ask here is to check if WG is ok with two > flavors or not. I do not recall that question has ever been asked formally > during the WG adoption call. > > > > With that let's note that optimal compressed SID size may be different > network to network. One size does not fit all. Draft says: > > 6.1. C-SID Length > > The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A > * C-SID length of 16-bit is recommended.* > > The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths. > * A C-SID length of 32-bit is recommended.* > > > > While I personally think 8-bit should be an option, if we choose a single > flavor we will introduce suboptimality for no good reason. Hardware > capable of supporting any flavor clearly can do LPM on locator. Also > hardware capable of supporting one flavor can support few other flavors as > this is pretty much just an offset game. > > > > Kind regards, > > Robert > > > > > > > > On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica 40juniper.net@dmarc.ietf.org> wrote: > > Pablo, > > > > Ae you sure? Please look at the question as Joel asked it ( > https://mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ > ). > > > > > Ron > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > --0000000000007dea7905cddd1fbe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Francois,
    you've said that= different flavors of C-SID can be present not only in the same SRH but als= o in the same C-SID container. The latter case got me thinking about severa= l potential scenarios. Have to admit that I got stuck trying to understand = how they can work. I hope you can help me out. Please consider the two case= s described below.

    Consider, for all cases, that we are handling a c= ontainer with entries A, B, C, and D, of some mix of NEXT-C-SID and REPLACE= -C-SID flavors.

    Case 1:
    Suppose that A was the REPLACE-C-SID flav= or C-SID and B is the NEXT-C-SID flavor. When A is processed, B will be cop= ied into the IPv6 DA, retaining the prefix before A in the container. So fa= r, so good. Then, when the packet arrives at the node that processes B, it = will say "NEXT". The remaining bits will be? I thought zero, but = actually, it will presumably be two bits with the value two? So the subsequ= ent behavior will shift that two up? Even if the NEXT-C-SID flavor guesses = that the two should be zero, it would skip C and D and pick up the entry fr= om the next C-SID container in the SRH. So it seems to either work wrong or= work oddly?

    Case 2:
    Suppose that A was the NEXT-C-SID flavor. So= it simply shifts B, C, D upwards in the IPv6 DA. Suppose B is the REPLACE-= C-SID flavor. It will interpret the upper bits of the C C-SID as the arg fo= r selecting the position in the C-SID container to pull an entry from. It w= ill also modify the C C-SID to perform the decrement it thinks it needs. It= will then overwrite itself with the randomly chosen entry from the contain= er.

    It seems that neither scenario works. At least, I cannot figure= out how it can work. I would greatly appreciate it if you could have a loo= k and clarify it for me.
    Regards,
    Greg
    <= br>
    On Fri,= Oct 8, 2021 at 10:12 AM Francois Clad (fclad) <fclad@cisco.com> wrote:

    Hi Greg,

    =C2=A0

    Thank you for the confirmation. I am glad that= the matter of combining C-SIDs of different flavors is clear now.

    =C2=A0

    Thanks,

    Francois

    =C2=A0

    From: Greg Mirsky <gregimirsky@gmail.com= >
    Date: Thursday, 7 October 2021 at 20:15
    To: Francois Clad (fclad) <fclad@cisco.com>
    Cc: Robert Raszuk <robert@raszuk.net>, Ron Bonica <rbonica=3D40juniper.net@dmarc.iet= f.org>, James Guichard <james.n.guichard@futurewei.com>, SPRING W= G <spring@ietf.org<= /a>>, spring= -chairs@ietf.org <spring-chairs@ietf.org>
    Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/

    Hi Francois,

    thank you for your detailed response and confirming = that C-SIDs of different flavors/behavior=C2=A0may be present in the same S= RH and even the same CSID container. I've noticed Ron's proposal as= I was trying to formulate my question. His proposal highlighted what I am trying to understand - the relationship=C2=A0between= NEXT-C-SID and REPLACE-C-SID. I concur with Ron. The WG has adopted the compression analysis draft, and the=C2=A0updates and an additional anal= ysis Ron proposed will keep the discussion and decision-making process on t= he firm technical foundation.

    =C2=A0

    Regards,

    Greg

    =C2=A0

    On Thu, Oct 7, 2021 at 9:17 AM Francois Clad (fclad)= <fclad@cisco.com> wrote:

    Hi Greg,

    =C2=A0

    It is the role of the SR Source Node [Section 3.1 of= RFC 8754] to form the segment list in the SRH. It learns about the availab= le SIDs in the network with their associated behavior and flavors via control plane and/or management plane protocols, as descri= bed in Section 8 of RFC 8986, and selects the SIDs that are the most approp= riate for the segment list.

    =C2=A0

    Each SR Segment Endpoint Node [Section 3.3 of RFC 87= 54] simply executes the pseudocode of a locally instantiated SID when it re= ceives a packet matching that SID. The SR Segment Endpoint Node does not need to bother about the behavior/flavor of the sub= sequent SRv6 SIDs.

    =C2=A0

    This SRv6 logic applies to the C-SID flavors as well= . The choice of flavors for the SIDs in the SID List is up to the SR Source= Node.

    =C2=A0

    It is indeed possible to mix SIDs of different C-SID= flavors in the same SRH, and even in a single C-SID container.

    =C2=A0

    Thanks,

    Francois

    =C2=A0

    =C2=A0

    From: Greg Mirsky <gregimirsky@gmail.com= >
    Date: Wednesday, 6 October 2021 at 19:19
    To: Francois Clad (fclad) <fclad@cisco.com>
    Cc: Robert Raszuk <robert@raszuk.net>, Ron Bonica <rbonica=3D40juniper.net@dmarc.iet= f.org>, James Guichard <james.n.guichard@futurewei.com>, SPRING WG <spring@= ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>
    Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/

    Hi Francois,

    thank you for the clarification. It is still not cle= ar how a node selects which flavor of CSID to use on the next compressed CS= ID that may happen also be in the next CSID container. As I understand it, a CSID container must use the same flavor of compressi= on but CSID containers with different compression flavors in the same SRH a= re allowed. Is that correct understanding?

    =C2=A0

    Regards,

    Greg

    =C2=A0

    On Wed, Oct 6, 2021 at 7:05 AM Francois Clad (fclad)= <fclad@cisco.com> wrote:

    Hi Greg,

    =C2=A0

    A node that supports this draft in its entirety can = instantiate SRv6 SIDs (e.g., End and End.X SIDs) with any of the three C-SID flavors. <= /u>

    =C2=A0

    In particular, a node can instantiate multiple SRv6 = SIDs bound to different C-SID flavors, possibly with different C-SID length= s. It can also instantiate SRv6 SIDs with behaviors and flavors defined in RFC 8986.

    =C2=A0

    As defined in Section 4.3 of RFC 8754 and again in S= ection 3 of RFC 8986, upon receiving an IPv6 packet with a destination addr= ess matching a FIB entry that represents one of these locally instantiated SIDs, the node processes the packet according to the = behavior (and flavor(s)) (i.e. pseudocode) of that SID.

    =C2=A0

    RFC 8754 and 8986 have already standardized these me= chanisms and the C-SID draft only leverages the same SRv6 dataplane to intr= oduce new endpoint flavors for compression.

    =C2=A0

    =C2=A0

    Francois

    =C2=A0

    Hi Robert,

    as I understand it, you believe everything that is w= ritten in the draft. I hope you can help me find an answer to one simple qu= estion:

    Can a node that supports this draft in its entirety,= i.e., supports all "flavors" defined in the document, process re= ceived SRv6 packet with the SRH encoded according to the specification?<= /u>

    So far, the proponents of the draft referred to &quo= t;planning" how flavors of SRv6 SID compressed. To the best of my unde= rstanding, that is is a clear demonstration of the incompatibility between flavors defined in the CSID draft. Regardless of=C2=A0what is writ= ten in it.

    =C2=A0

    Regards,

    Greg

    =C2=A0

    On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk <robert@raszuk.net&g= t; wrote:

    Ron & SPRING WG chairs,

    =C2=A0

    Through this discussion we first have seen a debate = if we need one or more data planes=C2=A0to compress SIDs in SRv6. WG clearl= y=C2=A0stated we need one.=C2=A0

    =C2=A0

    Following that we have observed a first terminology = shift to see if asking how many solutions should be supported will work any= better. To that many WG members clearly stated that they support one solution.=C2=A0

    =C2=A0

    Well please notice that the draft in question in its= introduction states:=C2=A0

    =C2=A0

    Abstract

    =C2=A0 =C2=A0This document defines a compressed SRv6 Segment List Encoding = in the
    =C2=A0 =C2=A0Segment Routing Header (SRH). =C2=A0This solution does = not require any SRH
    =C2=A0 =C2=A0data plane change nor any SRv6 control plane change. =C2=A0= This solution
    =C2=A0 =C2=A0leverages the SRv6 Network Programming model.

    =C2=A0

    So based on my understanding of English the entire d= raft talks about a single solution.=C2=A0

    =C2=A0

    Then suddenly a new question popped=C2=A0up: how man= y behaviours are acceptable.=C2=A0

    =C2=A0

    I bet number of folks including myself said "on= e" keeping in mind previous discussions and the definition of "on= e" meaning based on the SRv6 data plane in compliance to [RFC8402], [RFC8754] and [RFC8986].

    =C2=A0

    Interestingly enough the draft in question defines n= ot behaviours but flavors as new variants of the already defined behaviors = in Standards Track RFCs. Namely it defines:=C2=A0

    =C2=A0

    4.1.=C2=A0 NEXT-C-SID Flavor

    4.2.=C2=A0 REPLACE-C-SID Flavor

    =C2=A0

    The newly defined behaviour End.XPS is optional.=C2= =A0

    So if there is anything to ask here is to check if WG is ok with two flavor= s or not. I do not recall that question has=C2=A0ever been asked formally d= uring the WG adoption call.=C2=A0

    =C2=A0

    With that let's note that optimal compressed SID= size may be different network to network. One size does not fit all. Draft= says:=C2=A0

    6.1.=C2=A0 C-SID Length

    =C2=A0 =C2=A0The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengt= hs. =C2=A0A
    =C2=A0 =C2=A0C-SID length of 16-bit is recommended.

    =C2=A0 =C2=A0The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID le= ngths.
    =C2=A0 =C2=A0A C-SID length of 32-bit is recommended.<= /p>

    =C2=A0

    While I personally think 8-bit should be an option, = if we choose a single flavor we will introduce suboptimality for no good re= ason. Hardware capable=C2=A0of supporting any flavor clearly can do LPM on locator. Also hardware capable of supporting one flavor can = support few other flavors as this is pretty much just an offset game.=C2=A0=

    =C2=A0

    Kind regards,

    Robert

    =C2=A0

    =C2=A0

    =C2=A0

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

    --0000000000007dea7905cddd1fbe-- From nobody Fri Oct 8 14:56:28 2021 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 379093A0A83; Fri, 8 Oct 2021 14:56:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 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, 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=Tr4IIniS; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Ia/5vhHa 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 o3SLL1mw9LY6; Fri, 8 Oct 2021 14:56:20 -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 3426F3A0A79; Fri, 8 Oct 2021 14:56:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13943; q=dns/txt; s=iport; t=1633730180; x=1634939780; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mqxDBrZ2snTAFueBTUnOpxV8QpKdKA4DqkxQ/5ugjYg=; b=Tr4IIniSASqBzEh40IhrZhlKWFV8gcyMn5spQ+uTrFsIldEFeskL9vCl l8BPTQUsDeZC8HdVJOigysD5zBxq6fezYcJ2EgEXSA1oQ4BJ3w0GFa9gS q4T9jVBFMnJG8FWJlZfCmOYR3sCf8ogoeUhWiTvwSCQxePlHyit2l2NBu E=; IronPort-PHdr: =?us-ascii?q?A9a23=3AlJnPVRwlWbY4J0zXCzM7ngc9DxPP8536IxII8?= =?us-ascii?q?Jc4hrMIeaOmrNzuP03asPNqilKBHYDW8OlNhOeetaf8EXcB7pCMvDFnEtRMW?= =?us-ascii?q?hYJhN9Qk1kmB8iIWkPmMOPwYjM3HYJJU1o2t32+OFJeTcD5YVCaq3au7DkUT?= =?us-ascii?q?xP4Mwc9Jun8FoPIycqt0OXn8JzIaAIOjz24MttP?= IronPort-Data: =?us-ascii?q?A9a23=3A3qMiDqqeVDqPwehKMTJRUtthAiheBmLNZxIvg?= =?us-ascii?q?KrLsJaIsI4StFCztgarIBnQbqqIN2LwKN93bduxpB4B75fWnd9rHQE5rHoyF?= =?us-ascii?q?y4T9uPIVI+TRqvS04x+DSFioHqKZKzyU/GYRCwPZiKa9krF3oTJ9yEmjPjQH?= =?us-ascii?q?uqkUoYoBwgoLeNaYHZ54f5cs7ZRbr5A2bBVMivV0T/Ai5S31GyNg1aYBlkpB?= =?us-ascii?q?5er83uDihhdVAQw5TTSbdgT1LPXeuJ84Jg3fcldJFOgKmVY83LTegrN8F251?= =?us-ascii?q?juxExYFA9ehlPPwdVcHB+WUNgmVgX0QUK+n6vRAjnVtieBgarxFMgEO0Gvhc?= =?us-ascii?q?9NZkL2hsbS1QAEqN6jNg8wWUgJTFGd1OqguFLrvcCHv7pzMkBKaG5fr67A0Z?= =?us-ascii?q?K0sBqUD4vx2B24L/vwRKSoWRhGOm+zwx6i0IsF3nt4iKsbDPY4DtDdn1z6xJ?= =?us-ascii?q?fQvRJ3YBaOM6sJZ1zc5nMxmE+vCetAUdjduKh/HZnVy1v0/YH4ltO6sgn+6e?= =?us-ascii?q?DpCpRfO46E2+GPUigd21dDQ3BPuUoTiba1ocoyw/woqJ1jEPyw=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AibeEOaFKsGVlKdPWpLqFSpHXdLJyesId70?= =?us-ascii?q?hD6qkvc31om52j+fxGws516fatskdvZJkh8erwX5VoMkmsi6KdgLNhfItKOT?= =?us-ascii?q?OHhILGFvAY0WKP+UyEJ8S6zJ8g6U4CSdk/NDSTNykBsS+S2mDReLxMrKjlgc?= =?us-ascii?q?KVbKXlvgpQpGpRGsddBnJCe36m+zpNNXB77PQCZf6hz/sCgwDlVWUcb8y9CH?= =?us-ascii?q?VAdfPEvcf3mJXvZgNDLwI76SGV5AnYq4LSIly95FMzQjlPybAt/SzuiAri/J?= =?us-ascii?q?iutPm911v1y3LT1ZJLg9Hso+EzRvBky/JlbwkEuDzYI7iJaIfy+gzdZ9vfsW?= =?us-ascii?q?rCpeO85yvI+f4Ds085MFvF+icFkDOQoQrGo0WSuWNwx0GT+/AQgFkBepZ8bU?= =?us-ascii?q?UzSGqF16NohqAO7Itbm22erJZZFhXGgWD04MXJTQhjkg6urWMlivN7tQ0TbW?= =?us-ascii?q?IyUs4bkWUkxjIeLH7AJlOM1Kk3VO11SM3M7vdfdl2XK3jfo2l02dSpGnA+BA?= =?us-ascii?q?2PTEQOstGcl2E+pgE382IIgMgE2nsQ/pM0TJdJo+zCL6RzjblLCssbd7h0Cu?= =?us-ascii?q?sNSda+TmbNXRXPOmSPJkmPLtBKB1vd75rspLkl7uCjf5IFiJM0hZTaSVtd8X?= =?us-ascii?q?U/fkr/YPf+lKGjMiq9CVlVeA6dhP22y6IJz4EUdYCbRxFrEmpe4fdIi89vdv?= =?us-ascii?q?HmZw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BWAACYvWBh/4gNJK1aHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUUHAQELAYEgMCMuB3daNzGIDgOEWWCICQOVZoUGgS4UgRE?= =?us-ascii?q?DVAsBAQENAQE3CgQBAYR+AoJIAiU0CQ4BAgQBAQESAQEFAQEBAgEGBIERE4U?= =?us-ascii?q?7CCUNhkIBAQEBAxILEBMBASwLAQ8CAQgRAwECJAsyHQgCBAENBQgTB4JQgX5?= =?us-ascii?q?XAy8BDqFtAYE6AoofeIEzgQGCCAEBBgQEgUpBgn8YgjUDBoE6AYMAhBOGdSc?= =?us-ascii?q?cgUlEgRVDgmc+gmMCA4EjBQESASMeDYMiggwiinovQmQEGzggAlkWgQIqESm?= =?us-ascii?q?eCo1MkioKgzCKRpRBFINqi2yGRZB7hxOPEoxNmHgCBAIEBQIOAQEGgWE7aXB?= =?us-ascii?q?wFTuCaVEZD4M+imIMFhUZgyKFFIVKdAI2AgYLAQEDCZRxAQE?= X-IronPort-AV: E=Sophos;i="5.85,358,1624320000"; d="scan'208,217";a="918787774" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Oct 2021 21:56:18 +0000 Received: from mail.cisco.com (xbe-rcd-005.cisco.com [173.37.102.20]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 198LuIfx012327 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 8 Oct 2021 21:56:18 GMT Received: from xfe-rtp-003.cisco.com (64.101.210.233) by xbe-rcd-005.cisco.com (173.37.102.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 8 Oct 2021 16:56:18 -0500 Received: from xfe-rtp-001.cisco.com (64.101.210.231) by xfe-rtp-003.cisco.com (64.101.210.233) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 8 Oct 2021 17:56:17 -0400 Received: from NAM02-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-001.cisco.com (64.101.210.231) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Fri, 8 Oct 2021 17:56:17 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ch8URMsjMM2NuDg2/n231827vCWQgExENiSAkqBLB9egNPGDoxqApBFSvth/ndMb89JOCUGkapPBeDbU3gjj55zvM3Mp8UpgUVIHoZ40mzNnIZ0/WQBUgHDCe7eVQ80QXlzRkTmct5o4Pbggb8VpDe3OPGMa9a41lqfopGjlrr3VZ9vroZBw50xMeQq189QtRufxjNAobyq3Ver6wvCdXBc+4RyRiEa17fd/FPQn5Y0UM/w8S22/V95vrVYPCEAsES1GHu2jIMht82Abq92ONBI5mna1qEdsdqf5w6qsrxrpW+uLfRUwZX3rNppT273UyD7hvq4KnMKBMAKLkOA67Q== 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=MG0saQLawqo7G3kQbddYLPOS3e/Zs0FNKLo1DXX8azQ=; b=G7YUojHHJYIEaXEsDgiPRbjl+NMYpQuAdxOE8ovfAVebptPX5yRt3YZdWAhAHSAbOOuSVxJc38IIs+dl9voOafksgxswfHKMLF4KIORzOJFGVn32JstIfmc7qwJYecXObdTRs1UTcHP8ytKKZ+6fG1bu4Es6R8fYqQsA9P3Z4baJRwA0+UEias+hUmRskgSxPDPicUR6y7VLT/75YJpGW3I4SpG4ROMpiRmAFBEquTjZ09wMzyUV6W50jbsndfYSVQVwCMHM5dMS+8Tfin3MLqbjdnSv69avsEEjUKrxoyKV3YLEzTsoQZRiH5TRClGJCxmbfvqIsH40+QxfHmogGg== 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=MG0saQLawqo7G3kQbddYLPOS3e/Zs0FNKLo1DXX8azQ=; b=Ia/5vhHaU9rTMUCAq+ANtxyP4H8mbrsR9nTjHE0siu/LjMcPTGzDNunNbCMONqGyCKyNiwOXelLAmWnySDJI388Fpcb1gh+RkbV5ehtpwB2jnCVZLSy9zr86tzJ2NHy1ni+jkTg5Sc3FeXqqS5R5n1AzwI21xvlO3d5cbXeOnQI= Received: from BYAPR11MB2725.namprd11.prod.outlook.com (2603:10b6:a02:c5::25) by BYAPR11MB3766.namprd11.prod.outlook.com (2603:10b6:a03:b5::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4566.22; Fri, 8 Oct 2021 21:56:14 +0000 Received: from BYAPR11MB2725.namprd11.prod.outlook.com ([fe80::fc33:27d4:8b6e:888c]) by BYAPR11MB2725.namprd11.prod.outlook.com ([fe80::fc33:27d4:8b6e:888c%5]) with mapi id 15.20.4587.020; Fri, 8 Oct 2021 21:56:14 +0000 From: "Mankamana Mishra (mankamis)" To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: AQHXuWpoWkD3gfXwMEmJFeeQeppARavJq2+h Date: Fri, 8 Oct 2021 21:56:14 +0000 Message-ID: References: <71EFCBC8-A8A6-4A0F-A30F-2EB0C9760D3F@bell.ca> In-Reply-To: <71EFCBC8-A8A6-4A0F-A30F-2EB0C9760D3F@bell.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 59ab3c6a-cdea-4eab-be14-08d98aa672a8 x-ms-traffictypediagnostic: BYAPR11MB3766: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dl07SjyMEcs2ypJ4WAF/21UKVpQ0xF9vdOLGJsLP7AidzrGdBIEv+hcxCHeFP+WtDy+tjs28iIZGf+P7r5EoV+YLpiGasBYCv10JWCZe42wOI64fymVoShOpvakkVaYuVgk68mT3PYbuv5AErx5eRA7r8mcz7W68QxGtIHPMSg0V6PbW/i51zJv2U9qElt3aujLZq69DXUPTJ1hPwqvBx0cOE+VawfaitgFF86woTBQPXa+Ee9+lj3/0E+CzMyIPWrHa9sa765u/w1qG9ZRHfIJ+0yxwx1Wl6umvayFayjJpuBsTt+Hy6mc1R2KYKVCLymyxHOsLbKpTxjXK84OsJMsa/h4g32gyPeIWMVUiDZZxTjnqnwfQPElIE3iccz7Kx0vEsq4G0zdB3F/nIwMlWLeNWM1elIkR0QjunMQNeA+87JZTJGOfTBIqHYCx6lpAWEajvxLoxxHpGjtio2xFnoQPr2BGG/DDaao/2bNjNL+lf9b2TQ7hpIgzUmx260tlO2gJbXIasPtjiCwlmqrFI/hz2htQHypEyZCo+z5YNSkcKFd+pILhRZ50akFDRrZGb6fx9/ltkPSqF3tzVdSmw8DOpLKEsPCYo6kw1DzhKVrwKZQSpasndvxsXE8NkaxzZDF6ph5skX67S9+xVA/Vp4Uj8o7bjh6jgrICnL8UNdHyicKkikmOHexZaIA9RdgggC+qauom3jGtI0D9za2VO3H2f+g4eX0OyZaQ0UMQOOQ5TpKWyXAHdB3sIJneKrAW86F38kMY9M2UvP8LonpVMT1bfTB8OEW1fJkumf6IGB8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR11MB2725.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(64756008)(66556008)(66476007)(38100700002)(122000001)(83380400001)(66446008)(53546011)(6506007)(71200400001)(52536014)(5660300002)(38070700005)(4326008)(2906002)(33656002)(966005)(508600001)(166002)(8676002)(316002)(9686003)(186003)(55016002)(8936002)(110136005)(7696005)(76116006)(66946007)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?OP3Zu7//mIHI2y77UgVGAvflWmAwcACP4XGevS1UYWCxZfYzEGj95YyJ?= =?Windows-1252?Q?KQO/c9Ut4bBHkA1wfmBopsF2uLDqt0Li2+J+u4OkNWC8W1fFcXH740Cd?= =?Windows-1252?Q?Fu2L7KTDt40YYZMZGF+pykrIqGrYYaN+PBfA5sbxzd/UBEFSU1MVarES?= =?Windows-1252?Q?P7OBI+IJbSB0pMRvrPpsrUfOHaSJr4kSDLqnOlXjgOLwDdihFuzlUGcR?= =?Windows-1252?Q?lliqAd518qFXnWSzfe8sO5ACNT2gDesgBF71bKldnBJ4NwAwp9oeoGis?= =?Windows-1252?Q?KbDDSDFkyN1mxsjloKNm3FIg5Qim5lbVywbpJstnmabRT0egVKbk9p1H?= =?Windows-1252?Q?X0/Tmn6n0mXVv6ofU2yDCj5ySJkNEXuejyAdNwPCQzojtHSoHEfMLoB+?= =?Windows-1252?Q?WNn5ckPkVt/lSgfSdIUpdbWJJGuZZgtyqJMy4M2j6c67nLP8RplB83Ix?= =?Windows-1252?Q?K/BYtvHuuCdSyjn92CE4uj0KOI8OvYLk7Jqocs7UdxlRlscwmXNLK3+k?= =?Windows-1252?Q?I6CzBiMprtLuG55VCytvvQpqMlYkY0l/5GAjX0ev1UmyXcFwfVDhKYkz?= =?Windows-1252?Q?aTBjRlH2zOubgzP+9UthbrEvZHKSfzqMaFns2gQmQDnErZamSbhG7Eh9?= =?Windows-1252?Q?u2P+FGCus1W8878kJEF78PoMlV/ymvYXD3vYeHyObs/UD9+DwHRdjQTS?= =?Windows-1252?Q?c2tTgmn18fEEpn1AsrV+kWeI4TAV3NUhL8WfXvhkwbVsZFC/3d6zzePr?= =?Windows-1252?Q?jXI1eFqq3FJWD95djwslIXYySxggNeTXXN8W3kG4zyvwskYnNPgYTWcn?= =?Windows-1252?Q?MG2d6jYTJtQrgMepBlJqVcxNbA71BDv9P8zOTpB+1pP03VGVAtFko/58?= =?Windows-1252?Q?8BO2xaL27OX0+5rR7WO/SxSaMF/AOqOCUZ+mk2Kr98u68EKIPzWS7HQE?= =?Windows-1252?Q?ZiLrp3bIIlJtyrJXXc9/GzcurFpBCjiwVc/79mCI6T3JwcvyI/F8uGBa?= =?Windows-1252?Q?MboxEka7z4qzCo/Rh+53UXmzzm8CtrL+AwFneP36pliXs2g54Hr4OdZq?= =?Windows-1252?Q?NAvsO5hD+3FFa+CT0CuFWsaWOm1FcwmxN+FPmst7E4+75NbCIUuIaPSU?= =?Windows-1252?Q?+e1WO+sIgnN9Uy0TF5Tspv4/njyuehdB71D7VuPTi6V0gLXhcDxLi+9o?= =?Windows-1252?Q?Eajcbr8/Smivmpgp7DztiWCi2q25eDiDgXyMy4jykUjmmxzObKondZ17?= =?Windows-1252?Q?lOiimk9XyZqCDyDwGgUkgNOX9+bE9eW9ieBOd2L/O0Q4jp6x/0yJl2vl?= =?Windows-1252?Q?dR8d6x5XztLEkwkF4JVJ6srFFkvz+8lAhHg3yLmnyteHSUEAy6dcP88k?= =?Windows-1252?Q?/jQDSEVc7i/sluaXcZtgA3BLmos7BAnFCs7aYdD31T+QXVNyc3MQfnRA?= =?Windows-1252?Q?w567WjttGfcAP5PQqBwSJF2LtTCkr41U/dCM2560iNDivbTKUGd55zZT?= =?Windows-1252?Q?bzoJmo1jtO09XIuELG2OZXrufrDUaA=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BYAPR11MB27254DD0CE7BEA35DE5E9901DFB29BYAPR11MB2725namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR11MB2725.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 59ab3c6a-cdea-4eab-be14-08d98aa672a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Oct 2021 21:56:14.1571 (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: 5IVomWaMOlyM8MPBKlxlGf2gCxVowXbAmeRwbfJc50VF5HgrmI0UTd7+alt9eD/aZW1Ct6U8URaDf2KuLG8gzQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3766 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xbe-rcd-005.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 08 Oct 2021 21:56:27 -0000 --_000_BYAPR11MB27254DD0CE7BEA35DE5E9901DFB29BYAPR11MB2725namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I have read the draft-filsfilscheng-spring-srv6-srh-compression, and it is= a single SRv6 data plane compliant solution with the next and replace flav= ors added for the SRv6 compression. I strongly support the WG adoption of the draft. Mankamana From: spring on behalf of James Guichard Date: Friday, October 1, 2021 at 10:05 AM To: SPRING WG Cc: "spring-chairs@ietf.org" Subject: [EXT][spring] WG Adoption call for https://datatracker.ietf.org/do= c/draft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a =93living=94 document; it may change as it goes thr= ough review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_BYAPR11MB27254DD0CE7BEA35DE5E9901DFB29BYAPR11MB2725namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    I have read the draft-fi= lsfilscheng-spring-srv6-srh-compression, and it  is a single SRv6 data= plane compliant solution with the next and replace flavors added for the S= Rv6 compression.

     =

    I strongly support the W= G adoption of the draft. 

     

    Mankamana

    From= : spring <spring= -bounces@ietf.org> on behalf of James Guichard <james.n.guichard@futu= rewei.com>
    Date: Friday, October 1, 2021 at 10:05 AM
    To: SPRING WG <spring@ietf.org>
    Cc: "spring-chairs@ietf.org" <spring-chairs@ietf.org>= ;
    Subject: [EXT][spring] WG Adoption call for https://datatracker.ietf= .org/doc/draft-filsfilscheng-spring-srv6-srh-compression/    =

     

    Dear WG:

     

    The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

     

    The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

     

    Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

     

    1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors.
    2. The document is a =93living=94 document; it may chang= e as it goes through review and analysis by the SPRING working group.
    3. All open discussion points raised on our mailing list= MUST be addressed BEFORE said document is allowed to progress from the wor= king group to publication. A list of these discussion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
    4. If this document is adopted by the working group, the= chairs specify as part of the adoption call that the following text descri= bing an open issue be added to the document in the above-described open issues section:
      • "Given th= at the working group has said that it wants to standardize one data plane s= olution, and given that the document contains multiple SRv6 EndPoint behavi= ors that some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

     

    Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    --_000_BYAPR11MB27254DD0CE7BEA35DE5E9901DFB29BYAPR11MB2725namp_-- From nobody Fri Oct 8 20:14:23 2021 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 527703A0FFD; Fri, 8 Oct 2021 20:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 GW5pg1fS2itt; Fri, 8 Oct 2021 20:13:50 -0700 (PDT) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (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 6FDE33A0FFA; Fri, 8 Oct 2021 20:13:50 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id g184so4891280pgc.6; Fri, 08 Oct 2021 20:13:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=bH+oJRaj7MRkeXkaWYQlAoFzqlhL9RkPdTAEcsKg44I=; b=lE00h7vaZGTrixeUCtsJtS83L/rRLDNMzMFt03LLpGJ268+nK95Wg0WV7tsvNujaLI uX0etscZyC8wCPH0vquyQkgLPzLYEAs+s6Jbn7Gd9ruWlwEh5Ju5QEyxPmuzoN9Po9N3 azwveKBqKLKxhrp6gp4HcCx0bT0RtYOAZeAG4XAWc4g5OYgaM6vG76yxlbNEPPRtGTH1 2W0c5w1X0tTfva6D31byafaQPx0gKcryY7MGt/Od8jd3RiUp9WeVWxODF5zPiknCGitq Rb0UvRjG3/1uAj+1/nXdhbSd73gqLGruDeh7FhIMeT5Kf3/HE1TbUymr2nw3Au9o0mwq eduw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=bH+oJRaj7MRkeXkaWYQlAoFzqlhL9RkPdTAEcsKg44I=; b=JoG2yhGmqvjtNJmNEygpzyit6Vbsrnfkjt1XV5g3hwKU871H3zLCkcFbGGb2qmOuGI M+FJjMWmTz0eEOOjUbMVD1IrUASJ7CK6af+mmg6LlGrMZFQZCkMfgvbet6TxCV8Cbxkh xDCMoDTnZ5PWhffGkOwtD2+SsEdDHoXBgA4M2TaqVU5qXVoLxTUenU79gN0lAOwLoZuo Am84Bn/ZDZG8jpFWXe1pt9AgK8MzPc2rz01fmPxroYIGggp0JPcq91YfGSeH9ZqJaU13 bg6SMfxN+1Ped6eBAj68CTYVVKweAOfo81/bUDllPV8pC4I2yiKwqwcFWQPo0ZNJ2hdf +BUw== X-Gm-Message-State: AOAM532vXAftMcag1gSVUbDHes60LVqxz5QS6X3IkMksbeEuX1tPcZXu H+odJ0wGmp3+0UtX8BFnFPU9gZljS1d2lw== X-Google-Smtp-Source: ABdhPJzWd/H7gyxfmrWORKQe4f03fnAXMtRDAz3+8b7Bjf8fbb5BxlmYGoep7ThBkh80ceAR84WDfA== X-Received: by 2002:aa7:8e4b:0:b0:44c:77f9:9000 with SMTP id d11-20020aa78e4b000000b0044c77f99000mr13298437pfr.7.1633749229265; Fri, 08 Oct 2021 20:13:49 -0700 (PDT) Received: from ?IPv6:2406:e003:1018:b901:db7:d041:a2d:ce65? ([2406:e003:1018:b901:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id w11sm699524pgf.5.2021.10.08.20.13.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Oct 2021 20:13:48 -0700 (PDT) To: Vasilenko Eduard , Tom Herbert Cc: Ron Bonica , SPRING WG , 6MAN <6man@ietf.org> References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> <423b08d46294454d9a9625990ce52acb@huawei.com> From: Brian E Carpenter Message-ID: <322a8c29-e232-a39d-94ca-9c9cbf09c8d2@gmail.com> Date: Sat, 9 Oct 2021 16:13:44 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <423b08d46294454d9a9625990ce52acb@huawei.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 03:13:53 -0000 On 09-Oct-21 06:03, Vasilenko Eduard wrote: > Hi Tom, >=20 > It is not related to CSID. Because it is not important how IP address i= s prepared, it should be IP address at the time of writing to DA field. A= nd it is. >=20 > =C2=A0 >=20 > You are asking more general question: what was the legal reason to trea= t IPv6 address as LOC:FUNCT:ARG? That is not incompatible with the addressing architecture as long as the = locator is 64 bits and any semantics of the IID =3D=3D FUNCT:ARG are loca= l. =20 > Sorry, but it is a little bit late =E2=80=93 RFC 8986 is already publis= hed. "Locators are assigned consistent with IPv6 infrastructure allocation." Which means: 64 bits. I have no time to study compressed SIDs, but if they trample on the LOC t= hey are not IPv6 addresses. Brian From nobody Fri Oct 8 22:00:59 2021 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 77A603A147E; Fri, 8 Oct 2021 22:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DkB9Rdp8YLFf; Fri, 8 Oct 2021 22:00:52 -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 87D3C3A147D; Fri, 8 Oct 2021 22:00:52 -0700 (PDT) Received: from fraeml745-chm.china.huawei.com (unknown [172.18.147.200]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HRCTd3YZWz67ZJR; Sat, 9 Oct 2021 12:57:09 +0800 (CST) Received: from dggeme703-chm.china.huawei.com (10.1.199.99) by fraeml745-chm.china.huawei.com (10.206.15.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.8; Sat, 9 Oct 2021 07:00:47 +0200 Received: from dggeme754-chm.china.huawei.com (10.3.19.100) by dggeme703-chm.china.huawei.com (10.1.199.99) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.8; Sat, 9 Oct 2021 13:00:45 +0800 Received: from dggeme754-chm.china.huawei.com ([10.6.80.77]) by dggeme754-chm.china.huawei.com ([10.6.80.77]) with mapi id 15.01.2308.008; Sat, 9 Oct 2021 13:00:45 +0800 From: "Dongjie (Jimmy)" To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQF84K4Q Date: Sat, 9 Oct 2021 05:00:45 +0000 Message-ID: <7e1cf0ac7a9b47229335c264c6274e57@huawei.com> References: 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.40.66] Content-Type: multipart/alternative; boundary="_000_7e1cf0ac7a9b47229335c264c6274e57huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 09 Oct 2021 05:00:58 -0000 --_000_7e1cf0ac7a9b47229335c264c6274e57huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I've read the latest version of this document and found it provides practic= al mechanisms for SRv6 compression. It is in the right direction and the ma= turity has reached the bar for WG adoption. Thus I support the adoption of this document. Best regards, Jie From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard Sent: Friday, October 1, 2021 10:05 PM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_7e1cf0ac7a9b47229335c264c6274e57huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    I’ve read the latest version of this document and found it = provides practical mechanisms for SRv6 compression. It is in the right dire= ction and the maturity has reached the bar for WG adoption.

     

    Thus I support the adoption of this document.

     

    Best regards,

    Jie

     

    From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard
    Sent: Friday, October 1, 2021 10:05 PM
    To: SPRING WG <spring@ietf.org>
    Cc: spring-chairs@ietf.org
    Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

     

    Dear WG:

     

    The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a sol= ution for SRv6 compression.

     

    The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

     

    Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

     

    1. The SPRING working group is adopting a document that has multiple SRv6 = Endpoint behaviors.
    2. The document is a “living” document;= it may change as it goes through review and analysis by the SPRING working= group.
    3. All open discussion points raised on our mailing= list MUST be addressed BEFORE said document is allowed to progress from th= e working group to publication. A list of these discussion points will be documented in the WG document and maintained by the document edito= r in conjunction with the chairs.
    4. If this document is adopted by the working group= , the chairs specify as part of the adoption call that the following text d= escribing an open issue be added to the document in the above-described open issues section:
      • "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution obj= ective.".

     

    Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open d= iscussion points you would like addressed should the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    --_000_7e1cf0ac7a9b47229335c264c6274e57huaweicom_-- From nobody Sat Oct 9 02:19:13 2021 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 474623A00AD; Sat, 9 Oct 2021 02:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 FY1X2_QJu3gV; Sat, 9 Oct 2021 02:19:06 -0700 (PDT) Received: from mail-yb1-xb41.google.com (mail-yb1-xb41.google.com [IPv6:2607:f8b0:4864:20::b41]) (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 43B593A00C3; Sat, 9 Oct 2021 02:19:06 -0700 (PDT) Received: by mail-yb1-xb41.google.com with SMTP id n65so26314342ybb.7; Sat, 09 Oct 2021 02:19:06 -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=En59wD0C/fJQLq7ve7bGB7Ong9ylMqJLcGDZb64JUmg=; b=dBQWRjcsvGKWDvVEMI0ZudBpZUvkbqF8QGDal32tud11LkuxBz2muFYFhku5WV6iFt 3VRNBOMPi4M8zd0L1eSg2TI6rHd+fci5XnOEgnq/LN96MDQlwyfT+xNGy/JIOBLgi1ZV /LkwGQbFyIkRotjIwdN4ujRK30IZpGN2+Wb8vXIEWhW06dzqg6EIVgqsQSG0AGkKVwrx QT8eT8//h7xcKQupqYZ2E6c0kAQv6wOo5ssHE5oS1iie7QF4FrqoGD1YqVFcgK/Jr/5M T5pvR4OmnAdPFTV6Oh6JxVwV728N4iWDRkrVF1Vy3pGqlsQKsu/3qEBUG4nfKX92pgPK UBuw== 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=En59wD0C/fJQLq7ve7bGB7Ong9ylMqJLcGDZb64JUmg=; b=ZsBzWGmvXpzpKzHK2RG5uirpYd8oPQD+NZyhZJHjCRgTYe+SCKFWZEIOatnDVPN/fF OUy8aQmDkvzhpirA/HeulRlstG1jzluHx/P1Mq97McsdDCPirbzo98BKgmCD9a+/aTiI 7TtqiZE1SE/G+yf2RPiyYy3cIqTs94nOlNC0g38N85tbYCZei5exFkNSAwWIZpR5Wklc 19vYydpWXRKLefMeXICWhz51nL52xZAeuaQw3BL0dZxWBXZA5TZo4oGy0J+jWljXBRJo n2dPl+dASiGVbfRYA90AIYJeJHUeM0U5ZeqlZptIMIBif6f9WXSVYpunTgQQhJQydEfW +7Kg== X-Gm-Message-State: AOAM531GA1daIn78ENW4kT8N/QbPQyrIPSOjs/ny2ckbTKYPCyNot1Bc YPSXgUUPcxnZTNXk4vdzZVO09lGvly621K7JASNHuJjJ9a0v2g== X-Google-Smtp-Source: ABdhPJxs46Zl+drT8+coD8NnHKoiasHfJrqptMhe/gP0NYTdwp39C26a8sytOyb9wyoG3L0aRJMwNtM/O3NsOeVIMzs= X-Received: by 2002:a25:db0b:: with SMTP id g11mr8444018ybf.285.1633771144760; Sat, 09 Oct 2021 02:19:04 -0700 (PDT) MIME-Version: 1.0 From: zhen han Date: Sat, 9 Oct 2021 17:18:53 +0800 Message-ID: To: SPRING WG , James Guichard Cc: "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ba543105cde7fc1a" Archived-At: Subject: [spring] =?utf-8?q?Re=EF=BC=9A_WG_Adoption_call_forhttps=3A//dat?= =?utf-8?q?atracker=2Eietf=2Eorg/doc/draft-filsfilscheng-spring-srv6-srh-c?= =?utf-8?q?ompression/?= 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, 09 Oct 2021 09:19:11 -0000 --000000000000ba543105cde7fc1a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi WG=EF=BC=8C CSID is recommended by the DT after wide and long discussions, it could provide best compression efficiency and is based on SRv6 data plane. Regarding the concerns=EF=BC=8Cinterop was done to prove it is a single dat= a-plane based solution. After checking the draft, according to my understandings shown below=EF=BC= =9A - CSID is ready to serve as the basis for the SRv6 compression solution= =EF=BC=9B - CSID is an SRv6 dataplane solution=EF=BC=8Cso it is coherent with one = data plane solution objective=EF=BC=9B - CSID meets SRv6 compression requirements. I think the draft is good enough now. So=EF=BC=8CI support the adoption of this document=EF=BC=8Cand also look fo= rward to the next step . Best Regards=EF=BC=8C Zhen HAN (Fiberhome) =E5=9C=A8 2021=E5=B9=B410=E6=9C=881=E6=97=A5 22:04=EF=BC=8CJames Guichard =E5=86=99=E9=81=93=EF=BC=9A Dear WG: The chairs would like to express their appreciation for all the responses received to our emails with reference to how the working group wishes to move forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is part of what this email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv6 Endpoint behaviors. 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change as= it goes through review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be addressed BEFORE said document is allowed to progress from the working group to publication. A list of these discussion points will be document= ed in the WG document and maintained by the document editor in conjunction with the chairs. 4. If this document is adopted by the working group, the chairs specify as part of the adoption call that the following text describing an open issue be added to the document in the above-described open issues sectio= n: - "Given that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this is valid and coherent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or not this WG adoption. Please express clearly your reasoning for support/non-support as well as any open discussion points you would like addressed should the document be adopted into the working group. Thanks! Jim, Bruno & Joel --000000000000ba543105cde7fc1a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi WG=EF=BC=8C

    CSID is recommended by the DT after wide and long discussions, it could=20 provide best compression efficiency and is based on SRv6 data plane.
    <= div style=3D"font-size:14px">Regarding the concerns=EF=BC=8Cinterop was don= e to prove it is a single data-plane based solution.

    After checking the dra= ft, according to my understandings shown below=EF=BC=9A
    • CSID is ready to serve as the basis for the SRv6 co= mpression solution=EF=BC=9B
    • CSID is an SRv6 dataplane solution=EF= =BC=8Cso it is coherent with one data plane solution objective=EF=BC=9B
    • CSID meets SRv6 compression requirements.
    I think the draft is good enough now.=C2=A0

    So=EF=BC=8CI s= upport the adoption of this document=EF=BC=8Cand also look forward to the n= ext step .

    Best Regards=EF=BC=8C
    Zhen HA= N=C2=A0(Fiberhome)

    =E5=9C=A8 2021=E5=B9=B41= 0=E6=9C=881=E6=97=A5 22:04=EF=BC=8CJames Guichard<james.n.guichard@futurewei.com> =E5=86= =99=E9=81=93=EF=BC=9A

    Dear WG:

    =C2=A0

    The chairs would like to express their appreciation for all the responses received to our emails with reference to how the=20 working group wishes to move forward with respect to a solution for SRv6 compression.

    =C2=A0

    The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

    =C2=A0

    Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support for=20 adoption of this document you are fully aware of and are acknowledging=20 that:

    =C2=A0

    1. The SPRING working group is adoptin= g a document that has multiple SRv6 Endpoint behaviors.
    2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change as= it goes through review and analysis by the SPRING working group.
    3. All open discussion points raised on our mailing list MUST be addressed=20 BEFORE said document is allowed to progress from the working group to=20 publication. A list of these discussion points will be documented in the WG document and maintained by the=20 document editor in conjunction with the chairs.
    4. If this document is adopted by the working group, the chairs specify as=20 part of the adoption call that the following text describing an open=20 issue be added to the document in the above-described open issues section:
      • "Given that the working group has said that it wants to standardize one data plane=20 solution, and given that the document contains multiple SRv6 EndPoint=20 behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether=20 this is valid and coherent with its one data plane solution objective."= ;.

    =C2=A0

    Please consider the above guidelines as you decide= =20 on whether to support or not this WG adoption. Please express clearly=20 your reasoning for support/non-support as well as any open discussion=20 points you would like addressed should the document be adopted into the working group.

    =C2=A0

    Thanks!

    =C2=A0

    Jim, Bruno & Joel

    =
    --000000000000ba543105cde7fc1a-- From nobody Sat Oct 9 02:27:49 2021 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 587693A00B2; Sat, 9 Oct 2021 02:27:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jS6US4_nVhHc; Sat, 9 Oct 2021 02:27:41 -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 5FB6E3A00C3; Sat, 9 Oct 2021 02:27:41 -0700 (PDT) Received: from fraeml715-chm.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HRKPt6CLJz67bhN; Sat, 9 Oct 2021 17:24:18 +0800 (CST) Received: from dggpemm500004.china.huawei.com (7.185.36.219) by fraeml715-chm.china.huawei.com (10.206.15.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Sat, 9 Oct 2021 11:27:36 +0200 Received: from kwepeml500002.china.huawei.com (7.221.188.128) by dggpemm500004.china.huawei.com (7.185.36.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Sat, 9 Oct 2021 17:27:34 +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.008; Sat, 9 Oct 2021 17:27:34 +0800 From: "Xiejingrong (Jingrong)" To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQGI42dA Date: Sat, 9 Oct 2021 09:27:34 +0000 Message-ID: References: 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: multipart/alternative; boundary="_000_d315d20059bc48b78b7ae8a135692878huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 09 Oct 2021 09:27:47 -0000 --_000_d315d20059bc48b78b7ae8a135692878huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG, I have read the polling draft. I think it provides a valid solution for SRv6 SID list compression in a sim= ple way Compatible with SRH 8754 and SRv6 PGM 8986, and thus I support the = adoption. Thanks Jingrong From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard Sent: Friday, October 1, 2021 10:05 PM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_d315d20059bc48b78b7ae8a135692878huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi WG,

     

    I have read the polling draft.

    I think it provides a valid solution for SRv6 SID list compressio= n in a simple way Compatible with SRH 8754 and SRv6 PGM 8986, and thus I su= pport the adoption.

     

    Thanks

    Jingrong

     

     

    From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard
    Sent: Friday, October 1, 2021 10:05 PM
    To: SPRING WG <spring@ietf.org>
    Cc: spring-chairs@ietf.org
    Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

     

    Dear WG:

     

    The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a sol= ution for SRv6 compression.

     

    The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

     

    Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

     

    1. The SPRING working group is adopting a document that has multiple SRv6 = Endpoint behaviors.
    2. The document is a “living” document;= it may change as it goes through review and analysis by the SPRING working= group.
    3. All open discussion points raised on our mailing= list MUST be addressed BEFORE said document is allowed to progress from th= e working group to publication. A list of these discussion points will be documented in the WG document and maintained by the document edito= r in conjunction with the chairs.
    4. If this document is adopted by the working group= , the chairs specify as part of the adoption call that the following text d= escribing an open issue be added to the document in the above-described open issues section:
      • "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution obj= ective.".

     

    Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open d= iscussion points you would like addressed should the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    --_000_d315d20059bc48b78b7ae8a135692878huaweicom_-- From nobody Sat Oct 9 04:40:09 2021 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 A40BD3A0977 for ; Sat, 9 Oct 2021 04:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Jd_vK5nVTznk for ; Sat, 9 Oct 2021 04:40:02 -0700 (PDT) Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 997F53A0976 for ; Sat, 9 Oct 2021 04:40:02 -0700 (PDT) Received: by mail-vs1-xe31.google.com with SMTP id y28so13412294vsd.3 for ; Sat, 09 Oct 2021 04:40:02 -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=MUWKBPh8s6exnRWf9+aI1XOFctejzQemFZyFSn4mP+0=; b=VBnHxR+peqS2FGCCdQKY1gadBClmLltKGOn3LJMyNpeWtGg2SG47gdMOn+W9VsWD8w V4uRsZf2NDSBjjHjX+0SR3oXaedpssfO+Z9wporp+PTD9JSWiX5L1eW+tfa51fvHRq1r plq1aLbJqCcdvAfZQrhgBncWSgwpm9RPMA3Z9VcouuAl8ASbW3OqvI3VnWXA10d9eDiL HRk0txv7wZYYbKxv7mbszfb5vHCTwahWZP2ODQWLpMsG8lyoDNdSG0PDulUjkbK7UT1A JR7/99gajmqWESUYsbR2Mas5ZslCyet0kk31T4a5evxSdwPpOrnsahDCKDSoYWUhZM30 kqpQ== 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=MUWKBPh8s6exnRWf9+aI1XOFctejzQemFZyFSn4mP+0=; b=VuaUEUUCHjbkeR9AT5jJ5qEFJcU1r//LDgi2wrYARe9bd7yLEglOWb0W+Kv3aKvwSE KsOLKMmLxwsagR4pPlKqX/B9Sl52bgBzFgozd5S5dnoJh9f0A8M7jPlBwAFX8ixQwGKb cmWiYCQr/Ew782HpxNgeV5hTBQyqXQ7et5cMWGe2qSLNzoZTzZ/wjPz1hdKE3IfidjqT Iscoqcb0oH9BbGEsaBB52hfznBf7PXY3CPmTBcCyzmu3EGkHGiMawSqeu+Q82pq8PBDl 6j1J+vnrq2LYBNHRqpJ/5AhPcAiwBx7mCMPdcRh/OK2m4ukruSKbvihq4PuymONIrYy8 v15w== X-Gm-Message-State: AOAM532WcstI01MYAqc12bnZyqexzG9jG0meSxQ5glg/4EHyrY6Ue/rd girvhb6nIAm2d885YHHEl7Ffxeq26hXahQmz0go7l3sASBtZuQ== X-Google-Smtp-Source: ABdhPJxRv3zMxQwh5G/HFCesi+Y7Dxz7qRuB/EAZnqJnYhKoMb4/E9kwq1IPCGMR1+NUI3/FJG/tQdB2mLiE3bAMM8c= X-Received: by 2002:a67:2283:: with SMTP id i125mr15740492vsi.50.1633779601122; Sat, 09 Oct 2021 04:40:01 -0700 (PDT) MIME-Version: 1.0 References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> <423b08d46294454d9a9625990ce52acb@huawei.com> <322a8c29-e232-a39d-94ca-9c9cbf09c8d2@gmail.com> In-Reply-To: <322a8c29-e232-a39d-94ca-9c9cbf09c8d2@gmail.com> From: Robert Raszuk Date: Sat, 9 Oct 2021 13:39:58 +0200 Message-ID: To: Brian E Carpenter , 6MAN <6man@ietf.org> Cc: Vasilenko Eduard , SPRING WG Content-Type: multipart/alternative; boundary="000000000000c43ec205cde9f43c" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 11:40:08 -0000 --000000000000c43ec205cde9f43c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Brian, > Which means: 64 bits. Sorry but what is so magic about /64 here ? Is this coming from the longest routable IPv6 prefix ? Sort of analogy to /24 in the IPv4 world ? Or something else ? I think LPM and CIDR techniques are pretty well established. Any fixed length of the address block with the meaning - do not use those bits inter or intra domain for anything useful even if your prefix+node can happily fit in /32 seems just dead wrong to me. And that is irrespective of any SRv6 discussion. In my books if I get allocated say /48 or /40 from RIR what I do with the remaining bits is my own business. Best, R. > > Sorry, but it is a little bit late =E2=80=93 RFC 8986 is already publis= hed. > > "Locators are assigned consistent with IPv6 infrastructure allocation." > > Which means: 64 bits. > > I have no time to study compressed SIDs, but if they trample on the LOC > they are not IPv6 addresses. > > Brian > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000c43ec205cde9f43c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Brian,=C2=A0
    =
    > Which means: 64 bits.

    Sorr= y but what is so magic=C2=A0about /64 here ?=C2=A0

    Is this coming from the longest routable IPv6 prefix ? Sort of analogy to = /24 in the IPv4 world ? Or something else ?=C2=A0

    = I think LPM and CIDR techniques are pretty well established.=C2=A0

    Any fixed length of the address block with the meaning=C2= =A0- do not use those bits inter or intra domain for anything useful even i= f your prefix+node can happily fit in /32 seems just dead wrong to me. And = that is irrespective of any SRv6 discussion.=C2=A0

    =
    In my books if I get allocated say /48 or /40 from RIR what I do with = the remaining bits is my own business.=C2=A0

    Best,=
    R.

    =C2=A0
    > Sorry, but it is a little bit late =E2=80=93= RFC 8986 is already published.

    "Locators are assigned consistent with IPv6 infrastructure allocation.= "

    Which means: 64 bits.

    I have no time to study compressed SIDs, but if they trample on the LOC the= y are not IPv6 addresses.

    =C2=A0 =C2=A0Brian


    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
    --------------------------------------------------------------------
    --000000000000c43ec205cde9f43c-- From nobody Sat Oct 9 04:56:42 2021 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 31D583A09B8; Sat, 9 Oct 2021 04:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 zhNo2VJ4N0T8; Sat, 9 Oct 2021 04:56:38 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3322B3A09B5; Sat, 9 Oct 2021 04:56:34 -0700 (PDT) X-Envelope-To: 6man@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 199BuRV0002795 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Oct 2021 12:56:28 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local To: Robert Raszuk Cc: Brian E Carpenter , 6MAN <6man@ietf.org>, SPRING WG References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> <423b08d46294454d9a9625990ce52acb@huawei.com> <322a8c29-e232-a39d-94ca-9c9cbf09c8d2@gmail.com> From: Nick Hilliard Message-ID: <147ac076-3b24-ee55-1ad7-b8da90be7030@foobar.org> Date: Sat, 9 Oct 2021 12:56:26 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.49 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 11:56:40 -0000 Robert Raszuk wrote on 09/10/2021 12:39: > In my books if I get allocated say /48 or /40 from RIR what I do with > the remaining bits is my own business. on your own network, indeed you can. It would interoperate with nothing, and no-one else would mind. But we're not talking about your basement: we're talking about a candidate for ietf working group adoption for a standards track document, and the discussion is about whether long-standing ipv6 semantics right at the bottom of the protocol stack should be broken in order to provide a minor convenience for srv6. Extraordinary asks require extraordinary justification, and certainly on 6man there doesn't seem to have been any justification provided by spring or the authors about why this change is necessary to the ipv6 protocol stack. tbh at this point, the draft seems to be a bit of a head scratcher. Nick From nobody Sat Oct 9 05:41:39 2021 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 DE3D03A0A71; Sat, 9 Oct 2021 05:41:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 yWBuL_AsZH8K; Sat, 9 Oct 2021 05:41:15 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 762F23A0A70; Sat, 9 Oct 2021 05:41:15 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id h10so5919358ilq.3; Sat, 09 Oct 2021 05:41:15 -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=GBY0lHa29PuSIEC/jRzwaVbbiIstzg+yodD9kCPCfOM=; b=N2FNIpzey8WPMHubPplhjmA2JZuD4Iq2Dv71McpN85ZEmgtqWD/ubLE/5y1Nib7QZj VTX1lNXb+pIJloDD1F8N4KUwPnB863k62mhU9f7cbTmWAj8FRWSqWUXe8DQIYyD9wM+0 QN8z6Eu+g1vEInKe2ysoLHTo9LK3nAL8U4V4TM6qj7K8wUrWmDw4OwXdo7r13HasBeKq LXGhoAjjGK0C157uN6rFDaBfVKniFtnvjbzriD177zB1qrVqBmk++DVamwjg51DLOXGD puYTv2/V75jEgpPcOWUE+2qVO3ei4JXsSQKU/AbPokDjTPm9zhkt93ylSIq6C25ei2mN SBsg== 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=GBY0lHa29PuSIEC/jRzwaVbbiIstzg+yodD9kCPCfOM=; b=XttYHhSJxxgOHIDDRceZ7VtAY/+6UzhzKf73gbd2IFTyX39Phg82nD6cTgCTjJblWd zOECzpG5CsjrU0L3OdL9HaGUBNn/NbyBxYIpdUIbjyFC/XFcz00905ZT2QvrowDBqdJI PEeUT8DXap0U7+zLsE7aKQUBcLqittAjyBpgt/r/VNS9TBeRQIqb8ozIVH1BsTD2ruu6 CkiNij8eWo2mD1cBVWM4tq/YVQlg6mtvPdq4KKIIOPV3Bh2pEyr8mhMxpTGfpTLPQaOT 4/1pQjQynQnHKipa9Ehd6GsgUB0lgKwDWMM/WAtIX0meVz8wVwHXZWYDki3whH+fv+H7 37pA== X-Gm-Message-State: AOAM532/6nOf9Ii+V4RzX53RRfE9/dl8LzqOaffFy85cJz//DHXvtb3k r0p0kvL59u+lf7SmSdplmmuRQ9OuVzevxsmh2Z4= X-Google-Smtp-Source: ABdhPJwrFaav21wGLvXPJNlihk665exUQy19sq1XOopJp+ghBFhUy6Fzor7L+EAVLusnHs0pXCqt2d1Pnmwb/JGsIG0= X-Received: by 2002:a05:6e02:198d:: with SMTP id g13mr11432619ilf.300.1633783274531; Sat, 09 Oct 2021 05:41:14 -0700 (PDT) MIME-Version: 1.0 References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> <423b08d46294454d9a9625990ce52acb@huawei.com> <322a8c29-e232-a39d-94ca-9c9cbf09c8d2@gmail.com> In-Reply-To: From: Mark Smith Date: Sat, 9 Oct 2021 23:41:02 +1100 Message-ID: To: Robert Raszuk Cc: Brian E Carpenter , 6MAN <6man@ietf.org>, Vasilenko Eduard , SPRING WG Content-Type: multipart/alternative; boundary="000000000000b7f6fc05cdeacf3e" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 12:41:20 -0000 --000000000000b7f6fc05cdeacf3e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, 9 Oct 2021, 22:40 Robert Raszuk, wrote: > Hi Brian, > > > Which means: 64 bits. > > Sorry but what is so magic about /64 here ? > > Is this coming from the longest routable IPv6 prefix ? Sort of analogy to > /24 in the IPv4 world ? Or something else ? > > I think LPM and CIDR techniques are pretty well established. > > Any fixed length of the address block with the meaning - do not use those > bits inter or intra domain for anything useful even if your prefix+node c= an > happily fit in /32 seems just dead wrong to me. And that is irrespective = of > any SRv6 discussion. > > In my books if I get allocated say /48 or /40 from RIR what I do with the > remaining bits is my own business. > Please read RFC5453. > Best, > R. > > > >> > Sorry, but it is a little bit late =E2=80=93 RFC 8986 is already publi= shed. >> >> "Locators are assigned consistent with IPv6 infrastructure allocation." >> >> Which means: 64 bits. >> >> I have no time to study compressed SIDs, but if they trample on the LOC >> they are not IPv6 addresses. >> >> Brian >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --000000000000b7f6fc05cdeacf3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Sat, 9 Oct 2021, 22:40 Robert Raszuk, <robert@raszuk.net> wrote:
    Hi Brian,=C2=A0

    > Which means: 64 bits.=

    Sorry but what is so magic=C2=A0about /64 her= e ?=C2=A0

    Is this coming from the longest routable= IPv6 prefix ? Sort of analogy to /24 in the IPv4 world ? Or something else= ?=C2=A0

    I think LPM and CIDR techniques are prett= y well established.=C2=A0

    Any fixed length of the = address block with the meaning=C2=A0- do not use those bits inter or intra = domain for anything useful even if your prefix+node can happily fit in /32 = seems just dead wrong to me. And that is irrespective of any SRv6 discussio= n.=C2=A0

    In my books if I get allocated say /4= 8 or /40 from RIR what I do with the remaining bits is my own business.=C2= =A0

    <= div dir=3D"auto">
    Please read RFC5453.



    Best,
    R.

    =
    =C2=A0
    &g= t; Sorry, but it is a little bit late =E2=80=93 RFC 8986 is already publish= ed.

    "Locators are assigned consistent with IPv6 infrastructure allocation.= "

    Which means: 64 bits.

    I have no time to study compressed SIDs, but if they trample on the LOC the= y are not IPv6 addresses.

    =C2=A0 =C2=A0Brian


    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6=
    --------------------------------------------------------------------
    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://www.ietf.org/mailman/listinfo/spring
    --000000000000b7f6fc05cdeacf3e-- From nobody Sat Oct 9 08:50:26 2021 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 5547B3A0D4F; Sat, 9 Oct 2021 08:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 hhL8hs_DrizX; Sat, 9 Oct 2021 08:50:07 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 760A03A00C0; Sat, 9 Oct 2021 08:50:07 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id i11so12270611ila.12; Sat, 09 Oct 2021 08:50: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=K7j0m0hwMnA7JioFMZpU21tMp2C/RUHodx+79cM/5AY=; b=pFtdx1dFg1ZpFECPKaQCFxwLZJZ6KeP4x5os3jUsOwxYEsIz09te4n9So3f3/ux7ze t7iQrzggnFEuwRsXfh+1IFl/Ft0dDfhoFWRQuviNJz8NvhPR/mA0Q+iVJH8G6c3whuCZ 7Nh54e0x5xTa5hM6vOeL5uFwgJZKbjIESyiXnyuuAk8dZ9qS9fyK1LzoU+S3Hss4EbMY /yHe4uq04mRBxN3ed+Rd6DeUKgEiyXviWqwsEly8XZPiG7siIL7W23g0Pj87e7S6MV2k 7V7MVI4mDyUjp7MiTdLrIKiyExr6CyVaq5dhsJhZAGQCb0uqpZ6PsVb/Y/8ZUOwZqonS rBAg== 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=K7j0m0hwMnA7JioFMZpU21tMp2C/RUHodx+79cM/5AY=; b=aO9b9X4KAtHsTjbW8UuJ8A3WO2yOutEz9YOzDYx47AW0cmeDOnz/y4+sxmuLsIpWR3 p2zpLg/qshT/yPxCV1lAowdj8ZlBrNW6Ury4L2/iZeA2wI62dP6ojol4S9+imOX6mhkk ZZre8qe7Rr8bcJa7yJHeYREaSJryrDEyxuVkO6CYFhngfQvOvLYJTa++yGx3vp+0arjk EW07r0HeiLftmgehXBtjQU2yVA8Ih1XI9W2dUusjGjoiO1G4gFwzF1V1mdBshGuZ0acv w2o5+mX7IQPLLVMXW/5fUV0ZOyPfrt/uFGized0xtPvn+Nt6N/fJQrJShDJgKfO//dX4 rWbQ== X-Gm-Message-State: AOAM532smZMZ3Wh1Y+/YAbpKxjk7p4EEOVf3AoS2enzT+r6GZTCweWqC iqzJbLb8/nvRgv+Ayq/QHqzh7YK7Khvsv5TnaP6dHV7lsHo= X-Google-Smtp-Source: ABdhPJz5hU24FZxDToXYlVoYPTrLaIO8/L0qov+Jiuz/IdS5BkKf7xcYlwrYWmTEZzyhumQxSfCbY3izDS7K6dB8CeY= X-Received: by 2002:a92:d684:: with SMTP id p4mr276604iln.288.1633794606575; Sat, 09 Oct 2021 08:50:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tony Przygienda Date: Sat, 9 Oct 2021 17:49:30 +0200 Message-ID: To: Ron Bonica Cc: "6man@ietf.org" <6man@ietf.org>, SPRING WG Content-Type: multipart/alternative; boundary="0000000000002936b105cded73d7" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 15:50:11 -0000 --0000000000002936b105cded73d7 Content-Type: text/plain; charset="UTF-8" I object adoption of this document as well based on copious amount of technical counter arguments laid out in multiple threads. Beside that it seems that to violate IETF v6 architecture documents we seem to be trampling on established standards more and more using increasingly contorted sophisms (yes, you can hijack any address architecture if you _assume_ that only /4 will be routing table entries & the rest belongs to your new interpretation of address being a chipmunk that by magic means will never ever escape a private basement until it does). Beside that as others already pointed out copiously the document content does not even seem to actually match WG consensus as recorded to my understanding --- tony On Fri, Oct 1, 2021 at 10:37 PM Ron Bonica wrote: > Folks, > > > > Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new > SID types that can occupy the Destination Address field of an IPv6 header. > See Sections 4.1, 4.2, and 4.3 of the draft for details. > > > > The SPRING WG has issued a call for adoption for this draft. > > > > It is not clear that these SID types can be harmonized with the IPv6 > addressing architecture. > > > > Does anyone have an opinion? > > > > > Ron > > > > Juniper Business Use Only > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --0000000000002936b105cded73d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable





    On= Sat, Oct 9, 2021 at 5:50 PM Tony Przygienda <tonysietf@gmail.com> wrote:
    I object adoption of= this document as well based on copious amount of technical counter argumen= ts laid out in multiple threads. Beside that it seems that to violate IETF = v6 architecture documents we seem to be trampling on established standards = more and more using increasingly contorted sophisms (yes, you can hijack an= y address architecture if you _assume_ that only /4 will be routing table e= ntries & the rest belongs to your new interpretation of address being a= chipmunk that by magic means will never ever escape a private basement unt= il it does).

    Beside that as others already po= inted out copiously the document content does not even seem to actually mat= ch WG consensus as recorded to my understanding

    -= -- tony

    On Fri, Oct 1, 2021 at 10:37 PM Ron Bonica <rbonica=3D= 40juniper= .net@dmarc.ietf.org> wrote:

    Folks,<= /span>

    =C2=A0<= /span>

    Draft-filsfilscheng-s= pring-srv6-srh-compression-02 introduces three new SID types that can occup= y the Destination Address field of an IPv6 header. See Sections 4.1, 4.2, a= nd 4.3 of the draft for details.

    =C2=A0<= /span>

    The SPRING WG has iss= ued a call for adoption for this draft.

    =C2=A0<= /span>

    It is not clear that = these SID types can be harmonized with the IPv6 addressing architecture.=

    =C2=A0<= /span>

    Does anyone have an o= pinion?

    =C2=A0<= /span>

    =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0Ron

    =C2=A0<= /span>


    Juniper Business Use Only

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
    --------------------------------------------------------------------
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
    --------------------------------------------------------------------
    --000000000000122e5f05cdef77e0-- From nobody Sat Oct 9 11:42:50 2021 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 AD3593A03FC; Sat, 9 Oct 2021 11:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 m717qgwXIVNH; Sat, 9 Oct 2021 11:42:19 -0700 (PDT) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 AEC7C3A040F; Sat, 9 Oct 2021 11:42:17 -0700 (PDT) Received: by mail-il1-x136.google.com with SMTP id r9so13638805ile.5; Sat, 09 Oct 2021 11:42:17 -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=C/54ylv/FxV2a+qaIblQwvV2Jo9vgpK5J5luy3QgFCc=; b=LG4GYIHrAVa4WCPtf0R1LkuMhZAGCi2tqUTSWoAKJ1jbBEToCPQ10akxU7gkNq92V8 NXn8Fb2WPOlHGWiUTOV59zAd9hmvihqvzQvAYoEX5yv8H4KA/8GCa942GAVlVTipdpdZ B8LCOeCQ5DY+1bdBRtFrFRRgjYHDSejeDjZibpsO75a/nniwIynDnyRg/bjn5OEuzrm3 qDlsDXOC+zZQViG7J6puNiK7WEoKGGzdZerhq1VUEWCJanaRnK5H9+XmFaWq02MkHAEp ZDWj+kgQPnsBRpIEXo4AYTbs5krF7pgK7dDpP/51BhPQwnUHHCy9r5LhcK+Bs3P4SwFZ az0w== 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=C/54ylv/FxV2a+qaIblQwvV2Jo9vgpK5J5luy3QgFCc=; b=QuVW7RYkUqcwWsd1lhc0nVbpVF4wkd1exG2H22y/+BG8ANx2IlqrhVjbDHU+AyfIVt vJtwlAEw7F6vB8hfFsrOM+SCIFeRPuqa3ngVLqz1sAMiDR2+I1cEAUNerV2onSFBoWR8 v0q5nID1LOgigHoezauQUMgmFe+uhxmxzVwDgLhsm3o2G7DttBPkdA9jyEKAgFNHxgdJ NFUDA4Yv0zAZTYm1waFgIaOH/lQqtWC5yy0ZaqGfdhoUr1G6kvjLvEvLmINxLVDwCNMO B2g7Yq96ISIDDiZ7G+nN5wXt7Y6UU6QCmsq6R0tuMK9v4H5UZedQLkfveF/rHMPLdklp lzyg== X-Gm-Message-State: AOAM531SlCew/Y4p9rAsFhsbT3F/xo/zfe1gXF6IZ4jxiSPmvaXTrNha 63QHFaW7RbhNRPlagBDUKZCuCZAjejJ2wrExShfqVnehFd4= X-Google-Smtp-Source: ABdhPJz2SSeXch0xRAKT4PjMRLWKTWzWdC9+asDwWx87kuZOTxm3um7xzM6rh7SDreANMzk4alqt0Lxj2T9Qf+nPfgc= X-Received: by 2002:a05:6e02:17ca:: with SMTP id z10mr12234807ilu.249.1633804936578; Sat, 09 Oct 2021 11:42:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tony Przygienda Date: Sat, 9 Oct 2021 20:41:39 +0200 Message-ID: To: Robert Raszuk Cc: Ron Bonica , SPRING WG , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000e087e305cdefda73" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 18:42:25 -0000 --000000000000e087e305cdefda73 Content-Type: text/plain; charset="UTF-8" As a simple example to which I already know your answer as in the usual "oh, that will never happen" is the subnet routers anycast address I think. The all zeroes have a meaning in IPv6 address space and intermediate nodes that don't know they are dealing with a chipmunk may try to do something with it, probably kill the chipmunk or maybe turn it into a fish if they are in the next to be invented "ocean limited domain" which your chipmunk should never enter. Or maybe we all should read RFC2526 and make sure THAT never happens in a chipmunk packet or if it does do we intend to remap a possible combination that can be mistaken for anycast to something else so chipmunk doesn't become a fish? Or maybe there is already a SRv6 draft I missed that declares IPv6 anycast a violation of the chipmunk limited domain. As a historical example I lived, this is all oh so clever as folks who figured out IPv6 actually did not explicitly forbid to assign the same link local on a box to all interfaces (as far my thinking goes, a significant mistake) which caused all kind of collateral for a bit actually and even today, good luck to get all the linux tools to deal properly with %eth2 without coring (and even better luck trying that with funky interface naming that linux is employing all over the place). my last email on the subject (and I reserve right to maybe be off here and there a bit, I'm not too deep into v6 and SRv6 but I've seen enough architectural and WG mistakes to see this compression draft red-zoning), let's see what the WG moves fwd' with -- tony On Sat, Oct 9, 2021 at 8:14 PM Robert Raszuk wrote: > Tony, > > > *(yes, you can hijack any address architecture if you _assume_ that only > /4 will be routing table entries & the rest belongs to your new > interpretation of address being a chipmunk that by magic means will never > ever escape a private basement until it does).* > > Let's try again ... as it seems this keeps coming back over and > over again. > > Assume I got allocated /4 from RIR and I have allocated /10 blocks to my > global sites connected over plain IPv6 Internet. I advertise those /10s via > BGP. > > What technical harm will happen to anyone if I use bits 11-128 as it seems > to fit and still send those packets via v6 Internet ? No basement, but > public Internet. > > Last time I checked bits are bits and there is either 0 or 1 in the > packets (at least till we get to quantum networking). It should be in no > one's business in the transit to look anywhere beyond /10. > > Again please limit the answer to technical issues which this will cause. > > Kind regards, > Robert > > > > > > > > > > On Sat, Oct 9, 2021 at 5:50 PM Tony Przygienda > wrote: > >> I object adoption of this document as well based on copious amount of >> technical counter arguments laid out in multiple threads. Beside that it >> seems that to violate IETF v6 architecture documents we seem to be >> trampling on established standards more and more using increasingly >> contorted sophisms (yes, you can hijack any address architecture if you >> _assume_ that only /4 will be routing table entries & the rest belongs to >> your new interpretation of address being a chipmunk that by magic means >> will never ever escape a private basement until it does). >> >> Beside that as others already pointed out copiously the document content >> does not even seem to actually match WG consensus as recorded to my >> understanding >> >> --- tony >> >> On Fri, Oct 1, 2021 at 10:37 PM Ron Bonica > 40juniper.net@dmarc.ietf.org> wrote: >> >>> Folks, >>> >>> >>> >>> Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new >>> SID types that can occupy the Destination Address field of an IPv6 header. >>> See Sections 4.1, 4.2, and 4.3 of the draft for details. >>> >>> >>> >>> The SPRING WG has issued a call for adoption for this draft. >>> >>> >>> >>> It is not clear that these SID types can be harmonized with the IPv6 >>> addressing architecture. >>> >>> >>> >>> Does anyone have an opinion? >>> >>> >>> >>> >>> Ron >>> >>> >>> >>> Juniper Business Use Only >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > --000000000000e087e305cdefda73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    As a simple example to which I already know your answ= er as in the usual "oh, that will never happen" is the subnet rou= ters anycast address I think. The all zeroes have a meaning in IPv6 address= space and intermediate nodes that don't know they are dealing with a c= hipmunk may try to do something with it, probably kill the chipmunk or mayb= e turn it into a fish if they are in the next to be invented "ocean li= mited domain" which your chipmunk should never enter.

    Or maybe we all should read RFC2526 and make sure THAT never happe= ns in a chipmunk packet or if it does do we intend to remap a possible comb= ination that can be mistaken for anycast to something else so chipmunk does= n't become a fish?=C2=A0 Or maybe there is already a SRv6 draft I misse= d that declares IPv6 anycast a violation of the chipmunk limited domain.

    As a historical example I lived, this is all oh= so clever as folks who figured out IPv6 actually did not explicitly forbid= to assign the same link local on a box to all interfaces (as far my thinki= ng goes, a significant mistake) which caused all kind of collateral for a b= it actually and even today, good luck to get all the linux tools to deal pr= operly with %eth2 without coring (and even better luck trying that with fun= ky interface naming that linux is employing all over the place).
    =

    my last email on the subject (and I reserve right to ma= ybe be off here and there a bit, I'm not too deep into v6 and SRv6 but = I've seen enough architectural and WG mistakes to see this compression = draft red-zoning), let's see what the WG moves fwd' with
    =

    -- tony

    =
    On Sat, Oct 9, 2021 at 8:14 PM Robert= Raszuk <robert@raszuk.net> = wrote:
    Tony,

    (yes, you can hijack any address archi= tecture if you _assume_ that only /4 will be routing table entries & th= e rest belongs to your new interpretation of address being a chipmunk that = by magic means will never ever escape a private basement until it does).

    Let's try again ... as it seems this kee= ps coming back over and over=C2=A0again.=C2=A0

    Ass= ume I got allocated /4 from RIR and I have allocated /10 blocks to my globa= l sites connected over plain IPv6 Internet. I advertise those /10s via BGP.= =C2=A0

    What technical harm will happen to anyone i= f I use bits 11-128 as it seems to fit and=C2=A0still send those packets vi= a v6 Internet ? No basement, but public=C2=A0Internet.=C2=A0

    =
    Last time I checked bits are bits and there is either 0 or 1 in = the packets (at least till we get to quantum networking). It should be in n= o one's business=C2=A0in the transit to look anywhere beyond=C2=A0/10.= =C2=A0

    Again please limit=C2=A0the answer to techn= ical issues which this will cause.

    Kind regards,
    Robert




    =




    On Sat, O= ct 9, 2021 at 5:50 PM Tony Przygienda <tonysietf@gmail.com> wrote:
    I object a= doption of this document as well based on copious amount of technical count= er arguments laid out in multiple threads. Beside that it seems that to vio= late IETF v6 architecture documents we seem to be trampling on established = standards more and more using increasingly contorted sophisms (yes, you can= hijack any address architecture if you _assume_ that only /4 will be routi= ng table entries & the rest belongs to your new interpretation of addre= ss being a chipmunk that by magic means will never ever escape a private ba= sement until it does).

    Beside that as others = already pointed out copiously the document content does not even seem to ac= tually match WG consensus as recorded to my understanding

    --- tony

    On Fri, Oct 1, 2021 at 10:37 PM Ron Bonica &l= t;rbonica=3D40juniper.net@dmarc.ietf.org> wrote:

    Folks,<= /span>

    =C2=A0<= /span>

    Draft-filsfilscheng-s= pring-srv6-srh-compression-02 introduces three new SID types that can occup= y the Destination Address field of an IPv6 header. See Sections 4.1, 4.2, a= nd 4.3 of the draft for details.

    =C2=A0<= /span>

    The SPRING WG has iss= ued a call for adoption for this draft.

    =C2=A0<= /span>

    It is not clear that = these SID types can be harmonized with the IPv6 addressing architecture.=

    =C2=A0<= /span>

    Does anyone have an o= pinion?

    =C2=A0<= /span>

    =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0Ron

    =C2=A0<= /span>


    Juniper Business Use Only

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
    --------------------------------------------------------------------
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
    --------------------------------------------------------------------
    --000000000000e087e305cdefda73-- From nobody Sat Oct 9 12:06:54 2021 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 270963A074E for ; Sat, 9 Oct 2021 12:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 JBMMa7CYWb3Q for ; Sat, 9 Oct 2021 12:06:46 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 0985A3A05F0 for ; Sat, 9 Oct 2021 12:06:45 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id a10so3852664vsr.1 for ; Sat, 09 Oct 2021 12:06:45 -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=cvy/I3D/593VRJc8ZxUEnktjiC8q+Mslcst8ZI5ntVY=; b=dUkY/ToNoYn2OdJacu+P/AiPlWOOXOHKwUYYiKZm8h/Llgy/W/jNLJqtaMtX4oYtTR Yro6DfF/eZUmuO1f7v076qrtt7JuNssgmLt69K53Hr6HIUzXMdXNYshZnZyRYPXcKQ+T XTq6Ctyp6wqEXcojST8nWQRNy2vrmpalGT8bwjZwUdAAO4K/8t4ugKPFzYDCz5/4wKZq L32JbwbmKNGgEqSOBCBJWRPmt6v/70SZvaS2UWKRD0O0dGzBMoKnxgEWmN/qpC757V9S Q+46LJ3vZ2dIqOI+LAJ3JUsN9e+OGRBS5qfk2juw5KqWyEqaDi36U4vkJVYZC7MvP658 uiZw== 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=cvy/I3D/593VRJc8ZxUEnktjiC8q+Mslcst8ZI5ntVY=; b=iOVj/o5iK9dunvZ8/INDM/0gjQVAbHx7QPQXg3zlagRXEA7Ex2gbSc22GJtnqtg3fj kj5RMpUjDDRvG5NQBFDMav9K8nfk6lcdvly3H8wP3+0ag+hxrs3v4PvHTDig0IYbIN42 60kGVo1WOrqop8IgtPGKcXVHZl0kTpjGfSozBur4l2m5Gm2x3sr9P/N8HlM7PyCDRWMV yVp4Dz0vIMw0xSMmte+RIlfB4v1rFO4P2owj5oA3MbhFOZcml7WSSLbgzLhCRHMETHQ0 RO+0x17BYjEqKPmV6zRd9xYquCX6jdjVtd04YNkU8vJuBVg3qlpn1E95Ur65UrERoR1c BcdQ== X-Gm-Message-State: AOAM533gs6kdZiFk9P/xbLZ7i6/zcSY0sFh0N18nvcQTaMGW/DGaJsED B8KG2TV9TNd4UA7bZwWB+seeORQeE+gDufq4fFbbww== X-Google-Smtp-Source: ABdhPJxas69j+Gtzv5+l0Vb1iXM7QeQyTy7dl1a+3iLXurIpu3s/6/H3LsMea1pKl0OeJa2+7AYq74+4GMoGfq7f8RE= X-Received: by 2002:a67:d20e:: with SMTP id y14mr17839639vsi.5.1633806404692; Sat, 09 Oct 2021 12:06:44 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Sat, 9 Oct 2021 21:06:41 +0200 Message-ID: To: Tony Przygienda Cc: Ron Bonica , SPRING WG , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="0000000000006240f405cdf03217" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 19:06:53 -0000 --0000000000006240f405cdf03217 Content-Type: text/plain; charset="UTF-8" > The all zeroes have a meaning in IPv6 address space I am not trying to say that all predefined IPv6 innovations in the remaining bits are bad. So if I need to use subnet anycast to any ASBR advertising one of said /10's I will put zeros in the remaining bits. Clearly this will not be SRv6 packet. SRv6 spec does not claim everything MUST be SRv6 from now on :) Likewise if I need to use some format of the lower bits to get expected behaviour I will do so. I guess someone may be concerned what if any of the bits between /4 or /10 to /64 accidentally overlap with standards based reserved use cases ? Well for one IPv6 stack should prevent one from accidentally using it. And again this has nothing to do with SPRING. If anything SRv6 implementations use IPv6 stacks hence such protection will be there anyway. Best, R. On Sat, Oct 9, 2021 at 8:42 PM Tony Przygienda wrote: > As a simple example to which I already know your answer as in the usual > "oh, that will never happen" is the subnet routers anycast address I think. > The all zeroes have a meaning in IPv6 address space and intermediate nodes > that don't know they are dealing with a chipmunk may try to do something > with it, probably kill the chipmunk or maybe turn it into a fish if they > are in the next to be invented "ocean limited domain" which your chipmunk > should never enter. > > Or maybe we all should read RFC2526 and make sure THAT never happens in a > chipmunk packet or if it does do we intend to remap a possible combination > that can be mistaken for anycast to something else so chipmunk doesn't > become a fish? Or maybe there is already a SRv6 draft I missed that > declares IPv6 anycast a violation of the chipmunk limited domain. > > As a historical example I lived, this is all oh so clever as folks who > figured out IPv6 actually did not explicitly forbid to assign the same link > local on a box to all interfaces (as far my thinking goes, a significant > mistake) which caused all kind of collateral for a bit actually and even > today, good luck to get all the linux tools to deal properly with %eth2 > without coring (and even better luck trying that with funky interface > naming that linux is employing all over the place). > > my last email on the subject (and I reserve right to maybe be off here and > there a bit, I'm not too deep into v6 and SRv6 but I've seen enough > architectural and WG mistakes to see this compression draft red-zoning), > let's see what the WG moves fwd' with > > -- tony > > On Sat, Oct 9, 2021 at 8:14 PM Robert Raszuk wrote: > >> Tony, >> >> >> *(yes, you can hijack any address architecture if you _assume_ that only >> /4 will be routing table entries & the rest belongs to your new >> interpretation of address being a chipmunk that by magic means will never >> ever escape a private basement until it does).* >> >> Let's try again ... as it seems this keeps coming back over and >> over again. >> >> Assume I got allocated /4 from RIR and I have allocated /10 blocks to my >> global sites connected over plain IPv6 Internet. I advertise those /10s via >> BGP. >> >> What technical harm will happen to anyone if I use bits 11-128 as it >> seems to fit and still send those packets via v6 Internet ? No basement, >> but public Internet. >> >> Last time I checked bits are bits and there is either 0 or 1 in the >> packets (at least till we get to quantum networking). It should be in no >> one's business in the transit to look anywhere beyond /10. >> >> Again please limit the answer to technical issues which this will cause. >> >> Kind regards, >> Robert >> >> >> >> >> >> >> >> >> >> On Sat, Oct 9, 2021 at 5:50 PM Tony Przygienda >> wrote: >> >>> I object adoption of this document as well based on copious amount of >>> technical counter arguments laid out in multiple threads. Beside that it >>> seems that to violate IETF v6 architecture documents we seem to be >>> trampling on established standards more and more using increasingly >>> contorted sophisms (yes, you can hijack any address architecture if you >>> _assume_ that only /4 will be routing table entries & the rest belongs to >>> your new interpretation of address being a chipmunk that by magic means >>> will never ever escape a private basement until it does). >>> >>> Beside that as others already pointed out copiously the document content >>> does not even seem to actually match WG consensus as recorded to my >>> understanding >>> >>> --- tony >>> >>> On Fri, Oct 1, 2021 at 10:37 PM Ron Bonica >> 40juniper.net@dmarc.ietf.org> wrote: >>> >>>> Folks, >>>> >>>> >>>> >>>> Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new >>>> SID types that can occupy the Destination Address field of an IPv6 header. >>>> See Sections 4.1, 4.2, and 4.3 of the draft for details. >>>> >>>> >>>> >>>> The SPRING WG has issued a call for adoption for this draft. >>>> >>>> >>>> >>>> It is not clear that these SID types can be harmonized with the IPv6 >>>> addressing architecture. >>>> >>>> >>>> >>>> Does anyone have an opinion? >>>> >>>> >>>> >>>> >>>> Ron >>>> >>>> >>>> >>>> Juniper Business Use Only >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>>> >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>> >> --0000000000006240f405cdf03217 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    > The all zeroes have a meaning in IPv6 = address space

    I am not trying to say that all predef= ined IPv6 innovations in the remaining bits are bad.=C2=A0

    So if I need to use subnet anycast to any ASBR advertising one of = said /10's I will put zeros in the remaining bits. Clearly this will no= t be SRv6 packet. SRv6 spec does not claim everything MUST be SRv6 from now= on :)=C2=A0

    Likewise if I need to use some format= of the lower bits to get expected behaviour I will=C2=A0do so.=C2=A0
    =

    I guess someone may be concerned=C2=A0what if any of th= e bits between /4 or /10 to /64 accidentally overlap with standards based r= eserved use cases ? Well for one IPv6 stack should prevent one from acciden= tally using it. And again this has nothing=C2=A0to do with SPRING. If anyth= ing SRv6 implementations use IPv6 stacks hence such protection will be ther= e anyway.=C2=A0

    Best,
    R.

    <= /div>

    On Sat, Oct 9, 2021 at 8:42 PM Tony Przygienda <tonysietf@gmail.com> wrote:
    As a simple ex= ample to which I already know your answer as in the usual "oh, that wi= ll never happen" is the subnet routers anycast address I think. The al= l zeroes have a meaning in IPv6 address space and intermediate nodes that d= on't know they are dealing with a chipmunk may try to do something with= it, probably kill the chipmunk or maybe turn it into a fish if they are in= the next to be invented "ocean limited domain" which your chipmu= nk should never enter.

    Or maybe we all should read= RFC2526 and make sure THAT never happens in a chipmunk packet or if it doe= s do we intend to remap a possible combination that can be mistaken for any= cast to something else so chipmunk doesn't become a fish?=C2=A0 Or mayb= e there is already a SRv6 draft I missed that declares IPv6 anycast a viola= tion of the chipmunk limited domain.

    As a his= torical example I lived, this is all oh so clever as folks who figured out = IPv6 actually did not explicitly forbid to assign the same link local on a = box to all interfaces (as far my thinking goes, a significant mistake) whic= h caused all kind of collateral for a bit actually and even today, good luc= k to get all the linux tools to deal properly with %eth2 without coring (an= d even better luck trying that with funky interface naming that linux is em= ploying all over the place).

    my last email on= the subject (and I reserve right to maybe be off here and there a bit, I&#= 39;m not too deep into v6 and SRv6 but I've seen enough architectural a= nd WG mistakes to see this compression draft red-zoning), let's see wha= t the WG moves fwd' with

    -- tony

    On Sat, Oct 9, 2021 at 8:14 PM Robert Raszuk <robert@raszuk.net> wrote:
    Tony,
    =
    (yes, you can hijack any address architecture if you _ass= ume_ that only /4 will be routing table entries & the rest belongs to y= our new interpretation of address being a chipmunk that by magic means will= never ever escape a private basement until it does).
    Let's try again ... as it seems this keeps coming back over= and over=C2=A0again.=C2=A0

    Assume I got allocated= /4 from RIR and I have allocated /10 blocks to my global sites connected o= ver plain IPv6 Internet. I advertise those /10s via BGP.=C2=A0
    What technical harm will happen to anyone if I use bits 11-128= as it seems to fit and=C2=A0still send those packets via v6 Internet ? No = basement, but public=C2=A0Internet.=C2=A0

    Last tim= e I checked bits are bits and there is either 0 or 1 in the packets (at lea= st till we get to quantum networking). It should be in no one's busines= s=C2=A0in the transit to look anywhere beyond=C2=A0/10.=C2=A0
    Again please limit=C2=A0the answer to technical issues which th= is will cause.

    Kind regards,
    Robert









    On Sat, Oct 9, 2021 at 5:50 P= M Tony Przygienda <tonysietf@gmail.com> wrote:
    I object adoption of this docu= ment as well based on copious amount of technical counter arguments laid ou= t in multiple threads. Beside that it seems that to violate IETF v6 archite= cture documents we seem to be trampling on established standards more and m= ore using increasingly contorted sophisms (yes, you can hijack any address = architecture if you _assume_ that only /4 will be routing table entries &am= p; the rest belongs to your new interpretation of address being a chipmunk = that by magic means will never ever escape a private basement until it does= ).

    Beside that as others already pointed out = copiously the document content does not even seem to actually match WG cons= ensus as recorded to my understanding

    --- tony

    On Fri, Oct 1, 2021 at 10:37 PM Ron Bonica <rbonica=3D40juniper.net@dmarc= .ietf.org> wrote:

    Folks,<= /span>

    =C2=A0<= /span>

    Draft-filsfilscheng-s= pring-srv6-srh-compression-02 introduces three new SID types that can occup= y the Destination Address field of an IPv6 header. See Sections 4.1, 4.2, a= nd 4.3 of the draft for details.

    =C2=A0<= /span>

    The SPRING WG has iss= ued a call for adoption for this draft.

    =C2=A0<= /span>

    It is not clear that = these SID types can be harmonized with the IPv6 addressing architecture.=

    =C2=A0<= /span>

    Does anyone have an o= pinion?

    =C2=A0<= /span>

    =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0Ron

    =C2=A0<= /span>


    Juniper Business Use Only

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
    --------------------------------------------------------------------
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
    --------------------------------------------------------------------
    --0000000000006240f405cdf03217-- From nobody Sat Oct 9 13:02:21 2021 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 127783A09A7; Sat, 9 Oct 2021 13:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJsnnR0RVRLN; Sat, 9 Oct 2021 13:01:49 -0700 (PDT) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (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 831683A0990; Sat, 9 Oct 2021 13:01:49 -0700 (PDT) Received: by mail-pj1-x1035.google.com with SMTP id q7-20020a17090a2e0700b001a01027dd88so7383374pjd.1; Sat, 09 Oct 2021 13:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=1cg9Vq/79EUgLDYwPvftMyd6xxk+2GiQ0ClVzUWQQr0=; b=Cqe9TcQJnsZbCst1QltjOUawwE29DjDu5NSbXcz3TQ6G5JICR94QevEtlBOfrvE2AB U5ktAZ3bYul+GYXCEvCIISCgZldm9xb9Mf4sDIHvZfQhRWNACLK+62rQ3du6WbTnfMa4 lC6ELm59h2F2Jy4oAb2mn1fVvMFcNiZq08OhwzLmrmc2GSR1KCQvZGbngQvTud/iNdWs WzJiPdxdl2ftouWi67w5g+VLaJzDb8SEpkQF2xLeXSW8x4nfnw4W6Y/k1NAoAUzasszD +9QuGR+0w8dMQrPBaqviejVC6p45T8WWpdI3F7fc3bADsnNWHKvPX570dr8H24xAI95g /wkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=1cg9Vq/79EUgLDYwPvftMyd6xxk+2GiQ0ClVzUWQQr0=; b=rq27Ql9CUyj220Rb2QbqeH0aG1S8jvwLsa7/3f2h/w7oqvKFyPornGDaGu3Oh6RJvS 44dyyazUBGFwjuLAUZezELWor3steNo1jTDO57Wghh9BpCj1K923CCovfAYag00Vpnpg vrtdoEkJXOtlqnpkgpOHKjQYOVfLMwdW18U/HNqTgrMrir9wl5z9BkvAUP79SHpampIf yo3S292NU0VenGUj3o4aV2Rt7SzZpoM/eohWbSLr2FiqhDbzhcsY7PqqZBGAbvSolIiw WgU/KG4PSnmBwHMPdBS3AHtsGdx1B93Homh1SpIKuUUAF4dl9jp4Hdu1VxYpOevtCzFb 5qig== X-Gm-Message-State: AOAM531JuxNurEzBJOexhh3k1V6ABVI9KlL6odgGfxixcSgGp2Fgo+ud stpe64+JZJMPbvgVpp862zOUViBA/WDYWg== X-Google-Smtp-Source: ABdhPJxNxkS7pzsphTjPsiWfqDzE3fJYXxmajXa0v0VkWcgWlrgiEBA/UVrksL5qd2LHQnEXrRKeug== X-Received: by 2002:a17:902:7843:b0:13d:c728:69c9 with SMTP id e3-20020a170902784300b0013dc72869c9mr16099976pln.55.1633809706975; Sat, 09 Oct 2021 13:01:46 -0700 (PDT) Received: from ?IPv6:2406:e003:1018:b901:db7:d041:a2d:ce65? ([2406:e003:1018:b901:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id q6sm2784862pjd.26.2021.10.09.13.01.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 Oct 2021 13:01:46 -0700 (PDT) To: Robert Raszuk , 6MAN <6man@ietf.org> Cc: Vasilenko Eduard , SPRING WG References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> <423b08d46294454d9a9625990ce52acb@huawei.com> <322a8c29-e232-a39d-94ca-9c9cbf09c8d2@gmail.com> From: Brian E Carpenter Message-ID: <9945ca9c-2ba7-bd00-6e3e-261c376a9718@gmail.com> Date: Sun, 10 Oct 2021 09:01:42 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 20:01:55 -0000 On 10-Oct-21 00:39, Robert Raszuk wrote: > Hi Brian,=C2=A0 >=20 >> Which means: 64 bits. >=20 > Sorry but what is so magic=C2=A0about /64 here ?=20 It is mandated by the current IPv6 addressing architecture. Despite many = discussions, there has never been consensus to change it. So if /64 is no= t the boundary between the routeable part and the host-specific part, it'= s not IPv6. Brian >=20 > Is this coming from the longest routable IPv6 prefix ? Sort of analogy = to /24 in the IPv4 world ? Or something else ?=C2=A0 >=20 > I think LPM and CIDR techniques are pretty well established.=C2=A0 >=20 > Any fixed length of the address block with the meaning=C2=A0- do not us= e those bits inter or intra domain for anything useful even if your prefi= x+node can happily fit in /32 seems just dead wrong to me. And that is ir= respective of any SRv6 discussion.=C2=A0 >=20 > In my books if I get allocated say /48 or /40 from RIR what I do with t= he remaining bits is my own business.=C2=A0 >=20 > Best, > R. >=20 > =C2=A0 >=20 > > Sorry, but it is a little bit late =E2=80=93 RFC 8986 is already = published. >=20 > "Locators are assigned consistent with IPv6 infrastructure allocati= on." >=20 > Which means: 64 bits. >=20 > I have no time to study compressed SIDs, but if they trample on the=20 LOC they are not IPv6 addresses. >=20 > =C2=A0 =C2=A0Brian >=20 >=20 > -------------------------------------------------------------------= - > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6=20 > -------------------------------------------------------------------= - >=20 From nobody Sat Oct 9 13:23:31 2021 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 95A083A06E7; Sat, 9 Oct 2021 13:22:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 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, FREEMAIL_REPLY=1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 uEqhzW-2hsjC; Sat, 9 Oct 2021 13:22:28 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (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 29ECE3A060D; Sat, 9 Oct 2021 13:22:28 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id c4so8464889pls.6; Sat, 09 Oct 2021 13:22:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=st6lGmBxYZMoqDu1OP9qnlnytHiQZIeA0PxT6nDpQ1Y=; b=qyWNew3xAcHFlnSrhTY644ZWDHZeBZ2G+LfBQgiM9N9yhNz/PjAL65CjhHyNUWjlm/ KhiWKh1QkvdGY3izXVnspGG1MH1nhpmumTimfcIiL9ehF4N4W2BboFiTow9vkRm8FvDp bsasRB/+AEFx+MupuwGceOsd8iqKvcwPyV7BBRwJx5VGaRyXc68RykQdF8UqndgfRp4T 9OoGXrV7NIg1df5+4SI89pgz9sPQ9SwMNEm29+53DvzktjyuVjsHdo6lmq3L0S/sb0MC 2PCXuhCg+fZRDoA+Dg9Uxa39o2BdmsBrm8QTSjqZmULzX8bfVYm/7RK5OlLraATuGkG5 V89A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=st6lGmBxYZMoqDu1OP9qnlnytHiQZIeA0PxT6nDpQ1Y=; b=QTpokhWhwSGUPzsspudQthSOjujlfsNbHemieasGYVL/n9MnvW/RYy4WmSpPkx1oOa Q3CIB2v1zhXCCvQ+3ZylD3Gkhmplfwn56t6s6DXiMVn1Imakj3O46/1L6xm3VuDnc3pK aw0V8Zdym05pgJRtuttDSTS8hXLeBXaNhAIcZmP8UkZYVAGcwbszzxpB0LFFzwXDGX7c C8zvernCpahahzK8igoQlpYBKoWQeJrH6KFUTQLp6QsnPjVHt9bJ2LPVvamUT+W/85DO LtmiHXMMKAOHAwPzjHB97qK0Je4Qk9C6TJxkp7xoHZfAcdW3xzIrYuTN87hc7q6eHZaw OyKg== X-Gm-Message-State: AOAM533H6KYldy8vHBNrG0IwfhL2m5uMLi8bNq50Ke9RfgtZPC6suVVv yHIzb4TkC4OruWOk4qS30BHwq1TnLmlytg== X-Google-Smtp-Source: ABdhPJySQMuTz/LMVd91xKZdshQzrjvKeF5ydNOOZ6q4q3nIvyJ6BX9PTCAqkn5Mur7XR0CGfhkO4Q== X-Received: by 2002:a17:902:7c17:b0:13e:2dd5:e5c4 with SMTP id x23-20020a1709027c1700b0013e2dd5e5c4mr16471328pll.68.1633810947190; Sat, 09 Oct 2021 13:22:27 -0700 (PDT) Received: from ?IPv6:2406:e003:1018:b901:db7:d041:a2d:ce65? ([2406:e003:1018:b901:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id mi8sm1534379pjb.20.2021.10.09.13.22.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 Oct 2021 13:22:26 -0700 (PDT) To: Robert Raszuk , Tony Przygienda Cc: Ron Bonica , SPRING WG , "6man@ietf.org" <6man@ietf.org> References: From: Brian E Carpenter Message-ID: <14c36dcd-e801-624a-2788-54e922489e67@gmail.com> Date: Sun, 10 Oct 2021 09:22:22 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 20:22:35 -0000 This would all be much simpler if the SRV6 community explicitly dropped t= he claim to be implementing standard IPv6. Whether the IETF wants to standardise something at layer 3 that isn't IPv= 6 is a separate question. It is pretty obvious that if spring adopts this=20 draft and if it comes to IETF last call, that question will have to be re= solved then. From the present discussion, there is very little chance of = consensus. Regards Brian Carpenter On 10-Oct-21 08:06, Robert Raszuk wrote: >=20 >> The all zeroes have a meaning in IPv6 address space >=20 > I am not trying to say that all predefined IPv6 innovations in the rema= ining bits are bad.=C2=A0 >=20 > So if I need to use subnet anycast to any ASBR advertising one of said = /10's I will put zeros in the remaining bits. Clearly this will not be SR= v6 packet. SRv6 spec does not claim everything MUST be SRv6 from now on := )=C2=A0 >=20 > Likewise if I need to use some format of the lower bits to get expected=20 behaviour I will=C2=A0do so.=C2=A0 >=20 > I guess someone may be concerned=C2=A0what if any of the bits between /= 4 or /10 to /64 accidentally overlap with standards based reserved use ca= ses ? Well for one IPv6 stack should prevent one from accidentally using = it. And again this has nothing=C2=A0to do with SPRING. If anything SRv6 i= mplementations use IPv6 stacks hence such protection will be there anyway= =2E=C2=A0 >=20 > Best, > R. >=20 >=20 > On Sat, Oct 9, 2021 at 8:42 PM Tony Przygienda > wrote: >=20 > As a simple example to which I already know your answer as in the u= sual "oh, that will never happen" is the subnet routers anycast address I=20 think. The all zeroes have a meaning in IPv6 address space and intermedia= te nodes that don't know they are dealing with a chipmunk may try to do s= omething with it, probably kill the chipmunk or maybe turn it into a fish=20 if they are in the next to be invented "ocean limited domain" which your = chipmunk should never enter. >=20 > Or maybe we all should read RFC2526 and make sure THAT never happen= s in a chipmunk packet or if it does do we intend to remap a possible com= bination that can be mistaken for anycast to something else so chipmunk d= oesn't become a fish?=C2=A0 Or maybe there is already a SRv6 draft I miss= ed that declares IPv6 anycast a violation of the chipmunk limited domain.= >=20 > As a historical example I lived, this is all oh so clever as folks = who figured out IPv6 actually did not explicitly forbid to assign the sam= e link local on a box to all interfaces (as far my thinking goes, a signi= ficant mistake) which caused all kind of collateral for a bit actually an= d even today, good luck to get all the linux tools to deal properly with = %eth2 without coring (and even better luck trying that with funky interfa= ce naming that linux is employing all over the place). >=20 > my last email on the subject (and I reserve right to maybe be off h= ere and there a bit, I'm not too deep into v6 and SRv6 but I've seen enou= gh architectural and WG mistakes to see this compression draft red-zoning= ), let's see what the WG moves fwd' with >=20 > -- tony >=20 > On Sat, Oct 9, 2021 at 8:14 PM Robert Raszuk > wrote: >=20 > Tony, >=20 > /(yes, you can hijack any address architecture if you _assume_ = that only /4 will be routing table entries & the rest belongs to your new=20 interpretation of address being a chipmunk that by magic means will never=20 ever escape a private basement until it does). > / >=20 > Let's try again ... as it seems this keeps coming back over and=20 over=C2=A0again.=C2=A0 >=20 > Assume I got allocated /4 from RIR and I have allocated /10 blo= cks to my global sites connected over plain IPv6 Internet. I advertise th= ose /10s via BGP.=C2=A0 >=20 > What technical harm will happen to anyone if I use bits 11-128 = as it seems to fit and=C2=A0still send those packets via v6 Internet ? No=20 basement, but public=C2=A0Internet.=C2=A0 >=20 > Last time I checked bits are bits and there is either 0 or 1 in=20 the packets (at least till we get to quantum networking). It should be in=20 no one's business=C2=A0in the transit to look anywhere beyond=C2=A0/10.=C2= =A0 >=20 > Again please limit=C2=A0the answer to technical issues which th= is will cause. >=20 > Kind regards, > Robert >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Sat, Oct 9, 2021 at 5:50 PM Tony Przygienda > wrote: >=20 > I object adoption of this document as well based on copious=20 amount of technical counter arguments laid out in multiple threads. Besid= e that it seems that to violate IETF v6 architecture documents we seem to=20 be trampling on established standards more and more using increasingly co= ntorted sophisms (yes, you can hijack any address architecture if you _as= sume_ that only /4 will be routing table entries & the rest belongs to yo= ur new interpretation of address being a chipmunk that by magic means wil= l never ever escape a private basement until it does). >=20 > Beside that as others already pointed out copiously the doc= ument content does not even seem to actually match WG consensus as record= ed to my understanding >=20 > --- tony >=20 > On Fri, Oct 1, 2021 at 10:37 PM Ron Bonica > wrote: >=20 > Folks,____ >=20 > __=C2=A0__ >=20 > Draft-filsfilscheng-spring-srv6-srh-compression-02 intr= oduces three new SID types that can occupy the Destination Address field = of an IPv6 header. See Sections 4.1, 4.2, and 4.3 of the draft for detail= s.____ >=20 > __=C2=A0__ >=20 > The SPRING WG has issued a call for adoption for this d= raft.____ >=20 > __=C2=A0__ >=20 > It is not clear that these SID types can be harmonized = with the IPv6 addressing architecture.____ >=20 > __=C2=A0__ >=20 > Does anyone have an opinion?____ >=20 > __=C2=A0__ >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Ron____ >=20 > __=C2=A0__ >=20 >=20 > Juniper Business Use Only >=20 > -------------------------------------------------------= ------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/l= istinfo/ipv6 > -------------------------------------------------------= ------------- >=20 > -----------------------------------------------------------= --------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listi= nfo/ipv6 > -----------------------------------------------------------= --------- >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Sat Oct 9 13:27:05 2021 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 663033A079D for ; Sat, 9 Oct 2021 13:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 Sl6MUlN1QCln for ; Sat, 9 Oct 2021 13:26:34 -0700 (PDT) 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 A39803A07A1 for ; Sat, 9 Oct 2021 13:26:34 -0700 (PDT) Received: by mail-vs1-xe34.google.com with SMTP id o124so14416550vsc.6 for ; Sat, 09 Oct 2021 13:26:34 -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=2iq+LfaBaxH8vOIdqLL9D45dPKvbZ5JzMxTagayYRow=; b=Kz7qDm6lWO+CikhSwNRI5TnS7Ap956ovfIZaNQevFctFHK7l6aahZaFIucCOI73Ui7 6VaX4Doa3RlNc2Tlwx/+B9h43S2fhB4KvK8WNvxZI13IxmpW01zv6pImV+CL6G1txoWQ 20VOwuU8Od1ysOifnKy9vrV1PIE8dSDTqGfBCWE9pC2031XrkJEtHjAOlMMOSS+qBCEZ IUl3n9hetIwE4GDiqloUnhAqxcZA7f28Qj4fghb07CLktdD3Iqshdqho3aGdLHrgqh/L f+4cyJEIRaYYkXTEeCZ/BVhdEJ9KFb1XlraSkny9kRBpZZ2TkuYX+dyuxEbeobeKt/0l jZVw== 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=2iq+LfaBaxH8vOIdqLL9D45dPKvbZ5JzMxTagayYRow=; b=xhEIMos2++OKwKr7F9MCMeLV+/FvZWZC+Xe5vHZCYI38TnSQKz57Iqk56EJLuq3BCQ 1/uinc1ETAKLeY7TNyq7U/hJhI22xua3sbxBb6kaRedZE+oJaB0umIVSVx9NscMhkWFY KY+fhpIKm/LiWCbFGO9TFNowDleYST5VXYu3V1Z9Qjl7H6NSSqIdDGN7y/JQ4UfXJO7z TJWCkbd8PNp0Cba7rsvC8Hgv01BrcRrSucBhHEtpBqWLtGQRULvxjjamxnlTcN1G4Ptk uN0hqyfp9cx9As4Ip9q7TUJTqE50/OlIDH6BHvJBU9ELLd1I/J7zIlUwjy9FRdHUYdnq 0VlQ== X-Gm-Message-State: AOAM533XzwElrvDaN4s3GFG3seeMDRoIMbv3XAIcZi2TcU2897WUTvGe LH7gE8TDL+lNGXEBBbCptRbRefgF5EpU2N1HZtkOiw== X-Google-Smtp-Source: ABdhPJywsS9GS0cx8PRsj8cmNGk4KZPnS2UqXjI9dwWfv28rgeV2XcyKVJlCutDRpS/f26brHLp6U0tyFzvpxzG8w10= X-Received: by 2002:a67:2283:: with SMTP id i125mr17850466vsi.50.1633811193408; Sat, 09 Oct 2021 13:26:33 -0700 (PDT) MIME-Version: 1.0 References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> <423b08d46294454d9a9625990ce52acb@huawei.com> <322a8c29-e232-a39d-94ca-9c9cbf09c8d2@gmail.com> <9945ca9c-2ba7-bd00-6e3e-261c376a9718@gmail.com> In-Reply-To: <9945ca9c-2ba7-bd00-6e3e-261c376a9718@gmail.com> From: Robert Raszuk Date: Sat, 9 Oct 2021 22:26:30 +0200 Message-ID: To: Brian E Carpenter Cc: 6MAN <6man@ietf.org>, Vasilenko Eduard , SPRING WG Content-Type: multipart/alternative; boundary="000000000000d044e705cdf14f3d" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 20:26:40 -0000 --000000000000d044e705cdf14f3d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > > > Hi Brian, > > > >> Which means: 64 bits. > > > > Sorry but what is so magic about /64 here ? > > It is mandated by the current IPv6 addressing architecture. Really ? Where ? I am looking at RFC4291 and nowhere I can find /64 reference. Moreover sections 2.4 and 2.5 are very clear that there is no magic /64 hard defined. The text actually goes even further and says: Except for the knowledge of the subnet boundary discussed in the previous paragraphs, nodes should not make any assumptions about the structure of an IPv6 address. Thx, R. > Despite many discussions, there has never been consensus to change it. So > if /64 is not the boundary between the routeable part and the host-specif= ic > part, it's not IPv6. > > Brian > > > > > Is this coming from the longest routable IPv6 prefix ? Sort of analogy > to /24 in the IPv4 world ? Or something else ? > > > > I think LPM and CIDR techniques are pretty well established. > > > > Any fixed length of the address block with the meaning - do not use > those bits inter or intra domain for anything useful even if your > prefix+node can happily fit in /32 seems just dead wrong to me. And that = is > irrespective of any SRv6 discussion. > > > > In my books if I get allocated say /48 or /40 from RIR what I do with > the remaining bits is my own business. > > > > Best, > > R. > > > > > > > > > Sorry, but it is a little bit late =E2=80=93 RFC 8986 is already = published. > > > > "Locators are assigned consistent with IPv6 infrastructure > allocation." > > > > Which means: 64 bits. > > > > I have no time to study compressed SIDs, but if they trample on the > LOC they are not IPv6 addresses. > > > > Brian > > > > > > -------------------------------------------------------------------= - > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------= - > > > > --000000000000d044e705cdf14f3d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    > Hi Brian,=C2=A0
    >
    >> Which means: 64 bits.
    >
    > Sorry but what is so magic=C2=A0about /64 here ?

    It is mandated by the current IPv6 addressing architecture.

    Really ? Where ? I am looking at RFC4291 and nowhere I ca= n find /64 reference.=C2=A0

    Moreover sections = 2.4 and 2.5 are very clear that there is no magic /64 hard defined.=C2=A0

    The text actually goes even further and says:=C2=A0= 

       Except for the knowledge of the subnet boundary discussed in the
   previous paragraphs, nodes should not make any assumptions about the
   structure of an IPv6 address.

    R.


    <= /div>
    =C2=A0
    Des= pite many discussions, there has never been consensus to change it. So if /= 64 is not the boundary between the routeable part and the host-specific par= t, it's not IPv6.

    =C2=A0 =C2=A0Brian

    >
    > Is this coming from the longest routable IPv6 prefix ? Sort of analogy= to /24 in the IPv4 world ? Or something else ?=C2=A0
    >
    > I think LPM and CIDR techniques are pretty well established.=C2=A0
    >
    > Any fixed length of the address block with the meaning=C2=A0- do not u= se those bits inter or intra domain for anything useful even if your prefix= +node can happily fit in /32 seems just dead wrong to me. And that is irres= pective of any SRv6 discussion.=C2=A0
    >
    > In my books if I get allocated say /48 or /40 from RIR what I do with = the remaining bits is my own business.=C2=A0
    >
    > Best,
    > R.
    >
    > =C2=A0
    >
    >=C2=A0 =C2=A0 =C2=A0> Sorry, but it is a little bit late =E2=80=93 R= FC 8986 is already published.
    >
    >=C2=A0 =C2=A0 =C2=A0"Locators are assigned consistent with IPv6 in= frastructure allocation."
    >
    >=C2=A0 =C2=A0 =C2=A0Which means: 64 bits.
    >
    >=C2=A0 =C2=A0 =C2=A0I have no time to study compressed SIDs, but if the= y trample on the
    LOC they are not IPv6 addresses.
    >
    >=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Brian
    >
    >
    >=C2=A0 =C2=A0 =C2=A0---------------------------------------------------= -----------------
    >=C2=A0 =C2=A0 =C2=A0IETF IPv6 working group mailing list
    >=C2=A0 =C2=A0 =C2=A0= ipv6@ietf.org <mailto:ipv6@ietf.org>
    >=C2=A0 =C2=A0 =C2=A0Administrative Requests: https://w= ww.ietf.org/mailman/listinfo/ipv6
    <https://www.ietf.org/mailman/listinfo/ipv6>
    >=C2=A0 =C2=A0 =C2=A0---------------------------------------------------= -----------------
    >

    --000000000000d044e705cdf14f3d-- From nobody Sat Oct 9 13:41:47 2021 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 58D7F3A085C; Sat, 9 Oct 2021 13:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 3M8DaGb39l8o; Sat, 9 Oct 2021 13:41:41 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED99C3A0859; Sat, 9 Oct 2021 13:41:38 -0700 (PDT) X-Envelope-To: spring@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 199KfW40067362 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Oct 2021 21:41:33 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local To: Robert Raszuk Cc: Brian E Carpenter , SPRING WG , 6MAN <6man@ietf.org> References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> <423b08d46294454d9a9625990ce52acb@huawei.com> <322a8c29-e232-a39d-94ca-9c9cbf09c8d2@gmail.com> <9945ca9c-2ba7-bd00-6e3e-261c376a9718@gmail.com> From: Nick Hilliard Message-ID: <420e9333-6ba6-bf99-6ca0-4d6c4becd235@foobar.org> Date: Sat, 9 Oct 2021 21:41:31 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.49 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 20:41:46 -0000 Robert Raszuk wrote on 09/10/2021 21:26: > Really ? Where ? I am looking at RFC4291 and nowhere I can find /64 > reference. Robert, there's been extensive discussion about this on 6man. Please run a search on the ietf mail archive for draft-bourbaki-6man-classless-ipv6 to get a flavour for some of the complexities involved. Nick From nobody Sat Oct 9 13:44:17 2021 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 3F2663A085A; Sat, 9 Oct 2021 13:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 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] 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 MLygkYXtcimM; Sat, 9 Oct 2021 13:44:12 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A5CB3A0859; Sat, 9 Oct 2021 13:44:12 -0700 (PDT) Received: from smtpclient.apple (ti0389q160-5225.bb.online.no [95.34.0.166]) (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 clarinet.employees.org (Postfix) with ESMTPSA id AE7784E11A4F; Sat, 9 Oct 2021 20:44:11 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ole Troan Mime-Version: 1.0 (1.0) Date: Sat, 9 Oct 2021 22:44:07 +0200 Message-Id: <7BE1A3BF-B731-45CA-8A8B-3E422A58203C@employees.org> References: <9945ca9c-2ba7-bd00-6e3e-261c376a9718@gmail.com> Cc: Robert Raszuk , 6MAN <6man@ietf.org>, SPRING WG In-Reply-To: <9945ca9c-2ba7-bd00-6e3e-261c376a9718@gmail.com> To: Brian E Carpenter X-Mailer: iPhone Mail (19A348) Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 20:44:15 -0000 > On 9 Oct 2021, at 22:02, Brian E Carpenter w= rote: >=20 > It is mandated by the current IPv6 addressing architecture. Despite many d= iscussions, there has never been consensus to change it. So if /64 is not th= e boundary between the routeable part and the host-specific part, it's not I= Pv6. I understand that you are trying to make a point. It benefits this discussio= n to be as precise as possible.=20 There are all shades of grey here, as shown by the IETF standards, implement= ations and deployments. Let=E2=80=99s accept that fact, and we don=E2=80=99t= have to make this unnecessarily divisive.=20 O.=20= From nobody Sat Oct 9 13:48:30 2021 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 9094B3A081C; Sat, 9 Oct 2021 13:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 usSh2PPgZcua; Sat, 9 Oct 2021 13:48:20 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F1F3A085D; Sat, 9 Oct 2021 13:48:19 -0700 (PDT) X-Envelope-To: spring@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 199KmEvY068119 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Oct 2021 21:48:14 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local To: Robert Raszuk Cc: Tony Przygienda , Ron Bonica , SPRING WG , "6man@ietf.org" <6man@ietf.org> References: From: Nick Hilliard Message-ID: <255f0e51-a972-091e-bee9-a8df320ad515@foobar.org> Date: Sat, 9 Oct 2021 21:48:12 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.49 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 20:48:25 -0000 Robert Raszuk wrote on 09/10/2021 19:14: > What technical harm will happen to anyone if I use bits 11-128 as it > seems to fit and still send those packets via v6 Internet ? No basement, > but public Internet. Andrew Alston already answered this question with a production example. > https://mailarchive.ietf.org/arch/msg/spring/WnTS8xI_M8grDPVs3IvNvc0sSNI/ Not all SRv6 implementations will be green-field or lab. Probably many will not be, which is why the dst field rewriting proposal is actively harmful. Nick From nobody Sat Oct 9 13:52:14 2021 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 090A93A085F for ; Sat, 9 Oct 2021 13:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 LO76IISC0ilM for ; Sat, 9 Oct 2021 13:52:04 -0700 (PDT) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (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 61AFE3A0863 for ; Sat, 9 Oct 2021 13:52:04 -0700 (PDT) Received: by mail-vs1-xe30.google.com with SMTP id p23so244828vsq.10 for ; Sat, 09 Oct 2021 13:52:04 -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=uBoUsrwmLLLg6UU4Bp/pt5Rou42jEF0eoXEBeloYcfY=; b=ItvmM8JfXU0Jrn6OCM657/ANZ+qfZlv7FdK4mICEKpFbuMRmBmYR3Gwr5KvwVBYjcQ tbEjFUxpwXefCdljGLtws/GNq9BRHvTXFYmZhInLS70MMuJGsp3At0X65ij57Y0+E5I7 bifYMvbpVSqKnLSwSwb6Com/CDQowqJas3k84YGXYIdBKV7qiBqlej7xBFzWgwBV4H39 H9LD2sftsIkdbkkM1iyW2QzM3v/ZzvpLbLU0pPeHkJt+povdxyxLmGgNaj0aNKlKNwCS t/fW9+EYG0RClvAL3M6x71GV8vv+V1u/d1LcNshDtTUbEjzfcm/Djz5QSMHZzt2KugAq rX6w== 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=uBoUsrwmLLLg6UU4Bp/pt5Rou42jEF0eoXEBeloYcfY=; b=J94UObrdJPe9Q13il5iwLvaddQJwgii51EG0tsctOdKJUZm9OXAP5KC6eW8n1Lykpy LXYkcNkfFn8CtrKRlkhR4YsaqoZP4Chv8uMXV83p3PdO4FvClT91WpmHThg/ZPiH5Xt5 poZkH8te5LaYiXSiyY4j7iOiLOa6wqhpQEUtjFADEvtcFLYnArPvtqwtz4TeFoFhcB4B X/9SQ0zRtxLBD4vuQLdjkPQaPj9q2shuMPLzgtcoVcKSE9AR09H0NwWK3qm5gJa6oVC0 pqlz0Y/6VQWSqiXQQt21SMm16u8hpAtcFGc+GAI8SbS9xbxwvVFWXSjJexmJFFo1c5L3 Z43g== X-Gm-Message-State: AOAM532wwy4jLkQmJBtXLmQf4i4m1vzTE4tbkI3qfHgG/obCk8mq6qzN 9j3l2u6dRrP59TF8gBZ/5hFXZekp/owY5L+x9S7ZYA== X-Google-Smtp-Source: ABdhPJxKQ9u066qacDbY1HdrazFSJsJeeCtGYrGsE0smRvV1Sbx88ogckM2lD1MG6wW/lN54VlbVb+IEEcWWuLBoaWA= X-Received: by 2002:a67:2283:: with SMTP id i125mr17876881vsi.50.1633812722943; Sat, 09 Oct 2021 13:52:02 -0700 (PDT) MIME-Version: 1.0 References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> <423b08d46294454d9a9625990ce52acb@huawei.com> <322a8c29-e232-a39d-94ca-9c9cbf09c8d2@gmail.com> <9945ca9c-2ba7-bd00-6e3e-261c376a9718@gmail.com> <420e9333-6ba6-bf99-6ca0-4d6c4becd235@foobar.org> In-Reply-To: <420e9333-6ba6-bf99-6ca0-4d6c4becd235@foobar.org> From: Robert Raszuk Date: Sat, 9 Oct 2021 22:51:59 +0200 Message-ID: To: Nick Hilliard Cc: Brian E Carpenter , SPRING WG , 6MAN <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000fb19cd05cdf1aad5" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 20:52:10 -0000 --000000000000fb19cd05cdf1aad5 Content-Type: text/plain; charset="UTF-8" Hi Nick, I missed that draft, but I like it :) Back to our discussion I am not sure how definition of IPv6 Interface Identifiers came to the context of this thread. To the best of my understanding no one claims that SRv6 must be contained to IPv6 IIDs. RFC8986 section 3.2 uses an example of /64 IIDs, but this is only illustration with explicit wording "a network operator may:" which in no way should be read as any type of mandatory rule. Back to my example of few /10 sites interconnected over Internet - how any transit router is ever going to detect what am I doing with bits 11-128 in my sites ? Yes I do accept some special use address formats and I perfectly fine to make sure I will avoid using them. Many thx, Robert. On Sat, Oct 9, 2021 at 10:41 PM Nick Hilliard wrote: > Robert Raszuk wrote on 09/10/2021 21:26: > > Really ? Where ? I am looking at RFC4291 and nowhere I can find /64 > > reference. > > Robert, there's been extensive discussion about this on 6man. Please > run a search on the ietf mail archive for > draft-bourbaki-6man-classless-ipv6 to get a flavour for some of the > complexities involved. > > Nick > --000000000000fb19cd05cdf1aad5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Nick,

    I missed that draft, but I lik= e it :)=C2=A0

    Back to our discussion I am not sure= how definition of IPv6 Interface Identifiers came to the context of this t= hread. To the best of my understanding no one claims that SRv6 must be cont= ained to IPv6 IIDs.=C2=A0

    RFC8986 section 3.2 uses= an example of /64 IIDs, but this is only illustration with explicit wordin= g "a network oper= ator may:" which in no way should be read as any type of mandatory rul= e.=C2=A0

    Back to my example of few /10 sites interconnected over Internet - how = any transit router is ever going to detect what am I doing with bits 11-128= in my sites ? Yes I do accept some special use address formats and I perfe= ctly fine to make sure I will avoid=C2=A0using them.=C2=A0

    Many thx,
    Robert.


    On Sat, Oct 9, 2021 at 10:41 PM Nick Hilliard <nick@foobar.org> wrote:
    Robert Raszuk wrote on 09/10/2021 21:26:
    > Really ? Where ? I am looking at RFC4291 and nowhere I can find /64 > reference.

    Robert, there's been extensive discussion about this on 6man.=C2=A0 Ple= ase
    run a search on the ietf mail archive for
    draft-bourbaki-6man-classless-ipv6 to get a flavour for some of the
    complexities involved.

    Nick
    --000000000000fb19cd05cdf1aad5-- From nobody Sat Oct 9 13:54:32 2021 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 99B843A085D for ; Sat, 9 Oct 2021 13:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 djoPYs3XNJxq for ; Sat, 9 Oct 2021 13:54:18 -0700 (PDT) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 4C07B3A085F for ; Sat, 9 Oct 2021 13:54:18 -0700 (PDT) Received: by mail-vs1-xe32.google.com with SMTP id 66so14399925vsd.11 for ; Sat, 09 Oct 2021 13:54:18 -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=PeFrLkEExZs6EIkkzEQ1pbTyAaPsMaenPLVEdD0Odf4=; b=TQ8PsTFJPhsCmefZdRPTiwlX1fG8Jz2RXirCVQBuTQJGaINqoG6NHv43scYVB9sDOP HwDMuFSO85Bc5oXcI+52TQds/+9xmHLB2TPEpzx06zybQZ0eb5LrTUyyRmRL4tGvoiGi oDstmpWBCcukx7A2PtvjszVB1z5E3t33Hv1mqUaovgXhzWOj3zZP+tfbdRVse2G6gCz+ HecI0nngaEk4zPNZFOfWI4aysTXzhtC4+MzGOuqDzC6v5lUD7ubICip0OZhwX7CmIBnl gg2ycBCjdZkZc6OYxi0Rwkfqi/EKo06fnq60SnLriQfDS9gvZt+VyspQ1+CHrEW58gdP EbOQ== 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=PeFrLkEExZs6EIkkzEQ1pbTyAaPsMaenPLVEdD0Odf4=; b=qT5xg+xPzHWcm3oXn5N/uJD/4zomyLzSE9Z/sZGgeG0WGVZJx/yXySqLbOHpfFrC17 o5GRnemmB7wztYX/iPpupcZLr0vH4uR7bTS0WHg4U2raH8VlcE4GQAH6ULWxOLYx9WWB mCCm8LNjGDhGLuQ3pJTJc4je9evFvUJ9Ep9Br0L5Og/JY1Xs5jBLQd7d9WhdI76mFsG1 nZ2kqZcFWmR4IB5RYA5cNzJSFjD7poV0cazR9Yh1YHxC9mB633Wdkg2tiWlzyQ4fbguv I1MK0tfctb1eBDW7MvxW5264B2FSyLZggdExBv1+29lwp0TsBvBVm6jmyAv8cdVV0VWa Mgbg== X-Gm-Message-State: AOAM5332mgfNalHpDhJp8OMp5oVdnln+1NkLHMwhJAXIAUuPJtyU9dod 9d57BBNACM+nLQ52alqWbvXnvw6KYoUAjHGSfWIlkZKGD6Y= X-Google-Smtp-Source: ABdhPJz/vo0j2t7JGBI99vkP0myQGlNrdKX6hjyOLWkIn/3utaVA8hGn2mOBsgTOP3qaQAN6SzRCvGBJUb4kbiukRBo= X-Received: by 2002:a67:d20e:: with SMTP id y14mr18026092vsi.5.1633812857108; Sat, 09 Oct 2021 13:54:17 -0700 (PDT) MIME-Version: 1.0 References: <255f0e51-a972-091e-bee9-a8df320ad515@foobar.org> In-Reply-To: <255f0e51-a972-091e-bee9-a8df320ad515@foobar.org> From: Robert Raszuk Date: Sat, 9 Oct 2021 22:54:14 +0200 Message-ID: To: Nick Hilliard Cc: Tony Przygienda , Ron Bonica , SPRING WG , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000fa52ff05cdf1b240" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 20:54:24 -0000 --000000000000fa52ff05cdf1b240 Content-Type: text/plain; charset="UTF-8" The link below says nothing related to what I was saying. I am explicitly not talking about some "limited domain" in my example. I am talking about a few sites connected over wild IPv6 Internet. On Sat, Oct 9, 2021 at 10:48 PM Nick Hilliard wrote: > Robert Raszuk wrote on 09/10/2021 19:14: > > What technical harm will happen to anyone if I use bits 11-128 as it > > seems to fit and still send those packets via v6 Internet ? No basement, > > but public Internet. > > Andrew Alston already answered this question with a production example. > > > > https://mailarchive.ietf.org/arch/msg/spring/WnTS8xI_M8grDPVs3IvNvc0sSNI/ > > Not all SRv6 implementations will be green-field or lab. Probably many > will not be, which is why the dst field rewriting proposal is actively > harmful. > > Nick > --000000000000fa52ff05cdf1b240 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    The link below says nothin= g related to what I was saying. I am explicitly=C2=A0not talking about some= "limited domain" in my example. I am talking about a few sites c= onnected=C2=A0over wild IPv6 Internet.=C2=A0


    On Sat, Oct 9, 2= 021 at 10:48 PM Nick Hilliard <nick@f= oobar.org> wrote:
    Robert Raszuk wrote on 09/10/2021 19:14:
    > What technical harm will happen to anyone if I use bits 11-128 as it <= br> > seems to fit and=C2=A0still send those packets via v6 Internet ? No ba= sement,
    > but public=C2=A0Internet.

    Andrew Alston already answered this question with a production example.

    > https://mailarchive.ie= tf.org/arch/msg/spring/WnTS8xI_M8grDPVs3IvNvc0sSNI/

    Not all SRv6 implementations will be green-field or lab.=C2=A0 Probably man= y
    will not be, which is why the dst field rewriting proposal is actively
    harmful.

    Nick
    --000000000000fa52ff05cdf1b240-- From nobody Sat Oct 9 14:01:46 2021 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 C1FDB3A0B02; Sat, 9 Oct 2021 14:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 G-irZjKaoxrf; Sat, 9 Oct 2021 14:00:56 -0700 (PDT) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 9752B3A0AD4; Sat, 9 Oct 2021 14:00:56 -0700 (PDT) Received: by mail-il1-x129.google.com with SMTP id w11so10582123ilv.6; Sat, 09 Oct 2021 14:00: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=MFgNNBmAtPnwENgRIt8//qSBimZP2ABc7BkP+FjpGfw=; b=UCCrdoe/BvF7FFKAy4kGbEd00o6UGJo+7w6kE1BNqx4A9PELimyGAzDTRZj097rrvD l5IbMdNopcLfRJ8AenVpSHnrbvCNGffjUgzcU9hABzMWW4oR9noqIMibfIcFHMFkR4Ba 9bv7/MztMhyb7As45ovYe0VaUW4KCPNzx1f+cBPesGVDyWzx7CZd3eTpTd5II6U4f3lp HTyW+czPpRg36sF3NSU4Qf8RAlEMzwFsPKfBtetYGGCk7lRZeWcxcru3jqQVd+6JZbz+ sO4MmLe8QQMaTCCoGMmpQmydROu1PL7D6P/TaFtstpxYBdMMkQMZbfMwMkBbTe2L5cZ/ /kqA== 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=MFgNNBmAtPnwENgRIt8//qSBimZP2ABc7BkP+FjpGfw=; b=2kRT2p4y/CaHPktHm7sXX2kJvHtWsrHhFo3wnh2zmd+XKEL3yuyI8em7lvyvQlgCLb SpoLPs5AIIZ7IxOlAiYVi3ql6f9xY4QYdlLqm/M6OWEr8IWfsKa0rKLT00nkdFsZaWVF 4nvA9widKYrO1SUgP0cE96FUA8BI8EIpjW2uNLKgElXHco1+0sTo0lGQ2HDJVkFQ3rff duX1E6zoUOyca8V0UlUBhn+A+oFLxGr3nCBpkTy+/mluf6ExugHhFS5XD5gsG2hGqSmU jtsS1Hu8MhUKIWZEeL8MXktFakmlhLeSckYRxAMXUAK7EyzsjcjXThrkPbAHxBWIJj9I AohA== X-Gm-Message-State: AOAM533XuJQXbV8EfzOMxgXxyNVuxom5CO9iaaLMUaSzVvMKpcxGP5nt frF22Xt5qNa0pXvcm3sgK+aXESY0RULs9JdkTGU= X-Google-Smtp-Source: ABdhPJywlvLaeKLG5Jkl87qIgGtjYiMddVAp2mM5vaP2LjjUAvUbr7VmHJHOKEKjqPhmOXNtsiaGvjLgpGZE71NeJaA= X-Received: by 2002:a05:6e02:1025:: with SMTP id o5mr13582195ilj.133.1633813255134; Sat, 09 Oct 2021 14:00:55 -0700 (PDT) MIME-Version: 1.0 References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> <423b08d46294454d9a9625990ce52acb@huawei.com> <322a8c29-e232-a39d-94ca-9c9cbf09c8d2@gmail.com> <9945ca9c-2ba7-bd00-6e3e-261c376a9718@gmail.com> In-Reply-To: From: Mark Smith Date: Sun, 10 Oct 2021 08:00:43 +1100 Message-ID: To: Robert Raszuk Cc: Brian E Carpenter , SPRING WG , 6MAN <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000b3a4aa05cdf1ca95" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 21:01:07 -0000 --000000000000b3a4aa05cdf1ca95 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's stated twice in section 2.5 of RFC4291. For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format. All Global Unicast addresses other than those that start with binary 000 have a 64-bit interface ID field (i.e., n + m =3D 64), formatted as described in Section 2.5.1 . Global Unicast addresses that start with binary 000 have no such constraint on the size or structure of the interface ID field. Please also see RFC7421, Analysis of the 64-bit Boundary in IPv6 Addressing. On Sun, 10 Oct 2021, 07:27 Robert Raszuk, wrote: > > Hi Brian, >> > >> >> Which means: 64 bits. >> > >> > Sorry but what is so magic about /64 here ? >> >> It is mandated by the current IPv6 addressing architecture. > > > Really ? Where ? I am looking at RFC4291 and nowhere I can find /64 > reference. > > Moreover sections 2.4 and 2.5 are very clear that there is no magic /64 > hard defined. > > The text actually goes even further and says: > > Except for the knowledge of the subnet boundary discussed in the > previous paragraphs, nodes should not make any assumptions about the > structure of an IPv6 address. > > > Thx, > > R. > > > > > >> Despite many discussions, there has never been consensus to change it. S= o >> if /64 is not the boundary between the routeable part and the host-speci= fic >> part, it's not IPv6. >> >> Brian >> >> > >> > Is this coming from the longest routable IPv6 prefix ? Sort of analogy >> to /24 in the IPv4 world ? Or something else ? >> > >> > I think LPM and CIDR techniques are pretty well established. >> > >> > Any fixed length of the address block with the meaning - do not use >> those bits inter or intra domain for anything useful even if your >> prefix+node can happily fit in /32 seems just dead wrong to me. And that= is >> irrespective of any SRv6 discussion. >> > >> > In my books if I get allocated say /48 or /40 from RIR what I do with >> the remaining bits is my own business. >> > >> > Best, >> > R. >> > >> > >> > >> > > Sorry, but it is a little bit late =E2=80=93 RFC 8986 is already >> published. >> > >> > "Locators are assigned consistent with IPv6 infrastructure >> allocation." >> > >> > Which means: 64 bits. >> > >> > I have no time to study compressed SIDs, but if they trample on th= e >> LOC they are not IPv6 addresses. >> > >> > Brian >> > >> > >> > ------------------------------------------------------------------= -- >> > IETF IPv6 working group mailing list >> > ipv6@ietf.org >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv= 6 >> >> > ------------------------------------------------------------------= -- >> > >> >> -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000b3a4aa05cdf1ca95 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    It's stated twice= in section 2.5 of RFC4291.

    For=
 all unicast addresses, except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

    = 
       All Global Unicast addresses other than those that star=
t with binary
   000 have a 64-bit interface ID field (i.e., n + m =3D 64), formatted as
   described in Section 2.5.1.  Global Unicast addresses =
that start with
   binary 000 have no such constraint on the size or structure of the
   interface ID field.

    Please also see RFC7421,=C2=A0=C2= =A0Analysis of the 64= -bit Boundary in IPv6 Addressing.






    On Su= n, 10 Oct 2021, 07:27 Robert Raszuk, <robert@raszuk.net> wrote:
    =
    =
    > Hi Brian,=C2=A0
    >
    >> Which means: 64 bits.
    >
    > Sorry but what is so magic=C2=A0about /64 here ?

    It is mandated by the current IPv6 addressing architecture.

    Really ? Where ? I am looking at RFC4291 and nowhere I ca= n find /64 reference.=C2=A0

    Moreover sections = 2.4 and 2.5 are very clear that there is no magic /64 hard defined.=C2=A0

    The text actually goes even further and says:=C2=A0= 

       Except for the kno=
wledge of the subnet boundary discussed in the
   previous paragraphs, nodes should not make any assumptions about the
   structure of an IPv6 address.

    Thx,
    R.
    =


    =C2=A0
    Despite many discussions= , there has never been consensus to change it. So if /64 is not the boundar= y between the routeable part and the host-specific part, it's not IPv6.=

    =C2=A0 =C2=A0Brian

    >
    > Is this coming from the longest routable IPv6 prefix ? Sort of analogy= to /24 in the IPv4 world ? Or something else ?=C2=A0
    >
    > I think LPM and CIDR techniques are pretty well established.=C2=A0
    >
    > Any fixed length of the address block with the meaning=C2=A0- do not u= se those bits inter or intra domain for anything useful even if your prefix= +node can happily fit in /32 seems just dead wrong to me. And that is irres= pective of any SRv6 discussion.=C2=A0
    >
    > In my books if I get allocated say /48 or /40 from RIR what I do with = the remaining bits is my own business.=C2=A0
    >
    > Best,
    > R.
    >
    > =C2=A0
    >
    >=C2=A0 =C2=A0 =C2=A0> Sorry, but it is a little bit late =E2=80=93 R= FC 8986 is already published.
    >
    >=C2=A0 =C2=A0 =C2=A0"Locators are assigned consistent with IPv6 in= frastructure allocation."
    >
    >=C2=A0 =C2=A0 =C2=A0Which means: 64 bits.
    >
    >=C2=A0 =C2=A0 =C2=A0I have no time to study compressed SIDs, but if the= y trample on the
    LOC they are not IPv6 addresses.
    >
    >=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Brian
    >
    >
    >=C2=A0 =C2=A0 =C2=A0---------------------------------------------------= -----------------
    >=C2=A0 =C2=A0 =C2=A0IETF IPv6 working group mailing list
    >=C2=A0 =C2=A0 =C2=A0ipv6@ietf.org <mailto:ipv6@ietf.org> >=C2=A0 =C2=A0 =C2=A0Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    <https://www.ietf.org/mailman/listinfo/i= pv6>
    >=C2=A0 =C2=A0 =C2=A0---------------------------------------------------= -----------------
    >

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    i= pv6@ietf.org
    Administrative Requests: https://www.ietf.o= rg/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    --000000000000b3a4aa05cdf1ca95-- From nobody Sat Oct 9 14:05:29 2021 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 4EE503A0882 for ; Sat, 9 Oct 2021 14:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 b3eSuP3V2a60 for ; Sat, 9 Oct 2021 14:05:03 -0700 (PDT) Received: from mail-vs1-xe2f.google.com (mail-vs1-xe2f.google.com [IPv6:2607:f8b0:4864:20::e2f]) (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 003CE3A0873 for ; Sat, 9 Oct 2021 14:04:57 -0700 (PDT) Received: by mail-vs1-xe2f.google.com with SMTP id y28so14481507vsd.3 for ; Sat, 09 Oct 2021 14:04:57 -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=b7I4riz/db4Crvll3RUzAopeasY1xKfcd8fdsgBWod0=; b=F9/qlMPstvmsxTo03X5yDuWRGBZYG7lsAiCZr7CCNwEUdXPtObDeGPROkvCvDG0Vy5 ugaooHlr6G5UgG22FhJrtDeH0aEfoE3QVoLT9Tp+MUNmcykOzhI+JcXVFPr1G9/FGYPr kLfkb6ztn32lq1WonJBoLMIuv9ACFJLQ5SERYYUOjg3VdS6Ltu7pBkytUS9jo2IBdKIa yttVnOiB7u97vWGy3vnZOd1rRfNGyBk9ME/btF0b8WKwwcWjzUAwcUTXQvUc+8ZNF7Tt rW1GS/4UH/o+T1aFtGDyjoNOZFNYhps5rr8XPpj/ImuKsdLclWZaIBg0P99POn5rDDmo vafA== 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=b7I4riz/db4Crvll3RUzAopeasY1xKfcd8fdsgBWod0=; b=rEwM7F7hv0K9C5KyPj1adwv/FCt10leEcBXqLryciuSexoskwytpiX/pXHzEik7OYv oojIl07zYRkFYB71nyIvpifBtVj/SokPB6iLTaWZkH2K9jTKrifhUouIv6LsYd0/fXe6 xJZVyO6VfSGpkYvg7Jfv+8nZxOE26wHvE16pV6Hdr0sQrWVeA1YnCnDQpo1o2Y9eolDC EcFxj+dWnzTAC9y5TkqYoC40DHAUw634dqgqweEsmqBzRf4tQ4zWqCNJOZOXp9IjBIYP 9cr+fvG6ekiVRJm+qZOv7Lb8k+h95qwWNZYZ70MbldC1jnXvrOJWn/gfjeqgxechCqdw j0Hg== X-Gm-Message-State: AOAM532BJUrAqIaDrSoqaj5pllCIN0/otl2/rUvAy7f/vf1I6PHOHcsv 9FWdvwuIze7wxgJSJtv9KcDDY3rGNKs0Jpysyuu+8w== X-Google-Smtp-Source: ABdhPJx7yUIW0jWCQ97ow2VMN/Qm+mA/sP+7bgCKcH2dIP6Eu+V+Bgeb5NNSFP3b24VeCja79iniV4/2SlKNAYt5k28= X-Received: by 2002:a67:2283:: with SMTP id i125mr17895782vsi.50.1633813496832; Sat, 09 Oct 2021 14:04:56 -0700 (PDT) MIME-Version: 1.0 References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> <423b08d46294454d9a9625990ce52acb@huawei.com> <322a8c29-e232-a39d-94ca-9c9cbf09c8d2@gmail.com> <9945ca9c-2ba7-bd00-6e3e-261c376a9718@gmail.com> In-Reply-To: From: Robert Raszuk Date: Sat, 9 Oct 2021 23:04:54 +0200 Message-ID: To: Mark Smith Cc: Brian E Carpenter , SPRING WG , 6MAN <6man@ietf.org> Content-Type: multipart/alternative; boundary="0000000000001bb61505cdf1d937" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 21:05:10 -0000 --0000000000001bb61505cdf1d937 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Please kindly correct me if I am wrong, but where do you see that SRv6 is mandated to use "IPv6 Interface IDs" ? On Sat, Oct 9, 2021 at 11:00 PM Mark Smith wrote: > It's stated twice in section 2.5 of RFC4291. > > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long and to be > constructed in Modified EUI-64 format. > > > All Global Unicast addresses other than those that start with binary > 000 have a 64-bit interface ID field (i.e., n + m =3D 64), formatted a= s > described in Section 2.5.1 . Global Unicast addresses that start with > binary 000 have no such constraint on the size or structure of the > interface ID field. > > > Please also see RFC7421, Analysis of the 64-bit Boundary in IPv6 > Addressing. > > > > > > > On Sun, 10 Oct 2021, 07:27 Robert Raszuk, wrote: > >> > Hi Brian, >>> > >>> >> Which means: 64 bits. >>> > >>> > Sorry but what is so magic about /64 here ? >>> >>> It is mandated by the current IPv6 addressing architecture. >> >> >> Really ? Where ? I am looking at RFC4291 and nowhere I can find /64 >> reference. >> >> Moreover sections 2.4 and 2.5 are very clear that there is no magic /64 >> hard defined. >> >> The text actually goes even further and says: >> >> Except for the knowledge of the subnet boundary discussed in the >> previous paragraphs, nodes should not make any assumptions about the >> structure of an IPv6 address. >> >> >> Thx, >> >> R. >> >> >> >> >> >>> Despite many discussions, there has never been consensus to change it. >>> So if /64 is not the boundary between the routeable part and the >>> host-specific part, it's not IPv6. >>> >>> Brian >>> >>> > >>> > Is this coming from the longest routable IPv6 prefix ? Sort of analog= y >>> to /24 in the IPv4 world ? Or something else ? >>> > >>> > I think LPM and CIDR techniques are pretty well established. >>> > >>> > Any fixed length of the address block with the meaning - do not use >>> those bits inter or intra domain for anything useful even if your >>> prefix+node can happily fit in /32 seems just dead wrong to me. And tha= t is >>> irrespective of any SRv6 discussion. >>> > >>> > In my books if I get allocated say /48 or /40 from RIR what I do with >>> the remaining bits is my own business. >>> > >>> > Best, >>> > R. >>> > >>> > >>> > >>> > > Sorry, but it is a little bit late =E2=80=93 RFC 8986 is alread= y >>> published. >>> > >>> > "Locators are assigned consistent with IPv6 infrastructure >>> allocation." >>> > >>> > Which means: 64 bits. >>> > >>> > I have no time to study compressed SIDs, but if they trample on >>> the >>> LOC they are not IPv6 addresses. >>> > >>> > Brian >>> > >>> > >>> > >>> -------------------------------------------------------------------- >>> > IETF IPv6 working group mailing list >>> > ipv6@ietf.org >>> > Administrative Requests: >>> https://www.ietf.org/mailman/listinfo/ipv6 >>> >>> > >>> -------------------------------------------------------------------- >>> > >>> >>> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > --0000000000001bb61505cdf1d937 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Please kindly correct me=C2=A0if I am wrong= , but where do you see that SRv6 is mandated to use "IPv6 Interface ID= s" ?=C2=A0

    On Sat, Oct 9, 2021 at 11:00 PM Mark Smith <markzzzsmith@gmail.com> wrote:
    It's stated twice in section 2.5 of RFC4= 291.

    For all unicast addresses,=
 except those that start with the binary
   value 000, Interface IDs are required to be 64 bits long and to be
   constructed in Modified EUI-64 format.

    = 
       All Global Unicast addresses other than those that star=
t with binary
   000 have a 64-bit interface ID field (i.e., n + m =3D 64), formatted as
   described in Section 2.5.1.  Global Unicast addresses =
that start with
   binary 000 have no such constraint on the size or structure of the
   interface ID field.

    Please also see RFC7421,=C2=A0=C2= =A0Analysis of the 64= -bit Boundary in IPv6 Addressing.






    On Su= n, 10 Oct 2021, 07:27 Robert Raszuk, <robert@raszuk.net> wrote:
    =
    > H= i Brian,=C2=A0
    >
    >> Which means: 64 bits.
    >
    > Sorry but what is so magic=C2=A0about /64 here ?

    It is mandated by the current IPv6 addressing architecture.

    Really ? Where ? I am looking at RFC4291 and nowhere I ca= n find /64 reference.=C2=A0

    Moreover sections = 2.4 and 2.5 are very clear that there is no magic /64 hard defined.=C2=A0

    The text actually goes even further and says:=C2=A0= 

       Except for the kno=
wledge of the subnet boundary discussed in the
   previous paragraphs, nodes should not make any assumptions about the
   structure of an IPv6 address.

    Thx,
    R.
    =


    =C2=A0
    Despite many discussions= , there has never been consensus to change it. So if /64 is not the boundar= y between the routeable part and the host-specific part, it's not IPv6.=

    =C2=A0 =C2=A0Brian

    >
    > Is this coming from the longest routable IPv6 prefix ? Sort of analogy= to /24 in the IPv4 world ? Or something else ?=C2=A0
    >
    > I think LPM and CIDR techniques are pretty well established.=C2=A0
    >
    > Any fixed length of the address block with the meaning=C2=A0- do not u= se those bits inter or intra domain for anything useful even if your prefix= +node can happily fit in /32 seems just dead wrong to me. And that is irres= pective of any SRv6 discussion.=C2=A0
    >
    > In my books if I get allocated say /48 or /40 from RIR what I do with = the remaining bits is my own business.=C2=A0
    >
    > Best,
    > R.
    >
    > =C2=A0
    >
    >=C2=A0 =C2=A0 =C2=A0> Sorry, but it is a little bit late =E2=80=93 R= FC 8986 is already published.
    >
    >=C2=A0 =C2=A0 =C2=A0"Locators are assigned consistent with IPv6 in= frastructure allocation."
    >
    >=C2=A0 =C2=A0 =C2=A0Which means: 64 bits.
    >
    >=C2=A0 =C2=A0 =C2=A0I have no time to study compressed SIDs, but if the= y trample on the
    LOC they are not IPv6 addresses.
    >
    >=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Brian
    >
    >
    >=C2=A0 =C2=A0 =C2=A0---------------------------------------------------= -----------------
    >=C2=A0 =C2=A0 =C2=A0IETF IPv6 working group mailing list
    >=C2=A0 =C2=A0 =C2=A0ipv6@ietf.org <mailto:ipv6@ietf.org> >=C2=A0 =C2=A0 =C2=A0Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    <https://www.ietf.org/mailman/listinfo/i= pv6>
    >=C2=A0 =C2=A0 =C2=A0---------------------------------------------------= -----------------
    >

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    i= pv6@ietf.org
    Administrative Requests: https://www.ietf.o= rg/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    --0000000000001bb61505cdf1d937-- From nobody Sat Oct 9 14:07:48 2021 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 EFD303A0891; Sat, 9 Oct 2021 14:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3o8KVBOynq7v; Sat, 9 Oct 2021 14:07:38 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0: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 5B8C53A0882; Sat, 9 Oct 2021 14:07:38 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id s75so6802910pgs.5; Sat, 09 Oct 2021 14:07:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=v5xvyNKaAqcilQZeCXJ/TpprXq4yx8h431jW287MK/o=; b=NPT6JCYs2uzC2MvrLFReYQDi01Y38hsQgzpwzyoj2t4zODya9h/VEkHxlHBQH1svKK AsMyBigZTiM8ufw1Y3Wtn31SivnLF1ojoCVx96hWu79Y9nMMUz8f8DmKyQiDnkLxygwz 3hggs3fxkaFc9OrjbvTYB1nxcnnlf4cL6a2s3cCK2VvJ4RAYbDzb6B/Ct7UfJKErcIJY P668H5yciTMrapyEf1MBDwF/Cf7qrYuYsaI4dDF3iUvtjIF/7sm0GXKtS+kdzMDpfQ0H e3HbU3dsL3+HMBjnxna5TbiVISA4EJ1EakdD9aK9jg8rle/7GD8DW8N8mtpOw5T4XtmN Kg5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=v5xvyNKaAqcilQZeCXJ/TpprXq4yx8h431jW287MK/o=; b=shc4LmMPWeWpRod+CfaURes4asPIVq5LXjKBtfaxS4RrjZ/LIv3JItcWoIDmukyYF5 cgaePw+2/ff3X1r5pNOSMroqdx1nrLfP3+Ky3qY1mDxsOFG1Wl6uMHgB2PU6kbal8uh8 BGqYHItZQ/dLkHCINT07BYU8zlM/pga/ofj8rAVnU1t5Dp0CXXMsaw9ugUyjLC3mF95Y eoXadsmWrDFwt+qRgFLohSz+B9FznzytvtQSBpSCZDOZBteiqznwd+/l5WAdY1ywwM+F /2Q7cW32K9tJSrbXi1ZeIjZ83SRV5OFB89g9vSFxpz4xy9PBkaMv1uxxLTw0XfEAt5WM sLYw== X-Gm-Message-State: AOAM5321ozZR/v0FpBUaRrt/ZTCwjT8eMea1CI6jtAtHluB1N4L3VhYj V40+si/4CqgaZWLRy9Lr7Xes1IwPDyJD3Q== X-Google-Smtp-Source: ABdhPJykJ2fYZQWvTfnsEALiOWezIPVMwCAbNCINMq6dYGgOtubtzQKz555BmgwysjgiPG+WW3nOIw== X-Received: by 2002:a65:6a4b:: with SMTP id o11mr10764787pgu.278.1633813656158; Sat, 09 Oct 2021 14:07:36 -0700 (PDT) Received: from ?IPv6:2406:e003:1018:b901:db7:d041:a2d:ce65? ([2406:e003:1018:b901:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id 2sm14314832pjt.23.2021.10.09.14.07.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 Oct 2021 14:07:35 -0700 (PDT) To: Robert Raszuk Cc: 6MAN <6man@ietf.org>, Vasilenko Eduard , SPRING WG References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> <423b08d46294454d9a9625990ce52acb@huawei.com> <322a8c29-e232-a39d-94ca-9c9cbf09c8d2@gmail.com> <9945ca9c-2ba7-bd00-6e3e-261c376a9718@gmail.com> From: Brian E Carpenter Message-ID: <00ff0027-16b1-faf0-d8ac-08a12486f2e9@gmail.com> Date: Sun, 10 Oct 2021 10:07:31 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 21:07:43 -0000 On 10-Oct-21 09:26, Robert Raszuk wrote: > > Hi Brian,=C2=A0 > > > >> Which means: 64 bits. > > > > Sorry but what is so magic=C2=A0about /64 here ? >=20 > It is mandated by the current IPv6 addressing architecture.=20 >=20 >=20 > Really ? Where ? I am looking at RFC4291 and nowhere I can find /64 ref= erence.=20 An address consists of a subnet prefix followed by an interface ID (see R= FC4291 section 2.5). Then: " For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long..." (RFC4291 section 2.5.1) (The second half of that sentence is updated by https://www.rfc-editor.or= g/rfc/rfc7136#section-5, but the 64 bits remains.) >=20 > Moreover sections 2.4 and 2.5 are very clear that there is no magic /64=20 hard defined.=20 The parameter is set unambiguously by section 2.5.1 and confirmed by RFC7= 136. I have argued that it should be taken out and put in a separate docu= ment, but there was no consensus to do so. Brian >=20 > The text actually goes even further and says:=C2=A0 >=20 > Except for the knowledge of the subnet boundary discussed in the > previous paragraphs, nodes should not make any assumptions about the= > structure of an IPv6 address. >=20 >=20 > Thx, >=20 > R. >=20 >=20 >=20 > =C2=A0 >=20 > Despite many discussions, there has never been consensus to change = it. So if /64 is not the boundary between the routeable part and the host= -specific part, it's not IPv6. >=20 > =C2=A0 =C2=A0Brian >=20 > > > > Is this coming from the longest routable IPv6 prefix ? Sort of an= alogy to /24 in the IPv4 world ? Or something else ?=C2=A0 > > > > I think LPM and CIDR techniques are pretty well established.=C2=A0= > > > > Any fixed length of the address block with the meaning=C2=A0- do = not use those bits inter or intra domain for anything useful even if your=20 prefix+node can happily fit in /32 seems just dead wrong to me. And that = is irrespective of any SRv6 discussion.=C2=A0 > > > > In my books if I get allocated say /48 or /40 from RIR what I do = with the remaining bits is my own business.=C2=A0 > > > > Best, > > R. > > > > =C2=A0 > > > >=C2=A0 =C2=A0 =C2=A0> Sorry, but it is a little bit late =E2=80=93=20 RFC 8986 is already published. > > > >=C2=A0 =C2=A0 =C2=A0"Locators are assigned consistent with IPv6 in= frastructure allocation." > > > >=C2=A0 =C2=A0 =C2=A0Which means: 64 bits. > > > >=C2=A0 =C2=A0 =C2=A0I have no time to study compressed SIDs, but i= f they trample on the > LOC they are not IPv6 addresses. > > > >=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Brian > > > > > >=C2=A0 =C2=A0 =C2=A0----------------------------------------------= ---------------------- > >=C2=A0 =C2=A0 =C2=A0IETF IPv6 working group mailing list > >=C2=A0 =C2=A0 =C2=A0ipv6@ietf.org > > >=C2=A0 =C2=A0 =C2=A0Administrative Requests: https://www.ietf.org/= mailman/listinfo/ipv6 > > > >=C2=A0 =C2=A0 =C2=A0----------------------------------------------= ---------------------- > > >=20 From nobody Sat Oct 9 14:13:39 2021 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 967863A08A6; Sat, 9 Oct 2021 14:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 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, FREEMAIL_REPLY=1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 JrLmK5tS6hF0; Sat, 9 Oct 2021 14:13:22 -0700 (PDT) Received: from mail-pf1-x432.google.com (mail-pf1-x432.google.com [IPv6:2607:f8b0:4864:20::432]) (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 59F4B3A089C; Sat, 9 Oct 2021 14:13:22 -0700 (PDT) Received: by mail-pf1-x432.google.com with SMTP id q19so10716471pfl.4; Sat, 09 Oct 2021 14:13:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=qecyP7MV4Oxw+ZO5kqESpcyzcyukYrBV1/zMbSvlHS8=; b=ZJl9vGl9WAY3QkyPgyuARr4Kf5ChK6vNpDMiMtO7+pSNdznrwtSh8iCZG8lEkjmu6K UYpf8elIslPh4fAsQsO2xfHwFSTgkFCbDM/IFOIH1/WvKQnMUh/a5Zm7cjQNS/VGuWZm DgO/BweBMSRHBzf/ar3BaYPVr6sHModFi3ihYErYeVUtIxO2/5ETHMbIfitgOyeAzbmT mwoZPlyHBgMh+V7VSIL915BysRxdeBGCdwlK0a1psT+zTKa7aBRoGY/L9dTjEZuVPkHF EWOp3rN5d87TETsl2UnDmb+K18UQLjP2tem5Ng1Ohk90oujf4DX8fqa0LhnhsVD1R+3p XGpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=qecyP7MV4Oxw+ZO5kqESpcyzcyukYrBV1/zMbSvlHS8=; b=sAxJpsl0xuH/Qqi5YM8zsS15hclrk1PHWKIn2gHJ8tVnkRseFqyjldsBgpgbSxZpfg JcerU1gu6jA/zkErTcTiNmRuckTdx0mfmAA5Bu1xUNABgHx35YlltsXUVwadiwMCrGfX oOirIwASxjpQIa4Pn8onh91blj+7d97uTbh8PfAneqD+LrOIOpqKjZ+w1YcrLCG3nd22 2GjMMl3J8kujlS+kk8ZQDUHkPjTM6WUddmnwzNg0iK86cVG+H09t2gJ9x/i7sWWgWMWo raHUO6+jMuZLUubT1n4TQc1FEIiruhfl91QEX9n8VKDcSPO25SeF1QmyxsDA/y9UB1e6 2B2w== X-Gm-Message-State: AOAM531tttrmTfXB6bBUIv5spDonok/ch32bwliyLmdC6yjTPGWA3Qhy hzOvYKfju2oNIaVMB+e0gHCgTdgYsZer3w== X-Google-Smtp-Source: ABdhPJyaHrlvevAhf/362sacLbgN7LR47wGEoLegNsE6lu14kNhUtG1hD6hll0ySZ0D7Mbmam6ZDqA== X-Received: by 2002:a05:6a00:148f:b0:44c:fb1b:b3eb with SMTP id v15-20020a056a00148f00b0044cfb1bb3ebmr3497649pfu.11.1633814000775; Sat, 09 Oct 2021 14:13:20 -0700 (PDT) Received: from ?IPv6:2406:e003:1018:b901:db7:d041:a2d:ce65? ([2406:e003:1018:b901:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id l10sm3518013pgn.22.2021.10.09.14.13.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 Oct 2021 14:13:20 -0700 (PDT) To: Robert Raszuk , Mark Smith Cc: SPRING WG , 6MAN <6man@ietf.org> References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> <423b08d46294454d9a9625990ce52acb@huawei.com> <322a8c29-e232-a39d-94ca-9c9cbf09c8d2@gmail.com> <9945ca9c-2ba7-bd00-6e3e-261c376a9718@gmail.com> From: Brian E Carpenter Message-ID: <938b4efa-1383-beb8-5dc7-e2a951d15457@gmail.com> Date: Sun, 10 Oct 2021 10:13:16 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 21:13:27 -0000 On 10-Oct-21 10:04, Robert Raszuk wrote: >=20 > Please kindly correct me=C2=A0if I am wrong, but where do you see that = SRv6 is mandated to use "IPv6 Interface IDs" ?=20 I have no idea, but IPv6 is mandated to use IPv6 Interface IDs. If that d= oesn't apply to SRV6, then it's impossible to claim that SRV6 is IPv6. This isn't just academic standards-oriented formalism. As others have poi= nted out, it has very significant deployment and operational implications= , given that most products support IPv6, not SRV6. Brian >=20 > On Sat, Oct 9, 2021 at 11:00 PM Mark Smith > wrote: >=20 > It's stated twice in section 2.5 of RFC4291. >=20 > For all unicast addresses, except those that start with the binary > value 000, Interface IDs are required to be 64 bits long and to = be > constructed in Modified EUI-64 format. >=20 >=20 > All Global Unicast addresses other than those that start with bi= nary > 000 have a 64-bit interface ID field (i.e., n + m =3D 64), forma= tted as > described in Section 2.5.1 . Global Unicast addresses that start with > binary 000 have no such constraint on the size or structure of t= he > interface ID field. >=20 >=20 > Please also see RFC7421,=C2=A0=C2=A0Analysis of the 64-bit Boundary=20 in IPv6 Addressing. >=20 >=20 >=20 >=20 >=20 >=20 > On Sun, 10 Oct 2021, 07:27 Robert Raszuk, > wrote: >=20 > > Hi Brian,=C2=A0 > > > >> Which means: 64 bits. > > > > Sorry but what is so magic=C2=A0about /64 here ? >=20 > It is mandated by the current IPv6 addressing architecture.=20 >=20 >=20 > Really ? Where ? I am looking at RFC4291 and nowhere I can find=20 /64 reference.=C2=A0 >=20 > Moreover sections 2.4 and 2.5 are very clear that there is no m= agic /64 hard defined.=C2=A0 >=20 > The text actually goes even further and says:=C2=A0 >=20 > Except for the knowledge of the subnet boundary discussed in=20 the > previous paragraphs, nodes should not make any assumptions a= bout the > structure of an IPv6 address. >=20 >=20 > Thx, >=20 > R. >=20 >=20 >=20 > =C2=A0 >=20 > Despite many discussions, there has never been consensus to=20 change it. So if /64 is not the boundary between the routeable part and t= he host-specific part, it's not IPv6. >=20 > =C2=A0 =C2=A0Brian >=20 > > > > Is this coming from the longest routable IPv6 prefix ? So= rt of analogy to /24 in the IPv4 world ? Or something else ?=C2=A0 > > > > I think LPM and CIDR techniques are pretty well establish= ed.=C2=A0 > > > > Any fixed length of the address block with the meaning=C2= =A0- do not use those bits inter or intra domain for anything useful even=20 if your prefix+node can happily fit in /32 seems just dead wrong to me. A= nd that is irrespective of any SRv6 discussion.=C2=A0 > > > > In my books if I get allocated say /48 or /40 from RIR wh= at I do with the remaining bits is my own business.=C2=A0 > > > > Best, > > R. > > > > =C2=A0 > > > >=C2=A0 =C2=A0 =C2=A0> Sorry, but it is a little bit late =E2= =80=93 RFC 8986 is already published. > > > >=C2=A0 =C2=A0 =C2=A0"Locators are assigned consistent with=20 IPv6 infrastructure allocation." > > > >=C2=A0 =C2=A0 =C2=A0Which means: 64 bits. > > > >=C2=A0 =C2=A0 =C2=A0I have no time to study compressed SID= s, but if they trample on the > LOC they are not IPv6 addresses. > > > >=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Brian > > > > > >=C2=A0 =C2=A0 =C2=A0--------------------------------------= ------------------------------ > >=C2=A0 =C2=A0 =C2=A0IETF IPv6 working group mailing list > >=C2=A0 =C2=A0 =C2=A0ipv6@ietf.org <= mailto:ipv6@ietf.org > > >=C2=A0 =C2=A0 =C2=A0Administrative Requests: https://www.i= etf.org/mailman/listinfo/ipv6 > > > >=C2=A0 =C2=A0 =C2=A0--------------------------------------= ------------------------------ > > >=20 > ---------------------------------------------------------------= ----- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/= ipv6 > ---------------------------------------------------------------= ----- >=20 From nobody Sat Oct 9 14:26:13 2021 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 361CF3A08CE for ; Sat, 9 Oct 2021 14:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 1_wi59aKGiKY for ; Sat, 9 Oct 2021 14:25:53 -0700 (PDT) Received: from mail-vk1-xa2a.google.com (mail-vk1-xa2a.google.com [IPv6:2607:f8b0:4864:20::a2a]) (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 E06C73A08CF for ; Sat, 9 Oct 2021 14:25:52 -0700 (PDT) Received: by mail-vk1-xa2a.google.com with SMTP id n201so4950791vkn.12 for ; Sat, 09 Oct 2021 14:25:52 -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=pY6zW+S3Q7lhs5yDuwCfAIwGW2Tj1xDiyp9zUHlH/gc=; b=Xffnm2vvZYs4BwtonaTmw4j7nkNkeDt7k4Q85t4PfgIczOn9aMBvafi9v4GSE3/3qv krfqnq+bwH4WATSWwUoC2RZ/lwgOfPZO+xIT1uo0jKBH5DioMqbToWmBcgk697ExxLOs 8yZEryeAOpNQVtU0nDHlEAU4vQct4jPilz/uInJqbIYLWV9EQ7ZVIvPgAr5opHUM0EXq GK9N6wE0qnz/LSTC1n4P2tygZw1D1/MYhENAZqgGSYBurp3rO6tfpuQ+FFTDw6DrllkI 3F6zuMZX0C/0fNua5zMwg32OJeVCEysMGHCp2t3mV3SEs/AAUW3j8QbQodS46vMBzUd7 TyaQ== 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=pY6zW+S3Q7lhs5yDuwCfAIwGW2Tj1xDiyp9zUHlH/gc=; b=i6xVb22woRSg5yAnpzIpXWl/8+EzKn44nHZzyj/eGlPXaogJq+vPJy78Bcix7VwxJ6 vvHoi4xeNKKmPQ5yX4kNWmBTuScaxDfPDzus+rhC6nMJx7Y1IR0TD6GBV17tAWzEz65L wOYMw3c7k7pjbJpSVvMptYox3yFO5AL5EddCRtqFOPJgG+BLfpwuW1c37GmurQZVDOew c/iv4RbFlVrvZZVtjveMZqCDmjH0SFf8A1DiYAR2S1hKV6f3MFA7ljfvtwXz1TlJGr8I rp1YSFovi5XiWQYIRZXFT7ubZgZnreEG4179A4FkClpNSsB4x3k8c5hcNvA6wlHPy0sB PtgA== X-Gm-Message-State: AOAM530MIjQcgarDWq/q364t3LFndY/oQln2TYCyxVDHSiKk+LorCZ8O 83XMSl+lovElVzVq37yMdMpiw12HKHLOdfqUbiPGEA== X-Google-Smtp-Source: ABdhPJwjJYxs4c4cdEgbVECh3c+sQ9ArrLKZVVruLE026hozKyhTeXyjewOqKbFbCehuk78ExSz6FRPrkDAsZL8x1W0= X-Received: by 2002:a05:6122:658:: with SMTP id h24mr15420091vkp.15.1633814749207; Sat, 09 Oct 2021 14:25:49 -0700 (PDT) MIME-Version: 1.0 References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> <423b08d46294454d9a9625990ce52acb@huawei.com> <322a8c29-e232-a39d-94ca-9c9cbf09c8d2@gmail.com> <9945ca9c-2ba7-bd00-6e3e-261c376a9718@gmail.com> <938b4efa-1383-beb8-5dc7-e2a951d15457@gmail.com> In-Reply-To: <938b4efa-1383-beb8-5dc7-e2a951d15457@gmail.com> From: Robert Raszuk Date: Sat, 9 Oct 2021 23:25:46 +0200 Message-ID: To: Brian E Carpenter Cc: Mark Smith , SPRING WG , 6MAN <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000c1784b05cdf22304" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 21:25:57 -0000 --000000000000c1784b05cdf22304 Content-Type: text/plain; charset="UTF-8" Hi Brian & all, Last email from me on this topic as I am pretty sure this will otherwise never end. I am not sure anyone will hardly argue that SRv6 is IPv6 or not. Maybe it is IPv6+ fully backwards compatible with IPv6. What really matters to me is that SRv6 packets can be forwarded by not SR aware IPv6 network elements with no change to data plane and control plane required. That's it - no more - no less. And so far all SPRING work on SRv6 including the draft in the subject line of this mail meets that. Kind regards, Robert On 10-Oct-21 10:04, Robert Raszuk wrote: > > > > Please kindly correct me if I am wrong, but where do you see that SRv6 > is mandated to use "IPv6 Interface IDs" ? > > I have no idea, but IPv6 is mandated to use IPv6 Interface IDs. If that > doesn't apply to SRV6, then it's impossible to claim that SRV6 is IPv6. > > This isn't just academic standards-oriented formalism. As others have > pointed out, it has very significant deployment and operational > implications, given that most products support IPv6, not SRV6. > > Brian --000000000000c1784b05cdf22304 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Brian & all,

    Last ema= il from me on this topic as I am pretty sure this will otherwise never end.= =C2=A0

    I am not sure anyone will hardly argue that= SRv6 is IPv6 or not. Maybe it is IPv6+ fully backwards compatible with IPv= 6.=C2=A0

    What really matters to me is that SRv6 pa= ckets can be forwarded by not SR aware IPv6 network=C2=A0elements with no c= hange to data plane and control plane required. That's it - no more - n= o less.=C2=A0

    And so far all SPRING work on SRv6 i= ncluding the draft in the=C2=A0subject line of this mail meets that.=C2=A0<= /div>

    Kind regards,
    Robert


    On 10-Oct-21= 10:04, Robert Raszuk wrote:
    >
    > Please kindly correct me=C2=A0if I am wrong, but where do you see that= SRv6 is mandated to use "IPv6 Interface IDs" ?

    I have no idea, but IPv6 is mandated to use IPv6 Interface IDs. If that doe= sn't apply to SRV6, then it's impossible to claim that SRV6 is IPv6= .

    This isn't just academic standards-oriented formalism. As others have p= ointed out, it has very significant deployment and operational implications= , given that most products support IPv6, not SRV6.

    =C2=A0 =C2=A0Brian
    --000000000000c1784b05cdf22304-- From nobody Sat Oct 9 14:55:40 2021 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 4EC5E3A0AA4; Sat, 9 Oct 2021 14:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 AXACV5JdtsPe; Sat, 9 Oct 2021 14:55:11 -0700 (PDT) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 A5AF03A0859; Sat, 9 Oct 2021 14:55:11 -0700 (PDT) Received: by mail-il1-x129.google.com with SMTP id x1so390454ilv.4; Sat, 09 Oct 2021 14:55:11 -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=Ur8xS49kDfRSac2XxH/9fxbsG27coQcr+geTPkQyXX8=; b=AWYoGdGiIgDj7EZLKshmgRj/GVC8e/QJeI5trzCbMyv9XlMkd5wYUhGrFbCwvVktWd eAN6Kh1/V2FJgQf5n4aR+sSle8DdfztRcWNyyEJKHIoPEdvf8A6+/m8z7OEdHhipOrRk cUCt+ypQjx4tYeZnKATg9Sxq0v4s1kL145puIRttqyG8dEegEbntQwzQLfj2L5r+HwlO FQsrLYR1gMZl3oFayhlzP6g++bT5e8xXtzvlOPArpwQzxopvrctF8Zln668Hcnqqc714 Gc8IaZV3nnMAwy+7u1OMIOE+7ECl9wL8n3FsHjlt93wzCUuLCW4pTxCywvoyB3ZABTlR L6SA== 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=Ur8xS49kDfRSac2XxH/9fxbsG27coQcr+geTPkQyXX8=; b=IHVrBNklTvd4rgct+Pdb9BLKXW86rxoi0enVbDsvQsBzS1fEVbTSJElc0KrmIkRD2X pDmbBVzqXCHrCrekvstYbiIi+qababffU/2778LLr+TSsxW3xKgg7Zcp8iSsfM42PFGY DipfUV/Kh5kJVsaqra60C3gBKFOlRYG9QVWIrf9sjAHax37RqGNLgejBL5B1yb6WDRIp ItHda3ZbHsXrdMuQkbe8ErlRymwGdOzoO+i2lvc90vg0Q4fX3anppmOxQ8SaPhfQLFYO sAWioyUbBpX7Du/2K9SmUErI4gKkUHnNw0Pv1h3uEHPEjGnree2AkV75Prp1JgE+LQ3L 0YVw== X-Gm-Message-State: AOAM531XX7yRKwOTt5r/M92OZlRmg9VKl7EkvUi06IldnvAVtilabUSt FvqIvQZrQ+d4BqVRa+mDT2VVJYMMols0uXfnSgw= X-Google-Smtp-Source: ABdhPJzoWIrIulr2CzK7VK8XyI9M+unGYGqUiWX29teQr5p/lbe8xSxSn9u/2Sxf5VPElqzMvQBIstIgBVQkERS+2vQ= X-Received: by 2002:a05:6e02:1a6d:: with SMTP id w13mr12765299ilv.203.1633816510763; Sat, 09 Oct 2021 14:55:10 -0700 (PDT) MIME-Version: 1.0 References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> <423b08d46294454d9a9625990ce52acb@huawei.com> <322a8c29-e232-a39d-94ca-9c9cbf09c8d2@gmail.com> <9945ca9c-2ba7-bd00-6e3e-261c376a9718@gmail.com> <938b4efa-1383-beb8-5dc7-e2a951d15457@gmail.com> In-Reply-To: From: Mark Smith Date: Sun, 10 Oct 2021 08:54:58 +1100 Message-ID: To: Robert Raszuk Cc: Brian E Carpenter , SPRING WG , 6MAN <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000c0994505cdf28cf8" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 21:55:15 -0000 --000000000000c0994505cdf28cf8 Content-Type: text/plain; charset="UTF-8" On Sun, 10 Oct 2021, 08:25 Robert Raszuk, wrote: > Hi Brian & all, > > Last email from me on this topic as I am pretty sure this will otherwise > never end. > > I am not sure anyone will hardly argue that SRv6 is IPv6 or not. Maybe it > is IPv6+ fully backwards compatible with IPv6. > > What really matters to me is that SRv6 packets can be forwarded by not SR > aware IPv6 network elements with no change to data plane and control plane > required. That's it - no more - no less. > > And so far all SPRING work on SRv6 including the draft in the subject line > of this mail meets that. > You've demonstrated you don't know enough IPv6 to say that. That is also something that 6man are the authority to say, not SPRING. > Kind regards, > Robert > > > On 10-Oct-21 10:04, Robert Raszuk wrote: >> > >> > Please kindly correct me if I am wrong, but where do you see that SRv6 >> is mandated to use "IPv6 Interface IDs" ? >> >> I have no idea, but IPv6 is mandated to use IPv6 Interface IDs. If that >> doesn't apply to SRV6, then it's impossible to claim that SRV6 is IPv6. >> >> This isn't just academic standards-oriented formalism. As others have >> pointed out, it has very significant deployment and operational >> implications, given that most products support IPv6, not SRV6. >> >> Brian > > --000000000000c0994505cdf28cf8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Sun, 10 Oct 2021, 08:25 Robert Raszuk, <robert@raszuk.net> wrote:
    Hi Brian & all,
    =

    Last email from me on this topic as I am pretty sure th= is will otherwise never end.=C2=A0

    I am not sure a= nyone will hardly argue that SRv6 is IPv6 or not. Maybe it is IPv6+ fully b= ackwards compatible with IPv6.=C2=A0

    What really m= atters to me is that SRv6 packets can be forwarded by not SR aware IPv6 net= work=C2=A0elements with no change to data plane and control plane required.= That's it - no more - no less.=C2=A0

    And so f= ar all SPRING work on SRv6 including the draft in the=C2=A0subject line of = this mail meets that.=C2=A0

    You've demonstrated you don't kn= ow enough IPv6 to say that. That is also something that 6man are the author= ity to say, not SPRING.

    =


    Kind regards,
    Robert


    On 10-Oct-21 10:04, Robert Raszuk w= rote:
    >
    > Please kindly correct me=C2=A0if I am wrong, but where do you see that= SRv6 is mandated to use "IPv6 Interface IDs" ?

    I have no idea, but IPv6 is mandated to use IPv6 Interface IDs. If that doe= sn't apply to SRV6, then it's impossible to claim that SRV6 is IPv6= .

    This isn't just academic standards-oriented formalism. As others have p= ointed out, it has very significant deployment and operational implications= , given that most products support IPv6, not SRV6.

    =C2=A0 =C2=A0Brian
    --000000000000c0994505cdf28cf8-- From nobody Sat Oct 9 15:06:05 2021 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 7768D3A0AA8; Sat, 9 Oct 2021 15:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 a2NcQglOMegk; Sat, 9 Oct 2021 15:04:45 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B84DE3A0AA5; Sat, 9 Oct 2021 15:04:43 -0700 (PDT) X-Envelope-To: spring@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 199M4awU077567 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Oct 2021 23:04:37 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local To: Robert Raszuk Cc: Brian E Carpenter , SPRING WG , 6MAN <6man@ietf.org> References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> <423b08d46294454d9a9625990ce52acb@huawei.com> <322a8c29-e232-a39d-94ca-9c9cbf09c8d2@gmail.com> <9945ca9c-2ba7-bd00-6e3e-261c376a9718@gmail.com> <938b4efa-1383-beb8-5dc7-e2a951d15457@gmail.com> From: Nick Hilliard Message-ID: Date: Sat, 9 Oct 2021 23:04:35 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.49 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 22:04:48 -0000 Robert Raszuk wrote on 09/10/2021 22:25: > What really matters to me is that SRv6 packets can be forwarded by not > SR aware IPv6 network elements with no change to data plane and control > plane required. That's it - no more - no less. Andrew Alston's email indicates that there is at least one existing ipv6 network deployment where this is not the case. It is unlikely that this is an isolated example: there's no shortage of brownfield ipv6 deployments on the internet. As a general comment, protocol specification is about ensuring wide-scale interoperability, so redefining well-known semantic constructions is something that's likely to cause difficulties. The lower in the stack you go, the more likely you are to run into problems. Nick From nobody Sat Oct 9 16:17:53 2021 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 10CBB3A0B66 for ; Sat, 9 Oct 2021 16:17:50 -0700 (PDT) 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, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=liquidtelecom.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 0ihp_YJ5pnON for ; Sat, 9 Oct 2021 16:17:45 -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 8C2503A0B58 for ; Sat, 9 Oct 2021 16:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquidtelecom.com; s=mimecast20210406; t=1633821460; 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=uLW9kArP+AB7t1f6QQJfRKkvW3OW4yqnr2qekOwbxsQ=; b=NZQkKllRZVA8eTHC0/adpKlFd436urwoHBh3Wz3Z4NP34Se0Pjx9eyGAo06eK1IpgAJ3Gm qVvLGFYxH35hXhse4xNGnHAwMeqGULrnoY9nz4LIjb+fFa9B39rkiUzYm28//QAsTF0UUI oz2yUdn357Q3RjV3cyf9B+924ve9Fs4= Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02lp2052.outbound.protection.outlook.com [104.47.6.52]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-71-9FHxUGbvMAS6aUT3WXJT4w-2; Sun, 10 Oct 2021 00:17:38 +0100 X-MC-Unique: 9FHxUGbvMAS6aUT3WXJT4w-2 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com (2603:10a6:20b:346::6) by AS8PR03MB7602.eurprd03.prod.outlook.com (2603:10a6:20b:34d::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.19; Sat, 9 Oct 2021 23:17:37 +0000 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9]) by AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9%5]) with mapi id 15.20.4587.024; Sat, 9 Oct 2021 23:17:36 +0000 From: Andrew Alston To: Robert Raszuk , Brian E Carpenter CC: SPRING WG , 6MAN <6man@ietf.org> Thread-Topic: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 Thread-Index: Ade3AXyWK2NzAamgSlCvJ497z/5RLwC/aCkQAFbElIAAFRrfwAAcSamAAAzi0oAABMpdgAAVTRUAABGuFAAAEYXYAAAA3bsAAAEx7IAAACVnAAAASs0AAABvwwAACjELgA== Date: Sat, 9 Oct 2021 23:17:36 +0000 Message-ID: <84FFF3E9-267B-4EC7-BB5B-07C6E0B93DD2@liquidtelecom.com> References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> <423b08d46294454d9a9625990ce52acb@huawei.com> <322a8c29-e232-a39d-94ca-9c9cbf09c8d2@gmail.com> <9945ca9c-2ba7-bd00-6e3e-261c376a9718@gmail.com> <938b4efa-1383-beb8-5dc7-e2a951d15457@gmail.com> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.53.21091200 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 88d08e1d-8acc-40a4-d9a1-08d98b7afb66 x-ms-traffictypediagnostic: AS8PR03MB7602: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: IUfyDOaffs4HDXeK3YmkQTDfq98ZAbFDfr24pTsZ6Clk7YbNxcmuJDRwIy85P9NBhbOs0rzHMdrhH7STRRyPmlDGB5fjZ2umOT5Efki/fkFVqH6xUoa2OpSsyP+aCQ0++gLi41gZWR5vEjSVPbi92kgcofQMrCgrL7TMJI3U0T1L3Kf7ClDS6r3JmucXB70kf0RKWNNWU7r524QH3n4qlk4UEBIkFn4lcaTFVfQfQBHhJmIENPxRoBVXvl3r/LyddvXh1/CTPI83TcFTmBq46VwyFAKnK1XvYmDxBaglhyuscllVpAt/0iTLY2PPsWopSIoTcqSjzt9jw5cRM4EZrfvWSXBcOTlxRZjgIR3c8XZZWISjL3mnlIF78vFkdlBJMcJ8zbYKuSIk/mcK8C0gzRtcKHMp6LrHdN7fQfK4N0oSRpFYcDikcJIKYNiu4MB+bsKTzqLQtRgPLGcV6xAnMWhGLtd9miJvLL3CE7RTHZq8aB2pgeyMxLuasem4S3FCT6nItgVsoVP3+3Lo/7ZTscpSEV6CaYX70HZTKCsm/9RTToQY3qtmn7ecBxqBKf/29wOnMGcqoU3/1H2dQTukxxF4PFTIg1poW5eE43pHwTpvuh69sMzgNIOPN2uMlv8rWTN94XQcOrbShB4qF0rcUYjHvdGD7C06AhZHt+Ol8E/sX6PslKihT7XHdPptvNtZLBncEVzvHpJb5zFdkMder+0Y8YS2kf8KQx/oSzyxuaeGnHLwkhEOnynqz5tau50sbmBTvpdEo1bEkEXmEsSCZfiSSToyNtBU6npwh5CYZIsgC2GtvbF951o4QUS2GICD x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR03MB7622.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66946007)(38100700002)(64756008)(6512007)(6506007)(53546011)(6486002)(66476007)(91956017)(76116006)(5660300002)(33656002)(122000001)(2906002)(86362001)(966005)(508600001)(316002)(36756003)(54906003)(110136005)(66446008)(4326008)(186003)(66556008)(38070700005)(2616005)(8936002)(8676002)(71200400001)(166002)(45980500001); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MWREckJZZml1MFJ6d3lYZzFGWWhWc3c3NERsS3RLcERXWmRQM1JQNUszSXF6?= =?utf-8?B?aHdBOTc2SHZ0N1FnODR0M3o0VDcxZG5TL283VVl2bzRqam80bnJKUWVhUUdW?= =?utf-8?B?akttbXpLVkFHRmVjUXBWbUFmbFZKQzF2blQ1UHpHcmlkUEE2Um02M0dNdWFp?= =?utf-8?B?OWRCTHdHSzgzMDR1ZXdqYkRZejdHTzdZTktTWWJiQUtzcGNvQ1kyU0tLSUxN?= =?utf-8?B?SWt6d1JQbFVMWFFCbE8reHdGYVlDMlpZL1JMcTBrTFl5QkpEb3ZGYVlaTHAx?= =?utf-8?B?UzVaK3A5YThwOUxPNVY5T3ZJbXU4R3p3K3liUDRDaldYZ0dEUnYrVmwrUXYx?= =?utf-8?B?ZnV6YWRLYzVqNElRaEZpTVEzQ3F3Q1p0Ym9sUjNlelUycVdTUitNVng3dlYv?= =?utf-8?B?S2lLMFN1SEdycDdLWjlCcE13eGZrc1dHOGJqNkJyMXlyUEV2VEhrZmpEbFh6?= =?utf-8?B?enBJaDY2WEdLbWY1bk5uMjZZWUJMa2UxWFQ3V1JXcEQ0azFubE5iNE1VNGUx?= =?utf-8?B?ZW1HTEwza1hkS25KNmo4bFBUTnNVY2hqbGZDMWEzQk5pa3lWMFphdUVKaldY?= =?utf-8?B?cEY5bXZJZW5Ia0FFNVQxWlpDN1dvYnZ0Rk9JK1lxbDlxSFM1aVNCZU1NTnRT?= =?utf-8?B?UHFDd2t5dVJHd1FETzFJRGgyVVNaZ01HamEzc01KOHgvVzdZU3VMOHhMQy82?= =?utf-8?B?bDk0cE9rYk5LVmMyZVF1cFRtMlpGMVlTZ2pKVWFnMjBZTzU0WTFTYXlRNUx4?= =?utf-8?B?ekFJNitucXMxZzM5TFpJc3VhZEdBQmhXN0xpVEhmNmZoNm1lYVlCV2VpRmQ4?= =?utf-8?B?NXVJRmFOQllGSGJDb1ZZeCs0eWNJOWJyTVpvWk5NVE5uVFNLK1NrMnhOQVhS?= =?utf-8?B?U0lFWjFZV01odjFkVHZZZXhpTDdkd0loV1hKek1SUVN3VXV1VDhMWVlhOTRX?= =?utf-8?B?dDRkWVlaWkh5UHJ4L3VkaTdDNERkS0ZTNXR4OGRFeGJsS09naW9lYVpNVlR5?= =?utf-8?B?WGg2bHZPSm5BVTlvdkZONUsyWGtjSWplY2RxS3JvKzJoZEpVeUdUakVvZjdG?= =?utf-8?B?bFVFRTJxcFZXNU9IbS9sS2NPVnBvTmNvWmFqTktkSU8yd1BNVHdjZG5oRGE3?= =?utf-8?B?Njk2Z3BOWmhtaXBVdHk2WHg0aVNxOFRXWU10T21qUEZYRVR2VFVTVW5saXZF?= =?utf-8?B?OW5VU0luZ3E0cTU3NUtMZEVYTnIvUi9WUWlLVjRqUGVRQjJJRTQ3V1BPamY3?= =?utf-8?B?dnd3S1FJUWFYUFNOTWN0SkN5MHZPeGRKR1EzcHpNQ0FJNElMMVh3MjI3Q2RL?= =?utf-8?B?MkNYS25DeXFXWUVHS1lZWWQ5ZUxpREtJTktUZVBieCs4RzFKbW1SSFBDUHU2?= =?utf-8?B?Z25GcjVCeS9Sa0k4QWNnVGxHdXRmSlNZd3I4cXRJZlkwbDJBbVoxN3dac2g0?= =?utf-8?B?N0dzYzJDYXpSeDM4c3AvVC81Z0FHUFI5bUlWbFdzMmF6TnZIZHptVHp5ZzR0?= =?utf-8?B?dUl2OGJ5NXlyT1cyL3ZsNytBcWUzaW90dnQ3V3hTV05FNkVPS0FhR2c1ZDlk?= =?utf-8?B?L2ZPVjhoWDdNNmEyb2MrSmsrWHRPd2w5emIrV01TTVZRTWNGNlRJU2hZRDB3?= =?utf-8?B?emRyblNpeU9hVDBIN1VaTHhXWmRUMFk5V3p1RkRjL3V1VW91NXNpeGFCbHg5?= =?utf-8?B?UFY4MHdqMFBLZStGYnRzZ0VBbUtQR0VlOEFLNCt0cmpEeVhiVkVSNTBoeHJZ?= =?utf-8?B?dEVuakVWSVRiTEVqNU1ScDZQeERVVEk4ZEVCSTFRYi93NUFSNVVaSGxyanZz?= =?utf-8?B?R3Bpb2Vha3M4WnhCdTlQSkFoNDJkbmhRSmxFUHlGdXhHMWtvdHp1TkU5V2w5?= =?utf-8?Q?CDfB17nf2pOuz?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB7622.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 88d08e1d-8acc-40a4-d9a1-08d98b7afb66 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2021 23:17:36.9111 (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: zJkHkbKdFp0d+Auf7aLU5oaufUDLb/V5UHVKzmQMBmpliREcpes3iKcYkJhQkfvT4CFrfV5XJTzAsoiKG9y2/4JGdK0htCyTCwZEWHgZQXg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7602 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquidtelecom.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Language: en-GB Content-Type: multipart/alternative; boundary="_000_84FFF3E9267B4EC7BB5B07C6E0B93DD2liquidtelecomcom_" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 23:17:50 -0000 --_000_84FFF3E9267B4EC7BB5B07C6E0B93DD2liquidtelecomcom_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Um9iZXJ0LA0KDQpJIHdvdWxkIHNheSB0aGF0IG1hbnkgb2YgeW91ciBhcmd1bWVudHMg4oCTIHBh cnRpY3VsYXJseSB0aGF0IHNydjYgaXMgbm90IGV4YWN0bHkgaXB2NiDigJMgaWYgbXkgaW50ZXJw cmV0YXRpb24gb2YgeW91ciBlbWFpbHMgaXMgY29ycmVjdCDigJMgaW5kaWNhdGUgdGhhdCBpbmRl ZWQg4oCTIHdlIHNlZW0gdG8gYmUgaW4gdGhlIHRlcnJhaW4gb2YgbW9kaWZ5aW5nIG9yIGV4dGVu ZGluZyB0aGluZ3MgdGhhdCB3b3VsZCBwdXQgdGhpcyB3ZyBJbiB2aW9sYXRpb24gb2YgaXRzIG93 biBjaGFydGVyIOKAkyBhbmQgdGhlIHN0YXRlbWVudCBtYWRlIGJ5IHRoZSBjaGFpcnMgaGVyZTog aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJpbmcvdkNjOUNrdnd1NUhB LVJDbGVWNzEyZHNBNU9BLw0KDQpBcyBzdWNoIOKAkyBjYW4geW91IHBvaW50IG1lIHRvIHRoZSBJ LUTigJlzIGZvciB0aGUgcmVsZXZhbnQgZG9jdW1lbnRzIHdoaWNoIHBlcm1pdCB0aGVzZSBtb2Rp ZmljYXRpb25zIG9yIGV4dGVuc2lvbnM/IE9yLCBjYW4geW91IGNsYXJpZnkgaG93IHdoYXQgd2Ug c2VlaW5nIGluIHRoaXMgZGViYXRlIGRvZXMgbm90IHJ1biB1cCBhZ2FpbnN0IHRoZSBhZm9yZW1l bnRpb25lZCBzdGF0ZW1lbnQgYW5kIHRoZSB3ZyBjaGFydGVyPw0KDQpUaGFua3MNCg0KQW5kcmV3 DQoNCg0KRnJvbTogaXB2NiA8aXB2Ni1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgUm9i ZXJ0IFJhc3p1ayA8cm9iZXJ0QHJhc3p1ay5uZXQ+DQpEYXRlOiBTdW5kYXksIDEwIE9jdG9iZXIg MjAyMSBhdCAwMDoyNg0KVG86IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBn bWFpbC5jb20+DQpDYzogU1BSSU5HIFdHIDxzcHJpbmdAaWV0Zi5vcmc+LCA2TUFOIDw2bWFuQGll dGYub3JnPg0KU3ViamVjdDogUmU6IFtzcHJpbmddIGRyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5n LXNydjYtc3JoLWNvbXByZXNzaW9uLTAyDQoNCkhpIEJyaWFuICYgYWxsLA0KDQpMYXN0IGVtYWls IGZyb20gbWUgb24gdGhpcyB0b3BpYyBhcyBJIGFtIHByZXR0eSBzdXJlIHRoaXMgd2lsbCBvdGhl cndpc2UgbmV2ZXIgZW5kLg0KDQpJIGFtIG5vdCBzdXJlIGFueW9uZSB3aWxsIGhhcmRseSBhcmd1 ZSB0aGF0IFNSdjYgaXMgSVB2NiBvciBub3QuIE1heWJlIGl0IGlzIElQdjYrIGZ1bGx5IGJhY2t3 YXJkcyBjb21wYXRpYmxlIHdpdGggSVB2Ni4NCg0KV2hhdCByZWFsbHkgbWF0dGVycyB0byBtZSBp cyB0aGF0IFNSdjYgcGFja2V0cyBjYW4gYmUgZm9yd2FyZGVkIGJ5IG5vdCBTUiBhd2FyZSBJUHY2 IG5ldHdvcmsgZWxlbWVudHMgd2l0aCBubyBjaGFuZ2UgdG8gZGF0YSBwbGFuZSBhbmQgY29udHJv bCBwbGFuZSByZXF1aXJlZC4gVGhhdCdzIGl0IC0gbm8gbW9yZSAtIG5vIGxlc3MuDQoNCkFuZCBz byBmYXIgYWxsIFNQUklORyB3b3JrIG9uIFNSdjYgaW5jbHVkaW5nIHRoZSBkcmFmdCBpbiB0aGUg c3ViamVjdCBsaW5lIG9mIHRoaXMgbWFpbCBtZWV0cyB0aGF0Lg0KDQpLaW5kIHJlZ2FyZHMsDQpS b2JlcnQNCg0KDQpPbiAxMC1PY3QtMjEgMTA6MDQsIFJvYmVydCBSYXN6dWsgd3JvdGU6DQo+DQo+ IFBsZWFzZSBraW5kbHkgY29ycmVjdCBtZSBpZiBJIGFtIHdyb25nLCBidXQgd2hlcmUgZG8geW91 IHNlZSB0aGF0IFNSdjYgaXMgbWFuZGF0ZWQgdG8gdXNlICJJUHY2IEludGVyZmFjZSBJRHMiID8N Cg0KSSBoYXZlIG5vIGlkZWEsIGJ1dCBJUHY2IGlzIG1hbmRhdGVkIHRvIHVzZSBJUHY2IEludGVy ZmFjZSBJRHMuIElmIHRoYXQgZG9lc24ndCBhcHBseSB0byBTUlY2LCB0aGVuIGl0J3MgaW1wb3Nz aWJsZSB0byBjbGFpbSB0aGF0IFNSVjYgaXMgSVB2Ni4NCg0KVGhpcyBpc24ndCBqdXN0IGFjYWRl bWljIHN0YW5kYXJkcy1vcmllbnRlZCBmb3JtYWxpc20uIEFzIG90aGVycyBoYXZlIHBvaW50ZWQg b3V0LCBpdCBoYXMgdmVyeSBzaWduaWZpY2FudCBkZXBsb3ltZW50IGFuZCBvcGVyYXRpb25hbCBp bXBsaWNhdGlvbnMsIGdpdmVuIHRoYXQgbW9zdCBwcm9kdWN0cyBzdXBwb3J0IElQdjYsIG5vdCBT UlY2Lg0KDQogICBCcmlhbg0K --_000_84FFF3E9267B4EC7BB5B07C6E0B93DD2liquidtelecomcom_ Content-Type: text/html; charset=UTF-8 Content-ID: <19431FFAD4603F47B5894E2DF2CC90A9@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjND MTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJlbi1LRSIgbGluaz0iIzA1NjNDMSIgdmxpbms9 IiM5NTRGNzIiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Um9iZXJ0LDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPkkgd291bGQgc2F5IHRoYXQgbWFueSBvZiB5b3VyIGFyZ3VtZW50cyDigJMg cGFydGljdWxhcmx5IHRoYXQgc3J2NiBpcyBub3QgZXhhY3RseSBpcHY2IOKAkyBpZiBteSBpbnRl cnByZXRhdGlvbiBvZiB5b3VyIGVtYWlscyBpcyBjb3JyZWN0IOKAkyBpbmRpY2F0ZSB0aGF0IGlu ZGVlZCDigJMgd2Ugc2VlbSB0byBiZSBpbiB0aGUgdGVycmFpbg0KIG9mIG1vZGlmeWluZyBvciBl eHRlbmRpbmcgdGhpbmdzIHRoYXQgd291bGQgcHV0IHRoaXMgd2cgSW4gdmlvbGF0aW9uIG9mIGl0 cyBvd24gY2hhcnRlciDigJMgYW5kIHRoZSBzdGF0ZW1lbnQgbWFkZSBieSB0aGUgY2hhaXJzIGhl cmU6DQo8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3Nwcmlu Zy92Q2M5Q2t2d3U1SEEtUkNsZVY3MTJkc0E1T0EvIj4NCmh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0 Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL3ZDYzlDa3Z3dTVIQS1SQ2xlVjcxMmRzQTVPQS88L2E+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QXMgc3VjaCDigJMgY2FuIHlvdSBwb2ludCBt ZSB0byB0aGUgSS1E4oCZcyBmb3IgdGhlIHJlbGV2YW50IGRvY3VtZW50cyB3aGljaCBwZXJtaXQg dGhlc2UgbW9kaWZpY2F0aW9ucyBvciBleHRlbnNpb25zPyBPciwgY2FuIHlvdSBjbGFyaWZ5IGhv dyB3aGF0IHdlIHNlZWluZyBpbiB0aGlzIGRlYmF0ZSBkb2VzIG5vdCBydW4NCiB1cCBhZ2FpbnN0 IHRoZSBhZm9yZW1lbnRpb25lZCBzdGF0ZW1lbnQgYW5kIHRoZSB3ZyBjaGFydGVyPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkFuZHJldzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPmlwdjYgJmx0O2lw djYtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFJvYmVydCBSYXN6dWsgJmx0O3Jv YmVydEByYXN6dWsubmV0Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5TdW5kYXksIDEwIE9jdG9iZXIg MjAyMSBhdCAwMDoyNjxicj4NCjxiPlRvOiA8L2I+QnJpYW4gRSBDYXJwZW50ZXIgJmx0O2JyaWFu LmUuY2FycGVudGVyQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPlNQUklORyBXRyAmbHQ7 c3ByaW5nQGlldGYub3JnJmd0OywgNk1BTiAmbHQ7Nm1hbkBpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OiA8L2I+UmU6IFtzcHJpbmddIGRyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYt c3JoLWNvbXByZXNzaW9uLTAyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgQnJpYW4gJmFtcDsgYWxsLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MYXN0IGVtYWls IGZyb20gbWUgb24gdGhpcyB0b3BpYyBhcyBJIGFtIHByZXR0eSBzdXJlIHRoaXMgd2lsbCBvdGhl cndpc2UgbmV2ZXIgZW5kLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIG5vdCBzdXJlIGFueW9uZSB3aWxsIGhhcmRseSBhcmd1 ZSB0aGF0IFNSdjYgaXMgSVB2NiBvciBub3QuIE1heWJlIGl0IGlzIElQdjYrIGZ1bGx5IGJhY2t3 YXJkcyBjb21wYXRpYmxlIHdpdGggSVB2Ni4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCByZWFsbHkgbWF0dGVycyB0byBtZSBp cyB0aGF0IFNSdjYgcGFja2V0cyBjYW4gYmUgZm9yd2FyZGVkIGJ5IG5vdCBTUiBhd2FyZSBJUHY2 IG5ldHdvcmsmbmJzcDtlbGVtZW50cyB3aXRoIG5vIGNoYW5nZSB0byBkYXRhIHBsYW5lIGFuZCBj b250cm9sIHBsYW5lIHJlcXVpcmVkLiBUaGF0J3MgaXQgLSBubyBtb3JlIC0gbm8gbGVzcy4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QW5kIHNvIGZhciBhbGwgU1BSSU5HIHdvcmsgb24gU1J2NiBpbmNsdWRpbmcgdGhlIGRyYWZ0IGlu IHRoZSZuYnNwO3N1YmplY3QgbGluZSBvZiB0aGlzIG1haWwgbWVldHMgdGhhdC4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2luZCBy ZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Um9iZXJ0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEwLU9jdC0yMSAxMDowNCwgUm9iZXJ0IFJhc3p1ayB3 cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgUGxlYXNlIGtpbmRseSBjb3JyZWN0IG1lJm5ic3A7 aWYgSSBhbSB3cm9uZywgYnV0IHdoZXJlIGRvIHlvdSBzZWUgdGhhdCBTUnY2IGlzIG1hbmRhdGVk IHRvIHVzZSAmcXVvdDtJUHY2IEludGVyZmFjZSBJRHMmcXVvdDsgPw0KPGJyPg0KPGJyPg0KSSBo YXZlIG5vIGlkZWEsIGJ1dCBJUHY2IGlzIG1hbmRhdGVkIHRvIHVzZSBJUHY2IEludGVyZmFjZSBJ RHMuIElmIHRoYXQgZG9lc24ndCBhcHBseSB0byBTUlY2LCB0aGVuIGl0J3MgaW1wb3NzaWJsZSB0 byBjbGFpbSB0aGF0IFNSVjYgaXMgSVB2Ni48YnI+DQo8YnI+DQpUaGlzIGlzbid0IGp1c3QgYWNh ZGVtaWMgc3RhbmRhcmRzLW9yaWVudGVkIGZvcm1hbGlzbS4gQXMgb3RoZXJzIGhhdmUgcG9pbnRl ZCBvdXQsIGl0IGhhcyB2ZXJ5IHNpZ25pZmljYW50IGRlcGxveW1lbnQgYW5kIG9wZXJhdGlvbmFs IGltcGxpY2F0aW9ucywgZ2l2ZW4gdGhhdCBtb3N0IHByb2R1Y3RzIHN1cHBvcnQgSVB2Niwgbm90 IFNSVjYuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNwO0JyaWFuPG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_84FFF3E9267B4EC7BB5B07C6E0B93DD2liquidtelecomcom_-- From nobody Sat Oct 9 19:05:11 2021 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 E2CB93A0791; Sat, 9 Oct 2021 19:04:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 2LwzNzPmT06M; Sat, 9 Oct 2021 19:04:01 -0700 (PDT) Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) (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 9E1763A078A; Sat, 9 Oct 2021 19:04:00 -0700 (PDT) Received: by mail-oi1-x22d.google.com with SMTP id u69so6780747oie.3; Sat, 09 Oct 2021 19:04:00 -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=QKmtOVh/1GFRebENIJhq+SHbkk+qNt52GBJjIn5+Dm0=; b=JN/yEcjsJAUAuaymcN9/7W8jkAhY0uwku9Gp8ztHdn+SxYbSAFHxHxVNm7ijX1CMRL pWcE6AqBsbFlCzYUBs9ImOXE8mgzKBiaVMRRVamXxAdGCGi7RavF8pZ41bUzqxmZkyMW Pab3HLvMn08ka17KwiuWH2DaY8tKI87YaIjb0QLZPfigEMhf/Ov3+4sDZP5Y1cQw3Js8 9ey/3/d1elb+DkzxEiLcovBDb9hx0hFaHSQ1oCuPyOYCRz1BzzsYH6p8VpoT82lQIAE2 uKyAz7wZ4mhcI15X04qCsGVS7lOJupqMI9fRNBotKiankOD66PL1tUlfS2g5yW4w1Oap Rweg== 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=QKmtOVh/1GFRebENIJhq+SHbkk+qNt52GBJjIn5+Dm0=; b=5yTaaavTJqvPtBIbmEBsqjoW+zZTQITZm/CcOjjMa9C+hOgvMR2h2PwcQkh3pfkImp dPI++Yb5EeEBcT1gFB3NYJ6JkEDDGETeg7kIHuOaSz3LpWYgPlJikhMTtsuqBF8vzLfs EehElb5gpPM5lmcfRNqlc8+gL63t9ksd6sdEG+57f1CcacylcXcX9PaVs7FsWJX5UB0U SEcUzEt842qgcZL4HA+UxXhoTqa6lCyf8c41hX323jioDsXye3iu0fCXuVqPWkNLTc7U ROvKpofaXHAFsPeuJOcyOYs2O5aVd2fPN6q23lepZ4bNYvmc8vkHVspFBcq+dNJfEoTZ Sr3Q== X-Gm-Message-State: AOAM5338LHnW5Tmdu1jlfw2uL1qaatCycR1JuzUuU87XjYyFE4g6dLoN /B2XrMH+2+MpusXWD8NHPqBd83qoyTCFtssJAe0+2Q1mxYM= X-Google-Smtp-Source: ABdhPJw/qyVyxIP1tTUVvA8oPQrCQdtf325x6C7zVDFgo927I/Mx//SFYjAhDVbL/GIFS6PG7KFty0EYSsUmTDDDcss= X-Received: by 2002:aca:ba55:: with SMTP id k82mr20851922oif.97.1633831439675; Sat, 09 Oct 2021 19:03:59 -0700 (PDT) MIME-Version: 1.0 References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> <423b08d46294454d9a9625990ce52acb@huawei.com> <322a8c29-e232-a39d-94ca-9c9cbf09c8d2@gmail.com> <9945ca9c-2ba7-bd00-6e3e-261c376a9718@gmail.com> <938b4efa-1383-beb8-5dc7-e2a951d15457@gmail.com> In-Reply-To: <938b4efa-1383-beb8-5dc7-e2a951d15457@gmail.com> From: Erik Kline Date: Sat, 9 Oct 2021 19:03:48 -0700 Message-ID: To: Brian E Carpenter Cc: Robert Raszuk , Mark Smith , SPRING WG , 6MAN <6man@ietf.org> Content-Type: multipart/alternative; boundary="00000000000095b31d05cdf60653" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 10 Oct 2021 02:04:12 -0000 --00000000000095b31d05cdf60653 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable To address the self-rewriting Destination Address complexity, and some related objections, might it be possible to add a mutable TLV, requiring the presence of an SRH (no SRH-less packets)? The mutable TLV would contain any extra state necessary to continue decompression of the current segment in the SRH into the Destination Address field or trigger advancement to the next segment in the list. This would allow the DA to remain a plain IPv6 address/SID (current operation). (I've had a few other thoughts, but they aren't without their own shortcomings.) On Sat, Oct 9, 2021 at 2:13 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 10-Oct-21 10:04, Robert Raszuk wrote: > > > > Please kindly correct me if I am wrong, but where do you see that SRv6 > is mandated to use "IPv6 Interface IDs" ? > > I have no idea, but IPv6 is mandated to use IPv6 Interface IDs. If that > doesn't apply to SRV6, then it's impossible to claim that SRV6 is IPv6. > > This isn't just academic standards-oriented formalism. As others have > pointed out, it has very significant deployment and operational > implications, given that most products support IPv6, not SRV6. > > Brian > > > > > On Sat, Oct 9, 2021 at 11:00 PM Mark Smith > wrote: > > > > It's stated twice in section 2.5 of RFC4291. > > > > For all unicast addresses, except those that start with the binary > > value 000, Interface IDs are required to be 64 bits long and to = be > > constructed in Modified EUI-64 format. > > > > > > All Global Unicast addresses other than those that start with > binary > > 000 have a 64-bit interface ID field (i.e., n + m =3D 64), > formatted as > > described in Section 2.5.1 < > https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.1>. Global > Unicast addresses that start with > > binary 000 have no such constraint on the size or structure of t= he > > interface ID field. > > > > > > Please also see RFC7421, Analysis of the 64-bit Boundary > in IPv6 Addressing. > > > > > > > > > > > > > > On Sun, 10 Oct 2021, 07:27 Robert Raszuk, > wrote: > > > > > Hi Brian, > > > > > >> Which means: 64 bits. > > > > > > Sorry but what is so magic about /64 here ? > > > > It is mandated by the current IPv6 addressing architecture. > > > > > > > Really ? Where ? I am looking at RFC4291 and nowhere I can find > /64 reference. > > > > Moreover sections 2.4 and 2.5 are very clear that there is no > magic /64 hard defined. > > > > The text actually goes even further and says: > > > > Except for the knowledge of the subnet boundary discussed in > the > > previous paragraphs, nodes should not make any assumptions > about the > > structure of an IPv6 address. > > > > > > Thx, > > > > R. > > > > > > > > > > > > Despite many discussions, there has never been consensus to > change it. So if /64 is not the boundary between the routeable part and > the host-specific part, it's not IPv6. > > > > Brian > > > > > > > > Is this coming from the longest routable IPv6 prefix ? > Sort of analogy to /24 in the IPv4 world ? Or something else ? > > > > > > I think LPM and CIDR techniques are pretty well > established. > > > > > > Any fixed length of the address block with the meaning - > do not use those bits inter or intra domain for anything useful even > if your prefix+node can happily fit in /32 seems just dead wrong to me. > And that is irrespective of any SRv6 discussion. > > > > > > In my books if I get allocated say /48 or /40 from RIR > what I do with the remaining bits is my own business. > > > > > > Best, > > > R. > > > > > > > > > > > > > Sorry, but it is a little bit late =E2=80=93 RFC 89= 86 is > already published. > > > > > > "Locators are assigned consistent with > IPv6 infrastructure allocation." > > > > > > Which means: 64 bits. > > > > > > I have no time to study compressed SIDs, but if they > trample on the > > LOC they are not IPv6 addresses. > > > > > > Brian > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org ipv6@ietf.org > > > > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 < > https://www.ietf.org/mailman/listinfo/ipv6> > > https://www.ietf.org/mailman/listinfo/ipv6>> > > > > -------------------------------------------------------------------- > > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 < > https://www.ietf.org/mailman/listinfo/ipv6> > > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --00000000000095b31d05cdf60653 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    <random>

    To address the sel= f-rewriting Destination Address complexity, and some related objections, mi= ght it be possible to add a mutable TLV, requiring the presence of an SRH (= no SRH-less packets)?=C2=A0 The mutable TLV would contain any extra state n= ecessary to continue decompression of the current segment in the SRH into t= he Destination Address field or trigger advancement to the next segment in = the list.=C2=A0 This would allow the DA to remain a plain IPv6 address/SID = (current operation).

    (I've had a few other thoug= hts, but they aren't without their own shortcomings.)


    On Sat, Oct 9, 2021 at 2:13 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    <= /div>
    On 10-Oct-21 10:04, = Robert Raszuk wrote:
    >
    > Please kindly correct me=C2=A0if I am wrong, but where do you see that= SRv6 is mandated to use "IPv6 Interface IDs" ?

    I have no idea, but IPv6 is mandated to use IPv6 Interface IDs. If that doe= sn't apply to SRV6, then it's impossible to claim that SRV6 is IPv6= .

    This isn't just academic standards-oriented formalism. As others have p= ointed out, it has very significant deployment and operational implications= , given that most products support IPv6, not SRV6.

    =C2=A0 =C2=A0Brian

    >
    > On Sat, Oct 9, 2021 at 11:00 PM Mark Smith <markzzzsmith@gmail.com <mailto:= markzzzsmith@gm= ail.com>> wrote:
    >
    >=C2=A0 =C2=A0 =C2=A0It's stated twice in section 2.5 of RFC4291. >
    >=C2=A0 =C2=A0 =C2=A0For all unicast addresses, except those that start = with the binary
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 000, Interface IDs are required to be= 64 bits long and to be
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 constructed in Modified EUI-64 format.
    >
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 All Global Unicast addresses other than tho= se that start with binary
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 000 have a 64-bit interface ID field (i.e.,= n + m =3D 64), formatted as
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 described in Section 2.5.1 <https://datatracker.ietf.org/doc/html/rfc4291#section= -2.5.1>.=C2=A0 Global Unicast addresses that start with
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 binary 000 have no such constraint on the s= ize or structure of the
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 interface ID field.
    >
    >
    >=C2=A0 =C2=A0 =C2=A0Please also see RFC7421,=C2=A0=C2=A0Analysis of the= 64-bit Boundary
    in IPv6 Addressing.
    >
    >
    >
    >
    >
    >
    >=C2=A0 =C2=A0 =C2=A0On Sun, 10 Oct 2021, 07:27 Robert Raszuk, <robert@raszuk.net <= ;mailto:robert@raszu= k.net>> wrote:
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Hi Brian,=C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> Which means: 6= 4 bits.
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Sorry but what is = so magic=C2=A0about /64 here ?
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It is mandated by the c= urrent IPv6 addressing architecture.

    >
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Really ? Where ? I am looking at RFC4= 291 and nowhere I can find
    /64 reference.=C2=A0
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Moreover sections 2.4 and 2.5 are ver= y clear that there is no magic /64 hard defined.=C2=A0
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The text actually goes even further a= nd says:=C2=A0
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Except for the knowledge of t= he subnet boundary discussed in
    the
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 previous paragraphs, nodes sh= ould not make any assumptions about the
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 structure of an IPv6 address.=
    >
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thx,
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0R.
    >
    >
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Despite many discussion= s, there has never been consensus to
    change it. So if /64 is not the boundary between the routeable part and the= host-specific part, it's not IPv6.
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Brian
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Is this coming fro= m the longest routable IPv6 prefix ? Sort of analogy to /24 in the IPv4 wor= ld ? Or something else ?=C2=A0
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I think LPM and CI= DR techniques are pretty well established.=C2=A0
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Any fixed length o= f the address block with the meaning=C2=A0- do not use those bits inter or = intra domain for anything useful even
    if your prefix+node can happily fit in /32 seems just dead wrong to me. And= that is irrespective of any SRv6 discussion.=C2=A0
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> In my books if I g= et allocated say /48 or /40 from RIR what I do with the remaining bits is m= y own business.=C2=A0
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Best,
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> R.
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0> Sorry, but it is a little bit late =E2=80=93 RFC 8986 is already pu= blished.
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0"Locators are assigned consistent with
    IPv6 infrastructure allocation."
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0Which means: 64 bits.
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0I have no time to study compressed SIDs, but if they trample on the
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LOC they are not IPv6 a= ddresses.
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0=C2=A0 =C2=A0Brian
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0--------------------------------------------------------------------
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0IETF IPv6 working group mailing list
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0ipv6@ietf.org <= ;mailto:ipv6@ietf.org> <mailto:ipv6@ie= tf.org <mailto:ip= v6@ietf.org>>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0Administrative Requests: https://www.ietf.org/mailman/l= istinfo/ipv6 <https://www.ietf.org/mailman/listinfo= /ipv6>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<ht= tps://www.ietf.org/mailman/listinfo/ipv6 <https://w= ww.ietf.org/mailman/listinfo/ipv6>>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0--------------------------------------------------------------------
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------------------------------------= -------------------------------
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IETF IPv6 working group mailing list<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ipv6@ietf.org <mailto:ipv6@ietf.org>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <ht= tps://www.ietf.org/mailman/listinfo/ipv6>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------------------------------------= -------------------------------
    >

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
    --------------------------------------------------------------------
    --00000000000095b31d05cdf60653-- From nobody Sat Oct 9 21:06:38 2021 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 EAEE23A0C52; Sat, 9 Oct 2021 21:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vKH6NI8MXF-T; Sat, 9 Oct 2021 21:06:30 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 DA6743A0C51; Sat, 9 Oct 2021 21:06:29 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id r9so14443693ile.5; Sat, 09 Oct 2021 21:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=UWvHwZs8iNo0MJb43JgfwDxWAmw3QUcDg7WcBQ2n4c8=; b=nBUgYXqUW/honw2Rb9wvMMh749bcZ76fFUl+K20YfbBx/xa5gHXYahu3tZBB/nrMhG 9GmOyATWfmQ5B1xKv6933snvCEcCE6kY9xzvxudqmHYhX3Na/t+83XdNzzwEFmNsXf9L WTfx5GH2BofavhIGqla+nB3BS7FjM+tVlZlrvOFoUIMkJpV0+GVk/T6pxBwnorYmktZI YEoTd3ibABKkWLN6wbwRMrJiSeNPx2Mxm0xPrRO3SiCAonTN2TB22BQU5KAB7TSC09uD kKTZdqI0nbcKDdeRaeHIH/YGvi3miU/2CA0NXUUIipRkOyaWAmUj4YPl+oQwYe+dPevh ZYlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=UWvHwZs8iNo0MJb43JgfwDxWAmw3QUcDg7WcBQ2n4c8=; b=gfF5wFpTu9GO8F7RgrjYYxrl6YJTnomRaBvK6AvKrIuO47EqQUUJ2SsaDiuoOnAxoa LreAei3K8jYR8OAOXk/fcd/Nhbechy/m2Uk9a/2jzDj0vTBrAhjC77yZ5UTVko/ILQXD Bt3lSlRk7wjNI4Q2CgbRmLcSbwwGdM/mZcS1xBlk9ZmjQxCwscQRHFeEFm5w//BgkCeD DTMQnwODlPmPHf1F5hwrFnI0y6hOuiMpYE3/pemCa0IcMROATqGjiKzcWPxmhatx/NLx A6NJCcRXXSSJMXM8oXVdqnlvZV5zg+Qd5Uy55QBunAqNFB447AmXcTMR+vr4nykFyy+G QKlQ== X-Gm-Message-State: AOAM533awL3fQ3EqJuKqRvx50JACx/6WxY+eipK7Q5sZokle9ZXujlEq vqzlnfvbhdopw9k2aF2QmWCaVbk80xk= X-Google-Smtp-Source: ABdhPJxOU44lhZL/3dcEJbfDJSt73z1kbRdMT2ThvQNtOxBqWpS6h0tWh6xjTw2p6d/EquDr0hQAHA== X-Received: by 2002:a05:6e02:184f:: with SMTP id b15mr14391220ilv.187.1633838788916; Sat, 09 Oct 2021 21:06:28 -0700 (PDT) Received: from DM5PR1901MB2150.namprd19.prod.outlook.com ([2603:1036:4:9e::5]) by smtp.gmail.com with ESMTPSA id a12sm2073733ilb.66.2021.10.09.21.06.26 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 09 Oct 2021 21:06:26 -0700 (PDT) From: Tarek Saad To: "Francois Clad (fclad)" , James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQFKdpbcABx8r/YASPmz5Q== X-MS-Exchange-MessageSentRepresentingType: 1 Date: Sun, 10 Oct 2021 04:06:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_DM5PR1901MB21504469221363FBB6A27217FCB49DM5PR1901MB2150_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 10 Oct 2021 04:06:36 -0000 --_000_DM5PR1901MB21504469221363FBB6A27217FCB49DM5PR1901MB2150_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Francois, Thanks for your responses. Please see inline.. From: Francois Clad (fclad) Date: Friday, October 8, 2021 at 1:14 PM To: Tarek Saad , James Guichard , SPRING WG Cc: spring-chairs@ietf.org Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/draft-fi= lsfilscheng-spring-srv6-srh-compression/ Hi Tarek, I am assuming that the border node is an SR segment endpoint node in your q= uestion. [TS]: yes. This node processes the packet according to the behavior bound to the local= ly instantiated SID that was matched (see Section 4.3 of RFC 8754). There i= s no interpretation required. [TS]: consider the case that two locally instantiated SIDs (carried in the = DA) can match =96 like SID1 is contained within SID2 (or vice versa). Absen= ce anything present in the encoded SID-sequence, how can this node reliably= infer whether it is G-SID sequence or a C-CSID sequence? It is the responsibility of the SR source to make sure that the SIDs in the= Segment-List are used appropriately. This applies to all SRv6 SIDs, includ= ing those defined in RFC 8986. It is the same as ensuring that there is not= an End.DT4 SID in the middle of the Segment-List or that an End.X SID boun= d to the right interface is used. [TS]: I=92m not sure it is solely a SR source responsibility. There is some= responsibility that the node allocated the 2 kinds of SIDs that need to en= sure no such previous collision can ever occur, no? Regards, Tarek Thanks, Francois From: spring on behalf of Tarek Saad Date: Friday, 8 October 2021 at 06:06 To: James Guichard , SPRING WG Cc: spring-chairs@ietf.org Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ Hi all, I=92ve read this draft. It is proposing 2 different encodings schemes for c= ompressed sequence of SRv6 SIDs (and an optional behavior on border nodes).= . Although Section 4 makes a claim that different deployments usecase may dee= m one encoding scheme superior over the other, I could not glean in which c= ases a scheme would outperform the other and why? Or, why is the WG trying = to standardize both the two flavors -- keeping in mind the complex HW proce= dures evident by the proposed different pseudo codes in the draft. Also, are there concerns of misinterpreting (wrongfully decoding) a GSID se= quence for a C-SID-sequence (or vice-versa) for a received packet on border= nodes that may support both encoding flavors simultaneously? For these reasons, I think this it is still premature for this draft to be = adopted, and I oppose its adoption. Regards, Tarek From: spring on behalf of James Guichard Date: Friday, October 1, 2021 at 10:05 AM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a =93living=94 document; it may change as it goes thr= ough review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_DM5PR1901MB21504469221363FBB6A27217FCB49DM5PR1901MB2150_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    Hi Francois,

     

    Thanks for your res= ponses. Please see inline..

     

    From: Francois Clad (fcla= d) <fclad@cisco.com>
    Date: Friday, October 8, 2021 at 1:14 PM
    To: Tarek Saad <tsaad.net@gmail.com>, James Guichard <james= .n.guichard@futurewei.com>, SPRING WG <spring@ietf.org>
    Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
    Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/d= raft-filsfilscheng-spring-srv6-srh-compression/

    Hi Tarek,

     

    I am assuming that the border node is an SR segment = endpoint node in your question.

    [TS]= : yes.

     

    This node processes the packet according to the beha= vior bound to the locally instantiated SID that was matched (see Section 4.= 3 of RFC 8754). There is no interpretation required.

    [TS]= : consider the case that two locally instantiated SIDs (carried in the DA) = can match =96 like SID1 is contained within SID2 (or vice versa). Absence a= nything present in the encoded SID-sequence, how can this node reliably infer whether it is G-SID sequence or a C-CSID = sequence?

     

    It is the responsibility of the SR source to make su= re that the SIDs in the Segment-List are used appropriately. This applies t= o all SRv6 SIDs, including those defined in RFC 8986. It is the same as ens= uring that there is not an End.DT4 SID in the middle of the Segment-List or that an End.X SID bound to the ri= ght interface is used.

    [TS]= : I=92m not sure it is solely a SR source responsibility. There is some res= ponsibility that the node allocated the 2 kinds of SIDs that need to ensure= no such previous collision can ever occur, no?

     

    Rega= rds,

    Tare= k

     

    Thanks,

    Francois

     

    From: spring <spring-b= ounces@ietf.org> on behalf of Tarek Saad <tsaad.net@gmail.com>
    Date: Friday, 8 October 2021 at 06:06
    To: James Guichard <james.n.guichard@futurewei.com>, SPRING WG= <spring@ietf.org>
    Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
    Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.= org/doc/draft-filsfilscheng-spring-srv6-srh-compression/    <= /p>

    Hi all,<= /span>

     

    I=92ve read this dr= aft. It is proposing 2 different encodings schemes for compressed sequence = of SRv6 SIDs (and an optional behavior on border nodes)..=

    Although Section 4 = makes a claim that different deployments usecase may deem one encoding sche= me superior over the other, I could not glean in which cases a scheme would= outperform the other and why? Or, why is the WG trying to standardize both the two flavors -- keeping in mind th= e complex HW procedures evident by the proposed different pseudo codes in t= he draft.

     

    Also, are there con= cerns of misinterpreting (wrongfully decoding) a GSID sequence for a C-SID-= sequence (or vice-versa) for a received packet on border nodes that may sup= port both encoding flavors simultaneously?

     

    For these reasons, = I think this it is still premature for this draft to be adopted, and I oppo= se its adoption.

     

    Regards,=

    Tarek

     

     

    From: spring <spring-b= ounces@ietf.org> on behalf of James Guichard <james.n.guichard@future= wei.com>
    Date: Friday, October 1, 2021 at 10:05 AM
    To: SPRING WG <spring@ietf.org>
    Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
    Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

    Dear WG:

     

    The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a sol= ution for SRv6 compression.

     

    The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

     

    Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

     

    1. The SPRING working group is adopting a document = that has multiple SRv6 Endpoint behaviors.
    2. The document is a =93livi= ng=94 document; it may change as it goes through review and analysis by the= SPRING working group.
    3. All open discussion point= s raised on our mailing list MUST be addressed BEFORE said document is allo= wed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maint= ained by the document editor in conjunction with the chairs.
    4. If this document is adopt= ed by the working group, the chairs specify as part of the adoption call th= at the following text describing an open issue be added to the document in the above-described open issues section:
      • "Given that the working group has said that it wants to standar= dize one data plane solution, and given that the document contains multiple= SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution obj= ective.".

     

    Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open d= iscussion points you would like addressed should the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    --_000_DM5PR1901MB21504469221363FBB6A27217FCB49DM5PR1901MB2150_-- From nobody Sun Oct 10 13:23:14 2021 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 49F073A0D56; Sun, 10 Oct 2021 13:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2dHio1uwh2E; Sun, 10 Oct 2021 13:23:05 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 0B2C13A0D55; Sun, 10 Oct 2021 13:23:05 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id pi19-20020a17090b1e5300b0019fdd3557d3so11843553pjb.5; Sun, 10 Oct 2021 13:23: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=8l1x45MXnCLSgp7HQCSfo6Ch28llUdFJszOGYLzEHD8=; b=bURqM01vF41VgFGKQt8pSrd6Z0Jy4nUHj7YkH/m0wV4OfBQPjpc2WWSwoNK0atQyr9 f6cs0JKiQa/zxx9CE2Nxdg3g62qmajeC2+Ofk31u+pi/NtxSuee7yoMk9Uul4mnPzLKh 2msfmrl5SOVBG2nC13tDO8hhWfyTZDugKUJ3uC83Z2gry258VWryczPBVFWEz3yiyShZ O7BbnpaMR9JCnkgy3icPtjHoPaCztF18qPuGwbW4rr3ajwpwMZ5DgwjrIK+8aoNrO/zH LEyw+FTk7PI1unD68JPs04I3TNBqm46bwAZcX1scpF3oTqxnEmacVJG8FScyq0piXBjF tMtg== 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=8l1x45MXnCLSgp7HQCSfo6Ch28llUdFJszOGYLzEHD8=; b=aa21+1f2NTLQmqyNXWTG89TuKKrdkmmuwgR5fE1Kn6RG+5glpJ6+8zmNxlJunFy/z+ mstDN9He4KzyW+mrUtGy6uk3RZCVdmmTxLl/wuRCwlzDEQM4znt50mk5or/aH0Mmks0r 9Yj3ywqnsflJNr9oHSZCPWe/Yg2uTB+PVvuQ8VBZCyLsXGlX7kGpBlEd/MKQIIPYJZL5 DDnis0UTJ3d8rekcus+dYMFkHqXAkVEILgHde/rTceudUvSjtrU5H+kqaPyasUt42H5t jBlPqnNwokp7w87/pN/u03qUbC2jeSSYF6Ur146neoye/QUR4+5f3ncdTLkxmbI3V8kM sSaA== X-Gm-Message-State: AOAM531y0NLk5BdqoPc709l3uYRGCWtClIxm1lX778abGAAX2WowrGYs 2b+OI7p4rSxD+5CZzIu3lloHetJ+2Kir1GZZ6xU= X-Google-Smtp-Source: ABdhPJwHRp10E0jlqHRE7ax8Dl11iP6xCqAIyyyupToBzXaTUWiDcp27v0641T3R6qjx/UUkEZ3o0exlG61axERz5TU= X-Received: by 2002:a17:90b:1649:: with SMTP id il9mr9536217pjb.167.1633897383897; Sun, 10 Oct 2021 13:23:03 -0700 (PDT) MIME-Version: 1.0 References: <202110021255323466813813@chinamobile.com> In-Reply-To: From: Gyan Mishra Date: Sun, 10 Oct 2021 16:22:52 -0400 Message-ID: To: "Chengli (Cheng Li)" , "Francois Clad (fclad)" Cc: James Guichard , SPRING WG , Yisong Liu , spring-chairs Content-Type: multipart/alternative; boundary="0000000000002aae0805ce05610d" Archived-At: Subject: Re: [spring] =?utf-8?q?RE=EF=BC=9A_WG_Adoption_call_for_https=3A//da?= =?utf-8?q?tatracker=2Eietf=2Eorg/doc/draft-filsfilscheng-spring-srv6-srh-?= =?utf-8?q?compression/?= 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, 10 Oct 2021 20:23:11 -0000 --0000000000002aae0805ce05610d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Francois, Chengli & authors Many Thanks for your feedback to the WG on the critical topic interoperability of the uSID micro-sid 16 bit uSID =E2=80=9CNF=3DLocator/= Function combo=E2=80=9D 128 bit container based solution and the G-SRV6 32 bit G-SI= D =E2=80=9CNF=3DLocator/Function combo=E2=80=9D 4 - 32 bit G-SID in 128 bit c= ontainer based solution defined as Next and Replace flavors in the draft. I am really concerned as to how the next and replace interoperability would work for adjacent nodes using SID within same or adjacent container. Section 6.1 mentions that Next flavor recommendation is for 16 bit as the uSID draft & this draft NF as 16 bit is most optimal uSID size within the uSID container and Replace flavor recommendation is for 16 bit as the G-SRV6 draft & this draft NF as 32 bit G-SID is most optimal G-SID size within the G-SID container. Please elaborate on this in more detail, as with this draft for next and replace interoperability, following the SRv6 compression requirements for optimal hardware forwarding and state efficiency that Next would be recommended to use 16 bit SID and Replace would be recommended 32 bit SID. Please elaborate in detail as to why 16 bit is not recommended for replace flavor and 32 bit is not recommended for next flavor for all of the requirements drafts list of SRv6 compression requirements each one by one and the problems encountered when not using the recommended SID length. Thus for next and replace flavor interoperability even possible to work would require two different SID sizes within the same container interoperability caveats and now you have to deal with uSID container style using 16 bit SID and G-SID container style using 32 bit SID. >From the requirements draft, interoperability perspective, the primary objective is =E2=80=9Cencapsulation header compression=E2=80=9D as that is = what we have spent over a year on with DT finding an optimal compression solution. So here the lowest common denominator ends up being 32 bit SID and we now have failed the primary objective of a compression solution. As far as lowest common denominator is it true that in order to meet all the requirements draft list of all SRv6 compression requirements both next and replace have to revert to that lowest common denominator which is 32 bit SID. If that is true, unfortunately that makes the draft fail the primary objective of any SRv6 compression solution. To that end as far as interoperability on Next and Replace interoperability being the hinge pin of this drafts adoption, as well even if the authors state that Replace can use 16 bit SID as a possibility, as the 32 bit =E2= =80=9CNF=E2=80=9D G-SID is recommended for hardware forwarding efficiency and scalability that if 16 bit were used G-SID would fail the hardware forwarding efficiency and scalability requirements as well as possibly other requirements which should also be stated in the draft. 6.1 . C-SID Length The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A C-SID length of 16-bit is recommended. The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths. A C-SID length of 32-bit is recommended. The draft should mention the recommendation for common block length for interoperability. The only block size possible is 48 bit so block size so that would be a major addressing inflexibility for interoperability. 6.2 . Block Length The recommended SRv6 SID block sizes for the NEXT-C-SID flavor are 16, 32 or 48 bits. The smaller the block, the higher the compression efficiency. The recommended SRv6 SID block size for the REPLACE-C-SID flavor can be 48, 56, 64, 72 or 80 bits, depending on the needs of the operator. Taking this further another step as this draft needs to describe in detail with examples of the feasibility of how two adjacent nodes one using next 16 bit SID and other using replace 32 bit SID as recommended where the 16 bit uSID next flavor and 32 bit G-SID are in the same SRH 128 bit container= . As the uSID Next flavor draft performs a shift towards B towards nibble A, B nibbles, and Replace does a replace of the A-Arg portion of the 128 bit IPv6 address, how would that work with adjacent nodes using different SID flavors of different SID lengths. The Next flavor uSID SRv6 PGM compression solution process is very different where when indexing the micro sid nibbles within the 128 bit container, it performs a shift towards the top lower order bits of the IPv6 address, where the Replace flavor G-SRv6 PGM compression solution indexing the 4 G-SIDs within the container does a Replace at the A-Arg bottom higher order bits. The referencing of the 16 uSID or 32 bit G-SID nibbles, indexing and reference of which nibble to referenced for next and replace for directly adjacent nodes with nibbles within the same 128 bit container or adjacent containers is the interoperability issue that seems to exist. This needs to be clarified on the next snd replace interoperability operation in detail. Also Replace flavor uses COC delimiter for signaling compression function is active where Next does not have any signaling of compression being active or not or may have a different way of signaling that upcoming node does not support compression. How does the compression signaling interoperability work between Next and Replace flavors. That should be addressed as well in the draft. Kind Regards Gyan Verizon Inc On Fri, Oct 8, 2021 at 1:34 PM Francois Clad (fclad) wrote: > Hi Gyan, > > > > It is possible to combine SIDs of different C-SID flavors and C-SID > lengths in the same SRH, along with those defined in RFC 8986 After all, > they leverage the same SRv6 data plane. > > > > Let me give you an example. > > > > Assume that an SR source node wants to send a packet onto an SR path > through 10 SR segment endpoint nodes (nodes 1 through 10), and have a VPN > termination for a VRF 123 on a last SR segment endpoint node 11. > > > > The SR source node selects the segments as follows: > > - On nodes 1 through 5, the SID 2001:db8:0:0K01:: (with K being the > node ID) bound to End with NEXT-C-SID flavor and 16-bit C-SID length. > - On nodes 6 through 9, the SID 2001:db8:0:0K00:0001:: (with K being > the node ID) bound to End with REPLACE-C-SID flavor and 32-bit C-SID l= ength. > - On node 10, the SID 2001:db8:0:1000:0001:: bound to End (RFC 8986). > - On node 11, a SID 2001:db8:0:1100:d123:: bound to End.DT4 (RFC 8986) > for VRF 123. > > > > The SR source node then sends the packet onto the SR path by performing > the H.Encaps.Red behavior with: > > - IPv6 Source Address =3D > - IPv6 Destination Address =3D 2001:db8:0:0101:0201:0301:0401:0501 > - SRH =3D > - SegmentList[0] =3D 2001:db8:0:1100:d123:: > - SegmentList[1] =3D 1000:0001:0900:0001:0800:0001:0700:0001 > - SegmentList[2] =3D 2001:db8:0:0600:0001:: > > > > Therefore, there is no notion of lowest common denominator for C-SID leng= th > . Based on the deployment requirements, an operator has the flexibility > to select the SRv6 SID flavor and C-SID lengths of their choice. > > > > We can update the draft with this type of illustrations. > > > > Thanks, > > Francois > > > > *From: *spring on behalf of Gyan Mishra < > hayabusagsm@gmail.com> > *Date: *Sunday, 3 October 2021 at 21:01 > *To: *Yisong Liu > *Cc: *James Guichard , SPRING WG < > spring@ietf.org>, spring-chairs > *Subject: *Re: [spring] RE=EF=BC=9A WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > > > Hi Yisong > > > > The main goal for operators is interoperability. As interoperability is > the key reason for a single SRv6 compression solution that we have WG > consensus and is desired. > > > > Continued details of the interoperability study should be added to the > draft as the study progresses. > > > > One key detail that is missing is forwarding efficiency and scalability > using NEXT-C-SID and REPLACE-C-SID interoperability using 16 bit SID. > > > > As NEXT-CSID uSID Container Micro Segment shift flavor using GIB/LIB for > ultra scale SRv6 compression solution is recommended for 16 bit SID and > REPLACE-C-SID G-SID G-SID Container based solution is recommended for 32 > bit SID. > > > > Of all the requirements as stated, the encapsulation header size is the > primary objective for operators to eliminate MSD issues with optimal > forwarding and state efficiencies. > > > > At this time in order for Next and Replace solutions to be interoperable > keeping in mind requirements for optimal forwarding and state efficiency = 32 > bit SID would be the lowest common denominator which should be stated as > the baseline result of the analysis draft on CSID overall 2 prong solutio= n. > > > > CSID draft: > > > https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh= -compression-02#section-11 > > > > Bottom of section 11: > > > > > > The interoperability was validated for the following scenario: > > > > o Packet forwarding through a traffic engineering segment list > > combining, in the same SRH ([RFC8754 ]), SRv6 SIDs bound to an > > endpoint behavior with the NEXT-C-SID flavor and SRv6 SIDs bound > > to an endpoint behavior with the REPLACE-C-SID flavor. > > > > Further interoperability testing is ongoing and will be reported in > > this document as the work progresses. > > > > King Regards > > > > Gyan > > On Sat, Oct 2, 2021 at 12:56 AM Yisong Liu > wrote: > > Hi Chairs & WG, > > > > I strongly support the adoption call. Regarding chair's note in the email= , > I would like to point that the network programming model (RFC8996) by > nature defines multiple behaviors. CSID has a single SRv6 based data plan= e > that defines the next and replace behaviors consistent with the network > programming paradigm. > > > > CSID's next and replace behaviors have been verified by interoperability > test in China mobile laboratory and there is no problem with the > interworking of the two behaviors on the CSID dataplane. > > > > Best Regards > > Yisong > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: James Guichard > > =E6=97=B6=E9=97=B4: 2021/10/01(=E6=98=9F=E6=9C=9F=E4=BA=94)22:04 > > =E6=94=B6=E4=BB=B6=E4=BA=BA: SPRING WG ; > > =E6=8A=84=E9=80=81=E4=BA=BA: spring-chairs ; > > =E4=B8=BB=E9=A2=98: [spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > Dear WG: > > > > The chairs would like to express their appreciation for all the responses > received to our emails with reference to how the working group wishes to > move forward with respect to a solution for SRv6 compression. > > > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > as the basis for its compression standardization work. That is part of wh= at > this email attempts to confirm. > > > > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging > that: > > > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change = as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the working > group to publication. A list of these discussion points will be docume= nted > in the WG document and maintained by the document editor in conjunctio= n > with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text describin= g an > open issue be added to the document in the above-described open issues > section: > > > - "Given that the working group has said that it wants to standardize > one data plane solution, and given that the document contains multi= ple SRv6 > EndPoint behaviors that some WG members have stated are multiple da= ta plane > solutions, the working group will address whether this is valid and > coherent with its one data plane solution objective.". > > > > Please consider the above guidelines as you decide on whether to support > or not this WG adoption. Please express clearly your reasoning for > support/non-support as well as any open discussion points you would like > addressed should the document be adopted into the working group. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > -- > > > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com * > > *M 301 502-1347* > > > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --0000000000002aae0805ce05610d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Hi Francois, Chengli &= ; authors=C2=A0

    Many Tha= nks for your feedback to the WG on the critical topic interoperability of t= he uSID micro-sid 16 bit uSID =C2=A0 =E2=80=9CNF=3DLocator/Function c= ombo=E2=80=9D =C2=A0128 bit=C2=A0container based solution and the G-= SRV6 32 bit G-SID =E2=80=9CNF=3DLocator/Function combo=E2=80=9D 4 - 32 bit = G-SID in 128 bit container based solution defined as Next and Replace flavo= rs in the draft.

    I am re= ally concerned as to how the next and replace interoperability would work f= or adjacent nodes using SID within same or adjacent container.

    Section 6.1 mentions that =C2=A0Next= flavor recommendation is for 16 bit as the uSID draft & this draft NF = as 16 bit is most optimal uSID size within the uSID container and=C2=A0Replace flavor recommendation is for 16= bit as the G-SRV6 draft & this draft NF as 32 bit G-SID is most optima= l G-SID size within the G-SID container.=C2=A0=C2=A0

    Please =C2=A0elaborate on= this in more detail, as with this draft for next and replace interoperabil= ity, following the SRv6 compression requirements for optimal hardware forwa= rding and state efficiency that Next would be recommended to use 16 bit SID= and Replace would be recommended 32 bit SID. =C2=A0 Please elaborate in de= tail as to why 16 bit is not recommended for replace flavor and 32 bit is n= ot recommended for next flavor for all of the requirements drafts list of S= Rv6 compression requirements each one by one and the problems encountered w= hen not using the recommended SID length.

    Thus for next and replace flavor inter= operability even possible =C2=A0to work would require two different SID siz= es within the same container interoperability caveats and now you have to d= eal with uSID container style using 16 bit SID and G-SID container style us= ing 32 bit SID.

    From the requirements draft, =C2=A0inter= operability perspective, the primary objective is =E2=80=9Cencapsulation he= ader compression=E2=80=9D as that is what we have spent over a year on with= DT finding an optimal compression solution.=C2=A0 So here the lowest commo= n denominator ends up being 32 bit SID and we now have failed the primary o= bjective of a compression solution. =C2=A0=C2=A0

    As far as lowest common denominator is it true that in ord= er to meet all the requirements draft list of all SRv6 compression requirem= ents both next and replace have to revert to that lowest common denominator= which is 32 bit SID.=C2=A0 If that is true, unfortunately that makes the d= raft fail the primary objective of any SRv6 compression solution.

    To that end as far as interoperability on Next and Replace= interoperability being the hinge pin of this drafts adoption, as well even= if the authors state that Replace can use 16 bit SID as a possibility, as = the 32 bit =E2=80=9CNF=E2=80=9D G-SID is recommended for hardware forwardin= g efficiency and scalability that if 16 bit were used G-SID would fail the = hardware forwarding efficiency and scalability requirements as well as poss= ibly other requirements which should also be stated in the draft.

    6.1.  C-SID Length

   The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths.  A
   C-SID length of 16-bit is recommended.

   The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths.
   A C-SID length of 32-bit is recommended.

    The draft should mention the r= ecommendation for common block length for interoperability.=C2=A0 The only = block size possible is 48 bit so block size so that would be a major addres= sing inflexibility for interoperability.

    <= div dir=3D"auto">
    6.2.  Block Length

   The recommended SRv6 SID block sizes for the NEXT-C-SID flavor are
   16, 32 or 48 bits.  The smaller the block, the higher the compression
   efficiency.

   The recommended SRv6 SID block size for the REPLACE-C-SID flavor can
   be 48, 56, 64, 72 or 80 bits, depending on the needs of the operator.


    Taking this f= urther another step as this draft needs to describe in detail with examples= of the feasibility of how two adjacent nodes one using next 16 bit SID and= other using replace 32 bit SID as recommended where the 16 bit uSID next f= lavor and 32 bit G-SID are in the same SRH 128 bit container.

    As the uSID Next flavor draft perform= s a shift towards B towards nibble A, B nibbles, and Replace does a replace= of the A-Arg portion =C2=A0of the 128 bit IPv6 address, how would that wor= k with adjacent nodes using different SID flavors of different SID lengths.= =C2=A0


    The Next flavor uSID SRv6 PGM =C2=A0compression solution proces= s is very different where when indexing the micro sid nibbles within the 12= 8 bit container, it performs a shift towards the top lower order bits of th= e IPv6 address, where the Replace flavor G-SRv6 PGM compression solution in= dexing the 4 G-SIDs within the container does a Replace at the A-Arg bottom= higher order bits. =C2=A0

    The referencing of the 16 uSID or 32 =C2=A0bit G-SID =C2=A0nibbles, inde= xing and reference of which nibble to referenced for next and replace for d= irectly adjacent nodes with nibbles within the same 128 bit container or ad= jacent containers is the interoperability issue that seems to exist. =C2=A0=

    This needs to be clarif= ied on the next snd replace interoperability operation in detail.

    Also Replace flavor uses COC deli= miter for signaling compression function is active where Next does not have= any signaling of compression being active or not or may have a different w= ay of signaling that upcoming node does not support compression.=C2=A0=C2= =A0

    How does the compres= sion signaling interoperability work between Next and Replace flavors.=C2= =A0 That should be addressed as well in the draft.
    <= br>
    Kind Regards

    Gyan
    Verizon Inc=C2=A0

    On Fri, Oct 8, 2021 at 1:34 PM Francois Clad (fclad) <fclad@cisco.com> wrote:

    Hi Gyan,

    =C2=A0

    It is possible to combine SIDs of different C-= SID flavors and C-SID lengths in the same SRH, along with those defined in = RFC 8986 After all, they leverage the same SRv6 data plane.=

    =C2=A0

    Let me give you an example.

    =C2=A0

    Assume that an SR = source node wants to send a packet onto an SR path through 10 SR segment en= dpoint nodes (nodes 1 through 10), and have a VPN termination for a VRF 123 on a last SR segment endpoint node 11.<= /u>

    =C2=A0

    The SR source node selects the segments as fol= lows:

    • On nodes 1 through 5, the SID 2001:db8:= 0:0K01:: (with K being the node ID) bound to End with NEXT-C-SID flavor and= 16-bit C-SID length.
    • On nodes 6 through 9, the SID 2001:db8:0:0K00:0001:: (with K being = the node ID) bound to End with REPLACE-C-SID flavor and 32-bit C-SID length= .
    • On node 10, = the SID 2001:db8:0:1000:0001:: bound to End (RFC 8986).
    • = On node 11, a SID 2001:db8:0:1100:d123:: bound to End.DT4 (RFC= 8986) for VRF 123.

    =C2=A0

    The SR source node then sends the packet onto = the SR path by performing the H.Encaps.Red behavior with:

    • IPv6 Source Address =3D <an address = of the SR source node>
    • IPv6 Destination Address =3D 2001:db8:0:0101:0201:0301:0401:050= 1
    • SRH =3D
      • SegmentList[0] =3D 2001:db8:0:1100:d123= ::
      • SegmentList= [1] =3D 1000:0001:0900:0001:0800:0001:0700:0001
        • SegmentList[2] =3D 2001:db8:0:0600:0001::=

    =C2=A0

    Therefore, there is no notion of lowest common= denominator for C-SID length. Based on the deployment requiremen= ts, an operator has the flexibility to select the SRv6 SID flavor and C-SID lengt= hs of their choice.

    =C2=A0

    We can update the draft with this type of illu= strations.

    =C2=A0

    Thanks,

    Francois

    <= div lang=3D"en-FR" link=3D"blue" vlink=3D"purple" style=3D"word-wrap:break-= word">

    =C2=A0

    From: spring <spring-bounces@ietf.org<= /a>> on behalf of Gyan Mishra <hayabusagsm@gmail.com>
    Date: Sunday, 3 October 2021 at 21:01
    To: Yisong Liu <liuyisong@chinamobile.com>
    Cc: James Guichard <james.n.guichard@futurewei.com>, SPRING WG &l= t;spring@ietf.org&= gt;, spring-chairs <spring-chairs@ietf.org>
    Subject: Re: [spring] RE    =EF=BC=9A WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng= -spring-srv6-srh-compression/

    =C2=A0

    Hi=C2=A0Yisong

    =C2=A0

    The main goal for operators is interoperability.=C2= =A0 As interoperability is the key reason for a single SRv6 compression sol= ution that we have WG consensus and is desired. =C2=A0

    =C2=A0

    Continued details of the interoperability study =C2= =A0should be added to the draft as the study progresses.

    =C2=A0

    One key detail that is missing is forwarding efficie= ncy and scalability using NEXT-C-SID and REPLACE-C-SID interoperability usi= ng 16 bit SID. =C2=A0

    =C2=A0

    As NEXT-CSID uSID Container Micro Segment shift flav= or using GIB/LIB for ultra scale =C2=A0SRv6 compression solution is recomme= nded for 16 bit SID and REPLACE-C-SID G-SID G-SID Container based solution = is recommended for 32 bit SID.

    =C2=A0

    Of all the requirements as stated, the encapsulation= header size is the primary objective for operators to eliminate MSD issues= with optimal forwarding and state efficiencies.=C2=A0

    =C2=A0

    At this time in order for Next and Replace solutions= to be interoperable keeping in mind requirements for optimal forwarding an= d state efficiency 32 bit SID would be the lowest common denominator which = should be stated as the baseline result of the analysis draft on CSID overall 2 prong solution.

    =C2=A0

    CSID draft:

    Bottom of section 11:

    =C2=A0

    =C2=A0

    = =C2=A0 =C2=A0The interoperability was validated for the following scenario:= 

    =C2=
=A0
    =C2=A0=C2=A0 o=C2=A0 Packet forwarding through a traffic eng=
ineering segment list
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 combining, in the same SRH ([=
RFC8754]), SRv6 SIDs bound to an
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 endpoint behavior with the NE=
XT-C-SID flavor and SRv6 SIDs bound<=
u style=3D"font-family:monospace">
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to an endpoint behavior with =
the REPLACE-C-SID flavor.
    =C2=A0
    =C2=A0=C2=A0 Further interoperability testing is ongoing and=
 will be reported in
    =C2=A0=C2=A0 this document as the work progresses.

    =C2=A0

    King Regards=C2=A0

    =C2=A0

    Gyan

    On Sat, Oct 2, 2021 at 12:56 AM Yisong Liu <liuyisong@chinamo= bile.com> wrote:

    Hi Chairs & WG= ,

    =C2=A0

    I strongly support the adoption c= all. Regarding chair's note in the email, I would like to point that th= e network programming model (RFC8996) by nature defines multiple behaviors. CSID has a single SRv6 based data plane that defines t= he next and replace behaviors consistent with the network programming parad= igm.

    =C2=A0

    CSID's next and replace behav= iors have been verified by=C2=A0interoperability test=C2=A0in China mobile laboratory and there is no problem with the interworking = of the two behaviors on the CSID dataplane.

    =C2=A0

    Best Regards

    Yisong

    =C2=A0

    =E5=8F=91= =E4=BB=B6=E4=BA=BA: James Guichard

    =E6=97=B6= =E9=97=B4: 2021/10/01(=E6=98=9F=E6=9C=9F=E4=BA=94)22:04

    =E6=94=B6= =E4=BB=B6=E4=BA=BA: SPRING WG;

    =E6=8A=84= =E9=80=81=E4=BA=BA: spring-chairs;

    =E4=B8=BB= =E9=A2=98: [spring] WG Ado= ption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/<= /u>

    Dear WG:

    =C2=A0

    The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a solution for SRv6 compression.

    =C2=A0

    The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

    =C2=A0

    Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

    =C2=A0

    1. The SPRING working group is adopting a document that h= as multiple SRv6 Endpoint behaviors.
    2. The document is a =E2=80=9Cliving=E2=80=9D document; i= t may change as it goes through review and analysis by the SPRING working g= roup.
    3. All open discussion points raised on our mailing list = MUST be addressed BEFORE said document is allowed to progress from the work= ing group to publication. A list of these discussion points will be documen= ted in the WG document and maintained by the document editor in conjunction with the chairs.
    4. If this document is adopted by the working group, the = chairs specify as part of the adoption call that the following text describ= ing an open issue be added to the document in the above-described open issu= es section:
      • "Given that the working group has said that it wa= nts to standardize one data plane solution, and given that the document con= tains multiple SRv6 EndPoint behaviors that some WG members have stated are= multiple data plane solutions, the working group will address whether this is valid and coherent with its one data pl= ane solution objective.".

    =C2=A0

    Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open discussion points you would like addressed should the = document be adopted into the working group.

    =C2=A0

    Thanks!

    =C2=A0

    Jim, Bruno & Joel=

    =C2=A0

    =C2=A0

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

    --

    = =

    Gyan Mishra

    Network Solutions Architect=C2=A0

    Email gyan.s.mishra@verizon.com

    M 301 502-1347

    =C2=A0

    --

    =

    Gyan Mishra

    Network Solutions Architect=C2=A0<= /p>

    Email gyan.s.mishra@ver= izon.com<= br>

    M 301 502-1347


    --0000000000002aae0805ce05610d-- From nobody Sun Oct 10 13:31:05 2021 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 5AD9C3A0D9A; Sun, 10 Oct 2021 13:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mtn.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 uCdG1rw3rDZG; Sun, 10 Oct 2021 13:30:56 -0700 (PDT) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130044.outbound.protection.outlook.com [40.107.13.44]) (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 8622A3A0D99; Sun, 10 Oct 2021 13:30:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BIabP2dHTHR+znkjGQ7LpjCYNH/rpF5HS/nA2D5myR0UnmYSFzfv/N7cd75HiHRAbN0CK+t/1zh3Y9YecKWSpj+CpWVzJCfRKLYDG1FTXg3Jra0ao6fKImdJ/m7nGtXakUZpKPDf+lTxiJzr10+dZH2UvsELWgn1lJe+tSSwsz3fBiD36tciS9ANWav1jhKm3MUOIUtULHHXZOv07URMU69fesawpzzd/Q2L8jbKYZ4Fp27jMk8Z9E7vkP+Zula8Grreh/ETkO9bwm8WSVG6WpqeediHz5qV1aoCKMLjQJsiRLB1c8D9fZRJKYJnuc2qo/6yNAAtoXAcA9zQReur5Q== 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=AKmBBaJyBDBV//Lu4Xxl+sTCTz/m+m+PnY36MffeJvM=; b=b7/jgCix8qM5OH0v1v1WIGnARNNvHvlfV8hSuAovtYN5LeXWQBQ5QMAHvuzVd5qeQrmrdloKGAbcI7twpIYW3JQ3rMZ3nBQnuHDFCi0RVceDb7oYbZCRlO1wDfBTGtVBP2RP+x8Z+DBUg0lLCeoZIZj+Or1VF/4PppGV8w8mqctxrSZ3yVPqOWt4dcCey8VVh89jZ6FDigHT+0rIaG9PMOwWHtCT6Ed1p7ViJuBWGifdA+/dsSi1Z+yg6VpPYD142ur30knhS4bNJEfdiWqrn4cD/7XFZzvV/ZnnaQxiZS1ymlxjHhAc0yHP1kh4gu157ATVIrD20YKXlf8ojjc03g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 104.209.35.28) smtp.rcpttodomain=futurewei.com smtp.mailfrom=mtn.com; dmarc=pass (p=none sp=none pct=100) action=none header.from=mtn.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mtn.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AKmBBaJyBDBV//Lu4Xxl+sTCTz/m+m+PnY36MffeJvM=; b=X01M8Z8hoMJtIj/dWn3h9VRArwa0Sbzd1K23qCtKeY3KLBbCS3vnkxc4FeaZc+7uJdNGJnE1M6e1qjSY1fESjcHcmcEcEbQkzVUlM6W0tkja4Ie6yS9n9bXado6mn61GIqgvcaJa5gUKTeGJIyJzbY/O1aTEx0FSeJIH4L/K9Jk= Received: from AM5PR0602CA0015.eurprd06.prod.outlook.com (2603:10a6:203:a3::25) by VI1PR02MB5375.eurprd02.prod.outlook.com (2603:10a6:803:c5::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.22; Sun, 10 Oct 2021 20:30:46 +0000 Received: from VE1EUR03FT057.eop-EUR03.prod.protection.outlook.com (2603:10a6:203:a3:cafe::99) by AM5PR0602CA0015.outlook.office365.com (2603:10a6:203:a3::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.25 via Frontend Transport; Sun, 10 Oct 2021 20:30:46 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 104.209.35.28) smtp.mailfrom=mtn.com; futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=pass action=none header.from=mtn.com; Received-SPF: Pass (protection.outlook.com: domain of mtn.com designates 104.209.35.28 as permitted sender) receiver=protection.outlook.com; client-ip=104.209.35.28; helo=us2.smtp.exclaimer.net; Received: from us2.smtp.exclaimer.net (104.209.35.28) by VE1EUR03FT057.mail.protection.outlook.com (10.152.19.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.4587.18 via Frontend Transport; Sun, 10 Oct 2021 20:30:43 +0000 Received: from EUR01-HE1-obe.outbound.protection.outlook.com (104.47.0.59) by us2.smtp.exclaimer.net (104.209.35.28) with Exclaimer Signature Manager ESMTP Proxy us2.smtp.exclaimer.net (tlsversion=TLS12, tlscipher=TLS_ECDHE_WITH_AES256_SHA384); Sun, 10 Oct 2021 20:30:45 +0000 X-ExclaimerHostedSignatures-MessageProcessed: true X-ExclaimerProxyLatency: 37445551 X-ExclaimerImprintLatency: 8299867 X-ExclaimerImprintAction: e1978861d8f24d50b70d8e56061154ec Content-Type: multipart/related; boundary="----_=_NextPart_70e02604-672e-48e0-b995-ea3a65afca22" Received: from AM9PR02MB6979.eurprd02.prod.outlook.com (2603:10a6:20b:262::11) by AM4PR0201MB2210.eurprd02.prod.outlook.com (2603:10a6:200:4d::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.25; Sun, 10 Oct 2021 20:30:38 +0000 Received: from AM9PR02MB6979.eurprd02.prod.outlook.com ([fe80::5cd:3f2:34cf:52e0]) by AM9PR02MB6979.eurprd02.prod.outlook.com ([fe80::5cd:3f2:34cf:52e0%3]) with mapi id 15.20.4587.026; Sun, 10 Oct 2021 20:30:38 +0000 From: "Luc-Fabrice Ndifor Ngwa [ MTN Cameroon ]" To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQG4DHBQ Date: Sun, 10 Oct 2021 20:30:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: futurewei.com; dkim=none (message not signed) header.d=none; futurewei.com; dmarc=none action=none header.from=mtn.com; x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: ba5fcca6-3b71-4fed-141a-08d98c2cd6de x-ms-traffictypediagnostic: AM4PR0201MB2210:|VI1PR02MB5375: X-Microsoft-Antispam-PRVS: x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: ihkC17xmaRvsoYciJjL/JQOD+sCAGeu/aVO09BhG5Gaim+QRbU/T1MDtOUs7Vzq/N42Rw8qoc8g5hsB6cvDIn3YuibDLNl4ZvJ/7xkfVj/gEe9pYnCw+Zdr99r13jhAQMzN9Q+N0XrV4tiHKSKU256+iGsvJqQLVcQVmStSWnbZxQU1upN0GbcV4BsW2QcE+hwI+JB4xLWkttpb6VxIm//vh6LQtwGjUiSiJWDF8HW2nvQ1SuX97DuN8j0UGW0fbPff7A4hiFavlXjB5v3sDv4fOwKqfWfN2qbBDKP7AYEc532P3pW7Lhf4RB6FurCHVWCPN7UUVVx8uunO7TjBIw7twCTmeJmSITlW3+1/b5HmupQFhtX95hUrAIdjRRqjL3TggLxWz+mZdZRwgzGECWZJ/L8x2R/iJmT/wkn5yUccybHgSM8cE5l9SNL9uDhGzYZX/JLukvklotCikdChCopovsDlbGG2eWPPX5xjvyJ0SY8s8KfOyrS4mdWd8GURj0D+Es/t55FxtT0/hct+5plNalIP7p5gfezOnesPHbqn1qL+d4ula55qRNSmyDoSTI8F2s7F3PelC+QH59VxH6hqbtBh2PDbwZ3aT5eqoSfsWas3jM6BVF9JzXAQHMpEOdkB7YFRJnE9Z6SAhqi9CqbWvi/zwQ5M51hSYBYJflFK7uDE7x/12eqz8NHrEt5tynx+OSGkOJD3OEOLX1rUCGkFhVlknLVEwyHn6CrhU6VMXZhdX192OGF06cNYKOelBcrTD5rm7UsFxOMjVKbCO4wyP5YEVz53U9VsHTI7y78A= X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM9PR02MB6979.eurprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(4326008)(76116006)(86362001)(66556008)(64756008)(66446008)(66476007)(166002)(66946007)(508600001)(55016002)(9686003)(6506007)(53546011)(966005)(83380400001)(8676002)(2906002)(38070700005)(186003)(8936002)(316002)(26005)(5660300002)(110136005)(7696005)(52536014)(122000001)(38100700002)(71200400001)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR0201MB2210 X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT057.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 22f3e5f8-0a34-4928-8379-08d98c2cd221 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: KY7hgNbYLDG4JGr9hkt1725gU6VT/0OEvIyyP03j5NDkXJOLdlcf3eDDHjfpjo0Xann/7jGKFy0I5+2t69neuj3CC7EF2HwtLbKoSAIbp89L4HYp1pON5fAIkJ9ENEGsL21ByFDTHj3ykJ2T5qsue48r4ZbGuoCBtBffUGdiJgNAj9a3sge9FCaGi0Qoi4U4K7o1FxdYYnm3L/cjoR9+5vhhCoWrgySvX6htrxDy+7q2nIZstpKcyK2ZhYNfsbDmt9UZyWk+aNdz3SvULM1VpU8x8xqnPSEPfNP51uvUUAaopqh19BSC6PUuw/5zD6fCJE1NYfUkjAhvWNtU3kaT+v6ErFoHqxRiuCSkfiyhy+my8EDuG68r8FMBLgO0gBOAppwGeN6Sc8H2tYOOafrmnibddKKa0VkpDuJvi1zw8jp7M3CPNHmT2dT8sjFBFCjl1CFFTlb0b6jkm4+gfmuEAsFDLnID91tnxFh9TO0MGH2KBrPTDq5V5/GQK3NIX6v6DFf4mf4vHT8aDkgQM7YhcyRXTe5FxTtQMCG2kYObg4gNKI7qhA2LKNTM7EJ3OJiwCbt4V6NgcN6dJYYgg8qm93JuawXwpX6P5HZfJL8yNhC75fGUrcQJojfsEPq2IZLJsP0xlaQ4fl9aPcGHPujnCeR2Q9C71LK9DsxZU+69IgdcqHN6rhe3WkD3fL6LWGF2G0yG1ePIJd7BkkIg1XcewP3HNIGjGmxeLpUgrk29hf5ThNx9UlH+wavAv7gBfY4UWeaFrefVjmxFc6HFgEYxFZ1AGrhUr974Nwp3lr6srys3LNwuOo5E1nwZWcndf0ot X-Forefront-Antispam-Report: CIP:104.209.35.28; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:us2.smtp.exclaimer.net; PTR:us2.smtp.exclaimer.net; CAT:NONE; SFS:(4636009)(36840700001)(46966006)(26005)(316002)(52536014)(55016002)(70586007)(110136005)(33964004)(9686003)(36860700001)(2906002)(966005)(86362001)(83380400001)(6506007)(53546011)(166002)(508600001)(336012)(5660300002)(82310400003)(7636003)(356005)(4326008)(186003)(47076005)(7696005)(7596003)(33656002)(70206006)(8936002)(8676002); DIR:OUT; SFP:1101; X-OriginatorOrg: mtn.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Oct 2021 20:30:43.6735 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: ba5fcca6-3b71-4fed-141a-08d98c2cd6de X-MS-Exchange-CrossTenant-Id: c9b9cb50-3644-4db4-a267-fa84df2f4ceb X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=c9b9cb50-3644-4db4-a267-fa84df2f4ceb; Ip=[104.209.35.28]; Helo=[us2.smtp.exclaimer.net] X-MS-Exchange-CrossTenant-AuthSource: VE1EUR03FT057.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR02MB5375 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 10 Oct 2021 20:31:04 -0000 This is a multi-part message in MIME format. ------_=_NextPart_70e02604-672e-48e0-b995-ea3a65afca22 Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_AM9PR02MB6979899623F7E6851B5C15BBDBB49AM9PR02MB6979eurp_" --_000_AM9PR02MB6979899623F7E6851B5C15BBDBB49AM9PR02MB6979eurp_ Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear WG, As a multi-national operator who has deployed SRv6 in some of our markets, = we believe we need the SRv6 compression mechanism based on the SRv6 data pl= ane. After reading the CSID, Compression requirements and analysis drafts, = I think CSID is the way to go for standardization in IETF, and luckily, tha= t is happening now, so I strongly support the adoption. I also see many vendors have implemented CSID, and some interoperability te= st have been made on this, so I believe the mechanism is mature enough. Hop= e we can have CSID adopted soonest, while the issues can be addressed in th= e progress following IETF process. Thanks so far for the work done by the Chairs and DT members. =E2=80=8BWarm regards, Luc-Fabrice Ndifor Specialist - IP Access and Data center Luc-Fabrice.Ndifor@mtn.com T +237 677 55 02 13 Head Office: 360, Rue Drouot =E2=80=8BP.O. Box 15 574 Douala, Cameroon T +237 679 00 90 90 | mtn.cm This email is confidential. If you have received it in error, you are on no= tice of its status. Please notify =E2=80=8Bthe =E2=80=8B=E2=80=8Bsender imm= ediately by =E2=80=8Breply email and then delete this message from your system. Please = do not copy it =E2=80=8Bor use it for any purpose or disclose its content =E2=80=8Bto any other person as to do so could be a breach of =E2=80=8Bconf= identiality. =E2=80=8B Please be informed that no employee or agent is authorized to conclude any= legally binding agreement =E2=80=8Bon behalf of MTN Cameroon =E2=80=8Bvia email. This can be only done if the email is confirmed explici= tly in writing =E2=80=8Bby an MTN Cameroon authorized officer. In no event =E2=80=8Bwill this email or its content be construed as a written =E2=80= =8Bapproval. From: spring On Behalf Of James Guichard Sent: Friday, October 1, 2021 3:05 PM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= =2Eietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the bas= is for its compression standardization work. That is part of what this emai= l attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_AM9PR02MB6979899623F7E6851B5C15BBDBB49AM9PR02MB6979eurp_ Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

    Dear WG,

     

    As a multi-national operator who has deplo= yed SRv6 in some of our markets, we believe we need the SRv6 compression me= chanism based on the SRv6 data plane. After reading the CSID, Compression requirements and analysis drafts, I think CSID is th= e way to go for standardization in IETF, and luckily, that is happening now= , so I strongly support the adoption.

     

    I also see many vendors have implemented C= SID, and some interoperability test have been made on this, so I believe th= e mechanism is mature enough. Hope we can have CSID adopted soonest, while the issues can be addressed in the progress fo= llowing IETF process.

    Thanks so far for the work done by the Cha= irs and DT members.

     

     

    =
    3D""
    ​Warm regards,= ​
    Luc=E2=80=91Fabrice
    		 
    Ndifor
    Specialist =E2=80=91 IP Access and Da= ta center
    Luc-Fabrice.Ndifor@mtn.com
    T +237 677 55 02 13
    =
    Hea= d Office: 360, Rue Drouot
    ​P.O. Box&nbs= p;15 574 Douala, Cameroon
    <= table cellpadding=3D"0" cellspacing=3D"0" border=3D"0" style=3D"white-space= :nowrap;color:#000001;font-size:9.33px;font-family:'MTN Brighter Sans&#= 39;,'Century Gothic',CenturyGothic,'Apple Gothic',Arial,San= s-serif;font-weight:400;font-style:normal;text-align:left;line-height:13.33= px;">
    T +237 679 00 90 90
     | 
    mtn.cm
    This email is= confidential. If you have received it in error, you are on notice of its s= tatus. Please notify ​the ​​sender immediately by
    &= #8203;reply email and then delete this message from your system. Please do = not copy it ​or use it for any purpose or disclose its content
    = ​to any other person as to do so could be a breach of ​confiden= tiality.
    ​
    Please be informed that no employee or agent is authorized to conclude an= y legally binding agreement ​on behalf of MTN Cameroon
    ​vi= a email. This can be only done if the email is confirmed explicitly in writ= ing ​by an MTN Cameroon authorized officer. In no event
    &#= 8203;will this email or its content be construed as a written ​approv= al.
    = 3D""

    From: spring <spring-bounces@ietf.org> = On Behalf Of James Guichard
    Sent: Friday, October 1, 2021 3:05 PM
    To: SPRING WG <spring@ietf.org>
    Cc: spring-chairs@ietf.org
    Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

     

    Dear WG:

     

    The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

     

    The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

     

    Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

     

    1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors.
    2. The document is a “living” document; it m= ay change as it goes through review and analysis by the SPRING working grou= p.
    3. All open discussion points raised on our mailing list= MUST be addressed BEFORE said document is allowed to progress from the wor= king group to publication. A list of these discussion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
    4. If this document is adopted by the working group, the= chairs specify as part of the adoption call that the following text descri= bing an open issue be added to the document in the above-described open issues section:
      • "Given th= at the working group has said that it wants to standardize one data plane s= olution, and given that the document contains multiple SRv6 EndPoint behavi= ors that some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

     

    Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    --_000_AM9PR02MB6979899623F7E6851B5C15BBDBB49AM9PR02MB6979eurp_-- ------_=_NextPart_70e02604-672e-48e0-b995-ea3a65afca22 Content-Type: image/png; name="image365107.png" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image365107.png Content-Disposition: inline; creation-date="Sun, 10 Oct 2021 20:30:45 +0000"; filename=image365107.png; modification-date="Sun, 10 Oct 2021 20:30:45 +0000"; size=74234 iVBORw0KGgoAAAANSUhEUgAAAhwAAAChCAIAAAADV/GpAAAACXBIWXMAAAsTAAALEwEAmpwYAAAA GXRFWHRTb2Z0d2FyZQBBZG9iZSBJbWFnZVJlYWR5ccllPAABIYdJREFUeNrsfQmAHFWZf726u/qa njvJTO4DkgAJBAKEGwMSREUBQWDFa1FhRf+Lq+uyXqvrvbsoiKwruisICoIKhEuOAIGEJJBA7jsz k2Tuvrvrfv/36lW9et09MznJItufcejuqnpV9ar7+73v+n1g5esbOMghgYADnPcCQgDwS/8tR157 O/kC8Mf+dq7ydbCdfgxrPuE4RRUT0VgiFtU0VVVk7piI47qZTL53cMgwTO8WIXtp6L8QXZ/3Ocfx XHi/0Ps/mh6eAy76Lz0WeHMVTI+/f/hf6G13XXIG73O8e/g/7wMHut5+3icASLyIRud5HuD/4Cvx XqAx8CMhj4W8AsG1ks/JBxygTwpwoHre45FI54R2ri51qUtd3jbhoQuDV77OI4gCQziAVGVCrHkr XoRqGVQiCgs9dN9gk225hmVaSGzHwWr3WIjA8xFViUZUT+ESJQ+8V4Cjahj4gBDcFAw28T6yoNc8 JAAMOV/N+wP5Gp9uQQgEgQcPo1wRBiTegwgKRARsvAvwX/qgQC8JH8WTjegz3kcO7y4ArAB4skd4 IJcvl9OZXP1LX5e61OVtBBXyH0//kRUv1f8gwAqiWclmT3VVgkiFuQICOKrQb3RQciRwXGiYlo5g xbRs2z5md6uockyLSLKIlbkPAPT+IAysNR9Vye36MwHxVAXKHwR4AgA5hBwAsSkTTgTPAWqp0VsH FLqCk/hn9K8GQoIo3n+8ayIfMLYiXgeA0DACAdDDAIACRGT+BtI3OHQsJ7wudanL/zlQAVi7Yv3H BboQBPhBF8kV/h1PpYJK71DoZaEeJcB8SHfN7gE9y8X0drTFMh3DNCwMK8fUWNEiEc9YIYraDVxK tTCJ1LlLwYILXFQccTgBjmO9TFj18xhFIEWe0EzjfMAILRb6qTfNvj+L7G5jxIC+gQGZS8Kfub4J BCBzCvYFF4APZD1xlbYR2Lmnp/69r0td6vI2CVqzc0SzwsBsCXQn0YGwYt3rY01og0C6EmbjLLDC CQagbQ3vgrtX2OnB/p6tbeM7I4tvhZkdjpkylOMkU3IkUZD5Y2SsKHI0EimWypZlE7vLgwR6G66P H/57l9wAAzsg9OlBwEyBb/QEh5LIFAjsBwpNXBCQIYdD/70/2QjH0BkF6FlSwRjhnPqhHWYwgu+g Yjcu9JJVYw6+EwfC3d37JneOr3/761KXuhx9UKEKja/wYHleHX8bXZ9D3x3EyAhvyK6OZfa+JfVv dNO7OaPERRK5XKmUzWZzQwPp/WDzR0XbnXXcPP4DX1GkDsuSBFFAZsSxMFYEZKyo6F/WLtI1fRAI AdQnhe/YRX95HEHxYRQEGMNVYIyvsV06EoSMcg8HJmjkgwzgfEwJD4K+EeJAR/AcbIBAPfFwBckT aLv3cHgPijjAxGMAqLZauEqcITiF5jlfKg0NZZqaGuo/gLrUpS5HGVRoqJld4tIVOFW0vp+mOmFq hMwv9NYY2GJuf9HODwBT13PZ/fu2lx1h35CZirklS06nMypw25pSO/dmklDSTUuWbekYGisRVYlF IqUyMlacMHgUOrXI3ftvSRjfu33oG3ShruZZFxUIQuuAwjFCGuwQo1DkgqphOZoGhiP2BJegCz0k AzQdgIZyvMF5jgmwMFjCVbjxmIuo9pRBiCa7u7cvkYihaa//BupSl7ocXfeXnx7kMtGAMLwcKlkI aOAXVsZLKnGl1LXS3r0mM7D1lVfXtTdHI6KdyZdMB2SKtu3K8aiYKXHTxjcnJp8/9bJP2pxgmIYH K6IoojX0scAVdCJNQ6iiWlZpNKPLmw/Oy+j188T8+DzJ/cJeMj+0EcaUCH4ALkgOA9ib5aMTST0G kI3bB9lkFcEP73PbdUV8YggC2PHORmxAD7SweyzMPqPQEuQaVNhfFbdHMqYBzwv8xi07Tpo7q/4b qEtd6nJULZVqe8O3Tqj7hl2Ih0tkOHIo3hremd/84s4tK/Z0D5QNaFnRHV17RcGxIY+wBEIjonDj 28affMU/jzvpBMAD14GGZZumZUpo0SzKx8pYURU5pmnFsu44Lhcm49I7dT33Es/R+hKsrnnPeeWn exFTA1ZMB/RxyDdE3NCwCRLmvAxmSLMgwiEA8GGbhHg8DHK9U3KwwgAJ3Is0WQKyKQAMgrC5BFxo uwQii0LRsLdu3z1z+uT6z6AudanL0RI+DCv4upKsyyHHZAgHuVKVKgtWKS3OznYV1z3e27Vj5dqB wTR3/hlnHX9cp8lpezNC15CgiJwAoCi1XfDp74+ffyLg/cMsyy4jYwVXrdjuCAlLb4sgBItG1IhX d8nkUfuaHwAB6XMAXOCnT5N8OEjKUQjmgiAbzM8HJkAMWGiuVOg0tOJnPPC+2wqEDkb/XH6EBZtK rhukF/uJxW6QKEGdcAAH9iF5dlz4YGpnkklMRmMhU0WUhcF0LpPN138GdalLXY4aqIQJqJyfTER0 ZkUJI2B886AybzjQXa6ZL6x7rLf7rYHB3vam6KWLL5MjfKlsTZ3YWtb5k2eOQ6v/plTnWR//cdO0 qax5g40V0zIs0ytZcY7Znau4EDLC817RZ5DI5XmZXFhRbuKXtnMk7xr/cwLwCWADq2o3hCY+KHEH tOrFBSB0LnpxEViZZsyRsDsfHGa70PeZMbAQ1uVX+LQcH15AtR+vwpL0Bw4CRzwvigL6t2nbLpwI V5e61KUuRwVUABeW3ZHkLhDGqqFf/Fcbja/yrRg5d8Mf7WK5qzs7NJCZffwJsebkwGBON/Tu7r5T j2ubMK5p8sTJJ3/w/yUnd1RqPtcZ3goHtxuGblnH1FgRkbGiRSKKRAsSveReyHEVSVV+gJ3mxGEA EQAncDTSAQKF7kGSH/vwOAeAX4pPUYRjcIXEPyAAlSjga37f4PBL7GmJEKkRornfnAvDciKeuWBA I2NsvT5rvuBwvSAii8123S079tR/CXWpS12OioAVr2+oiWMw3vuRtlSDi6PzGx4EuT6Ol9HCP19w Ek2NUkQtZnPLlr2iapprF5RIpH3OpR1nv48N32S3Lxta9UjE5lra29QzrmuafEIsGo1FI8csJSn9 L38qf/CkfsGGrsO4rfggiRoGTikYaGuXiUyAAIQgBVmKREERCueHXvzjKni/sHUTeLWqCMEwXKBL 4vmACgxhUwD/XjpxwP9FYAwEPDE8E72ptFdqrRivFNQwzUJBt2xr5tRJbS2N9d9DXepSlyNdrwfU iSQSzXEjmCU0r3gkjkg0RP86Nzekl4xIVLR0Ix6Vo7IJLX18W+wjH168c8++nbt2yomZE866lB5W 7t84sPaxnWuWq7wgCFxfwZh/YXvZNBVZNr2aFX5UvqyjKcqJk93daXV2qqzbYe4bDFKHvbAPSxiA VDtkkqohrMhvALBq1kAIRzRZGbgsVNP6Uu/osLTFi84AF2ePQYG9KnImWFFYz/mpX2wKcdUbug8I jUxvEEkUEIQjUNnTvS8e0zTMNVCXutTlXSp2gSts5cweTse0GjD77Ah2RvQUTmzgxASnzYaRcUAZ d8igEigxHAiAwHevhN4tLvSlhNqVVVb6sNC7TtIiuXxJz2QVVS3nC+ViznHdJqs5kUp2jkv09GhT L/4YpvwyC/3rHivuXW8MDyDN2DuYk3kYS8w49YqvcILsMYFZsmXLksgfE2MlcslckC3GrLKum7CC 3Nd3QMEKJuagZBEw7C3At0Wq04I9VrAgBZgDAfVzkOHlj41TjoOUYpr6RVO8AMSwAjnBdSE2VAAt qg+yuwkZAsPlEnJJ+uUsFfAF2QfomVk8j0CFF03BdpxdXXvnzJpW/93VpS7vQilug5sug8aWA+4I cw9XmRT8uO9wU796CKBCeNz9BCRY4/gCVdSQNDOVxBgcfsdTgl2UI/H2SdM2rlsdB0KpXHRtSxIV yKVz2VxEkWbNnNI6QX3zxYcKO94o53JDAz04lOLCWLxj2oIPTjv/MjmGdsZsYLppyhJOLj42xgqQ BbU5rmU5uVg0THsEXx+kVgioKEEMKnggZXrxQxoutmbwX4pB6DZcPzYVmnguqc/nvfRjlwvcaBU1 9h4/pevyAh/YM3zAbUAgCldWggCvQvuKq7BIAGA4pitNUHS8iEEFB1ZKhlEqGz37ejvG17nx61KX d51Y+WpEEZqBMgeWllW/roWZ4ppD0sUigJUur1pEqRqP0VBw9wsg01O2LFGOaxo3Y8bUtRu2ZTMD 48d3IHU1nCtElKgka6mG2DP/9recLUydOmvQNLcOF2QFqNFZZ3/yq8mJ473oM9aIaD2OQEWVZdmy FFnkxYMyVmDYCOaAu5oIRqqBAwBNVaORiIkmnZaBEn5iGJTr4HMEBY0AUAZ8QCHHI3UhJgQMEcfD Cww2XqEiTQIIbRHez46g1aWBzwwGWXguyScmXPcVxf0B9RdkUyuYMBDjpKMQNUKyBXRFQRBlEeDk O2cgnUnE44l4tP4brEtd3t1SSH7zq39ouvaCH57Rufrnz0/vHiqeJo+/bN79Rz6ySJez1WF51tMV qkFatge44e1c/zbb0CVZsR2nkBlGS/Lpk8cNDCXLlpkeyCmSHI9JsVgkElFTscbBgb58tj8ZVYEg t01dfPJVn5NiSrD4989vW24ZGyuyKduCIICDMFYOFlHwLK51133CTmvWsGg67Yn3fk0YPw99LCvS w3t+ti3bvTB11kmJc7ya+UA9w0Bfw5DpiylZD2klSdpWaLgAykEAYUWRexU6ex24fK+XD0Q0AxgP 70L0Px7yrp/RzAUwEaIJZDZxldGVEUiMK8UzVngcWRFFGze3Ebv2758bn17/ydWlLu9iAcrxd780 9eE3V3UNpi0bpo31r/cNPfDJT//4+ZlcedfclpcvPnXnkYBKhbe9gtK+NpRCIwd22dn5SmG43zHS yYY2meONctGwTMCLzU0RUUqWSo0QOqooFrNDZmmIh6Zu5Pb2mq7YsfCK73ScMo+rCS6j/ziOa5qm gTAFV9hjN9jh3VX+F99y+/sSX/oxkJnIc/w0/swVUn6HZFkRy9Y3/0VRG4XGiTwA18y9ecO+Tfsz A5QKkvY8ARAwzR+rIJeW+EBAy0cAi0BeXb3XTMsvsIeQUrRwXMjbEsBPcM6gyp4cEpTWB0kCfNAx DIZdxXyAgQyXGxuaH81484wiURTRVJuWZduObfN1DuO61OXdLXu1f39rd+/mX37p7vtfmNrR/F9P rDq5renBFze9/MDPpkya4lzyN6Xlj16+aM3hDc7DWuuEdS3VeIt8j0/3Cr2QLeRzpuk6DtrPho5l m3a5rJfKdrFoKDLo2981PNSzZdvm/oEBx3UyeRPEz5h3/fcCRGGKLxgssyxX98rrkYo77JIV4exL 9ZdXcUa55nZjIHkSaF7AjzudM/oKK3xbryXecmLLSfObTgEVuEru1Q1Y7fnKCeIp0oIAGGgnrurm y0FVKYmfQ2odBq1VgrbEpGQynH/ed3y5HMcUrGCUYUiO/bRmPrBgQLVxUtXki3H9ecaKK/CCJIsi L+Bn6XLoueYLxfoPry51eXeaKYkP/+Nv9n/2Q2dlc6XXtvYse2PHDYtPiUnSC12DrS3tu/bsWvrE 0p7M4cdW+QAluCquEtquqwJRSPAjs51Pd+tFTB0vCsgukQUeyIqsabFYNBZRFVHgs9lCsqG9a+9A ybCz+VLeblxw9U9O/cStaiISqLmg+y5T7QF9Y8UyTNJq+DArvbXjTml77BUQT426h7FdyP8sftwJ PgjxvKZFNFXx7xrwzJ0LQZKvS3EVhLPGBcWIbGMytsEJ3d1PufJ7dtGiR9J3gCct531PWlCP6U8R zmrAeWCwAvFY1PAZQSklWNhMJUSP2l6dfoQfB3NkyS+EdDxSg659ffXfXl3q8q6UFfkv/27DdvTi +796ZqBY/tINi5PxyIs9vRfPmjxlykz0+RUfvmLh1DWHPb4Iq9qCcKPE54MFLywOuDuWaxG1pSlW FkyEI7KqIUWmKBov8aWyYdlAUqMdzRPjMWXGjOlPPPY7LjL5+Ktuk2NaaOvQ6m4AYGUvQySmaSNj RTGRluMFQTzMLDBh9Dg/tN03rpPnXAimXkI/U1VZi0QKZd2x3RAtfOUdsNxTDe73kBc87xathqSN 5RnGL78LGEnWAky3eTdk+QKU+j58BoT7y+MI4zxM8VoI++WTwE//9mkuScQfACYNGoz8CCtRJsAV FzdZQcaKRJBchILt2Hu6907qnPC2frnlT/1gjK2P3PC+S8+a/X/zZ//+7/x23XDuzW/ekIy9gyqH 1m/fP3f6uL+iaaRfsO3f/tuJ7WH3oH/9zXPfWLYa/+oVJXfnLcdsnHeEmZL69MsvD6EXv31q9Vkn TBnIFZMJ7Wd/Wo4+GcqXpk2cumbNK3oxfdrpvYcPKhVJw5SNcERqFqT6zaK+8YmEoogiD0SQM3XH UqU47xWHY/JDF0TGT4jzAlCiCT0zFInI4yafMe6CT2NEYXmuAG17VVv6grlHDAsZK6YsSzLScaIQ ZgccDbF3LS8sf6Phs2+yp+UBL2A+eOB4jbIocSQHfUpgioZB5jVpFk+1tM/E6ZtzVU40QIjxoZ9v DF2/6D3IBubCIArOggtq4MMwjeOF6zl2Bn3zyCVEl2ERJiRFm7CKWAyEHGB+SjJFF9K5S5YEQxAs 23YdiKA8Wyzl84V4PPb2fb+/ce4C+vrutVv3Z3PsJydM/78b13lh34BuGBu27ztz3tR3yCUlbro9 pSp7fvyZv5Y5RBBIX//0T6/88MYl5PUra3cSJEBy3viWYzbOO0Rg+he3nrr1xvM+uXTj+Edefqts WQtv+smOTA5DZjp7ysyOE2bPhZkVR3IKkYk4B1zqfCWiBIUOdn5/aePTsmO6qmIb5VxmuFgqOI4N gBONRy0TclKypUWTJAHpZ7NcgNARODD3rHNLzY10VRyW/42e2oU72NsOMnlUHFnBNSvgqNasuI6o S5dw2nQO6pzZz2W2uf1b9aFh04w6487jhCggLi3olZsAv4wkSOil8XDIVdwJIXdxIayloQdsdWOQ AIz2d6jbijKs4Q5dYe9Iqv95DNk89oDxARhjROODGEwYsXeDnjS04LLCWcYiCmuCQuzJxNX1pm3b liuImDugZ3/v8W9nJthXr7+ABZWqT/4vy/p//lhP7/A7B1GQIJBDC/K/ojnc05umr29ftf7vPnAm MjKyBf2a3zxNPz99YvsxG+cdhCulZbHSsqtauAmnf72cnXnLC1ny+Y5MPt/f/eErrjw9fusRgUqQ LgwYFcg4wQLJd68dXvdMRAJ5o7Rp65bGGOCdcnq4X5bUkllW00L7uMmS6GBF6WJbQ0GmjCCYhUJS 00uMMwgrw8H19r4NQnEI2lZk0jyrYxHHSxWeGdyN2DUsUzclGVkrtmesIOtssHv3tk2FfCabHiwW S6ZhLH7fVYlUcyyWOjSjeMaitsgO+FYjpxecYdcpj9OdOQWr09AVpWuzfupnXEkjYQnS3IRWsJOa EQCocwlS9c0BWBW5CLqqBK20IKVjoSUsIQF06D/jgUcU5gdHYNCdC//HdTkBeDSfAUZx9CWoqHQE FXxfbIpdLaIENhcUBOwBEw3TdmzJwVab7bp79nRPmtRZ1/LHWJDaYt0sdTkcUOlPs28fe2XD5z60 6M5HXkEGMf2wIYphsqs3c+8zr6/o6n1yV8+C9uZFne23XXsBdTwerXHegbL0xa6PPf8/D8bkp8/9 1Fc2ZNAnM6ZP3/zWq9dflTsyUAEMhIxS0aCnu/vXLRNsp2Tow+nerj17dnFOW3PUMQvQ4fqH+sY1 N8qyEomWU3InUpZyRJFkVVY0p1wQ7Jxg5RwpAaw8HNqS3fAkTKddm481NIii7Oxbb4sNolcv4gNP QAdsmrbhOfl39qzXi5nnnvrj6tfeyOUNtEuhUFIjWlRTnv/Lc7wgtbU1JhPalX9z09RZ8w6ybAV0 /A034cOuNazrcibvpgslx3HQkdqG++RX79HP+TtP3Vdmn/n6u6qPL6le5Jm9gE9RDBmMgYDtsMIo eR4SqhZQkZDMcUy1C/QjK9gtBn1LkjUviRMMmy0QjuojhHBs56F3O7hgRRRFtCZ1HFzJj4YrlEqG x8n2v/Klf/zljXcvW4t+ouj1uGTiy4tOQL9nsmnS3//8pMbEn//po3TnL9299Pdbu6h/5mcPL//+ 8rfQL19VlJSqoGOvvegU+gs/87Z7VvcOvv6V69kgwfu/81t0Luo3/9ffPPfYlt1oN3TqG+fNvOny M+nhYw9OR0N/P7Jg1lefXkX2vGJ6579/egndrerurpo5kV4/OjUy3ei9kD3XDefSunHe+JYbz51H o01VZ7nl1Lk/vHEJWkd/8RdLH9rejR7ldXOm1560dig0e3e/uQ1ZSEgtElckuqR/vejUay8+hd4R +pBGF8z/+of7nlrzu9VbiKeOXD9ZxY/9EOltHvARjHHXdIrIdV7Y0fqNay6oOvXqPRXJJl95dvWk 1hR1WBGZN3XcK2t3vvcXj2I7jBzVO4j+oano/v6NZNKO1jjvNNnWk7j6gvNjP/8zen3Vmu8lr7vq swONn/n8F+752mlHOLLIcE0xaorjioXMKy88ocj85M7J5u41Vqng2Lqpl0zdikW1kp7fuL0f6dKm OJ+MxYqGNZDOqWWcOhRPNgjlkqJokVhCjCaAYya2PeqIUu/uzcCF8Yi2ZTCtqtH9O7YUym7zjHMn nzSDMVKYFxCaljk42Pvs0j+seW3V4GCmVDZ5wOuGlc6XNN3JZAvNjfF4DGzZ0iMI/M5d/zR7zszz L3r/iQvOY7X8aGJYci4fz+RyJd0Iit2NNuv+oebLdb8+hBSX+BRe1NNE9LN3qW5F/ToJYzCJwiAE IxYvQmYc4ONKEIUBXOD+YstRAcNfjKwYgWkbCVi+lurVASTGFlfj7BrZWHEwGT7OLTZwwYoryZzX KQz0dPdMm/a/4IdBivsLS5cjlUECLUiDoLe7BrLEqc2uE4kgVUU/RCry9lXrkYY9b85k9Hbdrl6E AUgXUK103cmzVi8dfPHNnVSjrd++H6kzpIKJbiIqD71936zJaO2JlAgCmCe+8lGkIA44OBE0GgKS F/48cOOJM1Kaig6/d8P2zd/77Svf/kTt3aGtaMyqCBM7D2jli1Q8envnS+su//Vjj3AcOR17luXd vWQQpMvmpuJfOf0EctLpj7xC/IpjDIVmDynEq+94eG/ZRAiaLulokI8/+GxDNELvi4AreY0QBW1F 83PX+89C+6Dl/L2vb0k983qVA3OM2xz7EYx91+TpoK03zluALhVd/LM/fKAq3jNY0ullo8lEd4dG 4LygOlX9He2Nc//lv8nb/1iyCD1Egn/ok2/f9xz5ph2tcd5p8seVp3zqhN206uK8pX9cdOFnH/jN /7z/jDePGFSoLgr/i1XSYw/fv2rFm7t2bjnnuLaT5k6XHAMvlR1TBHwsFkcKf/IEqVB0XNfSIopu mvlyIZ0vlI1yLDOsqLHGxhQHsW6KaBo+rpSNxpp6enry3dsLFtixd6Pjtp/18W83T59SEUvhKK8v VoaFfGbdyw+ufGXFwFDZMq1MvpzOFZKxaESRoeNIkmyUdS9pCkSjWlmHGzft6ev9VdeuTZddddMY 94wuulTSs/kC+mc7DiXmStkrIuP3lZo+SLgWiSXhWRmwkpuRbVLG9MECbDvMCn+en7PlU0tSNR62 EuZCRq+gYJ4JglDAcnCYhw+bpQQBLx7zuQieccTDkJAYVk0tjalURbD8GXddgMP1fsGKY7uChIM2 xWI5j+A3ET/GNgrSKUi/3PPFD9EAzCf+/WGkkpAqP2BWGNoNqQD6Y0b7o8PR+p3ugCwetOREYEBN nz+/ugn9/dT588gqGOkspB3oVqLj7vS08wEHp4KMGJrB9VWOQ9ePVDwa6pwTp1bfXaAoa6PEVXsi 0wFZaUhn0UlAmuuFm68gAZjETbcTwCOXd1NB7/zy3Qii0BUezFCLOtvpfU3xbvkPqzazs00xAx2I /tKhyJRWTULtGdnbHOMRjH2ptU/nh94XpmrqiG2EgOems09C+Ec//96FC9DgNPBOkYCMdsL08dNv +08CzD88quO806TAz/70w69+8Rffan75cenRN9Rh84+fW/Cfjz/QuMQ4wpF5lrc26MMBX33pibWr N8uy3NncYBYzA3v3FgpltH7FDaoEEUFFItEYUZW21pSqqnv2D2/tyfQN7EfKZ1/fvp09Xft7u7Zu 27R181t7u3bu69ph2aVde3Zt27GuWO7bsW9wW3efmDz1PV/4qY8oJOeJWWr7lSCAX7fiuT//8bm+ gUImVyjpVr5kqLLcEhWPGx8/viM1PiknVUFwbdu00ulCuWyVy042b6167a1nH79vVAPFNNPpXN/g cDqXt5ywcB3dtdq9LKN92haaQsVf3YVkRCobjkEXUPnar0xk+kCGtfqVFgQETAkMe34/+5qUrkAu aNsFWaccDI1MGqSpdN1VmoJVm4IuLtgTJwqCLAuYK9Tx+hkjdBWFgcEB13WP5Tce6TL09/9ddgb7 IXlLNo0tSAWgReX7v/NbpICouqnyQqClPdqHbkWaFx1FVDN6jWCD6iyiAdEnJJvgYAanwn5Orv/J TXv++9k3au8OmQi1h5M9F0xqQyei/y7saCWajq6gaUg/5cXSKTCgs6NPiNFzMEOxa2py+8/29I94 X8RkQQiBJgFZLQROqibhgLc52iMY+1KRuVP1dLjAgqHS1ZshL5ojKgIkZFWQtwhu5031DaP3TulA Jo4PWhedQqNZYWLC0RvnHSiyYJ591jm/e/mNix5f9dDnbsz+/B/cpvYOdcWRjywyjhlfDa1ft3Lp o0/ruum6zkDRUaXEBNMGOHDLiyJCFIsXJNPURTGiG4WB4VzJhPkysJyiIJQ0lU9q8UwuI0uCIuHW goIgKTLfPzA0nLdFafK4WZcvOO297bMmVbr7af4SCNiSQXqwe8uGN4plK5svIx1nmtaEloZxSXVm RyIZ10RBzBfLumn3Zwr7Boptrc1oYc3LohbVRFHaumnzxCmrpx03H/AC1aNo8V0s6blCESGUjTUm BJXlisVN/Wbrh4mdAACsiUcwkXnAZF7Dyrqeyha+AQkObWgfVuVALiwpYUwTGoEHgEngIljCe+F6 ryJFCB2W+DJoOb1L4IkHI/i7mAh/hY0CAthCO3g5YJJh2MiGk1wRV/TzfLlsFIultzW9uEqILquq iiBvR1NzrDzxlY+SoAJWQ8s47tePVYUWkHzswvloUU9W4kgtIu325UWLaPAAqa3aYYl2PpjBRxRy /euGc+hf7d2NKERb0RUxFardDl6O4lDUZEEw4EcXHnwW4cF/3nAJe1PkjGPc5miPYOxLJVGusS+v p3fY1/jHT6JWBTrqtmsvuO9pv6yvWVP3B4BKnx1FEXKKozXOO1CuOvl3D604a87xZ3/g8v9+beWr N9794CcM7YYLth4lUGEWtUa5+Ogjf0wP5x3LURQcnt2dKZUd572NKcd1kVIWgYsAw+K4THbIce2C AQ2LQ0v+TAlIAiybdq6YRXpNQhDE837JBae0dZy56APXj58zgx8p2MGkKgV6luNef/WFt9ZvtyxX FuVCqQQ4vkEVTpjS0NbSoKoyUn+pVNS2nJbG1LROGGtsLRrurr19rmUlIrKmqmtfe9EyjdnzFhG9 axgmMrZyhULJMFkOLdcN6w2L8kwOxkkMRRR4tEh3MEULbQPMVIdWMnjV5MyBml5mPiqRpC4IggbE BJFApV0RVNvDsJlWyPwCcXm9wEMaZyEUyV5xCgxpJ2FlARAYxfdFi+2D8A+ucpFx+wELzRiaXkkR iC+yUMgraN6PVVNOtCy9N5urqrYjFQNo0wEPR7/te774oXu8YoK1O/ev3tN374bt3C+Wsu4aNDJa Y6LPv9Gb+d3qLUhh0cXvaIqAfH4wg48o9PoHS/r+mrsbUU5qxH78qmj24clRHIriCvqHtOdL63as 3d2H4OHSu/7EBjbIGce4zdEewdiXejAoiJ6L/02IqsSAQIZFR3sjenaZom86IEuI5DIQDCC2xb3P vM6aYkdrnHegzOjI/eMVSzlu6e+emylbp19y4ZnJ3K+PyshiqFKwDnX+55d3DfRnXdt1bFuHbqFU sGyrUBAesdzFc8YlFZxkpOdLssQhqOlNG7kydl0l401TZ5yIjCc5EpPUqKRokqTxguBpPjfZOrF5 eudYuUdBxSDt3u445ovPPWsZNjI0bNeNqnJrXJ0zKZmKKx4Zluvnv8bire0xpAZFJZpomTB5b1/Z MBOJCNrESeL+np0dk4/TYg1lXS8US/lS2bZtCmCeW8kN9CzW4e4FNzZkHxTsdsmFUq7LHExnmt9T bplPSWX8lKygMTBXFbmAICwxrLBXYKUKh35Rvu/QCtlaIB2cQZwQqUioBxslrgOJqQIq/Vj+aGGp KGS7TlaH6NlIEc0OwzwByCSVRGQaIttO8kI1yFjJ5/NNzceuwuvDpx6HdM2/Pfoqq6nRW7KJRk3p b5isc+meSN0TjxD6S17c+6kf1Jo4H1kwC1kbP/3TK+jvLafODRdxMyciFfmzh5ezMRVam3mQgyOZ EJFr3UHo+vf0p9EZ0dsfBkpzxJAMWSBX7Ul2fmz5BjYv62DkKA7FTgKa/2vbT7m2MlFitDPW3uaI j2DsS71ieicJTdGngzYhu4F1iFGNP6UtRdYB1EO4osuvFZ/UmrrxxBkkceDqOx6+7uRZuway5C3C resWn3wUx3kny0ewdbL1KA4ohp4XwD35p99t3bTbMi0bAYmet0yTOPSRzbF/KHP/q0WE0nPaBGCZ 5eF8vgzLtpxMtkyZdcYZH7i+cUITa3oAji2n4MZghvQ9NYAL+XkBt/ShX+VyJUkQzLKpiHxEkiY0 a00NUaTsMC8Xj1Qr+r8oSEokmtDiCTnaqCUbE03N5XLZMcsOdCJaJFO2+nr3pFqEvJcXC2kNv09l QutIiGrlgay5E65ud/8sZt90pVi5uVNPr7cFzUodF8QdQGg6QCAajhWhLZhpdxOmjxclDoCVqtyH HtdLLnODPishtxhlLiYV976yDybR9SLqQWQf5xhDAKuK54PIDQjsplFYWyDlwgx9ZV51vagLvONg hklMlIO72Vt6ueS6yuF5Sw5VLj1r9i0bcKbQs3//c7LWIwlR/7FkEfGeow+/sWz12T98AL3YPphB S0UCM2S1eN4dD5Hs1ZSmEi88Dr97eUSsIA311adXkd//xy6cTz+/7doLlnf3fmHp8ic37Tl9Yjsa H2mxBe3NZGF+kIMTR82Zt93zvlmTyW7oLdKb6PqRErz39S3ovOgsaCu5/hHnASlKoqGQyiZnRLrs hX0DSLEeKhIcxaGQ3PrQC+t/8Sg6dnozBnV0CyShuWJ6LzrlgLc54iMY+1K/cc0FD/1LN/t00LAp VWGzuqnGn1PDy4DG8cGgPXXbvKl3v7kNGRk4A3jpILWEnvz0ZWSxcrTG+d+XhpP5OWu43Aqo7+aM HZyxYawukEITiJ7LCY0gNp+LzoaxWYcIKj69CLd7x6ZnnnkBOnzRKOjlctGzUXhPsG5xHAQ1Kzft 7h5sntHIF3MwGtVOPPniMz/0sWRbnKtZijMMWGOyULEw5C/HQXZ43/IXXxR5wTRMXkCq045Fo6lE VJAEDlfrI+uKF0XJQfYKREt2IMqapCg8AJIaESXFMBSEemiclsZUKZ8Hat4Jg8yk+N0vaiRWCtGn kijENS3VMEGMfBmHLNDU6CYcHI6/9MXh1DdZ7i8850Ur9fNXuYI1+PUL/XyHoLiRhUbPycUHRg2s De4zaVxe3SMIQltBRb2X2+bXqnBBe2LiBfN4X4Kn5zvR/O4sHKBsZG7Aixw6uCpABIzAMklmQ5ak klV2bFcUBVIamU5nOyd22EEt6tstP7xxyZSW5PeXv0W89u+d0vGzy8+h8Vik30naK9qKNr3yxasu vetPNEa6/dt/ixa/SJeRRCOEB7+68sIRVeeXF51AUldZTwvSTU985aN3PvIKQjJSyIZsFBJFOKTB EfbsLZvk+tFrmhpExieBmdXe9d9/zeLPPfLi/pGCunQeiOZF43zvwgVVYepDndIjHwpdPzIO0FD3 etSEJGm4Kp/4IG9zxEcwxqWiR7D+nz/2jfufI2EtdOBXTj+BrSKiGh+p9apAF4JzGjknp0NDoadJ IAHtj2wOttrmaI3zDsEV9K+qnwkWr3H9GO3oD5XOBLz2xkb0d9euzffc9fOhoZzlmNlMGmEKXqW6 Ls0mIn8TWsJyLHSSeDQaUyM3ff5LcxbMD7xJEDCeNL8Q/EBNtAKmd29Nzvutrp565FdPProUu+Ow F86Kq2J7U2LGxLaWRk1RJQlnDHACslIkGSFMJNacau1AZoqCtqka0qGWZZtGURBw8i0vx7hYG+Rl 6u/iHFfcOihvHbBntJRmNeEqdR5EVPSliUlPbYlePFdo1HyDAMJ0Oidt/ft9kWsMeSLDXYNNgdSP XxQf7sn+/v3GhBjtq0hoH2leL2Fz8Q7jgxB66BCDNFzv+lld/sf0r+dkI8Qvrv+e7ILfIS0veBab z2nMkxQ637JBU8RTmmRA08pAVQIYGAlXMKYCUNSNfL6EC0I1Bac7QE50nWkzpqGTk2BbXQ6QXfOp HyBV+FdEllWXuhwVwcvYLZvW/fTH/9E/MFzWS8NDA6VS0esta2PXvetHdgVeUEVVQGtUQYhpcUXU Zk6ZP/vk+bS+HNBIe0C/TnKrIKhpy8JqMQCDFOKA7B1wWzdtBF6EB0k8oibjcVkSIlFNisQlJcaL CtKguPYFq1Zg20YZGVV6CVfvOZbrWDzAy2qifgXgijxPoQCfhOcjXVn5rrfUrUNog6pIjcl4e3NT KpVQT+xwukNKBqSUtYjqiHOj3G7SFZjS3KPzFi+f7fzzaVZ7lCR34Ub0HFPyCAI+So6v5sysYtH0 7Rs/sxm71cIsODwY7xM5c5Us+j4IUSwKfFluQC8J/CSJMM0gTABjfXFV6xFa3ilLIpp29AiQaUKA Ef0nl80iREFfj/ovpy51qcvI7q/9+7p+/tOfFUqYSqtYzBWKBb8iwccSHjfaECRcryDwhqljXBGF VLLhoksvC+vWmRwiUOW/hzTxFlT48SvCLZTSBJYLuYHePsvCYBCPqiIPJFFIxGNIwaGVucCLWLk5 pJ0icFzOMtFFlUvFgiBKMUHkeNGyLRfBIXR4kpLrWpwghdUfPChcPEOaN8Fu1mKaEotG4wiuvKQm eU6121RRpGLiDHvNvdy8c5mYD640NKe2DE9tZu+LjdGzFFxc2Ocx7EMMCW2+F6qHrsfCEmaGEebi EIsBYDqZQRoYwrl1OJxCvWseEz5PZjsELJftrQIqK+9HAxiX8kuamLTYL0gVhFw219TUdHT5PetS l7q8q0DlR9/9br5YRIv9UrmIxEcUQL0pPMKQoKeHazmO4DoRVW1uGDdr/swgyA/Z/KbK6nOfJ/4A TjBmFd67d6dtIwNCRjoz1ZBQEKJoEtL+qqJ4fCZejNqzODDdFYIOxymXixwv4ZIUtL6OaMgyMU3d 77WF9oeWXy3CcnFNSCQ1DcGJGlH40VUkj8yaCSfqe09MuGtzwkkB/gkQRzrCLlrQK3SvUtUUJkG4 AYYtWUAQ5oF+UaPf4Z6UwPiBj6CEB8dLXEoaGdQqupDQ6YcWD833CmL4NRLWrFRiTM1umO0Y93MW eMu2JUcAAo+mo1gul0qlaDSq64b6V8VZW5e61OUYgUo6kyuVcvl83jAMGDThoM54pF50U5dEORZJ Ip3XGosrsqRJ8Q9c+VFBFkJGEYZhhQaU2Q62YYuWINmsgucLhuvnwf37kJ2hqrKDSdjtaERGkJZI xDEBPs9D1/HaJOK0Wj7w55h6CelXHEqx7GgMR88My5AkSYvxaCjRtQBDwYwkoigxLRKJqNIBqy7c klJ+S577Ibn/v8twsg0agrbzlO+R9O9l+ThBYFhwNZ2JSUpcBcIGwSfoYweDQ5V9lqtMC3wW3AkY 8jQFOcDzqrJNMCKbZIByEDCFnRUeMGS6SZIsS6WSblmO4tXG8II4PJxGoII2OK4r8Hz9JzSamP/1 D/VJqMv/RVApFXOZXNY0Tc7nSSTRXk9x4wQjPhqJdbR0qqoajaoO73COcNn7r5118tRw2R1W/oUq jUTqmUwDULMupi1ASE056TkFMsP9APuXeDWiNiSTE9qbkvFoXJME4Hg8vA6mqCJndB1elFykWR3b sQu4i2UB60NRFD0iK8G2LbQZQJueD6GIpqqxqKYo0kH5cHhNbF6oFcv9sauscjnsEEBaL5KuKhCE jjFIKVL8xiU0pS0ItPNB1xoQ1DyGY3ptJH1Lxg/VBH40nqMGChfmynFBhxW/d5iXWuy7znhad+LT a9KaFYZ+srbtJ33hul47SJzDzdu2K7sQCPjbUSwUTNw/TdZ1U6gbK3WpS12qQGU4M2xbNue3VeeR HlFEhffUkNdyEahyxHRNx7AtYCCdcvll188/7wTWUwL8frYVfCajV6bAkZxf/rHp/du3rX8LvSyX dTEqyBIf1WRFFuh+uORRcEUAcPsu2zJNA4iKEokj/DD0guPaRqmgRLRINKbwAnRxSYeXRICsGyGi yFoEgaMqHWJGbESVo5pWMgw8WujHAiC4+5BvpaLAno0rQdpYhXLj05KScEZ4GBY7QgJFLk0GDrj0 A8ZiYqpgz5tAW5/5Y3OAY2tcarK6q3xf1eF6prwT964XRcsyHceL/PBo5t1CvtDY1Cgrimk78jFJ L65LXery1yI4AZfoF94Ln0i8hHEFCW6PpSoy0qiabdtIyaC/Zy1cvOiS01nCXr+iIiifHCHBqAJQ IENawlXADwB6YfDuf/ocKAzH1IgoCLgUP6EJIu+6tsd1iPOvTMvq2du7s6t7X1/fwOBQJj1czg+U 8oO2pTuWUS5kSoVMOZ+1TRMhIubbRYrXsVWJT8SiyUQc2SjSoStBQRA0DUGSEjj0sGlSsPPIaiNv bGhB33Ah1l5IZMYWhFTpcNrry28cyZK9BIxhVao/pLznwqZbpKmxX34JqaFTQf41Ip7XPijI7u/h iuiR4aPRbI99ExtGvJjOZEjMhixH6lKXurxj5euPvXGsLRXinkFAIvKiLMm4XyOuSsC1b5IopxKN SNshG8V2nIntUy/9yGUhnHAstnC0PI86eEaQgHsqNGm8Y4je3P36iwO9hdnHN7VHU5u371JlKRaN ioLsOJYJDU6S8vlSqZCzysVcNpPJIuQwRMFtbIhM7OyUVE1U4rwgY55dEfeRtLEhYyAzBynCWETV YtFRS/acNJ4HYSxqdwQpaBDDRMaK7yt6M/P8wub3orvtKe59dPcfPjP78wzlV1C4Q2lnQkZ6xiKA dAJgyG/PkdqW4GOfUxKyzezDMBbvtRnmgvBIyHdDqGB4NhGvkpTFTztmiVtq88Ec6IpoTmXR1HF1 PaZCww09eV03dL0ciWiqqhTLRjRSd4LVpS7vOBkumk0/fpjb3TVU0u+46oxjdl5klKjIQFFEVcaM wlhnyJKiYgMFmSlKRFWRPrQcOxlNXvvpzzW1J31sCKIHgPZpDxQTqIz6cuxCnUaM2YrKAFy2vPps KhrJD+1LNqY4hBIRNRaLCF5w3sH09rptW+RE6Jo7ps7SInG9lJZEF6cUe61dkBZ1cW2mp2+96nJc IamoDW2d6O/o1lqE40dWi+6mW2BuL2g82SPHdDHHouOQu+nUZglAQNfdb3RNTo5rkifQno7A906x MxFME8ekoIGg0wCgrF2Vls0IxJSkbAVSE5HW7ftJCLToJ2wSBvz3mOSYdXHVRrlqHllQLYnb5tiY qRrZfn4qBwSYtBhwhmUrx4plsi51qctBymu7hmZ89z6uD1PSrdrede0ZJzZFj9HiT4hHE6qkolU8 zwuSKKnY5aWpsoLTcyXZss2yqaPl6uUfuv6E04+v0D6BQ4dNZqpIgRpdqjHFe1fOpndvWb6/b5+u cx1TJqNVMFJhuKzexK4to1x0bEtUY/liobe3d3hwEAhSNBYd6B+wLNMFwDQtHESxHRy550CpXM7m C2XL5QShsWWcEjks2nZlNkDGmzaZ80p2bNvWTTOMO3jX3ii3NSsdgGXu99tBhoT+ZG4COAUcZJU+ tft84uJgC2D7owREYKT0kjLwB05F7Lxk0+l8RAsKKitK6kdDlIrHykTyMa5D1zIRsuAkCDIgmvNU QwNOOxYEZKzIdVypS13eSS6v6+9+iGPocH66vf8b5849Ru4vVVGBpzgk3FY+ikCF97wtCFEEL4tU kaOnnXz+mZeczpSCsw1yq+pSgr+QaUzIvAh68vol59CPP+Mjxh8/r+cXwz379VkxW5ZlAdfzO5Zp CZjiEJdp5HLF3P6MEo3NnTcf7yBHXnlhme0As2BzvI7r9UTZth0LAldQRBvGlZgk4uIVQy8d3uyA xCSOm5Q14No+Y0vWNnr1caJ73AQQJEVD5m79JDC2CX2YbFxRVI+Tr9ywkYvfeZ6iMc069qL0BIxc HyIgU19JzUXcvh6XlVCmY550gwy9cKSwv9oNRtLAWJcXrEibIC+Q/Ydj9ciORbDtOuREPAKVfD7f 0NCA9rNcWP8Z16Uu7xCX1wd//exLa94ib1s7uX7C4bm76yfPbfz8BbOPwTV4ZL84QI//QOCU7WLJ KFi2gSvRXQuI3JxZp1z+qQ9xXFiOwtFegUxVRUWT3FBLMRUSNOGYYRUBzFJeUlTThGUbdE6bTsrL 0T9ZlrRYFMFbLKqOG9c2derEVFzr3rHnrfU7H3hoWTZb1i1et6BetjkocLxcNu2+gczenj4B8Kmm lmQyheBnTJbkA8vDz+659ldr/tJnDInKy7v037yQKZl+aWhomFW1FuaCBo0+pBKDwyW1oZCjCQsw MCv4wEvmAgZ4mVRsSKwNQjzJ0Ywzn27fI2yBfm2QF2J3yQuKDUGPSJpLMUpSBSRcm4wP0HUF9AWR sY2CKVtIahrml0yTO4+qSiZfrP+e63LUZVt//r6VO2/+/avgWw+AT/wAacz6nIzt8mr6zm8potx8 Sn7/RV9GuELklgefOTYTKLrQdW0Xh6BhweulIaiyqsoRwRYh50bjqYs+vESUeY62ePJUGcPZ6691 q/m8Kgv1qnAFAI6rpsTi1Gh8xpw5kN9MdK6LK1BcXuQVBHic4phFRY1EpVh6YLMklFOi896zJlqO snvHTrOciSe0tvZxzR0zu/ds27G3p2OcOpjJR4YzaKBmWeTgEYHKx5dMvvKCiTEVT0L+1GjfUObx DeVZzW5nytf9tADeC8i7AY0K8VbBkKO+AnUA3TP4kBgrPEkk9qsiCWa4QcSeBEZcSFMjyGccJj5z BSjQB+SBlwvZBgRVZAcsHT/r++JqUQZzqcmSaPCi7biygylm0IClkq6XS5GIJom87f6v/Yq29Wdf 3dPXV9IfvOH8d+Dv/In1e8mLhVNaGqN1Is4Do8hruwbQA71z8x5ufx9XyWdcn8AxBKHvdb9+1J8x BSy9aNXFrQ+ily8vemDmI9dwBkSb5t21tOvWD77toEIInHElh9c00LItTE8MXQQtWlSbPWP++Gnj mAA7Y6mwhB/A5/jiaJYwDcuP0Iw3qLCvUGloJyHV1to0nFG0iMfpCzHho4xtKOAKoizjVl2d0xQ1 seHN1T37+2DP1o6OzsmTJxZyiVQyNr5zSqp1XD6faR8Pm9rHyxF1a3f/ScmEZRpHCCpICKJwuGZF jWvqeTO5zzw9+F8XJbGpAb1aGKY0kWlAT/xObiUxCpk8l6e19H4YhRaa+DaKT/XsGXSBF5H3u5lB UlHP0Www7AHDGAZA2JiLVEKCypSByjQwFtorexpzlaYn8YDZuo0LIQXBGxVkMzkEKmirpsrIWGmI R99ujbO9P/f4xq4/d/V1D2e4XqYv1uSJYxx1+wvrsZLa3VWxob31ipmT/nXJghmt8bFPehiH/+S5 jbf85bWKK/QOuf09p43hgkBL8gNOwszm5LFxYhxj6L3xyVXde3u5yjZfFTL6I67Llb9+/qEXV/lv WsHWC+6fFvUzidGLm+deesca/C3t3rgVTfUlcye8vaCiSgrSKJhHHQhRNY6wxHAwv5MkSBMnTPvA dVdxlLAQsvXXICRhAVxVP9wK9RTADwwzowI69prWg7Gm9s6ZUPAoQJCaVEQcB47IisPjOAmuoOGc WXOO65w0KZfLI5VqW3puuK+hQUN409nZmUg1FbNDDU1t+3r3NSUTkxqaErG4KsmOpR+1+RKFhmQc XZ3REN9REI9LOI7rVfoHrVlIWzOmvTybuxAyCtMcMVpJD+muPs2kx1zp1zuSvOvgFIGh4/kvOS8+ AzzvF+YkQ8amb+L4lZB8WPkP/GcBQpORSTimN1BrrLiO4OUWG4bp2Db0ylExv2Q+39LWKvC8KomF knHUvcMrdw2s2N3//J7el4ay1Tq9Um46btKIqmrJwy+NemBv/0Po34urzj7lhD/ecGHtKvjwDkfG 08JfPFoNJ8Eht9z72I9e37r2s0tqT3fOnU9Qx8Wooigr/+G6d59O/O6yN5G+q7lZ0NoKz0sav1+P 05bObkrWwWPEnwnJGyZvr5pr3L/wa1X73D7v23d0/4Drxz/tJb98dOjbn3hbbT7Rsm1FVpJaqqWx WYtEkN5xgZ3N5qeMn37jl76oxuSwsXlF7R7kKvo+gbAcL6TtDaP0rE4N9FllhN9TdHNOX7zqmccM cxgvjb2EJhyEhk40lnTMol5Ip/t2Oo6hxBoUBZgGAr8h4Bqtzc2xiJpMNWrxZHtLU96wmxpbNm7Z WtadWDwBoGoaBxGoR7dRLELL4BMNnBBWtDiDxeIf1khTWyKL/eQ3WZKbG5PzJ0sDnDlXNAFm6Mds m47LcbSknaOI4pfi1FgIdIbC6DjgaBdhjvGhEXyiPVpCpkovJAMCJjKfYDJoyEJm3yfOD6rrayyV ygbD3CgeMAdCkcdk+B5vMQ7XI6sF7WpZVrFQSCQS6FEpipTOFVOJIzVW8Jqrq6/W9TGCJLxLzeHb bdLUql/ajQ8uD9dugRD/cn8WkKOIIFXetH3Pys9fedqUpiM8vMIF4V1ha9JTi/0q+UmT1eIHf628 eNMlh4co9CLfTYIXDcEMX9WanxnPLmzavKDhGRwJWHsbunP04sSWhjqEjLDuufMh6vL6yRndN037 aTXqmK03vXEz/fohW/DeldvfVmNXTCUbm5pbBMD1ZnqHdg+bpoEWnq2NLR+8bCFCFF9HhSpxJJ7E Kj8W9ckwmyH1tYQldkErFRhqt+YJnZd+4nPPPXh3eqAXvXdtqOtlBC2YvtC2c5mB9EDPQN9eTpAR Fvbv7YKmcfqpp7S0dKIlfSweV+OJ5pY2p7+Xj8Ques95aC2txaKGXrD10cPIyNzZs8dY/pLx0mrz 5fV8pyCfdrx6xvnK2ReCKM5C5pOqeuZ0aXoLq3UFUTyjkW+QNFGTH91jPvhS1yena2fOjrhu4L+C 1LKDATsaCCCEq3AGBgRoFTMIw/xgL/TCh9YPAWkXMhySbsA1hsCN5yHH1g4RVhh6luAFBGCs7sK1 WxBikep6BCqW5WJ+T7SXIKbTGQQqOCQmiRnjKPRZqVXl7LqVaJzp8V7iLz5n2b8uz+EVwOmTWyvW bt/5bWgrJMDX5wxcO+kv1CFAfmn3d3/k8xs7/R9bNrfwB/cO/eizaAV32IcvvemKEFFawdKFvlMb yf0ct6M4f+Zz15D9EX48sf5E6oUIEUUBN88N/T/oTsNTcNy7FVGwBAvt/Rd9uWpLv+GvqS+dXXd/ 1bhY732MurxWnv0MgWFWECTfsT6BAyqBA3bpRxe/7e4vUZZ2dW0vFHDPXcnjOtciWmfbtDMuPoug CPRVF2DwhGABJZeqKNumzFNUPVX46ZlKPjZqX8mli6tTOF6wHawjEX7oeqmY6S+V8pZl5weGcEmK A+PxVDwGkskmRZGLxXxxaK8c0RRNa4xHnn/5xc4p08d3dEiCI2B2zFHJdGGxoD//LMwPxz97g/ij 6RhIjB3WxuGhT97ceNe/86kUkAT5hOo+K2j9/5Gp2qMbcl/YA9e6/AdPmfS7nYOgV1g0Dsc23CDD GAbENKQ43jfpAE2bY1lR/LiTZ1bwkJIgBxEajnfCHvaEEAyyZl4QQMHsZCRcz8RWvMuAgIWValwB I/otOZre5z1tXMmEu9o4DvqyiLg9JOBKpTLhlyQNbzL5UkNcO+yv42u7hlizAEFIk2wsbN59asOy RnkEh9LynEhucOGUlhEQRQFfP3nga7N/WHsgGg2t6W6a5v3qPHczAoOmHz889PcfOuzDl/zbfWO4 IBAmDVy8t+WpWwlIfHfZm+S3zdooK99XoRfu3PF3FFFuv+5971ZE2dafp5qxdusLWb9krymq1oGE lSHG4YxWMFWI8lT/lUuWneqZ1JCYubdfufjYROPEXV07cEAFd01By1D0T25JtF3x0b+RNTEIh7Dx ed+5VUkmFYaFw6zh2ubnB+x1DIh2BA5CFEw2ZSPAQ0rStu1CPptLD2Qzw4VCuVSyeE5IJuMcdPoH h/f37dy1cy3SpqqiJre3xZItWjyViilbNr1ZLmXGdUxKpprj8qhqDsRisY9/Ar3oyuzk7L6JIMal N4tzTgdaXH/qKe3qq0c7MCYJV5yQOG3YTsXFlAK+F1O36MZ5kuFgjQs9hxj0tT+pxqEs9LCi5jHs kMIFMXiONRdIcMQN0NdHpIAqErLRLC/XyxVIdjKEPmGxN6WAY0JacMynU9GXkwuK9wHxrREyfF03 HNtBXxrcghM6mUymtRUbChFZKpSPKLIyVNQpotQuWkeQfv8HQ3zEFYhSGa4cTW6f9+0m+UvffLWZ rJebbrvHjxUfxuHBldciCoWi++ZvufapmdhYWb+V4y5Bi02KKD85r6cKUT7/QgdFlMNTBwikjxkU Hfa5tvf7xtmixAhUcn6ZBcf9r2MqAr+xczoOOAljb31i/d7HN2KLDWeFeEIihchEm96aqD31N983 /1uvrCPf9iUrT3Uu881iZBOftfxqb9583XDFOafefeWiEeMoh3rSgwIVvMLkMd8Xh3N4kFqQ58ya c9KiuSyjB8MtxcbrAbvIDdvoBtqL4U3kQhcaYIMytb4oHPTGjdldVxAxxxSnSBy0AHQEOVrWnbJu y7La0tRKaEn2D+lPPrMyXXIntEWOm9Q4MDiUHDfLhvtVLZUr7B0YHIjEklI0IUh4jWO7lshLo01E ROD2ZXdMbJjGjbsUXVf0mvfrL7wW+bAFpJEPQTciCvzUFoXcSavGd0Q1LSqXyyW8ksdreRJl8ZkZ vUng2SAKCEmHmZaQlPDLp9evytoK2e1DJKZFjt4+2AUGAucYqQMKUrwB46EEI5F91T4PyhiKgzcI sXDFisTppmO7UPaukRey2WxTc7PA8xFZLOnmUUkDQzbKAfdZnVnsvxrXRv47766lFFEGLv7RiMZN rSBb5K6e7/vKK0CUwzzcy+Bkr/A3uxd+ffZ/0qGu7vjltdz3iWXDui8QorDe8MNGFKS2Ht/QhVMb 9vahqeicPfPWk2duHcxSD1JVZjOC4SfW97y6p+/NgQwJbFwxsa1NU//m1JkHVOLoXCt29T20aU/t uc6Y1HbJ3I4qLYb014rd/UMlvG6Y2Zy8ZG4n0VnoQ7LD/GSpNh5A40lsatyI49cKvbu+ko4DdcHd oXk4GBcQuWA6mTe99+xaBi0yCS919eHxd3dxyQT8988c0uNYuWsAZ77V5imgr4HnFbzzSe9NMnHF SbOqsg2XfnSxbx/3Q2Q0o2/aNzf+rW86U0kmzp7YVvssDvukBwYVTCUp4GoVtAjFVMSO09SS8v1X TDf1wAsCg6ZSoT4ETH5T0CCd5bsFFSjkB/XhCHZK8EJWVdfBhJAeD67LuegqsQ6U5agkum0trbGY FoslkRVQyGYz2bQAnM1dZdMcRoNbe5XjpnXA4T60ki6V7VKpiOyGeNM4dIOPrP/ZlSfeMtpEtMSn on+hA//cc92Cbm/aDDSNM8vCjFm16OIHwb2baVOgDbkVWeG8tpReKpSR2nVs4HgNM3FXMQiDipKQ n4VhI4Bhehihu+eCBiwAAjbk4oZexsBYIcncNL+LdFjxg/UQMF24wpIZEIRJAKjglKw1YiDT9oZU 6yuSYEgSjqs4HmmLwJuWUSoW4/E4uk9ZFPUj6GBPFk0Ha9aYfuSW5AXdt3Kn/yNRsJFxkJBA5Nfz Vi/pXkCDN4d9+FVzDda4uey19yCwOaP5MoQl4d4JP85/VBAFLZ+fWN8dKrVKQRNyC6M4fE0xeSL8 2tVouv7xpRFyrh7ydcpLSKHcftk57NkP/lx3kufi5cUNFY2vLl390Mo3qzIvbvGuZOX1izcOZnyo aN5fNeaqzLn+K8PAl0RvhBl/RGhBgP2j17eOfncYpW46/7RvXXoKe3gVilQdi5BsBBSpXpyq2Po8 pMdxkJLNPfTiKhxxnDxx62cuRVoeR+l/G5q2d6xP3LH+1jB8whyIvmm3/OW1oX/6KLpZ9BBn/vzx sXMpxzjpQYGKr55cDCcRRWtvHCcIcqVygcx6OlxQe1qQD2LHXJAhW9m2g2cq7ujymIMVPIthQMHf MdHQuNc2bdvAitWxoYKZLtGKWFWjgBN6+/smgIZEPKpI4qTJEyK9ktM7xAtuSeclNTqxs6O9rW14 uB+d2Hag6bhKLBlLYu/Eh+bedPBPECGYdvllzp6dxqo3hOZWvjULmpu5UZAQ/Z0Vl9cNWoLCRxQ5 EWkslsrpbA6jomeyuC7TT7GiEjSsjCfbIO2MEgY0AOMiI0YM76ELbVkPOJpx7GES9lT5ycc8COCg guuLeb5VGWnVlMWALhb8y8f1KrKIo/WWg6xJL9YiZjIZBCo4XK+ICE7zhXI8Fnm73RFL980iL0he 0HUPPE3e3nfellq31VP9V35n03z04t9Oer42nokj6gnigD6iwz8wYQ/9cEdxPjFfXh0cd3UHs3el g7AKUdCJKKJccc6pYyAKTpOr0dQHJekM+OqvR056HkUZ4Vy4Qz8Xzotbv5VAwmjx+YU/uJe+S8nV RSorBycfcPyq/AWsan/56Fj1LgxK3fn8a/fecBkyeipSM0aR65567bq7HzrAsF7W+OF8mxVw1Qz9 +Hh+YfNu9vaHTOX3/XFqB5NJ296fwzjNprQkwM0zciSHhR77l4HU8u0CvTB0j/d+4JyK7MRDPOlB g4pX8Chguha+UCrm1fz+wd2//NkPjjtu+vyF52jR5tC+gGH4hAmxBE1yuZGoiSETiqlMHAMsyRRW TCHNiRqN27ZplgsAt56M8EhxYR4yXlEkQ9f7s+6e3t5zJaG1tdFxLFFVx49vyxfM5paWhubWhqbm WEzN5UVFETmBl7V4Q4sfZhf4QyY9FCZN1SZNPZg9ZzZJGuCaEpLk5QREtYiqyMPZfKFY9PzE0HFd LoyQhykPQUdHf2OYiEwyvHxLAle14+xqDlYV+IR5EjAss8fOQ17w7RI/D9nDBPwRD2qXDDXWIk2L puQ85OkTkjFJQk8D2GgZ4uDKVNy7vliyLBs3S0CbOFA2rTh3OKDSV/JjKv2GjMx59JfEadH32/nk WHlBaHlI9EhrJ1dhFtSs/Rd2Lx64al2tIXLVRP3365UjPPyi1kfDVXb6ZP+7Ec9WqrNwLXnzKXkW UVZnFi95+lTyVNEyfGyOgBG0fAIsarXnJ0t3bEv4Sc+erkEWwNZc46Z8nBR84ImiOvfglBGXzh7w XIumO9R/FV4Ao78WddrhDt0JPx7GDEuT5RhjVGHvAqFO2kwgkGbHR7BEcaWiBnCku9ueb395sOX3 21T/KRgGwgk01SMgCr1Bmj2Vzoy2D/oq+nN7GI8jAX5y8gipwN6EeNYqzTZ8tZNcCTZQggtG31hk KNdOHTr2a2hls2D+x1df6T/N3v4QFA/9pDQX5sCgQnzlyAKIKonxje2Ga27f1qVp6osvvGbfec/Z Z51+7oUXNLW1t7ajJYMAoVMupyORFId7ruDvfibblx3qk2S5tX2K6IUufA0WeMy8Gj3IQyGMTIdL dcCiD9VoES2GdrPNElJY0JVwXxQdKDJvI/CTxIntqXyJK5TkS865ACnuob6BgcF0z95+0zBNV3/z zTcFWUbKr6m5MRKPR6LxxpYjzZ9zB/v5VBNbvEJFdzg1+LijUWIVtSAILY0NcS3SP5zWdSMwOmB1 916WcRhSUi8YEFbSKXIDpU9sGjccx08Vo7EVHmGPELa9Dxgmw7p6vrpOhUkUA5WGCgU8sgn3eeY4 GecM+uF6UZAgLmThcrlsU1MTbkwgC7rhFkt6VDvkdB3i+Ebi/d4UNvpdKzQvaHprAi9OA09U1W7I YqCQQHT6Hds/VpvT1aqY6IxHdLiismCDdJ9/eYFGq4gDeb6y2+d9m9208LHF5AeM1FxVIcuIa22i rG+ei/UUwjN69jvWfL82de1bG79UNaUHr4woMIx4LgQnv1rwIGve3T4Pn47mLyDsZANLZIcHej5J chZCr2BtlN6Ql15WfZHI7KsYH+HKTx7c+o/XzvyPPxyMqr1pGnf/Qu/w11vIbIcVQq3g5s7ckvFb 2GxDPJledMFHYm8SqvYZ9/T3x56i0R4H+g7cOf+OA/paSbbh51/4PkV6cq7RshOpoIfy4rlvXKN+ i8W8wzlpkAtzUKAiCbIaiTREG5PRmOmYA+mhxmRqf3/flPET0drz9VWbX12x9riZM+IJSVFwZHZo MG9bxtTpk8698D1IEz339NPpwfyevXs7O5pPOHEO0vs8WiNDrn18R0tru6RITz/+58zw8Gmnn7Xw 7EtCTko2DYmusgMFKkdiAPAeQ7GN9J9gKZIAbCDhgnHHjcejE8bHE41tW9ftbx/fFmlqO65z6swT 0Q9MKBTyd/z4IV61Zk1tjWhaqrlFiyWa28P0dqeQddYuk896/yHoOcfWn1uqLDxbmDStakvOgNuy 5ZNbcWrZ3h1r88P7bHTBuK+7IsoqbnwsyghoI6JsWXlXiOFgB+RozJxJnWO4jGFgr3hYgDOEMeIK wI/2A0xgQwgofSBwYRh1ARSXXNfheTGIcQXj+lCPTCC+urSeq9ipogUkk71MaGP86noT9xj2M/14 PpvNNjY1onOpsqgbVtmwDgNURpMZijNGXhBOHwoC7LV65Lb1l9OIJdkNrcRr07OQIrijNXEkh/9+ ROeAUnFJv9m9kP6w2SQxFlG49tYfLTntgDFkXw22QhaZCAqik1ZlJ4er/iNQRiOeq8p9x+YvDJm4 SKL2SmjOwtYzQuBpTY6QNTJaHh0Zv0kJLMhsbubX76Eoe8C7I4cvGc/MOXFFzq5evD/Vf2WwfjRG mwQP/PxfzyE9jjESBcdKSwke4mgTO0Lsff4dv++6lVhLh3nSIBfmoEAF6b8JLR2aGhnODyNE6Wzp KJiFYqmslywegNZEC0Kandu6OiZO4F1DVSNRLWYJ6msrNrz80utTJk0UgeTabkJIrF2zdWBvMRVP 2I4jSMJ6ZTvEwX/RsKz0cHaFteKUM84TJS1Y+oZ9dGnMOWSWjMRFSUE6EbeGMnVe5splXhCiPFLY uLOvZlu6rQ8NWgW9nGsebMpLvCSrODfMcs96z6Khvh5VEdVoFC2rp89eUOHOiiXByYdIOyiI2lU3 4LqZGinZ7tSkgi67VEj37HizWDL1chl6DiIEJ7iXppdTh5SuJIHWGadxQGayGqgXEDJ9gmFI+xwk DwfEL36ho4e/xOQhjYRBYOgwPJTYT4UMFuh1r/fo6/3EYqaL2EgVjjUfVXZABqTSEooCH/Sut23H FQUB8Lyum+VSGT0dnPshCLbDoTXBofZZuWJi20pNff/ENuLU+u6yN8kqcqy8oPbWe1b7wc+vTxuo HRP7OrwbuPfqi4j5v80YwehMybkjPBxX2jOCFrN3rFnAFjP6fiEOjoUo3jp04b/8sjZOXhmf911q tWlyaat5RHXz+/74kSijEc+FsOemaaNmXSPr5PrJJ41xLqTZv/n6D8iNH0y+X5UgANiaD+uEDvXu 0G4r38ct/MN76CesTUndZcEDThL7YOTr7IeH+jjeyGobzvtxrVm8vTidvG6SM+xRNC1ljNtEXySy W9XaCNkcPzm5GwOwAjac96PDOOkhceSIihwpGcXBXL9l2u0N7TwHSsVyUktmcrlUDC8eZKC0p9qz /blUsgEBjG3YvAA628bv6+3bvGnntI7JxXIZ6aqOpo4tO7edMHM25wDBcGAR5zzljGIkokT4yPBg 4Xtfv23SpPETJk1avWJVOp3p7Gi/4XNfjMUbq2L75eJwet96r3hbc6CN84t4aBoG1CJo9S0riuBF X0q5LFJl+XTfcKZvUtvEpiaVk3k+Itn7h2W8QHfQ4r65rXPK8SdV3TCvHTjW5A73IX0tNLeHylUY QTm2R33lUsyl85lMoagbehkt5EVRGMqXWpoaY7EGSVYQuCiqghCFJmeHUFoRuaf5dpCjHinaJJjm bGPjw+WCVsXkeiFkixepyeF6kRhCis/TyBVlrfT3BgEHfk2RPTV8AK21DAYOwvXINMWggkfj+eF0 BoEKdmAqYqEM0YQ0Nhxab7SqKAJFizHygjobGx5at4W8vnbSX2oD7ERndc6e2Thm57uVg5OP8HCk fNHvk3qB0A/b+WTFbxt7PHKwaqmI0HHhS4tHS9p5aNOeEf1gNC21Sa6OgU/V1o3o2ejvB5zCHaYy GuVcB/SfNMoH0O9oaU8szkMdnOLWHWv+/jAW7xRXbj5lIc3BPbVhWfU85wNlWtYPxoY4+MeB1klV n4eFtKG8Z9F05yMd+6/p/B1NSyG5JFW3ia6BpBoG03qqc9k/sDu8t/1lZBxeNUM/vJMeEkeOaDj6 YN+ApkYjomYgswDAslFub2jpzw3FnSjS6JKEg/hRTSvrBm5i70DifUlFG8olYziTlRW5f3iwKZlC 8LFp55a5U2cj1WOUDaSkDMMoFEpNTSlTN20LrFixXlizKaqq5bLz1obdd/34e1/46jclJYLjOo65 ZsVzT/75scmNdse4cSLuQqm5VpnnbQHa3kK4HI8mSroBeC9KbMFCNlMqlSE3tHvnDkVVtXhqwow5 ermErk9EqlyInLPkGnCggkunvwfwHN/cUWmdSF4brYMVBCqmUULIp+s6upXtXdm/rE+fP98+46QU EJAVpShaEoYxdcbPxPBNBsYJYBxiIWMBB1mjBGd/QY/HMiz+YVOVOT+ojuYtwAwvBgMd7EkDHEsg TVp1VcVUODagwlbve5flUYFhY0VHj8dyMPEn/krwxXzBsixJkhRcsII24D7Ewuh0BgcfYpke6xot L2hyROkmvq8EqM3aor8KYv2MIUOmcoSHY//Jtktvn/fGaKoHO/FbOXapiBDFr7H38nC8uA5ew9I4 OTLUbv59Q215BC1VY/N2qCofJQYD77t46+Epo9HOdeSClvZ3dMdHHBxNzh3bP3ZXTzPZrSoqQ2+W 9qFaetGqkXlKSFJAJXEOlc/PePyONVcTTKod3zfvGPcXMkCrrZlC6GA/+MdRu04i11C1vEDfhOXb Oz6v3Mol/Z92bS5JtaXrWU4P9HyS3c37bl/NZice0kkPiSNHHM4OCbxom5aoSMl4olAqjGts5wVB ESWMA1h/QxEI3mIY2LaNlqVezThEuiIVb9ANLKqkmKaliGrPQE9zQ3NbQ7MAeNzVHICyYQxlhiOK KgHBNhwENoVcEekjl+c2be36wbduy+ez6HTxeHz71j1nnjiuq3tPe0uLLIuKGrUNZEva6J8k4HC9 Cw30uSAK0OFiDa2RaAoMDhZKJb1cRDDSEG0yTMgLaPlsSryy+Iq/VSLRmvymakm/8Qq/9H9SP/wD kMN1KJ9sPIipg5xbRoYPXsQU0mhOcDYU5CQJTamBrj4e1US8nkcqVpVU/0rA/2fvPcDjuM5z4XOm z+xsxS56JQGwN5ESJVGkumVJkavc7cR24hbp2vkTP3mS63uda8ex49w4jnylOE6zf8ddLrJkyZas QnWRFEUJLCJBgOjAYrF9dnr7z5nZHSwKweYn93n04wgCgcX08r3n/cr71fmZgmJRsCD/yq3Tfg6U 9D2hez9SDubDL9U8ZDeoL8Uy/EE+mY84QaFQDXm8/meQqPNwzau1wXnK5DMUtypGXUtXg3VSCjRF oduh4emCzfgtvBxHkiqJRBzi2ntSc1xZ1iKXoNqCZSVrM8rl84IAaKqpd+xptJaN9Po/1L8V10XP d1J8/qv7S6JJ34e6b156tDgovX8dekXrayoDRLl7p7TYEb9rXijsvqcOLiqn8GycdrbJdbDxxzJ3 +MkCfvrZpRijs+3LFyv04y4IsZYmzqEFNu3/M9/oL7tAcIWXbry+jg8Bz70Tn122ItWHJTS5XgoY 7zvgx4Rc/9Rue2jX4HuHFk0d8K+N+FIjzrTcba1N+Wrur97Q0KJlgoyMC7odS11t6Bm4Z3uVH/tJ bvN5vege1c57aS4JQrVFXlawXH72sh+e5057GyMXACoEJHhWiIvJEC+40LahZbsWC2g0tzUsncId hR3LsXFKLyRcB6q4JhF6lRfYHomCMJ2bFYUQhVXhcarp0PhwTIhSBJrLEq6Nveq6ZhAAMQeSgbRq W8jwVfQK4hvI/h07PmTZpqKqyBYjo1woh5tw43MSr41rU2hEhjjGQcYZWS1VkcQwIj0SoiU0Q0fi TaFYo6FrJMPzQpgPR2S1kp2VXMhc/46P8ZGYaVoE2ueKZKXh5jszv/xP6b7/Hvn0VwF5QQEA6CMK Dq5Uiuh6OA42wo4JZuaUSl6iyTUEolsMS9MIcwUbwnkBG9eZ30jw+TxfqVNqCSRWwHwqcK1S0let rJPEr3mwCAD9uLaNbhzOyyagW09OoDuvphz0xXHnYW4+aF/DFRB0gA6qYF2S9EBFN9CNYxgSb4Yk i8VCPBHzw/U69pZaFw0ouEud7yhfLi8omEIeqDmClsZdwELlqIePV+mOTwjOZ5z/6liH2Fch+9lN 796898M9R5F9OVS8dkhq/tJwO35LG5dDlBI48M7Hl4JQVSjsJ5/1eystIytby/9ZdiJcn9rkDXyt Hrnj4o3R2fb1thf/JCBV/zS89r3tYOkCAQ1adoHqFV5u44ixLYpb/HDiPcsmBaDx7V2LEeW+4f+2 NM13WSrZyLqZlYMlLBvklS2lswEuXuDtSJ/tqfPRESe5ec/JgiL55VJREFQvvbDniPNf0E7x889e AKggYxwV4yxDO8AuKerk7DiadDcnmhEqKIZB4LJDEjucXIA1Thxc+2Z5BX3oOzJG6EeO4U6MHN++ Zit6p1iaKUql6eJMR7zddnHJNbJIhmlifmM6JEkT0ESfO/5/2BuDCzikcplmmLAoOpbR1Ma6ronL HRFbYgVFpkplCQKS5zGSaTLpOLZX1cfIsgIJRKgYBGwcbublmlpFVtUrbnhrKNFg2WgCbdM22ukC 94ttGurQMXFDtYYAUbHYH38OzIyc80odmX65I9ad4BPD+dNxviEpVLNWHNcZz582bcOT+8KmV1JN EroNMYHw9AoQW4G4nrSmnLYAUXwD7lTLRGuyKEGysP/h4hmUX2syXyZZrWYB81KRdWzFnQ+F1HSL 62pdFpbQB11V5uHNDRxrC3KMvb4tBO7chZ4HE7E0h6ZJhCoIY3RN4zgenTpBQtslVVXnefYiQOXA yNwKeUE4QuAd0ls6m+7zqpQXl4MsHFf0NHz2kYNn82Cgt+gSV5+XFvfyoX9ybBfiV3V2a7HuC5q/ o1UW6X0tcpsgi++/2H//ymA9qASym8tOrhdMz+sO4BKN0bL7CgQ9z5a/cM4FvOwGd+WNd2zs92vj fzzZctfaZSMzy3g+0cJVH+affuCl0cwXf/5bfy5yz3k/gfOGmGP9+c3Kqe0XcDs8z+otjecVl0Jk AtFfn1Pe3VEGFzUO5NZf9E4xoXnq+Bd+b8d57ovgWB6rVNm2Zqi54pznwvEFPAjFkJGt1G3DRsbe NDVkLkxd0VTTMg0bN4hEC1dUFeEKsipZKY94Ckvh6zuZntRNHRlUZLwoT6xS1TTH63WIW7t7ioe4 ht+0NU3HwpE0jQ7BS1HVHVd0AKHrOk0igoIAgVQ1N19UZUVBa1YqBVwVWcmrlYKuKQBhHUkUCpm5 uamJ0cGxsTGWDz3228dlqWiYWOkFHeHi9/8rn+aYBQ83u/lK9ub3rUxT0MFnlTwywbqloy+nVsmI Pv/hwL+fUE8hDufHLZBJrsgm+nskHPb0kXHKGoBV5YIaWBDzri+vjgTCmqBxnXsrEFoLetLDIJIP 5ksdq0XvcEHTZqL6O/R7vcyH2d1aTSQ4aw7Yolh9wFPqfHfVnmCU5wHDRUWWU3W2QaJUrFpnjqY8 /+dFqraskOBU5eYAp/k+GMRdwukVtoYM8bPHBs/mo3gsc8clrr7SmbBYlrweUZChQfN3ZKEWqbN4 vUPmR4BeE4p2/lcmmJ7fue/yoFviJRojcK6sp4tfoOyCc7GEj9Q6sC0PSzqz7NlVKRTL3rq5rb4z wtnG0rnCfMIVz63k+ZwA53k77nrzXgSQVYfescg52cOChAKPUy4fiTmP4UPsxe0Uk61XTl0AU5H1 Ck3RFWTzsWmwoOczQShiOaSiKSzFIcPhAg7ghB/aK6jGbbyQubSxVXGQ0TcMS2BDmUKmp7mHxqnA REWujGfG+trXOYaJ7CDPcpZjFSvlSEj0Y8v1c2Nkl9GEV0UTWk0rlM39rxRuva61olghjkPWk+dD qlyWFYQ+ZiyCe6wgCAOOzPEq8CRDGDbkQApBSFl1Uy3tPWs6pVPFH37737ft3L5tx2Vt7WsRMtXH ihs+/ddELHX+F8ifqaPjp0kqysW8JvJEmA37f3py+DetXFPc6Zdc03GrUYu3Xb+N4TmG4TCCelIF DiTnnV2grjFwEE5Z1Md3/tcao6nWl/i6ab5mCgHrBL2CdmjzcRiATrvKnvwql9q2HVjX4973ny3q PVA992q/46B1SxCqr7YwRqeG7h0isujJcR0KQxlBliQp1ZhCWMoyFEIUxyUqFVU8D9WWRc10g1j0 Ug4xXz2ADO5U+nzuI+YZ3mRzT6+91EfxT8NrP7fhyKWs7v/wvU/cmZM1rLEY1NMtSUmqTV3B1zfO y0AFJZaf7ttxTmnkF8dmzz257u68/8PX4wpzT+XpEo3RxXlUFi2wNDNqhS3UV0j0p6IrWe0M98ju xf3NcHVIbfVzwrDPepcGS+YTroKayiWez/kdncftwIkDGan/L3zpGhfxgLs37142AWFZzLv38K6l zknEkucV0s4WOTYiVYi9qJ1e6DNDKUrF8RwyyEBEIwlZU7CcCQSWjYsQSnIxHm7IFNPJSEq3NIQ3 FKSQ8WFIxsHqkxbpNbONCLGJuVHDMkmIeYllmbP5TCKSjAlxwzTKihSLRXUD63khG+S4NrShYzk1 K4sn1Wg127ZomrzjmvBsAZES3kSwRlG2ZSFAoEls3SRJQ5/ohk2RsCjLXgtfxGrKBMkUKm57W1sy mTJ1Kx4Tx6fmTh47PfDKsQ995IM9vRvrQeWCEAWNkfwwujKapbWGW+fkuRAT4ije3+BI/kyYjazj up+1X/N7P/qtF1taQizPg2ouL7bUuOPwfMpAfRdIv4m9TwUI7BlzF4Q3MKEL4vO1cEtQz+J3Iq52 vanVqYD6fOEqn3JckvR4TzVpeV4qpk6erU77JWjmNS9/WSfrUg0N+StjMXzaC9dbDsNgbmqatiTJ 0WgEd1ejCIT3Y2PTmzatXfk6IypQrxhYP1aqHqiTeEIfLqX2QXJRYOWXggeyC+iVG2q/pNX9SfEH dmNRHwQq50QU9Kf6qPX3x6rVEkNy7zlBZWCueM7JtV9YEKTPXaoxWnkif5YF6tOiwHKZUcECK2/8 g48ePNv0Atv0zDJOp4KZDHI9Tmekzzw34P+2FFyx3fdY7zkv+7KrBxUe53M7sB9p/7F6tn3v4fC9 h//MV7hBqy8qEzmfUTDbbnvoQuz+72Kn5wAVhCimZXsmwylViiTO+2LwxJygEGPRHM3kDVmRRSHs pWAhYNEQu0AUQaDDXjTAxm2hvCo/VVcwPHgGF/GOqexEcm2DA8iIKFYqMoXVByFAtMEiaIKxPIF4 AjMemwA4MxVZK8RUnnultOfy5skM4VoGsmc0y+N2LyZh4Ui4Y1u6YhCGS7heEpPlAgNZcmi1JKLN qThDk4l4Y0GR0Bqe2CXx0IMPdne/evU1+1rbus/CRCzfN3W2sSbRi64GOjaaoE1Eklw3HO+pGBXT tgRauKJjT3r0pO35DxGHgr4jq2qZPZbguEFX+XnR/5qaZp0KC1HFlTryAlxnPrUYzJMM161rPICR yF+xGj/HdT1gvt89JjgIU3C+BcRaOe5CTa+FKsULNCXr9cVggDp1KWDAExkj/d712NVI0biICJJk oVBAoIItJ0MblkuQF+DsWjpWqh4414eLplrL5gh94/Ttl746Gnddj8vg69s4nhVRlvjfX5fC9fHS wKYvMkn+CJrvrjC5PmdhwYUao5Um8mdZoD4tauUFVtp4oKcbgUuj9MHFX+q6AezNfppD/198M9jC 0vSzr53ae7ZgiYdh4Xo35uXxVxa7B+skL895O/Kycd9TVYC8e6cUqIrhFF4Qrj1pN/l/XZQQ6D8M wSMRDISF37jumgVKQnUH/O4+bUqjgpnBxe0Uh7UuRB3DK/rwqALLcDwtxEIRnucRPzBwCi8244qu kCSVLWSRPaEpFv2qGZqsyYalIUSxHERoNJJAZILULd12LER0/Na25UpprjxHUYTX+4smPNcVsjkM rnwhadzapJrMigwTx3LINJ8ez6CDzxb1giTP5sqGrhMEgdY2bYQfOIkZGS2acBCNsi20K/TlUK7T GqZaGyPIigkcWy4XCax95Rqa4ZguCemZ6cwv7v/p/T/6Tja7nJ/ELJwbeNEheI1YaCylyCAgjLAR RFmawy3odJRK0Taxu9BGVAXrqgBPlth2/b71yJYbahSU6qw0BPWiNAviFwDMq6LULwYXBDiqP9S6 qsCgCp+AVXCa725TVZL0E4wxSjlBF3t36QzPrS+LqXZCduG8RFldOwSMSn7VpReuJxGoYPjCORSE oiqahv2TDM4BhI0tLdPT6fN06aDXGz3c9V9LeTp624O/vnuzXnODhJfNaUHLBJDwwFX/uHSq6wfD L3F1RFM+c93md33nqYDTLCqbWJSMtMgPEyRBLWtzr+9qXrDXmp1dIRNpUWHBWYzR5NmCQOiqovNd tPzZ9nXRCwT5XedcFyP0zb9dSrawiaxnrvXe1EWJbSx85NpDS2/fMkKQtYEwrAo23gUZfPsyTdvm xW/O43Z84v7nfSeqL/tmf/DPv3/LIH6AG+E5rZD/MCzC6eA4B9/7I/SgoqP1v9DPaMto+z/c/fkg L+6id4pGENY6L6YS4mhkGng2xLMCMkCGbaiyiowiSzNY6gNXkioIbyRZkpSyyEcQX1ENFU2QFUMW 2DAyMLZruZ4vSzP0EBvyDBmaGNuaYc7m0k2xRtO1GAZnjim6xlEMWthv4sI4rOnqFp5KOwzN0KaB AEp3aNetWLbw2IsnbtyxpjlGexJYrmYAwxPat7zkL6yNCwFPwkiYT6WaWju6xHBobuZMNBojIYM4 SrlUjifinoaYQ9JQKkmP/PIXIZETI+Hrrr+N5WrZiswy3jAXG0QIufMCZyU309fRPT2dGVWzmFzY XkdhDMgmuorAseXcnGhXYEPUBYu6CYCasn3grVogKAnmHV9BaWOQ6FurTpknGCCQdgGuO5895pev oIvgp4rNR1Y8SuPO96/3/GD15AQAAAJatKTsv3rAaHWaotGswTRt9MX6uXaQLBXLXDP2AbI0gZ6n kbG51tbm83HpLKsDuPQtCn4OdBIzE9jKLEUg9CJ9um9HnJ5a1omMy0G8i3WJqyOa8utjE4FELrLX 9WdRr3O8wkDzyvpffU0XbJI2ddZROilA36WjXmQTeLI3fkxlsfx+7TK+uXkHmuwHgIqg7qrkjD+d Rwa3f+i957Ovi17AD7wv+6cvbf5FI1s9sE+1Z+/u/X+XXv8vnPi4P+l+LptamhXmTbq9ykcN1zAt 27Pgmuffu/IdOWf70eDSnfN2oBtXfTxYeN+Oe/3P/QS8H9YcccvqGtTBp4u++2UlS6cI92w/smxi G/rTuze//SenuYveKfZAXtF7AaCCDLXI0bKuoEk4ml6aluHbIxNPMXH+q2Mj8kHYjo2YB5qnswyv m7ppmQpQBCbs9e4gDEtHJsowdWS0vQQv6E3Y7WK5MFuYTYgJNNlHOEQZWBEZGziCdHC+rWVBxD3w 9BbtArEZVdcGhirdrdF4jJTkyhOvjV7e29QZRdNdoJvAxDJThD8Bp0nAMkQ8Em5qao0lElhy0tUr FjlX1AiOdYBTKFaaWppcby6NiA6NY+WkbZOa5hwdOLxmbT8viCzLEUtdM46j/fYRem0vtXHbSlfO LnqWOAZNlZXSW9ubWhINr0/OSAaia45HU/B3dLJyWSpoJTbaZVLRRaQkKEx069Wb631lVd2VoFM8 DLxRQXVKnTiL4wb5XNXU5WoVS42rEH5j4/l2nLA+JQEE9fn1H8LFHrAAFL2/4Bom16uux4l8DIt5 KiIrZUlKNqbQbeVoytYKG2KIqWxZ4XKu4NJZedRPFZGVWSr2t4K7/H0Hvljvkb/41ZsbGwTufJpu 4XQsz8ovmol/fePgBzLr/mzdswuSEcrVDLf6fiFB892VRTb91hd7EajUco0u0hh5E/mV9wXOlRa1 8gLLbnyFAwuualBIgQ7yS5uXSXAIKvvOdvuCI1zQO+RCRpDafs7bAb/4o4BCLTtBWSGwcdeRu2ta /bjD47JP6QrjmuRcIxu96J3u3bnlgjo/EqqBZ/4iR+qabBi6HwjAsQAHl6H4vyG0oCkG8YiKJkEv 4ccFjmmaqqFUPfi43oPAgASrKra+Aq5pWensjGX7woeQYRhk6SwsH4KWJxmK4RgO+gXjBMFzyP5Q M9nSYwdnp9fetrmv1TCNQ8OZJ14vl3QcZ7YcVzUd03ZpCKIC2ZqMtDU3p5LxsMhzNCjLxulJLyMa wmy2UClXEF/ADQodl8Si/QTW5sXlmXSpXDl18sSJ468dP3ZkanJUU+WFl4Sge9fZuTlXUVa6cmQM kIgJQUWRTxx99bnHfvHbh38s2HKCMKFXCFkrxrGVilysKFYpDc/SvTdgJXCxN8zvVkPUKW+CoFV9 DYz83OHqknVakbXmA5AI/FWuX7fiVn8GAaOpucPmZV7gosY4Vc0yd7EgP7quL2nml0lqEpFRdPFx p06vexsinYqMLyxhS6J8IgYnBw+/sNL1PLtL5zynisAraD//jMn6CMclrc6yd/Z3+WUQ4FxtHB95 x97qYY8v4MFo8mh/8M/r3/DbDlxeXeuOffVLBs0xlxZ7zmci1TKJP7i7NwjPLspXPk9jdO59+fP0 c6VFrbDAslWrK4+lzO8jL7/rgraw9O7/aPIPL/QwcH1SraRx5duBVaVrT/iFqpwtOlT0lKLTP/8j RPcdXauL3ynLPvDhGy9oXTS9tBXdsiyHoyHPklWhdNzoya41rMWZYFiS1rY1XbVsHUdNcAGErRmK jZuVe4KFHjWxMK4Q/n8AZ+I6klLOS3mGppF59bEH5yTbWMoX4Ki+1/WcomnC/cNdCHRoZI7HpouR ow9u62/qbokTJOGa7pmMe3RWL+sOA0GCAy0xpq0x3pRqjsfDPE8nk9Ez6dnXRjVLBQLPIiKVzxeR 6SsVy5qKKBSsVavgugqcX+ypHaPpNEnSqqqm09Nzc2nTNBx8LtgmUus3s3tugMKK+iJ+VxPHzhdy M9npV44deu3VVx594Lv5mTPtIUbAGosYmTGZcU1LN2xNgWblbE3h3YXoskzEpSas4mfL1TdorgVg XDDf7R5Wwcb71a9Z8QpWgBvUQwI3CKrUQjPQDSItC+ItQQ+2OjEAaJLUUUjuV439iIwBcn8kmkHH iCMr/hFQVLFQBKYEMgeAWQambM0eP3uUvhZgOA8/7+LJ4EJt4N2/uvmcwIDetH1Pfzl4UT//jptx yfTFrg5amgKv119dlT1bG8e73rz30zdsnO90VHZXsGL1HGhRLX3Qx2yFTKQgrJoIMbha5RKM0Tn3 dekLXJC9W3Rg6Pr4/z4/ROKLdn5baHnsq/O3L1qNNn3gxXXz0tdLBnoqlqJyffrcyrfjK08PzBPi F5Pk/X+HtrZyOrKPc2jJ+UOtPaXo9NETuPLq6K9oF6mffNbncxe900fuuvP8O6lU3V+cpzWrmljP iyKhwGDu4lSD+CQyEtgIoT8xhFfjZiEgYWlcgYFMlGEZjmvBalKsl0dEeMFibzieKdcNE2ckRxsw fhCkYxneujaB6yJp22vICIH9riu4CYNlMXIpPE2lM+WbdjfFQtrPn82LOBGZzWr6RNkt6W4vy3fE 4qnGRj4kMgwZT3GxpH3iTDEcC3EiAi9Xy6uKqkYbomrFMNSirhrhqIiOTQyHXEwgfMuKqRLhYxxB GYZZKBQoLB5AiWKExEIAK8kgYhKDVuS4g6OPHOWPlkh7tmwXJTdbVCFxEG29bc0mgU2Cahwbg49p IrZVlxu2sMlyvVPMrevN7C7EnfkFarXx1c+Jatil5hLzO2+5sNYPEgu3eOAP3dqKfsnLfEO1askK rEdNTJIWNPAKctFclzbtom4+qpkTFBElySKkXozEdlbKTV7fSQLLelp5kB12DQQtGgKZro6zygcF Lp09kQuXdSnXhDR8TRcvE/+vLtu+rBe+qj8R9PKrNYHvT0WrTfEucHVksgNEuXunVN/GY1EbR18U Er2fQX34B/av6/29xUJh9Wpa6KQOfGxxWeX5iGzWy19+6117sIqzl3uNjNGPJ7+8qKHWUmP0jdO3 15/jyvu66AWCzChk774w/Hd/tXbuA12Pr3Bgvr7kF46nAil+v5VZ598/4F9PdNH2l766Qkxu2bvf 1xi97R++7z9IqUc/O3jD4mg8uiD/4xh2AwYpG/PPbV2CwMq3A939bzzZ9Zn7f1t9Sst+Xu97QeP7 7u4oI1hd1NAX94VEXLZcEzVn2e99+A50qLj7srcFBKI44uWt7vfEDA5pUIrON9asn8Ze1E5v3XzB TQ7h1//hnn++9x8zuZzjgQrlJQTjvCqcxYNVN1xcnOil9VqOaZkh3NErJmuKoiu4tCUUZWjWsq2K VjF0PR6Nq7qGFvO+LC9oA3me725d25poQbYbbQN9VzQFeAq6yAAhZDId3cXt5LEXrFwpN4hkPJm8 bteaCDU+VwYPv1iqyJrl9dJFtoqkAMeyESG8sat57066vavtxHDphaMSQ4m8wNy+b/uxkcwjjz23 rmstxbKFxt5QOUMrOS7EbblsQ3NzE6JFQohDIxKOsRxL04gmsYgikV64hiEI2nEZQUQHDc5j0nxm /Pmf/+Kf8ycK48eO5XOyodsM4abi1NbLtq/ZcnWisYWLJ5SZcUOrJLrXimuuApBcWBRSlfmCZ3eL LeA21aJ9nyRVaQdaBkEx6VVTutX/qylfvgxojVQ5noS/x9SwrIGnbUD4fZyJKrWpluHX6+pXw/Sw VlMTtBe2if3Z4t/YrhKiewVuA7o5onBtNtsBnCiaHXCk081NEnbZtQxXrwAqAsXUmRy3dtMy7af+ 6ldHAvfRRY7uznuu2bqgPfjC/rW+o2yB6zwaOfDpdwXhim88eeJCV7/njn3zZuLsY1Ebx4MjOdwu JQjOb9bf2jbmN8r95VTXfKfbGuAtfmM/dc859/i9T9zpV8zM77FmjAJGeC5j9H9pNMJ3N2K15uDY /ANbfPFZ9p533exfnLxsLO4wX2vgWA9g9drP/hbQHNy3mPNZ4P7Mpr4v8u/iggS3Ax3qJ+5/fpk+ 0Od6tgc/ebsf1UCcvv+fH55Psz7nYNm7rr8CsdtL2emFDmrPjW/auO2ye77yv15+5bCJBVcQhOAZ PCI8FtbcpXVdd2xc6IBYgGEalmkZtolBBnMRLDpJU4xnlghP5svwM5TRdxrhkKdnjPhNqVJojCYp inBNZNYc3dSwRCTFQJKkcOtb2rBwBERgBZbRJdMNmUCxwPFBq7+NeOue8CMvwZKiEzgBmkQIh1bs ao7t2CJs29H5s0eHj48gGgASIiSBGU+2SQPD6CDRQoqsnehed6rpjua54c0//SaCHMdyWtqaLJZB iFeNTXiuOuyIM03u2Am4dbPLMFYuCxWNaEoR0djZoMWxLaWYloam3BHDVAErhEVdJ8NMPmeksxY8 /Fo+k+vdtKVn6xW4ot5xCFZwvbr6WutLn1a4S9xcdb2E3SUo4xdIVl1RrufUAhVVLeXTra09gb5x NS8LuC+fGjPV0tXbt/nJXrbrkAEJqRXUz1fUB11V5hvbw0UOOqcGNZr13HjxT9C/JKJAgOHYTTQV cR3Z0kUHqgxLt7AS4VSAYwFLhVQUCqKrTJml5T2KJ7LFS3xv7+xs8k3MvJXXXT8Tf/nl912OpvD1 vP5CV//orv7b7vvphSIK8GTEEFoEAOYJhfUvdoXWmbwFc+1AZHPFgaa0i/Y4+IWPLjBGGffeTPje Zc7ODYzRnbu3Luj3/l8zMu5PMriT9L0gvMIl/fd3XRPYO3QTc597PzbWwdH6Z3f2UvBFdx/doH33 zde3LrzvvwOIDW4H2uP9H74+/6499zx1HAufnAsbEKn91psvr38M0Fm7n38vngA9fnABji4dzY2f v3rbZ67f5J/mpez0gpnKoYGT/kz2sV/+7Lvf+ddsvuh69AKjAZZsAV5zP4dDUENSiqohtBAEgaM5 WZcRG2EYNhqKoSsvaxXN0HiOJ3AamImhxwtTE1i7lhBDoTXNfQ3xBkPHgpIzuTSO25OMXySDiA6C GdVQwkJEUiSETKmG+PVXrz84MLq2yTw2VNizvXFi1hqclBVND3HCDbu6OM7Yt6vpwf3p4RkXKxlT fEsyFUmQb7nlxl/+5plDr5zYunGjbbkkAkUbZIGojQxcvaknRjtZJrx2Q1/XmvaW1jaW41hPZJ9l WHHgGGxMub1rvKALhY1voYjBpiGxtDu9Xs6VRo6fPPFqOTPOAzQXR6flSBWlUCiWyuorrw0barGr I5poaNh89d7uDTsMTeWSTULr5qUur/MZ7iLqUo2r+719cUpFaeaEopst3dsdt6rhYhqSZrs/fmFC J/hPXbfGK5jB/i8/oIS9lNX6JFz6E1AUgggiN/NkBUIdkmngtLkuBaHtQk3Wf1bWfj4jD6u2kOSK aBsN/OVRfjPH9J6c1RVj+tbud/BmybV0YCiAYAHN4TYBrq1atNC/TEAVq4mMz17Ke4toSjBv/fzD h3GJ2bLGNxq5c9u6L9+262xTsOrqL75WX6u/dHX0I+5fG4+CFfPOEdQtajsWjO8fOPPBHz22zF5Y du/m/gc+fOOyjmzMOf7z3JQO2Z1lP78gYzSUkc5nX5c+0Iz4eweHzm3vznXvfn1s6hO/OeS7wi5i C/jiPPTMMnekuRFwl9QY+2y3wz/ml0YzOUUbmCv6CZB3eRUht2/s3N2TWjmYgVjLwZG5F8dmMRHx Xh9/3au6mm7d3L7Cupey0/MDlddeD+bIhbnMd7917/5nnlI1w7czFhYCc00LS98jpoJ+0Axd4JAZ FhD/0A0NUYdIKIoMlaqrmqkh64zAB62EaycdB0tCAb+lOZ2Mp/ra+tE823HtXLlYqpQ4mqUpGuKY LqUZqqxLiCGxJJsr5eKJ+I1XbhxPF06PznSn4Ja1TqFM9XXxA0MgFaM6W4mXXiucSTuahdZnkpFk QyxuOeaGTS1b+rofePTlweGxdWvWoK0B3BbeUSqVt48dBe2N7fks6YD7ey9Tw/wNb7p+/fp+QRSf yIVubDDajp6wr7uK5PmqBiQOtVAIUV1VRSiKDnGB6Rk/mR4cGB05Pjt8UspMsEKE5sRQpCEshhFO 8aHYqaNjTz/zZCjCbtiybu3Wy5o6eqhYiop1LfVuLf6kTl0FnG2y5KUO+4TDT+nKZsZn0+OkrW7Y ccOLh1/eubELUQRFNfMl44DZ/NbeBIHsu1v1jnkeMF+WjESsxEuY8IU+wRIHmK9z+UPdPEpS/Wiu oJtPolUse8BF8w3XNB0KHa7pELNaan0UEc03vTgzMJPVP772DxqFNq8SlMKUSklDLoqlyEhuWFnf u2n7f4GpQvb3pZHZoEMietOu6EmdP51ftDp633obIxfnDVhhIGipF/I6pzn4nYyLNkb/BQPZu9OZ UnDZL+LeoWnBr49NorPzLWaH1526QeBu39RZn5m9wn1HB4BWR6tc2d34OzGy/38bHqjUhJ78/wcO vvSv9/3j6MS4JxmJm/f501yeoWwXSIqGoADBitfYESeihL3uKaqpmBbu+odwwvIaVqGNmaaBW3rg mT8lCHxncw8CAFy6oalnpobi4QRJUo7totXRtLuil2zbjocaJrPj8URiW19nc1PjA799JhVJzRWz DXFyZ384EeVyBWlw0iyWGZ4Vo+FoVBT9eTuiPTu2dUZE8cn9x2aymbVdPVj/GLcjhv1q8d0z01/p XY/O4m3jR1vniv+6YVtiXV8ilVi3vq9jw+bO9BRL0eaWTTSFm4B57Vz8fAOy5i1aYP91RTrxzK+S 1Fet7NADv2qvqK6iyqyQiDW0QZLhxWg82QhN55mnDyUauLWbelt61jW0tvOt610ytAhOlmEtgSxX ED9fGl/xAKKiKCGe9xeYSZ+ZmzjT0NZdyM11trfLmramo0dTitOz2S1br5qcnvPiKrhyhqgmwHlA ghMrcGRF0hwD0o18jab44vhE2XZzsvr7Duig6W0lbYQGzyuWItIR1SpSBGA9YjOlhKal5K6msYy2 4dQMMzVuvad38+6eWwEVcrWsVkxjQQIxCQgGHcCx2fiWa9+5+uKtjtXxRh3kxz/13xYEjgFsau+4 /pbbaceamhjTDYPwcpYIr2aFpUgLx1FshkbTXcrGVSEOWo8kcWtIn5R46cgOVvrCcXjsnamJ9eI0 sbjYYFs2+iAv5dGSFCS9uhb8V8tGEGQwNIP7tdhWNBpZ19vzzIFDNEO3xFoKZWM8bY3PELmiEOFa GxtSsUgUuLAiKypu4EETJNHZGpMU49TpCTlq5/tsQnV5B31OXp0flx3tcKjBNO0BJp60lbeNp0/G ojOyPjUxmxs5vfnhJ5R9V1DxmOf/8fTLPLvqzifmLoxE0Wyqo98tcwL5m7KmHjtpUjivTSrlZ0qF udzsZD6bYSKRHZfvnJ4pEsBhEQ4zAgUtigsh2woXAkjt/yBfuL4QxOudUsv3XaSNj+iIY0gizz70 3MGR8dmWVGIiW5ksWc0NqUzJbIjHbF177slfX37VvqIk17RZvHRjTE+qecf+Dw/sP/mxI8YAjIQB jLCUQCLseaSiftS0jtNkTLcGLBtYzmu6rSBewpJJCIWyoVIE3uqc3iYZRH+YGVa2jMwV52ZAR9Ky QpmMPTyrnbClDDA4kgk76pyj5kgtK665bvXFWx2r4w0LKp/41N1VO+X5QPw8VsQ3Nu/ave/aG0qZ qdnZWcIXgPJsEbK3utd0C6GK4yUY4VkvRWFdSN9PDyBL466/futav5WH1ykLd5dnWU7kRMR+KkrF MDSWwTEYhCEMxaBJtG7pyMJxHF8oFziG6+1KjU/npmdneEFoS7QkwvFoOBwJi7SXpVtSpGKpJKuy hrZDMyQL1/W0zeSyQ4NTVC9ttVvCGYK08FR8Wqq8FooqDmXoBjqI/bJpNybeazhj5Uracq4+dXCK 1B8uaIhXRaIRnhe806iFGpbrOKIWM1ODhweHJh74Ue7Aq+Z4Wh9JW7NFoNvQsQ3gaJalW6bDiWLP hg0lSQ+FOJJGx8iSlkrwYYB1oAP8qMOXKjtZXHgYlMyDWpUjPgZNVQ1nPFe59+cHT55J33HV2rYo 2bV2w+kzZ7auSRLhNQ8fGenvTG5rVsfHJymxJahpxHJkPnYSIDjFXx4cORVuN+YqvzLhj45LHGN2 MR+pmKbrSoYTA0SnaQ/Jluy48aJByJYWZngXKCUTTR2cabWjqUJvot/2lDwzPiK7DHRaC5P6xKQ2 EtKLqUoSOKZWHFZLw0Z5jGforNsbSaRW373VsTreqEzl7ppirlfaPq9RCEJi5Kob3rRl46ap4dMV WfJNGol1vXAOK8ey6AfH826hqT2u8sP/kriFLsX4P2PVdwe3iYR+vSF2UtExMYqr9C3rzbBjxpUA muR7ypUA66notmvFxcRMLp2IJ+Miw7LC8PhERZUEgYtwIto0QeJtlmVZVTREaXRTVwxZt42O9oau 1qYjx0YLBakZJmNjfG6mSGEhSzAsKWQoivDNtoGqavlyoSw2vAbcfkMVpdxJJvxKpA2RqkIhPzE+ ls1kIpGIEBJ9fuaCxbiCtTKnR9D+pXzRVPI9HS1b1vWs72lLRCK6AYZnrYmSE+EtioQmonXAXbdl c3dPL8PyFjpu0wDAokINtWYqcP5rQXH8fDFKoGHv1otLQijlZ3TTefbw1E/nmGHJPjiU/tibr/jl EwenJrLl0Vd/crxyRiE+sm9DNN6o6ZpNxRZ52ryMbgJUmQq8//DMGUDdMJ29nhv71I6frA9/R3OG OFK0nLztzpEwYrmUYeccYBa0BkliKraW5G3VdismN6uldtJ75si5QX001Wi3t0CW5NFVWq+39Fsd E+KQIs8qEwOaNIVDZpCezDGt63atvnurY3W8MUHlY398t6/iVE1MgvMV3b6KYaq1/YZb74gLfHpi xDQM3x1kmDbL0h6oYB899BKHvObyBMuwNI5kkH5UwkQzdtevsCaxECQBKZIRWMG1wWRl9t12/2t0 3q01WzdxU3NLFKKyUkHIlExG4uHw7Fy5XCkruopm+hzN4R6Uuq7hzo64UoPEfRWx6n5zKt7X2cy8 Uk6TpiAKiEJpmu6pBQNFVUOhiKwi6DERFklqOR6O5w3zFdkYdqmcS87kZkU+pFY0TVHz+dzE+Hix kEXoGI5EkO21p8tEhKujDnBu/GS5lM1NDCnlLILTilSybCvWkOhd33/ZlvUJMXbwdD4eckIhERd0 QDIcS4iRKMIYpSIxoQiNQKUWEQe1Do/z+vN+Lm8NUWDgFlsoUM/xIdN2itGuR47PMfpk35W3Tp+Z ebUQ+tWM85XfvwmaTAYm4lBvb24om7zj1m3MWx1Hi3yFHJxRDb7/9LFiU1d3rvCe67JrW34C4BAB GRfIIeZKimjkqM5E+GYGRmVjRHe4l14OJ6Ku5sIYp3Bgy5kyWC9sf0Z5tuKYiAgZOI9A227F10Lu UGR4jsgNW0RsVEZzAZaLISanK2rz9retvnurY3W8cZlKIJYe1HDXpQBhA0SRvRu37rvhFqeSm0lP 4Tm4Xa3ddrBwPeFlpnrd2HE2l0th5RUWi0h6PROxQIuXzIqWxMX5JBUVkXEBJ+dGD7pTaCWEMQh7 PF8aWtpiSNz5qVgueNJe3Ph4CR2UJEuuY4tcBO0IN7IlcEidY7gQLyai8ZZkU09nSuS4Gx8Rn28u UjRtWXZFlmkK12/iTC6SUxQZMR5ZVxDShIUw4iElWfJU6h20cYZibQuxLohrM1X19Okz+5959sUX n6eg2zRqMuua6yMrfKRBykxNnX5ZLk2bakmV84V8VjVhSZLz2azAk12tybJGMoTOh0TM0UgyHE8g eClL5Vh7L0LVOt9WQFFArVAEBL1WqhkU7nzHyJoHDExnpX95ITMwXZqUDVLWzlScA0NzfZzTt7Vn VxJs64te3kImku2yrNhVhQS8ibig97dmO5uklgQQKK2kcf62v3Z4DtGZm1X97e9MO3YOoPtCkDx1 OSAiNAFCwm6aakmErxWYTaSrW05uNM0k4wZHJrZFPvtC+uUiMT5pKbZLWPgL9EJhO6Cf4sbTBmQI J1vimzRNcAjXKNta0SikW675zOq7tzpWxxsUVD5597wULqypRs2zFhiYMZYXtl113brevuLshKYr ZVmLhATELEhMULDdRBzFlynE5Yk0lm70uwV7PaxwubynROkiNEAURmBCJUVSNJkiSYQiuPrQMizc 9h7rI0dDsZncdCIW371z49HXR0iAs8s0Q2cZDlEKXFxCk7zAhsQQzzFCiEN76+mKI8Cay+ROMTLO BkaYIUnQqyTnGNYCrqYjSCnLeiUsRARe0A0EH4aHZFjczCUTbCgKbW06kznw6pGp6WxUjNIkOTud pmxQpPRYPIagzr9qOFDf2U8RdrkwOXTqhK6pHAIQtVTMz07NTDhG9vc/8ftbtq95+sAYAexQiLdM A7puCJEV1422ratqRNahFKwl3/kOsMViwNU2KfNV7ggpP/3NR4b45tMmGRt+VZVlvaEb6LLOEe+J 5ZJNScOwU/GIg1vPWN6W8YZbQzNd5AMUHAGOgmNXtMKSTlkT0Wa/9ezI2li4N0rccAVpWAXJOGHY QLe1ivG67ZSK6oCmDzkuDHF9Eb6vu7G9gU9mc/pVqU+6ZGSgfEghJNuFpgs1i3BL1O+J4cdI9JRw aBYhWYwsU7ZG6tMmhaio7Bwcsi0+3tF72errtzpWxxuSqdwVeFfm/WDVMHLQL33emZ9q67jmTW9p jodnJkY1TfNL5xCccCzH0IyLa66xXj7u0I4TVv1kMNzkESezEoTnGYMOcENsSDf0slJCgMTRHM9w hol7fCEjSBAwEW7ISXmOFnq6GvNlaS5fQFTGwAEJV+SijAcqaIc4OZaEeNsQrO1ODI3nHkufRijB swxFEZqqoT3ivwKoGoaDW1tm0WEkow2ICkmKbFkmSVKISGnimmO7P9iWOTI4dLxUkbqauuJiNJMt zGbyR18ffHV6MD09aemV9Ru3BhfOcazx11+anRwaGRoamVSmZjWKcMOiGYswt94c6u1LSsWhREOv ruOqEgSyOKUNwEhjMxdrrVNAWdheuOaegvNYU5cHVhPeKkraD378y0fTqnX8OHXyJSI9dttbL/un Pc/e2GmUQ51fH6T2hEPdjeRxozFCWn4li58R0MGepLTTkFQBGQEgBJBth6/ntTUJvvJXt4f/9Frt 1quEECkkxF2uE5pTnlWtSsmkJNPUbMUBtGZOO47K0C0kwTcn1+/oeEsqtksjHAVqkpHRbEszYTlP wmGj1FmaVliRtfIaO6FwDknYInFohB0pkrJMHM6Tl11xQ+faVVBZHavjDQkqf1wVLg2aRgWS6tVk pJpnrIo1HvB09G24cs++ycEBFxfD2zzHIabi+b4IBBVoMyxNI1YBHYQrFFYvdiyvFSImMehXBv2R pEVBnMmlXbww63d+RATIdm20JZ4VEE7lpfyajs5YhD89PI3wQzM0BAkhNiyKIs3gCI2q6Dij2DDi EX7Hzu7Dr41USjruOcYLaHKvqipiPsBLhtZ0jaLdYrnIs2GiY2+mYYvNRqClWrpsu1b69+5qKoyX jzySjDf0dnUfvP59oWhDNzSb4lHEmSYmp0YmJkql8pqu5qaWai8eRMBOHnpsbnpsdiqN4A6BqKwB RbU/+UdcVtvi8l16RYmHpHSBp1gOsSV0PcRELNzUTfOxRQoocCHABJEVoo4x1vKKMbAwNDVw7MTJ F47IfZcxLhkjlb+8Nb+h5XRPIh22ud9a2/56X8Ozo8Y41cgbSoytCk+idZu4oxR1EkT24eIU/TjQ TxvaoKiNNJh/T4dV4JjAHgVOFhaORkMbCsrUpCpbDp2WEmUzVNRNy6ko5hEaRiiqIeqmwrCLIGmH FcNCcwPXyUGYL2fnXjea+9y8ylLQVSSmnCdo2RV1h+WdSpmMNxAnT5iNydB1fV0N665bff1Wx+p4 Y8ZUYF1DD1hLQfIj5wu9M7UWt97HvBjefe1NxZmh2dksTWJZX2Q30eeIUti4ToVkWQ43VnFx1Ydp G15kBdAMDRF7cC2aYRoisXy5aJom4jcczSPSoCIT79gCJ1x1+Z6bb77xuReeTSVirS2JI8cGSYLS TB3xGEjBTRs2bLt8R8+aXobkZ6ZnEeFobYk0NiYnhsdu31U4PsaFeMFxCUVGeKPRWLLMLKslnA7N t4HkVq25fzbZLXduMjZfJ229KZvs6T/6hPrqLxqjTaZhlCQpnlNObth7om/rxskBQaBbmloqRaVY kGxb2XvtDdVLQpC27UqFLMvFC/n89suuGjgxIuvOZZs5jd26dsu1FTvO6a8dPa5yvEhSLBMSo8lk vH0jIOh58fqzCd3XBbTggsb11T9lpsZeeHkQMmFm6tQ7r46+Y+9Y2RDKWsgmIv/xFLisv+n4eGlb WBEZQmTJYEIQoXOsewZYwwAMAPCSrQ88/Uj0/v98+co1J6nYBARD0MoBeAi6ebuEK1ZHtWHEMQTa oAgH3UfDArpFaNapFLUlJne5lulC54x+pqxlaFJsEPvXxjZ0peY4DgE7dndyohXmneIoFGnHzgNQ tMnBSk53NxNwY29zfPPvrb5+q2N1vPEGVW0wCKoNaqtNnGqpplXHfi07awHAAMhwwp0f+9Op6T+f zRRl1aHQxJWjddOoVCRN11laFYQIxLLrLk/zBhoAu7A4jrMsWzVVWddaki1nJkc8rWI9LIYRg0GQ 80cf/Uhbm/D8wVfedPNN01OjG8hWIcQjUoJYjmZZFUU68uqrE2OTfIhdt3HNH33mA2rZzUy9OjmV zpeVSSlB4Io8ZNMAwzCaLvsNLNFk3QpvMbmGaPaZ2MhodNBQmZAbSaKTkkaOzOkyz/KmoTY3N4dD IklIHS98r8IkVQtBAkMQRHdHeyFXHBlcoE3Ut2Mf+npt/0NoWi4X8gyJkNP93k/1tb3PzIwejzDG zDShK6xWZiKN7WI8TjKIkoURLi57J2BdXxNPiGUx0Lh1CBSLCUpDIzRNCKmxWWOs1Pb+B5m9jfDP bsi5XTcePXb8pk6ScjVDDhPR5mTYiAomNPJEcaY49ChNVmwsuOmSJGTNk1f0WqYKmPIMFGYBcwIH wUjSBO5TP6Hl3QInYhqGoIWndQISiko5Oi9MhXR6jmHltJMZKP8GQoahGkhLaxRkUZhCaBJhC3Oy gGYQrzyrNTZYPd3q8aeY1tnKoTzIT9mvEkV57CcfXvf+tu37Vt/A1bE63migEuSxejnEbs2o1Vmy uomz31ejvrRbEOPX3HjTw794yMI9uACiCIZul92yYVmKrgpcCFETAhACKxrIkikS4iWIOiAzbeha RaukYqlMbk43VAQ2pEu2Jjs+9Ifvf+X1F7717adbYs2W62ZL2fU9zQ3xyBlpCvEhgyDQjiRNChth hmKGjk+MDk81d0au29X/4oFT2bL+6qkISeKGvhQNLMvwum7hHiKU2Fzpv5F75ZssSTeRZYYhByeG 3OlTuEehrhiWEeHFeCRBQdJxLAhJlgE8kXVIwjSw1gvNELFkJJWKL72CmeEjRn5QYGJ9rezpGXVo Qj8+koHkXHuSb02FWD6s6zpBujRNRhONAseWZavW92RB8XztuvqV73BZ1KnBP4gINCEVrL5+w7Fl GjLk7Ke3AcsGcaZEDxx8tDXykSt3TajU2rbWDn5YDGkARoCTtaXvvvi4wwjRGz54FaRLANJ7u3Km 2jP46BMtbjnS7pC8Axkc8zr4pPn4U7O3bGq/OnFn2I1BSYauorM2T8UspWzJpZI8ZcSbD9unRyoH LCfi6k4jDBPNIY7aHkskXKCIEeP0yYEErLSvx5L7Xbry7LAjE6Si2FKrOLdRPPTgD1ZBZXWsjjci U6k3W57fvlon4fqqUzBoKugGfaMW1Eu4W3df9/RjjxqmaTuubVshgeMqQlEqkgSpGSrP4yYtiAcY tq4ZmoqwBeEKRSPeohkK+i0RS05nJnBjq+aOP/38n/zbd/7Pgw88hkhJiaq0NrWMpydKshKNCI6N mBBFU5RPa8qyJPIiASlLA9mpvLPLvfam2147OmW7JpaRxM244Lv3le/fTxoO7g1jbbzFoeYIvUxF GmYtVjIozZiAXqKzpJY7m7obIo2mZaHjQ6fN8jSA6LBxzxEEtDjp2IIkA12amJkea2ldoAsJHFtX VZoLd/d0AnjmdNqyFUhThGW5xYqdYCAtCpFUwnbMts4+VuAVTbNsO+h75V9EYl5VvprMXbsL8/0Z F6CL7aAromZn6WJ20oECT3z/GJsKue/f6dANiTW9Zski+pixVmuEJ3LAjruUBc0MGV0TE8fartgM G/cBK48vE99OmUPhTuGxH7DNXWZzT7zlqrcUiirXp37sk11b1R1ktgfygi2ddO0RPhxCLFAQ2lxa 5M1TZ4ixE+UDRQOoFdnJUdH16qjazBIGkF+3nXw+baQPFhKb6Fi0IOWEkwWhYpUrFSuxrunE+7do 4ZbEs8dWa1VWx+p4I4IKrPWJCpRvCViFk4UzZljffbAuohxNNF25d89vf/0MMsDYV8KyYSFUKBdk VcHheo73yuyxBiWrcbgll2khUME5V5palosN0Vh6bnL92k1/9sXPfPvfv7n/8QN+zYpqKQh+Opu7 bIt56+23fOhDf1wqlUZGzhw9PkBBel1P/9XXX2MCWZYlylRUJe+GFI7jLRyhcW3gIrSUy4ZhiRa0 QTSp3HB77EdfpHETF0q3gGxCgqAUDeccI1pj2UamkA7xIgQ2RYb6TJ4QmUlgkCRwa2yCgDAzm/+n b9zz13/7D/VX8PI7/qhj4+7OLVdOPvGtXz/wAxfMTWRxT12adLFmM8M1NLeQiGMZarShiSA5nuUk RQa13r8EqAI54X0HAXGcj6nUOp3UwMZfl2pba7qcYJpZRwzRxZu6qLIOVcNpZdR3xNuH59zHXzmz ixi97Y/CQMsAhnGpDHROcjEtlRxywZjLlIEtQ33Ycbc2doRZu6QNc+7uDxvdnxBI0FWcAl/5QAW8 wN14M92zDXIxSF0FNAXRN6eUd/UpSIdfFR6XZFfVyeIMsaYLFmxoKgWE+EAtQFOYenQmtpZL9mgV m6M5J5uxNrczezZSX+tOZghnTBob2hr5/Or7tzpWxxsPVIJWUEFVCnSXa0yzuA+uC6rZYfi3K667 /bmnXtAM1wCWY9vRSJgrclJFklRa1NSoiCvsQmxI5XRVV3RTR2jBsaxXKaLTJLm+d/NnPvepf/za 3595fSpEh4yQ0dvT39rY6qh255q2vW++bPzES9/+/uOqZgm5yT8Q3XWh0P6cfM8/vwxUfNS7trdd eeX2SLQ73NAxmGEIQk2Ss5AED7wcxSJXjju77Wa1MCcAi480EqQDXTkGzArEOQXQU720XZslsUi+ aVvowxFaoaAFbK/a3PaAloSuTVIUmU4XJ8dOt3f1BRcm1tyBvixdZo3sZdu22+5rIaE0W9AdXLTu 8LyQbEwZtk1hPQCs3Y2YnKKpWLomoHuB1uP81YaLUATUydHjJDqKFudGc2t3aVqSluSiLPQm1V+c jvMsvZ4wprLK9g0tZ9q4AwPh2/RjgG+FJnCoacDLCG7Hj2fWNf/SDZEuyBhz4lf/tkzZkWarGN22 x9pwfTEzwpAs+b1/BM/NIcQzX/wpfc2TzNbLEFBDBhDRmGvobvlEuTt7UmQsl1YkoiEKTNYynJhq FNFcgNaoyd+M8lEq1ocLcljCtkvER/fI1+7KC+LVrTPKm1Q5xMQGneJsaaYp2rL6Eq6O1fEGdH8F JSnIZJEE9iCRQCOgQTloeqvgnoGAcPGsGllexoGs7ZKuy3liHyoFSsmGcqqBnJ7FYRVVV3lWSETi qqqWKxJDM4IgUgRDumRECFdUCZEVxFZIElfgV+Ryieav3nPN93/wg+eePRATEzzDW5Y9kRmFrLmp d/3azR0P/OLXImHKhcrW7VsaiU2P7X/0pzlpbETWuYjIiSQBmxoTDS1rXhhhxxLXTao5iqZmGXut cZwgci7CC57WExuaHv9h+h2fjj3/G2v4kA0cxTBwZhqAlo21AbzqGNMiacuxVENDJ8ooLsPQXotl jCUQEDZuEONwIvvygQP1oOIPeea0rinxiNDcEDVtgxXCqglpPtLVvwZxIcSkulq7/SUFnuMYFuFK PWYEhfXzEALAUnVk9FdemRIrI1NWGW9mdIjCpIzOFEJFpdgRssayVKOonSra7+QrwtrktTepoJJ3 4X4ADNeBirI5nXVeetHs6k1zXRFAcKZhME5FVyqHC2b/zGiyUH751/+5Zf32xM+fSxGQcvA9tw7l rZNPYkjjXRij3BICCfv0F2jLZU1E+FQ3vgZNJvoQGFuaRar29JMFxwKtVzJtTQoNbWUA7iXSHZt1 BEskOLh3LfUf48pntM0pOnGmPLYKKqtjdbzRQCVu3U8gi09oNDhD2Yeg/rrjBFLrAMs8QmCpgGaB jZW7qjzGT3NFZoLwUImiQIN45fQsxXGsomIGEBFFRY1Nz6VLUjkWkRpiCWTEHYcJcWHN0BBZQTSF pEjTM+LtzZ3P/vJF3TLKSgF3XmH5zEwmP5dPj86dGhgRwty0VepsTT25/4Wv/8MXmdb2b/3bv5qW HiZ0HdDJZFgU4E9fAo+n0w/8xY5jo/LXHp06k6scYW+Mid2pocf1UE/olcPm2CGHu5vWCpaF9ggU zUU4wjKsjpVabMsyXZrD/2CdRcRKCJLAmjNYjhK37cVl9+hXXBlT1Pc//dz1b3pzNJasv47ZmQnb ktE1CiMAzUKaYtmIGG1qjydjhWIZksSa9dVaP4amRYHXDN3xWjGelRMudH95nzvx2Wf52UPFXG5N 08b/87k73vIfQ85MwbVKuWJ0pGwdnCO2TrDNUXMorXc3Da1rt0BuShl/NZ/XG9fbFEXc/2/U5Eik J1z82pcjb36T1NBEDA6uk6U1tpqK8lsh7NCy4datH5itFLNb3p4pvdRTPh0lHf79V8BITHvwOXtI cYGhMYQUIcc6KdeGVoloazFVu9UhGMcokZJeeknRivq29/HtrQqlmsWnwM1tuVQY8VEQiQEybAJg vit1YmhS/N9216GRE1d1XLn6Eq6O1fGGAhVB+Z/oH6kExqY5wyRbWgHHoLk1cC1oGARNOpZFuA6I hG1IAVVDk03Ac0AzvR67OG0XA49NgpaEfXQIIl6CQMWxHWQ645EYQgZV17L5XFQMQy+yIrIhla0g y44oAvpGEERXV/std+5hE8yXvvTXpmUphozICqIHpm1VNNl27aZkE2DiV+7s37nzRk12rt63ZeTM DY4F9z+/X8f5rVGDjn5nkvrbt/UBW9vYBr754Y4v/WzitxXKado12n9Z9Dc/ZoZ/4CBrjpu/mLZt U57WsqLhinrXE0jGCjGORTpUKCSEeUQylGKxqGdwWYxAhwRWoBnSdp2QKMRikXJe/frffeVz/+tv aKaqMnnk0KF/uufbn7jSMg1LVWV0ojQbIoSIQ5CzmTkcVkk0t6/ZHIAFIiusTKtL+90G0sU1l1g9 qERmX2SGHjJariTIZp4LJ1J9xtR+2nYgRU/Nqjf3KY5DXbHGeFF1rtxLs+SYSzCQnKBoe+Z1zrLl rj577xUvR6+xGJZ67MfRh34SSoWJGXLLf/I3OKzTIrCkTua+O0RQpG5asUrjNmHXTfbg1SoM9/Ry e99pDQ3bZ4Y1isjxRKENKBwV0S0qBBVCQPzFUseAbJpjbnlK3fNxpjlZVmfpmUlxx8ayo0IhBGKN APJeBMkCJAM/RR18bc45kn8O7Pvo6ku4OlbHG2mQn7oTlPOUYxKRiJVIGNAhcGoSmp4bgII4MZcg XIZ1SQrQNIYQigUkDSgGMALgIoBEvzKAFoBpCy+8KqBpvmUDHDWxTJ7lZFVVNBWZZgQnAs/TWLme shzHMHXDMtDEn2EYWZUfffTRqbEJVTbRz7aDA7sISzRdRdASF2MNTdFkKkUCNdnaCkgKLXb13u0T 05PHXz8lhkIf+cAdB4mtek/fn24lcE045k/W7m5h8smH1dwkf/hhOnPUcSxknOWO/tTUKauU1yyE FrKNZUUwbLhYP4ZMRlNhIVyQC+OZ8bJcJl0SYVuqIRkPRxF5cYBjuXaxVB6bmMzksxVZowl987ad 2N2nKn/3pb89PTi4s79tYupMXpJMG12QmEtyqonVNEOiiJbfsP2qAIQQD7ItRzOMeqYCa20HFrCT Og+YII1UKoa48VY4fXDkmR+SgPzpOG86JBQTO7vYki0JNHlilrttB3FV1zBkJl0aAf4AoYxOnibX 3xgnw2yirSnUxDJcLMRW9GmWZInp/MybzcKVenoDLK21i2vmhjbDYn/+eFvueKJyQnRLnQ4ktVPm wFNupQw3tzpXtLvbOnMNBnV5liXAnMxrlIhIHygUwag5e6yy72NES1yamIyyOtxWLvbYuf61RqQJ QBrg+Qg6Q6oXGDal6T1D8ugr1i3v/vjqS7g6VscbiqnYJsHQuG8TMmmmSloWtG2Coh0xZHEhLxcM WS8Kw4kqg6BTO9abx6Je2A/mQOwH62kfo4gkIgIsS2sGZZoaMLSmhqSsKrqhzczNRsIRrBLGc1E7 IusVw8YG3dDNsispiqJXnLamdttxSpWCaqgszUGCQCtqht7fs27TFZuPvPBE8cTrNsFt2rrhxODr P3/gV+ig77jtFqKx7T8q63+xFVkty5NOdhH/CIX5d+zbet8938yVCxzNIC4S4oTOJ/4DAmhAOxKO GTpvoOVsS9UUxJZSiZRma7PpNEsxESEaYkWcq8bQWECAhALD27YTIQmuiaUoCiFltpj9l3/5UTEr 3/aOt3zvO99FSNPTFCK4RE5yCsUiJzRQDpqUOyKHGEuYoejnXhpueeyh29/+oSqoQCiG+AoCXF33 4ig+M1mo3bJICR+AcnwzF+nKHflNdPv7zaPHpgYO/OV7/vJ//stDRH5mYjLyJ3vLn3+04bpuMyKa BF1wYRo4hMPGIEnqiMxEU4BKuMxugGYN9PPJDsOlrOODRlw3O7tfTIXQrCAihBvL49NMa0u2MFMw y5OOhW6vDqB10LATM9Y/fKb1TXdVymkq/9rDP/uf5UMpvhPmHYY0Gd7IwpIzl9Zv/oTFE3o2HW4e LrVK6s6dpVQrADg9289yQydDoxmHI5U0mR4cDGVeO/O7fZoHTo2XJMX/ORoWtq7rXH3DV8fq+K8G Fa/Zo1eDguwgUW0NaBtQZ0gCS8EDUweEiSbqQFeB5QGMY+PvaB3EY3xvjeMCkcMtdXUL0gxBkzQW a7HsEMs3xpOTczMVRUlnMl2t7WjKL4aEBiOp67rsVEzTJAm8/4pWEYTQ//jvn/vFTx84cvxljhEY ktItU7f1jTvWPfbr3xw7+uo737J3dLr84K8e7GjqfPut73jw1w+u6e24P9/1aVHu50hsvQjCsW1k 99HJbN61XjEVCkECy2uGisw7QoiyLBXlItRsRE4QK1J1BZlshmby5TwCnng4gZgTJCDiSYhIKZYM VBfBG0uxkXAYbV2u4KwtMSb0tHeSNPHy4YGDR45k54rZbP663c1qRUqketC1qSgVRyowNqJ3uHMw ImXDk/mhobH6686wdIjj9IVkJcAPd2FKsf+ryyccOslsixXGBvre8+WnvvGX7768ceDldT87fHKm 7L6eTmxtgWEO3YgkAGloTrikhjAfJmInRt2d+WyorQnqj7rs9S6fB1ZhuhQhJbB7F0u39ViUkJFh x45rOz6yVR8/Hm9oLx4+GP/RTzOydQahtEbwcy7IT5tq0TUVqKkRhj85pIcTYYIJAaUCcraat254 V5GwgFbgwBPF7b2lnVeZiMViQVHCQxR0f0zgIkSRx9QiOHggejQd7l7bMTd0PNW76dKf46KkvPOv /+Xp0Yngk/9n7+7/vQoqq2N1/NeDiuNARFYwlFi4MSIyYiYiKw40TC/lC8u824isGJ7/3zIBJ+DF sNQIxDNQ7CR3MINBy4gCpeguwhKaJjnAG7pm2kYiGpHUSqFUnMlmkvE4TbMCxSVjDZIi6dgNZZoW Vs5HGFMsl555+rdfve9vvn3f9x586IFYODGbT5fkIjLfqVRzeq6Ynkq/cmC8tbX1Dz75IQQ3LR2p +18YORNOffyWgqE38RQNMa+AHp9CJ2SFI2J+Lpuv5GmKFnnecZBNMxBiKtK0CymsiIx4mdebUlFk juNpkvLTENCfXMuNRiMUomyOhSb35VKZZzmaRmBpVf4/9r4DzI7yPHd6n9Pb9iJp1QUSEgJRJIop BgTGJrYDF+NgJ3G3ibtDjE0SNxJj4hjbgRj74mtTbILpVQgBQqDed1fb6zl7+ple7/fPkRYhgRDN 9r3e/1kdzc6ZmZ0zM+d7//cr71dTmRjtIwtp1WqKaRi6YQAMlaqVkqJXVbuqWKxgMb5qeTjBy7kp CyfoYjF/+HUHsiIKQFZ0M+h75te7BR+FKNhhaWCej+uWH0s08yI/NTRyzhe+G++Yf/M/z1G/+1Dv yw8ta1Ue2hcR2Ugs3OhPvYQZw3h4AiP939y+aLIwuv+Z8kkf2ulROF65q5RbMjZQG89anTY5P0fW JFNVtOQJZ9gb15dffoZuaPFGxvQNj+COT9vEZsws8nSjTyh7ekrpuz3OGK9mXx50fZE0PIyxLKFk kLq5YnWe9n11mOW6ax84vxhNHGQn8AgpOqd688sVwrJnqWrMwuIWFtZPkpcudquVctkh35HGwl/6 yT2HIwqMtlR05us9M2bGnwBUbIuAH9fFyyWqWKY41hd5JxaxASR8F6b2FAvMg/FQmXpQreHYnmkR iKZQHh4gDbAW1DXXw2QJy1dRcjJB4CxM+X3Msk3fd5uSDZoBQxsYHZ7fydICLXB8MprRLR2MMArZ kx6B+4apbd614+E/PPDBv7m8WquuW7eOZVhY2LNn/8WXr+3vHhkZy7Y0x5efsoJlOYoiF686997B 3vdYj7/8giCds5rhON8PqgiBr3geUhrzcUVXCJyKRxEFqSmKbuuoMp8EM2jAuYHt5lgGPgsqnLFs 13MJgnQci2LJkCyWKiUZPhKSecEEXoAZd//YUCQSmtXQDjBooCNYxXKZpWlY3ts3Ks1Pl0ulqmbZ PmvpHuXalKX6bPWCtX9F8AOqMXDEpWeBjnGokeVBmoIdFMs5snvxEVPyqppKZDpObq83dwEAve3r F97034zr3jFYMP7xPTGM2osTm7VhbP9uP9To+3qua5a/aIlsHChwDUAXuJ/+2B4dlLTKZJvP2n1W WB0JqR6Re9gr1Lx+z2F2GAzB+ViexgYpd9JxE7OiHkYObtmbc4tYlCiG/KJqh+IsS/hMXknQ5ryT 86bKVvtTIZ2OzGIf2ufXDNZyRY9LAu74lkfTgPgCSfFSNC3DhR0f1WqDmEPY4/2DcmjOvHlv/zl+ eXTyiDUnzGp5swfZsHn/9HLfWE4x0POdjsqZWGTGUkyP1sZkW2N85jrMjNcFFV0nLYtQVeADXnPa ZBkPIIQi6xr4qDS9WKJDYQf1nCV8kvBhBuqhRoK44wAU+QAGFIN5FIqySJxr6K7l6AzDEiRje6iQ EEU4BCkdi49mrYpSzZeLFM0ANVkwu+vsc89+5PFH+oe7LdTXhATDrii1393zP5pqXvXxD+/ds9ew 1Fwp+9S6py774Ptv/OH1m55df2DX1iUnLqEpxvfcnEr+61p899bEb+5/7pmnt1m+iWN+PB5PJqKf /4frAFpyuSwAYSqaYmiGwHDFUINyTQxOL+huQqNmwz7mBQTN8RzTNimS5hmBpbmxqcnmdKNjORRN ySHRcb09vT2z29sb0imCwnVDBzJTq6nAUZDWC06+3DM+v4EwDNNBfekpzMMNVaNZr29o/IpkROBq Ps4dcelJggCyouq6HeDKK46vw9xhR5eqeL5fqiiojwxJeigxAW4K8ZWPnVsYsS6f9UtJL/k4gxQE FKUwRM9boV65MuWLAl4dGn+J2P0HQY6ZrDpo16rpJENOYMChWI/APAvzaF/FdRq3WaqCewqJT+Bu nnAIGmtY1c41NGl7dnk6Q8blTEJesyyabG2gcaFc01lcKB4QCFJ0vVzOU0wshsU8rFzEjZrkG2HB wKLRBm4ixgPOlB/fnnn44ScA1Du7FtKaSx/oJeZ3vSPP8e5s7og1Zyx/E1j147ue+MaDT6umNWMR 3nCs+/LHZ0BlZhwLVEyDpClPElwAEJr2KSReG4RYgGeYpKaRSo1kOeQVIkggAfCuX4/k+x5eL6h3 fY90MJ73JQHJJsKc33dtEmb7QHaQRDBumnoiGlc0rVQtDY2PCTwfkSNf/dcvTxXHF5405+e3/veO XVtt2yEJCox4bmrq8YefHBocOOf8M39/d7FQLezZ171z85YzzjqrsbXZ0bMnrVpeqVRt2zyp1S2N 4XMWdn3vzDVPPvn0nb/8HYETlYI+2D/+3PpnW9q7ANBSkUxECsG5AjWpahXbsQKkhHN2JIGjSTwR iy5ftvLu+39fT3FmKMa0DSA0bZkWXTdJkoCz1Q2zZ/DAkjmLRB6lD1QVRTN0uBKlStlxHc1EQDtS 1Dd3TzZEUcdJgCpF08s6ljft5tbQr++49dmtkxedv+boqw88CchKxXGwoxKIA33PV5p0+YctWJYN cEaSOFjnIGXMw4GNtVxw+XujocoXMGNs8/qld/7SPq9rUuhsxoSlGM67vJtXHF+1HnyKKJqFUAMf ipH+FBwJQMl3VMzcV/IApdI8sDnD9a0oy8RDHakEloxxi0+Pty0SZlXlWMZyndGhQUYyw25CqZQj PO6YZdqeZE2FkTguivHOxsa4Uk23N2Dr460H4Hz39b9vtnRfbpK69TdJKs5LPCAQQ5GUmBsRHZ/n 2bf/EO/sHj5iTSocehOus/+4+4cbNs3YguMcYVmYuQgz41iggkIILphK33Fxx8YBDnjBFUWHYXzH x8eyrGaQuuERQa4Xz3k6yhAjGBqnKM9Fq32ORxAErCUqWjhGm7aD4sOuTZOU4ngEQbkezMXNhlQa LLtuaCMT46eceIJmlm/53o9z46WrP/m/rv/KPiArQGtojDIMvVgs7thqdfcO0CQTkaKVaun223+5 7OQVmcbWgd6dw7174k2dOEn5jj3Yt3f2klWf/+K3RgaHOIaPy0lgJKVa6YnHnmpsOBARo42JNJgt RVVHSlnD0mmKRszEc1mGufrDVzS3tC87bTUriIPDYy9v20TTdFWrynK4MZyyLUcWBZZhAWD29XUv 7JwH9ht4CUESpmayNFOuVus1orBS4ARJijzfV1uUYcMcpjrUmEpULKIxAxyFf2FnUTFxWX4NM0dR ZJ2sOAFb8g+XVHsdD1h9A8C1SnGyo3MWWVc8RpIyZKL5ZD90m77verK2K8zTExoNFMR37gMI3fzk 0tvvbjq7Y8LlMDqa4KIRgEJ8Xlnvn/LaY8SiKL34jFyhUMUJN9rkp1pJOcyX8p6mSJGYQ5OTI6O+ b02O92hmwaM8imD29PwOM3LOVHXF/CVd0v1AbW3ptDA/HBaHqRC2u+9yietFvErFXIfYsrXpe/eg BLywk2/pnEuqSrKxSRIYIZ1KnH7BOwAqvSNHrJkfDR/nvkPjhWMjyj3n96Sk6oyl+O2u+bf2iLAw k1M3M96IqZgEMBVkmzyMZj0Z4IT1KlXKdMhkytJhRo5h1Qopyx6gDmFhdVl8yydsGwdmQ9KBTSN9 28bCokEQNMADSiXzfYaTwIh7mIf5rm7oPCfWM8HKtWq+mO3du62QLzelGuPJOOCB53lEIG1JYISi 1wRByI5mwQylo5mKWu7p7bvt1luv+bu/C0WTffs2x1INRiVXq1QiiRYpkmpOtNRySiwUh5m9qqtV vbL/wODggVwmmeFFAfDO9iwAA1mSTNP0ECnwmlPRKz76CVhZt9jXffkr13zkQ1Wl2tbU1hhr0DSD olHStOO4u3v3d2baPc9XdY2mqEqpCkcgEJj65UqJJEkG4BfzG9MNUzmzp4jBJNzDCd3DUZJbRO6a E92/vsqxAE/Ma94AnmN5jqup6hHx+SM5zUQve9dP/XDIz5WGs5UelyjPnfuxG/+FwOkgzu8hnTKc wuS51IIfJNXbMqGtpVL1hf/pXrXWAWrTkeo+bUFH59xT19zwbz5Njg6NVcsVX6uVfCxLEGqpwHJC bFkDT1KGaZSmJry+XYRZIfSK6sVr+V7TPFBzuKRoqmTeoamUvFLN7tULzgdPqshNi9uSPk5g3QWB dbKUiPkWZiikQ2B2gS+UGvqz/KR35uoLWSmUUMomW81iihBPJqa2vdS25lxTrb2p5xUw4M5Hnjti 5dPdR6cm+/9y+/1HrDrzhLlH+8SOPtoR47ITH3zL364zb/ssvD77sVuOf5cv/uHjL+X4N7XLH2f8 dDOq3hVf5zGeGTPjFVCxLDAIuOEQHO2ZNmkUUHwlHjVb202MQAUoKJ7tEZKMAimAK5pGCAJAAPAb Ann1XSAnYLaRbiNHm44N8OCYtkchfUaX4zhN14FVuLalqNVIOKLoyAn2+AsvnXv+6S5uf/Ybn9nb u4tnBddzErHkSctOisXj1Up18/Yt8UQkl8vPbu2MJlZu2b35xY3by6UfXHjxuQcO7PM9LRzObHr+ mZauk55Z90wsLqdiCYEXiuXSaH6kptVYmmvKNDMkNTmVnSpNGpbBc4KKSugdmqE5mj17ZWOAKAcb MMphGf6LR1PtmVbH9kKiSFLo3Z7RfrDXZbUkSA2maTMM5Tquj/ua5tgu0mO2LBMFkHCMY9giFxZZ PCYDfnAkxUbCoumTT2+ZlEPiBWevuvT9V7/2DaBICZEVwz3UvAt/NTup0xfy6Xtrv3iW9PzuTvm/ l62xXB+b0Oc/9+KZZ64ikIgZ4ooYEgqgCbEledLHrki89OKD6/YNdwq752BiiyMlO98fndKc/U89 4/l4JBIRBA6VtpYL/sRQWKt40Xj5dz83x8aJkkGevdJ+8NlR3xmT3MSa0wSrYNNeuFmoeWahyEi8 5xNqmLCvODM7u00at/Gy3qV40ZwyR6c68SHP1M0pPWp71zAVZ3uvYruUTUfHh/o4Uel57vnOshol qDTPRBmm9ayLdn3/64tXrTn+53XD1v3ffOzZN9xs/eAo/BwZDDhh7tFbPt09cIzjnJ+xj//c/uXx ax4bDm0sUFHGX9ts3HbFrbAyznlv6gv5o31yp+z9GVqKoknC6/KG9IzRnBlvACqOhxdKFJjQkoWA IBW12lt1gvbtetIwhVk27qJsYxyojOejBVzEgN8QsMJFbhfHQuwFp/2wpLuODFTDcT0dbUGzrIzx vKLWKJrRNUVRqqlYzLLB7Bi3/Oy3X/j7jw6M7L7/7gd4VgSYuv76rzV0ZMLhCE3T2Yn8N792gygL k6XslVdeUSjn+wcHVEXbvbs7FCHT6cYXNz1aq6grzul87I57B/v6OYEbmhwemRxxHScRTnY0dkbD EduyI1JE4qSJ/GjNrMGnAZBDHieOfP+arYGt9g5GMXCvs60jnciwFMtQyKEEIJer5gfHB3iWi0Q7 6o0vfRd3PeAhWLlWsx0bqIFu6nEyxtA0x7Nz53Yd6OufrHmc40siZoM59cFuc5GwcOlla2OJ1Ovd A0RWWEbV3cOdXUeEUlyALxKhRqVqpEYOOLPnR+OxTIoy9QrLR+BD5EbHyhW9puhwnR3HU6yU0n6u xAh9Js4TDEAjhtVogujs6DByu1raWjlO3Pyf32/Z02MP5QnbV69cG92wD67RrItOH5q9hHc2VHCC 8RxBlrP7xixda26OyxE8EZ8jsQnKbxbDs5SEsE/nzOqUL+LxqJIS3c7kvQyf93Vs19CVGfu337+r Q8GiC09oiKSblq1ZM7Z/2N+1L1kxm8M8S/IL//Fb+d2bxzfvelPP646Bsbf8rC9+Lb/NznzpGLss TWrHjyg3bIt9pFM/v7VaMugHRsXhfGfWIuDXOzd94Oe7GgFdHhxjbj4le1dvfH+N/PdVI2fO2vqe u9emGQ82g9c7L3uwYsTgUJc0q2VN/uJDV/2ynweAuemMA5csfvBPbikem0RVaZ3xmUTtmfFGoFIu kfCwcKKbaTQBVAALqgodCtu4j9K6GNr1fRJVVhs4iyrTcUMj0hlbU0kAHjCwMHd2bBx2dGEZJ23H DSTxfRRpYHnXsQjgKSTt2h7NsCjLi6KaGprGJ8cPDAz+4dEniqVymE9FQmHYafPWl2eVOxcuW9C3 78A5771w0YJ5W7fs6h058PRT62/41g3fvP6bH7v2Y08/9UhLc4zCiXlzFq654PJSuVArV3AfH54c ncxOgv1NRtPtDW3xWByl5xK4bejZUi5bniBJCs5K1dWQJHc2yInofgUzPQxxed/H5FAkGokWqyVf wuC0FU0xLHMiP4kkymjUUMtzfRIjXN+tKBUP85G2cSDpTFNIxZgFJKJIhmcWLFgwOp6Fz0jQDEmz AkexHHXemlWz5y87xj2gaUpE6QCGd6i2flqyZdodBlcwBO+TeEdXQ+mcc3mcxNLNNVOqqdRUsTgw OAyUh6IwnqbjmUaGxEZGJ5NhviGGcfbo0/f9NqsIDenoigvWosTo3iyDtXmqRSllmdI1w42umJU/ YQVDPwC3z+rvpxfMJ0+dnxFD8aaG0Mlnti48hRd928WmsptdvDhePhDmZuvYplqvffGJs0W6P9qR w6JfHn+hyoh5pBpnk4UKfd+zC/qyxuy5CY7mkukEAbv39iTg6cFxriGePv8ytn3+lr//CJFOGKrK ieJxPq9P9Ay8tQd9UToVOSrCXK5pJUU5xl6tYfU4j/+rAyjtuCOsL2nInzFr/T8Cqepb3V8jIqw9 VJGAvgDewAbf2pq6epaysSDfuKX5JsGADdJx74ykCfhxywvnrO6YCA6iAaL8YZT7xZphQKMfbOq8 ZPFr/MW9Y0sf3r/oj2MmDIesL/QXikf7FV/PtTgz/kJBBZktArMcvFQDQ+jRZJA3jKL3GOVhIkqm ZWjK13QURwDzahok0kLx69wFkRWSQMtg/1imRhBhiiBqtg6Aoxoq43oUKzE0izqn2A5JErqhCQIR j8bcfP6Rp9Yno5HmtNeabjMMbe+2A1dc+Vee7a1cdfqD9/+u98ABAA9ZksFi9vXs/dF//NA2Jue0 niVHYlKowdAN21Z2bHk5N5XLFfLlcpmi6KicaMs0SpLsuTAsTTenyvlCdSro3IsYCcuy8EZnA0aR GO5WMDJVJwa8yH/mui/+x03/NpwdBSBpTKUrSrVarWBIkIYqVUtJOYljRLFStj3AmaDDF00TOMFx AsMyBIAIcnoxsWi0sSExVag4vsuxdCwaWrH0hA988Cocw499GwSB4zRWM4wASXD8qPIU++KPkItP 1kaGJDEyixTmnbBszME8EteMWjQSbsyEBFHgWULV9UREYPjwrM6GwZ7djSnaLNIrlqU27uH06nBx tDfetti2XKVc5kv5hERT8+YKrQ6xbBWfTFvXfdSvqhVJJNq7nJ7d+vBwbnRXjzaam9oMn/WEk88z /EnPUSytLDaGlBoF5/rkDurKFXlMOgNTf0s4J6CaeQsrVE8zoudc+dVPnzewf3B4NN+9O5JMDDz5 LEfhakEJsYzQ2RGdO3fkiQeUCT1y+sKhrS/NPeOs43xej04dPs6xojlz9MpdR6WNHTEWpseP8/jX nzT60Wdagaxg22JRZs7t5/YOF1GyQGuscsuG2UA4brvi1l9+77rTkvZNa//rR/uuWxBydk4goesv rewHIgJvAbmJIjUEtMvnX0zDLmHB6ArbgDdH/K2KLl1590fr1OGPPF7TrxgQmWdXt7f87vq/jczk hs2ACgq/k0EHJhq1jWJYoCOYY+EwK2ZYl2VRzYph4byEuAggTa2CA18BFAHsQZEVDGbrvusg51hY 1BzHBqAhcRyOato2ih6TNEOLPCPolkZRjG3DxLTGc2I8HMuXC7liiUCZtfS8roUf/dS1W7dukTlh 5emnP/fUpssuvVytqQ8/+tjunp2/u+eB2V0ttF3QrYqhObpKRuLhXVuf6+sd1HRd0zVZkGU+koqn JIknSDhDxC0ADEq1oufB+ZAEQbgo/oOHQ/KcdsJ1MNKZdA9VcwM36JjX9a2bbrrp2zds2bU9XyrC BB7QI4h5UKVKORVOwV8xHcOBPQmkPELiBBCLiBzieIZlAdHIeCwsiizPsal0JOgiw5926mlLTz6d IMg3vA0MXCOBN0zT8338qNQvWGNkuvCGrp6myZZMA5sb1dONoy++0NBCmfg4nVjO034qIaLWXp5r 6CorhHAgiKxER9p8Qoi24wt5x6hkspNZE5PllhNMUnRZQjj1PGeo19y/jx7c5zd26D/5327NiJzY OrparT38YtV1zUaaZE1gETCLgFnB3q17TRePyHj7LBvuPhPFlYJc0o2U+ZSvwtxipVPCNm6NbxjD rv3KmWI4lumc62x8kaXJ8sjEnuc3dDRmRB8DThZeuNgoF7t/cRdGU3w4glvK8QZUDitOfFNDZJnP XPYauLWjb+TYO66a/exx/omLFz/WNyv5wJ5Tt+VCAAP/vaN9eQp9rvboZJpBfrBdo8tRTCKlTC+U DLq+wXC+ExaAr9TX1NEISMzlD6MiniNCLIAoF9x57eYi+edmStYPjrz/xp8/9f3Pz1jVv3RQcZH0 oc9QKIGIZlyaDdKEMdQPkaQwnvVgA8dBEGI7GGxjmLihoXk3rKRp9OpSmGUSguBQJByH0My6Fwez bZelPctSORYMLKdbKBrPUpyiK4pWk8RQWJbB0GdLZYIcplkuV8g+/fCG895zlmVaX7vh6zt3bOZk 78L3njsyNpLN577znR994iMXMQwbi/LRdOMjj9xFE9ipqxaffvry9eu2P/P8lhAvCxJPUiRwHU3T c/lsSSmh5vKIYBF1KRR4V5YlE30cjLIHLfZwtwIuR0JfvP76791wQ09/nxySq0oF8CMkhyqVUklD UgGoUyQgSlB4SNGU7TgSfAxZIGgCqfqLgihyAi/Ap03EIqetPi9zRDf71x940LxLUVnDNPzpzs2v 9oAB9Ckm2O664w2vaNW0G+vvP9A6ewVGoMIPYI+AJuVsgbedyfGR7ERJ1+CGUjbZScXMzq6Thl/+ /cj2+30q5UUlfueLeMnmCwV6S4FbVtEa2iTLtT2MyZcpVUX9YxC3o3Af2Ac1d1GDYvoXXvKJhx/+ OYER4TAvppsHe0akEH/Xi20fD+UZXMUx6sXu0365bl/XkgjL0kEUh8Q8x9D1/K7dJonDOcU5lm9t Srz3Qzv+/Z8L47kYsBZRDvr3HO/41vlnHrHmdzv275x8FX05f3bHqleX01914emvWa83lDtWQKVN PN6A+QO7Lr72yTlXz1KinB1hUcLFuS2lW/agKcvi5s0bC2d+bn5tsISoUoS1pxfqHrNn++YOVNDs /tJ5I1/cMBsWljQCPUqfGnfq4ZkT0686yf964X1/hogyjSt3Pvj8VRefNmNY/6JBReB9ikJcxHYo ngXj5EdCTjjsMDyK0gNTIUkUfHCDKhawaIbpWzoYVd+2CIfywGQbBpho33HgBWhNkGBMkC6SlPc1 w2RpqlLNy3KSZ0RFr/kEBrN4yzI1tSbwItCaQrmcKxZxvOfn//Gzz3350/A3nnzskQvXXrpvZ19r c3M0EVqxdPnzLz2XjkfS6eZwNBROtmx54RlGaDCrU7VKSQyl+QgjMCIvoHoZpabky6VytVxVy3i9 ETCqEES4AnDAMixsB4QALB7lHni1VUdETY5GvvTNG2668cZsdiISCmcLORew0fMsxyQJqq7DBZ8u aAcJdpzg4A/LAg0TegbIBimLCCqT8ejpZ110RBevNxxwBJHnDMusF568yl92SMq4YtiA+HhQnIJT LMmGdAMlY2uGO5EtELjvum5V0TxiKh4VKcpNxmIAgI5e6u8eI0qFuSdd2L/lGZcTNEGQQ0m6PMaK lA1Ec9+4s2hQrFmA09hUzVdLnIfZuMeI7FS16tj2wMB4Q+tsTd+eSeMcHckNj1vuqGe4mOC4Yb9E xqhqkui69vmnr6YEMiZy2x74QfvSy4qT2amRHKD4nj17mViE6e+jea7jk5+oDPeMPrKB8wmRwXDD 0rXjjVucsXze0Y77ez5zJH356uXnHqd//6Wh0WO8O092j/PETmjYu7a55Vd9UsnCgVjcsLT4qdW/ vqv3s+m4t6EXMSQAm2lvWN3rBQslE+Vu1D1dv1gzfMniB6998guwfMacdTef0giYdMO22MVN1uoO 4/C/9czoK5oxX1lzyomzmkuK/sm7HjrilM7ubF3R2hgR+aVzWtZt7/neMy8evtdZJ3atXj5/cCx/ xyPPH/4WjBMb0n975nLY68R5bdv3D23rHTni4N+56KzPf/i8/1m35cO337vve//Q3pT43C2//flL O+rv/s/Lu2ZA5S8dVCwb85BPw5UlOxa2UdNY3tENvFwjw1EHQAWVdQTFHS7K/kJV9MUSLYVdx8Vt mwCYASBxwSBbGMHhqN2w76I6eo9ESOSBmQOrZ9i2znKc7XCqoZBI+dFGwXxd5VkuKodKtWq2UPL3 7fq3797iWB6gTltn2xnvOWWwd6C5ufNzX1+29+N7Fs6f7eO2Yej9L70wMj4ylldmt4R//LPfJGJi c8t8UUBhm6lirgCsQi3CMsAGmGmYGQPUgan14YRIggnqZnIFA7m/zC2HeZhQGlggJomFY5Ev/9M3 b/r2t1zfL9bKYOVJgnBRcSLuex7N0kBWEIIwgCwELwA1YevOK7Ce4ZCUSqXOWHOhFHrTSTJw5UWB q6maaVvTXi+0th7CCkpYdNNhyAAfkR4l63tsMt2hArIKdDIhEPUIv1XLZKIEwZoO6QPtpDBaTHBS niRrtZHty87+0Mb1z0yODac9l8ZtuLsE3Ard9Q2jAp/MA3JBor5lPubAH2R53Nc1zbMJP6oaO8e3 Wj4pJpMlo6qYcK9pGVFAEmdoJ9k12fPrweFaSxsnh6TZp1xK05GhvU+4bFgbHxueGF86bz6zY0/k /NMjy07b/INvmA4WJvFwW9zoP5CfM+ftPMFHR1nqWV6Hy+C/3nh++Fi5ZJ0h64UDZx77CBG+tqBp W2uiv55AfPiYrjWxv7KuvvCp1ej1ksXYN85DC6WHrwPMuO+qH0/vkvvCDw9t+ev6xq8RvHh1KOWy s05av3kfIMGt177v1H/+aX2lfud3Dt/m9ic3TQMGbAZoUf8V8OCGj10KC9O4AnhTX3Nw+3ltFeXI a3jZmSjrZN2uXjgaHAGWf72ze/rdkm7MWNW/dFBJJxwC9aVH9nSqCFNHnKoyHOMmEyYnILnyIDKC mSbuHVKlUhUiErUdnwSygjOeZQIHAPDAKVQI6dmOQ5IMCZYwyJAybEdgadvSeF5mOdfyaddzSJoy DQO97fmhIPOnrFRzxYLXvXtuR5dmONd97huJUGLtZe9Z+4G/UpRaR0sjRRiOUVUdTBK5eDQei8dD 4fh4/pGxnO7aOVW1RnIjuVK23k1S4sM0iXSIXcfB0CQfTh0JTYKdLpcrtYiJ2sBoW8AAI6WsV7EC RG9CsdBnv/KV22/5UblSqdQqNIO+xqgdMoFcXz4KgVA8xwJTARhgWSYkieGwHI6E4vHYmedcJIrh t3YzGKTagnLkXhEtrnewD5LBcKSLbGJIVhkl2pEUWOn+JDdGqHrnspUkzuIkgApBsRJJSSSwmDBt KCVWBDrok7TAiZQHDFEZC0XjO19+PmLpS8K8T1C4hyqN8ENtJ+2aQ007VwguHrEMm2QjFHCalOhr Jk5RoloZVSouXEMdTknza6Vhiu/auO7Z1llMvOiIOs0VCnt+8y8+G6faFvbu2okRRGMsJCWi7X/z mbHtGyd6+hmCEgkfT2ew0amGxsa3/Pi+pkBLPVZ8wU2/yFXeViX8rT3irT3Lj73NJ7rUW9637S0c /IFdF8PrpgJ95m2fPbzU8Yt/+PgDo2L3J28+9u5g0D+4bMHWIZRH0NaQfOT6v42EBICEI2hHffQW yvWFrG4ATpSr2h0PPdeeiQMgwcprLjytvtc0osAGN9/9xMvD48B1jv6700Dy6VNORNRk3RbVmAGS mXEYqIznaI7xgZHwtBeJ2ALvyqLDcT5BonYpIo2RlG8ZKDLvBT3qfaQRgpk26aAGkb5hEhyDVMBo pAaGDJ/jugzhBvNrDCcpxzKRcAumObYhAAlynapWAXNFkCSQHZiVA/mB9TDlLdeqU8Wiae9ub+hI RVIDYwO/u+fBkZEROSx989vXu7pSzI8xNJGfmiwUhmPR+FTOXNQ53zDssezUZH4MwCwWSsYi8ZAU 4SiyVC0PTQ7anh0QDM82XZLAS+UKgWPfupomSczFLNLJOnTLYXwFqwtuwbknGlKf+frXqZt++Mi6 R1ka8TU8yH6DV4AQiiYlGcGJJAkhSUjEo6GwFImETznt3LeMKNjB5l2CqgMQ2wcRBcenGwvDfwxJ W6bBcZyhqxQXMWvjUkoeHRg98ewLdV0TZRm1I0AFRBZGsizLqRWPZsKOoxMUTYkyZ+puwmlusrPd LJWtErgQBJswX8coigB+RATiCEjmObgeNM9pSj4Zx+ko3CPWsDxD9wmM1fpyhG/BTWNjhKp4z78o NTSItqs0t/jkFj9z4Qnjt99WenwHcd4Kg8/uP9CXYHG6nG/54FpfCg3+6F+dco3DAcw9Jp2pbt0v R2Jv+YoNTUwdsaYu0FKuaW8TUY5zLE5V6kjwo33yQX4je/eufW5x8+Zj73jJ4gftxajk/ojqyF/1 Scdwu00zpxjPfv7D500TjjoSRESUJ9YQCV/93TsKmv4vf/3eOinZPpGtbzlRrtxw2/2PdQ/U1+gB qNR3Fznu83/1nvpxLrzx5/UNnu4fPtyf9tC3PzH9a/62b05Tpd9g2Idvv/fgx58pZJkBFYbyQ5Ir iS5NeYLg8jxCBoIOGqXYqFsw4I2hkpaJiIiHGnn5sB5+9ZB0IkCD73g4R6NW9jWboCkUD0f1LDhB 0wzKBKNI23UYiiqXc/FEM4/E3i3dUCmS8T3T9dxAoxcXeQFs2VSpCHbftXvTycysts6hsZH7Hnw0 EgqvWHGyZUyFRHL/nu25bKFr9nxWYEsKNpktlJUaYFMsnEiGU9G47OPkVCE/MDFSKEwZluF5ftB5 jGDgbGgmk44r1Ur/mLBk/iRgBOkMTYPKtELKoSoRX5CFT3/1y6OT40Ojg0gPn5Y93wV04XkG2JIk sLFYOBYOR2PhUAiYSmjlqnOj8bdbb4z08Hmuojh1RMEPoRxK5rZtnhfKVSUWjU2MDWUaG8d69lM0 UcpOEJ5nAMhjB1vc+yi67pIk5wXEi6J4iuVhkeRDnO3JcXtOJurnpwKeRnsURpkYFQgMwDUheAo3 3TopZQWBZI3RMYutuhJpWWNWgw88ic5OaWycYAkCd2zS8rKTVNX0TjmjNLWfpzUu0rVs6Ibvwhng NN+7Y1fJ1LoIwGApsfZ/9d5xswPzjJzKkEhKwHJwlNpBv/XU2J19RwZFzp7bgR1HrvA7NU5rR54f 4BbwesPSYsmgAV0+9eiqZz+2GbjIDzZ1bixQADMLQs59V/34fXd+umCgFpj7a+Tt5/ae0LC3Xh2J BbWTvzoQ6a+hd2HlGxY/1jnE9v1D076sz/7k7nt2d9eR454ygrr2xmR9m8N3nKYygD31hfoGQDuA 68ACcBRAFICQfcXKRHCc+ogL/OtdhO2H3YX2xEybgD/dMCcwY+LdAQoZE4/XTU1JgsdxSCKEYwEM UEiEBPDwUed5sCyegwHSVEtkPayCTBaBGxrSa2Fo37JxgfRsh/B8nGddVP9IAKdBFAZMm+3aFEyA CaoeVKFJt1otyKE4mHfUm8u2YCrtBgEP0zJhG57jM7FkrlSoaZqbGy/XyrPbZrmu393f8+kvfOm8 c84sFadmtcS75i5QLHxn74ENz+0HA9fa0ASwYXh2sVbq3tFTrBQNU/eCtvOBhgwWk6K6qRumgbSK da2xsfG53db7zkH9o0h7xOfqcEIE2UoH5ecDaIE5PMZw7Ne/ecPN3/3OgaEDHE1ytMChjo10PBaK RKRoBOBEFgS+paVt+alnc7z49u9dXQ9fq5OV6ULIgE5MTJXTEUm3NJLEy6rd0CzGoywjUDWtWM6O MaHYIaaFcB0uKpyvX/fs4TjF0LCGlFKk6VBUifd0rVrxGAmXOIzCXDpQa0PCAhgV5iiUBYaiTKzE +wTtWYZfwwlb911/zPAyTaQrIZciTsqOqQLYEVU61UXmiwIxgMM52T1bTdUAcmoTzP6+fgrH0yGx 4cIPVKcmDvz2Iem8czgboAQnGQKjSYJlSI5/y5fraJGVJbOaUTxjR/cf51u8oAn5vkomis9/47w7 MKSzch1gxnC+89on5wDn+MWa4Y8+0wpfNHjrwTEGNrukWd1YkAFvvrQSq1dH/uf6K2/YFgNMQsi0 LXb17PLrFT/uyTZOYwP8fOeis+ruLMCDX331mmW/efxrD617Jd4TgMTRQZH6+MU1B2Mnv3h8I7ye deLBHgRt6fh0SGb95n3v/+ndde/Wc6OTN//mcaBHg2P5T/3sni+vXbN6+fz/Wbflv9a9BPAzfdi2 dGLGtv/JRu4+b/RT78aB8dDl+MLfHS+oqBpYf5rEfTdo4AiIYFu4KMGE0udYzDEwBDkusrQAJxSF kMW2UM2jhaoiMMsmgh4lSOQYZSeTqOGHh7RMvEBG3qq7wQLpYr+mFGkWiZ+7NsCYi0rtaZiSm47r WrYNewm80N7UMpad1HTUuHfHvp2JaGL54pM819/44vaQKI2PVxWdu/R9F//+4Zd1yylUpvYM5VEa LnJPofwumqQiUoRleZ4WwmLY8oyKWhZYIVfMqWCqzUnLsmg81T2Y7mzLEu7oIYLiHWQp/kFH0yHt eT/ZmPr2v9+0b+tWzzYkiW9tb4vE4pahW5YJ9IVmmEQyk2pofgfvH8+zgF0V1akTFDinciG7Y+e2 clnRdYNluImW5qqm85RfrZQkrdF0tOGtj3au/nBw5i5Fo8aXnmd5nuk5ehCL8RiWtjSFIwlXLzhm zSJNjMVd20chJfjoLoJTD0cJcJ5IopSM+pPEkqaC6CnLyKZSc13WcQy4m7rtEx4WomJatVApeQtP 5MMp2SuGKjurdJdkbdlgBXH+omWXTKOdJcMN6eScBS9+9e9quiFjHo+jSia6KakXi0RIpENv3WHy 0TNX1KnJK6DS1Y69kaLXOzXqymCAHyULj7I+sI2BCgLItc3GLS+cAyv/84IXgg1bAUjqQRQADMCe B0Y/DwxmOh/sixtmnxp3YD2gCxZkG/+yP/aaxY8Vgz7cH1X3gAFHuS6owvnnpzYe/m59Yd32nqPP /CcfvAggoQ4b9cSt+q/okl5y+vRmsBIYTJ3cAGtZOgfR+jseeX7TeK6+/fce3jDtWzsIKpmZVit/ uWPTzsE7N+yiNI0QeZdj3VjYkSRHkl2GwWgGMRXkAsMwhsbquvdgam2EJL7jIQghUbYUjpz/KJwP Fh0ZdoEl3CB3CGgKjptAU3zkfqHB4pu2RxJYuZxPJpokWXRR8MWlCdpHQGWhkLrrKpoCfKct1TJZ ypVrJZZhcoVcoVzIxDOzZ82JSKFSpTowPPG1G/51964dYHHDQjgZTsdl5IFC9YckTlIo9AHTbgAt wzarNZyLcCSJxcKpklLITk3kC3mexrbsjc1qzRL22KFoyiuS84fSd72AJSAGQ5LE4pUrBJYPy5Ik CTT17lYJAFkB9gPTQ8dx6tgWSWTWnH1hVdEAMCqFyVKhXCyW9u7aW1SNuK4IkdSmx55NLHxPIhlH RJOk4VpSDOt6lotwwwHGBhdHN8qY2IwLcZ+q+XyapiYwB+VeoHaZAQH1gpiKy1KeqgZOfR+gCFNd mKey6ahWqvgm61lwY12gLjgFUxARN7I0i/EScpvl19XYCoHH4qVnNgND9CiibKJ2zY0kuehjn8u9 9PTE+i0ORbAE5hJIU9lJp0mlTMbjPs295Wv1etmrm19t6d6lsaYZBcB3TCzAglpFVE6PYQAPN110 58o7rsWCIpU6lkQ5u6JxdcCA1zTjYTJWNg8WP/bXurAgIlNfAzADm7xm8ePOKfkVltY/fNE/3QqM AThE7+339ZYqhwfMZycOQnVJ049GlDpybN8/BETk8LeAhXz45jvr7q96BAUYDIDKo5+/ehp1bvjY pdMZYht/8PlTv3Tz4bgy023lL3CMZSs/feil23f35quo4JdqbbZo2ucYZEYsi6hWcIaB77wPoILT viRhHI+6JGJBw2AYQDmcIAs5cHEFOvI+FlhZFMyXhbpoFXIekchLjxGBOhZq7OjYwBJcVyPLuVgk zTGcZmhwWBa1xfWAZLgewiPN1GHHjsa2qbI0NjUGU1rLsofGhyYL2Xg00dHSFudis9JtYUaybL9S K2uqMlkcz1fzQEcicgjsYKlWnSplS9Wy7Vh+kI9LEKTAi5lU+sTFJ4xPTlRqxUVzTOTtcuthXvxw 1flD7bKwQ63j8UDNDLcc27QsxkJyX/i7fJN4juUYVgmarEyfmW7ahuVTBLdwyQk0x8+eM+f+Pzy2 cxBPhqRst9O/a3d712zU3objtVo+RLO+58AlN/Ui6hfvaj7BG5o60f1SpWJYmE6TjqM6eNAmGknn H0rt8xnOqelBdjVuewTGRICZcLJcmpj0TMu00E3SbJzyMF6E27g/mikbOlPbnvVfdCmHsOGUC2po dpNaLSvlskwR85YtkrtO2P53f226rtQQZcpTJioexbBEyNlzIL76dD3o2vsOjp3dw3+cHo6LMnns UAH8zadkAQwABoBbRITaGUmzv8YD86gXNi5pyNfLU+BXWAk05YalxXrxIwBPp3w6QMidmz7w2DBq ulOHn9csfqxLBR+OK0/f/Ks6jTji3KKHQiAHDlPMFDnutisvrid9/eKB5750/1PTOFT3oWGHovrA RQ5iUpCW3daQfN2Ayqvxe6bbyl/OqKrGYy92/+L5XU8Ov0rNiCpXwUiCWaEl0aEZT+C8aNwWJY/h ME4MGnMFwi3B1B1BC2r16KHKR5L2bftgbBg2QBrGLi5x7nRyKhIQ85GQS11hHgZNM2Doa0pV4sJh lCUFgOEghUFGAOPGgjkDww3Q41gVpdgUa4iH4z1DvZpRA1SzHUXVtMnsRCIaTyUyjalMVGbSsagB htbzFV3Nl4sDE4OaoTquJ4tyV+tcSZBYjlYUdSQ7li9l+wYPRMKRzo72tkRy0ewXXPRxigFPIeqR +eCCEHVXGH6IvvgHl5GggG5aKOAP/95lsoL08EVON81AWgZ7BeUAH0gEaTTLwKvq0iMFJZ3wK1Uz Nzb+4B2/eu/VV6LwuYOy7xAgEqRrqUBDAFXH+p6d2vc04Zl0uGtv957WiprBWC/oYIMqPz0XOfvg Ooi0o5j1ubGlG1ouV1D8mkEVFTMRbXEsy8c5wNWgQRm3/imLpEJhzVuVqWEOIaEemG7Nce3JPN0S x4qTEZZb8smvja9/qDA4BRxKakq7Q2NAYGDG4ktRnyLlZStJ4h3G6KN7dr0bo030Llj4SB0n6vTi ksUPdm74/C/7+Y/0nvW5U1/eMHX6LXuSC0KowD7CqZtz7UHERT41zgOifOO8Ox4bRtWRWKAbdt0L LT/f1Zi1iCjjX7Xy3opx5WsWP+6vvfGDV3d8TcdI4gIPawB+AFGe/OI19cD++s37tg+M1nOCf7V9 H2DSfeu3An1pb0oAj1m358C156486D3bhZqtfepn99SJyw233V8nKwBCV970yyP+9Ey3lb+Qsbdv 8tZHX/7lnj7Deo3ZGyXwHsugTlqi5HCsBz+ejTEMwgldxQBagLgcrL0LivCQkJWHxLUcGyUZe8FK y8YJigAzHZWCru+oZxSa5geFkzC3tVHPD1S0R1AkbdnmaG64pbFDFiXbcgxLhYmy5biBPiMPlAI2 BFwpa+WoFD118Sn7h3vHc0N1R5BhGeNTE7niVP9oXzqWyaQyTYkMmm0ZajQcTcYTJE6GBZmmCAY+ lY/ni3mRFZZ2LRocD/ePH6jWqoPDQwLZAJeCouGQxqFIin+oGsSr4whaMz15P1g04luIa9G2xfxR yArHMbpmvOK78JFgAWFbwAKJQD4A4wSuBufpWATDF0dGekZHm+d0LT39NEB9z3MIgkGRErvqEqH9 L9xVyeUc0wB64ntTSrVKuiiRAW6si+EeiagiAJFBYhzDOEoFr/s+PU/EiJhMkQxnurWi5dMUU66V LQpdJMfxKjqFKc5JsThdKBE+CkYTcJXgCaoZQlTihyfnfvivSV7IbXm+ahotc1rIZLK4pdclCUoO E4JAZ9KGIDe3vcNz27cjj3+cI0z7v7pga335prX/ddPag+sPry/ZdE33R3//kXNbSvdd9Wv49WNP nACAMV3eiB1WHQkoctXKVx3/9Yofh1TiDRHl8MRfhBlfvWb7/qFT//mnACHTqWKrl8+fdmc99qUB AJUbH3vufauXAVkBaJkOqwCbqUdc6qlfACTfe+ZFQB1YBhA6POG4Pma6rfx/P+55asf3n9q8I1c4 1pwYKAJJoWAsFUh41b1XvOJyAsIP+JEkN3B8IaF71EDFCTxhLoKToFUXHiicBEbYxUOia7te0BgR s1yHJEhAC7BxKGMV5thB4AVVEfre6MRQe3NHIhbN5T3Hc3WrpFsGZShBUAOnSIphmKpepVnqpPmL GtPp7d07HcsgSQpMIRh3p+bomjY+NToaTTemG5saGliamyoXx7Pj+wf3welIgpyKp0iczhWyEie0 NjZqljJVmgK6MzxZGM9F2lrKmJ+f1m8MQBA7rCv8Ie/XYQP1ibFs1rKBrFDvNlmhKSQxaZl+YPph jeu4NI1bCMZR1ArOjyT8wbGsJXqhdCMhxnFs9Pf/9qPWBYuBfXguXFQgoZRhejue/JlaHKOElnxu Mp+fSDbzAkfA3XRsX1dRJgXDEoaNmIoHiCJKeERnPCLG0Ww84XsdS6Jxg0rxUicvyZIcZfhYY/Ny uPc01zi7ZVFU98LtsxxbJ2CCLAh2U4cYiqNpSCKxpHP28g//zeDLj1uNTckPXcbFUq4ghdIN6PQ4 1kg0E7H0+OQ7H/x4y/L4xznOz9jfP/e5et7X642yJq/9Px8F5vHgi+kljWedMWddf414m923Rovt b7jN0eWKKFIykT+cu7ym/wpwZdnXb7n+/NPPWjYvIgs7eoZ+/8KOafGVy1ei/LM7HnoO6A5gDyzf +/KuGQv7lzY+9P27f98z+Ma2SzNQjB3JRjn1qDvqLgzownKIvsAaWQ6iJjh2qDMh2BPcdYMU3MAK B6oiSGgS/pM4A3Uf8XxUgudjtgPTWaTU4sO02LbqUowMTdMEbdv2yMTw7Oa5mXg6W8zzjFCo5vXA 7+Kipiw4ywDZYKtqlaHZTDL1nlPO2n2gZ2S8P5BawWwgDb5tu+6IOVKsFCZyk22ZlkxDmvRbGuMN FVWdKIxv2bdFYMWWhmbH9xVVyyQyjmsrmlqtqXDiwMaAjOG4GyDHwQL2ekylDi3+q3UO671OLPtg ZIV8l8lK4EUMOBSqukS4ZzooM6vmuo5lUxRDAMnAsdPmNjR0hDIxj+dDkWRKLxcf3zS6fK7s+Bqg TlW1q5MjWGSWKHcaFh5bEEkQwDrCidmnMFN5i6QNXiQWnkQAnrR04uEUSjhLNbiJAbxcph2Xjyfm n3358w+s6+pqOKUzS7OuL8WzoxMqU85mNRFvsovDctmTO5rY5zc1nH+GVygO79gUn6pVhibZs5em lq8e7d714mPrk7M7ejZtmptqirY1qxueh+tNN6bZXE6PJlONTe/4pfuPj1z6htuc9f3/Osa7n+hS P7R432u+tbBpa5g/Ulb56J6PEaF2ckr/x3N/++uX10Z41DLZ/sq//xG+9vVU49d864Ig+nKMAbiC ZL6OkhHD6rWNh8obGz554+vypFdn4s2M/9+CKMcXqqRIEs2DiUDCi6F9BrnCUMjE0j2aBxKDgiUk iTkH9agOiXlYGNoQ6UkijoKCLh5KH0KSuMR0SupB44ikqg46l+reMJQfBpNo0zL7xg7MbZmXjqUm Co7IyYpeg/fdQLfW03WAJN3QVV0fmhiKR+JdLV2dTS1b9mxTURN7yTRRC17b9ypKTdW1fHkqlU8v nL2wWq5N5CZwgljQuVC3tMHxIUWtAWvpaGqLhmES7SlabWwqdOfjXU0N5GV/j8T7p+HkEGXBD6UU HwSUQx8FyIprmFYAeO8uWTFNO2hc7+GHTs72UfcbhiR1UyNpHkfNcPztO/tXNkm+46pFS5YZfbxP 7v3ShLVGGX181rIrCS5d2P/M5MD+ob6pBSefMrrvSbg7TbPPVKf66E1DIi5E5s/yH95OWp75wVOw ezdRwFouXVp9bq9WMVQKF5rjymQ127O7c1YT6z9Fe7bLXRr39wnkuOLwmDWXwov8FGJD7KRqP/CM HedJSfb2j3OWy3fOTq1e+9NrrsjEowsbM+2f+mxj8+x92zb1bd/qlUoNgqAOT+3ZO3BW+p13mLyh muTQeOHYG7y3a/j4Re9fs+fje+5e+9mFUwAtZZP+1KOr7rysCGsWhJy9VQrWf2r1r9/C52qODYZp v2Ljf7ZGZ6ZI5f+VMVntHK+iGcCy5qfeeS+L4+CmSZgewVC+wLs0BazFY3igFwhIKBb5uDjWr+qo iOGQXoiPxPApzLOC+LyHkngdL6jHBrIisKWqgaoJAzONalZwol7EV7ePwFGQRBgqTvRqanUoO9je 0NmUbiLzJDAJw9JRUzAU/PdsxwaaEpUjpVo5m58sVUqNqYZTTlherin9I31AFuBocATAIThiTVV0 U88XpzpaOjvb2uDXSq2q6koilmhNN7s+4Tg+SzGxcBwA5icP0kC2BvJs5JF717z3w9NEpJ4JVk8r qJdDHgIVYjq+YgJZMS0kSvyukRXDsHKFomFZ06lfCGt9XNf0SChUrpXEsGhbZjoS4ly9u1/T9myO 8e0rLjl59hmmo40VLHVibFCv3ugSc2oq13+ge2hCSOY109AAFGOGmR0fyJgeRbgchXu2R5lBcT3M HnwgqgxtOBQwORJ3lFq5KDOYzrIwh/AizecXrShDjHCNpynqQNFRW+WwbGtsoI3m1nRyaQs/WCQD EhU95YL+h3491jfQ1dkmcIzU3NKxdMXewRF/yfKTVi6PxDN6tdheKobimT/+N2rnG1H41sjk8R/t 6J6PwE76a0SQGYwd0rdfFlTLoyc2ULZ/i+OvO7Rbe8Q/TzslsszFq5fO2Os/Q/x4aezk3YXUtmLk mRJfc44Iyx0U+7kkqXZK2pJYfkXj3q7US28LVPBAnINiPMfGNZfkWOS4J0lP1Sh9Cgt5DsdhAAqo jqGeLOwFuVDuIW9YMKcPhPEx1K3Lw6MyW64hxXsCSTr6qJthkLZEBGqMNKqxJ11U+4i08V3fmyqj vN6onGBoOhFOF2o5H0VtMMu2Ldu0UGkMHgtHi5WSaRmDY4PjufHGdPP8WfNEBsX589Xizt6tQcGl jzKWHbe7f39IkHGCEnghKkXA+qNWYah6AzniXMer1Cp6Vg+ICFGu1U5adY4cSR1RrVL/bIe4C3GY W8xzXF+3LcZ8t8iKqur5UgUAlTiEKPCfohsyz2imlohFRiaMZIosFYqJREqWhRGLmJVmRIzmODsk uhrW3gymPkt5nqHpOV5YBLOCmgYXE68ZLEPoDpIw8Gjbh/tAUEHtqsj45KGqOoZBipUYRousr6vb nny2KUGEQpTomFbxIZe5WpCbbNfjxLg/WaCrJutgNI6Szh0Nw+SwPTVieljo/WvoVMuWX/8flMYW kj1JliPxSrk80j8wOT7pOg5J0anmhqWnneNjf4J599HiLkeMY8dLjhhH93ycLkDBgvoVIDFDFam+ 5VUr7307Z37jBb9+Of/n2KELEOXBz31kpu3jn89QzNDT/e/94Z75GyvHVQf2wJSIwc9AEtsyv41f +5HW3N8seTAT6n8roEJRvuNiSo3iWI+mfUF0gUjIETeacMplQlNwlvZRBqmP1yXYPZjz4yjK4jhB xq1bF9BFyWAkiRYyMbpvDJlvkiRYjuF5ESbZDMuZlukj8RPCO2SqEYkJikiKtRLL8aVKmSSoeDiV LY4FXRdR9YTreXqgsBIPR1H1toc0XQZH+0cnR6KhSDrW0JDILKNX7OzdYVsolQtQQwcY83FUBPOK fjxe7yhMHMxJCyTu5XAsFrZs/9vXf/36b90YimUOa47lH9RHqav3IjjxDwuuAHqhuIr5LkRWaoqa L5adQOqmXn1ZhzPTcgB0K1WLJHFVN2gSr+lmPBSOhoWNTUvbi3c3Nfp8/Eyr8JKLrRT4eLrpxFrh uWqlJsTCqslQhInKQX3G9TS4RKgTGCq0J3CaIQhMvnCREk/CPSU8DKdItiEpjRdsGUBFK4wML2kn WJbCADyQIhzOxs8xxvo9MlLK9scKDh1UIjmoARpmCxJqIsbi0Y9+vbzx4eFcIUTTUizKZprlWMK0 DaS3RpGiJAIdgqeld+9LDS3zsIbGP/L3bdvwsfSR6nXyxz+O7vkYZ1Ee/eLmzfVmKkBi6pX2bxNR 0EPLK49edftn7r/6N0Pcn4/9Wt3e8sNrL5+pUPnzGc/0X3rFhlOmScm5begrtrNUq5rm6RnkovTN oujmp7e3CcHmmvOGuT1bgI1h4dvd9Le7/+6f5o59dsUdEvvmtFkp00AmNyw7AufaDlEsMhzvRi2L I7FE2quWUbwEZRh7qJ7Rq9OUoHIjKG4I6h/r6iyBeKFlY5kIFhTVww9qO0zSZCrVIPNhoCaGi3rX l0olVdOQcjCQnSD/GKwn8I+utvn9Y31WxUrIqUINia/UkQC2BJwAWIiHE6VayQlKGoHGTBWnCuXi 4Hh/U7r11MWrssXs4MSgaagAPCTJtDdlYDPTtqtKWdMVYCiIKdGsLEhhMUzRpKrX8vkphmEcy3ri oftrVeXEFSefePIZ03zlkEOsXuOJHxLiwuqRFd0039nIChwdEKVQqjjuQZHaQ76vQJsM/SM9VFSC o7QJpLHm8SwuCdSegieGaEUZERlH1wA/nqoNTmkmPzBA1zQyHBIcMilIKk2zVdV1bUoqmpM1jsL1 hGJFPZdOoj4ADI7zjR5uYYrvUeUi3EImLFZ1PSyR6bRJovwwdC1IiielOUZ5AyWcWCvv6DQJPilQ us6EOEwxYPYBwJX65NUuiY898PuK4zRydGzOIniA5FCkMDiQbgwtPfnKptZO0zYFSUpk2sKhP4EX fvPk1DHe7Qy9icLJY/R8vHPTB54ZRgttYaXuBHtHBuDKrz70k38ttg8XW9992zTrm9tQZf7Xzznt PScteM1tFs9tnSEof1bjK09/8UcDrxSrAkg8fP1VsPDvd6Ew4XUfRELX6x+++YzwKwkXm/SfnXru VTXVmH/9L2DjJ17svigoSPp2d9MTk//wwCX/Jr8pUBF4z7KIco0yLSKTNBNJu1SmRkf4TKMZ5bxQ BHNMJGuPJNFRlSAKwhNEkF4c1Ng7iGrgloWmsVag196SsIOKFh/sOExHwcQPj42Q5IQkSTzHAzLF 40lFHzFtp94/EbW7olAP+VItv6B9Xu/YgZqhNCXaDMtU9LJh6jZwJ8fWEfoRYUlWDbDnhh9Akes6 NbXWPbBvcHwgGU3Oa50L68tqrVQtDo0PoCg3QQqcuHDOQp7mfYR5lqoZJaWgG6rIibKIrpWiavf9 4QmKpodHxxafdCoZhGqmE4vrWILksTDiMKTxTcs6GFkJOku+zQEwXKnAadcAQafhZDq92TIMAFGa 5lEBUF3sEsMYEjXlInk+tH1jra0xTBckDqt6aZaaYJl+gzi3qdEVRcUQib6BcRwYiu0OTHoiSzXb GC8IJdLaiTuZmGClKLLS42FNXpLAbR+TeF/wKIng5zfBVe1oJcIpuO8m6tJmYh5JE2zcKI/r8iLa tAWX51rC5khWSkpGzcBoDm+PiedfWdv6WHayaOK4IEtsKu3YHstLuq7pmqrrKsNJBIXznIDjpCD+ CSIEo6XysQIqIe34D/WaPR/PnLX8nHvO+PmuxrqsfVgw6oqT7+BHaI4Nws+7epUqunT1o8vqrq3r /vqCGeT4f2JsHT3ncERBoNJ1cPIREdgrzj6hvrxub74c/eAl8+6arHbc133e/JORyIIscjdftAoW Nux7pQJpY4W75eVrvvHe0Tfn/hIElLLlOHilBhbej0VtivGzWZYgrGjGwyyM5QJVSAKre64CJxjy gwHAoA4rAdiAGUSyLD7WmlCDZRw2Liuq7VYBP8BoijWwMBJOEBzDZZKpQrGEUo0xD8CjVqo5jg24 MpnPijwvC2GAMFkWIyGJwCjHc6paeSI/aQQOLoai8cCmHyz0D9xkhqGNTAyNTg5TFC3ycjwUa062 wGao+N+1eof7Al+aRxIUYAwwlXQ0BVhhOLpt257vVKoVnuX6B8fu+MlNaz/wIZhBY9h0zcorosWH /GnoB/nZLJMx34ECexext0pFUf1DLbnww6gKgHPPrs0FAM9qBSzywC5Wt5xezjAcz6Nwj3AxXXHj bSEAGScXabtCZN6rjn3XxWXkqMR8lhdZLoy5GkFhmkXA5XGphM8ZYqSzjyxuw9iJlpDAY11pefzE Btw3GxvlxT9Y5WLxaqnCPmzPma2zYsS2qkjUwCT8aEb/v+x9B5wkZ3Vn5dhVnXume3LY2TSbkHa1 CEnoRBLoEAjbYIwTCBtsjG3ss8/Y3OHzGYdzDvjANvbZgAGBMYhgGyEkEBJKK20Os7uTY0/n7srp 3vuqZ7QSUfrZCNn9qdXbVV1d9XWY9//+L/xf+ZxpMDYfJD2Ochi+mLEeXzRWWqzKuu1m31ve7py8 15o5Nb9aZiM6OzQUuU6iNOC5DnxH+UL/4Mg45pp7NstmKBp+ftx3+a/uvkfPf+sDrh1Z+M7P9g17 Pu4bfLT8jif1Uynve47ZJkCUmz90e1xr+cs3Hu0hynNlPLg6+ZQ9L9jTrXgFRAHYgAfnZjd+67z+ R9PIngFR3nF6fO6Huq962dGdcP8vl55U1nrXevbXqKcDKh2TVSNaEgJJClgVSxlrNT7f546O24ZB 2wbFc5QgBPD3T1xaJHsYy+8wq5hmux4wABXU76Bp14lEkerPKq22Y9iu6cLSlyIqx5RpY314HO7G mnBYLYuyJutrnbVcKq9IMnCRltFqGUalXkOtMFQ4joA3yKKS1FIjpVFJEOLgOZwQVQ09BwZgEtZC kgjPViAk6tgdx3cENPiCJIt7xnfrssZzpBdkGGJEJPSAAEWeiF2NHbfdMtp0Ox2k77nvkfn55V96 17u1VO4KQbCo23rxCU8VQileGG6Oy3HyM+Yqvh/UG61mp3NFghyR6owxjWHSSf2WV//A3V9+IFso rq/M792969GTZxotY3l5FsCatc0X5szm6kbyqj6vc9nnn1/bPBM5AtAtVF1hmEDcK4n3cYGlK8yY 4PORy/tOELJGJIaJ9FKZOXaW03VNKEpfvNeSOOf57Mb0gZLCblDK/uHSg7l+i5H20l4FvnHHYoTc tH3uAwAqnkoVKNHruEwmG26cRWHkYV3esUfcc2TpZ18X7N9fpymRojJjY6ICHJGFD6q2uVHZXN9/ 9RGgiQInYs0SJ373/+oW1r9NPvHegcf+kxumBy7dABwlRpTpvsKv3f6qnrF+7o5r9o20DRvgBG7x g6+dQY57pIgCPB9fLhV0baCQBKTZPd4XH3N840l/IzkheHoxFcuiMWBLYYheEMLAo2UZ6xRdJ5Bl 9PvAClfTsfMh0e3tvgzRJYzX8BhgAeCJnUACKoNQ+0eUL52w7ZBKlEYbS5e76/EgUJVEPpfXNU2R REEUGJrzPb9QzAZRSIe0JEooPEljz8m21dls1WuNmocZXUHTaDaMBoZfsLwcrwicA0MkgBmClNJg ra1oioqtOWQRX0+a/gJKWYbd6rRNw6zVa6gvSabhB2CNfewPBlgU+HBSWC/n0lmYQEpPagnl7s9+ 7Pk33tw3OBFFsdcrutIjtU1fAKIsxwHgEkXhmUVWAJYAUdqm2XWrbeFYfA+fBiAKMDbYkNgQmMlm tQk40zGsG689Sj1IH7r66g988OPC4I4Ee973LhqNdpvKaOGsFe0OaQ6gu9OmA+Fkp9PpkwFDnX2R r5vONdJSJ+V3PLvulqlEf4d2JC/M+rX9VCcMnP3j2YGr3lp57J2+p2QzZVGWAzYb2XWOpxhW5uRU e/OM69GUF6YDLogc7MMSYO5Y1JfUX/ia6if+wrpUiXa6KFjMCUq+YHtuStUMowOfUn9pWFX1trGR UBKkOor77v+NfWsRF5Gl/uqB2/7TGqDFlvL5FXlbDAYQ5d7fenvPLj+Hxmt23fXucz/xlBD9g6cW XkIoSPzgHtLCbvl0enbmdQ80pLcews4d//wItiACXIFjnnLOt02foKinYd84UQA2QNkOY5msogTJ pO/YjOsxnId8RNQwCK8oPmmeErtkiN4XTZrSsyhaLAqkd3AUeT4AA6pMHhpzH3UOlG99a+HT7w8a ZZEXs+lMXz4ryzJLGjECaUChehbTi8GuA4MBW49dbEPK6Jg1QBDDUBRloK9P4kVADo7lBZF1HE+W GAFF11nSj5gnjW/h3TKe6/EM7zq+ZdtN4DudtmM7HbtluxbQGJI1gPaaSMYQZMIdUVxamFD1fDYL lwOYWV1bm19cvP/hE5//1/sOX7Xv5ld939DY7m5PX1K7iU7Abm4xwqqDRAVjK88gDcx2vGq9YVoW ta0J00UURC34hNKppKbK2y4y4F2xDw7QEAHJsViGXt+sfy7IyLliGM34Xsgmsjy7Owwe4rSEIyWS qXSHCweHBuzyhfKGsV9T2m1DgTeTze95/TvKv/22FuvyndbURNGibc7x11lKAgq69s9mw3Lal5SE C7gQMBrHzGL/Lm1/2Jx1LRumnPNDxkGdBVRiIB5B8fDRwDFqH/ssnVObmzXLC3VJSQ2NMZKs6clq rdrYLI/t2IE93KhQEGWWE777vi8Y917+Vt4tJ6De+Wi+Z5tg/K+X3dDjKM+50a/P3v/yf3rlF29d sDCvfTKTfOjUwmeOzeiqdP/ZhZQiwuan51ZeGtTT96wuZPso8mOHnR89ebFhOrcYU3DwlSe849rH bxz/NKDV0wAVsAg8B1QDq9gbdd736EzW4wEbXNr3acaJBAHr6qktGV/CUTAzmJAPElMJ45U8Jok5 Dm2x+bP2wKUf/sXRY18oOMbY1JQsiawgcDwPrxJEnhN4lsGwP6BK6GMFjMRLhm2iKC9KtAS6kkhr qc167ezMBbBBLDISDmgEvBIjDBEWm+DlOFYWVVVWeF70Mc5DB15o+7btWZZluj7RiOmCR7eYn2yE cTBckpRcOqerOmCM5RiNZj3OHZaB7UiS7YUPHTt75vz8yHDfxI4d+aGxhCSOTe5KJNJUN7SE+clg 623Xk1zv6aaBWZZTbTQBAqPtZIC4HIYM+LAy6aSiPJE2KvK0SBJ7URgNJQpoluNCbNVI2bnhneO1 wHDC0Ir8eqtxCcA2cE2GFzqdRqB0OJqq1J1SvZ3RJAH2GxaVoJof+zN3puXvCrXRvvz1t9QDm5Mo 2aVDO1g7/kG7ZYbMmCDAh2VgM2h/FbCbz1xlrT8CX5ntUnpA8TyPGYAcfg7hSJK75U2V9/9G2LS1 A1Nnl8oSxydURc5mW20joenLy/MWfi0W/HaAspCOarAEeRZEbc+XKz3T882GKgpXF/tuu2rvK69/ 3kip127rOTmmCg8f+77zf3/i9e8+N/q+x8/BDXbG99vjC2z6C7teHT/ePub4RvV37n+iQuvnxjbf cfUnn0GpCheE3YRZUQjBiMA6stNi9bQviBFZEGNHYV33icYwsBASlmfiJiNY/0iIB0IL3PteFCi5 fzg53PKpA//0J/TKggw2X2BkGXAJKypVSZRVOcK+hFio6Adg9CM/wD72WkqhO8zmZmW9DIvvKjCf jJ7ZO7Fno1ZZWV9wXKpjdMgc0M3GsN0Z0LSB8MZgAQosewFwCJAE29qQMYUiVZbYuDjCNsNMNlXo y/aLHNfsNGDVLXCCriaJJBkLj+ETsEd2RsmU3KpyAnsxO3RPkFVn2mJr2b1gvEANnldKT++Y0LQ0 SmiGjO26NnGCsSxDfwd5YBHmm1m1etONRdOoJ3KHY6oCpjaTSkrSk+IN0/sOPHzs0UJfjngIUR6H pYNyyxnPcz+W8+yFi6WbfiCdL65X7YAfDOA5WvNUYHVGuy3rWiKVzkquHbCCzlG04+vXHCrsPVi/ 62GgWtmmxTQqkcjowBp5yqpZ2itvN7/8p1yKSeauiyLT5YZZy4TVBpOc9pY+YrTciNVEzwssD1P+ XJfmaPltP2Vdesz44iPwhWp7pldPfEaJqFSp4NmdzNAI8MNWo57J5UqDQwzLua5DYwFsxD4bTOXz v/DGb/HscCnfM6a98VwfCbH100fe/6MHsP7xcwtjn9zQv66Q/puOV+aNVw8vvmj8K8+s8pH47bFN IkqtuA6jyD5QCNtmZTcEE439VCJEDlUhHiCa1KMQfWIKO3pR6EkPcb+H61bK96m13HV12XCOP7gC RiQhsVSUy6ZYXpAVWP2LPrYfDhhShiiKfAwRjoUSjVHEaDqgz8DwYKnRaV24OLuGTVA2i4XiwX0H z5w/65LaSeKxQq1jDluA0cSsByh8idF7EnIh/q2I2m4g1uUmsacrn+7rzxTdwK03K5IoptUcWHBJ FsAshkHoeh4bIGIKyzNRReK0pL/ZUFl6MHKbol4d3rGzvdY59uBDp/nT94mFQr40MJDJ96czuaiv KH5nfVZgSh3DxIJ5L5ZgIUl1V0CLIsvplB4Ln1w5kqn08w4eKFcq9z/ytb7hoaW1jWQiMb9mzK80 T6sy2+hsVjYz0fmMOtFY/JCk5tnEtGGeYLWiqhUn9iamdg4P9Q1IAiBKpy4q8CWYD3/JefH1TUVP JtSNL91rH5i0zMDHLOUw13+Nmd9pOG2zvaYkOFbpS2SKZicM2ICyL1oGRbMqXat7LZcTGadjy9dN 0odeZP7jnwO9C7CLZ8gklIRtpIsFYG/403KdRq1ar1bgMzLMjiIrJIb07GhYfVtlsN7ojf8w0HLr 7o/eupt6P0XNlI+sdopnK6iKdM/6kwT3DmUaKcEZ1JqD2ua/iRQYF9duhyG2fbQdWpIw0ynEskUK bAjD45++JFO8SDlmHJaP3TVUXIAdWwbgK55HV6Zf9/vSDc7EpaRDSbOnrfrayGC/qqmiLFNwMoxH 0CIbO2/wNAApcB5ZZUVsBAZ4EAQK3gsKn06m2s2dl5bml5YXq/XK1PhUubpZ3lzfZh0h6T3JEPGX rmMujkkQBXvEkCDujELFzi49kerP9flesF5fA6M2UBjUErCYjhzHadttx3VQaQQV/IGuCTwYdfTy mBS8r7kLIjUzwHMlSTNr9arMKQnJMJx605xbWBV4TpIEuCmKnM/nC/BfrgBLcjWhp9MZTU+x3BPw ANDW7hi1Rsv1PbqbnkzH045BRZUkQBTh6xAlHtlsAW7DQ6PlSm21UhdTmc7MyZtvunrukRlBTs7M VqfGj7Ksb/sK49F+s0azsmlY1ea5lVmWNtfoB+66ZndReOy4WtSMwy/NVS80aE8em6YE0xN0auyQ UtrNw6daHDx7et4SX94xneVmf5bT6IBlxReG7Exr+RFBanCikM0nrUfXXM8XhzSr0cz93K9Wvvgx f3PTcAJB5lqtRrVjDzCsWsg2qhu7dh2ybQOWEJl8QVa0RrsjCJxptNJZvfdn3xu98V3ziU0VqBvH 8fFP/ztfi3N9WghIxhV2KqFDH+UfXZfmeTrksBU58XdhvMS1aTrEcD1pQYvyX3YQiSI2WWE56vLB N/9JM0Od+zJlMc3+USrX//LGuWRCpkkzYVjHx74OkrLFY5OVICSRc9LOqyuOQsXBDwzmC1Eqq12d 3Te9c+ri3MLFuUuFXH7v1L7zl88FRDSsezCDeBgLIcfg4QXE90VF22dT5ERfps8Pg3K1LAjiYN9g KqXZprtUXmmgYABm8CYUVZVVYAkAELHePAvmGT6LkMi60JFP+XTQUGQWiJltO5ZpIy8ROLiZNi/L ook5At5mpabIi6IErAyoCwfHpFKpUrFUHBzJ5vqbLczP6hbMb7m8mG7qMJtQkKN828AMnBtmO9IP wFPYMT4BIHzgQKtcXk+qQFdqopww5RuTQ3sBvL3li4nskNiqb7bmRieOylZTWD8fahIqTzs051jq /AUrPZa490vtFu3fZi3feZcK3O3tPyOK5325oUu7ReWIyKWNtrHQPNxs73Z9TqBvF64SWI+zUyuc 5QSazKsprjQx89u/LiuCB9+FEy5t1kUvkBhe6etzOFFkaatVu3D61ODgYLu+yYkqywksTet6D1R6 ozf+Aw4u9LFaXFICniMyjg4tykA7GCAEgDSAJR6pkwcG026SNOI4XB9RsfvJ91HJ+FJZ+uuLHtWZ oR0vsiKAqufb5QyHBlkGI5hIYM8WQiKIrCQDliYMIs/32SjWmqdcbLwSV5lQcZMuNwQbFUqyuHfX 5NjQ4GOnTq1sLE/v2nv+8kXHNrdi7wHLABngsCcwy4C95jkeHVhYnBgCmGWSWUWUN2obcK3+bHG4 WGp0msfPnWwbHWAJmWQ6lUwVkjlO4EImJPLLhD4gjESACgzPEtEvdI45rgdgF2DpDFwS3W+Mj0pm NBVYoYvECeXRaEwkCEKgRMB4XDew7M1qrXF+5mJK1wbHd4FJ7RajkPdJ+hjTcCY9oaaSGrr0vt2A gwH7PN/DPl3wLXC8nsxoybTr2J12QlES2RHW8rzACUN1aH2jrGVKuw+qsgTfw0SDppTrGN+twrzq y5c9h2cEoR3RbZECppUeKrCTO6jEULteFBQ98INOZbPlViyXXX/kc7m8Xpg4unz8WL9u6KM/UP/t L4g6H96wXykOeaajvfzWRr0R7thnWJbHslPXAlvy5zaqXNOyDlkbSxdb1WrUX5BkJYRvH5gv/az1 nf3qNyl+HCrmRgZyCyuVpbWnRvL37RxOakqzbZ4iuZiw2WiZX3/YNxzxa6+86JV74AFsPmVKSVJp eN/x8/snhq/rOet64zkHKnoCF/gdA6wn6a2C+k5RQvVFIVQSfly07rsUxu19Oq6lRyKAAXYMB6De V8Dee9ZNn7pjY+8BSk0Ba+DHd2QeOq309+nJJMfzqO4VYitDsJ/Ig0igHl4Z29A4FkIK3kMABjDl JG8rgB1x1AEsr6JI111zZHZx8dLlS1PDU2ubq/VWjaQgd7O7sFaEF+KJYSgbgYaXBcVwjPm1BZEX J4d2cCxzcuZ0o11nGK6Y7y/liwlVRbUXokBGyBdFVHsjDqw9D3ARusDjsHEypiIj2LA0L3LAQhAj Q8q0bNZlRE6QRImJGIscQpNSGEkCQuX7AvAVHmHGj6p+o2McGxgZz+QHqS2Ny4iARFJLJJMJ5Gff 2ZAl0Qa6hD2c6XCrD7IoyoJYAtTPl7RuPRGhXJ7nAQavLc3JaiZx1cus5uGZ6rrnGvPJlMKx+uAu W8sD4aLHpqXiXj2bY2TN2FzqVDeUbNFtV5REWkxm+255M8PxtXpr5AW3B53NusOUbz5Uqq3nXvUj C7bENDaY9GDoJaIE5jtHjhmJVsdsb641aba1+dGPwFRYQa237YvnzozunHZsR5CeHVABVLjjK4+m SXPcfdoJu3H6Zx8cfdNY62Bf7X9ePPi3v/TT7/yj33jF2PJfnho8UjBhZ/yqv72j8JpbfvKv//kL 3zf08EJTX9v8kWTtA+WG/c2uAueE+z89Og8HL2y8ef/k8Kfu/P0rz/a65w+VV4/BYQfypT99y2uv fDZ+Obz2lvHjizPDt9+x66YX/vAbbrmuZ6p641uMs5fX90z0f6+ACiyxwZimMh4vhAwdqYlAlkNR Ci2TNdq0xsFiGFOHeexUzxIPE5pfH0CC0BSKjRpyvmOtOlYzcd+9TKbQfNEt3vNuSs7cq2mJuDW9 LAoU8XRhZhbJ6KVp7C2MvYGjAEsmkccAhPiu66GR93zSehh7ENuOEwceYP/o0EBS0x47cXxyZBJO 3mjWZZhoGJmOARCiyKosytgcmeEp0jB9dWO13qyn9fRw//ByeblS3wQDXMj0jw2MwMKcpZHZwHm9 0IeLkemw5FIRau43bTdwScUPUBGsQ5QUEa4Cb6JWbcA8E4oKe4Cd+FHoRihTDxBrmlhQIgoiJsJJ oeCHvuDH/jpsfhlFi7MXXbtTGtkd+76AkMWIwjwd+TD4bGRZBswivZljBx1Jt9jSvozrQ2OIRUkC VR+d2henwUlaRh+YsI12PV2sVTaWN1phk1599GFaeLyoq4NX7Vesx4LQ7i8OOEYzK6nAuXyGrW4s +56tF8co1+CTgyzNjr/qhyttV8uPV9/3rnB5cWD/Pu0rx5hsMvmylzBTOzdXW4yQzO2YcpwAIKRW 3mi1OqIkmDZQvkBWVE1Pffd/67/1N592XP833nzb8XPzN16zd/OBD+a4T//k3W991a5L101+GQ74 /v/9u3f94P9LKu2/PPX2eOdXL70Q7t9wmBp9X/I9V118w+F/gsN+79FDPzTx4JGBChy5UBkZyS0s VseScncTfgf1r4x98Ia5+OC33HNjKqE85Wzw4A2HvwyXPnLN8OJ6ZftZOL5pq/e+5svD6Qv3z94w lN64bddSqtf5qje+5fj43Sdu/8d7Wn/x898roFKtoDlrNMRsJigUHFUJWB4D9bDC5nniYiK6LPAY I9kRCkp6fhRwsCCPrT0l0EGg6LTdALsa1DbVXB8FdnJ0KupUgHaA+TZtz3b9WN6YrKrpkBS10wyY dT9WWMFCSDbCwhXbif1aluXAkZIkgMX3YIfrMwydTaaOPu/IYyePl/IlVVDXqquakoAFO0oaU1Em kQVo8Hyv2q6sLC07rpPP9MmSdPLiSbDsmVR+YmBUVxMAHgAm2F0lwtC8KGEdJqCd43uWhW2skLf4 mFZAEnxFQeHhrZuG1e5sGnaH41ktoQMcurbLJRQkTNj9BXAWu4r5bhDwoSAgQUGBfEHwJRGQj/c5 kjsgrq+ug80HXBE4LqVrmqYyT1+QEj4WyxJ80o+Tittv0iQZjtque7lC/JJ0fibKMkSGE//xzj58 Z1LmU4pcZ9XrXv/9FsUIesbcWJ6bX2hVqq1TK1P9mnriYc62zYqVvfn64ubcykwlkVS+mpq8OWs+ eGr9wNvfcfbYI2LHmFfyMxsOM7VbcKwdYsJeNfR80Ww3Vi+dnT58oyAKH3ngPllTpqb2DE1MUwzv uFH62UgmfvDiwt+/8/aUrh7cjUwiyd53aumQxSv7SqjLAhhw/fgYAAO6nur8dOmxpql9ZX50OI0u rxHBggMAPIazc+cX5/5e+qNbCh/ar3zimg/d2pfq+8Grp6/cvD69sX2wXz9+4nL6p8afdLaDQ8fj S4/kUycuL20/C0/966L+5Td9HjbrlvSBE0fvrYlzP9CTlO+Nbzre/t7PvP/xc99jMRXsoIGxd8tm 19bldlvI5px01pMkABUsUqFIlxRJDIKA83wKlt1wDzcftdgRJ6KN8sjR58/N1DszpxPZfPngC/YJ HJVMC14LXtno2GBLYxcXaeeF96h1CIjiOz4Wt0ckA8qlyHKbFwTHQU3chKa6ttdpmSHKwLDodKIZ eHlClZ9/5PDxU6fTempkYOTSwiUeO0VGLaMVRgvwwkY7LlOP+gtFoBQLK/MJVZsoTaaTSQ4zqDGJ GWYkqxK6+7CNmGWhNwkm41Po90IBGFVVgAYFfoh5tZtrHatD2oVRGS2rKRrQFFEQaJZ2TNsIDHhH HMInis+4wLd4nxc4wbZECWP2MAfP82XMcAtip9TG2hq8fO/+I4mEQj+jzFoAWphfu+MTCWXSEHqr 3D+IlYzJYRHpTxAnLkRdoEFc4SVt5NCrXUDWwOfbtbMnHjE7TrA0K9AClc3sL2USO/fLE7trL3hZ a2PVQjW2jcsX5zuMeGiw7+COHZ07PzZq+TtqX/KG3rBgR8XT5y9EdPbwfu385f63/Gy5XL/jE3e+ QlvTXviKO/7o7YVdL0gwNQk+ZrNlNtcVvU9Wk9/9H/qHP/fV0Xym0TLhBpvLy/N76dpi/XBaiABI Tq08bx+R/GqY2lJ9B+xMKW2w7D986CsADB9+5Lb33HASnl2sD8PmhN54w8teoM7+Hpp+j/65q6d/ 9U2vqtzX3eRc7703PengL5488c7pJ872kUduez1ATr0Ax+yfGP6rz/5LahqR7Fdf/Hdw/wd/9g64 HGASuVG/9NnbYcLJnp5jb3zdaBn2i97z4RPl6vdcTGWgGHJcwNCRIEQcFyqJQNN9QUBEoUlhCs1i JJ/lKB9LC9Hl5XqRw9IcvIRIk4ginb588lLU57z41XLoholkhuVodG3RHcOliKBKFHZdNN0gCNZU hjFNiT1iW33scaDSve8rtAxPAbSAGey0rYbRZjgabD3qKsNab+/0sZPHNTUxNTZ1/vIFYq8jwAaP FD/CJQdLg612u9lqTgxOlrJFknrM+C6Yex6W+WBjLdOxbLNptBwPm7VwLC+JMjAMVVY4huvYnaWN lXqzbjlWiDF/LpVMZVOZZErnGN40zI3Nsu04rmcLophQNF3QfHR0mTwnAjwBznEOJ6HcJMCziFrI MMMn5CmZpcXFsbEJLfHMhd9FSQAo9NAFiRyF9HSOwq4uWbfmMySBolihOQ4+BcRLBjMYGp/CByi5 33A0vljqY0V9Y3UNrOLa2ZOn77oruveePf1pmldLfYPs6K7h0oAjJy/NzvBLC+3RPTXDrR5vTI1Z fa99W2T8VjjbEHixU7GW3/Pu0u++7+DE7Jl7Hzpw2F1fa5TLn2b9lWL/eH+/3rn4UF2aPnzzW777 P/SFjeovvPZlo4P5RssAsrJx+QTVoU6upG/MIDP+k68dHk/tIyzhz+6f7Y93nlp93qfPT77rpjuu Hz8OYAB7Yi/ZDaPzXz1+/ofy9983c53HcAcmhmBnVuxu3pxZjw/bPvjYhnrl2aZLqBOjS8Yv7mx+ 6s7fbzexyvWrl14Iz8KDN421mrb45k+85bZdS7dMfz4t+Sm9hyi98Q2CKC9+7ycrrc734Nw4PeW0 GrznsO0Qs4ptm7YNWpIZwBhBDHkpZHhKldEX5Pk0y1OSRKsKr2uhIFIcCewD0SmYjHX/OWF2dvTl L2rxKh0FdLNiOb7j+IAoLLFsJOWXxlTiIFbiYsDSoTAXbocoOgI0BUPsrCgKwB1m55ZSKV1TFXix qkqBHLkoJ9yBoxVV5nl+/769jx57vGMaeyf3XF6aNcw2KdEPGJYb6h9qtAAPnD1j02kN18Vx1hnY ejdwTNOqNKq2YwVUAFiiSCrsBywRBAGsf6VRqTZqnQ7m/gLSAddI6al8JpdQVSqga/Vao9kwLAOe 5VhW15OqmhBFkUI5dw/AzPMMGiXnKUEWXF+UPZQjUz0l8APXdTVdIy43mmXkxx9/9CX54pWFLE+X rACuBGYQ1+U8qbMYcVt2g/WEnFyJKNvSNdjC0jZWLj5s+NKF8nxkbrqAs7Sk2suDR/bk8n2ZwT0B zZXXlhcWlrDhzdnjCV2jpOTo/vECIwBinvvCJ3e++LXNH/3vpZn7nAfulscUyqmuf+mOa171I+dz bHnmbi2bd61TWiblepVmdR4WKP0Hh56VH3rTdI5fmJ9fKcebGxfufe0u6rKRHE8ifvBi7td+9TeX /se74PGJ9Xy8E1AhBoamlQOj/8GlH5+t1D9w05/tKz12avYUlacWmyicNNyfowwU44NNoDj/8798 4SkHjycnt88GfOVjJ5EVXT/1VbjBfuAiV14rdprFkzy1/LwN5kiPpvTGU8ZDJ+df8r5P2e7XdZMT B2n9Nf8eV6TVq54GqPg+k055ihywXCQKwBgwdkJhYQqs9ylFAeOIfbpKRffoYQEpR0jBghxYSBBQ rgusAhgM1Z/G0HqmWEi7zT5OcCm2oxWY9XU4UKDpIPRJ81rSDBLW85g55lPYhzjySBkgqkl6KChJ SiJpIBOptO56/uW5OUkQB4rFhKIAeREEThR423E3a3WYSiad2j89/dCxRwBsEooKtAQW6zzHFzL9 jVYDzrxrdGdCwEUi7PQZr2W0LNsyrA4Yd2AbsqTATRIBNcSIjlqd9tLGMjAb0vaY4llOS2jZVK6Q ywocb1j28vpqA4iLbYeofclqmpZOplVFTSWwuATeVscyDLvFYmJYhH6w0EOtSdMFWAVC5riu6ssu sDDdI722aIZpHn/sa1cdueEZf9Mwcwe5ih8rXm5FUDBmQqJfmKgXEtUa2OuHWyGVuPSGxFhSeuLI dTfV2iSLGhkNfhtts9NoVhc3Zmdm/3ljuayFXj6bKqhiYcfYV7/2kGW2xm64MZ/Ku3aHl2XHNPLj 45GsbmYLrVbDkNNq2PC/8t7xoz+5zFiHRpiFMysZscNmdsvepYcerbz9B//wWfk7TCri33zxa9ub 733bm9/4fvmyw+YY6kc/9Ru7J/fDzkt2Fh6veQmNdeBBfCRsFvkOI2h/9+s/furC4s//rZNgvFIp +wv3/OHlinnjgLiPtNGNNw/kxXfd98anHNwJ+e2zlUo7X/Nfd7zxU6OYTwhw5eGia/tZGDaf953G uFQ1AnF47PCf/kpP0rE3njQ+fveJN3zkX7/xc4Vb6cKtz/oM6TvfowtCKHCRkvBJm/pQ0QKGooCI oMAUB7hD+TbVMuiLZzQG5cojkv2FObVeQHsBZVmMYdJ/fCctDYyMHpp+4NZ3l3hWrSxN3vnnPLMt wIWxA8dBwS+wg7ABDyiGBoNIdBkjQeKJxiCsGXlSUk4DAK2vb547fwEQqC9bGBka4niWQj8VBxBd ryNslEr9l+cWZy5dUCQJ88RoWtd0jGEE/uTABM8JsijDOU3HMFwDjCzHcBQSMl7ConkeHVOuX25V 1surtm17WJYYAQIBnAz2DSSVZMRELatdrVXqzQZAEZAkmGIikcilc/lkTlEVTmQ7hgE3w+wEpO6S ZViBR9VM7OcORIcXFFkGw5HQFF1X4bVqQkloalKHmcJ1lGtfcF2xNPqMvz/DsEzLJmSEqPnHygSx 5ABJ1CZZ11TXF0YoC/GNUbFTTFWY0GuZbiKID+rKbpKumoTR+CEuA9qdulldD9bOb9baTYaLZk4V Mhk9nd115KrigWsimjOaVr1a8dnAM9eH+rIu/CpcLp0faVy+98Kj94RyLjMwajlUNpt7xfe/rWcX eqM3/s0R5XdecvTf++p/+NCZcqv97ZkKhUSBdiJa8GmbdMy12oAomOnLi6TIEau+MftL03ws8WPi FTE2tKdsFnCFEyKRonaP6OcbdpQs1kxzMpWsZEcGB6e4tYvAMAB+LNvF0pMA/V1YYghYBLiCOl64 eiaikGiCwaCzXAhHwhVgKdffnwdKcebc2eW1lUq9Njo0XMjnbMdmWS6fy5Q3KzMXLg4OD16eu2Q5 NphAsOAdowNL99HSGIWd3FngJbZvAbEAdImI4D2HMvq8JItwnvML881m0/GwZQvKkfF8Np0rpPo0 XbFde7m60mo3250OgBRRomRlSSrkC/35voSq+q5fbzfNTcO0DNu24hQsACrEYB/etIeqlzSDpZBR IAkSlktyLE2zFNG+5DlLEDnApBOPH8sXBrhn6gRDsuISPWYSOAli9yLiCfZfecLR1XV8dfPDyGas igbMkGq3q6KUjPPCiOOsG/qCNzA1nDt24nQ2XQTSFo7vHSYnYF9hOvWNi3d/+mt3/IP+4fc1d+9L pPv3HXoxz3CZTK5mUoA9504e2zM1tevAjZPpvRsL5ym3LnPBzunre3ahN3rj356jUNSv3PXg98g8 2R98CVIS4B8MQ4kiCfUChAj4gCWKITTb1WUJfEqQsISF4yIa2w+DxQSmQrctBkhCSo1mzP5Hbv05 ICBgwQWaabN89vJx0wCD79iW02oaDnp/UD4SLJaJzACLHFkGzhN6qLNPIvVMt6geK7rbViKhDA2W PD+sVDc3K5v1ZhMW+6TXVggLfSA9G+V1UVTA+oOVjCP/mWRGFAVWYC3XcAOXQVFj1vWBZwSqhNUs Las1vzK/tLrU6rRhRvAeVUUd7B+aHB4H7mC51vL6ytLacqVWNUwjbvSSy+QnRsd3DE7AAYZpopRy pVxv1lqdluM4hMEwAnYow0CRH3gxUcCCf5rFTvIsehWxJJPl8C1inT7mvwGhgfcOk83ln2HhErA7 0ssSPr/Aw7u4cjT04vZjQEBIhT8CTdD1QHb/30ouZhnPMG1RVFHfk6HxRsqIsHAHZxhEbsvF1m0q lg6xpKSHEYVEpn/ftX6qTy+kZKpdOvJ9iaRK+dTiwkJ5/tjq/NnFubmlpVkuNEYnDwr6gFrYnR8+ OD29r2caeqM3/s0R5XtqcI7DAAuBVakAtsmhMTGKxHx9lwZowQoKohpJlFowtwjlnRwwnUhQQoe2 XMZzaTegRN4rKV6tslDJDLXDVIZlFvX8BMbqPUAUNHkASn7MFkjtOimtCNHNQqRWMPAAbCDkI6xg h/n4QeC5btW0eJ7bNTWZSiVPnzlTq9eMTntoYEjTk1Qk9xdy9UZVlaXtnpQy1ijygEymbRCXUAjs ByaYSqYkXqx16pdXLpqG6aGhDcG8J/VkIdeX1lOAOiuV1UazQfxgPnmW1rVUsdCfTacBsRqt5vz6 omkhE9qWPqZIwFzAynkO3g+qpxGPH74ppC7YPQxr7+FgRGzyQdIUyyNrMU1LFGVgMDMzF8Z3TPPP tHRDFPhG0++YFibNYe52tzBlqwIS5cVoLhYCRcimul0D6BiTPKeuq7KMyc2xXih1RffJiGOZ8Ymp EyeOp4pFzEfo9hMjqw2aGuh72dLc6N+97w/feFWjv38vi9pwobr3cL5/oFZf2yivNGqVZrumK4l/ +egf3/Zj/61nGnqjN/5jI8qW+8tDQcnAY0Iucl1sLexyTOhRghvQhKPEbdN57GjLEKUW2naYZput NtnNGm3ZKBYCt4lkPfjsX8+++Mep/EBAUVVa2KwYdOQAN7FtrALB/Ne4GxUueElPFIoOKGLfwbp5 HolpB4LAEVcYFwi8adq1er3ZaqdTyWuPXnPh4uW1tZW5xTkAiXwGW0kODw0tLi3Gki2AH6qiwKks x4STsjSjqZqupGD2zU5zvnbZtCwiZYlHZjO5bDIjiWLb7MwuznYMdHPFvVgSCT0Pz6YydEQbtrG8 ukTca0G3w1dXsJKO4UTgeQZ7jgE6YhVnrC7TlYuMkDyREEZIKkepqA0MBfuSES0ZVpYBMtkWx1yc vbRn6hmqPHEcp2sArOIWsJLS+rjjTUS+ua609JbE5laBZHxfrRrNer0v3y3bvkKOs3v+MPQOHjhw 6tSZqw6/kNqugNk60+7pQ3D9hh3ulpDyju/ee/bxY4qqFfvGCrkhEujxTbP1ih/9lZ3TB3rWoTd6 4z82ouA6+/tvkCgUXMESSJ6LYCUL9jDAxsAhxUZEshBr6nwHsYdlQgZXr5HAhiKPwXcAAtuhDRPQ KJIE/8ICNSDxnT3XzjhgSJnC3Cm2VXUc27AMG/5xrAD4Ct1NViLKV2xIZIZxdR1ipQVYWzUhE61F LMXww6DRajWbdbhzbXdooJjL52v1RqfTCXwXJiOLXFqTlzcqsUMHgAGv49g06eEIx1Sbm5u1jXqz BnsprOKUMukMAEZcL7mxud51c4WBLCu5dH5ocDCpaZ7vto32Zq3cNlo2FmOGWyFwtKYcy4mCoGDT SQHwibR1QYLQTWCj4y6OiCjYMYZEvzEXi0gpI+qQDGfiYEI3E6CC4diTkztZ+pkUQsbV9BwXn40I 3DAszcZ9AWAybDwf+olCIGob9mjsxSm0Gps8n4BPhurup684AL1icHpdF2bOn+kvDsf9jpkrzjM8 lP/wh//hpS9/JUlpY5PZzOzZs5Iii7KKrkeGE6VECnOve6mxvdEbT2+cvbz+0v/7yefWnLkg7La0 D7CHChoKSUZcAZjheSqIsKge4+gM5Zno8uK4iGMCUaQkJdR1f3gAaAFbrgrnZ/mquOvs4be+dP7Y sk+hDFYYro7tHlm64AD9wfp5D+0pR7ueE4U8NhcG9CJS+yia4gFKUZYbmo4NljmXT3soj0yl0zoY 4nJ5s9lqWJbRbFb7+4o3XXfN/OL67NwlJqUaLbD7Dpyc6r4LFMEkgo+BY2PtdBR2E2lhJ5hvGuPS 7WqtBtZXEuVkMtMvyUA3JEH0PGBUQIwqpCEYRRJ/SbyJoWOVMFLrQgtIT0RyKkBEnwgGR/Ba5Cth CPtJNIKNqyZhqc7wAkmmDi0rIh3agfPxSkK0LE514YquKHluu3V+YWnf2Mgz+ArDrto/4SdUuE0k ItLnOYrdYRHVDdZH28H7WB0sCiIvooK1jZWIYeOjwmi7chIPj0uMaFoEZnfqzIlcfiBC2hWQvGQc mWJBT2sXLl5SVB15LUP3jY4uXJwpjE4CtSVcijm4d6pnIHqjN54uohz9g48+56bNAU8AYyMIERP7 vgTKdRigLD6YDBG9NtgzmKM4nkoXQ07oOk7iZCLPCU0LE7cSiSCd4qqLZ35M/Pjnr/tlo9Gk6jVq YGhlbN/APf8Yx4Vjo4c5xCwTS+uSmDzYWRdW9CguSWEcu16v2pYFL+kv5YCawEI3l0ujpWbZdqsB lGJpZcF1jGyur1LRgL7oMms6KH/CbKn8MtjemDiiSAAnJBYXwIAlbV0EnpdFCXgG5suilLDn2C3L wGCAH5CQBKE8xD3H0FuVHxie5lnCS3AmEWk0ydCk7yRFEfkyDKhwPJblw0uBKgF+uJ6LxwNqUnjq MMRiJcAb07babVHESnsfbo7tOo5z5vSJiaFB5Rv1U9lyV0VPbJMcLQA0w7SBSPndLOI41hPXpXTz uGJSGD5Rx0J3ASXadpRFm9VaIqU0Om2gqSEeS23VvdBbhyIoa1qG66y0scuWRIAriJHMMP3Xv+7W y3Mze6YPkz6WkRfy2YGB+spiamAIsHhydKhnIHqjN57WaBn2j33gc9+gwvG5ACrYGQWD7QzDs6Gq hJbJRXxAixErUIpOAZDECWDEYJPUWVy8UoQQUCyLjYdR4oWNwKKuWkvzRkR1ylQqi4hUHHMEhTY7 HunHjpnIuMrFUA4KSDIsPAT7G1t+gRdEEWvqa42KZZtgzfr7skAdYN2va0oU5oBMKEbH6NTq9YrR bhSz2vqmbdhOuxOAsR8uZScH1dEiO9wf9medhOKAvfN8rtIQVsrs7BrAvrGy3rR8BxhP11ZueXm6 S/fY6Mb9IxlEJpIPhSkFsFcSJZgwVm34QdwPxSMtioO4FCQKYZ6KrPIcD2+WVDviBETS9Qsek/Zm FOlLhulZVsdyNdUFiiWjvAtAi9hpPDRz+YZdk7Gl3prXNqZcgSexRQ9CFCxzna3EgairzUIawhA8 CON5RnEInjxGcTDSMIakQJP1AR5N3mfczCZuR0lQLG7xGSsfw51ps6Vi6eKlS6nsGOArRXVR3Lbp 4cHh2aXj8XVRhwzOxCqJbKq5vtI/OplQ5Z6N6I3eeFrjp/7iM9+Dul7fEah0g84o9UiJIgbhPZvJ Dzh9Iz7L0wgAwVYPYZID1o1A06SZSoQMRkZRST+tUQN94uf/RZw6+X9mXvzjVDqL+i2m4fpuFGA9 edeAB4SzRBSKoDDYbDJGFFh0hxIgEydLSgsoSas+OzunYz9GAcwmivMnNbDpVAjMgjUM17IdYC2l ggIve81LEjc/fzWtlwWi3k/wD+8B7Vgujo/je+wY7OPnch/6gvrQiTKYdKYbOEBjStxaOLuY7rDE xsIebH1MUmjjlr+2bXWhiFj9IAzorYg4xi6w7FGAxw52O7EBK2J6BJsosB/4AKMYWvGw0l7gBKNj J3XgSQ5qTWLKr7+yOGtPjIksMe/RU7jKNpp0K04wezrOOohL5amuZCS1pdUSyxaHVBc+YqyKexd0 4/Rb/2jJjO+bUTcvrJuaEXMaco7uE3Chjs3u3b3rscePD47uI/QPn5blRLO9mUyqW4ljUbdfjJhM pKix4YGegeiN3nha4wN3PvTxC3PP0cmzt16rcGTFyQsRUBYwRYNTlpbFto8MR3Mixao8IzDoSUHs iEvnsJcwRSxW4JPEppByPeYTaz/x+AMzzcVLDC/Y+69DUFmcGzp2t2G0PM8DMxNXb8AD4BwkUs0J ZF2Pa20ajaCeSMCa3XVd0zSxpsUP+/pzYG4d2yUtvOjAczxMUXZcP6y17Rcdzv3m21YOTNaTqicJ GK7gsOCGpBLwiCsMcSYBtAgiJYnRQME4urdTyqU5RmuZoeeFcbScjnEFV+txYloXZBhsV4xrfQbF +dkYSLrlg0HYXdQT6S3S41JWJAUAxXJtx3Fg2oAxWiJpOZjsiwhEyh4RsSgSTGdoGWViRF7gZUyE 5jnfpjPFQgKVNLfiItv324OKJTjh00FBSxLsecI3FkdCqHgH8fs9kcZFbeeBRdGWR42gB7Crdqsi KxmSLkzHKBltZ5Fttz5GmQP4ooNSX2pheVXTUtRWTJ9lHMtoqXpcbbOVkUzTxf5SOpXs2Yje6I3v fKxsNF/5gc90+44/F5kKzUQB9npHF0e7w3ACE/iMY4ROh/RQwboLT1RoXiJpYBwTuiFNfF8kjQv5 jWNj8QrHRVUl3TJN4Bz5E19pvOatlM9Q86dtGwDCwLAEx0axOaSBpnhxtxIAFZbhoghMcOjSABWe AJYYXSsoPblRXttYy+XzKR+NcuhaVuS7Es+KPNMygluvK/7MaxcTis9iVB6X4yxQky0gAcDzAzD3 tGGQBpOot0/7cO2I3lEyjY400iedviwtlt1mx4uTzejtxiY0iVd3e4NhnQeLjjkuCj2ABFKnScca joTl0N2AEc3A/E3bjNtnwWs5jndc2w/iTQpDRz4r89iCxfFcw7Br9ZYsSbIquo5LaRG8j/LacljI Uk80Q9kqNnkCGKKY5/le6G/xlC0x4ieoynYAJtxKDt7iH10e0YUrssULsqJIltVWgVl04/lPuew2 XaL9gHVodrBPK9fWs5n+uP0yFcH7imzLlmQpprMRfrnsQLHQsxG90RtPa/zE+z/zXAylbI//L8AA XL89uROPs9cAAAAASUVORK5CYII= ------_=_NextPart_70e02604-672e-48e0-b995-ea3a65afca22-- From nobody Sun Oct 10 22:48:03 2021 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 8FC573A0474; Sun, 10 Oct 2021 22:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft1331857.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 6WCkMfQ1ukJe; Sun, 10 Oct 2021 22:47:48 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1anam02on2082.outbound.protection.outlook.com [40.107.96.82]) (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 B9F673A044D; Sun, 10 Oct 2021 22:47:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=X1l/iLROpGQCzTm0oo00Oe0Ty3dCc+omBO+OmoqpuoXibGL9GYKzHcB6Mw0/FhEZbLbRxu9xTiApF8V8JIr2x8kIMqY6vmf3XXragMRtHob6nw5wK3Megq8s+bTsi92KVcbbZ3wD+SU19Gg1m3PlR8hbcT1uXSepsQbVAautM9III3D4ti+rgRa5PgoytnS9jm7hQTdL2l36Vy/lgxa4fDinl7DXAqB5N/PjTTzafhJVacHMPOsgqClqlOhtPAlbdF1xLaQhnKP+E4NUQGtjBDEe4Pyo6x2m7iY5P1MctHsbGG/H/WVJ1enRhO0ytqKnU99hko0QDLFo7rM1EdGj+Q== 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=0+PEHcuEFmLwWtmM24SNyIwPIfzU/hBFp6N2gUw5Now=; b=M7u2zT1kQm4n0Tv05NTqnrniRfe4EJ9Eqe4OqS19nrjJDwAlEaZj/0KT7sqx+T+X/y9vfMhmGQpxWDrldgBrLRuZ2sNIV3d5fKqdnaxG5KNMdee8JvcAIUZRHSO/8VsCuHDt+Sq2807wpiWdd8nn8bosFAXdBEmzIGJqHll2e8kDbdxN47UyEv2KmUC+pYBIeRBQM/yZ66XhTaiWFx2VU0M+eoYqXqy6ch36FDPt63Cj0CydGsa5i0yjUbNcDc/t3IUvAS0wZfz4A1XwrFYDZMVwBXui8usS1dqEQweDRmFxYFrF1P6lEEM1F+iohpwtAjk3LA0w/7TucNx/EvZOsg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arrcus.com; dmarc=pass action=none header.from=arrcus.com; dkim=pass header.d=arrcus.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT1331857.onmicrosoft.com; s=selector2-NETORGFT1331857-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0+PEHcuEFmLwWtmM24SNyIwPIfzU/hBFp6N2gUw5Now=; b=XEGO/xPufVIPXm+0tGK/2mzBkL5fp2iB2WHWQSUfgp6VU4K9WbCOXIy+GddnQUpQC6BSv6/BTEfnV9a6wLEx+DJ0hozJAn50RY5XFvwX6IkbFRD+OBnVO4Z7F9xJeAUGuFq8LEKixrgHwdtMkEnicMZwpG/PU9kRrt4o9GABE2c= Received: from BYAPR18MB2696.namprd18.prod.outlook.com (2603:10b6:a03:10b::26) by BYAPR18MB2616.namprd18.prod.outlook.com (2603:10b6:a03:13c::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.25; Mon, 11 Oct 2021 05:47:44 +0000 Received: from BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::218a:91d6:3c5f:b162]) by BYAPR18MB2696.namprd18.prod.outlook.com ([fe80::218a:91d6:3c5f:b162%5]) with mapi id 15.20.4587.026; Mon, 11 Oct 2021 05:47:44 +0000 From: Keyur Patel To: "Zafar Ali (zali)" , James Guichard , SPRING WG CC: "Zafar Ali (zali)" , "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: AQHXuTd9ijIiTOMLDkGipCqWUcImCKvM3z2A Date: Mon, 11 Oct 2021 05:47:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.50.21061301 authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=arrcus.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f46181c5-2152-424f-dbca-08d98c7aa5c5 x-ms-traffictypediagnostic: BYAPR18MB2616: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: J07aUe/I4R9+lMZnP1e43KFqfymLVa+JWRy7Meqyi2siGgzfVgHY71htNuO9P81PIn9knIk7tm08impztdYMbuKT4VPNrD0DBLi8N88ZPqn4SXW7nWGkOzIBOIP5w68n3BwAhePzFzwmrXRwZP1Db80A+rkxb8j6ezB8fx5FSN/V11+UeHNk0gQAgP8oj01UYhLAoVCTbQtRrJSKEL29sf1R7VUYiWYRLJP1IK3eB9iwn3UH/x/LPj/rINEK2ifAcpMbIJetjrmQFYLY/QA3aO1Mvt7fM/CorRw7GVH38WA8rh8afX7R1oATHZbXfh7VeUH1sa2gX5QGWA59R0B/5PsEp4Bq0aJmpLaSkkEogUBCDyqX3K2v0ACOUWe/tXfaRf6eBl/jxI58VsXK5TFEk1gah4itmKdBptoiw/ddWZVXC1f+UOwQIkJ6CmbvWFyhw69HEfgzjna7waUNlE+hTdi1ivvP8VrAszRpNJMAsaAS2A4B41G1NN9n8fCpYvZ8HSz7C7fyzXwkovHslfhKHC5z/3fqXtJcA/5QqrmOcnnJIVryDzFBNeHF30RcQk/fTyTI7JSZ/jnHbhn2z5cHYpMah5/GB22338/Pcf7YKfnefhaO/aRBbgtl0AC1E1TOQHGknLTvaP8SwyswdlyVdJ4K5Jm6LxDyZbKwp+MomnZuDUsoIbNoSflTgl0ny1KMLxNyiPOic22rpcobEQeGK1n9c/ZN8AaIqXgw6jiITV87G1OWKRG5O9V3YPmr0Qn5eOlebzxfyFuaBpYDABg5X8uz4M9/nEfq4DoRccuz8d32j2U+EpNVMde99AaqTt1t x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BYAPR18MB2696.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(396003)(39830400003)(366004)(376002)(346002)(2906002)(2616005)(186003)(83380400001)(64756008)(66446008)(166002)(66476007)(66946007)(38070700005)(71200400001)(76116006)(36756003)(66556008)(6512007)(122000001)(6486002)(38100700002)(316002)(54906003)(8676002)(110136005)(8936002)(508600001)(86362001)(966005)(4326008)(5660300002)(33656002)(53546011)(6506007)(45980500001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?YUlMU0U4enBnZVZqZTc4c2ZwTVF5dTJ0S1pMOUhzUUs0VmRsNFhGcWorOFh2?= =?utf-8?B?UndUbTljazh2c0FVbFZGSFh3R1NoNDN3Qm5uM1FQdzQzalVpUUdKdEZCQmll?= =?utf-8?B?LzJ3N2ptazV4eEt5WlA0Y0x5WDVlQVNZWVlzOWdFclBFRmlXYUwvM1ZQdjMz?= =?utf-8?B?b0NwQjljVGs5SDg3UDNLM1JudnNYcU1INldCeGVTNVZERzNqdTFETXpIMXR6?= =?utf-8?B?bnN6TEZrUGNuMEVpWURzem1rMEcveVJNb01zSTdUNENLRWQyMGJLVE1DeTNM?= =?utf-8?B?NnoxZ003SWRJSTZ3bStraGZZSEtpY2FGcXdPalpocys2QzF4U2xZVXBkVkNx?= =?utf-8?B?bzkyUlVDb0lSRzVHaGs4bGZHRjJza0paMzQzdWhPVnp0ZHJjemxlc2ROZm55?= =?utf-8?B?UU9ocFY0RjdjTGc2RSs0eC91QWE1LzhseEZHSlhvdHUrUXdsZVBpKzlDTXEv?= =?utf-8?B?bUw4RG9sSzJCY2k2R2VSUDh1RDRVMnZZZlZyUHdwTmVqT1BLS2pCaVphTWFN?= =?utf-8?B?cGJUaG1OOTFRdXRLZFZlZ0pkTkRNcE5wQ0hQWHdaYWNGM3VwSkYvZDhOSTZy?= =?utf-8?B?bUorc0hLZCtyUUR2bmhubi8rdHJjTXREbWM0WUI5YjhkTkRqTlZVUkRMNDhT?= =?utf-8?B?STJ0eW9aOCt0SE1xb0hMcVZjc25LR3U1emRYY1ZrYjV3Yjl3MXJoVUU4bzFt?= =?utf-8?B?SFVjM1hHQjI4Lzgwc2JzSHU2R09FdDNNbGp1VllyQ3RWQW5rVHo5OXFFQWp0?= =?utf-8?B?Y1dSNW9lWkZSYUwxcndSTGkra0N5OVZndFlNWU9yOGlDN296bGdYYlV5OStN?= =?utf-8?B?WnBTc0lhQm9UL0x0bVNUUStBbnZKcDFndzMvTFI2R2FYWkl0dXBzRVIyWlZx?= =?utf-8?B?RHdZUGUxdFlOS1IxOTBpSWc5QXdKZFFIbUdHUWtMSm5VQXcxU2Q0MVhEbFo3?= =?utf-8?B?Y2tkVE5IOG9JSldybnVPUld6R2tlSW80OU1xSjJybXFnSk8rWUdPTS9MVTNC?= =?utf-8?B?OU9GZWhRQXNTN1pVZUxaeGR1MWVSRVZyMk55UTA1TjlOS2RIVS9zbEVLcjRC?= =?utf-8?B?WGZ1NkF1aWFqalhPNDZSU1N4K0xjSCtzZDltZlE0NEhHa1MwdTJkYmZ2VjRw?= =?utf-8?B?MjVkeHhMaWdwQmRxTzUzQjMra0ZzWjY0Vi84TkYzdTkzZkowYVlaTytsSDBX?= =?utf-8?B?V3JMMkw2elBGb2pqVW8vODV2R0VpTE5zWGVORC9MWXAzS3k5MnlrUkdOKyt0?= =?utf-8?B?ZDd5Z2ZhNWRMSVQxU0UwbWVCWmVHYkQxT0pNUUtjbk90d2hFVDR4c2drREFV?= =?utf-8?B?d2NCNkhJL2xISHJuTE9KL2lSUGQ4YmRRQkQ0V0srT3pBOTNSUGh2Ui9VZlNW?= =?utf-8?B?MmdEWUxudk1DUDcxRmtXeG1pS3pEWFBMb1AyQVd3SzBwZWhBeHozK3QxcFZk?= =?utf-8?B?TzAzREpvMVFOTnZ1cUN1UnJSQmhISFpOWHdIVGVkZWdrc3JMcXRDYytuUkYr?= =?utf-8?B?U0pya240R2NGQzk1bHA2TnVYUnkrM2RpM0dFeWNHWjN6OTF6TzdkcjJFMkk3?= =?utf-8?B?ZWxQd3k5ZlpCQi9VVklwK0xSZFY2V3BQcHNTeXE4ejIrRFR4Z3R5cDFLTEtz?= =?utf-8?B?RDVOb2ZZSzQ4YklaV0t1VVI5azNHYlE1R014U2tGRzU3SnltbzNBaDFQK21v?= =?utf-8?B?R0FtMUVpWW5ra1FYYW5qTWlsUUR3NE1GYU12b1FiRUZVbEZBSi9OY2dvbUNN?= =?utf-8?B?MjNrQTEvNFJLZGc4aU4vb24zY0Y3OVpTK0RNZm1HbWZ6N3RqQUtMNmFTa1VT?= =?utf-8?Q?iqeWsmglRcwXLlLMFYrelAOtLfadG/xtj3JMk=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_E29516CFBF7E457E9EBB0D072C758CCBarrcuscom_" MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BYAPR18MB2696.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f46181c5-2152-424f-dbca-08d98c7aa5c5 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2021 05:47:44.2273 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 697b3529-5c2b-40cf-a019-193eb78f6820 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Eia8GXUo+xkdZmDC4MTJNh/FJlg16eYLqCyzJMjRDRoW9D3o4dYCubvNv9uxxSoxAHarV1tN40Bdz73AQzTkIQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB2616 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 11 Oct 2021 05:47:54 -0000 --_000_E29516CFBF7E457E9EBB0D072C758CCBarrcuscom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBXRyBhbmQgdGhlIFdHIENoYWlycywNCg0KTmV0d29yayBwcm9ncmFtbWluZyBtb2RlbCAo UkZDODk4NikgZGVmaW5lcyBtdWx0aXBsZSBmbGF2b3JzIGZvciBFbmQsIEVuZC5YLCBhbmQgRW5k LlQgU0lEcy4gQ1NJRCBkcmFmdCBidWlsZHMgb24gaXQgd2l0aCBuZXh0IGFuZCByZXBsYWNlIGZs YXZvcnMgZm9yIHRoZXNlIFNJRHMsIG9wdGltaXplZCBmb3IgMTYgYml0IGFuZCAzMiBiaXQgU0lE IHNpemVzLCByZXNwZWN0aXZlbHkuIFRoaXMgaXMganVzdCBsaWtlIFBTUCwgVVNQIGFuZCBVU0Qg Zmxhdm9ycyBkZWZpbmVkIGluIFJGQzg5ODYgdG8gY292ZXIgZGlmZmVyZW50IGRlcGxveW1lbnQg c2NlbmFyaW9zLg0KDQpXZSBhdCBBcnJjdXMgaGF2ZSBpbXBsZW1lbnRlZCBDU0lEIHNvbHV0aW9u IGFuZCBhbHNvIGhhdmUgcGFydGljaXBhdGVkIGluIG11bHRpdmVuZG9yIGludGVyb3AgZm9yIHRo ZSBzb2x1dGlvbi4NCg0KSSBzdHJvbmdseSBzdXBwb3J0IHRoZSBhZG9wdGlvbi4NCg0KQmVzdCBS ZWdhcmRzLA0KS2V5dXINCg0KDQpGcm9tOiBzcHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3Jn PiBvbiBiZWhhbGYgb2YgIlphZmFyIEFsaSAoemFsaSkiIDx6YWxpPTQwY2lzY28uY29tQGRtYXJj LmlldGYub3JnPg0KRGF0ZTogTW9uZGF5LCBPY3RvYmVyIDQsIDIwMjEgYXQgODo1MCBBTQ0KVG86 IEphbWVzIEd1aWNoYXJkIDxqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20+LCBTUFJJTkcg V0cgPHNwcmluZ0BpZXRmLm9yZz4NCkNjOiAiWmFmYXIgQWxpICh6YWxpKSIgPHphbGlAY2lzY28u Y29tPiwgInNwcmluZy1jaGFpcnNAaWV0Zi5vcmciIDxzcHJpbmctY2hhaXJzQGlldGYub3JnPg0K U3ViamVjdDogUmU6IFtzcHJpbmddIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNv bXByZXNzaW9uLw0KDQpEZWFyIFdHIGFuZCB0aGUgY2hhaXJzLA0KDQpJIHN0cm9uZ2x5IHN1cHBv cnQgdGhlIGFkb3B0aW9uIGNhbGwNCg0KQWJvdXQgdGhlIG1hdHRlciBpbiB0aGUgZW1haWwsIHRo ZSBXRyBoYXMgZGVmaW5lZCBhIHNpbmdsZSBkYXRhIHBsYW5lIHNvbHV0aW9uLCBpLmUuLCBTUnY2 IChSRkM4NDAyLCBSRkM4NzU0LCBhbmQgUkZDODk4NikuDQpTUnY2IGFzIHBlciB0aGUgaW5oZXJl bnQgbmF0dXJlIG9mIHRoZSBuZXR3b3JrIHByb2dyYW1taW5nIG1vZGVsIChSRkM4OTk2KSBhbHJl YWR5IGRlZmluZXMgbXVsdGlwbGUgc3RhbmRhcmRpemVkIGJlaGF2aW9ycy4NCkNsZWFybHksIENT SUQgaXMgYSBzaW5nbGUgc29sdXRpb24gYmFzZWQgb24gdGhlIFNSdjYgZGF0YSBwbGFuZS4NCg0K VGhhbmtzDQoNClJlZ2FyZHMg4oCmIFphZmFyDQoNCg0KRnJvbTogc3ByaW5nIDxzcHJpbmctYm91 bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIEphbWVzIEd1aWNoYXJkIDxqYW1lcy5uLmd1aWNo YXJkQGZ1dHVyZXdlaS5jb20+DQpEYXRlOiBGcmlkYXksIE9jdG9iZXIgMSwgMjAyMSBhdCAxMDow NSBBTQ0KVG86IFNQUklORyBXRyA8c3ByaW5nQGlldGYub3JnPg0KQ2M6ICJzcHJpbmctY2hhaXJz QGlldGYub3JnIiA8c3ByaW5nLWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6IFtzcHJpbmddIFdH IEFkb3B0aW9uIGNhbGwgZm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLw0KDQpEZWFyIFdHOg0K DQpUaGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gZXhwcmVzcyB0aGVpciBhcHByZWNpYXRpb24gZm9y IGFsbCB0aGUgcmVzcG9uc2VzIHJlY2VpdmVkIHRvIG91ciBlbWFpbHMgd2l0aCByZWZlcmVuY2Ug dG8gaG93IHRoZSB3b3JraW5nIGdyb3VwIHdpc2hlcyB0byBtb3ZlIGZvcndhcmQgd2l0aCByZXNw ZWN0IHRvIGEgc29sdXRpb24gZm9yIFNSdjYgY29tcHJlc3Npb24uDQoNClRoZSBhcHBhcmVudCBp bmNsaW5hdGlvbiBvZiB0aGUgd29ya2luZyBncm91cCBpcyB0byB1c2UgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29t cHJlc3Npb24vIGFzIHRoZSBiYXNpcyBmb3IgaXRzIGNvbXByZXNzaW9uIHN0YW5kYXJkaXphdGlv biB3b3JrLiBUaGF0IGlzIHBhcnQgb2Ygd2hhdCB0aGlzIGVtYWlsIGF0dGVtcHRzIHRvIGNvbmZp cm0uDQoNCkJlY2F1c2Ugb2YgdGhlIGFib3ZlIHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBpc3N1 ZSBhIDItd2VlayBXRyBjYWxsIGZvciBhZG9wdGlvbiBlbmRpbmcgT2N0b2JlciAxNXRoIGZvciBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmlu Zy1zcnY2LXNyaC1jb21wcmVzc2lvbi8gYnV0IHdpdGggc29tZSBjbGVhciBndWlkZWxpbmVzIGFz IGZvbGxvd3MuIEJ5IGV4cHJlc3Npbmcgc3VwcG9ydCBmb3IgYWRvcHRpb24gb2YgdGhpcyBkb2N1 bWVudCB5b3UgYXJlIGZ1bGx5IGF3YXJlIG9mIGFuZCBhcmUgYWNrbm93bGVkZ2luZyB0aGF0Og0K DQoNCjEuICAgICAgIFRoZSBTUFJJTkcgd29ya2luZyBncm91cCBpcyBhZG9wdGluZyBhIGRvY3Vt ZW50IHRoYXQgaGFzIG11bHRpcGxlIFNSdjYgRW5kcG9pbnQgYmVoYXZpb3JzLg0KDQoyLiAgICAg ICBUaGUgZG9jdW1lbnQgaXMgYSDigJxsaXZpbmfigJ0gZG9jdW1lbnQ7IGl0IG1heSBjaGFuZ2Ug YXMgaXQgZ29lcyB0aHJvdWdoIHJldmlldyBhbmQgYW5hbHlzaXMgYnkgdGhlIFNQUklORyB3b3Jr aW5nIGdyb3VwLg0KDQozLiAgICAgICBBbGwgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyByYWlzZWQg b24gb3VyIG1haWxpbmcgbGlzdCBNVVNUIGJlIGFkZHJlc3NlZCBCRUZPUkUgc2FpZCBkb2N1bWVu dCBpcyBhbGxvd2VkIHRvIHByb2dyZXNzIGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAgdG8gcHVibGlj YXRpb24uIEEgbGlzdCBvZiB0aGVzZSBkaXNjdXNzaW9uIHBvaW50cyB3aWxsIGJlIGRvY3VtZW50 ZWQgaW4gdGhlIFdHIGRvY3VtZW50IGFuZCBtYWludGFpbmVkIGJ5IHRoZSBkb2N1bWVudCBlZGl0 b3IgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgY2hhaXJzLg0KDQo0LiAgICAgICBJZiB0aGlzIGRv Y3VtZW50IGlzIGFkb3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAsIHRoZSBjaGFpcnMgc3BlY2lm eSBhcyBwYXJ0IG9mIHRoZSBhZG9wdGlvbiBjYWxsIHRoYXQgdGhlIGZvbGxvd2luZyB0ZXh0IGRl c2NyaWJpbmcgYW4gb3BlbiBpc3N1ZSBiZSBhZGRlZCB0byB0aGUgZG9jdW1lbnQgaW4gdGhlIGFi b3ZlLWRlc2NyaWJlZCBvcGVuIGlzc3VlcyBzZWN0aW9uOg0KDQrCtyAgICAgICAgICJHaXZlbiB0 aGF0IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBzYWlkIHRoYXQgaXQgd2FudHMgdG8gc3RhbmRhcmRp emUgb25lIGRhdGEgcGxhbmUgc29sdXRpb24sIGFuZCBnaXZlbiB0aGF0IHRoZSBkb2N1bWVudCBj b250YWlucyBtdWx0aXBsZSBTUnY2IEVuZFBvaW50IGJlaGF2aW9ycyB0aGF0IHNvbWUgV0cgbWVt YmVycyBoYXZlIHN0YXRlZCBhcmUgbXVsdGlwbGUgZGF0YSBwbGFuZSBzb2x1dGlvbnMsIHRoZSB3 b3JraW5nIGdyb3VwIHdpbGwgYWRkcmVzcyB3aGV0aGVyIHRoaXMgaXMgdmFsaWQgYW5kIGNvaGVy ZW50IHdpdGggaXRzIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uIG9iamVjdGl2ZS4iLg0KDQpQbGVh c2UgY29uc2lkZXIgdGhlIGFib3ZlIGd1aWRlbGluZXMgYXMgeW91IGRlY2lkZSBvbiB3aGV0aGVy IHRvIHN1cHBvcnQgb3Igbm90IHRoaXMgV0cgYWRvcHRpb24uIFBsZWFzZSBleHByZXNzIGNsZWFy bHkgeW91ciByZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9uLXN1cHBvcnQgYXMgd2VsbCBhcyBhbnkg b3BlbiBkaXNjdXNzaW9uIHBvaW50cyB5b3Ugd291bGQgbGlrZSBhZGRyZXNzZWQgc2hvdWxkIHRo ZSBkb2N1bWVudCBiZSBhZG9wdGVkIGludG8gdGhlIHdvcmtpbmcgZ3JvdXAuDQoNClRoYW5rcyEN Cg0KSmltLCBCcnVubyAmIEpvZWwNCg0KDQo= --_000_E29516CFBF7E457E9EBB0D072C758CCBarrcuscom_ Content-Type: text/html; charset="utf-8" Content-ID: <128491F86C26BA47AB1702E37CC4D534@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjND MTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29Q bGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpwLk1zb0xpc3RQ YXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21z by1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJZm9udC1zaXplOjEx LjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLlBsYWluVGV4 dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8N CkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjc1MTY5OTM5MzsNCgltc28tbGlzdC10eXBlOmh5YnJp ZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTcyMTY1NDc3NiA2NzY5ODcwMyA2NzY5ODY4OSA2 NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5 ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlz dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4 dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBw dDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEi IHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBXRyBhbmQgdGhlIFdH IENoYWlycyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5OZXR3b3JrIHByb2dyYW1taW5nIG1vZGVsIChSRkM4OTg2KSBkZWZpbmVzIG11bHRpcGxlIGZs YXZvcnMgZm9yIEVuZCwgRW5kLlgsIGFuZCBFbmQuVCBTSURzLiBDU0lEIGRyYWZ0IGJ1aWxkcyBv biBpdCB3aXRoIG5leHQgYW5kIHJlcGxhY2UgZmxhdm9ycyBmb3IgdGhlc2UgU0lEcywgb3B0aW1p emVkIGZvciAxNiBiaXQgYW5kIDMyIGJpdCBTSUQgc2l6ZXMsIHJlc3BlY3RpdmVseS4NCiBUaGlz IGlzIGp1c3QgbGlrZSBQU1AsIFVTUCBhbmQgVVNEIGZsYXZvcnMgZGVmaW5lZCBpbiBSRkM4OTg2 IHRvIGNvdmVyIGRpZmZlcmVudCBkZXBsb3ltZW50IHNjZW5hcmlvcy48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+V2UgYXQgQXJyY3VzIGhhdmUgaW1wbGVtZW50ZWQgQ1NJRCBzb2x1 dGlvbiBhbmQgYWxzbyBoYXZlIHBhcnRpY2lwYXRlZCBpbiBtdWx0aXZlbmRvciBpbnRlcm9wIGZv ciB0aGUgc29sdXRpb24uDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkkgc3Ry b25nbHkgc3VwcG9ydCB0aGUgYWRvcHRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPkJlc3QgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPktleXVyPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPnNwcmluZyAmbHQ7 c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDtaYWZhciBBbGkg KHphbGkpJnF1b3Q7ICZsdDt6YWxpPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnJmd0Ozxicj4N CjxiPkRhdGU6IDwvYj5Nb25kYXksIE9jdG9iZXIgNCwgMjAyMSBhdCA4OjUwIEFNPGJyPg0KPGI+ VG86IDwvYj5KYW1lcyBHdWljaGFyZCAmbHQ7amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29t Jmd0OywgU1BSSU5HIFdHICZsdDtzcHJpbmdAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4m cXVvdDtaYWZhciBBbGkgKHphbGkpJnF1b3Q7ICZsdDt6YWxpQGNpc2NvLmNvbSZndDssICZxdW90 O3NwcmluZy1jaGFpcnNAaWV0Zi5vcmcmcXVvdDsgJmx0O3NwcmluZy1jaGFpcnNAaWV0Zi5vcmcm Z3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbc3ByaW5nXSBXRyBBZG9wdGlvbiBjYWxsIGZv ciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNw cmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBXRyBhbmQgdGhlIGNoYWlycywgPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgc3Ryb25nbHkgc3VwcG9ydCB0aGUgYWRvcHRpb24gY2FsbDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BYm91dCB0aGUgbWF0dGVyIGluIHRoZSBlbWFpbCwgdGhlIFdH IGhhcyBkZWZpbmVkIGEgc2luZ2xlIGRhdGEgcGxhbmUgc29sdXRpb24sIGkuZS4sIFNSdjYgKFJG Qzg0MDIsIFJGQzg3NTQsIGFuZCBSRkM4OTg2KS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U1J2NiBhcyBwZXIgdGhlIGluaGVyZW50IG5hdHVyZSBvZiB0aGUgbmV0d29y ayBwcm9ncmFtbWluZyBtb2RlbCAoUkZDODk5NikgYWxyZWFkeSBkZWZpbmVzIG11bHRpcGxlIHN0 YW5kYXJkaXplZCBiZWhhdmlvcnMuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkNsZWFybHksIENTSUQgaXMgYSBzaW5nbGUgc29sdXRpb24gYmFzZWQgb24gdGhlIFNSdjYg ZGF0YSBwbGFuZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhhbmtzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMg4oCmIFphZmFyJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+c3ByaW5nICZsdDtzcHJpbmctYm91bmNlc0BpZXRmLm9yZyZn dDsgb24gYmVoYWxmIG9mIEphbWVzIEd1aWNoYXJkICZsdDtqYW1lcy5uLmd1aWNoYXJkQGZ1dHVy ZXdlaS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgT2N0b2JlciAxLCAyMDIxIGF0 IDEwOjA1IEFNPGJyPg0KPGI+VG86IDwvYj5TUFJJTkcgV0cgJmx0O3NwcmluZ0BpZXRmLm9yZyZn dDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3NwcmluZy1jaGFpcnNAaWV0Zi5vcmcmcXVvdDsgJmx0 O3NwcmluZy1jaGFpcnNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPltzcHJpbmdd IFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPkRlYXIgV0c6PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+VGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGV4cHJlc3MgdGhlaXIgYXBwcmVjaWF0aW9u IGZvciBhbGwgdGhlIHJlc3BvbnNlcyByZWNlaXZlZCB0byBvdXIgZW1haWxzIHdpdGggcmVmZXJl bmNlIHRvIGhvdyB0aGUgd29ya2luZyBncm91cCB3aXNoZXMgdG8gbW92ZSBmb3J3YXJkIHdpdGgg cmVzcGVjdCB0byBhIHNvbHV0aW9uIGZvciBTUnY2IGNvbXByZXNzaW9uLg0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+VGhlIGFwcGFyZW50IGluY2xpbmF0aW9uIG9mIHRoZSB3b3JraW5nIGdyb3VwIGlzIHRv IHVzZQ0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmls c2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vIj4NCmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNv bXByZXNzaW9uLzwvYT4gYXMgdGhlIGJhc2lzIGZvciBpdHMgY29tcHJlc3Npb24gc3RhbmRhcmRp emF0aW9uIHdvcmsuIFRoYXQgaXMgcGFydCBvZiB3aGF0IHRoaXMgZW1haWwgYXR0ZW1wdHMgdG8g Y29uZmlybS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5CZWNhdXNlIG9mIHRoZSBhYm92ZSB0aGUgY2hhaXJz IHdvdWxkIGxpa2UgdG8gaXNzdWUgYSAyLXdlZWsgV0cgY2FsbCBmb3IgYWRvcHRpb24gZW5kaW5n IE9jdG9iZXIgMTU8c3VwPnRoPC9zdXA+IGZvcg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJl c3Npb24vIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxz Y2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLzwvYT4gYnV0IHdpdGggc29tZSBjbGVh ciBndWlkZWxpbmVzIGFzIGZvbGxvd3MuIEJ5IGV4cHJlc3Npbmcgc3VwcG9ydCBmb3IgYWRvcHRp b24gb2YgdGhpcyBkb2N1bWVudCB5b3UgYXJlIGZ1bGx5IGF3YXJlIG9mIGFuZCBhcmUgYWNrbm93 bGVkZ2luZyB0aGF0Og0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEuMGluO3RleHQtaW5kZW50Oi0uMjVp bjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAgaXMgYWRv cHRpbmcgYSBkb2N1bWVudCB0aGF0IGhhcyBtdWx0aXBsZSBTUnY2IEVuZHBvaW50IGJlaGF2aW9y cy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJt YXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+ Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+VGhlIGRvY3VtZW50IGlzIGEg4oCcbGl2aW5n4oCdIGRvY3VtZW50OyBpdCBtYXkgY2hhbmdl IGFzIGl0IGdvZXMgdGhyb3VnaCByZXZpZXcgYW5kIGFuYWx5c2lzIGJ5IHRoZSBTUFJJTkcgd29y a2luZyBncm91cC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDoxLjBpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzIiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+My48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48IVtlbmRpZl0+QWxsIG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgcmFpc2VkIG9uIG91ciBtYWls aW5nIGxpc3QgTVVTVCBiZSBhZGRyZXNzZWQgQkVGT1JFIHNhaWQgZG9jdW1lbnQgaXMgYWxsb3dl ZCB0byBwcm9ncmVzcyBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIHRvIHB1YmxpY2F0aW9uLiBBIGxp c3Qgb2YgdGhlc2UgZGlzY3Vzc2lvbiBwb2ludHMgd2lsbCBiZSBkb2N1bWVudGVkIGluIHRoZSBX RyBkb2N1bWVudCBhbmQgbWFpbnRhaW5lZA0KIGJ5IHRoZSBkb2N1bWVudCBlZGl0b3IgaW4gY29u anVuY3Rpb24gd2l0aCB0aGUgY2hhaXJzLiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MS4waW47dGV4dC1pbmRlbnQ6LS4yNWlu O21zby1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPjQuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPklmIHRoaXMgZG9jdW1lbnQgaXMgYWRvcHRlZCBieSB0 aGUgd29ya2luZyBncm91cCwgdGhlIGNoYWlycyBzcGVjaWZ5IGFzIHBhcnQgb2YgdGhlIGFkb3B0 aW9uIGNhbGwgdGhhdCB0aGUgZm9sbG93aW5nIHRleHQgZGVzY3JpYmluZyBhbiBvcGVuIGlzc3Vl IGJlIGFkZGVkIHRvIHRoZSBkb2N1bWVudCBpbiB0aGUgYWJvdmUtZGVzY3JpYmVkIG9wZW4gaXNz dWVzIHNlY3Rpb246PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHls ZT0ibWFyZ2luLWxlZnQ6MS41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVs MiBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpT eW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6 Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT4mcXVvdDtHaXZlbiB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBzYWlkIHRoYXQgaXQgd2Fu dHMgdG8gc3RhbmRhcmRpemUgb25lIGRhdGEgcGxhbmUgc29sdXRpb24sIGFuZCBnaXZlbiB0aGF0 IHRoZSBkb2N1bWVudCBjb250YWlucyBtdWx0aXBsZSBTUnY2IEVuZFBvaW50IGJlaGF2aW9ycyB0 aGF0IHNvbWUgV0cgbWVtYmVycyBoYXZlIHN0YXRlZCBhcmUgbXVsdGlwbGUgZGF0YSBwbGFuZSBz b2x1dGlvbnMsDQogdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhZGRyZXNzIHdoZXRoZXIgdGhpcyBp cyB2YWxpZCBhbmQgY29oZXJlbnQgd2l0aCBpdHMgb25lIGRhdGEgcGxhbmUgc29sdXRpb24gb2Jq ZWN0aXZlLiZxdW90Oy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5QbGVhc2UgY29uc2lkZXIgdGhlIGFib3Zl IGd1aWRlbGluZXMgYXMgeW91IGRlY2lkZSBvbiB3aGV0aGVyIHRvIHN1cHBvcnQgb3Igbm90IHRo aXMgV0cgYWRvcHRpb24uIFBsZWFzZSBleHByZXNzIGNsZWFybHkgeW91ciByZWFzb25pbmcgZm9y IHN1cHBvcnQvbm9uLXN1cHBvcnQgYXMgd2VsbCBhcyBhbnkgb3BlbiBkaXNjdXNzaW9uIHBvaW50 cyB5b3Ugd291bGQgbGlrZQ0KIGFkZHJlc3NlZCBzaG91bGQgdGhlIGRvY3VtZW50IGJlIGFkb3B0 ZWQgaW50byB0aGUgd29ya2luZyBncm91cC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5UaGFua3MhPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbiI+SmltLCBCcnVubyAmYW1wOyBKb2VsPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_E29516CFBF7E457E9EBB0D072C758CCBarrcuscom_-- From nobody Mon Oct 11 00:21:22 2021 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 079563A00C0; Sat, 9 Oct 2021 11:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ost.ch 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 yY4F2R1Vd9cU; Sat, 9 Oct 2021 11:25:06 -0700 (PDT) Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2087.outbound.protection.outlook.com [40.107.21.87]) (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 7D4CE3A00AE; Sat, 9 Oct 2021 11:25:04 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G7zcNAiHInhdc/mvg+XwSYcwb+MXN+47hKOVuWu8rYSksQug5t3Xl5sKrREb7al6qKp1ZeKdwGiHRqhFKOvNb3Pv2JTsQCbzrrH42QFhW7m91hTt9M/dd7hcL8wGgXwi9c2RJvZvl6FXJuY3VIrDkYoxZQILPpK8uKlnTtp+J1CwOQY4ngYFimWt1+IKyM1+fSx9YwmrxkDP8n/c/slPaUwfrwUfsbLowk4tpb2d6X8t8dZeycvvqPFO0ykxw3vyqwYEydHRbBG0vnmWKY5z7YYcLsZYsKJOD2Y7It7LlRwDlxUqdjooxXhRNEuICPY/WIc0O7gOGdLYjxXCOBzuWA== 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=pKxnV8lJ3h5Gy9dRnXEyEaNATe36XoYOecVPZSs6tj4=; b=PpSSvI5UuiaXMM/52MDxw7l0gMeMZawykcV8Nd1ttNTA7tTAajozN1uE0V4E08B41x3SqXuL59UEiNueZmlp3CXRglkfNHbKrhGw6nLDCG4NyBzakbT/HioKFIW4lFftGbqsHaj7gO31zL+44dPk5ONAUcDyHpCLdsbNRqcNnz4xSa+WLDufpCHlrvlSXvH0k3QxbYMkNRc6KP6jU5A5tkCk3gIJLc0hLqig64yIDE/ZjbCGs4mQlJAiMg30ttLsWVnKZduFszMI+UwNUGZsuK0A4FFBkJC92q8Pr9ORjFq3hrcv74MfKrAIRalOyIewNDFEPh7I+5M06/EOdM7VYg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ost.ch; dmarc=pass action=none header.from=ost.ch; dkim=pass header.d=ost.ch; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ost.ch; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pKxnV8lJ3h5Gy9dRnXEyEaNATe36XoYOecVPZSs6tj4=; b=X7bH51x0I4P5rAQs0DfjJYSIhXKnjvP4JX/oiFGbcbkc5ObQBNZ1jd9qyNxiy/ryyQWIMjP30HYTuutlMUBsqQTnUmzmtsR8VcID3vJH1l+l4ex14TneawMhh57qpLp77fBwWjZ2sOXkbxrgdOwojb1kPbbgUNucAKZOTxfSziA= Received: from AS8PR09MB4967.eurprd09.prod.outlook.com (2603:10a6:20b:38e::13) by AM6PR09MB3538.eurprd09.prod.outlook.com (2603:10a6:20b:cb::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.18; Sat, 9 Oct 2021 18:24:55 +0000 Received: from AS8PR09MB4967.eurprd09.prod.outlook.com ([fe80::6846:9ad:7382:9836]) by AS8PR09MB4967.eurprd09.prod.outlook.com ([fe80::6846:9ad:7382:9836%7]) with mapi id 15.20.4587.025; Sat, 9 Oct 2021 18:24:55 +0000 From: Laurent Metzger To: "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: AQHXvTmldih57iK/oUS/9wWCtoW9Mg== Date: Sat, 9 Oct 2021 18:24:55 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 23d86005-b32f-1190-7103-74c2f3af1aac authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ost.ch; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 848db77e-c685-434b-3ab7-08d98b52181d x-ms-traffictypediagnostic: AM6PR09MB3538: x-ld-processed: a6e70fa3-1c7a-4aa2-a25e-836eea52ca22,ExtAddr x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FUKheZVvDHBaFIHYW4NHL8931hrlmPZR5pw+2sm47cX6O0jIIY8OKk6BXmPvSZ5qMLMqG7BvO3JpWFxXAioKrRyKWOB5OXtT/LBmH7gbLdTqHliVxisnziM9OjlN6UylIxKjXmevIhHIaQuKk/i6qo0e0RYz1ddviM+AAAni7LXHuSuiC0/oxhjrOvurt5csKj/e9gjtt0ahRK/1AVb4mJmzmUDx+jZVsadIGWRRZ3A2fFKRnaZy4lWvOqtRqJR1VzOlNIP7mqjTEGCqt7tqPt4XsPFcrvkI4SuxILsm7g+ZHaW7S2uxXbrn+o4t0224wv4GCItN3MiCboCSMX4VsMykAOfmVp4zLu4pHZOaE/EeBgVGLvTCS9/Sn6ID6KeLkeb+TJMtzfeYbdMc7MpBqGTT+kAgW8sc6eA/K+TbheHHYEoKsv8yGXR1Lc5fUjzoou0Nx9HCwxyGQjVOGD4ZHU/HYDT5B+y6AGZRPH45zAIiksRy//FDrsmD9lpH9xufjvV3W5jMCHdLHcD1IzS30nD4KCwtjssPHlkkzZb09pYh7K9p9mZ8HZRZvczASVyEvJFCuninGD12tt4qIuqyh9jJ6VW8lGsTscPepYiJ+Q0tPLP0hGIvgc2qe93yhRNSqYgPJ26sY6DCdHEdKeqLzljMfcFqhd879U3zwQiMFghRA1J31bfuWsWdFSYGWpbnF7zX5BbC6pXEk+GILXA2JWVclp4+7F7iMZhAuzSc+WL6eGFwk8O51DHXnVi3xYC43UQuss71lU2+st1avX3/YywEtytpSHW3BBjS8qCa3n4= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR09MB4967.eurprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(508600001)(122000001)(52536014)(38100700002)(8936002)(71200400001)(5660300002)(4326008)(966005)(7696005)(2906002)(19627405001)(8676002)(186003)(55016002)(66556008)(64756008)(66446008)(38070700005)(786003)(316002)(33656002)(83380400001)(6916009)(66476007)(66946007)(86362001)(53546011)(6506007)(9686003)(44832011)(26005)(166002)(91956017)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?lO4lL3EioCBHfx8pJqQP/GIQMBcVWDUXA3lc99w9BwRGz2lGPdI7VfQK?= =?Windows-1252?Q?vodH7DsUodHyf65+7ZDvQ4qzENRBIwDyCw4t1aMXyvtT6lWMKDrfDCf4?= =?Windows-1252?Q?4eZIaCdg1YXSyPa73IgHiNPvhg2xt9DpnDKItPuC75nktYM6lXP0wVPE?= =?Windows-1252?Q?1C63qKUNPg8BRaXbaDuzQahL9SAvU2BajDQ50N8h7Y8gnp69rogLk1ZO?= =?Windows-1252?Q?u/HtamSzbsq0QDsrWBjB6vKozQ7OvfrKsUpiej2FcmhKX/JKnBHH4JD6?= =?Windows-1252?Q?8bLnlnjcb+/wiZ77L4OeBeymak56Nkw4ght5bE2SZiI9tQd1hrXKwCTe?= =?Windows-1252?Q?ZyCXvbQWSvkN+yGS15bstOdCEjM0uwfpuelTj8a2K8RRCcfiNJyR2d88?= =?Windows-1252?Q?uC88pJGmk8BKrd/c8nQ3Mq/y9jagUPcsMjs1Rn7uM3Z/e9N6UfDNdmLA?= =?Windows-1252?Q?WUuSz9AwQ/qeF8uW//zn7BIsSOOX81nBNwrMl4PZIkh4boCegYwRSvHY?= =?Windows-1252?Q?8MaxZkzfQsDoTk5+GLJ3JE5BpOz8ii/pdUD3OnVEglE/iVxP20ct6/E6?= =?Windows-1252?Q?4kZowVx5txPw9NKJJxnl6AAIHsMZdfJbfcxAxY+mq9razwZcQmPGktKG?= =?Windows-1252?Q?ikDHDbKmbE6gId0ZTDYMkCwDBhC8/SXcflc3vg+WevlDMulwaQbofEk3?= =?Windows-1252?Q?+L6tElgrDt3zoe5gQZNfrDgXS6Gt6I/4Q6LDq9NLski4StPkwgTOI+u4?= =?Windows-1252?Q?2IJZN1Hyg1IziZQFqXFuByQd0xUwpC2174Ua6m4pGknj1LZvFevh/VJp?= =?Windows-1252?Q?ohr9ofQyMRlhdeyhvstTtPh2Kqp0TpICecWbn4U4GJabS5ehJ5suTRJG?= =?Windows-1252?Q?/VtMJT0SDg4TpfhUMyHrMuGphVGc+RH2MCnyKFfqoOgJqjMv5+78Z0dk?= =?Windows-1252?Q?MN7mduVy6mD38weLnGPWgLjBLuVLgEul+sj2na/AnPevuZ+hEtf8/ELy?= =?Windows-1252?Q?tERTjMPmfMC1tmYeG4SegrQdRify8A9htO7RyqZG6q+gMCHxZ/OEIsDx?= =?Windows-1252?Q?aOpmM7dcWxTyHqoJXaoDhw/JmVIZHHEb8vjzrPdtOjb00gaj9dDZ75j+?= =?Windows-1252?Q?Xm6KYkz6D82k2vrN4a9MfUlN7rGov0yh9ZfuE3seV1PMIdmNXqV2Dzk1?= =?Windows-1252?Q?YCndOLP+VayxdIQw/CpEVhj07APPeUTJRMiOsd7+tePyJPvu66mxlGXM?= =?Windows-1252?Q?cjEkMo0NbbQ3frV9scnUzaAyzUwYTb2uzrFTm+JMhL4OZzn+UwNNCha0?= =?Windows-1252?Q?bTJd083EqzOkKetST3JeGHRSMYidDyWs8toaK+7x5Xu8HduLcZvGIzY4?= =?Windows-1252?Q?QOOYd62/YrxiZY+4VToVdeQMBoXWoYRxpM2eW7uoz4cMJXm+rhkAGvzY?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AS8PR09MB49673696CFCB4B7D750EF5B29AB39AS8PR09MB4967eurp_" MIME-Version: 1.0 X-OriginatorOrg: ost.ch X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR09MB4967.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 848db77e-c685-434b-3ab7-08d98b52181d X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2021 18:24:55.4607 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a6e70fa3-1c7a-4aa2-a25e-836eea52ca22 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: D+0xKXT0d7Ql8j8D0yxDXUceMEoQX/bhjSyu716daTc1wQIkouV/BX6TP9fsOFJ/MO/bH9wgARyMKe6wvAaRmQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR09MB3538 Archived-At: X-Mailman-Approved-At: Mon, 11 Oct 2021 00:20:36 -0700 Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 09 Oct 2021 18:25:15 -0000 --_000_AS8PR09MB49673696CFCB4B7D750EF5B29AB39AS8PR09MB4967eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear WG I would like to express support for the WG adoption of the draft https://da= tatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ I have been using the SRv6 encapsulation in various applied research projec= ts at my university and I have mostly experience with the NEXT-C-SID flavor= in projects related to SR-TE and service chaining. I am happy about the fact that the draft describes multiple SRv6 EndPoint b= ehaviors and adds the Combined NEXT-and-REPLACE-C-SID flavor in order to al= low the support of different deployment use cases. It is adding a new flavo= r, in the same way the Penultimate Segment Pop (PSP), Ultimate Segment Pop = (USP), and Ultimate Segment Decapsulation (USD) of the SRH are flavors of t= he End, End.X, and End.T behaviors in the RFC8986. I consider that the draft is proposing a single SRv6 based dataplane that i= s consistent with RFC8986 and I therefore support the WG adoption of the dr= aft. Best Regards, Laurent From: spring on behalf of James Guichard Date: Friday, October 1, 2021 at 4:05 PM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple = SRv6 Endpoint behaviors. 2. The document is a =93living=94 document; it may change as it goes = through review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be addr= essed BEFORE said document is allowed to progress from the working group to= publication. A list of these discussion points will be documented in the W= G document and maintained by the document editor in conjunction with the ch= airs. 4. If this document is adopted by the working group, the chairs speci= fy as part of the adoption call that the following text describing an open = issue be added to the document in the above-described open issues section: =B7 "Given that the working group has said that it wants to standar= dize one data plane solution, and given that the document contains multiple= SRv6 EndPoint behaviors that some WG members have stated are multiple data= plane solutions, the working group will address whether this is valid and = coherent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_AS8PR09MB49673696CFCB4B7D750EF5B29AB39AS8PR09MB4967eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    Dear WG

     

    I would like to express support for the WG adoption of the draft https://datatracker.ietf.org/doc/draft-filsfilscheng-sp= ring-srv6-srh-compression/


    I have been= using the SRv6 encapsulation in various applied research projects at my un= iversity and I have mostly experience with the NEXT-C-SID flavor in project= s related to SR-TE and service chaining. 


    I am happy = about the fact that the draft describes multiple SRv6 EndPoint behaviors and adds the Combined N= EXT-and-REPLACE-C-SID flavor in order to allow the support of different = deployment use cases. It is adding a new flavor, in the same way the Penult= imate Segment Pop (PSP), Ultimate Segment Pop (USP), and Ultimate Segment Decapsulation (USD) of the SRH are flavors of the= End, End.X, and End.T behaviors in the RFC8986. 


    I consid= er that the draft is proposing a single SRv6 based dataplane that is co= nsistent with RFC8986 and I therefore support the WG adoption of the draft.


    Best Regards,

    Laurent



    From: spring <spring-= bounces@ietf.org> on behalf of James Guichard <james.n.guichard@futur= ewei.com>
    Date: Friday, Octob= er 1, 2021 at 4:05 PM
    To: SPRING WG <s= pring@ietf.org>
    Cc: spring-chairs@i= etf.org <spring-chairs@ietf.org>
    Subject: [spring] W= G Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-sp= ring-srv6-srh-compression/
    Dear WG:

    The chairs would li= ke to express their appreciation for all the responses received to our emai= ls with reference to how the working group wishes to move forward with respect to a solution for SRv6 compressi= on.

    The apparent inclin= ation of the working group is to use https://datatracker.ietf.org/doc/draft= -filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardization work. That is part of wha= t this email attempts to confirm.

    Because of the abov= e the chairs would like to issue a 2-week WG call for adoption ending Octob= er 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ but with some clear guidelines as follows. By expressing support for adopt= ion of this document you are fully aware of and are acknowledging that:


    1.     &n= bsp; The SPRING working group is adopting a document that has multiple SRv6= Endpoint behaviors.

    2.     &n= bsp; The document is a =93living=94 document; it may change as it goes thro= ugh review and analysis by the SPRING working group.

    3.     &n= bsp; All open discussion points raised on our mailing list MUST be addresse= d BEFORE said document is allowed to progress from the working group to publication. A list of these discussion points will b= e documented in the WG document and maintained by the document editor in co= njunction with the chairs.

    4.     &n= bsp; If this document is adopted by the working group, the chairs specify a= s part of the adoption call that the following text describing an open issue be added to the document in the above-described o= pen issues section:

    =B7     &= nbsp;   "Given that the working group has said that it wants to s= tandardize one data plane solution, and given that the document contains multiple SRv6 EndPoint behaviors that some WG members have stated= are multiple data plane solutions, the working group will address whether = this is valid and coherent with its one data plane solution objective."= ;.

    Please consider the= above guidelines as you decide on whether to support or not this WG adopti= on. Please express clearly your reasoning for support/non-support as well as any open discussion points you would li= ke addressed should the document be adopted into the working group.<= /div>

    Thanks!

    Jim, Bruno & Joel
    --_000_AS8PR09MB49673696CFCB4B7D750EF5B29AB39AS8PR09MB4967eurp_-- From nobody Mon Oct 11 01:42:57 2021 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 173C43A0C0C; Mon, 11 Oct 2021 01:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SoTOuJGfiWI3; Mon, 11 Oct 2021 01:42:50 -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 4A8FA3A0C08; Mon, 11 Oct 2021 01:42:50 -0700 (PDT) Received: from fraeml738-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HSXK628TRz687y2; Mon, 11 Oct 2021 16:39:22 +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.8; Mon, 11 Oct 2021 10:42:46 +0200 Received: from kwepeml500004.china.huawei.com (7.221.188.141) 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.8; Mon, 11 Oct 2021 16:42:44 +0800 Received: from kwepeml500004.china.huawei.com ([7.221.188.141]) by kwepeml500004.china.huawei.com ([7.221.188.141]) with mapi id 15.01.2308.008; Mon, 11 Oct 2021 16:42:44 +0800 From: Tianran Zhou To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade+eKDNAYyWLN0OQYGZaAvNV9N3dQ== Date: Mon, 11 Oct 2021 08:42:44 +0000 Message-ID: <890a5849737749f0ab36574d2063fde1@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.173.228] Content-Type: multipart/alternative; boundary="_000_890a5849737749f0ab36574d2063fde1huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 11 Oct 2021 08:42:55 -0000 --_000_890a5849737749f0ab36574d2063fde1huaweicom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgQ2hhaXJzIGFuZCBXRywNCg0KSSBzdHJvbmdseSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0 aGlzIGRyYWZ0Lg0KDQpBcyBmYXIgYXMgSSBrbm93LCB0aGVyZSBhcmUgYWxyZWFkeSBtdWx0aXBs ZSB2ZW5kb3JzKDEwKykgc3VwcG9ydCBDU0lEIGFuZCBwYXNzZWQgdGhlIGludGVyb3BlcmF0aW9u IHRlc3QuDQpJIGZvbGxvd2VkIHRoZSBEVCBmb3IgYSB3aGlsZS4gQ1NJRCBhcyBhIFNSdjYgbmF0 aXZlIHNvbHV0aW9uLCBzaG93cyBncmVhdCBhZHZhbnRhZ2VzIHRoYW4gQ1JILg0KVGhpcyBkcmFm dCBpcyBtYXR1cmUgZW5vdWdoIHRvIGJlIGFkb3B0ZWQgYnkgdGhlIFdHLCBhcyB0aGUgYmFzZWxp bmUgZm9yIGZ1cnRoZXIgZGV2ZWxvcG1lbnQuDQoNCkNoZWVycywNClRpYW5yYW4NCg0KDQq3orz+ yMs6IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEphbWVzIEd1 aWNoYXJkDQq3osvNyrG85DogMjAyMcTqMTDUwjHI1SAyMjowNQ0KytW8/sjLOiBTUFJJTkcgV0cg PHNwcmluZ0BpZXRmLm9yZz4NCrOty806IHNwcmluZy1jaGFpcnNAaWV0Zi5vcmcNCtb3zOI6IFtz cHJpbmddIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLw0KDQpE ZWFyIFdHOg0KDQpUaGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gZXhwcmVzcyB0aGVpciBhcHByZWNp YXRpb24gZm9yIGFsbCB0aGUgcmVzcG9uc2VzIHJlY2VpdmVkIHRvIG91ciBlbWFpbHMgd2l0aCBy ZWZlcmVuY2UgdG8gaG93IHRoZSB3b3JraW5nIGdyb3VwIHdpc2hlcyB0byBtb3ZlIGZvcndhcmQg d2l0aCByZXNwZWN0IHRvIGEgc29sdXRpb24gZm9yIFNSdjYgY29tcHJlc3Npb24uDQoNClRoZSBh cHBhcmVudCBpbmNsaW5hdGlvbiBvZiB0aGUgd29ya2luZyBncm91cCBpcyB0byB1c2UgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2 Ni1zcmgtY29tcHJlc3Npb24vIGFzIHRoZSBiYXNpcyBmb3IgaXRzIGNvbXByZXNzaW9uIHN0YW5k YXJkaXphdGlvbiB3b3JrLiBUaGF0IGlzIHBhcnQgb2Ygd2hhdCB0aGlzIGVtYWlsIGF0dGVtcHRz IHRvIGNvbmZpcm0uDQoNCkJlY2F1c2Ugb2YgdGhlIGFib3ZlIHRoZSBjaGFpcnMgd291bGQgbGlr ZSB0byBpc3N1ZSBhIDItd2VlayBXRyBjYWxsIGZvciBhZG9wdGlvbiBlbmRpbmcgT2N0b2JlciAx NXRoIGZvciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2No ZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8gYnV0IHdpdGggc29tZSBjbGVhciBndWlk ZWxpbmVzIGFzIGZvbGxvd3MuIEJ5IGV4cHJlc3Npbmcgc3VwcG9ydCBmb3IgYWRvcHRpb24gb2Yg dGhpcyBkb2N1bWVudCB5b3UgYXJlIGZ1bGx5IGF3YXJlIG9mIGFuZCBhcmUgYWNrbm93bGVkZ2lu ZyB0aGF0Og0KDQoNCiAgMS4gIFRoZSBTUFJJTkcgd29ya2luZyBncm91cCBpcyBhZG9wdGluZyBh IGRvY3VtZW50IHRoYXQgaGFzIG11bHRpcGxlIFNSdjYgRW5kcG9pbnQgYmVoYXZpb3JzLg0KICAy LiAgVGhlIGRvY3VtZW50IGlzIGEgobBsaXZpbmehsSBkb2N1bWVudDsgaXQgbWF5IGNoYW5nZSBh cyBpdCBnb2VzIHRocm91Z2ggcmV2aWV3IGFuZCBhbmFseXNpcyBieSB0aGUgU1BSSU5HIHdvcmtp bmcgZ3JvdXAuDQogIDMuICBBbGwgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyByYWlzZWQgb24gb3Vy IG1haWxpbmcgbGlzdCBNVVNUIGJlIGFkZHJlc3NlZCBCRUZPUkUgc2FpZCBkb2N1bWVudCBpcyBh bGxvd2VkIHRvIHByb2dyZXNzIGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAgdG8gcHVibGljYXRpb24u IEEgbGlzdCBvZiB0aGVzZSBkaXNjdXNzaW9uIHBvaW50cyB3aWxsIGJlIGRvY3VtZW50ZWQgaW4g dGhlIFdHIGRvY3VtZW50IGFuZCBtYWludGFpbmVkIGJ5IHRoZSBkb2N1bWVudCBlZGl0b3IgaW4g Y29uanVuY3Rpb24gd2l0aCB0aGUgY2hhaXJzLg0KICA0LiAgSWYgdGhpcyBkb2N1bWVudCBpcyBh ZG9wdGVkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLCB0aGUgY2hhaXJzIHNwZWNpZnkgYXMgcGFydCBv ZiB0aGUgYWRvcHRpb24gY2FsbCB0aGF0IHRoZSBmb2xsb3dpbmcgdGV4dCBkZXNjcmliaW5nIGFu IG9wZW4gaXNzdWUgYmUgYWRkZWQgdG8gdGhlIGRvY3VtZW50IGluIHRoZSBhYm92ZS1kZXNjcmli ZWQgb3BlbiBpc3N1ZXMgc2VjdGlvbjoNCiAgICAgKiAgICJHaXZlbiB0aGF0IHRoZSB3b3JraW5n IGdyb3VwIGhhcyBzYWlkIHRoYXQgaXQgd2FudHMgdG8gc3RhbmRhcmRpemUgb25lIGRhdGEgcGxh bmUgc29sdXRpb24sIGFuZCBnaXZlbiB0aGF0IHRoZSBkb2N1bWVudCBjb250YWlucyBtdWx0aXBs ZSBTUnY2IEVuZFBvaW50IGJlaGF2aW9ycyB0aGF0IHNvbWUgV0cgbWVtYmVycyBoYXZlIHN0YXRl ZCBhcmUgbXVsdGlwbGUgZGF0YSBwbGFuZSBzb2x1dGlvbnMsIHRoZSB3b3JraW5nIGdyb3VwIHdp bGwgYWRkcmVzcyB3aGV0aGVyIHRoaXMgaXMgdmFsaWQgYW5kIGNvaGVyZW50IHdpdGggaXRzIG9u ZSBkYXRhIHBsYW5lIHNvbHV0aW9uIG9iamVjdGl2ZS4iLg0KDQpQbGVhc2UgY29uc2lkZXIgdGhl IGFib3ZlIGd1aWRlbGluZXMgYXMgeW91IGRlY2lkZSBvbiB3aGV0aGVyIHRvIHN1cHBvcnQgb3Ig bm90IHRoaXMgV0cgYWRvcHRpb24uIFBsZWFzZSBleHByZXNzIGNsZWFybHkgeW91ciByZWFzb25p bmcgZm9yIHN1cHBvcnQvbm9uLXN1cHBvcnQgYXMgd2VsbCBhcyBhbnkgb3BlbiBkaXNjdXNzaW9u IHBvaW50cyB5b3Ugd291bGQgbGlrZSBhZGRyZXNzZWQgc2hvdWxkIHRoZSBkb2N1bWVudCBiZSBh ZG9wdGVkIGludG8gdGhlIHdvcmtpbmcgZ3JvdXAuDQoNClRoYW5rcyENCg0KSmltLCBCcnVubyAm IEpvZWwNCg0KDQo= --_000_890a5849737749f0ab36574d2063fde1huaweicom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

    Hi Chairs and WG,

     

    I strongly support the adoption= of this draft.

     

    As far as I know, there are alr= eady multiple vendors(10+) support CSID and passed the interoperation t= est.

    I followed the DT for a while. = CSID as a SRv6 native solution, shows great advantages than CRH.

    This draft is mature enough to = be adopted by the WG, as the baseline for further development.

     

    Cheers,

    Tianran   =

     

     

    =B7=A2=BC=FE=C8=CB:= spring [mailto:spring-bounces@ietf.org] =B4=FA=B1=ED James Guichard
    =B7=A2=CB=CD=CA=B1=BC=E4:= 2021=C4=EA10=D4=C21=C8=D5 22:05
    =CA=D5=BC=FE=C8=CB: SPRING WG <spring@ietf.org>
    =B3=AD=CB=CD: spring-chairs@ietf.org
    =D6=F7=CC=E2: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-fils= filscheng-spring-srv6-srh-compression/

     

    Dear WG:

     

    The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a sol= ution for SRv6 compression.

     

    The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

     

    Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

     

    1. The SPRING working group is adopting a document that has multiple SRv6 = Endpoint behaviors.
    2. The document is a =A1=B0living=A1=B1 document; i= t may change as it goes through review and analysis by the SPRING working g= roup.
    3. All open discussion points raised on our mailing= list MUST be addressed BEFORE said document is allowed to progress from th= e working group to publication. A list of these discussion points will be documented in the WG document and maintained by the document edito= r in conjunction with the chairs.
    4. If this document is adopted by the working group= , the chairs specify as part of the adoption call that the following text d= escribing an open issue be added to the document in the above-described open issues section:
      • "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution obj= ective.".

     

    Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open d= iscussion points you would like addressed should the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    --_000_890a5849737749f0ab36574d2063fde1huaweicom_-- From nobody Mon Oct 11 04:04:26 2021 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 068693A0D20; Mon, 11 Oct 2021 04:04:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dn4QdoQvS4_n; Mon, 11 Oct 2021 04:04:18 -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 627403A0D1B; Mon, 11 Oct 2021 04:04:18 -0700 (PDT) Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HSbSL3bHpz67Zpj; Mon, 11 Oct 2021 19:00:50 +0800 (CST) Received: from dggema719-chm.china.huawei.com (10.3.20.83) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.8; Mon, 11 Oct 2021 13:04:14 +0200 Received: from dggema769-chm.china.huawei.com (10.1.198.211) by dggema719-chm.china.huawei.com (10.3.20.83) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.8; Mon, 11 Oct 2021 19:04:12 +0800 Received: from dggema769-chm.china.huawei.com ([10.9.128.71]) by dggema769-chm.china.huawei.com ([10.9.128.71]) with mapi id 15.01.2308.008; Mon, 11 Oct 2021 19:04:12 +0800 From: Huzhibo To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQHw6NXw Date: Mon, 11 Oct 2021 11:04:12 +0000 Message-ID: <327e0c0d242b43eeb3ca385990aa4fe7@huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.232.179] Content-Type: multipart/alternative; boundary="_000_327e0c0d242b43eeb3ca385990aa4fe7huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 11 Oct 2021 11:04:24 -0000 --_000_327e0c0d242b43eeb3ca385990aa4fe7huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi SPRING, >From my understanding, REPLACE-CSID flavor and NEXT-CSID flavor just like P= SP, USP, USD flavor defined in RFC8986. I cannot treat PSP, USP, USD as dif= ferent data planes. All the SRv6 behaviors will have different data plane b= ehaviors, but they are built under the same data plane, SRv6. Like we have = different IPv6 address type, different forwarding actions will be bound to = them, but they are under the same IPv6 data plane. >From the implementation aspect, we have implemented REPLACE-CSID in CSID fo= r a long time, and now REPLACE-CSID flavor is available in almost all the H= uawei routers, and over 10 multiple vendors interop test have been made one= year ago. We also have finished the interop-test with NEXT-CSID flavor in = CMCC's lab one years ago. Therefore, from the maturity of running code, I t= hink we should adopt CSID draft. Moreover, from the SPRING WG and the DT outputs, I can see from the rough c= onsensus aspect, we should adopt CSID draft, so I strongly support CSID ado= ption. Thanks Zhibo From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard Sent: Friday, October 1, 2021 10:05 PM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_327e0c0d242b43eeb3ca385990aa4fe7huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi SPRING,

     

    From my understanding, REPLACE-CSID flavor and NEXT-CSID flavor jus= t like PSP, USP, USD flavor defined in RFC8986. I cannot treat PSP, USP, US= D as different data planes. All the SRv6 behaviors will have different data plane behaviors, but they are built und= er the same data plane, SRv6. Like we have different IPv6 address type, dif= ferent forwarding actions will be bound to them, but they are under the sam= e IPv6 data plane.

     

    From the implementation aspect, we have implemented REPLACE-CSID in= CSID for a long time, and now REPLACE-CSID flavor is available in almost a= ll the Huawei routers, and over 10 multiple vendors interop test have been made one year ago. We also have finished th= e interop-test with NEXT-CSID flavor in CMCC’s lab one years ago. The= refore, from the maturity of running code, I think we should adopt CSID dra= ft.

     

    Moreover, from the SPRING WG and the DT outputs, I can see from the= rough consensus aspect, we should adopt CSID draft, so I strongly support = CSID adoption.

     

    Thanks

     

    Zhibo

    From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard
    Sent: Friday, October 1, 2021 10:05 PM
    To: SPRING WG <spring@ietf.org>
    Cc: spring-chairs@ietf.org
    Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

     

    Dear WG:

     

    The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a sol= ution for SRv6 compression.

     

    The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

     

    Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

     

    1. The SPRING working group is adopting a document that has multiple SRv6 = Endpoint behaviors.
    2. The document is a “living” document;= it may change as it goes through review and analysis by the SPRING working= group.
    3. All open discussion points raised on our mailing= list MUST be addressed BEFORE said document is allowed to progress from th= e working group to publication. A list of these discussion points will be documented in the WG document and maintained by the document edito= r in conjunction with the chairs.
    4. If this document is adopted by the working group= , the chairs specify as part of the adoption call that the following text d= escribing an open issue be added to the document in the above-described open issues section:
      • "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution obj= ective.".

     

    Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open d= iscussion points you would like addressed should the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    --_000_327e0c0d242b43eeb3ca385990aa4fe7huaweicom_-- From nobody Mon Oct 11 04:22:26 2021 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 C18393A0DF4; Mon, 11 Oct 2021 04:22:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.098 X-Spam-Level: X-Spam-Status: No, score=-10.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.499, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 RxF-QnsAfpOC; Mon, 11 Oct 2021 04:22:20 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ADEA3A0DF7; Mon, 11 Oct 2021 04:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2752; q=dns/txt; s=iport; t=1633951339; x=1635160939; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=KBGOu5E7WqLF+k9jvGzjz2H55Ot3SRoIFQz0hDBq9BY=; b=hX91EStGgLy0KYzExs3k3g+lP5+ezQDInMgFbKx/xmHnA6OngA2j/KIm D2tSv2U2//5Cz5XOkF4emKP30AUqXH3FJ0UQcI4yLk6yqQYgItcSXHetN BkqaYTi+GMFqIBNH3Z5yPHEYqCnj7QeiEzrT4O/L+ZHr3qpYmnISP88e2 U=; X-IPAS-Result: =?us-ascii?q?A0AEAQBZHWRh/xbLJq1aGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBWYMgVgEoEoR4iQOICwOcMYFoCwEBAQ83CgQBAYR+AoJJJjgTAQIEA?= =?us-ascii?q?QEBAQMCAwEBAQEBAQMBAQUBAQECAQYEgREThTsIJQ2GQwEFHQYPAQU2CxALG?= =?us-ascii?q?AICHwcCAlcGAQwIAQEXglYBgwcPrBl6gTGBAYNiQUaDLIFdBoEQKgGOCkOBS?= =?us-ascii?q?USBFSeDAz6CYwIDgSMFARIBgzmCQyIEinsvQi42BBs4IAJZFoECKhEpvgODO?= =?us-ascii?q?oNxhlWUEQYPBSyDaotshheRKocTjxKMTZkjgXgkaXAzGggbFTuCalAZD4M+i?= =?us-ascii?q?m4WFRmINoVMPwNoAgYBCgEBAwmUFQEB?= IronPort-Data: A9a23:fSvyyKz9MI5Fgutfo/h6t+efxCrEfRIJ4+MujC+fZmUNrF6WrkVRn zAZWzjVOP2PZmb9eIt/aIq/pklUuseDzdRlTFA6pFhgHilAwSbn6Xt1DatR0we6dJCroJdPt p1GAjX4wURdokb0/n9BCJC5xZVH/fzOFueU5NLsYHgrHFY8EX550HqPpsZg6mJWqYnha++yk YuaT/33YDdJDBYtbwr4Q4rawP9elKyaVAEw5zTSVtgX1LPqrET5ObpETU2Hw9QUdaEPdgKyb 76rILhUZQo19T91Yj+uuu6TnkHn3tc+MCDW4ke6VZROjTB5twIwkfoYacMedEpVrRiYvdVM8 uxC4MnYpQcBZsUgmcwUXgMdGCZkMOgfvrTGOnO498eUyiUqcVO1nK4oVxFwZ9VDvLwtaY1N3 aRwxDQldgiYiuS/w5qwS/JngYIoK8yD0IY34SE7nW+HVqdOrZbrAITO1OVS2RkKpONXENfOR cAYaDpDVUGVC/FIEhJNYH4kp8+qj3zyaHte7l2IpKE36nLf5AJszKX3PcXYe5qBQsA9tl2Av GPA8Ez4Dw0UctuFxlKt6Wq2h+nA2Cj7UYMID5W5++JkxlqJyQQu5AY+XFah5PihjVSiHtRWN wof+zElqu4580nDosTBYiBUaUWs5nY0M+e82cVjgO1R4sI4OzqkO1U= IronPort-HdrOrdr: A9a23:HBMzoK9dyurqQFV/MUtuk+DpI+orL9Y04lQ7vn2ZhyY4TiXqrb HIoB19726TtN9xYgBFpTnuAsm9qB/nm6KdpLNhWItKPzOW2ldATrsC0WKK+VSJcBEWtNQz6U 4KScJD4bPLYGSSwfyKgzVR170bsaG6GGfCv5am80tQ X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.85,364,1624320000"; d="scan'208";a="38386639" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Oct 2021 11:22:16 +0000 Received: from [10.147.24.16] ([10.147.24.16]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id 19BBMGTY006099; Mon, 11 Oct 2021 11:22:16 GMT To: James Guichard , SPRING WG Cc: "spring-chairs@ietf.org" References: From: Peter Psenak Message-ID: <13edfe61-924b-df7c-b208-7c66b2694c1a@cisco.com> Date: Mon, 11 Oct 2021 13:22:16 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.147.24.16, [10.147.24.16] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 11 Oct 2021 11:22:25 -0000 I support the adoption of the draft by the SPRING WG to continue the work on it. The draft adds new flavors to the SR endpoint behaviors for the support of the SRv6 Segment-List compression in conformance with the RFC 8754 and the RFC 8986. thanks, Peter On 01/10/2021 16:04, James Guichard wrote: > Dear WG: > > The chairs would like to express their appreciation for all the > responses received to our emails with reference to how the working group > wishes to move forward with respect to a solution for SRv6 compression. > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > as the basis for its compression standardization work. That is part of > what this email attempts to confirm. > > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15^th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging > that: > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a “living” document; it may change as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the > working group to publication. A list of these discussion points will > be documented in the WG document and maintained by the document > editor in conjunction with the chairs. > 4. If this document is adopted by the working group, the chairs specify > as part of the adoption call that the following text describing an > open issue be added to the document in the above-described open > issues section: > * "Given that the working group has said that it wants to > standardize one data plane solution, and given that the document > contains multiple SRv6 EndPoint behaviors that some WG members > have stated are multiple data plane solutions, the working group > will address whether this is valid and coherent with its one > data plane solution objective.". > > Please consider the above guidelines as you decide on whether to support > or not this WG adoption. Please express clearly your reasoning for > support/non-support as well as any open discussion points you would like > addressed should the document be adopted into the working group. > > Thanks! > > Jim, Bruno & Joel > From nobody Mon Oct 11 05:46:52 2021 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 359FE3A05F0; Mon, 11 Oct 2021 05:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 yqRqo5sn-nG5; Mon, 11 Oct 2021 05:46:42 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01olkn0158.outbound.protection.outlook.com [104.47.92.158]) (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 B6F553A0603; Mon, 11 Oct 2021 05:46:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dTPq97tkIJy24ApDOKZlAxkhsfkpsJE1G/YQxtkfBLelT6L9Lap0SvJxLz0VC0Gt/jCUP3CKzvktxu4kQgkbG7hc4oZPVDR35dF11uMPxBK6zvMpiDzu+PfwUQA3CIINJIekP9RHNTBQCkpsi/PfBHJ4lKXiBb7LqB5nMqZjVpEkyaY7n/y+TF2ckRqTwirJ4O8uHRzzi2F+OyOBG49/OVWyYguh/lybeQ9HKKceG/3XRQxynosJD40Qt2SkYB3CHDj9oISZ+CI4/epwL36XCTQultliCE08bnKnuGQKJYLO84xJhiEzKo2GhYd9J6weFsidy1YoUdn19AcHed72nQ== 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=YDbXBReHzdMONNo+s7THaFws4ljmq/oVsrWmny1QfjE=; b=oHD6Q6t5+t+duQQEmBgTeZO9AR/gxcqnZYLtBm8XDFvMK8zsQ8u1lacgDKjyitfGlI5rrHKVzstElyAPjQ64tU8qHaScW32eMf+Qy7QU4/qgFfS5xCsFI394dWmoLBoi4cgrB2wDRc2KE9owcXVv3SbcellyKQJwIY0Dq0BvEq2ZSwMuHpm6Y/1o9aU2Fge4fafR6UIXWgQIEL0yIiA0si9gqWJP1RTz1P9L8yAqYPGla34JafP8MoD5LXN50AvnKTuWZNS0g0an8UYFarn7y1JrvV9Uy+TjzV2IGd4tQ1n1N5ck71h+vINw/sxavX6eeSh9JKSCluAVlNdQjtm72Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YDbXBReHzdMONNo+s7THaFws4ljmq/oVsrWmny1QfjE=; b=E9nVMWkFSrJD5Nl8NCPHNZ3ZJ3IfIFePaXJZJb1S+zQEu3lF2d5vIMItzZTnvt15pGT52luPSnBwLOapi5Sov1X8j775dAm5U132vjkeTeK4EHlykrfvznWpU8C79gXuNgOPbq1bQKKEGsfpox5+89xBLLs2kWFSF/ZWVFqDHKZbHiMiiTm1hyiooPPxG0av3lyCo0IluuljL/gdq3uTJS53BVua9BlekxutZlsrzD3O4JuRHp0eFmM1UF5msglyHEUH62PsVsddXPOgyY1T/AqlZlqsbkqJDViRzGALU6zh4Id+2XH/GXmPfChN9eXFdcUiyKw/wspIAmRjejPFbw== Received: from TYWP286MB2235.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:170::10) by TYYP286MB1811.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:f9::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.18; Mon, 11 Oct 2021 12:46:38 +0000 Received: from TYWP286MB2235.JPNP286.PROD.OUTLOOK.COM ([fe80::a85a:5e91:319:1f3f]) by TYWP286MB2235.JPNP286.PROD.OUTLOOK.COM ([fe80::a85a:5e91:319:1f3f%9]) with mapi id 15.20.4587.026; Mon, 11 Oct 2021 12:46:38 +0000 Date: Mon, 11 Oct 2021 20:48:33 +0800 From: "liupengyjy@outlook.com" To: "James Guichard" , spring Cc: spring-chairs References: X-GUID: 6BEDB9F2-5C40-4220-A8B6-C8C1E96C847D X-Has-Attach: no X-Mailer: Foxmail 7.2.21.453[cn] Message-ID: Content-Type: multipart/alternative; boundary="----=_001_NextPart228815232667_=----" X-TMN: [LUyHJATC83O9hQv5OL+625qJjGkJpShMnNlZAcyCDts=] X-ClientProxiedBy: HK2PR0302CA0003.apcprd03.prod.outlook.com (2603:1096:202::13) To TYWP286MB2235.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:170::10) X-Microsoft-Original-Message-ID: <202110112048306004353@outlook.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from CMCC-LP (117.136.117.168) by HK2PR0302CA0003.apcprd03.prod.outlook.com (2603:1096:202::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.4 via Frontend Transport; Mon, 11 Oct 2021 12:46:37 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3daf8d09-31d0-491a-1ec3-08d98cb52ab0 X-MS-TrafficTypeDiagnostic: TYYP286MB1811: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: u50RzW6BrYk5TbV95EvmETaZVFL2mELJ1+smpqvS2WuKFf3cnV2FxObNrkJFI3Sf3i8yK4Tj2gFPJxVaLrQgO3X9ckwj90xguoFG3YF7ldxo0PcHz24W4mrxEo+zTJxKPrOhwiZQjPXDloJYDNtYMJ8+p0G2A3gsApqTsPghdHcvQ25T0ayJki7/Tls+xMNdZYNM8BVITzrIZg+PBhtJGU3g58PC26NQj7YF0N7Gdckaogt/2tywG1aXTHSsUNv5G9k4heBOY6hRinCFWRazWqSZ0teBqWp5eUR+mGwPQ0tKkhkt/key64aDtGjpNmubRSk2bLpUgdQLt5DVl/VesgZHpfcZfjD2FvRkcoXV/5YuY/XCEO6dMR09nY6TWI42+wMMjaaRIOzOg//HeGSnc5GMo84BJL8IXX54jYWjLWbU5kBeDyk8PClCn3RYXcidJXhtTbkL2DAwPer/mVsOCtArq/HLlHCD+Rg8a9XMxLk= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: VIZNoY5igHttX339fMSMDr1kyHrETcHMTgaj6JQvch7gh9V2KGAdJoNEk9k9kM15W0rtdMNuFmOphopWJEN5AqfctXeSin6FHLACy1E72oFFgT4ywO4O3Xv3GF6WJk/+h1K0XQnEJ8EQAN648l0XZw== X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3daf8d09-31d0-491a-1ec3-08d98cb52ab0 X-MS-Exchange-CrossTenant-AuthSource: TYWP286MB2235.JPNP286.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Oct 2021 12:46:38.6683 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYYP286MB1811 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 11 Oct 2021 12:46:47 -0000 ------=_001_NextPart228815232667_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2hhaXJzICYgV0csDQoNCkkgc3VwcG9ydCB0aGUgYWRvcHRpb24gY2FsbC4gUmVnYXJkaW5n IGNoYWly4oCZcyBub3RlIGluIHRoZSBlbWFpbCwgSSB3b3VsZCBsaWtlIHRvIHBvaW50IHRoYXQg Q1NJRCBpcyBzaW5nbGUgU1J2NiBiYXNlZCBkYXRhIHBsYW5lIHRoYXQgZGVmaW5lcyBuZXh0IGFu ZCByZXBsYWNlIGJlaGF2aW9ycyBjb25zaXN0ZW50IHdpdGggdGhlIG5ldHdvcmsgcHJvZ3JhbW1p bmcgcGFyYWRpZ20uDQoNClJlZ2FyZHMsDQpQZW5nIExpdShDTUNDKQ0KDQoNCg0KbGl1cGVuZ3lq eUBvdXRsb29rLmNvbQ0KIA0KRnJvbTogSmFtZXMgR3VpY2hhcmQNCkRhdGU6IDIwMjEtMTAtMDEg MjI6MDQNClRvOiBTUFJJTkcgV0cNCkNDOiBzcHJpbmctY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0 OiBbc3ByaW5nXSBXRyBBZG9wdGlvbiBjYWxsIGZvciBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8N CkRlYXIgV0c6DQogDQpUaGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gZXhwcmVzcyB0aGVpciBhcHBy ZWNpYXRpb24gZm9yIGFsbCB0aGUgcmVzcG9uc2VzIHJlY2VpdmVkIHRvIG91ciBlbWFpbHMgd2l0 aCByZWZlcmVuY2UgdG8gaG93IHRoZSB3b3JraW5nIGdyb3VwIHdpc2hlcyB0byBtb3ZlIGZvcndh cmQgd2l0aCByZXNwZWN0IHRvIGEgc29sdXRpb24gZm9yIFNSdjYgY29tcHJlc3Npb24uIA0KIA0K VGhlIGFwcGFyZW50IGluY2xpbmF0aW9uIG9mIHRoZSB3b3JraW5nIGdyb3VwIGlzIHRvIHVzZSBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmlu Zy1zcnY2LXNyaC1jb21wcmVzc2lvbi8gYXMgdGhlIGJhc2lzIGZvciBpdHMgY29tcHJlc3Npb24g c3RhbmRhcmRpemF0aW9uIHdvcmsuIFRoYXQgaXMgcGFydCBvZiB3aGF0IHRoaXMgZW1haWwgYXR0 ZW1wdHMgdG8gY29uZmlybS4NCiANCkJlY2F1c2Ugb2YgdGhlIGFib3ZlIHRoZSBjaGFpcnMgd291 bGQgbGlrZSB0byBpc3N1ZSBhIDItd2VlayBXRyBjYWxsIGZvciBhZG9wdGlvbiBlbmRpbmcgT2N0 b2JlciAxNXRoIGZvciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxz Zmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8gYnV0IHdpdGggc29tZSBjbGVh ciBndWlkZWxpbmVzIGFzIGZvbGxvd3MuIEJ5IGV4cHJlc3Npbmcgc3VwcG9ydCBmb3IgYWRvcHRp b24gb2YgdGhpcyBkb2N1bWVudCB5b3UgYXJlIGZ1bGx5IGF3YXJlIG9mIGFuZCBhcmUgYWNrbm93 bGVkZ2luZyB0aGF0OiANCiANClRoZSBTUFJJTkcgd29ya2luZyBncm91cCBpcyBhZG9wdGluZyBh IGRvY3VtZW50IHRoYXQgaGFzIG11bHRpcGxlIFNSdjYgRW5kcG9pbnQgYmVoYXZpb3JzLiANClRo ZSBkb2N1bWVudCBpcyBhIOKAnGxpdmluZ+KAnSBkb2N1bWVudDsgaXQgbWF5IGNoYW5nZSBhcyBp dCBnb2VzIHRocm91Z2ggcmV2aWV3IGFuZCBhbmFseXNpcyBieSB0aGUgU1BSSU5HIHdvcmtpbmcg Z3JvdXAuIA0KQWxsIG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgcmFpc2VkIG9uIG91ciBtYWlsaW5n IGxpc3QgTVVTVCBiZSBhZGRyZXNzZWQgQkVGT1JFIHNhaWQgZG9jdW1lbnQgaXMgYWxsb3dlZCB0 byBwcm9ncmVzcyBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIHRvIHB1YmxpY2F0aW9uLiBBIGxpc3Qg b2YgdGhlc2UgZGlzY3Vzc2lvbiBwb2ludHMgd2lsbCBiZSBkb2N1bWVudGVkIGluIHRoZSBXRyBk b2N1bWVudCBhbmQgbWFpbnRhaW5lZCBieSB0aGUgZG9jdW1lbnQgZWRpdG9yIGluIGNvbmp1bmN0 aW9uIHdpdGggdGhlIGNoYWlycy4gDQpJZiB0aGlzIGRvY3VtZW50IGlzIGFkb3B0ZWQgYnkgdGhl IHdvcmtpbmcgZ3JvdXAsIHRoZSBjaGFpcnMgc3BlY2lmeSBhcyBwYXJ0IG9mIHRoZSBhZG9wdGlv biBjYWxsIHRoYXQgdGhlIGZvbGxvd2luZyB0ZXh0IGRlc2NyaWJpbmcgYW4gb3BlbiBpc3N1ZSBi ZSBhZGRlZCB0byB0aGUgZG9jdW1lbnQgaW4gdGhlIGFib3ZlLWRlc2NyaWJlZCBvcGVuIGlzc3Vl cyBzZWN0aW9uOg0KIkdpdmVuIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHNhaWQgdGhhdCBp dCB3YW50cyB0byBzdGFuZGFyZGl6ZSBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiwgYW5kIGdpdmVu IHRoYXQgdGhlIGRvY3VtZW50IGNvbnRhaW5zIG11bHRpcGxlIFNSdjYgRW5kUG9pbnQgYmVoYXZp b3JzIHRoYXQgc29tZSBXRyBtZW1iZXJzIGhhdmUgc3RhdGVkIGFyZSBtdWx0aXBsZSBkYXRhIHBs YW5lIHNvbHV0aW9ucywgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhZGRyZXNzIHdoZXRoZXIgdGhp cyBpcyB2YWxpZCBhbmQgY29oZXJlbnQgd2l0aCBpdHMgb25lIGRhdGEgcGxhbmUgc29sdXRpb24g b2JqZWN0aXZlLiIuDQogDQpQbGVhc2UgY29uc2lkZXIgdGhlIGFib3ZlIGd1aWRlbGluZXMgYXMg eW91IGRlY2lkZSBvbiB3aGV0aGVyIHRvIHN1cHBvcnQgb3Igbm90IHRoaXMgV0cgYWRvcHRpb24u IFBsZWFzZSBleHByZXNzIGNsZWFybHkgeW91ciByZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9uLXN1 cHBvcnQgYXMgd2VsbCBhcyBhbnkgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyB5b3Ugd291bGQgbGlr ZSBhZGRyZXNzZWQgc2hvdWxkIHRoZSBkb2N1bWVudCBiZSBhZG9wdGVkIGludG8gdGhlIHdvcmtp bmcgZ3JvdXAuDQogDQpUaGFua3MhDQogDQpKaW0sIEJydW5vICYgSm9lbA0KIA0KIA0K ------=_001_NextPart228815232667_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable body { line-height: 1.5; }blockquote { margin-top: 0px; margin-bottom:= 0px; margin-left: 0.5em; }ol, ul { margin-top: 0px; margin-bottom: 0px; li= st-style-position: inside; }p { margin-top: 0px; margin-bottom: 0px; }div.F= oxDiv20211011204508693456 { overflow-wrap: break-word; }body { font-size: 1= 4px; font-family: "Microsoft YaHei UI"; color: rgb(0, 0, 0); line-height: 1= .5; }=0A= =0A=
    Hi Ch= airs & WG,

    I support the adoption call. Regarding chair=E2=80=99s note in t= he email, I would like to point that CSID is single SRv6 based data plane t= hat defines next and replace behaviors consistent with the network programm= ing paradigm.

    Regards,
    Peng Liu(CMCC)
    =0A=

    =0A=
    liupengyjy@outlook.com
    =0A=
     
    =0A= =0A=
    =0A=

    Dear WG:

    =0A=

     

    =0A=

    The chairs would like to express their appreciation f= or all the responses received to our emails with reference to how the worki= ng group wishes to move forward with respect to a solution for SRv6 compres= sion.=0A=

    =0A=

     

    =0A=

    The apparent inclination of the working group is to u= se =0A= https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

    =0A=

     

    =0A=

    Because of the above the chairs would like to issue a= 2-week WG call for adoption ending October 15th for=0A= =0A= https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:=0A=

    =0A=

     

    =0A=
      = =0A=
    1. The SPRING working group is ado= pting a document that has multiple SRv6 Endpoint behaviors.=0A=
    2. The document is= a =E2=80=9Cliving=E2=80=9D document; it may change as it goes through revi= ew and analysis by the SPRING working group.=0A=
    3. All open discus= sion points raised on our mailing list MUST be addressed BEFORE said docume= nt is allowed to progress from the working group to publication. A list of = these discussion=0A= points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.=0A=
    4. If this documen= t is adopted by the working group, the chairs specify as part of the adopti= on call that the following text describing an open issue be added to the do= cument in the above-described=0A= open issues section:
        5. =0A=
      • "Given that the working group has said that = it wants to standardize one data plane solution, and given that the documen= t contains multiple SRv6 EndPoint behaviors that some WG members have state= d are=0A= multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".
      =0A=
    =0A=

     

    =0A=

    Please consider the above guidelines as you decide on= whether to support or not this WG adoption. Please express clearly your re= asoning for support/non-support as well as any open discussion points you w= ould like addressed should the document=0A= be adopted into the working group.

    =0A=

     

    =0A=

    Thanks!

    =0A=

     

    =0A=

    Jim, Bruno & Joel

    =0A=

     

    =0A=

     

    =0A=
    =0A=
    =0A= = ------=_001_NextPart228815232667_=------ From nobody Mon Oct 11 07:11:39 2021 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 EDA163A0CC9; Mon, 11 Oct 2021 07:11:36 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: 0.849 X-Spam-Level: X-Spam-Status: No, score=0.849 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, HELO_DYNAMIC_IPADDR=1.951, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=foxmail.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 JH416BOcSB4X; Mon, 11 Oct 2021 07:11:32 -0700 (PDT) Received: from out162-62-57-137.mail.qq.com (out162-62-57-137.mail.qq.com [162.62.57.137]) (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 6F0453A0CC8; Mon, 11 Oct 2021 07:11:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=foxmail.com; s=s201512; t=1633961480; bh=1Q0DTGs1VIwO7i/tifS8Eo2LKmSlNhqQSIYb81lk2rM=; h=Date:From:To:Cc:Subject:References; b=wviKyaZeknPbFO2BeYoZbMNLWyu64wqcd+Vq70Cz1j91OsY0CjRn1Gekh13llWd9J z2lRV7xVNqv53Emv42UMNU4yj0426CvLo1lAhUGqn23NKk7NInAqtcSAyQg71WxHtc n9DLZRh/DYBrgkruir0vvKX7GelFTGcgIWv6kXos= Received: from cmcc-PC ([36.7.134.125]) by newxmesmtplogicsvrsza7.qq.com (NewEsmtp) with SMTP id 28303818; Mon, 11 Oct 2021 22:10:03 +0800 X-QQ-mid: xmsmtpt1633961403thb4k9rd8 Message-ID: X-QQ-XMAILINFO: MpO6L0LObisWMc8X6vmsIAeic+Ti5labYaSk/+9zazKasgjAMCFLHPuaM04Kxk vqMQI4JC1rb3Qa8BS6pjvLse/8AknUPdL9akAMYeGEl7kevZ+tkT8NIgrJUxm63dZ4kiRTK2JtxP suAp+9tU8YI8LTFhCyf+Pc80E5VoKA3RYT5/sWrIFfwp2YqDsQePTRls+DBBuGRFqlbXB9k3VYfM 8JiGJ5zJr8v9GHwNTc/YyKsUuUqyAxN7GCQ7iSF9aZdjnzzO9BPoUo3kfW7e0g1J2qW17oalN6kF X2u0PMnnZcL6s1KFj5w8mp9T/txbYLaCtmJFYzKJa232I+shVdMTehycOfELIOVKsUJK4giZtXAy uPzvR5bi6zwwAaGVnQHBMyOito9oCATYwI8hCUfs4SuPzs6dKjKBdyVhk7+ls+W9O4TwQ/46jlGm W5lEOQ4OuNRmH2ZttEC+cxPAb4Yz+Mr/B79UU+MfTLlK+KXe0ilKfC+6i5tRQBT1Xk+0QJrEI97z H0UC9KdAUFyPiS4ogItXTWj++GSn5i2sXlWpoX3wPucHtObsUbg2cblc3oUO5j1R1kkcSWCecyAF IejDAvjb9Ws6ePtfCHNdIM0ZRaMsryb7dhSTa5yVLTHJEMaXm8EGiB1OU1I8eNDed1qyhm/bvwnl tZ+Ds7ayJr8dXbgip/Io2bELCaES6sF2N929FSYU6WB+FYmyL7VrSmymlvTKZaCsFxCLt7v7Q6QK plKW38xnw1JCqKMkkHqrFJ0oHiJUoy2wSCLTN0r0uaSiGEaH88/XUiBVBq+1n2yFRcGMHZoUgyXw a1mARQp0Pf5cHfRhqIV0Uoqbm4jjg2zxvWIzFMVuVJQRdoMh6uVDMNQ3Xpg+tzzLWlOekMozD5UA == Date: Mon, 11 Oct 2021 22:11:27 +0800 From: "duzongpeng@foxmail.com" To: "James Guichard" , "spring@ietf.org" Cc: "spring-chairs@ietf.org" References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.15.80[cn] Mime-Version: 1.0 Message-ID: <202110112211267553564@foxmail.com> Content-Type: multipart/alternative; boundary="----=_001_NextPart008427036260_=----" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 11 Oct 2021 14:11:37 -0000 This is a multi-part message in MIME format. ------=_001_NextPart008427036260_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIGFsbA0KDQogICAgSSBzdXBwb3J0IHRoZSBhZG9wdGlvbi4gQ1NJRCBpcyBhIG5lZWRlZCBz b2x1dGlvbiBmb3IgdGhlIFNSdjYgYmFzZWQgZGF0YSBwbGFuZS4gDQoNCkJlc3QgUmVnYXJkcw0K Wm9uZ3BlbmcgRHUNCg0KDQpkdXpvbmdwZW5nQGZveG1haWwuY29tICYgZHV6b25ncGVuZ0BjaGlu YW1vYmlsZS5jb20NCiANCkZyb206IEphbWVzIEd1aWNoYXJkDQpEYXRlOiAyMDIxLTEwLTAxIDIy OjA0DQpUbzogU1BSSU5HIFdHDQpDQzogc3ByaW5nLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDog W3NwcmluZ10gV0cgQWRvcHRpb24gY2FsbCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vDQpE ZWFyIFdHOg0KIA0KVGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGV4cHJlc3MgdGhlaXIgYXBwcmVj aWF0aW9uIGZvciBhbGwgdGhlIHJlc3BvbnNlcyByZWNlaXZlZCB0byBvdXIgZW1haWxzIHdpdGgg cmVmZXJlbmNlIHRvIGhvdyB0aGUgd29ya2luZyBncm91cCB3aXNoZXMgdG8gbW92ZSBmb3J3YXJk IHdpdGggcmVzcGVjdCB0byBhIHNvbHV0aW9uIGZvciBTUnY2IGNvbXByZXNzaW9uLiANCiANClRo ZSBhcHBhcmVudCBpbmNsaW5hdGlvbiBvZiB0aGUgd29ya2luZyBncm91cCBpcyB0byB1c2UgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmct c3J2Ni1zcmgtY29tcHJlc3Npb24vIGFzIHRoZSBiYXNpcyBmb3IgaXRzIGNvbXByZXNzaW9uIHN0 YW5kYXJkaXphdGlvbiB3b3JrLiBUaGF0IGlzIHBhcnQgb2Ygd2hhdCB0aGlzIGVtYWlsIGF0dGVt cHRzIHRvIGNvbmZpcm0uDQogDQpCZWNhdXNlIG9mIHRoZSBhYm92ZSB0aGUgY2hhaXJzIHdvdWxk IGxpa2UgdG8gaXNzdWUgYSAyLXdlZWsgV0cgY2FsbCBmb3IgYWRvcHRpb24gZW5kaW5nIE9jdG9i ZXIgMTV0aCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2Zp bHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vIGJ1dCB3aXRoIHNvbWUgY2xlYXIg Z3VpZGVsaW5lcyBhcyBmb2xsb3dzLiBCeSBleHByZXNzaW5nIHN1cHBvcnQgZm9yIGFkb3B0aW9u IG9mIHRoaXMgZG9jdW1lbnQgeW91IGFyZSBmdWxseSBhd2FyZSBvZiBhbmQgYXJlIGFja25vd2xl ZGdpbmcgdGhhdDogDQogDQpUaGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAgaXMgYWRvcHRpbmcgYSBk b2N1bWVudCB0aGF0IGhhcyBtdWx0aXBsZSBTUnY2IEVuZHBvaW50IGJlaGF2aW9ycy4gDQpUaGUg ZG9jdW1lbnQgaXMgYSDigJxsaXZpbmfigJ0gZG9jdW1lbnQ7IGl0IG1heSBjaGFuZ2UgYXMgaXQg Z29lcyB0aHJvdWdoIHJldmlldyBhbmQgYW5hbHlzaXMgYnkgdGhlIFNQUklORyB3b3JraW5nIGdy b3VwLiANCkFsbCBvcGVuIGRpc2N1c3Npb24gcG9pbnRzIHJhaXNlZCBvbiBvdXIgbWFpbGluZyBs aXN0IE1VU1QgYmUgYWRkcmVzc2VkIEJFRk9SRSBzYWlkIGRvY3VtZW50IGlzIGFsbG93ZWQgdG8g cHJvZ3Jlc3MgZnJvbSB0aGUgd29ya2luZyBncm91cCB0byBwdWJsaWNhdGlvbi4gQSBsaXN0IG9m IHRoZXNlIGRpc2N1c3Npb24gcG9pbnRzIHdpbGwgYmUgZG9jdW1lbnRlZCBpbiB0aGUgV0cgZG9j dW1lbnQgYW5kIG1haW50YWluZWQgYnkgdGhlIGRvY3VtZW50IGVkaXRvciBpbiBjb25qdW5jdGlv biB3aXRoIHRoZSBjaGFpcnMuIA0KSWYgdGhpcyBkb2N1bWVudCBpcyBhZG9wdGVkIGJ5IHRoZSB3 b3JraW5nIGdyb3VwLCB0aGUgY2hhaXJzIHNwZWNpZnkgYXMgcGFydCBvZiB0aGUgYWRvcHRpb24g Y2FsbCB0aGF0IHRoZSBmb2xsb3dpbmcgdGV4dCBkZXNjcmliaW5nIGFuIG9wZW4gaXNzdWUgYmUg YWRkZWQgdG8gdGhlIGRvY3VtZW50IGluIHRoZSBhYm92ZS1kZXNjcmliZWQgb3BlbiBpc3N1ZXMg c2VjdGlvbjoNCiJHaXZlbiB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBzYWlkIHRoYXQgaXQg d2FudHMgdG8gc3RhbmRhcmRpemUgb25lIGRhdGEgcGxhbmUgc29sdXRpb24sIGFuZCBnaXZlbiB0 aGF0IHRoZSBkb2N1bWVudCBjb250YWlucyBtdWx0aXBsZSBTUnY2IEVuZFBvaW50IGJlaGF2aW9y cyB0aGF0IHNvbWUgV0cgbWVtYmVycyBoYXZlIHN0YXRlZCBhcmUgbXVsdGlwbGUgZGF0YSBwbGFu ZSBzb2x1dGlvbnMsIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYWRkcmVzcyB3aGV0aGVyIHRoaXMg aXMgdmFsaWQgYW5kIGNvaGVyZW50IHdpdGggaXRzIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uIG9i amVjdGl2ZS4iLg0KIA0KUGxlYXNlIGNvbnNpZGVyIHRoZSBhYm92ZSBndWlkZWxpbmVzIGFzIHlv dSBkZWNpZGUgb24gd2hldGhlciB0byBzdXBwb3J0IG9yIG5vdCB0aGlzIFdHIGFkb3B0aW9uLiBQ bGVhc2UgZXhwcmVzcyBjbGVhcmx5IHlvdXIgcmVhc29uaW5nIGZvciBzdXBwb3J0L25vbi1zdXBw b3J0IGFzIHdlbGwgYXMgYW55IG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgeW91IHdvdWxkIGxpa2Ug YWRkcmVzc2VkIHNob3VsZCB0aGUgZG9jdW1lbnQgYmUgYWRvcHRlZCBpbnRvIHRoZSB3b3JraW5n IGdyb3VwLg0KIA0KVGhhbmtzIQ0KIA0KSmltLCBCcnVubyAmIEpvZWwNCiANCiANCg== ------=_001_NextPart008427036260_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A=0A
    Hi, all

        I support the adoption.= CSID is a needed solution for the SRv6 based data plane. 
    =0A
    Best Regards
    Zongpeng Du
    =0A
    duzongpeng@foxmail.com & duzongpeng@chinamobile.com
    <= span style=3D"font-size: 13.3333px; color: rgb(0, 0, 0); background-color:= rgba(0, 0, 0, 0); font-size: 13.3333px;">
    =0A
     
    From: <= a href=3D"mailto:james.n.guichard@futurewei.com">James Guichard
    <= div>Date: 2021-10-01 22:04
    Subject: [spring] WG Adoption call for https://datatracker.i= etf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
    =0A=0A
    =0A

    Dear WG:

    =0A

     

    =0A

    The chairs would like = to express their appreciation for all the responses received to our emails= with reference to how the working group wishes to move forward with respe= ct to a solution for SRv6 compression.=0A

    =0A

     

    =0A

    The apparent inclin= ation of the working group is to use =0Ahttps://datatr= acker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as= the basis for its compression standardization work. That is part of what = this email attempts to confirm.

    =0A

     

    =0A

    Because of the above the chai= rs would like to issue a 2-week WG call for adoption ending October 15th for=0A=0Ahttps://datatracker.ietf.org/doc/dr= aft-filsfilscheng-spring-srv6-srh-compression/ but with some clear gui= delines as follows. By expressing support for adoption of this document yo= u are fully aware of and are acknowledging that:=0A

    =0A

     

    =0A
      =0A
    1. The SPRING working group is adopting a document that has m= ultiple SRv6 Endpoint behaviors.=0A
    2. The document is a =E2=80=9Cliving=E2=80=9D document;= it may change as it goes through review and analysis by the SPRING workin= g group.=0A
    3. Al= l open discussion points raised on our mailing list MUST be addressed BEFO= RE said document is allowed to progress from the working group to publicat= ion. A list of these discussion=0A points will be documented in the WG doc= ument and maintained by the document editor in conjunction with the chairs= .=0A
    4. If this d= ocument is adopted by the working group, the chairs specify as part of the= adoption call that the following text describing an open issue be added t= o the document in the above-described=0A open issues section:
        =0A"Given that the working group has said that it wan= ts to standardize one data plane solution, and given that the document con= tains multiple SRv6 EndPoint behaviors that some WG members have stated ar= e=0A multiple data plane solutions, the working group will address whether= this is valid and coherent with its one data plane solution objective.".<= o:p>
      =0A
    =0A

     =0A

    Please consider the above guidelines as you dec= ide on whether to support or not this WG adoption. Please express clearly = your reasoning for support/non-support as well as any open discussion poin= ts you would like addressed should the document=0A be adopted into the wor= king group.

    =0A

     

    = =0A

    Thanks!

    =0A

    =  

    =0A

    Jim, Bruno & Joel<= /o:p>

    =0A

     

    =0A

     

    =0A
    =0A
    =0A ------=_001_NextPart008427036260_=------ . From nobody Mon Oct 11 13:55:56 2021 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 B8B1E3A0C39; Mon, 11 Oct 2021 13:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=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=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TlV0hDftdT7C; Mon, 11 Oct 2021 13:55:10 -0700 (PDT) Received: from NAM10-BN7-obe.outbound.protection.outlook.com (mail-bn7nam10on2129.outbound.protection.outlook.com [40.107.92.129]) (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 051703A0BCB; Mon, 11 Oct 2021 13:55:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lugA9QJEblNE0dc6vD2UPccSy9NhHFhB/xks8t8FKx6IKbvzEsZVTwvxjM0+LHRG2yjPeVBjf+av9Dj+xJB+LmgqzmH5C8oFi4RmZFofZpmsONfmiJCHIzMunUYvotFeUdghtGJiX6YiNWoFJLlPVTNm2M/asNkFijhAR0kHQgoo08Rfp9GUTA0JO26C/AA41cL722HuHia/YdAS/XJyJzVvM1rS0O0DeLuSxH29WVEDm2QMmUTJN+h9nKK5ClT9LlTjIUZ01jJ0yj69IIr8XJpMqyj5G8NeAyp9QLb1pvn1DA3IrvBrxoSjKjQO5rTmh/p6xAa5VfEVSrooco8DHw== 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=iKG1W0xO+y9ezFA4vp6CCnz+3hj/Z9EtBKkifjm4NZc=; b=ZZwKD7Oyf0UrdFNIb8mdOYyxa3zOScORIUiDF3Gy2l0VYTEAiDCxTmJseQ81fWg+UgP+HfUawEys1nVDGYomOxqgXww9kv/fkZdZUTsBhXJEmTVjexlE1LIHLCxcKGK26YaGkm6rUx0DefQM4MYY7A1plBSpMJ/Mf515eneUmpqmYMBhcWWFDCffZWtVvF0SXPrWOJZ113IkYvFfBgZKE29HyZ1iMZF52ePBVk14Pw2hVwSssV2GXMwNeu06nYMAVZV6rTEYX4VrswENQ4v5+3jkwWxU07R40GGKyQIu/uTrYq0JqOJoyiDMFRAXzrFmub1tr99EIYXIUDr63vvP0A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iKG1W0xO+y9ezFA4vp6CCnz+3hj/Z9EtBKkifjm4NZc=; b=khepq9tdH5U8e4xfezom+Pum7KfzPrbNQjto7N2kA/ZrlC5h+b1o/Fsl3hyCTY0DUjT3R11Ns962Dms1RAgih7hdOIV2nCoEF3Ov1L0YT9UGGBZkjZNQVRQdiGIbgQpxQY78AaYXDUD9u5q/zBJYH9t4uy65na2BXSLQdcvtoBM= Received: from CO1PR13MB4920.namprd13.prod.outlook.com (2603:10b6:303:f7::17) by MW3PR13MB3962.namprd13.prod.outlook.com (2603:10b6:303:54::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.12; Mon, 11 Oct 2021 20:55:01 +0000 Received: from CO1PR13MB4920.namprd13.prod.outlook.com ([fe80::7cf9:4e05:b9cb:1a69]) by CO1PR13MB4920.namprd13.prod.outlook.com ([fe80::7cf9:4e05:b9cb:1a69%6]) with mapi id 15.20.4608.014; Mon, 11 Oct 2021 20:55:01 +0000 From: Linda Dunbar To: Keyur Patel , "Zafar Ali (zali)" , James Guichard , SPRING WG CC: "spring-chairs@ietf.org" , "Zafar Ali (zali)" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: AQHXuTd9ijIiTOMLDkGipCqWUcImCKvM3z2AgAFylZA= Date: Mon, 11 Oct 2021 20:55:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: arrcus.com; dkim=none (message not signed) header.d=none;arrcus.com; dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 75200287-19aa-4d8b-784c-08d98cf964a2 x-ms-traffictypediagnostic: MW3PR13MB3962: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sbWiCWlgUCzZSMN4ZOWjuZsZwM/4JSaSq3JgiBc5kwHeyR43L4+6XSLY1++QwPdFs6pqVYONju7Xc45YpzhpRgiAe2hzmFzPM8mdmC4g1n8T+goCF4s3HoWrcwVlHGEH05qYZ7t8zvJlxVDF5Q0TH6NgeLKvRt6L3Nk1Uf3DkYZcVxaCbsX6H7W2sEFkWsQjnyNu8vxEsoM97I4rc8NUhTx1Sw0wgkVGcPNS67azEc6lI90CpfA1KJ58L0RlurItkjXVITFJVN6iUQ9Tx0z664VD6JxxvfnZgHyDhozF5ULqgp6twEzTYGmVGHp9oQkalHvkxrN3TEJTCTKgkijCoOPPX4iQ9GUbqHT79OaJtnRmHJJR5b46VYzl9KaSJ72bhXVNAx1A+Jlx1TA5Jbn/nv9UY3Ugql8QsjAeWYRkvklqbVlEoTNJjEHW7aGceFtmaFwdZgOcn3lt2lqOyljzujlCiRhRk8dlq/7BYIdwiWsSURNBZGgxyypjUTrdNkLvXlHYV4ZTytLjMkABS3acHy064Y8spMiWXIJFwMIiv+/58CKrs+a4BupPo/dWxMYL2HY3js6FCFJ1bP1EpM3VBh1SaOQfBnRFNmSocSKO/0l5QJQcP3+MauAZLtuGElEYWKOO2dck6Eg9d1J6QGaXqzbt4wXM5dg7BnJJqg5yTwNGQ+5wDZs/n5qnDT0PwPsd90M79rB8FH2D3VMmdP5nGA0S7lL4EXXjr+Cs+uCZn/Sl9YQJZINBT8LMkeyYBTLDV5uMEU3l+7yRQcZMgSQLpfdfEG2gqfvlRWwP/QNyNd8= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR13MB4920.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(71200400001)(7696005)(110136005)(26005)(55016002)(9686003)(54906003)(966005)(6506007)(316002)(53546011)(76116006)(186003)(8936002)(8676002)(508600001)(44832011)(33656002)(86362001)(66476007)(38100700002)(166002)(2906002)(52536014)(5660300002)(83380400001)(66946007)(122000001)(66556008)(4326008)(64756008)(66446008)(38070700005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?blXPbe/78ol9SxDiC1k8MiTrnJzlQoebuQKBC954R5821qeSU48cWPT4NtkX?= =?us-ascii?Q?ikCT14yloOxsqI8Q4rNzd5W+xsIJ1z3YaE++8f4hyrtdyoQVHDTQ6PET1wXH?= =?us-ascii?Q?8sKbP8sctx8errSa1SQdQyhnYf2oMCeJMpqCOmKC7KNXCT2NBaXZm1x8bvqI?= =?us-ascii?Q?4BlfGJGAoxU1B8dqhDqTv1zuFZmKAmivD+r3OjwC3D8YXFwHs1ATxkeD7sLS?= =?us-ascii?Q?UzKfAIElsUhTrzzB8h+75qT6o/bk0GhtncsWsDbgBmJRd0ivWsbBLQ80xECz?= =?us-ascii?Q?S8jH54OhmJPUVeEY/Sm8Lc8nrKocecd8DEYQhLTmN9H6FDvTb3pYnDSwSfan?= =?us-ascii?Q?ffyJOsOzm/1baD7slN7tH0kjlF51Lj24AhPvR+wVwp00ID+aCgB07OWNDxql?= =?us-ascii?Q?guHbc05l8S2AtYFMKIF27tG5uCfjtfYCqhI6/Uv1gNkACjb7TcgWMyqPNcbV?= =?us-ascii?Q?n/9lEmyJm3pJHTQv53N8xGh+unWaVDNerKFQOs7TN6gzslTRtJ0kiue6KTP5?= =?us-ascii?Q?207zx5BSgHPYxegSEy7si2RItdK5AliPt0e6vJbwaXd+p30AWhLlF2Zx95sL?= =?us-ascii?Q?XeaUz9+5J9ff8sgyBPiaXZac5pxa/tD+YAo5ySL0CVjf9AttIGm6A2RUi1r9?= =?us-ascii?Q?XxzG95kLZHcqNpPs3L9JDachXN2qJbDdxTFbXM65hwXCe4Q1tRp8gdTJx2DG?= =?us-ascii?Q?aZP86+ASyFB5WddBWOjoexppuG/mdJUbBA2HXjCDXCxS7tDseuMAjIgu7Mh+?= =?us-ascii?Q?yqPGwdLU0vlkwSIPybVvy0jTtS48V97+xPHT1R4JsKPUn9E/n6eDzS4KRuB1?= =?us-ascii?Q?UDVkihZShuodfR07t5wDs883Hunacjy7GywTBWfD3DeEPkOfnx03bZgrhxzu?= =?us-ascii?Q?4rUEVO5csRfLjC3BDkVJDKSwcRudh/6HpQjFx27BoX0ScU5BabU2GyHgkWnj?= =?us-ascii?Q?KG0tsSidpAeIa2IOUui1Al3qhWPLeSw9gMzgqJHMk7fVMI4XcC0UBZX6TyqD?= =?us-ascii?Q?6Vp3yk7slhlIYH8rLnGBqfv/Qe7fjkm/0OgO9SepAn4xeT15p+V3RDEb59Jv?= =?us-ascii?Q?uDBW35onGjNllqOqZQFHhS9fVYvLQQg89VTIawzb8OV7labYzhrrQfgHmofe?= =?us-ascii?Q?ubg8IBZyWvOVVcqw1rFx4VJ7Xp/xId9Ky7frE3nD1YrlcmWDAq4Dhk+JMDRw?= =?us-ascii?Q?kp6St2crM+nVZf46xiTI1PROKW1Jg9GtB1KYkjsuTp8aUWMOLZN7z+bDRi54?= =?us-ascii?Q?hXR5ERYmZtPgNRiw8sWLN3RW+KhowttxCaADjRMVDIRTF55XYF+E+Z/Y7c2W?= =?us-ascii?Q?yq5u7ssMn4yI00j20nLKas6I?= Content-Type: multipart/alternative; boundary="_000_CO1PR13MB4920383271BF3F1477A9001D85B59CO1PR13MB4920namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR13MB4920.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 75200287-19aa-4d8b-784c-08d98cf964a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2021 20:55:01.0958 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4qYxdQs2Tt1v5YzTkN7qjEAHH+BMWYOq7JLbBfWGqwL0kSINjbirAp7wKIqYcNZWjKpmJkPvR9XGEFbaBctxdA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR13MB3962 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 11 Oct 2021 20:55:24 -0000 --_000_CO1PR13MB4920383271BF3F1477A9001D85B59CO1PR13MB4920namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable With multiple vendors having implemented the solution, I strongly support t= he adoption of draft-filsfilscheng-spring-srv6-srh-compression. Linda Dunbar From: spring On Behalf Of Keyur Patel Sent: Monday, October 11, 2021 12:48 AM To: Zafar Ali (zali) ; James Guichard ; SPRING WG Cc: spring-chairs@ietf.org; Zafar Ali (zali) Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ Dear WG and the WG Chairs, Network programming model (RFC8986) defines multiple flavors for End, End.X= , and End.T SIDs. CSID draft builds on it with next and replace flavors for= these SIDs, optimized for 16 bit and 32 bit SID sizes, respectively. This = is just like PSP, USP and USD flavors defined in RFC8986 to cover different= deployment scenarios. We at Arrcus have implemented CSID solution and also have participated in m= ultivendor interop for the solution. I strongly support the adoption. Best Regards, Keyur From: spring > on b= ehalf of "Zafar Ali (zali)" > Date: Monday, October 4, 2021 at 8:50 AM To: James Guichard >, SPRING WG > Cc: "Zafar Ali (zali)" >, "spring-cha= irs@ietf.org" > Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ Dear WG and the chairs, I strongly support the adoption call About the matter in the email, the WG has defined a single data plane solut= ion, i.e., SRv6 (RFC8402, RFC8754, and RFC8986). SRv6 as per the inherent nature of the network programming model (RFC8996) = already defines multiple standardized behaviors. Clearly, CSID is a single solution based on the SRv6 data plane. Thanks Regards ... Zafar From: spring > on b= ehalf of James Guichard > Date: Friday, October 1, 2021 at 10:05 AM To: SPRING WG > Cc: "spring-chairs@ietf.org" > Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as= the basis for its compression standardization work. That is part of what t= his email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guideli= nes as follows. By expressing support for adoption of this document you are= fully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple = SRv6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes thro= ugh review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be addr= essed BEFORE said document is allowed to progress from the working group to= publication. A list of these discussion points will be documented in the W= G document and maintained by the document editor in conjunction with the ch= airs. 4. If this document is adopted by the working group, the chairs speci= fy as part of the adoption call that the following text describing an open = issue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardi= ze one data plane solution, and given that the document contains multiple S= Rv6 EndPoint behaviors that some WG members have stated are multiple data p= lane solutions, the working group will address whether this is valid and co= herent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_CO1PR13MB4920383271BF3F1477A9001D85B59CO1PR13MB4920namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    With multiple vendors having implemented the solutio= n, I strongly support the adoption of draft-filsfilscheng-spring-srv6-srh-c= ompression.

     

    Linda Dunbar

     

    From: spring <spring-bounces@ietf.org> = On Behalf Of Keyur Patel
    Sent: Monday, October 11, 2021 12:48 AM
    To: Zafar Ali (zali) <zali=3D40cisco.com@dmarc.ietf.org>; Jame= s Guichard <james.n.guichard@futurewei.com>; SPRING WG <spring@iet= f.org>
    Cc: spring-chairs@ietf.org; Zafar Ali (zali) <zali@cisco.com><= br> Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.= org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

     

    Dear WG and the WG Chairs,

     

    Network programming mode= l (RFC8986) defines multiple flavors for End, End.X, and End.T SIDs. CSID d= raft builds on it with next and replace flavors for these SIDs, optimized f= or 16 bit and 32 bit SID sizes, respectively. This is just like PSP, USP and USD flavors defined in RFC8986 to cover dif= ferent deployment scenarios.

     =

    We at Arrcus have implem= ented CSID solution and also have participated in multivendor interop for t= he solution.

     

    I strongly support the a= doption.

     =

    Best Regards,=

    Keyur

     

     

    From= : spring <spring-bounces@ietf.org> on beh= alf of "Zafar Ali (zali)" <zali=3D40cisco.com@dmarc.ietf.org>
    Date: Monday, October 4, 2021 at 8:50 AM
    To: James Guichard <james.n.guichard@futurewei.com>, SPRING WG <spring@ietf.org>
    Cc: "Zafar Ali (zali)" <zali@cisco.com>, "= spring-chairs@ietf.org" <spring-chairs@ietf.org>
    Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/

     

    Dear WG and the chairs,

     

    I strongly support the adoption call

     

    About the matter in the email, the WG has defined a = single data plane solution, i.e., SRv6 (RFC8402, RFC8754, and RFC8986).

    SRv6 as per the inherent nature of the network progr= amming model (RFC8996) already defines multiple standardized behaviors.

    Clearly, CSID is a single solution based on the SRv6= data plane.

     

    Thanks

     

    Regards … Zafar 

     

     

    From: spring <spring-bounces@ietf.org> on beha= lf of James Guichard <= james.n.guichard@futurewei.com>
    Date: Friday, October 1, 2021 at 10:05 AM
    To: SPRING WG <spring@ietf.org= >
    Cc: "spring-chairs@ie= tf.org" <spring-chair= s@ietf.org>
    Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/

     

    Dear WG:

     

    The chairs would like to = express their appreciation for all the responses received to our emails wit= h reference to how the working group wishes to move forward with respect to= a solution for SRv6 compression.

     

    The apparent inclination = of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

     

    Because of the above the = chairs would like to issue a 2-week WG call for adoption ending October 15<= sup>th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

     

    1.       The SPRING working group is adopting a document tha= t has multiple SRv6 Endpoint behaviors.

    2.       The document is a “living” document; it= may change as it goes through review and analysis by the SPRING working gr= oup.

    3.       All open discussion points raised on our mailing li= st MUST be addressed BEFORE said document is allowed to progress from the w= orking group to publication. A list of these discussion points will be docu= mented in the WG document and maintained by the document editor in conjunction with the chairs.

    4.       If this document is adopted by the working group, t= he chairs specify as part of the adoption call that the following text desc= ribing an open issue be added to the document in the above-described open i= ssues section:

    ·         "Given that the working group has said = that it wants to standardize one data plane solution, and given that the do= cument contains multiple SRv6 EndPoint behaviors that some WG members have = stated are multiple data plane solutions, the working group will address whether this is valid and coherent with its= one data plane solution objective.".

     

    Please consider the above= guidelines as you decide on whether to support or not this WG adoption. Pl= ease express clearly your reasoning for support/non-support as well as any = open discussion points you would like addressed should the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    --_000_CO1PR13MB4920383271BF3F1477A9001D85B59CO1PR13MB4920namp_-- From nobody Mon Oct 11 16:14:30 2021 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 91A393A10B8; Mon, 11 Oct 2021 16:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=kkx6vDzd; dkim=pass (1024-bit key) header.d=juniper.net header.b=Z9LjvfDY 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 2aRhGPNOg_xx; Mon, 11 Oct 2021 16:14:18 -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 F3FD03A10C0; Mon, 11 Oct 2021 16:14:17 -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 SMTP id 19BGX9p1029108; Mon, 11 Oct 2021 16:14:16 -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-transfer-encoding : mime-version; s=PPS1017; bh=hq7MTVM608HJ2KsILzjboe8WNvWzUstcrhle6AQiwI4=; b=kkx6vDzd4Nz+tK45GNnI0t0O/h7v0mfJhApYTDuib2uoW911522VsTlBhVsgFnvAzRfL GABIrMuV46Mq7cHZrWCpBXRc4Ze19cxrlBOABgwk87BBxHgq8nuzGvzrmzSx6OTY5rFl VJtnVz69g0GQsrE0S9A7ri+KLa7mviO7fywj9/WiPBWzEgDnAC1O4A1ffadMTj/RjIw3 EjZ5WG2+FU8P1RW8YaNbZO4rES05yzvwQQankenaURvxR+voDouO/oeOKAuT2dOTbseF Rq/A9O/DpdadHHhNvbyG4VgEAeYQssccNq8pv0Rs6SecKaBh6zX5Rt/9rbpk4Ev5g1QZ Tg== Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2170.outbound.protection.outlook.com [104.47.57.170]) by mx0b-00273201.pphosted.com with ESMTP id 3bmrvy8rge-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Oct 2021 16:14:15 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CgpaT4boWXEcicfnpKWiAKf663U/5hvILn2ASLqBx2mhJUqvi8nj01PRz6XX755hnZ4KhZU2mOa/xJFXCVMBfGOo24FeRW0P97RIvmj2v6fajdHgOg2c99iw1vrJK9MAxqflKoazU7Q9IPWvvuciFASXMEj+ztt0TXPRKz8X2P2yx2715Citq2Y0ivRA3uV/oRMxzzalvZWm48o03von+FtBRTZdI4d0iZaMat+p/D+ZoW1leBifMD5b/ePW7yL2hfeboY1C3O4pEJh0ICMqY2/r1akffeGNyhfPND5gNg9xNsmyKYqzrGyoUbxqNkNDQMx5EA4Qj9L+0OE17pmYSw== 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=hq7MTVM608HJ2KsILzjboe8WNvWzUstcrhle6AQiwI4=; b=fk01Jl1ntaU5iZRuAaJk6QWhnqnBK6YMmg5eWkSVR5dgqQtMs9ZNd+bMP9EjM5IUS6NXu9Hs0N9iJdA4i6BzaZEQxYHtc4Kf491AS7+pac+aQsHFiqzAK0jx2XZiHuZLgXQ/qeaGMnJCjzuqHPpwqWkoFQLIAOVcZ/88ZJmaZYCdOAHyBZiwRF7jdleS7xdhaUt5WY++Z30E3Me29tRxZrBuZZwBkIuR2KYt1SliZXa8eVyjtMqeoLo1BzAfi4BujTDOzOLQSX5XI13JStSBverbwtNKUzW8vnBXiP4Dvq5UuE3PQL267zsB5s/vKrkbc5JIfJXWJGG7s/5PFXr9OA== 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=hq7MTVM608HJ2KsILzjboe8WNvWzUstcrhle6AQiwI4=; b=Z9LjvfDY48jvIrMEIHIPnMh/PRDvv/wneNZb8Ayu6j5xBkccFUni1xyGDLPMCEtAB7riaLIfcrciD29Tmz1j1Twg2YqW3ZWaopM/cWkdn6SheE9XqU691jPOrGhTkIEVOUXZdecBbpVXaO5+IQ3/230su5K0w0KrV4E79HkrXJs= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by BL0PR05MB5155.namprd05.prod.outlook.com (2603:10b6:208:84::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.25; Mon, 11 Oct 2021 23:14:12 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4608.014; Mon, 11 Oct 2021 23:14:12 +0000 From: Ron Bonica To: Brian E Carpenter , Robert Raszuk , 6MAN <6man@ietf.org> CC: SPRING WG Thread-Topic: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 Thread-Index: Ade3AXyWK2NzAamgSlCvJ497z/5RLwC/aCkQAFbElIAAFRrfwAAcSamAAAzi0oAABMpdgAAVTRUAABGuFAAAEYXYAABo9ucg Date: Mon, 11 Oct 2021 23:14:12 +0000 Message-ID: References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> <423b08d46294454d9a9625990ce52acb@huawei.com> <322a8c29-e232-a39d-94ca-9c9cbf09c8d2@gmail.com> <9945ca9c-2ba7-bd00-6e3e-261c376a9718@gmail.com> In-Reply-To: <9945ca9c-2ba7-bd00-6e3e-261c376a9718@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-11T22:07:09Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=7a550747-7ca0-4ae5-9600-124ffd7d90e4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_enabled: true msip_label_0633b888-ae0d-4341-a75f-06e04137d755_setdate: 2021-10-11T23:14:11Z msip_label_0633b888-ae0d-4341-a75f-06e04137d755_method: Standard msip_label_0633b888-ae0d-4341-a75f-06e04137d755_name: 0633b888-ae0d-4341-a75f-06e04137d755 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_siteid: bea78b3c-4cdb-4130-854a-1d193232e5f4 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_actionid: 6403b4a4-b03f-4844-81cb-9582e70510ba msip_label_0633b888-ae0d-4341-a75f-06e04137d755_contentbits: 0 authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 59c31020-c0be-4aa4-e323-08d98d0cd678 x-ms-traffictypediagnostic: BL0PR05MB5155: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: X1swRa2qAoqqbESNgOg4YwW8ovIvuApZC6KBHWoOgddU8VfEjsU1Rm+v7ZcxP7IBwe9LjSJ7Mo+fqtc38KgZnDxbGnsociAzw8WtVitrBeirV/s/IZhFd/eLqrOnusY4bhMxIKBmuU+bOooozhhtX3DF9sqMgBGoTwkzz4+Z4Dk7hIOUZGtjhP7DrvUVQJR+ZEHZ/UhB8iH/hP+m263B92/WWI8R2Fv2DgQyhya/hF6Pd7JIn/wRdzVyh1RpH+0RQCtN0oZ4d64J2XeJ5QI8VfG/M/yhi4ymfFnNMssP52loqA4P4wF0b5kmnXpiz/eO64OFsj3Pxx9EMEQqCYXGLkfw26QKcsCLqS8t5OGNSvTxcn11oAxbet4acERibDWoyRGBDCTtmd9mD/UsxYrFpJReGkMQAuO5FhtoG8gFOmd1tG5zuGBJKSwwlzyBdAlOCiE6vnCJuSFvzzyhxz8FLVbQKROpFS4BDYipKCbKAsVDr6P27/AnII78g/Qy7V0g9vVLcQNoRceA+8YPjCGtgiJTDds2Ns988OTdShkl0FDJrZDBm0aMUKzgtZu00mPyKjSNFhLcUDIbc5WUgybtBJV4JGq+e3HyG8H1P8VEqdS7eb+I52DyG28y9O0RFSpkQiCVtyboTFTiTRVsSndHdlYl4wMW0b2IGJN7+snGPgsOEriXqoruahfvFcFpIOiWwWjnDoy9/4kIkTHXO6UHgHOClk3sdNyaf+Jg1hc6e8YsUBcI07ApNLU/jDMc8uH3Dct72UaRQ72SROn0h7rNRqyia0Lut187tbJwig7AShc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(8676002)(53546011)(6506007)(4326008)(2906002)(122000001)(26005)(38070700005)(7696005)(8936002)(71200400001)(66446008)(38100700002)(186003)(33656002)(508600001)(110136005)(83380400001)(55016002)(966005)(66946007)(66556008)(52536014)(76116006)(316002)(9686003)(86362001)(64756008)(66476007)(5660300002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Z2dWam1KdmhabjFIVGNBTElTNitxQy8zVmM3Wm94ZkxUcXJxNmNuallWcDdz?= =?utf-8?B?amhsbjMvRVJmLzloOEFNODJzb3hZSVk2RGR6Q3lvZ2xsTHN5R29KQ3FTRU5M?= =?utf-8?B?RFo3MEZqa3FPWDcyak5xMkNpOTR0aGdEenRXbGQ3NUdtREJ3bWtmQkV2cTlw?= =?utf-8?B?R0ZJWWJpaGxrc1dLOWlMOHA3dm13WTg0S3N2bGwyWVIvdVJLaEVpQUgwOE4r?= =?utf-8?B?aUROa0lCRVlzbDR0Wlpaenhxc2tzaUpTaE5NVXFEbDlFUUkybU5hOHBXK3JD?= =?utf-8?B?cVlhc1MxRXBVTWN4eHVPWG5wYmdSSmNMd2YwM29sQVdWVk05SDQ0K1dGb3lY?= =?utf-8?B?NVlvbmZHYkxXdEZSWDA0bXVqaHNOSzdlTzFXOWlMcXNGRzgrUDhDVnN0K3l4?= =?utf-8?B?emtlQnJFUnJvckFuVEdOMXNnS0Z0R05xakdpajdBR051NTJod0c2UEVsMlg5?= =?utf-8?B?NWZybEh6MHBwdG9HNjFlWlRmQ1VvL21lcHkxMnJxblUvVU1kU0I2cmxEUy9r?= =?utf-8?B?SDd4U1hiVjR4L0JVcFlUUi82K2x3UzI3UnptSTdST0J6V1dzVzNUNG15T1BV?= =?utf-8?B?MDhhVU9ENVdReFpMRHprMlpaZk1tbVQwN2tjRlBxWmxsazVXUXorRlRrZWZq?= =?utf-8?B?YnVuL1hqMVFnc3JLZGRCNUczSFBDVi9jQU5nMG1mV1p4RXFDYWRqQzUrYUtB?= =?utf-8?B?SjlDSTk3emRsZjBOT2FnVTRxbzFHN1FOQXc3TnlHalY4bXlMRm8rb3I1WXM0?= =?utf-8?B?OVNTdUN3UFQrcUtlMlQ0K0JOUkxVeXlWR2RFVytBa1pUZzNUNHFqYVdZSXZ2?= =?utf-8?B?V3NOSDY1OENkdVIrTEZoTDExRk1UNCtyNXBGcnV6MjRZbzRFeCtBOEVwd0NO?= =?utf-8?B?b1FtZ2xmS21nVUE3Y2ZqNlZCZTdwMWJ4aFJtVXdSUGh6V3p6VDlLU2lZWTVa?= =?utf-8?B?Vzg1MnZGdnVpWWkxdDlZVzZQbjhFSDJ6amx4czBUL0x6enBSb055T3VLbTgx?= =?utf-8?B?V016d2VKVFRqSFZ4bUNoQTBReTZMeTNxQnZjalZqMjZlMGYzZEFSQWg5TFM3?= =?utf-8?B?dzZQVFF5THRhNnZiZU00RzZpK1Vnekd5eWk0akZaT3BlNHZFa3dYdXpDVkNV?= =?utf-8?B?SE5DUmRFSE54MnNjbUROTzAzM0JTR202eW1uTG9rdUozVkthcG1YUGk3V3Av?= =?utf-8?B?WGRQRHhtNzA3L0MvN0h4VHJhUFJPNDgrRW0yOWd6dHBaeUQ1YTNia21GVm9S?= =?utf-8?B?SHZhYUE1WXI2V1lNeTRNVFhWTWtUN2JGZnNYaVN0Nk5WVWdNSWZWTFNpSDRU?= =?utf-8?B?cUUvSGZmWSt0c3JMMFVHd2VWdXUvWjJuekY5NWl3TFJ0SHZhSUc0aFdCbkUy?= =?utf-8?B?bjIyY3hTOEtGYTZBRjZOUEJCQytkMHZKUjN4bVhrQ2JHTE5HRm04K0FrRVdr?= =?utf-8?B?QjNoamxFdkxuL0F3MHYrbXA2QlZlZmZYR2JNUkRqckUrNjJGV04wb0VlUmJs?= =?utf-8?B?Rzd5cmtSOG1DR2sveTUveW0yVFVaQVd4WGdvSG04cklLTmFqZ3g4TDg1cTFa?= =?utf-8?B?OFp0MjBROWpCTCthbGVHU0dKS3VuejVlOHRaRUVYM3owaTN6SzFmOHB5eExk?= =?utf-8?B?SHVpN296dlNHSmZGU1JYdDRRMkIrUkZvSTBQbHluUE1kSTVITFM4WkxWVXhJ?= =?utf-8?B?d1FQckttMlFyTTdlVHBibkIwWW80Y2ZMblN5UVhaa3dNWFYzTEhRS1dpWFZp?= =?utf-8?Q?rpvSWmiLWIQrvnbFsHtSyVP2zf8+0DhmJFvbtGD?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 59c31020-c0be-4aa4-e323-08d98d0cd678 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2021 23:14:12.5207 (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: GBb3Y9Q+BIwS/dTZIesK/kVlDDu4zNADGGAzOdIbmLLHEYZS1IFSOT8lbqMKNE4brvPtrW8TpRo1uT0PN1Pvxw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5155 X-Proofpoint-ORIG-GUID: EJaP0DST3Tq05NLEapBNYPj_OaxNZQ9I X-Proofpoint-GUID: EJaP0DST3Tq05NLEapBNYPj_OaxNZQ9I X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-11_11,2021-10-11_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1015 spamscore=0 adultscore=0 lowpriorityscore=0 malwarescore=0 bulkscore=0 phishscore=0 priorityscore=1501 mlxlogscore=999 impostorscore=0 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110110132 Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 11 Oct 2021 23:14:23 -0000 Rm9sa3MsDQoNCkl0IGlzIG11Y2ggbW9yZSBzaW1wbGUgdGhhbiB0aGlzLg0KDQpBY2NvcmRpbmcg dG8gUkZDIDgyMDAsIGFuIElQdjYgRGVzdGluYXRpb24gQWRkcmVzcyBpcyB0aGUg4oCcMTI4LWJp dCBhZGRyZXNzIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb2YgdGhlIHBhY2tldCAocG9zc2li bHkgbm90IHRoZSB1bHRpbWF0ZSByZWNpcGllbnQsIGlmIGEgUm91dGluZyBoZWFkZXIgaXMgcHJl c2VudCkuIFNlZSBbUkZDNDI5MV0gYW5kIFNlY3Rpb24gNC40LuKAnQ0KDQpUaGVyZWZvcmUsIGlm IGEgcGFja2V0IGRvZXMgbm90IGNvbnRhaW4gYSBSb3V0aW5nIGhlYWRlciwgaXRzIElQdjYgRGVz dGluYXRpb24gQWRkcmVzcyBpcyB0aGUgMTI4LWJpdCBhZGRyZXNzIG9mIGl0cyAqdWx0aW1hdGUg cmVjaXBpZW50Ki4NCg0KVGhlcmVmb3JlLCBhIG5vZGUgTVVTVCBoYXZlIGJpbGxpb25zIG9mIElQ djYgYWRkcmVzc2VzIGluIG9yZGVyIHRvIGNvbnN1bWUgYSBwYWNrZXQ6DQoNCi0gdGhhdCBkb2Vz IG5vdCBoYXZlIGEgUm91dGluZyBoZWFkZXINCi0gd2hvc2UgSVB2NiBkZXN0aW5hdGlvbiBhZGRy ZXNzIGlzIGEgMTI4LWJpdCBjYXJyaWVyIEMtU0lEDQoNClRoaXMgaXMgYmVjYXVzZSBiaWxsaW9u cyBvZiBjYXJyaWVyIENTSURzIGNhbiBiZSB1c2VkIHRvIHJvdXRlIHRoZSBwYWNrZXQgdG8gdGhh dCBub2RlLg0KDQpUaGUgdmFzdCBtYWpvcml0eSBvZiB0aG9zZSBhZGRyZXNzZXMgYXJlIG5vdCBj b25maWd1cmVkIG9uIHRoZSBub2RlLg0KDQpJIGFtIHByZXR0eSBzdXJlIHRoYXQgdGhpcyBpcyBu b3Qgd2hhdCBSRkMgODIwMCBoYWQgaW4gbWluZC4NCg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgUm9uDQoNCg0KDQoNCg0KQmlsbGlvbnMgb2YgdW5pcXVl IDEyOC1iaXQgQ1NJRCBjb250YWluZXJzIGNhbiBzdGVlciBhIHBhY2tldCB0byBhIHBhcnRpY3Vs YXIgbm9kZS4gVGhlcmVmb3JlLCB0aGF0IG5vZGUgbXVzdCBoYXZlIGJpbGxpb25zIG9mIGFkZHJl c3NlcywgdGhlIHZhc3QgbWFqb3JpdHkgb2Ygd2hpY2ggYXJlIG5vdCBjb25maWd1cmVkIG9uIHRo ZSBub2RlISENCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgDQoNCg0KSnVuaXBlciBCdXNpbmVzcyBVc2UgT25seQ0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogaXB2NiA8aXB2Ni1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYg T2YgQnJpYW4gRSBDYXJwZW50ZXINClNlbnQ6IFNhdHVyZGF5LCBPY3RvYmVyIDksIDIwMjEgNDow MiBQTQ0KVG86IFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PjsgNk1BTiA8Nm1hbkBp ZXRmLm9yZz4NCkNjOiBTUFJJTkcgV0cgPHNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBb c3ByaW5nXSBkcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi0w Mg0KDQpbRXh0ZXJuYWwgRW1haWwuIEJlIGNhdXRpb3VzIG9mIGNvbnRlbnRdDQoNCg0KT24gMTAt T2N0LTIxIDAwOjM5LCBSb2JlcnQgUmFzenVrIHdyb3RlOg0KPiBIaSBCcmlhbiwNCj4NCj4+IFdo aWNoIG1lYW5zOiA2NCBiaXRzLg0KPg0KPiBTb3JyeSBidXQgd2hhdCBpcyBzbyBtYWdpYyBhYm91 dCAvNjQgaGVyZSA/DQoNCkl0IGlzIG1hbmRhdGVkIGJ5IHRoZSBjdXJyZW50IElQdjYgYWRkcmVz c2luZyBhcmNoaXRlY3R1cmUuIERlc3BpdGUgbWFueSBkaXNjdXNzaW9ucywgdGhlcmUgaGFzIG5l dmVyIGJlZW4gY29uc2Vuc3VzIHRvIGNoYW5nZSBpdC4gU28gaWYgLzY0IGlzIG5vdCB0aGUgYm91 bmRhcnkgYmV0d2VlbiB0aGUgcm91dGVhYmxlIHBhcnQgYW5kIHRoZSBob3N0LXNwZWNpZmljIHBh cnQsIGl0J3Mgbm90IElQdjYuDQoNCiAgIEJyaWFuDQoNCj4NCj4gSXMgdGhpcyBjb21pbmcgZnJv bSB0aGUgbG9uZ2VzdCByb3V0YWJsZSBJUHY2IHByZWZpeCA/IFNvcnQgb2YgYW5hbG9neSB0byAv MjQgaW4gdGhlIElQdjQgd29ybGQgPyBPciBzb21ldGhpbmcgZWxzZSA/DQo+DQo+IEkgdGhpbmsg TFBNIGFuZCBDSURSIHRlY2huaXF1ZXMgYXJlIHByZXR0eSB3ZWxsIGVzdGFibGlzaGVkLg0KPg0K PiBBbnkgZml4ZWQgbGVuZ3RoIG9mIHRoZSBhZGRyZXNzIGJsb2NrIHdpdGggdGhlIG1lYW5pbmcg LSBkbyBub3QgdXNlIHRob3NlIGJpdHMgaW50ZXIgb3IgaW50cmEgZG9tYWluIGZvciBhbnl0aGlu ZyB1c2VmdWwgZXZlbiBpZiB5b3VyIHByZWZpeCtub2RlIGNhbiBoYXBwaWx5IGZpdCBpbiAvMzIg c2VlbXMganVzdCBkZWFkIHdyb25nIHRvIG1lLiBBbmQgdGhhdCBpcyBpcnJlc3BlY3RpdmUgb2Yg YW55IFNSdjYgZGlzY3Vzc2lvbi4NCj4NCj4gSW4gbXkgYm9va3MgaWYgSSBnZXQgYWxsb2NhdGVk IHNheSAvNDggb3IgLzQwIGZyb20gUklSIHdoYXQgSSBkbyB3aXRoIHRoZSByZW1haW5pbmcgYml0 cyBpcyBteSBvd24gYnVzaW5lc3MuDQo+DQo+IEJlc3QsDQo+IFIuDQo+DQo+DQo+DQo+ICAgICA+ IFNvcnJ5LCBidXQgaXQgaXMgYSBsaXR0bGUgYml0IGxhdGUg4oCTIFJGQyA4OTg2IGlzIGFscmVh ZHkgcHVibGlzaGVkLg0KPg0KPiAgICAgIkxvY2F0b3JzIGFyZSBhc3NpZ25lZCBjb25zaXN0ZW50 IHdpdGggSVB2NiBpbmZyYXN0cnVjdHVyZSBhbGxvY2F0aW9uLiINCj4NCj4gICAgIFdoaWNoIG1l YW5zOiA2NCBiaXRzLg0KPg0KPiAgICAgSSBoYXZlIG5vIHRpbWUgdG8gc3R1ZHkgY29tcHJlc3Nl ZCBTSURzLCBidXQgaWYgdGhleSB0cmFtcGxlIG9uIHRoZQ0KTE9DIHRoZXkgYXJlIG5vdCBJUHY2 IGFkZHJlc3Nlcy4NCj4NCj4gICAgICAgIEJyaWFuDQo+DQo+DQo+ICAgICAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PiAgICAgSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+ICAgICBpcHY2QGll dGYub3JnIDxtYWlsdG86aXB2NkBpZXRmLm9yZz4NCj4gICAgIEFkbWluaXN0cmF0aXZlIFJlcXVl c3RzOiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pcHY2X187ISFORXQ2eU1hTy1nayFVQlJQUThlOGpOaFIwSHVtampuWWFQ Nmg1QUFEeklqRUpCZmNOdXJlcjByNEFFUm5sdkZORjVSMXRwX1h5czBhJA0KPGh0dHBzOi8vdXJs ZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lw djZfXzshIU5FdDZ5TWFPLWdrIVVCUlBROGU4ak5oUjBIdW1qam5ZYVA2aDVBQUR6SWpFSkJmY051 cmVyMHI0QUVSbmx2Rk5GNVIxdHBfWHlzMGEkID4NCj4gICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQpJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCmlwdjZAaWV0 Zi5vcmcNCkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3VybGRlZmVuc2UuY29tL3Yz L19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2X187ISFORXQ2eU1h Ty1nayFVQlJQUThlOGpOaFIwSHVtampuWWFQNmg1QUFEeklqRUpCZmNOdXJlcjByNEFFUm5sdkZO RjVSMXRwX1h5czBhJA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== From nobody Mon Oct 11 17:48:40 2021 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 0F68F3A0744 for ; Mon, 11 Oct 2021 17:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=herbertland-com.20210112.gappssmtp.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 ODzDL8OAXeo6 for ; Mon, 11 Oct 2021 17:48:32 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 EEB503A074B for ; Mon, 11 Oct 2021 17:48:31 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id z20so74110312edc.13 for ; Mon, 11 Oct 2021 17:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2irVSmPlwOxM3yyC/+0xeCa9MWuOLhTZEcWFxokYOY0=; b=X0WUjPkz+G4mrXz8NvFtufeCI5d/VSGrZfUPPJiwrZDqbJDBmDpuDWJQBVDOWA5vCZ liq2bM1QcLOnrrD7Ufgl3bP5u9odZe3lH+SKYNBC3HpgU1H6ik33B1Fo9GQkRhdP65H8 e7NBMzv7TbC+cn6zRBLD1f1VuEMjv3aPxBQJJrcYsBLxQE+6saTN1bIh083ycw6mhNXj YPqySn+T9qa4wj4aSctoD1DttzQQ/idK5WW0UJyqCbLkMvoDxgyI00TylT/Vi2V7yYbX E6Vy1hkaabZhpFRYUEe2jNLX8xAdNdKqjAM3v0aHg4oJb+YFVsvB4C9ajZ/2G+u+8ITK LYyg== 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:content-transfer-encoding; bh=2irVSmPlwOxM3yyC/+0xeCa9MWuOLhTZEcWFxokYOY0=; b=ZU3xD59aIGCgsW78CiJbxgfMAb+5oKqp2S38A4gKggdM/xiGN//G2XaiMV/83wzxC4 Bdokum3R5/HEmlKEzTLfFNKLILnyxXYNTwyGyLdf0fUlGkeqXzIFtwdsDsoFavybIdpI KRr1NUk2fdUq47bTNsEg4qx1FWJkyCfzLFk/SeTUDh416EAtRhbT+664bvJI+0vRB3I0 C9awxQtr2Gj8CoUuutu2yUpr63Y+sW3+IBnAENTIc03yg7oaQAUowe4FEfdTSZtkurEV Zvkz9vfPEhEHbeSmY00Er+iGP2cHTKE4XL2RSAwOUO55JP/HOus9sDAP4ikxMafhgfr7 dkAg== X-Gm-Message-State: AOAM530fYmThbskKIRjn+qLNlqsWm5PkI4H6rUv69O+aLrIrixqLVdns tRHFHH5LbpPkG3quskDcJP1XwAT/fJ9bzjK71v4mIA== X-Google-Smtp-Source: ABdhPJypN9ngZEXZimdS3q/WYszT1SPWH9C2iKM7aK3foElCjBBkR2TgWJMDgCl7vFc+8v5pfJl4j54vTC7VixO5D6Q= X-Received: by 2002:a17:906:3bca:: with SMTP id v10mr29261964ejf.9.1633999710116; Mon, 11 Oct 2021 17:48:30 -0700 (PDT) MIME-Version: 1.0 References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> <423b08d46294454d9a9625990ce52acb@huawei.com> <322a8c29-e232-a39d-94ca-9c9cbf09c8d2@gmail.com> <9945ca9c-2ba7-bd00-6e3e-261c376a9718@gmail.com> In-Reply-To: From: Tom Herbert Date: Mon, 11 Oct 2021 17:48:19 -0700 Message-ID: To: Ron Bonica Cc: Brian E Carpenter , Robert Raszuk , 6MAN <6man@ietf.org>, SPRING WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 12 Oct 2021 00:48:38 -0000 On Mon, Oct 11, 2021 at 4:14 PM Ron Bonica wrote: > > Folks, > > It is much more simple than this. > > According to RFC 8200, an IPv6 Destination Address is the =E2=80=9C128-bi= t address of the intended recipient of the packet (possibly not the ultimat= e recipient, if a Routing header is present). See [RFC4291] and Section 4.4= .=E2=80=9D > > Therefore, if a packet does not contain a Routing header, its IPv6 Destin= ation Address is the 128-bit address of its *ultimate recipient*. > > Therefore, a node MUST have billions of IPv6 addresses in order to consum= e a packet: > > - that does not have a Routing header > - whose IPv6 destination address is a 128-bit carrier C-SID > > This is because billions of carrier CSIDs can be used to route the packet= to that node. > > The vast majority of those addresses are not configured on the node. > > I am pretty sure that this is not what RFC 8200 had in mind. Ron, I'm not sure I understand this. Isn't it already common practice in mobile networks to assign each host its own /64 from which the host can use SLAAC to dynamically create fully qualified and routable 128-bit addresses? If such a host wants to create one, two, or a billion addresses from that space for its own purposes then what does the Internet or the protocol care? In fact, the idea of creating a unique source address for each client TCP connection has already been floated as there are potential advantages for privacy by obfuscating addresses to prevent third parties from making correlations to identify the sender of different flows (e.g. draft-herbert-ipv6-prefix-address-privacy). Tom > > Ron > > > > > > Billions of unique 128-bit CSID containers can steer a packet to a partic= ular node. Therefore, that node must have billions of addresses, the vast m= ajority of which are not configured on the node!! > > > > > Juniper Business Use Only > > -----Original Message----- > From: ipv6 On Behalf Of Brian E Carpenter > Sent: Saturday, October 9, 2021 4:02 PM > To: Robert Raszuk ; 6MAN <6man@ietf.org> > Cc: SPRING WG > Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 > > [External Email. Be cautious of content] > > > On 10-Oct-21 00:39, Robert Raszuk wrote: > > Hi Brian, > > > >> Which means: 64 bits. > > > > Sorry but what is so magic about /64 here ? > > It is mandated by the current IPv6 addressing architecture. Despite many = discussions, there has never been consensus to change it. So if /64 is not = the boundary between the routeable part and the host-specific part, it's no= t IPv6. > > Brian > > > > > Is this coming from the longest routable IPv6 prefix ? Sort of analogy = to /24 in the IPv4 world ? Or something else ? > > > > I think LPM and CIDR techniques are pretty well established. > > > > Any fixed length of the address block with the meaning - do not use tho= se bits inter or intra domain for anything useful even if your prefix+node = can happily fit in /32 seems just dead wrong to me. And that is irrespectiv= e of any SRv6 discussion. > > > > In my books if I get allocated say /48 or /40 from RIR what I do with t= he remaining bits is my own business. > > > > Best, > > R. > > > > > > > > > Sorry, but it is a little bit late =E2=80=93 RFC 8986 is already = published. > > > > "Locators are assigned consistent with IPv6 infrastructure allocati= on." > > > > Which means: 64 bits. > > > > I have no time to study compressed SIDs, but if they trample on the > LOC they are not IPv6 addresses. > > > > Brian > > > > > > -------------------------------------------------------------------= - > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://urldefense.com/v3/__https://www.ie= tf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!UBRPQ8e8jNhR0HumjjnYaP6h5AADzI= jEJBfcNurer0r4AERnlvFNF5R1tp_Xys0a$ > > > -------------------------------------------------------------------= - > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org= /mailman/listinfo/ipv6__;!!NEt6yMaO-gk!UBRPQ8e8jNhR0HumjjnYaP6h5AADzIjEJBfc= Nurer0r4AERnlvFNF5R1tp_Xys0a$ > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Mon Oct 11 18:13:39 2021 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 2F4D63A0990; Mon, 11 Oct 2021 18:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=2IWy6XN2; dkim=pass (1024-bit key) header.d=juniper.net header.b=FD6rW3Tx 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 GHodWlSBt78t; Mon, 11 Oct 2021 18:13:31 -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 145D43A0984; Mon, 11 Oct 2021 18:13:30 -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 SMTP id 19BGX6IQ028915; Mon, 11 Oct 2021 18:13:29 -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-transfer-encoding : mime-version; s=PPS1017; bh=mbWxh27StTDxWpHuqs5H7Be0fWv+Y44xw4m15ybmUpo=; b=2IWy6XN2H4qxtkDDoSOhu1AfRQn0TZ2vDmRSyuCXeu7qzsv4Vkr8o7nJs/F4qqVkNJLf 0ns203c0P9yXMUf5oaebzEAccU7AFr6OSgXhnpwd1aPVESgkO4P89FPHt/hLoLoNF4Qd toLU2SFLXwH3YjN+85awLvJq95qXF8SFuGTtXmZ1QikKZWt9YYYv6MMchwZHrpO9/8ve MatGtjit5rG8L2kVjdhCFSxy3dHWZxrC9MV/aJYEI2X3P4nwKOm/vB5YksTuAfA2sNi+ pE/mdmxN5AFI+m+qv6xTY/V7FMSVOgBquVtzhlJ6HIML3TilrI2+qp89MX6aYK9KAOuz lQ== Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2171.outbound.protection.outlook.com [104.47.59.171]) by mx0b-00273201.pphosted.com with ESMTP id 3bmrvy8wtx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Oct 2021 18:13:29 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T358nBR1bUf6shbX9pCDUqoTCeHrKyNRJAZbDlTPJzSv58BYg9iWYNiAJe5kEyzah0TaEUL3x/HCm1A7xqhkDmQ0fi0Wt0XTgfh8ecIjRVqu6jDvSmKkXVcR8CSdaGZNvaVlT5Jgp8ikgLD0qis6XAoA5mWSXk3KXhrA8HtbfdseWasCKCn1K0ccc/E+Jj3OLq2UQnO8xa/4/jNd/P2yUyCZX9vA/HPYTsV5Pw1TsdfstMA60xLhcdw/Rghrt43gpTEbTIQpKPL12jL5nYxnIPW1M4f3SqFD7fOKNpfKocC8y7aKYHw5wECKUBpUR+oNpzkBNaCCCQD4c429EHlwlA== 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=mbWxh27StTDxWpHuqs5H7Be0fWv+Y44xw4m15ybmUpo=; b=N5PUq4qH3LRJ1dbW1t7OddQUdTg75+q5TD97v/xdcjoB+XW76H0dFhiIsJSenvIOsyAygPaf6TLcmRCSkY/4ftRcHlCAjfyP2AzFhz9+ZbTgxKqbZL0gc6JV9etnTiqE36B3FzKj17kO3oXLcH07R+UT4Iitd1QnEwU1GXTwQPtESsIAuATtV1Rhhdg1yh0T/DIg2rKgYD/wIkN1jEqo3BUyHh8hcEXb7T9x4s5QAJnI+j3JZKka+zn1BGVsehW5DL9SkMgkYIrtzImWbYJo0ixUfeb997zgDKRateI+wO4EAxlYWOSrn1CKRyFqPgLb3WdNiAodEZ36wEYAwh98kQ== 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=mbWxh27StTDxWpHuqs5H7Be0fWv+Y44xw4m15ybmUpo=; b=FD6rW3TxRwEUOYKVD8tVD8VSaO9Ea7ewp7/sozCEdibcSK0vJQOFdL4mph+X5e3DRIzOzDN/100dnqzSH2XMdxmPuuPP+X1HEBztjTn+UFl16nVr7I3Vq7NyDkp1cU9K9SQmbicVosOv8+1qgezuzOd3zAlSj8m3jS6aWchptsQ= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by BL0PR05MB5156.namprd05.prod.outlook.com (2603:10b6:208:88::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.14; Tue, 12 Oct 2021 01:13:27 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4608.014; Tue, 12 Oct 2021 01:13:27 +0000 From: Ron Bonica To: Tom Herbert CC: Brian E Carpenter , Robert Raszuk , 6MAN <6man@ietf.org>, SPRING WG Thread-Topic: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 Thread-Index: Ade3AXyWK2NzAamgSlCvJ497z/5RLwC/aCkQAFbElIAAFRrfwAAcSamAAAzi0oAABMpdgAAVTRUAABGuFAAAEYXYAABo9ucgAAWg3IAAAHBggA== Date: Tue, 12 Oct 2021 01:13:26 +0000 Message-ID: References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> <423b08d46294454d9a9625990ce52acb@huawei.com> <322a8c29-e232-a39d-94ca-9c9cbf09c8d2@gmail.com> <9945ca9c-2ba7-bd00-6e3e-261c376a9718@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-12T01:00:53Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=62736fa6-6c15-4117-9af5-68c8dd2983fe; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_enabled: true msip_label_0633b888-ae0d-4341-a75f-06e04137d755_setdate: 2021-10-12T01:13:25Z msip_label_0633b888-ae0d-4341-a75f-06e04137d755_method: Standard msip_label_0633b888-ae0d-4341-a75f-06e04137d755_name: 0633b888-ae0d-4341-a75f-06e04137d755 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_siteid: bea78b3c-4cdb-4130-854a-1d193232e5f4 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_actionid: 8d24f2ee-9b8e-4294-989a-0fbe1fd2be69 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_contentbits: 0 authentication-results: herbertland.com; dkim=none (message not signed) header.d=none;herbertland.com; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b62e474a-921c-432a-f473-08d98d1d7ed2 x-ms-traffictypediagnostic: BL0PR05MB5156: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kd5F8+RHTBJSySZTx9FyCqWleLT4I7vSYD5ro/tZlN3/i/jVpPEfDsmr0c1vx3DrkeTukNlzc7kokVNIIfHY/cRIDMf5UnJtv4MFurJLLwtsv2IwXXLV5KkXtP9gljxHqJ/5/S8fvqmpNT2G6M7CwNwWL4ttB94IRDnEY/0YEf61OubmZqMZTMenGeDJA33hDqnBY7jW/m0L0xBXIAICjt2ZBtTyxuK00xA+JlTTGmjUHHGw2jYH6/LicU4spBc18lP2+7n8dNGXDmV4IGYzcj8AKA1WQ+FHha36wh+zWjrWiN7Cg53uxXSAQjeA1WdUGBum0ik08AGHWEgwUIDl2QuQB5l2r3aZAY7XViVReHSxCkzpJX1SVKfXnL13ipyRqgmsOWhjGPB66Fh36mwtYOjFUhLapcSeJMlMRzQTbKJGt4o45MVaCxyLOSzmg3a9D6xUOxQLpLpR1EqFjPW/4Y8ox2AYL+kOyTkwWufQCqKm/DTpa+1Rv4wNNFXu+C+WRh4z9R9ViHRnRmpUoI6CgjWPwHEV/YGUoK8vZHJVCfXKgun4oBd+Pxbic30X22L2nTr/BftW16nIh1idZtZR1s0tJR0Lbb8Gtp2S5Q1b3a09Ki6usZl/Qel4mPFT59v7nZW7vVXYDY7j3inmFKn3T6fr67+jFGZe/LtGY4KMsbF01Fz08x313EpfDCRUrBdHdUrpTZj4hQgezpR7kjP3/eFUnzMjCePA8DprM7yUhKHNUsYIx5UDm2i8Ng5eZ6+24akodLNlv50nQkZiI2435E5Yys87UDC7oqJBw3ZnvC8Ni1l/MUUTL2orpBuSpWWZFktMP84JWgg/eYF9V2wvhA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(8676002)(52536014)(9686003)(76116006)(5660300002)(71200400001)(6506007)(86362001)(55016002)(53546011)(8936002)(186003)(33656002)(26005)(66446008)(64756008)(66556008)(66476007)(66946007)(4326008)(6916009)(83380400001)(7696005)(316002)(66574015)(966005)(2906002)(508600001)(38070700005)(122000001)(54906003)(38100700002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?UDZ2N2J5RVgwemJ6a0tsQm5GcEJTczlWVUFseG0zYnk5MWwxLytzWXJZak9I?= =?utf-8?B?ZGROQ3lLU3R0UCtuRS8yd0szVkJzOHRLQkNxdXBBM205TmVSNUlZeHRnT25K?= =?utf-8?B?VGcxL0J3cXFOTGVZSnQ1TmFGaE1jbi95WnM0UUppdXRPUytGY1NrRkNmaXNF?= =?utf-8?B?M1IvT1BOUmQ0VDlyams2S01jVzF6MXRtNlhhdXhFWFkzZzRVSlJYRGRzY2JN?= =?utf-8?B?dk9UZ2NKQ2o0b3JPVWtDZ1lWUWNEZkdQeDZGdUViU090VkZJblpKN0hWV0ZB?= =?utf-8?B?Tys5RGZ2NnNIUFBOV2pJNGdsVGVCRVEzbVdtUmRHVkxlbU5aa0czdlVtWFFY?= =?utf-8?B?QTlXVjdjTklid2U0YTllMWlab0pFSERzSUdMTG1WSE1SNFJvbHRNV2ZYNGZR?= =?utf-8?B?VGppZ3FKUzVZVGF3TlE5UUNZcXI2WjVIY29sOEhPOXB5Njk3T1VmR1VhWjYr?= =?utf-8?B?L3M5ZXJjMXRQSHY1Mm5ISkMwWS83N1g2dlpncXFBZlM4cFRnOVZWZ1hXakl1?= =?utf-8?B?VWpZREtvKzUyc0lNWmRpN21BS0dnN3hDeHFWMFp1Uk5zNVNYblhNdVY2ckdo?= =?utf-8?B?MVJpTG96V3dQWUNvZVdiNzVXS2ZubG5xMFgwZmUwYmZOK1lBSDdKRkx5VmFS?= =?utf-8?B?UXNqWU1JZko3UTZhU3lkbHJiSGRteU9veFFhZDFoYVJPNkQraEhzMzJteEFQ?= =?utf-8?B?UFJHTWVNamdacTgvYzBTN0NzcnoyU3BkY2U1c1JvY2QreERXRGFPYldjL2ov?= =?utf-8?B?Mm1LR25nUnQ0SHRkQTE2RUNLRHhoS0RyL0RZOStlZDUwZUN4RmRZSEIyTEk1?= =?utf-8?B?QWhnNlBubVpCMVUrWFFPK0pGMXNSMGFZeE8rbjNjMlpwNWYwam1lVGI4Mlc2?= =?utf-8?B?U20wU1NaWjBITE03OFlocEhyNVhBNHdoNFE0T2t0TUpRVW1qY0h5c2RCZUVU?= =?utf-8?B?eFMraWlOM1h4bDBQQVRzUkZja09GbGp6eFF5aEZCRzlPcFpRR0dwREl5dmMv?= =?utf-8?B?V2xFWWxHVkhOdDZzbnZNUExjemd5YUFyVFJBY1ltQUlWT2M2KzBCVVRkN1NX?= =?utf-8?B?YnE0b0N1ek5za0lSQW15UUlaYlUxYjB1bkRERlhCYnBBQ3lpVitIYmN2UUU4?= =?utf-8?B?cThnZmhDaU5NaGJ1Qm5FczAwaWYvdVljNGZLWTdBWnl0blRRdlBnSUhTaW5V?= =?utf-8?B?eThQMWNyVFJJait3WVYwUWhNWjM4alRCSmx3ZUc3VHFIdnF5UGx3T0N2b1Fp?= =?utf-8?B?MDBpSzZPOENBWkVGVS94dXQ4ekNGbDNScEZua05FOUcva3hSWm45YWhIRWdT?= =?utf-8?B?dVRXTGR4MjFqVUxWa1pzTEhOd0s2MUVxU0VQSjc0VUp2dU5ZdndPNC9oZ3dX?= =?utf-8?B?UVg0aHNlMk90aU9SbGIwbWY2bzdSeVRZNWQ5a2kyTkE3TVJZSTZlSjFpUTNp?= =?utf-8?B?dXFRUTFFd3YrUmFSeGtCK2R1L2krQzRGYTRLNEk5eUFuWi9ZMXl4S3IyeW5q?= =?utf-8?B?VGkzNTNaYUsxblYrY2N3U3lJNUZnSHEzZjYxYzh1MjVLMW5ROXhhcm9BWisr?= =?utf-8?B?eVRhMFl5eEJoamMrNE1IUERlNkhRa2JMbCtDU3VjRlc2eTBEcTR5YVIrUTN3?= =?utf-8?B?ZkUwTW9nRzFHN3JvRU1FbmZJL2xlQm96VXlCZWg2Um90UW9WcnQ5UzlhcU5J?= =?utf-8?B?OUFFSDdNWlo4a01sMityaGZHOHFFVTRhRDdtcERiYmNFMm52QWNkQUVhcmhI?= =?utf-8?Q?kkHcIg61p2ltVI7+Nn6v/rweiKJtZerugGVdwQr?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b62e474a-921c-432a-f473-08d98d1d7ed2 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2021 01:13:26.9928 (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: nyj9ErNVeU0DtWVZh1MmfEUKFoWheW6M4Pdmdp6BTG04l8B4RRv4x/8IfTgkgkj0bbl2KTHrEn7N4GLfrDiUPw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5156 X-Proofpoint-ORIG-GUID: Wvd5HxYqCjsOq5pB8M8rTl4US6XtgxPf X-Proofpoint-GUID: Wvd5HxYqCjsOq5pB8M8rTl4US6XtgxPf X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-11_11,2021-10-11_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1011 spamscore=0 adultscore=0 lowpriorityscore=0 malwarescore=0 bulkscore=0 phishscore=0 priorityscore=1501 mlxlogscore=999 impostorscore=0 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110120003 Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 12 Oct 2021 01:13:37 -0000 VG9tLA0KDQpUaGVyZSBpcyBhIGRpZmZlcmVuY2UgYmV0d2VlbiBDLVNJRCBhbmQgdGhlIGNvbW1v biBtb2JpbGUgcHJhY3RpY2UuLi4uLi4NCg0KQ29uc2lkZXIgYW4gU1J2NiBkb21haW4gd2hlcmU6 DQoNCi0gVGhlIGNvbW1vbiBwcmVmaXggaXMgMjAwMTpkYjg6Oi80OA0KLSBFYWNoIEMtU0lEIGlz IDE2IGJpdHMgbG9uZw0KLSBOb2RlIEEgaW5zdGFudGlhdGVzIHRoZSBzZWdtZW50IDIwMDE6ZGI4 OjE6Oi8xMjgNCg0KVGhlIGZvbGxvd2luZyBhcmUgYWxsIGFkZHJlc3NlcyBvZiBOb2RlIEE6DQoN Ci0gMjAwMTpkYjg6MjoxOjovMTI4DQotIDIwMDE6ZGI4OjM6MTo6LzEyOA0KLTIwMDE6ZGI4OjI6 MzoxOjovMTI4DQotIEFuZCBiaWxsaW9ucyBvZiBvdGhlcnMuLi4NCg0KWWVzLCB0aGV5IGFyZSBh bGwgZHJhd24gZnJvbSAyMDAxOmRiODo6LzQ4LiBCdXQgTm9kZSBBIGlzIG5vdCB0aGUgc29sZSBv d25lciBvZiAyMDAxOmRiODo6LzQ4Lg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFJvbg0KDQoNCg0KSnVuaXBl ciBCdXNpbmVzcyBVc2UgT25seQ0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog VG9tIEhlcmJlcnQgPHRvbUBoZXJiZXJ0bGFuZC5jb20+IA0KU2VudDogTW9uZGF5LCBPY3RvYmVy IDExLCAyMDIxIDg6NDggUE0NClRvOiBSb24gQm9uaWNhIDxyYm9uaWNhQGp1bmlwZXIubmV0Pg0K Q2M6IEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb20+OyBSb2Jl cnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldD47IDZNQU4gPDZtYW5AaWV0Zi5vcmc+OyBTUFJJ TkcgV0cgPHNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBkcmFmdC1maWxz Zmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi0wMg0KDQpbRXh0ZXJuYWwgRW1h aWwuIEJlIGNhdXRpb3VzIG9mIGNvbnRlbnRdDQoNCg0KT24gTW9uLCBPY3QgMTEsIDIwMjEgYXQg NDoxNCBQTSBSb24gQm9uaWNhIDxyYm9uaWNhPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+ IHdyb3RlOg0KPg0KPiBGb2xrcywNCj4NCj4gSXQgaXMgbXVjaCBtb3JlIHNpbXBsZSB0aGFuIHRo aXMuDQo+DQo+IEFjY29yZGluZyB0byBSRkMgODIwMCwgYW4gSVB2NiBEZXN0aW5hdGlvbiBBZGRy ZXNzIGlzIHRoZSDigJwxMjgtYml0IGFkZHJlc3Mgb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudCBv ZiB0aGUgcGFja2V0IChwb3NzaWJseSBub3QgdGhlIHVsdGltYXRlIHJlY2lwaWVudCwgaWYgYSBS b3V0aW5nIGhlYWRlciBpcyBwcmVzZW50KS4gU2VlIFtSRkM0MjkxXSBhbmQgU2VjdGlvbiA0LjQu 4oCdDQo+DQo+IFRoZXJlZm9yZSwgaWYgYSBwYWNrZXQgZG9lcyBub3QgY29udGFpbiBhIFJvdXRp bmcgaGVhZGVyLCBpdHMgSVB2NiBEZXN0aW5hdGlvbiBBZGRyZXNzIGlzIHRoZSAxMjgtYml0IGFk ZHJlc3Mgb2YgaXRzICp1bHRpbWF0ZSByZWNpcGllbnQqLg0KPg0KPiBUaGVyZWZvcmUsIGEgbm9k ZSBNVVNUIGhhdmUgYmlsbGlvbnMgb2YgSVB2NiBhZGRyZXNzZXMgaW4gb3JkZXIgdG8gY29uc3Vt ZSBhIHBhY2tldDoNCj4NCj4gLSB0aGF0IGRvZXMgbm90IGhhdmUgYSBSb3V0aW5nIGhlYWRlcg0K PiAtIHdob3NlIElQdjYgZGVzdGluYXRpb24gYWRkcmVzcyBpcyBhIDEyOC1iaXQgY2FycmllciBD LVNJRA0KPg0KPiBUaGlzIGlzIGJlY2F1c2UgYmlsbGlvbnMgb2YgY2FycmllciBDU0lEcyBjYW4g YmUgdXNlZCB0byByb3V0ZSB0aGUgcGFja2V0IHRvIHRoYXQgbm9kZS4NCj4NCj4gVGhlIHZhc3Qg bWFqb3JpdHkgb2YgdGhvc2UgYWRkcmVzc2VzIGFyZSBub3QgY29uZmlndXJlZCBvbiB0aGUgbm9k ZS4NCj4NCj4gSSBhbSBwcmV0dHkgc3VyZSB0aGF0IHRoaXMgaXMgbm90IHdoYXQgUkZDIDgyMDAg aGFkIGluIG1pbmQuDQoNClJvbiwNCg0KSSdtIG5vdCBzdXJlIEkgdW5kZXJzdGFuZCB0aGlzLiBJ c24ndCBpdCBhbHJlYWR5IGNvbW1vbiBwcmFjdGljZSBpbiBtb2JpbGUgbmV0d29ya3MgdG8gYXNz aWduIGVhY2ggaG9zdCBpdHMgb3duIC82NCBmcm9tIHdoaWNoIHRoZSBob3N0IGNhbiB1c2UgU0xB QUMgdG8gZHluYW1pY2FsbHkgY3JlYXRlIGZ1bGx5IHF1YWxpZmllZCBhbmQgcm91dGFibGUgMTI4 LWJpdCBhZGRyZXNzZXM/IElmIHN1Y2ggYSBob3N0IHdhbnRzIHRvIGNyZWF0ZSBvbmUsIHR3bywg b3IgYSBiaWxsaW9uIGFkZHJlc3NlcyBmcm9tIHRoYXQgc3BhY2UgZm9yIGl0cyBvd24gcHVycG9z ZXMgdGhlbiB3aGF0IGRvZXMgdGhlIEludGVybmV0IG9yIHRoZSBwcm90b2NvbCBjYXJlPyBJbiBm YWN0LCB0aGUgaWRlYSBvZiBjcmVhdGluZyBhIHVuaXF1ZSBzb3VyY2UgYWRkcmVzcyBmb3IgZWFj aCBjbGllbnQgVENQIGNvbm5lY3Rpb24gaGFzIGFscmVhZHkgYmVlbiBmbG9hdGVkIGFzIHRoZXJl IGFyZSBwb3RlbnRpYWwgYWR2YW50YWdlcyBmb3IgcHJpdmFjeSBieSBvYmZ1c2NhdGluZyBhZGRy ZXNzZXMgdG8gcHJldmVudCB0aGlyZCBwYXJ0aWVzIGZyb20gbWFraW5nIGNvcnJlbGF0aW9ucyB0 byBpZGVudGlmeSB0aGUgc2VuZGVyIG9mIGRpZmZlcmVudCBmbG93cyAoZS5nLg0KZHJhZnQtaGVy YmVydC1pcHY2LXByZWZpeC1hZGRyZXNzLXByaXZhY3kpLg0KDQpUb20NCg0KPg0KPiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBSb24NCj4NCj4NCj4NCj4N Cj4NCj4gQmlsbGlvbnMgb2YgdW5pcXVlIDEyOC1iaXQgQ1NJRCBjb250YWluZXJzIGNhbiBzdGVl ciBhIHBhY2tldCB0byBhIHBhcnRpY3VsYXIgbm9kZS4gVGhlcmVmb3JlLCB0aGF0IG5vZGUgbXVz dCBoYXZlIGJpbGxpb25zIG9mIGFkZHJlc3NlcywgdGhlIHZhc3QgbWFqb3JpdHkgb2Ygd2hpY2gg YXJlIG5vdCBjb25maWd1cmVkIG9uIHRoZSBub2RlISENCj4NCj4NCj4NCj4NCj4gSnVuaXBlciBC dXNpbmVzcyBVc2UgT25seQ0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9t OiBpcHY2IDxpcHY2LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBCcmlhbiBFIENhcnBl bnRlcg0KPiBTZW50OiBTYXR1cmRheSwgT2N0b2JlciA5LCAyMDIxIDQ6MDIgUE0NCj4gVG86IFJv YmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PjsgNk1BTiA8Nm1hbkBpZXRmLm9yZz4NCj4g Q2M6IFNQUklORyBXRyA8c3ByaW5nQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZTogW3NwcmluZ10g DQo+IGRyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLTAyDQo+ DQo+IFtFeHRlcm5hbCBFbWFpbC4gQmUgY2F1dGlvdXMgb2YgY29udGVudF0NCj4NCj4NCj4gT24g MTAtT2N0LTIxIDAwOjM5LCBSb2JlcnQgUmFzenVrIHdyb3RlOg0KPiA+IEhpIEJyaWFuLA0KPiA+ DQo+ID4+IFdoaWNoIG1lYW5zOiA2NCBiaXRzLg0KPiA+DQo+ID4gU29ycnkgYnV0IHdoYXQgaXMg c28gbWFnaWMgYWJvdXQgLzY0IGhlcmUgPw0KPg0KPiBJdCBpcyBtYW5kYXRlZCBieSB0aGUgY3Vy cmVudCBJUHY2IGFkZHJlc3NpbmcgYXJjaGl0ZWN0dXJlLiBEZXNwaXRlIG1hbnkgZGlzY3Vzc2lv bnMsIHRoZXJlIGhhcyBuZXZlciBiZWVuIGNvbnNlbnN1cyB0byBjaGFuZ2UgaXQuIFNvIGlmIC82 NCBpcyBub3QgdGhlIGJvdW5kYXJ5IGJldHdlZW4gdGhlIHJvdXRlYWJsZSBwYXJ0IGFuZCB0aGUg aG9zdC1zcGVjaWZpYyBwYXJ0LCBpdCdzIG5vdCBJUHY2Lg0KPg0KPiAgICBCcmlhbg0KPg0KPiA+ DQo+ID4gSXMgdGhpcyBjb21pbmcgZnJvbSB0aGUgbG9uZ2VzdCByb3V0YWJsZSBJUHY2IHByZWZp eCA/IFNvcnQgb2YgYW5hbG9neSB0byAvMjQgaW4gdGhlIElQdjQgd29ybGQgPyBPciBzb21ldGhp bmcgZWxzZSA/DQo+ID4NCj4gPiBJIHRoaW5rIExQTSBhbmQgQ0lEUiB0ZWNobmlxdWVzIGFyZSBw cmV0dHkgd2VsbCBlc3RhYmxpc2hlZC4NCj4gPg0KPiA+IEFueSBmaXhlZCBsZW5ndGggb2YgdGhl IGFkZHJlc3MgYmxvY2sgd2l0aCB0aGUgbWVhbmluZyAtIGRvIG5vdCB1c2UgdGhvc2UgYml0cyBp bnRlciBvciBpbnRyYSBkb21haW4gZm9yIGFueXRoaW5nIHVzZWZ1bCBldmVuIGlmIHlvdXIgcHJl Zml4K25vZGUgY2FuIGhhcHBpbHkgZml0IGluIC8zMiBzZWVtcyBqdXN0IGRlYWQgd3JvbmcgdG8g bWUuIEFuZCB0aGF0IGlzIGlycmVzcGVjdGl2ZSBvZiBhbnkgU1J2NiBkaXNjdXNzaW9uLg0KPiA+ DQo+ID4gSW4gbXkgYm9va3MgaWYgSSBnZXQgYWxsb2NhdGVkIHNheSAvNDggb3IgLzQwIGZyb20g UklSIHdoYXQgSSBkbyB3aXRoIHRoZSByZW1haW5pbmcgYml0cyBpcyBteSBvd24gYnVzaW5lc3Mu DQo+ID4NCj4gPiBCZXN0LA0KPiA+IFIuDQo+ID4NCj4gPg0KPiA+DQo+ID4gICAgID4gU29ycnks IGJ1dCBpdCBpcyBhIGxpdHRsZSBiaXQgbGF0ZSDigJMgUkZDIDg5ODYgaXMgYWxyZWFkeSBwdWJs aXNoZWQuDQo+ID4NCj4gPiAgICAgIkxvY2F0b3JzIGFyZSBhc3NpZ25lZCBjb25zaXN0ZW50IHdp dGggSVB2NiBpbmZyYXN0cnVjdHVyZSBhbGxvY2F0aW9uLiINCj4gPg0KPiA+ICAgICBXaGljaCBt ZWFuczogNjQgYml0cy4NCj4gPg0KPiA+ICAgICBJIGhhdmUgbm8gdGltZSB0byBzdHVkeSBjb21w cmVzc2VkIFNJRHMsIGJ1dCBpZiB0aGV5IHRyYW1wbGUgb24gDQo+ID4gdGhlDQo+IExPQyB0aGV5 IGFyZSBub3QgSVB2NiBhZGRyZXNzZXMuDQo+ID4NCj4gPiAgICAgICAgQnJpYW4NCj4gPg0KPiA+ DQo+ID4gICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gICAgIElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1h aWxpbmcgbGlzdA0KPiA+ICAgICBpcHY2QGlldGYub3JnIDxtYWlsdG86aXB2NkBpZXRmLm9yZz4N Cj4gPiAgICAgQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IA0KPiA+IGh0dHBzOi8vdXJsZGVmZW5z ZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwDQo+ID4g djZfXzshIU5FdDZ5TWFPLWdrIVVCUlBROGU4ak5oUjBIdW1qam5ZYVA2aDVBQUR6SWpFSkJmY051 cmVyMHI0QUVSbmwNCj4gPiB2Rk5GNVIxdHBfWHlzMGEkDQo+IDxodHRwczovL3VybGRlZmVuc2Uu Y29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHYNCj4gNl9f OyEhTkV0NnlNYU8tZ2shVUJSUFE4ZThqTmhSMEh1bWpqbllhUDZoNUFBRHpJakVKQmZjTnVyZXIw cjRBRVJubHZGTg0KPiBGNVIxdHBfWHlzMGEkID4NCj4gPiAgICAgDQo+ID4gLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj4gPg0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5n IGxpc3QNCj4gaXB2NkBpZXRmLm9yZw0KPiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogDQo+IGh0 dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL2lwdjYNCj4gX187ISFORXQ2eU1hTy1nayFVQlJQUThlOGpOaFIwSHVtampuWWFQNmg1 QUFEeklqRUpCZmNOdXJlcjByNEFFUm5sdkZORg0KPiA1UjF0cF9YeXMwYSQNCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0 DQo+IGlwdjZAaWV0Zi5vcmcNCj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IA0KPiBodHRwczov L3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pcHY2DQo+IF9fOyEhTkV0NnlNYU8tZ2shUkV0LXNjLTVNVkJBaGpEU1B6OWZUd0d4TUt3RnRk TGhxUVNuYTlUUnd0cnN1SHlyWWw0TXYNCj4gS19Nb1IyN3MySmwkDQo+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo= From nobody Mon Oct 11 18:18:44 2021 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 A7C0C3A0A22; Mon, 11 Oct 2021 18:18:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=KnEZlIF+; dkim=pass (1024-bit key) header.d=juniper.net header.b=BgiXQqlx 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 In5BZa-z1-Lw; Mon, 11 Oct 2021 18:18:34 -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 DAF5D3A0A1B; Mon, 11 Oct 2021 18:18:33 -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 SMTP id 19BGXGLj030522; Mon, 11 Oct 2021 18:18:31 -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=a3brxTT/lCB313tbR5wMI5Kil9twot8p1AKk9Olxsbk=; b=KnEZlIF+PPV+WRnDP0CVf8QvJhWnqyXafATpxwBK9VXYPth9CUeEqagVGJdeoOZP/Lur PS4Vsb0Bq5EHBRnGKSblqlExsREDGFaY5b7s6dIYQ/rwh7v2vsqDBnPF6l6QhHgHVmqP skAOmNeT3aRD1qZvRbINvT9HSHiY16253uYafzP8K0hBmJGhaU8iQcZpgFCB+9K3DG4X 9VlPKw8MqbAdirPR/M1snSg5YSKO/0553fTVPGfA1XShVkQpf0fLdPZiCr8cKyHQ79Zw E383HFOP/Q/gXiX9hPoJwSe22DEOAiYhvAIg+rT9kpC9ESrC4DjpDNJO1Aothkik8hL0 Xw== Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2170.outbound.protection.outlook.com [104.47.57.170]) by mx0b-00273201.pphosted.com with ESMTP id 3bmrvy8x1y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Oct 2021 18:18:31 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eAQwnG2shtuDI40b9c+Favewh3wvGeLWnNQ7Eu4qaVxE5MHreePw5T2WKFdlasmcuq94fqXRjb4qei0FonEzJjDVbp7q3vzILcRbQCEOgpTsSsUQQ/CwBGmMb2Bj7CeiUEPgfxdJPrZPareUc7TctRcIlk9hUHGh+mK6YdspNAp/j/DlPH7fGAqjIG5KqaFkvafuFi1ULnSROwJe5UWSXgy8Uy/q2eGkxDD5DqH8/n1chQzBiai9NHYVyV8AynMi3q89NWKyKBfcRBjl8p/Q7Nmh7DmXraK0PTiEjSuz4IOpkkvkUnMIfZkpDWUX3a9dSZrcZA6+hmoYQvBJhJex3w== 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=a3brxTT/lCB313tbR5wMI5Kil9twot8p1AKk9Olxsbk=; b=Jo+NBXXrzn/X4Cm+tyDAG6S5i6WvTO/KgDoaGR3KN3wVXXljBZgHyNU+/o9GCiB27q8t9nvQm2mb+q7Q7lyz587/vTlaCUTeaCNnanP3z34PIRBdESbvL+CKOc8pMxIn5IyCEw1ph1pXeqhgUTHSI5Zfy/wK3Jh1is5uC3CZ+zpFI00eUB80nszuG9AhMo3hG7UFkSFr/1CbjJzMCHVHspXdRx10fmiVS8QBaIkQYVZbtGLPP92s+r0VvVT8lO+XyNuDrs/vUNU63B6uDvb+C+z5zZhyM9cvAa4APupw1y4hzwZqwPTU14YQA8VqtFo5NkN+6Gs8I11U+hAGyLCjNw== 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=a3brxTT/lCB313tbR5wMI5Kil9twot8p1AKk9Olxsbk=; b=BgiXQqlxNRFBYhHmBEQRf1c2co8i9CDP3MDM40B51T+rRR7ixRkzMfS4KSy10wSmAKYcmWcKnwXG8Rp1K449sBrHkP5baScnGREMY9M3YxtozE+AJQZcnqe7WT6bKwjmmYAl0CP74iKAcf7kd1u64OmJbwnh0+CcK4MIR8YAU4k= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by MN2PR05MB6942.namprd05.prod.outlook.com (2603:10b6:208:188::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.8; Tue, 12 Oct 2021 01:18:27 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4608.014; Tue, 12 Oct 2021 01:18:27 +0000 From: Ron Bonica To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQIOp7yA Date: Tue, 12 Oct 2021 01:18:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-12T01:14:19Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=cfa5962a-c804-4eac-89ce-4a8f819834f3; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_enabled: true msip_label_0633b888-ae0d-4341-a75f-06e04137d755_setdate: 2021-10-12T01:18:26Z msip_label_0633b888-ae0d-4341-a75f-06e04137d755_method: Standard msip_label_0633b888-ae0d-4341-a75f-06e04137d755_name: 0633b888-ae0d-4341-a75f-06e04137d755 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_siteid: bea78b3c-4cdb-4130-854a-1d193232e5f4 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_actionid: c72b61ec-34a5-4d22-8d10-bb6b7389b04c msip_label_0633b888-ae0d-4341-a75f-06e04137d755_contentbits: 0 authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 80b1b251-ee10-412b-452d-08d98d1e320e x-ms-traffictypediagnostic: MN2PR05MB6942: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9nPYWUUHrYwwEaYLnokVi57XN9IWicXIc1DYt7sqTWmX7F9/lgDj3T76hmbwU31I1O9ECa3oQ4itvm1imCIW43ryh/9H91+MExB34TBX83pRJ5ewGkVVtoacanG8JeyjZ19+aJIf3K2bX1aJcjOw+s9DJ9mYkhy3EDNX5KvnmlFK3mx9MVIEb7qH5j+4HAo6GsNfcMf2YaHsn2fO8XJErIPCq+ZqxwDpOQ/HqxalVzXkZ3utz0NgLQFbZnq3vrQL+SW1OIgrrPy8R+ITM2ki9CRPTLCngys6OaoPW1w+tqcx4vaELJ3SCfD+m2zkdnnoWib4dREz/8xLpXH2VmAWLtRSDHHaS6cuZI1m8P4Ur7OSgHxkcdU26OP0CWve2kWxqXih4n3FGI978wBpBhrOZXjdzLLGF0GAvL7qVsNmM5lfENsvzdP6x5h8Z5PmpranFB7nCsImtTDwzLNcsL2Jk6FOaA/smh53wPdA0MQ5xt6Lx9uQfk/N7YrMu9VFEpKk4rhChJv6UNdabD34QdEGu6QheAg8+L1WJJC6g+7aRAgaYmqu393PGQvNjAVQ6trg/+ZXbvgCxc55x9qwz/1KVAjUMMal3pR6DaeUq18+Bz1MBg/CWrv0ICZSqppFhda2q1oFtG6XYFGNDYw+wQcdjk7K07JM/9BpgoTQDEyX9Lf5jYeptwHI36V7vXztE16+G1ADt9NpfA28MzvtMQgVyl2AHIln/KbJTeWJ89fjCzqc0FQU0mlYsyEqKtm5jZtSwuLc+7VJ76VOt/J44s9ktgWZanJg/ASHYEE0NF3FdkE= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(86362001)(66446008)(64756008)(66556008)(83380400001)(166002)(66476007)(76116006)(66946007)(38070700005)(33656002)(966005)(8676002)(53546011)(6506007)(4326008)(508600001)(9686003)(55016002)(186003)(52536014)(5660300002)(8936002)(2906002)(26005)(71200400001)(110136005)(316002)(38100700002)(122000001)(7696005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?lIY5+eImhmQFIJYz1tVjO072xVdGFs47w+MV3yVeljm6aBHJtcG3ZScUsN8z?= =?us-ascii?Q?hzQsXj4md9Ag8dfKthlEb8XKSl3ReoBVn/rpILBoHoltSExzUoz39yMO/YCR?= =?us-ascii?Q?MOoSniKay9FAnbc43MixcAUGUBLS+W6A5PqCRKd/gRaTfFuon2LcNxw+8UcI?= =?us-ascii?Q?AfMzpV+75ZLSW1nkklqY4+iSXg6AySU76fHsNdnJNC/Z5a8+jjYgrF2utM9F?= =?us-ascii?Q?5w1srTgvefx6dwbEi9Gxrm0LHBFwEKbpdPn2lUADtnnm5ap143Qv+QXwIC7N?= =?us-ascii?Q?M0v6OIHt9/ahF09CkgyN1W0v8c2KTKRy3U001z3JEBQT16aUdPa376Fs7K04?= =?us-ascii?Q?asOZ6Udwmr3ufOfyy6Zwkk45a/+WWQ5PKAEokc744d6f4O3vZtJVZ0VawN8r?= =?us-ascii?Q?WDAPpadk27Es16o9wsQKjryChmmhsDm3gG1SREmmZX61ZFjJIDgYhR9O4Y2D?= =?us-ascii?Q?p+XVlEMi81LtvhXXqiXi6bOs3GkNTVIcuIPI1rDfM1DkvCnQh3II8gpf211t?= =?us-ascii?Q?Sj56jL99AB3CGOUh4kXXOERDZRMqiotihr1R/mApiw+o3C9x4xWrRfZi76S1?= =?us-ascii?Q?+24Wt+dVLRE1nSoew9DZnXTtRajWz4sehZda47MPRZb4TSLXNbQ6FxUfuyCS?= =?us-ascii?Q?qrP2sKywc53sI89RC4e30ypdxwId80p3hx1GfNJQZfHTmt5CwYED7wQC9XzG?= =?us-ascii?Q?iuArkPM8YgdbCg4eDXztxfveBUbVgNzNemE+I/YWrX7Sq1aQldWO4MsdJ204?= =?us-ascii?Q?wqdZVHUWKO4ZFLz0cgi1hq+mqitALxHWMpCF8nLXfy6LfIU1PavIe7erYBBQ?= =?us-ascii?Q?U7Poco5mjJB++3+uk2w2TH6LDZX2+7BScprNdLF6LSRzCq+BwFYwvmt6IJ4c?= =?us-ascii?Q?LNPnEX2gE1FHx7kSpXBMlWw2HvECGGTIcr0aP9h1ZjFv/77azowqUjED/ZIy?= =?us-ascii?Q?d8S0QWMJ/jKRkfxNUt/OdcNPWz/y+rahNYL31dtwQPLC/AbYFPy+R7buw8lS?= =?us-ascii?Q?zUzk0Pu79GkLHxhDxHyRpQPibOnv4mf87FldijKlB3kpwBhU1zH86IaUmh7Y?= =?us-ascii?Q?OyFswojbcTVDX5/YOkrrqx08vlleyTmy1zAuIpScrYbz83zbkxNmrSHZfsdQ?= =?us-ascii?Q?tYP1fDceyCvKMRJ/j1e+tAjoTOWDJoFF8UhDlvFaFsjBuSYAkVlP6KCpPSUi?= =?us-ascii?Q?cGx8UtWXt83TJSHToQKmCeFT3GZSswwD9H8UkXU+mS8rc0hpNptIXrGuDnlD?= =?us-ascii?Q?Py5HwOrKs8vDDA+5xepTESd5Usiu0V3+6tfipmnkzyBh0Yb41K/H0d+Ehpar?= =?us-ascii?Q?LNOXKaW0InEe+jVA2EcYnyam?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR05MB5316B8F4AAF425CBACC84C97AEB69BL0PR05MB5316namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 80b1b251-ee10-412b-452d-08d98d1e320e X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2021 01:18:27.6368 (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: srZrtvxsM+pH1JU5g3KkJRD1J6lG6jz1k4MY/PMHrb6PholPdR3vbiOKr1OtAYh+PdQl5MfjsPy1YLFiib0faw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6942 X-Proofpoint-ORIG-GUID: fHznXLEhjelNjSXhR5wAvX2KGFtzkc0g X-Proofpoint-GUID: fHznXLEhjelNjSXhR5wAvX2KGFtzkc0g X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-11_11,2021-10-11_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1015 spamscore=0 adultscore=0 lowpriorityscore=0 malwarescore=0 bulkscore=0 phishscore=0 priorityscore=1501 mlxlogscore=999 impostorscore=0 suspectscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110120003 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 12 Oct 2021 01:18:42 -0000 --_000_BL0PR05MB5316B8F4AAF425CBACC84C97AEB69BL0PR05MB5316namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Jim, Before accepting this document, we might want to discuss why the NEXT-C-SID= behavior and the REPLACE-C-SID behavior are both needed. Even if there are= use cases in which one performs slightly better than the other, it the per= formance improvement really worth all of the additional complexity? = Ron Juniper Business Use Only From: spring On Behalf Of James Guichard Sent: Friday, October 1, 2021 10:05 AM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ [External Email. Be cautious of content] Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardizat= ion work. That is part of what this email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as follows. By expressing support for a= doption of this document you are fully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_BL0PR05MB5316B8F4AAF425CBACC84C97AEB69BL0PR05MB5316namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Jim,

     

    Before accepting th= is document, we might want to discuss why the NEXT-C-SID behavior and the R= EPLACE-C-SID behavior are both needed. Even if there are use cases in which= one performs slightly better than the other, it the performance improvement really worth all of the additional c= omplexity?

     

       &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     Ron

     

     

     

    Juniper Business Use Only

    From: spring <spring-bounces@ietf.org> = On Behalf Of James Guichard
    Sent: Friday, October 1, 2021 10:05 AM
    To: SPRING WG <spring@ietf.org>
    Cc: spring-chairs@ietf.org
    Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

     

    <= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

     

    Dear WG:

     

    The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

     

    The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

     

    Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

     

    1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors.
    2. The document is a “living” document; it m= ay change as it goes through review and analysis by the SPRING working grou= p.
    3. All open discussion points raised on our mailing list= MUST be addressed BEFORE said document is allowed to progress from the wor= king group to publication. A list of these discussion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
    4. If this document is adopted by the working group, the= chairs specify as part of the adoption call that the following text descri= bing an open issue be added to the document in the above-described open issues section:
      • "Given th= at the working group has said that it wants to standardize one data plane s= olution, and given that the document contains multiple SRv6 EndPoint behavi= ors that some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

     

    Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    --_000_BL0PR05MB5316B8F4AAF425CBACC84C97AEB69BL0PR05MB5316namp_-- From nobody Mon Oct 11 18:31:42 2021 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 DD5333A0AE2 for ; Mon, 11 Oct 2021 18:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.076 X-Spam-Level: X-Spam-Status: No, score=-0.076 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, FORGED_GMAIL_RCVD=1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 HkDO_LGbfzp8 for ; Mon, 11 Oct 2021 18:31:34 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (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 9A8803A0ABD for ; Mon, 11 Oct 2021 18:31:29 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id t2so61653020wrb.8 for ; Mon, 11 Oct 2021 18:31:29 -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:cc; bh=zeTzoiV9K2QkvXwh7uwCh63qiHBJAFiXGtYXNBgSDuk=; b=h1EgNvKnOjahSrYxQa3sxD/uPdxDc2Oih+ndBXl+cqfq2R0ettiC0+L/48wq3bY3DR ekLSbijeaUZ0X+FoIl9hO/tGjoV4KE6Iur+YcsZvZ6kZhIjS4cvanRd9zFmvR+jkO0WH WzjR22PB9uT93uaoL3rIQ3nxVjRWAPNw2Sg6sV3PZ40RRuWs5kpvqy9FJurwy+22+8Dy xztFNGw9JtTZU6yDkOBN/NB1/0kiKJg7WrPiIP1BdOqvUpRro7ixrNHZAR5jXyrFesVi d8rH9gkDjnKDfR/c1kIn9mxWPbd96Hi1lTFnlttU8L5DEybf6+vBNbT5MuJDnUhqAihK XSFw== 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:cc; bh=zeTzoiV9K2QkvXwh7uwCh63qiHBJAFiXGtYXNBgSDuk=; b=rSuTtESTEraV7S4f6TMmk9ShcTVV1CAcWhOKPQlJIlcTmFHw7bq6Ljn4fswFFgtJAz 6bmL6vMd/8dq5kqXPqHZdzdHW293N87g0mz0f8GaAnUaRPcOZ2B/97TXdQtDjyMYdSFo Y4F71aas+XOTXhI2WFXIIRdQs0QzoBdSCnsl55QvM4C4nMumBkzkQ5jghYx1DN9dattw RryPL2HQvwsOKO6dOGhl075k/XPfyEWLKmbW6obfhOhqD+pb+piNNMEE5F0VAVtAfDqD vhPtsetTlvdl8FhuwBK88Fcu/b2YKBuCBgCq8hL9dpxlvSaCfYD+c4P4tjTpFXrWbO9t XRLw== X-Gm-Message-State: AOAM530yZ0Ms7kzxoarXmji6oNih1HaiR4fdoiOMJ0ptbH5z1Q0hPwhI WH9E3pbpeX/KgW6qVcK2KxqJhO6Iwli9WzjcfKeUEYYlwDM= X-Received: by 2002:adf:d1c2:: with SMTP id b2mt4539333wrd.73.1634002287495; Mon, 11 Oct 2021 18:31:27 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Rishabh Parekh Date: Mon, 11 Oct 2021 18:31:15 -0700 Message-ID: Cc: SPRING WG , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ecf6d505ce1dcd21" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 12 Oct 2021 01:31:40 -0000 --000000000000ecf6d505ce1dcd21 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable With regards to the chair's question, CSID is based on the single SRv6 based data plane. The addition of flavors for SRv6 compression does not mean the draft is defining multiple data planes. This is because, if we go with that logic, RFC8986, which is a product of the Spring WG has already defined many behaviors with the applicable flavors. That does not mean RFC8986 defines multiple data planes! I strongly support the WG adoption call. Thanks, Rishabh Parekh On Fri, Oct 1, 2021 at 7:05 AM James Guichard < james.n.guichard@futurewei.com> wrote: > Dear WG: > > > > The chairs would like to express their appreciation for all the responses > received to our emails with reference to how the working group wishes to > move forward with respect to a solution for SRv6 compression. > > > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > as the basis for its compression standardization work. That is part of wh= at > this email attempts to confirm. > > > > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging > that: > > > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change = as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the working > group to publication. A list of these discussion points will be docume= nted > in the WG document and maintained by the document editor in conjunctio= n > with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text describin= g an > open issue be added to the document in the above-described open issues > section: > - "Given that the working group has said that it wants to > standardize one data plane solution, and given that the document co= ntains > multiple SRv6 EndPoint behaviors that some WG members have stated a= re > multiple data plane solutions, the working group will address wheth= er this > is valid and coherent with its one data plane solution objective.". > > > > Please consider the above guidelines as you decide on whether to support > or not this WG adoption. Please express clearly your reasoning for > support/non-support as well as any open discussion points you would like > addressed should the document be adopted into the working group. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --000000000000ecf6d505ce1dcd21 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    With regards to the chair's question, CSID is based on the single SRv6 based data plane. The addition o= f flavors for SRv6 compression does not mean the draft is defining multiple d= ata planes. This is because, if we go with that logic, RFC8986, which is a prod= uct of the Spring WG has already defined many behaviors with the applicable flavors. That does not mean RFC8986 defines multiple data planes!

    =C2=A0

    I strong= ly support the WG adoption call.

    Thanks,
    Rishabh Parekh

    = On Fri, Oct 1, 2021 at 7:05 AM James Guichard <james.n.guichard@futurewei.com> wrote:
    <= /div>

    Dear WG:

    =C2=A0

    The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

    =C2=A0

    The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

    =C2=A0

    Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

    =C2=A0

    1. The SPRING working group is adopting a document that has multiple = SRv6 Endpoint behaviors.
    2. The document is a =E2=80=9Cliving=E2=80=9D docu= ment; it may change as it goes through review and analysis by the SPRING wo= rking group.
    3. All open discussion points raised on our mailin= g list MUST be addressed BEFORE said document is allowed to progress from t= he working group to publication. A list of these discussion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
    4. If this document is adopted by the working grou= p, the chairs specify as part of the adoption call that the following text = describing an open issue be added to the document in the above-described open issues section:
      • "Given that the = working group has said that it wants to standardize one data plane solution= , and given that the document contains multiple SRv6 EndPoint behaviors tha= t some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

    =C2=A0

    Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

    =C2=A0

    Thanks!

    =C2=A0

    Jim, Bruno & Joel

    =C2=A0

    =C2=A0

    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --000000000000ecf6d505ce1dcd21-- From nobody Mon Oct 11 19:03:40 2021 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 10D303A0B10; Mon, 11 Oct 2021 19:03:37 -0700 (PDT) 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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3lVuUjL9S3m; Mon, 11 Oct 2021 19:03:31 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 901DC3A0D25; Mon, 11 Oct 2021 19:02:35 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id c4so12500905pls.6; Mon, 11 Oct 2021 19:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:subject:from:in-reply-to:cc :date:message-id:references:to; bh=Jw8w7feYfsnxuRkVw+vAheHAnKDhomaxK2BsfGvWpAc=; b=fFGUvizt6Or0rtelbyLuJjUmuf12RYiBB3nda8cmsGxd19U5wqFyMoRYrdDKT6qiJy Rt5u5q+2nSXb1JZ3bTzPBTpARpMVyDAwCCyWzK4VXr9jZkqYIY8duLE9ZFyXfDfrSJcM C731MQYAkJZB+WAkUcwwofV2fQ8KrqkqArlUKFDQF9Hd08Q3Ot4V6DFOivFAZn9vhCbV cdxsl/HQcG0HcN5pBLhSiPb9+NxeXCMfXt25Sh14bUCZKtPkEJDtkHmWbU2L1q3kM/6A +/XaXNP22lryPuHTkCeu1HbcU8d/yp9taKCgdRQsshVJXVFl7g+GC6gk1OjFDqH63Y6M Uhcw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:cc:date:message-id:references:to; bh=Jw8w7feYfsnxuRkVw+vAheHAnKDhomaxK2BsfGvWpAc=; b=WaqtPjre3uM7gsvYHqHz/MJ3/aOSZwgBjuZE5qXujZZWmY5zggOK0DkDbTzR1H1E9Q trMwfzMCmT+9hUtki60bg2yhxpP3g7J2rlflv+CC79bROq2M8GqDOhBC5u7PF9HhkI7O 7Dd1CvDuRx8qkuYHNz4hIRp0MRx0UYimYYepPMBIcxdfz3mzT6i0bVHQQs8pawE7cI09 ReEtTF5EaSyZ8HP5jfWyfqzPbcaqqDVzkKBOjvkT6YHByfUGFhqmq5H6eQCqBxBVNbvu eijG+uv19y8WAuMuzIK0OJF8BTfKhNCYt95Kk4UIFtlDo5ebDXVmy+nz1gR9PxJbAjWT 3tBw== X-Gm-Message-State: AOAM531qmcKSa3tqJGS7868MrQsJQ7osfudK+eYQPJTyaRbZjk/DkVz+ WSosorTT6XWXbCaA+guCic+iKh/tJ0Q= X-Google-Smtp-Source: ABdhPJxb/XAx05ddNzB1WT4HGu5+IOBGf+DE1+QCcdvRgHPPpx/7eWVx1MrfunMAhRGTm/QD4WgEsA== X-Received: by 2002:a17:90a:d24d:: with SMTP id o13mr2911251pjw.59.1634004154461; Mon, 11 Oct 2021 19:02:34 -0700 (PDT) Received: from smtpclient.apple (108-221-21-153.lightspeed.sntcca.sbcglobal.net. [108.221.21.153]) by smtp.gmail.com with ESMTPSA id u63sm2988051pfc.195.2021.10.11.19.02.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Oct 2021 19:02:33 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-82B3D083-92EF-49D1-B2B3-5D4D821DE982 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Gaurav Dawra In-Reply-To: Cc: "Zafar Ali (zali)" , James Guichard , SPRING WG , spring-chairs@ietf.org, "Zafar Ali (zali)" Date: Mon, 11 Oct 2021 19:02:32 -0700 Message-Id: References: To: Keyur Patel X-Mailer: iPhone Mail (18H17) Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 12 Oct 2021 02:03:37 -0000 --Apple-Mail-82B3D083-92EF-49D1-B2B3-5D4D821DE982 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear WG and Chairs, With multiple vendor implementations and interops. The draft is for SRv6 com= pression based on the single SRv6 data plane I strongly support its adoption Gaurav Linkedin > On Oct 10, 2021, at 10:48 PM, Keyur Patel wrote: > =EF=BB=BF > Dear WG and the WG Chairs, > =20 > Network programming model (RFC8986) defines multiple flavors for End, End.= X, and End.T SIDs. CSID draft builds on it with next and replace flavors for= these SIDs, optimized for 16 bit and 32 bit SID sizes, respectively. This i= s just like PSP, USP and USD flavors defined in RFC8986 to cover different d= eployment scenarios. > =20 > We at Arrcus have implemented CSID solution and also have participated in m= ultivendor interop for the solution. > =20 > I strongly support the adoption. > =20 > Best Regards, > Keyur > =20 > =20 > From: spring on behalf of "Zafar Ali (zali)" > Date: Monday, October 4, 2021 at 8:50 AM > To: James Guichard , SPRING WG > Cc: "Zafar Ali (zali)" , "spring-chairs@ietf.org" > Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/do= c/draft-filsfilscheng-spring-srv6-srh-compression/ > =20 > Dear WG and the chairs, > =20 > I strongly support the adoption call > =20 > About the matter in the email, the WG has defined a single data plane solu= tion, i.e., SRv6 (RFC8402, RFC8754, and RFC8986). > SRv6 as per the inherent nature of the network programming model (RFC8996)= already defines multiple standardized behaviors. > Clearly, CSID is a single solution based on the SRv6 data plane. > =20 > Thanks > =20 > Regards =E2=80=A6 Zafar=20 > =20 > =20 > From: spring on behalf of James Guichard > Date: Friday, October 1, 2021 at 10:05 AM > To: SPRING WG > Cc: "spring-chairs@ietf.org" > Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dr= aft-filsfilscheng-spring-srv6-srh-compression/ > =20 > Dear WG: > =20 > The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to move= forward with respect to a solution for SRv6 compression. > =20 > The apparent inclination of the working group is to use https://datatracke= r.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email a= ttempts to confirm. > =20 > Because of the above the chairs would like to issue a 2-week WG call for a= doption ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as foll= ows. By expressing support for adoption of this document you are fully aware= of and are acknowledging that: > =20 > 1. The SPRING working group is adopting a document that has multiple= SRv6 Endpoint behaviors. > 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may chang= e as it goes through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be add= ressed BEFORE said document is allowed to progress from the working group to= publication. A list of these discussion points will be documented in the WG= document and maintained by the document editor in conjunction with the chai= rs. > 4. If this document is adopted by the working group, the chairs spec= ify as part of the adoption call that the following text describing an open i= ssue be added to the document in the above-described open issues section: > =C2=B7 "Given that the working group has said that it wants to sta= ndardize one data plane solution, and given that the document contains multi= ple SRv6 EndPoint behaviors that some WG members have stated are multiple da= ta plane solutions, the working group will address whether this is valid and= coherent with its one data plane solution objective.". > =20 > Please consider the above guidelines as you decide on whether to support o= r not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sho= uld the document be adopted into the working group. > =20 > Thanks! > =20 > Jim, Bruno & Joel > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --Apple-Mail-82B3D083-92EF-49D1-B2B3-5D4D821DE982 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
    Dear WG and Chairs,

    <= /div>
    With multiple vendor implementations and interops. The draft is fo= r SRv6 compression based on the single SRv6 data plane


    I strongly support its= adoption


    Gaurav
    Linkedin

    On Oct 10, 2021, at 10:48 PM, Keyur Patel= <keyur@arrcus.com> wrote:

    =EF=BB=BF

    Dear WG and the WG Chairs,

     

    Network programming model= (RFC8986) defines multiple flavors for End, End.X, and End.T SIDs. CSID dra= ft builds on it with next and replace flavors for these SIDs, optimized for 1= 6 bit and 32 bit SID sizes, respectively. This is just like PSP, USP and USD flavors defined in RFC8986 to cover diff= erent deployment scenarios.

     <= /p>

    We at Arrcus have impleme= nted CSID solution and also have participated in multivendor interop for the= solution.

     

    I strongly support the ad= option.

     <= /p>

    Best Regards,<= /span>

    Keyur

     

     

    From:= spring <spring-b= ounces@ietf.org> on behalf of "Zafar Ali (zali)" <zali=3D40cisco.com@d= marc.ietf.org>
    Date: Monday, October 4, 2021 at 8:50 AM
    To: James Guichard <james.n.guichard@futurewei.com>, SPRING WG &= lt;spring@ietf.org>
    Cc: "Zafar Ali (zali)" <zali@cisco.com>, "spring-chairs@ietf.or= g" <spring-chairs@ietf.org>
    Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.o= rg/doc/draft-filsfilscheng-spring-srv6-srh-compression/

     

    Dear WG and the chairs,

     

    I strongly support the adoption call

     

    About the matter in the email, the WG has defined a s= ingle data plane solution, i.e., SRv6 (RFC8402, RFC8754, and RFC8986).

    SRv6 as per the inherent nature of the network progra= mming model (RFC8996) already defines multiple standardized behaviors.

    Clearly, CSID is a single solution based on the SRv6 d= ata plane.

     

    Thanks

     

    Regards =E2=80=A6 Zafar 

     

     

    From: spring <spring-bo= unces@ietf.org> on behalf of James Guichard <james.n.guichard@futurewe= i.com>
    Date: Friday, October 1, 2021 at 10:05 AM
    To: SPRING WG <spring@ietf.org>
    Cc: "spring-chairs@ietf.org" <spring-chairs@ietf.org>
    Subject: [spring] WG Adoption call for https://datatracker.ietf.org/d= oc/draft-filsfilscheng-spring-srv6-srh-compression/

     

    Dear WG:

     

    The chairs would like to e= xpress their appreciation for all the responses received to our emails with r= eference to how the working group wishes to move forward with respect to a s= olution for SRv6 compression.

     

    The apparent inclination o= f the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compres= sion/ as the basis for its compression standardization work. That is par= t of what this email attempts to confirm.

     

    Because of the above the c= hairs would like to issue a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compres= sion/ but with some clear guidelines as follows. By expressing support f= or adoption of this document you are fully aware of and are acknowledging th= at:

     

    1.       The SPRING working group is adopting a document t= hat has multiple SRv6 Endpoint behaviors.

    2.       The document is a =E2=80=9Cliving=E2=80=9D docum= ent; it may change as it goes through review and analysis by the SPRING work= ing group.

    3.       All open discussion points raised on our mailing= list MUST be addressed BEFORE said document is allowed to progress from the= working group to publication. A list of these discussion points will be doc= umented in the WG document and maintained by the document editor in conjunction with the chairs.

    4.       If this document is adopted by the working group= , the chairs specify as part of the adoption call that the following text de= scribing an open issue be added to the document in the above-described open i= ssues section:

    =C2=B7         "Given that the working group has said th= at it wants to standardize one data plane solution, and given that the docum= ent contains multiple SRv6 EndPoint behaviors that some WG members have stat= ed are multiple data plane solutions, the working group will address whether this is valid and coherent with its o= ne data plane solution objective.".

     

    Please consider the above g= uidelines as you decide on whether to support or not this WG adoption. Pleas= e express clearly your reasoning for support/non-support as well as any open= discussion points you would like addressed should the document be adopted into the working group.=

     

    Thanks!

     

    Jim, Bruno & Joel=

     

     

    _______________________________________________
    spring= mailing list
    spring@ietf.org
    https://www.ie= tf.org/mailman/listinfo/spring
    = --Apple-Mail-82B3D083-92EF-49D1-B2B3-5D4D821DE982-- From haitao.kang@intel.com Mon Oct 11 19:08:07 2021 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 4C4D13A0B4C; Mon, 11 Oct 2021 19:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=intel.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 FXr4EOMHo0q9; Mon, 11 Oct 2021 19:08:00 -0700 (PDT) Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) (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 978EB3A0B52; Mon, 11 Oct 2021 19:07:58 -0700 (PDT) X-IronPort-AV: E=McAfee;i="6200,9189,10134"; a="227303554" X-IronPort-AV: E=Sophos;i="5.85,366,1624345200"; d="scan'208,217";a="227303554" Received: from orsmga001.jf.intel.com ([10.7.209.18]) by fmsmga103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 11 Oct 2021 19:07:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,366,1624345200"; d="scan'208,217";a="524037144" Received: from fmsmsx602.amr.corp.intel.com ([10.18.126.82]) by orsmga001.jf.intel.com with ESMTP; 11 Oct 2021 19:07:54 -0700 Received: from fmsmsx604.amr.corp.intel.com (10.18.126.84) by fmsmsx602.amr.corp.intel.com (10.18.126.82) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Mon, 11 Oct 2021 19:07:53 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx604.amr.corp.intel.com (10.18.126.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Mon, 11 Oct 2021 19:07:53 -0700 Received: from NAM02-DM3-obe.outbound.protection.outlook.com (104.47.56.49) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Mon, 11 Oct 2021 19:07:53 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gdAYmgzV+/ZTAMtRGqZwIg6XxLvoJUNzbEW5YOIZaxh0SKXML+Q3Y7FmxH03BA0Tl9sG56pqUukpC7A6lUHHmj81UFgvDfUmBmv8zs2RVUM5WP4zHUAiuS9BseS4HfstkwqNeav4Tyw/h4DbzkLyovMixXRu89VPH+w73jRc6XbaEdZN36VqmBgpS9qUpCRz0XSaU/GnXx13/xKI5FY4Rj3Wz/E5aKGiCOmiaaASAm2uSVHYV9+Bov2oZxC83rnbGszFS9OliaUAZCj/HdLSmweQpkaQu0DpGcp+mP6VEYn9NBNCZduSkXsXnnMeAasKuthMMvvz2zmE2CG2bjN5rQ== 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=KUt3ECBXRH+sZBHOs/9AhLiygwvUOf9yxjjpYZsFi2U=; b=Wm90Rb51xmn9d79sezHzFSbR0FSEZWVP64Ub6Xo8s+pHCdPMWAo4OTNtqtcq18Nq6N6q1FnNwacMGk0uVIh6dN1zMASihloC49jlwcUwR+2WiFcxQj3tBEYt4qRkNfAdW5BiQK41Ht+b4izn1KMmglohPprzdh4/xpcZjuFK25HJhrYnbElq6Ihw8WDrMe0o+mMgkUzkgwHaoIYpuMAkPdoy/JOU3Y0FglYJgDeX77pPL8ulO+6Gk23G8mgm7vig1NRMJ07bD8jEIVC7k/dYFUqHJcz/q53Zh3YBNtNeJ94VD2bplz8EKdmJSNgF+KYcYHSCzWne8wkp//NRjDugvA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KUt3ECBXRH+sZBHOs/9AhLiygwvUOf9yxjjpYZsFi2U=; b=YyHDQp6uBvAgROBbS7lfEhMmlrdta/DcywBaQ1ago4EIS40JN+SNtQGxhpPQHeOuAhMIjV7SSGC9MQUnC/bwoTm+fcuLyz3VP9m7H6pme8wOQbvmBdaAevwCAv/qhvzyL4pjd0WRA/C8NDCmigt7j99EfRsgFWBl18VRHJKPXus= Received: from BL0PR11MB3458.namprd11.prod.outlook.com (2603:10b6:208:6a::20) by BL0PR11MB3426.namprd11.prod.outlook.com (2603:10b6:208:32::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.25; Tue, 12 Oct 2021 02:07:47 +0000 Received: from BL0PR11MB3458.namprd11.prod.outlook.com ([fe80::e47b:aafa:e41d:f78a]) by BL0PR11MB3458.namprd11.prod.outlook.com ([fe80::e47b:aafa:e41d:f78a%2]) with mapi id 15.20.4587.026; Tue, 12 Oct 2021 02:07:47 +0000 From: "Kang, Haitao" To: SPRING WG , "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: AQHXvwj4qoAGsNQLMUOuKHvL3ZM0mavOnBbQ Date: Tue, 12 Oct 2021 02:07:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-reaction: no-action dlp-version: 11.6.200.16 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5fa90585-ddd6-48c0-3f63-08d98d251607 x-ms-traffictypediagnostic: BL0PR11MB3426: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lCkRRMOZs1KN4wZs4MlD7wjtxmaJ5yXvausq0bzboGo4e0BibzNrG6lA/PkpixdeMEP6VhVzNSEQiZF/tXuDcNPskzzKu5Iu6eaTBIPWp+ahPlg78a21Wooqunh6AsU3tYORLRcR7Wn/GzsuamOyjhUNQQ7CLg3aL99yxTuYGnO4KboTrRVWtNTYz8NHAa62v2jjQVPE6FAJy36SjQw8LgBehPEYXLWzHv1pIu/vGYWsLeMISK2sZ/qzNE8XAQf2nE8Nm0jroXEan886orDxx250wLTZ5cvqIFAbiLR+s0bCFo3m4Rz/1gZfFW0AjUt1+iNSIlyL0rinhtSbSADpd0eDMEnLfTJ8yN1mjtabZ922grsiPFcw3JzFYd3/43gQC+6Hl2t/1Ok8Tlh1qVS/M30Vi8mmYAqfPJJqae39kVV4fBrqMLcpDzEAfbZ9zlFWBZyPa6K8bMig5+M7Me4GMMsH13LP03Q6yhjb+4DaeVwm4JfL87bhtJODGPpijW2HYhyapmpDbBjjQN3L4rBUG02WogPARbRFUT4FyDpkkVMyN4QAiyAVoMXFP0bqKYNGGUNKLzfDg8NcbQHzA+/xmK0Qkxf3LMD14TOz5nyRDi9vPhJ03Q/WdNHEGd94PjmTrAComzz9CLlxjo71aUASPIOPhUI4aZV9xUJY7GBGHX8NIcNFEGJ2LKR6qDrjIW8aXrzdp0BhLSldjUyLNnb+pe+bQT7ROA8LY3lVtCJKzKmDqvo99UVl8NW+v8uhTLO/yoxSBKBShPZVWHexcXXNatCTPXecJ8wSPLgKeb4aBIHywxSMhixDebXY/sizL52H x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR11MB3458.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66946007)(52536014)(8936002)(38070700005)(508600001)(8676002)(55016002)(71200400001)(53546011)(6506007)(33656002)(122000001)(2906002)(7696005)(966005)(5660300002)(66446008)(64756008)(76116006)(9686003)(450100002)(316002)(66556008)(38100700002)(66476007)(166002)(83380400001)(186003)(110136005)(26005)(86362001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?TWNzcnVvS3FyaFR1YktyeUFrdHJnazJqU1pnY1hHanowand4cFp5ZlhlczRM?= =?utf-8?B?NkVYZXR6NFhOQlQwZXJieUlFdDg5dXhmRWZOYzVVRUJWOHgya0s0R2gwUndD?= =?utf-8?B?bDZjNU10TFF1ZE5GS0ZYMkxFdStLZ1VHUGplOEZpNDVRRitBLzg4S2Q5R0t5?= =?utf-8?B?RDNZTkVjeGlmU2RhaGF1QWNyOFFUTVM1Q3c0Rk5mQ2JkM3dEM3lreVJUeTg0?= =?utf-8?B?djVrb09Gb29iMjR2dTVObHFmdmgwbmlrRmFHNk4wdFVXbG9wOStkd0tEMDJp?= =?utf-8?B?MVpqdzNjREpNVm13ZWJ6ek9Va0VMUHJQY1FBRVc4V1R6cTN1Q3craTk3dnJH?= =?utf-8?B?UUxwNXNScUZ5M1V1bFZ1VDVla09TdUVScTBHV1lvN3ljUXJIZjByRE1saFZQ?= =?utf-8?B?YmpUWmZENkZoMTFBWWFSU3c3WTdHT1hRR2EyVlVHVklqaDVBQUdwdGtoQWxn?= =?utf-8?B?Q2QrcUtPMnBUbTNSWEpiTW15V3BWcFI2K0NZUnlZL3ZCWGlKS0c1TjV4YW1G?= =?utf-8?B?YWg3Mnc5ZlZCYStrV0I1OTdyS1ZwYlFZd0IyeDQ4enVuUWxtK2dpQVVxYXIz?= =?utf-8?B?NjI1UndCc1Y0Q2RPRTd0RDhjQ1BnTHp3c1JtZjRXSzBxaUw4TFBYZGtpdUs5?= =?utf-8?B?MjBkWHNBcHZZZklkeUdHR2lpLzhwd1pMbWF2emFaTXFRc0hSSm1BTGIzQ0JV?= =?utf-8?B?WjI4bW5RWWFXdTJ2NFlOaEpBRXRRbnFOdVhmMFNNWTUyazJZcmlYUWd4WFcw?= =?utf-8?B?V2I3aGh0RWlhcFlsWDRqcjFlS3VTNXg1SjNTRUpQM0M0cnNnK3lWOG9Id1A4?= =?utf-8?B?ak4waW1RNDFBU1d2cktaSDdYeGdXOUlydkZmOVpJdEJjRkhHMENMZjFienRO?= =?utf-8?B?VzB5SGg1aFY3TllwK25WLzRCVTdTaEJ5dzJkZlNmTzdWanluZUFkWHhtQlRw?= =?utf-8?B?eUhNbTBFQkE4U3M5ZmdDZ29UcE5XN1Iwc2pYb0JHUnR1UDBZT1FkNHlJdGp4?= =?utf-8?B?Vm5wYjZ0bzQrSnNNdGVIeStJbGxQRlBPRGlZU2V5T2pDajc4cFloYjF6b1Jw?= =?utf-8?B?UnJ4QSszT3lsNzFVYTlIVzJVNlJTSXVJallrYzhUOUx0Y2ZZWk5mdjYxYU5J?= =?utf-8?B?R2pDMEpGYldFMDFMZVVDNklZRVQrRCt3S2U2MjRXak9GaXFQY25rTGV0TGJt?= =?utf-8?B?cmd3M1RiY1dUMnAvNTFVMWJWM2s5STVoZ3FlWFJXWnZrRy9DbXpnSndiR3NK?= =?utf-8?B?bmk3MGJEMzZFK2lHL0tZcUhxWjBZZ2hVOVpqWDdWVmxwdTU2aWZnc3VHMmlZ?= =?utf-8?B?L1d0R3ZlTnJBUWpnQXlVL0ZtTlJFM1ZnQUZ4em5kNTNyVmhUbURGMkFKK3l1?= =?utf-8?B?S3hUM1k4UENtL3NqQ3BJWkZPWlAyVU5wcXE5SVlLSCsxL2cwbjJJQzJmQnZW?= =?utf-8?B?blI2TEpvamZqNWFGaWlZejRDTkgxQXpZd1dMbHJpd3pIYmlMNUR0U3pJN1BJ?= =?utf-8?B?NmNmREJhKy9uUEhPcUhweTRIRW9pZUhTMG1Sd0NxZWlsWWJsRmk2OWVidjFQ?= =?utf-8?B?MWFKMlJGUEVxOTA4T20ybUFSN2Zldmg4b0FtNUViY21DQzBDY01RY2tBTGty?= =?utf-8?B?WkpieGhEZndEVzcxOGtUY2RFS2hIRmRYNjZpdmh2Tm1XNXYxRUVOcDhmOW81?= =?utf-8?B?RHpDYk5hbHRCQ2o3ZUEvY2VvdHd1VlRDc21ERDBIR2szZlhJbzg1b2JoUzNj?= =?utf-8?Q?0H+IInQ1xuAS9U86IrJn0uFxfwpR4AuOLIY6v2X?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR11MB3458F5D663A6D76EAB431479F8B69BL0PR11MB3458namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR11MB3458.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5fa90585-ddd6-48c0-3f63-08d98d251607 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2021 02:07:47.1386 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Drl+BlSIQ/kKM66fefm44qMBVvRdRLkb24U6qO4yh65Y+y/d0xfCsBZYibMeS962BX+hrXmPYQVXeBHKon3Rpw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR11MB3426 X-OriginatorOrg: intel.com Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 12 Oct 2021 02:14:59 -0000 --_000_BL0PR11MB3458F5D663A6D76EAB431479F8B69BL0PR11MB3458namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiBDU0lEIGRyYWZ0Lg0KQ1NJRCBkcmFmdCBkZWZpbmVz IG5leHQgYW5kIHJlcGxhY2UgYmVoYXZpb3JzIHRoYXQgYXJlIGNvbnNpc3RlbnQgd2l0aCB0aGUg U1J2NiBuZXR3b3JrIHByb2dyYW1taW5nIFJGQzg5OTYuDQpXZSd2ZSB2ZXJpZmllZCB0aGUgc29s dXRpb24gd2l0aCBwYXJ0bmVycyBpbiBJbnRlbCBUb2Zpbm8gcHJvZ3JhbW1hYmxlIHN3aXRjaCBj aGlwc2V0Lg0KDQpSZWdhcmRzLA0KSGFpdGFvDQoNCk9uIEZyaSwgT2N0IDEsIDIwMjEgYXQgNzow NSBBTSBKYW1lcyBHdWljaGFyZCA8amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPG1haWx0 bzpqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20+PiB3cm90ZToNCkRlYXIgV0c6DQoNClRo ZSBjaGFpcnMgd291bGQgbGlrZSB0byBleHByZXNzIHRoZWlyIGFwcHJlY2lhdGlvbiBmb3IgYWxs IHRoZSByZXNwb25zZXMgcmVjZWl2ZWQgdG8gb3VyIGVtYWlscyB3aXRoIHJlZmVyZW5jZSB0byBo b3cgdGhlIHdvcmtpbmcgZ3JvdXAgd2lzaGVzIHRvIG1vdmUgZm9yd2FyZCB3aXRoIHJlc3BlY3Qg dG8gYSBzb2x1dGlvbiBmb3IgU1J2NiBjb21wcmVzc2lvbi4NCg0KVGhlIGFwcGFyZW50IGluY2xp bmF0aW9uIG9mIHRoZSB3b3JraW5nIGdyb3VwIGlzIHRvIHVzZSBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVz c2lvbi8gYXMgdGhlIGJhc2lzIGZvciBpdHMgY29tcHJlc3Npb24gc3RhbmRhcmRpemF0aW9uIHdv cmsuIFRoYXQgaXMgcGFydCBvZiB3aGF0IHRoaXMgZW1haWwgYXR0ZW1wdHMgdG8gY29uZmlybS4N Cg0KQmVjYXVzZSBvZiB0aGUgYWJvdmUgdGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGlzc3VlIGEg Mi13ZWVrIFdHIGNhbGwgZm9yIGFkb3B0aW9uIGVuZGluZyBPY3RvYmVyIDE1dGggZm9yIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNy djYtc3JoLWNvbXByZXNzaW9uLyBidXQgd2l0aCBzb21lIGNsZWFyIGd1aWRlbGluZXMgYXMgZm9s bG93cy4gQnkgZXhwcmVzc2luZyBzdXBwb3J0IGZvciBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50 IHlvdSBhcmUgZnVsbHkgYXdhcmUgb2YgYW5kIGFyZSBhY2tub3dsZWRnaW5nIHRoYXQ6DQoNCg0K ICAxLiAgVGhlIFNQUklORyB3b3JraW5nIGdyb3VwIGlzIGFkb3B0aW5nIGEgZG9jdW1lbnQgdGhh dCBoYXMgbXVsdGlwbGUgU1J2NiBFbmRwb2ludCBiZWhhdmlvcnMuDQogIDIuICBUaGUgZG9jdW1l bnQgaXMgYSDigJxsaXZpbmfigJ0gZG9jdW1lbnQ7IGl0IG1heSBjaGFuZ2UgYXMgaXQgZ29lcyB0 aHJvdWdoIHJldmlldyBhbmQgYW5hbHlzaXMgYnkgdGhlIFNQUklORyB3b3JraW5nIGdyb3VwLg0K ICAzLiAgQWxsIG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgcmFpc2VkIG9uIG91ciBtYWlsaW5nIGxp c3QgTVVTVCBiZSBhZGRyZXNzZWQgQkVGT1JFIHNhaWQgZG9jdW1lbnQgaXMgYWxsb3dlZCB0byBw cm9ncmVzcyBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIHRvIHB1YmxpY2F0aW9uLiBBIGxpc3Qgb2Yg dGhlc2UgZGlzY3Vzc2lvbiBwb2ludHMgd2lsbCBiZSBkb2N1bWVudGVkIGluIHRoZSBXRyBkb2N1 bWVudCBhbmQgbWFpbnRhaW5lZCBieSB0aGUgZG9jdW1lbnQgZWRpdG9yIGluIGNvbmp1bmN0aW9u IHdpdGggdGhlIGNoYWlycy4NCiAgNC4gIElmIHRoaXMgZG9jdW1lbnQgaXMgYWRvcHRlZCBieSB0 aGUgd29ya2luZyBncm91cCwgdGhlIGNoYWlycyBzcGVjaWZ5IGFzIHBhcnQgb2YgdGhlIGFkb3B0 aW9uIGNhbGwgdGhhdCB0aGUgZm9sbG93aW5nIHRleHQgZGVzY3JpYmluZyBhbiBvcGVuIGlzc3Vl IGJlIGFkZGVkIHRvIHRoZSBkb2N1bWVudCBpbiB0aGUgYWJvdmUtZGVzY3JpYmVkIG9wZW4gaXNz dWVzIHNlY3Rpb246DQoNCiAgICAgKiAgICJHaXZlbiB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGhh cyBzYWlkIHRoYXQgaXQgd2FudHMgdG8gc3RhbmRhcmRpemUgb25lIGRhdGEgcGxhbmUgc29sdXRp b24sIGFuZCBnaXZlbiB0aGF0IHRoZSBkb2N1bWVudCBjb250YWlucyBtdWx0aXBsZSBTUnY2IEVu ZFBvaW50IGJlaGF2aW9ycyB0aGF0IHNvbWUgV0cgbWVtYmVycyBoYXZlIHN0YXRlZCBhcmUgbXVs dGlwbGUgZGF0YSBwbGFuZSBzb2x1dGlvbnMsIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYWRkcmVz cyB3aGV0aGVyIHRoaXMgaXMgdmFsaWQgYW5kIGNvaGVyZW50IHdpdGggaXRzIG9uZSBkYXRhIHBs YW5lIHNvbHV0aW9uIG9iamVjdGl2ZS4iLg0KDQpQbGVhc2UgY29uc2lkZXIgdGhlIGFib3ZlIGd1 aWRlbGluZXMgYXMgeW91IGRlY2lkZSBvbiB3aGV0aGVyIHRvIHN1cHBvcnQgb3Igbm90IHRoaXMg V0cgYWRvcHRpb24uIFBsZWFzZSBleHByZXNzIGNsZWFybHkgeW91ciByZWFzb25pbmcgZm9yIHN1 cHBvcnQvbm9uLXN1cHBvcnQgYXMgd2VsbCBhcyBhbnkgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyB5 b3Ugd291bGQgbGlrZSBhZGRyZXNzZWQgc2hvdWxkIHRoZSBkb2N1bWVudCBiZSBhZG9wdGVkIGlu dG8gdGhlIHdvcmtpbmcgZ3JvdXAuDQoNClRoYW5rcyENCg0KSmltLCBCcnVubyAmIEpvZWwNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5n IG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0K --_000_BL0PR11MB3458F5D663A6D76EAB431479F8B69BL0PR11MB3458namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLmdtYWlsLW0xMDIy MTE0NzMzMTU3MjY2OTc1bXNvbGlzdHBhcmFncmFwaCwgbGkuZ21haWwtbTEwMjIxMTQ3MzMxNTcy NjY5NzVtc29saXN0cGFyYWdyYXBoLCBkaXYuZ21haWwtbTEwMjIxMTQ3MzMxNTcyNjY5NzVtc29s aXN0cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fMTAyMjExNDczMzE1NzI2Njk3 NW1zb2xpc3RwYXJhZ3JhcGg7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpwLmdtYWlsLW0xMDIyMTE0NzMzMTU3MjY2OTc1bXNvcGxhaW50ZXh0LCBsaS5nbWFpbC1tMTAy MjExNDczMzE1NzI2Njk3NW1zb3BsYWludGV4dCwgZGl2LmdtYWlsLW0xMDIyMTE0NzMzMTU3MjY2 OTc1bXNvcGxhaW50ZXh0DQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLW1fMTAyMjExNDczMzE1NzI2 Njk3NW1zb3BsYWludGV4dDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0 IGwwDQoJe21zby1saXN0LWlkOjkyMjExMDg5NDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTE3 NTQ3MDkxNDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXtt YXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9Indv cmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIENTSUQgZHJhZnQuIDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q1NJRCBkcmFmdCBkZWZpbmVzIG5leHQg YW5kIHJlcGxhY2UgYmVoYXZpb3JzIHRoYXQgYXJlIGNvbnNpc3RlbnQgd2l0aCB0aGUgU1J2NiBu ZXR3b3JrIHByb2dyYW1taW5nIFJGQzg5OTYuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPldlJ3ZlIHZlcmlmaWVkIHRoZSBzb2x1dGlvbiB3aXRoIHBhcnRuZXJzIGluIElu dGVsIFRvZmlubyBwcm9ncmFtbWFibGUgc3dpdGNoIGNoaXBzZXQuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IYWl0 YW88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBGcmksIE9jdCAxLCAy MDIxIGF0IDc6MDUgQU0gSmFtZXMgR3VpY2hhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpqYW1lcy5u Lmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20iPmphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkRlYXIgV0c6PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5UaGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gZXhwcmVzcyB0aGVpciBhcHByZWNp YXRpb24gZm9yIGFsbCB0aGUgcmVzcG9uc2VzIHJlY2VpdmVkIHRvIG91ciBlbWFpbHMgd2l0aCBy ZWZlcmVuY2UgdG8gaG93IHRoZSB3b3JraW5nIGdyb3VwIHdpc2hlcyB0byBtb3ZlIGZvcndhcmQg d2l0aCByZXNwZWN0IHRvIGENCiBzb2x1dGlvbiBmb3IgU1J2NiBjb21wcmVzc2lvbi4gPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgYXBwYXJlbnQgaW5jbGluYXRpb24gb2YgdGhlIHdv cmtpbmcgZ3JvdXAgaXMgdG8gdXNlDQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8i IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLzwvYT4gYXMgdGhlIGJh c2lzIGZvciBpdHMgY29tcHJlc3Npb24gc3RhbmRhcmRpemF0aW9uIHdvcmsuIFRoYXQgaXMgcGFy dCBvZiB3aGF0IHRoaXMgZW1haWwgYXR0ZW1wdHMgdG8gY29uZmlybS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkJlY2F1c2Ugb2YgdGhlIGFib3ZlIHRoZSBjaGFpcnMgd291bGQgbGlrZSB0 byBpc3N1ZSBhIDItd2VlayBXRyBjYWxsIGZvciBhZG9wdGlvbiBlbmRpbmcgT2N0b2JlciAxNTxz dXA+dGg8L3N1cD4gZm9yDQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8iIHRhcmdl dD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNm aWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLzwvYT4gYnV0IHdpdGggc29tZSBj bGVhciBndWlkZWxpbmVzIGFzIGZvbGxvd3MuIEJ5IGV4cHJlc3Npbmcgc3VwcG9ydCBmb3IgYWRv cHRpb24gb2YgdGhpcyBkb2N1bWVudCB5b3UgYXJlIGZ1bGx5IGF3YXJlIG9mIGFuZCBhcmUgYWNr bm93bGVkZ2luZyB0aGF0Og0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4NCjxsaSBjbGFz cz0iZ21haWwtbTEwMjIxMTQ3MzMxNTcyNjY5NzVtc29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibXNv LWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KVGhlIFNQUklORyB3b3JraW5nIGdyb3VwIGlzIGFkb3B0 aW5nIGEgZG9jdW1lbnQgdGhhdCBoYXMgbXVsdGlwbGUgU1J2NiBFbmRwb2ludCBiZWhhdmlvcnMu DQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJnbWFpbC1tMTAyMjExNDczMzE1NzI2Njk3NW1z b2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpUaGUgZG9j dW1lbnQgaXMgYSDigJxsaXZpbmfigJ0gZG9jdW1lbnQ7IGl0IG1heSBjaGFuZ2UgYXMgaXQgZ29l cyB0aHJvdWdoIHJldmlldyBhbmQgYW5hbHlzaXMgYnkgdGhlIFNQUklORyB3b3JraW5nIGdyb3Vw Lg0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iZ21haWwtbTEwMjIxMTQ3MzMxNTcyNjY5NzVt c29saXN0cGFyYWdyYXBoIiBzdHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KQWxsIG9w ZW4gZGlzY3Vzc2lvbiBwb2ludHMgcmFpc2VkIG9uIG91ciBtYWlsaW5nIGxpc3QgTVVTVCBiZSBh ZGRyZXNzZWQgQkVGT1JFIHNhaWQgZG9jdW1lbnQgaXMgYWxsb3dlZCB0byBwcm9ncmVzcyBmcm9t IHRoZSB3b3JraW5nIGdyb3VwIHRvIHB1YmxpY2F0aW9uLiBBIGxpc3Qgb2YgdGhlc2UgZGlzY3Vz c2lvbiBwb2ludHMgd2lsbCBiZSBkb2N1bWVudGVkIGluIHRoZSBXRyBkb2N1bWVudCBhbmQgbWFp bnRhaW5lZCBieSB0aGUgZG9jdW1lbnQNCiBlZGl0b3IgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUg Y2hhaXJzLiA8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJnbWFpbC1tMTAyMjExNDczMzE1NzI2 Njk3NW1zb2xpc3RwYXJhZ3JhcGgiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQpJ ZiB0aGlzIGRvY3VtZW50IGlzIGFkb3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAsIHRoZSBjaGFp cnMgc3BlY2lmeSBhcyBwYXJ0IG9mIHRoZSBhZG9wdGlvbiBjYWxsIHRoYXQgdGhlIGZvbGxvd2lu ZyB0ZXh0IGRlc2NyaWJpbmcgYW4gb3BlbiBpc3N1ZSBiZSBhZGRlZCB0byB0aGUgZG9jdW1lbnQg aW4gdGhlIGFib3ZlLWRlc2NyaWJlZCBvcGVuIGlzc3VlcyBzZWN0aW9uOjxvOnA+PC9vOnA+PC9s aT48L29sPg0KPG9sIHN0YXJ0PSI0IiB0eXBlPSIxIj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBj bGFzcz0iZ21haWwtbTEwMjIxMTQ3MzMxNTcyNjY5NzVtc29wbGFpbnRleHQiIHN0eWxlPSJtc28t bGlzdDpsMCBsZXZlbDIgbGZvMSI+DQomcXVvdDtHaXZlbiB0aGF0IHRoZSB3b3JraW5nIGdyb3Vw IGhhcyBzYWlkIHRoYXQgaXQgd2FudHMgdG8gc3RhbmRhcmRpemUgb25lIGRhdGEgcGxhbmUgc29s dXRpb24sIGFuZCBnaXZlbiB0aGF0IHRoZSBkb2N1bWVudCBjb250YWlucyBtdWx0aXBsZSBTUnY2 IEVuZFBvaW50IGJlaGF2aW9ycyB0aGF0IHNvbWUgV0cgbWVtYmVycyBoYXZlIHN0YXRlZCBhcmUg bXVsdGlwbGUgZGF0YSBwbGFuZSBzb2x1dGlvbnMsIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYWRk cmVzcw0KIHdoZXRoZXIgdGhpcyBpcyB2YWxpZCBhbmQgY29oZXJlbnQgd2l0aCBpdHMgb25lIGRh dGEgcGxhbmUgc29sdXRpb24gb2JqZWN0aXZlLiZxdW90Oy48bzpwPjwvbzpwPjwvbGk+PC91bD4N Cjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5QbGVhc2UgY29uc2lkZXIgdGhlIGFib3ZlIGd1aWRlbGluZXMg YXMgeW91IGRlY2lkZSBvbiB3aGV0aGVyIHRvIHN1cHBvcnQgb3Igbm90IHRoaXMgV0cgYWRvcHRp b24uIFBsZWFzZSBleHByZXNzIGNsZWFybHkgeW91ciByZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9u LXN1cHBvcnQgYXMgd2VsbCBhcyBhbnkgb3Blbg0KIGRpc2N1c3Npb24gcG9pbnRzIHlvdSB3b3Vs ZCBsaWtlIGFkZHJlc3NlZCBzaG91bGQgdGhlIGRvY3VtZW50IGJlIGFkb3B0ZWQgaW50byB0aGUg d29ya2luZyBncm91cC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoYW5rcyE8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkppbSwgQnJ1bm8gJmFtcDsgSm9lbDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNw cmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZyIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5n PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_BL0PR11MB3458F5D663A6D76EAB431479F8B69BL0PR11MB3458namp_-- From nobody Mon Oct 11 20:04:53 2021 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 1ACB83A0AEE; Mon, 11 Oct 2021 20:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 LrPLtj4CLabe; Mon, 11 Oct 2021 20:04:46 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (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 B30923A0AC4; Mon, 11 Oct 2021 20:04:46 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id q129so6489191oib.0; Mon, 11 Oct 2021 20:04:46 -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=/bLtvqMyjtN9ADfXw8XxxGBklgEHhLht/k5YNHSaJGs=; b=AG7AqHbWPvusFp2UyAjpQmIoNn/mACoGhRbkakjVsQjY/0RZ+qerL0v8HWjKGu8Je3 8uyF441QdTgVCMuhTGhVmaQpgphBVmw93JH3+eOVgBFZBHeUmwOQHeYYcBQfI/ZVLDbp ayQEjrL21LWZ7AOD0xcckxH9QPg2RDaCjc5nsO0fZzpLqTEsOum+W4qE7Yu9a3psYJU8 qhqnezjUuCNO75PsEq38jeAmNif+CieaeaGzBviOtASYAyQ26yxalhRcWxJ6ZmYsXVue ySa6zQObb0y87dUEjBT1yBX0axUHs5hAUcuxA4hhnut7COSP4gRJ+HsSGTSdQU4igJBd w6mg== 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=/bLtvqMyjtN9ADfXw8XxxGBklgEHhLht/k5YNHSaJGs=; b=BSH9mZOHb/ShOYHhb08zwCax7mf/8Yq+UO4roXz6O0jPS8NtlFUsVDjSn12wSvXtPQ Mpqj8tFhBkbTTR6cS1F8M+KuR4Fc19/f212C8s+9WFOkbeXCATI5UxewTCkyljMYhhMv 1at5vpvDzJj8mS+GhcwfTkJSaqyBTyoci0WePx13alyk9jhdae+PkWtfVQI/0I8oDcqo Y9m9Jinp5EY5BeR1yhgkNhufiGw2KDBN1Wspb7EHCHSh/Un5cGX2R/jutqsn4jFm4Z+r Rwim72snEdNlz9zup6JNWqNMVdTiJxNT2l/prp5a0fsMzyTOWSGYKPj9eiKWCbWPHdNs PtPQ== X-Gm-Message-State: AOAM533tkBPmRte/cYz0PDelLv3rl9OCrNfUtEPbLx7PKysrhxogxvEi D5HzORfUG6SS77TLTiJdRZlnpTMbuVcJgZ2FfYw= X-Google-Smtp-Source: ABdhPJwHK0nAJPr8TbyZOcPD6pV5M+hBzt9fEagPCqpd8IBmYFXy3/8u99TbyO7ieGa+LaK22uUuxNNzSw0sQRqwdNk= X-Received: by 2002:aca:3c42:: with SMTP id j63mr1906166oia.97.1634007885803; Mon, 11 Oct 2021 20:04:45 -0700 (PDT) MIME-Version: 1.0 References: <8d9d962c7c9d4130bdf7030ee09b5d09@huawei.com> <423b08d46294454d9a9625990ce52acb@huawei.com> <322a8c29-e232-a39d-94ca-9c9cbf09c8d2@gmail.com> <9945ca9c-2ba7-bd00-6e3e-261c376a9718@gmail.com> <938b4efa-1383-beb8-5dc7-e2a951d15457@gmail.com> In-Reply-To: From: Erik Kline Date: Mon, 11 Oct 2021 20:04:34 -0700 Message-ID: To: Brian E Carpenter Cc: Robert Raszuk , Mark Smith , SPRING WG , 6MAN <6man@ietf.org> Content-Type: multipart/alternative; boundary="00000000000097f29205ce1f1be7" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 12 Oct 2021 03:04:51 -0000 --00000000000097f29205ce1f1be7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've been noodling on these issues for a couple of days now (many thanks to all who've been trying to help me understand), and I'm kinda confused by how some unicast address semantics could be met (or not met). Specifically: how can you ping a CSID? It's possible to ping a SID, but I don't yet see how this works with CSIDs. Per RFC 4443 S4.2, the source address of an Echo Reply MUST be the Destination Address. If I understand things correctly (a big "if") the first segment router won't reply to an Echo Request but instead `uncompress` the address and forward the packet on, until it reaches the last node. The last node won't be able to originate a packet with the correct source address though, I think. Am I missing something? Probably... On Sat, Oct 9, 2021 at 7:03 PM Erik Kline wrote: > > > To address the self-rewriting Destination Address complexity, and some > related objections, might it be possible to add a mutable TLV, requiring > the presence of an SRH (no SRH-less packets)? The mutable TLV would > contain any extra state necessary to continue decompression of the curren= t > segment in the SRH into the Destination Address field or trigger > advancement to the next segment in the list. This would allow the DA to > remain a plain IPv6 address/SID (current operation). > > (I've had a few other thoughts, but they aren't without their own > shortcomings.) > > > On Sat, Oct 9, 2021 at 2:13 PM Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >> On 10-Oct-21 10:04, Robert Raszuk wrote: >> > >> > Please kindly correct me if I am wrong, but where do you see that SRv6 >> is mandated to use "IPv6 Interface IDs" ? >> >> I have no idea, but IPv6 is mandated to use IPv6 Interface IDs. If that >> doesn't apply to SRV6, then it's impossible to claim that SRV6 is IPv6. >> >> This isn't just academic standards-oriented formalism. As others have >> pointed out, it has very significant deployment and operational >> implications, given that most products support IPv6, not SRV6. >> >> Brian >> >> > >> > On Sat, Oct 9, 2021 at 11:00 PM Mark Smith > > wrote: >> > >> > It's stated twice in section 2.5 of RFC4291. >> > >> > For all unicast addresses, except those that start with the binary >> > value 000, Interface IDs are required to be 64 bits long and to >> be >> > constructed in Modified EUI-64 format. >> > >> > >> > All Global Unicast addresses other than those that start with >> binary >> > 000 have a 64-bit interface ID field (i.e., n + m =3D 64), >> formatted as >> > described in Section 2.5.1 < >> https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.1>. Global >> Unicast addresses that start with >> > binary 000 have no such constraint on the size or structure of >> the >> > interface ID field. >> > >> > >> > Please also see RFC7421, Analysis of the 64-bit Boundary >> in IPv6 Addressing. >> > >> > >> > >> > >> > >> > >> > On Sun, 10 Oct 2021, 07:27 Robert Raszuk, > > wrote: >> > >> > > Hi Brian, >> > > >> > >> Which means: 64 bits. >> > > >> > > Sorry but what is so magic about /64 here ? >> > >> > It is mandated by the current IPv6 addressing architecture= . >> >> > >> > >> > Really ? Where ? I am looking at RFC4291 and nowhere I can fin= d >> /64 reference. >> > >> > Moreover sections 2.4 and 2.5 are very clear that there is no >> magic /64 hard defined. >> > >> > The text actually goes even further and says: >> > >> > Except for the knowledge of the subnet boundary discussed i= n >> the >> > previous paragraphs, nodes should not make any assumptions >> about the >> > structure of an IPv6 address. >> > >> > >> > Thx, >> > >> > R. >> > >> > >> > >> > >> > >> > Despite many discussions, there has never been consensus t= o >> change it. So if /64 is not the boundary between the routeable part and >> the host-specific part, it's not IPv6. >> > >> > Brian >> > >> > > >> > > Is this coming from the longest routable IPv6 prefix ? >> Sort of analogy to /24 in the IPv4 world ? Or something else ? >> > > >> > > I think LPM and CIDR techniques are pretty well >> established. >> > > >> > > Any fixed length of the address block with the meaning - >> do not use those bits inter or intra domain for anything useful even >> if your prefix+node can happily fit in /32 seems just dead wrong to me. >> And that is irrespective of any SRv6 discussion. >> > > >> > > In my books if I get allocated say /48 or /40 from RIR >> what I do with the remaining bits is my own business. >> > > >> > > Best, >> > > R. >> > > >> > > >> > > >> > > > Sorry, but it is a little bit late =E2=80=93 RFC 8= 986 is >> already published. >> > > >> > > "Locators are assigned consistent with >> IPv6 infrastructure allocation." >> > > >> > > Which means: 64 bits. >> > > >> > > I have no time to study compressed SIDs, but if they >> trample on the >> > LOC they are not IPv6 addresses. >> > > >> > > Brian >> > > >> > > >> > > >> -------------------------------------------------------------------- >> > > IETF IPv6 working group mailing list >> > > ipv6@ietf.org > ipv6@ietf.org > >> > > Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 < >> https://www.ietf.org/mailman/listinfo/ipv6> >> > > https://www.ietf.org/mailman/listinfo/ipv6>> >> > > >> -------------------------------------------------------------------- >> > > >> > >> > >> -------------------------------------------------------------------- >> > IETF IPv6 working group mailing list >> > ipv6@ietf.org >> > Administrative Requests: >> https://www.ietf.org/mailman/listinfo/ipv6 < >> https://www.ietf.org/mailman/listinfo/ipv6> >> > >> -------------------------------------------------------------------- >> > >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > --00000000000097f29205ce1f1be7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I've been noodling on these issues for a couple=C2=A0o= f days now (many thanks to all who've been trying to help me understand= ), and I'm kinda confused by how some unicast address semantics could b= e met (or not met).=C2=A0 Specifically: how can you ping a CSID?=C2=A0 It&#= 39;s possible to ping a SID, but I don't yet see how this works with CS= IDs.

    Per RFC 4443 S4.2, the source address of an Echo Re= ply MUST be the Destination Address.=C2=A0 If I understand things correctly= (a big "if") the first segment router won't reply to an Echo= Request but instead `uncompress` the address and forward the packet on, un= til it reaches the last node.=C2=A0 The last node won't be able to orig= inate a packet with the correct source address though, I think.
    <= br>
    Am I missing something?=C2=A0 Probably...

    On Sat, Oct 9,= 2021 at 7:03 PM Erik Kline <ek.iet= f@gmail.com> wrote:
    <random>

    To addr= ess the self-rewriting Destination Address complexity, and some related obj= ections, might it be possible to add a mutable TLV, requiring the presence = of an SRH (no SRH-less packets)?=C2=A0 The mutable TLV would contain any ex= tra state necessary to continue decompression of the current segment in the= SRH into the Destination Address field or trigger advancement to the next = segment in the list.=C2=A0 This would allow the DA to remain a plain IPv6 a= ddress/SID (current operation).

    (I've had a few = other thoughts, but they aren't without their own shortcomings.)
    <= div>

    On Sat, Oct 9, 2021 at 2:13 PM Brian E Carpenter <brian.e.carpente= r@gmail.com> wrote:
    On 10-Oct-21 10:04, Robert Raszuk wrote:
    >
    > Please kindly correct me=C2=A0if I am wrong, but where do you see that= SRv6 is mandated to use "IPv6 Interface IDs" ?

    I have no idea, but IPv6 is mandated to use IPv6 Interface IDs. If that doe= sn't apply to SRV6, then it's impossible to claim that SRV6 is IPv6= .

    This isn't just academic standards-oriented formalism. As others have p= ointed out, it has very significant deployment and operational implications= , given that most products support IPv6, not SRV6.

    =C2=A0 =C2=A0Brian

    >
    > On Sat, Oct 9, 2021 at 11:00 PM Mark Smith <markzzzsmith@gmail.com <mailto:= markzzzsmith@gm= ail.com>> wrote:
    >
    >=C2=A0 =C2=A0 =C2=A0It's stated twice in section 2.5 of RFC4291. >
    >=C2=A0 =C2=A0 =C2=A0For all unicast addresses, except those that start = with the binary
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 value 000, Interface IDs are required to be= 64 bits long and to be
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 constructed in Modified EUI-64 format.
    >
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 All Global Unicast addresses other than tho= se that start with binary
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 000 have a 64-bit interface ID field (i.e.,= n + m =3D 64), formatted as
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 described in Section 2.5.1 <https://datatracker.ietf.org/doc/html/rfc4291#section= -2.5.1>.=C2=A0 Global Unicast addresses that start with
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 binary 000 have no such constraint on the s= ize or structure of the
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 interface ID field.
    >
    >
    >=C2=A0 =C2=A0 =C2=A0Please also see RFC7421,=C2=A0=C2=A0Analysis of the= 64-bit Boundary
    in IPv6 Addressing.
    >
    >
    >
    >
    >
    >
    >=C2=A0 =C2=A0 =C2=A0On Sun, 10 Oct 2021, 07:27 Robert Raszuk, <robert@raszuk.net <= ;mailto:robert@raszu= k.net>> wrote:
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Hi Brian,=C2=A0 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> Which means: 6= 4 bits.
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Sorry but what is = so magic=C2=A0about /64 here ?
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It is mandated by the c= urrent IPv6 addressing architecture.

    >
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Really ? Where ? I am looking at RFC4= 291 and nowhere I can find
    /64 reference.=C2=A0
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Moreover sections 2.4 and 2.5 are ver= y clear that there is no magic /64 hard defined.=C2=A0
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The text actually goes even further a= nd says:=C2=A0
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Except for the knowledge of t= he subnet boundary discussed in
    the
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 previous paragraphs, nodes sh= ould not make any assumptions about the
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 structure of an IPv6 address.=
    >
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thx,
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0R.
    >
    >
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Despite many discussion= s, there has never been consensus to
    change it. So if /64 is not the boundary between the routeable part and the= host-specific part, it's not IPv6.
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0Brian
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Is this coming fro= m the longest routable IPv6 prefix ? Sort of analogy to /24 in the IPv4 wor= ld ? Or something else ?=C2=A0
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> I think LPM and CI= DR techniques are pretty well established.=C2=A0
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Any fixed length o= f the address block with the meaning=C2=A0- do not use those bits inter or = intra domain for anything useful even
    if your prefix+node can happily fit in /32 seems just dead wrong to me. And= that is irrespective of any SRv6 discussion.=C2=A0
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> In my books if I g= et allocated say /48 or /40 from RIR what I do with the remaining bits is m= y own business.=C2=A0
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Best,
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> R.
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> =C2=A0
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0> Sorry, but it is a little bit late =E2=80=93 RFC 8986 is already pu= blished.
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0"Locators are assigned consistent with
    IPv6 infrastructure allocation."
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0Which means: 64 bits.
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0I have no time to study compressed SIDs, but if they trample on the
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LOC they are not IPv6 a= ddresses.
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0=C2=A0 =C2=A0Brian
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0--------------------------------------------------------------------
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0IETF IPv6 working group mailing list
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0ipv6@ietf.org <= ;mailto:ipv6@ietf.org> <mailto:ipv6@ie= tf.org <mailto:ip= v6@ietf.org>>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0Administrative Requests: https://www.ietf.org/mailman/l= istinfo/ipv6 <https://www.ietf.org/mailman/listinfo= /ipv6>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<ht= tps://www.ietf.org/mailman/listinfo/ipv6 <https://w= ww.ietf.org/mailman/listinfo/ipv6>>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2= =A0--------------------------------------------------------------------
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
    >
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------------------------------------= -------------------------------
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IETF IPv6 working group mailing list<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ipv6@ietf.org <mailto:ipv6@ietf.org>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <ht= tps://www.ietf.org/mailman/listinfo/ipv6>
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-------------------------------------= -------------------------------
    >

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
    --------------------------------------------------------------------
    --00000000000097f29205ce1f1be7-- From nobody Tue Oct 12 02:43:56 2021 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 BBAA23A0CCC; Tue, 12 Oct 2021 02:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8USWAXaICa3; Tue, 12 Oct 2021 02:43:48 -0700 (PDT) Received: from esmtp-1.proxad.net (esmtp-1.proxad.net [213.36.6.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82EDE3A08D8; Tue, 12 Oct 2021 02:43:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by esmtp-1.proxad.net (Postfix) with ESMTP id F20CF150042E; Tue, 12 Oct 2021 11:43:41 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at proxad.net Received: from esmtp-1.proxad.net ([127.0.0.1]) by localhost (esmtp-b23-1.proxad.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tBI1rNabZQLr; Tue, 12 Oct 2021 11:43:41 +0200 (CEST) Received: from zstore-3.mgt.proxad.net (unknown [172.18.94.10]) by esmtp-1.proxad.net (Postfix) with ESMTP id 2D5261500239; Tue, 12 Oct 2021 11:43:38 +0200 (CEST) Date: Tue, 12 Oct 2021 11:43:38 +0200 (CEST) From: =?utf-8?Q?S=C3=A9bastien?= Parisot To: James Guichard Cc: SPRING WG List , spring-chairs@ietf.org Message-ID: <2146047828.310892003.1634031818005.JavaMail.zimbra@free-mobile.fr> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.8.12_GA_3803 (ZimbraWebClient - GC90 (Linux)/8.8.12_GA_3794) Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3ddzSgt4M Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 12 Oct 2021 09:43:53 -0000 Dear chairs and WG, I support the adoption of draft-filsfilscheng-spring-srv6-srh-compression. A SID compression mechanism is needed and this draft specifies one that is = both efficient (as the DT documented) and consistent with standardized SRv6= architecture and dataplane. Thanks, S=C3=A9bastien ----- Mail original ----- > De: "James Guichard" > =C3=80: "SPRING WG List" > Cc: spring-chairs@ietf.org > Envoy=C3=A9: Vendredi 1 Octobre 2021 16:04:48 > Objet: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ > Dear WG: >=20 >=20 >=20 > The chairs would like to express their appreciation for all the responses > received to our emails with reference to how the working group wishes to = move > forward with respect to a solution for SRv6 compression. >=20 >=20 >=20 > The apparent inclination of the working group is to use [ > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > | > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > ] as the basis for its compression standardization work. That is part of = what > this email attempts to confirm. >=20 >=20 >=20 > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15 th for [ > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > | > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > ] but with some clear guidelines as follows. By expressing support for ad= option > of this document you are fully aware of and are acknowledging that: >=20 >=20 >=20 > 1. The SPRING working group is adopting a document that has multiple S= Rv6 > Endpoint behaviors. > 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change = as it goes through review > and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be addre= ssed > BEFORE said document is allowed to progress from the working group to > publication. A list of these discussion points will be documented in t= he WG > document and maintained by the document editor in conjunction with the= chairs. > 4. If this document is adopted by the working group, the chairs specif= y as part > of the adoption call that the following text describing an open issue = be added > to the document in the above-described open issues section: >=20 >=20 > * "Given that the working group has said that it wants to standard= ize one data > plane solution, and given that the document contains multiple SRv6= EndPoint > behaviors that some WG members have stated are multiple data plane= solutions, > the working group will address whether this is valid and coherent = with its one > data plane solution objective.". >=20 >=20 >=20 >=20 > Please consider the above guidelines as you decide on whether to support = or not > this WG adoption. Please express clearly your reasoning for support/non-s= upport > as well as any open discussion points you would like addressed should the > document be adopted into the working group. >=20 >=20 >=20 > Thanks! >=20 >=20 >=20 > Jim, Bruno & Joel >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From prvs=911225e75=Mike.DiVincenzo@wwt.com Mon Oct 11 10:19:49 2021 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 B65853A0E45; Mon, 11 Oct 2021 10:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=wwt.com header.b=YHnFQ8G8; dkim=pass (1024-bit key) header.d=wwt.onmicrosoft.com header.b=MFOXZQJh 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 ExvPBgtLwsMU; Mon, 11 Oct 2021 10:19:44 -0700 (PDT) Received: from esa.hc1931-21.iphmx.com (esa.hc1931-21.iphmx.com [68.232.131.167]) (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 F36CD3A0E3C; Mon, 11 Oct 2021 10:19:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=wwt.com; i=@wwt.com; q=dns/txt; s=selector1; t=1633972784; x=1665508784; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mlwBEMNOg57PJx6/2SLvPotHcOi3LSK9wC0MEUSbaxY=; b=YHnFQ8G8IG1Gdrfh1d/eeXHgiRMfhVFEc8yqOjxbA0HgDYB1h9FbSiN3 5Be+h+ZA7v2N3bs9SZMKVcxVjesj6dwmu/EcWRQzeDNv4HGdIROafGLqv rsZlFjdLAbuA0gxdM8LXsWgDWVnsh8ieKSwv+G7ZFqpix4OyjEl3VNpp5 oEAxSTzCZ/Tv9JhTV3soiKD36wB/jQxZSSxzo8/8beLUrCuV8AFoCKMqg YzD8Wysa5GPD2JB6gq8GDrbs83gLOO0fibilt2AkWVIYhfueuMqvakbyU c4FBQWE7mSWyZ/FoNxQXEtp8HasH/gIJLh2l80EOIw0dMIg4WB8EieLFN Q==; X-IronPort-AV: E=Sophos;i="5.85,365,1624338000"; d="scan'208,217";a="154346833" Received: from mail-dm6nam12lp2177.outbound.protection.outlook.com (HELO NAM12-DM6-obe.outbound.protection.outlook.com) ([104.47.59.177]) by ob1.hc1931-21.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES128-GCM-SHA256; 11 Oct 2021 12:19:42 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Yz4OMIPnYirpZd77OTvimqchtyLts7ZyC78XW1wshIDwB1lS3l350GJ+hHdWxKvRyNwjz3Wy1DbqCXfRA/wjwvsKDbMWflYUVrZBil2Vu1TbeK+tUWPqxW45gikxsnfYAZKGQCnXdgFJyDPUvA/ax35gU6YuYKfvVMWHNW/R2hG9CH375wXgiccr5Vga1YPm43OCFS77b+y6GIIjCW37HmgpxP5Zuv0DeO1C/AUmRtrko96bVOaUBH6ch/BM4oRktRJIrzAciik5owft9cDp1tRAZ2ARDv947g590dsVncjNGOngDN7VEEHBjrbqJApcidzXF5mblL/A89IMJh7K1Q== 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=mlwBEMNOg57PJx6/2SLvPotHcOi3LSK9wC0MEUSbaxY=; b=Sd10EmziKHamBx11mlFyxI1IIk6+Uzw+vO3ZuDHQxrWBSe8dtWidcTJoUcXdHvStl7BSPxRXoypzsLGNKeQmZ9KXiVqYXa3XEgd1iH2wTEZSsUAGLvU019ql6stY1zbfLJfDC30gmfBfz6vtZC+W97OlPSwSThu5ZNf0IydthymFb8KDKcTmIJSM40bt3e86PyZ0r0rEcPJtZYkAlh2ObdllLwV1eQWFHUKi8BLxSdlCAU/mkY+MOqVoACCKIkH0CxgXpdSep9CkY5pYRUMEg77HrNIhFqJSHnWcewTw5E4W+mf5yQIVfMsxtq8vT4LG48b1XF0GyW2sYAQDU8mDxQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wwt.com; dmarc=pass action=none header.from=wwt.com; dkim=pass header.d=wwt.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=WWT.onmicrosoft.com; s=selector1-WWT-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mlwBEMNOg57PJx6/2SLvPotHcOi3LSK9wC0MEUSbaxY=; b=MFOXZQJh1KYnDklIVWIvOjcIg7zpmtcgh4frUpaMHt+cNU6P5vMxxc1moH1jiMzrLFiWuZf5WcO/esQy58anXF8981ajfP8yJQNaVZdV3KQEtWB+gU9p8mQ2R42j04UTCbL+uKd6dIht90pOnowzTM/dtKBevkGWFJ0ftzj7wAo= Received: from MW3PR19MB4283.namprd19.prod.outlook.com (2603:10b6:303:41::16) by MWHPR19MB1197.namprd19.prod.outlook.com (2603:10b6:320:2b::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.25; Mon, 11 Oct 2021 17:19:39 +0000 Received: from MW3PR19MB4283.namprd19.prod.outlook.com ([fe80::4496:b2e5:fc92:94c5]) by MW3PR19MB4283.namprd19.prod.outlook.com ([fe80::4496:b2e5:fc92:94c5%7]) with mapi id 15.20.4587.026; Mon, 11 Oct 2021 17:19:39 +0000 From: "DiVincenzo, Mike" To: James Guichard CC: SPRING WG , "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: AQHXvsQsi0NDaGQea0SW/65j1/028Q== Date: Mon, 11 Oct 2021 17:19:39 +0000 Message-ID: <8BA8291F-D97B-4ED4-8200-EBCADB98B8B2@wwt.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.120.0.1.13) authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=wwt.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d674624a-9253-470a-ffa8-08d98cdb4ee7 x-ms-traffictypediagnostic: MWHPR19MB1197: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: v8aKDV3GeGNh79qB1CtQ7PiBK8gdsna7N8LC5NkCxHnK/5yubt9lXP1qb0zubjncsz5oQ8zNYOee+2t9lbcKztBvlVQOnuaj6ypJIi7dVSMijVHZpwT/f2weBmNHLM8xQI4yXkSBUiTlVWp9LnLUkdhWIGLTBsPQtrN8Sk0I/NdvUOnUrsUlLmKcHO8fZk1z22SbR22PrR8jsAebWr5+hwurnLlGHej48IEK6WmuOxvLQju7FLgaLSWsuUqyG0UdzEQRnhFyOJlt4pdxG2fpUeHoW2x4UldNKinvFJNSB+ICRCklSe94ID26lYAiLQYlQUs5REpPXj7oSM9LC10JJGODrke7O/7FKTVgWqu+uN+IuSrouXoQ96e/EaJ1mw3vZVaZKVvJlCqbm0qdBqLE89tKy2Jx8Stp8vBuxphYTf66uUIG2ABja8lubm3zSihXz6Jq+Ru73dNelwEcvMQFJur3rY4IKm2ApVjZZXNfLkaqt78th7t55HmJOM9/itNop4c7ML3Rn//MAqguEePYe4Xci1Abv+rsVMC/r82yiWbsw2z87Q5Xsmlzyu/wvIqpld4StYxpLW1iPo8HGXpyEr6/hvgy0n+pOUFLCjinqMuwIVbxCx7ONe04+Tfegtifx1ECKbF1I2sTqbpGV0cZgBrE8hEotmKhj107d57CRP18CYdkr5t3QDnnTwqUm56FrPM5xYIcSES/f/o9DrnbwW7w5n3bxzeXCcEnzVM34bUdtpc/XEPy625ToMcEe9lgZszlx3DOLGv1DIHPaEhswQlVJq+MaGXySQiqusA/S6ubpx2Ird4J+BUT+iQ+jUsM x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR19MB4283.namprd19.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(40140700001)(166002)(966005)(5660300002)(4326008)(26005)(508600001)(2616005)(71200400001)(6512007)(36756003)(6506007)(6916009)(53546011)(8676002)(8936002)(54906003)(38100700002)(83380400001)(6486002)(66446008)(64756008)(66556008)(66476007)(33656002)(38070700005)(76116006)(122000001)(2906002)(316002)(91956017)(186003)(86362001)(66946007)(45980500001)(579004)(559001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?QWRSemRKcjk0QXhlUU52djdxUmd1R1ZWeHp4M3NNM1JOVC92UUF1TzIwYUEr?= =?utf-8?B?K0F5eVlRZ3VpR3RNdFV2cGRnc2d0ekxkZ2VuMkVERGdUM2Q1OXRWeGF0aEVM?= =?utf-8?B?SnRTRWkxcUpjaGFPKzRvS1J6ZkpXVS9rTldUVXZWSzRZTGhxK2I2blpLSkZi?= =?utf-8?B?OHh0aWdKMWpWM1pneFg3cVZvSnZldFdwSVFFSktoNWZBc2U0MlJURG9GRStM?= =?utf-8?B?c3lzeEJRVnl3Ly9FUUJrZUlMdnlXeHhzcWRsaVJ4TEJNR0VuS2JpdGU2MXVI?= =?utf-8?B?NUVWR1pSYTNzVC9xNGM1Wm54TFdOMm03YktkRWhyL1MxQ29Dc0krUWVJdXlv?= =?utf-8?B?NDNFajI2VXV2VnhaUjRsL1JHTzRBM0ZtQmcxdTNZWkdmMmRxcTROOHBvN0h5?= =?utf-8?B?bzFzd3lodm8wTWs1VnVMbWVDdUE2WFVFdHdidGNKMDNoUi8xY1NoSHBRQTUz?= =?utf-8?B?cGo5alR6RWRhT2d5aDlpM0lsek9CUTQ5dzBHVGRUSit2N3pvdUlQa3FYb2Nu?= =?utf-8?B?bFBXVzR2NDh1UjQ5Wi9aRXVXVW5nOWxBMElVTTJyTnNPZjQvVFBVb0RuVmsr?= =?utf-8?B?cGhHTlBUbDFBZE8vNXNDekxWdHRPVldlWDU4dFFZOXlSMllpKzJheHBrblgw?= =?utf-8?B?TldKZ0Z2dHlWYnU3RzR3VGNXamlMU1JLSHMxUDR3OHJVc2NXWi9FY2F4S0Rm?= =?utf-8?B?T3M5elJhQjVpRE9zVTg3WmFiV0tQZ2M2NzRqZXVWaWpxTkRzQlUvYm9DdHdh?= =?utf-8?B?WkdwR1kwaGJsRDZBVWVMa3hXVXNpZEFuS01TK1lyRzFPZnR6TDBMQng0VlFV?= =?utf-8?B?a0w5RjJSaTNFZ1I3UDRrb3VidElLejVCWjYvVHVFNnNEOW5maVg5NzlhWGtY?= =?utf-8?B?dDJRWlpDQlZwVjZYQjVRaUp3eStkcW1GRVdudFZzY2tvb2YwMkxhSkV6Rnkv?= =?utf-8?B?aGJ5aFFhKzVhMHh6V29GN0NiVDAwUE03M0VKRnIwNXpJMlp1NmhaYmFSNWZk?= =?utf-8?B?SUVOcUF0SWNoaDJGZmFHdXo1ZFUxL2wrdUwxRy9nc3lORHZ3dGZnTXpaWFBa?= =?utf-8?B?TWpUbFlZSUlnMmhiY1luNEdKWm95SGd2YkRUZjJZWkFqb21BWFh3NEx3aTR3?= =?utf-8?B?K2JacVFObWEvQnltK1ZOZDNLc2loSWc0WjhBR2FXeDFuRmM5cDREUkFoQXVK?= =?utf-8?B?U0RGbzZpVnluWlEzdXkxSkQrVFVVeXo3cjVSTHJDV2EzR3FKOHd4OGxNSWc5?= =?utf-8?B?NXdlSm5MREtmQS9hVGRCekN1L0NyNnhmeTYvMmlTMjRwc09JdkpaallTbDdZ?= =?utf-8?B?TVJYNFRtd2RBaTUrZ2x3RzVtbVk4S3hLblVDR1QxbDFGdkxuM0F1WkVhOUZN?= =?utf-8?B?TG5VZnYvekhoTG4rWXR5S25vQU1pNnBWbWd5K2hlclVaRnozL2VYYS9YcW9s?= =?utf-8?B?MmNvOUdjZEsyUXFTUW83ejJKazY2dkY2V0hwTHh3Tno5a1lPais5dTk1dlFp?= =?utf-8?B?dXRBSFZxZFBDdFl2cDFMSElPWmdvbTAyRys3N0FyOU5oVTNWSlN3STN6UjFN?= =?utf-8?B?U2VxVS9DWVRlSnk4bnIweUFqbmhOUlI4bVJabFJLRUh5Nk1FVEZJdnZPajZk?= =?utf-8?B?UnM1aGszeXhwak9SVFhzOGoxYmdCN1N1MDZMY1RwcENHMXR5ZysrOFY3UXJU?= =?utf-8?B?d0twYWp4NjEvTDVzOTRNRkUrM0xhYnNNSStiZ3VtL2hmOXViWUpxcHJBS1FT?= =?utf-8?Q?DyN8KmsDSwY1GTclgvweNriFqictV0HIxjQ6XH6?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_8BA8291FD97B4ED48200EBCADB98B8B2wwtcom_" MIME-Version: 1.0 X-OriginatorOrg: wwt.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR19MB4283.namprd19.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d674624a-9253-470a-ffa8-08d98cdb4ee7 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2021 17:19:39.8353 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a2d8e6b4-e26e-4421-8f3d-ec288c827c7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: YDWZHlUj+pUftSPKJD+rhtz94Z3dr4JuKKun8oJ2WlI1Cwb+wRTovSwbwfUi+fa597wLH95POwBUR8AIvCMDnw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR19MB1197 Archived-At: X-Mailman-Approved-At: Tue, 12 Oct 2021 02:44:27 -0700 Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 11 Oct 2021 17:21:51 -0000 --_000_8BA8291FD97B4ED48200EBCADB98B8B2wwtcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBsaWtlIHRvIGV4cHJlc3MgbXkgc3VwcG9ydCBmb3IgdGhlIENvbXByZXNzZWQgU1J2 NiBTZWdtZW50IExpc3QgRW5jb2RpbmcgaW4gU1JIIGRyYWZ0LiAgQXMgYW4gYXJjaGl0ZWN0IGZv ciBvbmUgb2YgdGhlIHdvcmxk4oCZcyBsYXJnZXN0IFNvbHV0aW9ucyBwcm92aWRlcnMsIHdlIGhh dmUgcXVpdGUgYSBiaXQgb2YgaW50ZXJlc3QgaW4gdGhpcyBzb2x1dGlvbi4gIEkgaGF2ZSBiZWVu IGludm9sdmVkIGluIFNSIHNpbmNlIDIwMTMgYW5kIGhhdmUgYmVlbiBmb2xsb3dpbmcgU1J2NiBp bXBsZW1lbnRhdGlvbiBmb3IgcXVpdGUgYSB3aGlsZS4gIE5vdCBvbmx5IGlzIHRoaXMgc29sdXRp b24gZWxlZ2FudCBhbmQgc3RyYWlnaHRmb3J3YXJkLCBidXQgd2VsbCBuZWVkZWQuIEkgZW5jb3Vy YWdlIHRoZSBJRVRGIHRvIGFkb3B0IHRoaXMgZHJhZnQgZm9yIGEgcHJvcG9zZWQgc3RhbmRhcmQu DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN Ck1pa2UgRGlWaW5jZW56bw0KVGVjaG5pY2FsIFNvbHV0aW9ucyBBcmNoaXRlY3QgKE1QTFMvU1Ip DQpXb3JsZCBXaWRlIFRlY2hub2xvZ3kgfCBHbG9iYWwgRW5naW5lZXJpbmcNCk9mZmljZTogOTgw LjI3My43OTAxICB8ICBNb2JpbGU6IDkxOS43NDEuODMxNA0KRW1haWw6IG1pa2UuZGl2aW5jZW56 b0B3d3QuY29tPG1haWx0bzptaWtlLmRpdmluY2Vuem9Ad3d0LmNvbT4gIHwgIENDSUUgIzkzNTgN Cg0KDQoNCk9uIE9jdCAxLCAyMDIxLCBhdCAxMDowNSBBTSwgSmFtZXMgR3VpY2hhcmQgPGphbWVz Lm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbTxtYWlsdG86amFtZXMubi5ndWljaGFyZEBmdXR1cmV3 ZWkuY29tPj4gd3JvdGU6DQoNCkRlYXIgV0c6DQoNClRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBl eHByZXNzIHRoZWlyIGFwcHJlY2lhdGlvbiBmb3IgYWxsIHRoZSByZXNwb25zZXMgcmVjZWl2ZWQg dG8gb3VyIGVtYWlscyB3aXRoIHJlZmVyZW5jZSB0byBob3cgdGhlIHdvcmtpbmcgZ3JvdXAgd2lz aGVzIHRvIG1vdmUgZm9yd2FyZCB3aXRoIHJlc3BlY3QgdG8gYSBzb2x1dGlvbiBmb3IgU1J2NiBj b21wcmVzc2lvbi4NCg0KVGhlIGFwcGFyZW50IGluY2xpbmF0aW9uIG9mIHRoZSB3b3JraW5nIGdy b3VwIGlzIHRvIHVzZSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxz Zmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8gYXMgdGhlIGJhc2lzIGZvciBp dHMgY29tcHJlc3Npb24gc3RhbmRhcmRpemF0aW9uIHdvcmsuIFRoYXQgaXMgcGFydCBvZiB3aGF0 IHRoaXMgZW1haWwgYXR0ZW1wdHMgdG8gY29uZmlybS4NCg0KQmVjYXVzZSBvZiB0aGUgYWJvdmUg dGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGlzc3VlIGEgMi13ZWVrIFdHIGNhbGwgZm9yIGFkb3B0 aW9uIGVuZGluZyBPY3RvYmVyIDE1dGggZm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyBidXQg d2l0aCBzb21lIGNsZWFyIGd1aWRlbGluZXMgYXMgZm9sbG93cy4gQnkgZXhwcmVzc2luZyBzdXBw b3J0IGZvciBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IHlvdSBhcmUgZnVsbHkgYXdhcmUgb2Yg YW5kIGFyZSBhY2tub3dsZWRnaW5nIHRoYXQ6DQoNCg0KICAxLiAgVGhlIFNQUklORyB3b3JraW5n IGdyb3VwIGlzIGFkb3B0aW5nIGEgZG9jdW1lbnQgdGhhdCBoYXMgbXVsdGlwbGUgU1J2NiBFbmRw b2ludCBiZWhhdmlvcnMuDQogIDIuICBUaGUgZG9jdW1lbnQgaXMgYSDigJxsaXZpbmfigJ0gZG9j dW1lbnQ7IGl0IG1heSBjaGFuZ2UgYXMgaXQgZ29lcyB0aHJvdWdoIHJldmlldyBhbmQgYW5hbHlz aXMgYnkgdGhlIFNQUklORyB3b3JraW5nIGdyb3VwLg0KICAzLiAgQWxsIG9wZW4gZGlzY3Vzc2lv biBwb2ludHMgcmFpc2VkIG9uIG91ciBtYWlsaW5nIGxpc3QgTVVTVCBiZSBhZGRyZXNzZWQgQkVG T1JFIHNhaWQgZG9jdW1lbnQgaXMgYWxsb3dlZCB0byBwcm9ncmVzcyBmcm9tIHRoZSB3b3JraW5n IGdyb3VwIHRvIHB1YmxpY2F0aW9uLiBBIGxpc3Qgb2YgdGhlc2UgZGlzY3Vzc2lvbiBwb2ludHMg d2lsbCBiZSBkb2N1bWVudGVkIGluIHRoZSBXRyBkb2N1bWVudCBhbmQgbWFpbnRhaW5lZCBieSB0 aGUgZG9jdW1lbnQgZWRpdG9yIGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIGNoYWlycy4NCiAgNC4g IElmIHRoaXMgZG9jdW1lbnQgaXMgYWRvcHRlZCBieSB0aGUgd29ya2luZyBncm91cCwgdGhlIGNo YWlycyBzcGVjaWZ5IGFzIHBhcnQgb2YgdGhlIGFkb3B0aW9uIGNhbGwgdGhhdCB0aGUgZm9sbG93 aW5nIHRleHQgZGVzY3JpYmluZyBhbiBvcGVuIGlzc3VlIGJlIGFkZGVkIHRvIHRoZSBkb2N1bWVu dCBpbiB0aGUgYWJvdmUtZGVzY3JpYmVkIG9wZW4gaXNzdWVzIHNlY3Rpb246DQogICAgICogICAi R2l2ZW4gdGhhdCB0aGUgd29ya2luZyBncm91cCBoYXMgc2FpZCB0aGF0IGl0IHdhbnRzIHRvIHN0 YW5kYXJkaXplIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uLCBhbmQgZ2l2ZW4gdGhhdCB0aGUgZG9j dW1lbnQgY29udGFpbnMgbXVsdGlwbGUgU1J2NiBFbmRQb2ludCBiZWhhdmlvcnMgdGhhdCBzb21l IFdHIG1lbWJlcnMgaGF2ZSBzdGF0ZWQgYXJlIG11bHRpcGxlIGRhdGEgcGxhbmUgc29sdXRpb25z LCB0aGUgd29ya2luZyBncm91cCB3aWxsIGFkZHJlc3Mgd2hldGhlciB0aGlzIGlzIHZhbGlkIGFu ZCBjb2hlcmVudCB3aXRoIGl0cyBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiBvYmplY3RpdmUuIi4N Cg0KDQpQbGVhc2UgY29uc2lkZXIgdGhlIGFib3ZlIGd1aWRlbGluZXMgYXMgeW91IGRlY2lkZSBv biB3aGV0aGVyIHRvIHN1cHBvcnQgb3Igbm90IHRoaXMgV0cgYWRvcHRpb24uIFBsZWFzZSBleHBy ZXNzIGNsZWFybHkgeW91ciByZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9uLXN1cHBvcnQgYXMgd2Vs bCBhcyBhbnkgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyB5b3Ugd291bGQgbGlrZSBhZGRyZXNzZWQg c2hvdWxkIHRoZSBkb2N1bWVudCBiZSBhZG9wdGVkIGludG8gdGhlIHdvcmtpbmcgZ3JvdXAuDQoN ClRoYW5rcyENCg0KSmltLCBCcnVubyAmIEpvZWwNCg0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGll dGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NwcmluZw0KDQo= --_000_8BA8291FD97B4ED48200EBCADB98B8B2wwtcom_ Content-Type: text/html; charset="utf-8" Content-ID: <81566C1EE8E8F34C8A19B200CFC74334@namprd19.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KIDxv Ok9mZmljZURvY3VtZW50U2V0dGluZ3M+DQogIDxvOkFsbG93UE5HLz4NCiA8L286T2ZmaWNlRG9j dW1lbnRTZXR0aW5ncz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KIDx3OldvcmREb2N1bWVudD4NCiAgPHc6Vmlldz5Ob3JtYWw8L3c6Vmlldz4NCiAgPHc6Wm9v bT4wPC93Olpvb20+DQogIDx3OlRyYWNrTW92ZXMvPg0KICA8dzpUcmFja0Zvcm1hdHRpbmcvPg0K ICA8dzpEb05vdFNob3dSZXZpc2lvbnMvPg0KICA8dzpEb05vdFByaW50UmV2aXNpb25zLz4NCiAg PHc6RG9Ob3RTaG93TWFya3VwLz4NCiAgPHc6RG9Ob3RTaG93Q29tbWVudHMvPg0KICA8dzpEb05v dFNob3dJbnNlcnRpb25zQW5kRGVsZXRpb25zLz4NCiAgPHc6RG9Ob3RTaG93UHJvcGVydHlDaGFu Z2VzLz4NCiAgPHc6UHVuY3R1YXRpb25LZXJuaW5nLz4NCiAgPHc6VmFsaWRhdGVBZ2FpbnN0U2No ZW1hcy8+DQogIDx3OlNhdmVJZlhNTEludmFsaWQ+ZmFsc2U8L3c6U2F2ZUlmWE1MSW52YWxpZD4N CiAgPHc6SWdub3JlTWl4ZWRDb250ZW50PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4NCiAg PHc6QWx3YXlzU2hvd1BsYWNlaG9sZGVyVGV4dD5mYWxzZTwvdzpBbHdheXNTaG93UGxhY2Vob2xk ZXJUZXh0Pg0KICA8dzpEb05vdFByb21vdGVRRi8+DQogIDx3OkxpZFRoZW1lT3RoZXI+RU4tVVM8 L3c6TGlkVGhlbWVPdGhlcj4NCiAgPHc6TGlkVGhlbWVBc2lhbj5YLU5PTkU8L3c6TGlkVGhlbWVB c2lhbj4NCiAgPHc6TGlkVGhlbWVDb21wbGV4U2NyaXB0PlgtTk9ORTwvdzpMaWRUaGVtZUNvbXBs ZXhTY3JpcHQ+DQogIDx3OkNvbXBhdGliaWxpdHk+DQogICA8dzpCcmVha1dyYXBwZWRUYWJsZXMv Pg0KICAgPHc6U25hcFRvR3JpZEluQ2VsbC8+DQogICA8dzpXcmFwVGV4dFdpdGhQdW5jdC8+DQog ICA8dzpVc2VBc2lhbkJyZWFrUnVsZXMvPg0KICAgPHc6RG9udEdyb3dBdXRvZml0Lz4NCiAgIDx3 OlNwbGl0UGdCcmVha0FuZFBhcmFNYXJrLz4NCiAgIDx3OkVuYWJsZU9wZW5UeXBlS2VybmluZy8+ DQogICA8dzpEb250RmxpcE1pcnJvckluZGVudHMvPg0KICAgPHc6T3ZlcnJpZGVUYWJsZVN0eWxl SHBzLz4NCiAgPC93OkNvbXBhdGliaWxpdHk+DQogIDxtOm1hdGhQcj4NCiAgIDxtOm1hdGhGb250 IG06dmFsPSJDYW1icmlhIE1hdGgiLz4NCiAgIDxtOmJya0JpbiBtOnZhbD0iYmVmb3JlIi8+DQog ICA8bTpicmtCaW5TdWIgbTp2YWw9IiYjNDU7LSIvPg0KICAgPG06c21hbGxGcmFjIG06dmFsPSJv ZmYiLz4NCiAgIDxtOmRpc3BEZWYvPg0KICAgPG06bE1hcmdpbiBtOnZhbD0iMCIvPg0KICAgPG06 ck1hcmdpbiBtOnZhbD0iMCIvPg0KICAgPG06ZGVmSmMgbTp2YWw9ImNlbnRlckdyb3VwIi8+DQog ICA8bTp3cmFwSW5kZW50IG06dmFsPSIxNDQwIi8+DQogICA8bTppbnRMaW0gbTp2YWw9InN1YlN1 cCIvPg0KICAgPG06bmFyeUxpbSBtOnZhbD0idW5kT3ZyIi8+DQogIDwvbTptYXRoUHI+PC93Oldv cmREb2N1bWVudD4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K IDx3OkxhdGVudFN0eWxlcyBEZWZMb2NrZWRTdGF0ZT0iZmFsc2UiIERlZlVuaGlkZVdoZW5Vc2Vk PSJmYWxzZSINCiAgRGVmU2VtaUhpZGRlbj0iZmFsc2UiIERlZlFGb3JtYXQ9ImZhbHNlIiBEZWZQ cmlvcml0eT0iOTkiDQogIExhdGVudFN0eWxlQ291bnQ9IjM3NiI+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMCIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iTm9ybWFs Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgUUZvcm1h dD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRl V2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMyIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUi DQogICBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA0 Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhp ZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1l PSJoZWFkaW5nIDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9 InRydWUiIE5hbWU9ImhlYWRpbmcgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRydWUiDQogICBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA3Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdo ZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDgiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIg0K ICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgOSIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJpbmRleCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIN CiAgIE5hbWU9ImluZGV4IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iaW5kZXggMyIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJpbmRleCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIN CiAgIE5hbWU9ImluZGV4IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iaW5kZXggNiIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJpbmRleCA3Ii8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIN CiAgIE5hbWU9ImluZGV4IDgiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iaW5kZXggOSIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlk ZGVuPSJ0cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyAxIi8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRy dWUiDQogICBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDIiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSINCiAg IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRl V2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiDQogICBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSIgTmFtZT0idG9jIDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl IiBOYW1lPSJ0b2MgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9 InRvYyA3Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzki IFNlbWlIaWRkZW49InRydWUiDQogICBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDgi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhp ZGRlbj0idHJ1ZSINCiAgIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgOSIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiDQogICBOYW1lPSJOb3JtYWwgSW5kZW50Ii8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIN CiAgIE5hbWU9ImZvb3Rub3RlIHRleHQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iYW5u b3RhdGlvbiB0ZXh0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9ImhlYWRlciIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiDQogICBOYW1lPSJmb290ZXIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFt ZT0iaW5kZXggaGVhZGluZyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjM1IiBTZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFG b3JtYXQ9InRydWUiIE5hbWU9ImNhcHRpb24iLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0i dGFibGUgb2YgZmlndXJlcyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJlbnZlbG9wZSBh ZGRyZXNzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0 cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9ImVudmVsb3BlIHJldHVybiIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJmb290bm90ZSByZWZlcmVuY2UiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIg0KICAgTmFtZT0iYW5ub3RhdGlvbiByZWZlcmVuY2UiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl Ig0KICAgTmFtZT0ibGluZSBudW1iZXIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0icGFn ZSBudW1iZXIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iZW5kbm90ZSByZWZlcmVuY2Ui Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iZW5kbm90ZSB0ZXh0Ii8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSINCiAgIE5hbWU9InRhYmxlIG9mIGF1dGhvcml0aWVzIi8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIN CiAgIE5hbWU9Im1hY3JvIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1p SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9InRvYSBoZWFkaW5n Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ikxpc3QiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0K ICAgTmFtZT0iTGlzdCBCdWxsZXQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTGlzdCBO dW1iZXIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTGlzdCAyIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSINCiAgIE5hbWU9Ikxpc3QgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJMaXN0 IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTGlzdCA1Ii8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSINCiAgIE5hbWU9Ikxpc3QgQnVsbGV0IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0i TGlzdCBCdWxsZXQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJMaXN0IEJ1bGxldCA0 Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ikxpc3QgQnVsbGV0IDUiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIg0KICAgTmFtZT0iTGlzdCBOdW1iZXIgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBO YW1lPSJMaXN0IE51bWJlciAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ikxpc3QgTnVt YmVyIDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTGlzdCBOdW1iZXIgNSIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEwIiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJUaXRsZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJDbG9zaW5nIi8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlNpZ25hdHVyZSIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEiIFNlbWlIaWRkZW49InRydWUiDQogICBVbmhpZGVX aGVuVXNlZD0idHJ1ZSIgTmFtZT0iRGVmYXVsdCBQYXJhZ3JhcGggRm9udCIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiDQogICBOYW1lPSJCb2R5IFRleHQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0i Qm9keSBUZXh0IEluZGVudCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJMaXN0IENvbnRp bnVlIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ikxpc3QgQ29udGludWUgMiIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiDQogICBOYW1lPSJMaXN0IENvbnRpbnVlIDMiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl Ig0KICAgTmFtZT0iTGlzdCBDb250aW51ZSA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9 Ikxpc3QgQ29udGludWUgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJNZXNzYWdlIEhl YWRlciIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjExIiBR Rm9ybWF0PSJ0cnVlIiBOYW1lPSJTdWJ0aXRsZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1l PSJTYWx1dGF0aW9uIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkRhdGUiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIg0KICAgTmFtZT0iQm9keSBUZXh0IEZpcnN0IEluZGVudCIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiDQogICBOYW1lPSJCb2R5IFRleHQgRmlyc3QgSW5kZW50IDIiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0 cnVlIg0KICAgTmFtZT0iTm90ZSBIZWFkaW5nIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9 IkJvZHkgVGV4dCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkJvZHkgVGV4dCAzIi8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkJvZHkgVGV4dCBJbmRlbnQgMiIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz ZWQ9InRydWUiDQogICBOYW1lPSJCb2R5IFRleHQgSW5kZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl Ig0KICAgTmFtZT0iQmxvY2sgVGV4dCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJIeXBl cmxpbmsiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iRm9sbG93ZWRIeXBlcmxpbmsiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyMiIgUUZvcm1hdD0i dHJ1ZSIgTmFtZT0iU3Ryb25nIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iMjAiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkVtcGhhc2lzIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSINCiAgIE5hbWU9IkRvY3VtZW50IE1hcCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1l PSJQbGFpbiBUZXh0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkUtbWFpbCBTaWduYXR1 cmUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iSFRNTCBUb3Agb2YgRm9ybSIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiDQogICBOYW1lPSJIVE1MIEJvdHRvbSBvZiBGb3JtIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i dHJ1ZSINCiAgIE5hbWU9Ik5vcm1hbCAoV2ViKSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1l PSJIVE1MIEFjcm9ueW0iLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iSFRNTCBBZGRyZXNz Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkhUTUwgQ2l0ZSIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiDQogICBOYW1lPSJIVE1MIENvZGUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iSFRN TCBEZWZpbml0aW9uIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkhUTUwgS2V5Ym9hcmQi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iSFRNTCBQcmVmb3JtYXR0ZWQiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIg0KICAgTmFtZT0iSFRNTCBTYW1wbGUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAg TmFtZT0iSFRNTCBUeXBld3JpdGVyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IkhUTUwg VmFyaWFibGUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49 InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iTm9ybWFsIFRhYmxlIi8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9ImFubm90YXRpb24gc3ViamVjdCIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9 InRydWUiDQogICBOYW1lPSJObyBMaXN0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ik91 dGxpbmUgTGlzdCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ik91dGxpbmUgTGlzdCAy Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBV bmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ik91dGxpbmUgTGlzdCAzIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIFNpbXBsZSAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAg IE5hbWU9IlRhYmxlIFNpbXBsZSAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxl IFNpbXBsZSAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIENsYXNzaWMgMSIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBDbGFzc2ljIDIiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgQ2xhc3NpYyAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAg IE5hbWU9IlRhYmxlIENsYXNzaWMgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJs ZSBDb2xvcmZ1bCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIENvbG9yZnVs IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgQ29sb3JmdWwgMyIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl blVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBDb2x1bW5zIDEiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl Ig0KICAgTmFtZT0iVGFibGUgQ29sdW1ucyAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9 IlRhYmxlIENvbHVtbnMgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBDb2x1 bW5zIDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgQ29sdW1ucyA1Ii8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX aGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIEdyaWQgMSIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi DQogICBOYW1lPSJUYWJsZSBHcmlkIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFi bGUgR3JpZCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIEdyaWQgNCIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl V2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBHcmlkIDUiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl Ig0KICAgTmFtZT0iVGFibGUgR3JpZCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRh YmxlIEdyaWQgNyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBHcmlkIDgiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk ZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgTGlzdCAxIi8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSINCiAgIE5hbWU9IlRhYmxlIExpc3QgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJU YWJsZSBMaXN0IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgTGlzdCA0Ii8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp ZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIExpc3QgNSIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy dWUiDQogICBOYW1lPSJUYWJsZSBMaXN0IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0i VGFibGUgTGlzdCA3Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlRhYmxlIExpc3QgOCIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o aWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSAzRCBlZmZlY3RzIDEiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgM0QgZWZmZWN0cyAyIi8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1 ZSINCiAgIE5hbWU9IlRhYmxlIDNEIGVmZmVjdHMgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBO YW1lPSJUYWJsZSBDb250ZW1wb3JhcnkiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFi bGUgRWxlZ2FudCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiDQogICBOYW1lPSJUYWJsZSBQcm9mZXNzaW9u YWwiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgU3VidGxlIDEiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgU3VidGxlIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0K ICAgTmFtZT0iVGFibGUgV2ViIDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUg V2ViIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgV2ViIDMiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V c2VkPSJ0cnVlIg0KICAgTmFtZT0iQmFsbG9vbiBUZXh0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIE5hbWU9IlRhYmxlIEdyaWQiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk PSJ0cnVlIg0KICAgTmFtZT0iVGFibGUgVGhlbWUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIE5hbWU9IlBsYWNlaG9sZGVyIFRleHQiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxIiBRRm9ybWF0PSJ0cnVl IiBOYW1lPSJObyBTcGFjaW5nIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ cmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIi8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1l ZGl1bSBTaGFkaW5nIDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0 IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFt ZT0iTWVkaXVtIEdyaWQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0Ii8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNv bG9yZnVsIFNoYWRpbmciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcg QWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCAxIi8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBT aGFkaW5nIDEgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgMSIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAx IEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu PSJ0cnVlIiBOYW1lPSJSZXZpc2lvbiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjM0IiBRRm9ybWF0PSJ0cnVlIg0KICAgTmFtZT0iTGlzdCBQYXJhZ3JhcGgi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIyOSIgUUZvcm1h dD0idHJ1ZSIgTmFtZT0iUXVvdGUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSIzMCIgUUZvcm1hdD0idHJ1ZSINCiAgIE5hbWU9IkludGVuc2UgUXVvdGUiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVk aXVtIExpc3QgMiBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIg QWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDEiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3Jm dWwgU2hhZGluZyBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAxIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQg QWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAyIi8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0 IEdyaWQgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAy IEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMiIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJN ZWRpdW0gR3JpZCAxIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDIiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQg MyBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMiIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJD b2xvcmZ1bCBMaXN0IEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDIiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGlu ZyBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDMiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVt IFNoYWRpbmcgMSBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCAzIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0 IDEgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCAz Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9 Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgMyIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3Qg QWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3 MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCAz Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9 IkNvbG9yZnVsIEdyaWQgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNCIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0 IEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNCIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJN ZWRpdW0gU2hhZGluZyAyIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDQiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExp c3QgMiBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50 IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFt ZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDQiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hh ZGluZyBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50 IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFt ZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBMaXN0IEFjY2VudCA1Ii8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQg QWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2 MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2Vu dCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5h bWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNSIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0g R3JpZCAxIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2Nl bnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBO YW1lPSJEYXJrIExpc3QgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNSIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1 bCBMaXN0IEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2Nl bnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBO YW1lPSJMaWdodCBMaXN0IEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDYiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRp bmcgMSBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNj ZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIg TmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA2Ii8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1 bSBHcmlkIDIgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50 IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFt ZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9y ZnVsIEdyaWQgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSIxOSIgUUZvcm1hdD0idHJ1ZSINCiAgIE5hbWU9IlN1YnRsZSBFbXBoYXNpcyIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjIxIiBRRm9ybWF0PSJ0 cnVlIg0KICAgTmFtZT0iSW50ZW5zZSBFbXBoYXNpcyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMxIiBRRm9ybWF0PSJ0cnVlIg0KICAgTmFtZT0iU3VidGxl IFJlZmVyZW5jZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjMyIiBRRm9ybWF0PSJ0cnVlIg0KICAgTmFtZT0iSW50ZW5zZSBSZWZlcmVuY2UiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzMyIgUUZvcm1hdD0idHJ1ZSIg TmFtZT0iQm9vayBUaXRsZSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjM3IiBTZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h bWU9IkJpYmxpb2dyYXBoeSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIg0KICAgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFG b3JtYXQ9InRydWUiIE5hbWU9IlRPQyBIZWFkaW5nIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDEiIE5hbWU9IlBsYWluIFRhYmxlIDEiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0MiIgTmFtZT0iUGxhaW4gVGFibGUg MiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQzIiBOYW1l PSJQbGFpbiBUYWJsZSAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDQiIE5hbWU9IlBsYWluIFRhYmxlIDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI0NSIgTmFtZT0iUGxhaW4gVGFibGUgNSIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQwIiBOYW1lPSJHcmlkIFRhYmxlIExp Z2h0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5h bWU9IkdyaWQgVGFibGUgMSBMaWdodCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJHcmlkIFRhYmxlIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIi8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFi bGUgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBO YW1lPSJHcmlkIFRhYmxlIDUgRGFyayIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3 IENvbG9yZnVsIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NDYiDQogICBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFj Y2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgi IE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2Vk PSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDEiLz4NCiAg PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBU YWJsZSA1IERhcmsgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI1MSINCiAgIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgMSIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIg0KICAgTmFt ZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiDQogICBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQg QWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0 NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2Nr ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgMiIvPg0K ICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlk IFRhYmxlIDQgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy aW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDIiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSINCiAgIE5hbWU9IkdyaWQgVGFi bGUgNiBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjUyIg0KICAgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAy Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiDQogICBO YW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCAzIi8+ DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikdy aWQgVGFibGUgMyBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg UHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhj ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERh cmsgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI1MSINCiAgIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIg0KICAgTmFtZT0iR3JpZCBU YWJsZSA3IENvbG9yZnVsIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDYiDQogICBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50IDQi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0i R3JpZCBUYWJsZSAyIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl IiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgNCIvPg0KICA8dzpMc2RF eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQg QWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1 MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSINCiAgIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xv cmZ1bCBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjUyIg0KICAgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA0Ii8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiDQogICBOYW1lPSJHcmlk IFRhYmxlIDEgTGlnaHQgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJsZSAyIEFjY2VudCA1Ii8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUg MyBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9 IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExv Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50 IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSINCiAg IE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRp b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIg0KICAgTmFtZT0iR3JpZCBUYWJsZSA3IENv bG9yZnVsIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv cml0eT0iNDYiDQogICBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50IDYiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3JpZCBUYWJs ZSAyIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNjZW50IDYi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0i R3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI1MSINCiAgIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCBBY2Nl bnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIg0K ICAgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2Vw dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdo dCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1l PSJMaXN0IFRhYmxlIDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI0OCIgTmFtZT0iTGlzdCBUYWJsZSAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFy ayIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1l PSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiDQogICBOYW1lPSJMaXN0IFRh YmxlIDEgTGlnaHQgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4 Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBB Y2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5 IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDEiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tl ZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDEi Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSINCiAgIE5h bWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgMSIvPg0KICA8dzpMc2RFeGNlcHRpb24g TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIg0KICAgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9y ZnVsIEFjY2VudCAxIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0 eT0iNDYiDQogICBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDIiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAy IEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i NDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgMiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9j a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDIiLz4N CiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlz dCBUYWJsZSA1IERhcmsgQWNjZW50IDIiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs c2UiIFByaW9yaXR5PSI1MSINCiAgIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQg MiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIg0KICAg TmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAyIi8+DQogIDx3OkxzZEV4Y2VwdGlv biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiDQogICBOYW1lPSJMaXN0IFRhYmxlIDEgTGln aHQgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFjY2VudCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBM b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgMyIv Pg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJM aXN0IFRhYmxlIDQgQWNjZW50IDMiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui IFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDMiLz4NCiAgPHc6 THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSINCiAgIE5hbWU9Ikxpc3Qg VGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgMyIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm YWxzZSIgUHJpb3JpdHk9IjUyIg0KICAgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2Vu dCAzIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiDQog ICBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFjY2VudCA0 Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9 Ikxpc3QgVGFibGUgMyBBY2NlbnQgNCIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz ZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDQiLz4NCiAgPHc6THNk RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1 IERhcmsgQWNjZW50IDQiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y aXR5PSI1MSINCiAgIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNCIvPg0KICA8 dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIg0KICAgTmFtZT0iTGlz dCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA0Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9 ImZhbHNlIiBQcmlvcml0eT0iNDYiDQogICBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50 IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFt ZT0iTGlzdCBUYWJsZSAyIEFjY2VudCA1Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh bHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgNSIvPg0KICA8dzpM c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxl IDQgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5 PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNjZW50IDUiLz4NCiAgPHc6THNkRXhjZXB0 aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSINCiAgIE5hbWU9Ikxpc3QgVGFibGUgNiBD b2xvcmZ1bCBBY2NlbnQgNSIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp b3JpdHk9IjUyIg0KICAgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA1Ii8+DQog IDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiDQogICBOYW1lPSJM aXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFjY2VudCA2Ii8+DQogIDx3 OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9Ikxpc3QgVGFi bGUgMyBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp dHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9u IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsgQWNj ZW50IDYiLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIN CiAgIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNiIvPg0KICA8dzpMc2RFeGNl cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIg0KICAgTmFtZT0iTGlzdCBUYWJsZSA3 IENvbG9yZnVsIEFjY2VudCA2Ii8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9Ik1lbnRpb24i Lz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu aGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0iU21hcnQgSHlwZXJsaW5rIi8+DQogIDx3Okxz ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl ZD0idHJ1ZSINCiAgIE5hbWU9Ikhhc2h0YWciLz4NCiAgPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIg0KICAgTmFtZT0i VW5yZXNvbHZlZCBNZW50aW9uIi8+DQogIDx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSINCiAgIE5hbWU9IlNtYXJ0IExp bmsiLz4NCiA8L3c6TGF0ZW50U3R5bGVzPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUg bXNvIDEwXT4NCjxzdHlsZT4NCiAvKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHRhYmxlLk1zb05v cm1hbFRhYmxlDQoJe21zby1zdHlsZS1uYW1lOiJUYWJsZSBOb3JtYWwiOw0KCW1zby10c3R5bGUt cm93YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1jb2xiYW5kLXNpemU6MDsNCgltc28tc3R5bGUt bm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLXBhcmVudDoi IjsNCgltc28tcGFkZGluZy1hbHQ6MGluIDUuNHB0IDBpbiA1LjRwdDsNCgltc28tcGFyYS1tYXJn aW46MGluOw0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1hc2NpaS1mb250LWZh bWlseTpDYWxpYnJpOw0KCW1zby1hc2NpaS10aGVtZS1mb250Om1pbm9yLWxhdGluOw0KCW1zby1o YW5zaS1mb250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1oYW5zaS10aGVtZS1mb250Om1pbm9yLWxh dGluOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCW1zby1iaWRp LXRoZW1lLWZvbnQ6bWlub3ItYmlkaTt9DQo8L3N0eWxlPg0KPCFbZW5kaWZdLS0+PCEtLVN0YXJ0 RnJhZ21lbnQtLT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDEwcHQ7IGZvbnQtZmFtaWx5OiBWZXJkYW5hLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+SSB3b3Vs ZCBsaWtlIHRvIGV4cHJlc3MgbXkgc3VwcG9ydCBmb3IgdGhlJm5ic3A7Q29tcHJlc3NlZCBTUnY2 IFNlZ21lbnQgTGlzdCBFbmNvZGluZyBpbiBTUkggZHJhZnQuICZuYnNwO0FzIGFuIGFyY2hpdGVj dCBmb3Igb25lIG9mIHRoZSB3b3JsZOKAmXMgbGFyZ2VzdCBTb2x1dGlvbnMgcHJvdmlkZXJzLA0K IHdlIGhhdmUgcXVpdGUgYSBiaXQgb2YgaW50ZXJlc3QgaW4gdGhpcyBzb2x1dGlvbi4gJm5ic3A7 SSBoYXZlIGJlZW4gaW52b2x2ZWQgaW4gU1Igc2luY2UgMjAxMyBhbmQgaGF2ZSBiZWVuIGZvbGxv d2luZyBTUnY2IGltcGxlbWVudGF0aW9uIGZvciBxdWl0ZSBhIHdoaWxlLiAmbmJzcDtOb3Qgb25s eSBpcyB0aGlzIHNvbHV0aW9uIGVsZWdhbnQgYW5kIHN0cmFpZ2h0Zm9yd2FyZCwgYnV0IHdlbGwg bmVlZGVkLiBJIGVuY291cmFnZSB0aGUgSUVURiB0byBhZG9wdCB0aGlzDQogZHJhZnQgZm9yIGEg cHJvcG9zZWQgc3RhbmRhcmQuICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmOw0KbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwv bzpwPjwvc3Bhbj48L3A+DQo8IS0tRW5kRnJhZ21lbnQtLT4mbmJzcDs8YnIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9ImF1dG8iIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAs IDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogVmVyZGFuYTsgZm9udC1z aXplOiAxM3B4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr aXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFz cz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7 IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7 IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hLCBWZXJkYW5hOyBm b250LXNpemU6IDEzcHg7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IiBjbGFzcz0iIj4NCjxkaXYgZGly PSJhdXRvIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyB3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1t b2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxk aXYgZGlyPSJhdXRvIiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxM3B4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZm9u dC1mYW1pbHk6IFZlcmRhbmEsIFZlcmRhbmE7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtp dC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNz PSIiPg0KPGRpdiBkaXI9ImF1dG8iIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJr aXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFz cz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Vi a2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1t b2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNl OyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i d29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJl YWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXIt d2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29y ZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0 LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2Rl OiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBs aW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29y ZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6 IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJy ZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hp dGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsi IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5i c3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBz cGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IiIgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNw YWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBjbGFzcz0iIiBzdHls ZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUt YnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7Ij4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdh dHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1udW1lcmljOiBub3JtYWw7IGZvbnQtdmFyaWFudC1hbHRlcm5hdGVzOiBub3JtYWw7IGZvbnQt dmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7Ij4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9ImZvbnQt dmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1udW1lcmljOiBub3JtYWw7IGZvbnQtdmFyaWFudC1hbHRlcm5hdGVzOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7Ij4NCjxkaXYgY2xhc3M9IiIg c3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBs aW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0id29y ZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6 IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJ3b3JkLXdyYXA6IGJy ZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hp dGUtc3BhY2U7Ij4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVyZXM6 IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWw7IGZvbnQtdmFyaWFudC1udW1l cmljOiBub3JtYWw7IGZvbnQtdmFyaWFudC1hbHRlcm5hdGVzOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1lYXN0LWFzaWFuOiBub3JtYWw7Ij4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9ImZvbnQtZmFtaWx5 OiBWZXJkYW5hOyBmb250LXNpemU6IDE0cHg7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1h bDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWw7IGZvbnQtdmFyaWFudC1udW1lcmljOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1hbHRlcm5hdGVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0 LWFzaWFuOiBub3JtYWw7Ij4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdh dHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1udW1lcmljOiBub3JtYWw7IGZvbnQtdmFyaWFudC1hbHRlcm5hdGVzOiBub3JtYWw7IGZvbnQt dmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7Ij4NCjxkaXYgY2xhc3M9IiIgc3R5bGU9ImZvbnQt c2l6ZTogMTNweDsgZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQt cG9zaXRpb246IG5vcm1hbDsgZm9udC12YXJpYW50LW51bWVyaWM6IG5vcm1hbDsgZm9udC12YXJp YW50LWFsdGVybmF0ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsi Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBm b250LXZhcmlhbnQtcG9zaXRpb246IG5vcm1hbDsgZm9udC12YXJpYW50LW51bWVyaWM6IG5vcm1h bDsgZm9udC12YXJpYW50LWFsdGVybmF0ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNp YW46IG5vcm1hbDsiPg0KPGRpdiBkaXI9ImF1dG8iIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3Bh Y2U7IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0id29yZC13cmFwOiBicmVhay13 b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNw YWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9IndvcmQtd3JhcDogYnJlYWst d29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBkaXI9ImF1dG8iIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFr LXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUt c3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgZGlyPSJhdXRvIiBzdHlsZT0id29yZC13cmFwOiBicmVh ay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0iYXV0byIgc3R5bGU9IndvcmQtd3JhcDogYnJl YWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0 ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAt d2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJz cC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNw YWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUt YnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWst d29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1z cGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Vi a2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xh c3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1t b2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNl OyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i d29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJl YWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6 IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXIt d2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29y ZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFj ZTsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0 LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9 IiI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQt bmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7Ij4NCjxkaXYg Y2xhc3M9IiIgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6 IHNwYWNlOyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBjbGFzcz0iIiBz dHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxp bmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJmb250 LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFs OyBmb250LXZhcmlhbnQtbnVtZXJpYzogbm9ybWFsOyBmb250LXZhcmlhbnQtYWx0ZXJuYXRlczog bm9ybWFsOyBmb250LXZhcmlhbnQtZWFzdC1hc2lhbjogbm9ybWFsOyI+DQo8ZGl2IGNsYXNzPSIi IHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3Np dGlvbjogbm9ybWFsOyBmb250LXZhcmlhbnQtbnVtZXJpYzogbm9ybWFsOyBmb250LXZhcmlhbnQt YWx0ZXJuYXRlczogbm9ybWFsOyBmb250LXZhcmlhbnQtZWFzdC1hc2lhbjogbm9ybWFsOyI+DQo8 ZGl2IGNsYXNzPSIiIHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1t b2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7Ij4NCjxkaXYgY2xhc3M9 IiIgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNl OyBsaW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0i d29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IGxpbmUtYnJl YWs6IGFmdGVyLXdoaXRlLXNwYWNlOyI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJmb250LXZhcmlh bnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBmb250 LXZhcmlhbnQtbnVtZXJpYzogbm9ybWFsOyBmb250LXZhcmlhbnQtYWx0ZXJuYXRlczogbm9ybWFs OyBmb250LXZhcmlhbnQtZWFzdC1hc2lhbjogbm9ybWFsOyI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxl PSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjog bm9ybWFsOyBmb250LXZhcmlhbnQtbnVtZXJpYzogbm9ybWFsOyBmb250LXZhcmlhbnQtYWx0ZXJu YXRlczogbm9ybWFsOyBmb250LXZhcmlhbnQtZWFzdC1hc2lhbjogbm9ybWFsOyI+DQo8ZGl2IGNs YXNzPSIiIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1wb3NpdGlvbjogbm9ybWFsOyBmb250LXZhcmlhbnQtbnVtZXJpYzogbm9ybWFsOyBmb250LXZh cmlhbnQtYWx0ZXJuYXRlczogbm9ybWFsOyBmb250LXZhcmlhbnQtZWFzdC1hc2lhbjogbm9ybWFs OyI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBmb250LXZhcmlhbnQtbnVtZXJpYzogbm9y bWFsOyBmb250LXZhcmlhbnQtYWx0ZXJuYXRlczogbm9ybWFsOyBmb250LXZhcmlhbnQtZWFzdC1h c2lhbjogbm9ybWFsOyI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1 cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBmb250LXZhcmlhbnQt bnVtZXJpYzogbm9ybWFsOyBmb250LXZhcmlhbnQtYWx0ZXJuYXRlczogbm9ybWFsOyBmb250LXZh cmlhbnQtZWFzdC1hc2lhbjogbm9ybWFsOyI+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJmb250LXZh cmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBm b250LXZhcmlhbnQtbnVtZXJpYzogbm9ybWFsOyBmb250LXZhcmlhbnQtYWx0ZXJuYXRlczogbm9y bWFsOyBmb250LXZhcmlhbnQtZWFzdC1hc2lhbjogbm9ybWFsOyI+DQo8Zm9udCBjbGFzcz0iIj48 YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0i IiBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtcG9z aXRpb246IG5vcm1hbDsgZm9udC12YXJpYW50LW51bWVyaWM6IG5vcm1hbDsgZm9udC12YXJpYW50 LWFsdGVybmF0ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsiPg0K PGZvbnQgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9mb250PjwvZGl2Pg0KPGRpdiBjbGFzcz0i IiBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtcG9z aXRpb246IG5vcm1hbDsgZm9udC12YXJpYW50LW51bWVyaWM6IG5vcm1hbDsgZm9udC12YXJpYW50 LWFsdGVybmF0ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsiPg0K PGRpdiBjbGFzcz0iIiBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250 LXZhcmlhbnQtcG9zaXRpb246IG5vcm1hbDsgZm9udC12YXJpYW50LW51bWVyaWM6IG5vcm1hbDsg Zm9udC12YXJpYW50LWFsdGVybmF0ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46 IG5vcm1hbDsiPg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczog bm9ybWFsOyBmb250LXZhcmlhbnQtcG9zaXRpb246IG5vcm1hbDsgZm9udC12YXJpYW50LW51bWVy aWM6IG5vcm1hbDsgZm9udC12YXJpYW50LWFsdGVybmF0ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50 LWVhc3QtYXNpYW46IG5vcm1hbDsiPg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0iZm9udC12YXJpYW50 LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtcG9zaXRpb246IG5vcm1hbDsgZm9udC12 YXJpYW50LW51bWVyaWM6IG5vcm1hbDsgZm9udC12YXJpYW50LWFsdGVybmF0ZXM6IG5vcm1hbDsg Zm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsiPg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0i Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtcG9zaXRpb246IG5v cm1hbDsgZm9udC12YXJpYW50LW51bWVyaWM6IG5vcm1hbDsgZm9udC12YXJpYW50LWFsdGVybmF0 ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsiPg0KPGRpdiBjbGFz cz0iIiBzdHlsZT0iZm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQt cG9zaXRpb246IG5vcm1hbDsgZm9udC12YXJpYW50LW51bWVyaWM6IG5vcm1hbDsgZm9udC12YXJp YW50LWFsdGVybmF0ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsi Pg0KPGZvbnQgY2xhc3M9IiI+PHNwYW4gY2xhc3M9IiIgc3R5bGU9ImNvbG9yOiByZ2IoMTk4LCAy NywgMCk7IGZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0 aW9uOiBub3JtYWw7IGZvbnQtdmFyaWFudC1udW1lcmljOiBub3JtYWw7IGZvbnQtdmFyaWFudC1h bHRlcm5hdGVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1lYXN0LWFzaWFuOiBub3JtYWw7Ij48c3Bh biBjbGFzcz0iIj48YiBjbGFzcz0iIj5NaWtlIERpVmluY2Vuem88L2I+PC9zcGFuPjwvc3Bhbj48 L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVz OiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBmb250LXZhcmlhbnQtbnVt ZXJpYzogbm9ybWFsOyBmb250LXZhcmlhbnQtYWx0ZXJuYXRlczogbm9ybWFsOyBmb250LXZhcmlh bnQtZWFzdC1hc2lhbjogbm9ybWFsOyI+DQo8Zm9udCBjbGFzcz0iIj48Zm9udCBjb2xvcj0iIzAw MmU3YSIgY2xhc3M9IiI+PGZvbnQgY2xhc3M9IiIgc3R5bGU9ImZvbnQtdmFyaWFudC1saWdhdHVy ZXM6IG5vcm1hbDsgZm9udC12YXJpYW50LXBvc2l0aW9uOiBub3JtYWw7IGZvbnQtdmFyaWFudC1u dW1lcmljOiBub3JtYWw7IGZvbnQtdmFyaWFudC1hbHRlcm5hdGVzOiBub3JtYWw7IGZvbnQtdmFy aWFudC1lYXN0LWFzaWFuOiBub3JtYWw7Ij5UZWNobmljYWwmbmJzcDs8L2ZvbnQ+PHNwYW4gY2xh c3M9IiI+U29sdXRpb25zDQogQXJjaGl0ZWN0Jm5ic3A7PC9zcGFuPjwvZm9udD48L2ZvbnQ+PHNw YW4gc3R5bGU9ImNvbG9yOiByZ2IoMCwgNDYsIDEyMik7IiBjbGFzcz0iIj4oTVBMUy9TUik8L3Nw YW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBu b3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFsOyBmb250LXZhcmlhbnQtbnVtZXJp Yzogbm9ybWFsOyBmb250LXZhcmlhbnQtYWx0ZXJuYXRlczogbm9ybWFsOyBmb250LXZhcmlhbnQt ZWFzdC1hc2lhbjogbm9ybWFsOyI+DQo8Zm9udCBjbGFzcz0iIiBjb2xvcj0iIzAwMmU3YSI+V29y bGQgV2lkZSBUZWNobm9sb2d5Jm5ic3A7PGZvbnQgY2xhc3M9IiI+fCBHbG9iYWwgRW5naW5lZXJp bmc8L2ZvbnQ+PGJyIGNsYXNzPSIiPg0KPC9mb250Pg0KPGRpdiBjbGFzcz0iIiBzdHlsZT0iZm9u dC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsOyBmb250LXZhcmlhbnQtcG9zaXRpb246IG5vcm1h bDsgZm9udC12YXJpYW50LW51bWVyaWM6IG5vcm1hbDsgZm9udC12YXJpYW50LWFsdGVybmF0ZXM6 IG5vcm1hbDsgZm9udC12YXJpYW50LWVhc3QtYXNpYW46IG5vcm1hbDsiPg0KPGZvbnQgY29sb3I9 IiMwMDJlN2EiIGNsYXNzPSIiPk9mZmljZTogOTgwLjI3My43OTAxICZuYnNwO3wgJm5ic3A7TW9i aWxlOiA5MTkuNzQxLjgzMTQ8L2ZvbnQ+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiIHN0eWxlPSJmb250 LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7IGZvbnQtdmFyaWFudC1wb3NpdGlvbjogbm9ybWFs OyBmb250LXZhcmlhbnQtbnVtZXJpYzogbm9ybWFsOyBmb250LXZhcmlhbnQtYWx0ZXJuYXRlczog bm9ybWFsOyBmb250LXZhcmlhbnQtZWFzdC1hc2lhbjogbm9ybWFsOyI+DQo8Zm9udCBjb2xvcj0i IzAwMmU3YSIgY2xhc3M9IiI+RW1haWw6Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOm1pa2UuZGl2aW5j ZW56b0B3d3QuY29tIiBjbGFzcz0iIj5taWtlLmRpdmluY2Vuem9Ad3d0LmNvbTwvYT4mbmJzcDsg fCAmbmJzcDtDQ0lFICM5MzU4PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFu Z2UtbmV3bGluZSIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2Io MCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBWZXJkYW5hOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRp b246IG5vbmU7Ij4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSIgc3R5bGU9 ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBWZXJkYW5hOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij4NCjwvZGl2 Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IiI+T24gT2N0IDEsIDIwMjEsIGF0IDEwOjA1IEFNLCBKYW1lcyBHdWljaGFy ZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbSIgY2xh c3M9IiI+amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+ DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsgY2Fy ZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IFZlcmRhbmE7IGZvbnQtc2l6ZTog MTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4N CkRlYXIgV0c6PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IiBjbGFzcz0iIj4NClRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBleHByZXNzIHRoZWly IGFwcHJlY2lhdGlvbiBmb3IgYWxsIHRoZSByZXNwb25zZXMgcmVjZWl2ZWQgdG8gb3VyIGVtYWls cyB3aXRoIHJlZmVyZW5jZSB0byBob3cgdGhlIHdvcmtpbmcgZ3JvdXAgd2lzaGVzIHRvIG1vdmUg Zm9yd2FyZCB3aXRoIHJlc3BlY3QgdG8gYSBzb2x1dGlvbiBmb3IgU1J2NiBjb21wcmVzc2lvbi48 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFz cz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNs YXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4N ClRoZSBhcHBhcmVudCBpbmNsaW5hdGlvbiBvZiB0aGUgd29ya2luZyBncm91cCBpcyB0byB1c2U8 c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJp bmctc3J2Ni1zcmgtY29tcHJlc3Npb24vIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lv bi88L2E+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmFz DQogdGhlIGJhc2lzIGZvciBpdHMgY29tcHJlc3Npb24gc3RhbmRhcmRpemF0aW9uIHdvcmsuIFRo YXQgaXMgcGFydCBvZiB3aGF0IHRoaXMgZW1haWwgYXR0ZW1wdHMgdG8gY29uZmlybS48bzpwIGNs YXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAg Y2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbjsgZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIi Pg0KQmVjYXVzZSBvZiB0aGUgYWJvdmUgdGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGlzc3VlIGEg Mi13ZWVrIFdHIGNhbGwgZm9yIGFkb3B0aW9uIGVuZGluZyBPY3RvYmVyIDE1PHN1cCBjbGFzcz0i Ij50aDwvc3VwPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5mb3I8c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVu Zy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vIiBjbGFzcz0iIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21w cmVzc2lvbi88L2E+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPmJ1dA0KIHdpdGggc29tZSBjbGVhciBndWlkZWxpbmVzIGFzIGZvbGxvd3MuIEJ5IGV4cHJl c3Npbmcgc3VwcG9ydCBmb3IgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCB5b3UgYXJlIGZ1bGx5 IGF3YXJlIG9mIGFuZCBhcmUgYWNrbm93bGVkZ2luZyB0aGF0OjxzcGFuIGNsYXNzPSJBcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+ PC9kaXY+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9IjEiIHN0eWxlPSJtYXJnaW4tYm90dG9tOiAwaW47 IG1hcmdpbi10b3A6IDBpbjsiIGNsYXNzPSIiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7Ij4NClRoZSBTUFJJTkcgd29ya2luZyBncm91cCBpcyBhZG9wdGluZyBh IGRvY3VtZW50IHRoYXQgaGFzIG11bHRpcGxlIFNSdjYgRW5kcG9pbnQgYmVoYXZpb3JzLjxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIi PjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luOiAw aW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4N ClRoZSBkb2N1bWVudCBpcyBhIOKAnGxpdmluZ+KAnSBkb2N1bWVudDsgaXQgbWF5IGNoYW5nZSBh cyBpdCBnb2VzIHRocm91Z2ggcmV2aWV3IGFuZCBhbmFseXNpcyBieSB0aGUgU1BSSU5HIHdvcmtp bmcgZ3JvdXAuPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW46IDBpbjsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwg c2Fucy1zZXJpZjsiPg0KQWxsIG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgcmFpc2VkIG9uIG91ciBt YWlsaW5nIGxpc3QgTVVTVCBiZSBhZGRyZXNzZWQgQkVGT1JFIHNhaWQgZG9jdW1lbnQgaXMgYWxs b3dlZCB0byBwcm9ncmVzcyBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIHRvIHB1YmxpY2F0aW9uLiBB IGxpc3Qgb2YgdGhlc2UgZGlzY3Vzc2lvbiBwb2ludHMgd2lsbCBiZSBkb2N1bWVudGVkIGluIHRo ZSBXRyBkb2N1bWVudCBhbmQgbWFpbnRhaW5lZCBieSB0aGUgZG9jdW1lbnQNCiBlZGl0b3IgaW4g Y29uanVuY3Rpb24gd2l0aCB0aGUgY2hhaXJzLjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCklmIHRoaXMgZG9jdW1lbnQgaXMgYWRv cHRlZCBieSB0aGUgd29ya2luZyBncm91cCwgdGhlIGNoYWlycyBzcGVjaWZ5IGFzIHBhcnQgb2Yg dGhlIGFkb3B0aW9uIGNhbGwgdGhhdCB0aGUgZm9sbG93aW5nIHRleHQgZGVzY3JpYmluZyBhbiBv cGVuIGlzc3VlIGJlIGFkZGVkIHRvIHRoZSBkb2N1bWVudCBpbiB0aGUgYWJvdmUtZGVzY3JpYmVk IG9wZW4gaXNzdWVzIHNlY3Rpb246PG86cCBjbGFzcz0iIj48L286cD48L2xpPjx1bCB0eXBlPSJk aXNjIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTogMGluOyBtYXJnaW4tdG9wOiAwaW47IiBjbGFzcz0i Ij4NCjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCiZxdW90O0dpdmVu IHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHNhaWQgdGhhdCBpdCB3YW50cyB0byBzdGFuZGFy ZGl6ZSBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiwgYW5kIGdpdmVuIHRoYXQgdGhlIGRvY3VtZW50 IGNvbnRhaW5zIG11bHRpcGxlIFNSdjYgRW5kUG9pbnQgYmVoYXZpb3JzIHRoYXQgc29tZSBXRyBt ZW1iZXJzIGhhdmUgc3RhdGVkIGFyZSBtdWx0aXBsZSBkYXRhIHBsYW5lIHNvbHV0aW9ucywgdGhl IHdvcmtpbmcgZ3JvdXAgd2lsbCBhZGRyZXNzDQogd2hldGhlciB0aGlzIGlzIHZhbGlkIGFuZCBj b2hlcmVudCB3aXRoIGl0cyBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiBvYmplY3RpdmUuJnF1b3Q7 LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9saT48L3VsPg0KPC9vbD4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IiBjbGFzcz0iIj4NClBsZWFzZSBjb25zaWRlciB0aGUgYWJvdmUgZ3VpZGVsaW5l cyBhcyB5b3UgZGVjaWRlIG9uIHdoZXRoZXIgdG8gc3VwcG9ydCBvciBub3QgdGhpcyBXRyBhZG9w dGlvbi4gUGxlYXNlIGV4cHJlc3MgY2xlYXJseSB5b3VyIHJlYXNvbmluZyBmb3Igc3VwcG9ydC9u b24tc3VwcG9ydCBhcyB3ZWxsIGFzIGFueSBvcGVuIGRpc2N1c3Npb24gcG9pbnRzIHlvdSB3b3Vs ZCBsaWtlIGFkZHJlc3NlZCBzaG91bGQgdGhlIGRvY3VtZW50IGJlIGFkb3B0ZWQgaW50bw0KIHRo ZSB3b3JraW5nIGdyb3VwLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbjsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQpUaGFua3MhPG86cCBjbGFzcz0iIj48L286cD48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwv bzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW47IGZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCkppbSwgQnJ1bm8gJmFt cDsgSm9lbDxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp bjsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiIGNs YXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1h cmdpbjogMGluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPC9kaXY+ DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IFZl cmRhbmE7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRp c3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogVmVyZGFuYTsgZm9udC1zaXplOiAxM3B4OyBmb250 LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNv cmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IFZlcmRhbmE7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1zdHls ZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFs OyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6 IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3Bh Y2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlv bjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9 IiI+c3ByaW5nDQogbWFpbGluZyBsaXN0PC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IFZlcmRhbmE7IGZvbnQtc2l6ZTogMTNweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9y bWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRl bnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3Jh dGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIg c3R5bGU9ImZvbnQtZmFtaWx5OiBWZXJkYW5hOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1h ZGp1c3Q6IGF1dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPnNw cmluZ0BpZXRmLm9yZzwvYT48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiBWZXJkYW5hOyBmb250LXNpemU6IDEzcHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBj bGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3ByaW5nIiBzdHlsZT0iZm9udC1mYW1pbHk6IFZlcmRhbmE7IGZvbnQtc2l6ZTogMTNweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xh c3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8L2E+PC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_8BA8291FD97B4ED48200EBCADB98B8B2wwtcom_-- From francesco.lombardo@uniroma2.it Tue Oct 12 00:52:38 2021 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 CB8DA3A0E13; Tue, 12 Oct 2021 00:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.613 X-Spam-Level: X-Spam-Status: No, score=0.613 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FORGED_MUA_MOZILLA=2.309, HTML_MESSAGE=0.001, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=uniroma2.it header.b=Ol25rzCC; dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=uniroma2.it header.b=JKgU1gma 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 kp6tsRCjLX1A; Tue, 12 Oct 2021 00:52:33 -0700 (PDT) Received: from smtp.uniroma2.it (smtp.uniroma2.it [160.80.6.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 41B6E3A0A65; Tue, 12 Oct 2021 00:52:30 -0700 (PDT) Received: from smtpauth-2019-1.uniroma2.it (smtpauth.uniroma2.it [160.80.5.46]) by smtp-2015.uniroma2.it (8.14.4/8.14.4/Debian-8) with ESMTP id 19C7qIiX023666; Tue, 12 Oct 2021 09:52:23 +0200 Message-Id: <202110120752.19C7qIiX023666@smtp-2015.uniroma2.it> Received: from [192.168.1.17] (host-82-51-160-12.retail.telecomitalia.it [82.51.160.12]) by smtpauth-2019-1.uniroma2.it (Postfix) with ESMTPSA id 6A081120092; Tue, 12 Oct 2021 09:52:13 +0200 (CEST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=uniroma2.it; s=ed201904; t=1634025133; h=from:from:sender:reply-to:subject:subject:date:date:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=9iqYp/Cw3L1l86n5NW11OmBJAtwazqI3v1T2DTzjcr8=; b=Ol25rzCCdKrPLIGaa7c+/RjvTLebxPzfE912gz/zwgH7afps4Btk1nl8HqWvns5wGhQTDO pBcpUoi/pfIQ48DA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniroma2.it; s=rsa201904; t=1634025133; h=from:from:sender:reply-to:subject:subject:date:date:message-id:to:to: cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=9iqYp/Cw3L1l86n5NW11OmBJAtwazqI3v1T2DTzjcr8=; b=JKgU1gma7jhKlih4anBvMmOH9S+vWdVeWruhuex8l+IepzzQ5qMrf8JTOE7y3I7evk61u9 dBJbdQY9RByfVGQtTeYmOvVS5phx6e9lIoVCPNZlSFkFq3IcKlrMRU4K/FQXVIhTAbVan0 JUIlXTQ3NX6umNdQNUL8RyAD5GK47bLatfVAxyvuSAPkEiGmmXn4nVlnmSOU1KdV8796Cp BGpZa6pPRkyDWxq5czngd2td31ZV0eOeUmlEuvq4Tj7Kw3ICGheOoGl5o1QUO1afnzoPNr J2C0iPqg7DKUeLYucTMdHaRZTjY+Ic6XLLFvJCvljumVIT6+CYzAgl0IYHL4VA== To: James Guichard , SPRING WG Cc: "spring-chairs@ietf.org" References: From: Francesco Lombardo Date: Tue, 12 Oct 2021 09:52:12 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1D385618594D0860523DD59A" Content-Language: en-US X-Virus-Scanned: clamav-milter 0.100.0 at smtp-2015 X-Virus-Status: Clean Archived-At: X-Mailman-Approved-At: Tue, 12 Oct 2021 02:44:26 -0700 Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 12 Oct 2021 07:55:42 -0000 This is a multi-part message in MIME format. --------------1D385618594D0860523DD59A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi WG, I support the adoption of CSID draft. I have been working on developing a Kubernetes network datapath solution using the SRv6 network programming defined in RFC8986. I would like to thank the DT team for the hard work over the past months. The DT analysis doc shows the CSID solution outperforms other options and is based on the SRv6 data plane. CSID defines two new flavors (next and replace) in the same way as the flavors defined in RFC8986. Thanks Francesco On 01/10/21 16:04, James Guichard wrote: > > Dear WG: > > The chairs would like to express their appreciation for all the > responses received to our emails with reference to how the working > group wishes to move forward with respect to a solution for SRv6 > compression. > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > as the basis for its compression standardization work. That is part of > what this email attempts to confirm. > > Because of the above the chairs would like to issue a 2-week WG call > for adoption ending October 15^th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging > that: > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a “living” document; it may change as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the > working group to publication. A list of these discussion points > will be documented in the WG document and maintained by the > document editor in conjunction with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text > describing an open issue be added to the document in the > above-described open issues section: > * "Given that the working group has said that it wants to > standardize one data plane solution, and given that the > document contains multiple SRv6 EndPoint behaviors that some > WG members have stated are multiple data plane solutions, the > working group will address whether this is valid and coherent > with its one data plane solution objective.". > > Please consider the above guidelines as you decide on whether to > support or not this WG adoption. Please express clearly your reasoning > for support/non-support as well as any open discussion points you > would like addressed should the document be adopted into the working > group. > > Thanks! > > Jim, Bruno & Joel > --------------1D385618594D0860523DD59A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

    Hi WG,

    I support the adoption of CSID draft.

    I have been working on developing a Kubernetes network datapath solution using the SRv6 network programming defined in RFC8986.
    I would like to thank the DT team for the hard work over the past months.
    The DT analysis doc shows the CSID solution outperforms other options and is based on the SRv6 data plane.

    CSID defines two new flavors (next and replace) in the same way as the flavors defined in RFC8986.

    Thanks
    Francesco

    On 01/10/21 16:04, James Guichard wrote:

    Dear WG:

     

    The chairs would like to express their appreciation for all the responses received to our emails with reference to how the working group wishes to move forward with respect to a solution for SRv6 compression.

     

    The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardization work. That is part of what this email attempts to confirm.

     

    Because of the above the chairs would like to issue a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that:

     

    1. The SPRING working group is adopting a document that has multiple SRv6 Endpoint behaviors.
    2. The document is a “living” document; it may change as it goes through review and analysis by the SPRING working group.
    3. All open discussion points raised on our mailing list MUST be addressed BEFORE said document is allowed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maintained by the document editor in conjunction with the chairs.
    4. If this document is adopted by the working group, the chairs specify as part of the adoption call that the following text describing an open issue be added to the document in the above-described open issues section:
      • "Given that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this is valid and coherent with its one data plane solution objective.".

     

    Please consider the above guidelines as you decide on whether to support or not this WG adoption. Please express clearly your reasoning for support/non-support as well as any open discussion points you would like addressed should the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    --------------1D385618594D0860523DD59A-- From marco.bonola@uniroma2.it Tue Oct 12 02:21:39 2021 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 88C2A3A1225; Tue, 12 Oct 2021 02:21:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=uniroma2.it header.b=SAJHjDQa; dkim=pass (2048-bit key) header.d=uniroma2.it header.b=KjKAcZka 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 q84NZcui5TzS; Tue, 12 Oct 2021 02:21:32 -0700 (PDT) Received: from smtp.uniroma2.it (smtp.uniroma2.it [160.80.6.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 AE9C73A11F9; Tue, 12 Oct 2021 02:21:29 -0700 (PDT) Received: from smtpauth-2019-1.uniroma2.it (smtpauth.uniroma2.it [160.80.5.46]) by smtp-2015.uniroma2.it (8.14.4/8.14.4/Debian-8) with ESMTP id 19C9LFu2031459; Tue, 12 Oct 2021 11:21:20 +0200 Received: from [192.168.1.40] (host-79-23-12-198.retail.telecomitalia.it [79.23.12.198]) by smtpauth-2019-1.uniroma2.it (Postfix) with ESMTPSA id C8F371228F4; Tue, 12 Oct 2021 11:21:11 +0200 (CEST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=uniroma2.it; s=ed201904; t=1634030471; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dbaLZJq1nZnIuSEXH334VQ2ZMaq+fEuBZ+all9LSm/4=; b=SAJHjDQaNK/FFg6thp0iqUi+tSeujwgDnH9pQjuXA7FQT3chJylQb1xrmJZt45vu7P+8Ni 5ZgaGg2u2qr7b5Bw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniroma2.it; s=rsa201904; t=1634030471; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dbaLZJq1nZnIuSEXH334VQ2ZMaq+fEuBZ+all9LSm/4=; b=KjKAcZka8OBmiCCe6Jhpat3eSWnuibP/jr6iquNw+x8xduoBxZGyo/ADYrhMSloU+76h3Q Ern4CvwbEYZ5oJYNPwoo54PDTg5IDZmobjU/KwMnNFwWPTY1mLBeoN/yySh8lcTZbm8acG DkFq60IiAvv/ZK9wHjDA/iarom47SHa9hrPKugutePao7dYp5IWVb2pcD+Tsbq+P64RAsh mZ6qKmAx+pbpRASwJiIOr3Vm+RqMT3Xxaw0M8w6exfPK7rH1R2yU/9PwD/WDodGrLOyUYE 3rpxgA97ynJtBxBGCgcXeDFVhbkJTWcJdBO+dP3nDd5yopcid09HCSQUyh5sMQ== Content-Type: multipart/alternative; boundary="------------IMBWlebm20AhlMy5ZR9Wzh9y" Message-ID: Date: Tue, 12 Oct 2021 11:21:11 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.1.2 Content-Language: en-US To: James Guichard , SPRING WG Cc: "spring-chairs@ietf.org" References: From: Marco Bonola In-Reply-To: X-Virus-Scanned: clamav-milter 0.100.0 at smtp-2015 X-Virus-Status: Clean Archived-At: X-Mailman-Approved-At: Tue, 12 Oct 2021 02:44:27 -0700 Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 12 Oct 2021 09:23:32 -0000 This is a multi-part message in MIME format. --------------IMBWlebm20AhlMy5ZR9Wzh9y Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Dear all, I support the adoption of this draft. I am Marco Bonola, senior researcher at CNIT (Italy), and I have recently worked on the SRv6 dataplane in the context of SmartNIC and in-Kernel acceleration. The new flavor designed in this draft compiles with the SRv6 dataplane and can be implemented on top of it, as other flavors defined in RFC8986. Kind regards Marco On 01/10/21 16:04, James Guichard wrote: > > Dear WG: > > The chairs would like to express their appreciation for all the > responses received to our emails with reference to how the working > group wishes to move forward with respect to a solution for SRv6 > compression. > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > as the basis for its compression standardization work. That is part of > what this email attempts to confirm. > > Because of the above the chairs would like to issue a 2-week WG call > for adoption ending October 15^th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging > that: > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a “living” document; it may change as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the > working group to publication. A list of these discussion points > will be documented in the WG document and maintained by the > document editor in conjunction with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text > describing an open issue be added to the document in the > above-described open issues section: > * "Given that the working group has said that it wants to > standardize one data plane solution, and given that the > document contains multiple SRv6 EndPoint behaviors that some > WG members have stated are multiple data plane solutions, the > working group will address whether this is valid and coherent > with its one data plane solution objective.". > > Please consider the above guidelines as you decide on whether to > support or not this WG adoption. Please express clearly your reasoning > for support/non-support as well as any open discussion points you > would like addressed should the document be adopted into the working > group. > > Thanks! > > Jim, Bruno & Joel > --------------IMBWlebm20AhlMy5ZR9Wzh9y Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

    Dear all,

    I support the adoption of this draft.

    I am Marco Bonola, senior researcher at CNIT (Italy), and I have recently worked on the SRv6 dataplane in the context of SmartNIC and in-Kernel acceleration. The new flavor designed in this draft compiles with the SRv6 dataplane and can be implemented on top of it, as other flavors defined in RFC8986. 

    Kind regards

    Marco


    On 01/10/21 16:04, James Guichard wrote:

    Dear WG:

     

    The chairs would like to express their appreciation for all the responses received to our emails with reference to how the working group wishes to move forward with respect to a solution for SRv6 compression.

     

    The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardization work. That is part of what this email attempts to confirm.

     

    Because of the above the chairs would like to issue a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that:

     

    1. The SPRING working group is adopting a document that has multiple SRv6 Endpoint behaviors.
    2. The document is a “living” document; it may change as it goes through review and analysis by the SPRING working group.
    3. All open discussion points raised on our mailing list MUST be addressed BEFORE said document is allowed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maintained by the document editor in conjunction with the chairs.
    4. If this document is adopted by the working group, the chairs specify as part of the adoption call that the following text describing an open issue be added to the document in the above-described open issues section:
      • "Given that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this is valid and coherent with its one data plane solution objective.".

     

    Please consider the above guidelines as you decide on whether to support or not this WG adoption. Please express clearly your reasoning for support/non-support as well as any open discussion points you would like addressed should the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    --------------IMBWlebm20AhlMy5ZR9Wzh9y-- From nobody Tue Oct 12 07:23:23 2021 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 DA73C3A14BD; Tue, 12 Oct 2021 07:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.894 X-Spam-Level: X-Spam-Status: No, score=-0.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 xgpuGgVxgB_O; Tue, 12 Oct 2021 07:23:15 -0700 (PDT) Received: from mail-pg1-f180.google.com (mail-pg1-f180.google.com [209.85.215.180]) (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 ACC633A14B9; Tue, 12 Oct 2021 07:23:12 -0700 (PDT) Received: by mail-pg1-f180.google.com with SMTP id m21so14013225pgu.13; Tue, 12 Oct 2021 07:23:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-transfer-encoding; bh=6cSkpScSlU5uSzEjdEMrT0cP3hZvkqvTw0sF2TLtvZ4=; b=NvWH+0lJiOKA43kPBUE+JEd29tPCyyBPs4wHlwhSb33oW1NiDQ2ev7M8A/CTGnxl3z HO2oUlQ1ALLa3LYmh81YjBkIFv81x6PW9Rnkxf9YTItrfC54VVtUmhg9V2vh/NgtWwgR sZCGy5LIuZj89q2x1PoU9scCbGajnJtIq6d5qxGjaYZTATte3GFTPMDSd05mO1K9PO6H RdJUyyJj8c/LLbQo3uL3m6ti3ChSJVrpX4Ks6T/Co6UzzeqHl7PG2dVrKATvuqgMfti+ MnB5NWVGRxFba37bjU6ld6SYVLVGJKUQJg4jIZ5zbLVK/SwMEHiOnNYYou7io7OvMzE+ 2eCw== X-Gm-Message-State: AOAM531UzC1/AoPlQpwMb/WP64SF73z63oekJA0OE3KAPnLShO3kTsVf b0/QNBG0nFDBVS6COjDfV+8= X-Google-Smtp-Source: ABdhPJwMFYcHHRozqXN4AtNR2MES+iaSy4fJPsvrMzeKPD6tlrxIaHnB7DJrNJEs0wP1b9DmOYSbdg== X-Received: by 2002:a62:8c92:0:b0:44c:acfe:73a2 with SMTP id m140-20020a628c92000000b0044cacfe73a2mr31860508pfd.9.1634048592105; Tue, 12 Oct 2021 07:23:12 -0700 (PDT) Received: from Jianhuas-MacBook-Pro.local ([103.129.252.48]) by smtp.gmail.com with ESMTPSA id x31sm2929792pfu.40.2021.10.12.07.23.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Oct 2021 07:23:11 -0700 (PDT) Date: Tue, 12 Oct 2021 22:22:59 +0800 From: liujh.cc To: =?utf-8?Q?james.n.guichard=40futurewei.com?= , =?utf-8?Q?spring=40ietf.org?= Cc: =?utf-8?Q?spring-chairs=40ietf.org?= Message-ID: <2F812186-132B-4D48-8D92-776D0BE5F2FC@gmail.com> In-Reply-To: References: X-Mailer: MailMasterMac/4.15.7.1280 (10.15.7) X-CUSTOM-MAIL-MASTER-SENT-ID: EF3558D2-D2FA-4CC4-8C4D-381947513BCB MIME-Version: 1.0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [spring] =?utf-8?q?WG_Adoption_call_for_https=3A//datatracker=2E?= =?utf-8?q?ietf=2Eorg/doc/draft-filsfilscheng-spring-srv6-srh-compression/?= 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, 12 Oct 2021 14:23:20 -0000 PGh0bWw+DQo8aGVhZD4NCiAgICA8bWV0YSBodHRwLWVxdWl2PSdDb250ZW50LVR5cGUnIGNvbnRl bnQ9J3RleHQvaHRtbDsgY2hhcnNldD1VVEYtOCc+DQo8L2hlYWQ+DQo8Ym9keT4NCjxzdHlsZT4N CiAgICBmb250ew0KICAgICAgICBsaW5lLWhlaWdodDogMS42Ow0KICAgIH0NCiAgICB1bCxvbHsN CiAgICAgICAgcGFkZGluZy1sZWZ0OiAyMHB4Ow0KICAgICAgICBsaXN0LXN0eWxlLXBvc2l0aW9u OiBpbnNpZGU7DQogICAgfQ0KPC9zdHlsZT4NCjxkaXYgc3R5bGUgPSAnZm9udC1mYW1pbHk6SGVs dmV0aWNhLEhlbHZldGljYSzlvq7ova/pm4Xpu5EsIOWui+S9kzsgbGluZS1oZWlnaHQ6MS42Oyc+ DQogICAgPGRpdiA+PC9kaXY+PGRpdj4KICAgIDxkaXY+PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9y OiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiAmcXVvdDtT b25ndGkgU0MmcXVvdDs7IGZvbnQtc2l6ZTogMTZweDsiPkhpLCAmbmJzcDtBbGw8L3NwYW4+PC9k aXY+PC9kaXY+PGRpdj48ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogJnF1b3Q7U29uZ3RpIFNDJnF1b3Q7OyBmb250 LXNpemU6IDE2cHg7Ij48YnI+PC9kaXY+PGRpdj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xv cjogcmdiKDI1NSwgMjU1LCAyNTUpOyBjb2xvcjogcmdiKDMzLCAzNywgNDEpOyBmb250LXNpemU6 IDE2cHg7Ij48Zm9udCBmYWNlPSJTb25ndGkgU0MiPknigJlkIGxpa2UgdG8mbmJzcDs8c3BhbiBz dHlsZT0iY29sb3I6IHJnYigzMywgMzcsIDQxKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwg MjU1LCAyNTUpOyBvcnBoYW5zOiAyOyB3aWRvd3M6IDI7Ij4gc3VwcG9ydCB0aGUgYWRvcHRpb24g b2YgPC9zcGFuPnRoZTxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMzLCAzNywgNDEpOyBiYWNrZ3Jv dW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7IG1hcmdpbjogMHB4OyI+Jm5ic3A7ZHJhZnQ8 L3NwYW4+Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vIiB0YXJnZXQ9Il9i bGFuayIgcmVsPSJub29wZW5lciBub3JlZmVycmVyIiBkYXRhLWF1dGg9Ik5vdEFwcGxpY2FibGUi IGRhdGEtbGlua2luZGV4PSIwIiBzdHlsZT0ibWFyZ2luOiAwcHg7IiBjbGFzcz0iIGNsYXNzRGFy a2ZvbnQiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hl bmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLzwvYT48L2ZvbnQ+PC9zcGFuPjwvZGl2Pjxk aXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiAmcXVvdDtTb25ndGkgU0MmcXVvdDs7IGZvbnQtc2l6ZTogMTZweDsiPjxz cGFuIHN0eWxlPSJjb2xvcjogcmdiKDMzLCAzNywgNDEpOyBmb250LWZhbWlseTogdmFyKC0tYnMt Zm9udC1tb25vc3BhY2UpOyBvcnBoYW5zOiAyOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IHdpZG93 czogMjsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+PGJyPjwvc3Bhbj48 L2Rpdj48ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAs IDAsIDApOyBmb250LWZhbWlseTogJnF1b3Q7U29uZ3RpIFNDJnF1b3Q7OyBmb250LXNpemU6IDE2 cHg7Ij48c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMywgMzcsIDQxKTsgZm9udC1mYW1pbHk6IHZh cigtLWJzLWZvbnQtbW9ub3NwYWNlKTsgb3JwaGFuczogMjsgd2hpdGUtc3BhY2U6IHByZS13cmFw OyB3aWRvd3M6IDI7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPkZvciBD U0lEIDwvc3Bhbj48c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigzMywgMzcsIDQxKTsgY29s b3I6IHJnYigzMywgMzcsIDQxKTsgZm9udC1mYW1pbHk6IHZhcigtLWJzLWZvbnQtbW9ub3NwYWNl KTsgb3JwaGFuczogMjsgd2hpdGUtc3BhY2U6IHByZS13cmFwOyB3aWRvd3M6IDI7Ij5pcyBhIGVm ZmljaWVudCBzb2x1dGlvbiBiYXNlZCBvbiB0aGUgU1J2NiBkYXRhIHBsYW5lLiBBbmQgaXQgcHJv dmlkZXM8L3NwYW4+PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMzMsIDM3LCA0MSk7IGNv bG9yOiByZ2IoMzMsIDM3LCA0MSk7IGZvbnQtZmFtaWx5OiB2YXIoLS1icy1mb250LW1vbm9zcGFj ZSk7IG9ycGhhbnM6IDI7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsgd2lkb3dzOiAyOyI+IGEgZmxl eGlibGUgY2hvaWNlIG9mIGZsYXZvcnMgd2hlbiBhcHBseSBpbiBkaWZmZXJlbnQ8L3NwYW4+PHNw YW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMzMsIDM3LCA0MSk7IGNvbG9yOiByZ2IoMzMsIDM3 LCA0MSk7IGZvbnQtZmFtaWx5OiB2YXIoLS1icy1mb250LW1vbm9zcGFjZSk7IG9ycGhhbnM6IDI7 IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsgd2lkb3dzOiAyOyI+IGtpbmRzIG9mIHNjZW5hcmlvcy4g Jm5ic3A7PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7 IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiAmcXVvdDtTb25ndGkgU0MmcXVvdDs7 IGZvbnQtc2l6ZTogMTZweDsiPjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDMzLCAzNywg NDEpOyBjb2xvcjogcmdiKDMzLCAzNywgNDEpOyBmb250LWZhbWlseTogdmFyKC0tYnMtZm9udC1t b25vc3BhY2UpOyBvcnBoYW5zOiAyOyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7IHdpZG93czogMjsi Pjxicj48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsg Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6ICZxdW90O1Nvbmd0aSBTQyZxdW90Ozsg Zm9udC1zaXplOiAxNnB4OyI+PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMzMsIDM3LCA0 MSk7IGNvbG9yOiByZ2IoMzMsIDM3LCA0MSk7IGZvbnQtZmFtaWx5OiB2YXIoLS1icy1mb250LW1v bm9zcGFjZSk7IG9ycGhhbnM6IDI7IHdoaXRlLXNwYWNlOiBwcmUtd3JhcDsgd2lkb3dzOiAyOyI+ QmVzdCBXaXNoZXMhPC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwg MCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiAmcXVvdDtTb25ndGkgU0Mm cXVvdDs7IGZvbnQtc2l6ZTogMTZweDsgb3JwaGFuczogMjsgd2lkb3dzOiAyOyI+PGZvbnQgY29s b3I9IiMyMTI1MjkiPjxzcGFuIHN0eWxlPSJ3aGl0ZS1zcGFjZTogcHJlLXdyYXA7Ij48YnI+PC9z cGFuPjwvZm9udD48L2Rpdj48ZGl2IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogJnF1b3Q7U29uZ3RpIFNDJnF1b3Q7OyBm b250LXNpemU6IDE2cHg7IG9ycGhhbnM6IDI7IHdpZG93czogMjsiPjxmb250IGNvbG9yPSIjMjEy NTI5Ij48c3BhbiBzdHlsZT0id2hpdGUtc3BhY2U6IHByZS13cmFwOyI+Smlhbmh1YSBMaXU8L3Nw YW4+PC9mb250PjwvZGl2PjxkaXYgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiAmcXVvdDtTb25ndGkgU0MmcXVvdDs7IGZv bnQtc2l6ZTogMTZweDsgb3JwaGFuczogMjsgd2lkb3dzOiAyOyI+aHR0cDovL3d3dy5maWJlcmhv bWUuY29tPC9kaXY+PC9kaXY+PGJsb2NrcXVvdGUgaWQ9Im50ZXMtcGNtYWlsLXF1b3RlIiBzdHls ZT0ibWFyZ2luOiAwOyBwYWRkaW5nOiAwOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiAn J0hlbHZldGljYScsJ01pY3Jvc29mdCBZYWhlaScsICflvq7ova/pm4Xpu5EnJzsiPgo8cCBjbGFz cz0ieF9Nc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbTsgY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPgo8c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9Im1hcmdpbjowcHgiPiZuYnNwOzwvc3Bhbj48L3A+PHAgY2xh c3M9InhfTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY207IGNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9Im1hcmdpbjowcHgiPjxicj48L3NwYW4+PC9wPgo8ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgQXJpYWwsIEhlbHZldGljYSwgc2Fucy1zZXJpZjsg Zm9udC1zaXplOiAxMnB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiBy Z2IoMjU1LCAyNTUsIDI1NSk7Ij4KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBz YW5zLXNlcmlmOyBmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91 bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPkZyb206IHNwcmluZyAmbHQ7c3ByaW5nLWJv dW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBKYW1lcyBHdWljaGFyZCAmbHQ7amFtZXMu bi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tJmd0Ozwvc3Bhbj4KPGRpdj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJn YigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+RGF0ZTog RnJpZGF5LCBPY3RvYmVyIDEsIDIwMjEgYXQgNDowNSBQTTwvc3Bhbj48L2Rpdj4KPGRpdj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTFw dDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAy NTUpOyI+VG86IFNQUklORyBXRyAmbHQ7c3ByaW5nQGlldGYub3JnJmd0Ozwvc3Bhbj48L2Rpdj4K PGRpdj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTFwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1 NSwgMjU1LCAyNTUpOyI+Q2M6IHNwcmluZy1jaGFpcnNAaWV0Zi5vcmcgJmx0O3NwcmluZy1jaGFp cnNAaWV0Zi5vcmcmZ3Q7PC9zcGFuPjwvZGl2Pgo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDAsIDAs IDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij5TdWJqZWN0OiBbc3By aW5nXSBXRyBBZG9wdGlvbiBjYWxsIGZvciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88L3NwYW4+ PC9kaXY+CjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6 IHJnYigyNTUsIDI1NSwgMjU1KTsiPkRlYXIgV0c6PC9zcGFuPjwvZGl2Pgo8ZGl2Pjxicj4KPC9k aXY+CjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBm b250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJn YigyNTUsIDI1NSwgMjU1KTsiPlRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBleHByZXNzIHRoZWly IGFwcHJlY2lhdGlvbiBmb3IgYWxsIHRoZSByZXNwb25zZXMgcmVjZWl2ZWQgdG8gb3VyIGVtYWls cyB3aXRoIHJlZmVyZW5jZSB0byBob3cgdGhlIHdvcmtpbmcKIGdyb3VwIHdpc2hlcyB0byBtb3Zl IGZvcndhcmQgd2l0aCByZXNwZWN0IHRvIGEgc29sdXRpb24gZm9yIFNSdjYgY29tcHJlc3Npb24u PC9zcGFuPjwvZGl2Pgo8ZGl2Pjxicj4KPC9kaXY+CjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMCwg MCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPlRoZSBhcHBhcmVu dCBpbmNsaW5hdGlvbiBvZiB0aGUgd29ya2luZyBncm91cCBpcyB0byB1c2UgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgt Y29tcHJlc3Npb24vCiBhcyB0aGUgYmFzaXMgZm9yIGl0cyBjb21wcmVzc2lvbiBzdGFuZGFyZGl6 YXRpb24gd29yay4gVGhhdCBpcyBwYXJ0IG9mIHdoYXQgdGhpcyBlbWFpbCBhdHRlbXB0cyB0byBj b25maXJtLjwvc3Bhbj48L2Rpdj4KPGRpdj48YnI+CjwvZGl2Pgo8ZGl2PjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMXB0OyBjb2xvcjog cmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij5CZWNh dXNlIG9mIHRoZSBhYm92ZSB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gaXNzdWUgYSAyLXdlZWsg V0cgY2FsbCBmb3IgYWRvcHRpb24gZW5kaW5nIE9jdG9iZXIgMTV0aCBmb3IgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgt Y29tcHJlc3Npb24vCiBidXQgd2l0aCBzb21lIGNsZWFyIGd1aWRlbGluZXMgYXMgZm9sbG93cy4g QnkgZXhwcmVzc2luZyBzdXBwb3J0IGZvciBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IHlvdSBh cmUgZnVsbHkgYXdhcmUgb2YgYW5kIGFyZSBhY2tub3dsZWRnaW5nIHRoYXQ6PC9zcGFuPjwvZGl2 Pgo8ZGl2Pjxicj4KPC9kaXY+CjxkaXY+PGJyPgo8L2Rpdj4KPGRpdj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJn YigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+MS4gJm5i c3A7ICZuYnNwOyAmbmJzcDsgVGhlIFNQUklORyB3b3JraW5nIGdyb3VwIGlzIGFkb3B0aW5nIGEg ZG9jdW1lbnQgdGhhdCBoYXMgbXVsdGlwbGUgU1J2NiBFbmRwb2ludCBiZWhhdmlvcnMuPC9zcGFu PjwvZGl2Pgo8ZGl2Pjxicj4KPC9kaXY+CjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDExcHQ7IGNvbG9yOiByZ2IoMCwgMCwgMCk7 IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPjIuICZuYnNwOyAmbmJzcDsg Jm5ic3A7IFRoZSBkb2N1bWVudCBpcyBhIOKAnGxpdmluZ+KAnSBkb2N1bWVudDsgaXQgbWF5IGNo YW5nZSBhcyBpdCBnb2VzIHRocm91Z2ggcmV2aWV3IGFuZCBhbmFseXNpcyBieSB0aGUgU1BSSU5H IHdvcmtpbmcgZ3JvdXAuPC9zcGFuPjwvZGl2Pgo8ZGl2Pjxicj4KPC9kaXY+CjxkaXY+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDExcHQ7 IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1 KTsiPjMuICZuYnNwOyAmbmJzcDsgJm5ic3A7IEFsbCBvcGVuIGRpc2N1c3Npb24gcG9pbnRzIHJh aXNlZCBvbiBvdXIgbWFpbGluZyBsaXN0IE1VU1QgYmUgYWRkcmVzc2VkIEJFRk9SRSBzYWlkIGRv Y3VtZW50IGlzIGFsbG93ZWQgdG8gcHJvZ3Jlc3MgZnJvbQogdGhlIHdvcmtpbmcgZ3JvdXAgdG8g cHVibGljYXRpb24uIEEgbGlzdCBvZiB0aGVzZSBkaXNjdXNzaW9uIHBvaW50cyB3aWxsIGJlIGRv Y3VtZW50ZWQgaW4gdGhlIFdHIGRvY3VtZW50IGFuZCBtYWludGFpbmVkIGJ5IHRoZSBkb2N1bWVu dCBlZGl0b3IgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgY2hhaXJzLjwvc3Bhbj48L2Rpdj4KPGRp dj48YnI+CjwvZGl2Pgo8ZGl2PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgZm9udC1zaXplOiAxMXB0OyBjb2xvcjogcmdiKDAsIDAsIDApOyBiYWNrZ3JvdW5k LWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij40LiAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJZiB0 aGlzIGRvY3VtZW50IGlzIGFkb3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAsIHRoZSBjaGFpcnMg c3BlY2lmeSBhcyBwYXJ0IG9mIHRoZSBhZG9wdGlvbiBjYWxsIHRoYXQgdGhlIGZvbGxvd2luZyB0 ZXh0CiBkZXNjcmliaW5nIGFuIG9wZW4gaXNzdWUgYmUgYWRkZWQgdG8gdGhlIGRvY3VtZW50IGlu IHRoZSBhYm92ZS1kZXNjcmliZWQgb3BlbiBpc3N1ZXMgc2VjdGlvbjo8L3NwYW4+PC9kaXY+Cjxk aXY+PGJyPgo8L2Rpdj4KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3Vu ZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+wrcgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICJHaXZlbiB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBzYWlkIHRoYXQgaXQgd2FudHMg dG8gc3RhbmRhcmRpemUgb25lIGRhdGEgcGxhbmUgc29sdXRpb24sIGFuZCBnaXZlbiB0aGF0IHRo ZSBkb2N1bWVudAogY29udGFpbnMgbXVsdGlwbGUgU1J2NiBFbmRQb2ludCBiZWhhdmlvcnMgdGhh dCBzb21lIFdHIG1lbWJlcnMgaGF2ZSBzdGF0ZWQgYXJlIG11bHRpcGxlIGRhdGEgcGxhbmUgc29s dXRpb25zLCB0aGUgd29ya2luZyBncm91cCB3aWxsIGFkZHJlc3Mgd2hldGhlciB0aGlzIGlzIHZh bGlkIGFuZCBjb2hlcmVudCB3aXRoIGl0cyBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiBvYmplY3Rp dmUuIi48L3NwYW4+PC9kaXY+CjxkaXY+PGJyPgo8L2Rpdj4KPGRpdj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJn YigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+UGxlYXNl IGNvbnNpZGVyIHRoZSBhYm92ZSBndWlkZWxpbmVzIGFzIHlvdSBkZWNpZGUgb24gd2hldGhlciB0 byBzdXBwb3J0IG9yIG5vdCB0aGlzIFdHIGFkb3B0aW9uLiBQbGVhc2UgZXhwcmVzcyBjbGVhcmx5 IHlvdXIgcmVhc29uaW5nCiBmb3Igc3VwcG9ydC9ub24tc3VwcG9ydCBhcyB3ZWxsIGFzIGFueSBv cGVuIGRpc2N1c3Npb24gcG9pbnRzIHlvdSB3b3VsZCBsaWtlIGFkZHJlc3NlZCBzaG91bGQgdGhl IGRvY3VtZW50IGJlIGFkb3B0ZWQgaW50byB0aGUgd29ya2luZyBncm91cC48L3NwYW4+PC9kaXY+ CjxkaXY+PGJyPgo8L2Rpdj4KPGRpdj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dy b3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+VGhhbmtzITwvc3Bhbj48L2Rpdj4KPGRp dj48YnI+CjwvZGl2Pgo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTFwdDsgY29sb3I6IHJnYigwLCAwLCAwKTsgYmFja2dyb3VuZC1jb2xv cjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+SmltLCBCcnVubyAmYW1wOyBKb2VsPC9zcGFuPjxicj4K PC9kaXY+PC9ibG9ja3F1b3RlPjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyI+IFAge21hcmdpbi10b3A6 MDttYXJnaW4tYm90dG9tOjA7fSAKPC9zdHlsZT48IS0t77+9LS0+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4= From nobody Tue Oct 12 07:35:52 2021 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 05AE43A153C; Tue, 12 Oct 2021 07:35:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 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, 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=lrQ6pQRi; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=s+ZwtqaG 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 qKD9OiMlQVrT; Tue, 12 Oct 2021 07:35:46 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02C703A1538; Tue, 12 Oct 2021 07:35:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10150; q=dns/txt; s=iport; t=1634049346; x=1635258946; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7eG9mav75EyRZeaYkqudcgHLz3ZSv+gWXZ9+oLgtj30=; b=lrQ6pQRikITCgSci/hb1z9xc5RyOiLAdZafGM/uwXgLMI6HtzapUXiGy fMv8UcA512vCfhcdEWNWbGTkcf7vzdFtRdKNY5kskqboQkOOW6DFRtM9j aaWlt1268blgqAKUcjjolysSVxzTVxcLuIYF+37+dGO3YArNSYyUihGaa s=; IronPort-PHdr: =?us-ascii?q?A9a23=3AFx9iAR/gE8/whf9uWDnoyV9kXcBvk7T5IgBT7?= =?us-ascii?q?YAo2PpCcaWmqpLlOkGXpfBgl0TAUoiT7fVYw/HXvKbtVS1lg96BvXkOfYYKW?= =?us-ascii?q?0oDjsMbzA0tHMDDDlf0f7bmaiUgF5FEU1lot3iwLUlSHpP4YFvf6n2/5DIfA?= =?us-ascii?q?FPxLw1wc+/0AYXVyc+w0rPaxg=3D=3D?= IronPort-Data: =?us-ascii?q?A9a23=3AN8JRuqK2gfG9EpfNFE+R8ZclxSXFcZb7ZxGr2?= =?us-ascii?q?PjKsXjdYENS0DxTz2NMWmuPO6vfMWP3KNskbovjoEgPvsWHyNQxSwYd+CA2R?= =?us-ascii?q?RqmiyZq6fd1j6vI0qj7wvTrFCqL1O1DLImdRCwIZiWE/E70auG79SAUOZygH?= =?us-ascii?q?9IQNsaVYkideic8IMsRoUoLd98R2uaEs/Dga+++kYuaT/nkBbOQ82Uc3lT4R?= =?us-ascii?q?E60gEgHUPza4Fv0t7GlDBxBlAe2e3I9VPrzKUwtRkYUTLW4HsbiLwrC5Kuy8?= =?us-ascii?q?mWc9BA3B5b01L36aUYNBLXVOGBiiFIPBPPk2UcE93d0i/pmXBYfQR8/ZzGhk?= =?us-ascii?q?9xsy9hWnZexUgwueKbLnYzxVjEITnonYPcepOCvzX+X9Jb7I1f9W2D02fRoA?= =?us-ascii?q?2k3MJEWvOFtDglmq/kRLhgMYwyNweWsz9qGpkNE7ig4BNPgMIVasXZ6wHSIS?= =?us-ascii?q?/0nWpvEBa7N4LdlMP4LrpgmNZ7jiwAxM1KDtCj9XiA=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AT0ny4qwE5I8qZyvLo5TMKrPxdegkLtp133?= =?us-ascii?q?Aq2lEZdPULSK2lfpGV8sjziyWatN9IYgBepTiBUJPwJk80hqQFn7X5XI3SHD?= =?us-ascii?q?UO3VHJEGgM1/qY/9SNIVyaygcZ79YdT0EcMqyyMbEZt7eB3ODQKb9Jq7PrnN?= =?us-ascii?q?HK9IXjJjVWPHxXgspbnmFE43OgYzVLrX59dOME/fSnl656jgvlXU5SQtWwB3?= =?us-ascii?q?EDUeSGjcbMjojabRkPAANiwBWSjBuzgYSKUSSw71M7aXdi0L0i+W/Kn0jS/a?= =?us-ascii?q?O4qcy2zRfayiv684lWot380dFObfb8z/T9aw+czjpAVr4RHYFqjwpF+d1HL2?= =?us-ascii?q?xayOUkli1QePibLUmhJV1d7yGdgTUImwxemkMKgWXo8UcL5/aJGQ7Tz6F69N?= =?us-ascii?q?1kmtyz0Tt9gDg06tM444qU2qAnfi/ojWDz4cPFWAptkVfxqX0+kfQLh3gaSo?= =?us-ascii?q?cGbqRNxLZvsH+9Pa1wVh4S0rpXXdWGzfusksp+YBefdTTUr2NvyNujUjA6GQ?= =?us-ascii?q?qHWFELvoiQ3yJNlH50wkMEzIhH901wuq4VWt1B/aDJI65onLZBQosfar98Hv?= =?us-ascii?q?4IRY+yBnbWSRzBPWqOKRDsFb0BOXjKt5nriY9Fq92CadgN1t8/iZ7BWFRXuS?= =?us-ascii?q?o7fF/vE9SH2NlR/hXEUAyGLH/QIwFlltBEU5jHNfvW2AG4OSQTevqb0rwi65?= =?us-ascii?q?fgKoOO0bptcojeEVc=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DtCwB7nGVh/5FdJa1agQmCejBRB3c?= =?us-ascii?q?OTDcxiA4DhTmddoUIglMDVAsBAQENAQFBBAEBhH4CgkgCJTgTAQIEAQEBEgE?= =?us-ascii?q?BBQEBAQIBBgSBEROFaAEMhkMCAQMSCxATAQExBgEPAgEIEjQyFw4BAQQOBQg?= =?us-ascii?q?aglCBflcDLwGjIQGBOgKKH3iBM4EBgggBAQYEBIUKGII1CYE6gwOEEoJ2g38?= =?us-ascii?q?nHIFJRIEVAUKCZz6ER4NNgi6LGoFZdIFhdZE/jFSfeQqDMJ8KFKcXlggfoGa?= =?us-ascii?q?EYgIEAgQFAg4BAQaBeCSBWXAVgyRRGQ+OLBaDUIpedDgCBgsBAQMJlBUBAQ?= X-IronPort-AV: E=Sophos;i="5.85,367,1624320000"; d="scan'208,217";a="853152047" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Oct 2021 14:35:44 +0000 Received: from mail.cisco.com (xbe-aln-007.cisco.com [173.36.7.22]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 19CEZi8u031624 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 12 Oct 2021 14:35:44 GMT Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xbe-aln-007.cisco.com (173.36.7.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 12 Oct 2021 09:35:44 -0500 Received: from xfe-aln-001.cisco.com (173.37.135.121) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 12 Oct 2021 09:35:43 -0500 Received: from NAM02-BN1-obe.outbound.protection.outlook.com (173.37.151.57) 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.792.15 via Frontend Transport; Tue, 12 Oct 2021 09:35:43 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Rnzbg+erMHU38MLBYtqL30bBT9dY57E+mHqfIcoPi8/Z6a80npkGN014xqDbMJ2rsse7XxJM2FGTbBqTdVMYMMhwLbwAVbcfXScHz1MqBk4XsKq08GUf3ZX8h1kOFJab2Pwy+cfPi/1AJPGHdJIYyE13FFkzbHwGvpgqroXCFCWNe4BGEFAi5IKxCnygQWKrI9R5eHRDovRrN/wqT9qRqNVK+QZbRJ5wvlU5D6/7uC+zDpfc7HU6uxQQaao/pbCW1TZ2eku8Onm/w30v6WgOsAJH6Gr0EWtFm61rPjX3UvgS/Xm7AJjH+quwd4KzhvKjpmZf5Pfkfscj1VjU8cZRPw== 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=l2sXG049Fva2Jo7wf9N7ijUSZ0+pX+PpdS+Lb8zV3Ww=; b=D5wjeDhwLYoeRGShG7UeZ4HLUmb6PgUcqpiQ5xxG2eQrYWi3p2iXgWavhL8GJN/3szg66E2oOycSV4oQ896QGwzjC2uzwSOwbw/mkLnrbFsuQ5vMuC3MH7iinE3CS2tq/ZXKGmAvqSSxpBH00KPgt8TETGoXtW3jgN+rs0X24aiW8ouOJzMR0lXrZcscw0gK1+4M8oBAFj0VAAA/Iugn5I1Q1edILgmKdq4qU+rJxslQt0q+nLjfCtmfXLoBjhDv/GfWbkEnvk/QJ1dsihv8qZVFLbbpAuLKZf4L5RcbVe+N1rqKpVy68YDbRU76gtuooa/GpdSaTQm4UBspoLkbPA== 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=l2sXG049Fva2Jo7wf9N7ijUSZ0+pX+PpdS+Lb8zV3Ww=; b=s+ZwtqaGflgOlbe4KgPdj+CZ+hWAfEdrMEMp3TYsBK3KRzrRGRST2SPD63NcvdSzDWbXCpX5MfyrtEZHUigeVvRHYQeKuPABo3Vyy+TBi5W0ZWkmQdZRV08sD960TPeAV0Y5IxXVh9xoSHzzZJVtjDR641AvSVJfn4zNuLt0EwA= Received: from BN6PR11MB4081.namprd11.prod.outlook.com (2603:10b6:405:78::38) by BN7PR11MB2772.namprd11.prod.outlook.com (2603:10b6:406:ae::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.24; Tue, 12 Oct 2021 14:35:42 +0000 Received: from BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::29b3:3118:f61f:8c]) by BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::29b3:3118:f61f:8c%6]) with mapi id 15.20.4587.026; Tue, 12 Oct 2021 14:35:42 +0000 From: "Darren Dukes (ddukes)" To: "6man@ietf.org" <6man@ietf.org> CC: SPRING WG Thread-Topic: draft-filsfilscheng-spring-srv6-srh-compression-02 Thread-Index: Ade3AXyWK2NzAamgSlCvJ497z/5RLwIYy1no Date: Tue, 12 Oct 2021 14:35:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=True; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-01T20:34:49.0000000Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8942abde-8afe-4ad8-fe13-08d98d8d918a x-ms-traffictypediagnostic: BN7PR11MB2772: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fmUhyhyyixdLxWnGZyrjcOw63fdC4OD1gibQott1aoLImbnkYuZSdBVQITZ56UNhyU6iZivWb44AXqYbGHEiK1Nhqp92gOwckOP4H9Xn4b5zbBfALsyZa15NibMNKq2XNJUfnBidSXzdP1UDEpfJ6gPqLM5c6PKlvIGRSHfhh4mMggZDTzP1y4SOwQttr+BAU2KLqKqHv8OAYJQkmIRYoYolNhu+xAaQGqUDq6ygxqm6PKg2Q+uquofvDFwFoxPIXF4K2usHCwO4lmL03+I2D5SNc6vG9ukKguQZvPVbBAp7cSuyGFe/XpnBuclZ79c5uiyaHMPEYrvDADMOBCrw4HV3HcuQJWskm+3f/DucOqF4dTEIayVQVjYj6xQTxM59txEuQZDGQ/3lTT+f1tCiTYyoRM6oPuWZM0nT/tW5V+X7wzwUj/zN4TGMFFyWkx5HLWu8cLJlZskWPMkxWEgbL/OiKx1swAPSacrkkseOUbrz+hQrWqqbKZ7SnBEqkP/oe4n98pMdj6Tyui4HHOzz5bhq58PO4sn6OBwijMgRncolncOSZhuRgkQpeK2lo7k3HUbgWECkonVoE9GXWtnrpRY9jXpOYGFxHu7oJ/xl3VpjAcne8uvujnXjJ12qZIG98y//9X60rGh5o1kCnjDxQ5jDzebk5nTF9IqI9yAWIW1BIQzOUXilPX2AOiP8LIowXXu9ZJ03Bjfd/ogz2eC3FA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB4081.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(64756008)(86362001)(66946007)(6916009)(66446008)(450100002)(66556008)(4326008)(52536014)(38100700002)(122000001)(76116006)(66476007)(2906002)(91956017)(53546011)(508600001)(71200400001)(38070700005)(9686003)(186003)(33656002)(26005)(6506007)(316002)(55016002)(8676002)(8936002)(5660300002)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?OEtYUfZT0YbhmWunRxqPu+Fms99PnaGfLad4Oo5XaIhSxjyV+lbKzjNh0i3O?= =?us-ascii?Q?bnmxv8l3CftfrAbPybow1cjLVn0e+5+fnghDS2dPDcJw5YbLNU8y2qQp4Ggv?= =?us-ascii?Q?SJnGHI3TUAHbw/LLYPyA0Hht38daDMcj20ZNYUVHBZsw4TVp8K+fYwnnXPH1?= =?us-ascii?Q?7mne6nX6P0YV5+Z397/26H0c9wguCWsE1iR8Me/jFZ5BgGpXlZkVTHk4xKjx?= =?us-ascii?Q?WyhCpLa4QW49qVF5Mn0cekMCpuAZcL3T9gQvB+dPMbjG1VctN4eqrCT3y/+M?= =?us-ascii?Q?OgkzbwM0FT2oZDo+jq7bZGziB/5+Kk0kr9YvwXpkM92dPVobQ7zK95Ok0Jqe?= =?us-ascii?Q?ypB+EMrBhFizW3FUKv1CQT1lmu6kBo8kcysULXV5wGSz8Meoylh46KuLlOg1?= =?us-ascii?Q?AX4ndeaVZBn3ASWFacgUpSrn/Ve2+jEPT+rQTN5/YSgn2t3bTL58a3l3swZC?= =?us-ascii?Q?nqnizdOkuaznWkmlbck7C5QY+nyWxmBYgy9jk6FdSqx3DiseLoKmiT0uI+4J?= =?us-ascii?Q?NxxXnpKglEIPyyU7x8BMwhruEdo8DGvvaypShQ/N6LlfwKoKGNO9wi/T5jn1?= =?us-ascii?Q?oKH0DNi0/1ufpYpdP276op0hz+iAdbD5Y7NKQPDcs5xJ9KY5veykiJiJzIq9?= =?us-ascii?Q?IJozLj405Lf/3rR31Ig1v+VVl9l+H8cTIcPftG6BQdSeXoKvNT/2NHVRtrH7?= =?us-ascii?Q?SAzOC0HofSprIoXAmB9Q5kKOrIJP+2W5dSODBUrWR+O7/PfVMpSYd9tiGYXz?= =?us-ascii?Q?/THg5n3k9ZK1Wucr+UB8YdJksJgCLg3OwYqcgpbATYPp8cupneorbhVU7SuT?= =?us-ascii?Q?rXUnREczdUbB6kbe92BPY3DkFhxNkq2lrM8TH47mGRO5YLdJKGSy+MZRfHxR?= =?us-ascii?Q?QRL0MBh/OUogRVkL4t7/JhmTjhaX4ISH8WVeR3KhMBE4UDX/7HsftWMAiRBP?= =?us-ascii?Q?14PNYdc9ZrD0udsv8JSYQJTMiBEimQx4xYchDOLLK59azs7PSbAGXpyTEXG2?= =?us-ascii?Q?wCKoOTqqW77+iZoppko5/6qHsudo3Xx0cY+KHQkg0jG5pnN5kGnLOpgwsan9?= =?us-ascii?Q?ahglWCZMThiKDZrAIiwQ1AG9HkgQnwKUFgUuXnO6bLIn/Pk3LGxp1rj2FwpT?= =?us-ascii?Q?0X2CKiF2cP/xQGTBFlJYPtNHiCKOXvAIY5IfwVI6bdF/4KIgTG/3TY8tTf92?= =?us-ascii?Q?xhY/4azR5iJ6w6l1v4vj6ykyZDyF9wgu1Z34l+jVlJYvAwGDpU8dJ/9tj0dd?= =?us-ascii?Q?h7zn+dYMzh4P68D9VQcSzhubrreGwq+VGk6iReG9k7P5XzUeEC+0dOoqzKI1?= =?us-ascii?Q?6lS7ab7co0wOCxbJurVMTNHnT4UIMTMPIqiAp/dRs5zUGA=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN6PR11MB408124A97D94A97D52CD2635C8B69BN6PR11MB4081namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN6PR11MB4081.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8942abde-8afe-4ad8-fe13-08d98d8d918a X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2021 14:35:42.0556 (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: 0qkPWNNMAwsYdSoJG885dcViyWkrV2a4kqXWPyXN4p7H1YeT8bpVquloZskRIF/01PchKm29IOYcNhWm6y3wnQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2772 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.22, xbe-aln-007.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 12 Oct 2021 14:35:51 -0000 --_000_BN6PR11MB408124A97D94A97D52CD2635C8B69BN6PR11MB4081namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is an interesting conversation but I would like to restate something I= mentioned early on. I'll try to say it differently this time. 1 - The CSID draft (draft-filsfilscheng-spring-srv6-srh-compression-02) doe= s NOT alter the definition of an SRv6 SID as defined in RFC8754 and RFC8986= . 2 - The CSID draft does define flavors of the END and END.X SIDs with argum= ents. 3 - We know SRv6 SIDs with arguments are defined in RFC8986 (eg section 4.1= 2). 4 - We know SRv6 SIDs are IPv6 addresses (RFC8402, RFC8754 and RFC8986). Given this, it is clear, the CSID flavors of the same SRv6 SIDs defined in = RFC8986 are also IPv6 addresses. While it is interesting to rehash the discussion we had while working on RF= C8754 and RFC8986 regarding SRv6 SIDs as IPv6 addresses, let's acknowledge = it is orthogonal to SPRINGs adoption poll and subsequent work on draft-fils= filscheng-spring-srv6-srh-compression-02. Sincerely, Darren On 2021-10-01, 4:37 PM, "spring" wrote: Folks, Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new SID= types that can occupy the Destination Address field of an IPv6 header. See= Sections 4.1, 4.2, and 4.3 of the draft for details. The SPRING WG has issued a call for adoption for this draft. It is not clear that these SID types can be harmonized with the IPv6 addres= sing architecture. Does anyone have an opinion? = Ron Juniper Business Use Only --_000_BN6PR11MB408124A97D94A97D52CD2635C8B69BN6PR11MB4081namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    <in reply to conversations on this thread><= /span>

     

    This is an interesting conversation but I wou= ld like to restate something I mentioned early on. I'll try to say it diffe= rently this time.

     

    1 - The CSID draft (draft-filsfilscheng-sprin= g-srv6-srh-compression-02) does NOT alter the definition of an SRv6 SID as = defined in RFC8754 and RFC8986.

    2 - The CSID draft does define flavors of the= END and END.X SIDs with arguments.

    3 - We know SRv6 SIDs with arguments are defi= ned in RFC8986 (eg section 4.12).

    4 - We know SRv6 SIDs are IPv6 addresses (RFC= 8402, RFC8754 and RFC8986).

     

    Given this, it is clear, the CSID flavors of = the same SRv6 SIDs defined in RFC8986 are also IPv6 addresses.

     

    While it is interesting to rehash the discuss= ion we had while working on RFC8754 and RFC8986 regarding SRv6 SIDs as IPv6= addresses, let's acknowledge it is orthogonal to SPRINGs adoption poll and subsequent work on draft-filsfilscheng-spring-sr= v6-srh-compression-02.

     

    Sincerely,

      Darren

     

     

    On 2021-10-01, 4:37 PM,= "spring" <spring-bounces@ietf.org> wrote:

     

    Folks,

     

    Draft-filsfilscheng-spring-srv6-srh-compression-02= introduces three new SID types that can occupy the Destination Address fie= ld of an IPv6 header. See Sections 4.1, 4.2, and 4.3 of the draft for details.

     

    The SPRING WG has issued a call for adoption for t= his draft.

     

    It is not clear that these SID types can be harmon= ized with the IPv6 addressing architecture.

     

    Does anyone have an opinion?

     

            &n= bsp;            = ;             &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;          Ron

     

     

    Juniper Business= Use Only

    --_000_BN6PR11MB408124A97D94A97D52CD2635C8B69BN6PR11MB4081namp_-- From nobody Tue Oct 12 07:39:59 2021 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 464A83A1558; Tue, 12 Oct 2021 07:39:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 71jkwydhGJIt; Tue, 12 Oct 2021 07:39:54 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BFDA3A155B; Tue, 12 Oct 2021 07:39:51 -0700 (PDT) X-Envelope-To: 6man@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 19CEdk0o055271 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Oct 2021 15:39:46 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: "Darren Dukes (ddukes)" Cc: "6man@ietf.org" <6man@ietf.org>, SPRING WG References: From: Nick Hilliard Message-ID: Date: Tue, 12 Oct 2021 15:39:45 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.49 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 12 Oct 2021 14:39:56 -0000 Darren Dukes (ddukes) wrote on 12/10/2021 15:35: > Given this, it is clear, the CSID flavors of the same SRv6 SIDs defined > in RFC8986 are also IPv6 addresses. Ok, this is good that we're all on the same page about SIDs being IPv6 addresses. This means that they and draft-filsfilscheng-spring-srv6-srh-compression need to comply with 8200 and 4291, and it looks to me like the draft does not. Nick From carmine.scarpitta@uniroma2.it Tue Oct 12 02:38:23 2021 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 D9B853A0A9D; Tue, 12 Oct 2021 02:38:23 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=uniroma2.it header.b=9a59WkIq; dkim=pass (2048-bit key) header.d=uniroma2.it header.b=KYNMu5np 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 lJbnyYAzEvA3; Tue, 12 Oct 2021 02:38:19 -0700 (PDT) Received: from smtp.uniroma2.it (smtp.uniroma2.it [160.80.6.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 F319F3A0A87; Tue, 12 Oct 2021 02:38:16 -0700 (PDT) Received: from smtpauth-2019-1.uniroma2.it (smtpauth.uniroma2.it [160.80.5.46]) by smtp-2015.uniroma2.it (8.14.4/8.14.4/Debian-8) with ESMTP id 19C9c4KP000701; Tue, 12 Oct 2021 11:38:09 +0200 Received: from DESKTOPIEBDPSE (93-56-31-130.ip287.fastwebnet.it [93.56.31.130]) by smtpauth-2019-1.uniroma2.it (Postfix) with ESMTPSA id A7286120092; Tue, 12 Oct 2021 11:38:00 +0200 (CEST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=uniroma2.it; s=ed201904; t=1634031480; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bzLGteqbShPmNSakBNeONGt+UYxuvSMBISfl+FqSQbg=; b=9a59WkIqqjOY3664TUxK2/2oMAcyR7hM+cK11wT+0bs8Acv7UIsuygJTB3RAou/vvyM+qI iNVsa+pCR0Md1mDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniroma2.it; s=rsa201904; t=1634031480; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bzLGteqbShPmNSakBNeONGt+UYxuvSMBISfl+FqSQbg=; b=KYNMu5npY3QV0A/IkR+0K/qKRhDrHGt92GFevQVUvyYmP3XeEvum+tBB8mjxMwLC3zXlK/ /l+pJyR8c8wE1ZwZUcZ0q3ynZnvGx7VENdMItaSd0hvegnF5sT6nSEDFjE1VeBazUFtHhE s5zPTpQWQGUWrYwzZw3I8ANxNk6U6yErJ7Xg7QWbnW/0/ETxbc1UsTjVUEFlcw2bbOljyX cSS31qE+HiLxznQd1055+/P18NQgn4iMmOI4/AaR7K7Pa/JfscnCKA3i5+a696sV8FAGmF BeUh2Nx/XT2E3wD5LF5ukg5KdVcWHQ8gI4Dzu1ptg3eraWo9khNMSaKB20ka0g== From: "Carmine Scarpitta" To: "'James Guichard'" , "'SPRING WG'" Cc: References: In-Reply-To: Date: Tue, 12 Oct 2021 11:37:59 +0200 Message-ID: <000201d7bf4c$d8fa48e0$8aeedaa0$@uniroma2.it> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01D7BF5D.9C84EDA0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQEEWQJbPMHwJZ19hgzfqnce2skSI61155Fw Content-Language: it X-Virus-Scanned: clamav-milter 0.100.0 at smtp-2015 X-Virus-Status: Clean Archived-At: X-Mailman-Approved-At: Tue, 12 Oct 2021 08:26:56 -0700 Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 12 Oct 2021 09:48:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0003_01D7BF5D.9C84EDA0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi WG,=20 =20 I support the adoption of = draft-filsfilscheng-spring-srv6-srh-compression.=20 =20 I have spent a lot of time doing performance measurements for SRv6 = dataplane implementations in open-source stack including Linux Kernel, = VPP and others.=20 The measurements included SRv6 behaviors defined in RFC8986 as well as = the flavors defined for End, End.X and End.T behaviors.=20 The flavors defined in the CSID draft are complaint with RFC8986 and = builds on top of the single SRv6 dataplane.=20 =20 Thanks=20 Carmine =20 From: spring On Behalf Of James Guichard Sent: Friday, October 1, 2021 4:05 PM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ =20 Dear WG: =20 The chairs would like to express their appreciation for all the = responses received to our emails with reference to how the working group = wishes to move forward with respect to a solution for SRv6 compression.=20 =20 The apparent inclination of the working group is to use = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ as the basis for its compression standardization work. That is = part of what this email attempts to confirm. =20 Because of the above the chairs would like to issue a 2-week WG call for = adoption ending October 15th for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ but with some clear guidelines as follows. By expressing = support for adoption of this document you are fully aware of and are = acknowledging that:=20 =20 1. The SPRING working group is adopting a document that has multiple = SRv6 Endpoint behaviors.=20 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change as = it goes through review and analysis by the SPRING working group.=20 3. All open discussion points raised on our mailing list MUST be = addressed BEFORE said document is allowed to progress from the working = group to publication. A list of these discussion points will be = documented in the WG document and maintained by the document editor in = conjunction with the chairs.=20 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open = issue be added to the document in the above-described open issues = section: * "Given that the working group has said that it wants to standardize = one data plane solution, and given that the document contains multiple = SRv6 EndPoint behaviors that some WG members have stated are multiple = data plane solutions, the working group will address whether this is = valid and coherent with its one data plane solution objective.". =20 Please consider the above guidelines as you decide on whether to support = or not this WG adoption. Please express clearly your reasoning for = support/non-support as well as any open discussion points you would like = addressed should the document be adopted into the working group. =20 Thanks! =20 Jim, Bruno & Joel =20 =20 ------=_NextPart_000_0003_01D7BF5D.9C84EDA0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Hi WG,

     

    I support the adoption of = draft-filsfilscheng-spring-srv6-srh-compression. =

     

    I have spent a lot of time doing = performance measurements for SRv6 dataplane implementations in = open-source stack including Linux Kernel, VPP and others. =

    The measurements included SRv6 = behaviors defined in RFC8986 as well as the flavors defined for End, = End.X and End.T behaviors.

    The flavors defined in the CSID = draft are complaint with RFC8986 and builds on top of the single SRv6 = dataplane.

     

    Thanks =

    Carmine

     

    From: = spring <spring-bounces@ietf.org> On Behalf Of James = Guichard
    Sent: Friday, October 1, 2021 4:05 PM
    To: = SPRING WG <spring@ietf.org>
    Cc: = spring-chairs@ietf.org
    Subject: [spring] WG Adoption call for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/

     

    Dear WG:

     

    The chairs would like to express their appreciation for all = the responses received to our emails with reference to how the working = group wishes to move forward with respect to a solution for SRv6 = compression.

     

    The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-sp= ring-srv6-srh-compression/ as the basis for its compression = standardization work. That is part of what this email attempts to = confirm.

     

    Because of the above the chairs would like to issue a = 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-sp= ring-srv6-srh-compression/ but with some clear guidelines as = follows. By expressing support for adoption of this document you are = fully aware of and are acknowledging that:

     

    1. The = SPRING working group is adopting a document that has multiple SRv6 = Endpoint behaviors.
    2. The = document is a =E2=80=9Cliving=E2=80=9D document; it may change as it = goes through review and analysis by the SPRING working group. =
    3. All = open discussion points raised on our mailing list MUST be addressed = BEFORE said document is allowed to progress from the working group to = publication. A list of these discussion points will be documented in the = WG document and maintained by the document editor in conjunction with = the chairs.
    4. If = this document is adopted by the working group, the chairs specify as = part of the adoption call that the following text describing an open = issue be added to the document in the above-described open issues = section:
      • "Given that the working group has said that it wants = to standardize one data plane solution, and given that the document = contains multiple SRv6 EndPoint behaviors that some WG members have = stated are multiple data plane solutions, the working group will address = whether this is valid and coherent with its one data plane solution = objective.".

     

    Please consider the above = guidelines as you decide on whether to support or not this WG adoption. = Please express clearly your reasoning for support/non-support as well as = any open discussion points you would like addressed should the document = be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & = Joel

     

     

    ------=_NextPart_000_0003_01D7BF5D.9C84EDA0-- From nobody Tue Oct 12 08:47:24 2021 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 EE1E93A1626; Tue, 12 Oct 2021 08:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=XVB1cSKa; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=onOig4FI 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 QW-zlk7csBVF; Tue, 12 Oct 2021 08:47:07 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39B7E3A11E1; Tue, 12 Oct 2021 08:47:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3368; q=dns/txt; s=iport; t=1634053627; x=1635263227; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=x9D1Vo9L87q8pRekE4qOZqQvncC4NTcwbinNqPma3ks=; b=XVB1cSKaPhEB4wEvhwZWXrCbufhP7rQ3/vs+WSSvqiEevfWb/Yaz4ZMf aiJUgIqZENGN6HZfYhnOo5z9gkAPA4ABdEY7zMtiFyZoklV5saRlS8H+j L7VfmVh9icC8J11ZbB4iip5wMKHeHuj7yBZUUJ7XriOQpsc+IA2apk0YQ k=; X-IronPort-AV: E=Sophos;i="5.85,368,1624320000"; d="scan'208,217";a="936546095" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Oct 2021 15:46:41 +0000 Received: from mail.cisco.com (xbe-rcd-005.cisco.com [173.37.102.20]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 19CFkfhC006722 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 12 Oct 2021 15:46:41 GMT Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xbe-rcd-005.cisco.com (173.37.102.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 12 Oct 2021 10:46:41 -0500 Received: from xfe-rtp-002.cisco.com (64.101.210.232) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 12 Oct 2021 10:46:40 -0500 Received: from NAM10-MW2-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.792.15 via Frontend Transport; Tue, 12 Oct 2021 11:46:40 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mRrdLocz+Au0GWUh6E/DaBNtHZDAyxk259e+jhqmrsLZFgvFvcAKXdA1UwIwu9B1syx+wcF5nNO/9l+SQhgghM3wZGGKC8Hu609rLBubEA7Es53VEgDzFsVkq7Zm3MR8hoyYHRUidFZdz5YgC8/o+oKU6iuodeAZsGMypziwRrCbBESO86lD06uZKT57nJ0oUVAAjr01P5NNF4zorSHyd5fmIwkTxnc1TsJqe3OJzZqPUcrUcSI1MPwhsVZ6dayRXTozdt0FKWkhFG7Cb4qSTFs4Lt5Vw8yI2HfbKrO3AdpuSh6pT0/XP11x7jCpIEatk2rL+niQhL86/nDszco6bw== 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=iCZguA20Q/LDR5OKIDDB0pFcTMG8TAbGRPJoMlUwI1w=; b=ILWgmNyRs8dABBi0Xj3ayNZxeLCOmLwB2DBrPGECRrmPo08DzffuqZfkX26GTkbOzOp96A2kfn4/y8qfY/JdAgr3T0ck29fiBTKPmDb1Tm9KeB4KMHJEyzgZ+IVkeNB9DrceJCJsHIGm7foZ1b5iL1vAMT6c78tnEE8ma/t9IT15K7OYXPbNGlGKUMn4nvSv4McK0kVvJFpLYivD6lspWLzl3cSNQ0si6psJOs+TvJhkST9MFwjPG686r+gb9U8I8BuNzGdV8ns53VlZ9i9Jaqj9HxNxmhOoetND8jjx+cdSbAGDhlEC8K7IKxzYM1FJbx37DcffecRIz+DrXlig6Q== 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=iCZguA20Q/LDR5OKIDDB0pFcTMG8TAbGRPJoMlUwI1w=; b=onOig4FIfB4LdcUOFmk9jNJifIpjHW3Sh0kCfIBZhEkc2zTpoX80jsnDlSt/qjNfWqXphyz9MdblQgwLR9+bS2U99/McEYtdKzOeS3C95Zde5lmz3DIbAOVrVaxSU2eJEzkTK8RIR4fbiAg7eX7BV3jTetmK137DOWz5HkflZEM= Received: from BN6PR11MB4081.namprd11.prod.outlook.com (2603:10b6:405:78::38) by BN6PR1101MB2098.namprd11.prod.outlook.com (2603:10b6:405:52::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.18; Tue, 12 Oct 2021 15:46:39 +0000 Received: from BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::29b3:3118:f61f:8c]) by BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::29b3:3118:f61f:8c%6]) with mapi id 15.20.4587.026; Tue, 12 Oct 2021 15:46:38 +0000 From: "Darren Dukes (ddukes)" To: Nick Hilliard CC: "6man@ietf.org" <6man@ietf.org>, SPRING WG Thread-Topic: draft-filsfilscheng-spring-srv6-srh-compression-02 Thread-Index: Ade3AXyWK2NzAamgSlCvJ497z/5RLwIYy1noAASVd4AAAQRZWg== Date: Tue, 12 Oct 2021 15:46:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: foobar.org; dkim=none (message not signed) header.d=none;foobar.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 511f9a25-ea65-4aaa-49a6-08d98d977abb x-ms-traffictypediagnostic: BN6PR1101MB2098: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3968; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1G/fWPpXuBO5OehYm9tWWUArpjbpLtD/KZ3UqvgvQrRpfYCvFi26bUXQjDTt+0N1ep535uSny33MuGgDjSfSDwdXDjOUrIoF9G0/EA7s29aikO7nT77n+IfDT5a+jUWjXTYCnlmVazqa43lUkrjPXrsnpdKvkRGeUR1zjVU8ntgjyktQKkYGDMUn3PhPchKBxhWJkD8dwH2PxS2plvk2dvle0lGku9SXGmbHLT0CazsdCSxFX7JOtNXX4lhljnpVa/7umiLaV4+V32/zZWx9VNFAEDke0sVAW6EvdlaTL0QFZGUwvajjB2my6AyFN4CPaWMyMD1IRPXP07mHEEYx4YiJp891xMQR3N+dzx9s+vxHNwHFEXz0+ZRDgJHZyB4OT4YUGYv1tBGnaz5SEk8EQOnpj1slQAL2rShlxXswu753uCS6tQcgpcVEAYG2eiaViYJCQaUjNLTV8Lrr7iK+yG9LlH2wBkgS4CykFrQwzbjTXiWTeqVZu5rtqL3EOZKFeQYLHRt1Fb9KAEMwB3lzsgylYJDVNPLtXs9GfbTmDFiv8nOqi/PGEJiS2wRLvWi3qMUm0tREsNMAPwosvZRBQRCZhjg/y/6Vk/YCf4ozk2vlh2lMVUYvxY++sO0B1dldslmBMsYbrr9BKljyxj/D+Z80yT0LtzcrHEsmWx1OuF9ucqzGZXlJgnNWlOjg9uCdgeZXWSojrZ5yQMdGCAH/aQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB4081.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(86362001)(6916009)(66476007)(66446008)(5660300002)(66556008)(6506007)(64756008)(7696005)(4326008)(2906002)(8676002)(54906003)(38070700005)(53546011)(52536014)(9686003)(66946007)(8936002)(4001150100001)(33656002)(91956017)(4744005)(316002)(508600001)(26005)(122000001)(55016002)(71200400001)(186003)(38100700002)(76116006); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?rv/P//n+9I5kT/+fRowBNS9vD3FkdcOg4tWwLM7FMGpMu65/krnBWQEbksyX?= =?us-ascii?Q?0BRLstTh7tDQVWWyjh5B38y4FgJ3JXUQBDAtXStjOaQben1rjc0hWH668yDf?= =?us-ascii?Q?4YlDWWOJj0D1WO+BEsitxvEwE8GqxEZDYi+Nqzw9bRJg0KZMVspKsSIqbQiR?= =?us-ascii?Q?PiQxXi17hcUrPrQgxjjCWAYPjN7mpRJjnnIm3qUyBq7Dbi9uoA3EvfM0R2Ml?= =?us-ascii?Q?PNYEddAtBycaFFGTTUJFHac6sJTNaPVWDH4eaAGA3f1hFtWW8RWihAz8wiYn?= =?us-ascii?Q?VVfwOlRkOqLu6ZfrOIh3j6J7vIrbudASkF3q2ZrIkeyV7BYHcT2UHYPrluxd?= =?us-ascii?Q?pGf0e91+PXB2f3IVXk7P8o3DYIZGSQBrxHscB/ImbhK6VOlyg/uOqS+Q32fe?= =?us-ascii?Q?jAxAeSmqPLjxA/Bp0pVjUZ46eTtyffmnLRRRKofLA1KYPE+j9v5muGOcgiR9?= =?us-ascii?Q?UnXV36K1MoZM/KH72u4H3qplpU37VIvPI1fWWJuxQLx3TPCn5SHkMdNLLFK9?= =?us-ascii?Q?ZDJLMwXxew3Xb3n44+VphE1/BYyK9ZgrXiXEbQcaT1UbD1SWS4nU1BKCrzyz?= =?us-ascii?Q?PQmHaknmZEBhyNtfsEx0O4ax8E8e0nGI5E7LZfliZzaox0B5l0Wx6XQ3enZp?= =?us-ascii?Q?7G4+KmC736FuZ024znSx6y6fRwbc7n2t/SfYJ0QCPbnYZqvvOphiqNTMK8nU?= =?us-ascii?Q?Mi52hZ/MW5E3EYof2UUnp2Y/sZATNKH+bHG+3NOiWM4we3TgCndOfjcLA4sh?= =?us-ascii?Q?iydT7VcFTL/Qjaj07H67gbQ1P8FJ67OlLFKiQub4Gku/VCHqhB2HAJhNYHej?= =?us-ascii?Q?G7R4EuINhf8xIRNMfKKonLwBXlZ99ZUSw9uklm/J6XH23LFcvqB4RQwqn+mM?= =?us-ascii?Q?46MDsMTrjx0Y7l3XUqE15n8XWiofUGqLL9UnTFSqWkKDJ2BBRRw+Nu2gafVT?= =?us-ascii?Q?eXGtpmv5IBJXgmxSU7bFk+O5asbu8qHo8rDryZRybSObhImWMnau3hI492LU?= =?us-ascii?Q?2KbUkTLj3HHxrw7Q7xFuyIFnE9VXNPLhh+gF8knLSBjP1rMoNF031G4Px1cP?= =?us-ascii?Q?hk84cW0H3N4v77pPv2COLvt9mk2G4k8Kmp7iH8oPIxuwHYh5GwNM/Kv5NTmw?= =?us-ascii?Q?AgNjX+JoLGFWf3MjR1zykqTGosonVFpErtP+sO/XY6VN5Hup+6qgOL9dJ+P7?= =?us-ascii?Q?cO8/kg6qbA6ws6kuMxLYWHZRBZcSq5iO8PHDllJIrE6iz/GKmx7TDrw1j4si?= =?us-ascii?Q?mBXhfAROuG83QopdjA/3TJa3FhPUxP7LT4VwfAgrypCDSBaZ17CEIO10OeBC?= =?us-ascii?Q?90bQAqp87ErAefDSN5Wl8z57GgogB4puwUYDLU78rW50Ng=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN6PR11MB40814CF67EF268280EA0EF01C8B69BN6PR11MB4081namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN6PR11MB4081.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 511f9a25-ea65-4aaa-49a6-08d98d977abb X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2021 15:46:38.6249 (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: g9fIzuozriPOqmMuQGs8Yp97Z/vJgiCBtQet//6izcgHQoSjv7pqfRb9cUvRjTUQkVf/r1sZ/MG1/+9QQlZfPg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1101MB2098 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xbe-rcd-005.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 12 Oct 2021 15:47:18 -0000 --_000_BN6PR11MB40814CF67EF268280EA0EF01C8B69BN6PR11MB4081namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Nick, during review of RFC8986, section 3.2 was added. SID allocation f= ollows that. Darren On 2021-10-12, 10:40 AM, "Nick Hilliard" wrote: Darren Dukes (ddukes) wrote on 12/10/2021 15:35: > Given this, it is clear, the CSID flavors of the same SRv6 SIDs defined > in RFC8986 are also IPv6 addresses. Ok, this is good that we're all on the same page about SIDs being IPv6 addresses. This means that they and draft-filsfilscheng-spring-srv6-srh-compression need to comply with 8200 and 4291, and it looks to me like the draft does not. Nick --_000_BN6PR11MB40814CF67EF268280EA0EF01C8B69BN6PR11MB4081namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Nick, during review of RFC89= 86, section 3.2 was added.  SID allocation follows that.

     

    Darren

     

    On 2021-10-12, 10:40 AM= , "Nick Hilliard" <nick@foobar.org> wrote:



    Darren Dukes (ddukes) wrote on 12/10/2021 15:35:
    > Given this, it is clear, the CSID flavors of the same SRv6 SIDs define= d
    > in RFC8986 are also IPv6 addresses.

    Ok, this is good that we're all on the same page about SIDs being IPv6
    addresses.  This means that they and
    draft-filsfilscheng-spring-srv6-srh-compression need to comply with 8200 and 4291, and it looks to me like the draft does not.

    Nick

    --_000_BN6PR11MB40814CF67EF268280EA0EF01C8B69BN6PR11MB4081namp_-- From nobody Tue Oct 12 08:55:24 2021 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 056243A1631; Tue, 12 Oct 2021 08:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=AjPGWM+X; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=NIQM6yzw 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 pe25gBnYIRAE; Tue, 12 Oct 2021 08:55:16 -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 2FE9C3A164F; Tue, 12 Oct 2021 08:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15846; q=dns/txt; s=iport; t=1634054085; x=1635263685; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BRXiimaOC4bR8wopVtfBjfrWwaEkc4LBvhZWMUY6KGs=; b=AjPGWM+XV66hEvPNFX3nSfcDeiaVSW8To3YQ4SWJRN1/P9HmAvMOZ9Fm D3DXNVR41wFXtsrMr2SF6YtYvALamHjkpgxUn7Lqfvq1pmpsJY3dMyijm jnEZXxaGQY+HsMmEwwSBXbSFNhL3W5VgxTZr7riuVVQN0BPKxcRTsZgwe Y=; X-IPAS-Result: =?us-ascii?q?A0AnAAB1r2Vhl40NJK1aHAEBAQEBAQcBARIBAQQEAQGCB?= =?us-ascii?q?gYBAQsBgSAwIy5+WjcxhEeDRwOFOYgLA5VohQiBLhSBEQNUCwEBAQ0BATcKB?= =?us-ascii?q?AEBhH4CF4IxAiU1CA4BAgQBAQEBAwIDAQEBAQUBAQUBAQECAQYEFAEBAQEBA?= =?us-ascii?q?QEBgQiFOwglDYZCAQEBAQMSCwYKEwEBLAsBDwIBCBEEAQEkBwICAjAdCAEBB?= =?us-ascii?q?AENBQgTB4JPAYF+VwMvAQ6icgGBOgKKH3qBMYEBgggBAQYEBIFKQYJ/GII1A?= =?us-ascii?q?waBOgGDAoQSAQGGcyccgUlEgRVDgmc+gmMCA4EjBQESASMrgms3ggwiixovQ?= =?us-ascii?q?mQEGzggAlkWgQIqESmVFYh+jU6SKwqDMIpGlEQUg2qLbJdBhxOOdR+MTZh7A?= =?us-ascii?q?gQCBAUCDgEBBoFjAzRrcHAVO4JpURkPgz6KYgwNCRUZgyKFFIVKdDgCBgEKA?= =?us-ascii?q?QEDCZQVAQE?= IronPort-PHdr: A9a23:IzHYph2e0TE5rWSDsmDPTVBlVkEcU/3cMBMJ94AqlL9PNK+k+seqM E/e4KBri1nEFcXe5ulfguXb+6bnRSQb4JmHvXxDFf4EVxIMhcgM2QB1BsmDBB71MeL3dSElE cUEX1hgrDm3NEFPE5P4YFvf6nS58T8VHED5Mgx4buT4E4LflYK5zee3rpbSeA5PwjG6ZOAaE Q== IronPort-Data: A9a23:cSq4qq5LIa1uo+7ZdFaxAAxRtAvHchMFZxGqfqrLsTDasY5as4F+v mIfWmuBbKuPajTzLtxxPdjj9RsAsJSEztZgSQI4pXpgZn8b8sCt6fZ1gavT04J+CuWZESqLO u1HMoGowPjZzRYwnz/1WlTbhSEUOZqgG/ysVYYoBggrHVU9EX9400o58wIEqtcAbeaRUlvlV eza+6UzCHf9s9KjGjtJg04rgEoHUMXa4Fv0jHRnDRx4lAO2e00uMX4qDfrZw00U7WVjNrXSq +7rlNlV945ClvsnIovNfr3TKiXmTlNOVOSDoiI+ZkSsvvRNjg5qyZQgL/YfUn5wp2TTltEpw ddgmbXlHG/FPoWU8AgcexBcFyc7Nqpc9fqXZ3O+qseUiUbBdhMAwd03UxpwZtNeo70xWD0Xn RAbAGhlghSrguGxxL6qQelEjcU4J86tN4Qa0p1l5W6HVKp9G8GTGc0m4/db+CwvhPl2MsrPb vdJaStuQTbaQhlAbwJ/5JUWxbf02SaXnydjgEmNv6sx7C3YzAVwyqPFMdfJdJqNX8o9tl2Av GPA8Ez4Dw0UctuFxlKt8Hupi/SJm2X0RYMZFLSi+tZknUGO3GEMBRxQXly+ycRVkWa3X9ZZb kcT4Cdr/e459VegSZ/2WBjQTGO4UgA0eYJLIfYh5AK28434slyQBzANTBNtQYlz3CMpfgAC2 liMltLvIDVgtryJVH6Qnot4SxvvZ0D5ykdfO0c5oRs5D8rL+9pq102RJjp3OOvk0IOqSGiYL yWi9nBWulkFsSIcO0xXF3juhzahoPAlpSZqu12OBQpJAu6FDbNJiqSh7VzdqP1HNovcHh+Kv WMPnI6V6+Vm4XCxeM6lHb9l8FKBvqvt3NjgbbhHRMBJG9OFoCfLQGyoyGsiTHqFy+5dEdMTX GfduBlK+LhYN2awYKl8buqZUppxlvm/Soy9DK2ENrKih6Sdkifao0mCgmbNgAjQfLQEysnTx L/CK5/3VCZGYUiZ5GPsGrx1PUAXKtAWnDOPGs+TI+WP2ruFb3ndUqYeLFaLdYgEAFCs/m3oH yJkH5LSkX13CbSmCgGOqNJ7BQ1afBATWMGtw+QKJ7HrClQ9QgkJVaSOqY7NjqQ4xsy5YM+Tp SrjMqKZoXKi7UD6xfKiMyg5Nuy0B8oj9BrW/0UEZD6V5pTqWq73hI93Snf9VedPGDBLpRKsc 8Q4Rg== IronPort-HdrOrdr: A9a23:tS71pqjK4xPHQ75Dh2P81vg5u3BQX3h13DAbv31ZSRFFG/FwyP rOoB1L73HJYWgqN03IwerwR5VpQRvnhPlICPoqTMmftWjdySqVxeRZjbcKrAeQYBEWmtQtsJ uINpIOdOEYbmIKzfoSgjPIaerIqePvmMvD6IuurAYOcegpUdAc0+4TMHf8LqQCfng/OXNPLu vk2iMonUvFRV0nKuCAQlUVVenKoNPG0Lj8ZwQdOhIh4A6SyRu19b/TCXGjr1QjegIK5Y1n3X nOkgT/6Knmmeq80AXg22ja6IkTsMf9y+FEGNeHhqEuW3fRY0eTFcFcso+5zXcISdKUmRAXeR 730k4d1vFImjfsl6eO0EPQMkfboW0TAjTZuC6laDPY0LzErXQBepB8bUYzSGqE16Lm1+sMjZ 6jlljpxKZ/HFfOmj/w6MPPUAwvnk2ooWA6mepWlHBHV5ACAYUh4LD30XklW6voJhiKorzP0d Mee/309bJTaxeXfnrZtm5gzJilWWkyBA6PRgwHttaO2zZbkXhlxw9ArfZv0Uso5dY4Ud1J9u 7EOqNnmPVHSdIXd7t0AKMETdGsAmLATBrQOCaZIEjhFqsAJ3XRwqSHrIkd9aWvYtgF3ZEykJ POXBdRsnMzYVvnDYmU0JhC4nn2MS2AtPTWu4hjDr1Cy/PBrZbQQFi+oWEV4r2dSq8kc7/mst 6ISeZrP8M= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.85,368,1624320000"; d="scan'208,217";a="761432982" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Oct 2021 15:54:30 +0000 Received: from mail.cisco.com (xbe-rcd-007.cisco.com [173.37.102.22]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 19CFsUq3028549 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Tue, 12 Oct 2021 15:54:30 GMT Received: from xfe-aln-004.cisco.com (173.37.135.124) by xbe-rcd-007.cisco.com (173.37.102.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Tue, 12 Oct 2021 10:54:30 -0500 Received: from xfe-aln-003.cisco.com (173.37.135.123) 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.792.15; Tue, 12 Oct 2021 10:54:29 -0500 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Tue, 12 Oct 2021 10:54:29 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dkiG8cz0bIBruuUAni+tkftypr1FTEgaUVfJMvdvg9n3+1imhu34B2uXXt2PvpMZQt41nmxCgBdLxEUxS8x/wGBaFpDLgypMz0ZsbtkxXpuTpN0acqOlB/3fmj8fkZU/bTks64uHyiE8OziI6+zJFrCmeehHSr9wyXft8TV1HNcnig7cpvHVngcAYL1H/2IZkYX38UVPXRuoAPvA4JmwcQk+g7AWnP61dm81W+E+4lt2df6qwuMAphMqBaXuMwRrsvcFpNoqLY7AKOhMWjdtc5IrTTfB2QxasY95faxVYahU28e2iQwakmBnLr5noaLOayUmtT3AAMOLdIBRhL+0Ig== 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=BRXiimaOC4bR8wopVtfBjfrWwaEkc4LBvhZWMUY6KGs=; b=nV42XKoQ7bFrBXVju8HrwUdnZM+diGZ7yAq9tcpCZPdNaFxgodfiJokNmWDdOc0jaWVHaOMw1ByG/IVOEODE3C8U7f4gSwq1Wat/bTRxjNUhD5EPLFrCgKhk1UzIQ1OZhwq+DBJsM2El8xxZ0KrdGnrgTj3kFAa8q3l4GAoqJBkAiyeVZHx4AsQqllfpPsExRNy/+Y5fAHKxszyDrsVuS/zaEW5K0u8njxOeUGjroa8I2xkFR1wUoYsRmOiJKKJ+Dkfu85l5/rNK0K7ZRYwhBQh4nTVgXgrf6Atig7EmvXaryI27jhsbzFFKMOee8CrF2vqx82T6TAB75uwiAuOK1A== 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=BRXiimaOC4bR8wopVtfBjfrWwaEkc4LBvhZWMUY6KGs=; b=NIQM6yzwIVL8JQPUNKG5j2l2H7HATXpYrGXCRSE6Y+q7vPPKGqw805j3JgTxi/r8gwq4aqRmzvncUWDKtErobe01CZYtbAF7eyzVAiiiF2YYh4jAeUugo6Pbu5yZ1DkQYMzB1nzPDqghA5ZEEgTvh+Q7QtqFy2ceiOVHubKVhWU= Received: from DM6PR11MB3802.namprd11.prod.outlook.com (2603:10b6:5:143::30) by DM6PR11MB4153.namprd11.prod.outlook.com (2603:10b6:5:19f::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.18; Tue, 12 Oct 2021 15:54:28 +0000 Received: from DM6PR11MB3802.namprd11.prod.outlook.com ([fe80::ac9f:937a:e415:3160]) by DM6PR11MB3802.namprd11.prod.outlook.com ([fe80::ac9f:937a:e415:3160%3]) with mapi id 15.20.4587.026; Tue, 12 Oct 2021 15:54:28 +0000 From: "Mike Koldychev (mkoldych)" To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQItXCZw Date: Tue, 12 Oct 2021 15:54:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 80a34884-f1bc-489c-9790-08d98d989292 x-ms-traffictypediagnostic: DM6PR11MB4153: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qUEjJkKAjrKIybReDQbt7XI588wLb6mFNLy/QGlByGAtZEdMq+sxNho1jDWkwjw4/8I76f2RLOjhMiOI8Gi1mapHND4QQ+3kAFFJtqV0hzRKtg89rjy3cUejtH/r+D7j1jM6ofRNofEgl/Inkcs020rgT2EwHYjEXJnGCg+lirUS6zJcW2gRFeFzQ4CMf3cwrTPRYCaITxom2EDXf9GXN6hyf7UFEZUgLEsvlLwIsp+xpibp/mpK5JXT3wc1LzII2NiyLunUU4KRBJJMOGcJIk3qG8q4b63eqkVTO0Je0Je61ZdqWIADHxEczluf7dXAzivmJ5skvqKOnrUw+D3cpKsCnRRrbRVnOjA+YHY5Q4XGPZSSPfzxFz4Cmn76lMvUSd9S4mWZ+6vFKvlSkTZXoAxEhzpqapGOaY5Q2srC4p/Ccl/7W1wTEOpcByz07TD6uk32ECljtMdcjhh81m8AaNUtTOVZytS7j4UWivcVE1DgD83C5iYMahOa6fn4mvyNS0DAHu9QajrktIUc2dXjZm0PjKotpEmQif4ureAL7u3zYeZlbF6lMGHtjT+F+kT8hJ38+DRmJRAXjlGHgU9U4qqmPAcVu+WKYNQcbFIENcdIev97VbpFifOHpHNufANuJjB59osuSXPtNeS4Lpn+Msds8JQMx1ngxMmcXcyGJF04u2rZD3y/3Wj7Mr336K+LZc0hKycmEX55VlHZYRGO3dN8EP8sWUGITbBuEgFqYjUGU1OeuLkmxXiik3j6ofAiOp5QIWV4+tIsDA3LwRQZq5nVIXoiv85+dbnUtk9k+tQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3802.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(86362001)(316002)(110136005)(71200400001)(66476007)(166002)(55016002)(64756008)(66946007)(66446008)(66556008)(8936002)(38070700005)(52536014)(186003)(5660300002)(26005)(966005)(8676002)(76116006)(6506007)(83380400001)(53546011)(33656002)(9686003)(508600001)(4326008)(38100700002)(2906002)(122000001)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?WmJWTE04S0M1QnZNbFFsL0pITG9YWUorUjRva0trWUtHSVBQSzlHMndrVkRu?= =?utf-8?B?enkyZkltZ3lPZkdLc1kxMVY4SEVueWIrUkdrcUF1UTltOC9WZlZhQzdNaWVZ?= =?utf-8?B?dUd4elVzVlNNZzU4Ylc2bEZLTm5qTVRnMDFpekJwNXJhYzBzZS9GQk9YQWV1?= =?utf-8?B?QlJ5MTNPaFkvK3IyVXZkUTdldFpOMXMxamZRdnd5SXZMYk9USU9pYndFTGlS?= =?utf-8?B?RDJOcEV0ZTRLN2lqdFp1ckl2NVNDRGlQZ3crMjRNT3JyZTBNZlY2bWNKUEdR?= =?utf-8?B?VzBsSGxzR0pHUjRCV25kOUExN0pzbENQeWlxKzZ3OHF1TGI5eFJNb29Ub1Uz?= =?utf-8?B?ODJvdysvay92emZJbEw4NWtTckFHZ0JUcUJaYStDL0JWamJjSmxRelhZNUNH?= =?utf-8?B?U0FibXBnVVU4ajNmYWpOVWJGcDd4cTY0V3Vyd0RZYlNJeUwyeDJ6SU5GUWNu?= =?utf-8?B?Vzh3elczdG5aZk9BQXY4S1JqWDRmMHM1VE9nb1p2TlRaY0NGc3E2aWFwd084?= =?utf-8?B?VU94MC9HVldSbHNmck9hOVdCcDRnUk8zdGltWCswVVZRSFNNUGdwLy90OG4y?= =?utf-8?B?Y08rTXAxcEFQZk4yVzREUUk4amt6UVFEeXVjVXJKckp5VlgxR0Z4N1M5djVJ?= =?utf-8?B?UGtuc25iSm9LVUc0OTJmV20zeDc0TEZpWGo5bGFubmc0ckFNRGViMzhMUm9q?= =?utf-8?B?S3hKQ2RYUGhVanA0MnozWWl5OUVwdHFNM1Z3OFAzMm8xWTVGUFZHSExXOUNP?= =?utf-8?B?aHg4VDRBUkl5SllObUhjUjJreU1NK1dueldTNWVHNVpGUkthUjdINy9ISGs5?= =?utf-8?B?VWRlZ1FWU0E2Q0U5UlFJWFNvTE11NlNkYXI0eXpoSlMyVUJoaXYzY05YUVBj?= =?utf-8?B?cE5zU3ZxOFNDbWxuOHB4ZGJmN1F0TUEzb1JTZTJ1YUxKRDF0dXFBdURaN1NJ?= =?utf-8?B?ZmNyWWJBbVVpbTZYWWY0RUQ3QVU1UG5nbHJNbFFBZUs2cHNJMnRCblhPWDFS?= =?utf-8?B?d2hPbER0NHJ3MEdGUTlIUmdwUTdDOGRqTCs0R1J3Wm0yaGdYRXVGVmFnM0h1?= =?utf-8?B?SHNEc3cxUXREREtOaDdHRkhTV3U2L3Q3dmJ6OTlVTmV0L3ZYKzNHZUIyZFND?= =?utf-8?B?a1hCeGd5WWFsS2NDNTJsYTlKaU9PcGg1VzN0ZWJ3a1AwUXVjWGNnUDhUOWZM?= =?utf-8?B?SjNPRWRUeUJvUHpFQ2huNk1hN2ZtVWlNYWszalo3Zy9QNWx1ZTRMaHFjaks4?= =?utf-8?B?MFdzOTBvZEtXc2NMa2pIdXFNdEhaTGVLcCs5Z09kTGd2NEdOK2JRNk5CVEdW?= =?utf-8?B?TkFtSjdOKzJQSzhCWUdiUnNJZzRTUTcrbGNIMGtoSjA4TkNUVVh3Nk1ySkF2?= =?utf-8?B?USs4V3FxRTMvRDNGL1RYbWI0MENVN3pNTCs1SUVvbFhUTi81dG9IZlhLcTN4?= =?utf-8?B?OHhWQVhVbDZaVWZmQThqR3JWUXlVbFBTZUErUk9DNVR3VmkzRSt0MFdSNW9q?= =?utf-8?B?TXV1dHQxTkc2NCs4ZHR5UDAxY2ViVU1GOHBvOWorVjB0Q2laRnVnVE8wWFVj?= =?utf-8?B?ZDZlcWorYmZKRDU4bXJqVFZBdGduaHN2bWFMa3FCYUQwQnp5cERSYUVVR2ph?= =?utf-8?B?amxyZlNEUittYVd3UE9UTzZvNmFKa2NtL202Z053L2JpSlcvR3dTaFd1OXRo?= =?utf-8?B?Ty9sSGtKRmlSMW82Tng4MVBTOWdrSmlLMGRHSU5vZmZjZEpnallPS053bFRu?= =?utf-8?Q?43Jk9sfxNf30E8TF0cWp0XVafLujxi/rl/IexdS?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR11MB380214E9B6546245A931F46ED3B69DM6PR11MB3802namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3802.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 80a34884-f1bc-489c-9790-08d98d989292 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2021 15:54:28.2202 (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: LUcv9C8fUD8h0AiqruYMIUjj09FbtKlImNaADRNlJphIw2eB7gUsZ3aCcnQ+4csQutRBPgZX2absSdV1QQTU2Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4153 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.22, xbe-rcd-007.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 12 Oct 2021 15:55:22 -0000 --_000_DM6PR11MB380214E9B6546245A931F46ED3B69DM6PR11MB3802namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgV0csDQoNClRoZSBkcmFmdCBpcyBiYXNlZCBvbiBTUnY2IGRhdGEgcGxhbmUgd2l0aCBmbGF2 b3JzIGRlZmluZWQgZm9yIFNSdjYgY29tcHJlc3Npb24sIGFzIHBlciBSRkM4OTg2LiBJdCBpcyBj b2hlcmVudCB3aXRoIHRoZSBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiBvYmplY3RpdmUuDQpJIHN0 cm9uZ2x5IHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoZSBkcmFmdC4NCg0KVGhhbmtzLA0KTWlr ZS4NCg0KRnJvbTogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9m IEphbWVzIEd1aWNoYXJkDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMSwgMjAyMSAxMDowNSBBTQ0K VG86IFNQUklORyBXRyA8c3ByaW5nQGlldGYub3JnPg0KQ2M6IHNwcmluZy1jaGFpcnNAaWV0Zi5v cmcNClN1YmplY3Q6IFtzcHJpbmddIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNv bXByZXNzaW9uLw0KDQpEZWFyIFdHOg0KDQpUaGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gZXhwcmVz cyB0aGVpciBhcHByZWNpYXRpb24gZm9yIGFsbCB0aGUgcmVzcG9uc2VzIHJlY2VpdmVkIHRvIG91 ciBlbWFpbHMgd2l0aCByZWZlcmVuY2UgdG8gaG93IHRoZSB3b3JraW5nIGdyb3VwIHdpc2hlcyB0 byBtb3ZlIGZvcndhcmQgd2l0aCByZXNwZWN0IHRvIGEgc29sdXRpb24gZm9yIFNSdjYgY29tcHJl c3Npb24uDQoNClRoZSBhcHBhcmVudCBpbmNsaW5hdGlvbiBvZiB0aGUgd29ya2luZyBncm91cCBp cyB0byB1c2UgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNj aGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vIGFzIHRoZSBiYXNpcyBmb3IgaXRzIGNv bXByZXNzaW9uIHN0YW5kYXJkaXphdGlvbiB3b3JrLiBUaGF0IGlzIHBhcnQgb2Ygd2hhdCB0aGlz IGVtYWlsIGF0dGVtcHRzIHRvIGNvbmZpcm0uDQoNCkJlY2F1c2Ugb2YgdGhlIGFib3ZlIHRoZSBj aGFpcnMgd291bGQgbGlrZSB0byBpc3N1ZSBhIDItd2VlayBXRyBjYWxsIGZvciBhZG9wdGlvbiBl bmRpbmcgT2N0b2JlciAxNXRoIGZvciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8gYnV0IHdpdGgg c29tZSBjbGVhciBndWlkZWxpbmVzIGFzIGZvbGxvd3MuIEJ5IGV4cHJlc3Npbmcgc3VwcG9ydCBm b3IgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCB5b3UgYXJlIGZ1bGx5IGF3YXJlIG9mIGFuZCBh cmUgYWNrbm93bGVkZ2luZyB0aGF0Og0KDQoNCiAgMS4gIFRoZSBTUFJJTkcgd29ya2luZyBncm91 cCBpcyBhZG9wdGluZyBhIGRvY3VtZW50IHRoYXQgaGFzIG11bHRpcGxlIFNSdjYgRW5kcG9pbnQg YmVoYXZpb3JzLg0KICAyLiAgVGhlIGRvY3VtZW50IGlzIGEg4oCcbGl2aW5n4oCdIGRvY3VtZW50 OyBpdCBtYXkgY2hhbmdlIGFzIGl0IGdvZXMgdGhyb3VnaCByZXZpZXcgYW5kIGFuYWx5c2lzIGJ5 IHRoZSBTUFJJTkcgd29ya2luZyBncm91cC4NCiAgMy4gIEFsbCBvcGVuIGRpc2N1c3Npb24gcG9p bnRzIHJhaXNlZCBvbiBvdXIgbWFpbGluZyBsaXN0IE1VU1QgYmUgYWRkcmVzc2VkIEJFRk9SRSBz YWlkIGRvY3VtZW50IGlzIGFsbG93ZWQgdG8gcHJvZ3Jlc3MgZnJvbSB0aGUgd29ya2luZyBncm91 cCB0byBwdWJsaWNhdGlvbi4gQSBsaXN0IG9mIHRoZXNlIGRpc2N1c3Npb24gcG9pbnRzIHdpbGwg YmUgZG9jdW1lbnRlZCBpbiB0aGUgV0cgZG9jdW1lbnQgYW5kIG1haW50YWluZWQgYnkgdGhlIGRv Y3VtZW50IGVkaXRvciBpbiBjb25qdW5jdGlvbiB3aXRoIHRoZSBjaGFpcnMuDQogIDQuICBJZiB0 aGlzIGRvY3VtZW50IGlzIGFkb3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAsIHRoZSBjaGFpcnMg c3BlY2lmeSBhcyBwYXJ0IG9mIHRoZSBhZG9wdGlvbiBjYWxsIHRoYXQgdGhlIGZvbGxvd2luZyB0 ZXh0IGRlc2NyaWJpbmcgYW4gb3BlbiBpc3N1ZSBiZSBhZGRlZCB0byB0aGUgZG9jdW1lbnQgaW4g dGhlIGFib3ZlLWRlc2NyaWJlZCBvcGVuIGlzc3VlcyBzZWN0aW9uOg0KICAgICAqICAgIkdpdmVu IHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHNhaWQgdGhhdCBpdCB3YW50cyB0byBzdGFuZGFy ZGl6ZSBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiwgYW5kIGdpdmVuIHRoYXQgdGhlIGRvY3VtZW50 IGNvbnRhaW5zIG11bHRpcGxlIFNSdjYgRW5kUG9pbnQgYmVoYXZpb3JzIHRoYXQgc29tZSBXRyBt ZW1iZXJzIGhhdmUgc3RhdGVkIGFyZSBtdWx0aXBsZSBkYXRhIHBsYW5lIHNvbHV0aW9ucywgdGhl IHdvcmtpbmcgZ3JvdXAgd2lsbCBhZGRyZXNzIHdoZXRoZXIgdGhpcyBpcyB2YWxpZCBhbmQgY29o ZXJlbnQgd2l0aCBpdHMgb25lIGRhdGEgcGxhbmUgc29sdXRpb24gb2JqZWN0aXZlLiIuDQoNClBs ZWFzZSBjb25zaWRlciB0aGUgYWJvdmUgZ3VpZGVsaW5lcyBhcyB5b3UgZGVjaWRlIG9uIHdoZXRo ZXIgdG8gc3VwcG9ydCBvciBub3QgdGhpcyBXRyBhZG9wdGlvbi4gUGxlYXNlIGV4cHJlc3MgY2xl YXJseSB5b3VyIHJlYXNvbmluZyBmb3Igc3VwcG9ydC9ub24tc3VwcG9ydCBhcyB3ZWxsIGFzIGFu eSBvcGVuIGRpc2N1c3Npb24gcG9pbnRzIHlvdSB3b3VsZCBsaWtlIGFkZHJlc3NlZCBzaG91bGQg dGhlIGRvY3VtZW50IGJlIGFkb3B0ZWQgaW50byB0aGUgd29ya2luZyBncm91cC4NCg0KVGhhbmtz IQ0KDQpKaW0sIEJydW5vICYgSm9lbA0KDQoNCg== --_000_DM6PR11MB380214E9B6546245A931F46ED3B69DM6PR11MB3802namp_ 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 Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNv UGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxh aW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28t bGlzdC1pZDo3NTE2OTkzOTM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOi03MjE2NTQ3NzYgNjc2OTg3MDMgNjc2OTg2ODkgNjc2OTg3MTUgNjc2OTg3MDMg Njc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1p bmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDENCgl7 bXNvLWxpc3QtaWQ6MTE2MjMwOTg2MDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjA4MDU2MTAy Njt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0eWxlPSJ3b3Jk LXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGkgV0csPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkcmFmdCBpcyBi YXNlZCBvbiBTUnY2IGRhdGEgcGxhbmUgd2l0aCBmbGF2b3JzIGRlZmluZWQgZm9yIFNSdjYgY29t cHJlc3Npb24sIGFzIHBlciBSRkM4OTg2LiBJdCBpcw0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5jb2hlcmVudCB3aXRoIHRoZSBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiBvYmplY3RpdmUuIDxv OnA+DQo8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj5JIHN0cm9uZ2x5IHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIHRoZSBkcmFm dC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlrZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAw aW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBzcHJpbmcgJmx0O3Nw cmluZy1ib3VuY2VzQGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5KYW1lcyBHdWlj aGFyZDxicj4NCjxiPlNlbnQ6PC9iPiBGcmlkYXksIE9jdG9iZXIgMSwgMjAyMSAxMDowNSBBTTxi cj4NCjxiPlRvOjwvYj4gU1BSSU5HIFdHICZsdDtzcHJpbmdAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiBzcHJpbmctY2hhaXJzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFtzcHJp bmddIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBXRzo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGV4cHJlc3MgdGhlaXIgYXBwcmVjaWF0 aW9uIGZvciBhbGwgdGhlIHJlc3BvbnNlcyByZWNlaXZlZCB0byBvdXIgZW1haWxzIHdpdGggcmVm ZXJlbmNlIHRvIGhvdyB0aGUgd29ya2luZyBncm91cCB3aXNoZXMgdG8gbW92ZSBmb3J3YXJkIHdp dGggcmVzcGVjdCB0byBhIHNvbHV0aW9uIGZvciBTUnY2IGNvbXByZXNzaW9uLg0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoZSBhcHBhcmVudCBpbmNsaW5hdGlvbiBvZiB0aGUgd29ya2luZyBn cm91cCBpcyB0byB1c2UgPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vIj4NCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNy djYtc3JoLWNvbXByZXNzaW9uLzwvYT4gYXMgdGhlIGJhc2lzIGZvciBpdHMgY29tcHJlc3Npb24g c3RhbmRhcmRpemF0aW9uIHdvcmsuIFRoYXQgaXMgcGFydCBvZiB3aGF0IHRoaXMgZW1haWwgYXR0 ZW1wdHMgdG8gY29uZmlybS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVjYXVzZSBvZiB0aGUg YWJvdmUgdGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGlzc3VlIGEgMi13ZWVrIFdHIGNhbGwgZm9y IGFkb3B0aW9uIGVuZGluZyBPY3RvYmVyIDE1PHN1cD50aDwvc3VwPiBmb3INCjxhIGhyZWY9Imh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5n LXNydjYtc3JoLWNvbXByZXNzaW9uLyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88L2E+IGJ1 dCB3aXRoIHNvbWUgY2xlYXIgZ3VpZGVsaW5lcyBhcyBmb2xsb3dzLiBCeSBleHByZXNzaW5nIHN1 cHBvcnQgZm9yIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgeW91IGFyZSBmdWxseSBhd2FyZSBv ZiBhbmQgYXJlIGFja25vd2xlZGdpbmcgdGhhdDoNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6 MGluIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0 eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPlRoZSBTUFJJTkcg d29ya2luZyBncm91cCBpcyBhZG9wdGluZyBhIGRvY3VtZW50IHRoYXQgaGFzIG11bHRpcGxlIFNS djYgRW5kcG9pbnQgYmVoYXZpb3JzLg0KPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZv MyI+VGhlIGRvY3VtZW50IGlzIGEg4oCcbGl2aW5n4oCdIGRvY3VtZW50OyBpdCBtYXkgY2hhbmdl IGFzIGl0IGdvZXMgdGhyb3VnaCByZXZpZXcgYW5kIGFuYWx5c2lzIGJ5IHRoZSBTUFJJTkcgd29y a2luZyBncm91cC4NCjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPkFsbCBvcGVu IGRpc2N1c3Npb24gcG9pbnRzIHJhaXNlZCBvbiBvdXIgbWFpbGluZyBsaXN0IE1VU1QgYmUgYWRk cmVzc2VkIEJFRk9SRSBzYWlkIGRvY3VtZW50IGlzIGFsbG93ZWQgdG8gcHJvZ3Jlc3MgZnJvbSB0 aGUgd29ya2luZyBncm91cCB0byBwdWJsaWNhdGlvbi4gQSBsaXN0IG9mIHRoZXNlIGRpc2N1c3Np b24NCiBwb2ludHMgd2lsbCBiZSBkb2N1bWVudGVkIGluIHRoZSBXRyBkb2N1bWVudCBhbmQgbWFp bnRhaW5lZCBieSB0aGUgZG9jdW1lbnQgZWRpdG9yIGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIGNo YWlycy4NCjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPklmIHRoaXMgZG9jdW1l bnQgaXMgYWRvcHRlZCBieSB0aGUgd29ya2luZyBncm91cCwgdGhlIGNoYWlycyBzcGVjaWZ5IGFz IHBhcnQgb2YgdGhlIGFkb3B0aW9uIGNhbGwgdGhhdCB0aGUgZm9sbG93aW5nIHRleHQgZGVzY3Jp YmluZyBhbiBvcGVuIGlzc3VlIGJlIGFkZGVkIHRvIHRoZSBkb2N1bWVudCBpbiB0aGUgYWJvdmUt ZGVzY3JpYmVkDQogb3BlbiBpc3N1ZXMgc2VjdGlvbjo8bzpwPjwvbzpwPjwvbGk+PHVsIHN0eWxl PSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1zby1saXN0OmwwIGxldmVsMiBsZm8zIj4mcXVvdDtHaXZlbiB0aGF0IHRoZSB3b3Jr aW5nIGdyb3VwIGhhcyBzYWlkIHRoYXQgaXQgd2FudHMgdG8gc3RhbmRhcmRpemUgb25lIGRhdGEg cGxhbmUgc29sdXRpb24sIGFuZCBnaXZlbiB0aGF0IHRoZSBkb2N1bWVudCBjb250YWlucyBtdWx0 aXBsZSBTUnY2IEVuZFBvaW50IGJlaGF2aW9ycyB0aGF0IHNvbWUgV0cgbWVtYmVycyBoYXZlIHN0 YXRlZCBhcmUNCiBtdWx0aXBsZSBkYXRhIHBsYW5lIHNvbHV0aW9ucywgdGhlIHdvcmtpbmcgZ3Jv dXAgd2lsbCBhZGRyZXNzIHdoZXRoZXIgdGhpcyBpcyB2YWxpZCBhbmQgY29oZXJlbnQgd2l0aCBp dHMgb25lIGRhdGEgcGxhbmUgc29sdXRpb24gb2JqZWN0aXZlLiZxdW90Oy48bzpwPjwvbzpwPjwv bGk+PC91bD4NCjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBsZWFzZSBjb25zaWRlciB0aGUgYWJvdmUgZ3VpZGVs aW5lcyBhcyB5b3UgZGVjaWRlIG9uIHdoZXRoZXIgdG8gc3VwcG9ydCBvciBub3QgdGhpcyBXRyBh ZG9wdGlvbi4gUGxlYXNlIGV4cHJlc3MgY2xlYXJseSB5b3VyIHJlYXNvbmluZyBmb3Igc3VwcG9y dC9ub24tc3VwcG9ydCBhcyB3ZWxsIGFzIGFueSBvcGVuIGRpc2N1c3Npb24gcG9pbnRzIHlvdSB3 b3VsZCBsaWtlIGFkZHJlc3NlZCBzaG91bGQgdGhlIGRvY3VtZW50DQogYmUgYWRvcHRlZCBpbnRv IHRoZSB3b3JraW5nIGdyb3VwLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MhPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkppbSwgQnJ1bm8gJmFtcDsgSm9lbDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DM6PR11MB380214E9B6546245A931F46ED3B69DM6PR11MB3802namp_-- From nobody Tue Oct 12 09:04:22 2021 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 9D8263A1620; Tue, 12 Oct 2021 09:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BObgtQra-21m; Tue, 12 Oct 2021 09:04:15 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBCF33A161D; Tue, 12 Oct 2021 09:04:14 -0700 (PDT) X-Envelope-To: 6man@ietf.org Received: from cupcake.local (089-101-195156.ntlworld.ie [89.101.195.156] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 19CG419r066044 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 12 Oct 2021 17:04:02 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-195156.ntlworld.ie [89.101.195.156] (may be forged) claimed to be cupcake.local To: "Darren Dukes (ddukes)" Cc: "6man@ietf.org" <6man@ietf.org>, SPRING WG References: From: Nick Hilliard Message-ID: <317cee11-c2c9-a012-a8cf-1563a719dee9@foobar.org> Date: Tue, 12 Oct 2021 17:04:00 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.49 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 12 Oct 2021 16:04:20 -0000 Good to hear. This doesn't address compatibility with 8200 and 4291 though, which seems to be the bit that's causing people concern. Nick Darren Dukes (ddukes) wrote on 12/10/2021 16:46: > Hi Nick, during review of RFC8986, section 3.2 was added. SID > allocation follows that. > > Darren > > On 2021-10-12, 10:40 AM, "Nick Hilliard" wrote: > > > > Darren Dukes (ddukes) wrote on 12/10/2021 15:35: > > Given this, it is clear, the CSID flavors of the same SRv6 SIDs defined > > in RFC8986 are also IPv6 addresses. > > Ok, this is good that we're all on the same page about SIDs being IPv6 > addresses. This means that they and > draft-filsfilscheng-spring-srv6-srh-compression need to comply with 8200 > and 4291, and it looks to me like the draft does not. > > Nick > From nobody Tue Oct 12 09:34:18 2021 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 5D00E3A1643; Tue, 12 Oct 2021 09:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 FmHzhp007ydG; Tue, 12 Oct 2021 09:33:46 -0700 (PDT) Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAE823A0B08; Tue, 12 Oct 2021 09:33:45 -0700 (PDT) Received: by mail-il1-x130.google.com with SMTP id y17so22282541ilb.9; Tue, 12 Oct 2021 09:33:45 -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:content-transfer-encoding; bh=E2SK4KLb/mpoBUh+4OkLKEdtzQzbrJ0gcNU6ZsTlGOw=; b=OXqzvPelI78qfA0bGKfu7HRxHMFeqU4IBBZRPKd0/lISX8UORqgvT7J7q8pHv9QOjl KF4yG+epYbk2lPGu1sbozxIe/LZvLyvXOhG6HDzIJr2g675kwNX5CjlLEmyUu+LPURW6 7p+sCsG8OqciAX8TqfVDE9BB7+DiadXcfRKTiDX1NdH5CrrPwdSCVtKqVNXkmORwF5RJ 8fZ0Zk/Arn76kVaaroVNNbhFWd1v+sHL3OkpnqSANOWUoThGm4sKaUWjEAMNNW5AsRoL 76l7/ahMRSkROXhSkVmL2m//huGzqW8FRFJb/aSSyRwDvlSg9f1HFFqVhGQ0Zb8RjnoX UCrA== 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:content-transfer-encoding; bh=E2SK4KLb/mpoBUh+4OkLKEdtzQzbrJ0gcNU6ZsTlGOw=; b=Nh3XlCf80PvsSp1OqORF1xAebgIq+b8bBGTS19r35JdP7gg/e6rnUR7VBfK5E4AasW qh23fosZElr7kK0p2zNx49vm1m8e8iKgLeBgzk1eWXHNPHC+vw/U+1IsQgR6kA40eogc sLsSwfwqdXk09VNE3MmTqslS9cx/Jlr4ggVBBthIpEYfIj0u/RyPcN59UR6JItkEvrKh KAh0xH9TI7NwVcl4cW1ZLUKBZhcqUBKwf6AQBLC0Bb74riZtaTdhTXs6fmV9URmZ3pGo BPbFA5P6xwwI+uqGLgomUE4mZr+mIi366Rt1wA8H+zBGsdKr9QJkOkR8Z0s24btD7vDI 8B9A== X-Gm-Message-State: AOAM532UAH0fVYiLxBiVIi+1vWPu5Eiol/c0oRKU6urdvVthYT4hXqEw DTw23l7lYA5rTnAkckmV+i8TryQLo1EvT9I23SAjZy4GFes= X-Google-Smtp-Source: ABdhPJz7KrA5EiurziJLf3yJ1xMZxKTjXrA4Fan80sV0MoDksEM7FLl1FLXurBbt4w2MS56ptx+Tb93qoIJ8A9hmN5w= X-Received: by 2002:a05:6e02:1649:: with SMTP id v9mr2631186ilu.171.1634056425053; Tue, 12 Oct 2021 09:33:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mark Smith Date: Wed, 13 Oct 2021 03:33:18 +1100 Message-ID: To: James Guichard Cc: SPRING WG , "spring-chairs@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 12 Oct 2021 16:34:00 -0000 Dear Chairs, I object to the WG adopting this draft. If SIDs are IPv6 addresses, then this draft is fundamentally relying on encoding a segment list of SIDs (with a common high order prefix), and therefore a list of multiple IPv6 addresses, in the IPv6 Destination Address field. Clearly the IPv6 DA field is to only carry a single IPv6 address - it would be called the IPv6 Destination Addresses or perhaps IPv6 Destination Address List field if it were to contain a list of IPv6 addresses (SIDs). As far as I can see, it would not be possible to remove this multiple-SID/address encoding in the single IPv6 DA address field from this draft without invalidating the entire draft. Adoption by the WG will not fix that. Being able to implement it does not make it a good idea. It just shows it is not impossible to implement. There are other ways SIDs could be compressed that also comply with the IPv6 RFCs - firstly by starting having a much smaller yet quite adequate SID size, such as 32 bits, or the 20 bit size used with SR-MPLS, and then encoding the single smaller SID value in an IPv6 address, when the SID is placed into an IPv6 DA field, such as how 32 bit IPv4 addresses are encoded in IPv6 addresses, per RFC4291, 2.5.5. IPv6 Addresses with Embedded IPv4 Addresses. Regards, Mark. On Sat, 2 Oct 2021 at 00:05, James Guichard wrote: > > Dear WG: > > > > The chairs would like to express their appreciation for all the responses= received to our emails with reference to how the working group wishes to m= ove forward with respect to a solution for SRv6 compression. > > > > The apparent inclination of the working group is to use https://datatrack= er.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the bas= is for its compression standardization work. That is part of what this emai= l attempts to confirm. > > > > Because of the above the chairs would like to issue a 2-week WG call for = adoption ending October 15th for https://datatracker.ietf.org/doc/draft-fil= sfilscheng-spring-srv6-srh-compression/ but with some clear guidelines as f= ollows. By expressing support for adoption of this document you are fully a= ware of and are acknowledging that: > > > > The SPRING working group is adopting a document that has multiple SRv6 En= dpoint behaviors. > The document is a =E2=80=9Cliving=E2=80=9D document; it may change as it = goes through review and analysis by the SPRING working group. > All open discussion points raised on our mailing list MUST be addressed B= EFORE said document is allowed to progress from the working group to public= ation. A list of these discussion points will be documented in the WG docum= ent and maintained by the document editor in conjunction with the chairs. > If this document is adopted by the working group, the chairs specify as p= art of the adoption call that the following text describing an open issue b= e added to the document in the above-described open issues section: > > "Given that the working group has said that it wants to standardize one d= ata plane solution, and given that the document contains multiple SRv6 EndP= oint behaviors that some WG members have stated are multiple data plane sol= utions, the working group will address whether this is valid and coherent w= ith its one data plane solution objective.". > > > > Please consider the above guidelines as you decide on whether to support = or not this WG adoption. Please express clearly your reasoning for support/= non-support as well as any open discussion points you would like addressed = should the document be adopted into the working group. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Tue Oct 12 11:32:36 2021 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 D7F1C3A00C3 for ; Tue, 12 Oct 2021 11:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uniroma1.it 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 P4Fep46kP4-6 for ; Tue, 12 Oct 2021 11:32:30 -0700 (PDT) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFB83A0651 for ; Tue, 12 Oct 2021 11:32:29 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id t16so2952198eds.9 for ; Tue, 12 Oct 2021 11:32:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniroma1.it; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=dfdQgCBZFXejIQH+7fH2eeHtahyX9YvBVu1kAhCGuTg=; b=w0wG0KEa7cT4RBoZQE7RMbTxK0V4MgyvFPtxwWr0SPN9YklD69niGhpN/2/+xdb19b +opXwlSrVUMVJ3MRWY+4ct5LRleaPEU3i7feg5RZlVtyeB7FrOYiPAdT/+2itUDvjgOi v609H3GAI2sccWXpbjpk7hUHtiXYMHC1K9Dt+DddQglY2u8xRgV+uDde8n5A5DQBlROj 80YrtKjm5S6m+x1EgiYNYI5ug7Zz6ALRQwqi5EEIWS0eYrTZrl/+a/p4U7dNx2y3XCX3 T5YcDA1CV0vkm6N/M0pswgVj90XdrOTC/YWxm5Qmut9dHvtpxAenGOSqxOBFA1cBuyyI dh0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=dfdQgCBZFXejIQH+7fH2eeHtahyX9YvBVu1kAhCGuTg=; b=jbVyvv4CIv5nOhtjg09SYx/4ydjl4HFS3gAVCXhsS8U1/dvdux6KchymxnL49grDOZ gALhPV2XPnb3wAcDsDgI4BWG5Er1Y1h3r+EPOcPtWMwu7H0qmuWPOtM5U/0vyxhE2pDz /bTlAHGLuGIFTnfulgX5Z8l4cnEm5u1HI9Gi+OYhM/jP71ieJJry2/H0Va31/5UM9TAH HmgkwtInkI7xB3F0dUefRnTlDtlZrQG79Lfqukqan9HXrnSneWjhj83JhXthj0GszgsV eI7YPQapexyiAm+avHp7Ran+Y7BtN7at0oZaxBpQHE8tF44VZgBQIUhlRy+o/vIQLlaV Hkpg== X-Gm-Message-State: AOAM530gjdhWboNJsMQIvHcMVLWp1vv7Pdpf7af/8X76J9ljSxkSTF6m CtjNb8bR1ukdvdbtY9SNxzPQnk9TR7A84m+8QRQYNekkBOO1nCx4Rs9IJznRH7qts5x8M1+t1Xn ZXmUJJ+LK X-Google-Smtp-Source: ABdhPJzDQF0N4sKwTR38QSQyjJvdfK6uBL7ctsPhLbw7b/RmMH+4Q9kBV3sG7G/rO6KrqkOvd3qykg== X-Received: by 2002:a05:6402:3588:: with SMTP id y8mr1813688edc.285.1634063546241; Tue, 12 Oct 2021 11:32:26 -0700 (PDT) Received: from MBP-di-David.fritz.box ([77.39.166.130]) by smtp.gmail.com with ESMTPSA id l16sm5241032eje.67.2021.10.12.11.32.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Oct 2021 11:32:25 -0700 (PDT) To: James Guichard Cc: "spring-chairs@ietf.org" , SPRING WG References: From: David Lo Bascio Message-ID: <890e2687-7f93-31be-8133-b394dbf9bf7e@uniroma1.it> Date: Tue, 12 Oct 2021 20:32:24 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------65E1840C9B22698207F1889D" Content-Language: it Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 12 Oct 2021 18:32:35 -0000 This is a multi-part message in MIME format. --------------65E1840C9B22698207F1889D Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable I support the WG adoption of draft-filsfilscheng-spring-srv6-srh-compressio= n. My research activity is related on leveraging SRv6 to implement a container= ized SFC on Kubernetes. The new flavors added to the SR endpoint behaviors will be useful to this s= cope, simplifying the processing on each cluster node. It is quite clear to me they belong to a singe SRv6 data plane. -- David Lo Bascio PhD Student in ICT Department of Information Engineering, Electronics and Telecommunications (DIET) Sapienza University of Rome +39 331 63 51 362 david.lobascio@uniroma1.it Il 01/10/21 16:04, James Guichard ha scritto: > > Dear WG: > > The chairs would like to express their appreciation for all the=20 > responses received to our emails with reference to how the working=20 > group wishes to move forward with respect to a solution for SRv6=20 > compression. > > The apparent inclination of the working group is to use=20 > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/=20 > =20 > as the basis for its compression standardization work. That is part of=20 > what this email attempts to confirm. > > Because of the above the chairs would like to issue a 2-week WG call=20 > for adoption ending October 15^th for=20 > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/=20 > =20 > but with some clear guidelines as follows. By expressing support for=20 > adoption of this document you are fully aware of and are acknowledging=20 > that: > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change as= it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the > working group to publication. A list of these discussion points > will be documented in the WG document and maintained by the > document editor in conjunction with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text > describing an open issue be added to the document in the > above-described open issues section: > * "Given that the working group has said that it wants to > standardize one data plane solution, and given that the > document contains multiple SRv6 EndPoint behaviors that some > WG members have stated are multiple data plane solutions, the > working group will address whether this is valid and coherent > with its one data plane solution objective.". > > Please consider the above guidelines as you decide on whether to=20 > support or not this WG adoption. Please express clearly your reasoning=20 > for support/non-support as well as any open discussion points you=20 > would like addressed should the document be adopted into the working=20 > group. > > Thanks! > > Jim, Bruno & Joel > --=20 ________________________________________________________ Le informazioni=20 contenute in questo messaggio di posta elettronica sono strettamente=20 riservate e indirizzate esclusivamente al destinatario. Si prega di non=20 leggere, fare copia, inoltrare a terzi o conservare tale messaggio se non= =20 si =C3=A8 il legittimo destinatario dello stesso. Qualora tale messaggio si= a=20 stato ricevuto per errore, si prega di restituirlo al mittente e di=20 cancellarlo permanentemente dal proprio computer. The information contained=20 in this e mail message is strictly confidential and intended for the use of= =20 the addressee only.=C2=A0 If you are not the intended recipient, please do = not=20 read, copy, forward or store it on your computer. If you have received the= =20 message in error, please forward it back to the sender and delete it=20 permanently from your computer system. --------------65E1840C9B22698207F1889D Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
    I support the WG adoption of draft-filsfilscheng-spring-srv6-srh=
-compression.
My research activity is related on leveraging SRv6 to implement a container=
ized SFC on Kubernetes.
The new flavors added to the SR endpoint behaviors will be useful to this s=
cope, simplifying the processing on each cluster node.
It is quite clear to me they belong to a singe SRv6 data plane.

--
David Lo Bascio
PhD Student in ICT
Department of Information Engineering,=20
Electronics and Telecommunications (DIET)
Sapienza University of Rome
+39 331 63 51 362
david.lobascio@uniroma1.it


    Il 01/10/21 16:04, James Guichard ha scritto:

    Dear WG:

    =C2=A0

    The chairs would like to express their appreciation for all the responses received to our emails with reference to how the working group wishes to move forward with respect to a solution for SRv6 compression.

    =C2=A0

    The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft= -filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardization work. That is part of what this email attempts to confirm.

    =C2=A0

    Because of the above the chairs would like to issue a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft= -filsfilscheng-spring-srv6-srh-compression/ but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that:

    =C2=A0

    1. The SPRING working group is adopting a document that has multiple SRv6 Endpoint behaviors.
    2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change as it goe= s through review and analysis by the SPRING working group.
    3. All open discussion points raised on our mailing list MUST be addressed BEFORE said document is allowed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maintained by the document editor in conjunction with the chairs.
    4. If this document is adopted by the working group, the chairs specify as part of the adoption call that the following text describing an open issue be added to the document in the above-described open issues section:
      • "G= iven that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this is valid and coherent with its one data plane solution objective.".

    =C2=A0

    Please consider the above guidelines as you decide on whether to support or not this WG adoption. Please express clearly your reasoning for support/non-support as well as any open discussion points you would like addressed should the document be adopted into the working group.

    =C2=A0

    Thanks!

    =C2=A0

    Jim, Bruno & Joel

    =C2=A0

    =C2=A0



    _= _______________________________________________________<= /div>Le informazioni contenute i= n questo messaggio di posta elettronica sono strettamente riservate e indir= izzate esclusivamente al destinatario. Si prega di non leggere, fare copia,= inoltrare a terzi o conservare tale messaggio se non si =C3=A8 il legittim= o destinatario dello stesso. Qualora tale messaggio sia stato ricevuto per = errore, si prega di restituirlo al mittente e di cancellarlo permanentement= e dal proprio computer.
    The information contained in this e mail message is strictly confident= ial and intended for the use of the addressee only.=C2=A0 If you are not th= e intended recipient, please do not read, copy, forward or store it on your= computer. If you have received the message in error, please forward it bac= k to the sender and delete it permanently from your computer system.=
    --------------65E1840C9B22698207F1889D-- From nobody Tue Oct 12 12:47:43 2021 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 E15FA3A053E; Tue, 12 Oct 2021 12:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FVzwnDKUamh8; Tue, 12 Oct 2021 12:47:37 -0700 (PDT) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 CF1AE3A058F; Tue, 12 Oct 2021 12:47:37 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id a73so165892pge.0; Tue, 12 Oct 2021 12:47:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Jl7JTXBgeCgv0XNwyglsy/57edr8ap7C+xbMi0WIW9Y=; b=RjPYuKGynUSNAYvkKPmNbPg1tNZDyc5aY1RWKIiU66kadmQcf2sUK+UckAcr6acmB4 m2eSWwpjauP96A7vO5IZfkTt6pJx6xjGl5GKpIbt2ZiV3sqcz2M0WvYk1QtrW9D9GMr0 NRqC/g9t21xIYjIseACJlUBrKL5ULGQzzC9LIRdSFifHAHNiUMfEvcV0uF5MsqePWQEn Tt3iJPvpu2QEdsAvFO79tGCUMyFZaWC6Yb8d8Tdu2Vw0RkVeaCwGED/bLVTXLBnfsKIr lcBSGMx4jqmkdcGvH/dw24Q1FCpMWhiPDP0MjbPOeCcxV0HpYuGGLjGDsrkpLusmbzQU S4Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Jl7JTXBgeCgv0XNwyglsy/57edr8ap7C+xbMi0WIW9Y=; b=Y27v+W1Th2dK8aMdQRNtXTYtQpBxY2GJRbb7XTiaJAABr40t8H/vbxq2vtIZo7oiUt R34eGfMQ8iHQ9jvsmkyarDKlgjYUSeggBMxQZuu7PMzfojJom4WQKcdqd6o+Na+H33iY ZDWSVSlJZAg0WDatpP+Fgp53EBhfME0sighrRRB4Z3u2zmLsmnpubgRJZLIWQ7Nna/3Y uscyhmkQYk4G8wAr8+HTcPxw7+hP6AOcc9+ETUNjI9t+ShCPHjqv5MDA7sag2yPYzjDx G3oxYNBhuLq2x4c2rEoktrB6NZDuruhdcXWfVmMcIflTklFIisjICFuAGYNKqFeXOgs7 fUxw== X-Gm-Message-State: AOAM530SeA6aZ99yxExwlKYfxy7kgAThA2pgsAd52S5vMD4sxyo9LtTr Ra99fMHlo8ggQpCj5JhjK6DkH1Pop+Otrw== X-Google-Smtp-Source: ABdhPJzeyvsaP6ciDw+hH/LLvAiV9Z2fVYvKePBaeZal98gcoy51chhqI006VGYJTl3FgBagLFgnyw== X-Received: by 2002:aa7:8d09:0:b0:44b:fd25:dd8a with SMTP id j9-20020aa78d09000000b0044bfd25dd8amr33832055pfe.41.1634068056022; Tue, 12 Oct 2021 12:47:36 -0700 (PDT) Received: from ?IPv6:2406:e003:1018:b901:db7:d041:a2d:ce65? ([2406:e003:1018:b901:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id w15sm11845546pfc.220.2021.10.12.12.47.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Oct 2021 12:47:35 -0700 (PDT) To: Nick Hilliard , "Darren Dukes (ddukes)" Cc: SPRING WG , "6man@ietf.org" <6man@ietf.org> References: <317cee11-c2c9-a012-a8cf-1563a719dee9@foobar.org> From: Brian E Carpenter Message-ID: Date: Wed, 13 Oct 2021 08:47:32 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <317cee11-c2c9-a012-a8cf-1563a719dee9@foobar.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 12 Oct 2021 19:47:42 -0000 Could somebody provide a copious set of *example* IPv6 addresses that con= form to draft-filsfilscheng-spring-srv6-srh-compression? I means the actual addresses in standard IPv6 address notation (RFC5952) = or just as 0x.... hex numbers. BTW, is there running code for srv6-srh-compression? Regards Brian Carpenter On 13-Oct-21 05:04, Nick Hilliard wrote: > Good to hear. This doesn't address compatibility with 8200 and 4291=20 > though, which seems to be the bit that's causing people concern. >=20 > Nick >=20 > Darren Dukes (ddukes) wrote on 12/10/2021 16:46: >> Hi Nick, during review of RFC8986, section 3.2 was added.=C2=A0 SID=20 >> allocation follows that. >> >> Darren >> >> On 2021-10-12, 10:40 AM, "Nick Hilliard" wrote: >> >> >> >> Darren Dukes (ddukes) wrote on 12/10/2021 15:35: >> > Given this, it is clear, the CSID flavors of the same SRv6 SIDs def= ined >> > in RFC8986 are also IPv6 addresses. >> >> Ok, this is good that we're all on the same page about SIDs being IPv6= >> addresses.=C2=A0 This means that they and >> draft-filsfilscheng-spring-srv6-srh-compression need to comply with 82= 00 >> and 4291, and it looks to me like the draft does not. >> >> Nick >> >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From primadi.kusuma@indosatooredoo.com Tue Oct 12 14:31:45 2021 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 D3D813A0B10; Tue, 12 Oct 2021 14:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=o365indosat.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 KJeh_I8rFuex; Tue, 12 Oct 2021 14:31:41 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-sg2apc01on062e.outbound.protection.outlook.com [IPv6:2a01:111:f400:febd::62e]) (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 8ED183A0AA6; Tue, 12 Oct 2021 14:31:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kTjO6tPKA7XNzO0ZYS87+Gz4TjXSwJiedqjf3ufEGHWrB9LWaS5P69T4h4dY70ORbrvxIA1Hc/6R3SPaQJ5Rggg8Mga+w5QeOn/PFCelsvoq7Ja939rEfSctbT/L4UbodBeGT4ODugWj1D1OJ0KAONDG90S8RsI5g9WjxF71x2MSCFt8J0rPP/AjSZmbGGCW44ywf2pOJ+d1izLGJYmuWiZlLz7QounmogKQd7dlr+DbuGNBVHEJXi+GInEKLIpqZdFPq+8Z6hmmZ+gXOzdrBihsqJ19NoSGvK7eUi3QRcttROPDge4c1sA6JOSufHOo0b2IMS1bGs/+nGBxTqXUEA== 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=Y4O5P7XRvZXy+LMTh007nPKF7/7apGuTgjRw+h/iu+8=; b=BYVWLNv3RcalBSJiwaCXBx5RzrZBbG0CysLNKoZznSw9A104OZO8UrXTIcEC9UgfCY4rAIRe7a2nUiULUxg7UDGsZD5Ewh5wOy0VIlpsK8DZ1MQLljjZmp5rhemBKakL+lgJ4XJEcCcLRGz3v/C20y2gqeMhJJVhjiOVyueiHqo9SARKDQK1gHdfOju3GultKp+vtfGoxkHFG1vn/RSkNfNagKW9qu1anze3S15nvkWSZkwflrsrHoAep2sXCj8R/s3XtTzsO2MU7iEnBklqQ4VaqlsDzsD7GbWuiARlc1eqPaUSI2TaNuUOxyQColVsECKiKlxyq15DbfWuhLLTOg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=indosatooredoo.com; dmarc=pass action=none header.from=indosatooredoo.com; dkim=pass header.d=indosatooredoo.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=o365indosat.onmicrosoft.com; s=selector2-o365indosat-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y4O5P7XRvZXy+LMTh007nPKF7/7apGuTgjRw+h/iu+8=; b=svFbAeJSpxdMPUNTRyklgahBd3x93Ub7Dgh3X/nPzk1B8cTCm0DS6vTY+qBF8B96P+TrapsqNQutqoqhpS3XjHTUta+SVfoXuZVK0a0GTMofkkAfH+/9NQpfGTt+NOWskf6VBYYTkyWtEx0Ldz6mbDuPcD2i7ZQ2wEIjvkLVuO4= Received: from SG2PR01MB2886.apcprd01.prod.exchangelabs.com (20.177.168.18) by SG2PR01MB2347.apcprd01.prod.exchangelabs.com (20.177.84.73) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.25; Tue, 12 Oct 2021 21:31:29 +0000 Received: from SG2PR01MB2886.apcprd01.prod.exchangelabs.com ([fe80::cc99:1e39:82fc:af0]) by SG2PR01MB2886.apcprd01.prod.exchangelabs.com ([fe80::cc99:1e39:82fc:af0%7]) with mapi id 15.20.4587.025; Tue, 12 Oct 2021 21:31:29 +0000 From: Primadi Hendra Kusuma To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQI4FdIA Date: Tue, 12 Oct 2021 21:31:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-version: 11.4.200.18 dlp-reaction: no-action dlp-product: dlpe-windows authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=indosatooredoo.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 427bb509-6fdc-4b4a-16e1-08d98dc7a769 x-ms-traffictypediagnostic: SG2PR01MB2347: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Tv7+OiUDGChXT/Djr61M1a5DIwwVDr4aBrXrKaWwXvLFnbdH7mh1jJVtDZ2qmAop+I2TLcqPVatEDhdcxZ+k7ZRCvYVmdeD7DDy03WyNcKWJ+VZOPr6DtCUDklYOmhz6haIJEM0V+XMUX8tQG5NWfwYy/oZ9N2NLLleNWA+WmKaQ3dde0xVv73dOBTyJ3adeLRxQ72SdxTT1sK6EiZBZzkXUQK1fr1cSeorfb/sjHUQaYD0z0QwNsW2phEN9dYYKnVKDgbsBJpragC6PHkMiHl1MtyeLXUSBFU2Zb9PqvSfpQ18cU3v6/lwpXprsqRt2yhETxkpYLLIurPqF8LimBiPLoHOvIxKsjB2OvSnA7R1ituSpBjFpIPUwtRE3xZu1xi4sMHuCLrrcI3GkWeq9Z0EiWZVivOxjvIfYdI+POTC03rVtDuPvT5DUC9GMkhy8bxMWbxzojwNgRBFovACBfiR4j1EdeVl2BJ1jDizERkCKIzJf5/5hoI9FZNCg00BRszEG0oFgmlewXKy5CSg7aKiLzzh7O9E4xsSarAmdg9fTbwDbrlnuV7+JlAuXpowOJR9hWj/mSSdpRwRYJ0F+jJs5or4Sq4uNnKU6AE450pLL7rjfZ/PQPRL8M7BsS2NynOW1AJlBehMF+5/nqQY17l+iikDmmQxE2BFv1Gmb87zoCuQv1RBKuSWHHtKrTl6qaDMUe5ujau9Qyl5jGh7MVDp5PUq6JkBuacz5+/R9puzGuXb249j6zdmCmTT74UYyGxNkTSDeR33oMhQVYiECT7vWvzR5zfQb20ezwziLnSU= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SG2PR01MB2886.apcprd01.prod.exchangelabs.com; PTR:; CAT:NONE; SFS:(366004)(4326008)(2906002)(508600001)(86362001)(966005)(5660300002)(110136005)(83380400001)(7696005)(316002)(122000001)(38070700005)(66946007)(66476007)(33656002)(53546011)(186003)(166002)(38100700002)(71200400001)(9686003)(8936002)(52536014)(55016002)(26005)(76116006)(6506007)(66556008)(8676002)(64756008)(66446008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?T1dDRWpjZmtQMWUxUUdSMkdmWFdSVnZCU0RUdFkyc1RqTkpwRHBGS1ludEpW?= =?utf-8?B?TnBLTXB2OHNGeENOa2VJZ3lTM0ttNUs4NzRIWEozN1pTS21pYVBab0xQdlQy?= =?utf-8?B?Y2EvdXphU1lEcUJ3dFkyT0VjS2cxN1JpeVFFejFLWVZYRUoxeklnVzF6amFy?= =?utf-8?B?Q1lzdDRPbVBINlA2cURaVVgrMnZMdWNyODBkcmNRRk40Z1QvODBUODZmck4x?= =?utf-8?B?Wm5UbngxOVJmblVYd015Zm9NenpvMFFpQ1ZSUzVhVzVLVjh3YkxhQ0JKbDRz?= =?utf-8?B?SUVxckkvNCtkeW94QUpGVXBkS01rY0ljTE9XWkhXMi8vcERheFcvS1g0ek5B?= =?utf-8?B?KzZ3QWxZMENwWUVJM0c5UVQ1dDV0Z1p2bUVIcFNnUjhiTm02NDR2R011V0xo?= =?utf-8?B?QVZVT3ZpdnlDY1BZU3RmdEVQcWJDOXduSFZoNFh0NWdyMXJobUNTQUhhUzJV?= =?utf-8?B?UFRBbGIzQmhsVFNtTVBPS1NReWp3YjRNWlI5SVdnRTFIMitIM01UYVc5ZzA0?= =?utf-8?B?TGhqcVR1OUVTTkdoZHlIK2ZZS0o0VFhKVE5VdmwvM3BEOGQ2TFdxRDM1Tnpk?= =?utf-8?B?aWFNc2xKYU5MVzV5NFBPMWJKNkhPcWtGbnFXN21TbVVmU0N2dlVyRWxRMXIr?= =?utf-8?B?cUNjbk9wYWlpRmNacS8yQStNS01NdFUvVldGeituZHluQjd0VURETUs5TnBW?= =?utf-8?B?WE1IVmcxZlpEc3FTbFNIcHpuMnRYb0ZZSk5XZzFqRzlsUE9nK0RLYUU3MHQz?= =?utf-8?B?ajFITUJLZW9PMnIza2pWVGY3SGMxTGdHSXF4eGx5cTJsOXM2cFRuWFNQVFh3?= =?utf-8?B?S0ZHL0luODVsZlM2L0xiWjBaNTQ4b2p0T0Z5UmxrUEc5bUpNcmFkcFM0eE4v?= =?utf-8?B?N3ptV0d2YytoNzJaZ3BFN20yRXNPMEx1VmZKQThQUlUvVkVLTmZ0OUNDV2xD?= =?utf-8?B?TlduSXp1UEc4YjYrMk1MSHlIc1g1RDR0elE3bllaY2tGVngxUTJpYnhQZEhw?= =?utf-8?B?WnFINUxWMkZZdStjOHZ3YWpHY0Joc0tvclJvcVMxRWlwemNFb21XeTM0bjhr?= =?utf-8?B?bjVzZjVrUjhMY0NXbHo5RmYrVzVUYW92MVJ4RDZIK05JTytvcWFPYzhPL1p3?= =?utf-8?B?dGMvaDVJUFNWS3dvNktQOEhPTXNHMlR6dkJteVV6SEVzNkViU2FXNXJDNnZi?= =?utf-8?B?Zk5kbzlvajhrdzkrb2ZJUjA0aTlKWmNCeGpPZkRQWG9QZCtnL0VoSnFoREc1?= =?utf-8?B?UTlyTkEvZDh0Umd6bG5vdUN0ZWFNOEVLeEFmeUQvaWRISGpyV3ZOWkZVYlNP?= =?utf-8?B?WnM2V1MrOG5YOHAydFpoSEUyZzFIK3p6OWlyVVpLMDJaclFCSnBwQkFwbUpl?= =?utf-8?B?OFRSR2JBUUhRYjhLWlkyTUtGM1ZBTnZvaU02Qi9mR0RrQkZpVFoyVDUzcjN2?= =?utf-8?B?NFZTdHdISXhPUC85RVZ1RW9EZ2lubnNwMXl6N2ZUdXVVYVF3OE8vRXBUUWdh?= =?utf-8?B?bTBvcCt2Q1ZBSHNCSzV3cVBCRVcyMFVRMVdZQk1PVytyNmpwd1R1UWJ1ZlI1?= =?utf-8?B?Nzc2WmE5K1B5TGgzdEVwSjJTL2IvSWlqQ2hMOEluR2FlRzNONm9jMU9lQ2Ix?= =?utf-8?B?R09IMEMwK014KzEyYkFramE1S0tYaHhOOUJ5MmhpRHJuZHFldVRFWjBpaVpj?= =?utf-8?B?KzM0cm5mQjFmOTdhOVhLcWp0MlFLd20vZWRCM29oc3FiRmo3M1pQQlBhM2dU?= =?utf-8?Q?O2/AQDIhl/fYAyBfBlZcYTM65S9hhZIL6w+uFhL?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SG2PR01MB28864B17A609418C9411F36DFCB69SG2PR01MB2886apcp_" MIME-Version: 1.0 X-OriginatorOrg: indosatooredoo.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SG2PR01MB2886.apcprd01.prod.exchangelabs.com X-MS-Exchange-CrossTenant-Network-Message-Id: 427bb509-6fdc-4b4a-16e1-08d98dc7a769 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2021 21:31:29.5286 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 77080246-342c-482e-a864-447a4f6133f1 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: P1fS2Wm+RIptOHA6AyGtwKgJf+TpSa7C6T9IMF5izYRGoGN6hkBbkE5qQz6ahhXg3h7FcSBO9iIP5iGOEwEcieUatQRl8y2eszq68KFyk2c= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2PR01MB2347 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 12 Oct 2021 22:23:17 -0000 --_000_SG2PR01MB28864B17A609418C9411F36DFCB69SG2PR01MB2886apcp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBXRywNCg0KVGhlIGRyYWZ0LCBhcyBmYXIgYXMgSSBjYW4gdW5kZXJzdGFuZCwgZGVmaW5l cyBSRVBMQUNFLUNTSUQgYW5kIE5FWFQtQ1NJRCBmbGF2b3VycyBpbiBvcmRlciB0byBlbmFibGUg ZWZmaWNpZW50IFNSSCBlbmNvZGluZyBjYXBhYmlsaXR5LCBhbmQgaXQgaXMgYmFzZWQgb24gYSBz aW5nbGUgU1J2NiBkYXRhIHBsYW5lLiBJIGhpZ2hseSBlbmRvcnNlIHRoZSBhZG9wdGlvbiBvZiBD U0lEIGFzIGFuIG9wZXJhdG9yIHdobyBpcyBnb2luZyB0byBkZXBsb3kgbXVsdGktdmVuZG9ycyBT UnY2IGluIHRoZSBuZWFyIGZ1dHVyZS4gV2UncmUgd2lzaGluZyB0byBzdGFuZGFyZGl6ZSB0aGUg Q1NJRCBzbyB0aGF0IHdlIGNhbiBhZG9wdCBhIHVuaWZvcm0gc29sdXRpb24gYWNyb3NzIHRoZSBu ZXR3b3JrLg0KDQpSZWdhcmRzLA0KDQpGcm9tOiBzcHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYu b3JnPiBPbiBCZWhhbGYgT2YgSmFtZXMgR3VpY2hhcmQNClNlbnQ6IEZyaWRheSwgT2N0b2JlciAx LCAyMDIxIDk6MDUgUE0NClRvOiBTUFJJTkcgV0cgPHNwcmluZ0BpZXRmLm9yZz4NCkNjOiBzcHJp bmctY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiBbc3ByaW5nXSBXRyBBZG9wdGlvbiBjYWxsIGZv ciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNw cmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8NCg0KRGVhciBXRzoNCg0KVGhlIGNoYWlycyB3b3Vs ZCBsaWtlIHRvIGV4cHJlc3MgdGhlaXIgYXBwcmVjaWF0aW9uIGZvciBhbGwgdGhlIHJlc3BvbnNl cyByZWNlaXZlZCB0byBvdXIgZW1haWxzIHdpdGggcmVmZXJlbmNlIHRvIGhvdyB0aGUgd29ya2lu ZyBncm91cCB3aXNoZXMgdG8gbW92ZSBmb3J3YXJkIHdpdGggcmVzcGVjdCB0byBhIHNvbHV0aW9u IGZvciBTUnY2IGNvbXByZXNzaW9uLg0KDQpUaGUgYXBwYXJlbnQgaW5jbGluYXRpb24gb2YgdGhl IHdvcmtpbmcgZ3JvdXAgaXMgdG8gdXNlIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyBhcyB0aGUg YmFzaXMgZm9yIGl0cyBjb21wcmVzc2lvbiBzdGFuZGFyZGl6YXRpb24gd29yay4gVGhhdCBpcyBw YXJ0IG9mIHdoYXQgdGhpcyBlbWFpbCBhdHRlbXB0cyB0byBjb25maXJtLg0KDQpCZWNhdXNlIG9m IHRoZSBhYm92ZSB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gaXNzdWUgYSAyLXdlZWsgV0cgY2Fs bCBmb3IgYWRvcHRpb24gZW5kaW5nIE9jdG9iZXIgMTV0aCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJl c3Npb24vIGJ1dCB3aXRoIHNvbWUgY2xlYXIgZ3VpZGVsaW5lcyBhcyBmb2xsb3dzLiBCeSBleHBy ZXNzaW5nIHN1cHBvcnQgZm9yIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgeW91IGFyZSBmdWxs eSBhd2FyZSBvZiBhbmQgYXJlIGFja25vd2xlZGdpbmcgdGhhdDoNCg0KDQogIDEuICBUaGUgU1BS SU5HIHdvcmtpbmcgZ3JvdXAgaXMgYWRvcHRpbmcgYSBkb2N1bWVudCB0aGF0IGhhcyBtdWx0aXBs ZSBTUnY2IEVuZHBvaW50IGJlaGF2aW9ycy4NCiAgMi4gIFRoZSBkb2N1bWVudCBpcyBhIOKAnGxp dmluZ+KAnSBkb2N1bWVudDsgaXQgbWF5IGNoYW5nZSBhcyBpdCBnb2VzIHRocm91Z2ggcmV2aWV3 IGFuZCBhbmFseXNpcyBieSB0aGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAuDQogIDMuICBBbGwgb3Bl biBkaXNjdXNzaW9uIHBvaW50cyByYWlzZWQgb24gb3VyIG1haWxpbmcgbGlzdCBNVVNUIGJlIGFk ZHJlc3NlZCBCRUZPUkUgc2FpZCBkb2N1bWVudCBpcyBhbGxvd2VkIHRvIHByb2dyZXNzIGZyb20g dGhlIHdvcmtpbmcgZ3JvdXAgdG8gcHVibGljYXRpb24uIEEgbGlzdCBvZiB0aGVzZSBkaXNjdXNz aW9uIHBvaW50cyB3aWxsIGJlIGRvY3VtZW50ZWQgaW4gdGhlIFdHIGRvY3VtZW50IGFuZCBtYWlu dGFpbmVkIGJ5IHRoZSBkb2N1bWVudCBlZGl0b3IgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgY2hh aXJzLg0KICA0LiAgSWYgdGhpcyBkb2N1bWVudCBpcyBhZG9wdGVkIGJ5IHRoZSB3b3JraW5nIGdy b3VwLCB0aGUgY2hhaXJzIHNwZWNpZnkgYXMgcGFydCBvZiB0aGUgYWRvcHRpb24gY2FsbCB0aGF0 IHRoZSBmb2xsb3dpbmcgdGV4dCBkZXNjcmliaW5nIGFuIG9wZW4gaXNzdWUgYmUgYWRkZWQgdG8g dGhlIGRvY3VtZW50IGluIHRoZSBhYm92ZS1kZXNjcmliZWQgb3BlbiBpc3N1ZXMgc2VjdGlvbjoN CiAgICAgKiAgICJHaXZlbiB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBzYWlkIHRoYXQgaXQg d2FudHMgdG8gc3RhbmRhcmRpemUgb25lIGRhdGEgcGxhbmUgc29sdXRpb24sIGFuZCBnaXZlbiB0 aGF0IHRoZSBkb2N1bWVudCBjb250YWlucyBtdWx0aXBsZSBTUnY2IEVuZFBvaW50IGJlaGF2aW9y cyB0aGF0IHNvbWUgV0cgbWVtYmVycyBoYXZlIHN0YXRlZCBhcmUgbXVsdGlwbGUgZGF0YSBwbGFu ZSBzb2x1dGlvbnMsIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYWRkcmVzcyB3aGV0aGVyIHRoaXMg aXMgdmFsaWQgYW5kIGNvaGVyZW50IHdpdGggaXRzIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uIG9i amVjdGl2ZS4iLg0KDQpQbGVhc2UgY29uc2lkZXIgdGhlIGFib3ZlIGd1aWRlbGluZXMgYXMgeW91 IGRlY2lkZSBvbiB3aGV0aGVyIHRvIHN1cHBvcnQgb3Igbm90IHRoaXMgV0cgYWRvcHRpb24uIFBs ZWFzZSBleHByZXNzIGNsZWFybHkgeW91ciByZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9uLXN1cHBv cnQgYXMgd2VsbCBhcyBhbnkgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyB5b3Ugd291bGQgbGlrZSBh ZGRyZXNzZWQgc2hvdWxkIHRoZSBkb2N1bWVudCBiZSBhZG9wdGVkIGludG8gdGhlIHdvcmtpbmcg Z3JvdXAuDQoNClRoYW5rcyENCg0KSmltLCBCcnVubyAmIEpvZWwNCg0KDQo= --_000_SG2PR01MB28864B17A609418C9411F36DFCB69SG2PR01MB2886apcp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8q IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv Tm9ybWFsDQoJe21hcmdpbjowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4 dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFn cmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1h cmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJ bWFyZ2luLWxlZnQ6LjVpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi UGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEu MGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2Vj dGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6 NzQwMzcwOTA4Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMTIxNzQ3NjkyO30NCkBsaXN0IGww OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjc1 MTY5OTM5MzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTcyMTY1NDc3NiA2NzY5ODcwMyA2NzY5ODY4OSA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2 NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMTpsZXZlbDENCgl7 bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4w cHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3Qg bDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwx OmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1s b3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBp bjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1JRCIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0eWxlPSJ3b3JkLXdyYXA6YnJl YWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5EZWFyIFdHLDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5UaGUgZHJhZnQsIGFzIGZhciBhcyBJIGNhbiB1bmRlcnN0YW5kLCBkZWZpbmVzIFJFUExBQ0Ut Q1NJRCBhbmQgTkVYVC1DU0lEIGZsYXZvdXJzIGluIG9yZGVyIHRvIGVuYWJsZSBlZmZpY2llbnQg U1JIIGVuY29kaW5nIGNhcGFiaWxpdHksIGFuZCBpdCBpcyBiYXNlZCBvbiBhIHNpbmdsZSBTUnY2 IGRhdGEgcGxhbmUuIEkgaGlnaGx5IGVuZG9yc2UNCiB0aGUgYWRvcHRpb24gb2YgQ1NJRCBhcyBh biBvcGVyYXRvciB3aG8gaXMgZ29pbmcgdG8gZGVwbG95IG11bHRpLXZlbmRvcnMgU1J2NiBpbiB0 aGUgbmVhciBmdXR1cmUuIFdlJ3JlIHdpc2hpbmcgdG8gc3RhbmRhcmRpemUgdGhlIENTSUQgc28g dGhhdCB3ZSBjYW4gYWRvcHQgYSB1bmlmb3JtIHNvbHV0aW9uIGFjcm9zcyB0aGUgbmV0d29yay48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIj4gc3ByaW5nICZsdDtzcHJpbmctYm91bmNlc0BpZXRmLm9yZyZndDsNCjxi Pk9uIEJlaGFsZiBPZiA8L2I+SmFtZXMgR3VpY2hhcmQ8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5 LCBPY3RvYmVyIDEsIDIwMjEgOTowNSBQTTxicj4NCjxiPlRvOjwvYj4gU1BSSU5HIFdHICZsdDtz cHJpbmdAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBzcHJpbmctY2hhaXJzQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtzcHJpbmddIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNy djYtc3JoLWNvbXByZXNzaW9uLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5EZWFyIFdHOjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ VGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGV4cHJlc3MgdGhlaXIgYXBwcmVjaWF0aW9uIGZvciBh bGwgdGhlIHJlc3BvbnNlcyByZWNlaXZlZCB0byBvdXIgZW1haWxzIHdpdGggcmVmZXJlbmNlIHRv IGhvdyB0aGUgd29ya2luZyBncm91cCB3aXNoZXMgdG8gbW92ZSBmb3J3YXJkIHdpdGggcmVzcGVj dCB0byBhIHNvbHV0aW9uIGZvciBTUnY2IGNvbXByZXNzaW9uLg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5UaGUgYXBwYXJlbnQgaW5jbGluYXRpb24gb2YgdGhlIHdvcmtpbmcgZ3JvdXAgaXMgdG8gdXNl DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmls c2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8iPg0KaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJl c3Npb24vPC9hPiBhcyB0aGUgYmFzaXMgZm9yIGl0cyBjb21wcmVzc2lvbiBzdGFuZGFyZGl6YXRp b24gd29yay4gVGhhdCBpcyBwYXJ0IG9mIHdoYXQgdGhpcyBlbWFpbCBhdHRlbXB0cyB0byBjb25m aXJtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QmVjYXVzZSBvZiB0aGUgYWJvdmUgdGhlIGNoYWlycyB3 b3VsZCBsaWtlIHRvIGlzc3VlIGEgMi13ZWVrIFdHIGNhbGwgZm9yIGFkb3B0aW9uIGVuZGluZyBP Y3RvYmVyIDE1PHN1cD50aDwvc3VwPiBmb3INCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNz aW9uLyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2No ZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88L2E+IGJ1dCB3aXRoIHNvbWUgY2xlYXIg Z3VpZGVsaW5lcyBhcyBmb2xsb3dzLiBCeSBleHByZXNzaW5nIHN1cHBvcnQgZm9yIGFkb3B0aW9u IG9mIHRoaXMgZG9jdW1lbnQgeW91IGFyZSBmdWxseSBhd2FyZSBvZiBhbmQgYXJlIGFja25vd2xl ZGdpbmcgdGhhdDoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8b2wgc3R5 bGU9Im1hcmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxm bzMiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAgaXMgYWRvcHRp bmcgYSBkb2N1bWVudCB0aGF0IGhhcyBtdWx0aXBsZSBTUnY2IEVuZHBvaW50IGJlaGF2aW9ycy4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8zIj48c3BhbiBsYW5nPSJF Ti1VUyI+VGhlIGRvY3VtZW50IGlzIGEg4oCcbGl2aW5n4oCdIGRvY3VtZW50OyBpdCBtYXkgY2hh bmdlIGFzIGl0IGdvZXMgdGhyb3VnaCByZXZpZXcgYW5kIGFuYWx5c2lzIGJ5IHRoZSBTUFJJTkcg d29ya2luZyBncm91cC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwxIGxldmVsMSBsZm8z Ij48c3BhbiBsYW5nPSJFTi1VUyI+QWxsIG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgcmFpc2VkIG9u IG91ciBtYWlsaW5nIGxpc3QgTVVTVCBiZSBhZGRyZXNzZWQgQkVGT1JFIHNhaWQgZG9jdW1lbnQg aXMgYWxsb3dlZCB0byBwcm9ncmVzcyBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIHRvIHB1YmxpY2F0 aW9uLiBBIGxpc3QNCiBvZiB0aGVzZSBkaXNjdXNzaW9uIHBvaW50cyB3aWxsIGJlIGRvY3VtZW50 ZWQgaW4gdGhlIFdHIGRvY3VtZW50IGFuZCBtYWludGFpbmVkIGJ5IHRoZSBkb2N1bWVudCBlZGl0 b3IgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgY2hhaXJzLg0KPG86cD48L286cD48L3NwYW4+PC9s aT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNv LWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB0aGlzIGRvY3VtZW50 IGlzIGFkb3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAsIHRoZSBjaGFpcnMgc3BlY2lmeSBhcyBw YXJ0IG9mIHRoZSBhZG9wdGlvbiBjYWxsIHRoYXQgdGhlIGZvbGxvd2luZyB0ZXh0IGRlc2NyaWJp bmcgYW4gb3BlbiBpc3N1ZSBiZSBhZGRlZCB0byB0aGUNCiBkb2N1bWVudCBpbiB0aGUgYWJvdmUt ZGVzY3JpYmVkIG9wZW4gaXNzdWVzIHNlY3Rpb246PG86cD48L286cD48L3NwYW4+PC9saT48dWwg c3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvUGxhaW5U ZXh0IiBzdHlsZT0ibXNvLWxpc3Q6bDEgbGV2ZWwyIGxmbzMiPjxzcGFuIGxhbmc9IkVOLVVTIj4m cXVvdDtHaXZlbiB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBzYWlkIHRoYXQgaXQgd2FudHMg dG8gc3RhbmRhcmRpemUgb25lIGRhdGEgcGxhbmUgc29sdXRpb24sIGFuZCBnaXZlbiB0aGF0IHRo ZSBkb2N1bWVudCBjb250YWlucyBtdWx0aXBsZSBTUnY2IEVuZFBvaW50IGJlaGF2aW9ycyB0aGF0 IHNvbWUgV0cgbWVtYmVycw0KIGhhdmUgc3RhdGVkIGFyZSBtdWx0aXBsZSBkYXRhIHBsYW5lIHNv bHV0aW9ucywgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhZGRyZXNzIHdoZXRoZXIgdGhpcyBpcyB2 YWxpZCBhbmQgY29oZXJlbnQgd2l0aCBpdHMgb25lIGRhdGEgcGxhbmUgc29sdXRpb24gb2JqZWN0 aXZlLiZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L29sPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5QbGVhc2UgY29uc2lk ZXIgdGhlIGFib3ZlIGd1aWRlbGluZXMgYXMgeW91IGRlY2lkZSBvbiB3aGV0aGVyIHRvIHN1cHBv cnQgb3Igbm90IHRoaXMgV0cgYWRvcHRpb24uIFBsZWFzZSBleHByZXNzIGNsZWFybHkgeW91ciBy ZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9uLXN1cHBvcnQgYXMgd2VsbCBhcyBhbnkgb3BlbiBkaXNj dXNzaW9uIHBvaW50cyB5b3Ugd291bGQgbGlrZSBhZGRyZXNzZWQNCiBzaG91bGQgdGhlIGRvY3Vt ZW50IGJlIGFkb3B0ZWQgaW50byB0aGUgd29ya2luZyBncm91cC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PlRoYW5rcyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkppbSwgQnJ1bm8gJmFtcDsgSm9lbDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2JvZHk+ DQo8L2h0bWw+DQo= --_000_SG2PR01MB28864B17A609418C9411F36DFCB69SG2PR01MB2886apcp_-- From nobody Tue Oct 12 18:43:31 2021 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 EB5CD3A0966; Tue, 12 Oct 2021 18:43:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tuWE3vK_7LI3; Tue, 12 Oct 2021 18:43:26 -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 C9A453A0963; Tue, 12 Oct 2021 18:43:25 -0700 (PDT) Received: from fraeml739-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HTZwq5ZgFz6885x; Wed, 13 Oct 2021 09:40:27 +0800 (CST) Received: from dggpemm100001.china.huawei.com (7.185.36.93) by fraeml739-chm.china.huawei.com (10.206.15.220) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Wed, 13 Oct 2021 03:43:21 +0200 Received: from dggpemm500002.china.huawei.com (7.185.36.229) by dggpemm100001.china.huawei.com (7.185.36.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Wed, 13 Oct 2021 09:43:19 +0800 Received: from dggpemm500002.china.huawei.com ([7.185.36.229]) by dggpemm500002.china.huawei.com ([7.185.36.229]) with mapi id 15.01.2308.008; Wed, 13 Oct 2021 09:43:19 +0800 From: Mach Chen To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQJA+K9Q Date: Wed, 13 Oct 2021 01:43:19 +0000 Message-ID: <03fb23a1ce1b43d08bd4c18daab6dae8@huawei.com> References: 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.110.46.250] Content-Type: multipart/alternative; boundary="_000_03fb23a1ce1b43d08bd4c18daab6dae8huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 13 Oct 2021 01:43:30 -0000 --_000_03fb23a1ce1b43d08bd4c18daab6dae8huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have read the draft and been following this discussion of SRH compression= . Since the WG has agreed to address the SRH compression issue, the draft p= roposes a reasonable way to do that, and the quality of the document is abo= ve the average, IMHO. Therefore, I support the adoption of the document, and then the draft can = be improved, modified and progressed according to the WG consensus. Best regards, Mach From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard Sent: Friday, October 1, 2021 10:05 PM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_03fb23a1ce1b43d08bd4c18daab6dae8huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi,

     

    I have read the draft and been following this discussion of SRH c= ompression. Since the WG has agreed to address the SRH compression issue, t= he draft proposes a reasonable way to do that, and the quality of the document is above the average, IMHO.<= /o:p>

     

    Therefore, I support the adoption of the document,  and then= the draft can be improved, modified and progressed according to the WG con= sensus.

     

    Best regards,

    Mach

     

    From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard
    Sent: Friday, October 1, 2021 10:05 PM
    To: SPRING WG <spring@ietf.org>
    Cc: spring-chairs@ietf.org
    Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

     

    Dear WG:

     

    The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a sol= ution for SRv6 compression.

     

    The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

     

    Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

     

    1. The SPRING working group is adopting a document that has multiple SRv6 = Endpoint behaviors.
    2. The document is a “living” document;= it may change as it goes through review and analysis by the SPRING working= group.
    3. All open discussion points raised on our mailing= list MUST be addressed BEFORE said document is allowed to progress from th= e working group to publication. A list of these discussion points will be documented in the WG document and maintained by the document edito= r in conjunction with the chairs.
    4. If this document is adopted by the working group= , the chairs specify as part of the adoption call that the following text d= escribing an open issue be added to the document in the above-described open issues section:
      • "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution obj= ective.".

     

    Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open d= iscussion points you would like addressed should the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    --_000_03fb23a1ce1b43d08bd4c18daab6dae8huaweicom_-- From nobody Tue Oct 12 19:03:58 2021 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 7A81E3A0A8C; Tue, 12 Oct 2021 19:03:54 -0700 (PDT) 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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aIz9sso5wwIr; Tue, 12 Oct 2021 19:03:41 -0700 (PDT) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 402D23A0A86; Tue, 12 Oct 2021 19:03:41 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id q5so799835pgr.7; Tue, 12 Oct 2021 19:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; bh=aa/pzY0cPiJ/nYh4mJysW8rgE74hKpx99gZjrsy38Q0=; b=o2Ltys4d/xeP5xFC6Wa8L8wKFdWhvE+ksnAPAZlXprsWrdnSEkrO5EQA2JTXTyBNTE 3mozI1BinU38fCK1GcewPFLiQewexRIAXC8Ir3Lpok9ghsDQ3EQxvsxAC3XCrPHXNDNx 2kfyqgkJ1bCiAEM7hq2rjiUJF+C2zMnhc6ayf6xP+RoIoIl4tMB+bsxOoKuDlo2xyd+Z +s2vZoptPGWg6hZpwLN0f5HGOyhIXJSY+k0Vb7VtNrChIHWEamZhHQwQk2znV/qgtxds RCzb83ZXqS8+SVyuHJIrhWbXEclLvFUS6UaspDSJuJO0PV2J7S83CrWecxIpaY2x2IYb 0xVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:content-transfer-encoding:mime-version:subject :from:in-reply-to:date:cc:message-id:references:to; bh=aa/pzY0cPiJ/nYh4mJysW8rgE74hKpx99gZjrsy38Q0=; b=0ICrlkDnLFQQ0/CoY1Is4Ggyvt7d5BmY0poO1/oXFVXJPnxjPYrkGcmNFFlRFr4sa7 hQ0FiKZvUkuYRCPgFifiOTVj18jWmSkS9oZryacbAGnnRHMfin7STQfiZNYsYt5D8wVj MJovJG2gW6B2ln3hi0A1RpK6LS32gJkqrlfJnxPbs+OmstmzkbANaWWMKsRdBdHMpSGU yX19PDmftMOulUQOBK4eAEfXr/Au163DCKS2lanRKbdBM3gaXx/TI9KGw2RMeKYiy1W4 JB7O85/tzM97mHij88hibVmYT+BiZPcvckxy2RVDS58rSYiqnf+yNBHU1Gxc89AtfSFf FgaA== X-Gm-Message-State: AOAM530cz/nQ72QkfcJJyCCll1lcAdTxwFbof0LQky0rN+HFLD7IsDRO 1u6TAlOHRKJNTKgQj5Ql7kf8XE/oRCc= X-Google-Smtp-Source: ABdhPJxaOGj724+CGIQVXVvYSbl3/TvxsSwuybPGylREIy0kcdztp5ff/N0c91PILW4lpiTyPRDLZA== X-Received: by 2002:a63:5608:: with SMTP id k8mr25743103pgb.287.1634090620345; Tue, 12 Oct 2021 19:03:40 -0700 (PDT) Received: from smtpclient.apple ([2400:2411:8900:0:bd1a:5bf9:fc2a:6f47]) by smtp.gmail.com with ESMTPSA id l19sm11991436pff.131.2021.10.12.19.03.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Oct 2021 19:03:39 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-F77FC9CF-169B-4419-B7A5-E0DB2C6616BA Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Satoru Matsushima In-Reply-To: Date: Wed, 13 Oct 2021 11:03:38 +0900 Cc: spring-chairs@ietf.org Message-Id: <8D2ED39F-6AF4-4E5E-8BDF-678E2CB7F318@gmail.com> References: To: James Guichard , SPRING WG X-Mailer: iPad Mail (19A348) Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 13 Oct 2021 02:03:55 -0000 --Apple-Mail-F77FC9CF-169B-4419-B7A5-E0DB2C6616BA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear SPRING WG, I support this adoption for draft-filsfilscheng-spring-srv6-srh-compression.= After I read the draft with the related DT documents, I understand that NEXT= and REPLACE flavors comply with RFC8986, and satisfied all the requirements= at high level. I really appreciate all DT members efforts that brings this d= raft to the WG.=20 Best regards, --satoru > On Oct 1, 2021, at 23:05, James Guichard w= rote: >=20 > =EF=BB=BF > Dear WG: > =20 > The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to move= forward with respect to a solution for SRv6 compression. > =20 > The apparent inclination of the working group is to use https://datatracke= r.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email a= ttempts to confirm. > =20 > Because of the above the chairs would like to issue a 2-week WG call for a= doption ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as foll= ows. By expressing support for adoption of this document you are fully aware= of and are acknowledging that: > =20 > The SPRING working group is adopting a document that has multiple SRv6 End= point behaviors. > The document is a =E2=80=9Cliving=E2=80=9D document; it may change as it g= oes through review and analysis by the SPRING working group. > All open discussion points raised on our mailing list MUST be addressed BE= FORE said document is allowed to progress from the working group to publicat= ion. A list of these discussion points will be documented in the WG document= and maintained by the document editor in conjunction with the chairs. > If this document is adopted by the working group, the chairs specify as pa= rt of the adoption call that the following text describing an open issue be a= dded to the document in the above-described open issues section: > "Given that the working group has said that it wants to standardize one da= ta plane solution, and given that the document contains multiple SRv6 EndPoi= nt behaviors that some WG members have stated are multiple data plane soluti= ons, the working group will address whether this is valid and coherent with i= ts one data plane solution objective.". > =20 > Please consider the above guidelines as you decide on whether to support o= r not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sho= uld the document be adopted into the working group. > =20 > Thanks! > =20 > Jim, Bruno & Joel > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --Apple-Mail-F77FC9CF-169B-4419-B7A5-E0DB2C6616BA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear SPRING WG,

    I suppor= t this adoption for = draft-filsfilscheng-spring-srv6-srh-compression.

    =
    After I read the draft with the related DT documents, I understand that= NEXT and REPLACE flavors comply with RFC8986, and satisfied all the require= ments at high level. I really appreciate all DT members efforts that brings t= his draft to the WG. 

    Best regards,
    --satoru=

    On Oct 1, 2021, at 23:0= 5, James Guichard <james.n.guichard@futurewei.com> wrote:

    =EF=BB=BF =

    Dear WG:

     

    The chairs would like to express their appreciation f= or all the responses received to our emails with reference to how the workin= g group wishes to move forward with respect to a solution for SRv6 compressi= on.

     

    The apparent inclination of the working group is to u= se https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compres= sion/ as the basis for its compression standardization work. That is par= t of what this email attempts to confirm.

     

    Because of the above the chairs would like to issue a= 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compres= sion/ but with some clear guidelines as follows. By expressing support f= or adoption of this document you are fully aware of and are acknowledging th= at:

     

    1. The SPRING working group is adopting a document that has multiple SRv6 E= ndpoint behaviors.
    2. The document is a =E2=80=9Cliving=E2=80=9D document; it= may change as it goes through review and analysis by the SPRING working gro= up.
    3. All open discussion points raised on our mailing list M= UST be addressed BEFORE said document is allowed to progress from the workin= g group to publication. A list of these discussion points will be documented in the WG document and maintained by the document= editor in conjunction with the chairs.
    4. If this document is adopted by the working group, the c= hairs specify as part of the adoption call that the following text describin= g an open issue be added to the document in the above-described open issues section:
      • "Given that the= working group has said that it wants to standardize one data plane solution= , and given that the document contains multiple SRv6 EndPoint behaviors that= some WG members have stated are multiple data plane solutions, the working group will address whether this i= s valid and coherent with its one data plane solution objective.".

     

    Please consider the above guidelines as you decide on= whether to support or not this WG adoption. Please express clearly your rea= soning for support/non-support as well as any open discussion points you wou= ld like addressed should the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    _______________________________________________
    spring= mailing list
    spring@ietf.org
    https://www.ie= tf.org/mailman/listinfo/spring
    = --Apple-Mail-F77FC9CF-169B-4419-B7A5-E0DB2C6616BA-- From nobody Tue Oct 12 19:47:40 2021 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 365EC3A0B98; Tue, 12 Oct 2021 19:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AsS-DxOEpuA; Tue, 12 Oct 2021 19:47:32 -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 D10B13A0CC4; Tue, 12 Oct 2021 19:47:31 -0700 (PDT) Received: from fraeml701-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HTcLp6l7yz67gM3; Wed, 13 Oct 2021 10:44:34 +0800 (CST) Received: from kwepeml500003.china.huawei.com (7.221.188.182) by fraeml701-chm.china.huawei.com (10.206.15.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.8; Wed, 13 Oct 2021 04:47:28 +0200 Received: from kwepeml500001.china.huawei.com (7.221.188.162) by kwepeml500003.china.huawei.com (7.221.188.182) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Wed, 13 Oct 2021 10:47:26 +0800 Received: from kwepeml500001.china.huawei.com ([7.221.188.162]) by kwepeml500001.china.huawei.com ([7.221.188.162]) with mapi id 15.01.2308.008; Wed, 13 Oct 2021 10:47:26 +0800 From: "Wanghaibo (Rainsword)" To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQJEJEYw Date: Wed, 13 Oct 2021 02:47:26 +0000 Message-ID: <247ead00a7d845028d4e8e86636cbc75@huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.153.118] Content-Type: multipart/alternative; boundary="_000_247ead00a7d845028d4e8e86636cbc75huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 13 Oct 2021 02:47:38 -0000 --_000_247ead00a7d845028d4e8e86636cbc75huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG, We are working on SRv6 for many years, and a lots of innovations are built = on SRv6. CSID uses the existing SRv6 data plane and control plane extension= s to provide efficient encoding of SRH so that we can mitigate a lot of com= plexities and workload of implementation and standardization. Therefore, I = support the adoption. Regards, Haibo From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard Sent: Friday, October 1, 2021 10:05 PM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_247ead00a7d845028d4e8e86636cbc75huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi WG,

     

    We are working on SRv6 for many= years, and a lots of innovations are built on SRv6. CSID uses the existing= SRv6 data plane and control plane extensions to provide efficient encoding= of SRH so that we can mitigate a lot of complexities and workload of implementation and standardization. Theref= ore, I support the adoption.

     

    Regards,

    Haibo

     

    From: spring [mailto:spring-bounces@ietf.org] On Behalf Of James Guichard
    Sent: Friday, October 1, 2021 10:05 PM
    To: SPRING WG <spring@ietf.org>
    Cc: spring-chairs@ietf.org
    Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

     

    Dear WG:

     

    The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a sol= ution for SRv6 compression.

     

    The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

     

    Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

     

    1. The SPRING working group is adopting a document that has multiple SRv6 = Endpoint behaviors.
    2. The document is a “living” document;= it may change as it goes through review and analysis by the SPRING working= group.
    3. All open discussion points raised on our mailing= list MUST be addressed BEFORE said document is allowed to progress from th= e working group to publication. A list of these discussion points will be documented in the WG document and maintained by the document edito= r in conjunction with the chairs.
    4. If this document is adopted by the working group= , the chairs specify as part of the adoption call that the following text d= escribing an open issue be added to the document in the above-described open issues section:
      • "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution obj= ective.".

     

    Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open d= iscussion points you would like addressed should the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    --_000_247ead00a7d845028d4e8e86636cbc75huaweicom_-- From nobody Tue Oct 12 20:53:04 2021 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 2CDA83A0B0F; Tue, 12 Oct 2021 20:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, 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 PflS7959Pv5d; Tue, 12 Oct 2021 20:52:56 -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 4D5983A0B0A; Tue, 12 Oct 2021 20:52:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4HTdsg66Qrz1pGcw; Tue, 12 Oct 2021 20:52:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1634097175; bh=0BTSKJBg+QQEtSeERzvdGyBZ6lOtDN1EcF7Xu6+UfJo=; h=Date:To:Cc:From:Subject:From; b=iSSBZ+o04SAtuQQtG3cm0KLaTdvwvHtORaWYaZeAyX6hwWNhE4n6knO3e24k8CL37 iidlMI/arkTUy7W+QPaRGs9ajWj/MWs6u2Fpii9Eoea1Y4GOBHNexv7RzbWXrPxd/Y 9Rm9ORaciN1NXX7A6Yq4QBLIZBZEkQKd5sfiiUL8= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.22.111] (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 4HTdsg2dqPz1ns1W; Tue, 12 Oct 2021 20:52:55 -0700 (PDT) Message-ID: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> Date: Tue, 12 Oct 2021 23:52:54 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Content-Language: en-US To: "ipv6@ietf.org" Cc: "spring@ietf.org" From: "Joel M. Halpern" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 13 Oct 2021 03:53:01 -0000 The SPRING working group is in the midst of an adoption call on https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/. The SPRING charter has text that is explicit that modifications to data planes and architectures standardized by other working groups may not be modified in SPRING unless the chairs and ADs responsible for that data plane and / or architecture agree. To complete the context, as my SPRING co-chairs are co-authors on the document in question, they have recused themselves from decisional activities regarding the document. Therefore, this message is coming just from my as the responsible SPRING co-chair managing this adoption call. As you have seen, multiple questions have been raised about the relationship of the document to the IPv6 defined data plane and architecture (particularly RFC 4291 and 8200). In particular the questions seem to revolve around what the document describes as the NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6 standards. (For those seeking more context without reading the full document, a paraphrase and simplification of the NEXT-C_SID flavor is provided as a postscript.) I raised the question of concurrence as required by the SPRING charter with the Internet ADs and SPRING chairs. They quite reasonably asked me to write a note to 6man explaining the concerns as clearly as a can, so that they can then determine how to proceed. The questions that prompted my inquiry are: 1) Does the placement of a list of sids in the IPv6 DA field change the IPv6 architectural description of that field. 2) Does the operation of shifting information around in the IPv6 destination address field represent a modification or extension of the IPv6 data plane. On a related note, the document in question also defines two other flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID flavor operation, so seems to be affected by the same question. From my own reading, it appears that the REPLACE-C-SID flavor does not raise issues requiring 6man leadership concurrence. Yours, Joel M. Halpern for the SPRING working group PS: Clearly, understanding the question requires some understanding of what the NEXT-C_SID flavor does. This explanation is a simplification for length and context. Really, the best place to understand it is the draft. However, to give you enough information to let you decide whether you care, I will try to provide a fair summary. My apologies in advance to the authors for necessary liberties for length. Also, discussion of the draft contents (as distinct from the interaction with the IPv6 data plane and architecture) belongs on the SPRING list, and should not clutter up 6man. SIDs are the identifiers used in segment routing. In SRv6, as document in the current RFCs, these are 128 bits. As defined in the relevant RFCs, SIDs which identify endpoints to which packets are directed are identified by endpoint SIDs. These can have behaviors (decapsulate and forward is one example). They can have flavors such as where the SRH is removed. The topic under discussion is means to compress these SIDs in the packets on the wire. The document under discussion provides three flavors of compression. The fundamental mechanism of the draft is to use a single SRH entry as a container for multiple SIDs. In the NEXT-C_SID mechanism, when it is first encountered the entire container is copied into the desination address of the IPv6 packet. The container has a common routing prefix used for all the NEXT-C-SID SIDs. It is followed by a sequence of compressed SIDs of a configured length. One could configure 16, 24, or 32 bits. Or whatever length. The routing advertisements are arranged so that the IPv6 packet is directed to the node represented by the first compressed SID on the basis of longest prefix match matching the combination of the common routing prefix and that compressed SID. When the packet arrives at that node, it looks up the configured portion, the compressed SID, and determines the behavior and flavor. In the case of the NEXT-C-SID flavor, the resulting operation is to shift the entire remaining contents of the IPv6 address (the bits past the first compressed sid) so as to over-write the first compressed SID. 0 bits are shifted into the low order positions. If the result is a non-zero new first compressed SID, then the packets is forwarded and the process repeats. When all that is left are 0s, if there is an SRH, it is consulted to find the next SRH entry, which is, per normal SRv6 processing, put into the IPv6 DA. Note that in the common case where the SIDS needed all fit in to a single container, the analysis also assumes the use of the reduced encapsulation options which omits the SRH that is not needed as it would have no entries. This the packet contains a normal IPv6 header, with a sequence of compressed SIDs (what one might or might not call a source route) in the IPv6 destination address field. PPS: If the authors of the NEXT-C-SID flavor feel I have mis-represented the work, please, send clarifications or corrections. Again, the best source of information is the draft itself. I was asked to provide extra context in this email. From nobody Tue Oct 12 21:11:09 2021 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 DFD283A0BC5; Tue, 12 Oct 2021 21:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4jy4EIzYY8S; Tue, 12 Oct 2021 21:11:00 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 93F833A0BCA; Tue, 12 Oct 2021 21:10:57 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id m20so1296650iol.4; Tue, 12 Oct 2021 21:10:57 -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=l7MoSfdDNKI8Bgxop/Ff2LHt8qhPI33fJiOaECdZlxM=; b=R/q14L7U6A4IcY6WWtc1xbHcznxFVecUkq3QEgS2kv0RkGu82H0foCmq+ez3MNqskg i+yfZT0QoAEckDMrRBhKAWcqaWEdI9qE5zIGp2opGIS+Z0hjZCYpU3h64SYHnlsRVtk1 He76FRk4rgduihC2qugm77ChZLeCta6R4k6xivwoTO+Ax0R0f9+likfa1QGO9XI4kM4V YOM23Ijq5fI3XY+ymRcM0IsmBNuShu3WIbcLP/PQ+8PhKQ4+6noMnfxDbwGxNKysYGOn 9nfeZCjTjQFdfCsrnuZAfAPjYfe1UoTkHTrmiWRbLtlAsjPCQn44YQy2CnohmYTBPnlf xtGA== 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=l7MoSfdDNKI8Bgxop/Ff2LHt8qhPI33fJiOaECdZlxM=; b=IZvjyGi2Ck63CIQYx+kGd82f94xbVneUzDLBRGnS3PF9xR6dFrJ3d9B6eusYTT2/XL pRNuDMhkBoaopLhpr8al9iw4/5+3cUbB+HOpCkjyxPYcE8CZczs4oV7Wpg82XxdUwgpc l6p9+iytXms4nmP9Y+JiBakeLuNqvcF8h4vvxI3cnVfYuZue5yIMstfnHklG//4YVvQi NnAEYnZkPd1NCE2e0P1ottfCypZ6yZfG7s32zeIiB0F72huc4sIo3A6VTOFvY/GMokU6 GZev719tyufUSJDFL1l253Zlk4QZ26u4tYoBLYWTisPveADPlva2rnoSQKIKcMkIvye+ QcAQ== X-Gm-Message-State: AOAM532wCW5UJeKOx5BqdiK0LOrQpIv1remD2MqSAxJSuPeukLrCPod8 ZqGSdWa4mVZh6Os7P/QfKmn1nfeBwxRa9PVZd2WGnYBevXc= X-Google-Smtp-Source: ABdhPJxhTDTyXv+W1FknDCCp104LqaeSDuOSDA4tCt9c2d+JCFdtS/qEM+wmoAEju0aD+WCWLou1BSzOFlZNUSEru9k= X-Received: by 2002:a02:c00e:: with SMTP id y14mr16261018jai.68.1634098256604; Tue, 12 Oct 2021 21:10:56 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dhruv Dhody Date: Wed, 13 Oct 2021 09:40:19 +0530 Message-ID: To: James Guichard Cc: SPRING WG , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001cf2ad05ce342622" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 13 Oct 2021 04:11:05 -0000 --0000000000001cf2ad05ce342622 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Chairs, I would not consider new flavors to the existing endpoint behaviors as multiple data planes. At least that's not what I thought of when responding to the earlier poll. Either way, this I-D is a good base for making progress. In fact, making sure that the I-D is in WG control is a much better way to further the discussion. Thus, I support adoption. Thanks to Joel for posting the summary in 6man as well. Some suggestions to authors: - Some sections could use some more explanation and text instead of the reader guessing why. For example section 6.3 - There is a lot of lower case "recommended" in this I-D. Perhaps, some of these might be more suitable as RECOMMENDED. Section 2 o Compressed-SID (C-SID): A C-SID is a short encoding of a SID in SRv6 packet that does not include the SID block bits (locator block). What about the argument? In other places, we say NF is C-SID length (which does not include argument) and thus I am not sure. Section 3 These common bits are named Locator-Block in [RFC8986] I did not find the term "Locator-Block" in RFC 8986. They do use the term SRv6 SID block though. Section 10 Illustrations will be provided in a separate document. An example/illustration is needed to visualize and understand this document. I urge authors to consider adding it as part of this document itself, perhaps as an appendix. Nits - Expand SRv6, SID, PCE on first use. Thanks! Dhruv On Fri, Oct 1, 2021 at 7:35 PM James Guichard < james.n.guichard@futurewei.com> wrote: > Dear WG: > > > > The chairs would like to express their appreciation for all the responses > received to our emails with reference to how the working group wishes to > move forward with respect to a solution for SRv6 compression. > > > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > as the basis for its compression standardization work. That is part of wh= at > this email attempts to confirm. > > > > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging > that: > > > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change = as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the working > group to publication. A list of these discussion points will be docume= nted > in the WG document and maintained by the document editor in conjunctio= n > with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text describin= g an > open issue be added to the document in the above-described open issues > section: > - "Given that the working group has said that it wants to > standardize one data plane solution, and given that the document co= ntains > multiple SRv6 EndPoint behaviors that some WG members have stated a= re > multiple data plane solutions, the working group will address wheth= er this > is valid and coherent with its one data plane solution objective.". > > > > Please consider the above guidelines as you decide on whether to support > or not this WG adoption. Please express clearly your reasoning for > support/non-support as well as any open discussion points you would like > addressed should the document be adopted into the working group. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --0000000000001cf2ad05ce342622 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Chairs, <= br>
    I would not consider new fla= vors to the existing endpoint behaviors as multiple data planes. At least t= hat's not what I thought of when responding to the earlier poll. Either= way, this I-D is a good base for making progress. In fact, making sure tha= t the I-D is in WG control is a much better way to further the discussion. = Thus, I support adoption. Thanks to Joel for posting the summary in 6man as= well.=C2=A0

    Some sug= gestions to authors:

    - Some sections could use some more explanation and text instead of the re= ader guessing why. For example section 6.3
    - There is a lot of lower case "recommended" in= this I-D. Perhaps, some of these might be more suitable as RECOMMENDED.

    Section 2
    =C2=A0 =C2=A0o =C2=A0Compressed-SID (C-SID): A C= -SID is a short encoding of a SID in
    =C2=A0 =C2=A0 =C2=A0 SRv6 packet th= at does not include the SID block bits (locator
    =C2=A0 =C2=A0 =C2=A0 blo= ck).

    What about the a= rgument? In other places, we say NF is C-SID length (which does not include= argument) and thus I am not sure.

    Section 3

    =C2=A0 =C2= =A0These common bits are named Locator-Block in [RFC8986]

    I did not find the term "Locator-= Block" in RFC 8986. They do use the term SRv6 SID block though.

    Section 10

    <= font face=3D"monospace">=C2=A0 =C2=A0Illustrations will be provided in a se= parate document.

    An e= xample/illustration is needed to visualize and understand this document. I = urge authors to consider adding it as part of this document itself, perhaps= as an appendix. =C2=A0 =C2=A0

    Nits
    - Expand S= Rv6, SID, PCE on first use.=C2=A0

    Thanks!
    Dhr= uv

    On Fri, Oct 1, 2021 at 7:35 PM James Guichard <james.n.guichard@futurewei.com<= /a>> wrote:

    Dear WG:

    =C2=A0

    The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

    =C2=A0

    The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

    =C2=A0

    Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

    =C2=A0

    1. The SPRING working group is adopting a document that has multiple = SRv6 Endpoint behaviors.
    2. The document is a =E2=80=9Cliving=E2=80=9D docu= ment; it may change as it goes through review and analysis by the SPRING wo= rking group.
    3. All open discussion points raised on our mailin= g list MUST be addressed BEFORE said document is allowed to progress from t= he working group to publication. A list of these discussion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
    4. If this document is adopted by the working grou= p, the chairs specify as part of the adoption call that the following text = describing an open issue be added to the document in the above-described open issues section:
      • "Given that the = working group has said that it wants to standardize one data plane solution= , and given that the document contains multiple SRv6 EndPoint behaviors tha= t some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

    =C2=A0

    Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

    =C2=A0

    Thanks!

    =C2=A0

    Jim, Bruno & Joel

    =C2=A0

    =C2=A0

    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --0000000000001cf2ad05ce342622-- From nobody Tue Oct 12 22:30:56 2021 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 0FB533A12F2; Tue, 12 Oct 2021 22:30:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.796 X-Spam-Level: X-Spam-Status: No, score=-1.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 dD9-aJZnx0s2; Tue, 12 Oct 2021 22:30:49 -0700 (PDT) Received: from mail.swisscom.com (mailout110.swisscom.com [138.188.166.110]) (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 CF5113A12E8; Tue, 12 Oct 2021 22:30:47 -0700 (PDT) Received: by mail.swisscom.com; Wed, 13 Oct 2021 07:30:41 +0200 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="----=_Part_1201237_1771716413.1634103041492" X-Mailer: Totemo_TrustMail_(Notification) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ibiB+jDEyp2bvbP8sSYo15Scp2tJbZOPXsUbXU4o4HS2nIhA61slJotPpEm5RIgP6m83ncQUk93+afxb6IFBvd6LzyD3qYHscF2uhJR6780qWopIlUsgqoT2Cx0Qnj0aiqibf+NiPRvpkwtmluCxPm6TdIxlMuNCobj15IJKDrKBZl3Q6AEdvXyia73oz5EKh3vq2HbvK/+x8tmnqS5UuCZ7XRIUgy0WVFYaqSuSv/tVuUL061FYwX68zgBIEnCnxKztPLLg0Ir1223NjHwD2ikgvxfi19OEZl9RxJ+H2jHKp9EEksMlc/yogEbnClIun/+rbEtPnQs6UcJoUOaP/A== 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=jDBNkK+hOKvDXc9IAJ5f0DW1LTHmUZ2mLkXZr3Z1kU8=; b=fgXPbhzIoO+XlAJKv77pyZDiWwOEWADUnn+WvRhtZCiPmBYeGdbX3WbroYcw5ZzSVNJAEUkAWfVS5ZY8LBTwboFtSd6slgMgFTIunkmI6ul4nUFdu44sHeBJjqLWOx3Imutlqw2n+CYNgqxRBFUfKfr3olmbqdikbTklcTkLR9JobbsUunp/WhMuKy+Q3yORHfO04WhiOamKvvLNVS9tjyS9tAmIrXedSHsLpe9p53eQkjyexXZr2sSheSPyc90zqrpId7O31JnpOXgGqNG+mMQHloJl1FaQofu8K0grlFUTDLDguflsCeUKRQDUaMkkpCri9yEwungqFWXw/D4mCQ== 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: , CC: Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQJJjawA Date: Wed, 13 Oct 2021 05:30:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: futurewei.com; dkim=none (message not signed) header.d=none; futurewei.com; dmarc=none action=none header.from=swisscom.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 699c155b-6802-46b9-18d3-08d98e0a970e x-ms-traffictypediagnostic: ZR0P278MB0668: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7NyrHU3m565Hihqqq92V+e4pl33vCPMTxZI9PDKkrWIqEtTzzRDPiUn46L+VV/en0APjkjSa+hx/5Bhg/w0X75OK1+vL4NiYvxWLQ+aewSRZAGYLAdEASgTVpLnHl6fpoakcXwbV9fEWehF7zOQaK1qnYSLw6pY3va5lOyNFWG0LPDATZjDXXrrDYAY9xK062ZgTr53HjY++pJ3tWvYJESO8qEv7pIn9ljfJ5/7VeuDwNgxTKuHW4xhUjxz+9wkiLOVZwr9GMnGNbGUIyP/qqZKN5ptyropEQHHxbaLApAp0CrCF+jo6FV27OXi2ZqxfPyP8K2H7DMsJWj3V2+s+8yu/eg45n/WERhWULPD+hNEkKICrUZ0FXFPvn3bnKynGnWxix22zfRLYibt2R5N04KULscayirCJgVxvQLf6Y4AMX7yMHNJEbWouGoKuJvP8TBi6Yjjz/yWCgFFxvqrP4WXdwQFHLuhI8Yh0uSXSClABvRdPIlLZoZ+sTdUITeq0yWF7AZunUd9UMd8jP2KhlKOrYDuzD053m9POzOwjpG0tZBzSjdC5x/i+wQz5DCyrG4ck7LOFgBN8dt7YdtiAr7ynoWbIANnKilnvLbZzTSxpjzPiGE+DhWajqNylbFoOP8EFn2B1C5WreR4wmSUAgQLKR5vUX1AezD+m5ppuRhzFzMrbEYPde4HE4GoSkyJ/b4LB19Z6v9ggLYyXQfxMESimYjUxZ0nRRk9gNOvAY4aE/o6GFQ80TCIy+5r0fbrtGVSqioKZnUZx8H+4T8JT7Eto9WhE8Lu7vOzM0We65iU= 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:(4636009)(366004)(82960400001)(8676002)(10300500001)(966005)(53546011)(7696005)(9686003)(6506007)(4326008)(86362001)(38070700005)(76116006)(316002)(55016002)(10290500003)(83380400001)(66556008)(52536014)(2906002)(38100700002)(33656002)(186003)(8936002)(166002)(71200400001)(5660300002)(122000001)(110136005)(26005)(66446008)(508600001)(66946007)(66476007)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Y2h6SURtQ0kyN3ZyemI2MzJEYnBDdHBYNXJaY0NRcG80cllQWHlnajN4MUJZ?= =?utf-8?B?SEhic1NGUkhsVm5JeXJUT0R6ejBCWjY2WU9jd2ZPOTNHMGpQTlRNeDJhL3hD?= =?utf-8?B?YTM5UG1nTEwyKzM4bVQySS9ZWHEyYTVWb0laZ2IyNEFDd0hxQzY0d2RTRVBF?= =?utf-8?B?UTBzRFkvemVsZlpoZENQL3czSkhiSnU0ejFWTGROblNhWUgvN211dVJKVndq?= =?utf-8?B?TTh6UkF1aUZycFFhVHRJNXJpbjE5SGJNK1BWdWY3RXdNVDg2d0lHSDVDKzk1?= =?utf-8?B?RXhiaGtYV0J0MWFzcW84NlZWeWJOdjVtVmlqaFNxajVJOFBCeFZOOVRiWWdr?= =?utf-8?B?cThZMTYvVWx6b0g5dmkvRjIyTW1FeDVTOGcwSUlqYXVmT0RFL05PMmlrTk5K?= =?utf-8?B?clVmdGdScDV1Y2w2SWR4MFVHdHdEQmJLN3pnYWNTRzgvYjlPRnNjMWIvalpL?= =?utf-8?B?NmRqM1FUOTh1RlR1Q25XQ2ZTTlhvVzYvUVZVdmQxVzNRZmNYWmljekhDRDhs?= =?utf-8?B?Qk8xOXlPbUM3UlZNVlNYUEdaM1RyTmR1NW5PMGlKdkZiQ0ZWMGxNU3RoL0ZM?= =?utf-8?B?RU9wUWRTUHNlTTUzcm51YnRadmovRDR5TGRCRzZERnV2bFYyTzh3V200Rmda?= =?utf-8?B?aGZIZEUwQS9GSmNBek5aY2hGMjBieDkvL1RodjkxZTNaRGJFQ2dSV1pMQVV0?= =?utf-8?B?TXd5dkloYzUwK2VnQ0VTWnZQVkdDbmwvRDFsN0VYdGR1aUNhVzlpL0hVTU5h?= =?utf-8?B?TFhkKzA5dStNYjB1WVFCdSthZ0lvVTVaMTEvVStlbnIyNFZDbzJTckQ0WWFE?= =?utf-8?B?OGJhQWl4eDRLVUphcUxMczBqa3p2em8rZWdXL1NiS1ZnU3BrYmU4d3drZEZv?= =?utf-8?B?WDhMYTVhK3grM3JOWnVQMHdvMXFxUmVtbUdqbTFXUndSNTkzZTdPM2Vzd2Na?= =?utf-8?B?UTEzREpOLzU5QlRlRVlrSStqcFJiMzBpYWVkMkFqRXh0Q2xzM2x1SC9rZlBz?= =?utf-8?B?K1kwR2FSZUhKSGd1eTZpVUZPa0FzWWszWFdiMUZnWGZsOGljcWlhVzhtcGhj?= =?utf-8?B?YTE1UEdnbXByTGxnZHZBakJFTkc3ZVdVbjhuNnpkZWF0OGZXRThoSUdseW1M?= =?utf-8?B?blg5SlJCWklqVENyRld0R3ZZMEJ2aHlEbTF5QjVLRkdMTnFPWkt0am5ZeDU1?= =?utf-8?B?M0I5d2VtWmljaE50ZFVUWFYyN1JZaVJlbitvbDAyU2lqdHE4a0hQZUdZK2lS?= =?utf-8?B?QVBFa1c0NWxPSUN1V2wxYlpHQVFEbnBSRVpFbDZ1VjBQQzZkcWZzQjRsejJH?= =?utf-8?B?QUt2ZjFBS21qZTBjdUFKTFlvMmxKdm0rMkJsak1maGpQU1Qvc0l3YjhDb2JE?= =?utf-8?B?dzZyK0YvcHZMVGxMcFF4Uk1XS2tISWV4Uk4zdi9SUXlidnNLczBMSTdVY2Nz?= =?utf-8?B?TkUzWTcyVE1rNHlvdm5DRHlCMVpXMW92NC9qNzEycnpsK0FEdDJRckIxanVx?= =?utf-8?B?ZzZOMGdlOEdaQjNDb3FMdWJ1OUk4TGJEMzZhZ2RDeEJzYjFDcklsZ3RNVENT?= =?utf-8?B?Um84MTBCV09qdHhuZi9yOHVYdTViclNtYTdJTk5aU1hSVEJuNnRPanNEdk0w?= =?utf-8?B?ODBzWDcvMlcrV3Byd3BTWnk1VFBrUTFQWVcwejNRWTlyUnM4Skdta3R6QkhL?= =?utf-8?B?bVYvVlFaSjVCMnFFUzk0RXNVWWlLcURLUWc2ZWlZSmZWWXhCYzJXVHhLY0t5?= =?utf-8?Q?n2XT7ZljKyT5wtH5i2rmlEu5hcuV04TOPhMKH1M?= x-ms-exchange-transport-forked: True X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: ZRAP278MB0176.CHEP278.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 699c155b-6802-46b9-18d3-08d98e0a970e X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2021 05:30:38.3073 (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: j1CbgIzkUbjTzg8GWrLSpDiwP6VhRkPqzbREQFw9VIk7QzzFSYXF5bAmzNoiaeew/tBYzZJL65ooxyLjQjNTwRjPA/D4GMSYZ6riGjcB3fo= X-MS-Exchange-Transport-CrossTenantHeadersStamped: ZR0P278MB0668 X-OriginatorOrg: swisscom.com X-CFilter-Loop: Reflected X-Trustmail: processed Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 13 Oct 2021 05:30:54 -0000 ------=_Part_1201237_1771716413.1634103041492 Content-Type: multipart/alternative; boundary="_000_ZRAP278MB0176640C5755214291A7C04189B79ZRAP278MB0176CHEP_" Content-Language: en-US --_000_ZRAP278MB0176640C5755214291A7C04189B79ZRAP278MB0176CHEP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBXRywNCg0KSSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiBkcmFmdCBodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1j b21wcmVzc2lvbi88aHR0cHM6Ly9ldXIwMy5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNBJTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZkcmFmdC1m aWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbiUyRiZkYXRhPTA0JTdDMDEl N0NUaG9tYXMuR3JhZiU0MHN3aXNzY29tLmNvbSU3QzM3OTIxMjQzOTFkZTQyMmI2ZmE3MDhkOThj ODdiYTAzJTdDMzY0ZTViODdjMWM3NDIwZDliZWVjMzVkMTliNTU3YTElN0MwJTdDMCU3QzYzNzY5 NTMzNjg0MDgxNDUxMCU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURB aUxDSlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJnNk YXRhPWRLZVhkOCUyRnNWNjk2VFVnaXA1N3VzVXJvSVhRbGxKVEFwbCUyRlJBQkNwRUI4JTNEJnJl c2VydmVkPTA+IGFuZCB1c2UgaXQgYXMgdGhlIGJhc2lzIGZvciBpdHMgY29tcHJlc3Npb24gc3Rh bmRhcmRpemF0aW9uIHdvcmsuDQoNCkkgZm91bmQgdGhlIGRvY3VtZW50IGRyYWZ0LWlldGYtc3By aW5nLWNvbXByZXNzaW9uLXJlcXVpcmVtZW50IGFuZCBkcmFmdC1pZXRmLXNwcmluZy1jb21wcmVz c2lvbi1hbmFseXNpcyB2ZXJ5IHVzZWZ1bCB0byB1bmRlcnN0YW5kIHRoZSBjb250ZXh0Lg0KDQpC ZXN0IHdpc2hlcw0KVGhvbWFzDQoNCkZyb206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5v cmc+IE9uIEJlaGFsZiBPZiBKYW1lcyBHdWljaGFyZA0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDEs IDIwMjEgNDowNSBQTQ0KVG86IFNQUklORyBXRyA8c3ByaW5nQGlldGYub3JnPg0KQ2M6IHNwcmlu Zy1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IFtzcHJpbmddIFdHIEFkb3B0aW9uIGNhbGwgZm9y IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3By aW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLw0KDQpEZWFyIFdHOg0KDQpUaGUgY2hhaXJzIHdvdWxk IGxpa2UgdG8gZXhwcmVzcyB0aGVpciBhcHByZWNpYXRpb24gZm9yIGFsbCB0aGUgcmVzcG9uc2Vz IHJlY2VpdmVkIHRvIG91ciBlbWFpbHMgd2l0aCByZWZlcmVuY2UgdG8gaG93IHRoZSB3b3JraW5n IGdyb3VwIHdpc2hlcyB0byBtb3ZlIGZvcndhcmQgd2l0aCByZXNwZWN0IHRvIGEgc29sdXRpb24g Zm9yIFNSdjYgY29tcHJlc3Npb24uDQoNClRoZSBhcHBhcmVudCBpbmNsaW5hdGlvbiBvZiB0aGUg d29ya2luZyBncm91cCBpcyB0byB1c2UgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vIGFzIHRoZSBi YXNpcyBmb3IgaXRzIGNvbXByZXNzaW9uIHN0YW5kYXJkaXphdGlvbiB3b3JrLiBUaGF0IGlzIHBh cnQgb2Ygd2hhdCB0aGlzIGVtYWlsIGF0dGVtcHRzIHRvIGNvbmZpcm0uDQoNCkJlY2F1c2Ugb2Yg dGhlIGFib3ZlIHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBpc3N1ZSBhIDItd2VlayBXRyBjYWxs IGZvciBhZG9wdGlvbiBlbmRpbmcgT2N0b2JlciAxNXRoIGZvciBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVz c2lvbi8gYnV0IHdpdGggc29tZSBjbGVhciBndWlkZWxpbmVzIGFzIGZvbGxvd3MuIEJ5IGV4cHJl c3Npbmcgc3VwcG9ydCBmb3IgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCB5b3UgYXJlIGZ1bGx5 IGF3YXJlIG9mIGFuZCBhcmUgYWNrbm93bGVkZ2luZyB0aGF0Og0KDQoNCiAgMS4gIFRoZSBTUFJJ Tkcgd29ya2luZyBncm91cCBpcyBhZG9wdGluZyBhIGRvY3VtZW50IHRoYXQgaGFzIG11bHRpcGxl IFNSdjYgRW5kcG9pbnQgYmVoYXZpb3JzLg0KICAyLiAgVGhlIGRvY3VtZW50IGlzIGEg4oCcbGl2 aW5n4oCdIGRvY3VtZW50OyBpdCBtYXkgY2hhbmdlIGFzIGl0IGdvZXMgdGhyb3VnaCByZXZpZXcg YW5kIGFuYWx5c2lzIGJ5IHRoZSBTUFJJTkcgd29ya2luZyBncm91cC4NCiAgMy4gIEFsbCBvcGVu IGRpc2N1c3Npb24gcG9pbnRzIHJhaXNlZCBvbiBvdXIgbWFpbGluZyBsaXN0IE1VU1QgYmUgYWRk cmVzc2VkIEJFRk9SRSBzYWlkIGRvY3VtZW50IGlzIGFsbG93ZWQgdG8gcHJvZ3Jlc3MgZnJvbSB0 aGUgd29ya2luZyBncm91cCB0byBwdWJsaWNhdGlvbi4gQSBsaXN0IG9mIHRoZXNlIGRpc2N1c3Np b24gcG9pbnRzIHdpbGwgYmUgZG9jdW1lbnRlZCBpbiB0aGUgV0cgZG9jdW1lbnQgYW5kIG1haW50 YWluZWQgYnkgdGhlIGRvY3VtZW50IGVkaXRvciBpbiBjb25qdW5jdGlvbiB3aXRoIHRoZSBjaGFp cnMuDQogIDQuICBJZiB0aGlzIGRvY3VtZW50IGlzIGFkb3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3Jv dXAsIHRoZSBjaGFpcnMgc3BlY2lmeSBhcyBwYXJ0IG9mIHRoZSBhZG9wdGlvbiBjYWxsIHRoYXQg dGhlIGZvbGxvd2luZyB0ZXh0IGRlc2NyaWJpbmcgYW4gb3BlbiBpc3N1ZSBiZSBhZGRlZCB0byB0 aGUgZG9jdW1lbnQgaW4gdGhlIGFib3ZlLWRlc2NyaWJlZCBvcGVuIGlzc3VlcyBzZWN0aW9uOg0K ICAgICAqICAgIkdpdmVuIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHNhaWQgdGhhdCBpdCB3 YW50cyB0byBzdGFuZGFyZGl6ZSBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiwgYW5kIGdpdmVuIHRo YXQgdGhlIGRvY3VtZW50IGNvbnRhaW5zIG11bHRpcGxlIFNSdjYgRW5kUG9pbnQgYmVoYXZpb3Jz IHRoYXQgc29tZSBXRyBtZW1iZXJzIGhhdmUgc3RhdGVkIGFyZSBtdWx0aXBsZSBkYXRhIHBsYW5l IHNvbHV0aW9ucywgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhZGRyZXNzIHdoZXRoZXIgdGhpcyBp cyB2YWxpZCBhbmQgY29oZXJlbnQgd2l0aCBpdHMgb25lIGRhdGEgcGxhbmUgc29sdXRpb24gb2Jq ZWN0aXZlLiIuDQoNClBsZWFzZSBjb25zaWRlciB0aGUgYWJvdmUgZ3VpZGVsaW5lcyBhcyB5b3Ug ZGVjaWRlIG9uIHdoZXRoZXIgdG8gc3VwcG9ydCBvciBub3QgdGhpcyBXRyBhZG9wdGlvbi4gUGxl YXNlIGV4cHJlc3MgY2xlYXJseSB5b3VyIHJlYXNvbmluZyBmb3Igc3VwcG9ydC9ub24tc3VwcG9y dCBhcyB3ZWxsIGFzIGFueSBvcGVuIGRpc2N1c3Npb24gcG9pbnRzIHlvdSB3b3VsZCBsaWtlIGFk ZHJlc3NlZCBzaG91bGQgdGhlIGRvY3VtZW50IGJlIGFkb3B0ZWQgaW50byB0aGUgd29ya2luZyBn cm91cC4NCg0KVGhhbmtzIQ0KDQpKaW0sIEJydW5vICYgSm9lbA0KDQoNCg== --_000_ZRAP278MB0176640C5755214291A7C04189B79ZRAP278MB0176CHEP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1TIjsNCglwYW5vc2Ut MToyIDExIDYgMyAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuTXNvTGlzdFBhcmFn cmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0 eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBU ZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5 bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiVHJl YnVjaGV0IE1TIixzYW5zLXNlcmlmOw0KCWNvbG9yOiM0NDU0NkE7DQoJZm9udC13ZWlnaHQ6bm9y bWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5p dGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjc1MTY5OTM5MzsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTcyMTY1NDc3NiA2NzY5ODcwMyA2 NzY5ODY4OSA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5 ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0 DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0K QGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmln aHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVs OQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5k ZW50Oi05LjBwdDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMjI1NDg1NjgyOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczotMzkzOTU4OTkyO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0 b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkRFLUNIIiBsaW5rPSIjMDU2M0MxIiB2 bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzQ0NTQ2QTttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+RGVhciBXRyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZBO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZBO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5JIHN1cHBvcnQgdGhlIGFkb3B0aW9uIG9mIGRyYWZ0PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PjxhIGhyZWY9Imh0dHBzOi8vZXVyMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwcyUzQSUyRiUyRmRhdGF0cmFja2VyLmlldGYub3JnJTJGZG9jJTJGZHJhZnQtZmls c2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24lMkYmYW1wO2RhdGE9MDQlN0Mw MSU3Q1Rob21hcy5HcmFmJTQwc3dpc3Njb20uY29tJTdDMzc5MjEyNDM5MWRlNDIyYjZmYTcwOGQ5 OGM4N2JhMDMlN0MzNjRlNWI4N2MxYzc0MjBkOWJlZWMzNWQxOWI1NTdhMSU3QzAlN0MwJTdDNjM3 Njk1MzM2ODQwODE0NTEwJTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdN REFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAm YW1wO3NkYXRhPWRLZVhkOCUyRnNWNjk2VFVnaXA1N3VzVXJvSVhRbGxKVEFwbCUyRlJBQkNwRUI4 JTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5n LXNydjYtc3JoLWNvbXByZXNzaW9uLzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzQ0NTQ2QTttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+YW5kIHVzZSBpdCBhcyB0aGUgYmFzaXMgZm9yIGl0cyBjb21wcmVzc2lv biBzdGFuZGFyZGl6YXRpb24gd29yay48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ1NDZBO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzQ0NTQ2 QTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SSBmb3VuZCB0aGUgZG9jdW1lbnQgZHJhZnQt aWV0Zi1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQgYW5kIGRyYWZ0LWlldGYtc3ByaW5n LWNvbXByZXNzaW9uLWFuYWx5c2lzIHZlcnkgdXNlZnVsDQogdG8gdW5kZXJzdGFuZCB0aGUgY29u dGV4dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VHJl YnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzQ0NTQ2QTttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0NDU0NkE7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJlc3Qgd2lzaGVzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM0NDU0NkE7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRob21hczxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiM0NDU0NkE7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIj4gc3ByaW5nICZsdDtzcHJpbmctYm91bmNlc0BpZXRmLm9yZyZndDsNCjxi Pk9uIEJlaGFsZiBPZiA8L2I+SmFtZXMgR3VpY2hhcmQ8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5 LCBPY3RvYmVyIDEsIDIwMjEgNDowNSBQTTxicj4NCjxiPlRvOjwvYj4gU1BSSU5HIFdHICZsdDtz cHJpbmdAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBzcHJpbmctY2hhaXJzQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtzcHJpbmddIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNy djYtc3JoLWNvbXByZXNzaW9uLzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkRl YXIgV0c6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gZXhwcmVz cyB0aGVpciBhcHByZWNpYXRpb24gZm9yIGFsbCB0aGUgcmVzcG9uc2VzIHJlY2VpdmVkIHRvIG91 ciBlbWFpbHMgd2l0aCByZWZlcmVuY2UgdG8gaG93IHRoZSB3b3JraW5nIGdyb3VwIHdpc2hlcyB0 byBtb3ZlIGZvcndhcmQgd2l0aCByZXNwZWN0IHRvIGEgc29sdXRpb24gZm9yIFNSdjYgY29tcHJl c3Npb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBhcHBhcmVudCBpbmNsaW5hdGlvbiBvZiB0 aGUgd29ya2luZyBncm91cCBpcyB0byB1c2UNCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNz aW9uLyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2No ZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88L2E+IGFzIHRoZSBiYXNpcyBmb3IgaXRz IGNvbXByZXNzaW9uIHN0YW5kYXJkaXphdGlvbiB3b3JrLiBUaGF0IGlzIHBhcnQgb2Ygd2hhdCB0 aGlzIGVtYWlsIGF0dGVtcHRzIHRvIGNvbmZpcm0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5CZWNhdXNl IG9mIHRoZSBhYm92ZSB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gaXNzdWUgYSAyLXdlZWsgV0cg Y2FsbCBmb3IgYWRvcHRpb24gZW5kaW5nIE9jdG9iZXIgMTU8c3VwPnRoPC9zdXA+IGZvcg0KPGEg aHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVu Zy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9u LzwvYT4gYnV0IHdpdGggc29tZSBjbGVhciBndWlkZWxpbmVzIGFzIGZvbGxvd3MuIEJ5IGV4cHJl c3Npbmcgc3VwcG9ydCBmb3IgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCB5b3UgYXJlIGZ1bGx5 IGF3YXJlIG9mIGFuZCBhcmUgYWNrbm93bGVkZ2luZyB0aGF0Og0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHN0YXJ0PSIxIiB0 eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBTUFJJ Tkcgd29ya2luZyBncm91cCBpcyBhZG9wdGluZyBhIGRvY3VtZW50IHRoYXQgaGFzIG11bHRpcGxl IFNSdjYgRW5kcG9pbnQgYmVoYXZpb3JzLg0KPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzMiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgZG9jdW1lbnQgaXMgYSDigJxsaXZp bmfigJ0gZG9jdW1lbnQ7IGl0IG1heSBjaGFuZ2UgYXMgaXQgZ29lcyB0aHJvdWdoIHJldmlldyBh bmQgYW5hbHlzaXMgYnkgdGhlIFNQUklORyB3b3JraW5nIGdyb3VwLg0KPG86cD48L286cD48L3Nw YW4+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPjxzcGFuIGxhbmc9IkVOLVVTIj5BbGwgb3BlbiBk aXNjdXNzaW9uIHBvaW50cyByYWlzZWQgb24gb3VyIG1haWxpbmcgbGlzdCBNVVNUIGJlIGFkZHJl c3NlZCBCRUZPUkUgc2FpZCBkb2N1bWVudCBpcyBhbGxvd2VkIHRvIHByb2dyZXNzIGZyb20gdGhl IHdvcmtpbmcgZ3JvdXAgdG8gcHVibGljYXRpb24uIEEgbGlzdA0KIG9mIHRoZXNlIGRpc2N1c3Np b24gcG9pbnRzIHdpbGwgYmUgZG9jdW1lbnRlZCBpbiB0aGUgV0cgZG9jdW1lbnQgYW5kIG1haW50 YWluZWQgYnkgdGhlIGRvY3VtZW50IGVkaXRvciBpbiBjb25qdW5jdGlvbiB3aXRoIHRoZSBjaGFp cnMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+PHNwYW4gbGFu Zz0iRU4tVVMiPklmIHRoaXMgZG9jdW1lbnQgaXMgYWRvcHRlZCBieSB0aGUgd29ya2luZyBncm91 cCwgdGhlIGNoYWlycyBzcGVjaWZ5IGFzIHBhcnQgb2YgdGhlIGFkb3B0aW9uIGNhbGwgdGhhdCB0 aGUgZm9sbG93aW5nIHRleHQgZGVzY3JpYmluZyBhbiBvcGVuIGlzc3VlIGJlIGFkZGVkIHRvIHRo ZQ0KIGRvY3VtZW50IGluIHRoZSBhYm92ZS1kZXNjcmliZWQgb3BlbiBpc3N1ZXMgc2VjdGlvbjo8 bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRp c2MiPg0KPGxpIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDIg bGZvMyI+PHNwYW4gbGFuZz0iRU4tVVMiPiZxdW90O0dpdmVuIHRoYXQgdGhlIHdvcmtpbmcgZ3Jv dXAgaGFzIHNhaWQgdGhhdCBpdCB3YW50cyB0byBzdGFuZGFyZGl6ZSBvbmUgZGF0YSBwbGFuZSBz b2x1dGlvbiwgYW5kIGdpdmVuIHRoYXQgdGhlIGRvY3VtZW50IGNvbnRhaW5zIG11bHRpcGxlIFNS djYgRW5kUG9pbnQgYmVoYXZpb3JzIHRoYXQgc29tZSBXRyBtZW1iZXJzDQogaGF2ZSBzdGF0ZWQg YXJlIG11bHRpcGxlIGRhdGEgcGxhbmUgc29sdXRpb25zLCB0aGUgd29ya2luZyBncm91cCB3aWxs IGFkZHJlc3Mgd2hldGhlciB0aGlzIGlzIHZhbGlkIGFuZCBjb2hlcmVudCB3aXRoIGl0cyBvbmUg ZGF0YSBwbGFuZSBzb2x1dGlvbiBvYmplY3RpdmUuJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwv bGk+PC91bD4NCjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPlBsZWFzZSBjb25zaWRlciB0aGUgYWJvdmUgZ3VpZGVsaW5lcyBhcyB5b3Ug ZGVjaWRlIG9uIHdoZXRoZXIgdG8gc3VwcG9ydCBvciBub3QgdGhpcyBXRyBhZG9wdGlvbi4gUGxl YXNlIGV4cHJlc3MgY2xlYXJseSB5b3VyIHJlYXNvbmluZyBmb3Igc3VwcG9ydC9ub24tc3VwcG9y dCBhcyB3ZWxsIGFzIGFueSBvcGVuIGRpc2N1c3Npb24gcG9pbnRzIHlvdSB3b3VsZCBsaWtlIGFk ZHJlc3NlZA0KIHNob3VsZCB0aGUgZG9jdW1lbnQgYmUgYWRvcHRlZCBpbnRvIHRoZSB3b3JraW5n IGdyb3VwLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Smlt LCBCcnVubyAmYW1wOyBKb2VsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_ZRAP278MB0176640C5755214291A7C04189B79ZRAP278MB0176CHEP_-- ------=_Part_1201237_1771716413.1634103041492 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMjExMDEzMDUzMDQxWjAtBgkqhkiG9w0B CTQxIDAeMA0GCWCGSAFlAwQCAQUAoQ0GCSqGSIb3DQEBCwUAMC8GCSqGSIb3DQEJBDEiBCBS8eiP TFYMdkhrvBk/VEp6SF5mt7p5yWVTWGYu1OKKdjB9BgkrBgEEAYI3EAQxcDBuMFYxCzAJBgNVBAYT AkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNzU2lnbiBQZXJzb25hbCBT aWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8wfwYLKoZIhvcNAQkQAgsx cKBuMFYxCzAJBgNVBAYTAkNIMRUwEwYDVQQKEwxTd2lzc1NpZ24gQUcxMDAuBgNVBAMTJ1N3aXNz U2lnbiBQZXJzb25hbCBTaWx2ZXIgQ0EgMjAxNCAtIEcyMgIUeIuhHnNW+9mJCIySjpOK+tpcTG8w gYMGCSqGSIb3DQEJDzF2MHQwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjALBglghkgBZQMEAQIw CgYIKoZIhvcNAwcwCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwCwYJYIZI AWUDBAIEMAsGCWCGSAFlAwQCBzANBgkqhkiG9w0BAQsFAASCAQB5HDL+i7R2IACfZBKlYp3kM1oa B2NCelH8c+E9Akrj93Gvzg/QD0ZJ47YCVtXIkcHUpmPrvJgoiNBzFw9KgGNsKxb7vc6lh1RKRDL6 X5dIcgeBwnLh3n03hQgxABL2eWA8J+MMeowMgNfyYpxuP8izWhpfBTHuExnfRT+f6iSsOyF73D4R 6oHMRNCN3ujUoVSmyc/RbOw6Yse7bukvGzv6l+3wrdPRYgvMxUPA604R5YpnlXxw65Xy+Z+EwiQb ihzHTpdmAQeVzCSfHcNfg+Pj/qS5oA0mhLnqbpTygW4v++pLkiDlk/5jHm27HtM+V9YxIld1RuuR pF97FsIGKC1MAAAAAAAA ------=_Part_1201237_1771716413.1634103041492-- From nobody Wed Oct 13 00:37:00 2021 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 570713A1676; Tue, 12 Oct 2021 09:21:41 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=uniroma2.it header.b=LBLXA9K1; dkim=pass (2048-bit key) header.d=uniroma2.it header.b=IuzmqAEn 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 QxEJDTNcpm54; Tue, 12 Oct 2021 09:21:34 -0700 (PDT) Received: from smtp.uniroma2.it (smtp.uniroma2.it [160.80.6.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 0325D3A164F; Tue, 12 Oct 2021 09:21:32 -0700 (PDT) Received: from smtpauth-2019-1.uniroma2.it (smtpauth-2019-1.uniroma2.it [160.80.5.46]) by smtp-2015.uniroma2.it (8.14.4/8.14.4/Debian-8) with ESMTP id 19CGLJOb029943; Tue, 12 Oct 2021 18:21:24 +0200 Received: from [192.168.178.104] (unknown [194.79.222.156]) by smtpauth-2019-1.uniroma2.it (Postfix) with ESMTPSA id B4897120092; Tue, 12 Oct 2021 18:21:15 +0200 (CEST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=uniroma2.it; s=ed201904; t=1634055675; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=L+5/leno8B53Yh2oRG9HjUZQIsifgdlN1UyBe9j4dCI=; b=LBLXA9K1VZZ9UF43VNJ4fRkTopvo8Hkd3/4wB+X49hM9iQWRT0oSOrBl4j/KYBF/3awq9T 1gieS5V/ANoQB1Bg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniroma2.it; s=rsa201904; t=1634055675; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=L+5/leno8B53Yh2oRG9HjUZQIsifgdlN1UyBe9j4dCI=; b=IuzmqAEnWIeZYGLEGiP1JfATOxf84n7lJkgvKkPWvn1YymicJh8/fKXtJonunkFlECloF1 Xs0eEmfihgYsJxAcy+B+d2/V91H/2nE1kcZ5Z2W+ePyqDFdnAGztBX2agRlsHhg94RUHn7 Qw+zAL9NDC1+dZRrKuYswsd+e64lCO8IomyZNPKSJrRDw62gWTT5Kl8mtKl4PxLE+KiVbJ IFwds7BkUp+p3dgScNH0E2BFxw7qjybSwcFpJjVjVLc5qk4eAilgTrF7nvkI14oSopfft2 EVwxGHoeoOHkvcYNwmImSHf4qTH58ti4ELF5TFQcZjUt1JBOacGGP8rn6iJBnQ== From: Pier Luigi Ventre Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9167FC1D-AFD6-4C1A-A818-38CE53926769" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Tue, 12 Oct 2021 18:21:15 +0200 In-Reply-To: Cc: SPRING WG , "spring-chairs@ietf.org" To: James Guichard References: X-Mailer: Apple Mail (2.3445.104.21) X-Virus-Scanned: clamav-milter 0.100.0 at smtp-2015 X-Virus-Status: Clean Archived-At: X-Mailman-Approved-At: Wed, 13 Oct 2021 00:36:55 -0700 Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 12 Oct 2021 16:21:46 -0000 --Apple-Mail=_9167FC1D-AFD6-4C1A-A818-38CE53926769 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear J. Guichard, Spring WG and Spring Chairs we support the adoption of = draft-filsfilscheng-spring-srv6-srh-compression. To the best of our = knowledge, CSID is single SRv6 based data plane that defines next and = replace flavors to End, End.X, and End.T SIDs and it is consistent with = RFC8996 Best regards Pier Luigi Ventre (UniRoma2) > On Oct 1, 2021, at 4:04 PM, James Guichard = wrote: >=20 > Dear WG: > =20 > The chairs would like to express their appreciation for all the = responses received to our emails with reference to how the working group = wishes to move forward with respect to a solution for SRv6 compression.=20= > =20 > The apparent inclination of the working group is to use = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = as the basis for its compression standardization work. That is = part of what this email attempts to confirm. > =20 > Because of the above the chairs would like to issue a 2-week WG call = for adoption ending October 15th for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = but with some clear guidelines as follows. By expressing = support for adoption of this document you are fully aware of and are = acknowledging that:=20 > =20 > The SPRING working group is adopting a document that has multiple SRv6 = Endpoint behaviors.=20 > The document is a =E2=80=9Cliving=E2=80=9D document; it may change as = it goes through review and analysis by the SPRING working group.=20 > All open discussion points raised on our mailing list MUST be = addressed BEFORE said document is allowed to progress from the working = group to publication. A list of these discussion points will be = documented in the WG document and maintained by the document editor in = conjunction with the chairs.=20 > If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open = issue be added to the document in the above-described open issues = section: > "Given that the working group has said that it wants to standardize = one data plane solution, and given that the document contains multiple = SRv6 EndPoint behaviors that some WG members have stated are multiple = data plane solutions, the working group will address whether this is = valid and coherent with its one data plane solution objective.". > =20 > Please consider the above guidelines as you decide on whether to = support or not this WG adoption. Please express clearly your reasoning = for support/non-support as well as any open discussion points you would = like addressed should the document be adopted into the working group. > =20 > Thanks! > =20 > Jim, Bruno & Joel > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring = --Apple-Mail=_9167FC1D-AFD6-4C1A-A818-38CE53926769 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear = J. Guichard, Spring WG and Spring Chairs
    we support the = adoption of draft-filsfilscheng-spring-srv6-srh-compression. To the best = of our knowledge, CSID is single SRv6 based data plane that defines next = and replace flavors to End, End.X, and End.T SIDs and it is consistent = with RFC8996

    Best regards
    Pier Luigi Ventre = (UniRoma2)

    On Oct 1, 2021, at 4:04 PM, James Guichard = <james.n.guichard@futurewei.com> wrote:

    Dear WG:
     
    The chairs would like to = express their appreciation for all the responses received to our emails = with reference to how the working group wishes to move forward with = respect to a solution for SRv6 compression. 
     
    The apparent inclination = of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ as the basis for its = compression standardization work. That is part of what this email = attempts to confirm.
     
    Because of the above the = chairs would like to issue a 2-week WG call for adoption ending October = 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ but with some clear = guidelines as follows. By expressing support for adoption of this = document you are fully aware of and are acknowledging that: 
     
    1. The SPRING working group is adopting = a document that has multiple SRv6 Endpoint behaviors. 
    2. The document is = a =E2=80=9Cliving=E2=80=9D document; it may change as it goes through = review and analysis by the SPRING working group. 
    3. All open = discussion points raised on our mailing list MUST be addressed BEFORE = said document is allowed to progress from the working group to = publication. A list of these discussion points will be documented in the = WG document and maintained by the document editor in conjunction with = the chairs. 
    4. If this = document is adopted by the working group, the chairs specify as part of = the adoption call that the following text describing an open issue be = added to the document in the above-described open issues section:
      • "Given that the = working group has said that it wants to standardize one data plane = solution, and given that the document contains multiple SRv6 EndPoint = behaviors that some WG members have stated are multiple data plane = solutions, the working group will address whether this is valid and = coherent with its one data plane solution objective.".
     
    Please consider the above = guidelines as you decide on whether to support or not this WG adoption. = Please express clearly your reasoning for support/non-support as well as = any open discussion points you would like addressed should the document = be adopted into the working group.
     
    Thanks!
     
    Jim, Bruno & Joel
     
     
    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://www.ietf.org/mailman/listinfo/spring

    = --Apple-Mail=_9167FC1D-AFD6-4C1A-A818-38CE53926769-- From paolo.lungaroni@uniroma2.it Tue Oct 12 09:44:04 2021 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 79FE03A0C7E; Tue, 12 Oct 2021 09:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=uniroma2.it header.b=jn8KhXc/; dkim=pass (2048-bit key) header.d=uniroma2.it header.b=EwxiqeJ4 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 j2KcJAaYjpq7; Tue, 12 Oct 2021 09:43:57 -0700 (PDT) Received: from smtp.uniroma2.it (smtp.uniroma2.it [160.80.6.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 EFD203A0BDD; Tue, 12 Oct 2021 09:43:56 -0700 (PDT) Received: from smtpauth-2019-1.uniroma2.it (smtpauth-2019-1.uniroma2.it [160.80.5.46]) by smtp-2015.uniroma2.it (8.14.4/8.14.4/Debian-8) with ESMTP id 19CGhhlO030842; Tue, 12 Oct 2021 18:43:48 +0200 Received: from imac-di-mac.homenet.telecomitalia.it (host-87-3-36-93.retail.telecomitalia.it [87.3.36.93]) by smtpauth-2019-1.uniroma2.it (Postfix) with ESMTPSA id B5254120092; Tue, 12 Oct 2021 18:43:38 +0200 (CEST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=uniroma2.it; s=ed201904; t=1634057018; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C0ryF87tlQD8dD//WGgHJxcldJtF1Fd2jcZPeGAORSc=; b=jn8KhXc/lBtJRwr+CHnGx+s5OoiP4qnVFS2DVwDdgwP7QIMHn6PW3hFNCIoaTsDmdmMe0H mn5joPpts4XuL2DQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniroma2.it; s=rsa201904; t=1634057018; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C0ryF87tlQD8dD//WGgHJxcldJtF1Fd2jcZPeGAORSc=; b=EwxiqeJ45MHz/QfW3GWEotNCILaXpPBFimZc4fUH3e+rAO88TrWTqu1yXcKEpyc9fm2B/w xvsLETdjOLCxAMqSfLbCWTEk/1gYuYgZM9TnuMSKoTwxZUhiqcNb/8KG/K+3K9fVVmXeng YqYRZ8bpXxbfR8tg7j8aXsO6IP07FEcYbtBqFiWsiohV3Yr3YjseaCvU4BY9KvOwWHqysZ vCzwaNhTut1A3nI7pfJtRbf5EEF1w/TbFGKqo6sNoXb22NGYLWUZVOkcaY3oCEjPLxxWdZ VAvXKXXsy/kHeRMMYtMpnc5gU2AT5K6NYQf6F280nwz0B5AFoPWoHviC0bB5ew== Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.7\)) From: Paolo Lungaroni In-Reply-To: Date: Tue, 12 Oct 2021 18:43:37 +0200 Cc: SPRING WG , "spring-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: To: James Guichard X-Mailer: Apple Mail (2.3445.9.7) X-Virus-Scanned: clamav-milter 0.100.0 at smtp-2015 X-Virus-Status: Clean Archived-At: X-Mailman-Approved-At: Wed, 13 Oct 2021 00:36:55 -0700 Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 12 Oct 2021 16:46:15 -0000 I support the adoption of = draft-filsfilscheng-spring-srv6-srh-compression. I have been working together with my team at the university of Rome Tor = Vergata on SRv6 support in the Linux kernel.=20 The CSID draft builds on RFC8986 and defines two new flavors.=20 We supported these two flavors in the Linux kernel by re-using the same = infrastructure developed to support the flavors defined in RFC8986.=20 Which confirms that the new flavors build on the single dataplane (SRv6 = dataplane). Thanks=20 Paolo > Il giorno 01 ott 2021, alle ore 16:04, James Guichard = ha scritto: >=20 > Dear WG: > =20 > The chairs would like to express their appreciation for all the = responses received to our emails with reference to how the working group = wishes to move forward with respect to a solution for SRv6 compression.=20= > =20 > The apparent inclination of the working group is to use = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ as the basis for its compression standardization work. That is = part of what this email attempts to confirm. > =20 > Because of the above the chairs would like to issue a 2-week WG call = for adoption ending October 15th for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ but with some clear guidelines as follows. By expressing support = for adoption of this document you are fully aware of and are = acknowledging that:=20 > =20 > =E2=80=A2 The SPRING working group is adopting a document that = has multiple SRv6 Endpoint behaviors.=20 > =E2=80=A2 The document is a =E2=80=9Cliving=E2=80=9D document; = it may change as it goes through review and analysis by the SPRING = working group.=20 > =E2=80=A2 All open discussion points raised on our mailing list = MUST be addressed BEFORE said document is allowed to progress from the = working group to publication. A list of these discussion points will be = documented in the WG document and maintained by the document editor in = conjunction with the chairs.=20 > =E2=80=A2 If this document is adopted by the working group, the = chairs specify as part of the adoption call that the following text = describing an open issue be added to the document in the above-described = open issues section: > =E2=80=A2 "Given that the working group has said that it = wants to standardize one data plane solution, and given that the = document contains multiple SRv6 EndPoint behaviors that some WG members = have stated are multiple data plane solutions, the working group will = address whether this is valid and coherent with its one data plane = solution objective.". > =20 > Please consider the above guidelines as you decide on whether to = support or not this WG adoption. Please express clearly your reasoning = for support/non-support as well as any open discussion points you would = like addressed should the document be adopted into the working group. > =20 > Thanks! > =20 > Jim, Bruno & Joel > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From andrea.mayer@uniroma2.it Tue Oct 12 09:50:02 2021 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 8998F3A0C7E; Tue, 12 Oct 2021 09:50:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=uniroma2.it header.b=2g+UsER0; dkim=pass (2048-bit key) header.d=uniroma2.it header.b=v0JNfwPe 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 tPjdOFYy2jgp; Tue, 12 Oct 2021 09:49:57 -0700 (PDT) Received: from smtp.uniroma2.it (smtp.uniroma2.it [160.80.6.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 635FE3A1671; Tue, 12 Oct 2021 09:49:55 -0700 (PDT) Received: from smtpauth-2019-1.uniroma2.it (smtpauth-2019-1.uniroma2.it [160.80.5.46]) by smtp-2015.uniroma2.it (8.14.4/8.14.4/Debian-8) with ESMTP id 19CGnhiK031079; Tue, 12 Oct 2021 18:49:48 +0200 Received: from lubuntu-18.04 (unknown [160.80.103.126]) by smtpauth-2019-1.uniroma2.it (Postfix) with ESMTPSA id 5778A1227F6; Tue, 12 Oct 2021 18:49:39 +0200 (CEST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=uniroma2.it; s=ed201904; t=1634057379; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RKMIakqoWjkQX2BgaqCSTsWDoCiY3f4cuVgPSh0SKqQ=; b=2g+UsER06qZJfmf/l8pVUzJaXfltzOa3AG86mSshIctoV4+ogp+DrSnO1wT6Wv3Q9UA2nO ax/osjG3hZe1ECAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniroma2.it; s=rsa201904; t=1634057379; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=RKMIakqoWjkQX2BgaqCSTsWDoCiY3f4cuVgPSh0SKqQ=; b=v0JNfwPeLaTAft5dPpWzBlIcwc/fL2g/DNOUgtMRCh0L21GRd4HoPDPhag/41CtbyQs1qp P7ipylz2EgkPVbX1zdqfZTO3xc8yZ+1EZ5xOg/78FRCczAwi/et0MkZ/Yb0BLQu+6HJGoE 0/+LROP/z5oZhItjcUoxLvH0jSk3k1ej1jeuEaVqs+WHhsTuWKsp8ANZZIxZbLeOCzdoZl S4MGqOxyqtmkNZD8f9gnxYIQPE0u/LyRoBeQERY8vpWfIUSlm960EEtMqkvLPayZtIKUyd 8Fz/GQt0cj4XqR0ri+3M3OTyIfUD2QNxd9TVORC2DHdwd9EBFQew4l2XyKS9NQ== Date: Tue, 12 Oct 2021 18:49:28 +0200 From: Andrea Mayer To: James Guichard Cc: Andrea Mayer , SPRING WG , "spring-chairs@ietf.org" Message-Id: <20211012184928.fc9f46c7202ed18e9d3050cd@uniroma2.it> In-Reply-To: References: X-Mailer: Sylpheed 3.5.1 (GTK+ 2.24.32; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.0 at smtp-2015 X-Virus-Status: Clean Archived-At: X-Mailman-Approved-At: Wed, 13 Oct 2021 00:36:55 -0700 Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 12 Oct 2021 16:53:07 -0000 Dear WG, WG chairs, I support the adoption of CSID draft (draft-filsfilscheng-spring-srv6-srh-compression). Over the past years, I have been working extensively on the SRv6 stack in the Linux kernel. I have contributed to the Linux kernel by introducing new SRv6 features as well as optimizing current SRv6 code in the Linux. RFC8986 defines multiple flavors for End, End.X, and End.T SID behaviors. I already developed the infrastructure to support the flavors defined in RFC8986 in the Linux kernel. CSID draft builds on RFC8986 and defines two new flavors for these SIDs. I have implemented CSID in the Linux kernel. The implementation leverages the same infrastructure developed for the flavors defined in RFC8986. Thanks Andrea On Fri, 1 Oct 2021 14:04:48 +0000 James Guichard wrote: > Dear WG: > > > > The chairs would like to express their appreciation for all the responses received to our emails with reference to how the working group wishes to move forward with respect to a solution for SRv6 compression. > > > > The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardization work. That is part of what this email attempts to confirm. > > > > Because of the above the chairs would like to issue a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that: > > > The SPRING working group is adopting a document that has multiple SRv6 Endpoint behaviors. > The document is a “living” document; it may change as it goes through review and analysis by the SPRING working group. > All open discussion points raised on our mailing list MUST be addressed BEFORE said document is allowed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maintained by the document editor in conjunction with the chairs. > If this document is adopted by the working group, the chairs specify as part of the adoption call that the following text describing an open issue be added to the document in the above-described open issues section: > "Given that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this is valid and coherent with its one data plane solution objective.". > > > Please consider the above guidelines as you decide on whether to support or not this WG adoption. Please express clearly your reasoning for support/non-support as well as any open discussion points you would like addressed should the document be adopted into the working group. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > -- Andrea Mayer From nobody Wed Oct 13 00:37:11 2021 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 E54093A096E; Tue, 12 Oct 2021 18:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.837 X-Spam-Level: X-Spam-Status: No, score=-1.837 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 mIMKjEZL7QF3; Tue, 12 Oct 2021 18:45:32 -0700 (PDT) Received: from mail-yb1-xb41.google.com (mail-yb1-xb41.google.com [IPv6:2607:f8b0:4864:20::b41]) (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 0F0583A095D; Tue, 12 Oct 2021 18:45:32 -0700 (PDT) Received: by mail-yb1-xb41.google.com with SMTP id s4so2566884ybs.8; Tue, 12 Oct 2021 18:45:31 -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=rwghgcE7UdCDujHvlMXyQZsl0Kl3YlYvAifm9cd9GRI=; b=Mj9XKQDNd3ylWDLfSW5dlZ8853dt4goDntrDkyKyPY+S4twbKdKB9YaLKITy6JuRaP H4HJ7BAGi69K2sf0tHU0ctc9g7VeJG/zb099/NltwAP5O3WtoE9xRol4m3wSa1cyn1O7 NxfC7iER/GTT6PZHe4QYcsMZM3VarsX04Q43pkXqnQnONgUE5ftJHyVhJEoK4D41+yDv a990yon+n69Nf9Pp0NaAfSvlvOTrpshlIkvccYM8BS9OwvKfP6OS89p3RgWQ0/5Zoruc W/F3bb6FV7KCg5zAhq5k6fxlgPfnZUqzthVZpppOrQz/uN8RE8zScpbW5OrWGtN1szEj bwYg== 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=rwghgcE7UdCDujHvlMXyQZsl0Kl3YlYvAifm9cd9GRI=; b=bVa88x5oi5zeFBrvughGO7TAQAjY17VdSnGo/h+0vq18ZD0r/COvrItqdTrVsP5rnu lbsplIAeA8BjAsvLTK+IpPLb2XMnifE5LrH7luysVsmFdlpo1xc+vttBGd7IfciAOaRm jZBp4rF4W2PmPJPl3x5upnHnM4iibvybe5WSBkrU7f6esCfsiCzHHZ/Hz+DkkPQGWRIO yM6YhBdwobNJzghtA1dcIz7nq90edlbweqwfRbNTp/cxLrWWd5bHPSIfia+Irjlyx0VT m0ipIFkNPV3QbuPor+/aNVZtQkxrOj2fXgUZNW5KM2pjC0iOKCEj0mWJxBsupncvHD2Z uqNw== X-Gm-Message-State: AOAM531k2xpBQppLqygSNx6jwp9IBuNLaD1KVokAfeyTux/kgoLMH9No Y2vrWV/9uORXewPFHCbidx30nwDlZvbZbLdfLBHe1gH6s0k= X-Google-Smtp-Source: ABdhPJxuyZ2vMlkahIk3F3zdd2QGw0qDGtYB13qUwJQje1L0O91BKoVLXfnsrlu0YSgklD2zAbSJU2mXENeZgh9YhBk= X-Received: by 2002:a25:81d1:: with SMTP id n17mr7253772ybm.425.1634089530763; Tue, 12 Oct 2021 18:45:30 -0700 (PDT) MIME-Version: 1.0 From: ximin dong Date: Wed, 13 Oct 2021 09:45:19 +0800 Message-ID: To: SPRING WG , James Guichard Cc: spring-chairs@ietf.org Content-Type: multipart/alternative; boundary="000000000000032df005ce321e35" Archived-At: X-Mailman-Approved-At: Wed, 13 Oct 2021 00:36:56 -0700 Subject: [spring] =?utf-8?q?Re=EF=BC=9A_WG_Adoption_call_for_draft-filsfi?= =?utf-8?q?lscheng-spring-srv6-srh-compression?= 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, 13 Oct 2021 01:45:38 -0000 --000000000000032df005ce321e35 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi WG=EF=BC=8C After many interop and efficiency tests in our lab, I have to say that CSID recommended by draft-filsfilscheng-spring-srv6-srh-compressio= n/ is a good solution for the deployment of SRv6. Our judgements came frome the following aspects: - Under the circumstances of large deployment, even with heavy load in MAN, the mentioned solution, CSID, proved to be working at high efficiency which is actually quite beyond our expectations; - From the perspective of packet forwarding, it is coherent with data plane objectives and could interop well with other IPv6 deployments; - CSID can meets all requirements derived from SRv6 header compression. Based on those facts, I really appreciate that the recommended CSID should be used as the candidate standard for SRv6 header compression, and we are looking forward to the early consent of it as a standard=EF=BC=8Cthus the = adoption as a WG document should be done ASAP. Best Regards=EF=BC=8C Calvin Dong =E5=9C=A8 2021=E5=B9=B410=E6=9C=881=E6=97=A5 22:04=EF=BC=8CJames Guichard =E5=86=99=E9=81=93=EF=BC=9A Dear WG: The chairs would like to express their appreciation for all the responses received to our emails with reference to how the working group wishes to move forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is part of what this email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv6 Endpoint behaviors. 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change as= it goes through review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be addressed BEFORE said document is allowed to progress from the working group to publication. A list of these discussion points will be document= ed in the WG document and maintained by the document editor in conjunction with the chairs. 4. If this document is adopted by the working group, the chairs specify as part of the adoption call that the following text describing an open issue be added to the document in the above-described open issues sectio= n: - "Given that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this is valid and coherent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or not this WG adoption. Please express clearly your reasoning for support/non-support as well as any open discussion points you would like addressed should the document be adopted into the working group. Thanks! Jim, Bruno & Joel ------------------------------ =E8=91=A3=E5=96=9C=E6=98=8E =E7=83=BD=E7=81=AB=E9=80=9A=E4=BF=A1=E7=A7=91=E6=8A=80=E8=82=A1=E4=BB=BD=E6= =9C=89=E9=99=90=E5=85=AC=E5=8F=B8 =E7=BD=91=E7=BB=9C=E4=BA=A7=E5=87=BA=E7= =BA=BF =E9=A2=84=E7=A0=94=E9=83=A8 =E6=B9=96=E5=8C=97=E7=9C=81=E6=AD=A6=E6=B1=89=E5=B8=82=E4=B8=9C=E6=B9=96=E6= =96=B0=E6=8A=80=E6=9C=AF=E5=BC=80=E5=8F=91=E5=8C=BA=E9=AB=98=E6=96=B0=E5=9B= =9B=E8=B7=AF6=E5=8F=B7 =E6=89=8B=E6=9C=BA=EF=BC=9A+86-13871232900 E-mail=EF=BC=9A dxm@fiberhome.com http://www.fiberhome.com/ ------------------------------------- Calvin Dong Network Business Unit=EF=BC=8CFiberhome Telecommunication Technologies Co.,= LTD. Addr: No.6, Gaoxinsilu, East Lake High-tech Development Zone, Wuhan, Hubei Mobile: +86-13871232900 E-mail=EF=BC=9Adxm@fiberhome.com http://www.fiberhome.com/ --000000000000032df005ce321e35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable     --000000000000032df005ce321e35-- From reshma.sudarshan@intel.com Tue Oct 12 22:53:07 2021 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 100173A13A6; Tue, 12 Oct 2021 22:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=intel.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 hoZ5RpHHe-xh; Tue, 12 Oct 2021 22:52:55 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (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 3A1673A13A2; Tue, 12 Oct 2021 22:52:50 -0700 (PDT) X-IronPort-AV: E=McAfee;i="6200,9189,10135"; a="224793250" X-IronPort-AV: E=Sophos;i="5.85,369,1624345200"; d="scan'208,217";a="224793250" Received: from orsmga006.jf.intel.com ([10.7.209.51]) by fmsmga102.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Oct 2021 22:52:49 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.85,369,1624345200"; d="scan'208,217";a="441517670" Received: from fmsmsx605.amr.corp.intel.com ([10.18.126.85]) by orsmga006.jf.intel.com with ESMTP; 12 Oct 2021 22:52:48 -0700 Received: from fmsmsx610.amr.corp.intel.com (10.18.126.90) by fmsmsx605.amr.corp.intel.com (10.18.126.85) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Tue, 12 Oct 2021 22:52:48 -0700 Received: from fmsmsx611.amr.corp.intel.com (10.18.126.91) by fmsmsx610.amr.corp.intel.com (10.18.126.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12; Tue, 12 Oct 2021 22:52:47 -0700 Received: from fmsedg601.ED.cps.intel.com (10.1.192.135) by fmsmsx611.amr.corp.intel.com (10.18.126.91) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.12 via Frontend Transport; Tue, 12 Oct 2021 22:52:47 -0700 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (104.47.57.177) by edgegateway.intel.com (192.55.55.70) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2242.12; Tue, 12 Oct 2021 22:52:47 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=epcpAFyBsNxr/UyZpz1wUq5BkKi45fBViJMfYD06Kk0O4wkrXWEl/hR+Xis+DgFWl9KemTXzx3Oyl1TtUozXM/CKuCdwvj67brrsfx3/0vjJdHKQEypi8oAeD5bcjWk+fh5RDn6mMRjqW4gPn+ugCM14NmOKv1RQ3+KsIBaXXVvFEqm9JLdDixV0WBahGeoLY3uPvolLna/qjRz9+YJ9OcSluQv2fJo93ob9Xg/RUNlZ/lBFriuaTlTktXUf6x5jeHY2NbfKpRukl9+R6S9bvuzaPhiJQeUt6jF5ME3KyDrXxJBOYpkY59nY06H6L4KOEzDQJijcDXrx8Rp1cU2qTA== 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=x/Azng3NJ6DKGaSXSEkzHIYZDCnxoPUtCOv6GpUPZ2o=; b=k1h0Zqu3vPK71KQfZ/7d5xJZHuN+mfFPqr7kVlRQgSvInY3+xFN7jk27WgWq1x+dM94Mesyv2Od/6yMu9sd9g1fznUnrzv+kjDuZakFIVXdcyeDDobdbbd/F3P8VVAPbbXqaZByTx4U/moEctMds4NJrrplD1e8DrJeemz2WanPo6Q8oZSDHspbizaeK10qEAsDg9gQ4I66FRySCalaXuoAKN7c0WiTxqp04BDnLE/TICWH7CA8PHmxvf6xTFPuOCK9gq6amwtLwDJU6TuEgHHJwZzhB1Twq5wW5cp8SLKenABbPb58ce3ovNAYqcpwXQOSwZ3gBjU5rBtEiqjgSVQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=x/Azng3NJ6DKGaSXSEkzHIYZDCnxoPUtCOv6GpUPZ2o=; b=lfbDdUVIZMcpJ3/ZfCoOzylj6j2r4dRbciYII/SoRmgolUd4K6DQLig/C1eg7g4vyfDjpZS+gYn94DfJFIlC2MUyleNbAJqBGXWAE7DSDfS51tWI3iidyaqoIwN07NDk1f0Kwhy9Axa3UW1fljT5yoB11Mx+2SHPpPFCx9MAqyI= Received: from SA2PR11MB5209.namprd11.prod.outlook.com (2603:10b6:806:110::11) by SA2PR11MB5163.namprd11.prod.outlook.com (2603:10b6:806:113::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.20; Wed, 13 Oct 2021 05:52:46 +0000 Received: from SA2PR11MB5209.namprd11.prod.outlook.com ([fe80::7ca5:386f:d7bb:d07e]) by SA2PR11MB5209.namprd11.prod.outlook.com ([fe80::7ca5:386f:d7bb:d07e%7]) with mapi id 15.20.4587.026; Wed, 13 Oct 2021 05:52:46 +0000 From: "Sudarshan, Reshma" To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" , "Sudarshan, Reshma" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQJJj5rg Date: Wed, 13 Oct 2021 05:52:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.200.16 dlp-reaction: no-action authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=intel.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a786e0fc-46a5-4297-566a-08d98e0daea5 x-ms-traffictypediagnostic: SA2PR11MB5163: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Xe/wE6ykuOEuD7dZLg+lwfjvkG/sKAsYpiuAO5K4TzBdkXHdaMe5NIAqpNNOX17E5wt+Qb+3iUbsC1PyUfenOTAhhoEYRyhgDlv4hRNR9E8hT7dE1Qnu2VDpbzGxXJL2xDAtpvBC8UqXEP3etHs/RCJFUCHSegD8P/Kv6w9MydP/6xyY8o34ndrafbIZNh91xN1oVtQyj4niQuXesoW+Ybc9i58QAEwTCsmTTfBh03Zdjpi7j1qWKdKg1UXqUq1qr0XYKV2WeHkEbqp20ZgGHu4rHGWqMe2SQ6GkrJ2BSInm+sBB6ru7aIgdXIlC8829PWEB6LLi8HFVIIrLX0/aA4P4bPgd9CXqC/rL8HUFL6yB0d/WYmW+HRc1++FpWb3D7TF72JlvMpL7wQtDHzXuj6Apmff7L05xalmeJvkwq1hiBsJe4JlnpLWcXMRD4TQ/g6xW72NGTq+hHrT4ywWSAN3xDD9wFunn6KptzQpcQfWIBRA42IDJ5I/sua/+K/nkbl9ApYRlhkRA/I1t0SCAxdqTNaZDJWKYNZ+DsLnb1bCTdTtabjwJXt3J3BN51TGIDpXNZj3Hyi1n7ksuaf2Pwv0xKuwKgSIHAMUosuc0vhevd4l3qkKFjQR0qvvSrzkPBIrit8LpOU7Lj1hw0KUtlg2A2fPHnEq/8e8PUxmH70alhj77Ld3Hp3ZctUoEunbsvCQbATfR3cGTQ67aYTFUGbxxs/9lJ7v9fFhhsf4IAMYjQTr/cXZQ8N91GbSKmPe67srm2gJ1MNvCPPSgCuCkRS9gZuV1q3eVwOBmMOV17xM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR11MB5209.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(55016002)(52536014)(71200400001)(316002)(8676002)(83380400001)(166002)(186003)(966005)(7696005)(8936002)(82960400001)(2906002)(6506007)(107886003)(38100700002)(53546011)(66556008)(33656002)(66476007)(4326008)(26005)(5660300002)(86362001)(64756008)(122000001)(9686003)(38070700005)(508600001)(66446008)(110136005)(66946007)(76116006)(54906003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?4nF7HAMRtwk+NMy1Ob9G8zElmnrBpFszbbkkM8HeLzGkEWTTQaI8BJdBN2C7?= =?us-ascii?Q?Z5iWcx7m8Zg1NjRm/FdA1j0R/abEuxo+RZUcCYMTDRbIGbReC8e2PPW1Hruq?= =?us-ascii?Q?ShPFDGjoc2QD+3o7hLg0Ui7Jb8MC1n8Au3qRrivwmBFr8KnSvsqrFQcs4OJZ?= =?us-ascii?Q?ECOoWr5qoYUTCx90K/2tqo/41aCrsdUOeESh1woSMugQtfNd6ShnFktTWcIA?= =?us-ascii?Q?sliMxAGuKKdJrNF0UJYJb3MynOjvG48Owo6hyBhcP9haThfkc3jSVwKn1W61?= =?us-ascii?Q?h9nWg6/gxrTg9dOm0aUS8NB6cqjK7qWZu/h3sGnhDuX2OSCv9nOYVwsNxHDt?= =?us-ascii?Q?n2Fo0WDh8YW334yzkvMk8UfBDdS5X5qNKBgsSRHd7UrKYd6aH1W3pQjgYmaq?= =?us-ascii?Q?+tyw2UuDT+p6AKZ8I2fdXa1I4XFU+7aVD59bs8nl+YgRpg5V6ohJ1ijYWOFS?= =?us-ascii?Q?/GCpgBNfm6e8tEP0Tiuf8T+0wxhKA77yfUFapgNk43MVL9AarTihtN7/lMvY?= =?us-ascii?Q?S2mkyFeKP2zPK8vXcD7bfPfIvmKsgWrOGJm9Dpz4AHXRRYE6ZSNo01BTyBf2?= =?us-ascii?Q?Ny5RM29iR8FVNlUf07ake/ugs7JI32511xW+obLpjRLBVn/QGJxeg2dreDog?= =?us-ascii?Q?2eWF09kwGPqsWl08/uyLORKMdOAjl6KRbYLw/VIZyce2HvRLD08U5HyRxkcB?= =?us-ascii?Q?i7VaK9ZoodtPKUvCgEobuNXaG7bHxEo9tZIbW58+v3krTUgmjVqxZjSLrjbv?= =?us-ascii?Q?eQHLtmqQw5GJU6rGxpHSzfubJDrajmm4hZ2w0T9Fe/4F3he7gtCosqN90G0R?= =?us-ascii?Q?AuCoGussQb7XrDz6RaTyyqjJcjAcRi4kKhW6QiIdRLLC9WuR3YNBAY+RUkXa?= =?us-ascii?Q?9rUPboa4IoWnAiNiwh5AepYUUlysDg05c7Yq58Svm7Z34pajmytTaJ6jxw5Z?= =?us-ascii?Q?rAW72nhgOxQcNmR1gzBlZTPW4GFaLYRTsrzyigUoPbYyByoVjEf/OfnMB0t5?= =?us-ascii?Q?iTaI0De33CKwcpvCU3pE3MITmltDaXG9YL+T+V04nppPZC25Uqr2bW+1Zltz?= =?us-ascii?Q?qRMUaYVFRHZCuvm8tJvs8RU/IyXGXg/0vAsN1fMu8KUSDt7PEYr2Ukd5HJSb?= =?us-ascii?Q?mO+TzCPI//xykJVQnRRA3KGcr/qKrn1tYHi6RxTiYtxNtxEXSe9DoTvppGqc?= =?us-ascii?Q?JbwstFzrbSLJ+gtydWzTjVmiO9Ituv8hVW6jFViDohHg20WK61yl8S0aW3+A?= =?us-ascii?Q?LTQlO0yrO9jsUNANhUTzHaEmDlk5pogIyy7FQUze6ve451zKs52Mq00huCZK?= =?us-ascii?Q?kwyHIqsHeYmtVUhzZWKeepkO?= Content-Type: multipart/alternative; boundary="_000_SA2PR11MB5209BB8BFB4648E40ACB5CBE84B79SA2PR11MB5209namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR11MB5209.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a786e0fc-46a5-4297-566a-08d98e0daea5 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2021 05:52:46.4360 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 46c98d88-e344-4ed4-8496-4ed7712e255d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LyHeIbYbfz9sg7B3IIjGaMq0w2Pb6UF6sme04fHrDrfmc7jjM1e9cSdvbUE+Kij8DjHHhpXeUq1sdw7DuX2XisCWk61HpfZzdQvoJ9ISWhI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR11MB5163 X-OriginatorOrg: intel.com Archived-At: X-Mailman-Approved-At: Wed, 13 Oct 2021 00:36:55 -0700 Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 13 Oct 2021 06:49:53 -0000 --_000_SA2PR11MB5209BB8BFB4648E40ACB5CBE84B79SA2PR11MB5209namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Spring WG, >From Intel, we are currently in the process of adding SRv6 feature in the o= pen source NOS - SONiC. In our discussions with our customers about SRv6 H.encaps.red, END.X, END.D= T46 etc functions that we are implementing in SONiC, we also hear about the= importance of NEXT and REPLACE flavors in their deployments. For that reas= on we have implemented CSID in our platform as well as added NEXT in SAI, = and will continue to implement this in SONiC in the future releases. Lookin= g at the deployment benefits, I do support the WG adoption of this draft. Best Regards, Reshma Sudarshan Director of Applications Engineering, ENA | CG | NEX Intel Corporation From: spring On Behalf Of James Guichard Sent: Friday, October 1, 2021 7:05 AM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_SA2PR11MB5209BB8BFB4648E40ACB5CBE84B79SA2PR11MB5209namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hello Spring WG,

     

    From Intel, we are currently in the process of addin= g SRv6 feature in the open source NOS – SONiC.

    In our discussions with our customers about SRv6 H.e= ncaps.red, END.X, END.DT46 etc functions that we are implementing in SONiC,= we also hear about the importance of NEXT and REPLACE flavors in their dep= loyments. For that reason we have implemented  CSID in our platform as well as added NEXT in SAI, and w= ill continue to implement this in SONiC in the future releases. Looking at = the deployment benefits, I do support the WG adoption of this draft.

     

    Best Regards,

     

    Reshma Sudarshan

     

    Director of Applications Engineering, ENA |&nb= sp;CG | NEX

    Intel Corporation  <= /p>

     

    From: spring <spring-bounces@ietf.org> = On Behalf Of James Guichard
    Sent: Friday, October 1, 2021 7:05 AM
    To: SPRING WG <spring@ietf.org>
    Cc: spring-chairs@ietf.org
    Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

     

    Dear WG:

     

    The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

     

    The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

     

    Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

     

    1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors.
    2. The document is a “living” document; it m= ay change as it goes through review and analysis by the SPRING working grou= p.
    3. All open discussion points raised on our mailing list= MUST be addressed BEFORE said document is allowed to progress from the wor= king group to publication. A list of these discussion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
    4. If this document is adopted by the working group, the= chairs specify as part of the adoption call that the following text descri= bing an open issue be added to the document in the above-described open issues section:
      • "Given th= at the working group has said that it wants to standardize one data plane s= olution, and given that the document contains multiple SRv6 EndPoint behavi= ors that some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

     

    Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    --_000_SA2PR11MB5209BB8BFB4648E40ACB5CBE84B79SA2PR11MB5209namp_-- From nobody Wed Oct 13 00:37:44 2021 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 2D6F23A15F0; Wed, 13 Oct 2021 00:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, 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 9WRHEZISxuls; Wed, 13 Oct 2021 00:37:28 -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 408B03A1527; Wed, 13 Oct 2021 00:37:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4HTkrT5gRvz1pC97; Wed, 13 Oct 2021 00:37:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1634110633; bh=10dlyxObm4fBBp47TviBv6KMHL5DCsNqF9P2QI9KMwA=; h=Date:Subject:From:To:Cc:References:In-Reply-To:From; b=qPxGUvvut2yRfJVQ0a+atfY6M2TvRIRnrj8FvawwgsH9LqohDUnQK3Lm1+nOS8uAQ kRrWQUDXHd8xxHtLRq07l7vOf41+8m/T2iiktDkibPHwLNL2hF3lOe+0AB2xQpmXZg dhOkUNMpFG+9GS+LuxVyObllJBXXY7mVePfQ/y30= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.22.111] (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 mailb2.tigertech.net (Postfix) with ESMTPSA id 4HTkrS6BXqz1pC93; Wed, 13 Oct 2021 00:37:12 -0700 (PDT) Message-ID: <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> Date: Wed, 13 Oct 2021 03:37:11 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Content-Language: en-US From: "Joel M. Halpern" To: "ipv6@ietf.org" Cc: "spring@ietf.org" , Martin Vigoureux , "John G. Scudder" , Alvaro Retana References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> In-Reply-To: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 13 Oct 2021 07:37:42 -0000 There is a typo in the below which if not understood as a typo would be quite confusing. I wrote that I raised the issue with "with the Internet ADs and SPRING chairs". That should have read "with the Internet ADs and 6man chairs". The SPRING co-chairs are recused, and the charter requirement leads to the 6man chairs. Which is who I talked to. Also, I am sending a courtesy copy to the routing ADs, which I should have done originally. Thank you and enjoy. Yours, Joel On 10/12/2021 11:52 PM, Joel M. Halpern wrote: > The SPRING working group is in the midst of an adoption call on > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/. > > > The SPRING charter has text that is explicit that modifications to data > planes and architectures standardized by other working groups may not be > modified in SPRING unless the chairs and ADs responsible for that data > plane and / or architecture agree. > > To complete the context, as my SPRING co-chairs are co-authors on the > document in question, they have recused themselves from decisional > activities regarding the document.  Therefore, this message is coming > just from my as the responsible SPRING co-chair managing this adoption > call. > > As you have seen, multiple questions have been raised about the > relationship of the document to the IPv6 defined data plane and > architecture (particularly RFC 4291 and 8200). In particular the > questions seem to revolve around what the document describes as the > NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6 > standards.  (For those seeking more context without reading the full > document, a paraphrase and simplification of the NEXT-C_SID flavor is > provided as a postscript.) > > I raised the question of concurrence as required by the SPRING charter > with the Internet ADs and SPRING chairs.  They quite reasonably asked me > to write a note to 6man explaining the concerns as clearly as a can, so > that they can then determine how to proceed. > > The questions that prompted my inquiry are: > > 1) Does the placement of a list of sids in the IPv6 DA field change the > IPv6 architectural description of that field. > 2) Does the operation of shifting information around in the IPv6 > destination address field represent a modification or extension of the > IPv6 data plane. > > On a related note, the document in question also defines two other > flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.  The > NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID > flavor operation, so seems to be affected by the same question. > > From my own reading, it appears that the REPLACE-C-SID flavor does not > raise issues requiring 6man leadership concurrence. > > Yours, > Joel M. Halpern for the SPRING working group > > > PS: > Clearly, understanding the question requires some understanding of what > the NEXT-C_SID flavor does.   This explanation is a simplification for > length and context.  Really, the best place to understand it is the > draft.  However, to give you enough information to let you decide > whether you care, I will try to provide a fair summary.  My apologies in > advance to the authors for necessary liberties for length.  Also, > discussion of the draft contents (as distinct from the interaction with > the IPv6 data plane and architecture) belongs on the SPRING list, and > should not clutter up 6man. > > SIDs are the identifiers used in segment routing. > In SRv6, as document in the current RFCs, these are 128 bits.   As > defined in the relevant RFCs, SIDs which identify endpoints to which > packets are directed are identified by endpoint SIDs.  These can have > behaviors (decapsulate and forward is one example).  They can have > flavors such as where the SRH is removed. > > The topic under discussion is means to compress these SIDs in the > packets on the wire.  The document under discussion provides three > flavors of compression. > > The fundamental mechanism of the draft is to use a single SRH entry as a > container for multiple SIDs.  In the NEXT-C_SID mechanism, when it is > first encountered the entire container is copied into the desination > address of the IPv6 packet.  The container has a common routing prefix > used for all the NEXT-C-SID SIDs.  It is followed by a sequence of > compressed SIDs of a configured length.  One could configure 16, 24, or > 32 bits.  Or whatever length.  The routing advertisements are arranged > so that the IPv6 packet is directed to the node represented by the first > compressed SID on the basis of longest prefix match matching the > combination of the common routing prefix and that compressed SID. > > When the packet arrives at that node, it looks up the configured > portion, the compressed SID, and determines the behavior and flavor.  In > the case of the NEXT-C-SID flavor, the resulting operation is to shift > the entire remaining contents of the IPv6 address (the bits past the > first compressed sid) so as to over-write the first compressed SID.  0 > bits are shifted into the low order positions.  If the result is a > non-zero new first compressed SID, then the packets is forwarded and the > process repeats.  When all that is left are 0s, if there is an SRH, it > is consulted to find the next SRH entry, which is, per normal SRv6 > processing, put into the IPv6 DA. > Note that in the common case where the SIDS needed all fit in to a > single container, the analysis also assumes the use of the reduced > encapsulation options which omits the SRH that is not needed as it would > have no entries.  This the packet contains a normal IPv6 header, with a > sequence of compressed SIDs (what one might or might not call a source > route) in the IPv6 destination address field. > > PPS: If the authors of the NEXT-C-SID flavor feel I have mis-represented > the work, please, send clarifications or corrections.   Again, the best > source of information is the draft itself.  I was asked to provide extra > context in this email. From julian.klaiber@ost.ch Wed Oct 13 00:56:41 2021 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 978FF3A1502; Wed, 13 Oct 2021 00:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ost.ch 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 zJaI716lUkLB; Wed, 13 Oct 2021 00:56:36 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2049.outbound.protection.outlook.com [40.107.22.49]) (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 0254C3A14C4; Wed, 13 Oct 2021 00:56:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TAf1oUV4XZu97GJ0A+kFN2NzKaGIM75LonX8nTUMofHu/R/inX3+8jdx5ljn/4bkTeR0TyrMA/2rQ82KboM/9+SemCfyO8Rg7xi+5IdoykKtm7VZgdicfC9BiyQtk9QbFN7s4dFUoxifalzbcLXnYxnTD1Vc6b0qmPCNnYFohxB6X2vwYYk+Qg/2TaBrnEY/q98yhUSBh5ayFzkUEhk6R5sC5C60fWavWz3itUH4lyKlTvJskFdOhfqFrUYf8A0bHL3j3dqQC97BXd8CXu384y3FGHtpY82hLIDz5l7H8rQUggWXNcGyA7Rfjh28s1O23Jq4NOX8UHPPHbiQ3RvlwA== 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=bLx2nlKW5JFnPFf05tvSBs2anORmHG9smzgxpugMlSw=; b=dMCoJKMH64D3qbAMs1E0ekeGh5QtOJ3MKwIj+HyNhoMmQEC0mpaZd9jpoECJdqoG0NFYlx68POTViHWcgKTUDqURJhnz7lrCbDxg92KZoe3o1RoH0vC6BokGLZ34325i2PahWtVekd+VuyztJygWccdEEAn/C3wY+sy8J8I3hoh71ZZx6ydiLnvOkia1PsxjjVQlk/f0AQ7XxRfe0Je+PAsQhQgXqZShl4HQ8eQkw3B7ryQVJqqt8sNMRZ0YYJrvkgDamt2nhUkJPKmvOOl/dimfNJHIbqEzHJ92R9dHEXC8uXHzJzWCkPV/vZF2YbUZ/TIhqT8NepFpjHyF5xKU9g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ost.ch; dmarc=pass action=none header.from=ost.ch; dkim=pass header.d=ost.ch; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ost.ch; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bLx2nlKW5JFnPFf05tvSBs2anORmHG9smzgxpugMlSw=; b=O91/c/uL5jsZVUkLgsU7Or3I8wMU8Qd68GzfrNmNWUHg9pFvi5IOG3cra3dw8VOqQJGWoJMevOlr7KItUo85pJlbFvFsMLiIvnZgnAKFIy39QUaX4u5S58tr1JGxCmmh7dHlbeJ5NRg6h3y4I85a7LlODUlZmj9+Ux9s4yt/UQg= Received: from AS8PR09MB5206.eurprd09.prod.outlook.com (2603:10a6:20b:395::5) by AM7PR09MB3751.eurprd09.prod.outlook.com (2603:10a6:20b:10f::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.15; Wed, 13 Oct 2021 07:56:24 +0000 Received: from AS8PR09MB5206.eurprd09.prod.outlook.com ([fe80::d08:8bce:1efa:ef88]) by AS8PR09MB5206.eurprd09.prod.outlook.com ([fe80::d08:8bce:1efa:ef88%3]) with mapi id 15.20.4587.026; Wed, 13 Oct 2021 07:56:24 +0000 From: Julian Klaiber To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQJO8Ga9 Date: Wed, 13 Oct 2021 07:56:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-CH, de-CH, en-US Content-Language: aa X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 85a3c025-ed6b-6687-f41a-150cb342355c authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=ost.ch; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b7b7ac1c-5ffd-4ed3-3272-08d98e1ef3d7 x-ms-traffictypediagnostic: AM7PR09MB3751: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VEemOx2q5Q+ybKbO4cgJozz/YMzm5GDuyzDlDlZDY7hkxzMFcgX+MFAcd4O3t8TJLzVf8IZrwTjdAi7l0ASZAGeXd199jJBXBtWd3+lQVRIEd767eDZEt65RgVQQIctK/qpQFBZxZZ8fT5hfCjcWbcOTVbcdE6HtuCYCgoEuvig3y1/ysK8vlcr+/4rsrfVicDUu/TeK5+tEbWnE+/CqpqcUQJHHe2/s+6jVDmC/FqANvHaoUBIp2sEKyGyk+mbcKtyWgjzXRAVUNW79M8FnD/TsSwU5b7bKmAuZi6KAN9CTKr4AdJ+hgIs5fDIysJFw0Vql3TH5npDnmcn1egd33zyefYA5lQIWE/FboKsbhnGqab2q58rOcaN8TEzlEv15y6S3ZWpOAJEBUciwF4qQ9EWk4AfGezoEsRiLJPlllAD9cDRkpmv/2uNQ10BwjziVWPfaeIKMHfmTcTLRARH0we/6JRlf/HS1CqqGZRw98Mo2MsIhaKUpd0icmdGXlFsIEylyRU0u3lVX+PY7Pxwn3DXANrTmlmesBuGpenBal4Q+PzIomsVoIUnJZ0TGzmqxviCaH+mqDtV5VfIoOyN4WvMP+OsYasX8VurwqAVUqw49woQYDIDv1nJUrJXUopvUeXp7wIIvrQufZBlWx8mnEXc0aB08m/CD28YF0LWx7MenotZdmDnN7uwbd3ho7EJ0lQKPkxs7fHXhkpKgrOtsqNXl1UKDdHv/FWKljzRVEixvjGHRlqAM1NC54ey6K/i4PQTg1fNov6IhJokkVtXfzDFO+3MbthzmTfHFvtjRFZ0= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR09MB5206.eurprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(8676002)(64756008)(33656002)(38100700002)(122000001)(166002)(508600001)(76116006)(966005)(91956017)(66476007)(66946007)(66556008)(44832011)(53546011)(66446008)(2906002)(38070700005)(6506007)(86362001)(9686003)(8936002)(5660300002)(19627405001)(786003)(71200400001)(52536014)(316002)(55016002)(7696005)(83380400001)(4326008)(186003)(110136005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?+cQZXy3o5FHExPjv5iyRaoVMjXbSKMVGUMcf4VE7PY3YjdHqmbGFTqZJ?= =?Windows-1252?Q?XVg+87wiImcn4LEmqU8DK9JAYqDUZ+MAYUyC1EWEJHH0i9QaksPTxFad?= =?Windows-1252?Q?8rcolEmap0mjBHxPQ43bds/1AHjFXlID0H3ZBTBykuLLdu6lAUEN3tJ+?= =?Windows-1252?Q?oNRlgjzAHmSQFfZcjgIv0wl/g3TjrCVXqaFuYrLwgVEUHEDwdRMa5h2F?= =?Windows-1252?Q?ZPzf869CPqRMKgMfuebXokfVQ9bYgMdpTN3bfvJnGlu5zMoBOdTaLd2E?= =?Windows-1252?Q?j2M0L4wUc9p+nyTkoEoklUcMXd24qqywkTxKnVIdCYEEBwCKOnpyWU3W?= =?Windows-1252?Q?GSc7zQ5SJiDsPI3VIV+9jcsK/Lq92eAjcN9y9WHk1rGP8prysTlyAZtT?= =?Windows-1252?Q?I96Bnw/oI9Jgh9O4kdH9LlVLS/dwvNX6+ajZ0gYMBASi0qsnqw34PQnP?= =?Windows-1252?Q?CoQQqZZHAatkZJcXRXNI0Vl1EtP3EcN2B1gQ1TBcLJ5uYzIwBrj1UhJq?= =?Windows-1252?Q?m6L5YCSFyx6JS9ly6g/fNZaZxGzu600YVlNCjzYZEwmZswvjmAowA54+?= =?Windows-1252?Q?kV0oQr9rS3C/OpnDjAPPHxN+KDBs/1arC3HdnhdgNiQSDyPgMo9Qqrsf?= =?Windows-1252?Q?LQxmmCdaiECXQs8WcUFce8gkoBSHYvYEAySkZJGsagEkichKW0OIX6mb?= =?Windows-1252?Q?KcO2qRfG8/1jx/MHuj9vYiGRDh8OKTZqQfgYRRj0bHiqrK0gOHWSxZQq?= =?Windows-1252?Q?gOQdkZCOxJ9KvqKgLeg+na5FwB3G/1YJ2Wl6CNVflmbKLxe6iZNXWbLI?= =?Windows-1252?Q?mNbedPUBucH/zcgppDOXdNlsGN+EszxBvAw6zMi9KWx/NE0eeciphFin?= =?Windows-1252?Q?QdDXyeUq3Fxc7y0HwoNcLN9xPQCJe8KthSmyeDIYaSF5r5PFNbvC2sEm?= =?Windows-1252?Q?pNWpIlW90QiCqgKGe4g2UY1OFpCkMEiOary7QH2rZVTn84yyMJij1wzr?= =?Windows-1252?Q?DODaDcuuNRqJ44U2beRKwUg/UPETawXd6f/BgU/r2dbpx41NDZVNs0qQ?= =?Windows-1252?Q?qOc3V6054bnxdZmNECCaJEsXEIzQL4HwouJT4bsbS6eW9LbDWiYEvED/?= =?Windows-1252?Q?QN77QmVpZVijOSVmScQBfqHszGG+ETXbtXcDH9k2UjCutb14Q34jEaCI?= =?Windows-1252?Q?xakhjp5td0cWKQuIHcTIH5bJlYIxOwF3mos6GijFX50IDbYgji7WPARs?= =?Windows-1252?Q?a2QWjQhWp/QptYDz3N7iP7ApVvVupac8LvpMit1ZwkTxv1r+fpc/oxv1?= =?Windows-1252?Q?4g4OkY8WcMW3DjPx8AKDZoKDIgm8b4KeBHI9+yePCejjotSzLtemT9b3?= =?Windows-1252?Q?cHvtPO2dR14oENbAqexYuWKJyim0pA5cRUWP2Q2c4s2MUcygwX4RFeva?= =?Windows-1252?Q?UlZWOY4b/N+1YeY4Nh+9+6yUeDqfDRWlEPOJubAI1AQ=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AS8PR09MB5206B7B8E1DB0A3A241CA097F6B79AS8PR09MB5206eurp_" MIME-Version: 1.0 X-OriginatorOrg: ost.ch X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR09MB5206.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b7b7ac1c-5ffd-4ed3-3272-08d98e1ef3d7 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2021 07:56:24.0188 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a6e70fa3-1c7a-4aa2-a25e-836eea52ca22 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 1l0WHna2me5RbZrOkKWKzwAibtnPsjUzz3J4SJrXqdqjkUeY42Qk1uh+d3c26B+Jh/8KrVBj1JGlbueqefVi4g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR09MB3751 Archived-At: X-Mailman-Approved-At: Wed, 13 Oct 2021 01:17:03 -0700 Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 13 Oct 2021 07:58:06 -0000 --_000_AS8PR09MB5206B7B8E1DB0A3A241CA097F6B79AS8PR09MB5206eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear WG I want to express support for the WG adoption of the draft https://datatrac= ker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ (CSID). In my research studies at the University of Applied Sciences, I have develo= ped a Segment Routing application capable of doing service chaining. The ap= plication uses the SRv6 encapsulation with the NEXT-C-SID flavor. The analysis of the DT shows that CSID is performing better than the other = options. Another crucial point is that CSID is based on the SRv6 data plane= , and CSID also enables different deployment use-cases by adding next and r= eplace flavors for these SIDs, like PSP, USP, and USD flavors defined in th= e RFC8986. I also want to thank the DT team for their hard work over the last months. Best Regards, Julian ________________________________ From: spring on behalf of James Guichard Sent: Friday, 1 October 2021 16:04 To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a =93living=94 document; it may change as it goes thr= ough review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_AS8PR09MB5206B7B8E1DB0A3A241CA097F6B79AS8PR09MB5206eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    Dear = WG


    I wan= t to express support for the WG adoption of the draft https://datatracker.ietf.org/doc/draft-filsfilscheng-s= pring-srv6-srh-compression/ (CSID).


    In my= research studies at the University of Applied Sciences, I have developed a= Segment Routing application capable of doing service chaining. The applica= tion uses the SRv6 encapsulation with the NEXT-C-SID flavor. 


    The a= nalysis of the DT shows that CSID is performing better than the other optio= ns. Another crucial point is that CSID is based on the SRv6 data plane, and= CSID also enables different deployment use-cases by adding next and replace flavors for these SIDs, like PSP, USP= , and USD flavors defined in the RFC8986.


    I als= o want to thank the DT team for their hard work over the last months. =  


    Best = Regards,

    Julia= n 



    From: spring <spring-bou= nces@ietf.org> on behalf of James Guichard <james.n.guichard@futurewe= i.com>
    Sent: Friday, 1 October 2021 16:04
    To: SPRING WG <spring@ietf.org>
    Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
    Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/
     

    Dear WG:

     

    The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression.

     

    The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

     

    Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

     

    1. The SPRING working group is adopting a document that has multiple SRv6 Endp= oint behaviors.
    2. The document is a =93living=94 document; it may change as it goes through r= eview and analysis by the SPRING working group.
    3. All open discussion points raised on our mailing list MUST be addressed BEF= ORE said document is allowed to progress from the working group to publicat= ion. A list of these discussion points will be documented in the WG documen= t and maintained by the document editor in conjunction with the chairs.
    4. If this document is adopted by the working group, the chairs specify as par= t of the adoption call that the following text describing an open issue be = added to the document in the above-described open issues section:
      • "Given that the working group has said that it wants to standardize on= e data plane solution, and given that the document contains multiple SRv6 E= ndPoint behaviors that some WG members have stated are multiple data plane = solutions, the working group will address whether this is valid and coherent with its one data plane solution object= ive.".

     

    Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    --_000_AS8PR09MB5206B7B8E1DB0A3A241CA097F6B79AS8PR09MB5206eurp_-- From severin.dellsperger@ost.ch Wed Oct 13 01:00:19 2021 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 8972E3A1504; Wed, 13 Oct 2021 01:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ost.ch 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 FiHaQGx-WHqn; Wed, 13 Oct 2021 01:00:13 -0700 (PDT) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2061b.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e1b::61b]) (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 756A43A1502; Wed, 13 Oct 2021 01:00:13 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=U7QqAXeVw7/w3lUFO0Q7VkvQd/l2vRS/YH5iWWBMuNAGqLlCbN5fZC4BZhjFSAqt23WmILSJEI/nRs2qJ3hEd97x9ZTtC0j/PE7NvNipB6CHuEP7QCv0YYrh2CsQLKwc+9wzc+FBY2spPqj+h8tZRsLh6suERV9sBisgbTvN3bGSSHza+WYztBFyRNiRp/pBYSYR+uli4Ic++QO1nwWO5eP51Uj95CyML0iVblUtbTEioy47s/Ijl0V06G8wx0wsgJmqQsiG5w4su6ORPqiQl0GYGiunW9qIPHYqtoEreyw+a1KxnVaMOl+tHVw2Q01d3mB4Ta6w7aJqMRBa6hBzAQ== 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=Pbk9Y/TpyWlzFCgpKssJKX6oQCyiy3SvEqgU4VMxXqY=; b=FfYSVSNFNduwe5RwCdBd0zIWD1Ul4H8dxk+pax+86cXa8DcSRZBefY8jYjJYz/uSnjAxK3DS0NWtCkbAhsMS2saB/WRXDd1ijLUpezoQuFT5liolgQUdeiCmASiLOojKWScqDDaa4zBZjOZGwWb9sgSIQHzTrcxBgICzee0qkx7kJFh8f5v+PLDU2giiDjOhRksuzb2zgGEWb9CNJhIxz/VxdU/Y0toVP0sdp+REAx2apKdvYM7NtJpkrs8aa63jGG2IOLnoomee/ZQr30tpMnFqhhl979r/q/ak1DzXbBUQsSf+VQWJgBaELbD31IB8Nu5W1YslGp2aHvjjgpfeMw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ost.ch; dmarc=pass action=none header.from=ost.ch; dkim=pass header.d=ost.ch; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ost.ch; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pbk9Y/TpyWlzFCgpKssJKX6oQCyiy3SvEqgU4VMxXqY=; b=Ud4EvbZqvj2NR0KoBFqNEuy3hBKyG/HLdq6lAaIkPvd0NM53phRPL8W8E7kBPPKUG5O/hX5IlYO9ZBhaAnMrHIe4TKW0ZBghGNO4qEby59gxZGMzfUcbCfn3DiEqI48XNGYrYtcVd9AbnOFBXwnIafMtwcsqL4hVcNZftAthyJI= Received: from VI1PR09MB2398.eurprd09.prod.outlook.com (2603:10a6:803:89::31) by VI1PR09MB2960.eurprd09.prod.outlook.com (2603:10a6:803:ed::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.19; Wed, 13 Oct 2021 07:59:58 +0000 Received: from VI1PR09MB2398.eurprd09.prod.outlook.com ([fe80::18ba:fc03:9510:5901]) by VI1PR09MB2398.eurprd09.prod.outlook.com ([fe80::18ba:fc03:9510:5901%7]) with mapi id 15.20.4608.016; Wed, 13 Oct 2021 07:59:58 +0000 From: Severin Dellsperger To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQJPDOPA Date: Wed, 13 Oct 2021 07:59:57 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 4b0a85f6-e505-d097-ad42-a1d019df5187 authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=ost.ch; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2dbee292-4163-4227-e4bf-08d98e1f7380 x-ms-traffictypediagnostic: VI1PR09MB2960: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wNkIraMk4aNkmhm5ZS9Xy7BH86MljGb4AWGhVItoSxyCdfd3NQO0b005wVM+4aDZE6bVI7vlcWjftgEch1UOAUBvoOIT28vix7LrVTWaGPf9FsF0lUwkpB4qovv2ZdEz81J8LBLceJRFcllgJsbX1umanIpTM/HH+RVViVMwjZvZEXVFQNOGhi/Eupoh8W7EiLOYwewCkYMDVija51rf7LiAMYqhODgHn3PDOund/aGtoyaXJFcURxqnLut+mUORVdHCme1nU2l+D9enloOm15DWQQPl4WW7m46q1kns5MF/AB6ZYdiOrgYeNwm/Do3JTFdYniu0mttFRHiId6j31CgfvrFzdC3MHACUjTrgkEVrXR8pvDvGZXD2Ds49l6vWQ/h6FyGTibbXvQXT078AX4/ofsiziBXhNMOHxXRQU43V1b0+nlpLjXuXW0kyZlRstnu3Nmfw5m0qPeGTYByVu4CX7BUMtPa/FHsneNoyfGS1QqLqcRbPXNhdbnzR8gjyAa7nWjWtUZMEv0Q0+uDc2Ci6o3UdUo53yr4M1/EaLFOq/B/yaNFa/6gqk/WuQcgUxW5lYW9Lzsb86pJxBu90L4OO+j8Ar9EhrIe4e4buT+8vW2/WVjxMd9iXg8ssNJbb0sAyaloF/KrjGb+kD6ddnQ+672C3XtiZLZ31kGoTXguzUgxvYt/oXlXgaHO+kuAFk838QC7uchjLAVXZoGBM3YLtf/sOPD8a5HV7J9xaOE4yOWDYb6Etqn9SciBoU8ZZpCQEli+nxu2wQ3QxTINi7etbaeEO89p7/HydBDtRFzc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR09MB2398.eurprd09.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66446008)(110136005)(66476007)(66556008)(64756008)(4326008)(71200400001)(83380400001)(966005)(66946007)(5660300002)(786003)(44832011)(508600001)(7696005)(8676002)(316002)(8936002)(52536014)(2906002)(6506007)(53546011)(76116006)(38100700002)(186003)(122000001)(38070700005)(166002)(55016002)(9686003)(19627405001)(33656002)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?c38adPiLgtPC0A4lXdMl+uq/nrbSfD5LbkVvwCuVqZxnHjjeC7aSC34Y?= =?Windows-1252?Q?A3BrEF+d3WKDLePoApSSfOgPWa7o9xBXabVllWd13xBG+qEjc4TcI9RM?= =?Windows-1252?Q?OgiE5lfEGHFxkifg4bS6iHk1JJQyh2iVJr6g3C4AuGudjU5wuFAbfARt?= =?Windows-1252?Q?9B656HVZnLh95snDItlP3TdZ5o5fdKJX/C0FHLF63f2wpOLnmZ/F1TpW?= =?Windows-1252?Q?b/jx957Znm20UTJuEf4nGH6fOD+/hQP9je6BTvUtME3CEiBkMThC9vgy?= =?Windows-1252?Q?p6PzBgMgnkIChJZCM32iLihnPi2NPUUCz8+eXHJS9yjGCEkw8HBiOPOZ?= =?Windows-1252?Q?r/k5m2qKBdGVhFaJbRLXi0erPTE/go8Ikq8qZtManFDKoG3CD3BoPIGr?= =?Windows-1252?Q?xMwjKmVr59O7i34+msArvjQfSEEdFkH5LdPW60D9UvV4SHSflRb7vh34?= =?Windows-1252?Q?fnZ3PpEkotKAnPCt4vuwdtuxG8kxAY4eGdtt+N045jwS55mvZnlkTj5W?= =?Windows-1252?Q?hmrcQ3hxZPXQ2V4II6imL6n3MR+6C9SxYhR9LftLiwUeQJbQt8WxD9td?= =?Windows-1252?Q?bRj5Y8AC7y2p/d68SuUkTRkRiVOBKeKgBwJ4f/WWJ2DtbjPr/D7HqO3h?= =?Windows-1252?Q?4jhrmt+je4BGXwmSZb4a55+5JL0bLgHG9dGmXH0fUPsf2qQuVlJraBoC?= =?Windows-1252?Q?CfYMoJ6NMg2mb8NYT2SOULEy9OdVp7kvDe0+e7iPgSJAy+e70eKHkVLv?= =?Windows-1252?Q?2uazgLb+z1tSvKQ/dF6YWiwYD3/MwMC1gyOOn8duAC0lMXHqa6w+xbX7?= =?Windows-1252?Q?UQtaDG/R4ZHFQVJVpNGMkWWALhrxNGgat6zSsNKR8A0mgxvcQYPdXA2Z?= =?Windows-1252?Q?MDKPlYoY+EKGPASkBrGh+9Kntn/bc8bK0uIcoYFtqTZzpoVAzNqjG2RC?= =?Windows-1252?Q?DlEKmp16qr3l0A7XvWT6BcLNOWE/lGPqlpsfKPtzJYAHKATWmhpSUYQS?= =?Windows-1252?Q?1p4+NZtii2yExCnMQk6E8Txagb29vABMUbbQ6enBaTSPbQLWU4kEii/e?= =?Windows-1252?Q?xA9+8bHj/uD3vz0oDPpLpKmvbAgMvST4TOdJ5QX0CQIz6CJZF8ccRUtL?= =?Windows-1252?Q?8lA98ZyuaWzVys6xnwTImTtJF7jEX6TNMjbJFW0KCrX4+s+zoxFxbrzO?= =?Windows-1252?Q?l+rrEilN5XmSXXlsHuQ1DxvGPHvokTTDaxmris8G5wcttSBrJ/gPw9iK?= =?Windows-1252?Q?Q7VbYQzNxErzzWiMa0Z5ajxaC3mqw3b2UmDJuIyNh7DbefKaQgKoVkSj?= =?Windows-1252?Q?oJK3ffb7l5OqR0O3NfqLiZQg8qq5JkHtxtCX9QseNl4Irm3DvmB7xyDf?= =?Windows-1252?Q?v8U0rWlYel7wssoo0QZcIJIj2/durxYYreUHqGcAjc1AoIGNAGM2rghQ?= =?Windows-1252?Q?2tPPldHRICaCte08nSpPwI/IzlQvFRoVCjKEbMOwLXc=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_VI1PR09MB23984AA4E8A5B9813CA34DD38CB79VI1PR09MB2398eurp_" MIME-Version: 1.0 X-OriginatorOrg: ost.ch X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: VI1PR09MB2398.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2dbee292-4163-4227-e4bf-08d98e1f7380 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2021 07:59:57.9694 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a6e70fa3-1c7a-4aa2-a25e-836eea52ca22 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: /PBRrjpkm/yd+aF04uE63AkRHBKbeLmg7POosstmHVaS6DNZ5BvqkHKcngw9Yw4wIfct/BkSCF1p/rIxIYHH9wEYvGcAvyD9RHdDJNaZlYc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR09MB2960 Archived-At: X-Mailman-Approved-At: Wed, 13 Oct 2021 01:17:03 -0700 Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 13 Oct 2021 08:01:48 -0000 --_000_VI1PR09MB23984AA4E8A5B9813CA34DD38CB79VI1PR09MB2398eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Dear WG I strongly support the WG adoption for the Compressed SRv6 Segment List Enc= oding in SRH draft (https://datatracker.ietf.org/doc/draft-filsfilscheng-sp= ring-srv6-srh-compression/). In different projects, I have worked with SRv6 and used the NEXT-C-SID flav= or to enable Segment Routing Traffic Engineering applications, especially i= n the Service Programming field. The following points convinced me for my decision: * First, the CSID draft supports the different flavors defined in RFC89= 86 with its next and replace methods. * CSID only supports SRv6 based data plane, which is IMHO the right ste= p for the future Kind Regards, Severin ________________________________ From: spring on behalf of James Guichard Sent: Friday, October 1, 2021 4:04 PM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a =93living=94 document; it may change as it goes thr= ough review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_VI1PR09MB23984AA4E8A5B9813CA34DD38CB79VI1PR09MB2398eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    Dea= r WG


    I s= trongly support the WG adoption for the Compressed SRv6 Segment List Encodi= ng in SRH draft (https:= //datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/= ).


    In = different projects, I have worked with SRv6 and used the NEXT-C-SID flavor = to enable Segment Routing Traffic Engineering applications, especially in t= he Service Programming field.


    The= following points convinced me for my decision:

    • First, the CSID draft supports the diffe= rent flavors defined in RFC8986 with its next and replace methods.
    • CS= ID only supports SRv6 based data plane, which is IMHO the right step for th= e future


    Kin= d Regards,

    Sev= erin


    From: spring <spring-b= ounces@ietf.org> on behalf of James Guichard <james.n.guichard@future= wei.com>
    Sent: Friday, October 1, 2021 4:04 PM
    To: SPRING WG <spring@ietf.org>
    Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
    Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/
     

    Dear WG:

     

    The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression.

     

    The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

     

    Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

     

    1. The SPRING working group is adopting a document that has multiple SRv6 Endp= oint behaviors.
    2. The document is a =93living=94 document; it may change as it goes through r= eview and analysis by the SPRING working group.
    3. All open discussion points raised on our mailing list MUST be addressed BEF= ORE said document is allowed to progress from the working group to publicat= ion. A list of these discussion points will be documented in the WG documen= t and maintained by the document editor in conjunction with the chairs.
    4. If this document is adopted by the working group, the chairs specify as par= t of the adoption call that the following text describing an open issue be = added to the document in the above-described open issues section:
      • "Given that the working group has said that it wants to standardize on= e data plane solution, and given that the document contains multiple SRv6 E= ndPoint behaviors that some WG members have stated are multiple data plane = solutions, the working group will address whether this is valid and coherent with its one data plane solution object= ive.".

     

    Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    --_000_VI1PR09MB23984AA4E8A5B9813CA34DD38CB79VI1PR09MB2398eurp_-- From nobody Wed Oct 13 02:37:02 2021 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 D3AD93A11D8 for ; Wed, 13 Oct 2021 02:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUy26RkSF_JU for ; Wed, 13 Oct 2021 02:36:55 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (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 36E393A118B for ; Wed, 13 Oct 2021 02:36:52 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id r201so1777530pgr.4 for ; Wed, 13 Oct 2021 02:36:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=F4l2a3fYjLNTaCsyzV97r5GGQiEtvGBixnw2X2WaiE8=; b=oGjEsfbQeE9cn4d75Ny1qYsiv4EfEzNI2Fp1qdk+HBJ6KVnixEJHEkhUJ/VgzPcvVl zUpW4/Qh1cR3mRoqh8sX/l+fo8bdhIcWnhZsRqCNgOjUE4D7WWYQpr3WJttoU9T02YZt FysHLl/XFTA967OjcuG71OaWVICXSNxX64maem2X5ucwRxiZZQulesslX3WuZ8wQvnzx evHWigCI0J7JXl3+VfhNaq3fmaO8JN8QfpXe+7LvRiVlhX+F46LiN7C5FzkIN6MMpK6x LJCGlOyqX3r8l31AvcIie9XK6vd5PV+5MyBLvgJS5Gb5FkO225aoF4pYhG1ciusHfgzK aBGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=F4l2a3fYjLNTaCsyzV97r5GGQiEtvGBixnw2X2WaiE8=; b=BfKfO0R19CtML3X9i6ZiFZNstzTIas0PxSvMGSaT7tzQHaRa/eyEj4TCE/Rw4NQ04G FdJJ44TJ32XkEFmlgd06TC/8KTZt3cwIH7nxVXSS6ZycfR+cF/AnMMNpDIc95KYbF6QO FsUxIa+m1gSVA+KD1EdMwfRIwiIMgzkh93AIBXBtoK2VxUyNTAT1e//2lxJRnuUXlF4N 5IF2Slh6ZpuBaaEAYuE/SThBixzULPiE4MHZWVBavsBh03dJo4paXzvlgl44LrxMBeZR AJmGDg8LOYxthWv6TvaC9ljGvdbJHk/20slIkcOT8JRtu5V7bNTYW/79ao8NbtA1wqN1 USWg== X-Gm-Message-State: AOAM532a+3oeNRbayZQPy640yLBeQPDmsEH2G1xSMuw+uR7Xg2ujU7N7 XeuKJEBpaxxVNPtDMIF5ZsKcY0NqyxyL/A== X-Google-Smtp-Source: ABdhPJz+fCQZwg17uT98HpE3Ooc603GohgIYvUgBj5UV1gCf4VmyUR3b1TWnwVy7eENJXvaP5Mt1Jw== X-Received: by 2002:a65:538e:: with SMTP id x14mr26825390pgq.364.1634117811025; Wed, 13 Oct 2021 02:36:51 -0700 (PDT) Received: from [192.168.10.9] (122x210x140x65.ap122.ftth.ucom.ne.jp. [122.210.140.65]) by smtp.gmail.com with ESMTPSA id p31sm4495718pfw.201.2021.10.13.02.36.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Oct 2021 02:36:50 -0700 (PDT) To: spring@ietf.org References: From: Kentaro Ebisawa Message-ID: Date: Wed, 13 Oct 2021 18:36:48 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7837361BD6AEA1C489D743E8" Content-Language: en-US Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 13 Oct 2021 09:37:01 -0000 This is a multi-part message in MIME format. --------------7837361BD6AEA1C489D743E8 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Dear SPRING Working Group, I support the adoption of draft-filsfilscheng-spring-srv6-srh-compression. The SID compression mechanism described in the document will help adopting SRv6 more efficiently when having multiple SIDs with small payload, in a way consistent with a single and already standardized SRv6 dataplane. I think the draft is already in a good state as a starting point. And I hope we can start the discussion soon to make improvements as a WG document. Best Regards, -- Kentaro Ebisawa | Mailing List: | Work: On 2021/10/01 23:04, James Guichard wrote: > > Dear WG: > > The chairs would like to express their appreciation for all the responses received to our emails with reference to how the working group wishes to move forward with respect to a solution for SRv6 compression. > > The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardization work. That is part of what this email attempts to confirm. > > Because of the above the chairs would like to issue a 2-week WG call for adoption ending October 15^th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that: > > 1. The SPRING working group is adopting a document that has multiple SRv6 Endpoint behaviors. > 2. The document is a living document; it may change as it goes through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be addressed BEFORE said document is allowed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maintained by the document editor in conjunction with the chairs. > 4. If this document is adopted by the working group, the chairs specify as part of the adoption call that the following text describing an open issue be added to the document in the above-described open issues section: > * "Given that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this is valid and coherent with its one data plane solution objective.". > > Please consider the above guidelines as you decide on whether to support or not this WG adoption. Please express clearly your reasoning for support/non-support as well as any open discussion points you would like addressed should the document be adopted into the working group. > > Thanks! > > Jim, Bruno & Joel > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --------------7837361BD6AEA1C489D743E8 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Dear SPRING Working Group,

    I support the adoption of draft-filsfilscheng-spring-srv6-srh-compression.

    The SID compression mechanism described in the document will help adopting SRv6 more efficiently when having multiple SIDs with small payload, in a way consistent with a single and already standardized SRv6 dataplane.

    I think the draft is already in a good state as a starting point. And I hope we can start the discussion soon to make improvements as a WG document.

    Best Regards,
    -- 
Kentaro Ebisawa | Mailing List: <ebiken.g@gmail.com> | Work: <ebisawa@toyota-tokyo.tech>

    On 2021/10/01 23:04, James Guichard wrote:

    Dear WG:

    The chairs would like to express their appreciation for all the responses received to our emails with reference to how the working group wishes to move forward with respect to a solution for SRv6 compression.

    The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardization work. That is part of what this email attempts to confirm.

    Because of the above the chairs would like to issue a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that:

    1. The SPRING working group is adopting a document that has multiple SRv6 Endpoint behaviors.
    2. The document is a living document; it may change as it goes through review and analysis by the SPRING working group.
    3. All open discussion points raised on our mailing list MUST be addressed BEFORE said document is allowed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maintained by the document editor in conjunction with the chairs.
    4. If this document is adopted by the working group, the chairs specify as part of the adoption call that the following text describing an open issue be added to the document in the above-described open issues section:
      • "Given that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this is valid and coherent with its one data plane solution objective.".

    Please consider the above guidelines as you decide on whether to support or not this WG adoption. Please express clearly your reasoning for support/non-support as well as any open discussion points you would like addressed should the document be adopted into the working group.

    Thanks!

    Jim, Bruno & Joel


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

    --------------7837361BD6AEA1C489D743E8-- From nobody Wed Oct 13 02:56:53 2021 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 8DD4B3A155A; Wed, 13 Oct 2021 02:56:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOB_hZbNESsL; Wed, 13 Oct 2021 02:56:42 -0700 (PDT) Received: from cmccmta3.chinamobile.com (cmccmta3.chinamobile.com [221.176.66.81]) by ietfa.amsl.com (Postfix) with ESMTP id 183173A1551; Wed, 13 Oct 2021 02:56:40 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.1]) by rmmx-syy-dmz-app10-12010 (RichMail) with SMTP id 2eea6166ad4a360-af67f; Wed, 13 Oct 2021 17:56:27 +0800 (CST) X-RM-TRANSID: 2eea6166ad4a360-af67f X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from YuexiaFu (unknown[39.144.37.227]) by rmsmtp-syy-appsvr01-12001 (RichMail) with SMTP id 2ee16166ad4829f-3a65a; Wed, 13 Oct 2021 17:56:27 +0800 (CST) X-RM-TRANSID: 2ee16166ad4829f-3a65a From: "fuyuexia" To: "'James Guichard'" , "'SPRING WG'" Cc: References: In-Reply-To: Date: Wed, 13 Oct 2021 17:56:26 +0800 Message-ID: <005b01d7c018$97a7e5b0$c6f7b110$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005C_01D7C05B.A5CB25B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQJPDOPAAAJxagA= Content-Language: zh-cn Archived-At: Subject: [spring] =?gb2312?b?tPC4tDogIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0dHBz?= =?gb2312?b?Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hl?= =?gb2312?b?bmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLw==?= 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, 13 Oct 2021 09:56:48 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005C_01D7C05B.A5CB25B0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear WG, =20 I support the adoption call. CSID draft defines multiple SRv6 flavors, = but they present a single SRv6 data plane based solution.=20 =20 Regards, Yuexia Fu =20 =20 =B7=A2=BC=FE=C8=CB: spring [mailto:spring-bounces@ietf.org] =B4=FA=B1=ED = Severin Dellsperger =B7=A2=CB=CD=CA=B1=BC=E4: 2021=C4=EA10=D4=C213=C8=D5 16:00 =CA=D5=BC=FE=C8=CB: James Guichard; SPRING WG =B3=AD=CB=CD: spring-chairs@ietf.org =D6=F7=CC=E2: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= res sion/ =20 Dear WG =20 I strongly support the WG adoption for the Compressed SRv6 Segment List Encoding in SRH draft ( https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= res sion/). =20 In different projects, I have worked with SRv6 and used the NEXT-C-SID flavor to enable Segment Routing Traffic Engineering applications, especially in the Service Programming field. =20 The following points convinced me for my decision: * First, the CSID draft supports the different flavors defined in RFC8986 with its next and replace methods. * CSID only supports SRv6 based data plane, which is IMHO the right step for the future =20 Kind Regards, Severin =20 _____ =20 From: spring on behalf of James Guichard = Sent: Friday, October 1, 2021 4:04 PM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= res sion/=20 =20 Dear WG: =20 The chairs would like to express their appreciation for all the = responses received to our emails with reference to how the working group wishes to move forward with respect to a solution for SRv6 compression.=20 =20 The apparent inclination of the working group is to use = https://datatracker. ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the = basis for its compression standardization work. That is part of what this = email attempts to confirm. =20 Because of the above the chairs would like to issue a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= res sion/ but with some clear guidelines as follows. By expressing support = for adoption of this document you are fully aware of and are acknowledging = that: =20 1. The SPRING working group is adopting a document that has multiple SRv6 Endpoint behaviors.=20 2. The document is a =A1=B0living=A1=B1 document; it may change as it = goes through review and analysis by the SPRING working group.=20 3. All open discussion points raised on our mailing list MUST be addressed BEFORE said document is allowed to progress from the working = group to publication. A list of these discussion points will be documented in = the WG document and maintained by the document editor in conjunction with = the chairs.=20 4. If this document is adopted by the working group, the chairs specify as part of the adoption call that the following text describing an open issue be added to the document in the above-described open issues = section: * "Given that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple = SRv6 EndPoint behaviors that some WG members have stated are multiple data = plane solutions, the working group will address whether this is valid and = coherent with its one data plane solution objective.". =20 Please consider the above guidelines as you decide on whether to support = or not this WG adoption. Please express clearly your reasoning for support/non-support as well as any open discussion points you would like addressed should the document be adopted into the working group. =20 Thanks! =20 Jim, Bruno & Joel =20 =20 ------=_NextPart_000_005C_01D7C05B.A5CB25B0 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

    Dear WG,

     

    I support the adoption call. CSID draft defines multiple SRv6 = flavors, but they present a single SRv6 data plane based solution. =

     

    Regards,

    Yuexia Fu

     

     

    =B7=A2=BC=FE=C8=CB: spring = [mailto:spring-bounces@ietf.org] =B4=FA=B1=ED = Severin = Dellsperger
    =B7=A2=CB=CD=CA=B1=BC= =E4: 2021=C4=EA10=D4=C213=C8=D5 16:00
    =CA=D5=BC=FE=C8=CB: James Guichard; SPRING = WG
    =B3=AD=CB=CD: spring-chairs@ietf.org
    =D6=F7=CC=E2: Re: [spring] WG Adoption = call for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/

     

    Dear WG

     

    I strongly support the WG adoption for the Compressed SRv6 Segment List = Encoding in SRH draft (https://datatracker.ietf.org/doc/draft-filsfilsch= eng-spring-srv6-srh-compression/).

     

    In different projects, I have worked with SRv6 and used the NEXT-C-SID = flavor to enable Segment Routing Traffic Engineering applications, = especially in the Service Programming = field.

     

    The following points convinced me for my = decision:

    • First, the = CSID draft supports the different flavors defined in RFC8986 with its = next and replace methods.
    • CSID only = supports SRv6 based data plane, which is IMHO the right step for the = future

     

    Kind Regards,

    Severin

    <= o:p> 

    From: spring <spring-bounces@ietf.org> on behalf of James Guichard = <james.n.guichard@futurewei.com>
    Sent: Friday, October = 1, 2021 4:04 PM
    To: SPRING WG = <spring@ietf.org>
    Cc: spring-chairs@ietf.org = <spring-chairs@ietf.org>
    Subject: [spring] WG Adoption = call for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/

     

    Dear = WG:

     =

    The chairs = would like to express their appreciation for all the responses received = to our emails with reference to how the working group wishes to move = forward with respect to a solution for SRv6 compression. =

     =

    The = apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-sp= ring-srv6-srh-compression/ as the basis for its compression = standardization work. That is part of what this email attempts to = confirm.

     =

    Because of = the above the chairs would like to issue a 2-week WG call for adoption = ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-sp= ring-srv6-srh-compression/ but with some clear guidelines as = follows. By expressing support for adoption of this document you are = fully aware of and are acknowledging that:

     =

    1. The SPRING = working group is adopting a document that has multiple SRv6 Endpoint = behaviors.
    2. The = document is a =A1=B0living=A1=B1 document; it may change as it goes = through review and analysis by the SPRING working group. =
    3. All open = discussion points raised on our mailing list MUST be addressed BEFORE = said document is allowed to progress from the working group to = publication. A list of these discussion points will be documented in the = WG document and maintained by the document editor in conjunction with = the chairs.
    4. If this = document is adopted by the working group, the chairs specify as part of = the adoption call that the following text describing an open issue be = added to the document in the above-described open issues = section:
      • "Given= that the working group has said that it wants to standardize one data = plane solution, and given that the document contains multiple SRv6 = EndPoint behaviors that some WG members have stated are multiple data = plane solutions, the working group will address whether this is valid = and coherent with its one data plane solution = objective.".

     =

    Please = consider the above guidelines as you decide on whether to support or not = this WG adoption. Please express clearly your reasoning for = support/non-support as well as any open discussion points you would like = addressed should the document be adopted into the working = group.

     =

    Thanks!

     =

    Jim, Bruno = & Joel

     =

     =

    ------=_NextPart_000_005C_01D7C05B.A5CB25B0-- From nobody Wed Oct 13 03:53:51 2021 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 943683A11FB; Wed, 13 Oct 2021 03:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.584 X-Spam-Level: X-Spam-Status: No, score=-9.584 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=A+VlgCwX; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Xwm+hHIq 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 bgD34fHmTzd8; Wed, 13 Oct 2021 03:53:41 -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 7E6E83A0EBD; Wed, 13 Oct 2021 03:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=72326; q=dns/txt; s=iport; t=1634122421; x=1635332021; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=QCAh0szvKw2Rtdn76CLAl5as3Dscl3GDXy2ZU0sIAB0=; b=A+VlgCwX33pez/fccsb94HEfkEX3/xsLcElxNMiOI500XmUkyPm9dsEK d/0OM7xjLJDh8bLWnh8P7uylnylNC2Ql9lSoNKeu9kKoU0iBchpQlfVWK OPodEdDWGSy0PZ1ZmiPuqTKo0ZbniGHuNNqodJWSm4X7Cr74zpLg2CQMb c=; IronPort-PHdr: =?us-ascii?q?A9a23=3Ab/X0uhOdiw032qz676Yl6ncZWUAX0o4cdiYa7?= =?us-ascii?q?5Mmj/RFdaHwt5jhPUmK4/JrgReJWIjA8PtLhqLQtLyoQm0P55uN8RVgOJxBX?= =?us-ascii?q?hMIk4MaygonBsPWBkjyLfqsZCs/T4xOUVZ/9CS9Nk5YUM/1e1zVpCi06jgfU?= =?us-ascii?q?hXyPAZ4PKL7AInX2s+2zOu1vZbUZlYguQ=3D=3D?= IronPort-Data: =?us-ascii?q?A9a23=3ABSIBwK7naGRacFUpnnFqLAxRtLLFchMFZxGqf?= =?us-ascii?q?qrLsTDasY5as4F+vmZKXjqFP/+LMGL8c99xO9mw8k1V6Jbdm94wQQVt+yExZ?= =?us-ascii?q?n8b8sCt6fZ1gavT04J+FiBIJa5ex512huLocYZkExcwmj/3auK49CEljvnRL?= =?us-ascii?q?lbBILes1h5ZFFcMpBgJ0XqPq8Zh6mJZqYDR7zGl4LsekOWHULOR4AOYB0pPg?= =?us-ascii?q?061RLyDi9yp0N8QlgRWifmmJzYynVFNZH4UDfnZw3cV3uBp8uCGq+brlNlV/?= =?us-ascii?q?0vD9BsrT9iiiLu+IgsBQ6XZOk6FjX8+t6qK20cZ4HdtlPdgcqNANS+7iB3R9?= =?us-ascii?q?zx14NtGsZW8YQwoJabL3u8aVnG0FgkvZ/UZqO+acCPXXcu7iheun2HX6+52F?= =?us-ascii?q?kAwMsgT+u92G3pm9PEEJnYKdB/rr+a33aO6Ue5qiewoLMjtNYYYsHBkwHfSC?= =?us-ascii?q?vNOaYvbWaTM6vdZ0Ss+wMdUEp72ZcMcZCEpalLPfhxEOl4NBLowgfu1nHTgf?= =?us-ascii?q?jweo1WQzYI8pWz7zBF4z7XsdtHSf7SiRcxEl0yFvWvJ5GHRDRQTNdjZwj2Am?= =?us-ascii?q?k9ALMencTjTQokeEviz8eRnxQ3VzW0IAxpQXly+ycRVQ3WWA7p3Q3H4MAJ0x?= =?us-ascii?q?UTqyHGWcw=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A+2zjd6nobmYbcC+pfbVKjegC2TbpDfOOim?= =?us-ascii?q?dD5ihNYBxZY6Wkfp+V/cjzhCWbtN9OYh4dcIi7Sda9qXO1z+8T3WBjB8bdYO?= =?us-ascii?q?CGghroEGgG1+vfKlLbalbDH4JmpMJdmu1FeaHN5DtB/IbHCWuDYqwdKbC8mc?= =?us-ascii?q?jC74qzvhQdLz2CKZsQkjuRYTzrdHGeMTM2fabRY6Dsn/avyQDQHUg/X4CePD?= =?us-ascii?q?0oTuLDr9rEmNbNehgdHSMq7wGIkHeB9KP6OwLw5GZcbxp/hZMZtUTVmQ3w4a?= =?us-ascii?q?uu99uhzAXH6mPV55NK3PP819p4AtCWgMR9EESvtu/oXvUlZ1SxhkFznAid0i?= =?us-ascii?q?dtrDAKmWZ4Ay1H0QKUQohym2q05+Cv6kd015ao8y7ovZKqm72IeNt9MbsauW?= =?us-ascii?q?qcGSGpt3bJe7pHof92NiuixulqJAKFkyLn69fSURZ20kKyvHo5iOYWy2dSSI?= =?us-ascii?q?0EddZq3MEiFW5uYdw99RjBmcoa+ShVfbbhzecTdUnfY2HSv2FpztDpVnMvHg?= =?us-ascii?q?2eSkxHvsCOyTBZkH1w0kNdnaUk7zg93YN4T4MB6/XPM6xumr0LRsgKbbhlDO?= =?us-ascii?q?NERcesEGTCTR/FLWrXK1X6E6MMPW7LtvfMkfkIzfDvfIZNwIo5mZzHXl8dvW?= =?us-ascii?q?kue1j2AcnLx5FP+gClehT0Yd0s8LAW23FdgMyzeFPGC1z3dLkeqbrXnxxEOL?= =?us-ascii?q?yoZx+aAuMjP8Pe?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAADmuWZh/5BdJa1XAxoBAQEBAQE?= =?us-ascii?q?BAQEBAwEBAQESAQEBAQICAQEBAYIFBQEBAQELAYEgMCMuB3daNzGER4NHA4R?= =?us-ascii?q?ZYIgLA4p0hSGKW4EuFIERA08FCwEBAQ0BASoBDAoEAQGEOUUCF4IxAiU0CQ4?= =?us-ascii?q?BAgQBAQESAQEFAQEBAgEGBIERE4U7CCUNhkIBAQEBAwEBEAgDEBMBASwLAQ8?= =?us-ascii?q?CAQYCBwcDAwECIQECBAUCAh8GCxQGAwgCBAENBQgTB4JQgX5XAy8BDpBojzY?= =?us-ascii?q?BgToCih9zCYEvgQGCCAEBBgQEgTYBAwIOQYJ/DQuCNQmBIxcBgwOEEoEehVc?= =?us-ascii?q?nHIFJRIEUAUOCZz6CIUIBAQIBgSMFARIBIxUJAQUHCQgJgk0bIIIMIospLyM?= =?us-ascii?q?fZAQLEDYBAQUbAg0sIBY0CBIMGBAfCxECDgkQkTAPCIxMg2+JX5FEZwqDMIE?= =?us-ascii?q?ziROIHoYhglODMhSDaotsl0GHE40TgWIfgh+KLoNAkEUbhFsCBAIEBQIOAQE?= =?us-ascii?q?GNYEsO2lwcBU7gjUBATIJSBkPgz6KYgwFERUZgyKFFGCEanQCNgIGAQoBAQM?= =?us-ascii?q?JkVEtghcBAQ?= X-IronPort-AV: E=Sophos;i="5.85,370,1624320000"; d="scan'208,217";a="920788593" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Oct 2021 10:53:33 +0000 Received: from mail.cisco.com (xbe-aln-005.cisco.com [173.36.7.20]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 19DArX56006127 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 13 Oct 2021 10:53:33 GMT Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xbe-aln-005.cisco.com (173.36.7.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 13 Oct 2021 05:53:33 -0500 Received: from xfe-aln-001.cisco.com (173.37.135.121) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 13 Oct 2021 05:53:32 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (173.37.151.57) 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.792.15 via Frontend Transport; Wed, 13 Oct 2021 05:53:32 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nnrEM5jDNqThxDdw7iuB0pti/MJOKG6GaBdJ2jtMIXszYRmEgl9ovMuFqCLu1QM4iHQDg0z98Q5RWmsfaLUYl83O3hsXjyAp4EtdzZQ7Bfps/ntThsO4L4HGseAKiqe9CLilQl0KTHziLNjjgDSgtygC3otsA58LqxMjFANNA19RZ3mr7JL1qVSw/6A91EiUbRmQynq3Vu8DejH8DtVsH4gisGl1eu6I9ZOyWc1TmsjTzuYV13B3niG1O2iFWGCr9Udt+0ZUJvdAc8jW0229ZixU/MZWOkGeLPXd5fMSRw9bJX4/VWRO1qWkGipAIj72GwcqOIE/nFE+FZcetTeKcA== 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=FX3mBFFEZx6FYPuii+g6IXIKYyE7sHJ1UuDQrggYgZo=; b=XPn4VNUL+/xR4UFOaLpHaBbJ4QNuiCHLVwACgwhrhuyz8ETVZtuJmV2NjAzqBcAn9CaM/HnG3O0x9E93+OzvsjlGvUZGz2mXNv8kRkhswRO8nWq4b/MLzBr7F+2JuTEJnI2h3MBggOCyO8/9M95/RxubePC1po0pgigyhIxM6U1g4VW5Me23RWKuINiRiY2/EM1+tjrp6MbYd4Z1otJRj4f9K+vmtcG0UhXSADmSoGeff+pEyQg844+C6ouexMcIdzcvnMNY2mz0b3H8QXWlWXBinpcV0AcftkhRoEjleKFA02PZxMsAp5iTVAZK/8aPLEVSw6rzAWRAoZSQnodiww== 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=FX3mBFFEZx6FYPuii+g6IXIKYyE7sHJ1UuDQrggYgZo=; b=Xwm+hHIq7cxeGqnIL0Dk+j0selUbdLmuIVauzV5pVkQFY0zz5eQ91p+Rbwoati9wVHAdroiunxH+hLlLCn0g8hmY92vDySRHQGzaUTjL5JcsOcMl0J7W3DHzHYrmnzfmizMKzxcf9AqGPWT5EGR57lY3To2MCC/Dkl6Do9f+sYY= Received: from CO6PR11MB5650.namprd11.prod.outlook.com (2603:10b6:5:35a::9) by CO6PR11MB5635.namprd11.prod.outlook.com (2603:10b6:5:35f::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.24; Wed, 13 Oct 2021 10:53:31 +0000 Received: from CO6PR11MB5650.namprd11.prod.outlook.com ([fe80::6071:7cb6:d30e:b0d]) by CO6PR11MB5650.namprd11.prod.outlook.com ([fe80::6071:7cb6:d30e:b0d%4]) with mapi id 15.20.4587.030; Wed, 13 Oct 2021 10:53:30 +0000 From: "Francois Clad (fclad)" To: Gyan Mishra , "Chengli (Cheng Li)" CC: James Guichard , SPRING WG , Yisong Liu , spring-chairs Thread-Topic: =?gb2312?B?W3NwcmluZ10gUkWjuiBXRyBBZG9wdGlvbiBjYWxsIGZvciBodHRwczovL2Rh?= =?gb2312?B?dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNw?= =?gb2312?Q?ring-srv6-srh-compression/?= Thread-Index: AQHXvhSxizv67pcXzkGWXcntuVNYbqvQxGnh Date: Wed, 13 Oct 2021 10:53:30 +0000 Message-ID: References: <202110021255323466813813@chinamobile.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 788cce8e-d288-4692-b6eb-08d98e37b1e3 x-ms-traffictypediagnostic: CO6PR11MB5635: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6108; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: gJhQh61Fiu1nxhr971K95TI9jF7YVuC2QEboIrON1Jw973GbT43aCLIoClNEyBo8iXec3kzB73SycjdU1WcSzn138kQk1TllQsZ5bzenVH9yCGeGgqG4kKCU7ao6IEfoYxrVyUg0Og/CchqmTb43vs7xdjd9i4k0kB9oIH3O7iuW5rYH5Ig4jAa07e4g0T7in1dDGvIKXo3eEyfe3hx9T7ppmjoRXNGwzxJERJ/ZV5emYWz8kZ/kq2kIUIywWnzx1TcZcKrGu3RIgn4C8ikULM2DF+LB7yle3fgHivBi6qUTrUWrFwKYjdmXlRJ6BBwtoLrIg1K3pEbvcpofLltSFhEDAALPPuhxTG6W+W5sOOOv19Hytfrk/kYSCAEQtjyt3VOF3rw3eyk7cHwhJyKbXoypnq/9ap0cihktoszmQ7icoq86bw5CwDmSSBKrpcVdjmd6wBkPGTKF9Lx5m9SuxGPaP+/kidgvvI1dokYYuGhQfYa9fZ1zSSa1FOHh7fsGAvinJsP2vgLls3eW9gmIUvp0H5kp08f6bYN/9WUOANRlalaZlGH8J/iHysYRfR/jmZNSSKT/HFFM4FOQpnG36ARXWOE/00V2Z+dsFz8u8YbMNtsUyoQe5xycrafVWvMtNUavpjRwYXvrEoUbeI45e155gd+dSWXvbOfBC+lfybh7G46ChacGkc1ysYL1Fs9sCIzE1oaoHYqQ5jK7NcPL17kfHv4kbM8LZZ8zCnO5Rbe/vZs4+plnACCTxbQ0Fp0dwhZ22vyJobylWFJOrUd36A6mXxJaq5xYpXPq70WOIVNJioVP2Q+lIRyGskNtWuxAKwAKAIYjmDevxfdYoIytVQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR11MB5650.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(9686003)(186003)(55016002)(5660300002)(966005)(71200400001)(166002)(40140700001)(6506007)(7696005)(91956017)(76116006)(4326008)(66556008)(64756008)(52536014)(110136005)(30864003)(8936002)(33656002)(66476007)(38070700005)(66446008)(66946007)(83380400001)(53546011)(26005)(122000001)(38100700002)(86362001)(54906003)(316002)(508600001)(2906002)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?gb2312?B?TnRseGVOQXJGWDc4eDg3NEFUWERIZGY1WCtMVzI1eHoxZjVOMFRDT2NvWnZU?= =?gb2312?B?RU9YTHdsZWFhdk9vZHQyZU90cXZMVlhwdmVFNWg0WE5EZkswV1B3a1VSMGpp?= =?gb2312?B?RVFMRm1GT1pEbEtNNnF6bXFFNTg4dllza1JHaGUyWTN3QmFNTDFWZG9pK0Zj?= =?gb2312?B?allMTDdFRFdMMkgxYzVhU1FxK1dqTkR0bUlyL1ltSmNIOCtwWktmZGJXbEhv?= =?gb2312?B?a2lXYWdVWU05cGQyQmptT3l0bDJIaG1UM3ZsODlERVNoZnBaM2dlSk4vNEFa?= =?gb2312?B?eFZpOFc0bVpBaHQvaWpwQ1JYZEZhakR1TGx5MndVbDRNNE1zcmVhU1NNZ1pn?= =?gb2312?B?MW9uN0JPTjR1alZtblZLSGNYQm9IWWtkdWl4NVQ1RjRGN0ZIZlN6Q2ZzNDNC?= =?gb2312?B?TEZTSDI0ZjVCUnZjY3A2cFlTd25XOXhwMzNUeXdmMHAvNWlZRDBGQ1loWUU2?= =?gb2312?B?WERIelEzTU1nY21kSUZOTUJ1NW5zQlo0SWxpM2Y5bkp2TkZNRGs5YkxoQjFG?= =?gb2312?B?dHNzeWtBN1A2ZmNmbXNZL1QyeXhxdnZKb2thd1FpZFZHODRkL2ZuNzFsclNl?= =?gb2312?B?ZmxqVGJadzIzb29xYTVhb3o4V1k3WFFLK1pyZEZEc0tSR1Vtbnc2U0lPbkp0?= =?gb2312?B?dVpwdHVZN1E0ekx5cVVFZDg2cHlycTNqUnl1OEkvRlFLRzVxOWxIb1dhbnhL?= =?gb2312?B?OTNLbFZGeVNmL3poOHZMOGdsK0xaNEJ3SHhieWlCckliLzNaYnBzcGRXRkds?= =?gb2312?B?dk5IZFA2NklLVjJmTWNIZTVtZ1hyOGpuMTIweUhZQkt3dkNjNThSM1Q1NFlH?= =?gb2312?B?b2F3M2s3bnhlVlc5djNwTFZZUUFHZkFZY0U1YjJkVlJiZlAyTEdJWkZuSWd4?= =?gb2312?B?T3J6VVcwNGNKeVlsa2Zkc2pqVVRoVERaczBOR2RITGhabzhCR3RWK3hja2Qy?= =?gb2312?B?U2w1bDA4dEVjOFR4cmhpRjhPMVhMbGRKREdwZTg4Qmx1LzNzNjc5cW55SG5x?= =?gb2312?B?WGYzWGh6SHlNTlcwMHIvRGlYUFRtYWkxWFV1ZzhDb3ZFRmtydW1sQ05WejI2?= =?gb2312?B?R0hHa1JsQmtUbzFkSGFDSCtKSlBEN2R4OHdtbHdHdDVodC9lamtYd3IxUHYz?= =?gb2312?B?RGxBdUpMQ2F2aWZsK0lvdEUwK2ExdndDY1lPVk8rSUwrR0JXWmQxaHkyWWVs?= =?gb2312?B?RCtxWkJEVmhsU3o1WG5UM0huSnB1Y0VucXh6TTNONEw4QklKbm51OHRWSElm?= =?gb2312?B?MEFZZjZGRG1mZHhXbzBJRExJbUZGdU5nTHFVcHoyK3BWSjJOckw4RWZlZlFj?= =?gb2312?B?SzRVUkRJa3hYZ2JSL3FrN3NLYlhnMk8xeTh1TEhCYXl1dnZXc0NWMldNTjV1?= =?gb2312?B?WWpxUjR5UzlEa3pSMmlMeVJRQno4bWJJV0Nid3QxaVZEdHNwa05ja3RhNjMv?= =?gb2312?B?bXZZTTg5V1Zac3k2OFZ6Y3hKbExGT1lYelRYaXowWW84Um5tVEsxWityMlZP?= =?gb2312?B?TUx3eFc5RlNqVGhweWdxNmZXZ0tXdkk0WXRwNlNSNUZ5UWVlemxHRGZ6SEE3?= =?gb2312?B?eWJNY1I0QXo5bWFHbUQxSVN2YUpNVXliSVlXYUgvT0h2a2tKQWpEODRLUDBy?= =?gb2312?B?MWMyS3JMYmxKNTZyYytKZlI2T2hvaDJ0SmJsL09yZVlrS2lldnROWDcxbXNR?= =?gb2312?B?VWxYdHJjaGdvZHlkcHJKL21jbURaTG1HbHlJZklKS3gyL3RkS3pZTHl1SThy?= =?gb2312?B?d0pPK1dILzczY09PM0JaOUY5cXIwSWYzcC9NajR3a2JOSU44c0xZcjVxcXM2?= =?gb2312?B?MCtkZytRTXkzUm1kUW9qZz09?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO6PR11MB5650B52988D3B6607BAC1B58ACB79CO6PR11MB5650namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO6PR11MB5650.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 788cce8e-d288-4692-b6eb-08d98e37b1e3 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2021 10:53:30.7396 (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: 6ScDDc/oPJYArLsifcg+qx6VtgBjgkfGyB2ab6U9RdW0yquHtzOaFqzVUEgkCij4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR11MB5635 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xbe-aln-005.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [spring] =?gb2312?b?UkWjuiBXRyBBZG9wdGlvbiBjYWxsIGZvciBodHRwczov?= =?gb2312?b?L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5n?= =?gb2312?b?LXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8=?= 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, 13 Oct 2021 10:53:48 -0000 --_000_CO6PR11MB5650B52988D3B6607BAC1B58ACB79CO6PR11MB5650namp_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgR3lhbiwNCg0KVGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrLiBUaGUgYXV0aG9ycyB3aWxsIHdv cmsgb24gc29tZSBtb3JlIGlsbHVzdHJhdGlvbnMgdG8gYWRkIGluIHRoZSBkcmFmdC4NCg0KSW4g bXkgcHJldmlvdXMgZW1haWwgKGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cv c3ByaW5nL1pmYkh0UTFGVHFXWXFqWHFjRnVFZjIySTJMOC8pLCBJIHByb3ZpZGVkIGFuIGV4YW1w bGUgb2YgaG93IHRoZSBOZXh0LUMtU0lEIGFuZCBSZXBsYWNlLUMtU0lEIGZsYXZvcnMgY291bGQg YmUgdXNlZCB0b2dldGhlciBhbmQgd2l0aCBkaWZmZXJlbnQgQy1TSUQgbGVuZ3Rocy4gTGV0IG1l IHJlc3RhdGUgdGhhdCwgYXMgc2hvd24gaW4gdGhpcyBleGFtcGxlLCB0aGVyZSBpcyBubyBsZWFz dCBjb21tb24gZGVub21pbmF0b3IgZm9yIEMtU0lEIGxlbmd0aHMgYmV0d2VlbiB0aGUgZmxhdm9y cy4NCg0KQXMgYSBzaWRlIG5vdGUsIGNvdWxkIHlvdSBwbGVhc2UgdXNlIHRoZSB0ZXJtaW5vbG9n eSBkZWZpbmVkIGluIHRoaXMgQy1TSUQgZHJhZnQgb3IgaW4gUkZDIDg5ODYvODc1ND8gWW91ciBl bWFpbHMgc2VlbSB0byBtaXggdGhlbSB1cCBhbmQgbWFrZXMgaXQgZGlmZmljdWx0IGZvciBtZSB0 byB1bmRlcnN0YW5kIHlvdXIgcXVlc3Rpb25zLg0KDQpUaGFua3MsDQpGcmFuY29pcw0KDQpGcm9t OiBHeWFuIE1pc2hyYSA8aGF5YWJ1c2Fnc21AZ21haWwuY29tPg0KRGF0ZTogU3VuZGF5LCAxMCBP Y3RvYmVyIDIwMjEgYXQgMjI6MjMNClRvOiBDaGVuZ2xpIChDaGVuZyBMaSkgPGMubEBodWF3ZWku Y29tPiwgRnJhbmNvaXMgQ2xhZCAoZmNsYWQpIDxmY2xhZEBjaXNjby5jb20+DQpDYzogSmFtZXMg R3VpY2hhcmQgPGphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbT4sIFNQUklORyBXRyA8c3By aW5nQGlldGYub3JnPiwgWWlzb25nIExpdSA8bGl1eWlzb25nQGNoaW5hbW9iaWxlLmNvbT4sIHNw cmluZy1jaGFpcnMgPHNwcmluZy1jaGFpcnNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3Nwcmlu Z10gUkWjuiBXRyBBZG9wdGlvbiBjYWxsIGZvciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8NCg0K SGkgRnJhbmNvaXMsIENoZW5nbGkgJiBhdXRob3JzDQoNCk1hbnkgVGhhbmtzIGZvciB5b3VyIGZl ZWRiYWNrIHRvIHRoZSBXRyBvbiB0aGUgY3JpdGljYWwgdG9waWMgaW50ZXJvcGVyYWJpbGl0eSBv ZiB0aGUgdVNJRCBtaWNyby1zaWQgMTYgYml0IHVTSUQgICChsE5GPUxvY2F0b3IvRnVuY3Rpb24g Y29tYm+hsSAgMTI4IGJpdCBjb250YWluZXIgYmFzZWQgc29sdXRpb24gYW5kIHRoZSBHLVNSVjYg MzIgYml0IEctU0lEIKGwTkY9TG9jYXRvci9GdW5jdGlvbiBjb21ib6GxIDQgLSAzMiBiaXQgRy1T SUQgaW4gMTI4IGJpdCBjb250YWluZXIgYmFzZWQgc29sdXRpb24gZGVmaW5lZCBhcyBOZXh0IGFu ZCBSZXBsYWNlIGZsYXZvcnMgaW4gdGhlIGRyYWZ0Lg0KDQpJIGFtIHJlYWxseSBjb25jZXJuZWQg YXMgdG8gaG93IHRoZSBuZXh0IGFuZCByZXBsYWNlIGludGVyb3BlcmFiaWxpdHkgd291bGQgd29y ayBmb3IgYWRqYWNlbnQgbm9kZXMgdXNpbmcgU0lEIHdpdGhpbiBzYW1lIG9yIGFkamFjZW50IGNv bnRhaW5lci4NCg0KU2VjdGlvbiA2LjEgbWVudGlvbnMgdGhhdCAgTmV4dCBmbGF2b3IgcmVjb21t ZW5kYXRpb24gaXMgZm9yIDE2IGJpdCBhcyB0aGUgdVNJRCBkcmFmdCAmIHRoaXMgZHJhZnQgTkYg YXMgMTYgYml0IGlzIG1vc3Qgb3B0aW1hbCB1U0lEIHNpemUgd2l0aGluIHRoZSB1U0lEIGNvbnRh aW5lciBhbmQgUmVwbGFjZSBmbGF2b3IgcmVjb21tZW5kYXRpb24gaXMgZm9yIDE2IGJpdCBhcyB0 aGUgRy1TUlY2IGRyYWZ0ICYgdGhpcyBkcmFmdCBORiBhcyAzMiBiaXQgRy1TSUQgaXMgbW9zdCBv cHRpbWFsIEctU0lEIHNpemUgd2l0aGluIHRoZSBHLVNJRCBjb250YWluZXIuDQoNClBsZWFzZSAg ZWxhYm9yYXRlIG9uIHRoaXMgaW4gbW9yZSBkZXRhaWwsIGFzIHdpdGggdGhpcyBkcmFmdCBmb3Ig bmV4dCBhbmQgcmVwbGFjZSBpbnRlcm9wZXJhYmlsaXR5LCBmb2xsb3dpbmcgdGhlIFNSdjYgY29t cHJlc3Npb24gcmVxdWlyZW1lbnRzIGZvciBvcHRpbWFsIGhhcmR3YXJlIGZvcndhcmRpbmcgYW5k IHN0YXRlIGVmZmljaWVuY3kgdGhhdCBOZXh0IHdvdWxkIGJlIHJlY29tbWVuZGVkIHRvIHVzZSAx NiBiaXQgU0lEIGFuZCBSZXBsYWNlIHdvdWxkIGJlIHJlY29tbWVuZGVkIDMyIGJpdCBTSUQuICAg UGxlYXNlIGVsYWJvcmF0ZSBpbiBkZXRhaWwgYXMgdG8gd2h5IDE2IGJpdCBpcyBub3QgcmVjb21t ZW5kZWQgZm9yIHJlcGxhY2UgZmxhdm9yIGFuZCAzMiBiaXQgaXMgbm90IHJlY29tbWVuZGVkIGZv ciBuZXh0IGZsYXZvciBmb3IgYWxsIG9mIHRoZSByZXF1aXJlbWVudHMgZHJhZnRzIGxpc3Qgb2Yg U1J2NiBjb21wcmVzc2lvbiByZXF1aXJlbWVudHMgZWFjaCBvbmUgYnkgb25lIGFuZCB0aGUgcHJv YmxlbXMgZW5jb3VudGVyZWQgd2hlbiBub3QgdXNpbmcgdGhlIHJlY29tbWVuZGVkIFNJRCBsZW5n dGguDQoNClRodXMgZm9yIG5leHQgYW5kIHJlcGxhY2UgZmxhdm9yIGludGVyb3BlcmFiaWxpdHkg ZXZlbiBwb3NzaWJsZSAgdG8gd29yayB3b3VsZCByZXF1aXJlIHR3byBkaWZmZXJlbnQgU0lEIHNp emVzIHdpdGhpbiB0aGUgc2FtZSBjb250YWluZXIgaW50ZXJvcGVyYWJpbGl0eSBjYXZlYXRzIGFu ZCBub3cgeW91IGhhdmUgdG8gZGVhbCB3aXRoIHVTSUQgY29udGFpbmVyIHN0eWxlIHVzaW5nIDE2 IGJpdCBTSUQgYW5kIEctU0lEIGNvbnRhaW5lciBzdHlsZSB1c2luZyAzMiBiaXQgU0lELg0KDQpG cm9tIHRoZSByZXF1aXJlbWVudHMgZHJhZnQsICBpbnRlcm9wZXJhYmlsaXR5IHBlcnNwZWN0aXZl LCB0aGUgcHJpbWFyeSBvYmplY3RpdmUgaXMgobBlbmNhcHN1bGF0aW9uIGhlYWRlciBjb21wcmVz c2lvbqGxIGFzIHRoYXQgaXMgd2hhdCB3ZSBoYXZlIHNwZW50IG92ZXIgYSB5ZWFyIG9uIHdpdGgg RFQgZmluZGluZyBhbiBvcHRpbWFsIGNvbXByZXNzaW9uIHNvbHV0aW9uLiAgU28gaGVyZSB0aGUg bG93ZXN0IGNvbW1vbiBkZW5vbWluYXRvciBlbmRzIHVwIGJlaW5nIDMyIGJpdCBTSUQgYW5kIHdl IG5vdyBoYXZlIGZhaWxlZCB0aGUgcHJpbWFyeSBvYmplY3RpdmUgb2YgYSBjb21wcmVzc2lvbiBz b2x1dGlvbi4NCg0KQXMgZmFyIGFzIGxvd2VzdCBjb21tb24gZGVub21pbmF0b3IgaXMgaXQgdHJ1 ZSB0aGF0IGluIG9yZGVyIHRvIG1lZXQgYWxsIHRoZSByZXF1aXJlbWVudHMgZHJhZnQgbGlzdCBv ZiBhbGwgU1J2NiBjb21wcmVzc2lvbiByZXF1aXJlbWVudHMgYm90aCBuZXh0IGFuZCByZXBsYWNl IGhhdmUgdG8gcmV2ZXJ0IHRvIHRoYXQgbG93ZXN0IGNvbW1vbiBkZW5vbWluYXRvciB3aGljaCBp cyAzMiBiaXQgU0lELiAgSWYgdGhhdCBpcyB0cnVlLCB1bmZvcnR1bmF0ZWx5IHRoYXQgbWFrZXMg dGhlIGRyYWZ0IGZhaWwgdGhlIHByaW1hcnkgb2JqZWN0aXZlIG9mIGFueSBTUnY2IGNvbXByZXNz aW9uIHNvbHV0aW9uLg0KDQpUbyB0aGF0IGVuZCBhcyBmYXIgYXMgaW50ZXJvcGVyYWJpbGl0eSBv biBOZXh0IGFuZCBSZXBsYWNlIGludGVyb3BlcmFiaWxpdHkgYmVpbmcgdGhlIGhpbmdlIHBpbiBv ZiB0aGlzIGRyYWZ0cyBhZG9wdGlvbiwgYXMgd2VsbCBldmVuIGlmIHRoZSBhdXRob3JzIHN0YXRl IHRoYXQgUmVwbGFjZSBjYW4gdXNlIDE2IGJpdCBTSUQgYXMgYSBwb3NzaWJpbGl0eSwgYXMgdGhl IDMyIGJpdCChsE5GobEgRy1TSUQgaXMgcmVjb21tZW5kZWQgZm9yIGhhcmR3YXJlIGZvcndhcmRp bmcgZWZmaWNpZW5jeSBhbmQgc2NhbGFiaWxpdHkgdGhhdCBpZiAxNiBiaXQgd2VyZSB1c2VkIEct U0lEIHdvdWxkIGZhaWwgdGhlIGhhcmR3YXJlIGZvcndhcmRpbmcgZWZmaWNpZW5jeSBhbmQgc2Nh bGFiaWxpdHkgcmVxdWlyZW1lbnRzIGFzIHdlbGwgYXMgcG9zc2libHkgb3RoZXIgcmVxdWlyZW1l bnRzIHdoaWNoIHNob3VsZCBhbHNvIGJlIHN0YXRlZCBpbiB0aGUgZHJhZnQuDQoNCg0KNi4xPGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtZmlsc2ZpbHNjaGVuZy1z cHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24tMDIjc2VjdGlvbi02LjE+LiAgQy1TSUQgTGVuZ3Ro DQoNCg0KDQogICBUaGUgTkVYVC1DLVNJRCBmbGF2b3Igc3VwcG9ydHMgYm90aCAxNi0gYW5kIDMy LWJpdCBDLVNJRCBsZW5ndGhzLiAgQQ0KDQogICBDLVNJRCBsZW5ndGggb2YgMTYtYml0IGlzIHJl Y29tbWVuZGVkLg0KDQoNCg0KICAgVGhlIFJFUExBQ0UtQy1TSUQgZmxhdm9yIHN1cHBvcnRzIGJv dGggMTYtIGFuZCAzMi1iaXQgQy1TSUQgbGVuZ3Rocy4NCg0KICAgQSBDLVNJRCBsZW5ndGggb2Yg MzItYml0IGlzIHJlY29tbWVuZGVkLg0KDQpUaGUgZHJhZnQgc2hvdWxkIG1lbnRpb24gdGhlIHJl Y29tbWVuZGF0aW9uIGZvciBjb21tb24gYmxvY2sgbGVuZ3RoIGZvciBpbnRlcm9wZXJhYmlsaXR5 LiAgVGhlIG9ubHkgYmxvY2sgc2l6ZSBwb3NzaWJsZSBpcyA0OCBiaXQgc28gYmxvY2sgc2l6ZSBz byB0aGF0IHdvdWxkIGJlIGEgbWFqb3IgYWRkcmVzc2luZyBpbmZsZXhpYmlsaXR5IGZvciBpbnRl cm9wZXJhYmlsaXR5Lg0KDQoNCjYuMjxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o dG1sL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLTAyI3Nl Y3Rpb24tNi4yPi4gIEJsb2NrIExlbmd0aA0KDQoNCg0KICAgVGhlIHJlY29tbWVuZGVkIFNSdjYg U0lEIGJsb2NrIHNpemVzIGZvciB0aGUgTkVYVC1DLVNJRCBmbGF2b3IgYXJlDQoNCiAgIDE2LCAz MiBvciA0OCBiaXRzLiAgVGhlIHNtYWxsZXIgdGhlIGJsb2NrLCB0aGUgaGlnaGVyIHRoZSBjb21w cmVzc2lvbg0KDQogICBlZmZpY2llbmN5Lg0KDQoNCg0KICAgVGhlIHJlY29tbWVuZGVkIFNSdjYg U0lEIGJsb2NrIHNpemUgZm9yIHRoZSBSRVBMQUNFLUMtU0lEIGZsYXZvciBjYW4NCg0KICAgYmUg NDgsIDU2LCA2NCwgNzIgb3IgODAgYml0cywgZGVwZW5kaW5nIG9uIHRoZSBuZWVkcyBvZiB0aGUg b3BlcmF0b3IuDQoNCg0KVGFraW5nIHRoaXMgZnVydGhlciBhbm90aGVyIHN0ZXAgYXMgdGhpcyBk cmFmdCBuZWVkcyB0byBkZXNjcmliZSBpbiBkZXRhaWwgd2l0aCBleGFtcGxlcyBvZiB0aGUgZmVh c2liaWxpdHkgb2YgaG93IHR3byBhZGphY2VudCBub2RlcyBvbmUgdXNpbmcgbmV4dCAxNiBiaXQg U0lEIGFuZCBvdGhlciB1c2luZyByZXBsYWNlIDMyIGJpdCBTSUQgYXMgcmVjb21tZW5kZWQgd2hl cmUgdGhlIDE2IGJpdCB1U0lEIG5leHQgZmxhdm9yIGFuZCAzMiBiaXQgRy1TSUQgYXJlIGluIHRo ZSBzYW1lIFNSSCAxMjggYml0IGNvbnRhaW5lci4NCg0KQXMgdGhlIHVTSUQgTmV4dCBmbGF2b3Ig ZHJhZnQgcGVyZm9ybXMgYSBzaGlmdCB0b3dhcmRzIEIgdG93YXJkcyBuaWJibGUgQSwgQiBuaWJi bGVzLCBhbmQgUmVwbGFjZSBkb2VzIGEgcmVwbGFjZSBvZiB0aGUgQS1BcmcgcG9ydGlvbiAgb2Yg dGhlIDEyOCBiaXQgSVB2NiBhZGRyZXNzLCBob3cgd291bGQgdGhhdCB3b3JrIHdpdGggYWRqYWNl bnQgbm9kZXMgdXNpbmcgZGlmZmVyZW50IFNJRCBmbGF2b3JzIG9mIGRpZmZlcmVudCBTSUQgbGVu Z3Rocy4NCg0KDQpUaGUgTmV4dCBmbGF2b3IgdVNJRCBTUnY2IFBHTSAgY29tcHJlc3Npb24gc29s dXRpb24gcHJvY2VzcyBpcyB2ZXJ5IGRpZmZlcmVudCB3aGVyZSB3aGVuIGluZGV4aW5nIHRoZSBt aWNybyBzaWQgbmliYmxlcyB3aXRoaW4gdGhlIDEyOCBiaXQgY29udGFpbmVyLCBpdCBwZXJmb3Jt cyBhIHNoaWZ0IHRvd2FyZHMgdGhlIHRvcCBsb3dlciBvcmRlciBiaXRzIG9mIHRoZSBJUHY2IGFk ZHJlc3MsIHdoZXJlIHRoZSBSZXBsYWNlIGZsYXZvciBHLVNSdjYgUEdNIGNvbXByZXNzaW9uIHNv bHV0aW9uIGluZGV4aW5nIHRoZSA0IEctU0lEcyB3aXRoaW4gdGhlIGNvbnRhaW5lciBkb2VzIGEg UmVwbGFjZSBhdCB0aGUgQS1BcmcgYm90dG9tIGhpZ2hlciBvcmRlciBiaXRzLg0KDQpUaGUgcmVm ZXJlbmNpbmcgb2YgdGhlIDE2IHVTSUQgb3IgMzIgIGJpdCBHLVNJRCAgbmliYmxlcywgaW5kZXhp bmcgYW5kIHJlZmVyZW5jZSBvZiB3aGljaCBuaWJibGUgdG8gcmVmZXJlbmNlZCBmb3IgbmV4dCBh bmQgcmVwbGFjZSBmb3IgZGlyZWN0bHkgYWRqYWNlbnQgbm9kZXMgd2l0aCBuaWJibGVzIHdpdGhp biB0aGUgc2FtZSAxMjggYml0IGNvbnRhaW5lciBvciBhZGphY2VudCBjb250YWluZXJzIGlzIHRo ZSBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlIHRoYXQgc2VlbXMgdG8gZXhpc3QuDQoNClRoaXMgbmVl ZHMgdG8gYmUgY2xhcmlmaWVkIG9uIHRoZSBuZXh0IHNuZCByZXBsYWNlIGludGVyb3BlcmFiaWxp dHkgb3BlcmF0aW9uIGluIGRldGFpbC4NCg0KQWxzbyBSZXBsYWNlIGZsYXZvciB1c2VzIENPQyBk ZWxpbWl0ZXIgZm9yIHNpZ25hbGluZyBjb21wcmVzc2lvbiBmdW5jdGlvbiBpcyBhY3RpdmUgd2hl cmUgTmV4dCBkb2VzIG5vdCBoYXZlIGFueSBzaWduYWxpbmcgb2YgY29tcHJlc3Npb24gYmVpbmcg YWN0aXZlIG9yIG5vdCBvciBtYXkgaGF2ZSBhIGRpZmZlcmVudCB3YXkgb2Ygc2lnbmFsaW5nIHRo YXQgdXBjb21pbmcgbm9kZSBkb2VzIG5vdCBzdXBwb3J0IGNvbXByZXNzaW9uLg0KDQpIb3cgZG9l cyB0aGUgY29tcHJlc3Npb24gc2lnbmFsaW5nIGludGVyb3BlcmFiaWxpdHkgd29yayBiZXR3ZWVu IE5leHQgYW5kIFJlcGxhY2UgZmxhdm9ycy4gIFRoYXQgc2hvdWxkIGJlIGFkZHJlc3NlZCBhcyB3 ZWxsIGluIHRoZSBkcmFmdC4NCg0KS2luZCBSZWdhcmRzDQoNCkd5YW4NClZlcml6b24gSW5jDQoN Ck9uIEZyaSwgT2N0IDgsIDIwMjEgYXQgMTozNCBQTSBGcmFuY29pcyBDbGFkIChmY2xhZCkgPGZj bGFkQGNpc2NvLmNvbTxtYWlsdG86ZmNsYWRAY2lzY28uY29tPj4gd3JvdGU6DQpIaSBHeWFuLA0K DQpJdCBpcyBwb3NzaWJsZSB0byBjb21iaW5lIFNJRHMgb2YgZGlmZmVyZW50IEMtU0lEIGZsYXZv cnMgYW5kIEMtU0lEIGxlbmd0aHMgaW4gdGhlIHNhbWUgU1JILCBhbG9uZyB3aXRoIHRob3NlIGRl ZmluZWQgaW4gUkZDIDg5ODYgQWZ0ZXIgYWxsLCB0aGV5IGxldmVyYWdlIHRoZSBzYW1lIFNSdjYg ZGF0YSBwbGFuZS4NCg0KTGV0IG1lIGdpdmUgeW91IGFuIGV4YW1wbGUuDQoNCkFzc3VtZSB0aGF0 IGFuIFNSIHNvdXJjZSBub2RlIHdhbnRzIHRvIHNlbmQgYSBwYWNrZXQgb250byBhbiBTUiBwYXRo IHRocm91Z2ggMTAgU1Igc2VnbWVudCBlbmRwb2ludCBub2RlcyAobm9kZXMgMSB0aHJvdWdoIDEw KSwgYW5kIGhhdmUgYSBWUE4gdGVybWluYXRpb24gZm9yIGEgVlJGIDEyMyBvbiBhIGxhc3QgU1Ig c2VnbWVudCBlbmRwb2ludCBub2RlIDExLg0KDQpUaGUgU1Igc291cmNlIG5vZGUgc2VsZWN0cyB0 aGUgc2VnbWVudHMgYXMgZm9sbG93czoNCg0KICAqICAgT24gbm9kZXMgMSB0aHJvdWdoIDUsIHRo ZSBTSUQgMjAwMTpkYjg6MDowSzAxOjogKHdpdGggSyBiZWluZyB0aGUgbm9kZSBJRCkgYm91bmQg dG8gRW5kIHdpdGggTkVYVC1DLVNJRCBmbGF2b3IgYW5kIDE2LWJpdCBDLVNJRCBsZW5ndGguDQog ICogICBPbiBub2RlcyA2IHRocm91Z2ggOSwgdGhlIFNJRCAyMDAxOmRiODowOjBLMDA6MDAwMTo6 ICh3aXRoIEsgYmVpbmcgdGhlIG5vZGUgSUQpIGJvdW5kIHRvIEVuZCB3aXRoIFJFUExBQ0UtQy1T SUQgZmxhdm9yIGFuZCAzMi1iaXQgQy1TSUQgbGVuZ3RoLg0KICAqICAgT24gbm9kZSAxMCwgdGhl IFNJRCAyMDAxOmRiODowOjEwMDA6MDAwMTo6IGJvdW5kIHRvIEVuZCAoUkZDIDg5ODYpLg0KICAq ICAgT24gbm9kZSAxMSwgYSBTSUQgMjAwMTpkYjg6MDoxMTAwOmQxMjM6OiBib3VuZCB0byBFbmQu RFQ0IChSRkMgODk4NikgZm9yIFZSRiAxMjMuDQoNClRoZSBTUiBzb3VyY2Ugbm9kZSB0aGVuIHNl bmRzIHRoZSBwYWNrZXQgb250byB0aGUgU1IgcGF0aCBieSBwZXJmb3JtaW5nIHRoZSBILkVuY2Fw cy5SZWQgYmVoYXZpb3Igd2l0aDoNCg0KICAqICAgSVB2NiBTb3VyY2UgQWRkcmVzcyA9IDxhbiBh ZGRyZXNzIG9mIHRoZSBTUiBzb3VyY2Ugbm9kZT4NCiAgKiAgIElQdjYgRGVzdGluYXRpb24gQWRk cmVzcyA9IDIwMDE6ZGI4OjA6MDEwMTowMjAxOjAzMDE6MDQwMTowNTAxDQogICogICBTUkggPQ0K DQogICAgICogICBTZWdtZW50TGlzdFswXSA9IDIwMDE6ZGI4OjA6MTEwMDpkMTIzOjoNCiAgICAg KiAgIFNlZ21lbnRMaXN0WzFdID0gMTAwMDowMDAxOjA5MDA6MDAwMTowODAwOjAwMDE6MDcwMDow MDAxDQogICAgICogICBTZWdtZW50TGlzdFsyXSA9IDIwMDE6ZGI4OjA6MDYwMDowMDAxOjoNCg0K VGhlcmVmb3JlLCB0aGVyZSBpcyBubyBub3Rpb24gb2YgbG93ZXN0IGNvbW1vbiBkZW5vbWluYXRv ciBmb3IgQy1TSUQgbGVuZ3RoLiBCYXNlZCBvbiB0aGUgZGVwbG95bWVudCByZXF1aXJlbWVudHMs IGFuIG9wZXJhdG9yIGhhcyB0aGUgZmxleGliaWxpdHkgdG8gc2VsZWN0IHRoZSBTUnY2IFNJRCBm bGF2b3IgYW5kIEMtU0lEIGxlbmd0aHMgb2YgdGhlaXIgY2hvaWNlLg0KDQpXZSBjYW4gdXBkYXRl IHRoZSBkcmFmdCB3aXRoIHRoaXMgdHlwZSBvZiBpbGx1c3RyYXRpb25zLg0KDQpUaGFua3MsDQpG cmFuY29pcw0KDQpGcm9tOiBzcHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpz cHJpbmctYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBHeWFuIE1pc2hyYSA8aGF5YWJ1 c2Fnc21AZ21haWwuY29tPG1haWx0bzpoYXlhYnVzYWdzbUBnbWFpbC5jb20+Pg0KRGF0ZTogU3Vu ZGF5LCAzIE9jdG9iZXIgMjAyMSBhdCAyMTowMQ0KVG86IFlpc29uZyBMaXUgPGxpdXlpc29uZ0Bj aGluYW1vYmlsZS5jb208bWFpbHRvOmxpdXlpc29uZ0BjaGluYW1vYmlsZS5jb20+Pg0KQ2M6IEph bWVzIEd1aWNoYXJkIDxqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb208bWFpbHRvOmphbWVz Lm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbT4+LCBTUFJJTkcgV0cgPHNwcmluZ0BpZXRmLm9yZzxt YWlsdG86c3ByaW5nQGlldGYub3JnPj4sIHNwcmluZy1jaGFpcnMgPHNwcmluZy1jaGFpcnNAaWV0 Zi5vcmc8bWFpbHRvOnNwcmluZy1jaGFpcnNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtzcHJp bmddIFJFo7ogV0cgQWRvcHRpb24gY2FsbCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vDQoN CkhpIFlpc29uZw0KDQpUaGUgbWFpbiBnb2FsIGZvciBvcGVyYXRvcnMgaXMgaW50ZXJvcGVyYWJp bGl0eS4gIEFzIGludGVyb3BlcmFiaWxpdHkgaXMgdGhlIGtleSByZWFzb24gZm9yIGEgc2luZ2xl IFNSdjYgY29tcHJlc3Npb24gc29sdXRpb24gdGhhdCB3ZSBoYXZlIFdHIGNvbnNlbnN1cyBhbmQg aXMgZGVzaXJlZC4NCg0KQ29udGludWVkIGRldGFpbHMgb2YgdGhlIGludGVyb3BlcmFiaWxpdHkg c3R1ZHkgIHNob3VsZCBiZSBhZGRlZCB0byB0aGUgZHJhZnQgYXMgdGhlIHN0dWR5IHByb2dyZXNz ZXMuDQoNCk9uZSBrZXkgZGV0YWlsIHRoYXQgaXMgbWlzc2luZyBpcyBmb3J3YXJkaW5nIGVmZmlj aWVuY3kgYW5kIHNjYWxhYmlsaXR5IHVzaW5nIE5FWFQtQy1TSUQgYW5kIFJFUExBQ0UtQy1TSUQg aW50ZXJvcGVyYWJpbGl0eSB1c2luZyAxNiBiaXQgU0lELg0KDQpBcyBORVhULUNTSUQgdVNJRCBD b250YWluZXIgTWljcm8gU2VnbWVudCBzaGlmdCBmbGF2b3IgdXNpbmcgR0lCL0xJQiBmb3IgdWx0 cmEgc2NhbGUgIFNSdjYgY29tcHJlc3Npb24gc29sdXRpb24gaXMgcmVjb21tZW5kZWQgZm9yIDE2 IGJpdCBTSUQgYW5kIFJFUExBQ0UtQy1TSUQgRy1TSUQgRy1TSUQgQ29udGFpbmVyIGJhc2VkIHNv bHV0aW9uIGlzIHJlY29tbWVuZGVkIGZvciAzMiBiaXQgU0lELg0KDQpPZiBhbGwgdGhlIHJlcXVp cmVtZW50cyBhcyBzdGF0ZWQsIHRoZSBlbmNhcHN1bGF0aW9uIGhlYWRlciBzaXplIGlzIHRoZSBw cmltYXJ5IG9iamVjdGl2ZSBmb3Igb3BlcmF0b3JzIHRvIGVsaW1pbmF0ZSBNU0QgaXNzdWVzIHdp dGggb3B0aW1hbCBmb3J3YXJkaW5nIGFuZCBzdGF0ZSBlZmZpY2llbmNpZXMuDQoNCkF0IHRoaXMg dGltZSBpbiBvcmRlciBmb3IgTmV4dCBhbmQgUmVwbGFjZSBzb2x1dGlvbnMgdG8gYmUgaW50ZXJv cGVyYWJsZSBrZWVwaW5nIGluIG1pbmQgcmVxdWlyZW1lbnRzIGZvciBvcHRpbWFsIGZvcndhcmRp bmcgYW5kIHN0YXRlIGVmZmljaWVuY3kgMzIgYml0IFNJRCB3b3VsZCBiZSB0aGUgbG93ZXN0IGNv bW1vbiBkZW5vbWluYXRvciB3aGljaCBzaG91bGQgYmUgc3RhdGVkIGFzIHRoZSBiYXNlbGluZSBy ZXN1bHQgb2YgdGhlIGFuYWx5c2lzIGRyYWZ0IG9uIENTSUQgb3ZlcmFsbCAyIHByb25nIHNvbHV0 aW9uLg0KDQpDU0lEIGRyYWZ0Og0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRt bC9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi0wMiNzZWN0 aW9uLTExDQoNCkJvdHRvbSBvZiBzZWN0aW9uIDExOg0KDQoNCiAgIFRoZSBpbnRlcm9wZXJhYmls aXR5IHdhcyB2YWxpZGF0ZWQgZm9yIHRoZSBmb2xsb3dpbmcgc2NlbmFyaW86DQoNCg0KDQogICBv ICBQYWNrZXQgZm9yd2FyZGluZyB0aHJvdWdoIGEgdHJhZmZpYyBlbmdpbmVlcmluZyBzZWdtZW50 IGxpc3QNCg0KICAgICAgY29tYmluaW5nLCBpbiB0aGUgc2FtZSBTUkggKFtSRkM4NzU0PGh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjODc1ND5dKSwgU1J2NiBTSURzIGJv dW5kIHRvIGFuDQoNCiAgICAgIGVuZHBvaW50IGJlaGF2aW9yIHdpdGggdGhlIE5FWFQtQy1TSUQg Zmxhdm9yIGFuZCBTUnY2IFNJRHMgYm91bmQNCg0KICAgICAgdG8gYW4gZW5kcG9pbnQgYmVoYXZp b3Igd2l0aCB0aGUgUkVQTEFDRS1DLVNJRCBmbGF2b3IuDQoNCg0KDQogICBGdXJ0aGVyIGludGVy b3BlcmFiaWxpdHkgdGVzdGluZyBpcyBvbmdvaW5nIGFuZCB3aWxsIGJlIHJlcG9ydGVkIGluDQoN CiAgIHRoaXMgZG9jdW1lbnQgYXMgdGhlIHdvcmsgcHJvZ3Jlc3Nlcy4NCg0KS2luZyBSZWdhcmRz DQoNCkd5YW4NCk9uIFNhdCwgT2N0IDIsIDIwMjEgYXQgMTI6NTYgQU0gWWlzb25nIExpdSA8bGl1 eWlzb25nQGNoaW5hbW9iaWxlLmNvbTxtYWlsdG86bGl1eWlzb25nQGNoaW5hbW9iaWxlLmNvbT4+ IHdyb3RlOg0KSGkgQ2hhaXJzICYgV0csDQoNCkkgc3Ryb25nbHkgc3VwcG9ydCB0aGUgYWRvcHRp b24gY2FsbC4gUmVnYXJkaW5nIGNoYWlyJ3Mgbm90ZSBpbiB0aGUgZW1haWwsIEkgd291bGQgbGlr ZSB0byBwb2ludCB0aGF0IHRoZSBuZXR3b3JrIHByb2dyYW1taW5nIG1vZGVsIChSRkM4OTk2KSBi eSBuYXR1cmUgZGVmaW5lcyBtdWx0aXBsZSBiZWhhdmlvcnMuIENTSUQgaGFzIGEgc2luZ2xlIFNS djYgYmFzZWQgZGF0YSBwbGFuZSB0aGF0IGRlZmluZXMgdGhlIG5leHQgYW5kIHJlcGxhY2UgYmVo YXZpb3JzIGNvbnNpc3RlbnQgd2l0aCB0aGUgbmV0d29yayBwcm9ncmFtbWluZyBwYXJhZGlnbS4N Cg0KQ1NJRCdzIG5leHQgYW5kIHJlcGxhY2UgYmVoYXZpb3JzIGhhdmUgYmVlbiB2ZXJpZmllZCBi eSBpbnRlcm9wZXJhYmlsaXR5IHRlc3QgaW4gQ2hpbmEgbW9iaWxlIGxhYm9yYXRvcnkgYW5kIHRo ZXJlIGlzIG5vIHByb2JsZW0gd2l0aCB0aGUgaW50ZXJ3b3JraW5nIG9mIHRoZSB0d28gYmVoYXZp b3JzIG9uIHRoZSBDU0lEIGRhdGFwbGFuZS4NCg0KQmVzdCBSZWdhcmRzDQpZaXNvbmcNCg0Kt6K8 /sjLOiBKYW1lcyBHdWljaGFyZDxtYWlsdG86amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29t Pg0KyrG85DogMjAyMS8xMC8wMSjQx8bazuUpMjI6MDQNCsrVvP7IyzogU1BSSU5HIFdHPG1haWx0 bzpzcHJpbmdAaWV0Zi5vcmc+Ow0Ks63LzcjLOiBzcHJpbmctY2hhaXJzPG1haWx0bzpzcHJpbmct Y2hhaXJzQGlldGYub3JnPjsNCtb3zOI6IFtzcHJpbmddIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5n LXNydjYtc3JoLWNvbXByZXNzaW9uLw0KRGVhciBXRzoNCg0KVGhlIGNoYWlycyB3b3VsZCBsaWtl IHRvIGV4cHJlc3MgdGhlaXIgYXBwcmVjaWF0aW9uIGZvciBhbGwgdGhlIHJlc3BvbnNlcyByZWNl aXZlZCB0byBvdXIgZW1haWxzIHdpdGggcmVmZXJlbmNlIHRvIGhvdyB0aGUgd29ya2luZyBncm91 cCB3aXNoZXMgdG8gbW92ZSBmb3J3YXJkIHdpdGggcmVzcGVjdCB0byBhIHNvbHV0aW9uIGZvciBT UnY2IGNvbXByZXNzaW9uLg0KDQpUaGUgYXBwYXJlbnQgaW5jbGluYXRpb24gb2YgdGhlIHdvcmtp bmcgZ3JvdXAgaXMgdG8gdXNlIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyBhcyB0aGUgYmFzaXMg Zm9yIGl0cyBjb21wcmVzc2lvbiBzdGFuZGFyZGl6YXRpb24gd29yay4gVGhhdCBpcyBwYXJ0IG9m IHdoYXQgdGhpcyBlbWFpbCBhdHRlbXB0cyB0byBjb25maXJtLg0KDQpCZWNhdXNlIG9mIHRoZSBh Ym92ZSB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gaXNzdWUgYSAyLXdlZWsgV0cgY2FsbCBmb3Ig YWRvcHRpb24gZW5kaW5nIE9jdG9iZXIgMTV0aCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24v IGJ1dCB3aXRoIHNvbWUgY2xlYXIgZ3VpZGVsaW5lcyBhcyBmb2xsb3dzLiBCeSBleHByZXNzaW5n IHN1cHBvcnQgZm9yIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgeW91IGFyZSBmdWxseSBhd2Fy ZSBvZiBhbmQgYXJlIGFja25vd2xlZGdpbmcgdGhhdDoNCg0KDQogIDEuICBUaGUgU1BSSU5HIHdv cmtpbmcgZ3JvdXAgaXMgYWRvcHRpbmcgYSBkb2N1bWVudCB0aGF0IGhhcyBtdWx0aXBsZSBTUnY2 IEVuZHBvaW50IGJlaGF2aW9ycy4NCiAgMi4gIFRoZSBkb2N1bWVudCBpcyBhIKGwbGl2aW5nobEg ZG9jdW1lbnQ7IGl0IG1heSBjaGFuZ2UgYXMgaXQgZ29lcyB0aHJvdWdoIHJldmlldyBhbmQgYW5h bHlzaXMgYnkgdGhlIFNQUklORyB3b3JraW5nIGdyb3VwLg0KICAzLiAgQWxsIG9wZW4gZGlzY3Vz c2lvbiBwb2ludHMgcmFpc2VkIG9uIG91ciBtYWlsaW5nIGxpc3QgTVVTVCBiZSBhZGRyZXNzZWQg QkVGT1JFIHNhaWQgZG9jdW1lbnQgaXMgYWxsb3dlZCB0byBwcm9ncmVzcyBmcm9tIHRoZSB3b3Jr aW5nIGdyb3VwIHRvIHB1YmxpY2F0aW9uLiBBIGxpc3Qgb2YgdGhlc2UgZGlzY3Vzc2lvbiBwb2lu dHMgd2lsbCBiZSBkb2N1bWVudGVkIGluIHRoZSBXRyBkb2N1bWVudCBhbmQgbWFpbnRhaW5lZCBi eSB0aGUgZG9jdW1lbnQgZWRpdG9yIGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIGNoYWlycy4NCiAg NC4gIElmIHRoaXMgZG9jdW1lbnQgaXMgYWRvcHRlZCBieSB0aGUgd29ya2luZyBncm91cCwgdGhl IGNoYWlycyBzcGVjaWZ5IGFzIHBhcnQgb2YgdGhlIGFkb3B0aW9uIGNhbGwgdGhhdCB0aGUgZm9s bG93aW5nIHRleHQgZGVzY3JpYmluZyBhbiBvcGVuIGlzc3VlIGJlIGFkZGVkIHRvIHRoZSBkb2N1 bWVudCBpbiB0aGUgYWJvdmUtZGVzY3JpYmVkIG9wZW4gaXNzdWVzIHNlY3Rpb246DQoNCiAgICAg KiAgICJHaXZlbiB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBzYWlkIHRoYXQgaXQgd2FudHMg dG8gc3RhbmRhcmRpemUgb25lIGRhdGEgcGxhbmUgc29sdXRpb24sIGFuZCBnaXZlbiB0aGF0IHRo ZSBkb2N1bWVudCBjb250YWlucyBtdWx0aXBsZSBTUnY2IEVuZFBvaW50IGJlaGF2aW9ycyB0aGF0 IHNvbWUgV0cgbWVtYmVycyBoYXZlIHN0YXRlZCBhcmUgbXVsdGlwbGUgZGF0YSBwbGFuZSBzb2x1 dGlvbnMsIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYWRkcmVzcyB3aGV0aGVyIHRoaXMgaXMgdmFs aWQgYW5kIGNvaGVyZW50IHdpdGggaXRzIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uIG9iamVjdGl2 ZS4iLg0KDQpQbGVhc2UgY29uc2lkZXIgdGhlIGFib3ZlIGd1aWRlbGluZXMgYXMgeW91IGRlY2lk ZSBvbiB3aGV0aGVyIHRvIHN1cHBvcnQgb3Igbm90IHRoaXMgV0cgYWRvcHRpb24uIFBsZWFzZSBl eHByZXNzIGNsZWFybHkgeW91ciByZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9uLXN1cHBvcnQgYXMg d2VsbCBhcyBhbnkgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyB5b3Ugd291bGQgbGlrZSBhZGRyZXNz ZWQgc2hvdWxkIHRoZSBkb2N1bWVudCBiZSBhZG9wdGVkIGludG8gdGhlIHdvcmtpbmcgZ3JvdXAu DQoNClRoYW5rcyENCg0KSmltLCBCcnVubyAmIEpvZWwNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5n QGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KLS0NCg0KW2h0dHA6Ly9zczcudnp3LmNvbS9pcy9pbWFn ZS9WZXJpem9uV2lyZWxlc3MvdnotbG9nby1lbWFpbF08aHR0cDovL3d3dy52ZXJpem9uLmNvbS8+ DQoNCkd5YW4gTWlzaHJhDQoNCk5ldHdvcmsgU29sdXRpb25zIEFyY2hpdGVjdA0KDQpFbWFpbCBn eWFuLnMubWlzaHJhQHZlcml6b24uY29tPG1haWx0bzpneWFuLnMubWlzaHJhQHZlcml6b24uY29t Pg0KDQpNIDMwMSA1MDItMTM0Nw0KDQotLQ0KDQpbaHR0cDovL3NzNy52encuY29tL2lzL2ltYWdl L1Zlcml6b25XaXJlbGVzcy92ei1sb2dvLWVtYWlsXTxodHRwOi8vd3d3LnZlcml6b24uY29tLz4N Cg0KR3lhbiBNaXNocmENCg0KTmV0d29yayBTb2x1dGlvbnMgQXJjaGl0ZWN0DQoNCkVtYWlsIGd5 YW4ucy5taXNocmFAdmVyaXpvbi5jb208bWFpbHRvOmd5YW4ucy5taXNocmFAdmVyaXpvbi5jb20+ DQoNCk0gMzAxIDUwMi0xMzQ3DQoNCg== --_000_CO6PR11MB5650B52988D3B6607BAC1B58ACB79CO6PR11MB5650namp_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

    Hi Gyan,<= o:p>

    &nbs= p;

    Thanks fo= r your feedback. The authors will work on some more illustrations to add in= the draft.

    &nbs= p;

    In my pre= vious email (https://mailarchive.ietf.org/arch/msg/spring/ZfbHtQ1FTqWYqjXqc= FuEf22I2L8/), I provided an example of how the Next-C-SID and Replace-C-SID= flavors could be used together and with different C-SID lengths. Let me restate that, as shown in this exampl= e, there is no least common denominator for C-SID lengths between the flavo= rs.

    &nbs= p;

    As a side= note, could you please use the terminology defined in this C-SID draft or = in RFC 8986/8754? Your emails seem to mix them up and makes it difficult fo= r me to understand your questions.

    &nbs= p;

    Thanks,

    Francois<= o:p>

    &nbs= p;

    From: Gyan Mishra <hay= abusagsm@gmail.com>
    Date: Sunday, 10 October 2021 at 22:23
    To: Chengli (Cheng Li) <c.l@huawei.com>, Francois Clad (fclad)= <fclad@cisco.com>
    Cc: James Guichard <james.n.guichard@futurewei.com>, SPRING WG= <spring@ietf.org>, Yisong Liu <liuyisong@chinamobile.com>, spr= ing-chairs <spring-chairs@ietf.org>
    Subject: Re: [spring] RE    =A3=BA WG Adoption call for https://datat= racker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

     =

    Hi Francois, Chengli &am= p; authors 

     =

    Many Thanks for your fee= dback to the WG on the critical topic interoperability of the uSID micro-si= d 16 bit uSID   =A1=B0NF=3DLocator/Function combo=A1=B1  128 bit&= nbsp;container based solution and the G-SRV6 32 bit G-SID =A1=B0NF=3DLocato= r/Function combo=A1=B1 4 - 32 bit G-SID in 128 bit container based solution defined a= s Next and Replace flavors in the draft.

     =

    I am really concerned as= to how the next and replace interoperability would work for adjacent nodes= using SID within same or adjacent container.

     =

    Section 6.1 mentions tha= t  Next flavor recommendation is for 16 bit as the uSID draft & th= is draft NF as 16 bit is most optimal uSID size within the uSID container a= nd Replace flavor recommendation is for 16 bit as the G-SRV6 draft & this draft N= F as 32 bit G-SID is most optimal G-SID size within the G-SID container.&nb= sp; 

     =

    Please  elaborate on this in more detail, as with thi= s draft for next and replace interoperability, following the SRv6 compressi= on requirements for optimal hardware forwarding and state efficiency that Next would be recommended to use 16 bit SID and = Replace would be recommended 32 bit SID.   Please elaborate in detail = as to why 16 bit is not recommended for replace flavor and 32 bit is not re= commended for next flavor for all of the requirements drafts list of SRv6 compression requirements each one by = one and the problems encountered when not using the recommended SID length.=

     =

    Thus for next and replace flavor interoperability even pos= sible  to work would require two different SID sizes within the same c= ontainer interoperability caveats and now you have to deal with uSID container style using 16 bit SID and G-SID cont= ainer style using 32 bit SID.=

     =

    From the requirements draft,  interoperability perspe= ctive, the primary objective is =A1=B0encapsulation header compression=A1= =B1 as that is what we have spent over a year on with DT finding an optimal compression solution.  So here the lowest commo= n denominator ends up being 32 bit SID and we now have failed the primary o= bjective of a compression solution.   

     =

    As far as lowest common denominator is it true that in ord= er to meet all the requirements draft list of all SRv6 compression requirem= ents both next and replace have to revert to that lowest common denominator which is 32 bit SID.  If that is tr= ue, unfortunately that makes the draft fail the primary objective of any SR= v6 compression solution.

     =

    To that end as far as interoperability on Next and Replace= interoperability being the hinge pin of this drafts adoption, as well even= if the authors state that Replace can use 16 bit SID as a possibility, as the 32 bit =A1=B0NF=A1=B1 G-SID is rec= ommended for hardware forwarding efficiency and scalability that if 16 bit = were used G-SID would fail the hardware forwarding efficiency and scalabili= ty requirements as well as possibly other requirements which should also be stated in the draft.

     

    6.1.  C-SID Leng=
th
     
       The NEXT-C-SID flavor su=
pports both 16- and 32-bit C-SID lengths.  A
       C-SID length of 16-bit i=
s recommended.
     
       The REPLACE-C-SID flavor=
 supports both 16- and 32-bit C-SID lengths.
       A C-SID length of 32-bit=
 is recommended.

     

    The draft should mention the recommendation for comm= on block length for interoperability.  The only block size possible is= 48 bit so block size so that would be a major addressing inflexibility for= interoperability.

     

    6.2.  Block Leng=
th
     
       The recommended SRv6 SID=
 block sizes for the NEXT-C-SID flavor are
       16, 32 or 48 bits. =
 The smaller the block, the higher the compression
       efficiency.
     
       The recommended SRv6 SID=
 block size for the REPLACE-C-SID flavor can
       be 48, 56, 64, 72 or 80 =
bits, depending on the needs of the operator.

     

     

    Taking this further another step as this draft needs= to describe in detail with examples of the feasibility of how two adjacent= nodes one using next 16 bit SID and other using replace 32 bit SID as reco= mmended where the 16 bit uSID next flavor and 32 bit G-SID are in the same SRH 128 bit container.<= /p>

     

    As the uSID Next flavor draft performs a shift towar= ds B towards nibble A, B nibbles, and Replace does a replace of the A-Arg p= ortion  of the 128 bit IPv6 address, how would that work with adjacent= nodes using different SID flavors of different SID lengths.  

     

     

    The Next flavor uSID SRv6 PGM  compression solu= tion process is very different where when indexing the micro sid nibbles wi= thin the 128 bit container, it performs a shift towards the top lower order= bits of the IPv6 address, where the Replace flavor G-SRv6 PGM compression solution indexing the 4 G-SIDs within the co= ntainer does a Replace at the A-Arg bottom higher order bits.  

     

    The referencing of the 16 uSID or 32  bit G-SID=  nibbles, indexing and reference of which nibble to referenced for ne= xt and replace for directly adjacent nodes with nibbles within the same 128= bit container or adjacent containers is the interoperability issue that seems to exist.  

     

    This needs to be clarified on the next snd replace i= nteroperability operation in detail.

     

    Also Replace flavor uses COC delimiter for signaling= compression function is active where Next does not have any signaling of c= ompression being active or not or may have a different way of signaling tha= t upcoming node does not support compression.  

     

    How does the compression signaling interoperability = work between Next and Replace flavors.  That should be addressed as we= ll in the draft.

     

    Kind Regards

     

    Gyan

    Verizon Inc 

     

    On Fri, Oct 8, 2021 at 1:34 PM Francois Clad (fclad)= <fclad@cisco.com> wrote:

    Hi Gyan,

     

    It is possible to combine SIDs of different C-SID flavors and C-SI= D lengths in the same SRH, along with those defined in RFC 8986 After all, = they leverage the same SRv6 data plane.

     

    Let me give you an example.

     

    Assume that an SR source node wants to= send a packet onto an SR path through 10 SR segment endpoint nodes (nodes = 1 through 10), and have a VPN termination for a VRF 123 on a last SR segment endpoint node 11.

     

    The SR source node selects the segments as follows:

    • On nodes 1 through 5, the SID 2001:db8:0:0K01:: (with K being the node ID) = bound to End with NEXT-C-SID flavor and 16-bit C-SID length.
    • On nodes 6 through 9, the SID 2001:db8:0:0K00:0001:: (with K being the node= ID) bound to End with REPLACE-C-SID flavor and 32-bit C-SID length.
    • On node 10, the SID 2001:db8:0:1000:0001:: bound to End (RFC 8986).
    • On node 11, a SID 2001:db8:0:1100:d123:: bound to End.DT4 (RFC 8986) for VR= F 123.

     

    The SR source node then sends the packet onto the SR path by perfo= rming the H.Encaps.Red behavior with:

    • IPv6 Source Address =3D <an address of the SR source node>=
    • IPv6 Destination Address =3D 2001:db8:0:0101:0201:0301:0401:0501=
    • SRH =3D
      • SegmentList[0] =3D 2001:db8:0:1100:d123::
      • SegmentList[1] =3D 1000:0001:0900:0001:0800:0001:0700:0001
        • <= li class=3D"MsoNormal" style=3D"mso-margin-top-alt:auto;mso-margin-bottom-a= lt:auto;mso-list:l1 level2 lfo2"> SegmentList[2] =3D 2001:db8:0:0600:0001::

     

    Therefore, there is no notion of lowest common denominator for C-S= ID length. Based on the deployment requirements= , an operator has the flexibility to select the SRv6 SID flavor and C-= SID lengths of their choice.

     

    We can update the draft with this type of illustrations.

     

    Thanks,

    Francois

     

    From: spring <spring-bounces@ietf.o= rg> on behalf of Gyan Mishra <hayabusagsm@gmail.com>
    Date: Sunday, 3 October 2021 at 21:01
    To: Yisong Liu <liuyisong@chinamobile.com>
    Cc: James Guichard <james.n.guichard@futurewei.com>, SPRING WG &l= t;spring@ietf.org&= gt;, spring-chairs <spring-chairs@ietf.org>
    Subject: Re: [spring] RE=A3=BA WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/

     

    Hi Yisong

     

    The main goal for operators is interoperability.  As interope= rability is the key reason for a single SRv6 compression solution that we h= ave WG consensus and is desired.  

     

    Continued details of the interoperability study  should be ad= ded to the draft as the study progresses.

     

    One key detail that is missing is forwarding efficiency and scalab= ility using NEXT-C-SID and REPLACE-C-SID interoperability using 16 bit SID.=  

     

    As NEXT-CSID uSID Container Micro Segment shift flavor using GIB/L= IB for ultra scale  SRv6 compression solution is recommended for 16 bi= t SID and REPLACE-C-SID G-SID G-SID Container based solution is recommended for 32 bit SID.

     

    Of all the requirements as stated, the encapsulation header size i= s the primary objective for operators to eliminate MSD issues with optimal = forwarding and state efficiencies. 

     

    At this time in order for Next and Replace solutions to be interop= erable keeping in mind requirements for optimal forwarding and state effici= ency 32 bit SID would be the lowest common denominator which should be stated as the baseline result of the an= alysis draft on CSID overall 2 prong solution.

     

    CSID draft:

    Bottom of section 11:

     

     

       T= he interoperability was validated for the following scenario:

     
       o  Packet forwardin=
g through a traffic engineering segment list
          combin=
ing, in the same SRH ([RFC8754]), SRv6 SIDs bound to an
          endpoi=
nt behavior with the NEXT-C-SID flavor and SRv6 SIDs bound
          to an =
endpoint behavior with the REPLACE-C-SID flavor.
     
       Further interoperability=
 testing is ongoing and will be reported in
       this document as the wor=
k progresses.

     

    King Regards 

     

    Gyan

    On Sat, Oct 2, 2021 at 12:56 AM Yisong Liu <liuyisong@chinamobile.com&g= t; wrote:

    Hi Chairs & WG,

     

    I strongly support the adoption call. Regarding= chair's note in the email, I would like to point that the network programming model (RFC8996) by nature defines multiple be= haviors. CSID has a single SRv6 based data plane that defines the next and = replace behaviors consistent with the network programming paradigm.<= o:p>

     

    CSID's next and replace behaviors have been ver= ified by interoperability test in China mobile laboratory and there= is no problem with the interworking of the two behaviors on the CSID datap= lane.

     

    Best Regards=

    Yisong

     

    =B7=A2=BC=FE=C8=CB: James G= uichard

    =CA=B1=BC=E4: 2021/10/01(=D0=C7=C6=DA=CE=E5= )22:04

    =CA=D5=BC=FE=C8=CB: SPRING WG;<= o:p>

    =B3=AD=CB=CD=C8=CB: spring-chairs;

    Dear WG:

     

    The chairs would like to express their apprec= iation for all the responses received to our emails with reference to how t= he working group wishes to move forward with respect to a solution for SRv6 compression.

     

    The apparent inclination of the working group= is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

     

    Because of the above the chairs would like to= issue a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

     

    1. The SPRING working group is adopting a document that h= as multiple SRv6 Endpoint behaviors.
    2. The document is a =A1=B0living=A1=B1 document; it may = change as it goes through review and analysis by the SPRING working group.
    3. All open discussion points raised on our mailing list = MUST be addressed BEFORE said document is allowed to progress from the work= ing group to publication. A list of these discussion points will be documen= ted in the WG document and maintained by the document editor in conjunction with the chairs. <= /li>
    4. If this document is adopted by the working group, the = chairs specify as part of the adoption call that the following text describ= ing an open issue be added to the document in the above-described open issu= es section:
      • "Given that the working group has said that it wa= nts to standardize one data plane solution, and given that the document con= tains multiple SRv6 EndPoint behaviors that some WG members have stated are= multiple data plane solutions, the working group will address whether this is valid and coherent with its one data pl= ane solution objective.".

     

    Please consider the above guidelines as you d= ecide on whether to support or not this WG adoption. Please express clearly= your reasoning for support/non-support as well as any open discussion points you would like addressed should the = document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

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

    --

    Gyan Mishra

    Network Solutions Architect 

    Email gyan.s.mishr= a@verizon.com

    M 301 502-1347

     

    --

    =

    Gyan Mishra=

    Network Solutions Architect&nb= sp;

    Email gyan.s.mishr= a@verizon.com

    M 301 = 502-1347

     

    --_000_CO6PR11MB5650B52988D3B6607BAC1B58ACB79CO6PR11MB5650namp_-- From nobody Wed Oct 13 03:55:35 2021 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 9723A3A0EBD; Wed, 13 Oct 2021 03:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 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, 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=WRJnWwrj; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=yRvteF64 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 bmCaFvIvW9wI; Wed, 13 Oct 2021 03:55:25 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C4CC3A11FB; Wed, 13 Oct 2021 03:55:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25676; q=dns/txt; s=iport; t=1634122525; x=1635332125; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=4dvtETQlLysi1gavRn3Pmk4/1cohLaW3rK9sEsJTDUc=; b=WRJnWwrj0UzgPxPuFLpYKuYdaWar+s0EEHICeuGTw2d+7673tPrfoskU kQq67g/qhL4HUOpHVWjVZkievMzAOFPxdVJncT0FJRw3YOX+J8rlFDLCK z1nC8wGssPDEUrVQ5hAARfW+8PhqQQilawSEaAzMABxiqBkgTXaGHr0E/ c=; IronPort-PHdr: =?us-ascii?q?A9a23=3A02g7zRzl0s4wbc/XCzPDngc9DxPP8537OwcU7?= =?us-ascii?q?twsjLcdOqig/pG3OkvZ6L0tiVLSRozU5rpCjPaeqKHvX2EMoPPj+HAPeZBBT?= =?us-ascii?q?VkJ3MMRmQFzD8uMCEm9J/nvPGQ2Gc1YXwpj+He2eUFeBMf5YQjUpXu/pT4fE?= =?us-ascii?q?xnyL0x7POPwT4XTlM+wkeu1/s67Xg=3D=3D?= IronPort-Data: =?us-ascii?q?A9a23=3A1XIhbKmep7iuRbvroTMsTB/o5gxmJERdPkR7X?= =?us-ascii?q?Q2eYbSJt1+Wr1GztxIaD26FM6zbMGX8Kd9+Ooix9k0DvpXSm9cwHFA5+XtjF?= =?us-ascii?q?1tH+JHPbTi7wugcHM8zwvUuxyuL1u1GAjX7BJ1yHiK0SiuFaOC79CAkjPrQH?= =?us-ascii?q?9IQNcadUsxPbV48IMseoUoLd94R2uaEsPDha++/kYqaT/73YDdJ7wVJ3lc8s?= =?us-ascii?q?Mpvnv/AUMPa41v0tnRmDRxCUcS3e3M9VPrzLonpR5f0rxU9IwK0ewrD5OnRE?= =?us-ascii?q?mLx5RwhDJaulaz2NxZMSb/JNg/IgX1TM0SgqkEd/WppjeBqb7xFNBs/Zzahx?= =?us-ascii?q?7idzP1Dvpi5RS8iP7bHn6IWVBww/yRWbPYepu6WfSbi2SCU5wicG5f2+N11F?= =?us-ascii?q?Fs3O4Jd8eZ+AHtV3f0VND5LaQqM78qt2Ki6TOZEh8k/Io/sJox3knNpyDzCS?= =?us-ascii?q?/BgTo3CSKXD/9Nw0iosm9pDAvvfIcEebFJHcA/JahEJPFoLIJ07leaswHL4d?= =?us-ascii?q?lVlRPi9zUYsy3LYwAo027/3PZ+OPNeLXs5S2E2fowr7E63CKklyHLSiJfCtq?= =?us-ascii?q?xpAXtPyoB4=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A5/dpu6zuBL4Uu1ugjtlbKrPxjuskLtp133?= =?us-ascii?q?Aq2lEZdPULSK2lfpGV8sjziyWatN9IYgBepTiBUJPwJk80hqQFn7X5XI3SHT?= =?us-ascii?q?UO3VHJEGgM1/qY/9SNIVyaygcZ79YdT0EcMqyxMbEZt7eB3ODQKb9Jq7PrnN?= =?us-ascii?q?HK9IXjJjVWPHxXgspbnmFE43OgYzVLrX59dOME/fSnl656jgvlXU5SQtWwB3?= =?us-ascii?q?EDUeSGjcbMjojabRkPAANiwBWSjBuzgYSKUCSw71M7aXdi0L0i+W/Kn0jS/a?= =?us-ascii?q?O4qcy2zRfayiv684lWot380dFObfb8yPT9aw+czzpAVr4RHIFqjwpF5t1HL2?= =?us-ascii?q?xayeUkli1Qe/ibLUmhJl1d7yGdgDUImwxemkMKgWXo8UcL5/aJHg7Tz6F69N?= =?us-ascii?q?5kmtyz0Tt8gDg06tM540uJ85VQFh/OhyL7+pzBUAxrjFO9pT44nfcUlGE3a/?= =?us-ascii?q?pSVFZ9l/1VwKpuKuZLIMs60vFRLMB+SMXHoPpGe1KTaH7U+mFp3dy3R3w2Wh?= =?us-ascii?q?OLWFILtMCZ2yVf2CkR9TpW+OUP2nMbsJ4tQZhN4OrJdqxuibFVV8cTKaZwHv?= =?us-ascii?q?0IT8e7AnHEBRjMLGWRK1L6E7xvAQOAl7fnpLEuoO26cp0By5U/3JzHTVNDrG?= =?us-ascii?q?Y3P1njDMWftac7uiwlgF/NFAgF7/suqaSRloeMMYYDABfzPmzGyfHQ0cn3Kv?= =?us-ascii?q?erL8qOBA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B5AACuumZh/5pdJa1aHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQFAgUYGAQELAYEgMCMuB3daNzGIDgOFOYgLA4p0j3yBLhSBEQN?= =?us-ascii?q?UCwEBAQ0BATcKBAEBhH4CgkgCJTUIDgECBAEBARIBAQUBAQECAQYEgREThTs?= =?us-ascii?q?IJQ2GQgEBAQEDEgsQEwEBJQcLAQ8CAQgOAwMBAiEDCyERHQgBAQQBDQUIEwe?= =?us-ascii?q?CUIF+VwMvAQ6gHQGBOgKKH3iBM4EBgggBAQYEBIFKQYJ/DQuCNQMGgToBgwO?= =?us-ascii?q?EEoEehVcnHIFJRIEUAUOCZz6CIUICA4EjBQESASMeBgeDIoIMIospLzwGCFw?= =?us-ascii?q?EDQ44IAINTBY8DQQHHw8qESmeE41OkURnCoMwgTOJE44/hgUUg2qLbIZGkHu?= =?us-ascii?q?HE451H4xNg0CSMYMKAgQCBAUCDgEBBoFiATlpcHAVO4JpURkPgz6KYgwWFRm?= =?us-ascii?q?DIoRZO4VKdAI2AgYLAQEDCZQVAQE?= X-IronPort-AV: E=Sophos;i="5.85,370,1624320000"; d="scan'208,217";a="930699465" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Oct 2021 10:55:22 +0000 Received: from mail.cisco.com (xbe-rcd-006.cisco.com [173.37.102.21]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 19DAtMvc017521 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 13 Oct 2021 10:55:23 GMT Received: from xfe-rtp-005.cisco.com (64.101.210.235) by xbe-rcd-006.cisco.com (173.37.102.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 13 Oct 2021 05:55:22 -0500 Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xfe-rtp-005.cisco.com (64.101.210.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 13 Oct 2021 06:55:21 -0400 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Wed, 13 Oct 2021 05:55:21 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ylgv9wc1MBNqH90uqKVblVPIr2kkcNzag6pZauU3x5Z43DrRnpfgbZftA9RdXa7OSsdmfO0/La9nMjsrQ18stnJsa8QuUat6qD1uWDcSYIlSmVzUWLzy/c4Kv8zMdPntfQ3QdOB9YzghfXvhd59o/EM1EnUD1oi0jB4rCZsNTz3kUfPO7UuI72QdVTnvQNtaSbh4W2/P4ETqYkp+7R2jNtLUV1rBaBTdPjEu+2yVHijViU9SL2ZNCWjZvps0fG+7eotqBqHdae5CDt71JCsvMX186s+TTEPVmmlbk28fbeUgv65HB+1c0Yz5Y1k0Ag1SigPOYOEDIRohPB6CBfKLuA== 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=Dri5fiV3p0/fbZSNwFwdPvyLxS6Eiz/QzeWgmhYNRGc=; b=ktk8ce7c7SKTAbR2ywZAhws+rLmIRQTZE08vp2J8TAVcx8CVBdKXiySJ/7pRVmoQTfcLS9nkZYvTIkqTnX+LkZKtx+v/ZGerELpYDQ377kbmnpm/+dGFTKyy6zSjgOwCrdnsc0sRmwOP2NqYEoPCHrLvSMVv7djD2Zp3cdg+iS7JCm4iTT6kjGRsBRw01W0qIJ3jiTWr6m6JtOpj7mkYLyys+4oAN2KLZqXPqQlThHFLH6ji/A7qKsZhG504lMyDeZw4n/RIbHP13q8EVosURXsOlXpvCgJOZ5k+x414HfGIKe9tx0EuLy4konpy5fAEtCa3mC/QA4UCgRXopQVjkg== 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=Dri5fiV3p0/fbZSNwFwdPvyLxS6Eiz/QzeWgmhYNRGc=; b=yRvteF64sOTOl3Iy0+iHDnlw3S4i1cSzXidalxbID/pdpGV12NATZm9zbmMv4XAC2bo6WZSYyx6PEWBjpXSU9knWhqrT+ncvwMyRd+klL4wtCD9DlG3bIFA75m12XMK3ER7RPNO5cYUo88Xee8l0ya95CEIZ9To7uIhTxPs30N8= Received: from CO6PR11MB5650.namprd11.prod.outlook.com (2603:10b6:5:35a::9) by CO6PR11MB5635.namprd11.prod.outlook.com (2603:10b6:5:35f::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.24; Wed, 13 Oct 2021 10:55:19 +0000 Received: from CO6PR11MB5650.namprd11.prod.outlook.com ([fe80::6071:7cb6:d30e:b0d]) by CO6PR11MB5650.namprd11.prod.outlook.com ([fe80::6071:7cb6:d30e:b0d%4]) with mapi id 15.20.4587.030; Wed, 13 Oct 2021 10:55:19 +0000 From: "Francois Clad (fclad)" To: Tarek Saad , James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQFKdpbcABx8r/YASPmz5QClQ3X1 Date: Wed, 13 Oct 2021 10:55:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7d3d68da-040d-43f8-94fb-08d98e37f271 x-ms-traffictypediagnostic: CO6PR11MB5635: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BotOCbJicr5qXLlCONoUZyBIdxTkHmiBY7/GcrN4r286I9PgN7AXHzqbuf6SwVNoqK4opBclNrxdc5YGt6PW74YVaFVqqKhbnNmuKTKiEUOxrHNwnwhb17V5AgQtA2VH/RAsyCZaeenjVRvrpPS1LLldrhbRNACP8PMJjZ7N5qTb/9hZad/qJhnpmpLUtnzTLPTf8bwC+0tf50fda4X0m6PlCYhtZoEWpApaUWtMrP7ZLEaZYpbDhPAsVlpQUSIjnA/ZuNEWLy7q1pqEBu9/1ugyzxxPW5u/F8aFaAqUNJ64kepV2yegBxn5C0jTXX4YkuSoQvVv6ObgK3VxCWK85J2Eku+Y30O8i0I05cqnpuCYSjOL5V/TOZ+JVeojxrL15LfE9+DsiY/qWuKn59fYzRZidTNCwEwrJkaqMddMcdGSLRmE4w5Bn4cif1WK645WHDmHhQRHmLl2Aghc3ddqb19xrjYiReqH5Kuxx85IXI3neZoOySDCgNiWmiJZsogdZP2L40tzM5aNtrHHcuHc0iFQ6wigo0NU7Mhbj9MU7BiEkMtKGiYyUfkdsYpldzbqAprLjobEAhHvKO4eEF/iZiOwZoqcp9QvsdmnAr7/w9mu4TR8zekEH4nXStYfFaXOm5Rt5yhNOWd0R7OYOrslH+VAN9npvz+WW08Kd4JStGq/S3e8Jquc6Obo9jtjhm4yUH6YiGCa/F8R05M+MRchjyaJ38YE37sMrJavX96tOhx1VJUr0H6ZQO+Tc9bZMcHCqO3M4SP8dMHcd+2GEP6gZGPm59wODUKSSMfULmBqm+U= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR11MB5650.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(9686003)(186003)(55016002)(5660300002)(966005)(71200400001)(166002)(6506007)(7696005)(91956017)(76116006)(4326008)(66556008)(64756008)(52536014)(110136005)(8936002)(33656002)(66476007)(38070700005)(66446008)(66946007)(83380400001)(53546011)(26005)(122000001)(38100700002)(86362001)(316002)(508600001)(8676002)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?qstVj7Kg2N0Th00z/7CtEsCswaPpoFC7ZhDDggWTg3NP32howu9Lsy6D?= =?Windows-1252?Q?wVtyqDN/eOWmI41qzugdsqp0vJtcZXw+q8DXis0MzqlnoexUannYtFn2?= =?Windows-1252?Q?bRfpuZAvZ4nl5lYVItIxBi5qmklpC1ayxVwdPfg+x0leNoXbRP4uwUtm?= =?Windows-1252?Q?XQ9p6A3yann4aQb524k/wZwvf544CEE44TSmWDVKoTawJIwNj2j7fYTv?= =?Windows-1252?Q?43SUskTHgZ+EdG03q4oDHI0Tihy7HrTrfAwR4+WlMrZEPW00imMOQdz8?= =?Windows-1252?Q?tYACazRlG94NjRlzyOMGdyCO3V8TDTvXixA2I62SE0a+R9+zK5WQya9g?= =?Windows-1252?Q?yZqFeRCgQUWxLGkQTfbYqrOzDfalg1ohlkgZlWrU5y8iNvT9EGtXEk8i?= =?Windows-1252?Q?mElQ5VhezBYhDGTmuBVslBJY97WAFIOd9sNIoled1u4Z9mbdWr9ayaL6?= =?Windows-1252?Q?H4ZcUJTRmGuSQRo+YMJNVxddAhhYVHVejgbLmP2FCYENU+DBmrnNmtSq?= =?Windows-1252?Q?b5sf6FjTV4+2qDogLelR+4Jh5m6TOfEgCQTdc7SicxH2nbHlLXuCUuLJ?= =?Windows-1252?Q?KLg0Dn09pgVQ6zTy71WSI5a4c3c1zvlxtHUYGRBTRz/45y+KIpnxWF7o?= =?Windows-1252?Q?U7xp0k0zlZwkIaw8Pz2rVwH9I4jXpcu2lJ1FiWdThYEZukNv1AZ/IJ4V?= =?Windows-1252?Q?E+PZU/HyuDEEHMHoSmMcFG0RKubswJaTxaPShJxGqs7+TJi19jKMXqyP?= =?Windows-1252?Q?Zl7ltm38hkfr6FVUA4uxutJ4jE4S4UYlz29u6ihC8ZMIt3ZkTdKJ6U9N?= =?Windows-1252?Q?cBAIK24W1jtOBhFzzuaMzboiCW4C3RHYXdLQkyjAJfVGjeNitzJ6UK6q?= =?Windows-1252?Q?EC9Msr5t4qRFGI+PyhFHzYIs7TmnpEZTLzs1hEhcCa9C4HZN5Po/mN13?= =?Windows-1252?Q?ip1pZSxHMUy9sqThdsolVkFBZO2jlkDfLGyRq52yNmyw82eUcIr1EX5l?= =?Windows-1252?Q?1SHpS5D5ja/Ba1fOqMhkStLzvXkWDDCu17y9jy0bdh6/BB1eemkyqcTd?= =?Windows-1252?Q?vvpF0W4qDAxXMORIMgUrzb5N5xioHr+FjczmQjbKFtX7vDqV0lG11Fz2?= =?Windows-1252?Q?gY+GOP4RMf5oehfNzyv/gCKLgc5CbWAa4JP+Hk+j35AK6+dIK5s9+vAn?= =?Windows-1252?Q?34zA3rBF0NFUtg0BYFwWbRIGM1BNWL9eMDiB8C37jUYkBTmHXdUZkL4d?= =?Windows-1252?Q?69ov2nNBW0Dozr1ncKFtpvhMYZw+3EqLFqdgr6MFZYEic+pCvS38mY/i?= =?Windows-1252?Q?O4mbSPb36H7C4m9O5H0gYYiktGJ23seinfQxuOtbFyrwC5w1VXi4Ngn5?= =?Windows-1252?Q?FWAeTIxNQ4U/vfAE8xp+M74UKDO8B7RNnWqs4idLAQX4tknC3A3LK+ct?= =?Windows-1252?Q?dPduPos11NFLFCb0/EFm7A=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO6PR11MB5650BE13ACFBDB5EB7CED10CACB79CO6PR11MB5650namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO6PR11MB5650.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7d3d68da-040d-43f8-94fb-08d98e37f271 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2021 10:55:19.0645 (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: 5ii5u7xNzI4j+E7CrgrSLdlfgss05ySvMlj48T9k3yEm+dw5+IYGzauk/wfwypjK X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR11MB5635 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.21, xbe-rcd-006.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 13 Oct 2021 10:55:33 -0000 --_000_CO6PR11MB5650BE13ACFBDB5EB7CED10CACB79CO6PR11MB5650namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Tarek, Section 4.3 of RFC 8754 indicates that a locally instantiated SID is identi= fied based on the result of an LPM lookup on the packet=92s destination add= ress. That SID has a behavior that determines how the endpoint node should = process the packet. The C-SID draft does not change how the endpoint node identifies a SID. Could you provide an example showing the kind of inference or collision you= are referring to? Thanks, Francois From: Tarek Saad Date: Sunday, 10 October 2021 at 06:06 To: Francois Clad (fclad) , James Guichard , SPRING WG Cc: spring-chairs@ietf.org Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/draft-fi= lsfilscheng-spring-srv6-srh-compression/ Hi Francois, Thanks for your responses. Please see inline.. From: Francois Clad (fclad) Date: Friday, October 8, 2021 at 1:14 PM To: Tarek Saad , James Guichard , SPRING WG Cc: spring-chairs@ietf.org Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/draft-fi= lsfilscheng-spring-srv6-srh-compression/ Hi Tarek, I am assuming that the border node is an SR segment endpoint node in your q= uestion. [TS]: yes. This node processes the packet according to the behavior bound to the local= ly instantiated SID that was matched (see Section 4.3 of RFC 8754). There i= s no interpretation required. [TS]: consider the case that two locally instantiated SIDs (carried in the = DA) can match =96 like SID1 is contained within SID2 (or vice versa). Absen= ce anything present in the encoded SID-sequence, how can this node reliably= infer whether it is G-SID sequence or a C-CSID sequence? It is the responsibility of the SR source to make sure that the SIDs in the= Segment-List are used appropriately. This applies to all SRv6 SIDs, includ= ing those defined in RFC 8986. It is the same as ensuring that there is not= an End.DT4 SID in the middle of the Segment-List or that an End.X SID boun= d to the right interface is used. [TS]: I=92m not sure it is solely a SR source responsibility. There is some= responsibility that the node allocated the 2 kinds of SIDs that need to en= sure no such previous collision can ever occur, no? Regards, Tarek Thanks, Francois From: spring on behalf of Tarek Saad Date: Friday, 8 October 2021 at 06:06 To: James Guichard , SPRING WG Cc: spring-chairs@ietf.org Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ Hi all, I=92ve read this draft. It is proposing 2 different encodings schemes for c= ompressed sequence of SRv6 SIDs (and an optional behavior on border nodes).= . Although Section 4 makes a claim that different deployments usecase may dee= m one encoding scheme superior over the other, I could not glean in which c= ases a scheme would outperform the other and why? Or, why is the WG trying = to standardize both the two flavors -- keeping in mind the complex HW proce= dures evident by the proposed different pseudo codes in the draft. Also, are there concerns of misinterpreting (wrongfully decoding) a GSID se= quence for a C-SID-sequence (or vice-versa) for a received packet on border= nodes that may support both encoding flavors simultaneously? For these reasons, I think this it is still premature for this draft to be = adopted, and I oppose its adoption. Regards, Tarek From: spring on behalf of James Guichard Date: Friday, October 1, 2021 at 10:05 AM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis= for its compression standardization work. That is part of what this email = attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as fol= lows. By expressing support for adoption of this document you are fully awa= re of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a =93living=94 document; it may change as it goes thr= ough review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_CO6PR11MB5650BE13ACFBDB5EB7CED10CACB79CO6PR11MB5650namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    Hi Tarek,=

    &nbs= p;

    Section 4= .3 of RFC 8754 indicates that a locally instantiated SID is identified base= d on the result of an LPM lookup on the packet=92s destination address. Tha= t SID has a behavior that determines how the endpoint node should process the packet.

    &nbs= p;

    The C-SID= draft does not change how the endpoint node identifies a SID.

    &nbs= p;

    Could you= provide an example showing the kind of inference or collision you are refe= rring to?

    &nbs= p;

    Thanks,

    Francois<= o:p>

    &nbs= p;

    From: Tarek Saad <tsaa= d.net@gmail.com>
    Date: Sunday, 10 October 2021 at 06:06
    To: Francois Clad (fclad) <fclad@cisco.com>, James Guichard &l= t;james.n.guichard@futurewei.com>, SPRING WG <spring@ietf.org>
    Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
    Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/d= raft-filsfilscheng-spring-srv6-srh-compression/

    Hi F= rancois,

     

    Than= ks for your responses. Please see inline..

     

    From: Fran= cois Clad (fclad) <fclad@cisco.com>
    Date: Friday, October 8, 2021 at 1:14 PM
    To: Tarek Saad <tsaad.net@gmail.com>, James Guichard <james= .n.guichard@futurewei.com>, SPRING WG <spring@ietf.org>
    Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
    Subject: Re: WG Adoption call for https://datatracker.ietf.org/doc/d= raft-filsfilscheng-spring-srv6-srh-compression/

    Hi Tarek,

     

    I am assuming that the border n= ode is an SR segment endpoint node in your question.

    [TS]= : yes.

     

    This node processes the packet = according to the behavior bound to the locally instantiated SID that was ma= tched (see Section 4.3 of RFC 8754). There is no interpretation required.

    [TS]= : consider the case that two locally instantiated SIDs (carried in the DA) = can match =96 like SID1 is contained within SID2 (or vice versa). Absence a= nything present in the encoded SID-sequence, how can this node reliably infer whether it is G-SID sequence or a C-CSID = sequence?

     

    It is the responsibility of the= SR source to make sure that the SIDs in the Segment-List are used appropri= ately. This applies to all SRv6 SIDs, including those defined in RFC 8986. = It is the same as ensuring that there is not an End.DT4 SID in the middle of the Segment-List or that an End.X S= ID bound to the right interface is used.

    [TS]= : I=92m not sure it is solely a SR source responsibility. There is some res= ponsibility that the node allocated the 2 kinds of SIDs that need to ensure= no such previous collision can ever occur, no?

     

    Rega= rds,

    Tare= k

     

    Thanks,

    Francois

     

    From: spri= ng <spring-bounces@ietf.org> on behalf of Tarek Saad <tsaad.net@gm= ail.com>
    Date: Friday, 8 October 2021 at 06:06
    To: James Guichard <james.n.guichard@futurewei.com>, SPRING WG= <spring@ietf.org>
    Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
    Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.= org/doc/draft-filsfilscheng-spring-srv6-srh-compression/    <= /p>

    Hi a= ll,

     

    I=92= ve read this draft. It is proposing 2 different encodings schemes for compr= essed sequence of SRv6 SIDs (and an optional behavior on border nodes)..

    Alth= ough Section 4 makes a claim that different deployments usecase may deem on= e encoding scheme superior over the other, I could not glean in which cases= a scheme would outperform the other and why? Or, why is the WG trying to standardize both the two flavors -- keepi= ng in mind the complex HW procedures evident by the proposed different pseu= do codes in the draft.

     

    Also= , are there concerns of misinterpreting (wrongfully decoding) a GSID sequen= ce for a C-SID-sequence (or vice-versa) for a received packet on border nod= es that may support both encoding flavors simultaneously?

     

    For = these reasons, I think this it is still premature for this draft to be adop= ted, and I oppose its adoption.

     

    Rega= rds,

    Tare= k

     

     

    From: spri= ng <spring-bounces@ietf.org> on behalf of James Guichard <james.n.= guichard@futurewei.com>
    Date: Friday, October 1, 2021 at 10:05 AM
    To: SPRING WG <spring@ietf.org>
    Cc: spring-chairs@ietf.org <spring-chairs@ietf.org>
    Subject: [spring] WG Adoption call for https://datatracker.ietf.org/= doc/draft-filsfilscheng-spring-srv6-srh-compression/

    Dear WG:

     

    The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a sol= ution for SRv6 compression.

     

    The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

     

    Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

     

    1. The SPRING working group is adopting a document = that has multiple SRv6 Endpoint behaviors.
    2. The document is a =93livi= ng=94 document; it may change as it goes through review and analysis by the= SPRING working group.
    3. All open discussion point= s raised on our mailing list MUST be addressed BEFORE said document is allo= wed to progress from the working group to publication. A list of these discussion points will be documented in the WG document and maint= ained by the document editor in conjunction with the chairs.
    4. If this document is adopt= ed by the working group, the chairs specify as part of the adoption call th= at the following text describing an open issue be added to the document in the above-described open issues section:
      • "Given that the working group has said that it wants to standar= dize one data plane solution, and given that the document contains multiple= SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution obj= ective.".

     

    Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open d= iscussion points you would like addressed should the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    --_000_CO6PR11MB5650BE13ACFBDB5EB7CED10CACB79CO6PR11MB5650namp_-- From nobody Wed Oct 13 03:56:55 2021 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 0C9D43A1596; Wed, 13 Oct 2021 03:56:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, 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=PAre9M5u; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0OCdpMR3 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 I74jlYVcETDU; Wed, 13 Oct 2021 03:56:49 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBB833A15BA; Wed, 13 Oct 2021 03:56:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43733; q=dns/txt; s=iport; t=1634122605; x=1635332205; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=i9thjx4Fxi35EhKHv7+LEyXI4egDYLJCGr5bSA0qx9E=; b=PAre9M5uNs/dg2FgXn42+OIEtv7HH9nnECwKf2qFxTSmHdwHSqXbrRnS LsF0RNITnkfXcXomT3TOEMxO+To/uIF1kEeSTPVMUghWxh3E3T+9b491i Wu4Ea9dgr0cSPUYwejPQfzJa9HN6Xja08rHaW1O1WHcuNazdemi+ZpY25 8=; X-IPAS-Result: =?us-ascii?q?A0AZAAATu2Zhl4wNJK1aHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?UUHAQELAYEgMFF+WjcxiA4DhFlgiAsDinSPfIEugSUDTwULAQEBDQEBKgEMC?= =?us-ascii?q?gQBAYQ5RQKCSAIlNAkOAQIEAQEBAQMCAwEBAQEFAQEFAQEBAgEGBBQBAQEBA?= =?us-ascii?q?QEBAYEIhWgNhkIBAQEBAwEBEAgDEBMBASwEBwEPAgEIEQMBAiEBAgQHIQYLF?= =?us-ascii?q?AkIAgQOBQgTB4JPAYF+VwMvAQ6gGwGBOgKKH3iBM4EBgggBAQYEBIE2ARNBg?= =?us-ascii?q?n8NC4I1AwaBOgGDA4QSgR6FVyccgUlEgRQBQ4FmgQE+giFCAQECAYFfHgYHC?= =?us-ascii?q?YMZggwiiygBawYCBRtCBDIREC8sIAUFSBELAhg6OpE/jFSeVhQoZwqDMIEzh?= =?us-ascii?q?0SBT4gehSR9hgUUg2pCiyqFVZFshxOOdYxsg0CQOg6EcwIEAgQFAg4BAQaBY?= =?us-ascii?q?TmBW3AVO4I1AQEyURkPiEuFVQwNCRUZgyKFFIVKdAI2AgYLAQEDCZQVAQE?= IronPort-PHdr: A9a23:q8jPwxSieZyiyn0yDQmpBV9VhNpso6HLVj580XJvo71Le6WnuZ/lO R+X6fZsiQrPWoPWo7JBhvHNuq/tEWoH/d6asX8EfZANMn1NicgfkwE6RsLQD0r9Ia3laiU7G IJJU1o2t32+OFJeTcD5YVCaq3au7DkUTxP4Mwc9Jun8FoPIycqt0OXn8JzIaAIOjz24MttP IronPort-Data: A9a23:vXMXlK7zZSffME/ZP7DrgAxRtMPHchMFZxGqfqrLsTDasY5as4F+v msYUTqFPv/cMzH2L4oladi190xQu5OExtRrSAZrpCxgZn8b8sCt6fZ1gavT04J+CuWZESqLO u1HMoGowPjZzRYwnz/1WlTbhSEUOZqgG/ysVYYoBggrHVU9EX940ko68wIEqtcAbeaRUlvlV eza+6UzCHf9s9KjGjtJg04rgEoHUMXa4Fv0jHRnDRx4lAO2e00uMX4qDfrZw00U7WVjNrXSq +7rlNlV945ClvsnIovNfr3TKiXmTlNOVOSDoiI+ZkSsvvRNjm9v04J8L8AzU3pGli+AlfVKy tFnkZPlHG/FPoWU8AgcexBcFyc7Nqpc9fqYZ3O+qseUiUbBdhMAwd03UxpwZtNeo70xWD0Wn RAbAGhlghSriemyyb6TQeh3jcNlJ87uVG8aki4wkWGBVa53HvgvRY3g7uJFhhMT3/xwBP+Ge /cLRzNUYQz5Nkgn1lA/UcJiw7jAamPEWyZAslOTqu8842HS1hdZ0bXxPpzSYNPibd5NhEeeq UrH8nj3RBYAO7S3yzOA/2nqgKnAgCLwWIsIGJW26+J3mlCMy21VAxoTPXOhq/6/i0W3Do4HK VES+zIjt+40+VCDQtz0RRb+oXOYsFgbQdU4O/c94gyX1oLO6h2LG2tCSDNdAPQprsI5RDkrz ESKjvvmADVutPueTnf1y1uPhTq2PS5QJmgYaGpbCwAE+NLk5oo0i3ojU+qPDob209zRXirK7 Aq3vTUkjr82tswP/YG0qAWvby2XmrDFSQs85wPyV22j7x9kaIPNW2BOwQWFhRqnBNvFJmRtr EToiODFt7lXUs/leDilBbRTQu74vp5pJRWB2TZS848dGyNBEpJJValU5Dx4TKuCGplZIWayC KM/VP842XO+FHKuaakyaIWrBoF1i6PhDt/iEPvTa7Kig6Sdlifap0mChmbJgggBdXTAd4lkZ f93lu73VB4n5VxPlmbeegvk+eZDKtoC7W3SX4vn6B+szKCTYnWYIZ9cbgDSNr5isPvV+VmEm zq6Cyds40sHOAEZSnSImbP/0XhRRZTGLcms8pcOJrLrzvROQTt8W5c9Po/Ni6Q8z/gKyY8kD 1m2W1RTzxLklGbbJACRAk2Pm5uxNauTWUkTZHR2VX7xgiBLSd/2sM83KspsFZF6pbML5aAvF ZEtJZ7fasmjvxyaolzxm7Gm9Nw8HPlq7CrTVxeYjM8XJsY6GVOSoIO4J2MCNkAmV0KKiCf3m JX4viuzfHbJb10K4Br+AB53826MgA== IronPort-HdrOrdr: A9a23:Wzv5Lqqb58jtyOqtqlJsHsgaV5uJL9V00zEX/kB9WHVpm5Oj9v xGzc506farslkssSkb6K+90KnpewK6yXcH2/huAV7CZnimhILMFuFfBOTZskbd8kHFh4tgPO JbAtRD4b7LfBhHZKTBkXOF+r8bqbHtms3F9ISurUuFDzsaFp2IhD0JbDpzZ3cGPDWucqBJba Z0iPA3wwaISDAyVICWF3MFV+/Mq5ngj5T9eyMLABYh9U2nkS6owKSSKWna4j4uFxd0hZsy+2 nMlAL0oo+5teug9xPa32jPq7xLhdrazMdZDsDksLlWFtyssHfsWG1SYczEgNkHmpDo1L/sqq iUn/4UBbU215oWRBDsnfKi4Xi67N9k0Q6S9bbRuwqSnSW+fkNhNyKE7rgpLicwLCEbzYxBOe twrhGknosSAhXakCvn4d/UExlsi0qvuHIn1fUelnpFTOIlGfJsRKEkjQho+a07bWjHAUEcYZ 5TJdCZ4OwTfUKRbnjfsGUqyNuwXm4rFhPDRkQZoMSa3zVfgXg8liIjtYMit2ZF8Ih4R4hP5u zCPKgtnLZSTtUOZaY4AOsaW8O4BmHEXBqJOmOPJlbsEr0BJhv22tLKyaRw4PvvdI0DzZM0lp iEWFREtXQqc0arEsGK1I0jyGGEfIx8Z0Wl9ih63ek2hlTRfsufDcSzciFZryL7mYRsPiTyYY fGBK5r X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.85,370,1624320000"; d="scan'208,217";a="784800097" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Oct 2021 10:56:43 +0000 Received: from mail.cisco.com (xbe-rcd-001.cisco.com [173.37.102.16]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 19DAuh2Y030948 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 13 Oct 2021 10:56:43 GMT Received: from xfe-aln-003.cisco.com (173.37.135.123) by xbe-rcd-001.cisco.com (173.37.102.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 13 Oct 2021 05:56:43 -0500 Received: from xfe-aln-003.cisco.com (173.37.135.123) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Wed, 13 Oct 2021 05:56:42 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Wed, 13 Oct 2021 05:56:42 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UopoIkaJNfScwJpvJap0nAc9K8+rdpoTMec9KyQ32cosOHJN5odelCfPvodIM5E7f7v5lmQpkeIa570SxJtKtNCznhfVZW/m4g9OXdnuPvZBTQ/zfG8THO5NolYRRp5oeLoKcndNZny+W5KIbvmbs7b479RG5JeeWXf8Op/ehUP0Wi1uWtoBAq6f7gMiYhoNFRk4q5ZdVx/k0v0f9qwLoi2fFkJYmZ64jo1qg6Fn1oPIZwPyJnMv2nKRk3lI1o293UhzHPwv8y3z8kao/pSt53VoHaZ7chQ2PY5kD6ZYQWcF+iAwoHpkDsSkFxFa0DZT/vERimv84hAKMBk8xNsPog== 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=GyOczMZJ5wjGeE3tzJqJggpMSLm4lu9ACMVlbP4TnFg=; b=Q8m4Fy5NZ46xP0REo91u/6xnONUrhTsHiIEd6XUTU1M4hxaBqFEqxauIm4pBkIU+O18zw8j3OVZaqQzy1qHot+qrMaAkqxhj+VnKqmA6F6n11NSd1uXl0VEADTPzPsu435uFUExuXlCcwIXA+Jb3l4mYxOXkpf7fSyMoHhcyemxy09ZL6yhOpeaxj6TlTHC5OaldTsB/I2E7dlqDKw/oWsddcq3+WWz7w5CqsGEjUs4/flTJVtn3JqqWhbVCnNYundrzW/ibfpaq+y3xg+ckZTStrXWHg4at8U/u3S/9/XTFttTsPdCxXgW6/78YzZwc0ZUQacHCQ2znQO4C5FenuA== 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=GyOczMZJ5wjGeE3tzJqJggpMSLm4lu9ACMVlbP4TnFg=; b=0OCdpMR3kMzHxVWg5e5F9Z9hTT/vxLO8JmdstivuhLmUB1GDqXhBss2ArR335BbWkTRzsrm2DuDAYzasq+t3TqV0tC91jfCHpm0+bDG0wHBEm8S6VJXrm63JQMjDBfPp19ZOUCEFO3fxISIuVR115nKLm2qbV/NY2Tl1ef+b6HA= Received: from CO6PR11MB5650.namprd11.prod.outlook.com (2603:10b6:5:35a::9) by CO6PR11MB5666.namprd11.prod.outlook.com (2603:10b6:303:13a::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.20; Wed, 13 Oct 2021 10:56:41 +0000 Received: from CO6PR11MB5650.namprd11.prod.outlook.com ([fe80::6071:7cb6:d30e:b0d]) by CO6PR11MB5650.namprd11.prod.outlook.com ([fe80::6071:7cb6:d30e:b0d%4]) with mapi id 15.20.4587.030; Wed, 13 Oct 2021 10:56:41 +0000 From: "Francois Clad (fclad)" To: Greg Mirsky CC: Robert Raszuk , Ron Bonica , James Guichard , SPRING WG , "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQCeJTAAAC58nBAAAQ3tgAAHRGEgAAHK+wAAAookgAAiGUeHAAc4nAAAMAjOBAAENzmAAC/Wf/0ABtmXAADntdyT Date: Wed, 13 Oct 2021 10:56:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5e12980b-2068-43d4-df99-08d98e382351 x-ms-traffictypediagnostic: CO6PR11MB5666: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tGANIewbPrlWyyCpHLPpUpZSVwY5WG1R5uKgnDKuCMJpca5U4z/NGw/AMOUMNcu/iAUWnMAKWNtyYeAzTd7Fv05ZzIB2jMrxCgSjdZ4IHufE1i5GvfFsAGrkQwewUpE9jRwNGKzikY/XSdMyukvRjWWsDdAK0EbP9xP9FdEQrwjcy2IGpQwB0SWM0Skmp5npQb+BN39nh8NmVL9y66d5erWGYj8c9pqSZeUaHh0QKPYGhZbuIQ8j1bi/Rpr0G3pLfRAvOUmkUai9KnbOvXC6XgtlgOcBGdC79gCCuJpD9WYcx7Wp37cxtMFisUQUw+wo0Ia53jLCoPNoZV47EXEW/fxI+wZGhBQbR2WxV7lNW9wjHNASWbOQsg50p420ToekJF5iQ6sKC+XVhiupegrT6Im3t8P/aSLHH2ClKvAVg/jvPZJ5U8cWms9VlrLiJTDtYGO4egnoBmel2BrJPoqVgH7IHqSBCN8q0FxfN7yMGLVR8U8GTsthxmYkwOYoa594Ta/U32ZzGOfVDrMh3hnnTf5TJBkyexQsz8o4R3Pah6I5PmksNficmWdIahBOlc8pYXrTBfshiIDI0OyL3UPnvucUb6gzkFEEQ1RrZejSWkNVtjGT4F4elFLvJUak1ESZgQsAXfBQL6y1/RqZdfWtz1JapjPiekSrJQVuSGJ4FsbUqhMExNufl4NkaCEz9Cfr+ZcU2p0x+LfQgk2Zz3NHpLirCqpKPD0+BTjephgTQWOBUOFYxwoLWZaJOEpVssKGPDxrrK5DwLuyRv/4lIQGFhzqxE9ElNCM2w2CQPDXMQpVly2ySU6wvwmJ1bAXQZGh/e7ev8SH0XXIx3U+MXHvzg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR11MB5650.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(2906002)(8676002)(186003)(122000001)(4326008)(26005)(8936002)(6506007)(316002)(86362001)(38100700002)(5660300002)(33656002)(30864003)(66556008)(83380400001)(76116006)(71200400001)(53546011)(508600001)(966005)(64756008)(9686003)(66446008)(6916009)(52536014)(7696005)(38070700005)(91956017)(66476007)(55016002)(66946007)(54906003)(166002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?IL5fGaFhlyn0OaovaJXU5RfqqVWpR3iIFxPcnnSJH3YTQ/czDwhe1712s0lL?= =?us-ascii?Q?M5Wgckon6b82cwnzBijLqf2GDcvouBHBfocJDZ4fIKwBFJK4hcfZ9k/Wuz1j?= =?us-ascii?Q?NXvRWGg1osvsZtOytkbVuHP6k/DQefzTUDmv40IrWH3aA9tpYTaan7JR+I6Z?= =?us-ascii?Q?hN9ztQ4cvV4x7pQe9qRF2z5U1/F5+dwcnLKWduyNFcO6/JYqQOJ1YLdLVIzy?= =?us-ascii?Q?MgBs1PGoiO1pf/TIEgLXwSh7B9GCyqvDu5DCnmbJS8t3zsAVkNkSvKjTUPAM?= =?us-ascii?Q?mW/g2Qw2g/I8M2ZIUNp7ApREmsIz6ioKpK8MTePdRA5nr2z5RYU4jaM5H8Id?= =?us-ascii?Q?E+1oP/mTRdQ45QMa6bojEYVQpxuxN0K1o2RrIyYYXlo6P4pdURqKO7e7A5bE?= =?us-ascii?Q?VXZsN9WBqfelstt08eYFJjfZ24E7A8TOzqPW7QvNQmd103JipSr9FAucAiUc?= =?us-ascii?Q?04I06j0yukixCdlO9t2Ol+fHtVhO4tdvt2+F20TjOvxtkM/hQsW3vamtU4So?= =?us-ascii?Q?JqZqS8NEtDRwqGV1mdfjh0xx11f0u7Rwpxm/HVZ4ryE4Vr72IChvoqX/EHaR?= =?us-ascii?Q?cmVfsZGxsFqI2gVJqANo1XC4RKnfTHuiY29hHomstpIJvLb3F10m6Y7jSS3b?= =?us-ascii?Q?DP1uaYs4SW/fzo6mUA6zHmQ48BIifVcA6LlUAx75A/ePsjVBmZp4UM62PnpI?= =?us-ascii?Q?ym5RNvkF9lkuXc3ygNeP9Lh5VdlFe0SesynMXeE/ECIs/YUblltciuT7ybXW?= =?us-ascii?Q?hCQDanGBP3cNMshw0KmKcJ9OnjQX9xta1Q8n0+qm4fTWh5/8Ss+cGrquFnmh?= =?us-ascii?Q?y7veoxZG1Gz15d4y37BKX9JkPOs0+mG+l+Wo2byxkbiUjMioV98Irfyzi4XD?= =?us-ascii?Q?Z7LU3SREik65Bt8SGqtXGOpAVqCqauyV/DVLkos+K9Y/pG59eoYHcqnskEgY?= =?us-ascii?Q?o6oFYnlXZBRIbtUi4PCAGwpAtPLZWzhdAgH2u4JhSN9mExviXgNAfEIuYtbG?= =?us-ascii?Q?QgwEVr3cIkbSSk/lELK5eZ8eQ7inXHqTOYB0TfeXzkl6Tb2nKswIdB4jktxW?= =?us-ascii?Q?6K773YNblGIvKfZqrP60synMCLB14PKJIHGoucY1f6RRx/IPaQATRyyH9huG?= =?us-ascii?Q?6eJlYAxfkWXU5FSiKRNlDl7crL2763+/3HOdxXrFfoizldXCkhSEM9VTueY4?= =?us-ascii?Q?GfWEf2GS5xhSR8hoLV+iQ6vIR2aeKt26gFVUvyTpluSqgA90XG7WV4n3gucX?= =?us-ascii?Q?27GJjnLD0cW2lPcSPzUMHfmDgEyPdRe77BzvgF6q966VSvNFZQU0zaiA0QdJ?= =?us-ascii?Q?rkTY6PWV27BmEA+PDMJ8KDprvyRR2XT+qbtzTRlOT6XWHA=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO6PR11MB565063F24696D8B96D2276B6ACB79CO6PR11MB5650namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO6PR11MB5650.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 5e12980b-2068-43d4-df99-08d98e382351 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2021 10:56:40.9814 (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: DcYzTXH/+Ov1bziSU+iPa4cn4Ccd+/M/yv0/R6n6CLrOG/ENAndd0LiP61qdbpU0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR11MB5666 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xbe-rcd-001.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 13 Oct 2021 10:56:54 -0000 --_000_CO6PR11MB565063F24696D8B96D2276B6ACB79CO6PR11MB5650namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Your understanding is correct. The C-SID flavors cannot be randomly mixed w= ithin the same C-SID container. We can clarify the details related to the combination of flavors in a C-SID= container in an upcoming version of the draft. For example, the last entry= of a C-SID container can carry a C-SID bound to any behavior, including on= e with another C-SID flavor. Thanks, Francois From: Greg Mirsky Date: Friday, 8 October 2021 at 22:21 To: Francois Clad (fclad) Cc: Robert Raszuk , Ron Bonica , James Guichard , SPRING WG= , spring-chairs@ietf.org Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ Hi Francois, you've said that different flavors of C-SID can be present not only in the = same SRH but also in the same C-SID container. The latter case got me think= ing about several potential scenarios. Have to admit that I got stuck tryin= g to understand how they can work. I hope you can help me out. Please consi= der the two cases described below. Consider, for all cases, that we are handling a container with entries A, B= , C, and D, of some mix of NEXT-C-SID and REPLACE-C-SID flavors. Case 1: Suppose that A was the REPLACE-C-SID flavor C-SID and B is the NEXT-C-SID f= lavor. When A is processed, B will be copied into the IPv6 DA, retaining th= e prefix before A in the container. So far, so good. Then, when the packet = arrives at the node that processes B, it will say "NEXT". The remaining bit= s will be? I thought zero, but actually, it will presumably be two bits wit= h the value two? So the subsequent behavior will shift that two up? Even if= the NEXT-C-SID flavor guesses that the two should be zero, it would skip C= and D and pick up the entry from the next C-SID container in the SRH. So i= t seems to either work wrong or work oddly? Case 2: Suppose that A was the NEXT-C-SID flavor. So it simply shifts B, C, D upwar= ds in the IPv6 DA. Suppose B is the REPLACE-C-SID flavor. It will interpret= the upper bits of the C C-SID as the arg for selecting the position in the= C-SID container to pull an entry from. It will also modify the C C-SID to = perform the decrement it thinks it needs. It will then overwrite itself wit= h the randomly chosen entry from the container. It seems that neither scenario works. At least, I cannot figure out how it = can work. I would greatly appreciate it if you could have a look and clarif= y it for me. Regards, Greg On Fri, Oct 8, 2021 at 10:12 AM Francois Clad (fclad) > wrote: Hi Greg, Thank you for the confirmation. I am glad that the matter of combining C-SI= Ds of different flavors is clear now. Thanks, Francois From: Greg Mirsky > Date: Thursday, 7 October 2021 at 20:15 To: Francois Clad (fclad) > Cc: Robert Raszuk >, Ron Bonica= >, James Guichard >, SPRING WG >, spri= ng-chairs@ietf.org > Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ Hi Francois, thank you for your detailed response and confirming that C-SIDs of differen= t flavors/behavior may be present in the same SRH and even the same CSID co= ntainer. I've noticed Ron's proposal as I was trying to formulate my questi= on. His proposal highlighted what I am trying to understand - the relations= hip between NEXT-C-SID and REPLACE-C-SID. I concur with Ron. The WG has ado= pted the compression analysis draft, and the updates and an additional analy= sis Ron proposed will keep the discussion and decision-making process on th= e firm technical foundation. Regards, Greg On Thu, Oct 7, 2021 at 9:17 AM Francois Clad (fclad) > wrote: Hi Greg, It is the role of the SR Source Node [Section 3.1 of RFC 8754] to form the = segment list in the SRH. It learns about the available SIDs in the network = with their associated behavior and flavors via control plane and/or managem= ent plane protocols, as described in Section 8 of RFC 8986, and selects the= SIDs that are the most appropriate for the segment list. Each SR Segment Endpoint Node [Section 3.3 of RFC 8754] simply executes the= pseudocode of a locally instantiated SID when it receives a packet matchin= g that SID. The SR Segment Endpoint Node does not need to bother about the = behavior/flavor of the subsequent SRv6 SIDs. This SRv6 logic applies to the C-SID flavors as well. The choice of flavors= for the SIDs in the SID List is up to the SR Source Node. It is indeed possible to mix SIDs of different C-SID flavors in the same SR= H, and even in a single C-SID container. Thanks, Francois From: Greg Mirsky > Date: Wednesday, 6 October 2021 at 19:19 To: Francois Clad (fclad) > Cc: Robert Raszuk >, Ron Bonica= >, James Guichard >, SPRING WG >, spri= ng-chairs@ietf.org > Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ Hi Francois, thank you for the clarification. It is still not clear how a node selects w= hich flavor of CSID to use on the next compressed CSID that may happen also= be in the next CSID container. As I understand it, a CSID container must u= se the same flavor of compression but CSID containers with different compre= ssion flavors in the same SRH are allowed. Is that correct understanding? Regards, Greg On Wed, Oct 6, 2021 at 7:05 AM Francois Clad (fclad) > wrote: Hi Greg, A node that supports this draft in its entirety can instantiate SRv6 SIDs (= e.g., End and End.X SIDs) with any of the three C-SID flavors. In particular, a node can instantiate multiple SRv6 SIDs bound to different= C-SID flavors, possibly with different C-SID lengths. It can also instanti= ate SRv6 SIDs with behaviors and flavors defined in RFC 8986. As defined in Section 4.3 of RFC 8754 and again in Section 3 of RFC 8986, u= pon receiving an IPv6 packet with a destination address matching a FIB entr= y that represents one of these locally instantiated SIDs, the node processe= s the packet according to the behavior (and flavor(s)) (i.e. pseudocode) of= that SID. RFC 8754 and 8986 have already standardized these mechanisms and the C-SID = draft only leverages the same SRv6 dataplane to introduce new endpoint flav= ors for compression. Francois From: spring > on b= ehalf of Greg Mirsky > Date: Tuesday, 5 October 2021 at 23:37 To: Robert Raszuk > Cc: Ron Bonica >, James Guichard >, SPRING WG >, spring-chairs@ietf.org > Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ Hi Robert, as I understand it, you believe everything that is written in the draft. I = hope you can help me find an answer to one simple question: Can a node that supports this draft in its entirety, i.e., supports all "fl= avors" defined in the document, process received SRv6 packet with the SRH e= ncoded according to the specification? So far, the proponents of the draft referred to "planning" how flavors of S= Rv6 SID compressed. To the best of my understanding, that is is a clear dem= onstration of the incompatibility between flavors defined in the CSID draft= . Regardless of what is written in it. Regards, Greg On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk > wrote: Ron & SPRING WG chairs, Through this discussion we first have seen a debate if we need one or more = data planes to compress SIDs in SRv6. WG clearly stated we need one. Following that we have observed a first terminology shift to see if asking = how many solutions should be supported will work any better. To that many W= G members clearly stated that they support one solution. Well please notice that the draft in question in its introduction states: Abstract This document defines a compressed SRv6 Segment List Encoding in the Segment Routing Header (SRH). This solution does not require any SRH data plane change nor any SRv6 control plane change. This solution leverages the SRv6 Network Programming model. So based on my understanding of English the entire draft talks about a sing= le solution. Then suddenly a new question popped up: how many behaviours are acceptable. I bet number of folks including myself said "one" keeping in mind previous = discussions and the definition of "one" meaning based on the SRv6 data plan= e in compliance to [RFC8402], [RFC8754] and [RFC8986]. Interestingly enough the draft in question defines not behaviours but flavo= rs as new variants of the already defined behaviors in Standards Track RFCs= . Namely it defines: 4.1. NEXT-C-SID Flavor 4.2. REPLACE-C-SID Flavor The newly defined behaviour End.XPS is optional. So if there is anything to ask here is to check if WG is ok with two flavor= s or not. I do not recall that question has ever been asked formally during= the WG adoption call. With that let's note that optimal compressed SID size may be different netw= ork to network. One size does not fit all. Draft says: 6.1. C-SID Length The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A C-SID length of 16-bit is recommended. The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths. A C-SID length of 32-bit is recommended. While I personally think 8-bit should be an option, if we choose a single f= lavor we will introduce suboptimality for no good reason. Hardware capable = of supporting any flavor clearly can do LPM on locator. Also hardware capab= le of supporting one flavor can support few other flavors as this is pretty= much just an offset game. Kind regards, Robert On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica > wrote: Pablo, Ae you sure? Please look at the question as Joel asked it ( https://mailarc= hive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ ). = Ron _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_CO6PR11MB565063F24696D8B96D2276B6ACB79CO6PR11MB5650namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Greg,<= o:p>

    &nbs= p;

    Your unde= rstanding is correct. The C-SID flavors cannot be randomly mixed within the= same C-SID container.

    &nbs= p;

    We can cl= arify the details related to the combination of flavors in a C-S= ID container in an upcoming version of the draft. For example, the last ent= ry of a C-SID container can carry a C-SID bound to any behavior, including one with another C-SID flavor.=

    &nbs= p;

    Thanks,

    Francois<= o:p>

    &nbs= p;

    From: Greg Mirsky <gre= gimirsky@gmail.com>
    Date: Friday, 8 October 2021 at 22:21
    To: Francois Clad (fclad) <fclad@cisco.com>
    Cc: Robert Raszuk <robert@raszuk.net>, Ron Bonica <rbonica= =3D40juniper.net@dmarc.ietf.org>, James Guichard <james.n.guichard@fu= turewei.com>, SPRING WG <spring@ietf.org>, spring-chairs@ietf.org = <spring-chairs@ietf.org>
    Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.= org/doc/draft-filsfilscheng-spring-srv6-srh-compression/    <= /p>

    Hi Francois,
    you've said that different flavors of C-SID can be present not only in the = same SRH but also in the same C-SID container. The latter case got me think= ing about several potential scenarios. Have to admit that I got stuck tryin= g to understand how they can work. I hope you can help me out. Please consider the two cases described below.=

    Consider, for all cases, that we are handling a container with entries A, B= , C, and D, of some mix of NEXT-C-SID and REPLACE-C-SID flavors.

    Case 1:
    Suppose that A was the REPLACE-C-SID flavor C-SID and B is the NEXT-C-SID f= lavor. When A is processed, B will be copied into the IPv6 DA, retaining th= e prefix before A in the container. So far, so good. Then, when the packet = arrives at the node that processes B, it will say "NEXT". The remaining bits will be? I thought zer= o, but actually, it will presumably be two bits with the value two? So the = subsequent behavior will shift that two up? Even if the NEXT-C-SID flavor g= uesses that the two should be zero, it would skip C and D and pick up the entry from the next C-SID container in the SR= H. So it seems to either work wrong or work oddly?

    Case 2:
    Suppose that A was the NEXT-C-SID flavor. So it simply shifts B, C, D upwar= ds in the IPv6 DA. Suppose B is the REPLACE-C-SID flavor. It will interpret= the upper bits of the C C-SID as the arg for selecting the position in the= C-SID container to pull an entry from. It will also modify the C C-SID to perform the decrement it thinks i= t needs. It will then overwrite itself with the randomly chosen entry from = the container.

    It seems that neither scenario works. At least, I cannot figure out how it = can work. I would greatly appreciate it if you could have a look and clarif= y it for me.

    Regards,

    Greg

     

    On Fri, Oct 8, 2021 at 10:12 AM Francois Clad (fclad= ) <fclad@cisco.com> wrote:

    Hi Greg,

     

    Thank you for the confirmation. I am glad that the matter of combi= ning C-SIDs of different flavors is clear now.

     

    Thanks,

    Francois

     

    From: Greg Mirsky <gregimirsky@gmail.c= om>
    Date: Thursday, 7 October 2021 at 20:15
    To: Francois Clad (fclad) <fclad@cisco.com>
    Cc: Robert Raszuk <robert@raszuk.net>, Ron Bonica <rbonica=3D40juniper.net@dmarc.iet= f.org>, James Guichard <james.n.guichard@futurewei.com>, SPRING WG <spring@= ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>
    Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/

    Hi Francois,

    thank you for your detailed response and confirming that C-SIDs of= different flavors/behavior may be present in the same SRH and even th= e same CSID container. I've noticed Ron's proposal as I was trying to formulate my question. His proposal highlighte= d what I am trying to understand - the relationship between NEXT-C-SID= and REPLACE-C-SID. I concur with Ron. The WG has adopted the compression analysis draft, and the updates and an additional anal= ysis Ron proposed will keep the discussion and decision-making process on t= he firm technical foundation.

     

    Regards,

    Greg

     

    On Thu, Oct 7, 2021 at 9:17 AM Francois Clad (fclad) <fclad@cisco.com> wrote= :

    Hi Greg,

     

    It is the role of the SR Source Node [Section 3.1 of RFC 8754] to = form the segment list in the SRH. It learns about the available SIDs in the= network with their associated behavior and flavors via control plane and/or management plane protocols, as descri= bed in Section 8 of RFC 8986, and selects the SIDs that are the most approp= riate for the segment list.

     

    Each SR Segment Endpoint Node [Section 3.3 of RFC 8754] simply exe= cutes the pseudocode of a locally instantiated SID when it receives a packe= t matching that SID. The SR Segment Endpoint Node does not need to bother about the behavior/flavor of the sub= sequent SRv6 SIDs.

     

    This SRv6 logic applies to the C-SID flavors as well. The choice o= f flavors for the SIDs in the SID List is up to the SR Source Node.

     

    It is indeed possible to mix SIDs of different C-SID flavors in th= e same SRH, and even in a single C-SID container.

     

    Thanks,

    Francois

     

     

    From: Greg Mirsky <gregimirsky@gmail.c= om>
    Date: Wednesday, 6 October 2021 at 19:19
    To: Francois Clad (fclad) <fclad@cisco.com>
    Cc: Robert Raszuk <robert@raszuk.net>, Ron Bonica <rbonica=3D40juniper.net@dmarc.iet= f.org>, James Guichard <james.n.guichard@futurewei.com>, SPRING WG <spring@= ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>
    Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/

    Hi Francois,

    thank you for the clarification. It is still not clear how a node = selects which flavor of CSID to use on the next compressed CSID that may ha= ppen also be in the next CSID container. As I understand it, a CSID container must use the same flavor of compressi= on but CSID containers with different compression flavors in the same SRH a= re allowed. Is that correct understanding?

     

    Regards,

    Greg

     

    On Wed, Oct 6, 2021 at 7:05 AM Francois Clad (fclad) <fclad@cisco.com> wrote= :

    Hi Greg,

     

    A node that supports this draft in its entirety can instantiate SR= v6 SIDs (e.g., End and End.X SIDs) with any of the three C-SID flavors.

     

    In particular, a node can instantiate multiple SRv6 SIDs bound to = different C-SID flavors, possibly with different C-SID lengths. It can also= instantiate SRv6 SIDs with behaviors and flavors defined in RFC 8986.

     

    As defined in Section 4.3 of RFC 8754 and again in Section 3 of RF= C 8986, upon receiving an IPv6 packet with a destination address matching a= FIB entry that represents one of these locally instantiated SIDs, the node processes the packet according to the = behavior (and flavor(s)) (i.e. pseudocode) of that SID.

     

    RFC 8754 and 8986 have already standardized these mechanisms and t= he C-SID draft only leverages the same SRv6 dataplane to introduce new endp= oint flavors for compression.

     

     

    Francois

     

    From: spring <spring-bounces@ietf.o= rg> on behalf of Greg Mirsky <gregimirsky@gmail.com>
    Date: Tuesday, 5 October 2021 at 23:37
    To: Robert Raszuk <robert@raszuk.net>
    Cc: Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org>, James Guic= hard <james.n.guichard@futurewei.com>, SPRING WG <spring@ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>
    Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/

    Hi Robert,

    as I understand it, you believe everything that is written in the = draft. I hope you can help me find an answer to one simple question:

    Can a node that supports this draft in its entirety, i.e., support= s all "flavors" defined in the document, process received SRv6 pa= cket with the SRH encoded according to the specification?

    So far, the proponents of the draft referred to "planning&quo= t; how flavors of SRv6 SID compressed. To the best of my understanding, tha= t is is a clear demonstration of the incompatibility between flavors defined in the CSID draft. Regardless of what is writ= ten in it.

     

    Regards,

    Greg

     

    On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk <robert@raszuk.net> wrote:=

    Ron & SPRING WG chairs,

     

    Through this discussion we first have seen a debate if we need one= or more data planes to compress SIDs in SRv6. WG clearly stated = we need one. 

     

    Following that we have observed a first terminology shift to see i= f asking how many solutions should be supported will work any better. To th= at many WG members clearly stated that they support one solution. 

     

    Well please notice that the draft in question in its introduction = states: 

     

    Abstract

       This document defines a compressed SRv6 Segment List Encoding = in the
       Segment Routing Header (SRH).  This solution does = not require any SRH
       data plane change nor any SRv6 control plane change.  = This solution
       leverages the SRv6 Network Programming model.

     

    So based on my understanding of English the entire draft talks abo= ut a single solution. 

     

    Then suddenly a new question popped up: how many behaviours a= re acceptable. 

     

    I bet number of folks including myself said "one" keepin= g in mind previous discussions and the definition of "one" meanin= g based on the SRv6 data plane in compliance to [RFC8402], [RFC8754] and [RFC8986].

     

    Interestingly enough the draft in question defines not behaviours = but flavors as new variants of the already defined behaviors in Standards T= rack RFCs. Namely it defines: 

     

    4.1.  NEXT-C-SID Flavor

    4.2.  REPLACE-C-SID Flavor

     

    The newly defined behaviour End.XPS is optional. 

    So if there is anything to ask here is to check if WG is ok with two flavor= s or not. I do not recall that question has ever been asked formally d= uring the WG adoption call. 

     

    With that let's note that optimal compressed SID size may be diffe= rent network to network. One size does not fit all. Draft says: 

    6.1.  C-SID Length

       The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengt= hs.  A
       C-SID length of 16-bit is recommended.

       The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID le= ngths.
       A C-SID length of 32-bit is recommended.

     

    While I personally think 8-bit should be an option, if we choose a= single flavor we will introduce suboptimality for no good reason. Hardware= capable of supporting any flavor clearly can do LPM on locator. Also hardware capable of supporting one flavor can = support few other flavors as this is pretty much just an offset game. =

     

    Kind regards,

    Robert

     

     

     

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

    --_000_CO6PR11MB565063F24696D8B96D2276B6ACB79CO6PR11MB5650namp_-- From nobody Wed Oct 13 05:04:17 2021 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 C80E13A088C; Wed, 13 Oct 2021 05:04:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIqKT218xJjf; Wed, 13 Oct 2021 05:04:10 -0700 (PDT) Received: from cmccmta1.chinamobile.com (cmccmta1.chinamobile.com [221.176.66.79]) by ietfa.amsl.com (Postfix) with ESMTP id 449D93A088D; Wed, 13 Oct 2021 05:04:08 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.121.9]) by rmmx-syy-dmz-app02-12002 (RichMail) with SMTP id 2ee26166cb378dc-b0a10; Wed, 13 Oct 2021 20:04:07 +0800 (CST) X-RM-TRANSID: 2ee26166cb378dc-b0a10 X-RM-TagInfo: emlType=0 X-RM-SPAM-FLAG: 00000000 Received: from cmcc (unknown[10.1.6.6]) by rmsmtp-syy-appsvr05-12005 (RichMail) with SMTP id 2ee56166cb361f5-4ce03; Wed, 13 Oct 2021 20:04:07 +0800 (CST) X-RM-TRANSID: 2ee56166cb361f5-4ce03 From: "Weiqiang Cheng" To: "'James Guichard'" , "'SPRING WG'" Cc: References: In-Reply-To: Date: Wed, 13 Oct 2021 20:04:06 +0800 Message-ID: <053a01d7c02a$6c75d520$45617f60$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_053B_01D7C06D.7A991520" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQJXdi8w Content-Language: zh-cn Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 13 Oct 2021 12:04:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_053B_01D7C06D.7A991520 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable Dear Chairs and WG, =20 As a co-author of this document, I would like to thank all participants = in the discussion. All those discussions, comments and suggestions are of = great value to us. =20 It was unexpected that so many IETFers could join the discussion. It is amazing. It also made me realize that the draft is very valuable. =20 Here I would like to raise one suggestion: =20 Due to National Day holiday (October 1st to October 7th) in China, many experts interested in the draft were not fully involved in the = discussion.=20 =20 Could the Working Group consider extending the adoption call by one week more so that all members could participate fully in the discussions? =20 B.R. Weiqiang Cheng =20 =B7=A2=BC=FE=C8=CB: spring [mailto:spring-bounces@ietf.org] =B4=FA=B1=ED = James Guichard =B7=A2=CB=CD=CA=B1=BC=E4: 2021=C4=EA10=D4=C21=C8=D5 22:05 =CA=D5=BC=FE=C8=CB: SPRING WG =B3=AD=CB=CD: spring-chairs@ietf.org =D6=F7=CC=E2: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= res sion/ =20 Dear WG: =20 The chairs would like to express their appreciation for all the = responses received to our emails with reference to how the working group wishes to move forward with respect to a solution for SRv6 compression.=20 =20 The apparent inclination of the working group is to use = https://datatracker. ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the = basis for its compression standardization work. That is part of what this = email attempts to confirm. =20 Because of the above the chairs would like to issue a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= res sion/ but with some clear guidelines as follows. By expressing support = for adoption of this document you are fully aware of and are acknowledging = that: =20 1. The SPRING working group is adopting a document that has multiple SRv6 Endpoint behaviors.=20 2. The document is a =A1=B0living=A1=B1 document; it may change as it = goes through review and analysis by the SPRING working group.=20 3. All open discussion points raised on our mailing list MUST be addressed BEFORE said document is allowed to progress from the working = group to publication. A list of these discussion points will be documented in = the WG document and maintained by the document editor in conjunction with = the chairs.=20 4. If this document is adopted by the working group, the chairs specify as part of the adoption call that the following text describing an open issue be added to the document in the above-described open issues = section: * "Given that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple = SRv6 EndPoint behaviors that some WG members have stated are multiple data = plane solutions, the working group will address whether this is valid and = coherent with its one data plane solution objective.". =20 Please consider the above guidelines as you decide on whether to support = or not this WG adoption. Please express clearly your reasoning for support/non-support as well as any open discussion points you would like addressed should the document be adopted into the working group. =20 Thanks! =20 Jim, Bruno & Joel =20 =20 ------=_NextPart_000_053B_01D7C06D.7A991520 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

    Dear Chairs and = WG,

     

    As a co-author of this = document, I would like to thank all participants in the discussion. All = those discussions, comments and suggestions are of great value to = us.

     

    It was unexpected that so many = IETFers could join the discussion. It is amazing. It also made me = realize that the draft is very valuable.

     

    Here I would like to raise one = suggestion:

     

    Due to National Day holiday = (October 1st to October 7th) in China, many experts interested in the = draft were not fully involved in the discussion. =

     

    Could the Working Group = consider extending the adoption call by one week more so that all = members could participate fully in the = discussions?

     

    B.R.

    Weiqiang = Cheng

     

    =B7=A2=BC=FE=C8=CB: spring = [mailto:spring-bounces@ietf.org] =B4=FA=B1=ED = James = Guichard
    =B7=A2=CB=CD=CA=B1=BC= =E4: 2021=C4=EA10=D4=C21=C8=D5 22:05
    =CA=D5=BC=FE=C8=CB: SPRING = WG
    =B3=AD=CB=CD: spring-chairs@ietf.org
    =D6=F7=CC=E2: [spring] WG Adoption call = for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/

     

    Dear WG:

     

    The chairs would like to express = their appreciation for all the responses received to our emails with = reference to how the working group wishes to move forward with respect = to a solution for SRv6 compression.

     

    The apparent inclination of the = working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-sp= ring-srv6-srh-compression/ as the basis for its compression = standardization work. That is part of what this email attempts to = confirm.

     

    Because of the above the chairs would like to issue a = 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-sp= ring-srv6-srh-compression/ but with some clear guidelines as = follows. By expressing support for adoption of this document you are = fully aware of and are acknowledging that:

     

    1. The SPRING working = group is adopting a document that has multiple SRv6 Endpoint behaviors. =
    2. The document is a =A1=B0living=A1=B1 document; = it may change as it goes through review and analysis by the SPRING = working group.
    3. All open discussion = points raised on our mailing list MUST be addressed BEFORE said document = is allowed to progress from the working group to publication. A list of = these discussion points will be documented in the WG document and = maintained by the document editor in conjunction with the chairs. =
    4. If this document is adopted by the working = group, the chairs specify as part of the adoption call that the = following text describing an open issue be added to the document in the = above-described open issues section:
      • "Given that = the working group has said that it wants to standardize one data plane = solution, and given that the document contains multiple SRv6 EndPoint = behaviors that some WG members have stated are multiple data plane = solutions, the working group will address whether this is valid and = coherent with its one data plane solution = objective.".

     

    Please consider the above = guidelines as you decide on whether to support or not this WG adoption. = Please express clearly your reasoning for support/non-support as well as = any open discussion points you would like addressed should the document = be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & = Joel

     

     

    Hi WG=EF=BC=8C

    = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0After many interop and efficiency = tests in our lab, I have to say that=C2=A0C= SID recommended by=C2=A0draft-filsfi= lscheng-spring-srv6-srh-compression/ is a good solution for the deployment of SRv6. Our judgements came=20 frome the following aspects:
    • Under = the circumstances of large deployment, even with heavy load in MAN, the men= tioned solution,=C2=A0C= SID,=C2=A0 proved to be= working at high efficiency which is actually quite beyond our expectations= ;=C2=A0
    • From the perspective of packet forwarding,=C2=A0 it is coherent with data plane= =C2=A0=20 objectives and could interop well with other IPv6 deployments;
    • CSID can meets all requirements de= rived from=C2=A0 SRv6 header compression.
    Based on those facts, I really appreciate that=C2=A0the=C2=A0recommended=C2=A0CSID should be used as the candidate standard for SRv6 header compression,=20 and we are looking forward to the early consent of it as a=20 standard=EF=BC=8Cthus=C2=A0 the adoption as a WG document should be done AS= AP.

    Best Regards=EF=BC=8C
    Calvin Dong


    =E5=9C=A8 2021=E5=B9=B410=E6=9C=881= =E6=97=A5 22:04=EF=BC=8CJames Guichard<james.n.guichard@futurewei.com<= /a>> =E5=86=99=E9=81=93=EF=BC=9A

    Dear WG:

    =C2=A0

    The chairs would like to express their appreciation for all the responses=20 received to our emails with reference to how the working group wishes to move forward with respect to a solution for SRv6 compression.=

    =C2=A0

    The apparent incli= nation of the working group is to use=C2=A0https://datatracker.ietf.org/doc/d= raft-filsfilscheng-spring-srv6-srh-compression/=C2=A0as the basis for i= ts compression standardization work. That is part of what this email attemp= ts to confirm.

    =C2=A0

    Because of the above the chairs would like to issue a 2-week WG ca= ll for adoption ending October 15th=C2=A0for=C2=A0https://datatrac= ker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/=C2=A0= but with some clear guidelines as follows. By expressing support for=20 adoption of this document you are fully aware of and are acknowledging=20 that:

    =C2=A0

    1. The SPRING working group= is adopting a document that has multiple SRv6 Endpoint behaviors.
    2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change as = it goes through review and analysis by the SPRING working group.
    3. All open discussion points raised on our mailing list MUST be addressed=20 BEFORE said document is allowed to progress from the working group to=20 publication. A list of these discussion points will be documented in the WG document and maintained by the document editor in conjunction with=20 the chairs.
    4. If this document is adopted by the working group, the chairs specify as=20 part of the adoption call that the following text describing an open=20 issue be added to the document in the above-described open issues=20 section:
      • "Given that the working group has said that it wants to standardize one data=20 plane solution, and given that the document contains multiple SRv6=20 EndPoint behaviors that some WG members have stated are multiple data=20 plane solutions, the working group will address whether this is valid=20 and coherent with its one data plane solution objective.".

    =C2=A0

    Please consider the above guidelines as you decide on whether to support or=20 not this WG adoption. Please express clearly your reasoning for=20 support/non-support as well as any open discussion points you would like addressed should the document be adopted into the working group.

    =C2=A0

    Thanks!=

    =C2=A0

    Jim, Bruno = & Joel


    =E8=91=A3=E5=96=9C=E6=98=8E

    =E7=83=BD=E7=81=AB=E9=80=9A=E4=BF=A1=E7=A7=91=E6=8A=80=E8= =82=A1=E4=BB=BD=E6=9C=89=E9=99=90=E5=85=AC=E5=8F=B8=C2=A0=E7=BD=91=E7=BB=9C=E4=BA=A7=E5=87=BA=E7=BA=BF = =E9=A2=84=E7=A0=94=E9=83=A8
    =E6=B9=96=E5=8C=97=E7=9C=81=E6=AD=A6=E6=B1=89=E5=B8=82=E4= =B8=9C=E6=B9=96=E6=96=B0=E6=8A=80=E6=9C=AF=E5=BC=80=E5=8F=91=E5=8C=BA=E9=AB= =98=E6=96=B0=E5=9B=9B=E8=B7=AF6=E5=8F=B7=C2=A0
    =E6=89=8B=E6=9C=BA=EF=BC=9A+86-13871232900
    E-mail=EF=BC=9A=C2=A0dxm@fiberhome.com

    = ------= -------------------------------
    Calvin Dong

    Network Business Unit=EF=BC=8C    Fiberhome=C2=A0Telecommunication=C2=A0Technol= ogies=C2=A0Co.,LTD.
    Addr:=C2=A0No.6, Gaoxinsilu, East Lake High-tech Develo= pment Zone, Wuhan, Hubei
    Mobile: +86-13871232900
    E-mail=EF=BC= =9Adxm@fiberhome.com
    ------=_NextPart_000_053B_01D7C06D.7A991520-- From nobody Wed Oct 13 05:19:17 2021 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 1C8643A08EC; Wed, 13 Oct 2021 05:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.798 X-Spam-Level: X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=marvell.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 DxVpoC5W9WfF; Wed, 13 Oct 2021 05:19:05 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (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 B97083A08E7; Wed, 13 Oct 2021 05:19:05 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19DAVJjp017039; Wed, 13 Oct 2021 05:19:04 -0700 Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2109.outbound.protection.outlook.com [104.47.55.109]) by mx0a-0016f401.pphosted.com with ESMTP id 3bnwrxge9d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Oct 2021 05:19:03 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mxVd23mzss05SXy+W8DyENKBS4B/opnyYUs0+gsekGowbONhSTB6VCNUC9+ZRy0R4qZgZvNmqlXtreB2igH6tvxWtb939AfaSJjJe0U7fFAbth3WFqpe0PKa3w4Pz/L6lR5zTh7Pd8tBtjquHyuqa1iWTo+TSAnSZiI2WeLAlCNT7pwgS9y0v9CgzfCRxvESVAZlPbPFinWC2jsUAz+/DMgOZXoeZSpTFLfBasGUdt2ADsP65itWMLB7FeHdE1q1zP6gcyE10ziXq/9B6WH974BhxmnRYG0prUfwnM+B26S94qqlbtJNlDaYgfMXLW3aEe4JgEFwpog7vvKO/UlR2w== 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=I7Yl/VVsT7XlqZNxzj2W9VGPg8ydF9ar3+g62FQp4MY=; b=NQQO8a6Khzb5eOjnmXpxDGa/I/00vBCHv3tUu8RcutI3vVSaSqTzWuub7qj4evF5EwIeQfx8QaQkQFcLIZZZ7cDXMjppD925VsI9yiul4cOiFKqbdT6PWGpcjgaA6vJXFN0VDihYXmbqChpOFdoS60GaSqIBUygZHMZTwkrZe1zBfueAkzZYTxG9L2kKbIEfEi60R+vKUC4qhv6DyC8Z4BQByGO9PBR1FlptAjYsLbX/uwK1YB9h8UbfyfVs4hPZSlS+snw7FUp8Rg/pC6HK+IeLI/DTv7HB40J9sxIFJYimaR+UgpZddGr16Ahf6vwi/O3BfnqbLw79ajmNr/HwqQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=marvell.com; dmarc=pass action=none header.from=marvell.com; dkim=pass header.d=marvell.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=marvell.onmicrosoft.com; s=selector1-marvell-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I7Yl/VVsT7XlqZNxzj2W9VGPg8ydF9ar3+g62FQp4MY=; b=QrIYDQGam2PWIk5F1JTRT2i8AG0CLyMEibt8dxJs4uBVO38EC4n2sSExh4dd/Y3mVuplPqkXsJ0/1GSu/eREMlEMNMDku/o+n2w65WyVS+FfBd5/bqelf792XyGPE9ugt8c8IufvFPz3c6uu/vQ29gs+I+ipBQkOEp/HMKay3Mk= Received: from PH0PR18MB4704.namprd18.prod.outlook.com (2603:10b6:510:cb::9) by PH0PR18MB4558.namprd18.prod.outlook.com (2603:10b6:510:ac::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.20; Wed, 13 Oct 2021 12:19:01 +0000 Received: from PH0PR18MB4704.namprd18.prod.outlook.com ([fe80::f0dd:457:6f7d:e357]) by PH0PR18MB4704.namprd18.prod.outlook.com ([fe80::f0dd:457:6f7d:e357%5]) with mapi id 15.20.4608.015; Wed, 13 Oct 2021 12:19:01 +0000 From: David Melman To: "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQImlNYg Date: Wed, 13 Oct 2021 12:19:00 +0000 Message-ID: References: In-Reply-To: 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: cfea8e52-b9fe-4954-f70d-08d98e43a3b7 x-ms-traffictypediagnostic: PH0PR18MB4558: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OMKa41ba8nISAlN2U9ogAo53ZfFM4qCw3KuaBa0I5XFkeBW4/uHSlaoW+ixcAyBscQ91XqaciLLL4FZiV6u6kiMxYnepk8gqhpu+WnWTwLiocYZAroVYG4U97GNCUf+ivHXlcP8QI8fWtHK2iUl3LCkZyg2A7iDacrP7VDjU4UhuyzCm39+yngtjAt2pFdkcOUoFVNOwjMYFT8UxutHaprcGYokOgF9ZgJeFjr4i622KJcqFT1p+ieoJYaNHh5b2pUpWtotBw7YCOQ4QEBFgcUFu70W1W0/tsUVn3lUd2w4SSyuz2I1475skD4eyHSEicS1fEYuKV5rQAdHwhn2em3+stViHTvbiGfnAHosuNMU4CuJv62dkEkLCi7bLvpsRRwfLOYihepeIxGmwff9YhsmzuEi9lMlOiI/7tmd8RIJinYd1++/lYDh+5ZJXBH50mfD3ILlBs5LpX212QOub7oxPfcZtYBJLP758ZjiKn9iRoeierJs3Na/2HKcVX3PB6t219q9O7VwhVASZmdSpqEHtMFuy0239rRums85MURGee2rBxd9lq+54IUKZyWSZDcMfwim/iIRKLQr4gXB7beNS2Sbb+XnpcAR94zr2WnVYnDwbg/cSg1LfIEmKMukPEixfsicEL+82fMAQIaB4e3ZmU/L96rk7Yt6IMLARToAbxlAwSMzKVw/l1lmikjbGtn7F6XEnQbci+pk7riOzQsMs+lni1r8KfO9JBPIA8AqpbSA/qLdY7OGBuQQuyYhbWzXAUvF90WOu6kArEiMklnuw7mATtRH9prw1Q2ETAvY= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR18MB4704.namprd18.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(966005)(76116006)(450100002)(66476007)(9686003)(316002)(55016002)(66556008)(64756008)(508600001)(38070700005)(66446008)(52536014)(6916009)(66946007)(166002)(5660300002)(4326008)(2906002)(83380400001)(6506007)(8676002)(186003)(86362001)(8936002)(26005)(38100700002)(71200400001)(122000001)(7696005)(53546011)(33656002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?SXu2GZd5HXY90eQvG4JFlWEsUrgUzu5qb7T+55+Bll9v67utzEBKvUYJ0uuW?= =?us-ascii?Q?RabW6Lb6KzXjEiEzm/70wKmsj/GVnGVwazDhY0L4L8aZXveFWP/7ykFVQU60?= =?us-ascii?Q?XxevosvwPMuew2iN3+ajc1YmF4Hq+/Qr/kl9EgRgIBCvYKbnucxKlhw9crrv?= =?us-ascii?Q?iihug0LpLkLmevzRygVrM4bNsJ04yorwolm4n2wNBSMtjNABf85Lm1iir1n0?= =?us-ascii?Q?O1bgPOMNjC+8jqp1h3lMAZK85nNPI1c5/SMxBaK7M6GrFA9xzti7odFVysGr?= =?us-ascii?Q?i6X+eKBZGsnixWGV78SMCPRupWjHbELNgG3Tmt0sq39pOnHzYrcBQ6+ZHo7u?= =?us-ascii?Q?zFfYCsoEiT5Rclw5UbZgnKuTFpmhUJ6xOfAPWad/xdaGQUQrypjY/skka8yd?= =?us-ascii?Q?vhDQtOG6Xkb35neFBB6Vy2v1kVmcUKeUhnPabmzrwhOc/p5ZkCiYG8b1QlJj?= =?us-ascii?Q?h20OrTlVq44VEfW8REpxFQ8VbUKu1N44hQBKyq/lDsQTBIRyNUmqu5qzf/lo?= =?us-ascii?Q?SgX4kAA1as2UbngPDkBTs66Og5EY3hhHZTrDZHCqFXCIKj5gMKvyy8gk2hzF?= =?us-ascii?Q?IHtPeHhM2Um/p93BW1WVOsE6KAllrUdZ7bDn6jL3QpZgI4Ssfo7a5Qaj2nCS?= =?us-ascii?Q?ti9PDV8+IV3cWtizkL9v0XSCD9E3Kx9qrwMcUpRntffIuafDaPc1MHRqqLV9?= =?us-ascii?Q?5N6n09sToB1p2OPN5pTGUUyZ2N03GSzktvcxzdhNCvr4M5y/bwzH24aLbgLe?= =?us-ascii?Q?3DMOkv/iPt68ZVhqrlxiXvBBb9u2slgf12/jSb2KZFcRxwjqt7jDShLfHkX3?= =?us-ascii?Q?8odmcN+GHyArxjy3Pwyu4agVIpk7EcUgNzlkHEyxl3noZOcM7NCfCQnRMubm?= =?us-ascii?Q?Qmy4ExQ/Sm3BHWWqPfWGF8VMoPc0tzx46j5Zr9mTAbObdU/+mmMfDTj2Zx4y?= =?us-ascii?Q?pjpBjRF24L5eluqLk7JJXzjKta7C7bkJQI9koN1+Dc5hIuwPMNOA/RrXdhQC?= =?us-ascii?Q?yYhULsWW17nu1GlyWxlph0Vbrn1LnszcdICfveUn0+1stWwT79HcbL4JDfe4?= =?us-ascii?Q?zrNOEIeCqFntHBdm+rVSr3lN8SQLfho+x+UL218TPsnhXSZohv1Zxw75Y7JR?= =?us-ascii?Q?SYg/FQFCBpasS6q14XFDzNtWUeju5UVBmaZzRvS+aDgQbAJK51kGS/Z77HC5?= =?us-ascii?Q?4bGVN/GJd4CJybC/goVnTvgNajVw13EwrrTxOf3PPUETLdCCl8O0YzokB5Qd?= =?us-ascii?Q?GzxQL+JBTO9sjp0GYHxTLLhUFIzgorGfC91K0SNYpaDaQCRyFu+tcKOVn9M+?= =?us-ascii?Q?DM//TzzAooTwFGCGvPevG3Cs?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_PH0PR18MB47049A50708B89220F8764C3AEB79PH0PR18MB4704namp_" MIME-Version: 1.0 X-OriginatorOrg: marvell.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR18MB4704.namprd18.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cfea8e52-b9fe-4954-f70d-08d98e43a3b7 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2021 12:19:00.9076 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 70e1fb47-1155-421d-87fc-2e58f638b6e0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: bw9VG1qpKgAKqpyqld+Fca0FIk6o/8vNUwG/OrKHjU1+LLhroeq4qKhpqhCxd4InsaiKV9AHJX69TvVsysi/7w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR18MB4558 X-Proofpoint-ORIG-GUID: np0gGa-ZN8f0AclXahuCOWwd4Fz28kf- X-Proofpoint-GUID: np0gGa-ZN8f0AclXahuCOWwd4Fz28kf- X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-13_05,2021-10-13_02,2020-04-07_01 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 13 Oct 2021 12:19:11 -0000 --_000_PH0PR18MB47049A50708B89220F8764C3AEB79PH0PR18MB4704namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Marvell silicon supports the SRv6 CSID flavors REPLACE-CSID and NEXT-CSID, = and Marvell has participated in multi-vendor interoperability testing of th= ese CSID flavors. I support the WG adoption of the draft. David From: spring On Behalf Of James Guichard Sent: Friday, October 1, 2021 5:05 PM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [EXT] [spring] WG Adoption call for https://datatracker.ietf.org/d= oc/draft-filsfilscheng-spring-srv6-srh-compression/ External Email ________________________________ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardization work. That = is part of what this email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with s= ome clear guidelines as follows. By expressing support for adoption of this= document you are fully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel --_000_PH0PR18MB47049A50708B89220F8764C3AEB79PH0PR18MB4704namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Marvell silicon supports the SRv6 CSID flavors REPLACE-CSID and NEXT-CSID, and Marvell has participated in = multi-vendor interoperability testing of these CSID flavors.

     

    I support the WG adoptio= n of the draft.

     

    David

     

    From: spring <spring-bounces@ietf.org> = On Behalf Of James Guichard
    Sent: Friday, October 1, 2021 5:05 PM
    To: SPRING WG <spring@ietf.org>
    Cc: spring-chairs@ietf.org
    Subject: [EXT] [spring] WG Adoption call for https://datatracker.iet= f.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

     

    External = Email

    Dear WG:

     

    The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

     

    The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

     

    Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

     

    1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors.
    2. The document is a “living” document; it m= ay change as it goes through review and analysis by the SPRING working grou= p.
    3. All open discussion points raised on our mailing list= MUST be addressed BEFORE said document is allowed to progress from the wor= king group to publication. A list of these discussion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
    4. If this document is adopted by the working group, the= chairs specify as part of the adoption call that the following text descri= bing an open issue be added to the document in the above-described open issues section:
      • "Given th= at the working group has said that it wants to standardize one data plane s= olution, and given that the document contains multiple SRv6 EndPoint behavi= ors that some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

     

    Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    --_000_PH0PR18MB47049A50708B89220F8764C3AEB79PH0PR18MB4704namp_-- From nobody Wed Oct 13 05:54:50 2021 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 D3D4C3A0954; Wed, 13 Oct 2021 05:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60Mg3T5zwMCK; Wed, 13 Oct 2021 05:54:41 -0700 (PDT) Received: from chinatelecom.cn (prt-mail.chinatelecom.cn [42.123.76.227]) by ietfa.amsl.com (Postfix) with ESMTP id D7ABF3A0953; Wed, 13 Oct 2021 05:54:39 -0700 (PDT) HMM_SOURCE_IP: 172.18.0.48:55204.823409368 HMM_ATTACHE_NUM: 0000 HMM_SOURCE_TYPE: SMTP Received: from clientip-36.7.134.125 (unknown [172.18.0.48]) by chinatelecom.cn (HERMES) with SMTP id 463FC280096; Wed, 13 Oct 2021 20:54:21 +0800 (CST) X-189-SAVE-TO-SEND: 44031110@chinatelecom.cn Received: from ([172.18.0.48]) by app0024 with ESMTP id 6e04d7cf422a449f93e53a47b33f8096 for james.n.guichard@futurewei.com; Wed, 13 Oct 2021 20:54:34 CST X-Transaction-ID: 6e04d7cf422a449f93e53a47b33f8096 X-Real-From: zhuyq8@chinatelecom.cn X-Receive-IP: 172.18.0.48 Sender: zhuyq8@chinatelecom.cn Date: Wed, 13 Oct 2021 20:54:24 +0800 From: "zhuyq8@chinatelecom.cn" To: james.n.guichard , spring Cc: spring-chairs References: X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.22.188[cn] Mime-Version: 1.0 Message-ID: <2021101320542370430139@chinatelecom.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart680360265150_=----" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 13 Oct 2021 12:54:47 -0000 This is a multi-part message in MIME format. ------=_001_NextPart680360265150_=---- Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgRGVhciBXRywgDQogICAgV2UgaGF2ZSBkZXBsb3llZCBTUnY2IGluIG91ciBuYXRpb25hbC13 aWRlIGxhcmdlIHNjYWxlIG5ldHdvcmtzIGZvciBhIGxvbmcgdGltZSB0byBwcm92aWRlIGJldHRl ciBJbnRlcm5ldCBzZXJ2aWNlcyBmb3Igb3ZlciAxIGJpbGxpb24gcGVvcGxlLiBGdXJ0aGVybW9y ZSwgYWxtb3N0IG9uZSB5ZWFyIGFnbywgd2UgaGFkIGRlY2lkZWQgdG8gdXNlIHRoZSBtZWNoYW5p c20gZGVmaW5lZCBpbiB0aGlzIGRyYWZ0IGluIG91ciBuZXR3b3JrIGluIHRoZSBuZWFyIGZ1dHVy ZS4gDQogSSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0LiBUaGFua3MuQi5SLllv bmdxaW5nIFpodQ0KDQoNCg0Kemh1eXE4QGNoaW5hdGVsZWNvbS5jbg0KIA0KRnJvbTogSmFtZXMg R3VpY2hhcmQNCkRhdGU6IDIwMjEtMTAtMDEgMjI6MDQNClRvOiBTUFJJTkcgV0cNCkNDOiBzcHJp bmctY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiBbc3ByaW5nXSBXRyBBZG9wdGlvbiBjYWxsIGZv ciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNw cmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8NCkRlYXIgV0c6DQogDQpUaGUgY2hhaXJzIHdvdWxk IGxpa2UgdG8gZXhwcmVzcyB0aGVpciBhcHByZWNpYXRpb24gZm9yIGFsbCB0aGUgcmVzcG9uc2Vz IHJlY2VpdmVkIHRvIG91ciBlbWFpbHMgd2l0aCByZWZlcmVuY2UgdG8gaG93IHRoZSB3b3JraW5n IGdyb3VwIHdpc2hlcyB0byBtb3ZlIGZvcndhcmQgd2l0aCByZXNwZWN0IHRvIGEgc29sdXRpb24g Zm9yIFNSdjYgY29tcHJlc3Npb24uIA0KIA0KVGhlIGFwcGFyZW50IGluY2xpbmF0aW9uIG9mIHRo ZSB3b3JraW5nIGdyb3VwIGlzIHRvIHVzZSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8gYXMgdGhl IGJhc2lzIGZvciBpdHMgY29tcHJlc3Npb24gc3RhbmRhcmRpemF0aW9uIHdvcmsuIFRoYXQgaXMg cGFydCBvZiB3aGF0IHRoaXMgZW1haWwgYXR0ZW1wdHMgdG8gY29uZmlybS4NCiANCkJlY2F1c2Ug b2YgdGhlIGFib3ZlIHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBpc3N1ZSBhIDItd2VlayBXRyBj YWxsIGZvciBhZG9wdGlvbiBlbmRpbmcgT2N0b2JlciAxNXRoIGZvciBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21w cmVzc2lvbi8gYnV0IHdpdGggc29tZSBjbGVhciBndWlkZWxpbmVzIGFzIGZvbGxvd3MuIEJ5IGV4 cHJlc3Npbmcgc3VwcG9ydCBmb3IgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCB5b3UgYXJlIGZ1 bGx5IGF3YXJlIG9mIGFuZCBhcmUgYWNrbm93bGVkZ2luZyB0aGF0OiANCiANClRoZSBTUFJJTkcg d29ya2luZyBncm91cCBpcyBhZG9wdGluZyBhIGRvY3VtZW50IHRoYXQgaGFzIG11bHRpcGxlIFNS djYgRW5kcG9pbnQgYmVoYXZpb3JzLiANClRoZSBkb2N1bWVudCBpcyBhIOKAnGxpdmluZ+KAnSBk b2N1bWVudDsgaXQgbWF5IGNoYW5nZSBhcyBpdCBnb2VzIHRocm91Z2ggcmV2aWV3IGFuZCBhbmFs eXNpcyBieSB0aGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAuIA0KQWxsIG9wZW4gZGlzY3Vzc2lvbiBw b2ludHMgcmFpc2VkIG9uIG91ciBtYWlsaW5nIGxpc3QgTVVTVCBiZSBhZGRyZXNzZWQgQkVGT1JF IHNhaWQgZG9jdW1lbnQgaXMgYWxsb3dlZCB0byBwcm9ncmVzcyBmcm9tIHRoZSB3b3JraW5nIGdy b3VwIHRvIHB1YmxpY2F0aW9uLiBBIGxpc3Qgb2YgdGhlc2UgZGlzY3Vzc2lvbiBwb2ludHMgd2ls bCBiZSBkb2N1bWVudGVkIGluIHRoZSBXRyBkb2N1bWVudCBhbmQgbWFpbnRhaW5lZCBieSB0aGUg ZG9jdW1lbnQgZWRpdG9yIGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIGNoYWlycy4gDQpJZiB0aGlz IGRvY3VtZW50IGlzIGFkb3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAsIHRoZSBjaGFpcnMgc3Bl Y2lmeSBhcyBwYXJ0IG9mIHRoZSBhZG9wdGlvbiBjYWxsIHRoYXQgdGhlIGZvbGxvd2luZyB0ZXh0 IGRlc2NyaWJpbmcgYW4gb3BlbiBpc3N1ZSBiZSBhZGRlZCB0byB0aGUgZG9jdW1lbnQgaW4gdGhl IGFib3ZlLWRlc2NyaWJlZCBvcGVuIGlzc3VlcyBzZWN0aW9uOg0KIkdpdmVuIHRoYXQgdGhlIHdv cmtpbmcgZ3JvdXAgaGFzIHNhaWQgdGhhdCBpdCB3YW50cyB0byBzdGFuZGFyZGl6ZSBvbmUgZGF0 YSBwbGFuZSBzb2x1dGlvbiwgYW5kIGdpdmVuIHRoYXQgdGhlIGRvY3VtZW50IGNvbnRhaW5zIG11 bHRpcGxlIFNSdjYgRW5kUG9pbnQgYmVoYXZpb3JzIHRoYXQgc29tZSBXRyBtZW1iZXJzIGhhdmUg c3RhdGVkIGFyZSBtdWx0aXBsZSBkYXRhIHBsYW5lIHNvbHV0aW9ucywgdGhlIHdvcmtpbmcgZ3Jv dXAgd2lsbCBhZGRyZXNzIHdoZXRoZXIgdGhpcyBpcyB2YWxpZCBhbmQgY29oZXJlbnQgd2l0aCBp dHMgb25lIGRhdGEgcGxhbmUgc29sdXRpb24gb2JqZWN0aXZlLiIuDQogDQpQbGVhc2UgY29uc2lk ZXIgdGhlIGFib3ZlIGd1aWRlbGluZXMgYXMgeW91IGRlY2lkZSBvbiB3aGV0aGVyIHRvIHN1cHBv cnQgb3Igbm90IHRoaXMgV0cgYWRvcHRpb24uIFBsZWFzZSBleHByZXNzIGNsZWFybHkgeW91ciBy ZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9uLXN1cHBvcnQgYXMgd2VsbCBhcyBhbnkgb3BlbiBkaXNj dXNzaW9uIHBvaW50cyB5b3Ugd291bGQgbGlrZSBhZGRyZXNzZWQgc2hvdWxkIHRoZSBkb2N1bWVu dCBiZSBhZG9wdGVkIGludG8gdGhlIHdvcmtpbmcgZ3JvdXAuDQogDQpUaGFua3MhDQogDQpKaW0s IEJydW5vICYgSm9lbA0KIA0KIA0K ------=_001_NextPart680360265150_=---- Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0A=0A
    Hi Dear WG, 
        We have deployed SRv6 in our nationa= l-wide large scale networks for a long time to provide better Internet ser= vices for over 1 billion people. Furthermore, almost one year ago, we had = decided to use the mechanism defined in this draft in our network in the n= ear future. 
     I support the =
adoption of this draft. Thanks.
    B.R.
    Yongqing Zhu
    =0A

    =0A
    zhuyq8@chinatelecom.cn
    =0A
     
    Subject: [spring] WG Adoption call for https://data= tracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/
    =0A=0A
    =0A

    Dear WG:

    =0A

     

    =0A

    The chairs w= ould like to express their appreciation for all the responses received to = our emails with reference to how the working group wishes to move forward = with respect to a solution for SRv6 compression.=0A

    =0A

     

    =0A

    The appar= ent inclination of the working group is to use =0Ahttp= s://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compressi= on/ as the basis for its compression standardization work. That is par= t of what this email attempts to confirm.

    =0A

     

    =0A

    Because of the abov= e the chairs would like to issue a 2-week WG call for adoption ending Octo= ber 15th for=0A=0Ahttps://datatracker.ietf.= org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ but with some= clear guidelines as follows. By expressing support for adoption of this d= ocument you are fully aware of and are acknowledging that:=0A=0A

     

    =0A
      =0A
    1. The SPRING working group is adopting a document = that has multiple SRv6 Endpoint behaviors.=0A
    2. The document is a =E2=80=9Cliving=E2=80=9D= document; it may change as it goes through review and analysis by the SPR= ING working group.=0A
    3. All open discussion points raised on our mailing list MUST be add= ressed BEFORE said document is allowed to progress from the working group = to publication. A list of these discussion=0A points will be documented in= the WG document and maintained by the document editor in conjunction with= the chairs.=0A
    4. =0A
    5. "Given that the working group has said = that it wants to standardize one data plane solution, and given that the d= ocument contains multiple SRv6 EndPoint behaviors that some WG members hav= e stated are=0A multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution ob= jective.".
      6. =0A
    =0A

    &nbs= p;

    =0A

    Please consider the above guidelines= as you decide on whether to support or not this WG adoption. Please expre= ss clearly your reasoning for support/non-support as well as any open disc= ussion points you would like addressed should the document=0A be adopted i= nto the working group.

    =0A

     =

    =0A

    Thanks!

    =0A

     

    =0A

    Jim, Bruno & = Joel

    =0A

     

    =0A

     

    =0A
    =0A
    =0A ------=_001_NextPart680360265150_=------ From nobody Wed Oct 13 07:07:28 2021 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 BD51D3A0A01; Wed, 13 Oct 2021 07:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GxhpRwaw2WCb; Wed, 13 Oct 2021 07:07:18 -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 BB8543A0A00; Wed, 13 Oct 2021 07:07:17 -0700 (PDT) Received: from fraeml707-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HTvQR34Rnz67yc9; Wed, 13 Oct 2021 22:03:43 +0800 (CST) Received: from dggpemm500001.china.huawei.com (7.185.36.107) 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.2308.8; Wed, 13 Oct 2021 16:07:13 +0200 Received: from dggpemm500003.china.huawei.com (7.185.36.56) by dggpemm500001.china.huawei.com (7.185.36.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Wed, 13 Oct 2021 22:07:12 +0800 Received: from dggpemm500003.china.huawei.com ([7.185.36.56]) by dggpemm500003.china.huawei.com ([7.185.36.56]) with mapi id 15.01.2308.008; Wed, 13 Oct 2021 22:07:12 +0800 From: "Chengli (Cheng Li)" To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: AdfAO61WAYyWLN0OQYGZaAvNV9N3dQ== Date: Wed, 13 Oct 2021 14:07:12 +0000 Message-ID: <466aa02714f84d81b62a88bd63f8fe1e@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.145.61] Content-Type: multipart/alternative; boundary="_000_466aa02714f84d81b62a88bd63f8fe1ehuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 13 Oct 2021 14:07:24 -0000 --_000_466aa02714f84d81b62a88bd63f8fe1ehuaweicom_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgU1BSSU5Ho6wNCg0KU29ycnkgZm9yIHRoZSBsYXRlIHJlc3BvbnNlIGR1ZSB0byB0aGUgTmF0 aW9uYWwgZGF5cyBicmVhay4gSXQgc2VlbXMgbGlrZSBJIG1pc3MgYSBsb3Qgb2YgZGlzY3Vzc2lv biwgYW5kIGl0IGRpZCBjb3N0IG1lIGEgbG90IG9mIHRpbWUgdG8gcmVhZCBhbGwgdGhlIHRocmVh ZHMuDQoNCkFzIGEgbWVtYmVyIG9mIHRoZSBkZXNpZ24gdGVhbSwgYW5kIGEgcGVyc29uIHdobyBw YXJ0aWNpcGF0ZXMgaW4gSUVURiBTUiBzdGFuZGFyZHMgZm9yIGEgbG9uZyB0aW1lLCAgSSBrbm93 IHdobyBob3cgZGlmZmljdWx0IGZvciB1cyB0byBnZXQgaGVyZS4gTWFueSB0aGFua3MgZm9yIHRo ZSBjb250cmlidXRpb25zIGZyb20gYW55b25lLg0KDQpGcm9tIHRoZSBvdXRwdXRzIG9mIERUIHRl YW0sIHdlIGtub3cgdGhhdCBDU0lEIG1lZXRzIGFsbCB0aGUgcmVxdWlyZW1lbnRzIGFuZCBwcm92 aWRlIHRoZSBiZXN0IHBlcmZvcm1hbmNlLiBBcyBhbiBhdXRob3Igb2YgQ1NJRCBkcmFmdCwgSSBj YW4gc2F5IHRoYXQgb3ZlciAxMCB2ZW5kb3JzIGhhdmUgaW1wbGVtZW50ZWQgQ1NJRCwgd2hpY2gg cHJvdmVzIHRoYXQgQ1NJRCBoYXMgYmVlbiBhZG9wdGVkIGJ5IHRoZSBpbmR1c3RyeSB2ZXJ5IHdl bGwuIFRoZXJlZm9yZSwgbm8gbWF0dGVyIGZyb20gdGhlIGFzcGVjdCBvZiByb3VnaCBjb25zZW5z dXMgYW5kIHJ1bm5pbmcgY29kZSwgSSBkbyB0aGluayB3ZSBzaG91bGQgYWRvcHQgQ1NJRCBhbmQg aXQgaXMgdGhlIHJpZ2h0IHdheSBmb3Igc3VyZS4gQWxzbywgZnJvbSBtYW55IHBvbGxzIGluIHRo ZSBtYWlsaW5nIGxpc3QsIHdlIGFsc28gc2VlIHRoZSBjb25zZW5zdXMgb2YgdXNpbmcgQ1NJRCBh cyB0aGUgYmFzaXMgb2YgU1J2NiBjb21wcmVzc2lvbiBzdGFuZGFyZC4NCg0KVGlsbCBub3csIG1h bnkgb3VyIGN1c3RvbWVycyBoYXZlIGNob3NlbiB0aGUgQ1NJRCBhcyB0aGUgU1J2NiBjb21wcmVz c2lvbiBzb2x1dGlvbiwgYW5kIHNvbWUgaW50ZXItb3AgdGVzdCBhbmQgdHJpYWwgZGVwbG95bWVu dCBoYXZlIGJlZW4gZmluaXNoZWQgZXZlbiBvbmUgeWVhciBhZ28gaW4gQ01DQ6GvcyBsYWIgYW5k IGxpdmUgbmV0d29yaywgYW5kIHdlIHdpbGwgaGF2ZSBtb3JlIHByb2R1Y3QgbmV0d29yayBkZXBs b3ltZW50cyBpbiB0aGUgbmVhciBmdXR1cmUuIEl0IHByb3ZlcyB0aGF0IENTSUQgY2FuIHdvcmsg dmVyeSB3ZWxsIGluIHRoZSBwcm9kdWN0IG5ldHdvcmsuIE1hbnkgdGhhbmtzIGZvciB0aGUgY3Vz dG9tZXJzIGFuZCBwYXJ0bmVycyB3aG8gY2hvb3NlIENTSUQgaW4gdGhlaXIgbmV0d29ya3MgYW5k IHByb2R1Y3RzLg0KDQpUaGVyZSBtYXkgYmUgc29tZSBpc3N1ZXMgZGlzY3Vzc2VkIGluIHRoZSBt YWlsaW5nIGxpc3QsIHRoYXQgaXMgZ29vZCEgSXQgYWxzbyBwcm92ZXMgdGhhdCBwZW9wbGUgYXJl IGludGVyZXN0ZWQgaW4gdGhlIHRvcGljIGFzIHdlbGwsIHdlIGFyZSB2ZXJ5IHdlbGNvbWUgYW55 b25lIHRvIG1ha2UgdGhlIGNvbnRyaWJ1dGlvbnMgdG8gdGhlIHNvbHV0aW9uLCBhbmQgbGV0oa9z IGRvIGl0IHRvZ2V0aGVyIHRvIHByb2R1Y2UgYSBnb29kIHNvbHV0aW9uIGZvciB0aGUgaW5kdXN0 cnksIHRoYXQgaXMgd2hhdCB3ZSBhcmUgZG9pbmcgYWxsIHRoZSBsb25nIHdheS4gVGhlcmVmb3Jl LCBhbHNvIHRoYW5rcyB0byB0aGUgcGVvcGxlIHByb3ZpZGUgY29tbWVudHMgaW4gdGhlIG1haWxp bmcgbGlzdC4gV2lsbCByZXBseSB0byB0aGUgbWFpbGluZyBsaXN0IHRvIGFuc3dlciB0aGUgcXVl c3Rpb25zIEFTQVAuDQoNCkF0IHRoZSBlbmQsIGFzIGFuIGF1dGhvciwgdGhlIG1lbWJlciBvZiB0 aGUgZGVzaWduIHRlYW0sIGFuZCBhIHBlcnNvbiB3aG8gZm9jdXMgb24gU1Igc3RhbmRhcmRzIGZv ciBhIGxvbmcgdGltZSwgSSBzdHJvbmdseSBzdXBwb3J0IHRoZSBDU0lEIGFkb3B0aW9uLg0KDQpS ZXNwZWN0LA0KQ2hlbmcNCg0KDQoNCreivP7Iyzogc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5j ZXNAaWV0Zi5vcmddILT6se0gSmFtZXMgR3VpY2hhcmQNCreiy83KsbzkOiAyMDIxxOoxMNTCMcjV IDIyOjA1DQrK1bz+yMs6IFNQUklORyBXRyA8c3ByaW5nQGlldGYub3JnPg0Ks63LzTogc3ByaW5n LWNoYWlyc0BpZXRmLm9yZw0K1vfM4jogW3NwcmluZ10gV0cgQWRvcHRpb24gY2FsbCBmb3IgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmct c3J2Ni1zcmgtY29tcHJlc3Npb24vDQoNCkRlYXIgV0c6DQoNClRoZSBjaGFpcnMgd291bGQgbGlr ZSB0byBleHByZXNzIHRoZWlyIGFwcHJlY2lhdGlvbiBmb3IgYWxsIHRoZSByZXNwb25zZXMgcmVj ZWl2ZWQgdG8gb3VyIGVtYWlscyB3aXRoIHJlZmVyZW5jZSB0byBob3cgdGhlIHdvcmtpbmcgZ3Jv dXAgd2lzaGVzIHRvIG1vdmUgZm9yd2FyZCB3aXRoIHJlc3BlY3QgdG8gYSBzb2x1dGlvbiBmb3Ig U1J2NiBjb21wcmVzc2lvbi4NCg0KVGhlIGFwcGFyZW50IGluY2xpbmF0aW9uIG9mIHRoZSB3b3Jr aW5nIGdyb3VwIGlzIHRvIHVzZSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8gYXMgdGhlIGJhc2lz IGZvciBpdHMgY29tcHJlc3Npb24gc3RhbmRhcmRpemF0aW9uIHdvcmsuIFRoYXQgaXMgcGFydCBv ZiB3aGF0IHRoaXMgZW1haWwgYXR0ZW1wdHMgdG8gY29uZmlybS4NCg0KQmVjYXVzZSBvZiB0aGUg YWJvdmUgdGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGlzc3VlIGEgMi13ZWVrIFdHIGNhbGwgZm9y IGFkb3B0aW9uIGVuZGluZyBPY3RvYmVyIDE1dGggZm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9u LyBidXQgd2l0aCBzb21lIGNsZWFyIGd1aWRlbGluZXMgYXMgZm9sbG93cy4gQnkgZXhwcmVzc2lu ZyBzdXBwb3J0IGZvciBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IHlvdSBhcmUgZnVsbHkgYXdh cmUgb2YgYW5kIGFyZSBhY2tub3dsZWRnaW5nIHRoYXQ6DQoNCg0KICAxLiAgVGhlIFNQUklORyB3 b3JraW5nIGdyb3VwIGlzIGFkb3B0aW5nIGEgZG9jdW1lbnQgdGhhdCBoYXMgbXVsdGlwbGUgU1J2 NiBFbmRwb2ludCBiZWhhdmlvcnMuDQogIDIuICBUaGUgZG9jdW1lbnQgaXMgYSChsGxpdmluZ6Gx IGRvY3VtZW50OyBpdCBtYXkgY2hhbmdlIGFzIGl0IGdvZXMgdGhyb3VnaCByZXZpZXcgYW5kIGFu YWx5c2lzIGJ5IHRoZSBTUFJJTkcgd29ya2luZyBncm91cC4NCiAgMy4gIEFsbCBvcGVuIGRpc2N1 c3Npb24gcG9pbnRzIHJhaXNlZCBvbiBvdXIgbWFpbGluZyBsaXN0IE1VU1QgYmUgYWRkcmVzc2Vk IEJFRk9SRSBzYWlkIGRvY3VtZW50IGlzIGFsbG93ZWQgdG8gcHJvZ3Jlc3MgZnJvbSB0aGUgd29y a2luZyBncm91cCB0byBwdWJsaWNhdGlvbi4gQSBsaXN0IG9mIHRoZXNlIGRpc2N1c3Npb24gcG9p bnRzIHdpbGwgYmUgZG9jdW1lbnRlZCBpbiB0aGUgV0cgZG9jdW1lbnQgYW5kIG1haW50YWluZWQg YnkgdGhlIGRvY3VtZW50IGVkaXRvciBpbiBjb25qdW5jdGlvbiB3aXRoIHRoZSBjaGFpcnMuDQog IDQuICBJZiB0aGlzIGRvY3VtZW50IGlzIGFkb3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAsIHRo ZSBjaGFpcnMgc3BlY2lmeSBhcyBwYXJ0IG9mIHRoZSBhZG9wdGlvbiBjYWxsIHRoYXQgdGhlIGZv bGxvd2luZyB0ZXh0IGRlc2NyaWJpbmcgYW4gb3BlbiBpc3N1ZSBiZSBhZGRlZCB0byB0aGUgZG9j dW1lbnQgaW4gdGhlIGFib3ZlLWRlc2NyaWJlZCBvcGVuIGlzc3VlcyBzZWN0aW9uOg0KICAgICAq ICAgIkdpdmVuIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHNhaWQgdGhhdCBpdCB3YW50cyB0 byBzdGFuZGFyZGl6ZSBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiwgYW5kIGdpdmVuIHRoYXQgdGhl IGRvY3VtZW50IGNvbnRhaW5zIG11bHRpcGxlIFNSdjYgRW5kUG9pbnQgYmVoYXZpb3JzIHRoYXQg c29tZSBXRyBtZW1iZXJzIGhhdmUgc3RhdGVkIGFyZSBtdWx0aXBsZSBkYXRhIHBsYW5lIHNvbHV0 aW9ucywgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhZGRyZXNzIHdoZXRoZXIgdGhpcyBpcyB2YWxp ZCBhbmQgY29oZXJlbnQgd2l0aCBpdHMgb25lIGRhdGEgcGxhbmUgc29sdXRpb24gb2JqZWN0aXZl LiIuDQoNClBsZWFzZSBjb25zaWRlciB0aGUgYWJvdmUgZ3VpZGVsaW5lcyBhcyB5b3UgZGVjaWRl IG9uIHdoZXRoZXIgdG8gc3VwcG9ydCBvciBub3QgdGhpcyBXRyBhZG9wdGlvbi4gUGxlYXNlIGV4 cHJlc3MgY2xlYXJseSB5b3VyIHJlYXNvbmluZyBmb3Igc3VwcG9ydC9ub24tc3VwcG9ydCBhcyB3 ZWxsIGFzIGFueSBvcGVuIGRpc2N1c3Npb24gcG9pbnRzIHlvdSB3b3VsZCBsaWtlIGFkZHJlc3Nl ZCBzaG91bGQgdGhlIGRvY3VtZW50IGJlIGFkb3B0ZWQgaW50byB0aGUgd29ya2luZyBncm91cC4N Cg0KVGhhbmtzIQ0KDQpKaW0sIEJydW5vICYgSm9lbA0KDQoNCg== --_000_466aa02714f84d81b62a88bd63f8fe1ehuaweicom_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

    Hi SPRING=A3=AC

     

    Sorry for the late response due to the National days break. It se= ems like I miss a lot of discussion, and it did cost me a lot of time to re= ad all the threads.

     

    As a member of the design team, and a person who participates in = IETF SR standards for a long time,  I know who how difficult for us to= get here. Many thanks for the contributions from anyone.

     

    From the outputs of DT team, we know that CSID meets all the requ= irements and provide the best performance. As an author of CSID draft, I ca= n say that over 10 vendors have implemented CSID, which proves that CSID has been adopted by the industry very well. T= herefore, no matter from the aspect of rough consensus and running code, I = do think we should adopt CSID and it is the right way for sure. Also, from = many polls in the mailing list, we also see the consensus of using CSID as the basis of SRv6 compression s= tandard.

     

    Till now, many our customers have chosen the CSID as the SRv6 com= pression solution, and some inter-op test and trial deployment have been fi= nished even one year ago in CMCC=A1=AFs lab and live network, and we will have more product network deployments in the= near future. It proves that CSID can work very well in the product network= . Many thanks for the customers and partners who choose CSID in their netwo= rks and products.

     

    There may be some issues discussed in the mailing list, that is g= ood! It also proves that people are interested in the topic as well, we are= very welcome anyone to make the contributions to the solution, and let=A1=AFs do it together to produce a good solution = for the industry, that is what we are doing all the long way. Therefore, al= so thanks to the people provide comments in the mailing list. Will reply to= the mailing list to answer the questions ASAP.

     

    At the end, as an author, the member of the design team, and a pe= rson who focus on SR standards for a long time, I strongly support the CSID= adoption.

     

    Respect,

    Cheng

     

     

     

    =B7=A2=BC=FE=C8=CB:= spring [mailto:spring-bounces@ietf.org] =B4=FA=B1=ED James Guichard
    =B7=A2=CB=CD=CA=B1=BC=E4:= 2021=C4=EA10=D4=C21=C8=D5 22:05
    =CA=D5=BC=FE=C8=CB: SPRING WG <spring@ietf.org>
    =B3=AD=CB=CD: spring-chairs@ietf.org
    =D6=F7=CC=E2: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-fils= filscheng-spring-srv6-srh-compression/

     

    Dear WG:

     

    The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a sol= ution for SRv6 compression.

     

    The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

     

    Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

     

    1. The SPRING working group is adopting a document that has multiple SRv6 = Endpoint behaviors.
    2. The document is a =A1=B0living=A1=B1 document; i= t may change as it goes through review and analysis by the SPRING working g= roup.
    3. All open discussion points raised on our mailing= list MUST be addressed BEFORE said document is allowed to progress from th= e working group to publication. A list of these discussion points will be documented in the WG document and maintained by the document edito= r in conjunction with the chairs.
    4. If this document is adopted by the working group= , the chairs specify as part of the adoption call that the following text d= escribing an open issue be added to the document in the above-described open issues section:
      • "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will addr= ess whether this is valid and coherent with its one data plane solution obj= ective.".

     

    Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open d= iscussion points you would like addressed should the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    --_000_466aa02714f84d81b62a88bd63f8fe1ehuaweicom_-- From nobody Wed Oct 13 07:08:12 2021 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 AA51B3A0A00 for ; Wed, 13 Oct 2021 07:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, 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 ZFLiVlZnP1q4 for ; Wed, 13 Oct 2021 07:08:04 -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 D534F3A09FF for ; Wed, 13 Oct 2021 07:07:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4HTvW62nprz1pGcf; Wed, 13 Oct 2021 07:07:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1634134066; bh=+CnTcs7yjTwaVgsD9ggbLYBA2Kav2v1mC6e/X5Glu9g=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=OHmvF1xARkwSiRQrrTzBUCmpIhVMaRUt8HxyIrPw1SCSeqK5TVrIVWfe0fwTbznyG d27JaAC9pRkHiWNtkL9PiKJMXa7t1nYqQLP00QYT/dyr3iH30nnknRgpHUNoh/trP0 KaUkFz/+9AM2Aaqb3v+nFc6eL7Eo17FAb4MBYg0Y= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.22.111] (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 4HTvW5441qz1pFHg; Wed, 13 Oct 2021 07:07:44 -0700 (PDT) Message-ID: <1265893a-059c-cbad-c107-cbb009c10ca2@joelhalpern.com> Date: Wed, 13 Oct 2021 10:07:43 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Content-Language: en-US To: Weiqiang Cheng , 'SPRING WG' Cc: "bruno.decraene@orange.com" , 'James Guichard' References: <053a01d7c02a$6c75d520$45617f60$@com> From: "Joel M. Halpern" In-Reply-To: <053a01d7c02a$6c75d520$45617f60$@com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 13 Oct 2021 14:08:10 -0000 I will consider this as we reach the current closure date. Yours, Joel On 10/13/2021 8:04 AM, Weiqiang Cheng wrote: > Dear Chairs and WG, > > As a co-author of this document, I would like to thank all participants > in the discussion. All those discussions, comments and suggestions are > of great value to us. > > It was unexpected that so many IETFers could join the discussion. It is > amazing. It also made me realize that the draft is very valuable. > > Here I would like to raise one suggestion: > > Due to National Day holiday (October 1st to October 7th) in China, many > experts interested in the draft were not fully involved in the discussion. > > Could the Working Group consider extending the adoption call by one week > more so that all members could participate fully in the discussions? > > B.R. > > Weiqiang Cheng > > *发件人:*spring [mailto:spring-bounces@ietf.org] *代表 *James Guichard > *发送时间:*2021年10月1日22:05 > *收件人:*SPRING WG > *抄送:*spring-chairs@ietf.org > *主题:*[spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > Dear WG: > > The chairs would like to express their appreciation for all the > responses received to our emails with reference to how the working group > wishes to move forward with respect to a solution for SRv6 compression. > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > as the basis for its compression standardization work. That is part of > what this email attempts to confirm. > > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15^th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging > that: > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a “living” document; it may change as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the > working group to publication. A list of these discussion points will > be documented in the WG document and maintained by the document > editor in conjunction with the chairs. > 4. If this document is adopted by the working group, the chairs specify > as part of the adoption call that the following text describing an > open issue be added to the document in the above-described open > issues section: > * "Given that the working group has said that it wants to > standardize one data plane solution, and given that the document > contains multiple SRv6 EndPoint behaviors that some WG members > have stated are multiple data plane solutions, the working group > will address whether this is valid and coherent with its one > data plane solution objective.". > > Please consider the above guidelines as you decide on whether to support > or not this WG adoption. Please express clearly your reasoning for > support/non-support as well as any open discussion points you would like > addressed should the document be adopted into the working group. > > Thanks! > > Jim, Bruno & Joel > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > From nobody Wed Oct 13 07:39:09 2021 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 245993A0B5E for ; Wed, 13 Oct 2021 07:38:38 -0700 (PDT) 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, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=liquidtelecom.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 XcndDHshT5_L for ; Wed, 13 Oct 2021 07:38:32 -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 06A573A0B41 for ; Wed, 13 Oct 2021 07:38:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquidtelecom.com; s=mimecast20210406; t=1634135906; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=w2clDmWcdZBCtKCwnL6TgI5q1HiJUB4mLmc1u84Al3Q=; b=DyVvSmYBppbz7YXG61ZZOklersgC2NjaMxcXZG49D+qPembEm/RtLt1PIOC1yTESGX4TVU kObE5IsLKNd5Gh2RioUB+LhzdzXK/Bs8CfyAEYBdacvpUL/RAK38MosL8iKlxjSFUqbJuo TY2niu5ecag/KE9Nup2p6D6Ngx15KIg= Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05lp2174.outbound.protection.outlook.com [104.47.17.174]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-55-puRqDC9QN52hCxT8dSGnkA-1; Wed, 13 Oct 2021 15:38:24 +0100 X-MC-Unique: puRqDC9QN52hCxT8dSGnkA-1 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com (2603:10a6:20b:346::6) by AS8PR03MB7873.eurprd03.prod.outlook.com (2603:10a6:20b:420::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.20; Wed, 13 Oct 2021 14:38:23 +0000 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9]) by AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9%5]) with mapi id 15.20.4587.030; Wed, 13 Oct 2021 14:38:23 +0000 From: Andrew Alston To: SPRING WG Thread-Topic: Further thoughts on g-srv6/csid Thread-Index: AdfAPVhAcfWL+VyISxOgIvLlngm3RA== Date: Wed, 13 Oct 2021 14:38:23 +0000 Message-ID: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f32bf2a9-25ae-4778-78b1-08d98e571c09 x-ms-traffictypediagnostic: AS8PR03MB7873: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: Be28sVurlVk7ORC8N7BwBgc1MYQIMHoNJ9umwzwEYqVxaoRSbaKwj2YvilNiAzsEUXeNoXa/PQNCPMMsTwpP74Gc2DndZuPGUX3vgAwrkFwhjN65dgK6ki6Y+8v+vlUuIFFxk6zYForiv5zuuMBXk3FKkvA8OqMnAtJUljqRr9ZL+Spi7o6kjVGlztZHNGvE8lRz3gBicuVUZD39WS7dB28V52gVmS04bCJ3LFbujWCmCN0LBmwH3KRcI44zpIjtJeSQftjjywVj4TqlwnjJNrhdYGOThxMenrL1bxVKoCG9wb3LMP2jQYj7tHZ2K1yKqMm7h83xby0xVZGJpnSrVWl10idDMv6RWA1E2WmZWPe6wiJ16KuVVpuDrbzW1lczOW1f5ezQamtKCgxIWvR2NP4gRb9lllaDpCNdZU+WSA4GJxVOhY1ceiWYfDHMaiauDzl6sBZMUUc9PF/nx56gYB3kyh0buGKXanV1dbsiXrFZB5KVasfjXM4fArgp4xqksFNUj5fWdyK2P66MjiW+mESgns8va/8zmT7+36T/ULvIjeW8RxLuVLJnrWCp7wMnDYK7vr2nxV6viWcQiTsgpSWCsttq025tuCQa0KSWzzbIEJPnAinRHcNPS4N7xje5AbMBVPn1Og1si72C0DkbldcDUGGvIMswh9RqXabZwe799fy29IrFgUxRmB2qbnrtgemfG5qXzien5cbGLMtVlA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR03MB7622.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(186003)(38070700005)(9326002)(7696005)(6506007)(8676002)(71200400001)(66574015)(8936002)(86362001)(6916009)(83380400001)(9686003)(122000001)(316002)(5660300002)(76116006)(66476007)(38100700002)(66946007)(52536014)(55016002)(66446008)(64756008)(66556008)(2906002)(33656002)(508600001); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?Pb74AFZm8ZU1zCawL3Qovo8s7S+IZJr/w4ycZsRfCEXnIlMO2rNTd+OQucFp?= =?us-ascii?Q?9tBLZOBWNKBig2Ceb8VtgjZ1XXg17RxJouwWYELQWBUK3ykJewuCb6exgdQ5?= =?us-ascii?Q?BRVZQSaAWGtJin8NdGJpCMuqRPU9xGgxD3D3e7Q/+9X9JkWDxy17j1RnmdNm?= =?us-ascii?Q?2sbcj9YqeKVUKBG7zmjsAiLkoSHFEzVMp+vbaZOfzHucUU+VQzdLFWeOn+vt?= =?us-ascii?Q?MTkUA40y+Q3SPe2ToulwrbSd7Qcb6ci2Rgt3rA55W1V8LosyPXhPsrQ1YGKx?= =?us-ascii?Q?ht0uIoK1nAz/1/GzFe9foAT7YuOxHjHWNcnJtad+ABcoLX72WE4NXfuaWAIl?= =?us-ascii?Q?/P1D6G4W94x7h4/93KRpCuDpK7R79nCy+b7u1SbUl/6QZh17AUIWkhZw/rA8?= =?us-ascii?Q?f36fzqs6dyFkF2P7EXfLfWi6yYly7HQqtWGmVUVvaJMWJJbEPUp6Jmb1NCah?= =?us-ascii?Q?88bHnu+vz+wdKZueFS1Y8Wy29q5nUv1VOXAubXGD7fe7YmnE4pxQHdavl1Ev?= =?us-ascii?Q?TrkLzJVgjHg83NbOGVQ/Ui5n0J6yK5HrmPuHWYmMukYK2qUv69iG2nTPadJE?= =?us-ascii?Q?UZk9IczhlzMZ8MUUbhKTrphdxinlmSJE0jhpEItfJqYmxgk/LB3WMx34FVMs?= =?us-ascii?Q?XkZBhNeL7arZoHBruRtsMOUvaj1GzPKP/g9VXrBUsxG5fqAe8XSHc26ES6Z0?= =?us-ascii?Q?zwOQeuolERAG8n9A/XZgsuFcL76sgpHNpzfOmX3/DjgEsmmIJGY9cI+7tIOR?= =?us-ascii?Q?SiZI1m5cO6PE9W2gzldfTrnwRKujBtHyuKUBEDN3kfDfth6XlSIf9rXrIdm9?= =?us-ascii?Q?pSbOuprIe9TyEBjgSAXYDZ0JdPFS4LWV7IjmB9zSPcKr2yE2SwJNDaWXA9Ci?= =?us-ascii?Q?SjcLnqZfFoV1cjYivCI3ii1Nq2vjZgBHBgPj7Itfe3Hy4tQqqmcr8SlEZIZy?= =?us-ascii?Q?+GThMFdSCTkKAAFJ7OEEKb6TVkr9lUpPezXyOVrGljms63edZh+MvN1rvdgP?= =?us-ascii?Q?R33DiQk+LAVfSU1DlvCEfB+bpQm9jaLy/ReqXLfZHMojJTQbtDiaVzuQpQnG?= =?us-ascii?Q?DlgcjHcga7K886Pj3IWA2fg0pHGcs6Hcjk+6mALMOIglx93SwTOEKDZrL5ug?= =?us-ascii?Q?nRezldv0W3rGUKN0CpOQE3T4FJNrExqGI7H4rQwJTIsREXNjerjEq7TpQ2US?= =?us-ascii?Q?HATiUA7qsAjxwoNh0CmsDBsQlvIpawKNdwHD0LEu/Yq48cxBQEUGym5PBiLT?= =?us-ascii?Q?XxRuu86gxvBfEwmtIDsQTgWRu0Lx6qLzXKBHdFMkG4aGapzPC80BeOdZ7eJD?= =?us-ascii?Q?1+8cOaBW00mT/tCPsdjzwCePj4u1YqRzL1cGImHnFjX/edxFPIZbrLx62XGV?= =?us-ascii?Q?In3GYbE=3D?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB7622.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f32bf2a9-25ae-4778-78b1-08d98e571c09 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2021 14:38:23.2600 (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: LV5YfmFE/ZYSpkJyiToM/btgo0wJRgEqiFSHcmWnYRdWX1i7VehHGC0XTYGGsN7wHf1LRbXjoh5ilWxggHYNNlYR47Xzxz0a/ZV64Tng7vA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7873 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquidtelecom.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_AS8PR03MB7622B9A3BAE56F3ABD8B55B1EEB79AS8PR03MB7622eurp_" Archived-At: Subject: [spring] Further thoughts on g-srv6/csid 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, 13 Oct 2021 14:38:43 -0000 --_000_AS8PR03MB7622B9A3BAE56F3ABD8B55B1EEB79AS8PR03MB7622eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi All, So - to understand the claims of compatibility between the behaviors within= the same domain - I decided the best way to test this was to write some ac= tual code to simulate it. I'm hoping to get the full simulation code out i= n the next 24 hours - but in the mean time I figured I'd add some thoughts = here on the list so that any assumptions and readings I have of the documen= ts that are incorrect can be corrected so I can adjust my code for these th= ings to make it more accurate. However - so far, I observe the following. Firstly - on an ingress node that must encapsulate with a stack of srh head= ers - there is an assumption that the encapsulation is always going to be c= orrect as regards the various node sid sizes and behaviors. For example - = if you were to create something using purely next behavior - and in the net= work you were running a combination of 16bit and 32bit - the assumption is = that the node receiving the packet is configured for that size - and the sh= ift it does on the address matches that size. However, if the encapsulatio= n is wrong - you could end up shifting 32bit when you meant to shift 16bit = or vice versa - and ending up with some entirely undefined behavior - since= the packet itself contains no information that lets the node determine the= sid size its meant to shift by - it ASSUMES the encapsulating node got it = right. That seems very fragile to me. This gets even worse in a mixed replace/next scenario. Again - because the= node receiving the encapsulated packet has no way to determine from what I= can see, what is in that routing header, you can end up with a situation w= here a node applies replace behavior to what is meant to be next behavior o= r vice versa - and again - undefined behavior. That's the very definition = of fragile, since it assumes that either the controller always got it right= , or in the case of something being statically configured for pathing, that= the human who configured the path got the flavors right in their path defi= nition - because there ain't no room for error there. Then - we get to the issue of the encapsulation itself. In the event that = this is all controller driven - and the controller is constructing that SRH= and the router is basically storing the SRH and just applying it - that's = not gonna hurt. However, if the router itself has to do a mixed constructi= on - that - is a pretty performance heavy operation by anyone's standards. = Yes, the transit node can handle the behaviors at line rate - but the head= er construction at the ingress node makes me wonder about potential perform= ance hits. (there are ways to mitigate this - which are going to be implem= entation dependent, but it would be worth making some suggestions on this i= n the document) Basically - what we've now got is a situation where - it can be argued thes= e things can work together in the same domain - but the potential for break= age and undefined behavior is off the charts. Without some way embedded in= the packet to verify what behavior and sid size is in that routing header = - I can see not only mistakes happening - but potential exploitable issues = here - because of the potential for defined behavior against wrong data whi= ch will produce undefined results. This is over and above the cases that Greg mentioned in his email - and in = the simulation code - those things will be able to be simulated and it will= become pretty clear as to the results. But - as I said - if anyone sees a= ny problems with my assumptions here - please - let me know and I can adjus= t the simulation code before release. Thanks Andrew --_000_AS8PR03MB7622B9A3BAE56F3ABD8B55B1EEB79AS8PR03MB7622eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

    Hi All,

     

    So – to understand the claims of compatibility= between the behaviors within the same domain – I decided the best wa= y to test this was to write some actual code to simulate it.  I’= m hoping to get the full simulation code out in the next 24 hours – but in the mean time I figured I’d add some thought= s here on the list so that any assumptions and readings I have of the docum= ents that are incorrect can be corrected so I can adjust my code for these = things to make it more accurate.

     

    However – so far, I observe the following.

     

    Firstly – on an ingress node that must encapsu= late with a stack of srh headers – there is an assumption that the en= capsulation is always going to be correct as regards the various node sid s= izes and behaviors.  For example – if you were to create something using purely next behavior – and in the network = you were running a combination of 16bit and 32bit – the assumption is= that the node receiving the packet is configured for that size – and= the shift it does on the address matches that size.  However, if the encapsulation is wrong – you could end up shifting 3= 2bit when you meant to shift 16bit or vice versa – and ending up with= some entirely undefined behavior – since the packet itself contains = no information that lets the node determine the sid size its meant to shift by – it ASSUMES the encapsulating node got i= t right.  That seems very fragile to me.

     

    This gets even worse in a mixed replace/next scenari= o.  Again – because the node receiving the encapsulated packet h= as no way to determine from what I can see, what is in that routing header,= you can end up with a situation where a node applies replace behavior to what is meant to be next behavior or vice vers= a – and again – undefined behavior.  That’s the very= definition of fragile, since it assumes that either the controller always = got it right, or in the case of something being statically configured for pathing, that the human who configured the path got the fla= vors right in their path definition – because there ain’t no ro= om for error there.

     

    Then – we get to the issue of the encapsulatio= n itself.  In the event that this is all controller driven – and= the controller is constructing that SRH and the router is basically storin= g the SRH and just applying it – that’s not gonna hurt.  However, if the router itself has to do a mixed construction – that = – is a pretty performance heavy operation by anyone’s standards= .  Yes, the transit node can handle the behaviors at line rate –= but the header construction at the ingress node makes me wonder about potential performance hits.  (there are ways to mitigate this &= #8211; which are going to be implementation dependent, but it would be wort= h making some suggestions on this in the document)

     

    Basically – what we’ve now got is a situ= ation where – it can be argued these things can work together in the = same domain – but the potential for breakage and undefined behavior i= s off the charts.  Without some way embedded in the packet to verify what behavior and sid size is in that routing header – I c= an see not only mistakes happening – but potential exploitable issues= here – because of the potential for defined behavior against wrong d= ata which will produce undefined results.

     

    This is over and above the cases that Greg mentioned= in his email – and in the simulation code – those things will = be able to be simulated and it will become pretty clear as to the results.&= nbsp; But – as I said – if anyone sees any problems with my assumptions here – please – let me know and I can adju= st the simulation code before release.

     

    Thanks

     

    Andrew

     

     

     

     

    --_000_AS8PR03MB7622B9A3BAE56F3ABD8B55B1EEB79AS8PR03MB7622eurp_-- From nobody Wed Oct 13 08:38:16 2021 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 1C70F3A0B6E; Wed, 13 Oct 2021 08:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9t7O13skTuS; Wed, 13 Oct 2021 08:38:07 -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 849153A0B67; Wed, 13 Oct 2021 08:38:06 -0700 (PDT) Received: from fraeml704-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HTxRC33dXz6809b; Wed, 13 Oct 2021 23:34:31 +0800 (CST) Received: from dggpemm500001.china.huawei.com (7.185.36.107) by fraeml704-chm.china.huawei.com (10.206.15.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.8; Wed, 13 Oct 2021 17:37:59 +0200 Received: from dggpemm500003.china.huawei.com (7.185.36.56) by dggpemm500001.china.huawei.com (7.185.36.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.8; Wed, 13 Oct 2021 23:37:58 +0800 Received: from dggpemm500003.china.huawei.com ([7.185.36.56]) by dggpemm500003.china.huawei.com ([7.185.36.56]) with mapi id 15.01.2308.008; Wed, 13 Oct 2021 23:37:58 +0800 From: "Chengli (Cheng Li)" To: Gyan Mishra , "Francois Clad (fclad)" CC: James Guichard , SPRING WG , Yisong Liu , spring-chairs Thread-Topic: =?utf-8?B?W3NwcmluZ10gUkXvvJogV0cgQWRvcHRpb24gY2FsbCBmb3IgaHR0cHM6Ly9k?= =?utf-8?B?YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1z?= =?utf-8?Q?pring-srv6-srh-compression/?= Thread-Index: AQHXvhS2F/2QHLYncEixWQ/uTW9oy6vRDiaA Date: Wed, 13 Oct 2021 15:37:58 +0000 Message-ID: <1c919ecf8db842dc8ecda349a74b741c@huawei.com> References: <202110021255323466813813@chinamobile.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.45.145.61] Content-Type: multipart/related; boundary="_004_1c919ecf8db842dc8ecda349a74b741chuaweicom_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [spring] =?utf-8?b?562U5aSNOiAgUkXvvJogV0cgQWRvcHRpb24gY2FsbCBm?= =?utf-8?q?or_https=3A//datatracker=2Eietf=2Eorg/doc/draft-filsfilscheng-s?= =?utf-8?q?pring-srv6-srh-compression/?= 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, 13 Oct 2021 15:38:13 -0000 --_004_1c919ecf8db842dc8ecda349a74b741chuaweicom_ Content-Type: multipart/alternative; boundary="_000_1c919ecf8db842dc8ecda349a74b741chuaweicom_" --_000_1c919ecf8db842dc8ecda349a74b741chuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3lhbiwNCg0KU29ycnkgZm9yIHRoZSBsYXRlIHJlcGx5LiBUaGFuayB5b3UgZm9yIHJlYWRp bmcgdGhlIGRyYWZ0IHNvIGNhcmVmdWxseSwgcmVhbGx5IGFwcHJlY2lhdGVkLiBCdXQgSSB3aWxs IHJlY29tbWVuZCB5b3UgdG8gc3BsaXQgdGhlIGNvbW1lbnRzIGludG8gc21hbGwgZW1haWxzIHNv IHRoYXQgd2UgY2FuIGRpc2N1c3MgZWFzaWx5LiBMT0wuDQpSZWdhcmRpbmcgdGhlIGlsbHVzdHJh dGlvbnMsIHllcywgaXQgY2FuIGJlIGFkZGVkIGxhdGVyIG9uLiBBbmQgYWxzbyBGcmFuY29pcyBw cm92aWRlcyB0aGUgZXhhbXBsZSBhbHJlYWR5LCBwbGVhc2UgcmVmZXIgdG8gaXQuDQoNCkxpa2Ug eW91IHF1b3RlIGZyb20gdGhlIGRyYWZ0LCBSRVBMQUNFLUNTSUQgYW5kIE5FWFQtQ1NJRCBjYW4g c3VwcG9ydGVkIGJvdGggdGhlIDE2LWJpdCBhbmQgMzItYml0IHNvbHV0aW9uLCBidXQgZnJvbSB0 aGUgY29uc2lkZXJhdGlvbnMgb2YgdHJhZGUtb2ZmIG9mIGJldHRlciBjb21wcmVzc2lvbiBhbmQg ZWFzeSBvcGVyYXRpb24sIE5FWFQtQ1NJRCByZWNvbW1lbmRzIDE2LWJpdCBhbmQgUkVQTEFDRS1D U0lEIHJlY29tbWVuZHMgMzItYml0LiBGcm9tIHRoZSB0ZXh0LCB5b3UgYWxzbyBjYW4gc2VlIHVz aW5nIHRoZSBjb21tb24gZGVzaWduIG9mIEdJQi9MSUIsIGJvdGggZmxhdm9ycyBjYW4gc3VwcG9y dCAxNi1iaXQgc29sdXRpb24uDQoNCg0KRnJvbSB0aGUgc2VjdGlvbiA0IGluIHRoZSBkcmFmdCBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWZpbHNmaWxzY2hlbmct c3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uI3NlY3Rpb24tNCwgaXQgYWxzbyBzdGF0ZXMgdGhh dA0KDQoNCg0KIEl0IGlzIHJlY29tbWVuZGVkIGZvciBlYXNlIG9mIG9wZXJhdGlvbiB0aGF0IGEg c2luZ2xlIGNvbXByZXNzZWQNCiAgIGVuY29kaW5nIGZsYXZvciBiZSB1c2VkIGluIGEgZ2l2ZW4g U1J2NiBkb21haW4uICBIb3dldmVyLCBpbiBhIG11bHRpLQ0KICAgZG9tYWluIGRlcGxveW1lbnQs IGRpZmZlcmVudCBmbGF2b3JzIGNhbiBiZSB1c2VkIGluIGRpZmZlcmVudA0KICAgZG9tYWlucy4N Cg0Kc28gd2Ugc2hvdWxkIGF2b2lkIHRvIG1peCBkaWZmZXJlbnQgbGVuZ3RoIG9mIENTSURzIGlu IGEgc2luZ2xlIGNvbnRhaW5lciwgdGhvdWdoIHdlIGNhbiBkbyBpdC4NCg0KVGhhbmtzLA0KQ2hl bmcNCg0KDQoNCg0K5Y+R5Lu25Lq6OiBHeWFuIE1pc2hyYSBbbWFpbHRvOmhheWFidXNhZ3NtQGdt YWlsLmNvbV0NCuWPkemAgeaXtumXtDogMjAyMeW5tDEw5pyIMTHml6UgNDoyMw0K5pS25Lu25Lq6 OiBDaGVuZ2xpIChDaGVuZyBMaSkgPGMubEBodWF3ZWkuY29tPjsgRnJhbmNvaXMgQ2xhZCAoZmNs YWQpIDxmY2xhZEBjaXNjby5jb20+DQrmioTpgIE6IEphbWVzIEd1aWNoYXJkIDxqYW1lcy5uLmd1 aWNoYXJkQGZ1dHVyZXdlaS5jb20+OyBTUFJJTkcgV0cgPHNwcmluZ0BpZXRmLm9yZz47IFlpc29u ZyBMaXUgPGxpdXlpc29uZ0BjaGluYW1vYmlsZS5jb20+OyBzcHJpbmctY2hhaXJzIDxzcHJpbmct Y2hhaXJzQGlldGYub3JnPg0K5Li76aKYOiBSZTogW3NwcmluZ10gUkXvvJogV0cgQWRvcHRpb24g Y2FsbCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNj aGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vDQoNCg0KSGkgRnJhbmNvaXMsIENoZW5n bGkgJiBhdXRob3JzDQoNCk1hbnkgVGhhbmtzIGZvciB5b3VyIGZlZWRiYWNrIHRvIHRoZSBXRyBv biB0aGUgY3JpdGljYWwgdG9waWMgaW50ZXJvcGVyYWJpbGl0eSBvZiB0aGUgdVNJRCBtaWNyby1z aWQgMTYgYml0IHVTSUQgICDigJxORj1Mb2NhdG9yL0Z1bmN0aW9uIGNvbWJv4oCdICAxMjggYml0 IGNvbnRhaW5lciBiYXNlZCBzb2x1dGlvbiBhbmQgdGhlIEctU1JWNiAzMiBiaXQgRy1TSUQg4oCc TkY9TG9jYXRvci9GdW5jdGlvbiBjb21ib+KAnSA0IC0gMzIgYml0IEctU0lEIGluIDEyOCBiaXQg Y29udGFpbmVyIGJhc2VkIHNvbHV0aW9uIGRlZmluZWQgYXMgTmV4dCBhbmQgUmVwbGFjZSBmbGF2 b3JzIGluIHRoZSBkcmFmdC4NCg0KSSBhbSByZWFsbHkgY29uY2VybmVkIGFzIHRvIGhvdyB0aGUg bmV4dCBhbmQgcmVwbGFjZSBpbnRlcm9wZXJhYmlsaXR5IHdvdWxkIHdvcmsgZm9yIGFkamFjZW50 IG5vZGVzIHVzaW5nIFNJRCB3aXRoaW4gc2FtZSBvciBhZGphY2VudCBjb250YWluZXIuDQoNClNl Y3Rpb24gNi4xIG1lbnRpb25zIHRoYXQgIE5leHQgZmxhdm9yIHJlY29tbWVuZGF0aW9uIGlzIGZv ciAxNiBiaXQgYXMgdGhlIHVTSUQgZHJhZnQgJiB0aGlzIGRyYWZ0IE5GIGFzIDE2IGJpdCBpcyBt b3N0IG9wdGltYWwgdVNJRCBzaXplIHdpdGhpbiB0aGUgdVNJRCBjb250YWluZXIgYW5kIFJlcGxh Y2UgZmxhdm9yIHJlY29tbWVuZGF0aW9uIGlzIGZvciAxNiBiaXQgYXMgdGhlIEctU1JWNiBkcmFm dCAmIHRoaXMgZHJhZnQgTkYgYXMgMzIgYml0IEctU0lEIGlzIG1vc3Qgb3B0aW1hbCBHLVNJRCBz aXplIHdpdGhpbiB0aGUgRy1TSUQgY29udGFpbmVyLg0KDQpQbGVhc2UgIGVsYWJvcmF0ZSBvbiB0 aGlzIGluIG1vcmUgZGV0YWlsLCBhcyB3aXRoIHRoaXMgZHJhZnQgZm9yIG5leHQgYW5kIHJlcGxh Y2UgaW50ZXJvcGVyYWJpbGl0eSwgZm9sbG93aW5nIHRoZSBTUnY2IGNvbXByZXNzaW9uIHJlcXVp cmVtZW50cyBmb3Igb3B0aW1hbCBoYXJkd2FyZSBmb3J3YXJkaW5nIGFuZCBzdGF0ZSBlZmZpY2ll bmN5IHRoYXQgTmV4dCB3b3VsZCBiZSByZWNvbW1lbmRlZCB0byB1c2UgMTYgYml0IFNJRCBhbmQg UmVwbGFjZSB3b3VsZCBiZSByZWNvbW1lbmRlZCAzMiBiaXQgU0lELiAgIFBsZWFzZSBlbGFib3Jh dGUgaW4gZGV0YWlsIGFzIHRvIHdoeSAxNiBiaXQgaXMgbm90IHJlY29tbWVuZGVkIGZvciByZXBs YWNlIGZsYXZvciBhbmQgMzIgYml0IGlzIG5vdCByZWNvbW1lbmRlZCBmb3IgbmV4dCBmbGF2b3Ig Zm9yIGFsbCBvZiB0aGUgcmVxdWlyZW1lbnRzIGRyYWZ0cyBsaXN0IG9mIFNSdjYgY29tcHJlc3Np b24gcmVxdWlyZW1lbnRzIGVhY2ggb25lIGJ5IG9uZSBhbmQgdGhlIHByb2JsZW1zIGVuY291bnRl cmVkIHdoZW4gbm90IHVzaW5nIHRoZSByZWNvbW1lbmRlZCBTSUQgbGVuZ3RoLg0KDQpUaHVzIGZv ciBuZXh0IGFuZCByZXBsYWNlIGZsYXZvciBpbnRlcm9wZXJhYmlsaXR5IGV2ZW4gcG9zc2libGUg IHRvIHdvcmsgd291bGQgcmVxdWlyZSB0d28gZGlmZmVyZW50IFNJRCBzaXplcyB3aXRoaW4gdGhl IHNhbWUgY29udGFpbmVyIGludGVyb3BlcmFiaWxpdHkgY2F2ZWF0cyBhbmQgbm93IHlvdSBoYXZl IHRvIGRlYWwgd2l0aCB1U0lEIGNvbnRhaW5lciBzdHlsZSB1c2luZyAxNiBiaXQgU0lEIGFuZCBH LVNJRCBjb250YWluZXIgc3R5bGUgdXNpbmcgMzIgYml0IFNJRC4NCg0KRnJvbSB0aGUgcmVxdWly ZW1lbnRzIGRyYWZ0LCAgaW50ZXJvcGVyYWJpbGl0eSBwZXJzcGVjdGl2ZSwgdGhlIHByaW1hcnkg b2JqZWN0aXZlIGlzIOKAnGVuY2Fwc3VsYXRpb24gaGVhZGVyIGNvbXByZXNzaW9u4oCdIGFzIHRo YXQgaXMgd2hhdCB3ZSBoYXZlIHNwZW50IG92ZXIgYSB5ZWFyIG9uIHdpdGggRFQgZmluZGluZyBh biBvcHRpbWFsIGNvbXByZXNzaW9uIHNvbHV0aW9uLiAgU28gaGVyZSB0aGUgbG93ZXN0IGNvbW1v biBkZW5vbWluYXRvciBlbmRzIHVwIGJlaW5nIDMyIGJpdCBTSUQgYW5kIHdlIG5vdyBoYXZlIGZh aWxlZCB0aGUgcHJpbWFyeSBvYmplY3RpdmUgb2YgYSBjb21wcmVzc2lvbiBzb2x1dGlvbi4NCg0K QXMgZmFyIGFzIGxvd2VzdCBjb21tb24gZGVub21pbmF0b3IgaXMgaXQgdHJ1ZSB0aGF0IGluIG9y ZGVyIHRvIG1lZXQgYWxsIHRoZSByZXF1aXJlbWVudHMgZHJhZnQgbGlzdCBvZiBhbGwgU1J2NiBj b21wcmVzc2lvbiByZXF1aXJlbWVudHMgYm90aCBuZXh0IGFuZCByZXBsYWNlIGhhdmUgdG8gcmV2 ZXJ0IHRvIHRoYXQgbG93ZXN0IGNvbW1vbiBkZW5vbWluYXRvciB3aGljaCBpcyAzMiBiaXQgU0lE LiAgSWYgdGhhdCBpcyB0cnVlLCB1bmZvcnR1bmF0ZWx5IHRoYXQgbWFrZXMgdGhlIGRyYWZ0IGZh aWwgdGhlIHByaW1hcnkgb2JqZWN0aXZlIG9mIGFueSBTUnY2IGNvbXByZXNzaW9uIHNvbHV0aW9u Lg0KDQpUbyB0aGF0IGVuZCBhcyBmYXIgYXMgaW50ZXJvcGVyYWJpbGl0eSBvbiBOZXh0IGFuZCBS ZXBsYWNlIGludGVyb3BlcmFiaWxpdHkgYmVpbmcgdGhlIGhpbmdlIHBpbiBvZiB0aGlzIGRyYWZ0 cyBhZG9wdGlvbiwgYXMgd2VsbCBldmVuIGlmIHRoZSBhdXRob3JzIHN0YXRlIHRoYXQgUmVwbGFj ZSBjYW4gdXNlIDE2IGJpdCBTSUQgYXMgYSBwb3NzaWJpbGl0eSwgYXMgdGhlIDMyIGJpdCDigJxO RuKAnSBHLVNJRCBpcyByZWNvbW1lbmRlZCBmb3IgaGFyZHdhcmUgZm9yd2FyZGluZyBlZmZpY2ll bmN5IGFuZCBzY2FsYWJpbGl0eSB0aGF0IGlmIDE2IGJpdCB3ZXJlIHVzZWQgRy1TSUQgd291bGQg ZmFpbCB0aGUgaGFyZHdhcmUgZm9yd2FyZGluZyBlZmZpY2llbmN5IGFuZCBzY2FsYWJpbGl0eSBy ZXF1aXJlbWVudHMgYXMgd2VsbCBhcyBwb3NzaWJseSBvdGhlciByZXF1aXJlbWVudHMgd2hpY2gg c2hvdWxkIGFsc28gYmUgc3RhdGVkIGluIHRoZSBkcmFmdC4NCg0KDQo2LjE8aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2 LXNyaC1jb21wcmVzc2lvbi0wMiNzZWN0aW9uLTYuMT4uICBDLVNJRCBMZW5ndGgNCg0KDQoNCiAg IFRoZSBORVhULUMtU0lEIGZsYXZvciBzdXBwb3J0cyBib3RoIDE2LSBhbmQgMzItYml0IEMtU0lE IGxlbmd0aHMuICBBDQoNCiAgIEMtU0lEIGxlbmd0aCBvZiAxNi1iaXQgaXMgcmVjb21tZW5kZWQu DQoNCg0KDQogICBUaGUgUkVQTEFDRS1DLVNJRCBmbGF2b3Igc3VwcG9ydHMgYm90aCAxNi0gYW5k IDMyLWJpdCBDLVNJRCBsZW5ndGhzLg0KDQogICBBIEMtU0lEIGxlbmd0aCBvZiAzMi1iaXQgaXMg cmVjb21tZW5kZWQuDQoNClRoZSBkcmFmdCBzaG91bGQgbWVudGlvbiB0aGUgcmVjb21tZW5kYXRp b24gZm9yIGNvbW1vbiBibG9jayBsZW5ndGggZm9yIGludGVyb3BlcmFiaWxpdHkuICBUaGUgb25s eSBibG9jayBzaXplIHBvc3NpYmxlIGlzIDQ4IGJpdCBzbyBibG9jayBzaXplIHNvIHRoYXQgd291 bGQgYmUgYSBtYWpvciBhZGRyZXNzaW5nIGluZmxleGliaWxpdHkgZm9yIGludGVyb3BlcmFiaWxp dHkuDQoNCg0KNi4yPGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt Zmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24tMDIjc2VjdGlvbi02LjI+ LiAgQmxvY2sgTGVuZ3RoDQoNCg0KDQogICBUaGUgcmVjb21tZW5kZWQgU1J2NiBTSUQgYmxvY2sg c2l6ZXMgZm9yIHRoZSBORVhULUMtU0lEIGZsYXZvciBhcmUNCg0KICAgMTYsIDMyIG9yIDQ4IGJp dHMuICBUaGUgc21hbGxlciB0aGUgYmxvY2ssIHRoZSBoaWdoZXIgdGhlIGNvbXByZXNzaW9uDQoN CiAgIGVmZmljaWVuY3kuDQoNCg0KDQogICBUaGUgcmVjb21tZW5kZWQgU1J2NiBTSUQgYmxvY2sg c2l6ZSBmb3IgdGhlIFJFUExBQ0UtQy1TSUQgZmxhdm9yIGNhbg0KDQogICBiZSA0OCwgNTYsIDY0 LCA3MiBvciA4MCBiaXRzLCBkZXBlbmRpbmcgb24gdGhlIG5lZWRzIG9mIHRoZSBvcGVyYXRvci4N Cg0KDQpUYWtpbmcgdGhpcyBmdXJ0aGVyIGFub3RoZXIgc3RlcCBhcyB0aGlzIGRyYWZ0IG5lZWRz IHRvIGRlc2NyaWJlIGluIGRldGFpbCB3aXRoIGV4YW1wbGVzIG9mIHRoZSBmZWFzaWJpbGl0eSBv ZiBob3cgdHdvIGFkamFjZW50IG5vZGVzIG9uZSB1c2luZyBuZXh0IDE2IGJpdCBTSUQgYW5kIG90 aGVyIHVzaW5nIHJlcGxhY2UgMzIgYml0IFNJRCBhcyByZWNvbW1lbmRlZCB3aGVyZSB0aGUgMTYg Yml0IHVTSUQgbmV4dCBmbGF2b3IgYW5kIDMyIGJpdCBHLVNJRCBhcmUgaW4gdGhlIHNhbWUgU1JI IDEyOCBiaXQgY29udGFpbmVyLg0KDQpBcyB0aGUgdVNJRCBOZXh0IGZsYXZvciBkcmFmdCBwZXJm b3JtcyBhIHNoaWZ0IHRvd2FyZHMgQiB0b3dhcmRzIG5pYmJsZSBBLCBCIG5pYmJsZXMsIGFuZCBS ZXBsYWNlIGRvZXMgYSByZXBsYWNlIG9mIHRoZSBBLUFyZyBwb3J0aW9uICBvZiB0aGUgMTI4IGJp dCBJUHY2IGFkZHJlc3MsIGhvdyB3b3VsZCB0aGF0IHdvcmsgd2l0aCBhZGphY2VudCBub2RlcyB1 c2luZyBkaWZmZXJlbnQgU0lEIGZsYXZvcnMgb2YgZGlmZmVyZW50IFNJRCBsZW5ndGhzLg0KDQoN ClRoZSBOZXh0IGZsYXZvciB1U0lEIFNSdjYgUEdNICBjb21wcmVzc2lvbiBzb2x1dGlvbiBwcm9j ZXNzIGlzIHZlcnkgZGlmZmVyZW50IHdoZXJlIHdoZW4gaW5kZXhpbmcgdGhlIG1pY3JvIHNpZCBu aWJibGVzIHdpdGhpbiB0aGUgMTI4IGJpdCBjb250YWluZXIsIGl0IHBlcmZvcm1zIGEgc2hpZnQg dG93YXJkcyB0aGUgdG9wIGxvd2VyIG9yZGVyIGJpdHMgb2YgdGhlIElQdjYgYWRkcmVzcywgd2hl cmUgdGhlIFJlcGxhY2UgZmxhdm9yIEctU1J2NiBQR00gY29tcHJlc3Npb24gc29sdXRpb24gaW5k ZXhpbmcgdGhlIDQgRy1TSURzIHdpdGhpbiB0aGUgY29udGFpbmVyIGRvZXMgYSBSZXBsYWNlIGF0 IHRoZSBBLUFyZyBib3R0b20gaGlnaGVyIG9yZGVyIGJpdHMuDQoNClRoZSByZWZlcmVuY2luZyBv ZiB0aGUgMTYgdVNJRCBvciAzMiAgYml0IEctU0lEICBuaWJibGVzLCBpbmRleGluZyBhbmQgcmVm ZXJlbmNlIG9mIHdoaWNoIG5pYmJsZSB0byByZWZlcmVuY2VkIGZvciBuZXh0IGFuZCByZXBsYWNl IGZvciBkaXJlY3RseSBhZGphY2VudCBub2RlcyB3aXRoIG5pYmJsZXMgd2l0aGluIHRoZSBzYW1l IDEyOCBiaXQgY29udGFpbmVyIG9yIGFkamFjZW50IGNvbnRhaW5lcnMgaXMgdGhlIGludGVyb3Bl cmFiaWxpdHkgaXNzdWUgdGhhdCBzZWVtcyB0byBleGlzdC4NCg0KVGhpcyBuZWVkcyB0byBiZSBj bGFyaWZpZWQgb24gdGhlIG5leHQgc25kIHJlcGxhY2UgaW50ZXJvcGVyYWJpbGl0eSBvcGVyYXRp b24gaW4gZGV0YWlsLg0KDQpBbHNvIFJlcGxhY2UgZmxhdm9yIHVzZXMgQ09DIGRlbGltaXRlciBm b3Igc2lnbmFsaW5nIGNvbXByZXNzaW9uIGZ1bmN0aW9uIGlzIGFjdGl2ZSB3aGVyZSBOZXh0IGRv ZXMgbm90IGhhdmUgYW55IHNpZ25hbGluZyBvZiBjb21wcmVzc2lvbiBiZWluZyBhY3RpdmUgb3Ig bm90IG9yIG1heSBoYXZlIGEgZGlmZmVyZW50IHdheSBvZiBzaWduYWxpbmcgdGhhdCB1cGNvbWlu ZyBub2RlIGRvZXMgbm90IHN1cHBvcnQgY29tcHJlc3Npb24uDQoNCkhvdyBkb2VzIHRoZSBjb21w cmVzc2lvbiBzaWduYWxpbmcgaW50ZXJvcGVyYWJpbGl0eSB3b3JrIGJldHdlZW4gTmV4dCBhbmQg UmVwbGFjZSBmbGF2b3JzLiAgVGhhdCBzaG91bGQgYmUgYWRkcmVzc2VkIGFzIHdlbGwgaW4gdGhl IGRyYWZ0Lg0KDQpLaW5kIFJlZ2FyZHMNCg0KR3lhbg0KVmVyaXpvbiBJbmMNCg0KT24gRnJpLCBP Y3QgOCwgMjAyMSBhdCAxOjM0IFBNIEZyYW5jb2lzIENsYWQgKGZjbGFkKSA8ZmNsYWRAY2lzY28u Y29tPG1haWx0bzpmY2xhZEBjaXNjby5jb20+PiB3cm90ZToNCkhpIEd5YW4sDQoNCkl0IGlzIHBv c3NpYmxlIHRvIGNvbWJpbmUgU0lEcyBvZiBkaWZmZXJlbnQgQy1TSUQgZmxhdm9ycyBhbmQgQy1T SUQgbGVuZ3RocyBpbiB0aGUgc2FtZSBTUkgsIGFsb25nIHdpdGggdGhvc2UgZGVmaW5lZCBpbiBS RkMgODk4NiBBZnRlciBhbGwsIHRoZXkgbGV2ZXJhZ2UgdGhlIHNhbWUgU1J2NiBkYXRhIHBsYW5l Lg0KDQpMZXQgbWUgZ2l2ZSB5b3UgYW4gZXhhbXBsZS4NCg0KQXNzdW1lIHRoYXQgYW4gU1Igc291 cmNlIG5vZGUgd2FudHMgdG8gc2VuZCBhIHBhY2tldCBvbnRvIGFuIFNSIHBhdGggdGhyb3VnaCAx MCBTUiBzZWdtZW50IGVuZHBvaW50IG5vZGVzIChub2RlcyAxIHRocm91Z2ggMTApLCBhbmQgaGF2 ZSBhIFZQTiB0ZXJtaW5hdGlvbiBmb3IgYSBWUkYgMTIzIG9uIGEgbGFzdCBTUiBzZWdtZW50IGVu ZHBvaW50IG5vZGUgMTEuDQoNClRoZSBTUiBzb3VyY2Ugbm9kZSBzZWxlY3RzIHRoZSBzZWdtZW50 cyBhcyBmb2xsb3dzOg0KDQogICogICBPbiBub2RlcyAxIHRocm91Z2ggNSwgdGhlIFNJRCAyMDAx OmRiODowOjBLMDE6OiAod2l0aCBLIGJlaW5nIHRoZSBub2RlIElEKSBib3VuZCB0byBFbmQgd2l0 aCBORVhULUMtU0lEIGZsYXZvciBhbmQgMTYtYml0IEMtU0lEIGxlbmd0aC4NCiAgKiAgIE9uIG5v ZGVzIDYgdGhyb3VnaCA5LCB0aGUgU0lEIDIwMDE6ZGI4OjA6MEswMDowMDAxOjogKHdpdGggSyBi ZWluZyB0aGUgbm9kZSBJRCkgYm91bmQgdG8gRW5kIHdpdGggUkVQTEFDRS1DLVNJRCBmbGF2b3Ig YW5kIDMyLWJpdCBDLVNJRCBsZW5ndGguDQogICogICBPbiBub2RlIDEwLCB0aGUgU0lEIDIwMDE6 ZGI4OjA6MTAwMDowMDAxOjogYm91bmQgdG8gRW5kIChSRkMgODk4NikuDQogICogICBPbiBub2Rl IDExLCBhIFNJRCAyMDAxOmRiODowOjExMDA6ZDEyMzo6IGJvdW5kIHRvIEVuZC5EVDQgKFJGQyA4 OTg2KSBmb3IgVlJGIDEyMy4NCg0KVGhlIFNSIHNvdXJjZSBub2RlIHRoZW4gc2VuZHMgdGhlIHBh Y2tldCBvbnRvIHRoZSBTUiBwYXRoIGJ5IHBlcmZvcm1pbmcgdGhlIEguRW5jYXBzLlJlZCBiZWhh dmlvciB3aXRoOg0KDQogICogICBJUHY2IFNvdXJjZSBBZGRyZXNzID0gPGFuIGFkZHJlc3Mgb2Yg dGhlIFNSIHNvdXJjZSBub2RlPg0KICAqICAgSVB2NiBEZXN0aW5hdGlvbiBBZGRyZXNzID0gMjAw MTpkYjg6MDowMTAxOjAyMDE6MDMwMTowNDAxOjA1MDENCiAgKiAgIFNSSCA9DQoNCiAgICAgKiAg IFNlZ21lbnRMaXN0WzBdID0gMjAwMTpkYjg6MDoxMTAwOmQxMjM6Og0KICAgICAqICAgU2VnbWVu dExpc3RbMV0gPSAxMDAwOjAwMDE6MDkwMDowMDAxOjA4MDA6MDAwMTowNzAwOjAwMDENCiAgICAg KiAgIFNlZ21lbnRMaXN0WzJdID0gMjAwMTpkYjg6MDowNjAwOjAwMDE6Og0KDQpUaGVyZWZvcmUs IHRoZXJlIGlzIG5vIG5vdGlvbiBvZiBsb3dlc3QgY29tbW9uIGRlbm9taW5hdG9yIGZvciBDLVNJ RCBsZW5ndGguIEJhc2VkIG9uIHRoZSBkZXBsb3ltZW50IHJlcXVpcmVtZW50cywgYW4gb3BlcmF0 b3IgaGFzIHRoZSBmbGV4aWJpbGl0eSB0byBzZWxlY3QgdGhlIFNSdjYgU0lEIGZsYXZvciBhbmQg Qy1TSUQgbGVuZ3RocyBvZiB0aGVpciBjaG9pY2UuDQoNCldlIGNhbiB1cGRhdGUgdGhlIGRyYWZ0 IHdpdGggdGhpcyB0eXBlIG9mIGlsbHVzdHJhdGlvbnMuDQoNClRoYW5rcywNCkZyYW5jb2lzDQoN CkZyb206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZy1ib3Vu Y2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIEd5YW4gTWlzaHJhIDxoYXlhYnVzYWdzbUBnbWFp bC5jb208bWFpbHRvOmhheWFidXNhZ3NtQGdtYWlsLmNvbT4+DQpEYXRlOiBTdW5kYXksIDMgT2N0 b2JlciAyMDIxIGF0IDIxOjAxDQpUbzogWWlzb25nIExpdSA8bGl1eWlzb25nQGNoaW5hbW9iaWxl LmNvbTxtYWlsdG86bGl1eWlzb25nQGNoaW5hbW9iaWxlLmNvbT4+DQpDYzogSmFtZXMgR3VpY2hh cmQgPGphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbTxtYWlsdG86amFtZXMubi5ndWljaGFy ZEBmdXR1cmV3ZWkuY29tPj4sIFNQUklORyBXRyA8c3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJp bmdAaWV0Zi5vcmc+Piwgc3ByaW5nLWNoYWlycyA8c3ByaW5nLWNoYWlyc0BpZXRmLm9yZzxtYWls dG86c3ByaW5nLWNoYWlyc0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gUkXvvJog V0cgQWRvcHRpb24gY2FsbCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vDQoNCkhpIFlpc29u Zw0KDQpUaGUgbWFpbiBnb2FsIGZvciBvcGVyYXRvcnMgaXMgaW50ZXJvcGVyYWJpbGl0eS4gIEFz IGludGVyb3BlcmFiaWxpdHkgaXMgdGhlIGtleSByZWFzb24gZm9yIGEgc2luZ2xlIFNSdjYgY29t cHJlc3Npb24gc29sdXRpb24gdGhhdCB3ZSBoYXZlIFdHIGNvbnNlbnN1cyBhbmQgaXMgZGVzaXJl ZC4NCg0KQ29udGludWVkIGRldGFpbHMgb2YgdGhlIGludGVyb3BlcmFiaWxpdHkgc3R1ZHkgIHNo b3VsZCBiZSBhZGRlZCB0byB0aGUgZHJhZnQgYXMgdGhlIHN0dWR5IHByb2dyZXNzZXMuDQoNCk9u ZSBrZXkgZGV0YWlsIHRoYXQgaXMgbWlzc2luZyBpcyBmb3J3YXJkaW5nIGVmZmljaWVuY3kgYW5k IHNjYWxhYmlsaXR5IHVzaW5nIE5FWFQtQy1TSUQgYW5kIFJFUExBQ0UtQy1TSUQgaW50ZXJvcGVy YWJpbGl0eSB1c2luZyAxNiBiaXQgU0lELg0KDQpBcyBORVhULUNTSUQgdVNJRCBDb250YWluZXIg TWljcm8gU2VnbWVudCBzaGlmdCBmbGF2b3IgdXNpbmcgR0lCL0xJQiBmb3IgdWx0cmEgc2NhbGUg IFNSdjYgY29tcHJlc3Npb24gc29sdXRpb24gaXMgcmVjb21tZW5kZWQgZm9yIDE2IGJpdCBTSUQg YW5kIFJFUExBQ0UtQy1TSUQgRy1TSUQgRy1TSUQgQ29udGFpbmVyIGJhc2VkIHNvbHV0aW9uIGlz IHJlY29tbWVuZGVkIGZvciAzMiBiaXQgU0lELg0KDQpPZiBhbGwgdGhlIHJlcXVpcmVtZW50cyBh cyBzdGF0ZWQsIHRoZSBlbmNhcHN1bGF0aW9uIGhlYWRlciBzaXplIGlzIHRoZSBwcmltYXJ5IG9i amVjdGl2ZSBmb3Igb3BlcmF0b3JzIHRvIGVsaW1pbmF0ZSBNU0QgaXNzdWVzIHdpdGggb3B0aW1h bCBmb3J3YXJkaW5nIGFuZCBzdGF0ZSBlZmZpY2llbmNpZXMuDQoNCkF0IHRoaXMgdGltZSBpbiBv cmRlciBmb3IgTmV4dCBhbmQgUmVwbGFjZSBzb2x1dGlvbnMgdG8gYmUgaW50ZXJvcGVyYWJsZSBr ZWVwaW5nIGluIG1pbmQgcmVxdWlyZW1lbnRzIGZvciBvcHRpbWFsIGZvcndhcmRpbmcgYW5kIHN0 YXRlIGVmZmljaWVuY3kgMzIgYml0IFNJRCB3b3VsZCBiZSB0aGUgbG93ZXN0IGNvbW1vbiBkZW5v bWluYXRvciB3aGljaCBzaG91bGQgYmUgc3RhdGVkIGFzIHRoZSBiYXNlbGluZSByZXN1bHQgb2Yg dGhlIGFuYWx5c2lzIGRyYWZ0IG9uIENTSUQgb3ZlcmFsbCAyIHByb25nIHNvbHV0aW9uLg0KDQpD U0lEIGRyYWZ0Og0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1m aWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi0wMiNzZWN0aW9uLTExDQoN CkJvdHRvbSBvZiBzZWN0aW9uIDExOg0KDQoNCiAgIFRoZSBpbnRlcm9wZXJhYmlsaXR5IHdhcyB2 YWxpZGF0ZWQgZm9yIHRoZSBmb2xsb3dpbmcgc2NlbmFyaW86DQoNCg0KDQogICBvICBQYWNrZXQg Zm9yd2FyZGluZyB0aHJvdWdoIGEgdHJhZmZpYyBlbmdpbmVlcmluZyBzZWdtZW50IGxpc3QNCg0K ICAgICAgY29tYmluaW5nLCBpbiB0aGUgc2FtZSBTUkggKFtSRkM4NzU0PGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvcmZjODc1ND5dKSwgU1J2NiBTSURzIGJvdW5kIHRvIGFu DQoNCiAgICAgIGVuZHBvaW50IGJlaGF2aW9yIHdpdGggdGhlIE5FWFQtQy1TSUQgZmxhdm9yIGFu ZCBTUnY2IFNJRHMgYm91bmQNCg0KICAgICAgdG8gYW4gZW5kcG9pbnQgYmVoYXZpb3Igd2l0aCB0 aGUgUkVQTEFDRS1DLVNJRCBmbGF2b3IuDQoNCg0KDQogICBGdXJ0aGVyIGludGVyb3BlcmFiaWxp dHkgdGVzdGluZyBpcyBvbmdvaW5nIGFuZCB3aWxsIGJlIHJlcG9ydGVkIGluDQoNCiAgIHRoaXMg ZG9jdW1lbnQgYXMgdGhlIHdvcmsgcHJvZ3Jlc3Nlcy4NCg0KS2luZyBSZWdhcmRzDQoNCkd5YW4N Ck9uIFNhdCwgT2N0IDIsIDIwMjEgYXQgMTI6NTYgQU0gWWlzb25nIExpdSA8bGl1eWlzb25nQGNo aW5hbW9iaWxlLmNvbTxtYWlsdG86bGl1eWlzb25nQGNoaW5hbW9iaWxlLmNvbT4+IHdyb3RlOg0K SGkgQ2hhaXJzICYgV0csDQoNCkkgc3Ryb25nbHkgc3VwcG9ydCB0aGUgYWRvcHRpb24gY2FsbC4g UmVnYXJkaW5nIGNoYWlyJ3Mgbm90ZSBpbiB0aGUgZW1haWwsIEkgd291bGQgbGlrZSB0byBwb2lu dCB0aGF0IHRoZSBuZXR3b3JrIHByb2dyYW1taW5nIG1vZGVsIChSRkM4OTk2KSBieSBuYXR1cmUg ZGVmaW5lcyBtdWx0aXBsZSBiZWhhdmlvcnMuIENTSUQgaGFzIGEgc2luZ2xlIFNSdjYgYmFzZWQg ZGF0YSBwbGFuZSB0aGF0IGRlZmluZXMgdGhlIG5leHQgYW5kIHJlcGxhY2UgYmVoYXZpb3JzIGNv bnNpc3RlbnQgd2l0aCB0aGUgbmV0d29yayBwcm9ncmFtbWluZyBwYXJhZGlnbS4NCg0KQ1NJRCdz IG5leHQgYW5kIHJlcGxhY2UgYmVoYXZpb3JzIGhhdmUgYmVlbiB2ZXJpZmllZCBieSBpbnRlcm9w ZXJhYmlsaXR5IHRlc3QgaW4gQ2hpbmEgbW9iaWxlIGxhYm9yYXRvcnkgYW5kIHRoZXJlIGlzIG5v IHByb2JsZW0gd2l0aCB0aGUgaW50ZXJ3b3JraW5nIG9mIHRoZSB0d28gYmVoYXZpb3JzIG9uIHRo ZSBDU0lEIGRhdGFwbGFuZS4NCg0KQmVzdCBSZWdhcmRzDQpZaXNvbmcNCg0K5Y+R5Lu25Lq6OiBK YW1lcyBHdWljaGFyZDxtYWlsdG86amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tPg0K5pe2 6Ze0OiAyMDIxLzEwLzAxKOaYn+acn+S6lCkyMjowNA0K5pS25Lu25Lq6OiBTUFJJTkcgV0c8bWFp bHRvOnNwcmluZ0BpZXRmLm9yZz47DQrmioTpgIHkuro6IHNwcmluZy1jaGFpcnM8bWFpbHRvOnNw cmluZy1jaGFpcnNAaWV0Zi5vcmc+Ow0K5Li76aKYOiBbc3ByaW5nXSBXRyBBZG9wdGlvbiBjYWxs IGZvciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5n LXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8NCkRlYXIgV0c6DQoNClRoZSBjaGFpcnMgd291 bGQgbGlrZSB0byBleHByZXNzIHRoZWlyIGFwcHJlY2lhdGlvbiBmb3IgYWxsIHRoZSByZXNwb25z ZXMgcmVjZWl2ZWQgdG8gb3VyIGVtYWlscyB3aXRoIHJlZmVyZW5jZSB0byBob3cgdGhlIHdvcmtp bmcgZ3JvdXAgd2lzaGVzIHRvIG1vdmUgZm9yd2FyZCB3aXRoIHJlc3BlY3QgdG8gYSBzb2x1dGlv biBmb3IgU1J2NiBjb21wcmVzc2lvbi4NCg0KVGhlIGFwcGFyZW50IGluY2xpbmF0aW9uIG9mIHRo ZSB3b3JraW5nIGdyb3VwIGlzIHRvIHVzZSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8gYXMgdGhl IGJhc2lzIGZvciBpdHMgY29tcHJlc3Npb24gc3RhbmRhcmRpemF0aW9uIHdvcmsuIFRoYXQgaXMg cGFydCBvZiB3aGF0IHRoaXMgZW1haWwgYXR0ZW1wdHMgdG8gY29uZmlybS4NCg0KQmVjYXVzZSBv ZiB0aGUgYWJvdmUgdGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGlzc3VlIGEgMi13ZWVrIFdHIGNh bGwgZm9yIGFkb3B0aW9uIGVuZGluZyBPY3RvYmVyIDE1dGggZm9yIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXBy ZXNzaW9uLyBidXQgd2l0aCBzb21lIGNsZWFyIGd1aWRlbGluZXMgYXMgZm9sbG93cy4gQnkgZXhw cmVzc2luZyBzdXBwb3J0IGZvciBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IHlvdSBhcmUgZnVs bHkgYXdhcmUgb2YgYW5kIGFyZSBhY2tub3dsZWRnaW5nIHRoYXQ6DQoNCg0KICAxLiAgVGhlIFNQ UklORyB3b3JraW5nIGdyb3VwIGlzIGFkb3B0aW5nIGEgZG9jdW1lbnQgdGhhdCBoYXMgbXVsdGlw bGUgU1J2NiBFbmRwb2ludCBiZWhhdmlvcnMuDQogIDIuICBUaGUgZG9jdW1lbnQgaXMgYSDigJxs aXZpbmfigJ0gZG9jdW1lbnQ7IGl0IG1heSBjaGFuZ2UgYXMgaXQgZ29lcyB0aHJvdWdoIHJldmll dyBhbmQgYW5hbHlzaXMgYnkgdGhlIFNQUklORyB3b3JraW5nIGdyb3VwLg0KICAzLiAgQWxsIG9w ZW4gZGlzY3Vzc2lvbiBwb2ludHMgcmFpc2VkIG9uIG91ciBtYWlsaW5nIGxpc3QgTVVTVCBiZSBh ZGRyZXNzZWQgQkVGT1JFIHNhaWQgZG9jdW1lbnQgaXMgYWxsb3dlZCB0byBwcm9ncmVzcyBmcm9t IHRoZSB3b3JraW5nIGdyb3VwIHRvIHB1YmxpY2F0aW9uLiBBIGxpc3Qgb2YgdGhlc2UgZGlzY3Vz c2lvbiBwb2ludHMgd2lsbCBiZSBkb2N1bWVudGVkIGluIHRoZSBXRyBkb2N1bWVudCBhbmQgbWFp bnRhaW5lZCBieSB0aGUgZG9jdW1lbnQgZWRpdG9yIGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIGNo YWlycy4NCiAgNC4gIElmIHRoaXMgZG9jdW1lbnQgaXMgYWRvcHRlZCBieSB0aGUgd29ya2luZyBn cm91cCwgdGhlIGNoYWlycyBzcGVjaWZ5IGFzIHBhcnQgb2YgdGhlIGFkb3B0aW9uIGNhbGwgdGhh dCB0aGUgZm9sbG93aW5nIHRleHQgZGVzY3JpYmluZyBhbiBvcGVuIGlzc3VlIGJlIGFkZGVkIHRv IHRoZSBkb2N1bWVudCBpbiB0aGUgYWJvdmUtZGVzY3JpYmVkIG9wZW4gaXNzdWVzIHNlY3Rpb246 DQoNCiAgICAgKiAgICJHaXZlbiB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBzYWlkIHRoYXQg aXQgd2FudHMgdG8gc3RhbmRhcmRpemUgb25lIGRhdGEgcGxhbmUgc29sdXRpb24sIGFuZCBnaXZl biB0aGF0IHRoZSBkb2N1bWVudCBjb250YWlucyBtdWx0aXBsZSBTUnY2IEVuZFBvaW50IGJlaGF2 aW9ycyB0aGF0IHNvbWUgV0cgbWVtYmVycyBoYXZlIHN0YXRlZCBhcmUgbXVsdGlwbGUgZGF0YSBw bGFuZSBzb2x1dGlvbnMsIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYWRkcmVzcyB3aGV0aGVyIHRo aXMgaXMgdmFsaWQgYW5kIGNvaGVyZW50IHdpdGggaXRzIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9u IG9iamVjdGl2ZS4iLg0KDQpQbGVhc2UgY29uc2lkZXIgdGhlIGFib3ZlIGd1aWRlbGluZXMgYXMg eW91IGRlY2lkZSBvbiB3aGV0aGVyIHRvIHN1cHBvcnQgb3Igbm90IHRoaXMgV0cgYWRvcHRpb24u IFBsZWFzZSBleHByZXNzIGNsZWFybHkgeW91ciByZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9uLXN1 cHBvcnQgYXMgd2VsbCBhcyBhbnkgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyB5b3Ugd291bGQgbGlr ZSBhZGRyZXNzZWQgc2hvdWxkIHRoZSBkb2N1bWVudCBiZSBhZG9wdGVkIGludG8gdGhlIHdvcmtp bmcgZ3JvdXAuDQoNClRoYW5rcyENCg0KSmltLCBCcnVubyAmIEpvZWwNCg0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlz dA0Kc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KLS0NCg0KW+WbvuWDj+W3suiiq+WPkeS7 tuS6uuWIoOmZpOOAgl08aHR0cDovL3d3dy52ZXJpem9uLmNvbS8+DQoNCkd5YW4gTWlzaHJhDQoN Ck5ldHdvcmsgU29sdXRpb25zIEFyY2hpdGVjdA0KDQpFbWFpbCBneWFuLnMubWlzaHJhQHZlcml6 b24uY29tPG1haWx0bzpneWFuLnMubWlzaHJhQHZlcml6b24uY29tPg0KDQpNIDMwMSA1MDItMTM0 Nw0KDQotLQ0KDQpb5Zu+5YOP5bey6KKr5Y+R5Lu25Lq65Yig6Zmk44CCXTxodHRwOi8vd3d3LnZl cml6b24uY29tLz4NCg0KR3lhbiBNaXNocmENCg0KTmV0d29yayBTb2x1dGlvbnMgQXJjaGl0ZWN0 DQoNCkVtYWlsIGd5YW4ucy5taXNocmFAdmVyaXpvbi5jb208bWFpbHRvOmd5YW4ucy5taXNocmFA dmVyaXpvbi5jb20+DQoNCk0gMzAxIDUwMi0xMzQ3DQoNCg== --_000_1c919ecf8db842dc8ecda349a74b741chuaweicom_ 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 CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7DQoJcGFub3NlLTE6MiAxMSA2 IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRo IjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIg NCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJ cGFub3NlLTE6MiAxMSA1IDMgMiAyIDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpHZW9yZ2lhOw0KCXBhbm9zZS0xOjIgNCA1IDIgNSA0IDUgMiAzIDM7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIg MTEgNiA5IDcgMiA1IDggMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk65a6L5L2TO30NCnNwYW4uSFRNTENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg 6aKE6K6+5qC85byPIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiSFRNTCDpooTorr7moLzlvI8iOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K c3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBs aXN0IGwwDQoJe21zby1saXN0LWlkOjEwMzg3NDcwMTA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi02ODQ4MDk5NTI7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx DQoJe21zby1saXN0LWlkOjE1OTM5MzAwMzc7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMTQ3 ODg5MzI4O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwx OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlk OjE4MTQwNTYwNDY7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMzQ4NTQ0MDY4O30NCkBsaXN0 IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6NDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDMNCgl7bXNvLWxpc3QtaWQ6MjAxNzIyNjkxNDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTcz Mzc0OTA3Njt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBHeWFuLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5Tb3JyeSBmb3IgdGhlIGxhdGUgcmVwbHkuIFRoYW5rIHlvdSBmb3IgcmVhZGlu ZyB0aGUgZHJhZnQgc28gY2FyZWZ1bGx5LCByZWFsbHkgYXBwcmVjaWF0ZWQuIEJ1dCBJIHdpbGwg cmVjb21tZW5kIHlvdSB0byBzcGxpdCB0aGUgY29tbWVudHMgaW50byBzbWFsbA0KIGVtYWlscyBz byB0aGF0IHdlIGNhbiBkaXNjdXNzIGVhc2lseS4gTE9MLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPlJlZ2FyZGluZyB0aGUgaWxsdXN0cmF0aW9ucywgeWVzLCBpdCBjYW4gYmUgYWRk ZWQgbGF0ZXIgb24uIEFuZCBhbHNvIEZyYW5jb2lzIHByb3ZpZGVzIHRoZSBleGFtcGxlIGFscmVh ZHksIHBsZWFzZSByZWZlciB0byBpdC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5MaWtlIHlvdSBxdW90ZSBmcm9t IHRoZSBkcmFmdCwgUkVQTEFDRS1DU0lEIGFuZCBORVhULUNTSUQgY2FuIHN1cHBvcnRlZCBib3Ro IHRoZSAxNi1iaXQgYW5kIDMyLWJpdCBzb2x1dGlvbiwgYnV0IGZyb20gdGhlIGNvbnNpZGVyYXRp b25zIG9mIHRyYWRlLW9mZg0KIG9mIGJldHRlciBjb21wcmVzc2lvbiBhbmQgZWFzeSBvcGVyYXRp b24sIE5FWFQtQ1NJRCByZWNvbW1lbmRzIDE2LWJpdCBhbmQgUkVQTEFDRS1DU0lEIHJlY29tbWVu ZHMgMzItYml0LiBGcm9tIHRoZSB0ZXh0LCB5b3UgYWxzbyBjYW4gc2VlIHVzaW5nIHRoZSBjb21t b24gZGVzaWduIG9mIEdJQi9MSUIsIGJvdGggZmxhdm9ycyBjYW4gc3VwcG9ydCAxNi1iaXQgc29s dXRpb24uICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkZyb20gdGhlIHNlY3Rpb24gNCBpbiB0aGUgZHJhZnQgaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNy aC1jb21wcmVzc2lvbiNzZWN0aW9uLTQsIGl0IGFsc28gc3RhdGVzIHRoYXQ8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InRleHQtaW5k ZW50OjE1Ljc1cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ IDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6 YmxhY2siPkl0IGlzIHJlY29tbWVuZGVkIGZvciBlYXNlIG9mIG9wZXJhdGlvbiB0aGF0IGEgc2lu Z2xlIGNvbXByZXNzZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFj ayI+Jm5ic3A7Jm5ic3A7IGVuY29kaW5nIGZsYXZvciBiZSB1c2VkIGluIGEgZ2l2ZW4gU1J2NiBk b21haW4uJm5ic3A7IEhvd2V2ZXIsIGluIGEgbXVsdGktPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsgZG9tYWluIGRlcGxveW1lbnQsIGRpZmZl cmVudCBmbGF2b3JzIGNhbiBiZSB1c2VkIGluIGRpZmZlcmVudDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7IGRvbWFpbnMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PnNvIHdlIHNob3VsZCBhdm9pZCB0byBtaXggZGlmZmVyZW50IGxlbmd0aCBvZiBDU0lEcyBpbiBh IHNpbmdsZSBjb250YWluZXIsIHRob3VnaCB3ZSBjYW4gZG8gaXQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlRoYW5r cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNoZW5nPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRDb21wb3NlIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvYT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1z ZXJpZiI+5Y+R5Lu25Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 5b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPiBHeWFuIE1pc2hyYSBbbWFpbHRvOmhheWFi dXNhZ3NtQGdtYWlsLmNvbV0NCjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+ 5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u 6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYiPiAyMDIxPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNl cmlmIj7lubQ8c3BhbiBsYW5nPSJFTi1VUyI+MTA8L3NwYW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMi PjExPC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4NCiA0OjIzPGJyPg0KPC9zcGFuPjxiPuaU tuS7tuS6ujxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+ IENoZW5nbGkgKENoZW5nIExpKSAmbHQ7Yy5sQGh1YXdlaS5jb20mZ3Q7OyBGcmFuY29pcyBDbGFk IChmY2xhZCkgJmx0O2ZjbGFkQGNpc2NvLmNvbSZndDs8YnI+DQo8L3NwYW4+PGI+5oqE6YCBPHNw YW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gSmFtZXMgR3Vp Y2hhcmQgJmx0O2phbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbSZndDs7IFNQUklORyBXRyAm bHQ7c3ByaW5nQGlldGYub3JnJmd0OzsgWWlzb25nIExpdSAmbHQ7bGl1eWlzb25nQGNoaW5hbW9i aWxlLmNvbSZndDs7IHNwcmluZy1jaGFpcnMgJmx0O3NwcmluZy1jaGFpcnNAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPC9zcGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyI+IFJlOiBbc3ByaW5nXSBSRTwvc3Bhbj7vvJo8c3BhbiBsYW5nPSJFTi1V UyI+IFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLzxvOnA+PC9v OnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lIGJsYWNrIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gMGNtO2JhY2tncm91bmQt Y29sb3I6cmdiYSgwLDAsMCwwKSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjpibGFjayI+SGkgRnJhbmNvaXMsIENoZW5nbGkgJmFtcDsgYXV0aG9y cyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPk1hbnkgVGhhbmtzIGZvciB5 b3VyIGZlZWRiYWNrIHRvIHRoZSBXRyBvbiB0aGUgY3JpdGljYWwgdG9waWMgaW50ZXJvcGVyYWJp bGl0eSBvZiB0aGUgdVNJRCBtaWNyby1zaWQgMTYgYml0IHVTSUQgJm5ic3A7IOKAnE5GPUxvY2F0 b3IvRnVuY3Rpb24gY29tYm/igJ0gJm5ic3A7MTI4IGJpdCZuYnNwO2NvbnRhaW5lciBiYXNlZCBz b2x1dGlvbiBhbmQgdGhlIEctU1JWNiAzMiBiaXQNCiBHLVNJRCDigJxORj1Mb2NhdG9yL0Z1bmN0 aW9uIGNvbWJv4oCdIDQgLSAzMiBiaXQgRy1TSUQgaW4gMTI4IGJpdCBjb250YWluZXIgYmFzZWQg c29sdXRpb24gZGVmaW5lZCBhcyBOZXh0IGFuZCBSZXBsYWNlIGZsYXZvcnMgaW4gdGhlIGRyYWZ0 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkkgYW0gcmVhbGx5IGNvbmNlcm5lZCBh cyB0byBob3cgdGhlIG5leHQgYW5kIHJlcGxhY2UgaW50ZXJvcGVyYWJpbGl0eSB3b3VsZCB3b3Jr IGZvciBhZGphY2VudCBub2RlcyB1c2luZyBTSUQgd2l0aGluIHNhbWUgb3IgYWRqYWNlbnQgY29u dGFpbmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPlNlY3Rpb24gNi4xIG1lbnRp b25zIHRoYXQgJm5ic3A7TmV4dCBmbGF2b3IgcmVjb21tZW5kYXRpb24gaXMgZm9yIDE2IGJpdCBh cyB0aGUgdVNJRCBkcmFmdCAmYW1wOyB0aGlzIGRyYWZ0IE5GIGFzIDE2IGJpdCBpcyBtb3N0IG9w dGltYWwgdVNJRCBzaXplIHdpdGhpbiB0aGUgdVNJRCBjb250YWluZXIgYW5kJm5ic3A7PHNwYW4g c3R5bGU9ImJvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowY20iPlJlcGxhY2UN CiBmbGF2b3IgcmVjb21tZW5kYXRpb24gaXMgZm9yIDE2IGJpdCBhcyB0aGUgRy1TUlY2IGRyYWZ0 ICZhbXA7IHRoaXMgZHJhZnQgTkYgYXMgMzIgYml0IEctU0lEIGlzIG1vc3Qgb3B0aW1hbCBHLVNJ RCBzaXplIHdpdGhpbiB0aGUgRy1TSUQgY29udGFpbmVyLiZuYnNwOyZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrO2JvcmRlcjpub25lIHdpbmRvd3RleHQgMS4wcHQ7 cGFkZGluZzowY20iPlBsZWFzZSAmbmJzcDtlbGFib3JhdGUgb24gdGhpcyBpbiBtb3JlIGRldGFp bCwgYXMgd2l0aCB0aGlzIGRyYWZ0IGZvciBuZXh0IGFuZCByZXBsYWNlIGludGVyb3BlcmFiaWxp dHksIGZvbGxvd2luZyB0aGUgU1J2NiBjb21wcmVzc2lvbiByZXF1aXJlbWVudHMgZm9yIG9wdGlt YWwNCiBoYXJkd2FyZSBmb3J3YXJkaW5nIGFuZCBzdGF0ZSBlZmZpY2llbmN5IHRoYXQgTmV4dCB3 b3VsZCBiZSByZWNvbW1lbmRlZCB0byB1c2UgMTYgYml0IFNJRCBhbmQgUmVwbGFjZSB3b3VsZCBi ZSByZWNvbW1lbmRlZCAzMiBiaXQgU0lELiAmbmJzcDsgUGxlYXNlIGVsYWJvcmF0ZSBpbiBkZXRh aWwgYXMgdG8gd2h5IDE2IGJpdCBpcyBub3QgcmVjb21tZW5kZWQgZm9yIHJlcGxhY2UgZmxhdm9y IGFuZCAzMiBiaXQgaXMgbm90IHJlY29tbWVuZGVkIGZvciBuZXh0DQogZmxhdm9yIGZvciBhbGwg b2YgdGhlIHJlcXVpcmVtZW50cyBkcmFmdHMgbGlzdCBvZiBTUnY2IGNvbXByZXNzaW9uIHJlcXVp cmVtZW50cyBlYWNoIG9uZSBieSBvbmUgYW5kIHRoZSBwcm9ibGVtcyBlbmNvdW50ZXJlZCB3aGVu IG5vdCB1c2luZyB0aGUgcmVjb21tZW5kZWQgU0lEIGxlbmd0aC48L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj aztib3JkZXI6bm9uZSB3aW5kb3d0ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIj5UaHVzIGZvciBuZXh0 IGFuZCByZXBsYWNlIGZsYXZvciBpbnRlcm9wZXJhYmlsaXR5IGV2ZW4gcG9zc2libGUgJm5ic3A7 dG8gd29yayB3b3VsZCByZXF1aXJlIHR3byBkaWZmZXJlbnQgU0lEIHNpemVzIHdpdGhpbiB0aGUg c2FtZSBjb250YWluZXIgaW50ZXJvcGVyYWJpbGl0eSBjYXZlYXRzDQogYW5kIG5vdyB5b3UgaGF2 ZSB0byBkZWFsIHdpdGggdVNJRCBjb250YWluZXIgc3R5bGUgdXNpbmcgMTYgYml0IFNJRCBhbmQg Ry1TSUQgY29udGFpbmVyIHN0eWxlIHVzaW5nIDMyIGJpdCBTSUQuPC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmUgYmxhY2sgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSAwY207YmFj a2dyb3VuZC1jb2xvcjpyZ2JhKDAsMCwwLDApIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2s7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAx LjBwdDtwYWRkaW5nOjBjbSI+RnJvbSB0aGUgcmVxdWlyZW1lbnRzIGRyYWZ0LCAmbmJzcDtpbnRl cm9wZXJhYmlsaXR5IHBlcnNwZWN0aXZlLCB0aGUgcHJpbWFyeSBvYmplY3RpdmUgaXMg4oCcZW5j YXBzdWxhdGlvbiBoZWFkZXIgY29tcHJlc3Npb27igJ0gYXMgdGhhdCBpcyB3aGF0IHdlIGhhdmUg c3BlbnQgb3ZlciBhDQogeWVhciBvbiB3aXRoIERUIGZpbmRpbmcgYW4gb3B0aW1hbCBjb21wcmVz c2lvbiBzb2x1dGlvbi4mbmJzcDsgU28gaGVyZSB0aGUgbG93ZXN0IGNvbW1vbiBkZW5vbWluYXRv ciBlbmRzIHVwIGJlaW5nIDMyIGJpdCBTSUQgYW5kIHdlIG5vdyBoYXZlIGZhaWxlZCB0aGUgcHJp bWFyeSBvYmplY3RpdmUgb2YgYSBjb21wcmVzc2lvbiBzb2x1dGlvbi4gJm5ic3A7Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmUgYmxhY2sgMS4wcHQ7cGFk ZGluZzowY20gMGNtIDBjbSAwY207YmFja2dyb3VuZC1jb2xvcjpyZ2JhKDAsMCwwLDApIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmUgYmxhY2sgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSAwY207YmFja2dyb3VuZC1jb2xv cjpyZ2JhKDAsMCwwLDApIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6YmxhY2s7Ym9yZGVyOm5vbmUgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5n OjBjbSI+QXMgZmFyIGFzIGxvd2VzdCBjb21tb24gZGVub21pbmF0b3IgaXMgaXQgdHJ1ZSB0aGF0 IGluIG9yZGVyIHRvIG1lZXQgYWxsIHRoZSByZXF1aXJlbWVudHMgZHJhZnQgbGlzdCBvZiBhbGwg U1J2NiBjb21wcmVzc2lvbiByZXF1aXJlbWVudHMgYm90aCBuZXh0IGFuZCByZXBsYWNlDQogaGF2 ZSB0byByZXZlcnQgdG8gdGhhdCBsb3dlc3QgY29tbW9uIGRlbm9taW5hdG9yIHdoaWNoIGlzIDMy IGJpdCBTSUQuJm5ic3A7IElmIHRoYXQgaXMgdHJ1ZSwgdW5mb3J0dW5hdGVseSB0aGF0IG1ha2Vz IHRoZSBkcmFmdCBmYWlsIHRoZSBwcmltYXJ5IG9iamVjdGl2ZSBvZiBhbnkgU1J2NiBjb21wcmVz c2lvbiBzb2x1dGlvbi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZSBibGFjayAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDBjbTtiYWNrZ3JvdW5kLWNvbG9yOnJn YmEoMCwwLDAsMCkiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZSBibGFjayAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDBj bTtiYWNrZ3JvdW5kLWNvbG9yOnJnYmEoMCwwLDAsMCkiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjaztib3JkZXI6bm9uZSB3aW5kb3d0 ZXh0IDEuMHB0O3BhZGRpbmc6MGNtIj5UbyB0aGF0IGVuZCBhcyBmYXIgYXMgaW50ZXJvcGVyYWJp bGl0eSBvbiBOZXh0IGFuZCBSZXBsYWNlIGludGVyb3BlcmFiaWxpdHkgYmVpbmcgdGhlIGhpbmdl IHBpbiBvZiB0aGlzIGRyYWZ0cyBhZG9wdGlvbiwgYXMgd2VsbCBldmVuIGlmIHRoZSBhdXRob3Jz IHN0YXRlIHRoYXQNCiBSZXBsYWNlIGNhbiB1c2UgMTYgYml0IFNJRCBhcyBhIHBvc3NpYmlsaXR5 LCBhcyB0aGUgMzIgYml0IOKAnE5G4oCdIEctU0lEIGlzIHJlY29tbWVuZGVkIGZvciBoYXJkd2Fy ZSBmb3J3YXJkaW5nIGVmZmljaWVuY3kgYW5kIHNjYWxhYmlsaXR5IHRoYXQgaWYgMTYgYml0IHdl cmUgdXNlZCBHLVNJRCB3b3VsZCBmYWlsIHRoZSBoYXJkd2FyZSBmb3J3YXJkaW5nIGVmZmljaWVu Y3kgYW5kIHNjYWxhYmlsaXR5IHJlcXVpcmVtZW50cyBhcyB3ZWxsIGFzIHBvc3NpYmx5DQogb3Ro ZXIgcmVxdWlyZW1lbnRzIHdoaWNoIHNob3VsZCBhbHNvIGJlIHN0YXRlZCBpbiB0aGUgZHJhZnQu PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9ImJyZWFrLWJlZm9yZTpwYWdlIj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij48YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0 LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLTAyI3NlY3Rpb24tNi4x IiB0YXJnZXQ9Il9ibGFuayIgaWQ9Im1fLTQ0NzQ2MjQyMTY3OTQ1NzcxNXNlY3Rpb24tNi4xIj42 LjE8L2E+LiZuYnNwOyBDLVNJRCBMZW5ndGg8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFRoZSBORVhULUMtU0lEIGZsYXZvciBzdXBwb3J0cyBib3Ro IDE2LSBhbmQgMzItYml0IEMtU0lEIGxlbmd0aHMuJm5ic3A7IEE8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEMtU0lEIGxlbmd0aCBvZiAxNi1iaXQgaXMg cmVjb21tZW5kZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsgVGhlIFJFUExB Q0UtQy1TSUQgZmxhdm9yIHN1cHBvcnRzIGJvdGggMTYtIGFuZCAzMi1iaXQgQy1TSUQgbGVuZ3Ro cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEEgQy1T SUQgbGVuZ3RoIG9mIDMyLWJpdCBpcyByZWNvbW1lbmRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGRyYWZ0IHNob3VsZCBtZW50aW9uIHRo ZSByZWNvbW1lbmRhdGlvbiBmb3IgY29tbW9uIGJsb2NrIGxlbmd0aCBmb3IgaW50ZXJvcGVyYWJp bGl0eS4mbmJzcDsgVGhlIG9ubHkgYmxvY2sgc2l6ZSBwb3NzaWJsZSBpcyA0OCBiaXQgc28gYmxv Y2sgc2l6ZSBzbyB0aGF0IHdvdWxkIGJlIGEgbWFqb3IgYWRkcmVzc2luZyBpbmZsZXhpYmlsaXR5 IGZvciBpbnRlcm9wZXJhYmlsaXR5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJicmVhay1iZWZvcmU6 cGFnZSI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90OyI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv aHRtbC9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi0wMiNz ZWN0aW9uLTYuMiIgdGFyZ2V0PSJfYmxhbmsiIGlkPSJtXy00NDc0NjI0MjE2Nzk0NTc3MTVzZWN0 aW9uLTYuMiI+Ni4yPC9hPi4mbmJzcDsgQmxvY2sgTGVuZ3RoPC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBUaGUgcmVjb21tZW5kZWQgU1J2NiBTSUQg YmxvY2sgc2l6ZXMgZm9yIHRoZSBORVhULUMtU0lEIGZsYXZvciBhcmU8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IDE2LCAzMiBvciA0OCBiaXRzLiZuYnNw OyBUaGUgc21hbGxlciB0aGUgYmxvY2ssIHRoZSBoaWdoZXIgdGhlIGNvbXByZXNzaW9uPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBlZmZpY2llbmN5Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IFRoZSByZWNvbW1lbmRlZCBTUnY2IFNJ RCBibG9jayBzaXplIGZvciB0aGUgUkVQTEFDRS1DLVNJRCBmbGF2b3IgY2FuPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBiZSA0OCwgNTYsIDY0LCA3MiBv ciA4MCBiaXRzLCBkZXBlbmRpbmcgb24gdGhlIG5lZWRzIG9mIHRoZSBvcGVyYXRvci48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PlRha2luZyB0aGlzIGZ1cnRoZXIgYW5vdGhlciBzdGVwIGFzIHRoaXMgZHJhZnQgbmVlZHMgdG8g ZGVzY3JpYmUgaW4gZGV0YWlsIHdpdGggZXhhbXBsZXMgb2YgdGhlIGZlYXNpYmlsaXR5IG9mIGhv dyB0d28gYWRqYWNlbnQgbm9kZXMgb25lIHVzaW5nIG5leHQgMTYgYml0IFNJRCBhbmQgb3RoZXIg dXNpbmcgcmVwbGFjZSAzMiBiaXQgU0lEIGFzIHJlY29tbWVuZGVkIHdoZXJlIHRoZQ0KIDE2IGJp dCB1U0lEIG5leHQgZmxhdm9yIGFuZCAzMiBiaXQgRy1TSUQgYXJlIGluIHRoZSBzYW1lIFNSSCAx MjggYml0IGNvbnRhaW5lci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPkFzIHRoZSB1U0lEIE5leHQgZmxhdm9yIGRyYWZ0IHBlcmZvcm1zIGEgc2hpZnQg dG93YXJkcyBCIHRvd2FyZHMgbmliYmxlIEEsIEIgbmliYmxlcywgYW5kIFJlcGxhY2UgZG9lcyBh IHJlcGxhY2Ugb2YgdGhlIEEtQXJnIHBvcnRpb24gJm5ic3A7b2YgdGhlIDEyOCBiaXQgSVB2NiBh ZGRyZXNzLCBob3cgd291bGQgdGhhdCB3b3JrIHdpdGggYWRqYWNlbnQgbm9kZXMgdXNpbmcgZGlm ZmVyZW50DQogU0lEIGZsYXZvcnMgb2YgZGlmZmVyZW50IFNJRCBsZW5ndGhzLiAmbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5UaGUgTmV4dCBmbGF2b3IgdVNJRCBTUnY2IFBHTSAmbmJzcDtjb21w cmVzc2lvbiBzb2x1dGlvbiBwcm9jZXNzIGlzIHZlcnkgZGlmZmVyZW50IHdoZXJlIHdoZW4gaW5k ZXhpbmcgdGhlIG1pY3JvIHNpZCBuaWJibGVzIHdpdGhpbiB0aGUgMTI4IGJpdCBjb250YWluZXIs IGl0IHBlcmZvcm1zIGEgc2hpZnQgdG93YXJkcyB0aGUgdG9wIGxvd2VyIG9yZGVyIGJpdHMgb2Yg dGhlIElQdjYgYWRkcmVzcywNCiB3aGVyZSB0aGUgUmVwbGFjZSBmbGF2b3IgRy1TUnY2IFBHTSBj b21wcmVzc2lvbiBzb2x1dGlvbiBpbmRleGluZyB0aGUgNCBHLVNJRHMgd2l0aGluIHRoZSBjb250 YWluZXIgZG9lcyBhIFJlcGxhY2UgYXQgdGhlIEEtQXJnIGJvdHRvbSBoaWdoZXIgb3JkZXIgYml0 cy4gJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5UaGUgcmVmZXJlbmNpbmcgb2YgdGhlIDE2IHVTSUQgb3IgMzIgJm5ic3A7Yml0IEctU0lEICZu YnNwO25pYmJsZXMsIGluZGV4aW5nIGFuZCByZWZlcmVuY2Ugb2Ygd2hpY2ggbmliYmxlIHRvIHJl ZmVyZW5jZWQgZm9yIG5leHQgYW5kIHJlcGxhY2UgZm9yIGRpcmVjdGx5IGFkamFjZW50IG5vZGVz IHdpdGggbmliYmxlcyB3aXRoaW4gdGhlIHNhbWUgMTI4IGJpdCBjb250YWluZXIgb3IgYWRqYWNl bnQNCiBjb250YWluZXJzIGlzIHRoZSBpbnRlcm9wZXJhYmlsaXR5IGlzc3VlIHRoYXQgc2VlbXMg dG8gZXhpc3QuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+VGhpcyBuZWVkcyB0byBiZSBjbGFyaWZpZWQgb24gdGhlIG5leHQgc25kIHJlcGxh Y2UgaW50ZXJvcGVyYWJpbGl0eSBvcGVyYXRpb24gaW4gZGV0YWlsLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QWxzbyBSZXBsYWNlIGZsYXZvciB1c2Vz IENPQyBkZWxpbWl0ZXIgZm9yIHNpZ25hbGluZyBjb21wcmVzc2lvbiBmdW5jdGlvbiBpcyBhY3Rp dmUgd2hlcmUgTmV4dCBkb2VzIG5vdCBoYXZlIGFueSBzaWduYWxpbmcgb2YgY29tcHJlc3Npb24g YmVpbmcgYWN0aXZlIG9yIG5vdCBvciBtYXkgaGF2ZSBhIGRpZmZlcmVudCB3YXkgb2Ygc2lnbmFs aW5nIHRoYXQgdXBjb21pbmcgbm9kZQ0KIGRvZXMgbm90IHN1cHBvcnQgY29tcHJlc3Npb24uJm5i c3A7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij5Ib3cgZG9lcyB0aGUgY29tcHJlc3Npb24gc2lnbmFsaW5nIGludGVyb3BlcmFiaWxpdHkgd29y ayBiZXR3ZWVuIE5leHQgYW5kIFJlcGxhY2UgZmxhdm9ycy4mbmJzcDsgVGhhdCBzaG91bGQgYmUg YWRkcmVzc2VkIGFzIHdlbGwgaW4gdGhlIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+S2luZCBSZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5HeWFuPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlZl cml6b24gSW5jJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBGcmksIE9jdCA4LCAyMDIxIGF0IDE6MzQg UE0gRnJhbmNvaXMgQ2xhZCAoZmNsYWQpICZsdDs8YSBocmVmPSJtYWlsdG86ZmNsYWRAY2lzY28u Y29tIiB0YXJnZXQ9Il9ibGFuayI+ZmNsYWRAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBHeWFuLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPkl0IGlzIHBvc3NpYmxlIHRvIGNvbWJpbmUgU0lEcyBvZiBkaWZmZXJlbnQg Qy1TSUQgZmxhdm9ycyBhbmQgQy1TSUQgbGVuZ3RocyBpbiB0aGUgc2FtZSBTUkgsIGFsb25nIHdp dGggdGhvc2UgZGVmaW5lZCBpbiBSRkMgODk4NiBBZnRlciBhbGwsIHRoZXkgbGV2ZXJhZ2UgdGhl DQogc2FtZSBTUnY2IGRhdGEgcGxhbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+TGV0IG1lIGdp dmUgeW91IGFuIGV4YW1wbGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+QXNzdW1lIHRoYXQgYW4g U1Igc291cmNlIG5vZGUgd2FudHMgdG8gc2VuZCBhIHBhY2tldCBvbnRvIGFuIFNSIHBhdGggdGhy b3VnaCAxMCBTUiBzZWdtZW50IGVuZHBvaW50IG5vZGVzIChub2RlcyAxIHRocm91Z2ggMTApLCBh bmQgaGF2ZSBhIFZQTiB0ZXJtaW5hdGlvbiBmb3INCiBhIFZSRiAxMjMgb24gYSBsYXN0IFNSIHNl Z21lbnQgZW5kcG9pbnQgbm9kZSAxMS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgU1Igc291 cmNlIG5vZGUgc2VsZWN0cyB0aGUgc2VnbWVudHMgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBub2RlcyAxIHRocm91Z2gg NSwgdGhlIFNJRCAyMDAxOmRiODowOjBLMDE6OiAod2l0aCBLIGJlaW5nIHRoZSBub2RlIElEKSBi b3VuZCB0byBFbmQgd2l0aCBORVhULUMtU0lEIGZsYXZvciBhbmQgMTYtYml0IEMtU0lEIGxlbmd0 aC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPk9uIG5vZGVzIDYgdGhyb3VnaCA5 LCB0aGUgU0lEIDIwMDE6ZGI4OjA6MEswMDowMDAxOjogKHdpdGggSyBiZWluZyB0aGUgbm9kZSBJ RCkgYm91bmQgdG8gRW5kIHdpdGggUkVQTEFDRS1DLVNJRCBmbGF2b3IgYW5kIDMyLWJpdCBDLVNJ RCBsZW5ndGguPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z by1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBub2RlIDEwLCB0 aGUgU0lEIDIwMDE6ZGI4OjA6MTAwMDowMDAxOjogYm91bmQgdG8gRW5kIChSRkMgODk4NikuPG86 cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBub2RlIDExLCBhIFNJRCAyMDAxOmRi ODowOjExMDA6ZDEyMzo6IGJvdW5kIHRvIEVuZC5EVDQgKFJGQyA4OTg2KSBmb3IgVlJGIDEyMy48 bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgU1Igc291cmNlIG5vZGUgdGhlbiBzZW5k cyB0aGUgcGFja2V0IG9udG8gdGhlIFNSIHBhdGggYnkgcGVyZm9ybWluZyB0aGUgSC5FbmNhcHMu UmVkIGJlaGF2aW9yIHdpdGg6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHVsIHR5cGU9ImRpc2Mi Pg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+DQo8c3Bh biBsYW5nPSJFTi1VUyI+SVB2NiBTb3VyY2UgQWRkcmVzcyA9ICZsdDthbiBhZGRyZXNzIG9mIHRo ZSBTUiBzb3VyY2Ugbm9kZSZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPklQ djYgRGVzdGluYXRpb24gQWRkcmVzcyA9IDIwMDE6ZGI4OjA6MDEwMTowMjAxOjAzMDE6MDQwMTow NTAxPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0 OmwxIGxldmVsMSBsZm8yIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5TUkggPTxvOnA+PC9vOnA+PC9z cGFuPjwvbGk+PC91bD4NCjx1bCB0eXBlPSJkaXNjIj4NCjx1bCB0eXBlPSJjaXJjbGUiPg0KPGxp IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDIgbGZvMiI+DQo8c3BhbiBsYW5n PSJFTi1VUyI+U2VnbWVudExpc3RbMF0gPSAyMDAxOmRiODowOjExMDA6ZDEyMzo6PG86cD48L286 cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxIGxldmVsMiBs Zm8yIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5TZWdtZW50TGlzdFsxXSA9IDEwMDA6MDAwMTowOTAw OjAwMDE6MDgwMDowMDAxOjA3MDA6MDAwMTxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMSBsZXZlbDIgbGZvMiI+DQo8c3BhbiBsYW5nPSJFTi1V UyI+U2VnbWVudExpc3RbMl0gPSAyMDAxOmRiODowOjA2MDA6MDAwMTo6PG86cD48L286cD48L3Nw YW4+PC9saT48L3VsPg0KPC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZXJlZm9yZSwgdGhlcmUgaXMgbm8gbm90aW9uIG9mIGxv d2VzdCBjb21tb24gZGVub21pbmF0b3IgZm9yIEMtU0lEIGxlbmd0aC4gQmFzZWQgb24gdGhlIGRl cGxveW1lbnQgcmVxdWlyZW1lbnRzLCBhbiBvcGVyYXRvciBoYXMgdGhlIGZsZXhpYmlsaXR5IHRv IHNlbGVjdCB0aGUNCiBTUnY2IFNJRCBmbGF2b3IgYW5kIEMtU0lEIGxlbmd0aHMgb2YgdGhlaXIg Y2hvaWNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPldlIGNhbiB1cGRhdGUgdGhlIGRyYWZ0IHdp dGggdGhpcyB0eXBlIG9mIGlsbHVzdHJhdGlvbnMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhh bmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiPkZyYW5jb2lzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21h cmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJs YWNrIj5zcHJpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnNwcmluZy1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxm IG9mIEd5YW4gTWlzaHJhICZsdDs8YSBocmVmPSJtYWlsdG86aGF5YWJ1c2Fnc21AZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+aGF5YWJ1c2Fnc21AZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5E YXRlOiA8L2I+U3VuZGF5LCAzIE9jdG9iZXIgMjAyMSBhdCAyMTowMTxicj4NCjxiPlRvOiA8L2I+ WWlzb25nIExpdSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxpdXlpc29uZ0BjaGluYW1vYmlsZS5jb20i IHRhcmdldD0iX2JsYW5rIj5saXV5aXNvbmdAY2hpbmFtb2JpbGUuY29tPC9hPiZndDs8YnI+DQo8 Yj5DYzogPC9iPkphbWVzIEd1aWNoYXJkICZsdDs8YSBocmVmPSJtYWlsdG86amFtZXMubi5ndWlj aGFyZEBmdXR1cmV3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+amFtZXMubi5ndWljaGFyZEBmdXR1 cmV3ZWkuY29tPC9hPiZndDssIFNQUklORyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7LCBzcHJpbmct Y2hhaXJzICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnNwcmluZy1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6 IDwvYj5SZTogW3NwcmluZ10gUkU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O01TIEdvdGhpYyZxdW90Oztjb2xvcjpibGFjayI+77yaPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iY29sb3I6YmxhY2siPiBXRyBBZG9wdGlvbiBjYWxsIGZvcg0KPGEgaHJlZj0iaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmct c3J2Ni1zcmgtY29tcHJlc3Npb24vIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21w cmVzc2lvbi88L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSZuYnNwO1lpc29uZzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUg bWFpbiBnb2FsIGZvciBvcGVyYXRvcnMgaXMgaW50ZXJvcGVyYWJpbGl0eS4mbmJzcDsgQXMgaW50 ZXJvcGVyYWJpbGl0eSBpcyB0aGUga2V5IHJlYXNvbiBmb3IgYSBzaW5nbGUgU1J2NiBjb21wcmVz c2lvbiBzb2x1dGlvbiB0aGF0IHdlIGhhdmUgV0cgY29uc2Vuc3VzIGFuZCBpcw0KIGRlc2lyZWQu ICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiPkNvbnRpbnVlZCBkZXRhaWxzIG9mIHRoZSBpbnRlcm9wZXJhYmlsaXR5IHN0dWR5ICZuYnNw O3Nob3VsZCBiZSBhZGRlZCB0byB0aGUgZHJhZnQgYXMgdGhlIHN0dWR5IHByb2dyZXNzZXMuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+T25lIGtl eSBkZXRhaWwgdGhhdCBpcyBtaXNzaW5nIGlzIGZvcndhcmRpbmcgZWZmaWNpZW5jeSBhbmQgc2Nh bGFiaWxpdHkgdXNpbmcgTkVYVC1DLVNJRCBhbmQgUkVQTEFDRS1DLVNJRCBpbnRlcm9wZXJhYmls aXR5IHVzaW5nIDE2IGJpdCBTSUQuICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkFzIE5FWFQtQ1NJRCB1U0lEIENvbnRhaW5lciBNaWNy byBTZWdtZW50IHNoaWZ0IGZsYXZvciB1c2luZyBHSUIvTElCIGZvciB1bHRyYSBzY2FsZSAmbmJz cDtTUnY2IGNvbXByZXNzaW9uIHNvbHV0aW9uIGlzIHJlY29tbWVuZGVkIGZvciAxNiBiaXQgU0lE IGFuZCBSRVBMQUNFLUMtU0lEDQogRy1TSUQgRy1TSUQgQ29udGFpbmVyIGJhc2VkIHNvbHV0aW9u IGlzIHJlY29tbWVuZGVkIGZvciAzMiBiaXQgU0lELjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk9mIGFsbCB0aGUgcmVxdWlyZW1lbnRzIGFzIHN0 YXRlZCwgdGhlIGVuY2Fwc3VsYXRpb24gaGVhZGVyIHNpemUgaXMgdGhlIHByaW1hcnkgb2JqZWN0 aXZlIGZvciBvcGVyYXRvcnMgdG8gZWxpbWluYXRlIE1TRCBpc3N1ZXMgd2l0aCBvcHRpbWFsIGZv cndhcmRpbmcgYW5kIHN0YXRlDQogZWZmaWNpZW5jaWVzLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPkF0IHRoaXMgdGltZSBpbiBvcmRl ciBmb3IgTmV4dCBhbmQgUmVwbGFjZSBzb2x1dGlvbnMgdG8gYmUgaW50ZXJvcGVyYWJsZSBrZWVw aW5nIGluIG1pbmQgcmVxdWlyZW1lbnRzIGZvciBvcHRpbWFsIGZvcndhcmRpbmcgYW5kIHN0YXRl IGVmZmljaWVuY3kgMzIgYml0IFNJRCB3b3VsZA0KIGJlIHRoZSBsb3dlc3QgY29tbW9uIGRlbm9t aW5hdG9yIHdoaWNoIHNob3VsZCBiZSBzdGF0ZWQgYXMgdGhlIGJhc2VsaW5lIHJlc3VsdCBvZiB0 aGUgYW5hbHlzaXMgZHJhZnQgb24gQ1NJRCBvdmVyYWxsIDIgcHJvbmcgc29sdXRpb24uPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Q1NJRCBkcmFm dDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNy aC1jb21wcmVzc2lvbi0wMiNzZWN0aW9uLTExIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2 LXNyaC1jb21wcmVzc2lvbi0wMiNzZWN0aW9uLTExPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Qm90dG9tIG9mIHNlY3Rpb24gMTE6PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDsiPiZuYnNwOyAmbmJzcDtUaGUgaW50ZXJvcGVyYWJpbGl0eSB3YXMgdmFsaWRhdGVk IGZvciB0aGUgZm9sbG93aW5nIHNjZW5hcmlvOjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHlsZT0iYnJlYWstYmVm b3JlOnBhZ2UiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZu YnNwOyBvJm5ic3A7IFBhY2tldCBmb3J3YXJkaW5nIHRocm91Z2ggYSB0cmFmZmljIGVuZ2luZWVy aW5nIHNlZ21lbnQgbGlzdDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg Y29tYmluaW5nLCBpbiB0aGUgc2FtZSBTUkggKFs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL3JmYzg3NTQiIHRhcmdldD0iX2JsYW5rIiB0aXRsZT0iJnF1b3Q7 SVB2NiBTZWdtZW50IFJvdXRpbmcgSGVhZGVyIChTUkgpJnF1b3Q7Ij5SRkM4NzU0PC9hPl0pLCBT UnY2IFNJRHMgYm91bmQgdG8gYW48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IGVuZHBvaW50IGJlaGF2aW9yIHdpdGggdGhlIE5FWFQtQy1TSUQgZmxhdm9yIGFuZCBTUnY2 IFNJRHMgYm91bmQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRvIGFu IGVuZHBvaW50IGJlaGF2aW9yIHdpdGggdGhlIFJFUExBQ0UtQy1TSUQgZmxhdm9yLjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IEZ1cnRoZXIgaW50ZXJvcGVyYWJpbGl0eSB0 ZXN0aW5nIGlzIG9uZ29pbmcgYW5kIHdpbGwgYmUgcmVwb3J0ZWQgaW48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7 Jm5ic3A7IHRoaXMgZG9jdW1lbnQgYXMgdGhlIHdvcmsgcHJvZ3Jlc3Nlcy48L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+ PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5LaW5nIFJlZ2FyZHMmbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5H eWFuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBTYXQsIE9jdCAyLCAyMDIxIGF0IDEyOjU2IEFN IFlpc29uZyBMaXUgJmx0OzxhIGhyZWY9Im1haWx0bzpsaXV5aXNvbmdAY2hpbmFtb2JpbGUuY29t IiB0YXJnZXQ9Il9ibGFuayI+bGl1eWlzb25nQGNoaW5hbW9iaWxlLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow Y207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDvlvq7ova/p m4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SGkgQ2hhaXJzICZhbXA7IFdHLDwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+SSBzdHJvbmdseSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBjYWxsLiBSZWdhcmRp bmcgY2hhaXIncyBub3RlIGluIHRoZSBlbWFpbCwgSSB3b3VsZCBsaWtlIHRvIHBvaW50IHRoYXQg dGhlIG5ldHdvcmsNCiBwcm9ncmFtbWluZyBtb2RlbCAoUkZDODk5NikgYnkgbmF0dXJlIGRlZmlu ZXMgbXVsdGlwbGUgYmVoYXZpb3JzLiBDU0lEIGhhcyBhIHNpbmdsZSBTUnY2IGJhc2VkIGRhdGEg cGxhbmUgdGhhdCBkZWZpbmVzIHRoZSBuZXh0IGFuZCByZXBsYWNlIGJlaGF2aW9ycyBjb25zaXN0 ZW50IHdpdGggdGhlIG5ldHdvcmsgcHJvZ3JhbW1pbmcgcGFyYWRpZ20uPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6YmxhY2siPkNTSUQncyBuZXh0IGFuZCByZXBsYWNlIGJlaGF2aW9ycyBoYXZl IGJlZW4gdmVyaWZpZWQgYnkmbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+aW50ZXJvcGVy YWJpbGl0eQ0KIHRlc3QmbmJzcDtpbiBDaGluYSBtb2JpbGUgbGFib3JhdG9yeSBhbmQgdDxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+aGVyZSBpcyBubyBwcm9ibGVtIHdpdGggdGhlIGludGVyd29y a2luZyBvZiB0aGUgdHdvIGJlaGF2aW9ycyBvbiB0aGUgQ1NJRCBkYXRhcGxhbmUuPC9zcGFuPjwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjpibGFjayI+QmVzdCBSZWdhcmRzPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 5b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPllpc29uZzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6Ni4wcHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMz MzMzIj7lj5Hku7bkuro8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj46DQo8 YSBocmVmPSJtYWlsdG86amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tIiB0YXJnZXQ9Il9i bGFuayI+SmFtZXMgR3VpY2hhcmQ8L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMzMzMzMzIj7ml7bpl7Q8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMz MzMzIj46IDIwMjEvMTAvMDEoPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDvl vq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj7mmJ/mnJ/kupQ8L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xp u5EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj4pMjI6MDQ8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7 kSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPuaUtuS7tuS6ujwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPjoNCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5TUFJJTkcgV0c8L2E+Ozwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+5oqE6YCB5Lq6PC9zcGFuPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzMzMzMzMyI+Og0KPGEgaHJlZj0ibWFpbHRvOnNwcmluZy1jaGFpcnNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmctY2hhaXJzPC9hPjs8L3NwYW4+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPuS4u+mimDwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMzMzMzMzMiPjogW3NwcmluZ10gV0cgQWRvcHRpb24gY2FsbCBmb3INCjxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmct c3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1z cmgtY29tcHJlc3Npb24vPC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5EZWFyIFdHOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiPlRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBleHByZXNzIHRoZWlyIGFwcHJlY2lh dGlvbiBmb3IgYWxsIHRoZSByZXNwb25zZXMgcmVjZWl2ZWQgdG8gb3VyIGVtYWlscyB3aXRoIHJl ZmVyZW5jZSB0byBob3cgdGhlIHdvcmtpbmcgZ3JvdXAgd2lzaGVzIHRvIG1vdmUgZm9yd2FyZA0K IHdpdGggcmVzcGVjdCB0byBhIHNvbHV0aW9uIGZvciBTUnY2IGNvbXByZXNzaW9uLiA8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj5UaGUgYXBwYXJlbnQgaW5jbGluYXRpb24gb2YgdGhlIHdvcmtpbmcg Z3JvdXAgaXMgdG8gdXNlDQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8iIHRhcmdl dD0iX2JsYW5rIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNm aWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLzwvYT4gYXMgdGhlIGJhc2lzIGZv ciBpdHMgY29tcHJlc3Npb24gc3RhbmRhcmRpemF0aW9uIHdvcmsuIFRoYXQgaXMgcGFydCBvZiB3 aGF0IHRoaXMgZW1haWwgYXR0ZW1wdHMgdG8gY29uZmlybS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT Ij5CZWNhdXNlIG9mIHRoZSBhYm92ZSB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gaXNzdWUgYSAy LXdlZWsgV0cgY2FsbCBmb3IgYWRvcHRpb24gZW5kaW5nIE9jdG9iZXIgMTU8c3VwPnRoPC9zdXA+ IGZvcg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmls c2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vIiB0YXJnZXQ9Il9ibGFuayI+ DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNw cmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88L2E+IGJ1dCB3aXRoIHNvbWUgY2xlYXIgZ3VpZGVs aW5lcyBhcyBmb2xsb3dzLiBCeSBleHByZXNzaW5nIHN1cHBvcnQgZm9yIGFkb3B0aW9uIG9mIHRo aXMgZG9jdW1lbnQgeW91IGFyZSBmdWxseSBhd2FyZSBvZiBhbmQgYXJlIGFja25vd2xlZGdpbmcg dGhhdDoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxvbCBzdGFydD0i MSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwzIGxldmVsMSBs Zm8zIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAgaXMgYWRv cHRpbmcgYSBkb2N1bWVudCB0aGF0IGhhcyBtdWx0aXBsZSBTUnY2IEVuZHBvaW50IGJlaGF2aW9y cy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMyBsZXZlbDEgbGZvMyI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+VGhlIGRvY3VtZW50IGlzIGEg 4oCcbGl2aW5n4oCdIGRvY3VtZW50OyBpdCBtYXkgY2hhbmdlIGFzIGl0IGdvZXMgdGhyb3VnaCBy ZXZpZXcgYW5kIGFuYWx5c2lzIGJ5IHRoZSBTUFJJTkcgd29ya2luZyBncm91cC4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDEg bGZvMyI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+QWxsIG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgcmFp c2VkIG9uIG91ciBtYWlsaW5nIGxpc3QgTVVTVCBiZSBhZGRyZXNzZWQgQkVGT1JFIHNhaWQgZG9j dW1lbnQgaXMgYWxsb3dlZCB0byBwcm9ncmVzcyBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIHRvIHB1 YmxpY2F0aW9uLiBBIGxpc3Qgb2YgdGhlc2UgZGlzY3Vzc2lvbiBwb2ludHMgd2lsbCBiZSBkb2N1 bWVudGVkIGluIHRoZSBXRyBkb2N1bWVudCBhbmQgbWFpbnRhaW5lZA0KIGJ5IHRoZSBkb2N1bWVu dCBlZGl0b3IgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgY2hhaXJzLiA8bzpwPjwvbzpwPjwvc3Bh bj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDMgbGV2ZWwxIGxmbzMiPg0K PHNwYW4gbGFuZz0iRU4tVVMiPklmIHRoaXMgZG9jdW1lbnQgaXMgYWRvcHRlZCBieSB0aGUgd29y a2luZyBncm91cCwgdGhlIGNoYWlycyBzcGVjaWZ5IGFzIHBhcnQgb2YgdGhlIGFkb3B0aW9uIGNh bGwgdGhhdCB0aGUgZm9sbG93aW5nIHRleHQgZGVzY3JpYmluZyBhbiBvcGVuIGlzc3VlIGJlIGFk ZGVkIHRvIHRoZSBkb2N1bWVudCBpbiB0aGUgYWJvdmUtZGVzY3JpYmVkIG9wZW4gaXNzdWVzIHNl Y3Rpb246PG86cD48L286cD48L3NwYW4+PC9saT48L29sPg0KPG9sIHN0YXJ0PSI0IiB0eXBlPSIx Ij4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDIg bGV2ZWwyIGxmbzQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPiZxdW90O0dpdmVuIHRoYXQgdGhlIHdv cmtpbmcgZ3JvdXAgaGFzIHNhaWQgdGhhdCBpdCB3YW50cyB0byBzdGFuZGFyZGl6ZSBvbmUgZGF0 YSBwbGFuZSBzb2x1dGlvbiwgYW5kIGdpdmVuIHRoYXQgdGhlIGRvY3VtZW50IGNvbnRhaW5zIG11 bHRpcGxlIFNSdjYgRW5kUG9pbnQgYmVoYXZpb3JzIHRoYXQgc29tZSBXRyBtZW1iZXJzIGhhdmUg c3RhdGVkIGFyZSBtdWx0aXBsZSBkYXRhIHBsYW5lIHNvbHV0aW9ucywgdGhlIHdvcmtpbmcNCiBn cm91cCB3aWxsIGFkZHJlc3Mgd2hldGhlciB0aGlzIGlzIHZhbGlkIGFuZCBjb2hlcmVudCB3aXRo IGl0cyBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiBvYmplY3RpdmUuJnF1b3Q7LjxvOnA+PC9vOnA+ PC9zcGFuPjwvbGk+PC91bD4NCjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5QbGVhc2UgY29uc2lkZXIgdGhlIGFib3ZlIGd1aWRl bGluZXMgYXMgeW91IGRlY2lkZSBvbiB3aGV0aGVyIHRvIHN1cHBvcnQgb3Igbm90IHRoaXMgV0cg YWRvcHRpb24uIFBsZWFzZSBleHByZXNzIGNsZWFybHkgeW91ciByZWFzb25pbmcgZm9yIHN1cHBv cnQvbm9uLXN1cHBvcnQNCiBhcyB3ZWxsIGFzIGFueSBvcGVuIGRpc2N1c3Npb24gcG9pbnRzIHlv dSB3b3VsZCBsaWtlIGFkZHJlc3NlZCBzaG91bGQgdGhlIGRvY3VtZW50IGJlIGFkb3B0ZWQgaW50 byB0aGUgd29ya2luZyBncm91cC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MhPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyI+SmltLCBCcnVubyAmYW1wOyBKb2VsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc3ByaW5nIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zcHJpbmciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NwcmluZzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+LS0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6IzIyMjIyMiI+PGEgaHJlZj0iaHR0cDovL3d3dy52ZXJpem9uLmNv bS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzExNTVDQztib3JkZXI6c29s aWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbTt0ZXh0LWRlY29yYXRpb246bm9uZSI+PGlt ZyBib3JkZXI9IjAiIHdpZHRoPSI4MSIgaGVpZ2h0PSIxOCIgaWQ9Im1fLTQ0NzQ2MjQyMTY3OTQ1 NzcxNW1fLTUzNTk3MjAzNDQzODgxODI4NTNtXy03MTQyMDY4NTM2NDU5NzY5MzI5X3gwMDVmX3gw MDAwX2kxMDI1IiBzcmM9ImNpZDppbWFnZTAwMS5qcGdAMDFEN0MwODguQTI1MTk1RTAiIGFsdD0i 5Zu+5YOP5bey6KKr5Y+R5Lu25Lq65Yig6Zmk44CCIj48L3NwYW4+PC9hPjwvc3Bhbj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkd5YW4gTWlz aHJhPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij48aT48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDssc2VyaWY7Y29s b3I6YmxhY2siPk5ldHdvcmsgU29sdXRpb25zIEFyY2hpdGVjdCZuYnNwOzwvc3Bhbj48L2k+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJnaW46 MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdCI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDssc2VyaWY7Y29s b3I6YmxhY2siPkVtYWlsDQo8YSBocmVmPSJtYWlsdG86Z3lhbi5zLm1pc2hyYUB2ZXJpem9uLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmd5YW4ucy5taXNocmFAdmVyaXpvbi5jb208L2E+PC9zcGFuPjwv aT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0dlb3JnaWEmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPk0gMzAxIDUwMi0xMzQ3 PC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0tIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzIyMjIyMiI+PGEgaHJl Zj0iaHR0cDovL3d3dy52ZXJpem9uLmNvbS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Y29sb3I6IzExNTVDQztib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBjbTt0 ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSI4MSIgaGVpZ2h0PSIx OCIgaWQ9Il94MDAwMF9pMTAyNiIgc3JjPSJjaWQ6aW1hZ2UwMDEuanBnQDAxRDdDMDg4LkEyNTE5 NUUwIiBhbHQ9IuWbvuWDj+W3suiiq+WPkeS7tuS6uuWIoOmZpOOAgiI+PC9zcGFuPjwvYT48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4w MDAxcHQ7bXNvLWxpbmUtaGVpZ2h0LWFsdDo5Ljc1cHQiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj ayI+R3lhbiBNaXNocmE8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbjowY207bWFyZ2luLWJvdHRvbTouMDAwMXB0 O21zby1saW5lLWhlaWdodC1hbHQ6OS43NXB0Ij48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDssc2VyaWY7Y29sb3I6YmxhY2siPk5ldHdv cmsgU29sdXRpb25zIEFyY2hpdGVjdCZuYnNwOzwvc3Bhbj48L2k+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjojMjIyMjIyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0i bWFyZ2luOjBjbTttYXJnaW4tYm90dG9tOi4wMDAxcHQ7bXNvLWxpbmUtaGVpZ2h0LWFsdDo5Ljc1 cHQiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtHZW9yZ2lhJnF1b3Q7LHNlcmlmO2NvbG9yOmJsYWNrIj5FbWFpbA0KPGEgaHJl Zj0ibWFpbHRvOmd5YW4ucy5taXNocmFAdmVyaXpvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5neWFu LnMubWlzaHJhQHZlcml6b24uY29tPC9hPjwvc3Bhbj48L2k+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjojMjIyMjIyIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OjBjbTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0 O21hcmdpbi1sZWZ0OjBjbTttc28tbGluZS1oZWlnaHQtYWx0OjkuNzVwdCI+DQo8aT48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDssc2VyaWY7 Y29sb3I6YmxhY2siPk0gMzAxIDUwMi0xMzQ3PC9zcGFuPjwvaT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1c919ecf8db842dc8ecda349a74b741chuaweicom_-- --_004_1c919ecf8db842dc8ecda349a74b741chuaweicom_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=361; creation-date="Wed, 13 Oct 2021 15:37:58 GMT"; modification-date="Wed, 13 Oct 2021 15:37:58 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAAXAGUBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZqKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKK//2Q== --_004_1c919ecf8db842dc8ecda349a74b741chuaweicom_-- From nobody Wed Oct 13 13:05:33 2021 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 1CE2C3A0D4F; Wed, 13 Oct 2021 13:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 W15X4gqG9gPx; Wed, 13 Oct 2021 13:05:25 -0700 (PDT) Received: from na01-obe.outbound.protection.outlook.com (mail-oln040093003014.outbound.protection.outlook.com [40.93.3.14]) (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 A86773A0D4E; Wed, 13 Oct 2021 13:05:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HQZrg38zAEHnmgpZmVxoGefvfWSW4ctpqXnjkdZWDLMHgouxE3yojmL6Kgk9mK7o6YJxvXfyC61ATtmZiYvV3FwlM2mflhkkiSagNmadaOxb9yOvcB3F6HTbiOKCb6bTfsv1DI5QlornkfCOEv4O1lM8jvbWAKEUYf6y8uXvuCx4R5JgZhZ0PQTuIxVtn4RwW5r+zjvuGIlumFuO24VQ/+4rkvLvrbJAhuMHnAFHMzrQCMJsPlQRse2vJ9LnfqP3HddovANcl72AH0fuWVsyTo67WvrkU1g+IW66okzhg+MFecDWBFuekz0LfY8wHp+xKDIjgdWzdn8c5pJUatv+xw== 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=/LsCB4NUHowB5iI2rWkEZI3cfjcXihn89Wo/BoYk7H4=; b=HMYTBDNSLBWipx0bd7GkHgPwb370Noj7paOnmaIQ8dMSr03S5HZTwVun1Qk9eXA1kI9YrEWQhPUjQlBaeWoZGV1fF5RufGpZMCMH6R+fIVkE0LbegKvDxd5ks8oI+ANEzsUytwFZyLrhcqY0Uz23PE02GNCiGNlgW8/ouW9RQYQ1hsV4gIrhCRN8+8uEbpihW+K3SHSrPM2VUoYFQrVxWSNgeg1AFAAId8gMhOUv+OwEP+sQTaUOj1edkW6q409hZZCYSt3bBkUdg34FKzOJe4Mb25fft5G3Vp/NvMjpXvqKhPExu7UaCSePM3dfrOPBF8a2uDBAnte2DnIiO5b1jw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/LsCB4NUHowB5iI2rWkEZI3cfjcXihn89Wo/BoYk7H4=; b=VZ9resGnWOIreHntxZX7g2KmMZzO1/I1OiyDPRcfONIFweDulWopiFObjlc5nWbnORwMh4cUUinwN4hhBVqy8oZmSZh2MPhjKPHc0NnXOz0rXzS6xcBfsSQPH8EZ4Mk02KfcNcQqwkc/yAPyTLUSbuW1XpUlB+m7hAVcbqYjyW8= Received: from DM5PR21MB0508.namprd21.prod.outlook.com (2603:10b6:3:eb::14) by DM5PR21MB0747.namprd21.prod.outlook.com (2603:10b6:3:a3::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.3; Wed, 13 Oct 2021 20:05:22 +0000 Received: from DM5PR21MB0508.namprd21.prod.outlook.com ([fe80::d54b:a0bc:da44:ba0e]) by DM5PR21MB0508.namprd21.prod.outlook.com ([fe80::d54b:a0bc:da44:ba0e%8]) with mapi id 15.20.4628.009; Wed, 13 Oct 2021 20:05:22 +0000 From: Paul Mattes To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQJoVveg Date: Wed, 13 Oct 2021 20:05:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=bcc63afe-f62c-472e-8cc4-443649122351; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2021-10-13T20:02:16Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=microsoft.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dc73797d-cb83-47d3-2ab1-08d98e84ca17 x-ms-traffictypediagnostic: DM5PR21MB0747: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 99XIVKn7A0hFyO+wVIypza4JSsFlIHnJH2u2Q7dIIF/hG2edf4lsexVsRrIo8R5zUvxUHru8NaZEYF020at5CWnHBdZXAKIdcEDZSaafzDexCSkT0SVMNS97NtYaZbRPRMZ+cMZxA/HrDtYk7XAnLGGW/vUjUB5cWC8KYPAGQBcWHKjrVH/s21c65keJRVT1jJ+RcMxLhtX1OvI6vIFeY71jhD1r3avL3Y/GiPZvLVTKQhVN+oEV9ahujkNNIw2ypam/S3YW1cig+XyVjWsn1gWg2JCDXb90PS2Ptfx3HYzbCid3McGH1sVjxSp8hDF2C5oS/fqeQKVOKB8HxLyFBA6S1mleeFmzeqhP2wrXsz/0yq5yQNFw5WHpLvT5RdY2v4FTJp+eT8OhYn8Ok0Ddkd0L5zDdGTba0dLipGoZdVxJ5hLvo+YBkIvWtfClig21rxJoeuICJi/jisnczu66RuWroucDwRw/dCjZNguDdSi2MMAlMoV0R+jwUceSMxawx1xB0drPIV3QmrfVLqFxqgDXdjnbigrH1P8iaESIcK0VV3PExBAYm9HVyRLo9ELwFRAvh4AN4ai/DBCjv7oIT+3syVUxF5AJsnmskkimiiAul6UwMPaHQlXCLU1fzsIw1nCpT+UhxHCaRbPPtNYmnvkNd+1C1P9WnzDdqTqs+kDgE9IgF3dWz1UVbIoyjOluteRxdkU1x1AalFZc30EEVLUVa84jIphwNCPNjnUG+HBksgxsvPNNCc+jyYgyn/8tQi49mqzJU15ZcyQ2/y9sqI8QGVt4oeHXAvxeMpoIMq0= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM5PR21MB0508.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(26005)(71200400001)(508600001)(316002)(8936002)(7696005)(86362001)(4326008)(52536014)(10290500003)(8676002)(110136005)(33656002)(166002)(55016002)(76116006)(966005)(83380400001)(186003)(9686003)(5660300002)(82960400001)(82950400001)(38100700002)(6506007)(64756008)(8990500004)(66476007)(38070700005)(66446008)(66946007)(66556008)(2906002)(53546011)(122000001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?QUpqUXVXcXphOWJaQmRZMnllUVBlUWsrQklqV0F3d1U0SUlYcnNhejlhZXgv?= =?utf-8?B?ek5YZFJjYWc5SkJSNEVkb3UvdTRrUTdQaVVjOUVHNzRXRm50eWs3djgweC9z?= =?utf-8?B?SzNkUG5LLzUzSkhvNUViQ2lEUnRiSGR3SElwYU15TWQ2V3N3RFlZSFFZeDRX?= =?utf-8?B?SXZJY3lja1pkeG0rdk0wdWtMR3BhT2Z2QUE2WW8wc214RHRKYjJ6K2VTaW55?= =?utf-8?B?ZDZmcVZhUzFkbTJURFpPcEFuVUdrWU5Tdm1yZm1BalFIT1hhMXRyNTBVc3l2?= =?utf-8?B?UzlFZHBJbnplVlBtL2NsTTJKUSs5MSsvajFtR28vMzk1eEJPMjIyenIvWHlh?= =?utf-8?B?Um5iYmpqZFlQZXNsdDcxT0tVVmEwbGdvNW9ML0Y0azdlVnJpb0ZERmxSTEVY?= =?utf-8?B?aUlSV3VDYTBPYU9FOEE5WWVNVmhhZSt2c3dZWm9GUlVhZjZZVTFocFlsTXRs?= =?utf-8?B?dm1MNjVSejBlVmdEY3VwZVZCTTEzdnN3WEplcVhOb29HUElkK2pjYVB2bk5K?= =?utf-8?B?dU85a29aejMrc1ptYVhRcWtwU0tXZFZDZ0dpNk1ET1FyVEVRVmJPcFBhYnpK?= =?utf-8?B?T0tYTVBvSHozd01RbFVVdnRmYWhzL3V5R0lvSXFmMFl2QzlvS282MXF0QlYw?= =?utf-8?B?N3hnRFcvWEZvb2xBbWZMRGNac3JMMEFabUw2NGMxKytIT21ncXNlNGVxUTd6?= =?utf-8?B?UkY3Sk1jU1FjbnJMcjViWGVNVUs5WkQ2dy9rN1BqTFlreXp3M0dueHc5NHNK?= =?utf-8?B?a3JPTUdYNmErSEp4SUVSRk12dHlpeUZObUlXSmhxZENOWmtEcE55N0lEZnNr?= =?utf-8?B?eHI0R2dYd3MzL3dFRmR5WTRMbGRFQzlvM3kxdEdhUzFXTHY2azduc0JaWXRj?= =?utf-8?B?TlBtRVg4dzR5VWxnQkkyYk9zakVUZllnV0hWZnpXS0JYajErdmx5enl0YjR4?= =?utf-8?B?L1FwUjIwNHZjUEt4OG8rOWIrdjJNZXJDSHFpY3RLY0dGUXIvQldKNFJ6dmVt?= =?utf-8?B?Y0IzUTlJWVBIM05obk1hMWMxS2J0M2twTTI0NlVzRzRmT1VLWFFxMGoydThy?= =?utf-8?B?S09vRWpiWFVPTVAzMUd2M09uRThIYVhzTlo4RUVWNGRSbHU4Yi9YVHppNStQ?= =?utf-8?B?ejBONlZmTlZZeUZtTHM1QTlrLzdiZlZQcVR3djVZdXBRSTF5VFJSYndLalp3?= =?utf-8?B?dUJoMTR3NXdzNkdkTUJWYTRqUENEMnZ3K3ZjbThEcE1SK09xTHk2NUUvbkdx?= =?utf-8?B?V1BoM1ZuT0J4Sm1naTRCaVNZZ2U1ekcrNzVrcjZmY2FSOXZHRjV5OStGSEc5?= =?utf-8?B?bzQ2b2tnMDZ3dHpUd0ZuTE82UE5sNWlKTDluM3BHTUxtZjdVTENoakt3YTZm?= =?utf-8?B?WWIvRE9LZXN3U2dkT0ZmTkxNQkV3YXNKejJPREhucHRrS2EvMWwvY2U2a2lt?= =?utf-8?B?SE5GdGtPREJJVzc5dWUxUHFGY1VtWWFCbFBsOXZ4K1V1bFpLWTlmYXRXUjZn?= =?utf-8?B?TmpVYThSNzVWQTF2QzhwZzZ4WkticEZFb0EwV0FwMEhYTFFVd1BWRVFKTm5s?= =?utf-8?B?dkVlZmkxUWp5ai84amNSRXFGTE1DanVvMTJtSlBGOGFGNXc3SE1GdVE4dmRw?= =?utf-8?B?WkpBTm16VWpCOVRmbXp0UTFDM3BGdUU3WG82THN1RTJEcmJVVWQxY0RHUWx4?= =?utf-8?B?ekJqVmxkTXJ0VkxlQkNlaTFTbXBtMGliM3VSRzFZdU5lM016N01VQVVnem9m?= =?utf-8?B?Wlk0N0lteEFmemIrQThudVJxWHp0VFM1QjRsN2hUNk02Q3pUeSs5cG9Td3JO?= =?utf-8?B?OXg2d1AvVllrK0t1SlhoVnA2dlIyNmo2WGsxUUxUYVBkY3hUUWFIb2gzOVBX?= =?utf-8?B?MklrNUxDYTBmajEzcThaYjRWeSsxVWF0UGo5VVBJWnRXckVCUnJQTTNiYzRR?= =?utf-8?B?YVE1VnVzQnlDcVJZS1JTb0JWMUdacDd2KzN3aktFWDZhUmgyMVI1NXAyVWYw?= =?utf-8?B?dlh0T1B0WmVybmxWbGwrN0FXS1JGSU5XaVBrU2hVbEU3cncyK3pQS202d1c0?= =?utf-8?B?WFRaTHU1Zk56OG1lTWFhUFc5UHY0OGZYcWN0bjZOR0ozRUVSajE5ZnozSmw1?= =?utf-8?B?REg1U2RVRHR0UFhsay96dE9QK0Y3TWU3L0RZNEwxekc0Vk01QVZvUWFrdjVo?= =?utf-8?Q?XD8IO66/Q7tMvYyf4YtmSls=3D?= Content-Type: multipart/alternative; boundary="_000_DM5PR21MB05083DB0139F0433CC2AFA0ACAB79DM5PR21MB0508namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM5PR21MB0508.namprd21.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dc73797d-cb83-47d3-2ab1-08d98e84ca17 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2021 20:05:22.5499 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +Qe3k1D0j8AmfXKB0WyJaGiyDwLtmvHq8xeZnbrs8wNKxo0dKryQ6YWai1m5YIF8vmUXCc3K9LfC/tX29WaI/g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR21MB0747 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 13 Oct 2021 20:05:31 -0000 --_000_DM5PR21MB05083DB0139F0433CC2AFA0ACAB79DM5PR21MB0508namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IGFkb3B0aW9uLiBUaGUgZG9jdW1lbnQgZGVzY3JpYmVzIGNoYW5nZXMgdGhhdCBh cmUgY29uc2lzdGVudCB3aXRoIGV4aXN0aW5nIFNSdjYtcmVsYXRlZCBSRkNzLCBhbmQgSSBmaW5k IHRoZSBvYmplY3Rpb24gYWJvdXQgbXVsdGlwbGUgYXBwYXJlbnQgZGF0YSBwbGFuZSBzb2x1dGlv bnMgdG8gYmUgcHV6emxpbmcgYXQgYmVzdC4NCg0KICAgICAgICAgICAgICAgIHBkbQ0KDQpGcm9t OiBzcHJpbmcgPHNwcmluZy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgSmFtZXMgR3Vp Y2hhcmQNClNlbnQ6IEZyaWRheSwgT2N0b2JlciAxLCAyMDIxIDk6MDUgQU0NClRvOiBTUFJJTkcg V0cgPHNwcmluZ0BpZXRmLm9yZz4NCkNjOiBzcHJpbmctY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0 OiBbc3ByaW5nXSBXRyBBZG9wdGlvbiBjYWxsIGZvciBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8N Cg0KRGVhciBXRzoNCg0KVGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGV4cHJlc3MgdGhlaXIgYXBw cmVjaWF0aW9uIGZvciBhbGwgdGhlIHJlc3BvbnNlcyByZWNlaXZlZCB0byBvdXIgZW1haWxzIHdp dGggcmVmZXJlbmNlIHRvIGhvdyB0aGUgd29ya2luZyBncm91cCB3aXNoZXMgdG8gbW92ZSBmb3J3 YXJkIHdpdGggcmVzcGVjdCB0byBhIHNvbHV0aW9uIGZvciBTUnY2IGNvbXByZXNzaW9uLg0KDQpU aGUgYXBwYXJlbnQgaW5jbGluYXRpb24gb2YgdGhlIHdvcmtpbmcgZ3JvdXAgaXMgdG8gdXNlIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5n LXNydjYtc3JoLWNvbXByZXNzaW9uLyBhcyB0aGUgYmFzaXMgZm9yIGl0cyBjb21wcmVzc2lvbiBz dGFuZGFyZGl6YXRpb24gd29yay4gVGhhdCBpcyBwYXJ0IG9mIHdoYXQgdGhpcyBlbWFpbCBhdHRl bXB0cyB0byBjb25maXJtLg0KDQpCZWNhdXNlIG9mIHRoZSBhYm92ZSB0aGUgY2hhaXJzIHdvdWxk IGxpa2UgdG8gaXNzdWUgYSAyLXdlZWsgV0cgY2FsbCBmb3IgYWRvcHRpb24gZW5kaW5nIE9jdG9i ZXIgMTV0aCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2Zp bHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vIGJ1dCB3aXRoIHNvbWUgY2xlYXIg Z3VpZGVsaW5lcyBhcyBmb2xsb3dzLiBCeSBleHByZXNzaW5nIHN1cHBvcnQgZm9yIGFkb3B0aW9u IG9mIHRoaXMgZG9jdW1lbnQgeW91IGFyZSBmdWxseSBhd2FyZSBvZiBhbmQgYXJlIGFja25vd2xl ZGdpbmcgdGhhdDoNCg0KDQogIDEuICBUaGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAgaXMgYWRvcHRp bmcgYSBkb2N1bWVudCB0aGF0IGhhcyBtdWx0aXBsZSBTUnY2IEVuZHBvaW50IGJlaGF2aW9ycy4N CiAgMi4gIFRoZSBkb2N1bWVudCBpcyBhIOKAnGxpdmluZ+KAnSBkb2N1bWVudDsgaXQgbWF5IGNo YW5nZSBhcyBpdCBnb2VzIHRocm91Z2ggcmV2aWV3IGFuZCBhbmFseXNpcyBieSB0aGUgU1BSSU5H IHdvcmtpbmcgZ3JvdXAuDQogIDMuICBBbGwgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyByYWlzZWQg b24gb3VyIG1haWxpbmcgbGlzdCBNVVNUIGJlIGFkZHJlc3NlZCBCRUZPUkUgc2FpZCBkb2N1bWVu dCBpcyBhbGxvd2VkIHRvIHByb2dyZXNzIGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAgdG8gcHVibGlj YXRpb24uIEEgbGlzdCBvZiB0aGVzZSBkaXNjdXNzaW9uIHBvaW50cyB3aWxsIGJlIGRvY3VtZW50 ZWQgaW4gdGhlIFdHIGRvY3VtZW50IGFuZCBtYWludGFpbmVkIGJ5IHRoZSBkb2N1bWVudCBlZGl0 b3IgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgY2hhaXJzLg0KICA0LiAgSWYgdGhpcyBkb2N1bWVu dCBpcyBhZG9wdGVkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLCB0aGUgY2hhaXJzIHNwZWNpZnkgYXMg cGFydCBvZiB0aGUgYWRvcHRpb24gY2FsbCB0aGF0IHRoZSBmb2xsb3dpbmcgdGV4dCBkZXNjcmli aW5nIGFuIG9wZW4gaXNzdWUgYmUgYWRkZWQgdG8gdGhlIGRvY3VtZW50IGluIHRoZSBhYm92ZS1k ZXNjcmliZWQgb3BlbiBpc3N1ZXMgc2VjdGlvbjoNCiAgICAgKiAgICJHaXZlbiB0aGF0IHRoZSB3 b3JraW5nIGdyb3VwIGhhcyBzYWlkIHRoYXQgaXQgd2FudHMgdG8gc3RhbmRhcmRpemUgb25lIGRh dGEgcGxhbmUgc29sdXRpb24sIGFuZCBnaXZlbiB0aGF0IHRoZSBkb2N1bWVudCBjb250YWlucyBt dWx0aXBsZSBTUnY2IEVuZFBvaW50IGJlaGF2aW9ycyB0aGF0IHNvbWUgV0cgbWVtYmVycyBoYXZl IHN0YXRlZCBhcmUgbXVsdGlwbGUgZGF0YSBwbGFuZSBzb2x1dGlvbnMsIHRoZSB3b3JraW5nIGdy b3VwIHdpbGwgYWRkcmVzcyB3aGV0aGVyIHRoaXMgaXMgdmFsaWQgYW5kIGNvaGVyZW50IHdpdGgg aXRzIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uIG9iamVjdGl2ZS4iLg0KDQpQbGVhc2UgY29uc2lk ZXIgdGhlIGFib3ZlIGd1aWRlbGluZXMgYXMgeW91IGRlY2lkZSBvbiB3aGV0aGVyIHRvIHN1cHBv cnQgb3Igbm90IHRoaXMgV0cgYWRvcHRpb24uIFBsZWFzZSBleHByZXNzIGNsZWFybHkgeW91ciBy ZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9uLXN1cHBvcnQgYXMgd2VsbCBhcyBhbnkgb3BlbiBkaXNj dXNzaW9uIHBvaW50cyB5b3Ugd291bGQgbGlrZSBhZGRyZXNzZWQgc2hvdWxkIHRoZSBkb2N1bWVu dCBiZSBhZG9wdGVkIGludG8gdGhlIHdvcmtpbmcgZ3JvdXAuDQoNClRoYW5rcyENCg0KSmltLCBC cnVubyAmIEpvZWwNCg0KDQo= --_000_DM5PR21MB05083DB0139F0433CC2AFA0ACAB79DM5PR21MB0508namp_ 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 Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNv UGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxh aW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHls ZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28t bGlzdC1pZDozNDU3MTYwNDQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi00NDM2NzAxODY7fQ0K QGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDENCgl7bXNvLWxp c3QtaWQ6NzUxNjk5MzkzOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBs YXRlLWlkczotNzIxNjU0Nzc2IDY3Njk4NzAzIDY3Njk4Njg5IDY3Njk4NzE1IDY3Njk4NzAzIDY3 Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwxOmxl dmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5k ZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0K QGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCm9sDQoJe21hcmdpbi1i b3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIgc3R5bGU9IndvcmQt d3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JIHN1cHBvcnQgYWRvcHRpb24uIFRoZSBkb2N1bWVudCBkZXNjcmliZXMgY2hh bmdlcyB0aGF0IGFyZSBjb25zaXN0ZW50IHdpdGggZXhpc3RpbmcgU1J2Ni1yZWxhdGVkIFJGQ3Ms IGFuZCBJIGZpbmQgdGhlIG9iamVjdGlvbiBhYm91dCBtdWx0aXBsZSBhcHBhcmVudCBkYXRhIHBs YW5lIHNvbHV0aW9ucyB0byBiZSBwdXp6bGluZyBhdCBiZXN0LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxpPnBkbTxvOnA+ PC9vOnA+PC9pPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+RnJvbTo8L2I+IHNwcmluZyAmbHQ7c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcm Z3Q7IDxiPk9uIEJlaGFsZiBPZg0KPC9iPkphbWVzIEd1aWNoYXJkPGJyPg0KPGI+U2VudDo8L2I+ IEZyaWRheSwgT2N0b2JlciAxLCAyMDIxIDk6MDUgQU08YnI+DQo8Yj5Ubzo8L2I+IFNQUklORyBX RyAmbHQ7c3ByaW5nQGlldGYub3JnJmd0Ozxicj4NCjxiPkNjOjwvYj4gc3ByaW5nLWNoYWlyc0Bp ZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbc3ByaW5nXSBXRyBBZG9wdGlvbiBjYWxsIGZv ciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNw cmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkRlYXIgV0c6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBjaGFpcnMgd291 bGQgbGlrZSB0byBleHByZXNzIHRoZWlyIGFwcHJlY2lhdGlvbiBmb3IgYWxsIHRoZSByZXNwb25z ZXMgcmVjZWl2ZWQgdG8gb3VyIGVtYWlscyB3aXRoIHJlZmVyZW5jZSB0byBob3cgdGhlIHdvcmtp bmcgZ3JvdXAgd2lzaGVzIHRvIG1vdmUgZm9yd2FyZCB3aXRoIHJlc3BlY3QgdG8gYSBzb2x1dGlv biBmb3IgU1J2NiBjb21wcmVzc2lvbi4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgYXBw YXJlbnQgaW5jbGluYXRpb24gb2YgdGhlIHdvcmtpbmcgZ3JvdXAgaXMgdG8gdXNlIDxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3By aW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88L2E+ IGFzIHRoZSBiYXNpcyBmb3IgaXRzIGNvbXByZXNzaW9uIHN0YW5kYXJkaXphdGlvbiB3b3JrLiBU aGF0IGlzIHBhcnQgb2Ygd2hhdCB0aGlzIGVtYWlsIGF0dGVtcHRzIHRvIGNvbmZpcm0uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkJlY2F1c2Ugb2YgdGhlIGFib3ZlIHRoZSBjaGFpcnMgd291bGQg bGlrZSB0byBpc3N1ZSBhIDItd2VlayBXRyBjYWxsIGZvciBhZG9wdGlvbiBlbmRpbmcgT2N0b2Jl ciAxNTxzdXA+dGg8L3N1cD4gZm9yDQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8i Pg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1z cHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vPC9hPiBidXQgd2l0aCBzb21lIGNsZWFyIGd1aWRl bGluZXMgYXMgZm9sbG93cy4gQnkgZXhwcmVzc2luZyBzdXBwb3J0IGZvciBhZG9wdGlvbiBvZiB0 aGlzIGRvY3VtZW50IHlvdSBhcmUgZnVsbHkgYXdhcmUgb2YgYW5kIGFyZSBhY2tub3dsZWRnaW5n IHRoYXQ6DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgc3RhcnQ9IjEiIHR5cGU9IjEi Pg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21z by1saXN0OmwxIGxldmVsMSBsZm8zIj5UaGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAgaXMgYWRvcHRp bmcgYSBkb2N1bWVudCB0aGF0IGhhcyBtdWx0aXBsZSBTUnY2IEVuZHBvaW50IGJlaGF2aW9ycy4N CjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJn aW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPlRoZSBkb2N1bWVudCBpcyBhIOKA nGxpdmluZ+KAnSBkb2N1bWVudDsgaXQgbWF5IGNoYW5nZSBhcyBpdCBnb2VzIHRocm91Z2ggcmV2 aWV3IGFuZCBhbmFseXNpcyBieSB0aGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAuDQo8bzpwPjwvbzpw PjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGlu O21zby1saXN0OmwxIGxldmVsMSBsZm8zIj5BbGwgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyByYWlz ZWQgb24gb3VyIG1haWxpbmcgbGlzdCBNVVNUIGJlIGFkZHJlc3NlZCBCRUZPUkUgc2FpZCBkb2N1 bWVudCBpcyBhbGxvd2VkIHRvIHByb2dyZXNzIGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAgdG8gcHVi bGljYXRpb24uIEEgbGlzdCBvZiB0aGVzZSBkaXNjdXNzaW9uDQogcG9pbnRzIHdpbGwgYmUgZG9j dW1lbnRlZCBpbiB0aGUgV0cgZG9jdW1lbnQgYW5kIG1haW50YWluZWQgYnkgdGhlIGRvY3VtZW50 IGVkaXRvciBpbiBjb25qdW5jdGlvbiB3aXRoIHRoZSBjaGFpcnMuDQo8bzpwPjwvbzpwPjwvbGk+ PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1s aXN0OmwxIGxldmVsMSBsZm8zIj5JZiB0aGlzIGRvY3VtZW50IGlzIGFkb3B0ZWQgYnkgdGhlIHdv cmtpbmcgZ3JvdXAsIHRoZSBjaGFpcnMgc3BlY2lmeSBhcyBwYXJ0IG9mIHRoZSBhZG9wdGlvbiBj YWxsIHRoYXQgdGhlIGZvbGxvd2luZyB0ZXh0IGRlc2NyaWJpbmcgYW4gb3BlbiBpc3N1ZSBiZSBh ZGRlZCB0byB0aGUgZG9jdW1lbnQgaW4gdGhlIGFib3ZlLWRlc2NyaWJlZA0KIG9wZW4gaXNzdWVz IHNlY3Rpb246PG86cD48L286cD48L2xpPjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9 ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZl bDIgbGZvMyI+JnF1b3Q7R2l2ZW4gdGhhdCB0aGUgd29ya2luZyBncm91cCBoYXMgc2FpZCB0aGF0 IGl0IHdhbnRzIHRvIHN0YW5kYXJkaXplIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uLCBhbmQgZ2l2 ZW4gdGhhdCB0aGUgZG9jdW1lbnQgY29udGFpbnMgbXVsdGlwbGUgU1J2NiBFbmRQb2ludCBiZWhh dmlvcnMgdGhhdCBzb21lIFdHIG1lbWJlcnMgaGF2ZSBzdGF0ZWQgYXJlDQogbXVsdGlwbGUgZGF0 YSBwbGFuZSBzb2x1dGlvbnMsIHRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYWRkcmVzcyB3aGV0aGVy IHRoaXMgaXMgdmFsaWQgYW5kIGNvaGVyZW50IHdpdGggaXRzIG9uZSBkYXRhIHBsYW5lIHNvbHV0 aW9uIG9iamVjdGl2ZS4mcXVvdDsuPG86cD48L286cD48L2xpPjwvdWw+DQo8L29sPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5QbGVhc2UgY29uc2lkZXIgdGhlIGFib3ZlIGd1aWRlbGluZXMgYXMgeW91IGRlY2lkZSBvbiB3 aGV0aGVyIHRvIHN1cHBvcnQgb3Igbm90IHRoaXMgV0cgYWRvcHRpb24uIFBsZWFzZSBleHByZXNz IGNsZWFybHkgeW91ciByZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9uLXN1cHBvcnQgYXMgd2VsbCBh cyBhbnkgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyB5b3Ugd291bGQgbGlrZSBhZGRyZXNzZWQgc2hv dWxkIHRoZSBkb2N1bWVudA0KIGJlIGFkb3B0ZWQgaW50byB0aGUgd29ya2luZyBncm91cC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzITxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KaW0s IEJydW5vICZhbXA7IEpvZWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM5PR21MB05083DB0139F0433CC2AFA0ACAB79DM5PR21MB0508namp_-- From nobody Wed Oct 13 13:27:10 2021 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 B66663A0DD8; Wed, 13 Oct 2021 13:27:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzdzkKfr-n68; Wed, 13 Oct 2021 13:27:00 -0700 (PDT) Received: from mail-pl1-x62e.google.com (mail-pl1-x62e.google.com [IPv6:2607:f8b0:4864:20::62e]) (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 80E243A0DE7; Wed, 13 Oct 2021 13:26:55 -0700 (PDT) Received: by mail-pl1-x62e.google.com with SMTP id g5so2624413plg.1; Wed, 13 Oct 2021 13:26:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=PbwyFwXmkDLjCN5Ia72re7BPa+DeiMTCb4/NOvb8hUQ=; b=DzZDkTP/VF9V3zKiPsAzx4DdcH2aokqyDusMdKdxZBOZxKu4qDjYGn+eCdfGDhbOie RKYv6ZxbZ8Zc0s3li4oE6DRawnwDnuPAkGQRO7Chp+cN1Y03HUmLoWdVR4c47+Skmq7P HuwDc2gZYz9tgtqHLFcxr0cu5qQXI7UA6Ixz5A0cXgH9KkH/5PS3OrbsGBWQJJTAzcHS xj6bp5n6r2SBlbtk4KEeUYwwY/BPpueYLeIx716vaATybwhZEWtPEf3scUJqrceZvnU9 B5cw1hemVrrmIM3C0ttxl7DlNyHnHsAx4cOE7InfIJl/bbD7o/TSlzdhoaUfe4jHjKt7 nlcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PbwyFwXmkDLjCN5Ia72re7BPa+DeiMTCb4/NOvb8hUQ=; b=TEp+zhVcTCp6ABJ33Q5LJk9VU1KL+034kJ0VPAWBJmvfZXnKUu7gCQq9Y6rjbHN5EA h5NokwkKXQwh6SdHDPI+dVQYTM4lEnBBtgRdjNHKGhm2yl/ne9MGgHJzzhxLbf8LygTh nNBYl/kFFXBZbE/PWWfxFAmM+6ZWUsBXQ1KSgDhlVkMieFZSM/mx8N77eMN4iW5+B0Ki ZIcIeK0jTvFMOSuecISTma2RQRgftwHAOYaYtvw3oQvBpEsZ/TfHwRbv8zwSLK6BNJl9 xyL9mououlW6kYdXsyMCyfTo/Utc9thniSKgvD7HeP64qs9ykxDVExtEIvHQSFsARhDD RtZA== X-Gm-Message-State: AOAM5332mi5a9OPiuPb8eTNxzZWJh4jQsIoOS9xb02CWpi5OwMnOpTiA y4Ke9zlwaQgL2Qy/Z8qqfrX/Yl+MoGIqqA== X-Google-Smtp-Source: ABdhPJxDDoGAEBZ+HaHauTkvpuRcO0CqRQHlOAC3StSAcdgIxvdAEQMiPFIyiQgITo/qmKzyIpQj6A== X-Received: by 2002:a17:90b:fd0:: with SMTP id gd16mr1526515pjb.157.1634156813864; Wed, 13 Oct 2021 13:26:53 -0700 (PDT) Received: from ?IPv6:2406:e003:1018:b901:db7:d041:a2d:ce65? ([2406:e003:1018:b901:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id t14sm339158pga.62.2021.10.13.13.26.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 Oct 2021 13:26:53 -0700 (PDT) To: "Joel M. Halpern" , "ipv6@ietf.org" Cc: "spring@ietf.org" References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> From: Brian E Carpenter Message-ID: <1daf3d20-22b2-d111-5131-bd53f51c53a3@gmail.com> Date: Thu, 14 Oct 2021 09:26:49 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 13 Oct 2021 20:27:07 -0000 Joel, On 13-Oct-21 20:37, Joel M. Halpern wrote: >> 1) Does the placement of a list of sids in the IPv6 DA field change the >> IPv6 architectural description of that field. That's why I recently asked for a set of examples of the resulting "addresses". I don't understand enough of SRV6 to understand what the bit patterns in such addresses will actually be. And I don't care about the details of SRV6, given that it will only be used in certain special types of network. So I can only answer your question based on concrete examples. Are they compatible with RFC4291 or not? (There's a subsidiary question which IMHO is in some ways more important than the architectural question: what existing code and devices will such addresses break?) >> 2) Does the operation of shifting information around in the IPv6 >> destination address field represent a modification or extension of the >> IPv6 data plane. Including semantics *of any kind* in an IP address is a very fundamental change to the concept of IP. I may be wrong, but I'm not aware that any RFCs prior to SRV6 have done this, and the founding reference for what an address *is* still seems to be IEN19 [1]. So I'm not concerned that srv6-srh-compression has any more fundamental impact than basic SRV6 or RFC8986. (However, this aspect of SRV6 was one of my primary motivations for RFC8799. What happens in SRV6 stays in SRV6.) [1] https://www.rfc-editor.org/ien/ien19.txt) Regards Brian From nobody Wed Oct 13 14:33:22 2021 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 66E8B3A0D50; Wed, 13 Oct 2021 14:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBsT6UDKaR-M; Wed, 13 Oct 2021 14:33:11 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF8B3A0CCC; Wed, 13 Oct 2021 14:33:11 -0700 (PDT) Received: from dooku.sandelman.ca (cpe788a207f397a-cmbc4dfb96bb50.sdns.net.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id E57A81F45A; Wed, 13 Oct 2021 21:33:09 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 8C0DC1A0524; Wed, 13 Oct 2021 17:33:08 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter , "Joel M. Halpern" , "ipv6\@ietf.org" , "spring\@ietf.org" In-reply-to: <1daf3d20-22b2-d111-5131-bd53f51c53a3@gmail.com> References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <1daf3d20-22b2-d111-5131-bd53f51c53a3@gmail.com> Comments: In-reply-to Brian E Carpenter message dated "Thu, 14 Oct 2021 09:26:49 +1300." X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Wed, 13 Oct 2021 17:33:08 -0400 Message-ID: <113586.1634160788@dooku> Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 13 Oct 2021 21:33:17 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: > So I'm not concerned that srv6-srh-compression has any more fundamental > impact than basic SRV6 or RFC8986. (However, this aspect of SRV6 was > one of my primary motivations for RFC8799. What happens in SRV6 stays > in SRV6.) You said it better than I. {Now, if a router wanted to announce it's SRV6-ness, and would it want to do that in an RA, would it want to use the universal RA option to do so?} -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAmFnUJQACgkQlUzhVv38 QpDFuwf+N+HHjvCf+Mnu+3xhDlp/NU7IOnJmfB8/dtrUgcxuz+3FbK7sbXWNc+Bi KqQlMu4lo94WuRPr8pA1i8p4oMXHBVZRUp7xWQWhXpPnIq0BgeQMLfeNAIYVqr5y /nPOz8tEK5CqjqaXGC6N03mZ23QBdBCNi1hClgc72ea2/g0QL4N8SkPgqszAXI0d lWlb8+H6gBk5tnuvHGsAy4XVXKmEnMUoN/hHqAxiiUIy9v/rPuZbhvwtnYaI26qC +P22ZA1d77tCVd6/77v0nL9ghnlpmTW3wcz5PmqN47ttB1SRKdQQ48qPhmGQyJH+ OIYwszf6kITmCz/VPxiy+1LZgXo4Zw== =BxhH -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Oct 13 15:28:53 2021 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 ABB533A1262; Wed, 13 Oct 2021 15:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=yunhi6GP; dkim=pass (1024-bit key) header.d=juniper.net header.b=YI8XPr1F 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 Y7lZkz6gDvAb; Wed, 13 Oct 2021 15:28:47 -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 AD57F3A1261; Wed, 13 Oct 2021 15:28:46 -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 SMTP id 19DIBd2B000905; Wed, 13 Oct 2021 15:28:45 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=CoMxaRzng4vvKTivX+81MSLvA94t7GZuk2OihH81JOU=; b=yunhi6GPv5fx/LruQOzyZEIX7QxrpWRi3FIHm/jTmvubJAUbnhXOVNefwHh+dHUIlQW5 hyKPMTEGuhPVrPHVetU+1FUx3xfKxSq3RMKVy/DI01wgQd5KlbUHxqw4rwMO0ynQEUfg dG59uP4fM1TYBK14WKP5j3bbD0q0PeILRN5S5fN9VpQYrUo9qWTGlFPs5N75Np/XwEhb rVqer5NUgGLByxwnvCZkGl3tKlfZuGlhuu6QxaedBBc0nklJxiRoqawxQJddF6WlWVia 29yyB3MX3dXnPHwvXCnBAuSQ/sLfzcB6zTs40Pu3RJvxaQFzMzjp0vYNytFwdiGTCrOm 7w== Received: from nam10-dm6-obe.outbound.protection.outlook.com (mail-dm6nam10lp2102.outbound.protection.outlook.com [104.47.58.102]) by mx0b-00273201.pphosted.com with ESMTP id 3bnvn6hyg5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Oct 2021 15:28:45 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Fxhzby8k+i+997pMRSvGfFIMGFN/HUdd49YzL0GQULeexq8AZvnVIZkKS/8fESgu3xMIbQbJrhSXc3uPmXJW/uVZQvq60pqSUCXsuZ1p8GkK8AGCAfR17EzNffd0kf1Le8YG5jNdb0bOXVu/Vhe5DUl7KRwZBfF4rnByCUKjj6nlauwA5bG1mT/eXLy1l9ZPzeAtSzwdK1U/AtPf4gwXuouHdyJQ5pemF1bwUxLnuuXhWh5htOrU5ceOH/M2lpKaerB7RTkG4WXeaU8pRq946ltM84R8bKy099tQJCY9TZjL3wYtXIuEJai4285M1QUCnckl35o/H3gXc3emA/frog== 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=CoMxaRzng4vvKTivX+81MSLvA94t7GZuk2OihH81JOU=; b=Oap86nwMjIhPmzimOev5nYb8eQF8qPzztUsbFmrAio0pw5098CHUzB8aUq+qOs5T4Tx+ZIV8YRPpzS52/AnAhrw6+pirIqcSOqsRy3IBVyz/xZPEu8Qw+UT5e+o3tWSmIJua3C9CamsCmg6u6j45B5ovqr6CsJLFdTWZV7N5irehBFG/0cRB8FujcceJycIu1otfnbMgAdOqbWcgA0Shz+HgibUPgT5WQAfK2ly2fvlbFDbD/Wvo3nwFMT0S7vbELNPZEOTwCJXLQDVb8IOR9aetxgcInC1wjcHQ8SEvGgFq4Eb7akMcbTFjstVCoB3kFUUIBhuUj5HSGwZ5QWDAnQ== 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=CoMxaRzng4vvKTivX+81MSLvA94t7GZuk2OihH81JOU=; b=YI8XPr1FRC8lu5CHX5/NqgryYGg3k3HYkGNi3f5BVw2OJqp24uXbvKznKQ3pxsvRZ5jSIt+Ca1YYAOSPZjHn3ZNSo/kOqfI1n4NWLRpL7YW0YDPteUnKVAJTmjBmkyl+RS48r2z4PpzR+5RtvqqoibXSSUOuqED2eFZsar4LBL8= Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by MN2PR05MB6160.namprd05.prod.outlook.com (2603:10b6:208:c4::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.13; Wed, 13 Oct 2021 22:28:43 +0000 Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::10b9:2bb9:11f2:6b4a]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::10b9:2bb9:11f2:6b4a%3]) with mapi id 15.20.4608.016; Wed, 13 Oct 2021 22:28:43 +0000 From: John Scudder To: "draft-filsfilscheng-spring-srv6-srh-compression@ietf.org" , "spring@ietf.org" Thread-Topic: "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 Thread-Index: AQHXwIGtGfUetDOXlk+YPM+Rvcp8kw== Date: Wed, 13 Oct 2021 22:28:42 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.120.0.1.13) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9b9732db-fe59-4015-918b-08d98e98d055 x-ms-traffictypediagnostic: MN2PR05MB6160: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: JBpJF/Razz6ZF9qce17IFuCkY6vrCfNTNxHaX0+6hxjHrJlE4TD8PIX1stv5hA0+PrRac0uRP6L6HvryyHA8C/o5UMfU1ReTsQC3+YlcakajSwsmECpY2pPQQq62N27pWnofqdOHbSLswbOLmuaqebZEf12gEWeSau1VocPf1A1CY5MPT/CO4xA3quxhJzB4QJuExYz0ARcZFcy7EGSBTQkHPZCqqOGBMYAdeXx8yVKtDutrgJWqZGbh8YDA7xra/SC1byHUWwLvKSWO9txAM+2khzE/OQ1hLIb2FgE/Kl20Z88EzLACxntQ+b+xRloSonX2SScQsT69ZlOiDz9cQ9C5Gjzuslwd+y3FJQTt84UefCMpc5YNdeJ4zgNmrq0xPJx8912deTRxpXiLfcivQDlluWFhxmvnVSCX/l3yYxSTI9aSZQ06A5JplyftdEs8gNqHo7GqDDg6d/yA2tDx8e0oviWh1Ri6olnYJmKbFpdZC7NqJ6iZHS70aQWr6GQ3EEviVbA+mgoieQoITNX2qOx2JJ+p1o0orjuVhj4fXgg9SZUBgplLlN2noJnlJ2q9FTYHvxFE8xy+lxL8ivUdGnk1iEoqzmV84o8laOFjuLov47RQADOTzLhgTYGzDRPTwUJT3HC9Q2X8Nao4NWRkX9FQMZkG5GrwYsXqBKUkBMTzWsUvCFIpqAnvb0+fCYfAWhccMopHbDni33+ZdTyOQ0TZnL7uYGI05T12UhXib8TLifJTumBPgZK3HTvhJSgY 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:(4636009)(366004)(5660300002)(316002)(33656002)(186003)(6506007)(86362001)(508600001)(6512007)(450100002)(6486002)(36756003)(122000001)(110136005)(2906002)(2616005)(8936002)(64756008)(8676002)(91956017)(38100700002)(66556008)(66446008)(76116006)(66476007)(38070700005)(71200400001)(83380400001)(66574015)(66946007)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?a2tUTVh5RXg2RWoxTTVoeWJGSytESEJLYmtpeWYzOGg3YzhDZUN6TktDRDJs?= =?utf-8?B?TEZvWW1jamI5bWR5ZHErdXk4OHhNcUQvNlp2cWJpSktTWnNYSmVIV3dGa0Zz?= =?utf-8?B?eFRUbXgzYUFiQ2hxWWNYVDE4cEtzUUVyNDVOUUpXT2IzU1dpTmxEcVBRelQ2?= =?utf-8?B?STd6L3ZVZlVWa1NaVmNNNUlmckU3bU9NYkZsbzJnL3p3MjRwU09GYkJMQUpr?= =?utf-8?B?SzUySnZqc2VFUEVkMHVqa1ZrOFFYV3Q5M1dCTG83WWdmK3JSRCtTcWNnTlN4?= =?utf-8?B?VWFZRjk5OG5mL3RYcmttdDNHYkhGTHo2YzBaUXpub0xVazE1a2FaKzZ4enNV?= =?utf-8?B?aUdsMFhINllzbVV2STBYdWx4Y3UvQUEvSDRWd0Fkc2JKb2VndlFTYmxuVjZl?= =?utf-8?B?UkdOVHFCWkNqNmpmYkN3Mlk0SXBTeGxmSFVBMXl2K0h6OG1UOGRrWVdDVnFp?= =?utf-8?B?SUJOMG1QRThBNnJrMXNIY1VsOGpnamt5d0Zkck4yZlVUUnRJU0xnd1lYY09x?= =?utf-8?B?aWVqVXR1WEpuQjhPd2xMbTNDMjR0SGU2MW01b0VTcEFBNHNldUt2ang4RXJV?= =?utf-8?B?RDQ5VXNvbFZDcVNNcnhSK0xhMUZWejhhZEIzZmkrTGI5NnRvS01QOVBKaDFY?= =?utf-8?B?amxvMGRMRDZSb0J0OEZJMEZPL2xaUUNocTJYQjI2aGQwZTlOMXp6cTRRWW12?= =?utf-8?B?TjFxcDMxcnlRZzYyc3U0T2F6WE80TzEwTC9xb3R3bXdialdzNnpxUDRybVJx?= =?utf-8?B?VmlDNVo2NVU5T2NUbmIyclRmSzVuT2xQRHhwdmxhT09ZOEZkWHl2eWo1d3JC?= =?utf-8?B?eFg5MmZmRzFyOFk5L3U2N1NHbm9aUnRrZFlHdUlod1NnZTdwY1lrcmppWTc0?= =?utf-8?B?cXpRVHNQYk9iTC92cENseTlOWHc1am5HVVJEZE9PaWduamtIMDRmSnlkN0x5?= =?utf-8?B?dCtucnFpSW1nalo0dTRoWnhxeTNRb1pXS2xwai9OZngzalVHbCt5bGs2cW5v?= =?utf-8?B?WDdOVzl6TTgxSkZDcGJGMDI5eitjaHEwaENhQlI1d2tPaGJjWVVCRDg5MTdX?= =?utf-8?B?N1gwL080eFlWTTlQaTM5NDFmS3o4aTFtYWpoMVc3YmhYbUtsZGR2SytDQmRW?= =?utf-8?B?ZVkzblhBU0JBWjhrOUFvdHljSWdyaUZSKy9hZCtBcU5BZlYwK1pxT3ZDeHlx?= =?utf-8?B?b0E3YUEwZytmeWgyUzhkbXdZQVJ4WS9xZTBqdWc3NWd2ZmdHNkJxMWoyc0or?= =?utf-8?B?QlQvV0tOR3lmNnZWYS9wb080RlFWd2gvbHo4SmlvanFmWDNRdExEazJvVzZh?= =?utf-8?B?Rlh0YjVVR2VrREZQSTg3ZGFKdExPaGMwRUhwcFJFSHYwRFowREFQVzFQMk91?= =?utf-8?B?MWxVWmJ3QVhYSHk1Q0dPT3FZekVvMDhVSmdCbU5VTlJzRGVka2M4N21NT0hD?= =?utf-8?B?K2pPd21oM09OdWRBdW1iRHZLbzk5SjYyVUFmZzlWd1hEOTdLQ3dkRHN1S3Yz?= =?utf-8?B?RUJVQmZyS0ZZTC9tclVnRHZVZVpJRGZ3Q0VvdGxKZm00VTM5SUpkaHNqd2JD?= =?utf-8?B?UWRBUWJFdHVwbDF5c3NxZ1ZNajhtd0RCb1F6U2xrS3B2dndid0d2YlozZWhD?= =?utf-8?B?OUFFUzJaN0kzRU4rNTM0c0Y5YjFheE5pY1ZxWlRNQTBPaVVYY0JxV2hzRjB3?= =?utf-8?B?UjM0WXZIUXNsNCs3Y2JUS3RZRDBudUVLTmlUMWk1c3pzc2ZFSUQ5WnRNZGdz?= =?utf-8?B?MUs0RW5MN2tQVzdtN0dDZHZYckRtNFNVOTg2YmpjTXBtZDJzeGEra2tZUVpk?= =?utf-8?Q?FDmy47DVWnpcYA9GryFQ6JbCzcD9Uib1c2Rt4=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <0F9092402642154B8633BEF9315FB09A@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: 9b9732db-fe59-4015-918b-08d98e98d055 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2021 22:28:42.8669 (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: jU5kKEIf8giUKC88+RZTD3svu8DBxRj1GdNgR1SBFybYK2pNED/jmUqm5jbwSu3H X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6160 X-Proofpoint-GUID: AWvtpnAOC_yJFMV7J5Rmd4hfeJiswhNm X-Proofpoint-ORIG-GUID: AWvtpnAOC_yJFMV7J5Rmd4hfeJiswhNm X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-13_08,2021-10-13_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 clxscore=1011 adultscore=0 phishscore=0 mlxlogscore=772 impostorscore=0 suspectscore=0 spamscore=0 bulkscore=0 mlxscore=0 malwarescore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110130135 Archived-At: Subject: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 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, 13 Oct 2021 22:28:52 -0000 SGkgRm9sa3MsDQoNCknigJltIHN0cnVnZ2xpbmcgd2l0aCB0aGUgY2xhaW0gcmVwZWF0ZWQgdGhy b3VnaG91dCB0aGUgYmVnaW5uaW5nIG9mIGRyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYt c3JoLWNvbXByZXNzaW9uLTAyIChBYnN0cmFjdCwgwqcxLCDCpzMpIHRoYXQg4oCcdGhpcyBzb2x1 dGlvbiBkb2VzIG5vdCByZXF1aXJlIGFueSBTUkggZGF0YSBwbGFuZSBjaGFuZ2XigJ0uDQoNCkni gJltIG5vdCBhd2FyZSBvZiBhIHN0YW5kYXJkaXplZCBmb3JtYWwgZGVmaW5pdGlvbiBvZiDigJxk YXRhIHBsYW5l4oCdLCBpdCBzZWVtcyB0byBmb2xsb3cgSnVzdGljZSBTdGV3YXJ04oCZcyBtYXhp bSBvZiDigJxJIGtub3cgaXQgd2hlbiBJIHNlZSBpdOKAnS4gSG93ZXZlciwgaGVyZeKAmXMgYW4g YXR0ZW1wdCwgY3JpYmJlZCBmcm9tIHNvbWUgV2FzaGluZ3RvbiBVbml2ZXJzaXR5IGNvdXJzZSBz bGlkZXM6IGEg4oCcbG9jYWwsIHBlci1yb3V0ZXIgZnVuY3Rpb24gdGhhdCBkZXRlcm1pbmVzIGhv dyBhIGRhdGFncmFtIGFycml2aW5nIG9uIGEgcm91dGVyIGlucHV0IHBvcnQgaXMgZm9yd2FyZGVk IHRvIGEgcm91dGVyIG91dHB1dCBwb3J04oCdLiBTZWVtcyByZWFzb25hYmxlLg0KDQpJIGFsc28g YW0gbm90IGF3YXJlIG9mIGEgc3RhbmRhcmRpemVkIGZvcm1hbCBkZWZpbml0aW9uIG9mIHRoZSB0 ZXJtIOKAnFNSSCBkYXRhIHBsYW5l4oCdLCBpbiBmYWN0IHRoaXMgZHJhZnQsIGl0cyBwcmVkZWNl c3NvcnMsIHNvbWUgYXNzb2NpYXRlZCBibG9nIHBvc3RzLCBhbmQgQ2xhcmVuY2XigJlzIGRpc3Nl cnRhdGlvbiwgYXJlIHRoZSBvbmx5IHBsYWNlcyBhIHNlYXJjaCBmaW5kcyB0aGUgcGhyYXNlIChi dXQgaXTigJlzIG5vdCBmb3JtYWxseSBkZWZpbmVkIGluIGFueSBvZiB0aGVtKS4gU28gSeKAmW0g anVzdCBnb2luZyB0byBhc3N1bWUgaXQgbWVhbnMgdGhlIGRhdGEgcGxhbmUsIGFzIGFwcGxpZWQg dG8gcGFja2V0cyB0aGF0IGluY2x1ZGUgYW4gU1JILiAoSeKAmW0gbm90IHN1cmUgd2h5IHdlIHNo b3VsZCBkaXNyZWdhcmQgcGFja2V0cyB0aGF0IGFyZSBlbmNvZGVkIHVzaW5nIE5FWFQtQy1TSUQg dGhhdCBvbWl0IHRoZSBTUkgsIGJ1dCBsZXTigJlzIG92ZXJsb29rIHRoYXQgZm9yIG5vdy4pDQoN CklmIHRoaXMgc29sdXRpb24gZG9lcyBub3QgcmVxdWlyZSBhbnkgU1JIIGRhdGEgcGxhbmUgY2hh bmdlLCBwcmVzdW1hYmx5IGl0IHdvdWxkIGJlIHRydWUgdGhhdCBpZiBJIHRha2UgYSBwYWNrZXQg dGhhdCBpbmNsdWRlcyBhbiBTUkggYW5kIHBsYWNlIHdpdGhpbiBpdCBhIHNlcmllcyBvZiBTSURz IGVuY29kZWQgd2l0aCAoZm9yIGV4YW1wbGUpIHRoZSBSRVBMQUNFLUMtU0lEIGZsYXZvciwgdGhl biB0aGF0IHBhY2tldCB3b3VsZCBiZSBhYmxlIHRvIHN1Y2Nlc3NmdWxseSB0cmF2ZXJzZSBhIG5l dHdvcmsgb2Ygcm91dGVycyB0aGF0IHN1cHBvcnQgcGxhaW4gdmFuaWxsYSBSRkMgODc1NC4gVGhh dCBpcywgaXQgd291bGQgYXJyaXZlIGF0IGl0cyBmaXJzdCBob3Agcm91dGVyIHdoaWNoIGFjY29y ZGluZyB0byBhIGxvY2FsLCBwZXItcm91dGVyIGZ1bmN0aW9uLCB3b3VsZCBkZXRlcm1pbmUgaG93 IHRvIHRha2UgdGhlIGRhdGFncmFtIGFycml2aW5nIG9uIHRoZSByb3V0ZXIgaW5wdXQgcG9ydCBh bmQgZm9yd2FyZCBpdCB0byAodGhlIGNvcnJlY3QpIHJvdXRlciBvdXRwdXQgcG9ydC4gVGhlbiB0 aGF0IHByb2Nlc3Mgd291bGQgYmUgcmVwZWF0ZWQgYWNyb3NzIHRoZSByZXN0IG9mIHRoZSBuZXR3 b3JrLg0KDQpCdXQgdGhhdCBpcyBwYXRlbnRseSBpbmNvcnJlY3Q6IHdoZW4gaXTigJlzIGRlbGl2 ZXJlZCB0byB0aGUgZmlyc3QgaG9wLCB0aGUgcGxhaW4gdmFuaWxsYSBSRkMgODc1NCByb3V0ZXIg d2lsbCBiZSB1bmFibGUgdG8gYXBwbHkgdGhlIFJFUExBQ0UtQy1TSUQgYmVoYXZpb3IsIGFuZCBm b3J3YXJkaW5nIHRvIHRoZSBuZXh0IGhvcCB3aWxsIGZhaWwuIEl0IHNlZW1zIHRoYXQgYSBkaWZm ZXJlbnQgbG9jYWwsIHBlci1yb3V0ZXIgZnVuY3Rpb24gaXMgcmVxdWlyZWQgKGluIGZhY3QsIHRo ZSBsb2NhbCwgcGVyLXJvdXRlciBmdW5jdGlvbiBkZWZpbmVkIGluIHRoZSBkcmFmdCkgaW4gb3Jk ZXIgZm9yIHRoZSBmb3J3YXJkaW5nIHRvIHN1Y2NlZWQuIEJ5IHRoZSBkZWZpbml0aW9ucyBJ4oCZ bSB1c2luZyBoZXJlLCB0aGF0IGlzIGV4YWN0bHkgYSBkYXRhIHBsYW5lIGNoYW5nZS4NCg0KV2hh dCwgcHJlY2lzZWx5LCBpcyB0aGVuIGJlaW5nIGNsYWltZWQ/DQoNClRoYW5rcywNCg0K4oCUSm9o bg== From nobody Wed Oct 13 15:57:55 2021 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 D0D143A1349 for ; Wed, 13 Oct 2021 15:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 pQ8kYqAhC7Ys for ; Wed, 13 Oct 2021 15:57:48 -0700 (PDT) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 30B4D3A134C for ; Wed, 13 Oct 2021 15:57:48 -0700 (PDT) Received: by mail-ua1-x935.google.com with SMTP id e7so7722178ual.11 for ; Wed, 13 Oct 2021 15:57:48 -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=VBYOgq/Omigw7cWleg6VMYtima2SsHAukxwVa34uKUs=; b=YbUQh7QHcNG9z63sEjVnorbME8ZsEaUDAA9p6XPc/efo/AebgdrB3xvCtyUxUM1Y/r KkM5LBS3VFba8QRXYh54lfQVGeqhxmCWjgpLjEvTlc2kfnMobCBtJFPaD3cUhg/v+GG1 I3OikWPzRLH0VZwR4PCBAVwCAV7n29TSuzF4DP2F08B6P1WteGwJ1tltZf9jgFM3lO2Z SKbWzPg/hut3ZWIq64Hgr5yjzUnkO/Fc3H1ChVkkgBxaVwLuWVZwdlHqg758SDwP+gCK wy6zU4wfl1pUDxrp3N75RYUvr5QGwP4IYVXe+n0ZLZC+WCHb95jcLAruVQLSqmc1ZagL syyw== 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=VBYOgq/Omigw7cWleg6VMYtima2SsHAukxwVa34uKUs=; b=XL4l84YSrGAH0mnC+TToXreja5W66Lv8ZSX5e2B6lpBaF3wkbmgqh+vlG+YMz/9mJ5 t4yNCmYmi71cmmueCCrIAKwbZsAVC24m2S0VeEUNIUxVReF6yO2dh8GV4dL451aWbD2r /pX6Cl07IkwGGUtBHDNe4jHCHjajs1E/g2Mn6xTMQ+LX9z3DnA5dxaL5918jzNDLJxvQ gqFIaCiRA7itGoxF+izK5Kmf6zdgXBuhrzwxr6+JEibqh1k/XH/qjA4I3K9yr4Ldq83K kms3hPucMGRY5kGzWCnvDEhx+PW8uNLCMB8vsM2JBJz0A/jMBbRbkfW8ozIj4LL1cYET +rHA== X-Gm-Message-State: AOAM531cVQk0ULoR/HZNhaScHBxRRcwhHlVWeIa+XQ1vM3kDEH228QK3 LdeHlq6VvT8zbn+4/ACHJVPotCivYKk+BHXGY88Uog== X-Google-Smtp-Source: ABdhPJxNhtxW91AUaCI4QqSXnnnZ1mLXptsCUt91KgpOlWlrMEAHu/1g/zWWtvQT0moqCfDKmT5exvFY0OJRDFFP1TE= X-Received: by 2002:ab0:45c4:: with SMTP id u62mr2485951uau.69.1634165866241; Wed, 13 Oct 2021 15:57:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Thu, 14 Oct 2021 00:57:49 +0200 Message-ID: To: John Scudder Cc: "draft-filsfilscheng-spring-srv6-srh-compression@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f62f1a05ce43e3d9" Archived-At: Subject: Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 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, 13 Oct 2021 22:57:53 -0000 --000000000000f62f1a05ce43e3d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi John, I think the crux of the matter is indeed in definition of "SRH data plane". So let me present my own personal understanding of it. Clearly SRH external format does not change so hardware's ability to read SRH remains intact. IPv6 packet's header also can be read and processed by network elements which have no idea about cSIDs so that as well is not questionable. Now your definition of data plane is sound if you consider traditional data planes of network elements when control plane input set's forwarding behaviour. Well in SRH as you know we have SIDs which inside may contain functions. So forwarding behavior is not pre programmed from control plane, but can and often is embedded in the actual packets. That is what real network programming is all about. And each function can have zoo of also nested arguments all resulting in different forwarding outcome. With such definition of SRH data plane I do not see anything new in adding few new flavours to existing behaviours or even adding new behaviours. Now the question is do we all see SRH data plane in the same way. Maybe it is way ahead of our times and classic ASIC design ? And I am in no way judging here if this is good or bad - I am just observing the facts and already published RFCs. Many thx, Robert PS. And I do agree with your inline comment that cSIDs should be possible to be used without SRH if no special functions are needed at each segment endpoint. On Thu, Oct 14, 2021 at 12:28 AM John Scudder wrote: > Hi Folks, > > I=E2=80=99m struggling with the claim repeated throughout the beginning o= f > draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, =C2=A71, = =C2=A73) that > =E2=80=9Cthis solution does not require any SRH data plane change=E2=80= =9D. > > I=E2=80=99m not aware of a standardized formal definition of =E2=80=9Cdat= a plane=E2=80=9D, it > seems to follow Justice Stewart=E2=80=99s maxim of =E2=80=9CI know it whe= n I see it=E2=80=9D. > However, here=E2=80=99s an attempt, cribbed from some Washington Universi= ty course > slides: a =E2=80=9Clocal, per-router function that determines how a datag= ram > arriving on a router input port is forwarded to a router output port=E2= =80=9D. > Seems reasonable. > > I also am not aware of a standardized formal definition of the term =E2= =80=9CSRH > data plane=E2=80=9D, in fact this draft, its predecessors, some associate= d blog > posts, and Clarence=E2=80=99s dissertation, are the only places a search = finds the > phrase (but it=E2=80=99s not formally defined in any of them). So I=E2=80= =99m just going to > assume it means the data plane, as applied to packets that include an SRH= . > (I=E2=80=99m not sure why we should disregard packets that are encoded us= ing > NEXT-C-SID that omit the SRH, but let=E2=80=99s overlook that for now.) > > If this solution does not require any SRH data plane change, presumably i= t > would be true that if I take a packet that includes an SRH and place with= in > it a series of SIDs encoded with (for example) the REPLACE-C-SID flavor, > then that packet would be able to successfully traverse a network of > routers that support plain vanilla RFC 8754. That is, it would arrive at > its first hop router which according to a local, per-router function, wou= ld > determine how to take the datagram arriving on the router input port and > forward it to (the correct) router output port. Then that process would b= e > repeated across the rest of the network. > > But that is patently incorrect: when it=E2=80=99s delivered to the first = hop, the > plain vanilla RFC 8754 router will be unable to apply the REPLACE-C-SID > behavior, and forwarding to the next hop will fail. It seems that a > different local, per-router function is required (in fact, the local, > per-router function defined in the draft) in order for the forwarding to > succeed. By the definitions I=E2=80=99m using here, that is exactly a dat= a plane > change. > > What, precisely, is then being claimed? > > Thanks, > > =E2=80=94John --000000000000f62f1a05ce43e3d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi John,

    I think the crux of the matter= is indeed in definition of "SRH data plane". So let me present m= y own personal understanding of it.=C2=A0

    Clearly = SRH external format does not change so hardware's ability to read SRH r= emains intact. IPv6 packet's header also can be read and processed by n= etwork elements which have no idea about cSIDs so that as well is not quest= ionable.=C2=A0

    Now your definition of data plane i= s sound if you consider traditional data planes=C2=A0of network elements wh= en control plane input set's forwarding behaviour.=C2=A0

    =
    Well in SRH as you know we have SIDs which inside may contain fu= nctions. So forwarding behavior is not pre programmed from control plane, b= ut can and often is embedded in the actual packets. That is what real netwo= rk programming is all about. And each function=C2=A0can have zoo of also ne= sted arguments all resulting in different forwarding outcome.=C2=A0

    With such definition of SRH data plane I do not see anyth= ing new in adding few new flavours to existing behaviours or even adding ne= w behaviours.=C2=A0

    Now the question is do we all = see SRH data plane in the same way. Maybe it is way ahead of our times and = classic ASIC design ? And I am in no way judging=C2=A0here if this is good = or bad - I am just observing the facts and already published=C2=A0RFCs.=C2= =A0

    Many thx,
    Robert

    PS. And I do agree with your=C2=A0inline comment that cSIDs should be= possible to be used without SRH if no=C2=A0special=C2=A0functions are need= ed=C2=A0at each segment endpoint.=C2=A0

    On Thu, Oct 14, 2021 at 12:28 = AM John Scudder <jgs@juniper.net&= gt; wrote:
    Hi Fo= lks,

    I=E2=80=99m struggling with the claim repeated throughout the beginning of = draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, =C2=A71, =C2= =A73) that =E2=80=9Cthis solution does not require any SRH data plane chang= e=E2=80=9D.

    I=E2=80=99m not aware of a standardized formal definition of =E2=80=9Cdata = plane=E2=80=9D, it seems to follow Justice Stewart=E2=80=99s maxim of =E2= =80=9CI know it when I see it=E2=80=9D. However, here=E2=80=99s an attempt,= cribbed from some Washington University course slides: a =E2=80=9Clocal, p= er-router function that determines how a datagram arriving on a router inpu= t port is forwarded to a router output port=E2=80=9D. Seems reasonable.

    I also am not aware of a standardized formal definition of the term =E2=80= =9CSRH data plane=E2=80=9D, in fact this draft, its predecessors, some asso= ciated blog posts, and Clarence=E2=80=99s dissertation, are the only places= a search finds the phrase (but it=E2=80=99s not formally defined in any of= them). So I=E2=80=99m just going to assume it means the data plane, as app= lied to packets that include an SRH. (I=E2=80=99m not sure why we should di= sregard packets that are encoded using NEXT-C-SID that omit the SRH, but le= t=E2=80=99s overlook that for now.)

    If this solution does not require any SRH data plane change, presumably it = would be true that if I take a packet that includes an SRH and place within= it a series of SIDs encoded with (for example) the REPLACE-C-SID flavor, t= hen that packet would be able to successfully traverse a network of routers= that support plain vanilla RFC 8754. That is, it would arrive at its first= hop router which according to a local, per-router function, would determin= e how to take the datagram arriving on the router input port and forward it= to (the correct) router output port. Then that process would be repeated a= cross the rest of the network.

    But that is patently incorrect: when it=E2=80=99s delivered to the first ho= p, the plain vanilla RFC 8754 router will be unable to apply the REPLACE-C-= SID behavior, and forwarding to the next hop will fail. It seems that a dif= ferent local, per-router function is required (in fact, the local, per-rout= er function defined in the draft) in order for the forwarding to succeed. B= y the definitions I=E2=80=99m using here, that is exactly a data plane chan= ge.

    What, precisely, is then being claimed?

    Thanks,

    =E2=80=94John
    --000000000000f62f1a05ce43e3d9-- From nobody Wed Oct 13 16:25:10 2021 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 159F63A141E; Wed, 13 Oct 2021 16:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=Es7s2Fow; dkim=pass (1024-bit key) header.d=juniper.net header.b=h0onNPTR 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 nNkI8DGKRYu5; Wed, 13 Oct 2021 16:25:02 -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 D220E3A141A; Wed, 13 Oct 2021 16:25:01 -0700 (PDT) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19DLUBf3029070; Wed, 13 Oct 2021 16:25:00 -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=B7/eAjb3q4C1tY4JKJB/+Kr8MK8vSXvydB15t4Ae+9o=; b=Es7s2Fow4rgtgFF8hY6MTTel0Vn4RGaii1yZ0OurTeRS55ZNrKhMDMjSzesXbAwaFyRk wdT+4hfQtdwljokcQTeDX8bUBM2gKDS7z63YKzMoOxuR2CxCf9Y0qTdB4LgWHB85Ss3C yoFmZpwgv/bCz51JG+IXhQZd3s5dZhmlw2cQuukXTSMyIij1hfrsWDids2+2LdXPZYcS ROHVpocFOy0R8blNXStVwzXYKbyzF2rRH9ZeQq0KeoVGrCyvc/7gEkwSNwEITloueC9D 3zK1zuF10HKzxQNV8Z+y7r0pdG2G2OCJRN7xWIAkSW7RfoQOOIP00Ka6/kYkV6PkchJs nQ== Received: from nam11-dm6-obe.outbound.protection.outlook.com (mail-dm6nam11lp2174.outbound.protection.outlook.com [104.47.57.174]) by mx0b-00273201.pphosted.com with ESMTP id 3bp7e706y2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 13 Oct 2021 16:25:00 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jz30l1/wns+UNhuSvpXt0jXHKS6ZUBeu93qe6KOQyTJtVrZQkm+eMcN4qPQpjxeRomeWK7E3szrgx9xyQa9qNe0gcMziVT1r3Y0HNt+lnqkpSHavF1aX+aNEaR5xwDlkZf60ipNrbGmVJ4JE8g+EDbNrz8UKzdOf+KSWYpdyuU36FeslyVYES/GlkASNcuwFBJ8QcgQls9IOSfTYYZo5r/sIOUHC+ssU287lxzxMZnLOGO0T7u069g8H5BgYSdJ2H9JOzdMCK2X0vI5ESjriXs30bdQeZxX26h6sjuXq+6WG0by6M0+R1QwMGYLecUIC427Ik2JW/i8jWV1sGxuSaA== 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=B7/eAjb3q4C1tY4JKJB/+Kr8MK8vSXvydB15t4Ae+9o=; b=SLJ4KOqK7SiGKPaAw7oAPOipbGgIzfu7TynZYzb+AVZscTurk5Lz/qgsxF/eIA806KEpn+cbLFWh+ynQttwMI0vYCiczFzBV4pnL11cTsw+ugvKqmy8Y/6mvzEwmWyBMPb2a9HTLWPwrMeyFItuBX+n7s5LfiieMNhkFpVLzkGF2WRpJoQxBI3c1q8cz2ySmOXzKwGKbJaJW/AGvMvmgTV2GOaIMyOp73xhBUMdF0ihJgo3R6cKBp4AXeaPhYUOfYbnvq12CzCArM6OmPzZsZK/QzlWy+o8WwSEZCr1mfwaTOrbEbFcmer47Q4mNQs0lo/m0Zse+GKOwJ3Zd6qTnPg== 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=B7/eAjb3q4C1tY4JKJB/+Kr8MK8vSXvydB15t4Ae+9o=; b=h0onNPTRE7Ph/XlA67HOGytLYzkocmL+/d7iLsrEiQIjH8QjJn/Jt2fvZib/mAbENBw4HM3fEruBVEZtJJRhnAn+LHanahdSssvQHHZJPcU5U8asoPTYgXyZWGyiSYPOLatdBKY1YnKJXlgOO/QZ204vuKHml6PehE+hpcd9enQ= Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by MN2PR05MB6592.namprd05.prod.outlook.com (2603:10b6:208:e1::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.13; Wed, 13 Oct 2021 23:24:58 +0000 Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::10b9:2bb9:11f2:6b4a]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::10b9:2bb9:11f2:6b4a%3]) with mapi id 15.20.4608.016; Wed, 13 Oct 2021 23:24:58 +0000 From: John Scudder To: Robert Raszuk CC: "draft-filsfilscheng-spring-srv6-srh-compression@ietf.org" , "spring@ietf.org" Thread-Topic: "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 Thread-Index: AQHXwIGtAQ5iI0HLYkm+pjy3rdbrTKvRinmAgAAHlYA= Date: Wed, 13 Oct 2021 23:24:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.120.0.1.13) authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1cde3962-a8c3-4eb0-9320-08d98ea0ac26 x-ms-traffictypediagnostic: MN2PR05MB6592: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: f1bx4Oia7zL7KOvxpD36rt0YNgY2I9q+dJ5YTUBZ9uOnT+GF4ERLGmD13Ago/zpQwvYMM1Jwpx6DT/TvisWYbZB5XmksXXyWglhRKibQsad+er2drf2uUpJS7VItZvEWGkjOYsDYR/PEjvP3XiZkhaR+qGdinRkemEdsSxrwGsGXXkPLOhTLVh5IEgQ4dkwWtvi9eC8eVcdgNq2qSqoDkkkfXcxALZg+FC0ncaZ3wSmSFOfRXk5CHDy72VVHjEj7m0ONFzW1wWrwKqaXEjKswMfT9UCqK0aQV++HLgqiL/NxfZCQ9zJcH545gVVYWiaKIJbNxjZdJNF3joXnuGAIlITruGIij6q3b6sJVhPPcZD9M9OiUrjNlcVNEuje4YhRF8mZ5ERO6kaZ6wRcxgB6KE8wdDrjD3gorq0C3B1Yu7ZSEsxdTLNlRsoV/OPsugs133CctgXBNVzr9rkICBCpwlYVxr4GNsRFNIENhe0RsiK6txqoCTV4bulzKbSLjwK2J6e6WnhgVpCQlTs3fR4ftQwjZfbLSNmXaD3EV2npYGsayubGGM2N24LnmmkL/nUwbKGXSle1Ek6cFICgd6vmTWa18q/v2+k86Ndeo05TvqdBb3UDyLRee8wkU30mvQKly+0Y9ftx7vZlo4so9/+TksReEe5p83u/YD5zSdtehE6Pu5vYW06H9vOdi3HvlgC/PtFv4QR4LRM6UPWthQxyMwHM0+Y8FDM3n+nqAArh9GICq/kQeSsnV5tP7e1L3NwUNl792UwtPt/6ZFP0jCAhveEVqErR5rENUpxRiAzYzYvz2bd3cMwE6VEA11phIOrI 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:(4636009)(366004)(66476007)(53546011)(6506007)(54906003)(66556008)(66946007)(38070700005)(71200400001)(122000001)(64756008)(38100700002)(966005)(166002)(66446008)(2906002)(6916009)(66574015)(83380400001)(8676002)(6512007)(91956017)(8936002)(86362001)(76116006)(5660300002)(508600001)(2616005)(6486002)(186003)(4326008)(33656002)(26005)(316002)(36756003)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?Y0FOMWVaNTdBVXpEQnRpdDhQRk9ndHh1Z0pzRjFqaFI2MjRiamRNVG15aDN0?= =?utf-8?B?R3JrWWp5emlrZzZ5OHdmajR6YndISnRWclIyZUZjUzJsUCt1RVlON0twMzBm?= =?utf-8?B?WDM2VW9UaTNua0RiZUU5WmpSMFdsd21jWTRjWVJYRFhLOUtyZmJ3NHBBbW1v?= =?utf-8?B?R3paZ2FvQWZtaERoc0xMV1cxQ05nZldqdVZBSVk2SnQ1S3NlQkN5SHozVWRi?= =?utf-8?B?NlNFdmxoWERaV2dRcVpsN1pvVzhuUDRobkZWLzhxTGQxNkNtQXo0Ynhudncr?= =?utf-8?B?VzNuQXRRdDFuQ21Db1lobGx1U0IvYUdMRVkrZmRvOEFZM0gwSXNzbFpNRGlI?= =?utf-8?B?OEF0bXN5U2JUbVBmY3Zpamo5ZFlGZVc3amdONWdtT2N6SUw5dUprdU1KNEI2?= =?utf-8?B?ODRlVDdZSVJjYllWUi9tbzYvdW1ZWUZHd2dOSjBPWkNYSGlSclpjMzRYMmFr?= =?utf-8?B?ZWJwQldUeDkzTmxPbHZQb1M2NENIUGZIei95ZDdQSGV4OFRMT3MvUjlRMUxN?= =?utf-8?B?bHpUa2FOc1NUcHJwRk5OSmZtM1VCcW5vZVhzUzNyb3duMm56THozcUpDczRL?= =?utf-8?B?Rk9VWEZhVDlUT25yZlpNbXBBZUR6bUpHQlpEaVlzWDFPWjk0d2FnM3ZZMk52?= =?utf-8?B?OVUxYUM2cXRydksyRUU3Qi9wYUZ3bkwxM2hleE5wblBDUTFSMkVvVDJBR0FT?= =?utf-8?B?dlN5ajY5T1VhQng3S3VYeHRaZUdIUlV6TCtCcVJqSHlCMjM5Sjd4aHNoditt?= =?utf-8?B?dytTOUR4Tmx4UWFXbGM4ZC9pckRWdjlXcXhyd3RwaEpXN1lKMi9IREJMYXIr?= =?utf-8?B?bmVRUUJma0dYU05BbGsxQ0dBL05Rb2VEdTA5cXlyb3FYalBKb1FpOW91T1RI?= =?utf-8?B?SysvbUg0MmRIZ09pSjM3RmJ3b1kyM0xYaERwbzZ2Q2JDcy9ONWVvSytPOUh0?= =?utf-8?B?RVlzdUZsdXFSbGtxUC9iTU11Um0rSlNINHNqQ3dMN3pQOU9HYmtWUmp0dDNV?= =?utf-8?B?bEhRbklQYzFYTzY0N2FiRUk2dzVpVUprdjVhcjI2aDYvWk10VmowdDAvbVdB?= =?utf-8?B?R1NMT1NDT1FiZnpGMUp5bTVleEcvd3djbHk4RGRlclYzUjRnRlg5Z1ZuSUdH?= =?utf-8?B?QnZHQ2dTcWZVSnpoc2RmQkRLNVp6RmpFUkQ0TVBpZ3pKZTdLZHczL3I3ZDV5?= =?utf-8?B?UU4rdDRZdllSa3huQTB6RzgvcG5iMStWcFdMYnNzY1h4M0xJRXRtWVZaSUtj?= =?utf-8?B?ZG1VTEViNEZTUG1tc0Y1TzYvMTlYWGJHUWc0aE1vd2JPUEVFME9LcjZqVFJv?= =?utf-8?B?cXpiWGxUbkYyanVXNE14VVUxcHpRNkRIQ2pyc3h4ZGM3cnVnK0V0Y1kzenM4?= =?utf-8?B?VXpQb2E0Skc5Yjg0Y1R5QldyQmJ6ZE9lYlFYclZTa3B0d0E2VEszMXhrWjJ3?= =?utf-8?B?NGZjK0Zadzh4dG1seHJIcDUxVGt1bU9paEpLbTBSVGJSOWFnUVJSVFBCQWtj?= =?utf-8?B?OXg0ejFtemtIN0EwU0lNS1Jnd0xiTDBFaWRVZFYwTjdNc3Uwb3pzNzZQaVNy?= =?utf-8?B?QjdBMTM4MEJQb3NYZFFGK255YXhqQld4MVBzR1BVc0ROQWRGejlwOXN2VWVp?= =?utf-8?B?dUpwNlo3WFVIVklhbVBZZ0I2MmpkNGl1bXRieTFURk9lM3RNSXFjZytKeHFq?= =?utf-8?B?OWNEQWVmMEdXaU5iL0VTTTZ3ZWdmUEFsZmlaYXdGdVFDNEVLUmpITkg1cDR1?= =?utf-8?B?OWVpcU5LNUdjay9HRXdINnhJRHlQSkQ1c2Z1bjg2cEVzTERSZU1NOHVhM3BV?= =?utf-8?B?T2ZuSHpFM1RVZjRpZTg0UT09?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CB63798DEBFB44D4A0C4FD22DEDC5EC3junipernet_" 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: 1cde3962-a8c3-4eb0-9320-08d98ea0ac26 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2021 23:24:58.2837 (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: S85RmmX2BR+bR5Vhjp21TjLMtSB8SovTWXYaDE6FsN0XHnQCcY9wHOA9F7kABCqw X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6592 X-Proofpoint-GUID: _QJbcJ4ynsStzveqaG56GKWddfTeLW13 X-Proofpoint-ORIG-GUID: _QJbcJ4ynsStzveqaG56GKWddfTeLW13 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-13_09,2021-10-13_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 lowpriorityscore=0 phishscore=0 bulkscore=0 suspectscore=0 priorityscore=1501 adultscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999 clxscore=1011 impostorscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110130141 Archived-At: Subject: Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 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, 13 Oct 2021 23:25:07 -0000 --_000_CB63798DEBFB44D4A0C4FD22DEDC5EC3junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpNeSBxdWVzdGlvbiBkb2VzbuKAmXQgaGF2ZSBhbnl0aGluZyB0byBkbyB3 aXRoIOKAnGNsYXNzaWMgQVNJQyBkZXNpZ27igJ0uIEluZGVlZCBpZiB5b3UgbG9vayBhdCB0aGUg ZGVmaW5pdGlvbnMgSSBzdXBwbGllZCB0aGV5IGRvbuKAmXQgc2F5IGFueXRoaW5nIGF0IGFsbCBh Ym91dCBob3cgdGhlIHJvdXRlciBpcyBpbXBsZW1lbnRlZCwgdGhlIG5hdHVyZSBvZiB0aGUgY29u dHJvbCBwbGFuZSBpbmNsdWRpbmcgd2hldGhlciB0aGVyZSBpcyBvbmUsIGFuZCBpbmRlZWQgYXJl IHZlcnkgYnJvYWQuIEkgd291bGQgc2F5IHRoZXkgYXJlIGdlbmVyYWwgZW5vdWdoIHRvIGVuY29t cGFzcyBldmVyeXRoaW5nIHlvdSBkZXNjcmliZWQuDQoNCkFzIGJlc3QgSSBjYW4gdGVsbCwg4oCc YWRkaW5nIG5ldyBmbGF2b1t1XXJz4oCdIG9yIOKAnGFkZGluZyBuZXcgYmVoYXZpb3Jz4oCdIGlz IGp1c3QgYSBkaWZmZXJlbnQgd2F5IG9mIHNheWluZyDigJxtYWtpbmcgYSBjaGFuZ2UgdG8gdGhl IGxvY2FsLCBwZXItcm91dGVyIGZ1bmN0aW9uIHRoYXQgZGV0ZXJtaW5lcyBob3cgYSBkYXRhZ3Jh bSBhcnJpdmluZyBvbiBhIHJvdXRlciBpbnB1dCBwb3J0IGlzIGZvcndhcmRlZCB0byBhIHJvdXRl ciBvdXRwdXQgcG9ydOKAnS4gVGhhdCBpcyB0byBzYXksIGJ5IGRlZmluaXRpb24gaXQgaXMgYSBj aGFuZ2UgdG8gdGhlIGZvcndhcmRpbmcgcGxhbmUuDQoNCkkgdHJpZWQgdG8gbW90aXZhdGUgdGhp cyB3aXRoIHRoZSBmb3ItaW5zdGFuY2UgaW4gbXkgZm91cnRoIHBhcmFncmFwaDogY2FuIG15IHBs YWluLXZhbmlsbGEgUkZDIDg3NTQgbmV0d29yayBzdWNjZXNzZnVsbHkgZm9yd2FyZCBhIHBhY2tl dCB0aGF0IHVzZXMgY1NJRHM/IE9yIGRvZXMgaXQgbmVlZCBuZXcgc29mdHdhcmUsIGF0IHRoZSBu b2RlcyBpZGVudGlmaWVkIGJ5IHRoZSBTSURzIGNvbnRhaW5lZCBpbiB0aGUgY1NJRCwgaW4gb3Jk ZXIgdG8gc3VwcGx5IHN1cHBvcnQgZm9yIHRoZSDigJxuZXcgZmxhdm9y4oCdIG9yIOKAnG5ldyBi ZWhhdmlvcuKAnT8gSWYgaXQgbmVlZHMgbmV3IHNvZnR3YXJlLCB0aGVuIGl0IHNlZW1zIHNlbGYt ZXZpZGVudCB0byBtZSB0aGF0IGl04oCZcyBhIGNoYW5nZSB0byB0aGUgZm9yd2FyZGluZyBwbGFu ZSDigJQgaXQg4oCcbG9va3MgbGlrZSBhIGR1Y2ssIHN3aW1zIGxpa2UgYSBkdWNrLCBhbmQgcXVh Y2tzIGxpa2UgYSBkdWNr4oCdLlsqXQ0KDQpUaGFua3MsDQoNCuKAlEpvaG4NCg0KWypdIGh0dHBz Oi8vZW4ud2lraXBlZGlhLm9yZy93aWtpL0R1Y2tfdGVzdA0KDQpPbiBPY3QgMTMsIDIwMjEsIGF0 IDY6NTcgUE0sIFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRA cmFzenVrLm5ldD4+IHdyb3RlOg0KDQoNCkhpIEpvaG4sDQoNCkkgdGhpbmsgdGhlIGNydXggb2Yg dGhlIG1hdHRlciBpcyBpbmRlZWQgaW4gZGVmaW5pdGlvbiBvZiAiU1JIIGRhdGEgcGxhbmUiLiBT byBsZXQgbWUgcHJlc2VudCBteSBvd24gcGVyc29uYWwgdW5kZXJzdGFuZGluZyBvZiBpdC4NCg0K Q2xlYXJseSBTUkggZXh0ZXJuYWwgZm9ybWF0IGRvZXMgbm90IGNoYW5nZSBzbyBoYXJkd2FyZSdz IGFiaWxpdHkgdG8gcmVhZCBTUkggcmVtYWlucyBpbnRhY3QuIElQdjYgcGFja2V0J3MgaGVhZGVy IGFsc28gY2FuIGJlIHJlYWQgYW5kIHByb2Nlc3NlZCBieSBuZXR3b3JrIGVsZW1lbnRzIHdoaWNo IGhhdmUgbm8gaWRlYSBhYm91dCBjU0lEcyBzbyB0aGF0IGFzIHdlbGwgaXMgbm90IHF1ZXN0aW9u YWJsZS4NCg0KTm93IHlvdXIgZGVmaW5pdGlvbiBvZiBkYXRhIHBsYW5lIGlzIHNvdW5kIGlmIHlv dSBjb25zaWRlciB0cmFkaXRpb25hbCBkYXRhIHBsYW5lcyBvZiBuZXR3b3JrIGVsZW1lbnRzIHdo ZW4gY29udHJvbCBwbGFuZSBpbnB1dCBzZXQncyBmb3J3YXJkaW5nIGJlaGF2aW91ci4NCg0KV2Vs bCBpbiBTUkggYXMgeW91IGtub3cgd2UgaGF2ZSBTSURzIHdoaWNoIGluc2lkZSBtYXkgY29udGFp biBmdW5jdGlvbnMuIFNvIGZvcndhcmRpbmcgYmVoYXZpb3IgaXMgbm90IHByZSBwcm9ncmFtbWVk IGZyb20gY29udHJvbCBwbGFuZSwgYnV0IGNhbiBhbmQgb2Z0ZW4gaXMgZW1iZWRkZWQgaW4gdGhl IGFjdHVhbCBwYWNrZXRzLiBUaGF0IGlzIHdoYXQgcmVhbCBuZXR3b3JrIHByb2dyYW1taW5nIGlz IGFsbCBhYm91dC4gQW5kIGVhY2ggZnVuY3Rpb24gY2FuIGhhdmUgem9vIG9mIGFsc28gbmVzdGVk IGFyZ3VtZW50cyBhbGwgcmVzdWx0aW5nIGluIGRpZmZlcmVudCBmb3J3YXJkaW5nIG91dGNvbWUu DQoNCldpdGggc3VjaCBkZWZpbml0aW9uIG9mIFNSSCBkYXRhIHBsYW5lIEkgZG8gbm90IHNlZSBh bnl0aGluZyBuZXcgaW4gYWRkaW5nIGZldyBuZXcgZmxhdm91cnMgdG8gZXhpc3RpbmcgYmVoYXZp b3VycyBvciBldmVuIGFkZGluZyBuZXcgYmVoYXZpb3Vycy4NCg0KTm93IHRoZSBxdWVzdGlvbiBp cyBkbyB3ZSBhbGwgc2VlIFNSSCBkYXRhIHBsYW5lIGluIHRoZSBzYW1lIHdheS4gTWF5YmUgaXQg aXMgd2F5IGFoZWFkIG9mIG91ciB0aW1lcyBhbmQgY2xhc3NpYyBBU0lDIGRlc2lnbiA/IEFuZCBJ IGFtIGluIG5vIHdheSBqdWRnaW5nIGhlcmUgaWYgdGhpcyBpcyBnb29kIG9yIGJhZCAtIEkgYW0g anVzdCBvYnNlcnZpbmcgdGhlIGZhY3RzIGFuZCBhbHJlYWR5IHB1Ymxpc2hlZCBSRkNzLg0KDQpN YW55IHRoeCwNClJvYmVydA0KDQpQUy4gQW5kIEkgZG8gYWdyZWUgd2l0aCB5b3VyIGlubGluZSBj b21tZW50IHRoYXQgY1NJRHMgc2hvdWxkIGJlIHBvc3NpYmxlIHRvIGJlIHVzZWQgd2l0aG91dCBT UkggaWYgbm8gc3BlY2lhbCBmdW5jdGlvbnMgYXJlIG5lZWRlZCBhdCBlYWNoIHNlZ21lbnQgZW5k cG9pbnQuDQoNCk9uIFRodSwgT2N0IDE0LCAyMDIxIGF0IDEyOjI4IEFNIEpvaG4gU2N1ZGRlciA8 amdzQGp1bmlwZXIubmV0PG1haWx0bzpqZ3NAanVuaXBlci5uZXQ+PiB3cm90ZToNCkhpIEZvbGtz LA0KDQpJ4oCZbSBzdHJ1Z2dsaW5nIHdpdGggdGhlIGNsYWltIHJlcGVhdGVkIHRocm91Z2hvdXQg dGhlIGJlZ2lubmluZyBvZiBkcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21w cmVzc2lvbi0wMiAoQWJzdHJhY3QsIMKnMSwgwqczKSB0aGF0IOKAnHRoaXMgc29sdXRpb24gZG9l cyBub3QgcmVxdWlyZSBhbnkgU1JIIGRhdGEgcGxhbmUgY2hhbmdl4oCdLg0KDQpJ4oCZbSBub3Qg YXdhcmUgb2YgYSBzdGFuZGFyZGl6ZWQgZm9ybWFsIGRlZmluaXRpb24gb2Yg4oCcZGF0YSBwbGFu ZeKAnSwgaXQgc2VlbXMgdG8gZm9sbG93IEp1c3RpY2UgU3Rld2FydOKAmXMgbWF4aW0gb2Yg4oCc SSBrbm93IGl0IHdoZW4gSSBzZWUgaXTigJ0uIEhvd2V2ZXIsIGhlcmXigJlzIGFuIGF0dGVtcHQs IGNyaWJiZWQgZnJvbSBzb21lIFdhc2hpbmd0b24gVW5pdmVyc2l0eSBjb3Vyc2Ugc2xpZGVzOiBh IOKAnGxvY2FsLCBwZXItcm91dGVyIGZ1bmN0aW9uIHRoYXQgZGV0ZXJtaW5lcyBob3cgYSBkYXRh Z3JhbSBhcnJpdmluZyBvbiBhIHJvdXRlciBpbnB1dCBwb3J0IGlzIGZvcndhcmRlZCB0byBhIHJv dXRlciBvdXRwdXQgcG9ydOKAnS4gU2VlbXMgcmVhc29uYWJsZS4NCg0KSSBhbHNvIGFtIG5vdCBh d2FyZSBvZiBhIHN0YW5kYXJkaXplZCBmb3JtYWwgZGVmaW5pdGlvbiBvZiB0aGUgdGVybSDigJxT UkggZGF0YSBwbGFuZeKAnSwgaW4gZmFjdCB0aGlzIGRyYWZ0LCBpdHMgcHJlZGVjZXNzb3JzLCBz b21lIGFzc29jaWF0ZWQgYmxvZyBwb3N0cywgYW5kIENsYXJlbmNl4oCZcyBkaXNzZXJ0YXRpb24s IGFyZSB0aGUgb25seSBwbGFjZXMgYSBzZWFyY2ggZmluZHMgdGhlIHBocmFzZSAoYnV0IGl04oCZ cyBub3QgZm9ybWFsbHkgZGVmaW5lZCBpbiBhbnkgb2YgdGhlbSkuIFNvIEnigJltIGp1c3QgZ29p bmcgdG8gYXNzdW1lIGl0IG1lYW5zIHRoZSBkYXRhIHBsYW5lLCBhcyBhcHBsaWVkIHRvIHBhY2tl dHMgdGhhdCBpbmNsdWRlIGFuIFNSSC4gKEnigJltIG5vdCBzdXJlIHdoeSB3ZSBzaG91bGQgZGlz cmVnYXJkIHBhY2tldHMgdGhhdCBhcmUgZW5jb2RlZCB1c2luZyBORVhULUMtU0lEIHRoYXQgb21p dCB0aGUgU1JILCBidXQgbGV04oCZcyBvdmVybG9vayB0aGF0IGZvciBub3cuKQ0KDQpJZiB0aGlz IHNvbHV0aW9uIGRvZXMgbm90IHJlcXVpcmUgYW55IFNSSCBkYXRhIHBsYW5lIGNoYW5nZSwgcHJl c3VtYWJseSBpdCB3b3VsZCBiZSB0cnVlIHRoYXQgaWYgSSB0YWtlIGEgcGFja2V0IHRoYXQgaW5j bHVkZXMgYW4gU1JIIGFuZCBwbGFjZSB3aXRoaW4gaXQgYSBzZXJpZXMgb2YgU0lEcyBlbmNvZGVk IHdpdGggKGZvciBleGFtcGxlKSB0aGUgUkVQTEFDRS1DLVNJRCBmbGF2b3IsIHRoZW4gdGhhdCBw YWNrZXQgd291bGQgYmUgYWJsZSB0byBzdWNjZXNzZnVsbHkgdHJhdmVyc2UgYSBuZXR3b3JrIG9m IHJvdXRlcnMgdGhhdCBzdXBwb3J0IHBsYWluIHZhbmlsbGEgUkZDIDg3NTQuIFRoYXQgaXMsIGl0 IHdvdWxkIGFycml2ZSBhdCBpdHMgZmlyc3QgaG9wIHJvdXRlciB3aGljaCBhY2NvcmRpbmcgdG8g YSBsb2NhbCwgcGVyLXJvdXRlciBmdW5jdGlvbiwgd291bGQgZGV0ZXJtaW5lIGhvdyB0byB0YWtl IHRoZSBkYXRhZ3JhbSBhcnJpdmluZyBvbiB0aGUgcm91dGVyIGlucHV0IHBvcnQgYW5kIGZvcndh cmQgaXQgdG8gKHRoZSBjb3JyZWN0KSByb3V0ZXIgb3V0cHV0IHBvcnQuIFRoZW4gdGhhdCBwcm9j ZXNzIHdvdWxkIGJlIHJlcGVhdGVkIGFjcm9zcyB0aGUgcmVzdCBvZiB0aGUgbmV0d29yay4NCg0K QnV0IHRoYXQgaXMgcGF0ZW50bHkgaW5jb3JyZWN0OiB3aGVuIGl04oCZcyBkZWxpdmVyZWQgdG8g dGhlIGZpcnN0IGhvcCwgdGhlIHBsYWluIHZhbmlsbGEgUkZDIDg3NTQgcm91dGVyIHdpbGwgYmUg dW5hYmxlIHRvIGFwcGx5IHRoZSBSRVBMQUNFLUMtU0lEIGJlaGF2aW9yLCBhbmQgZm9yd2FyZGlu ZyB0byB0aGUgbmV4dCBob3Agd2lsbCBmYWlsLiBJdCBzZWVtcyB0aGF0IGEgZGlmZmVyZW50IGxv Y2FsLCBwZXItcm91dGVyIGZ1bmN0aW9uIGlzIHJlcXVpcmVkIChpbiBmYWN0LCB0aGUgbG9jYWws IHBlci1yb3V0ZXIgZnVuY3Rpb24gZGVmaW5lZCBpbiB0aGUgZHJhZnQpIGluIG9yZGVyIGZvciB0 aGUgZm9yd2FyZGluZyB0byBzdWNjZWVkLiBCeSB0aGUgZGVmaW5pdGlvbnMgSeKAmW0gdXNpbmcg aGVyZSwgdGhhdCBpcyBleGFjdGx5IGEgZGF0YSBwbGFuZSBjaGFuZ2UuDQoNCldoYXQsIHByZWNp c2VseSwgaXMgdGhlbiBiZWluZyBjbGFpbWVkPw0KDQpUaGFua3MsDQoNCuKAlEpvaG4NCg0K --_000_CB63798DEBFB44D4A0C4FD22DEDC5EC3junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <35FDDE2C1EBE734283809836EB1842E3@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIFJvYmVydCwNCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk15IHF1ZXN0aW9uIGRvZXNu4oCZdCBo YXZlIGFueXRoaW5nIHRvIGRvIHdpdGgg4oCcY2xhc3NpYyBBU0lDIGRlc2lnbuKAnS4gSW5kZWVk IGlmIHlvdSBsb29rIGF0IHRoZSBkZWZpbml0aW9ucyBJIHN1cHBsaWVkIHRoZXkgZG9u4oCZdCBz YXkgYW55dGhpbmcgYXQgYWxsIGFib3V0IGhvdyB0aGUgcm91dGVyIGlzIGltcGxlbWVudGVkLCB0 aGUgbmF0dXJlIG9mIHRoZSBjb250cm9sIHBsYW5lIGluY2x1ZGluZyB3aGV0aGVyIHRoZXJlIGlz DQogb25lLCBhbmQgaW5kZWVkIGFyZSB2ZXJ5IGJyb2FkLiBJIHdvdWxkIHNheSB0aGV5IGFyZSBn ZW5lcmFsIGVub3VnaCB0byBlbmNvbXBhc3MgZXZlcnl0aGluZyB5b3UgZGVzY3JpYmVkLjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+QXMg YmVzdCBJIGNhbiB0ZWxsLCDigJxhZGRpbmcgbmV3IGZsYXZvW3VdcnPigJ0gb3Ig4oCcYWRkaW5n IG5ldyBiZWhhdmlvcnPigJ0gaXMganVzdCBhIGRpZmZlcmVudCB3YXkgb2Ygc2F5aW5nIOKAnG1h a2luZyBhIGNoYW5nZSB0byB0aGUmbmJzcDtsb2NhbCwgcGVyLXJvdXRlciBmdW5jdGlvbiB0aGF0 IGRldGVybWluZXMgaG93IGEgZGF0YWdyYW0gYXJyaXZpbmcgb24gYSByb3V0ZXIgaW5wdXQgcG9y dCBpcyBmb3J3YXJkZWQgdG8gYSByb3V0ZXImbmJzcDtvdXRwdXQNCiBwb3J04oCdLiBUaGF0IGlz IHRvIHNheSwgYnkgZGVmaW5pdGlvbiBpdCBpcyBhIGNoYW5nZSB0byB0aGUgZm9yd2FyZGluZyBw bGFuZS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPkkgdHJpZWQgdG8gbW90aXZhdGUgdGhpcyB3aXRoIHRoZSBmb3ItaW5zdGFuY2UgaW4g bXkgZm91cnRoIHBhcmFncmFwaDogY2FuIG15IHBsYWluLXZhbmlsbGEgUkZDIDg3NTQgbmV0d29y ayBzdWNjZXNzZnVsbHkgZm9yd2FyZCBhIHBhY2tldCB0aGF0IHVzZXMgY1NJRHM/IE9yIGRvZXMg aXQgbmVlZCBuZXcgc29mdHdhcmUsIGF0IHRoZSBub2RlcyBpZGVudGlmaWVkIGJ5IHRoZSBTSURz IGNvbnRhaW5lZCBpbiB0aGUgY1NJRCwNCiBpbiBvcmRlciB0byBzdXBwbHkgc3VwcG9ydCBmb3Ig dGhlIOKAnG5ldyBmbGF2b3LigJ0gb3Ig4oCcbmV3IGJlaGF2aW9y4oCdPyBJZiBpdCBuZWVkcyBu ZXcgc29mdHdhcmUsIHRoZW4gaXQgc2VlbXMgc2VsZi1ldmlkZW50IHRvIG1lIHRoYXQgaXTigJlz IGEgY2hhbmdlIHRvIHRoZSBmb3J3YXJkaW5nIHBsYW5lIOKAlCBpdCDigJxsb29rcyBsaWtlIGEg ZHVjaywgc3dpbXMgbGlrZSBhIGR1Y2ssIGFuZCBxdWFja3MgbGlrZSBhIGR1Y2vigJ0uWypdPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5U aGFua3MsPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj7igJRKb2huPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5bKl0mbmJzcDs8YSBocmVmPSJodHRwczovL2VuLndpa2lwZWRpYS5v cmcvd2lraS9EdWNrX3Rlc3QiIGNsYXNzPSIiPmh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtp L0R1Y2tfdGVzdDwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0iIj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBPY3Qg MTMsIDIwMjEsIGF0IDY6NTcgUE0sIFJvYmVydCBSYXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpy b2JlcnRAcmFzenVrLm5ldCIgY2xhc3M9IiI+cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0OyB3cm90 ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+SGkgSm9obiwNCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkkgdGhpbmsg dGhlIGNydXggb2YgdGhlIG1hdHRlciBpcyBpbmRlZWQgaW4gZGVmaW5pdGlvbiBvZiAmcXVvdDtT UkggZGF0YSBwbGFuZSZxdW90Oy4gU28gbGV0IG1lIHByZXNlbnQgbXkgb3duIHBlcnNvbmFsIHVu ZGVyc3RhbmRpbmcgb2YgaXQuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5DbGVhcmx5IFNSSCBleHRlcm5hbCBmb3JtYXQgZG9l cyBub3QgY2hhbmdlIHNvIGhhcmR3YXJlJ3MgYWJpbGl0eSB0byByZWFkIFNSSCByZW1haW5zIGlu dGFjdC4gSVB2NiBwYWNrZXQncyBoZWFkZXIgYWxzbyBjYW4gYmUgcmVhZCBhbmQgcHJvY2Vzc2Vk IGJ5IG5ldHdvcmsgZWxlbWVudHMgd2hpY2ggaGF2ZSBubyBpZGVhIGFib3V0IGNTSURzIHNvIHRo YXQgYXMgd2VsbCBpcyBub3QgcXVlc3Rpb25hYmxlLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Tm93IHlvdXIgZGVmaW5pdGlv biBvZiBkYXRhIHBsYW5lIGlzIHNvdW5kIGlmIHlvdSBjb25zaWRlciB0cmFkaXRpb25hbCBkYXRh IHBsYW5lcyZuYnNwO29mIG5ldHdvcmsgZWxlbWVudHMgd2hlbiBjb250cm9sIHBsYW5lIGlucHV0 IHNldCdzIGZvcndhcmRpbmcgYmVoYXZpb3VyLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2VsbCBpbiBTUkggYXMgeW91IGtu b3cgd2UgaGF2ZSBTSURzIHdoaWNoIGluc2lkZSBtYXkgY29udGFpbiBmdW5jdGlvbnMuIFNvIGZv cndhcmRpbmcgYmVoYXZpb3IgaXMgbm90IHByZSBwcm9ncmFtbWVkIGZyb20gY29udHJvbCBwbGFu ZSwgYnV0IGNhbiBhbmQgb2Z0ZW4gaXMgZW1iZWRkZWQgaW4gdGhlIGFjdHVhbCBwYWNrZXRzLiBU aGF0IGlzIHdoYXQgcmVhbCBuZXR3b3JrIHByb2dyYW1taW5nIGlzIGFsbCBhYm91dC4NCiBBbmQg ZWFjaCBmdW5jdGlvbiZuYnNwO2NhbiBoYXZlIHpvbyBvZiBhbHNvIG5lc3RlZCBhcmd1bWVudHMg YWxsIHJlc3VsdGluZyBpbiBkaWZmZXJlbnQgZm9yd2FyZGluZyBvdXRjb21lLiZuYnNwOzwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+V2l0 aCBzdWNoIGRlZmluaXRpb24gb2YgU1JIIGRhdGEgcGxhbmUgSSBkbyBub3Qgc2VlIGFueXRoaW5n IG5ldyBpbiBhZGRpbmcgZmV3IG5ldyBmbGF2b3VycyB0byBleGlzdGluZyBiZWhhdmlvdXJzIG9y IGV2ZW4gYWRkaW5nIG5ldyBiZWhhdmlvdXJzLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Tm93IHRoZSBxdWVzdGlvbiBpcyBk byB3ZSBhbGwgc2VlIFNSSCBkYXRhIHBsYW5lIGluIHRoZSBzYW1lIHdheS4gTWF5YmUgaXQgaXMg d2F5IGFoZWFkIG9mIG91ciB0aW1lcyBhbmQgY2xhc3NpYyBBU0lDIGRlc2lnbiA/IEFuZCBJIGFt IGluIG5vIHdheSBqdWRnaW5nJm5ic3A7aGVyZSBpZiB0aGlzIGlzIGdvb2Qgb3IgYmFkIC0gSSBh bSBqdXN0IG9ic2VydmluZyB0aGUgZmFjdHMgYW5kIGFscmVhZHkgcHVibGlzaGVkJm5ic3A7UkZD cy4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPk1hbnkgdGh4LDwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5Sb2JlcnQ8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlBTLiBBbmQg SSBkbyBhZ3JlZSB3aXRoIHlvdXImbmJzcDtpbmxpbmUgY29tbWVudCB0aGF0IGNTSURzIHNob3Vs ZCBiZSBwb3NzaWJsZSB0byBiZSB1c2VkIHdpdGhvdXQgU1JIIGlmIG5vJm5ic3A7c3BlY2lhbCZu YnNwO2Z1bmN0aW9ucyBhcmUgbmVlZGVkJm5ic3A7YXQgZWFjaCBzZWdtZW50IGVuZHBvaW50LiZu YnNwOzwvZGl2Pg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90 ZSI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0ciI+T24gVGh1LCBPY3QgMTQsIDIw MjEgYXQgMTI6MjggQU0gSm9obiBTY3VkZGVyICZsdDs8YSBocmVmPSJtYWlsdG86amdzQGp1bmlw ZXIubmV0IiBjbGFzcz0iIj5qZ3NAanVuaXBlci5uZXQ8L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdp bjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0 KTtwYWRkaW5nLWxlZnQ6MWV4Ij4NCkhpIEZvbGtzLDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0i Ij4NCknigJltIHN0cnVnZ2xpbmcgd2l0aCB0aGUgY2xhaW0gcmVwZWF0ZWQgdGhyb3VnaG91dCB0 aGUgYmVnaW5uaW5nIG9mIGRyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXBy ZXNzaW9uLTAyIChBYnN0cmFjdCwgwqcxLCDCpzMpIHRoYXQg4oCcdGhpcyBzb2x1dGlvbiBkb2Vz IG5vdCByZXF1aXJlIGFueSBTUkggZGF0YSBwbGFuZSBjaGFuZ2XigJ0uPGJyIGNsYXNzPSIiPg0K PGJyIGNsYXNzPSIiPg0KSeKAmW0gbm90IGF3YXJlIG9mIGEgc3RhbmRhcmRpemVkIGZvcm1hbCBk ZWZpbml0aW9uIG9mIOKAnGRhdGEgcGxhbmXigJ0sIGl0IHNlZW1zIHRvIGZvbGxvdyBKdXN0aWNl IFN0ZXdhcnTigJlzIG1heGltIG9mIOKAnEkga25vdyBpdCB3aGVuIEkgc2VlIGl04oCdLiBIb3dl dmVyLCBoZXJl4oCZcyBhbiBhdHRlbXB0LCBjcmliYmVkIGZyb20gc29tZSBXYXNoaW5ndG9uIFVu aXZlcnNpdHkgY291cnNlIHNsaWRlczogYSDigJxsb2NhbCwgcGVyLXJvdXRlciBmdW5jdGlvbiB0 aGF0DQogZGV0ZXJtaW5lcyBob3cgYSBkYXRhZ3JhbSBhcnJpdmluZyBvbiBhIHJvdXRlciBpbnB1 dCBwb3J0IGlzIGZvcndhcmRlZCB0byBhIHJvdXRlciBvdXRwdXQgcG9ydOKAnS4gU2VlbXMgcmVh c29uYWJsZS48YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpJIGFsc28gYW0gbm90IGF3YXJl IG9mIGEgc3RhbmRhcmRpemVkIGZvcm1hbCBkZWZpbml0aW9uIG9mIHRoZSB0ZXJtIOKAnFNSSCBk YXRhIHBsYW5l4oCdLCBpbiBmYWN0IHRoaXMgZHJhZnQsIGl0cyBwcmVkZWNlc3NvcnMsIHNvbWUg YXNzb2NpYXRlZCBibG9nIHBvc3RzLCBhbmQgQ2xhcmVuY2XigJlzIGRpc3NlcnRhdGlvbiwgYXJl IHRoZSBvbmx5IHBsYWNlcyBhIHNlYXJjaCBmaW5kcyB0aGUgcGhyYXNlIChidXQgaXTigJlzIG5v dCBmb3JtYWxseSBkZWZpbmVkDQogaW4gYW55IG9mIHRoZW0pLiBTbyBJ4oCZbSBqdXN0IGdvaW5n IHRvIGFzc3VtZSBpdCBtZWFucyB0aGUgZGF0YSBwbGFuZSwgYXMgYXBwbGllZCB0byBwYWNrZXRz IHRoYXQgaW5jbHVkZSBhbiBTUkguIChJ4oCZbSBub3Qgc3VyZSB3aHkgd2Ugc2hvdWxkIGRpc3Jl Z2FyZCBwYWNrZXRzIHRoYXQgYXJlIGVuY29kZWQgdXNpbmcgTkVYVC1DLVNJRCB0aGF0IG9taXQg dGhlIFNSSCwgYnV0IGxldOKAmXMgb3Zlcmxvb2sgdGhhdCBmb3Igbm93Lik8YnIgY2xhc3M9IiI+ DQo8YnIgY2xhc3M9IiI+DQpJZiB0aGlzIHNvbHV0aW9uIGRvZXMgbm90IHJlcXVpcmUgYW55IFNS SCBkYXRhIHBsYW5lIGNoYW5nZSwgcHJlc3VtYWJseSBpdCB3b3VsZCBiZSB0cnVlIHRoYXQgaWYg SSB0YWtlIGEgcGFja2V0IHRoYXQgaW5jbHVkZXMgYW4gU1JIIGFuZCBwbGFjZSB3aXRoaW4gaXQg YSBzZXJpZXMgb2YgU0lEcyBlbmNvZGVkIHdpdGggKGZvciBleGFtcGxlKSB0aGUgUkVQTEFDRS1D LVNJRCBmbGF2b3IsIHRoZW4gdGhhdCBwYWNrZXQgd291bGQgYmUgYWJsZSB0bw0KIHN1Y2Nlc3Nm dWxseSB0cmF2ZXJzZSBhIG5ldHdvcmsgb2Ygcm91dGVycyB0aGF0IHN1cHBvcnQgcGxhaW4gdmFu aWxsYSBSRkMgODc1NC4gVGhhdCBpcywgaXQgd291bGQgYXJyaXZlIGF0IGl0cyBmaXJzdCBob3Ag cm91dGVyIHdoaWNoIGFjY29yZGluZyB0byBhIGxvY2FsLCBwZXItcm91dGVyIGZ1bmN0aW9uLCB3 b3VsZCBkZXRlcm1pbmUgaG93IHRvIHRha2UgdGhlIGRhdGFncmFtIGFycml2aW5nIG9uIHRoZSBy b3V0ZXIgaW5wdXQgcG9ydCBhbmQNCiBmb3J3YXJkIGl0IHRvICh0aGUgY29ycmVjdCkgcm91dGVy IG91dHB1dCBwb3J0LiBUaGVuIHRoYXQgcHJvY2VzcyB3b3VsZCBiZSByZXBlYXRlZCBhY3Jvc3Mg dGhlIHJlc3Qgb2YgdGhlIG5ldHdvcmsuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KQnV0 IHRoYXQgaXMgcGF0ZW50bHkgaW5jb3JyZWN0OiB3aGVuIGl04oCZcyBkZWxpdmVyZWQgdG8gdGhl IGZpcnN0IGhvcCwgdGhlIHBsYWluIHZhbmlsbGEgUkZDIDg3NTQgcm91dGVyIHdpbGwgYmUgdW5h YmxlIHRvIGFwcGx5IHRoZSBSRVBMQUNFLUMtU0lEIGJlaGF2aW9yLCBhbmQgZm9yd2FyZGluZyB0 byB0aGUgbmV4dCBob3Agd2lsbCBmYWlsLiBJdCBzZWVtcyB0aGF0IGEgZGlmZmVyZW50IGxvY2Fs LCBwZXItcm91dGVyIGZ1bmN0aW9uIGlzIHJlcXVpcmVkDQogKGluIGZhY3QsIHRoZSBsb2NhbCwg cGVyLXJvdXRlciBmdW5jdGlvbiBkZWZpbmVkIGluIHRoZSBkcmFmdCkgaW4gb3JkZXIgZm9yIHRo ZSBmb3J3YXJkaW5nIHRvIHN1Y2NlZWQuIEJ5IHRoZSBkZWZpbml0aW9ucyBJ4oCZbSB1c2luZyBo ZXJlLCB0aGF0IGlzIGV4YWN0bHkgYSBkYXRhIHBsYW5lIGNoYW5nZS48YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQpXaGF0LCBwcmVjaXNlbHksIGlzIHRoZW4gYmVpbmcgY2xhaW1lZD88YnIg Y2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpUaGFua3MsPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNz PSIiPg0K4oCUSm9objwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_CB63798DEBFB44D4A0C4FD22DEDC5EC3junipernet_-- From nobody Wed Oct 13 16:53:55 2021 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 3B8093A15D4 for ; Wed, 13 Oct 2021 16:53:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=uniroma2.it header.b=sNqRiAUS; dkim=pass (2048-bit key) header.d=uniroma2.it header.b=v9zvFL3x 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 uCmz3w0CYibD for ; Wed, 13 Oct 2021 16:53:44 -0700 (PDT) Received: from smtp.uniroma2.it (smtp.uniroma2.it [160.80.6.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 93C7F3A15D1 for ; Wed, 13 Oct 2021 16:53:43 -0700 (PDT) Received: from smtpauth-2019-1.uniroma2.it (smtpauth-2019-1.uniroma2.it [160.80.5.46]) by smtp-2015.uniroma2.it (8.14.4/8.14.4/Debian-8) with ESMTP id 19DNrXpt018325 for ; Thu, 14 Oct 2021 01:53:38 +0200 Received: from [192.168.1.82] (93-41-113-141.ip81.fastwebnet.it [93.41.113.141]) by smtpauth-2019-1.uniroma2.it (Postfix) with ESMTPSA id B24951209F4 for ; Thu, 14 Oct 2021 01:53:29 +0200 (CEST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=uniroma2.it; s=ed201904; t=1634169209; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+XN87CAqfqogDBg/YQmEeM2vOe68TMQofrDiWDrKjTo=; b=sNqRiAUStstrpXFr/2lwUQPsfC9oP6LOnhccCIcTlSYkiMCvzdVd4eghdsVIWPeEhdUjk2 YF7txE/LcrW/0NDQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniroma2.it; s=rsa201904; t=1634169209; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=+XN87CAqfqogDBg/YQmEeM2vOe68TMQofrDiWDrKjTo=; b=v9zvFL3xAmmOw2ymKt4wLZbwuRxp5bNUYtrnpv6FgKe1ipbdQ43r6S9HNXGjvAHG0XNobR vUJL0c03sfH21J+40cRAZlCTa0noIMH8PRm6d3qEsYyQubJ6WvP22nLtwjZ8kycHjhoskb MwwmocS8BQqLr+aRSGBn/IuDWtH/Vc9fz9nKwWboiU+1iWBE+OCViP0r34h2fvRk4BU7IH Zjzm1ZRW2iRLzM6UTVqPHekua82iQvAyHYAI5IFPRTs9s3mPuXdplTnhciAU6tdKrbW91h cOk0YX8mkkNM3xSBUcvn9cosSWmtM8lSU3cz/9ucAUvt2AbonbbJtg5qUIzvIw== To: spring@ietf.org References: From: Stefano Salsano Message-ID: Date: Thu, 14 Oct 2021 01:53:28 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: it-IT Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.0 at smtp-2015 X-Virus-Status: Clean Archived-At: Subject: Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 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, 13 Oct 2021 23:53:52 -0000 Il 2021-10-14 01:24, John Scudder ha scritto: > Hi Robert, > > My question doesn’t have anything to do with “classic ASIC design”. > Indeed if you look at the definitions I supplied they don’t say anything > at all about how the router is implemented, the nature of the control > plane including whether there is one, and indeed are very broad. I would > say they are general enough to encompass everything you described. > > As best I can tell, “adding new flavo[u]rs” or “adding new behaviors” is > just a different way of saying “making a change to the local, per-router > function that determines how a datagram arriving on a router input port > is forwarded to a router output port”. That is to say, by definition it > is a change to the forwarding plane. > > I tried to motivate this with the for-instance in my fourth paragraph: > can my plain-vanilla RFC 8754 network successfully forward a packet that > uses cSIDs? Or does it need new software, at the nodes identified by the > SIDs contained in the cSID, in order to supply support for the “new > flavor” or “new behavior”? If it needs new software, then it seems > self-evident to me that it’s a change to the forwarding plane — it > “looks like a duck, swims like a duck, and quacks like a duck”.[*] Hi John, I agree that the statement "this solution does not require any SRH data plane change" needs to be clarified, also because there is no formal definition of a "data plane", hence it is even more vague the "SRH data plane". My understanding of "SRH data plane" here is the combination of RFC 8754 AND RFC 8986 (SRv6 Network Programming). The second sentence in the draft says: "SRv6 Network Programming [RFC8986] defines a framework to build a network program with topological and service segments carried in a Segment Routing header (SRH) [RFC8754]." So I think the context of the draft is SRv6 Network programming... in this context the basic idea is that you can add new features (i.e. new instructions) in specific nodes and add the "network program" in the packet header so that you know in advance which nodes will execute which instructions. In this way you can include in your network a mix of "legacy" RFC 8754 nodes (that do not need to implement the new features) and nodes that support the new features (e.g. the CSID flavours). I think this gives a reasonable interpretaion of "does not require any SRH data plane change"... though I agree it could be better explained ciao Stefano > > Thanks, > > —John > > [*] https://en.wikipedia.org/wiki/Duck_test > > >> On Oct 13, 2021, at 6:57 PM, Robert Raszuk > > wrote: >> >> >> Hi John, >> >> I think the crux of the matter is indeed in definition of "SRH data >> plane". So let me present my own personal understanding of it. >> >> Clearly SRH external format does not change so hardware's ability to >> read SRH remains intact. IPv6 packet's header also can be read and >> processed by network elements which have no idea about cSIDs so that >> as well is not questionable. >> >> Now your definition of data plane is sound if you consider traditional >> data planes of network elements when control plane input set's >> forwarding behaviour. >> >> Well in SRH as you know we have SIDs which inside may contain >> functions. So forwarding behavior is not pre programmed from control >> plane, but can and often is embedded in the actual packets. That is >> what real network programming is all about. And each function can have >> zoo of also nested arguments all resulting in different forwarding >> outcome. >> >> With such definition of SRH data plane I do not see anything new in >> adding few new flavours to existing behaviours or even adding new >> behaviours. >> >> Now the question is do we all see SRH data plane in the same way. >> Maybe it is way ahead of our times and classic ASIC design ? And I am >> in no way judging here if this is good or bad - I am just observing >> the facts and already published RFCs. >> >> Many thx, >> Robert >> >> PS. And I do agree with your inline comment that cSIDs should be >> possible to be used without SRH if no special functions are needed at >> each segment endpoint. >> >> On Thu, Oct 14, 2021 at 12:28 AM John Scudder > > wrote: >> >> Hi Folks, >> >> I’m struggling with the claim repeated throughout the beginning of >> draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, §1, >> §3) that “this solution does not require any SRH data plane change”. >> >> I’m not aware of a standardized formal definition of “data plane”, >> it seems to follow Justice Stewart’s maxim of “I know it when I >> see it”. However, here’s an attempt, cribbed from some Washington >> University course slides: a “local, per-router function that >> determines how a datagram arriving on a router input port is >> forwarded to a router output port”. Seems reasonable. >> >> I also am not aware of a standardized formal definition of the >> term “SRH data plane”, in fact this draft, its predecessors, some >> associated blog posts, and Clarence’s dissertation, are the only >> places a search finds the phrase (but it’s not formally defined in >> any of them). So I’m just going to assume it means the data plane, >> as applied to packets that include an SRH. (I’m not sure why we >> should disregard packets that are encoded using NEXT-C-SID that >> omit the SRH, but let’s overlook that for now.) >> >> If this solution does not require any SRH data plane change, >> presumably it would be true that if I take a packet that includes >> an SRH and place within it a series of SIDs encoded with (for >> example) the REPLACE-C-SID flavor, then that packet would be able >> to successfully traverse a network of routers that support plain >> vanilla RFC 8754. That is, it would arrive at its first hop router >> which according to a local, per-router function, would determine >> how to take the datagram arriving on the router input port and >> forward it to (the correct) router output port. Then that process >> would be repeated across the rest of the network. >> >> But that is patently incorrect: when it’s delivered to the first >> hop, the plain vanilla RFC 8754 router will be unable to apply the >> REPLACE-C-SID behavior, and forwarding to the next hop will fail. >> It seems that a different local, per-router function is required >> (in fact, the local, per-router function defined in the draft) in >> order for the forwarding to succeed. By the definitions I’m using >> here, that is exactly a data plane change. >> >> What, precisely, is then being claimed? >> >> Thanks, >> >> —John >> > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > -- ******************************************************************* Stefano Salsano Professore Associato Dipartimento Ingegneria Elettronica Universita' di Roma Tor Vergata Viale Politecnico, 1 - 00133 Roma - ITALY http://netgroup.uniroma2.it/Stefano_Salsano/ E-mail : stefano.salsano@uniroma2.it Cell. : +39 320 4307310 Office : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435 ******************************************************************* From nobody Wed Oct 13 16:57:21 2021 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 4EBD93A15ED; Wed, 13 Oct 2021 16:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=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 8FN9ZiGINEMY; Wed, 13 Oct 2021 16:57:13 -0700 (PDT) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (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 827D73A15E3; Wed, 13 Oct 2021 16:57:13 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id y4so2944522plb.0; Wed, 13 Oct 2021 16:57:13 -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=4c+X+0rTWatrPc2Fg8umLIeH1qfLwasnkTHzzwhMaHM=; b=M2G7Ge6AjG4LkaXFaVLJpYXJ1F21fr+vui7Au5j7UqyiMbbGIojkbWFmj3v7m/DxE2 SGmyCfMw7p2O8Hn+nbQk/XYXPLJgrZFwfLyu5sl/c6ox4Jk7AE9z24zoyRulJjhPV2Ss WnYvseaXOHy/ZN6uaBndBYtpwp6c+mopCih1NRd8q/pzIrZaEcwP4jS3YxE5TjEfn/pq VxOiq80V61Bd61FBt0sWtCn+QAx9bn4OjoST0QstdHzR8llok7ZlHSchIcDRdAJl17TJ G38OTJgRjzpZI94azCZUPIENQ1R4BhtRQ5SneOHA51nNhHKACygOurMJE+UoU0A41EAJ OSwQ== 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=4c+X+0rTWatrPc2Fg8umLIeH1qfLwasnkTHzzwhMaHM=; b=vrf1H010aXfqZNKTzA/mGCnnn7T2Rr71C9v5ZRfsorXRhlT0vK1niXH8JmGvlABKRx lvbH9VpOAgIFp/Kf0a3KGKtGAz78oLDuB2PW31RW82UKGxN+pk4BvEthGLPfyMwYbPTf zfvI/j3PbcZR8eb8SqY+shp0wcAWW64BM5ICEQXI+gtqK1QlG2pnkgPU0gsbOlHzNmzB 9KB4bA93HdG1SiZfC+BV/Urm7+X7BQ8QUZPc+bxxVu3hQkAQgicw5c4gswEYaxmUQj53 f0bQNrFvZlnLiiaV95gbFe+nUqXGVs/ks7P0CAayqKKcH340648tRCiTBkVGu4u50xtd VaJQ== X-Gm-Message-State: AOAM530XgU3alFlEqiJFqNX/0TJitwcwy57fOjdEF9VWuk0HBPLg2HtV Z2FCD6Q4J2rqZBkyPWvpkRQtqjgSeZ/M/PS10cU= X-Google-Smtp-Source: ABdhPJyQNmMp+4/6PW/z9R1B7DW+xeNuNSCydbL7AhMjltmzsRGpt1XfNWYAVUJt9hd+tMnUGhW6LWXVkJhTZ2XVxEQ= X-Received: by 2002:a17:902:b597:b0:13e:9ba6:fed with SMTP id a23-20020a170902b59700b0013e9ba60fedmr2134050pls.32.1634169432368; Wed, 13 Oct 2021 16:57:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Wed, 13 Oct 2021 19:57:01 -0400 Message-ID: To: John Scudder Cc: Robert Raszuk , "draft-filsfilscheng-spring-srv6-srh-compression@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="00000000000084ec9e05ce44b842" Archived-At: Subject: Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 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, 13 Oct 2021 23:57:20 -0000 --00000000000084ec9e05ce44b842 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi John CSID as it does supports SRv6 forwarding plane, it does require a change to the existing SRv6 PGM RFC 8986 to support the CSID draft new flavors. So yes definitely a software upgrade would be required. Kind Regards Gyan On Wed, Oct 13, 2021 at 7:25 PM John Scudder wrote: > Hi Robert, > > My question doesn=E2=80=99t have anything to do with =E2=80=9Cclassic ASI= C design=E2=80=9D. Indeed > if you look at the definitions I supplied they don=E2=80=99t say anything= at all > about how the router is implemented, the nature of the control plane > including whether there is one, and indeed are very broad. I would say th= ey > are general enough to encompass everything you described. > > As best I can tell, =E2=80=9Cadding new flavo[u]rs=E2=80=9D or =E2=80=9Ca= dding new behaviors=E2=80=9D is > just a different way of saying =E2=80=9Cmaking a change to the local, per= -router > function that determines how a datagram arriving on a router input port i= s > forwarded to a router output port=E2=80=9D. That is to say, by definition= it is a > change to the forwarding plane. > > I tried to motivate this with the for-instance in my fourth paragraph: ca= n > my plain-vanilla RFC 8754 network successfully forward a packet that uses > cSIDs? Or does it need new software, at the nodes identified by the SIDs > contained in the cSID, in order to supply support for the =E2=80=9Cnew fl= avor=E2=80=9D or > =E2=80=9Cnew behavior=E2=80=9D? If it needs new software, then it seems s= elf-evident to me > that it=E2=80=99s a change to the forwarding plane =E2=80=94 it =E2=80=9C= looks like a duck, swims > like a duck, and quacks like a duck=E2=80=9D.[*] > > Thanks, > > =E2=80=94John > > [*] https://en.wikipedia.org/wiki/Duck_test > > On Oct 13, 2021, at 6:57 PM, Robert Raszuk wrote: > > > Hi John, > > I think the crux of the matter is indeed in definition of "SRH data > plane". So let me present my own personal understanding of it. > > Clearly SRH external format does not change so hardware's ability to read > SRH remains intact. IPv6 packet's header also can be read and processed b= y > network elements which have no idea about cSIDs so that as well is not > questionable. > > Now your definition of data plane is sound if you consider traditional > data planes of network elements when control plane input set's forwarding > behaviour. > > Well in SRH as you know we have SIDs which inside may contain functions. > So forwarding behavior is not pre programmed from control plane, but can > and often is embedded in the actual packets. That is what real network > programming is all about. And each function can have zoo of also nested > arguments all resulting in different forwarding outcome. > > With such definition of SRH data plane I do not see anything new in addin= g > few new flavours to existing behaviours or even adding new behaviours. > > Now the question is do we all see SRH data plane in the same way. Maybe i= t > is way ahead of our times and classic ASIC design ? And I am in no way > judging here if this is good or bad - I am just observing the facts and > already published RFCs. > > Many thx, > Robert > > PS. And I do agree with your inline comment that cSIDs should be possible > to be used without SRH if no special functions are needed at each segment > endpoint. > > On Thu, Oct 14, 2021 at 12:28 AM John Scudder wrote: > >> Hi Folks, >> >> I=E2=80=99m struggling with the claim repeated throughout the beginning = of >> draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, =C2=A71, = =C2=A73) that >> =E2=80=9Cthis solution does not require any SRH data plane change=E2=80= =9D. >> >> I=E2=80=99m not aware of a standardized formal definition of =E2=80=9Cda= ta plane=E2=80=9D, it >> seems to follow Justice Stewart=E2=80=99s maxim of =E2=80=9CI know it wh= en I see it=E2=80=9D. >> However, here=E2=80=99s an attempt, cribbed from some Washington Univers= ity course >> slides: a =E2=80=9Clocal, per-router function that determines how a data= gram >> arriving on a router input port is forwarded to a router output port=E2= =80=9D. >> Seems reasonable. >> >> I also am not aware of a standardized formal definition of the term =E2= =80=9CSRH >> data plane=E2=80=9D, in fact this draft, its predecessors, some associat= ed blog >> posts, and Clarence=E2=80=99s dissertation, are the only places a search= finds the >> phrase (but it=E2=80=99s not formally defined in any of them). So I=E2= =80=99m just going to >> assume it means the data plane, as applied to packets that include an SR= H. >> (I=E2=80=99m not sure why we should disregard packets that are encoded u= sing >> NEXT-C-SID that omit the SRH, but let=E2=80=99s overlook that for now.) >> >> If this solution does not require any SRH data plane change, presumably >> it would be true that if I take a packet that includes an SRH and place >> within it a series of SIDs encoded with (for example) the REPLACE-C-SID >> flavor, then that packet would be able to successfully traverse a networ= k >> of routers that support plain vanilla RFC 8754. That is, it would arrive= at >> its first hop router which according to a local, per-router function, wo= uld >> determine how to take the datagram arriving on the router input port and >> forward it to (the correct) router output port. Then that process would = be >> repeated across the rest of the network. >> >> But that is patently incorrect: when it=E2=80=99s delivered to the first= hop, the >> plain vanilla RFC 8754 router will be unable to apply the REPLACE-C-SID >> behavior, and forwarding to the next hop will fail. It seems that a >> different local, per-router function is required (in fact, the local, >> per-router function defined in the draft) in order for the forwarding to >> succeed. By the definitions I=E2=80=99m using here, that is exactly a da= ta plane >> change. >> >> What, precisely, is then being claimed? >> >> Thanks, >> >> =E2=80=94John > > > _______________________________________________ > 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* --00000000000084ec9e05ce44b842 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi John=C2=A0

    CSID as it does supports SRv6 forwarding plane, it does require a= change to the existing SRv6 PGM RFC 8986 to support the CSID draft new fla= vors.

    So yes definitely = a software upgrade would be required.

    Kind Regards=C2=A0

    Gyan=C2=A0
    On Wed, Oct 13, 2021 at 7:25 PM John Scudder <= ;jgs=3D40juniper.net@dmarc.= ietf.org> wrote:
    Hi Robert,

    My question doesn=E2=80=99t have anything to do with =E2=80=9Cclassic = ASIC design=E2=80=9D. Indeed if you look at the definitions I supplied they= don=E2=80=99t say anything at all about how the router is implemented, the= nature of the control plane including whether there is one, and indeed are very broad. I would say they are general enough to enc= ompass everything you described.

    As best I can tell, =E2=80=9Cadding new flavo[u]rs=E2=80=9D or =E2=80= =9Cadding new behaviors=E2=80=9D is just a different way of saying =E2=80= =9Cmaking a change to the=C2=A0local, per-router function that determines h= ow a datagram arriving on a router input port is forwarded to a router=C2= =A0output port=E2=80=9D. That is to say, by definition it is a change to the forward= ing plane.

    I tried to motivate this with the for-instance in my fourth paragraph:= can my plain-vanilla RFC 8754 network successfully forward a packet that u= ses cSIDs? Or does it need new software, at the nodes identified by the SID= s contained in the cSID, in order to supply support for the =E2=80=9Cnew flavor=E2=80=9D or =E2=80= =9Cnew behavior=E2=80=9D? If it needs new software, then it seems self-evid= ent to me that it=E2=80=99s a change to the forwarding plane =E2=80=94 it = =E2=80=9Clooks like a duck, swims like a duck, and quacks like a duck=E2=80= =9D.[*]

    Thanks,

    =E2=80=94John


    On Oct 13, 2021, at 6:57 PM, Robert Raszuk <robert@raszuk.net> wrote:


    Hi John,

    I think the crux of the matter is indeed in definition of "SRH da= ta plane". So let me present my own personal understanding of it.=C2= =A0

    Clearly SRH external format does not change so hardware's ability = to read SRH remains intact. IPv6 packet's header also can be read and p= rocessed by network elements which have no idea about cSIDs so that as well= is not questionable.=C2=A0

    Now your definition of data plane is sound if you consider traditional= data planes=C2=A0of network elements when control plane input set's fo= rwarding behaviour.=C2=A0

    Well in SRH as you know we have SIDs which inside may contain function= s. So forwarding behavior is not pre programmed from control plane, but can= and often is embedded in the actual packets. That is what real network pro= gramming is all about. And each function=C2=A0can have zoo of also nested arguments all resulting= in different forwarding outcome.=C2=A0

    With such definition of SRH data plane I do not see anything new in ad= ding few new flavours to existing behaviours or even adding new behaviours.= =C2=A0

    Now the question is do we all see SRH data plane in the same way. Mayb= e it is way ahead of our times and classic ASIC design ? And I am in no way= judging=C2=A0here if this is good or bad - I am just observing the facts a= nd already published=C2=A0RFCs.=C2=A0

    Many thx,
    Robert

    PS. And I do agree with your=C2=A0inline comment that cSIDs should be = possible to be used without SRH if no=C2=A0special=C2=A0functions are neede= d=C2=A0at each segment endpoint.=C2=A0

    On Thu, Oct 14, 2021 at 12:28 AM John= Scudder <jgs@junip= er.net> wrote:
    Hi Folks,

    I=E2=80=99m struggling with the claim repeated throughout the beginning of = draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, =C2=A71, =C2= =A73) that =E2=80=9Cthis solution does not require any SRH data plane chang= e=E2=80=9D.

    I=E2=80=99m not aware of a standardized formal definition of =E2=80=9Cdata = plane=E2=80=9D, it seems to follow Justice Stewart=E2=80=99s maxim of =E2= =80=9CI know it when I see it=E2=80=9D. However, here=E2=80=99s an attempt,= cribbed from some Washington University course slides: a =E2=80=9Clocal, p= er-router function that determines how a datagram arriving on a router input port is forwarded to = a router output port=E2=80=9D. Seems reasonable.

    I also am not aware of a standardized formal definition of the term =E2=80= =9CSRH data plane=E2=80=9D, in fact this draft, its predecessors, some asso= ciated blog posts, and Clarence=E2=80=99s dissertation, are the only places= a search finds the phrase (but it=E2=80=99s not formally defined in any of them). So I=E2=80=99m just going to assume it means the data pla= ne, as applied to packets that include an SRH. (I=E2=80=99m not sure why we= should disregard packets that are encoded using NEXT-C-SID that omit the S= RH, but let=E2=80=99s overlook that for now.)

    If this solution does not require any SRH data plane change, presumably it = would be true that if I take a packet that includes an SRH and place within= it a series of SIDs encoded with (for example) the REPLACE-C-SID flavor, t= hen that packet would be able to successfully traverse a network of routers that support plain vanilla RFC = 8754. That is, it would arrive at its first hop router which according to a= local, per-router function, would determine how to take the datagram arriv= ing on the router input port and forward it to (the correct) router output port. Then that process would be= repeated across the rest of the network.

    But that is patently incorrect: when it=E2=80=99s delivered to the first ho= p, the plain vanilla RFC 8754 router will be unable to apply the REPLACE-C-= SID behavior, and forwarding to the next hop will fail. It seems that a dif= ferent local, per-router function is required (in fact, the local, per-router function defined in the draft) in order fo= r the forwarding to succeed. By the definitions I=E2=80=99m using here, tha= t is exactly a data plane change.

    What, precisely, is then being claimed?

    Thanks,

    =E2=80=94John

    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --
    --00000000000084ec9e05ce44b842-- From nobody Wed Oct 13 18:23:03 2021 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 A48C23A16F0; Wed, 13 Oct 2021 18:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yaXaD9jRKNCz; Wed, 13 Oct 2021 18:22:56 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 2BF0B3A16EB; Wed, 13 Oct 2021 18:22:56 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id w19so17846482edd.2; Wed, 13 Oct 2021 18: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=juxCjGvSepLSEAkHsFRGVhp8Yv7O4F5+rvt9AbkRiX0=; b=hym0ujbPUj5Mg/MRKo0j5UYlrheLU2qH50arOXSTkYGmGHIA/Cio6E5nob15EJvZfc EoVmjOx8s/+ke4EMBUz9FHHpv3qaJzCJsaRvMRX5fR/H9T5hTuYKl3LkElIguB3ZFNfM pGbynN+TJ5L6sH/po0krUZ9czvLN3N+mkIvXmje2Nw722gDSMHhKFGjf72XgRnpkoPPf +JSlyn2G//j917UI3v6pH/0PhBP7DEt+/KvjEkMpxLgv1WKj6n4n3m4UFnh08B1bHvQb cueVFCRzuPoEGzlCcQ58xvQJz2yIgH3eRszYLCHyyTBH7lzL3HG4aSSaKSmUEnWfTTUx j71g== 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=juxCjGvSepLSEAkHsFRGVhp8Yv7O4F5+rvt9AbkRiX0=; b=g0oBB2H+eAZjPWqoPY40IWkyCll6mbhwVeaIjdhncecE++KEEdaXTFt8k6JooVB1Om 0o6jEz0RBrhgp/Zc3zJC3FKWaAC7PYnilYXKPfNxCkMsGRJXdFdFIKdcL3yR2xaYGndM pNXtZY4RDA0vbueBWOcY+vNvCT9q+TQLtQrHhHkDWJYCANHOm5YlwNzHd4YLY/MtqjzM O6voVvgt2Ghss+aVicDgyyHm2gOMlCKXIYSvCe42Nh8jsWAJOVb4D7ecrAkfldWsPA3Z F53Erg16812baRf0D6fKVNNjKWPVxGI5HnCzFOk2Q+uYdqcrIeixPZDi1j9rGl075cf3 H41g== X-Gm-Message-State: AOAM533BO0AYXn5cq4R1+skLNnskfFhlNx99zZWAnkF5zjlG/oy7+hce 22dxCaSuQhGfmru9+/SNud3wl9ghLeUtZU/rTYc= X-Google-Smtp-Source: ABdhPJwt8TFcuP0KwF0ktVOYx7sOQw94JHWROrF54K3akkkEuKyGTLf72RVREpeOLr6YwVd1O1lT8qt9//djGJFeAgM= X-Received: by 2002:a17:906:6a2a:: with SMTP id qw42mr216252ejc.561.1634174574411; Wed, 13 Oct 2021 18:22:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Wed, 13 Oct 2021 18:22:43 -0700 Message-ID: To: John Scudder Cc: "draft-filsfilscheng-spring-srv6-srh-compression@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="00000000000002440305ce45ebb3" Archived-At: Subject: Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 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, 14 Oct 2021 01:23:01 -0000 --00000000000002440305ce45ebb3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi John, thank you for equipping your question with the definition of the data plane. That helps a lot. I agree with Gyan that as the local function processing the SID encoding in an SRH container must change, so the only conclusion we can make is that the data plane that supports C-SID is different from the one that only supports RFC 8754. Regards, Greg On Wed, Oct 13, 2021 at 3:29 PM John Scudder wrote: > Hi Folks, > > I=E2=80=99m struggling with the claim repeated throughout the beginning o= f > draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, =C2=A71, = =C2=A73) that > =E2=80=9Cthis solution does not require any SRH data plane change=E2=80= =9D. > > I=E2=80=99m not aware of a standardized formal definition of =E2=80=9Cdat= a plane=E2=80=9D, it > seems to follow Justice Stewart=E2=80=99s maxim of =E2=80=9CI know it whe= n I see it=E2=80=9D. > However, here=E2=80=99s an attempt, cribbed from some Washington Universi= ty course > slides: a =E2=80=9Clocal, per-router function that determines how a datag= ram > arriving on a router input port is forwarded to a router output port=E2= =80=9D. > Seems reasonable. > > I also am not aware of a standardized formal definition of the term =E2= =80=9CSRH > data plane=E2=80=9D, in fact this draft, its predecessors, some associate= d blog > posts, and Clarence=E2=80=99s dissertation, are the only places a search = finds the > phrase (but it=E2=80=99s not formally defined in any of them). So I=E2=80= =99m just going to > assume it means the data plane, as applied to packets that include an SRH= . > (I=E2=80=99m not sure why we should disregard packets that are encoded us= ing > NEXT-C-SID that omit the SRH, but let=E2=80=99s overlook that for now.) > > If this solution does not require any SRH data plane change, presumably i= t > would be true that if I take a packet that includes an SRH and place with= in > it a series of SIDs encoded with (for example) the REPLACE-C-SID flavor, > then that packet would be able to successfully traverse a network of > routers that support plain vanilla RFC 8754. That is, it would arrive at > its first hop router which according to a local, per-router function, wou= ld > determine how to take the datagram arriving on the router input port and > forward it to (the correct) router output port. Then that process would b= e > repeated across the rest of the network. > > But that is patently incorrect: when it=E2=80=99s delivered to the first = hop, the > plain vanilla RFC 8754 router will be unable to apply the REPLACE-C-SID > behavior, and forwarding to the next hop will fail. It seems that a > different local, per-router function is required (in fact, the local, > per-router function defined in the draft) in order for the forwarding to > succeed. By the definitions I=E2=80=99m using here, that is exactly a dat= a plane > change. > > What, precisely, is then being claimed? > > Thanks, > > =E2=80=94John > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --00000000000002440305ce45ebb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi John,
    thank you for equipping your question with th= e definition=C2=A0of the data plane. That helps a lot. I agree with Gyan th= at as the local function processing the SID encoding in an SRH container mu= st change, so the only conclusion we can make is that the data plane that s= upports C-SID is different from the one that only supports RFC 8754.
    <= div>
    Regards,
    Greg

    On Wed, Oct 13, 2021 at 3:2= 9 PM John Scudder <jgs=3D40juniper.net@dmarc.ietf.org> wrote:
    Hi Folks,

    I=E2=80=99m struggling with the claim repeated throughout the beginning of = draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, =C2=A71, =C2= =A73) that =E2=80=9Cthis solution does not require any SRH data plane chang= e=E2=80=9D.

    I=E2=80=99m not aware of a standardized formal definition of =E2=80=9Cdata = plane=E2=80=9D, it seems to follow Justice Stewart=E2=80=99s maxim of =E2= =80=9CI know it when I see it=E2=80=9D. However, here=E2=80=99s an attempt,= cribbed from some Washington University course slides: a =E2=80=9Clocal, p= er-router function that determines how a datagram arriving on a router inpu= t port is forwarded to a router output port=E2=80=9D. Seems reasonable.

    I also am not aware of a standardized formal definition of the term =E2=80= =9CSRH data plane=E2=80=9D, in fact this draft, its predecessors, some asso= ciated blog posts, and Clarence=E2=80=99s dissertation, are the only places= a search finds the phrase (but it=E2=80=99s not formally defined in any of= them). So I=E2=80=99m just going to assume it means the data plane, as app= lied to packets that include an SRH. (I=E2=80=99m not sure why we should di= sregard packets that are encoded using NEXT-C-SID that omit the SRH, but le= t=E2=80=99s overlook that for now.)

    If this solution does not require any SRH data plane change, presumably it = would be true that if I take a packet that includes an SRH and place within= it a series of SIDs encoded with (for example) the REPLACE-C-SID flavor, t= hen that packet would be able to successfully traverse a network of routers= that support plain vanilla RFC 8754. That is, it would arrive at its first= hop router which according to a local, per-router function, would determin= e how to take the datagram arriving on the router input port and forward it= to (the correct) router output port. Then that process would be repeated a= cross the rest of the network.

    But that is patently incorrect: when it=E2=80=99s delivered to the first ho= p, the plain vanilla RFC 8754 router will be unable to apply the REPLACE-C-= SID behavior, and forwarding to the next hop will fail. It seems that a dif= ferent local, per-router function is required (in fact, the local, per-rout= er function defined in the draft) in order for the forwarding to succeed. B= y the definitions I=E2=80=99m using here, that is exactly a data plane chan= ge.

    What, precisely, is then being claimed?

    Thanks,

    =E2=80=94John
    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --00000000000002440305ce45ebb3-- From nobody Wed Oct 13 18:36:15 2021 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 D8F8E3A1752; Wed, 13 Oct 2021 18:36:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=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 Y8oGPyRjRhzt; Wed, 13 Oct 2021 18:36:08 -0700 (PDT) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (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 576433A1755; Wed, 13 Oct 2021 18:36:08 -0700 (PDT) Received: by mail-pg1-x534.google.com with SMTP id s136so776109pgs.4; Wed, 13 Oct 2021 18:36: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=a45c3T4Ftdbqm33/bkbXsYZB2b6byCvgVvsFAjGgpnI=; b=cM7QBe7cG+8ffPVsGGVjQMzSOGFV7FB9bPzOeVbZWOdi/FzsqRPyY8MY0YjIqGKaHR nobzMPm0N3AhoN04UV6YdPo/brPrXBGTNmrU9+e6qIh4KG4ZWrG7RrMucU1Yz8pRyC2R rpG4RxyG+JbHRAsDvfi3ISR5Ux0yTXE0QLoixKORCX594nKgp6KhpgqNqHUR6cB/xrUh jJ3q8vqIYtnEAm0+8JfkWyzp6ss3jjfs4J2TcOqfY0Kl9z+CCG2T78niCChK8vrVhoVv EAJQJl88fHd85yfiCg5WRYUsij/e5xCuGf/AhdrLgEbpm4FMgoij+f0jABKWGPZZGRL9 iG+Q== 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=a45c3T4Ftdbqm33/bkbXsYZB2b6byCvgVvsFAjGgpnI=; b=Ukq/y8E/Oi2TTYlG9sgyexWHFiN5S6H6UhmtmeVKqxmeg5vav78HjTBhUJvM967J9T hFgXauBE9Ymnpz1G4eOyl38AAjuILSCVsHAL6y+79A7HJCcPMAE+7DHgQPh5hoCJTMa2 ukSxA/aURxifcSk6J6jOcmB/qbP/Ya01HwImKbCwBK16OBy1IOwYUzo1qEMbxurG57xX Nm9HMFaGsgffYko1X2EFvcwnw/yGF+iuxmKX/52gkFtfVwsBpPUgfTeJWxOQWEArOX39 rhq+YqzqML/pufVltzM1ZQbGKxrAYcCgKaoy4Zw1MIkMDNuHfPM33WQZrqbfwgszKVxY ICQg== X-Gm-Message-State: AOAM532TspkaEMw3bGvYIXQjs3hSzYBNM/iuSjI5Sjtv7ibCzmRwixBg qcK0mYTPd6kYGiBds5KCPCompI8vAavEZeR7WQg= X-Google-Smtp-Source: ABdhPJyUzpcC2SAssRgKRZ61agAeajKZiKVyUP/4T44QT1ZuHLzWFGEAVK8eGTQZVui4WUBhpu0+YU14K4whI2B0EX0= X-Received: by 2002:a62:1995:0:b0:44c:728e:323b with SMTP id 143-20020a621995000000b0044c728e323bmr2816164pfz.54.1634175362431; Wed, 13 Oct 2021 18:36:02 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Wed, 13 Oct 2021 21:35:51 -0400 Message-ID: To: Greg Mirsky Cc: John Scudder , "draft-filsfilscheng-spring-srv6-srh-compression@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000fa7e9605ce461929" Archived-At: Subject: Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 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, 14 Oct 2021 01:36:13 -0000 --000000000000fa7e9605ce461929 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi John Greg made an excellent point that as SRv6 uses the IPv6 data plane and as IPv6 extended header routing header SRH RH type 4 is in fact part of the =E2=80=9Cdata plane=E2=80=9D. So as CSID containerization of the 128 bit SID entry in the SRH header RFC 8754, CSID is in fact a change of not only the SRV6 forwarding plane RFC 8986 as well as IPv6 data plane SRH RFC 8754. Many Thanks Gyan On Wed, Oct 13, 2021 at 9:23 PM Greg Mirsky wrote: > Hi John, > thank you for equipping your question with the definition of the data > plane. That helps a lot. I agree with Gyan that as the local function > processing the SID encoding in an SRH container must change, so the only > conclusion we can make is that the data plane that supports C-SID is > different from the one that only supports RFC 8754. > > Regards, > Greg > > On Wed, Oct 13, 2021 at 3:29 PM John Scudder 40juniper.net@dmarc.ietf.org> wrote: > >> Hi Folks, >> >> I=E2=80=99m struggling with the claim repeated throughout the beginning = of >> draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, =C2=A71, = =C2=A73) that >> =E2=80=9Cthis solution does not require any SRH data plane change=E2=80= =9D. >> >> I=E2=80=99m not aware of a standardized formal definition of =E2=80=9Cda= ta plane=E2=80=9D, it >> seems to follow Justice Stewart=E2=80=99s maxim of =E2=80=9CI know it wh= en I see it=E2=80=9D. >> However, here=E2=80=99s an attempt, cribbed from some Washington Univers= ity course >> slides: a =E2=80=9Clocal, per-router function that determines how a data= gram >> arriving on a router input port is forwarded to a router output port=E2= =80=9D. >> Seems reasonable. >> >> I also am not aware of a standardized formal definition of the term =E2= =80=9CSRH >> data plane=E2=80=9D, in fact this draft, its predecessors, some associat= ed blog >> posts, and Clarence=E2=80=99s dissertation, are the only places a search= finds the >> phrase (but it=E2=80=99s not formally defined in any of them). So I=E2= =80=99m just going to >> assume it means the data plane, as applied to packets that include an SR= H. >> (I=E2=80=99m not sure why we should disregard packets that are encoded u= sing >> NEXT-C-SID that omit the SRH, but let=E2=80=99s overlook that for now.) >> >> If this solution does not require any SRH data plane change, presumably >> it would be true that if I take a packet that includes an SRH and place >> within it a series of SIDs encoded with (for example) the REPLACE-C-SID >> flavor, then that packet would be able to successfully traverse a networ= k >> of routers that support plain vanilla RFC 8754. That is, it would arrive= at >> its first hop router which according to a local, per-router function, wo= uld >> determine how to take the datagram arriving on the router input port and >> forward it to (the correct) router output port. Then that process would = be >> repeated across the rest of the network. >> >> But that is patently incorrect: when it=E2=80=99s delivered to the first= hop, the >> plain vanilla RFC 8754 router will be unable to apply the REPLACE-C-SID >> behavior, and forwarding to the next hop will fail. It seems that a >> different local, per-router function is required (in fact, the local, >> per-router function defined in the draft) in order for the forwarding to >> succeed. By the definitions I=E2=80=99m using here, that is exactly a da= ta plane >> change. >> >> What, precisely, is then being claimed? >> >> Thanks, >> >> =E2=80=94John >> _______________________________________________ >> 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* --000000000000fa7e9605ce461929 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Hi John

    <= div dir=3D"auto">Greg made an excellent point that as SRv6 uses the IPv6 da= ta plane and as IPv6 extended header routing header SRH RH =C2=A0type 4 is = in fact part of the =E2=80=9Cdata plane=E2=80=9D. =C2=A0

    So as CSID containerization of the 128 bit= SID entry in the SRH header RFC 8754, CSID is in fact a change of not only= the SRV6 forwarding plane RFC 8986 as well as IPv6 data plane SRH RFC 8754= .

    Many Thanks=C2=A0

    Gyan=C2=A0
    On Wed, Oct= 13, 2021 at 9:23 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
    Hi John,
    thank you for equipping your question with the defini= tion=C2=A0of the data plane. That helps a lot. I agree with Gyan that as th= e local function processing the SID encoding in an SRH container must chang= e, so the only conclusion we can make is that the data plane that supports = C-SID is different from the one that only supports RFC 8754.

    =
    Regards,
    Greg

    On Wed, Oct 13, 2021 at 3:29 PM Joh= n Scudder <jgs=3D40juniper.net@dmarc.ietf.org> wrote:
    Hi Folks,

    I=E2=80=99m struggling with the claim repeated throughout the beginning of = draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, =C2=A71, =C2= =A73) that =E2=80=9Cthis solution does not require any SRH data plane chang= e=E2=80=9D.

    I=E2=80=99m not aware of a standardized formal definition of =E2=80=9Cdata = plane=E2=80=9D, it seems to follow Justice Stewart=E2=80=99s maxim of =E2= =80=9CI know it when I see it=E2=80=9D. However, here=E2=80=99s an attempt,= cribbed from some Washington University course slides: a =E2=80=9Clocal, p= er-router function that determines how a datagram arriving on a router inpu= t port is forwarded to a router output port=E2=80=9D. Seems reasonable.

    I also am not aware of a standardized formal definition of the term =E2=80= =9CSRH data plane=E2=80=9D, in fact this draft, its predecessors, some asso= ciated blog posts, and Clarence=E2=80=99s dissertation, are the only places= a search finds the phrase (but it=E2=80=99s not formally defined in any of= them). So I=E2=80=99m just going to assume it means the data plane, as app= lied to packets that include an SRH. (I=E2=80=99m not sure why we should di= sregard packets that are encoded using NEXT-C-SID that omit the SRH, but le= t=E2=80=99s overlook that for now.)

    If this solution does not require any SRH data plane change, presumably it = would be true that if I take a packet that includes an SRH and place within= it a series of SIDs encoded with (for example) the REPLACE-C-SID flavor, t= hen that packet would be able to successfully traverse a network of routers= that support plain vanilla RFC 8754. That is, it would arrive at its first= hop router which according to a local, per-router function, would determin= e how to take the datagram arriving on the router input port and forward it= to (the correct) router output port. Then that process would be repeated a= cross the rest of the network.

    But that is patently incorrect: when it=E2=80=99s delivered to the first ho= p, the plain vanilla RFC 8754 router will be unable to apply the REPLACE-C-= SID behavior, and forwarding to the next hop will fail. It seems that a dif= ferent local, per-router function is required (in fact, the local, per-rout= er function defined in the draft) in order for the forwarding to succeed. B= y the definitions I=E2=80=99m using here, that is exactly a data plane chan= ge.

    What, precisely, is then being claimed?

    Thanks,

    =E2=80=94John
    _______________________________________________
    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
    --
    --000000000000fa7e9605ce461929-- From nobody Wed Oct 13 22:09:36 2021 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 2A25D3A12FF; Wed, 13 Oct 2021 22:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=O08Km0em; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=k5aHItrG 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 xvIvZj3L2Dvh; Wed, 13 Oct 2021 22:09:27 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35A5D3A12FD; Wed, 13 Oct 2021 22:09:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20572; q=dns/txt; s=iport; t=1634188167; x=1635397767; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=1v/AtXnaaQjohMQl+8Cchj2AE7Um9ZGB8TTx6mPiBiY=; b=O08Km0emoy4uU6+j2gD87WGfbzP1FK4vw4kf4qL0ZgYmoMbd+PgzV/5o X30pEcZYQqa4Zb7695mhyox7Jz4rXXGP8OATzs70kXO+TXvhqbT/QZKqW /ChF/2FiC2uTJyzGpUcSlrXueftfytPhioBWcoaZNNyJZuL0cGfrsKWRd A=; IronPort-PHdr: =?us-ascii?q?A9a23=3ASUOxcx8mOdDxzP9uWMfoyV9kXcBvk7vpIhMP5?= =?us-ascii?q?4UqivRFdaHwt5jhPUmK4/JrgReJWIjA8PtLhqLQtLyoQm0P55uN8RVgOJxBX?= =?us-ascii?q?hMIk4MaygonBsPWB1DnMeTncCE7Ws9FUQwt83SyK0MAHsH4ahXbqWGz6jhHH?= =?us-ascii?q?BL5OEJ1K+35F5SUgd6w0rW5+obYZENDgz/uCY4=3D?= IronPort-Data: =?us-ascii?q?A9a23=3AS2eBk6pJ7trN8/k8N8zfBDVr6TReBmLNZxIvg?= =?us-ascii?q?KrLsJaIsI4StFCztgarIBnXM/uDa2TxfYglbN7k9B8B75/Rm4I3SQFopSBgE?= =?us-ascii?q?CIa9uPIVI+TRqvS04x+DSFioHqKZKzyU/GYRCwPZiKa9krF3oTJ9yEmjPjQH?= =?us-ascii?q?+GkU4YoBwgoLeNaYHZ54f5cs7ZRbr5A2bBVMivV0T/Ai5S31GyNg1aYBlkpB?= =?us-ascii?q?5er83uDihhdVAQw5TTSbdgT1LPXeuJ84Jg3fcldJFOgKmVY83LTegrN8F251?= =?us-ascii?q?juxExYFENiplPPwdVcHB+WUNgmVgX0QUK+n6vRAjnVtieBga7xNMgEO1mnhc?= =?us-ascii?q?9NZkL2hsbSyQAIrP6TKl8wWUgJTFGd1OqguFLrvcCTh6ZPCnxKaG5fr67A0Z?= =?us-ascii?q?K0sBqUD4vx2B24L/vwRKSoWRhGOm+zwx6i0IsF3nt4iKsbDPY4DtDdn1z6xJ?= =?us-ascii?q?fQvRJ3YBaOM6sJZ1zc5nMxmE+vCetAUdjduKh/HZnVy1v0/YH4ltP2jin+6e?= =?us-ascii?q?DpCpRfO46E2+GPUigd21dDQ3BPuUoTiba1ocoyw/AoqJ1jEPyw=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AL1dkMqCzoRGMRLPlHegOsceALOsnbusQ8z?= =?us-ascii?q?AXPh9KKCC9I/b3qynxppsmPEfP+UkssHFJo6HmBEDyewKjyXcV2/hRAV7GZm?= =?us-ascii?q?nbUQSTXfpfBOfZsljd8mjFh5JgPMRbAuhD4b/LfCJHZK/BiWHSebtNsbr3kp?= =?us-ascii?q?xAx92uskuFJjsaDZ2Imj0JcjpzZXcGPTWua6BJcKa0145inX6NaH4XZsO0Cj?= =?us-ascii?q?0uRO7YveDGk5rgfFovGwMnwBPmt0Lq1JfKVzyjmjsOWTJGxrkvtULflRbi26?= =?us-ascii?q?mlu/anjjfBym7o6YhMkteJ8KoAOCXMsLlRFtzfsHfuWG1TYczFgNnzmpD31L?= =?us-ascii?q?8eqqiJn/7nBbUq15qeRBDvnfKn4XiQ7N9n0Q6T9bbfuwq4nSQ8LwhKV/aoQu?= =?us-ascii?q?liA0bkAgMbzaJB+bMO0GSDu5VNCxTc2Cz7+tjTThlv0lG5uHw4jIco/jFiuK?= =?us-ascii?q?YlGfRsRLYkjQlo+VY7bVXHwZFiFPMrANDX5f5Qf1/fZ3fFvnN3yNjpWngoBB?= =?us-ascii?q?+JTkULp8TQilFt7T9E5lpdwNZakmYL9Zo7RZUB7+PYMr5wnLULSsMNd6pyCO?= =?us-ascii?q?oIXMPyAG3QRhDHNn6UPD3cZe06EmOIr4Sy7KQ+5emsdpBNxJwumI7ZWFcdrm?= =?us-ascii?q?I2c1KGM7zH4HSKyGGFfIyZZ0Wi9ihz3ekNhlTMfsucDcTYciFdryKJmYRqPv?= =?us-ascii?q?Hm?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AQAgA0u2dh/5pdJa1aHQEBAQEJARI?= =?us-ascii?q?BBQUBgggFAQsBgSAwIy4Hd1o3MYRHg0cDhTmIC5VrhQiBQoERA1QLAQEBDQE?= =?us-ascii?q?BNwoEAQGEfgIXgjICJTcGDgECBAEBARIBAQUBAQECAQYEgREThTsIJQ2GQwI?= =?us-ascii?q?BAxILBgoTAQEsCwEPAgEGPQcCAgIwGgsBAQQBDQUIEweCUIF+VwMvAQ6QO48?= =?us-ascii?q?2AYE6AoofeoExgQGCCAEBBgQEgUpBgn8YgjUDBoE6AYMDhBIBAYJUhB8nHIF?= =?us-ascii?q?JRIEVQ4MlgmMCA4EjBQESASMrgms3ggwii0QvQmQEGzggAlkWgQIqERAZkTB?= =?us-ascii?q?SBYMOiH6NTpIrCoMwikaREoMyFINqi2yXQYU9gVaOdR+MTZh7AgQCBAUCDgE?= =?us-ascii?q?BBjWBQiVpcHAVO4JpURkPgz6KYgwWFRmDIoUUhUp0OAIGAQoBAQMJAZMfAQE?= X-IronPort-AV: E=Sophos;i="5.85,371,1624320000"; d="scan'208,217";a="946079874" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Oct 2021 05:09:25 +0000 Received: from mail.cisco.com (xbe-rcd-005.cisco.com [173.37.102.20]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 19E59PeQ002325 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 14 Oct 2021 05:09:25 GMT Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xbe-rcd-005.cisco.com (173.37.102.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 14 Oct 2021 00:09:25 -0500 Received: from xfe-aln-005.cisco.com (173.37.135.125) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 14 Oct 2021 00:09:25 -0500 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Thu, 14 Oct 2021 00:09:25 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XMWyfLJGLr0tLlL+qZvFprrSolbCnJVWIER0IJaoaNLqFR8wfl5fX+/14Npe+Au9bz0DNxvzoDTM1BRAlhr3EIsngFAhdgj9MU/TjwOu8x1xcHnee/4QUr4Ghd3hAuO07wltWutZWOY4FzeNC73Odz3CBwO2t53k5rS1B7eEMgECxy8ePtMYOWGGXOCUV4oxA3uWFBx6WWr+m40pFeMzXHb57c8fFfQ6xve/8x4z09bSXJvbC2W4TC6pDMCQq5eUHSK3Mxppg10PnIHLytDkImPpwCAtgV0thk8ibF+QkCWvY/66/CsDhBPbCyY5Nag4g1sP+i1BHjoMV3G4TyCKBQ== 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=1v/AtXnaaQjohMQl+8Cchj2AE7Um9ZGB8TTx6mPiBiY=; b=kT0f6kR17DB8fpKLYZBdT1uU+hCCBJJpqUmJ9+521PxBjTHXFipiLR1wiI8uJTNQOOuAlV0FT7GrsCg3GXRb0gREiP1HlOfeZLBjPdm30mrKpGbEtfCW4yEIFXyuIq68dq5f5ayo73mMV+B3cD56fgvQa7v+tuy+blaQ1t1hyI1hxIW1ozxghUfOLrgmRlatVF0zGeXIwM10oanKg3fiCDK2rsAJFJBn9CeMP+eqxmAouVTFXrI+q3PkDSsR/tPpGTJUFpqY/zEABBYBDOmkTQjTlOdCT/oXqe8K8YtmAkUQ7Im9s+pM5c+uwXVaXW3x0sImmWpnFNassYF+Bu2rQg== 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=1v/AtXnaaQjohMQl+8Cchj2AE7Um9ZGB8TTx6mPiBiY=; b=k5aHItrGEYbtai+jSaZbdQz3BjxcgMiRiZwJWj7a5d5QBO9dFDqLayM8mHZDN5jAfhVlF4UVsxG3pY26/QhSx5m/+cCLTmc53c3X6Z02lWlMw20mub3Orh+HwipcHHF8PqZX+eIA3xgd/N/X21Nca7QnLSpKvCGphzxaBj3rhUA= Received: from SA2PR11MB5033.namprd11.prod.outlook.com (2603:10b6:806:115::12) by SA2PR11MB4842.namprd11.prod.outlook.com (2603:10b6:806:f8::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.20; Thu, 14 Oct 2021 05:09:23 +0000 Received: from SA2PR11MB5033.namprd11.prod.outlook.com ([fe80::25a6:3d0a:5ab3:76eb]) by SA2PR11MB5033.namprd11.prod.outlook.com ([fe80::25a6:3d0a:5ab3:76eb%7]) with mapi id 15.20.4608.016; Thu, 14 Oct 2021 05:09:23 +0000 From: "Xing James Jiang (jamjiang)" To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQJ67/wA Date: Thu, 14 Oct 2021 05:09:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1e60614c-4416-4adf-02fb-08d98ed0c9c9 x-ms-traffictypediagnostic: SA2PR11MB4842: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: OVc3dzoWQ9b0b/mfEND5JCCQBB+sOSBw3MW/BxowV/4bA1qthd3Dupv6eUixnYBOW2wb3K5nCwLl5PmHoNcSk0rrWXTCjYfCzUC+ahIWwpf54yvAxcYP7ul01V/CzJ8yGCXex8mJYtT02nkIoaNh6gN7wVOFW8sHC8E9a0S5a1lk2gqZEOToneHVuuxw1d5q58zanUtcFYQ11SEa0S1iOoFk4Z0rVLmJ0aDkksaSyjFHiAovNOlNDO71wxbIRZAOmQYpH8lZ3fD83UalCW40cKNO2VCgDWsl1oriS7IvwconirtoVx6nIx/18ueBha92ZEpY5PS+HjaSpwRxEKoHWXmFnGarAw4Bst8ieOgg6HyVLws3QPW45uLb6tPkSZk9EitQOahZkwhjzjLANmfQtwsjQvhE/sWqGTYmYaxiYNACbOf7ppZC8iblhBu7qpzsr0hxsGHInN/2CPhfuYar3K6TR/zOqPeN+1E2isE6h63Q5WOOvulJCfUsWtCUx/qdlMAfCmyIne22XfXv1r4aBe9f3EUDA8dgQhkxFFq98TOvWCFOXfLa6qntX3xmjhC7Z9voVQOpcBisMdwX94LbWkk+oydogjkstIdu1rw4Faw+oDXAiUS77Glrpyin0mxk+Lx60k6QErpU/Err1llChdMi8CQq9L/0xehcbo7zd7aRZ1kFL1G14BEb13SNURMEQrTCsAm2gLjsTJl2N9ZCm+Ci2iuKQqHOeC4XnEHiFpZJX6PPB1/17moUUxQfXKWLe4C2Po+h4fs+nJOoK4c1BkzUZ/44JxSAAgr8M3u8MGo= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SA2PR11MB5033.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(110136005)(316002)(66556008)(5660300002)(71200400001)(52536014)(9686003)(55016002)(66946007)(7696005)(6506007)(66476007)(76116006)(186003)(64756008)(66446008)(966005)(166002)(4326008)(38070700005)(26005)(2906002)(38100700002)(33656002)(83380400001)(86362001)(8936002)(224303003)(122000001)(508600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?ZlVCMDZFSVRIRitRRTZNVzVJV1ZlNGFHNktlRDRsNy9RZWh6cjY2b0FqOXlS?= =?utf-8?B?cEtwNW1Ob1Zmb3E3a2NqeHFiT1dlK0Jvbk4weEdiZS9NbkVVMnlNaUF1RGtm?= =?utf-8?B?cTY2TUVLejlVZmUvbG1hbG1DWkFtWFZBQVBDTW04OHVPOGJadnlPb2dpVGJl?= =?utf-8?B?SlJFVXpJcDRJZ1Btczl0K1BBTVViODJoaExXS3RWOXlOQXFEbDJYNkRWTTY3?= =?utf-8?B?a1VPTUtSR2UyN21CN25peXVHR2Z6RHNuNk9nbnhmWWFPRG1ieTdPNlFNK3F6?= =?utf-8?B?T1FObkJvMTh1VkJYNTM3dzE4QUdScHI4bmxpSFE1MG1rRUFqc3M5aEdpMjBL?= =?utf-8?B?b0Rla096WjFSN0QxMkw4UktJZzkrbm4vOVNyNFRUZy9ncFY4SHRTbCtCYkd1?= =?utf-8?B?NDl5YTlxVVl5NWUzcFdkUkoyQlNlcFBzRkJtWmhBcG1nK0M0ZzhiVUdyMm92?= =?utf-8?B?S3pmckZIUU1Vemp3Wjh5VjFrMFVTMk9ub3pWOWxiNW1JMjhOU2VRWmt0YTNH?= =?utf-8?B?L3REdVFWeUZCcHZOVHRYZmtPTzR0QXhyaFo2Y3Bib2V6TnJpWExJUFdINzZm?= =?utf-8?B?TVhtQlRnNHN4Wks5S1JYWjBtLzVaQllqUVJCRGNiODcvNkM4cEJQRXI5MHN2?= =?utf-8?B?Qko5SFc0QUlXQTBDVlVKYXY2YjBldkFpVVJvSUNydTVqNk02NmNMSlU1TnBn?= =?utf-8?B?VnVyR3lkWURPWWM2TGxBVm45dkZmVEpyRGE2RFBDVU1PY1hsV2VrNTFRTDdh?= =?utf-8?B?SzR4ZmlqelBYOGNtdW9lT0thUjQ2NldhOS9KYjVoVG0xU0pqa0RIRHBPL3JU?= =?utf-8?B?RStkYXBGUmZURVpCTVZXWi95QmFRRTdxaCtmcVZTU0FGQlVNWW9kak1ZOStz?= =?utf-8?B?UlV6K2kvSkRMVEZrN0t3RVNhYXZSYURXL245YlJ4cWNnQmZ0MnR3bVpiRHpl?= =?utf-8?B?VDRJUnpueVR5VWxNVVhVdXN4SjVjMnZZUVZYRzY3ZnVmcklYa1d3d0hPY2hx?= =?utf-8?B?L2dLU0xiWGhHOWRDRU0yNHplaWNqanRXRXFKNGQvbUZ1RXBQT04zeG9tZU9O?= =?utf-8?B?ZEJyZFZLUmZiNjNsZVVnZEFCalhmTGVKRlpZeENtL1BFYUw3QzlPaGc0U1BZ?= =?utf-8?B?a0VCSEhONlBGbHdONmkzQmQwNWNLMnhvWUo1ZDRTSDFBaHdYRFVMdzMxbTVS?= =?utf-8?B?Qm01NC85NFhseVU0Nk9nQUYxMit1QmxleWZhMnJpdlh5OGE4YWplWHVWSmVn?= =?utf-8?B?aERFalFJOE8raGRvd0tVOFpWTCtaV2xZYzhtSUplNG13ZmE3OFRVNjIwdXBU?= =?utf-8?B?U1QxYTEwSU8zaUlxQWRHYjMwcmFBcXI5WjBZeXVDUVorOGs0U3ZHcitTZTkz?= =?utf-8?B?ZlBMb1d4anFHN0F4a0ZoTkFKcmU4OVJhb2JhWUJLSDFBRFY5aVNxZzVGNXZy?= =?utf-8?B?bEljeGdKQitEclFNUEo5WDQ4V3p4cHZ3L0I3K3BDbkl6bjVqR3Z4V1pBV3hp?= =?utf-8?B?NHIyK2luY21FUSt1NjQ3UjlHQTBudTZXQnluQ3h6VFp1RkIxSFZRWE8vWHNy?= =?utf-8?B?U21oVGNKR1dDa1R4N0Z0SnZxSWg3bkVOeDBGL3JjanZGQTFyc201bCtnbG16?= =?utf-8?B?MEtwNEFVNzM1WUo4Wkw4YVRtSUlBZk5QTVp0SW85am81Z0VlQWNRQmliaktr?= =?utf-8?B?TlY5WC9LOEVwZlpEZU85WUdmUFp5RkhrRkYvU0cwL1FLRFZCMURUUDhVeXBs?= =?utf-8?Q?XuwLYLIx/CbDV9RMXL7FNdR9VIFtynM52O+MD92?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SA2PR11MB503392FC4321F1051D382E6ACDB89SA2PR11MB5033namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA2PR11MB5033.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1e60614c-4416-4adf-02fb-08d98ed0c9c9 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2021 05:09:23.7927 (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: 7NPvtt/Bo5wGSKJQkm27s5vc/4vwUZlRgbm+EkZ+YVaStJffEfAKiyX9fx0n+rwIwxZTInIhgvjBkpzWQ1XAbg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA2PR11MB4842 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xbe-rcd-005.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: [spring] =?utf-8?b?5Zue5aSNOiBXRyBBZG9wdGlvbiBjYWxsIGZvciBodHRw?= =?utf-8?q?s=3A//datatracker=2Eietf=2Eorg/doc/draft-filsfilscheng-spring-s?= =?utf-8?q?rv6-srh-compression/?= 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, 14 Oct 2021 05:09:33 -0000 --_000_SA2PR11MB503392FC4321F1051D382E6ACDB89SA2PR11MB5033namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ2hhaXJzICYgV0csDQoNCkkgZnVsbHkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhlIGRy YWZ0Lg0KDQpGcm9tIE9jdG9iZXIgdG8gRGVjZW1iZXIgMjAyMCwgSSBsZWQgdGhlIENTSUQgbXVs dGktdmVuZG9yIGludGVyb3BlcmFiaWxpdHkgdGVzdCBpbiB0aGUgQ2hpbmEgTW9iaWxlIExhYi4g VGhlIGpvaW50IHRlYW0gc3VjY2Vzc2Z1bGx5IHZlcmlmaWVkIHRoYXQgZGlmZmVyZW50IHZlbmRv cnMgaW1wbGVtZW50IGRhdGEgcGxhbmUgaW50ZXJvcGVyYWJpbGl0eSBiYXNlZCBvbiB0aGUgQ1NJ RCBkcmFmdC4gV2UgdGVzdGVkIGVuZC10by1lbmQgTkVYVCBGbGF2b3IsIGVuZC10by1lbmQgUkVQ TEFDRSBGbGF2b3IgYW5kIEh5YnJpZCBORVhUICsgUkVQTEFDRSBmbGF2b3IgdXNlIGNhc2VzLiBU aGUgdGhyZWUgYXBwbGljYXRpb24gc2NlbmFyaW9zIG9mIENTSUQgRmxhdm9yIHByb3ZlZCB0aGF0 IHRoZSBDU0lEIGRyYWZ0IGNhbiBhY2hpZXZlIGhlYWRlciBjb21wcmVzc2lvbiBvbiBleGlzdGlu ZyBuZXR3b3JrIGVxdWlwbWVudCBhbmQgdGhlIGludGVyb3BlcmFiaWxpdHkgb2YgdHdvIGRpZmZl cmVudCBGbGF2b3JzIG9uIGEgc2luZ2xlIGRhdGEgcGxhbmUuDQoNCkkgaG9wZSB0aGlzIGludGVy b3BlcmFiaWxpdHkgdGVzdCB3aWxsIGhlbHAgdGhlIHdvcmtpbmcgZ3JvdXAgdG8gYWRvcHQgdGhl IENTSUQgZHJhZnQuDQoNClRoYW5rcyAmIFJlZ2FyZHMNCg0KWGluZyBKYW1lcyBKaWFuZw0KDQrl j5Hku7bkuro6IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+IOS7o+ihqCBKYW1lcyBH dWljaGFyZA0K5Y+R6YCB5pe26Ze0OiAyMDIx5bm0MTDmnIgx5pelIDIyOjA1DQrmlLbku7bkuro6 IFNQUklORyBXRyA8c3ByaW5nQGlldGYub3JnPg0K5oqE6YCBOiBzcHJpbmctY2hhaXJzQGlldGYu b3JnDQrkuLvpopg6IFtzcHJpbmddIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNv bXByZXNzaW9uLw0KDQpEZWFyIFdHOg0KDQpUaGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gZXhwcmVz cyB0aGVpciBhcHByZWNpYXRpb24gZm9yIGFsbCB0aGUgcmVzcG9uc2VzIHJlY2VpdmVkIHRvIG91 ciBlbWFpbHMgd2l0aCByZWZlcmVuY2UgdG8gaG93IHRoZSB3b3JraW5nIGdyb3VwIHdpc2hlcyB0 byBtb3ZlIGZvcndhcmQgd2l0aCByZXNwZWN0IHRvIGEgc29sdXRpb24gZm9yIFNSdjYgY29tcHJl c3Npb24uDQoNClRoZSBhcHBhcmVudCBpbmNsaW5hdGlvbiBvZiB0aGUgd29ya2luZyBncm91cCBp cyB0byB1c2UgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNj aGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vIGFzIHRoZSBiYXNpcyBmb3IgaXRzIGNv bXByZXNzaW9uIHN0YW5kYXJkaXphdGlvbiB3b3JrLiBUaGF0IGlzIHBhcnQgb2Ygd2hhdCB0aGlz IGVtYWlsIGF0dGVtcHRzIHRvIGNvbmZpcm0uDQoNCkJlY2F1c2Ugb2YgdGhlIGFib3ZlIHRoZSBj aGFpcnMgd291bGQgbGlrZSB0byBpc3N1ZSBhIDItd2VlayBXRyBjYWxsIGZvciBhZG9wdGlvbiBl bmRpbmcgT2N0b2JlciAxNXRoIGZvciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8gYnV0IHdpdGgg c29tZSBjbGVhciBndWlkZWxpbmVzIGFzIGZvbGxvd3MuIEJ5IGV4cHJlc3Npbmcgc3VwcG9ydCBm b3IgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCB5b3UgYXJlIGZ1bGx5IGF3YXJlIG9mIGFuZCBh cmUgYWNrbm93bGVkZ2luZyB0aGF0Og0KDQoNCiAgMS4gIFRoZSBTUFJJTkcgd29ya2luZyBncm91 cCBpcyBhZG9wdGluZyBhIGRvY3VtZW50IHRoYXQgaGFzIG11bHRpcGxlIFNSdjYgRW5kcG9pbnQg YmVoYXZpb3JzLg0KICAyLiAgVGhlIGRvY3VtZW50IGlzIGEg4oCcbGl2aW5n4oCdIGRvY3VtZW50 OyBpdCBtYXkgY2hhbmdlIGFzIGl0IGdvZXMgdGhyb3VnaCByZXZpZXcgYW5kIGFuYWx5c2lzIGJ5 IHRoZSBTUFJJTkcgd29ya2luZyBncm91cC4NCiAgMy4gIEFsbCBvcGVuIGRpc2N1c3Npb24gcG9p bnRzIHJhaXNlZCBvbiBvdXIgbWFpbGluZyBsaXN0IE1VU1QgYmUgYWRkcmVzc2VkIEJFRk9SRSBz YWlkIGRvY3VtZW50IGlzIGFsbG93ZWQgdG8gcHJvZ3Jlc3MgZnJvbSB0aGUgd29ya2luZyBncm91 cCB0byBwdWJsaWNhdGlvbi4gQSBsaXN0IG9mIHRoZXNlIGRpc2N1c3Npb24gcG9pbnRzIHdpbGwg YmUgZG9jdW1lbnRlZCBpbiB0aGUgV0cgZG9jdW1lbnQgYW5kIG1haW50YWluZWQgYnkgdGhlIGRv Y3VtZW50IGVkaXRvciBpbiBjb25qdW5jdGlvbiB3aXRoIHRoZSBjaGFpcnMuDQogIDQuICBJZiB0 aGlzIGRvY3VtZW50IGlzIGFkb3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAsIHRoZSBjaGFpcnMg c3BlY2lmeSBhcyBwYXJ0IG9mIHRoZSBhZG9wdGlvbiBjYWxsIHRoYXQgdGhlIGZvbGxvd2luZyB0 ZXh0IGRlc2NyaWJpbmcgYW4gb3BlbiBpc3N1ZSBiZSBhZGRlZCB0byB0aGUgZG9jdW1lbnQgaW4g dGhlIGFib3ZlLWRlc2NyaWJlZCBvcGVuIGlzc3VlcyBzZWN0aW9uOg0KICAgICAqICAgIkdpdmVu IHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHNhaWQgdGhhdCBpdCB3YW50cyB0byBzdGFuZGFy ZGl6ZSBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiwgYW5kIGdpdmVuIHRoYXQgdGhlIGRvY3VtZW50 IGNvbnRhaW5zIG11bHRpcGxlIFNSdjYgRW5kUG9pbnQgYmVoYXZpb3JzIHRoYXQgc29tZSBXRyBt ZW1iZXJzIGhhdmUgc3RhdGVkIGFyZSBtdWx0aXBsZSBkYXRhIHBsYW5lIHNvbHV0aW9ucywgdGhl IHdvcmtpbmcgZ3JvdXAgd2lsbCBhZGRyZXNzIHdoZXRoZXIgdGhpcyBpcyB2YWxpZCBhbmQgY29o ZXJlbnQgd2l0aCBpdHMgb25lIGRhdGEgcGxhbmUgc29sdXRpb24gb2JqZWN0aXZlLiIuDQoNClBs ZWFzZSBjb25zaWRlciB0aGUgYWJvdmUgZ3VpZGVsaW5lcyBhcyB5b3UgZGVjaWRlIG9uIHdoZXRo ZXIgdG8gc3VwcG9ydCBvciBub3QgdGhpcyBXRyBhZG9wdGlvbi4gUGxlYXNlIGV4cHJlc3MgY2xl YXJseSB5b3VyIHJlYXNvbmluZyBmb3Igc3VwcG9ydC9ub24tc3VwcG9ydCBhcyB3ZWxsIGFzIGFu eSBvcGVuIGRpc2N1c3Npb24gcG9pbnRzIHlvdSB3b3VsZCBsaWtlIGFkZHJlc3NlZCBzaG91bGQg dGhlIGRvY3VtZW50IGJlIGFkb3B0ZWQgaW50byB0aGUgd29ya2luZyBncm91cC4NCg0KVGhhbmtz IQ0KDQpKaW0sIEJydW5vICYgSm9lbA0KDQoNCg== --_000_SA2PR11MB503392FC4321F1051D382E6ACDB89SA2PR11MB5033namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuWui+S9kzsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ouetiee6vzsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEg MSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7 DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQOetiee6vyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHls ZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1h bA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiLnuq/mlofmnKwg5a2X56ym IjsNCgltYXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBo LCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2lu LXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJn aW4tbGVmdDozNi4wcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpzcGFuLmENCgl7bXNvLXN0eWxlLW5hbWU6Iue6r+aWh+acrCDlrZfn rKYiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazrnuq/mlofmnKw7 DQoJZm9udC1mYW1pbHk6562J57q/O30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5Ouetiee6vzsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIu MHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlz dCBsMA0KCXttc28tbGlzdC1pZDoyMTQzMTY3OTA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0x NzUwNTY5NTc0O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDENCgl7bXNvLWxpc3QtaWQ6NzUxNjk5MzkzOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczotNzIxNjU0Nzc2IDY3Njk4NzAzIDY3Njk4Njg5IDY3Njk4 NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1 O30NCkBsaXN0IGwxOmxldmVsMQ0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7 fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2Vy Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4 dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEt bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTku MHB0O30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNt O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IlpILUNOIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0i Izk1NEY3MiIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6562J57q/Ij5IaSBDaGFpcnMgJmFtcDsgV0cs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ouetiee6vyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ouetiee6vyI+SSBmdWxs eSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGUgZHJhZnQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5Ouetiee6vyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5Ouetiee6vyI+RnJvbSBPY3RvYmVyIHRvIERlY2VtYmVyIDIw MjAsIEkgbGVkIHRoZSBDU0lEIG11bHRpLXZlbmRvciBpbnRlcm9wZXJhYmlsaXR5IHRlc3QgaW4g dGhlIENoaW5hIE1vYmlsZSBMYWIuIFRoZSBqb2ludCB0ZWFtIHN1Y2Nlc3NmdWxseSB2ZXJpZmll ZCB0aGF0IGRpZmZlcmVudCB2ZW5kb3JzIGltcGxlbWVudCBkYXRhDQogcGxhbmUgaW50ZXJvcGVy YWJpbGl0eSBiYXNlZCBvbiB0aGUgQ1NJRCBkcmFmdC4gV2UgdGVzdGVkIGVuZC10by1lbmQgTkVY VCBGbGF2b3IsIGVuZC10by1lbmQgUkVQTEFDRSBGbGF2b3IgYW5kIEh5YnJpZCBORVhUICsgUkVQ TEFDRSBmbGF2b3IgdXNlIGNhc2VzLiBUaGUgdGhyZWUgYXBwbGljYXRpb24gc2NlbmFyaW9zIG9m IENTSUQgRmxhdm9yIHByb3ZlZCB0aGF0IHRoZSBDU0lEIGRyYWZ0IGNhbiBhY2hpZXZlIGhlYWRl ciBjb21wcmVzc2lvbg0KIG9uIGV4aXN0aW5nIG5ldHdvcmsgZXF1aXBtZW50IGFuZCB0aGUgaW50 ZXJvcGVyYWJpbGl0eSBvZiB0d28gZGlmZmVyZW50IEZsYXZvcnMgb24gYSBzaW5nbGUgZGF0YSBw bGFuZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6562J57q/Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6562J57q/Ij5J IGhvcGUgdGhpcyBpbnRlcm9wZXJhYmlsaXR5IHRlc3Qgd2lsbCBoZWxwIHRoZSB3b3JraW5nIGdy b3VwIHRvIGFkb3B0IHRoZSBDU0lEIGRyYWZ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTrnrYnnur8iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTrnrYnnur8iPlRoYW5rcyAmYW1wOyBSZWdhcmRzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ouetiee6vyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ouetiee6vyI+WGluZyBKYW1lcyBKaWFuZzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTrnrYnnur8iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6562J57q/Ij7lj5Hk u7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6562J57q/Ij4gc3ByaW5nICZsdDtzcHJpbmctYm91bmNl c0BpZXRmLm9yZyZndDsNCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6562J57q/ Ij7ku6PooaggPC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5 Ouetiee6vyI+SmFtZXMgR3VpY2hhcmQ8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5Ouetiee6vyI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5Ouetiee6vyI+IDIw MjE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5Ouetiee6vyI+5bm0PHNwYW4gbGFuZz0i RU4tVVMiPjEwPC9zcGFuPuaciDxzcGFuIGxhbmc9IkVOLVVTIj4xPC9zcGFuPuaXpTxzcGFuIGxh bmc9IkVOLVVTIj4gMjI6MDU8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4gbGFuZz0iRU4t VVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gU1BSSU5HIFdHICZsdDtzcHJpbmdA aWV0Zi5vcmcmZ3Q7PGJyPg0KPC9zcGFuPjxiPuaKhOmAgTxzcGFuIGxhbmc9IkVOLVVTIj46PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IHNwcmluZy1jaGFpcnNAaWV0Zi5vcmc8YnI+DQo8 L3NwYW4+PGI+5Li76aKYPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIj4gW3NwcmluZ10gV0cgQWRvcHRpb24gY2FsbCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJl c3Npb24vPG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkRlYXIgV0c6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gZXhwcmVzcyB0aGVp ciBhcHByZWNpYXRpb24gZm9yIGFsbCB0aGUgcmVzcG9uc2VzIHJlY2VpdmVkIHRvIG91ciBlbWFp bHMgd2l0aCByZWZlcmVuY2UgdG8gaG93IHRoZSB3b3JraW5nIGdyb3VwIHdpc2hlcyB0byBtb3Zl IGZvcndhcmQgd2l0aCByZXNwZWN0IHRvIGEgc29sdXRpb24gZm9yIFNSdjYgY29tcHJlc3Npb24u DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBhcHBhcmVudCBpbmNsaW5hdGlvbiBvZiB0aGUgd29y a2luZyBncm91cCBpcyB0byB1c2UNCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyI+ DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNw cmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88L2E+IGFzIHRoZSBiYXNpcyBmb3IgaXRzIGNvbXBy ZXNzaW9uIHN0YW5kYXJkaXphdGlvbiB3b3JrLiBUaGF0IGlzIHBhcnQgb2Ygd2hhdCB0aGlzIGVt YWlsIGF0dGVtcHRzIHRvIGNvbmZpcm0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5CZWNhdXNlIG9mIHRo ZSBhYm92ZSB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gaXNzdWUgYSAyLXdlZWsgV0cgY2FsbCBm b3IgYWRvcHRpb24gZW5kaW5nIE9jdG9iZXIgMTU8c3VwPnRoPC9zdXA+IGZvcg0KPGEgaHJlZj0i aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJp bmctc3J2Ni1zcmgtY29tcHJlc3Npb24vIj4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLzwvYT4g YnV0IHdpdGggc29tZSBjbGVhciBndWlkZWxpbmVzIGFzIGZvbGxvd3MuIEJ5IGV4cHJlc3Npbmcg c3VwcG9ydCBmb3IgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCB5b3UgYXJlIGZ1bGx5IGF3YXJl IG9mIGFuZCBhcmUgYWNrbm93bGVkZ2luZyB0aGF0Og0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHN0YXJ0PSIxIiB0eXBlPSIx Ij4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTtt c28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBTUFJJTkcgd29y a2luZyBncm91cCBpcyBhZG9wdGluZyBhIGRvY3VtZW50IHRoYXQgaGFzIG11bHRpcGxlIFNSdjYg RW5kcG9pbnQgYmVoYXZpb3JzLg0KPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDEgbGV2ZWwx IGxmbzMiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgZG9jdW1lbnQgaXMgYSDigJxsaXZpbmfigJ0g ZG9jdW1lbnQ7IGl0IG1heSBjaGFuZ2UgYXMgaXQgZ29lcyB0aHJvdWdoIHJldmlldyBhbmQgYW5h bHlzaXMgYnkgdGhlIFNQUklORyB3b3JraW5nIGdyb3VwLg0KPG86cD48L286cD48L3NwYW4+PC9s aT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNv LWxpc3Q6bDEgbGV2ZWwxIGxmbzMiPjxzcGFuIGxhbmc9IkVOLVVTIj5BbGwgb3BlbiBkaXNjdXNz aW9uIHBvaW50cyByYWlzZWQgb24gb3VyIG1haWxpbmcgbGlzdCBNVVNUIGJlIGFkZHJlc3NlZCBC RUZPUkUgc2FpZCBkb2N1bWVudCBpcyBhbGxvd2VkIHRvIHByb2dyZXNzIGZyb20gdGhlIHdvcmtp bmcgZ3JvdXAgdG8gcHVibGljYXRpb24uIEEgbGlzdA0KIG9mIHRoZXNlIGRpc2N1c3Npb24gcG9p bnRzIHdpbGwgYmUgZG9jdW1lbnRlZCBpbiB0aGUgV0cgZG9jdW1lbnQgYW5kIG1haW50YWluZWQg YnkgdGhlIGRvY3VtZW50IGVkaXRvciBpbiBjb25qdW5jdGlvbiB3aXRoIHRoZSBjaGFpcnMuDQo8 bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMSBsZXZlbDEgbGZvMyI+PHNwYW4gbGFuZz0iRU4t VVMiPklmIHRoaXMgZG9jdW1lbnQgaXMgYWRvcHRlZCBieSB0aGUgd29ya2luZyBncm91cCwgdGhl IGNoYWlycyBzcGVjaWZ5IGFzIHBhcnQgb2YgdGhlIGFkb3B0aW9uIGNhbGwgdGhhdCB0aGUgZm9s bG93aW5nIHRleHQgZGVzY3JpYmluZyBhbiBvcGVuIGlzc3VlIGJlIGFkZGVkIHRvIHRoZQ0KIGRv Y3VtZW50IGluIHRoZSBhYm92ZS1kZXNjcmliZWQgb3BlbiBpc3N1ZXMgc2VjdGlvbjo8bzpwPjwv bzpwPjwvc3Bhbj48L2xpPjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHR5cGU9ImRpc2MiPg0K PGxpIGNsYXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtc28tbGlzdDpsMSBsZXZlbDIgbGZvMyI+ PHNwYW4gbGFuZz0iRU4tVVMiPiZxdW90O0dpdmVuIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgaGFz IHNhaWQgdGhhdCBpdCB3YW50cyB0byBzdGFuZGFyZGl6ZSBvbmUgZGF0YSBwbGFuZSBzb2x1dGlv biwgYW5kIGdpdmVuIHRoYXQgdGhlIGRvY3VtZW50IGNvbnRhaW5zIG11bHRpcGxlIFNSdjYgRW5k UG9pbnQgYmVoYXZpb3JzIHRoYXQgc29tZSBXRyBtZW1iZXJzDQogaGF2ZSBzdGF0ZWQgYXJlIG11 bHRpcGxlIGRhdGEgcGxhbmUgc29sdXRpb25zLCB0aGUgd29ya2luZyBncm91cCB3aWxsIGFkZHJl c3Mgd2hldGhlciB0aGlzIGlzIHZhbGlkIGFuZCBjb2hlcmVudCB3aXRoIGl0cyBvbmUgZGF0YSBw bGFuZSBzb2x1dGlvbiBvYmplY3RpdmUuJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91 bD4NCjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPlBsZWFzZSBjb25zaWRlciB0aGUgYWJvdmUgZ3VpZGVsaW5lcyBhcyB5b3UgZGVjaWRl IG9uIHdoZXRoZXIgdG8gc3VwcG9ydCBvciBub3QgdGhpcyBXRyBhZG9wdGlvbi4gUGxlYXNlIGV4 cHJlc3MgY2xlYXJseSB5b3VyIHJlYXNvbmluZyBmb3Igc3VwcG9ydC9ub24tc3VwcG9ydCBhcyB3 ZWxsIGFzIGFueSBvcGVuIGRpc2N1c3Npb24gcG9pbnRzIHlvdSB3b3VsZCBsaWtlIGFkZHJlc3Nl ZA0KIHNob3VsZCB0aGUgZG9jdW1lbnQgYmUgYWRvcHRlZCBpbnRvIHRoZSB3b3JraW5nIGdyb3Vw LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SmltLCBCcnVu byAmYW1wOyBKb2VsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SA2PR11MB503392FC4321F1051D382E6ACDB89SA2PR11MB5033namp_-- From nobody Wed Oct 13 22:45:37 2021 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 76CFA3A1430; Wed, 13 Oct 2021 22:45:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1WB7ydGdreI; Wed, 13 Oct 2021 22:45:23 -0700 (PDT) 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 F04AB3A142E; Wed, 13 Oct 2021 22:45:22 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id d13-20020a17090ad3cd00b0019e746f7bd4so6143364pjw.0; Wed, 13 Oct 2021 22:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=Ngpon+RGbpRUARVt4DqgB0oFuvzRD2awSYMUw3xqXUY=; b=a1Io/BSCcskrLJ1hk3kvlYIWfwlvzHTxbkqf/+m/qOt/PnaduNC8e4+c8FeYiyPnuW BlE4e9axBGXx7lwettY4OzrUls8nOq8EKlMZF+ZKJU091sh/FwvbP1T12zzuc2DdoOBE l3XJOY24vxCLiT5mtc07i0fpaAxCAALkSRb2oZs7TknkUCGmlOb5YVkpNNx/y/5SqbUa kD4kNdCmbqh5DwcPt9SFKDTvIwhrYH+LdM8MkhHWKYQ0eXWDcF335NU6Tj7n+2LvcgpW CXkiy5K0afw0GtPSTUb8Af7dOHwF745mxxqXmseQu9kKfOZ1BJO/NCvOeX+W+lL/Oebp RhTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=Ngpon+RGbpRUARVt4DqgB0oFuvzRD2awSYMUw3xqXUY=; b=MG65QKrmNch/5c4KydvdwXebxtKFnIaN8mr+XLMuSPFbfbSgHcd8wUTosdKHBgdolG /YkKp3BiHvsHZVbLhMcnWgIKLCxYswMmuTRNvKJjHPprberuJ3vWwzcZ2mk3MirJLUb+ caaOjYYmgZ/i1VNE1VKEsxE6oiA7ZZhfLg/jopm0R1V39cU1uRvY+YMCAuMlga5kPaPM d+3Xj4l99QpUUzIwcmAXdXJd5vxBuDAsP4/WsZL6R2sEtIY9wOfU4CZYEpCZNM2RZlt7 2Ogm7BCIZsIxvOV9/PwsnefgqlnTqjcrKk9quc+vv+LbmSnrkOcuJAATHILD8omw16YI zg8g== X-Gm-Message-State: AOAM533Al0flJomPvLUxHWKi/FI4UyY4u0naIijuNEViL1l2tOHJWTfX AULKRiJsbIvfSeqqmxqZZhA= X-Google-Smtp-Source: ABdhPJxHsulreCeB2KwrA3PAA8aChTfhR8jyMYcqtea6C8jE0wD3F2w1sRcIHLpsudk+e/nferkVGA== X-Received: by 2002:a17:903:41c1:b0:13e:fe56:e42a with SMTP id u1-20020a17090341c100b0013efe56e42amr3152658ple.52.1634190322155; Wed, 13 Oct 2021 22:45:22 -0700 (PDT) Received: from smtpclient.apple ([2601:647:5580:31a0:5cfc:e447:841c:3be2]) by smtp.gmail.com with ESMTPSA id k14sm1225705pji.45.2021.10.13.22.45.20 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Oct 2021 22:45:21 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_366EBBD7-DBBD-425F-9257-55FB352C25A3" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Tetsuya Murakami In-Reply-To: Date: Wed, 13 Oct 2021 22:45:19 -0700 Cc: SPRING WG , "spring-chairs@ietf.org" Message-Id: References: To: James Guichard X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 14 Oct 2021 05:45:33 -0000 --Apple-Mail=_366EBBD7-DBBD-425F-9257-55FB352C25A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear WG, I support the adoption of = draft-filsfilscheng-spring-srv6-srh-compression.=20 Based on my understanding, NEXT and REPLACE flavors defined in this = draft can meet with RFC8986. Also, there are multiple implementations = today like Arrcus and VPP as well. I really appreciate the huge efforts = made by DT team in order to deliver this draft. Thanks, Tetsuya > On Oct 1, 2021, at 7:04 AM, James Guichard = wrote: >=20 > Dear WG: > =20 > The chairs would like to express their appreciation for all the = responses received to our emails with reference to how the working group = wishes to move forward with respect to a solution for SRv6 compression. > =20 > The apparent inclination of the working group is to use = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = as the basis for its compression standardization work. That is = part of what this email attempts to confirm. > =20 > Because of the above the chairs would like to issue a 2-week WG call = for adoption ending October 15th = forhttps://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-co= mpression/ = but with some clear guidelines as follows. By expressing = support for adoption of this document you are fully aware of and are = acknowledging that: > =20 > The SPRING working group is adopting a document that has multiple SRv6 = Endpoint behaviors. > The document is a =E2=80=9Cliving=E2=80=9D document; it may change as = it goes through review and analysis by the SPRING working group. > All open discussion points raised on our mailing list MUST be = addressed BEFORE said document is allowed to progress from the working = group to publication. A list of these discussion points will be = documented in the WG document and maintained by the document editor in = conjunction with the chairs. > If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open = issue be added to the document in the above-described open issues = section: > "Given that the working group has said that it wants to standardize = one data plane solution, and given that the document contains multiple = SRv6 EndPoint behaviors that some WG members have stated are multiple = data plane solutions, the working group will address whether this is = valid and coherent with its one data plane solution objective.". > =20 > Please consider the above guidelines as you decide on whether to = support or not this WG adoption. Please express clearly your reasoning = for support/non-support as well as any open discussion points you would = like addressed should the document be adopted into the working group. > =20 > Thanks! > =20 > Jim, Bruno & Joel > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring = --Apple-Mail=_366EBBD7-DBBD-425F-9257-55FB352C25A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear= WG,

    I support the adoption = of draft-filsfilscheng-spring-srv6-srh-compression. 

    Based on my understanding, NEXT and REPLACE = flavors defined in this draft can meet with RFC8986.= Also, there are multiple implementations today like Arrcus and VPP as = well. I really appreciate the huge efforts made by DT team in order to = deliver this draft.
    Thanks,
    Tetsuya

    On Oct 1, 2021, at 7:04 AM, = James Guichard <james.n.guichard@futurewei.com> wrote:

    Dear WG:
     
    The chairs would like to express their = appreciation for all the responses received to our emails with reference = to how the working group wishes to move forward with respect to a = solution for SRv6 compression.
     
    The apparent inclination of the working group is = to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ as the basis for its = compression standardization work. That is part of what this email = attempts to confirm.
     
    Because of the above the = chairs would like to issue a 2-week WG call for adoption ending October = 15th forhttps://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ but with some clear = guidelines as follows. By expressing support for adoption of this = document you are fully aware of and are acknowledging that:
     
    1. The SPRING working group is adopting = a document that has multiple SRv6 Endpoint behaviors.
    2. The document is = a =E2=80=9Cliving=E2=80=9D document; it may change as it goes through = review and analysis by the SPRING working group.
    3. All open = discussion points raised on our mailing list MUST be addressed BEFORE = said document is allowed to progress from the working group to = publication. A list of these discussion points will be documented in the = WG document and maintained by the document editor in conjunction with = the chairs.
    4. If this document is adopted by the working group, the = chairs specify as part of the adoption call that the following text = describing an open issue be added to the document in the above-described = open issues section:
      • "Given that the working group has = said that it wants to standardize one data plane solution, and given = that the document contains multiple SRv6 EndPoint behaviors that some WG = members have stated are multiple data plane solutions, the working group = will address whether this is valid and coherent with its one data plane = solution objective.".
     
    Please consider the above guidelines as you = decide on whether to support or not this WG adoption. Please express = clearly your reasoning for support/non-support as well as any open = discussion points you would like addressed should the document be = adopted into the working group.
     
    Thanks!
     
    Jim, Bruno & Joel
     
     
    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://www.ietf.org/mailman/listinfo/spring

    = --Apple-Mail=_366EBBD7-DBBD-425F-9257-55FB352C25A3-- From Hasitha.Seneviratne@dialog.lk Wed Oct 13 21:26:47 2021 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 6706A3A1185; Wed, 13 Oct 2021 21:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dialogsl.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 KGHxOwHiTU9P; Wed, 13 Oct 2021 21:26:42 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-eopbgr1300088.outbound.protection.outlook.com [40.107.130.88]) (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 919EC3A1187; Wed, 13 Oct 2021 21:26:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cwTFXrJmtRSpmg30YCr/ZsETr+RJ1CKsb+9Md21pQ1e5qxW123m39d/U+icbJiB3bF8nVu2Xoox0tpgiOTVnOYMmaQ84gj4wB9h02KTVa3TaGbPKRJYsd295kVjWAGds/VJVRmhzKtww1BdNuC8FYeW2ioou3BttDtiiKcra6TTnrFE+ojEVHyMij82FMpXVh7+B88eVKoaA4or4hnSGFA5uT0V6my4MN1NS+ZH6RA5t3oYlmKI61kmXOA7cAR7XfMqDhipBAnmWKYSgyjMs3mEzq9Z6MxyV7q+f0TyZtVQPa9bze3+ynqkjhV++nktByS2Dzo+65tCeA8jCPQxeRQ== 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=kcbKgGVfph/FxEkFu43JyCsaji9/oLuNSu3InEqaVUI=; b=emlkCp5aSEXZANAPHcCLv2/1ag1f2lqSPgpVVGeZAVeqiGxHdY+aYSWY6lLATpas7SoYKzgnusMfOEjT5Rg0moRBMKnHU2MEzmB5/iV6gy2HUivux+Wpajx/6V28467d9Fq7L5rAJyB7MXjY2Xb1Ebnk95vqv1d2fiinEIzB6zPJHy4DErxAdmhb7S0l76MgUwfF0fNtUrIOyI8CAH4TOvjmNcfsEvax19pLs7hs0Fw6WdE07z+AKvuOavHsg+TnsAuKJioz3Z1BSxHrNIHK32bXeUzpPz+4AyfNmuwZrDzzwyNr4BkAX44zzNBxnAeAdBc8e/8OzXcV1S7cmX6xpg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=dialog.lk; dmarc=pass action=none header.from=dialog.lk; dkim=pass header.d=dialog.lk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dialogsl.onmicrosoft.com; s=selector2-dialogsl-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kcbKgGVfph/FxEkFu43JyCsaji9/oLuNSu3InEqaVUI=; b=zyKsUOCxgLWAOL4rJD356qxkWsnfqOTVZ2/tcoSJUQrBphJP/vg28V9OAFY8/5i0rA7JTXEoLfZZliARxlXXrrk6tRiRnobzhBLbseuJmu0fs3XDQDC7h3Z4QOWwMzmKhCbW5mC5T00FFnaT3LO/KSEUXkGG3UKA9z9BKYgQhjI= Received: from SI2PR02MB4681.apcprd02.prod.outlook.com (2603:1096:4:ee::9) by SI2PR02MB4938.apcprd02.prod.outlook.com (2603:1096:4:120::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.19; Thu, 14 Oct 2021 04:26:37 +0000 Received: from SI2PR02MB4681.apcprd02.prod.outlook.com ([fe80::d1b5:d971:1e45:7bc1]) by SI2PR02MB4681.apcprd02.prod.outlook.com ([fe80::d1b5:d971:1e45:7bc1%5]) with mapi id 15.20.4608.016; Thu, 14 Oct 2021 04:26:37 +0000 From: Hasitha Seneviratne To: "spring@ietf.org" , "spring-chairs@ietf.org" CC: Amila Prasanna Thread-Topic: SRV6 based compression standardization - https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: AdfAs5p/CATCHsTpQ/GNuyjGNy+cUQ== Date: Thu, 14 Oct 2021 04:26:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=dialog.lk; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 16d4bd25-62f4-4c14-5d9a-08d98ecacfe1 x-ms-traffictypediagnostic: SI2PR02MB4938: x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1esCv/NcEQBVfWvnhY6fwBzOHRPXhYpnCHTIl0Xbo8VsglFg72mhvfVpfbfoh+oJV7jq4F1Xq56dLC6zwlawz2FFabjiFdp6ie/ARFdIMskMzUBVKJkQ5xSFogMNwtO63BNHW79UaOxym8kBJ9A0rg02Rz5cLqdsJec1ImB+2C+S+q1W2D/XYkBH5te1Mh6TwG/lrKlFRK10z989hK+dAEAZZ8KdWHua65/luNPxWEYhQjvSjKcRn/j58nAQypAaZPuX9nKT6FTwrwBG3tJqBvnHarPpTK+bFJ5AP5FgOu0Pz5ddTJ6d1R8etZK7bZjrDQ1a+zp/GaL7pwbwHs4RfMMDwG8dAORYEOdyBg0duVns3YOIup8IL84r67QBFz1H8StMYCnPFR8PSm5bz2hHhzlFHe/rbxi8wA2TT9sAXvI3vhB0jFWw1AH/iUm0wh1lkcr1KWf97bcoz6oGpSSS0hOOC7puOV3iilsQubxSrc2eXo5kt47tWGZZaL8ah5E4aGUdS5N7dl4NAO/0pOIFbR02kTf5gQGwP3mQd/goxn+dKwHCut3kqTH4P/jWRlAJxKPZg0FElxbOxxJNyKIN0MDHrMwXp4XRaXOM1y+47nL1rDqAdXXsCdEL2bW+72ENrH9b52nLPJkjBvSb4JmGt/AaIO2+vThmUaDqs5y5YxRvKVV1/74grdjS+sce/c3Ayx6Xno57fH6LGsaGwynyt+IxMHvdQdnEZIQFhXpnymM9mcAurm19U3QgjG6NKRSeOyyWATS/lr6LKZpjfXEstX1KjNv/0Z2W6H8/jbpD3bI= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SI2PR02MB4681.apcprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66446008)(76116006)(316002)(38100700002)(122000001)(83380400001)(66574015)(107886003)(450100002)(66556008)(52536014)(66946007)(38070700005)(33656002)(66476007)(64756008)(8676002)(86362001)(26005)(5660300002)(186003)(110136005)(9686003)(8936002)(55016002)(4326008)(7696005)(71200400001)(2906002)(6506007)(508600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?8yh8ik8Amw3tUJ49/fsR3ZSJ4MAxIQkAQI3Hbml8Jh5P7FhSTxzZIlKeWKRH?= =?us-ascii?Q?bfWzgtSCVcO0KhGnw3zlv89+KF2OimdLumRYy4ZwKY3wVdfsDc+prqI+UQ6s?= =?us-ascii?Q?UJNF3+4Vwjr+vqPRLI6m0B6Mf5hqbxJcigAo6O9NQTp162uGsXjlvn1BEZsc?= =?us-ascii?Q?c5RXa+6q7YqJ8J+JuQOCNbvu+6CPTTYC7US9QHvMcNWQAGNxxliY/OzUUcZH?= =?us-ascii?Q?ku+xN/FR7H+PAO6Ne6xuy+wuKDtQPDFZXZO9RdhQJJMb7c/hwb259j3ka6wH?= =?us-ascii?Q?FlpX19eHigRgWKUzsj/N25bp3YECIKl961cUrDQbWufORf+84CLC5MrA+J5H?= =?us-ascii?Q?wKy5c9fWB9Ip7SPv8hZ++7po1B1KQcvd1Tk9DRSR+CSUYxgGKYWpzwIgAR0n?= =?us-ascii?Q?nwd1KFIMhopyUWeDm8HEBjJxAU8edsJfzCDS1Mzq6FINHKJaN2ZL4XemOezu?= =?us-ascii?Q?PX/lwLjd3S2QQodoL9ziefjsgkxQprr1hKgjqAzxFOnvmAD4cNfusXRmj7Lo?= =?us-ascii?Q?LoZ2Zyd8IEPLf8Es59S22gupvqCatE0LcH6Fl6Wzi5lQixCpR4zE1UpogyW+?= =?us-ascii?Q?BAq3F7vaa+YzanzowzouyA9AIDxJOyiHGiwaWoObuU4ZTJp1anYK7qk18SE8?= =?us-ascii?Q?J4l68iGjlkA8FwVvVysZlQ10FTL++9vNMThgsknYL35D8r3PsLy+3k+fT+FL?= =?us-ascii?Q?axkEwS0D8S13QXXNR3hIYH6BqwP7v2tYfTs8FtQMdC8JIEPMQL3oh3PUE8rn?= =?us-ascii?Q?iljZ2fUXM0gC71J5leoxvVZnLB7C+iv1CwJvl4KTaVC0/XjDhmUsjf3Ghrmh?= =?us-ascii?Q?OfmtwoNwYs/6qpTNgxSAZKV8i1bj8NQoONltZkfNMMV/uzXkFOz43UcXNrE1?= =?us-ascii?Q?p2HBC2glmDkWaCGcYyAab5r2ZMWOK510m6M7IrQCkblBh4KNleAYhgYSBhIs?= =?us-ascii?Q?Uh0sEv11F7p12uD8uTncRarqh3+oNs7/+113Kc3ENJqm+8Kijq5ICx1BX7Kp?= =?us-ascii?Q?OGZav2Q6lgAWiWpmYfHI1GKnDwB25Gl++qs7pslv2zWYEjuglbUTQWfUIH2C?= =?us-ascii?Q?Mm/nS/1t5aGu8m3j4lB9l6gIugwdU9F0c3rI1uV7mSyDR/57ylQw/qU6y6C3?= =?us-ascii?Q?O4IZy4wI95yO7qWdjaVi1RhGtKjn5a9NSTAzAnaT4RmiMscOZsqtVLerSZSv?= =?us-ascii?Q?w8+5CwOootZ7MtItCGfKRDcsc7vCc6w/4bLNgLxXKXVMz4HTgHMGvPL9GIXE?= =?us-ascii?Q?7Uw/9DBAvd+5XQ5mOv7wh0CSd2+H9woNHIMM0gfNbVmiGzqwMLSa2tn595d0?= =?us-ascii?Q?jApGRSUn/y56TwTahuCQEbvI?= Content-Type: multipart/alternative; boundary="_000_SI2PR02MB46815768745045AF2FC14BF0F5B89SI2PR02MB4681apcp_" MIME-Version: 1.0 X-OriginatorOrg: dialog.lk X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SI2PR02MB4681.apcprd02.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 16d4bd25-62f4-4c14-5d9a-08d98ecacfe1 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2021 04:26:36.9666 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a628da58-b099-463e-b9bd-4987cd45ed75 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: miMlv+t4MNesHbbezTdSbnb4kGNLKeBFe+y0HTqGAcKgAWrGEaMl039CBLkjTkF3tzaCqaVAo/45blWBuLczKsCZ76NrBOxnbK5shYUxEAc= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SI2PR02MB4938 Archived-At: X-Mailman-Approved-At: Wed, 13 Oct 2021 23:33:05 -0700 Subject: [spring] SRV6 based compression standardization - https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 14 Oct 2021 04:29:02 -0000 --_000_SI2PR02MB46815768745045AF2FC14BF0F5B89SI2PR02MB4681apcp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Spring WG I am Hasitha from Dialog which is the largest telecommunication Operator in= Sri Lanka. We are in the process of migrating dialog IP network in to SRv6= . With this paradigms standardization of SRv6 compression is an indispensa= ble task. Dialog IP network is a multivendor network with CISCO & Huawei . We do not want the implementation of SRv6 will increase our investment in t= he router interface and DWDM. Dialog network consist of several links with = multiple 100Gbps with a distance more than 100km. Hope standardization of S= Rv6 compression will help to solve our problems while establishing cost opt= imized SRv6 based IP network Regards Hasitha ________________________________ This e-mail is confidential. It may also be legally privileged. If you are = not the intended recipient or have received it in error, please delete it a= nd all copies from your system and notify the sender immediately by return = e-mail. Any unauthorized reading, reproducing, printing or further dissemin= ation of this e-mail or its contents is strictly prohibited and may be unla= wful. Internet communications cannot be guaranteed to be timely, secure, er= ror or virus-free. The sender does not accept liability for any errors or o= missions. --_000_SI2PR02MB46815768745045AF2FC14BF0F5B89SI2PR02MB4681apcp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

     

    Dear&nb= sp;Spring WG=

    &n= bsp;

    I am Ha= sitha from Dialog which is the largest telecommunication Operator in Sri La= nka. We are in the process of migrating dialog IP network in to SRv6 . With= this paradigms standardization of SRv6 compression is an indispensable  task. Dialog IP network is a multive= ndor network with CISCO & Huawei .

    &n= bsp;

    We do not want the imple= mentation of SRv6 will increase our investment in the router interface and = DWDM. Dialog network consist of several links with multiple 100Gbps with a = distance more than 100km. Hope standardization of SRv6 compression will help to solve our problems while establishing cos= t optimized SRv6 based IP network

     =

    Regards

    Hasitha

     

     




    This e-mail is confidential. It may also be legally privileged. If you are = not the intended recipient or have received it in error, please delete it a= nd all copies from your system and notify the sender immediately by return = e-mail. Any unauthorized reading, reproducing, printing or further dissemination of this e-mail or its conte= nts is strictly prohibited and may be unlawful. Internet communications can= not be guaranteed to be timely, secure, error or virus-free. The sender doe= s not accept liability for any errors or omissions.

     --_000_SI2PR02MB46815768745045AF2FC14BF0F5B89SI2PR02MB4681apcp_-- From nobody Thu Oct 14 00:57:52 2021 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 858133A0E08; Thu, 14 Oct 2021 00:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3sgedacqDL6W; Thu, 14 Oct 2021 00:57:45 -0700 (PDT) Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [192.26.91.6]) by ietfa.amsl.com (Postfix) with ESMTP id E83CB3A0DB9; Thu, 14 Oct 2021 00:57:41 -0700 (PDT) Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 51B7AC1A7162; Thu, 14 Oct 2021 16:57:40 +0900 (JST) X-Virus-Scanned: amavisd-new at kddi-research.jp Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4_xuvlfDTTVH; Thu, 14 Oct 2021 16:57:35 +0900 (JST) Received: from safeattach.localdomain (unknown [IPv6:2001:200:601:1a00:20c:29ff:fe79:2280]) by mandala.kddilabs.jp (Postfix) with ESMTP id B1465C1A7161; Thu, 14 Oct 2021 16:57:35 +0900 (JST) Received: from [172.19.124.101] (dhcp101.west-4f.cn.kddilabs.jp [172.19.124.101]) by safeattach.localdomain with ESMTP id 19E7vYSu000861; Thu, 14 Oct 2021 16:57:34 +0900 To: James Guichard , SPRING WG Cc: "spring-chairs@ietf.org" References: From: Takuya Miyasaka Message-ID: <46dc8aae-e5d2-ef18-8299-f1e1cbb7f6c0@kddi-research.jp> Date: Thu, 14 Oct 2021 16:55:48 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 14 Oct 2021 07:57:50 -0000 Hi, I support the adoption of this draft. While SRv6 has high potential, for a simple operation such as TE the high packet length overhead of SRv6 has been an issue for operators. This draft resolves this issue and (I believe) a necessary feature for operators, so we would like to support this draft. Thanks, Takuya On 2021/10/01 23:04, James Guichard wrote: > > Dear WG: > > The chairs would like to express their appreciation for all the > responses received to our emails with reference to how the working > group wishes to move forward with respect to a solution for SRv6 > compression. > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > as the basis for its compression standardization work. That is part of > what this email attempts to confirm. > > Because of the above the chairs would like to issue a 2-week WG call > for adoption ending October 15^th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging > that: > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a living document; it may change as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the > working group to publication. A list of these discussion points > will be documented in the WG document and maintained by the > document editor in conjunction with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text > describing an open issue be added to the document in the > above-described open issues section: > * "Given that the working group has said that it wants to > standardize one data plane solution, and given that the > document contains multiple SRv6 EndPoint behaviors that some > WG members have stated are multiple data plane solutions, the > working group will address whether this is valid and coherent > with its one data plane solution objective.". > > Please consider the above guidelines as you decide on whether to > support or not this WG adoption. Please express clearly your reasoning > for support/non-support as well as any open discussion points you > would like addressed should the document be adopted into the working > group. > > Thanks! > > Jim, Bruno & Joel > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Thu Oct 14 01:48:55 2021 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 385BB3A1150 for ; Thu, 14 Oct 2021 01:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 4NjR7QxIGwjM for ; Thu, 14 Oct 2021 01:48:37 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 3C82C3A1168 for ; Thu, 14 Oct 2021 01:48:35 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id x27so23549808lfa.9 for ; Thu, 14 Oct 2021 01:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=T+HnsjjRR/jyq0TA/hyiF4+r9rFLTUfG7RYdK5ByGHc=; b=c6YqXy15zbv3hBjAZhZoqg2M0RM3WmU/9Lcodj/7JBHy+C8kfiUYvS4O56qw5Ic9zQ AMie2WLLQqDI6GQgoluG97xZxjCrcQnVL5hzmOKQRnO+RadXHOUUlk6xkqG5qB8dYXQC mdh2Tus3KFJ0WUarIl3pQDJaCsEYBjrdJHSJY= 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=T+HnsjjRR/jyq0TA/hyiF4+r9rFLTUfG7RYdK5ByGHc=; b=32C2tjMJia5CINc7M7Ij5JjFcfM0lE45otO68LHcF0c8ZD38yYAK6GbI+d8oplzJVM dODTm/rjNJO+2a6WsNvPy/zhtOXClPfjtelLxkTbKhvK2a+3q7PN7KFTNP1HzK3NnR9d YY9DRTTA8okrFW/uAGBE+9SQWajQoEIY2gMJ7s/XzAHKD8QYBPehYFCrWYi2c+ihpmKy Cgp+1kHP84u+g3P3tO/K3vawBJxrlOfnylt78QboT3Y7oUzWWkfMU5i1LC50Fbmtg2O7 biu6MFIVlM+aFUAWylaf8PDhTmN2mKSdCztyKHvLG/QMPyF4im65AtbuegFTm8TUKSvy 4USA== X-Gm-Message-State: AOAM530L2bg5VifFsejf2hsHo0xYyL6IJGQtSsSfZ54BqyS0486A84SA VV6vME66KHuCA1JQtHlCvj2UlkoTnwnadYm7S6SO79E7StBd0SQSefocvbkcSloQHm7TwjXBxBY R21B6oqkbn/rhur54y7UorQ== X-Google-Smtp-Source: ABdhPJzSsBS16nNOGKYd1h5zty2UNx4RUG50HJ7ScbjskpTgxh+uqoCmSEZAMOICYdGvvdLNxcvTc7/r5XLN/Rrpybk= X-Received: by 2002:a2e:7816:: with SMTP id t22mr5022073ljc.133.1634201311165; Thu, 14 Oct 2021 01:48:31 -0700 (PDT) MIME-Version: 1.0 From: Shay Zadok Date: Thu, 14 Oct 2021 11:48:20 +0300 Message-ID: To: james.n.guichard@futurewei.com, spring@ietf.org Content-Type: multipart/alternative; boundary="000000000000a5377d05ce4c24a2" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 14 Oct 2021 08:48:52 -0000 --000000000000a5377d05ce4c24a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear WG, We would like to update on the production support by the StrataDNX products of both flavors REPLACE and NEXT as defined in CSID draft, as well as non-compressed "Classic" SRv6. StrataDNX products include: Jericho2/Jericho2c/Qumran2c/Qumran2a/Qumran2u/Qumran2n/Jericho2c+ and any future device This support keeps: 1. Single and unified data-plane uCode, programmed using high level languag= e 2. Single data-plane API 3. Concurrent/Simultaneous support of all three techniques based on a per-packet behavior 4. Concurrent/Simultaneous support of all three techniques inside of the same SRv6 Header 5. In all three techniques the following is already supported concurrently/simultaneously and in production 1. SRv6 main behaviors - compliant with *rfc8986* 2. SRv6 insert behaviors - compliant with *draft-srv6-net-pgm-insertion= * 3. SRv6 midpoint protection behaviors - compliant with *draft-midpoint-protection* All of the above is in production deployment in various published and unpublished networks around the globe. Our products are used by industry leading OEM (some of them published they are using the StrataDNX products) and "pure" NOS vendors. BRCM using Jericho2 participated in couple of interops that included some mix of REPLACE-CSID, NEXT-CSID and non-compressed "Classic" SRv6 - and all interops have ended successfully Thanks & Regards, Shay *=E5=8F=91=E4=BB=B6=E4=BA=BA:* spring [mailto:spring-bounces@ietf.org] *=E4= =BB=A3=E8=A1=A8 *James Guichard *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2021=E5=B9=B410=E6=9C=881=E6=97=A5 = 22:05 *=E6=94=B6=E4=BB=B6=E4=BA=BA:* SPRING WG *=E6=8A=84=E9=80=81:* spring-chairs@ietf.org *=E4=B8=BB=E9=A2=98:* [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ Dear WG: The chairs would like to express their appreciation for all the responses received to our emails with reference to how the working group wishes to move forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is part of what this email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv6 Endpoint behaviors. 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change as= it goes through review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be addressed BEFORE said document is allowed to progress from the working group to publication. A list of these discussion points will be document= ed in the WG document and maintained by the document editor in conjunction with the chairs. 4. If this document is adopted by the working group, the chairs specify as part of the adoption call that the following text describing an open issue be added to the document in the above-described open issues sectio= n: - "Given that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this is valid and coherent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or not this WG adoption. Please express clearly your reasoning for support/non-support as well as any open discussion points you would like addressed should the document be adopted into the working group. Thanks! Jim, Bruno & Joel --=20 This electronic communication and the information and any files transmitted= =20 with it, or attached to it, are confidential and are intended solely for=20 the use of the individual or entity to whom it is addressed and may contain= =20 information that is confidential, legally privileged, protected by privacy= =20 laws, or otherwise restricted from disclosure to anyone else. If you are=20 not the intended recipient or the person responsible for delivering the=20 e-mail to the intended recipient, you are hereby notified that any use,=20 copying, distributing, dissemination, forwarding, printing, or copying of= =20 this e-mail is strictly prohibited. If you received this e-mail in error,= =20 please return the e-mail to the sender, delete it from your computer, and= =20 destroy any printed copy of it. --000000000000a5377d05ce4c24a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Dear WG,

    We would like to update on the produ= ction support by the StrataDNX products=C2=A0of both flavors REPLACE and NE= XT as defined in CSID draft, as well as non-compressed "Classic" = SRv6.=C2=A0
    StrataDNX=C2=A0products include: Jericho2/Jericho2c/Q= umran2c/Qumran2a/Qumran2u/Qumran2n/Jericho2c+ and any future device

    This support keeps:
    1. Single and unified data-plane uCode, progr= ammed using high level language
    2. Single data-plane API
    3. Concurren= t/Simultaneous support of all three techniques based on a per-packet behavi= or
    4. Concurrent/Simultaneous support of all three techniques inside of = the same SRv6 Header
    5. In all three techniques the following is = already supported=C2=A0concurrently/simultaneously = and in production
    =C2=A0 =C2=A0 1. SRv6 main behaviors - c= ompliant with rfc8986
    =C2=A0 =C2=A0 2. SRv6 insert behaviors - co= mpliant with draft-srv6-net-pgm-insertion
    =C2=A0 =C2=A0 3. SRv6 m= idpoint protection behaviors - compliant with draft-midpoint-protection<= /b>

    All of the above is in production deployment in various publishe= d and unpublished networks around the globe.
    Our products are used by in= dustry leading OEM (some of them published they are using the StrataDNX pro= ducts) and "pure" NOS vendors.

    BRCM using Jericho2 partici= pated in couple of interops that included some mix of REPLACE-CSID, NEXT-CS= ID and non-compressed "Classic" SRv6 - and all interops have ende= d successfully

    Thanks= & Regards,
    Shay


    =

    =C2=A0

    =C2=A0

    =E5=8F=91=E4=BB=B6=E4=BA= =BA:=C2=A0spring [ma= ilto:spring-bo= unces@ietf.org]=C2=A0=E4=BB=A3=E8=A1=A8=C2=A0James Guichard
    =E5=8F=91=E9=80=81=E6=97=B6=E9= =97=B4:=C2=A02021=E5=B9=B410=E6=9C=881= =E6=97=A5=C2=A022:05
    =E6=94=B6=E4= =BB=B6=E4=BA=BA:=C2=A0= SPRING WG <spring@i= etf.org>
    =E6=8A=84=E9=80=81:=C2=A0spring-chairs@ietf.org
    =E4=B8=BB=E9=A2=98= :=C2=A0[spring] WG Ado= ption call for=C2=A0https://datatracke= r.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/<= /span>

    =C2=A0

    Dear WG:

    =C2=A0

    The chairs would like to express their = appreciation for all the responses received to our emails with reference to= how the working group wishes to move forward with respect to a solution fo= r SRv6 compression.

    =C2=A0

    The apparent inclination of the working group is to use=C2=A0<= a href=3D"https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-= srh-compression/" target=3D"_blank">https://datatracker.ietf.org/doc/draft-= filsfilscheng-spring-srv6-srh-compression/=C2=A0as the basis for its co= mpression standardization work. That is part of what this email attempts to= confirm.

    =C2=A0

    Because of the above the chairs would like to issue a 2-week WG call for= adoption ending October 15th=C2=A0for=C2=A0https://datatracker.ietf.org/doc/draft-filsfilscheng-sprin= g-srv6-srh-compression/=C2=A0but with some clear guidelines as follows.= By expressing support for adoption of this document you are fully aware of= and are acknowledging that:

    =C2=A0

    1. The SPRING working grou= p is adopting a document that has multiple SRv6 Endpoint behaviors.<= u>
    2. The document= is a=C2=A0=E2=80=9Cliving=E2=80=9D=C2=A0document; it may change as it goes through review and= analysis by the SPRING working group.
    3. All open discussion points raised on ou= r mailing list MUST be addressed BEFORE said document is allowed to progres= s from the working group to publication. A list of these discussion points = will be documented in the WG document and maintained by the document editor= in conjunction with the chairs.
    4. If this document is adopted by the working grou= p, the chairs specify as part of the adoption call that the following text = describing an open issue be added to the document in the above-described op= en issues section:
      • "Given= that the working group has said that it wants to standardize one data plan= e solution, and given that the document contains multiple SRv6 EndPoint beh= aviors that some WG members have stated are multiple data plane solutions, = the working group will address whether this is valid and coherent with its = one data plane solution objective.".

      =C2=A0

      Please consider the above gui= delines as you decide on whether to support or not this WG adoption. Please= express clearly your reasoning for support/non-support as well as any open= discussion points you would like addressed should the document be adopted = into the working group.

      =C2=A0

      Thanks!

      =C2=A0

      Jim, Bruno & Joel

      =C2=A0

      =C2=A0



    This ele= ctronic communication and the information and any files transmitted with it= , or attached to it, are confidential and are intended solely for the use o= f the individual or entity to whom it is addressed and may contain informat= ion that is confidential, legally privileged, protected by privacy laws, or= otherwise restricted from disclosure to anyone else. If you are not the in= tended recipient or the person responsible for delivering the e-mail to the= intended recipient, you are hereby notified that any use, copying, distrib= uting, dissemination, forwarding, printing, or copying of this e-mail is st= rictly prohibited. If you received this e-mail in error, please return the = e-mail to the sender, delete it from your computer, and destroy any printed= copy of it. --000000000000a5377d05ce4c24a2-- From nobody Thu Oct 14 02:13:47 2021 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 AF4383A113A; Thu, 14 Oct 2021 02:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Zb4P8zjjocJ; Thu, 14 Oct 2021 02:13:39 -0700 (PDT) Received: from baidu.com (mx22.baidu.com [220.181.50.185]) by ietfa.amsl.com (Postfix) with ESMTP id 02C963A1136; Thu, 14 Oct 2021 02:13:36 -0700 (PDT) Received: from BC-Mail-Ex32.internal.baidu.com (unknown [172.31.51.26]) by Forcepoint Email with ESMTPS id B8103405679585A48056; Thu, 14 Oct 2021 17:13:34 +0800 (CST) Received: from BJHW-MAIL-EX28.internal.baidu.com (10.127.64.43) by BC-Mail-Ex32.internal.baidu.com (172.31.51.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2242.12; Thu, 14 Oct 2021 17:13:34 +0800 Received: from BJHW-MAIL-EX25.internal.baidu.com (10.127.64.40) by BJHW-MAIL-EX28.internal.baidu.com (10.127.64.43) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14; Thu, 14 Oct 2021 17:13:33 +0800 Received: from BJHW-MAIL-EX25.internal.baidu.com ([169.254.1.114]) by BJHW-MAIL-EX25.internal.baidu.com ([169.254.1.114]) with mapi id 15.01.2308.014; Thu, 14 Oct 2021 17:13:33 +0800 From: "Bao,Guixin" To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: AQHXwNTbSK1+iaDi8k6Ss7lPL41lU6vSNccA Date: Thu, 14 Oct 2021 09:13:33 +0000 Message-ID: <03955D7A-5E82-4088-AC1C-912393EA739E@baidu.com> References: <675D7B89-7CC4-44D2-8167-7C51382D7BC1@baidu.com> In-Reply-To: <675D7B89-7CC4-44D2-8167-7C51382D7BC1@baidu.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.204.158] Content-Type: multipart/alternative; boundary="_000_03955D7A5E824088AC1C912393EA739Ebaiducom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 14 Oct 2021 09:13:45 -0000 --_000_03955D7A5E824088AC1C912393EA739Ebaiducom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIERlYXIgV0cNCg0KSSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0Lg0KDQpG cm9tIHRoZSB1c2VyIHBvaW50IG9mIHZpZXcsIEkgdGhpbmsgdGhlIENTSUQgcHJvcG9zZXMgYSBo aWdobHkgZWZmaWNpZW50IHdheSAgZm9yIFNSdjYgY29tcHJlc3Npb24sIGFuZCBpdCBjYW4gbWFr ZSB0aGUgbmV0d29yayBwcm9ncmFtbWluZyBtb2RlbCAoUkZDODk4NikgYmUgZWFzaWVyIHRvIGRl cGxveS4gQ1NJRCBpcyBqdXN0IGFkZGluZyB0aGUgbmV4dCBhbmQgcmVwbGFjZSBmbGF2b3JzIGFu ZCBzdGlsbCBtYWludGFpbiBhIHNpbmdsZSBTUnY2IGJhc2VkIGRhdGEgcGxhbmUuDQoNClRoYW5r cy4NCg0KR3VpeGluIEJhbw0KQmFpZHUgIE5ldHdvcmsgQ2hpZWYgQXJjaGl0ZWN0DQoNCuWPkeS7 tuS6ujogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4g5Luj6KGoIEphbWVzIEd1aWNo YXJkIDxqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20+DQrml6XmnJ86IDIwMjHlubQxMOac iDHml6Ug5pif5pyf5LqUIDIyOjA0DQrmlLbku7bkuro6IFNQUklORyBXRyA8c3ByaW5nQGlldGYu b3JnPg0K5oqE6YCBOiAic3ByaW5nLWNoYWlyc0BpZXRmLm9yZyIgPHNwcmluZy1jaGFpcnNAaWV0 Zi5vcmc+DQrkuLvpopg6IFtzcHJpbmddIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3Jo LWNvbXByZXNzaW9uLw0KDQpEZWFyIFdHOg0KDQpUaGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gZXhw cmVzcyB0aGVpciBhcHByZWNpYXRpb24gZm9yIGFsbCB0aGUgcmVzcG9uc2VzIHJlY2VpdmVkIHRv IG91ciBlbWFpbHMgd2l0aCByZWZlcmVuY2UgdG8gaG93IHRoZSB3b3JraW5nIGdyb3VwIHdpc2hl cyB0byBtb3ZlIGZvcndhcmQgd2l0aCByZXNwZWN0IHRvIGEgc29sdXRpb24gZm9yIFNSdjYgY29t cHJlc3Npb24uDQoNClRoZSBhcHBhcmVudCBpbmNsaW5hdGlvbiBvZiB0aGUgd29ya2luZyBncm91 cCBpcyB0byB1c2UgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2Zp bHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vIGFzIHRoZSBiYXNpcyBmb3IgaXRz IGNvbXByZXNzaW9uIHN0YW5kYXJkaXphdGlvbiB3b3JrLiBUaGF0IGlzIHBhcnQgb2Ygd2hhdCB0 aGlzIGVtYWlsIGF0dGVtcHRzIHRvIGNvbmZpcm0uDQoNCkJlY2F1c2Ugb2YgdGhlIGFib3ZlIHRo ZSBjaGFpcnMgd291bGQgbGlrZSB0byBpc3N1ZSBhIDItd2VlayBXRyBjYWxsIGZvciBhZG9wdGlv biBlbmRpbmcgT2N0b2JlciAxNXRoIGZvciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8gYnV0IHdp dGggc29tZSBjbGVhciBndWlkZWxpbmVzIGFzIGZvbGxvd3MuIEJ5IGV4cHJlc3Npbmcgc3VwcG9y dCBmb3IgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCB5b3UgYXJlIGZ1bGx5IGF3YXJlIG9mIGFu ZCBhcmUgYWNrbm93bGVkZ2luZyB0aGF0Og0KDQoNCiAgMS4gIFRoZSBTUFJJTkcgd29ya2luZyBn cm91cCBpcyBhZG9wdGluZyBhIGRvY3VtZW50IHRoYXQgaGFzIG11bHRpcGxlIFNSdjYgRW5kcG9p bnQgYmVoYXZpb3JzLg0KICAyLiAgVGhlIGRvY3VtZW50IGlzIGEg4oCcbGl2aW5n4oCdIGRvY3Vt ZW50OyBpdCBtYXkgY2hhbmdlIGFzIGl0IGdvZXMgdGhyb3VnaCByZXZpZXcgYW5kIGFuYWx5c2lz IGJ5IHRoZSBTUFJJTkcgd29ya2luZyBncm91cC4NCiAgMy4gIEFsbCBvcGVuIGRpc2N1c3Npb24g cG9pbnRzIHJhaXNlZCBvbiBvdXIgbWFpbGluZyBsaXN0IE1VU1QgYmUgYWRkcmVzc2VkIEJFRk9S RSBzYWlkIGRvY3VtZW50IGlzIGFsbG93ZWQgdG8gcHJvZ3Jlc3MgZnJvbSB0aGUgd29ya2luZyBn cm91cCB0byBwdWJsaWNhdGlvbi4gQSBsaXN0IG9mIHRoZXNlIGRpc2N1c3Npb24gcG9pbnRzIHdp bGwgYmUgZG9jdW1lbnRlZCBpbiB0aGUgV0cgZG9jdW1lbnQgYW5kIG1haW50YWluZWQgYnkgdGhl IGRvY3VtZW50IGVkaXRvciBpbiBjb25qdW5jdGlvbiB3aXRoIHRoZSBjaGFpcnMuDQogIDQuICBJ ZiB0aGlzIGRvY3VtZW50IGlzIGFkb3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAsIHRoZSBjaGFp cnMgc3BlY2lmeSBhcyBwYXJ0IG9mIHRoZSBhZG9wdGlvbiBjYWxsIHRoYXQgdGhlIGZvbGxvd2lu ZyB0ZXh0IGRlc2NyaWJpbmcgYW4gb3BlbiBpc3N1ZSBiZSBhZGRlZCB0byB0aGUgZG9jdW1lbnQg aW4gdGhlIGFib3ZlLWRlc2NyaWJlZCBvcGVuIGlzc3VlcyBzZWN0aW9uOg0KICAgICAqICAgIkdp dmVuIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHNhaWQgdGhhdCBpdCB3YW50cyB0byBzdGFu ZGFyZGl6ZSBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiwgYW5kIGdpdmVuIHRoYXQgdGhlIGRvY3Vt ZW50IGNvbnRhaW5zIG11bHRpcGxlIFNSdjYgRW5kUG9pbnQgYmVoYXZpb3JzIHRoYXQgc29tZSBX RyBtZW1iZXJzIGhhdmUgc3RhdGVkIGFyZSBtdWx0aXBsZSBkYXRhIHBsYW5lIHNvbHV0aW9ucywg dGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhZGRyZXNzIHdoZXRoZXIgdGhpcyBpcyB2YWxpZCBhbmQg Y29oZXJlbnQgd2l0aCBpdHMgb25lIGRhdGEgcGxhbmUgc29sdXRpb24gb2JqZWN0aXZlLiIuDQoN ClBsZWFzZSBjb25zaWRlciB0aGUgYWJvdmUgZ3VpZGVsaW5lcyBhcyB5b3UgZGVjaWRlIG9uIHdo ZXRoZXIgdG8gc3VwcG9ydCBvciBub3QgdGhpcyBXRyBhZG9wdGlvbi4gUGxlYXNlIGV4cHJlc3Mg Y2xlYXJseSB5b3VyIHJlYXNvbmluZyBmb3Igc3VwcG9ydC9ub24tc3VwcG9ydCBhcyB3ZWxsIGFz IGFueSBvcGVuIGRpc2N1c3Npb24gcG9pbnRzIHlvdSB3b3VsZCBsaWtlIGFkZHJlc3NlZCBzaG91 bGQgdGhlIGRvY3VtZW50IGJlIGFkb3B0ZWQgaW50byB0aGUgd29ya2luZyBncm91cC4NCg0KVGhh bmtzIQ0KDQpKaW0sIEJydW5vICYgSm9lbA0KDQoNCg== --_000_03955D7A5E824088AC1C912393EA739Ebaiducom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAxIDYg MCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi XEDnrYnnur8iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxh aW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi57qv5paH 5pysIOWtl+espiI7DQoJbWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTow Y207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5hDQoJe21zby1zdHlsZS1uYW1lOiLnuq/m lofmnKwg5a2X56ymIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 57qv5paH5pysOw0KCWZvbnQtZmFtaWx5OkRlbmdYaWFuO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0 IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo3NTE2OTkz OTM7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi03MjE2 NTQ3NzYgNjc2OTg3MDMgNjc2OTg2ODkgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3 MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGww OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6 bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4t bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3Qt aWQ6OTk0MTg0NDA0Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTkyMjM5NjY5Njt9DQpAbGlz dCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21hcmdpbi1ib3R0b206 MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IlpILUNOIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiIgc3R5bGU9IndvcmQtd3JhcDpi cmVhay13b3JkIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6RGVuZ1hpYW4iPkhpLCBEZWFyIFdHPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OkRlbmdYaWFuIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6RGVuZ1hpYW4iPkkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkcmFm dC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpEZW5nWGlhbiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkRlbmdYaWFu Ij5Gcm9tIHRoZSB1c2VyIHBvaW50IG9mIHZpZXcsIEkgdGhpbmsgdGhlIENTSUQgcHJvcG9zZXMg YSBoaWdobHkgZWZmaWNpZW50IHdheSAmbmJzcDtmb3IgU1J2NiBjb21wcmVzc2lvbiwgYW5kIGl0 IGNhbiBtYWtlIHRoZSBuZXR3b3JrIHByb2dyYW1taW5nIG1vZGVsIChSRkM4OTg2KSBiZSBlYXNp ZXIgdG8gZGVwbG95Lg0KIENTSUQgaXMganVzdCBhZGRpbmcgdGhlIG5leHQgYW5kIHJlcGxhY2Ug Zmxhdm9ycyBhbmQgc3RpbGwgbWFpbnRhaW4gYSBzaW5nbGUgU1J2NiBiYXNlZCBkYXRhIHBsYW5l LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpEZW5nWGlhbiI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkRlbmdYaWFuIj5U aGFua3MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkRlbmdYaWFu Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6RGVuZ1hp YW4iPkd1aXhpbiBCYW88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 RGVuZ1hpYW4iPkJhaWR1ICZuYnNwO05ldHdvcmsgQ2hpZWYgQXJjaGl0ZWN0Jm5ic3A7Jm5ic3A7 DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6RGVuZ1hpYW4iPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OuWui+S9kztjb2xvcjpibGFjayI+5Y+R5Lu25Lq6PC9zcGFuPjwvYj48Yj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjoNCjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj5zcHJpbmcgJmx0O3NwcmluZy1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjpibGFjayI+ 5Luj6KGoPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+IEphbWVzIEd1aWNoYXJkICZsdDtqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdl aS5jb20mZ3Q7PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OuWui+S9kztjb2xvcjpibGFjayI+5pel5pyfPC9zcGFuPjwvYj48Yj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjoNCjwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj4yMDIxPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OuWui+S9kztjb2xvcjpibGFjayI+5bm0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+MTA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmJsYWNrIj7mnIg8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4xPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xv cjpibGFjayI+5pelPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTrl rovkvZM7Y29sb3I6YmxhY2siPuaYn+acn+S6lDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiAyMjowNDxicj4NCjwvc3Bhbj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6Ymxh Y2siPuaUtuS7tuS6ujwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj46DQo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+U1BSSU5HIFdHICZsdDtzcHJp bmdAaWV0Zi5vcmcmZ3Q7PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjpibGFjayI+5oqE6YCBPC9zcGFuPjwvYj48Yj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjoN Cjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj4mcXVvdDtzcHJpbmctY2hhaXJzQGlldGYub3JnJnF1b3Q7ICZsdDtzcHJpbmct Y2hhaXJzQGlldGYub3JnJmd0Ozxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseTrlrovkvZM7Y29sb3I6YmxhY2siPuS4u+mimDwvc3Bhbj48L2I+ PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij46DQo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+W3NwcmluZ10gV0cgQWRvcHRpb24gY2FsbCBmb3IgaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgt Y29tcHJlc3Npb24vPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OuWui+S9kyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+RGVhciBXRzo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPlRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBleHByZXNzIHRoZWlyIGFwcHJl Y2lhdGlvbiBmb3IgYWxsIHRoZSByZXNwb25zZXMgcmVjZWl2ZWQgdG8gb3VyIGVtYWlscyB3aXRo IHJlZmVyZW5jZSB0byBob3cgdGhlIHdvcmtpbmcgZ3JvdXAgd2lzaGVzIHRvIG1vdmUgZm9yd2Fy ZCB3aXRoIHJlc3BlY3QgdG8gYSBzb2x1dGlvbiBmb3IgU1J2NiBjb21wcmVzc2lvbi4NCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+VGhlIGFwcGFyZW50IGluY2xpbmF0aW9uIG9mIHRoZSB3b3JraW5nIGdy b3VwIGlzIHRvIHVzZQ0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vIj4NCmh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNy djYtc3JoLWNvbXByZXNzaW9uLzwvYT4gYXMgdGhlIGJhc2lzIGZvciBpdHMgY29tcHJlc3Npb24g c3RhbmRhcmRpemF0aW9uIHdvcmsuIFRoYXQgaXMgcGFydCBvZiB3aGF0IHRoaXMgZW1haWwgYXR0 ZW1wdHMgdG8gY29uZmlybS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJlY2F1c2Ugb2YgdGhlIGFib3Zl IHRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBpc3N1ZSBhIDItd2VlayBXRyBjYWxsIGZvciBhZG9w dGlvbiBlbmRpbmcgT2N0b2JlciAxNTxzdXA+dGg8L3N1cD4gZm9yDQo8YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2 LXNyaC1jb21wcmVzc2lvbi8iPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vPC9hPiBidXQgd2l0 aCBzb21lIGNsZWFyIGd1aWRlbGluZXMgYXMgZm9sbG93cy4gQnkgZXhwcmVzc2luZyBzdXBwb3J0 IGZvciBhZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IHlvdSBhcmUgZnVsbHkgYXdhcmUgb2YgYW5k IGFyZSBhY2tub3dsZWRnaW5nIHRoYXQ6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPG9sIHN0eWxlPSJtYXJnaW4tdG9wOjBjbSIgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxp IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0 OmwwIGxldmVsMSBsZm8zIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIFNQUklORyB3b3JraW5nIGdy b3VwIGlzIGFkb3B0aW5nIGEgZG9jdW1lbnQgdGhhdCBoYXMgbXVsdGlwbGUgU1J2NiBFbmRwb2lu dCBiZWhhdmlvcnMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsMCBsZXZlbDEgbGZvMyI+ PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBkb2N1bWVudCBpcyBhIOKAnGxpdmluZ+KAnSBkb2N1bWVu dDsgaXQgbWF5IGNoYW5nZSBhcyBpdCBnb2VzIHRocm91Z2ggcmV2aWV3IGFuZCBhbmFseXNpcyBi eSB0aGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDps MCBsZXZlbDEgbGZvMyI+PHNwYW4gbGFuZz0iRU4tVVMiPkFsbCBvcGVuIGRpc2N1c3Npb24gcG9p bnRzIHJhaXNlZCBvbiBvdXIgbWFpbGluZyBsaXN0IE1VU1QgYmUgYWRkcmVzc2VkIEJFRk9SRSBz YWlkIGRvY3VtZW50IGlzIGFsbG93ZWQgdG8gcHJvZ3Jlc3MgZnJvbSB0aGUgd29ya2luZyBncm91 cCB0byBwdWJsaWNhdGlvbi4gQSBsaXN0DQogb2YgdGhlc2UgZGlzY3Vzc2lvbiBwb2ludHMgd2ls bCBiZSBkb2N1bWVudGVkIGluIHRoZSBXRyBkb2N1bWVudCBhbmQgbWFpbnRhaW5lZCBieSB0aGUg ZG9jdW1lbnQgZWRpdG9yIGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIGNoYWlycy4NCjxvOnA+PC9v OnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj48c3BhbiBsYW5nPSJFTi1VUyI+SWYg dGhpcyBkb2N1bWVudCBpcyBhZG9wdGVkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLCB0aGUgY2hhaXJz IHNwZWNpZnkgYXMgcGFydCBvZiB0aGUgYWRvcHRpb24gY2FsbCB0aGF0IHRoZSBmb2xsb3dpbmcg dGV4dCBkZXNjcmliaW5nIGFuIG9wZW4gaXNzdWUgYmUgYWRkZWQgdG8gdGhlDQogZG9jdW1lbnQg aW4gdGhlIGFib3ZlLWRlc2NyaWJlZCBvcGVuIGlzc3VlcyBzZWN0aW9uOiA8bzpwPjwvbzpwPjwv c3Bhbj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNz PSJNc29QbGFpblRleHQiIHN0eWxlPSJtc28tbGlzdDpsMCBsZXZlbDIgbGZvMyI+PHNwYW4gbGFu Zz0iRU4tVVMiPiZxdW90O0dpdmVuIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHNhaWQgdGhh dCBpdCB3YW50cyB0byBzdGFuZGFyZGl6ZSBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiwgYW5kIGdp dmVuIHRoYXQgdGhlIGRvY3VtZW50IGNvbnRhaW5zIG11bHRpcGxlIFNSdjYgRW5kUG9pbnQgYmVo YXZpb3JzIHRoYXQgc29tZSBXRyBtZW1iZXJzDQogaGF2ZSBzdGF0ZWQgYXJlIG11bHRpcGxlIGRh dGEgcGxhbmUgc29sdXRpb25zLCB0aGUgd29ya2luZyBncm91cCB3aWxsIGFkZHJlc3Mgd2hldGhl ciB0aGlzIGlzIHZhbGlkIGFuZCBjb2hlcmVudCB3aXRoIGl0cyBvbmUgZGF0YSBwbGFuZSBzb2x1 dGlvbiBvYmplY3RpdmUuJnF1b3Q7LjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjwvbGk+ PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+UGxlYXNlIGNvbnNpZGVyIHRoZSBhYm92ZSBndWlkZWxpbmVzIGFzIHlvdSBkZWNpZGUgb24g d2hldGhlciB0byBzdXBwb3J0IG9yIG5vdCB0aGlzIFdHIGFkb3B0aW9uLiBQbGVhc2UgZXhwcmVz cyBjbGVhcmx5IHlvdXIgcmVhc29uaW5nIGZvciBzdXBwb3J0L25vbi1zdXBwb3J0IGFzIHdlbGwg YXMgYW55IG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgeW91IHdvdWxkIGxpa2UgYWRkcmVzc2VkDQog c2hvdWxkIHRoZSBkb2N1bWVudCBiZSBhZG9wdGVkIGludG8gdGhlIHdvcmtpbmcgZ3JvdXAuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5UaGFua3MhPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5KaW0sIEJydW5vICZh bXA7IEpvZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_03955D7A5E824088AC1C912393EA739Ebaiducom_-- From nobody Thu Oct 14 02:43:35 2021 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 B33013A114A; Thu, 14 Oct 2021 02:42:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdnAyTkfzrV1; Thu, 14 Oct 2021 02:42:16 -0700 (PDT) Received: from mail-oi1-x231.google.com (mail-oi1-x231.google.com [IPv6:2607:f8b0:4864:20::231]) (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 215A93A0EA5; Thu, 14 Oct 2021 02:42:15 -0700 (PDT) Received: by mail-oi1-x231.google.com with SMTP id m67so7703890oif.6; Thu, 14 Oct 2021 02:42:15 -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=vkXcIZO9gAu65Y5MA+5kgj7MSR+6Kx+ctDQGRQge20M=; b=NsdTa25XBbHBLSrjCwVod0Kq0PMmR7QlRVLgHEgaPBLdAU8UgxCgBRUpxmd2uiZxsA ut63Z4HY4t791rpv3xr4YOU+tcJ2l+tQi2w4RKfEz67Fj2t/0lkdyQMUbHcc8+Y+qLhV j3twunayrlcMg7RRRq+5jyhP3I04nWDV5ifuwgleS77EkCNRzwFArqPTtxp1T0IDaSrb GRs4E7G2Aa14XRnzp4QnLtX99SsydkjNA7hetO7DVQawegALHFF6CsKOchUhiaoEdRbn or1BFFWLlaZHccnoelJ6E9Su4zfVY0I7kDEfCnkb2r/ArkjXowQ3aePZtDLjk1RADXo1 n1Zg== 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=vkXcIZO9gAu65Y5MA+5kgj7MSR+6Kx+ctDQGRQge20M=; b=evSywoEHYf5ou6w4AZIX5rSKTFUDdavKx4ejIedh79K90kYoazm//KDu+PAeo9EqSI 1j5tTOApyne3uBrSPJp06HFZib8r2J5qEmxKleHwpUNDGGs1CIZAP6YbnMNz2/eOdCYA vWmVWxA1KQ1Q0rbGfeZWypR1ipNUViTe83lFHXmv5r8OivlPoUuVshGo1msoAX/FojFY T4UDICv3qOXma/EAaJ5Emdbr7DSqnLX3tD461Dte2LzVWwEhFpbY/tmyt54HoQGfoqaz 1Dxw236KCFlMgUuuPxa4OkYlY3TwfveyF1TnuGB4d2v9FYKTi1m1xXE0FiY1gMsRC1pK fBmQ== X-Gm-Message-State: AOAM531n5G0apTI8+4VUfKygT9qDvHhSGuFS0EWFVYzAfHYC4idlodVk CF0um4oEGJrxv2YI/Ne2s1cXeMVveTdNhtJuB3g= X-Google-Smtp-Source: ABdhPJzOdafYZpipSDdGFkiU2RRc9ksA5c5D92d8LqZFFbgQAEPdSPdEbPOpVZLHuBpQH/u9xyUmTdQhziDJ2NLg87A= X-Received: by 2002:aca:5bd6:: with SMTP id p205mr205950oib.35.1634204534005; Thu, 14 Oct 2021 02:42:14 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <1daf3d20-22b2-d111-5131-bd53f51c53a3@gmail.com> In-Reply-To: <1daf3d20-22b2-d111-5131-bd53f51c53a3@gmail.com> From: Ted Hardie Date: Thu, 14 Oct 2021 10:41:47 +0100 Message-ID: To: Brian E Carpenter Cc: "Joel M. Halpern" , "ipv6@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bd636405ce4ce4f2" Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 14 Oct 2021 09:42:23 -0000 --000000000000bd636405ce4ce4f2 Content-Type: text/plain; charset="UTF-8" On Wed, Oct 13, 2021 at 9:28 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > > > Including semantics *of any kind* in an IP address is a very fundamental > change to the concept of IP. Would you mind elaborating what you mean by semantics in the statement above? Clearly there are semantics in things like the IPv4 multicast and experimental address ranges (aka "Class D" and "Class E"); especially for the multicast case, the very fundamental semantics of the distribution are signalled using the address and there has been significant deployment using those semantics. Isn't that semantics in the meaning above? Thanks for any clarification, Ted --000000000000bd636405ce4ce4f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Wed, Oct 13, 2021 at 9:28 PM Brian E Carpenter <brian.e.carpenter@gmail.com>= wrote:


    Including semantics *of any kind* in an IP address is a very fundamental change to the concept of IP.

    Would you mind ela= borating what you mean by semantics in the statement above?=C2=A0 Clearly t= here are semantics in things like the IPv4 multicast and experimental addre= ss ranges (aka "Class D" and "Class E"); especially for= the multicast case, the very fundamental semantics of the distribution are= signalled using the address and there has been significant deployment usin= g those semantics.=C2=A0 Isn't that semantics in the meaning above?

    Thanks for any clarification= ,

    Ted

    <= /div>
    --000000000000bd636405ce4ce4f2-- From nobody Thu Oct 14 03:52:56 2021 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 18F9C3A12DC; Thu, 14 Oct 2021 03:52:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvsJS0mShKLZ; Thu, 14 Oct 2021 03:52:49 -0700 (PDT) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F0C3A12DA; Thu, 14 Oct 2021 03:52:46 -0700 (PDT) Received: from smtpclient.apple (p5089a8ac.dip0.t-ipconnect.de [80.137.168.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4HVR7Z1wMYz2xLf; Thu, 14 Oct 2021 12:52:42 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Carsten Bormann In-Reply-To: <1daf3d20-22b2-d111-5131-bd53f51c53a3@gmail.com> Date: Thu, 14 Oct 2021 12:52:41 +0200 Cc: "Joel M. Halpern" , "ipv6@ietf.org" , "spring@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <858A5EDC-1207-4759-8298-1220ED233532@tzi.org> References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <1daf3d20-22b2-d111-5131-bd53f51c53a3@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 14 Oct 2021 10:52:54 -0000 On 13. Oct 2021, at 22:26, Brian E Carpenter = wrote: >=20 > Including semantics *of any kind* in an IP address is a very = fundamental > change to the concept of IP. I may be wrong, but I'm not aware that = any > RFCs prior to SRV6 have done this, and the founding reference for what=20= > an address *is* still seems to be IEN19 [1]. One reason may be that you don=E2=80=99t need an RFC to do that. I don=E2=80=99t have the references handy, but people have been = allocating a whole /64 to a single end-system (*) for quite a while. E.g., see = https://serverfault.com/questions/936848/adding-a-whole-ipv6-64-block-to-a= -server-using-netplan for a discussion on how to do this with Linux. The IID then becomes =E2=80=9CSemantics=E2=80=9D (like the port number = already is). Gr=C3=BC=C3=9Fe, Carsten (*) Not exactly a =E2=80=9Chost=E2=80=9D any more, so maybe there is = room for an RFC here=E2=80=A6 From nobody Thu Oct 14 05:54:03 2021 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 892653A084F for ; Thu, 14 Oct 2021 05:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 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, 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=g3z4fyrE; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=iCeoj1/y 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 XkMPis7efeeZ for ; Thu, 14 Oct 2021 05:53:57 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD50D3A0414 for ; Thu, 14 Oct 2021 05:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=49182; q=dns/txt; s=iport; t=1634216036; x=1635425636; h=from:to:subject:date:message-id:mime-version; bh=F+Jq2bLBEhs6gKmKEPjNUYXclDArjUdEemSKrAuiKrc=; b=g3z4fyrEtyKyIsweDSOCiM5GPLpHGsEn4no2MmpgkXvU9prLbRmRT1XJ FL8cz61Z+NMx15rgvDOgh2twysqFrKcrTL84prry6Ogg9dB81YMJCWpwu g2ayIebG7B77c4zEllKfc+ZLSPjBBZ+isxUGlPWqWhiYlk5E6FTlGj3Ci o=; IronPort-PHdr: =?us-ascii?q?A9a23=3ALgHUvBALCrJObwji9PWlUyQVdBdPi9zP1kY96?= =?us-ascii?q?5c7hfRJaKvwt5jhPUmK4/JrgReJWIjA8PtLhqLQtLyoQm0P55uN8RVgOJxBX?= =?us-ascii?q?hMIk4MaygonBsPWCEDnIrjtdSNpVMhHXUVuqne8N0UdEc3iZlrU93u16zNaG?= =?us-ascii?q?hj2OQdvYOrvHYuHhMWs3Of08JrWMG11?= IronPort-Data: =?us-ascii?q?A9a23=3AfOegKq9E9nTUmj6ynNOPDrUDnXyTJUtcMsCJ2?= =?us-ascii?q?f8bNWPcYEJGY0x3xmEfXDzVaK6JMWbxfYwnO9609h5V7JDTm4BmGgQ6rHpEQ?= =?us-ascii?q?iMRo6IpJzg2wmQcns+qw0aqoHtPt63yUfGdapBpJpPgjk31aOG49SAgjfjgq?= =?us-ascii?q?ofUUYYoBAggHWeIdw954f5Ts7ZRbr9A2bBVMSvU0T/Bi5W31Gue5tJBGjl8B?= =?us-ascii?q?5RvB/9YlK+aVDsw5jTSbB3Q1bPUvyF94Jk3fcldI5ZkK7S4ENJWR86bpF241?= =?us-ascii?q?nnS8xFoAdS/n/OiKgsBQ6XZOk6FjX8+t6qK20cZ4HdtlPdgcqNANy+7iB3R9?= =?us-ascii?q?zx14NlBqJ+9Ui8iP7bHn6IWVBww/yRWY/IZo+aYeCjm2SCU5wicG5f2+N11F?= =?us-ascii?q?Fs3O4Iw++trDydJ7/NwFdynRnhvnMqsy769D+JrnMlmdZGtN4IEsXYmxjbcZ?= =?us-ascii?q?cvKiKvrG83ijeK0Fh9r7iyWIcvjWg=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3A0rLUS6msXXpU6hn+6bslQrO4U6fpDfOTim?= =?us-ascii?q?dD5ihNYBxZY6Wkfp+V/cjzhCWbtN9OYh4dcIi7SdO9qADnhONICOgqTPuftW?= =?us-ascii?q?zd2FdAQ7sSlbcKrweQfhEWldQtmpuIEZIOc+EYZGIS5a2RjWXIcKdD/DDtyt?= =?us-ascii?q?HOuQ6q9QYVcegcUdAH0+4WMHf+LmRGAC19QbYpHpuV4cRK4xC6f24MU8i9Dn?= =?us-ascii?q?4ZG8DeutzijvvdEFA7Li9izDPLoSKj6bb8HRTd9AwZSSlzzbAr9nWAuxDl55?= =?us-ascii?q?+kr+qwxnbnpi7uBtVt6ZvcI+l4dY6xY/suW3DRY8GTFcBcsoi5zXMISSeUmR?= =?us-ascii?q?EXeZf30lEd1o9Img/slymO0GTQMk/boW8TA7uI8y7CvZMlyvaJHA7SQvAx+7?= =?us-ascii?q?5xY1/X7VEts8p7178O12WFt4BPBReFhyjl4cPUPisa3nZcjEBS59L7tUYvGL?= =?us-ascii?q?f2qYUh37A37QdQCtMNDSj64IcoHK1nC9zd/u9fdRefY2rCtmdizdSwVjBrdy?= =?us-ascii?q?32CHQqq4iQyXxbjXp5x0wXyIgWmWoB7os0T91B6/7fOqplmblSRosdbL57Bu?= =?us-ascii?q?0GXcyrY1a9Ci7kISaXOxDqBasHM3XCp9r+56g0/vijfNgSwJ47iP36ISRlXK?= =?us-ascii?q?4JCjbT4Oi1rdB2Gzz2MRWAtAXWu7RjDsJCy8zBrZLQQF6+dGw=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CaDADGJ2hh/5JdJa1agQmCejBRB3d?= =?us-ascii?q?aNzGIDgOFOYVmgiWac4JTA1QLAQEBDQEBQQQBAYR+AoJJAiU4EwECBAEBARI?= =?us-ascii?q?BAQUBAQECAQYEgREThWgNhlsuAQE4EQFAAT8nBBsaglCBflcDLwGgFQGBOgK?= =?us-ascii?q?KH3iBM4EBgggBAQYEBIUKGII1CYE6gwSEEoccHIFJRIEUAQFCeYY+CgEqg02?= =?us-ascii?q?CLotEUhluCwmBDnYHAWWeWo1OkisKgzCYCIcCFIQsomuWCKB4hHMCBAIEBQI?= =?us-ascii?q?OAQEGgXgkgVlwFTuCaVEZD44sFoNQil50OAIGCwEBAwmQWgEngh4BAQ?= X-IronPort-AV: E=Sophos;i="5.85,372,1624320000"; d="scan'208,217";a="677317181" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Oct 2021 12:53:55 +0000 Received: from mail.cisco.com (xbe-rcd-006.cisco.com [173.37.102.21]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 19ECrtFk018825 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Thu, 14 Oct 2021 12:53:55 GMT Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xbe-rcd-006.cisco.com (173.37.102.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 14 Oct 2021 07:53:55 -0500 Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 14 Oct 2021 07:53:54 -0500 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Thu, 14 Oct 2021 07:53:54 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=maKh2Lk08v1ADG+1nSGEWSODnCJyMaxbtF+tDzUptCCm71E7Ns+FVTLiBkgLx89NO2SDpfqCg2DC0dllSZE4Ay4UiZBsmXGu7HMpd8Pr1gv92J0mXCV++uC+k0z/UOu3AGK3RW/KgrduJrXw+jGRgKtO2EDeGzGopXNc3uIaJ+7p8hFRuaf8ru1ZVucmeRSwTbFcJOooIZUkiOml0aLA9INTKC+3GxsKevjmxW7NiCIWk0Ytq7AzKZcLrmcbxMG6rACX6R/ZamH9FQpZV5y54dUHKzParEv8BOOnaeVvb8DPCHBaR1smQDKE9z2C7idiOBDlIYeaHJOl0vE/2Y0yNA== 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=0JVELuubPBJ4kHTVdGuzvLCoG6AJpbQIwfxpv6uEPQ8=; b=dpkLaXIeufNv5Dwx6yJ/KaimLhb36eT4usYKTq6QCJIM1790tPGM1Hl+HJ7CjDWb0rNc/x2IBEP6e+s+QmYvZR2+KwYO9Gjp8dMz7LGwE+tYfjjowNQBkbV5ACplnfVKX6KFSyFRyoyOwPBINEilU4qwTUb9WZC3pZ8oPp2n/Hqb5Jw+WfQ/aL8068cV1j/VdcvPNor7q0BpF5qc/8PRCmqcvzmY1Evg6Ap/rhr+pZnROv+1y/ASB0NDQOoJRhD8RxzvZJjn4Gt3U4E9n2qQNXl9fcDDrWz27aaR+51Sb+cJ0k2vjzJ7zTOTMz7W9FpABIwV+Q7zJptFPMQmoUjaQQ== 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=0JVELuubPBJ4kHTVdGuzvLCoG6AJpbQIwfxpv6uEPQ8=; b=iCeoj1/ya5OGbwQ+0T7j8lnR9WEkN0y1SfcIvI9kQJpZNnhob5cZko51y99sG9CZh58GjpnXnWwQnnFiIRUenoTygWTiBaqjyEMZ7NNKW62xsA1CcgChFquDJ4GT+UvTgc/g8BB3DR39/nVasARLm0vGYxcEitVOhpkDVAyNN9c= Received: from BN6PR11MB4081.namprd11.prod.outlook.com (2603:10b6:405:78::38) by BN6PR11MB3905.namprd11.prod.outlook.com (2603:10b6:405:82::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.22; Thu, 14 Oct 2021 12:53:48 +0000 Received: from BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::90c7:290e:a57c:1a39]) by BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::90c7:290e:a57c:1a39%3]) with mapi id 15.20.4608.017; Thu, 14 Oct 2021 12:53:48 +0000 From: "Darren Dukes (ddukes)" To: SPRING WG Thread-Topic: CSID proposed clarifications Thread-Index: AQHXwPmD76WD43ON70uWpO9ECDy+Zg== Date: Thu, 14 Oct 2021 12:53:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1e34bd9c-01ac-45e7-6fbe-08d98f11aa3f x-ms-traffictypediagnostic: BN6PR11MB3905: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: fEHgUrvE94Ji3DewzXBt3S6qbrlGit2ob87YkKdMjP5XSK4skD8Ia72V3xGwdknvW6zVfKhrMqnaJwYoFXifaHSP6KDfen2TU2ZcIzvjFjpn/es5+aWRwuXSMEnz9AuJ6U0g7tu2NNDYxGjmm6dBJqxD7dSfACACuJSpRYjci8LX52aorsHvreVgX5MSsg5qRexwEnole//Wb1+tZ5xDRPs7tkUzCx9EFU8gs6kc22eiMXf3vy7n5+XyeC4D4htN+1IIw6yvuih8NeCuBqN+7BhWDUVZw9H98/SdMysLAXF8chzVtqKZ8Hn6ood3v2t2xwV6ZD3ldpPgYG03wgmte/dcH9BD83g06RE5ooAH1i9PT/wd8jSsu4tNaN+1S9k1o/dUE4blkGxN8tg3V6L2L3GIaBdmoEkfmIVDM6VJD3pp9cC/YccXl3tmtFCTw7Mo69x5kd7xqsccXduzLR1fvQfG1YiNh47Nt7YYWV23vneQtD2RCkXl7G1iap4TRm6nt49tCNtlghpBdsG0LVktIpp2YR8j7IFj2nqgBil8VLDi763Nw37KO22AtG2AfXHlX6Hxwl9HQcx+zxyalIonvQM2SxUrMFamBBBVlSga9LVt0ZXgbhqCk6CTShZXNehz5Qa8OICtZiHo1aQoxE+IGIrJKpZ8vEW1G3PeE5OZn0r8f98zTDSzRg1gy7zwLKAQcrwtnAXiF+GJMv8tdvGIvw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB4081.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(33656002)(5660300002)(316002)(186003)(66476007)(55016002)(71200400001)(7696005)(8936002)(6916009)(8676002)(26005)(3480700007)(2906002)(7116003)(122000001)(6506007)(91956017)(52536014)(66946007)(76116006)(86362001)(9686003)(38100700002)(66446008)(66556008)(83380400001)(64756008)(508600001)(38070700005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?czSXeDryNOf6U77T3/M4lwqSU3m+rZTTXefjCSFkePXSWucjDVfaK7X1?= =?Windows-1252?Q?riAvAUQyGBmYI6oCCRvQaLCnZnKFX7jPrQcXuPSieor05gqC6DjkEtun?= =?Windows-1252?Q?47j6XhYoHI/p5JSRoZH35ri32XgSdPmPc39E+V61Z1ggEM9QrY18iU72?= =?Windows-1252?Q?ujtV9gKG6mpLATwcucbSOL4Y1udhLHw0MxfK6WdIpl4oP6VspyWfVCF9?= =?Windows-1252?Q?yb1oQBjZPmywKDrlntOSZDx+YUlwEOpZnRM41070eEBE7ibvCz7d+nSM?= =?Windows-1252?Q?C1SnPQE7uQcVLX0vQiIA4ZjcAjf8xWStKmayJyir7W0CBuvqK2StKT5d?= =?Windows-1252?Q?YnIlxX4PA0v+gY2E36Lw+CHGEcILRT+KBYaKn2K2giCx2DTjtslXf4f5?= =?Windows-1252?Q?KVkdlzAqMz7zPHRoPLiUBBL72P53mGlMEeX9tJJ9PAnRtCFi/jjTNZ3Y?= =?Windows-1252?Q?xGprtxxwSdA5HwODm1VkC03aqHUpnD+flSQjHN2W65tMGOy2au2fMA8r?= =?Windows-1252?Q?c1SyCozEtMrMoLplwXPmkvXso1UWrW7h+SllivOv3FRwu5xRaaQQx2hq?= =?Windows-1252?Q?mgs0E8VnGksn23guUMhX+XXQnMzfsE1MmDaKzFqYX/B1bywE3eFtOwyA?= =?Windows-1252?Q?HnZBzxRyZpSVgzmY+FLUlUysp/r7v0vqM6U7hEMaNCYtjXbjxHksFjRD?= =?Windows-1252?Q?hc6MDYy+REu8EQi/cIc+vMUhpB45mM0TnyYmUDuMoXDJ1jfWY3TfVUcl?= =?Windows-1252?Q?2JEwGAlpw3u8FU0d3jOTeBF9vJWJvG/DbW60e5X75zbYxsbGz2WbcsP1?= =?Windows-1252?Q?QAv1rQXdY4HTl5QKH8x75VCu8VtSsxaUScpKTOEWotToMgWDI3Uiersn?= =?Windows-1252?Q?a/bHQ4HeWEIGDSkMCv1vZ4LDsFRg0uh6IEOmnCsUEo4B9MMB8BlwgGw+?= =?Windows-1252?Q?hcV9ZYiaLs6uqRRXJamXKh53kaavJPmMoYBCPAKZNx2p/dowADZdesEH?= =?Windows-1252?Q?xVISzwwLu8BlbNarb1GOCDd7A560y4LPjcup3Fgr6c8bJ+RbM0GR44WV?= =?Windows-1252?Q?AJLMeEWg7CqQu0/NgIccvqI/vxR8gm8cZ6m8Fx+XHkXsgSGKT3nKaKVE?= =?Windows-1252?Q?pQd1Y/o7AYozDaGKvAgBuwPfAD5vlHnPIbm43Dn5+shPEmvWI0aCNpdi?= =?Windows-1252?Q?psYfLnzx0fgQZvoNzmO0wJ9KYNqbcIgs72UqC+V67BI3up8iiB2KUMsI?= =?Windows-1252?Q?MaHJ6xs1GiX1vtU6lS2HHggkYh/e+GQogg6T7dIDzltgBG8w/jrUP+fr?= =?Windows-1252?Q?SdMJD4zeXnlvS8a45BkqbFBru+f2MmzUBRFnJKe7lme1AyjQ1ewbQntI?= =?Windows-1252?Q?9scJBzvqDYOITxUvRSGZB4CqXz3Y+id08vS6rl9Qa9aRT1qZHUia4574?= =?Windows-1252?Q?D1nH1cSTsEgD44QIYgbkLQ=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN6PR11MB40815FF94A9509B46469A4F4C8B89BN6PR11MB4081namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN6PR11MB4081.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1e34bd9c-01ac-45e7-6fbe-08d98f11aa3f X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2021 12:53:48.1726 (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: Qkd+1gz+P1rVtnAMqiMRYbF1bZXxDHtuSAze+Bo3eUR+wShCg+mSSvAsusClFNeGaa8aCT+smF8rDyyAgBr4lA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB3905 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.21, xbe-rcd-006.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: [spring] CSID proposed clarifications 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, 14 Oct 2021 12:54:02 -0000 --_000_BN6PR11MB40815FF94A9509B46469A4F4C8B89BN6PR11MB4081namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The NEXT-C-SID and REPLACE-C-SID flavors are functionally very similar. In both cases the SID in the IPv6 Destination Address (DA) contains an argu= ment, that argument is used to construct the next SID from the active segment in the SRH Segment List. I believe the following pseudocode is a much better description of their segment endpoint processing. You=92ll notice there is no manipulation of the bits in the IPv6 DA. I propose we replace the pseudocode in the draft with the following, stand-alone pseudocode, for the NEXT-C-SID and REPLACE-C-SID flavors of the END behavior (sections 4.1.1 and 4.2.1 respectively). Equivalent changes can be completed for the NEXT-C-SID and REPLACE-C-SID flavors of the END.X behavior (sections 4.1.2 and 4.2.2 respectively) and NEXT-AND-REPLACE-C-SID flavor. Comments are appreciated. Thanks Darren 4.1.1. End with NEXT-C-SID When processing an IPv6 packet that matches a FIB entry locally instantiated as an End SID with the NEXT-C-SID flavor, the SRH processing described in Section 4.1 of [RFC8986] is replaced as follows. S.01 When an SRH is processed { S.02 If (IPv6.DA.Argument =3D=3D 0 and SRH.SegmentsLeft =3D=3D 0) { S.03 Stop processing the SRH, and proceed to process the next header in the packet, whose type is identified by the Next Header field in the routing header. S.04 } S.05 If (IPv6.HopLimit <=3D 1) { S.06 Send an ICMP Time Exceeded message to the Source Address with Code 0 (Hop limit exceeded in transit), interrupt packet processing, and discard the packet. S.07 } S.08 # Determine the maximum SRH Last Entry S.09 Set maxLE to ((SRH.HdrExtLen / 2) - 1) S.10 Initialize 128-bit buffer memory S to 0. S.11 Initialize local parameter Argument to the value of IPv6.DA.Argument S.12 If (Argument =3D=3D 0) { S.13 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)= ) { S.14 Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S.15 } S.16 Decrement SRH.SegmentsLeft by 1 S.17 Set S to the value of SRH.SegmentList[SRH.SegmentsLeft] S.18 } S.19 Else { S.20 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)= ) { S.21 Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S.22 } S.23 Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common loc= ator block) S.24 If (SRH.SegmentsLeft > SRH.LastEntry) { S.25 Initialize local parameter ActiveSegment to the value of DA S.26 } S.27 Else { S.28 Initialize local parameter ActiveSegment to the value S.29 of SRH.SegmentList[SRH.SegmentsLeft] S.30 } S.31 Initialize local parameter BitLength to (CountTrailingZeros(ActiveS= egment) + AL - CountTrailingZeros(A= rgument)) S.32 Initialize local parameter BitIndex to (128 =96 BitLength) S.33 Set S[B..B+BitLength-1] to the value of ActiveSegment[BitIndex..(BitIndex+BitLength-1)] S.34 } S.35 Set IPv6.DA to the value of S S.36 Decrement IPv6.HopLimit by 1 S.37 Submit the packet to the egress IPv6 FIB lookup for transmission to the new destination. S.38 } 4.1.1.1 Upper layer header processing The upper-layer header processing described in Section 4.1.1 of [RFC8986] is replaced as follows. S.01 Initialize local parameter Argument to the value of IPv6.DA.Argument S.02 If (Argument !=3D 0) { # In this case, the SRH was not added by source # The source compressed it into the active segment in IPv6.DA # Build a pseudo header from the active segment in the IPv6.DA for = use # during processing. S.03 Initialize a 24-byte local SRH in memory to 0=92s for use below S.04 Set SRH.MaxHdrLen to 3 S.05 Set SRH.RoutingType to 4 S.06 Set SRH.SegmentsLeft to 0 S.07 Set SRH.SegmentList[0] to the value of IPv6.DA S.08 Process the SRH as per section 4.1.1, S.09 noting such processing is limited to the pseudo SRH S.10 since Argument is not 0. S.11 } S.12 If (Upper-Layer header type is allowed by local configuration) { S.13 Proceed to process the Upper-Layer header S.14 } Else { S.15 Send an ICMP Parameter Problem to the Source Address with Code 4 (SR Upper-layer Header Error) and Pointer set to the offset of the Upper-Layer header, interrupt packet processing, and discard the packet. S.16 } 4.2.1. End with REPLACE-C-SID When processing an IPv6 packet that matches a FIB entry locally instantiated as an End SID with the REPLACE-C-SID flavor, the SRH processing described in Section 4.1 of [RFC8986] is replaced as follows. S.01 When an SRH is processed { S.02 If (IPv6.DA.Argument =3D=3D 0 and SRH.SegmentsLeft =3D=3D 0) { S.03 Stop processing the SRH, and proceed to process the next header in the packet, whose type is identified by the Next Header field in the routing header. S.04 } S.05 If (IPv6.HopLimit <=3D 1) { S.06 Send an ICMP Time Exceeded message to the Source Address with Code 0 (Hop limit exceeded in transit), interrupt packet processing, and discard the packet. S.07 } S.08 # Determine the maximum SRH Last Entry S.09 Set maxLE to ((SRH.HdrExtLen / 2) - 1) S.10 Initialize 128-bit buffer memory S to 0. S.11 Initialize local parameter Argument to the value of IPv6.DA.Argument S.12 Initialize local parameter ActiveSegment to SRH.SegmentList[SRH.Segme= ntsLeft] S.13 If (Argument =3D=3D 0) { S.14 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)= ) { S.15 Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S.16 } S.17 Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common loc= ator block) S.18 Decrement SRH.SegmentsLeft by 1 S.19 Set Argument to (128 / NF - 1) S.20 } S.21 Else { S.22 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry)) = { S.23 Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S.24 } S.25 Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common loc= ator block) S.26 Decrement Argument by 1 S.27 } S.28 Initialize local parameter BitLength to the value of NF S.29 Initialize local parameter BitIndex to (Argument * NF) S.30 Set S[B..B+BitLength-1] to the value of ActiveSegment[BitIndex..(BitIndex+BitLength-1)] S.32 Set S[B+BitLength..B+BitLength+A-1] to the value of Argument S.33 Set IPv6.DA to the value of S S.34 Decrement IPv6.HopLimit by 1 S.35 Submit the packet to the egress IPv6 FIB lookup for transmission S.36 to the new destination. S.37 } 4.2.1.1. Upper layer header processing The upper-layer header processing described in Section 4.1.1 of [RFC8986] i= s unchanged and reproduced below. S.01 If (Upper-Layer header type is allowed by local configuration) { S.02 Proceed to process the Upper-Layer header S.03 } Else { S.04 Send an ICMP Parameter Problem to the Source Address with Code 4 (SR Upper-layer Header Error) and Pointer set to the offset of the Upper-Layer header, interrupt packet processing, and discard the packet. S.05 } --_000_BN6PR11MB40815FF94A9509B46469A4F4C8B89BN6PR11MB4081namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    The NEXT-C-SID and REPLACE-C-SID flavors ar= e functionally very similar.

    In both cases the SID in the IPv6 Destinati= on Address (DA) contains an argument,

    that argument is used to construct the next= SID from the active segment in

    the SRH Segment List.

     

    I believe the following pseudocode is a muc= h better description of their

    segment endpoint processing. You=92ll notic= e there is no manipulation of

    the bits in the IPv6 DA.<= /p>

     

    I propose we replace the pseudocode in the = draft with the following,

    stand-alone pseudocode, for the NEXT-C-SID = and REPLACE-C-SID flavors

    of the END behavior (sections 4.1.1 and 4.2= .1 respectively).

     

    Equivalent changes can be completed for the= NEXT-C-SID and REPLACE-C-SID

    flavors of the END.X behavior (sections 4.1= .2 and 4.2.2 respectively) and

    NEXT-AND-REPLACE-C-SID flavor.

     

    Comments are appreciated.=

     

    Thanks

      Darren

     

    4.1.1.  End with NEXT-C-SID

     

    When processing an IPv6 packet that matches= a FIB entry locally

    instantiated as an End SID with the NEXT-C-= SID flavor, the SRH

    processing described in Section 4.1 of [RFC= 8986] is replaced as

    follows.

     

     

    S.01 When an SRH is processed {<= /span>

    S.02  If (IPv6.DA.Argument =3D=3D 0 an= d SRH.SegmentsLeft =3D=3D 0) {

    S.03     Stop processin= g the SRH, and proceed to process the next

           &= nbsp; header in the packet, whose type is identified by

           &= nbsp; the Next Header field in the routing header.

    S.04  }

     

    S.05  If (IPv6.HopLimit <=3D 1) {

    S.06     Send an ICMP T= ime Exceeded message to the Source Address

           &= nbsp; with Code 0 (Hop limit exceeded in transit),

           &= nbsp; interrupt packet processing, and discard the packet.

    S.07  }

     

    S.08  # Determine the maximum SRH Last= Entry

    S.09  Set maxLE to ((SRH.HdrExtLen / 2= ) - 1)

     

    S.10  Initialize 128-bit buffer memory= S to 0.

    S.11  Initialize local parameter Argum= ent to the value of IPv6.DA.Argument

     

    S.12  If (Argument =3D=3D 0) {

    S.13    If ((SRH.LastEntry &= gt; maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)) {<= /p>

    S.14      Send an = ICMP Parameter Problem to the Source Address

           &= nbsp;   with Code 0 (Erroneous header field encountered)

           &= nbsp;   and Pointer set to the Segments Left field,

           &= nbsp;   interrupt packet processing, and discard the packet.=

    S.15    }<= /p>

     

    S.16    Decrement SRH.Segmen= tsLeft by 1

     

    S.17    Set S to the value o= f SRH.SegmentList[SRH.SegmentsLeft]

    S.18  }

    S.19  Else {

    S.20    If ((SRH.LastEntry &= gt; maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)) {<= /p>

    S.21      Send an = ICMP Parameter Problem to the Source Address

           &= nbsp;  with Code 0 (Erroneous header field encountered)

           &= nbsp;   and Pointer set to the Segments Left field,

           &= nbsp;   interrupt packet processing, and discard the packet.=

    S.22    }<= /p>

     

    S.23    Set S[0..B-1] to the= value of IPv6.DA[0..B-1] (i.e., the common locator block)

     

    S.24    If (SRH.SegmentsLeft= > SRH.LastEntry) {

    S.25      Initiali= ze local parameter ActiveSegment to the value of DA

    S.26    }<= /p>

    S.27    Else {

    S.28      Initiali= ze local parameter ActiveSegment to the value

    S.29       of= SRH.SegmentList[SRH.SegmentsLeft]

    S.30    }<= /p>

     

    S.31    Initialize local par= ameter BitLength to (CountTrailingZeros(ActiveSegment) +

           &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;     AL - CountTrailingZeros(Argument))

    S.32    Initialize local par= ameter BitIndex to (128 =96 BitLength)

     

    S.33    Set S[B..B+BitLength= -1] to the value of

           &= nbsp; ActiveSegment[BitIndex..(BitIndex+BitLength-1)]

    S.34  }

     

    S.35  Set IPv6.DA to the value of S

     

    S.36  Decrement IPv6.HopLimit by 1

     

    S.37  Submit the packet to the egress = IPv6 FIB lookup for transmission

           to the= new destination.

    S.38 }

     

    4.1.1.1 Upper layer header processing

     

    The upper-layer header processing described= in Section 4.1.1 of

    [RFC8986] is replaced as follows.

     

    S.01  Initialize local parameter Argum= ent to the value of IPv6.DA.Argument

    S.02  If (Argument !=3D 0) {

            = # In this case, the SRH was not added by source

           &= nbsp;# The source compressed it into the active segment in IPv6.DA

           &= nbsp;# Build a pseudo header from the active segment in the IPv6.DA for use

          # durin= g processing.

    S.03    Initialize a 24-byte= local SRH in memory to 0=92s for use below

    S.04    Set SRH.MaxHdrLen to= 3

    S.05    Set SRH.RoutingType = to 4

    S.06    Set SRH.SegmentsLeft= to 0

    S.07    Set SRH.SegmentList[= 0] to the value of IPv6.DA

     

    S.08    Process the SRH as p= er section 4.1.1,

    S.09     noting such pr= ocessing is limited to the pseudo SRH

    S.10     since Argument= is not 0.

    S.11  }

     

    S.12  If (Upper-Layer header type is a= llowed by local configuration) {

    S.13    Proceed to process t= he Upper-Layer header

    S.14  } Else {

    S.15    Send an ICMP Paramet= er Problem to the Source Address

           &= nbsp; with Code 4 (SR Upper-layer Header Error)

           &= nbsp; and Pointer set to the offset of the Upper-Layer header,

           &= nbsp; interrupt packet processing, and discard the packet.

    S.16  }

     

     

     

    4.2.1.  End with REPLACE-C-SID=

     

    When processing an IPv6 packet that matches= a FIB entry locally

    instantiated as an End SID with the REPLACE= -C-SID flavor, the SRH

    processing described in Section 4.1 of [RFC= 8986] is replaced as

    follows.

     

    S.01 When an SRH is processed {<= /span>

    S.02  If (IPv6.DA.Argument =3D=3D 0 an= d SRH.SegmentsLeft =3D=3D 0) {

    S.03    Stop processing the = SRH, and proceed to process the next

            = header in the packet, whose type is identified by

            = the Next Header field in the routing header.

    S.04  }

     

    S.05  If (IPv6.HopLimit <=3D 1) {

    S.06    Send an ICMP Time Ex= ceeded message to the Source Address

            = with Code 0 (Hop limit exceeded in transit),

            = interrupt packet processing, and discard the packet.

    S.07  }

     

    S.08  # Determine the maximum SRH Last= Entry

    S.09  Set maxLE to ((SRH.HdrExtLen / 2= ) - 1)

     

    S.10  Initialize 128-bit buffer memory= S to 0.

    S.11  Initialize local parameter Argum= ent to the value of IPv6.DA.Argument

    S.12  Initialize local parameter Activ= eSegment to SRH.SegmentList[SRH.SegmentsLeft]

     

    S.13  If (Argument =3D=3D 0) {

    S.14    If ((SRH.LastEntry &= gt; maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)) {<= /p>

    S.15      Send an = ICMP Parameter Problem to the Source Address

           &= nbsp;  with Code 0 (Erroneous header field encountered)

           &= nbsp;  and Pointer set to the Segments Left field,

           &= nbsp;  interrupt packet processing, and discard the packet.=

    S.16    }<= /p>

     

    S.17    Set S[0..B-1] to the= value of IPv6.DA[0..B-1] (i.e., the common locator block)

     

    S.18    Decrement SRH.Segmen= tsLeft by 1

     

    S.19    Set Argument to (128= / NF - 1)

    S.20  }

    S.21  Else {

    S.22    If ((SRH.LastEntry &= gt; maxLE) or (SRH.SegmentsLeft > SRH.LastEntry)) {

    S.23      Send an = ICMP Parameter Problem to the Source Address

           &= nbsp;  with Code 0 (Erroneous header field encountered)

           &= nbsp;  and Pointer set to the Segments Left field,

           &= nbsp;  interrupt packet processing, and discard the packet.=

    S.24    }<= /p>

     

    S.25    Set S[0..B-1] to the= value of IPv6.DA[0..B-1] (i.e., the common locator block)

     

    S.26    Decrement Argument b= y 1

    S.27  }

     

    S.28  Initialize local parameter BitLe= ngth to the value of NF

    S.29  Initialize local parameter BitIn= dex to (Argument * NF)

     

    S.30  Set S[B..B+BitLength-1] to the v= alue of

           Active= Segment[BitIndex..(BitIndex+BitLength-1)]

    S.32  Set S[B+BitLength..B+BitLength+A= -1] to the value of Argument

     

    S.33  Set IPv6.DA to the value of S

     

    S.34  Decrement IPv6.HopLimit by 1

     

    S.35  Submit the packet to the egress = IPv6 FIB lookup for transmission

    S.36   to the new destination.

    S.37 }

     

    4.2.1.1.  Upper layer header proces= sing

     

    The upper-layer header processing described= in Section 4.1.1 of [RFC8986] is unchanged and reproduced below.

     

    S.01  If (Upper-Layer header type is a= llowed by local configuration) {

    S.02    Proceed to process t= he Upper-Layer header

    S.03  } Else {

    S.04    Send an ICMP Paramet= er Problem to the Source Address

            = with Code 4 (SR Upper-layer Header Error)

            = and Pointer set to the offset of the Upper-Layer header,<= /p>

            = interrupt packet processing, and discard the packet.

    S.05  }

     

     

     

    --_000_BN6PR11MB40815FF94A9509B46469A4F4C8B89BN6PR11MB4081namp_-- From nobody Thu Oct 14 07:42:43 2021 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 01C073A16E7 for ; Thu, 14 Oct 2021 07:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.554 X-Spam-Level: X-Spam-Status: No, score=-1.554 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, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 FPs1CHRmPaio for ; Thu, 14 Oct 2021 07:42:36 -0700 (PDT) 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 EF52B3A0A5E for ; Thu, 14 Oct 2021 07:42:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquid.tech; s=mimecast20210406; t=1634222553; 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=GhYGJqEGD+CIrbe5dQqDNWF6sEAnlTVOyizOT3edlUg=; b=UOcV1Rj8vvB2VimdF/lG/+ITGv0DdgauRb4XILXoYF4yU6ZhVmtcJhGxKNB71JwhXMRT6y DrArRCX3mOD82QXu9DA7oTRuxm4EuDPdOo/45lDjW0jbKMvo+Ly/4XKXFzP8NWqvcvmhCb 3fNAEUZgtpecRLn6lOlWOiqKBbM7aR4= Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05lp2108.outbound.protection.outlook.com [104.47.17.108]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-214-oUOs8pRDNT2e7OcudHkF3g-2; Thu, 14 Oct 2021 15:42:30 +0100 X-MC-Unique: oUOs8pRDNT2e7OcudHkF3g-2 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com (2603:10a6:20b:346::6) by AS8PR03MB8120.eurprd03.prod.outlook.com (2603:10a6:20b:447::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.16; Thu, 14 Oct 2021 14:42:29 +0000 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9]) by AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9%7]) with mapi id 15.20.4608.016; Thu, 14 Oct 2021 14:42:29 +0000 From: Andrew Alston To: SPRING WG Thread-Topic: CSID proposed clarifications Thread-Index: AQHXwPmD76WD43ON70uWpO9ECDy+ZqvSkT1Q Date: Thu, 14 Oct 2021 14:42:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d19b7044-44fa-4b59-1e5a-08d98f20d94e x-ms-traffictypediagnostic: AS8PR03MB8120: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: qIgyV86RTZfO3/p39tXU7qAPZ5fLgVbf1RygdcgitnjNytIoJMs1AKWW3O4s2s1mN0rNxDrY/jp320GM3UBXdMvXedb+HXkRcUtIvMQMBk5pLqgL3+alMw0A/X+cYlihvZ+osYshi+981yuQnHpUKrsoW37kYalxM7o5chHSrZUwKagsoLvXLpAEV1FXizw+CF3qjhXQKAItvo+soOS95hheWH8J5SNvoCsqTal8DSBow53Jr/tB0cO3tH1OF+GezAnpozw1Lt5st+SZEHw+D1b6tCLIyZ+vCYO+LVx0n4FFyA0dM/OsMDOYnG7s2xGwRZMnLhHrkBB5h77F1j2Ia7m0nM2DlCYlm+GjObPC1BSdcMPemXDoJ2A6UqSCrWiAPCBHQ5nd1Aa55RGbPr0l5st9ysWjoB1f2InwqfzLZ8gRyhv2L6dvOkSjVJO8x7PzHFJNQb88QNAjnkBTyJJFawgwRMr8Q4MPf/RJrfExS3x7Yyx9OFPwalq8fRiO0zsc6zoj0amJnSzxxvHzQ9Yr3FXUHax3oT72PDgWm3CbYjIPD4du7knHtM+bjWmh3Z/OmDp+ESstenuq9HqO6tLREam5WP/rL//NtahUFYMmbKvvTPcL4PRTV/YKthVdIfItBduDZDtPIDBTI6QWf8VojLvilBcqz3n7wXt1z6g5E01P+uE7sIaMIaZuWGLAcD0c9a7wam58XjUKTbUixpneZUyL7Bt/rzSgqsZKYW35L55xsC+zismbKKj3R6E6CQ8Gc4y25j2XK23HQJ4PNxa/OIUyf6xT1MGy4U5CLfdEPdYVdIyhAqQ62ApBsSvDEz/whO1NdYzF1XfJK1dTO3qNRg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR03MB7622.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(33656002)(76116006)(508600001)(55016002)(71200400001)(8676002)(86362001)(2906002)(7696005)(9686003)(6916009)(83380400001)(66946007)(7116003)(66556008)(66476007)(66446008)(64756008)(5660300002)(122000001)(38100700002)(53546011)(316002)(186003)(52536014)(166002)(3480700007)(8936002)(6506007)(38070700005); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?FH/MPgfuzdbm8qAjkwKt9NNxSab8lDlUbVuXQmqPXQ7iMsAw9UoXWe69iavz?= =?us-ascii?Q?LhomwwEZ0lf7gH8PeDAyTNePDaM64auAtPvbj2sG4O1qras/tHX98paq9zYg?= =?us-ascii?Q?5SwLCySCnZiJDpjBEHuuThMbrnUfjWw2yttjGMwwlEBYDJeSE9pBUnygCSt7?= =?us-ascii?Q?bQehyy5tbio3llCMdQSUD0mKOLyC7Rtva/fjgsOgsS1LlxUkz1dj7lqOtzt4?= =?us-ascii?Q?FO9kkizDL0KeTTxGehER7mZvBlAM5J+N4D/h1onhnQHtgjm+F/eh5WIIKX3R?= =?us-ascii?Q?t3avMKtB9BpFGa9srOU9cPFMVlzv4o3QloT1HexLEDLlLZ+HTD7FrL1vTnjk?= =?us-ascii?Q?WToaX/JdFzu9D+XUdsYTdBehXlJ0fUpt5bcW8Q1IDTk4eOKjS33TjtT/iSwH?= =?us-ascii?Q?bfbFF8opiUycngUhSGY+YoHwyWWAuXNHac7iWgzn3BRwcAoO+DAVxKVDJl0A?= =?us-ascii?Q?avMDcQ+5PYBc7O/KxhWCcC91CQtH/eS3dS0OCnztdaFIXP1hAv2oS8t0OjRf?= =?us-ascii?Q?br4kRIBmXnrvzXJ/Y1LPY4XWlYkWlqISO+HalRi7TQeyq1XreoFu8PoPIzzY?= =?us-ascii?Q?4huHlYJ8EWYVsigLlwsBm4xrGKuWcz/IXH/PmxK9jY04YAILnkyvfZAMR9yy?= =?us-ascii?Q?M3MsU7zfoJgPmhBG9u8HQ0nvAKMlQ5SHS1m0m8Lkkvy+511qiKiaWSNPNDqB?= =?us-ascii?Q?AFF1mMGVJsEDRA16FrZkAzzK/JIkd12RooXlkpxxQ7Awl5LyX7WD8FhbeEUi?= =?us-ascii?Q?MjOKArqe6APvQKD6vzFfuIPquk/QdpM9Mb6yGm/amqqkq3OYjiFUgcSA9tGM?= =?us-ascii?Q?EDc/RDIZaGcA/b6rZR0SxklXgHhfZclGmTq32hywgULN8D3MhLq7iXI+E/mP?= =?us-ascii?Q?5v6LxyG9zAxaJIBj2fS6H+mAw+XEE/bsDVJL9a4EWwS+C447BL3YjTisuAyc?= =?us-ascii?Q?nkBeHs0OwQf0+DPsxwl7Ji2b0cQPetPltoCNcea2K4mv4nVQVTc1tG/9SlR0?= =?us-ascii?Q?Ga+xEzGWfHWfFPWYduEB9hsApf2WtYsumaYIk8AMgObDZbHAqcCuWDH4T28u?= =?us-ascii?Q?sT8kDM3c8rwGSTp2mmacwy4nEW/+6RmYGciMfP9UHv9Ep4M6fE8rcUH09Dm7?= =?us-ascii?Q?+3bAkfVSO7ndyIYDTCOwVxDchZGIvr/rhVHU+2GhUusrXC+LTqXAbLjnSm9v?= =?us-ascii?Q?RmNtLsA3lfo6pxlUgwDcH6w/9EEeHzYKX4Xgc1yqFk9aic/R3k9NR7+qP5ak?= =?us-ascii?Q?qYfoXKTfR4uP2HzbiJSNFgcTjVFfaUWQDj73bZX1eno6FeDII3cNCUqyfm/8?= =?us-ascii?Q?Pt1dycRRPQLjvqN67pGG8DdjBNmVIZC09HOw+JqUAzXY+dBcv+8fXjXWZMnI?= =?us-ascii?Q?FRIlr5g=3D?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquid.tech X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB7622.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d19b7044-44fa-4b59-1e5a-08d98f20d94e X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2021 14:42:29.5892 (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: BxhaAw9nyvOLZ6J7QKP5UBk2LkO7Pj57oq/DxBFaJDsnbCyCmER2z7MlrdDDsZg4BGRWpCTOddwGxlqMULSQLhs2qHxnrIIpDBGnBsr2RcU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB8120 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquid.tech X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquid.tech Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_AS8PR03MB7622DD5180B608DBD377E93DEEB89AS8PR03MB7622eurp_" Archived-At: Subject: Re: [spring] CSID proposed clarifications 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, 14 Oct 2021 14:42:42 -0000 --_000_AS8PR03MB7622DD5180B608DBD377E93DEEB89AS8PR03MB7622eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable (Apologies if this appears twice - seems something went screwy with my outb= ound address so the other version of this is moderated) Darren, I'm a little confused here reading this - but all said and done - on the ne= xt behavior - how is this different from doing something along the lines of Da[loc_bits/8] << sid_size Because - when I trace this all out into actual C code - that's pretty much= what it seems to summarize down to - more specifically - it could be done = something like this: (taking out all the comparisons and error checking) __m128i vec; __u8 output[16]; vec =3D __mm_loadl_epi64((void *)da[loc_size/8]) if(sid_size =3D=3D 16) { vec =3D _mm_bsrli_si128(vec, 2) } else { vec =3D _mm_bsrli_si128(vec, 4) } _mm_store_u_si128((__m128i*)output, vec); memcpy(da[loc_size/8], output, 16-(loc_size/8)); (think I got that pretty much right) Andrew From: spring On Behalf Of Darren Dukes (ddukes) Sent: Thursday, October 14, 2021 3:54 PM To: SPRING WG Subject: [spring] CSID proposed clarifications The NEXT-C-SID and REPLACE-C-SID flavors are functionally very similar. In both cases the SID in the IPv6 Destination Address (DA) contains an argu= ment, that argument is used to construct the next SID from the active segment in the SRH Segment List. I believe the following pseudocode is a much better description of their segment endpoint processing. You'll notice there is no manipulation of the bits in the IPv6 DA. I propose we replace the pseudocode in the draft with the following, stand-alone pseudocode, for the NEXT-C-SID and REPLACE-C-SID flavors of the END behavior (sections 4.1.1 and 4.2.1 respectively). Equivalent changes can be completed for the NEXT-C-SID and REPLACE-C-SID flavors of the END.X behavior (sections 4.1.2 and 4.2.2 respectively) and NEXT-AND-REPLACE-C-SID flavor. Comments are appreciated. Thanks Darren 4.1.1. End with NEXT-C-SID When processing an IPv6 packet that matches a FIB entry locally instantiated as an End SID with the NEXT-C-SID flavor, the SRH processing described in Section 4.1 of [RFC8986] is replaced as follows. S.01 When an SRH is processed { S.02 If (IPv6.DA.Argument =3D=3D 0 and SRH.SegmentsLeft =3D=3D 0) { S.03 Stop processing the SRH, and proceed to process the next header in the packet, whose type is identified by the Next Header field in the routing header. S.04 } S.05 If (IPv6.HopLimit <=3D 1) { S.06 Send an ICMP Time Exceeded message to the Source Address with Code 0 (Hop limit exceeded in transit), interrupt packet processing, and discard the packet. S.07 } S.08 # Determine the maximum SRH Last Entry S.09 Set maxLE to ((SRH.HdrExtLen / 2) - 1) S.10 Initialize 128-bit buffer memory S to 0. S.11 Initialize local parameter Argument to the value of IPv6.DA.Argument S.12 If (Argument =3D=3D 0) { S.13 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)= ) { S.14 Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S.15 } S.16 Decrement SRH.SegmentsLeft by 1 S.17 Set S to the value of SRH.SegmentList[SRH.SegmentsLeft] S.18 } S.19 Else { S.20 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)= ) { S.21 Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S.22 } S.23 Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common loc= ator block) S.24 If (SRH.SegmentsLeft > SRH.LastEntry) { S.25 Initialize local parameter ActiveSegment to the value of DA S.26 } S.27 Else { S.28 Initialize local parameter ActiveSegment to the value S.29 of SRH.SegmentList[SRH.SegmentsLeft] S.30 } S.31 Initialize local parameter BitLength to (CountTrailingZeros(ActiveS= egment) + AL - CountTrailingZeros(A= rgument)) S.32 Initialize local parameter BitIndex to (128 - BitLength) S.33 Set S[B..B+BitLength-1] to the value of ActiveSegment[BitIndex..(BitIndex+BitLength-1)] S.34 } S.35 Set IPv6.DA to the value of S S.36 Decrement IPv6.HopLimit by 1 S.37 Submit the packet to the egress IPv6 FIB lookup for transmission to the new destination. S.38 } 4.1.1.1 Upper layer header processing The upper-layer header processing described in Section 4.1.1 of [RFC8986] is replaced as follows. S.01 Initialize local parameter Argument to the value of IPv6.DA.Argument S.02 If (Argument !=3D 0) { # In this case, the SRH was not added by source # The source compressed it into the active segment in IPv6.DA # Build a pseudo header from the active segment in the IPv6.DA for = use # during processing. S.03 Initialize a 24-byte local SRH in memory to 0's for use below S.04 Set SRH.MaxHdrLen to 3 S.05 Set SRH.RoutingType to 4 S.06 Set SRH.SegmentsLeft to 0 S.07 Set SRH.SegmentList[0] to the value of IPv6.DA S.08 Process the SRH as per section 4.1.1, S.09 noting such processing is limited to the pseudo SRH S.10 since Argument is not 0. S.11 } S.12 If (Upper-Layer header type is allowed by local configuration) { S.13 Proceed to process the Upper-Layer header S.14 } Else { S.15 Send an ICMP Parameter Problem to the Source Address with Code 4 (SR Upper-layer Header Error) and Pointer set to the offset of the Upper-Layer header, interrupt packet processing, and discard the packet. S.16 } 4.2.1. End with REPLACE-C-SID When processing an IPv6 packet that matches a FIB entry locally instantiated as an End SID with the REPLACE-C-SID flavor, the SRH processing described in Section 4.1 of [RFC8986] is replaced as follows. S.01 When an SRH is processed { S.02 If (IPv6.DA.Argument =3D=3D 0 and SRH.SegmentsLeft =3D=3D 0) { S.03 Stop processing the SRH, and proceed to process the next header in the packet, whose type is identified by the Next Header field in the routing header. S.04 } S.05 If (IPv6.HopLimit <=3D 1) { S.06 Send an ICMP Time Exceeded message to the Source Address with Code 0 (Hop limit exceeded in transit), interrupt packet processing, and discard the packet. S.07 } S.08 # Determine the maximum SRH Last Entry S.09 Set maxLE to ((SRH.HdrExtLen / 2) - 1) S.10 Initialize 128-bit buffer memory S to 0. S.11 Initialize local parameter Argument to the value of IPv6.DA.Argument S.12 Initialize local parameter ActiveSegment to SRH.SegmentList[SRH.Segme= ntsLeft] S.13 If (Argument =3D=3D 0) { S.14 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)= ) { S.15 Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S.16 } S.17 Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common loc= ator block) S.18 Decrement SRH.SegmentsLeft by 1 S.19 Set Argument to (128 / NF - 1) S.20 } S.21 Else { S.22 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry)) = { S.23 Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S.24 } S.25 Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common loc= ator block) S.26 Decrement Argument by 1 S.27 } S.28 Initialize local parameter BitLength to the value of NF S.29 Initialize local parameter BitIndex to (Argument * NF) S.30 Set S[B..B+BitLength-1] to the value of ActiveSegment[BitIndex..(BitIndex+BitLength-1)] S.32 Set S[B+BitLength..B+BitLength+A-1] to the value of Argument S.33 Set IPv6.DA to the value of S S.34 Decrement IPv6.HopLimit by 1 S.35 Submit the packet to the egress IPv6 FIB lookup for transmission S.36 to the new destination. S.37 } 4.2.1.1. Upper layer header processing The upper-layer header processing described in Section 4.1.1 of [RFC8986] i= s unchanged and reproduced below. S.01 If (Upper-Layer header type is allowed by local configuration) { S.02 Proceed to process the Upper-Layer header S.03 } Else { S.04 Send an ICMP Parameter Problem to the Source Address with Code 4 (SR Upper-layer Header Error) and Pointer set to the offset of the Upper-Layer header, interrupt packet processing, and discard the packet. S.05 } --_000_AS8PR03MB7622DD5180B608DBD377E93DEEB89AS8PR03MB7622eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

    (Apologies if this = appears twice – seems something went screwy with my outbound address = so the other version of this is moderated)

     

    Darren,<= /span>

     

    I’m a little = confused here reading this – but all said and done – on the nex= t behavior – how is this different from doing something along the lin= es of

     

    Da[loc_bits/8] <= < sid_size

     

    Because – whe= n I trace this all out into actual C code – that’s pretty much = what it seems to summarize down to – more specifically – it cou= ld be done something like this:

     

    (taking out all the= comparisons and error checking)

     

    __m128i vec;

    __u8 output[16];=

     

    vec =3D __mm_loa= dl_epi64((void *)da[loc_size/8])

    if(sid_size =3D= =3D 16) {

      &nbs= p;           vec =3D _mm_= bsrli_si128(vec, 2)

    } else {

      &nbs= p;           vec =3D _mm_= bsrli_si128(vec, 4)

    }

    _mm_store_u_si12= 8((__m128i*)output, vec);

    memcpy(da[loc_si= ze/8], output, 16-(loc_size/8));

     

    (think I got that p= retty much right)

     

    Andrew

     

    From:= spring <spring-bounces@ietf.org> On Behalf Of Darren Dukes (ddukes)
    Sent: Thursday, October 14, 2021 3:54 PM
    To: SPRING WG <spring@ietf.org>
    Subject: [spring] CSID proposed clarifications

     

    The NEXT-C-SID and REPLACE-C-SID flavors are functionally = very similar.

    In both cases the SID in the IPv6 Destination Address (DA)= contains an argument,

    that argument is used to construct the next SID from the a= ctive segment in

    the SRH Segment List.

     

    I believe the following pseudocode is a much better descri= ption of their

    segment endpoint processing. You’ll notice there is = no manipulation of

    the bits in the IPv6 DA.

     

    I propose we replace the pseudocode in the draft with the = following,

    stand-alone pseudocode, for the NEXT-C-SID and REPLACE-C-S= ID flavors

    of the END behavior (sections 4.1.1 and 4.2.1 respectively= ).

     

    Equivalent changes can be completed for the NEXT-C-SID and= REPLACE-C-SID

    flavors of the END.X behavior (sections 4.1.2 and 4.2.2 re= spectively) and

    NEXT-AND-REPLACE-C-SID flavor.

     

    Comments are appreciated.

     

    Thanks

      Darren

     

    4.1.1.  End with NEXT-C-SID<= /p>

     

    When processing an IPv6 packet that matches a FIB entry lo= cally

    instantiated as an End SID with the NEXT-C-SID flavor, the= SRH

    processing described in Section 4.1 of [RFC8986] is replac= ed as

    follows.

     

     

    S.01 When an SRH is processed {

    S.02  If (IPv6.DA.Argument =3D=3D 0 and SRH.SegmentsL= eft =3D=3D 0) {

    S.03     Stop processing the SRH, and = proceed to process the next

             header in= the packet, whose type is identified by

             the Next = Header field in the routing header.

    S.04  }

     

    S.05  If (IPv6.HopLimit <=3D 1) {

    S.06     Send an ICMP Time Exceeded me= ssage to the Source Address

             with Code= 0 (Hop limit exceeded in transit),

             interrupt= packet processing, and discard the packet.

    S.07  }

     

    S.08  # Determine the maximum SRH Last Entry

    S.09  Set maxLE to ((SRH.HdrExtLen / 2) - 1)

     

    S.10  Initialize 128-bit buffer memory S to 0.

    S.11  Initialize local parameter Argument to the valu= e of IPv6.DA.Argument

     

    S.12  If (Argument =3D=3D 0) {

    S.13    If ((SRH.LastEntry > maxLE) or (= SRH.SegmentsLeft > SRH.LastEntry+1)) {

    S.14      Send an ICMP Parameter = Problem to the Source Address

             &nbs= p; with Code 0 (Erroneous header field encountered)

             &nbs= p; and Pointer set to the Segments Left field,

             &nbs= p; interrupt packet processing, and discard the packet.

    S.15    }

     

    S.16    Decrement SRH.SegmentsLeft by 1

     

    S.17    Set S to the value of SRH.SegmentLi= st[SRH.SegmentsLeft]

    S.18  }

    S.19  Else {

    S.20    If ((SRH.LastEntry > maxLE) or (= SRH.SegmentsLeft > SRH.LastEntry+1)) {

    S.21      Send an ICMP Parameter = Problem to the Source Address

             &nbs= p;with Code 0 (Erroneous header field encountered)

             &nbs= p; and Pointer set to the Segments Left field,

             &nbs= p; interrupt packet processing, and discard the packet.

    S.22    }

     

    S.23    Set S[0..B-1] to the value of IPv6.= DA[0..B-1] (i.e., the common locator block)

     

    S.24    If (SRH.SegmentsLeft > SRH.LastE= ntry) {

    S.25      Initialize local parame= ter ActiveSegment to the value of DA

    S.26    }

    S.27    Else {

    S.28      Initialize local parame= ter ActiveSegment to the value

    S.29       of SRH.SegmentLis= t[SRH.SegmentsLeft]

    S.30    }

     

    S.31    Initialize local parameter BitLengt= h to (CountTrailingZeros(ActiveSegment) +

             &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  AL - CountTrailingZeros(Argument))

    S.32    Initialize local parameter BitIndex= to (128 – BitLength)

     

    S.33    Set S[B..B+BitLength-1] to the valu= e of

             Acti= veSegment[BitIndex..(BitIndex+BitLength-1)]

    S.34  }

     

    S.35  Set IPv6.DA to the value of S=

     

    S.36  Decrement IPv6.HopLimit by 1<= /p>

     

    S.37  Submit the packet to the egress IPv6 FIB lookup= for transmission

           to the new destinatio= n.

    S.38 }

     

    4.1.1.1 Upper la= yer header processing

     

    The upper-layer header processing described in Section 4.1= .1 of

    [RFC8986] is replaced as follows.

     

    S.01  Initialize local parameter Argument to the valu= e of IPv6.DA.Argument

    S.02  If (Argument !=3D 0) {

            # In this case,= the SRH was not added by source

            # The sour= ce compressed it into the active segment in IPv6.DA

            # Build a = pseudo header from the active segment in the IPv6.DA for use

          # during processing.

    S.03    Initialize a 24-byte local SRH in m= emory to 0’s for use below

    S.04    Set SRH.MaxHdrLen to 3

    S.05    Set SRH.RoutingType to 4=

    S.06    Set SRH.SegmentsLeft to 0

    S.07    Set SRH.SegmentList[0] to the value= of IPv6.DA

     

    S.08    Process the SRH as per section 4.1.= 1,

    S.09     noting such processing is lim= ited to the pseudo SRH

    S.10     since Argument is not 0.=

    S.11  }

     

    S.12  If (Upper-Layer header type is allowed by local= configuration) {

    S.13    Proceed to process the Upper-Layer = header

    S.14  } Else {

    S.15    Send an ICMP Parameter Problem to t= he Source Address

             with Code= 4 (SR Upper-layer Header Error)

             and Point= er set to the offset of the Upper-Layer header,

             interrupt= packet processing, and discard the packet.

    S.16  }

     

     

     

    4.2.1.  End with REPLACE-C-SID

     

    When processing an IPv6 packet that matches a FIB entry lo= cally

    instantiated as an End SID with the REPLACE-C-SID flavor, = the SRH

    processing described in Section 4.1 of [RFC8986] is replac= ed as

    follows.

     

    S.01 When an SRH is processed {

    S.02  If (IPv6.DA.Argument =3D=3D 0 and SRH.SegmentsL= eft =3D=3D 0) {

    S.03    Stop processing the SRH, and procee= d to process the next

            header in the p= acket, whose type is identified by

            the Next Header= field in the routing header.

    S.04  }

     

    S.05  If (IPv6.HopLimit <=3D 1) {

    S.06    Send an ICMP Time Exceeded message = to the Source Address

            with Code 0 (Ho= p limit exceeded in transit),

            interrupt packe= t processing, and discard the packet.

    S.07  }

     

    S.08  # Determine the maximum SRH Last Entry

    S.09  Set maxLE to ((SRH.HdrExtLen / 2) - 1)

     

    S.10  Initialize 128-bit buffer memory S to 0.

    S.11  Initialize local parameter Argument to the valu= e of IPv6.DA.Argument

    S.12  Initialize local parameter ActiveSegment to SRH= .SegmentList[SRH.SegmentsLeft]

     

    S.13  If (Argument =3D=3D 0) {

    S.14    If ((SRH.LastEntry > maxLE) or (= SRH.SegmentsLeft > SRH.LastEntry+1)) {

    S.15      Send an ICMP Parameter = Problem to the Source Address

              wit= h Code 0 (Erroneous header field encountered)

              and= Pointer set to the Segments Left field,

              int= errupt packet processing, and discard the packet.

    S.16    }

     

    S.17    Set S[0..B-1] to the value of IPv6.= DA[0..B-1] (i.e., the common locator block)

     

    S.18    Decrement SRH.SegmentsLeft by 1

     

    S.19    Set Argument to (128 / NF - 1)=

    S.20  }

    S.21  Else {

    S.22    If ((SRH.LastEntry > maxLE) or (= SRH.SegmentsLeft > SRH.LastEntry)) {

    S.23      Send an ICMP Parameter = Problem to the Source Address

              wit= h Code 0 (Erroneous header field encountered)

              and= Pointer set to the Segments Left field,

              int= errupt packet processing, and discard the packet.

    S.24    }

     

    S.25    Set S[0..B-1] to the value of IPv6.= DA[0..B-1] (i.e., the common locator block)

     

    S.26    Decrement Argument by 1<= /span>

    S.27  }

     

    S.28  Initialize local parameter BitLength to the val= ue of NF

    S.29  Initialize local parameter BitIndex to (Argumen= t * NF)

     

    S.30  Set S[B..B+BitLength-1] to the value of

           ActiveSegment[BitInde= x..(BitIndex+BitLength-1)]

    S.32  Set S[B+BitLength..B+BitLength+A-1] to the valu= e of Argument

     

    S.33  Set IPv6.DA to the value of S=

     

    S.34  Decrement IPv6.HopLimit by 1<= /p>

     

    S.35  Submit the packet to the egress IPv6 FIB lookup= for transmission

    S.36   to the new destination.=

    S.37 }

     

    4.2.1.1.  U= pper layer header processing

     

    The upper-layer header processing described in Section 4.1= .1 of [RFC8986] is unchanged and reproduced below.

     

    S.01  If (Upper-Layer header type is allowed by local= configuration) {

    S.02    Proceed to process the Upper-Layer = header

    S.03  } Else {

    S.04    Send an ICMP Parameter Problem to t= he Source Address

            with Code 4 (SR= Upper-layer Header Error)

            and Pointer set= to the offset of the Upper-Layer header,

            interrupt packe= t processing, and discard the packet.

    S.05  }

     

     

     

    --_000_AS8PR03MB7622DD5180B608DBD377E93DEEB89AS8PR03MB7622eurp_-- From nobody Thu Oct 14 07:54:43 2021 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 BC1613A1693 for ; Thu, 14 Oct 2021 07:54:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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=gXUA13BN; dkim=pass (1024-bit key) header.d=juniper.net header.b=dX/szw+D 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 HC1FyvWpv3BQ for ; Thu, 14 Oct 2021 07:54:33 -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 56D343A0A0A for ; Thu, 14 Oct 2021 07:54:33 -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 SMTP id 19E8U4VN001875; Thu, 14 Oct 2021 07:54:32 -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=Dr4lLt6Jlj77G7zOUiuVLInKBhClOVtZPQOFyXl9d5Q=; b=gXUA13BNPD1URxdpaBiUURWmnskUUbmqUfjNATmYmUTN8QBoqOSrXvyLTbaiqybSd6iG DdTWmH+51FroGEb/r/LJD48aS1Sovxyk8aeYZ7mOjBvPzb447QJtWyTTtyRCAqtglyS2 r72NOPf4xgOOudveUlbNqBjuY1JFKENyAPqWs+4fQwEbPFSslMzpiNR9u3epUNzwwGVT dc9RYMtX+pECvkV4fnrMSV3dJ/h/9nddot+wReBrcCYFzJO8+KVtFKjuoktW8Z5XIERY Px65mwP3owjBqVzCzAif0pkEPLWdYBSJlq7iWa3K2xZqIkHNtGQ/ImMDQuLMDBdimpvD cA== Received: from nam04-mw2-obe.outbound.protection.outlook.com (mail-mw2nam08lp2172.outbound.protection.outlook.com [104.47.73.172]) by mx0b-00273201.pphosted.com with ESMTP id 3bph2wrvkp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Oct 2021 07:54:31 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mBzP+KlwMHgTiD4ICaQ+ypcK5CugwgkpnjxmqWcNbr+KcJ1WCzlFWn45zP44Hbt7TxVZ1c9ss6Ke6gSSfvkb17GmRI9GTqbHqk9U9dsR26I8il4xbysy41qAItbmysXaJ0WyYxz42iXHIPAbUGqMpf7B02h2mp0G4EvhqqZGyGV4A6+++valhRwAxnauf4v+CJ+3h54kAjVe/UVg1EJZzjCooWNWI6cLlSXbBPMg5plQwaHMNtYHTn/xAjX+roJtYBa+SMB5kOI42z9sP0b/dKdk2+V0mnajXLrdQKHJ3H40YgyaP6EaECpw441cy5zQWGwiHQUjHkBsMwuwGa7Myw== 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=Dr4lLt6Jlj77G7zOUiuVLInKBhClOVtZPQOFyXl9d5Q=; b=Z4xOlsyTxa7libcrTkBRysFP9AMMw2vYJ1kUwPP2/3fACX+VAb26gazjFNbcSuUEIUFFLyQEbUU/e8ZqiQCT8xF9rUrXIK5kG1FPMrTLmxKr6BR3nGu4pmtGh+sp0ArCnZmr02/rMj/rWglT9vyS2qO97opa7TzmT8y5N6LefYD+bYeCI9OM008PVvEXFhcl/nG44HpKDgIEU9ble0VJvJaybcjQCuOCWYkDwz8KnNiLqwoPF7LgTAmA5wkBWUOjcs9n0bjxykrZfM9BOvbwoQ1uXnjFtCx7NjW8X9XtRQDumt//fZo59wkrHKuX7OvnU6oCHoKXLGDcdfRARkEc9Q== 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=Dr4lLt6Jlj77G7zOUiuVLInKBhClOVtZPQOFyXl9d5Q=; b=dX/szw+DB4dH6rBl7h+hV7uf77eBtX7Gagvzxl7x1iib82JaSXzs+9EdLkwz6pv2Pl/i7mGbirLQH3IMY1lFw42zSmCpXWu8Y6RYWYVZCcHcpQ/7sTTtZydd1JSPV0r+V2n14Nq09iB01FlEuB1kIrv7Sffmmo5LWyqqU5/X064= Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by MN2PR05MB6046.namprd05.prod.outlook.com (2603:10b6:208:cd::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.8; Thu, 14 Oct 2021 14:54:29 +0000 Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::10b9:2bb9:11f2:6b4a]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::10b9:2bb9:11f2:6b4a%3]) with mapi id 15.20.4608.016; Thu, 14 Oct 2021 14:54:29 +0000 From: John Scudder To: Stefano Salsano CC: "spring@ietf.org" Thread-Topic: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 Thread-Index: AQHXwIGtAQ5iI0HLYkm+pjy3rdbrTKvRinmAgAAHlYCAAAf4AIAA+7wA Date: Thu, 14 Oct 2021 14:54:29 +0000 Message-ID: <5732621F-6634-4F98-A970-2655DE044951@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.120.0.1.13) authentication-results: uniroma2.it; dkim=none (message not signed) header.d=none;uniroma2.it; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d9f47a64-fdd7-4d14-2716-08d98f228628 x-ms-traffictypediagnostic: MN2PR05MB6046: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wZG7jgQijL7quvoHopLLvpHnPbfAaCUMf2G7iuMtiKSIiN1c4IpIN5rjQZtHS3sLe5mgU0wUfekRhLE9qKPCZavStJjasZRO9W0LxbFsy3ShC/MgkxOfrErZJqZ4NmQnUjqXUEMuNqu6JIU30yHPXISX+E1YQxMJbqwi1j0ZZUOa9XPQ2JsOnzrHJpahgLepQToGalgU0maYNOQCVYQs3PqSjhiPeGnTIMZLpzanK2vlSmPSg9X2oeeU5SnGWq7m+zszCfILAfsvlld8pf/LZAhYl3mOw9tSX0WUEM89Oc9d7Ji8CrnRg7nxfApMMyjADPrMCnHkftA+I1UqVx6eFH01T3apxN08Fp5fkvnUcmukjyaGGkGjc2VN/5gDGN081500jxJGbUm1/JLZyCmSWTDvw1FUB2cgab6n8rufoy9IqeWYmzm/Jsjq41yyz4EFA3ez1RQTtdmkfTlTHF+T+uoBrIx4R/NZcgBYzAJn0w9Uag4+3YFWPUWIXxrlqdDuY2mnnTJlkEIZgTTGSxWxFHmI0/YCVSoP3MIf+edtUX9sjdZ0U9CmSIHSQm5R7cveky31F5jfgzAUPdI5FuxNcX+T0NDfLK+I8MzEKb6Jn0ef75FBC7BHqHMhzcSNPYnzmYW0RKtdCePG2861U7+1n7YEAHI+yE6yi2GHoyGS9RUSir6EmftnKq66BUo7qr0lqvC7Sad0Q+DEKz7cVnmOoWlfM3gZprBUbA9CLUeehLdtiJ+OngwF8OHOgKmDa/gQ 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:(4636009)(366004)(8676002)(38070700005)(33656002)(36756003)(4326008)(6916009)(8936002)(66946007)(76116006)(66446008)(2616005)(66476007)(64756008)(86362001)(122000001)(6486002)(53546011)(6506007)(2906002)(26005)(316002)(71200400001)(508600001)(5660300002)(186003)(91956017)(66556008)(38100700002)(6512007)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?MWJjMDJ1cWZFOFJpWWlYZndobGlDSWQ2ek4vdExzZ2drSFVsMTlOcVgvckZn?= =?utf-8?B?TnRBVGJMRE80bHdPSkxzaEdqY3Z3akVTSkFNNk10Y3BiRUU3NDJRZ2hIOHY3?= =?utf-8?B?VENucjhBYksydENDeFdzTGVXVzRpSThQV3gvbm9WSmkxMFBySU1jZStJQTc5?= =?utf-8?B?WHFYdEgwVXlKR0ErK0M3N0FpYldBbFZVRTY5Z3FRRGFXWld0bzJDSVE1d0hV?= =?utf-8?B?MWxsaGZwdllPMFU2aUd1Z012eUJXREMySnJLOXZZSnlaU2o2QjlHVzA2d3Ba?= =?utf-8?B?UldTM0hzK00xWktjaUpMbkhJTXVCRElJM1lCd0FFRVJZazQ1U3lmUjZGUXph?= =?utf-8?B?YUxLUjVsbFNJZ1VCcHFqMXBnbmxjaTJsM3hIcU9NQk1OYkpkZ3hlc3lYSGpW?= =?utf-8?B?cHpqQ3hwV2pleUhwcnVWeFVsOXZyMHRHOGljK3pEUDNIby9HTjVoaGdla1Y0?= =?utf-8?B?OWttTHFlOTlCakRuNVd2YkJMVDJTWHljbzIwRnhHdDUxaEpLL3hGaXl5VjZP?= =?utf-8?B?WGhJT3plazBONzg4b28xUk8xTFkwSjc3ZFhlUmtMYjY2VjAzOTh6ZFFkZThR?= =?utf-8?B?bUN0bjIxeXhKWkxZb2YwZXlnRHNNNE83MVZQZEsrNGwxVUNsSmhSRlVKUEdJ?= =?utf-8?B?SDM3ZXdGdXlrVzgvYWloNTA2QjVjQXdES0xVeHNQaVlvWEhOOUl4VEo1bHV0?= =?utf-8?B?Y21aQ3pRTEZGTEVEQjJnL2dha3lZQXFicTFtYXNFbW9jVXlEUitiQUJiVDFN?= =?utf-8?B?RXJrdnE1aEhEOUFmQlllYjIvR0IyNDR5V3N5bGNlL2IydjJtcmx0Y3RZNVdO?= =?utf-8?B?T3BqN0gyMFpPRTRCQjdDYys3czNEWkJ2NjREMjlQc1lidlh2bHdlai9jVDZv?= =?utf-8?B?cXhRTE9zRDRUQU1uVjZCc2JFWTFXZS9XLy9lQWU0STRETGxPaVpYSUtXWlZp?= =?utf-8?B?N0JvbDM0dXZjUDI4UWc5SzdiYklId1JHbW5wbWVrS1Ftck1oWHVvc2UxV2pm?= =?utf-8?B?bExDamY3bU5qVFBoZzBwM1hDamYxREhlL2pyUW5FYjdDckRSV2E4Qm5sTmp0?= =?utf-8?B?KzRaeldHcnBPVFllWUVDbkpsNjk2NEltamtjTUpoRm5ncjFJemN0QkhnT01W?= =?utf-8?B?dTFSYzZ6VlRiaDFuSGhHWTRmTVpMY2dKc2NwamNkUUtkdmgreC9DbjY5eUUr?= =?utf-8?B?TmJpeHcrNElGZXhCcnR0dWN6YlRsUDlHdVJtOUd1VHhncDl0Zzl6aGpWV0U4?= =?utf-8?B?STVLYkFsbGlscEFqQ3F2WGxlVWlDeVpwazAvcHpjWnZuUTFRWGRDRWxyWE9H?= =?utf-8?B?ZGE4SkxlN0tiSXFjWUoyd3ZrbTB5aExEVWg3azNLT2VOclBCalFhUFdQL0Vt?= =?utf-8?B?ZncxQU0zYU9jdWhwK3ZVcU9Nc2FYQmhBVHJrTk5tenowTUlIRWlBTkNRNkJn?= =?utf-8?B?WCtCOURwd2lKY2ZyMDdtdkZWbER2U2U3Ti9xYXM0ME16ZU5aVDE3V3ZrQ3NZ?= =?utf-8?B?NDcxaldaY2c5ckdWTldobytIUWUvcXBtQ3Q3aEI1WVNEM2k1aS9TRTJoc3ZO?= =?utf-8?B?dW9XZjNNdTlWcGs0WkZDdElxeHg0QnNKY1piZEsvQTljeGlvc3pva2F4am1o?= =?utf-8?B?TWplbHBZRkkyM0FIMVlRVkp4UFFWakpBcG5UNW5VNnl6QkZVc2RNaCtqaUp0?= =?utf-8?B?dEhmaFV5TW1PbE9HeHdVR2VraWtib01tblR6K2Q2eGpjUitxRUZzVEJJK0lv?= =?utf-8?B?N2ZsWE9uY1gxWG56dm02NUgxcTBtNDRDOFVEaStybXhRb1lCWVN4M1RtNkph?= =?utf-8?B?SG1nVmY3VDJLWndvVFJKdz09?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_5732621F66344F98A9702655DE044951junipernet_" 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: d9f47a64-fdd7-4d14-2716-08d98f228628 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2021 14:54:29.1324 (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: ygXAFPX75hhQjvOcHWMlm5R9MZkzqpl+QTQg0E9374GacskwrphGKRQW1pOXp3H1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6046 X-Proofpoint-GUID: X92BSF6h7foTKlz-eXZmN1LA5otArBeG X-Proofpoint-ORIG-GUID: X92BSF6h7foTKlz-eXZmN1LA5otArBeG X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-14_08,2021-10-14_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 lowpriorityscore=0 malwarescore=0 suspectscore=0 mlxscore=0 clxscore=1011 bulkscore=0 adultscore=0 phishscore=0 impostorscore=0 spamscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110140091 Archived-At: Subject: Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 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, 14 Oct 2021 14:54:39 -0000 --_000_5732621F66344F98A9702655DE044951junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3RlZmFubywNCg0KV2UgYWdyZWUgb24gdGhlIG92ZXJhcmNoaW5nIHBvaW50LCB3aGljaCBp cyB0aGF0IHRoZSBzdGF0ZW1lbnQgaXNu4oCZdCBjbGVhciBhcyB3cml0dGVuLg0KDQpJIHRha2Ug eW91ciBwb2ludCBhYm91dCByZWFkaW5nIGl0IGluIHRoZSBjb250ZXh0IG9mIFNSdjYgTmV0d29y ayBQcm9ncmFtbWluZywgYW5kIEkgd291bGQgYWJzb2x1dGVseSBhZ3JlZSB0aGF0IGl04oCZcyBy aWdodCB0byB0YWxrIGFib3V0IOKAnHRoZSBOZXR3b3JrIFByb2dyYW1taW5nIHBhcmFkaWdt4oCd LCBidXQgcmlnaHQgbm93IEkgZG9u4oCZdCBzZWUgdGhpcyBwYXJhZGlnbSBhcyBkZWZpbmluZyDi gJxhIGRhdGEgcGxhbmXigJ0gaW4gYSB1c2VmdWwgc2Vuc2UuIEkgd29u4oCZdCBnbyBpbnRvIGdy ZWF0ZXIgZGV0YWlsIG9uIHRoaXMgcmlnaHQgbm93IHNpbmNlIGl0IG1heSByZXByZXNlbnQgYSBz ZXJpb3VzIHRhbmdlbnQgYW5kIG1pZ2h0IG5vdCBlbmQgdXAgYmVpbmcgcmVsZXZhbnQgZGVwZW5k aW5nIG9uIGhvdyB0aGUgYXV0aG9ycyAoYW5kIFdHIGlmIHRoZSBkb2N1bWVudCBpcyBhZG9wdGVk KSBkZWNpZGUgdG8gYWRkcmVzcyB0aGUgY29uY2Vybi4NCg0KVGhhbmtzIGZvciB5b3VyIGhlbHBm dWwgcmVwbHksDQoNCuKAlEpvaG4NCg0KT24gT2N0IDEzLCAyMDIxLCBhdCA3OjUzIFBNLCBTdGVm YW5vIFNhbHNhbm8gPHN0ZWZhbm8uc2Fsc2Fub0B1bmlyb21hMi5pdDxtYWlsdG86c3RlZmFuby5z YWxzYW5vQHVuaXJvbWEyLml0Pj4gd3JvdGU6DQoNCkhpIEpvaG4sDQoNCkkgYWdyZWUgdGhhdCB0 aGUgc3RhdGVtZW50ICJ0aGlzIHNvbHV0aW9uIGRvZXMgbm90IHJlcXVpcmUgYW55IFNSSCBkYXRh DQpwbGFuZSBjaGFuZ2UiIG5lZWRzIHRvIGJlIGNsYXJpZmllZCwgYWxzbyBiZWNhdXNlIHRoZXJl IGlzIG5vIGZvcm1hbA0KZGVmaW5pdGlvbiBvZiBhICJkYXRhIHBsYW5lIiwgaGVuY2UgaXQgaXMg ZXZlbiBtb3JlIHZhZ3VlIHRoZSAiU1JIIGRhdGENCnBsYW5lIi4NCg0KTXkgdW5kZXJzdGFuZGlu ZyBvZiAiU1JIIGRhdGEgcGxhbmUiIGhlcmUgaXMgdGhlIGNvbWJpbmF0aW9uIG9mIFJGQyA4NzU0 DQpBTkQgUkZDIDg5ODYgKFNSdjYgTmV0d29yayBQcm9ncmFtbWluZykuDQoNClRoZSBzZWNvbmQg c2VudGVuY2UgaW4gdGhlIGRyYWZ0IHNheXM6DQoiU1J2NiBOZXR3b3JrIFByb2dyYW1taW5nIFtS RkM4OTg2XSBkZWZpbmVzIGEgZnJhbWV3b3JrIHRvIGJ1aWxkIGENCm5ldHdvcmsgcHJvZ3JhbSB3 aXRoIHRvcG9sb2dpY2FsIGFuZCBzZXJ2aWNlIHNlZ21lbnRzIGNhcnJpZWQgaW4gYQ0KU2VnbWVu dCBSb3V0aW5nIGhlYWRlciAoU1JIKSBbUkZDODc1NF0uIg0KDQpTbyBJIHRoaW5rIHRoZSBjb250 ZXh0IG9mIHRoZSBkcmFmdCBpcyBTUnY2IE5ldHdvcmsgcHJvZ3JhbW1pbmcuLi4gaW4NCnRoaXMg Y29udGV4dCB0aGUgYmFzaWMgaWRlYSBpcyB0aGF0IHlvdSBjYW4gYWRkIG5ldyBmZWF0dXJlcyAo aS5lLiBuZXcNCmluc3RydWN0aW9ucykgaW4gc3BlY2lmaWMgbm9kZXMgYW5kIGFkZCB0aGUgIm5l dHdvcmsgcHJvZ3JhbSIgaW4gdGhlDQpwYWNrZXQgaGVhZGVyIHNvIHRoYXQgeW91IGtub3cgaW4g YWR2YW5jZSB3aGljaCBub2RlcyB3aWxsIGV4ZWN1dGUgd2hpY2gNCmluc3RydWN0aW9ucy4NCg0K SW4gdGhpcyB3YXkgeW91IGNhbiBpbmNsdWRlIGluIHlvdXIgbmV0d29yayBhIG1peCBvZiAibGVn YWN5IiBSRkMgODc1NA0Kbm9kZXMgKHRoYXQgZG8gbm90IG5lZWQgdG8gaW1wbGVtZW50IHRoZSBu ZXcgZmVhdHVyZXMpIGFuZCBub2RlcyB0aGF0DQpzdXBwb3J0IHRoZSBuZXcgZmVhdHVyZXMgKGUu Zy4gdGhlIENTSUQgZmxhdm91cnMpLg0KDQpJIHRoaW5rIHRoaXMgZ2l2ZXMgYSByZWFzb25hYmxl IGludGVycHJldGFpb24gb2YgImRvZXMgbm90IHJlcXVpcmUgYW55DQpTUkggZGF0YSBwbGFuZSBj aGFuZ2UiLi4uIHRob3VnaCBJIGFncmVlIGl0IGNvdWxkIGJlIGJldHRlciBleHBsYWluZWQNCg0K Y2lhbw0KU3RlZmFubw0KDQo= --_000_5732621F66344F98A9702655DE044951junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpIFN0ZWZhbm8sDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5XZSBhZ3JlZSBvbiB0aGUgb3ZlcmFy Y2hpbmcgcG9pbnQsIHdoaWNoIGlzIHRoYXQgdGhlIHN0YXRlbWVudCBpc27igJl0IGNsZWFyIGFz IHdyaXR0ZW4uJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5JIHRha2UgeW91ciBwb2ludCBhYm91dCByZWFkaW5nIGl0IGluIHRo ZSBjb250ZXh0IG9mIFNSdjYgTmV0d29yayBQcm9ncmFtbWluZywgYW5kIEkgd291bGQgYWJzb2x1 dGVseSBhZ3JlZSB0aGF0IGl04oCZcyByaWdodCB0byB0YWxrIGFib3V0IOKAnHRoZSZuYnNwO05l dHdvcmsgUHJvZ3JhbW1pbmcgcGFyYWRpZ23igJ0sIGJ1dCByaWdodCBub3cgSSBkb27igJl0IHNl ZSB0aGlzIHBhcmFkaWdtIGFzIGRlZmluaW5nIOKAnGEgZGF0YSBwbGFuZeKAnSBpbg0KIGEgdXNl ZnVsIHNlbnNlLiBJIHdvbuKAmXQgZ28gaW50byBncmVhdGVyIGRldGFpbCBvbiB0aGlzIHJpZ2h0 IG5vdyBzaW5jZSBpdCBtYXkgcmVwcmVzZW50IGEgc2VyaW91cyB0YW5nZW50IGFuZCBtaWdodCBu b3QgZW5kIHVwIGJlaW5nIHJlbGV2YW50IGRlcGVuZGluZyBvbiBob3cgdGhlIGF1dGhvcnMgKGFu ZCBXRyBpZiB0aGUgZG9jdW1lbnQgaXMgYWRvcHRlZCkgZGVjaWRlIHRvIGFkZHJlc3MgdGhlIGNv bmNlcm4uPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5UaGFua3MgZm9yIHlvdXIgaGVscGZ1bCByZXBseSw8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPuKAlEpvaG48L2Rpdj4NCjxk aXYgY2xhc3M9IiI+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUi IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBPY3QgMTMsIDIwMjEsIGF0IDc6NTMgUE0sIFN0 ZWZhbm8gU2Fsc2FubyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZWZhbm8uc2Fsc2Fub0B1bmlyb21h Mi5pdCIgY2xhc3M9IiI+c3RlZmFuby5zYWxzYW5vQHVuaXJvbWEyLml0PC9hPiZndDsgd3JvdGU6 PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFz cz0iIj48c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxOHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9u ZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5IaQ0KIEpvaG4sPC9zcGFu PjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiAxOHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIg c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMThweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogMThweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9y bWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFs aWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRl LXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlu bGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+SQ0KIGFncmVlIHRoYXQgdGhlIHN0YXRlbWVudCAm cXVvdDt0aGlzIHNvbHV0aW9uIGRvZXMgbm90IHJlcXVpcmUgYW55IFNSSCBkYXRhPC9zcGFuPjxi ciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGlj YTsgZm9udC1zaXplOiAxOHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiAxOHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBu b3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTog aW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5wbGFuZQ0KIGNoYW5nZSZxdW90OyBuZWVkcyB0 byBiZSBjbGFyaWZpZWQsIGFsc28gYmVjYXVzZSB0aGVyZSBpcyBubyBmb3JtYWw8L3NwYW4+PGJy IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDE4cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDE4cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBp bmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPmRlZmluaXRpb24NCiBvZiBhICZxdW90O2RhdGEg cGxhbmUmcXVvdDssIGhlbmNlIGl0IGlzIGV2ZW4gbW9yZSB2YWd1ZSB0aGUgJnF1b3Q7U1JIIGRh dGE8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE4cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNm b3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDE4cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25l OyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPnBsYW5lJnF1b3Q7Ljwvc3Bh bj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMThweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPGJy IHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IDE4cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9r ZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDE4cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBp bmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPk15DQogdW5kZXJzdGFuZGluZyBvZiAmcXVvdDtT UkggZGF0YSBwbGFuZSZxdW90OyBoZXJlIGlzIHRoZSBjb21iaW5hdGlvbiBvZiBSRkMgODc1NDwv c3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMThweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06 IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0K PHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2 ZXRpY2E7IGZvbnQtc2l6ZTogMThweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRp c3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+QU5EDQogUkZDIDg5ODYgKFNSdjYg TmV0d29yayBQcm9ncmFtbWluZykuPC9zcGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxOHB4OyBmb250LXN0 eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVu dDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0 aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwg MCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMThweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBs ZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBw eDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjog bm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7 IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMThweDsgZm9udC1zdHlsZTogbm9y bWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsg dGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9u ZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+VGhl DQogc2Vjb25kIHNlbnRlbmNlIGluIHRoZSBkcmFmdCBzYXlzOjwvc3Bhbj48YnIgc3R5bGU9ImNh cmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMThweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0 LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MThweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1w b3J0YW50OyIgY2xhc3M9IiI+JnF1b3Q7U1J2Ng0KIE5ldHdvcmsgUHJvZ3JhbW1pbmcgW1JGQzg5 ODZdIGRlZmluZXMgYSBmcmFtZXdvcmsgdG8gYnVpbGQgYTwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0 LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MThweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMThw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRl eHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0 YW50OyIgY2xhc3M9IiI+bmV0d29yaw0KIHByb2dyYW0gd2l0aCB0b3BvbG9naWNhbCBhbmQgc2Vy dmljZSBzZWdtZW50cyBjYXJyaWVkIGluIGE8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE4cHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6 IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRl Y29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE4cHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5v cm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29y YXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNs YXNzPSIiPlNlZ21lbnQNCiBSb3V0aW5nIGhlYWRlciAoU1JIKSBbUkZDODc1NF0uJnF1b3Q7PC9z cGFuPjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhl bHZldGljYTsgZm9udC1zaXplOiAxOHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3Jt YWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4 dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8 YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogMThweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fw czogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogMThweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczog bm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0 LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdo aXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6 IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+U28NCiBJIHRoaW5rIHRoZSBjb250ZXh0IG9m IHRoZSBkcmFmdCBpcyBTUnY2IE5ldHdvcmsgcHJvZ3JhbW1pbmcuLi4gaW48L3NwYW4+PGJyIHN0 eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDE4cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl PSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDE4cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxp bmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPnRoaXMNCiBjb250ZXh0IHRoZSBiYXNpYyBpZGVhIGlz IHRoYXQgeW91IGNhbiBhZGQgbmV3IGZlYXR1cmVzIChpLmUuIG5ldzwvc3Bhbj48YnIgc3R5bGU9 ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQt c2l6ZTogMThweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs OyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWdu OiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNw YWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNh cmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMThweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAh aW1wb3J0YW50OyIgY2xhc3M9IiI+aW5zdHJ1Y3Rpb25zKQ0KIGluIHNwZWNpZmljIG5vZGVzIGFu ZCBhZGQgdGhlICZxdW90O25ldHdvcmsgcHJvZ3JhbSZxdW90OyBpbiB0aGU8L3NwYW4+PGJyIHN0 eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDE4cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl PSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDE4cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxp bmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPnBhY2tldA0KIGhlYWRlciBzbyB0aGF0IHlvdSBrbm93 IGluIGFkdmFuY2Ugd2hpY2ggbm9kZXMgd2lsbCBleGVjdXRlIHdoaWNoPC9zcGFuPjxiciBzdHls ZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9u dC1zaXplOiAxOHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Y2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiAxOHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246 IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3Bh Y2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6 IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5l ICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5pbnN0cnVjdGlvbnMuPC9zcGFuPjxiciBzdHlsZT0iY2Fy ZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl OiAxOHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9IiI+DQo8YnIgc3R5bGU9ImNhcmV0LWNv bG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMThw eDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRl eHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9y OiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMThweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50 OyIgY2xhc3M9IiI+SW4NCiB0aGlzIHdheSB5b3UgY2FuIGluY2x1ZGUgaW4geW91ciBuZXR3b3Jr IGEgbWl4IG9mICZxdW90O2xlZ2FjeSZxdW90OyBSRkMgODc1NDwvc3Bhbj48YnIgc3R5bGU9ImNh cmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMThweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBm b250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw cHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0 LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTog MThweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250 LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1w b3J0YW50OyIgY2xhc3M9IiI+bm9kZXMNCiAodGhhdCBkbyBub3QgbmVlZCB0byBpbXBsZW1lbnQg dGhlIG5ldyBmZWF0dXJlcykgYW5kIG5vZGVzIHRoYXQ8L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1j b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE4 cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0 ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjYXJldC1jb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE4cHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0 LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFu dDsiIGNsYXNzPSIiPnN1cHBvcnQNCiB0aGUgbmV3IGZlYXR1cmVzIChlLmcuIHRoZSBDU0lEIGZs YXZvdXJzKS48L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE4cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsg LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBj bGFzcz0iIj4NCjxiciBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxOHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyIgY2xhc3M9 IiI+DQo8c3BhbiBzdHlsZT0iY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxOHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBmbG9hdDogbm9u ZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5JDQogdGhpbmsgdGhpcyBn aXZlcyBhIHJlYXNvbmFibGUgaW50ZXJwcmV0YWlvbiBvZiAmcXVvdDtkb2VzIG5vdCByZXF1aXJl IGFueTwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMThweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNz PSIiPg0KPHNwYW4gc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMThweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsgZmxvYXQ6IG5v bmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+U1JIDQogZGF0YSBwbGFu ZSBjaGFuZ2UmcXVvdDsuLi4gdGhvdWdoIEkgYWdyZWUgaXQgY291bGQgYmUgYmV0dGVyIGV4cGxh aW5lZDwvc3Bhbj48YnIgc3R5bGU9ImNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMThweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250 LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2lu Zzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiIGNsYXNz PSIiPg0KPGJyIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDE4cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5v cm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVs dmV0aWNhOyBmb250LXNpemU6IDE4cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50 LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1h bDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBk aXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPmNpYW88L3NwYW4+PGJyIHN0eWxl PSJjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IDE4cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1h bDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJj YXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNp emU6IDE4cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsg Zm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUg IWltcG9ydGFudDsiIGNsYXNzPSIiPlN0ZWZhbm88L3NwYW4+PGJyIHN0eWxlPSJjYXJldC1jb2xv cjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDE4cHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0 LWRlY29yYXRpb246IG5vbmU7IiBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5732621F66344F98A9702655DE044951junipernet_-- From nobody Thu Oct 14 10:04:43 2021 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 767693A1756; Thu, 14 Oct 2021 10:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 iRFoAUVeKGlO; Thu, 14 Oct 2021 10:04:35 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 047203A1752; Thu, 14 Oct 2021 10:04:34 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id k2-20020a056830168200b0054e523d242aso9148840otr.6; Thu, 14 Oct 2021 10:04: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=QZP/SlTxjb2dNXQcCoBIAt1Bo9mTA3CFuvh0bKz6ctY=; b=Z82YCnXa/k/GmCNBph8G7xtcXfW5MBbg8ezznZFLRB/jxjLqVoReKvIsLiytQKPwT0 myhvkcui5k/pDgkoxY+Yn+16l/LazhQx8WkWKo86eAWzdIkE7yaKM8UK2tDQExksFnZK XyFKq8IZtjo/00vS8c69/Cv58chv7dhzLMJjSjESZgxylEhBubRY2EK3i2D3yxCsY3HM bQCCw4T0r9cFk5uN7nzwKxzVS1jgkvhznHFtvGgwbd+zNNFiKyNvaUJke61pvkhgfblt AHqzqFTgybJRgfB2yJ5YNjsMH8eakx5SCQgqBp+a0Owu/kCt1Ng4wvIcTdzyddIHYfve oZBg== 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=QZP/SlTxjb2dNXQcCoBIAt1Bo9mTA3CFuvh0bKz6ctY=; b=GFeyGphi68hk6G586QlR2efNYislxz5lBYdfEeT8TurEJM/tMyuNwFUTsfAGnmdTup qM4USXIrD8Dqx5BYd7ctAQIht8IfAR+X/AUx++9fqrDHi/qUtjo0hlWIUzpTuZx/1dnV etyHlXajd+lWU9zdcCmCaLJuL8aGkO88hOyaFJrZkudueW+Xc8O+SL1MJax2TH3h1GIG b64AvvvhhxBa4Vw5APs1loFTDdT4HKTseTt5ew8zmbo8zT9mnp+bPHc8DZ9FJXFTDLbk 7VJpQojwkcQDCOZHajrEtLq8pCa8HIvDnO0k5s20EGznIkLgmhSENzgPoD2aYPH4fTFL CeQg== X-Gm-Message-State: AOAM530kIp3WKFgAsIMazEUr8ZvrSr60g9pvMoYwqRD6fSB+0tgfzFbM jN22aUuK2RIsB8fYBUn8WW4HXf8iXG8zvCCeaEBOteem X-Google-Smtp-Source: ABdhPJwIr2LZON6ayvoHe0D5ew7N+M4NDL52YroF5fBb91qHRzbS8TMqKVLYE+/r1Jjn5FYQtXbeGxGWuZJpi5uVgXY= X-Received: by 2002:a05:6830:349:: with SMTP id h9mr3430609ote.349.1634231073790; Thu, 14 Oct 2021 10:04:33 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> In-Reply-To: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> From: Erik Kline Date: Thu, 14 Oct 2021 10:04:23 -0700 Message-ID: To: "Joel M. Halpern" Cc: "ipv6@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a25fe505ce531293" Archived-At: Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 14 Oct 2021 17:04:41 -0000 --000000000000a25fe505ce531293 Content-Type: text/plain; charset="UTF-8" Joel, Thank you for your email. The ADs and chairs have been discussing. One thing that would be very helpful to our discussions would be some worked examples of the various C-SID behaviors, showing some SRv6 datagrams and what happens to their contents as they move across some suitable example SR domain. (It would also be helpful if they showed what happens to something like an ICMPv6 Echo Request to a representative Destination Address in these cases when, say, an SRH is not present, i.e. to see when typical unicast semantics are preserved or when something more like anycast or multicast behavior is to be expected.) Assuming some forthcoming helpful examples, we have a goal to get a more complete answer back to you by the latter half of next week. Thanks, -Erik On Tue, Oct 12, 2021 at 8:53 PM Joel M. Halpern wrote: > The SPRING working group is in the midst of an adoption call on > > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > . > > The SPRING charter has text that is explicit that modifications to data > planes and architectures standardized by other working groups may not be > modified in SPRING unless the chairs and ADs responsible for that data > plane and / or architecture agree. > > To complete the context, as my SPRING co-chairs are co-authors on the > document in question, they have recused themselves from decisional > activities regarding the document. Therefore, this message is coming > just from my as the responsible SPRING co-chair managing this adoption > call. > > As you have seen, multiple questions have been raised about the > relationship of the document to the IPv6 defined data plane and > architecture (particularly RFC 4291 and 8200). In particular the > questions seem to revolve around what the document describes as the > NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6 > standards. (For those seeking more context without reading the full > document, a paraphrase and simplification of the NEXT-C_SID flavor is > provided as a postscript.) > > I raised the question of concurrence as required by the SPRING charter > with the Internet ADs and SPRING chairs. They quite reasonably asked me > to write a note to 6man explaining the concerns as clearly as a can, so > that they can then determine how to proceed. > > The questions that prompted my inquiry are: > > 1) Does the placement of a list of sids in the IPv6 DA field change the > IPv6 architectural description of that field. > 2) Does the operation of shifting information around in the IPv6 > destination address field represent a modification or extension of the > IPv6 data plane. > > On a related note, the document in question also defines two other > flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The > NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID > flavor operation, so seems to be affected by the same question. > > From my own reading, it appears that the REPLACE-C-SID flavor does not > raise issues requiring 6man leadership concurrence. > > Yours, > Joel M. Halpern for the SPRING working group > > > PS: > Clearly, understanding the question requires some understanding of what > the NEXT-C_SID flavor does. This explanation is a simplification for > length and context. Really, the best place to understand it is the > draft. However, to give you enough information to let you decide > whether you care, I will try to provide a fair summary. My apologies in > advance to the authors for necessary liberties for length. Also, > discussion of the draft contents (as distinct from the interaction with > the IPv6 data plane and architecture) belongs on the SPRING list, and > should not clutter up 6man. > > SIDs are the identifiers used in segment routing. > In SRv6, as document in the current RFCs, these are 128 bits. As > defined in the relevant RFCs, SIDs which identify endpoints to which > packets are directed are identified by endpoint SIDs. These can have > behaviors (decapsulate and forward is one example). They can have > flavors such as where the SRH is removed. > > The topic under discussion is means to compress these SIDs in the > packets on the wire. The document under discussion provides three > flavors of compression. > > The fundamental mechanism of the draft is to use a single SRH entry as a > container for multiple SIDs. In the NEXT-C_SID mechanism, when it is > first encountered the entire container is copied into the desination > address of the IPv6 packet. The container has a common routing prefix > used for all the NEXT-C-SID SIDs. It is followed by a sequence of > compressed SIDs of a configured length. One could configure 16, 24, or > 32 bits. Or whatever length. The routing advertisements are arranged > so that the IPv6 packet is directed to the node represented by the first > compressed SID on the basis of longest prefix match matching the > combination of the common routing prefix and that compressed SID. > > When the packet arrives at that node, it looks up the configured > portion, the compressed SID, and determines the behavior and flavor. In > the case of the NEXT-C-SID flavor, the resulting operation is to shift > the entire remaining contents of the IPv6 address (the bits past the > first compressed sid) so as to over-write the first compressed SID. 0 > bits are shifted into the low order positions. If the result is a > non-zero new first compressed SID, then the packets is forwarded and the > process repeats. When all that is left are 0s, if there is an SRH, it > is consulted to find the next SRH entry, which is, per normal SRv6 > processing, put into the IPv6 DA. > Note that in the common case where the SIDS needed all fit in to a > single container, the analysis also assumes the use of the reduced > encapsulation options which omits the SRH that is not needed as it would > have no entries. This the packet contains a normal IPv6 header, with a > sequence of compressed SIDs (what one might or might not call a source > route) in the IPv6 destination address field. > > PPS: If the authors of the NEXT-C-SID flavor feel I have mis-represented > the work, please, send clarifications or corrections. Again, the best > source of information is the draft itself. I was asked to provide extra > context in this email. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --000000000000a25fe505ce531293 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Joel,

    Thank you for your email.=C2=A0 T= he ADs and chairs have been discussing.

    One thing = that would be very helpful to our discussions would be some worked examples= of the various C-SID behaviors, showing some SRv6 datagrams and what happe= ns to their contents as they move across some suitable example SR domain.

    (It would also be helpful if they showed what happe= ns to something like an ICMPv6 Echo Request to a representative Destination= Address in these cases when, say, an SRH is not present, i.e. to see when = typical unicast semantics are preserved or when something more like anycast= or multicast behavior is to be expected.)

    Assumin= g some forthcoming helpful examples, we have a goal to get a more complete = answer back to you by the latter half of next week.

    Thanks,
    -Erik

    On Tue, Oct 12, 2021 at 8:53 PM Joel M. Halp= ern <jmh@joelhalpern.com> = wrote:
    The SPRIN= G working group is in the midst of an adoption call on
    https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/.

    The SPRING charter has text that is explicit that modifications to data planes and architectures standardized by other working groups may not be modified in SPRING unless the chairs and ADs responsible for that data
    plane and / or architecture agree.

    To complete the context, as my SPRING co-chairs are co-authors on the
    document in question, they have recused themselves from decisional
    activities regarding the document.=C2=A0 Therefore, this message is coming =
    just from my as the responsible SPRING co-chair managing this adoption call= .

    As you have seen, multiple questions have been raised about the
    relationship of the document to the IPv6 defined data plane and
    architecture (particularly RFC 4291 and 8200). In particular the
    questions seem to revolve around what the document describes as the
    NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6
    standards.=C2=A0 (For those seeking more context without reading the full <= br> document, a paraphrase and simplification of the NEXT-C_SID flavor is
    provided as a postscript.)

    I raised the question of concurrence as required by the SPRING charter
    with the Internet ADs and SPRING chairs.=C2=A0 They quite reasonably asked = me
    to write a note to 6man explaining the concerns as clearly as a can, so that they can then determine how to proceed.

    The questions that prompted my inquiry are:

    1) Does the placement of a list of sids in the IPv6 DA field change the IPv6 architectural description of that field.
    2) Does the operation of shifting information around in the IPv6
    destination address field represent a modification or extension of the
    IPv6 data plane.

    On a related note, the document in question also defines two other
    flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.=C2=A0 The
    NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID
    flavor operation, so seems to be affected by the same question.

    =C2=A0From my own reading, it appears that the REPLACE-C-SID flavor does no= t
    raise issues requiring 6man leadership concurrence.

    Yours,
    Joel M. Halpern for the SPRING working group


    PS:
    Clearly, understanding the question requires some understanding of what the NEXT-C_SID flavor does.=C2=A0 =C2=A0This explanation is a simplificatio= n for
    length and context.=C2=A0 Really, the best place to understand it is the draft.=C2=A0 However, to give you enough information to let you decide
    whether you care, I will try to provide a fair summary.=C2=A0 My apologies = in
    advance to the authors for necessary liberties for length.=C2=A0 Also,
    discussion of the draft contents (as distinct from the interaction with the IPv6 data plane and architecture) belongs on the SPRING list, and
    should not clutter up 6man.

    SIDs are the identifiers used in segment routing.
    In SRv6, as document in the current RFCs, these are 128 bits.=C2=A0 =C2=A0A= s
    defined in the relevant RFCs, SIDs which identify endpoints to which
    packets are directed are identified by endpoint SIDs.=C2=A0 These can have =
    behaviors (decapsulate and forward is one example).=C2=A0 They can have flavors such as where the SRH is removed.

    The topic under discussion is means to compress these SIDs in the
    packets on the wire.=C2=A0 The document under discussion provides three flavors of compression.

    The fundamental mechanism of the draft is to use a single SRH entry as a container for multiple SIDs.=C2=A0 In the NEXT-C_SID mechanism, when it is =
    first encountered the entire container is copied into the desination
    address of the IPv6 packet.=C2=A0 The container has a common routing prefix=
    used for all the NEXT-C-SID SIDs.=C2=A0 It is followed by a sequence of compressed SIDs of a configured length.=C2=A0 One could configure 16, 24, o= r
    32 bits.=C2=A0 Or whatever length.=C2=A0 The routing advertisements are arr= anged
    so that the IPv6 packet is directed to the node represented by the first compressed SID on the basis of longest prefix match matching the
    combination of the common routing prefix and that compressed SID.

    When the packet arrives at that node, it looks up the configured
    portion, the compressed SID, and determines the behavior and flavor.=C2=A0 = In
    the case of the NEXT-C-SID flavor, the resulting operation is to shift
    the entire remaining contents of the IPv6 address (the bits past the
    first compressed sid) so as to over-write the first compressed SID.=C2=A0 0=
    bits are shifted into the low order positions.=C2=A0 If the result is a non-zero new first compressed SID, then the packets is forwarded and the process repeats.=C2=A0 When all that is left are 0s, if there is an SRH, it=
    is consulted to find the next SRH entry, which is, per normal SRv6
    processing, put into the IPv6 DA.
    Note that in the common case where the SIDS needed all fit in to a
    single container, the analysis also assumes the use of the reduced
    encapsulation options which omits the SRH that is not needed as it would have no entries.=C2=A0 This the packet contains a normal IPv6 header, with = a
    sequence of compressed SIDs (what one might or might not call a source
    route) in the IPv6 destination address field.

    PPS: If the authors of the NEXT-C-SID flavor feel I have mis-represented the work, please, send clarifications or corrections.=C2=A0 =C2=A0Again, th= e best
    source of information is the draft itself.=C2=A0 I was asked to provide ext= ra
    context in this email.

    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --000000000000a25fe505ce531293-- From nobody Thu Oct 14 11:49:51 2021 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 C1A943A0835 for ; Thu, 14 Oct 2021 11:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 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, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=noviflow.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 XbBkXE9h5NTw for ; Thu, 14 Oct 2021 11:49:43 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (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 E05F43A0869 for ; Thu, 14 Oct 2021 11:49:42 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id m22so22203864wrb.0 for ; Thu, 14 Oct 2021 11:49:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=noviflow.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=Ksv2NXZ2VgentXbShfjvEJeKKm8VPLN+TjYzdnh0Gbs=; b=X9HilCBGU/REkM0Lsc2bMrYloVfJJdc4nuOpx733VpXTgJkg4aAooOS+SjIcfPjr8a ewgmSVdlHTE4ZniCQU2u6vsTvHF76x509hjrOBrPXKEFd72MmzTRAXfJrgQNO8PiXCLh SRXpRvAKEMXi6pIApCYZ66gPfKHDCaRjmhqVQX4bg13w/jppmPOYCFc0R0T5HR3PJnkW CtsQKgDTL24pl31Cx4ZCP4CpbNsBL05Utka8tgW6l32myXni1y7d24FFkIzKcVSK9RTK ZKaL8CjtnriuRQf0PLNvrfX+ykV3NmZcC4abxQm4YUy3/5Nemmmv+i8D5VjZ0oF2coay Nj3Q== 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; bh=Ksv2NXZ2VgentXbShfjvEJeKKm8VPLN+TjYzdnh0Gbs=; b=vrMWLW6Qix+QsUNPywiKwXPmZv5hqerTGSNd2y4/vyx0F/IqWkWTMug++kAhj9uSoM 7g+KhShRD3PSXgH3/MASMEKyTcGVNtFtz5bP7ZbWeDnvwjOqDWlQe7ZDnsCLAprmwHHx b32vg/l98KiJOHJRT1lPCZsu/YMNsR/JfFZe+L6JEc69Z+KENQLgjFHUqOjpjhIYhci/ meWBVcg5EuioEy5QL4cnI615Wwpp1ZRfK2x4kWe4UE9ZvjIQYfto2DmAqJuISWcWH86r np4L2v5yB1bm/tFiaqWaFDmy6v/wAdQ/lOX+x/f9ZiEgg5v3ITk+dtuqQL9QDu/kUJ9B GSFQ== X-Gm-Message-State: AOAM530nengTvZ6bODNPlVikCcAvyzS7UXgqFZPJuTeETJu6KKhOtA/H x6GjFT/cbIFyioCiqC807hqyJ5384YxzqZiXTfNxx1Fb7B0= X-Google-Smtp-Source: ABdhPJzQfUZkbgGOwoZlhRNya0BXwIJWc5d+OwPczHg8fcbxE/5DC1Cx/plqaPww+wij2uHwSIJf1GrIhyP1Ede6bho= X-Received: by 2002:adf:b350:: with SMTP id k16mr8681503wrd.368.1634237378245; Thu, 14 Oct 2021 11:49:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: andre beliveau Date: Thu, 14 Oct 2021 14:49:26 -0400 Message-ID: To: SPRING WG , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="00000000000068d04705ce548adc" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 14 Oct 2021 18:49:48 -0000 --00000000000068d04705ce548adc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear WG and the WG Chairs, The draft https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ is based on SRv6 data plane (RFC8986). RFC8996 already defines multiple behaviors and flavors. As such, RFC8986 nor this draft mandates an SRv6 data plane node to support all behaviors and flavors. It only adds additi= onal flavors for SRv6 compression to RFC8986. We, at NoviFlow, have implemented a CSID solution. I strongly support the adoption of the draft and believe that it is valid and coherent with the WG objective of one data plane solution. Regards, Andr=C3=A9 B=C3=A9liveau NoviFlow On Fri, Oct 1, 2021 at 10:05 AM James Guichard < james.n.guichard@futurewei.com> wrote: > Dear WG: > > > > The chairs would like to express their appreciation for all the responses > received to our emails with reference to how the working group wishes to > move forward with respect to a solution for SRv6 compression. > > > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > as the basis for its compression standardization work. That is part of wh= at > this email attempts to confirm. > > > > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging > that: > > > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change = as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the working > group to publication. A list of these discussion points will be docume= nted > in the WG document and maintained by the document editor in conjunctio= n > with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text describin= g an > open issue be added to the document in the above-described open issues > section: > - "Given that the working group has said that it wants to > standardize one data plane solution, and given that the document co= ntains > multiple SRv6 EndPoint behaviors that some WG members have stated a= re > multiple data plane solutions, the working group will address wheth= er this > is valid and coherent with its one data plane solution objective.". > > > > Please consider the above guidelines as you decide on whether to support > or not this WG adoption. Please express clearly your reasoning for > support/non-support as well as any open discussion points you would like > addressed should the document be adopted into the working group. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --=20 *Andr=C3=A9 B=C3=A9liveau* Director Product Management M : +1 514-502-9592 andre.beliveau@noviflow.com www.noviflow.com --00000000000068d04705ce548adc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    This ele= ctronic communication and the information and any files transmitted with it= , or attached to it, are confidential and are intended solely for the use o= f the individual or entity to whom it is addressed and may contain informat= ion that is confidential, legally privileged, protected by privacy laws, or= otherwise restricted from disclosure to anyone else. If you are not the in= tended recipient or the person responsible for delivering the e-mail to the= intended recipient, you are hereby notified that any use, copying, distrib= uting, dissemination, forwarding, printing, or copying of this e-mail is st= rictly prohibited. If you received this e-mail in error, please return the = e-mail to the sender, delete it from your computer, and destroy any printed= copy of it._______________________________________________ spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    <= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ">Dear WG and the WG= Chairs,

    The draft=C2=A0https://datatracker.ietf.org/doc/draft-filsfilsch= eng-spring-srv6-srh-compression/=C2=A0=C2=A0is based on SRv6 data plane (RFC8986).=C2=A0 RFC8996 already defines mult= iple behaviors and flavors.=C2=A0=C2=A0As such, RFC8986 nor this draft mandates an SRv6 = data plane node to support all behaviors and flavors.=C2=A0=C2=A0It only=C2=A0 adds=C2= =A0additional= flavors for SRv6 compression to RFC8986.

    We, at NoviFlo= w, have implemented a CSID solution.

    I strongly suppor= t the adoption of the draft and believe that it is valid and coherent with = the WG objective of one data plane solution.

    Regards= ,=C2=A0
    Andr=C3=A9 B=C3=A9liveau
    NoviFlow


    On= Fri, Oct 1, 2021 at 10:05 AM James Guichard <james.n.guichard@futurewei.com> wrote:

    Dear WG:

    =C2=A0

    The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

    =C2=A0

    The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

    =C2=A0

    Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

    =C2=A0

    1. The SPRING working group is adopting a docume= nt that has multiple SRv6 Endpoint behaviors.
    2. The document is a =E2=80= =9Cliving=E2=80=9D document; it may change as it goes through review and an= alysis by the SPRING working group.
    3. All open discussion points= raised on our mailing list MUST be addressed BEFORE said document is allow= ed to progress from the working group to publication. A list of these discu= ssion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
    4. If this document is adopte= d by the working group, the chairs specify as part of the adoption call tha= t the following text describing an open issue be added to the document in t= he above-described open issues section:
      • "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

    =C2=A0

    Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

    =C2=A0

    Thanks!

    =C2=A0

    Jim, Bruno & Joel

    =C2=A0

    =C2=A0

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


    --

    Andr=C3=A9 B=C3=A9liveau=

    Director Product Management

    M=C2=A0: +1 514-502-95= 92

    andre.beliveau@noviflow.com

    =

    =C2=A0

    www.no= viflow.com

    --00000000000068d04705ce548adc-- From nobody Thu Oct 14 14:06:47 2021 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 358B33A0870; Thu, 14 Oct 2021 14:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ydX6-VAeMfrO; Thu, 14 Oct 2021 14:06:31 -0700 (PDT) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (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 3B5AE3A0D6F; Thu, 14 Oct 2021 14:06:31 -0700 (PDT) Received: by mail-pg1-x529.google.com with SMTP id m21so6619448pgu.13; Thu, 14 Oct 2021 14:06:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=Amy9gc7H0x8HJS+EAptVnzqydNA1Mr7o9Bc5FX2+0yI=; b=fIvvVF4eKIu4ks5pQlJf3fgyJf5nkZCb7f0tI7lRdlWIR7rJH2fRyEi0lnhisMEbjZ CMdMm6y7HTWWmxcw2GSThmpdvj5fYHWY9Xdk6MBFM1zx4ppqm1Kio+FloCsBUlLef5rK ayuP8CNhcWobn27j2drbB689UTbcizmFBroek3DR7py55FRsobtTY4JGGE1q90BcZEtI p3JSsnyFfhRQt2KU0ra1IlYMR8CaZMQ4lKzToOG3+HbcUURvv/PxhD3zBauibx7wc0N0 OZlnNWtaAj1NYJGJvb+080OXNPBfeaqvACYlAT0rX4hKBgAMflM0g5TDZPoFK/jWe5cx CRbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Amy9gc7H0x8HJS+EAptVnzqydNA1Mr7o9Bc5FX2+0yI=; b=M3902URfAME5oBaDafc0XqseJDengk0nC96WVtwbY+fFXfBGrM4khJzUIz3uYuvcNK BWvZuGqgzhYWKY3dpMLTuo3Btnc5bC9/FdYH6afbAyjgsSuATVCAaQGDuf8ayTV4FFZM 5nZqDx4ZZPN2LG5zy6SIMIYXQvCTwfcPz2nKHKQ6TyfVM4ykZawDxeJ8BPJxYFbvQL6t wEN2mYyAohcLHIKBb1HshFXoEwpne991dgxe1ABPik0g5I4fvEzZM8EsLuM/yzoA3jI7 mmwVKEYJ2+HMmdQpTHEJZcJ41h5oLiSXAjJttKahc9b/Gc5NPqA+2Afb8Qs2dVjyJThR LfMA== X-Gm-Message-State: AOAM532azzucf0U1x+HpIufmSL+JQl1K/MlrUGfxjkp/SsTi4TwBG3MV eN4DtF8rNcYLPZ36rxah+fHXI88TYhw= X-Google-Smtp-Source: ABdhPJy33SCI4A/xxOs4VW8XyUUZMip8QCxhr/5e2Y0wIW0u9v9RTwhD8CmI8hD+EIDBZjXdU5RTsw== X-Received: by 2002:a63:d40b:: with SMTP id a11mr5991756pgh.456.1634245590147; Thu, 14 Oct 2021 14:06:30 -0700 (PDT) Received: from ?IPv6:2406:e003:102d:e801:db7:d041:a2d:ce65? ([2406:e003:102d:e801:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id p4sm3082672pgc.15.2021.10.14.14.06.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Oct 2021 14:06:29 -0700 (PDT) To: Ted Hardie Cc: "Joel M. Halpern" , "ipv6@ietf.org" , "spring@ietf.org" References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <1daf3d20-22b2-d111-5131-bd53f51c53a3@gmail.com> From: Brian E Carpenter Message-ID: <60f71d8c-8165-111c-4099-7f926a897d22@gmail.com> Date: Fri, 15 Oct 2021 10:06:24 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 14 Oct 2021 21:06:36 -0000 On 14-Oct-21 22:41, Ted Hardie wrote: > On Wed, Oct 13, 2021 at 9:28 PM Brian E Carpenter > wrote: >=20 >=20 >=20 > Including semantics *of any kind* in an IP address is a very fundam= ental > change to the concept of IP. >=20 >=20 > Would you mind elaborating what you mean by semantics in the statement = above?=C2=A0 Clearly there are semantics in things like the IPv4 multicas= t and experimental address ranges (aka "Class D" and "Class E"); especial= ly for the multicast case, the very fundamental semantics of the distribu= tion are signalled using the address and there has been significant deplo= yment using those semantics.=C2=A0 Isn't that semantics in the meaning ab= ove? Yes, I should have restricted my remark to *unicast* addresses. But there=20 is a difference, I think, between semantics that describe the *type of ad= dress* and semantics that actively describe *what the recipient is going = to do*. It's the latter that I was getting at. (This applies to Carsten's comment too. Port numbers or multiple addresse= s per host are not actively describing what the recipient will do; they'r= e just numbers.) Also, I tried not to express shock and horror at the notion of semantics = in address, but concern about how this will impact existing hardware and = software. >=20 > Thanks for any clarification, >=20 > Ted >=20 From nobody Thu Oct 14 16:34:01 2021 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 340513A1801 for ; Thu, 14 Oct 2021 16:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20210112.gappssmtp.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 Mi5R0RJ_H8Uz for ; Thu, 14 Oct 2021 16:33:04 -0700 (PDT) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFB463A1803 for ; Thu, 14 Oct 2021 16:33:03 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id y30so13587361edi.0 for ; Thu, 14 Oct 2021 16:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=eNqZUYu5eHqgUWUJTCtxYxfVOPeBkmJcDwzFYay68w0=; b=JbvDMbcRPaJMIGbDdwb4mQIoP9KHjSODVd7M+vtzHQ0C704JEObHCZNTDQfBci7nMd 8K/gu0jX3A5JSVg56KeEkuURakhR6RRPHJu44CFEKcBPm0XRB6TNT0scfVee3TMOs4du UDzbDhAuYkZUIjF/eCdlZwlwz8Nlvs7Jjmzn4V/hE8D+dsgyu935Fn7ETIO7h8RYf64y 8ttz2NxjtSBafb8YrdlyFTxAbmMmcj+Q2G0gsVvHvDIhx0WsItUvToADHqq6IaoU2dYq um4VVzOGe3MbpR7/NvCVTV5RHKRf4w8pNNdSuLR0d9nN7kCI59cKvWr+LdUL2q1lVGfu L3Aw== 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:content-transfer-encoding; bh=eNqZUYu5eHqgUWUJTCtxYxfVOPeBkmJcDwzFYay68w0=; b=uFnHpJNX5KNp+npxw/40uQp+CVlsLz+Eg1L278IXMQ94acnoVWXGszaVwAOSvHjY3f tohAq/RPI3vzt/JwxHeJ02Dvimg3KZHx/b8YxgVL4QnyKJ+eayHBGxXPB/jSGU0Nakd+ dA9QW2DQxNMBdd/PT4HMPHPxSfE9TJjZpbUUq/Y36wuH/Aj5GLbBE3UWlgXoKpngmxMJ KMsC3D/zt2awz8viXe/omz1WKTsgnjLuGup8QAgCNKq2qUXU7Q71Yo+VyHI0QtBFPK1/ K2Zolqf50uaoNEpNSp4OeHlrY51z6dp28IwEckJu3BZVLmWmQYuAQ63X9/ckQbaMeF+1 eb4w== X-Gm-Message-State: AOAM530879BKKTZ0DDeRyMA8pXyL0VqYdRJ5TmWFwHDrq7N2qrwM3cca ZBDQHviS4+8+boIglO74mjSUPxnkCxhBx/KPL9C/CA== X-Google-Smtp-Source: ABdhPJyhaQQB14PhXaiTZSBZTB8A1BK+FS9BWCDNT+lup6QBhIX7qt2Th0UdHquXJjnsDsUs5CcjOOkcDibNDB4fz9A= X-Received: by 2002:a50:e384:: with SMTP id b4mr12759343edm.314.1634254380334; Thu, 14 Oct 2021 16:33:00 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <1daf3d20-22b2-d111-5131-bd53f51c53a3@gmail.com> <60f71d8c-8165-111c-4099-7f926a897d22@gmail.com> In-Reply-To: <60f71d8c-8165-111c-4099-7f926a897d22@gmail.com> From: Tom Herbert Date: Thu, 14 Oct 2021 16:32:49 -0700 Message-ID: To: Brian E Carpenter Cc: Ted Hardie , "spring@ietf.org" , "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 14 Oct 2021 23:33:09 -0000 On Thu, Oct 14, 2021 at 2:07 PM Brian E Carpenter wrote: > > On 14-Oct-21 22:41, Ted Hardie wrote: > > On Wed, Oct 13, 2021 at 9:28 PM Brian E Carpenter > wrote: > > > > > > > > Including semantics *of any kind* in an IP address is a very fundam= ental > > change to the concept of IP. > > > > > > Would you mind elaborating what you mean by semantics in the statement = above? Clearly there are semantics in things like the IPv4 multicast and e= xperimental address ranges (aka "Class D" and "Class E"); especially for th= e multicast case, the very fundamental semantics of the distribution are si= gnalled using the address and there has been significant deployment using t= hose semantics. Isn't that semantics in the meaning above? > > Yes, I should have restricted my remark to *unicast* addresses. But there > is a difference, I think, between semantics that describe the *type of ad= dress* and semantics that actively describe *what the recipient is going to= do*. It's the latter that I was getting at. > Brian, Joel's description is very good, and it makes me think that this mechanism is best described as yet another form of NAT. Similar to a NAT device, these devices are rewriting destination addresses per some algorithm which is not necessarily exposed to the outside world. In both NAT and Sid compression, packets are being routed to some intermediate node which is performing address translation and forwarding. The Sid compression method has the advantage that the translation is stateless. While SId compression is explicit as encoded in the destination address set by the sender, it seems like Sid compression would still be transparent to any intermediate node that's not the destination address-- that would include the Internet in packets that were leaked. Given that NAT seems to work okay, I don't immediately see how SId compression would be any more of a problem :-) Tom > (This applies to Carsten's comment too. Port numbers or multiple addresse= s per host are not actively describing what the recipient will do; they're = just numbers.) > > Also, I tried not to express shock and horror at the notion of semantics = in address, but concern about how this will impact existing hardware and so= ftware. > > > > > Thanks for any clarification, > > > > Ted > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Thu Oct 14 17:41:40 2021 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 8CB8F3A14CE; Thu, 14 Oct 2021 17:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=Mt+lWM0A; dkim=pass (1024-bit key) header.d=juniper.net header.b=GfBwySxV 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 bWmqulAXPFDW; Thu, 14 Oct 2021 17:41:30 -0700 (PDT) Received: from mx0b-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 9075D3A14A9; Thu, 14 Oct 2021 17:41:30 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19EIibWI008280; Thu, 14 Oct 2021 17:41:25 -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=LWGXal0l51gZC1I3jPsmIMwue1KnM4+MzyejZE63gWs=; b=Mt+lWM0ALpSRRJ5X9ukZ2bEwgS5CX08dNPi4Gf6ADjgVeOaeJ2ETFGCm8q3e4F17m0fQ FAhugPQAIF5opG8rBr/w5rJQGD2Rzg/eZeUkf8SiMS5EM1GRZ4rPTV2LCjA7+a7glkrn Gt1hyu4nDZ4JUPXfyx3qBUZmtu46Ery46/8+elBvPNwMX+1i1bmSJX83RSqshjfl1Pav J3fFAowIivscDlAteD1KfVClLQYcWAQoAGbJ6QgRoUmC6jjHnGCH4jGXGFSQHVcXhfoz Gg9dmPQj6Ng38sEd7BNWgwuBqbe2Knx/YZqYScPFaNYS+bEkZb041r6wFF118AR/sZH5 Kg== Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2175.outbound.protection.outlook.com [104.47.59.175]) by mx0a-00273201.pphosted.com with ESMTP id 3bpt3g0swe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 14 Oct 2021 17:41:25 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KVnLt5AX9Pu/8YlYjYnk/SGqn0MSTx0j/6ACSqXcwLBAwWW6fR/VZCb8rmc8wuhdm3VS+nYmiAvHeJiwmQXHJJFF80PrKMHkHDbqUvd4TYeyhWZIKp6wlvRbl80dF7XS6/ZuKmw2vT/dpI6/6HJBeO9YV0uIzOXQAXi8f5fgaAqdV35b4iXZVu2QlAW2gYZAEMVqBEo7ZPmU3fo0RSUXdgky4aIRy+uc2K5WvyevIYXwBiyUR8w+YrTZs5rSOTwzOrtEBIJEBpOb5njDeRa1mE+neIIZ0AaJlQ/e0ZgutHlpA6yZ5qPzPw/wOsI9KDng77QkAWZNEqYI8eZa+YNOEQ== 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=LWGXal0l51gZC1I3jPsmIMwue1KnM4+MzyejZE63gWs=; b=jtSlR4zaFHeAlS0GoFqTkEZLaMJxcOnzVeo42gbyW9qvu5jW2YHdVnOAtg2OsOdtlQuujoAJgga+oCr3E+VWbGLIoZDl1N4ptJ/UfLYeV+0Kkr0jOscXjsCTx5fqG6X6b79W++kV1tRBuyWhC6gMuJ/b68mqhe+kwLWKfLXjABlPwwXZ4lWxXF+rf5vKjYxFPJOOkmi9wewr6zZ0kueHu2BAESnZE+I+V82Bk6p1+gwv/maTr3txrIgiAdA/THoS3wGv9/x5VJLxmO+b4PwCZEJDv8Qj2vjnH7gNi6GPVRL8YE6lw4gEXVIg+EJX/f35b4Y8guOZNrCGa6xHIbzz/g== 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=LWGXal0l51gZC1I3jPsmIMwue1KnM4+MzyejZE63gWs=; b=GfBwySxVvA5Ip99pCpEnE2jF1R12u5cY2q3motb0T0oy67YiRZhqdeVV+dRdt4r+zYohgmT+j49vfp9UmPDxZHdrN4pz0Sbo1GdT3SeEWC5aVJM+ROzWAPlMMD8yCYXcHEdEcwGhosW9QbnVMKawVTrLuwI3Zh3fk7amhZcuXSg= Received: from BL0PR05MB5652.namprd05.prod.outlook.com (2603:10b6:208:6a::19) by BL0PR05MB5410.namprd05.prod.outlook.com (2603:10b6:208:66::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.13; Fri, 15 Oct 2021 00:41:23 +0000 Received: from BL0PR05MB5652.namprd05.prod.outlook.com ([fe80::311e:aa39:d3cc:db8d]) by BL0PR05MB5652.namprd05.prod.outlook.com ([fe80::311e:aa39:d3cc:db8d%7]) with mapi id 15.20.4628.010; Fri, 15 Oct 2021 00:41:23 +0000 From: "Jeffrey (Zhaohui) Zhang" To: Tarek Saad , James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQFKdpbcAVbW8xA= Date: Fri, 15 Oct 2021 00:41:22 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=4dc4daac-e4ba-4cbe-b17c-0598b7a1702a; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=0; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-14T23:13:18Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dde570c5-1f86-4fa5-d670-08d98f74833b x-ms-traffictypediagnostic: BL0PR05MB5410: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: pCwxovn9YQmbF6Sp5T6JVoTyxQsfYnw3z0IK9qyq/AiVqrBbtP1UcTa+R9HDMnKQpZKN51u+VNhquIDzRTc2irQeKUe4MigaUxqFBSj33XuYO3wPkYYc8FUBpwki6nMa5S6HXcJ21t5XoYUETqB5hUkmUGYIoi4zHjXzS3yxTuQSOrfhgINtzkUfWy3R5QPhPmvOQMAvZHeQqmyp5VWIrSg2wyVLWAI4yp2e8AgNgYrP9HL7Hf8pJg2mBo3HoVL2I8c+BURpRYydKWqai6wqaSpxRR2PaBooOkHMjWvcnFzTTFA+4XyTQ3HcBX8qbIkeO1CeMrTsVH5ghVe5eDCM4LIs4cermE98v/et9GFobuTwnUV6JyYDAEDml3dpbZiBGCipaU286pyConIqR/pWYKd/tGXBFMUWlHfYiLF7DQMOhS0VV+v6HMPCAKLxeOtwZpNbCfYFRYRHQXSGqxDp1qzl6Yk0IXtAmxmnAn7N2gLaM7DrJrCXf4nulpKoEpanyZ7btcRongqFGwEltxMO/ysZhcMympWqC6dmtsr+cbzT0cF98djVGxz4AJ3oeXqlIQjKmDmH2MkIBynPixEc1FXjaGt55uBlb7BNJwTgGCfMGAlILJDT+ZuBqhvLTtL5Oc3KA/b84P5ROSfryvQ4mOoQBUIFJKtfDOYgyOeo+4mtfx7PeQK3pHggImt8BdRYXWys17dDkxY1dmzOwsUss8ZGtA7mPoS9kS4hgrW+B/1+RRsVNj2GhI9oW75dui+Q3pYk8S1MVVv+6JcBCY5ImK9ufbTbwqPH4/2VpSnO5gc= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5652.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(83380400001)(8936002)(110136005)(66556008)(8676002)(316002)(55016002)(9686003)(7696005)(86362001)(2906002)(33656002)(5660300002)(71200400001)(66946007)(53546011)(26005)(166002)(508600001)(66446008)(52536014)(966005)(38070700005)(66476007)(6506007)(122000001)(64756008)(38100700002)(76116006)(4326008)(186003); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?pjOkmMs5jbjQilqpSsk39kW0RB4YHFDoProzGQAo9+YhRY/izCWPw33wNsvA?= =?us-ascii?Q?ys1rGo2c3dEUZdi6mHoQfI9NYnBYv6PGy8giBLHW2kmo/15M28aDHAc28v0g?= =?us-ascii?Q?SEsXHs2CI2rk8SxnDD8nGCVaE/qpt3LZL8VA+t0n6xbMIAoC/SF4S23i0fIq?= =?us-ascii?Q?WYZQYsTeb07GrkTKd3pOAWKZCvIg7oFSbWD1shBy//2zYj7e37gnv+KpCJeL?= =?us-ascii?Q?xOlUiIkie+vXLltln6ySJbeAVRXDTr1cu5k0WpbaQbP2o4Zp52ZFOtRRaRPB?= =?us-ascii?Q?oyC269dH30O1NI5Do7m07U8rXmEJ1I9A8lqT0bg5t8V5JU6D2x0h5WiOiU21?= =?us-ascii?Q?d3fh0S4qVjb97sJEvsQe/bU9NseiD+Qxzort5Bs4a7TNmZe5vT47bXWtWTli?= =?us-ascii?Q?PK3bvgkPfbJ6TXvdYclEklzrHn0Qt2KyeNdDMOxz87SXDCWPFK1sRjEeFmE1?= =?us-ascii?Q?x7ssQorFmaanczUOZvsBZYs5YVdy2e+WJIihHHmZuwBwT3tGDSCUkWmulb4V?= =?us-ascii?Q?HIsugmgWjyB+VhbbOUdnjLPcIwSfbZV1VbwaYSHWOVLa0/lCOuZH9IqLqlpa?= =?us-ascii?Q?KnvtcHVUxnP2CDqPMLeImRQL/HWDpeMj+NTij/6zY6OvykhHq+Ewm+0myMea?= =?us-ascii?Q?ofyQpAbS82tOudq7NTpsT8cEXBZKUk8r0lmXNCNZNlQDt+Xb15XfHJ/V+jPF?= =?us-ascii?Q?NwHWPvCFzFyeqWHAfUwNTMcF392Re1TjvcaEcBiEcsTWf/VwdKTFidYAJvSE?= =?us-ascii?Q?dFy4vavIhy5yn6xiyMirNAY3dRwYsN6v71u/5IGfUARsjsFXbPtjXchGHIn7?= =?us-ascii?Q?YF5KVdiyQAfcqGMJNDSjxad+/qWy1ty2cKVCtJFQBD6iD0BnPJfVzZzIrCtV?= =?us-ascii?Q?QTwVksrSd5jtuo0QonE7V/8vG5EhqiNbw5cAQ/u09LJLLWRoHkgUMWz1Thck?= =?us-ascii?Q?XdT16x2XktijgIlT7khoC/CwJX7FruncAwf9KSMiEi4TtgiF+lSOy9JNL0n8?= =?us-ascii?Q?4DQO65MOOylOo2FRQlr6iUWQfkMz6whjwAQnJlqVBppljxynljW7jVbAA/bA?= =?us-ascii?Q?7+663lsp3sbRzhOo5XK23FNgK8+ZigD2Y7QJH96tZ2FJpu8S+6lSl/7W5Afb?= =?us-ascii?Q?8zriuq491nK4Dwb5w1L2xSxk32i/laJ96i/w7zpzfbBEbGWkg+3iMpVqmzlV?= =?us-ascii?Q?s1FSBzsTrVu1K0BYxv7xjOMsQXsg4549kDTsD9EYcge4RBcGJmvSbc9ieyoM?= =?us-ascii?Q?SfynHHGAwYw4DAFKE4k0lVF2Agb7mXro0+4VuD3+jsiQA51saTxjMo2F0FXL?= =?us-ascii?Q?lXyou3KetR3/thJ1SdWQ1rEH?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BL0PR05MB5652F9253EAE77AD5ECB25CBD4B99BL0PR05MB5652namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5652.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dde570c5-1f86-4fa5-d670-08d98f74833b X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2021 00:41:22.8661 (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: fWuVv2t2iLfT9+hobrj8D0kbu80Q1/AHkfsL0KHmjFIF7okXFD/eZ2/K+3O+q8NXar/AMdXkR8Nk7XY6txKxmg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5410 X-Proofpoint-GUID: bfKj8ru-JiUTOz8QWiodMQV6xJPVB478 X-Proofpoint-ORIG-GUID: bfKj8ru-JiUTOz8QWiodMQV6xJPVB478 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-14_12,2021-10-14_02,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 clxscore=1011 bulkscore=0 phishscore=0 adultscore=0 impostorscore=0 suspectscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999 spamscore=0 priorityscore=1501 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110150001 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 15 Oct 2021 00:41:36 -0000 --_000_BL0PR05MB5652F9253EAE77AD5ECB25CBD4B99BL0PR05MB5652namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I oppose for the same reasons as well. From: spring On Behalf Of Tarek Saad Sent: Friday, October 8, 2021 12:05 AM To: James Guichard ; SPRING WG Cc: spring-chairs@ietf.org Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/ [External Email. Be cautious of content] Hi all, I've read this draft. It is proposing 2 different encodings schemes for com= pressed sequence of SRv6 SIDs (and an optional behavior on border nodes).. Although Section 4 makes a claim that different deployments usecase may dee= m one encoding scheme superior over the other, I could not glean in which c= ases a scheme would outperform the other and why? Or, why is the WG trying = to standardize both the two flavors -- keeping in mind the complex HW proce= dures evident by the proposed different pseudo codes in the draft. Also, are there concerns of misinterpreting (wrongfully decoding) a GSID se= quence for a C-SID-sequence (or vice-versa) for a received packet on border= nodes that may support both encoding flavors simultaneously? For these reasons, I think this it is still premature for this draft to be = adopted, and I oppose its adoption. Regards, Tarek From: spring > on b= ehalf of James Guichard > Date: Friday, October 1, 2021 at 10:05 AM To: SPRING WG > Cc: spring-chairs@ietf.org > Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses r= eceived to our emails with reference to how the working group wishes to mov= e forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis for its compression standardizat= ion work. That is part of what this email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ad= option ending October 15th for https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ but with some clear guidelines as follows. By expressing support for a= doption of this document you are fully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be address= ed BEFORE said document is allowed to progress from the working group to pu= blication. A list of these discussion points will be documented in the WG d= ocument and maintained by the document editor in conjunction with the chair= s. 4. If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open iss= ue be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data pl= ane solutions, the working group will address whether this is valid and coh= erent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/no= n-support as well as any open discussion points you would like addressed sh= ould the document be adopted into the working group. Thanks! Jim, Bruno & Joel Juniper Business Use Only --_000_BL0PR05MB5652F9253EAE77AD5ECB25CBD4B99BL0PR05MB5652namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    = I oppose for the same reasons as well.

    =  

    From: spring <spring-bounces@ietf.org> = On Behalf Of Tarek Saad
    Sent: Friday, October 8, 2021 12:05 AM
    To: James Guichard <james.n.guichard@futurewei.com>; SPRING WG= <spring@ietf.org>
    Cc: spring-chairs@ietf.org
    Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.= org/doc/draft-filsfilscheng-spring-srv6-srh-compression/

     

    <= span lang=3D"EN-CA" style=3D"font-size:10.5pt;font-family:"Lato",= sans-serif;color:black">[External Email. Be cautious of content]=

     

    Hi a= ll,

     

    I= 217;ve read this draft. It is proposing 2 different encodings schemes for c= ompressed sequence of SRv6 SIDs (and an optional behavior on border nodes).= .

    Alth= ough Section 4 makes a claim that different deployments usecase may deem on= e encoding scheme superior over the other, I could not glean in which cases= a scheme would outperform the other and why? Or, why is the WG trying to standardize both the two flavors -- keepi= ng in mind the complex HW procedures evident by the proposed different pseu= do codes in the draft.

     

    Also= , are there concerns of misinterpreting (wrongfully decoding) a GSID sequen= ce for a C-SID-sequence (or vice-versa) for a received packet on border nod= es that may support both encoding flavors simultaneously?

     

    For = these reasons, I think this it is still premature for this draft to be adop= ted, and I oppose its adoption.

     

    Rega= rds,

    Tare= k

     

     

    Dear WG:

     

    The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

     

    The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

     

    Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

     

    1. The SPRING working group is adopting a document that has multiple SRv= 6 Endpoint behaviors.
    2. The document is a “living” document; it m= ay change as it goes through review and analysis by the SPRING working grou= p.
    3. All open discussion points raised on our mailing list= MUST be addressed BEFORE said document is allowed to progress from the wor= king group to publication. A list of these discussion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
    4. If this document is adopted by the working group, the= chairs specify as part of the adoption call that the following text descri= bing an open issue be added to the document in the above-described open issues section:
      • "Given th= at the working group has said that it wants to standardize one data plane s= olution, and given that the document contains multiple SRv6 EndPoint behavi= ors that some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

     

    Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     


    Juniper Business Use Only

    --_000_BL0PR05MB5652F9253EAE77AD5ECB25CBD4B99BL0PR05MB5652namp_-- From nobody Thu Oct 14 18:02:48 2021 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 ED5923A1639; Thu, 14 Oct 2021 18:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ND19Frx7lqjs; Thu, 14 Oct 2021 18:02:41 -0700 (PDT) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (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 C55EE3A1604; Thu, 14 Oct 2021 18:02:40 -0700 (PDT) Received: by mail-lf1-x12e.google.com with SMTP id z11so33277527lfj.4; Thu, 14 Oct 2021 18:02:40 -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=CceYc6afKzbVh2KFX1/RgCiocQN/9xkCXaPD+xdh0ls=; b=J7/zsrANdh5KMC8QbPp2SmKn+pIsHkd/Nwddo4r/twf0e9nYOy+zJhYJf/CflKdnb5 B8cSag/DVS7bmHzWG9Q9rplrToDPHh3HyP69cMyZYqqF0mobBRa+SocMVY1sdwaot/eb W0E3k8NJwdrSAe9P6Si5zZzi2V7rE33kMAN6XnHv32g2qdrURrnF4fOQ1NYLv88Vz+Fl v3k6dxJAf3XTCp4vWVzjbH9o7zANNMVI1/NL/+K/s5Giq3tHeW0O3EUPErmnRO6yffRQ O/VDs5B4lCiMaBAa6b/SGBir/yBZPD1uiTP/6niD9GAuiGrBaCUUkMGlufdlR0Isk5/t fl4Q== 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=CceYc6afKzbVh2KFX1/RgCiocQN/9xkCXaPD+xdh0ls=; b=FS0dLL3zA4XYZynq7/MSs+evIyefO8K5U6MNsSs+cBK5Dh/VjZKl24eQ7MRugK1bLo d040F9dtyH9b/1446c+hGDD55YPSl9+2eLVSrgkoLfabJxa75fzeKA5Khe6tn506O5sE YFZYcsQTylIFQf47o7TgGB9NpWBf6Db/Ni6uw+CCcJQtX+TrjDZQd036lS8ZAIMJ/sRU CAXSLrAADkGnZvTFdCdqZL9RTbpes/n4rqcUweEXSn2/tuV2vgpVtr7RJ+Iv/KTW1QZN 9ilwxDnC946i1zl+x/hJvNdG2R8YvG8U++AuviH1j8DkDaQgIyssqyy42ymRchabzbdm h+Lw== X-Gm-Message-State: AOAM531FfZ6o+EIOIry388emitUkx67rFZMdtu4TePuRA7zfPvG+ntYN szx/+0C+IhiP24bCil624RqAecrluiYR3f75SkrCze3AA84= X-Google-Smtp-Source: ABdhPJxJDZF1pwfEAK+IK1R70RXIv27Mkwv38UBlZa8kLFOebcmD1ZNMV2HFXlPj41sglEhzuIat6XyGLYD/Vfkrczg= X-Received: by 2002:a2e:814c:: with SMTP id t12mr9238599ljg.387.1634259756978; Thu, 14 Oct 2021 18:02:36 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Kalyani Rajaraman Date: Thu, 14 Oct 2021 20:02:26 -0500 Message-ID: To: spring-chairs@ietf.org Cc: james.n.guichard@futurewei.com, spring@ietf.org Content-Type: multipart/alternative; boundary="00000000000049162605ce59c07b" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 15 Oct 2021 01:02:46 -0000 --00000000000049162605ce59c07b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear WG, I support the adoption of draft-filsfilscheng-spring-srv6-srh-compression. We, at Arrcus have implemented CSID solution on the following hardware Products: Arrcus Quanta (IXAE, IXA) Broadcom Jericho-2 based platforms. Arrcus Edgecore (AS7962) Jericho-2 based platforms. Thanks, Kalyani On Thu, Oct 14, 2021 at 3:49 AM Shay Zadok wrote: > Dear WG, > > We would like to update on the production support by the StrataDNX > products of both flavors REPLACE and NEXT as defined in CSID draft, as we= ll > as non-compressed "Classic" SRv6. > StrataDNX products include: > Jericho2/Jericho2c/Qumran2c/Qumran2a/Qumran2u/Qumran2n/Jericho2c+ and any > future device > > This support keeps: > 1. Single and unified data-plane uCode, programmed using high level > language > 2. Single data-plane API > 3. Concurrent/Simultaneous support of all three techniques based on a > per-packet behavior > 4. Concurrent/Simultaneous support of all three techniques inside of the > same SRv6 Header > 5. In all three techniques the following is already supported concurrentl= y/simultaneously > and in production > 1. SRv6 main behaviors - compliant with *rfc8986* > 2. SRv6 insert behaviors - compliant with > *draft-srv6-net-pgm-insertion* > 3. SRv6 midpoint protection behaviors - compliant with > *draft-midpoint-protection* > > All of the above is in production deployment in various published and > unpublished networks around the globe. > Our products are used by industry leading OEM (some of them published the= y > are using the StrataDNX products) and "pure" NOS vendors. > > BRCM using Jericho2 participated in couple of interops that included some > mix of REPLACE-CSID, NEXT-CSID and non-compressed "Classic" SRv6 - and al= l > interops have ended successfully > > Thanks & Regards, > Shay > > > > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* spring [mailto:spring-bounces@ietf.org] *= =E4=BB=A3=E8=A1=A8 *James Guichard > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2021=E5=B9=B410=E6=9C=881=E6=97= =A5 22:05 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* SPRING WG > *=E6=8A=84=E9=80=81:* spring-chairs@ietf.org > *=E4=B8=BB=E9=A2=98:* [spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > > > Dear WG: > > > > The chairs would like to express their appreciation for all the responses > received to our emails with reference to how the working group wishes to > move forward with respect to a solution for SRv6 compression. > > > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ as > the basis for its compression standardization work. That is part of what > this email attempts to confirm. > > > > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ but > with some clear guidelines as follows. By expressing support for adoption > of this document you are fully aware of and are acknowledging that: > > > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change = as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the working > group to publication. A list of these discussion points will be docume= nted > in the WG document and maintained by the document editor in conjunctio= n > with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text describin= g an > open issue be added to the document in the above-described open issues > section: > > > - "Given that the working group has said that it wants to standardize > one data plane solution, and given that the document contains multi= ple SRv6 > EndPoint behaviors that some WG members have stated are multiple da= ta plane > solutions, the working group will address whether this is valid and > coherent with its one data plane solution objective.". > > > > Please consider the above guidelines as you decide on whether to support > or not this WG adoption. Please express clearly your reasoning for > support/non-support as well as any open discussion points you would like > addressed should the document be adopted into the working group. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > > > > This electronic communication and the information and any files > transmitted with it, or attached to it, are confidential and are intended > solely for the use of the individual or entity to whom it is addressed an= d > may contain information that is confidential, legally privileged, protect= ed > by privacy laws, or otherwise restricted from disclosure to anyone else. = If > you are not the intended recipient or the person responsible for deliveri= ng > the e-mail to the intended recipient, you are hereby notified that any us= e, > copying, distributing, dissemination, forwarding, printing, or copying of > this e-mail is strictly prohibited. If you received this e-mail in error, > please return the e-mail to the sender, delete it from your computer, and > destroy any printed copy of it. > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --00000000000049162605ce59c07b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Dear WG,

    I support the adoption of=C2=A0draft-filsfilscheng-spring-srv6-srh-compression.=C2=A0

    We, at Arrcus have implemented CSID solution on the f= ollowing hardware Products:

    =C2=A0 =C2=A0 =C2= =A0 Arrcus Quanta (IXAE, IXA) Broadcom Jericho-2 based platforms.
    =C2=A0 =C2=A0 =C2=A0 Arrcus Edgeco= re (AS7962) Jericho-2 based platforms.

    Thanks= ,
    Kalyani
    =C2=A0 =C2=A0 =C2=A0

    On Thu, Oct 14, 2021 at 3:49 A= M Shay Zadok <shay.zadok=3D40broadcom.com@dmarc.ietf.org> wrote:
    Dear WG,

    We = would like to update on the production support by the StrataDNX products=C2= =A0of both flavors REPLACE and NEXT as defined in CSID draft, as well as no= n-compressed "Classic" SRv6.=C2=A0
    StrataDNX=C2=A0produ= cts include: Jericho2/Jericho2c/Qumran2c/Qumran2a/Qumran2u/Qumran2n/Jericho= 2c+ and any future device

    This support keeps:
    1. Single an= d unified data-plane uCode, programmed using high level language
    2. Sing= le data-plane API
    3. Concurrent/Simultaneous support of all three techni= ques based on a per-packet behavior
    4. Concurrent/Simultaneous support o= f all three techniques inside of the same SRv6 Header
    5. In all t= hree techniques the following is already supported= =C2=A0concurrently/simultaneously and in production
    =C2=A0= =C2=A0 1. SRv6 main behaviors - compliant with rfc8986
    =C2=A0 = =C2=A0 2. SRv6 insert behaviors - compliant with draft-srv6-net-pgm-inse= rtion
    =C2=A0 =C2=A0 3. SRv6 midpoint protection behaviors - complian= t with draft-midpoint-protection

    All of the above is in produ= ction deployment in various published and unpublished networks around the g= lobe.
    Our products are used by industry leading OEM (some of them publis= hed they are using the StrataDNX products) and "pure" NOS vendors= .

    BRCM using Jericho2 participated in couple of interops that includ= ed some mix of REPLACE-CSID, NEXT-CSID and non-compressed "Classic&quo= t; SRv6 - and all interops have ended successfully

    Thanks & Regards,
    Shay


    =C2=A0

    =C2=A0=

    =C2=A0

    Dear WG:

    =C2=A0

    The chairs would like to express their appreciatio= n for all the responses received to our emails with reference to how the wo= rking group wishes to move forward with respect to a solution for SRv6 comp= ression.

    =C2=A0

    The apparent inclination of the working group is to use=C2=A0https://datatracker.ietf.org/doc/draft-filsfilsche= ng-spring-srv6-srh-compression/=C2=A0as the basis for its compression s= tandardization work. That is part of what this email attempts to confirm.

    =C2=A0

    Because = of the above the chairs would like to issue a 2-week WG call for adoption e= nding October 15th=C2=A0for=C2=A0https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-= compression/=C2=A0but with some clear guidelines as follows. By express= ing support for adoption of this document you are fully aware of and are ac= knowledging that:

    =C2=A0

    1. The SPRING working group is adopting= a document that has multiple SRv6 Endpoint behaviors.=
    2. The document is a=C2=A0=E2=80=9Cliving=E2=80=9D=C2=A0document; it may change as it goes through review and analysis by = the SPRING working group.
    3. = All open discussion points raised on our mailing list = MUST be addressed BEFORE said document is allowed to progress from the work= ing group to publication. A list of these discussion points will be documen= ted in the WG document and maintained by the document editor in conjunction= with the chairs.
    4. If this document is adopted by the working group, the chairs s= pecify as part of the adoption call that the following text describing an o= pen issue be added to the document in the above-described open issues secti= on:
      • "Given that the worki= ng group has said that it wants to standardize one data plane solution, and= given that the document contains multiple SRv6 EndPoint behaviors that som= e WG members have stated are multiple data plane solutions, the working gro= up will address whether this is valid and coherent with its one data plane = solution objective.".

    =C2=A0

    Please consider the above guidelines as you = decide on whether to support or not this WG adoption. Please express clearl= y your reasoning for support/non-support as well as any open discussion poi= nts you would like addressed should the document be adopted into the workin= g group.

    =C2=A0

    Thanks!

    =C2=A0

    Jim, Bruno & Joel

    =C2=A0

    =C2=A0

    <= /div>


    --00000000000049162605ce59c07b-- From nobody Thu Oct 14 23:18:02 2021 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 C32433A1875; Thu, 14 Oct 2021 23:17:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 zVfDEn9SHmwY; Thu, 14 Oct 2021 23:17:04 -0700 (PDT) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.36]) (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 EEB153A13DA; Thu, 14 Oct 2021 23:17:03 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) (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 opfednr22.francetelecom.fr (ESMTP service) with ESMTPS id 4HVwz21B4Jz10Yq; Fri, 15 Oct 2021 08:17:02 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1634278622; bh=B1xlIqCiNSxdLHccSaU8YbmCyAt+3AUOt4pZZ0LoKZY=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=Sxj82nns95IcqnH+y9pWWqxFnH5W4zHByKAEVMaf1el6Ig7uxfJTmKMrttwb6ICq9 ukfo0GXJtAGPH4qp39S6fJ0R3bJGuc4J/Gpy4mc3ayqoBt69VxL6HMY1CNsb45PB16 Egzgls6ZzBd7kh+AmJ0aa1fVBIVld/UmWLve3BSaeEUogBROADPKjEAKiV0clVP5rT uipNPeWpu0ipLdqoIRydwGJgI7LjaSPugZBdZfHBSh4/3q1jVskBvr1cGq7+pC4Yfh 3qcCUiiQtkWeUfysj7J+Lxt8DjDOCT1LxbeXMfg3MqO/lt55kkMWc3RQjJYkBcPWkl gJxeSulYcjhRQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfednr00.francetelecom.fr (ESMTP service) with ESMTPS id 4HVwz20HzwzDq7p; Fri, 15 Oct 2021 08:17:02 +0200 (CEST) From: To: "Joel M. Halpern" , "ipv6@ietf.org" CC: "spring@ietf.org" Thread-Topic: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression Thread-Index: AQHXwAWG2aV0+xABZUqfytom/0kT0KvTla4A Content-Class: Date: Fri, 15 Oct 2021 06:17:00 +0000 Message-ID: <1396_1634278622_61691CDE_1396_28_5_787AE7BB302AE849A7480A190F8B93303542C654@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> In-Reply-To: <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2021-10-15T06:12:09Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=f980fb0f-5149-47f7-b90b-583cfa61a5b4; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0 x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 15 Oct 2021 06:17:09 -0000 SGkgSm9lbCAsIGFsbCwgDQoNCkMtU0lEIGlzIG5vIG1vcmUgdGhhbiBhbm90aGVyIG1lY2hhbmlz bSB0aGF0IHJlbGllcyBvbiBzb21lIGFsZ29yaXRobWljIG1hcHBpbmcgZW1iZWRkZWQgaW4gdGhl IElQdjYgYWRkcmVzcy4gV2UgZG8gaGF2ZSBhbHJlYWR5IG1hbnkgb2Ygc3VjaCBhbGdvcml0aG1p YyBhcHByb2FjaGVzOiBSRkM2MDUyLCBSRkM3NTk3LCBldGMuIA0KDQpUaGUgaW50ZXJuYWwgc3Ry dWN0dXJlIHdvdWxkIGJlIHByb2JsZW1hdGljIGlmIGl0IHJlcXVpcmVzIHRoYXQgZXZlcnkgaW50 ZXJtZWRpYXRlIG5vZGUgb24gdGhlIHBhdGggaGFzIHRvIHBhcnNlIGl0LCBidXQgdGhpcyBpcyBu b3QgdGhlIGNhc2UuIFRoZSBwYWNrZXQgaXMgZm9yd2FyZGVkIGJhc2VkIG9uIHRoZSBEQSBmb2xs b3dpbmcgY29udmVudGlvbmFsIHByb2NlZHVyZXMuIFRoZSBwcm9jZWR1cmUgdG8gZGV0ZXJtaW5l IHRoZSBuZXh0IFNSIGhvcCBpcyBpbnRlcm5hbCB0byBhbiBTUi1jYXBhYmxlIG5vZGUuDQoNCkhh dmluZyBleGFtcGxlcyBvZiBzdWNoIFNJRHMgaW4gdGhlIGRyYWZ0IHdvdWxkIGhlbHAgdG8gYmV0 dGVyIHVuZGVyc3RhbmQgdGhlIGNvbXByZXNzaW9uIHByb2NlZHVyZSwgYnV0IG5vIG1vcmUgdGhh biB0aGF0IGFzIHRoZXNlIHdpbGwgYmUgZGlzcGxheWVkIGFzIElQdjYgYWRkcmVzc2VzISANCg0K Q2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERlwqA6IGlw djYgPGlwdjYtYm91bmNlc0BpZXRmLm9yZz4gRGUgbGEgcGFydCBkZSBKb2VsIE0uIEhhbHBlcm4N Cj4gRW52b3nDqcKgOiBtZXJjcmVkaSAxMyBvY3RvYnJlIDIwMjEgMDk6MzcNCj4gw4DCoDogaXB2 NkBpZXRmLm9yZw0KPiBDY8KgOiBzcHJpbmdAaWV0Zi5vcmcNCj4gT2JqZXTCoDogVHlwbyBjb3Jy ZWN0aW9uIFJlOiBRdWVzdGlvbiBmcm9tIFNQUklORyByZWdhcmRpbmcgZHJhZnQtDQo+IGZpbHNm aWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uDQo+IA0KPiBUaGVyZSBpcyBhIHR5 cG8gaW4gdGhlIGJlbG93IHdoaWNoIGlmIG5vdCB1bmRlcnN0b29kIGFzIGEgdHlwbyB3b3VsZCBi ZQ0KPiBxdWl0ZSBjb25mdXNpbmcuICAgSSB3cm90ZSB0aGF0IEkgcmFpc2VkIHRoZSBpc3N1ZSB3 aXRoDQo+ICJ3aXRoIHRoZSBJbnRlcm5ldCBBRHMgYW5kIFNQUklORyBjaGFpcnMiLg0KPiBUaGF0 IHNob3VsZCBoYXZlIHJlYWQgIndpdGggdGhlIEludGVybmV0IEFEcyBhbmQgNm1hbiBjaGFpcnMi Lg0KPiBUaGUgU1BSSU5HIGNvLWNoYWlycyBhcmUgcmVjdXNlZCwgYW5kIHRoZSBjaGFydGVyIHJl cXVpcmVtZW50IGxlYWRzIHRvIHRoZQ0KPiA2bWFuIGNoYWlycy4gIFdoaWNoIGlzIHdobyBJIHRh bGtlZCB0by4NCj4gDQo+IEFsc28sIEkgYW0gc2VuZGluZyBhIGNvdXJ0ZXN5IGNvcHkgdG8gdGhl IHJvdXRpbmcgQURzLCB3aGljaCBJIHNob3VsZCBoYXZlDQo+IGRvbmUgb3JpZ2luYWxseS4NCj4g DQo+IFRoYW5rIHlvdSBhbmQgZW5qb3kuDQo+IFlvdXJzLA0KPiBKb2VsDQo+IA0KPiBPbiAxMC8x Mi8yMDIxIDExOjUyIFBNLCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+ID4gVGhlIFNQUklORyB3 b3JraW5nIGdyb3VwIGlzIGluIHRoZSBtaWRzdCBvZiBhbiBhZG9wdGlvbiBjYWxsIG9uDQo+ID4g aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJp bmctc3J2Ni1zcmgtDQo+IGNvbXByZXNzaW9uLy4NCj4gPg0KPiA+DQo+ID4gVGhlIFNQUklORyBj aGFydGVyIGhhcyB0ZXh0IHRoYXQgaXMgZXhwbGljaXQgdGhhdCBtb2RpZmljYXRpb25zIHRvDQo+ ID4gZGF0YSBwbGFuZXMgYW5kIGFyY2hpdGVjdHVyZXMgc3RhbmRhcmRpemVkIGJ5IG90aGVyIHdv cmtpbmcgZ3JvdXBzIG1heQ0KPiA+IG5vdCBiZSBtb2RpZmllZCBpbiBTUFJJTkcgdW5sZXNzIHRo ZSBjaGFpcnMgYW5kIEFEcyByZXNwb25zaWJsZSBmb3INCj4gPiB0aGF0IGRhdGEgcGxhbmUgYW5k IC8gb3IgYXJjaGl0ZWN0dXJlIGFncmVlLg0KPiA+DQo+ID4gVG8gY29tcGxldGUgdGhlIGNvbnRl eHQsIGFzIG15IFNQUklORyBjby1jaGFpcnMgYXJlIGNvLWF1dGhvcnMgb24gdGhlDQo+ID4gZG9j dW1lbnQgaW4gcXVlc3Rpb24sIHRoZXkgaGF2ZSByZWN1c2VkIHRoZW1zZWx2ZXMgZnJvbSBkZWNp c2lvbmFsDQo+ID4gYWN0aXZpdGllcyByZWdhcmRpbmcgdGhlIGRvY3VtZW50LsKgIFRoZXJlZm9y ZSwgdGhpcyBtZXNzYWdlIGlzIGNvbWluZw0KPiA+IGp1c3QgZnJvbSBteSBhcyB0aGUgcmVzcG9u c2libGUgU1BSSU5HIGNvLWNoYWlyIG1hbmFnaW5nIHRoaXMgYWRvcHRpb24NCj4gPiBjYWxsLg0K PiA+DQo+ID4gQXMgeW91IGhhdmUgc2VlbiwgbXVsdGlwbGUgcXVlc3Rpb25zIGhhdmUgYmVlbiBy YWlzZWQgYWJvdXQgdGhlDQo+ID4gcmVsYXRpb25zaGlwIG9mIHRoZSBkb2N1bWVudCB0byB0aGUg SVB2NiBkZWZpbmVkIGRhdGEgcGxhbmUgYW5kDQo+ID4gYXJjaGl0ZWN0dXJlIChwYXJ0aWN1bGFy bHkgUkZDIDQyOTEgYW5kIDgyMDApLiBJbiBwYXJ0aWN1bGFyIHRoZQ0KPiA+IHF1ZXN0aW9ucyBz ZWVtIHRvIHJldm9sdmUgYXJvdW5kIHdoYXQgdGhlIGRvY3VtZW50IGRlc2NyaWJlcyBhcyB0aGUN Cj4gPiBORVhULUMtU0lEIGZsYXZvciBvZiBjb21wcmVzc2VkIFNJRCwgYW5kIGl0cyByZWxhdGlv bnNoaXAgdG8gdGhlIElQdjYNCj4gPiBzdGFuZGFyZHMuwqAgKEZvciB0aG9zZSBzZWVraW5nIG1v cmUgY29udGV4dCB3aXRob3V0IHJlYWRpbmcgdGhlIGZ1bGwNCj4gPiBkb2N1bWVudCwgYSBwYXJh cGhyYXNlIGFuZCBzaW1wbGlmaWNhdGlvbiBvZiB0aGUgTkVYVC1DX1NJRCBmbGF2b3IgaXMNCj4g PiBwcm92aWRlZCBhcyBhIHBvc3RzY3JpcHQuKQ0KPiA+DQo+ID4gSSByYWlzZWQgdGhlIHF1ZXN0 aW9uIG9mIGNvbmN1cnJlbmNlIGFzIHJlcXVpcmVkIGJ5IHRoZSBTUFJJTkcgY2hhcnRlcg0KPiA+ IHdpdGggdGhlIEludGVybmV0IEFEcyBhbmQgU1BSSU5HIGNoYWlycy7CoCBUaGV5IHF1aXRlIHJl YXNvbmFibHkgYXNrZWQNCj4gPiBtZSB0byB3cml0ZSBhIG5vdGUgdG8gNm1hbiBleHBsYWluaW5n IHRoZSBjb25jZXJucyBhcyBjbGVhcmx5IGFzIGENCj4gPiBjYW4sIHNvIHRoYXQgdGhleSBjYW4g dGhlbiBkZXRlcm1pbmUgaG93IHRvIHByb2NlZWQuDQo+ID4NCj4gPiBUaGUgcXVlc3Rpb25zIHRo YXQgcHJvbXB0ZWQgbXkgaW5xdWlyeSBhcmU6DQo+ID4NCj4gPiAxKSBEb2VzIHRoZSBwbGFjZW1l bnQgb2YgYSBsaXN0IG9mIHNpZHMgaW4gdGhlIElQdjYgREEgZmllbGQgY2hhbmdlDQo+ID4gdGhl DQo+ID4gSVB2NiBhcmNoaXRlY3R1cmFsIGRlc2NyaXB0aW9uIG9mIHRoYXQgZmllbGQuDQo+ID4g MikgRG9lcyB0aGUgb3BlcmF0aW9uIG9mIHNoaWZ0aW5nIGluZm9ybWF0aW9uIGFyb3VuZCBpbiB0 aGUgSVB2Ng0KPiA+IGRlc3RpbmF0aW9uIGFkZHJlc3MgZmllbGQgcmVwcmVzZW50IGEgbW9kaWZp Y2F0aW9uIG9yIGV4dGVuc2lvbiBvZiB0aGUNCj4gPiBJUHY2IGRhdGEgcGxhbmUuDQo+ID4NCj4g PiBPbiBhIHJlbGF0ZWQgbm90ZSwgdGhlIGRvY3VtZW50IGluIHF1ZXN0aW9uIGFsc28gZGVmaW5l cyB0d28gb3RoZXINCj4gPiBmbGF2b3JzLCBSRVBMQUNFLUMtU0lELCBhbmQgTkVYVC1hbmQtUkVQ TEFDRS1DLVNJRC7CoCBUaGUNCj4gPiBORVhULWFuZC1SRVBMQUNFLUNfU0lEIGZsYXZvciBpcyBk ZWZpbmVkIHRvIGluY2x1ZGUgdGhlIE5FWFQtQ19TSUQNCj4gPiBmbGF2b3Igb3BlcmF0aW9uLCBz byBzZWVtcyB0byBiZSBhZmZlY3RlZCBieSB0aGUgc2FtZSBxdWVzdGlvbi4NCj4gPg0KPiA+ICBG cm9tIG15IG93biByZWFkaW5nLCBpdCBhcHBlYXJzIHRoYXQgdGhlIFJFUExBQ0UtQy1TSUQgZmxh dm9yIGRvZXMNCj4gPiBub3QgcmFpc2UgaXNzdWVzIHJlcXVpcmluZyA2bWFuIGxlYWRlcnNoaXAg Y29uY3VycmVuY2UuDQo+ID4NCj4gPiBZb3VycywNCj4gPiBKb2VsIE0uIEhhbHBlcm4gZm9yIHRo ZSBTUFJJTkcgd29ya2luZyBncm91cA0KPiA+DQo+ID4NCj4gPiBQUzoNCj4gPiBDbGVhcmx5LCB1 bmRlcnN0YW5kaW5nIHRoZSBxdWVzdGlvbiByZXF1aXJlcyBzb21lIHVuZGVyc3RhbmRpbmcgb2YN Cj4gPiB3aGF0IHRoZSBORVhULUNfU0lEIGZsYXZvciBkb2VzLsKgwqAgVGhpcyBleHBsYW5hdGlv biBpcyBhDQo+ID4gc2ltcGxpZmljYXRpb24gZm9yIGxlbmd0aCBhbmQgY29udGV4dC7CoCBSZWFs bHksIHRoZSBiZXN0IHBsYWNlIHRvDQo+ID4gdW5kZXJzdGFuZCBpdCBpcyB0aGUgZHJhZnQuwqAg SG93ZXZlciwgdG8gZ2l2ZSB5b3UgZW5vdWdoIGluZm9ybWF0aW9uDQo+ID4gdG8gbGV0IHlvdSBk ZWNpZGUgd2hldGhlciB5b3UgY2FyZSwgSSB3aWxsIHRyeSB0byBwcm92aWRlIGEgZmFpcg0KPiA+ IHN1bW1hcnkuwqAgTXkgYXBvbG9naWVzIGluIGFkdmFuY2UgdG8gdGhlIGF1dGhvcnMgZm9yIG5l Y2Vzc2FyeQ0KPiA+IGxpYmVydGllcyBmb3IgbGVuZ3RoLsKgIEFsc28sIGRpc2N1c3Npb24gb2Yg dGhlIGRyYWZ0IGNvbnRlbnRzIChhcw0KPiA+IGRpc3RpbmN0IGZyb20gdGhlIGludGVyYWN0aW9u IHdpdGggdGhlIElQdjYgZGF0YSBwbGFuZSBhbmQNCj4gPiBhcmNoaXRlY3R1cmUpIGJlbG9uZ3Mg b24gdGhlIFNQUklORyBsaXN0LCBhbmQgc2hvdWxkIG5vdCBjbHV0dGVyIHVwDQo+IDZtYW4uDQo+ ID4NCj4gPiBTSURzIGFyZSB0aGUgaWRlbnRpZmllcnMgdXNlZCBpbiBzZWdtZW50IHJvdXRpbmcu DQo+ID4gSW4gU1J2NiwgYXMgZG9jdW1lbnQgaW4gdGhlIGN1cnJlbnQgUkZDcywgdGhlc2UgYXJl IDEyOCBiaXRzLsKgwqAgQXMNCj4gPiBkZWZpbmVkIGluIHRoZSByZWxldmFudCBSRkNzLCBTSURz IHdoaWNoIGlkZW50aWZ5IGVuZHBvaW50cyB0byB3aGljaA0KPiA+IHBhY2tldHMgYXJlIGRpcmVj dGVkIGFyZSBpZGVudGlmaWVkIGJ5IGVuZHBvaW50IFNJRHMuwqAgVGhlc2UgY2FuIGhhdmUNCj4g PiBiZWhhdmlvcnMgKGRlY2Fwc3VsYXRlIGFuZCBmb3J3YXJkIGlzIG9uZSBleGFtcGxlKS7CoCBU aGV5IGNhbiBoYXZlDQo+ID4gZmxhdm9ycyBzdWNoIGFzIHdoZXJlIHRoZSBTUkggaXMgcmVtb3Zl ZC4NCj4gPg0KPiA+IFRoZSB0b3BpYyB1bmRlciBkaXNjdXNzaW9uIGlzIG1lYW5zIHRvIGNvbXBy ZXNzIHRoZXNlIFNJRHMgaW4gdGhlDQo+ID4gcGFja2V0cyBvbiB0aGUgd2lyZS7CoCBUaGUgZG9j dW1lbnQgdW5kZXIgZGlzY3Vzc2lvbiBwcm92aWRlcyB0aHJlZQ0KPiA+IGZsYXZvcnMgb2YgY29t cHJlc3Npb24uDQo+ID4NCj4gPiBUaGUgZnVuZGFtZW50YWwgbWVjaGFuaXNtIG9mIHRoZSBkcmFm dCBpcyB0byB1c2UgYSBzaW5nbGUgU1JIIGVudHJ5IGFzDQo+ID4gYSBjb250YWluZXIgZm9yIG11 bHRpcGxlIFNJRHMuwqAgSW4gdGhlIE5FWFQtQ19TSUQgbWVjaGFuaXNtLCB3aGVuIGl0DQo+ID4g aXMgZmlyc3QgZW5jb3VudGVyZWQgdGhlIGVudGlyZSBjb250YWluZXIgaXMgY29waWVkIGludG8g dGhlDQo+ID4gZGVzaW5hdGlvbiBhZGRyZXNzIG9mIHRoZSBJUHY2IHBhY2tldC7CoCBUaGUgY29u dGFpbmVyIGhhcyBhIGNvbW1vbg0KPiA+IHJvdXRpbmcgcHJlZml4IHVzZWQgZm9yIGFsbCB0aGUg TkVYVC1DLVNJRCBTSURzLsKgIEl0IGlzIGZvbGxvd2VkIGJ5IGENCj4gPiBzZXF1ZW5jZSBvZiBj b21wcmVzc2VkIFNJRHMgb2YgYSBjb25maWd1cmVkIGxlbmd0aC7CoCBPbmUgY291bGQNCj4gPiBj b25maWd1cmUgMTYsIDI0LCBvcg0KPiA+IDMyIGJpdHMuwqAgT3Igd2hhdGV2ZXIgbGVuZ3RoLsKg IFRoZSByb3V0aW5nIGFkdmVydGlzZW1lbnRzIGFyZSBhcnJhbmdlZA0KPiA+IHNvIHRoYXQgdGhl IElQdjYgcGFja2V0IGlzIGRpcmVjdGVkIHRvIHRoZSBub2RlIHJlcHJlc2VudGVkIGJ5IHRoZQ0K PiA+IGZpcnN0IGNvbXByZXNzZWQgU0lEIG9uIHRoZSBiYXNpcyBvZiBsb25nZXN0IHByZWZpeCBt YXRjaCBtYXRjaGluZyB0aGUNCj4gPiBjb21iaW5hdGlvbiBvZiB0aGUgY29tbW9uIHJvdXRpbmcg cHJlZml4IGFuZCB0aGF0IGNvbXByZXNzZWQgU0lELg0KPiA+DQo+ID4gV2hlbiB0aGUgcGFja2V0 IGFycml2ZXMgYXQgdGhhdCBub2RlLCBpdCBsb29rcyB1cCB0aGUgY29uZmlndXJlZA0KPiA+IHBv cnRpb24sIHRoZSBjb21wcmVzc2VkIFNJRCwgYW5kIGRldGVybWluZXMgdGhlIGJlaGF2aW9yIGFu ZCBmbGF2b3IuDQo+ID4gSW4gdGhlIGNhc2Ugb2YgdGhlIE5FWFQtQy1TSUQgZmxhdm9yLCB0aGUg cmVzdWx0aW5nIG9wZXJhdGlvbiBpcyB0bw0KPiA+IHNoaWZ0IHRoZSBlbnRpcmUgcmVtYWluaW5n IGNvbnRlbnRzIG9mIHRoZSBJUHY2IGFkZHJlc3MgKHRoZSBiaXRzIHBhc3QNCj4gPiB0aGUgZmly c3QgY29tcHJlc3NlZCBzaWQpIHNvIGFzIHRvIG92ZXItd3JpdGUgdGhlIGZpcnN0IGNvbXByZXNz ZWQNCj4gPiBTSUQuwqAgMCBiaXRzIGFyZSBzaGlmdGVkIGludG8gdGhlIGxvdyBvcmRlciBwb3Np dGlvbnMuwqAgSWYgdGhlIHJlc3VsdA0KPiA+IGlzIGEgbm9uLXplcm8gbmV3IGZpcnN0IGNvbXBy ZXNzZWQgU0lELCB0aGVuIHRoZSBwYWNrZXRzIGlzIGZvcndhcmRlZA0KPiA+IGFuZCB0aGUgcHJv Y2VzcyByZXBlYXRzLsKgIFdoZW4gYWxsIHRoYXQgaXMgbGVmdCBhcmUgMHMsIGlmIHRoZXJlIGlz IGFuDQo+ID4gU1JILCBpdCBpcyBjb25zdWx0ZWQgdG8gZmluZCB0aGUgbmV4dCBTUkggZW50cnks IHdoaWNoIGlzLCBwZXIgbm9ybWFsDQo+ID4gU1J2NiBwcm9jZXNzaW5nLCBwdXQgaW50byB0aGUg SVB2NiBEQS4NCj4gPiBOb3RlIHRoYXQgaW4gdGhlIGNvbW1vbiBjYXNlIHdoZXJlIHRoZSBTSURT IG5lZWRlZCBhbGwgZml0IGluIHRvIGENCj4gPiBzaW5nbGUgY29udGFpbmVyLCB0aGUgYW5hbHlz aXMgYWxzbyBhc3N1bWVzIHRoZSB1c2Ugb2YgdGhlIHJlZHVjZWQNCj4gPiBlbmNhcHN1bGF0aW9u IG9wdGlvbnMgd2hpY2ggb21pdHMgdGhlIFNSSCB0aGF0IGlzIG5vdCBuZWVkZWQgYXMgaXQNCj4g PiB3b3VsZCBoYXZlIG5vIGVudHJpZXMuwqAgVGhpcyB0aGUgcGFja2V0IGNvbnRhaW5zIGEgbm9y bWFsIElQdjYgaGVhZGVyLA0KPiA+IHdpdGggYSBzZXF1ZW5jZSBvZiBjb21wcmVzc2VkIFNJRHMg KHdoYXQgb25lIG1pZ2h0IG9yIG1pZ2h0IG5vdCBjYWxsIGENCj4gPiBzb3VyY2UNCj4gPiByb3V0 ZSkgaW4gdGhlIElQdjYgZGVzdGluYXRpb24gYWRkcmVzcyBmaWVsZC4NCj4gPg0KPiA+IFBQUzog SWYgdGhlIGF1dGhvcnMgb2YgdGhlIE5FWFQtQy1TSUQgZmxhdm9yIGZlZWwgSSBoYXZlDQo+ID4g bWlzLXJlcHJlc2VudGVkIHRoZSB3b3JrLCBwbGVhc2UsIHNlbmQgY2xhcmlmaWNhdGlvbnMgb3Ig Y29ycmVjdGlvbnMuDQo+ID4gQWdhaW4sIHRoZSBiZXN0IHNvdXJjZSBvZiBpbmZvcm1hdGlvbiBp cyB0aGUgZHJhZnQgaXRzZWxmLsKgIEkgd2FzDQo+ID4gYXNrZWQgdG8gcHJvdmlkZSBleHRyYSBj b250ZXh0IGluIHRoaXMgZW1haWwuDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJRVRGIElQdjYgd29y a2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRmLm9yZw0KPiBBZG1pbmlzdHJhdGl2 ZSBSZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMg b3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdl IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRl dHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJv bmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRv dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91 IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJl IHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBv ciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBP cmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQs IGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From nobody Fri Oct 15 00:15:18 2021 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 72ED73A0DC7; Fri, 15 Oct 2021 00:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 AWcRuBW8Vw9K; Fri, 15 Oct 2021 00:13:18 -0700 (PDT) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 EF3D73A19D3; Fri, 15 Oct 2021 00:12:43 -0700 (PDT) Received: by mail-il1-x134.google.com with SMTP id s3so6241777ild.0; Fri, 15 Oct 2021 00:12:43 -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=0pZ8U+osTwmJUtg+t8i69P4p75ch2fUEq4i9A20wP4Y=; b=AwIh1s6QdBRfmWphossOnrPRwxWECGOJQfbUYlqzUcu6wKf/VKFbxpOSO7ERHQDsES Zeg47RBFzEEfOTwJTR/kAV+4lf2g76lA4WA5rN2h3cn4NjaR6OWsL9zuWon3qWEbXfEe 0ZRGtIGzegkHnSm31k9HhNvxD+h+0XkT+ig6aVRzCP8Yku4eDRESbVR63aDIE6+nwxg8 Y39bCVFrYEnjut6pQZRTwXZD2QDs1p/38UaoCYC61ZOGZjmiWI4GxE2IQTfo5BSTM2g2 xtkpY6K8kApmHicLjH6KQc9QUyqoV1C3fc/PcHykoW67pyxmlDtYrLoPmrEEIzY4uORM AuDA== 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=0pZ8U+osTwmJUtg+t8i69P4p75ch2fUEq4i9A20wP4Y=; b=43+0XEJ5L8g1i6p3w7SF268OqWWsHpH+QPTFwReaO0+hl2SgbW/GurvbeDTf9aEAf4 TLHKMWzhGlFmCcc8W/bFqf3wBDSESflgXtILgm9WQsDa/wtLKrdbjLY1T6WQ8oHNaqT0 H2FK6135M9rMRDQtY0GSa7EHaUgUzSbWcCwx4Mhc693qKJ3kT+Gk9PUv/YHNbA6wBS7n /4qQUiVeH6ookpstR3A4TfvQ0ulKWr0sO+uuiMZFb/3D+hyuP3qtw5WAx0mUH98baO6h FdDsBYEjJ1IRD43112OfTjvsSxx5JX7QzIbEwa1A6lOHFTrW4yzuNKcoCDLZP1UHE1aW DC1A== X-Gm-Message-State: AOAM531SfDdi5KY9OfLy1R2nzxcGhgq0FS7W/kJ7PInx/Yb0MKBBXOyI aNL35RzmIFYW9qEuZIis+xNFKXT/XSxfnevI0vc= X-Google-Smtp-Source: ABdhPJw5z2ctRJP73Q0Orkhj9+/OEQtagXhohiNJ7O2/12SjmZ6ObVM1ii263dLwLFQ/Up9TJSeb/WwKzDXCwz6v1i8= X-Received: by 2002:a05:6e02:1025:: with SMTP id o5mr2826736ilj.133.1634281961525; Fri, 15 Oct 2021 00:12:41 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <1396_1634278622_61691CDE_1396_28_5_787AE7BB302AE849A7480A190F8B93303542C654@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <1396_1634278622_61691CDE_1396_28_5_787AE7BB302AE849A7480A190F8B93303542C654@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Mark Smith Date: Fri, 15 Oct 2021 18:12:29 +1100 Message-ID: To: mohamed.boucadair@orange.com Cc: "Joel M. Halpern" , 6man WG , SPRING WG Content-Type: multipart/alternative; boundary="000000000000c7950605ce5eeb9f" Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 15 Oct 2021 07:13:23 -0000 --000000000000c7950605ce5eeb9f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 15 Oct 2021, 17:18 , wrote: > Hi Joel , all, > > C-SID is no more than another mechanism that relies on some algorithmic > mapping embedded in the IPv6 address. We do have already many of such > algorithmic approaches: RFC6052, RFC7597, etc. That's not correct. DAs aren't expected to change in fight, otherwise they will break all of the transport layer protocols for which packet addresses are included in the transport layer checksum. In fight changing DAs also will break AH protection of the IPv6 header. DA changing in flight is NAT. I'd have thought the IETF had learnt that lesson by now. Perhaps people need to read RFC2993 again. > > The internal structure would be problematic if it requires that every > intermediate node on the path has to parse it, but this is not the case. > The packet is forwarded based on the DA following conventional procedures= . > The procedure to determine the next SR hop is internal to an SR-capable > node. > > Having examples of such SIDs in the draft would help to better understand > the compression procedure, but no more than that as these will be display= ed > as IPv6 addresses! > > Cheers, > Med > > > -----Message d'origine----- > > De : ipv6 De la part de Joel M. Halpern > > Envoy=C3=A9 : mercredi 13 octobre 2021 09:37 > > =C3=80 : ipv6@ietf.org > > Cc : spring@ietf.org > > Objet : Typo correction Re: Question from SPRING regarding draft- > > filsfilscheng-spring-srv6-srh-compression > > > > There is a typo in the below which if not understood as a typo would be > > quite confusing. I wrote that I raised the issue with > > "with the Internet ADs and SPRING chairs". > > That should have read "with the Internet ADs and 6man chairs". > > The SPRING co-chairs are recused, and the charter requirement leads to > the > > 6man chairs. Which is who I talked to. > > > > Also, I am sending a courtesy copy to the routing ADs, which I should > have > > done originally. > > > > Thank you and enjoy. > > Yours, > > Joel > > > > On 10/12/2021 11:52 PM, Joel M. Halpern wrote: > > > The SPRING working group is in the midst of an adoption call on > > > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh- > > compression/. > > > > > > > > > The SPRING charter has text that is explicit that modifications to > > > data planes and architectures standardized by other working groups ma= y > > > not be modified in SPRING unless the chairs and ADs responsible for > > > that data plane and / or architecture agree. > > > > > > To complete the context, as my SPRING co-chairs are co-authors on the > > > document in question, they have recused themselves from decisional > > > activities regarding the document. Therefore, this message is coming > > > just from my as the responsible SPRING co-chair managing this adoptio= n > > > call. > > > > > > As you have seen, multiple questions have been raised about the > > > relationship of the document to the IPv6 defined data plane and > > > architecture (particularly RFC 4291 and 8200). In particular the > > > questions seem to revolve around what the document describes as the > > > NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6 > > > standards. (For those seeking more context without reading the full > > > document, a paraphrase and simplification of the NEXT-C_SID flavor is > > > provided as a postscript.) > > > > > > I raised the question of concurrence as required by the SPRING charte= r > > > with the Internet ADs and SPRING chairs. They quite reasonably asked > > > me to write a note to 6man explaining the concerns as clearly as a > > > can, so that they can then determine how to proceed. > > > > > > The questions that prompted my inquiry are: > > > > > > 1) Does the placement of a list of sids in the IPv6 DA field change > > > the > > > IPv6 architectural description of that field. > > > 2) Does the operation of shifting information around in the IPv6 > > > destination address field represent a modification or extension of th= e > > > IPv6 data plane. > > > > > > On a related note, the document in question also defines two other > > > flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The > > > NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID > > > flavor operation, so seems to be affected by the same question. > > > > > > From my own reading, it appears that the REPLACE-C-SID flavor does > > > not raise issues requiring 6man leadership concurrence. > > > > > > Yours, > > > Joel M. Halpern for the SPRING working group > > > > > > > > > PS: > > > Clearly, understanding the question requires some understanding of > > > what the NEXT-C_SID flavor does. This explanation is a > > > simplification for length and context. Really, the best place to > > > understand it is the draft. However, to give you enough information > > > to let you decide whether you care, I will try to provide a fair > > > summary. My apologies in advance to the authors for necessary > > > liberties for length. Also, discussion of the draft contents (as > > > distinct from the interaction with the IPv6 data plane and > > > architecture) belongs on the SPRING list, and should not clutter up > > 6man. > > > > > > SIDs are the identifiers used in segment routing. > > > In SRv6, as document in the current RFCs, these are 128 bits. As > > > defined in the relevant RFCs, SIDs which identify endpoints to which > > > packets are directed are identified by endpoint SIDs. These can have > > > behaviors (decapsulate and forward is one example). They can have > > > flavors such as where the SRH is removed. > > > > > > The topic under discussion is means to compress these SIDs in the > > > packets on the wire. The document under discussion provides three > > > flavors of compression. > > > > > > The fundamental mechanism of the draft is to use a single SRH entry a= s > > > a container for multiple SIDs. In the NEXT-C_SID mechanism, when it > > > is first encountered the entire container is copied into the > > > desination address of the IPv6 packet. The container has a common > > > routing prefix used for all the NEXT-C-SID SIDs. It is followed by a > > > sequence of compressed SIDs of a configured length. One could > > > configure 16, 24, or > > > 32 bits. Or whatever length. The routing advertisements are arrange= d > > > so that the IPv6 packet is directed to the node represented by the > > > first compressed SID on the basis of longest prefix match matching th= e > > > combination of the common routing prefix and that compressed SID. > > > > > > When the packet arrives at that node, it looks up the configured > > > portion, the compressed SID, and determines the behavior and flavor. > > > In the case of the NEXT-C-SID flavor, the resulting operation is to > > > shift the entire remaining contents of the IPv6 address (the bits pas= t > > > the first compressed sid) so as to over-write the first compressed > > > SID. 0 bits are shifted into the low order positions. If the result > > > is a non-zero new first compressed SID, then the packets is forwarded > > > and the process repeats. When all that is left are 0s, if there is a= n > > > SRH, it is consulted to find the next SRH entry, which is, per normal > > > SRv6 processing, put into the IPv6 DA. > > > Note that in the common case where the SIDS needed all fit in to a > > > single container, the analysis also assumes the use of the reduced > > > encapsulation options which omits the SRH that is not needed as it > > > would have no entries. This the packet contains a normal IPv6 header= , > > > with a sequence of compressed SIDs (what one might or might not call = a > > > source > > > route) in the IPv6 destination address field. > > > > > > PPS: If the authors of the NEXT-C-SID flavor feel I have > > > mis-represented the work, please, send clarifications or corrections. > > > Again, the best source of information is the draft itself. I was > > > asked to provide extra context in this email. > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles 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 > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information 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 > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000c7950605ce5eeb9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Fri, 15 Oct 2021, 17:18 , <mohamed.bou= cadair@orange.com> wrote:
    Hi= Joel , all,

    C-SID is no more than another mechanism that relies on some algorithmic map= ping embedded in the IPv6 address. We do have already many of such algorith= mic approaches: RFC6052, RFC7597, etc.


    That's no= t correct.

    DAs aren'= t expected to change in fight, otherwise they will break all of the transpo= rt layer protocols for which packet addresses are included in the transport= layer checksum.

    In figh= t changing DAs also will break AH protection of the IPv6 header.

    DA changing in flight is NAT. I= 9;d have thought the IETF had learnt that lesson by now.

    Perhaps people need to read RFC2993 again.=



    The internal structure would be problematic if it requires that every inter= mediate node on the path has to parse it, but this is not the case. The pac= ket is forwarded based on the DA following conventional procedures. The pro= cedure to determine the next SR hop is internal to an SR-capable node.

    Having examples of such SIDs in the draft would help to better understand t= he compression procedure, but no more than that as these will be displayed = as IPv6 addresses!

    Cheers,
    Med

    > -----Message d'origine-----
    > De=C2=A0: ipv6 <ipv6-bounces@ietf.org> De la p= art de Joel M. Halpern
    > Envoy=C3=A9=C2=A0: mercredi 13 octobre 2021 09:37
    > =C3=80=C2=A0: ipv6@ietf.org
    > Cc=C2=A0: spring@ietf.org
    > Objet=C2=A0: Typo correction Re: Question from SPRING regarding draft-=
    > filsfilscheng-spring-srv6-srh-compression
    >
    > There is a typo in the below which if not understood as a typo would b= e
    > quite confusing.=C2=A0 =C2=A0I wrote that I raised the issue with
    > "with the Internet ADs and SPRING chairs".
    > That should have read "with the Internet ADs and 6man chairs"= ;.
    > The SPRING co-chairs are recused, and the charter requirement leads to= the
    > 6man chairs.=C2=A0 Which is who I talked to.
    >
    > Also, I am sending a courtesy copy to the routing ADs, which I should = have
    > done originally.
    >
    > Thank you and enjoy.
    > Yours,
    > Joel
    >
    > On 10/12/2021 11:52 PM, Joel M. Halpern wrote:
    > > The SPRING working group is in the midst of an adoption call on > > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-<= br> > compression/.
    > >
    > >
    > > The SPRING charter has text that is explicit that modifications t= o
    > > data planes and architectures standardized by other working group= s may
    > > not be modified in SPRING unless the chairs and ADs responsible f= or
    > > that data plane and / or architecture agree.
    > >
    > > To complete the context, as my SPRING co-chairs are co-authors on= the
    > > document in question, they have recused themselves from decisiona= l
    > > activities regarding the document.=C2=A0 Therefore, this message = is coming
    > > just from my as the responsible SPRING co-chair managing this ado= ption
    > > call.
    > >
    > > As you have seen, multiple questions have been raised about the > > relationship of the document to the IPv6 defined data plane and > > architecture (particularly RFC 4291 and 8200). In particular the<= br> > > questions seem to revolve around what the document describes as t= he
    > > NEXT-C-SID flavor of compressed SID, and its relationship to the = IPv6
    > > standards.=C2=A0 (For those seeking more context without reading = the full
    > > document, a paraphrase and simplification of the NEXT-C_SID flavo= r is
    > > provided as a postscript.)
    > >
    > > I raised the question of concurrence as required by the SPRING ch= arter
    > > with the Internet ADs and SPRING chairs.=C2=A0 They quite reasona= bly asked
    > > me to write a note to 6man explaining the concerns as clearly as = a
    > > can, so that they can then determine how to proceed.
    > >
    > > The questions that prompted my inquiry are:
    > >
    > > 1) Does the placement of a list of sids in the IPv6 DA field chan= ge
    > > the
    > > IPv6 architectural description of that field.
    > > 2) Does the operation of shifting information around in the IPv6<= br> > > destination address field represent a modification or extension o= f the
    > > IPv6 data plane.
    > >
    > > On a related note, the document in question also defines two othe= r
    > > flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.=C2=A0 The
    > > NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SI= D
    > > flavor operation, so seems to be affected by the same question. > >
    > >=C2=A0 From my own reading, it appears that the REPLACE-C-SID flav= or does
    > > not raise issues requiring 6man leadership concurrence.
    > >
    > > Yours,
    > > Joel M. Halpern for the SPRING working group
    > >
    > >
    > > PS:
    > > Clearly, understanding the question requires some understanding o= f
    > > what the NEXT-C_SID flavor does.=C2=A0=C2=A0 This explanation is = a
    > > simplification for length and context.=C2=A0 Really, the best pla= ce to
    > > understand it is the draft.=C2=A0 However, to give you enough inf= ormation
    > > to let you decide whether you care, I will try to provide a fair<= br> > > summary.=C2=A0 My apologies in advance to the authors for necessa= ry
    > > liberties for length.=C2=A0 Also, discussion of the draft content= s (as
    > > distinct from the interaction with the IPv6 data plane and
    > > architecture) belongs on the SPRING list, and should not clutter = up
    > 6man.
    > >
    > > SIDs are the identifiers used in segment routing.
    > > In SRv6, as document in the current RFCs, these are 128 bits.=C2= =A0=C2=A0 As
    > > defined in the relevant RFCs, SIDs which identify endpoints to wh= ich
    > > packets are directed are identified by endpoint SIDs.=C2=A0 These= can have
    > > behaviors (decapsulate and forward is one example).=C2=A0 They ca= n have
    > > flavors such as where the SRH is removed.
    > >
    > > The topic under discussion is means to compress these SIDs in the=
    > > packets on the wire.=C2=A0 The document under discussion provides= three
    > > flavors of compression.
    > >
    > > The fundamental mechanism of the draft is to use a single SRH ent= ry as
    > > a container for multiple SIDs.=C2=A0 In the NEXT-C_SID mechanism,= when it
    > > is first encountered the entire container is copied into the
    > > desination address of the IPv6 packet.=C2=A0 The container has a = common
    > > routing prefix used for all the NEXT-C-SID SIDs.=C2=A0 It is foll= owed by a
    > > sequence of compressed SIDs of a configured length.=C2=A0 One cou= ld
    > > configure 16, 24, or
    > > 32 bits.=C2=A0 Or whatever length.=C2=A0 The routing advertisemen= ts are arranged
    > > so that the IPv6 packet is directed to the node represented by th= e
    > > first compressed SID on the basis of longest prefix match matchin= g the
    > > combination of the common routing prefix and that compressed SID.=
    > >
    > > When the packet arrives at that node, it looks up the configured<= br> > > portion, the compressed SID, and determines the behavior and flav= or.
    > > In the case of the NEXT-C-SID flavor, the resulting operation is = to
    > > shift the entire remaining contents of the IPv6 address (the bits= past
    > > the first compressed sid) so as to over-write the first compresse= d
    > > SID.=C2=A0 0 bits are shifted into the low order positions.=C2=A0= If the result
    > > is a non-zero new first compressed SID, then the packets is forwa= rded
    > > and the process repeats.=C2=A0 When all that is left are 0s, if t= here is an
    > > SRH, it is consulted to find the next SRH entry, which is, per no= rmal
    > > SRv6 processing, put into the IPv6 DA.
    > > Note that in the common case where the SIDS needed all fit in to = a
    > > single container, the analysis also assumes the use of the reduce= d
    > > encapsulation options which omits the SRH that is not needed as i= t
    > > would have no entries.=C2=A0 This the packet contains a normal IP= v6 header,
    > > with a sequence of compressed SIDs (what one might or might not c= all a
    > > source
    > > route) in the IPv6 destination address field.
    > >
    > > PPS: If the authors of the NEXT-C-SID flavor feel I have
    > > mis-represented the work, please, send clarifications or correcti= ons.
    > > Again, the best source of information is the draft itself.=C2=A0 = I was
    > > asked to provide extra context in this email.
    >
    > -------------------------------------------------------------------- > IETF IPv6 working group mailing list
    > ipv6@ietf.org
    > Administrative Requests: https:= //www.ietf.org/mailman/listinfo/ipv6
    > --------------------------------------------------------------------
    ___________________________________________________________________________= ______________________________________________

    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 message= s 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 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.

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www= .ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    --000000000000c7950605ce5eeb9f-- From nobody Fri Oct 15 00:21:21 2021 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 85EF93A1898; Fri, 15 Oct 2021 00:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 bODkQWfNHU1C; Fri, 15 Oct 2021 00:21:08 -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 EB9FB3A1874; Fri, 15 Oct 2021 00:21:07 -0700 (PDT) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) (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 opfedar27.francetelecom.fr (ESMTP service) with ESMTPS id 4HVyNy4Lgyz2y22; Fri, 15 Oct 2021 09:21:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1634282466; bh=AImhUd7OQNyJCd7rRtvCBFmoIdxa8eHywJeLMSW/Eco=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=Nuixr8F4XH8G2TtgPrjO4D+BQfO9XovFO8Eks3wHWcum/D3FLJJapBsKZqzx63pHW Z9xFLN1YeEN7fF/ZSiGDFyPoedKVF6pFSDraLSXwHvAastpW/n+7SrKW7c5GXt3qZV ibj2Nn7cBTG1OB094hBnyRJYlyIp+/YSlnykb0Ry7Hm+mwnRiiS46tXZCmIj9nPPRw /+Cng4wdX1dvMJ4qoi6m5ToFYscN1mhB/rm8JhU6xQWsoBPMq7CsoOP+4+sPsTnGux OLNxKSFf7yHyN+ny+IfwfcMVeZHODMcgLrqdODdkwFbdl29EVCGsCblwdMlzMoArds 5okEFzjPxqynw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by opfedar02.francetelecom.fr (ESMTP service) with ESMTPS id 4HVyNy2wVpzCqkd; Fri, 15 Oct 2021 09:21:06 +0200 (CEST) From: To: Mark Smith CC: "Joel M. Halpern" , 6man WG , "SPRING WG" Thread-Topic: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression Thread-Index: AQHXwZQuOXuVqWIUUkuvgoceaWVXEKvTpX6g Content-Class: Date: Fri, 15 Oct 2021 07:21:05 +0000 Message-ID: <14658_1634282466_61692BE2_14658_109_20_787AE7BB302AE849A7480A190F8B93303542C720@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <1396_1634278622_61691CDE_1396_28_5_787AE7BB302AE849A7480A190F8B93303542C654@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 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_07222825-62ea-40f3-96b5-5375c07996e2_Enabled=true; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SetDate=2021-10-15T07:14:55Z; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Method=Privileged; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_Name=unrestricted_parent.2; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_SiteId=90c7a20a-f34b-40bf-bc48-b9253b6f5d20; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ActionId=f0178eaf-e722-46c2-b31f-e7b28253b695; MSIP_Label_07222825-62ea-40f3-96b5-5375c07996e2_ContentBits=0 x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B93303542C720OPEXCAUBMA2corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 15 Oct 2021 07:21:17 -0000 --_000_787AE7BB302AE849A7480A190F8B93303542C720OPEXCAUBMA2corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFyaywNCg0KTm90IHN1cmUgd2hhdCBpcyBpbmNvcnJlY3QgaW4gd2hhdCBJIG1lbnRpb25l ZC4NCg0KQ2hlY2tzdW0gbmV1dHJhbGl0eSBpcyBhIGRpc3RpbmN0IGlzc3VlIHRoYW4gdGhlIG9y aWdpbmFsIHF1ZXN0aW9uIGZyb20gSm9lbC4gVGhhdCB3YXMgZGlzY3Vzc2VkIGluIHRoZSBSRkNz IGNpdGVkIGluIHRoZSBwcmV2aW91cyBtZXNzYWdlLg0KDQpUaGF04oCZcyBzYWlkLCBJ4oCZbSBu b3Qgc3VyZSB0aGF04oCZcyBhbiBpc3N1ZSBmb3IgU1JIIGdpdmVuIHRoYXQgdGhlIGVuY2FwIHdp bGwgbmVlZCB0byBiZSB1cGRhdGVkIGFueXdheSB0byBhbGxvdyB0byBjcm9zcyB0aGUgYXBwcm9w cmlhdGUgU1Igbm9kZXMgb2YgYSBwYXRoLg0KDQpDaGVlcnMsDQpNZWQNCg0KRGUgOiBNYXJrIFNt aXRoIDxtYXJrenp6c21pdGhAZ21haWwuY29tPg0KRW52b3nDqSA6IHZlbmRyZWRpIDE1IG9jdG9i cmUgMjAyMSAwOToxMg0Kw4AgOiBCT1VDQURBSVIgTW9oYW1lZCBJTk5PVi9ORVQgPG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20+DQpDYyA6IEpvZWwgTS4gSGFscGVybiA8am1oQGpvZWxoYWxw ZXJuLmNvbT47IDZtYW4gV0cgPGlwdjZAaWV0Zi5vcmc+OyBTUFJJTkcgV0cgPHNwcmluZ0BpZXRm Lm9yZz4NCk9iamV0IDogUmU6IFR5cG8gY29ycmVjdGlvbiBSZTogUXVlc3Rpb24gZnJvbSBTUFJJ TkcgcmVnYXJkaW5nIGRyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNz aW9uDQoNCg0KT24gRnJpLCAxNSBPY3QgMjAyMSwgMTc6MTggLCA8bW9oYW1lZC5ib3VjYWRhaXJA b3JhbmdlLmNvbTxtYWlsdG86bW9oYW1lZC5ib3VjYWRhaXJAb3JhbmdlLmNvbT4+IHdyb3RlOg0K SGkgSm9lbCAsIGFsbCwNCg0KQy1TSUQgaXMgbm8gbW9yZSB0aGFuIGFub3RoZXIgbWVjaGFuaXNt IHRoYXQgcmVsaWVzIG9uIHNvbWUgYWxnb3JpdGhtaWMgbWFwcGluZyBlbWJlZGRlZCBpbiB0aGUg SVB2NiBhZGRyZXNzLiBXZSBkbyBoYXZlIGFscmVhZHkgbWFueSBvZiBzdWNoIGFsZ29yaXRobWlj IGFwcHJvYWNoZXM6IFJGQzYwNTIsIFJGQzc1OTcsIGV0Yy4NCg0KDQpUaGF0J3Mgbm90IGNvcnJl Y3QuDQoNCkRBcyBhcmVuJ3QgZXhwZWN0ZWQgdG8gY2hhbmdlIGluIGZpZ2h0LCBvdGhlcndpc2Ug dGhleSB3aWxsIGJyZWFrIGFsbCBvZiB0aGUgdHJhbnNwb3J0IGxheWVyIHByb3RvY29scyBmb3Ig d2hpY2ggcGFja2V0IGFkZHJlc3NlcyBhcmUgaW5jbHVkZWQgaW4gdGhlIHRyYW5zcG9ydCBsYXll ciBjaGVja3N1bS4NCg0KSW4gZmlnaHQgY2hhbmdpbmcgREFzIGFsc28gd2lsbCBicmVhayBBSCBw cm90ZWN0aW9uIG9mIHRoZSBJUHY2IGhlYWRlci4NCg0KREEgY2hhbmdpbmcgaW4gZmxpZ2h0IGlz IE5BVC4gSSdkIGhhdmUgdGhvdWdodCB0aGUgSUVURiBoYWQgbGVhcm50IHRoYXQgbGVzc29uIGJ5 IG5vdy4NCg0KUGVyaGFwcyBwZW9wbGUgbmVlZCB0byByZWFkIFJGQzI5OTMgYWdhaW4uDQoNCg0K DQpUaGUgaW50ZXJuYWwgc3RydWN0dXJlIHdvdWxkIGJlIHByb2JsZW1hdGljIGlmIGl0IHJlcXVp cmVzIHRoYXQgZXZlcnkgaW50ZXJtZWRpYXRlIG5vZGUgb24gdGhlIHBhdGggaGFzIHRvIHBhcnNl IGl0LCBidXQgdGhpcyBpcyBub3QgdGhlIGNhc2UuIFRoZSBwYWNrZXQgaXMgZm9yd2FyZGVkIGJh c2VkIG9uIHRoZSBEQSBmb2xsb3dpbmcgY29udmVudGlvbmFsIHByb2NlZHVyZXMuIFRoZSBwcm9j ZWR1cmUgdG8gZGV0ZXJtaW5lIHRoZSBuZXh0IFNSIGhvcCBpcyBpbnRlcm5hbCB0byBhbiBTUi1j YXBhYmxlIG5vZGUuDQoNCkhhdmluZyBleGFtcGxlcyBvZiBzdWNoIFNJRHMgaW4gdGhlIGRyYWZ0 IHdvdWxkIGhlbHAgdG8gYmV0dGVyIHVuZGVyc3RhbmQgdGhlIGNvbXByZXNzaW9uIHByb2NlZHVy ZSwgYnV0IG5vIG1vcmUgdGhhbiB0aGF0IGFzIHRoZXNlIHdpbGwgYmUgZGlzcGxheWVkIGFzIElQ djYgYWRkcmVzc2VzIQ0KDQpDaGVlcnMsDQpNZWQNCg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5l LS0tLS0NCj4gRGUgOiBpcHY2IDxpcHY2LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmlwdjYtYm91 bmNlc0BpZXRmLm9yZz4+IERlIGxhIHBhcnQgZGUgSm9lbCBNLiBIYWxwZXJuDQo+IEVudm95w6kg OiBtZXJjcmVkaSAxMyBvY3RvYnJlIDIwMjEgMDk6MzcNCj4gw4AgOiBpcHY2QGlldGYub3JnPG1h aWx0bzppcHY2QGlldGYub3JnPg0KPiBDYyA6IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5n QGlldGYub3JnPg0KPiBPYmpldCA6IFR5cG8gY29ycmVjdGlvbiBSZTogUXVlc3Rpb24gZnJvbSBT UFJJTkcgcmVnYXJkaW5nIGRyYWZ0LQ0KPiBmaWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1j b21wcmVzc2lvbg0KPg0KPiBUaGVyZSBpcyBhIHR5cG8gaW4gdGhlIGJlbG93IHdoaWNoIGlmIG5v dCB1bmRlcnN0b29kIGFzIGEgdHlwbyB3b3VsZCBiZQ0KPiBxdWl0ZSBjb25mdXNpbmcuICAgSSB3 cm90ZSB0aGF0IEkgcmFpc2VkIHRoZSBpc3N1ZSB3aXRoDQo+ICJ3aXRoIHRoZSBJbnRlcm5ldCBB RHMgYW5kIFNQUklORyBjaGFpcnMiLg0KPiBUaGF0IHNob3VsZCBoYXZlIHJlYWQgIndpdGggdGhl IEludGVybmV0IEFEcyBhbmQgNm1hbiBjaGFpcnMiLg0KPiBUaGUgU1BSSU5HIGNvLWNoYWlycyBh cmUgcmVjdXNlZCwgYW5kIHRoZSBjaGFydGVyIHJlcXVpcmVtZW50IGxlYWRzIHRvIHRoZQ0KPiA2 bWFuIGNoYWlycy4gIFdoaWNoIGlzIHdobyBJIHRhbGtlZCB0by4NCj4NCj4gQWxzbywgSSBhbSBz ZW5kaW5nIGEgY291cnRlc3kgY29weSB0byB0aGUgcm91dGluZyBBRHMsIHdoaWNoIEkgc2hvdWxk IGhhdmUNCj4gZG9uZSBvcmlnaW5hbGx5Lg0KPg0KPiBUaGFuayB5b3UgYW5kIGVuam95Lg0KPiBZ b3VycywNCj4gSm9lbA0KPg0KPiBPbiAxMC8xMi8yMDIxIDExOjUyIFBNLCBKb2VsIE0uIEhhbHBl cm4gd3JvdGU6DQo+ID4gVGhlIFNQUklORyB3b3JraW5nIGdyb3VwIGlzIGluIHRoZSBtaWRzdCBv ZiBhbiBhZG9wdGlvbiBjYWxsIG9uDQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtDQo+IGNvbXByZXNzaW9uLy4N Cj4gPg0KPiA+DQo+ID4gVGhlIFNQUklORyBjaGFydGVyIGhhcyB0ZXh0IHRoYXQgaXMgZXhwbGlj aXQgdGhhdCBtb2RpZmljYXRpb25zIHRvDQo+ID4gZGF0YSBwbGFuZXMgYW5kIGFyY2hpdGVjdHVy ZXMgc3RhbmRhcmRpemVkIGJ5IG90aGVyIHdvcmtpbmcgZ3JvdXBzIG1heQ0KPiA+IG5vdCBiZSBt b2RpZmllZCBpbiBTUFJJTkcgdW5sZXNzIHRoZSBjaGFpcnMgYW5kIEFEcyByZXNwb25zaWJsZSBm b3INCj4gPiB0aGF0IGRhdGEgcGxhbmUgYW5kIC8gb3IgYXJjaGl0ZWN0dXJlIGFncmVlLg0KPiA+ DQo+ID4gVG8gY29tcGxldGUgdGhlIGNvbnRleHQsIGFzIG15IFNQUklORyBjby1jaGFpcnMgYXJl IGNvLWF1dGhvcnMgb24gdGhlDQo+ID4gZG9jdW1lbnQgaW4gcXVlc3Rpb24sIHRoZXkgaGF2ZSBy ZWN1c2VkIHRoZW1zZWx2ZXMgZnJvbSBkZWNpc2lvbmFsDQo+ID4gYWN0aXZpdGllcyByZWdhcmRp bmcgdGhlIGRvY3VtZW50LiAgVGhlcmVmb3JlLCB0aGlzIG1lc3NhZ2UgaXMgY29taW5nDQo+ID4g anVzdCBmcm9tIG15IGFzIHRoZSByZXNwb25zaWJsZSBTUFJJTkcgY28tY2hhaXIgbWFuYWdpbmcg dGhpcyBhZG9wdGlvbg0KPiA+IGNhbGwuDQo+ID4NCj4gPiBBcyB5b3UgaGF2ZSBzZWVuLCBtdWx0 aXBsZSBxdWVzdGlvbnMgaGF2ZSBiZWVuIHJhaXNlZCBhYm91dCB0aGUNCj4gPiByZWxhdGlvbnNo aXAgb2YgdGhlIGRvY3VtZW50IHRvIHRoZSBJUHY2IGRlZmluZWQgZGF0YSBwbGFuZSBhbmQNCj4g PiBhcmNoaXRlY3R1cmUgKHBhcnRpY3VsYXJseSBSRkMgNDI5MSBhbmQgODIwMCkuIEluIHBhcnRp Y3VsYXIgdGhlDQo+ID4gcXVlc3Rpb25zIHNlZW0gdG8gcmV2b2x2ZSBhcm91bmQgd2hhdCB0aGUg ZG9jdW1lbnQgZGVzY3JpYmVzIGFzIHRoZQ0KPiA+IE5FWFQtQy1TSUQgZmxhdm9yIG9mIGNvbXBy ZXNzZWQgU0lELCBhbmQgaXRzIHJlbGF0aW9uc2hpcCB0byB0aGUgSVB2Ng0KPiA+IHN0YW5kYXJk cy4gIChGb3IgdGhvc2Ugc2Vla2luZyBtb3JlIGNvbnRleHQgd2l0aG91dCByZWFkaW5nIHRoZSBm dWxsDQo+ID4gZG9jdW1lbnQsIGEgcGFyYXBocmFzZSBhbmQgc2ltcGxpZmljYXRpb24gb2YgdGhl IE5FWFQtQ19TSUQgZmxhdm9yIGlzDQo+ID4gcHJvdmlkZWQgYXMgYSBwb3N0c2NyaXB0LikNCj4g Pg0KPiA+IEkgcmFpc2VkIHRoZSBxdWVzdGlvbiBvZiBjb25jdXJyZW5jZSBhcyByZXF1aXJlZCBi eSB0aGUgU1BSSU5HIGNoYXJ0ZXINCj4gPiB3aXRoIHRoZSBJbnRlcm5ldCBBRHMgYW5kIFNQUklO RyBjaGFpcnMuICBUaGV5IHF1aXRlIHJlYXNvbmFibHkgYXNrZWQNCj4gPiBtZSB0byB3cml0ZSBh IG5vdGUgdG8gNm1hbiBleHBsYWluaW5nIHRoZSBjb25jZXJucyBhcyBjbGVhcmx5IGFzIGENCj4g PiBjYW4sIHNvIHRoYXQgdGhleSBjYW4gdGhlbiBkZXRlcm1pbmUgaG93IHRvIHByb2NlZWQuDQo+ ID4NCj4gPiBUaGUgcXVlc3Rpb25zIHRoYXQgcHJvbXB0ZWQgbXkgaW5xdWlyeSBhcmU6DQo+ID4N Cj4gPiAxKSBEb2VzIHRoZSBwbGFjZW1lbnQgb2YgYSBsaXN0IG9mIHNpZHMgaW4gdGhlIElQdjYg REEgZmllbGQgY2hhbmdlDQo+ID4gdGhlDQo+ID4gSVB2NiBhcmNoaXRlY3R1cmFsIGRlc2NyaXB0 aW9uIG9mIHRoYXQgZmllbGQuDQo+ID4gMikgRG9lcyB0aGUgb3BlcmF0aW9uIG9mIHNoaWZ0aW5n IGluZm9ybWF0aW9uIGFyb3VuZCBpbiB0aGUgSVB2Ng0KPiA+IGRlc3RpbmF0aW9uIGFkZHJlc3Mg ZmllbGQgcmVwcmVzZW50IGEgbW9kaWZpY2F0aW9uIG9yIGV4dGVuc2lvbiBvZiB0aGUNCj4gPiBJ UHY2IGRhdGEgcGxhbmUuDQo+ID4NCj4gPiBPbiBhIHJlbGF0ZWQgbm90ZSwgdGhlIGRvY3VtZW50 IGluIHF1ZXN0aW9uIGFsc28gZGVmaW5lcyB0d28gb3RoZXINCj4gPiBmbGF2b3JzLCBSRVBMQUNF LUMtU0lELCBhbmQgTkVYVC1hbmQtUkVQTEFDRS1DLVNJRC4gIFRoZQ0KPiA+IE5FWFQtYW5kLVJF UExBQ0UtQ19TSUQgZmxhdm9yIGlzIGRlZmluZWQgdG8gaW5jbHVkZSB0aGUgTkVYVC1DX1NJRA0K PiA+IGZsYXZvciBvcGVyYXRpb24sIHNvIHNlZW1zIHRvIGJlIGFmZmVjdGVkIGJ5IHRoZSBzYW1l IHF1ZXN0aW9uLg0KPiA+DQo+ID4gIEZyb20gbXkgb3duIHJlYWRpbmcsIGl0IGFwcGVhcnMgdGhh dCB0aGUgUkVQTEFDRS1DLVNJRCBmbGF2b3IgZG9lcw0KPiA+IG5vdCByYWlzZSBpc3N1ZXMgcmVx dWlyaW5nIDZtYW4gbGVhZGVyc2hpcCBjb25jdXJyZW5jZS4NCj4gPg0KPiA+IFlvdXJzLA0KPiA+ IEpvZWwgTS4gSGFscGVybiBmb3IgdGhlIFNQUklORyB3b3JraW5nIGdyb3VwDQo+ID4NCj4gPg0K PiA+IFBTOg0KPiA+IENsZWFybHksIHVuZGVyc3RhbmRpbmcgdGhlIHF1ZXN0aW9uIHJlcXVpcmVz IHNvbWUgdW5kZXJzdGFuZGluZyBvZg0KPiA+IHdoYXQgdGhlIE5FWFQtQ19TSUQgZmxhdm9yIGRv ZXMuICAgVGhpcyBleHBsYW5hdGlvbiBpcyBhDQo+ID4gc2ltcGxpZmljYXRpb24gZm9yIGxlbmd0 aCBhbmQgY29udGV4dC4gIFJlYWxseSwgdGhlIGJlc3QgcGxhY2UgdG8NCj4gPiB1bmRlcnN0YW5k IGl0IGlzIHRoZSBkcmFmdC4gIEhvd2V2ZXIsIHRvIGdpdmUgeW91IGVub3VnaCBpbmZvcm1hdGlv bg0KPiA+IHRvIGxldCB5b3UgZGVjaWRlIHdoZXRoZXIgeW91IGNhcmUsIEkgd2lsbCB0cnkgdG8g cHJvdmlkZSBhIGZhaXINCj4gPiBzdW1tYXJ5LiAgTXkgYXBvbG9naWVzIGluIGFkdmFuY2UgdG8g dGhlIGF1dGhvcnMgZm9yIG5lY2Vzc2FyeQ0KPiA+IGxpYmVydGllcyBmb3IgbGVuZ3RoLiAgQWxz bywgZGlzY3Vzc2lvbiBvZiB0aGUgZHJhZnQgY29udGVudHMgKGFzDQo+ID4gZGlzdGluY3QgZnJv bSB0aGUgaW50ZXJhY3Rpb24gd2l0aCB0aGUgSVB2NiBkYXRhIHBsYW5lIGFuZA0KPiA+IGFyY2hp dGVjdHVyZSkgYmVsb25ncyBvbiB0aGUgU1BSSU5HIGxpc3QsIGFuZCBzaG91bGQgbm90IGNsdXR0 ZXIgdXANCj4gNm1hbi4NCj4gPg0KPiA+IFNJRHMgYXJlIHRoZSBpZGVudGlmaWVycyB1c2VkIGlu IHNlZ21lbnQgcm91dGluZy4NCj4gPiBJbiBTUnY2LCBhcyBkb2N1bWVudCBpbiB0aGUgY3VycmVu dCBSRkNzLCB0aGVzZSBhcmUgMTI4IGJpdHMuICAgQXMNCj4gPiBkZWZpbmVkIGluIHRoZSByZWxl dmFudCBSRkNzLCBTSURzIHdoaWNoIGlkZW50aWZ5IGVuZHBvaW50cyB0byB3aGljaA0KPiA+IHBh Y2tldHMgYXJlIGRpcmVjdGVkIGFyZSBpZGVudGlmaWVkIGJ5IGVuZHBvaW50IFNJRHMuICBUaGVz ZSBjYW4gaGF2ZQ0KPiA+IGJlaGF2aW9ycyAoZGVjYXBzdWxhdGUgYW5kIGZvcndhcmQgaXMgb25l IGV4YW1wbGUpLiAgVGhleSBjYW4gaGF2ZQ0KPiA+IGZsYXZvcnMgc3VjaCBhcyB3aGVyZSB0aGUg U1JIIGlzIHJlbW92ZWQuDQo+ID4NCj4gPiBUaGUgdG9waWMgdW5kZXIgZGlzY3Vzc2lvbiBpcyBt ZWFucyB0byBjb21wcmVzcyB0aGVzZSBTSURzIGluIHRoZQ0KPiA+IHBhY2tldHMgb24gdGhlIHdp cmUuICBUaGUgZG9jdW1lbnQgdW5kZXIgZGlzY3Vzc2lvbiBwcm92aWRlcyB0aHJlZQ0KPiA+IGZs YXZvcnMgb2YgY29tcHJlc3Npb24uDQo+ID4NCj4gPiBUaGUgZnVuZGFtZW50YWwgbWVjaGFuaXNt IG9mIHRoZSBkcmFmdCBpcyB0byB1c2UgYSBzaW5nbGUgU1JIIGVudHJ5IGFzDQo+ID4gYSBjb250 YWluZXIgZm9yIG11bHRpcGxlIFNJRHMuICBJbiB0aGUgTkVYVC1DX1NJRCBtZWNoYW5pc20sIHdo ZW4gaXQNCj4gPiBpcyBmaXJzdCBlbmNvdW50ZXJlZCB0aGUgZW50aXJlIGNvbnRhaW5lciBpcyBj b3BpZWQgaW50byB0aGUNCj4gPiBkZXNpbmF0aW9uIGFkZHJlc3Mgb2YgdGhlIElQdjYgcGFja2V0 LiAgVGhlIGNvbnRhaW5lciBoYXMgYSBjb21tb24NCj4gPiByb3V0aW5nIHByZWZpeCB1c2VkIGZv ciBhbGwgdGhlIE5FWFQtQy1TSUQgU0lEcy4gIEl0IGlzIGZvbGxvd2VkIGJ5IGENCj4gPiBzZXF1 ZW5jZSBvZiBjb21wcmVzc2VkIFNJRHMgb2YgYSBjb25maWd1cmVkIGxlbmd0aC4gIE9uZSBjb3Vs ZA0KPiA+IGNvbmZpZ3VyZSAxNiwgMjQsIG9yDQo+ID4gMzIgYml0cy4gIE9yIHdoYXRldmVyIGxl bmd0aC4gIFRoZSByb3V0aW5nIGFkdmVydGlzZW1lbnRzIGFyZSBhcnJhbmdlZA0KPiA+IHNvIHRo YXQgdGhlIElQdjYgcGFja2V0IGlzIGRpcmVjdGVkIHRvIHRoZSBub2RlIHJlcHJlc2VudGVkIGJ5 IHRoZQ0KPiA+IGZpcnN0IGNvbXByZXNzZWQgU0lEIG9uIHRoZSBiYXNpcyBvZiBsb25nZXN0IHBy ZWZpeCBtYXRjaCBtYXRjaGluZyB0aGUNCj4gPiBjb21iaW5hdGlvbiBvZiB0aGUgY29tbW9uIHJv dXRpbmcgcHJlZml4IGFuZCB0aGF0IGNvbXByZXNzZWQgU0lELg0KPiA+DQo+ID4gV2hlbiB0aGUg cGFja2V0IGFycml2ZXMgYXQgdGhhdCBub2RlLCBpdCBsb29rcyB1cCB0aGUgY29uZmlndXJlZA0K PiA+IHBvcnRpb24sIHRoZSBjb21wcmVzc2VkIFNJRCwgYW5kIGRldGVybWluZXMgdGhlIGJlaGF2 aW9yIGFuZCBmbGF2b3IuDQo+ID4gSW4gdGhlIGNhc2Ugb2YgdGhlIE5FWFQtQy1TSUQgZmxhdm9y LCB0aGUgcmVzdWx0aW5nIG9wZXJhdGlvbiBpcyB0bw0KPiA+IHNoaWZ0IHRoZSBlbnRpcmUgcmVt YWluaW5nIGNvbnRlbnRzIG9mIHRoZSBJUHY2IGFkZHJlc3MgKHRoZSBiaXRzIHBhc3QNCj4gPiB0 aGUgZmlyc3QgY29tcHJlc3NlZCBzaWQpIHNvIGFzIHRvIG92ZXItd3JpdGUgdGhlIGZpcnN0IGNv bXByZXNzZWQNCj4gPiBTSUQuICAwIGJpdHMgYXJlIHNoaWZ0ZWQgaW50byB0aGUgbG93IG9yZGVy IHBvc2l0aW9ucy4gIElmIHRoZSByZXN1bHQNCj4gPiBpcyBhIG5vbi16ZXJvIG5ldyBmaXJzdCBj b21wcmVzc2VkIFNJRCwgdGhlbiB0aGUgcGFja2V0cyBpcyBmb3J3YXJkZWQNCj4gPiBhbmQgdGhl IHByb2Nlc3MgcmVwZWF0cy4gIFdoZW4gYWxsIHRoYXQgaXMgbGVmdCBhcmUgMHMsIGlmIHRoZXJl IGlzIGFuDQo+ID4gU1JILCBpdCBpcyBjb25zdWx0ZWQgdG8gZmluZCB0aGUgbmV4dCBTUkggZW50 cnksIHdoaWNoIGlzLCBwZXIgbm9ybWFsDQo+ID4gU1J2NiBwcm9jZXNzaW5nLCBwdXQgaW50byB0 aGUgSVB2NiBEQS4NCj4gPiBOb3RlIHRoYXQgaW4gdGhlIGNvbW1vbiBjYXNlIHdoZXJlIHRoZSBT SURTIG5lZWRlZCBhbGwgZml0IGluIHRvIGENCj4gPiBzaW5nbGUgY29udGFpbmVyLCB0aGUgYW5h bHlzaXMgYWxzbyBhc3N1bWVzIHRoZSB1c2Ugb2YgdGhlIHJlZHVjZWQNCj4gPiBlbmNhcHN1bGF0 aW9uIG9wdGlvbnMgd2hpY2ggb21pdHMgdGhlIFNSSCB0aGF0IGlzIG5vdCBuZWVkZWQgYXMgaXQN Cj4gPiB3b3VsZCBoYXZlIG5vIGVudHJpZXMuICBUaGlzIHRoZSBwYWNrZXQgY29udGFpbnMgYSBu b3JtYWwgSVB2NiBoZWFkZXIsDQo+ID4gd2l0aCBhIHNlcXVlbmNlIG9mIGNvbXByZXNzZWQgU0lE cyAod2hhdCBvbmUgbWlnaHQgb3IgbWlnaHQgbm90IGNhbGwgYQ0KPiA+IHNvdXJjZQ0KPiA+IHJv dXRlKSBpbiB0aGUgSVB2NiBkZXN0aW5hdGlvbiBhZGRyZXNzIGZpZWxkLg0KPiA+DQo+ID4gUFBT OiBJZiB0aGUgYXV0aG9ycyBvZiB0aGUgTkVYVC1DLVNJRCBmbGF2b3IgZmVlbCBJIGhhdmUNCj4g PiBtaXMtcmVwcmVzZW50ZWQgdGhlIHdvcmssIHBsZWFzZSwgc2VuZCBjbGFyaWZpY2F0aW9ucyBv ciBjb3JyZWN0aW9ucy4NCj4gPiBBZ2FpbiwgdGhlIGJlc3Qgc291cmNlIG9mIGluZm9ybWF0aW9u IGlzIHRoZSBkcmFmdCBpdHNlbGYuICBJIHdhcw0KPiA+IGFza2VkIHRvIHByb3ZpZGUgZXh0cmEg Y29udGV4dCBpbiB0aGlzIGVtYWlsLg0KPg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBJRVRGIElQdjYgd29y a2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gaXB2NkBpZXRmLm9yZzxtYWlsdG86aXB2NkBpZXRm Lm9yZz4NCj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vaXB2Ng0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KcGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXINCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpv aW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2Fs dGVyYXRpb24sDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2 aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQp0aGV5IHNo b3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNh dGlvbi4NCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzLg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3Ig bWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0K VGhhbmsgeW91Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFpbGlu ZyBsaXN0DQppcHY2QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYub3JnPg0KQWRtaW5pc3RyYXRp dmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0K LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZp bGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBv dSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2Ug cGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91 dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3Ug ZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUg cHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9y IGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_787AE7BB302AE849A7480A190F8B93303542C720OPEXCAUBMA2corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h bC1yZXBseTsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOndpbmRvd3RleHQ7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJlYWstd29yZCI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIE1hcmssDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Ob3Qgc3VyZSB3aGF0IGlz IGluY29ycmVjdCBpbiB3aGF0IEkgbWVudGlvbmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5D aGVja3N1bSBuZXV0cmFsaXR5IGlzIGEgZGlzdGluY3QgaXNzdWUgdGhhbiB0aGUgb3JpZ2luYWwg cXVlc3Rpb24gZnJvbSBKb2VsLiBUaGF0IHdhcyBkaXNjdXNzZWQgaW4gdGhlIFJGQ3MgY2l0ZWQg aW4gdGhlIHByZXZpb3VzIG1lc3NhZ2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYXTigJlz IHNhaWQsIEnigJltIG5vdCBzdXJlIHRoYXTigJlzIGFuIGlzc3VlIGZvciBTUkggZ2l2ZW4gdGhh dCB0aGUgZW5jYXAgd2lsbCBuZWVkIHRvIGJlIHVwZGF0ZWQgYW55d2F5IHRvIGFsbG93IHRvIGNy b3NzIHRoZSBhcHByb3ByaWF0ZSBTUg0KIG5vZGVzIG9mIGEgcGF0aC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TWVk PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkRlJm5ic3A7OjwvYj4gTWFyayBT bWl0aCAmbHQ7bWFya3p6enNtaXRoQGdtYWlsLmNvbSZndDsgPGJyPg0KPGI+RW52b3nDqSZuYnNw Ozo8L2I+IHZlbmRyZWRpIDE1IG9jdG9icmUgMjAyMSAwOToxMjxicj4NCjxiPsOAJm5ic3A7Ojwv Yj4gQk9VQ0FEQUlSIE1vaGFtZWQgSU5OT1YvTkVUICZsdDttb2hhbWVkLmJvdWNhZGFpckBvcmFu Z2UuY29tJmd0Ozxicj4NCjxiPkNjJm5ic3A7OjwvYj4gSm9lbCBNLiBIYWxwZXJuICZsdDtqbWhA am9lbGhhbHBlcm4uY29tJmd0OzsgNm1hbiBXRyAmbHQ7aXB2NkBpZXRmLm9yZyZndDs7IFNQUklO RyBXRyAmbHQ7c3ByaW5nQGlldGYub3JnJmd0Ozxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6 IFR5cG8gY29ycmVjdGlvbiBSZTogUXVlc3Rpb24gZnJvbSBTUFJJTkcgcmVnYXJkaW5nIGRyYWZ0 LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIEZyaSwgMTUgT2N0IDIwMjEsIDE3OjE4ICwgJmx0OzxhIGhyZWY9Im1h aWx0bzptb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+bW9oYW1l ZC5ib3VjYWRhaXJAb3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0ND Q0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21h cmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgSm9lbCAsIGFsbCwgPGJy Pg0KPGJyPg0KQy1TSUQgaXMgbm8gbW9yZSB0aGFuIGFub3RoZXIgbWVjaGFuaXNtIHRoYXQgcmVs aWVzIG9uIHNvbWUgYWxnb3JpdGhtaWMgbWFwcGluZyBlbWJlZGRlZCBpbiB0aGUgSVB2NiBhZGRy ZXNzLiBXZSBkbyBoYXZlIGFscmVhZHkgbWFueSBvZiBzdWNoIGFsZ29yaXRobWljIGFwcHJvYWNo ZXM6IFJGQzYwNTIsIFJGQzc1OTcsIGV0Yy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQncyBu b3QgY29ycmVjdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+REFzIGFyZW4ndCBleHBlY3RlZCB0byBjaGFuZ2UgaW4gZmlnaHQsIG90aGVyd2lz ZSB0aGV5IHdpbGwgYnJlYWsgYWxsIG9mIHRoZSB0cmFuc3BvcnQgbGF5ZXIgcHJvdG9jb2xzIGZv ciB3aGljaCBwYWNrZXQgYWRkcmVzc2VzIGFyZSBpbmNsdWRlZCBpbiB0aGUgdHJhbnNwb3J0IGxh eWVyIGNoZWNrc3VtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JbiBmaWdodCBjaGFuZ2luZyBEQXMgYWxzbyB3aWxsIGJyZWFrIEFIIHByb3Rl Y3Rpb24gb2YgdGhlIElQdjYgaGVhZGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5EQSBjaGFuZ2luZyBpbiBmbGlnaHQgaXMgTkFULiBJJ2Qg aGF2ZSB0aG91Z2h0IHRoZSBJRVRGIGhhZCBsZWFybnQgdGhhdCBsZXNzb24gYnkgbm93LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QZXJoYXBz IHBlb3BsZSBuZWVkIHRvIHJlYWQgUkZDMjk5MyBhZ2Fpbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+ DQo8YnI+DQpUaGUgaW50ZXJuYWwgc3RydWN0dXJlIHdvdWxkIGJlIHByb2JsZW1hdGljIGlmIGl0 IHJlcXVpcmVzIHRoYXQgZXZlcnkgaW50ZXJtZWRpYXRlIG5vZGUgb24gdGhlIHBhdGggaGFzIHRv IHBhcnNlIGl0LCBidXQgdGhpcyBpcyBub3QgdGhlIGNhc2UuIFRoZSBwYWNrZXQgaXMgZm9yd2Fy ZGVkIGJhc2VkIG9uIHRoZSBEQSBmb2xsb3dpbmcgY29udmVudGlvbmFsIHByb2NlZHVyZXMuIFRo ZSBwcm9jZWR1cmUgdG8gZGV0ZXJtaW5lIHRoZSBuZXh0IFNSDQogaG9wIGlzIGludGVybmFsIHRv IGFuIFNSLWNhcGFibGUgbm9kZS48YnI+DQo8YnI+DQpIYXZpbmcgZXhhbXBsZXMgb2Ygc3VjaCBT SURzIGluIHRoZSBkcmFmdCB3b3VsZCBoZWxwIHRvIGJldHRlciB1bmRlcnN0YW5kIHRoZSBjb21w cmVzc2lvbiBwcm9jZWR1cmUsIGJ1dCBubyBtb3JlIHRoYW4gdGhhdCBhcyB0aGVzZSB3aWxsIGJl IGRpc3BsYXllZCBhcyBJUHY2IGFkZHJlc3NlcyENCjxicj4NCjxicj4NCkNoZWVycyw8YnI+DQpN ZWQ8YnI+DQo8YnI+DQomZ3Q7IC0tLS0tTWVzc2FnZSBkJ29yaWdpbmUtLS0tLTxicj4NCiZndDsg RGUmbmJzcDs6IGlwdjYgJmx0OzxhIGhyZWY9Im1haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5pcHY2LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBEZSBsYSBwYXJ0 IGRlIEpvZWwgTS4gSGFscGVybjxicj4NCiZndDsgRW52b3nDqSZuYnNwOzogbWVyY3JlZGkgMTMg b2N0b2JyZSAyMDIxIDA5OjM3PGJyPg0KJmd0OyDDgCZuYnNwOzogPGEgaHJlZj0ibWFpbHRvOmlw djZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pcHY2QGlldGYub3JnPC9hPjxicj4NCiZndDsg Q2MmbmJzcDs6IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBPYmpldCZuYnNwOzogVHlwbyBjb3JyZWN0 aW9uIFJlOiBRdWVzdGlvbiBmcm9tIFNQUklORyByZWdhcmRpbmcgZHJhZnQtPGJyPg0KJmd0OyBm aWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbjxicj4NCiZndDsgPGJyPg0K Jmd0OyBUaGVyZSBpcyBhIHR5cG8gaW4gdGhlIGJlbG93IHdoaWNoIGlmIG5vdCB1bmRlcnN0b29k IGFzIGEgdHlwbyB3b3VsZCBiZTxicj4NCiZndDsgcXVpdGUgY29uZnVzaW5nLiZuYnNwOyAmbmJz cDtJIHdyb3RlIHRoYXQgSSByYWlzZWQgdGhlIGlzc3VlIHdpdGg8YnI+DQomZ3Q7ICZxdW90O3dp dGggdGhlIEludGVybmV0IEFEcyBhbmQgU1BSSU5HIGNoYWlycyZxdW90Oy48YnI+DQomZ3Q7IFRo YXQgc2hvdWxkIGhhdmUgcmVhZCAmcXVvdDt3aXRoIHRoZSBJbnRlcm5ldCBBRHMgYW5kIDZtYW4g Y2hhaXJzJnF1b3Q7Ljxicj4NCiZndDsgVGhlIFNQUklORyBjby1jaGFpcnMgYXJlIHJlY3VzZWQs IGFuZCB0aGUgY2hhcnRlciByZXF1aXJlbWVudCBsZWFkcyB0byB0aGU8YnI+DQomZ3Q7IDZtYW4g Y2hhaXJzLiZuYnNwOyBXaGljaCBpcyB3aG8gSSB0YWxrZWQgdG8uPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEFsc28sIEkgYW0gc2VuZGluZyBhIGNvdXJ0ZXN5IGNvcHkgdG8gdGhlIHJvdXRpbmcgQURz LCB3aGljaCBJIHNob3VsZCBoYXZlPGJyPg0KJmd0OyBkb25lIG9yaWdpbmFsbHkuPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IFRoYW5rIHlvdSBhbmQgZW5qb3kuPGJyPg0KJmd0OyBZb3Vycyw8YnI+DQom Z3Q7IEpvZWw8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gMTAvMTIvMjAyMSAxMTo1MiBQTSwgSm9l bCBNLiBIYWxwZXJuIHdyb3RlOjxicj4NCiZndDsgJmd0OyBUaGUgU1BSSU5HIHdvcmtpbmcgZ3Jv dXAgaXMgaW4gdGhlIG1pZHN0IG9mIGFuIGFkb3B0aW9uIGNhbGwgb248YnI+DQomZ3Q7ICZndDsg PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNj aGVuZy1zcHJpbmctc3J2Ni1zcmgtIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC08L2E+ PGJyPg0KJmd0OyBjb21wcmVzc2lvbi8uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7IFRoZSBTUFJJTkcgY2hhcnRlciBoYXMgdGV4dCB0aGF0IGlzIGV4cGxpY2l0 IHRoYXQgbW9kaWZpY2F0aW9ucyB0bzxicj4NCiZndDsgJmd0OyBkYXRhIHBsYW5lcyBhbmQgYXJj aGl0ZWN0dXJlcyBzdGFuZGFyZGl6ZWQgYnkgb3RoZXIgd29ya2luZyBncm91cHMgbWF5PGJyPg0K Jmd0OyAmZ3Q7IG5vdCBiZSBtb2RpZmllZCBpbiBTUFJJTkcgdW5sZXNzIHRoZSBjaGFpcnMgYW5k IEFEcyByZXNwb25zaWJsZSBmb3I8YnI+DQomZ3Q7ICZndDsgdGhhdCBkYXRhIHBsYW5lIGFuZCAv IG9yIGFyY2hpdGVjdHVyZSBhZ3JlZS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgVG8g Y29tcGxldGUgdGhlIGNvbnRleHQsIGFzIG15IFNQUklORyBjby1jaGFpcnMgYXJlIGNvLWF1dGhv cnMgb24gdGhlPGJyPg0KJmd0OyAmZ3Q7IGRvY3VtZW50IGluIHF1ZXN0aW9uLCB0aGV5IGhhdmUg cmVjdXNlZCB0aGVtc2VsdmVzIGZyb20gZGVjaXNpb25hbDxicj4NCiZndDsgJmd0OyBhY3Rpdml0 aWVzIHJlZ2FyZGluZyB0aGUgZG9jdW1lbnQuJm5ic3A7IFRoZXJlZm9yZSwgdGhpcyBtZXNzYWdl IGlzIGNvbWluZzxicj4NCiZndDsgJmd0OyBqdXN0IGZyb20gbXkgYXMgdGhlIHJlc3BvbnNpYmxl IFNQUklORyBjby1jaGFpciBtYW5hZ2luZyB0aGlzIGFkb3B0aW9uPGJyPg0KJmd0OyAmZ3Q7IGNh bGwuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEFzIHlvdSBoYXZlIHNlZW4sIG11bHRp cGxlIHF1ZXN0aW9ucyBoYXZlIGJlZW4gcmFpc2VkIGFib3V0IHRoZTxicj4NCiZndDsgJmd0OyBy ZWxhdGlvbnNoaXAgb2YgdGhlIGRvY3VtZW50IHRvIHRoZSBJUHY2IGRlZmluZWQgZGF0YSBwbGFu ZSBhbmQ8YnI+DQomZ3Q7ICZndDsgYXJjaGl0ZWN0dXJlIChwYXJ0aWN1bGFybHkgUkZDIDQyOTEg YW5kIDgyMDApLiBJbiBwYXJ0aWN1bGFyIHRoZTxicj4NCiZndDsgJmd0OyBxdWVzdGlvbnMgc2Vl bSB0byByZXZvbHZlIGFyb3VuZCB3aGF0IHRoZSBkb2N1bWVudCBkZXNjcmliZXMgYXMgdGhlPGJy Pg0KJmd0OyAmZ3Q7IE5FWFQtQy1TSUQgZmxhdm9yIG9mIGNvbXByZXNzZWQgU0lELCBhbmQgaXRz IHJlbGF0aW9uc2hpcCB0byB0aGUgSVB2Njxicj4NCiZndDsgJmd0OyBzdGFuZGFyZHMuJm5ic3A7 IChGb3IgdGhvc2Ugc2Vla2luZyBtb3JlIGNvbnRleHQgd2l0aG91dCByZWFkaW5nIHRoZSBmdWxs PGJyPg0KJmd0OyAmZ3Q7IGRvY3VtZW50LCBhIHBhcmFwaHJhc2UgYW5kIHNpbXBsaWZpY2F0aW9u IG9mIHRoZSBORVhULUNfU0lEIGZsYXZvciBpczxicj4NCiZndDsgJmd0OyBwcm92aWRlZCBhcyBh IHBvc3RzY3JpcHQuKTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBJIHJhaXNlZCB0aGUg cXVlc3Rpb24gb2YgY29uY3VycmVuY2UgYXMgcmVxdWlyZWQgYnkgdGhlIFNQUklORyBjaGFydGVy PGJyPg0KJmd0OyAmZ3Q7IHdpdGggdGhlIEludGVybmV0IEFEcyBhbmQgU1BSSU5HIGNoYWlycy4m bmJzcDsgVGhleSBxdWl0ZSByZWFzb25hYmx5IGFza2VkPGJyPg0KJmd0OyAmZ3Q7IG1lIHRvIHdy aXRlIGEgbm90ZSB0byA2bWFuIGV4cGxhaW5pbmcgdGhlIGNvbmNlcm5zIGFzIGNsZWFybHkgYXMg YTxicj4NCiZndDsgJmd0OyBjYW4sIHNvIHRoYXQgdGhleSBjYW4gdGhlbiBkZXRlcm1pbmUgaG93 IHRvIHByb2NlZWQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFRoZSBxdWVzdGlvbnMg dGhhdCBwcm9tcHRlZCBteSBpbnF1aXJ5IGFyZTo8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZn dDsgMSkgRG9lcyB0aGUgcGxhY2VtZW50IG9mIGEgbGlzdCBvZiBzaWRzIGluIHRoZSBJUHY2IERB IGZpZWxkIGNoYW5nZTxicj4NCiZndDsgJmd0OyB0aGU8YnI+DQomZ3Q7ICZndDsgSVB2NiBhcmNo aXRlY3R1cmFsIGRlc2NyaXB0aW9uIG9mIHRoYXQgZmllbGQuPGJyPg0KJmd0OyAmZ3Q7IDIpIERv ZXMgdGhlIG9wZXJhdGlvbiBvZiBzaGlmdGluZyBpbmZvcm1hdGlvbiBhcm91bmQgaW4gdGhlIElQ djY8YnI+DQomZ3Q7ICZndDsgZGVzdGluYXRpb24gYWRkcmVzcyBmaWVsZCByZXByZXNlbnQgYSBt b2RpZmljYXRpb24gb3IgZXh0ZW5zaW9uIG9mIHRoZTxicj4NCiZndDsgJmd0OyBJUHY2IGRhdGEg cGxhbmUuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE9uIGEgcmVsYXRlZCBub3RlLCB0 aGUgZG9jdW1lbnQgaW4gcXVlc3Rpb24gYWxzbyBkZWZpbmVzIHR3byBvdGhlcjxicj4NCiZndDsg Jmd0OyBmbGF2b3JzLCBSRVBMQUNFLUMtU0lELCBhbmQgTkVYVC1hbmQtUkVQTEFDRS1DLVNJRC4m bmJzcDsgVGhlPGJyPg0KJmd0OyAmZ3Q7IE5FWFQtYW5kLVJFUExBQ0UtQ19TSUQgZmxhdm9yIGlz IGRlZmluZWQgdG8gaW5jbHVkZSB0aGUgTkVYVC1DX1NJRDxicj4NCiZndDsgJmd0OyBmbGF2b3Ig b3BlcmF0aW9uLCBzbyBzZWVtcyB0byBiZSBhZmZlY3RlZCBieSB0aGUgc2FtZSBxdWVzdGlvbi48 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgRnJvbSBteSBvd24gcmVhZGluZywg aXQgYXBwZWFycyB0aGF0IHRoZSBSRVBMQUNFLUMtU0lEIGZsYXZvciBkb2VzPGJyPg0KJmd0OyAm Z3Q7IG5vdCByYWlzZSBpc3N1ZXMgcmVxdWlyaW5nIDZtYW4gbGVhZGVyc2hpcCBjb25jdXJyZW5j ZS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgWW91cnMsPGJyPg0KJmd0OyAmZ3Q7IEpv ZWwgTS4gSGFscGVybiBmb3IgdGhlIFNQUklORyB3b3JraW5nIGdyb3VwPGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFBTOjxicj4NCiZndDsgJmd0OyBDbGVhcmx5 LCB1bmRlcnN0YW5kaW5nIHRoZSBxdWVzdGlvbiByZXF1aXJlcyBzb21lIHVuZGVyc3RhbmRpbmcg b2Y8YnI+DQomZ3Q7ICZndDsgd2hhdCB0aGUgTkVYVC1DX1NJRCBmbGF2b3IgZG9lcy4mbmJzcDsm bmJzcDsgVGhpcyBleHBsYW5hdGlvbiBpcyBhPGJyPg0KJmd0OyAmZ3Q7IHNpbXBsaWZpY2F0aW9u IGZvciBsZW5ndGggYW5kIGNvbnRleHQuJm5ic3A7IFJlYWxseSwgdGhlIGJlc3QgcGxhY2UgdG88 YnI+DQomZ3Q7ICZndDsgdW5kZXJzdGFuZCBpdCBpcyB0aGUgZHJhZnQuJm5ic3A7IEhvd2V2ZXIs IHRvIGdpdmUgeW91IGVub3VnaCBpbmZvcm1hdGlvbjxicj4NCiZndDsgJmd0OyB0byBsZXQgeW91 IGRlY2lkZSB3aGV0aGVyIHlvdSBjYXJlLCBJIHdpbGwgdHJ5IHRvIHByb3ZpZGUgYSBmYWlyPGJy Pg0KJmd0OyAmZ3Q7IHN1bW1hcnkuJm5ic3A7IE15IGFwb2xvZ2llcyBpbiBhZHZhbmNlIHRvIHRo ZSBhdXRob3JzIGZvciBuZWNlc3Nhcnk8YnI+DQomZ3Q7ICZndDsgbGliZXJ0aWVzIGZvciBsZW5n dGguJm5ic3A7IEFsc28sIGRpc2N1c3Npb24gb2YgdGhlIGRyYWZ0IGNvbnRlbnRzIChhczxicj4N CiZndDsgJmd0OyBkaXN0aW5jdCBmcm9tIHRoZSBpbnRlcmFjdGlvbiB3aXRoIHRoZSBJUHY2IGRh dGEgcGxhbmUgYW5kPGJyPg0KJmd0OyAmZ3Q7IGFyY2hpdGVjdHVyZSkgYmVsb25ncyBvbiB0aGUg U1BSSU5HIGxpc3QsIGFuZCBzaG91bGQgbm90IGNsdXR0ZXIgdXA8YnI+DQomZ3Q7IDZtYW4uPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFNJRHMgYXJlIHRoZSBpZGVudGlmaWVycyB1c2Vk IGluIHNlZ21lbnQgcm91dGluZy48YnI+DQomZ3Q7ICZndDsgSW4gU1J2NiwgYXMgZG9jdW1lbnQg aW4gdGhlIGN1cnJlbnQgUkZDcywgdGhlc2UgYXJlIDEyOCBiaXRzLiZuYnNwOyZuYnNwOyBBczxi cj4NCiZndDsgJmd0OyBkZWZpbmVkIGluIHRoZSByZWxldmFudCBSRkNzLCBTSURzIHdoaWNoIGlk ZW50aWZ5IGVuZHBvaW50cyB0byB3aGljaDxicj4NCiZndDsgJmd0OyBwYWNrZXRzIGFyZSBkaXJl Y3RlZCBhcmUgaWRlbnRpZmllZCBieSBlbmRwb2ludCBTSURzLiZuYnNwOyBUaGVzZSBjYW4gaGF2 ZTxicj4NCiZndDsgJmd0OyBiZWhhdmlvcnMgKGRlY2Fwc3VsYXRlIGFuZCBmb3J3YXJkIGlzIG9u ZSBleGFtcGxlKS4mbmJzcDsgVGhleSBjYW4gaGF2ZTxicj4NCiZndDsgJmd0OyBmbGF2b3JzIHN1 Y2ggYXMgd2hlcmUgdGhlIFNSSCBpcyByZW1vdmVkLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBUaGUgdG9waWMgdW5kZXIgZGlzY3Vzc2lvbiBpcyBtZWFucyB0byBjb21wcmVzcyB0aGVz ZSBTSURzIGluIHRoZTxicj4NCiZndDsgJmd0OyBwYWNrZXRzIG9uIHRoZSB3aXJlLiZuYnNwOyBU aGUgZG9jdW1lbnQgdW5kZXIgZGlzY3Vzc2lvbiBwcm92aWRlcyB0aHJlZTxicj4NCiZndDsgJmd0 OyBmbGF2b3JzIG9mIGNvbXByZXNzaW9uLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBU aGUgZnVuZGFtZW50YWwgbWVjaGFuaXNtIG9mIHRoZSBkcmFmdCBpcyB0byB1c2UgYSBzaW5nbGUg U1JIIGVudHJ5IGFzPGJyPg0KJmd0OyAmZ3Q7IGEgY29udGFpbmVyIGZvciBtdWx0aXBsZSBTSURz LiZuYnNwOyBJbiB0aGUgTkVYVC1DX1NJRCBtZWNoYW5pc20sIHdoZW4gaXQ8YnI+DQomZ3Q7ICZn dDsgaXMgZmlyc3QgZW5jb3VudGVyZWQgdGhlIGVudGlyZSBjb250YWluZXIgaXMgY29waWVkIGlu dG8gdGhlPGJyPg0KJmd0OyAmZ3Q7IGRlc2luYXRpb24gYWRkcmVzcyBvZiB0aGUgSVB2NiBwYWNr ZXQuJm5ic3A7IFRoZSBjb250YWluZXIgaGFzIGEgY29tbW9uPGJyPg0KJmd0OyAmZ3Q7IHJvdXRp bmcgcHJlZml4IHVzZWQgZm9yIGFsbCB0aGUgTkVYVC1DLVNJRCBTSURzLiZuYnNwOyBJdCBpcyBm b2xsb3dlZCBieSBhPGJyPg0KJmd0OyAmZ3Q7IHNlcXVlbmNlIG9mIGNvbXByZXNzZWQgU0lEcyBv ZiBhIGNvbmZpZ3VyZWQgbGVuZ3RoLiZuYnNwOyBPbmUgY291bGQ8YnI+DQomZ3Q7ICZndDsgY29u ZmlndXJlIDE2LCAyNCwgb3I8YnI+DQomZ3Q7ICZndDsgMzIgYml0cy4mbmJzcDsgT3Igd2hhdGV2 ZXIgbGVuZ3RoLiZuYnNwOyBUaGUgcm91dGluZyBhZHZlcnRpc2VtZW50cyBhcmUgYXJyYW5nZWQ8 YnI+DQomZ3Q7ICZndDsgc28gdGhhdCB0aGUgSVB2NiBwYWNrZXQgaXMgZGlyZWN0ZWQgdG8gdGhl IG5vZGUgcmVwcmVzZW50ZWQgYnkgdGhlPGJyPg0KJmd0OyAmZ3Q7IGZpcnN0IGNvbXByZXNzZWQg U0lEIG9uIHRoZSBiYXNpcyBvZiBsb25nZXN0IHByZWZpeCBtYXRjaCBtYXRjaGluZyB0aGU8YnI+ DQomZ3Q7ICZndDsgY29tYmluYXRpb24gb2YgdGhlIGNvbW1vbiByb3V0aW5nIHByZWZpeCBhbmQg dGhhdCBjb21wcmVzc2VkIFNJRC48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgV2hlbiB0 aGUgcGFja2V0IGFycml2ZXMgYXQgdGhhdCBub2RlLCBpdCBsb29rcyB1cCB0aGUgY29uZmlndXJl ZDxicj4NCiZndDsgJmd0OyBwb3J0aW9uLCB0aGUgY29tcHJlc3NlZCBTSUQsIGFuZCBkZXRlcm1p bmVzIHRoZSBiZWhhdmlvciBhbmQgZmxhdm9yLjxicj4NCiZndDsgJmd0OyBJbiB0aGUgY2FzZSBv ZiB0aGUgTkVYVC1DLVNJRCBmbGF2b3IsIHRoZSByZXN1bHRpbmcgb3BlcmF0aW9uIGlzIHRvPGJy Pg0KJmd0OyAmZ3Q7IHNoaWZ0IHRoZSBlbnRpcmUgcmVtYWluaW5nIGNvbnRlbnRzIG9mIHRoZSBJ UHY2IGFkZHJlc3MgKHRoZSBiaXRzIHBhc3Q8YnI+DQomZ3Q7ICZndDsgdGhlIGZpcnN0IGNvbXBy ZXNzZWQgc2lkKSBzbyBhcyB0byBvdmVyLXdyaXRlIHRoZSBmaXJzdCBjb21wcmVzc2VkPGJyPg0K Jmd0OyAmZ3Q7IFNJRC4mbmJzcDsgMCBiaXRzIGFyZSBzaGlmdGVkIGludG8gdGhlIGxvdyBvcmRl ciBwb3NpdGlvbnMuJm5ic3A7IElmIHRoZSByZXN1bHQ8YnI+DQomZ3Q7ICZndDsgaXMgYSBub24t emVybyBuZXcgZmlyc3QgY29tcHJlc3NlZCBTSUQsIHRoZW4gdGhlIHBhY2tldHMgaXMgZm9yd2Fy ZGVkPGJyPg0KJmd0OyAmZ3Q7IGFuZCB0aGUgcHJvY2VzcyByZXBlYXRzLiZuYnNwOyBXaGVuIGFs bCB0aGF0IGlzIGxlZnQgYXJlIDBzLCBpZiB0aGVyZSBpcyBhbjxicj4NCiZndDsgJmd0OyBTUkgs IGl0IGlzIGNvbnN1bHRlZCB0byBmaW5kIHRoZSBuZXh0IFNSSCBlbnRyeSwgd2hpY2ggaXMsIHBl ciBub3JtYWw8YnI+DQomZ3Q7ICZndDsgU1J2NiBwcm9jZXNzaW5nLCBwdXQgaW50byB0aGUgSVB2 NiBEQS48YnI+DQomZ3Q7ICZndDsgTm90ZSB0aGF0IGluIHRoZSBjb21tb24gY2FzZSB3aGVyZSB0 aGUgU0lEUyBuZWVkZWQgYWxsIGZpdCBpbiB0byBhPGJyPg0KJmd0OyAmZ3Q7IHNpbmdsZSBjb250 YWluZXIsIHRoZSBhbmFseXNpcyBhbHNvIGFzc3VtZXMgdGhlIHVzZSBvZiB0aGUgcmVkdWNlZDxi cj4NCiZndDsgJmd0OyBlbmNhcHN1bGF0aW9uIG9wdGlvbnMgd2hpY2ggb21pdHMgdGhlIFNSSCB0 aGF0IGlzIG5vdCBuZWVkZWQgYXMgaXQ8YnI+DQomZ3Q7ICZndDsgd291bGQgaGF2ZSBubyBlbnRy aWVzLiZuYnNwOyBUaGlzIHRoZSBwYWNrZXQgY29udGFpbnMgYSBub3JtYWwgSVB2NiBoZWFkZXIs PGJyPg0KJmd0OyAmZ3Q7IHdpdGggYSBzZXF1ZW5jZSBvZiBjb21wcmVzc2VkIFNJRHMgKHdoYXQg b25lIG1pZ2h0IG9yIG1pZ2h0IG5vdCBjYWxsIGE8YnI+DQomZ3Q7ICZndDsgc291cmNlPGJyPg0K Jmd0OyAmZ3Q7IHJvdXRlKSBpbiB0aGUgSVB2NiBkZXN0aW5hdGlvbiBhZGRyZXNzIGZpZWxkLjxi cj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBQUFM6IElmIHRoZSBhdXRob3JzIG9mIHRoZSBO RVhULUMtU0lEIGZsYXZvciBmZWVsIEkgaGF2ZTxicj4NCiZndDsgJmd0OyBtaXMtcmVwcmVzZW50 ZWQgdGhlIHdvcmssIHBsZWFzZSwgc2VuZCBjbGFyaWZpY2F0aW9ucyBvciBjb3JyZWN0aW9ucy48 YnI+DQomZ3Q7ICZndDsgQWdhaW4sIHRoZSBiZXN0IHNvdXJjZSBvZiBpbmZvcm1hdGlvbiBpcyB0 aGUgZHJhZnQgaXRzZWxmLiZuYnNwOyBJIHdhczxicj4NCiZndDsgJmd0OyBhc2tlZCB0byBwcm92 aWRlIGV4dHJhIGNvbnRleHQgaW4gdGhpcyBlbWFpbC48YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+DQomZ3Q7IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdDxi cj4NCiZndDsgPGEgaHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5p cHY2QGlldGYub3JnPC9hPjxicj4NCiZndDsgQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IDxhIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2NiIgdGFyZ2V0PSJf YmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2PC9hPjxi cj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KPGJyPg0KQ2UgbWVz c2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRp b25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPGJy Pg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUg c2lnbmFsZXI8YnI+DQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVz IHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0 aWJsZXMgZCdhbHRlcmF0aW9uLDxicj4NCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmls aXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJj aS48YnI+DQo8YnI+DQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90 ZWN0ZWQgYnkgbGF3Ozxicj4NCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBv ciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxicj4NCklmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRl IHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxicj4NCkFzIGVtYWlscyBtYXkgYmUg YWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVu IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48YnI+DQpUaGFuayB5b3UuPGJyPg0KPGJy Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS08YnI+DQpJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3Q8 YnI+DQo8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlwdjZA aWV0Zi5vcmc8L2E+PGJyPg0KQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IDxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2NiIgdGFyZ2V0PSJfYmxhbmsiPg0K aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2PC9hPjxicj4NCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVj ZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVs bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3Jhbmdl IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1 dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQg ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJl IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5 Pg0KPC9odG1sPg0K --_000_787AE7BB302AE849A7480A190F8B93303542C720OPEXCAUBMA2corp_-- From baoguixin@baidu.com Thu Oct 14 01:24:24 2021 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 594D63A0E9C; Thu, 14 Oct 2021 01:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OR1V4ELHZY7I; Thu, 14 Oct 2021 01:24:19 -0700 (PDT) Received: from baidu.com (mx22.baidu.com [220.181.50.185]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5443A0E95; Thu, 14 Oct 2021 01:24:15 -0700 (PDT) Received: from BJHW-Mail-Ex13.internal.baidu.com (unknown [10.127.64.36]) by Forcepoint Email with ESMTPS id 4584340005373F4F47BA; Thu, 14 Oct 2021 16:24:08 +0800 (CST) Received: from BJHW-MAIL-EX25.internal.baidu.com (10.127.64.40) by BJHW-Mail-Ex13.internal.baidu.com (10.127.64.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14; Thu, 14 Oct 2021 16:24:08 +0800 Received: from BJHW-MAIL-EX25.internal.baidu.com (10.127.64.40) by BJHW-MAIL-EX25.internal.baidu.com (10.127.64.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.14; Thu, 14 Oct 2021 16:24:07 +0800 Received: from BJHW-MAIL-EX25.internal.baidu.com ([169.254.1.114]) by BJHW-MAIL-EX25.internal.baidu.com ([169.254.1.114]) with mapi id 15.01.2308.014; Thu, 14 Oct 2021 16:24:07 +0800 From: "Bao,Guixin" To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: AQHXwNTbSK1+iaDi8k6Ss7lPL41lUw== Date: Thu, 14 Oct 2021 08:24:07 +0000 Message-ID: <675D7B89-7CC4-44D2-8167-7C51382D7BC1@baidu.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.22.204.158] Content-Type: multipart/alternative; boundary="_000_675D7B897CC444D281677C51382D7BC1baiducom_" MIME-Version: 1.0 X-Baidu-BdMsfe-DateCheck: 1_BJHW-Mail-Ex13_2021-10-14 16:24:08:389 Archived-At: X-Mailman-Approved-At: Fri, 15 Oct 2021 01:17:52 -0700 Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 14 Oct 2021 08:50:15 -0000 --_000_675D7B897CC444D281677C51382D7BC1baiducom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIERlYXIgV0cNCg0KSSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0Lg0KDQpG cm9tIHRoZSB1c2VyIHBvaW50IG9mIHZpZXcsIEkgdGhpbmsgdGhlIENTSUQgcHJvcG9zZXMgYSBo aWdobHkgZWZmaWNpZW50IHdheSAgZm9yIFNSdjYgY29tcHJlc3Npb24sIGFuZCBpdCBjYW4gbWFr ZSB0aGUgbmV0d29yayBwcm9ncmFtbWluZyBtb2RlbCAoUkZDODk4NikgYmUgZWFzaWVyIHRvIGRl cGxveS4gQ1NJRCBpcyBqdXN0IGFkZGluZyB0aGUgbmV4dCBhbmQgcmVwbGFjZSBmbGF2b3JzIGFu ZCBzdGlsbCBtYWludGFpbiBhIHNpbmdsZSBTUnY2IGJhc2VkIGRhdGEgcGxhbmUuDQoNClRoYW5r cy4NCg0KR3VpeGluIEJhbw0KQmFpZHUgIE5ldHdvcmsgQ2hpZWYgQXJjaGl0ZWN0DQoNCuWPkeS7 tuS6ujogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4g5Luj6KGoIEphbWVzIEd1aWNo YXJkIDxqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20+DQrml6XmnJ86IDIwMjHlubQxMOac iDHml6Ug5pif5pyf5LqUIDIyOjA0DQrmlLbku7bkuro6IFNQUklORyBXRyA8c3ByaW5nQGlldGYu b3JnPg0K5oqE6YCBOiAic3ByaW5nLWNoYWlyc0BpZXRmLm9yZyIgPHNwcmluZy1jaGFpcnNAaWV0 Zi5vcmc+DQrkuLvpopg6IFtzcHJpbmddIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3Jo LWNvbXByZXNzaW9uLw0KDQpEZWFyIFdHOg0KDQpUaGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gZXhw cmVzcyB0aGVpciBhcHByZWNpYXRpb24gZm9yIGFsbCB0aGUgcmVzcG9uc2VzIHJlY2VpdmVkIHRv IG91ciBlbWFpbHMgd2l0aCByZWZlcmVuY2UgdG8gaG93IHRoZSB3b3JraW5nIGdyb3VwIHdpc2hl cyB0byBtb3ZlIGZvcndhcmQgd2l0aCByZXNwZWN0IHRvIGEgc29sdXRpb24gZm9yIFNSdjYgY29t cHJlc3Npb24uDQoNClRoZSBhcHBhcmVudCBpbmNsaW5hdGlvbiBvZiB0aGUgd29ya2luZyBncm91 cCBpcyB0byB1c2UgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2Zp bHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vIGFzIHRoZSBiYXNpcyBmb3IgaXRz IGNvbXByZXNzaW9uIHN0YW5kYXJkaXphdGlvbiB3b3JrLiBUaGF0IGlzIHBhcnQgb2Ygd2hhdCB0 aGlzIGVtYWlsIGF0dGVtcHRzIHRvIGNvbmZpcm0uDQoNCkJlY2F1c2Ugb2YgdGhlIGFib3ZlIHRo ZSBjaGFpcnMgd291bGQgbGlrZSB0byBpc3N1ZSBhIDItd2VlayBXRyBjYWxsIGZvciBhZG9wdGlv biBlbmRpbmcgT2N0b2JlciAxNXRoIGZvciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8gYnV0IHdp dGggc29tZSBjbGVhciBndWlkZWxpbmVzIGFzIGZvbGxvd3MuIEJ5IGV4cHJlc3Npbmcgc3VwcG9y dCBmb3IgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCB5b3UgYXJlIGZ1bGx5IGF3YXJlIG9mIGFu ZCBhcmUgYWNrbm93bGVkZ2luZyB0aGF0Og0KDQoNCiAgMS4gIFRoZSBTUFJJTkcgd29ya2luZyBn cm91cCBpcyBhZG9wdGluZyBhIGRvY3VtZW50IHRoYXQgaGFzIG11bHRpcGxlIFNSdjYgRW5kcG9p bnQgYmVoYXZpb3JzLg0KICAyLiAgVGhlIGRvY3VtZW50IGlzIGEg4oCcbGl2aW5n4oCdIGRvY3Vt ZW50OyBpdCBtYXkgY2hhbmdlIGFzIGl0IGdvZXMgdGhyb3VnaCByZXZpZXcgYW5kIGFuYWx5c2lz IGJ5IHRoZSBTUFJJTkcgd29ya2luZyBncm91cC4NCiAgMy4gIEFsbCBvcGVuIGRpc2N1c3Npb24g cG9pbnRzIHJhaXNlZCBvbiBvdXIgbWFpbGluZyBsaXN0IE1VU1QgYmUgYWRkcmVzc2VkIEJFRk9S RSBzYWlkIGRvY3VtZW50IGlzIGFsbG93ZWQgdG8gcHJvZ3Jlc3MgZnJvbSB0aGUgd29ya2luZyBn cm91cCB0byBwdWJsaWNhdGlvbi4gQSBsaXN0IG9mIHRoZXNlIGRpc2N1c3Npb24gcG9pbnRzIHdp bGwgYmUgZG9jdW1lbnRlZCBpbiB0aGUgV0cgZG9jdW1lbnQgYW5kIG1haW50YWluZWQgYnkgdGhl IGRvY3VtZW50IGVkaXRvciBpbiBjb25qdW5jdGlvbiB3aXRoIHRoZSBjaGFpcnMuDQogIDQuICBJ ZiB0aGlzIGRvY3VtZW50IGlzIGFkb3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAsIHRoZSBjaGFp cnMgc3BlY2lmeSBhcyBwYXJ0IG9mIHRoZSBhZG9wdGlvbiBjYWxsIHRoYXQgdGhlIGZvbGxvd2lu ZyB0ZXh0IGRlc2NyaWJpbmcgYW4gb3BlbiBpc3N1ZSBiZSBhZGRlZCB0byB0aGUgZG9jdW1lbnQg aW4gdGhlIGFib3ZlLWRlc2NyaWJlZCBvcGVuIGlzc3VlcyBzZWN0aW9uOg0KICAgICAqICAgIkdp dmVuIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHNhaWQgdGhhdCBpdCB3YW50cyB0byBzdGFu ZGFyZGl6ZSBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiwgYW5kIGdpdmVuIHRoYXQgdGhlIGRvY3Vt ZW50IGNvbnRhaW5zIG11bHRpcGxlIFNSdjYgRW5kUG9pbnQgYmVoYXZpb3JzIHRoYXQgc29tZSBX RyBtZW1iZXJzIGhhdmUgc3RhdGVkIGFyZSBtdWx0aXBsZSBkYXRhIHBsYW5lIHNvbHV0aW9ucywg dGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhZGRyZXNzIHdoZXRoZXIgdGhpcyBpcyB2YWxpZCBhbmQg Y29oZXJlbnQgd2l0aCBpdHMgb25lIGRhdGEgcGxhbmUgc29sdXRpb24gb2JqZWN0aXZlLiIuDQoN ClBsZWFzZSBjb25zaWRlciB0aGUgYWJvdmUgZ3VpZGVsaW5lcyBhcyB5b3UgZGVjaWRlIG9uIHdo ZXRoZXIgdG8gc3VwcG9ydCBvciBub3QgdGhpcyBXRyBhZG9wdGlvbi4gUGxlYXNlIGV4cHJlc3Mg Y2xlYXJseSB5b3VyIHJlYXNvbmluZyBmb3Igc3VwcG9ydC9ub24tc3VwcG9ydCBhcyB3ZWxsIGFz IGFueSBvcGVuIGRpc2N1c3Npb24gcG9pbnRzIHlvdSB3b3VsZCBsaWtlIGFkZHJlc3NlZCBzaG91 bGQgdGhlIGRvY3VtZW50IGJlIGFkb3B0ZWQgaW50byB0aGUgd29ya2luZyBncm91cC4NCg0KVGhh bmtzIQ0KDQpKaW0sIEJydW5vICYgSm9lbA0KDQoNCg== --_000_675D7B897CC444D281677C51382D7BC1baiducom_ Content-Type: text/html; charset="utf-8" Content-ID: <4DC2130DE1A9D8438F6472D4F5AD9F30@internal.baidu.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6MiAxIDYg MCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi XEDnrYnnur8iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxh aW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi57qv5paH 5pysIOWtl+espiI7DQoJbWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlz dFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0 Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRvbTow Y207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5hDQoJe21zby1zdHlsZS1uYW1lOiLnuq/m lofmnKwg5a2X56ymIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6 57qv5paH5pysOw0KCWZvbnQtZmFtaWx5OkRlbmdYaWFuO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkRlbmdYaWFuOw0K CWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5p dGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjc1MTY5OTM5MzsNCgltc28tbGlzdC10 eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTcyMTY1NDc3NiA2NzY5ODcwMyA2 NzY5ODY4OSA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5 ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4w cHQ7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZl bDQNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGww OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxOTQ1MDcxNjgwOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczoxMDUzMDQ0ODcwO30NCkBsaXN0IGwxOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFy Z2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9IiMw NTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpEZW5nWGlhbiI+SGks IERlYXIgV0c8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6RGVuZ1hp YW4iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpEZW5n WGlhbiI+SSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0Lg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkRlbmdYaWFuIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6RGVuZ1hpYW4iPkZyb20gdGhlIHVzZXIg cG9pbnQgb2YgdmlldywgSSB0aGluayB0aGUgQ1NJRCBwcm9wb3NlcyBhIGhpZ2hseSBlZmZpY2ll bnQgd2F5ICZuYnNwO2ZvciBTUnY2IGNvbXByZXNzaW9uLCBhbmQgaXQgY2FuIG1ha2UgdGhlIG5l dHdvcmsgcHJvZ3JhbW1pbmcgbW9kZWwgKFJGQzg5ODYpIGJlIGVhc2llciB0byBkZXBsb3kuDQog Q1NJRCBpcyBqdXN0IGFkZGluZyB0aGUgbmV4dCBhbmQgcmVwbGFjZSBmbGF2b3JzIGFuZCBzdGls bCBtYWludGFpbiBhIHNpbmdsZSBTUnY2IGJhc2VkIGRhdGEgcGxhbmUuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkRlbmdYaWFuIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6RGVuZ1hpYW4iPlRoYW5rcy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6RGVuZ1hpYW4iPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpEZW5nWGlhbiI+R3VpeGluIEJhbzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpEZW5nWGlhbiI+QmFpZHUg Jm5ic3A7TmV0d29yayBDaGllZiBBcmNoaXRlY3QmbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpEZW5nWGlhbiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVD NERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2Nv bG9yOmJsYWNrIj7lj5Hku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Og0KPC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPnNwcmluZyAmbHQ7 c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmJsYWNrIj7ku6Pooag8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4gSmFt ZXMgR3VpY2hhcmQgJmx0O2phbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbSZndDs8YnI+DQo8 L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L5L2T O2NvbG9yOmJsYWNrIj7ml6XmnJ88L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Og0KPC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjIwMjE8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmJs YWNrIj7lubQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2NvbG9yOmJsYWNrIj4xMDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTrlrovkvZM7Y29sb3I6YmxhY2siPuaciDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjE8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L5L2TO2NvbG9yOmJsYWNrIj7ml6U8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPg0KPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjpibGFj ayI+5pif5pyf5LqUPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+IDIyOjA0PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OuWui+S9kztjb2xvcjpibGFjayI+5pS25Lu25Lq6PC9z cGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29s b3I6YmxhY2siPjoNCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2NvbG9yOmJsYWNrIj5TUFJJTkcgV0cgJmx0O3NwcmluZ0BpZXRmLm9yZyZndDs8 YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 5a6L5L2TO2NvbG9yOmJsYWNrIj7mioTpgIE8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Og0KPC9zcGFuPjwvYj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZxdW90 O3NwcmluZy1jaGFpcnNAaWV0Zi5vcmcmcXVvdDsgJmx0O3NwcmluZy1jaGFpcnNAaWV0Zi5vcmcm Z3Q7PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OuWui+S9kztjb2xvcjpibGFjayI+5Li76aKYPC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPjoNCjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5b c3ByaW5nXSBXRyBBZG9wdGlvbiBjYWxsIGZvciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk65a6L 5L2TIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5EZWFyIFdHOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhl IGNoYWlycyB3b3VsZCBsaWtlIHRvIGV4cHJlc3MgdGhlaXIgYXBwcmVjaWF0aW9uIGZvciBhbGwg dGhlIHJlc3BvbnNlcyByZWNlaXZlZCB0byBvdXIgZW1haWxzIHdpdGggcmVmZXJlbmNlIHRvIGhv dyB0aGUgd29ya2luZyBncm91cCB3aXNoZXMgdG8gbW92ZSBmb3J3YXJkIHdpdGggcmVzcGVjdCB0 byBhIHNvbHV0aW9uIGZvciBTUnY2IGNvbXByZXNzaW9uLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5U aGUgYXBwYXJlbnQgaW5jbGluYXRpb24gb2YgdGhlIHdvcmtpbmcgZ3JvdXAgaXMgdG8gdXNlDQo8 YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2No ZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8iPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Np b24vPC9hPiBhcyB0aGUgYmFzaXMgZm9yIGl0cyBjb21wcmVzc2lvbiBzdGFuZGFyZGl6YXRpb24g d29yay4gVGhhdCBpcyBwYXJ0IG9mIHdoYXQgdGhpcyBlbWFpbCBhdHRlbXB0cyB0byBjb25maXJt LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+QmVjYXVzZSBvZiB0aGUgYWJvdmUgdGhlIGNoYWlycyB3b3Vs ZCBsaWtlIHRvIGlzc3VlIGEgMi13ZWVrIFdHIGNhbGwgZm9yIGFkb3B0aW9uIGVuZGluZyBPY3Rv YmVyIDE1PHN1cD50aDwvc3VwPiBmb3INCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9u LyI+DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5n LXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88L2E+IGJ1dCB3aXRoIHNvbWUgY2xlYXIgZ3Vp ZGVsaW5lcyBhcyBmb2xsb3dzLiBCeSBleHByZXNzaW5nIHN1cHBvcnQgZm9yIGFkb3B0aW9uIG9m IHRoaXMgZG9jdW1lbnQgeW91IGFyZSBmdWxseSBhd2FyZSBvZiBhbmQgYXJlIGFja25vd2xlZGdp bmcgdGhhdDoNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8b2wgc3R5bGU9 Im1hcmdpbi10b3A6MGNtIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMi PjxzcGFuIGxhbmc9IkVOLVVTIj5UaGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAgaXMgYWRvcHRpbmcg YSBkb2N1bWVudCB0aGF0IGhhcyBtdWx0aXBsZSBTUnY2IEVuZHBvaW50IGJlaGF2aW9ycy4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj48c3BhbiBsYW5nPSJFTi1V UyI+VGhlIGRvY3VtZW50IGlzIGEg4oCcbGl2aW5n4oCdIGRvY3VtZW50OyBpdCBtYXkgY2hhbmdl IGFzIGl0IGdvZXMgdGhyb3VnaCByZXZpZXcgYW5kIGFuYWx5c2lzIGJ5IHRoZSBTUFJJTkcgd29y a2luZyBncm91cC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj48 c3BhbiBsYW5nPSJFTi1VUyI+QWxsIG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgcmFpc2VkIG9uIG91 ciBtYWlsaW5nIGxpc3QgTVVTVCBiZSBhZGRyZXNzZWQgQkVGT1JFIHNhaWQgZG9jdW1lbnQgaXMg YWxsb3dlZCB0byBwcm9ncmVzcyBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIHRvIHB1YmxpY2F0aW9u LiBBIGxpc3QNCiBvZiB0aGVzZSBkaXNjdXNzaW9uIHBvaW50cyB3aWxsIGJlIGRvY3VtZW50ZWQg aW4gdGhlIFdHIGRvY3VtZW50IGFuZCBtYWludGFpbmVkIGJ5IHRoZSBkb2N1bWVudCBlZGl0b3Ig aW4gY29uanVuY3Rpb24gd2l0aCB0aGUgY2hhaXJzLg0KPG86cD48L286cD48L3NwYW4+PC9saT48 bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzMiPjxzcGFuIGxhbmc9IkVOLVVTIj5JZiB0aGlzIGRvY3VtZW50IGlz IGFkb3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAsIHRoZSBjaGFpcnMgc3BlY2lmeSBhcyBwYXJ0 IG9mIHRoZSBhZG9wdGlvbiBjYWxsIHRoYXQgdGhlIGZvbGxvd2luZyB0ZXh0IGRlc2NyaWJpbmcg YW4gb3BlbiBpc3N1ZSBiZSBhZGRlZCB0byB0aGUNCiBkb2N1bWVudCBpbiB0aGUgYWJvdmUtZGVz Y3JpYmVkIG9wZW4gaXNzdWVzIHNlY3Rpb246PG86cD48L286cD48L3NwYW4+DQo8dWwgc3R5bGU9 Im1hcmdpbi10b3A6MGNtIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBz dHlsZT0ibXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzMiPjxzcGFuIGxhbmc9IkVOLVVTIj4mcXVvdDtH aXZlbiB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBzYWlkIHRoYXQgaXQgd2FudHMgdG8gc3Rh bmRhcmRpemUgb25lIGRhdGEgcGxhbmUgc29sdXRpb24sIGFuZCBnaXZlbiB0aGF0IHRoZSBkb2N1 bWVudCBjb250YWlucyBtdWx0aXBsZSBTUnY2IEVuZFBvaW50IGJlaGF2aW9ycyB0aGF0IHNvbWUg V0cgbWVtYmVycw0KIGhhdmUgc3RhdGVkIGFyZSBtdWx0aXBsZSBkYXRhIHBsYW5lIHNvbHV0aW9u cywgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhZGRyZXNzIHdoZXRoZXIgdGhpcyBpcyB2YWxpZCBh bmQgY29oZXJlbnQgd2l0aCBpdHMgb25lIGRhdGEgcGxhbmUgc29sdXRpb24gb2JqZWN0aXZlLiZx dW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L2xpPjwvb2w+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPlBsZWFzZSBjb25zaWRl ciB0aGUgYWJvdmUgZ3VpZGVsaW5lcyBhcyB5b3UgZGVjaWRlIG9uIHdoZXRoZXIgdG8gc3VwcG9y dCBvciBub3QgdGhpcyBXRyBhZG9wdGlvbi4gUGxlYXNlIGV4cHJlc3MgY2xlYXJseSB5b3VyIHJl YXNvbmluZyBmb3Igc3VwcG9ydC9ub24tc3VwcG9ydCBhcyB3ZWxsIGFzIGFueSBvcGVuIGRpc2N1 c3Npb24gcG9pbnRzIHlvdSB3b3VsZCBsaWtlIGFkZHJlc3NlZA0KIHNob3VsZCB0aGUgZG9jdW1l bnQgYmUgYWRvcHRlZCBpbnRvIHRoZSB3b3JraW5nIGdyb3VwLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ VGhhbmtzITxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SmltLCBCcnVubyAmYW1wOyBKb2VsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_675D7B897CC444D281677C51382D7BC1baiducom_-- From nobody Fri Oct 15 01:18:27 2021 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 C80773A03FE for ; Thu, 14 Oct 2021 07:23:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.854 X-Spam-Level: X-Spam-Status: No, score=-0.854 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, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 Rx8LU1ioVAqO for ; Thu, 14 Oct 2021 07:22:56 -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 823413A09A7 for ; Thu, 14 Oct 2021 07:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquid.tech; s=mimecast20210406; t=1634221368; 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=A++eUarmOmpR0hIc/gLFAjv6r/Ev1ooAV47AkmDjS8c=; b=PdCatyENKh9NYgwKJR8yeea5WQLJpB2eVfQD/wvCYR627PxKf45psedLY8xH+Ya+yWI2n8 Y2J6dsftPj7mGp4pGSX44IhRl2LUTXmL0kdygBPRudrrUP4+DgkjhoctVC1Um3bWw9ngi9 1dzfTU/3s+l+Yg8ehCLzNm+c5fG2goU= Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-am5eur03lp2057.outbound.protection.outlook.com [104.47.8.57]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-223-zYK8z51kNX-VilF5eXZIEA-1; Thu, 14 Oct 2021 15:22:45 +0100 X-MC-Unique: zYK8z51kNX-VilF5eXZIEA-1 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com (2603:10a6:20b:346::6) by AS8PR03MB7540.eurprd03.prod.outlook.com (2603:10a6:20b:348::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.16; Thu, 14 Oct 2021 14:22:42 +0000 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9]) by AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9%7]) with mapi id 15.20.4608.016; Thu, 14 Oct 2021 14:22:42 +0000 From: Andrew Alston To: "Darren Dukes (ddukes)" , SPRING WG Thread-Topic: CSID proposed clarifications Thread-Index: AQHXwPmD76WD43ON70uWpO9ECDy+ZqvSilqw Date: Thu, 14 Oct 2021 14:22:42 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dfc1b0dc-6b08-41de-13ae-08d98f1e15ba x-ms-traffictypediagnostic: AS8PR03MB7540: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: uY6j/MW/mRcKDc02NwlX+iiF5H3aSgjsXmLQEzTPXyk9f/zMDj5WGio0Yt5heyi6bg5SmZcD0dLt4xspz8zBHFEc+egG29/1TNYVapz/JBN005Dcy4eoiP6kZGtu4MgIEchGDT7ji03u6Wk8hfH+CF2x7ap8omt0UQUFlq5MpZXOM7KZQ+Ebm/4gfSszxwh5SqSz8zTxO7p1L1dlWDU08W60vsP2gI2dJuJ5o+VBoP3sF5XqYxALQ7Yte0Z5Il/+OxBiQlZ3xWeX/9biOfssQRre/gLERErif7H8fnN11WOk+8B92CfNL4AiAY6fb/ZsuAAcU8z6FVJPqbIIaY0pBipgm+TJUDiyukebiqF0DOxCTsNByLYKxjD+iPA0EwXZ+y5dZJw2al6ykVOcXmt6pHzafNUmpj+dUG3UPCoEHnmFFPVm2ZJSMukXTQlrmU3S4Gm0ZN5xI+0Rq8UPt4PIfibNFi/2jnBX32rmFpvdUq/fRUpz2a38Z+VWa/AY27NyRQ7ASXibr57/9eXf6IJYtAH3a6+wefEM4/k4Cm/4pOUWvRMUU/nKTS1yrtFEXuasZJC9Y7Y2ms4WBk3XP2OagaqpLbs4LMw0V+c+pa+mkeOSRfzet0j6SwuFSHCfA02qm9BWjBh92dgm8Mhpji4LYpigA7aigHrWatA3pWE38oTiQ7DcBVwT5uydhQLyj2NUizhehIAV519McRyU0B1MM6EFEc2us12fMks0UyQqTmx8rH4M2jmPfRtbnW1vYiXhkVSPSulNAKw2cCCPa2Aqy4v1PX2xY4VbaRcELO0qEgeKj1C7veBW5YF5hDgnNUzqLkyypTb0/0Mehm0RFewm6w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR03MB7622.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(8676002)(7116003)(76116006)(3480700007)(38070700005)(166002)(508600001)(33656002)(71200400001)(55016002)(186003)(66446008)(9686003)(52536014)(5660300002)(86362001)(66946007)(66476007)(38100700002)(316002)(122000001)(83380400001)(64756008)(2906002)(7696005)(53546011)(6506007)(66556008)(8936002)(110136005); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?lf9Sq5qHK+bVWVaG8IluY13pEeY8CVNwhS3DFpC58BSMRuamR0HDfSvJHskf?= =?us-ascii?Q?ACSvyAF8CD8XlaVumZeKizVsMIPn+6qsbYq+vmidivJtMdPGcY5ticgAfJk3?= =?us-ascii?Q?TtovJM9G4LP/NWbQEx5ZWvsT78b5QpmNaigfU4BG/DKfxdQuA/0sKNl4kfhy?= =?us-ascii?Q?ZS/iEU3hDxnR4Nm5MPwTBzIcn5d/9yiI673HjeHtjFaWclmY656D2IUp7yyO?= =?us-ascii?Q?/TScth47CAskNvQ6nWsh9/dOtsWwqs0vQwT9hOj054f4S5bxWz2LQ49Jald8?= =?us-ascii?Q?Bj7sZMblD5h0A39K8FS+TRRnN/Q+xM6L7Na9WgeoHcR07h+46ThYC/LvONx+?= =?us-ascii?Q?J9T1FVLxQ9n+AamTCFVdHxTm0Avr86zr2e+Tg3fcpAaEBu7dAwMzA36HSamu?= =?us-ascii?Q?+zWaBFDqQsQa9bFWjJVGvKSy6pt8azlE9Wet2vdb2xjLuRtON1jnQismcWRN?= =?us-ascii?Q?xtx5awPdJWMwAJJ0dICW49v2NcpW1F0kYObnoA/x7WC7LqtKks69DfMbRDj4?= =?us-ascii?Q?qtEt5coZUbjngaKNeNpvEFOA6FS/Z6xW+NjOKSFdDQgCxkl+C7cNkO9reQW/?= =?us-ascii?Q?VVvta7FMLAcjTp0H8foRDxMxuFskogq4TkuVCPkZEdbsXPLxGpXWBd8VAhjl?= =?us-ascii?Q?sScmQfxZRvcvTqiKafA5RjulP3eTcH97R5iyxeMMIWsCW5wrvbx3QOHyb9uA?= =?us-ascii?Q?bbvp09ipHMRxJ51akUba64VqGx54waYq7i9jXLClWJxPaWTcMiL+R2gFvE1+?= =?us-ascii?Q?SlcSYwoWe2E6xzImm0173DIF31uP8osJQ8yWMf3MRseQpBjDsvxlDJmczpO/?= =?us-ascii?Q?1snb5meOaiRgUWxmuh+IN0WVgm3Dz6Ufh2TYN3j4U38WPcqWZooO2db44F03?= =?us-ascii?Q?Gx9Snot+x47CnFJHydwaYG+7e1N8VoygApccerEQGDogX2v2qNa48vDq5+xO?= =?us-ascii?Q?eFo8E5ipHhXldI68UXl13wkLdvB4bc47yswAo277RMd5YGEJSevLIr5o6EfY?= =?us-ascii?Q?eezSONEU6+vl2epSOvuYCsMZLY9b7EC2bT54IcmKMpoOLLe2pGeGqBIHW7qn?= =?us-ascii?Q?NBuFg9xzjZtlP3Wn6jT9G9/BF3jkozumrrSBnu5ynwxCrE269EZ/27JCWFRa?= =?us-ascii?Q?FXAhACmC01CLPbZndG5M7wBA4SXU1cFMyUVBDcm+14scOwKNbDx/3znr8aNM?= =?us-ascii?Q?BR3YPOIMWfHO775OTItWgaidFx3hkYvhfvq336R3u7v3M98tNRinZ/lqaXsG?= =?us-ascii?Q?gY4enXejEP9qUmiEpDuGAElVvVa8tRQ5GvCf2lXSTeQTFLCBBhpzOqiFGQ9D?= =?us-ascii?Q?nliy7ugibxZIDToRidHlvivTBhIwhafPkrMbE4ofvEUKLbRGYwN0roPP/qX2?= =?us-ascii?Q?BWIj1os=3D?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquid.tech X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB7622.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: dfc1b0dc-6b08-41de-13ae-08d98f1e15ba X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2021 14:22:42.4638 (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: 8welB4q3FbZzJ4BoxM1+i39c8UVmCBD1B4lfSWdzp2c3r+SG3R/PBgIAFzadgI7S28wcW59mruKKMqI0GpM62CvGHGO35n/gycDea/109ho= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7540 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquid.tech X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquid.tech Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_AS8PR03MB7622768FD4B8B4D3D519078CECB89AS8PR03MB7622eurp_" Archived-At: X-Mailman-Approved-At: Fri, 15 Oct 2021 01:17:52 -0700 Subject: Re: [spring] CSID proposed clarifications 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, 14 Oct 2021 14:23:02 -0000 --_000_AS8PR03MB7622768FD4B8B4D3D519078CECB89AS8PR03MB7622eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Darren, I'm a little confused here reading this - but all said and done - on the ne= xt behavior - how is this different from doing something along the lines of Da[loc_bits/8] << sid_size Because - when I trace this all out into actual C code - that's pretty much= what it seems to summarize down to - more specifically - it could be done = something like this: (taking out all the comparisons and error checking) __m128i vec; __u8 output[16]; vec =3D __mm_loadl_epi64((void *)da[loc_size/8]) if(sid_size =3D=3D 16) { vec =3D _mm_bsrli_si128(vec, 2) } else { vec =3D _mm_bsrli_si128(vec, 4) } _mm_store_u_si128((__m128i*)output, vec); memcpy(da[loc_size/8], output, 16-(loc_size/8)); (think I got that pretty much right) Andrew From: spring On Behalf Of Darren Dukes (ddukes) Sent: Thursday, October 14, 2021 3:54 PM To: SPRING WG Subject: [spring] CSID proposed clarifications The NEXT-C-SID and REPLACE-C-SID flavors are functionally very similar. In both cases the SID in the IPv6 Destination Address (DA) contains an argu= ment, that argument is used to construct the next SID from the active segment in the SRH Segment List. I believe the following pseudocode is a much better description of their segment endpoint processing. You'll notice there is no manipulation of the bits in the IPv6 DA. I propose we replace the pseudocode in the draft with the following, stand-alone pseudocode, for the NEXT-C-SID and REPLACE-C-SID flavors of the END behavior (sections 4.1.1 and 4.2.1 respectively). Equivalent changes can be completed for the NEXT-C-SID and REPLACE-C-SID flavors of the END.X behavior (sections 4.1.2 and 4.2.2 respectively) and NEXT-AND-REPLACE-C-SID flavor. Comments are appreciated. Thanks Darren 4.1.1. End with NEXT-C-SID When processing an IPv6 packet that matches a FIB entry locally instantiated as an End SID with the NEXT-C-SID flavor, the SRH processing described in Section 4.1 of [RFC8986] is replaced as follows. S.01 When an SRH is processed { S.02 If (IPv6.DA.Argument =3D=3D 0 and SRH.SegmentsLeft =3D=3D 0) { S.03 Stop processing the SRH, and proceed to process the next header in the packet, whose type is identified by the Next Header field in the routing header. S.04 } S.05 If (IPv6.HopLimit <=3D 1) { S.06 Send an ICMP Time Exceeded message to the Source Address with Code 0 (Hop limit exceeded in transit), interrupt packet processing, and discard the packet. S.07 } S.08 # Determine the maximum SRH Last Entry S.09 Set maxLE to ((SRH.HdrExtLen / 2) - 1) S.10 Initialize 128-bit buffer memory S to 0. S.11 Initialize local parameter Argument to the value of IPv6.DA.Argument S.12 If (Argument =3D=3D 0) { S.13 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)= ) { S.14 Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S.15 } S.16 Decrement SRH.SegmentsLeft by 1 S.17 Set S to the value of SRH.SegmentList[SRH.SegmentsLeft] S.18 } S.19 Else { S.20 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)= ) { S.21 Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S.22 } S.23 Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common loc= ator block) S.24 If (SRH.SegmentsLeft > SRH.LastEntry) { S.25 Initialize local parameter ActiveSegment to the value of DA S.26 } S.27 Else { S.28 Initialize local parameter ActiveSegment to the value S.29 of SRH.SegmentList[SRH.SegmentsLeft] S.30 } S.31 Initialize local parameter BitLength to (CountTrailingZeros(ActiveS= egment) + AL - CountTrailingZeros(A= rgument)) S.32 Initialize local parameter BitIndex to (128 - BitLength) S.33 Set S[B..B+BitLength-1] to the value of ActiveSegment[BitIndex..(BitIndex+BitLength-1)] S.34 } S.35 Set IPv6.DA to the value of S S.36 Decrement IPv6.HopLimit by 1 S.37 Submit the packet to the egress IPv6 FIB lookup for transmission to the new destination. S.38 } 4.1.1.1 Upper layer header processing The upper-layer header processing described in Section 4.1.1 of [RFC8986] is replaced as follows. S.01 Initialize local parameter Argument to the value of IPv6.DA.Argument S.02 If (Argument !=3D 0) { # In this case, the SRH was not added by source # The source compressed it into the active segment in IPv6.DA # Build a pseudo header from the active segment in the IPv6.DA for = use # during processing. S.03 Initialize a 24-byte local SRH in memory to 0's for use below S.04 Set SRH.MaxHdrLen to 3 S.05 Set SRH.RoutingType to 4 S.06 Set SRH.SegmentsLeft to 0 S.07 Set SRH.SegmentList[0] to the value of IPv6.DA S.08 Process the SRH as per section 4.1.1, S.09 noting such processing is limited to the pseudo SRH S.10 since Argument is not 0. S.11 } S.12 If (Upper-Layer header type is allowed by local configuration) { S.13 Proceed to process the Upper-Layer header S.14 } Else { S.15 Send an ICMP Parameter Problem to the Source Address with Code 4 (SR Upper-layer Header Error) and Pointer set to the offset of the Upper-Layer header, interrupt packet processing, and discard the packet. S.16 } 4.2.1. End with REPLACE-C-SID When processing an IPv6 packet that matches a FIB entry locally instantiated as an End SID with the REPLACE-C-SID flavor, the SRH processing described in Section 4.1 of [RFC8986] is replaced as follows. S.01 When an SRH is processed { S.02 If (IPv6.DA.Argument =3D=3D 0 and SRH.SegmentsLeft =3D=3D 0) { S.03 Stop processing the SRH, and proceed to process the next header in the packet, whose type is identified by the Next Header field in the routing header. S.04 } S.05 If (IPv6.HopLimit <=3D 1) { S.06 Send an ICMP Time Exceeded message to the Source Address with Code 0 (Hop limit exceeded in transit), interrupt packet processing, and discard the packet. S.07 } S.08 # Determine the maximum SRH Last Entry S.09 Set maxLE to ((SRH.HdrExtLen / 2) - 1) S.10 Initialize 128-bit buffer memory S to 0. S.11 Initialize local parameter Argument to the value of IPv6.DA.Argument S.12 Initialize local parameter ActiveSegment to SRH.SegmentList[SRH.Segme= ntsLeft] S.13 If (Argument =3D=3D 0) { S.14 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)= ) { S.15 Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S.16 } S.17 Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common loc= ator block) S.18 Decrement SRH.SegmentsLeft by 1 S.19 Set Argument to (128 / NF - 1) S.20 } S.21 Else { S.22 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry)) = { S.23 Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S.24 } S.25 Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common loc= ator block) S.26 Decrement Argument by 1 S.27 } S.28 Initialize local parameter BitLength to the value of NF S.29 Initialize local parameter BitIndex to (Argument * NF) S.30 Set S[B..B+BitLength-1] to the value of ActiveSegment[BitIndex..(BitIndex+BitLength-1)] S.32 Set S[B+BitLength..B+BitLength+A-1] to the value of Argument S.33 Set IPv6.DA to the value of S S.34 Decrement IPv6.HopLimit by 1 S.35 Submit the packet to the egress IPv6 FIB lookup for transmission S.36 to the new destination. S.37 } 4.2.1.1. Upper layer header processing The upper-layer header processing described in Section 4.1.1 of [RFC8986] i= s unchanged and reproduced below. S.01 If (Upper-Layer header type is allowed by local configuration) { S.02 Proceed to process the Upper-Layer header S.03 } Else { S.04 Send an ICMP Parameter Problem to the Source Address with Code 4 (SR Upper-layer Header Error) and Pointer set to the offset of the Upper-Layer header, interrupt packet processing, and discard the packet. S.05 } --_000_AS8PR03MB7622768FD4B8B4D3D519078CECB89AS8PR03MB7622eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

    Darren,<= /span>

     

    I’m a little = confused here reading this – but all said and done – on the nex= t behavior – how is this different from doing something along the lin= es of

     

    Da[loc_bits/8] <= < sid_size

     

    Because – whe= n I trace this all out into actual C code – that’s pretty much = what it seems to summarize down to – more specifically – it cou= ld be done something like this:

     

    (taking out all the= comparisons and error checking)

     

    __m128i vec;

    __u8 output[16];=

     

    vec =3D __mm_loa= dl_epi64((void *)da[loc_size/8])

    if(sid_size =3D= =3D 16) {

      &nbs= p;           vec =3D _mm_= bsrli_si128(vec, 2)

    } else {

      &nbs= p;           vec =3D _mm_= bsrli_si128(vec, 4)

    }

    _mm_store_u_si12= 8((__m128i*)output, vec);

    memcpy(da[loc_si= ze/8], output, 16-(loc_size/8));

     

    (think I got that p= retty much right)

     

    Andrew

     

    From:= spring <spring-bounces@ietf.org> On Behalf Of Darren Dukes (ddukes)
    Sent: Thursday, October 14, 2021 3:54 PM
    To: SPRING WG <spring@ietf.org>
    Subject: [spring] CSID proposed clarifications

     

    The NEXT-C-SID and REPLACE-C-SID flavors are functionally = very similar.

    In both cases the SID in the IPv6 Destination Address (DA)= contains an argument,

    that argument is used to construct the next SID from the a= ctive segment in

    the SRH Segment List.

     

    I believe the following pseudocode is a much better descri= ption of their

    segment endpoint processing. You’ll notice there is = no manipulation of

    the bits in the IPv6 DA.

     

    I propose we replace the pseudocode in the draft with the = following,

    stand-alone pseudocode, for the NEXT-C-SID and REPLACE-C-S= ID flavors

    of the END behavior (sections 4.1.1 and 4.2.1 respectively= ).

     

    Equivalent changes can be completed for the NEXT-C-SID and= REPLACE-C-SID

    flavors of the END.X behavior (sections 4.1.2 and 4.2.2 re= spectively) and

    NEXT-AND-REPLACE-C-SID flavor.

     

    Comments are appreciated.

     

    Thanks

      Darren

     

    4.1.1.  End with NEXT-C-SID<= /p>

     

    When processing an IPv6 packet that matches a FIB entry lo= cally

    instantiated as an End SID with the NEXT-C-SID flavor, the= SRH

    processing described in Section 4.1 of [RFC8986] is replac= ed as

    follows.

     

     

    S.01 When an SRH is processed {

    S.02  If (IPv6.DA.Argument =3D=3D 0 and SRH.SegmentsL= eft =3D=3D 0) {

    S.03     Stop processing the SRH, and = proceed to process the next

             header in= the packet, whose type is identified by

             the Next = Header field in the routing header.

    S.04  }

     

    S.05  If (IPv6.HopLimit <=3D 1) {

    S.06     Send an ICMP Time Exceeded me= ssage to the Source Address

             with Code= 0 (Hop limit exceeded in transit),

             interrupt= packet processing, and discard the packet.

    S.07  }

     

    S.08  # Determine the maximum SRH Last Entry

    S.09  Set maxLE to ((SRH.HdrExtLen / 2) - 1)

     

    S.10  Initialize 128-bit buffer memory S to 0.

    S.11  Initialize local parameter Argument to the valu= e of IPv6.DA.Argument

     

    S.12  If (Argument =3D=3D 0) {

    S.13    If ((SRH.LastEntry > maxLE) or (= SRH.SegmentsLeft > SRH.LastEntry+1)) {

    S.14      Send an ICMP Parameter = Problem to the Source Address

             &nbs= p; with Code 0 (Erroneous header field encountered)

             &nbs= p; and Pointer set to the Segments Left field,

             &nbs= p; interrupt packet processing, and discard the packet.

    S.15    }

     

    S.16    Decrement SRH.SegmentsLeft by 1

     

    S.17    Set S to the value of SRH.SegmentLi= st[SRH.SegmentsLeft]

    S.18  }

    S.19  Else {

    S.20    If ((SRH.LastEntry > maxLE) or (= SRH.SegmentsLeft > SRH.LastEntry+1)) {

    S.21      Send an ICMP Parameter = Problem to the Source Address

             &nbs= p;with Code 0 (Erroneous header field encountered)

             &nbs= p; and Pointer set to the Segments Left field,

             &nbs= p; interrupt packet processing, and discard the packet.

    S.22    }

     

    S.23    Set S[0..B-1] to the value of IPv6.= DA[0..B-1] (i.e., the common locator block)

     

    S.24    If (SRH.SegmentsLeft > SRH.LastE= ntry) {

    S.25      Initialize local parame= ter ActiveSegment to the value of DA

    S.26    }

    S.27    Else {

    S.28      Initialize local parame= ter ActiveSegment to the value

    S.29       of SRH.SegmentLis= t[SRH.SegmentsLeft]

    S.30    }

     

    S.31    Initialize local parameter BitLengt= h to (CountTrailingZeros(ActiveSegment) +

             &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  AL - CountTrailingZeros(Argument))

    S.32    Initialize local parameter BitIndex= to (128 – BitLength)

     

    S.33    Set S[B..B+BitLength-1] to the valu= e of

             Acti= veSegment[BitIndex..(BitIndex+BitLength-1)]

    S.34  }

     

    S.35  Set IPv6.DA to the value of S=

     

    S.36  Decrement IPv6.HopLimit by 1<= /p>

     

    S.37  Submit the packet to the egress IPv6 FIB lookup= for transmission

           to the new destinatio= n.

    S.38 }

     

    4.1.1.1 Upper layer head= er processing

     

    The upper-layer header processing described in Section 4.1= .1 of

    [RFC8986] is replaced as follows.

     

    S.01  Initialize local parameter Argument to the valu= e of IPv6.DA.Argument

    S.02  If (Argument !=3D 0) {

            # In this case,= the SRH was not added by source

            # The sour= ce compressed it into the active segment in IPv6.DA

            # Build a = pseudo header from the active segment in the IPv6.DA for use

          # during processing.

    S.03    Initialize a 24-byte local SRH in m= emory to 0’s for use below

    S.04    Set SRH.MaxHdrLen to 3

    S.05    Set SRH.RoutingType to 4=

    S.06    Set SRH.SegmentsLeft to 0

    S.07    Set SRH.SegmentList[0] to the value= of IPv6.DA

     

    S.08    Process the SRH as per section 4.1.= 1,

    S.09     noting such processing is lim= ited to the pseudo SRH

    S.10     since Argument is not 0.=

    S.11  }

     

    S.12  If (Upper-Layer header type is allowed by local= configuration) {

    S.13    Proceed to process the Upper-Layer = header

    S.14  } Else {

    S.15    Send an ICMP Parameter Problem to t= he Source Address

             with Code= 4 (SR Upper-layer Header Error)

             and Point= er set to the offset of the Upper-Layer header,

             interrupt= packet processing, and discard the packet.

    S.16  }

     

     

     

    4.2.1.  End with REPLACE-C-SID

     

    When processing an IPv6 packet that matches a FIB entry lo= cally

    instantiated as an End SID with the REPLACE-C-SID flavor, = the SRH

    processing described in Section 4.1 of [RFC8986] is replac= ed as

    follows.

     

    S.01 When an SRH is processed {

    S.02  If (IPv6.DA.Argument =3D=3D 0 and SRH.SegmentsL= eft =3D=3D 0) {

    S.03    Stop processing the SRH, and procee= d to process the next

            header in the p= acket, whose type is identified by

            the Next Header= field in the routing header.

    S.04  }

     

    S.05  If (IPv6.HopLimit <=3D 1) {

    S.06    Send an ICMP Time Exceeded message = to the Source Address

            with Code 0 (Ho= p limit exceeded in transit),

            interrupt packe= t processing, and discard the packet.

    S.07  }

     

    S.08  # Determine the maximum SRH Last Entry

    S.09  Set maxLE to ((SRH.HdrExtLen / 2) - 1)

     

    S.10  Initialize 128-bit buffer memory S to 0.

    S.11  Initialize local parameter Argument to the valu= e of IPv6.DA.Argument

    S.12  Initialize local parameter ActiveSegment to SRH= .SegmentList[SRH.SegmentsLeft]

     

    S.13  If (Argument =3D=3D 0) {

    S.14    If ((SRH.LastEntry > maxLE) or (= SRH.SegmentsLeft > SRH.LastEntry+1)) {

    S.15      Send an ICMP Parameter = Problem to the Source Address

              wit= h Code 0 (Erroneous header field encountered)

              and= Pointer set to the Segments Left field,

              int= errupt packet processing, and discard the packet.

    S.16    }

     

    S.17    Set S[0..B-1] to the value of IPv6.= DA[0..B-1] (i.e., the common locator block)

     

    S.18    Decrement SRH.SegmentsLeft by 1

     

    S.19    Set Argument to (128 / NF - 1)=

    S.20  }

    S.21  Else {

    S.22    If ((SRH.LastEntry > maxLE) or (= SRH.SegmentsLeft > SRH.LastEntry)) {

    S.23      Send an ICMP Parameter = Problem to the Source Address

              wit= h Code 0 (Erroneous header field encountered)

              and= Pointer set to the Segments Left field,

              int= errupt packet processing, and discard the packet.

    S.24    }

     

    S.25    Set S[0..B-1] to the value of IPv6.= DA[0..B-1] (i.e., the common locator block)

     

    S.26    Decrement Argument by 1<= /span>

    S.27  }

     

    S.28  Initialize local parameter BitLength to the val= ue of NF

    S.29  Initialize local parameter BitIndex to (Argumen= t * NF)

     

    S.30  Set S[B..B+BitLength-1] to the value of

           ActiveSegment[BitInde= x..(BitIndex+BitLength-1)]

    S.32  Set S[B+BitLength..B+BitLength+A-1] to the valu= e of Argument

     

    S.33  Set IPv6.DA to the value of S=

     

    S.34  Decrement IPv6.HopLimit by 1<= /p>

     

    S.35  Submit the packet to the egress IPv6 FIB lookup= for transmission

    S.36   to the new destination.=

    S.37 }

     

    4.2.1.1.  Upper lay= er header processing

     

    The upper-layer header processing described in Section 4.1= .1 of [RFC8986] is unchanged and reproduced below.

     

    S.01  If (Upper-Layer header type is allowed by local= configuration) {

    S.02    Proceed to process the Upper-Layer = header

    S.03  } Else {

    S.04    Send an ICMP Parameter Problem to t= he Source Address

            with Code 4 (SR= Upper-layer Header Error)

            and Pointer set= to the offset of the Upper-Layer header,

            interrupt packe= t processing, and discard the packet.

    S.05  }

     

     

     

    --_000_AS8PR03MB7622768FD4B8B4D3D519078CECB89AS8PR03MB7622eurp_-- From nobody Fri Oct 15 01:18:32 2021 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 867DA3A09EC for ; Thu, 14 Oct 2021 07:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.854 X-Spam-Level: X-Spam-Status: No, score=-0.854 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, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 QhnvghTWYzhd for ; Thu, 14 Oct 2021 07:34:02 -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 7677C3A08F9 for ; Thu, 14 Oct 2021 07:34:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquid.tech; s=mimecast20210406; t=1634222038; 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=d2xkoaDHKwUIh+kyo7NivtZROvm/qVs2UcXHeAQcMxQ=; b=eqGQm86iFnWiLAkFWbwYiWHjIUVV8k3DCFQC01EV6xJEWCEXIZ/NtOLd/MeeYf0iZu7eAA P24+O/DsDUfXcX796/wsAMWxkKyevwUQ1B5MCTsdB7YDr3aepGoX3oH7yzSssiIysD95P5 uAVqolLT/PS0P1UuhyvxjtO3unQ3NiE= Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03lp2054.outbound.protection.outlook.com [104.47.9.54]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-147-8JK7CYPROeqT5hRnAVmjKg-1; Thu, 14 Oct 2021 15:33:54 +0100 X-MC-Unique: 8JK7CYPROeqT5hRnAVmjKg-1 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com (2603:10a6:20b:346::6) by AS8PR03MB7970.eurprd03.prod.outlook.com (2603:10a6:20b:427::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.16; Thu, 14 Oct 2021 14:33:52 +0000 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9]) by AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9%7]) with mapi id 15.20.4608.016; Thu, 14 Oct 2021 14:33:52 +0000 From: Andrew Alston To: "Darren Dukes (ddukes)" , SPRING WG Thread-Topic: CSID proposed clarifications Thread-Index: AQHXwPmD76WD43ON70uWpO9ECDy+ZqvSjuoA Date: Thu, 14 Oct 2021 14:33:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1580b034-bd5c-456f-e08d-08d98f1fa50c x-ms-traffictypediagnostic: AS8PR03MB7970: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: FQ5Pz5Gkxm5WXQibL8+nXLwpT1aJm1Rt99NB1SXzBw43mor/UFQUZVxnOXWlMpcawC0m5lZIl5yVOMRYORNz9dZI4+FbIskvHHJfFd+wGgKOlbwGLYn/fUMI72MYfNJidNdXsPBn7MU301amliTZgmKk5VEzCYNFz00Wj9wFUpEavQ+aLD38qmeA5LMOzogone2MDKUydcpwXtch4NPSLdGtdACI39gO8lxpmafqcVj2FzV5BiDPhJs3mr3KEIjKu5CveSIfVDQhuiLWiDDLcYGJT0g9f8lRcKshon4of0LSc7wMpnFToh1YaKRPh5jI5V9OTYr7eahe4ERRjC5hJysaufeXWvM5xYikpWWgmZioBa9cT4TZlCChblH42+1Bcm4Pfgv8w3z1znkex7g2HPdDJPbLCTXi0ss29Z0dDcWzaPfzCDO7jvFA6fNhijJMjI9W9jK3Ek2rdAXMC1gjSms9HG2mKzZ1u4wHl9ge3eXkq8fTv/egAF5FwLo9V+Piedlf9Am2bKfVba6KWoi/Kgkbk/wn3VdkQYQDjQRhmUb8vKXfnV6ZyexmMB8i3WLL1tOg6uOJXeB1NblUnkAOlxpGc2XNPqMnukphbVbMK+3Z9/kk8hA/e71jB//waOMgHdRs6OK2+AG9wIbuHevV323D6HFVFmEEAY8+bEuSP+5Z/Pij0ABUaVB76TqJEL7HbSikSxPnFlQdEWKxlCXeTXxlOV5CSuG2kt5iTw2QCdgnOj43TCdJF8xg4vUejjlq+uZCvWGie+NdVp8ZFJp/sHkiBoFzNbdGeIwtd36/T0QJwl7JJtYumqgZXwEeAx+IbyfOj3CvQZsiW+ZdeZLzxg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR03MB7622.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(64756008)(66946007)(76116006)(66476007)(66556008)(52536014)(66446008)(9686003)(5660300002)(186003)(55016002)(83380400001)(71200400001)(8676002)(2906002)(166002)(8936002)(38070700005)(86362001)(53546011)(110136005)(38100700002)(508600001)(316002)(122000001)(6506007)(7116003)(7696005)(33656002)(3480700007); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?5mIiXGHiCuwnYkaa/GFOuDZxYpt6+Wwc3TrUP1YieCKkFUXZdhdck2O+DsS6?= =?us-ascii?Q?lle4kNJIZpEIl2accu3p3Pspx7O8VqYIYLT0T3Z1X4NZ8nCsQEAwIny2yata?= =?us-ascii?Q?vk+DUyelFcSupIOEUo3aNAgyNUjyE2E7K/OJHZkanN7JJ4jxHauFvjMi7dMx?= =?us-ascii?Q?RPSWYpf9I3fKXpZjpwt2KG1rlIo43s/GEHW6gN788kiUMXs3i9mdNxnQwESu?= =?us-ascii?Q?x+W15pMGln3+cs3SLjg5mf0eW52yKQ95q9uAhx+GeEIQcmrwS6gYQigYVzV6?= =?us-ascii?Q?lfmD2+ciNWGNVkeeUmxeljKfOOWqL8mviWQupE+CknvcyVyVe8K5XJ0rMKQp?= =?us-ascii?Q?k3FrLZb7LXYWpPhbkterC5cYm33FPCapmAYrYv51x91rF98X5+KMGGrcbpx8?= =?us-ascii?Q?fUxhA5oepPmRAeuN3hqjfO3R+lgFEEzPLnfD1XAlonPDSGAfHWJGXszYgyKY?= =?us-ascii?Q?ly9vXuAKZ7yBPa358F18UMuk/L3CekXmqC2zDIK+L3DL/NFLUfqr61pEhylb?= =?us-ascii?Q?JcXAnJnXnJxaWDDsrZTtJJFGZIxq6u9Y1DmaNlZfuvySCL9DU5IiqfnIbMAp?= =?us-ascii?Q?Y6fy9hvolFzt6mI945luH4NvHZuIHQAZ5CPpPcMWIioiLEYC0RwxYSccWr+b?= =?us-ascii?Q?hWJG+YjAaoRD/cO4ka1UfhuL1gGLMeED8vIA0x4ahmF897XR7RbWqDL8/IMd?= =?us-ascii?Q?VxvPUnWnkwM8bpURHO9rq6aumsydCFH6wibx4m0btiImaBzGZIv52mMdz/rG?= =?us-ascii?Q?/qU8MJnS7y1jovLQ/cczOhEkefysUtvhVvaBq3QUvStmxliBFIWP9a08vmDG?= =?us-ascii?Q?72WAwd3p9Tj4BC/xPZHSTqlc/dvkCugUPA1WKzKlTa25oOtXcDaDbt+/ShF8?= =?us-ascii?Q?nc6QlGyEAHPO+PuMcRoWoKdVCZbv1QsVnqB3kBS7WaZ0sEhTqfJgsA3MK7N5?= =?us-ascii?Q?9Ymdd5c5i41ZUyt/IdTEBHuIHXNjHvK4NyFcS7saxnNWnOrOZIrjrcBBNWUb?= =?us-ascii?Q?jOv46AqWyWq6s7OwsYbWHCwDSqAKixKzvSOLqvBKJlB/YJmqBfq4SFFYhG4I?= =?us-ascii?Q?hGI7hvh6+WoiQcW9KOonQNZUmzEtPcr7NRvHc7fGQ4FVowCt49a6Yfm1xjjo?= =?us-ascii?Q?fozJIMEF3qensoSvT+gqaJtFMBylqcHQN1R7mnoUjUiSmcfNjOb8WGBiGbt4?= =?us-ascii?Q?6nHk1v2YHa1r6VJYn0he35qcv5+WIdk2M6W6n0jnXnRrQYs23iJg2fQviKCu?= =?us-ascii?Q?nW2pb+YgwsnN0Cz+IoBcLCzeH0UVyyDLSRWkTsERFz5hn5JAOV6eFpzjdx8t?= =?us-ascii?Q?4hGTFQ2xYmHDRFcTI8GJgEMgp0ZmpOXPd5I7WIwq/EcIv1s5teDG3YOIt2r3?= =?us-ascii?Q?NvZ/0PI=3D?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquid.tech X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB7622.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1580b034-bd5c-456f-e08d-08d98f1fa50c X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2021 14:33:52.4234 (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: u18ry/SgXXuq7/l2pLegiwBWWwFcBjV7b6EOJ9NbHUvWwkF+1MGNghDvKEusOWti4LBKWVMAeLcXFBi8gvs+f7AGgZV6KUmdO86oxAxv5U4= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7970 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquid.tech X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquid.tech Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_AS8PR03MB7622B60021ECF2ABA7A5E20EEEB89AS8PR03MB7622eurp_" Archived-At: X-Mailman-Approved-At: Fri, 15 Oct 2021 01:17:52 -0700 Subject: Re: [spring] CSID proposed clarifications 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, 14 Oct 2021 14:34:09 -0000 --_000_AS8PR03MB7622B60021ECF2ABA7A5E20EEEB89AS8PR03MB7622eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable (Apologies if this appears twice - seems something went screwy with my outb= ound address so the other version of this is moderated) Darren, I'm a little confused here reading this - but all said and done - on the ne= xt behavior - how is this different from doing something along the lines of Da[loc_bits/8] << sid_size Because - when I trace this all out into actual C code - that's pretty much= what it seems to summarize down to - more specifically - it could be done = something like this: (taking out all the comparisons and error checking) __m128i vec; __u8 output[16]; vec =3D __mm_loadl_epi64((void *)da[loc_size/8]) if(sid_size =3D=3D 16) { vec =3D _mm_bsrli_si128(vec, 2) } else { vec =3D _mm_bsrli_si128(vec, 4) } _mm_store_u_si128((__m128i*)output, vec); memcpy(da[loc_size/8], output, 16-(loc_size/8)); (think I got that pretty much right) Andrew From: spring On Behalf Of Darren Dukes (ddukes) Sent: Thursday, October 14, 2021 3:54 PM To: SPRING WG Subject: [spring] CSID proposed clarifications The NEXT-C-SID and REPLACE-C-SID flavors are functionally very similar. In both cases the SID in the IPv6 Destination Address (DA) contains an argu= ment, that argument is used to construct the next SID from the active segment in the SRH Segment List. I believe the following pseudocode is a much better description of their segment endpoint processing. You'll notice there is no manipulation of the bits in the IPv6 DA. I propose we replace the pseudocode in the draft with the following, stand-alone pseudocode, for the NEXT-C-SID and REPLACE-C-SID flavors of the END behavior (sections 4.1.1 and 4.2.1 respectively). Equivalent changes can be completed for the NEXT-C-SID and REPLACE-C-SID flavors of the END.X behavior (sections 4.1.2 and 4.2.2 respectively) and NEXT-AND-REPLACE-C-SID flavor. Comments are appreciated. Thanks Darren 4.1.1. End with NEXT-C-SID When processing an IPv6 packet that matches a FIB entry locally instantiated as an End SID with the NEXT-C-SID flavor, the SRH processing described in Section 4.1 of [RFC8986] is replaced as follows. S.01 When an SRH is processed { S.02 If (IPv6.DA.Argument =3D=3D 0 and SRH.SegmentsLeft =3D=3D 0) { S.03 Stop processing the SRH, and proceed to process the next header in the packet, whose type is identified by the Next Header field in the routing header. S.04 } S.05 If (IPv6.HopLimit <=3D 1) { S.06 Send an ICMP Time Exceeded message to the Source Address with Code 0 (Hop limit exceeded in transit), interrupt packet processing, and discard the packet. S.07 } S.08 # Determine the maximum SRH Last Entry S.09 Set maxLE to ((SRH.HdrExtLen / 2) - 1) S.10 Initialize 128-bit buffer memory S to 0. S.11 Initialize local parameter Argument to the value of IPv6.DA.Argument S.12 If (Argument =3D=3D 0) { S.13 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)= ) { S.14 Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S.15 } S.16 Decrement SRH.SegmentsLeft by 1 S.17 Set S to the value of SRH.SegmentList[SRH.SegmentsLeft] S.18 } S.19 Else { S.20 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)= ) { S.21 Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S.22 } S.23 Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common loc= ator block) S.24 If (SRH.SegmentsLeft > SRH.LastEntry) { S.25 Initialize local parameter ActiveSegment to the value of DA S.26 } S.27 Else { S.28 Initialize local parameter ActiveSegment to the value S.29 of SRH.SegmentList[SRH.SegmentsLeft] S.30 } S.31 Initialize local parameter BitLength to (CountTrailingZeros(ActiveS= egment) + AL - CountTrailingZeros(A= rgument)) S.32 Initialize local parameter BitIndex to (128 - BitLength) S.33 Set S[B..B+BitLength-1] to the value of ActiveSegment[BitIndex..(BitIndex+BitLength-1)] S.34 } S.35 Set IPv6.DA to the value of S S.36 Decrement IPv6.HopLimit by 1 S.37 Submit the packet to the egress IPv6 FIB lookup for transmission to the new destination. S.38 } 4.1.1.1 Upper layer header processing The upper-layer header processing described in Section 4.1.1 of [RFC8986] is replaced as follows. S.01 Initialize local parameter Argument to the value of IPv6.DA.Argument S.02 If (Argument !=3D 0) { # In this case, the SRH was not added by source # The source compressed it into the active segment in IPv6.DA # Build a pseudo header from the active segment in the IPv6.DA for = use # during processing. S.03 Initialize a 24-byte local SRH in memory to 0's for use below S.04 Set SRH.MaxHdrLen to 3 S.05 Set SRH.RoutingType to 4 S.06 Set SRH.SegmentsLeft to 0 S.07 Set SRH.SegmentList[0] to the value of IPv6.DA S.08 Process the SRH as per section 4.1.1, S.09 noting such processing is limited to the pseudo SRH S.10 since Argument is not 0. S.11 } S.12 If (Upper-Layer header type is allowed by local configuration) { S.13 Proceed to process the Upper-Layer header S.14 } Else { S.15 Send an ICMP Parameter Problem to the Source Address with Code 4 (SR Upper-layer Header Error) and Pointer set to the offset of the Upper-Layer header, interrupt packet processing, and discard the packet. S.16 } 4.2.1. End with REPLACE-C-SID When processing an IPv6 packet that matches a FIB entry locally instantiated as an End SID with the REPLACE-C-SID flavor, the SRH processing described in Section 4.1 of [RFC8986] is replaced as follows. S.01 When an SRH is processed { S.02 If (IPv6.DA.Argument =3D=3D 0 and SRH.SegmentsLeft =3D=3D 0) { S.03 Stop processing the SRH, and proceed to process the next header in the packet, whose type is identified by the Next Header field in the routing header. S.04 } S.05 If (IPv6.HopLimit <=3D 1) { S.06 Send an ICMP Time Exceeded message to the Source Address with Code 0 (Hop limit exceeded in transit), interrupt packet processing, and discard the packet. S.07 } S.08 # Determine the maximum SRH Last Entry S.09 Set maxLE to ((SRH.HdrExtLen / 2) - 1) S.10 Initialize 128-bit buffer memory S to 0. S.11 Initialize local parameter Argument to the value of IPv6.DA.Argument S.12 Initialize local parameter ActiveSegment to SRH.SegmentList[SRH.Segme= ntsLeft] S.13 If (Argument =3D=3D 0) { S.14 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)= ) { S.15 Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S.16 } S.17 Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common loc= ator block) S.18 Decrement SRH.SegmentsLeft by 1 S.19 Set Argument to (128 / NF - 1) S.20 } S.21 Else { S.22 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry)) = { S.23 Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S.24 } S.25 Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common loc= ator block) S.26 Decrement Argument by 1 S.27 } S.28 Initialize local parameter BitLength to the value of NF S.29 Initialize local parameter BitIndex to (Argument * NF) S.30 Set S[B..B+BitLength-1] to the value of ActiveSegment[BitIndex..(BitIndex+BitLength-1)] S.32 Set S[B+BitLength..B+BitLength+A-1] to the value of Argument S.33 Set IPv6.DA to the value of S S.34 Decrement IPv6.HopLimit by 1 S.35 Submit the packet to the egress IPv6 FIB lookup for transmission S.36 to the new destination. S.37 } 4.2.1.1. Upper layer header processing The upper-layer header processing described in Section 4.1.1 of [RFC8986] i= s unchanged and reproduced below. S.01 If (Upper-Layer header type is allowed by local configuration) { S.02 Proceed to process the Upper-Layer header S.03 } Else { S.04 Send an ICMP Parameter Problem to the Source Address with Code 4 (SR Upper-layer Header Error) and Pointer set to the offset of the Upper-Layer header, interrupt packet processing, and discard the packet. S.05 } --_000_AS8PR03MB7622B60021ECF2ABA7A5E20EEEB89AS8PR03MB7622eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

    (Apologies if this = appears twice – seems something went screwy with my outbound address = so the other version of this is moderated)

     

    Darren,<= /span>

     

    I’m a little = confused here reading this – but all said and done – on the nex= t behavior – how is this different from doing something along the lin= es of

     

    Da[loc_bits/8] <= < sid_size

     

    Because – whe= n I trace this all out into actual C code – that’s pretty much = what it seems to summarize down to – more specifically – it cou= ld be done something like this:

     

    (taking out all the= comparisons and error checking)

     

    __m128i vec;

    __u8 output[16];=

     

    vec =3D __mm_loa= dl_epi64((void *)da[loc_size/8])

    if(sid_size =3D= =3D 16) {

      &nbs= p;           vec =3D _mm_= bsrli_si128(vec, 2)

    } else {

      &nbs= p;           vec =3D _mm_= bsrli_si128(vec, 4)

    }

    _mm_store_u_si12= 8((__m128i*)output, vec);

    memcpy(da[loc_si= ze/8], output, 16-(loc_size/8));

     

    (think I got that p= retty much right)

     

    Andrew

     

     

    From:= spring <spring-bounces@ietf.org> On Behalf Of Darren Dukes (ddukes)
    Sent: Thursday, October 14, 2021 3:54 PM
    To: SPRING WG <spring@ietf.org>
    Subject: [spring] CSID proposed clarifications

     

    The NEXT-C-SID and REPLACE-C-SID flavors are functionally = very similar.

    In both cases the SID in the IPv6 Destination Address (DA)= contains an argument,

    that argument is used to construct the next SID from the a= ctive segment in

    the SRH Segment List.

     

    I believe the following pseudocode is a much better descri= ption of their

    segment endpoint processing. You’ll notice there is = no manipulation of

    the bits in the IPv6 DA.

     

    I propose we replace the pseudocode in the draft with the = following,

    stand-alone pseudocode, for the NEXT-C-SID and REPLACE-C-S= ID flavors

    of the END behavior (sections 4.1.1 and 4.2.1 respectively= ).

     

    Equivalent changes can be completed for the NEXT-C-SID and= REPLACE-C-SID

    flavors of the END.X behavior (sections 4.1.2 and 4.2.2 re= spectively) and

    NEXT-AND-REPLACE-C-SID flavor.

     

    Comments are appreciated.

     

    Thanks

      Darren

     

    4.1.1.  End with NEXT-C-SID<= /p>

     

    When processing an IPv6 packet that matches a FIB entry lo= cally

    instantiated as an End SID with the NEXT-C-SID flavor, the= SRH

    processing described in Section 4.1 of [RFC8986] is replac= ed as

    follows.

     

     

    S.01 When an SRH is processed {

    S.02  If (IPv6.DA.Argument =3D=3D 0 and SRH.SegmentsL= eft =3D=3D 0) {

    S.03     Stop processing the SRH, and = proceed to process the next

             header in= the packet, whose type is identified by

             the Next = Header field in the routing header.

    S.04  }

     

    S.05  If (IPv6.HopLimit <=3D 1) {

    S.06     Send an ICMP Time Exceeded me= ssage to the Source Address

             with Code= 0 (Hop limit exceeded in transit),

             interrupt= packet processing, and discard the packet.

    S.07  }

     

    S.08  # Determine the maximum SRH Last Entry

    S.09  Set maxLE to ((SRH.HdrExtLen / 2) - 1)

     

    S.10  Initialize 128-bit buffer memory S to 0.

    S.11  Initialize local parameter Argument to the valu= e of IPv6.DA.Argument

     

    S.12  If (Argument =3D=3D 0) {

    S.13    If ((SRH.LastEntry > maxLE) or (= SRH.SegmentsLeft > SRH.LastEntry+1)) {

    S.14      Send an ICMP Parameter = Problem to the Source Address

             &nbs= p; with Code 0 (Erroneous header field encountered)

             &nbs= p; and Pointer set to the Segments Left field,

             &nbs= p; interrupt packet processing, and discard the packet.

    S.15    }

     

    S.16    Decrement SRH.SegmentsLeft by 1

     

    S.17    Set S to the value of SRH.SegmentLi= st[SRH.SegmentsLeft]

    S.18  }

    S.19  Else {

    S.20    If ((SRH.LastEntry > maxLE) or (= SRH.SegmentsLeft > SRH.LastEntry+1)) {

    S.21      Send an ICMP Parameter = Problem to the Source Address

             &nbs= p;with Code 0 (Erroneous header field encountered)

             &nbs= p; and Pointer set to the Segments Left field,

             &nbs= p; interrupt packet processing, and discard the packet.

    S.22    }

     

    S.23    Set S[0..B-1] to the value of IPv6.= DA[0..B-1] (i.e., the common locator block)

     

    S.24    If (SRH.SegmentsLeft > SRH.LastE= ntry) {

    S.25      Initialize local parame= ter ActiveSegment to the value of DA

    S.26    }

    S.27    Else {

    S.28      Initialize local parame= ter ActiveSegment to the value

    S.29       of SRH.SegmentLis= t[SRH.SegmentsLeft]

    S.30    }

     

    S.31    Initialize local parameter BitLengt= h to (CountTrailingZeros(ActiveSegment) +

             &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  AL - CountTrailingZeros(Argument))

    S.32    Initialize local parameter BitIndex= to (128 – BitLength)

     

    S.33    Set S[B..B+BitLength-1] to the valu= e of

             Acti= veSegment[BitIndex..(BitIndex+BitLength-1)]

    S.34  }

     

    S.35  Set IPv6.DA to the value of S=

     

    S.36  Decrement IPv6.HopLimit by 1<= /p>

     

    S.37  Submit the packet to the egress IPv6 FIB lookup= for transmission

           to the new destinatio= n.

    S.38 }

     

    4.1.1.1 Upper layer head= er processing

     

    The upper-layer header processing described in Section 4.1= .1 of

    [RFC8986] is replaced as follows.

     

    S.01  Initialize local parameter Argument to the valu= e of IPv6.DA.Argument

    S.02  If (Argument !=3D 0) {

            # In this case,= the SRH was not added by source

            # The sour= ce compressed it into the active segment in IPv6.DA

            # Build a = pseudo header from the active segment in the IPv6.DA for use

          # during processing.

    S.03    Initialize a 24-byte local SRH in m= emory to 0’s for use below

    S.04    Set SRH.MaxHdrLen to 3

    S.05    Set SRH.RoutingType to 4=

    S.06    Set SRH.SegmentsLeft to 0

    S.07    Set SRH.SegmentList[0] to the value= of IPv6.DA

     

    S.08    Process the SRH as per section 4.1.= 1,

    S.09     noting such processing is lim= ited to the pseudo SRH

    S.10     since Argument is not 0.=

    S.11  }

     

    S.12  If (Upper-Layer header type is allowed by local= configuration) {

    S.13    Proceed to process the Upper-Layer = header

    S.14  } Else {

    S.15    Send an ICMP Parameter Problem to t= he Source Address

             with Code= 4 (SR Upper-layer Header Error)

             and Point= er set to the offset of the Upper-Layer header,

             interrupt= packet processing, and discard the packet.

    S.16  }

     

     

     

    4.2.1.  End with REPLACE-C-SID

     

    When processing an IPv6 packet that matches a FIB entry lo= cally

    instantiated as an End SID with the REPLACE-C-SID flavor, = the SRH

    processing described in Section 4.1 of [RFC8986] is replac= ed as

    follows.

     

    S.01 When an SRH is processed {

    S.02  If (IPv6.DA.Argument =3D=3D 0 and SRH.SegmentsL= eft =3D=3D 0) {

    S.03    Stop processing the SRH, and procee= d to process the next

            header in the p= acket, whose type is identified by

            the Next Header= field in the routing header.

    S.04  }

     

    S.05  If (IPv6.HopLimit <=3D 1) {

    S.06    Send an ICMP Time Exceeded message = to the Source Address

            with Code 0 (Ho= p limit exceeded in transit),

            interrupt packe= t processing, and discard the packet.

    S.07  }

     

    S.08  # Determine the maximum SRH Last Entry

    S.09  Set maxLE to ((SRH.HdrExtLen / 2) - 1)

     

    S.10  Initialize 128-bit buffer memory S to 0.

    S.11  Initialize local parameter Argument to the valu= e of IPv6.DA.Argument

    S.12  Initialize local parameter ActiveSegment to SRH= .SegmentList[SRH.SegmentsLeft]

     

    S.13  If (Argument =3D=3D 0) {

    S.14    If ((SRH.LastEntry > maxLE) or (= SRH.SegmentsLeft > SRH.LastEntry+1)) {

    S.15      Send an ICMP Parameter = Problem to the Source Address

              wit= h Code 0 (Erroneous header field encountered)

              and= Pointer set to the Segments Left field,

              int= errupt packet processing, and discard the packet.

    S.16    }

     

    S.17    Set S[0..B-1] to the value of IPv6.= DA[0..B-1] (i.e., the common locator block)

     

    S.18    Decrement SRH.SegmentsLeft by 1

     

    S.19    Set Argument to (128 / NF - 1)=

    S.20  }

    S.21  Else {

    S.22    If ((SRH.LastEntry > maxLE) or (= SRH.SegmentsLeft > SRH.LastEntry)) {

    S.23      Send an ICMP Parameter = Problem to the Source Address

              wit= h Code 0 (Erroneous header field encountered)

              and= Pointer set to the Segments Left field,

              int= errupt packet processing, and discard the packet.

    S.24    }

     

    S.25    Set S[0..B-1] to the value of IPv6.= DA[0..B-1] (i.e., the common locator block)

     

    S.26    Decrement Argument by 1<= /span>

    S.27  }

     

    S.28  Initialize local parameter BitLength to the val= ue of NF

    S.29  Initialize local parameter BitIndex to (Argumen= t * NF)

     

    S.30  Set S[B..B+BitLength-1] to the value of

           ActiveSegment[BitInde= x..(BitIndex+BitLength-1)]

    S.32  Set S[B+BitLength..B+BitLength+A-1] to the valu= e of Argument

     

    S.33  Set IPv6.DA to the value of S=

     

    S.34  Decrement IPv6.HopLimit by 1<= /p>

     

    S.35  Submit the packet to the egress IPv6 FIB lookup= for transmission

    S.36   to the new destination.=

    S.37 }

     

    4.2.1.1.  Upper lay= er header processing

     

    The upper-layer header processing described in Section 4.1= .1 of [RFC8986] is unchanged and reproduced below.

     

    S.01  If (Upper-Layer header type is allowed by local= configuration) {

    S.02    Proceed to process the Upper-Layer = header

    S.03  } Else {

    S.04    Send an ICMP Parameter Problem to t= he Source Address

            with Code 4 (SR= Upper-layer Header Error)

            and Pointer set= to the offset of the Upper-Layer header,

            interrupt packe= t processing, and discard the packet.

    S.05  }

     

     

     

    --_000_AS8PR03MB7622B60021ECF2ABA7A5E20EEEB89AS8PR03MB7622eurp_-- From nobody Fri Oct 15 03:40:30 2021 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 57C043A190F; Fri, 15 Oct 2021 03:40:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.097 X-Spam-Level: X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 d_m1xnmNaU-J; Fri, 15 Oct 2021 03:40:22 -0700 (PDT) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0:4864:20::32f]) (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 7ECA53A115D; Fri, 15 Oct 2021 03:40:22 -0700 (PDT) Received: by mail-ot1-x32f.google.com with SMTP id w12-20020a056830410c00b0054e7ceecd88so12291236ott.2; Fri, 15 Oct 2021 03:40:22 -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=EXYG2g1NZNwHHJLK6hCAmUcr766MA+Rs9bB4I5h4T8A=; b=oIgQbp1ozV/e3lcyjgQY6qRAuz86MxsISYZp413/lI67ScGLVCZdhCZN0TDCkrSJVG Zhb7ZcVmXAxClxVYiOIy8erdC+zLS3e5Yzj5xiVeuh5QSr/7DU3NwYlsrtZZTNeMxdEW ZSNLzGhmvOOJ5qgcbeGXbcSGHEVIahTr7gphxesCkXCjuIwI/AZCCgq6kPQOlWAB/hCX Ogut/fGNeVxcKdIPBRfytuc/YEnaAnwv8gWBCrMsr6JKGaero+vaExeKnPYP35E1cQrT K3LhI36kwpAYii95C5AkDb4tiEAq6I/5d0WKqKg5T70cgqXVeIVecoXGzJQi8TuI7z0G YYjQ== 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=EXYG2g1NZNwHHJLK6hCAmUcr766MA+Rs9bB4I5h4T8A=; b=rI7Gk4NkoH3UcJytw1UUKKR6agDlYOaA45ox1poFhRjB9OOQ9m4KbsxlVnQOxWxZT/ 8uZZy26Mr+wKTnvCMCaTgTMBe6hXkMpGv0g8Im9iHI/Ohz/Jh5vW2rbGkGfSPjwNu/ui A035VBQV6z8+FonEUqAJSsBShRjP+Pd7svvcYHNla18uKhd42oNeF6Jt+Io30NK4ej9C wiSR/C3H/RpMdmV4/drjEAedfWXw4Xx1zhIF/oKUZtagk24x3eI/JiIbDvKDMOHT2lny DlkHtzuxlC4bgTf7KEwt+gISt2rKaef1/UJ1Gq7iauDjK8Aay1fpIeBYiAOA3srcb5aU cfuQ== X-Gm-Message-State: AOAM531ak+b5u4vFve54yYYt84roOVLVjfqVrQHhtlQGPpr3OQr8X47V 5AA06BEO9eqADYWKSttrU9pe0phwVnk2jzRJCsSWxl+jEkg= X-Google-Smtp-Source: ABdhPJzrWWJfbQUFX4hPG3VSSQaq4eQNTN8HqQr41bPJTV/1iRCQ6IvyWh1xov5NAKmeAAStUhJNaBqPuK7AGRB1sXA= X-Received: by 2002:a9d:6113:: with SMTP id i19mr7251453otj.322.1634294421462; Fri, 15 Oct 2021 03:40:21 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <1daf3d20-22b2-d111-5131-bd53f51c53a3@gmail.com> <60f71d8c-8165-111c-4099-7f926a897d22@gmail.com> In-Reply-To: <60f71d8c-8165-111c-4099-7f926a897d22@gmail.com> From: Ted Hardie Date: Fri, 15 Oct 2021 11:39:54 +0100 Message-ID: To: Brian E Carpenter Cc: "Joel M. Halpern" , "ipv6@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="00000000000073237a05ce61d27b" Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 15 Oct 2021 10:40:29 -0000 --00000000000073237a05ce61d27b Content-Type: text/plain; charset="UTF-8" On Thu, Oct 14, 2021 at 10:06 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 14-Oct-21 22:41, Ted Hardie wrote: > > On Wed, Oct 13, 2021 at 9:28 PM Brian E Carpenter < > brian.e.carpenter@gmail.com > wrote: > > > > > > > > Including semantics *of any kind* in an IP address is a very > fundamental > > change to the concept of IP.< > https://www.ietf.org/mailman/listinfo/ipv6> > > > > > > Would you mind elaborating what you mean by semantics in the statement > above? Clearly there are semantics in things like the IPv4 multicast and > experimental address ranges (aka "Class D" and "Class E"); especially for > the multicast case, the very fundamental semantics of the distribution are > signalled using the address and there has been significant deployment using > those semantics. Isn't that semantics in the meaning above? > > Yes, I should have restricted my remark to *unicast* addresses. But there > is a difference, I think, between semantics that describe the *type of > address* and semantics that actively describe *what the recipient is going > to do*. It's the latter that I was getting at. > > Thank you for the clarification, though I'm still struggling a bit with understanding your concern. Since we use address ranges for scope semantics (e.g. ULAs for administratively determined scopes) even within unicast addressing, I'm not quite seeing the line you are yet. > (This applies to Carsten's comment too. Port numbers or multiple addresses per host are not actively describing what the recipient will do; they're just numbers.) While this may theoretically be true, we actually associate significant semantics with port numbers, both in the end hosts (e.g. the ports below 1024 being privileged ports) and in the network (where firewalls use ports to start the process of analyzing the permissibility of a flow). A specific port number very much describes what the host will do: port 25 will link to the SMTP service, for example. So I guess I'm not following this parallel too well either. regards, Ted > > Also, I tried not to express shock and horror at the notion of semantics > in address, but concern about how this will impact existing hardware and > software. > > > > > Thanks for any clarification, > > > > Ted > > > > --00000000000073237a05ce61d27b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Thu, Oct 14, 2021 at 10:06 PM Brian E Carpenter <brian.e.carpenter@gmail.com>= ; wrote:
    On 14-Oct-21 22:41, Ted Hardie wrote:
    > On Wed, Oct 13, 2021 at 9:28 PM Brian E Carpenter <brian.e.carpenter@gmail.co= m <mailto:brian.e.carpenter@gmail.com>> wrote:
    >
    >
    >
    >=C2=A0 =C2=A0 =C2=A0Including semantics *of any kind* in an IP address = is a very fundamental
    >=C2=A0 =C2=A0 =C2=A0change to the concept of IP.<ht= tps://www.ietf.org/mailman/listinfo/ipv6>
    >
    >
    > Would you mind elaborating what you mean by semantics in the statement= above?=C2=A0 Clearly there are semantics in things like the IPv4 multicast= and experimental address ranges (aka "Class D" and "Class E= "); especially for the multicast case, the very fundamental semantics = of the distribution are signalled using the address and there has been sign= ificant deployment using those semantics.=C2=A0 Isn't that semantics in= the meaning above?

    Yes, I should have restricted my remark to *unicast* addresses. But there <= br> is a difference, I think, between semantics that describe the *type of addr= ess* and semantics that actively describe *what the recipient is going to d= o*. It's the latter that I was getting at.


    Thank you for the clarification, = though I'm still struggling a bit with understanding your concern.=C2= =A0 Since we use address ranges for scope semantics (e.g. ULAs for administ= ratively determined scopes) even within unicast addressing, I'm not qui= te=C2=A0seeing the line you are yet.

    > (This applies to Carsten&#= 39;s comment too. Port numbers or multiple addresses per host are not activ= ely describing what the recipient will do; they're just numbers.)
    While this may theoretically be true, we actually associate significant s= emantics with port numbers, both in the end hosts (e.g. the ports below 102= 4 being privileged ports) and in the network (where firewalls use ports to = start the process of analyzing the permissibility of a flow).=C2=A0 A speci= fic port number very much describes what the host will do: =C2=A0port 25 wi= ll link to the SMTP service, for example.=C2=A0 So I guess I'm not foll= owing this parallel too well either.

    regards,

    Ted
    =C2=A0

    Also, I tried not to express shock and horror at the notion of semantics in= address, but concern about how this will impact existing hardware and soft= ware.

    >
    > Thanks for any clarification,
    >
    > Ted
    >

    --00000000000073237a05ce61d27b-- From nobody Fri Oct 15 06:12:30 2021 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 AAF8C3A0773; Fri, 15 Oct 2021 06:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bS5WIPktArH7; Fri, 15 Oct 2021 06:12:23 -0700 (PDT) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 68B403A0743; Fri, 15 Oct 2021 06:12:23 -0700 (PDT) Received: by mail-qv1-xf33.google.com with SMTP id k19so5649855qvm.13; Fri, 15 Oct 2021 06:12:23 -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=5VNabtW2za/fBo6ogg/dN/30wlK18XLjslIlMsULe7w=; b=aDO0aXuG+SgALSWy4kodrl+5HwJx0DwinCymIBJHqZTd8ZTRvJEmaDVT/eBe283RtI rlYjm7YssamD6UmL1+EJTaLTRM/tCpJZ3o2mLlZ/+9iAXzY8ziLRyYzhDIK1V+rPCLkO EuCULgbh4MhV+wC85hQKDEVgN4HDrvpx2Emo+u23r7dlqK7Oq5BsvW38/PNJrFOeuLRT CQQKIH4FHjoNdmgLNO5u1GsQq7cPSw2BpZ6Luu94yrAvr3TX4F6pXHzYZqmYZShel5vN HEG8q8Y86dfn4DdXrOdUs2yzNBFqTQA4PYpKzZyqXD/4VeYdp67ZS7Rd1BiUflmmw7FN AXYA== 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=5VNabtW2za/fBo6ogg/dN/30wlK18XLjslIlMsULe7w=; b=R75fnTimzDJqGWytJTLcK+pE2vCvXchS86ozucMy09i4yhFePOtVEu1Zatvun7I/8y S78SqjZpP5XIkWON/2grPSTqy3Locqq7Rdh6r2vId3DRW53KshlpU4GGfdtj7UlKEnQZ BodvABnB76x45gE9LlrtHVptn1mt9EwFMh/UO/HfHQx6/ExUhRtU8OiafbT3ybI1HyDW IyUe3mADEZufsQlE7sqeTFAnG+WRAwuxo+pVb2Z95u+xbaT/2pErzWpH/z7raLkhRBp/ WcPfINTPvTdbQd5BbDLMqGs8/EGVk74cTMwO1Rnlfwe8UuUmZ0HgejHxuWpnqgfZiIIu 0PIA== X-Gm-Message-State: AOAM531zGlgszXO3+CYj0opCMvWEkorFMG+YMiHZ1w3B+fuuiBNIhlbz A9+gkSVKPWaprYrpSo+cKVursU48FB67qOdR5R0= X-Google-Smtp-Source: ABdhPJyFE+LUplss7NKeoTnXjaZAibUnCSgP4rvu+j+PjuwJ7YACfHnSnF+Df2f0KSmMIlc0V066sldf1IXRa68nYj4= X-Received: by 2002:a0c:f38c:: with SMTP id i12mr10957023qvk.23.1634303542332; Fri, 15 Oct 2021 06:12:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: "Luis M. Contreras" Date: Fri, 15 Oct 2021 15:12:10 +0200 Message-ID: To: James Guichard Cc: SPRING WG , "spring-chairs@ietf.org" , LUIS MIGUEL CONTRERAS MURILLO Content-Type: multipart/alternative; boundary="000000000000188f8a05ce63f2ef" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 15 Oct 2021 13:12:29 -0000 --000000000000188f8a05ce63f2ef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi all, I support the adoption of this draft which goes in line with the conclusions of the DT analysis, as the basis for a compression solution defined by the WG. I'm planning to perform interop tests in the forthcoming months, so further operational feedback can be provided afterwards. Best regards Luis El vie, 1 oct 2021 a las 16:05, James Guichard (< james.n.guichard@futurewei.com>) escribi=C3=B3: > Dear WG: > > > > The chairs would like to express their appreciation for all the responses > received to our emails with reference to how the working group wishes to > move forward with respect to a solution for SRv6 compression. > > > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > as the basis for its compression standardization work. That is part of wh= at > this email attempts to confirm. > > > > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging > that: > > > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change = as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the working > group to publication. A list of these discussion points will be docume= nted > in the WG document and maintained by the document editor in conjunctio= n > with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text describin= g an > open issue be added to the document in the above-described open issues > section: > - "Given that the working group has said that it wants to > standardize one data plane solution, and given that the document co= ntains > multiple SRv6 EndPoint behaviors that some WG members have stated a= re > multiple data plane solutions, the working group will address wheth= er this > is valid and coherent with its one data plane solution objective.". > > > > Please consider the above guidelines as you decide on whether to support > or not this WG adoption. Please express clearly your reasoning for > support/non-support as well as any open discussion points you would like > addressed should the document be adopted into the working group. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > _________________________ Luis M. Contreras contreras.ietf@gmail.com luismiguel.contrerasmurillo@telefonica.com Global CTIO unit / Telefonica --000000000000188f8a05ce63f2ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi all,

    I support the = adoption of this draft which goes in line with the conclusions of the DT an= alysis, as the basis=C2=A0for a compression solution defined by the WG.=C2= =A0

    I'm planning to perform interop tests in t= he forthcoming months, so further operational feedback can be provided afte= rwards.

    Best regards

    Luis=


    =
    El vie, 1 oct 2021 a las 16:05, James Guichard (<james.n.guicha= rd@futurewei.com>) escribi=C3=B3:

    Dear WG:

    =C2=A0

    The chairs would like to express their appreciation = for all the responses received to our emails with reference to how the work= ing group wishes to move forward with respect to a solution for SRv6 compre= ssion.

    =C2=A0

    The apparent inclination of the working group is to = use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

    =C2=A0

    Because of the above the chairs would like to issue = a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

    =C2=A0

    1. The SPRING working group is adopting a docume= nt that has multiple SRv6 Endpoint behaviors.
    2. The document is a =E2=80= =9Cliving=E2=80=9D document; it may change as it goes through review and an= alysis by the SPRING working group.
    3. All open discussion points= raised on our mailing list MUST be addressed BEFORE said document is allow= ed to progress from the working group to publication. A list of these discu= ssion points will be documented in the WG document and maintained by the documen= t editor in conjunction with the chairs.
    4. If this document is adopte= d by the working group, the chairs specify as part of the adoption call tha= t the following text describing an open issue be added to the document in t= he above-described open issues section:
      • "Given that the working group has said that it wants to standardiz= e one data plane solution, and given that the document contains multiple SR= v6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

    =C2=A0

    Please consider the above guidelines as you decide o= n whether to support or not this WG adoption. Please express clearly your r= easoning for support/non-support as well as any open discussion points you = would like addressed should the document be adopted into the working group.

    =C2=A0

    Thanks!

    =C2=A0

    Jim, Bruno & Joel

    =C2=A0

    =C2=A0

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


    _________________________
    Luis M. Contreras
    =
    Global CTIO unit / Telefonica


    --000000000000188f8a05ce63f2ef-- From nobody Fri Oct 15 08:03:22 2021 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 33BEC3A0912 for ; Fri, 15 Oct 2021 08:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 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, 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=XlAzqyEN; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=sUk8Lqtd 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 6t2yh8fDyAac for ; Fri, 15 Oct 2021 08:03:13 -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 01BD13A0907 for ; Fri, 15 Oct 2021 08:03:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=55722; q=dns/txt; s=iport; t=1634310193; x=1635519793; h=from:to:cc:subject:date:message-id:mime-version; bh=znP5SpnI/cMwEB4EhgClkMyYQsCK0LbApXBLX7bkMKU=; b=XlAzqyENix0dQkZpQrHoFH16pO1xnp3xZnIzINlPDHzDnnHPVSlFV388 z6uXfN8AlaSKJJ2eaTXRpZxjOEHYbU1liLOz3X5NujKHHGgBldGpz34hk ao16yepqv6SjjU1afAsGjzt5j2kkJ0kIkUgawGqt08o7/yNjT8XMdwWX1 Q=; IronPort-PHdr: =?us-ascii?q?A9a23=3AKMTWRBVKiSQ6dDe8ptQrIihI+hLV8K3mAWYlg?= =?us-ascii?q?6HPw5pPf7ituZP4Mx+X6fZsiQrPWoPWo7JBhvHNuq/tEWoH/d6asX8EfZANM?= =?us-ascii?q?n1NicgfkwE6RsLQD0r9Ia3rYjA0WsNYWwwt83SyK0MAHsH4ahXbqWGz6jhHH?= =?us-ascii?q?BL5OEJ1K+35F5SUgd6w0rW5+obYZENDgz/uCY4=3D?= IronPort-Data: =?us-ascii?q?A9a23=3AUGCXo6BE27mJURVW/9Dhw5YqxClBgxIJ4kV8j?= =?us-ascii?q?S/XYbTApG9w3zIDzmsbXGuDbPjYajChc4xxO9y0/RxU7cLUmtA2OVdlrnsFo?= =?us-ascii?q?1CmBibm6XV1Fqp7Vs+rBpWroHlPsoNON7EsEOhuFiWF/0/0b+C7xZVB/fjgq?= =?us-ascii?q?oTUWbas1h9ZHWeIeA954f5Ss7ZRbrxA2LBVMCvV0T/GmPAzDXf+s9JC3s343?= =?us-ascii?q?IrYwP9nlKyaVDr1JTXSb9gT1LPVvyF94J7yuciMw3XErol8RoZWRs7Zx72/u?= =?us-ascii?q?2je5RpoW5Wuk63wdQsBRbu60Qqm0yUNHfP9xEkZ4HVuj87XN9JEAatToz+Fg?= =?us-ascii?q?s5w1tRAnZexUgwueKbLnYzxVjEJSXsnZfEcoeOvzX+X9Jb7I1f9W3Hh2el0B?= =?us-ascii?q?Uc6FYEF5OdpAGxUs/cfLVgldRCKlqSkyb68Sbww3s45K8DnN4Qa/HpnyBnVC?= =?us-ascii?q?P88StbCTrnEo9hC018YhMlLEO2YYYwWdDtkbB3abzVBJ0sKEp8hkebujX76G?= =?us-ascii?q?xVDsEiUo6Uf4mXPwkp2yreFDTZ/UrRmXu1PlUqe42nB5Wm8U1cRNceUznyO9?= =?us-ascii?q?XfEuwMGpgujMKp6KVFy3qcz0Qf7KrQvNSAr?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AWvdlZqxR8Drs4DOodpbtKrPxmuskLtp133?= =?us-ascii?q?Aq2lEZdPULSK2lfpGV8sjziyWatN9IYgBcpTiBUJPwJk80hqQFnbX5XI3SEz?= =?us-ascii?q?UO3VHJEGgM1/qY/9SNIVyaygc/79YvT0EdMqyLMbESt6+Ti2PUf6dCsbu6Gc?= =?us-ascii?q?uT9IHjJgJWPHlXgtZbnn5E42igYylLbTgDIaB8OIuX58JBqTblU28QdN6HCn?= =?us-ascii?q?4MWPWGj8HXlbr9CCR2RiIP2U2rt3eF+bT6Gx+X0lM1SDVU24ov9mDDjkjQ+r?= =?us-ascii?q?ijifem0RXRvlWjr6i+2eGRieerNvb8z/T9GQ+czjpAo74RHIFqiQpF4t1HLm?= =?us-ascii?q?xa1uUk7S1QZviboEmhAV1d6SGdpTUIlgxes0MLDTSj8CHeSQuTfkNgNyMJv/?= =?us-ascii?q?MpTjLJr0Unp91yy6RNwiaQsIdWFwrJmGDn68HPTAwCrDv+nZMOq59bs5Vka/?= =?us-ascii?q?pXVFaRl/1rwGpFVJMbWC7q4oEuF+djSMna+fZNaFufK3TUpHNmztCgVmk6Wk?= =?us-ascii?q?7ueDlOhuWFlzxN2HxpxUoRw8IS2n8G6ZImUpFBo+DJKL5hmr1CRtIfKah9GO?= =?us-ascii?q?ACS82qDXGle2OHDEuCZVD8UK0XMXPErJD6pL0z+eGxYZQNiIA/nZzQOWkow1?= =?us-ascii?q?Lau3iefvFm+ac7viwlbF/NLggF+/suk6SR4IeMNIYDGRfzOmwTrw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwAACNl2lh/5FdJa1aHAEBAQEBAQc?= =?us-ascii?q?BARIBAQQEAQGCBwUBAQsBgSAwIy4Hd1o3MYRHg0cDhTmIDZp1gS4UgREDTwU?= =?us-ascii?q?LAQEBDQEBKgEMCgQBAYQ5RQIXgjICJTYHDgECBAEBARIBAQUBAQECAQYEgRE?= =?us-ascii?q?ThTsIJQEMhkUBBAEQCwYKEwEBJAgLAREBBjoBAgQDAgQlCxQTBA4FCBMHglC?= =?us-ascii?q?BflcDLwEOkH+PNgGBOgKKH3qBMYEBgggBAQYEBIFKQYJ/GII1AwaBOgGDBIQ?= =?us-ascii?q?TAQGCdYMEeyccgUlEJm9DgyWCYwEBAgGBHwQFARIBIysJgmI3ggwii2kBLQJ?= =?us-ascii?q?CMh8TBAYOBw0rIAI2AyAWRAI2BioRKZE4QX6CIokDjU+SKwqDMYpHlEcUg2q?= =?us-ascii?q?LbZdBhxOOdR+CH4oxmQACBAIEBQIOAQEGgWgILGlwcBU7gmkJSBkPgz6KYgw?= =?us-ascii?q?WFRmDIoUUhUp0AgE1AgYBCgEBAwmTIAEB?= X-IronPort-AV: E=Sophos;i="5.85,376,1624320000"; d="scan'208,217";a="922104214" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Oct 2021 15:01:55 +0000 Received: from mail.cisco.com (xbe-aln-001.cisco.com [173.36.7.16]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 19FF1sn7021032 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 15 Oct 2021 15:01:54 GMT Received: from xfe-rcd-003.cisco.com (173.37.227.251) 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.792.15; Fri, 15 Oct 2021 10:01:54 -0500 Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 15 Oct 2021 10:01:54 -0500 Received: from NAM10-DM6-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.792.15 via Frontend Transport; Fri, 15 Oct 2021 11:01:53 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P7AxVvb2ShjonyIAY4Y6zQfA69F35qBYZvNqqF/MEnXmJcz9nHG6FIEPCJRklbU16EzmtCk5bW2a7in7K4z+oJrIg3l812dnzX8hwSIAiESeGMshyTM3friQX1HHdaDgkd0tL0W1WNmzj7WuCvv+MMesrqwONimGTXjtrOlKYCBN3f3nLezEQoJkpGMwRBZucjtcCFcheis9V5mGrffc4IO1qB4G5tzOFg25fxVI0m+E+NysrrDk+c2mPez5A3j3OHrnXUegdSXNMas03DdnpGrH4zo4XRLkFwPvuJfhs1hrha3jiCT+B2zrMp3D7Jyba33OVokrP/XNwKDsVaWOtw== 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=znP5SpnI/cMwEB4EhgClkMyYQsCK0LbApXBLX7bkMKU=; b=htoaHlKT4is6QWxEwstOosGOthqIRcaLr2JJHZ+5TWjTAhXgXyYUPMPR2nmH/1hjzAqZcc0GUbFYozp1YYFLwKcDrMWY+6nx8QtiQMUCKOeoxjt2cPF8x1R4a1W32TjFROqXk6+sRwSB5ulZeeyqdjj7JqTocYpO4vUjaZ1qbIxd0Sxp0K09lFR7LbicNECMRHBesQfkssiktN/ap9/1dLKbAZhw7d5/SBj0pmMt/L4PgS17GEFzMjTF9fd8VpDNlYYKbjV08gs7M0siqEyzqbRDHzLCzMiL15ZjOG9mc7qHiZi0y+S3ThsnT2nVgqtzZpinOksazBenz0eapMzTkg== 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=znP5SpnI/cMwEB4EhgClkMyYQsCK0LbApXBLX7bkMKU=; b=sUk8Lqtd0mKKbYnn8t7YlCvoVL8e174LXOVzvh71Hl0NEgLW8yT4VJZe+ewTbp/BQFUqHJBj1FoY5nbbUbil+XtnWDcabXPbLyjsr3m3D9Vxdu4+3uEayjrHcIhlkQEbg13ncNZknsukNt2rEOWIGHevtVnT/kjUzGFN9ZDk0XU= Received: from SN6PR11MB2749.namprd11.prod.outlook.com (2603:10b6:805:5f::16) by SN6PR11MB3072.namprd11.prod.outlook.com (2603:10b6:805:d8::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.14; Fri, 15 Oct 2021 15:01:52 +0000 Received: from SN6PR11MB2749.namprd11.prod.outlook.com ([fe80::2c4b:e64:c430:46de]) by SN6PR11MB2749.namprd11.prod.outlook.com ([fe80::2c4b:e64:c430:46de%7]) with mapi id 15.20.4587.032; Fri, 15 Oct 2021 15:01:52 +0000 From: "Bertrand Duvivier (bduvivie)" To: "spring@ietf.org" CC: "james.n.guichard@futurewei.com" , "shay.zadok=40broadcom.com@dmarc.ietf.org" , "bertrand@duvivier.com" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: AQHXwdT1hkMD/xwKf062EjYpQWWpnw== Date: Fri, 15 Oct 2021 15:01:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1dc50041-1d29-465b-c6fc-08d98fecb8b2 x-ms-traffictypediagnostic: SN6PR11MB3072: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aBQn+v/8JJkEmQ53Sfk8hx/ISXCogB5ZeoRNNce8iTko34mw5v1TiM4rRa6uW2H/ZzKcsOYadF3g8ymlg7EsR502oSPpT5GZungkpx9miCOcs1PKs7cNLPkz4brmWM3TKGioR9QNvSbsX0JQg7pmLIMUnma1XMhg4gEFyIwSHMC8qc38nBJvsljIRAZQqPDr2GSnEfJ/V/5q32r1EMM2pZLabrnYBdJjBPhYidtVe/WdCdjIKytXG2qZVFkCARUyDKzvgPi9rhNB4yrLfPFtN5L9Qeb4JNpEjVwUvid7ROBJV9mYM04MdkHf7cUyuz+r/sRbxfuJswf4sr2JkR3zHqMAuQIu0TMgGeI8Mxn4Ha00iZKuk5RA0ne0gtf+qZ6evz8EqJYpH96TmBkGRdqWPX5ZVswmfGgm+W9VODukTVu/drwqG79oa8E/ICiy0khI3a7PefXq/+fJEZrq79CuTSSPkhWdCozGbH6jYTj5FB0tg3TGRDQbeXDX0Q5ESXbHVxAkwVBrC5GHhHtFtj2tLRyL1JXs5EP7eRt6Xpgi/e2kLR7VRun0wtm4B8mMl7NH0Tcn4/Oc1aG9eLkLVAopO6isNXXVK9AgL/FJFnEUK4eFBI3EfEoJ/OH8czYa5wmWqiR+rVh1Z4VGvAwTsQffC4PBIauqFFW0lm43/5IXnp2C0yVCU+jhvbICHLHpIsmjRwJquDAUBSHY215E0/KvcBUw7MrG6DVo8IK/4nq4QNEcWMUFxSvqI9rTwSKm9TmKuQp0mMieJDqqe/l5CSeVf+Fgr92hLdd0B3Hgwc0g77cNF1TAa8LxYKaKIBk+mybquJNZzmGNPxOFtsfnafai/w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SN6PR11MB2749.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(7696005)(186003)(76116006)(86362001)(38100700002)(53546011)(26005)(166002)(6506007)(38070700005)(8936002)(83380400001)(8676002)(122000001)(66946007)(2906002)(33656002)(5660300002)(6916009)(966005)(66446008)(64756008)(71200400001)(9686003)(91956017)(66476007)(66556008)(4326008)(508600001)(55016002)(316002)(54906003)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bVdyMWpHT05aS05SSGtzeFM0VjNSdzZUeGRoRG43RnRKdTRCV3QyOTBJTEZa?= =?utf-8?B?QjZzakFMbnVTQWtwVTg4bzl1dnJObUpnTitsUW50b0E5K0lKNHRnWmQxT2FT?= =?utf-8?B?dlVwTW55YlozakNSUlo3aDQ1cWxTWEp5QVIyZ1R5cEZ3MW41OFNFd3NJU3Vn?= =?utf-8?B?MEtaSHFNcE9YL0hpd092bVNYT0JQaEQ3KzNDRnRta1NSRTgrNWdvZkFIYkQz?= =?utf-8?B?L3pwSGRDZDcwL2xKdjlhVitqcnNsWEdzOTAydkRZKzR4MmdKQXRTMFNRdDJy?= =?utf-8?B?NmhrYVJRSGFaTXV0Ynh6VGxHOUxMSTRUZTdCSTBQclhvSWg0MThvWGF3OGgy?= =?utf-8?B?R2lEVU5DUlpqU04zYXZqMHJKZk1ZdTByVEZxL09MMnlyT2pYWjVSVithWlh6?= =?utf-8?B?NitaVlM5VHhEOWFHZ2NNeWVhN3dzOXZscklmQVVPNGRpODZBOTdqQk5sWFVM?= =?utf-8?B?VDZacERPcDErbkFUWllXYnBSY0JxZFlhRmlFVS95b3Rlczcvc2ZXV2JhZUdR?= =?utf-8?B?RzhYQXdScEw5VzZ0WU45emd1K2NyVkJscE82ZkQ3em9aWUdOTEsvV056WmxQ?= =?utf-8?B?cGlGMXZvaEVSZ2FQdzlIZnd6bzlpZmFKdlZScmtKR1pESy9pS1IrL2lFNEJ4?= =?utf-8?B?OWdqdElqeTJ6N1Q5QXJYOFkzeWVIcytSNDlYME9SNjZuTE5NbmJTV0hUdEhD?= =?utf-8?B?N0o1T2h5T3ZQMENpQkJZcUNKQ05CK3JHbFRQdkJYRGgxTmE4MFN1WDhRd2pO?= =?utf-8?B?QU9IcUM2WnFxeU1zVS93TFIwcmVFN2ZrVjQyS2JhR0xXdXJuRUVLZkl0TW9h?= =?utf-8?B?WGpDR2sweWt6Z1NyNWQvTEE2VTE4TXFTWE9SMjFMWjdaQ0QyTlllblhXa0Ux?= =?utf-8?B?S2VTTGNQcTNoejhsa1RjZUhpdlVIeXZXYkx2ZEl3Z0o5dEZUc1IxNnBlcjh0?= =?utf-8?B?WVptT3BuZElvcU5aL1psK3JDNkloSW9zRHFhZ1dURWNpREEwdVZOV3pnNDNq?= =?utf-8?B?UTVPU1Jra1NmSSsxcGhpVWU3STNoV3dJOVlYMWdlM1cyWnJsNjQ0am1GT2Va?= =?utf-8?B?czZvbkNCZmErT1lYZGFiUjViU3RoRHpwbCt6T2czUnlWbkdrOWtpNTBka2lq?= =?utf-8?B?ajdUOEV4NDFSSDBuTEliZlZRcjVOb08xM3hMbm9SQmIxSVVBeFU1RXc4UWJH?= =?utf-8?B?T1VBK1RWanRldG93cVNrdU5mOENyTUpZOUtSZDFaVk44Y0lMNWVPMXg0Z3Jy?= =?utf-8?B?QjVWdXRWS2xxaE91WlVQa3hVUkdhUGZnSGVzTkFRSi92ZTRzZEtLOWNXcnNC?= =?utf-8?B?dWFwbzRlT1ArSTEzajAvVU1aVXRWYURNNU01WWVybG5hbDZKdXNaNHFFSHd6?= =?utf-8?B?SkFnUkJhM094cUdOckEzbEF0dzNQa2F1alRPSnROYzRUSTMyaW42UUk3bTZN?= =?utf-8?B?emYwQlFydnQ2VDRJSGEzVUswd3NQbHZkU1c3ZzNuemRsOTRSM09MTmxEemlt?= =?utf-8?B?L3Q0eFJiMElDbDdEVmRjOHo5TGh4TzV5TkFmczlBR0dMUnVIZFB1MFJDVVpU?= =?utf-8?B?VVpzaW8vUHpkcURlaFdHVXF3amFER1kxdGNOVTVOV3dScmIxZWdDRVc1eE1G?= =?utf-8?B?M2s3L3pTTUY2STdyMlIvcXlCUENiYjhTYi8yRldJNHZ6ZkUyQXRsSHkvcjU3?= =?utf-8?B?U1ZxTXdTeDF6Q1pLMW9iaVkyODcrVUl0SmpiYldiTkV6a2cyYTZmbkdPbFZk?= =?utf-8?B?cGdsL1pDOXlmbDF2b3R4cHJRZThZejN0L1laWitBMmlJbkxXUU9DV0VnanJR?= =?utf-8?B?N2VveWI3cFUvWDEvcFY0Zz09?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SN6PR11MB2749DA200645295C71FC1147D6B99SN6PR11MB2749namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SN6PR11MB2749.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1dc50041-1d29-465b-c6fc-08d98fecb8b2 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2021 15:01:52.2104 (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: h6Yvaqp5OFMy4h7uMFC5wCX7hio6LRRElpBagHIXUKdWH7RW3Fhyao4sG5E3t3Pi0ufxcoX+Icsn6/1l5wulxQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB3072 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xbe-aln-001.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 15 Oct 2021 15:03:18 -0000 --_000_SN6PR11MB2749DA200645295C71FC1147D6B99SN6PR11MB2749namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBXb3JraW5nIEdyb3VwLA0KDQoNCkkgd291bGQgbGlrZSB0byBjb25maXJtIHRoYXQgQ2lz Y28gcGFydGljaXBhdGVkIHRvIHRoZSBpbnRlcm9wcyBtZW50aW9uZWQgYnkgU2hheS4gVGhleSB3 ZXJlIGFsbOKAr3N1Y2Nlc3NmdWwgYW5kIGxlZCB0byBkZXBsb3ltZW50cy4NCg0KDQpJIHdvdWxk IGxpa2UgdG8gcmVtaW5kIHRoYXQgQ2lzY28gaGFzIGJlZW4gc2hpcHBpbmcgcHJvZHVjdHMgc3Vw cG9ydGluZyB0aGlzIGRyYWZ0IGZvciB+MTAgbW9udGhzLCBhY3Jvc3Mgb3VyIGhhcmR3YXJlIHBy b2R1Y3QgbGluZTrigK8NCsK3ICAgICAgICAgTkNTIDU1MDANCsK3ICAgICAgICAgTkNTIDU2MA0K wrcgICAgICAgICBOQ1MgNTQwDQrCtyAgICAgICAgIE5DUyA1NDAtTA0KwrcgICAgICAgICBBU1Ig OTAwMCAoVG9tYWhhd2spDQrCtyAgICAgICAgIEFTUiA5MDAwIChMaWdodFNwZWVkKQ0KwrcgICAg ICAgICBOQ1MgNTcwMCAoTmVhciBGQ1MpDQrCtyAgICAgICAgIFNpbGljb24gT25lIC0gODAwMCAo TmVhciBGQ1MpDQrCtyAgICAgICAgIFhSOTAwMCAodmlydHVhbCkNCg0KDQpJIHdvdWxkIGFsc28g bGlrZSB0byByZW1pbmQgdGhhdCBDaXNjbyBhbmQgUmFrdXRlbiBoYXZlIHB1YmxpY2x5IGNvbW11 bmljYXRlZCBvbiB0aGUgY29tbWVyY2lhbCBkZXBsb3ltZW50IG9mIHRoZSB0ZWNobm9sb2d5IHNw ZWNpZmllZCBpbiB0aGlzIGRyYWZ0LiBGdXJ0aGVybW9yZSwgdGhlIHRlY2hub2xvZ3kgaXMgYWxz byBkZXBsb3llZCBpbiBwcm9kdWN0aW9uIHdpdGggbGl2ZSB0cmFmZmljIGluIEJlbGwgQ2FuYWRh 4oCZcyBuZXR3b3JrIGluIGEgbXVsdGl2ZW5kb3IgZW52aXJvbm1lbnQuIFRoZXJlIGFyZSBhZGRp dGlvbmFsIHVuZGlzY2xvc2VkIGRlcGxveW1lbnRzLg0KDQoNCkkgc3Ryb25nbHkgc3VwcG9ydCB0 aGUgYWRvcHRpb24gb2YgdGhpcyBkcmFmdA0KDQoNCk9uIDE0IE9jdCAyMDIxLCBhdCAxMDo0OCwg U2hheSBaYWRvayA8c2hheS56YWRvaz00MGJyb2FkY29tLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWls dG86c2hheS56YWRvaz00MGJyb2FkY29tLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQpE ZWFyIFdHLA0KDQpXZSB3b3VsZCBsaWtlIHRvIHVwZGF0ZSBvbiB0aGUgcHJvZHVjdGlvbiBzdXBw b3J0IGJ5IHRoZSBTdHJhdGFETlggcHJvZHVjdHMgb2YgYm90aCBmbGF2b3JzIFJFUExBQ0UgYW5k IE5FWFQgYXMgZGVmaW5lZCBpbiBDU0lEIGRyYWZ0LCBhcyB3ZWxsIGFzIG5vbi1jb21wcmVzc2Vk ICJDbGFzc2ljIiBTUnY2Lg0KU3RyYXRhRE5YIHByb2R1Y3RzIGluY2x1ZGU6IEplcmljaG8yL0pl cmljaG8yYy9RdW1yYW4yYy9RdW1yYW4yYS9RdW1yYW4ydS9RdW1yYW4ybi9KZXJpY2hvMmMrIGFu ZCBhbnkgZnV0dXJlIGRldmljZQ0KDQpUaGlzIHN1cHBvcnQga2VlcHM6DQoxLiBTaW5nbGUgYW5k IHVuaWZpZWQgZGF0YS1wbGFuZSB1Q29kZSwgcHJvZ3JhbW1lZCB1c2luZyBoaWdoIGxldmVsIGxh bmd1YWdlDQoyLiBTaW5nbGUgZGF0YS1wbGFuZSBBUEkNCjMuIENvbmN1cnJlbnQvU2ltdWx0YW5l b3VzIHN1cHBvcnQgb2YgYWxsIHRocmVlIHRlY2huaXF1ZXMgYmFzZWQgb24gYSBwZXItcGFja2V0 IGJlaGF2aW9yDQo0LiBDb25jdXJyZW50L1NpbXVsdGFuZW91cyBzdXBwb3J0IG9mIGFsbCB0aHJl ZSB0ZWNobmlxdWVzIGluc2lkZSBvZiB0aGUgc2FtZSBTUnY2IEhlYWRlcg0KNS4gSW4gYWxsIHRo cmVlIHRlY2huaXF1ZXMgdGhlIGZvbGxvd2luZyBpcyBhbHJlYWR5IHN1cHBvcnRlZCBjb25jdXJy ZW50bHkvc2ltdWx0YW5lb3VzbHkgYW5kIGluIHByb2R1Y3Rpb24NCiAgICAxLiBTUnY2IG1haW4g YmVoYXZpb3JzIC0gY29tcGxpYW50IHdpdGggcmZjODk4Ng0KICAgIDIuIFNSdjYgaW5zZXJ0IGJl aGF2aW9ycyAtIGNvbXBsaWFudCB3aXRoIGRyYWZ0LXNydjYtbmV0LXBnbS1pbnNlcnRpb24NCiAg ICAzLiBTUnY2IG1pZHBvaW50IHByb3RlY3Rpb24gYmVoYXZpb3JzIC0gY29tcGxpYW50IHdpdGgg ZHJhZnQtbWlkcG9pbnQtcHJvdGVjdGlvbg0KDQpBbGwgb2YgdGhlIGFib3ZlIGlzIGluIHByb2R1 Y3Rpb24gZGVwbG95bWVudCBpbiB2YXJpb3VzIHB1Ymxpc2hlZCBhbmQgdW5wdWJsaXNoZWQgbmV0 d29ya3MgYXJvdW5kIHRoZSBnbG9iZS4NCk91ciBwcm9kdWN0cyBhcmUgdXNlZCBieSBpbmR1c3Ry eSBsZWFkaW5nIE9FTSAoc29tZSBvZiB0aGVtIHB1Ymxpc2hlZCB0aGV5IGFyZSB1c2luZyB0aGUg U3RyYXRhRE5YIHByb2R1Y3RzKSBhbmQgInB1cmUiIE5PUyB2ZW5kb3JzLg0KDQpCUkNNIHVzaW5n IEplcmljaG8yIHBhcnRpY2lwYXRlZCBpbiBjb3VwbGUgb2YgaW50ZXJvcHMgdGhhdCBpbmNsdWRl ZCBzb21lIG1peCBvZiBSRVBMQUNFLUNTSUQsIE5FWFQtQ1NJRCBhbmQgbm9uLWNvbXByZXNzZWQg IkNsYXNzaWMiIFNSdjYgLSBhbmQgYWxsIGludGVyb3BzIGhhdmUgZW5kZWQgc3VjY2Vzc2Z1bGx5 DQoNClRoYW5rcyAmIFJlZ2FyZHMsDQpTaGF5DQoNCg0KDQrlj5Hku7bkuro6IHNwcmluZyBbbWFp bHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9y Zz5dIOS7o+ihqCBKYW1lcyBHdWljaGFyZA0K5Y+R6YCB5pe26Ze0OiAyMDIx5bm0MTDmnIgx5pel IDIyOjA1DQrmlLbku7bkuro6IFNQUklORyBXRyA8c3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJp bmdAaWV0Zi5vcmc+Pg0K5oqE6YCBOiBzcHJpbmctY2hhaXJzQGlldGYub3JnPG1haWx0bzpzcHJp bmctY2hhaXJzQGlldGYub3JnPg0K5Li76aKYOiBbc3ByaW5nXSBXRyBBZG9wdGlvbiBjYWxsIGZv ciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNw cmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8NCg0KRGVhciBXRzoNCg0KVGhlIGNoYWlycyB3b3Vs ZCBsaWtlIHRvIGV4cHJlc3MgdGhlaXIgYXBwcmVjaWF0aW9uIGZvciBhbGwgdGhlIHJlc3BvbnNl cyByZWNlaXZlZCB0byBvdXIgZW1haWxzIHdpdGggcmVmZXJlbmNlIHRvIGhvdyB0aGUgd29ya2lu ZyBncm91cCB3aXNoZXMgdG8gbW92ZSBmb3J3YXJkIHdpdGggcmVzcGVjdCB0byBhIHNvbHV0aW9u IGZvciBTUnY2IGNvbXByZXNzaW9uLg0KDQpUaGUgYXBwYXJlbnQgaW5jbGluYXRpb24gb2YgdGhl IHdvcmtpbmcgZ3JvdXAgaXMgdG8gdXNlIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyBhcyB0aGUg YmFzaXMgZm9yIGl0cyBjb21wcmVzc2lvbiBzdGFuZGFyZGl6YXRpb24gd29yay4gVGhhdCBpcyBw YXJ0IG9mIHdoYXQgdGhpcyBlbWFpbCBhdHRlbXB0cyB0byBjb25maXJtLg0KDQpCZWNhdXNlIG9m IHRoZSBhYm92ZSB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gaXNzdWUgYSAyLXdlZWsgV0cgY2Fs bCBmb3IgYWRvcHRpb24gZW5kaW5nIE9jdG9iZXIgMTV0aCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJl c3Npb24vIGJ1dCB3aXRoIHNvbWUgY2xlYXIgZ3VpZGVsaW5lcyBhcyBmb2xsb3dzLiBCeSBleHBy ZXNzaW5nIHN1cHBvcnQgZm9yIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgeW91IGFyZSBmdWxs eSBhd2FyZSBvZiBhbmQgYXJlIGFja25vd2xlZGdpbmcgdGhhdDoNCg0KDQogIDEuICBUaGUgU1BS SU5HIHdvcmtpbmcgZ3JvdXAgaXMgYWRvcHRpbmcgYSBkb2N1bWVudCB0aGF0IGhhcyBtdWx0aXBs ZSBTUnY2IEVuZHBvaW50IGJlaGF2aW9ycy4NCiAgMi4gIFRoZSBkb2N1bWVudCBpcyBhIOKAnGxp dmluZ+KAnSBkb2N1bWVudDsgaXQgbWF5IGNoYW5nZSBhcyBpdCBnb2VzIHRocm91Z2ggcmV2aWV3 IGFuZCBhbmFseXNpcyBieSB0aGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAuDQogIDMuICBBbGwgb3Bl biBkaXNjdXNzaW9uIHBvaW50cyByYWlzZWQgb24gb3VyIG1haWxpbmcgbGlzdCBNVVNUIGJlIGFk ZHJlc3NlZCBCRUZPUkUgc2FpZCBkb2N1bWVudCBpcyBhbGxvd2VkIHRvIHByb2dyZXNzIGZyb20g dGhlIHdvcmtpbmcgZ3JvdXAgdG8gcHVibGljYXRpb24uIEEgbGlzdCBvZiB0aGVzZSBkaXNjdXNz aW9uIHBvaW50cyB3aWxsIGJlIGRvY3VtZW50ZWQgaW4gdGhlIFdHIGRvY3VtZW50IGFuZCBtYWlu dGFpbmVkIGJ5IHRoZSBkb2N1bWVudCBlZGl0b3IgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgY2hh aXJzLg0KICA0LiAgSWYgdGhpcyBkb2N1bWVudCBpcyBhZG9wdGVkIGJ5IHRoZSB3b3JraW5nIGdy b3VwLCB0aGUgY2hhaXJzIHNwZWNpZnkgYXMgcGFydCBvZiB0aGUgYWRvcHRpb24gY2FsbCB0aGF0 IHRoZSBmb2xsb3dpbmcgdGV4dCBkZXNjcmliaW5nIGFuIG9wZW4gaXNzdWUgYmUgYWRkZWQgdG8g dGhlIGRvY3VtZW50IGluIHRoZSBhYm92ZS1kZXNjcmliZWQgb3BlbiBpc3N1ZXMgc2VjdGlvbjoN Cg0KICAgICAqICAgIkdpdmVuIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHNhaWQgdGhhdCBp dCB3YW50cyB0byBzdGFuZGFyZGl6ZSBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiwgYW5kIGdpdmVu IHRoYXQgdGhlIGRvY3VtZW50IGNvbnRhaW5zIG11bHRpcGxlIFNSdjYgRW5kUG9pbnQgYmVoYXZp b3JzIHRoYXQgc29tZSBXRyBtZW1iZXJzIGhhdmUgc3RhdGVkIGFyZSBtdWx0aXBsZSBkYXRhIHBs YW5lIHNvbHV0aW9ucywgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhZGRyZXNzIHdoZXRoZXIgdGhp cyBpcyB2YWxpZCBhbmQgY29oZXJlbnQgd2l0aCBpdHMgb25lIGRhdGEgcGxhbmUgc29sdXRpb24g b2JqZWN0aXZlLiIuDQoNClBsZWFzZSBjb25zaWRlciB0aGUgYWJvdmUgZ3VpZGVsaW5lcyBhcyB5 b3UgZGVjaWRlIG9uIHdoZXRoZXIgdG8gc3VwcG9ydCBvciBub3QgdGhpcyBXRyBhZG9wdGlvbi4g UGxlYXNlIGV4cHJlc3MgY2xlYXJseSB5b3VyIHJlYXNvbmluZyBmb3Igc3VwcG9ydC9ub24tc3Vw cG9ydCBhcyB3ZWxsIGFzIGFueSBvcGVuIGRpc2N1c3Npb24gcG9pbnRzIHlvdSB3b3VsZCBsaWtl IGFkZHJlc3NlZCBzaG91bGQgdGhlIGRvY3VtZW50IGJlIGFkb3B0ZWQgaW50byB0aGUgd29ya2lu ZyBncm91cC4NCg0KVGhhbmtzIQ0KDQpKaW0sIEJydW5vICYgSm9lbA0KDQoNCg0KDQpUaGlzIGVs ZWN0cm9uaWMgY29tbXVuaWNhdGlvbiBhbmQgdGhlIGluZm9ybWF0aW9uIGFuZCBhbnkgZmlsZXMg dHJhbnNtaXR0ZWQgd2l0aCBpdCwgb3IgYXR0YWNoZWQgdG8gaXQsIGFyZSBjb25maWRlbnRpYWwg YW5kIGFyZSBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3Ig ZW50aXR5IHRvIHdob20gaXQgaXMgYWRkcmVzc2VkIGFuZCBtYXkgY29udGFpbiBpbmZvcm1hdGlv biB0aGF0IGlzIGNvbmZpZGVudGlhbCwgbGVnYWxseSBwcml2aWxlZ2VkLCBwcm90ZWN0ZWQgYnkg cHJpdmFjeSBsYXdzLCBvciBvdGhlcndpc2UgcmVzdHJpY3RlZCBmcm9tIGRpc2Nsb3N1cmUgdG8g YW55b25lIGVsc2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb3IgdGhl IHBlcnNvbiByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZyB0aGUgZS1tYWlsIHRvIHRoZSBpbnRl bmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgY29w eWluZywgZGlzdHJpYnV0aW5nLCBkaXNzZW1pbmF0aW9uLCBmb3J3YXJkaW5nLCBwcmludGluZywg b3IgY29weWluZyBvZiB0aGlzIGUtbWFpbCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3Ug cmVjZWl2ZWQgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSByZXR1cm4gdGhlIGUtbWFpbCB0 byB0aGUgc2VuZGVyLCBkZWxldGUgaXQgZnJvbSB5b3VyIGNvbXB1dGVyLCBhbmQgZGVzdHJveSBh bnkgcHJpbnRlZCBjb3B5IG9mIGl0Ll9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRv OnNwcmluZ0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c3ByaW5nDQoNCg== --_000_SN6PR11MB2749DA200645295C71FC1147D6B99SN6PR11MB2749namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpIZWx2ZXRpY2E7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OldpbmdkaW5nczsNCglwYW5vc2UtMTo1IDAg MCAwIDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseToiU2Vnb2UgVUkiOw0KCXBhbm9zZS0xOjIgMTEgNSAyIDQgMiA0 IDIgMiAzO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Ik1pY3Jvc29mdCBZYUhlaSI7DQoJ cGFub3NlLTE6MiAxMSA1IDMgMiAyIDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiXEBNaWNyb3NvZnQgWWFIZWkiO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4udGV4dHJ1bg0KCXttc28tc3R5bGUtbmFtZTp0ZXh0cnVuO30NCnNwYW4uZW9w DQoJe21zby1zdHlsZS1uYW1lOmVvcDt9DQpwLnBhcmFncmFwaCwgbGkucGFyYWdyYXBoLCBkaXYu cGFyYWdyYXBoDQoJe21zby1zdHlsZS1uYW1lOnBhcmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ow0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uc2N4dzMzMjk3NTkwDQoJe21zby1zdHlsZS1uYW1l OnNjeHczMzI5NzU5MDt9DQpzcGFuLm5vcm1hbHRleHRydW4NCgl7bXNvLXN0eWxlLW5hbWU6bm9y bWFsdGV4dHJ1bjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFt ZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEy LjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25z ICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMjEyMzc2NjAzOw0KCW1zby1saXN0LXRlbXBs YXRlLWlkczotMjY5MDY4NDcyO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjEzODU5MDQ2ODQ7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi01NzcxODg2Nzg7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w OjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxp c3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIx Ni4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MjA1Njky NTEwNTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE3MzAyNzk1MTA7fQ0KQGxpc3QgbDI6bGV2 ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDo0Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7 fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4t Ym90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iZW4tQkUiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBz dHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJ0ZXh0cnVuIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPkRlYXIgV29ya2luZyBHcm91cCwmbmJzcDs8 L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJlb3AiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9InBhcmFn cmFwaCIgc3R5bGU9Im1hcmdpbjowY207YmFja2dyb3VuZDp3aGl0ZTt2ZXJ0aWNhbC1hbGlnbjpi YXNlbGluZTstd2Via2l0LXVzZXItZHJhZzogbm9uZTtvdmVyZmxvdy13cmFwOiBicmVhay13b3Jk Oy13ZWJraXQtZm9udC1rZXJuaW5nOiBub25lO2NvbG9yOnJnYmEoMCwgMCwgMCwgMC44NDcpIj4N CjxzcGFuIGNsYXNzPSJlb3AiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGU7dmVydGljYWwtYWxpZ246YmFzZWxpbmUiPjxzcGFuIGNsYXNzPSJzY3h3MzMyOTc1 OTAiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFj ayI+SSB3b3VsZCBsaWtlIHRvIGNvbmZpcm0gdGhhdCBDaXNjbyBwYXJ0aWNpcGF0ZWQgdG8gdGhl Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0ibm9ybWFsdGV4dHJ1biI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj5pbnRlcm9wczwv c3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9InNjeHczMzI5NzU5MCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDttZW50aW9uZWQNCiBi eSZuYnNwO1NoYXkuJm5ic3A7VGhleSB3ZXJlIGFsbOKAr3N1Y2Nlc3NmdWwgYW5kIGxlZCZuYnNw O3RvJm5ic3A7ZGVwbG95bWVudHMuPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iZW9wIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJ JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW46MGNtO2JhY2tncm91bmQ6d2hpdGU7dmVy dGljYWwtYWxpZ246YmFzZWxpbmU7LXdlYmtpdC11c2VyLWRyYWc6IG5vbmU7b3ZlcmZsb3ctd3Jh cDogYnJlYWstd29yZDstd2Via2l0LWZvbnQta2VybmluZzogbm9uZTtjb2xvcjpyZ2JhKDAsIDAs IDAsIDAuODQ3KSI+DQo8c3BhbiBjbGFzcz0iZW9wIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJiYWNrZ3JvdW5kOndoaXRlO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lIj48c3BhbiBjbGFz cz0idGV4dHJ1biI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Nv bG9yOmJsYWNrIj5JIHdvdWxkJm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0ic2N4dzMz Mjk3NTkwIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6 YmxhY2siPmxpa2UNCiB0byZuYnNwO3JlbWluZCB0aGF0IENpc2NvIGhhcyBiZWVuIHNoaXBwaW5n IHByb2R1Y3RzJm5ic3A7c3VwcG9ydGluZyB0aGlzIGRyYWZ0IGZvciZuYnNwO34xMCZuYnNwO21v bnRocywgYWNyb3NzJm5ic3A7b3VyJm5ic3A7aGFyZHdhcmUmbmJzcDtwcm9kdWN0IGxpbmU64oCv PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iZW9wIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDo1NC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBs ZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOndoaXRlO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lIj4NCjwh W2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OlN5bWJvbDtjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGNsYXNzPSJ0ZXh0cnVuIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPk5DUyA1NTAwPC9zcGFuPjwv c3Bhbj48c3BhbiBjbGFzcz0iZW9wIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjU0LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0 OmwxIGxldmVsMSBsZm8xO2JhY2tncm91bmQ6d2hpdGU7dmVydGljYWwtYWxpZ246YmFzZWxpbmUi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6U3ltYm9sO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3Jl Ij7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gY2xhc3M9InRleHRydW4iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+TkNTIDU2MDwvc3Bh bj48L3NwYW4+PHNwYW4gY2xhc3M9ImVvcCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1NC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28t bGlzdDpsMSBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOndoaXRlO3ZlcnRpY2FsLWFsaWduOmJhc2Vs aW5lIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGNsYXNzPSJ0ZXh0cnVuIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPk5DUyA1NDA8 L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJlb3AiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTQuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7 bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzE7YmFja2dyb3VuZDp3aGl0ZTt2ZXJ0aWNhbC1hbGlnbjpi YXNlbGluZSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBjbGFzcz0idGV4dHJ1biI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj5OQ1Mg NTQwLUw8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJlb3AiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTQuMHB0O3RleHQtaW5kZW50Oi0x OC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzE7YmFja2dyb3VuZDp3aGl0ZTt2ZXJ0aWNhbC1h bGlnbjpiYXNlbGluZSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBjbGFzcz0ic2N4dzMz Mjk3NTkwIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6 YmxhY2siPkFTUiA5MDAwJm5ic3A7KFRvbWFoYXdrKTwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9 ImVvcCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDo1NC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMTti YWNrZ3JvdW5kOndoaXRlO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lIj4NCjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtj b2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0i Zm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFb ZW5kaWZdPjxzcGFuIGNsYXNzPSJzY3h3MzMyOTc1OTAiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+QVNSIDkwMDAmbmJzcDsoTGlnaHRTcGVl ZCk8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJlb3AiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTQuMHB0O3RleHQtaW5kZW50Oi0xOC4w cHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzE7YmFja2dyb3VuZDp3aGl0ZTt2ZXJ0aWNhbC1hbGln bjpiYXNlbGluZSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6YmxhY2siPjxzcGFuIHN0eWxlPSJtc28t bGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJv bWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBjbGFzcz0ic2N4dzMzMjk3 NTkwIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6Ymxh Y2siPk5DUyA1NzAwIChOZWFyIEZDUyk8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJlb3AiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NTQu MHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzE7YmFja2dyb3Vu ZDp3aGl0ZTt2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2w7Y29sb3I6Ymxh Y2siPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4w cHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48 c3BhbiBjbGFzcz0ic2N4dzMzMjk3NTkwIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPlNpbGljb24gT25lIC0mbmJzcDs4MDAwJm5ic3A7KE5l YXIgRkNTKSZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImVvcCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1NC4wcHQ7dGV4dC1p bmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOndoaXRlO3Zl cnRpY2FsLWFsaWduOmJhc2VsaW5lIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjpibGFjayI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtU aW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGNsYXNz PSJ0ZXh0cnVuIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29s b3I6YmxhY2siPlhSOTAwMCAodmlydHVhbCkmbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNz PSJlb3AiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8 L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6NTQuMHB0O2JhY2tncm91bmQ6d2hpdGU7dmVydGljYWwtYWxpZ246YmFzZWxpbmUiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2siPjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3Jv dW5kOndoaXRlO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lIj48c3BhbiBjbGFzcz0ic2N4dzMzMjk3 NTkwIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6Ymxh Y2siPkkmbmJzcDt3b3VsZCZuYnNwO2Fsc28mbmJzcDtsaWtlIHRvJm5ic3A7cmVtaW5kIHRoYXQg Q2lzY28gYW5kIFJha3V0ZW4gaGF2ZSBwdWJsaWNseSZuYnNwO2NvbW11bmljYXRlZCZuYnNwO29u Jm5ic3A7dGhlIGNvbW1lcmNpYWwmbmJzcDtkZXBsb3ltZW50DQogb2YgdGhlIHRlY2hub2xvZ3km bmJzcDtzcGVjaWZpZWQmbmJzcDtpbiB0aGlzIGRyYWZ0LiZuYnNwO0Z1cnRoZXJtb3JlLCB0aGUm bmJzcDt0ZWNobm9sb2d5Jm5ic3A7aXMgYWxzbyBkZXBsb3llZCBpbiBwcm9kdWN0aW9uIHdpdGgg bGl2ZSB0cmFmZmljIGluJm5ic3A7QmVsbCBDYW5hZGHigJlzJm5ic3A7bmV0d29yayZuYnNwO2lu IGEgbXVsdGl2ZW5kb3IgZW52aXJvbm1lbnQuJm5ic3A7VGhlcmUgYXJlIGFkZGl0aW9uYWwgdW5k aXNjbG9zZWQgZGVwbG95bWVudHMuJm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iZW9w Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Nl Z29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJwYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW46MGNtO2JhY2tncm91bmQ6d2hp dGU7dmVydGljYWwtYWxpZ246YmFzZWxpbmU7LXdlYmtpdC11c2VyLWRyYWc6IG5vbmU7b3ZlcmZs b3ctd3JhcDogYnJlYWstd29yZDstd2Via2l0LWZvbnQta2VybmluZzogbm9uZTtjb2xvcjpyZ2Jh KDAsIDAsIDAsIDAuODQ3KSI+DQo8c3BhbiBjbGFzcz0iZW9wIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlO3ZlcnRpY2FsLWFsaWduOmJhc2VsaW5lIj48c3Bh biBjbGFzcz0ic2N4dzMzMjk3NTkwIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Y29sb3I6YmxhY2siPkkmbmJzcDtzdHJvbmdseSZuYnNwO3N1cHBvcnQmbmJzcDt0 aGUmbmJzcDthZG9wdGlvbiZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2RyYWZ0PC9zcGFuPjwvc3Bh bj48c3BhbiBjbGFzcz0iZW9wIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpi bGFjayI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNrIj48YnI+DQo8 YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2 ZXRpY2E7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNh O2NvbG9yOmJsYWNrIj5PbiAxNCBPY3QgMjAyMSwgYXQgMTA6NDgsIFNoYXkgWmFkb2sgJmx0Ozxh IGhyZWY9Im1haWx0bzpzaGF5LnphZG9rPTQwYnJvYWRjb20uY29tQGRtYXJjLmlldGYub3JnIj5z aGF5LnphZG9rPTQwYnJvYWRjb20uY29tQGRtYXJjLmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6YmxhY2siPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNrIj5EZWFyIFdH LDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8 YnI+DQpXZSB3b3VsZCBsaWtlIHRvIHVwZGF0ZSBvbiB0aGUgcHJvZHVjdGlvbiBzdXBwb3J0IGJ5 IHRoZSBTdHJhdGFETlggcHJvZHVjdHMmbmJzcDtvZiBib3RoIGZsYXZvcnMgUkVQTEFDRSBhbmQg TkVYVCBhcyBkZWZpbmVkIGluIENTSUQgZHJhZnQsIGFzIHdlbGwgYXMgbm9uLWNvbXByZXNzZWQg JnF1b3Q7Q2xhc3NpYyZxdW90OyBTUnY2LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNrIj5TdHJhdGFETlgmbmJzcDtwcm9kdWN0cyBpbmNsdWRl OiBKZXJpY2hvMi9KZXJpY2hvMmMvUXVtcmFuMmMvUXVtcmFuMmEvUXVtcmFuMnUvUXVtcmFuMm4v SmVyaWNobzJjKyBhbmQgYW55IGZ1dHVyZSBkZXZpY2U8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt aWx5OkhlbHZldGljYTtjb2xvcjpibGFjayI+PGJyPg0KVGhpcyBzdXBwb3J0IGtlZXBzOjxicj4N CjEuIFNpbmdsZSBhbmQgdW5pZmllZCBkYXRhLXBsYW5lIHVDb2RlLCBwcm9ncmFtbWVkIHVzaW5n IGhpZ2ggbGV2ZWwgbGFuZ3VhZ2U8YnI+DQoyLiBTaW5nbGUgZGF0YS1wbGFuZSBBUEk8YnI+DQoz LiBDb25jdXJyZW50L1NpbXVsdGFuZW91cyBzdXBwb3J0IG9mIGFsbCB0aHJlZSB0ZWNobmlxdWVz IGJhc2VkIG9uIGEgcGVyLXBhY2tldCBiZWhhdmlvcjxicj4NCjQuIENvbmN1cnJlbnQvU2ltdWx0 YW5lb3VzIHN1cHBvcnQgb2YgYWxsIHRocmVlIHRlY2huaXF1ZXMgaW5zaWRlIG9mIHRoZSBzYW1l IFNSdjYgSGVhZGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6 YmxhY2siPjUuIEluIGFsbCB0aHJlZSB0ZWNobmlxdWVzIHRoZSBmb2xsb3dpbmcgaXMgYWxyZWFk eTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6 Ymx1ZSI+c3VwcG9ydGVkJm5ic3A7Y29uY3VycmVudGx5L3NpbXVsdGFuZW91c2x5DQogYW5kIGlu IHByb2R1Y3Rpb248L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTpIZWx2ZXRpY2E7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVs dmV0aWNhO2NvbG9yOmJsYWNrIj4mbmJzcDsgJm5ic3A7IDEuIFNSdjYgbWFpbiBiZWhhdmlvcnMg LSBjb21wbGlhbnQgd2l0aDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48Yj5yZmM4OTg2PC9iPjxicj4NCiZuYnNwOyAmbmJzcDsgMi4gU1J2NiBpbnNlcnQg YmVoYXZpb3JzIC0gY29tcGxpYW50IHdpdGg8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGI+ZHJhZnQtc3J2Ni1uZXQtcGdtLWluc2VydGlvbjwvYj48YnI+ DQombmJzcDsgJm5ic3A7IDMuIFNSdjYgbWlkcG9pbnQgcHJvdGVjdGlvbiBiZWhhdmlvcnMgLSBj b21wbGlhbnQgd2l0aDxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48Yj5kcmFmdC1taWRwb2ludC1wcm90ZWN0aW9uPC9iPjxicj4NCjxicj4NCkFsbCBvZiB0 aGUgYWJvdmUgaXMgaW4gcHJvZHVjdGlvbiBkZXBsb3ltZW50IGluIHZhcmlvdXMgcHVibGlzaGVk IGFuZCB1bnB1Ymxpc2hlZCBuZXR3b3JrcyBhcm91bmQgdGhlIGdsb2JlLjxicj4NCk91ciBwcm9k dWN0cyBhcmUgdXNlZCBieSBpbmR1c3RyeSBsZWFkaW5nIE9FTSAoc29tZSBvZiB0aGVtIHB1Ymxp c2hlZCB0aGV5IGFyZSB1c2luZyB0aGUgU3RyYXRhRE5YIHByb2R1Y3RzKSBhbmQgJnF1b3Q7cHVy ZSZxdW90OyBOT1MgdmVuZG9ycy48YnI+DQo8YnI+DQpCUkNNIHVzaW5nIEplcmljaG8yIHBhcnRp Y2lwYXRlZCBpbiBjb3VwbGUgb2YgaW50ZXJvcHMgdGhhdCBpbmNsdWRlZCBzb21lIG1peCBvZiBS RVBMQUNFLUNTSUQsIE5FWFQtQ1NJRCBhbmQgbm9uLWNvbXByZXNzZWQgJnF1b3Q7Q2xhc3NpYyZx dW90OyBTUnY2IC0gYW5kIGFsbCBpbnRlcm9wcyBoYXZlIGVuZGVkIHN1Y2Nlc3NmdWxseTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj48YnI+DQpUaGFua3MgJmFtcDsgUmVnYXJkcyw8YnI+DQpTaGF5PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjazttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9y OmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxhIG5hbWU9Im1fNjc0MzMwMTAzNTUzOTA3NDUxM19t Xy02OTA0NzIwNzU3MTQyMDAiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOm1f Njc0MzMwMTAzNTUzOTA3NDUxM19tXy02OTA0NzIwNzU3MTQyMDAiPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjazttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+5Y+R5Lu25Lq6PC9zcGFuPjwvYj48 Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjazttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNw O3NwcmluZw0KIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSZuYnNwOzwvc3Bh bj48Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjazttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+5Luj6KGoPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8 L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5KYW1lcw0KIEd1aWNoYXJkPGJyPg0KPC9zcGFu PjxiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO21zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj7lj5HpgIHml7bpl7Q8L3NwYW4+PC9iPjxiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jv c29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7MjAyMTwvc3Bh bj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjazttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+5bm0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4xMDwvc3Bh bj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTom cXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjazttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+5pyIPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4xPC9zcGFu PjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj7ml6U8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzIy OjA1PGJyPg0KPC9zcGFuPjxiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj7mlLbku7bkuro8L3NwYW4+PC9i PjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrO21zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5i c3A7U1BSSU5HDQogV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjwvc3Bhbj48Yj48c3BhbiBs YW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtNaWNy b3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+5oqE6YCBPC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Ojwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpzcHJpbmctY2hh aXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nLWNoYWlyc0BpZXRmLm9yZzwvYT48 YnI+DQo8L3NwYW4+PGI+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuS4u+mimDwvc3Bhbj48L2I+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDtbc3By aW5nXQ0KIFdHIEFkb3B0aW9uIGNhbGwgZm9yJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29t cHJlc3Npb24vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vPC9hPjwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtj b2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6YmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2 ZXRpY2E7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkRlYXIgV0c6PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2Nv bG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjazttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w cHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdl OlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZl dGljYTtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+VGhlIGNoYWlycyB3 b3VsZCBsaWtlIHRvIGV4cHJlc3MgdGhlaXIgYXBwcmVjaWF0aW9uIGZvciBhbGwgdGhlIHJlc3Bv bnNlcw0KIHJlY2VpdmVkIHRvIG91ciBlbWFpbHMgd2l0aCByZWZlcmVuY2UgdG8gaG93IHRoZSB3 b3JraW5nIGdyb3VwIHdpc2hlcyB0byBtb3ZlIGZvcndhcmQgd2l0aCByZXNwZWN0IHRvIGEgc29s dXRpb24gZm9yIFNSdjYgY29tcHJlc3Npb24uPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Okhl bHZldGljYTtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2Nv bG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjazttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+VGhlIGFwcGFyZW50IGluY2xpbmF0aW9uIG9mIHRoZSB3b3JraW5n IGdyb3VwIGlzIHRvIHVzZSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZp bHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLzwvYT4mbmJzcDthcw0KIHRo ZSBiYXNpcyBmb3IgaXRzIGNvbXByZXNzaW9uIHN0YW5kYXJkaXphdGlvbiB3b3JrLiBUaGF0IGlz IHBhcnQgb2Ygd2hhdCB0aGlzIGVtYWlsIGF0dGVtcHRzIHRvIGNvbmZpcm0uPC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNr O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m YW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xv cjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+QmVjYXVzZSBvZiB0aGUgYWJvdmUg dGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGlzc3VlIGEgMi13ZWVrIFdHIGNhbGwgZm9yDQogYWRv cHRpb24gZW5kaW5nIE9jdG9iZXIgMTU8c3VwPnRoPC9zdXA+Jm5ic3A7Zm9yJm5ic3A7PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1z cHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgt Y29tcHJlc3Npb24vPC9hPiZuYnNwO2J1dCB3aXRoIHNvbWUgY2xlYXINCiBndWlkZWxpbmVzIGFz IGZvbGxvd3MuIEJ5IGV4cHJlc3Npbmcgc3VwcG9ydCBmb3IgYWRvcHRpb24gb2YgdGhpcyBkb2N1 bWVudCB5b3UgYXJlIGZ1bGx5IGF3YXJlIG9mIGFuZCBhcmUgYWNrbm93bGVkZ2luZyB0aGF0Ojwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtj b2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6YmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSIxIj4N CjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzIiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p bHk6SGVsdmV0aWNhO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGUgU1BSSU5HIHdvcmtp bmcgZ3JvdXAgaXMgYWRvcHRpbmcgYSBkb2N1bWVudCB0aGF0IGhhcyBtdWx0aXBsZSBTUnY2IEVu ZHBvaW50IGJlaGF2aW9ycy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTpIZWx2ZXRpY2E7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+ PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjazttc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDps MCBsZXZlbDEgbGZvMiI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpIZWx2ZXRpY2E7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlRoZSBk b2N1bWVudCBpcyBhJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj7igJw8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO21z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5saXZpbmc8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04i IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuKAnTwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTpIZWx2ZXRpY2E7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwO2RvY3VtZW50Ow0K IGl0IG1heSBjaGFuZ2UgYXMgaXQgZ29lcyB0aHJvdWdoIHJldmlldyBhbmQgYW5hbHlzaXMgYnkg dGhlIFNQUklORyB3b3JraW5nIGdyb3VwLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku MHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86 cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJs YWNrO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z by1saXN0OmwwIGxldmVsMSBsZm8yIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+QWxsIG9wZW4gZGlzY3Vzc2lvbiBwb2ludHMgcmFpc2VkIG9uIG91ciBtYWlsaW5nIGxpc3Qg TVVTVCBiZSBhZGRyZXNzZWQgQkVGT1JFIHNhaWQgZG9jdW1lbnQgaXMgYWxsb3dlZCB0byBwcm9n cmVzcyBmcm9tIHRoZSB3b3JraW5nIGdyb3VwIHRvIHB1YmxpY2F0aW9uLiBBIGxpc3Qgb2YNCiB0 aGVzZSBkaXNjdXNzaW9uIHBvaW50cyB3aWxsIGJlIGRvY3VtZW50ZWQgaW4gdGhlIFdHIGRvY3Vt ZW50IGFuZCBtYWludGFpbmVkIGJ5IHRoZSBkb2N1bWVudCBlZGl0b3IgaW4gY29uanVuY3Rpb24g d2l0aCB0aGUgY2hhaXJzLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OkhlbHZldGljYTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48 L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOmJsYWNrO21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omww IGxldmVsMSBsZm8yIj4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0 O2ZvbnQtZmFtaWx5OkhlbHZldGljYTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SWYgdGhp cyBkb2N1bWVudCBpcyBhZG9wdGVkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLCB0aGUgY2hhaXJzIHNw ZWNpZnkgYXMgcGFydCBvZiB0aGUgYWRvcHRpb24gY2FsbCB0aGF0IHRoZSBmb2xsb3dpbmcgdGV4 dCBkZXNjcmliaW5nIGFuIG9wZW4gaXNzdWUgYmUgYWRkZWQgdG8gdGhlIGRvY3VtZW50DQogaW4g dGhlIGFib3ZlLWRlc2NyaWJlZCBvcGVuIGlzc3VlcyBzZWN0aW9uOjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9saT48L29sPg0KPG9sIHN0YXJ0PSI0IiB0 eXBlPSIxIj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Y29sb3I6YmxhY2s7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDIgbGV2ZWwyIGxmbzMiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj4mcXVvdDtHaXZlbiB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBzYWlkIHRo YXQgaXQgd2FudHMgdG8gc3RhbmRhcmRpemUgb25lIGRhdGEgcGxhbmUgc29sdXRpb24sIGFuZCBn aXZlbiB0aGF0IHRoZSBkb2N1bWVudCBjb250YWlucyBtdWx0aXBsZSBTUnY2IEVuZFBvaW50IGJl aGF2aW9ycyB0aGF0DQogc29tZSBXRyBtZW1iZXJzIGhhdmUgc3RhdGVkIGFyZSBtdWx0aXBsZSBk YXRhIHBsYW5lIHNvbHV0aW9ucywgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhZGRyZXNzIHdoZXRo ZXIgdGhpcyBpcyB2YWxpZCBhbmQgY29oZXJlbnQgd2l0aCBpdHMgb25lIGRhdGEgcGxhbmUgc29s dXRpb24gb2JqZWN0aXZlLiZxdW90Oy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpIZWx2ZXRpY2E7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+ PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZl dGljYTtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9y OmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjazttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+UGxlYXNlIGNvbnNpZGVyIHRoZSBhYm92ZSBndWlkZWxpbmVzIGFzIHlv dSBkZWNpZGUgb24gd2hldGhlciB0byBzdXBwb3J0DQogb3Igbm90IHRoaXMgV0cgYWRvcHRpb24u IFBsZWFzZSBleHByZXNzIGNsZWFybHkgeW91ciByZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9uLXN1 cHBvcnQgYXMgd2VsbCBhcyBhbnkgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyB5b3Ugd291bGQgbGlr ZSBhZGRyZXNzZWQgc2hvdWxkIHRoZSBkb2N1bWVudCBiZSBhZG9wdGVkIGludG8gdGhlIHdvcmtp bmcgZ3JvdXAuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhO2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFj azttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhO2NvbG9yOmJsYWNrO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ VGhhbmtzITwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Okhl bHZldGljYTtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6YmxhY2s7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjazttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh bWlseTpIZWx2ZXRpY2E7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkpp bSwgQnJ1bm8gJmFtcDsgSm9lbDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7 Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFj azttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5 LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt ZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYTtjb2xvcjpibGFjazttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls eTpIZWx2ZXRpY2E7Y29sb3I6YmxhY2siPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3 aGl0ZSI+VGhpcyBlbGVjdHJvbmljIGNvbW11bmljYXRpb24gYW5kIHRoZSBpbmZvcm1hdGlvbiBh bmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQsIG9yIGF0dGFjaGVkIHRvIGl0LCBhcmUg Y29uZmlkZW50aWFsIGFuZCBhcmUgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBp bmRpdmlkdWFsDQogb3IgZW50aXR5IHRvIHdob20gaXQgaXMgYWRkcmVzc2VkIGFuZCBtYXkgY29u dGFpbiBpbmZvcm1hdGlvbiB0aGF0IGlzIGNvbmZpZGVudGlhbCwgbGVnYWxseSBwcml2aWxlZ2Vk LCBwcm90ZWN0ZWQgYnkgcHJpdmFjeSBsYXdzLCBvciBvdGhlcndpc2UgcmVzdHJpY3RlZCBmcm9t IGRpc2Nsb3N1cmUgdG8gYW55b25lIGVsc2UuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQgb3IgdGhlIHBlcnNvbiByZXNwb25zaWJsZSBmb3IgZGVsaXZlcmluZw0KIHRoZSBl LW1haWwgdG8gdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJlYnkgbm90aWZpZWQg dGhhdCBhbnkgdXNlLCBjb3B5aW5nLCBkaXN0cmlidXRpbmcsIGRpc3NlbWluYXRpb24sIGZvcndh cmRpbmcsIHByaW50aW5nLCBvciBjb3B5aW5nIG9mIHRoaXMgZS1tYWlsIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQuIElmIHlvdSByZWNlaXZlZCB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIHJl dHVybiB0aGUgZS1tYWlsIHRvIHRoZQ0KIHNlbmRlciwgZGVsZXRlIGl0IGZyb20geW91ciBjb21w dXRlciwgYW5kIGRlc3Ryb3kgYW55IHByaW50ZWQgY29weSBvZiBpdC48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2E7Y29sb3I6YmxhY2siPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc3ByaW5n IG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPnNwcmlu Z0BpZXRmLm9yZzwvYT48YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NwcmluZzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Okhl bHZldGljYTtjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1HQiI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_SN6PR11MB2749DA200645295C71FC1147D6B99SN6PR11MB2749namp_-- From nobody Fri Oct 15 08:57:25 2021 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 EAAE93A0A63 for ; Fri, 15 Oct 2021 08:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, 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 vF7nL3-YjVnQ for ; Fri, 15 Oct 2021 08:57:19 -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 3AC373A0A5F for ; Fri, 15 Oct 2021 08:57:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4HW9rZ0F2Yz1pCF5 for ; Fri, 15 Oct 2021 08:57:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1634313438; bh=2MPlnXrEqs4BeIeqka5wY6lw6hHyWTajOJvfAwSS8gM=; h=Date:Subject:To:References:From:In-Reply-To:From; b=lFDg5m2a3e6F53k3nR6YLW3HR/cTwMB0GV6B9nSpcfI2PkEc9YqVz4mBOrzXPMW8a JqsxjbkDywqIjKzEsbQ11tIJGc3A4m2zyfNh0mrSbbJn+7A339PAga1I4nLcE93gql kVBuhAcV+/wjdbeGJnIBaJQeajqt2gfkW/q/bokI= X-Quarantine-ID: <35f5o83029Gv> X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.22.111] (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 4HW9rY438sz1ns43 for ; Fri, 15 Oct 2021 08:57:17 -0700 (PDT) Message-ID: <2c0dd98f-fc6a-06df-cc18-2ea1e8783713@joelhalpern.com> Date: Fri, 15 Oct 2021 11:57:16 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Content-Language: en-US To: "spring@ietf.org" References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> From: "Joel M. Halpern" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [spring] short term plan regarding adoption call for draft-filsfilscheng-spring-srv6-srh-compression 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, 15 Oct 2021 15:57:24 -0000 Given this note from the 6man leadership, and its indication of more information by the middle of next week, I am going to leave the adoption call open till we get that information. If their update is significantly delayed, I will have to decide what to do next. Assuming they do update us, I will see what that update does to the adoption call. Before I sign off, i want to explicitly thank all the working group participants who have responded to and discussed this adoption call. Whatever the difficulty of resolving this and finding a rough consensus, I very much appreciate and value the engagement. It is what makes the IETF work. Yours, Joel M. Halpern, SPRING co-Chair On 10/14/2021 1:04 PM, Erik Kline wrote: > Joel, > > Thank you for your email.  The ADs and chairs have been discussing. > > One thing that would be very helpful to our discussions would be some > worked examples of the various C-SID behaviors, showing some SRv6 > datagrams and what happens to their contents as they move across some > suitable example SR domain. > > (It would also be helpful if they showed what happens to something like > an ICMPv6 Echo Request to a representative Destination Address in these > cases when, say, an SRH is not present, i.e. to see when typical unicast > semantics are preserved or when something more like anycast or multicast > behavior is to be expected.) > > Assuming some forthcoming helpful examples, we have a goal to get a more > complete answer back to you by the latter half of next week. > > Thanks, > -Erik > > On Tue, Oct 12, 2021 at 8:53 PM Joel M. Halpern > wrote: > > The SPRING working group is in the midst of an adoption call on > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > . > > The SPRING charter has text that is explicit that modifications to data > planes and architectures standardized by other working groups may > not be > modified in SPRING unless the chairs and ADs responsible for that data > plane and / or architecture agree. > > To complete the context, as my SPRING co-chairs are co-authors on the > document in question, they have recused themselves from decisional > activities regarding the document.  Therefore, this message is coming > just from my as the responsible SPRING co-chair managing this > adoption call. > > As you have seen, multiple questions have been raised about the > relationship of the document to the IPv6 defined data plane and > architecture (particularly RFC 4291 and 8200). In particular the > questions seem to revolve around what the document describes as the > NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6 > standards.  (For those seeking more context without reading the full > document, a paraphrase and simplification of the NEXT-C_SID flavor is > provided as a postscript.) > > I raised the question of concurrence as required by the SPRING charter > with the Internet ADs and SPRING chairs.  They quite reasonably > asked me > to write a note to 6man explaining the concerns as clearly as a can, so > that they can then determine how to proceed. > > The questions that prompted my inquiry are: > > 1) Does the placement of a list of sids in the IPv6 DA field change the > IPv6 architectural description of that field. > 2) Does the operation of shifting information around in the IPv6 > destination address field represent a modification or extension of the > IPv6 data plane. > > On a related note, the document in question also defines two other > flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.  The > NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID > flavor operation, so seems to be affected by the same question. > >  From my own reading, it appears that the REPLACE-C-SID flavor does > not > raise issues requiring 6man leadership concurrence. > > Yours, > Joel M. Halpern for the SPRING working group > > > PS: > Clearly, understanding the question requires some understanding of what > the NEXT-C_SID flavor does.   This explanation is a simplification for > length and context.  Really, the best place to understand it is the > draft.  However, to give you enough information to let you decide > whether you care, I will try to provide a fair summary.  My > apologies in > advance to the authors for necessary liberties for length.  Also, > discussion of the draft contents (as distinct from the interaction with > the IPv6 data plane and architecture) belongs on the SPRING list, and > should not clutter up 6man. > > SIDs are the identifiers used in segment routing. > In SRv6, as document in the current RFCs, these are 128 bits.   As > defined in the relevant RFCs, SIDs which identify endpoints to which > packets are directed are identified by endpoint SIDs.  These can have > behaviors (decapsulate and forward is one example).  They can have > flavors such as where the SRH is removed. > > The topic under discussion is means to compress these SIDs in the > packets on the wire.  The document under discussion provides three > flavors of compression. > > The fundamental mechanism of the draft is to use a single SRH entry > as a > container for multiple SIDs.  In the NEXT-C_SID mechanism, when it is > first encountered the entire container is copied into the desination > address of the IPv6 packet.  The container has a common routing prefix > used for all the NEXT-C-SID SIDs.  It is followed by a sequence of > compressed SIDs of a configured length.  One could configure 16, 24, or > 32 bits.  Or whatever length.  The routing advertisements are arranged > so that the IPv6 packet is directed to the node represented by the > first > compressed SID on the basis of longest prefix match matching the > combination of the common routing prefix and that compressed SID. > > When the packet arrives at that node, it looks up the configured > portion, the compressed SID, and determines the behavior and > flavor.  In > the case of the NEXT-C-SID flavor, the resulting operation is to shift > the entire remaining contents of the IPv6 address (the bits past the > first compressed sid) so as to over-write the first compressed SID.  0 > bits are shifted into the low order positions.  If the result is a > non-zero new first compressed SID, then the packets is forwarded and > the > process repeats.  When all that is left are 0s, if there is an SRH, it > is consulted to find the next SRH entry, which is, per normal SRv6 > processing, put into the IPv6 DA. > Note that in the common case where the SIDS needed all fit in to a > single container, the analysis also assumes the use of the reduced > encapsulation options which omits the SRH that is not needed as it > would > have no entries.  This the packet contains a normal IPv6 header, with a > sequence of compressed SIDs (what one might or might not call a source > route) in the IPv6 destination address field. > > PPS: If the authors of the NEXT-C-SID flavor feel I have > mis-represented > the work, please, send clarifications or corrections.   Again, the best > source of information is the draft itself.  I was asked to provide > extra > context in this email. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > From nobody Fri Oct 15 09:00:59 2021 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 8D4E73A0A97 for ; Fri, 15 Oct 2021 09:00:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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=herbertland-com.20210112.gappssmtp.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 kQGzsTJx-taP for ; Fri, 15 Oct 2021 09:00:51 -0700 (PDT) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EF893A0A87 for ; Fri, 15 Oct 2021 09:00:51 -0700 (PDT) Received: by mail-ed1-x531.google.com with SMTP id t16so39933279eds.9 for ; Fri, 15 Oct 2021 09:00:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2EJnTdk1qMhMAY2154e9F9q3m+1kaipfORnOgzVzoS4=; b=HgHnLpj5FTBs+Nd6e1YL+0TKnhtTVgEDQCo1zshm1Xb4RV1JrtKxkyEoS/ZKqGryqC zzoQVUgdg9q4n0bWggZmMx2Ph7ZeLeQQrolN3SaYAEcu963denLWn5sSVStuI+At8Q8Z 6U0pFQ58jCtp9MrnJ/eFGcPQZayE+iA7I6vQTM+2ScdZAEvFWrxyvFKcZBmLYtTR9Bkh o//U/ZsW9Oo3JWOAkx/vEuYuFG/LqyztSOh0h8kty9LOH8cM8Qlt2eBuR6b4w1MuB3VP Xi3Azqb+rwcXONyNbwhUMKc0Q/cmuWY09ntKjxbKClvzX7Uf3Jrgytco5dwGeM95M87e MgWg== 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:content-transfer-encoding; bh=2EJnTdk1qMhMAY2154e9F9q3m+1kaipfORnOgzVzoS4=; b=1ORw6Tg9oZD/xTTmptLkD8xTVf/8vdnGizx7l7xB5t+tUttD5cf02aPbb0/A4j+Jfm VDt6T5D5xNj7HJQIHIHNpDQL56af2/jce8HJAOSFBnt65uTDJqZf+NLY+z4YQWxxH4BW Qfb12D7MFSO3SR+U6JtodJRG1H+Sv3H9OXbAAic3gtEOvVzuL2oaAH5+c14sAUsomGST TqLOjUmP9898UbzTfVEi1+QSHTJEPmaEpNDoO4X+wjpmo/ApOuU/WL5gjtyoRIBx9S6O dIu+uxkK2wiSfnQGC1BD+SNriq6WEt+CBhN+sLnfufyFcu15S8hxJvaSwTKpaYq4w9aN bz2A== X-Gm-Message-State: AOAM532bIMLpDbnKx+Lsmc5/+oApm85vzR4JzfzkBX35rV69+rO/Gpx7 1Qk0TRQ4uNbJ0vbY4HGVbhu2YWx0dOK9sfqAypv0ZQ== X-Google-Smtp-Source: ABdhPJwQ1N2WpkT4k5nnG6yicI02Pwk7jEmrkbpL7qGOSWlznOFDGL3yqqb4U/G0D98qdzib19g7VxP9RQnRsbotHlg= X-Received: by 2002:a17:906:48ce:: with SMTP id d14mr8099179ejt.336.1634313648841; Fri, 15 Oct 2021 09:00:48 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <1396_1634278622_61691CDE_1396_28_5_787AE7BB302AE849A7480A190F8B93303542C654@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: From: Tom Herbert Date: Fri, 15 Oct 2021 09:00:37 -0700 Message-ID: To: Mark Smith Cc: mohamed.boucadair@orange.com, SPRING WG , 6man WG Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 15 Oct 2021 16:00:57 -0000 On Fri, Oct 15, 2021 at 12:14 AM Mark Smith wrote: > > > > On Fri, 15 Oct 2021, 17:18 , wrote: >> >> Hi Joel , all, >> >> C-SID is no more than another mechanism that relies on some algorithmic = mapping embedded in the IPv6 address. We do have already many of such algor= ithmic approaches: RFC6052, RFC7597, etc. > > > > That's not correct. > > DAs aren't expected to change in fight, otherwise they will break all of = the transport layer protocols for which packet addresses are included in th= e transport layer checksum. Mark, they already do change courtesy of routing headers. Transport layer checksums are end to end and there's no requirement that the intermediate nodes can correctly compute transport layer checksums. NAT translation maintains the correct checksum, but routing headers do not, so unless an intermediate node is able to discern the final destination of the packet it won't be able to compute the correct checksum (this is a practical problem we are seeing with NICs that still insist on doing protocol specific checksum offload, in the presence of routing headers these devices can fail to offload RX checksum). > > In fight changing DAs also will break AH protection of the IPv6 header. SRH already breaks AH ;-) It's fixable and changing DAs in flight is compatible if it's prescribed that both the source and destination see the same destination address for AH processing. Tom > > DA changing in flight is NAT. I'd have thought the IETF had learnt that l= esson by now. > > Perhaps people need to read RFC2993 again. > >> >> >> The internal structure would be problematic if it requires that every in= termediate node on the path has to parse it, but this is not the case. The = packet is forwarded based on the DA following conventional procedures. The = procedure to determine the next SR hop is internal to an SR-capable node. >> >> Having examples of such SIDs in the draft would help to better understan= d the compression procedure, but no more than that as these will be display= ed as IPv6 addresses! >> >> Cheers, >> Med >> >> > -----Message d'origine----- >> > De : ipv6 De la part de Joel M. Halpern >> > Envoy=C3=A9 : mercredi 13 octobre 2021 09:37 >> > =C3=80 : ipv6@ietf.org >> > Cc : spring@ietf.org >> > Objet : Typo correction Re: Question from SPRING regarding draft- >> > filsfilscheng-spring-srv6-srh-compression >> > >> > There is a typo in the below which if not understood as a typo would b= e >> > quite confusing. I wrote that I raised the issue with >> > "with the Internet ADs and SPRING chairs". >> > That should have read "with the Internet ADs and 6man chairs". >> > The SPRING co-chairs are recused, and the charter requirement leads to= the >> > 6man chairs. Which is who I talked to. >> > >> > Also, I am sending a courtesy copy to the routing ADs, which I should = have >> > done originally. >> > >> > Thank you and enjoy. >> > Yours, >> > Joel >> > >> > On 10/12/2021 11:52 PM, Joel M. Halpern wrote: >> > > The SPRING working group is in the midst of an adoption call on >> > > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh= - >> > compression/. >> > > >> > > >> > > The SPRING charter has text that is explicit that modifications to >> > > data planes and architectures standardized by other working groups m= ay >> > > not be modified in SPRING unless the chairs and ADs responsible for >> > > that data plane and / or architecture agree. >> > > >> > > To complete the context, as my SPRING co-chairs are co-authors on th= e >> > > document in question, they have recused themselves from decisional >> > > activities regarding the document. Therefore, this message is comin= g >> > > just from my as the responsible SPRING co-chair managing this adopti= on >> > > call. >> > > >> > > As you have seen, multiple questions have been raised about the >> > > relationship of the document to the IPv6 defined data plane and >> > > architecture (particularly RFC 4291 and 8200). In particular the >> > > questions seem to revolve around what the document describes as the >> > > NEXT-C-SID flavor of compressed SID, and its relationship to the IPv= 6 >> > > standards. (For those seeking more context without reading the full >> > > document, a paraphrase and simplification of the NEXT-C_SID flavor i= s >> > > provided as a postscript.) >> > > >> > > I raised the question of concurrence as required by the SPRING chart= er >> > > with the Internet ADs and SPRING chairs. They quite reasonably aske= d >> > > me to write a note to 6man explaining the concerns as clearly as a >> > > can, so that they can then determine how to proceed. >> > > >> > > The questions that prompted my inquiry are: >> > > >> > > 1) Does the placement of a list of sids in the IPv6 DA field change >> > > the >> > > IPv6 architectural description of that field. >> > > 2) Does the operation of shifting information around in the IPv6 >> > > destination address field represent a modification or extension of t= he >> > > IPv6 data plane. >> > > >> > > On a related note, the document in question also defines two other >> > > flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The >> > > NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID >> > > flavor operation, so seems to be affected by the same question. >> > > >> > > From my own reading, it appears that the REPLACE-C-SID flavor does >> > > not raise issues requiring 6man leadership concurrence. >> > > >> > > Yours, >> > > Joel M. Halpern for the SPRING working group >> > > >> > > >> > > PS: >> > > Clearly, understanding the question requires some understanding of >> > > what the NEXT-C_SID flavor does. This explanation is a >> > > simplification for length and context. Really, the best place to >> > > understand it is the draft. However, to give you enough information >> > > to let you decide whether you care, I will try to provide a fair >> > > summary. My apologies in advance to the authors for necessary >> > > liberties for length. Also, discussion of the draft contents (as >> > > distinct from the interaction with the IPv6 data plane and >> > > architecture) belongs on the SPRING list, and should not clutter up >> > 6man. >> > > >> > > SIDs are the identifiers used in segment routing. >> > > In SRv6, as document in the current RFCs, these are 128 bits. As >> > > defined in the relevant RFCs, SIDs which identify endpoints to which >> > > packets are directed are identified by endpoint SIDs. These can hav= e >> > > behaviors (decapsulate and forward is one example). They can have >> > > flavors such as where the SRH is removed. >> > > >> > > The topic under discussion is means to compress these SIDs in the >> > > packets on the wire. The document under discussion provides three >> > > flavors of compression. >> > > >> > > The fundamental mechanism of the draft is to use a single SRH entry = as >> > > a container for multiple SIDs. In the NEXT-C_SID mechanism, when it >> > > is first encountered the entire container is copied into the >> > > desination address of the IPv6 packet. The container has a common >> > > routing prefix used for all the NEXT-C-SID SIDs. It is followed by = a >> > > sequence of compressed SIDs of a configured length. One could >> > > configure 16, 24, or >> > > 32 bits. Or whatever length. The routing advertisements are arrang= ed >> > > so that the IPv6 packet is directed to the node represented by the >> > > first compressed SID on the basis of longest prefix match matching t= he >> > > combination of the common routing prefix and that compressed SID. >> > > >> > > When the packet arrives at that node, it looks up the configured >> > > portion, the compressed SID, and determines the behavior and flavor. >> > > In the case of the NEXT-C-SID flavor, the resulting operation is to >> > > shift the entire remaining contents of the IPv6 address (the bits pa= st >> > > the first compressed sid) so as to over-write the first compressed >> > > SID. 0 bits are shifted into the low order positions. If the resul= t >> > > is a non-zero new first compressed SID, then the packets is forwarde= d >> > > and the process repeats. When all that is left are 0s, if there is = an >> > > SRH, it is consulted to find the next SRH entry, which is, per norma= l >> > > SRv6 processing, put into the IPv6 DA. >> > > Note that in the common case where the SIDS needed all fit in to a >> > > single container, the analysis also assumes the use of the reduced >> > > encapsulation options which omits the SRH that is not needed as it >> > > would have no entries. This the packet contains a normal IPv6 heade= r, >> > > with a sequence of compressed SIDs (what one might or might not call= a >> > > source >> > > route) in the IPv6 destination address field. >> > > >> > > PPS: If the authors of the NEXT-C-SID flavor feel I have >> > > mis-represented the work, please, send clarifications or corrections= . >> > > Again, the best source of information is the draft itself. I was >> > > asked to provide extra context in this email. >> > >> > -------------------------------------------------------------------- >> > IETF IPv6 working group mailing list >> > ipv6@ietf.org >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> > -------------------------------------------------------------------- >> >> ________________________________________________________________________= _________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confi= dentielles ou privilegiees et ne doivent donc >> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez r= ecu ce message par erreur, veuillez le signaler >> a l'expediteur et le detruire ainsi que les pieces jointes. 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 confidential or privileged = information 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 d= elete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have be= en modified, changed or falsified. >> Thank you. >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Fri Oct 15 11:36:25 2021 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 E35943A097E for ; Fri, 15 Oct 2021 11:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 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, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=liquidtelecom.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 n31H7hFlw_Ae for ; Fri, 15 Oct 2021 11:36:01 -0700 (PDT) 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 8856D3A0980 for ; Fri, 15 Oct 2021 11:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquidtelecom.com; s=mimecast20210406; t=1634322953; 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=Q3DrV7RoK0tV50w5A8aWTmZWwiXQ9zj3izEsdIS9Ark=; b=m6KBmNJvmLym72RkjFzdTnhBgvp9g/anFk3RLlaoTsl9EfVbimSS3/UAbdGbe7lDiEAaAX YKTnRADK5Zbrj+IPNGA1xAfdjzOvguf5857fyICQ4Ws4I+9WJGiN2UpZ7sJfNk/BiEcv+G T5zXG343eI5y3Dy0AdnAV/Tq1Tlau4s= Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05lp2110.outbound.protection.outlook.com [104.47.17.110]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-32-tnn2-H0TP8alE7RHOAL3Aw-2; Fri, 15 Oct 2021 19:35:50 +0100 X-MC-Unique: tnn2-H0TP8alE7RHOAL3Aw-2 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com (2603:10a6:20b:346::6) by AS8PR03MB7921.eurprd03.prod.outlook.com (2603:10a6:20b:424::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.15; Fri, 15 Oct 2021 18:35:48 +0000 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9]) by AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9%7]) with mapi id 15.20.4608.016; Fri, 15 Oct 2021 18:35:48 +0000 From: Andrew Alston To: "Joel M. Halpern" , "ipv6@ietf.org" CC: "spring@ietf.org" Thread-Topic: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression Thread-Index: AQHXv+XgSULF7Ea5WUWRAuZUPOIHz6vUmW+A Date: Fri, 15 Oct 2021 18:35:48 +0000 Message-ID: <4AF550FA-B350-45EF-85CD-AE7CB3F71132@liquidtelecom.com> References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> In-Reply-To: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.53.21091200 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: abcaba1d-2b50-47ee-c123-08d9900a9b88 x-ms-traffictypediagnostic: AS8PR03MB7921: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: pPrDbWv6hr2uw9eQq/udHwZIr/yVF2YQzc7TriBfO6DJU+kpZ9LdJZHelQDEmzzAoRLCOFCya8U6e1fTq+zZ9Bw3P1YtQgDT8eY/Ixn8wW0sVAu6vAGh/6VQkjjv9qOmIdUT/frpmPvbaZC6Xn3kDmHfxkYSdJjqVNpD6M2GewbhhehKhLDXDIPVPz9Vkx8dkgX4BdRz+Vmb2Pk7OjwZiyZLDnKf2LWCImnU45CbIRbt9z3a/MUoUP4bE3gR2rHIE2W/3od+CrsojfVFqnt+lj1ZZe39tF5ywGVX9h/d3HiyvbCauiOWf8X6xgLxmgBnDI9QxzbxpJ65wD2uumBIG0C6ppC1u3LEIQNBU08WPe9wMIvujNHya9aV4U69ZmMMIPy1O+aFfUuWeyO8R1oIYB5jTKTI7fSh4R4T/tiLfQgSMkWwPCBArRoa4VCuJ3OBuZ6gr5VrKGGMtj8n5+M5JTYeTNqk8/6qrrL/vsDMXKIC/gHpj367Q+uLlwR+/SjH8tvzde7s16b/ewN+B1vV9rWMCrcgg+NTCX+PMgHX0VjDz1FWRPLKJNyZS8zmhhlIWEner1pSLqKgSOJuWQ9vvgGCAbsct2GE+GsJzuQ5k8wI4+oiqA8xiF6pDWVIZ5LLovxN/WBp3jxDa1tlAzwG8bTDQWi7fB/u7WUpN+ltVE5+ZTAUmRuU7rdI72WDIAoxcZjQk7U7ASCMb6MUGmZJ2fFkHz8OUX/ZojVyp2+O+ZXV8JqlT4QuLPmooYFbJPQXmBfXLeka8sC3eQUmhmUpEmGqziKNja6gs0oRQjnNSoIzTlsgxkvFCUCVcR1tnxaq/O0pIHlnkKht5gZeoXHk1zMvG9w4T5EgztjZCxw0Nfk= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR03MB7622.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(86362001)(83380400001)(53546011)(508600001)(6506007)(66946007)(66476007)(66556008)(64756008)(66446008)(76116006)(91956017)(166002)(966005)(6512007)(66574015)(2616005)(36756003)(71200400001)(122000001)(2906002)(186003)(8936002)(4326008)(5660300002)(316002)(110136005)(8676002)(38070700005)(33656002)(38100700002)(6486002)(45980500001); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?RWMxQWx3MDNZQTBXczNzakRVRllFTmpiZEtMYU80ZVpXWnZTc2JaeUNBTkVB?= =?utf-8?B?RlQ0Q3F5QWFRYU4yeEpadXg0c3ZWeW5wbm9uRXRVa2hlUTJ5WDZ1NU5kNE94?= =?utf-8?B?ZnVsUjY0eDUwUEYwaUlieGYrVjdYUXZRRHhvR0JyVjlBcDdLSTRsQWNuN0Rs?= =?utf-8?B?WkRoRTZLdlF2N0puc2MzSGV5UGdZMmhkUytaNGZTOXk2VkdjTmdQUlJmNndR?= =?utf-8?B?cURlY0xvSStRT1Ftb3dGbGRpdzl1RjYvMGdSWVBrVUlRdHhFcUpKWGJkbG04?= =?utf-8?B?TG11ZjVHdEdnNlVXdGs3ZFN2M000d0tSSmEzQlJ6VnlvdDJDeHVrKy81ajdC?= =?utf-8?B?VDZHZ3ZBQTEwbzlhTUU3bkllQ24vaUhyQXNJbDcrRmt4ZXpVdmNjV1RvK1lk?= =?utf-8?B?dXE3RkxkbERvZjkzTXpSS1Y5WUJUTFRCNUpQZjltQk9lb3hJbTBUalBGakI5?= =?utf-8?B?ek1Wb1lNRTd6SVNLQU1TNkVWcnNUUUJadngwV0tTR2VmYnEycFRSWjk4UXNl?= =?utf-8?B?Ty9pVU5MNkNMWG5KczNNK1l1YUpBclUwcEJnd2R6VllsRmVObmYyY3lteS9i?= =?utf-8?B?eVg0QVdmMHR3N29NS1RoSHJoNFJGcnZncElreTkyMGcwS0d6M1FwaUFVRDJW?= =?utf-8?B?TkQzTVd2U1o3SnRPOGJ1Rlhrd2MxT293eHdBNUo2U2JDUE1FRTBaSmpqOW5y?= =?utf-8?B?Q2xiSGk5ZDJzY3hVcVM5VzUwVDYyekxwbDd5U1ZRMCt0SCs0cldUN3FVZWZm?= =?utf-8?B?OW9sV0JxZ2ZVTElkMEJRRHBOV3ZjZGthdnp3VVJmaHJhK0RidXlBZkViSGxt?= =?utf-8?B?ZVJsK1ErMDJZR1V1ZGVDY05DUlNNalRqT1ozckdaaTRNZ0lBN1NudENkTlpZ?= =?utf-8?B?SzA4emJROEQrL0FEUXpGMG1zM0FpanBndWZ0TXRmTFQ5SFZVSGQrNjBiR0Iw?= =?utf-8?B?S1dpcFZ3c1hlaThaN2pNcHY0UU1tSHhDN3J0cVBoQlhJbmt3NEM5QldkalYz?= =?utf-8?B?WVJPMG5PRjU1NFdwVW5UcDZoaVFwYnVMeVhJb1JCSDYwODFvVk1PMjgycU43?= =?utf-8?B?dFp4eHloK0lQQkNlNUdhdmdMSHZGZ09SWnFTM1MrRkhvaHVyblRFL0NQVDFV?= =?utf-8?B?bEtPOTVsVkZSeEtvUVRYQlN5UmVkZC9JT1NCQk1iMnNkZ3l0UlNwSVdNTk1P?= =?utf-8?B?RVhMb056cEV6cEFSNzBuczJBUmY0Z0liYWJLeElySUpsNDBtd1RheEdLWnMx?= =?utf-8?B?Wm9SQTB1Zjlkb2s1blNvV1hsNUk2RDliMHhCdC8yUWN3bno2N3dBSnJSTmla?= =?utf-8?B?a3pwL0hlN3NLaDl4ek96am0ySVd2bS82S29KWFNsZlpQU2VIMmtyUzhnSXA2?= =?utf-8?B?S0lQY0ZmSzdKN01PTDM2aW1kNHdMeG12QXhkZjZGVTdodlQzUGtCSG5sU251?= =?utf-8?B?LytJNHAvdWVVOWpJWFdscnp6MGx3SjdkdnJ2VXBxUHpBanJWR2VpakR6R1pl?= =?utf-8?B?Kzltc0F3UzJOWStiNy9JMisyZndYUEVFWDVTcVU3c1VVUDAvRVV0cmFnQ0tI?= =?utf-8?B?amRzVzVieVhZdUJlNjRxeW1Vb29OR0hjSitUSkNxZGtzYXEza0tiaXVjdFJM?= =?utf-8?B?b2FjajlwWVg0WVZBdXErakVaMVhxS1JUUmROdmRkTnpWQWlaR05GNFdvaFdt?= =?utf-8?B?QlBRWVhwRjQrUUdaZHd4TFV0YlR3S0EzUVN5Z3JkOXY1cmJqdHdwMmhSalpP?= =?utf-8?B?SS9TbXFXVENoQUVVMWxFN3RpZzBDSU5jYndhSjNBSVpQZktGV0VFRzJqRDU0?= =?utf-8?B?VzRPalhCKzduaWt3N0xoZzRGdUxSK2kvZXZyNGZoNmw4bnppT1Fsa0xlZUFr?= =?utf-8?Q?9k4JMbslFUJzW?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB7622.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: abcaba1d-2b50-47ee-c123-08d9900a9b88 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2021 18:35:48.1874 (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: fdtBW9n0hQ8sTh9C3iUffdiZmI0RLOBglALiSI4pTIRU4uR2JL+8pLIcwrMWxRslrkURw/Fms6CvPEhpcOrUTPP34TpcoG633eOEDcwdR98= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7921 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquidtelecom.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Language: en-GB Content-Type: multipart/alternative; boundary="_000_4AF550FAB35045EF85CDAE7CB3F71132liquidtelecomcom_" Archived-At: Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 15 Oct 2021 18:36:09 -0000 --_000_4AF550FAB35045EF85CDAE7CB3F71132liquidtelecomcom_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Sm9lbCwNCg0KDQogIDEuICBEb2VzIHRoZSBwbGFjZW1lbnQgb2YgYSBsaXN0IG9mIHNpZHMgaW4g dGhlIElQdjYgREEgZmllbGQgY2hhbmdlIHRoZSBJUHY2IGFyY2hpdGVjdHVyYWwgZGVzY3JpcHRp b24gb2YgdGhhdCBmaWVsZC4NCg0KDQpUbyB0aGlzIEkgd291bGQgc2F5IDEwMCUgeWVzIOKAkyBT ZWN0aW9uIDIgb2YgUkZDODIwMCBkZWZpbmVzIGFuIGFkZHJlc3MgYXMg4oCcYW4gSVB2Ni1MYXll ciBpZGVudGlmaWVyIGZvciBhbiBpbnRlcmZhY2Ugb3IgYSBzZXQgb2YgaW50ZXJmYWNlc+KAnSBh bmQgcmlnaHQgYWJvdmUgdGhhdCBpdCBkZXNjcmliZXMgYXMgYW4gaW50ZXJmYWNlIGFzIOKAnEEg bm9kZeKAmXMgYXR0YWNobWVudCB0byBhIGxpbmvigJ0uICBUaGUgZGVmaW5pdGlvbiBvZiBsaW5r IGFib3ZlIHRoYXQgYWxzbyBkb2VzIG5vdCBpbiBhbnkgd2F5IGhlbHAgdGhlIGNhc2UuICBXaGVu IHlvdSBwbGFjZSBhIGxpc3Qgb2YgU0lE4oCZcyBpbiB0aGUgREEgb2YgYSBmaWVsZCDigJMgeW91 IG5vIGxvbmdlciBoYXZlIGFuIGFkZHJlc3MgYnkgdGhlc2UgZGVmaW5pdGlvbnMg4oCTIHlvdSBo YXZlIOKAkyBzb21ldGhpbmcgZWxzZS4gIFllcyDigJMgaXQgY2FuIGJlIGNsZWFybHkgYXJndWVk IHRoYXQgdGhlIERBIGRvZXMgbm90IG5lZWQgdG8gcmVwcmVzZW50IHRoZSB1bHRpbWF0ZSBkZXN0 aW5hdGlvbiDigJMgYnV0IGl0IGlzIGhhcmQgdG8gZ2V0IGF3YXkgZnJvbSB0aGUgZmFjdCB0aGF0 IHRoaXMgZG9lcyBjaGFuZ2UgdGhlIGRlZmluaXRpb24gYXMgcGVyIHRoZSB0ZXJtaW5vbG9neSBz ZWN0aW9uLCBzaW5jZSB0aGUgYWRkcmVzcyBpcyBubyBsb25nZXIgcmVwcmVzZW50YXRpdmUgb2Yg YW4gaW50ZXJmYWNlIHRoYXQgcmVwcmVzZW50cyBhIG5vZGXigJlzIGF0dGFjaG1lbnQgdG8gYSBs aW5rIOKAkyBiZSBpdCB2aXJ0dWFsIG9yIG90aGVyZXdpc2UuDQoNCg0KDQogIDEuICBEb2VzIHRo ZSBvcGVyYXRpb24gb2Ygc2hpZnRpbmcgaW5mb3JtYXRpb24gYXJvdW5kIGluIHRoZSBJUHY2IGRl c3RpbmF0aW9uIGFkZHJlc3MgZmllbGQgcmVwcmVzZW50IGEgbW9kaWZpY2F0aW9uIG9yIGV4dGVu c2lvbiBvZiB0aGUgSVB2NiBkYXRhIHBsYW5lLg0KDQoNCg0KSSBhbSBhdCBhIGxvc3MgdG8gc2Vl IGhvdyB0aGlzIGNhbm5vdCBiZSBzZWVuIGFzIGEgbW9kaWZpY2F0aW9uIG9mIHRoZSBkYXRhIHBs YW5lLiAgWW91IGFyZSB0YWtpbmcgYW4gaW5ncmVzcyBwYWNrZXQg4oCTIG1vZGlmeWluZyB0aGUg REEgYmFzZWQgZWl0aGVyIG9uIHdoYXRzIGluIHRoZSBEQSBpdHNlbGYgKHdoaWNoIGlzIGEgbW9y ZSBjbGVhciBjdXQgY2FzZSDigJMgc2luY2UgeW91IGFyZSB1c2luZyB0aGUgYWRkcmVzcyB0byBt b2RpZnkgaXRzZWxmIOKAkyBhbmQgaXQgaXMgaW4gbm8gd2F5IGluIGxpbmUgd2l0aCB3aGF0IGlz IGRlc2NyaWJlZCBpbiBwb2ludCAxKSBvciBpbiB0aGUgY2FzZSBvZiB3aGVuIGFuIFNSSCBwYWNr ZXQgaXMgYXBwbGllZCDigJMgZGVyaXZpbmcgdGhlIERBIGluIHBhcnQgZnJvbSB0aGUgd2hhdCBp cyBjb250YWluZWQgaW4gdGhlIFNSSCBhbmQgaW4gcGFydCBmcm9tIHdoYXQgaXMgY29uZmlndXJl ZCBvbiB0aGUgZGV2aWNlLiAgQXMgc3VjaCB0aGUgU1JIIGl0c2VsZiBkb2VzIG5vdCDigJxsaXN0 IG9uZSBvciBtb3JlIGludGVybWVkaWF0ZSBub2RlcyB0byBiZSB2aXN0ZWTigJ0sIHRoYXQgaXMg ZGVyaXZlZCBpbmZvcm1hdGlvbiBhbmQgSSB3b3VsZCBhcmd1ZSBvdXRzaWRlIG9mIHRoZSBzcGVj LiAgVGhpcyBpcyBwYXJ0aWN1bGFybHkgcmVsZXZhbnQgY29uc2lkZXJpbmcgdGhhdCB0aGUgcGFj a2V0cyBkbyBub3QgY29udGFpbiBTSUQgbGVuZ3RoIGFuZCBtdWx0aXBsZSBTSUQgbGVuZ3RocyBh cmUgcG9zc2libGUsIGFzIHN1Y2ggZGVyaXZpbmcgdGhpcyBpbmZvcm1hdGlvbiBpcyBhIGZsZXhp YmxlIGJlaGF2aW9yIGluc2lkZSB0aGUgZGF0YSBwbGFuZSB0aGF0IGlzIG1vZGlmaWVkIGJ5IGNv bmZpZ3VyYXRpb24uDQoNCg0KDQpBcyBJIHN0YXRlZCBpbiBhbm90aGVyIGVtYWlsIOKAkyBpcnJl c3BlY3RpdmUgb2YgaG93IGNvbXBsZXggdGhlIHBzZXVkb2NvZGUgZ2V0cyDigJMgYW5kIGlmIHlv dSBhcmUgZGVyaXZpbmcgdGhlIGluZm9ybWF0aW9uIGZyb20gdGhlIFNSSCBvciBmcm9tIHRoZSBE QSBpdHNlbGYg4oCTIHRoZSB1bHRpbWF0ZSBjb25zZXF1ZW5jZSBvZiB0aGUgYmVoYXZpb3IgY2Fu IHN0aWxsIGJlIHN1bW1hcml6ZWQgYXMgZGFbbG9jYXRpb25fc2l6ZV0gPDwgc2lkX3NpemUuICBJ ZiB5b3UgY29weSB0aGF0IGluZm9ybWF0aW9uIG91dCBvZiB0aGUgcm91dGluZyBoZWFkZXIgaW4g YW4gb2JmdXNjYXRlZCB3YXkgb3Igbm90IOKAkyB0aGF0IGRvZXMgbm90IGNoYW5nZSB0aGUgb3V0 Y29tZSDigJMgYW5kIGluIGZhY3QgSSB3b3VsZCBhcmd1ZSB0aGF0IGFueSBzdGF0ZW1lbnRzIHRo YXQgYmVjYXVzZSB5b3UgY2FuIGNvcHkgcGFydHMgb2YgdGhlIERBIG91dCBvZiB0aGUgU1JIIGFu ZCBzb21lIGhvdyBkbyB0aGlzIHZpYSBhIGxlc3MgZWZmaWNpZW50IG1ldGhvZCB0byBhY2hpZXZl IHRoZSBzYW1lIHJlc3VsdCDigJMgZG8gbm90IHNvbHZlIHRoZSBpc3N1ZSBvZiBpZiB0aGlzIGlz IGEgbW9kaWZpY2F0aW9uIOKAkyBhbGwgdGhleSBkbyBpcyBjcmVhdGUgYSBzaXR1YXRpb24gd2hl cmUgdG8gYXZvaWQgYSBjbGFpbSBvZiBvZiBkYXRhIHBsYW5lIG1vZGlmaWNhdGlvbiwgcHNldWRv Y29kZSBpcyBwcm9wb3NlZCB0aGF0IGlzIHVubGlrZWx5IHRvIGV2ZXIgYmUgc2VlbiBpbiBhIHJl YWwgaW1wbGVtZW50YXRpb24gYmVjYXVzZSBvZiBlZmZpY2llbmN5IHJlYXNvbnMsIGFuZCBoZW5j ZSB3ZSBhcmUgaW4gYWxsIGxpa2VsaWhvb2QgYWNjZXB0aW5nIHN0YW5kYXJkaXphdGlvbiBvZiBh IG1ldGhvZCB0aGF0IHdlIGtub3cgbWF5IHdlbGwgYmUgdmlvbGF0ZWQgaW4gZXZlcnkgaW1wbGVt ZW50YXRpb24g4oCTIGZvciB0aGUgc2FrZSBvZiBtYWtpbmcgYSBjbGFpbSBvZiBsYWNrIG9mIHZp b2xhdGlvbiBvZiBhbm90aGVyIHN0YW5kYXJkLiAgVGhpcyBkb2VzbuKAmXQgc2l0IHdlbGwuDQoN ClRoYW5rcw0KDQpBbmRyZXcNCg0KDQoNCg0KRnJvbTogc3ByaW5nIDxzcHJpbmctYm91bmNlc0Bp ZXRmLm9yZz4gb24gYmVoYWxmIG9mICJKb2VsIE0uIEhhbHBlcm4iIDxqbWhAam9lbGhhbHBlcm4u Y29tPg0KRGF0ZTogV2VkbmVzZGF5LCAxMyBPY3RvYmVyIDIwMjEgYXQgMDY6NTMNClRvOiAiaXB2 NkBpZXRmLm9yZyIgPGlwdjZAaWV0Zi5vcmc+DQpDYzogInNwcmluZ0BpZXRmLm9yZyIgPHNwcmlu Z0BpZXRmLm9yZz4NClN1YmplY3Q6IFtzcHJpbmddIFF1ZXN0aW9uIGZyb20gU1BSSU5HIHJlZ2Fy ZGluZyBkcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbg0KDQpU aGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAgaXMgaW4gdGhlIG1pZHN0IG9mIGFuIGFkb3B0aW9uIGNh bGwgb24NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hl bmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLzxodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbj4u DQoNClRoZSBTUFJJTkcgY2hhcnRlciBoYXMgdGV4dCB0aGF0IGlzIGV4cGxpY2l0IHRoYXQgbW9k aWZpY2F0aW9ucyB0byBkYXRhDQpwbGFuZXMgYW5kIGFyY2hpdGVjdHVyZXMgc3RhbmRhcmRpemVk IGJ5IG90aGVyIHdvcmtpbmcgZ3JvdXBzIG1heSBub3QgYmUNCm1vZGlmaWVkIGluIFNQUklORyB1 bmxlc3MgdGhlIGNoYWlycyBhbmQgQURzIHJlc3BvbnNpYmxlIGZvciB0aGF0IGRhdGENCnBsYW5l IGFuZCAvIG9yIGFyY2hpdGVjdHVyZSBhZ3JlZS4NCg0KVG8gY29tcGxldGUgdGhlIGNvbnRleHQs IGFzIG15IFNQUklORyBjby1jaGFpcnMgYXJlIGNvLWF1dGhvcnMgb24gdGhlDQpkb2N1bWVudCBp biBxdWVzdGlvbiwgdGhleSBoYXZlIHJlY3VzZWQgdGhlbXNlbHZlcyBmcm9tIGRlY2lzaW9uYWwN CmFjdGl2aXRpZXMgcmVnYXJkaW5nIHRoZSBkb2N1bWVudC4gVGhlcmVmb3JlLCB0aGlzIG1lc3Nh Z2UgaXMgY29taW5nDQpqdXN0IGZyb20gbXkgYXMgdGhlIHJlc3BvbnNpYmxlIFNQUklORyBjby1j aGFpciBtYW5hZ2luZyB0aGlzIGFkb3B0aW9uIGNhbGwuDQoNCkFzIHlvdSBoYXZlIHNlZW4sIG11 bHRpcGxlIHF1ZXN0aW9ucyBoYXZlIGJlZW4gcmFpc2VkIGFib3V0IHRoZQ0KcmVsYXRpb25zaGlw IG9mIHRoZSBkb2N1bWVudCB0byB0aGUgSVB2NiBkZWZpbmVkIGRhdGEgcGxhbmUgYW5kDQphcmNo aXRlY3R1cmUgKHBhcnRpY3VsYXJseSBSRkMgNDI5MSBhbmQgODIwMCkuIEluIHBhcnRpY3VsYXIg dGhlDQpxdWVzdGlvbnMgc2VlbSB0byByZXZvbHZlIGFyb3VuZCB3aGF0IHRoZSBkb2N1bWVudCBk ZXNjcmliZXMgYXMgdGhlDQpORVhULUMtU0lEIGZsYXZvciBvZiBjb21wcmVzc2VkIFNJRCwgYW5k IGl0cyByZWxhdGlvbnNoaXAgdG8gdGhlIElQdjYNCnN0YW5kYXJkcy4gKEZvciB0aG9zZSBzZWVr aW5nIG1vcmUgY29udGV4dCB3aXRob3V0IHJlYWRpbmcgdGhlIGZ1bGwNCmRvY3VtZW50LCBhIHBh cmFwaHJhc2UgYW5kIHNpbXBsaWZpY2F0aW9uIG9mIHRoZSBORVhULUNfU0lEIGZsYXZvciBpcw0K cHJvdmlkZWQgYXMgYSBwb3N0c2NyaXB0LikNCg0KSSByYWlzZWQgdGhlIHF1ZXN0aW9uIG9mIGNv bmN1cnJlbmNlIGFzIHJlcXVpcmVkIGJ5IHRoZSBTUFJJTkcgY2hhcnRlcg0Kd2l0aCB0aGUgSW50 ZXJuZXQgQURzIGFuZCBTUFJJTkcgY2hhaXJzLiBUaGV5IHF1aXRlIHJlYXNvbmFibHkgYXNrZWQg bWUNCnRvIHdyaXRlIGEgbm90ZSB0byA2bWFuIGV4cGxhaW5pbmcgdGhlIGNvbmNlcm5zIGFzIGNs ZWFybHkgYXMgYSBjYW4sIHNvDQp0aGF0IHRoZXkgY2FuIHRoZW4gZGV0ZXJtaW5lIGhvdyB0byBw cm9jZWVkLg0KDQpUaGUgcXVlc3Rpb25zIHRoYXQgcHJvbXB0ZWQgbXkgaW5xdWlyeSBhcmU6DQoN CjEpIERvZXMgdGhlIHBsYWNlbWVudCBvZiBhIGxpc3Qgb2Ygc2lkcyBpbiB0aGUgSVB2NiBEQSBm aWVsZCBjaGFuZ2UgdGhlDQpJUHY2IGFyY2hpdGVjdHVyYWwgZGVzY3JpcHRpb24gb2YgdGhhdCBm aWVsZC4NCjIpIERvZXMgdGhlIG9wZXJhdGlvbiBvZiBzaGlmdGluZyBpbmZvcm1hdGlvbiBhcm91 bmQgaW4gdGhlIElQdjYNCmRlc3RpbmF0aW9uIGFkZHJlc3MgZmllbGQgcmVwcmVzZW50IGEgbW9k aWZpY2F0aW9uIG9yIGV4dGVuc2lvbiBvZiB0aGUNCklQdjYgZGF0YSBwbGFuZS4NCg0KT24gYSBy ZWxhdGVkIG5vdGUsIHRoZSBkb2N1bWVudCBpbiBxdWVzdGlvbiBhbHNvIGRlZmluZXMgdHdvIG90 aGVyDQpmbGF2b3JzLCBSRVBMQUNFLUMtU0lELCBhbmQgTkVYVC1hbmQtUkVQTEFDRS1DLVNJRC4g VGhlDQpORVhULWFuZC1SRVBMQUNFLUNfU0lEIGZsYXZvciBpcyBkZWZpbmVkIHRvIGluY2x1ZGUg dGhlIE5FWFQtQ19TSUQNCmZsYXZvciBvcGVyYXRpb24sIHNvIHNlZW1zIHRvIGJlIGFmZmVjdGVk IGJ5IHRoZSBzYW1lIHF1ZXN0aW9uLg0KDQpGcm9tIG15IG93biByZWFkaW5nLCBpdCBhcHBlYXJz IHRoYXQgdGhlIFJFUExBQ0UtQy1TSUQgZmxhdm9yIGRvZXMgbm90DQpyYWlzZSBpc3N1ZXMgcmVx dWlyaW5nIDZtYW4gbGVhZGVyc2hpcCBjb25jdXJyZW5jZS4NCg0KWW91cnMsDQpKb2VsIE0uIEhh bHBlcm4gZm9yIHRoZSBTUFJJTkcgd29ya2luZyBncm91cA0KDQoNClBTOg0KQ2xlYXJseSwgdW5k ZXJzdGFuZGluZyB0aGUgcXVlc3Rpb24gcmVxdWlyZXMgc29tZSB1bmRlcnN0YW5kaW5nIG9mIHdo YXQNCnRoZSBORVhULUNfU0lEIGZsYXZvciBkb2VzLiBUaGlzIGV4cGxhbmF0aW9uIGlzIGEgc2lt cGxpZmljYXRpb24gZm9yDQpsZW5ndGggYW5kIGNvbnRleHQuIFJlYWxseSwgdGhlIGJlc3QgcGxh Y2UgdG8gdW5kZXJzdGFuZCBpdCBpcyB0aGUNCmRyYWZ0LiBIb3dldmVyLCB0byBnaXZlIHlvdSBl bm91Z2ggaW5mb3JtYXRpb24gdG8gbGV0IHlvdSBkZWNpZGUNCndoZXRoZXIgeW91IGNhcmUsIEkg d2lsbCB0cnkgdG8gcHJvdmlkZSBhIGZhaXIgc3VtbWFyeS4gTXkgYXBvbG9naWVzIGluDQphZHZh bmNlIHRvIHRoZSBhdXRob3JzIGZvciBuZWNlc3NhcnkgbGliZXJ0aWVzIGZvciBsZW5ndGguIEFs c28sDQpkaXNjdXNzaW9uIG9mIHRoZSBkcmFmdCBjb250ZW50cyAoYXMgZGlzdGluY3QgZnJvbSB0 aGUgaW50ZXJhY3Rpb24gd2l0aA0KdGhlIElQdjYgZGF0YSBwbGFuZSBhbmQgYXJjaGl0ZWN0dXJl KSBiZWxvbmdzIG9uIHRoZSBTUFJJTkcgbGlzdCwgYW5kDQpzaG91bGQgbm90IGNsdXR0ZXIgdXAg Nm1hbi4NCg0KU0lEcyBhcmUgdGhlIGlkZW50aWZpZXJzIHVzZWQgaW4gc2VnbWVudCByb3V0aW5n Lg0KSW4gU1J2NiwgYXMgZG9jdW1lbnQgaW4gdGhlIGN1cnJlbnQgUkZDcywgdGhlc2UgYXJlIDEy OCBiaXRzLiBBcw0KZGVmaW5lZCBpbiB0aGUgcmVsZXZhbnQgUkZDcywgU0lEcyB3aGljaCBpZGVu dGlmeSBlbmRwb2ludHMgdG8gd2hpY2gNCnBhY2tldHMgYXJlIGRpcmVjdGVkIGFyZSBpZGVudGlm aWVkIGJ5IGVuZHBvaW50IFNJRHMuIFRoZXNlIGNhbiBoYXZlDQpiZWhhdmlvcnMgKGRlY2Fwc3Vs YXRlIGFuZCBmb3J3YXJkIGlzIG9uZSBleGFtcGxlKS4gVGhleSBjYW4gaGF2ZQ0KZmxhdm9ycyBz dWNoIGFzIHdoZXJlIHRoZSBTUkggaXMgcmVtb3ZlZC4NCg0KVGhlIHRvcGljIHVuZGVyIGRpc2N1 c3Npb24gaXMgbWVhbnMgdG8gY29tcHJlc3MgdGhlc2UgU0lEcyBpbiB0aGUNCnBhY2tldHMgb24g dGhlIHdpcmUuIFRoZSBkb2N1bWVudCB1bmRlciBkaXNjdXNzaW9uIHByb3ZpZGVzIHRocmVlDQpm bGF2b3JzIG9mIGNvbXByZXNzaW9uLg0KDQpUaGUgZnVuZGFtZW50YWwgbWVjaGFuaXNtIG9mIHRo ZSBkcmFmdCBpcyB0byB1c2UgYSBzaW5nbGUgU1JIIGVudHJ5IGFzIGENCmNvbnRhaW5lciBmb3Ig bXVsdGlwbGUgU0lEcy4gSW4gdGhlIE5FWFQtQ19TSUQgbWVjaGFuaXNtLCB3aGVuIGl0IGlzDQpm aXJzdCBlbmNvdW50ZXJlZCB0aGUgZW50aXJlIGNvbnRhaW5lciBpcyBjb3BpZWQgaW50byB0aGUg ZGVzaW5hdGlvbg0KYWRkcmVzcyBvZiB0aGUgSVB2NiBwYWNrZXQuIFRoZSBjb250YWluZXIgaGFz IGEgY29tbW9uIHJvdXRpbmcgcHJlZml4DQp1c2VkIGZvciBhbGwgdGhlIE5FWFQtQy1TSUQgU0lE cy4gSXQgaXMgZm9sbG93ZWQgYnkgYSBzZXF1ZW5jZSBvZg0KY29tcHJlc3NlZCBTSURzIG9mIGEg Y29uZmlndXJlZCBsZW5ndGguIE9uZSBjb3VsZCBjb25maWd1cmUgMTYsIDI0LCBvcg0KMzIgYml0 cy4gT3Igd2hhdGV2ZXIgbGVuZ3RoLiBUaGUgcm91dGluZyBhZHZlcnRpc2VtZW50cyBhcmUgYXJy YW5nZWQNCnNvIHRoYXQgdGhlIElQdjYgcGFja2V0IGlzIGRpcmVjdGVkIHRvIHRoZSBub2RlIHJl cHJlc2VudGVkIGJ5IHRoZSBmaXJzdA0KY29tcHJlc3NlZCBTSUQgb24gdGhlIGJhc2lzIG9mIGxv bmdlc3QgcHJlZml4IG1hdGNoIG1hdGNoaW5nIHRoZQ0KY29tYmluYXRpb24gb2YgdGhlIGNvbW1v biByb3V0aW5nIHByZWZpeCBhbmQgdGhhdCBjb21wcmVzc2VkIFNJRC4NCg0KV2hlbiB0aGUgcGFj a2V0IGFycml2ZXMgYXQgdGhhdCBub2RlLCBpdCBsb29rcyB1cCB0aGUgY29uZmlndXJlZA0KcG9y dGlvbiwgdGhlIGNvbXByZXNzZWQgU0lELCBhbmQgZGV0ZXJtaW5lcyB0aGUgYmVoYXZpb3IgYW5k IGZsYXZvci4gSW4NCnRoZSBjYXNlIG9mIHRoZSBORVhULUMtU0lEIGZsYXZvciwgdGhlIHJlc3Vs dGluZyBvcGVyYXRpb24gaXMgdG8gc2hpZnQNCnRoZSBlbnRpcmUgcmVtYWluaW5nIGNvbnRlbnRz IG9mIHRoZSBJUHY2IGFkZHJlc3MgKHRoZSBiaXRzIHBhc3QgdGhlDQpmaXJzdCBjb21wcmVzc2Vk IHNpZCkgc28gYXMgdG8gb3Zlci13cml0ZSB0aGUgZmlyc3QgY29tcHJlc3NlZCBTSUQuIDANCmJp dHMgYXJlIHNoaWZ0ZWQgaW50byB0aGUgbG93IG9yZGVyIHBvc2l0aW9ucy4gSWYgdGhlIHJlc3Vs dCBpcyBhDQpub24temVybyBuZXcgZmlyc3QgY29tcHJlc3NlZCBTSUQsIHRoZW4gdGhlIHBhY2tl dHMgaXMgZm9yd2FyZGVkIGFuZCB0aGUNCnByb2Nlc3MgcmVwZWF0cy4gV2hlbiBhbGwgdGhhdCBp cyBsZWZ0IGFyZSAwcywgaWYgdGhlcmUgaXMgYW4gU1JILCBpdA0KaXMgY29uc3VsdGVkIHRvIGZp bmQgdGhlIG5leHQgU1JIIGVudHJ5LCB3aGljaCBpcywgcGVyIG5vcm1hbCBTUnY2DQpwcm9jZXNz aW5nLCBwdXQgaW50byB0aGUgSVB2NiBEQS4NCk5vdGUgdGhhdCBpbiB0aGUgY29tbW9uIGNhc2Ug d2hlcmUgdGhlIFNJRFMgbmVlZGVkIGFsbCBmaXQgaW4gdG8gYQ0Kc2luZ2xlIGNvbnRhaW5lciwg dGhlIGFuYWx5c2lzIGFsc28gYXNzdW1lcyB0aGUgdXNlIG9mIHRoZSByZWR1Y2VkDQplbmNhcHN1 bGF0aW9uIG9wdGlvbnMgd2hpY2ggb21pdHMgdGhlIFNSSCB0aGF0IGlzIG5vdCBuZWVkZWQgYXMg aXQgd291bGQNCmhhdmUgbm8gZW50cmllcy4gVGhpcyB0aGUgcGFja2V0IGNvbnRhaW5zIGEgbm9y bWFsIElQdjYgaGVhZGVyLCB3aXRoIGENCnNlcXVlbmNlIG9mIGNvbXByZXNzZWQgU0lEcyAod2hh dCBvbmUgbWlnaHQgb3IgbWlnaHQgbm90IGNhbGwgYSBzb3VyY2UNCnJvdXRlKSBpbiB0aGUgSVB2 NiBkZXN0aW5hdGlvbiBhZGRyZXNzIGZpZWxkLg0KDQpQUFM6IElmIHRoZSBhdXRob3JzIG9mIHRo ZSBORVhULUMtU0lEIGZsYXZvciBmZWVsIEkgaGF2ZSBtaXMtcmVwcmVzZW50ZWQNCnRoZSB3b3Jr LCBwbGVhc2UsIHNlbmQgY2xhcmlmaWNhdGlvbnMgb3IgY29ycmVjdGlvbnMuIEFnYWluLCB0aGUg YmVzdA0Kc291cmNlIG9mIGluZm9ybWF0aW9uIGlzIHRoZSBkcmFmdCBpdHNlbGYuIEkgd2FzIGFz a2VkIHRvIHByb3ZpZGUgZXh0cmENCmNvbnRleHQgaW4gdGhpcyBlbWFpbC4NCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxp c3QNCnNwcmluZ0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zcHJpbmc8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc+DQoN Cg== --_000_4AF550FAB35045EF85CDAE7CB3F71132liquidtelecomcom_ Content-Type: text/html; charset=UTF-8 Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBz cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNv TGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5 OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJvdHRv bTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBE ZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MTgyODM1MjY5NTsNCgltc28t bGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTU5MjI5NDc1OCAxMzQ4 MDc1NjkgMTM0ODA3NTc3IDEzNDgwNzU3OSAxMzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OSAx MzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxl dmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2 ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs MDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFy Z2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9ImVuLUtF IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjaztiYWNrZ3Jv dW5kOndoaXRlIj5Kb2VsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFj aztiYWNrZ3JvdW5kOndoaXRlIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8b2wgc3R5 bGU9Im1hcmdpbi10b3A6MGNtIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJjb2xvcjpibGFjazttYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6 bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7YmFja2dyb3Vu ZDp3aGl0ZSI+RG9lcyB0aGUgcGxhY2VtZW50IG9mIGEgbGlzdCBvZiBzaWRzIGluIHRoZSBJUHY2 IERBIGZpZWxkIGNoYW5nZSB0aGUmbmJzcDtJUHY2IGFyY2hpdGVjdHVyYWwgZGVzY3JpcHRpb24g b2YgdGhhdCBmaWVsZC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPjxicj4N Cjxicj4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRlIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3NwYW4+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndo aXRlIj5UbyB0aGlzIEkgd291bGQgc2F5IDEwMCUgeWVzIOKAkyBTZWN0aW9uIDIgb2YgUkZDODIw MCBkZWZpbmVzIGFuIGFkZHJlc3MgYXMg4oCcYW4gSVB2Ni1MYXllciBpZGVudGlmaWVyIGZvciBh biBpbnRlcmZhY2Ugb3IgYSBzZXQgb2YgaW50ZXJmYWNlc+KAnSBhbmQgcmlnaHQgYWJvdmUNCiB0 aGF0IGl0IGRlc2NyaWJlcyBhcyBhbiBpbnRlcmZhY2UgYXMg4oCcQSBub2Rl4oCZcyBhdHRhY2ht ZW50IHRvIGEgbGlua+KAnS4mbmJzcDsgVGhlIGRlZmluaXRpb24gb2YgbGluayBhYm92ZSB0aGF0 IGFsc28gZG9lcyBub3QgaW4gYW55IHdheSBoZWxwIHRoZSBjYXNlLiZuYnNwOyBXaGVuIHlvdSBw bGFjZSBhIGxpc3Qgb2YgU0lE4oCZcyBpbiB0aGUgREEgb2YgYSBmaWVsZCDigJMgeW91IG5vIGxv bmdlciBoYXZlIGFuIGFkZHJlc3MgYnkgdGhlc2UgZGVmaW5pdGlvbnMg4oCTIHlvdQ0KIGhhdmUg 4oCTIHNvbWV0aGluZyBlbHNlLiZuYnNwOyBZZXMg4oCTIGl0IGNhbiBiZSBjbGVhcmx5IGFyZ3Vl ZCB0aGF0IHRoZSBEQSBkb2VzIG5vdCBuZWVkIHRvIHJlcHJlc2VudCB0aGUgdWx0aW1hdGUgZGVz dGluYXRpb24g4oCTIGJ1dCBpdCBpcyBoYXJkIHRvIGdldCBhd2F5IGZyb20gdGhlIGZhY3QgdGhh dCB0aGlzIGRvZXMgY2hhbmdlIHRoZSBkZWZpbml0aW9uIGFzIHBlciB0aGUgdGVybWlub2xvZ3kg c2VjdGlvbiwgc2luY2UgdGhlIGFkZHJlc3MgaXMgbm8gbG9uZ2VyDQogcmVwcmVzZW50YXRpdmUg b2YgYW4gaW50ZXJmYWNlIHRoYXQgcmVwcmVzZW50cyBhIG5vZGXigJlzIGF0dGFjaG1lbnQgdG8g YSBsaW5rIOKAkyBiZSBpdCB2aXJ0dWFsIG9yIG90aGVyZXdpc2UuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuNXB0O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHN0YXJ0PSIyIiB0eXBlPSIxIj4N CjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9ImNvbG9yOmJsYWNrO21hcmdpbi1s ZWZ0OjBjbTttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtiYWNrZ3JvdW5kOndoaXRlIj5Eb2VzIHRoZSBvcGVyYXRpb24gb2Ygc2hpZnRpbmcg aW5mb3JtYXRpb24gYXJvdW5kIGluIHRoZSBJUHY2Jm5ic3A7ZGVzdGluYXRpb24gYWRkcmVzcyBm aWVsZCByZXByZXNlbnQgYSBtb2RpZmljYXRpb24gb3IgZXh0ZW5zaW9uIG9mIHRoZSZuYnNwO0lQ djYgZGF0YSBwbGFuZS48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+SSBhbSBhdCBh IGxvc3MgdG8gc2VlIGhvdyB0aGlzIGNhbm5vdCBiZSBzZWVuIGFzIGEgbW9kaWZpY2F0aW9uIG9m IHRoZSBkYXRhIHBsYW5lLiZuYnNwOyBZb3UgYXJlIHRha2luZyBhbiBpbmdyZXNzIHBhY2tldCDi gJMgbW9kaWZ5aW5nIHRoZSBEQSBiYXNlZCBlaXRoZXIgb24gd2hhdHMNCiBpbiB0aGUgREEgaXRz ZWxmICh3aGljaCBpcyBhIG1vcmUgY2xlYXIgY3V0IGNhc2Ug4oCTIHNpbmNlIHlvdSBhcmUgdXNp bmcgdGhlIGFkZHJlc3MgdG8gbW9kaWZ5IGl0c2VsZiDigJMgYW5kIGl0IGlzIGluIG5vIHdheSBp biBsaW5lIHdpdGggd2hhdCBpcyBkZXNjcmliZWQgaW4gcG9pbnQgMSkgb3IgaW4gdGhlIGNhc2Ug b2Ygd2hlbiBhbiBTUkggcGFja2V0IGlzIGFwcGxpZWQg4oCTIGRlcml2aW5nIHRoZSBEQSBpbiBw YXJ0IGZyb20gdGhlIHdoYXQgaXMNCiBjb250YWluZWQgaW4gdGhlIFNSSCBhbmQgaW4gcGFydCBm cm9tIHdoYXQgaXMgY29uZmlndXJlZCBvbiB0aGUgZGV2aWNlLiZuYnNwOyBBcyBzdWNoIHRoZSBT UkggaXRzZWxmIGRvZXMgbm90IOKAnGxpc3Qgb25lIG9yIG1vcmUgaW50ZXJtZWRpYXRlIG5vZGVz IHRvIGJlIHZpc3RlZOKAnSwgdGhhdCBpcyBkZXJpdmVkIGluZm9ybWF0aW9uIGFuZCBJIHdvdWxk IGFyZ3VlIG91dHNpZGUgb2YgdGhlIHNwZWMuJm5ic3A7IFRoaXMgaXMgcGFydGljdWxhcmx5IHJl bGV2YW50IGNvbnNpZGVyaW5nDQogdGhhdCB0aGUgcGFja2V0cyBkbyBub3QgY29udGFpbiBTSUQg bGVuZ3RoIGFuZCBtdWx0aXBsZSBTSUQgbGVuZ3RocyBhcmUgcG9zc2libGUsIGFzIHN1Y2ggZGVy aXZpbmcgdGhpcyBpbmZvcm1hdGlvbiBpcyBhIGZsZXhpYmxlIGJlaGF2aW9yIGluc2lkZSB0aGUg ZGF0YSBwbGFuZSB0aGF0IGlzIG1vZGlmaWVkIGJ5IGNvbmZpZ3VyYXRpb24uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrO2Jh Y2tncm91bmQ6d2hpdGUiPkFzIEkgc3RhdGVkIGluIGFub3RoZXIgZW1haWwg4oCTIGlycmVzcGVj dGl2ZSBvZiBob3cgY29tcGxleCB0aGUgcHNldWRvY29kZSBnZXRzIOKAkyBhbmQgaWYgeW91IGFy ZSBkZXJpdmluZyB0aGUgaW5mb3JtYXRpb24gZnJvbSB0aGUgU1JIIG9yIGZyb20gdGhlIERBIGl0 c2VsZg0KIOKAkyB0aGUgdWx0aW1hdGUgY29uc2VxdWVuY2Ugb2YgdGhlIGJlaGF2aW9yIGNhbiBz dGlsbCBiZSBzdW1tYXJpemVkIGFzIGRhW2xvY2F0aW9uX3NpemVdICZsdDsmbHQ7IHNpZF9zaXpl LiZuYnNwOyBJZiB5b3UgY29weSB0aGF0IGluZm9ybWF0aW9uIG91dCBvZiB0aGUgcm91dGluZyBo ZWFkZXIgaW4gYW4gb2JmdXNjYXRlZCB3YXkgb3Igbm90IOKAkyB0aGF0IGRvZXMgbm90IGNoYW5n ZSB0aGUgb3V0Y29tZSDigJMgYW5kIGluIGZhY3QgSSB3b3VsZCBhcmd1ZSB0aGF0IGFueQ0KIHN0 YXRlbWVudHMgdGhhdCBiZWNhdXNlIHlvdSBjYW4gY29weSBwYXJ0cyBvZiB0aGUgREEgb3V0IG9m IHRoZSBTUkggYW5kIHNvbWUgaG93IGRvIHRoaXMgdmlhIGEgbGVzcyBlZmZpY2llbnQgbWV0aG9k IHRvIGFjaGlldmUgdGhlIHNhbWUgcmVzdWx0IOKAkyBkbyBub3Qgc29sdmUgdGhlIGlzc3VlIG9m IGlmIHRoaXMgaXMgYSBtb2RpZmljYXRpb24g4oCTIGFsbCB0aGV5IGRvIGlzIGNyZWF0ZSBhIHNp dHVhdGlvbiB3aGVyZSB0byBhdm9pZCBhIGNsYWltDQogb2Ygb2YgZGF0YSBwbGFuZSBtb2RpZmlj YXRpb24sIHBzZXVkb2NvZGUgaXMgcHJvcG9zZWQgdGhhdCBpcyB1bmxpa2VseSB0byBldmVyIGJl IHNlZW4gaW4gYSByZWFsIGltcGxlbWVudGF0aW9uIGJlY2F1c2Ugb2YgZWZmaWNpZW5jeSByZWFz b25zLCBhbmQgaGVuY2Ugd2UgYXJlIGluIGFsbCBsaWtlbGlob29kIGFjY2VwdGluZyBzdGFuZGFy ZGl6YXRpb24gb2YgYSBtZXRob2QgdGhhdCB3ZSBrbm93IG1heSB3ZWxsIGJlIHZpb2xhdGVkIGlu IGV2ZXJ5DQogaW1wbGVtZW50YXRpb24g4oCTIGZvciB0aGUgc2FrZSBvZiBtYWtpbmcgYSBjbGFp bSBvZiBsYWNrIG9mIHZpb2xhdGlvbiBvZiBhbm90aGVyIHN0YW5kYXJkLiZuYnNwOyBUaGlzIGRv ZXNu4oCZdCBzaXQgd2VsbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6Ymxh Y2s7YmFja2dyb3VuZDp3aGl0ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtjb2xvcjpibGFjaztiYWNrZ3JvdW5kOndoaXRlIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+QW5kcmV3 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hp dGUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJs YWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5zcHJpbmcgJmx0O3NwcmluZy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYg b2YgJnF1b3Q7Sm9lbCBNLiBIYWxwZXJuJnF1b3Q7ICZsdDtqbWhAam9lbGhhbHBlcm4uY29tJmd0 Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIDEzIE9jdG9iZXIgMjAyMSBhdCAwNjo1Mzxi cj4NCjxiPlRvOiA8L2I+JnF1b3Q7aXB2NkBpZXRmLm9yZyZxdW90OyAmbHQ7aXB2NkBpZXRmLm9y ZyZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O3NwcmluZ0BpZXRmLm9yZyZxdW90OyAmbHQ7c3By aW5nQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bc3ByaW5nXSBRdWVzdGlvbiBm cm9tIFNQUklORyByZWdhcmRpbmcgZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgt Y29tcHJlc3Npb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlIFNQUklORyB3b3JraW5nIGdyb3VwIGlzIGluIHRoZSBtaWRzdCBvZiBhbiBh ZG9wdGlvbiBjYWxsIG9uDQo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbiI+ aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJp bmctc3J2Ni1zcmgtY29tcHJlc3Npb24vPC9hPi48YnI+DQo8YnI+DQpUaGUgU1BSSU5HIGNoYXJ0 ZXIgaGFzIHRleHQgdGhhdCBpcyBleHBsaWNpdCB0aGF0IG1vZGlmaWNhdGlvbnMgdG8gZGF0YSA8 YnI+DQpwbGFuZXMgYW5kIGFyY2hpdGVjdHVyZXMgc3RhbmRhcmRpemVkIGJ5IG90aGVyIHdvcmtp bmcgZ3JvdXBzIG1heSBub3QgYmUgPGJyPg0KbW9kaWZpZWQgaW4gU1BSSU5HIHVubGVzcyB0aGUg Y2hhaXJzIGFuZCBBRHMgcmVzcG9uc2libGUgZm9yIHRoYXQgZGF0YSA8YnI+DQpwbGFuZSBhbmQg LyBvciBhcmNoaXRlY3R1cmUgYWdyZWUuPGJyPg0KPGJyPg0KVG8gY29tcGxldGUgdGhlIGNvbnRl eHQsIGFzIG15IFNQUklORyBjby1jaGFpcnMgYXJlIGNvLWF1dGhvcnMgb24gdGhlIDxicj4NCmRv Y3VtZW50IGluIHF1ZXN0aW9uLCB0aGV5IGhhdmUgcmVjdXNlZCB0aGVtc2VsdmVzIGZyb20gZGVj aXNpb25hbCA8YnI+DQphY3Rpdml0aWVzIHJlZ2FyZGluZyB0aGUgZG9jdW1lbnQuIFRoZXJlZm9y ZSwgdGhpcyBtZXNzYWdlIGlzIGNvbWluZyA8YnI+DQpqdXN0IGZyb20gbXkgYXMgdGhlIHJlc3Bv bnNpYmxlIFNQUklORyBjby1jaGFpciBtYW5hZ2luZyB0aGlzIGFkb3B0aW9uIGNhbGwuPGJyPg0K PGJyPg0KQXMgeW91IGhhdmUgc2VlbiwgbXVsdGlwbGUgcXVlc3Rpb25zIGhhdmUgYmVlbiByYWlz ZWQgYWJvdXQgdGhlIDxicj4NCnJlbGF0aW9uc2hpcCBvZiB0aGUgZG9jdW1lbnQgdG8gdGhlIElQ djYgZGVmaW5lZCBkYXRhIHBsYW5lIGFuZCA8YnI+DQphcmNoaXRlY3R1cmUgKHBhcnRpY3VsYXJs eSBSRkMgNDI5MSBhbmQgODIwMCkuIEluIHBhcnRpY3VsYXIgdGhlIDxicj4NCnF1ZXN0aW9ucyBz ZWVtIHRvIHJldm9sdmUgYXJvdW5kIHdoYXQgdGhlIGRvY3VtZW50IGRlc2NyaWJlcyBhcyB0aGUg PGJyPg0KTkVYVC1DLVNJRCBmbGF2b3Igb2YgY29tcHJlc3NlZCBTSUQsIGFuZCBpdHMgcmVsYXRp b25zaGlwIHRvIHRoZSBJUHY2IDxicj4NCnN0YW5kYXJkcy4gKEZvciB0aG9zZSBzZWVraW5nIG1v cmUgY29udGV4dCB3aXRob3V0IHJlYWRpbmcgdGhlIGZ1bGwgPGJyPg0KZG9jdW1lbnQsIGEgcGFy YXBocmFzZSBhbmQgc2ltcGxpZmljYXRpb24gb2YgdGhlIE5FWFQtQ19TSUQgZmxhdm9yIGlzIDxi cj4NCnByb3ZpZGVkIGFzIGEgcG9zdHNjcmlwdC4pPGJyPg0KPGJyPg0KSSByYWlzZWQgdGhlIHF1 ZXN0aW9uIG9mIGNvbmN1cnJlbmNlIGFzIHJlcXVpcmVkIGJ5IHRoZSBTUFJJTkcgY2hhcnRlciA8 YnI+DQp3aXRoIHRoZSBJbnRlcm5ldCBBRHMgYW5kIFNQUklORyBjaGFpcnMuIFRoZXkgcXVpdGUg cmVhc29uYWJseSBhc2tlZCBtZSA8YnI+DQp0byB3cml0ZSBhIG5vdGUgdG8gNm1hbiBleHBsYWlu aW5nIHRoZSBjb25jZXJucyBhcyBjbGVhcmx5IGFzIGEgY2FuLCBzbyA8YnI+DQp0aGF0IHRoZXkg Y2FuIHRoZW4gZGV0ZXJtaW5lIGhvdyB0byBwcm9jZWVkLjxicj4NCjxicj4NClRoZSBxdWVzdGlv bnMgdGhhdCBwcm9tcHRlZCBteSBpbnF1aXJ5IGFyZTo8YnI+DQo8YnI+DQoxKSBEb2VzIHRoZSBw bGFjZW1lbnQgb2YgYSBsaXN0IG9mIHNpZHMgaW4gdGhlIElQdjYgREEgZmllbGQgY2hhbmdlIHRo ZSA8YnI+DQpJUHY2IGFyY2hpdGVjdHVyYWwgZGVzY3JpcHRpb24gb2YgdGhhdCBmaWVsZC48YnI+ DQoyKSBEb2VzIHRoZSBvcGVyYXRpb24gb2Ygc2hpZnRpbmcgaW5mb3JtYXRpb24gYXJvdW5kIGlu IHRoZSBJUHY2IDxicj4NCmRlc3RpbmF0aW9uIGFkZHJlc3MgZmllbGQgcmVwcmVzZW50IGEgbW9k aWZpY2F0aW9uIG9yIGV4dGVuc2lvbiBvZiB0aGUgPGJyPg0KSVB2NiBkYXRhIHBsYW5lLjxicj4N Cjxicj4NCk9uIGEgcmVsYXRlZCBub3RlLCB0aGUgZG9jdW1lbnQgaW4gcXVlc3Rpb24gYWxzbyBk ZWZpbmVzIHR3byBvdGhlciA8YnI+DQpmbGF2b3JzLCBSRVBMQUNFLUMtU0lELCBhbmQgTkVYVC1h bmQtUkVQTEFDRS1DLVNJRC4gVGhlIDxicj4NCk5FWFQtYW5kLVJFUExBQ0UtQ19TSUQgZmxhdm9y IGlzIGRlZmluZWQgdG8gaW5jbHVkZSB0aGUgTkVYVC1DX1NJRCA8YnI+DQpmbGF2b3Igb3BlcmF0 aW9uLCBzbyBzZWVtcyB0byBiZSBhZmZlY3RlZCBieSB0aGUgc2FtZSBxdWVzdGlvbi48YnI+DQo8 YnI+DQpGcm9tIG15IG93biByZWFkaW5nLCBpdCBhcHBlYXJzIHRoYXQgdGhlIFJFUExBQ0UtQy1T SUQgZmxhdm9yIGRvZXMgbm90IDxicj4NCnJhaXNlIGlzc3VlcyByZXF1aXJpbmcgNm1hbiBsZWFk ZXJzaGlwIGNvbmN1cnJlbmNlLjxicj4NCjxicj4NCllvdXJzLDxicj4NCkpvZWwgTS4gSGFscGVy biBmb3IgdGhlIFNQUklORyB3b3JraW5nIGdyb3VwPGJyPg0KPGJyPg0KPGJyPg0KUFM6PGJyPg0K Q2xlYXJseSwgdW5kZXJzdGFuZGluZyB0aGUgcXVlc3Rpb24gcmVxdWlyZXMgc29tZSB1bmRlcnN0 YW5kaW5nIG9mIHdoYXQgPGJyPg0KdGhlIE5FWFQtQ19TSUQgZmxhdm9yIGRvZXMuIFRoaXMgZXhw bGFuYXRpb24gaXMgYSBzaW1wbGlmaWNhdGlvbiBmb3IgPGJyPg0KbGVuZ3RoIGFuZCBjb250ZXh0 LiBSZWFsbHksIHRoZSBiZXN0IHBsYWNlIHRvIHVuZGVyc3RhbmQgaXQgaXMgdGhlIDxicj4NCmRy YWZ0LiBIb3dldmVyLCB0byBnaXZlIHlvdSBlbm91Z2ggaW5mb3JtYXRpb24gdG8gbGV0IHlvdSBk ZWNpZGUgPGJyPg0Kd2hldGhlciB5b3UgY2FyZSwgSSB3aWxsIHRyeSB0byBwcm92aWRlIGEgZmFp ciBzdW1tYXJ5LiBNeSBhcG9sb2dpZXMgaW4gPGJyPg0KYWR2YW5jZSB0byB0aGUgYXV0aG9ycyBm b3IgbmVjZXNzYXJ5IGxpYmVydGllcyBmb3IgbGVuZ3RoLiBBbHNvLCA8YnI+DQpkaXNjdXNzaW9u IG9mIHRoZSBkcmFmdCBjb250ZW50cyAoYXMgZGlzdGluY3QgZnJvbSB0aGUgaW50ZXJhY3Rpb24g d2l0aCA8YnI+DQp0aGUgSVB2NiBkYXRhIHBsYW5lIGFuZCBhcmNoaXRlY3R1cmUpIGJlbG9uZ3Mg b24gdGhlIFNQUklORyBsaXN0LCBhbmQgPGJyPg0Kc2hvdWxkIG5vdCBjbHV0dGVyIHVwIDZtYW4u PGJyPg0KPGJyPg0KU0lEcyBhcmUgdGhlIGlkZW50aWZpZXJzIHVzZWQgaW4gc2VnbWVudCByb3V0 aW5nLjxicj4NCkluIFNSdjYsIGFzIGRvY3VtZW50IGluIHRoZSBjdXJyZW50IFJGQ3MsIHRoZXNl IGFyZSAxMjggYml0cy4gQXMgPGJyPg0KZGVmaW5lZCBpbiB0aGUgcmVsZXZhbnQgUkZDcywgU0lE cyB3aGljaCBpZGVudGlmeSBlbmRwb2ludHMgdG8gd2hpY2ggPGJyPg0KcGFja2V0cyBhcmUgZGly ZWN0ZWQgYXJlIGlkZW50aWZpZWQgYnkgZW5kcG9pbnQgU0lEcy4gVGhlc2UgY2FuIGhhdmUgPGJy Pg0KYmVoYXZpb3JzIChkZWNhcHN1bGF0ZSBhbmQgZm9yd2FyZCBpcyBvbmUgZXhhbXBsZSkuIFRo ZXkgY2FuIGhhdmUgPGJyPg0KZmxhdm9ycyBzdWNoIGFzIHdoZXJlIHRoZSBTUkggaXMgcmVtb3Zl ZC48YnI+DQo8YnI+DQpUaGUgdG9waWMgdW5kZXIgZGlzY3Vzc2lvbiBpcyBtZWFucyB0byBjb21w cmVzcyB0aGVzZSBTSURzIGluIHRoZSA8YnI+DQpwYWNrZXRzIG9uIHRoZSB3aXJlLiBUaGUgZG9j dW1lbnQgdW5kZXIgZGlzY3Vzc2lvbiBwcm92aWRlcyB0aHJlZSA8YnI+DQpmbGF2b3JzIG9mIGNv bXByZXNzaW9uLjxicj4NCjxicj4NClRoZSBmdW5kYW1lbnRhbCBtZWNoYW5pc20gb2YgdGhlIGRy YWZ0IGlzIHRvIHVzZSBhIHNpbmdsZSBTUkggZW50cnkgYXMgYSA8YnI+DQpjb250YWluZXIgZm9y IG11bHRpcGxlIFNJRHMuIEluIHRoZSBORVhULUNfU0lEIG1lY2hhbmlzbSwgd2hlbiBpdCBpcyA8 YnI+DQpmaXJzdCBlbmNvdW50ZXJlZCB0aGUgZW50aXJlIGNvbnRhaW5lciBpcyBjb3BpZWQgaW50 byB0aGUgZGVzaW5hdGlvbiA8YnI+DQphZGRyZXNzIG9mIHRoZSBJUHY2IHBhY2tldC4gVGhlIGNv bnRhaW5lciBoYXMgYSBjb21tb24gcm91dGluZyBwcmVmaXggPGJyPg0KdXNlZCBmb3IgYWxsIHRo ZSBORVhULUMtU0lEIFNJRHMuIEl0IGlzIGZvbGxvd2VkIGJ5IGEgc2VxdWVuY2Ugb2YgPGJyPg0K Y29tcHJlc3NlZCBTSURzIG9mIGEgY29uZmlndXJlZCBsZW5ndGguIE9uZSBjb3VsZCBjb25maWd1 cmUgMTYsIDI0LCBvciA8YnI+DQozMiBiaXRzLiBPciB3aGF0ZXZlciBsZW5ndGguIFRoZSByb3V0 aW5nIGFkdmVydGlzZW1lbnRzIGFyZSBhcnJhbmdlZCA8YnI+DQpzbyB0aGF0IHRoZSBJUHY2IHBh Y2tldCBpcyBkaXJlY3RlZCB0byB0aGUgbm9kZSByZXByZXNlbnRlZCBieSB0aGUgZmlyc3QgPGJy Pg0KY29tcHJlc3NlZCBTSUQgb24gdGhlIGJhc2lzIG9mIGxvbmdlc3QgcHJlZml4IG1hdGNoIG1h dGNoaW5nIHRoZSA8YnI+DQpjb21iaW5hdGlvbiBvZiB0aGUgY29tbW9uIHJvdXRpbmcgcHJlZml4 IGFuZCB0aGF0IGNvbXByZXNzZWQgU0lELjxicj4NCjxicj4NCldoZW4gdGhlIHBhY2tldCBhcnJp dmVzIGF0IHRoYXQgbm9kZSwgaXQgbG9va3MgdXAgdGhlIGNvbmZpZ3VyZWQgPGJyPg0KcG9ydGlv biwgdGhlIGNvbXByZXNzZWQgU0lELCBhbmQgZGV0ZXJtaW5lcyB0aGUgYmVoYXZpb3IgYW5kIGZs YXZvci4gSW4gPGJyPg0KdGhlIGNhc2Ugb2YgdGhlIE5FWFQtQy1TSUQgZmxhdm9yLCB0aGUgcmVz dWx0aW5nIG9wZXJhdGlvbiBpcyB0byBzaGlmdCA8YnI+DQp0aGUgZW50aXJlIHJlbWFpbmluZyBj b250ZW50cyBvZiB0aGUgSVB2NiBhZGRyZXNzICh0aGUgYml0cyBwYXN0IHRoZSA8YnI+DQpmaXJz dCBjb21wcmVzc2VkIHNpZCkgc28gYXMgdG8gb3Zlci13cml0ZSB0aGUgZmlyc3QgY29tcHJlc3Nl ZCBTSUQuIDAgPGJyPg0KYml0cyBhcmUgc2hpZnRlZCBpbnRvIHRoZSBsb3cgb3JkZXIgcG9zaXRp b25zLiBJZiB0aGUgcmVzdWx0IGlzIGEgPGJyPg0Kbm9uLXplcm8gbmV3IGZpcnN0IGNvbXByZXNz ZWQgU0lELCB0aGVuIHRoZSBwYWNrZXRzIGlzIGZvcndhcmRlZCBhbmQgdGhlIDxicj4NCnByb2Nl c3MgcmVwZWF0cy4gV2hlbiBhbGwgdGhhdCBpcyBsZWZ0IGFyZSAwcywgaWYgdGhlcmUgaXMgYW4g U1JILCBpdCA8YnI+DQppcyBjb25zdWx0ZWQgdG8gZmluZCB0aGUgbmV4dCBTUkggZW50cnksIHdo aWNoIGlzLCBwZXIgbm9ybWFsIFNSdjYgPGJyPg0KcHJvY2Vzc2luZywgcHV0IGludG8gdGhlIElQ djYgREEuPGJyPg0KTm90ZSB0aGF0IGluIHRoZSBjb21tb24gY2FzZSB3aGVyZSB0aGUgU0lEUyBu ZWVkZWQgYWxsIGZpdCBpbiB0byBhIDxicj4NCnNpbmdsZSBjb250YWluZXIsIHRoZSBhbmFseXNp cyBhbHNvIGFzc3VtZXMgdGhlIHVzZSBvZiB0aGUgcmVkdWNlZCA8YnI+DQplbmNhcHN1bGF0aW9u IG9wdGlvbnMgd2hpY2ggb21pdHMgdGhlIFNSSCB0aGF0IGlzIG5vdCBuZWVkZWQgYXMgaXQgd291 bGQgPGJyPg0KaGF2ZSBubyBlbnRyaWVzLiBUaGlzIHRoZSBwYWNrZXQgY29udGFpbnMgYSBub3Jt YWwgSVB2NiBoZWFkZXIsIHdpdGggYSA8YnI+DQpzZXF1ZW5jZSBvZiBjb21wcmVzc2VkIFNJRHMg KHdoYXQgb25lIG1pZ2h0IG9yIG1pZ2h0IG5vdCBjYWxsIGEgc291cmNlIDxicj4NCnJvdXRlKSBp biB0aGUgSVB2NiBkZXN0aW5hdGlvbiBhZGRyZXNzIGZpZWxkLjxicj4NCjxicj4NClBQUzogSWYg dGhlIGF1dGhvcnMgb2YgdGhlIE5FWFQtQy1TSUQgZmxhdm9yIGZlZWwgSSBoYXZlIG1pcy1yZXBy ZXNlbnRlZCA8YnI+DQp0aGUgd29yaywgcGxlYXNlLCBzZW5kIGNsYXJpZmljYXRpb25zIG9yIGNv cnJlY3Rpb25zLiBBZ2FpbiwgdGhlIGJlc3QgPGJyPg0Kc291cmNlIG9mIGluZm9ybWF0aW9uIGlz IHRoZSBkcmFmdCBpdHNlbGYuIEkgd2FzIGFza2VkIHRvIHByb3ZpZGUgZXh0cmEgPGJyPg0KY29u dGV4dCBpbiB0aGlzIGVtYWlsLjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCnNwcmlu Z0BpZXRmLm9yZzxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc3ByaW5nIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nwcmlu ZzwvYT48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_4AF550FAB35045EF85CDAE7CB3F71132liquidtelecomcom_-- From nobody Fri Oct 15 14:55:30 2021 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 AEC643A0C34; Fri, 15 Oct 2021 14:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=eaMZ+Et3; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Gqu1Tmzr 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 Y7gi6wFg5jca; Fri, 15 Oct 2021 14:55:21 -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 9E0D63A0C33; Fri, 15 Oct 2021 14:55:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19034; q=dns/txt; s=iport; t=1634334921; x=1635544521; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=JAlY6NJvP53eHuo2Vs+xm5hakIet4Pg2IgtzgrNm/Yc=; b=eaMZ+Et3iyS2uiyJmet18ev9MYzAgo9q9IfadJe+LyKQKdxsV5NZ8h8z 8OIWph3YbL9NMg3Mb+DNEKQ/q6NxKVlQndgV3sDNVV9oQILyAhLXLHo7F MXPorBKXAbmlLewD9A8RSMd04d4IdvO0HeyueEDDpIm0Lqd2Oim7Zvu7P 4=; X-IPAS-Result: =?us-ascii?q?A0AZAACb92lhl51dJa1QChwBAQEBAQEHAQESAQEEBAEBQ?= =?us-ascii?q?IFFBwEBCwGBIDAjLn5aNzGIDgOEWWCIDQOKdIp0hQqBLhSBEQNUCwEBAQ0BA?= =?us-ascii?q?SoBDAoEAQGEOUUCgkwCJTQJDgECBAEBAQEDAgMBAQEBBQEBBQEBAQIBBgQUA?= =?us-ascii?q?QEBAQEBAQGBCIVoDYZCAQEBAQMBARAuAQEsBAcBDwIBCA4DAQIBAigHIQYLF?= =?us-ascii?q?AMGCAIEAQ0FCBqCTwGBflcDLwEOoB8BgToCih94gTOBAYIIAQEGBASBSkGCf?= =?us-ascii?q?w0LgjUDBoE6AYMEgnZUSYZ2JxyBSUSBFAFDgmc+giFCAQEDgSgBBwsBBxweB?= =?us-ascii?q?gcJgxmCLot9EFsGFycmBAsXFhMIFA45BhpRAQ0EASUBASxFA5FcjD2NT5FEZ?= =?us-ascii?q?wqDMYEziRSOQIYHFINqi22XQZYIH4xQg0SQMyCEaQIEAgQFAg4BAQaBYTlrc?= =?us-ascii?q?HAVO4JpURkPgVmMRwwNCRWDO4UUhUp0OAIGCwEBAwmTIAEB?= IronPort-PHdr: A9a23:8yyXQxR6ba7VpR5SOo4ecrWxgNpso6HLVj580XJvo71Le6WnuZ/lO R+X6fZsiQrPWoPWo7JBhvHNuq/tEWoH/d6asX8EfZANMn1NicgfkwE6RsLQD0r9Ia3laiU7G IJJU1o2t32+OFJeTcD5YVCaq3au7DkUTxP4Mwc9Jun8FoPIycqt0OXn8JzIaAIOjz24MttP IronPort-Data: A9a23:z8zrr6DGesHfMxVW/xTjw5YqxClBgxIJ4kV8jS/XYbTApDsghj1Ty WsZXWGPbqyMYDH8Lo1xb4S09ElS6pWDyoAyOVdlrnsFo1CmBibm6XV1Cm+qYkt+++WaFBoPA /3z6bAsFehsJpPmjk/F3oPJ8D8siMlkepKmULSdY3goGFc+IMscoUsLd9AR09YAbeeRW2thi fuqyyEIEAb4s9LcGjt8B5Or8HuDjtyr0N8rlgBWicRwgbPrvyJ94KTzik2GByCQroF8RoZWT gtYpV2z1juxExwFUrtJnltnG6EHaua6AOSAtpZZc/O9hzdojAse6PwYF9AXR0cHtBuRr88kn b2htbToIesoFrfHlOJYWB5CHmQge6ZH47TAZ3O4tKR/zWWfLCCqmKooXRpwZNBHkgp0KTkmG fgwJjsJZxyrjOOty7X9Qe5p7igmBJa1Zt5E5is/lVk1C949U5D9BPnA5OVnxRJglMFJONbHe u4GPG8HgBPoOk0TZQh/5IgFtOawmCfXcjBEphSSv6Vfy3PL1g1335DsPcbbPNuQSq19nEOYj mDB8mD5CxUCOcaZjzGC9xqEi+yJnC7nVqodEbS58rhhh1j7+4AIIAcdWV3+qv6jhwvgHdleM EcTvCEpqMDe6XBHUPGmQBiXilSjkiRGePl6GMM6uD6j0prLtlPx6nc/chZNb9kvtckTTDMs1 0OUk96BOdCJmODJIZ563urIxQ5eKRT5PkdZP35YElFtD83L5dBt0UqVEb6PBYbs1oWtcQwc1 Qxmu8TXa187t88A16yh8UvAhVpATbCWE1Zlv207so9Zhz6Viaa/bICurFPc9/sFcsCST0KKu z4PnM32AAEy4XOlyXflrAYlRezBCxO53Nv02gUH834JrGjFxpJbVdoMiAyS3W8wWir+RRfnY VXIpSRa74JJMX2hYMdfOtzqV59wl/a4T4u6Dpg4i+aihLAsK2drGwkzOiatM5zFzCDAbIlmY 87AKJbwZZrkIf08l2LeqxghPU8Dn3Bimjy7qWHTxBW82r3Wf2+OVboAKzOzghMRssu5TPHu2 48HbaOikkwHOMWnO3W/2dNDfDgicClgbbir+pM/XrDYeGJORjp+Y8I9NJt8IuSJaYwOzbyWl px8M2cFoGfCaYrvd1vVMy45NOK+NXu9xFpiVRER0Z+T8yBLSe6SAG03LfPboZFPGDRf8MNJ IronPort-HdrOrdr: A9a23:Qs8LIqsf5m+Q6JuTqW58xQ7i7skC1IMji2hC6mlwRA09TyXGra GTdaUguyMc1gx/ZJh5o6H+BEGBKUmskqKdkrNhQ4tKPTOW+VdASbsD0WKM+UyaJ8STzJ856U 4kSdkDNDSSNyk7sS+Z2njDLz9I+rDum8rE6Za8vhVQpENRGtxdBmxCe2Cm+zhNNXF77O0CZe OhD6R81l6dUEVSSv7+KmgOXuDFqdGOvonhewQ6Cxku7xTLpS+06ZbheiLonSs2Yndq+/MP4G LFmwv26uGIqPeg0CLR0GfV8tB/hMbh8N1eH8aB4/JlaAkEyzzYIbiJaYfy+wzdk9vfrmrCV+ O8+ivICv4Dr085uFvF+ScFlTOQiwrGoEWSuGNwyUGT0fARAghKUfaoQeliA0fkA41KhqAg7E sD5RPri7NHSRzHhyjz/N7OSlVjkVe1u2MrlaoJg2VYSpZ2Us4dkWUzxjIfLH47JlOx1GnnKp gYMOjMoPJNNV+KZXHQuWdihNSqQ3QoBx+DBkwPoNac3TRalG1wixJw/r1Rol4QsJYmD5VU7e XNNapl0LlIU88NdKp4QOMMW9G+BGDBSQ/FdGiSPVPkHqcaPG+lke+63JwloOWxPJAYxpo7n5 rMFFteqG4pYkrrTdaD2ZVamyq9CFlVnQ6dg/22wqIJ9IEUaICbRBFreWpe5fdI+c9vcPEzc8 zDTK5rPw== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.85,376,1624320000"; d="scan'208,217";a="762534270" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Oct 2021 21:55:20 +0000 Received: from mail.cisco.com (xbe-aln-007.cisco.com [173.36.7.22]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 19FLtKqN024288 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 15 Oct 2021 21:55:20 GMT Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xbe-aln-007.cisco.com (173.36.7.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 15 Oct 2021 16:55:19 -0500 Received: from xfe-aln-005.cisco.com (173.37.135.125) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 15 Oct 2021 16:55:19 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-005.cisco.com (173.37.135.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Fri, 15 Oct 2021 16:55:19 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZnPn8ML/swHpW76L0meDGe+GkKJIHMNi7KZOEmxO8r0oso/GJ9F/cJCnkCdsbNJ404txO+mw9UZltdBW1OD2viYY1Rp94HV/qcQt1uA+LnBdUM0Bcoy6TYhJcVDtLbTEt3dtWg+MSlT/n3ncYXNLwNh/NKHCgFe9j8+atl9eryKhY8HtmZNC+7WE6EmF8Hl/BvlH4m5VD+h/VQBb4eko7m333CwOKm3GKYVTWzdefDctX3T9671F+I1aA+Qa3UANn4GL8JFSPV2MQDgxyQrxXcpFBz3hAmvrg+6Ixc8zrkX2IeQpDGg5AFHnJ0uubtQT/d26FkKHNg7UxAdp7IdEmA== 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=EdlVGmkRvHIVBVqMQqJHa/eng0EXVcLuAegvsA3/nWA=; b=oS7JSG8Mp1ZM7pjMScrINKIkJY71p0cdjmAE8GHwCMHZ0N755vY8k/9pulmePqgnneZNbAnAkS7xLlWR37MGwpzR2RSnk70EPCa41G9R95C2eoIQCS2XBGXBQMMPKv6yWyUzauAOOR0bW3RSxn6UyJVkfBAqthEacdhLiSJ4996jD9LXWgiQq8kI/OvnItzn5NMwnSWn+NNhoAinX0DzYMpAr8TnLlXumSGKSyf/eFBNEQYQrmFWgyYz3n+96beMbSXRMU+mNKMjuoJNt0S6dq89B/Z8NwLmb442jZsWXsvUCNPQOOJ5GZAyKuYr9X8191s6DostD0Oq7GZwgUm6LA== 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=EdlVGmkRvHIVBVqMQqJHa/eng0EXVcLuAegvsA3/nWA=; b=Gqu1TmzrKsZIr5JrkgeGV52gaicu2WVUAT1DlSzm5CoDnYoQ2GQtlNlnPOz3kPbp8bjn3hZcZsdJ6Dw7GIdfq2SHaswq4xvCe9fEboZvT4HcqxT6L47HxadHUKcw/7oHyeYMGe9WrDnDgMP6QeYnGp48SIyS4V6ShPuxLQ0RK0w= Received: from CO6PR11MB5650.namprd11.prod.outlook.com (2603:10b6:5:35a::9) by CO6PR11MB5602.namprd11.prod.outlook.com (2603:10b6:303:13a::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.17; Fri, 15 Oct 2021 21:55:18 +0000 Received: from CO6PR11MB5650.namprd11.prod.outlook.com ([fe80::6071:7cb6:d30e:b0d]) by CO6PR11MB5650.namprd11.prod.outlook.com ([fe80::6071:7cb6:d30e:b0d%4]) with mapi id 15.20.4608.017; Fri, 15 Oct 2021 21:55:18 +0000 From: "Francois Clad (fclad)" To: Erik Kline , "Joel M. Halpern" CC: "spring@ietf.org" , "ipv6@ietf.org" Thread-Topic: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression Thread-Index: AQHXv+Xlhv5fTa3I2UKXYQQBq/ghoqvSu0aAgAHilS4= Date: Fri, 15 Oct 2021 21:55:18 +0000 Message-ID: References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fcd4e2c1-234f-4360-e79c-08d990267a28 x-ms-traffictypediagnostic: CO6PR11MB5602: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0B3fLtmA1dEgPw+c+TNP0AgkX7hHnz9GPk/TS+Kc74tmI8NurKOx8w/s71ndgmWJe/J+BgBrWLwL+XdDAa6VT2JVmWQLPFMGehmnHpf0Pl6mF3cQ/7xoKHZ+Z2RgrUgQWeFCcQ5TFj2hDwiPLiPjeJINTSYVAEy1efnAUD/wnRZEvHgiMxzxaybDTAoNOq/o736seMOF4GfqJAEsutIruTrKY5Fsi51NzWF8aULfxwlUD3lEYCPCWBq1XRh+sf8a2HyinTlnawYjeER08FeInNOgRhnTwuk7QdJUQGO87YwFa+zC2jtNa/CRSL2UUmtsEr5hE0NaXd6MG7/IEiJc3RYh3/YTnvnthsiviYj0+QGFYW9sMhP0fpijhdiVbo2JyBt2X6opnfxQUYHpZHCHUWVMqO7ibLkiGchH4xWn62APZTh67L24xfRcNvXHlFV17SJrW1KMa3YYJB/LQD2vw4+0gIS7vMoEqlUJxKmlRK1TL0gyM57DuU8oznF4cs1ufRrnW55qS2Kk9hKKBtyF9atBF4CL8WuFdDSpgrtulsT75vZogOY9PAQoKJvUb1ndCVKLv7oZ4AZ5fj4KtUUwnQ00MF1Hm4KgRaHTDwWX7KM68EoXWHtuGqgAU0qWxNDzCDUkbSBtaQLWY6cRjYVw6+fNoryn92wwZ6hjIZMLxydLzpiYCjWyln9SMFlbCFra852KQ/5F2ScQY8PiRq/qvmtVR2GJSUfx/8HLa6NITkLY4EhC6VtUjyRacgpcdIuMieAXcHZuQjVrtxM8nNkHktXnhlFw7+2YXn5QEtAzrUUTAvRlPt6CVhS0JqVrlV6m4mAsDZkZdjs4810afUuuhw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO6PR11MB5650.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(966005)(110136005)(6506007)(53546011)(508600001)(5660300002)(122000001)(38100700002)(4326008)(2906002)(7696005)(83380400001)(166002)(8676002)(66946007)(38070700005)(52536014)(66476007)(66556008)(64756008)(66446008)(91956017)(76116006)(33656002)(54906003)(186003)(9686003)(316002)(8936002)(26005)(71200400001)(66574015)(55016002)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?h7tHXsQym9NDxJ60hqulhdZH46gRve8P+OaHrQVCLaTz/FrpDaSTzvr+W55Y?= =?us-ascii?Q?hZaf4ISfzIr3QK2i5cijK2o440Z1rxDrv9FwdUQFm6hiMxvM3rgJKwoTmCRh?= =?us-ascii?Q?HdJhRczrIAo7eRHlsYf3/MN09azaNF616MF/lTpQNmS4Ypq+5MqOJnH5+OYp?= =?us-ascii?Q?J0dP1gqlInR8eEUIIBK9LtWZTOBgzB4giGpQgptnCsHQZyLGf6OwldKT6uEP?= =?us-ascii?Q?wFh2VPnepavDzJbIk2YrRftg3dlfg5ndQJ9chE2UC4f1+1bwC84UxkZOAtwn?= =?us-ascii?Q?UZqJy8muU+l8kMBv65NGhOHgxKvt6w0qkpdsNNz57g23TAkXynf2r78S86cf?= =?us-ascii?Q?cZjKnxjkXSRN6NhSUv8LSV40kBq1TSNl1EDqaOIT7kuQxaK8h15hybsUevKX?= =?us-ascii?Q?Jl+qcvW/R0iPCpW8h2rH7We6IDXelNTvptDMk6ISWkSw3Gv9+h/l+XGPGkiQ?= =?us-ascii?Q?Stl1SwlTpz0Wy5uegR+IgwISUKx8znxtCRxSVwSFybqpaAruBvy7g272UVOu?= =?us-ascii?Q?lMixz/TOb6Zu/JqbrDYD2Pnb3jox030g6dyawuiDTIuhQNrbdX8p9uQvCYne?= =?us-ascii?Q?6xFCGMtqLHYxxBJmPycoseCnpeBwqdLXPL1eTZ72yLKPXYHBDD4rrhGbiIfG?= =?us-ascii?Q?Wi9+SGuNUwaUYVMvDwWbD7QfuILN7G2xKxENcjXfuSsSCQBR7GIB6YofuBU3?= =?us-ascii?Q?i01Zde8lKQ8nsh1yi6OyMWsGCi8ohhVcWm8DyOCENDBnrwZLcKIMuXtQNHc6?= =?us-ascii?Q?sNlhoVJkMAbkKGgkw5etuWD/mItLBsx0YVmn7qeiq95Gi2FUoGSB7nXaXccv?= =?us-ascii?Q?I5LgVPXsWaQTWnntTuKJU+NHNuoxCBlrACSh60JEyz9FgqJ0TGX3MvbxcXYP?= =?us-ascii?Q?LDDk+eIB+phpP+yAsao++lOArp5FoVXZvyFo8j1ui0VJwHXh/fjncA8fIRdb?= =?us-ascii?Q?WT6z4WgomnBOxgaBwOY6huOYtUs7Zf0j6EoBHRUsyE017aM1892Gf6klqY3y?= =?us-ascii?Q?cYn7dn2AePwKC1VNGSY+UspN3HnmbHjlnZagFUCxu2waVO0kAZ6saKafRSQX?= =?us-ascii?Q?FK+h5kgpMfOrdZyDjhL0hv76mn3nb8O6i+qPoplAkMcc1Mq7uQz7FDgK7KxD?= =?us-ascii?Q?qRxI4IJtN+atWPH9AvmuLGwk7JUESbHUYPPDTPjRGV9CnMDA8i8rkCsvyue4?= =?us-ascii?Q?eMJyjnH/C4cHMDuZjPLJMNy0oRC8MB40r+984/AS/I2nuCkWhOypD/jD0p0V?= =?us-ascii?Q?VKx1r1/Hyw0reo0UNh07QvnLzs35x5+V7vgUKNZgubgqbZ+u7QBz+qIibHhq?= =?us-ascii?Q?Pr2SAKcL+hoSaCLh0PqW0OSutXdLt5Hn7MCN5VczYb08bw=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO6PR11MB5650D2647CFD16908FE55159ACB99CO6PR11MB5650namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO6PR11MB5650.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: fcd4e2c1-234f-4360-e79c-08d990267a28 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2021 21:55:18.1417 (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: MDwlV/5jTM+uQizqnRw/7E88f1amXCi7LPs2ZOBxumTeIg0rhtIoyIr7vIe8GkV5 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO6PR11MB5602 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.22, xbe-aln-007.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 15 Oct 2021 21:55:27 -0000 --_000_CO6PR11MB5650D2647CFD16908FE55159ACB99CO6PR11MB5650namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Erik, You may find some examples here: https://datatracker.ietf.org/doc/draft-cla= d-spring-srv6-srh-compression-illus/ Hope this helps. Thanks, Francois From: spring on behalf of Erik Kline Date: Thursday, 14 October 2021 at 19:06 To: Joel M. Halpern Cc: spring@ietf.org , ipv6@ietf.org Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-sp= ring-srv6-srh-compression Joel, Thank you for your email. The ADs and chairs have been discussing. One thing that would be very helpful to our discussions would be some worke= d examples of the various C-SID behaviors, showing some SRv6 datagrams and = what happens to their contents as they move across some suitable example SR= domain. (It would also be helpful if they showed what happens to something like an = ICMPv6 Echo Request to a representative Destination Address in these cases = when, say, an SRH is not present, i.e. to see when typical unicast semantic= s are preserved or when something more like anycast or multicast behavior i= s to be expected.) Assuming some forthcoming helpful examples, we have a goal to get a more co= mplete answer back to you by the latter half of next week. Thanks, -Erik On Tue, Oct 12, 2021 at 8:53 PM Joel M. Halpern > wrote: The SPRING working group is in the midst of an adoption call on https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/. The SPRING charter has text that is explicit that modifications to data planes and architectures standardized by other working groups may not be modified in SPRING unless the chairs and ADs responsible for that data plane and / or architecture agree. To complete the context, as my SPRING co-chairs are co-authors on the document in question, they have recused themselves from decisional activities regarding the document. Therefore, this message is coming just from my as the responsible SPRING co-chair managing this adoption call= . As you have seen, multiple questions have been raised about the relationship of the document to the IPv6 defined data plane and architecture (particularly RFC 4291 and 8200). In particular the questions seem to revolve around what the document describes as the NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6 standards. (For those seeking more context without reading the full document, a paraphrase and simplification of the NEXT-C_SID flavor is provided as a postscript.) I raised the question of concurrence as required by the SPRING charter with the Internet ADs and SPRING chairs. They quite reasonably asked me to write a note to 6man explaining the concerns as clearly as a can, so that they can then determine how to proceed. The questions that prompted my inquiry are: 1) Does the placement of a list of sids in the IPv6 DA field change the IPv6 architectural description of that field. 2) Does the operation of shifting information around in the IPv6 destination address field represent a modification or extension of the IPv6 data plane. On a related note, the document in question also defines two other flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID flavor operation, so seems to be affected by the same question. From my own reading, it appears that the REPLACE-C-SID flavor does not raise issues requiring 6man leadership concurrence. Yours, Joel M. Halpern for the SPRING working group PS: Clearly, understanding the question requires some understanding of what the NEXT-C_SID flavor does. This explanation is a simplification for length and context. Really, the best place to understand it is the draft. However, to give you enough information to let you decide whether you care, I will try to provide a fair summary. My apologies in advance to the authors for necessary liberties for length. Also, discussion of the draft contents (as distinct from the interaction with the IPv6 data plane and architecture) belongs on the SPRING list, and should not clutter up 6man. SIDs are the identifiers used in segment routing. In SRv6, as document in the current RFCs, these are 128 bits. As defined in the relevant RFCs, SIDs which identify endpoints to which packets are directed are identified by endpoint SIDs. These can have behaviors (decapsulate and forward is one example). They can have flavors such as where the SRH is removed. The topic under discussion is means to compress these SIDs in the packets on the wire. The document under discussion provides three flavors of compression. The fundamental mechanism of the draft is to use a single SRH entry as a container for multiple SIDs. In the NEXT-C_SID mechanism, when it is first encountered the entire container is copied into the desination address of the IPv6 packet. The container has a common routing prefix used for all the NEXT-C-SID SIDs. It is followed by a sequence of compressed SIDs of a configured length. One could configure 16, 24, or 32 bits. Or whatever length. The routing advertisements are arranged so that the IPv6 packet is directed to the node represented by the first compressed SID on the basis of longest prefix match matching the combination of the common routing prefix and that compressed SID. When the packet arrives at that node, it looks up the configured portion, the compressed SID, and determines the behavior and flavor. In the case of the NEXT-C-SID flavor, the resulting operation is to shift the entire remaining contents of the IPv6 address (the bits past the first compressed sid) so as to over-write the first compressed SID. 0 bits are shifted into the low order positions. If the result is a non-zero new first compressed SID, then the packets is forwarded and the process repeats. When all that is left are 0s, if there is an SRH, it is consulted to find the next SRH entry, which is, per normal SRv6 processing, put into the IPv6 DA. Note that in the common case where the SIDS needed all fit in to a single container, the analysis also assumes the use of the reduced encapsulation options which omits the SRH that is not needed as it would have no entries. This the packet contains a normal IPv6 header, with a sequence of compressed SIDs (what one might or might not call a source route) in the IPv6 destination address field. PPS: If the authors of the NEXT-C-SID flavor feel I have mis-represented the work, please, send clarifications or corrections. Again, the best source of information is the draft itself. I was asked to provide extra context in this email. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_CO6PR11MB5650D2647CFD16908FE55159ACB99CO6PR11MB5650namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hello Erik,

     

    You may find some examples here: https://datatracker.ietf.org/doc/draft-clad-spring-srv6-srh-compression-ill= us/

     

    Hope this helps.

     

    Thanks,

    Francois

    &nbs= p;

    From: spring <spring-b= ounces@ietf.org> on behalf of Erik Kline <ek.ietf@gmail.com>
    Date: Thursday, 14 October 2021 at 19:06
    To: Joel M. Halpern <jmh@joelhalpern.com>
    Cc: spring@ietf.org <spring@ietf.org>, ipv6@ietf.org <ipv6@= ietf.org>
    Subject: Re: [spring] Question from SPRING regarding draft-filsfilsc= heng-spring-srv6-srh-compression

    Joel,

     

    Thank you for your email.  The ADs and chairs h= ave been discussing.

     

    One thing that would be very helpful to our discussi= ons would be some worked examples of the various C-SID behaviors, showing s= ome SRv6 datagrams and what happens to their contents as they move across s= ome suitable example SR domain.

     

    (It would also be helpful if they showed what happen= s to something like an ICMPv6 Echo Request to a representative Destination = Address in these cases when, say, an SRH is not present, i.e. to see when t= ypical unicast semantics are preserved or when something more like anycast or multicast behavior is to be expecte= d.)

     

    Assuming some forthcoming helpful examples, we have = a goal to get a more complete answer back to you by the latter half of next= week.

     

    Thanks,

    -Erik

     

    On Tue, Oct 12, 2021 at 8:53 PM Joel M. Halpern <= jmh@joelhalpern.com> wrote:

    The SPRING working group is in the midst of an adopt= ion call on
    https://datatracker.ietf.org/doc/draft= -filsfilscheng-spring-srv6-srh-compression/.

    The SPRING charter has text that is explicit that modifications to data planes and architectures standardized by other working groups may not be modified in SPRING unless the chairs and ADs responsible for that data
    plane and / or architecture agree.

    To complete the context, as my SPRING co-chairs are co-authors on the
    document in question, they have recused themselves from decisional
    activities regarding the document.  Therefore, this message is coming =
    just from my as the responsible SPRING co-chair managing this adoption call= .

    As you have seen, multiple questions have been raised about the
    relationship of the document to the IPv6 defined data plane and
    architecture (particularly RFC 4291 and 8200). In particular the
    questions seem to revolve around what the document describes as the
    NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6
    standards.  (For those seeking more context without reading the full <= br> document, a paraphrase and simplification of the NEXT-C_SID flavor is
    provided as a postscript.)

    I raised the question of concurrence as required by the SPRING charter
    with the Internet ADs and SPRING chairs.  They quite reasonably asked = me
    to write a note to 6man explaining the concerns as clearly as a can, so that they can then determine how to proceed.

    The questions that prompted my inquiry are:

    1) Does the placement of a list of sids in the IPv6 DA field change the IPv6 architectural description of that field.
    2) Does the operation of shifting information around in the IPv6
    destination address field represent a modification or extension of the
    IPv6 data plane.

    On a related note, the document in question also defines two other
    flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.  The
    NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID
    flavor operation, so seems to be affected by the same question.

     From my own reading, it appears that the REPLACE-C-SID flavor does no= t
    raise issues requiring 6man leadership concurrence.

    Yours,
    Joel M. Halpern for the SPRING working group


    PS:
    Clearly, understanding the question requires some understanding of what the NEXT-C_SID flavor does.   This explanation is a simplificatio= n for
    length and context.  Really, the best place to understand it is the draft.  However, to give you enough information to let you decide
    whether you care, I will try to provide a fair summary.  My apologies = in
    advance to the authors for necessary liberties for length.  Also,
    discussion of the draft contents (as distinct from the interaction with the IPv6 data plane and architecture) belongs on the SPRING list, and
    should not clutter up 6man.

    SIDs are the identifiers used in segment routing.
    In SRv6, as document in the current RFCs, these are 128 bits.   A= s
    defined in the relevant RFCs, SIDs which identify endpoints to which
    packets are directed are identified by endpoint SIDs.  These can have =
    behaviors (decapsulate and forward is one example).  They can have flavors such as where the SRH is removed.

    The topic under discussion is means to compress these SIDs in the
    packets on the wire.  The document under discussion provides three flavors of compression.

    The fundamental mechanism of the draft is to use a single SRH entry as a container for multiple SIDs.  In the NEXT-C_SID mechanism, when it is =
    first encountered the entire container is copied into the desination
    address of the IPv6 packet.  The container has a common routing prefix=
    used for all the NEXT-C-SID SIDs.  It is followed by a sequence of compressed SIDs of a configured length.  One could configure 16, 24, o= r
    32 bits.  Or whatever length.  The routing advertisements are arr= anged
    so that the IPv6 packet is directed to the node represented by the first compressed SID on the basis of longest prefix match matching the
    combination of the common routing prefix and that compressed SID.

    When the packet arrives at that node, it looks up the configured
    portion, the compressed SID, and determines the behavior and flavor.  = In
    the case of the NEXT-C-SID flavor, the resulting operation is to shift
    the entire remaining contents of the IPv6 address (the bits past the
    first compressed sid) so as to over-write the first compressed SID.  0=
    bits are shifted into the low order positions.  If the result is a non-zero new first compressed SID, then the packets is forwarded and the process repeats.  When all that is left are 0s, if there is an SRH, it=
    is consulted to find the next SRH entry, which is, per normal SRv6
    processing, put into the IPv6 DA.
    Note that in the common case where the SIDS needed all fit in to a
    single container, the analysis also assumes the use of the reduced
    encapsulation options which omits the SRH that is not needed as it would have no entries.  This the packet contains a normal IPv6 header, with = a
    sequence of compressed SIDs (what one might or might not call a source
    route) in the IPv6 destination address field.

    PPS: If the authors of the NEXT-C-SID flavor feel I have mis-represented the work, please, send clarifications or corrections.   Again, th= e best
    source of information is the draft itself.  I was asked to provide ext= ra
    context in this email.

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

    --_000_CO6PR11MB5650D2647CFD16908FE55159ACB99CO6PR11MB5650namp_-- From nobody Fri Oct 15 15:45:41 2021 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 814033A0E15; Fri, 15 Oct 2021 15:34:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: martin.vigoureux@nokia.com, spring@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <163433725250.17026.1213242120649022890@ietfa.amsl.com> Date: Fri, 15 Oct 2021 15:34:12 -0700 Archived-At: Subject: [spring] spring - Requested session has been scheduled for IETF 112 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Oct 2021 22:34:30 -0000 Dear Bruno Decraene, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. spring Session 1 (2:00 requested) Monday, 8 November 2021, Session I 1200-1400 Room Name: Room 5 size: 505 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/112/sessions/spring.ics Request Information: --------------------------------------------------------- Working Group Name: Source Packet Routing in Networking Area Name: Routing Area Session Requester: Bruno Decraene Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: People who must be present: Bruno Decraene Jim Guichard Joel M. Halpern Martin Vigoureux Shuping Peng Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Oct 15 15:47:36 2021 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 735813A1176; Fri, 15 Oct 2021 15:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.095 X-Spam-Level: X-Spam-Status: No, score=-2.095 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, 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_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPLK9NjIwAZW; Fri, 15 Oct 2021 15:38:00 -0700 (PDT) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (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 1C6D63A10F4; Fri, 15 Oct 2021 15:36:54 -0700 (PDT) Received: by mail-pg1-x535.google.com with SMTP id m21so9788739pgu.13; Fri, 15 Oct 2021 15:36:54 -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=HhKy8n9RwvjHZjvCWWfEqY05RenrzsCS9xuR029PYME=; b=TAFzGa9qTrbUBKGclG8WxfYIRrazoEnkigklN5bpMIn2zhevILDqXi7xuI3FZtak2V S9ez0PXpA1J0cuJitrHCiwmAVcrNaZpVKKeKXBtH75RZbtLx+JRbTBdIQCuFD/n3hPNl CcjwrjxT+ayGNiitbVl2MzFAnUSjoCJa8k24WwZNM88dhL6bD3UWOzFAyOF1XsuK/tmV EoftTa3P6D0rifmd1SmCWBigvdeZRQ5fSJR3chY56h7/R5DlhCOtJaL+4wUzn9dAwzXS ++/oGR2E5ZpI4oNyuE/XY3RvbsAtHVFedEj/fNVIViL/bLIBYq5vKrP4yGMynnFG1bZX mX4Q== 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=HhKy8n9RwvjHZjvCWWfEqY05RenrzsCS9xuR029PYME=; b=t+kdAXtMFUvw4DomYZNDJ/KutriJG0d1LpIXB1ZSQSqTpK6CMZYPBCMz8isVj3h3N3 JtX9o7+sShKvfGBzWzEq3kqzYsVVUKb1O0adKydZw2w/9ZXRvrfjjKdwEBVwv+cfhyU9 y+rQRmA/N27oodJhu2k6Kj6pZ4tdddzyrBK+XdLOyE3X6Vl2bRpcgqJi1mmWxxPYgK9N ncliQIhsyIkrxA8olDcw9RZ0WWy8B1OMWuEcKB30ifHS3zJ51sbkItMcg8PPySI+KGmR QZLHMkQg5mgVUpKV28yck+quLimMnlfINCWSvNnYBrKXiOcJ0lh6DizAHYUqMj57Dhi7 Fmnw== X-Gm-Message-State: AOAM5308yQuY8JAfmNOpm6sV9ofvHSwrHyI4ajkcSTZJeFzprj7wp6Ex ol15+7luhymwJrDhAaP28+HN6a+3e8WwRSsIvTY= X-Google-Smtp-Source: ABdhPJwVkWuu38lc8v5yy8phMFIJ6evycJl9SMdGAzqNNcJsWdIUol+NhirIiy7s2Ko8/otvW4vuQTSKVzujYyR5lfE= X-Received: by 2002:a63:b948:: with SMTP id v8mr5229074pgo.243.1634337412898; Fri, 15 Oct 2021 15:36:52 -0700 (PDT) MIME-Version: 1.0 References: <202110021255323466813813@chinamobile.com> <1c919ecf8db842dc8ecda349a74b741c@huawei.com> In-Reply-To: <1c919ecf8db842dc8ecda349a74b741c@huawei.com> From: Gyan Mishra Date: Fri, 15 Oct 2021 18:36:41 -0400 Message-ID: To: "Chengli (Cheng Li)" Cc: "Francois Clad (fclad)" , James Guichard , SPRING WG , Yisong Liu , spring-chairs Content-Type: multipart/related; boundary="000000000000f07b6905ce6bd4c6" Archived-At: Subject: Re: [spring] =?utf-8?q?RE=EF=BC=9A_WG_Adoption_call_for_https=3A//da?= =?utf-8?q?tatracker=2Eietf=2Eorg/doc/draft-filsfilscheng-spring-srv6-srh-?= =?utf-8?q?compression/?= 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, 15 Oct 2021 22:38:17 -0000 --000000000000f07b6905ce6bd4c6 Content-Type: multipart/alternative; boundary="000000000000f07b6705ce6bd4c5" --000000000000f07b6705ce6bd4c5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Chengli Most welcome! Overall the main point I would like to make that needs to be addressed more clearly in the draft is the interoperability between NEXT and REPLACE SID and a visual diagram of how that would look for same or different SID lengths. As these interoperability permutations have been discussed on ML at length, I think it=E2=80=99s important to address as part of the two flavor solutio= n adding the following mix flavor scenario=E2=80=99s to the draft. No LIB/GIB 1 - Next and Replace SID using common 16 bit SID within the same container. 2- Next and Replace SID using common 32 bit within the same container. 3 - Next 16 bit SID and Replace 32 bit SID using within the same container. 4- Next 32 bit SID and Replace 16 bit SID using within the same container. Common design with LIB/GIB 1 - Next and Replace SID using common 16 bit SID within the same container. -> This is the most optimal solution for mix flavor deployments 2- Next and Replace SID using common 32 bit within the same container. 3 - Next 16 bit SID and Replace 32 bit SID using within the same container. 4- Next 32 bit SID and Replace 16 bit SID using within the same container. Responses in-line Kind Regards Gyan On Wed, Oct 13, 2021 at 11:38 AM Chengli (Cheng Li) wrote: > Hi Gyan, > > > > Sorry for the late reply. Thank you for reading the draft so carefully, > really appreciated. > Gyan> Welcome > But I will recommend you to split the comments into small emails so that > we can discuss easily. LOL. > Gyan> Will do > Regarding the illustrations, yes, it can be added later on. And also > Francois provides the example already, please refer to it. > > Gyan> Thank you > > Like you quote from the draft, REPLACE-CSID and NEXT-CSID can supported > both the 16-bit and 32-bit solution, but from the considerations of > trade-off of better compression and easy operation, NEXT-CSID recommends > 16-bit and REPLACE-CSID recommends 32-bit. From the text, you also can se= e > using the common design of GIB/LIB, both flavors can support 16-bit > solution. > > Gyan> In section 6 please state more clearly and explicitly to the > reader that a common design using GIB/LIB can yield both flavors using 16 > bit SID meeting optimal compression as well as all other requirements. I > think by clearly stating so will really help the drafts adoption by the W= G > as it would help put to bed interoperability issues. Also will help > eliminate other mix SID length use cases. Section 6.1 SID length should > then also be updated to state that compression SID length of 16 with > common LIB/GIB usage by both flavors the recommended SID length can be 16 > bit for both flavors and is the most optimal deployable recommendation fo= r > operators if mix flavor is necessary. Also to that end if 16 bit sid can > be utilized optimally with next and replace sid meeting compression and > all other requirements it does put next and replace sid on the same playi= ng > field as equally good solutions that meet the primary goal of optimal > compression. > >From the section 4 in the draft https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh-c= ompression#section-4, it also states that > > > > It is recommended for ease of operation that a single compressed > > encoding flavor be used in a given SRv6 domain. However, in a multi- > > domain deployment, different flavors can be used in different > > domains. > > Gyan>. Good. That is a very important point. > > so we should avoid to mix different length of CSIDs in a single container= , > though we can do it. > > Gyan> This important verbiage should be added to the draft. > > I think we should add recommendation to avoid mixed flavors within the same domain. Kind Regards Gyan Thanks, > > Cheng > > > > > > > > > > *=E5=8F=91=E4=BB=B6=E4=BA=BA:* Gyan Mishra [mailto:hayabusagsm@gmail.com] > *=E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4:* 2021=E5=B9=B410=E6=9C=8811=E6=97= =A5 4:23 > *=E6=94=B6=E4=BB=B6=E4=BA=BA:* Chengli (Cheng Li) ; Franc= ois Clad (fclad) < > fclad@cisco.com> > *=E6=8A=84=E9=80=81:* James Guichard ; SP= RING WG < > spring@ietf.org>; Yisong Liu ; spring-chairs < > spring-chairs@ietf.org> > *=E4=B8=BB=E9=A2=98:* Re: [spring] RE=EF=BC=9A WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > > > > > Hi Francois, Chengli & authors > > > > Many Thanks for your feedback to the WG on the critical topic > interoperability of the uSID micro-sid 16 bit uSID =E2=80=9CNF=3DLocato= r/Function > combo=E2=80=9D 128 bit container based solution and the G-SRV6 32 bit G-= SID > =E2=80=9CNF=3DLocator/Function combo=E2=80=9D 4 - 32 bit G-SID in 128 bit= container based > solution defined as Next and Replace flavors in the draft. > > > > I am really concerned as to how the next and replace interoperability > would work for adjacent nodes using SID within same or adjacent container= . > > > > Section 6.1 mentions that Next flavor recommendation is for 16 bit as th= e > uSID draft & this draft NF as 16 bit is most optimal uSID size within the > uSID container and Replace flavor recommendation is for 16 bit as the > G-SRV6 draft & this draft NF as 32 bit G-SID is most optimal G-SID size > within the G-SID container. > > > > Please elaborate on this in more detail, as with this draft for next and > replace interoperability, following the SRv6 compression requirements for > optimal hardware forwarding and state efficiency that Next would be > recommended to use 16 bit SID and Replace would be recommended 32 bit SID= . > Please elaborate in detail as to why 16 bit is not recommended for > replace flavor and 32 bit is not recommended for next flavor for all of t= he > requirements drafts list of SRv6 compression requirements each one by one > and the problems encountered when not using the recommended SID length. > > > > Thus for next and replace flavor interoperability even possible to work > would require two different SID sizes within the same container > interoperability caveats and now you have to deal with uSID container sty= le > using 16 bit SID and G-SID container style using 32 bit SID. > > > > From the requirements draft, interoperability perspective, the primary > objective is =E2=80=9Cencapsulation header compression=E2=80=9D as that i= s what we have > spent over a year on with DT finding an optimal compression solution. So > here the lowest common denominator ends up being 32 bit SID and we now ha= ve > failed the primary objective of a compression solution. > > > > As far as lowest common denominator is it true that in order to meet all > the requirements draft list of all SRv6 compression requirements both nex= t > and replace have to revert to that lowest common denominator which is 32 > bit SID. If that is true, unfortunately that makes the draft fail the > primary objective of any SRv6 compression solution. > > > > To that end as far as interoperability on Next and Replace > interoperability being the hinge pin of this drafts adoption, as well eve= n > if the authors state that Replace can use 16 bit SID as a possibility, as > the 32 bit =E2=80=9CNF=E2=80=9D G-SID is recommended for hardware forward= ing efficiency and > scalability that if 16 bit were used G-SID would fail the hardware > forwarding efficiency and scalability requirements as well as possibly > other requirements which should also be stated in the draft. > > > > *6.1 . C-SID Length* > > > > The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A > > C-SID length of 16-bit is recommended. > > > > The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths. > > A C-SID length of 32-bit is recommended. > > > > The draft should mention the recommendation for common block length for > interoperability. The only block size possible is 48 bit so block size s= o > that would be a major addressing inflexibility for interoperability. > > > > *6.2 . Block Length* > > > > The recommended SRv6 SID block sizes for the NEXT-C-SID flavor are > > 16, 32 or 48 bits. The smaller the block, the higher the compression > > efficiency. > > > > The recommended SRv6 SID block size for the REPLACE-C-SID flavor can > > be 48, 56, 64, 72 or 80 bits, depending on the needs of the operator. > > > > > > Taking this further another step as this draft needs to describe in detai= l > with examples of the feasibility of how two adjacent nodes one using next > 16 bit SID and other using replace 32 bit SID as recommended where the 16 > bit uSID next flavor and 32 bit G-SID are in the same SRH 128 bit contain= er. > > > > As the uSID Next flavor draft performs a shift towards B towards nibble A= , > B nibbles, and Replace does a replace of the A-Arg portion of the 128 bi= t > IPv6 address, how would that work with adjacent nodes using different SID > flavors of different SID lengths. > > > > > > The Next flavor uSID SRv6 PGM compression solution process is very > different where when indexing the micro sid nibbles within the 128 bit > container, it performs a shift towards the top lower order bits of the IP= v6 > address, where the Replace flavor G-SRv6 PGM compression solution indexin= g > the 4 G-SIDs within the container does a Replace at the A-Arg bottom high= er > order bits. > > > > The referencing of the 16 uSID or 32 bit G-SID nibbles, indexing and > reference of which nibble to referenced for next and replace for directly > adjacent nodes with nibbles within the same 128 bit container or adjacent > containers is the interoperability issue that seems to exist. > > > > This needs to be clarified on the next snd replace interoperability > operation in detail. > > > > Also Replace flavor uses COC delimiter for signaling compression function > is active where Next does not have any signaling of compression being > active or not or may have a different way of signaling that upcoming node > does not support compression. > > > > How does the compression signaling interoperability work between Next and > Replace flavors. That should be addressed as well in the draft. > > > > Kind Regards > > > > Gyan > > Verizon Inc > > > > On Fri, Oct 8, 2021 at 1:34 PM Francois Clad (fclad) > wrote: > > Hi Gyan, > > > > It is possible to combine SIDs of different C-SID flavors and C-SID > lengths in the same SRH, along with those defined in RFC 8986 After all, > they leverage the same SRv6 data plane. > > > > Let me give you an example. > > > > Assume that an SR source node wants to send a packet onto an SR path > through 10 SR segment endpoint nodes (nodes 1 through 10), and have a VPN > termination for a VRF 123 on a last SR segment endpoint node 11. > > > > The SR source node selects the segments as follows: > > - On nodes 1 through 5, the SID 2001:db8:0:0K01:: (with K being the > node ID) bound to End with NEXT-C-SID flavor and 16-bit C-SID length. > - On nodes 6 through 9, the SID 2001:db8:0:0K00:0001:: (with K being > the node ID) bound to End with REPLACE-C-SID flavor and 32-bit C-SID l= ength. > - On node 10, the SID 2001:db8:0:1000:0001:: bound to End (RFC 8986). > - On node 11, a SID 2001:db8:0:1100:d123:: bound to End.DT4 (RFC 8986) > for VRF 123. > > > > The SR source node then sends the packet onto the SR path by performing > the H.Encaps.Red behavior with: > > - IPv6 Source Address =3D > - IPv6 Destination Address =3D 2001:db8:0:0101:0201:0301:0401:0501 > - SRH =3D > > > - SegmentList[0] =3D 2001:db8:0:1100:d123:: > - SegmentList[1] =3D 1000:0001:0900:0001:0800:0001:0700:0001 > - SegmentList[2] =3D 2001:db8:0:0600:0001:: > > > > Therefore, there is no notion of lowest common denominator for C-SID > length. Based on the deployment requirements, an operator has the > flexibility to select the SRv6 SID flavor and C-SID lengths of their choi= ce. > > > > We can update the draft with this type of illustrations. > > > > Thanks, > > Francois > > > > *From: *spring on behalf of Gyan Mishra < > hayabusagsm@gmail.com> > *Date: *Sunday, 3 October 2021 at 21:01 > *To: *Yisong Liu > *Cc: *James Guichard , SPRING WG < > spring@ietf.org>, spring-chairs > *Subject: *Re: [spring] RE=EF=BC=9A WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > > > Hi Yisong > > > > The main goal for operators is interoperability. As interoperability is > the key reason for a single SRv6 compression solution that we have WG > consensus and is desired. > > > > Continued details of the interoperability study should be added to the > draft as the study progresses. > > > > One key detail that is missing is forwarding efficiency and scalability > using NEXT-C-SID and REPLACE-C-SID interoperability using 16 bit SID. > > > > As NEXT-CSID uSID Container Micro Segment shift flavor using GIB/LIB for > ultra scale SRv6 compression solution is recommended for 16 bit SID and > REPLACE-C-SID G-SID G-SID Container based solution is recommended for 32 > bit SID. > > > > Of all the requirements as stated, the encapsulation header size is the > primary objective for operators to eliminate MSD issues with optimal > forwarding and state efficiencies. > > > > At this time in order for Next and Replace solutions to be interoperable > keeping in mind requirements for optimal forwarding and state efficiency = 32 > bit SID would be the lowest common denominator which should be stated as > the baseline result of the analysis draft on CSID overall 2 prong solutio= n. > > > > CSID draft: > > > https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh= -compression-02#section-11 > > > > Bottom of section 11: > > > > > > The interoperability was validated for the following scenario: > > > > o Packet forwarding through a traffic engineering segment list > > combining, in the same SRH ([RFC8754 ]), SRv6 SIDs bound to an > > endpoint behavior with the NEXT-C-SID flavor and SRv6 SIDs bound > > to an endpoint behavior with the REPLACE-C-SID flavor. > > > > Further interoperability testing is ongoing and will be reported in > > this document as the work progresses. > > > > King Regards > > > > Gyan > > On Sat, Oct 2, 2021 at 12:56 AM Yisong Liu > wrote: > > Hi Chairs & WG, > > > > I strongly support the adoption call. Regarding chair's note in the email= , > I would like to point that the network programming model (RFC8996) by > nature defines multiple behaviors. CSID has a single SRv6 based data plan= e > that defines the next and replace behaviors consistent with the network > programming paradigm. > > > > CSID's next and replace behaviors have been verified by interoperability > test in China mobile laboratory and there is no problem with the > interworking of the two behaviors on the CSID dataplane. > > > > Best Regards > > Yisong > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: James Guichard > > =E6=97=B6=E9=97=B4: 2021/10/01(=E6=98=9F=E6=9C=9F=E4=BA=94)22:04 > > =E6=94=B6=E4=BB=B6=E4=BA=BA: SPRING WG ; > > =E6=8A=84=E9=80=81=E4=BA=BA: spring-chairs ; > > =E4=B8=BB=E9=A2=98: [spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > Dear WG: > > > > The chairs would like to express their appreciation for all the responses > received to our emails with reference to how the working group wishes to > move forward with respect to a solution for SRv6 compression. > > > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > as the basis for its compression standardization work. That is part of wh= at > this email attempts to confirm. > > > > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging > that: > > > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change = as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the working > group to publication. A list of these discussion points will be docume= nted > in the WG document and maintained by the document editor in conjunctio= n > with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text describin= g an > open issue be added to the document in the above-described open issues > section: > > > - "Given that the working group has said that it wants to standardize > one data plane solution, and given that the document contains multi= ple SRv6 > EndPoint behaviors that some WG members have stated are multiple da= ta plane > solutions, the working group will address whether this is valid and > coherent with its one data plane solution objective.". > > > > Please consider the above guidelines as you decide on whether to support > or not this WG adoption. Please express clearly your reasoning for > support/non-support as well as any open discussion points you would like > addressed should the document be adopted into the working group. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > > _______________________________________________ > 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* > > > > -- > > [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* > > > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --000000000000f07b6705ce6bd4c5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Hi Chengli=C2=A0
    Most welcome!

    =C2=A0Overall the main point I would like to make that need= s to be addressed more clearly in the draft is the interoperability between= NEXT and REPLACE SID and a visual diagram of how that would look for same = or different =C2=A0SID lengths.=C2=A0

    As these interoperability permutations have been discussed on= ML at length, I think it=E2=80=99s important to address as part of the two= flavor solution adding the following mix flavor scenario=E2=80=99s to the = draft.

    =C2=A0No LIB/GIB= =C2=A0

    1 - Next and = Replace SID using common 16 bit SID within the same container.=C2=A0
    <= div dir=3D"auto">
    2- Next and Replace SID using = common 32 bit within the same container.

    <= div dir=3D"auto">
    3 - Next 16 bit SID and Replace 32 bit S= ID using within the same container.=C2=A0

    =
    4- Next 32 bit SID and Replace 16 bit SID using within th= e same container.


    C= ommon design with LIB/GIB=C2=A0

    1 - Next and Replace SID using common 16 bit SID within the same container= . -> This is the most optimal solution for mix flavor deployments=C2=A0<= /div>

    2- Next and Replace SID using c= ommon 32 bit within the same container.

    3 - Next 16 bi= t SID and Replace 32 bit SID using within the same container.=C2=A0

    4- Next 32 bit SID and Replace 16 bit = SID using within the same container.

    Responses in-line=C2= =A0

    Kind Regards=C2=A0

    Gyan


    On Wed, Oct 13, 2021 at 11:38 AM Chengli (Cheng Li) <= c.l@huawei.com> wrote:

    Hi Gyan,

    =C2=A0=

    Sorry for the = late reply. Thank you for reading the draft so carefully, really appreciate= d.

    Gyan> Welcome=C2= =A0

    <= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rg= b(204,204,204)">

    But I will recommend you to split the comments = into small emails so that we can discuss easily. LOL.

    Gyan> Will do

    =

    Regarding the illustrations= , yes, it can be added later on. And also Francois provides the example alr= eady, please refer to it.

    Gyan> Thank you=C2=A0

    Like you quote from the dra= ft, REPLACE-CSID and NEXT-CSID can supported both the 16-bit and 32-bit sol= ution, but from the considerations of trade-off of better compression and easy operation, NEXT-CSID recommends 16-bit and = REPLACE-CSID recommends 32-bit. From the text, you also can see using the c= ommon design of GIB/LIB, both flavors can support 16-bit solution. =C2=A0

    =C2=A0Gyan> =C2=A0In section 6 please = state more clearly and explicitly to the reader that a common design using = GIB/LIB can yield both flavors using 16 bit SID meeting optimal compression= as well as all other requirements.=C2=A0 I think by clearly stating so wil= l really help the drafts adoption by the WG as it would help put to bed int= eroperability issues.=C2=A0 Also will help eliminate other mix SID length u= se cases.=C2=A0 Section 6.1 SID length should then =C2=A0also be updated to= state that compression SID length of 16 with common LIB/GIB usage by both = flavors the recommended SID length can be 16 bit for both flavors and is th= e most optimal deployable recommendation for operators if mix flavor is nec= essary.=C2=A0 Also to that end if 16 bit sid can =C2=A0be utilized optimall= y with next and replace sid meeting compression and all other requirements = it does put next and replace sid on the same playing field as equally good = solutions that meet the primary goal of optimal compression.


    = 

    From the sect=
ion 4 in the draft https://datatracker.ietf.org/doc/html/d=
raft-filsfilscheng-spring-srv6-srh-compression#section-4, it also state=
s that
    =C2=A0
     It is recommended for ease of operation that a single c=
ompressed

    =C2=A0=C2=A0 encoding flavor be used in a given SRv6 domain.=C2=A0 Ho= wever, in a multi-

    =C2=A0=C2=A0 domain deployment, different flavors can be used in diff= erent

    =C2=A0=C2=A0 domains.

    Gyan>. Good.=C2=A0 That is a very impo= rtant point. =C2=A0<= /p>

    so we should avoid to mix d= ifferent length of CSIDs in a single container, though we can do it.

    =C2=A0Gyan> =C2=A0This important verbi= age should be added to the draft.

    =C2=A0 I think we should add recommendation to a= void mixed flavors within the same domain.

    Kind Regards=C2=A0

    Gyan

    Thanks,

    Cheng<= /span>

    =C2=A0=

    =C2=A0=

    =C2=A0=

    <= span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:Calibri,sans-seri= f;color:rgb(31,73,125)">=C2= =A0

    =E5=8F=91=E4=BB=B6=E4=BA=BA: Gyan Mishra [= mailto:hayabusagsm@gm= ail.com]
    =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2021=E5=B9=B410=E6=9C=8811=E6=97=A5 4:23
    =E6=94=B6=E4=BB=B6=E4=BA=BA: Chengli (Cheng Li) <c.= l@huawei.com>; Francois Clad (fclad) <fclad@cisco.com>
    =E6=8A=84=E9=80=81: James = Guichard <james.n.guichard@futurewei.com>; SPRING WG <spring@ietf.org>; Yisong Liu <liuyisong@chinamobile.co= m>; spring-chairs <spring-chairs@ietf.org>
    =E4=B8=BB=E9=A2=98: Re: [s= pring] RE=EF=BC=9A WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-= spring-srv6-srh-compression/

    =C2=A0

    = =C2=A0

    Hi Franco= is, Chengli & authors=C2=A0

    = =C2=A0

    Many Than= ks for your feedback to the WG on the critical topic interoperability of th= e uSID micro-sid 16 bit uSID =C2=A0 =E2=80=9CNF=3DLocator/Function combo=E2= =80=9D =C2=A0128 bit=C2=A0container based solution and the G-SRV6 32 bit G-SID =E2=80=9CNF=3DLocator/Function combo=E2=80=9D 4 - 32 bit G-SID in 12= 8 bit container based solution defined as Next and Replace flavors in the d= raft.

    = =C2=A0

    I am real= ly concerned as to how the next and replace interoperability would work for= adjacent nodes using SID within same or adjacent container.<= /span>

    = =C2=A0

    Section 6= .1 mentions that =C2=A0Next flavor recommendation is for 16 bit as the uSID= draft & this draft NF as 16 bit is most optimal uSID size within the u= SID container and=C2=A0Replace flavor recommendation is for 16 bit as the G-SRV6 draft & this draft N= F as 32 bit G-SID is most optimal G-SID size within the G-SID container.=C2= =A0=C2=A0

    = =C2=A0

    Please =C2=A0elaborate on this in more detail= , as with this draft for next and replace interoperability, following the S= Rv6 compression requirements for optimal hardware forwarding and state efficiency that Next would be recommended to= use 16 bit SID and Replace would be recommended 32 bit SID. =C2=A0 Please = elaborate in detail as to why 16 bit is not recommended for replace flavor = and 32 bit is not recommended for next flavor for all of the requirements drafts list of SRv6 compression require= ments each one by one and the problems encountered when not using the recom= mended SID length.=

    = =C2=A0

    Thus for next and replace flavor interoperabi= lity even possible =C2=A0to work would require two different SID sizes with= in the same container interoperability caveats and now you have to deal with uSID container style using 16 bit SID and G-= SID container style using 32 bit SID.

    = =C2=A0

    From the requirements draft, =C2=A0interopera= bility perspective, the primary objective is =E2=80=9Cencapsulation header = compression=E2=80=9D as that is what we have spent over a year on with DT finding an optimal compression solution.=C2=A0 So here the= lowest common denominator ends up being 32 bit SID and we now have failed = the primary objective of a compression solution. =C2=A0=C2=A0

    = =C2=A0

    As far as lowest common denominator is it tru= e that in order to meet all the requirements draft list of all SRv6 compres= sion requirements both next and replace have to revert to that lowest common denominator which is 32 bit SID.=C2= =A0 If that is true, unfortunately that makes the draft fail the primary ob= jective of any SRv6 compression solution.

    = =C2=A0

    To that end as far as interoperability on Nex= t and Replace interoperability being the hinge pin of this drafts adoption,= as well even if the authors state that Replace can use 16 bit SID as a possibility, as the 32 bit =E2=80=9CNF=E2= =80=9D G-SID is recommended for hardware forwarding efficiency and scalabil= ity that if 16 bit were used G-SID would fail the hardware forwarding effic= iency and scalability requirements as well as possibly other requirements which should also be stated in the draft.

    =C2=A0

    6.1.=C2=A0 C-SID Length
    =C2=A0

    =C2=A0=C2=A0 The NEXT-C-SID flavor supports bo=
th 16- and 32-bit C-SID lengths.=C2=A0 A
    

    =C2=A0=C2=A0 C-SID length of 16-bit is recomme=
nded.
    

    =C2=A0

    =C2=A0=C2=A0 The REPLACE-C-SID flavor supports=
 both 16- and 32-bit C-SID lengths.

    =C2=A0=C2=A0 A C-SID length of 32-bit is recom=
mended.
    

    =C2=A0

    The draft should mention the re= commendation for common block length for interoperability.=C2=A0 The only b= lock size possible is 48 bit so block size so that would be a major address= ing inflexibility for interoperability.

    =C2=A0

    6.2.=C2=A0 Block Length
    =C2=A0

    =C2=A0=C2=A0 The recommended SRv6 SID block si=
zes for the NEXT-C-SID flavor are

    =C2=A0=C2=A0 16, 32 or 48 bits.=C2=A0 The smal=
ler the block, the higher the compression
    

    =C2=A0=C2=A0 efficiency.
    

    =C2=A0

    =C2=A0=C2=A0 The recommended SRv6 SID block si=
ze for the REPLACE-C-SID flavor can

    =C2=A0=C2=A0 be 48, 56, 64, 72 or 80 bits, dep=
ending on the needs of the operator.<=
/pre>

    =C2=A0

    =C2=A0

    Taking this further another ste= p as this draft needs to describe in detail with examples of the feasibilit= y of how two adjacent nodes one using next 16 bit SID and other using repla= ce 32 bit SID as recommended where the 16 bit uSID next flavor and 32 bit G-SID are in the same SRH 128 bit conta= iner.

    =C2=A0

    As the uSID Next flavor draft p= erforms a shift towards B towards nibble A, B nibbles, and Replace does a r= eplace of the A-Arg portion =C2=A0of the 128 bit IPv6 address, how would th= at work with adjacent nodes using different SID flavors of different SID lengths. =C2=A0

    =C2=A0

    =C2=A0

    The Next flavor uSID SRv6 PGM = =C2=A0compression solution process is very different where when indexing th= e micro sid nibbles within the 128 bit container, it performs a shift towar= ds the top lower order bits of the IPv6 address, where the Replace flavor G-SRv6 PGM compression solution indexing the 4 G-= SIDs within the container does a Replace at the A-Arg bottom higher order b= its. =C2=A0

    =C2=A0

    The referencing of the 16 uSID = or 32 =C2=A0bit G-SID =C2=A0nibbles, indexing and reference of which nibble= to referenced for next and replace for directly adjacent nodes with nibble= s within the same 128 bit container or adjacent containers is the interoperability issue that seems to exist. =C2=A0

    =C2=A0

    This needs to be clarified on t= he next snd replace interoperability operation in detail.

    =C2=A0

    Also Replace flavor uses COC de= limiter for signaling compression function is active where Next does not ha= ve any signaling of compression being active or not or may have a different= way of signaling that upcoming node does not support compression.=C2=A0=C2=A0

    =C2=A0

    How does the compression signal= ing interoperability work between Next and Replace flavors.=C2=A0 That shou= ld be addressed as well in the draft.

    =C2=A0

    Kind Regards

    =C2=A0

    Gyan

    Verizon Inc=C2=A0=

    =C2=A0

    On Fri, Oct 8, 2021 at 1:34 PM = Francois Clad (fclad) <fclad@cisco.com> wrote:

    Hi Gyan,

    =C2=A0

    It is possible to combine SIDs = of different C-SID flavors and C-SID lengths in the same SRH, along with th= ose defined in RFC 8986 After all, they leverage the same SRv6 data plane.

    =C2=A0

    Let me give you an example.<= /u>

    =C2=A0

    Assume that an SR source node w= ants to send a packet onto an SR path through 10 SR segment endpoint nodes = (nodes 1 through 10), and have a VPN termination for a VRF 123 on a last SR segment endpoint node 11.

    =C2=A0

    The SR source node selects the = segments as follows:

    • On nodes 1 through 5, the SID 2001:db8:0:0K01:: (with = K being the node ID) bound to End with NEXT-C-SID flavor and 16-bit C-SID l= ength.
    • On nodes 6 through 9, the SID 2001:db8:0:0K00:0001:: (= with K being the node ID) bound to End with REPLACE-C-SID flavor and 32-bit= C-SID length.
    • On node 10, the SID 2001:db8:0:1000:0001:: bound to En= d (RFC 8986).
    • On node 11, a SID 2001:db8:0:1100:d123:: bound to End.= DT4 (RFC 8986) for VRF 123.

    =C2=A0

    The SR source node then sends t= he packet onto the SR path by performing the H.Encaps.Red behavior with:=

    • IPv6 Source Address =3D <an address of the SR sourc= e node>
    • IPv6 Destination Address =3D 2001:db8:0:0101:0201:0301= :0401:0501
    • SRH =3D
      • SegmentList[0] =3D 2001:db8:0:1100:d123::
      • SegmentList[1] =3D 1000:0001:0900:0001:0800:0001:0700:= 0001
      • SegmentList[2] =3D 2001:db8:0:0600:0001::

    =C2=A0

    Therefore, there is no notion o= f lowest common denominator for C-SID length. Based on the deployment requi= rements, an operator has the flexibility to select the SRv6 SID flavor and C-SID lengths of their choice.

    =C2=A0

    We can update the draft with th= is type of illustrations.

    =C2=A0

    Thanks,

    Francois

    =C2=A0

    From: spring <spring-bounces@ietf.org<= /a>> on behalf of Gyan Mishra <hayabusagsm@gmail.com>
    Date: Sunday, 3 October 2021 at 21:01
    To: Yisong Liu <liuyisong@chinamobile.com>
    Cc: James Guichard <james.n.guichard@futurewei.com>, SPRING WG &l= t;spring@ietf.org&= gt;, spring-chairs <spring-chairs@ietf.org>
    Subject: Re: [spring] RE    =EF=BC=9A WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/

    =C2=A0

    Hi=C2=A0Yisong

    =C2=A0

    The main goal for operators is = interoperability.=C2=A0 As interoperability is the key reason for a single = SRv6 compression solution that we have WG consensus and is desired. =C2=A0

    =C2=A0

    Continued details of the intero= perability study =C2=A0should be added to the draft as the study progresses= .

    =C2=A0

    One key detail that is missing = is forwarding efficiency and scalability using NEXT-C-SID and REPLACE-C-SID= interoperability using 16 bit SID. =C2=A0

    =C2=A0

    As NEXT-CSID uSID Container Mic= ro Segment shift flavor using GIB/LIB for ultra scale =C2=A0SRv6 compressio= n solution is recommended for 16 bit SID and REPLACE-C-SID G-SID G-SID Container based solution is recommended for 32 bit SID.=

    =C2=A0

    Of all the requirements as stat= ed, the encapsulation header size is the primary objective for operators to= eliminate MSD issues with optimal forwarding and state efficiencies.=C2=A0

    =C2=A0

    At this time in order for Next = and Replace solutions to be interoperable keeping in mind requirements for = optimal forwarding and state efficiency 32 bit SID would be the lowest common denominator which should be stated as the baseline re= sult of the analysis draft on CSID overall 2 prong solution.<= /span>

    =C2=A0

    CSID draft:

    Bottom of section 11:=

    =C2=A0

    =C2=A0

    =C2=A0 =C2=A0The interoperability was validated for the foll= owing scenario:

    =C2=A0=

    =C2=A0=C2=A0 o=C2=A0 Packet for=
warding through a traffic engineering segment list
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
combining, in the same SRH ([RFC8754]), SR=
v6 SIDs bound to an
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
endpoint behavior with the NEXT-C-SID flavor and SRv6 SIDs bound
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
to an endpoint behavior with the REPLACE-C-SID flavor.
    =C2=A0
    =C2=A0=C2=A0 Further interopera=
bility testing is ongoing and will be reported in=

    =C2=A0=C2=A0 this document as t=
he work progresses.

    =C2=A0

    King Regards=C2=A0

    =C2=A0

    Gyan

    On Sat, Oct 2, 2021 at 12:56 AM= Yisong Liu <liuyisong@chinamobile.com> wrote:

    Hi Chairs & WG,

    =C2=A0

    I strongly support the = adoption call. Regarding chair's note in the email, I would like to poi= nt that the network programming model (RFC8996) by nature defines multiple behaviors. CSID has= a single SRv6 based data plane that defines the next and replace behaviors= consistent with the network programming paradigm.

    =C2=A0

    CSID's next and rep= lace behaviors have been verified by=C2=A0interopera= bility test=C2=A0in China mobile laboratory and there is no proble= m with the interworking of the two behaviors on the CSID dataplane.<= /span>

    =C2=A0

    Best Regards

    Yisong

    =C2=A0

    =E5=8F=91=E4=BB=B6=E4=BA=BA: James Guic= hard

    =E6=97=B6=E9=97=B4: 2021/10/01(=E6= =98=9F=E6=9C=9F=E4=BA=94)22:04=

    =E6=94=B6=E4=BB=B6=E4=BA=BA: SPRING WG;

    =E6=8A=84=E9=80=81=E4=BA=BA: spring-chairs;

    Dear WG:

    =C2=A0

    The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a solution for SRv6 compression.

    =C2=A0

    The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

    =C2=A0

    Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

    =C2=A0

    1. The SPRING working group is adopting a document that h= as multiple SRv6 Endpoint behaviors.
    2. The document is a =E2=80=9Cliving=E2=80=9D document; i= t may change as it goes through review and analysis by the SPRING working g= roup.
    3. All open discussion points raised on our mailing list = MUST be addressed BEFORE said document is allowed to progress from the work= ing group to publication. A list of these discussion points will be documen= ted in the WG document and maintained by the document editor in conjunction with the chairs.
    4. If this document is adopted by the working group, the = chairs specify as part of the adoption call that the following text describ= ing an open issue be added to the document in the above-described open issu= es section:
      • "Given that the working group has said that it wa= nts to standardize one data plane solution, and given that the document con= tains multiple SRv6 EndPoint behaviors that some WG members have stated are= multiple data plane solutions, the working group will address whether this is valid and coherent with its one data pl= ane solution objective.".

    =C2=A0

    Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open discussion points you would like addressed should the = document be adopted into the working group.

    =C2=A0

    Thanks!

    =C2=A0

    Jim, Bruno & Joel=

    =C2=A0

    =C2=A0

    _______________________________= ________________
    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==

    Gyan Mishra

    Network Solutions Architect=C2=A0<= /i>

    Email gyan.s.mishra@verizon.com

    M 301 502-1347=

    =C2=A0

    --

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

    Gyan Mishra

    Network Solutions Architect=C2=A0<= /i>=

    Email gyan.s.mishra@verizon.com

    M 3= 01 502-1347=

    =C2=A0

    --
    --000000000000f07b6705ce6bd4c5-- --000000000000f07b6905ce6bd4c6 Content-Type: image/jpeg; name="image001.jpg" Content-Disposition: inline; filename="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: <17c85fa2c1a4cd34f0f1> X-Attachment-Id: 17c85fa2c1a4cd34f0f1 /9j/4AAQSkZJRgABAQEAeAB4AAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAAXAGUBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZqKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKK//2Q== --000000000000f07b6905ce6bd4c6-- From nobody Fri Oct 15 15:48:19 2021 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 0AE2E3A1D3D; Fri, 15 Oct 2021 15:45:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.086 X-Spam-Level: X-Spam-Status: No, score=-2.086 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kUl3-gp77Kyu; Fri, 15 Oct 2021 15:45:44 -0700 (PDT) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 1FC0C3A1D11; Fri, 15 Oct 2021 15:42:38 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id q5so9822733pgr.7; Fri, 15 Oct 2021 15:42:38 -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=FKdUU8WqNSmioxVBUoqF/0iIbNqZZRAZn2fTH57TvDQ=; b=iLnXNufwn/iKixwRjiSjBWOXOOjrp/EdBB6qNrXDLNC/zo3kiqjlldEu4ammPIEwX9 BhGfgWb1wJmmGUHyeSfZOrUUgGg55yH1sq4Yx5k/vALGRvYLg1oCRKBV3NeZybUHEC4j FDO2N0rfUjuY9gu7Q9PCy4km6jPt+0Ii/o0SvFgezE/wep7JbCBvkQ2718ajHvFjb05B FrEJApJpqh3TmHlE6bZq8ANayUFyUFhvEA+Awpr5aQP6ClxyggPmDzumg5DuupM+kzyW NSkgSWa5tpxL2HAmd8Af2xEASLvcZxEjb/Qq+uXd7lQ9nhpEXDDNeX4aa5JnVEZQ4pj/ l0VQ== 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=FKdUU8WqNSmioxVBUoqF/0iIbNqZZRAZn2fTH57TvDQ=; b=piWSm5M8hVqwhYsUjPH7Eyq0R5aFGR90uB6yc2uwdMMyZ9/O1DmhphHVqBxgFG3ynk iom7aoR9aghrb/KTtFiJ7wW1UI3QVPh+xrZ/aPgNnZJY0ZVN0R8cwrE02ebQt6Va44v6 r+heebNk4cTGLlK7dx9zRMyo/JHRybqzeJTu0yIVfmXo9L+5DGJj2YFiXyUpOMh1JcAV b1uwLvKYlaZRWbUbRWzJMMSVEb10clrytCyduPPh06ynDdV6lPVXXcS2kPLUPniJeEGb m4rj1sKqiHwWzazrer43ogYqTwXQkbXgI6JGAMuwB5dNNvoHp6UiRrjIsrT6bzHr5iWY +Dzw== X-Gm-Message-State: AOAM531FjWpGPj/hh/yd3saVh2N33LVKDD6hHDACOIgcmyoDLMzqluIz 7J8nDNLGwyH2L8wwGMGuj8idYsM7QfoimJQFCC4= X-Google-Smtp-Source: ABdhPJwJF6d9MGkcAxGnf5cQecCUEI0mj+sDf7N8S8BAxpYVeOWsQVix7hZzsVI+kTGtnrVDTUpNgiKfZ4zfYqIDVmc= X-Received: by 2002:a63:251:: with SMTP id 78mr11313108pgc.54.1634337757191; Fri, 15 Oct 2021 15:42:37 -0700 (PDT) MIME-Version: 1.0 References: <202110021255323466813813@chinamobile.com> In-Reply-To: From: Gyan Mishra Date: Fri, 15 Oct 2021 18:42:26 -0400 Message-ID: To: "Francois Clad (fclad)" Cc: "Chengli (Cheng Li)" , James Guichard , SPRING WG , Yisong Liu , spring-chairs Content-Type: multipart/alternative; boundary="00000000000075e3c705ce6be99c" Archived-At: Subject: Re: [spring] =?utf-8?q?RE=EF=BC=9A_WG_Adoption_call_for_https=3A//da?= =?utf-8?q?tatracker=2Eietf=2Eorg/doc/draft-filsfilscheng-spring-srv6-srh-?= =?utf-8?q?compression/?= 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, 15 Oct 2021 22:45:59 -0000 --00000000000075e3c705ce6be99c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Francois Most Welcome! Responses in-line Kind Regards Gyan On Wed, Oct 13, 2021 at 6:53 AM Francois Clad (fclad) wrote: > Hi Gyan, > > > > Thanks for your feedback. The authors will work on some more illustration= s > to add in the draft. > Gyan> Excellent! In my previous email ( https://mailarchive.ietf.org/arch/msg/spring/ZfbHtQ1FTqWYqjXqcFuEf22I2L8/), I provided an example of how the Next-C-SID and Replace-C-SID flavors could be used together and with different C-SID lengths. Let me restate that, as shown in this example, there is no least common denominator for C-SID lengths between the flavors. Gyan> Yes that was a good illustration of mixed lengths between flavors. I have some comments and will respond to that post. As a side note, could you please use the terminology defined in this C-SID draft or in RFC 8986/8754? Your emails seem to mix them up and makes it difficult for me to understand your questions. Gyan> Will do > Thanks, > > Francois > > > > *From: *Gyan Mishra > *Date: *Sunday, 10 October 2021 at 22:23 > *To: *Chengli (Cheng Li) , Francois Clad (fclad) < > fclad@cisco.com> > *Cc: *James Guichard , SPRING WG < > spring@ietf.org>, Yisong Liu , spring-chairs < > spring-chairs@ietf.org> > *Subject: *Re: [spring] RE=EF=BC=9A WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > > > Hi Francois, Chengli & authors > > > > Many Thanks for your feedback to the WG on the critical topic > interoperability of the uSID micro-sid 16 bit uSID =E2=80=9CNF=3DLocato= r/Function > combo=E2=80=9D 128 bit container based solution and the G-SRV6 32 bit G-= SID > =E2=80=9CNF=3DLocator/Function combo=E2=80=9D 4 - 32 bit G-SID in 128 bit= container based > solution defined as Next and Replace flavors in the draft. > > > > I am really concerned as to how the next and replace interoperability > would work for adjacent nodes using SID within same or adjacent container= . > > > > Section 6.1 mentions that Next flavor recommendation is for 16 bit as th= e > uSID draft & this draft NF as 16 bit is most optimal uSID size within the > uSID container and Replace flavor recommendation is for 16 bit as the > G-SRV6 draft & this draft NF as 32 bit G-SID is most optimal G-SID size > within the G-SID container. > > > > Please elaborate on this in more detail, as with this draft for next and > replace interoperability, following the SRv6 compression requirements for > optimal hardware forwarding and state efficiency that Next would be > recommended to use 16 bit SID and Replace would be recommended 32 bit SID= . > Please elaborate in detail as to why 16 bit is not recommended for > replace flavor and 32 bit is not recommended for next flavor for all of t= he > requirements drafts list of SRv6 compression requirements each one by one > and the problems encountered when not using the recommended SID length. > > > > Thus for next and replace flavor interoperability even possible to work > would require two different SID sizes within the same container > interoperability caveats and now you have to deal with uSID container sty= le > using 16 bit SID and G-SID container style using 32 bit SID. > > > > From the requirements draft, interoperability perspective, the primary > objective is =E2=80=9Cencapsulation header compression=E2=80=9D as that i= s what we have > spent over a year on with DT finding an optimal compression solution. So > here the lowest common denominator ends up being 32 bit SID and we now ha= ve > failed the primary objective of a compression solution. > > > > As far as lowest common denominator is it true that in order to meet all > the requirements draft list of all SRv6 compression requirements both nex= t > and replace have to revert to that lowest common denominator which is 32 > bit SID. If that is true, unfortunately that makes the draft fail the > primary objective of any SRv6 compression solution. > > > > To that end as far as interoperability on Next and Replace > interoperability being the hinge pin of this drafts adoption, as well eve= n > if the authors state that Replace can use 16 bit SID as a possibility, as > the 32 bit =E2=80=9CNF=E2=80=9D G-SID is recommended for hardware forward= ing efficiency and > scalability that if 16 bit were used G-SID would fail the hardware > forwarding efficiency and scalability requirements as well as possibly > other requirements which should also be stated in the draft. > > > > *6.1 . C-SID Length* > > > > The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A > > C-SID length of 16-bit is recommended. > > > > The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths. > > A C-SID length of 32-bit is recommended. > > > > The draft should mention the recommendation for common block length for > interoperability. The only block size possible is 48 bit so block size s= o > that would be a major addressing inflexibility for interoperability. > > > > *6.2 . Block Length* > > > > The recommended SRv6 SID block sizes for the NEXT-C-SID flavor are > > 16, 32 or 48 bits. The smaller the block, the higher the compression > > efficiency. > > > > The recommended SRv6 SID block size for the REPLACE-C-SID flavor can > > be 48, 56, 64, 72 or 80 bits, depending on the needs of the operator. > > > > > > Taking this further another step as this draft needs to describe in detai= l > with examples of the feasibility of how two adjacent nodes one using next > 16 bit SID and other using replace 32 bit SID as recommended where the 16 > bit uSID next flavor and 32 bit G-SID are in the same SRH 128 bit contain= er. > > > > As the uSID Next flavor draft performs a shift towards B towards nibble A= , > B nibbles, and Replace does a replace of the A-Arg portion of the 128 bi= t > IPv6 address, how would that work with adjacent nodes using different SID > flavors of different SID lengths. > > > > > > The Next flavor uSID SRv6 PGM compression solution process is very > different where when indexing the micro sid nibbles within the 128 bit > container, it performs a shift towards the top lower order bits of the IP= v6 > address, where the Replace flavor G-SRv6 PGM compression solution indexin= g > the 4 G-SIDs within the container does a Replace at the A-Arg bottom high= er > order bits. > > > > The referencing of the 16 uSID or 32 bit G-SID nibbles, indexing and > reference of which nibble to referenced for next and replace for directly > adjacent nodes with nibbles within the same 128 bit container or adjacent > containers is the interoperability issue that seems to exist. > > > > This needs to be clarified on the next snd replace interoperability > operation in detail. > > > > Also Replace flavor uses COC delimiter for signaling compression function > is active where Next does not have any signaling of compression being > active or not or may have a different way of signaling that upcoming node > does not support compression. > > > > How does the compression signaling interoperability work between Next and > Replace flavors. That should be addressed as well in the draft. > > > > Kind Regards > > > > Gyan > > Verizon Inc > > > > On Fri, Oct 8, 2021 at 1:34 PM Francois Clad (fclad) > wrote: > > Hi Gyan, > > > > It is possible to combine SIDs of different C-SID flavors and C-SID > lengths in the same SRH, along with those defined in RFC 8986 After all, > they leverage the same SRv6 data plane. > > > > Let me give you an example. > > > > Assume that an SR source node wants to send a packet onto an SR path > through 10 SR segment endpoint nodes (nodes 1 through 10), and have a VPN > termination for a VRF 123 on a last SR segment endpoint node 11. > > > > The SR source node selects the segments as follows: > > - On nodes 1 through 5, the SID 2001:db8:0:0K01:: (with K being the > node ID) bound to End with NEXT-C-SID flavor and 16-bit C-SID length. > - On nodes 6 through 9, the SID 2001:db8:0:0K00:0001:: (with K being > the node ID) bound to End with REPLACE-C-SID flavor and 32-bit C-SID l= ength. > - On node 10, the SID 2001:db8:0:1000:0001:: bound to End (RFC 8986). > - On node 11, a SID 2001:db8:0:1100:d123:: bound to End.DT4 (RFC 8986) > for VRF 123. > > > > The SR source node then sends the packet onto the SR path by performing > the H.Encaps.Red behavior with: > > - IPv6 Source Address =3D > - IPv6 Destination Address =3D 2001:db8:0:0101:0201:0301:0401:0501 > - SRH =3D > > > - SegmentList[0] =3D 2001:db8:0:1100:d123:: > - SegmentList[1] =3D 1000:0001:0900:0001:0800:0001:0700:0001 > - SegmentList[2] =3D 2001:db8:0:0600:0001:: > > > > Therefore, there is no notion of lowest common denominator for C-SID leng= th. > Based on the deployment requirements, an operator has the flexibility to > select the SRv6 SID flavor and C-SID lengths of their choice. > > > > We can update the draft with this type of illustrations. > > > > Thanks, > > Francois > > > > *From: *spring on behalf of Gyan Mishra < > hayabusagsm@gmail.com> > *Date: *Sunday, 3 October 2021 at 21:01 > *To: *Yisong Liu > *Cc: *James Guichard , SPRING WG < > spring@ietf.org>, spring-chairs > *Subject: *Re: [spring] RE=EF=BC=9A WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > > > Hi Yisong > > > > The main goal for operators is interoperability. As interoperability is > the key reason for a single SRv6 compression solution that we have WG > consensus and is desired. > > > > Continued details of the interoperability study should be added to the > draft as the study progresses. > > > > One key detail that is missing is forwarding efficiency and scalability > using NEXT-C-SID and REPLACE-C-SID interoperability using 16 bit SID. > > > > As NEXT-CSID uSID Container Micro Segment shift flavor using GIB/LIB for > ultra scale SRv6 compression solution is recommended for 16 bit SID and > REPLACE-C-SID G-SID G-SID Container based solution is recommended for 32 > bit SID. > > > > Of all the requirements as stated, the encapsulation header size is the > primary objective for operators to eliminate MSD issues with optimal > forwarding and state efficiencies. > > > > At this time in order for Next and Replace solutions to be interoperable > keeping in mind requirements for optimal forwarding and state efficiency = 32 > bit SID would be the lowest common denominator which should be stated as > the baseline result of the analysis draft on CSID overall 2 prong solutio= n. > > > > CSID draft: > > > https://datatracker.ietf.org/doc/html/draft-filsfilscheng-spring-srv6-srh= -compression-02#section-11 > > > > Bottom of section 11: > > > > > > The interoperability was validated for the following scenario: > > > > o Packet forwarding through a traffic engineering segment list > > combining, in the same SRH ([RFC8754 ]), SRv6 SIDs bound to an > > endpoint behavior with the NEXT-C-SID flavor and SRv6 SIDs bound > > to an endpoint behavior with the REPLACE-C-SID flavor. > > > > Further interoperability testing is ongoing and will be reported in > > this document as the work progresses. > > > > King Regards > > > > Gyan > > On Sat, Oct 2, 2021 at 12:56 AM Yisong Liu > wrote: > > Hi Chairs & WG, > > > > I strongly support the adoption call. Regarding chair's note in the email= , > I would like to point that the network programming model (RFC8996) by > nature defines multiple behaviors. CSID has a single SRv6 based data plan= e > that defines the next and replace behaviors consistent with the network > programming paradigm. > > > > CSID's next and replace behaviors have been verified by interoperability > test in China mobile laboratory and there is no problem with the > interworking of the two behaviors on the CSID dataplane. > > > > Best Regards > > Yisong > > > > =E5=8F=91=E4=BB=B6=E4=BA=BA: James Guichard > > =E6=97=B6=E9=97=B4: 2021/10/01(=E6=98=9F=E6=9C=9F=E4=BA=94)22:04 > > =E6=94=B6=E4=BB=B6=E4=BA=BA: SPRING WG ; > > =E6=8A=84=E9=80=81=E4=BA=BA: spring-chairs ; > > =E4=B8=BB=E9=A2=98: [spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > > Dear WG: > > > > The chairs would like to express their appreciation for all the responses > received to our emails with reference to how the working group wishes to > move forward with respect to a solution for SRv6 compression. > > > > The apparent inclination of the working group is to use > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > as the basis for its compression standardization work. That is part of wh= at > this email attempts to confirm. > > > > Because of the above the chairs would like to issue a 2-week WG call for > adoption ending October 15th for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ > but with some clear guidelines as follows. By expressing support for > adoption of this document you are fully aware of and are acknowledging > that: > > > > 1. The SPRING working group is adopting a document that has multiple > SRv6 Endpoint behaviors. > 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change = as it goes > through review and analysis by the SPRING working group. > 3. All open discussion points raised on our mailing list MUST be > addressed BEFORE said document is allowed to progress from the working > group to publication. A list of these discussion points will be docume= nted > in the WG document and maintained by the document editor in conjunctio= n > with the chairs. > 4. If this document is adopted by the working group, the chairs > specify as part of the adoption call that the following text describin= g an > open issue be added to the document in the above-described open issues > section: > > > - "Given that the working group has said that it wants to standardize > one data plane solution, and given that the document contains multi= ple SRv6 > EndPoint behaviors that some WG members have stated are multiple da= ta plane > solutions, the working group will address whether this is valid and > coherent with its one data plane solution objective.". > > > > Please consider the above guidelines as you decide on whether to support > or not this WG adoption. Please express clearly your reasoning for > support/non-support as well as any open discussion points you would like > addressed should the document be adopted into the working group. > > > > Thanks! > > > > Jim, Bruno & Joel > > > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > -- > > > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com * > > *M 301 502-1347* > > > > -- > > > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email gyan.s.mishra@verizon.com * > > *M 301 502-1347* > > > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --00000000000075e3c705ce6be99c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi=C2=A0Francois

    Most Welcome!

    <= div dir=3D"auto">Responses in-line

    Kind Regards=C2=A0

    Gyan

    =
    On Wed, Oct 13, 2021 at 6:= 53 AM Francois Clad (fclad) <fclad@cisco.com> wrote:

    Hi Gyan,

    =C2=A0

    Thanks for your feedback. The authors will wor= k on some more illustrations to add in the draft.

    <= /div>

    =C2=A0Gyan> Excellent!<= u>

    In my previous email (https://mailarchive.ietf.org/arch/msg/spring/ZfbHtQ1FTqWYqjXqcFuEf22I2= L8/), I provided an example of how the Next-C-SID and Replace-C-SID fla= vors could be used together and with different C-SID lengths. Let me restate that, as shown in this exampl= e, there is no least common denominator for C-SID lengths between the flavo= rs.

    Gyan> =C2=A0= Yes that was a good illustration of mixed lengths between flavors. =C2=A0 I= have some comments and will respond to that post.

    <= div>

    As a side note, could you please use the termi= nology defined in this C-SID draft or in RFC 8986/8754? Your emails seem to= mix them up and makes it difficult for me to understand your questions.=

    =C2=A0Gyan> = Will do

    Thanks,

    Francois

    =C2=A0

    From: Gyan Mishra <hayabusagsm@gmail.c= om>
    Date: Sunday, 10 October 2021 at 22:23
    To: Chengli (Cheng Li) <c.l@huawei.com>, Francois Clad (fclad) <fclad@cisco.com>
    Cc: James Guichard <james.n.guichard@futurewei.com>, SPRING WG &l= t;spring@ietf.org&= gt;, Yisong Liu <liuyisong@chinamobile.com>, spring-chairs <spring-chairs@ietf.org>= ;
    Subject: Re: [spring] RE    =EF=BC=9A WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilsc= heng-spring-srv6-srh-compression/

    =C2=A0

    Hi Francois, Chengli &am= p; authors=C2=A0

    =C2=A0

    Many Thanks for your fee= dback to the WG on the critical topic interoperability of the uSID micro-si= d 16 bit uSID =C2=A0 =E2=80=9CNF=3DLocator/Function combo=E2=80=9D =C2=A012= 8 bit=C2=A0container based solution and the G-SRV6 32 bit G-SID =E2=80=9CNF= =3DLocator/Function combo=E2=80=9D 4 - 32 bit G-SID in 128 bit container based solution define= d as Next and Replace flavors in the draft.

    =C2=A0

    I am really concerned as= to how the next and replace interoperability would work for adjacent nodes= using SID within same or adjacent container.

    =C2=A0

    Section 6.1 mentions tha= t =C2=A0Next flavor recommendation is for 16 bit as the uSID draft & th= is draft NF as 16 bit is most optimal uSID size within the uSID container a= nd=C2=A0Replace flavor recommendation is for 16 bit as the G-SRV6 draft & this draft N= F as 32 bit G-SID is most optimal G-SID size within the G-SID container.=C2= =A0=C2=A0

    =C2=A0

    Please =C2=A0elaborate on this in more detail, as with thi= s draft for next and replace interoperability, following the SRv6 compressi= on requirements for optimal hardware forwarding and state efficiency that Next would be recommended to use 16 bit SID and = Replace would be recommended 32 bit SID. =C2=A0 Please elaborate in detail = as to why 16 bit is not recommended for replace flavor and 32 bit is not re= commended for next flavor for all of the requirements drafts list of SRv6 compression requirements each one by = one and the problems encountered when not using the recommended SID length.=

    =C2=A0

    Thus for next and replace flavor interoperability even pos= sible =C2=A0to work would require two different SID sizes within the same c= ontainer interoperability caveats and now you have to deal with uSID container style using 16 bit SID and G-SID cont= ainer style using 32 bit SID.<= /u>

    =C2=A0

    From the requirements draft, =C2=A0interoperability perspe= ctive, the primary objective is =E2=80=9Cencapsulation header compression= =E2=80=9D as that is what we have spent over a year on with DT finding an optimal compression solution.=C2=A0 So here the lowest commo= n denominator ends up being 32 bit SID and we now have failed the primary o= bjective of a compression solution. =C2=A0=C2=A0

    =C2=A0

    As far as lowest common denominator is it true that in ord= er to meet all the requirements draft list of all SRv6 compression requirem= ents both next and replace have to revert to that lowest common denominator which is 32 bit SID.=C2=A0 If that is tr= ue, unfortunately that makes the draft fail the primary objective of any SR= v6 compression solution.

    =C2=A0

    To that end as far as interoperability on Next and Replace= interoperability being the hinge pin of this drafts adoption, as well even= if the authors state that Replace can use 16 bit SID as a possibility, as the 32 bit =E2=80=9CNF=E2=80=9D G-SID = is recommended for hardware forwarding efficiency and scalability that if 1= 6 bit were used G-SID would fail the hardware forwarding efficiency and sca= lability requirements as well as possibly other requirements which should also be stated in the draft.

    =C2=A0

    6.1.=C2=A0 C-SID Leng=
th
    =C2=A0
    =C2=A0=C2=A0 The NEXT-C-SID flavor su=
pports both 16- and 32-bit C-SID lengths.=C2=A0 A

    =C2=A0=C2=A0 C-SID length of 16-bit i=
s recommended.
    

    =C2=A0
    

    =C2=A0=C2=A0 The REPLACE-C-SID flavor=
 supports both 16- and 32-bit C-SID lengths.
    

    =C2=A0=C2=A0 A C-SID length of 32-bit=
 is recommended.
    

    =C2=A0

    The draft should mention the recommendation for comm= on block length for interoperability.=C2=A0 The only block size possible is= 48 bit so block size so that would be a major addressing inflexibility for= interoperability.

    =C2=A0

    6.2.=C2=A0 Block Leng=
th
    =C2=A0
    =C2=A0=C2=A0 The recommended SRv6 SID=
 block sizes for the NEXT-C-SID flavor are
    =C2=A0=C2=A0 16, 32 or 48 bits.=C2=A0=
 The smaller the block, the higher the compression

    =C2=A0=C2=A0 efficiency.
    

    =C2=A0
    

    =C2=A0=C2=A0 The recommended SRv6 SID=
 block size for the REPLACE-C-SID flavor can
    

    =C2=A0=C2=A0 be 48, 56, 64, 72 or 80 =
bits, depending on the needs of the operator.
    

    =C2=A0

    =C2=A0

    Taking this further another step as this draft needs= to describe in detail with examples of the feasibility of how two adjacent= nodes one using next 16 bit SID and other using replace 32 bit SID as reco= mmended where the 16 bit uSID next flavor and 32 bit G-SID are in the same SRH 128 bit container.

    =C2=A0

    As the uSID Next flavor draft performs a shift towar= ds B towards nibble A, B nibbles, and Replace does a replace of the A-Arg p= ortion =C2=A0of the 128 bit IPv6 address, how would that work with adjacent= nodes using different SID flavors of different SID lengths. =C2=A0

    =C2=A0

    =C2=A0

    The Next flavor uSID SRv6 PGM =C2=A0compression solu= tion process is very different where when indexing the micro sid nibbles wi= thin the 128 bit container, it performs a shift towards the top lower order= bits of the IPv6 address, where the Replace flavor G-SRv6 PGM compression solution indexing the 4 G-SIDs within the co= ntainer does a Replace at the A-Arg bottom higher order bits. =C2=A0=

    =C2=A0

    The referencing of the 16 uSID or 32 =C2=A0bit G-SID= =C2=A0nibbles, indexing and reference of which nibble to referenced for ne= xt and replace for directly adjacent nodes with nibbles within the same 128= bit container or adjacent containers is the interoperability issue that seems to exist. =C2=A0

    =C2=A0

    This needs to be clarified on the next snd replace i= nteroperability operation in detail.

    =C2=A0

    Also Replace flavor uses COC delimiter for signaling= compression function is active where Next does not have any signaling of c= ompression being active or not or may have a different way of signaling tha= t upcoming node does not support compression.=C2=A0=C2=A0

    =C2=A0

    How does the compression signaling interoperability = work between Next and Replace flavors.=C2=A0 That should be addressed as we= ll in the draft.

    =C2=A0

    Kind Regards

    =C2=A0

    Gyan

    Verizon Inc=C2=A0

    =C2=A0

    On Fri, Oct 8, 2021 at 1:34 PM Francois Clad (fclad)= <fclad@cisco.com> wrote:

    Hi Gyan,

    =C2=A0

    It is possible to combine SIDs of different C-SID fl= avors and C-SID lengths in the same SRH, along with those defined in RFC 89= 86 After all, they leverage the same SRv6 data plane.

    =C2=A0

    Let me give you an example.

    =C2=A0

    Assume that an SR source= node wants to send a packet onto an SR path through 10 SR segment endpoint= nodes (nodes 1 through 10), and have a VPN termination for a VRF 123 on a last SR segment endpoint node 11.

    =C2=A0

    The SR source node selects the segments as follows:<= u>

    • On nodes 1 through 5, the SID 2001:db8:0:0K01:: (with K being the node ID) = bound to End with NEXT-C-SID flavor and 16-bit C-SID length.<= /li>
    • On nodes 6 through 9, the SID 2001:db8:0:0K00:0001:: (with K being the node= ID) bound to End with REPLACE-C-SID flavor and 32-bit C-SID length.=
    • On node 10, the SID 2001:db8:0:1000:0001:: bound to End (RFC 8986).<= u>
    • On node 11, a SID 2001:db8:0:1100:d123:: bound to End.DT4 (RFC 8986) for VR= F 123.

    =C2=A0

    The SR source node then sends the packet onto the SR= path by performing the H.Encaps.Red behavior with:

    • IPv6 Source Address =3D <an address of the SR source node><= /u>
    • IPv6 Destination Address =3D 2001:db8:0:0101:0201:0301:0401:0501<= /u>
    • SRH =3D
      • SegmentList[0] =3D 2001:db8:0:1100:d123::
      • SegmentList[1] =3D 1000:0001:0900:0001:0800:0001:0700:0001
      • SegmentList[2] =3D 2001:db8:0:0600:0001::

    =C2=A0

    Therefore, there is no notion of lowest common denom= inator for C-SID length. Based on the deploymen= t requirements, an operator has the flexibility to select the SRv6 SID flavor and C-= SID lengths of their choice.

    =C2=A0

    We can update the draft with this type of illustrati= ons.

    =C2=A0

    Thanks,

    Francois

    =C2=A0

    From: spring <spring-bounces@ietf.o= rg> on behalf of Gyan Mishra <hayabusagsm@gmail.com>
    Date: Sunday, 3 October 2021 at 21:01
    To: Yisong Liu <liuyisong@chinamobile.com>
    Cc: James Guichard <james.n.guichard@futurewei.com>, SPRING WG &l= t;spring@ietf.org&= gt;, spring-chairs <spring-chairs@ietf.org>
    Subject: Re: [spring] RE=EF=BC=9A WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/

    =C2=A0

    Hi=C2=A0Yisong

    =C2=A0

    The main goal for operators is interoperability.=C2= =A0 As interoperability is the key reason for a single SRv6 compression sol= ution that we have WG consensus and is desired. =C2=A0

    =C2=A0

    Continued details of the interoperability study =C2= =A0should be added to the draft as the study progresses.

    =C2=A0

    One key detail that is missing is forwarding efficie= ncy and scalability using NEXT-C-SID and REPLACE-C-SID interoperability usi= ng 16 bit SID. =C2=A0

    =C2=A0

    As NEXT-CSID uSID Container Micro Segment shift flav= or using GIB/LIB for ultra scale =C2=A0SRv6 compression solution is recomme= nded for 16 bit SID and REPLACE-C-SID G-SID G-SID Container based solution is recommended for 32 bit SID.

    =C2=A0

    Of all the requirements as stated, the encapsulation= header size is the primary objective for operators to eliminate MSD issues= with optimal forwarding and state efficiencies.=C2=A0

    =C2=A0

    At this time in order for Next and Replace solutions= to be interoperable keeping in mind requirements for optimal forwarding an= d state efficiency 32 bit SID would be the lowest common denominator which should be stated as the baseline result of the an= alysis draft on CSID overall 2 prong solution.

    =C2=A0

    CSID draft:

    Bottom of section 11:

    =C2=A0

    =C2=A0

    = =C2=A0 =C2=A0The interoperability was validated for the following scenario:= 

    =C2=A0
    =C2=A0=C2=A0 o=C2=A0 Packet forwardin=
g through a traffic engineering segment list
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 combin=
ing, in the same SRH ([RFC8754]), SRv6 SIDs bound to an
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 endpoi=
nt behavior with the NEXT-C-SID flavor and SRv6 SIDs bound=

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to an =
endpoint behavior with the REPLACE-C-SID flavor.
    =C2=A0
    =C2=A0=C2=A0 Further interoperability=
 testing is ongoing and will be reported in
    =C2=A0=C2=A0 this document as the wor=
k progresses.

    =C2=A0

    King Regards=C2=A0

    =C2=A0

    Gyan

    On Sat, Oct 2, 2021 at 12:56 AM Yisong Liu <liuyisong@chinamo= bile.com> wrote:

    Hi Chairs & = WG,

    =C2=A0=

    I strongly support the adoption c= all. Regarding chair's note in the email, I would like to point that the network programming model (RFC8996) by nature defines multiple be= haviors. CSID has a single SRv6 based data plane that defines the next and = replace behaviors consistent with the network programming paradigm.<= u>

    =C2=A0

    CSID's next and replace behav= iors have been verified by=C2=A0interoperability test=C2=A0in China mobile laboratory and there= is no problem with the interworking of the two behaviors on the CSID datap= lane.

    =C2=A0=

    Best Regards

    Yisong=

    =C2=A0

    =E5=8F=91=E4= =BB=B6=E4=BA=BA: James G= uichard

    =E6=97=B6=E9= =97=B4: 2021/10/01(=E6=98=9F=E6=9C=9F= =E4=BA=94)22:04<= u>

    =E6=94=B6=E4= =BB=B6=E4=BA=BA: SPRING WG;<= u>

    =E6=8A=84=E9= =80=81=E4=BA=BA: spring-chairs;

    Dear WG:

    =C2=A0

    The chairs would like to expres= s their appreciation for all the responses received to our emails with refe= rence to how the working group wishes to move forward with respect to a solution for SRv6 compression.

    =C2=A0

    The apparent inclination of the= working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is p= art of what this email attempts to confirm.

    =C2=A0

    Because of the above the chairs= would like to issue a 2-week WG call for adoption ending October 15th= for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support= for adoption of this document you are fully aware of and are acknowledging= that:

    =C2=A0

    1. The SPRING working group is adopting a document that h= as multiple SRv6 Endpoint behaviors.
    2. The document is a =E2=80=9Cliving=E2=80=9D document; i= t may change as it goes through review and analysis by the SPRING working g= roup.
    3. All open discussion points raised on our mailing list = MUST be addressed BEFORE said document is allowed to progress from the work= ing group to publication. A list of these discussion points will be documen= ted in the WG document and maintained by the document editor in conjunction with the chairs.
    4. If this document is adopted by the working group, the = chairs specify as part of the adoption call that the following text describ= ing an open issue be added to the document in the above-described open issu= es section:
      • "Given that the working group has said that it wa= nts to standardize one data plane solution, and given that the document con= tains multiple SRv6 EndPoint behaviors that some WG members have stated are= multiple data plane solutions, the working group will address whether this is valid and coherent with its one data pl= ane solution objective.".

    =C2=A0

    Please consider the above guide= lines as you decide on whether to support or not this WG adoption. Please e= xpress clearly your reasoning for support/non-support as well as any open discussion points you would like addressed should the = document be adopted into the working group.

    =C2=A0

    Thanks!

    =C2=A0

    Jim, Bruno & Joel=

    =C2=A0

    =C2=A0

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

    --

    Gyan Mishra

    Network Solutions Architect=C2=A0

    Email gyan.s.mishr= a@verizon.com

    M 301 502-1347

    =C2=A0

    --

    Gyan Mishra

    Network Solutions Architect=C2=A0

    Email gyan.s.mishr= a@verizon.com

    M 301 = 502-1347

    =C2=A0

    --

    =

    Gyan Mishra

    Network Solutions Architect=C2=A0<= /p>

    Email gyan.s.mishra@ver= izon.com<= br>

    M 301 502-1347


    --00000000000075e3c705ce6be99c-- From nobody Sat Oct 16 01:23:26 2021 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 1C47C3A0C64; Sat, 16 Oct 2021 01:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alibaba-inc.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 Rx1Sz9tAgXU6; Sat, 16 Oct 2021 01:23:18 -0700 (PDT) Received: from out0-153.mail.aliyun.com (out0-153.mail.aliyun.com [140.205.0.153]) (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 3AA093A0C5E; Sat, 16 Oct 2021 01:23:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1634372592; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=Kh9bZeAdMuvPF91mvZmWt2p0Rbr7PHvPN/q2sD1mbHI=; b=p+6ziT6RJZ7KRGkB77uUnAWaDrx4n+B+27j9S96dCkVeWBo2Yr58dY6VhM7UwPSJiG6Mw7nT41nLSqhGNh9oULPB96KSu3zUNTpGA9bilVoiMfqLAUojKg46qEIns0IVzueociD1MgVNR8ea25JWHcXLiSkOGhfjP6oLEcj26LI= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R161e4; CH=green; DM=||false|; DS=||; FP=0|-1|-1|-1|0|-1|-1|-1; HT=ay29a033018047203; MF=zhichun.jzc@alibaba-inc.com; NM=1; PH=DW; RN=5; SR=0; TI=alimail_yun_mac.COREAPI9ec7507ab1ac464eaaa6e8aee8d020b7; Received: from WS-web (zhichun.jzc@alibaba-inc.com[alimail_yun_mac.COREAPI9ec7507ab1ac464eaaa6e8aee8d020b7]) by ay29a011140100204.et135 at Sat, 16 Oct 2021 16:23:11 +0800 Date: Sat, 16 Oct 2021 16:23:11 +0800 From: "=?UTF-8?B?6JKL5rK75pilKOiLpeW8iCk=?=" To: "spring" , "spring@ietf.org" Cc: "james.n.guichard@futurewei.com" , "shay.zadok40broadcom.com@dmarc.ietf.org" , "bertrand@duvivier.com" Message-ID: X-Priority: 3 X-Mailer: [Alimail-Mailagent] MIME-Version: 1.0 In-Reply-To: References: Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_98586_7f27f8a56700_616a8bef_104797" Archived-At: Subject: [spring] =?utf-8?b?5Zue5aSN77yaIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0?= =?utf-8?q?tps=3A//datatracker=2Eietf=2Eorg/doc/draft-filsfilscheng-spring?= =?utf-8?q?-srv6-srh-compression/?= 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, 16 Oct 2021 08:23:23 -0000 ------=ALIBOUNDARY_98586_7f27f8a56700_616a8bef_104797 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgRGVhciBXR++8jAoKSSBzdXBwb3J0IHRoZSBhZG9wdGlvbiBvZiB0aGlzIGRyYWZ0LgpJIHRo aW5rIHRoaXMgcHJvcG9zYWwgbWVyZ2VzIHRoZSBHLVNJRCBhbmQgbWljb3ItU0lEIG1lY2hhbml6 bSBzdWNjZXNzZnVsbHkgYmFzZWQgb24gdGhlIHN0YW5kYXJkaXplZCBTUkggZm9ybWF0IGFuZCBn ZXRzIHdlbGwgc3VwcG9ydCBieSB0aGUgbWFpbiBzdHJlYW0gY2hpcCB2ZW5kb3IuIEl0IGRvZXMg aGVscCByZWR1Y2luZyB0aGUgU1J2NiBTSUQgc2l6ZSBpbiBhIGJyaWxsaWFudCB3YXkuCgpUaGFu a3MKCgpCUgpSb3kgSmlhbmcKTmV0d29yayBBcmNoaXRlY3RAQWxpYmFiYSBDbG91ZAoK4oCLCgog LS0tLS0tLS0tLS0tLS0tLS0t5Y6f5aeL6YKu5Lu2IC0tLS0tLS0tLS0tLS0tLS0tLQrlj5Hku7bk uro6c3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZz4K5Y+R6YCB5pe26Ze0OkZyaSBPY3Qg MTUgMjM6MDM6MzMgMjAyMQrmlLbku7bkuro6c3ByaW5nQGlldGYub3JnIDxzcHJpbmdAaWV0Zi5v cmc+CuaKhOmAgTpqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20gPGphbWVzLm4uZ3VpY2hh cmRAZnV0dXJld2VpLmNvbT4sIHNoYXkuemFkb2s0MGJyb2FkY29tLmNvbUBkbWFyYy5pZXRmLm9y ZyA8c2hheS56YWRvaz00MGJyb2FkY29tLmNvbUBkbWFyYy5pZXRmLm9yZz4sIGJlcnRyYW5kQGR1 dml2aWVyLmNvbSA8YmVydHJhbmRAZHV2aXZpZXIuY29tPgrkuLvpopg6W3NwcmluZ10gV0cgQWRv cHRpb24gY2FsbCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmls c2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vCgpEZWFyIFdvcmtpbmcgR3Jv dXAsIAogCkkgd291bGQgbGlrZSB0byBjb25maXJtIHRoYXQgQ2lzY28gcGFydGljaXBhdGVkIHRv IHRoZSBpbnRlcm9wcyBtZW50aW9uZWQgYnkgU2hheS4gVGhleSB3ZXJlIGFsbOKAr3N1Y2Nlc3Nm dWwgYW5kIGxlZCB0byBkZXBsb3ltZW50cy4gCiAKSSB3b3VsZCBsaWtlIHRvIHJlbWluZCB0aGF0 IENpc2NvIGhhcyBiZWVuIHNoaXBwaW5nIHByb2R1Y3RzIHN1cHBvcnRpbmcgdGhpcyBkcmFmdCBm b3IgfjEwIG1vbnRocywgYWNyb3NzIG91ciBoYXJkd2FyZSBwcm9kdWN0IGxpbmU64oCvIArCtyBO Q1MgNTUwMCAKwrcgTkNTIDU2MCAKwrcgTkNTIDU0MCAKwrcgTkNTIDU0MC1MIArCtyBBU1IgOTAw MCAoVG9tYWhhd2spIArCtyBBU1IgOTAwMCAoTGlnaHRTcGVlZCkgCsK3IE5DUyA1NzAwIChOZWFy IEZDUykgCsK3IFNpbGljb24gT25lIC0gODAwMCAoTmVhciBGQ1MpICAKwrcgWFI5MDAwICh2aXJ0 dWFsKSAgCgoKSSB3b3VsZCBhbHNvIGxpa2UgdG8gcmVtaW5kIHRoYXQgQ2lzY28gYW5kIFJha3V0 ZW4gaGF2ZSBwdWJsaWNseSBjb21tdW5pY2F0ZWQgb24gdGhlIGNvbW1lcmNpYWwgZGVwbG95bWVu dCBvZiB0aGUgdGVjaG5vbG9neSBzcGVjaWZpZWQgaW4gdGhpcyBkcmFmdC4gRnVydGhlcm1vcmUs IHRoZSB0ZWNobm9sb2d5IGlzIGFsc28gZGVwbG95ZWQgaW4gcHJvZHVjdGlvbiB3aXRoIGxpdmUg dHJhZmZpYyBpbiBCZWxsIENhbmFkYeKAmXMgbmV0d29yayBpbiBhIG11bHRpdmVuZG9yIGVudmly b25tZW50LiBUaGVyZSBhcmUgYWRkaXRpb25hbCB1bmRpc2Nsb3NlZCBkZXBsb3ltZW50cy4gIAog Ckkgc3Ryb25nbHkgc3VwcG9ydCB0aGUgYWRvcHRpb24gb2YgdGhpcyBkcmFmdCAKCgpPbiAxNCBP Y3QgMjAyMSwgYXQgMTA6NDgsIFNoYXkgWmFkb2sgPHNoYXkuemFkb2s9NDBicm9hZGNvbS5jb21A ZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOgoKRGVhciBXRywgCgpXZSB3b3VsZCBsaWtlIHRvIHVwZGF0 ZSBvbiB0aGUgcHJvZHVjdGlvbiBzdXBwb3J0IGJ5IHRoZSBTdHJhdGFETlggcHJvZHVjdHMgb2Yg Ym90aCBmbGF2b3JzIFJFUExBQ0UgYW5kIE5FWFQgYXMgZGVmaW5lZCBpbiBDU0lEIGRyYWZ0LCBh cyB3ZWxsIGFzIG5vbi1jb21wcmVzc2VkICJDbGFzc2ljIiBTUnY2LiAKU3RyYXRhRE5YIHByb2R1 Y3RzIGluY2x1ZGU6IEplcmljaG8yL0plcmljaG8yYy9RdW1yYW4yYy9RdW1yYW4yYS9RdW1yYW4y dS9RdW1yYW4ybi9KZXJpY2hvMmMrIGFuZCBhbnkgZnV0dXJlIGRldmljZQoKVGhpcyBzdXBwb3J0 IGtlZXBzOgoxLiBTaW5nbGUgYW5kIHVuaWZpZWQgZGF0YS1wbGFuZSB1Q29kZSwgcHJvZ3JhbW1l ZCB1c2luZyBoaWdoIGxldmVsIGxhbmd1YWdlCjIuIFNpbmdsZSBkYXRhLXBsYW5lIEFQSQozLiBD b25jdXJyZW50L1NpbXVsdGFuZW91cyBzdXBwb3J0IG9mIGFsbCB0aHJlZSB0ZWNobmlxdWVzIGJh c2VkIG9uIGEgcGVyLXBhY2tldCBiZWhhdmlvcgo0LiBDb25jdXJyZW50L1NpbXVsdGFuZW91cyBz dXBwb3J0IG9mIGFsbCB0aHJlZSB0ZWNobmlxdWVzIGluc2lkZSBvZiB0aGUgc2FtZSBTUnY2IEhl YWRlcgo1LiBJbiBhbGwgdGhyZWUgdGVjaG5pcXVlcyB0aGUgZm9sbG93aW5nIGlzIGFscmVhZHkg c3VwcG9ydGVkIGNvbmN1cnJlbnRseS9zaW11bHRhbmVvdXNseSBhbmQgaW4gcHJvZHVjdGlvbgog ICAgMS4gU1J2NiBtYWluIGJlaGF2aW9ycyAtIGNvbXBsaWFudCB3aXRoIHJmYzg5ODYKICAgIDIu IFNSdjYgaW5zZXJ0IGJlaGF2aW9ycyAtIGNvbXBsaWFudCB3aXRoIGRyYWZ0LXNydjYtbmV0LXBn bS1pbnNlcnRpb24KICAgIDMuIFNSdjYgbWlkcG9pbnQgcHJvdGVjdGlvbiBiZWhhdmlvcnMgLSBj b21wbGlhbnQgd2l0aCBkcmFmdC1taWRwb2ludC1wcm90ZWN0aW9uCgpBbGwgb2YgdGhlIGFib3Zl IGlzIGluIHByb2R1Y3Rpb24gZGVwbG95bWVudCBpbiB2YXJpb3VzIHB1Ymxpc2hlZCBhbmQgdW5w dWJsaXNoZWQgbmV0d29ya3MgYXJvdW5kIHRoZSBnbG9iZS4KT3VyIHByb2R1Y3RzIGFyZSB1c2Vk IGJ5IGluZHVzdHJ5IGxlYWRpbmcgT0VNIChzb21lIG9mIHRoZW0gcHVibGlzaGVkIHRoZXkgYXJl IHVzaW5nIHRoZSBTdHJhdGFETlggcHJvZHVjdHMpIGFuZCAicHVyZSIgTk9TIHZlbmRvcnMuCgpC UkNNIHVzaW5nIEplcmljaG8yIHBhcnRpY2lwYXRlZCBpbiBjb3VwbGUgb2YgaW50ZXJvcHMgdGhh dCBpbmNsdWRlZCBzb21lIG1peCBvZiBSRVBMQUNFLUNTSUQsIE5FWFQtQ1NJRCBhbmQgbm9uLWNv bXByZXNzZWQgIkNsYXNzaWMiIFNSdjYgLSBhbmQgYWxsIGludGVyb3BzIGhhdmUgZW5kZWQgc3Vj Y2Vzc2Z1bGx5CgpUaGFua3MgJiBSZWdhcmRzLApTaGF5CgogCiAK5Y+R5Lu25Lq6OiBzcHJpbmcg W21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIEphbWVzIEd1aWNoYXJkCuWP kemAgeaXtumXtDogMjAyMeW5tDEw5pyIMeaXpSAyMjowNQrmlLbku7bkuro6IFNQUklORyBXRyA8 c3ByaW5nQGlldGYub3JnPgrmioTpgIE6IHNwcmluZy1jaGFpcnNAaWV0Zi5vcmcK5Li76aKYOiBb c3ByaW5nXSBXRyBBZG9wdGlvbiBjYWxsIGZvciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8KIApE ZWFyIFdHOgogClRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBleHByZXNzIHRoZWlyIGFwcHJlY2lh dGlvbiBmb3IgYWxsIHRoZSByZXNwb25zZXMgcmVjZWl2ZWQgdG8gb3VyIGVtYWlscyB3aXRoIHJl ZmVyZW5jZSB0byBob3cgdGhlIHdvcmtpbmcgZ3JvdXAgd2lzaGVzIHRvIG1vdmUgZm9yd2FyZCB3 aXRoIHJlc3BlY3QgdG8gYSBzb2x1dGlvbiBmb3IgU1J2NiBjb21wcmVzc2lvbi4KIApUaGUgYXBw YXJlbnQgaW5jbGluYXRpb24gb2YgdGhlIHdvcmtpbmcgZ3JvdXAgaXMgdG8gdXNlIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYt c3JoLWNvbXByZXNzaW9uLyBhcyB0aGUgYmFzaXMgZm9yIGl0cyBjb21wcmVzc2lvbiBzdGFuZGFy ZGl6YXRpb24gd29yay4gVGhhdCBpcyBwYXJ0IG9mIHdoYXQgdGhpcyBlbWFpbCBhdHRlbXB0cyB0 byBjb25maXJtLgogCkJlY2F1c2Ugb2YgdGhlIGFib3ZlIHRoZSBjaGFpcnMgd291bGQgbGlrZSB0 byBpc3N1ZSBhIDItd2VlayBXRyBjYWxsIGZvciBhZG9wdGlvbiBlbmRpbmcgT2N0b2JlciAxNXRo IGZvciBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5n LXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8gYnV0IHdpdGggc29tZSBjbGVhciBndWlkZWxp bmVzIGFzIGZvbGxvd3MuIEJ5IGV4cHJlc3Npbmcgc3VwcG9ydCBmb3IgYWRvcHRpb24gb2YgdGhp cyBkb2N1bWVudCB5b3UgYXJlIGZ1bGx5IGF3YXJlIG9mIGFuZCBhcmUgYWNrbm93bGVkZ2luZyB0 aGF0OgogClRoZSBTUFJJTkcgd29ya2luZyBncm91cCBpcyBhZG9wdGluZyBhIGRvY3VtZW50IHRo YXQgaGFzIG11bHRpcGxlIFNSdjYgRW5kcG9pbnQgYmVoYXZpb3JzLgpUaGUgZG9jdW1lbnQgaXMg YSDigJxsaXZpbmfigJ0gZG9jdW1lbnQ7IGl0IG1heSBjaGFuZ2UgYXMgaXQgZ29lcyB0aHJvdWdo IHJldmlldyBhbmQgYW5hbHlzaXMgYnkgdGhlIFNQUklORyB3b3JraW5nIGdyb3VwLgpBbGwgb3Bl biBkaXNjdXNzaW9uIHBvaW50cyByYWlzZWQgb24gb3VyIG1haWxpbmcgbGlzdCBNVVNUIGJlIGFk ZHJlc3NlZCBCRUZPUkUgc2FpZCBkb2N1bWVudCBpcyBhbGxvd2VkIHRvIHByb2dyZXNzIGZyb20g dGhlIHdvcmtpbmcgZ3JvdXAgdG8gcHVibGljYXRpb24uIEEgbGlzdCBvZiB0aGVzZSBkaXNjdXNz aW9uIHBvaW50cyB3aWxsIGJlIGRvY3VtZW50ZWQgaW4gdGhlIFdHIGRvY3VtZW50IGFuZCBtYWlu dGFpbmVkIGJ5IHRoZSBkb2N1bWVudCBlZGl0b3IgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgY2hh aXJzLgpJZiB0aGlzIGRvY3VtZW50IGlzIGFkb3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAsIHRo ZSBjaGFpcnMgc3BlY2lmeSBhcyBwYXJ0IG9mIHRoZSBhZG9wdGlvbiBjYWxsIHRoYXQgdGhlIGZv bGxvd2luZyB0ZXh0IGRlc2NyaWJpbmcgYW4gb3BlbiBpc3N1ZSBiZSBhZGRlZCB0byB0aGUgZG9j dW1lbnQgaW4gdGhlIGFib3ZlLWRlc2NyaWJlZCBvcGVuIGlzc3VlcyBzZWN0aW9uOgoiR2l2ZW4g dGhhdCB0aGUgd29ya2luZyBncm91cCBoYXMgc2FpZCB0aGF0IGl0IHdhbnRzIHRvIHN0YW5kYXJk aXplIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uLCBhbmQgZ2l2ZW4gdGhhdCB0aGUgZG9jdW1lbnQg Y29udGFpbnMgbXVsdGlwbGUgU1J2NiBFbmRQb2ludCBiZWhhdmlvcnMgdGhhdCBzb21lIFdHIG1l bWJlcnMgaGF2ZSBzdGF0ZWQgYXJlIG11bHRpcGxlIGRhdGEgcGxhbmUgc29sdXRpb25zLCB0aGUg d29ya2luZyBncm91cCB3aWxsIGFkZHJlc3Mgd2hldGhlciB0aGlzIGlzIHZhbGlkIGFuZCBjb2hl cmVudCB3aXRoIGl0cyBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiBvYmplY3RpdmUuIi4KIApQbGVh c2UgY29uc2lkZXIgdGhlIGFib3ZlIGd1aWRlbGluZXMgYXMgeW91IGRlY2lkZSBvbiB3aGV0aGVy IHRvIHN1cHBvcnQgb3Igbm90IHRoaXMgV0cgYWRvcHRpb24uIFBsZWFzZSBleHByZXNzIGNsZWFy bHkgeW91ciByZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9uLXN1cHBvcnQgYXMgd2VsbCBhcyBhbnkg b3BlbiBkaXNjdXNzaW9uIHBvaW50cyB5b3Ugd291bGQgbGlrZSBhZGRyZXNzZWQgc2hvdWxkIHRo ZSBkb2N1bWVudCBiZSBhZG9wdGVkIGludG8gdGhlIHdvcmtpbmcgZ3JvdXAuCiAKVGhhbmtzIQog CkppbSwgQnJ1bm8gJiBKb2VsCiAKIAoKClRoaXMgZWxlY3Ryb25pYyBjb21tdW5pY2F0aW9uIGFu ZCB0aGUgaW5mb3JtYXRpb24gYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0LCBvciBh dHRhY2hlZCB0byBpdCwgYXJlIGNvbmZpZGVudGlhbCBhbmQgYXJlIGludGVuZGVkIHNvbGVseSBm b3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSBpdCBpcyBhZGRy ZXNzZWQgYW5kIG1heSBjb250YWluIGluZm9ybWF0aW9uIHRoYXQgaXMgY29uZmlkZW50aWFsLCBs ZWdhbGx5IHByaXZpbGVnZWQsIHByb3RlY3RlZCBieSBwcml2YWN5IGxhd3MsIG9yIG90aGVyd2lz ZSByZXN0cmljdGVkIGZyb20gZGlzY2xvc3VyZSB0byBhbnlvbmUgZWxzZS4gSWYgeW91IGFyZSBu b3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCBvciB0aGUgcGVyc29uIHJlc3BvbnNpYmxlIGZvciBk ZWxpdmVyaW5nIHRoZSBlLW1haWwgdG8gdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBo ZXJlYnkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBjb3B5aW5nLCBkaXN0cmlidXRpbmcsIGRpc3Nl bWluYXRpb24sIGZvcndhcmRpbmcsIHByaW50aW5nLCBvciBjb3B5aW5nIG9mIHRoaXMgZS1tYWls IGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSByZWNlaXZlZCB0aGlzIGUtbWFpbCBpbiBl cnJvciwgcGxlYXNlIHJldHVybiB0aGUgZS1tYWlsIHRvIHRoZSBzZW5kZXIsIGRlbGV0ZSBpdCBm cm9tIHlvdXIgY29tcHV0ZXIsIGFuZCBkZXN0cm95IGFueSBwcmludGVkIGNvcHkgb2YgaXQuX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kc3ByaW5nIG1haWxp bmcgbGlzdApzcHJpbmdAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zcHJpbmcK ------=ALIBOUNDARY_98586_7f27f8a56700_616a8bef_104797 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBpZD0ibWFpbGJveC1jb252ZXJzYXRpb24iIHN0eWxlPSJjb2xvcjojNDk0RjUwO2ZvbnQt c2l6ZToxNC4wMDAwMDBweDtmb250LWZhbWlseTonSGVsdmV0aWNhIE5ldWUnIj48ZGl2PjxkaXYg c3R5bGU9Im1hcmdpbjogMHB4OyBwYWRkaW5nOiAwcHg7IGJvcmRlcjogMHB4OyBvdXRsaW5lOiAw cHg7IGNhcmV0LWNvbG9yOiByZ2IoNzMsIDc5LCA4MCk7IGNvbG9yOiByZ2IoNzMsIDc5LCA4MCk7 IGZvbnQtZmFtaWx5OiAmcXVvdDtoZWx2ZXRpY2EgbmV1ZSZxdW90OzsgZm9udC1zaXplOiAxNHB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiPjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBwYWRkaW5n OiAwcHg7IGJvcmRlcjogMHB4OyBvdXRsaW5lOiAwcHg7IGNhcmV0LWNvbG9yOiByZ2IoNzMsIDc5 LCA4MCk7IGNvbG9yOiByZ2IoNzMsIDc5LCA4MCk7IGZvbnQtZmFtaWx5OiAmcXVvdDtoZWx2ZXRp Y2EgbmV1ZSZxdW90OzsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+PGRpdiBz dHlsZT0ibWFyZ2luOiAwcHg7IHBhZGRpbmc6IDBweDsgYm9yZGVyOiAwcHg7IG91dGxpbmU6IDBw eDsgY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1m YW1pbHk6IHRhaG9tYSwgYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsg Y2xlYXI6IGJvdGg7Ij48c3BhbiBjbGFzcz0iIF9fYWxpeXVuX25vZGVfaGFzX2NvbG9yIiBzdHls ZT0ibWFyZ2luOiAwcHg7IHBhZGRpbmc6IDBweDsgYm9yZGVyOiAwcHg7IG91dGxpbmU6IDBweDsg Zm9udC1mYW1pbHk6IHRhaG9tYSwgYXJpYWwsIHN0aGVpdGksIHNpbXN1bjsgY29sb3I6IHJnYigw LCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyI+SGkgRGVhciBXR++8jDwvc3Bhbj48L2Rpdj48ZGl2 IHN0eWxlPSJtYXJnaW46IDBweDsgcGFkZGluZzogMHB4OyBib3JkZXI6IDBweDsgb3V0bGluZTog MHB4OyBjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250 LWZhbWlseTogdGFob21hLCBhcmlhbDsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3Jt YWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0 ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAw cHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25l OyBjbGVhcjogYm90aDsiPjxzcGFuIGNsYXNzPSIgX19hbGl5dW5fbm9kZV9oYXNfY29sb3IiIHN0 eWxlPSJtYXJnaW46IDBweDsgcGFkZGluZzogMHB4OyBib3JkZXI6IDBweDsgb3V0bGluZTogMHB4 OyBmb250LWZhbWlseTogdGFob21hLCBhcmlhbCwgc3RoZWl0aSwgc2ltc3VuOyBjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7Ij48YnIgc3R5bGU9Im91dGxpbmU6IG5vbmU7Ij48 L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IHBhZGRpbmc6IDBweDsgYm9yZGVy OiAwcHg7IG91dGxpbmU6IDBweDsgY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJn YigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IHRhaG9tYSwgYXJpYWw7IGZvbnQtc2l6ZTogMTRweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsgY2xlYXI6IGJvdGg7Ij48c3BhbiBjbGFzcz0iIF9fYWxpeXVuX25v ZGVfaGFzX2NvbG9yIiBzdHlsZT0ibWFyZ2luOiAwcHg7IHBhZGRpbmc6IDBweDsgYm9yZGVyOiAw cHg7IG91dGxpbmU6IDBweDsgZm9udC1mYW1pbHk6IHRhaG9tYSwgYXJpYWwsIHN0aGVpdGksIHNp bXN1bjsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAxNHB4OyI+SSZuYnNwO3N1cHBv cnQmbmJzcDt0aGUmbmJzcDthZG9wdGlvbiZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2RyYWZ0Ljwv c3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgcGFkZGluZzogMHB4OyBib3JkZXI6 IDBweDsgb3V0bGluZTogMHB4OyBjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjogcmdi KDAsIDAsIDApOyBmb250LWZhbWlseTogdGFob21hLCBhcmlhbDsgZm9udC1zaXplOiAxNHB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1k ZWNvcmF0aW9uOiBub25lOyBjbGVhcjogYm90aDsiPjxzcGFuIGNsYXNzPSIgX19hbGl5dW5fbm9k ZV9oYXNfY29sb3IiIHN0eWxlPSJtYXJnaW46IDBweDsgcGFkZGluZzogMHB4OyBib3JkZXI6IDBw eDsgb3V0bGluZTogMHB4OyBmb250LWZhbWlseTogdGFob21hLCBhcmlhbCwgc3RoZWl0aSwgc2lt c3VuOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7Ij5JIHRoaW5rIHRoaXMg cHJvcG9zYWwgbWVyZ2VzIHRoZSBHLVNJRCBhbmQgbWljb3ItU0lEIG1lY2hhbml6bSBzdWNjZXNz ZnVsbHkgYmFzZWQgb24gdGhlIHN0YW5kYXJkaXplZCBTUkggZm9ybWF0IGFuZCBnZXRzIHdlbGwg c3VwcG9ydCBieSB0aGUgbWFpbiBzdHJlYW0gY2hpcCB2ZW5kb3IuIEl0IGRvZXMgaGVscCByZWR1 Y2luZyB0aGUgU1J2NiBTSUQgc2l6ZSBpbiBhIGJyaWxsaWFudCB3YXkuPC9zcGFuPjwvZGl2Pjxk aXYgc3R5bGU9Im1hcmdpbjogMHB4OyBwYWRkaW5nOiAwcHg7IGJvcmRlcjogMHB4OyBvdXRsaW5l OiAwcHg7IGNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiB0YWhvbWEsIGFyaWFsOyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0 dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7 IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5v bmU7IGNsZWFyOiBib3RoOyI+PHNwYW4gY2xhc3M9IiBfX2FsaXl1bl9ub2RlX2hhc19jb2xvciIg c3R5bGU9Im1hcmdpbjogMHB4OyBwYWRkaW5nOiAwcHg7IGJvcmRlcjogMHB4OyBvdXRsaW5lOiAw cHg7IGZvbnQtZmFtaWx5OiB0YWhvbWEsIGFyaWFsLCBzdGhlaXRpLCBzaW1zdW47IGNvbG9yOiBy Z2IoMCwgMCwgMCk7IGZvbnQtc2l6ZTogMTRweDsiPjxiciBzdHlsZT0ib3V0bGluZTogbm9uZTsi PlRoYW5rczwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgcGFkZGluZzogMHB4 OyBib3JkZXI6IDBweDsgb3V0bGluZTogMHB4OyBjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogdGFob21hLCBhcmlhbDsgZm9udC1zaXpl OiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBjbGVhcjogYm90aDsiPjxiciBzdHlsZT0ib3V0bGlu ZTogbm9uZTsiPjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBwYWRkaW5nOiAw cHg7IGJvcmRlcjogMHB4OyBvdXRsaW5lOiAwcHg7IGNhcmV0LWNvbG9yOiByZ2IoNzMsIDc5LCA4 MCk7IGNvbG9yOiByZ2IoNzMsIDc5LCA4MCk7IGZvbnQtZmFtaWx5OiAmcXVvdDtoZWx2ZXRpY2Eg bmV1ZSZxdW90OzsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQt dGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyI+PHNwYW4gc3R5 bGU9Im1hcmdpbjogMHB4OyBwYWRkaW5nOiAwcHg7IGJvcmRlcjogMHB4OyBvdXRsaW5lOiAwcHg7 Ij48YnIgc3R5bGU9Im91dGxpbmU6IG5vbmU7Ij48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0ibWFy Z2luOiAwcHg7IHBhZGRpbmc6IDBweDsgYm9yZGVyOiAwcHg7IG91dGxpbmU6IDBweDsgY2FyZXQt Y29sb3I6IHJnYig3MywgNzksIDgwKTsgY29sb3I6IHJnYig3MywgNzksIDgwKTsgZm9udC1mYW1p bHk6ICZxdW90O2hlbHZldGljYSBuZXVlJnF1b3Q7OyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5 bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50 OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNw YWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRp b246IG5vbmU7Ij48ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgcGFkZGluZzogMHB4OyBib3JkZXI6 IDBweDsgb3V0bGluZTogMHB4OyI+PGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IHBhZGRpbmc6IDBw eDsgYm9yZGVyOiAwcHg7IG91dGxpbmU6IDBweDsgY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsg Y29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6ICZxdW90O21pY3Jvc29mdCB5YWhlaSZx dW90OzsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1j YXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9u ZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBjbGVhcjogYm90aDsiPkJS PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IHBhZGRpbmc6IDBweDsgYm9yZGVyOiAwcHg7 IG91dGxpbmU6IDBweDsgY2FyZXQtY29sb3I6IHJnYigwLCAwLCAwKTsgY29sb3I6IHJnYigwLCAw LCAwKTsgZm9udC1mYW1pbHk6ICZxdW90O21pY3Jvc29mdCB5YWhlaSZxdW90OzsgZm9udC1zaXpl OiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZv bnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0 YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6 IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDsgdGV4dC1kZWNvcmF0aW9uOiBub25lOyBjbGVhcjogYm90aDsiPlJveSBKaWFuZzwvZGl2Pjxk aXYgc3R5bGU9Im1hcmdpbjogMHB4OyBwYWRkaW5nOiAwcHg7IGJvcmRlcjogMHB4OyBvdXRsaW5l OiAwcHg7IGNhcmV0LWNvbG9yOiByZ2IoMCwgMCwgMCk7IGNvbG9yOiByZ2IoMCwgMCwgMCk7IGZv bnQtZmFtaWx5OiAmcXVvdDttaWNyb3NvZnQgeWFoZWkmcXVvdDs7IGZvbnQtc2l6ZTogMTRweDsg Zm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQt ZGVjb3JhdGlvbjogbm9uZTsgY2xlYXI6IGJvdGg7Ij5OZXR3b3JrIEFyY2hpdGVjdEBBbGliYWJh IENsb3VkPC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luOiAwcHg7IHBh ZGRpbmc6IDBweDsgYm9yZGVyOiAwcHg7IG91dGxpbmU6IDBweDsgY2FyZXQtY29sb3I6IHJnYig3 MywgNzksIDgwKTsgY29sb3I6IHJnYig3MywgNzksIDgwKTsgZm9udC1mYW1pbHk6ICZxdW90O2hl bHZldGljYSBuZXVlJnF1b3Q7OyBmb250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsg Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNw YWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5k ZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRv d3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1 dG87IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgdGV4dC1kZWNvcmF0aW9uOiBub25l OyI+PHNwYW4gc3R5bGU9Im1hcmdpbjogMHB4OyBwYWRkaW5nOiAwcHg7IGJvcmRlcjogMHB4OyBv dXRsaW5lOiAwcHg7Ij48YnI+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBw YWRkaW5nOiAwcHg7IGJvcmRlcjogMHB4OyBvdXRsaW5lOiAwcHg7IGNhcmV0LWNvbG9yOiByZ2Io NzMsIDc5LCA4MCk7IGNvbG9yOiByZ2IoNzMsIDc5LCA4MCk7IGZvbnQtZmFtaWx5OiAmcXVvdDto ZWx2ZXRpY2EgbmV1ZSZxdW90OzsgZm9udC1zaXplOiAxNHB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWlu ZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lk b3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBh dXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHRleHQtZGVjb3JhdGlvbjogbm9u ZTsiPjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBwYWRkaW5nOiAwcHg7IGJvcmRlcjogMHB4OyBv dXRsaW5lOiAwcHg7Ij48ZGl2IHN0eWxlPSJtYXJnaW46IDBweDsgcGFkZGluZzogMHB4OyBib3Jk ZXI6IDBweDsgb3V0bGluZTogMHB4OyBjYXJldC1jb2xvcjogcmdiKDAsIDAsIDApOyBjb2xvcjog cmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogJnF1b3Q7bWljcm9zb2Z0IHlhaGVpJnF1b3Q7OyBm b250LXNpemU6IDE0cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1h bGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0 ZS1zcGFjZTogbm9ybWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyB0ZXh0LWRlY29yYXRpb246IG5vbmU7IGNsZWFyOiBib3RoOyI+4oCLPGJyPjwv ZGl2PjwvZGl2PjwvZGl2PjwvZGl2PjxibG9ja3F1b3RlPjxkaXY+PGRpdiBzdHlsZT0iZm9udC1z aXplOiA3MCUiPiAtLS0tLS0tLS0tLS0tLS0tLS3ljp/lp4vpgq7ku7YgLS0tLS0tLS0tLS0tLS0t LS0tPC9kaXY+PGRpdj48Yj7lj5Hku7bkuro6PC9iPnNwcmluZyAmbHQ7c3ByaW5nLWJvdW5jZXNA aWV0Zi5vcmcmZ3Q7PC9kaXY+PGRpdj48Yj7lj5HpgIHml7bpl7Q6PC9iPkZyaSBPY3QgMTUgMjM6 MDM6MzMgMjAyMTwvZGl2PjxkaXY+PGI+5pS25Lu25Lq6OjwvYj5zcHJpbmdAaWV0Zi5vcmcgJmx0 O3NwcmluZ0BpZXRmLm9yZyZndDs8L2Rpdj48ZGl2PjxiPuaKhOmAgTo8L2I+amFtZXMubi5ndWlj aGFyZEBmdXR1cmV3ZWkuY29tICZsdDtqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20mZ3Q7 LCBzaGF5LnphZG9rNDBicm9hZGNvbS5jb21AZG1hcmMuaWV0Zi5vcmcgJmx0O3NoYXkuemFkb2s9 NDBicm9hZGNvbS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7LCBiZXJ0cmFuZEBkdXZpdmllci5jb20g Jmx0O2JlcnRyYW5kQGR1dml2aWVyLmNvbSZndDs8L2Rpdj48ZGl2PjxiPuS4u+mimDo8L2I+W3Nw cmluZ10gV0cgQWRvcHRpb24gY2FsbCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vPC9kaXY+ PC9kaXY+PGRpdj48YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiPjxtZXRhPjxtZXRhPjxz dHlsZT5wLm1zb25vcm1hbCwgbGkubXNvbm9ybWFsLCBkaXYubXNvbm9ybWFsIHttYXJnaW46IDAu MGNtO2ZvbnQtc2l6ZTogMTEuMHB0O2ZvbnQtZmFtaWx5OiBjYWxpYnJpICwgc2Fucy1zZXJpZjtt c28tZmFyZWFzdC1sYW5ndWFnZTogZW4tdXM7fWE6bGluaywgc3Bhbi5tc29oeXBlcmxpbmsge21z by1zdHlsZS1wcmlvcml0eTogOTk7Y29sb3I6ICMwNTYzYzE7dGV4dC1kZWNvcmF0aW9uOiB1bmRl cmxpbmU7fXNwYW4uZW1haWxzdHlsZTE3IHttc28tc3R5bGUtdHlwZTogcGVyc29uYWwtY29tcG9z ZTtmb250LWZhbWlseTogY2FsaWJyaSAsIHNhbnMtc2VyaWY7Y29sb3I6IHdpbmRvd3RleHQ7fXNw YW4udGV4dHJ1biB7bXNvLXN0eWxlLW5hbWU6IHRleHRydW47fXNwYW4uZW9wIHttc28tc3R5bGUt bmFtZTogZW9wO31wLnBhcmFncmFwaCwgbGkucGFyYWdyYXBoLCBkaXYucGFyYWdyYXBoIHttc28t c3R5bGUtbmFtZTogcGFyYWdyYXBoO21zby1tYXJnaW4tdG9wLWFsdDogYXV0bzttYXJnaW4tcmln aHQ6IDAuMGNtO21zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0bzttYXJnaW4tbGVmdDogMC4wY207 Zm9udC1zaXplOiAxMS4wcHQ7Zm9udC1mYW1pbHk6IGNhbGlicmkgLCBzYW5zLXNlcmlmO31zcGFu LnNjeHczMzI5NzU5MCB7bXNvLXN0eWxlLW5hbWU6IHNjeHczMzI5NzU5MDt9c3Bhbi5ub3JtYWx0 ZXh0cnVuIHttc28tc3R5bGUtbmFtZTogbm9ybWFsdGV4dHJ1bjt9c3Bhbi5hcHBsZS1jb252ZXJ0 ZWQtc3BhY2Uge21zby1zdHlsZS1uYW1lOiBhcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fS5tc29jaHBk ZWZhdWx0IHttc28tc3R5bGUtdHlwZTogZXhwb3J0LW9ubHk7Zm9udC1mYW1pbHk6IGNhbGlicmkg LCBzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOiBlbi11czt9ZGl2LndvcmRzZWN0aW9u MSB7cGFnZTogd29yZHNlY3Rpb24xO31vbCB7bWFyZ2luLWJvdHRvbTogMC4wY207fXVsIHttYXJn aW4tYm90dG9tOiAwLjBjbTt9PC9zdHlsZT48ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJ0ZXh0cnVuIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMC4wcHQ7Ij5EZWFyIFdvcmtpbmcgR3JvdXAsJm5ic3A7PC9zcGFuPjwvc3Bhbj48c3Bh biBjbGFzcz0iZW9wIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC4wcHQ7Ij4mbmJzcDs8L3Nw YW4+PC9zcGFuPjwvcD48cCBjbGFzcz0icGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luOiAwLjBjbTti YWNrZ3JvdW5kOiB3aGl0ZTt2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7LXdlYmtpdC11c2VyLWRy YWc6IG5vbmU7b3ZlcmZsb3ctd3JhcDogYnJlYWstd29yZDstd2Via2l0LWZvbnQta2VybmluZzog bm9uZTtjb2xvcjogOyI+PHNwYW4gY2xhc3M9ImVvcCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTAuMHB0O2NvbG9yOiBibGFjazsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IHNlZ29lIHVpICwgc2Fucy1zZXJpZjtjb2xvcjog YmxhY2s7Ij48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5k OiB3aGl0ZTt2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7Ij48c3BhbiBjbGFzcz0ic2N4dzMzMjk3 NTkwIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC4wcHQ7Y29sb3I6IGJsYWNrOyI+SSB3b3Vs ZCBsaWtlIHRvIGNvbmZpcm0gdGhhdCBDaXNjbyBwYXJ0aWNpcGF0ZWQgdG8gdGhlJm5ic3A7PC9z cGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0ibm9ybWFsdGV4dHJ1biI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTAuMHB0O2NvbG9yOiBibGFjazsiPmludGVyb3BzPC9zcGFuPjwvc3Bhbj48c3BhbiBj bGFzcz0ic2N4dzMzMjk3NTkwIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC4wcHQ7Y29sb3I6 IGJsYWNrOyI+Jm5ic3A7bWVudGlvbmVkIGJ5Jm5ic3A7U2hheS4mbmJzcDtUaGV5IHdlcmUgYWxs 4oCvc3VjY2Vzc2Z1bCBhbmQgbGVkJm5ic3A7dG8mbmJzcDtkZXBsb3ltZW50cy48L3NwYW4+PC9z cGFuPjxzcGFuIGNsYXNzPSJlb3AiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjBwdDtjb2xv cjogYmxhY2s7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDku MHB0O2ZvbnQtZmFtaWx5OiBzZWdvZSB1aSAsIHNhbnMtc2VyaWY7Y29sb3I6IGJsYWNrOyI+PC9z cGFuPjwvcD48cCBjbGFzcz0icGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luOiAwLjBjbTtiYWNrZ3Jv dW5kOiB3aGl0ZTt2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7LXdlYmtpdC11c2VyLWRyYWc6IG5v bmU7b3ZlcmZsb3ctd3JhcDogYnJlYWstd29yZDstd2Via2l0LWZvbnQta2VybmluZzogbm9uZTtj b2xvcjogOyI+PHNwYW4gY2xhc3M9ImVvcCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0 O2NvbG9yOiBibGFjazsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IHNlZ29lIHVpICwgc2Fucy1zZXJpZjtjb2xvcjogYmxhY2s7 Ij48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJiYWNrZ3JvdW5kOiB3aGl0 ZTt2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7Ij48c3BhbiBjbGFzcz0idGV4dHJ1biI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0O2NvbG9yOiBibGFjazsiPkkgd291bGQmbmJzcDs8L3Nw YW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJzY3h3MzMyOTc1OTAiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEwLjBwdDtjb2xvcjogYmxhY2s7Ij5saWtlIHRvJm5ic3A7cmVtaW5kIHRoYXQgQ2lzY28g aGFzIGJlZW4gc2hpcHBpbmcgcHJvZHVjdHMmbmJzcDtzdXBwb3J0aW5nIHRoaXMgZHJhZnQgZm9y Jm5ic3A7fjEwJm5ic3A7bW9udGhzLCBhY3Jvc3MmbmJzcDtvdXImbmJzcDtoYXJkd2FyZSZuYnNw O3Byb2R1Y3QgbGluZTrigK88L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJlb3AiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwLjBwdDtjb2xvcjogYmxhY2s7Ij4mbmJzcDs8L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDkuMHB0O2ZvbnQtZmFtaWx5OiBzZWdvZSB1aSAsIHNh bnMtc2VyaWY7Y29sb3I6IGJsYWNrOyI+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6IDU0LjBwdDt0ZXh0LWluZGVudDogLTE4LjBwdDttc28tbGlzdDog bDEgbGV2ZWwxIGxmbzE7YmFja2dyb3VuZDogd2hpdGU7dmVydGljYWwtYWxpZ246IGJhc2VsaW5l OyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0O2ZvbnQtZmFtaWx5OiBzeW1ib2w7Y29s b3I6IGJsYWNrOyI+PHNwYW4gc3R5bGU9Im1zby1saXN0OiBpZ25vcmU7Ij7CtzxzcGFuIHN0eWxl PSJmb250OiA3LjBwdCB0aW1lcyBuZXcgcm9tYW47Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0i dGV4dHJ1biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0O2NvbG9yOiBibGFjazsiPk5D UyA1NTAwPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0iZW9wIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMC4wcHQ7Y29sb3I6IGJsYWNrOyI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMC4wcHQ7Y29sb3I6IGJsYWNrOyI+PC9zcGFuPjwvcD48cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6IDU0LjBwdDt0ZXh0LWluZGVudDogLTE4LjBw dDttc28tbGlzdDogbDEgbGV2ZWwxIGxmbzE7YmFja2dyb3VuZDogd2hpdGU7dmVydGljYWwtYWxp Z246IGJhc2VsaW5lOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0O2ZvbnQtZmFtaWx5 OiBzeW1ib2w7Y29sb3I6IGJsYWNrOyI+PHNwYW4gc3R5bGU9Im1zby1saXN0OiBpZ25vcmU7Ij7C tzxzcGFuIHN0eWxlPSJmb250OiA3LjBwdCB0aW1lcyBuZXcgcm9tYW47Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L3NwYW4+PC9zcGFuPjwvc3Bhbj48 c3BhbiBjbGFzcz0idGV4dHJ1biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0O2NvbG9y OiBibGFjazsiPk5DUyA1NjA8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJlb3AiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwLjBwdDtjb2xvcjogYmxhY2s7Ij4mbmJzcDs8L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjBwdDtjb2xvcjogYmxhY2s7Ij48L3NwYW4+PC9w PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDogNTQuMHB0O3RleHQtaW5k ZW50OiAtMTguMHB0O21zby1saXN0OiBsMSBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOiB3aGl0ZTt2 ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC4wcHQ7 Zm9udC1mYW1pbHk6IHN5bWJvbDtjb2xvcjogYmxhY2s7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 IGlnbm9yZTsiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6IDcuMHB0IHRpbWVzIG5ldyByb21hbjsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48L3Nw YW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJ0ZXh0cnVuIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MC4wcHQ7Y29sb3I6IGJsYWNrOyI+TkNTIDU0MDwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImVv cCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0O2NvbG9yOiBibGFjazsiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0O2NvbG9yOiBibGFjazsi Pjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OiA1NC4w cHQ7dGV4dC1pbmRlbnQ6IC0xOC4wcHQ7bXNvLWxpc3Q6IGwxIGxldmVsMSBsZm8xO2JhY2tncm91 bmQ6IHdoaXRlO3ZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEwLjBwdDtmb250LWZhbWlseTogc3ltYm9sO2NvbG9yOiBibGFjazsiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDogaWdub3JlOyI+wrc8c3BhbiBzdHlsZT0iZm9udDogNy4wcHQgdGltZXMgbmV3 IHJvbWFuOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9InRleHRydW4iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwLjBwdDtjb2xvcjogYmxhY2s7Ij5OQ1MgNTQwLUw8L3NwYW4+PC9zcGFuPjxz cGFuIGNsYXNzPSJlb3AiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjBwdDtjb2xvcjogYmxh Y2s7Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjBwdDtj b2xvcjogYmxhY2s7Ij48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDogNTQuMHB0O3RleHQtaW5kZW50OiAtMTguMHB0O21zby1saXN0OiBsMSBsZXZlbDEg bGZvMTtiYWNrZ3JvdW5kOiB3aGl0ZTt2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMC4wcHQ7Zm9udC1mYW1pbHk6IHN5bWJvbDtjb2xvcjogYmxhY2s7 Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6IGlnbm9yZTsiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6IDcu MHB0IHRpbWVzIG5ldyByb21hbjsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOzwvc3Bhbj48L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJzY3h3MzMyOTc1 OTAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjBwdDtjb2xvcjogYmxhY2s7Ij5BU1IgOTAw MCZuYnNwOyhUb21haGF3ayk8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJlb3AiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEwLjBwdDtjb2xvcjogYmxhY2s7Ij4mbmJzcDs8L3NwYW4+PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjBwdDtjb2xvcjogYmxhY2s7Ij48L3NwYW4+PC9w PjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDogNTQuMHB0O3RleHQtaW5k ZW50OiAtMTguMHB0O21zby1saXN0OiBsMSBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOiB3aGl0ZTt2 ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC4wcHQ7 Zm9udC1mYW1pbHk6IHN5bWJvbDtjb2xvcjogYmxhY2s7Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6 IGlnbm9yZTsiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6IDcuMHB0IHRpbWVzIG5ldyByb21hbjsiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48L3Nw YW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJzY3h3MzMyOTc1OTAiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEwLjBwdDtjb2xvcjogYmxhY2s7Ij5BU1IgOTAwMCZuYnNwOyhMaWdodFNwZWVkKTwvc3Bh bj48L3NwYW4+PHNwYW4gY2xhc3M9ImVvcCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0 O2NvbG9yOiBibGFjazsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTAuMHB0O2NvbG9yOiBibGFjazsiPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OiA1NC4wcHQ7dGV4dC1pbmRlbnQ6IC0xOC4wcHQ7bXNvLWxpc3Q6 IGwxIGxldmVsMSBsZm8xO2JhY2tncm91bmQ6IHdoaXRlO3ZlcnRpY2FsLWFsaWduOiBiYXNlbGlu ZTsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjBwdDtmb250LWZhbWlseTogc3ltYm9sO2Nv bG9yOiBibGFjazsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDogaWdub3JlOyI+wrc8c3BhbiBzdHls ZT0iZm9udDogNy4wcHQgdGltZXMgbmV3IHJvbWFuOyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9 InNjeHczMzI5NzU5MCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0O2NvbG9yOiBibGFj azsiPk5DUyA1NzAwIChOZWFyIEZDUyk8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJlb3AiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjBwdDtjb2xvcjogYmxhY2s7Ij4mbmJzcDs8L3NwYW4+ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjBwdDtjb2xvcjogYmxhY2s7Ij48L3Nw YW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDogNTQuMHB0O3Rl eHQtaW5kZW50OiAtMTguMHB0O21zby1saXN0OiBsMSBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOiB3 aGl0ZTt2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MC4wcHQ7Zm9udC1mYW1pbHk6IHN5bWJvbDtjb2xvcjogYmxhY2s7Ij48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6IGlnbm9yZTsiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6IDcuMHB0IHRpbWVzIG5ldyByb21h bjsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bh bj48L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJzY3h3MzMyOTc1OTAiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwLjBwdDtjb2xvcjogYmxhY2s7Ij5TaWxpY29uIE9uZSAtJm5ic3A7ODAwMCZu YnNwOyhOZWFyIEZDUykmbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJlb3AiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDEwLjBwdDtjb2xvcjogYmxhY2s7Ij4mbmJzcDs8L3NwYW4+PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjBwdDtjb2xvcjogYmxhY2s7Ij48L3NwYW4+ PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDogNTQuMHB0O3RleHQt aW5kZW50OiAtMTguMHB0O21zby1saXN0OiBsMSBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOiB3aGl0 ZTt2ZXJ0aWNhbC1hbGlnbjogYmFzZWxpbmU7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMC4w cHQ7Zm9udC1mYW1pbHk6IHN5bWJvbDtjb2xvcjogYmxhY2s7Ij48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6IGlnbm9yZTsiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6IDcuMHB0IHRpbWVzIG5ldyByb21hbjsi PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48 L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJ0ZXh0cnVuIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMC4wcHQ7Y29sb3I6IGJsYWNrOyI+WFI5MDAwICh2aXJ0dWFsKSZuYnNwOzwvc3Bhbj48L3Nw YW4+PHNwYW4gY2xhc3M9ImVvcCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0O2NvbG9y OiBibGFjazsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAu MHB0O2NvbG9yOiBibGFjazsiPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OiA1NC4wcHQ7YmFja2dyb3VuZDogd2hpdGU7dmVydGljYWwtYWxpZ246IGJh c2VsaW5lOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0O2NvbG9yOiBibGFjazsiPjxi cj48YnI+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iYmFja2dyb3VuZDog d2hpdGU7dmVydGljYWwtYWxpZ246IGJhc2VsaW5lOyI+PHNwYW4gY2xhc3M9InNjeHczMzI5NzU5 MCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0O2NvbG9yOiBibGFjazsiPkkmbmJzcDt3 b3VsZCZuYnNwO2Fsc28mbmJzcDtsaWtlIHRvJm5ic3A7cmVtaW5kIHRoYXQgQ2lzY28gYW5kIFJh a3V0ZW4gaGF2ZSBwdWJsaWNseSZuYnNwO2NvbW11bmljYXRlZCZuYnNwO29uJm5ic3A7dGhlIGNv bW1lcmNpYWwmbmJzcDtkZXBsb3ltZW50IG9mIHRoZSB0ZWNobm9sb2d5Jm5ic3A7c3BlY2lmaWVk Jm5ic3A7aW4gdGhpcyBkcmFmdC4mbmJzcDtGdXJ0aGVybW9yZSwgdGhlJm5ic3A7dGVjaG5vbG9n eSZuYnNwO2lzIGFsc28gZGVwbG95ZWQgaW4gcHJvZHVjdGlvbiB3aXRoIGxpdmUgdHJhZmZpYyBp biZuYnNwO0JlbGwgQ2FuYWRh4oCZcyZuYnNwO25ldHdvcmsmbmJzcDtpbiBhIG11bHRpdmVuZG9y IGVudmlyb25tZW50LiZuYnNwO1RoZXJlIGFyZSBhZGRpdGlvbmFsIHVuZGlzY2xvc2VkIGRlcGxv eW1lbnRzLiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImVvcCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogMTAuMHB0O2NvbG9yOiBibGFjazsiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IHNlZ29lIHVpICwgc2Fucy1z ZXJpZjtjb2xvcjogYmxhY2s7Ij48L3NwYW4+PC9wPjxwIGNsYXNzPSJwYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW46IDAuMGNtO2JhY2tncm91bmQ6IHdoaXRlO3ZlcnRpY2FsLWFsaWduOiBiYXNlbGlu ZTstd2Via2l0LXVzZXItZHJhZzogbm9uZTtvdmVyZmxvdy13cmFwOiBicmVhay13b3JkOy13ZWJr aXQtZm9udC1rZXJuaW5nOiBub25lO2NvbG9yOiA7Ij48c3BhbiBjbGFzcz0iZW9wIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMC4wcHQ7Y29sb3I6IGJsYWNrOyI+Jm5ic3A7PC9zcGFuPjwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5LjBwdDtmb250LWZhbWlseTogc2Vnb2UgdWkgLCBz YW5zLXNlcmlmO2NvbG9yOiBibGFjazsiPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImJhY2tncm91bmQ6IHdoaXRlO3ZlcnRpY2FsLWFsaWduOiBiYXNlbGluZTsiPjxzcGFu IGNsYXNzPSJzY3h3MzMyOTc1OTAiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwLjBwdDtjb2xv cjogYmxhY2s7Ij5JJm5ic3A7c3Ryb25nbHkmbmJzcDtzdXBwb3J0Jm5ic3A7dGhlJm5ic3A7YWRv cHRpb24mbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtkcmFmdDwvc3Bhbj48L3NwYW4+PHNwYW4gY2xh c3M9ImVvcCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuMHB0O2NvbG9yOiBibGFjazsiPiZu YnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1p bHk6IHNlZ29lIHVpICwgc2Fucy1zZXJpZjtjb2xvcjogYmxhY2s7Ij48L3NwYW4+PC9wPjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDkuMHB0O2ZvbnQtZmFtaWx5 OiBoZWx2ZXRpY2E7Y29sb3I6IGJsYWNrOyI+PGJyPjxicj48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IGhlbHZldGljYTtjb2xvcjogYmxhY2s7Ij48L3Nw YW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDkuMHB0 O2ZvbnQtZmFtaWx5OiBoZWx2ZXRpY2E7Y29sb3I6IGJsYWNrOyI+T24gMTQgT2N0IDIwMjEsIGF0 IDEwOjQ4LCBTaGF5IFphZG9rICZsdDs8YSBocmVmPSJtYWlsdG86c2hheS56YWRvaz00MGJyb2Fk Y29tLmNvbUBkbWFyYy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNoYXkuemFkb2s9NDBicm9h ZGNvbS5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PC9wPjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDkuMHB0O2ZvbnQtZmFtaWx5OiBo ZWx2ZXRpY2E7Y29sb3I6IGJsYWNrOyI+Jm5ic3A7PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5LjBwdDtmb250LWZhbWlseTogaGVsdmV0aWNh O2NvbG9yOiBibGFjazsiPkRlYXIgV0csPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPjxicj48YnI+V2Ugd291bGQgbGlrZSB0byB1cGRhdGUgb24gdGhlIHBy b2R1Y3Rpb24gc3VwcG9ydCBieSB0aGUgU3RyYXRhRE5YIHByb2R1Y3RzJm5ic3A7b2YgYm90aCBm bGF2b3JzIFJFUExBQ0UgYW5kIE5FWFQgYXMgZGVmaW5lZCBpbiBDU0lEIGRyYWZ0LCBhcyB3ZWxs IGFzIG5vbi1jb21wcmVzc2VkICJDbGFzc2ljIiBTUnY2LiZuYnNwOzwvc3Bhbj48L3A+PHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6 IGhlbHZldGljYTtjb2xvcjogYmxhY2s7Ij5TdHJhdGFETlgmbmJzcDtwcm9kdWN0cyBpbmNsdWRl OiBKZXJpY2hvMi9KZXJpY2hvMmMvUXVtcmFuMmMvUXVtcmFuMmEvUXVtcmFuMnUvUXVtcmFuMm4v SmVyaWNobzJjKyBhbmQgYW55IGZ1dHVyZSBkZXZpY2U8L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDkuMHB0O2ZvbnQtZmFtaWx5OiBoZWx2ZXRp Y2E7Y29sb3I6IGJsYWNrOyI+PGJyPlRoaXMgc3VwcG9ydCBrZWVwczo8YnI+MS4gU2luZ2xlIGFu ZCB1bmlmaWVkIGRhdGEtcGxhbmUgdUNvZGUsIHByb2dyYW1tZWQgdXNpbmcgaGlnaCBsZXZlbCBs YW5ndWFnZTxicj4yLiBTaW5nbGUgZGF0YS1wbGFuZSBBUEk8YnI+My4gQ29uY3VycmVudC9TaW11 bHRhbmVvdXMgc3VwcG9ydCBvZiBhbGwgdGhyZWUgdGVjaG5pcXVlcyBiYXNlZCBvbiBhIHBlci1w YWNrZXQgYmVoYXZpb3I8YnI+NC4gQ29uY3VycmVudC9TaW11bHRhbmVvdXMgc3VwcG9ydCBvZiBh bGwgdGhyZWUgdGVjaG5pcXVlcyBpbnNpZGUgb2YgdGhlIHNhbWUgU1J2NiBIZWFkZXI8L3NwYW4+ PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDkuMHB0O2Zv bnQtZmFtaWx5OiBoZWx2ZXRpY2E7Y29sb3I6IGJsYWNrOyI+NS4gSW4gYWxsIHRocmVlIHRlY2hu aXF1ZXMgdGhlIGZvbGxvd2luZyBpcyBhbHJlYWR5PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5LjBw dDtmb250LWZhbWlseTogaGVsdmV0aWNhO2NvbG9yOiBibHVlOyI+c3VwcG9ydGVkJm5ic3A7Y29u Y3VycmVudGx5L3NpbXVsdGFuZW91c2x5IGFuZCBpbiBwcm9kdWN0aW9uPC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDkuMHB0O2ZvbnQtZmFtaWx5OiBoZWx2ZXRpY2E7Y29sb3I6IGJsYWNr OyI+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiA5LjBwdDtmb250LWZhbWlseTogaGVsdmV0aWNhO2NvbG9yOiBibGFjazsiPiZuYnNwOyAmbmJz cDsgMS4gU1J2NiBtYWluIGJlaGF2aW9ycyAtIGNvbXBsaWFudCB3aXRoPHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPnJmYzg5ODY8L2I+PGJyPiZuYnNw OyAmbmJzcDsgMi4gU1J2NiBpbnNlcnQgYmVoYXZpb3JzIC0gY29tcGxpYW50IHdpdGg8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGI+ZHJhZnQtc3J2Ni1u ZXQtcGdtLWluc2VydGlvbjwvYj48YnI+Jm5ic3A7ICZuYnNwOyAzLiBTUnY2IG1pZHBvaW50IHBy b3RlY3Rpb24gYmVoYXZpb3JzIC0gY29tcGxpYW50IHdpdGg8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGI+ZHJhZnQtbWlkcG9pbnQtcHJvdGVjdGlvbjwv Yj48YnI+PGJyPkFsbCBvZiB0aGUgYWJvdmUgaXMgaW4gcHJvZHVjdGlvbiBkZXBsb3ltZW50IGlu IHZhcmlvdXMgcHVibGlzaGVkIGFuZCB1bnB1Ymxpc2hlZCBuZXR3b3JrcyBhcm91bmQgdGhlIGds b2JlLjxicj5PdXIgcHJvZHVjdHMgYXJlIHVzZWQgYnkgaW5kdXN0cnkgbGVhZGluZyBPRU0gKHNv bWUgb2YgdGhlbSBwdWJsaXNoZWQgdGhleSBhcmUgdXNpbmcgdGhlIFN0cmF0YUROWCBwcm9kdWN0 cykgYW5kICJwdXJlIiBOT1MgdmVuZG9ycy48YnI+PGJyPkJSQ00gdXNpbmcgSmVyaWNobzIgcGFy dGljaXBhdGVkIGluIGNvdXBsZSBvZiBpbnRlcm9wcyB0aGF0IGluY2x1ZGVkIHNvbWUgbWl4IG9m IFJFUExBQ0UtQ1NJRCwgTkVYVC1DU0lEIGFuZCBub24tY29tcHJlc3NlZCAiQ2xhc3NpYyIgU1J2 NiAtIGFuZCBhbGwgaW50ZXJvcHMgaGF2ZSBlbmRlZCBzdWNjZXNzZnVsbHk8L3NwYW4+PC9wPjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDkuMHB0O2ZvbnQtZmFt aWx5OiBoZWx2ZXRpY2E7Y29sb3I6IGJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOiB6aC1jbjsi Pjxicj5UaGFua3MgJmFtcDsgUmVnYXJkcyw8YnI+U2hheTwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6IGF1dG87Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5LjBwdDtmb250LWZhbWlseTog aGVsdmV0aWNhO2NvbG9yOiBibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTogemgtY247Ij4mbmJz cDs8L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6IGF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvOyI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTAuNXB0O2NvbG9yOiAjMWY0OTdkO21zby1mYXJlYXN0LWxhbmd1YWdlOiB6aC1jbjsi PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5LjBwdDtmb250LWZhbWlseTog aGVsdmV0aWNhO2NvbG9yOiBibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTogemgtY247Ij48L3Nw YW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6IGF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvOyI+PGEgbmFtZT0ibV82NzQzMzAxMDM1NTM5 MDc0NTEzX21fLTY5MDQ3MjA3NTcxNDIwMCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTAuNXB0 O2ZvbnQtZmFtaWx5OiBoZWx2ZXRpY2E7Y29sb3I6ICMxZjQ5N2Q7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6IHpoLWNuOyI+Jm5ic3A7PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOiBt XzY3NDMzMDEwMzU1MzkwNzQ1MTNfbV8tNjkwNDcyMDc1NzE0MjAwOyI+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDkuMHB0O2ZvbnQtZmFtaWx5OiBoZWx2ZXRpY2E7Y29sb3I6IGJsYWNr O21zby1mYXJlYXN0LWxhbmd1YWdlOiB6aC1jbjsiPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6IGF1dG87Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5LjBwdDtmb250LWZhbWlseTog bWljcm9zb2Z0IHlhaGVpICwgc2Fucy1zZXJpZjtjb2xvcjogYmxhY2s7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6IHpoLWNuOyI+5Y+R5Lu25Lq6PC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiA5LjBwdDtmb250LWZhbWlseTogbWljcm9zb2Z0IHlhaGVpICwgc2Fucy1zZXJpZjtjb2xv cjogYmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IHpoLWNuOyI+Ojwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IG1pY3Jvc29mdCB5YWhlaSAsIHNh bnMtc2VyaWY7Y29sb3I6IGJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOiB6aC1jbjsiPiZuYnNw O3NwcmluZyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnNwcmluZy1ib3VuY2VzQGlldGYub3JnPC9hPl0mbmJzcDs8L3NwYW4+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IG1pY3Jvc29mdCB5 YWhlaSAsIHNhbnMtc2VyaWY7Y29sb3I6IGJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOiB6aC1j bjsiPuS7o+ihqDwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9u dC1mYW1pbHk6IG1pY3Jvc29mdCB5YWhlaSAsIHNhbnMtc2VyaWY7Y29sb3I6IGJsYWNrO21zby1m YXJlYXN0LWxhbmd1YWdlOiB6aC1jbjsiPiZuYnNwOzwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IG1pY3Jvc29mdCB5YWhlaSAsIHNhbnMtc2VyaWY7 Y29sb3I6IGJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOiB6aC1jbjsiPkphbWVzIEd1aWNoYXJk PGJyPjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5LjBwdDtmb250LWZhbWlseTog bWljcm9zb2Z0IHlhaGVpICwgc2Fucy1zZXJpZjtjb2xvcjogYmxhY2s7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6IHpoLWNuOyI+5Y+R6YCB5pe26Ze0PC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiA5LjBwdDtmb250LWZhbWlseTogbWljcm9zb2Z0IHlhaGVpICwgc2Fucy1zZXJpZjtj b2xvcjogYmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IHpoLWNuOyI+Ojwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IG1pY3Jvc29mdCB5YWhlaSAs IHNhbnMtc2VyaWY7Y29sb3I6IGJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOiB6aC1jbjsiPiZu YnNwOzIwMjE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6 IG1pY3Jvc29mdCB5YWhlaSAsIHNhbnMtc2VyaWY7Y29sb3I6IGJsYWNrO21zby1mYXJlYXN0LWxh bmd1YWdlOiB6aC1jbjsiPuW5tDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5LjBwdDtm b250LWZhbWlseTogbWljcm9zb2Z0IHlhaGVpICwgc2Fucy1zZXJpZjtjb2xvcjogYmxhY2s7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6IHpoLWNuOyI+MTA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IG1pY3Jvc29mdCB5YWhlaSAsIHNhbnMtc2VyaWY7Y29sb3I6 IGJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOiB6aC1jbjsiPuaciDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiA5LjBwdDtmb250LWZhbWlseTogbWljcm9zb2Z0IHlhaGVpICwgc2Fucy1z ZXJpZjtjb2xvcjogYmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IHpoLWNuOyI+MTwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5LjBwdDtmb250LWZhbWlseTogbWljcm9zb2Z0IHlhaGVp ICwgc2Fucy1zZXJpZjtjb2xvcjogYmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IHpoLWNuOyI+ 5pelPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDkuMHB0O2ZvbnQtZmFtaWx5OiBtaWNy b3NvZnQgeWFoZWkgLCBzYW5zLXNlcmlmO2NvbG9yOiBibGFjazttc28tZmFyZWFzdC1sYW5ndWFn ZTogemgtY247Ij4mbmJzcDsyMjowNTxicj48L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IG1pY3Jvc29mdCB5YWhlaSAsIHNhbnMtc2VyaWY7Y29sb3I6 IGJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOiB6aC1jbjsiPuaUtuS7tuS6ujwvc3Bhbj48L2I+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IG1pY3Jvc29mdCB5 YWhlaSAsIHNhbnMtc2VyaWY7Y29sb3I6IGJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOiB6aC1j bjsiPjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDkuMHB0O2ZvbnQtZmFtaWx5 OiBtaWNyb3NvZnQgeWFoZWkgLCBzYW5zLXNlcmlmO2NvbG9yOiBibGFjazttc28tZmFyZWFzdC1s YW5ndWFnZTogemgtY247Ij4mbmJzcDtTUFJJTkcgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJp bmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj48 L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IG1pY3Jv c29mdCB5YWhlaSAsIHNhbnMtc2VyaWY7Y29sb3I6IGJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdl OiB6aC1jbjsiPuaKhOmAgTwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOS4w cHQ7Zm9udC1mYW1pbHk6IG1pY3Jvc29mdCB5YWhlaSAsIHNhbnMtc2VyaWY7Y29sb3I6IGJsYWNr O21zby1mYXJlYXN0LWxhbmd1YWdlOiB6aC1jbjsiPjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDkuMHB0O2ZvbnQtZmFtaWx5OiBtaWNyb3NvZnQgeWFoZWkgLCBzYW5zLXNlcmlm O2NvbG9yOiBibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTogemgtY247Ij4mbmJzcDs8YSBocmVm PSJtYWlsdG86c3ByaW5nLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZy1j aGFpcnNAaWV0Zi5vcmc8L2E+PGJyPjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5 LjBwdDtmb250LWZhbWlseTogbWljcm9zb2Z0IHlhaGVpICwgc2Fucy1zZXJpZjtjb2xvcjogYmxh Y2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IHpoLWNuOyI+5Li76aKYPC9zcGFuPjwvYj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiA5LjBwdDtmb250LWZhbWlseTogbWljcm9zb2Z0IHlhaGVpICwg c2Fucy1zZXJpZjtjb2xvcjogYmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IHpoLWNuOyI+Ojwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IG1pY3Jv c29mdCB5YWhlaSAsIHNhbnMtc2VyaWY7Y29sb3I6IGJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdl OiB6aC1jbjsiPiZuYnNwO1tzcHJpbmddIFdHIEFkb3B0aW9uIGNhbGwgZm9yJm5ic3A7PGEgaHJl Zj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1z cHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgt Y29tcHJlc3Npb24vPC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5LjBwdDtmb250 LWZhbWlseTogaGVsdmV0aWNhO2NvbG9yOiBibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTogemgt Y247Ij48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6IGF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvOyI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IGhlbHZldGljYTtjb2xvcjogYmxhY2s7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6IHpoLWNuOyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDkuMHB0O2ZvbnQtZmFtaWx5OiBoZWx2ZXRpY2E7Y29sb3I6IGJsYWNrO21zby1mYXJlYXN0 LWxhbmd1YWdlOiB6aC1jbjsiPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG87Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5LjBwdDtmb250LWZhbWlseTogaGVsdmV0aWNhO2NvbG9y OiBibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTogemgtY247Ij5EZWFyIFdHOjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiA5LjBwdDtmb250LWZhbWlseTogaGVsdmV0aWNhO2NvbG9yOiBi bGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTogemgtY247Ij48L3NwYW4+PC9wPjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6IGF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OiBhdXRvOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6 IGhlbHZldGljYTtjb2xvcjogYmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IHpoLWNuOyI+Jm5i c3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDkuMHB0O2ZvbnQtZmFtaWx5OiBoZWx2 ZXRpY2E7Y29sb3I6IGJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOiB6aC1jbjsiPjwvc3Bhbj48 L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDogYXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG87Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5LjBw dDtmb250LWZhbWlseTogaGVsdmV0aWNhO2NvbG9yOiBibGFjazttc28tZmFyZWFzdC1sYW5ndWFn ZTogemgtY247Ij5UaGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gZXhwcmVzcyB0aGVpciBhcHByZWNp YXRpb24gZm9yIGFsbCB0aGUgcmVzcG9uc2VzIHJlY2VpdmVkIHRvIG91ciBlbWFpbHMgd2l0aCBy ZWZlcmVuY2UgdG8gaG93IHRoZSB3b3JraW5nIGdyb3VwIHdpc2hlcyB0byBtb3ZlIGZvcndhcmQg d2l0aCByZXNwZWN0IHRvIGEgc29sdXRpb24gZm9yIFNSdjYgY29tcHJlc3Npb24uPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDkuMHB0O2ZvbnQtZmFtaWx5OiBoZWx2ZXRpY2E7Y29sb3I6 IGJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOiB6aC1jbjsiPjwvc3Bhbj48L3A+PHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6IGF1dG87Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5LjBwdDtmb250LWZhbWls eTogaGVsdmV0aWNhO2NvbG9yOiBibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTogemgtY247Ij4m bmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IGhl bHZldGljYTtjb2xvcjogYmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IHpoLWNuOyI+PC9zcGFu PjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OiBhdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0bzsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDku MHB0O2ZvbnQtZmFtaWx5OiBoZWx2ZXRpY2E7Y29sb3I6IGJsYWNrO21zby1mYXJlYXN0LWxhbmd1 YWdlOiB6aC1jbjsiPlRoZSBhcHBhcmVudCBpbmNsaW5hdGlvbiBvZiB0aGUgd29ya2luZyBncm91 cCBpcyB0byB1c2UmbmJzcDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8iIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmls c2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi88L2E+Jm5ic3A7YXMgdGhlIGJhc2lz IGZvciBpdHMgY29tcHJlc3Npb24gc3RhbmRhcmRpemF0aW9uIHdvcmsuIFRoYXQgaXMgcGFydCBv ZiB3aGF0IHRoaXMgZW1haWwgYXR0ZW1wdHMgdG8gY29uZmlybS48L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IGhlbHZldGljYTtjb2xvcjogYmxhY2s7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6IHpoLWNuOyI+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDog YXV0bzsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDkuMHB0O2ZvbnQtZmFtaWx5OiBoZWx2ZXRp Y2E7Y29sb3I6IGJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOiB6aC1jbjsiPiZuYnNwOzwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5LjBwdDtmb250LWZhbWlseTogaGVsdmV0aWNhO2Nv bG9yOiBibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTogemgtY247Ij48L3NwYW4+PC9wPjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6IGF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OiBhdXRvOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1m YW1pbHk6IGhlbHZldGljYTtjb2xvcjogYmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IHpoLWNu OyI+QmVjYXVzZSBvZiB0aGUgYWJvdmUgdGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGlzc3VlIGEg Mi13ZWVrIFdHIGNhbGwgZm9yIGFkb3B0aW9uIGVuZGluZyBPY3RvYmVyIDE1PHN1cD50aDwvc3Vw PiZuYnNwO2ZvciZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyIgdGFyZ2V0 PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxz Y2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLzwvYT4mbmJzcDtidXQgd2l0aCBzb21l IGNsZWFyIGd1aWRlbGluZXMgYXMgZm9sbG93cy4gQnkgZXhwcmVzc2luZyBzdXBwb3J0IGZvciBh ZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IHlvdSBhcmUgZnVsbHkgYXdhcmUgb2YgYW5kIGFyZSBh Y2tub3dsZWRnaW5nIHRoYXQ6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDkuMHB0O2Zv bnQtZmFtaWx5OiBoZWx2ZXRpY2E7Y29sb3I6IGJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOiB6 aC1jbjsiPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDogYXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG87Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiA5LjBwdDtmb250LWZhbWlseTogaGVsdmV0aWNhO2NvbG9yOiBibGFjazttc28t ZmFyZWFzdC1sYW5ndWFnZTogemgtY247Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IGhlbHZldGljYTtjb2xvcjogYmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6IHpoLWNuOyI+PC9zcGFuPjwvcD48b2wgc3RhcnQ9IjEiPjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IGJsYWNrO21zby1tYXJnaW4tdG9wLWFsdDogYXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG87bXNvLWxpc3Q6IGwwIGxldmVsMSBsZm8yOyI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IGhlbHZldGljYTttc28tZmFy ZWFzdC1sYW5ndWFnZTogemgtY247Ij5UaGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAgaXMgYWRvcHRp bmcgYSBkb2N1bWVudCB0aGF0IGhhcyBtdWx0aXBsZSBTUnY2IEVuZHBvaW50IGJlaGF2aW9ycy48 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IGhlbHZldGlj YTttc28tZmFyZWFzdC1sYW5ndWFnZTogemgtY247Ij48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImNvbG9yOiBibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6IGF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvO21zby1saXN0OiBsMCBsZXZlbDEgbGZvMjsiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDkuMHB0O2ZvbnQtZmFtaWx5OiBoZWx2ZXRpY2E7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6IHpoLWNuOyI+VGhlIGRvY3VtZW50IGlzIGEmbmJzcDs8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IHpoLWNuOyI+4oCc PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDkuMHB0O2ZvbnQtZmFtaWx5OiBoZWx2ZXRp Y2E7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IHpoLWNuOyI+bGl2aW5nPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDkuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOiB6aC1jbjsiPuKAnTwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5LjBwdDtmb250LWZhbWlseTogaGVsdmV0aWNhO21z by1mYXJlYXN0LWxhbmd1YWdlOiB6aC1jbjsiPiZuYnNwO2RvY3VtZW50OyBpdCBtYXkgY2hhbmdl IGFzIGl0IGdvZXMgdGhyb3VnaCByZXZpZXcgYW5kIGFuYWx5c2lzIGJ5IHRoZSBTUFJJTkcgd29y a2luZyBncm91cC48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1p bHk6IGhlbHZldGljYTttc28tZmFyZWFzdC1sYW5ndWFnZTogemgtY247Ij48L3NwYW4+PC9saT48 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiBibGFjazttc28tbWFyZ2luLXRvcC1h bHQ6IGF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvO21zby1saXN0OiBsMCBsZXZlbDEg bGZvMjsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDkuMHB0O2ZvbnQtZmFtaWx5OiBoZWx2ZXRp Y2E7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IHpoLWNuOyI+QWxsIG9wZW4gZGlzY3Vzc2lvbiBwb2lu dHMgcmFpc2VkIG9uIG91ciBtYWlsaW5nIGxpc3QgTVVTVCBiZSBhZGRyZXNzZWQgQkVGT1JFIHNh aWQgZG9jdW1lbnQgaXMgYWxsb3dlZCB0byBwcm9ncmVzcyBmcm9tIHRoZSB3b3JraW5nIGdyb3Vw IHRvIHB1YmxpY2F0aW9uLiBBIGxpc3Qgb2YgdGhlc2UgZGlzY3Vzc2lvbiBwb2ludHMgd2lsbCBi ZSBkb2N1bWVudGVkIGluIHRoZSBXRyBkb2N1bWVudCBhbmQgbWFpbnRhaW5lZCBieSB0aGUgZG9j dW1lbnQgZWRpdG9yIGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIGNoYWlycy48L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IGhlbHZldGljYTttc28tZmFyZWFz dC1sYW5ndWFnZTogemgtY247Ij48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9ImNvbG9yOiBibGFjazttc28tbWFyZ2luLXRvcC1hbHQ6IGF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OiBhdXRvO21zby1saXN0OiBsMCBsZXZlbDEgbGZvMjsiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDkuMHB0O2ZvbnQtZmFtaWx5OiBoZWx2ZXRpY2E7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 IHpoLWNuOyI+SWYgdGhpcyBkb2N1bWVudCBpcyBhZG9wdGVkIGJ5IHRoZSB3b3JraW5nIGdyb3Vw LCB0aGUgY2hhaXJzIHNwZWNpZnkgYXMgcGFydCBvZiB0aGUgYWRvcHRpb24gY2FsbCB0aGF0IHRo ZSBmb2xsb3dpbmcgdGV4dCBkZXNjcmliaW5nIGFuIG9wZW4gaXNzdWUgYmUgYWRkZWQgdG8gdGhl IGRvY3VtZW50IGluIHRoZSBhYm92ZS1kZXNjcmliZWQgb3BlbiBpc3N1ZXMgc2VjdGlvbjo8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IGhlbHZldGljYTtt c28tZmFyZWFzdC1sYW5ndWFnZTogemgtY247Ij48L3NwYW4+PC9saT48L29sPjxvbCBzdGFydD0i NCI+PHVsPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IGJsYWNrO21zby1tYXJn aW4tdG9wLWFsdDogYXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6IGF1dG87bXNvLWxpc3Q6IGwy IGxldmVsMiBsZm8zOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6 IGhlbHZldGljYTttc28tZmFyZWFzdC1sYW5ndWFnZTogemgtY247Ij4iR2l2ZW4gdGhhdCB0aGUg d29ya2luZyBncm91cCBoYXMgc2FpZCB0aGF0IGl0IHdhbnRzIHRvIHN0YW5kYXJkaXplIG9uZSBk YXRhIHBsYW5lIHNvbHV0aW9uLCBhbmQgZ2l2ZW4gdGhhdCB0aGUgZG9jdW1lbnQgY29udGFpbnMg bXVsdGlwbGUgU1J2NiBFbmRQb2ludCBiZWhhdmlvcnMgdGhhdCBzb21lIFdHIG1lbWJlcnMgaGF2 ZSBzdGF0ZWQgYXJlIG11bHRpcGxlIGRhdGEgcGxhbmUgc29sdXRpb25zLCB0aGUgd29ya2luZyBn cm91cCB3aWxsIGFkZHJlc3Mgd2hldGhlciB0aGlzIGlzIHZhbGlkIGFuZCBjb2hlcmVudCB3aXRo IGl0cyBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiBvYmplY3RpdmUuIi48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IGhlbHZldGljYTttc28tZmFyZWFzdC1s YW5ndWFnZTogemgtY247Ij48L3NwYW4+PC9saT48L3VsPjwvb2w+PHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 IGF1dG87Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5LjBwdDtmb250LWZhbWlseTogaGVsdmV0 aWNhO2NvbG9yOiBibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTogemgtY247Ij4mbmJzcDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IGhlbHZldGljYTtj b2xvcjogYmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IHpoLWNuOyI+PC9zcGFuPjwvcD48cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDogYXV0bzsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDkuMHB0O2ZvbnQt ZmFtaWx5OiBoZWx2ZXRpY2E7Y29sb3I6IGJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOiB6aC1j bjsiPlBsZWFzZSBjb25zaWRlciB0aGUgYWJvdmUgZ3VpZGVsaW5lcyBhcyB5b3UgZGVjaWRlIG9u IHdoZXRoZXIgdG8gc3VwcG9ydCBvciBub3QgdGhpcyBXRyBhZG9wdGlvbi4gUGxlYXNlIGV4cHJl c3MgY2xlYXJseSB5b3VyIHJlYXNvbmluZyBmb3Igc3VwcG9ydC9ub24tc3VwcG9ydCBhcyB3ZWxs IGFzIGFueSBvcGVuIGRpc2N1c3Npb24gcG9pbnRzIHlvdSB3b3VsZCBsaWtlIGFkZHJlc3NlZCBz aG91bGQgdGhlIGRvY3VtZW50IGJlIGFkb3B0ZWQgaW50byB0aGUgd29ya2luZyBncm91cC48L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IGhlbHZldGljYTtj b2xvcjogYmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IHpoLWNuOyI+PC9zcGFuPjwvcD48cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OiBhdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDogYXV0bzsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDkuMHB0O2ZvbnQt ZmFtaWx5OiBoZWx2ZXRpY2E7Y29sb3I6IGJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOiB6aC1j bjsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5LjBwdDtmb250LWZhbWls eTogaGVsdmV0aWNhO2NvbG9yOiBibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTogemgtY247Ij48 L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 IGF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IGhlbHZldGljYTtjb2xvcjogYmxhY2s7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6IHpoLWNuOyI+VGhhbmtzITwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5 LjBwdDtmb250LWZhbWlseTogaGVsdmV0aWNhO2NvbG9yOiBibGFjazttc28tZmFyZWFzdC1sYW5n dWFnZTogemgtY247Ij48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6IGF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvOyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IGhlbHZldGljYTtjb2xvcjogYmxh Y2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IHpoLWNuOyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDkuMHB0O2ZvbnQtZmFtaWx5OiBoZWx2ZXRpY2E7Y29sb3I6IGJsYWNrO21z by1mYXJlYXN0LWxhbmd1YWdlOiB6aC1jbjsiPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 IGF1dG87Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5LjBwdDtmb250LWZhbWlseTogaGVsdmV0 aWNhO2NvbG9yOiBibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTogemgtY247Ij5KaW0sIEJydW5v ICZhbXA7IEpvZWw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1p bHk6IGhlbHZldGljYTtjb2xvcjogYmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IHpoLWNuOyI+ PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OiBhdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDogYXV0bzsiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDkuMHB0O2ZvbnQtZmFtaWx5OiBoZWx2ZXRpY2E7Y29sb3I6IGJsYWNrO21zby1mYXJlYXN0 LWxhbmd1YWdlOiB6aC1jbjsiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5 LjBwdDtmb250LWZhbWlseTogaGVsdmV0aWNhO2NvbG9yOiBibGFjazttc28tZmFyZWFzdC1sYW5n dWFnZTogemgtY247Ij48L3NwYW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6IGF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OiBhdXRvOyI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IGhlbHZldGljYTtjb2xvcjogYmxh Y2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6IHpoLWNuOyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6IDkuMHB0O2ZvbnQtZmFtaWx5OiBoZWx2ZXRpY2E7Y29sb3I6IGJsYWNrO21z by1mYXJlYXN0LWxhbmd1YWdlOiB6aC1jbjsiPjwvc3Bhbj48L3A+PHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDogYXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 IGF1dG87Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5LjBwdDtmb250LWZhbWlseTogaGVsdmV0 aWNhO2NvbG9yOiBibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTogemgtY247Ij4mbmJzcDs8L3Nw YW4+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDkuMHB0 O2ZvbnQtZmFtaWx5OiBoZWx2ZXRpY2E7Y29sb3I6IGJsYWNrOyI+PGJyPjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMC4wcHQ7Zm9udC1mYW1pbHk6IGhlbHZldGljYTtjb2xvcjogYmxh Y2s7YmFja2dyb3VuZDogd2hpdGU7Ij5UaGlzIGVsZWN0cm9uaWMgY29tbXVuaWNhdGlvbiBhbmQg dGhlIGluZm9ybWF0aW9uIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCwgb3IgYXR0 YWNoZWQgdG8gaXQsIGFyZSBjb25maWRlbnRpYWwgYW5kIGFyZSBpbnRlbmRlZCBzb2xlbHkgZm9y IHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gaXQgaXMgYWRkcmVz c2VkIGFuZCBtYXkgY29udGFpbiBpbmZvcm1hdGlvbiB0aGF0IGlzIGNvbmZpZGVudGlhbCwgbGVn YWxseSBwcml2aWxlZ2VkLCBwcm90ZWN0ZWQgYnkgcHJpdmFjeSBsYXdzLCBvciBvdGhlcndpc2Ug cmVzdHJpY3RlZCBmcm9tIGRpc2Nsb3N1cmUgdG8gYW55b25lIGVsc2UuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb3IgdGhlIHBlcnNvbiByZXNwb25zaWJsZSBmb3IgZGVs aXZlcmluZyB0aGUgZS1tYWlsIHRvIHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVy ZWJ5IG5vdGlmaWVkIHRoYXQgYW55IHVzZSwgY29weWluZywgZGlzdHJpYnV0aW5nLCBkaXNzZW1p bmF0aW9uLCBmb3J3YXJkaW5nLCBwcmludGluZywgb3IgY29weWluZyBvZiB0aGlzIGUtbWFpbCBp cyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5b3UgcmVjZWl2ZWQgdGhpcyBlLW1haWwgaW4gZXJy b3IsIHBsZWFzZSByZXR1cm4gdGhlIGUtbWFpbCB0byB0aGUgc2VuZGVyLCBkZWxldGUgaXQgZnJv bSB5b3VyIGNvbXB1dGVyLCBhbmQgZGVzdHJveSBhbnkgcHJpbnRlZCBjb3B5IG9mIGl0Ljwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiA5LjBwdDtmb250LWZhbWlseTogaGVsdmV0aWNhO2Nv bG9yOiBibGFjazsiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPnNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogOS4wcHQ7Zm9udC1mYW1pbHk6IGhlbHZldGljYTtjb2xvcjogYmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6IGVuLWdiOyI+PC9zcGFuPjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8L3A+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj4= ------=ALIBOUNDARY_98586_7f27f8a56700_616a8bef_104797-- From nobody Sat Oct 16 12:37:06 2021 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 640CE3A0A31; Sat, 16 Oct 2021 12:36:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 ttufGWZA9aaq; Sat, 16 Oct 2021 12:36:02 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3982F3A0A2C; Sat, 16 Oct 2021 12:36:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id D484D18276; Sat, 16 Oct 2021 15:36:24 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id SsiGvRt20AJX; Sat, 16 Oct 2021 15:36:24 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 5CE78180B8; Sat, 16 Oct 2021 15:36:24 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 4ADC2236; Sat, 16 Oct 2021 15:35:58 -0400 (EDT) From: Michael Richardson To: Mark Smith cc: mohamed.boucadair@orange.com, SPRING WG , 6man WG In-Reply-To: References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <1396_1634278622_61691CDE_1396_28_5_787AE7BB302AE849A7480A190F8B93303542C654@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Date: Sat, 16 Oct 2021 15:35:58 -0400 Message-ID: <1101.1634412958@localhost> Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 16 Oct 2021 19:36:06 -0000 Mark Smith wrote: > In fight changing DAs also will break AH protection of the IPv6 header. AH is dead. It's been dead for decades. I say this as an IPsec enthusiast who wishes this wasn't true. But it is. From nobody Sat Oct 16 14:20:50 2021 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 9A1473A0E96; Sat, 16 Oct 2021 14:19:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZB0blUzgxZ4t; Sat, 16 Oct 2021 14:19:40 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0: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 1CE463A0E81; Sat, 16 Oct 2021 14:19:39 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id s136so8831847pgs.4; Sat, 16 Oct 2021 14:19:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=OL7jgWNGoD5D5kRFu4AqHqyoJ76FQL6wpYFsXFcR4Xg=; b=GDv/L8yUEUvF55jUDpIWLXY6jrluPcG0YZ9Bfb1NdIDP9hP1xzKxjJpdckvGlnW7/L 0RHi8H68k1CtDnKLza2CPLXrh2Yl+4/b5H7v4iLTbqqbsSIF/MRagt4I1+yaaMuNDzXl 6iQhKMM4Ohrd2qRP+Bdner2o5og99i/lB0nnwFj28DblnA2B9riIwcPex7R0JEYbuaw4 YmSVdFf/OeVTzyQNX6zoHMSjQvbNwoxymo3VGI2XlATG0ulIXSWVUwCVAntzN8u5ogXp CAFoexbhZyUQs4t3Gqwzk4DJw2zQ2w6D+mXR94gYwVTqGcgOTID47Rn2siZrqUmC7Bpq DLPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=OL7jgWNGoD5D5kRFu4AqHqyoJ76FQL6wpYFsXFcR4Xg=; b=mx6A3RTdS8zAA3ocUWzfgKWIgSKCEPbKX8DT5duCS1qgtEcNsix+9vyZjCuI3nVUFy YyQcXg5HoISM1hCckucf8uPzv7yyv8WJZ11yHfUauxbIXrbt8NKLDKozQAcaCrl64ZDB +WwoKrWqosfoGayHI/KF5ZOs+YLea70nweqvVtgW7MSAec1Mi8p2Z5oqYMMIRyJI5bbk Dt1gg69iVWohemhaaKN6SFFOQudessY7M+8ZcHwZKQ3nkpjuRIGaQtAFRKKIHC5MU0n6 GRWdl3mDLkE6/Yr1cApIF8TyvDq0GAKOQ/cKlmBLKC4EAVQmb9wJRQG7njEd73VGYVBr 7EtQ== X-Gm-Message-State: AOAM531NONgdVqvo3RcX8G+VdB2ok0sC44nWa952v0bAuwwyyIVlweQS rr5l5/dK+GSBovEVZwTGaN+ji9Pk4AUuGg== X-Google-Smtp-Source: ABdhPJyZIgFMhh7LIEtOujxo7+HY+83tdVDV6FqChjlU6FEZSv6L35zhzdxXEgG+31WEfk9IdLG1Iw== X-Received: by 2002:a63:3e4f:: with SMTP id l76mr8667896pga.65.1634419178466; Sat, 16 Oct 2021 14:19:38 -0700 (PDT) Received: from ?IPv6:2406:e003:102d:e801:db7:d041:a2d:ce65? ([2406:e003:102d:e801:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id y3sm8597156pjg.7.2021.10.16.14.19.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 16 Oct 2021 14:19:37 -0700 (PDT) To: Ted Hardie Cc: "Joel M. Halpern" , "ipv6@ietf.org" , "spring@ietf.org" References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <1daf3d20-22b2-d111-5131-bd53f51c53a3@gmail.com> <60f71d8c-8165-111c-4099-7f926a897d22@gmail.com> From: Brian E Carpenter Message-ID: <13455849-c0a0-705b-66d8-3b31e7bf95eb@gmail.com> Date: Sun, 17 Oct 2021 10:19:32 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 16 Oct 2021 21:19:45 -0000 Ted, On 15-Oct-21 23:39, Ted Hardie wrote: > On Thu, Oct 14, 2021 at 10:06 PM Brian E Carpenter > wrote: >=20 > On 14-Oct-21 22:41, Ted Hardie wrote: > > On Wed, Oct 13, 2021 at 9:28 PM Brian E Carpenter >> wrote: > > > > > > > >=C2=A0 =C2=A0 =C2=A0Including semantics *of any kind* in an IP add= ress is a very fundamental > >=C2=A0 =C2=A0 =C2=A0change to the concept of IP.> > > > > > > Would you mind elaborating what you mean by semantics in the stat= ement above?=C2=A0 Clearly there are semantics in things like the IPv4 mu= lticast and experimental address ranges (aka "Class D" and "Class E"); es= pecially for the multicast case, the very fundamental semantics of the di= stribution are signalled using the address and there has been significant=20 deployment using those semantics.=C2=A0 Isn't that semantics in the meani= ng above? >=20 > Yes, I should have restricted my remark to *unicast* addresses. But=20 there > is a difference, I think, between semantics that describe the *type=20 of address* and semantics that actively describe *what the recipient is g= oing to do*. It's the latter that I was getting at. >=20 >=20 > Thank you for the clarification, though I'm still struggling a bit with=20 understanding your concern.=C2=A0 Since we use address ranges for scope s= emantics (e.g. ULAs for administratively determined scopes) even within u= nicast addressing, I'm not quite=C2=A0seeing the line you are yet. I definitely did not express myself clearly enough. I want to draw a dist= inction between unicast address bits that are arbitrary numbers as far as=20 the routing system is concerned -- such as the classical IID bits in IPv6=20 unicast addresses, or the prefix bits following fc00::/7 -- and address b= its that are meaningful to the routing system, such as fe80::/10 (which m= eans "do not route this packet"). A glance at https://www.iana.org/assignments/iana-ipv6-special-registry/i= ana-ipv6-special-registry.xhtml shows that this distinction is not mathem= atically rigid, because of oddities like 100::/64, but I think it's gener= ally valid. Within an SRV6 domain, with RFC8986 and the current draft, we see somethi= ng new: a field which has classically been an arbitrary 64-bit number for=20 the routing system (the IID field) becomes meaningful to the routing syst= em. That's an architectural change, and definitely was not envisaged by t= he IPv6 address architecture. So, IMHO, the question behind SPRING's question to 6MAN is not whether th= ere is an architectural change, but whether this changes matters. In part= icular, will it have impact on legacy devices and software within the SRV= 6 domain, and will it do any damage if it leaks outside the domain? (To a certain extent, this question is linked to draft-bourbaki-6man-clas= sless-ipv6.) >=20 >> (This applies to Carsten's comment too. Port numbers or multiple addre= sses per host are not actively describing what the recipient will do; the= y're just numbers.) >=20 > While this may theoretically be true, we actually associate significant=20 semantics with port numbers, both in the end hosts (e.g. the ports below = 1024 being privileged ports) and in the network (where firewalls use port= s to start the process of analyzing the permissibility of a flow).=C2=A0 = A specific port number very much describes what the host will do: =C2=A0p= ort 25 will link to the SMTP service, for example.=C2=A0 So I guess I'm n= ot following this parallel too well either. I hope that it's clearer now that I'm making a distinction between bits t= hat do or do not convey a semantic meaning to unicast routing mechanisms.=20 What happens inside the destination host is really a different matter. Regards, Brian >=20 > regards, >=20 > Ted > =C2=A0 >=20 >=20 > Also, I tried not to express shock and horror at the notion of sema= ntics in address, but concern about how this will impact existing hardwar= e and software. >=20 > > > > Thanks for any clarification, > > > > Ted > > >=20 From nobody Sat Oct 16 16:59:03 2021 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 9B6653A0E07; Sat, 16 Oct 2021 16:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 Kirh0OvlmPgz; Sat, 16 Oct 2021 16:58:35 -0700 (PDT) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 81FDD3A0E09; Sat, 16 Oct 2021 16:58:35 -0700 (PDT) Received: by mail-io1-xd29.google.com with SMTP id h196so12088934iof.2; Sat, 16 Oct 2021 16:58:35 -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=2UBNSvtuYlDYrQtIiTQYw/iHvXQA00tQaC5qzucwX8w=; b=WMYm/cw5sTg3kuVPP6wp8BrfMVyXEoNh1dgxFwi0dNyWUNtXoapnB22GhsEb12Krmn efvKLgZMp9LzB+gCI0mgVgGipTLnSv4oinHQT59UHNo3t5+eHvpPTDFkXAdCMOCZNrXK VEv4l9HRkS4S+vT4Lt4CXIwx6e1r4sGUUTZneFkzbGElnWTFO37Adu7ftzix7CKY0Q7+ Db4HileAvZCbyj/2img8FyAJdQ4ltbF+bObYOSXjE47mD10Tdlsc73eWMfx+OVlhe4og 71afw95e+bloXCggPNnlHGSwJo8xAPEd/ZjwayVV7K9YSfbtMwqb1/us+zDbwS+NYDCZ nJGQ== 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=2UBNSvtuYlDYrQtIiTQYw/iHvXQA00tQaC5qzucwX8w=; b=kVr8pVf3muuEOsA+YX8fCHpxlxSHmWZ4SG3O7a9amQ+QW9LkxEPRMECqoQVp+QSjmJ XVx/2m3ggqqKTNQ7TuHaltNDZUbOb9jQewgEDsSAtD3EStxEN2xfUnSB1JF48J8Sr7b5 O/OXOo4yuxqFMEtP2Q323JPn+jLqbNrJqFOrTEzbuW6IZtkMUg6N1d0pMYqZTB7Dl62N /wHRd4+cgwwIpcgBW2BoWGBpLUSAcpdesa87LAcSck1MBZhAHzWfj0OQO414W3j3qUet MIFYV7oDPZLdSj+Bq2FeT8WKrzD+JjqDom+kKXmkPWYAi3RCfbeJZ5i6dasu5+nxeb5N ELjQ== X-Gm-Message-State: AOAM532SP1KOrdavsZPb7B4oGgLMyQ/Srucg2c4uJ5dJJD/5qgen65r7 mxy9MWlYz8GBpf1ipW3TWfuA20UvfkXGWqaf0cs= X-Google-Smtp-Source: ABdhPJwnS4DebKCv/DXsRWgPUg3bmQqxJw2j9Xaz2mx+OdYC+ppp89v24Y6JApp97TN1YC/FfNmGyyxMHX9Zr6IV/sQ= X-Received: by 2002:a05:6602:2d92:: with SMTP id k18mr9525210iow.130.1634428714513; Sat, 16 Oct 2021 16:58:34 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <1396_1634278622_61691CDE_1396_28_5_787AE7BB302AE849A7480A190F8B93303542C654@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1101.1634412958@localhost> In-Reply-To: <1101.1634412958@localhost> From: Mark Smith Date: Sun, 17 Oct 2021 10:58:08 +1100 Message-ID: To: Michael Richardson Cc: mohamed.boucadair@orange.com, SPRING WG , 6man WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [spring] All IPv6 fields are now mutable (Re: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 16 Oct 2021 23:58:41 -0000 On Sun, 17 Oct 2021, 06:36 Michael Richardson, wrote: > > Mark Smith wrote: > > In fight changing DAs also will break AH protection of the IPv6 header. > > AH is dead. It's been dead for decades. > I say this as an IPsec enthusiast who wishes this wasn't true. > But it is. Then all IPv6 field immutability while the packet is in flight is also dead. "Controlled domain" == redefine any field, field semantics, and field processing we like in an existing protocol, yet claim we're still using the original protocol. That has been tacitly endorsed via standards track RFC8986. The Next Header field is not supposed to be modified in flight per internet standard RFC8200, yet standards track RFC8986 specifies the behaviour via PSP. This SRH compression ID is redefining the IPv6 DA field semantics. It encodes multiple network hop destinations in the single IPv6 destination address field. Structured Flow Label - https://datatracker.ietf.org/doc/draft-filsfils-6man-structured-flow-label/ is redefining the IPv6 flow label field. This will be an operational nightmare in the future, when there are multiple applicable RFCs that conflict with each other. I don't want to have to spend time getting into arguments with vendors about which protocol variant RFC their implementation should or shouldn't have to comply with while I have 1000s, 10s or 100s of 1000s of customers off-line. From nobody Sat Oct 16 17:32:05 2021 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 C3BB73A1189; Sat, 16 Oct 2021 17:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3KWYPx4-bK3p; Sat, 16 Oct 2021 17:31:57 -0700 (PDT) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 B4E1E3A1187; Sat, 16 Oct 2021 17:31:57 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id i5so2564269pla.5; Sat, 16 Oct 2021 17:31:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=7wQAJDloYXSGkc94KWRtVIDXT6pLCXekETsBs7Gh9tc=; b=EU+hFZvNDm+vpjYUqlh0jty5oXB665ULWJZH9IvKFRXq0pw+ZE38PsAQtq5o+or4m3 JGJDMS8avqcYfdQnyxIOTsziMAs4PF0ce/L34gMXXgliDOc5/HqF6+9rcZ08ZySilRVd fdj9LejBXMVU4dg71fgidphMIDB5UFjdXMqkYJQ82neFfaK18osNsiaNH0rwj/pTeDYp 511Aev7DkqirTDUZHToK0kYRuNmd6PyAJx1gagcm3DJ+Nxq1PHye+/3vU/rxVDjR6Dl9 g8Hne/+NoKojdSPCLePOPWrsHJr1qPzaNakwqathGts6fTh1ByjFM6DUuE15iUNylBm6 3JKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=7wQAJDloYXSGkc94KWRtVIDXT6pLCXekETsBs7Gh9tc=; b=IPHEBAI5GE2pFZJKWpb6xhR+Wgn6wzrEvkjpYS89Oq/389VClmeeNMt7qMYRj+0TrY 0kT5dFzBjVQ4SrllXvtqBd4P3q8UKTzOJrBAv1G18tnfIMmhfBvLPsRLCt/ntuX7TvMb bBcTn0COECTM0PE1MwBjYEaLoPTAGHEp+2tZnke8jMNP+jtcHfrHhjtEdT942dRWbGLL JMvwJ0cSeK7aX1mV+kZRlWf92vsqiixJnJ0XTKkUb3kJmo+pwGAo9DW1RmyGfdOQiSy7 SZJhm6xthP2FZRSZbDnnEq12DeypNQddqL9YyIuha9URebwQtZfratRCLoq8ViyRdVuI ErSg== X-Gm-Message-State: AOAM5328jTeEEfMwxzGnnm5qlK6Fs2KcPtlVlEsAkBBLVuzkMJfPaQkP blYRQpyKUZce2Xy8W3VD++c= X-Google-Smtp-Source: ABdhPJx5GwwP5A3uxxB7D4pUAhuEJvReDfI+y5Tz3Xd3bAcYLINsPV1YaQcWEr0sJp2g0zVYVFXT1Q== X-Received: by 2002:a17:90a:1b2a:: with SMTP id q39mr23675201pjq.219.1634430716533; Sat, 16 Oct 2021 17:31:56 -0700 (PDT) Received: from ?IPv6:2406:e003:102d:e801:db7:d041:a2d:ce65? ([2406:e003:102d:e801:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id t13sm5211798pgn.94.2021.10.16.17.31.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 16 Oct 2021 17:31:56 -0700 (PDT) To: "Francois Clad (fclad)" Cc: "spring@ietf.org" , "ipv6@ietf.org" , Erik Kline , "Joel M. Halpern" References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> From: Brian E Carpenter Message-ID: <6baed9dc-36c6-720b-0a73-0af7f062cb6a@gmail.com> Date: Sun, 17 Oct 2021 13:31:52 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 17 Oct 2021 00:32:03 -0000 Thanks for this draft. Question: where you show "Source address 2001:db8:a:1100::" is that inten= ded to be the complete address, because it looks like a prefix? I can't f= ind anywhere that an interface identifier of zero is forbidden, but it's = unusual, and can only exist once in a given subnet. Regards Brian Carpenter On 16-Oct-21 10:55, Francois Clad (fclad) wrote: > Hello Erik, >=20 > =C2=A0 >=20 > You may find some examples here: https://datatracker.ietf.org/doc/draft= -clad-spring-srv6-srh-compression-illus/ >=20 > =C2=A0 >=20 > Hope this helps. >=20 > =C2=A0 >=20 > Thanks, >=20 > Francois >=20 > =C2=A0 >=20 > *From: *spring on behalf of Erik Kline > *Date: *Thursday, 14 October 2021 at 19:06 > *To: *Joel M. Halpern > *Cc: *spring@ietf.org , ipv6@ietf.org > *Subject: *Re: [spring] Question from SPRING regarding draft-filsfilsch= eng-spring-srv6-srh-compression >=20 > Joel, >=20 > =C2=A0 >=20 > Thank you for your email.=C2=A0 The ADs and chairs have been discussing= =2E >=20 > =C2=A0 >=20 > One thing that would be very helpful to our discussions would be some w= orked examples of the various C-SID behaviors, showing some SRv6 datagram= s and what happens to their contents as they move across some suitable ex= ample SR domain. >=20 > =C2=A0 >=20 > (It would also be helpful if they showed what happens to something like=20 an ICMPv6 Echo Request to a representative Destination Address in these c= ases when, say, an SRH is not present, i.e. to see when typical unicast s= emantics are preserved or when something more like anycast or multicast b= ehavior is to be expected.) >=20 > =C2=A0 >=20 > Assuming some forthcoming helpful examples, we have a goal to get a mor= e complete answer back to you by the latter half of next week. >=20 > =C2=A0 >=20 > Thanks, >=20 > -Erik >=20 > =C2=A0 >=20 > On Tue, Oct 12, 2021 at 8:53 PM Joel M. Halpern > wrote: >=20 > The SPRING working group is in the midst of an adoption call on > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-sr= h-compression/ . >=20 > The SPRING charter has text that is explicit that modifications to = data > planes and architectures standardized by other working groups may n= ot be > modified in SPRING unless the chairs and ADs responsible for that d= ata > plane and / or architecture agree. >=20 > To complete the context, as my SPRING co-chairs are co-authors on t= he > document in question, they have recused themselves from decisional > activities regarding the document.=C2=A0 Therefore, this message is=20 coming > just from my as the responsible SPRING co-chair managing this adopt= ion call. >=20 > As you have seen, multiple questions have been raised about the > relationship of the document to the IPv6 defined data plane and > architecture (particularly RFC 4291 and 8200). In particular the > questions seem to revolve around what the document describes as the= > NEXT-C-SID flavor of compressed SID, and its relationship to the IP= v6 > standards.=C2=A0 (For those seeking more context without reading th= e full > document, a paraphrase and simplification of the NEXT-C_SID flavor = is > provided as a postscript.) >=20 > I raised the question of concurrence as required by the SPRING char= ter > with the Internet ADs and SPRING chairs.=C2=A0 They quite reasonabl= y asked me > to write a note to 6man explaining the concerns as clearly as a can= , so > that they can then determine how to proceed. >=20 > The questions that prompted my inquiry are: >=20 > 1) Does the placement of a list of sids in the IPv6 DA field change=20 the > IPv6 architectural description of that field. > 2) Does the operation of shifting information around in the IPv6 > destination address field represent a modification or extension of = the > IPv6 data plane. >=20 > On a related note, the document in question also defines two other > flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.=C2=A0 The > NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID > flavor operation, so seems to be affected by the same question. >=20 > =C2=A0From my own reading, it appears that the REPLACE-C-SID flavor=20 does not > raise issues requiring 6man leadership concurrence. >=20 > Yours, > Joel M. Halpern for the SPRING working group >=20 >=20 > PS: > Clearly, understanding the question requires some understanding of = what > the NEXT-C_SID flavor does.=C2=A0 =C2=A0This explanation is a simpl= ification for > length and context.=C2=A0 Really, the best place to understand it i= s the > draft.=C2=A0 However, to give you enough information to let you dec= ide > whether you care, I will try to provide a fair summary.=C2=A0 My ap= ologies in > advance to the authors for necessary liberties for length.=C2=A0 Al= so, > discussion of the draft contents (as distinct from the interaction = with > the IPv6 data plane and architecture) belongs on the SPRING list, a= nd > should not clutter up 6man. >=20 > SIDs are the identifiers used in segment routing. > In SRv6, as document in the current RFCs, these are 128 bits.=C2=A0=20 =C2=A0As > defined in the relevant RFCs, SIDs which identify endpoints to whic= h > packets are directed are identified by endpoint SIDs.=C2=A0 These c= an have > behaviors (decapsulate and forward is one example).=C2=A0 They can = have > flavors such as where the SRH is removed. >=20 > The topic under discussion is means to compress these SIDs in the > packets on the wire.=C2=A0 The document under discussion provides t= hree > flavors of compression. >=20 > The fundamental mechanism of the draft is to use a single SRH entry=20 as a > container for multiple SIDs.=C2=A0 In the NEXT-C_SID mechanism, whe= n it is > first encountered the entire container is copied into the desinatio= n > address of the IPv6 packet.=C2=A0 The container has a common routin= g prefix > used for all the NEXT-C-SID SIDs.=C2=A0 It is followed by a sequenc= e of > compressed SIDs of a configured length.=C2=A0 One could configure 1= 6, 24, or > 32 bits.=C2=A0 Or whatever length.=C2=A0 The routing advertisements=20 are arranged > so that the IPv6 packet is directed to the node represented by the = first > compressed SID on the basis of longest prefix match matching the > combination of the common routing prefix and that compressed SID. >=20 > When the packet arrives at that node, it looks up the configured > portion, the compressed SID, and determines the behavior and flavor= =2E=C2=A0 In > the case of the NEXT-C-SID flavor, the resulting operation is to sh= ift > the entire remaining contents of the IPv6 address (the bits past th= e > first compressed sid) so as to over-write the first compressed SID.= =C2=A0 0 > bits are shifted into the low order positions.=C2=A0 If the result = is a > non-zero new first compressed SID, then the packets is forwarded an= d the > process repeats.=C2=A0 When all that is left are 0s, if there is an=20 SRH, it > is consulted to find the next SRH entry, which is, per normal SRv6 > processing, put into the IPv6 DA. > Note that in the common case where the SIDS needed all fit in to a > single container, the analysis also assumes the use of the reduced > encapsulation options which omits the SRH that is not needed as it = would > have no entries.=C2=A0 This the packet contains a normal IPv6 heade= r, with a > sequence of compressed SIDs (what one might or might not call a sou= rce > route) in the IPv6 destination address field. >=20 > PPS: If the authors of the NEXT-C-SID flavor feel I have mis-repres= ented > the work, please, send clarifications or corrections.=C2=A0 =C2=A0A= gain, the best > source of information is the draft itself.=C2=A0 I was asked to pro= vide extra > context in this email. >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Sat Oct 16 18:30:07 2021 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 37C9B3A0A1B; Sat, 16 Oct 2021 18:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 3xSsoWp93szK; Sat, 16 Oct 2021 18:29:41 -0700 (PDT) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 107433A0A5E; Sat, 16 Oct 2021 18:29:41 -0700 (PDT) Received: by mail-pj1-x1036.google.com with SMTP id pi19-20020a17090b1e5300b0019fdd3557d3so10041056pjb.5; Sat, 16 Oct 2021 18:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=F7j2dMjNqYGHEu+pgmgTPNjpMbrO2rucGtggPTTzbWE=; b=LPeaTLEQ1Fl/CqdV8UdRYYuzlJxZzT+ZYncMP9oJw6A6k1iQR1c4GSpms5cCqSuubD uCvdemPx85+zxuEMRjygMMPQXisbCHzDF3gucHquPalPoP3v/30QR4f/OV0eEkgecRpV tSdg2V9CeosBQA8elMNRMMZLDarMLs2Z/vv6dsHA96LZr0FCpkmQ+8i1Tr8wbF7frFpI h511fbegAZUhq2HunDScrFxDOykj01lb+DLHCLUwZEpWuCcZiH/rc0GXRgYidpaMgMqw aqrkpELWzo1gl+dG7PhAXumnFzG3GDQxeHj0ZSVXqvh0rWc8eIW3GgAnOUp4P22+hIw/ nDLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:from:to:cc:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=F7j2dMjNqYGHEu+pgmgTPNjpMbrO2rucGtggPTTzbWE=; b=A8OnanhohuyC3nH4vZoJhKYKrge4vcLWYCyO2YMbUYmZMah8mt3WzSTJv2utQK40w/ UOerHiQIfEOHp8svcoTxoDXbErXb7VuHFl76YpPV6MLtUzqV1SYFxmTDL15Q75xHEL9W OTU8q+7/HblK0Bb4jc73+ejpX+22umnITBhaPaSeF15F0Toxh4Jq7XVf1fJb0l/oSJ95 yk3NhFTVOg4TEC8w1obtWEaKx1SsOr6M/87bxEXT7/w3prcrIz3NpGE/ptJUS+rccXpb hp9JqIJHeOc8uvpMTznpEE7kBwhaPJOIs0wAceeLBljsm5XbK11wPdCkuTJ4EWroahvo txaA== X-Gm-Message-State: AOAM532fLtrlnLwlOXT3JGIRb3hd7cqm+5oUh/OVt5r61hoSWQsnWPb6 xJE2RPgWGYlvBenEq1FHCRAFKY7y/W1KBA== X-Google-Smtp-Source: ABdhPJwbajPR6GVTeVjg9mzum7OPwyR401Ba2ZhHV7pdQmaCyHK6hLw70rbuyAKjzXdcEICDTafMsA== X-Received: by 2002:a17:90a:9b0d:: with SMTP id f13mr6785155pjp.235.1634434180117; Sat, 16 Oct 2021 18:29:40 -0700 (PDT) Received: from ?IPv6:2406:e003:102d:e801:db7:d041:a2d:ce65? ([2406:e003:102d:e801:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id t1sm8651946pfe.51.2021.10.16.18.29.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 16 Oct 2021 18:29:39 -0700 (PDT) From: Brian E Carpenter To: "Francois Clad (fclad)" Cc: "spring@ietf.org" , "ipv6@ietf.org" , Erik Kline , "Joel M. Halpern" References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <6baed9dc-36c6-720b-0a73-0af7f062cb6a@gmail.com> Message-ID: <6c852ab5-141f-4fad-1223-1a6a9eda375e@gmail.com> Date: Sun, 17 Oct 2021 14:29:35 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <6baed9dc-36c6-720b-0a73-0af7f062cb6a@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 17 Oct 2021 01:29:52 -0000 > I can't find anywhere that an interface identifier of zero is forbidden= However, when I assign such an address to a Linux box, it is unpingable, = so I'm guessing it breaks neighbor discovery. Regards Brian Carpenter On 17-Oct-21 13:31, Brian E Carpenter wrote: > Thanks for this draft. >=20 > Question: where you show "Source address 2001:db8:a:1100::" is that int= ended to be the complete address, because it looks like a prefix? I can't=20 find anywhere that an interface identifier of zero is forbidden, but it's=20 unusual, and can only exist once in a given subnet. >=20 > Regards > Brian Carpenter >=20 > On 16-Oct-21 10:55, Francois Clad (fclad) wrote: >> Hello Erik, >> >> =C2=A0 >> >> You may find some examples here: https://datatracker.ietf.org/doc/draf= t-clad-spring-srv6-srh-compression-illus/ >> >> =C2=A0 >> >> Hope this helps. >> >> =C2=A0 >> >> Thanks, >> >> Francois >> >> =C2=A0 >> >> *From: *spring on behalf of Erik Kline >> *Date: *Thursday, 14 October 2021 at 19:06 >> *To: *Joel M. Halpern >> *Cc: *spring@ietf.org , ipv6@ietf.org = >> *Subject: *Re: [spring] Question from SPRING regarding draft-filsfilsc= heng-spring-srv6-srh-compression >> >> Joel, >> >> =C2=A0 >> >> Thank you for your email.=C2=A0 The ADs and chairs have been discussin= g. >> >> =C2=A0 >> >> One thing that would be very helpful to our discussions would be some = worked examples of the various C-SID behaviors, showing some SRv6 datagra= ms and what happens to their contents as they move across some suitable e= xample SR domain. >> >> =C2=A0 >> >> (It would also be helpful if they showed what happens to something lik= e=20 > an ICMPv6 Echo Request to a representative Destination Address in these=20 cases when, say, an SRH is not present, i.e. to see when typical unicast = semantics are preserved or when something more like anycast or multicast = behavior is to be expected.) >> >> =C2=A0 >> >> Assuming some forthcoming helpful examples, we have a goal to get a mo= re complete answer back to you by the latter half of next week. >> >> =C2=A0 >> >> Thanks, >> >> -Erik >> >> =C2=A0 >> >> On Tue, Oct 12, 2021 at 8:53 PM Joel M. Halpern > wrote: >> >> The SPRING working group is in the midst of an adoption call on >> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-s= rh-compression/ . >> >> The SPRING charter has text that is explicit that modifications to=20 data >> planes and architectures standardized by other working groups may = not be >> modified in SPRING unless the chairs and ADs responsible for that = data >> plane and / or architecture agree. >> >> To complete the context, as my SPRING co-chairs are co-authors on = the >> document in question, they have recused themselves from decisional= >> activities regarding the document.=C2=A0 Therefore, this message i= s=20 > coming >> just from my as the responsible SPRING co-chair managing this adop= tion call. >> >> As you have seen, multiple questions have been raised about the >> relationship of the document to the IPv6 defined data plane and >> architecture (particularly RFC 4291 and 8200). In particular the >> questions seem to revolve around what the document describes as th= e >> NEXT-C-SID flavor of compressed SID, and its relationship to the I= Pv6 >> standards.=C2=A0 (For those seeking more context without reading t= he full >> document, a paraphrase and simplification of the NEXT-C_SID flavor=20 is >> provided as a postscript.) >> >> I raised the question of concurrence as required by the SPRING cha= rter >> with the Internet ADs and SPRING chairs.=C2=A0 They quite reasonab= ly asked me >> to write a note to 6man explaining the concerns as clearly as a ca= n, so >> that they can then determine how to proceed. >> >> The questions that prompted my inquiry are: >> >> 1) Does the placement of a list of sids in the IPv6 DA field chang= e=20 > the >> IPv6 architectural description of that field. >> 2) Does the operation of shifting information around in the IPv6 >> destination address field represent a modification or extension of=20 the >> IPv6 data plane. >> >> On a related note, the document in question also defines two other= >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.=C2=A0 The >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID= >> flavor operation, so seems to be affected by the same question. >> >> =C2=A0From my own reading, it appears that the REPLACE-C-SID flavo= r=20 > does not >> raise issues requiring 6man leadership concurrence. >> >> Yours, >> Joel M. Halpern for the SPRING working group >> >> >> PS: >> Clearly, understanding the question requires some understanding of=20 what >> the NEXT-C_SID flavor does.=C2=A0 =C2=A0This explanation is a simp= lification for >> length and context.=C2=A0 Really, the best place to understand it = is the >> draft.=C2=A0 However, to give you enough information to let you de= cide >> whether you care, I will try to provide a fair summary.=C2=A0 My a= pologies in >> advance to the authors for necessary liberties for length.=C2=A0 A= lso, >> discussion of the draft contents (as distinct from the interaction=20 with >> the IPv6 data plane and architecture) belongs on the SPRING list, = and >> should not clutter up 6man. >> >> SIDs are the identifiers used in segment routing. >> In SRv6, as document in the current RFCs, these are 128 bits.=C2=A0=20 > =C2=A0As >> defined in the relevant RFCs, SIDs which identify endpoints to whi= ch >> packets are directed are identified by endpoint SIDs.=C2=A0 These = can have >> behaviors (decapsulate and forward is one example).=C2=A0 They can=20 have >> flavors such as where the SRH is removed. >> >> The topic under discussion is means to compress these SIDs in the >> packets on the wire.=C2=A0 The document under discussion provides = three >> flavors of compression. >> >> The fundamental mechanism of the draft is to use a single SRH entr= y=20 > as a >> container for multiple SIDs.=C2=A0 In the NEXT-C_SID mechanism, wh= en it is >> first encountered the entire container is copied into the desinati= on >> address of the IPv6 packet.=C2=A0 The container has a common routi= ng prefix >> used for all the NEXT-C-SID SIDs.=C2=A0 It is followed by a sequen= ce of >> compressed SIDs of a configured length.=C2=A0 One could configure = 16, 24, or >> 32 bits.=C2=A0 Or whatever length.=C2=A0 The routing advertisement= s=20 > are arranged >> so that the IPv6 packet is directed to the node represented by the=20 first >> compressed SID on the basis of longest prefix match matching the >> combination of the common routing prefix and that compressed SID. >> >> When the packet arrives at that node, it looks up the configured >> portion, the compressed SID, and determines the behavior and flavo= r.=C2=A0 In >> the case of the NEXT-C-SID flavor, the resulting operation is to s= hift >> the entire remaining contents of the IPv6 address (the bits past t= he >> first compressed sid) so as to over-write the first compressed SID= =2E=C2=A0 0 >> bits are shifted into the low order positions.=C2=A0 If the result=20 is a >> non-zero new first compressed SID, then the packets is forwarded a= nd the >> process repeats.=C2=A0 When all that is left are 0s, if there is a= n=20 > SRH, it >> is consulted to find the next SRH entry, which is, per normal SRv6= >> processing, put into the IPv6 DA. >> Note that in the common case where the SIDS needed all fit in to a= >> single container, the analysis also assumes the use of the reduced= >> encapsulation options which omits the SRH that is not needed as it=20 would >> have no entries.=C2=A0 This the packet contains a normal IPv6 head= er, with a >> sequence of compressed SIDs (what one might or might not call a so= urce >> route) in the IPv6 destination address field. >> >> PPS: If the authors of the NEXT-C-SID flavor feel I have mis-repre= sented >> the work, please, send clarifications or corrections.=C2=A0 =C2=A0= Again, the best >> source of information is the draft itself.=C2=A0 I was asked to pr= ovide extra >> context in this email. >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >=20 From nobody Sat Oct 16 22:39:09 2021 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 8AEE43A0906 for ; Sat, 16 Oct 2021 22:39:05 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=liquidtelecom.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 sIZibq-QEJOy for ; Sat, 16 Oct 2021 22:38:59 -0700 (PDT) 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 3C53D3A0902 for ; Sat, 16 Oct 2021 22:38:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquidtelecom.com; s=mimecast20210406; t=1634449135; 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=ZAdc8ZUskBiKi/jB879ubY7PO2ef1DYugS/dp/6ikQs=; b=YE3gCrpOyC0RbkgCY7G7UrtErB7gjTt4GCE6f7XMf0NniGyRxzOcXlC4q06e8X0djsdXh1 CJchd+/FJ1BZkydlsDItfLsr+xFsZ/m6WWjk1LokKZ/wGTzCdwjaqqqZ/5lt0E3O9bhYa8 3SAcLNZgEl6MMcHPZHw/65MIToutSwM= Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05lp2112.outbound.protection.outlook.com [104.47.18.112]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-238-JDk0W5jBO72abPa9_-nkMg-1; Sun, 17 Oct 2021 06:38:53 +0100 X-MC-Unique: JDk0W5jBO72abPa9_-nkMg-1 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com (2603:10a6:20b:346::6) by AS8PR03MB7703.eurprd03.prod.outlook.com (2603:10a6:20b:402::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.16; Sun, 17 Oct 2021 05:38:51 +0000 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9]) by AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9%7]) with mapi id 15.20.4608.018; Sun, 17 Oct 2021 05:38:51 +0000 From: Andrew Alston To: Mark Smith , Michael Richardson CC: 6man WG , SPRING WG Thread-Topic: All IPv6 fields are now mutable (Re: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) Thread-Index: AQHXwunQOoEfzZ2oU0Wr0vRqrRe87avWqlPY Date: Sun, 17 Oct 2021 05:38:51 +0000 Message-ID: References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <1396_1634278622_61691CDE_1396_28_5_787AE7BB302AE849A7480A190F8B93303542C654@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1101.1634412958@localhost> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2185ab8c-02cb-476c-2f4f-08d99130667c x-ms-traffictypediagnostic: AS8PR03MB7703: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4714 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: RLp0rnQWsPFie8FcThNcj2bAKhjWmVCUeXt9E8Q7m1kZ1MB9GeLeSxjLOEHuI3IxncZfhMCSJhtxzxutbgkldQOpKN9YW2wwuj9viodS9dA5v0iIpn6Dk/BVJ4cIxynlOw5ZMpWyHaYhl4W8sT2GUNfNlJ+RQxFq2+Kj5Dtpjz2C2l95+TBXziyBW4A60GKsc6kCNMdXrXWbehecQEc5tK+3+Pz9sSiAtncGlFioprs40TXGroG57E3X3I+Iu3gYPF4wEmFN7wVL98x0ZMvzrvBoENZYbYhLNKUvGPjsPqz1vYhBKYdNkrb2uWB2c8cJLEogbSRkpKluvV4PfctgvDFXnn93efnLNLpljZRiJjR0WBvqpjjzOuoQjp7NxxUqFdrHykJV4owt38Y91Lwh6MYTkCj68AUZj1mfhHZmTebmoG0rDXZUl/dywlPMzN5m5aSs553CKOfTXJ0tRKJX78fDNvhrUgTpyW1Xijy+guVfAJb+r3EcuWk7a3yy3EG4BEOYUh8ARZUkmay9NEVs6jy9QXJ+wHREbe2x5460qwsO0Wbm8osyphItbDJg3nZJuvakK5DjQFk51XEDn7mUJYXzC897GA23yvp8CF1PcWE1THsGc2aknt8peP3HVNsUqDzKQYqDmtDUP0bYyG5V28/9Li84fpqDAadZicfnl2mvymsm7yder4sXmcVwYjOqs8ApDiNuIzQoBFCiVR8k6MoHrWeIrWSIvDzP6N7ydV6OHctLOs0LVANtNScvlTJtcoiJypO4DMBgdmwpgbm4yqR3OMuFw0bD9v4OYz2akhtDIWK7Aalb/V4Ixpz1TuStk9k7WkWNbrpVIhfY3NtAQw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR03MB7622.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(6506007)(53546011)(166002)(2906002)(316002)(9686003)(54906003)(71200400001)(110136005)(55016002)(64756008)(45080400002)(66446008)(66476007)(8936002)(186003)(8676002)(66556008)(122000001)(66574015)(83380400001)(33656002)(508600001)(91956017)(76116006)(66946007)(86362001)(52536014)(966005)(7696005)(5660300002)(38100700002)(38070700005)(4326008); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?4j2eRuzPa7cyBgA1PhSiou+MVuI6IUuM92wLAOvhfxjpNBM11QML065U?= =?Windows-1252?Q?lSDnJltwPxIyQgHPt+e5NvLvnVudrAgRCvbRJICc0mjNiSSmjUypOLoN?= =?Windows-1252?Q?+SXukGv8i3boViOdQCMN/T9vz13XdnyOGGImpyZwuHC+3Zdl3nuQI0Hi?= =?Windows-1252?Q?gAwFvAm/eFlHo1u0BEMuFMs9dQ2zKwkmkRVvimzaoAQV+5FzaQxJ0HGw?= =?Windows-1252?Q?bJOWq7bcsY1uTJTBYkQj/2PPSthscBcSq2u4XBfOF2qIiShgYSS98aYb?= =?Windows-1252?Q?bq8SrnLr9lvM9nLluT1IYEc9E70VsyVAa4wX1B5YdQGqWDgIrVQhF4EI?= =?Windows-1252?Q?z+PYAP99Eh0f+qipUphLyoVTlmuwTSLDxNSRvkUrjtdERKOsOu+TIHD/?= =?Windows-1252?Q?5PfwILOOT+NbyQU2wVIBub65o6Lj501GhCFR13HDEGDaczEe2aQe85Pr?= =?Windows-1252?Q?YwmwZ7KOwLPWT8ZDVuLjalQkt/A1OZqSZfWs/Vb0oR/SD8eEYiWodHtK?= =?Windows-1252?Q?QgzvGB70DsOv6TtrsdToS7ZJn3UOFinH9SIrKmAxrkzydNO5AbodPy6y?= =?Windows-1252?Q?L1oGf4yg70/V3yGpcwFGInD2WrAqdLwd4Tsmwh/ZEoG7W4y0VC7/d3Tk?= =?Windows-1252?Q?gLIv+NSzOqKNOUreyxcVRk4zZsgPkHSeu8/HJxH44NkoVNA1nBwaMGaG?= =?Windows-1252?Q?JrHz0JA0ydJELR5/9begFjNFQ1m5Mr4hd9FZbM86tRZsEDeTjfOXsSVA?= =?Windows-1252?Q?Dv4G6K4vNHw6voHXZ1ZdmADbUE4Iilh35IqEio/d55HFzWjGhgRLIIDt?= =?Windows-1252?Q?gGPiZwj5BqpiwU/kMmN/kb3gJzOUzI5N5RKFWQ24HbCYU2izf4eCuHOa?= =?Windows-1252?Q?i9Klizz+hpTb21DVJkZ2dywzIQxGxXCfm+7Le8DYkTd3kc4TC6K4HVgI?= =?Windows-1252?Q?4g8lFZTRLLgBwG9+bNhkm3SLuKdHJGTTJWSKADzGncUo0JSAcVLrAOGq?= =?Windows-1252?Q?o7mk7PV+FXsWb8FhlAUTTz7vTx37y932sNcuXsABe8n+GrPZbg7x/ZDX?= =?Windows-1252?Q?i4H2mo8Ra1F83BqQWyZLkDBKSoV5LEACMjk663FhWeDRc+lO6qPhbaTT?= =?Windows-1252?Q?w2U2d+kUox4r+8SMHI6btDl19enIc5cwtVNV7ZAKX9m238yCdKfs/zVi?= =?Windows-1252?Q?1BatSIp/cLka1vBtEq4fZazzwxwVTZciKgj+9S9zpHAU6GfsHuBn6Nkj?= =?Windows-1252?Q?U1hYchrEkTC5j1BDKmboAXrLS1WoDk7MEJ6mWydDrk9itwfx91f7F7LL?= =?Windows-1252?Q?/SwXtUYbe76aMNA3j/siYVQAawSKrpe6ivgIbimckCZzCzF2pghavb49?= =?Windows-1252?Q?NaT7Pc8r1UXrufoDu/rTPnsRzjhjtgEulyO5uFjyqWLnPqy2i0RuP3LA?= =?Windows-1252?Q?aTZntsAzkIruYqnRiNLmeYUJwx8mMT8MrwTJ7PZslDj6mif1kO+giiLO?= =?Windows-1252?Q?fm8LmmL8?= x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB7622.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2185ab8c-02cb-476c-2f4f-08d99130667c X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2021 05:38:51.1367 (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: s+3AyBJd9qqoQiYcsMpJfSEwTgD7tYxDSH82dmDT1oy7gxnJ2bYr3ZHoDvKbRRPIFgdE0od8iVkRVKqWNIVzxu9cITWK+KRVMxVYtsZUfDE= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7703 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquidtelecom.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_AS8PR03MB7622C8D3E9273B3D9025D025EEBB9AS8PR03MB7622eurp_" Archived-At: Subject: Re: [spring] All IPv6 fields are now mutable (Re: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 17 Oct 2021 05:39:06 -0000 --_000_AS8PR03MB7622C8D3E9273B3D9025D025EEBB9AS8PR03MB7622eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Mark, I seriously wonder as I see all this if it wasn=92t a mistake to not declar= e srv6 an entirely new protocol with a new protocol number back at the star= t of this. Because it looks more and more like Robert was right when he said that srv6= was not ipv6 - that or we seem to have forgotten the very basics of standa= rdization. The problem here is that it seems to be a slow drift - and the delta betwee= n these minor corruptions of each aspect of the specification in each new d= raft is small enough that we seem to be content to let it slide. Unfortuna= tely each time this happens - the delta between the original spec and whate= ver we have by the time we take all of this combined is well - rather large= . Sooner or later we are going to have to decide - continue to allow the prot= ocol to mutate while still claiming it is ipv6 - or do what maybe should ha= ve been done in the first place - give it a new protocol number and let peo= ple decide if they want ipv6 or whatever this is. Andrew Get Outlook for iOS ________________________________ From: ipv6 on behalf of Mark Smith Sent: Sunday, October 17, 2021 2:58:08 AM To: Michael Richardson Cc: 6man WG ; SPRING WG Subject: All IPv6 fields are now mutable (Re: Typo correction Re: Question = from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) On Sun, 17 Oct 2021, 06:36 Michael Richardson, wrote: > > Mark Smith wrote: > > In fight changing DAs also will break AH protection of the IPv6 header. > > AH is dead. It's been dead for decades. > I say this as an IPsec enthusiast who wishes this wasn't true. > But it is. Then all IPv6 field immutability while the packet is in flight is also dead= . "Controlled domain" =3D=3D redefine any field, field semantics, and field processing we like in an existing protocol, yet claim we're still using the original protocol. That has been tacitly endorsed via standards track RFC8986. The Next Header field is not supposed to be modified in flight per internet standard RFC8200, yet standards track RFC8986 specifies the behaviour via PSP. This SRH compression ID is redefining the IPv6 DA field semantics. It encodes multiple network hop destinations in the single IPv6 destination address field. Structured Flow Label - https://datatracker.ietf.org/doc/draft-filsfils-6man-structured-flow-label/= is redefining the IPv6 flow label field. This will be an operational nightmare in the future, when there are multiple applicable RFCs that conflict with each other. I don't want to have to spend time getting into arguments with vendors about which protocol variant RFC their implementation should or shouldn't have to comply with while I have 1000s, 10s or 100s of 1000s of customers off-line. -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --_000_AS8PR03MB7622C8D3E9273B3D9025D025EEBB9AS8PR03MB7622eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
    Mark,

    I seriously wonder as I see all this if it wasn=92t a mistake to not declar= e srv6 an entirely new protocol with a new protocol number back at the star= t of this.

    Because it looks more and more like Robert was right when he said that srv6= was not ipv6 - that or we seem to have forgotten the very basics of standa= rdization.

    The problem here is that it seems to be a slow drift - and the delta betwee= n these minor corruptions of each aspect of the specification in each new d= raft is small enough that we seem to be content to let it slide.  Unfo= rtunately each time this happens - the delta between the original spec and whatever we have by the time we take a= ll of this combined is well - rather large.

    Sooner or later we are going to have to decide - continue to allow the prot= ocol to mutate while still claiming it is ipv6 - or do what maybe should ha= ve been done in the first place - give it a new protocol number and let peo= ple decide if they want ipv6 or whatever this is.

    Andrew 
    From: ipv6 <ipv6-bounces= @ietf.org> on behalf of Mark Smith <markzzzsmith@gmail.com>
    Sent: Sunday, October 17, 2021 2:58:08 AM
    To: Michael Richardson <mcr@sandelman.ca>
    Cc: 6man WG <ipv6@ietf.org>; SPRING WG <spring@ietf.org>=
    Subject: All IPv6 fields are now mutable (Re: Typo correction Re: Qu= estion from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compressio= n)
     
    On Sun, 17 Oct 2021, 06:36 Michael Richardson, <mcr@sandelman.ca>= ; wrote:
    >
    > Mark Smith <markzzzsmith@gmail.com> wrote:
    > > In fight changing DAs also will break AH protection of the IPv6 h= eader.
    >
    > AH is dead. It's been dead for decades.
    > I say this as an IPsec enthusiast who wishes this wasn't true.
    > But it is.


    Then all IPv6 field immutability while the packet is in flight is also dead= .

    "Controlled domain" =3D=3D redefine any field, field semantics, a= nd field
    processing we like in an existing protocol, yet claim we're still
    using the original protocol.

    That has been tacitly endorsed via standards track RFC8986. The Next
    Header field is not supposed to be modified in flight per internet
    standard RFC8200, yet standards track RFC8986 specifies the behaviour
    via PSP.

    This SRH compression ID is redefining the IPv6 DA field semantics. It
    encodes multiple network hop destinations in the single IPv6
    destination address field.

    Structured Flow Label -
    https://datatracker.ietf.org/doc/draft-filsfils-6man-structured= -flow-label/
    is redefining the IPv6 flow label field.

    This will be an operational nightmare in the future, when there are
    multiple applicable RFCs that conflict with each other. I don't want
    to have to spend time getting into arguments with vendors about which
    protocol variant RFC their implementation should or shouldn't have to
    comply with while I have 1000s, 10s or 100s of 1000s of customers
    off-line.

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    --_000_AS8PR03MB7622C8D3E9273B3D9025D025EEBB9AS8PR03MB7622eurp_-- From nobody Sat Oct 16 22:58:56 2021 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 1C5503A091B; Sat, 16 Oct 2021 22:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 7iYzyzW3Ojql; Sat, 16 Oct 2021 22:58:25 -0700 (PDT) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 995C43A091C; Sat, 16 Oct 2021 22:58:25 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id g2so11608560ild.1; Sat, 16 Oct 2021 22:58:25 -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:content-transfer-encoding; bh=HAGAbPPrspCyo05U/gC5b/ASX/A6IV1wlDoy6toUA64=; b=M6IwVTf64Hukgu6UHMYGxgrVF0M7FwlpmOk0MF8c0MJkJt2YWPi5iUANYvSuU4Ue/B ScK1MHjek7znkCn4Q8np/Olt81YiL9A4cWClWXAY/y3oCtxfHCLgAo9hpzbkcpSuv0JO VouTwG2FtmFye0u8Qgc/EqhL++29lUUzYspymtS8IVsqGr7f/+Gmuc4y803tZju8+QO/ zBx64o7oCefdWAhye11iRQr8N2kaMfqhe1yGCNtukQSYVDMTaY2A5M3rQrnaZHMTThDH WbWwg6UGWQgjKzUEC351tGzMSeiluywE1lx+god79ZoDB6zsch8tX0RB6BKYzXtoXBiu eG4w== 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:content-transfer-encoding; bh=HAGAbPPrspCyo05U/gC5b/ASX/A6IV1wlDoy6toUA64=; b=klpF+ny7JuJ3yTieB2TAmRxOV8Y3Wp5oWGP0P7wxHRVDBfWs7uhBbXQm7JrpI5zVWP XVwlYZ0AaWGPwGGplS0z2zwFgo6NP1tfR+/HnDagkjRMyMeVh9tEb6yDqLpqrjMvrr/A pS5Mok8aL1SqP8xhCiv0E9hjco5HFSoIr9UW810Vi+UF2z/u6P+rute0pnbEmABHkv6B GadUPKbJWsVEHQsTivnMl1K7pZlgEa3405UyVZYUOAnd5RHjxzqlMvI155qvoa4pDSyr i8UaziD/+pLhYQu4NbiYHwGEFKyU6gkPDu+qkSwwb7Mqq0sS5dTLdABeNIz2uO3Fi+0q fU5Q== X-Gm-Message-State: AOAM530+9iQTJX9XzdlNMOy7dRY0J+WV4sfLcPA49IxeJF2TuMLU1fbM lu8y0porO8kfUoGnWxE2U8gd6TT6BALSMoZVTCc= X-Google-Smtp-Source: ABdhPJw3HFHmukwTpZShfTS2Cp8rpm4mvRIRyz8S6LMfHJmqHDJMhfDbQqAQcrOPrIp+zIpxvevk9zGk7vGxySOe6sc= X-Received: by 2002:a05:6e02:1025:: with SMTP id o5mr10398045ilj.133.1634450304491; Sat, 16 Oct 2021 22:58:24 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <6baed9dc-36c6-720b-0a73-0af7f062cb6a@gmail.com> In-Reply-To: <6baed9dc-36c6-720b-0a73-0af7f062cb6a@gmail.com> From: Mark Smith Date: Sun, 17 Oct 2021 16:57:58 +1100 Message-ID: To: Brian E Carpenter Cc: "Francois Clad (fclad)" , Erik Kline , "spring@ietf.org" , "ipv6@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 17 Oct 2021 05:58:30 -0000 On Sun, 17 Oct 2021 at 11:32, Brian E Carpenter wrote: > > Thanks for this draft. > > Question: where you show "Source address 2001:db8:a:1100::" is that inten= ded to be the complete address, because it looks like a prefix? I can't fin= d anywhere that an interface identifier of zero is forbidden, but it's unus= ual, and can only exist once in a given subnet. > The IID value of all zeros is the subnet-router anycast address within a subnet, and is required. See 2.6.1 of RFC4291. For example, Linux automatically configures the subnet-router anycast address for all prefixes on an interface if the interface is a forwarding interface. [mark@opy ~]$ ip -6 route show table local | grep anycast anycast 2403:5803:XXXX:: dev wlp3s0 proto kernel metric 0 pref medium anycast fe80:: dev wlp3s0 proto kernel metric 0 pref medium [mark@opy ~]$ (The "local" route table is where the interface address and multicast route route table entries are kept in Linux. They don't all show up via the normal 'ip addr show' or 'ifconfig' commands). Regards, Mark. > Regards > Brian Carpenter > > On 16-Oct-21 10:55, Francois Clad (fclad) wrote: > > Hello Erik, > > > > > > > > You may find some examples here: https://datatracker.ietf.org/doc/draft= -clad-spring-srv6-srh-compression-illus/ > > > > > > > > Hope this helps. > > > > > > > > Thanks, > > > > Francois > > > > > > > > *From: *spring on behalf of Erik Kline > > *Date: *Thursday, 14 October 2021 at 19:06 > > *To: *Joel M. Halpern > > *Cc: *spring@ietf.org , ipv6@ietf.org > > *Subject: *Re: [spring] Question from SPRING regarding draft-filsfilsch= eng-spring-srv6-srh-compression > > > > Joel, > > > > > > > > Thank you for your email. The ADs and chairs have been discussing. > > > > > > > > One thing that would be very helpful to our discussions would be some w= orked examples of the various C-SID behaviors, showing some SRv6 datagrams = and what happens to their contents as they move across some suitable exampl= e SR domain. > > > > > > > > (It would also be helpful if they showed what happens to something like > an ICMPv6 Echo Request to a representative Destination Address in these c= ases when, say, an SRH is not present, i.e. to see when typical unicast sem= antics are preserved or when something more like anycast or multicast behav= ior is to be expected.) > > > > > > > > Assuming some forthcoming helpful examples, we have a goal to get a mor= e complete answer back to you by the latter half of next week. > > > > > > > > Thanks, > > > > -Erik > > > > > > > > On Tue, Oct 12, 2021 at 8:53 PM Joel M. Halpern > wrote: > > > > The SPRING working group is in the midst of an adoption call on > > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-sr= h-compression/ . > > > > The SPRING charter has text that is explicit that modifications to = data > > planes and architectures standardized by other working groups may n= ot be > > modified in SPRING unless the chairs and ADs responsible for that d= ata > > plane and / or architecture agree. > > > > To complete the context, as my SPRING co-chairs are co-authors on t= he > > document in question, they have recused themselves from decisional > > activities regarding the document. Therefore, this message is > coming > > just from my as the responsible SPRING co-chair managing this adopt= ion call. > > > > As you have seen, multiple questions have been raised about the > > relationship of the document to the IPv6 defined data plane and > > architecture (particularly RFC 4291 and 8200). In particular the > > questions seem to revolve around what the document describes as the > > NEXT-C-SID flavor of compressed SID, and its relationship to the IP= v6 > > standards. (For those seeking more context without reading the ful= l > > document, a paraphrase and simplification of the NEXT-C_SID flavor = is > > provided as a postscript.) > > > > I raised the question of concurrence as required by the SPRING char= ter > > with the Internet ADs and SPRING chairs. They quite reasonably ask= ed me > > to write a note to 6man explaining the concerns as clearly as a can= , so > > that they can then determine how to proceed. > > > > The questions that prompted my inquiry are: > > > > 1) Does the placement of a list of sids in the IPv6 DA field change > the > > IPv6 architectural description of that field. > > 2) Does the operation of shifting information around in the IPv6 > > destination address field represent a modification or extension of = the > > IPv6 data plane. > > > > On a related note, the document in question also defines two other > > flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The > > NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID > > flavor operation, so seems to be affected by the same question. > > > > From my own reading, it appears that the REPLACE-C-SID flavor > does not > > raise issues requiring 6man leadership concurrence. > > > > Yours, > > Joel M. Halpern for the SPRING working group > > > > > > PS: > > Clearly, understanding the question requires some understanding of = what > > the NEXT-C_SID flavor does. This explanation is a simplification = for > > length and context. Really, the best place to understand it is the > > draft. However, to give you enough information to let you decide > > whether you care, I will try to provide a fair summary. My apologi= es in > > advance to the authors for necessary liberties for length. Also, > > discussion of the draft contents (as distinct from the interaction = with > > the IPv6 data plane and architecture) belongs on the SPRING list, a= nd > > should not clutter up 6man. > > > > SIDs are the identifiers used in segment routing. > > In SRv6, as document in the current RFCs, these are 128 bits. > As > > defined in the relevant RFCs, SIDs which identify endpoints to whic= h > > packets are directed are identified by endpoint SIDs. These can ha= ve > > behaviors (decapsulate and forward is one example). They can have > > flavors such as where the SRH is removed. > > > > The topic under discussion is means to compress these SIDs in the > > packets on the wire. The document under discussion provides three > > flavors of compression. > > > > The fundamental mechanism of the draft is to use a single SRH entry > as a > > container for multiple SIDs. In the NEXT-C_SID mechanism, when it = is > > first encountered the entire container is copied into the desinatio= n > > address of the IPv6 packet. The container has a common routing pre= fix > > used for all the NEXT-C-SID SIDs. It is followed by a sequence of > > compressed SIDs of a configured length. One could configure 16, 24= , or > > 32 bits. Or whatever length. The routing advertisements > are arranged > > so that the IPv6 packet is directed to the node represented by the = first > > compressed SID on the basis of longest prefix match matching the > > combination of the common routing prefix and that compressed SID. > > > > When the packet arrives at that node, it looks up the configured > > portion, the compressed SID, and determines the behavior and flavor= . In > > the case of the NEXT-C-SID flavor, the resulting operation is to sh= ift > > the entire remaining contents of the IPv6 address (the bits past th= e > > first compressed sid) so as to over-write the first compressed SID.= 0 > > bits are shifted into the low order positions. If the result is a > > non-zero new first compressed SID, then the packets is forwarded an= d the > > process repeats. When all that is left are 0s, if there is an > SRH, it > > is consulted to find the next SRH entry, which is, per normal SRv6 > > processing, put into the IPv6 DA. > > Note that in the common case where the SIDS needed all fit in to a > > single container, the analysis also assumes the use of the reduced > > encapsulation options which omits the SRH that is not needed as it = would > > have no entries. This the packet contains a normal IPv6 header, wi= th a > > sequence of compressed SIDs (what one might or might not call a sou= rce > > route) in the IPv6 destination address field. > > > > PPS: If the authors of the NEXT-C-SID flavor feel I have mis-repres= ented > > the work, please, send clarifications or corrections. Again, the = best > > source of information is the draft itself. I was asked to provide = extra > > context in this email. > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Sat Oct 16 23:06:33 2021 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 5988B3A0912; Sat, 16 Oct 2021 23:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 qC5boLYVSQIf; Sat, 16 Oct 2021 23:05:06 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (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 D36C73A0922; Sat, 16 Oct 2021 23:05:05 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id n7so2328668ljp.5; Sat, 16 Oct 2021 23:05:05 -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=0qzYU03LLwz6NlQVUPl/Azt2NaU7f58BaN5OnPyDTKA=; b=N6M3XWjKQY9BFVEgGgVKQjHkcS0lMs9A5f8yYcDrQBrEGKI4byDk7NGQcvZjhCGTbK TZAz40diL40Y8zoKeo8bbG3tqvQfn1ol3zkNfdRZj6J9dszN9OkA4dATpfcw+M8Qc4rw eNyyLv4uPO3mxaULTKZlYi3vyvdYqVysS4b1ottjUjFDt4BhybOAkS0nrG7dBVtjd+I/ fVvR1AKyycVR1fF6szuJ8t1KML3Z3XK6iO4P11HbfyVJH6Ynz6sBlfHD1VCfsKKdWGkD 7sZKD1j3ledDUPFKorz60JUs111khDN/HnreiXhUBEZxkNe9JTFYyoKsGhqAV496mPHR m9+w== 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=0qzYU03LLwz6NlQVUPl/Azt2NaU7f58BaN5OnPyDTKA=; b=E0H4Y0EptzP8kihEql24FsZAHOkVfZcxY1MmLb+EtrrLghZyq4lvFDiPtIPsTvjFzX jnVVrxN+/W4okELSiQ/d3m16/u3/7xqlDNphB3xWvIF8BaM/IX4aMrwN4iL9AvOyEtiP 02VA4k5+N+lRqWzdMBVveiLqyYJHZmSv64A9yNqacz0VpoVG58tgDorfBikCfh9hf7GG sXA0qAbAmAcL98M/x7feMkEaCxuEQHvXJWbQDY3/fqJqBEXymtuFyShs1xugC+65X+hc C5R/nr6D3flz8QNHeXTrKjYreP6WjmIfbY0Gc+MtjxIVLQE3kLnwrFstRjcMDJUtbw1b VUgA== X-Gm-Message-State: AOAM530BZ9zimh5JMuo030b5X+yM77fRE2o9iAxjK/+4GwU0I3o7i1ZV DsQaYbxdQuU7OHTx5XQeVJsbTAOICnWdNg64qoM= X-Google-Smtp-Source: ABdhPJxQ1nne3/ZlrNCgrIH3NY3w0By0sPYuXQJq11w9+YX49RSRqq71lXA5aLdo2F2fcsDiRAWLzU8Fif4ChXjlqBw= X-Received: by 2002:a2e:9844:: with SMTP id e4mr22676708ljj.413.1634450703533; Sat, 16 Oct 2021 23:05:03 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <6baed9dc-36c6-720b-0a73-0af7f062cb6a@gmail.com> In-Reply-To: From: Brian Carpenter Date: Sun, 17 Oct 2021 19:04:51 +1300 Message-ID: To: Mark Smith Cc: "Francois Clad (fclad)" , Erik Kline , SPRING WG List , 6man WG Content-Type: multipart/alternative; boundary="000000000000964b7905ce8635d2" Archived-At: Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 17 Oct 2021 06:05:12 -0000 --000000000000964b7905ce8635d2 Content-Type: text/plain; charset="UTF-8" Ah, thanks, that's the sort of thing you can only know by knowing it :-). Ok, so my question about the examples supplied stands. Using this as a source address has interesting implications. Regards, Brian Carpenter (via tiny screen & keyboard) On Sun, 17 Oct 2021, 18:58 Mark Smith, wrote: > On Sun, 17 Oct 2021 at 11:32, Brian E Carpenter > wrote: > > > > Thanks for this draft. > > > > Question: where you show "Source address 2001:db8:a:1100::" is that > intended to be the complete address, because it looks like a prefix? I > can't find anywhere that an interface identifier of zero is forbidden, but > it's unusual, and can only exist once in a given subnet. > > > > The IID value of all zeros is the subnet-router anycast address within > a subnet, and is required. See 2.6.1 of RFC4291. > > For example, Linux automatically configures the subnet-router anycast > address for all prefixes on an interface if the interface is a > forwarding interface. > > [mark@opy ~]$ ip -6 route show table local | grep anycast > anycast 2403:5803:XXXX:: dev wlp3s0 proto kernel metric 0 pref medium > anycast fe80:: dev wlp3s0 proto kernel metric 0 pref medium > [mark@opy ~]$ > > (The "local" route table is where the interface address and multicast > route route table entries are kept in Linux. They don't all show up > via the normal 'ip addr show' or 'ifconfig' commands). > > Regards, > Mark. > > > > Regards > > Brian Carpenter > > > > On 16-Oct-21 10:55, Francois Clad (fclad) wrote: > > > Hello Erik, > > > > > > > > > > > > You may find some examples here: > https://datatracker.ietf.org/doc/draft-clad-spring-srv6-srh-compression-illus/ > < > https://datatracker.ietf.org/doc/draft-clad-spring-srv6-srh-compression-illus/ > > > > > > > > > > > > > > Hope this helps. > > > > > > > > > > > > Thanks, > > > > > > Francois > > > > > > > > > > > > *From: *spring on behalf of Erik Kline < > ek.ietf@gmail.com> > > > *Date: *Thursday, 14 October 2021 at 19:06 > > > *To: *Joel M. Halpern > > > *Cc: *spring@ietf.org , ipv6@ietf.org > > > *Subject: *Re: [spring] Question from SPRING regarding > draft-filsfilscheng-spring-srv6-srh-compression > > > > > > Joel, > > > > > > > > > > > > Thank you for your email. The ADs and chairs have been discussing. > > > > > > > > > > > > One thing that would be very helpful to our discussions would be some > worked examples of the various C-SID behaviors, showing some SRv6 datagrams > and what happens to their contents as they move across some suitable > example SR domain. > > > > > > > > > > > > (It would also be helpful if they showed what happens to something like > > an ICMPv6 Echo Request to a representative Destination Address in these > cases when, say, an SRH is not present, i.e. to see when typical unicast > semantics are preserved or when something more like anycast or multicast > behavior is to be expected.) > > > > > > > > > > > > Assuming some forthcoming helpful examples, we have a goal to get a > more complete answer back to you by the latter half of next week. > > > > > > > > > > > > Thanks, > > > > > > -Erik > > > > > > > > > > > > On Tue, Oct 12, 2021 at 8:53 PM Joel M. Halpern > wrote: > > > > > > The SPRING working group is in the midst of an adoption call on > > > > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > < > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > >. > > > > > > The SPRING charter has text that is explicit that modifications to > data > > > planes and architectures standardized by other working groups may > not be > > > modified in SPRING unless the chairs and ADs responsible for that > data > > > plane and / or architecture agree. > > > > > > To complete the context, as my SPRING co-chairs are co-authors on > the > > > document in question, they have recused themselves from decisional > > > activities regarding the document. Therefore, this message is > > coming > > > just from my as the responsible SPRING co-chair managing this > adoption call. > > > > > > As you have seen, multiple questions have been raised about the > > > relationship of the document to the IPv6 defined data plane and > > > architecture (particularly RFC 4291 and 8200). In particular the > > > questions seem to revolve around what the document describes as the > > > NEXT-C-SID flavor of compressed SID, and its relationship to the > IPv6 > > > standards. (For those seeking more context without reading the > full > > > document, a paraphrase and simplification of the NEXT-C_SID flavor > is > > > provided as a postscript.) > > > > > > I raised the question of concurrence as required by the SPRING > charter > > > with the Internet ADs and SPRING chairs. They quite reasonably > asked me > > > to write a note to 6man explaining the concerns as clearly as a > can, so > > > that they can then determine how to proceed. > > > > > > The questions that prompted my inquiry are: > > > > > > 1) Does the placement of a list of sids in the IPv6 DA field change > > the > > > IPv6 architectural description of that field. > > > 2) Does the operation of shifting information around in the IPv6 > > > destination address field represent a modification or extension of > the > > > IPv6 data plane. > > > > > > On a related note, the document in question also defines two other > > > flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The > > > NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID > > > flavor operation, so seems to be affected by the same question. > > > > > > From my own reading, it appears that the REPLACE-C-SID flavor > > does not > > > raise issues requiring 6man leadership concurrence. > > > > > > Yours, > > > Joel M. Halpern for the SPRING working group > > > > > > > > > PS: > > > Clearly, understanding the question requires some understanding of > what > > > the NEXT-C_SID flavor does. This explanation is a simplification > for > > > length and context. Really, the best place to understand it is the > > > draft. However, to give you enough information to let you decide > > > whether you care, I will try to provide a fair summary. My > apologies in > > > advance to the authors for necessary liberties for length. Also, > > > discussion of the draft contents (as distinct from the interaction > with > > > the IPv6 data plane and architecture) belongs on the SPRING list, > and > > > should not clutter up 6man. > > > > > > SIDs are the identifiers used in segment routing. > > > In SRv6, as document in the current RFCs, these are 128 bits. > > As > > > defined in the relevant RFCs, SIDs which identify endpoints to > which > > > packets are directed are identified by endpoint SIDs. These can > have > > > behaviors (decapsulate and forward is one example). They can have > > > flavors such as where the SRH is removed. > > > > > > The topic under discussion is means to compress these SIDs in the > > > packets on the wire. The document under discussion provides three > > > flavors of compression. > > > > > > The fundamental mechanism of the draft is to use a single SRH entry > > as a > > > container for multiple SIDs. In the NEXT-C_SID mechanism, when it > is > > > first encountered the entire container is copied into the > desination > > > address of the IPv6 packet. The container has a common routing > prefix > > > used for all the NEXT-C-SID SIDs. It is followed by a sequence of > > > compressed SIDs of a configured length. One could configure 16, > 24, or > > > 32 bits. Or whatever length. The routing advertisements > > are arranged > > > so that the IPv6 packet is directed to the node represented by the > first > > > compressed SID on the basis of longest prefix match matching the > > > combination of the common routing prefix and that compressed SID. > > > > > > When the packet arrives at that node, it looks up the configured > > > portion, the compressed SID, and determines the behavior and > flavor. In > > > the case of the NEXT-C-SID flavor, the resulting operation is to > shift > > > the entire remaining contents of the IPv6 address (the bits past > the > > > first compressed sid) so as to over-write the first compressed > SID. 0 > > > bits are shifted into the low order positions. If the result is a > > > non-zero new first compressed SID, then the packets is forwarded > and the > > > process repeats. When all that is left are 0s, if there is an > > SRH, it > > > is consulted to find the next SRH entry, which is, per normal SRv6 > > > processing, put into the IPv6 DA. > > > Note that in the common case where the SIDS needed all fit in to a > > > single container, the analysis also assumes the use of the reduced > > > encapsulation options which omits the SRH that is not needed as it > would > > > have no entries. This the packet contains a normal IPv6 header, > with a > > > sequence of compressed SIDs (what one might or might not call a > source > > > route) in the IPv6 destination address field. > > > > > > PPS: If the authors of the NEXT-C-SID flavor feel I have > mis-represented > > > the work, please, send clarifications or corrections. Again, the > best > > > source of information is the draft itself. I was asked to provide > extra > > > context in this email. > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org > > > https://www.ietf.org/mailman/listinfo/spring < > https://www.ietf.org/mailman/listinfo/spring> > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > --000000000000964b7905ce8635d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Ah, thanks, that's the sort of thing you can only kno= w by knowing it :-). Ok, so my question about the examples supplied stands.= Using this as a source address has interesting implications.

    Regards,
    =C2=A0=C2=A0=C2=A0 Brian Carp= enter
    =C2=A0=C2=A0=C2=A0 (via tiny screen & keyboard)
    On Sun, 1= 7 Oct 2021, 18:58 Mark Smith, <markzzzsmith@gmail.com> wrote:
    On Sun, 17 Oct 2021 at 11:32, Brian E Carpenter
    <brian.e.carpenter@gmail.com> wrote:
    >
    > Thanks for this draft.
    >
    > Question: where you show "Source address 2001:db8:a:1100::" = is that intended to be the complete address, because it looks like a prefix= ? I can't find anywhere that an interface identifier of zero is forbidd= en, but it's unusual, and can only exist once in a given subnet.
    >

    The IID value of all zeros is the subnet-router anycast address within
    a subnet, and is required. See 2.6.1 of RFC4291.

    For example, Linux automatically configures the subnet-router anycast
    address for all prefixes on an interface if the interface is a
    forwarding interface.

    [mark@opy ~]$ ip -6 route show table local | grep anycast
    anycast 2403:5803:XXXX:: dev wlp3s0 proto kernel metric 0 pref medium
    anycast fe80:: dev wlp3s0 proto kernel metric 0 pref medium
    [mark@opy ~]$

    (The "local" route table is where the interface address and multi= cast
    route route table entries are kept in Linux. They don't all show up
    via the normal 'ip addr show' or 'ifconfig' commands).

    Regards,
    Mark.


    > Regards
    >=C2=A0 =C2=A0 Brian Carpenter
    >
    > On 16-Oct-21 10:55, Francois Clad (fclad) wrote:
    > > Hello Erik,
    > >
    > >
    > >
    > > You may find some examples here: https://datatracker.ietf.org/doc/draft-clad= -spring-srv6-srh-compression-illus/ <https://datatracker.ietf.org/doc/draft-cla= d-spring-srv6-srh-compression-illus/>
    > >
    > >
    > >
    > > Hope this helps.
    > >
    > >
    > >
    > > Thanks,
    > >
    > > Francois
    > >
    > >
    > >
    > > *From: *spring <spring-bounces@ietf.org> on behalf= of Erik Kline <ek.ietf@gmail.com>
    > > *Date: *Thursday, 14 October 2021 at 19:06
    > > *To: *Joel M. Halpern <jmh@joelhalpern.com>
    > > *Cc: *spring@ietf.org <spring@ietf.org>, ipv6@ietf.org <= ;ipv6= @ietf.org>
    > > *Subject: *Re: [spring] Question from SPRING regarding draft-fils= filscheng-spring-srv6-srh-compression
    > >
    > > Joel,
    > >
    > >
    > >
    > > Thank you for your email.=C2=A0 The ADs and chairs have been disc= ussing.
    > >
    > >
    > >
    > > One thing that would be very helpful to our discussions would be = some worked examples of the various C-SID behaviors, showing some SRv6 data= grams and what happens to their contents as they move across some suitable = example SR domain.
    > >
    > >
    > >
    > > (It would also be helpful if they showed what happens to somethin= g like
    > an ICMPv6 Echo Request to a representative Destination Address in thes= e cases when, say, an SRH is not present, i.e. to see when typical unicast = semantics are preserved or when something more like anycast or multicast be= havior is to be expected.)
    > >
    > >
    > >
    > > Assuming some forthcoming helpful examples, we have a goal to get= a more complete answer back to you by the latter half of next week.
    > >
    > >
    > >
    > > Thanks,
    > >
    > > -Erik
    > >
    > >
    > >
    > > On Tue, Oct 12, 2021 at 8:53 PM Joel M. Halpern <jmh@joelhalp= ern.com <mailto:jmh@joelhalpern.com>> wrote:
    > >
    > >=C2=A0 =C2=A0 =C2=A0The SPRING working group is in the midst of an= adoption call on
    > >=C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-filsfilscheng-s= pring-srv6-srh-compression/ <https://datatracker.ietf.org/doc/draft-filsfils= cheng-spring-srv6-srh-compression/>.
    > >
    > >=C2=A0 =C2=A0 =C2=A0The SPRING charter has text that is explicit t= hat modifications to data
    > >=C2=A0 =C2=A0 =C2=A0planes and architectures standardized by other= working groups may not be
    > >=C2=A0 =C2=A0 =C2=A0modified in SPRING unless the chairs and ADs r= esponsible for that data
    > >=C2=A0 =C2=A0 =C2=A0plane and / or architecture agree.
    > >
    > >=C2=A0 =C2=A0 =C2=A0To complete the context, as my SPRING co-chair= s are co-authors on the
    > >=C2=A0 =C2=A0 =C2=A0document in question, they have recused themse= lves from decisional
    > >=C2=A0 =C2=A0 =C2=A0activities regarding the document.=C2=A0 There= fore, this message is
    > coming
    > >=C2=A0 =C2=A0 =C2=A0just from my as the responsible SPRING co-chai= r managing this adoption call.
    > >
    > >=C2=A0 =C2=A0 =C2=A0As you have seen, multiple questions have been= raised about the
    > >=C2=A0 =C2=A0 =C2=A0relationship of the document to the IPv6 defin= ed data plane and
    > >=C2=A0 =C2=A0 =C2=A0architecture (particularly RFC 4291 and 8200).= In particular the
    > >=C2=A0 =C2=A0 =C2=A0questions seem to revolve around what the docu= ment describes as the
    > >=C2=A0 =C2=A0 =C2=A0NEXT-C-SID flavor of compressed SID, and its r= elationship to the IPv6
    > >=C2=A0 =C2=A0 =C2=A0standards.=C2=A0 (For those seeking more conte= xt without reading the full
    > >=C2=A0 =C2=A0 =C2=A0document, a paraphrase and simplification of t= he NEXT-C_SID flavor is
    > >=C2=A0 =C2=A0 =C2=A0provided as a postscript.)
    > >
    > >=C2=A0 =C2=A0 =C2=A0I raised the question of concurrence as requir= ed by the SPRING charter
    > >=C2=A0 =C2=A0 =C2=A0with the Internet ADs and SPRING chairs.=C2=A0= They quite reasonably asked me
    > >=C2=A0 =C2=A0 =C2=A0to write a note to 6man explaining the concern= s as clearly as a can, so
    > >=C2=A0 =C2=A0 =C2=A0that they can then determine how to proceed. > >
    > >=C2=A0 =C2=A0 =C2=A0The questions that prompted my inquiry are: > >
    > >=C2=A0 =C2=A0 =C2=A01) Does the placement of a list of sids in the= IPv6 DA field change
    > the
    > >=C2=A0 =C2=A0 =C2=A0IPv6 architectural description of that field.<= br> > >=C2=A0 =C2=A0 =C2=A02) Does the operation of shifting information = around in the IPv6
    > >=C2=A0 =C2=A0 =C2=A0destination address field represent a modifica= tion or extension of the
    > >=C2=A0 =C2=A0 =C2=A0IPv6 data plane.
    > >
    > >=C2=A0 =C2=A0 =C2=A0On a related note, the document in question al= so defines two other
    > >=C2=A0 =C2=A0 =C2=A0flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C= -SID.=C2=A0 The
    > >=C2=A0 =C2=A0 =C2=A0NEXT-and-REPLACE-C_SID flavor is defined to in= clude the NEXT-C_SID
    > >=C2=A0 =C2=A0 =C2=A0flavor operation, so seems to be affected by t= he same question.
    > >
    > >=C2=A0 =C2=A0 =C2=A0 From my own reading, it appears that the REPL= ACE-C-SID flavor
    > does not
    > >=C2=A0 =C2=A0 =C2=A0raise issues requiring 6man leadership concurr= ence.
    > >
    > >=C2=A0 =C2=A0 =C2=A0Yours,
    > >=C2=A0 =C2=A0 =C2=A0Joel M. Halpern for the SPRING working group > >
    > >
    > >=C2=A0 =C2=A0 =C2=A0PS:
    > >=C2=A0 =C2=A0 =C2=A0Clearly, understanding the question requires s= ome understanding of what
    > >=C2=A0 =C2=A0 =C2=A0the NEXT-C_SID flavor does.=C2=A0 =C2=A0This e= xplanation is a simplification for
    > >=C2=A0 =C2=A0 =C2=A0length and context.=C2=A0 Really, the best pla= ce to understand it is the
    > >=C2=A0 =C2=A0 =C2=A0draft.=C2=A0 However, to give you enough infor= mation to let you decide
    > >=C2=A0 =C2=A0 =C2=A0whether you care, I will try to provide a fair= summary.=C2=A0 My apologies in
    > >=C2=A0 =C2=A0 =C2=A0advance to the authors for necessary liberties= for length.=C2=A0 Also,
    > >=C2=A0 =C2=A0 =C2=A0discussion of the draft contents (as distinct = from the interaction with
    > >=C2=A0 =C2=A0 =C2=A0the IPv6 data plane and architecture) belongs = on the SPRING list, and
    > >=C2=A0 =C2=A0 =C2=A0should not clutter up 6man.
    > >
    > >=C2=A0 =C2=A0 =C2=A0SIDs are the identifiers used in segment routi= ng.
    > >=C2=A0 =C2=A0 =C2=A0In SRv6, as document in the current RFCs, thes= e are 128 bits.
    >=C2=A0 As
    > >=C2=A0 =C2=A0 =C2=A0defined in the relevant RFCs, SIDs which ident= ify endpoints to which
    > >=C2=A0 =C2=A0 =C2=A0packets are directed are identified by endpoin= t SIDs.=C2=A0 These can have
    > >=C2=A0 =C2=A0 =C2=A0behaviors (decapsulate and forward is one exam= ple).=C2=A0 They can have
    > >=C2=A0 =C2=A0 =C2=A0flavors such as where the SRH is removed.
    > >
    > >=C2=A0 =C2=A0 =C2=A0The topic under discussion is means to compres= s these SIDs in the
    > >=C2=A0 =C2=A0 =C2=A0packets on the wire.=C2=A0 The document under = discussion provides three
    > >=C2=A0 =C2=A0 =C2=A0flavors of compression.
    > >
    > >=C2=A0 =C2=A0 =C2=A0The fundamental mechanism of the draft is to u= se a single SRH entry
    > as a
    > >=C2=A0 =C2=A0 =C2=A0container for multiple SIDs.=C2=A0 In the NEXT= -C_SID mechanism, when it is
    > >=C2=A0 =C2=A0 =C2=A0first encountered the entire container is copi= ed into the desination
    > >=C2=A0 =C2=A0 =C2=A0address of the IPv6 packet.=C2=A0 The containe= r has a common routing prefix
    > >=C2=A0 =C2=A0 =C2=A0used for all the NEXT-C-SID SIDs.=C2=A0 It is = followed by a sequence of
    > >=C2=A0 =C2=A0 =C2=A0compressed SIDs of a configured length.=C2=A0 = One could configure 16, 24, or
    > >=C2=A0 =C2=A0 =C2=A032 bits.=C2=A0 Or whatever length.=C2=A0 The r= outing advertisements
    > are arranged
    > >=C2=A0 =C2=A0 =C2=A0so that the IPv6 packet is directed to the nod= e represented by the first
    > >=C2=A0 =C2=A0 =C2=A0compressed SID on the basis of longest prefix = match matching the
    > >=C2=A0 =C2=A0 =C2=A0combination of the common routing prefix and t= hat compressed SID.
    > >
    > >=C2=A0 =C2=A0 =C2=A0When the packet arrives at that node, it looks= up the configured
    > >=C2=A0 =C2=A0 =C2=A0portion, the compressed SID, and determines th= e behavior and flavor.=C2=A0 In
    > >=C2=A0 =C2=A0 =C2=A0the case of the NEXT-C-SID flavor, the resulti= ng operation is to shift
    > >=C2=A0 =C2=A0 =C2=A0the entire remaining contents of the IPv6 addr= ess (the bits past the
    > >=C2=A0 =C2=A0 =C2=A0first compressed sid) so as to over-write the = first compressed SID.=C2=A0 0
    > >=C2=A0 =C2=A0 =C2=A0bits are shifted into the low order positions.= =C2=A0 If the result is a
    > >=C2=A0 =C2=A0 =C2=A0non-zero new first compressed SID, then the pa= ckets is forwarded and the
    > >=C2=A0 =C2=A0 =C2=A0process repeats.=C2=A0 When all that is left a= re 0s, if there is an
    > SRH, it
    > >=C2=A0 =C2=A0 =C2=A0is consulted to find the next SRH entry, which= is, per normal SRv6
    > >=C2=A0 =C2=A0 =C2=A0processing, put into the IPv6 DA.
    > >=C2=A0 =C2=A0 =C2=A0Note that in the common case where the SIDS ne= eded all fit in to a
    > >=C2=A0 =C2=A0 =C2=A0single container, the analysis also assumes th= e use of the reduced
    > >=C2=A0 =C2=A0 =C2=A0encapsulation options which omits the SRH that= is not needed as it would
    > >=C2=A0 =C2=A0 =C2=A0have no entries.=C2=A0 This the packet contain= s a normal IPv6 header, with a
    > >=C2=A0 =C2=A0 =C2=A0sequence of compressed SIDs (what one might or= might not call a source
    > >=C2=A0 =C2=A0 =C2=A0route) in the IPv6 destination address field.<= br> > >
    > >=C2=A0 =C2=A0 =C2=A0PPS: If the authors of the NEXT-C-SID flavor f= eel I have mis-represented
    > >=C2=A0 =C2=A0 =C2=A0the work, please, send clarifications or corre= ctions.=C2=A0 =C2=A0Again, the best
    > >=C2=A0 =C2=A0 =C2=A0source of information is the draft itself.=C2= =A0 I was asked to provide extra
    > >=C2=A0 =C2=A0 =C2=A0context in this email.
    > >
    > >=C2=A0 =C2=A0 =C2=A0______________________________________________= _
    > >=C2=A0 =C2=A0 =C2=A0spring mailing list
    > >=C2=A0 =C2=A0 =C2=A0spring@ietf.org <mailto:spring@ietf.org&g= t;
    > >=C2=A0 =C2=A0 =C2=A0https://www.ietf= .org/mailman/listinfo/spring <https://= www.ietf.org/mailman/listinfo/spring>
    > >
    > >
    > > -----------------------------------------------------------------= ---
    > > IETF IPv6 working group mailing list
    > > ipv6@ietf.org
    > > Administrative Requests: https://www.= ietf.org/mailman/listinfo/ipv6
    > > -----------------------------------------------------------------= ---
    > >
    >
    > _______________________________________________
    > spring mailing list
    > spring@ietf.org
    > https://www.ietf.org/mailman/listinfo/sp= ring
    --000000000000964b7905ce8635d2-- From nobody Sun Oct 17 08:25:38 2021 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 95B763A08E2 for ; Sun, 17 Oct 2021 08:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ju1WsZv7QkGA for ; Sun, 17 Oct 2021 08:25:31 -0700 (PDT) Received: from NAM12-BN8-obe.outbound.protection.outlook.com (mail-bn8nam12on2110.outbound.protection.outlook.com [40.107.237.110]) (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 C667E3A08DE for ; Sun, 17 Oct 2021 08:25:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DrdpkrUcqqb8xlFd2OGAdhUEMxSNbZ0xxq7IFgAaUhRcd9zg0UVpcqhiA2QwRZbqk6NWqWMcdonqC39YoW91Rj88rnn7iO7GLT+gO5ZssN/ZnOWnicXHMm3CgEpk8j8ohuZl/RpULZm7BNv2lSdOY5+owIW+eG4ZGyjOPXrIa3p2nnH3vDNOw2TAl1QqlQaylJUhUe3kK+AXq1rcfc9xPe4jCPoAgMYVYrhJcyEYPOViFVg+eWUsV7PFYOfbdouZ8NpJrs09eu8ynKjEFyVNm3mVLCaM+7t9PcDbxTR3Q1OOMwBo4MZVmx75j1tZfLdloeQJTBE5IuNT/laMeMpoVA== 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=pe/zsP5+Xs20e9ItqYgqveOsqfV0MWnlwTlbvrXtFGk=; b=Lks4b98LwEG6lOM9HH6M+bHR0+QC0Nzl9KJBHp7iks4FfaU3ClE5aRn56QwxWW5WUeSREj7j+Yqn2B7rB9/dyjyFkveYaaAtwopWLq3wXDE6IvK5pWtL+yYc67kVBXZAGMzeNjEciETv9Bx939axAJ4i5wJkrzH9bWEfvXyjUcUKdTZloY6blnExfKIbxAQRDXG582l0k3iybh2FTHhjJhpOxvglluBQJs7hNM8Nqg5/7oc2x11UhfAo4+z8JVQnZ/9ZJLY61FJ3Q3VU4wDyrhr+9F+DJflKZ1MxMZ6Xoee9pR1koLaE130651yGfUTxNTpOvyuW6dc+DyDXRDlnrQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=futurewei.com; dmarc=pass action=none header.from=futurewei.com; dkim=pass header.d=futurewei.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pe/zsP5+Xs20e9ItqYgqveOsqfV0MWnlwTlbvrXtFGk=; b=tPWKY7tBabXonsyTk3j86HjTCcM8W4aopY9LlczoKZ9OIfSLEWfcPrrdR0Nj+6zzxaqPSNEz/cxaKaICldNHL4K83LYHbBvgxkXvP1UkNlEauRMW6BoO/MsqxVDF5TLEkrg+ikmfoODcMpBOTLe2D0nbhlxNSfBNugPB+hTpYiM= Received: from BY3PR13MB5044.namprd13.prod.outlook.com (2603:10b6:a03:362::22) by BYAPR13MB2565.namprd13.prod.outlook.com (2603:10b6:a02:cc::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.10; Sun, 17 Oct 2021 15:25:26 +0000 Received: from BY3PR13MB5044.namprd13.prod.outlook.com ([fe80::2480:c433:fd3d:7357]) by BY3PR13MB5044.namprd13.prod.outlook.com ([fe80::2480:c433:fd3d:7357%7]) with mapi id 15.20.4628.013; Sun, 17 Oct 2021 15:25:26 +0000 From: Huaimo Chen To: "spring@ietf.org" Thread-Topic: draft-ietf-rtgwg-srv6-egress-protection-04 Thread-Index: AQHXw2s131Ao8V9rH0OanWMcsNLF6g== Date: Sun, 17 Oct 2021 15:25:25 +0000 Message-ID: References: <163448363730.5618.3428281894934206128@ietfa.amsl.com> In-Reply-To: <163448363730.5618.3428281894934206128@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: e5271257-ed18-2159-fc4e-fa9fc2b9f9cf authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=futurewei.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8fd156b7-4067-4a89-c6e5-08d991825833 x-ms-traffictypediagnostic: BYAPR13MB2565: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3826; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /PO8u9s/EDI5n1LjuphZET2Qyckhe9rlCihFLh4yPw5xoAEM7g6ksQHyFosvnA7e0Bkro6RzDU9yQidw8pzl+w7u/rQWVNKG5gqfPkO7YyHmRUReBMnlxRilXsAP9YLow5VEI5ZVS82iZvVHeFRIXsmKm0DXdckmqlr9g6pwvnW1HHlq/EEiLH8dd0QqJ4G4hHC1BETbDZb35keLYQ4rk56Mohpt74PsKdj8dfYuKS1TwJ0NFNj7Lc3rkoYb7HxqUocchBPvLKXg3i7x+MasRgAn/NKnxzY2PluNj5NNk6A2yW8U5ktaAe46ZqO41m+zvoBQ7644lJ+WPV63e6Bi9fsugaU9X/ety1SBsQrK4pXXe+hM/9MWJzl8mJPzmeFFI4aiifP35pk/uTKnN9AxU/6JfMfhAbfbezbR6+RtuAomhu9W5EMsnCLcNCg8+1QuEy4g2BeB1JtXwU+F2+O+4/+zyxPUmTN3H4PtMNKlKnclzoBToTnhvoCOjxG/vTZhvSnRvtivHdTxUMcSStboIuThxKVXgrnc5FIfSTezX0fpO1vXtgThFe6Hs35s+hhj6WVveDOEQqr3yFD+2mTwCs8HfKV4VcJemkSlkaXvRv7B9YDyY8b2IcZhc71YaLgmS0hsmtgNfvHVlPiU+Odf0iAXXi8RuBHKbvphQ+Twz0AQuzNag4R00/bM3cC72xzquqrfcWqP/ilHrB3p9nBidFkTfcaLpf0XxBslWuPqTksCE02mGiV45ISPgf5e2Bnw1RulNyuensHH/HzVvDwPY5wZy8gDnRgCJiq4YkCGHOwnVqSRyGXo1XpTQi2sLHw2tI3RjzgbVg3nDSuXro8wZA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR13MB5044.namprd13.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(38070700005)(38100700002)(2906002)(122000001)(76116006)(33656002)(4001150100001)(86362001)(53546011)(5660300002)(8676002)(7696005)(9686003)(83380400001)(66574015)(6506007)(8936002)(186003)(166002)(52536014)(55016002)(45080400002)(966005)(66946007)(6916009)(66446008)(64756008)(71200400001)(91956017)(44832011)(19627405001)(66476007)(508600001)(66556008); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?gb2312?B?SU5tbmZFNGJnam9MSk15Wm00WEVwUUtvUU81Mk8zajNLTHI2bVJvRmoxdkN0?= =?gb2312?B?ams2Kzg5RFNMT2ZWc2FUc0hPTTRhVmZsdGJxa2VjcHBuNlNrS2VyMStHc1po?= =?gb2312?B?cW5QUG9sb3VULzArQ1pYVUZHdk43UFBPWWZ2WGdFd2RnVzJjWUxTYjIrbW9V?= =?gb2312?B?NVpCSDBBZUlLa0tqblMrQTBjWlFHMGRTMFhxYVFBNTlieWx4V09ST0ttVnFM?= =?gb2312?B?UUttTU9aWFNJdjJWaTFSZW9IN1JmVDVzTTZhUXV3aS9OSEkvV0NRNnZmTThK?= =?gb2312?B?b0w4RE1od2lUN2l3RXRwQXYrN2tiM1d5L2FaUCtUQVIrRGl2QW40c3prcm5U?= =?gb2312?B?OUoxQ09LZWMxV2RzQzlvcUxueHJwWGxKKzc4bGxISGhXTCt2T0xEZWhBZURy?= =?gb2312?B?THk3eVZ0UWdqUVV5WDFFQzA3YUdHcUliZVhaZ0RNdlhNYy9nN1lrZXVFTVVM?= =?gb2312?B?UWU4Tk41UkxMMkpIVmVzUWxibmtRTWUxUzU3Sk1YN0kveFptZGVtQkhsTXlY?= =?gb2312?B?MlEyOWVqZUZOTFJ3NXRhYUhid1dia3ZHRUtYRFcrN2ZidE9wNi90WjV4c1FC?= =?gb2312?B?T3VXa0kzdGd2dWcvNFRyNDJWWEpvMm1Pekdjb3NybmJLSFN1LzUxUGRrK2k5?= =?gb2312?B?THhSZjd0Q0pSdjIreEJ1d2h1NmJGTDh4L2ZtaVRLYnVqSnZRVVZFQlVZcU9V?= =?gb2312?B?eXVNZmdic0pVQnVwQStmUXpCWGZzOTRDY3VRZzExbHVZejhSdDZiYithY1lu?= =?gb2312?B?cExQdWpUalVHbjFJL25Odm4rV25kQUNEdThLMnI1elpvdFZQOXZpRHdQdWF2?= =?gb2312?B?djJ4UHRmdWE1aWtiZWxvQlYrM0lGYUdjSXZDRkVNVE1Ka0dvbERSZlRjY3VI?= =?gb2312?B?RU9manpVazZOZHZUeFpzY20rdzVQL0s4aS96MDlleDVJVHlIanExRVEwdzR1?= =?gb2312?B?bkw3S0pOd05hN0N1K0pobm45b0pqU21yamdudFMxNXhQa0tDMlB3WXVRMUc2?= =?gb2312?B?WmNrLzVldEZvTXFnblhaS2lsM214OENQOHZSU0ZFVllHVjlBOVA5eGY0WlFW?= =?gb2312?B?M25pb3lDUytGZnFkNjVibjRoSUtveHNNTjZJeVBVNndQZjBSVDJvSUdvK1pn?= =?gb2312?B?bG1FZWp0MXc3WkVKc3dPaDRwMWV5RHZnWEZDMFdFRmo4NW1iSWVYbnJidHhK?= =?gb2312?B?NXFRcnJSbm9raEV2c1RoM2FRdTJUamMrRGtQa3l6S2VMR0VibFFrMjVGeWR5?= =?gb2312?B?dFlQbWJXUzVvSkhudXowTGpac1VBcitBSktpYXNLVS85UGZyd0NrS0tyV1hU?= =?gb2312?B?QjQ0S1B3Y0krOGZwSTRUcXVaNGlBaTZibDFQcm41RlZxd0ZoQlEyOExnZ0xL?= =?gb2312?B?RzBxbXpqeFBIaVlhZGtJdUtKczVZTGhSSlJNSmZVUXdkQkdtYUlTbmJYTmVO?= =?gb2312?B?QVpJcmxnUGRsZ0IwMTlnWU1FQ1M5eVNyeE1pWlBMdjdxR2JGYitVdWdMaDlk?= =?gb2312?B?dWgrSEJjQ1o0eUwzRVJCUlRRWEc4UHAwcUU0UlFIUWw3Tk85UFJ1UEs0TTRZ?= =?gb2312?B?MVhmM2tjK0J1NnBLUnRBODBlUGhOU2tXTDF2TDg4V0h2REFnNTNDLzhuWlNv?= =?gb2312?B?RXhpaXhZbDRrRGxhRmFQclNtc0d1S1NTRDZIM0E3elo3L3gzbTF5aG9QcXlT?= =?gb2312?B?L2UvUEl1TDJRRjlqNXdud0NtOEZISkVDdlcyOHg0ZWx5cjR5NjNlcWtJSGJn?= =?gb2312?B?NDlNL3dRWE5Qb2dUaHI5K3NoblFVTkRJREFjSVl3aVhEbHhrcm83NWVubHJW?= =?gb2312?B?WmpBMHluSER4RGJoQ1hHU2FvU0JuZjJjU0ozSWd0bmgrcE9mVzJ6VG1NVnR4?= =?gb2312?B?eDJLQmdGQW01VVAxSEZCSDJxd0pxd0N0K1BKOEZ3ckJ0dUtHNG9WSE1sR3JB?= =?gb2312?B?akN0OFIxbkNmRy9Pb2FVUFcxTlZ3U05DaWZqdG4wTjB6c0RHblBGTDBQRG5B?= =?gb2312?B?Z3lMbmNKUC81ZzVoM2JhMHFsQVJVTXRKaWVERytQT0g2MmNiWGFZWTFNV2JZ?= =?gb2312?B?QXRZeXRtUmJNWk1yM3Bsak5YbDFaT04xcnNKVmdRUlZvdTNZK043REhoOUtY?= =?gb2312?B?Wi85UVNJbHArSGVCcFFNMnNMcEJoTFYzNHFGQlZ0aEFFLzB0QlhmYXNJeU5V?= =?gb2312?B?eUp5WFhIVkVpcnUvVnJVeVlRbzE2U2R0WGNTaERia1RlUHFRQ1VWSUNhN3ov?= =?gb2312?B?dDBFaWdhNWdqU2RiTittYTdsK3pBPT0=?= Content-Type: multipart/alternative; boundary="_000_BY3PR13MB50446DD76E4FB0AA061D3204F2BB9BY3PR13MB5044namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BY3PR13MB5044.namprd13.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8fd156b7-4067-4a89-c6e5-08d991825833 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2021 15:25:25.9955 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: kx67Tzvsfh+EsO4hwsKq+bDXzqZuE5ffwFnAywYjTkQ2U1FplCEKWUlHGVLnz4l/cUDycfpL8bK9iaWJaxmzsQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR13MB2565 Archived-At: Subject: [spring] draft-ietf-rtgwg-srv6-egress-protection-04 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, 17 Oct 2021 15:25:37 -0000 --_000_BY3PR13MB50446DD76E4FB0AA061D3204F2BB9BY3PR13MB5044namp_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgRXZlcnlvbmUsDQoNCiAgICBBIG5ldyB2ZXJzaW9uIG9mIGRyYWZ0LWlldGYtcnRnd2ctc3J2 Ni1lZ3Jlc3MtcHJvdGVjdGlvbiBpcyBzdWJtaXR0ZWQuDQogICAgQW55IGNvbW1lbnRzIGFuZCBz dWdnZXN0aW9ucyBhcmUgd2VsY29tZS4NCg0KQmVzdCBSZWdhcmRzLA0KSHVhaW1vDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQpTZW50OiBTdW5kYXksIE9jdG9iZXIgMTcsIDIw MjEgMTE6MTMgQU0NClRvOiBDaGFuZyBDYW8gPGNhb2MxNUBjaGluYXVuaWNvbS5jbj47IENoaW5h IFRlbGVjb20gPGNoZW5objguZ2RAY2hpbmF0ZWxlY29tLmNuPjsgSHVhaW1vIENoZW4gPGh1YWlt by5jaGVuQGZ1dHVyZXdlaS5jb20+OyBIdWFpbW8gQ2hlbiA8aHVhaW1vLmNoZW5AZnV0dXJld2Vp LmNvbT47IEh1YW5hbiBDaGVuIDxjaGVuaG44LmdkQGNoaW5hdGVsZWNvbS5jbj47IExlaSBMaXUg PGxpdWxlaS5rZGRpQGdtYWlsLmNvbT47IE1laG1ldCBUb3kgPG1laG1ldC50b3lAdmVyaXpvbi5j b20+OyDO4sX0KCAwMDI0NjQwMikgPGJhZ2dpby53dXBlbmdAaHVhd2VpLmNvbT47IFRhbyBIZSA8 aGV0MjFAY2hpbmF1bmljb20uY24+OyBYdWZlbmcgTGl1IDx4dWZlbmcubGl1LmlldGZAZ21haWwu Y29tPjsgWmhpYm8gSHUgPGh1emhpYm9AaHVhd2VpLmNvbT47IHJ0Z3dnLWNoYWlyc0BpZXRmLm9y ZyA8cnRnd2ctY2hhaXJzQGlldGYub3JnPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1pZXRmLXJ0Z3dnLXNydjYtZWdyZXNzLXByb3RlY3Rpb24tMDQudHh0DQoN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWlldGYtcnRnd2ctc3J2Ni1lZ3Jlc3MtcHJv dGVjdGlvbi0wNC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgSHVhaW1v IENoZW4gYW5kIHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTogICAgICAg ICAgIGRyYWZ0LWlldGYtcnRnd2ctc3J2Ni1lZ3Jlc3MtcHJvdGVjdGlvbg0KUmV2aXNpb246ICAg ICAgIDA0DQpUaXRsZTogICAgICAgICAgU1J2NiBQYXRoIEVncmVzcyBQcm90ZWN0aW9uDQpEb2N1 bWVudCBkYXRlOiAgMjAyMS0xMC0xNw0KR3JvdXA6ICAgICAgICAgIHJ0Z3dnDQpQYWdlczogICAg ICAgICAgMTkNClVSTDogICAgICAgICAgICBodHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZhcmNoaXZl JTJGaWQlMkZkcmFmdC1pZXRmLXJ0Z3dnLXNydjYtZWdyZXNzLXByb3RlY3Rpb24tMDQudHh0JmFt cDtkYXRhPTA0JTdDMDElN0NIdWFpbW8uY2hlbiU0MGZ1dHVyZXdlaS5jb20lN0M4NjFjNzdhMmQw Y2M0Y2JiZTdmYzA4ZDk5MTgwYmU1YSU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRj JTdDMSU3QzElN0M2Mzc3MDA4MDQ0MzQwNDI2NDUlN0NVbmtub3duJTdDVFdGcGJHWnNiM2Q4ZXlK V0lqb2lNQzR3TGpBd01EQWlMQ0pRSWpvaVYybHVNeklpTENKQlRpSTZJazFoYVd3aUxDSlhWQ0k2 TW4wJTNEJTdDMTAwMCZhbXA7c2RhdGE9JTJCZzBLYzRZZVhabGZZSEdJJTJGRWI2ZlMxTTNNSlNT bHNZcEY5ZzlZTWNidlElM0QmYW1wO3Jlc2VydmVkPTANClN0YXR1czogICAgICAgICBodHRwczov L25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYl MkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmRyYWZ0LWlldGYtcnRnd2ctc3J2Ni1lZ3Jl c3MtcHJvdGVjdGlvbiUyRiZhbXA7ZGF0YT0wNCU3QzAxJTdDSHVhaW1vLmNoZW4lNDBmdXR1cmV3 ZWkuY29tJTdDODYxYzc3YTJkMGNjNGNiYmU3ZmMwOGQ5OTE4MGJlNWElN0MwZmVlOGZmMmEzYjI0 MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MxJTdDNjM3NzAwODA0NDM0MDQyNjQ1JTdDVW5rbm93 biU3Q1RXRnBiR1pzYjNkOGV5SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJU aUk2SWsxaGFXd2lMQ0pYVkNJNk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRhPVFEZTV6cmNvYkZDWEIx ek83WjRVbjhYOGJ1aVlLMHpITnJ3NmN6VEVRVEUlM0QmYW1wO3Jlc2VydmVkPTANCkh0bWxpemVk OiAgICAgICBodHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91 cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFm dC1pZXRmLXJ0Z3dnLXNydjYtZWdyZXNzLXByb3RlY3Rpb24mYW1wO2RhdGE9MDQlN0MwMSU3Q0h1 YWltby5jaGVuJTQwZnV0dXJld2VpLmNvbSU3Qzg2MWM3N2EyZDBjYzRjYmJlN2ZjMDhkOTkxODBi ZTVhJTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMSU3QzYzNzcwMDgw NDQzNDA0MjY0NSU3Q1Vua25vd24lN0NUV0ZwYkdac2IzZDhleUpXSWpvaU1DNHdMakF3TURBaUxD SlFJam9pVjJsdU16SWlMQ0pCVGlJNklrMWhhV3dpTENKWFZDSTZNbjAlM0QlN0MxMDAwJmFtcDtz ZGF0YT0xckQ1ZTFySnJ2Z3VneVQ0SzQxJTJCRHU0b3JQZmZRTFJMcnQwVnlZQTZ6SGslM0QmYW1w O3Jlc2VydmVkPTANCkRpZmY6ICAgICAgICAgICBodHRwczovL25hbTExLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ3d3cuaWV0Zi5vcmclMkZyZmNk aWZmJTNGdXJsMiUzRGRyYWZ0LWlldGYtcnRnd2ctc3J2Ni1lZ3Jlc3MtcHJvdGVjdGlvbi0wNCZh bXA7ZGF0YT0wNCU3QzAxJTdDSHVhaW1vLmNoZW4lNDBmdXR1cmV3ZWkuY29tJTdDODYxYzc3YTJk MGNjNGNiYmU3ZmMwOGQ5OTE4MGJlNWElN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVk YyU3QzElN0MxJTdDNjM3NzAwODA0NDM0MDQyNjQ1JTdDVW5rbm93biU3Q1RXRnBiR1pzYjNkOGV5 SldJam9pTUM0d0xqQXdNREFpTENKUUlqb2lWMmx1TXpJaUxDSkJUaUk2SWsxaGFXd2lMQ0pYVkNJ Nk1uMCUzRCU3QzEwMDAmYW1wO3NkYXRhPXNReXFxbzEwOGNXb1FPMUJ0WGtuWTVtM1JqZ1BXV0V0 ZVFqY3Job2cxVG8lM0QmYW1wO3Jlc2VydmVkPTANCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3Vt ZW50IGRlc2NyaWJlcyBwcm90b2NvbCBleHRlbnNpb25zIGZvciBwcm90ZWN0aW5nIHRoZSBlZ3Jl c3MNCiAgIG5vZGUgb2YgYSBTZWdtZW50IFJvdXRpbmcgZm9yIElQdjYgKFNSdjYpIHBhdGggb3Ig dHVubmVsLg0KDQoNCg0KDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQo= --_000_BY3PR13MB50446DD76E4FB0AA061D3204F2BB9BY3PR13MB5044namp_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
    Hi Everyone,

        A new version of draft-ietf-rtgwg-srv6-egress-protection= is submitted.
        Any comments and suggestions are welcome.

    Best Regards,
    Huaimo
    From: internet-drafts@ietf.= org <internet-drafts@ietf.org>
    Sent: Sunday, October 17, 2021 11:13 AM
    To: Chang Cao <caoc15@chinaunicom.cn>; China Telecom <chenh= n8.gd@chinatelecom.cn>; Huaimo Chen <huaimo.chen@futurewei.com>; H= uaimo Chen <huaimo.chen@futurewei.com>; Huanan Chen <chenhn8.gd@ch= inatelecom.cn>; Lei Liu <liulei.kddi@gmail.com>; Mehmet Toy <mehmet.toy@verizon.com>; =CE=E2=C5=F4( 00246402) <baggio.wupeng@= huawei.com>; Tao He <het21@chinaunicom.cn>; Xufeng Liu <xufeng.= liu.ietf@gmail.com>; Zhibo Hu <huzhibo@huawei.com>; rtgwg-chairs@i= etf.org <rtgwg-chairs@ietf.org>
    Subject: New Version Notification for draft-ietf-rtgwg-srv6-egress-p= rotection-04.txt
     

    A new version of I-D, draft-ietf-rtgwg-srv6-egress-protection-04.txt
    has been successfully submitted by Huaimo Chen and posted to the
    IETF repository.

    Name:           draft-iet= f-rtgwg-srv6-egress-protection
    Revision:       04
    Title:          SRv6 Path Egre= ss Protection
    Document date:  2021-10-17
    Group:          rtgwg
    Pages:          19
    URL:            https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Farchive%2Fid%2Fdraft-ietf-rtgwg-srv6-egress-protection-04.txt&a= mp;data=3D04%7C01%7CHuaimo.chen%40futurewei.com%7C861c77a2d0cc4cbbe7fc08d99= 180be5a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637700804434042645%7CU= nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLC= JXVCI6Mn0%3D%7C1000&amp;sdata=3D%2Bg0Kc4YeXZlfYHGI%2FEb6fS1M3MJSSlsYpF9= g9YMcbvQ%3D&amp;reserved=3D0
    Status:         https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-ietf-rtgwg-srv6-egress-protection%2F&amp;da= ta=3D04%7C01%7CHuaimo.chen%40futurewei.com%7C861c77a2d0cc4cbbe7fc08d99180be= 5a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637700804434042645%7CUnknow= n%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI= 6Mn0%3D%7C1000&amp;sdata=3DQDe5zrcobFCXB1zO7Z4Un8X8buiYK0zHNrw6czTEQTE%= 3D&amp;reserved=3D0
    Htmlized:       https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-rtgwg-srv6-egress-protection&am= p;data=3D04%7C01%7CHuaimo.chen%40futurewei.com%7C861c77a2d0cc4cbbe7fc08d991= 80be5a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637700804434042645%7CUn= known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJ= XVCI6Mn0%3D%7C1000&amp;sdata=3D1rD5e1rJrvgugyT4K41%2BDu4orPffQLRLrt0VyY= A6zHk%3D&amp;reserved=3D0
    Diff:           https://nam11.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Frfcdiff%3Furl2%3Ddraft-ietf-rtgwg-srv6-egress-protection-04&amp= ;data=3D04%7C01%7CHuaimo.chen%40futurewei.com%7C861c77a2d0cc4cbbe7fc08d9918= 0be5a%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637700804434042645%7CUnk= nown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX= VCI6Mn0%3D%7C1000&amp;sdata=3DsQyqqo108cWoQO1BtXknY5m3RjgPWWEteQjcrhog1= To%3D&amp;reserved=3D0

    Abstract:
       This document describes protocol extensions for protecting the= egress
       node of a Segment Routing for IPv6 (SRv6) path or tunnel.



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


    The IETF Secretariat


    --_000_BY3PR13MB50446DD76E4FB0AA061D3204F2BB9BY3PR13MB5044namp_-- From nobody Sun Oct 17 13:19:57 2021 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 B01D63A0B30; Sun, 17 Oct 2021 13:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxDsIr2rdcgs; Sun, 17 Oct 2021 13:19:50 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA00D3A0B2A; Sun, 17 Oct 2021 13:19:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 68E6C182A5; Sun, 17 Oct 2021 16:20:17 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id G6itJQe7LXcy; Sun, 17 Oct 2021 16:20:17 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id EE0C2182A6; Sun, 17 Oct 2021 16:20:16 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 0CDD3527; Sun, 17 Oct 2021 16:19:47 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter , "Francois Clad \(fclad\)" , "spring\@ietf.org" , "ipv6\@ietf.org" In-Reply-To: <6c852ab5-141f-4fad-1223-1a6a9eda375e@gmail.com> References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <6baed9dc-36c6-720b-0a73-0af7f062cb6a@gmail.com> <6c852ab5-141f-4fad-1223-1a6a9eda375e@gmail.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 17 Oct 2021 20:19:54 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Brian E Carpenter wrote: >> I can't find anywhere that an interface identifier of zero is forbid= den > However, when I assign such an address to a Linux box, it is > unpingable, so I'm guessing it breaks neighbor discovery. If you put it on "eth0", it might break ND. If you put as a /128 address on lo, and arrange routing, then it works just fine. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmFshWIACgkQgItw+93Q 3WV4JAf9E1UXhwe/hPDxYoEvBwzzGz7xudedsGPY6XpPeurSzv+yO9E37M6JqwjI XgiKaBEAIMU5lvvD0zeMv67fAZEXaXBePnWx5yqNVUWBhSpvc5hjY/GYd6Mk5+z6 QihtT9PLqntDZH9T54AKsiaZA+m2fv6svojisHr2q1thobgG9YY/3kGoMVU0bxnm mHi1wsmLBVPQjWmBp/ry/7SegoMAd1WGQGiecoXX29kW0TDBEgr0I2SU+48T1iJT 24vWZ2Q5DiEXcWTPllTL0KeqP0F1BUiD5DjzlCNCWG7+cXKkMCgetY3SC1kY6Ye1 aZSaR9eCWx4XpZ1s0BhTmRaEcsLSuQ== =4eyy -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Oct 17 13:30:44 2021 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 EDD503A0BBD; Sun, 17 Oct 2021 13:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.595 X-Spam-Level: X-Spam-Status: No, score=-9.595 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, 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=e/tFO1Vk; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=LDZU01lA 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 DPe3IjLGc5o3; Sun, 17 Oct 2021 13:29:36 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90C0F3A0BC0; Sun, 17 Oct 2021 13:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30372; q=dns/txt; s=iport; t=1634502576; x=1635712176; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EM8IPxJq3HzUnRdzx7QzuJi7Nor1z9JSRRvze3UASGE=; b=e/tFO1VkjkzUDAtZIgqW28M3d+7Mf7NTzht7d6KW7icuEewzcQCXjQPk 7AZSy/9bUCKtdHV3gPwEECh/tC3SXfz5PKT6VQobBkmikuTSH68asqfb0 mQCdqa/KO5+oino2U/lit/azs8eYKortGcrYJVErgQVsQrZfBN9JPCYlz c=; IronPort-PHdr: =?us-ascii?q?A9a23=3ApRt5Wh/IQYY8cP9uWD/oyV9kXcBvk7rxNw8Rr?= =?us-ascii?q?JEgjuEGfqei+sHkO0rSrbVogUTSVIrWo/RDl6LNsq/mVGBBhPTJsH0LfJFWE?= =?us-ascii?q?RNQj8IQkl8vBceEDQvwK/u5JyA/Fd5JAVli+XzzOENJGcH4MlvVpHD67TMbF?= =?us-ascii?q?hjlcwRvIeGgEY/JhMPx3Oe3qPXu?= IronPort-Data: =?us-ascii?q?A9a23=3ApnhZaKwWgq6Cw47SeoJ6t+fOxCrEfRIJ4+Muj?= =?us-ascii?q?C+fZmUNrF6WrkUOnGAaD2yPMvaCNDfxeNkibIW08kgOsMTdzNJqHlM5+FhgH?= =?us-ascii?q?ilAwSbn6Xt1DatR0xt/paQvdWo/hyklQoSGfJ1cokP0/E/3a+G59CYkjMlke?= =?us-ascii?q?5KlYAL6EnEpLeNbYH9JZSJLw4bVs6Yw6TSLK1rlVeDa+6UzDGSYNwtcaQr43?= =?us-ascii?q?U4sRCRH55wesBtA1rA3iGsiUFX2zxH5B7pHTU29wueRf2VaIgK6b76rILCR5?= =?us-ascii?q?GjV+VImDcmo1+29eUwRSbmUNg+L4pZUc/H92V4Z+WpjieBiaaZ0hUR/011lm?= =?us-ascii?q?/h9xMhOuIeYQgYyNaqKk+MYO/VdO3AjZPQWpu+efxBTtuTWlSUqaUDEzf5qB?= =?us-ascii?q?U1jYdUT+/18BidF8vkwJDUEdBvFhu+qzvS8UOYErsU7MpfDPY4DtDdn1z6xJ?= =?us-ascii?q?e0+W5HFTI3L6MNWmjAqiahmGP/EZNgLeyFqbQjASxJKM1YTTpk5mY+AjGP+e?= =?us-ascii?q?jsepRSerLAv7m7PwRZZ373kMd6TcduPLfi5NG7wSnnu5W/1BFQRM8aSjGHD+?= =?us-ascii?q?XO3jeiJliT+ML/+3YaQrpZC6GB/DERKYPHOaWaGnA=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AFWfEj6MmnWzwK8BcT2P155DYdb4zR+YMi2?= =?us-ascii?q?TDiHoRdfUFSKKlfp6V88jzjSWE9wr4WBkb6Le90dq7MA3hHP9OkMgs1NKZPD?= =?us-ascii?q?UO11HYV72KgbGSpgEIXheOitK1tp0QM5SWaueAd2SS5PySiGLTfrpQo6jkzE?= =?us-ascii?q?nrv5ai854Hd3ANV0gU1XYANu/tKDwOeOApP+tcKLOsou584xawc3Ueacq2Ql?= =?us-ascii?q?MfWfLYmtHNnJX6JTYbGh8O8mC1/HCVwY+/NyLd8gYVUjtJz7tn23PCiRbF6q?= =?us-ascii?q?KqtOz+4gPA1lXU849dlLLau5l+7Y23+40owwfX+0GVjbdaKvu/VfcO0biSAW?= =?us-ascii?q?MR4Z3xStEbTpxOAj3qDzqISFDWqnjdOX4Vmg/fIBmj8CHeSQiTfkNnNyKH7r?= =?us-ascii?q?gpLycxonBQz+1UweZF2XmUuIFQCg6FlCPh58LQXxUvjUasp2E++NRjwkC3fL?= =?us-ascii?q?FuI4O5l7Zvtn+90a1wax7S+cQiCq1jHcvc7PFZfReTaG3YpHBmxJipUm4oFh?= =?us-ascii?q?mLT0AesojNugIm00xR3g8d3ogSj30A/JUyR91N4PnFKL1hkPVLQtUNZaxwCe?= =?us-ascii?q?8dSY+8C3DLQxjLLGWOSG6XWJ0vKjbIsdr68b817OaldNgBy4Yzgo3IVBdCuW?= =?us-ascii?q?s7ayvVeIWzNV1wg1nwqUCGLHrQI+1llu1EU4zHNczW2He4OSITeuOb0oEiPv?= =?us-ascii?q?E=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BLAABAh2xh/5pdJa1QBAYcAQEBAQE?= =?us-ascii?q?BBwEBEgEBBAQBAUCBRQcBAQsBgSAwUQd3WjcxiA4DhFlgiA4DinSPfoEuFIE?= =?us-ascii?q?RA1QLAQEBDQEBKgEMCgQBAYQ7RQKCTAIlNAkOAQIEAQEBEgEBBQEBAQIBBgS?= =?us-ascii?q?BEROFaA2GQgEBAQECAQEBEC4BASwCAgcBBAsCAQgRAQIBAgEgBwchBgsUAwY?= =?us-ascii?q?IAgQBDQUIGoJQgX5XAw4hAQ6gLAGBOgKKH3iBM4EBgggBAQYEBIFKQYJ/DQu?= =?us-ascii?q?CNQMGgToBgwWCd1RKgSCFWyccgUlEgRQBQ4JnPoIhQgEBA4EoAQcLAQcKEh4?= =?us-ascii?q?GB4Migi6LfRAuLQYXJyYECxcWEwgUDjkGGlEBDQQBJQEBLEUDkVMJB4w4nl0?= =?us-ascii?q?8ZwqDMYpKjkCGBxSDaottl0KWCx+MUINEkDQghGkCBAIEBQIOAQEGgWE7aXB?= =?us-ascii?q?wFTuCaVEZD1eBAoxHDBYVgzuFFIVKdAI2AgYLAQEDCZMgAQE?= X-IronPort-AV: E=Sophos;i="5.85,380,1624320000"; d="scan'208,217";a="951186816" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Oct 2021 20:29:00 +0000 Received: from mail.cisco.com (xbe-rcd-001.cisco.com [173.37.102.16]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 19HKT0Xh027241 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Sun, 17 Oct 2021 20:29:00 GMT Received: from xfe-rtp-002.cisco.com (64.101.210.232) by xbe-rcd-001.cisco.com (173.37.102.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Sun, 17 Oct 2021 15:28:59 -0500 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.792.15; Sun, 17 Oct 2021 16:28:58 -0400 Received: from NAM12-BN8-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.792.15 via Frontend Transport; Sun, 17 Oct 2021 15:28:58 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q2wLKJ97RflQH7spteJQe7p/YE8c0AxLhWUfbozh82GliXd3FbycVyQbbE8wM4i841h0v6Aood6G9/QBZXITZWdJ6csdj3HJ2hvZ/CGV1bu6KUfH16p2cJfLqXj36jOl+rYp75AL0U6BNMw7ua4gpgH8L4BaGMZXrw2eEJhA2EL85np2RL+qP2bcKlmU8V+w6iqVDv7Y1DrhB/5SJ+Vk86bpIyKc2hpbhZYxPbhGta9tmNwdHMZexnVbu+OELF/uk+1XHfIfXxQSTlhgJP2xC7NPVIs21It/KN+rmTCJ6iJVwfH23uXQIu5K7a/A8Hmhekt+VIkX3Inj8dNNuuvzEA== 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=F9yRPzZiGO1kfv4S331Y1oGcVAXK338j2XWrQZ7IEIk=; b=fWMI23PD+p54mQPGtUN2D+GGfRSB+brDqDX1C1F/N499CuZNCLYIPCdWBhN1yaAdKyXruakbiXa40GEo2fEy8vrRKLQMdGJD5eeC05YLJQEdB1uJQflwdpYbakT2IRf1qIOrE+v91Iokki0QPVbWjpt1rh0hNgTX+lZt1G7gmUmZvn1+lKx/4CzjsLR9EhzdTG1F/TSOZuc2UjsShdWEskxqFMcf7pcAxvgafKphkpDxztt/ZfI+A8PMZYrSztS0ecFQ0c28vksboq0BkQdS6SXG0OEtEPdZkECE+AUDZL9a2CL14MTeE26EkHg3QVmbzKkRXAny8akLHYZIYFUIWA== 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=F9yRPzZiGO1kfv4S331Y1oGcVAXK338j2XWrQZ7IEIk=; b=LDZU01lAOZ7WLHUvFI9WF4ad7IqJav+H/7eRi4ZD7QZ32mbJjler7kN0Q2Ba1P9Fi8mhIFJkckGMU2Q0IRR8QwjOhZ5X4tf747LOSa72F1RSEsyeCV8IU9N9Z3Xaw2fjep4Dv2pp3sjKAft9EAwC0P7p1ThZoTdqfWDiunatBQ4= Received: from BN6PR11MB4081.namprd11.prod.outlook.com (2603:10b6:405:78::38) by BN6PR11MB4084.namprd11.prod.outlook.com (2603:10b6:405:7f::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.18; Sun, 17 Oct 2021 20:28:57 +0000 Received: from BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::90c7:290e:a57c:1a39]) by BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::90c7:290e:a57c:1a39%3]) with mapi id 15.20.4608.018; Sun, 17 Oct 2021 20:28:56 +0000 From: "Darren Dukes (ddukes)" To: Brian Carpenter , Mark Smith CC: SPRING WG List , 6man WG , "Francois Clad (fclad)" Thread-Topic: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression Thread-Index: AQHXv+XlXV6npBRdu0aZTU4AwV14R6vSu0aAgAHjnQCAAb4TAIAAWx0AgAAB7ICAAOYPwQ== Date: Sun, 17 Oct 2021 20:28:56 +0000 Message-ID: References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <6baed9dc-36c6-720b-0a73-0af7f062cb6a@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 24d6606c-c7b2-48f8-22b5-08d991acbeb0 x-ms-traffictypediagnostic: BN6PR11MB4084: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: FQNtlY51Nwc8DZS6TqLUYXV29i+6JwP5wtil1p6RAF0L8qCpPwOM7nle16mQmRIvaUenolWEKzSemnRHdvVx3NCGBxLyKShZQ8fac5NUdh1zilNFiNK9Ue/bS9qV1ma2ZnzAZHJLABb6DisaxGLmOJkkbuW1iIuM1d9YGaRdKtmc0/3aIqIC49YPImDp8y+52Qeo0lb+z9z/SEBy2Ff3qrRO6qxy6wWbB8X0M1F9IQe6uxMY97qtuAObEomf4kTmkrK0ay3hhW1so3BYg2Z1z8UeUx/UICzg0BkpattsgcZiVsc96rsNIOgEy9tb9/lP/Yqs9IEcE9JhOl+az5aisRCpB7fCt4JqOv49SHbnFve+R4DXoVm3oBG+2HtwjUYIZcBbqCfH15H9WxsOeeVt1AGxQmfdsR1ro7P4j+YMAMKDrJfJ7p2ez3g2QyQIe7arWp4/9061FhV3KqChScEOOkJiUJTMdEGqKKM5JXnm+Iq2Wd/HjmOLaVyzLma8biK5H91TJiLghUNagythL3zA8yYcbEKrXPc2F+Tsoxoi74SwggIK9MZIQG+VaRNLFvghRc18JMIxX6pOjTjQu9FJdRyF6jxGJ75qW2JF+dBXrSvd4BSGBzSCz+cy3W1oVB7uD7kpHpkpDnLjgf4qJbNzzPSeqqWcw7swchkkKlq+NaD0NSJoXnL8m7EG5lHPqCcGL4G59cEtk4a3x0jrrfz9SDB60qpAYpDJKTAuZpY+EPWN+u/bNDCwPMFPStIf192kD4iptSNQRoJhgH0WVSl0Y175I6sgHWiqidz5zlGISWMo14tQaywBFYAdclRiry5KgYFsSyYH3ULDnuLxJgHtIg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB4081.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(76116006)(122000001)(38100700002)(91956017)(508600001)(66574015)(71200400001)(83380400001)(166002)(53546011)(966005)(64756008)(66946007)(2906002)(54906003)(8936002)(66556008)(66476007)(66446008)(110136005)(4001150100001)(6506007)(186003)(26005)(33656002)(316002)(4326008)(5660300002)(86362001)(7696005)(9686003)(38070700005)(55016002)(52536014)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?yVyeXoMMZ5rmAEQyA9wU01wFvNsC/2yn4RZnXokOivW0cIVOFiGPOhXPvTCL?= =?us-ascii?Q?ODDz/yK/SiOCALx091Nq/9tv1UYeJc+1/PAneCz0Th8t9LOODJiTz5ul57KN?= =?us-ascii?Q?mFbVmUwssWQF9/sK9IuxLNu0BkFVY//xrLHFFippQ4mBpDrt9M6Lsw0eC/m2?= =?us-ascii?Q?7Mohxb0aSwXbKBA41ykoGhO9J7ZapEcHTSYfvqcsn6xT704WCauxT+zYN27D?= =?us-ascii?Q?bsYiAoweiBqKqst5qgKuvLgHseeDVbJejss99Ep5PLfapLJX1MrDMSCz1wiM?= =?us-ascii?Q?wgqY4/StgWbIYH2GZS6QPgIx1sGLK48APbNii3KGzMV1y341RXFFnG805gO2?= =?us-ascii?Q?O1idXQgJiRFewkl2987AMQuGwCHtBhcXHX4IKH1lchLziSMvp4EljrCAbWZH?= =?us-ascii?Q?yxCZ9MSb/8h0VrZTzjsF7ghMYRbmOhWYS786QdacH5XbF5jG+olN5VWd/qFR?= =?us-ascii?Q?U6lAxe6qmEseColwx9+m3Uok5bnmdJY4kWtPIZ9epObjJJwGV00NOIHbGRd6?= =?us-ascii?Q?q5dI4B9DwI5ztYaDfwDScaX2CJK6/uEiyrKNNtKN7BdKLJJtNZJwJ10bwsAY?= =?us-ascii?Q?ZQOGOJW6siQYmoXcA3jw2EH7d/kOZ17ud/1Pr8tWwPk/5LqcZT9/1UJhnvcU?= =?us-ascii?Q?84N3R6Nz7xddzJ35vnQL7jd+1gEN4IAQETWAXQN7Nra5SDfWT2RFQktiHEPd?= =?us-ascii?Q?DG6km+PTbqnXodvgwD/lRSU0ANrbDDXNE+g3OJGHTvMKjN2nSjFmY6JMG4vx?= =?us-ascii?Q?xYDdmk9dHVmO6q3WcHXxSSrKwfBoCBjLa9TG+U2Tai4YC/9scI/dR0i8zQ3E?= =?us-ascii?Q?i9VzxkpZ6kUZvHpfjXQZuS+iYnof+a9kS6k5S+e2+BjahMfqhLSv/T6OXUkq?= =?us-ascii?Q?jISgUDcAP2ZIzkPOo9JirWuwz5wuBm/5ve1IsXIwkzbFNIuIQCJFJk32RphI?= =?us-ascii?Q?eW38oK7dBFDSWJZZuteKSTzsdCcf1czCZV23nyl1mLrXY3y4nh7V0dGzR1kr?= =?us-ascii?Q?FX93XJZh1RqnUET83MYjwg3ykDzmaKg1e03I1agUAiAIuqc2ipJ2HHkZHIbR?= =?us-ascii?Q?aAvBmXozI27XKzzK6vLhYkvd7KcpCHfCcbRTKPRMoJiA/4Xd5rUKvQns757R?= =?us-ascii?Q?YMEcInykHGL97WDDMi3X54Qdj5BE54Pk/OkKjket78ynaFiOWUu5qlV1tW6U?= =?us-ascii?Q?go0YfiRzz1u7980FIzre0t4npWzExi47dxWBAxPeorwg4w8bNAfkflUquo/m?= =?us-ascii?Q?PK5MAIaYw+dwkU3Y7snf+650FTGdO5FqADzWTkZn8gmz9WrU96nmCk70S5GW?= =?us-ascii?Q?O3mazYgEJ5PfogLniIwjaljC9svO/VAY4uD7aWVFPAoRBw=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN6PR11MB4081A6F3D3EB0F03B1C6A0D9C8BB9BN6PR11MB4081namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN6PR11MB4081.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 24d6606c-c7b2-48f8-22b5-08d991acbeb0 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2021 20:28:56.7803 (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: 32U6u+U2ukoz4mHO2ba9/babqjHSPN9jlP+gVKYH1oDbnXXn6+ATBRsMpwHJP2OPjfth+9fuvaErQiF+9V4LWQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB4084 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xbe-rcd-001.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 17 Oct 2021 20:29:42 -0000 --_000_BN6PR11MB4081A6F3D3EB0F03B1C6A0D9C8BB9BN6PR11MB4081namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Brian, the draft says: Loopback interface addresses are allocated from the prefix 2001:db8:a::/48. In the examples 2001:db8:a:1100:: is the IPv6 address assigned to the loopb= ack interface of node 11. Darren On 2021-10-17, 2:06 AM, "ipv6" wrote: Ah, thanks, that's the sort of thing you can only know by knowing it :-). O= k, so my question about the examples supplied stands. Using this as a sourc= e address has interesting implications. Regards, Brian Carpenter (via tiny screen & keyboard) On Sun, 17 Oct 2021, 18:58 Mark Smith, > wrote: On Sun, 17 Oct 2021 at 11:32, Brian E Carpenter > wrote: > > Thanks for this draft. > > Question: where you show "Source address 2001:db8:a:1100::" is that inten= ded to be the complete address, because it looks like a prefix? I can't fin= d anywhere that an interface identifier of zero is forbidden, but it's unus= ual, and can only exist once in a given subnet. > The IID value of all zeros is the subnet-router anycast address within a subnet, and is required. See 2.6.1 of RFC4291. For example, Linux automatically configures the subnet-router anycast address for all prefixes on an interface if the interface is a forwarding interface. [mark@opy ~]$ ip -6 route show table local | grep anycast anycast 2403:5803:XXXX:: dev wlp3s0 proto kernel metric 0 pref medium anycast fe80:: dev wlp3s0 proto kernel metric 0 pref medium [mark@opy ~]$ (The "local" route table is where the interface address and multicast route route table entries are kept in Linux. They don't all show up via the normal 'ip addr show' or 'ifconfig' commands). Regards, Mark. > Regards > Brian Carpenter > > On 16-Oct-21 10:55, Francois Clad (fclad) wrote: > > Hello Erik, > > > > > > > > You may find some examples here: https://datatracker.ietf.org/doc/draft= -clad-spring-srv6-srh-compression-illus/ > > > > > > > > Hope this helps. > > > > > > > > Thanks, > > > > Francois > > > > > > > > *From: *spring = > on behalf of Erik Kline > > > *Date: *Thursday, 14 October 2021 at 19:06 > > *To: *Joel M. Halpern > > > *Cc: *spring@ietf.org >, ipv6@ietf.org > > > *Subject: *Re: [spring] Question from SPRING regarding draft-filsfilsch= eng-spring-srv6-srh-compression > > > > Joel, > > > > > > > > Thank you for your email. The ADs and chairs have been discussing. > > > > > > > > One thing that would be very helpful to our discussions would be some w= orked examples of the various C-SID behaviors, showing some SRv6 datagrams = and what happens to their contents as they move across some suitable exampl= e SR domain. > > > > > > > > (It would also be helpful if they showed what happens to something like > an ICMPv6 Echo Request to a representative Destination Address in these c= ases when, say, an SRH is not present, i.e. to see when typical unicast sem= antics are preserved or when something more like anycast or multicast behav= ior is to be expected.) > > > > > > > > Assuming some forthcoming helpful examples, we have a goal to get a mor= e complete answer back to you by the latter half of next week. > > > > > > > > Thanks, > > > > -Erik > > > > > > > > On Tue, Oct 12, 2021 at 8:53 PM Joel M. Halpern >> wrote: > > > > The SPRING working group is in the midst of an adoption call on > > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-sr= h-compression/ . > > > > The SPRING charter has text that is explicit that modifications to = data > > planes and architectures standardized by other working groups may n= ot be > > modified in SPRING unless the chairs and ADs responsible for that d= ata > > plane and / or architecture agree. > > > > To complete the context, as my SPRING co-chairs are co-authors on t= he > > document in question, they have recused themselves from decisional > > activities regarding the document. Therefore, this message is > coming > > just from my as the responsible SPRING co-chair managing this adopt= ion call. > > > > As you have seen, multiple questions have been raised about the > > relationship of the document to the IPv6 defined data plane and > > architecture (particularly RFC 4291 and 8200). In particular the > > questions seem to revolve around what the document describes as the > > NEXT-C-SID flavor of compressed SID, and its relationship to the IP= v6 > > standards. (For those seeking more context without reading the ful= l > > document, a paraphrase and simplification of the NEXT-C_SID flavor = is > > provided as a postscript.) > > > > I raised the question of concurrence as required by the SPRING char= ter > > with the Internet ADs and SPRING chairs. They quite reasonably ask= ed me > > to write a note to 6man explaining the concerns as clearly as a can= , so > > that they can then determine how to proceed. > > > > The questions that prompted my inquiry are: > > > > 1) Does the placement of a list of sids in the IPv6 DA field change > the > > IPv6 architectural description of that field. > > 2) Does the operation of shifting information around in the IPv6 > > destination address field represent a modification or extension of = the > > IPv6 data plane. > > > > On a related note, the document in question also defines two other > > flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The > > NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID > > flavor operation, so seems to be affected by the same question. > > > > From my own reading, it appears that the REPLACE-C-SID flavor > does not > > raise issues requiring 6man leadership concurrence. > > > > Yours, > > Joel M. Halpern for the SPRING working group > > > > > > PS: > > Clearly, understanding the question requires some understanding of = what > > the NEXT-C_SID flavor does. This explanation is a simplification = for > > length and context. Really, the best place to understand it is the > > draft. However, to give you enough information to let you decide > > whether you care, I will try to provide a fair summary. My apologi= es in > > advance to the authors for necessary liberties for length. Also, > > discussion of the draft contents (as distinct from the interaction = with > > the IPv6 data plane and architecture) belongs on the SPRING list, a= nd > > should not clutter up 6man. > > > > SIDs are the identifiers used in segment routing. > > In SRv6, as document in the current RFCs, these are 128 bits. > As > > defined in the relevant RFCs, SIDs which identify endpoints to whic= h > > packets are directed are identified by endpoint SIDs. These can ha= ve > > behaviors (decapsulate and forward is one example). They can have > > flavors such as where the SRH is removed. > > > > The topic under discussion is means to compress these SIDs in the > > packets on the wire. The document under discussion provides three > > flavors of compression. > > > > The fundamental mechanism of the draft is to use a single SRH entry > as a > > container for multiple SIDs. In the NEXT-C_SID mechanism, when it = is > > first encountered the entire container is copied into the desinatio= n > > address of the IPv6 packet. The container has a common routing pre= fix > > used for all the NEXT-C-SID SIDs. It is followed by a sequence of > > compressed SIDs of a configured length. One could configure 16, 24= , or > > 32 bits. Or whatever length. The routing advertisements > are arranged > > so that the IPv6 packet is directed to the node represented by the = first > > compressed SID on the basis of longest prefix match matching the > > combination of the common routing prefix and that compressed SID. > > > > When the packet arrives at that node, it looks up the configured > > portion, the compressed SID, and determines the behavior and flavor= . In > > the case of the NEXT-C-SID flavor, the resulting operation is to sh= ift > > the entire remaining contents of the IPv6 address (the bits past th= e > > first compressed sid) so as to over-write the first compressed SID.= 0 > > bits are shifted into the low order positions. If the result is a > > non-zero new first compressed SID, then the packets is forwarded an= d the > > process repeats. When all that is left are 0s, if there is an > SRH, it > > is consulted to find the next SRH entry, which is, per normal SRv6 > > processing, put into the IPv6 DA. > > Note that in the common case where the SIDS needed all fit in to a > > single container, the analysis also assumes the use of the reduced > > encapsulation options which omits the SRH that is not needed as it = would > > have no entries. This the packet contains a normal IPv6 header, wi= th a > > sequence of compressed SIDs (what one might or might not call a sou= rce > > route) in the IPv6 destination address field. > > > > PPS: If the authors of the NEXT-C-SID flavor feel I have mis-repres= ented > > the work, please, send clarifications or corrections. Again, the = best > > source of information is the draft itself. I was asked to provide = extra > > context in this email. > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --_000_BN6PR11MB4081A6F3D3EB0F03B1C6A0D9C8BB9BN6PR11MB4081namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Brian, the draft says:<= /o:p>

     

       Loopback interface addresses are = allocated from the prefix

       2001:db8:a::/48.

     

    In the examples 2001:db8:a:1100= :: is the IPv6 address assigned to the loopback interface of node 11. 

     

    Darren

     

     

     

    On 2021-10-17, 2:06 AM,= "ipv6" <ipv6-bounces@ietf.org> wrote:

     

    Ah, thanks, that's the sort of thing you can only know by knowing it :-). O= k, so my question about the examples supplied stands. Using this as a sourc= e address has interesting implications.

    Regards,
        Brian Carpenter
        (via tiny screen & keyboard)

     

    On Sun, 17 Oct 2021, 18= :58 Mark Smith, <markzzzsmith@= gmail.com> wrote:

    On Sun, 17 Oct 2021 at = 11:32, Brian E Carpenter
    <brian.= e.carpenter@gmail.com> wrote:
    >
    > Thanks for this draft.
    >
    > Question: where you show "Source address 2001:db8:a:1100::" = is that intended to be the complete address, because it looks like a prefix= ? I can't find anywhere that an interface identifier of zero is forbidden, = but it's unusual, and can only exist once in a given subnet.
    >

    The IID value of all zeros is the subnet-router anycast address within
    a subnet, and is required. See 2.6.1 of RFC4291.

    For example, Linux automatically configures the subnet-router anycast
    address for all prefixes on an interface if the interface is a
    forwarding interface.

    [mark@opy ~]$ ip -6 route show table local | grep anycast
    anycast 2403:5803:XXXX:: dev wlp3s0 proto kernel metric 0 pref medium
    anycast fe80:: dev wlp3s0 proto kernel metric 0 pref medium
    [mark@opy ~]$

    (The "local" route table is where the interface address and multi= cast
    route route table entries are kept in Linux. They don't all show up
    via the normal 'ip addr show' or 'ifconfig' commands).

    Regards,
    Mark.


    > Regards
    >    Brian Carpenter
    >
    > On 16-Oct-21 10:55, Francois Clad (fclad) wrote:
    > > Hello Erik,
    > >
    > >
    > >
    > > You may find some examples here: https://datatracker.ietf.org/doc/draft-clad-spring-srv6-srh-compression-ill= us/ <https://datatracker.ietf.org/= doc/draft-clad-spring-srv6-srh-compression-illus/>
    > >
    > >
    > >
    > > Hope this helps.
    > >
    > >
    > >
    > > Thanks,
    > >
    > > Francois
    > >
    > >
    > >
    > > *From: *spring <spring-bounces@ietf.org> on behalf of Erik Kline <= ek.ietf@gmail.com>
    > > *Date: *Thursday, 14 October 2021 at 19:06
    > > *To: *Joel M. Halpern <    jmh@joelhalpern.com>
    > > *Cc: *spring= @ietf.org <spri= ng@ietf.org>, ipv6@ietf.org <ipv6@ietf.org>
    > > *Subject: *Re: [spring] Question from SPRING regarding draft-fils= filscheng-spring-srv6-srh-compression
    > >
    > > Joel,
    > >
    > >
    > >
    > > Thank you for your email.  The ADs and chairs have been disc= ussing.
    > >
    > >
    > >
    > > One thing that would be very helpful to our discussions would be = some worked examples of the various C-SID behaviors, showing some SRv6 data= grams and what happens to their contents as they move across some suitable = example SR domain.
    > >
    > >
    > >
    > > (It would also be helpful if they showed what happens to somethin= g like
    > an ICMPv6 Echo Request to a representative Destination Address in thes= e cases when, say, an SRH is not present, i.e. to see when typical unicast = semantics are preserved or when something more like anycast or multicast be= havior is to be expected.)
    > >
    > >
    > >
    > > Assuming some forthcoming helpful examples, we have a goal to get= a more complete answer back to you by the latter half of next week.
    > >
    > >
    > >
    > > Thanks,
    > >
    > > -Erik
    > >
    > >
    > >
    > > On Tue, Oct 12, 2021 at 8:53 PM Joel M. Halpern <jmh@joelhalpern.com <mai= lto:jmh@joelhalper= n.com>> wrote:
    > >
    > >     The SPRING working group is in the midst of an= adoption call on
    > >     https://d= atatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/     <https://datatracker.ietf.org/doc= /draft-filsfilscheng-spring-srv6-srh-compression/>.
    > >
    > >     The SPRING charter has text that is explicit t= hat modifications to data
    > >     planes and architectures standardized by other= working groups may not be
    > >     modified in SPRING unless the chairs and ADs r= esponsible for that data
    > >     plane and / or architecture agree.
    > >
    > >     To complete the context, as my SPRING co-chair= s are co-authors on the
    > >     document in question, they have recused themse= lves from decisional
    > >     activities regarding the document.  There= fore, this message is
    > coming
    > >     just from my as the responsible SPRING co-chai= r managing this adoption call.
    > >
    > >     As you have seen, multiple questions have been= raised about the
    > >     relationship of the document to the IPv6 defin= ed data plane and
    > >     architecture (particularly RFC 4291 and 8200).= In particular the
    > >     questions seem to revolve around what the docu= ment describes as the
    > >     NEXT-C-SID flavor of compressed SID, and its r= elationship to the IPv6
    > >     standards.  (For those seeking more conte= xt without reading the full
    > >     document, a paraphrase and simplification of t= he NEXT-C_SID flavor is
    > >     provided as a postscript.)
    > >
    > >     I raised the question of concurrence as requir= ed by the SPRING charter
    > >     with the Internet ADs and SPRING chairs. = They quite reasonably asked me
    > >     to write a note to 6man explaining the concern= s as clearly as a can, so
    > >     that they can then determine how to proceed. > >
    > >     The questions that prompted my inquiry are: > >
    > >     1) Does the placement of a list of sids in the= IPv6 DA field change
    > the
    > >     IPv6 architectural description of that field.<= br> > >     2) Does the operation of shifting information = around in the IPv6
    > >     destination address field represent a modifica= tion or extension of the
    > >     IPv6 data plane.
    > >
    > >     On a related note, the document in question al= so defines two other
    > >     flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C= -SID.  The
    > >     NEXT-and-REPLACE-C_SID flavor is defined to in= clude the NEXT-C_SID
    > >     flavor operation, so seems to be affected by t= he same question.
    > >
    > >      From my own reading, it appears that the REPL= ACE-C-SID flavor
    > does not
    > >     raise issues requiring 6man leadership concurr= ence.
    > >
    > >     Yours,
    > >     Joel M. Halpern for the SPRING working group > >
    > >
    > >     PS:
    > >     Clearly, understanding the question requires s= ome understanding of what
    > >     the NEXT-C_SID flavor does.   This e= xplanation is a simplification for
    > >     length and context.  Really, the best pla= ce to understand it is the
    > >     draft.  However, to give you enough infor= mation to let you decide
    > >     whether you care, I will try to provide a fair= summary.  My apologies in
    > >     advance to the authors for necessary liberties= for length.  Also,
    > >     discussion of the draft contents (as distinct = from the interaction with
    > >     the IPv6 data plane and architecture) belongs = on the SPRING list, and
    > >     should not clutter up 6man.
    > >
    > >     SIDs are the identifiers used in segment routi= ng.
    > >     In SRv6, as document in the current RFCs, thes= e are 128 bits.
    >  As
    > >     defined in the relevant RFCs, SIDs which ident= ify endpoints to which
    > >     packets are directed are identified by endpoin= t SIDs.  These can have
    > >     behaviors (decapsulate and forward is one exam= ple).  They can have
    > >     flavors such as where the SRH is removed.
    > >
    > >     The topic under discussion is means to compres= s these SIDs in the
    > >     packets on the wire.  The document under = discussion provides three
    > >     flavors of compression.
    > >
    > >     The fundamental mechanism of the draft is to u= se a single SRH entry
    > as a
    > >     container for multiple SIDs.  In the NEXT= -C_SID mechanism, when it is
    > >     first encountered the entire container is copi= ed into the desination
    > >     address of the IPv6 packet.  The containe= r has a common routing prefix
    > >     used for all the NEXT-C-SID SIDs.  It is = followed by a sequence of
    > >     compressed SIDs of a configured length.  = One could configure 16, 24, or
    > >     32 bits.  Or whatever length.  The r= outing advertisements
    > are arranged
    > >     so that the IPv6 packet is directed to the nod= e represented by the first
    > >     compressed SID on the basis of longest prefix = match matching the
    > >     combination of the common routing prefix and t= hat compressed SID.
    > >
    > >     When the packet arrives at that node, it looks= up the configured
    > >     portion, the compressed SID, and determines th= e behavior and flavor.  In
    > >     the case of the NEXT-C-SID flavor, the resulti= ng operation is to shift
    > >     the entire remaining contents of the IPv6 addr= ess (the bits past the
    > >     first compressed sid) so as to over-write the = first compressed SID.  0
    > >     bits are shifted into the low order positions.=   If the result is a
    > >     non-zero new first compressed SID, then the pa= ckets is forwarded and the
    > >     process repeats.  When all that is left a= re 0s, if there is an
    > SRH, it
    > >     is consulted to find the next SRH entry, which= is, per normal SRv6
    > >     processing, put into the IPv6 DA.
    > >     Note that in the common case where the SIDS ne= eded all fit in to a
    > >     single container, the analysis also assumes th= e use of the reduced
    > >     encapsulation options which omits the SRH that= is not needed as it would
    > >     have no entries.  This the packet contain= s a normal IPv6 header, with a
    > >     sequence of compressed SIDs (what one might or= might not call a source
    > >     route) in the IPv6 destination address field.<= br> > >
    > >     PPS: If the authors of the NEXT-C-SID flavor f= eel I have mis-represented
    > >     the work, please, send clarifications or corre= ctions.   Again, the best
    > >     source of information is the draft itself.&nbs= p; I was asked to provide extra
    > >     context in this email.
    > >
    > >     ______________________________________________= _
    > >     spring mailing list
    > >     spring@ietf.org <mailto:spring@ietf.org>
    > >     https://www.ietf.org/mailman/listinfo/spring <https://www.ietf.org/mailman/listinfo/spring>
    > >
    > >
    > > -----------------------------------------------------------------= ---
    > > IETF IPv6 working group mailing list
    > > ipv6@ietf.org<= /a>
    > > Administrative Requests:     https://www.ietf.org/mailman/listinfo/ipv6
    > > -----------------------------------------------------------------= ---
    > >
    >
    > _______________________________________________
    > spring mailing list
    > spring@ietf.org
    >     https://www.ietf.org/mailman/listinfo/spring

    --_000_BN6PR11MB4081A6F3D3EB0F03B1C6A0D9C8BB9BN6PR11MB4081namp_-- From nobody Sun Oct 17 13:40:43 2021 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 5FAA43A0C6D for ; Sun, 17 Oct 2021 13:40:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20210112.gappssmtp.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 3nPJhZ8sfEPD for ; Sun, 17 Oct 2021 13:40:05 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 E87093A0C6E for ; Sun, 17 Oct 2021 13:40:04 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id w19so62194536edd.2 for ; Sun, 17 Oct 2021 13:40:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=coNmtsUsAbK2y+i3Fyly+GaxSqn8zRr6Y66/9PcQWLw=; b=BqCtHafUvHRDptSO61RzwzZH6wXDrIfPXgKyM40/ztxBvrUqeU8rK3WpEV3axB8DGB 4KfKoMdsSIEO5VfEc5iiOzKx+psaswn/H5pjYgNjxuuRBlgJkVOdaxIYsIrBo/TiWKNd kAxpBrgSzmmDHRZrZg1NtGOO42fqGC7pUzsn6lyhsKFwYoSpIL+U+nzJSvlHi4sMbDnh keDUKDB1FsyqlDshOsS1K+ANEbvNtgwJwmhrpHw4lHp8v24i8iRgAlalsNSPmygMc6zl yeOdwofOHh2ZPYcJhEroAD+x0tOBJbujxd8Ub6FIpZxibVfcpQOuXXAouhXdeALvmScR Q5ug== 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=coNmtsUsAbK2y+i3Fyly+GaxSqn8zRr6Y66/9PcQWLw=; b=lIxHC4V09CMvPoSd7UMQBfH5XWXndx6F/gRrDi1QRDzSb7DVlxRAZhzeY3hOLDviwH byFfuu+jfx9O33UNf6DyudiYejHlkrcj+6zpDZ077Q2Yl5Gxi35rR9HFoXJzTT1aFK38 BsnXnmBFKe8M3gZqfLPLBvOiwdg4MSxCldIVCHG3eGMIgnTUhG+JqjFl/p1uYIxWG43U sU3YAL70ePhdqqPO4+W9WnndtPKkrNAXYhg5JVx8yjhcnd5A8/WV7ZfXXLiSXUlZrXp2 VcHcwca/mUDjdugHWaKX3sMMSq/xOYa/V2y2JBkGm9UpCnx5IAqoLKjeCSWbRNnwIAwt 8RiQ== X-Gm-Message-State: AOAM533EDe15Sa6VRu8riMJ4UmSaUMHdnXxKnJAbhLmdYi0kc9xN758d 9b4XFqeODiQmg3U5tT+zdL86pVP6jbLXTCeu8JkuzQ== X-Google-Smtp-Source: ABdhPJzeVHuPLuYJzgvzoQiF0M90/aliiTx9Sr0Ub4RZQMPARY98v9eDLVPObglcLQgXq7xz1ne8PVMFrfTCpuq0NoY= X-Received: by 2002:a17:907:3312:: with SMTP id ym18mr23954411ejb.370.1634503202630; Sun, 17 Oct 2021 13:40:02 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <1396_1634278622_61691CDE_1396_28_5_787AE7BB302AE849A7480A190F8B93303542C654@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1101.1634412958@localhost> In-Reply-To: From: Tom Herbert Date: Sun, 17 Oct 2021 13:39:51 -0700 Message-ID: To: Mark Smith Cc: Michael Richardson , 6man WG , SPRING WG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [spring] All IPv6 fields are now mutable (Re: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 17 Oct 2021 20:40:11 -0000 On Sat, Oct 16, 2021 at 4:59 PM Mark Smith wrote: > > On Sun, 17 Oct 2021, 06:36 Michael Richardson, wrote: > > > > Mark Smith wrote: > > > In fight changing DAs also will break AH protection of the IPv6 header. > > > > AH is dead. It's been dead for decades. > > I say this as an IPsec enthusiast who wishes this wasn't true. > > But it is. > > > Then all IPv6 field immutability while the packet is in flight is also dead. > > "Controlled domain" == redefine any field, field semantics, and field > processing we like in an existing protocol, yet claim we're still > using the original protocol. > > That has been tacitly endorsed via standards track RFC8986. The Next > Header field is not supposed to be modified in flight per internet > standard RFC8200, yet standards track RFC8986 specifies the behaviour > via PSP. > > This SRH compression ID is redefining the IPv6 DA field semantics. It > encodes multiple network hop destinations in the single IPv6 > destination address field. > > Structured Flow Label - > https://datatracker.ietf.org/doc/draft-filsfils-6man-structured-flow-label/ > is redefining the IPv6 flow label field. > > This will be an operational nightmare in the future, when there are > multiple applicable RFCs that conflict with each other. I don't want > to have to spend time getting into arguments with vendors about which > protocol variant RFC their implementation should or shouldn't have to > comply with while I have 1000s, 10s or 100s of 1000s of customers > off-line. Mark, I think you might be lumping together several disparate proposals in your general claim that "IPv6 field immutability while the packet is in flight is also dead". When SRH was under discussion in 6man there was a lot of work to define which fields were immutable and that is described in RFC8754. Those definitions are sufficient to specify proper interaction between SRH and AH, however RFC8754 knowingly breaks AH as that handling was not specified. Some of us did object to that, but I suppose expediency to publish the protocol won out. Nevertheless, there is nothing that prevents someone from properly defining AH usage with SRH. As for the IPv6 destination address, it was never defined to be an immutable field inflight. In fact, the core operation of a routing header is to overwrite the destination address at each intermediate destination. NAT also changes the DA in flight, but there is a significant difference between NAT and the routing header header operation: when a routing header is set in a packet the sender knows and indicates the destination address. For the purposes of AH or transport checksum, both the sender and final receiver use this address-- there is no ambiguity and the fact that the destination address is mutable in flight doesn't adversely impact end to end protocol operations that operate on the addresses. We have seen various proposals to steal bits or redefine flow label fields, but IMO it's unlikely any of those will ever get consensus. Hosts routinely set the flow label as an unstructured value, and redefining flow label semantics would be a massive retroactive change in deployment. I would point out though, that the flow label is technically not immutable in flight, RFC6437 allows it to be modified by intermediate nodes for "only for compelling operational security reasons". Tom > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Sun Oct 17 15:16:26 2021 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 908113A127D; Sun, 17 Oct 2021 15:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 cvCwYkUHJiBQ; Sun, 17 Oct 2021 15:15:09 -0700 (PDT) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 3C0793A127E; Sun, 17 Oct 2021 15:15:09 -0700 (PDT) Received: by mail-pj1-x1033.google.com with SMTP id om14so10898139pjb.5; Sun, 17 Oct 2021 15:15:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=5F9TE21t+KngT+F2ZNGdB6dKZ5lX2JC13t2o7kvsWvc=; b=Tz4nlQ9RkzXTqTL6XNsyjy04RXNJ9Xk4SkYVGYdv0eAmrK2RRKB7VeSNp16p2ZBN4m 6mfCydP9/j/N/BiPG/m8bSA7w8D7Rlq7BD/R3n3ZVuhDjGgMkz3wKQzOSW4tleVPkz9n wjipw+qup/H7p5H8Oxsof0wi0B0ZZtDnJQwdrbZ30sDBFuk2pCuSR4bNpBsHuSLvFyR6 0moxK5EZamOhKYpM80vSlDCcUdtnL0KbVcc7ICSetEiVyiPuCP9yfIfpOnB87qOjWOKl aQ1rbd4t6Vdf/TbBqlQ2kIi+QWJ9nHBshgCK0xhwxFyRgG+JRpPDN4Be/1wzPYM2Yuwi I6WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5F9TE21t+KngT+F2ZNGdB6dKZ5lX2JC13t2o7kvsWvc=; b=V1fdd3wnmekw3r0W1/jQ5RCTKz8j8nH7ayjGIMLx4BmeWCgklALzrKd19hSKU8KLKq N3XgROXH4cxMpkXv9Gi3Bu391DBTCl9H71kNO8EPO3echyMXfwmTze4CFo6hiBXG5W9r Xf2Z8i0g697WWhtdwN6xipYv3DbfqthT7dYcjqvb21/8e9g0Nhg71aRjVWvqq2iSlTHu RlteVtN7WGdAqVJe+KiLu0gxDbQdnEM5Z7mHI4kQwnTvPwm0f5B+pUWvtO9SLoNf1mDR Ad7Nvd584AKO2d/L7sCmgj99iGmGSqKMdWwO9G0hEik0vslcq40PK1mxBUrzjBLB3PLv nDOw== X-Gm-Message-State: AOAM5302GpfWS1xdf48Kn5OfFWC5dDKaNM1ErJ5TUnezr4ltJvKWVnxH pV6NJZuazGVPVoZgHnw4Kts= X-Google-Smtp-Source: ABdhPJzUju7XPBIxolwS0dUJ0EO1g3jid/PBU2eqOH6tR5dvrBoaK+qAFdZ1AWBScWjdxQCxQipd0w== X-Received: by 2002:a17:902:7e84:b0:13e:d793:20d8 with SMTP id z4-20020a1709027e8400b0013ed79320d8mr23704665pla.67.1634508907347; Sun, 17 Oct 2021 15:15:07 -0700 (PDT) Received: from ?IPv6:2406:e003:102d:e801:db7:d041:a2d:ce65? ([2406:e003:102d:e801:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id 12sm10819897pfz.133.2021.10.17.15.15.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 17 Oct 2021 15:15:06 -0700 (PDT) To: "Darren Dukes (ddukes)" , Mark Smith Cc: SPRING WG List , 6man WG , "Francois Clad (fclad)" References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <6baed9dc-36c6-720b-0a73-0af7f062cb6a@gmail.com> From: Brian E Carpenter Message-ID: Date: Mon, 18 Oct 2021 11:15:03 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 17 Oct 2021 22:15:14 -0000 On 18-Oct-21 09:28, Darren Dukes (ddukes) wrote: > Hi Brian, the draft says: >=20 > =C2=A0=C2=A0 Loopback interface addresses are allocated from the prefix= > =C2=A0=C2=A0 2001:db8:a::/48.=20 >=20 > In the examples 2001:db8:a:1100:: is the IPv6 address assigned to the l= oopback interface of node 11.=20 Still, using IID =3D=3D 0 seems to be asking for trouble, since it's a re= served value and is definitely special-cased in some code. Unless, that i= s, you want exactly the properties described in RFC4291 section 2.6.1 (th= anks, Mark Smith). Would it change your examples if you used 2001:db8:a:1100::1 instead? Brian >=20 > =C2=A0 >=20 > Darren >=20 > =C2=A0 >=20 > =C2=A0 >=20 > =C2=A0 >=20 > On 2021-10-17, 2:06 AM, "ipv6" wrote: >=20 > =C2=A0 >=20 > Ah, thanks, that's the sort of thing you can only know by knowing it :-= ). Ok, so my question about the examples supplied stands. Using this as a=20 source address has interesting implications. >=20 > Regards, > =C2=A0=C2=A0=C2=A0 Brian Carpenter > =C2=A0=C2=A0=C2=A0 (via tiny screen & keyboard) >=20 > =C2=A0 >=20 > On Sun, 17 Oct 2021, 18:58 Mark Smith, > wrote: >=20 > On Sun, 17 Oct 2021 at 11:32, Brian E Carpenter > > = wrote: > > > > Thanks for this draft. > > > > Question: where you show "Source address 2001:db8:a:1100::" is th= at intended to be the complete address, because it looks like a prefix? I=20 can't find anywhere that an interface identifier of zero is forbidden, bu= t it's unusual, and can only exist once in a given subnet. > > >=20 > The IID value of all zeros is the subnet-router anycast address wit= hin > a subnet, and is required. See 2.6.1 of RFC4291. >=20 > For example, Linux automatically configures the subnet-router anyca= st > address for all prefixes on an interface if the interface is a > forwarding interface. >=20 > [mark@opy ~]$ ip -6 route show table local | grep anycast > anycast 2403:5803:XXXX:: dev wlp3s0 proto kernel metric 0 pref medi= um > anycast fe80:: dev wlp3s0 proto kernel metric 0 pref medium > [mark@opy ~]$ >=20 > (The "local" route table is where the interface address and multica= st > route route table entries are kept in Linux. They don't all show up= > via the normal 'ip addr show' or 'ifconfig' commands). >=20 > Regards, > Mark. >=20 >=20 > > Regards > >=C2=A0 =C2=A0 Brian Carpenter > > > > On 16-Oct-21 10:55, Francois Clad (fclad) wrote: > > > Hello Erik, > > > > > > > > > > > > You may find some examples here: https://datatracker.ietf.org/d= oc/draft-clad-spring-srv6-srh-compression-illus/ > > > > > > > > > > > > > Hope this helps. > > > > > > > > > > > > Thanks, > > > > > > Francois > > > > > > > > > > > > *From: *spring > on behalf of Erik Kline > > > > *Date: *Thursday, 14 October 2021 at 19:06 > > > *To: *Joel M. Halpern > > > > *Cc: *spring@ietf.org >, ipv6@ietf.org > > > > *Subject: *Re: [spring] Question from SPRING regarding draft-fi= lsfilscheng-spring-srv6-srh-compression > > > > > > Joel, > > > > > > > > > > > > Thank you for your email.=C2=A0 The ADs and chairs have been di= scussing. > > > > > > > > > > > > One thing that would be very helpful to our discussions would b= e some worked examples of the various C-SID behaviors, showing some SRv6 = datagrams and what happens to their contents as they move across some sui= table example SR domain. > > > > > > > > > > > > (It would also be helpful if they showed what happens to someth= ing like > > an ICMPv6 Echo Request to a representative Destination Address in=20 these cases when, say, an SRH is not present, i.e. to see when typical un= icast semantics are preserved or when something more like anycast or mult= icast behavior is to be expected.) > > > > > > > > > > > > Assuming some forthcoming helpful examples, we have a goal to g= et a more complete answer back to you by the latter half of next week. > > > > > > > > > > > > Thanks, > > > > > > -Erik > > > > > > > > > > > > On Tue, Oct 12, 2021 at 8:53 PM Joel M. Halpern >> wrote: > > > > > >=C2=A0 =C2=A0 =C2=A0The SPRING working group is in the midst of = an adoption call on > > >=C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-filsf= ilscheng-spring-srv6-srh-compression/ >. > > > > > >=C2=A0 =C2=A0 =C2=A0The SPRING charter has text that is explicit=20 that modifications to data > > >=C2=A0 =C2=A0 =C2=A0planes and architectures standardized by oth= er working groups may not be > > >=C2=A0 =C2=A0 =C2=A0modified in SPRING unless the chairs and ADs=20 responsible for that data > > >=C2=A0 =C2=A0 =C2=A0plane and / or architecture agree. > > > > > >=C2=A0 =C2=A0 =C2=A0To complete the context, as my SPRING co-cha= irs are co-authors on the > > >=C2=A0 =C2=A0 =C2=A0document in question, they have recused them= selves from decisional > > >=C2=A0 =C2=A0 =C2=A0activities regarding the document.=C2=A0 The= refore, this message is > > coming > > >=C2=A0 =C2=A0 =C2=A0just from my as the responsible SPRING co-ch= air managing this adoption call. > > > > > >=C2=A0 =C2=A0 =C2=A0As you have seen, multiple questions have be= en raised about the > > >=C2=A0 =C2=A0 =C2=A0relationship of the document to the IPv6 def= ined data plane and > > >=C2=A0 =C2=A0 =C2=A0architecture (particularly RFC 4291 and 8200= ). In particular the > > >=C2=A0 =C2=A0 =C2=A0questions seem to revolve around what the do= cument describes as the > > >=C2=A0 =C2=A0 =C2=A0NEXT-C-SID flavor of compressed SID, and its=20 relationship to the IPv6 > > >=C2=A0 =C2=A0 =C2=A0standards.=C2=A0 (For those seeking more con= text without reading the full > > >=C2=A0 =C2=A0 =C2=A0document, a paraphrase and simplification of=20 the NEXT-C_SID flavor is > > >=C2=A0 =C2=A0 =C2=A0provided as a postscript.) > > > > > >=C2=A0 =C2=A0 =C2=A0I raised the question of concurrence as requ= ired by the SPRING charter > > >=C2=A0 =C2=A0 =C2=A0with the Internet ADs and SPRING chairs.=C2=A0=20 They quite reasonably asked me > > >=C2=A0 =C2=A0 =C2=A0to write a note to 6man explaining the conce= rns as clearly as a can, so > > >=C2=A0 =C2=A0 =C2=A0that they can then determine how to proceed.= > > > > > >=C2=A0 =C2=A0 =C2=A0The questions that prompted my inquiry are: > > > > > >=C2=A0 =C2=A0 =C2=A01) Does the placement of a list of sids in t= he IPv6 DA field change > > the > > >=C2=A0 =C2=A0 =C2=A0IPv6 architectural description of that field= =2E > > >=C2=A0 =C2=A0 =C2=A02) Does the operation of shifting informatio= n around in the IPv6 > > >=C2=A0 =C2=A0 =C2=A0destination address field represent a modifi= cation or extension of the > > >=C2=A0 =C2=A0 =C2=A0IPv6 data plane. > > > > > >=C2=A0 =C2=A0 =C2=A0On a related note, the document in question = also defines two other > > >=C2=A0 =C2=A0 =C2=A0flavors, REPLACE-C-SID, and NEXT-and-REPLACE= -C-SID.=C2=A0 The > > >=C2=A0 =C2=A0 =C2=A0NEXT-and-REPLACE-C_SID flavor is defined to = include the NEXT-C_SID > > >=C2=A0 =C2=A0 =C2=A0flavor operation, so seems to be affected by=20 the same question. > > > > > >=C2=A0 =C2=A0 =C2=A0 From my own reading, it appears that the RE= PLACE-C-SID flavor > > does not > > >=C2=A0 =C2=A0 =C2=A0raise issues requiring 6man leadership concu= rrence. > > > > > >=C2=A0 =C2=A0 =C2=A0Yours, > > >=C2=A0 =C2=A0 =C2=A0Joel M. Halpern for the SPRING working group= > > > > > > > > >=C2=A0 =C2=A0 =C2=A0PS: > > >=C2=A0 =C2=A0 =C2=A0Clearly, understanding the question requires=20 some understanding of what > > >=C2=A0 =C2=A0 =C2=A0the NEXT-C_SID flavor does.=C2=A0 =C2=A0This=20 explanation is a simplification for > > >=C2=A0 =C2=A0 =C2=A0length and context.=C2=A0 Really, the best p= lace to understand it is the > > >=C2=A0 =C2=A0 =C2=A0draft.=C2=A0 However, to give you enough inf= ormation to let you decide > > >=C2=A0 =C2=A0 =C2=A0whether you care, I will try to provide a fa= ir summary.=C2=A0 My apologies in > > >=C2=A0 =C2=A0 =C2=A0advance to the authors for necessary liberti= es for length.=C2=A0 Also, > > >=C2=A0 =C2=A0 =C2=A0discussion of the draft contents (as distinc= t from the interaction with > > >=C2=A0 =C2=A0 =C2=A0the IPv6 data plane and architecture) belong= s on the SPRING list, and > > >=C2=A0 =C2=A0 =C2=A0should not clutter up 6man. > > > > > >=C2=A0 =C2=A0 =C2=A0SIDs are the identifiers used in segment rou= ting. > > >=C2=A0 =C2=A0 =C2=A0In SRv6, as document in the current RFCs, th= ese are 128 bits. > >=C2=A0 As > > >=C2=A0 =C2=A0 =C2=A0defined in the relevant RFCs, SIDs which ide= ntify endpoints to which > > >=C2=A0 =C2=A0 =C2=A0packets are directed are identified by endpo= int SIDs.=C2=A0 These can have > > >=C2=A0 =C2=A0 =C2=A0behaviors (decapsulate and forward is one ex= ample).=C2=A0 They can have > > >=C2=A0 =C2=A0 =C2=A0flavors such as where the SRH is removed. > > > > > >=C2=A0 =C2=A0 =C2=A0The topic under discussion is means to compr= ess these SIDs in the > > >=C2=A0 =C2=A0 =C2=A0packets on the wire.=C2=A0 The document unde= r discussion provides three > > >=C2=A0 =C2=A0 =C2=A0flavors of compression. > > > > > >=C2=A0 =C2=A0 =C2=A0The fundamental mechanism of the draft is to=20 use a single SRH entry > > as a > > >=C2=A0 =C2=A0 =C2=A0container for multiple SIDs.=C2=A0 In the NE= XT-C_SID mechanism, when it is > > >=C2=A0 =C2=A0 =C2=A0first encountered the entire container is co= pied into the desination > > >=C2=A0 =C2=A0 =C2=A0address of the IPv6 packet.=C2=A0 The contai= ner has a common routing prefix > > >=C2=A0 =C2=A0 =C2=A0used for all the NEXT-C-SID SIDs.=C2=A0 It i= s followed by a sequence of > > >=C2=A0 =C2=A0 =C2=A0compressed SIDs of a configured length.=C2=A0=20 One could configure 16, 24, or > > >=C2=A0 =C2=A0 =C2=A032 bits.=C2=A0 Or whatever length.=C2=A0 The=20 routing advertisements > > are arranged > > >=C2=A0 =C2=A0 =C2=A0so that the IPv6 packet is directed to the n= ode represented by the first > > >=C2=A0 =C2=A0 =C2=A0compressed SID on the basis of longest prefi= x match matching the > > >=C2=A0 =C2=A0 =C2=A0combination of the common routing prefix and=20 that compressed SID. > > > > > >=C2=A0 =C2=A0 =C2=A0When the packet arrives at that node, it loo= ks up the configured > > >=C2=A0 =C2=A0 =C2=A0portion, the compressed SID, and determines = the behavior and flavor.=C2=A0 In > > >=C2=A0 =C2=A0 =C2=A0the case of the NEXT-C-SID flavor, the resul= ting operation is to shift > > >=C2=A0 =C2=A0 =C2=A0the entire remaining contents of the IPv6 ad= dress (the bits past the > > >=C2=A0 =C2=A0 =C2=A0first compressed sid) so as to over-write th= e first compressed SID.=C2=A0 0 > > >=C2=A0 =C2=A0 =C2=A0bits are shifted into the low order position= s.=C2=A0 If the result is a > > >=C2=A0 =C2=A0 =C2=A0non-zero new first compressed SID, then the = packets is forwarded and the > > >=C2=A0 =C2=A0 =C2=A0process repeats.=C2=A0 When all that is left=20 are 0s, if there is an > > SRH, it > > >=C2=A0 =C2=A0 =C2=A0is consulted to find the next SRH entry, whi= ch is, per normal SRv6 > > >=C2=A0 =C2=A0 =C2=A0processing, put into the IPv6 DA. > > >=C2=A0 =C2=A0 =C2=A0Note that in the common case where the SIDS = needed all fit in to a > > >=C2=A0 =C2=A0 =C2=A0single container, the analysis also assumes = the use of the reduced > > >=C2=A0 =C2=A0 =C2=A0encapsulation options which omits the SRH th= at is not needed as it would > > >=C2=A0 =C2=A0 =C2=A0have no entries.=C2=A0 This the packet conta= ins a normal IPv6 header, with a > > >=C2=A0 =C2=A0 =C2=A0sequence of compressed SIDs (what one might = or might not call a source > > >=C2=A0 =C2=A0 =C2=A0route) in the IPv6 destination address field= =2E > > > > > >=C2=A0 =C2=A0 =C2=A0PPS: If the authors of the NEXT-C-SID flavor=20 feel I have mis-represented > > >=C2=A0 =C2=A0 =C2=A0the work, please, send clarifications or cor= rections.=C2=A0 =C2=A0Again, the best > > >=C2=A0 =C2=A0 =C2=A0source of information is the draft itself.=C2= =A0 I was asked to provide extra > > >=C2=A0 =C2=A0 =C2=A0context in this email. > > > > > >=C2=A0 =C2=A0 =C2=A0____________________________________________= ___ > > >=C2=A0 =C2=A0 =C2=A0spring mailing list > > >=C2=A0 =C2=A0 =C2=A0spring@ietf.org > > > >=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listinfo/spring=20 > > > > > > > > > > ---------------------------------------------------------------= ----- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/= ipv6 > > > ---------------------------------------------------------------= ----- > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring >=20 From nobody Sun Oct 17 15:23:10 2021 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 93FBB3A139E; Sun, 17 Oct 2021 15:22:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YA_AqNNstgTH; Sun, 17 Oct 2021 15:22:50 -0700 (PDT) Received: from mail-pj1-x1032.google.com (mail-pj1-x1032.google.com [IPv6:2607:f8b0:4864:20::1032]) (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 590643A132B; Sun, 17 Oct 2021 15:22:45 -0700 (PDT) Received: by mail-pj1-x1032.google.com with SMTP id ls18-20020a17090b351200b001a00250584aso13142553pjb.4; Sun, 17 Oct 2021 15:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=TxucyUoMXjFTuNZ273Ce/aux0mxSPObdLCP743qHd08=; b=oEEhsWniWYZoh9yivZY8/OcRCdcp26m5F+pEBjlYhIgyBjQ3RPbZ7ja/WJ/qZ/bYNf mEBig7fy4ssRRYsmlquy6OnbUpVGowZe1B7uy5Hys0naSScrR3gc71RSrbrguVBMYf1D LhBA43HQhuG9eKBKySs3OGG8czIWkPwULCxq+Cn8BDJXW8Q55HYG71+/Kh+MYzYydV0e Ob+BDdoQ4zEBx6bx/e4qak95j1D/MGTs4YW58mg8jc9LyM8ysYdULUALWq6bswci7+cq QZK0UoaU8sNgJKVMnZVp9elZi6yVGGEchn0EkuoYea6RokLvS0roSAgbF+OuJ8mFxnAb Hcpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=TxucyUoMXjFTuNZ273Ce/aux0mxSPObdLCP743qHd08=; b=6QPh1LAOmpWwxBAeM/iE1jiMV2S5JilW+tPyJZ0lUBrs8SrXgxkm8LWov8UEY+Sina LkCFijWkt8qqEXM3mjhBb1IwG0uF7y0uMLivuWB4Cigw9J4u1VDqygtzhOxRg7eFvCHy hyBAeTIJ/V/JsKoFbT+t27oevrgKWt1vAjPj42HTe+QsBoSKfiG4GfbOHjGb3E8DI8ZD kofAmJ+QypppUHr+r39IgoF2W5Aq9TXiDAIMbxUqnOmokwXi7sjsnUU5rSn2ejdMgz1E fQGE7x1oMGJ3kt5I4euwkO5y9JTU8wrJmcsYDpwRl3D/cjFlE0+Cgako3qhtiMvT+aok oVOw== X-Gm-Message-State: AOAM531HHebolqc2DI+5tiNLPywUl8Gi80QtiDIV4Gg4CS2zpv8mcqCm vxDKUv8CCPmKBarusR9K/e5S822UupcFYg== X-Google-Smtp-Source: ABdhPJzlPghXa+2J+oAhZu7PEdAaYPB7cIas34yhZGhpzQlggwV635yY867b5Y2N7TMWhd4eJS6gKQ== X-Received: by 2002:a17:902:ea0d:b0:13f:2b62:adeb with SMTP id s13-20020a170902ea0d00b0013f2b62adebmr23555373plg.1.1634509364308; Sun, 17 Oct 2021 15:22:44 -0700 (PDT) Received: from ?IPv6:2406:e003:102d:e801:db7:d041:a2d:ce65? ([2406:e003:102d:e801:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id a22sm10991006pfg.61.2021.10.17.15.22.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 17 Oct 2021 15:22:43 -0700 (PDT) To: Tom Herbert , Mark Smith Cc: SPRING WG , 6man WG , Michael Richardson References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <1396_1634278622_61691CDE_1396_28_5_787AE7BB302AE849A7480A190F8B93303542C654@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1101.1634412958@localhost> From: Brian E Carpenter Message-ID: <5bbcf175-10a7-4839-b968-eea0a0ad8a1b@gmail.com> Date: Mon, 18 Oct 2021 11:22:40 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spring] All IPv6 fields are now mutable (Re: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 17 Oct 2021 22:23:03 -0000 On 18-Oct-21 09:39, Tom Herbert wrote: > On Sat, Oct 16, 2021 at 4:59 PM Mark Smith wrote: >> >> On Sun, 17 Oct 2021, 06:36 Michael Richardson, wrote: >>> >>> Mark Smith wrote: >>> > In fight changing DAs also will break AH protection of the IPv6 header. >>> >>> AH is dead. It's been dead for decades. >>> I say this as an IPsec enthusiast who wishes this wasn't true. >>> But it is. >> >> >> Then all IPv6 field immutability while the packet is in flight is also dead. >> >> "Controlled domain" == redefine any field, field semantics, and field >> processing we like in an existing protocol, yet claim we're still >> using the original protocol. >> >> That has been tacitly endorsed via standards track RFC8986. The Next >> Header field is not supposed to be modified in flight per internet >> standard RFC8200, yet standards track RFC8986 specifies the behaviour >> via PSP. >> >> This SRH compression ID is redefining the IPv6 DA field semantics. It >> encodes multiple network hop destinations in the single IPv6 >> destination address field. >> >> Structured Flow Label - >> https://datatracker.ietf.org/doc/draft-filsfils-6man-structured-flow-label/ >> is redefining the IPv6 flow label field. >> >> This will be an operational nightmare in the future, when there are >> multiple applicable RFCs that conflict with each other. I don't want >> to have to spend time getting into arguments with vendors about which >> protocol variant RFC their implementation should or shouldn't have to >> comply with while I have 1000s, 10s or 100s of 1000s of customers >> off-line. > > Mark, > > I think you might be lumping together several disparate proposals in > your general claim that "IPv6 field immutability while the packet is > in flight is also dead". > > When SRH was under discussion in 6man there was a lot of work to > define which fields were immutable and that is described in RFC8754. > Those definitions are sufficient to specify proper interaction between > SRH and AH, however RFC8754 knowingly breaks AH as that handling was > not specified. Some of us did object to that, but I suppose expediency > to publish the protocol won out. Nevertheless, there is nothing that > prevents someone from properly defining AH usage with SRH. > > As for the IPv6 destination address, it was never defined to be an > immutable field inflight. In fact, the core operation of a routing > header is to overwrite the destination address at each intermediate > destination. NAT also changes the DA in flight, but there is a > significant difference between NAT and the routing header header > operation: when a routing header is set in a packet the sender knows > and indicates the destination address. For the purposes of AH or > transport checksum, both the sender and final receiver use this > address-- there is no ambiguity and the fact that the destination > address is mutable in flight doesn't adversely impact end to end > protocol operations that operate on the addresses. > > We have seen various proposals to steal bits or redefine flow label > fields, but IMO it's unlikely any of those will ever get consensus. > Hosts routinely set the flow label as an unstructured value, and > redefining flow label semantics would be a massive retroactive change > in deployment. I would point out though, that the flow label is > technically not immutable in flight, RFC6437 allows it to be modified > by intermediate nodes for "only for compelling operational security > reasons". Correct, because it was very clear that some firewalls were going to clobber it whatever we wrote. So we tried to describe behaviour that would not nullify the usefulness of the field for stateless load balancing. As for draft-filsfils-6man-structured-flow-label, the problems in https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&index=qrTou1rjtNDDchE5yFfSN31pkMc remain unsolved. Brian From nobody Sun Oct 17 15:40:44 2021 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 94B3F3A132D; Sun, 17 Oct 2021 15:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGLGShPipHXk; Sun, 17 Oct 2021 15:38:50 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B674F3A132B; Sun, 17 Oct 2021 15:38:48 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 19HMciK8096722 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Oct 2021 23:38:44 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local To: "Joel M. Halpern" Cc: "ipv6@ietf.org" , "spring@ietf.org" References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> From: Nick Hilliard Message-ID: <66bcaafc-ab55-7884-d002-c4be439e2062@foobar.org> Date: Sun, 17 Oct 2021 23:38:43 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.49 MIME-Version: 1.0 In-Reply-To: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 17 Oct 2021 22:38:55 -0000 Joel M. Halpern wrote on 13/10/2021 04:52: > 1) Does the placement of a list of sids in the IPv6 DA field change the > IPv6 architectural description of that field. the draft, as I understand it, specifies that inside the srv6 limited domain, the DA is overwritten in-flight with a locator of configurable mask length, followed by a stack containing CSIDs. On each node that the packet passes through, the router left-shifts the stack of CSIDs by a number of bits, which causes an implicit stack pop of the CSID list. The locator remains unchanged. Once the stack is empty, the DA field is reverted to the original DA. The question from the point of view of IPv6 architecture is whether the modified DA a) represents the ipv6 address of an interface (rfc4291, section 2.1) and b) represents the "128-bit address of the intended recipient of the packet" (rfc8200, section 3). The answer to both of these questions seems to be no. -- If we take the examples in draft-clad-spring-srv6-srh-compression-illus, the locator is 2001:db8:000b (block length 48), normally written as 2001:db8:b::/48. At no point is there necessarily a node in the network with an interface which which is bound to an ip address constructed as [locator].[csid1]..[csidN]. It might happen that there was such an interface, but this is not necessary for the protocol to function as specified. From this point of view, the draft does not appear to comply with the definition of the destination address field of the ipv6 header, as defined in rfc8200. -- Question b (i.e. whether the address represents the "128-bit address of the intended recipient of the packet"). It is presumed that the address space carved out by the operator allocates a unique block of IP addresses for the locator. The modified DA will not generally (and probably not ever) represent the intended recipient of the packet, so on this basis it seems that the draft introduces a semantic change to the addressing architecture of ipv6 as defined in rfc4291. -- In simple terms, the srh compression draft appears to repurpose the ipv6 DA field as a temporary storage stack. This changes the semantics of the DA field into something different that rfc8200 / rfc4291 aren't aware of. Some people have brought up NAT and mutable ipv6 header fields. I don't see an issue with modifying source or destination IP addresses / ports in-flight, as long as they represent actual endpoints as defined in rfc8200/4291. We have 25 years of precedent in the form of NAT, so this simply isn't a problem. What is a problem is changing the semantics of a well-known field to mean something else other than what's defined in 8200/4291. The rationale for doing this is not relevant. On a constructive point, I have no doubt that the authors need space to store the SID stack, so it may be better for them to consider using an EH for this purpose. If this were handled in a similar way to how standard SRv6 forwards packets using EHs for SID lists, I don't believe that there would be an issue for 6man to be concerned about, and as there is already running code which uses EHs to determine next-hops for SRv6 packets, there is no reason not to do something similar for C-SIDs. > 2) Does the operation of shifting information around in the IPv6 > destination address field represent a modification or extension of the > IPv6 data plane. Although the syntax remains the same, the draft proposes that the semantics of the ipv6 header be modified. In a SRv6 domain, a packet modified as described will do one thing, and outside the domain it mean something quite different. Rather than answering this question directly, let's take the heterogeneous brown-field network example provided in: https://mailarchive.ietf.org/arch/msg/ipv6/LQyfNkJjCEijP0v8mHYIQPBT7-A/ In this network, if a packet has its DA modified as described in this draft, then the packet would not necessarily arrive at its endpoint if it needed to traverse a section of the network which wasn't srv6 aware. If no modification had been made to the ipv6 data plane, then the packet would be expected to arrive at its destination. This is in contrast with standard srv6, which can apparently support this style of configuration. It is true that SRv6 is defined only in terms of its rfc8799 limited domain and you could argue that as the limited domain is not properly specified according to what the I-D authors intended, that this is a configuration problem rather than a protocol problem. Flip side, this example describes what happens when limited domains hit operational reality, i.e. this is an interesting example of why modifying data plane semantics is considered to be a red-flag issue from the point of view of baseline protocol semantics - things break. Nick From nobody Sun Oct 17 17:35:58 2021 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 8D6393A168B for ; Sun, 17 Oct 2021 17:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20210112.gappssmtp.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 Ekia8nMz6t69 for ; Sun, 17 Oct 2021 17:35:29 -0700 (PDT) Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (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 5B6103A168F for ; Sun, 17 Oct 2021 17:35:29 -0700 (PDT) Received: by mail-ed1-x533.google.com with SMTP id d9so63683663edh.5 for ; Sun, 17 Oct 2021 17:35:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x6msWSqEHZm1iXVIvu7i2VNufCSwTKUdFAJRVPoqE2U=; b=AKoXrmINUFW68wAD/2+5WMgryXu5MNZbxJJ9S2vPpEYsd0HPmqdDIIn/ZKDV3hLayx EadZO60q2LMj2bY2kTPkx9xL/h81dQSNjDCJw+wbHEkep7oN2z1SGxeEoGDDntOnFGQL qN07D2v50kIGm4FC61uNOI23fwp1XzSS7OlaVArigCXiJbJtCsGyDyw+kaBTHIcp/n0Z Fh8Z6rXWhfRlHOBNZ0zrzPFgyQsaL0z0LXg7CB9FWJ0+/uWWpM+9lGK0NkbopZiEl+lB RYV3QwNkhCA+wQ13u8V9fWEvwsjqNsfAEOO/2meKN5Lj4QuxYjCnZ+HwJ6r1t6m/TnyL lxRQ== 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=x6msWSqEHZm1iXVIvu7i2VNufCSwTKUdFAJRVPoqE2U=; b=YA2vuCqhFdV6XXmaD83m/1ngOFVKqaTLVSuz9BatVvoAflSyMx/UUxoSreYW/X6qfi QDR48Ty1Q7OzJyMtu4cKO4DHu08vlm2mAFJNNyltHLfLOzJ6QdXmNDlIjoaYTgUWHsBX b1htA8NJgP6qONbIBaqUtEHpmyITqkyb25KihHUwNyXQMKDNIwubEnIfL/vsFVxsu2kC k3w3mFuu5gEk0OVBkPrZ6g7j3AOZ/jXE/rhAvg+91A94RSHIN1BfC8H0dBcSMASlw8Iz 4pRwLGFfWnK18Pwi3/kPgk2+IUxgwStBBXCgH+0wurIQpdoWGJf3FN6OkiPugRVvngDp UEKA== X-Gm-Message-State: AOAM5323kRfE28CDkrs+TDaE2th9CzYP3nnC+lgydrV8VfOE2bvGH0JU cLeHJ03Jht9mx05XeCMAzy38kWRRWynsq3lIiqWN8Q== X-Google-Smtp-Source: ABdhPJxlihKOD1m7YKFIs+gxGgEp5Rdo2O7T7zy2z6SfdIfM4HXhrL7VLo5HvPPweHXJ7yfPg3nHyzjLmHXe90ROI40= X-Received: by 2002:a17:907:3312:: with SMTP id ym18mr25076200ejb.370.1634517327163; Sun, 17 Oct 2021 17:35:27 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <1396_1634278622_61691CDE_1396_28_5_787AE7BB302AE849A7480A190F8B93303542C654@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1101.1634412958@localhost> <5bbcf175-10a7-4839-b968-eea0a0ad8a1b@gmail.com> In-Reply-To: <5bbcf175-10a7-4839-b968-eea0a0ad8a1b@gmail.com> From: Tom Herbert Date: Sun, 17 Oct 2021 17:35:15 -0700 Message-ID: To: Brian E Carpenter Cc: Mark Smith , SPRING WG , 6man WG , Michael Richardson Content-Type: multipart/alternative; boundary="000000000000aa455505ce95b8d0" Archived-At: Subject: Re: [spring] All IPv6 fields are now mutable (Re: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 18 Oct 2021 00:35:36 -0000 --000000000000aa455505ce95b8d0 Content-Type: text/plain; charset="UTF-8" On Sun, Oct 17, 2021, 3:22 PM Brian E Carpenter wrote: > On 18-Oct-21 09:39, Tom Herbert wrote: > > On Sat, Oct 16, 2021 at 4:59 PM Mark Smith > wrote: > >> > >> On Sun, 17 Oct 2021, 06:36 Michael Richardson, > wrote: > >>> > >>> Mark Smith wrote: > >>> > In fight changing DAs also will break AH protection of the IPv6 > header. > >>> > >>> AH is dead. It's been dead for decades. > >>> I say this as an IPsec enthusiast who wishes this wasn't true. > >>> But it is. > >> > >> > >> Then all IPv6 field immutability while the packet is in flight is also > dead. > >> > >> "Controlled domain" == redefine any field, field semantics, and field > >> processing we like in an existing protocol, yet claim we're still > >> using the original protocol. > >> > >> That has been tacitly endorsed via standards track RFC8986. The Next > >> Header field is not supposed to be modified in flight per internet > >> standard RFC8200, yet standards track RFC8986 specifies the behaviour > >> via PSP. > >> > >> This SRH compression ID is redefining the IPv6 DA field semantics. It > >> encodes multiple network hop destinations in the single IPv6 > >> destination address field. > >> > >> Structured Flow Label - > >> > https://datatracker.ietf.org/doc/draft-filsfils-6man-structured-flow-label/ > >> is redefining the IPv6 flow label field. > >> > >> This will be an operational nightmare in the future, when there are > >> multiple applicable RFCs that conflict with each other. I don't want > >> to have to spend time getting into arguments with vendors about which > >> protocol variant RFC their implementation should or shouldn't have to > >> comply with while I have 1000s, 10s or 100s of 1000s of customers > >> off-line. > > > > Mark, > > > > I think you might be lumping together several disparate proposals in > > your general claim that "IPv6 field immutability while the packet is > > in flight is also dead". > > > > When SRH was under discussion in 6man there was a lot of work to > > define which fields were immutable and that is described in RFC8754. > > Those definitions are sufficient to specify proper interaction between > > SRH and AH, however RFC8754 knowingly breaks AH as that handling was > > not specified. Some of us did object to that, but I suppose expediency > > to publish the protocol won out. Nevertheless, there is nothing that > > prevents someone from properly defining AH usage with SRH. > > > > As for the IPv6 destination address, it was never defined to be an > > immutable field inflight. In fact, the core operation of a routing > > header is to overwrite the destination address at each intermediate > > destination. NAT also changes the DA in flight, but there is a > > significant difference between NAT and the routing header header > > operation: when a routing header is set in a packet the sender knows > > and indicates the destination address. For the purposes of AH or > > transport checksum, both the sender and final receiver use this > > address-- there is no ambiguity and the fact that the destination > > address is mutable in flight doesn't adversely impact end to end > > protocol operations that operate on the addresses. > > > > We have seen various proposals to steal bits or redefine flow label > > fields, but IMO it's unlikely any of those will ever get consensus. > > Hosts routinely set the flow label as an unstructured value, and > > redefining flow label semantics would be a massive retroactive change > > in deployment. I would point out though, that the flow label is > > technically not immutable in flight, RFC6437 allows it to be modified > > by intermediate nodes for "only for compelling operational security > > reasons". > > Correct, because it was very clear that some firewalls were going to > clobber it whatever we wrote. So we tried to describe behaviour > that would not nullify the usefulness of the field for stateless > load balancing. > Brian, Thanks for the explanation concerning why the exception was created. For the concern that the flow label could be used a a covert channel, was this a hypothetical possibility or in response to some real events (sending twenty bits at a time doesn't seem like a very effective covert channel compared to other methods :-) ) Tom > As for draft-filsfils-6man-structured-flow-label, the problems in > https://mailarchive.ietf.org/arch/browse/ipv6/?gbt=1&index=qrTou1rjtNDDchE5yFfSN31pkMc > remain unsolved. > > Brian > --000000000000aa455505ce95b8d0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Sun, Oct 17, 2021, 3:22 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    On 18-Oct-21 09:39, To= m Herbert wrote:
    > On Sat, Oct 16, 2021 at 4:59 PM Mark Smith <markzzzsmith@gmail.= com> wrote:
    >>
    >> On Sun, 17 Oct 2021, 06:36 Michael Richardson, <mcr@sandelman.ca<= /a>> wrote:
    >>>
    >>> Mark Smith <    markzzzsmith@gmail.com> wrote:
    >>>=C2=A0 =C2=A0 =C2=A0> In fight changing DAs also will break = AH protection of the IPv6 header.
    >>>
    >>> AH is dead. It's been dead for decades.
    >>> I say this as an IPsec enthusiast who wishes this wasn't t= rue.
    >>> But it is.
    >>
    >>
    >> Then all IPv6 field immutability while the packet is in flight is = also dead.
    >>
    >> "Controlled domain" =3D=3D redefine any field, field sem= antics, and field
    >> processing we like in an existing protocol, yet claim we're st= ill
    >> using the original protocol.
    >>
    >> That has been tacitly endorsed via standards track RFC8986. The Ne= xt
    >> Header field is not supposed to be modified in flight per internet=
    >> standard RFC8200, yet standards track RFC8986 specifies the behavi= our
    >> via PSP.
    >>
    >> This SRH compression ID is redefining the IPv6 DA field semantics.= It
    >> encodes multiple network hop destinations in the single IPv6
    >> destination address field.
    >>
    >> Structured Flow Label -
    >> https= ://datatracker.ietf.org/doc/draft-filsfils-6man-structured-flow-label/<= br> >> is redefining the IPv6 flow label field.
    >>
    >> This will be an operational nightmare in the future, when there ar= e
    >> multiple applicable RFCs that conflict with each other. I don'= t want
    >> to have to spend time getting into arguments with vendors about wh= ich
    >> protocol variant RFC their implementation should or shouldn't = have to
    >> comply with while I have 1000s, 10s or 100s of 1000s of customers<= br> >> off-line.
    >
    > Mark,
    >
    > I think you might be lumping together several disparate proposals in > your general claim that "IPv6 field immutability while the packet= is
    > in flight is also dead".
    >
    > When SRH was under discussion in 6man there was a lot of work to
    > define which fields were immutable and that is described in RFC8754. > Those definitions are sufficient to specify proper interaction between=
    > SRH and AH, however RFC8754 knowingly breaks AH as that handling was > not specified. Some of us did object to that, but I suppose expediency=
    > to publish the protocol won out. Nevertheless, there is nothing that > prevents someone from properly defining AH usage with SRH.
    >
    > As for the IPv6 destination address, it was never defined to be an
    > immutable field inflight. In fact, the core operation of a routing
    > header is to overwrite the destination address at each intermediate > destination. NAT also changes the DA in flight, but there is a
    > significant difference between NAT and the routing header header
    > operation: when a routing header is set in a packet the sender knows > and indicates the destination address. For the purposes of AH or
    > transport checksum, both the sender and final receiver use this
    > address-- there is no ambiguity and the fact that the destination
    > address is mutable in flight doesn't adversely impact end to end > protocol operations that operate on the addresses.
    >
    > We have seen various proposals to steal bits or redefine flow label > fields, but IMO it's unlikely any of those will ever get consensus= .
    > Hosts routinely set the flow label as an unstructured value, and
    > redefining flow label semantics would be a massive retroactive change<= br> > in deployment. I would point out though, that the flow label is
    > technically not immutable in flight, RFC6437 allows it to be modified<= br> > by intermediate nodes for "only for compelling operational securi= ty
    > reasons".

    Correct, because it was very clear that some firewalls were going to
    clobber it whatever we wrote. So we tried to describe behaviour
    that would not nullify the usefulness of the field for stateless
    load balancing.

    Brian,

    Th= anks for the explanation concerning why the exception was created. For the = concern that the flow label could be used a a covert channel, was this a hy= pothetical possibility or in response to some real events (sending twenty b= its at a time doesn't seem like a very effective covert channel compare= d to other methods :-) )

    Tom


    As for draft-filsfils-6man-structured-flow-label, the problems in ht= tps://mailarchive.ietf.org/arch/browse/ipv6/?gbt=3D1&index=3DqrTou1rjtN= DDchE5yFfSN31pkMc
    remain unsolved.

    =C2=A0 =C2=A0Brian
    --000000000000aa455505ce95b8d0-- From nobody Sun Oct 17 18:30:48 2021 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 BEB0A3A0653; Sun, 17 Oct 2021 18:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, 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=Lf7edTOh; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=W/Ro7iL3 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 fdRgLb-YiFew; Sun, 17 Oct 2021 18:30:10 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C123A0637; Sun, 17 Oct 2021 18:30:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43083; q=dns/txt; s=iport; t=1634520609; x=1635730209; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=rU4kvvLnPh5ELkzI+1L2AFK7a/MGF7/s1GIm7ZXL6bA=; b=Lf7edTOhj1M86sFVWEiXr7iQJpGzQLd746T6O3gDZIHHSWlAd98Y3oM4 DGeJKwntug+fslVUL5R53JKhdBQvUmWO2Y1V0jKHsDM2r/FrDDKLr8KnP iw66UYa4KtjS5TV3TWVEQYoukqbF+9ZhFLpn4WDI6bg+zf5yskYGLn9kV 8=; IronPort-PHdr: =?us-ascii?q?A9a23=3ACgLi9hzfBtJacmbXCzPDngc9DxPP8537OwcU7?= =?us-ascii?q?twsjLcdOqig/pG3OkvZ6L0tiVLSRozU5rpCjPaeqKHvX2EMoPPj+HAPeZBBT?= =?us-ascii?q?VkJ3MMRmQFzD8uMCEm9J/nvPGQ2Gc1YXwpj+He2eUFeBMf5YQjUpXu/pT4fE?= =?us-ascii?q?xnyL0x7POPwT4XTlM+wkeu1/s67Xg=3D=3D?= IronPort-Data: =?us-ascii?q?A9a23=3A5UoakK239M6Uq6rYafbD5Spzkn2cJEfYwER7X?= =?us-ascii?q?KvMYLTBsI5bp2QAmmYcWTuCPfqOZmKkKo8ibYyy8R8F6JHWx4VlSFY93Hw8F?= =?us-ascii?q?HgiRegpqji6wuYcB84ZRyH6ZBoPA/42N5+QcajYcleG/k30a+C48iElvU21b?= =?us-ascii?q?uOU5NDsa3gZqTBMEE/NuTo78wIIqtYAbeqRWmthivuqyyHrA2JJ7hYvWo4iB?= =?us-ascii?q?w1vnzs01Bj6kGtwUlXT/pmntneG/5UeJMp3ya1csxLFrodo8u6SH44vzZmj9?= =?us-ascii?q?W/fuhwqEN7gwvDwc1YBRfjZOg3mZnh+Avf5xEMd4H1plP9naJLwam8P49mNt?= =?us-ascii?q?9x91dZArrS7SBwiOevHn+F1vxxwQnovZPIXo+CdSZS4mYnJp6HcSFPiyPFnA?= =?us-ascii?q?BRqZYYZ4e1wR2pJ8NQULTkXZVaCiv64hrWhRYFEh9w9cuHqMZ8R/HZ6wlnxF?= =?us-ascii?q?u48QJbMa6TH+dEe2y0/7uhLFOzdddgLcj9ucBTobBhGO1NRA5U79M+inHj2d?= =?us-ascii?q?XtV7lmcv7I65XTe1iR+1bHsNJzefdnieCn/ti50vUrc9Gj/RxodLtHamXyO8?= =?us-ascii?q?2mnganEmiaTZW7bL5XgntYCvbFZ7jV75MUqaGaG?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AHrGyRaFQ+C2Tkg8gpLqFSpHXdLJyesId70?= =?us-ascii?q?hD6qkvc31om52j+fxGws516fatskdvZJkh8erwX5VoMkmsi6KdgLNhfItKOT?= =?us-ascii?q?OHhILGFvAY0WKP+UyEJ8S6zJ8g6U4CSdk/NDSTNykBsS+S2mDReLxMrKjlgc?= =?us-ascii?q?KVbKXlvgpQpGpRGsddBnJCe36m+zpNNXB77PQCZf6hz/sCgwDlVWUcb8y9CH?= =?us-ascii?q?VAdfPEvcf3mJXvZgNDLwI76SGV5AnYq4LSIly95FMzQjlPybAt/SzuiAri/J?= =?us-ascii?q?iutPm911v1y3LT1ZJLg9Hso+EzRvBky/JlbwkEuDzYI7iJaIfy+gzdZ9vfsW?= =?us-ascii?q?rCpeO85yvI+f4Ds085MFvF+icFkDOQoQrGo0WSuWNwx0GT+/AQgFkBepZ8bU?= =?us-ascii?q?UzSGqF16NohqAO7Itbm22erJZZFhXGgWD04MXJTQhjkg6urWMlivN7tQ0TbW?= =?us-ascii?q?IyUs4bkWUkxjIeLH7AJlOM1Kk3VO11SM3M7vdfdl2XK3jfo2l02dSpGnA+BA?= =?us-ascii?q?2PTEQOstGcl2E+pgE382IIgMgE2nsQ/pM0TJdJo+zCL6RzjblLCssbd7h0Cu?= =?us-ascii?q?sNSda+TmbNXRXPOmSPJkmPLtBKB1vd75rspLkl7uCjf5IFiJM0hZTaSVtd8X?= =?us-ascii?q?U/fkr/YPf+lKGjMiq9CVlVeA6dhP22y6IJz4EUdYCbRxFrEmpe4fdIi89vdv?= =?us-ascii?q?HmZw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BXAADTzGxh/5BdJa1QBAYcAQEBAQE?= =?us-ascii?q?BBwEBEgEBBAQBAUCBRQcBAQsBgSAwUQd3WjcxiA4DhFlgiA4DinSPfoEuFIE?= =?us-ascii?q?RA08FCwEBAQ0BASoBDAoEAQGEO0UCgkwCJTQJDgECBAEBARIBAQUBAQECAQY?= =?us-ascii?q?EgREThWgNhkIBAQEBAgEBARAIExMBASwCAgcBBAsCAQgRAQIBAQEBIAEGByE?= =?us-ascii?q?GCxQDBggCBAENBQgaglCBflcDDiEBDqAFAYE6AoofeIEzgQGCCAEBBgQEgUp?= =?us-ascii?q?Bgn8NC4I1AwaBOgGDBYJ3VEqBIIVbJxyBSUSBFAFDgmc+giFCAQEDgSgBBws?= =?us-ascii?q?BBwoSHQEGAQYJgxmCLot9EC4tBhcnJgQLFxYTCBQOOQYaUQENBAElAQEsRQO?= =?us-ascii?q?RUwkHjDieXTxnCoMxikqOQIYHFINqi22XQpQpgWIfjFCDRJA0IIRpAgQCBAU?= =?us-ascii?q?CDgEBBoFhO2lwcBU7gmlRGQ9XgQKMRwwWFYM7hRSFSnQCNgIGCwEBAwmTIAE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.85,380,1624320000"; d="scan'208,217";a="939179372" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 Oct 2021 01:30:07 +0000 Received: from mail.cisco.com (xbe-aln-003.cisco.com [173.36.7.18]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 19I1U5lu014717 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 18 Oct 2021 01:30:06 GMT Received: from xfe-aln-001.cisco.com (173.37.135.121) by xbe-aln-003.cisco.com (173.36.7.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Sun, 17 Oct 2021 20:30:05 -0500 Received: from xfe-rcd-001.cisco.com (173.37.227.249) 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.792.15; Sun, 17 Oct 2021 20:30:04 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Sun, 17 Oct 2021 20:30:04 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I8vscN/JuPXCGmtQcWNkcTa1HZmYn9zJiBRuiWURKqxjn95bUIhfGVImtzXdwtmF0Wj3XrkMbyU1dKSbB0Z56tXvxE+G+bAJpCTDpvxXEatcaBq6LHDM0WZ9Y+lFNZrwEKZ4UtYfvqnHdOAOo/qGSv5qWdThw7KUSjqVpgIT9S6URoOPjDH1FNfXmeqpjH1ylNqHs1P3D9VB52welgvMIzWxr4NhAHhU4U7IBB1UvWA4TGxhcSc1/SPBxF8eIXJ5xVv5xXFcYKvQYA79I2UftSprUkCJJg6DaQUvndMT/WJhwVOpuoJc7uVlsrctwqV5hLaWX1y+rX74l1TgZI5T5Q== 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=S9bzfrLtnicZRj4sPa78SKGBzUzzvH4F2louRbR1Oq0=; b=QjgFYJdfhFuaKGQaSr747X1jeqKcj5IjA9i26rMljMTrVmGX/ULM/fXwsgHraQU+r6PFMiggGkLzc54bl0vxZKg4Ah2IQjExJ1mDy5+Drxq/Z9sTer2ZeeCV5B2rok2NCEILRkqVuzaH0itfI+vievsSC6oRaWPh3nSm4A2+OP2kZXcrHIdU7ucLl6wnF11+e5fsnIV5isTuMhFiu2TtBP7FbZCqoLCRLomDGd/abEyzxSkhLNSRNZmXj3EKSIAgLdn11fXH3qw9ctIx8ISvPZHkkpQO114YQkyK5HpMdohhe/3eQeXhv3zXZ9dWzNgHuZSH3u+7FggDU3ZJjW5UQQ== 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=S9bzfrLtnicZRj4sPa78SKGBzUzzvH4F2louRbR1Oq0=; b=W/Ro7iL31qffxf+4llJRbCDtWlqFc12T5/rCp+dbHeN+IBhgYPZ5xK3L/HvDJ+4Y85YS4o0C4pt8w2bNEukOjODNQsLO5In859CRerOb8lGLdFu6Ki/qWcL3R3Pvhrv1+KOafoZemRWcegdF/zsxCPalVJyeRzJX7J/xGKeYSRI= Received: from BN6PR11MB4081.namprd11.prod.outlook.com (2603:10b6:405:78::38) by BN6PR11MB4036.namprd11.prod.outlook.com (2603:10b6:405:82::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.16; Mon, 18 Oct 2021 01:30:01 +0000 Received: from BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::90c7:290e:a57c:1a39]) by BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::90c7:290e:a57c:1a39%3]) with mapi id 15.20.4608.018; Mon, 18 Oct 2021 01:30:01 +0000 From: "Darren Dukes (ddukes)" To: Brian E Carpenter , Mark Smith CC: SPRING WG List , 6man WG , "Francois Clad (fclad)" Thread-Topic: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression Thread-Index: AQHXv+XlXV6npBRdu0aZTU4AwV14R6vSu0aAgAHjnQCAAb4TAIAAWx0AgAAB7ICAAOYPwYAAKQOAgAAVG4Q= Date: Mon, 18 Oct 2021 01:30:01 +0000 Message-ID: References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <6baed9dc-36c6-720b-0a73-0af7f062cb6a@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7bea844d-1543-4b75-cf29-08d991d6ce13 x-ms-traffictypediagnostic: BN6PR11MB4036: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dzI2GWaN7HgC2phOvcoLvHZ/U15d8tbbVbspT/nZcaKL1WrEvLTbN3g+QxdNL80qfL57G7YdVbGHF90ufbRKWdnKXMhvWGLIAOBHkxXrnqoKlZ8DdPZpZgIVHNLS2Nn0KzQ846UENSxh5/bovKS4uV5AIgImSwWWR8twLRPAknl5ZMlASOmhwe4RUgnfPmj4i0zjobCGGte3TkrsbkB6WVIGcQmgk1fonHrF4GGc+qN7WLxe1OeA7a/EJ8QCyyirb7HO5r2T4M8GoxBVH5e8p+ewWzrIzfuHhqbRshGlrdj5E7eQkvkzt885kYI/0b42NcI4c4LqxB1gs6EoKnFHYfRjkzbbJkXnsptheTCnLJR+LUe0jCAzocd7eh04PdvDv+Sq2R8kGdfQfkw/U++f9fNQR34zqgBGGAAuOeDcY+JaL+UQZ+Z0sZ87rY6VrH6vM6t5hA0yQcOnogly4JDqX26Qe20YcqQYdPHPrK27vXOYyyauN4QJ7C59qHU5WlVT72BjWEMclY9VX9SyuqqNQakdpDjyBKh/TfJPKqy/lhPYSjJSQq3x+iSUVaqKVlphfVuUwacgLT9dC4G8Q9nJi2PEw9BCE6MMlU3qELljRr1+mdyLzYfZzrSdEAeEuuXZXORn0lam7M6AuxKOev84gyA1ralc6oRpLRPwyAciHkU4XwKqKiXiftvfQtV6DyWca3/8v2zb2P3svhVzMeLKt3d5piXbmr9YqbsJVesttvupBdb7U/huoQWXJ1B7eAI4bn7ln7qDh6AwvJY5tmqmUT3jX8OwRxsZVDcGmZqSRnAZMN0R1bujSA4oPsmt925RkMy/b+mUCJgcmNhfft8pUw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB4081.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(30864003)(54906003)(8676002)(166002)(2906002)(33656002)(66446008)(53546011)(76116006)(110136005)(66946007)(91956017)(86362001)(122000001)(66476007)(966005)(8936002)(9326002)(4326008)(64756008)(66556008)(508600001)(9686003)(66574015)(6506007)(55016002)(316002)(4001150100001)(38070700005)(186003)(83380400001)(5660300002)(38100700002)(52536014)(71200400001)(26005)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?1iDphHbE1S6h8rGEBknnvBRqXFKTSnykatO+zH1/zu25DzC6cqbhTrbL?= =?Windows-1252?Q?G33vXJOrJIE6tKkdUafCahXI8jLT2+ZYZ5Vkee7inT2wkwvsnCofzrBn?= =?Windows-1252?Q?sC1jfAE9ge5B9NymLfovqRTPKvxKmfuagXINZOs74xMRLwg2WnVBDFSJ?= =?Windows-1252?Q?utxt2bIHz/7EbppypTeRiiTR59hnABI4rhevOzDAg3L96XiuNZlaH7B6?= =?Windows-1252?Q?nqnijFlPLDYp8YAM0Uk+ufOhOS9irXGQ3Gk0amtA9gOyQ8kKFy0UpBrC?= =?Windows-1252?Q?JWbP91UwRXocoqsVgRev4lahMEIoDF1WUIntDisZ3ECOr7GSY1dFX3Y4?= =?Windows-1252?Q?Hz+ZO4TiTJRV7LL7GssWP7o+FNN5+fOszphiLtoo26w2LSHeoABIxUhQ?= =?Windows-1252?Q?yQEsISUn8ji7f3CwKJAmS3dhJG8IkXoyPU7fIbx596+m/oHw5LPt6gCq?= =?Windows-1252?Q?jUbBtqA7beatBjVcZu0A7kmNrjXlFIpYeN8cJoougJ8i1tCc3lPcOgdI?= =?Windows-1252?Q?Vh9YaaKKXCtAgUL1Uw/r6mlG8uXgV7GQc/6ZJxuRgyrG6djKJQLEFrun?= =?Windows-1252?Q?Akm1wj3uXm+ZuT/OOWR7XDs6G3fBHpc51S2OQrB5No1xLjLX/lvFHl7M?= =?Windows-1252?Q?lKmLEkHuFBWpqQ1vOetH1o1bksoZCVCYp5lfWtshPZSsYNpjaFcv44kl?= =?Windows-1252?Q?6Ff9UBSNCrL7ZGV7EjPeV9d6J65hZxB3CelHXbvjHgD6dB5HchlJY8gz?= =?Windows-1252?Q?F6lNBfZGmYS5Z2D+qtZ2RrWmioa7Vpd5EvBvc5kpnHxftxrOh9xhL7dx?= =?Windows-1252?Q?WrNJT2039pYhtijG1wCIngj9JVy3emSPy/7aMaoUCzI+yERQts62cqyC?= =?Windows-1252?Q?2mf63HSX4lllDdGhGQGbz/ekh7ap1rsYNnjsol5cuELEU+rhU+zkXs/0?= =?Windows-1252?Q?3fHAPYxRLpnxaNNV2yaBS1kNNON0VawR4wfzp9Psr/3PMpx7cqd4/74L?= =?Windows-1252?Q?dwQz04CZ/c8Zw9sxwg/oTt1dxFPR7CirwPmyHA/JfVuehmQQMNx3xfJd?= =?Windows-1252?Q?1PlBPSe/SOk3fQKQsL31MC3a93VGcJyspZSkfgZ1PVlcBpN5/c3bHgqT?= =?Windows-1252?Q?BEFBPjBfneIMZj18F6iPQSBc7NIkeovfJImq5nNIShG7OvsubN1tAmDn?= =?Windows-1252?Q?KV267ORXgGC39Y0U1Pqq7VEVOBZVEgx2rHCQ9OJWKp4RtneuhiNEqJ0Y?= =?Windows-1252?Q?oWR/UuBsYd83VODYc+A+mlehFV7kwtDUyRkPwy/fGMWM6Lcmv/cxvBeW?= =?Windows-1252?Q?jw1o/erTapN9wcKf5yvZYx79NLe4NeUlQsjDmB8t8ulikk46jN+ovIun?= =?Windows-1252?Q?HHmHhp0VGfYLbHpFagxax5YEklbXWvsn52eTKMHOPPPuY4F7RcGFSG19?= =?Windows-1252?Q?2gmEB1lcGj5zDk/BVIzkrw=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN6PR11MB4081984D4640339B6697B1E2C8BB9BN6PR11MB4081namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN6PR11MB4081.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7bea844d-1543-4b75-cf29-08d991d6ce13 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Oct 2021 01:30:01.3890 (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: 5kx6cPk6w7dbXWFbetGp4Txr1nlPpH3/KD9XjpMPP2PWVHtDXb0LCiFtO3A0cAIT3t4Lv5JQwK8wBRjSgoHO8A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB4036 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xbe-aln-003.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 18 Oct 2021 01:30:16 -0000 --_000_BN6PR11MB4081984D4640339B6697B1E2C8BB9BN6PR11MB4081namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Brian, > Would it change your examples if you used 2001:db8:a:1100::1 instead? No it would not change the examples, any other assignment for loopback inte= rfaces works the same. > Still, using IID =3D=3D 0 seems to be asking for trouble, since it's a re= served value and is definitely special-cased in some code. Unless, that is,= you want exactly the properties described in RFC4291 section 2.6.1 (thanks= , Mark Smith). As Michael described, this assignment to loopback interfaces works fine. T= he addresses are assigned as /128=92s, not prefixes, the router subnet anyc= ast concern is not applicable. Thanks, Darren ________________________________ From: Brian E Carpenter Sent: Sunday, October 17, 2021 6:15 PM To: Darren Dukes (ddukes); Mark Smith Cc: SPRING WG List; 6man WG; Francois Clad (fclad) Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-sp= ring-srv6-srh-compression On 18-Oct-21 09:28, Darren Dukes (ddukes) wrote: > Hi Brian, the draft says: > > Loopback interface addresses are allocated from the prefix > 2001:db8:a::/48. > > In the examples 2001:db8:a:1100:: is the IPv6 address assigned to the loo= pback interface of node 11. Still, using IID =3D=3D 0 seems to be asking for trouble, since it's a rese= rved value and is definitely special-cased in some code. Unless, that is, y= ou want exactly the properties described in RFC4291 section 2.6.1 (thanks, = Mark Smith). Would it change your examples if you used 2001:db8:a:1100::1 instead? Brian > > > > Darren > > > > > > > > On 2021-10-17, 2:06 AM, "ipv6" wrote: > > > > Ah, thanks, that's the sort of thing you can only know by knowing it :-).= Ok, so my question about the examples supplied stands. Using this as a source address has interesting implications. > > Regards, > Brian Carpenter > (via tiny screen & keyboard) > > > > On Sun, 17 Oct 2021, 18:58 Mark Smith, > wrote: > > On Sun, 17 Oct 2021 at 11:32, Brian E Carpenter > > wr= ote: > > > > Thanks for this draft. > > > > Question: where you show "Source address 2001:db8:a:1100::" is that= intended to be the complete address, because it looks like a prefix? I can't find anywhere that an interface identifier of zero is forbidden, but = it's unusual, and can only exist once in a given subnet. > > > > The IID value of all zeros is the subnet-router anycast address withi= n > a subnet, and is required. See 2.6.1 of RFC4291. > > For example, Linux automatically configures the subnet-router anycast > address for all prefixes on an interface if the interface is a > forwarding interface. > > [mark@opy ~]$ ip -6 route show table local | grep anycast > anycast 2403:5803:XXXX:: dev wlp3s0 proto kernel metric 0 pref medium > anycast fe80:: dev wlp3s0 proto kernel metric 0 pref medium > [mark@opy ~]$ > > (The "local" route table is where the interface address and multicast > route route table entries are kept in Linux. They don't all show up > via the normal 'ip addr show' or 'ifconfig' commands). > > Regards, > Mark. > > > > Regards > > Brian Carpenter > > > > On 16-Oct-21 10:55, Francois Clad (fclad) wrote: > > > Hello Erik, > > > > > > > > > > > > You may find some examples here: https://datatracker.ietf.org/doc= /draft-clad-spring-srv6-srh-compression-illus/ > > > > > > > > > > > > > Hope this helps. > > > > > > > > > > > > Thanks, > > > > > > Francois > > > > > > > > > > > > *From: *spring > on behalf of Erik Kline > > > > *Date: *Thursday, 14 October 2021 at 19:06 > > > *To: *Joel M. Halpern > > > > *Cc: *spring@ietf.org >, ipv6@ietf.org > > > > *Subject: *Re: [spring] Question from SPRING regarding draft-fils= filscheng-spring-srv6-srh-compression > > > > > > Joel, > > > > > > > > > > > > Thank you for your email. The ADs and chairs have been discussin= g. > > > > > > > > > > > > One thing that would be very helpful to our discussions would be = some worked examples of the various C-SID behaviors, showing some SRv6 data= grams and what happens to their contents as they move across some suitable = example SR domain. > > > > > > > > > > > > (It would also be helpful if they showed what happens to somethin= g like > > an ICMPv6 Echo Request to a representative Destination Address in these cases when, say, an SRH is not present, i.e. to see when typical unic= ast semantics are preserved or when something more like anycast or multicas= t behavior is to be expected.) > > > > > > > > > > > > Assuming some forthcoming helpful examples, we have a goal to get= a more complete answer back to you by the latter half of next week. > > > > > > > > > > > > Thanks, > > > > > > -Erik > > > > > > > > > > > > On Tue, Oct 12, 2021 at 8:53 PM Joel M. Halpern >> wrote: > > > > > > The SPRING working group is in the midst of an adoption call = on > > > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-s= rv6-srh-compression/ >. > > > > > > The SPRING charter has text that is explicit that modifications to data > > > planes and architectures standardized by other working groups= may not be > > > modified in SPRING unless the chairs and ADs responsible for that data > > > plane and / or architecture agree. > > > > > > To complete the context, as my SPRING co-chairs are co-author= s on the > > > document in question, they have recused themselves from decis= ional > > > activities regarding the document. Therefore, this message i= s > > coming > > > just from my as the responsible SPRING co-chair managing this= adoption call. > > > > > > As you have seen, multiple questions have been raised about t= he > > > relationship of the document to the IPv6 defined data plane a= nd > > > architecture (particularly RFC 4291 and 8200). In particular = the > > > questions seem to revolve around what the document describes = as the > > > NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6 > > > standards. (For those seeking more context without reading t= he full > > > document, a paraphrase and simplification of the NEXT-C_SID flavor is > > > provided as a postscript.) > > > > > > I raised the question of concurrence as required by the SPRIN= G charter > > > with the Internet ADs and SPRING chairs. They quite reasonably asked me > > > to write a note to 6man explaining the concerns as clearly as= a can, so > > > that they can then determine how to proceed. > > > > > > The questions that prompted my inquiry are: > > > > > > 1) Does the placement of a list of sids in the IPv6 DA field = change > > the > > > IPv6 architectural description of that field. > > > 2) Does the operation of shifting information around in the I= Pv6 > > > destination address field represent a modification or extensi= on of the > > > IPv6 data plane. > > > > > > On a related note, the document in question also defines two = other > > > flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The > > > NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-= C_SID > > > flavor operation, so seems to be affected by the same question. > > > > > > From my own reading, it appears that the REPLACE-C-SID flavo= r > > does not > > > raise issues requiring 6man leadership concurrence. > > > > > > Yours, > > > Joel M. Halpern for the SPRING working group > > > > > > > > > PS: > > > Clearly, understanding the question requires some understanding of what > > > the NEXT-C_SID flavor does. This explanation is a simplification for > > > length and context. Really, the best place to understand it = is the > > > draft. However, to give you enough information to let you de= cide > > > whether you care, I will try to provide a fair summary. My a= pologies in > > > advance to the authors for necessary liberties for length. A= lso, > > > discussion of the draft contents (as distinct from the intera= ction with > > > the IPv6 data plane and architecture) belongs on the SPRING l= ist, and > > > should not clutter up 6man. > > > > > > SIDs are the identifiers used in segment routing. > > > In SRv6, as document in the current RFCs, these are 128 bits. > > As > > > defined in the relevant RFCs, SIDs which identify endpoints t= o which > > > packets are directed are identified by endpoint SIDs. These = can have > > > behaviors (decapsulate and forward is one example). They can= have > > > flavors such as where the SRH is removed. > > > > > > The topic under discussion is means to compress these SIDs in= the > > > packets on the wire. The document under discussion provides = three > > > flavors of compression. > > > > > > The fundamental mechanism of the draft is to use a single SRH entry > > as a > > > container for multiple SIDs. In the NEXT-C_SID mechanism, wh= en it is > > > first encountered the entire container is copied into the des= ination > > > address of the IPv6 packet. The container has a common routi= ng prefix > > > used for all the NEXT-C-SID SIDs. It is followed by a sequen= ce of > > > compressed SIDs of a configured length. One could configure 16, 24, or > > > 32 bits. Or whatever length. The routing advertisements > > are arranged > > > so that the IPv6 packet is directed to the node represented b= y the first > > > compressed SID on the basis of longest prefix match matching = the > > > combination of the common routing prefix and that compressed SID. > > > > > > When the packet arrives at that node, it looks up the configu= red > > > portion, the compressed SID, and determines the behavior and = flavor. In > > > the case of the NEXT-C-SID flavor, the resulting operation is= to shift > > > the entire remaining contents of the IPv6 address (the bits p= ast the > > > first compressed sid) so as to over-write the first compresse= d SID. 0 > > > bits are shifted into the low order positions. If the result= is a > > > non-zero new first compressed SID, then the packets is forwar= ded and the > > > process repeats. When all that is left are 0s, if there is an > > SRH, it > > > is consulted to find the next SRH entry, which is, per normal= SRv6 > > > processing, put into the IPv6 DA. > > > Note that in the common case where the SIDS needed all fit in= to a > > > single container, the analysis also assumes the use of the re= duced > > > encapsulation options which omits the SRH that is not needed = as it would > > > have no entries. This the packet contains a normal IPv6 head= er, with a > > > sequence of compressed SIDs (what one might or might not call= a source > > > route) in the IPv6 destination address field. > > > > > > PPS: If the authors of the NEXT-C-SID flavor feel I have mis-represented > > > the work, please, send clarifications or corrections. Again= , the best > > > source of information is the draft itself. I was asked to pr= ovide extra > > > context in this email. > > > > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org > > > > https://www.ietf.org/mailman/listinfo/spring > > > > > > > > > > -----------------------------------------------------------------= --- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ip= v6 > > > -----------------------------------------------------------------= --- > > > > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring > --_000_BN6PR11MB4081984D4640339B6697B1E2C8BB9BN6PR11MB4081namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

    Hi Brian,

    > Would it change your examples if you used 2001:db8:a:1100::1 instea= d?

    No it would not change the examples, any other assignment for loopback i= nterfaces works the same.

     

    > Still, using IID =3D=3D 0 seems to be asking for trouble, since it'= s a reserved value and is definitely special-cased in some code. Unless, th= at is, you want exactly the properties described in RFC4291 section 2.6.1 (thanks, Mark Smith).

    As Michael described, this assignment to loopback interfaces works fine.=   The addresses are assigned as /128=92s, not prefixes, the router sub= net anycast concern is not applicable.

     

    Thanks,

      Darren

     

    From: Brian E Carpenter <brian.e.carpenter= @gmail.com>
    Sent: Sunday, October 17, 2021 6:15 PM
    To: Darren Dukes (ddukes); Mark Smith
    Cc: SPRING WG List; 6man WG; Francois Clad (fclad)
    Subject: Re: [spring] Question from SPRING regarding draft-filsfilsc= heng-spring-srv6-srh-compression

     

    On 18-Oct-21 09:28, D= arren Dukes (ddukes) wrote:
    > Hi Brian, the draft says:
    >
    >    Loopback interface addresses are allocated from the prefi= x
    >    2001:db8:a::/48.
    >
    > In the examples 2001:db8:a:1100:: is the IPv6 address assigned to the = loopback interface of node 11.


    Still, using IID =3D=3D 0 seems to be asking for trouble, since it's a rese= rved value and is definitely special-cased in some code. Unless, that is, y= ou want exactly the properties described in RFC4291 section 2.6.1 (thanks, = Mark Smith).

    Would it change your examples if you used 2001:db8:a:1100::1 instead?

       Brian

    >
    >  
    >
    > Darren
    >
    >  
    >
    >  
    >
    >  
    >
    > On 2021-10-17, 2:06 AM, "ipv6" <ipv6-bounces@ietf.org>= wrote:
    >
    >  
    >
    > Ah, thanks, that's the sort of thing you can only know by knowing it := -). Ok, so my question about the examples supplied stands. Using this as a
    source address has interesting implications.
    >
    > Regards,
    >     Brian Carpenter
    >     (via tiny screen & keyboard)
    >
    >  
    >
    > On Sun, 17 Oct 2021, 18:58 Mark Smith, <markzzzsmith@gmail.com <= mailto:markzzzsmith@gmail.com= >> wrote:
    >
    >     On Sun, 17 Oct 2021 at 11:32, Brian E Carpente= r
    >     <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com= >> wrote:
    >     >
    >     > Thanks for this draft.
    >     >
    >     > Question: where you show "Source add= ress 2001:db8:a:1100::" is that intended to be the complete address, b= ecause it looks like a prefix? I
    can't find anywhere that an interface identifier of zero is forbidden, but = it's unusual, and can only exist once in a given subnet.
    >     >
    >
    >     The IID value of all zeros is the subnet-route= r anycast address within
    >     a subnet, and is required. See 2.6.1 of RFC429= 1.
    >
    >     For example, Linux automatically configures th= e subnet-router anycast
    >     address for all prefixes on an interface if th= e interface is a
    >     forwarding interface.
    >
    >     [mark@opy ~]$ ip -6 route show table local | g= rep anycast
    >     anycast 2403:5803:XXXX:: dev wlp3s0 proto kern= el metric 0 pref medium
    >     anycast fe80:: dev wlp3s0 proto kernel metric = 0 pref medium
    >     [mark@opy ~]$
    >
    >     (The "local" route table is where th= e interface address and multicast
    >     route route table entries are kept in Linux. T= hey don't all show up
    >     via the normal 'ip addr show' or 'ifconfig' co= mmands).
    >
    >     Regards,
    >     Mark.
    >
    >
    >     > Regards
    >     >    Brian Carpenter
    >     >
    >     > On 16-Oct-21 10:55, Francois Clad (fclad)= wrote:
    >     > > Hello Erik,
    >     > >
    >     > >
    >     > >
    >     > > You may find some examples here: https://datatracker.ietf.org/doc/draft-clad-spring-srv6-srh-compression-ill= us/ <https://datatracker.ietf.org/doc/draft-clad-spr= ing-srv6-srh-compression-illus/> <https://datatracker.ietf.org/doc/draft-clad-spring-srv6-srh-compressio= n-illus/ <https://datatracker.ietf.org/doc/draft-clad-sp= ring-srv6-srh-compression-illus/>>
    >     > >
    >     > >
    >     > >
    >     > > Hope this helps.
    >     > >
    >     > >
    >     > >
    >     > > Thanks,
    >     > >
    >     > > Francois
    >     > >
    >     > >
    >     > >
    >     > > *From: *spring <spring-bounces@ie= tf.org <mailto:spring-bounces= @ietf.org>> on behalf of Erik Kline <ek.ietf@gmail.com <mailto:ek.ietf@gmail.com>>
    >     > > *Date: *Thursday, 14 October 2021 at= 19:06
    >     > > *To: *Joel M. Halpern <jmh@joelha= lpern.com <mailto:jmh@joelhalpern= .com>>
    >     > > *Cc: *spring@ietf.org <mailto:spring@ietf.org> <spring@ietf.org
    <mailto:spring@ietf.org>>, = ipv6@ietf.org <mailto:ipv6@ietf.org= > <ipv6@ietf.org <mailto:ipv6@iet= f.org>>
    >     > > *Subject: *Re: [spring] Question fro= m SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression
    >     > >
    >     > > Joel,
    >     > >
    >     > >
    >     > >
    >     > > Thank you for your email.  The = ADs and chairs have been discussing.
    >     > >
    >     > >
    >     > >
    >     > > One thing that would be very helpful= to our discussions would be some worked examples of the various C-SID beha= viors, showing some SRv6 datagrams and what happens to their contents as th= ey move across some suitable example SR domain.
    >     > >
    >     > >
    >     > >
    >     > > (It would also be helpful if they sh= owed what happens to something like
    >     > an ICMPv6 Echo Request to a representativ= e Destination Address in
    these cases when, say, an SRH is not present, i.e. to see when typical unic= ast semantics are preserved or when something more like anycast or multicas= t behavior is to be expected.)
    >     > >
    >     > >
    >     > >
    >     > > Assuming some forthcoming helpful ex= amples, we have a goal to get a more complete answer back to you by the lat= ter half of next week.
    >     > >
    >     > >
    >     > >
    >     > > Thanks,
    >     > >
    >     > > -Erik
    >     > >
    >     > >
    >     > >
    >     > > On Tue, Oct 12, 2021 at 8:53 PM Joel= M. Halpern <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com> <mailto:jmh@joelhalpern.com <<= a href=3D"mailto:jmh@joelhalpern.com">mailto:jmh@joelhalpern.com>>= ;> wrote:
    >     > >
    >     > >     The SPRING workin= g group is in the midst of an adoption call on
    >     > >     https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/ <https://datatracker.ietf.org/doc/draft-= filsfilscheng-spring-srv6-srh-compression/> <https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-c= ompression/ <https://datatracker.ietf.org/doc/draft-f= ilsfilscheng-spring-srv6-srh-compression/>>.
    >     > >
    >     > >     The SPRING charte= r has text that is explicit
    that modifications to data
    >     > >     planes and archit= ectures standardized by other working groups may not be
    >     > >     modified in SPRIN= G unless the chairs and ADs
    responsible for that data
    >     > >     plane and / or ar= chitecture agree.
    >     > >
    >     > >     To complete the c= ontext, as my SPRING co-chairs are co-authors on the
    >     > >     document in quest= ion, they have recused themselves from decisional
    >     > >     activities regard= ing the document.  Therefore, this message is
    >     > coming
    >     > >     just from my as t= he responsible SPRING co-chair managing this adoption call.
    >     > >
    >     > >     As you have seen,= multiple questions have been raised about the
    >     > >     relationship of t= he document to the IPv6 defined data plane and
    >     > >     architecture (par= ticularly RFC 4291 and 8200). In particular the
    >     > >     questions seem to= revolve around what the document describes as the
    >     > >     NEXT-C-SID flavor= of compressed SID, and its
    relationship to the IPv6
    >     > >     standards.  = (For those seeking more context without reading the full
    >     > >     document, a parap= hrase and simplification of
    the NEXT-C_SID flavor is
    >     > >     provided as a pos= tscript.)
    >     > >
    >     > >     I raised the ques= tion of concurrence as required by the SPRING charter
    >     > >     with the Internet= ADs and SPRING chairs. 
    They quite reasonably asked me
    >     > >     to write a note t= o 6man explaining the concerns as clearly as a can, so
    >     > >     that they can the= n determine how to proceed.
    >     > >
    >     > >     The questions tha= t prompted my inquiry are:
    >     > >
    >     > >     1) Does the place= ment of a list of sids in the IPv6 DA field change
    >     > the
    >     > >     IPv6 architectura= l description of that field.
    >     > >     2) Does the opera= tion of shifting information around in the IPv6
    >     > >     destination addre= ss field represent a modification or extension of the
    >     > >     IPv6 data plane.<= br> >     > >
    >     > >     On a related note= , the document in question also defines two other
    >     > >     flavors, REPLACE-= C-SID, and NEXT-and-REPLACE-C-SID.  The
    >     > >     NEXT-and-REPLACE-= C_SID flavor is defined to include the NEXT-C_SID
    >     > >     flavor operation,= so seems to be affected by
    the same question.
    >     > >
    >     > >      From my own read= ing, it appears that the REPLACE-C-SID flavor
    >     > does not
    >     > >     raise issues requ= iring 6man leadership concurrence.
    >     > >
    >     > >     Yours,
    >     > >     Joel M. Halpern f= or the SPRING working group
    >     > >
    >     > >
    >     > >     PS:
    >     > >     Clearly, understa= nding the question requires
    some understanding of what
    >     > >     the NEXT-C_SID fl= avor does.   This
    explanation is a simplification for
    >     > >     length and contex= t.  Really, the best place to understand it is the
    >     > >     draft.  Howe= ver, to give you enough information to let you decide
    >     > >     whether you care,= I will try to provide a fair summary.  My apologies in
    >     > >     advance to the au= thors for necessary liberties for length.  Also,
    >     > >     discussion of the= draft contents (as distinct from the interaction with
    >     > >     the IPv6 data pla= ne and architecture) belongs on the SPRING list, and
    >     > >     should not clutte= r up 6man.
    >     > >
    >     > >     SIDs are the iden= tifiers used in segment routing.
    >     > >     In SRv6, as docum= ent in the current RFCs, these are 128 bits.
    >     >  As
    >     > >     defined in the re= levant RFCs, SIDs which identify endpoints to which
    >     > >     packets are direc= ted are identified by endpoint SIDs.  These can have
    >     > >     behaviors (decaps= ulate and forward is one example).  They can have
    >     > >     flavors such as w= here the SRH is removed.
    >     > >
    >     > >     The topic under d= iscussion is means to compress these SIDs in the
    >     > >     packets on the wi= re.  The document under discussion provides three
    >     > >     flavors of compre= ssion.
    >     > >
    >     > >     The fundamental m= echanism of the draft is to
    use a single SRH entry
    >     > as a
    >     > >     container for mul= tiple SIDs.  In the NEXT-C_SID mechanism, when it is
    >     > >     first encountered= the entire container is copied into the desination
    >     > >     address of the IP= v6 packet.  The container has a common routing prefix
    >     > >     used for all the = NEXT-C-SID SIDs.  It is followed by a sequence of
    >     > >     compressed SIDs o= f a configured length. 
    One could configure 16, 24, or
    >     > >     32 bits.  Or= whatever length.  The
    routing advertisements
    >     > are arranged
    >     > >     so that the IPv6 = packet is directed to the node represented by the first
    >     > >     compressed SID on= the basis of longest prefix match matching the
    >     > >     combination of th= e common routing prefix and
    that compressed SID.
    >     > >
    >     > >     When the packet a= rrives at that node, it looks up the configured
    >     > >     portion, the comp= ressed SID, and determines the behavior and flavor.  In
    >     > >     the case of the N= EXT-C-SID flavor, the resulting operation is to shift
    >     > >     the entire remain= ing contents of the IPv6 address (the bits past the
    >     > >     first compressed = sid) so as to over-write the first compressed SID.  0
    >     > >     bits are shifted = into the low order positions.  If the result is a
    >     > >     non-zero new firs= t compressed SID, then the packets is forwarded and the
    >     > >     process repeats.&= nbsp; When all that is left
    are 0s, if there is an
    >     > SRH, it
    >     > >     is consulted to f= ind the next SRH entry, which is, per normal SRv6
    >     > >     processing, put i= nto the IPv6 DA.
    >     > >     Note that in the = common case where the SIDS needed all fit in to a
    >     > >     single container,= the analysis also assumes the use of the reduced
    >     > >     encapsulation opt= ions which omits the SRH that is not needed as it would
    >     > >     have no entries.&= nbsp; This the packet contains a normal IPv6 header, with a
    >     > >     sequence of compr= essed SIDs (what one might or might not call a source
    >     > >     route) in the IPv= 6 destination address field.
    >     > >
    >     > >     PPS: If the autho= rs of the NEXT-C-SID flavor
    feel I have mis-represented
    >     > >     the work, please,= send clarifications or corrections.   Again, the best
    >     > >     source of informa= tion is the draft itself.  I was asked to provide extra
    >     > >     context in this e= mail.
    >     > >
    >     > >     _________________= ______________________________
    >     > >     spring mailing li= st
    >     > >     spring@ietf.org &= lt;mailto:spring@ietf.org> <ma= ilto:spring@ietf.org <mailto:spring@i= etf.org>>
    >     > >     https://www.ietf.org/mailman/listin= fo/spring
    <https://www.ie= tf.org/mailman/listinfo/spring> <https://www.ietf.org/mailman/lis= tinfo/spring <h= ttps://www.ietf.org/mailman/listinfo/spring>>
    >     > >
    >     > >
    >     > > ------------------------------------= --------------------------------
    >     > > IETF IPv6 working group mailing list=
    >     > > ipv6@ietf.org <mailto:ipv6@ietf.org>
    >     > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https://www.ietf.org/mailman/listinfo/ipv6>
    >     > > ------------------------------------= --------------------------------
    >     > >
    >     >
    >     > _________________________________________= ______
    >     > spring mailing list
    >     > spring@ietf.org <    mailto:spring@ietf.org>
    >     > https://www.ietf.org/mailman/listinfo/spring <https://www.ietf.org/mai= lman/listinfo/spring>
    >

    --_000_BN6PR11MB4081984D4640339B6697B1E2C8BB9BN6PR11MB4081namp_-- From nobody Sun Oct 17 19:53:49 2021 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 BA1A03A0CFC; Sun, 17 Oct 2021 19:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 8qgYlMe5O4Ss; Sun, 17 Oct 2021 19:53:42 -0700 (PDT) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (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 EC5573A0CFA; Sun, 17 Oct 2021 19:53:41 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id gn3so5671664pjb.0; Sun, 17 Oct 2021 19:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=z9uNrmnuAN5D/7Am+SVdhwEOWHKpOSmKVK2+k18asjc=; b=S5RIUmO7YkVFJXwcnB7xjr8dtrnkZXyrUHpnGlZffIqbskib6IRmEcb2XeSPVvf45W xAe05DYcSioDWWdTkjbVIZz6dG4NWxzJ0wuoNB7fJAymwAyC0BaOSofF56c+kEOt+4hL 1TM0srwUBEBIzGEUfM8WGXpvcVc8fEIJBD7WrJtloyq6U1kkL/PEP423eFD3tcZv5ArB ip7QxFH9SPLImlRFtaqmcwTM/kgkPtf+pM2WehGzLkqpOBiKDLVBOBOKTWGsvHp4x0v8 OHWdp8ohOcWiFnurM3SytE3Sdf0f3uxlNYpNn0J7MFoRBC3UOG1pRqpj60qGlYtrNH8d iPXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=z9uNrmnuAN5D/7Am+SVdhwEOWHKpOSmKVK2+k18asjc=; b=BQz4c02xvScSLha+W7V7OujvQQNeEgKcJlTcbeXjWtgqh7suTrCIjt+ms3JXydjN5H DxgDIyJk2OOD5XBTmwA+XOBXqFoOlCNCT3tcdLyi599ngS4F5cjgDgYyj5+nHRekiX2H /cQ8m0F3ItB6Y4xu37PRDYPj66zjGj2jTkJ/5QpMu8OCncSvW3sR9tFN4fKN2dB7eGeg BJpZzvmH+vmKDynB+z+ZsQhO2bUMHm6FGO7z8d/es7zZ6rrUl9fk6lVV23PHz16idnj2 Mo6ripeEHQ+OjZAysxR1gw4OHcM17SE9GJh7WmeFqeN6YiVzET1FeWVuxAspBjrFAxyn 0+dw== X-Gm-Message-State: AOAM5326+ORrQEqFpUhWIIoxKJQ84F5JkdLzF+gDGu709KJJx8HNrnup uCYVTL3OZP4Rxtk+7V0WCb2W4KFTNSxdMA== X-Google-Smtp-Source: ABdhPJwdxe2MhdItyKAdYbQUyMQkKWFjpeiuT+lF0Vl/3Gq6uAAlYMUUfBjEa7IXZBSRNkq1SJCeKA== X-Received: by 2002:a17:902:9a97:b0:13e:2da4:8132 with SMTP id w23-20020a1709029a9700b0013e2da48132mr24517209plp.34.1634525620927; Sun, 17 Oct 2021 19:53:40 -0700 (PDT) Received: from ?IPv6:2406:e003:102d:e801:db7:d041:a2d:ce65? ([2406:e003:102d:e801:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id j6sm2601748pgf.60.2021.10.17.19.53.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 17 Oct 2021 19:53:40 -0700 (PDT) To: "Darren Dukes (ddukes)" , Mark Smith Cc: SPRING WG List , 6man WG , "Francois Clad (fclad)" References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <6baed9dc-36c6-720b-0a73-0af7f062cb6a@gmail.com> From: Brian E Carpenter Message-ID: <3caff2d3-3bf5-e840-be5c-f0606ecc5e20@gmail.com> Date: Mon, 18 Oct 2021 15:53:37 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 18 Oct 2021 02:53:48 -0000 On 18-Oct-21 14:30, Darren Dukes (ddukes) wrote: > Hi Brian, >=20 >> Would it change your examples if you used 2001:db8:a:1100::1 instead? >=20 > No it would not change the examples, any other assignment for loopback = interfaces works the same. OK, that's helpful. >> Still, using IID =3D=3D 0 seems to be asking for trouble, since it's a=20 reserved value and is definitely special-cased in some code. Unless, that=20 is, you want exactly the properties described in RFC4291 section 2.6.1 (t= hanks, Mark Smith). >=20 > As Michael described, this assignment to loopback interfaces works fine= =2E=C2=A0 The addresses are assigned as /128=E2=80=99s, not prefixes, the=20 router subnet anycast concern is not applicable. I'm not sure about that. Is there a risk that ICMP replies sent to such a= n address might get lost? Standard host stacks identify any such address = as a router when they save it in the neighbor cache. My home router decli= nes to answer ICMP pings sent to such an address. (Try pinging fe80::) Ho= wever, that is not our problem here. On the other hand, it seems that as the compressed SIDs are shifted out o= ne at a time, we will end up with an effective zero IID at the final reci= pient. So the DA would then be a subnet router anycast address, according=20 to RFC4291. That seems a bit strange and might have unexpected consequenc= es, such as more than one box handling the packet and decapsulating it. Brian >=20 > =C2=A0 >=20 > Thanks, >=20 > =C2=A0 Darren >=20 > =C2=A0 >=20 > -----------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= -------------------------------------------------------------------------= ------------------------------------------- >=20 > *From:* Brian E Carpenter > *Sent:* Sunday, October 17, 2021 6:15 PM > *To:* Darren Dukes (ddukes); Mark Smith > *Cc:* SPRING WG List; 6man WG; Francois Clad (fclad) > *Subject:* Re: [spring] Question from SPRING regarding draft-filsfilsch= eng-spring-srv6-srh-compression >=20 > =C2=A0 >=20 > On 18-Oct-21 09:28, Darren Dukes (ddukes) wrote: >> Hi Brian, the draft says: >> >> =C2=A0=C2=A0 Loopback interface addresses are allocated from the prefi= x >> =C2=A0=C2=A0 2001:db8:a::/48. >> >> In the examples 2001:db8:a:1100:: is the IPv6 address assigned to the = loopback interface of node 11. >=20 >=20 > Still, using IID =3D=3D 0 seems to be asking for trouble, since it's a = reserved value and is definitely special-cased in some code. Unless, that=20 is, you want exactly the properties described in RFC4291 section 2.6.1 (t= hanks, Mark Smith). >=20 > Would it change your examples if you used 2001:db8:a:1100::1 instead? >=20 > =C2=A0=C2=A0 Brian >=20 >> >> =C2=A0 >> >> Darren >> >> =C2=A0 >> >> =C2=A0 >> >> =C2=A0 >> >> On 2021-10-17, 2:06 AM, "ipv6" wrote: >> >> =C2=A0 >> >> Ah, thanks, that's the sort of thing you can only know by knowing it := -). Ok, so my question about the examples supplied stands. Using this as = a > source address has interesting implications. >> >> Regards, >> =C2=A0=C2=A0=C2=A0 Brian Carpenter >> =C2=A0=C2=A0=C2=A0 (via tiny screen & keyboard) >> >> =C2=A0 >> >> On Sun, 17 Oct 2021, 18:58 Mark Smith, >> wrote: >> >>=C2=A0=C2=A0=C2=A0=C2=A0 On Sun, 17 Oct 2021 at 11:32, Brian E Carpente= r >>=C2=A0=C2=A0=C2=A0=C2=A0 >> wrote: >>=C2=A0=C2=A0=C2=A0=C2=A0 > >>=C2=A0=C2=A0=C2=A0=C2=A0 > Thanks for this draft. >>=C2=A0=C2=A0=C2=A0=C2=A0 > >>=C2=A0=C2=A0=C2=A0=C2=A0 > Question: where you show "Source address 200= 1:db8:a:1100::" is that intended to be the complete address, because it l= ooks like a prefix? I > can't find anywhere that an interface identifier of zero is forbidden, = but it's unusual, and can only exist once in a given subnet. >>=C2=A0=C2=A0=C2=A0=C2=A0 > >> >>=C2=A0=C2=A0=C2=A0=C2=A0 The IID value of all zeros is the subnet-route= r anycast address within >>=C2=A0=C2=A0=C2=A0=C2=A0 a subnet, and is required. See 2.6.1 of RFC429= 1. >> >>=C2=A0=C2=A0=C2=A0=C2=A0 For example, Linux automatically configures th= e subnet-router anycast >>=C2=A0=C2=A0=C2=A0=C2=A0 address for all prefixes on an interface if th= e interface is a >>=C2=A0=C2=A0=C2=A0=C2=A0 forwarding interface. >> >>=C2=A0=C2=A0=C2=A0=C2=A0 [mark@opy ~]$ ip -6 route show table local | g= rep anycast >>=C2=A0=C2=A0=C2=A0=C2=A0 anycast 2403:5803:XXXX:: dev wlp3s0 proto kern= el metric 0 pref medium >>=C2=A0=C2=A0=C2=A0=C2=A0 anycast fe80:: dev wlp3s0 proto kernel metric = 0 pref medium >>=C2=A0=C2=A0=C2=A0=C2=A0 [mark@opy ~]$ >> >>=C2=A0=C2=A0=C2=A0=C2=A0 (The "local" route table is where the interfac= e address and multicast >>=C2=A0=C2=A0=C2=A0=C2=A0 route route table entries are kept in Linux. T= hey don't all show up >>=C2=A0=C2=A0=C2=A0=C2=A0 via the normal 'ip addr show' or 'ifconfig' co= mmands). >> >>=C2=A0=C2=A0=C2=A0=C2=A0 Regards, >>=C2=A0=C2=A0=C2=A0=C2=A0 Mark. >> >> >>=C2=A0=C2=A0=C2=A0=C2=A0 > Regards >>=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 =C2=A0 Brian Carpenter >>=C2=A0=C2=A0=C2=A0=C2=A0 > >>=C2=A0=C2=A0=C2=A0=C2=A0 > On 16-Oct-21 10:55, Francois Clad (fclad) wr= ote: >>=C2=A0=C2=A0=C2=A0=C2=A0 > > Hello Erik, >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > You may find some examples here: https://d= atatracker.ietf.org/doc/draft-clad-spring-srv6-srh-compression-illus/ > >> >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > Hope this helps. >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > Thanks, >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > Francois >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > *From: *spring >> on behal= f of Erik Kline >> >>=C2=A0=C2=A0=C2=A0=C2=A0 > > *Date: *Thursday, 14 October 2021 at 19:06= >>=C2=A0=C2=A0=C2=A0=C2=A0 > > *To: *Joel M. Halpern >> >>=C2=A0=C2=A0=C2=A0=C2=A0 > > *Cc: *spring@ietf.org > >>, ipv6@ietf.org > >> >>=C2=A0=C2=A0=C2=A0=C2=A0 > > *Subject: *Re: [spring] Question from SPRI= NG regarding draft-filsfilscheng-spring-srv6-srh-compression >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > Joel, >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > Thank you for your email.=C2=A0 The ADs an= d chairs have been discussing. >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > One thing that would be very helpful to ou= r discussions would be some worked examples of the various C-SID behavior= s, showing some SRv6 datagrams and what happens to their contents as they=20 move across some suitable example SR domain. >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > (It would also be helpful if they showed w= hat happens to something like >>=C2=A0=C2=A0=C2=A0=C2=A0 > an ICMPv6 Echo Request to a representative D= estination Address in > these cases when, say, an SRH is not present, i.e. to see when typical = unicast semantics are preserved or when something more like anycast or mu= lticast behavior is to be expected.) >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > Assuming some forthcoming helpful examples= , we have a goal to get a more complete answer back to you by the latter = half of next week. >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > Thanks, >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > -Erik >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > On Tue, Oct 12, 2021 at 8:53 PM Joel M. Ha= lpern > >>> wrote: >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0The SPRING working grou= p is in the midst of an adoption call on >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0https://datatracker.iet= f.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > >>. >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0The SPRING charter has = text that is explicit > that modifications to data >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0planes and architecture= s standardized by other working groups may not be >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0modified in SPRING unle= ss the chairs and ADs > responsible for that data >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0plane and / or architec= ture agree. >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0To complete the context= , as my SPRING co-chairs are co-authors on the >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0document in question, t= hey have recused themselves from decisional >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0activities regarding th= e document.=C2=A0 Therefore, this message is >>=C2=A0=C2=A0=C2=A0=C2=A0 > coming >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0just from my as the res= ponsible SPRING co-chair managing this adoption call. >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0As you have seen, multi= ple questions have been raised about the >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0relationship of the doc= ument to the IPv6 defined data plane and >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0architecture (particula= rly RFC 4291 and 8200). In particular the >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0questions seem to revol= ve around what the document describes as the >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0NEXT-C-SID flavor of co= mpressed SID, and its > relationship to the IPv6 >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0standards.=C2=A0 (For t= hose seeking more context without reading the full >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0document, a paraphrase = and simplification of > the NEXT-C_SID flavor is >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0provided as a postscrip= t.) >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0I raised the question o= f concurrence as required by the SPRING charter >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0with the Internet ADs a= nd SPRING chairs.=C2=A0 > They quite reasonably asked me >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0to write a note to 6man=20 explaining the concerns as clearly as a can, so >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0that they can then dete= rmine how to proceed. >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0The questions that prom= pted my inquiry are: >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A01) Does the placement o= f a list of sids in the IPv6 DA field change >>=C2=A0=C2=A0=C2=A0=C2=A0 > the >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0IPv6 architectural desc= ription of that field. >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A02) Does the operation o= f shifting information around in the IPv6 >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0destination address fie= ld represent a modification or extension of the >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0IPv6 data plane. >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0On a related note, the = document in question also defines two other >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0flavors, REPLACE-C-SID,=20 and NEXT-and-REPLACE-C-SID.=C2=A0 The >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0NEXT-and-REPLACE-C_SID = flavor is defined to include the NEXT-C_SID >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0flavor operation, so se= ems to be affected by > the same question. >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0 From my own reading, i= t appears that the REPLACE-C-SID flavor >>=C2=A0=C2=A0=C2=A0=C2=A0 > does not >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0raise issues requiring = 6man leadership concurrence. >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0Yours, >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0Joel M. Halpern for the=20 SPRING working group >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0PS: >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0Clearly, understanding = the question requires > some understanding of what >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0the NEXT-C_SID flavor d= oes.=C2=A0 =C2=A0This > explanation is a simplification for >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0length and context.=C2=A0=20 Really, the best place to understand it is the >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0draft.=C2=A0 However, t= o give you enough information to let you decide >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0whether you care, I wil= l try to provide a fair summary.=C2=A0 My apologies in >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0advance to the authors = for necessary liberties for length.=C2=A0 Also, >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0discussion of the draft=20 contents (as distinct from the interaction with >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0the IPv6 data plane and=20 architecture) belongs on the SPRING list, and >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0should not clutter up 6= man. >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0SIDs are the identifier= s used in segment routing. >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0In SRv6, as document in=20 the current RFCs, these are 128 bits. >>=C2=A0=C2=A0=C2=A0=C2=A0 >=C2=A0 As >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0defined in the relevant=20 RFCs, SIDs which identify endpoints to which >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0packets are directed ar= e identified by endpoint SIDs.=C2=A0 These can have >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0behaviors (decapsulate = and forward is one example).=C2=A0 They can have >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0flavors such as where t= he SRH is removed. >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0The topic under discuss= ion is means to compress these SIDs in the >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0packets on the wire.=C2= =A0 The document under discussion provides three >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0flavors of compression.= >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0The fundamental mechani= sm of the draft is to > use a single SRH entry >>=C2=A0=C2=A0=C2=A0=C2=A0 > as a >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0container for multiple = SIDs.=C2=A0 In the NEXT-C_SID mechanism, when it is >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0first encountered the e= ntire container is copied into the desination >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0address of the IPv6 pac= ket.=C2=A0 The container has a common routing prefix >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0used for all the NEXT-C= -SID SIDs.=C2=A0 It is followed by a sequence of >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0compressed SIDs of a co= nfigured length.=C2=A0 > One could configure 16, 24, or >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A032 bits.=C2=A0 Or whate= ver length.=C2=A0 The > routing advertisements >>=C2=A0=C2=A0=C2=A0=C2=A0 > are arranged >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0so that the IPv6 packet=20 is directed to the node represented by the first >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0compressed SID on the b= asis of longest prefix match matching the >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0combination of the comm= on routing prefix and > that compressed SID. >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0When the packet arrives=20 at that node, it looks up the configured >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0portion, the compressed=20 SID, and determines the behavior and flavor.=C2=A0 In >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0the case of the NEXT-C-= SID flavor, the resulting operation is to shift >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0the entire remaining co= ntents of the IPv6 address (the bits past the >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0first compressed sid) s= o as to over-write the first compressed SID.=C2=A0 0 >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0bits are shifted into t= he low order positions.=C2=A0 If the result is a >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0non-zero new first comp= ressed SID, then the packets is forwarded and the >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0process repeats.=C2=A0 = When all that is left > are 0s, if there is an >>=C2=A0=C2=A0=C2=A0=C2=A0 > SRH, it >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0is consulted to find th= e next SRH entry, which is, per normal SRv6 >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0processing, put into th= e IPv6 DA. >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0Note that in the common=20 case where the SIDS needed all fit in to a >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0single container, the a= nalysis also assumes the use of the reduced >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0encapsulation options w= hich omits the SRH that is not needed as it would >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0have no entries.=C2=A0 = This the packet contains a normal IPv6 header, with a >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0sequence of compressed = SIDs (what one might or might not call a source >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0route) in the IPv6 dest= ination address field. >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0PPS: If the authors of = the NEXT-C-SID flavor > feel I have mis-represented >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0the work, please, send = clarifications or corrections.=C2=A0 =C2=A0Again, the best >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0source of information i= s the draft itself.=C2=A0 I was asked to provide extra >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0context in this email. >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0_______________________= ________________________ >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0spring mailing list >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0spring@ietf.org > >> >>=C2=A0=C2=A0=C2=A0=C2=A0 > >=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/ma= ilman/listinfo/spring > > >> >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > ------------------------------------------= -------------------------- >>=C2=A0=C2=A0=C2=A0=C2=A0 > > IETF IPv6 working group mailing list >>=C2=A0=C2=A0=C2=A0=C2=A0 > > ipv6@ietf.org > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > Administrative Requests: https://www.ietf.= org/mailman/listinfo/ipv6 > >>=C2=A0=C2=A0=C2=A0=C2=A0 > > ------------------------------------------= -------------------------- >>=C2=A0=C2=A0=C2=A0=C2=A0 > > >>=C2=A0=C2=A0=C2=A0=C2=A0 > >>=C2=A0=C2=A0=C2=A0=C2=A0 > ____________________________________________= ___ >>=C2=A0=C2=A0=C2=A0=C2=A0 > spring mailing list >>=C2=A0=C2=A0=C2=A0=C2=A0 > spring@ietf.org > >>=C2=A0=C2=A0=C2=A0=C2=A0 > https://www.ietf.org/mailman/listinfo/spring=20 > >> >=20 From nobody Sun Oct 17 20:16:12 2021 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 3EE273A0DE9; Sun, 17 Oct 2021 20:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 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, FREEMAIL_REPLY=1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 7GzzhGcac7rj; Sun, 17 Oct 2021 20:16:05 -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 C98943A0DE8; Sun, 17 Oct 2021 20:16:05 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id gn3so5700015pjb.0; Sun, 17 Oct 2021 20:16:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=hADBdGLp5e3B4GLci9xwkuP491/kUINHhQV5VotB4Dw=; b=j3CsyQxpf9CARpdPsIU7NbkeG82uvoKKKf4hOlD8GdXq9xL48kSlnDvXylU4pTyRFH zhjUQY8p5IgGOMiT3o1eOGNoWWgOQEwAxqRV/07Zqjh1jFjubDvl5frzo9FTylBd/qsp YNZwJu+Ff6QmFVLbHeNCK57Y25rcWNioKsrt5nAABJtAuMmnwRZiGEBUwWHo77mnKxJz P8md5pHtG4YfmGwZ+067M5gmTTJzY+he0Dj7cbUAriuFNpHPgUpPme1UurN2fMoQ49xA WXxO0LfDzDS+WVr8P4zQ1e4HN+2+L/WFd2Uc6b0jx+pYkiBBKJrNPQx0P9f2/LBw95fM 92ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=hADBdGLp5e3B4GLci9xwkuP491/kUINHhQV5VotB4Dw=; b=1ayHDNlyhHcuSNgS0UN7dXetbgpOyop50TSvT6gc88ojX6y1HaA5RtlIWlu8rxucNL 6X/pmxZgVzec7tFM0Fnkj4LLbZURbl2g5HOVx0Sz3+Dm2/KmyHAuqsjgR45ap8NdDyG6 PWmINVMKM3vAEh2Rkm4yRAAlnZi8EvG9CQnIDzPXi3JDnpgNpAr9f9r3jRtXPXUL+D0P I11TUvHLNdQcCFHYxmF0cJGlusi1uYVLh67IAYiEzhTcRhTI7uv71kDzBC58vPY9Ina2 fm/uf6/OLlyNQFnRpKuistcfF4UeCwsFaHr/zR7EvjP9y5uLVhBsUNNA746nxGjo0pQ5 fEDA== X-Gm-Message-State: AOAM532ZW5SEzlN/anMVWr1/rF54l/t7BiHiYmx4MqJuO37lCPLXKaBW YvuN4YK0Ig5BEp+EbIm8+sc= X-Google-Smtp-Source: ABdhPJyc0ohwD88r5DrMvUE5gjnF/A6qStL1atN12TeaV763zlHfGKZMs28c72njv/PKlcBTtisNDA== X-Received: by 2002:a17:90b:4f8a:: with SMTP id qe10mr30135105pjb.27.1634526964979; Sun, 17 Oct 2021 20:16:04 -0700 (PDT) Received: from ?IPv6:2406:e003:102d:e801:db7:d041:a2d:ce65? ([2406:e003:102d:e801:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id g19sm17706674pjl.25.2021.10.17.20.16.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 17 Oct 2021 20:16:04 -0700 (PDT) To: Tom Herbert Cc: Mark Smith , SPRING WG , 6man WG , Michael Richardson References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <1396_1634278622_61691CDE_1396_28_5_787AE7BB302AE849A7480A190F8B93303542C654@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1101.1634412958@localhost> <5bbcf175-10a7-4839-b968-eea0a0ad8a1b@gmail.com> From: Brian E Carpenter Message-ID: <03daf257-5f80-c156-1645-e4d3e99fb353@gmail.com> Date: Mon, 18 Oct 2021 16:16:01 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] All IPv6 fields are now mutable (Re: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 18 Oct 2021 03:16:10 -0000 On 18-Oct-21 13:35, Tom Herbert wrote: >=20 >=20 > On Sun, Oct 17, 2021, 3:22 PM Brian E Carpenter > wrote: >=20 > On 18-Oct-21 09:39, Tom Herbert wrote: > > On Sat, Oct 16, 2021 at 4:59 PM Mark Smith > wrote: > >> > >> On Sun, 17 Oct 2021, 06:36 Michael Richardson, > wrote: > >>> > >>> Mark Smith > wrote: > >>>=C2=A0 =C2=A0 =C2=A0> In fight changing DAs also will break AH p= rotection of the IPv6 header. > >>> > >>> AH is dead. It's been dead for decades. > >>> I say this as an IPsec enthusiast who wishes this wasn't true. > >>> But it is. > >> > >> > >> Then all IPv6 field immutability while the packet is in flight i= s also dead. > >> > >> "Controlled domain" =3D=3D redefine any field, field semantics, = and field > >> processing we like in an existing protocol, yet claim we're stil= l > >> using the original protocol. > >> > >> That has been tacitly endorsed via standards track RFC8986. The = Next > >> Header field is not supposed to be modified in flight per intern= et > >> standard RFC8200, yet standards track RFC8986 specifies the beha= viour > >> via PSP. > >> > >> This SRH compression ID is redefining the IPv6 DA field semantic= s. It > >> encodes multiple network hop destinations in the single IPv6 > >> destination address field. > >> > >> Structured Flow Label - > >> https://datatracker.ietf.org/doc/draft-filsfils-6man-structured-= flow-label/ > >> is redefining the IPv6 flow label field. > >> > >> This will be an operational nightmare in the future, when there = are > >> multiple applicable RFCs that conflict with each other. I don't = want > >> to have to spend time getting into arguments with vendors about = which > >> protocol variant RFC their implementation should or shouldn't ha= ve to > >> comply with while I have 1000s, 10s or 100s of 1000s of customer= s > >> off-line. > > > > Mark, > > > > I think you might be lumping together several disparate proposals=20 in > > your general claim that "IPv6 field immutability while the packet=20 is > > in flight is also dead". > > > > When SRH was under discussion in 6man there was a lot of work to > > define which fields were immutable and that is described in RFC87= 54. > > Those definitions are sufficient to specify proper interaction be= tween > > SRH and AH, however RFC8754 knowingly breaks AH as that handling = was > > not specified. Some of us did object to that, but I suppose exped= iency > > to publish the protocol won out. Nevertheless, there is nothing t= hat > > prevents someone from properly defining AH usage with SRH. > > > > As for the IPv6 destination address, it was never defined to be a= n > > immutable field inflight. In fact, the core operation of a routin= g > > header is to overwrite the destination address at each intermedia= te > > destination. NAT also changes the DA in flight, but there is a > > significant difference between NAT and the routing header header > > operation: when a routing header is set in a packet the sender kn= ows > > and indicates the destination address. For the purposes of AH or > > transport checksum, both the sender and final receiver use this > > address-- there is no ambiguity and the fact that the destination= > > address is mutable in flight doesn't adversely impact end to end > > protocol operations that operate on the addresses. > > > > We have seen various proposals to steal bits or redefine flow lab= el > > fields, but IMO it's unlikely any of those will ever get consensu= s. > > Hosts routinely set the flow label as an unstructured value, and > > redefining flow label semantics would be a massive retroactive ch= ange > > in deployment. I would point out though, that the flow label is > > technically not immutable in flight, RFC6437 allows it to be modi= fied > > by intermediate nodes for "only for compelling operational securi= ty > > reasons". >=20 > Correct, because it was very clear that some firewalls were going t= o > clobber it whatever we wrote. So we tried to describe behaviour > that would not nullify the usefulness of the field for stateless > load balancing. >=20 >=20 > Brian, >=20 > Thanks for the explanation concerning why the exception was created. Fo= r the concern that the flow label could be used a a covert channel, was t= his a hypothetical possibility or in response to some real events (sendin= g twenty bits at a time doesn't seem like a very effective covert channel=20 compared to other methods :-) ) This was one of the crucial differences between RFC3967 and RFC6437. As I=20 recall, it was started by anecdotal evidence of firewalls zapping the flo= w label, and then we discussed how to deal with this. For example: https://mailarchive.ietf.org/arch/msg/ipv6/0T2gPgciSq6qG-2JGBzHvBuVKb8/ It was discussed at length but (almost inevitably) without input from actual firewall vendors, I believe. Brian >=20 > Tom >=20 >=20 > As for draft-filsfils-6man-structured-flow-label, the problems in h= ttps://mailarchive.ietf.org/arch/browse/ipv6/?gbt=3D1&index=3DqrTou1rjtND= DchE5yFfSN31pkMc > remain unsolved. >=20 > =C2=A0 =C2=A0Brian >=20 From nobody Sun Oct 17 20:43:51 2021 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 2E6DD3A0E09; Sun, 17 Oct 2021 20:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cv55h_MDoxZM; Sun, 17 Oct 2021 20:43:44 -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 99FDC3A0E07; Sun, 17 Oct 2021 20:43:44 -0700 (PDT) Received: from fraeml703-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4HXjMD1P77z67qQW; Mon, 18 Oct 2021 11:40:40 +0800 (CST) Received: from dggeml756-chm.china.huawei.com (10.1.199.158) by fraeml703-chm.china.huawei.com (10.206.15.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.8; Mon, 18 Oct 2021 05:43:40 +0200 Received: from dggeml757-chm.china.huawei.com (10.1.199.137) by dggeml756-chm.china.huawei.com (10.1.199.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.15; Mon, 18 Oct 2021 11:43:39 +0800 Received: from dggeml757-chm.china.huawei.com ([10.1.199.137]) by dggeml757-chm.china.huawei.com ([10.1.199.137]) with mapi id 15.01.2308.015; Mon, 18 Oct 2021 11:43:39 +0800 From: "Pengshuping (Peng Shuping)" To: "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: IETF 112 Slot Requests Thread-Index: AdfD0g0gKR3MrzG+Tai60emOyxI8dA== Date: Mon, 18 Oct 2021 03:43:39 +0000 Message-ID: <76441b1b77ae4aafac1d2f9894c72e55@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.153.179.89] Content-Type: multipart/alternative; boundary="_000_76441b1b77ae4aafac1d2f9894c72e55huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [spring] IETF 112 Slot Requests 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, 18 Oct 2021 03:43:49 -0000 --_000_76441b1b77ae4aafac1d2f9894c72e55huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, The IETF 112 Final Agenda is now available https://datatracker.ietf.org/mee= ting/112/agenda.html and the SPRING session is arranged on Monday as below. Monday, November 8, 2021 12:00-14:00 Monday Session I Room 5 rtg spring Source Packet Routing in Networking We will continue to using the Google Form to collect presentation slot requ= ests in the SPRING WG for this IETF112. Please fill in your request in the = following Form. https://docs.google.com/forms/d/1MkWm0817Qibt1JaOQjaMEmzbWOEJZAA1XxeKvnL2NQ= Q/edit If there is any issue for you to access this Form, please send your request= directly to spring-chairs@ietf.org. Thank you! Best regards, Shuping --_000_76441b1b77ae4aafac1d2f9894c72e55huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Dear all,

     

    The IETF 112 Final Agenda is= now available https://da= tatracker.ietf.org/meeting/112/agenda.html

    and the SPRING session is ar= ranged on Monday as below.

     

    Monday, November 8, 2021

    12:00-14:00

    Monday Session I<= /span>

    Room 5   rtg =    spring Source Packet Routing in Networking

     

    We will continue to using the G= oogle Form to collect presentation slot requests in the SPRING WG for this = IETF112. Please fill in your request in the following Form.

     

    https://docs= .google.com/forms/d/1MkWm0817Qibt1JaOQjaMEmzbWOEJZAA1XxeKvnL2NQQ/edit

     

    If there is any issue for you t= o access this Form, please send your request directly to spring-chairs@ietf.org.<= /o:p>

     

    Thank you!

     

    Best regards,=

    Shuping

    --_000_76441b1b77ae4aafac1d2f9894c72e55huaweicom_-- From nobody Sun Oct 17 23:49:15 2021 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 738A53A11F2; Sun, 17 Oct 2021 23:49:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 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] autolearn=unavailable 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 DeBGl2r5H1wl; Sun, 17 Oct 2021 23:48:57 -0700 (PDT) Received: from clarinet.employees.org (clarinet.employees.org [198.137.202.74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64A223A11F0; Sun, 17 Oct 2021 23:48:57 -0700 (PDT) Received: from astfgl.hanazo.no (ti0389q160-5225.bb.online.no [95.34.0.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 5B9874E11A79; Mon, 18 Oct 2021 06:48:56 +0000 (UTC) Received: from smtpclient.apple (localhost [IPv6:::1]) by astfgl.hanazo.no (Postfix) with ESMTP id E99BD637DFA1; Mon, 18 Oct 2021 08:48:53 +0200 (CEST) From: otroan@employees.org Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_510ADFA8-0EA6-4B25-9033-31408C41D34B"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Date: Mon, 18 Oct 2021 08:48:52 +0200 In-Reply-To: <3caff2d3-3bf5-e840-be5c-f0606ecc5e20@gmail.com> Cc: "Darren Dukes (ddukes)" , Mark Smith , SPRING WG List , 6man WG , "Francois Clad (fclad)" To: Brian E Carpenter References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <6baed9dc-36c6-720b-0a73-0af7f062cb6a@gmail.com> <3caff2d3-3bf5-e840-be5c-f0606ecc5e20@gmail.com> X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 18 Oct 2021 06:49:03 -0000 --Apple-Mail=_510ADFA8-0EA6-4B25-9033-31408C41D34B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >>> Still, using IID =3D=3D 0 seems to be asking for trouble, since it's = a > reserved value and is definitely special-cased in some code. Unless, = that > is, you want exactly the properties described in RFC4291 section 2.6.1 = (thanks, Mark Smith). >>=20 >> As Michael described, this assignment to loopback interfaces works = fine. The addresses are assigned as /128=E2=80=99s, not prefixes, the > router subnet anycast concern is not applicable. >=20 >=20 > I'm not sure about that. Is there a risk that ICMP replies sent to = such an address might get lost? Standard host stacks identify any such = address as a router when they save it in the neighbor cache. My home = router declines to answer ICMP pings sent to such an address. (Try = pinging fe80::) However, that is not our problem here. >=20 > On the other hand, it seems that as the compressed SIDs are shifted = out one at a time, we will end up with an effective zero IID at the = final recipient. So the DA would then be a subnet router anycast = address, according > to RFC4291. That seems a bit strange and might have unexpected = consequences, such as more than one box handling the packet and = decapsulating it. >=20 Just to be clear. An IPv6 node does not make any assumption about the = prefix length. Ref RFC5942. IID has no meaning unless both the address and associated subnet prefix = length is known. I agree with you though, there appears to be a need for clarification = regarding the properties of these addresses. RFC6052 updated 4291 and had the following: When a /32 prefix is used, an all-zero suffix results in an all-zero interface identifier. We understand the conflict with Section 2.6.1 of RFC4291, which specifies that all zeroes are used for the subnet- router anycast address. However, in our specification, there is only one node with an IPv4-translatable IPv6 address in the /64 subnet, so the anycast semantic does not create confusion. We thus decided to keep the null suffix for now. This issue does not exist for prefixes larger than 32 bits, such as the /40, /56, /64, and /96 prefixes that we recommend in Section 3.3. Looks like this issue goes back to RFC8986 or even RFC8754(?) If this is not partiuclar to the srh-compression draft, could a separate document, updating RFC4291, and clarifying the = particular properties of these addresses work? O. --Apple-Mail=_510ADFA8-0EA6-4B25-9033-31408C41D34B 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----- iQIzBAEBCAAdFiEEdu1h07DO3As4hPTA3JCvLd9yNkgFAmFtGNQACgkQ3JCvLd9y Nkg/KA/9HXfREGUAOukFOjDIrCi6tdfKnc7Y74gdI2CCvfW93rbx1H8qK9tWIUwj eQ2CUiOtk5qwuqMMLw5N/z8m9uDGHV/ZV7QvwiQTNDSTmQDjeANoc6AfaBVlHVRa o61lI01DfnCEimcrNHE9GedFxVZyf1xCnTARMHNikDDeZdowUQayCFExANdV1cbP yNenktBTgIaBbJfp51syfJ3/hGFy2DuEjwdjWTiJJ+4Uno3LoIHmvdAHRwdeM9Gp /RaxqEEv2jL8F7LwwJH+WWFroPPjwYEIBEmE/uy4uAP8FU097+XEWdd/8Jk/7SB9 zn1dqGLVNuCHtnBw2piyQgx8Iz2ksH1uuJYAuFYSGqKh0SkwV01OXF4bA9RSJJZI gBT+FEjkEpXpPzm1mocsvXDfYiN03eASHerwgQTGoVt+LcWgjyF8SIEzHPikyC5v jA1fh/0iyNnDBc9jW1i2bs4XF6yPDWUsSxDPZ7MGvVUOR/oBkSWnwxbhN4rkiuGh Um42xrzH1twRH02Xl/SpQ5IZikI0yyGOlD6f8kNOfHJPTS9ump0y+VJzJOMwLT4H 602+17uDL4WOu2NF9SP76o5J3HWOwUs2f3iIkjetHRmusdH48xdw7EoAyJuUIZwS gLoGVjKM170g1JcBKpwbWoaMZguR9ai6sHCtEcD+idGcVXXv3aY= =t283 -----END PGP SIGNATURE----- --Apple-Mail=_510ADFA8-0EA6-4B25-9033-31408C41D34B-- From nobody Mon Oct 18 00:24:37 2021 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 DBFE93A1224; Mon, 18 Oct 2021 00:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 BLYjmA40ChVJ; Mon, 18 Oct 2021 00:23:02 -0700 (PDT) Received: from mail-oi1-x22f.google.com (mail-oi1-x22f.google.com [IPv6:2607:f8b0:4864:20::22f]) (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 1EC103A0A10; Mon, 18 Oct 2021 00:23:02 -0700 (PDT) Received: by mail-oi1-x22f.google.com with SMTP id o204so23117606oih.13; Mon, 18 Oct 2021 00:23:02 -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=kM7Y/johg+4hRz6boZ4XIC649SoNgRJt7G4qNI+RyIQ=; b=j2SQK1UTAHNYd4740BS17cXOlm/dEuiVQ6o1d2hX1QdPZp+cImrXb/TI/+Pbrh70Pe 9c5cQxU7mMK4aulxtUsA5CH7RUPC+TJexg5hFDK2ofWYtmA3y33TAEopd4pN6eJrTazY 4nZm+h/bc64EDhdizrI9WkZ5KAyHYaRtRxJIc8p+OGhUGpdy7+NiuuZsKLxW+aYbR/jR oPwElTFgTTbIiUsJa0ywzSWYui8AokUrpJf0obtID/KZ6Cyg/Ziopxom0t28zlEdg5o4 TYakz9W1j9rgbKhhhFq3farWoZskju005RVf7xbYZ2aDuxtx4mMEkz0xtWpBWxCUS26H ENxg== 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=kM7Y/johg+4hRz6boZ4XIC649SoNgRJt7G4qNI+RyIQ=; b=lKvUuQm5XrSUO5Qr+eQw8js36T6LxS2IwN4jbh8aWyYT6GUlvkC9SQkkIINcCPOaon aiyHMkvLj/EfS077oFp5tLljqd1qmIpDhBV3YaFGcIB81+tm1a46vXS06z/RYABiAytG xwddpkdJbuqmOrOsmnIbhCo7M7I/LWyFHRsDkD6UY9fbwK+3mKHWPKCuufVhtNbaCtEQ dXCLT9S8VX++9lVHVOP/D6LULcQh5ruspk/DaBeWREpEMINkboZSbe8C3g9D/n3iEkFR 8kSeRomOw8Yim1QAQyMPHMLLiSgftoCSLO3jZ4n+QqQfSty03xKKF8QbkKGdrXenGeSX QJMQ== X-Gm-Message-State: AOAM532yttVgmPp2mvd3SkTt6ht9Ex0lU3tw5kcFs6IhMf36k2AmfA8O jvbt+tS6qXsnQyctmTAdCn1smzUGcvduDIiNp/8= X-Google-Smtp-Source: ABdhPJwsoEMENZPQ+pk9y4Yauh4WKxTQt1kQZqOKyOBEVo88JzP0JC2CduR88ldso2irRrY06oYyQIwAnuiT+9gPSnQ= X-Received: by 2002:aca:3d55:: with SMTP id k82mr24549401oia.167.1634541781222; Mon, 18 Oct 2021 00:23:01 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <1daf3d20-22b2-d111-5131-bd53f51c53a3@gmail.com> <60f71d8c-8165-111c-4099-7f926a897d22@gmail.com> <13455849-c0a0-705b-66d8-3b31e7bf95eb@gmail.com> In-Reply-To: <13455849-c0a0-705b-66d8-3b31e7bf95eb@gmail.com> From: Ted Hardie Date: Mon, 18 Oct 2021 08:22:35 +0100 Message-ID: To: Brian E Carpenter Cc: "Joel M. Halpern" , "ipv6@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003d8a7f05ce9b6af2" Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 18 Oct 2021 07:23:07 -0000 --0000000000003d8a7f05ce9b6af2 Content-Type: text/plain; charset="UTF-8" Hi Brian, Thanks for the additional clarification. I've cut below to the meat of what I understand to be your question: On Sat, Oct 16, 2021 at 10:19 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > I want to draw a distinction between unicast address bits that are > arbitrary numbers as far as > the routing system is concerned -- such as the classical IID bits in IPv6 > unicast addresses, or the prefix bits following fc00::/7 -- and address > bits that are meaningful to the routing system, such as fe80::/10 (which > means "do not route this packet"). > > Within an SRV6 domain, with RFC8986 and the current draft, we see > something new: a field which has classically been an arbitrary 64-bit > number for > the routing system (the IID field) becomes meaningful to the routing > system. That's an architectural change, and definitely was not envisaged by > the IPv6 address architecture. > > So, IMHO, the question behind SPRING's question to 6MAN is not whether > there is an architectural change, but whether this changes matters. In > particular, will it have impact on legacy devices and software within the > SRV6 domain, and will it do any damage if it leaks outside the domain? > > Do I understand correctly that you see the same architectural question for RFC 8986 ("will it have an impact on legacy devices and software within the SRV6 domain and will it do any damage if it leaks outside the domain")? Presuming so, the question for RFC 8986 seems to me to be answered within the document with a reference to rfc8754, Section 5, which has the deployment model for segment routing spelled out. Would a similar applicability statement here be something that helps resolve this? At least as far as I can tell, a shift in the formatting to a compressed format doesn't change the basic difference you call out, so I believe that it would be very similar if not identical. But it certainly does no harm to spell that out. regards, Ted Hardie --0000000000003d8a7f05ce9b6af2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable     --00000000000063c7a705ceb0a5d1-- From nobody Tue Oct 19 05:41:58 2021 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 4E4123A0C8B for ; Tue, 19 Oct 2021 05:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 kJvYfGc2EjiO for ; Tue, 19 Oct 2021 05:40:53 -0700 (PDT) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 A5D1A3A0C82 for ; Tue, 19 Oct 2021 05:40:52 -0700 (PDT) Received: by mail-ua1-x92e.google.com with SMTP id a17so8538483uax.12 for ; Tue, 19 Oct 2021 05:40:52 -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=Sjm+AwRYPTUqBYcjtJMfXEXDSN8sl06WL6zFi33MAWs=; b=SFCtuTALoWRI1c6mg/a/ibxERv0l3KVNEuxhHoyiJpcDBl6DfMX0Orq2GGLyAioV2Y T9q1N/TKM5+IKErALiWdsJzYfsWgpaTgEWwSnfampjbDrfx4FuZBptkpIAaEPsljzMCL JTimTcs4xDdIaLVSqKr1SxkjvuHxNUUb0t8BCnVKFSh5HKxQcMagmwRCvj3mXsjUkIwb 7MzwTZHgoGJRA89f8eN2CqcLVxvHDblmW03hntY5cNmgD9x4YpgBQBqUFBBKwxieZCmY O17wV8woFksRsVc5j2EcUZ9HcyjGpWHQAnAscRZYEhsI/uKeVN4qVxSvHGD/qfoH4tjO gcyA== 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=Sjm+AwRYPTUqBYcjtJMfXEXDSN8sl06WL6zFi33MAWs=; b=uX5HOBXW9IYehR2k9AIA1zj4Ycaxykm4IJa9v8201NhoqKknNX0j/APgSwg3v5M2bi hurYgenr9KgJAvJFbObTjVgRjsDIivZaXRqIwV29EvQyfcEpUCrC0E0volVa2YEj+v90 8ebEg12uAVPuMs1BVSnJKjnlWj7bBINZ0WS+Epm5cutidkyYeTTyhdQQcKsZJrjI+U5X xihGX84PO0aETfNYfsOD/e1Jlkdo0xACmnDs3o0EpSCCM35j/8p+/9j+TI+E/UyCelvY 771psTdyHwqn2Xo3EiN497YBciNA3LDtnUT+xh6uNR43DsKAZj5xzJW5QEkp1Cfn8YQw 6fvQ== X-Gm-Message-State: AOAM531Ol0XBLMHadINimTcpwFeshv7kfA9cnBhp7g198PPCMRuS+pK7 ziQZRjVPOXg8LvNyGJ5JS29MrCTYJYz20XtvglVTFA== X-Google-Smtp-Source: ABdhPJwN3pD4sOOiypqAMEa9uHrPthL60Le/iR8VOqlDQWLZPVR/ycclzVb2KS+wD5nj7c7q3Br/cCobDH5jYU8D9Wg= X-Received: by 2002:a9f:2438:: with SMTP id 53mr32046537uaq.116.1634647249501; Tue, 19 Oct 2021 05:40:49 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <26d9fc32-4884-602c-975a-79fc64551727@gmail.com> In-Reply-To: From: Robert Raszuk Date: Tue, 19 Oct 2021 14:40:38 +0200 Message-ID: To: Ted Hardie Cc: Mark Smith , "spring@ietf.org" , "ipv6@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a5200b05ceb3f8c4" Archived-At: Subject: Re: [spring] Administrative interfaces (was draft-filsfilscheng-spring-srv6-srh-compression) 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, 19 Oct 2021 12:40:58 -0000 --000000000000a5200b05ceb3f8c4 Content-Type: text/plain; charset="UTF-8" All, I must say that I am not quite sure what is being discussed here. Today the computer node says linux is also called host. That host has in the kernel multiple routing tables. The same very host (or node) is a home for the number of kube pods which in turn are home for the number of containers. Those run apps. Same for docker with its network interface of choice. To further make it real kubernetes CNI can modify packets between containers/pods and network interfaces in many places (system calls, socket layer, L4 protocol layer, netfilter, RIB, TC, nic driver or even NIC itself. Anything can be changed in the packet as long as kernel helper API allows. So all discussions that route can do that but the host can not are really moot. Maybe 20 years ago they could take the floor but sorry no these days :( SRv6 IPv6 header can be produced by the end app and inserted into a packet in the processing pipeline by BPF. Reverse direction can and does happen too. And none of the above is about the administrative interface of the hosts. That's all together a completely different thing - but I am not sure is in scope of this bigger thread. Thx, R. On Tue, Oct 19, 2021 at 10:43 AM Ted Hardie wrote: > Hi Mark, > > I updated the subject because I think this is a distinct question, and > I've tried to pull that question into focus by cutting to that text below. > I hope that's okay. > > On Tue, Oct 19, 2021 at 8:11 AM Mark Smith wrote: > >> Hi Brian, >> >> On Tue, 19 Oct 2021 at 15:51, Brian E Carpenter >> >> If a router as a physical device has IPv6 addresses that are sent to >> the device itself, then the router as a physical device is also >> performing host functions. For packets with those "router addresses", >> the router as a physical device is not "forward[ing] IPv6 packets not >> explicitly addressed to itself. " >> >> > In many deployments the packets sent to the router while it is "performing > host functions" are sent to a distinct interface (or distinct interfaces, > when there is one for each address family). That interface or those > interfaces typically have distinct security controls and expose different > ports (so that you can ssh in, for example). > > I think it would be reasonable to add text on using SID addressing to > reach administrative interfaces. I think that would work along the lines > already laid out, with the administrative interfaces being outside the SR > domain, but additional thought and text on it might well be useful. > > > >> In a router as a physical device, the forwarding plane is performing >> the router function above. In a router as a physical device, the >> "control plane" (really just a fancy name for a host) is performing >> host functions on packets that are directly to and from it (BGP, OSPF, >> SSH, SNMP etc. packets). >> >> The consequence is that all IPv6 addresses are host addresses, and all >> processing of packets at the device that holds a packet's DA is host >> processing of the packet. >> > > I must disagree with this conclusion. I think RFC 8504 was written the > way it was to highlight that there is some commonality between hosts and > routers and to set out the node requirements that unite the two. But there > are clear differences between the processing of a packet by a router and by > a host, with forwarding behavior being chief among them. To say that all > processing is host processing is to gloss over both an architectural > distinction and the deployed reality I mentioned before. The reason people > maintain distinct administrative addresses is to ensure that the host > processing and router processing remain distinct. > > I think Brian's note is maintaining a distinction that is both generally > important and important for understanding this case. Speaking personally, > I'd like to retain that understanding. > > best regards, > > Ted Hardie > > > >> >> It is the same in IPv4 - from RFC791, "The internet protocol provides >> for transmitting blocks of data called datagrams from sources to >> destinations, where sources and destinations are hosts identified by >> fixed length addresses." >> >> So these packets with CSID rotating IPv6 DAs are being host processed >> by the router (as a device), after the forwarding plane in the router >> (as a device) has forwarded the packet to the colocated host function. >> >> (A more practical example to support the above observation. If a >> router as a device is bought from a router vendor, and then is run as >> a BGP route reflector, meaning it is never in a packet forwarding >> path, and therefore never "forwards IPv6 packets not explicitly >> addressed to itself" is the router device still a router? Functionally >> no, it is a host, even though it looks like a router (as a device).) >> >> Regards, >> Mark. >> >> > Another way to say it is RFC 7608 is the relevant architectural >> > standard. CIDR rules, even within an SR domain. >> > >> > For that reason, the fact that the bottom 64 bits in the >> > "address" look funny or change is simply irrelevant. They are >> > invisible to routing (which is done based on the prefix) >> > and invisible to neighbor discovery (because it never happens). >> > >> > I apologise if this is all obvious to everybody, but I needed >> > to spell it out for my own understanding. >> > >> > Now back to Joel's questions: >> > >> > >> > On 13-Oct-21 20:37, Joel M. Halpern wrote: >> > > There is a typo in the below which if not understood as a typo would >> be >> > >> > > quite confusing. I wrote that I raised the issue with >> > > "with the Internet ADs and SPRING chairs". >> > > That should have read "with the Internet ADs and 6man chairs". >> > > The SPRING co-chairs are recused, and the charter requirement leads to >> > > the 6man chairs. Which is who I talked to. >> > > >> > > Also, I am sending a courtesy copy to the routing ADs, which I should >> > > have done originally. >> > > >> > > Thank you and enjoy. >> > > Yours, >> > > Joel >> > > >> > > On 10/12/2021 11:52 PM, Joel M. Halpern wrote: >> > >> The SPRING working group is in the midst of an adoption call on >> > >> >> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ >> . >> > >> >> > >> >> > >> The SPRING charter has text that is explicit that modifications to >> data >> > >> planes and architectures standardized by other working groups may >> not be >> > >> modified in SPRING unless the chairs and ADs responsible for that >> data >> > >> > >> plane and / or architecture agree. >> > >> >> > >> To complete the context, as my SPRING co-chairs are co-authors on the >> > >> document in question, they have recused themselves from decisional >> > >> activities regarding the document. Therefore, this message is coming >> > >> just from my as the responsible SPRING co-chair managing this >> adoption >> > >> > >> call. >> > >> >> > >> As you have seen, multiple questions have been raised about the >> > >> relationship of the document to the IPv6 defined data plane and >> > >> architecture (particularly RFC 4291 and 8200). In particular the >> > >> questions seem to revolve around what the document describes as the >> > >> NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6 >> > >> standards. (For those seeking more context without reading the full >> > >> document, a paraphrase and simplification of the NEXT-C_SID flavor is >> > >> provided as a postscript.) >> > >> >> > >> I raised the question of concurrence as required by the SPRING >> charter >> > >> > >> with the Internet ADs and SPRING chairs. They quite reasonably >> asked me >> > >> to write a note to 6man explaining the concerns as clearly as a can, >> so >> > >> that they can then determine how to proceed. >> > >> >> > >> The questions that prompted my inquiry are: >> > >> >> > >> 1) Does the placement of a list of sids in the IPv6 DA field change >> the >> > >> IPv6 architectural description of that field. >> > >> > I think it should be noted explicitly somewhere that since the contents >> > of the DA field are *never* used for last-hop neighbor discovery, >> > the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942 >> > are irrelevant. Another citation is RFC 7608: for routing, all that >> > counts is the prefix, and it can be anything up to 128. >> > >> > Perhaps this should have been in section 5 of RFC 8754, but I leave >> > that to the wordsmiths. >> > >> > >> 2) Does the operation of shifting information around in the IPv6 >> > >> destination address field represent a modification or extension of >> the >> > >> > >> IPv6 data plane. >> > >> > No. As my text above indicates, the SRv6 DA field is only ever used >> > by routing, where RFC 7608 rules. And of course it vanishes as soon >> > as the packet is decapsulated. >> > >> > Regards >> > Brian >> > >> > >> >> > >> On a related note, the document in question also defines two other >> > >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The >> > >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID >> > >> flavor operation, so seems to be affected by the same question. >> > >> >> > >> From my own reading, it appears that the REPLACE-C-SID flavor does >> not >> > >> raise issues requiring 6man leadership concurrence. >> > >> >> > >> Yours, >> > >> Joel M. Halpern for the SPRING working group >> > >> >> > >> >> > >> PS: >> > >> Clearly, understanding the question requires some understanding of >> what >> > >> the NEXT-C_SID flavor does. This explanation is a simplification >> for >> > >> length and context. Really, the best place to understand it is the >> > >> draft. However, to give you enough information to let you decide >> > >> > >> whether you care, I will try to provide a fair summary. My >> apologies in >> > >> advance to the authors for necessary liberties for length. Also, >> > >> > >> discussion of the draft contents (as distinct from the interaction >> with >> > >> the IPv6 data plane and architecture) belongs on the SPRING list, and >> > >> should not clutter up 6man. >> > >> >> > >> SIDs are the identifiers used in segment routing. >> > >> In SRv6, as document in the current RFCs, these are 128 bits. As >> > >> defined in the relevant RFCs, SIDs which identify endpoints to which >> > >> packets are directed are identified by endpoint SIDs. These can have >> > >> behaviors (decapsulate and forward is one example). They can have >> > >> flavors such as where the SRH is removed. >> > >> >> > >> The topic under discussion is means to compress these SIDs in the >> > >> packets on the wire. The document under discussion provides three >> > >> flavors of compression. >> > >> >> > >> The fundamental mechanism of the draft is to use a single SRH entry >> as >> > a >> > >> container for multiple SIDs. In the NEXT-C_SID mechanism, when it is >> > >> first encountered the entire container is copied into the desination >> > >> address of the IPv6 packet. The container has a common routing >> prefix >> > >> used for all the NEXT-C-SID SIDs. It is followed by a sequence of >> > >> compressed SIDs of a configured length. One could configure 16, 24, >> or >> > >> 32 bits. Or whatever length. The routing advertisements are >> arranged >> > >> so that the IPv6 packet is directed to the node represented by the >> first >> > >> compressed SID on the basis of longest prefix match matching the >> > >> combination of the common routing prefix and that compressed SID. >> > >> >> > >> When the packet arrives at that node, it looks up the configured >> > >> portion, the compressed SID, and determines the behavior and >> flavor. In >> > >> the case of the NEXT-C-SID flavor, the resulting operation is to >> shift >> > >> > >> the entire remaining contents of the IPv6 address (the bits past the >> > >> first compressed sid) so as to over-write the first compressed SID. >> 0 >> > >> bits are shifted into the low order positions. If the result is a >> > >> non-zero new first compressed SID, then the packets is forwarded and >> the >> > >> process repeats. When all that is left are 0s, if there is an SRH, >> it >> > >> is consulted to find the next SRH entry, which is, per normal SRv6 >> > >> processing, put into the IPv6 DA. >> > >> Note that in the common case where the SIDS needed all fit in to a >> > >> single container, the analysis also assumes the use of the reduced >> > >> encapsulation options which omits the SRH that is not needed as it >> would >> > >> have no entries. This the packet contains a normal IPv6 header, >> with a >> > >> sequence of compressed SIDs (what one might or might not call a >> source >> > >> > >> route) in the IPv6 destination address field. >> > >> >> > >> PPS: If the authors of the NEXT-C-SID flavor feel I have >> mis-represented >> > >> the work, please, send clarifications or corrections. Again, the >> best >> > >> source of information is the draft itself. I was asked to provide >> extra >> > >> context in this email. >> > > >> > > -------------------------------------------------------------------- >> > > IETF IPv6 working group mailing list >> > > ipv6@ietf.org >> > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> > > -------------------------------------------------------------------- >> > > >> > >> > -------------------------------------------------------------------- >> > IETF IPv6 working group mailing list >> > ipv6@ietf.org >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> > -------------------------------------------------------------------- >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000a5200b05ceb3f8c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    All,

    I must say that I am not quite sur= e what is being discussed here.=C2=A0

    Today the co= mputer node says linux is also called host.=C2=A0

    = That host has in the kernel multiple routing tables.=C2=A0

    The same very host (or node) is a home for the number of kube pods= which in turn are home for the number of containers. Those run apps.=C2=A0=

    Same for docker with its network interface of cho= ice.=C2=A0

    To further make it real kubernetes CNI = can modify packets between containers/pods and network interfaces in many p= laces (system calls, socket layer, L4 protocol layer, netfilter, RIB, TC, n= ic driver or even NIC itself.=C2=A0

    Anything can b= e changed in the packet as long=C2=A0as kernel helper API allows.=C2=A0

    So all discussions that route can do that but the hos= t can not are really moot. Maybe 20 years ago they could take the floor but= sorry no these=C2=A0days :(=C2=A0

    SRv6 IPv6 heade= r can be produced by the end app and inserted into a packet in the processi= ng=C2=A0pipeline=C2=A0by BPF. Reverse direction can and does happen too.=C2= =A0

    And none of the above is about the administrat= ive interface of the hosts. That's all together a completely different = thing - but I am not sure is in scope of this bigger thread.=C2=A0

    Thx,
    R.



    On Tu= e, Oct 19, 2021 at 10:43 AM Ted Hardie <ted.ietf@gmail.com> wrote:
    Hi Mark,

    I updated the subject because I think this is a disti= nct question, and I've tried to pull that question into focus by cuttin= g to that text below.=C2=A0 I hope that's okay.

    On Tue, Oct 19= , 2021 at 8:11 AM Mark Smith <markzzzsmith@gmail.com> wrote:
    Hi Brian,

    On Tue, 19 Oct 2021 at 15:51, Brian E Carpenter

    If a router as a physical device has IPv6 addresses that are sent to
    the device itself, then the router as a physical device is also
    performing host functions. For packets with those "router addresses&qu= ot;,
    the router as a physical device is not "forward[ing] IPv6 packets not<= br> explicitly addressed to itself. "


    In many deployments the packets sent to the router while= it is "performing host functions" are sent to a distinct interfa= ce (or distinct interfaces, when there is one for each address family).=C2= =A0 That interface or those interfaces typically have distinct security con= trols and expose different ports (so that you can ssh in, for example).

    I think it would be rea= sonable to add text on using SID addressing to reach administrative interfa= ces.=C2=A0 I think that would work along the lines already laid out, with t= he administrative interfaces being outside the SR domain, but additional th= ought and text on it might well be useful.=C2=A0

    = =C2=A0
    In a router as a physical device, the forwarding plane is performing
    the router function above. In a router as a physical device, the
    "control plane" (really just a fancy name for a host) is performi= ng
    host functions on packets that are directly to and from it (BGP, OSPF,
    SSH, SNMP etc. packets).

    The consequence is that all IPv6 addresses are host addresses, and all
    processing of packets at the device that holds a packet's DA is host processing of the packet.

    I must disagree with this conclus= ion.=C2=A0 I think RFC 8504 was written the way it was to highlight that th= ere is some commonality between hosts and routers and to set out the node r= equirements that unite the two.=C2=A0 But there are clear differences betwe= en the processing of a packet by a router and by a host, with forwarding be= havior being chief among them.=C2=A0 To say that all processing is host pro= cessing is to gloss over both an architectural distinction and the deployed= reality I mentioned before.=C2=A0 The reason people maintain distinct admi= nistrative addresses is to ensure that the host processing and router proce= ssing remain distinct.=C2=A0

    I think Brian's note is maintaining a distinction that is both= generally important and important for understanding this case.=C2=A0 Speak= ing personally, I'd like to retain that understanding.

    best regards,

    Ted Hardie

    =C2=A0

    It is the same in IPv4=C2=A0 - from RFC791, "The internet protocol pro= vides
    for transmitting blocks of data called datagrams from sources to
    destinations, where sources and destinations are hosts identified by
    fixed length addresses."

    So these packets with CSID rotating IPv6 DAs are being host processed
    by the router (as a device), after the forwarding plane in the router
    (as a device) has forwarded the packet to the colocated host function.

    (A more practical example to support the above observation. If a
    router as a device is bought from a router vendor, and then is run as
    a BGP route reflector, meaning it is never in a packet forwarding
    path, and therefore never "forwards IPv6 packets not explicitly
    addressed to itself" is the router device still a router? Functionally=
    no, it is a host, even though it looks like a router (as a device).)

    Regards,
    Mark.

    > Another way to say it is RFC 7608 is the relevant architectural
    > standard. CIDR rules, even within an SR domain.
    >
    > For that reason, the fact that the bottom 64 bits in the
    > "address" look funny or change is simply irrelevant. They ar= e
    > invisible to routing (which is done based on the prefix)
    > and invisible to neighbor discovery (because it never happens).
    >
    > I apologise if this is all obvious to everybody, but I needed
    > to spell it out for my own understanding.
    >
    > Now back to Joel's questions:
    >
    >
    > On 13-Oct-21 20:37, Joel M. Halpern wrote:
    > > There is a typo in the below which if not understood as a typo wo= uld be
    >
    > > quite confusing.=C2=A0 =C2=A0I wrote that I raised the issue with=
    > > "with the Internet ADs and SPRING chairs".
    > > That should have read "with the Internet ADs and 6man chairs= ".
    > > The SPRING co-chairs are recused, and the charter requirement lea= ds to
    > > the 6man chairs.=C2=A0 Which is who I talked to.
    > >
    > > Also, I am sending a courtesy copy to the routing ADs, which I sh= ould
    > > have done originally.
    > >
    > > Thank you and enjoy.
    > > Yours,
    > > Joel
    > >
    > > On 10/12/2021 11:52 PM, Joel M. Halpern wrote:
    > >> The SPRING working group is in the midst of an adoption call = on
    > >> https= ://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression= /.
    > >>
    > >>
    > >> The SPRING charter has text that is explicit that modificatio= ns to data
    > >> planes and architectures standardized by other working groups= may not be
    > >> modified in SPRING unless the chairs and ADs responsible for = that data
    >
    > >> plane and / or architecture agree.
    > >>
    > >> To complete the context, as my SPRING co-chairs are co-author= s on the
    > >> document in question, they have recused themselves from decis= ional
    > >> activities regarding the document.=C2=A0 Therefore, this mess= age is coming
    > >> just from my as the responsible SPRING co-chair managing this= adoption
    >
    > >> call.
    > >>
    > >> As you have seen, multiple questions have been raised about t= he
    > >> relationship of the document to the IPv6 defined data plane a= nd
    > >> architecture (particularly RFC 4291 and 8200). In particular = the
    > >> questions seem to revolve around what the document describes = as the
    > >> NEXT-C-SID flavor of compressed SID, and its relationship to = the IPv6
    > >> standards.=C2=A0 (For those seeking more context without read= ing the full
    > >> document, a paraphrase and simplification of the NEXT-C_SID f= lavor is
    > >> provided as a postscript.)
    > >>
    > >> I raised the question of concurrence as required by the SPRIN= G charter
    >
    > >> with the Internet ADs and SPRING chairs.=C2=A0 They quite rea= sonably asked me
    > >> to write a note to 6man explaining the concerns as clearly as= a can, so
    > >> that they can then determine how to proceed.
    > >>
    > >> The questions that prompted my inquiry are:
    > >>
    > >> 1) Does the placement of a list of sids in the IPv6 DA field = change the
    > >> IPv6 architectural description of that field.
    >
    > I think it should be noted explicitly somewhere that since the content= s
    > of the DA field are *never* used for last-hop neighbor discovery,
    > the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942
    > are irrelevant. Another citation is RFC 7608: for routing, all that > counts is the prefix, and it can be anything up to 128.
    >
    > Perhaps this should have been in section 5 of RFC 8754, but I leave > that to the wordsmiths.
    >
    > >> 2) Does the operation of shifting information around in the I= Pv6
    > >> destination address field represent a modification or extensi= on of the
    >
    > >> IPv6 data plane.
    >
    > No. As my text above indicates, the SRv6 DA field is only ever used > by routing, where RFC 7608 rules. And of course it vanishes as soon > as the packet is decapsulated.
    >
    > Regards
    >=C2=A0 =C2=A0 =C2=A0Brian
    >
    > >>
    > >> On a related note, the document in question also defines two = other
    > >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.=C2=A0 The=
    > >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-= C_SID
    > >> flavor operation, so seems to be affected by the same questio= n.
    > >>
    > >>=C2=A0 From my own reading, it appears that the REPLACE-C-SID = flavor does not
    > >> raise issues requiring 6man leadership concurrence.
    > >>
    > >> Yours,
    > >> Joel M. Halpern for the SPRING working group
    > >>
    > >>
    > >> PS:
    > >> Clearly, understanding the question requires some understandi= ng of what
    > >> the NEXT-C_SID flavor does.=C2=A0 =C2=A0This explanation is a= simplification for
    > >> length and context.=C2=A0 Really, the best place to understan= d it is the
    > >> draft.=C2=A0 However, to give you enough information to let y= ou decide
    >
    > >> whether you care, I will try to provide a fair summary.=C2=A0= My apologies in
    > >> advance to the authors for necessary liberties for length.=C2= =A0 Also,
    >
    > >> discussion of the draft contents (as distinct from the intera= ction with
    > >> the IPv6 data plane and architecture) belongs on the SPRING l= ist, and
    > >> should not clutter up 6man.
    > >>
    > >> SIDs are the identifiers used in segment routing.
    > >> In SRv6, as document in the current RFCs, these are 128 bits.= =C2=A0 =C2=A0As
    > >> defined in the relevant RFCs, SIDs which identify endpoints t= o which
    > >> packets are directed are identified by endpoint SIDs.=C2=A0 T= hese can have
    > >> behaviors (decapsulate and forward is one example).=C2=A0 The= y can have
    > >> flavors such as where the SRH is removed.
    > >>
    > >> The topic under discussion is means to compress these SIDs in= the
    > >> packets on the wire.=C2=A0 The document under discussion prov= ides three
    > >> flavors of compression.
    > >>
    > >> The fundamental mechanism of the draft is to use a single SRH= entry as
    > a
    > >> container for multiple SIDs.=C2=A0 In the NEXT-C_SID mechanis= m, when it is
    > >> first encountered the entire container is copied into the des= ination
    > >> address of the IPv6 packet.=C2=A0 The container has a common = routing prefix
    > >> used for all the NEXT-C-SID SIDs.=C2=A0 It is followed by a s= equence of
    > >> compressed SIDs of a configured length.=C2=A0 One could confi= gure 16, 24, or
    > >> 32 bits.=C2=A0 Or whatever length.=C2=A0 The routing advertis= ements are arranged
    > >> so that the IPv6 packet is directed to the node represented b= y the first
    > >> compressed SID on the basis of longest prefix match matching = the
    > >> combination of the common routing prefix and that compressed = SID.
    > >>
    > >> When the packet arrives at that node, it looks up the configu= red
    > >> portion, the compressed SID, and determines the behavior and = flavor.=C2=A0 In
    > >> the case of the NEXT-C-SID flavor, the resulting operation is= to shift
    >
    > >> the entire remaining contents of the IPv6 address (the bits p= ast the
    > >> first compressed sid) so as to over-write the first compresse= d SID.=C2=A0 0
    > >> bits are shifted into the low order positions.=C2=A0 If the r= esult is a
    > >> non-zero new first compressed SID, then the packets is forwar= ded and the
    > >> process repeats.=C2=A0 When all that is left are 0s, if there= is an SRH, it
    > >> is consulted to find the next SRH entry, which is, per normal= SRv6
    > >> processing, put into the IPv6 DA.
    > >> Note that in the common case where the SIDS needed all fit in= to a
    > >> single container, the analysis also assumes the use of the re= duced
    > >> encapsulation options which omits the SRH that is not needed = as it would
    > >> have no entries.=C2=A0 This the packet contains a normal IPv6= header, with a
    > >> sequence of compressed SIDs (what one might or might not call= a source
    >
    > >> route) in the IPv6 destination address field.
    > >>
    > >> PPS: If the authors of the NEXT-C-SID flavor feel I have mis-= represented
    > >> the work, please, send clarifications or corrections.=C2=A0 = =C2=A0Again, the best
    > >> source of information is the draft itself.=C2=A0 I was asked = to provide extra
    > >> context in this email.
    > >
    > > -----------------------------------------------------------------= ---
    > > IETF IPv6 working group mailing list
    > > ipv6@ietf.org<= /a>
    > > Administrative Requests:     https://www.ietf.org/ma= ilman/listinfo/ipv6
    > > -----------------------------------------------------------------= ---
    > >
    >
    > -------------------------------------------------------------------- > IETF IPv6 working group mailing list
    > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
    > --------------------------------------------------------------------
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
    --------------------------------------------------------------------
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
    --------------------------------------------------------------------
    Hi Brian,

    T= hanks for the additional clarification.=C2=A0 I've cut below to the mea= t of what I understand to be your question:


    On Sat, Oct 16, 2021 at 10:19 PM Bri= an E Carpenter <brian.e.c= arpenter@gmail.com> wrote:
    =C2=A0
    =C2=A0I want to draw a distinction betwe= en unicast address bits that are arbitrary numbers as far as
    the routing system is concerned -- such as the classical IID bits in IPv6 <= br> unicast addresses, or the prefix bits following fc00::/7 -- and address bit= s that are meaningful to the routing system, such as fe80::/10 (which means= "do not route this packet").

    Within an SRV6 domain, with RFC8986 and the current draft, we see something= new: a field which has classically been an arbitrary 64-bit number for the routing system (the IID field) becomes meaningful to the routing system= . That's an architectural change, and definitely was not envisaged by t= he IPv6 address architecture.

    So, IMHO, the question behind SPRING's question to 6MAN is not whether = there is an architectural change, but whether this changes matters. In part= icular, will it have impact on legacy devices and software within the SRV6 = domain, and will it do any damage if it leaks outside the domain?


    Do I understand correctly that you see the same architectural q= uestion for RFC 8986 ("will it have an impact on legacy devices and so= ftware within the SRV6 domain and will it do any damage if it leaks outside= the domain")?

    Presu= ming so, the question for RFC 8986 seems to me to be answered within the do= cument with a reference to rfc8754, Section 5, which has the deployment mod= el for segment routing spelled out.=C2=A0 Would a similar applicability sta= tement here be something that helps resolve this?=C2=A0 At least as far as = I can tell, a shift in the formatting to a compressed format doesn't ch= ange the basic difference you call out, so I believe that it would be very = similar if not identical.=C2=A0 But it certainly does no harm to spell that= out.

    regards,

    Ted Hardie


    --0000000000003d8a7f05ce9b6af2-- From giuseppe.siracusano@uniroma2.it Fri Oct 15 01:26:28 2021 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 EB6BF3A18B7; Fri, 15 Oct 2021 01:26:27 -0700 (PDT) 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=uniroma2.it header.b=dKpg7c2a; dkim=pass (2048-bit key) header.d=uniroma2.it header.b=NZ7cSOvb 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 5E54ElE5xehQ; Fri, 15 Oct 2021 01:26:21 -0700 (PDT) Received: from smtp.uniroma2.it (smtp.uniroma2.it [160.80.6.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 EA0C93A18B6; Fri, 15 Oct 2021 01:26:18 -0700 (PDT) Received: from smtpauth-2019-1.uniroma2.it (smtpauth-2019-1.uniroma2.it [160.80.5.46]) by smtp-2015.uniroma2.it (8.14.4/8.14.4/Debian-8) with ESMTP id 19F8Q9lX001887; Fri, 15 Oct 2021 10:26:14 +0200 Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) by smtpauth-2019-1.uniroma2.it (Postfix) with ESMTPSA id 2C94D1227F5; Fri, 15 Oct 2021 10:26:05 +0200 (CEST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=uniroma2.it; s=ed201904; t=1634286365; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding:in-reply-to: references; bh=yWZi73gpHL2O0fHwLUwndHd+EwIxH+SidyiT5BZgJMA=; b=dKpg7c2a/HKDhAsWEnALA2RIpyfMLY3gBlyBWSZ2p8eJApXd+deblkq7GCh7y+jGkA14vu xZ60viMRKBFpsIDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniroma2.it; s=rsa201904; t=1634286365; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding:in-reply-to: references; bh=yWZi73gpHL2O0fHwLUwndHd+EwIxH+SidyiT5BZgJMA=; b=NZ7cSOvbgdR9fVc4uEuP6vPmXfEagX5K8y3asfkfLLqg95fQ+p20MtR+ISmX2BdRdkseJ4 3EKdRWuzI/lZJXrxp4MwJylvMDNKnJPt26f4pouLUhgbPQU5X1myWLBE2Fe8riPE+CB25c lezKojX1Ng2q8hJ5voIq1ee/cdUSHOEAAleBzAe0u++xP4W6BFdgKrApbVs6xZtPamPRL+ J5/loDZmoG0HfivdnXLBkwXoPxuVs6wO4NYgD3v3eADtsa9yc06lP+vXlzVew5BWxINvYQ vRNeBtWVQpkMjFQS5BMUw4jU9Ig/e8jTAT4xm92S3CuiZYsYzrbydb7V9hGN8Q== Received: by mail-wr1-f51.google.com with SMTP id u18so25192962wrg.5; Fri, 15 Oct 2021 01:26:05 -0700 (PDT) X-Gm-Message-State: AOAM531eXL3pW9wruG54GTlXyOASL+3i23RyAVDq21sKVdtFF7leJsQ2 5ggPpbEergDoAcjiFasJK36rAtL8x08bshi66sk= X-Google-Smtp-Source: ABdhPJy6X6sjbRfmqgVlE4AqMERMwM+w9HZSVYZI16ueYrDrZtmwxmyLLVfAKi69GImVSaJhUWVmBDZAiKTOtAD5VOo= X-Received: by 2002:adf:f48a:: with SMTP id l10mr12791089wro.228.1634286364579; Fri, 15 Oct 2021 01:26:04 -0700 (PDT) MIME-Version: 1.0 From: Giuseppe Siracusano Date: Fri, 15 Oct 2021 10:25:53 +0200 X-Gmail-Original-Message-ID: Message-ID: To: spring@ietf.org Cc: spring-chairs@ietf.org Content-Type: multipart/alternative; boundary="00000000000038dabf05ce5ff2b5" X-Virus-Scanned: clamav-milter 0.100.0 at smtp-2015 X-Virus-Status: Clean Archived-At: X-Mailman-Approved-At: Mon, 18 Oct 2021 08:05:16 -0700 Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 15 Oct 2021 15:01:54 -0000 --00000000000038dabf05ce5ff2b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear WG, WG Chairs, I support the adoption of draft-filsfilscheng-spring-srv6-srh-compression. I have been working on SRv6 for different research project over the last years. The flavors defined in the CSID draft are complaint with RFC8986 and builds on top of the single SRv6 dataplane. Thanks Giuseppe Siracusano, PhD Dear WG: The chairs would like to express their appreciation for all the responses received to our emails with reference to how the working group wishes to move forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ as the basis for its compression standardization work. That is part of what this email attempts to confirm. Because of the above the chairs would like to issue a 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/ but with some clear guidelines as follows. By expressing support for adoption of this document you are fully aware of and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv6 Endpoint behaviors. 2. The document is a =E2=80=9Cliving=E2=80=9D document; it may change as= it goes through review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be addressed BEFORE said document is allowed to progress from the working group to publication. A list of these discussion points will be document= ed in the WG document and maintained by the document editor in conjunction with the chairs. 4. If this document is adopted by the working group, the chairs specify as part of the adoption call that the following text describing an open issue be added to the document in the above-described open issues sectio= n: - "Given that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this is valid and coherent with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or not this WG adoption. Please express clearly your reasoning for support/non-support as well as any open discussion points you would like addressed should the document be adopted into the working group. Thanks! Jim, Bruno & Joel --00000000000038dabf05ce5ff2b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Dear WG, WG Chairs,

    I support the adoption of draf= t-filsfilscheng-spring-srv6-srh-compression.

    I have been working on = SRv6 for different research project over the last years.
    The flavors de= fined in the CSID draft are complaint with RFC8986 and builds on top of the= single SRv6 dataplane.

    Thanks
    Giuseppe Siracusa= no, PhD


    Dear WG:

    =C2=A0

    The chairs would like to express their appreciation for all the responses=20 received to our emails with reference to how the working group wishes to move forward with respect to a solution for SRv6 compression.

    =C2=A0

    T= he apparent inclination of the working group is to use h= ttps://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compres= sion/ as the basis for its compression standardization work. That is pa= rt of what this email attempts to confirm.

    =C2=A0

    Because of the above t= he chairs would like to issue a 2-week WG call for adoption ending October = 15th for https://datatracker.ietf.org/doc/dra= ft-filsfilscheng-spring-srv6-srh-compression/ but with some clear guidelines as follows. By expressing support for=20 adoption of this document you are fully aware of and are acknowledging=20 that:

    =C2=A0

    1. The SPRING working group is adopting a do= cument that has multiple SRv6 Endpoint behaviors.
    2. The document is a = =E2=80=9Cliving=E2=80=9D document; it may change as it goes through review = and analysis by the SPRING working group.
    3. All open discussion points raised on our mailing list MUST be addressed=20 BEFORE said document is allowed to progress from the working group to=20 publication. A list of these discussion points will be documented in the WG document and maintained by the document editor in conjunction with=20 the chairs.
    4. If this document is adopted by the working group, the chairs specify as=20 part of the adoption call that the following text describing an open=20 issue be added to the document in the above-described open issues=20 section:
      • "Given that the working group has said that it wants to standardize one data=20 plane solution, and given that the document contains multiple SRv6=20 EndPoint behaviors that some WG members have stated are multiple data=20 plane solutions, the working group will address whether this is valid=20 and coherent with its one data plane solution objective.".

    =C2=A0

    Please consider the above guidelines as you decide on whether to support or=20 not this WG adoption. Please express clearly your reasoning for=20 support/non-support as well as any open discussion points you would like addressed should the document be adopted into the working group.

    =C2=A0

    Thanks!

    =C2=A0

    Jim, Bruno & Joel

    --00000000000038dabf05ce5ff2b5-- From nobody Mon Oct 18 13:19:27 2021 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 04F793A0A19; Mon, 18 Oct 2021 13:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 UVjcsymrSZtN; Mon, 18 Oct 2021 13:19:18 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (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 0656F3A0A0E; Mon, 18 Oct 2021 13:19:17 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id n11so12079770plf.4; Mon, 18 Oct 2021 13:19:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=LmOkCkCfbB6qDVJKAh9azGCkxdVhW8SnpKP5/BAkK20=; b=e/DHOQe2AcwE4jAraQRVeCVqlkTvDhiOi2z4fvkjWHcYfQUt5tSaMHzw1aImguvp6D 0es1lmiE+3SF4UadsrfXIA4dbUzCceAOfd7jqlOVVryxd45YFeygb2gLLH7CotvsJR2l Oe7x+p/6jiPfeT5pipXGW3l04bq6Ued9B29QFODnfIjNzyaO+qxTBhP2dMMw3nOsiG9Z DnFvHC2XodlMIKlwf4GQpv+jl21YioL/8btq90rcgKRdoM0gxJD2igQ0SwjQgXe78Dui pfHz4Lf0te5n9ZLasT9nf87IxcJpYUoQjopFMnGxYWHDp4veUOSYWVqVMuK9hNbPFqrU L2dA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=LmOkCkCfbB6qDVJKAh9azGCkxdVhW8SnpKP5/BAkK20=; b=N/dpBWAkfJr5JDptwc9GWyYzsDiupW6Zz7956gFzoaLDhGGIbEfG3gfhhnnKDliszn 5p97+lME5cEJBmtyOzaJUUl8kVy29EBrolV8Zl/VX1KFtGUgE1xezqjI1aEd8aydVK5h YYvWAkk+vFfy0xs6HuXm3DG1aY2oJ1bLFaoNSGPl0tQXA9rsI04fp29FYbEvgpRvy7ZZ b6kzkCwIa4GScrfVvyXMrO85gej5tV9a0uJub5fGCsHN8nU4gB+FvYiM3dkIaOJkUtHt rw7OE4953CaPGd4rKSuGAts4wtdNcpmm6hCcAE7OGA1T5DzL5ljS2DkLaTvEHV14jt/a WKCQ== X-Gm-Message-State: AOAM532rw+8Bxp9SIFDB3xmRrGlaA5InhCCBWONEMpdaZ0DYP/eXUiFI JTwmahL9jcH5Gry4GWXbHulxcVjUNX5XAA== X-Google-Smtp-Source: ABdhPJwVMnemCGSGfBqu/mwFogE5yvzlRcO0q8l/SDf5yhDzWuBjIiulD0thFpSU8kd2FNLaFHa+xQ== X-Received: by 2002:a17:90b:1646:: with SMTP id il6mr1181088pjb.129.1634588356913; Mon, 18 Oct 2021 13:19:16 -0700 (PDT) Received: from ?IPv6:2406:e003:102d:e801:db7:d041:a2d:ce65? ([2406:e003:102d:e801:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id v22sm14286728pff.93.2021.10.18.13.19.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Oct 2021 13:19:16 -0700 (PDT) To: Ted Hardie Cc: "Joel M. Halpern" , "ipv6@ietf.org" , "spring@ietf.org" References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <1daf3d20-22b2-d111-5131-bd53f51c53a3@gmail.com> <60f71d8c-8165-111c-4099-7f926a897d22@gmail.com> <13455849-c0a0-705b-66d8-3b31e7bf95eb@gmail.com> From: Brian E Carpenter Message-ID: Date: Tue, 19 Oct 2021 09:19:15 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 18 Oct 2021 20:19:26 -0000 Ted, On 18-Oct-21 20:22, Ted Hardie wrote: > Hi Brian, >=20 > Thanks for the additional clarification.=C2=A0 I've cut below to the me= at of what I understand to be your question: >=20 >=20 > On Sat, Oct 16, 2021 at 10:19 PM Brian E Carpenter > wrote: > =C2=A0 >=20 > =C2=A0I want to draw a distinction between unicast address bits tha= t are arbitrary numbers as far as > the routing system is concerned -- such as the classical IID bits i= n IPv6 > unicast addresses, or the prefix bits following fc00::/7 -- and add= ress bits that are meaningful to the routing system, such as fe80::/10 (w= hich means "do not route this packet"). >=20 > Within an SRV6 domain, with RFC8986 and the current draft, we see s= omething new: a field which has classically been an arbitrary 64-bit numb= er for > the routing system (the IID field) becomes meaningful to the routin= g system. That's an architectural change, and definitely was not envisage= d by the IPv6 address architecture. >=20 > So, IMHO, the question behind SPRING's question to 6MAN is not whet= her there is an architectural change, but whether this changes matters. I= n particular, will it have impact on legacy devices and software within t= he SRV6 domain, and will it do any damage if it leaks outside the domain?= >=20 >=20 > Do I understand correctly that you see the same architectural question = for RFC 8986 ("will it have an impact on legacy devices and software with= in the SRV6 domain and will it do any damage if it leaks outside the doma= in")? Yes, indeed. It's a bit clearer in my mind now than when we were debating=20 that RFC as a draft, but it certainly applies there too. >=20 > Presuming so, the question for RFC 8986 seems to me to be answered with= in the document with a reference to rfc8754, Section 5, which has the dep= loyment model for segment routing spelled out.=C2=A0 Would a similar appl= icability statement here be something that helps resolve this?=C2=A0 At l= east as far as I can tell, a shift in the formatting to a compressed form= at doesn't change the basic difference you call out, so I believe that it=20 would be very similar if not identical.=C2=A0 But it certainly does no ha= rm to spell that out. In fact the current draft says (section 3): >> The compressed Segment List encoding is fully compliant with the >> specifications in [RFC8402], [RFC8754] and [RFC8986] so from a logical point of view, it doesn't appear essential to add this.=20 However, it might well help future readers to do so. Thanks Brian From nobody Mon Oct 18 18:24:17 2021 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 7AD5D3A0D3E for ; Mon, 18 Oct 2021 18:24:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 Bu_uauaHmW2Q for ; Mon, 18 Oct 2021 18:23:55 -0700 (PDT) Received: from caict.ac.cn (mail.caict.ac.cn [106.38.3.229]) by ietfa.amsl.com (Postfix) with ESMTP id E30463A0D41 for ; Mon, 18 Oct 2021 18:23:50 -0700 (PDT) Received: from LAPTOP-NAK0KB4A (unknown [10.2.52.237]) by app1 (Coremail) with SMTP id H0IICgB3f1cdHm5hOWQNAA--.12513S2; Tue, 19 Oct 2021 09:23:41 +0800 (CST) Date: Tue, 19 Oct 2021 09:23:40 +0800 From: "zhaofeng@caict.ac.cn" To: "'SPRING WG List'" References: <15436_1631020356_61376544_15436_364_1_53C29892C857584299CBF5D05346208A4CE99E43@OPEXCAUBM43.corporate.adroot.infra.ftgroup> X-Priority: 3 X-Has-Attach: no X-Mailer: Foxmail 7.2.10.151[cn] Mime-Version: 1.0 Message-ID: <2021101909234002675410@caict.ac.cn> Content-Type: multipart/alternative; boundary="----=_001_NextPart051033802627_=----" X-CM-TRANSID: H0IICgB3f1cdHm5hOWQNAA--.12513S2 X-Coremail-Antispam: 1UD129KBjvJXoWxGF4kKFyfAr4xCF18uFy5CFg_yoW5tFykpa yUKr17Crs5A348C3WrAr18ZryxArZ5GFWUC3W5Kry8Ja45GF18Kr1ftw4YvayDGr1fJayY qrsruw1DXws0vFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Fb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr1j6rxdM28EF7xvwVC2z280aVAFwI0_GcCE3s1l84ACjcxK6I 8E87Iv6xkF7I0E14v26rxl6s0DM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAYj202 j2C_Gr0_Xr1l5I8CrVAqjxCE14ACF2xKxwAqx4xG64kEw2xG04xIwI0_Jr0_Gr1l5I8CrV CF0I0E4I0vr24l5I8CrVC2j2CEjI02ccxYII8I67AEr4CY67k08wAv7VC0I7IYx2IY67AK xVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UMxkIecxEwV Cm-wCFx2IqxVCFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r106r1rMI8I3I0E7480 Y4vE14v26r106r1rMI8E67AF67kF1VAFwI0_Jr0_JrylIxAIcVC0I7IYx2IY67AKxVWUJV WUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG6r1j 6r1xMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcS sGvfC2KfnxnUUI43ZEXa7IU8OzV5UUUUU== X-CM-SenderInfo: p2kd0wxhqjquhdlf3hldfou0/ Archived-At: Subject: Re: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis 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, 19 Oct 2021 01:24:07 -0000 This is a multi-part message in MIME format. ------=_001_NextPart051033802627_=---- Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU1BSSU5HLA0KIA0KSSBzdXBwb3J0IHRoZSBDU0lEIGFkb3B0aW9uLg0KIA0KQ1NJRCBpcyB0 aGUgcmlnaHQgZGlyZWN0aW9uIGZvciBTUnY2IGNvbXByZXNzaW9uLiBJIHNlZSBtYW55IHZlbmRv cnMgaGF2ZSBpbXBsZW1lbnRlZCBDU0lELCBlc3BlY2lhbGx5IFJFUExBQ0UtQ1NJRCBGbGF2b3Is IGFuZCB0aGUgaW50ZXJvcGVyYWJpbGl0eSB0ZXN0IGhhZCBiZWVuIG1hZGUgbG9uZyB0aW1lIGFn byBpbiBkaWZmZXJlbnQgbGFicywgc28gSSBiZWxpZXZlIHRoZSBtZWNoYW5pc20gaGFzIGJlZW4g bWF0dXJlLiBSZWdhcmRpbmcgdGhlIGlzc3VlcyBkaXNjdXNzZWQgaW4gdGhlIHRocmVhZHMsIHRo ZXkgY2FuIGJlIGFkZHJlc3NlZCBmb2xsb3dpbmcgdGhlIHByb2Nlc3NpbmcuDQogDQpBZ2Fpbiwg dGhhbmtzIHRvIENoYWlycyBhbmQgRGVzaWduIHRlYW0uDQogDQpCZXN0IHJlZ2FyZHMsDQpaaGFv IEZlbmcNCg0KDQoNClpoYW8gRmVuZw0KSW50ZXJuZXQgQ2VudGVyLCBSZXNlYXJjaCBJbnN0aXR1 dGUgb2YgVGVjaG5vbG9neSBhbmQgU3RhbmRhcmQsIENoaW5hIEFjYWRlbXkgb2YgSW5mb3JtYXRp b24gYW5kIENvbW11bmljYXRpb24gVGVjaG5vbG9neQ0KDQpDaGluYSBUVEwgTGFicw0KIA0KQWRk OiBCdWlsZGluZyBCbG9jayBCLTYwOCwgTm8uNTIgSHVhWXVhbiBOb3J0aCBSb2FkIEJlaWppbmcs IFAuUi5DaGluYSwgMTAwMTkxDQpNYWlsOiB6aGFvZmVuZ0BjYWljdC5hYy5jbg0KVGVsOiA4Ni0x MC02MjMwMDA1NQ0KTW9iaWxlOiA4NjEzNjAxMDY4MjEyDQpGYXg6IDg2LTEwLTYyMzAwMDk0DQoN CiANCkZyb206IGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20NCkRhdGU6IDIwMjEtMDktMDcgMjE6 MTINClRvOiBzcHJpbmdAaWV0Zi5vcmcNClN1YmplY3Q6IFtzcHJpbmddIFdHIEFkb3B0aW9uIGNh bGwgLSBkcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQgLSBkcmFm dC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tYW5hbHlzaXMNCkRlYXIgV0csDQogDQogDQpU aGUgRGVzaWduIFRlYW0gaGFzIHByb2R1Y2VkIHR3byBkb2N1bWVudHM6DQotIEEgcmVxdWlyZW1l bnQgZG9jdW1lbnQ6IGRyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVu dCANCi0gQSBzb2x1dGlvbiBhbmFseXNpcyBkb2N1bWVudDogZHJhZnQtc3Jjb21wZHQtc3ByaW5n LWNvbXByZXNzaW9uLWFuYWx5c2lzDQogDQpCb3RoIGhhdmUgYmVlbiBwcmVzZW50ZWQgdG8gdGhl IFdHIGFuZCB0cmlnZ2VyZWQgc29tZSBkaXNjdXNzaW9ucyBidXQgYXJlIHN0aWxsIGluZGl2aWR1 YWwgZG9jdW1lbnRzLg0KV2UgYmVsaWV2ZSBpdCdzIG5vdyB0aW1lIGZvciB0aGUgV0cgdG8gY29u c2lkZXIgdGFraW5nIG93bmVyc2hpcCBvZiB0aG9zZSB0d28gZG9jdW1lbnRzLg0KTm90ZSB0aGF0 LCBlc3BlY2lhbGx5IGZvciB0aG9zZSB0d28gZG9jdW1lbnRzLCBXRyBhZG9wdGlvbiBkb2VzIG5v dCBuZWNlc3NhcmlseSBtZWFuIFJGQyBwdWJsaWNhdGlvbiBpbiBwYXJ0aWN1bGFyIGlmIGl0IHR1 cm5zIG91dCB0aGF0IHRoZSBiZW5lZml0IG9mIGxvbmcgdGVybSBhcmNoaXZlIHdvdWxkIG5vdCBq dXN0aWZ5IHRoZSBXRyBhbmQgSUVTRyBlZmZvcnQgdG8gZmluYWxpemUgdGhvc2UgdHdvIGRvY3Vt ZW50cy4NCiANCiANClRoaXMgbWVzc2FnZSBzdGFydHMgYSAyIHdlZWsgV0cgYWRvcHRpb24gY2Fs bCwgZW5kaW5nIFNlcHRlbWJlciAgMjB0aCAyMDIxLCBmb3I6DQpodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1 aXJlbWVudA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1zcmNv bXBkdC1zcHJpbmctY29tcHJlc3Npb24tYW5hbHlzaXMNCiANCiANCkFmdGVyIHJldmlldyBvZiB0 aGUgZG9jdW1lbnQocykgcGxlYXNlIGluZGljYXRlIHN1cHBvcnQgKG9yIG5vdCkgZm9yIFdHIGFk b3B0aW9uIG9mIHRoZSBkb2N1bWVudChzKSB0byB0aGUgbWFpbGluZyBsaXN0Lg0KUGxlYXNlIGFs c28gcHJvdmlkZSBjb21tZW50cy9yZWFzb25zIGZvciB5b3VyIHN1cHBvcnQgKG9yIGxhY2sgdGhl cmVvZikgYXMgdGhpcyBpcyBhIHN0cm9uZ2VyIHdheSB0byBpbmRpY2F0ZSB5b3VyIChub24pIHN1 cHBvcnQgYXMgdGhpcyBpcyBub3QgYSB2b3RlLg0KIA0KSWYgeW91IGFyZSB3aWxsaW5nIHRvIHdv cmsgb24gdGhlIGRvY3VtZW50KHMpLCBwbGVhc2Ugc3RhdGUgdGhpcyBleHBsaWNpdGx5LiBUaGlz IGdpdmVzIHRoZSBjaGFpcnMgYW4gaW5kaWNhdGlvbiBvZiB0aGUgZW5lcmd5IGxldmVsIG9mIHBl b3BsZSBpbiB0aGUgd29ya2luZyBncm91cCB3aWxsaW5nIHRvIHdvcmsgb24gdGhlIGRvY3VtZW50 LiANCiANClRoYW5rcyENCiANCkppbSwgQnJ1bm8gJiBKb2VsDQogDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMg ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl cgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2lu dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl cmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl IGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuClRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2Vk IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5v dCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3Uu Cg0K ------=_001_NextPart051033802627_=---- Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =0A

    Hi SPRING,

    =  

    I support the CSID adoption.

     

    CSID= is the right direction for SRv6 compression. I see many vendors have impl= emented CSID, especially REPLACE-CSID Flavor, and the interoperability tes= t had been made long time ago in different labs, so I believe the mechanis= m has been mature. Regarding the issues discussed in the threads, they can= be addressed following the processing.

     = ;

    <= span style=3D"font-size: 10.5pt; background-color: transparent;">Again, th= anks to Chairs and Design team.

     

    Best regards,

    Zhao Feng

    =0A

    =0A=
    Zhao Feng

    Internet Center, Research Institute of Technology and Standard, China= Academy of Information and Communication Technology

    =

    <= br>

    China TTL Labs

    Add: Buildi= ng Block B-608, No.52 HuaYuan North Road Beijing, P.R.China, 100191

    Mail:=  zhaofeng@ca= ict.ac.cn

    Tel:=  86-10-6= 2300055

    Mo= bile:&= nbsp;8613601068212

    Fax: 86-10-62300094


    =0A
     
    Date: 2021-09-07 21:12<= div>Subject: [spring] WG Adoption call - draft-srcompdt-spring= -compression-requirement - draft-srcompdt-spring-compression-analysis
    =0A=0A
    =0A

    Dear=0A WG,

    =0A

     =0A

     

    =0A

    <= span lang=3D"EN-GB" style=3D"font-size:10.0pt;mso-bidi-font-size:11.0pt;fo= nt-family:"Arial",sans-serif;mso-bidi-font-family:"Times Ne= w Roman";mso-ansi-language:EN-GB">The Design Team has produced two do= cuments:

    =0A

    - A requirement document: draft-srcompdt-spring-compression-requirement=0A

    =0A

    - A solution analysis document: draft-srcompdt-spring-compression-analysis

    =0A<= p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; = font-family: Calibri, sans-serif;"> 

    =0A

    Both have been presented to the WG and t= riggered some discussions but are=0A still individual documents.

    =0A

    We believe it's now time for the WG to consider taking ow= nership of those=0A two documents.

    =0A

    Note that, es= pecially for those two documents, WG adoption does not necessarily=0A mean= RFC publication in particular if it turns out that the benefit of long te= rm archive would not justify the WG and IESG effort to finalize those two = documents.

    =0A

     

    =0A

     

    =0A

    This message starts a 2 week WG adoption cal= l, ending September =0A20th 2= 021, for:

    =0A

    https://datatracker.ietf.org= /doc/html/draft-srcompdt-spring-compression-requirement

    =0A

    https://datatracker.ietf.org/doc/html/draft-srcompdt-= spring-compression-analysis

    =0A

     

    =0A

     

    =0A

    After review of the docu= ment(s) please indicate support (or not) for WG=0A adoption of the documen= t(s) to the mailing list.

    =0A

    Please also provide co= mments/reasons for your support (or lack thereof)=0A as this is a stronger= way to indicate your (non) support as this is not a vote.

    =0A

     

    =0A

    If you are willing to work on = the document(s), please state this explicitly.=0A This gives the chairs an= indication of the energy level of people in the working group willing to = work on the document.=0A

    =0A

     

    =0A

    Thanks!

    = =0A

     

    =0A

    Jim, Bruno & Joel<= /p>=0A

     

    =0A=
    =0A
    ____________________________________________________________=
_____________________________________________________________=0ACe message=
 et ses pieces jointes peuvent contenir des informations confidentielles o=
u privilegiees et ne doivent donc=0Apas etre diffuses, exploites ou copies=
 sans autorisation. Si vous avez recu ce message par erreur, veuillez le s=
ignaler=0Aa l'expediteur et le detruire ainsi que les pieces jointes. Les =
messages electroniques etant susceptibles d'alteration,=0AOrange decline t=
oute responsabilite si ce message a ete altere, deforme ou falsifie. Merci=
.=0AThis message and its attachments may contain confidential or privilege=
d information that may be protected by law;=0Athey should not be distribut=
ed, used or copied without authorisation.=0AIf you have received this emai=
l in error, please notify the sender and delete this message and its attac=
hments.=0AAs emails may be altered, Orange is not liable for messages that=
 have been modified, changed or falsified.=0AThank you.=0A
    =0A
    <= /div>
    =0A ------=_001_NextPart051033802627_=------ From nobody Mon Oct 18 21:50:32 2021 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 C94B43A07F5; Mon, 18 Oct 2021 21:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 kjHVJHvlb1m7; Mon, 18 Oct 2021 21:50:14 -0700 (PDT) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (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 4C8493A07EC; Mon, 18 Oct 2021 21:50:14 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id ez7-20020a17090ae14700b001a132a1679bso1091885pjb.0; Mon, 18 Oct 2021 21:50:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=AS/nodXGNZKi2gOOWvyes9lBSibCok1perC7iOO+G1U=; b=XLbVVuM86LWvS/WRZpU0768abTyKwrzMIdJVKFARwiIQMXgxirGj6Z12Q3cI/vfcTv a+84siqRTXL6l+EhJGk9Fx6bujW5lRFlut4G7xaZxj5ySnWgmvPlnwa0yF3TDh11E65A 1wcAWZIBNPZb3l+lug3rMgyjjB1ZTw5na+uijmR5p4FDGvQdQOp6N/QL1ErBFGEOTrtG RgfJng6t1jC5RTMIV62E9vZaMyt0T8lby709tJeqNBzP7xRLRv7TNdqpv2QlbW6bdU1P fAdv3p80SKCazYRBascAczO3KyOUeyqGnttKTfw7PdyK5ivx9e6MAgbRet1YihcdJM/l l5oA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=AS/nodXGNZKi2gOOWvyes9lBSibCok1perC7iOO+G1U=; b=Ah21IwjPSKb7a2p0eU1w9twBCcmE5Cda4kfv1zYnXouEM4WllcRxw6ASp6VRbh6dP7 ocyfSFGPx+u7+NuelnFBRiVgox0IufCvd+UxtkSAevhC4V6pSYq+74WCU878VHtblD1E slNlrcK2SKDupbHzs4ipzT9sjFPqymb7tIOWhRDveI7IWlKI4UfNn/nOz7KF4UUaaN1E OwPdoasEBlz5XF/TjdnF5tdhV3DeqAjdvRTtSt+7RNCiNluXKp2bmEK/SJAefnAeb84O T81A+VnfiRcHxMFk8TL24wZQgN+ExXm60Eoe2QeB4/ikES10TRolm61YeH1eWgQ2vktC 1Tvg== X-Gm-Message-State: AOAM531To3cbfWGjHye42pKcpwE/siKAYhupVkWd+d93zvzrsh35hw2n Te91rSviNOrIZCb0+Wkr3mNY/u/m1/EgNQ== X-Google-Smtp-Source: ABdhPJz3rK2XxiP0IIm2zFL3zT/2prmCXlFrsWUoLhcEaR/9ZJmfuyuKM2h8k7C162ep1m0GRVyTVA== X-Received: by 2002:a17:90b:4a92:: with SMTP id lp18mr3939469pjb.47.1634619013311; Mon, 18 Oct 2021 21:50:13 -0700 (PDT) Received: from ?IPv6:2406:e003:102d:e801:db7:d041:a2d:ce65? ([2406:e003:102d:e801:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id j6sm6539209pgf.60.2021.10.18.21.50.10 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Oct 2021 21:50:12 -0700 (PDT) To: "Joel M. Halpern" , "ipv6@ietf.org" Cc: "spring@ietf.org" References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> From: Brian E Carpenter Message-ID: <26d9fc32-4884-602c-975a-79fc64551727@gmail.com> Date: Tue, 19 Oct 2021 17:50:10 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 19 Oct 2021 04:50:20 -0000 Hi, After reading a lot of messages, I'm going to offer my considered opinion as a direct response to Joel's OP. Firstly, I don't believe that in the end this draft raises any concerns that are *significantly* different than those raised when RFC 8986 was in draft. As Ted Hardie mentioned, section 5 of RFC 8754 explains that SIDs of any shape or size are only meaningful within an SR domain. That applies to srh-compression too. Secondly, I was concerned about how these strange looking "addresses" would potentially interfere with normal IPv6 addresses and their handling by normal IPv6 nodes. Well, I now believe that they won't. The reason is that in the SR model these "addresses" are *never used for final delivery of IPv6 packets to a host.* All SRv6 participants are routers. The last hop for a packet whose DA is set to (say) 2001:db8:a:1900:: is *not* the last hop on a LAN, mediated by neighbor discovery for 2001:db8:a:1900::. It's just a hop from one router to another, using the entry for 2001:db8:a:1900::/64 in the FIB of the last router that actually forwards the packet. 2001:db8:a:1900:: is not assigned to a physical interface so RFC 4861 is never invoked. Another way to say it is RFC 7608 is the relevant architectural standard. CIDR rules, even within an SR domain. For that reason, the fact that the bottom 64 bits in the "address" look funny or change is simply irrelevant. They are invisible to routing (which is done based on the prefix) and invisible to neighbor discovery (because it never happens). I apologise if this is all obvious to everybody, but I needed to spell it out for my own understanding. Now back to Joel's questions: On 13-Oct-21 20:37, Joel M. Halpern wrote: > There is a typo in the below which if not understood as a typo would be=20 > quite confusing. I wrote that I raised the issue with > "with the Internet ADs and SPRING chairs". > That should have read "with the Internet ADs and 6man chairs". > The SPRING co-chairs are recused, and the charter requirement leads to = > the 6man chairs. Which is who I talked to. >=20 > Also, I am sending a courtesy copy to the routing ADs, which I should=20 > have done originally. >=20 > Thank you and enjoy. > Yours, > Joel >=20 > On 10/12/2021 11:52 PM, Joel M. Halpern wrote: >> The SPRING working group is in the midst of an adoption call on=20 >> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-c= ompression/.=20 >> >> >> The SPRING charter has text that is explicit that modifications to dat= a=20 >> planes and architectures standardized by other working groups may not = be=20 >> modified in SPRING unless the chairs and ADs responsible for that data=20 >> plane and / or architecture agree. >> >> To complete the context, as my SPRING co-chairs are co-authors on the = >> document in question, they have recused themselves from decisional=20 >> activities regarding the document.=C2=A0 Therefore, this message is co= ming=20 >> just from my as the responsible SPRING co-chair managing this adoption=20 >> call. >> >> As you have seen, multiple questions have been raised about the=20 >> relationship of the document to the IPv6 defined data plane and=20 >> architecture (particularly RFC 4291 and 8200). In particular the=20 >> questions seem to revolve around what the document describes as the=20 >> NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6 = >> standards.=C2=A0 (For those seeking more context without reading the f= ull=20 >> document, a paraphrase and simplification of the NEXT-C_SID flavor is = >> provided as a postscript.) >> >> I raised the question of concurrence as required by the SPRING charter=20 >> with the Internet ADs and SPRING chairs.=C2=A0 They quite reasonably a= sked me=20 >> to write a note to 6man explaining the concerns as clearly as a can, s= o=20 >> that they can then determine how to proceed. >> >> The questions that prompted my inquiry are: >> >> 1) Does the placement of a list of sids in the IPv6 DA field change th= e=20 >> IPv6 architectural description of that field. I think it should be noted explicitly somewhere that since the contents of the DA field are *never* used for last-hop neighbor discovery, the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942 are irrelevant. Another citation is RFC 7608: for routing, all that counts is the prefix, and it can be anything up to 128. Perhaps this should have been in section 5 of RFC 8754, but I leave that to the wordsmiths. >> 2) Does the operation of shifting information around in the IPv6=20 >> destination address field represent a modification or extension of the=20 >> IPv6 data plane. No. As my text above indicates, the SRv6 DA field is only ever used by routing, where RFC 7608 rules. And of course it vanishes as soon as the packet is decapsulated.=20 Regards Brian >> >> On a related note, the document in question also defines two other=20 >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.=C2=A0 The=20 >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID=20 >> flavor operation, so seems to be affected by the same question. >> >> From my own reading, it appears that the REPLACE-C-SID flavor does no= t=20 >> raise issues requiring 6man leadership concurrence. >> >> Yours, >> Joel M. Halpern for the SPRING working group >> >> >> PS: >> Clearly, understanding the question requires some understanding of wha= t=20 >> the NEXT-C_SID flavor does.=C2=A0=C2=A0 This explanation is a simplifi= cation for=20 >> length and context.=C2=A0 Really, the best place to understand it is t= he=20 >> draft.=C2=A0 However, to give you enough information to let you decide=20 >> whether you care, I will try to provide a fair summary.=C2=A0 My apolo= gies in=20 >> advance to the authors for necessary liberties for length.=C2=A0 Also,=20 >> discussion of the draft contents (as distinct from the interaction wit= h=20 >> the IPv6 data plane and architecture) belongs on the SPRING list, and = >> should not clutter up 6man. >> >> SIDs are the identifiers used in segment routing. >> In SRv6, as document in the current RFCs, these are 128 bits.=C2=A0=C2= =A0 As=20 >> defined in the relevant RFCs, SIDs which identify endpoints to which=20 >> packets are directed are identified by endpoint SIDs.=C2=A0 These can = have=20 >> behaviors (decapsulate and forward is one example).=C2=A0 They can hav= e=20 >> flavors such as where the SRH is removed. >> >> The topic under discussion is means to compress these SIDs in the=20 >> packets on the wire.=C2=A0 The document under discussion provides thre= e=20 >> flavors of compression. >> >> The fundamental mechanism of the draft is to use a single SRH entry as=20 a=20 >> container for multiple SIDs.=C2=A0 In the NEXT-C_SID mechanism, when i= t is=20 >> first encountered the entire container is copied into the desination=20 >> address of the IPv6 packet.=C2=A0 The container has a common routing p= refix=20 >> used for all the NEXT-C-SID SIDs.=C2=A0 It is followed by a sequence o= f=20 >> compressed SIDs of a configured length.=C2=A0 One could configure 16, = 24, or=20 >> 32 bits.=C2=A0 Or whatever length.=C2=A0 The routing advertisements ar= e arranged=20 >> so that the IPv6 packet is directed to the node represented by the fir= st=20 >> compressed SID on the basis of longest prefix match matching the=20 >> combination of the common routing prefix and that compressed SID. >> >> When the packet arrives at that node, it looks up the configured=20 >> portion, the compressed SID, and determines the behavior and flavor.=C2= =A0 In=20 >> the case of the NEXT-C-SID flavor, the resulting operation is to shift=20 >> the entire remaining contents of the IPv6 address (the bits past the=20 >> first compressed sid) so as to over-write the first compressed SID.=C2= =A0 0=20 >> bits are shifted into the low order positions.=C2=A0 If the result is = a=20 >> non-zero new first compressed SID, then the packets is forwarded and t= he=20 >> process repeats.=C2=A0 When all that is left are 0s, if there is an SR= H, it=20 >> is consulted to find the next SRH entry, which is, per normal SRv6=20 >> processing, put into the IPv6 DA. >> Note that in the common case where the SIDS needed all fit in to a=20 >> single container, the analysis also assumes the use of the reduced=20 >> encapsulation options which omits the SRH that is not needed as it wou= ld=20 >> have no entries.=C2=A0 This the packet contains a normal IPv6 header, = with a=20 >> sequence of compressed SIDs (what one might or might not call a source=20 >> route) in the IPv6 destination address field. >> >> PPS: If the authors of the NEXT-C-SID flavor feel I have mis-represent= ed=20 >> the work, please, send clarifications or corrections.=C2=A0=C2=A0 Agai= n, the best=20 >> source of information is the draft itself.=C2=A0 I was asked to provid= e extra=20 >> context in this email. >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 From nobody Tue Oct 19 00:10:12 2021 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 169763A079E; Tue, 19 Oct 2021 00:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.598 X-Spam-Level: X-Spam-Status: No, score=-0.598 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 zb8nzdwjTrqE; Tue, 19 Oct 2021 00:10:08 -0700 (PDT) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (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 ACF603A079D; Tue, 19 Oct 2021 00:10:08 -0700 (PDT) Received: by mail-il1-x12d.google.com with SMTP id h27so11693896ila.5; Tue, 19 Oct 2021 00:10: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=YXlJ6bFDxi/CgcN+kx7qFdDuRNQCPxqxkbWL5helSAM=; b=NKscTzVOv8msrhVz6brCST/KBgBPLeJGfrrpwkjWQxaPA8++pr8IVmwbKzCg2KXKix BywKz86jd2YoNzZw+WRbRws1wJkIg4zF6SHmLcD9RFh8NxEL4tqcs/Xf3BBYSmHF8g/j kEln5tfTEZcaf6PzrUQSEOTBbIdBD2ehKthhKtUgofT7RsOONqHj5b8Ss0PSqc8rKLKh DyuackrVK+BTgt/wNjT8PjEm5MZxERoOijLwZJT6GZ3RN7omODEtXgngn7pkeD0K02fo 5G6nPw3F1YdcL4YYN0cVbGnyyvClL2rrYNNchNIQKShfriwi0ezPlQ3SCXeIxfOb00p9 tjyQ== 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=YXlJ6bFDxi/CgcN+kx7qFdDuRNQCPxqxkbWL5helSAM=; b=rADRNEzNuAC1VwK6033oYRDifE1yS8pBz1WcPlyNnwI1nUktRC1wjdNCxpNof/hRh7 xvXqLwiLgCQuU7WrCQ3JtNLLEBR78PJbIhPLGtZZjuvjPYmYOIvzkvod/HBYKxpum4jD RGrRBG+auwmVpnYIgD+GtOtQAOsEwSq31rNxgC4IQ9sZm27jXmixU3stkfcXPtfjOtfV etthKoCMrOQTVN7Gecg6IjfkaIa79uAXAw+X3nr0BL8yMnYXG67t5PU+R3zLFULx+2dE FxlCpPXt6HSc2rbUQPuhSHB2FIi/2u4rKhHu6UxoR2/WwyJ7QxM7LmGOUeOnHIy8XiOZ b1Hw== X-Gm-Message-State: AOAM531Bafj4AkdmQ6w872avq6azaM0LfAVoZRdyzepQATzrOSPlZQVG Ap9ra3w9mSfO6Ypk6iGsAOIUb0oXHPsqVFEQ9n43GDSQu7U= X-Google-Smtp-Source: ABdhPJyiq02aEXSB3KJ1Yo4cvgeUuGpbHxUuFgjYTKzGK+iqyTj42ySbgO34EqWhFTI6AqkcfFCrtndWhxBU5TZljt0= X-Received: by 2002:a05:6e02:1025:: with SMTP id o5mr18129974ilj.133.1634627405522; Tue, 19 Oct 2021 00:10:05 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <26d9fc32-4884-602c-975a-79fc64551727@gmail.com> In-Reply-To: <26d9fc32-4884-602c-975a-79fc64551727@gmail.com> From: Mark Smith Date: Tue, 19 Oct 2021 18:09:38 +1100 Message-ID: To: Brian E Carpenter Cc: "Joel M. Halpern" , "ipv6@ietf.org" , "spring@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 19 Oct 2021 07:10:11 -0000 Hi Brian, On Tue, 19 Oct 2021 at 15:51, Brian E Carpenter wrote: > > Hi, > > After reading a lot of messages, I'm going to offer my considered > opinion as a direct response to Joel's OP. > > Firstly, I don't believe that in the end this draft raises any > concerns that are *significantly* different than those raised > when RFC 8986 was in draft. As Ted Hardie mentioned, section 5 > of RFC 8754 explains that SIDs of any shape or size are only > meaningful within an SR domain. That applies to srh-compression > too. > > Secondly, I was concerned about how these strange looking > "addresses" would potentially interfere with normal IPv6 > addresses and their handling by normal IPv6 nodes. Well, I > now believe that they won't. The reason is that in the SR model > these "addresses" are *never used for final delivery of IPv6 > packets to a host.* All SRv6 participants are routers. The > last hop for a packet whose DA is set to (say) 2001:db8:a:1900:: > is *not* the last hop on a LAN, mediated by neighbor discovery > for 2001:db8:a:1900::. It's just a hop from one router to another, > using the entry for 2001:db8:a:1900::/64 in the FIB of the last > router that actually forwards the packet. 2001:db8:a:1900:: is > not assigned to a physical interface so RFC 4861 is never invoked. > So I'm guessing you're probably thinking of a router as a physical device (as most of us will by default), rather than as routing as a function. RFC8200 definitions: "router a node that forwards IPv6 packets not explicitly addressed to itself. (See Note below.) host any node that is not a router. (See Note below.)" (the note is about hosts having multiple interfaces) (A node doesn't have to be a device, and a device doesn't have to be physical, so the above are really function descriptions.) If a router as a physical device has IPv6 addresses that are sent to the device itself, then the router as a physical device is also performing host functions. For packets with those "router addresses", the router as a physical device is not "forward[ing] IPv6 packets not explicitly addressed to itself. " In a router as a physical device, the forwarding plane is performing the router function above. In a router as a physical device, the "control plane" (really just a fancy name for a host) is performing host functions on packets that are directly to and from it (BGP, OSPF, SSH, SNMP etc. packets). The consequence is that all IPv6 addresses are host addresses, and all processing of packets at the device that holds a packet's DA is host processing of the packet. It is the same in IPv4 - from RFC791, "The internet protocol provides for transmitting blocks of data called datagrams from sources to destinations, where sources and destinations are hosts identified by fixed length addresses." So these packets with CSID rotating IPv6 DAs are being host processed by the router (as a device), after the forwarding plane in the router (as a device) has forwarded the packet to the colocated host function. (A more practical example to support the above observation. If a router as a device is bought from a router vendor, and then is run as a BGP route reflector, meaning it is never in a packet forwarding path, and therefore never "forwards IPv6 packets not explicitly addressed to itself" is the router device still a router? Functionally no, it is a host, even though it looks like a router (as a device).) Regards, Mark. > Another way to say it is RFC 7608 is the relevant architectural > standard. CIDR rules, even within an SR domain. > > For that reason, the fact that the bottom 64 bits in the > "address" look funny or change is simply irrelevant. They are > invisible to routing (which is done based on the prefix) > and invisible to neighbor discovery (because it never happens). > > I apologise if this is all obvious to everybody, but I needed > to spell it out for my own understanding. > > Now back to Joel's questions: > > > On 13-Oct-21 20:37, Joel M. Halpern wrote: > > There is a typo in the below which if not understood as a typo would be > > > quite confusing. I wrote that I raised the issue with > > "with the Internet ADs and SPRING chairs". > > That should have read "with the Internet ADs and 6man chairs". > > The SPRING co-chairs are recused, and the charter requirement leads to > > the 6man chairs. Which is who I talked to. > > > > Also, I am sending a courtesy copy to the routing ADs, which I should > > have done originally. > > > > Thank you and enjoy. > > Yours, > > Joel > > > > On 10/12/2021 11:52 PM, Joel M. Halpern wrote: > >> The SPRING working group is in the midst of an adoption call on > >> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/. > >> > >> > >> The SPRING charter has text that is explicit that modifications to data > >> planes and architectures standardized by other working groups may not be > >> modified in SPRING unless the chairs and ADs responsible for that data > > >> plane and / or architecture agree. > >> > >> To complete the context, as my SPRING co-chairs are co-authors on the > >> document in question, they have recused themselves from decisional > >> activities regarding the document. Therefore, this message is coming > >> just from my as the responsible SPRING co-chair managing this adoption > > >> call. > >> > >> As you have seen, multiple questions have been raised about the > >> relationship of the document to the IPv6 defined data plane and > >> architecture (particularly RFC 4291 and 8200). In particular the > >> questions seem to revolve around what the document describes as the > >> NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6 > >> standards. (For those seeking more context without reading the full > >> document, a paraphrase and simplification of the NEXT-C_SID flavor is > >> provided as a postscript.) > >> > >> I raised the question of concurrence as required by the SPRING charter > > >> with the Internet ADs and SPRING chairs. They quite reasonably asked me > >> to write a note to 6man explaining the concerns as clearly as a can, so > >> that they can then determine how to proceed. > >> > >> The questions that prompted my inquiry are: > >> > >> 1) Does the placement of a list of sids in the IPv6 DA field change the > >> IPv6 architectural description of that field. > > I think it should be noted explicitly somewhere that since the contents > of the DA field are *never* used for last-hop neighbor discovery, > the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942 > are irrelevant. Another citation is RFC 7608: for routing, all that > counts is the prefix, and it can be anything up to 128. > > Perhaps this should have been in section 5 of RFC 8754, but I leave > that to the wordsmiths. > > >> 2) Does the operation of shifting information around in the IPv6 > >> destination address field represent a modification or extension of the > > >> IPv6 data plane. > > No. As my text above indicates, the SRv6 DA field is only ever used > by routing, where RFC 7608 rules. And of course it vanishes as soon > as the packet is decapsulated. > > Regards > Brian > > >> > >> On a related note, the document in question also defines two other > >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The > >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID > >> flavor operation, so seems to be affected by the same question. > >> > >> From my own reading, it appears that the REPLACE-C-SID flavor does not > >> raise issues requiring 6man leadership concurrence. > >> > >> Yours, > >> Joel M. Halpern for the SPRING working group > >> > >> > >> PS: > >> Clearly, understanding the question requires some understanding of what > >> the NEXT-C_SID flavor does. This explanation is a simplification for > >> length and context. Really, the best place to understand it is the > >> draft. However, to give you enough information to let you decide > > >> whether you care, I will try to provide a fair summary. My apologies in > >> advance to the authors for necessary liberties for length. Also, > > >> discussion of the draft contents (as distinct from the interaction with > >> the IPv6 data plane and architecture) belongs on the SPRING list, and > >> should not clutter up 6man. > >> > >> SIDs are the identifiers used in segment routing. > >> In SRv6, as document in the current RFCs, these are 128 bits. As > >> defined in the relevant RFCs, SIDs which identify endpoints to which > >> packets are directed are identified by endpoint SIDs. These can have > >> behaviors (decapsulate and forward is one example). They can have > >> flavors such as where the SRH is removed. > >> > >> The topic under discussion is means to compress these SIDs in the > >> packets on the wire. The document under discussion provides three > >> flavors of compression. > >> > >> The fundamental mechanism of the draft is to use a single SRH entry as > a > >> container for multiple SIDs. In the NEXT-C_SID mechanism, when it is > >> first encountered the entire container is copied into the desination > >> address of the IPv6 packet. The container has a common routing prefix > >> used for all the NEXT-C-SID SIDs. It is followed by a sequence of > >> compressed SIDs of a configured length. One could configure 16, 24, or > >> 32 bits. Or whatever length. The routing advertisements are arranged > >> so that the IPv6 packet is directed to the node represented by the first > >> compressed SID on the basis of longest prefix match matching the > >> combination of the common routing prefix and that compressed SID. > >> > >> When the packet arrives at that node, it looks up the configured > >> portion, the compressed SID, and determines the behavior and flavor. In > >> the case of the NEXT-C-SID flavor, the resulting operation is to shift > > >> the entire remaining contents of the IPv6 address (the bits past the > >> first compressed sid) so as to over-write the first compressed SID. 0 > >> bits are shifted into the low order positions. If the result is a > >> non-zero new first compressed SID, then the packets is forwarded and the > >> process repeats. When all that is left are 0s, if there is an SRH, it > >> is consulted to find the next SRH entry, which is, per normal SRv6 > >> processing, put into the IPv6 DA. > >> Note that in the common case where the SIDS needed all fit in to a > >> single container, the analysis also assumes the use of the reduced > >> encapsulation options which omits the SRH that is not needed as it would > >> have no entries. This the packet contains a normal IPv6 header, with a > >> sequence of compressed SIDs (what one might or might not call a source > > >> route) in the IPv6 destination address field. > >> > >> PPS: If the authors of the NEXT-C-SID flavor feel I have mis-represented > >> the work, please, send clarifications or corrections. Again, the best > >> source of information is the draft itself. I was asked to provide extra > >> context in this email. > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue Oct 19 01:43:20 2021 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 DC0353A0827; Tue, 19 Oct 2021 01:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 w3XCL092gqNa; Tue, 19 Oct 2021 01:42:49 -0700 (PDT) Received: from mail-ot1-x333.google.com (mail-ot1-x333.google.com [IPv6:2607:f8b0:4864:20::333]) (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 D14E03A08BE; Tue, 19 Oct 2021 01:42:48 -0700 (PDT) Received: by mail-ot1-x333.google.com with SMTP id x27-20020a9d459b000000b0055303520cc4so3138580ote.13; Tue, 19 Oct 2021 01:42:48 -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=Z1lJgiKuL1T7yi6IISouQCBYRQGgT4fCoXXHrKwqKzM=; b=BoTo18OK4Ktz6i3+UtWk2eYgkyAD8CRLW5K/NUadxx4c2b2o5eOznD/erSd3akIzdy zdFXc51RBIw7qgh4z1OkIpARannc0348G+I6XgD99rcHgqv8G1pyHgVlT+tO31YfzqSi SWPoRIY8s+Fm2wnCTHkkcEYcfw9pyovW0TNtkzS/jOkhGS0RUWncSqsB2iFAlJn7Nvo3 9s+3Jyop1zy2wF/iDMiAGXUkNuOD0KEM77L0s9VHIPUzXM36qimb7JGgyEILwUG3H33T CZBa4M9XMmTVXd1KJ7Nh0p5YmjO4czxoeNODDN6RJ0w/wi5cujBOaCyH71ao45Emn0pJ pa6Q== 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=Z1lJgiKuL1T7yi6IISouQCBYRQGgT4fCoXXHrKwqKzM=; b=7AUR8sKIY2TLA2ifSGvbzNS4Al8xKjHzh9ROziG5UWrzwbf54zbzF3V01JY9Q6ZgYy YNQdOYSrvDOI8RtoOivpdxwvuEOuLd1XlG0/JBold79tWQRYQV+wmcDhaBsIGUQveuTM /WFwIUAXjRbNRXOWowowpTu43t/pb97mBfTiIEqCZUs4URhJf9ckg8BWlW2oVKP4dAi9 uB6YVmGodl8PbZfLuc+rdAG7+Ufzx4WxQIWdfpiwEEcytxQILEoCU68T+MRQwapZKAHo W/5HjDjHd0P5Eu+y01nrfTYBWFjlvwcx76RFQ4gQfemqUNAvkyjgYs18kVCne10deMFa pVPw== X-Gm-Message-State: AOAM532gs7R4MEJdFLsrEnJhxkNsCNu+p5xB9wXGVws57BTNkDUNc/ZI hqKVH3LQ5q6yKuwdvZsR26sdW0Of9UkZdQ4xBhM= X-Google-Smtp-Source: ABdhPJzwWnUOTAQJvTOiqO4+wiBy+ibKfNl4Eur49c54hh/3lH9WG9Ai9/JLpUkNPi8VO1mD5GU7Gtw5BcdLs2TPtD8= X-Received: by 2002:a05:6830:1045:: with SMTP id b5mr4311782otp.338.1634632967897; Tue, 19 Oct 2021 01:42:47 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <26d9fc32-4884-602c-975a-79fc64551727@gmail.com> In-Reply-To: From: Ted Hardie Date: Tue, 19 Oct 2021 09:42:21 +0100 Message-ID: To: Mark Smith Cc: Brian E Carpenter , "spring@ietf.org" , "ipv6@ietf.org" Content-Type: multipart/alternative; boundary="00000000000063c7a705ceb0a5d1" Archived-At: Subject: [spring] Administrative interfaces (was draft-filsfilscheng-spring-srv6-srh-compression) 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, 19 Oct 2021 08:42:54 -0000 --00000000000063c7a705ceb0a5d1 Content-Type: text/plain; charset="UTF-8" Hi Mark, I updated the subject because I think this is a distinct question, and I've tried to pull that question into focus by cutting to that text below. I hope that's okay. On Tue, Oct 19, 2021 at 8:11 AM Mark Smith wrote: > Hi Brian, > > On Tue, 19 Oct 2021 at 15:51, Brian E Carpenter > > If a router as a physical device has IPv6 addresses that are sent to > the device itself, then the router as a physical device is also > performing host functions. For packets with those "router addresses", > the router as a physical device is not "forward[ing] IPv6 packets not > explicitly addressed to itself. " > > In many deployments the packets sent to the router while it is "performing host functions" are sent to a distinct interface (or distinct interfaces, when there is one for each address family). That interface or those interfaces typically have distinct security controls and expose different ports (so that you can ssh in, for example). I think it would be reasonable to add text on using SID addressing to reach administrative interfaces. I think that would work along the lines already laid out, with the administrative interfaces being outside the SR domain, but additional thought and text on it might well be useful. > In a router as a physical device, the forwarding plane is performing > the router function above. In a router as a physical device, the > "control plane" (really just a fancy name for a host) is performing > host functions on packets that are directly to and from it (BGP, OSPF, > SSH, SNMP etc. packets). > > The consequence is that all IPv6 addresses are host addresses, and all > processing of packets at the device that holds a packet's DA is host > processing of the packet. > I must disagree with this conclusion. I think RFC 8504 was written the way it was to highlight that there is some commonality between hosts and routers and to set out the node requirements that unite the two. But there are clear differences between the processing of a packet by a router and by a host, with forwarding behavior being chief among them. To say that all processing is host processing is to gloss over both an architectural distinction and the deployed reality I mentioned before. The reason people maintain distinct administrative addresses is to ensure that the host processing and router processing remain distinct. I think Brian's note is maintaining a distinction that is both generally important and important for understanding this case. Speaking personally, I'd like to retain that understanding. best regards, Ted Hardie > > It is the same in IPv4 - from RFC791, "The internet protocol provides > for transmitting blocks of data called datagrams from sources to > destinations, where sources and destinations are hosts identified by > fixed length addresses." > > So these packets with CSID rotating IPv6 DAs are being host processed > by the router (as a device), after the forwarding plane in the router > (as a device) has forwarded the packet to the colocated host function. > > (A more practical example to support the above observation. If a > router as a device is bought from a router vendor, and then is run as > a BGP route reflector, meaning it is never in a packet forwarding > path, and therefore never "forwards IPv6 packets not explicitly > addressed to itself" is the router device still a router? Functionally > no, it is a host, even though it looks like a router (as a device).) > > Regards, > Mark. > > > Another way to say it is RFC 7608 is the relevant architectural > > standard. CIDR rules, even within an SR domain. > > > > For that reason, the fact that the bottom 64 bits in the > > "address" look funny or change is simply irrelevant. They are > > invisible to routing (which is done based on the prefix) > > and invisible to neighbor discovery (because it never happens). > > > > I apologise if this is all obvious to everybody, but I needed > > to spell it out for my own understanding. > > > > Now back to Joel's questions: > > > > > > On 13-Oct-21 20:37, Joel M. Halpern wrote: > > > There is a typo in the below which if not understood as a typo would be > > > > > quite confusing. I wrote that I raised the issue with > > > "with the Internet ADs and SPRING chairs". > > > That should have read "with the Internet ADs and 6man chairs". > > > The SPRING co-chairs are recused, and the charter requirement leads to > > > the 6man chairs. Which is who I talked to. > > > > > > Also, I am sending a courtesy copy to the routing ADs, which I should > > > have done originally. > > > > > > Thank you and enjoy. > > > Yours, > > > Joel > > > > > > On 10/12/2021 11:52 PM, Joel M. Halpern wrote: > > >> The SPRING working group is in the midst of an adoption call on > > >> > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > . > > >> > > >> > > >> The SPRING charter has text that is explicit that modifications to > data > > >> planes and architectures standardized by other working groups may not > be > > >> modified in SPRING unless the chairs and ADs responsible for that data > > > > >> plane and / or architecture agree. > > >> > > >> To complete the context, as my SPRING co-chairs are co-authors on the > > >> document in question, they have recused themselves from decisional > > >> activities regarding the document. Therefore, this message is coming > > >> just from my as the responsible SPRING co-chair managing this adoption > > > > >> call. > > >> > > >> As you have seen, multiple questions have been raised about the > > >> relationship of the document to the IPv6 defined data plane and > > >> architecture (particularly RFC 4291 and 8200). In particular the > > >> questions seem to revolve around what the document describes as the > > >> NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6 > > >> standards. (For those seeking more context without reading the full > > >> document, a paraphrase and simplification of the NEXT-C_SID flavor is > > >> provided as a postscript.) > > >> > > >> I raised the question of concurrence as required by the SPRING charter > > > > >> with the Internet ADs and SPRING chairs. They quite reasonably asked > me > > >> to write a note to 6man explaining the concerns as clearly as a can, > so > > >> that they can then determine how to proceed. > > >> > > >> The questions that prompted my inquiry are: > > >> > > >> 1) Does the placement of a list of sids in the IPv6 DA field change > the > > >> IPv6 architectural description of that field. > > > > I think it should be noted explicitly somewhere that since the contents > > of the DA field are *never* used for last-hop neighbor discovery, > > the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942 > > are irrelevant. Another citation is RFC 7608: for routing, all that > > counts is the prefix, and it can be anything up to 128. > > > > Perhaps this should have been in section 5 of RFC 8754, but I leave > > that to the wordsmiths. > > > > >> 2) Does the operation of shifting information around in the IPv6 > > >> destination address field represent a modification or extension of the > > > > >> IPv6 data plane. > > > > No. As my text above indicates, the SRv6 DA field is only ever used > > by routing, where RFC 7608 rules. And of course it vanishes as soon > > as the packet is decapsulated. > > > > Regards > > Brian > > > > >> > > >> On a related note, the document in question also defines two other > > >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The > > >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID > > >> flavor operation, so seems to be affected by the same question. > > >> > > >> From my own reading, it appears that the REPLACE-C-SID flavor does > not > > >> raise issues requiring 6man leadership concurrence. > > >> > > >> Yours, > > >> Joel M. Halpern for the SPRING working group > > >> > > >> > > >> PS: > > >> Clearly, understanding the question requires some understanding of > what > > >> the NEXT-C_SID flavor does. This explanation is a simplification for > > >> length and context. Really, the best place to understand it is the > > >> draft. However, to give you enough information to let you decide > > > > >> whether you care, I will try to provide a fair summary. My apologies > in > > >> advance to the authors for necessary liberties for length. Also, > > > > >> discussion of the draft contents (as distinct from the interaction > with > > >> the IPv6 data plane and architecture) belongs on the SPRING list, and > > >> should not clutter up 6man. > > >> > > >> SIDs are the identifiers used in segment routing. > > >> In SRv6, as document in the current RFCs, these are 128 bits. As > > >> defined in the relevant RFCs, SIDs which identify endpoints to which > > >> packets are directed are identified by endpoint SIDs. These can have > > >> behaviors (decapsulate and forward is one example). They can have > > >> flavors such as where the SRH is removed. > > >> > > >> The topic under discussion is means to compress these SIDs in the > > >> packets on the wire. The document under discussion provides three > > >> flavors of compression. > > >> > > >> The fundamental mechanism of the draft is to use a single SRH entry as > > a > > >> container for multiple SIDs. In the NEXT-C_SID mechanism, when it is > > >> first encountered the entire container is copied into the desination > > >> address of the IPv6 packet. The container has a common routing prefix > > >> used for all the NEXT-C-SID SIDs. It is followed by a sequence of > > >> compressed SIDs of a configured length. One could configure 16, 24, > or > > >> 32 bits. Or whatever length. The routing advertisements are arranged > > >> so that the IPv6 packet is directed to the node represented by the > first > > >> compressed SID on the basis of longest prefix match matching the > > >> combination of the common routing prefix and that compressed SID. > > >> > > >> When the packet arrives at that node, it looks up the configured > > >> portion, the compressed SID, and determines the behavior and flavor. > In > > >> the case of the NEXT-C-SID flavor, the resulting operation is to shift > > > > >> the entire remaining contents of the IPv6 address (the bits past the > > >> first compressed sid) so as to over-write the first compressed SID. 0 > > >> bits are shifted into the low order positions. If the result is a > > >> non-zero new first compressed SID, then the packets is forwarded and > the > > >> process repeats. When all that is left are 0s, if there is an SRH, it > > >> is consulted to find the next SRH entry, which is, per normal SRv6 > > >> processing, put into the IPv6 DA. > > >> Note that in the common case where the SIDS needed all fit in to a > > >> single container, the analysis also assumes the use of the reduced > > >> encapsulation options which omits the SRH that is not needed as it > would > > >> have no entries. This the packet contains a normal IPv6 header, with > a > > >> sequence of compressed SIDs (what one might or might not call a source > > > > >> route) in the IPv6 destination address field. > > >> > > >> PPS: If the authors of the NEXT-C-SID flavor feel I have > mis-represented > > >> the work, please, send clarifications or corrections. Again, the > best > > >> source of information is the draft itself. I was asked to provide > extra > > >> context in this email. > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --00000000000063c7a705ceb0a5d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Mark,

    I = updated the subject because I think this is a distinct question, and I'= ve tried to pull that question into focus by cutting to that text below.=C2= =A0 I hope that's okay.

    <= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Oct 19, 2021 at 8:11 AM Mark S= mith <markzzzsmith@gmail.com> wrote:
    Hi= Brian,

    On Tue, 19 Oct 2021 at 15:51, Brian E Carpenter

    If a router as a physical device has IPv6 addresses that are sent to
    the device itself, then the router as a physical device is also
    performing host functions. For packets with those "router addresses&qu= ot;,
    the router as a physical device is not "forward[ing] IPv6 packets not<= br> explicitly addressed to itself. "



    In a router as a physical device, the forwarding plane is performing
    the router function above. In a router as a physical device, the
    "control plane" (really just a fancy name for a host) is performi= ng
    host functions on packets that are directly to and from it (BGP, OSPF,
    SSH, SNMP etc. packets).

    The consequence is that all IPv6 addresses are host addresses, and all
    processing of packets at the device that holds a packet's DA is host processing of the packet.

    I must disagree with this conclus= ion.=C2=A0 I think RFC 8504 was written the way it was to highlight that th= ere is some commonality between hosts and routers and to set out the node r= equirements that unite the two.=C2=A0 But there are clear differences betwe= en the processing of a packet by a router and by a host, with forwarding be= havior being chief among them.=C2=A0 To say that all processing is host pro= cessing is to gloss over both an architectural distinction and the deployed= reality I mentioned before.=C2=A0 The reason people maintain distinct admi= nistrative addresses is to ensure that the host processing and router proce= ssing remain distinct.=C2=A0

    I think Brian's note is maintaining a distinction that is both= generally important and important for understanding this case.=C2=A0 Speak= ing personally, I'd like to retain that understanding.

    best regards,

    Ted Hardie


    It is the same in IPv4=C2=A0 - from RFC791, "The internet protocol pro= vides
    for transmitting blocks of data called datagrams from sources to
    destinations, where sources and destinations are hosts identified by
    fixed length addresses."

    So these packets with CSID rotating IPv6 DAs are being host processed
    by the router (as a device), after the forwarding plane in the router
    (as a device) has forwarded the packet to the colocated host function.

    (A more practical example to support the above observation. If a
    router as a device is bought from a router vendor, and then is run as
    a BGP route reflector, meaning it is never in a packet forwarding
    path, and therefore never "forwards IPv6 packets not explicitly
    addressed to itself" is the router device still a router? Functionally=
    no, it is a host, even though it looks like a router (as a device).)

    Regards,
    Mark.

    > Another way to say it is RFC 7608 is the relevant architectural
    > standard. CIDR rules, even within an SR domain.
    >
    > For that reason, the fact that the bottom 64 bits in the
    > "address" look funny or change is simply irrelevant. They ar= e
    > invisible to routing (which is done based on the prefix)
    > and invisible to neighbor discovery (because it never happens).
    >
    > I apologise if this is all obvious to everybody, but I needed
    > to spell it out for my own understanding.
    >
    > Now back to Joel's questions:
    >
    >
    > On 13-Oct-21 20:37, Joel M. Halpern wrote:
    > > There is a typo in the below which if not understood as a typo wo= uld be
    >
    > > quite confusing.=C2=A0 =C2=A0I wrote that I raised the issue with=
    > > "with the Internet ADs and SPRING chairs".
    > > That should have read "with the Internet ADs and 6man chairs= ".
    > > The SPRING co-chairs are recused, and the charter requirement lea= ds to
    > > the 6man chairs.=C2=A0 Which is who I talked to.
    > >
    > > Also, I am sending a courtesy copy to the routing ADs, which I sh= ould
    > > have done originally.
    > >
    > > Thank you and enjoy.
    > > Yours,
    > > Joel
    > >
    > > On 10/12/2021 11:52 PM, Joel M. Halpern wrote:
    > >> The SPRING working group is in the midst of an adoption call = on
    > >>     https= ://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression= /.
    > >>
    > >>
    > >> The SPRING charter has text that is explicit that modificatio= ns to data
    > >> planes and architectures standardized by other working groups= may not be
    > >> modified in SPRING unless the chairs and ADs responsible for = that data
    >
    > >> plane and / or architecture agree.
    > >>
    > >> To complete the context, as my SPRING co-chairs are co-author= s on the
    > >> document in question, they have recused themselves from decis= ional
    > >> activities regarding the document.=C2=A0 Therefore, this mess= age is coming
    > >> just from my as the responsible SPRING co-chair managing this= adoption
    >
    > >> call.
    > >>
    > >> As you have seen, multiple questions have been raised about t= he
    > >> relationship of the document to the IPv6 defined data plane a= nd
    > >> architecture (particularly RFC 4291 and 8200). In particular = the
    > >> questions seem to revolve around what the document describes = as the
    > >> NEXT-C-SID flavor of compressed SID, and its relationship to = the IPv6
    > >> standards.=C2=A0 (For those seeking more context without read= ing the full
    > >> document, a paraphrase and simplification of the NEXT-C_SID f= lavor is
    > >> provided as a postscript.)
    > >>
    > >> I raised the question of concurrence as required by the SPRIN= G charter
    >
    > >> with the Internet ADs and SPRING chairs.=C2=A0 They quite rea= sonably asked me
    > >> to write a note to 6man explaining the concerns as clearly as= a can, so
    > >> that they can then determine how to proceed.
    > >>
    > >> The questions that prompted my inquiry are:
    > >>
    > >> 1) Does the placement of a list of sids in the IPv6 DA field = change the
    > >> IPv6 architectural description of that field.
    >
    > I think it should be noted explicitly somewhere that since the content= s
    > of the DA field are *never* used for last-hop neighbor discovery,
    > the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942
    > are irrelevant. Another citation is RFC 7608: for routing, all that > counts is the prefix, and it can be anything up to 128.
    >
    > Perhaps this should have been in section 5 of RFC 8754, but I leave > that to the wordsmiths.
    >
    > >> 2) Does the operation of shifting information around in the I= Pv6
    > >> destination address field represent a modification or extensi= on of the
    >
    > >> IPv6 data plane.
    >
    > No. As my text above indicates, the SRv6 DA field is only ever used > by routing, where RFC 7608 rules. And of course it vanishes as soon > as the packet is decapsulated.
    >
    > Regards
    >=C2=A0 =C2=A0 =C2=A0Brian
    >
    > >>
    > >> On a related note, the document in question also defines two = other
    > >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.=C2=A0 The=
    > >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-= C_SID
    > >> flavor operation, so seems to be affected by the same questio= n.
    > >>
    > >>=C2=A0 From my own reading, it appears that the REPLACE-C-SID = flavor does not
    > >> raise issues requiring 6man leadership concurrence.
    > >>
    > >> Yours,
    > >> Joel M. Halpern for the SPRING working group
    > >>
    > >>
    > >> PS:
    > >> Clearly, understanding the question requires some understandi= ng of what
    > >> the NEXT-C_SID flavor does.=C2=A0 =C2=A0This explanation is a= simplification for
    > >> length and context.=C2=A0 Really, the best place to understan= d it is the
    > >> draft.=C2=A0 However, to give you enough information to let y= ou decide
    >
    > >> whether you care, I will try to provide a fair summary.=C2=A0= My apologies in
    > >> advance to the authors for necessary liberties for length.=C2= =A0 Also,
    >
    > >> discussion of the draft contents (as distinct from the intera= ction with
    > >> the IPv6 data plane and architecture) belongs on the SPRING l= ist, and
    > >> should not clutter up 6man.
    > >>
    > >> SIDs are the identifiers used in segment routing.
    > >> In SRv6, as document in the current RFCs, these are 128 bits.= =C2=A0 =C2=A0As
    > >> defined in the relevant RFCs, SIDs which identify endpoints t= o which
    > >> packets are directed are identified by endpoint SIDs.=C2=A0 T= hese can have
    > >> behaviors (decapsulate and forward is one example).=C2=A0 The= y can have
    > >> flavors such as where the SRH is removed.
    > >>
    > >> The topic under discussion is means to compress these SIDs in= the
    > >> packets on the wire.=C2=A0 The document under discussion prov= ides three
    > >> flavors of compression.
    > >>
    > >> The fundamental mechanism of the draft is to use a single SRH= entry as
    > a
    > >> container for multiple SIDs.=C2=A0 In the NEXT-C_SID mechanis= m, when it is
    > >> first encountered the entire container is copied into the des= ination
    > >> address of the IPv6 packet.=C2=A0 The container has a common = routing prefix
    > >> used for all the NEXT-C-SID SIDs.=C2=A0 It is followed by a s= equence of
    > >> compressed SIDs of a configured length.=C2=A0 One could confi= gure 16, 24, or
    > >> 32 bits.=C2=A0 Or whatever length.=C2=A0 The routing advertis= ements are arranged
    > >> so that the IPv6 packet is directed to the node represented b= y the first
    > >> compressed SID on the basis of longest prefix match matching = the
    > >> combination of the common routing prefix and that compressed = SID.
    > >>
    > >> When the packet arrives at that node, it looks up the configu= red
    > >> portion, the compressed SID, and determines the behavior and = flavor.=C2=A0 In
    > >> the case of the NEXT-C-SID flavor, the resulting operation is= to shift
    >
    > >> the entire remaining contents of the IPv6 address (the bits p= ast the
    > >> first compressed sid) so as to over-write the first compresse= d SID.=C2=A0 0
    > >> bits are shifted into the low order positions.=C2=A0 If the r= esult is a
    > >> non-zero new first compressed SID, then the packets is forwar= ded and the
    > >> process repeats.=C2=A0 When all that is left are 0s, if there= is an SRH, it
    > >> is consulted to find the next SRH entry, which is, per normal= SRv6
    > >> processing, put into the IPv6 DA.
    > >> Note that in the common case where the SIDS needed all fit in= to a
    > >> single container, the analysis also assumes the use of the re= duced
    > >> encapsulation options which omits the SRH that is not needed = as it would
    > >> have no entries.=C2=A0 This the packet contains a normal IPv6= header, with a
    > >> sequence of compressed SIDs (what one might or might not call= a source
    >
    > >> route) in the IPv6 destination address field.
    > >>
    > >> PPS: If the authors of the NEXT-C-SID flavor feel I have mis-= represented
    > >> the work, please, send clarifications or corrections.=C2=A0 = =C2=A0Again, the best
    > >> source of information is the draft itself.=C2=A0 I was asked = to provide extra
    > >> context in this email.
    > >
    > > -----------------------------------------------------------------= ---
    > > IETF IPv6 working group mailing list
    > > ipv6@ietf.org<= /a>
    > > Administrative Requests:     https://www.ietf.org/ma= ilman/listinfo/ipv6
    > > -----------------------------------------------------------------= ---
    > >
    >
    > -------------------------------------------------------------------- > IETF IPv6 working group mailing list
    > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
    > --------------------------------------------------------------------
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
    --------------------------------------------------------------------
    --000000000000a5200b05ceb3f8c4-- From nobody Tue Oct 19 09:06:23 2021 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 C25BC3A0C36 for ; Tue, 19 Oct 2021 09:05:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20210112.gappssmtp.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 XS5-7jkKOS3E for ; Tue, 19 Oct 2021 09:05:42 -0700 (PDT) Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (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 0FC193A0A87 for ; Tue, 19 Oct 2021 09:05:42 -0700 (PDT) Received: by mail-ed1-x535.google.com with SMTP id i20so14594110edj.10 for ; Tue, 19 Oct 2021 09:05:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gIliAA817SMOwNByF+Oe39WdeX6SDogWHji+XXh+gzE=; b=kGlTG0GO4Kfe5R4uxZ446NQnqxDHS1Upjox6QHlxtW7Rmv64sGY2qKeZMeX74UkH7T qo1iJdDBzT5xydvKrG3WgdLBZ7VHBXFMOWG9Blo0YPt0HgLKne+VSImM4v2XIEqtwFHx qc+28T7jUUp4+oTU4XOyk4l2K/e5GhcsU3aXVlWqo9tyJUDYim+YU+nfJcMR9BxQ1Hih 4KZvnHZH1VAag2rIpdE80mQNQbHZ9Rj9Db23m2l3WPVIGKXsI7Y+NBbmO+DTEJFhHM6Q 5h0MjptvgvJMAQjN69tfCm/YtfHiIw/+ZslUVhJ7lWRQvckQqsS3zuPWHufzAHmM+i7E wOmg== 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=gIliAA817SMOwNByF+Oe39WdeX6SDogWHji+XXh+gzE=; b=bSs9rfrYlGDJYsCV0BJb1DV/DQIqGgTJGLXwoY0XUj9B82+ArUCZZQPqDewmtNdQ3h UjIQ1kG6Xrrg3uJBAtoKguJWtyEdQFd8uCHeQ0WZyaoTbLREofvOZFO5+pT+PTc2VMBt UZJuuVK3IDD3uxigeYWDSgxMQ6whokhpG4pa6vmN5tGvyyaKMf6kG6GvhUzvbEH96Oa2 BWxZxtZCJ8hDeFmtuIPxH67rOQYsgH7r7EAuD/HewpWywyT+qpLE9wsjpVwhSd7R5jyJ niYxjT1gg3OZkC6kfDp7H3vNd02jmJGlpTBsium8yCKfS4oXo89jvAxD6xY9eS6ddRk+ wpgA== X-Gm-Message-State: AOAM530b0+owC6AQL/5agK6C8fFw6Eqj/ysS/xC6rv60DUZ101cIHt/p WiR/pMjZZAH0WC7ETUz9miy+km4Gph9yWb9MVcZMu0mG X-Google-Smtp-Source: ABdhPJxoNEGNlJLteMtADqTSYGFq+MJh6f8Lb3eTybzPdHJYRUDc/sH7wd2oam3L8F9J9NemiYUaRCDN6q4/zsJuJ7A= X-Received: by 2002:a17:906:48ce:: with SMTP id d14mr40211362ejt.336.1634659357638; Tue, 19 Oct 2021 09:02:37 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <26d9fc32-4884-602c-975a-79fc64551727@gmail.com> In-Reply-To: From: Tom Herbert Date: Tue, 19 Oct 2021 09:02:25 -0700 Message-ID: To: Mark Smith Cc: Brian E Carpenter , SPRING WG , 6man Content-Type: multipart/alternative; boundary="00000000000057686f05ceb6ca9a" Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 19 Oct 2021 16:05:48 -0000 --00000000000057686f05ceb6ca9a Content-Type: text/plain; charset="UTF-8" On Tue, Oct 19, 2021, 12:10 AM Mark Smith wrote: > Hi Brian, > > On Tue, 19 Oct 2021 at 15:51, Brian E Carpenter > wrote: > > > > Hi, > > > > After reading a lot of messages, I'm going to offer my considered > > opinion as a direct response to Joel's OP. > > > > Firstly, I don't believe that in the end this draft raises any > > concerns that are *significantly* different than those raised > > when RFC 8986 was in draft. As Ted Hardie mentioned, section 5 > > of RFC 8754 explains that SIDs of any shape or size are only > > meaningful within an SR domain. That applies to srh-compression > > too. > > > > Secondly, I was concerned about how these strange looking > > "addresses" would potentially interfere with normal IPv6 > > addresses and their handling by normal IPv6 nodes. Well, I > > now believe that they won't. The reason is that in the SR model > > these "addresses" are *never used for final delivery of IPv6 > > packets to a host.* All SRv6 participants are routers. The > > last hop for a packet whose DA is set to (say) 2001:db8:a:1900:: > > is *not* the last hop on a LAN, mediated by neighbor discovery > > for 2001:db8:a:1900::. It's just a hop from one router to another, > > using the entry for 2001:db8:a:1900::/64 in the FIB of the last > > router that actually forwards the packet. 2001:db8:a:1900:: is > > not assigned to a physical interface so RFC 4861 is never invoked. > > > > So I'm guessing you're probably thinking of a router as a physical > device (as most of us will by default), rather than as routing as a > function. > > RFC8200 definitions: > > "router a node that forwards IPv6 packets not explicitly > addressed to itself. (See Note below.) > > host any node that is not a router. (See Note below.)" > (the note is about hosts having multiple interfaces) > > (A node doesn't have to be a device, and a device doesn't have to be > physical, so the above are really function descriptions.) > > If a router as a physical device has IPv6 addresses that are sent to > the device itself, then the router as a physical device is also > performing host functions. For packets with those "router addresses", > the router as a physical device is not "forward[ing] IPv6 packets not > explicitly addressed to itself. " > > In a router as a physical device, the forwarding plane is performing > the router function above. In a router as a physical device, the > "control plane" (really just a fancy name for a host) is performing > host functions on packets that are directly to and from it (BGP, OSPF, > SSH, SNMP etc. packets). > > The consequence is that all IPv6 addresses are host addresses, and all > processing of packets at the device that holds a packet's DA is host > processing of the packet. > > It is the same in IPv4 - from RFC791, "The internet protocol provides > for transmitting blocks of data called datagrams from sources to > destinations, where sources and destinations are hosts identified by > fixed length addresses." > > So these packets with CSID rotating IPv6 DAs are being host processed > by the router (as a device), after the forwarding plane in the router > (as a device) has forwarded the packet to the colocated host function. > > (A more practical example to support the above observation. If a > router as a device is bought from a router vendor, and then is run as > a BGP route reflector, meaning it is never in a packet forwarding > path, and therefore never "forwards IPv6 packets not explicitly > addressed to itself" is the router device still a router? Functionally > no, it is a host, even though it looks like a router (as a device).) > Mark, On the other hand, when a node is processing a routing it header it does forward packets addressed to it self (but not being the final destination). Processing a router header is intuitively router functionality and not host functionality. The RFC8200 definition of host and router don't seem to consider routing headers, perhaps this should be amended to say that a host is the final destination of the packet. Tom > > Regards, > Mark. > > > Another way to say it is RFC 7608 is the relevant architectural > > standard. CIDR rules, even within an SR domain. > > > > For that reason, the fact that the bottom 64 bits in the > > "address" look funny or change is simply irrelevant. They are > > invisible to routing (which is done based on the prefix) > > and invisible to neighbor discovery (because it never happens). > > > > I apologise if this is all obvious to everybody, but I needed > > to spell it out for my own understanding. > > > > Now back to Joel's questions: > > > > > > On 13-Oct-21 20:37, Joel M. Halpern wrote: > > > There is a typo in the below which if not understood as a typo would be > > > > > quite confusing. I wrote that I raised the issue with > > > "with the Internet ADs and SPRING chairs". > > > That should have read "with the Internet ADs and 6man chairs". > > > The SPRING co-chairs are recused, and the charter requirement leads to > > > the 6man chairs. Which is who I talked to. > > > > > > Also, I am sending a courtesy copy to the routing ADs, which I should > > > have done originally. > > > > > > Thank you and enjoy. > > > Yours, > > > Joel > > > > > > On 10/12/2021 11:52 PM, Joel M. Halpern wrote: > > >> The SPRING working group is in the midst of an adoption call on > > >> > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > . > > >> > > >> > > >> The SPRING charter has text that is explicit that modifications to > data > > >> planes and architectures standardized by other working groups may not > be > > >> modified in SPRING unless the chairs and ADs responsible for that data > > > > >> plane and / or architecture agree. > > >> > > >> To complete the context, as my SPRING co-chairs are co-authors on the > > >> document in question, they have recused themselves from decisional > > >> activities regarding the document. Therefore, this message is coming > > >> just from my as the responsible SPRING co-chair managing this adoption > > > > >> call. > > >> > > >> As you have seen, multiple questions have been raised about the > > >> relationship of the document to the IPv6 defined data plane and > > >> architecture (particularly RFC 4291 and 8200). In particular the > > >> questions seem to revolve around what the document describes as the > > >> NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6 > > >> standards. (For those seeking more context without reading the full > > >> document, a paraphrase and simplification of the NEXT-C_SID flavor is > > >> provided as a postscript.) > > >> > > >> I raised the question of concurrence as required by the SPRING charter > > > > >> with the Internet ADs and SPRING chairs. They quite reasonably asked > me > > >> to write a note to 6man explaining the concerns as clearly as a can, > so > > >> that they can then determine how to proceed. > > >> > > >> The questions that prompted my inquiry are: > > >> > > >> 1) Does the placement of a list of sids in the IPv6 DA field change > the > > >> IPv6 architectural description of that field. > > > > I think it should be noted explicitly somewhere that since the contents > > of the DA field are *never* used for last-hop neighbor discovery, > > the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942 > > are irrelevant. Another citation is RFC 7608: for routing, all that > > counts is the prefix, and it can be anything up to 128. > > > > Perhaps this should have been in section 5 of RFC 8754, but I leave > > that to the wordsmiths. > > > > >> 2) Does the operation of shifting information around in the IPv6 > > >> destination address field represent a modification or extension of the > > > > >> IPv6 data plane. > > > > No. As my text above indicates, the SRv6 DA field is only ever used > > by routing, where RFC 7608 rules. And of course it vanishes as soon > > as the packet is decapsulated. > > > > Regards > > Brian > > > > >> > > >> On a related note, the document in question also defines two other > > >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The > > >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID > > >> flavor operation, so seems to be affected by the same question. > > >> > > >> From my own reading, it appears that the REPLACE-C-SID flavor does > not > > >> raise issues requiring 6man leadership concurrence. > > >> > > >> Yours, > > >> Joel M. Halpern for the SPRING working group > > >> > > >> > > >> PS: > > >> Clearly, understanding the question requires some understanding of > what > > >> the NEXT-C_SID flavor does. This explanation is a simplification for > > >> length and context. Really, the best place to understand it is the > > >> draft. However, to give you enough information to let you decide > > > > >> whether you care, I will try to provide a fair summary. My apologies > in > > >> advance to the authors for necessary liberties for length. Also, > > > > >> discussion of the draft contents (as distinct from the interaction > with > > >> the IPv6 data plane and architecture) belongs on the SPRING list, and > > >> should not clutter up 6man. > > >> > > >> SIDs are the identifiers used in segment routing. > > >> In SRv6, as document in the current RFCs, these are 128 bits. As > > >> defined in the relevant RFCs, SIDs which identify endpoints to which > > >> packets are directed are identified by endpoint SIDs. These can have > > >> behaviors (decapsulate and forward is one example). They can have > > >> flavors such as where the SRH is removed. > > >> > > >> The topic under discussion is means to compress these SIDs in the > > >> packets on the wire. The document under discussion provides three > > >> flavors of compression. > > >> > > >> The fundamental mechanism of the draft is to use a single SRH entry as > > a > > >> container for multiple SIDs. In the NEXT-C_SID mechanism, when it is > > >> first encountered the entire container is copied into the desination > > >> address of the IPv6 packet. The container has a common routing prefix > > >> used for all the NEXT-C-SID SIDs. It is followed by a sequence of > > >> compressed SIDs of a configured length. One could configure 16, 24, > or > > >> 32 bits. Or whatever length. The routing advertisements are arranged > > >> so that the IPv6 packet is directed to the node represented by the > first > > >> compressed SID on the basis of longest prefix match matching the > > >> combination of the common routing prefix and that compressed SID. > > >> > > >> When the packet arrives at that node, it looks up the configured > > >> portion, the compressed SID, and determines the behavior and flavor. > In > > >> the case of the NEXT-C-SID flavor, the resulting operation is to shift > > > > >> the entire remaining contents of the IPv6 address (the bits past the > > >> first compressed sid) so as to over-write the first compressed SID. 0 > > >> bits are shifted into the low order positions. If the result is a > > >> non-zero new first compressed SID, then the packets is forwarded and > the > > >> process repeats. When all that is left are 0s, if there is an SRH, it > > >> is consulted to find the next SRH entry, which is, per normal SRv6 > > >> processing, put into the IPv6 DA. > > >> Note that in the common case where the SIDS needed all fit in to a > > >> single container, the analysis also assumes the use of the reduced > > >> encapsulation options which omits the SRH that is not needed as it > would > > >> have no entries. This the packet contains a normal IPv6 header, with > a > > >> sequence of compressed SIDs (what one might or might not call a source > > > > >> route) in the IPv6 destination address field. > > >> > > >> PPS: If the authors of the NEXT-C-SID flavor feel I have > mis-represented > > >> the work, please, send clarifications or corrections. Again, the > best > > >> source of information is the draft itself. I was asked to provide > extra > > >> context in this email. > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --00000000000057686f05ceb6ca9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Tue, Oct 19, 2021, 12:10 AM Mark Smith <markzzzsmith@gmail.com> wrote:
    Hi Brian,

    On Tue, 19 Oct 2021 at 15:51, Brian E Carpenter
    <brian.e.carpenter@gmail.com> wrote:
    >
    > Hi,
    >
    > After reading a lot of messages, I'm going to offer my considered<= br> > opinion as a direct response to Joel's OP.
    >
    > Firstly, I don't believe that in the end this draft raises any
    > concerns that are *significantly* different than those raised
    > when RFC 8986 was in draft. As Ted Hardie mentioned, section 5
    > of RFC 8754 explains that SIDs of any shape or size are only
    > meaningful within an SR domain. That applies to srh-compression
    > too.
    >
    > Secondly, I was concerned about how these strange looking
    > "addresses" would potentially interfere with normal IPv6
    > addresses and their handling by normal IPv6 nodes. Well, I
    > now believe that they won't. The reason is that in the SR model > these "addresses" are *never used for final delivery of IPv6=
    > packets to a host.* All SRv6 participants are routers. The
    > last hop for a packet whose DA is set to (say) 2001:db8:a:1900::
    > is *not* the last hop on a LAN, mediated by neighbor discovery
    > for 2001:db8:a:1900::. It's just a hop from one router to another,=
    > using the entry for 2001:db8:a:1900::/64 in the FIB of the last
    > router that actually forwards the packet. 2001:db8:a:1900:: is
    > not assigned to a physical interface so RFC 4861 is never invoked.
    >

    So I'm guessing you're probably thinking of a router as a physical<= br> device (as most of us will by default), rather than as routing as a
    function.

    RFC8200 definitions:

    "router=C2=A0 =C2=A0 =C2=A0 =C2=A0a node that forwards IPv6 packets no= t explicitly
    =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 addressed to itself= .=C2=A0 (See Note below.)

    =C2=A0 =C2=A0host=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0any node that is not a r= outer.=C2=A0 (See Note below.)"
    (the note is about hosts having multiple interfaces)

    (A node doesn't have to be a device, and a device doesn't have to b= e
    physical, so the above are really function descriptions.)

    If a router as a physical device has IPv6 addresses that are sent to
    the device itself, then the router as a physical device is also
    performing host functions. For packets with those "router addresses&qu= ot;,
    the router as a physical device is not "forward[ing] IPv6 packets not<= br> explicitly addressed to itself. "

    In a router as a physical device, the forwarding plane is performing
    the router function above. In a router as a physical device, the
    "control plane" (really just a fancy name for a host) is performi= ng
    host functions on packets that are directly to and from it (BGP, OSPF,
    SSH, SNMP etc. packets).

    The consequence is that all IPv6 addresses are host addresses, and all
    processing of packets at the device that holds a packet's DA is host processing of the packet.

    It is the same in IPv4=C2=A0 - from RFC791, "The internet protocol pro= vides
    for transmitting blocks of data called datagrams from sources to
    destinations, where sources and destinations are hosts identified by
    fixed length addresses."

    So these packets with CSID rotating IPv6 DAs are being host processed
    by the router (as a device), after the forwarding plane in the router
    (as a device) has forwarded the packet to the colocated host function.

    (A more practical example to support the above observation. If a
    router as a device is bought from a router vendor, and then is run as
    a BGP route reflector, meaning it is never in a packet forwarding
    path, and therefore never "forwards IPv6 packets not explicitly
    addressed to itself" is the router device still a router? Functionally=
    no, it is a host, even though it looks like a router (as a device).)

    Mark,

    On the other hand, when a= node is processing a routing it header it does forward packets addressed t= o it self (but not being the final destination). Processing a router header= is intuitively router functionality and not host functionality. The RFC820= 0 definition of host and router don't seem to consider routing headers,= perhaps this should be amended to say that a host is the final destination= of the packet.

    Tom
    https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-= compression/.
    > >>
    > >>
    > >> The SPRING charter has text that is explicit that modificatio= ns to data
    > >> planes and architectures standardized by other working groups= may not be
    > >> modified in SPRING unless the chairs and ADs responsible for = that data
    >
    > >> plane and / or architecture agree.
    > >>
    > >> To complete the context, as my SPRING co-chairs are co-author= s on the
    > >> document in question, they have recused themselves from decis= ional
    > >> activities regarding the document.=C2=A0 Therefore, this mess= age is coming
    > >> just from my as the responsible SPRING co-chair managing this= adoption
    >
    > >> call.
    > >>
    > >> As you have seen, multiple questions have been raised about t= he
    > >> relationship of the document to the IPv6 defined data plane a= nd
    > >> architecture (particularly RFC 4291 and 8200). In particular = the
    > >> questions seem to revolve around what the document describes = as the
    > >> NEXT-C-SID flavor of compressed SID, and its relationship to = the IPv6
    > >> standards.=C2=A0 (For those seeking more context without read= ing the full
    > >> document, a paraphrase and simplification of the NEXT-C_SID f= lavor is
    > >> provided as a postscript.)
    > >>
    > >> I raised the question of concurrence as required by the SPRIN= G charter
    >
    > >> with the Internet ADs and SPRING chairs.=C2=A0 They quite rea= sonably asked me
    > >> to write a note to 6man explaining the concerns as clearly as= a can, so
    > >> that they can then determine how to proceed.
    > >>
    > >> The questions that prompted my inquiry are:
    > >>
    > >> 1) Does the placement of a list of sids in the IPv6 DA field = change the
    > >> IPv6 architectural description of that field.
    >
    > I think it should be noted explicitly somewhere that since the content= s
    > of the DA field are *never* used for last-hop neighbor discovery,
    > the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942
    > are irrelevant. Another citation is RFC 7608: for routing, all that > counts is the prefix, and it can be anything up to 128.
    >
    > Perhaps this should have been in section 5 of RFC 8754, but I leave > that to the wordsmiths.
    >
    > >> 2) Does the operation of shifting information around in the I= Pv6
    > >> destination address field represent a modification or extensi= on of the
    >
    > >> IPv6 data plane.
    >
    > No. As my text above indicates, the SRv6 DA field is only ever used > by routing, where RFC 7608 rules. And of course it vanishes as soon > as the packet is decapsulated.
    >
    > Regards
    >=C2=A0 =C2=A0 =C2=A0Brian
    >
    > >>
    > >> On a related note, the document in question also defines two = other
    > >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.=C2=A0 The=
    > >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-= C_SID
    > >> flavor operation, so seems to be affected by the same questio= n.
    > >>
    > >>=C2=A0 From my own reading, it appears that the REPLACE-C-SID = flavor does not
    > >> raise issues requiring 6man leadership concurrence.
    > >>
    > >> Yours,
    > >> Joel M. Halpern for the SPRING working group
    > >>
    > >>
    > >> PS:
    > >> Clearly, understanding the question requires some understandi= ng of what
    > >> the NEXT-C_SID flavor does.=C2=A0 =C2=A0This explanation is a= simplification for
    > >> length and context.=C2=A0 Really, the best place to understan= d it is the
    > >> draft.=C2=A0 However, to give you enough information to let y= ou decide
    >
    > >> whether you care, I will try to provide a fair summary.=C2=A0= My apologies in
    > >> advance to the authors for necessary liberties for length.=C2= =A0 Also,
    >
    > >> discussion of the draft contents (as distinct from the intera= ction with
    > >> the IPv6 data plane and architecture) belongs on the SPRING l= ist, and
    > >> should not clutter up 6man.
    > >>
    > >> SIDs are the identifiers used in segment routing.
    > >> In SRv6, as document in the current RFCs, these are 128 bits.= =C2=A0 =C2=A0As
    > >> defined in the relevant RFCs, SIDs which identify endpoints t= o which
    > >> packets are directed are identified by endpoint SIDs.=C2=A0 T= hese can have
    > >> behaviors (decapsulate and forward is one example).=C2=A0 The= y can have
    > >> flavors such as where the SRH is removed.
    > >>
    > >> The topic under discussion is means to compress these SIDs in= the
    > >> packets on the wire.=C2=A0 The document under discussion prov= ides three
    > >> flavors of compression.
    > >>
    > >> The fundamental mechanism of the draft is to use a single SRH= entry as
    > a
    > >> container for multiple SIDs.=C2=A0 In the NEXT-C_SID mechanis= m, when it is
    > >> first encountered the entire container is copied into the des= ination
    > >> address of the IPv6 packet.=C2=A0 The container has a common = routing prefix
    > >> used for all the NEXT-C-SID SIDs.=C2=A0 It is followed by a s= equence of
    > >> compressed SIDs of a configured length.=C2=A0 One could confi= gure 16, 24, or
    > >> 32 bits.=C2=A0 Or whatever length.=C2=A0 The routing advertis= ements are arranged
    > >> so that the IPv6 packet is directed to the node represented b= y the first
    > >> compressed SID on the basis of longest prefix match matching = the
    > >> combination of the common routing prefix and that compressed = SID.
    > >>
    > >> When the packet arrives at that node, it looks up the configu= red
    > >> portion, the compressed SID, and determines the behavior and = flavor.=C2=A0 In
    > >> the case of the NEXT-C-SID flavor, the resulting operation is= to shift
    >
    > >> the entire remaining contents of the IPv6 address (the bits p= ast the
    > >> first compressed sid) so as to over-write the first compresse= d SID.=C2=A0 0
    > >> bits are shifted into the low order positions.=C2=A0 If the r= esult is a
    > >> non-zero new first compressed SID, then the packets is forwar= ded and the
    > >> process repeats.=C2=A0 When all that is left are 0s, if there= is an SRH, it
    > >> is consulted to find the next SRH entry, which is, per normal= SRv6
    > >> processing, put into the IPv6 DA.
    > >> Note that in the common case where the SIDS needed all fit in= to a
    > >> single container, the analysis also assumes the use of the re= duced
    > >> encapsulation options which omits the SRH that is not needed = as it would
    > >> have no entries.=C2=A0 This the packet contains a normal IPv6= header, with a
    > >> sequence of compressed SIDs (what one might or might not call= a source
    >
    > >> route) in the IPv6 destination address field.
    > >>
    > >> PPS: If the authors of the NEXT-C-SID flavor feel I have mis-= represented
    > >> the work, please, send clarifications or corrections.=C2=A0 = =C2=A0Again, the best
    > >> source of information is the draft itself.=C2=A0 I was asked = to provide extra
    > >> context in this email.
    > >
    > > -----------------------------------------------------------------= ---
    > > IETF IPv6 working group mailing list
    > > ipv6@ietf.org
    > > Administrative Requests: https://www.= ietf.org/mailman/listinfo/ipv6
    > > -----------------------------------------------------------------= ---
    > >
    >
    > -------------------------------------------------------------------- > IETF IPv6 working group mailing list
    > = ipv6@ietf.org
    > Administrative Requests: https://www.ietf.= org/mailman/listinfo/ipv6
    > --------------------------------------------------------------------
    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@= ietf.org
    Administrative Requests: https://www.ietf.org/m= ailman/listinfo/ipv6
    --------------------------------------------------------------------
    --00000000000057686f05ceb6ca9a-- From nobody Tue Oct 19 14:37:42 2021 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 9B59F3A0F41; Tue, 19 Oct 2021 14:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.1 X-Spam-Level: X-Spam-Status: No, score=-1.1 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, FREEMAIL_REPLY=1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 WgzCYo11qcw0; Tue, 19 Oct 2021 14:37:04 -0700 (PDT) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 E322C3A0E5B; Tue, 19 Oct 2021 14:37:02 -0700 (PDT) Received: by mail-pf1-x42e.google.com with SMTP id y7so1113467pfg.8; Tue, 19 Oct 2021 14:37:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2g+QaNiB/+ts0UFICFtr7y8XbsoGFMUdD7n8nZL85N0=; b=kPCNS2gG3hske2AKUIC8o2xa5r0H0XwPqRPe7/KKaXZPJ+zCQHzsU7xmu2mrlr61CZ 0dHsdqqHK9RigJQiUyCLtLw4FJ/+6gnNjWmAGv7bIftaFMBg/gxnEqcLuvuRic4/aswW qtMmzS7lrgIS+IT+Q15L/wzKYWxzM/5QeuAhlGWhwWldIL1+4YodVLsE7kiZv//sUH9v P40tMTOSIIOc2IqMnyTiCuGe+0+BWAln3/XTKUdy+PwMZwVWeKLUjVC5ApQq5sQqYsGu P+9zUyvSXU4gPpVo6m2uglEiXdbS68EAjZUV43uzIpZ1IlyCVSaMy5GbMADQ5bSsr+78 7hBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2g+QaNiB/+ts0UFICFtr7y8XbsoGFMUdD7n8nZL85N0=; b=zlJCf4DzMnp/IH19Unkn+woKidSSC9jGqVLnHIvmzSpjfH1sgL4fEQZ312mQ1w6sGq 1VMjlumNkUoJsz6sx4bhJZEt5ytriRijwdla0DD4f2++E46FpLXHnPaEYySI0bOUcLsj ZZ6tKIXodg2NtHHZz8mnU5nElKN0ZOI8CBOasKPjr6PBwTRcuPqLSHooQ9Oq4EByAtT4 JI2R9/eaMMBl0PEpHw1TLD/zYwYU21yFKiG2eA7CSQ+n2Cg7ISOX3kb3zpBWc2VcKux7 ZmXk9u+JoyQIW+J2qdWLTDe47zvmN8AyQjBhGCL/5fR/mAD/upCeDa72MVIAvxEiaKyI TEsw== X-Gm-Message-State: AOAM532sz+fSipcD7OvXeBm7oY7+ufe7ctbEfo0h3cFiTJhiUuLv3pd6 sElQB1gbj+bcFBGkkg5epUpJzX/t493fLQ== X-Google-Smtp-Source: ABdhPJyWfJbjVfqdh7JLFxSn07N6RwH++Nxk2QkfqDT3E96MLOET7r4LST3ciUrqDsX0F/ELMZWAIA== X-Received: by 2002:a63:bf07:: with SMTP id v7mr30541872pgf.475.1634679420939; Tue, 19 Oct 2021 14:37:00 -0700 (PDT) Received: from ?IPv6:2406:e003:102d:e801:db7:d041:a2d:ce65? ([2406:e003:102d:e801:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id i8sm169491pfo.117.2021.10.19.14.36.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 19 Oct 2021 14:37:00 -0700 (PDT) To: Tom Herbert , Mark Smith Cc: SPRING WG , 6man References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <26d9fc32-4884-602c-975a-79fc64551727@gmail.com> From: Brian E Carpenter Message-ID: Date: Wed, 20 Oct 2021 10:13:51 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 19 Oct 2021 21:37:18 -0000 On 20-Oct-21 05:02, Tom Herbert wrote: >=20 >=20 > On Tue, Oct 19, 2021, 12:10 AM Mark Smith > wrote: >=20 > Hi Brian, >=20 > On Tue, 19 Oct 2021 at 15:51, Brian E Carpenter > > = wrote: > > > > Hi, > > > > After reading a lot of messages, I'm going to offer my considered= > > opinion as a direct response to Joel's OP. > > > > Firstly, I don't believe that in the end this draft raises any > > concerns that are *significantly* different than those raised > > when RFC 8986 was in draft. As Ted Hardie mentioned, section 5 > > of RFC 8754 explains that SIDs of any shape or size are only > > meaningful within an SR domain. That applies to srh-compression > > too. > > > > Secondly, I was concerned about how these strange looking > > "addresses" would potentially interfere with normal IPv6 > > addresses and their handling by normal IPv6 nodes. Well, I > > now believe that they won't. The reason is that in the SR model > > these "addresses" are *never used for final delivery of IPv6 > > packets to a host.* All SRv6 participants are routers. The > > last hop for a packet whose DA is set to (say) 2001:db8:a:1900:: > > is *not* the last hop on a LAN, mediated by neighbor discovery > > for 2001:db8:a:1900::. It's just a hop from one router to another= , > > using the entry for 2001:db8:a:1900::/64 in the FIB of the last > > router that actually forwards the packet. 2001:db8:a:1900:: is > > not assigned to a physical interface so RFC 4861 is never invoked= =2E > > >=20 > So I'm guessing you're probably thinking of a router as a physical > device (as most of us will by default), rather than as routing as a= > function. >=20 > RFC8200 definitions: >=20 > "router=C2=A0 =C2=A0 =C2=A0 =C2=A0a node that forwards IPv6 packets=20 not explicitly > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 addressed t= o itself.=C2=A0 (See Note below.) >=20 > =C2=A0 =C2=A0host=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0any node that is=20 not a router.=C2=A0 (See Note below.)" > (the note is about hosts having multiple interfaces) >=20 > (A node doesn't have to be a device, and a device doesn't have to b= e > physical, so the above are really function descriptions.) >=20 > If a router as a physical device has IPv6 addresses that are sent t= o > the device itself, then the router as a physical device is also > performing host functions. For packets with those "router addresses= ", > the router as a physical device is not "forward[ing] IPv6 packets n= ot > explicitly addressed to itself. " >=20 > In a router as a physical device, the forwarding plane is performin= g > the router function above. In a router as a physical device, the > "control plane" (really just a fancy name for a host) is performing= > host functions on packets that are directly to and from it (BGP, OS= PF, > SSH, SNMP etc. packets). >=20 > The consequence is that all IPv6 addresses are host addresses, and = all > processing of packets at the device that holds a packet's DA is hos= t > processing of the packet. >=20 > It is the same in IPv4=C2=A0 - from RFC791, "The internet protocol = provides > for transmitting blocks of data called datagrams from sources to > destinations, where sources and destinations are hosts identified b= y > fixed length addresses." >=20 > So these packets with CSID rotating IPv6 DAs are being host process= ed > by the router (as a device), after the forwarding plane in the rout= er > (as a device) has forwarded the packet to the colocated host functi= on. >=20 > (A more practical example to support the above observation. If a > router as a device is bought from a router vendor, and then is run = as > a BGP route reflector, meaning it is never in a packet forwarding > path, and therefore never "forwards IPv6 packets not explicitly > addressed to itself" is the router device still a router? Functiona= lly > no, it is a host, even though it looks like a router (as a device).= ) >=20 >=20 > Mark, >=20 > On the other hand, when a node is processing a routing it header it doe= s forward packets addressed to it self (but not being the final destinati= on). Processing a router header is intuitively router functionality and n= ot host functionality. The RFC8200 definition of host and router don't se= em to consider routing headers, perhaps this should be amended to say tha= t a host is the final destination of the packet. That is the case even if the host is also a router and if it recognises t= he DA of a packet delivered to it in its role as a router as a DA that it=20 handles in its role as a host. (In Linux jargon, that means "if the DA is=20 assigned to its loopback interface", but that is an implementation detail= =2E) The point here is that the *previous* router doesn't know that the DA is = assigned that way; it just forwards the packet to whoever announced the l= ongest-matching prefix. It *does not* send the packet to DA. Brian >=20 > Tom >=20 >=20 > Regards, > Mark. >=20 > > Another way to say it is RFC 7608 is the relevant architectural > > standard. CIDR rules, even within an SR domain. > > > > For that reason, the fact that the bottom 64 bits in the > > "address" look funny or change is simply irrelevant. They are > > invisible to routing (which is done based on the prefix) > > and invisible to neighbor discovery (because it never happens). > > > > I apologise if this is all obvious to everybody, but I needed > > to spell it out for my own understanding. > > > > Now back to Joel's questions: > > > > > > On 13-Oct-21 20:37, Joel M. Halpern wrote: > > > There is a typo in the below which if not understood as a typo = would be > > > > > quite confusing.=C2=A0 =C2=A0I wrote that I raised the issue wi= th > > > "with the Internet ADs and SPRING chairs". > > > That should have read "with the Internet ADs and 6man chairs". > > > The SPRING co-chairs are recused, and the charter requirement l= eads to > > > the 6man chairs.=C2=A0 Which is who I talked to. > > > > > > Also, I am sending a courtesy copy to the routing ADs, which I = should > > > have done originally. > > > > > > Thank you and enjoy. > > > Yours, > > > Joel > > > > > > On 10/12/2021 11:52 PM, Joel M. Halpern wrote: > > >> The SPRING working group is in the midst of an adoption call o= n > > >> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-sr= v6-srh-compression/ . > > >> > > >> > > >> The SPRING charter has text that is explicit that modification= s to data > > >> planes and architectures standardized by other working groups = may not be > > >> modified in SPRING unless the chairs and ADs responsible for t= hat data > > > > >> plane and / or architecture agree. > > >> > > >> To complete the context, as my SPRING co-chairs are co-authors=20 on the > > >> document in question, they have recused themselves from decisi= onal > > >> activities regarding the document.=C2=A0 Therefore, this messa= ge is coming > > >> just from my as the responsible SPRING co-chair managing this = adoption > > > > >> call. > > >> > > >> As you have seen, multiple questions have been raised about th= e > > >> relationship of the document to the IPv6 defined data plane an= d > > >> architecture (particularly RFC 4291 and 8200). In particular t= he > > >> questions seem to revolve around what the document describes a= s the > > >> NEXT-C-SID flavor of compressed SID, and its relationship to t= he IPv6 > > >> standards.=C2=A0 (For those seeking more context without readi= ng the full > > >> document, a paraphrase and simplification of the NEXT-C_SID fl= avor is > > >> provided as a postscript.) > > >> > > >> I raised the question of concurrence as required by the SPRING=20 charter > > > > >> with the Internet ADs and SPRING chairs.=C2=A0 They quite reas= onably asked me > > >> to write a note to 6man explaining the concerns as clearly as = a can, so > > >> that they can then determine how to proceed. > > >> > > >> The questions that prompted my inquiry are: > > >> > > >> 1) Does the placement of a list of sids in the IPv6 DA field c= hange the > > >> IPv6 architectural description of that field. > > > > I think it should be noted explicitly somewhere that since the co= ntents > > of the DA field are *never* used for last-hop neighbor discovery,= > > the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942= > > are irrelevant. Another citation is RFC 7608: for routing, all th= at > > counts is the prefix, and it can be anything up to 128. > > > > Perhaps this should have been in section 5 of RFC 8754, but I lea= ve > > that to the wordsmiths. > > > > >> 2) Does the operation of shifting information around in the IP= v6 > > >> destination address field represent a modification or extensio= n of the > > > > >> IPv6 data plane. > > > > No. As my text above indicates, the SRv6 DA field is only ever us= ed > > by routing, where RFC 7608 rules. And of course it vanishes as so= on > > as the packet is decapsulated. > > > > Regards > >=C2=A0 =C2=A0 =C2=A0Brian > > > > >> > > >> On a related note, the document in question also defines two o= ther > > >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.=C2=A0 The > > >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C= _SID > > >> flavor operation, so seems to be affected by the same question= =2E > > >> > > >>=C2=A0 From my own reading, it appears that the REPLACE-C-SID f= lavor does not > > >> raise issues requiring 6man leadership concurrence. > > >> > > >> Yours, > > >> Joel M. Halpern for the SPRING working group > > >> > > >> > > >> PS: > > >> Clearly, understanding the question requires some understandin= g of what > > >> the NEXT-C_SID flavor does.=C2=A0 =C2=A0This explanation is a = simplification for > > >> length and context.=C2=A0 Really, the best place to understand=20 it is the > > >> draft.=C2=A0 However, to give you enough information to let yo= u decide > > > > >> whether you care, I will try to provide a fair summary.=C2=A0 = My apologies in > > >> advance to the authors for necessary liberties for length.=C2=A0=20 Also, > > > > >> discussion of the draft contents (as distinct from the interac= tion with > > >> the IPv6 data plane and architecture) belongs on the SPRING li= st, and > > >> should not clutter up 6man. > > >> > > >> SIDs are the identifiers used in segment routing. > > >> In SRv6, as document in the current RFCs, these are 128 bits.=C2= =A0 =C2=A0As > > >> defined in the relevant RFCs, SIDs which identify endpoints to=20 which > > >> packets are directed are identified by endpoint SIDs.=C2=A0 Th= ese can have > > >> behaviors (decapsulate and forward is one example).=C2=A0 They=20 can have > > >> flavors such as where the SRH is removed. > > >> > > >> The topic under discussion is means to compress these SIDs in = the > > >> packets on the wire.=C2=A0 The document under discussion provi= des three > > >> flavors of compression. > > >> > > >> The fundamental mechanism of the draft is to use a single SRH = entry as > > a > > >> container for multiple SIDs.=C2=A0 In the NEXT-C_SID mechanism= , when it is > > >> first encountered the entire container is copied into the desi= nation > > >> address of the IPv6 packet.=C2=A0 The container has a common r= outing prefix > > >> used for all the NEXT-C-SID SIDs.=C2=A0 It is followed by a se= quence of > > >> compressed SIDs of a configured length.=C2=A0 One could config= ure 16, 24, or > > >> 32 bits.=C2=A0 Or whatever length.=C2=A0 The routing advertise= ments are arranged > > >> so that the IPv6 packet is directed to the node represented by=20 the first > > >> compressed SID on the basis of longest prefix match matching t= he > > >> combination of the common routing prefix and that compressed S= ID. > > >> > > >> When the packet arrives at that node, it looks up the configur= ed > > >> portion, the compressed SID, and determines the behavior and f= lavor.=C2=A0 In > > >> the case of the NEXT-C-SID flavor, the resulting operation is = to shift > > > > >> the entire remaining contents of the IPv6 address (the bits pa= st the > > >> first compressed sid) so as to over-write the first compressed=20 SID.=C2=A0 0 > > >> bits are shifted into the low order positions.=C2=A0 If the re= sult is a > > >> non-zero new first compressed SID, then the packets is forward= ed and the > > >> process repeats.=C2=A0 When all that is left are 0s, if there = is an SRH, it > > >> is consulted to find the next SRH entry, which is, per normal = SRv6 > > >> processing, put into the IPv6 DA. > > >> Note that in the common case where the SIDS needed all fit in = to a > > >> single container, the analysis also assumes the use of the red= uced > > >> encapsulation options which omits the SRH that is not needed a= s it would > > >> have no entries.=C2=A0 This the packet contains a normal IPv6 = header, with a > > >> sequence of compressed SIDs (what one might or might not call = a source > > > > >> route) in the IPv6 destination address field. > > >> > > >> PPS: If the authors of the NEXT-C-SID flavor feel I have mis-r= epresented > > >> the work, please, send clarifications or corrections.=C2=A0 =C2= =A0Again, the best > > >> source of information is the draft itself.=C2=A0 I was asked t= o provide extra > > >> context in this email. > > > > > > ---------------------------------------------------------------= ----- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: https://www.ietf.org/mailman/listinfo/= ipv6 > > > ---------------------------------------------------------------= ----- > > > > > > > -----------------------------------------------------------------= --- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ip= v6 > > -----------------------------------------------------------------= --- >=20 > -------------------------------------------------------------------= - > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6=20 > -------------------------------------------------------------------= - >=20 From nobody Wed Oct 20 07:22:13 2021 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 826733A094D for ; Wed, 20 Oct 2021 07:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-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 BXZiroH04fgK for ; Wed, 20 Oct 2021 07:22:05 -0700 (PDT) Received: from caict.ac.cn (mail.caict.ac.cn [106.38.3.229]) by ietfa.amsl.com (Postfix) with ESMTP id 416533A0898 for ; Wed, 20 Oct 2021 07:22:03 -0700 (PDT) Received: from smtpclient.apple (unknown [123.115.181.237]) by app1 (Coremail) with SMTP id H0IICgB3f1cAJnBhX54OAA--.13413S2; Wed, 20 Oct 2021 22:21:52 +0800 (CST) From: TIAN Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_45677CAA-5598-458C-A2F6-47DAB2C30E8F" X-Priority: 3 Date: Wed, 20 Oct 2021 22:21:52 +0800 References: <43b9b090.5b4b.17c97fae2ad.Coremail.qogir73@163.com> To: spring@ietf.org In-Reply-To: <43b9b090.5b4b.17c97fae2ad.Coremail.qogir73@163.com> Message-Id: <44AA3FA2-6ED2-415C-8704-7B9F0EDDA590@caict.ac.cn> X-Mailer: Apple Mail (2.3654.100.0.2.22) X-CM-TRANSID: H0IICgB3f1cAJnBhX54OAA--.13413S2 X-Coremail-Antispam: 1UD129KBjvJXoWxXF13Xr45Kr1DWFyDAr17Awb_yoW5uryrpa yUKry7Crn5Ary8Cw4rAr18try8CrWrGrWUJ3W5Kr1UAa45GF18Kr13tw4YvayUGr1fJayY qrsruw1DXw4YvFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUBmb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_JFI_Gr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW0oVCq3wA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_GcCE3s1le2I262IYc4CY6c8Ij28IcVAaY2xG8wAqx4xG67k08I80 eVW8JVW5JwAqx4xG64kEw2xG04xIwI0_Jr0_Gr1l5I8CrVC2j2CE0s8v4I0Ex7kE8s4lYx 0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14v26r1j6r4UMcvjeVCFs4IE7xkEbVWU JVW8JwACjcxG0xvY0x0EwIxGrwCjr7xvwVCIw2I0I7xG6c02F41lc2xSY4AK67AK6ry5Mx AIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrVAFwI0_JrI_ JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUJVWUXwCIc40Y0x0EwI xGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8 JwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Jr0_Gr1lIxAIcV C2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxU7iL0UUUUU X-CM-SenderInfo: hwld0x1xl6utxlfwhtffof0/ Archived-At: Subject: Re: [spring] WG Adoption call - draft-srcompdt-spring-compression-requirement - draft-srcompdt-spring-compression-analysis 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, 20 Oct 2021 14:22:11 -0000 --Apple-Mail=_45677CAA-5598-458C-A2F6-47DAB2C30E8F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi WG=EF=BC=8C =20 After a long-term discussion in the WG, we have reached this point today I support the adoption of CSID draft, which describes an efficient = solution of SRv6 compression. I understand the document defines several Flavors, and I think it is = just like the normal flavors defined in RFC8986, like PSP, USP, so it = makes sense to me. Again, thanks to chairs and design team. =20 Best regards, TIAN >=20 > ---- Forwarded Message ---- > From bruno.decraene = > Date 09/07/2021 21:12 > To spring@ietf.org > Subject [spring] WG Adoption call - = draft-srcompdt-spring-compression-requirement - = draft-srcompdt-spring-compression-analysis > Dear WG, > =20 > =20 > The Design Team has produced two documents: > - A requirement document: = draft-srcompdt-spring-compression-requirement > - A solution analysis document: = draft-srcompdt-spring-compression-analysis > =20 > Both have been presented to the WG and triggered some discussions but = are still individual documents. > We believe it's now time for the WG to consider taking ownership of = those two documents. > Note that, especially for those two documents, WG adoption does not = necessarily mean RFC publication in particular if it turns out that the = benefit of long term archive would not justify the WG and IESG effort to = finalize those two documents. > =20 > =20 > This message starts a 2 week WG adoption call, ending September 20th = 2021, for: > = https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-re= quirement = > = https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-an= alysis = > =20 > =20 > After review of the document(s) please indicate support (or not) for = WG adoption of the document(s) to the mailing list. > Please also provide comments/reasons for your support (or lack = thereof) as this is a stronger way to indicate your (non) support as = this is not a vote. > =20 > If you are willing to work on the document(s), please state this = explicitly. This gives the chairs an indication of the energy level of = people in the working group willing to work on the document. > =20 > Thanks! > =20 > Jim, Bruno & Joel > =20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles 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 electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information 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 = 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. >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring = --Apple-Mail=_45677CAA-5598-458C-A2F6-47DAB2C30E8F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    Hi = WG=EF=BC=8C
     
    After a = long-term discussion in the WG, we have reached this point = today
    I support the adoption of = CSID draft, which describes an efficient solution of SRv6 = compression.
    I = understand the document defines several Flavors, and I think it is just = like the normal flavors defined in RFC8986, like PSP, USP, so it makes = sense to me.
    Again, = thanks to chairs and design team.
     
    Best = regards,
    TIAN




    ---- Forwarded Message ----
    Dear WG,
     
     
    The Design Team has produced two = documents:
    - A requirement document: draft-srcompdt-spring-compression-requirement
    - A solution analysis document: draft-srcompdt-spring-compression-analysis
     
    Both have been = presented to the WG and triggered some discussions but are still = individual documents.
    We believe it's now = time for the WG to consider taking ownership of those two documents.
    Note that, especially for those two documents, = WG adoption does not necessarily mean RFC publication in particular if = it turns out that the benefit of long term archive would not justify the = WG and IESG effort to finalize those two documents.
     
     
    This message starts a 2 week WG adoption = call, ending September  20th 2021, for:
    https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-com= pression-requirement
    https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-com= pression-analysis
     
     
    After review of the document(s) please = indicate support (or not) for WG adoption of the document(s) to the = mailing list.
    Please also provide comments/reasons for = your support (or lack thereof) as this is a stronger way to indicate = your (non) support as this is not a vote.
     
    If you are willing to = work on the document(s), please state this explicitly. This gives the = chairs an indication of the energy level of people in the working group = willing to work on the document.
     
    Thanks!
     
    Jim, Bruno & Joel
     
    _______________________________________________________________=
__________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations =
confidentielles 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 =
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 confidential or privileged =
information 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 =
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.

    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://www.ietf.org/mailman/listinfo/spring
    = --Apple-Mail=_45677CAA-5598-458C-A2F6-47DAB2C30E8F-- From nobody Wed Oct 20 13:16:50 2021 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 4B3963A0EB6; Wed, 20 Oct 2021 13:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 KCKMDbn31M14; Wed, 20 Oct 2021 13:13:52 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 0D1603A0EAF; Wed, 20 Oct 2021 13:13:52 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id i20so714286edj.10; Wed, 20 Oct 2021 13:13:51 -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=twwDStt8jAMT8eEKpPU0d7ML2ujikZkn347oFFhIqM8=; b=di1F0LLVPj4H7M4tI5igRKO9ja0HCx4kcGliFmqBrDunjJQapoifzFUnUyURfHJWDF xkVRCXoeAqhrquZUhiwJifpmRSX8PtEnQtkcSwY9vu8aapmnuFs3M9XPiDay35TkpaFM vwpUbxTDCi7YSPQStv+S6KT01X84HbBTpq5A1H4wKOlWeFVodCWmYP1Y5SkiZ+2+yshT ZOCcUs7OZft/CuCsSWIFsBVqMMl8+JHSYfBdTeTRbGjXgbHYP0o7YzcXkfT0XFFQb3Mt g0NC/2gAlwjfmh+8/qX10z7xtL+aAM2AEl1xhrcIIBJTjDddLRwParqW/sRQObK5DVUz y1kQ== 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=twwDStt8jAMT8eEKpPU0d7ML2ujikZkn347oFFhIqM8=; b=y2iLeJBoxlF7EDl88uW8e6rJ+yb72LeE3yiCJCn/1RrhOyvULLhz5kZxnMUs0ejoW6 XRQ5w+5lbyGSzuHkjmLbzCOXVtftm3F5uQEm8SJzCZf4bgccBmUza92StVXSrmAjXnwJ UW4c0BFh3cAnju/dEf4cFJj20UO7aIMd4nzULgJcQECRxJOosepczEhsibs3e2quj6x8 2GquVmfqGY5wleDB1LaET59xPmDIYfdkx2iMa/KpinYe3uGMXlwJ3IjUfTKL2TOPnDxL snuc4MMYH8KV3F8IZSEKT6F1dTAEvD2aBGcN76VClrrj8AvXPqAJsYGdQJ43jdmNa6AM kTmg== X-Gm-Message-State: AOAM532AcfOAD8l4yna49OghZj5IGDgJibGnXbAn0HDFyAnvHthyKsD+ r99pCiQR9x13oZvswDRTiJhNEtu7wR/PyoAIQ9NVm2za7OE= X-Google-Smtp-Source: ABdhPJzdBtllZ49Ht4KO/zGWH7YY0/qMlPWrHlIcRN2cpAxXXuJNZYa1ZlytLjXj1PZCqrsnqN+a5UBiP0TUvv7XuDM= X-Received: by 2002:a05:6402:4248:: with SMTP id g8mr1478545edb.126.1634760825077; Wed, 20 Oct 2021 13:13:45 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <26d9fc32-4884-602c-975a-79fc64551727@gmail.com> In-Reply-To: <26d9fc32-4884-602c-975a-79fc64551727@gmail.com> From: Greg Mirsky Date: Wed, 20 Oct 2021 13:13:33 -0700 Message-ID: To: Brian E Carpenter Cc: "Joel M. Halpern" , "ipv6@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="00000000000045832305cece6a53" Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 20 Oct 2021 20:14:08 -0000 --00000000000045832305cece6a53 Content-Type: text/plain; charset="UTF-8" Hi Brian, I've got some questions about what you've said: For that reason, the fact that the bottom 64 bits in the "address" look funny or change is simply irrelevant. They are invisible to routing (which is done based on the prefix) and invisible to neighbor discovery (because it never happens). As I understand it, what you describe is the case of a strict explicit path defined using one of the C-SID compression methods. But I am not sure that your conclusion also always applies when it is a loose explicit path specified in the compressed Segment List. As all C-SIDs share the same prefix, how routing can be done based only on that prefix and not using a part of that "funny" bottom 64 bits? And if any part of the bottom 64 bits must be used, how one can guarantee that CIDR still works in that domain? Regards, Greg On Mon, Oct 18, 2021 at 9:50 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Hi, > > After reading a lot of messages, I'm going to offer my considered > opinion as a direct response to Joel's OP. > > Firstly, I don't believe that in the end this draft raises any > concerns that are *significantly* different than those raised > when RFC 8986 was in draft. As Ted Hardie mentioned, section 5 > of RFC 8754 explains that SIDs of any shape or size are only > meaningful within an SR domain. That applies to srh-compression > too. > > Secondly, I was concerned about how these strange looking > "addresses" would potentially interfere with normal IPv6 > addresses and their handling by normal IPv6 nodes. Well, I > now believe that they won't. The reason is that in the SR model > these "addresses" are *never used for final delivery of IPv6 > packets to a host.* All SRv6 participants are routers. The > last hop for a packet whose DA is set to (say) 2001:db8:a:1900:: > is *not* the last hop on a LAN, mediated by neighbor discovery > for 2001:db8:a:1900::. It's just a hop from one router to another, > using the entry for 2001:db8:a:1900::/64 in the FIB of the last > router that actually forwards the packet. 2001:db8:a:1900:: is > not assigned to a physical interface so RFC 4861 is never invoked. > > Another way to say it is RFC 7608 is the relevant architectural > standard. CIDR rules, even within an SR domain. > > For that reason, the fact that the bottom 64 bits in the > "address" look funny or change is simply irrelevant. They are > invisible to routing (which is done based on the prefix) > and invisible to neighbor discovery (because it never happens). > > I apologise if this is all obvious to everybody, but I needed > to spell it out for my own understanding. > > Now back to Joel's questions: > > > On 13-Oct-21 20:37, Joel M. Halpern wrote: > > There is a typo in the below which if not understood as a typo would be > > > quite confusing. I wrote that I raised the issue with > > "with the Internet ADs and SPRING chairs". > > That should have read "with the Internet ADs and 6man chairs". > > The SPRING co-chairs are recused, and the charter requirement leads to > > the 6man chairs. Which is who I talked to. > > > > Also, I am sending a courtesy copy to the routing ADs, which I should > > have done originally. > > > > Thank you and enjoy. > > Yours, > > Joel > > > > On 10/12/2021 11:52 PM, Joel M. Halpern wrote: > >> The SPRING working group is in the midst of an adoption call on > >> > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/. > > >> > >> > >> The SPRING charter has text that is explicit that modifications to data > >> planes and architectures standardized by other working groups may not > be > >> modified in SPRING unless the chairs and ADs responsible for that data > > >> plane and / or architecture agree. > >> > >> To complete the context, as my SPRING co-chairs are co-authors on the > >> document in question, they have recused themselves from decisional > >> activities regarding the document. Therefore, this message is coming > >> just from my as the responsible SPRING co-chair managing this adoption > > >> call. > >> > >> As you have seen, multiple questions have been raised about the > >> relationship of the document to the IPv6 defined data plane and > >> architecture (particularly RFC 4291 and 8200). In particular the > >> questions seem to revolve around what the document describes as the > >> NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6 > >> standards. (For those seeking more context without reading the full > >> document, a paraphrase and simplification of the NEXT-C_SID flavor is > >> provided as a postscript.) > >> > >> I raised the question of concurrence as required by the SPRING charter > > >> with the Internet ADs and SPRING chairs. They quite reasonably asked > me > >> to write a note to 6man explaining the concerns as clearly as a can, so > >> that they can then determine how to proceed. > >> > >> The questions that prompted my inquiry are: > >> > >> 1) Does the placement of a list of sids in the IPv6 DA field change the > >> IPv6 architectural description of that field. > > I think it should be noted explicitly somewhere that since the contents > of the DA field are *never* used for last-hop neighbor discovery, > the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942 > are irrelevant. Another citation is RFC 7608: for routing, all that > counts is the prefix, and it can be anything up to 128. > > Perhaps this should have been in section 5 of RFC 8754, but I leave > that to the wordsmiths. > > >> 2) Does the operation of shifting information around in the IPv6 > >> destination address field represent a modification or extension of the > > >> IPv6 data plane. > > No. As my text above indicates, the SRv6 DA field is only ever used > by routing, where RFC 7608 rules. And of course it vanishes as soon > as the packet is decapsulated. > > Regards > Brian > > >> > >> On a related note, the document in question also defines two other > >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The > >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID > >> flavor operation, so seems to be affected by the same question. > >> > >> From my own reading, it appears that the REPLACE-C-SID flavor does not > >> raise issues requiring 6man leadership concurrence. > >> > >> Yours, > >> Joel M. Halpern for the SPRING working group > >> > >> > >> PS: > >> Clearly, understanding the question requires some understanding of what > >> the NEXT-C_SID flavor does. This explanation is a simplification for > >> length and context. Really, the best place to understand it is the > >> draft. However, to give you enough information to let you decide > > >> whether you care, I will try to provide a fair summary. My apologies > in > >> advance to the authors for necessary liberties for length. Also, > > >> discussion of the draft contents (as distinct from the interaction with > >> the IPv6 data plane and architecture) belongs on the SPRING list, and > >> should not clutter up 6man. > >> > >> SIDs are the identifiers used in segment routing. > >> In SRv6, as document in the current RFCs, these are 128 bits. As > >> defined in the relevant RFCs, SIDs which identify endpoints to which > >> packets are directed are identified by endpoint SIDs. These can have > >> behaviors (decapsulate and forward is one example). They can have > >> flavors such as where the SRH is removed. > >> > >> The topic under discussion is means to compress these SIDs in the > >> packets on the wire. The document under discussion provides three > >> flavors of compression. > >> > >> The fundamental mechanism of the draft is to use a single SRH entry as > a > >> container for multiple SIDs. In the NEXT-C_SID mechanism, when it is > >> first encountered the entire container is copied into the desination > >> address of the IPv6 packet. The container has a common routing prefix > >> used for all the NEXT-C-SID SIDs. It is followed by a sequence of > >> compressed SIDs of a configured length. One could configure 16, 24, or > >> 32 bits. Or whatever length. The routing advertisements are arranged > >> so that the IPv6 packet is directed to the node represented by the > first > >> compressed SID on the basis of longest prefix match matching the > >> combination of the common routing prefix and that compressed SID. > >> > >> When the packet arrives at that node, it looks up the configured > >> portion, the compressed SID, and determines the behavior and flavor. > In > >> the case of the NEXT-C-SID flavor, the resulting operation is to shift > > >> the entire remaining contents of the IPv6 address (the bits past the > >> first compressed sid) so as to over-write the first compressed SID. 0 > >> bits are shifted into the low order positions. If the result is a > >> non-zero new first compressed SID, then the packets is forwarded and > the > >> process repeats. When all that is left are 0s, if there is an SRH, it > >> is consulted to find the next SRH entry, which is, per normal SRv6 > >> processing, put into the IPv6 DA. > >> Note that in the common case where the SIDS needed all fit in to a > >> single container, the analysis also assumes the use of the reduced > >> encapsulation options which omits the SRH that is not needed as it > would > >> have no entries. This the packet contains a normal IPv6 header, with a > >> sequence of compressed SIDs (what one might or might not call a source > > >> route) in the IPv6 destination address field. > >> > >> PPS: If the authors of the NEXT-C-SID flavor feel I have > mis-represented > >> the work, please, send clarifications or corrections. Again, the best > >> source of information is the draft itself. I was asked to provide > extra > >> context in this email. > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --00000000000045832305cece6a53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Brian,
    I've got some questions= about what you've said:
    For that reason, the fact that = the bottom 64 bits in the
    "address"= ; look funny or change is simply irrelevant. They are
    = invisible to routing (which is done based on the prefix)
    and invisible to neighbor discovery (because it never happens).
    As I understand it, what you describe is the case of a stri= ct explicit path defined using one of the C-SID compression methods. But I = am not sure that your conclusion also always applies when it is a loose exp= licit path specified in the compressed Segment List. As all C-SIDs share th= e same prefix, how routing can be done based only on that prefix and not us= ing a part of that "funny" bottom 64 bits? And if any part of the= bottom 64 bits must be used, how one=C2=A0can guarantee that CIDR still wo= rks in that domain?

    Regards,
    Greg
    <= br>
    On Mon,= Oct 18, 2021 at 9:50 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    Hi,

    After reading a lot of messages, I'm going to offer my considered
    opinion as a direct response to Joel's OP.

    Firstly, I don't believe that in the end this draft raises any
    concerns that are *significantly* different than those raised
    when RFC 8986 was in draft. As Ted Hardie mentioned, section 5
    of RFC 8754 explains that SIDs of any shape or size are only
    meaningful within an SR domain. That applies to srh-compression
    too.

    Secondly, I was concerned about how these strange looking
    "addresses" would potentially interfere with normal IPv6
    addresses and their handling by normal IPv6 nodes. Well, I
    now believe that they won't. The reason is that in the SR model
    these "addresses" are *never used for final delivery of IPv6
    packets to a host.* All SRv6 participants are routers. The
    last hop for a packet whose DA is set to (say) 2001:db8:a:1900::
    is *not* the last hop on a LAN, mediated by neighbor discovery
    for 2001:db8:a:1900::. It's just a hop from one router to another,
    using the entry for 2001:db8:a:1900::/64 in the FIB of the last
    router that actually forwards the packet. 2001:db8:a:1900:: is
    not assigned to a physical interface so RFC 4861 is never invoked.

    Another way to say it is RFC 7608 is the relevant architectural
    standard. CIDR rules, even within an SR domain.

    For that reason, the fact that the bottom 64 bits in the
    "address" look funny or change is simply irrelevant. They are
    invisible to routing (which is done based on the prefix)
    and invisible to neighbor discovery (because it never happens).

    I apologise if this is all obvious to everybody, but I needed
    to spell it out for my own understanding.

    Now back to Joel's questions:


    On 13-Oct-21 20:37, Joel M. Halpern wrote:
    > There is a typo in the below which if not understood as a typo would b= e

    > quite confusing.=C2=A0 =C2=A0I wrote that I raised the issue with
    > "with the Internet ADs and SPRING chairs".
    > That should have read "with the Internet ADs and 6man chairs"= ;.
    > The SPRING co-chairs are recused, and the charter requirement leads to=
    > the 6man chairs.=C2=A0 Which is who I talked to.
    >
    > Also, I am sending a courtesy copy to the routing ADs, which I should =
    > have done originally.
    >
    > Thank you and enjoy.
    > Yours,
    > Joel
    >
    > On 10/12/2021 11:52 PM, Joel M. Halpern wrote:
    >> The SPRING working group is in the midst of an adoption call on >> https://da= tatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/= .
    >>
    >>
    >> The SPRING charter has text that is explicit that modifications to= data
    >> planes and architectures standardized by other working groups may = not be
    >> modified in SPRING unless the chairs and ADs responsible for that = data

    >> plane and / or architecture agree.
    >>
    >> To complete the context, as my SPRING co-chairs are co-authors on = the
    >> document in question, they have recused themselves from decisional=
    >> activities regarding the document.=C2=A0 Therefore, this message i= s coming
    >> just from my as the responsible SPRING co-chair managing this adop= tion

    >> call.
    >>
    >> As you have seen, multiple questions have been raised about the >> relationship of the document to the IPv6 defined data plane and >> architecture (particularly RFC 4291 and 8200). In particular the <= br> >> questions seem to revolve around what the document describes as th= e
    >> NEXT-C-SID flavor of compressed SID, and its relationship to the I= Pv6
    >> standards.=C2=A0 (For those seeking more context without reading t= he full
    >> document, a paraphrase and simplification of the NEXT-C_SID flavor= is
    >> provided as a postscript.)
    >>
    >> I raised the question of concurrence as required by the SPRING cha= rter

    >> with the Internet ADs and SPRING chairs.=C2=A0 They quite reasonab= ly asked me
    >> to write a note to 6man explaining the concerns as clearly as a ca= n, so
    >> that they can then determine how to proceed.
    >>
    >> The questions that prompted my inquiry are:
    >>
    >> 1) Does the placement of a list of sids in the IPv6 DA field chang= e the
    >> IPv6 architectural description of that field.

    I think it should be noted explicitly somewhere that since the contents
    of the DA field are *never* used for last-hop neighbor discovery,
    the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942
    are irrelevant. Another citation is RFC 7608: for routing, all that
    counts is the prefix, and it can be anything up to 128.

    Perhaps this should have been in section 5 of RFC 8754, but I leave
    that to the wordsmiths.

    >> 2) Does the operation of shifting information around in the IPv6 <= br> >> destination address field represent a modification or extension of= the

    >> IPv6 data plane.

    No. As my text above indicates, the SRv6 DA field is only ever used
    by routing, where RFC 7608 rules. And of course it vanishes as soon
    as the packet is decapsulated.

    Regards
    =C2=A0 =C2=A0 Brian

    >>
    >> On a related note, the document in question also defines two other=
    >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.=C2=A0 The
    >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID=
    >> flavor operation, so seems to be affected by the same question. >>
    >>=C2=A0 From my own reading, it appears that the REPLACE-C-SID flavo= r does not
    >> raise issues requiring 6man leadership concurrence.
    >>
    >> Yours,
    >> Joel M. Halpern for the SPRING working group
    >>
    >>
    >> PS:
    >> Clearly, understanding the question requires some understanding of= what
    >> the NEXT-C_SID flavor does.=C2=A0=C2=A0 This explanation is a simp= lification for
    >> length and context.=C2=A0 Really, the best place to understand it = is the
    >> draft.=C2=A0 However, to give you enough information to let you de= cide

    >> whether you care, I will try to provide a fair summary.=C2=A0 My a= pologies in
    >> advance to the authors for necessary liberties for length.=C2=A0 A= lso,

    >> discussion of the draft contents (as distinct from the interaction= with
    >> the IPv6 data plane and architecture) belongs on the SPRING list, = and
    >> should not clutter up 6man.
    >>
    >> SIDs are the identifiers used in segment routing.
    >> In SRv6, as document in the current RFCs, these are 128 bits.=C2= =A0=C2=A0 As
    >> defined in the relevant RFCs, SIDs which identify endpoints to whi= ch
    >> packets are directed are identified by endpoint SIDs.=C2=A0 These = can have
    >> behaviors (decapsulate and forward is one example).=C2=A0 They can= have
    >> flavors such as where the SRH is removed.
    >>
    >> The topic under discussion is means to compress these SIDs in the =
    >> packets on the wire.=C2=A0 The document under discussion provides = three
    >> flavors of compression.
    >>
    >> The fundamental mechanism of the draft is to use a single SRH entr= y as
    a
    >> container for multiple SIDs.=C2=A0 In the NEXT-C_SID mechanism, wh= en it is
    >> first encountered the entire container is copied into the desinati= on
    >> address of the IPv6 packet.=C2=A0 The container has a common routi= ng prefix
    >> used for all the NEXT-C-SID SIDs.=C2=A0 It is followed by a sequen= ce of
    >> compressed SIDs of a configured length.=C2=A0 One could configure = 16, 24, or
    >> 32 bits.=C2=A0 Or whatever length.=C2=A0 The routing advertisement= s are arranged
    >> so that the IPv6 packet is directed to the node represented by the= first
    >> compressed SID on the basis of longest prefix match matching the <= br> >> combination of the common routing prefix and that compressed SID.<= br> >>
    >> When the packet arrives at that node, it looks up the configured <= br> >> portion, the compressed SID, and determines the behavior and flavo= r.=C2=A0 In
    >> the case of the NEXT-C-SID flavor, the resulting operation is to s= hift

    >> the entire remaining contents of the IPv6 address (the bits past t= he
    >> first compressed sid) so as to over-write the first compressed SID= .=C2=A0 0
    >> bits are shifted into the low order positions.=C2=A0 If the result= is a
    >> non-zero new first compressed SID, then the packets is forwarded a= nd the
    >> process repeats.=C2=A0 When all that is left are 0s, if there is a= n SRH, it
    >> is consulted to find the next SRH entry, which is, per normal SRv6=
    >> processing, put into the IPv6 DA.
    >> Note that in the common case where the SIDS needed all fit in to a=
    >> single container, the analysis also assumes the use of the reduced=
    >> encapsulation options which omits the SRH that is not needed as it= would
    >> have no entries.=C2=A0 This the packet contains a normal IPv6 head= er, with a
    >> sequence of compressed SIDs (what one might or might not call a so= urce

    >> route) in the IPv6 destination address field.
    >>
    >> PPS: If the authors of the NEXT-C-SID flavor feel I have mis-repre= sented
    >> the work, please, send clarifications or corrections.=C2=A0=C2=A0 = Again, the best
    >> source of information is the draft itself.=C2=A0 I was asked to pr= ovide extra
    >> context in this email.
    >
    > -------------------------------------------------------------------- > IETF IPv6 working group mailing list
    > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman= /listinfo/ipv6
    > -------------------------------------------------------------------- >

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
    --------------------------------------------------------------------
    --00000000000045832305cece6a53-- From nobody Wed Oct 20 18:18:20 2021 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 2EB313A0E19; Wed, 20 Oct 2021 18:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HA_UhZ45HQZR; Wed, 20 Oct 2021 18:18:11 -0700 (PDT) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 94D9F3A0E1F; Wed, 20 Oct 2021 18:18:11 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id q10-20020a17090a1b0a00b001a076a59640so4788054pjq.0; Wed, 20 Oct 2021 18:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=BS7j1biTsSFfguinyRioVyrPvQXdKNgpURx5hZrobqU=; b=VATeH9Zqi/qDRylOidZSXnQeRAsb2RSz+Kd3wftOE5qbhGT1Qi1wHqVLhYJW+a5cJw flssPV3BQNjwMgXgID5l0aEqtejIbAXDHxgj7QikWfFQNg9/S/LIdAy7LxzxhGO1+lh5 jfpQrFDEtO0i2dxGwUahmB0Hc3LOwEwL12f5KjoX29K9WVBYqcLjLVQIdWU+xxW1ZlqX tITtyGfhVzmQJNctSve6gXN+O6uMyGCIV6FXAqUcCDvLBTMb+I1ODB4QIU0EjfaPCutq CrkOSeTgn4AP4QeFIFPFtSoa8kPEs24hoNlLCVoq6BBzZKrZIOi6OlHkKaIkCK7dufTn ryPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=BS7j1biTsSFfguinyRioVyrPvQXdKNgpURx5hZrobqU=; b=7iv5nk8Zy+Rd2LTK9I6yfW6Ig/m+/26UkB52N5RvWPFZKY7bk3G5EX4GupnA88T4xI XbpznOpJg4eN5kr/4FdXQqHC5SqBiy9JS+417WIs53PM7hitrZ3gG1sWw4B6U05Ddyos KdYSIZfsHUVzS/sRYhS4e6xUWrwGWn8DvmBpCFt+0pqE/gG1ZGR0JZ3tpEM5r4LCKlmC czr0KQ6Yf0RzXMM/IzqFbKj96CGdmyEs6mZJPvsO71XBlQieSJsJpsBHbt/sX4ThnpWU laG/QCAV3YQzS+4twVuPjHQ8oX5GnkKP1oQmhZHGzNrNDXPJhgRo0U0quF4fXY/2KSC5 OPWw== X-Gm-Message-State: AOAM530nYXv1waIw9Qq9WvfGiclgjjbbieQP1MucU74bQsMvo404eCJR ehipkDzRhes/+bfv+KRvyOyJy9Mg9x2x+g== X-Google-Smtp-Source: ABdhPJxerXAEX3myeuLLG6YYHs9PhfOTGTozqN4DTRObNRlEJOYaUAANMk7cSSXy2UAD486QOsfNhw== X-Received: by 2002:a17:90b:1e01:: with SMTP id pg1mr2873298pjb.73.1634779089942; Wed, 20 Oct 2021 18:18:09 -0700 (PDT) Received: from ?IPv6:2406:e003:102d:e801:db7:d041:a2d:ce65? ([2406:e003:102d:e801:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id b8sm4176278pfm.65.2021.10.20.18.18.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Oct 2021 18:18:09 -0700 (PDT) To: Greg Mirsky Cc: "Joel M. Halpern" , "ipv6@ietf.org" , "spring@ietf.org" References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <26d9fc32-4884-602c-975a-79fc64551727@gmail.com> From: Brian E Carpenter Message-ID: Date: Thu, 21 Oct 2021 14:18:05 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 21 Oct 2021 01:18:16 -0000 Greg, I would much prefer that one of the SRv6 experts answers that question. Regards Brian On 21-Oct-21 09:13, Greg Mirsky wrote: > Hi Brian, > I've got some questions about what you've said: >=20 > For that reason, the fact that the bottom 64 bits in the >=20 > "address" look funny or change is simply irrelevant. They are > invisible to routing (which is done based on the prefix) > and invisible to neighbor discovery (because it never happens). >=20 > As I understand it, what you describe is the case of a strict explicit = path defined using one of the C-SID compression methods. But I am not sur= e that your conclusion also always applies when it is a loose explicit pa= th specified in the compressed Segment List. As all C-SIDs share the same=20 prefix, how routing can be done based only on that prefix and not using a=20 part of that "funny" bottom 64 bits? And if any part of the bottom 64 bit= s must be used, how one=C2=A0can guarantee that CIDR still works in that = domain? >=20 > Regards, > Greg >=20 > On Mon, Oct 18, 2021 at 9:50 PM Brian E Carpenter > wrote: >=20 > Hi, >=20 > After reading a lot of messages, I'm going to offer my considered > opinion as a direct response to Joel's OP. >=20 > Firstly, I don't believe that in the end this draft raises any > concerns that are *significantly* different than those raised > when RFC 8986 was in draft. As Ted Hardie mentioned, section 5 > of RFC 8754 explains that SIDs of any shape or size are only > meaningful within an SR domain. That applies to srh-compression > too. >=20 > Secondly, I was concerned about how these strange looking > "addresses" would potentially interfere with normal IPv6 > addresses and their handling by normal IPv6 nodes. Well, I > now believe that they won't. The reason is that in the SR model > these "addresses" are *never used for final delivery of IPv6 > packets to a host.* All SRv6 participants are routers. The > last hop for a packet whose DA is set to (say) 2001:db8:a:1900:: > is *not* the last hop on a LAN, mediated by neighbor discovery > for 2001:db8:a:1900::. It's just a hop from one router to another, > using the entry for 2001:db8:a:1900::/64 in the FIB of the last > router that actually forwards the packet. 2001:db8:a:1900:: is > not assigned to a physical interface so RFC 4861 is never invoked. >=20 > Another way to say it is RFC 7608 is the relevant architectural > standard. CIDR rules, even within an SR domain. >=20 > For that reason, the fact that the bottom 64 bits in the > "address" look funny or change is simply irrelevant. They are > invisible to routing (which is done based on the prefix) > and invisible to neighbor discovery (because it never happens). >=20 > I apologise if this is all obvious to everybody, but I needed > to spell it out for my own understanding. >=20 > Now back to Joel's questions: >=20 >=20 > On 13-Oct-21 20:37, Joel M. Halpern wrote: > > There is a typo in the below which if not understood as a typo wo= uld be >=20 > > quite confusing.=C2=A0 =C2=A0I wrote that I raised the issue with= > > "with the Internet ADs and SPRING chairs". > > That should have read "with the Internet ADs and 6man chairs". > > The SPRING co-chairs are recused, and the charter requirement lea= ds to > > the 6man chairs.=C2=A0 Which is who I talked to. > > > > Also, I am sending a courtesy copy to the routing ADs, which I sh= ould > > have done originally. > > > > Thank you and enjoy. > > Yours, > > Joel > > > > On 10/12/2021 11:52 PM, Joel M. Halpern wrote: > >> The SPRING working group is in the midst of an adoption call on > >> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6= -srh-compression/ . > >> > >> > >> The SPRING charter has text that is explicit that modifications = to data > >> planes and architectures standardized by other working groups ma= y not be > >> modified in SPRING unless the chairs and ADs responsible for tha= t data >=20 > >> plane and / or architecture agree. > >> > >> To complete the context, as my SPRING co-chairs are co-authors o= n the > >> document in question, they have recused themselves from decision= al > >> activities regarding the document.=C2=A0 Therefore, this message=20 is coming > >> just from my as the responsible SPRING co-chair managing this ad= option >=20 > >> call. > >> > >> As you have seen, multiple questions have been raised about the > >> relationship of the document to the IPv6 defined data plane and > >> architecture (particularly RFC 4291 and 8200). In particular the= > >> questions seem to revolve around what the document describes as = the > >> NEXT-C-SID flavor of compressed SID, and its relationship to the=20 IPv6 > >> standards.=C2=A0 (For those seeking more context without reading=20 the full > >> document, a paraphrase and simplification of the NEXT-C_SID flav= or is > >> provided as a postscript.) > >> > >> I raised the question of concurrence as required by the SPRING c= harter >=20 > >> with the Internet ADs and SPRING chairs.=C2=A0 They quite reason= ably asked me > >> to write a note to 6man explaining the concerns as clearly as a = can, so > >> that they can then determine how to proceed. > >> > >> The questions that prompted my inquiry are: > >> > >> 1) Does the placement of a list of sids in the IPv6 DA field cha= nge the > >> IPv6 architectural description of that field. >=20 > I think it should be noted explicitly somewhere that since the cont= ents > of the DA field are *never* used for last-hop neighbor discovery, > the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942 > are irrelevant. Another citation is RFC 7608: for routing, all that= > counts is the prefix, and it can be anything up to 128. >=20 > Perhaps this should have been in section 5 of RFC 8754, but I leave= > that to the wordsmiths. >=20 > >> 2) Does the operation of shifting information around in the IPv6= > >> destination address field represent a modification or extension = of the >=20 > >> IPv6 data plane. >=20 > No. As my text above indicates, the SRv6 DA field is only ever used= > by routing, where RFC 7608 rules. And of course it vanishes as soon= > as the packet is decapsulated. >=20 > Regards > =C2=A0 =C2=A0 Brian >=20 > >> > >> On a related note, the document in question also defines two oth= er > >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.=C2=A0 The > >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_S= ID > >> flavor operation, so seems to be affected by the same question. > >> > >>=C2=A0 From my own reading, it appears that the REPLACE-C-SID fla= vor does not > >> raise issues requiring 6man leadership concurrence. > >> > >> Yours, > >> Joel M. Halpern for the SPRING working group > >> > >> > >> PS: > >> Clearly, understanding the question requires some understanding = of what > >> the NEXT-C_SID flavor does.=C2=A0=C2=A0 This explanation is a si= mplification for > >> length and context.=C2=A0 Really, the best place to understand i= t is the > >> draft.=C2=A0 However, to give you enough information to let you = decide >=20 > >> whether you care, I will try to provide a fair summary.=C2=A0 My=20 apologies in > >> advance to the authors for necessary liberties for length.=C2=A0=20 Also, >=20 > >> discussion of the draft contents (as distinct from the interacti= on with > >> the IPv6 data plane and architecture) belongs on the SPRING list= , and > >> should not clutter up 6man. > >> > >> SIDs are the identifiers used in segment routing. > >> In SRv6, as document in the current RFCs, these are 128 bits.=C2= =A0=C2=A0 As > >> defined in the relevant RFCs, SIDs which identify endpoints to w= hich > >> packets are directed are identified by endpoint SIDs.=C2=A0 Thes= e can have > >> behaviors (decapsulate and forward is one example).=C2=A0 They c= an have > >> flavors such as where the SRH is removed. > >> > >> The topic under discussion is means to compress these SIDs in th= e > >> packets on the wire.=C2=A0 The document under discussion provide= s three > >> flavors of compression. > >> > >> The fundamental mechanism of the draft is to use a single SRH en= try as > a > >> container for multiple SIDs.=C2=A0 In the NEXT-C_SID mechanism, = when it is > >> first encountered the entire container is copied into the desina= tion > >> address of the IPv6 packet.=C2=A0 The container has a common rou= ting prefix > >> used for all the NEXT-C-SID SIDs.=C2=A0 It is followed by a sequ= ence of > >> compressed SIDs of a configured length.=C2=A0 One could configur= e 16, 24, or > >> 32 bits.=C2=A0 Or whatever length.=C2=A0 The routing advertiseme= nts are arranged > >> so that the IPv6 packet is directed to the node represented by t= he first > >> compressed SID on the basis of longest prefix match matching the= > >> combination of the common routing prefix and that compressed SID= =2E > >> > >> When the packet arrives at that node, it looks up the configured= > >> portion, the compressed SID, and determines the behavior and fla= vor.=C2=A0 In > >> the case of the NEXT-C-SID flavor, the resulting operation is to=20 shift >=20 > >> the entire remaining contents of the IPv6 address (the bits past=20 the > >> first compressed sid) so as to over-write the first compressed S= ID.=C2=A0 0 > >> bits are shifted into the low order positions.=C2=A0 If the resu= lt is a > >> non-zero new first compressed SID, then the packets is forwarded=20 and the > >> process repeats.=C2=A0 When all that is left are 0s, if there is=20 an SRH, it > >> is consulted to find the next SRH entry, which is, per normal SR= v6 > >> processing, put into the IPv6 DA. > >> Note that in the common case where the SIDS needed all fit in to=20 a > >> single container, the analysis also assumes the use of the reduc= ed > >> encapsulation options which omits the SRH that is not needed as = it would > >> have no entries.=C2=A0 This the packet contains a normal IPv6 he= ader, with a > >> sequence of compressed SIDs (what one might or might not call a = source >=20 > >> route) in the IPv6 destination address field. > >> > >> PPS: If the authors of the NEXT-C-SID flavor feel I have mis-rep= resented > >> the work, please, send clarifications or corrections.=C2=A0=C2=A0=20 Again, the best > >> source of information is the draft itself.=C2=A0 I was asked to = provide extra > >> context in this email. > > > > -----------------------------------------------------------------= --- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ip= v6 > > -----------------------------------------------------------------= --- > > >=20 > -------------------------------------------------------------------= - > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6=20 > -------------------------------------------------------------------= - >=20 From nobody Thu Oct 21 01:49:51 2021 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 936EA3A125F; Thu, 21 Oct 2021 01:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 eVUCjLkDxsff; Thu, 21 Oct 2021 01:49:28 -0700 (PDT) Received: from caict.ac.cn (mail.caict.ac.cn [106.38.3.229]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2403A1316; Thu, 21 Oct 2021 01:49:14 -0700 (PDT) Received: from smtpclient.apple (unknown [114.242.250.120]) by app1 (Coremail) with SMTP id H0IICgAXVHR_KXFhcTkPAA--.13715S2; Thu, 21 Oct 2021 16:49:04 +0800 (CST) From: =?utf-8?B?55Sw6L6J?= Content-Type: multipart/alternative; boundary="Apple-Mail=_2110857E-57D3-4717-A272-107FEF2FEF01" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Thu, 21 Oct 2021 16:49:03 +0800 References: To: James Guichard , SPRING WG , "spring-chairs@ietf.org" In-Reply-To: Message-Id: <3F9B69D8-D385-40A3-AB41-E0AD34E6B0C7@catr.cn> X-Mailer: Apple Mail (2.3654.100.0.2.22) X-CM-TRANSID: H0IICgAXVHR_KXFhcTkPAA--.13715S2 X-Coremail-Antispam: 1UD129KBjvJXoWxXF13Xr48XFyfAryrAFW5ZFb_yoW5WF4kpa 9xGry7GrZ5AF1xGw4fZw4xZr1Iyr1xAFWUAFn8JryUAr98GF18KrWFkwnava47ur1fAayj vrsFkw45Gr4FvrDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9ab7Iv0xC_Zr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Jr0_JF4l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Jr0_Gr1l84ACjcxK6I8E87Iv67AKxVW8JVWxJwA2z4x0Y4vEx4 A2jsIEc7CjxVAFwI0_Gr0_Gr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAYj202 j2C_Xr0_Wr1l5I8CrVAKz4kIr2xC04v26r1j6r4UMcIj6xIIjxv20xvE14v26r1j6r18Mc Ij6I8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41l 7480Y4vEI4kI2Ix0rVAqx4xJMxkIecxEwVAFwVW8ZwCF04k20xvY0x0EwIxGrwCFx2IqxV CFs4IE7xkEbVWUJVW8JwC20s026c02F40E14v26r106r1rMI8I3I0E7480Y4vE14v26r10 6r1rMI8E67AF67kF1VAFwI0_Jrv_JF1lIxkGc2Ij64vIr41lIxAIcVC0I7IYx2IY67AKxV WUJVWUCwCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_Gr1lIxAIcVCF04k26cxKx2IYs7xG 6r1j6r1xMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_Gr UvcSsGvfC2KfnxnUUI43ZEXa7IU8AwIDUUUUU== X-CM-SenderInfo: hwld0x1xl6utxlfwhtffof0/ Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 21 Oct 2021 08:49:33 -0000 --Apple-Mail=_2110857E-57D3-4717-A272-107FEF2FEF01 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi ALL=EF=BC=8C =20 After a long-term discussion in the WG, we have reached this point today I support the adoption of CSID draft, which describes an efficient = solution of SRv6 compression. I understand the document defines several Flavors, and I think it is = just like the normal flavors defined in RFC8986, like PSP, USP, so it = makes sense to me. Again, thanks to chairs and design team. =20 Best regards, TIAN > On Oct 1, 2021, at 22:04, James Guichard = wrote: >=20 > Dear WG: > =20 > The chairs would like to express their appreciation for all the = responses received to our emails with reference to how the working group = wishes to move forward with respect to a solution for SRv6 compression. > =20 > The apparent inclination of the working group is to use = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = as the basis for its compression standardization work. That is = part of what this email attempts to confirm. > =20 > Because of the above the chairs would like to issue a 2-week WG call = for adoption ending October 15th for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = but with some clear guidelines as follows. By expressing = support for adoption of this document you are fully aware of and are = acknowledging that: > =20 > The SPRING working group is adopting a document that has multiple SRv6 = Endpoint behaviors. > The document is a =E2=80=9Cliving=E2=80=9D document; it may change as = it goes through review and analysis by the SPRING working group. > All open discussion points raised on our mailing list MUST be = addressed BEFORE said document is allowed to progress from the working = group to publication. A list of these discussion points will be = documented in the WG document and maintained by the document editor in = conjunction with the chairs. > If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open = issue be added to the document in the above-described open issues = section: > "Given that the working group has said that it wants to standardize = one data plane solution, and given that the document contains multiple = SRv6 EndPoint behaviors that some WG members have stated are multiple = data plane solutions, the working group will address whether this is = valid and coherent with its one data plane solution objective.". > =20 > Please consider the above guidelines as you decide on whether to = support or not this WG adoption. Please express clearly your reasoning = for support/non-support as well as any open discussion points you would = like addressed should the document be adopted into the working group. > =20 > Thanks! > =20 > Jim, Bruno & Joel > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring = --Apple-Mail=_2110857E-57D3-4717-A272-107FEF2FEF01 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    Hi  ALL=EF=BC=8C
     
    After a long-term discussion in the WG, we have reached this = point today
    I support the adoption of = CSID draft, which describes an efficient solution of SRv6 = compression.
    I understand the document defines several Flavors, and I = think it is just like the normal flavors defined in RFC8986, like PSP, = USP, so it makes sense to me.
    Again, thanks to chairs and design team.
     
    Best regards,
    TIAN


    On Oct 1, 2021, at 22:04, James Guichard <james.n.guichard@futurewei.com> wrote:

    Dear WG:
     
    The chairs would like to express their = appreciation for all the responses received to our emails with reference = to how the working group wishes to move forward with respect to a = solution for SRv6 compression.
     
    The apparent inclination of the working group is = to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ as the basis for its = compression standardization work. That is part of what this email = attempts to confirm.
     
    Because of the above the = chairs would like to issue a 2-week WG call for adoption ending October = 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ but with some clear = guidelines as follows. By expressing support for adoption of this = document you are fully aware of and are acknowledging that:
     
    1. The SPRING working group is adopting = a document that has multiple SRv6 Endpoint behaviors.
    2. The document is = a =E2=80=9Cliving=E2=80=9D document; it may change as it goes through = review and analysis by the SPRING working group.
    3. All open = discussion points raised on our mailing list MUST be addressed BEFORE = said document is allowed to progress from the working group to = publication. A list of these discussion points will be documented in the = WG document and maintained by the document editor in conjunction with = the chairs.
    4. If this document is adopted by the working group, the = chairs specify as part of the adoption call that the following text = describing an open issue be added to the document in the above-described = open issues section:
      • "Given that the working group has = said that it wants to standardize one data plane solution, and given = that the document contains multiple SRv6 EndPoint behaviors that some WG = members have stated are multiple data plane solutions, the working group = will address whether this is valid and coherent with its one data plane = solution objective.".
     
    Please consider the above guidelines as you = decide on whether to support or not this WG adoption. Please express = clearly your reasoning for support/non-support as well as any open = discussion points you would like addressed should the document be = adopted into the working group.
     
    Thanks!
     
    Jim, Bruno & Joel
     
     
    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://www.ietf.org/mailman/listinfo/spring

    = --Apple-Mail=_2110857E-57D3-4717-A272-107FEF2FEF01-- From nobody Thu Oct 21 01:51:23 2021 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 9F60B3A126B; Thu, 21 Oct 2021 01:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRAeglE7kXWY; Thu, 21 Oct 2021 01:51:12 -0700 (PDT) Received: from caict.ac.cn (mail.caict.ac.cn [106.38.3.229]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA5E3A1266; Thu, 21 Oct 2021 01:51:09 -0700 (PDT) Received: from smtpclient.apple (unknown [114.242.250.120]) by app1 (Coremail) with SMTP id H0IICgAXH1T2KXFhwzkPAA--.11371S2; Thu, 21 Oct 2021 16:51:04 +0800 (CST) From: TIAN Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4231F6C6-4A9F-4404-A1D1-7F90D8B1991A" Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\)) Date: Thu, 21 Oct 2021 16:51:02 +0800 In-Reply-To: Cc: SPRING WG , "spring-chairs@ietf.org" To: James Guichard References: X-Mailer: Apple Mail (2.3654.100.0.2.22) X-CM-TRANSID: H0IICgAXH1T2KXFhwzkPAA--.11371S2 X-Coremail-Antispam: 1UD129KBjvJXoWxXF13Xr45Wr1DWFWDZFWUJwb_yoW5AFyfpa 9xGry7GrZ5AF1xGw4fZw4xur1Iyr1xAFWUJ3Z8JryUZr98GF18KFWSkwnYva47Cr1fAFWj vrsFkw45Gw4FvrDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9Sb7Iv0xC_Cr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_tr0E3s1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40Eb7x2 x7xS6ryj6rWUMc02F40Ew4AK048IF2xKxVWUJVW8JwAv7VC0I7IYx2IY67AKxVWUGVWUXw Av7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcxkI7VAKI48J Mx8GjcxK6IxK0xIIj40E5I8CrwCY02Avz4vE14v_GFyl42xK82IYc2Ij64vIr41l4I8I3I 0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUGVWUWwC20s026x8GjcxK67AKxVWU GVWUWwC2zVAF1VAY17CE14v26r1Y6r17MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI 0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0 rVWUJVWUCwCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r 4UYxBIdaVFxhVjvjDU0xZFpf9x07j8F4iUUUUU= X-CM-SenderInfo: hwld0x1xl6utxlfwhtffof0/ Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 21 Oct 2021 08:51:19 -0000 --Apple-Mail=_4231F6C6-4A9F-4404-A1D1-7F90D8B1991A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi ALL=EF=BC=8C =20 After a long-term discussion in the WG, we have reached this point today I support the adoption of CSID draft, which describes an efficient = solution of SRv6 compression. I understand the document defines several Flavors, and I think it is = just like the normal flavors defined in RFC8986, like PSP, USP, so it = makes sense to me. Again, thanks to chairs and design team. =20 Best regards, TIAN =E7=94=B0=E8=BE=89 =E4=B8=AD=E5=9B=BD=E4=BF=A1=E6=81=AF=E9=80=9A=E4=BF=A1=E7=A0=94=E7=A9=B6=E9= =99=A2 010-62300052 tianhui@caict.ac.cn =E5=8C=97=E4=BA=AC=E5=B8=82=E6=B5=B7=E6=B7=80=E5=8C=BA=E8=8A=B1=E5=9B=AD=E5= =8C=97=E8=B7=AF52=E5=8F=B73G=E6=A5=BCB=E5=BA=A7 > On Oct 1, 2021, at 22:04, James Guichard = wrote: >=20 > Dear WG: > =20 > The chairs would like to express their appreciation for all the = responses received to our emails with reference to how the working group = wishes to move forward with respect to a solution for SRv6 compression. > =20 > The apparent inclination of the working group is to use = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = as the basis for its compression standardization work. That is = part of what this email attempts to confirm. > =20 > Because of the above the chairs would like to issue a 2-week WG call = for adoption ending October 15th for = https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compr= ession/ = but with some clear guidelines as follows. By expressing = support for adoption of this document you are fully aware of and are = acknowledging that: > =20 > The SPRING working group is adopting a document that has multiple SRv6 = Endpoint behaviors. > The document is a =E2=80=9Cliving=E2=80=9D document; it may change as = it goes through review and analysis by the SPRING working group. > All open discussion points raised on our mailing list MUST be = addressed BEFORE said document is allowed to progress from the working = group to publication. A list of these discussion points will be = documented in the WG document and maintained by the document editor in = conjunction with the chairs. > If this document is adopted by the working group, the chairs specify = as part of the adoption call that the following text describing an open = issue be added to the document in the above-described open issues = section: > "Given that the working group has said that it wants to standardize = one data plane solution, and given that the document contains multiple = SRv6 EndPoint behaviors that some WG members have stated are multiple = data plane solutions, the working group will address whether this is = valid and coherent with its one data plane solution objective.". > =20 > Please consider the above guidelines as you decide on whether to = support or not this WG adoption. Please express clearly your reasoning = for support/non-support as well as any open discussion points you would = like addressed should the document be adopted into the working group. > =20 > Thanks! > =20 > Jim, Bruno & Joel > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring = --Apple-Mail=_4231F6C6-4A9F-4404-A1D1-7F90D8B1991A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    Hi  ALL=EF=BC=8C
     
    After a long-term discussion in the WG, we have reached this = point today
    I support the adoption of = CSID draft, which describes an efficient solution of SRv6 = compression.
    I understand the document defines several Flavors, and I = think it is just like the normal flavors defined in RFC8986, like PSP, = USP, so it makes sense to me.
    Again, thanks to chairs and design team.
     
    Best regards,
    TIAN




    =E7=94=B0=E8=BE=89

    =E4=B8=AD=E5=9B=BD=E4=BF=A1=E6=81=AF=E9=80=9A=E4=BF= =A1=E7=A0=94=E7=A9=B6=E9=99=A2
    010-62300052 tianhui@caict.ac.cn
    =E5=8C=97=E4=BA=AC=E5=B8=82=E6=B5=B7=E6=B7=80=E5=8C=BA=E8=8A=B1=E5=9B= =AD=E5=8C=97=E8=B7=AF52=E5=8F=B73G=E6=A5=BCB=E5=BA=A7

    On Oct 1, 2021, at 22:04, James Guichard <james.n.guichard@futurewei.com> wrote:

    Dear WG:
     
    The chairs would like to express their = appreciation for all the responses received to our emails with reference = to how the working group wishes to move forward with respect to a = solution for SRv6 compression.
     
    The apparent inclination of the working group is = to use https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/ as the basis for its = compression standardization work. That is part of what this email = attempts to confirm.
     
    Because of the above the = chairs would like to issue a 2-week WG call for adoption ending October = 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/but with some clear guidelines as follows. By = expressing support for adoption of this document you are fully aware of = and are acknowledging that:
     
    1. The SPRING working group is adopting = a document that has multiple SRv6 Endpoint behaviors.
    2. The document is = a =E2=80=9Cliving=E2=80=9D document; it may change as it goes through = review and analysis by the SPRING working group.
    3. All open = discussion points raised on our mailing list MUST be addressed BEFORE = said document is allowed to progress from the working group to = publication. A list of these discussion points will be documented in the = WG document and maintained by the document editor in conjunction with = the chairs.
    4. If this document is adopted by the working group, the = chairs specify as part of the adoption call that the following text = describing an open issue be added to the document in the above-described = open issues section:
      • "Given that the working group has = said that it wants to standardize one data plane solution, and given = that the document contains multiple SRv6 EndPoint behaviors that some WG = members have stated are multiple data plane solutions, the working group = will address whether this is valid and coherent with its one data plane = solution objective.".
     
    Please consider the above guidelines as you = decide on whether to support or not this WG adoption. Please express = clearly your reasoning for support/non-support as well as any open = discussion points you would like addressed should the document be = adopted into the working group.
     
    Thanks!
     
    Jim, Bruno & Joel
     
     
    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://www.ietf.org/mailman/listinfo/spring

    = --Apple-Mail=_4231F6C6-4A9F-4404-A1D1-7F90D8B1991A-- From nobody Thu Oct 21 03:03:24 2021 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 70E1E3A14BE; Thu, 21 Oct 2021 03:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 kxaudW5ZuCe6; Thu, 21 Oct 2021 03:02:14 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556723A14C1; Thu, 21 Oct 2021 03:02:12 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from cupcake.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 19LA28U3028195 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Oct 2021 11:02:09 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be cupcake.local To: Stefano Salsano Cc: ipv6@ietf.org, SPRING WG List References: <6865E218-00B1-41F0-9386-7B8F6DB1D776@steffann.nl> <3b9416b4-be73-c1a7-9235-7e832aee1657@foobar.org> From: Nick Hilliard Message-ID: <78937788-5873-b89a-83a0-b93cc51223e9@foobar.org> Date: Thu, 21 Oct 2021 11:02:07 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.49 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 21 Oct 2021 10:02:22 -0000 Hi Stefano, [spring@ re-added to cc:] Stefano Salsano wrote on 20/10/2021 22:36: > I can anticipate that it is possible to use wireshark to dissect CSID > packets, by providing very simple configuration information. This is exactly the problem though - operators will need to manually instruct a dissector how to interpret the packet contents and that defeats the purpose of a debugging tool because the tool is supposed to be able to objectively tell you what's going on, without the operator having to tell it what's going on. In particular, if you're attempt to debug a problem relating to C-SID length, it would be completely useless. For example, how would you dissect the following sequence of compressed SIDs of different lengths? 0x53b7e4f4d23b The short answer is you can't objectively, yet this could be a valid SID argument. There's an opportunity at this point to ensure that whatever compressed SID mechanism is implemented, that it's done in such a way if difference lengths of compressed SIDs are allowed, that the SID length is included in the encoding. If this isn't done, it will create a mess which operations and support people will be stuck with for the lifetime of SRv6. Note that this devalues SRv6 as an infrastructure component. Nick From nobody Thu Oct 21 07:18:53 2021 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 A2C603A16F0; Thu, 21 Oct 2021 07:18:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=KDUR3URl; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=cUByfg6B 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 uGFAkfgiDIbm; Thu, 21 Oct 2021 07:18:35 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BEC43A0FD0; Thu, 21 Oct 2021 07:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27094; q=dns/txt; s=iport; t=1634825915; x=1636035515; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Ihf6rPy7LkqfLXvXnHOFAqGcs12t9mbeH6+Q5fdUVJk=; b=KDUR3URl/G2ef0Yif7MTa+/0Bf935smoDQdulKoIZMrusGjuvYVnKA3G 7Uo0Ey5YG9c0bVbc3lj3S4JFzXsbTYV6Lsxpbwk3gBUecqUA4VzGu9XdI OQGqd3BUyNIMR9wEC0U2fS7bE5dkN4csyUr0eFM0/RpClAvBCkXwNaJIQ c=; X-IPAS-Result: =?us-ascii?q?A0DhAgAzdnFhl5JdJa1QCh4BAQsSDECBTguBITBRflIIN?= =?us-ascii?q?zGIDgOFOYgNA4p0j3+BLhSBEQNUCwEBAQ0BASoBDAoEAQGFAAKCTAIlNgcOA?= =?us-ascii?q?QIEAQEBAQMCAwEBAQEFAQEFAQEBAgEGBBQBAQEBAQEBAYEIhTsIJQ2GQgEBA?= =?us-ascii?q?QECAQEBEC4BASwEBwEECwIBCBIGIAMEByEGCxQDDgIEAQ0FCBqCTwGBflcDD?= =?us-ascii?q?iEBDqBEAYE6AoofeIEzgQGCCAEBBgQEgUpBgn8NC4I1AwaBOoMGhBWBIIVbJ?= =?us-ascii?q?xyBSUSBFAFDgmc+giFCAQEDgSgBBwsBBxwrgyKCLoxIEFsGFxsMGwsECxcWG?= =?us-ascii?q?xQMAjkGGlEBDQQBJQEBLAFEA5FWCQeMQJ8aZwqDMopKjkKGBxSDaotvhkiQf?= =?us-ascii?q?JYNH4xRg0aQJ4UdAgQCBAUCDgEBBoFoBC4tPnBwFTuCaVEZD4cIhxgMDQkVg?= =?us-ascii?q?zuFFIVKdAI2AgYLAQEDCZBMAQE?= IronPort-PHdr: A9a23:0cdcHhIxOI6bi/7MP9mcuXsyDhhOgF28FgEQ45sjzblJd/fr85fjO RnZ4vNgxB/MUJ7A4v1Jw+zRr+j7WGMG7JrA1RJKcJFFWxIfz8lDmQsmDZ2KDET6KLjhaClpV MhHXUVuqne8N0UdEc3iZlrU93u16zNaGhj2OQdvYOrvHYuHhMWs3Of08JrWMG11 IronPort-Data: A9a23:o3SUbq+CKuXiOEozLUg+DrUDQX6TJUtcMsCJ2f8bNWPcYEJGY0x3y zYZDGDTbK6JYGemf9h0bd/i8E1U68XQyoQwQQQ6ri1EQiMRo6IpJzg2wmQcns+2BpeeJK6yx 5xGMrEsFC23J5Pljk/F3oLJ9RGQ7onVAOqjYAL4EnopH1Y9EH140UgLd9MR2+aEv/DoW2thh vuqyyHvEAfNN+lcaz98Bwqr8XuDjdyq0N8qlgVWicNj4Dcyo0Io4Kc3fsldGZdXrr58RYZWT 86bpF2wE/iwEx0FUrtJmZ6jGqEGryK70QWm0hJrt6aebhdqhwFp+7gpMNUna3hVqHKzu9Mh1 OVOnMnlIespFvWkdOU1SRJUFWR1OrdLveafZ3O+qseUiUbBdhMAwd03UxpwZtJeq70xWD0Qn RAbAGhlghSri+6rw7+gYuJtnc8kasLsOevzv1k/k2+IV6Z8Hc+rr6Pi2PAF8jNtnJt3N6zYO ZYramRXXS3SWkgaUrsQIMtuwLj37pXlSBVZsEzLjas6/2aVyxZ+uJD2KMDUfNOiRMhJkACfv G2u127jAxgcctHZwjOf6n+qmuLVtSz+UYMWUra/85ZCj0eeyW0WCQcNVkqTrvywi0r4UNVaQ 3H44QI0pqQ0sUesVNS4BkX+q3+ftRlaUN1VewEn1O2T4ov5uC+HFGwrdTx+av9hjus1FSAa1 XbcyrsFGgdTmLGSTHuc8JKdojWzJTUZIAc+icksEFdtDz7L/d1bs/7fcjpwOPXv34GqQ1kc1 xjP/XZh3+9M5SIe//zjpQivvt66mnTeoufZDC3tX2ml5xl1f4mjD2BDwQeGtaYZRGp1o6Xog ZTps9KV4OZLBpaXmWnUGKMGHaqi4LCONzi0bb9T83sJqm/FF52LJN04DNRCyKFBaZtsldjBO xS7hO+pzMUPVEZGlIcuC25LN+wkzLL7CfPuXe3OY9xFb/BZLVHcoH4zORDIhTq8yyDAdJ3T3 7/GIa5A6l5HVsxaIMaeG4/xLJdynHllnDOPLXwF5037iuf2iIGppUctaQvSMb9RAFKsqwTO+ NEXLNqR1xhaS4XDjtr/r+YuwaQxBSFjX/je8pUPHsbae1YOMDxwUJf5nOJ+E6Q7xP49vrmTo RmAtrpwlQOXaYvvcl3aNBiOqdrHAP5CkJ7MFXZxZgz3hyFyOtjHAWV2X8JfQITLPddLlZZcJ 8Tpse3aahiTYlwrIwggUKQ= IronPort-HdrOrdr: A9a23:YFwer6PI7m2adMBcT23155DYdb4zR+YMi2TDiHoRdfUFSKKlfp 6V88jzjSWE9wr4WBkb6Le90dq7MA3hHP9OkMcs1NKZPDUO11HYV72KgbGSpgEIXheOitK1tp 0QMpSWaueAd2SS5PySiGLTfrpQo6jkzEnrv5ai854Hd3ANV0gU1XYANu/tKDwOeOApP+tcKL Osou584xawc3Ueacq2QlMfWfLYmtHNnJX6JTYbGh8O8mC1/HOVwY+/NyLd8gYVUjtJz7tn23 PCiRbF6qKqtOz+4gPA1lXU849dlLLau5h+7Y23+4oowwfX+0KVjbdaKvq/VfcO0aeSAWMR4Z zxStEbTp1OAj3qDzmISFDWqnjdOX4Vmg/fIBmj8CDeSQiTfkNmNyKH7rgpKCcxonBQz+1Uwe ZF2XmUuIFQCg6FlCPh58LQXxUvjUasp2E++NRjwkC3fLFuI4O5l7Zvtn+90a1wax7S+cQiCq 1jHcvc7PFZfReTaG3YpHBmxJipUm4oFhmLT0AesojNugIm00xR3g8d3ogSj30A/JUyR91N4P nFKL1hkPVLQtUNZaxwCe8dSY+8C3DLQxjLLGWOSG6XWJ0vKjbIsdr68b817OaldNgBy4Yzgo 3IVBdCuWs7ayvVeIWzNV1wg1nwqUmGLEHQI/Bllu5EU+fHNcjW2AW4OSQTr/c= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.87,170,1631577600"; d="scan'208,217";a="766928247" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Oct 2021 14:18:33 +0000 Received: from mail.cisco.com (xbe-aln-006.cisco.com [173.36.7.21]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 19LEIXXp023544 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 21 Oct 2021 14:18:33 GMT Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xbe-aln-006.cisco.com (173.36.7.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 21 Oct 2021 09:18:33 -0500 Received: from xfe-rtp-004.cisco.com (64.101.210.234) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Thu, 21 Oct 2021 09:18:32 -0500 Received: from NAM12-BN8-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.792.15 via Frontend Transport; Thu, 21 Oct 2021 10:18:32 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LY9DyO8wFKcU/LYHfaClrcyIyY/EnZEikz5OSeTdNaFu+263J/GYRaHyaAObPM7Vc/90awdnFAvKXAZsOtAdE4AsZAAPo/lxG8A3dI36kbYb+o8PnJPOveD2j/6JMcu+vh4gFHFzsEpbfCgLDmLTHrXfPJMdx0F8ZW1tZoDF/jeFGXWK0TODby0gixiQaDKTJRR7g44onLp+1+H82jioU34/ftiXq4HN27PjNUTGcw2Hqheg4Yk+OHHHofqteRZ+e24s6uNmxmjKiGocXg5CZLXhGrK8iPdBa6EMIHAittm1BV80Kjd3lOcu90A+eaiqZoFzv6atl5E3xuMl/i6zyA== 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=eIrI6BnWfnoGlWwJGQxU08tIzIfWY0YTJP87WZJpao0=; b=Wz6hPOwzz2ZpFzQLYCYks0SY8DQNIxNCfOwfrubuQPAv0nP8VGYLzPV1VU1fOOPk0PjgG0FXVRKsaD4DmnNK6lWDILLlY+sVjEoo/tMT75gOeYJWHKYOk/F4yp9aJAZ3tQ59LUai2RBZQoc7zUIux/Nb/2QK4MqLSy5JbxraZBbqZpf/r3ToZqVyEO1ydjp767kMBsQ3PfNv2lpiFurHRX2rGI45ncJeOdTkn2HNOJkUQXzqIdW2TsHgXKbuuFcMUEXxhVvOXdg/CcsNmjd91XJoqNW5WUiIbNVuW/hPl49YUGDh2J0ItPZsgqGBrz3I1bmtLSyD/i/RoqGzOm1c4A== 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=eIrI6BnWfnoGlWwJGQxU08tIzIfWY0YTJP87WZJpao0=; b=cUByfg6BQwWKnm/1HLYRr5BA01tlp7M55ILU0UChdavF1tKPGJFFNPQX9SFTmyYexc4DlPYeJQahSAbCM+HXBt4G1+bZmpJZCHgsSajV6TCloDOuVhzOa8L3q1Ng00mKJpbnYfYlJmZVI0ENyBiwRNWhW2ZqCTk7XGsNz0djTHE= Received: from BN6PR11MB4081.namprd11.prod.outlook.com (2603:10b6:405:78::38) by BN6PR11MB1825.namprd11.prod.outlook.com (2603:10b6:404:104::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.16; Thu, 21 Oct 2021 14:18:31 +0000 Received: from BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::90c7:290e:a57c:1a39]) by BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::90c7:290e:a57c:1a39%3]) with mapi id 15.20.4628.018; Thu, 21 Oct 2021 14:18:31 +0000 From: "Darren Dukes (ddukes)" To: Greg Mirsky , Brian E Carpenter CC: "spring@ietf.org" , "ipv6@ietf.org" Thread-Topic: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression Thread-Index: AQHXxe8+Uq3QOF5820qajRqw1QJECavdgCRC Date: Thu, 21 Oct 2021 14:18:31 +0000 Message-ID: References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <26d9fc32-4884-602c-975a-79fc64551727@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b7a8be5a-1459-4acd-8740-08d9949da8c2 x-ms-traffictypediagnostic: BN6PR11MB1825: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oAd/GRi/FRUfZH1zbaxYvaArDQxDtIXYj80O787b+91GQ0vJC5tLSy7/Vv7E/Lo9T21E+aR3RyjJmGf7CKHHMJXfKwmq+sMKIIqDCXGLwdAZH1FzzRIvw/dp1WZ55Rd3muvhfYaSWxZJLCKpKsPsKaaIcuBf+7tXfn8RYukWwnbzhEIAPHKPxcT0siKx7eEPLlX/eDnSJIJUYrr6/amalfK8xC5Xfj3Z4hJinit9gNtoLsigqI8wfM5Lf961kpztnqMP9ll8uPLfvlJdk7Qr+t9zfFQQzD9S2snFesGJ9z75xSwFQ8iuOsSH/KUp7b55EMw9yBTulZPbRRquRQyf4pCCju+wLgWzIzgiKbJCdVWauYaIZzf/2FtnqgDCY2zXdHuPxS08uTVmF0KVIuRlvULL3Q41xhEeV88Z4LyxjE+xYPBMBQjRrIJgZ+Nw1K7XAV3BLG0BuXYYAF9Py/X+k8Rp+yXhgMBvzoN6Frz8Q9J/Z5gcEMPgR1qys6TMt93szx2Eu07+E1r5uq4Ebfo8DAffVij6ED/hQb3nVV8vgFC/Cy/eD/easXVbmr/cyILzLVsMltAVWgCqYq0kstST3Dy95FSr5Q3tB7D3+qv0psstlwWJ1Tb8IpTx4kKiQzesoYg5rOlVE89YwScCaLPxY+pbKrs0HblRPPyY1GQdRyjenjMyD5udb7dZCqqr+TnsVwEwkP6cUGGR95EgGzjAJLHZz72bGbA1dWiWHN9AcRS1UAn8ONN2klvsgZNLrVcB3O9bNVLTP0RSpQKotDLuWFiaR9IEMPmqe0FergwWzuxpDUXD0ox4m+27NkUfRjYi87wGg7y/xGm2GdbxFik3Cw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB4081.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(9686003)(76116006)(66946007)(66556008)(66476007)(91956017)(64756008)(52536014)(55016002)(26005)(66446008)(166002)(66574015)(83380400001)(33656002)(38100700002)(4326008)(966005)(122000001)(7696005)(71200400001)(6506007)(54906003)(110136005)(5660300002)(4001150100001)(38070700005)(30864003)(8676002)(53546011)(316002)(8936002)(86362001)(186003)(2906002)(9326002)(508600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?VkVSesZTWS06OI/soX03VBO4bnxhfSf3mhdlsS8xLdlRfxRwJYVGKEJqBlRW?= =?us-ascii?Q?KuM5tJABJMk/gawC+YnnkePwZOcl4PTVbeZ5IzOto/VfiBM1tw27sD4HU6h3?= =?us-ascii?Q?5deYKa8UKG+yUjTmboR2tFmsScWQrflatKCRY5lCPTaDaXj8tci9+jrcC9uA?= =?us-ascii?Q?4GaIcw8mBNU8PW84bDfm+aWZYQqtQQPUaaKUw92+CCSFmGXnS2CkTYx8t5pU?= =?us-ascii?Q?lVTMwyQEFNBeaUaSfT8grl+bS1mnFA1kxotV+cMX3CvdUD0+z5MfscIcfj4q?= =?us-ascii?Q?FILFb7k1NwN9Gdd3rr0hSL5X0CFzp4+Hgq3XLEXfB0XLsnvBICUBwg8md7o2?= =?us-ascii?Q?kZCIvQxlaoLcelPK2lXURxAw1MofBUVgyDrFvSIzKViaLh5b4FwjM3MWOQbC?= =?us-ascii?Q?ImPnl2I6TdWz9CsJWrWBUSNTf+lpfo+UVNKl2t72/0iLsK6WlvdoDYels1gP?= =?us-ascii?Q?ifw9U87UdW7DhbqRhGjKN2zkE6mcSvSdQJuWCqKzWy4XTmcq9vv8ljzT1lHz?= =?us-ascii?Q?Lnn7HHXuVeu+rXMxqYUat3eVy5P4Icuffk/ojxTcInkmPkbi3dipqzZHxg0p?= =?us-ascii?Q?DwK9d8/7NLnO7wqYhF51uHX1Xh8oI232C+aFZrXLKDsKYzg2JL6Gl7wz1nln?= =?us-ascii?Q?4ULLBNNGUAG5H/06Oq/7o3rDL1ITUL7RQwLQR4Oh0Cqn3/37IapUJbiN/tP5?= =?us-ascii?Q?iziPmuVXQgTOvR1dkpV2lAuJDVkc6C6DqDVeMCVDOhVyJujuYv+Fr+2hwARh?= =?us-ascii?Q?zhhSyFAlwAPIXToFTTWZIyvDuEkNf5cmdpNHAfyX/lfO/UGZdwBcpH3rrYvI?= =?us-ascii?Q?5zQcEYqGIDVTxSZaYx9pR0vLCCosOsbH0Wx/+6v8sDvZ8wdJa72StxgMx2TV?= =?us-ascii?Q?vBlKMWhWQfnnAPYnYVpkBpYEr/smk+Vsk7yxfa6y+68xdgtt15IfAPPO+vcZ?= =?us-ascii?Q?Jz1l/kMaR0pgWk3Uz8vj39jkr+Gku60yPhjcoMMw4icP5DuDm97axvpjjwyZ?= =?us-ascii?Q?UB98Oi2SJJ2VoGD2DnFvRfqQUMULy3SSrRHdczcMqTSea/koH5FWkwCxwIbB?= =?us-ascii?Q?59mSoA0AcVaGO04AypPv2s+StIwxeoRujkfSWBXKFab4FYmC/dytPHu7qVoF?= =?us-ascii?Q?ahLqSmINKxxQLxz6ksk2g4+k2xZeqLvrsK6NQJezzPYuJF0gHqw6JYmCECCF?= =?us-ascii?Q?jWDfcstBq80melI0UPjFp9W5Dln1kLdl82s3ZVqz1BKO5HInxoJDD8zS1xAz?= =?us-ascii?Q?vJkxM0sJUItpE6+xS1P1ekjNDBfDdH8FgR26Q6Fqy9k/uy8hVs5hapxzqAJz?= =?us-ascii?Q?zDwM/A1hKFtw12KVPa6cKusFeN3q5fbsJw9WGwgybA2LayzaK96XgzYuCNbn?= =?us-ascii?Q?r+DgNzXcY25jrbGxHJUikBYbIybadEUEPTz9KokakTgoF9G32DDFCA/WjxpL?= =?us-ascii?Q?C/ZsjB7lHptKNQUdIMpeIhk+HJXhlAme?= Content-Type: multipart/alternative; boundary="_000_BN6PR11MB408139C73921509416BACE4EC8BF9BN6PR11MB4081namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN6PR11MB4081.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b7a8be5a-1459-4acd-8740-08d9949da8c2 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2021 14:18:31.0943 (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: ddukes@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1825 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.21, xbe-aln-006.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 21 Oct 2021 14:18:41 -0000 --_000_BN6PR11MB408139C73921509416BACE4EC8BF9BN6PR11MB4081namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Greg, Your question is not clear to me. Can you try to restate it with the flavors and behaviors from the draft in = question? Darren On 2021-10-20, 4:15 PM, "ipv6" wrote: Hi Brian, I've got some questions about what you've said: For that reason, the fact that the bottom 64 bits in the "address" look funny or change is simply irrelevant. They are invisible to routing (which is done based on the prefix) and invisible to neighbor discovery (because it never happens). As I understand it, what you describe is the case of a strict explicit path= defined using one of the C-SID compression methods. But I am not sure that= your conclusion also always applies when it is a loose explicit path speci= fied in the compressed Segment List. As all C-SIDs share the same prefix, h= ow routing can be done based only on that prefix and not using a part of th= at "funny" bottom 64 bits? And if any part of the bottom 64 bits must be us= ed, how one can guarantee that CIDR still works in that domain? Regards, Greg On Mon, Oct 18, 2021 at 9:50 PM Brian E Carpenter > wrote: Hi, After reading a lot of messages, I'm going to offer my considered opinion as a direct response to Joel's OP. Firstly, I don't believe that in the end this draft raises any concerns that are *significantly* different than those raised when RFC 8986 was in draft. As Ted Hardie mentioned, section 5 of RFC 8754 explains that SIDs of any shape or size are only meaningful within an SR domain. That applies to srh-compression too. Secondly, I was concerned about how these strange looking "addresses" would potentially interfere with normal IPv6 addresses and their handling by normal IPv6 nodes. Well, I now believe that they won't. The reason is that in the SR model these "addresses" are *never used for final delivery of IPv6 packets to a host.* All SRv6 participants are routers. The last hop for a packet whose DA is set to (say) 2001:db8:a:1900:: is *not* the last hop on a LAN, mediated by neighbor discovery for 2001:db8:a:1900::. It's just a hop from one router to another, using the entry for 2001:db8:a:1900::/64 in the FIB of the last router that actually forwards the packet. 2001:db8:a:1900:: is not assigned to a physical interface so RFC 4861 is never invoked. Another way to say it is RFC 7608 is the relevant architectural standard. CIDR rules, even within an SR domain. For that reason, the fact that the bottom 64 bits in the "address" look funny or change is simply irrelevant. They are invisible to routing (which is done based on the prefix) and invisible to neighbor discovery (because it never happens). I apologise if this is all obvious to everybody, but I needed to spell it out for my own understanding. Now back to Joel's questions: On 13-Oct-21 20:37, Joel M. Halpern wrote: > There is a typo in the below which if not understood as a typo would be > quite confusing. I wrote that I raised the issue with > "with the Internet ADs and SPRING chairs". > That should have read "with the Internet ADs and 6man chairs". > The SPRING co-chairs are recused, and the charter requirement leads to > the 6man chairs. Which is who I talked to. > > Also, I am sending a courtesy copy to the routing ADs, which I should > have done originally. > > Thank you and enjoy. > Yours, > Joel > > On 10/12/2021 11:52 PM, Joel M. Halpern wrote: >> The SPRING working group is in the midst of an adoption call on >> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-com= pression/. >> >> >> The SPRING charter has text that is explicit that modifications to data >> planes and architectures standardized by other working groups may not be >> modified in SPRING unless the chairs and ADs responsible for that data >> plane and / or architecture agree. >> >> To complete the context, as my SPRING co-chairs are co-authors on the >> document in question, they have recused themselves from decisional >> activities regarding the document. Therefore, this message is coming >> just from my as the responsible SPRING co-chair managing this adoption >> call. >> >> As you have seen, multiple questions have been raised about the >> relationship of the document to the IPv6 defined data plane and >> architecture (particularly RFC 4291 and 8200). In particular the >> questions seem to revolve around what the document describes as the >> NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6 >> standards. (For those seeking more context without reading the full >> document, a paraphrase and simplification of the NEXT-C_SID flavor is >> provided as a postscript.) >> >> I raised the question of concurrence as required by the SPRING charter >> with the Internet ADs and SPRING chairs. They quite reasonably asked me >> to write a note to 6man explaining the concerns as clearly as a can, so >> that they can then determine how to proceed. >> >> The questions that prompted my inquiry are: >> >> 1) Does the placement of a list of sids in the IPv6 DA field change the >> IPv6 architectural description of that field. I think it should be noted explicitly somewhere that since the contents of the DA field are *never* used for last-hop neighbor discovery, the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942 are irrelevant. Another citation is RFC 7608: for routing, all that counts is the prefix, and it can be anything up to 128. Perhaps this should have been in section 5 of RFC 8754, but I leave that to the wordsmiths. >> 2) Does the operation of shifting information around in the IPv6 >> destination address field represent a modification or extension of the >> IPv6 data plane. No. As my text above indicates, the SRv6 DA field is only ever used by routing, where RFC 7608 rules. And of course it vanishes as soon as the packet is decapsulated. Regards Brian >> >> On a related note, the document in question also defines two other >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID >> flavor operation, so seems to be affected by the same question. >> >> From my own reading, it appears that the REPLACE-C-SID flavor does not >> raise issues requiring 6man leadership concurrence. >> >> Yours, >> Joel M. Halpern for the SPRING working group >> >> >> PS: >> Clearly, understanding the question requires some understanding of what >> the NEXT-C_SID flavor does. This explanation is a simplification for >> length and context. Really, the best place to understand it is the >> draft. However, to give you enough information to let you decide >> whether you care, I will try to provide a fair summary. My apologies in >> advance to the authors for necessary liberties for length. Also, >> discussion of the draft contents (as distinct from the interaction with >> the IPv6 data plane and architecture) belongs on the SPRING list, and >> should not clutter up 6man. >> >> SIDs are the identifiers used in segment routing. >> In SRv6, as document in the current RFCs, these are 128 bits. As >> defined in the relevant RFCs, SIDs which identify endpoints to which >> packets are directed are identified by endpoint SIDs. These can have >> behaviors (decapsulate and forward is one example). They can have >> flavors such as where the SRH is removed. >> >> The topic under discussion is means to compress these SIDs in the >> packets on the wire. The document under discussion provides three >> flavors of compression. >> >> The fundamental mechanism of the draft is to use a single SRH entry as a >> container for multiple SIDs. In the NEXT-C_SID mechanism, when it is >> first encountered the entire container is copied into the desination >> address of the IPv6 packet. The container has a common routing prefix >> used for all the NEXT-C-SID SIDs. It is followed by a sequence of >> compressed SIDs of a configured length. One could configure 16, 24, or >> 32 bits. Or whatever length. The routing advertisements are arranged >> so that the IPv6 packet is directed to the node represented by the first >> compressed SID on the basis of longest prefix match matching the >> combination of the common routing prefix and that compressed SID. >> >> When the packet arrives at that node, it looks up the configured >> portion, the compressed SID, and determines the behavior and flavor. In >> the case of the NEXT-C-SID flavor, the resulting operation is to shift >> the entire remaining contents of the IPv6 address (the bits past the >> first compressed sid) so as to over-write the first compressed SID. 0 >> bits are shifted into the low order positions. If the result is a >> non-zero new first compressed SID, then the packets is forwarded and the >> process repeats. When all that is left are 0s, if there is an SRH, it >> is consulted to find the next SRH entry, which is, per normal SRv6 >> processing, put into the IPv6 DA. >> Note that in the common case where the SIDS needed all fit in to a >> single container, the analysis also assumes the use of the reduced >> encapsulation options which omits the SRH that is not needed as it would >> have no entries. This the packet contains a normal IPv6 header, with a >> sequence of compressed SIDs (what one might or might not call a source >> route) in the IPv6 destination address field. >> >> PPS: If the authors of the NEXT-C-SID flavor feel I have mis-represented >> the work, please, send clarifications or corrections. Again, the best >> source of information is the draft itself. I was asked to provide extra >> context in this email. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- --_000_BN6PR11MB408139C73921509416BACE4EC8BF9BN6PR11MB4081namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi Greg,

     

    Your question is not clear to m= e.

    Can you try to restate it with = the flavors and behaviors from the draft in question?

     

    Darren

     

    On 2021-10-20, 4:15 PM,= "ipv6" <ipv6-bounces@ietf.org> wrote:

     

    Hi Brian,

    I've got some questions= about what you've said:

    For that reason, the fa= ct that the bottom 64 bits in the

    "address" loo= k funny or change is simply irrelevant. They are

    invisible to routing (w= hich is done based on the prefix)

    and invisible to neighb= or discovery (because it never happens).

    As I understand it, wha= t you describe is the case of a strict explicit path defined using one of t= he C-SID compression methods. But I am not sure that your conclusion also a= lways applies when it is a loose explicit path specified in the compressed Segment List. As all C-SIDs share the sam= e prefix, how routing can be done based only on that prefix and not using a= part of that "funny" bottom 64 bits? And if any part of the bott= om 64 bits must be used, how one can guarantee that CIDR still works in that domain?

     

    Regards,

    Greg

     

    On Mon, Oct 18, 2021 at= 9:50 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

    Hi,

    After reading a lot of messages, I'm going to offer my considered
    opinion as a direct response to Joel's OP.

    Firstly, I don't believe that in the end this draft raises any
    concerns that are *significantly* different than those raised
    when RFC 8986 was in draft. As Ted Hardie mentioned, section 5
    of RFC 8754 explains that SIDs of any shape or size are only
    meaningful within an SR domain. That applies to srh-compression
    too.

    Secondly, I was concerned about how these strange looking
    "addresses" would potentially interfere with normal IPv6
    addresses and their handling by normal IPv6 nodes. Well, I
    now believe that they won't. The reason is that in the SR model
    these "addresses" are *never used for final delivery of IPv6
    packets to a host.* All SRv6 participants are routers. The
    last hop for a packet whose DA is set to (say) 2001:db8:a:1900::
    is *not* the last hop on a LAN, mediated by neighbor discovery
    for 2001:db8:a:1900::. It's just a hop from one router to another,
    using the entry for 2001:db8:a:1900::/64 in the FIB of the last
    router that actually forwards the packet. 2001:db8:a:1900:: is
    not assigned to a physical interface so RFC 4861 is never invoked.

    Another way to say it is RFC 7608 is the relevant architectural
    standard. CIDR rules, even within an SR domain.

    For that reason, the fact that the bottom 64 bits in the
    "address" look funny or change is simply irrelevant. They are
    invisible to routing (which is done based on the prefix)
    and invisible to neighbor discovery (because it never happens).

    I apologise if this is all obvious to everybody, but I needed
    to spell it out for my own understanding.

    Now back to Joel's questions:


    On 13-Oct-21 20:37, Joel M. Halpern wrote:
    > There is a typo in the below which if not understood as a typo would b= e

    > quite confusing.   I wrote that I raised the issue with
    > "with the Internet ADs and SPRING chairs".
    > That should have read "with the Internet ADs and 6man chairs"= ;.
    > The SPRING co-chairs are recused, and the charter requirement leads to=
    > the 6man chairs.  Which is who I talked to.
    >
    > Also, I am sending a courtesy copy to the routing ADs, which I should =
    > have done originally.
    >
    > Thank you and enjoy.
    > Yours,
    > Joel
    >
    > On 10/12/2021 11:52 PM, Joel M. Halpern wrote:
    >> The SPRING working group is in the midst of an adoption call on >> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/.
    >>
    >>
    >> The SPRING charter has text that is explicit that modifications to= data
    >> planes and architectures standardized by other working groups may = not be
    >> modified in SPRING unless the chairs and ADs responsible for that = data

    >> plane and / or architecture agree.
    >>
    >> To complete the context, as my SPRING co-chairs are co-authors on = the
    >> document in question, they have recused themselves from decisional=
    >> activities regarding the document.  Therefore, this message i= s coming
    >> just from my as the responsible SPRING co-chair managing this adop= tion

    >> call.
    >>
    >> As you have seen, multiple questions have been raised about the >> relationship of the document to the IPv6 defined data plane and >> architecture (particularly RFC 4291 and 8200). In particular the <= br> >> questions seem to revolve around what the document describes as th= e
    >> NEXT-C-SID flavor of compressed SID, and its relationship to the I= Pv6
    >> standards.  (For those seeking more context without reading t= he full
    >> document, a paraphrase and simplification of the NEXT-C_SID flavor= is
    >> provided as a postscript.)
    >>
    >> I raised the question of concurrence as required by the SPRING cha= rter

    >> with the Internet ADs and SPRING chairs.  They quite reasonab= ly asked me
    >> to write a note to 6man explaining the concerns as clearly as a ca= n, so
    >> that they can then determine how to proceed.
    >>
    >> The questions that prompted my inquiry are:
    >>
    >> 1) Does the placement of a list of sids in the IPv6 DA field chang= e the
    >> IPv6 architectural description of that field.

    I think it should be noted explicitly somewhere that since the contents
    of the DA field are *never* used for last-hop neighbor discovery,
    the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942
    are irrelevant. Another citation is RFC 7608: for routing, all that
    counts is the prefix, and it can be anything up to 128.

    Perhaps this should have been in section 5 of RFC 8754, but I leave
    that to the wordsmiths.

    >> 2) Does the operation of shifting information around in the IPv6 <= br> >> destination address field represent a modification or extension of= the

    >> IPv6 data plane.

    No. As my text above indicates, the SRv6 DA field is only ever used
    by routing, where RFC 7608 rules. And of course it vanishes as soon
    as the packet is decapsulated.

    Regards
        Brian

    >>
    >> On a related note, the document in question also defines two other=
    >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.  The
    >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID=
    >> flavor operation, so seems to be affected by the same question. >>
    >>  From my own reading, it appears that the REPLACE-C-SID flavo= r does not
    >> raise issues requiring 6man leadership concurrence.
    >>
    >> Yours,
    >> Joel M. Halpern for the SPRING working group
    >>
    >>
    >> PS:
    >> Clearly, understanding the question requires some understanding of= what
    >> the NEXT-C_SID flavor does.   This explanation is a simp= lification for
    >> length and context.  Really, the best place to understand it = is the
    >> draft.  However, to give you enough information to let you de= cide

    >> whether you care, I will try to provide a fair summary.  My a= pologies in
    >> advance to the authors for necessary liberties for length.  A= lso,

    >> discussion of the draft contents (as distinct from the interaction= with
    >> the IPv6 data plane and architecture) belongs on the SPRING list, = and
    >> should not clutter up 6man.
    >>
    >> SIDs are the identifiers used in segment routing.
    >> In SRv6, as document in the current RFCs, these are 128 bits. = ;  As
    >> defined in the relevant RFCs, SIDs which identify endpoints to whi= ch
    >> packets are directed are identified by endpoint SIDs.  These = can have
    >> behaviors (decapsulate and forward is one example).  They can= have
    >> flavors such as where the SRH is removed.
    >>
    >> The topic under discussion is means to compress these SIDs in the =
    >> packets on the wire.  The document under discussion provides = three
    >> flavors of compression.
    >>
    >> The fundamental mechanism of the draft is to use a single SRH entr= y as
    a
    >> container for multiple SIDs.  In the NEXT-C_SID mechanism, wh= en it is
    >> first encountered the entire container is copied into the desinati= on
    >> address of the IPv6 packet.  The container has a common routi= ng prefix
    >> used for all the NEXT-C-SID SIDs.  It is followed by a sequen= ce of
    >> compressed SIDs of a configured length.  One could configure = 16, 24, or
    >> 32 bits.  Or whatever length.  The routing advertisement= s are arranged
    >> so that the IPv6 packet is directed to the node represented by the= first
    >> compressed SID on the basis of longest prefix match matching the <= br> >> combination of the common routing prefix and that compressed SID.<= br> >>
    >> When the packet arrives at that node, it looks up the configured <= br> >> portion, the compressed SID, and determines the behavior and flavo= r.  In
    >> the case of the NEXT-C-SID flavor, the resulting operation is to s= hift

    >> the entire remaining contents of the IPv6 address (the bits past t= he
    >> first compressed sid) so as to over-write the first compressed SID= .  0
    >> bits are shifted into the low order positions.  If the result= is a
    >> non-zero new first compressed SID, then the packets is forwarded a= nd the
    >> process repeats.  When all that is left are 0s, if there is a= n SRH, it
    >> is consulted to find the next SRH entry, which is, per normal SRv6=
    >> processing, put into the IPv6 DA.
    >> Note that in the common case where the SIDS needed all fit in to a=
    >> single container, the analysis also assumes the use of the reduced=
    >> encapsulation options which omits the SRH that is not needed as it= would
    >> have no entries.  This the packet contains a normal IPv6 head= er, with a
    >> sequence of compressed SIDs (what one might or might not call a so= urce

    >> route) in the IPv6 destination address field.
    >>
    >> PPS: If the authors of the NEXT-C-SID flavor feel I have mis-repre= sented
    >> the work, please, send clarifications or corrections.   = Again, the best
    >> source of information is the draft itself.  I was asked to pr= ovide extra
    >> context in this email.
    >
    > -------------------------------------------------------------------- > IETF IPv6 working group mailing list
    > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > -------------------------------------------------------------------- >

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------

    --_000_BN6PR11MB408139C73921509416BACE4EC8BF9BN6PR11MB4081namp_-- From nobody Thu Oct 21 16:03:31 2021 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 17F2A3A0E22; Thu, 21 Oct 2021 16:03:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7vwH-7Dv-uEz; Thu, 21 Oct 2021 16:03:15 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A7E93A08DE; Thu, 21 Oct 2021 16:03:15 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id c29so2009117pfp.2; Thu, 21 Oct 2021 16:03:15 -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=nOZVIZQA8vPgtOjfgvDdWCmvhKjAft8okr55+2X8Rts=; b=LEeSGr1EhIXvixrgFGVtD+iWjCkR03Heof0720FkT6cJ9dzcXgW4le6e8GG48BOjgp ecVj3YuhCLj9s/VcGFQxrieXfCzz7eJg0Bzm5gAKRVUCOP9po138PoYetbPD0zJQkf0y j8EyQZBk8c7ZAsc8fdzV2DEeRrulk2mL6NJZTn8R50tfq3gOWkXiQD0UZAVtOM0TpKri yFiRLdTzw/mgg3Ulv46GmhBzUTmhQO8NtPPuEZweuZ0px/U+1L/EII6/m4rPZtVWBBam Q4MsEhTPunmx5KZ0byHwtWkdYNpvGYK06jw+b/e437XE8SUx1GRZG733ZUhwWSblymyI cooQ== 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=nOZVIZQA8vPgtOjfgvDdWCmvhKjAft8okr55+2X8Rts=; b=6Q4Ds32U+to9E0ajcXW1QrumsuIt6p5PhITVkkvANrA3vDXRP1InPxrR0W7oPM936u C5Qg8muxclCnegkXLPs4C4tW20p41ou8gHwfUky+tuchQHn4lMG3qH6WV97F9+kpIxyT HANk9KGdYtpQvAqQyXMBROCuc9T/Fs2rQCXLgJ0au0TnCBg6LYU8qYcJu27w3oFxFSOI 6ai2MLPLX4IE493P6EyKhO5iN3xmg577XhwjwwyOh6bjnvzg4Ueo59zO1jeNHzYvviV0 OpTc6bT+2ClySVHlC/Lzpa6MEd4dUt1lpQfTOEwLcerjSBgRLWuZqV7K+1os7ljJJHlq FGMw== X-Gm-Message-State: AOAM530gHtDiyzN7idUm9VfQdDKCUw8oiMUhdk3J8/12+Q0e3uphhb2x lKF25PHMyedWuyQkwOew9KKH0pJ9JjlSC2cXY+PhvkCC X-Google-Smtp-Source: ABdhPJzL6Tp7eO2SbvQm+w5adh7CPjBanl4ddeid6uTO39DEegUtnexLHehrg0EYp7Ew+QpE3lRYTii00M6tKeP4JwM= X-Received: by 2002:a63:9250:: with SMTP id s16mr6576330pgn.469.1634857394964; Thu, 21 Oct 2021 16:03:14 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <26d9fc32-4884-602c-975a-79fc64551727@gmail.com> In-Reply-To: From: Gyan Mishra Date: Thu, 21 Oct 2021 19:00:47 -0400 Message-ID: To: Brian E Carpenter Cc: 6man , Mark Smith , SPRING WG , Tom Herbert Content-Type: multipart/alternative; boundary="000000000000490c8a05cee4e640" Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 21 Oct 2021 23:03:25 -0000 --000000000000490c8a05cee4e640 Content-Type: text/plain; charset="UTF-8" Brian Thank you for very eloquently explaining at least how an adjacency sid strict path end.x endpoint behavior does not violate any IPv6 specification. Also that CSID draft at least for end.x strict paths does not in any way change the IPv6 data plane. Kind Regards Gyan On Tue, Oct 19, 2021 at 5:39 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 20-Oct-21 05:02, Tom Herbert wrote: > > > > > > On Tue, Oct 19, 2021, 12:10 AM Mark Smith > wrote: > > > > Hi Brian, > > > > On Tue, 19 Oct 2021 at 15:51, Brian E Carpenter > > > > wrote: > > > > > > Hi, > > > > > > After reading a lot of messages, I'm going to offer my considered > > > opinion as a direct response to Joel's OP. > > > > > > Firstly, I don't believe that in the end this draft raises any > > > concerns that are *significantly* different than those raised > > > when RFC 8986 was in draft. As Ted Hardie mentioned, section 5 > > > of RFC 8754 explains that SIDs of any shape or size are only > > > meaningful within an SR domain. That applies to srh-compression > > > too. > > > > > > Secondly, I was concerned about how these strange looking > > > "addresses" would potentially interfere with normal IPv6 > > > addresses and their handling by normal IPv6 nodes. Well, I > > > now believe that they won't. The reason is that in the SR model > > > these "addresses" are *never used for final delivery of IPv6 > > > packets to a host.* All SRv6 participants are routers. The > > > last hop for a packet whose DA is set to (say) 2001:db8:a:1900:: > > > is *not* the last hop on a LAN, mediated by neighbor discovery > > > for 2001:db8:a:1900::. It's just a hop from one router to another, > > > using the entry for 2001:db8:a:1900::/64 in the FIB of the last > > > router that actually forwards the packet. 2001:db8:a:1900:: is > > > not assigned to a physical interface so RFC 4861 is never invoked. > > > > > > > So I'm guessing you're probably thinking of a router as a physical > > device (as most of us will by default), rather than as routing as a > > function. > > > > RFC8200 definitions: > > > > "router a node that forwards IPv6 packets > not explicitly > > addressed to itself. (See Note below.) > > > > host any node that is > not a router. (See Note below.)" > > (the note is about hosts having multiple interfaces) > > > > (A node doesn't have to be a device, and a device doesn't have to be > > physical, so the above are really function descriptions.) > > > > If a router as a physical device has IPv6 addresses that are sent to > > the device itself, then the router as a physical device is also > > performing host functions. For packets with those "router addresses", > > the router as a physical device is not "forward[ing] IPv6 packets not > > explicitly addressed to itself. " > > > > In a router as a physical device, the forwarding plane is performing > > the router function above. In a router as a physical device, the > > "control plane" (really just a fancy name for a host) is performing > > host functions on packets that are directly to and from it (BGP, > OSPF, > > SSH, SNMP etc. packets). > > > > The consequence is that all IPv6 addresses are host addresses, and > all > > processing of packets at the device that holds a packet's DA is host > > processing of the packet. > > > > It is the same in IPv4 - from RFC791, "The internet protocol > provides > > for transmitting blocks of data called datagrams from sources to > > destinations, where sources and destinations are hosts identified by > > fixed length addresses." > > > > So these packets with CSID rotating IPv6 DAs are being host processed > > by the router (as a device), after the forwarding plane in the router > > (as a device) has forwarded the packet to the colocated host > function. > > > > (A more practical example to support the above observation. If a > > router as a device is bought from a router vendor, and then is run as > > a BGP route reflector, meaning it is never in a packet forwarding > > path, and therefore never "forwards IPv6 packets not explicitly > > addressed to itself" is the router device still a router? > Functionally > > no, it is a host, even though it looks like a router (as a device).) > > > > > > Mark, > > > > On the other hand, when a node is processing a routing it header it does > forward packets addressed to it self (but not being the final destination). > Processing a router header is intuitively router functionality and not host > functionality. The RFC8200 definition of host and router don't seem to > consider routing headers, perhaps this should be amended to say that a host > is the final destination of the packet. > > That is the case even if the host is also a router and if it recognises > the DA of a packet delivered to it in its role as a router as a DA that it > handles in its role as a host. (In Linux jargon, that means "if the DA is > assigned to its loopback interface", but that is an implementation detail.) > > The point here is that the *previous* router doesn't know that the DA is > assigned that way; it just forwards the packet to whoever announced the > longest-matching prefix. It *does not* send the packet to DA. > > Brian > > > > > Tom > > > > > > Regards, > > Mark. > > > > > Another way to say it is RFC 7608 is the relevant architectural > > > standard. CIDR rules, even within an SR domain. > > > > > > For that reason, the fact that the bottom 64 bits in the > > > "address" look funny or change is simply irrelevant. They are > > > invisible to routing (which is done based on the prefix) > > > and invisible to neighbor discovery (because it never happens). > > > > > > I apologise if this is all obvious to everybody, but I needed > > > to spell it out for my own understanding. > > > > > > Now back to Joel's questions: > > > > > > > > > On 13-Oct-21 20:37, Joel M. Halpern wrote: > > > > There is a typo in the below which if not understood as a typo > would be > > > > > > > quite confusing. I wrote that I raised the issue with > > > > "with the Internet ADs and SPRING chairs". > > > > That should have read "with the Internet ADs and 6man chairs". > > > > The SPRING co-chairs are recused, and the charter requirement > leads to > > > > the 6man chairs. Which is who I talked to. > > > > > > > > Also, I am sending a courtesy copy to the routing ADs, which I > should > > > > have done originally. > > > > > > > > Thank you and enjoy. > > > > Yours, > > > > Joel > > > > > > > > On 10/12/2021 11:52 PM, Joel M. Halpern wrote: > > > >> The SPRING working group is in the midst of an adoption call on > > > >> > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > < > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > >. > > > >> > > > >> > > > >> The SPRING charter has text that is explicit that modifications > to data > > > >> planes and architectures standardized by other working groups > may not be > > > >> modified in SPRING unless the chairs and ADs responsible for > that data > > > > > > >> plane and / or architecture agree. > > > >> > > > >> To complete the context, as my SPRING co-chairs are co-authors > on the > > > >> document in question, they have recused themselves from > decisional > > > >> activities regarding the document. Therefore, this message is > coming > > > >> just from my as the responsible SPRING co-chair managing this > adoption > > > > > > >> call. > > > >> > > > >> As you have seen, multiple questions have been raised about the > > > >> relationship of the document to the IPv6 defined data plane and > > > >> architecture (particularly RFC 4291 and 8200). In particular the > > > >> questions seem to revolve around what the document describes as > the > > > >> NEXT-C-SID flavor of compressed SID, and its relationship to > the IPv6 > > > >> standards. (For those seeking more context without reading the > full > > > >> document, a paraphrase and simplification of the NEXT-C_SID > flavor is > > > >> provided as a postscript.) > > > >> > > > >> I raised the question of concurrence as required by the SPRING > charter > > > > > > >> with the Internet ADs and SPRING chairs. They quite reasonably > asked me > > > >> to write a note to 6man explaining the concerns as clearly as a > can, so > > > >> that they can then determine how to proceed. > > > >> > > > >> The questions that prompted my inquiry are: > > > >> > > > >> 1) Does the placement of a list of sids in the IPv6 DA field > change the > > > >> IPv6 architectural description of that field. > > > > > > I think it should be noted explicitly somewhere that since the > contents > > > of the DA field are *never* used for last-hop neighbor discovery, > > > the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942 > > > are irrelevant. Another citation is RFC 7608: for routing, all that > > > counts is the prefix, and it can be anything up to 128. > > > > > > Perhaps this should have been in section 5 of RFC 8754, but I leave > > > that to the wordsmiths. > > > > > > >> 2) Does the operation of shifting information around in the IPv6 > > > >> destination address field represent a modification or extension > of the > > > > > > >> IPv6 data plane. > > > > > > No. As my text above indicates, the SRv6 DA field is only ever used > > > by routing, where RFC 7608 rules. And of course it vanishes as soon > > > as the packet is decapsulated. > > > > > > Regards > > > Brian > > > > > > >> > > > >> On a related note, the document in question also defines two > other > > > >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The > > > >> NEXT-and-REPLACE-C_SID flavor is defined to include the > NEXT-C_SID > > > >> flavor operation, so seems to be affected by the same question. > > > >> > > > >> From my own reading, it appears that the REPLACE-C-SID flavor > does not > > > >> raise issues requiring 6man leadership concurrence. > > > >> > > > >> Yours, > > > >> Joel M. Halpern for the SPRING working group > > > >> > > > >> > > > >> PS: > > > >> Clearly, understanding the question requires some understanding > of what > > > >> the NEXT-C_SID flavor does. This explanation is a > simplification for > > > >> length and context. Really, the best place to understand > it is the > > > >> draft. However, to give you enough information to let you > decide > > > > > > >> whether you care, I will try to provide a fair summary. My > apologies in > > > >> advance to the authors for necessary liberties for length. > Also, > > > > > > >> discussion of the draft contents (as distinct from the > interaction with > > > >> the IPv6 data plane and architecture) belongs on the SPRING > list, and > > > >> should not clutter up 6man. > > > >> > > > >> SIDs are the identifiers used in segment routing. > > > >> In SRv6, as document in the current RFCs, these are 128 bits. > As > > > >> defined in the relevant RFCs, SIDs which identify endpoints to > which > > > >> packets are directed are identified by endpoint SIDs. These > can have > > > >> behaviors (decapsulate and forward is one example). They > can have > > > >> flavors such as where the SRH is removed. > > > >> > > > >> The topic under discussion is means to compress these SIDs in > the > > > >> packets on the wire. The document under discussion provides > three > > > >> flavors of compression. > > > >> > > > >> The fundamental mechanism of the draft is to use a single SRH > entry as > > > a > > > >> container for multiple SIDs. In the NEXT-C_SID mechanism, when > it is > > > >> first encountered the entire container is copied into the > desination > > > >> address of the IPv6 packet. The container has a common routing > prefix > > > >> used for all the NEXT-C-SID SIDs. It is followed by a sequence > of > > > >> compressed SIDs of a configured length. One could configure > 16, 24, or > > > >> 32 bits. Or whatever length. The routing advertisements are > arranged > > > >> so that the IPv6 packet is directed to the node represented by > the first > > > >> compressed SID on the basis of longest prefix match matching the > > > >> combination of the common routing prefix and that compressed > SID. > > > >> > > > >> When the packet arrives at that node, it looks up the configured > > > >> portion, the compressed SID, and determines the behavior and > flavor. In > > > >> the case of the NEXT-C-SID flavor, the resulting operation is > to shift > > > > > > >> the entire remaining contents of the IPv6 address (the bits > past the > > > >> first compressed sid) so as to over-write the first compressed > SID. 0 > > > >> bits are shifted into the low order positions. If the result > is a > > > >> non-zero new first compressed SID, then the packets is > forwarded and the > > > >> process repeats. When all that is left are 0s, if there is an > SRH, it > > > >> is consulted to find the next SRH entry, which is, per normal > SRv6 > > > >> processing, put into the IPv6 DA. > > > >> Note that in the common case where the SIDS needed all fit in > to a > > > >> single container, the analysis also assumes the use of the > reduced > > > >> encapsulation options which omits the SRH that is not needed as > it would > > > >> have no entries. This the packet contains a normal IPv6 > header, with a > > > >> sequence of compressed SIDs (what one might or might not call a > source > > > > > > >> route) in the IPv6 destination address field. > > > >> > > > >> PPS: If the authors of the NEXT-C-SID flavor feel I have > mis-represented > > > >> the work, please, send clarifications or corrections. Again, > the best > > > >> source of information is the draft itself. I was asked to > provide extra > > > >> context in this email. > > > > > > > > > -------------------------------------------------------------------- > > > > IETF IPv6 working group mailing list > > > > ipv6@ietf.org > > > > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 < > https://www.ietf.org/mailman/listinfo/ipv6> > > > > > -------------------------------------------------------------------- > > > > > > > > > > > -------------------------------------------------------------------- > > > IETF IPv6 working group mailing list > > > ipv6@ietf.org > > > Administrative Requests: > https://www.ietf.org/mailman/listinfo/ipv6 < > https://www.ietf.org/mailman/listinfo/ipv6> > > > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > > -------------------------------------------------------------------- > > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > -- *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --000000000000490c8a05cee4e640 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Brian=C2=A0

    Thank you for very eloquently explaining at least how = an adjacency sid strict path end.x endpoint behavior does not violate any I= Pv6 specification.

    Also = that CSID draft at least for end.x strict paths does not in any way change = the IPv6 data plane.

    Kin= d Regards=C2=A0

    Gyan

    On Tue, Oct 19, 2021 at 5:39 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
    On 20-Oct-21 05:02, Tom Herbert wrote: >
    >
    > On Tue, Oct 19, 2021, 12:10 AM Mark Smith <markzzzsmith@gmail.com <mailto:<= a href=3D"mailto:markzzzsmith@gmail.com" target=3D"_blank">markzzzsmith@gma= il.com>> wrote:
    >
    >=C2=A0 =C2=A0 =C2=A0Hi Brian,
    >
    >=C2=A0 =C2=A0 =C2=A0On Tue, 19 Oct 2021 at 15:51, Brian E Carpenter
    >=C2=A0 =C2=A0 =C2=A0<brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.= com>> wrote:
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> Hi,
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> After reading a lot of messages, I'm going= to offer my considered
    >=C2=A0 =C2=A0 =C2=A0> opinion as a direct response to Joel's OP.=
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> Firstly, I don't believe that in the end t= his draft raises any
    >=C2=A0 =C2=A0 =C2=A0> concerns that are *significantly* different th= an those raised
    >=C2=A0 =C2=A0 =C2=A0> when RFC 8986 was in draft. As Ted Hardie ment= ioned, section 5
    >=C2=A0 =C2=A0 =C2=A0> of RFC 8754 explains that SIDs of any shape or= size are only
    >=C2=A0 =C2=A0 =C2=A0> meaningful within an SR domain. That applies t= o srh-compression
    >=C2=A0 =C2=A0 =C2=A0> too.
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> Secondly, I was concerned about how these stra= nge looking
    >=C2=A0 =C2=A0 =C2=A0> "addresses" would potentially interf= ere with normal IPv6
    >=C2=A0 =C2=A0 =C2=A0> addresses and their handling by normal IPv6 no= des. Well, I
    >=C2=A0 =C2=A0 =C2=A0> now believe that they won't. The reason is= that in the SR model
    >=C2=A0 =C2=A0 =C2=A0> these "addresses" are *never used fo= r final delivery of IPv6
    >=C2=A0 =C2=A0 =C2=A0> packets to a host.* All SRv6 participants are = routers. The
    >=C2=A0 =C2=A0 =C2=A0> last hop for a packet whose DA is set to (say)= 2001:db8:a:1900::
    >=C2=A0 =C2=A0 =C2=A0> is *not* the last hop on a LAN, mediated by ne= ighbor discovery
    >=C2=A0 =C2=A0 =C2=A0> for 2001:db8:a:1900::. It's just a hop fro= m one router to another,
    >=C2=A0 =C2=A0 =C2=A0> using the entry for 2001:db8:a:1900::/64 in th= e FIB of the last
    >=C2=A0 =C2=A0 =C2=A0> router that actually forwards the packet. 2001= :db8:a:1900:: is
    >=C2=A0 =C2=A0 =C2=A0> not assigned to a physical interface so RFC 48= 61 is never invoked.
    >=C2=A0 =C2=A0 =C2=A0>
    >
    >=C2=A0 =C2=A0 =C2=A0So I'm guessing you're probably thinking of= a router as a physical
    >=C2=A0 =C2=A0 =C2=A0device (as most of us will by default), rather than= as routing as a
    >=C2=A0 =C2=A0 =C2=A0function.
    >
    >=C2=A0 =C2=A0 =C2=A0RFC8200 definitions:
    >
    >=C2=A0 =C2=A0 =C2=A0"router=C2=A0 =C2=A0 =C2=A0 =C2=A0a node that = forwards IPv6 packets
    not explicitly
    >=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 addressed to itself.=C2=A0 (See Note below.)
    >
    >=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0host=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= any node that is
    not a router.=C2=A0 (See Note below.)"
    >=C2=A0 =C2=A0 =C2=A0(the note is about hosts having multiple interfaces= )
    >
    >=C2=A0 =C2=A0 =C2=A0(A node doesn't have to be a device, and a devi= ce doesn't have to be
    >=C2=A0 =C2=A0 =C2=A0physical, so the above are really function descript= ions.)
    >
    >=C2=A0 =C2=A0 =C2=A0If a router as a physical device has IPv6 addresses= that are sent to
    >=C2=A0 =C2=A0 =C2=A0the device itself, then the router as a physical de= vice is also
    >=C2=A0 =C2=A0 =C2=A0performing host functions. For packets with those &= quot;router addresses",
    >=C2=A0 =C2=A0 =C2=A0the router as a physical device is not "forwar= d[ing] IPv6 packets not
    >=C2=A0 =C2=A0 =C2=A0explicitly addressed to itself. "
    >
    >=C2=A0 =C2=A0 =C2=A0In a router as a physical device, the forwarding pl= ane is performing
    >=C2=A0 =C2=A0 =C2=A0the router function above. In a router as a physica= l device, the
    >=C2=A0 =C2=A0 =C2=A0"control plane" (really just a fancy name= for a host) is performing
    >=C2=A0 =C2=A0 =C2=A0host functions on packets that are directly to and = from it (BGP, OSPF,
    >=C2=A0 =C2=A0 =C2=A0SSH, SNMP etc. packets).
    >
    >=C2=A0 =C2=A0 =C2=A0The consequence is that all IPv6 addresses are host= addresses, and all
    >=C2=A0 =C2=A0 =C2=A0processing of packets at the device that holds a pa= cket's DA is host
    >=C2=A0 =C2=A0 =C2=A0processing of the packet.
    >
    >=C2=A0 =C2=A0 =C2=A0It is the same in IPv4=C2=A0 - from RFC791, "T= he internet protocol provides
    >=C2=A0 =C2=A0 =C2=A0for transmitting blocks of data called datagrams fr= om sources to
    >=C2=A0 =C2=A0 =C2=A0destinations, where sources and destinations are ho= sts identified by
    >=C2=A0 =C2=A0 =C2=A0fixed length addresses."
    >
    >=C2=A0 =C2=A0 =C2=A0So these packets with CSID rotating IPv6 DAs are be= ing host processed
    >=C2=A0 =C2=A0 =C2=A0by the router (as a device), after the forwarding p= lane in the router
    >=C2=A0 =C2=A0 =C2=A0(as a device) has forwarded the packet to the coloc= ated host function.
    >
    >=C2=A0 =C2=A0 =C2=A0(A more practical example to support the above obse= rvation. If a
    >=C2=A0 =C2=A0 =C2=A0router as a device is bought from a router vendor, = and then is run as
    >=C2=A0 =C2=A0 =C2=A0a BGP route reflector, meaning it is never in a pac= ket forwarding
    >=C2=A0 =C2=A0 =C2=A0path, and therefore never "forwards IPv6 packe= ts not explicitly
    >=C2=A0 =C2=A0 =C2=A0addressed to itself" is the router device stil= l a router? Functionally
    >=C2=A0 =C2=A0 =C2=A0no, it is a host, even though it looks like a route= r (as a device).)
    >
    >
    > Mark,
    >
    > On the other hand, when a node is processing a routing it header it do= es forward packets addressed to it self (but not being the final destinatio= n). Processing a router header is intuitively router functionality and not = host functionality. The RFC8200 definition of host and router don't see= m to consider routing headers, perhaps this should be amended to say that a= host is the final destination of the packet.

    That is the case even if the host is also a router and if it recognises the= DA of a packet delivered to it in its role as a router as a DA that it handles in its role as a host. (In Linux jargon, that means "if the DA= is
    assigned to its loopback interface", but that is an implementation det= ail.)

    The point here is that the *previous* router doesn't know that the DA i= s assigned that way; it just forwards the packet to whoever announced the l= ongest-matching prefix. It *does not* send the packet to DA.

    =C2=A0 =C2=A0Brian

    >
    > Tom
    >
    >
    >=C2=A0 =C2=A0 =C2=A0Regards,
    >=C2=A0 =C2=A0 =C2=A0Mark.
    >
    >=C2=A0 =C2=A0 =C2=A0> Another way to say it is RFC 7608 is the relev= ant architectural
    >=C2=A0 =C2=A0 =C2=A0> standard. CIDR rules, even within an SR domain= .
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> For that reason, the fact that the bottom 64 b= its in the
    >=C2=A0 =C2=A0 =C2=A0> "address" look funny or change is si= mply irrelevant. They are
    >=C2=A0 =C2=A0 =C2=A0> invisible to routing (which is done based on t= he prefix)
    >=C2=A0 =C2=A0 =C2=A0> and invisible to neighbor discovery (because i= t never happens).
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> I apologise if this is all obvious to everybod= y, but I needed
    >=C2=A0 =C2=A0 =C2=A0> to spell it out for my own understanding.
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> Now back to Joel's questions:
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> On 13-Oct-21 20:37, Joel M. Halpern wrote:
    >=C2=A0 =C2=A0 =C2=A0> > There is a typo in the below which if not= understood as a typo would be
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> > quite confusing.=C2=A0 =C2=A0I wrote that= I raised the issue with
    >=C2=A0 =C2=A0 =C2=A0> > "with the Internet ADs and SPRING ch= airs".
    >=C2=A0 =C2=A0 =C2=A0> > That should have read "with the Inte= rnet ADs and 6man chairs".
    >=C2=A0 =C2=A0 =C2=A0> > The SPRING co-chairs are recused, and the= charter requirement leads to
    >=C2=A0 =C2=A0 =C2=A0> > the 6man chairs.=C2=A0 Which is who I tal= ked to.
    >=C2=A0 =C2=A0 =C2=A0> >
    >=C2=A0 =C2=A0 =C2=A0> > Also, I am sending a courtesy copy to the= routing ADs, which I should
    >=C2=A0 =C2=A0 =C2=A0> > have done originally.
    >=C2=A0 =C2=A0 =C2=A0> >
    >=C2=A0 =C2=A0 =C2=A0> > Thank you and enjoy.
    >=C2=A0 =C2=A0 =C2=A0> > Yours,
    >=C2=A0 =C2=A0 =C2=A0> > Joel
    >=C2=A0 =C2=A0 =C2=A0> >
    >=C2=A0 =C2=A0 =C2=A0> > On 10/12/2021 11:52 PM, Joel M. Halpern w= rote:
    >=C2=A0 =C2=A0 =C2=A0> >> The SPRING working group is in the mi= dst of an adoption call on
    >=C2=A0 =C2=A0 =C2=A0> >> https://datatracker.ietf.org/doc/draft-filsfilscheng-spr= ing-srv6-srh-compression/ <https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-= srv6-srh-compression/>.
    >=C2=A0 =C2=A0 =C2=A0> >>
    >=C2=A0 =C2=A0 =C2=A0> >>
    >=C2=A0 =C2=A0 =C2=A0> >> The SPRING charter has text that is e= xplicit that modifications to data
    >=C2=A0 =C2=A0 =C2=A0> >> planes and architectures standardized= by other working groups may not be
    >=C2=A0 =C2=A0 =C2=A0> >> modified in SPRING unless the chairs = and ADs responsible for that data
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> >> plane and / or architecture agree. >=C2=A0 =C2=A0 =C2=A0> >>
    >=C2=A0 =C2=A0 =C2=A0> >> To complete the context, as my SPRING= co-chairs are co-authors
    on the
    >=C2=A0 =C2=A0 =C2=A0> >> document in question, they have recus= ed themselves from decisional
    >=C2=A0 =C2=A0 =C2=A0> >> activities regarding the document.=C2= =A0 Therefore, this message is coming
    >=C2=A0 =C2=A0 =C2=A0> >> just from my as the responsible SPRIN= G co-chair managing this adoption
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> >> call.
    >=C2=A0 =C2=A0 =C2=A0> >>
    >=C2=A0 =C2=A0 =C2=A0> >> As you have seen, multiple questions = have been raised about the
    >=C2=A0 =C2=A0 =C2=A0> >> relationship of the document to the I= Pv6 defined data plane and
    >=C2=A0 =C2=A0 =C2=A0> >> architecture (particularly RFC 4291 a= nd 8200). In particular the
    >=C2=A0 =C2=A0 =C2=A0> >> questions seem to revolve around what= the document describes as the
    >=C2=A0 =C2=A0 =C2=A0> >> NEXT-C-SID flavor of compressed SID, = and its relationship to the IPv6
    >=C2=A0 =C2=A0 =C2=A0> >> standards.=C2=A0 (For those seeking m= ore context without reading the full
    >=C2=A0 =C2=A0 =C2=A0> >> document, a paraphrase and simplifica= tion of the NEXT-C_SID flavor is
    >=C2=A0 =C2=A0 =C2=A0> >> provided as a postscript.)
    >=C2=A0 =C2=A0 =C2=A0> >>
    >=C2=A0 =C2=A0 =C2=A0> >> I raised the question of concurrence = as required by the SPRING
    charter
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> >> with the Internet ADs and SPRING chai= rs.=C2=A0 They quite reasonably asked me
    >=C2=A0 =C2=A0 =C2=A0> >> to write a note to 6man explaining th= e concerns as clearly as a can, so
    >=C2=A0 =C2=A0 =C2=A0> >> that they can then determine how to p= roceed.
    >=C2=A0 =C2=A0 =C2=A0> >>
    >=C2=A0 =C2=A0 =C2=A0> >> The questions that prompted my inquir= y are:
    >=C2=A0 =C2=A0 =C2=A0> >>
    >=C2=A0 =C2=A0 =C2=A0> >> 1) Does the placement of a list of si= ds in the IPv6 DA field change the
    >=C2=A0 =C2=A0 =C2=A0> >> IPv6 architectural description of tha= t field.
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> I think it should be noted explicitly somewher= e that since the contents
    >=C2=A0 =C2=A0 =C2=A0> of the DA field are *never* used for last-hop = neighbor discovery,
    >=C2=A0 =C2=A0 =C2=A0> the IID aspect of RFC 4291 is irrelevant, and = RFC 4861 + RFC 5942
    >=C2=A0 =C2=A0 =C2=A0> are irrelevant. Another citation is RFC 7608: = for routing, all that
    >=C2=A0 =C2=A0 =C2=A0> counts is the prefix, and it can be anything u= p to 128.
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> Perhaps this should have been in section 5 of = RFC 8754, but I leave
    >=C2=A0 =C2=A0 =C2=A0> that to the wordsmiths.
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> >> 2) Does the operation of shifting inf= ormation around in the IPv6
    >=C2=A0 =C2=A0 =C2=A0> >> destination address field represent a= modification or extension of the
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> >> IPv6 data plane.
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> No. As my text above indicates, the SRv6 DA fi= eld is only ever used
    >=C2=A0 =C2=A0 =C2=A0> by routing, where RFC 7608 rules. And of cours= e it vanishes as soon
    >=C2=A0 =C2=A0 =C2=A0> as the packet is decapsulated.
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> Regards
    >=C2=A0 =C2=A0 =C2=A0>=C2=A0 =C2=A0 =C2=A0Brian
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> >>
    >=C2=A0 =C2=A0 =C2=A0> >> On a related note, the document in qu= estion also defines two other
    >=C2=A0 =C2=A0 =C2=A0> >> flavors, REPLACE-C-SID, and NEXT-and-= REPLACE-C-SID.=C2=A0 The
    >=C2=A0 =C2=A0 =C2=A0> >> NEXT-and-REPLACE-C_SID flavor is defi= ned to include the NEXT-C_SID
    >=C2=A0 =C2=A0 =C2=A0> >> flavor operation, so seems to be affe= cted by the same question.
    >=C2=A0 =C2=A0 =C2=A0> >>
    >=C2=A0 =C2=A0 =C2=A0> >>=C2=A0 From my own reading, it appears= that the REPLACE-C-SID flavor does not
    >=C2=A0 =C2=A0 =C2=A0> >> raise issues requiring 6man leadershi= p concurrence.
    >=C2=A0 =C2=A0 =C2=A0> >>
    >=C2=A0 =C2=A0 =C2=A0> >> Yours,
    >=C2=A0 =C2=A0 =C2=A0> >> Joel M. Halpern for the SPRING workin= g group
    >=C2=A0 =C2=A0 =C2=A0> >>
    >=C2=A0 =C2=A0 =C2=A0> >>
    >=C2=A0 =C2=A0 =C2=A0> >> PS:
    >=C2=A0 =C2=A0 =C2=A0> >> Clearly, understanding the question r= equires some understanding of what
    >=C2=A0 =C2=A0 =C2=A0> >> the NEXT-C_SID flavor does.=C2=A0 =C2= =A0This explanation is a simplification for
    >=C2=A0 =C2=A0 =C2=A0> >> length and context.=C2=A0 Really, the= best place to understand
    it is the
    >=C2=A0 =C2=A0 =C2=A0> >> draft.=C2=A0 However, to give you eno= ugh information to let you decide
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> >> whether you care, I will try to provi= de a fair summary.=C2=A0 My apologies in
    >=C2=A0 =C2=A0 =C2=A0> >> advance to the authors for necessary = liberties for length.=C2=A0
    Also,
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> >> discussion of the draft contents (as = distinct from the interaction with
    >=C2=A0 =C2=A0 =C2=A0> >> the IPv6 data plane and architecture)= belongs on the SPRING list, and
    >=C2=A0 =C2=A0 =C2=A0> >> should not clutter up 6man.
    >=C2=A0 =C2=A0 =C2=A0> >>
    >=C2=A0 =C2=A0 =C2=A0> >> SIDs are the identifiers used in segm= ent routing.
    >=C2=A0 =C2=A0 =C2=A0> >> In SRv6, as document in the current R= FCs, these are 128 bits.=C2=A0 =C2=A0As
    >=C2=A0 =C2=A0 =C2=A0> >> defined in the relevant RFCs, SIDs wh= ich identify endpoints to
    which
    >=C2=A0 =C2=A0 =C2=A0> >> packets are directed are identified b= y endpoint SIDs.=C2=A0 These can have
    >=C2=A0 =C2=A0 =C2=A0> >> behaviors (decapsulate and forward is= one example).=C2=A0 They
    can have
    >=C2=A0 =C2=A0 =C2=A0> >> flavors such as where the SRH is remo= ved.
    >=C2=A0 =C2=A0 =C2=A0> >>
    >=C2=A0 =C2=A0 =C2=A0> >> The topic under discussion is means t= o compress these SIDs in the
    >=C2=A0 =C2=A0 =C2=A0> >> packets on the wire.=C2=A0 The docume= nt under discussion provides three
    >=C2=A0 =C2=A0 =C2=A0> >> flavors of compression.
    >=C2=A0 =C2=A0 =C2=A0> >>
    >=C2=A0 =C2=A0 =C2=A0> >> The fundamental mechanism of the draf= t is to use a single SRH entry as
    >=C2=A0 =C2=A0 =C2=A0> a
    >=C2=A0 =C2=A0 =C2=A0> >> container for multiple SIDs.=C2=A0 In= the NEXT-C_SID mechanism, when it is
    >=C2=A0 =C2=A0 =C2=A0> >> first encountered the entire containe= r is copied into the desination
    >=C2=A0 =C2=A0 =C2=A0> >> address of the IPv6 packet.=C2=A0 The= container has a common routing prefix
    >=C2=A0 =C2=A0 =C2=A0> >> used for all the NEXT-C-SID SIDs.=C2= =A0 It is followed by a sequence of
    >=C2=A0 =C2=A0 =C2=A0> >> compressed SIDs of a configured lengt= h.=C2=A0 One could configure 16, 24, or
    >=C2=A0 =C2=A0 =C2=A0> >> 32 bits.=C2=A0 Or whatever length.=C2= =A0 The routing advertisements are arranged
    >=C2=A0 =C2=A0 =C2=A0> >> so that the IPv6 packet is directed t= o the node represented by
    the first
    >=C2=A0 =C2=A0 =C2=A0> >> compressed SID on the basis of longes= t prefix match matching the
    >=C2=A0 =C2=A0 =C2=A0> >> combination of the common routing pre= fix and that compressed SID.
    >=C2=A0 =C2=A0 =C2=A0> >>
    >=C2=A0 =C2=A0 =C2=A0> >> When the packet arrives at that node,= it looks up the configured
    >=C2=A0 =C2=A0 =C2=A0> >> portion, the compressed SID, and dete= rmines the behavior and flavor.=C2=A0 In
    >=C2=A0 =C2=A0 =C2=A0> >> the case of the NEXT-C-SID flavor, th= e resulting operation is to shift
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> >> the entire remaining contents of the = IPv6 address (the bits past the
    >=C2=A0 =C2=A0 =C2=A0> >> first compressed sid) so as to over-w= rite the first compressed
    SID.=C2=A0 0
    >=C2=A0 =C2=A0 =C2=A0> >> bits are shifted into the low order p= ositions.=C2=A0 If the result is a
    >=C2=A0 =C2=A0 =C2=A0> >> non-zero new first compressed SID, th= en the packets is forwarded and the
    >=C2=A0 =C2=A0 =C2=A0> >> process repeats.=C2=A0 When all that = is left are 0s, if there is an SRH, it
    >=C2=A0 =C2=A0 =C2=A0> >> is consulted to find the next SRH ent= ry, which is, per normal SRv6
    >=C2=A0 =C2=A0 =C2=A0> >> processing, put into the IPv6 DA.
    >=C2=A0 =C2=A0 =C2=A0> >> Note that in the common case where th= e SIDS needed all fit in to a
    >=C2=A0 =C2=A0 =C2=A0> >> single container, the analysis also a= ssumes the use of the reduced
    >=C2=A0 =C2=A0 =C2=A0> >> encapsulation options which omits the= SRH that is not needed as it would
    >=C2=A0 =C2=A0 =C2=A0> >> have no entries.=C2=A0 This the packe= t contains a normal IPv6 header, with a
    >=C2=A0 =C2=A0 =C2=A0> >> sequence of compressed SIDs (what one= might or might not call a source
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> >> route) in the IPv6 destination addres= s field.
    >=C2=A0 =C2=A0 =C2=A0> >>
    >=C2=A0 =C2=A0 =C2=A0> >> PPS: If the authors of the NEXT-C-SID= flavor feel I have mis-represented
    >=C2=A0 =C2=A0 =C2=A0> >> the work, please, send clarifications= or corrections.=C2=A0 =C2=A0Again, the best
    >=C2=A0 =C2=A0 =C2=A0> >> source of information is the draft it= self.=C2=A0 I was asked to provide extra
    >=C2=A0 =C2=A0 =C2=A0> >> context in this email.
    >=C2=A0 =C2=A0 =C2=A0> >
    >=C2=A0 =C2=A0 =C2=A0> > -----------------------------------------= ---------------------------
    >=C2=A0 =C2=A0 =C2=A0> > IETF IPv6 working group mailing list
    >=C2=A0 =C2=A0 =C2=A0> > ipv6@ietf.org <mailto:ipv6@ietf.org>
    >=C2=A0 =C2=A0 =C2=A0> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 <https:= //www.ietf.org/mailman/listinfo/ipv6>
    >=C2=A0 =C2=A0 =C2=A0> > -----------------------------------------= ---------------------------
    >=C2=A0 =C2=A0 =C2=A0> >
    >=C2=A0 =C2=A0 =C2=A0>
    >=C2=A0 =C2=A0 =C2=A0> ----------------------------------------------= ----------------------
    >=C2=A0 =C2=A0 =C2=A0> IETF IPv6 working group mailing list
    >=C2=A0 =C2=A0 =C2=A0> ipv6@ietf.org <mailto:ipv6@ietf.org>
    >=C2=A0 =C2=A0 =C2=A0> Administrative Requests: http= s://www.ietf.org/mailman/listinfo/ipv6 <https://www= .ietf.org/mailman/listinfo/ipv6>
    >=C2=A0 =C2=A0 =C2=A0> ----------------------------------------------= ----------------------
    >
    >=C2=A0 =C2=A0 =C2=A0---------------------------------------------------= -----------------
    >=C2=A0 =C2=A0 =C2=A0IETF IPv6 working group mailing list
    >=C2=A0 =C2=A0 =C2=A0= ipv6@ietf.org <mailto:ipv6@ietf.org>
    >=C2=A0 =C2=A0 =C2=A0Administrative Requests: https://w= ww.ietf.org/mailman/listinfo/ipv6
    <https://www.ietf.org/mailman/listinfo/ipv6>
    >=C2=A0 =C2=A0 =C2=A0---------------------------------------------------= -----------------
    >

    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --
    --000000000000490c8a05cee4e640-- From nobody Thu Oct 21 16:04:36 2021 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 A164E3A0E22; Thu, 21 Oct 2021 16:03:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUmVuNilmSKK; Thu, 21 Oct 2021 16:03:16 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 81BB53A0A55; Thu, 21 Oct 2021 16:03:16 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id v20so1443643plo.7; Thu, 21 Oct 2021 16:03:16 -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=AOC1RCFAxbF3ZRqjjDLUvDNcMeRkD2CrfOcp5OUvWag=; b=MqhOdJ5vrvjFRGSu0t7WRtDIPTWWeZ3pFQFN+61nZOl5S8rQVjq7gxMs1kGxJEN8J4 ECp+nXpoJTdKcNK7VzL4s8Y7Wo7FclEQ8HqEqRw8MY/hyQ+pERquVCOTvYONy193RDrP tESolMP2YjqMOKgfGPH/rheGE4Xte1BjjI3lEQfyWFUChDnoxPz8z8NFK4D5G1Z7QFxj 0zN00woSpAvzB7vjsr4TJLrarvR2/ZDIIf3HOfjVy6u8zloJIG9WNSXhlqsL833YGHel 9UwXiDkaEeew9Xl33fLPP+wMUdmYk7c5alC72IkdeqCgMZDll2STnEUnTmtlvcswwHmB EMZg== 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=AOC1RCFAxbF3ZRqjjDLUvDNcMeRkD2CrfOcp5OUvWag=; b=3e0IVTbdoqJj01Hnd/v8h+Ny4NvvAkJSe3sMzUlbYToPV7sn9Y0kqBfahIIsdEkOJA gaPkx0TdD+Ab/VhnSN9Z/Y9LvNl2Y++R77B0/+v5InjCO7Gocu0VDXnSGw0lz6apBhQ0 30LCFUsjEyqx+qB2BEJzA9zmfIjXz99CD68gxBrNJavTjSuBk85jgFjeuND4YDgVqvnI tQ3vNur7K6p9ckoiP64Dyk1uIqPrF4Nz853OcolomGKt+5/u6IupVR4FpcQyWKeVGUaL mpqOeUsRWb3RFSqgK5kgTIAF74upTDK/QXh3ZItGnyvlUGhUss25CYZ1BQayGCywxKf9 C4ZQ== X-Gm-Message-State: AOAM533DphMFtt8oTox7BpxW6nESiXREPZA/byJPcB9+9EkSX4O9jguX /15z0HYOLgPHRYxTL9uFuTgxW0Ay19S3y/To/NzSS3jX X-Google-Smtp-Source: ABdhPJxJyqrq6VjVVyORTSX2zSm8dGtSqv3mFfhUws1wAMN9QGVXt3fzv25d0qVLbbjyOBHtRv7OVfE9qPOL9cgg/no= X-Received: by 2002:a17:90b:1649:: with SMTP id il9mr10009320pjb.167.1634857394820; Thu, 21 Oct 2021 16:03:14 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <26d9fc32-4884-602c-975a-79fc64551727@gmail.com> In-Reply-To: From: Gyan Mishra Date: Thu, 21 Oct 2021 18:57:51 -0400 Message-ID: To: "Darren Dukes (ddukes)" Cc: Brian E Carpenter , Greg Mirsky , "ipv6@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="00000000000046da0b05cee4e699" Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 21 Oct 2021 23:03:28 -0000 --00000000000046da0b05cee4e699 Content-Type: text/plain; charset="UTF-8" Hi Darren What Greg is asking is if the SID is a prefix SID End and not adjacency SID End.x, so now the common prefix is needed to ECMP steer the flow to the prefix SID which uses the common prefix, which may in this case be mutated due to shifting of SIDs in GSID container. Kind Regards Gyan On Thu, Oct 21, 2021 at 10:18 AM Darren Dukes (ddukes) wrote: > Hi Greg, > > > > Your question is not clear to me. > > Can you try to restate it with the flavors and behaviors from the draft in > question? > > > > Darren > > > > On 2021-10-20, 4:15 PM, "ipv6" wrote: > > > > Hi Brian, > > I've got some questions about what you've said: > > For that reason, the fact that the bottom 64 bits in the > > "address" look funny or change is simply irrelevant. They are > > invisible to routing (which is done based on the prefix) > > and invisible to neighbor discovery (because it never happens). > > As I understand it, what you describe is the case of a strict explicit > path defined using one of the C-SID compression methods. But I am not sure > that your conclusion also always applies when it is a loose explicit path > specified in the compressed Segment List. As all C-SIDs share the same > prefix, how routing can be done based only on that prefix and not using a > part of that "funny" bottom 64 bits? And if any part of the bottom 64 bits > must be used, how one can guarantee that CIDR still works in that domain? > > > > Regards, > > Greg > > > > On Mon, Oct 18, 2021 at 9:50 PM Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > > Hi, > > After reading a lot of messages, I'm going to offer my considered > opinion as a direct response to Joel's OP. > > Firstly, I don't believe that in the end this draft raises any > concerns that are *significantly* different than those raised > when RFC 8986 was in draft. As Ted Hardie mentioned, section 5 > of RFC 8754 explains that SIDs of any shape or size are only > meaningful within an SR domain. That applies to srh-compression > too. > > Secondly, I was concerned about how these strange looking > "addresses" would potentially interfere with normal IPv6 > addresses and their handling by normal IPv6 nodes. Well, I > now believe that they won't. The reason is that in the SR model > these "addresses" are *never used for final delivery of IPv6 > packets to a host.* All SRv6 participants are routers. The > last hop for a packet whose DA is set to (say) 2001:db8:a:1900:: > is *not* the last hop on a LAN, mediated by neighbor discovery > for 2001:db8:a:1900::. It's just a hop from one router to another, > using the entry for 2001:db8:a:1900::/64 in the FIB of the last > router that actually forwards the packet. 2001:db8:a:1900:: is > not assigned to a physical interface so RFC 4861 is never invoked. > > Another way to say it is RFC 7608 is the relevant architectural > standard. CIDR rules, even within an SR domain. > > For that reason, the fact that the bottom 64 bits in the > "address" look funny or change is simply irrelevant. They are > invisible to routing (which is done based on the prefix) > and invisible to neighbor discovery (because it never happens). > > I apologise if this is all obvious to everybody, but I needed > to spell it out for my own understanding. > > Now back to Joel's questions: > > > On 13-Oct-21 20:37, Joel M. Halpern wrote: > > There is a typo in the below which if not understood as a typo would be > > > quite confusing. I wrote that I raised the issue with > > "with the Internet ADs and SPRING chairs". > > That should have read "with the Internet ADs and 6man chairs". > > The SPRING co-chairs are recused, and the charter requirement leads to > > the 6man chairs. Which is who I talked to. > > > > Also, I am sending a courtesy copy to the routing ADs, which I should > > have done originally. > > > > Thank you and enjoy. > > Yours, > > Joel > > > > On 10/12/2021 11:52 PM, Joel M. Halpern wrote: > >> The SPRING working group is in the midst of an adoption call on > >> > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/. > > >> > >> > >> The SPRING charter has text that is explicit that modifications to data > >> planes and architectures standardized by other working groups may not > be > >> modified in SPRING unless the chairs and ADs responsible for that data > > >> plane and / or architecture agree. > >> > >> To complete the context, as my SPRING co-chairs are co-authors on the > >> document in question, they have recused themselves from decisional > >> activities regarding the document. Therefore, this message is coming > >> just from my as the responsible SPRING co-chair managing this adoption > > >> call. > >> > >> As you have seen, multiple questions have been raised about the > >> relationship of the document to the IPv6 defined data plane and > >> architecture (particularly RFC 4291 and 8200). In particular the > >> questions seem to revolve around what the document describes as the > >> NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6 > >> standards. (For those seeking more context without reading the full > >> document, a paraphrase and simplification of the NEXT-C_SID flavor is > >> provided as a postscript.) > >> > >> I raised the question of concurrence as required by the SPRING charter > > >> with the Internet ADs and SPRING chairs. They quite reasonably asked > me > >> to write a note to 6man explaining the concerns as clearly as a can, so > >> that they can then determine how to proceed. > >> > >> The questions that prompted my inquiry are: > >> > >> 1) Does the placement of a list of sids in the IPv6 DA field change the > >> IPv6 architectural description of that field. > > I think it should be noted explicitly somewhere that since the contents > of the DA field are *never* used for last-hop neighbor discovery, > the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942 > are irrelevant. Another citation is RFC 7608: for routing, all that > counts is the prefix, and it can be anything up to 128. > > Perhaps this should have been in section 5 of RFC 8754, but I leave > that to the wordsmiths. > > >> 2) Does the operation of shifting information around in the IPv6 > >> destination address field represent a modification or extension of the > > >> IPv6 data plane. > > No. As my text above indicates, the SRv6 DA field is only ever used > by routing, where RFC 7608 rules. And of course it vanishes as soon > as the packet is decapsulated. > > Regards > Brian > > >> > >> On a related note, the document in question also defines two other > >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The > >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID > >> flavor operation, so seems to be affected by the same question. > >> > >> From my own reading, it appears that the REPLACE-C-SID flavor does not > >> raise issues requiring 6man leadership concurrence. > >> > >> Yours, > >> Joel M. Halpern for the SPRING working group > >> > >> > >> PS: > >> Clearly, understanding the question requires some understanding of what > >> the NEXT-C_SID flavor does. This explanation is a simplification for > >> length and context. Really, the best place to understand it is the > >> draft. However, to give you enough information to let you decide > > >> whether you care, I will try to provide a fair summary. My apologies > in > >> advance to the authors for necessary liberties for length. Also, > > >> discussion of the draft contents (as distinct from the interaction with > >> the IPv6 data plane and architecture) belongs on the SPRING list, and > >> should not clutter up 6man. > >> > >> SIDs are the identifiers used in segment routing. > >> In SRv6, as document in the current RFCs, these are 128 bits. As > >> defined in the relevant RFCs, SIDs which identify endpoints to which > >> packets are directed are identified by endpoint SIDs. These can have > >> behaviors (decapsulate and forward is one example). They can have > >> flavors such as where the SRH is removed. > >> > >> The topic under discussion is means to compress these SIDs in the > >> packets on the wire. The document under discussion provides three > >> flavors of compression. > >> > >> The fundamental mechanism of the draft is to use a single SRH entry as > a > >> container for multiple SIDs. In the NEXT-C_SID mechanism, when it is > >> first encountered the entire container is copied into the desination > >> address of the IPv6 packet. The container has a common routing prefix > >> used for all the NEXT-C-SID SIDs. It is followed by a sequence of > >> compressed SIDs of a configured length. One could configure 16, 24, or > >> 32 bits. Or whatever length. The routing advertisements are arranged > >> so that the IPv6 packet is directed to the node represented by the > first > >> compressed SID on the basis of longest prefix match matching the > >> combination of the common routing prefix and that compressed SID. > >> > >> When the packet arrives at that node, it looks up the configured > >> portion, the compressed SID, and determines the behavior and flavor. > In > >> the case of the NEXT-C-SID flavor, the resulting operation is to shift > > >> the entire remaining contents of the IPv6 address (the bits past the > >> first compressed sid) so as to over-write the first compressed SID. 0 > >> bits are shifted into the low order positions. If the result is a > >> non-zero new first compressed SID, then the packets is forwarded and > the > >> process repeats. When all that is left are 0s, if there is an SRH, it > >> is consulted to find the next SRH entry, which is, per normal SRv6 > >> processing, put into the IPv6 DA. > >> Note that in the common case where the SIDS needed all fit in to a > >> single container, the analysis also assumes the use of the reduced > >> encapsulation options which omits the SRH that is not needed as it > would > >> have no entries. This the packet contains a normal IPv6 header, with a > >> sequence of compressed SIDs (what one might or might not call a source > > >> route) in the IPv6 destination address field. > >> > >> PPS: If the authors of the NEXT-C-SID flavor feel I have > mis-represented > >> the work, please, send clarifications or corrections. Again, the best > >> source of information is the draft itself. I was asked to provide > extra > >> context in this email. > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -- *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --00000000000046da0b05cee4e699 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    Hi Darren=C2= =A0

    What Greg is asking = is if the SID is a prefix SID End and not adjacency SID End.x, so now the c= ommon prefix is needed to ECMP steer the flow =C2=A0to the prefix SID which= uses the common prefix, =C2=A0which may in this case be mutated due to shi= fting of SIDs in GSID container.


    Kind Regards=C2=A0

    Gyan=C2=A0
    On Thu, Oct 21, 2021 at 1= 0:18 AM Darren Dukes (ddukes) <ddukes=3D40cisco.com@dmarc.ietf.org> wrote:

    Hi Greg, <= /p>

    =C2=A0

    Your question is not clear to m= e.

    Can you try to restate it with = the flavors and behaviors from the draft in question?

    =C2=A0

    Darren

    =C2=A0

    On 2021-10-20, 4:15 PM,= "ipv6" <ipv6-bounces@ietf.org> wrote:

    =C2=A0

    Hi Brian,=

    I've got some quest= ions about what you've said:

    For that reason, the fa= ct that the bottom 64 bits in the

    "address" loo= k funny or change is simply irrelevant. They are

    invisible to routing (w= hich is done based on the prefix)

    and invisible to neighb= or discovery (because it never happens).

    As I understand it, wha= t you describe is the case of a strict explicit path defined using one of t= he C-SID compression methods. But I am not sure that your conclusion also a= lways applies when it is a loose explicit path specified in the compressed Segment List. As all C-SIDs share the sam= e prefix, how routing can be done based only on that prefix and not using a= part of that "funny" bottom 64 bits? And if any part of the bott= om 64 bits must be used, how one=C2=A0can guarantee that CIDR still works in that domain?

    =C2=A0

    Regards,<= /p>

    Greg

    =C2=A0

    On Mon, Oct 18, 2021 at= 9:50 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

    Hi,

    After reading a lot of messages, I'm going to offer my considered
    opinion as a direct response to Joel's OP.

    Firstly, I don't believe that in the end this draft raises any
    concerns that are *significantly* different than those raised
    when RFC 8986 was in draft. As Ted Hardie mentioned, section 5
    of RFC 8754 explains that SIDs of any shape or size are only
    meaningful within an SR domain. That applies to srh-compression
    too.

    Secondly, I was concerned about how these strange looking
    "addresses" would potentially interfere with normal IPv6
    addresses and their handling by normal IPv6 nodes. Well, I
    now believe that they won't. The reason is that in the SR model
    these "addresses" are *never used for final delivery of IPv6
    packets to a host.* All SRv6 participants are routers. The
    last hop for a packet whose DA is set to (say) 2001:db8:a:1900::
    is *not* the last hop on a LAN, mediated by neighbor discovery
    for 2001:db8:a:1900::. It's just a hop from one router to another,
    using the entry for 2001:db8:a:1900::/64 in the FIB of the last
    router that actually forwards the packet. 2001:db8:a:1900:: is
    not assigned to a physical interface so RFC 4861 is never invoked.

    Another way to say it is RFC 7608 is the relevant architectural
    standard. CIDR rules, even within an SR domain.

    For that reason, the fact that the bottom 64 bits in the
    "address" look funny or change is simply irrelevant. They are
    invisible to routing (which is done based on the prefix)
    and invisible to neighbor discovery (because it never happens).

    I apologise if this is all obvious to everybody, but I needed
    to spell it out for my own understanding.

    Now back to Joel's questions:


    On 13-Oct-21 20:37, Joel M. Halpern wrote:
    > There is a typo in the below which if not understood as a typo would b= e

    > quite confusing.=C2=A0 =C2=A0I wrote that I raised the issue with
    > "with the Internet ADs and SPRING chairs".
    > That should have read "with the Internet ADs and 6man chairs"= ;.
    > The SPRING co-chairs are recused, and the charter requirement leads to=
    > the 6man chairs.=C2=A0 Which is who I talked to.
    >
    > Also, I am sending a courtesy copy to the routing ADs, which I should =
    > have done originally.
    >
    > Thank you and enjoy.
    > Yours,
    > Joel
    >
    > On 10/12/2021 11:52 PM, Joel M. Halpern wrote:
    >> The SPRING working group is in the midst of an adoption call on >> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/.
    >>
    >>
    >> The SPRING charter has text that is explicit that modifications to= data
    >> planes and architectures standardized by other working groups may = not be
    >> modified in SPRING unless the chairs and ADs responsible for that = data

    >> plane and / or architecture agree.
    >>
    >> To complete the context, as my SPRING co-chairs are co-authors on = the
    >> document in question, they have recused themselves from decisional=
    >> activities regarding the document.=C2=A0 Therefore, this message i= s coming
    >> just from my as the responsible SPRING co-chair managing this adop= tion

    >> call.
    >>
    >> As you have seen, multiple questions have been raised about the >> relationship of the document to the IPv6 defined data plane and >> architecture (particularly RFC 4291 and 8200). In particular the <= br> >> questions seem to revolve around what the document describes as th= e
    >> NEXT-C-SID flavor of compressed SID, and its relationship to the I= Pv6
    >> standards.=C2=A0 (For those seeking more context without reading t= he full
    >> document, a paraphrase and simplification of the NEXT-C_SID flavor= is
    >> provided as a postscript.)
    >>
    >> I raised the question of concurrence as required by the SPRING cha= rter

    >> with the Internet ADs and SPRING chairs.=C2=A0 They quite reasonab= ly asked me
    >> to write a note to 6man explaining the concerns as clearly as a ca= n, so
    >> that they can then determine how to proceed.
    >>
    >> The questions that prompted my inquiry are:
    >>
    >> 1) Does the placement of a list of sids in the IPv6 DA field chang= e the
    >> IPv6 architectural description of that field.

    I think it should be noted explicitly somewhere that since the contents
    of the DA field are *never* used for last-hop neighbor discovery,
    the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942
    are irrelevant. Another citation is RFC 7608: for routing, all that
    counts is the prefix, and it can be anything up to 128.

    Perhaps this should have been in section 5 of RFC 8754, but I leave
    that to the wordsmiths.

    >> 2) Does the operation of shifting information around in the IPv6 <= br> >> destination address field represent a modification or extension of= the

    >> IPv6 data plane.

    No. As my text above indicates, the SRv6 DA field is only ever used
    by routing, where RFC 7608 rules. And of course it vanishes as soon
    as the packet is decapsulated.

    Regards
    =C2=A0 =C2=A0 Brian

    >>
    >> On a related note, the document in question also defines two other=
    >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.=C2=A0 The
    >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID=
    >> flavor operation, so seems to be affected by the same question. >>
    >>=C2=A0 From my own reading, it appears that the REPLACE-C-SID flavo= r does not
    >> raise issues requiring 6man leadership concurrence.
    >>
    >> Yours,
    >> Joel M. Halpern for the SPRING working group
    >>
    >>
    >> PS:
    >> Clearly, understanding the question requires some understanding of= what
    >> the NEXT-C_SID flavor does.=C2=A0=C2=A0 This explanation is a simp= lification for
    >> length and context.=C2=A0 Really, the best place to understand it = is the
    >> draft.=C2=A0 However, to give you enough information to let you de= cide

    >> whether you care, I will try to provide a fair summary.=C2=A0 My a= pologies in
    >> advance to the authors for necessary liberties for length.=C2=A0 A= lso,

    >> discussion of the draft contents (as distinct from the interaction= with
    >> the IPv6 data plane and architecture) belongs on the SPRING list, = and
    >> should not clutter up 6man.
    >>
    >> SIDs are the identifiers used in segment routing.
    >> In SRv6, as document in the current RFCs, these are 128 bits.=C2= =A0=C2=A0 As
    >> defined in the relevant RFCs, SIDs which identify endpoints to whi= ch
    >> packets are directed are identified by endpoint SIDs.=C2=A0 These = can have
    >> behaviors (decapsulate and forward is one example).=C2=A0 They can= have
    >> flavors such as where the SRH is removed.
    >>
    >> The topic under discussion is means to compress these SIDs in the =
    >> packets on the wire.=C2=A0 The document under discussion provides = three
    >> flavors of compression.
    >>
    >> The fundamental mechanism of the draft is to use a single SRH entr= y as
    a
    >> container for multiple SIDs.=C2=A0 In the NEXT-C_SID mechanism, wh= en it is
    >> first encountered the entire container is copied into the desinati= on
    >> address of the IPv6 packet.=C2=A0 The container has a common routi= ng prefix
    >> used for all the NEXT-C-SID SIDs.=C2=A0 It is followed by a sequen= ce of
    >> compressed SIDs of a configured length.=C2=A0 One could configure = 16, 24, or
    >> 32 bits.=C2=A0 Or whatever length.=C2=A0 The routing advertisement= s are arranged
    >> so that the IPv6 packet is directed to the node represented by the= first
    >> compressed SID on the basis of longest prefix match matching the <= br> >> combination of the common routing prefix and that compressed SID.<= br> >>
    >> When the packet arrives at that node, it looks up the configured <= br> >> portion, the compressed SID, and determines the behavior and flavo= r.=C2=A0 In
    >> the case of the NEXT-C-SID flavor, the resulting operation is to s= hift

    >> the entire remaining contents of the IPv6 address (the bits past t= he
    >> first compressed sid) so as to over-write the first compressed SID= .=C2=A0 0
    >> bits are shifted into the low order positions.=C2=A0 If the result= is a
    >> non-zero new first compressed SID, then the packets is forwarded a= nd the
    >> process repeats.=C2=A0 When all that is left are 0s, if there is a= n SRH, it
    >> is consulted to find the next SRH entry, which is, per normal SRv6=
    >> processing, put into the IPv6 DA.
    >> Note that in the common case where the SIDS needed all fit in to a=
    >> single container, the analysis also assumes the use of the reduced=
    >> encapsulation options which omits the SRH that is not needed as it= would
    >> have no entries.=C2=A0 This the packet contains a normal IPv6 head= er, with a
    >> sequence of compressed SIDs (what one might or might not call a so= urce

    >> route) in the IPv6 destination address field.
    >>
    >> PPS: If the authors of the NEXT-C-SID flavor feel I have mis-repre= sented
    >> the work, please, send clarifications or corrections.=C2=A0=C2=A0 = Again, the best
    >> source of information is the draft itself.=C2=A0 I was asked to pr= ovide extra
    >> context in this email.
    >
    > -------------------------------------------------------------------- > IETF IPv6 working group mailing list
    > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > -------------------------------------------------------------------- >

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------=

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
    --------------------------------------------------------------------
    --
    --00000000000046da0b05cee4e699-- From nobody Thu Oct 21 19:36:20 2021 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 488E53A09C1; Thu, 21 Oct 2021 19:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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 HKjkzRUH2hlV; Thu, 21 Oct 2021 19:36:10 -0700 (PDT) Received: from sendh.mailex.chinaunicom.cn (sendh.mailex.chinaunicom.cn [210.53.66.231]) by ietfa.amsl.com (Postfix) with ESMTP id 9373D3A09BB; Thu, 21 Oct 2021 19:36:06 -0700 (PDT) X-AuditID: 0a000f36-73ce0a8000007c17-6b-617223922ead Received: from M10-HQ-MLCEN01.cnc.intra (Unknown_Domain [10.249.212.31]) by sendh.mailex.chinaunicom.cn (Symantec Messaging Gateway) with SMTP id 47.D8.31767.29322716; Fri, 22 Oct 2021 10:36:02 +0800 (HKT) Received: from M10-HQ-ML04.hq.cnc.intra (10.249.213.74) by M10-HQ-MLCEN01.cnc.intra (10.249.212.31) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Fri, 22 Oct 2021 10:36:02 +0800 Received: from M10-HQ-ML10.hq.cnc.intra (10.249.213.80) by M10-HQ-ML04.hq.cnc.intra (10.249.213.74) with Microsoft SMTP Server (TLS) id 15.0.1497.23; Fri, 22 Oct 2021 10:35:58 +0800 Received: from M10-HQ-ML10.hq.cnc.intra ([fe80::cd67:886e:65c4:2842]) by M10-HQ-ML10.hq.cnc.intra ([fe80::cd67:886e:65c4:2842%20]) with mapi id 15.00.1497.023; Fri, 22 Oct 2021 10:35:58 +0800 From: =?utf-8?B?5bqe5YaJKOiBlOmAmumbhuWbouS4reWbveiBlOmAmueglOeptumZoi3mnKw=?= =?utf-8?B?6YOoKQ==?= To: James Guichard , "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: AQHXxuOIIAiVBXs4Zki093KUll3MpQ== Date: Fri, 22 Oct 2021 02:35:58 +0000 Message-ID: <18fefca3fbab4b698bbc909d8de775ec@M10-HQ-ML10.hq.cnc.intra> References: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.122.203.1] Content-Type: multipart/alternative; boundary="_000_18fefca3fbab4b698bbc909d8de775ecM10HQML10hqcncintra_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsXC9fOKvO4k5aJEg9WrLCx23lnFYnF6VS+7 xfELvxkdmD02r3PzWLLkJ1MAUxSXTUpqTmZZapG+XQJXxuSLH5gKZrQwVvS82srawHihgbGL kZNDQsBEYkfnQpYuRi4OIYHzjBLrl5xlgnB2MkqcvN3GCuc8mHSeDcI5zCjR3f6FDaSfTaBO YuXdL2CzRASiJNY3TgWzmQVMJe7M+g9mCwPVtD9ZwgJRUy+xfv9MJghbT2LxrXawGhYBVYlz ayYDzeTg4BVwl7j7uBIkLCQQI7Fj+2dWEJtRQFZi2qP7TBDjxSXmTpvFCvGCgMSSPeeZIWxR iZeP/0HFDSS2Lt3HAmErSCzvuQd1WrbEy6M7wGp4BQQlTs58wgKxS1mi+fh01gmM4rOQrJiF pGUWkpZZQJcyC2hKrN+lD1GiKDGl+yE7hK0h0TpnLjuy+AJG9lWMksG+7hbGFga6/iZ6yRmZ eYmleZnJ+bl6yXmbGEFRy8BvtoPxy60PeocYmTgYDzFKcDArifDurshPFOJNSaysSi3Kjy8q zUktPsQozcGiJM5bnR2UKCSQnliSmp2aWpBaBJNl4uCUamDaaLa8dutB7+tNS/1UG0X1F1zb Z2AyQ31qsdarZdf1nTRdpDueJ6Wfigvq1l+hPF9Mja1AdfWKuaz5+UfjysRW5ugsYgpJslhp YiPXxHpkfaumT2Re68EjctM8EjTP/HA4b/FXR43DVm53c8PNkldP788RlfitPDXug5OLeaV8 16zttT6R9ceUrWsEbcJebxD/9LbrwtlJf+81rOGb7lnszdOQs80pyGXamv/G/ya1//NNYWa3 f3PjSH5ug9jCGwk6Yd/y/duXryuxzT67h0f+cZjnbVndh76xV7Xdsp4ZXAzOtEmuKAueFGsg qHugqOW5+Bzb/tStn36Gbdfb8nblTsUurvtCMxbKWW7ZqMRSnJFoqMVcVJwIAOEKQxNJAwAA Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 22 Oct 2021 02:36:17 -0000 --_000_18fefca3fbab4b698bbc909d8de775ecM10HQML10hqcncintra_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGnvvIxXR++8jA0KDQpJIGFtIHNvcnJ5IGl0IHNlZW1zIHRvbyBsYXRlIHRvIHJlc3BvbmQgdG8g dGhlIGFkb3B0aW9uIGNhbGwuIEkgd291bGQgbGlrZSB0byBleHByZXNzIG15IHN1cHBvcnQgZm9y IHRoZSBkcmFmdC4NCkFzIGFuIG9wZXJhdG9yLCBXZSBkbyBuZWVkIGEgU1JIIGhlYWRlciBjb21w cmVzc2lvbiBzdGFuZGFyZC4gSGVuY2UsIHdl4oCZcmUgbG9va2luZyBmb3J3YXJkIHRvIGFueSBw cm9ncmVzcyBpbiBpdC4NCg0KQmVzdCByZWdhcmRzLA0KUGFuZyBSYW4uDQoNCkZyb206IEphbWVz IEd1aWNoYXJkPG1haWx0bzpqYW1lcy5uLmd1aWNoYXJkQGZ1dHVyZXdlaS5jb20+DQpEYXRlOiAy MDIxLTEwLTAxIDIyOjA0DQpUbzogU1BSSU5HIFdHPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpD Qzogc3ByaW5nLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nLWNoYWlyc0BpZXRmLm9yZz4N ClN1YmplY3Q6IFtzcHJpbmddIFdHIEFkb3B0aW9uIGNhbGwgZm9yIGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXBy ZXNzaW9uLw0KRGVhciBXRzoNCg0KVGhlIGNoYWlycyB3b3VsZCBsaWtlIHRvIGV4cHJlc3MgdGhl aXIgYXBwcmVjaWF0aW9uIGZvciBhbGwgdGhlIHJlc3BvbnNlcyByZWNlaXZlZCB0byBvdXIgZW1h aWxzIHdpdGggcmVmZXJlbmNlIHRvIGhvdyB0aGUgd29ya2luZyBncm91cCB3aXNoZXMgdG8gbW92 ZSBmb3J3YXJkIHdpdGggcmVzcGVjdCB0byBhIHNvbHV0aW9uIGZvciBTUnY2IGNvbXByZXNzaW9u Lg0KDQpUaGUgYXBwYXJlbnQgaW5jbGluYXRpb24gb2YgdGhlIHdvcmtpbmcgZ3JvdXAgaXMgdG8g dXNlIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmct c3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyBhcyB0aGUgYmFzaXMgZm9yIGl0cyBjb21wcmVz c2lvbiBzdGFuZGFyZGl6YXRpb24gd29yay4gVGhhdCBpcyBwYXJ0IG9mIHdoYXQgdGhpcyBlbWFp bCBhdHRlbXB0cyB0byBjb25maXJtLg0KDQpCZWNhdXNlIG9mIHRoZSBhYm92ZSB0aGUgY2hhaXJz IHdvdWxkIGxpa2UgdG8gaXNzdWUgYSAyLXdlZWsgV0cgY2FsbCBmb3IgYWRvcHRpb24gZW5kaW5n IE9jdG9iZXIgMTV0aCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt Zmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vIGJ1dCB3aXRoIHNvbWUg Y2xlYXIgZ3VpZGVsaW5lcyBhcyBmb2xsb3dzLiBCeSBleHByZXNzaW5nIHN1cHBvcnQgZm9yIGFk b3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgeW91IGFyZSBmdWxseSBhd2FyZSBvZiBhbmQgYXJlIGFj a25vd2xlZGdpbmcgdGhhdDoNCg0KDQogIDEuICBUaGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAgaXMg YWRvcHRpbmcgYSBkb2N1bWVudCB0aGF0IGhhcyBtdWx0aXBsZSBTUnY2IEVuZHBvaW50IGJlaGF2 aW9ycy4NCiAgMi4gIFRoZSBkb2N1bWVudCBpcyBhIOKAnGxpdmluZ+KAnSBkb2N1bWVudDsgaXQg bWF5IGNoYW5nZSBhcyBpdCBnb2VzIHRocm91Z2ggcmV2aWV3IGFuZCBhbmFseXNpcyBieSB0aGUg U1BSSU5HIHdvcmtpbmcgZ3JvdXAuDQogIDMuICBBbGwgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyBy YWlzZWQgb24gb3VyIG1haWxpbmcgbGlzdCBNVVNUIGJlIGFkZHJlc3NlZCBCRUZPUkUgc2FpZCBk b2N1bWVudCBpcyBhbGxvd2VkIHRvIHByb2dyZXNzIGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAgdG8g cHVibGljYXRpb24uIEEgbGlzdCBvZiB0aGVzZSBkaXNjdXNzaW9uIHBvaW50cyB3aWxsIGJlIGRv Y3VtZW50ZWQgaW4gdGhlIFdHIGRvY3VtZW50IGFuZCBtYWludGFpbmVkIGJ5IHRoZSBkb2N1bWVu dCBlZGl0b3IgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgY2hhaXJzLg0KICA0LiAgSWYgdGhpcyBk b2N1bWVudCBpcyBhZG9wdGVkIGJ5IHRoZSB3b3JraW5nIGdyb3VwLCB0aGUgY2hhaXJzIHNwZWNp ZnkgYXMgcGFydCBvZiB0aGUgYWRvcHRpb24gY2FsbCB0aGF0IHRoZSBmb2xsb3dpbmcgdGV4dCBk ZXNjcmliaW5nIGFuIG9wZW4gaXNzdWUgYmUgYWRkZWQgdG8gdGhlIGRvY3VtZW50IGluIHRoZSBh Ym92ZS1kZXNjcmliZWQgb3BlbiBpc3N1ZXMgc2VjdGlvbjoNCiAgICAgKiAgICJHaXZlbiB0aGF0 IHRoZSB3b3JraW5nIGdyb3VwIGhhcyBzYWlkIHRoYXQgaXQgd2FudHMgdG8gc3RhbmRhcmRpemUg b25lIGRhdGEgcGxhbmUgc29sdXRpb24sIGFuZCBnaXZlbiB0aGF0IHRoZSBkb2N1bWVudCBjb250 YWlucyBtdWx0aXBsZSBTUnY2IEVuZFBvaW50IGJlaGF2aW9ycyB0aGF0IHNvbWUgV0cgbWVtYmVy cyBoYXZlIHN0YXRlZCBhcmUgbXVsdGlwbGUgZGF0YSBwbGFuZSBzb2x1dGlvbnMsIHRoZSB3b3Jr aW5nIGdyb3VwIHdpbGwgYWRkcmVzcyB3aGV0aGVyIHRoaXMgaXMgdmFsaWQgYW5kIGNvaGVyZW50 IHdpdGggaXRzIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uIG9iamVjdGl2ZS4iLg0KDQpQbGVhc2Ug Y29uc2lkZXIgdGhlIGFib3ZlIGd1aWRlbGluZXMgYXMgeW91IGRlY2lkZSBvbiB3aGV0aGVyIHRv IHN1cHBvcnQgb3Igbm90IHRoaXMgV0cgYWRvcHRpb24uIFBsZWFzZSBleHByZXNzIGNsZWFybHkg eW91ciByZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9uLXN1cHBvcnQgYXMgd2VsbCBhcyBhbnkgb3Bl biBkaXNjdXNzaW9uIHBvaW50cyB5b3Ugd291bGQgbGlrZSBhZGRyZXNzZWQgc2hvdWxkIHRoZSBk b2N1bWVudCBiZSBhZG9wdGVkIGludG8gdGhlIHdvcmtpbmcgZ3JvdXAuDQoNClRoYW5rcyENCg0K SmltLCBCcnVubyAmIEpvZWwNCg0KDQrlpoLmnpzmgqjplJnor6/mjqXmlLbkuobor6Xpgq7ku7bv vIzor7fpgJrov4fnlLXlrZDpgq7ku7bnq4vljbPpgJrnn6XmiJHku6zjgILor7flm57lpI3pgq7k u7bliLAgaHFzLXNwbWNAY2hpbmF1bmljb20uY27vvIzljbPlj6/ku6XpgIDorqLmraTpgq7ku7bj gILmiJHku6zlsIbnq4vljbPlsIbmgqjnmoTkv6Hmga/ku47miJHku6znmoTlj5HpgIHnm67lvZXk uK3liKDpmaTjgIIgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVh c2Ugbm90aWZ5IHVzIGltbWVkaWF0ZWx5IGJ5IGUtbWFpbC4gUGxlYXNlIHJlcGx5IHRvIGhxcy1z cG1jQGNoaW5hdW5pY29tLmNuICx5b3UgY2FuIHVuc3Vic2NyaWJlIGZyb20gdGhpcyBtYWlsLiBX ZSB3aWxsIGltbWVkaWF0ZWx5IHJlbW92ZSB5b3VyIGluZm9ybWF0aW9uIGZyb20gc2VuZCBjYXRh bG9ndWUgb2Ygb3VyLg0K --_000_18fefca3fbab4b698bbc909d8de775ecM10HQML10hqcncintra_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5ib2R5IHsgbGluZS1oZWlnaHQ6IDEu NTsgfWJsb2NrcXVvdGUgeyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFy Z2luLWxlZnQ6IDAuNWVtOyB9b2wsIHVsIHsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9t OiAwcHg7IGxpc3Qtc3R5bGUtcG9zaXRpb246IGluc2lkZTsgfXAgeyBtYXJnaW4tdG9wOiAwcHg7 IG1hcmdpbi1ib3R0b206IDBweDsgfWJvZHkgeyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5 OiAiTWljcm9zb2Z0IFlhSGVpIFVJIjsgY29sb3I6IHJnYigwLCAwLCAwKTsgbGluZS1oZWlnaHQ6 IDEuNTsgfWJvZHkgeyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiAiTWljcm9zb2Z0IFlh SGVpIFVJIjsgY29sb3I6IHJnYigwLCAwLCAwKTsgbGluZS1oZWlnaHQ6IDEuNTsgfTwvc3R5bGU+ DQo8L2hlYWQ+DQo8Ym9keT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiA+PC9vOnNoYXBlZGVmYXVsdHM+CjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiA+PC9vOmlkbWFwPgo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmks IHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE0LjY2NjdweDsgdGV4dC1kZWNv cmF0aW9uLXN0eWxlOiBpbml0aWFsOyB0ZXh0LWRlY29yYXRpb24tY29sb3I6IGluaXRpYWw7Ij5I ae+8jFdH77yMPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pjxm b250IGZhY2U9IkNhbGlicmksIHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE0 LjY2NjdweDsiPkkgYW0gc29ycnkgaXQgc2VlbXMgdG9vIGxhdGUgdG8gcmVzcG9uZCB0byB0aGUg YWRvcHRpb24gY2FsbC4gSSB3b3VsZCBsaWtlIHRvIGV4cHJlc3MgbXkgc3VwcG9ydCBmb3IgdGhl IGRyYWZ0LiZuYnNwOzwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2PjxzcGFuIHN0eWxlPSJmb250 LXNpemU6IDE0LjY2NjdweDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGJhY2tn cm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyI+QXMgYW4gb3BlcmF0b3IsIFdlIGRvIG5lZWQgYSBT UkggaGVhZGVyIGNvbXByZXNzaW9uIHN0YW5kYXJkLiBIZW5jZSwgd2XigJlyZSBsb29raW5nIGZv cndhcmQgdG8gYW55IHByb2dyZXNzIGluIGl0Ljwvc3Bhbj48L2Rpdj4NCjxkaXY+DQo8ZGl2Pjxm b250IGZhY2U9IkNhbGlicmksIHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE0 LjY2NjdweDsgdGV4dC1kZWNvcmF0aW9uLXN0eWxlOiBpbml0aWFsOyB0ZXh0LWRlY29yYXRpb24t Y29sb3I6IGluaXRpYWw7Ij48YnI+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBm YWNlPSJDYWxpYnJpLCBzYW5zLXNlcmlmIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxNC42NjY3 cHg7IHRleHQtZGVjb3JhdGlvbi1zdHlsZTogaW5pdGlhbDsgdGV4dC1kZWNvcmF0aW9uLWNvbG9y OiBpbml0aWFsOyI+QmVzdCByZWdhcmRzLDwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250 IGZhY2U9IkNhbGlicmksIHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE0LjY2 NjdweDsgdGV4dC1kZWNvcmF0aW9uLXN0eWxlOiBpbml0aWFsOyB0ZXh0LWRlY29yYXRpb24tY29s b3I6IGluaXRpYWw7Ij5QYW5nIFJhbi48L3NwYW4+PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLVRvcDogMHB4OyBtYXJnaW4tQm90dG9tOiAwcHg7IG1hcmdp bi1MZWZ0OiAwLjVlbTsgbWFyZ2luLVJpZ2h0OiBpbmhlcml0Ij4NCjxkaXY+Jm5ic3A7PC9kaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2IHN0eWxlPSJQQURESU5HLVJJR0hUOiA4 cHg7IFBBRERJTkctTEVGVDogOHB4OyBGT05ULVNJWkU6IDEycHg7Rk9OVC1GQU1JTFk6dGFob21h O0NPTE9SOiMwMDAwMDA7IEJBQ0tHUk9VTkQ6ICNlZmVmZWY7IFBBRERJTkctQk9UVE9NOiA4cHg7 IFBBRERJTkctVE9QOiA4cHgiPg0KPGRpdj48Yj5Gcm9tOjwvYj4mbmJzcDs8YSBocmVmPSJtYWls dG86amFtZXMubi5ndWljaGFyZEBmdXR1cmV3ZWkuY29tIj5KYW1lcyBHdWljaGFyZDwvYT48L2Rp dj4NCjxkaXY+PGI+RGF0ZTo8L2I+Jm5ic3A7MjAyMS0xMC0wMSZuYnNwOzIyOjA0PC9kaXY+DQo8 ZGl2PjxiPlRvOjwvYj4mbmJzcDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5TUFJJ TkcgV0c8L2E+PC9kaXY+DQo8ZGl2PjxiPkNDOjwvYj4mbmJzcDs8YSBocmVmPSJtYWlsdG86c3By aW5nLWNoYWlyc0BpZXRmLm9yZyI+c3ByaW5nLWNoYWlyc0BpZXRmLm9yZzwvYT48L2Rpdj4NCjxk aXY+PGI+U3ViamVjdDo8L2I+Jm5ic3A7W3NwcmluZ10gV0cgQWRvcHRpb24gY2FsbCBmb3IgaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmct c3J2Ni1zcmgtY29tcHJlc3Npb24vPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYg Y2xhc3M9IkZveERpdjIwMjExMDIyMDkxMjEzMTQ2MDIyIiBzdHlsZT0ib3ZlcmZsb3ctd3JhcDog YnJlYWstd29yZDsiPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8bzpzaGFwZWRlZmF1bHRzIHY6 ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiA+PC9vOnNoYXBlZGVmYXVsdHM+CjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRp dCI+CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiA+PC9vOmlkbWFwPgo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxl PSJwYWdlOiBXb3JkU2VjdGlvbjE7Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW46IDBweCAwaW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7Ij4NCkRlYXIgV0c6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luOiAwcHggMGluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyI+DQo8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW46IDBweCAwaW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NClRoZSBjaGFpcnMgd291bGQgbGlrZSB0byBleHBy ZXNzIHRoZWlyIGFwcHJlY2lhdGlvbiBmb3IgYWxsIHRoZSByZXNwb25zZXMgcmVjZWl2ZWQgdG8g b3VyIGVtYWlscyB3aXRoIHJlZmVyZW5jZSB0byBob3cgdGhlIHdvcmtpbmcgZ3JvdXAgd2lzaGVz IHRvIG1vdmUgZm9yd2FyZCB3aXRoIHJlc3BlY3QgdG8gYSBzb2x1dGlvbiBmb3IgU1J2NiBjb21w cmVzc2lvbi4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbjogMHB4IDBpbjsgZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiPg0KPG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luOiAwcHggMGluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyI+DQpUaGUgYXBwYXJlbnQgaW5jbGluYXRpb24gb2YgdGhlIHdvcmtp bmcgZ3JvdXAgaXMgdG8gdXNlIDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLyI+DQpo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmlu Zy1zcnY2LXNyaC1jb21wcmVzc2lvbi88L2E+IGFzIHRoZSBiYXNpcyBmb3IgaXRzIGNvbXByZXNz aW9uIHN0YW5kYXJkaXphdGlvbiB3b3JrLiBUaGF0IGlzIHBhcnQgb2Ygd2hhdCB0aGlzIGVtYWls IGF0dGVtcHRzIHRvIGNvbmZpcm0uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luOiAwcHggMGluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBD YWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBweCAwaW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCkJlY2F1c2Ugb2YgdGhlIGFib3ZlIHRoZSBj aGFpcnMgd291bGQgbGlrZSB0byBpc3N1ZSBhIDItd2VlayBXRyBjYWxsIGZvciBhZG9wdGlvbiBl bmRpbmcgT2N0b2JlciAxNTxzdXA+dGg8L3N1cD4gZm9yDQo8YSBocmVmPSJodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1j b21wcmVzc2lvbi8iPg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZmls c2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24vPC9hPiBidXQgd2l0aCBzb21l IGNsZWFyIGd1aWRlbGluZXMgYXMgZm9sbG93cy4gQnkgZXhwcmVzc2luZyBzdXBwb3J0IGZvciBh ZG9wdGlvbiBvZiB0aGlzIGRvY3VtZW50IHlvdSBhcmUgZnVsbHkgYXdhcmUgb2YgYW5kIGFyZSBh Y2tub3dsZWRnaW5nIHRoYXQ6DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46IDBweCAwaW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7Ij4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPG9sIHN0eWxlPSJt YXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbGlzdC1zdHlsZS1wb3NpdGlvbjog aW5zaWRlOyIgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDBpbiAwLjVpbjsgZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KVGhlIFNQUklORyB3b3JraW5nIGdyb3Vw IGlzIGFkb3B0aW5nIGEgZG9jdW1lbnQgdGhhdCBoYXMgbXVsdGlwbGUgU1J2NiBFbmRwb2ludCBi ZWhhdmlvcnMuDQo8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDBpbiAwLjVpbjsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KVGhlIGRvY3VtZW50IGlzIGEg4oCcbGl2aW5n 4oCdIGRvY3VtZW50OyBpdCBtYXkgY2hhbmdlIGFzIGl0IGdvZXMgdGhyb3VnaCByZXZpZXcgYW5k IGFuYWx5c2lzIGJ5IHRoZSBTUFJJTkcgd29ya2luZyBncm91cC4NCjxvOnA+PC9vOnA+PC9saT48 bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMGluIDAu NWluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+ DQpBbGwgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyByYWlzZWQgb24gb3VyIG1haWxpbmcgbGlzdCBN VVNUIGJlIGFkZHJlc3NlZCBCRUZPUkUgc2FpZCBkb2N1bWVudCBpcyBhbGxvd2VkIHRvIHByb2dy ZXNzIGZyb20gdGhlIHdvcmtpbmcgZ3JvdXAgdG8gcHVibGljYXRpb24uIEEgbGlzdCBvZiB0aGVz ZSBkaXNjdXNzaW9uIHBvaW50cyB3aWxsIGJlIGRvY3VtZW50ZWQgaW4gdGhlIFdHIGRvY3VtZW50 IGFuZCBtYWludGFpbmVkIGJ5IHRoZSBkb2N1bWVudA0KIGVkaXRvciBpbiBjb25qdW5jdGlvbiB3 aXRoIHRoZSBjaGFpcnMuIDxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3Jh cGgiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMGluIDAuNWluOyBmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQpJZiB0aGlzIGRvY3VtZW50IGlzIGFk b3B0ZWQgYnkgdGhlIHdvcmtpbmcgZ3JvdXAsIHRoZSBjaGFpcnMgc3BlY2lmeSBhcyBwYXJ0IG9m IHRoZSBhZG9wdGlvbiBjYWxsIHRoYXQgdGhlIGZvbGxvd2luZyB0ZXh0IGRlc2NyaWJpbmcgYW4g b3BlbiBpc3N1ZSBiZSBhZGRlZCB0byB0aGUgZG9jdW1lbnQgaW4gdGhlIGFib3ZlLWRlc2NyaWJl ZCBvcGVuIGlzc3VlcyBzZWN0aW9uOjxvOnA+PC9vOnA+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6 IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4OyBsaXN0LXN0eWxlLXBvc2l0aW9uOiBpbnNpZGU7IiB0 eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2luOiAwaW47 IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCiZx dW90O0dpdmVuIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgaGFzIHNhaWQgdGhhdCBpdCB3YW50cyB0 byBzdGFuZGFyZGl6ZSBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiwgYW5kIGdpdmVuIHRoYXQgdGhl IGRvY3VtZW50IGNvbnRhaW5zIG11bHRpcGxlIFNSdjYgRW5kUG9pbnQgYmVoYXZpb3JzIHRoYXQg c29tZSBXRyBtZW1iZXJzIGhhdmUgc3RhdGVkIGFyZSBtdWx0aXBsZSBkYXRhIHBsYW5lIHNvbHV0 aW9ucywgdGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhZGRyZXNzDQogd2hldGhlciB0aGlzIGlzIHZh bGlkIGFuZCBjb2hlcmVudCB3aXRoIGl0cyBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiBvYmplY3Rp dmUuJnF1b3Q7LjxvOnA+PC9vOnA+PC9saT48L3VsPg0KPC9saT48L29sPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMHB4IDBpbjsgZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwcHggMGluOyBmb250LXNpemU6IDExcHQ7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQpQbGVhc2UgY29uc2lkZXIgdGhl IGFib3ZlIGd1aWRlbGluZXMgYXMgeW91IGRlY2lkZSBvbiB3aGV0aGVyIHRvIHN1cHBvcnQgb3Ig bm90IHRoaXMgV0cgYWRvcHRpb24uIFBsZWFzZSBleHByZXNzIGNsZWFybHkgeW91ciByZWFzb25p bmcgZm9yIHN1cHBvcnQvbm9uLXN1cHBvcnQgYXMgd2VsbCBhcyBhbnkgb3BlbiBkaXNjdXNzaW9u IHBvaW50cyB5b3Ugd291bGQgbGlrZSBhZGRyZXNzZWQgc2hvdWxkIHRoZSBkb2N1bWVudCBiZSBh ZG9wdGVkIGludG8NCiB0aGUgd29ya2luZyBncm91cC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBweCAwaW47IGZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMHB4IDBpbjsgZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KVGhhbmtzITxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMHB4IDBpbjsgZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwcHgg MGluOyBmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+ DQpKaW0sIEJydW5vICZhbXA7IEpvZWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW46IDBweCAwaW47IGZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7Ij4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMHB4IDBpbjsgZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQrlpoLmnpzmgqjplJnor6/mjqXm lLbkuobor6Xpgq7ku7bvvIzor7fpgJrov4fnlLXlrZDpgq7ku7bnq4vljbPpgJrnn6XmiJHku6zj gILor7flm57lpI3pgq7ku7bliLAmbmJzcDtocXMtc3BtY0BjaGluYXVuaWNvbS5jbu+8jOWNs+WP r+S7pemAgOiuouatpOmCruS7tuOAguaIkeS7rOWwhueri+WNs+WwhuaCqOeahOS/oeaBr+S7juaI keS7rOeahOWPkemAgeebruW9leS4reWIoOmZpOOAgiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdXMgaW1tZWRpYXRlbHkgYnkgZS1tYWlsLiBQ bGVhc2UgcmVwbHkgdG8mbmJzcDtocXMtc3BtY0BjaGluYXVuaWNvbS5jbiZuYnNwOyx5b3UgY2Fu IHVuc3Vic2NyaWJlIGZyb20gdGhpcyBtYWlsLiBXZSB3aWxsIGltbWVkaWF0ZWx5DQogcmVtb3Zl IHlvdXIgaW5mb3JtYXRpb24gZnJvbSBzZW5kIGNhdGFsb2d1ZSBvZiBvdXIuDQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_18fefca3fbab4b698bbc909d8de775ecM10HQML10hqcncintra_-- From nobody Thu Oct 21 20:12:24 2021 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 BC15F3A0AFA; Thu, 21 Oct 2021 20:12:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfqppvO7EaW5; Thu, 21 Oct 2021 20:12:06 -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 C195B3A0AB0; Thu, 21 Oct 2021 20:12:05 -0700 (PDT) Received: from fraeml744-chm.china.huawei.com (unknown [172.18.147.207]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Hb8Rq5Z3Kz67sMs; Fri, 22 Oct 2021 11:08:07 +0800 (CST) Received: from dggpemm500003.china.huawei.com (7.185.36.56) by fraeml744-chm.china.huawei.com (10.206.15.225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Fri, 22 Oct 2021 05:12:01 +0200 Received: from dggpemm500003.china.huawei.com (7.185.36.56) by dggpemm500003.china.huawei.com (7.185.36.56) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.15; Fri, 22 Oct 2021 11:12:00 +0800 Received: from dggpemm500003.china.huawei.com ([7.185.36.56]) by dggpemm500003.china.huawei.com ([7.185.36.56]) with mapi id 15.01.2308.015; Fri, 22 Oct 2021 11:12:00 +0800 From: "Chengli (Cheng Li)" To: Gyan Mishra , "Darren Dukes (ddukes)" CC: "spring@ietf.org" , "ipv6@ietf.org" Thread-Topic: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression Thread-Index: AQHXxKTt3WUDAyZqfEC85Z4zSXmOTqvbzoOAgAEvI4CAAJEZgIAAzL0g Date: Fri, 22 Oct 2021 03:12:00 +0000 Message-ID: <838f3074802b4b67b33b7153d2f7089e@huawei.com> References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <26d9fc32-4884-602c-975a-79fc64551727@gmail.com> In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.112.40.81] Content-Type: multipart/related; boundary="_004_838f3074802b4b67b33b7153d2f7089ehuaweicom_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 22 Oct 2021 03:12:17 -0000 --_004_838f3074802b4b67b33b7153d2f7089ehuaweicom_ Content-Type: multipart/alternative; boundary="_000_838f3074802b4b67b33b7153d2f7089ehuaweicom_" --_000_838f3074802b4b67b33b7153d2f7089ehuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgR3lhbiwNCg0KU29ycnkgSSBkb27igJl0IHVuZGVyc3RhbmQgdGhlIGNhc2UgeW91IG1lbnRp b25lZC4gQ291bGQgeW91IHBsZWFzZSBwcm92aWRlIGFuIGVhc3kgZXhhbXBsZT8gSG93IGEgU0lE IHdpbGwgYmUgc2hpZnRpbmcgaW4gYSBHU0lEIGNvbnRhaW5lcj8NCg0KUmVzcGVjdCwNCkNoZW5n DQoNCg0KRnJvbTogaXB2NiBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIEd5YW4gTWlzaHJhDQpTZW50OiBGcmlkYXksIE9jdG9iZXIgMjIsIDIwMjEgNjo1OCBBTQ0K VG86IERhcnJlbiBEdWtlcyAoZGR1a2VzKSA8ZGR1a2VzPTQwY2lzY28uY29tQGRtYXJjLmlldGYu b3JnPg0KQ2M6IHNwcmluZ0BpZXRmLm9yZzsgaXB2NkBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFR5 cG8gY29ycmVjdGlvbiBSZTogUXVlc3Rpb24gZnJvbSBTUFJJTkcgcmVnYXJkaW5nIGRyYWZ0LWZp bHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uDQoNCg0KDQpIaSBEYXJyZW4N Cg0KV2hhdCBHcmVnIGlzIGFza2luZyBpcyBpZiB0aGUgU0lEIGlzIGEgcHJlZml4IFNJRCBFbmQg YW5kIG5vdCBhZGphY2VuY3kgU0lEIEVuZC54LCBzbyBub3cgdGhlIGNvbW1vbiBwcmVmaXggaXMg bmVlZGVkIHRvIEVDTVAgc3RlZXIgdGhlIGZsb3cgIHRvIHRoZSBwcmVmaXggU0lEIHdoaWNoIHVz ZXMgdGhlIGNvbW1vbiBwcmVmaXgsICB3aGljaCBtYXkgaW4gdGhpcyBjYXNlIGJlIG11dGF0ZWQg ZHVlIHRvIHNoaWZ0aW5nIG9mIFNJRHMgaW4gR1NJRCBjb250YWluZXIuDQoNCg0KS2luZCBSZWdh cmRzDQoNCkd5YW4NCk9uIFRodSwgT2N0IDIxLCAyMDIxIGF0IDEwOjE4IEFNIERhcnJlbiBEdWtl cyAoZGR1a2VzKSA8ZGR1a2VzPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPG1haWx0bzo0MGNp c2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KSGkgR3JlZywNCg0KWW91ciBxdWVzdGlv biBpcyBub3QgY2xlYXIgdG8gbWUuDQpDYW4geW91IHRyeSB0byByZXN0YXRlIGl0IHdpdGggdGhl IGZsYXZvcnMgYW5kIGJlaGF2aW9ycyBmcm9tIHRoZSBkcmFmdCBpbiBxdWVzdGlvbj8NCg0KRGFy cmVuDQoNCk9uIDIwMjEtMTAtMjAsIDQ6MTUgUE0sICJpcHY2IiA8aXB2Ni1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmc+PiB3cm90ZToNCg0KSGkgQnJpYW4sDQpJ J3ZlIGdvdCBzb21lIHF1ZXN0aW9ucyBhYm91dCB3aGF0IHlvdSd2ZSBzYWlkOg0KRm9yIHRoYXQg cmVhc29uLCB0aGUgZmFjdCB0aGF0IHRoZSBib3R0b20gNjQgYml0cyBpbiB0aGUNCiJhZGRyZXNz IiBsb29rIGZ1bm55IG9yIGNoYW5nZSBpcyBzaW1wbHkgaXJyZWxldmFudC4gVGhleSBhcmUNCmlu dmlzaWJsZSB0byByb3V0aW5nICh3aGljaCBpcyBkb25lIGJhc2VkIG9uIHRoZSBwcmVmaXgpDQph bmQgaW52aXNpYmxlIHRvIG5laWdoYm9yIGRpc2NvdmVyeSAoYmVjYXVzZSBpdCBuZXZlciBoYXBw ZW5zKS4NCkFzIEkgdW5kZXJzdGFuZCBpdCwgd2hhdCB5b3UgZGVzY3JpYmUgaXMgdGhlIGNhc2Ug b2YgYSBzdHJpY3QgZXhwbGljaXQgcGF0aCBkZWZpbmVkIHVzaW5nIG9uZSBvZiB0aGUgQy1TSUQg Y29tcHJlc3Npb24gbWV0aG9kcy4gQnV0IEkgYW0gbm90IHN1cmUgdGhhdCB5b3VyIGNvbmNsdXNp b24gYWxzbyBhbHdheXMgYXBwbGllcyB3aGVuIGl0IGlzIGEgbG9vc2UgZXhwbGljaXQgcGF0aCBz cGVjaWZpZWQgaW4gdGhlIGNvbXByZXNzZWQgU2VnbWVudCBMaXN0LiBBcyBhbGwgQy1TSURzIHNo YXJlIHRoZSBzYW1lIHByZWZpeCwgaG93IHJvdXRpbmcgY2FuIGJlIGRvbmUgYmFzZWQgb25seSBv biB0aGF0IHByZWZpeCBhbmQgbm90IHVzaW5nIGEgcGFydCBvZiB0aGF0ICJmdW5ueSIgYm90dG9t IDY0IGJpdHM/IEFuZCBpZiBhbnkgcGFydCBvZiB0aGUgYm90dG9tIDY0IGJpdHMgbXVzdCBiZSB1 c2VkLCBob3cgb25lIGNhbiBndWFyYW50ZWUgdGhhdCBDSURSIHN0aWxsIHdvcmtzIGluIHRoYXQg ZG9tYWluPw0KDQpSZWdhcmRzLA0KR3JlZw0KDQpPbiBNb24sIE9jdCAxOCwgMjAyMSBhdCA5OjUw IFBNIEJyaWFuIEUgQ2FycGVudGVyIDxicmlhbi5lLmNhcnBlbnRlckBnbWFpbC5jb208bWFpbHRv OmJyaWFuLmUuY2FycGVudGVyQGdtYWlsLmNvbT4+IHdyb3RlOg0KSGksDQoNCkFmdGVyIHJlYWRp bmcgYSBsb3Qgb2YgbWVzc2FnZXMsIEknbSBnb2luZyB0byBvZmZlciBteSBjb25zaWRlcmVkDQpv cGluaW9uIGFzIGEgZGlyZWN0IHJlc3BvbnNlIHRvIEpvZWwncyBPUC4NCg0KRmlyc3RseSwgSSBk b24ndCBiZWxpZXZlIHRoYXQgaW4gdGhlIGVuZCB0aGlzIGRyYWZ0IHJhaXNlcyBhbnkNCmNvbmNl cm5zIHRoYXQgYXJlICpzaWduaWZpY2FudGx5KiBkaWZmZXJlbnQgdGhhbiB0aG9zZSByYWlzZWQN CndoZW4gUkZDIDg5ODYgd2FzIGluIGRyYWZ0LiBBcyBUZWQgSGFyZGllIG1lbnRpb25lZCwgc2Vj dGlvbiA1DQpvZiBSRkMgODc1NCBleHBsYWlucyB0aGF0IFNJRHMgb2YgYW55IHNoYXBlIG9yIHNp emUgYXJlIG9ubHkNCm1lYW5pbmdmdWwgd2l0aGluIGFuIFNSIGRvbWFpbi4gVGhhdCBhcHBsaWVz IHRvIHNyaC1jb21wcmVzc2lvbg0KdG9vLg0KDQpTZWNvbmRseSwgSSB3YXMgY29uY2VybmVkIGFi b3V0IGhvdyB0aGVzZSBzdHJhbmdlIGxvb2tpbmcNCiJhZGRyZXNzZXMiIHdvdWxkIHBvdGVudGlh bGx5IGludGVyZmVyZSB3aXRoIG5vcm1hbCBJUHY2DQphZGRyZXNzZXMgYW5kIHRoZWlyIGhhbmRs aW5nIGJ5IG5vcm1hbCBJUHY2IG5vZGVzLiBXZWxsLCBJDQpub3cgYmVsaWV2ZSB0aGF0IHRoZXkg d29uJ3QuIFRoZSByZWFzb24gaXMgdGhhdCBpbiB0aGUgU1IgbW9kZWwNCnRoZXNlICJhZGRyZXNz ZXMiIGFyZSAqbmV2ZXIgdXNlZCBmb3IgZmluYWwgZGVsaXZlcnkgb2YgSVB2Ng0KcGFja2V0cyB0 byBhIGhvc3QuKiBBbGwgU1J2NiBwYXJ0aWNpcGFudHMgYXJlIHJvdXRlcnMuIFRoZQ0KbGFzdCBo b3AgZm9yIGEgcGFja2V0IHdob3NlIERBIGlzIHNldCB0byAoc2F5KSAyMDAxOmRiODphOjE5MDA6 Og0KaXMgKm5vdCogdGhlIGxhc3QgaG9wIG9uIGEgTEFOLCBtZWRpYXRlZCBieSBuZWlnaGJvciBk aXNjb3ZlcnkNCmZvciAyMDAxOmRiODphOjE5MDA6Oi4gSXQncyBqdXN0IGEgaG9wIGZyb20gb25l IHJvdXRlciB0byBhbm90aGVyLA0KdXNpbmcgdGhlIGVudHJ5IGZvciAyMDAxOmRiODphOjE5MDA6 Oi82NCBpbiB0aGUgRklCIG9mIHRoZSBsYXN0DQpyb3V0ZXIgdGhhdCBhY3R1YWxseSBmb3J3YXJk cyB0aGUgcGFja2V0LiAyMDAxOmRiODphOjE5MDA6OiBpcw0Kbm90IGFzc2lnbmVkIHRvIGEgcGh5 c2ljYWwgaW50ZXJmYWNlIHNvIFJGQyA0ODYxIGlzIG5ldmVyIGludm9rZWQuDQoNCkFub3RoZXIg d2F5IHRvIHNheSBpdCBpcyBSRkMgNzYwOCBpcyB0aGUgcmVsZXZhbnQgYXJjaGl0ZWN0dXJhbA0K c3RhbmRhcmQuIENJRFIgcnVsZXMsIGV2ZW4gd2l0aGluIGFuIFNSIGRvbWFpbi4NCg0KRm9yIHRo YXQgcmVhc29uLCB0aGUgZmFjdCB0aGF0IHRoZSBib3R0b20gNjQgYml0cyBpbiB0aGUNCiJhZGRy ZXNzIiBsb29rIGZ1bm55IG9yIGNoYW5nZSBpcyBzaW1wbHkgaXJyZWxldmFudC4gVGhleSBhcmUN CmludmlzaWJsZSB0byByb3V0aW5nICh3aGljaCBpcyBkb25lIGJhc2VkIG9uIHRoZSBwcmVmaXgp DQphbmQgaW52aXNpYmxlIHRvIG5laWdoYm9yIGRpc2NvdmVyeSAoYmVjYXVzZSBpdCBuZXZlciBo YXBwZW5zKS4NCg0KSSBhcG9sb2dpc2UgaWYgdGhpcyBpcyBhbGwgb2J2aW91cyB0byBldmVyeWJv ZHksIGJ1dCBJIG5lZWRlZA0KdG8gc3BlbGwgaXQgb3V0IGZvciBteSBvd24gdW5kZXJzdGFuZGlu Zy4NCg0KTm93IGJhY2sgdG8gSm9lbCdzIHF1ZXN0aW9uczoNCg0KDQpPbiAxMy1PY3QtMjEgMjA6 MzcsIEpvZWwgTS4gSGFscGVybiB3cm90ZToNCj4gVGhlcmUgaXMgYSB0eXBvIGluIHRoZSBiZWxv dyB3aGljaCBpZiBub3QgdW5kZXJzdG9vZCBhcyBhIHR5cG8gd291bGQgYmUNCg0KPiBxdWl0ZSBj b25mdXNpbmcuICAgSSB3cm90ZSB0aGF0IEkgcmFpc2VkIHRoZSBpc3N1ZSB3aXRoDQo+ICJ3aXRo IHRoZSBJbnRlcm5ldCBBRHMgYW5kIFNQUklORyBjaGFpcnMiLg0KPiBUaGF0IHNob3VsZCBoYXZl IHJlYWQgIndpdGggdGhlIEludGVybmV0IEFEcyBhbmQgNm1hbiBjaGFpcnMiLg0KPiBUaGUgU1BS SU5HIGNvLWNoYWlycyBhcmUgcmVjdXNlZCwgYW5kIHRoZSBjaGFydGVyIHJlcXVpcmVtZW50IGxl YWRzIHRvDQo+IHRoZSA2bWFuIGNoYWlycy4gIFdoaWNoIGlzIHdobyBJIHRhbGtlZCB0by4NCj4N Cj4gQWxzbywgSSBhbSBzZW5kaW5nIGEgY291cnRlc3kgY29weSB0byB0aGUgcm91dGluZyBBRHMs IHdoaWNoIEkgc2hvdWxkDQo+IGhhdmUgZG9uZSBvcmlnaW5hbGx5Lg0KPg0KPiBUaGFuayB5b3Ug YW5kIGVuam95Lg0KPiBZb3VycywNCj4gSm9lbA0KPg0KPiBPbiAxMC8xMi8yMDIxIDExOjUyIFBN LCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6DQo+PiBUaGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAgaXMg aW4gdGhlIG1pZHN0IG9mIGFuIGFkb3B0aW9uIGNhbGwgb24NCj4+IGh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXBy ZXNzaW9uLy4NCj4+DQo+Pg0KPj4gVGhlIFNQUklORyBjaGFydGVyIGhhcyB0ZXh0IHRoYXQgaXMg ZXhwbGljaXQgdGhhdCBtb2RpZmljYXRpb25zIHRvIGRhdGENCj4+IHBsYW5lcyBhbmQgYXJjaGl0 ZWN0dXJlcyBzdGFuZGFyZGl6ZWQgYnkgb3RoZXIgd29ya2luZyBncm91cHMgbWF5IG5vdCBiZQ0K Pj4gbW9kaWZpZWQgaW4gU1BSSU5HIHVubGVzcyB0aGUgY2hhaXJzIGFuZCBBRHMgcmVzcG9uc2li bGUgZm9yIHRoYXQgZGF0YQ0KDQo+PiBwbGFuZSBhbmQgLyBvciBhcmNoaXRlY3R1cmUgYWdyZWUu DQo+Pg0KPj4gVG8gY29tcGxldGUgdGhlIGNvbnRleHQsIGFzIG15IFNQUklORyBjby1jaGFpcnMg YXJlIGNvLWF1dGhvcnMgb24gdGhlDQo+PiBkb2N1bWVudCBpbiBxdWVzdGlvbiwgdGhleSBoYXZl IHJlY3VzZWQgdGhlbXNlbHZlcyBmcm9tIGRlY2lzaW9uYWwNCj4+IGFjdGl2aXRpZXMgcmVnYXJk aW5nIHRoZSBkb2N1bWVudC4gIFRoZXJlZm9yZSwgdGhpcyBtZXNzYWdlIGlzIGNvbWluZw0KPj4g anVzdCBmcm9tIG15IGFzIHRoZSByZXNwb25zaWJsZSBTUFJJTkcgY28tY2hhaXIgbWFuYWdpbmcg dGhpcyBhZG9wdGlvbg0KDQo+PiBjYWxsLg0KPj4NCj4+IEFzIHlvdSBoYXZlIHNlZW4sIG11bHRp cGxlIHF1ZXN0aW9ucyBoYXZlIGJlZW4gcmFpc2VkIGFib3V0IHRoZQ0KPj4gcmVsYXRpb25zaGlw IG9mIHRoZSBkb2N1bWVudCB0byB0aGUgSVB2NiBkZWZpbmVkIGRhdGEgcGxhbmUgYW5kDQo+PiBh cmNoaXRlY3R1cmUgKHBhcnRpY3VsYXJseSBSRkMgNDI5MSBhbmQgODIwMCkuIEluIHBhcnRpY3Vs YXIgdGhlDQo+PiBxdWVzdGlvbnMgc2VlbSB0byByZXZvbHZlIGFyb3VuZCB3aGF0IHRoZSBkb2N1 bWVudCBkZXNjcmliZXMgYXMgdGhlDQo+PiBORVhULUMtU0lEIGZsYXZvciBvZiBjb21wcmVzc2Vk IFNJRCwgYW5kIGl0cyByZWxhdGlvbnNoaXAgdG8gdGhlIElQdjYNCj4+IHN0YW5kYXJkcy4gIChG b3IgdGhvc2Ugc2Vla2luZyBtb3JlIGNvbnRleHQgd2l0aG91dCByZWFkaW5nIHRoZSBmdWxsDQo+ PiBkb2N1bWVudCwgYSBwYXJhcGhyYXNlIGFuZCBzaW1wbGlmaWNhdGlvbiBvZiB0aGUgTkVYVC1D X1NJRCBmbGF2b3IgaXMNCj4+IHByb3ZpZGVkIGFzIGEgcG9zdHNjcmlwdC4pDQo+Pg0KPj4gSSBy YWlzZWQgdGhlIHF1ZXN0aW9uIG9mIGNvbmN1cnJlbmNlIGFzIHJlcXVpcmVkIGJ5IHRoZSBTUFJJ TkcgY2hhcnRlcg0KDQo+PiB3aXRoIHRoZSBJbnRlcm5ldCBBRHMgYW5kIFNQUklORyBjaGFpcnMu ICBUaGV5IHF1aXRlIHJlYXNvbmFibHkgYXNrZWQgbWUNCj4+IHRvIHdyaXRlIGEgbm90ZSB0byA2 bWFuIGV4cGxhaW5pbmcgdGhlIGNvbmNlcm5zIGFzIGNsZWFybHkgYXMgYSBjYW4sIHNvDQo+PiB0 aGF0IHRoZXkgY2FuIHRoZW4gZGV0ZXJtaW5lIGhvdyB0byBwcm9jZWVkLg0KPj4NCj4+IFRoZSBx dWVzdGlvbnMgdGhhdCBwcm9tcHRlZCBteSBpbnF1aXJ5IGFyZToNCj4+DQo+PiAxKSBEb2VzIHRo ZSBwbGFjZW1lbnQgb2YgYSBsaXN0IG9mIHNpZHMgaW4gdGhlIElQdjYgREEgZmllbGQgY2hhbmdl IHRoZQ0KPj4gSVB2NiBhcmNoaXRlY3R1cmFsIGRlc2NyaXB0aW9uIG9mIHRoYXQgZmllbGQuDQoN CkkgdGhpbmsgaXQgc2hvdWxkIGJlIG5vdGVkIGV4cGxpY2l0bHkgc29tZXdoZXJlIHRoYXQgc2lu Y2UgdGhlIGNvbnRlbnRzDQpvZiB0aGUgREEgZmllbGQgYXJlICpuZXZlciogdXNlZCBmb3IgbGFz dC1ob3AgbmVpZ2hib3IgZGlzY292ZXJ5LA0KdGhlIElJRCBhc3BlY3Qgb2YgUkZDIDQyOTEgaXMg aXJyZWxldmFudCwgYW5kIFJGQyA0ODYxICsgUkZDIDU5NDINCmFyZSBpcnJlbGV2YW50LiBBbm90 aGVyIGNpdGF0aW9uIGlzIFJGQyA3NjA4OiBmb3Igcm91dGluZywgYWxsIHRoYXQNCmNvdW50cyBp cyB0aGUgcHJlZml4LCBhbmQgaXQgY2FuIGJlIGFueXRoaW5nIHVwIHRvIDEyOC4NCg0KUGVyaGFw cyB0aGlzIHNob3VsZCBoYXZlIGJlZW4gaW4gc2VjdGlvbiA1IG9mIFJGQyA4NzU0LCBidXQgSSBs ZWF2ZQ0KdGhhdCB0byB0aGUgd29yZHNtaXRocy4NCg0KPj4gMikgRG9lcyB0aGUgb3BlcmF0aW9u IG9mIHNoaWZ0aW5nIGluZm9ybWF0aW9uIGFyb3VuZCBpbiB0aGUgSVB2Ng0KPj4gZGVzdGluYXRp b24gYWRkcmVzcyBmaWVsZCByZXByZXNlbnQgYSBtb2RpZmljYXRpb24gb3IgZXh0ZW5zaW9uIG9m IHRoZQ0KDQo+PiBJUHY2IGRhdGEgcGxhbmUuDQoNCk5vLiBBcyBteSB0ZXh0IGFib3ZlIGluZGlj YXRlcywgdGhlIFNSdjYgREEgZmllbGQgaXMgb25seSBldmVyIHVzZWQNCmJ5IHJvdXRpbmcsIHdo ZXJlIFJGQyA3NjA4IHJ1bGVzLiBBbmQgb2YgY291cnNlIGl0IHZhbmlzaGVzIGFzIHNvb24NCmFz IHRoZSBwYWNrZXQgaXMgZGVjYXBzdWxhdGVkLg0KDQpSZWdhcmRzDQogICAgQnJpYW4NCg0KPj4N Cj4+IE9uIGEgcmVsYXRlZCBub3RlLCB0aGUgZG9jdW1lbnQgaW4gcXVlc3Rpb24gYWxzbyBkZWZp bmVzIHR3byBvdGhlcg0KPj4gZmxhdm9ycywgUkVQTEFDRS1DLVNJRCwgYW5kIE5FWFQtYW5kLVJF UExBQ0UtQy1TSUQuICBUaGUNCj4+IE5FWFQtYW5kLVJFUExBQ0UtQ19TSUQgZmxhdm9yIGlzIGRl ZmluZWQgdG8gaW5jbHVkZSB0aGUgTkVYVC1DX1NJRA0KPj4gZmxhdm9yIG9wZXJhdGlvbiwgc28g c2VlbXMgdG8gYmUgYWZmZWN0ZWQgYnkgdGhlIHNhbWUgcXVlc3Rpb24uDQo+Pg0KPj4gIEZyb20g bXkgb3duIHJlYWRpbmcsIGl0IGFwcGVhcnMgdGhhdCB0aGUgUkVQTEFDRS1DLVNJRCBmbGF2b3Ig ZG9lcyBub3QNCj4+IHJhaXNlIGlzc3VlcyByZXF1aXJpbmcgNm1hbiBsZWFkZXJzaGlwIGNvbmN1 cnJlbmNlLg0KPj4NCj4+IFlvdXJzLA0KPj4gSm9lbCBNLiBIYWxwZXJuIGZvciB0aGUgU1BSSU5H IHdvcmtpbmcgZ3JvdXANCj4+DQo+Pg0KPj4gUFM6DQo+PiBDbGVhcmx5LCB1bmRlcnN0YW5kaW5n IHRoZSBxdWVzdGlvbiByZXF1aXJlcyBzb21lIHVuZGVyc3RhbmRpbmcgb2Ygd2hhdA0KPj4gdGhl IE5FWFQtQ19TSUQgZmxhdm9yIGRvZXMuICAgVGhpcyBleHBsYW5hdGlvbiBpcyBhIHNpbXBsaWZp Y2F0aW9uIGZvcg0KPj4gbGVuZ3RoIGFuZCBjb250ZXh0LiAgUmVhbGx5LCB0aGUgYmVzdCBwbGFj ZSB0byB1bmRlcnN0YW5kIGl0IGlzIHRoZQ0KPj4gZHJhZnQuICBIb3dldmVyLCB0byBnaXZlIHlv dSBlbm91Z2ggaW5mb3JtYXRpb24gdG8gbGV0IHlvdSBkZWNpZGUNCg0KPj4gd2hldGhlciB5b3Ug Y2FyZSwgSSB3aWxsIHRyeSB0byBwcm92aWRlIGEgZmFpciBzdW1tYXJ5LiAgTXkgYXBvbG9naWVz IGluDQo+PiBhZHZhbmNlIHRvIHRoZSBhdXRob3JzIGZvciBuZWNlc3NhcnkgbGliZXJ0aWVzIGZv ciBsZW5ndGguICBBbHNvLA0KDQo+PiBkaXNjdXNzaW9uIG9mIHRoZSBkcmFmdCBjb250ZW50cyAo YXMgZGlzdGluY3QgZnJvbSB0aGUgaW50ZXJhY3Rpb24gd2l0aA0KPj4gdGhlIElQdjYgZGF0YSBw bGFuZSBhbmQgYXJjaGl0ZWN0dXJlKSBiZWxvbmdzIG9uIHRoZSBTUFJJTkcgbGlzdCwgYW5kDQo+ PiBzaG91bGQgbm90IGNsdXR0ZXIgdXAgNm1hbi4NCj4+DQo+PiBTSURzIGFyZSB0aGUgaWRlbnRp ZmllcnMgdXNlZCBpbiBzZWdtZW50IHJvdXRpbmcuDQo+PiBJbiBTUnY2LCBhcyBkb2N1bWVudCBp biB0aGUgY3VycmVudCBSRkNzLCB0aGVzZSBhcmUgMTI4IGJpdHMuICAgQXMNCj4+IGRlZmluZWQg aW4gdGhlIHJlbGV2YW50IFJGQ3MsIFNJRHMgd2hpY2ggaWRlbnRpZnkgZW5kcG9pbnRzIHRvIHdo aWNoDQo+PiBwYWNrZXRzIGFyZSBkaXJlY3RlZCBhcmUgaWRlbnRpZmllZCBieSBlbmRwb2ludCBT SURzLiAgVGhlc2UgY2FuIGhhdmUNCj4+IGJlaGF2aW9ycyAoZGVjYXBzdWxhdGUgYW5kIGZvcndh cmQgaXMgb25lIGV4YW1wbGUpLiAgVGhleSBjYW4gaGF2ZQ0KPj4gZmxhdm9ycyBzdWNoIGFzIHdo ZXJlIHRoZSBTUkggaXMgcmVtb3ZlZC4NCj4+DQo+PiBUaGUgdG9waWMgdW5kZXIgZGlzY3Vzc2lv biBpcyBtZWFucyB0byBjb21wcmVzcyB0aGVzZSBTSURzIGluIHRoZQ0KPj4gcGFja2V0cyBvbiB0 aGUgd2lyZS4gIFRoZSBkb2N1bWVudCB1bmRlciBkaXNjdXNzaW9uIHByb3ZpZGVzIHRocmVlDQo+ PiBmbGF2b3JzIG9mIGNvbXByZXNzaW9uLg0KPj4NCj4+IFRoZSBmdW5kYW1lbnRhbCBtZWNoYW5p c20gb2YgdGhlIGRyYWZ0IGlzIHRvIHVzZSBhIHNpbmdsZSBTUkggZW50cnkgYXMNCmENCj4+IGNv bnRhaW5lciBmb3IgbXVsdGlwbGUgU0lEcy4gIEluIHRoZSBORVhULUNfU0lEIG1lY2hhbmlzbSwg d2hlbiBpdCBpcw0KPj4gZmlyc3QgZW5jb3VudGVyZWQgdGhlIGVudGlyZSBjb250YWluZXIgaXMg Y29waWVkIGludG8gdGhlIGRlc2luYXRpb24NCj4+IGFkZHJlc3Mgb2YgdGhlIElQdjYgcGFja2V0 LiAgVGhlIGNvbnRhaW5lciBoYXMgYSBjb21tb24gcm91dGluZyBwcmVmaXgNCj4+IHVzZWQgZm9y IGFsbCB0aGUgTkVYVC1DLVNJRCBTSURzLiAgSXQgaXMgZm9sbG93ZWQgYnkgYSBzZXF1ZW5jZSBv Zg0KPj4gY29tcHJlc3NlZCBTSURzIG9mIGEgY29uZmlndXJlZCBsZW5ndGguICBPbmUgY291bGQg Y29uZmlndXJlIDE2LCAyNCwgb3INCj4+IDMyIGJpdHMuICBPciB3aGF0ZXZlciBsZW5ndGguICBU aGUgcm91dGluZyBhZHZlcnRpc2VtZW50cyBhcmUgYXJyYW5nZWQNCj4+IHNvIHRoYXQgdGhlIElQ djYgcGFja2V0IGlzIGRpcmVjdGVkIHRvIHRoZSBub2RlIHJlcHJlc2VudGVkIGJ5IHRoZSBmaXJz dA0KPj4gY29tcHJlc3NlZCBTSUQgb24gdGhlIGJhc2lzIG9mIGxvbmdlc3QgcHJlZml4IG1hdGNo IG1hdGNoaW5nIHRoZQ0KPj4gY29tYmluYXRpb24gb2YgdGhlIGNvbW1vbiByb3V0aW5nIHByZWZp eCBhbmQgdGhhdCBjb21wcmVzc2VkIFNJRC4NCj4+DQo+PiBXaGVuIHRoZSBwYWNrZXQgYXJyaXZl cyBhdCB0aGF0IG5vZGUsIGl0IGxvb2tzIHVwIHRoZSBjb25maWd1cmVkDQo+PiBwb3J0aW9uLCB0 aGUgY29tcHJlc3NlZCBTSUQsIGFuZCBkZXRlcm1pbmVzIHRoZSBiZWhhdmlvciBhbmQgZmxhdm9y LiAgSW4NCj4+IHRoZSBjYXNlIG9mIHRoZSBORVhULUMtU0lEIGZsYXZvciwgdGhlIHJlc3VsdGlu ZyBvcGVyYXRpb24gaXMgdG8gc2hpZnQNCg0KPj4gdGhlIGVudGlyZSByZW1haW5pbmcgY29udGVu dHMgb2YgdGhlIElQdjYgYWRkcmVzcyAodGhlIGJpdHMgcGFzdCB0aGUNCj4+IGZpcnN0IGNvbXBy ZXNzZWQgc2lkKSBzbyBhcyB0byBvdmVyLXdyaXRlIHRoZSBmaXJzdCBjb21wcmVzc2VkIFNJRC4g IDANCj4+IGJpdHMgYXJlIHNoaWZ0ZWQgaW50byB0aGUgbG93IG9yZGVyIHBvc2l0aW9ucy4gIElm IHRoZSByZXN1bHQgaXMgYQ0KPj4gbm9uLXplcm8gbmV3IGZpcnN0IGNvbXByZXNzZWQgU0lELCB0 aGVuIHRoZSBwYWNrZXRzIGlzIGZvcndhcmRlZCBhbmQgdGhlDQo+PiBwcm9jZXNzIHJlcGVhdHMu ICBXaGVuIGFsbCB0aGF0IGlzIGxlZnQgYXJlIDBzLCBpZiB0aGVyZSBpcyBhbiBTUkgsIGl0DQo+ PiBpcyBjb25zdWx0ZWQgdG8gZmluZCB0aGUgbmV4dCBTUkggZW50cnksIHdoaWNoIGlzLCBwZXIg bm9ybWFsIFNSdjYNCj4+IHByb2Nlc3NpbmcsIHB1dCBpbnRvIHRoZSBJUHY2IERBLg0KPj4gTm90 ZSB0aGF0IGluIHRoZSBjb21tb24gY2FzZSB3aGVyZSB0aGUgU0lEUyBuZWVkZWQgYWxsIGZpdCBp biB0byBhDQo+PiBzaW5nbGUgY29udGFpbmVyLCB0aGUgYW5hbHlzaXMgYWxzbyBhc3N1bWVzIHRo ZSB1c2Ugb2YgdGhlIHJlZHVjZWQNCj4+IGVuY2Fwc3VsYXRpb24gb3B0aW9ucyB3aGljaCBvbWl0 cyB0aGUgU1JIIHRoYXQgaXMgbm90IG5lZWRlZCBhcyBpdCB3b3VsZA0KPj4gaGF2ZSBubyBlbnRy aWVzLiAgVGhpcyB0aGUgcGFja2V0IGNvbnRhaW5zIGEgbm9ybWFsIElQdjYgaGVhZGVyLCB3aXRo IGENCj4+IHNlcXVlbmNlIG9mIGNvbXByZXNzZWQgU0lEcyAod2hhdCBvbmUgbWlnaHQgb3IgbWln aHQgbm90IGNhbGwgYSBzb3VyY2UNCg0KPj4gcm91dGUpIGluIHRoZSBJUHY2IGRlc3RpbmF0aW9u IGFkZHJlc3MgZmllbGQuDQo+Pg0KPj4gUFBTOiBJZiB0aGUgYXV0aG9ycyBvZiB0aGUgTkVYVC1D LVNJRCBmbGF2b3IgZmVlbCBJIGhhdmUgbWlzLXJlcHJlc2VudGVkDQo+PiB0aGUgd29yaywgcGxl YXNlLCBzZW5kIGNsYXJpZmljYXRpb25zIG9yIGNvcnJlY3Rpb25zLiAgIEFnYWluLCB0aGUgYmVz dA0KPj4gc291cmNlIG9mIGluZm9ybWF0aW9uIGlzIHRoZSBkcmFmdCBpdHNlbGYuICBJIHdhcyBh c2tlZCB0byBwcm92aWRlIGV4dHJhDQo+PiBjb250ZXh0IGluIHRoaXMgZW1haWwuDQo+DQo+IC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KPiBpcHY2 QGlldGYub3JnPG1haWx0bzppcHY2QGlldGYub3JnPg0KPiBBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0 czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQo+DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxp c3QNCmlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+DQpBZG1pbmlzdHJhdGl2ZSBS ZXF1ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlz dA0KaXB2NkBpZXRmLm9yZzxtYWlsdG86aXB2NkBpZXRmLm9yZz4NCkFkbWluaXN0cmF0aXZlIFJl cXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCi0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQotLQ0KDQpb5Zu+5YOP5bey6KKr5Y+R5Lu25Lq65Yig6Zmk44CCXTxodHRwOi8vd3d3 LnZlcml6b24uY29tLz4NCg0KR3lhbiBNaXNocmENCg0KTmV0d29yayBTb2x1dGlvbnMgQXJjaGl0 ZWN0DQoNCkVtYWlsIGd5YW4ucy5taXNocmFAdmVyaXpvbi5jb208bWFpbHRvOmd5YW4ucy5taXNo cmFAdmVyaXpvbi5jb20+DQoNCk0gMzAxIDUwMi0xMzQ3DQoNCg== --_000_838f3074802b4b67b33b7153d2f7089ehuaweicom_ 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 eToiXEDlrovkvZMiOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpHZW9yZ2lhOw0KCXBhbm9zZS0xOjIgNCA1IDIgNSA0IDUgMiAzIDM7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6 MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkhpIEd5YW4s PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Tb3JyeSBJIGRvbuKA mXQgdW5kZXJzdGFuZCB0aGUgY2FzZSB5b3UgbWVudGlvbmVkLiBDb3VsZCB5b3UgcGxlYXNlIHBy b3ZpZGUgYW4gZWFzeSBleGFtcGxlPyBIb3cgYSBTSUQgd2lsbCBiZSBzaGlmdGluZyBpbiBhIEdT SUQgY29udGFpbmVyPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ UmVzcGVjdCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q2hlbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+IGlwdjYgW21haWx0bzppcHY2LWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPkd5YW4gTWlzaHJhPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgT2N0b2JlciAy MiwgMjAyMSA2OjU4IEFNPGJyPg0KPGI+VG86PC9iPiBEYXJyZW4gRHVrZXMgKGRkdWtlcykgJmx0 O2RkdWtlcz00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZyZndDs8YnI+DQo8Yj5DYzo8L2I+IHNw cmluZ0BpZXRmLm9yZzsgaXB2NkBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogVHlw byBjb3JyZWN0aW9uIFJlOiBRdWVzdGlvbiBmcm9tIFNQUklORyByZWdhcmRpbmcgZHJhZnQtZmls c2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb248bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgRGFycmVuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgR3JlZyBpcyBhc2tpbmcg aXMgaWYgdGhlIFNJRCBpcyBhIHByZWZpeCBTSUQgRW5kIGFuZCBub3QgYWRqYWNlbmN5IFNJRCBF bmQueCwgc28gbm93IHRoZSBjb21tb24gcHJlZml4IGlzIG5lZWRlZCB0byBFQ01QIHN0ZWVyIHRo ZSBmbG93ICZuYnNwO3RvIHRoZSBwcmVmaXggU0lEIHdoaWNoIHVzZXMgdGhlIGNvbW1vbiBwcmVm aXgsICZuYnNwO3doaWNoIG1heSBpbiB0aGlzIGNhc2UgYmUgbXV0YXRlZCBkdWUgdG8gc2hpZnRp bmcNCiBvZiBTSURzIGluIEdTSUQgY29udGFpbmVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPktpbmQgUmVnYXJkcyZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HeWFuJm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRo dSwgT2N0IDIxLCAyMDIxIGF0IDEwOjE4IEFNIERhcnJlbiBEdWtlcyAoZGR1a2VzKSAmbHQ7ZGR1 a2VzPTxhIGhyZWY9Im1haWx0bzo0MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZyI+NDBjaXNjby5j b21AZG1hcmMuaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSBHcmVn LA0KPHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WW91ciBxdWVzdGlvbiBpcyBub3QgY2xlYXIgdG8g bWUuPHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Q2FuIHlvdSB0cnkgdG8gcmVzdGF0ZSBpdCB3aXRoIHRoZSBmbGF2b3JzIGFu ZCBiZWhhdmlvcnMgZnJvbSB0aGUgZHJhZnQgaW4gcXVlc3Rpb24/PHNwYW4gbGFuZz0iRU4tQ0Ei PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+RGFycmVuPHNwYW4gbGFuZz0iRU4t Q0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PHNwYW4gbGFuZz0iRU4tQ0EiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIj5P biAyMDIxLTEwLTIwLCA0OjE1IFBNLCAmcXVvdDtpcHY2JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86aXB2Ni1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aXB2Ni1ib3VuY2VzQGll dGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLUNB Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPkhpIEJy aWFuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIj5JJ3ZlIGdvdCBzb21lIHF1 ZXN0aW9ucyBhYm91dCB3aGF0IHlvdSd2ZSBzYWlkOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzAuMHB0O21hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQi Pg0KPHNwYW4gbGFuZz0iRU4tQ0EiPkZvciB0aGF0IHJlYXNvbiwgdGhlIGZhY3QgdGhhdCB0aGUg Ym90dG9tIDY0IGJpdHMgaW4gdGhlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi1sZWZ0 OjMwLjBwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoz Ni4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPiZxdW90O2FkZHJlc3MmcXVvdDsgbG9vayBmdW5u eSBvciBjaGFuZ2UgaXMgc2ltcGx5IGlycmVsZXZhbnQuIFRoZXkgYXJlPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1DQSI+aW52aXNpYmxlIHRv IHJvdXRpbmcgKHdoaWNoIGlzIGRvbmUgYmFzZWQgb24gdGhlIHByZWZpeCk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIj5hbmQgaW52aXNp YmxlIHRvIG5laWdoYm9yIGRpc2NvdmVyeSAoYmVjYXVzZSBpdCBuZXZlciBoYXBwZW5zKS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1DQSI+ QXMgSSB1bmRlcnN0YW5kIGl0LCB3aGF0IHlvdSBkZXNjcmliZSBpcyB0aGUgY2FzZSBvZiBhIHN0 cmljdCBleHBsaWNpdCBwYXRoIGRlZmluZWQgdXNpbmcgb25lIG9mIHRoZSBDLVNJRCBjb21wcmVz c2lvbiBtZXRob2RzLiBCdXQgSSBhbSBub3Qgc3VyZSB0aGF0IHlvdXIgY29uY2x1c2lvbiBhbHNv IGFsd2F5cyBhcHBsaWVzIHdoZW4gaXQgaXMgYSBsb29zZSBleHBsaWNpdCBwYXRoIHNwZWNpZmll ZCBpbiB0aGUgY29tcHJlc3NlZA0KIFNlZ21lbnQgTGlzdC4gQXMgYWxsIEMtU0lEcyBzaGFyZSB0 aGUgc2FtZSBwcmVmaXgsIGhvdyByb3V0aW5nIGNhbiBiZSBkb25lIGJhc2VkIG9ubHkgb24gdGhh dCBwcmVmaXggYW5kIG5vdCB1c2luZyBhIHBhcnQgb2YgdGhhdCAmcXVvdDtmdW5ueSZxdW90OyBi b3R0b20gNjQgYml0cz8gQW5kIGlmIGFueSBwYXJ0IG9mIHRoZSBib3R0b20gNjQgYml0cyBtdXN0 IGJlIHVzZWQsIGhvdyBvbmUmbmJzcDtjYW4gZ3VhcmFudGVlIHRoYXQgQ0lEUiBzdGlsbCB3b3Jr cyBpbiB0aGF0DQogZG9tYWluPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIj5SZWdhcmRz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPkdyZWc8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1DQSI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxl ZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVOLUNBIj5PbiBNb24sIE9jdCAxOCwgMjAyMSBhdCA5 OjUwIFBNIEJyaWFuIEUgQ2FycGVudGVyICZsdDs8YSBocmVmPSJtYWlsdG86YnJpYW4uZS5jYXJw ZW50ZXJAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YnJpYW4uZS5jYXJwZW50ZXJAZ21haWwu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tQ0EiPkhpLDxicj4N Cjxicj4NCkFmdGVyIHJlYWRpbmcgYSBsb3Qgb2YgbWVzc2FnZXMsIEknbSBnb2luZyB0byBvZmZl ciBteSBjb25zaWRlcmVkPGJyPg0Kb3BpbmlvbiBhcyBhIGRpcmVjdCByZXNwb25zZSB0byBKb2Vs J3MgT1AuPGJyPg0KPGJyPg0KRmlyc3RseSwgSSBkb24ndCBiZWxpZXZlIHRoYXQgaW4gdGhlIGVu ZCB0aGlzIGRyYWZ0IHJhaXNlcyBhbnk8YnI+DQpjb25jZXJucyB0aGF0IGFyZSAqc2lnbmlmaWNh bnRseSogZGlmZmVyZW50IHRoYW4gdGhvc2UgcmFpc2VkPGJyPg0Kd2hlbiBSRkMgODk4NiB3YXMg aW4gZHJhZnQuIEFzIFRlZCBIYXJkaWUgbWVudGlvbmVkLCBzZWN0aW9uIDU8YnI+DQpvZiBSRkMg ODc1NCBleHBsYWlucyB0aGF0IFNJRHMgb2YgYW55IHNoYXBlIG9yIHNpemUgYXJlIG9ubHk8YnI+ DQptZWFuaW5nZnVsIHdpdGhpbiBhbiBTUiBkb21haW4uIFRoYXQgYXBwbGllcyB0byBzcmgtY29t cHJlc3Npb248YnI+DQp0b28uPGJyPg0KPGJyPg0KU2Vjb25kbHksIEkgd2FzIGNvbmNlcm5lZCBh Ym91dCBob3cgdGhlc2Ugc3RyYW5nZSBsb29raW5nPGJyPg0KJnF1b3Q7YWRkcmVzc2VzJnF1b3Q7 IHdvdWxkIHBvdGVudGlhbGx5IGludGVyZmVyZSB3aXRoIG5vcm1hbCBJUHY2PGJyPg0KYWRkcmVz c2VzIGFuZCB0aGVpciBoYW5kbGluZyBieSBub3JtYWwgSVB2NiBub2Rlcy4gV2VsbCwgSTxicj4N Cm5vdyBiZWxpZXZlIHRoYXQgdGhleSB3b24ndC4gVGhlIHJlYXNvbiBpcyB0aGF0IGluIHRoZSBT UiBtb2RlbDxicj4NCnRoZXNlICZxdW90O2FkZHJlc3NlcyZxdW90OyBhcmUgKm5ldmVyIHVzZWQg Zm9yIGZpbmFsIGRlbGl2ZXJ5IG9mIElQdjY8YnI+DQpwYWNrZXRzIHRvIGEgaG9zdC4qIEFsbCBT UnY2IHBhcnRpY2lwYW50cyBhcmUgcm91dGVycy4gVGhlPGJyPg0KbGFzdCBob3AgZm9yIGEgcGFj a2V0IHdob3NlIERBIGlzIHNldCB0byAoc2F5KSAyMDAxOmRiODphOjE5MDA6Ojxicj4NCmlzICpu b3QqIHRoZSBsYXN0IGhvcCBvbiBhIExBTiwgbWVkaWF0ZWQgYnkgbmVpZ2hib3IgZGlzY292ZXJ5 PGJyPg0KZm9yIDIwMDE6ZGI4OmE6MTkwMDo6LiBJdCdzIGp1c3QgYSBob3AgZnJvbSBvbmUgcm91 dGVyIHRvIGFub3RoZXIsPGJyPg0KdXNpbmcgdGhlIGVudHJ5IGZvciAyMDAxOmRiODphOjE5MDA6 Oi82NCBpbiB0aGUgRklCIG9mIHRoZSBsYXN0PGJyPg0Kcm91dGVyIHRoYXQgYWN0dWFsbHkgZm9y d2FyZHMgdGhlIHBhY2tldC4gMjAwMTpkYjg6YToxOTAwOjogaXM8YnI+DQpub3QgYXNzaWduZWQg dG8gYSBwaHlzaWNhbCBpbnRlcmZhY2Ugc28gUkZDIDQ4NjEgaXMgbmV2ZXIgaW52b2tlZC48YnI+ DQo8YnI+DQpBbm90aGVyIHdheSB0byBzYXkgaXQgaXMgUkZDIDc2MDggaXMgdGhlIHJlbGV2YW50 IGFyY2hpdGVjdHVyYWw8YnI+DQpzdGFuZGFyZC4gQ0lEUiBydWxlcywgZXZlbiB3aXRoaW4gYW4g U1IgZG9tYWluLjxicj4NCjxicj4NCkZvciB0aGF0IHJlYXNvbiwgdGhlIGZhY3QgdGhhdCB0aGUg Ym90dG9tIDY0IGJpdHMgaW4gdGhlPGJyPg0KJnF1b3Q7YWRkcmVzcyZxdW90OyBsb29rIGZ1bm55 IG9yIGNoYW5nZSBpcyBzaW1wbHkgaXJyZWxldmFudC4gVGhleSBhcmU8YnI+DQppbnZpc2libGUg dG8gcm91dGluZyAod2hpY2ggaXMgZG9uZSBiYXNlZCBvbiB0aGUgcHJlZml4KTxicj4NCmFuZCBp bnZpc2libGUgdG8gbmVpZ2hib3IgZGlzY292ZXJ5IChiZWNhdXNlIGl0IG5ldmVyIGhhcHBlbnMp Ljxicj4NCjxicj4NCkkgYXBvbG9naXNlIGlmIHRoaXMgaXMgYWxsIG9idmlvdXMgdG8gZXZlcnli b2R5LCBidXQgSSBuZWVkZWQ8YnI+DQp0byBzcGVsbCBpdCBvdXQgZm9yIG15IG93biB1bmRlcnN0 YW5kaW5nLjxicj4NCjxicj4NCk5vdyBiYWNrIHRvIEpvZWwncyBxdWVzdGlvbnM6PGJyPg0KPGJy Pg0KPGJyPg0KT24gMTMtT2N0LTIxIDIwOjM3LCBKb2VsIE0uIEhhbHBlcm4gd3JvdGU6PGJyPg0K Jmd0OyBUaGVyZSBpcyBhIHR5cG8gaW4gdGhlIGJlbG93IHdoaWNoIGlmIG5vdCB1bmRlcnN0b29k IGFzIGEgdHlwbyB3b3VsZCBiZSA8YnI+DQo8YnI+DQomZ3Q7IHF1aXRlIGNvbmZ1c2luZy4mbmJz cDsgJm5ic3A7SSB3cm90ZSB0aGF0IEkgcmFpc2VkIHRoZSBpc3N1ZSB3aXRoPGJyPg0KJmd0OyAm cXVvdDt3aXRoIHRoZSBJbnRlcm5ldCBBRHMgYW5kIFNQUklORyBjaGFpcnMmcXVvdDsuPGJyPg0K Jmd0OyBUaGF0IHNob3VsZCBoYXZlIHJlYWQgJnF1b3Q7d2l0aCB0aGUgSW50ZXJuZXQgQURzIGFu ZCA2bWFuIGNoYWlycyZxdW90Oy48YnI+DQomZ3Q7IFRoZSBTUFJJTkcgY28tY2hhaXJzIGFyZSBy ZWN1c2VkLCBhbmQgdGhlIGNoYXJ0ZXIgcmVxdWlyZW1lbnQgbGVhZHMgdG8gPGJyPg0KJmd0OyB0 aGUgNm1hbiBjaGFpcnMuJm5ic3A7IFdoaWNoIGlzIHdobyBJIHRhbGtlZCB0by48YnI+DQomZ3Q7 IDxicj4NCiZndDsgQWxzbywgSSBhbSBzZW5kaW5nIGEgY291cnRlc3kgY29weSB0byB0aGUgcm91 dGluZyBBRHMsIHdoaWNoIEkgc2hvdWxkIDxicj4NCiZndDsgaGF2ZSBkb25lIG9yaWdpbmFsbHku PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rIHlvdSBhbmQgZW5qb3kuPGJyPg0KJmd0OyBZb3Vy cyw8YnI+DQomZ3Q7IEpvZWw8YnI+DQomZ3Q7IDxicj4NCiZndDsgT24gMTAvMTIvMjAyMSAxMTo1 MiBQTSwgSm9lbCBNLiBIYWxwZXJuIHdyb3RlOjxicj4NCiZndDsmZ3Q7IFRoZSBTUFJJTkcgd29y a2luZyBncm91cCBpcyBpbiB0aGUgbWlkc3Qgb2YgYW4gYWRvcHRpb24gY2FsbCBvbiA8YnI+DQom Z3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1m aWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8iIHRhcmdldD0iX2JsYW5r Ij4NCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZpbHNmaWxzY2hlbmct c3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9uLzwvYT4uDQo8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIFNQUklORyBjaGFydGVyIGhhcyB0ZXh0IHRoYXQgaXMg ZXhwbGljaXQgdGhhdCBtb2RpZmljYXRpb25zIHRvIGRhdGEgPGJyPg0KJmd0OyZndDsgcGxhbmVz IGFuZCBhcmNoaXRlY3R1cmVzIHN0YW5kYXJkaXplZCBieSBvdGhlciB3b3JraW5nIGdyb3VwcyBt YXkgbm90IGJlIDxicj4NCiZndDsmZ3Q7IG1vZGlmaWVkIGluIFNQUklORyB1bmxlc3MgdGhlIGNo YWlycyBhbmQgQURzIHJlc3BvbnNpYmxlIGZvciB0aGF0IGRhdGEgPGJyPg0KPGJyPg0KJmd0OyZn dDsgcGxhbmUgYW5kIC8gb3IgYXJjaGl0ZWN0dXJlIGFncmVlLjxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsgVG8gY29tcGxldGUgdGhlIGNvbnRleHQsIGFzIG15IFNQUklORyBjby1jaGFpcnMg YXJlIGNvLWF1dGhvcnMgb24gdGhlIDxicj4NCiZndDsmZ3Q7IGRvY3VtZW50IGluIHF1ZXN0aW9u LCB0aGV5IGhhdmUgcmVjdXNlZCB0aGVtc2VsdmVzIGZyb20gZGVjaXNpb25hbCA8YnI+DQomZ3Q7 Jmd0OyBhY3Rpdml0aWVzIHJlZ2FyZGluZyB0aGUgZG9jdW1lbnQuJm5ic3A7IFRoZXJlZm9yZSwg dGhpcyBtZXNzYWdlIGlzIGNvbWluZyA8YnI+DQomZ3Q7Jmd0OyBqdXN0IGZyb20gbXkgYXMgdGhl IHJlc3BvbnNpYmxlIFNQUklORyBjby1jaGFpciBtYW5hZ2luZyB0aGlzIGFkb3B0aW9uIDxicj4N Cjxicj4NCiZndDsmZ3Q7IGNhbGwuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBBcyB5b3Ug aGF2ZSBzZWVuLCBtdWx0aXBsZSBxdWVzdGlvbnMgaGF2ZSBiZWVuIHJhaXNlZCBhYm91dCB0aGUg PGJyPg0KJmd0OyZndDsgcmVsYXRpb25zaGlwIG9mIHRoZSBkb2N1bWVudCB0byB0aGUgSVB2NiBk ZWZpbmVkIGRhdGEgcGxhbmUgYW5kIDxicj4NCiZndDsmZ3Q7IGFyY2hpdGVjdHVyZSAocGFydGlj dWxhcmx5IFJGQyA0MjkxIGFuZCA4MjAwKS4gSW4gcGFydGljdWxhciB0aGUgPGJyPg0KJmd0OyZn dDsgcXVlc3Rpb25zIHNlZW0gdG8gcmV2b2x2ZSBhcm91bmQgd2hhdCB0aGUgZG9jdW1lbnQgZGVz Y3JpYmVzIGFzIHRoZSA8YnI+DQomZ3Q7Jmd0OyBORVhULUMtU0lEIGZsYXZvciBvZiBjb21wcmVz c2VkIFNJRCwgYW5kIGl0cyByZWxhdGlvbnNoaXAgdG8gdGhlIElQdjYgPGJyPg0KJmd0OyZndDsg c3RhbmRhcmRzLiZuYnNwOyAoRm9yIHRob3NlIHNlZWtpbmcgbW9yZSBjb250ZXh0IHdpdGhvdXQg cmVhZGluZyB0aGUgZnVsbCA8YnI+DQomZ3Q7Jmd0OyBkb2N1bWVudCwgYSBwYXJhcGhyYXNlIGFu ZCBzaW1wbGlmaWNhdGlvbiBvZiB0aGUgTkVYVC1DX1NJRCBmbGF2b3IgaXMgPGJyPg0KJmd0OyZn dDsgcHJvdmlkZWQgYXMgYSBwb3N0c2NyaXB0Lik8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 IEkgcmFpc2VkIHRoZSBxdWVzdGlvbiBvZiBjb25jdXJyZW5jZSBhcyByZXF1aXJlZCBieSB0aGUg U1BSSU5HIGNoYXJ0ZXIgPGJyPg0KPGJyPg0KJmd0OyZndDsgd2l0aCB0aGUgSW50ZXJuZXQgQURz IGFuZCBTUFJJTkcgY2hhaXJzLiZuYnNwOyBUaGV5IHF1aXRlIHJlYXNvbmFibHkgYXNrZWQgbWUg PGJyPg0KJmd0OyZndDsgdG8gd3JpdGUgYSBub3RlIHRvIDZtYW4gZXhwbGFpbmluZyB0aGUgY29u Y2VybnMgYXMgY2xlYXJseSBhcyBhIGNhbiwgc28gPGJyPg0KJmd0OyZndDsgdGhhdCB0aGV5IGNh biB0aGVuIGRldGVybWluZSBob3cgdG8gcHJvY2VlZC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7IFRoZSBxdWVzdGlvbnMgdGhhdCBwcm9tcHRlZCBteSBpbnF1aXJ5IGFyZTo8YnI+DQomZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7IDEpIERvZXMgdGhlIHBsYWNlbWVudCBvZiBhIGxpc3Qgb2Ygc2lk cyBpbiB0aGUgSVB2NiBEQSBmaWVsZCBjaGFuZ2UgdGhlIDxicj4NCiZndDsmZ3Q7IElQdjYgYXJj aGl0ZWN0dXJhbCBkZXNjcmlwdGlvbiBvZiB0aGF0IGZpZWxkLjxicj4NCjxicj4NCkkgdGhpbmsg aXQgc2hvdWxkIGJlIG5vdGVkIGV4cGxpY2l0bHkgc29tZXdoZXJlIHRoYXQgc2luY2UgdGhlIGNv bnRlbnRzPGJyPg0Kb2YgdGhlIERBIGZpZWxkIGFyZSAqbmV2ZXIqIHVzZWQgZm9yIGxhc3QtaG9w IG5laWdoYm9yIGRpc2NvdmVyeSw8YnI+DQp0aGUgSUlEIGFzcGVjdCBvZiBSRkMgNDI5MSBpcyBp cnJlbGV2YW50LCBhbmQgUkZDIDQ4NjEgJiM0MzsgUkZDIDU5NDI8YnI+DQphcmUgaXJyZWxldmFu dC4gQW5vdGhlciBjaXRhdGlvbiBpcyBSRkMgNzYwODogZm9yIHJvdXRpbmcsIGFsbCB0aGF0PGJy Pg0KY291bnRzIGlzIHRoZSBwcmVmaXgsIGFuZCBpdCBjYW4gYmUgYW55dGhpbmcgdXAgdG8gMTI4 Ljxicj4NCjxicj4NClBlcmhhcHMgdGhpcyBzaG91bGQgaGF2ZSBiZWVuIGluIHNlY3Rpb24gNSBv ZiBSRkMgODc1NCwgYnV0IEkgbGVhdmU8YnI+DQp0aGF0IHRvIHRoZSB3b3Jkc21pdGhzLjxicj4N Cjxicj4NCiZndDsmZ3Q7IDIpIERvZXMgdGhlIG9wZXJhdGlvbiBvZiBzaGlmdGluZyBpbmZvcm1h dGlvbiBhcm91bmQgaW4gdGhlIElQdjYgPGJyPg0KJmd0OyZndDsgZGVzdGluYXRpb24gYWRkcmVz cyBmaWVsZCByZXByZXNlbnQgYSBtb2RpZmljYXRpb24gb3IgZXh0ZW5zaW9uIG9mIHRoZSA8YnI+ DQo8YnI+DQomZ3Q7Jmd0OyBJUHY2IGRhdGEgcGxhbmUuPGJyPg0KPGJyPg0KTm8uIEFzIG15IHRl eHQgYWJvdmUgaW5kaWNhdGVzLCB0aGUgU1J2NiBEQSBmaWVsZCBpcyBvbmx5IGV2ZXIgdXNlZDxi cj4NCmJ5IHJvdXRpbmcsIHdoZXJlIFJGQyA3NjA4IHJ1bGVzLiBBbmQgb2YgY291cnNlIGl0IHZh bmlzaGVzIGFzIHNvb248YnI+DQphcyB0aGUgcGFja2V0IGlzIGRlY2Fwc3VsYXRlZC4gPGJyPg0K PGJyPg0KUmVnYXJkczxicj4NCiZuYnNwOyAmbmJzcDsgQnJpYW48YnI+DQo8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7IE9uIGEgcmVsYXRlZCBub3RlLCB0aGUgZG9jdW1lbnQgaW4gcXVlc3Rp b24gYWxzbyBkZWZpbmVzIHR3byBvdGhlciA8YnI+DQomZ3Q7Jmd0OyBmbGF2b3JzLCBSRVBMQUNF LUMtU0lELCBhbmQgTkVYVC1hbmQtUkVQTEFDRS1DLVNJRC4mbmJzcDsgVGhlIDxicj4NCiZndDsm Z3Q7IE5FWFQtYW5kLVJFUExBQ0UtQ19TSUQgZmxhdm9yIGlzIGRlZmluZWQgdG8gaW5jbHVkZSB0 aGUgTkVYVC1DX1NJRCA8YnI+DQomZ3Q7Jmd0OyBmbGF2b3Igb3BlcmF0aW9uLCBzbyBzZWVtcyB0 byBiZSBhZmZlY3RlZCBieSB0aGUgc2FtZSBxdWVzdGlvbi48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jm5ic3A7IEZyb20gbXkgb3duIHJlYWRpbmcsIGl0IGFwcGVhcnMgdGhhdCB0aGUgUkVQ TEFDRS1DLVNJRCBmbGF2b3IgZG9lcyBub3QgPGJyPg0KJmd0OyZndDsgcmFpc2UgaXNzdWVzIHJl cXVpcmluZyA2bWFuIGxlYWRlcnNoaXAgY29uY3VycmVuY2UuPGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyBZb3Vycyw8YnI+DQomZ3Q7Jmd0OyBKb2VsIE0uIEhhbHBlcm4gZm9yIHRoZSBTUFJJ Tkcgd29ya2luZyBncm91cDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyBQUzo8YnI+DQomZ3Q7Jmd0OyBDbGVhcmx5LCB1bmRlcnN0YW5kaW5nIHRoZSBxdWVzdGlvbiBy ZXF1aXJlcyBzb21lIHVuZGVyc3RhbmRpbmcgb2Ygd2hhdCA8YnI+DQomZ3Q7Jmd0OyB0aGUgTkVY VC1DX1NJRCBmbGF2b3IgZG9lcy4mbmJzcDsmbmJzcDsgVGhpcyBleHBsYW5hdGlvbiBpcyBhIHNp bXBsaWZpY2F0aW9uIGZvciA8YnI+DQomZ3Q7Jmd0OyBsZW5ndGggYW5kIGNvbnRleHQuJm5ic3A7 IFJlYWxseSwgdGhlIGJlc3QgcGxhY2UgdG8gdW5kZXJzdGFuZCBpdCBpcyB0aGUgPGJyPg0KJmd0 OyZndDsgZHJhZnQuJm5ic3A7IEhvd2V2ZXIsIHRvIGdpdmUgeW91IGVub3VnaCBpbmZvcm1hdGlv biB0byBsZXQgeW91IGRlY2lkZSA8YnI+DQo8YnI+DQomZ3Q7Jmd0OyB3aGV0aGVyIHlvdSBjYXJl LCBJIHdpbGwgdHJ5IHRvIHByb3ZpZGUgYSBmYWlyIHN1bW1hcnkuJm5ic3A7IE15IGFwb2xvZ2ll cyBpbiA8YnI+DQomZ3Q7Jmd0OyBhZHZhbmNlIHRvIHRoZSBhdXRob3JzIGZvciBuZWNlc3Nhcnkg bGliZXJ0aWVzIGZvciBsZW5ndGguJm5ic3A7IEFsc28sIDxicj4NCjxicj4NCiZndDsmZ3Q7IGRp c2N1c3Npb24gb2YgdGhlIGRyYWZ0IGNvbnRlbnRzIChhcyBkaXN0aW5jdCBmcm9tIHRoZSBpbnRl cmFjdGlvbiB3aXRoIDxicj4NCiZndDsmZ3Q7IHRoZSBJUHY2IGRhdGEgcGxhbmUgYW5kIGFyY2hp dGVjdHVyZSkgYmVsb25ncyBvbiB0aGUgU1BSSU5HIGxpc3QsIGFuZCA8YnI+DQomZ3Q7Jmd0OyBz aG91bGQgbm90IGNsdXR0ZXIgdXAgNm1hbi48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFNJ RHMgYXJlIHRoZSBpZGVudGlmaWVycyB1c2VkIGluIHNlZ21lbnQgcm91dGluZy48YnI+DQomZ3Q7 Jmd0OyBJbiBTUnY2LCBhcyBkb2N1bWVudCBpbiB0aGUgY3VycmVudCBSRkNzLCB0aGVzZSBhcmUg MTI4IGJpdHMuJm5ic3A7Jm5ic3A7IEFzIDxicj4NCiZndDsmZ3Q7IGRlZmluZWQgaW4gdGhlIHJl bGV2YW50IFJGQ3MsIFNJRHMgd2hpY2ggaWRlbnRpZnkgZW5kcG9pbnRzIHRvIHdoaWNoIDxicj4N CiZndDsmZ3Q7IHBhY2tldHMgYXJlIGRpcmVjdGVkIGFyZSBpZGVudGlmaWVkIGJ5IGVuZHBvaW50 IFNJRHMuJm5ic3A7IFRoZXNlIGNhbiBoYXZlIDxicj4NCiZndDsmZ3Q7IGJlaGF2aW9ycyAoZGVj YXBzdWxhdGUgYW5kIGZvcndhcmQgaXMgb25lIGV4YW1wbGUpLiZuYnNwOyBUaGV5IGNhbiBoYXZl IDxicj4NCiZndDsmZ3Q7IGZsYXZvcnMgc3VjaCBhcyB3aGVyZSB0aGUgU1JIIGlzIHJlbW92ZWQu PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyBUaGUgdG9waWMgdW5kZXIgZGlzY3Vzc2lvbiBp cyBtZWFucyB0byBjb21wcmVzcyB0aGVzZSBTSURzIGluIHRoZSA8YnI+DQomZ3Q7Jmd0OyBwYWNr ZXRzIG9uIHRoZSB3aXJlLiZuYnNwOyBUaGUgZG9jdW1lbnQgdW5kZXIgZGlzY3Vzc2lvbiBwcm92 aWRlcyB0aHJlZSA8YnI+DQomZ3Q7Jmd0OyBmbGF2b3JzIG9mIGNvbXByZXNzaW9uLjxicj4NCiZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhlIGZ1bmRhbWVudGFsIG1lY2hhbmlzbSBvZiB0aGUgZHJh ZnQgaXMgdG8gdXNlIGEgc2luZ2xlIFNSSCBlbnRyeSBhcyA8YnI+DQphIDxicj4NCiZndDsmZ3Q7 IGNvbnRhaW5lciBmb3IgbXVsdGlwbGUgU0lEcy4mbmJzcDsgSW4gdGhlIE5FWFQtQ19TSUQgbWVj aGFuaXNtLCB3aGVuIGl0IGlzIDxicj4NCiZndDsmZ3Q7IGZpcnN0IGVuY291bnRlcmVkIHRoZSBl bnRpcmUgY29udGFpbmVyIGlzIGNvcGllZCBpbnRvIHRoZSBkZXNpbmF0aW9uIDxicj4NCiZndDsm Z3Q7IGFkZHJlc3Mgb2YgdGhlIElQdjYgcGFja2V0LiZuYnNwOyBUaGUgY29udGFpbmVyIGhhcyBh IGNvbW1vbiByb3V0aW5nIHByZWZpeCA8YnI+DQomZ3Q7Jmd0OyB1c2VkIGZvciBhbGwgdGhlIE5F WFQtQy1TSUQgU0lEcy4mbmJzcDsgSXQgaXMgZm9sbG93ZWQgYnkgYSBzZXF1ZW5jZSBvZiA8YnI+ DQomZ3Q7Jmd0OyBjb21wcmVzc2VkIFNJRHMgb2YgYSBjb25maWd1cmVkIGxlbmd0aC4mbmJzcDsg T25lIGNvdWxkIGNvbmZpZ3VyZSAxNiwgMjQsIG9yIDxicj4NCiZndDsmZ3Q7IDMyIGJpdHMuJm5i c3A7IE9yIHdoYXRldmVyIGxlbmd0aC4mbmJzcDsgVGhlIHJvdXRpbmcgYWR2ZXJ0aXNlbWVudHMg YXJlIGFycmFuZ2VkIDxicj4NCiZndDsmZ3Q7IHNvIHRoYXQgdGhlIElQdjYgcGFja2V0IGlzIGRp cmVjdGVkIHRvIHRoZSBub2RlIHJlcHJlc2VudGVkIGJ5IHRoZSBmaXJzdCA8YnI+DQomZ3Q7Jmd0 OyBjb21wcmVzc2VkIFNJRCBvbiB0aGUgYmFzaXMgb2YgbG9uZ2VzdCBwcmVmaXggbWF0Y2ggbWF0 Y2hpbmcgdGhlIDxicj4NCiZndDsmZ3Q7IGNvbWJpbmF0aW9uIG9mIHRoZSBjb21tb24gcm91dGlu ZyBwcmVmaXggYW5kIHRoYXQgY29tcHJlc3NlZCBTSUQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyBXaGVuIHRoZSBwYWNrZXQgYXJyaXZlcyBhdCB0aGF0IG5vZGUsIGl0IGxvb2tzIHVwIHRo ZSBjb25maWd1cmVkIDxicj4NCiZndDsmZ3Q7IHBvcnRpb24sIHRoZSBjb21wcmVzc2VkIFNJRCwg YW5kIGRldGVybWluZXMgdGhlIGJlaGF2aW9yIGFuZCBmbGF2b3IuJm5ic3A7IEluIDxicj4NCiZn dDsmZ3Q7IHRoZSBjYXNlIG9mIHRoZSBORVhULUMtU0lEIGZsYXZvciwgdGhlIHJlc3VsdGluZyBv cGVyYXRpb24gaXMgdG8gc2hpZnQgPGJyPg0KPGJyPg0KJmd0OyZndDsgdGhlIGVudGlyZSByZW1h aW5pbmcgY29udGVudHMgb2YgdGhlIElQdjYgYWRkcmVzcyAodGhlIGJpdHMgcGFzdCB0aGUgPGJy Pg0KJmd0OyZndDsgZmlyc3QgY29tcHJlc3NlZCBzaWQpIHNvIGFzIHRvIG92ZXItd3JpdGUgdGhl IGZpcnN0IGNvbXByZXNzZWQgU0lELiZuYnNwOyAwIDxicj4NCiZndDsmZ3Q7IGJpdHMgYXJlIHNo aWZ0ZWQgaW50byB0aGUgbG93IG9yZGVyIHBvc2l0aW9ucy4mbmJzcDsgSWYgdGhlIHJlc3VsdCBp cyBhIDxicj4NCiZndDsmZ3Q7IG5vbi16ZXJvIG5ldyBmaXJzdCBjb21wcmVzc2VkIFNJRCwgdGhl biB0aGUgcGFja2V0cyBpcyBmb3J3YXJkZWQgYW5kIHRoZSA8YnI+DQomZ3Q7Jmd0OyBwcm9jZXNz IHJlcGVhdHMuJm5ic3A7IFdoZW4gYWxsIHRoYXQgaXMgbGVmdCBhcmUgMHMsIGlmIHRoZXJlIGlz IGFuIFNSSCwgaXQgPGJyPg0KJmd0OyZndDsgaXMgY29uc3VsdGVkIHRvIGZpbmQgdGhlIG5leHQg U1JIIGVudHJ5LCB3aGljaCBpcywgcGVyIG5vcm1hbCBTUnY2IDxicj4NCiZndDsmZ3Q7IHByb2Nl c3NpbmcsIHB1dCBpbnRvIHRoZSBJUHY2IERBLjxicj4NCiZndDsmZ3Q7IE5vdGUgdGhhdCBpbiB0 aGUgY29tbW9uIGNhc2Ugd2hlcmUgdGhlIFNJRFMgbmVlZGVkIGFsbCBmaXQgaW4gdG8gYSA8YnI+ DQomZ3Q7Jmd0OyBzaW5nbGUgY29udGFpbmVyLCB0aGUgYW5hbHlzaXMgYWxzbyBhc3N1bWVzIHRo ZSB1c2Ugb2YgdGhlIHJlZHVjZWQgPGJyPg0KJmd0OyZndDsgZW5jYXBzdWxhdGlvbiBvcHRpb25z IHdoaWNoIG9taXRzIHRoZSBTUkggdGhhdCBpcyBub3QgbmVlZGVkIGFzIGl0IHdvdWxkIDxicj4N CiZndDsmZ3Q7IGhhdmUgbm8gZW50cmllcy4mbmJzcDsgVGhpcyB0aGUgcGFja2V0IGNvbnRhaW5z IGEgbm9ybWFsIElQdjYgaGVhZGVyLCB3aXRoIGEgPGJyPg0KJmd0OyZndDsgc2VxdWVuY2Ugb2Yg Y29tcHJlc3NlZCBTSURzICh3aGF0IG9uZSBtaWdodCBvciBtaWdodCBub3QgY2FsbCBhIHNvdXJj ZSA8YnI+DQo8YnI+DQomZ3Q7Jmd0OyByb3V0ZSkgaW4gdGhlIElQdjYgZGVzdGluYXRpb24gYWRk cmVzcyBmaWVsZC48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFBQUzogSWYgdGhlIGF1dGhv cnMgb2YgdGhlIE5FWFQtQy1TSUQgZmxhdm9yIGZlZWwgSSBoYXZlIG1pcy1yZXByZXNlbnRlZCA8 YnI+DQomZ3Q7Jmd0OyB0aGUgd29yaywgcGxlYXNlLCBzZW5kIGNsYXJpZmljYXRpb25zIG9yIGNv cnJlY3Rpb25zLiZuYnNwOyZuYnNwOyBBZ2FpbiwgdGhlIGJlc3QgPGJyPg0KJmd0OyZndDsgc291 cmNlIG9mIGluZm9ybWF0aW9uIGlzIHRoZSBkcmFmdCBpdHNlbGYuJm5ic3A7IEkgd2FzIGFza2Vk IHRvIHByb3ZpZGUgZXh0cmEgPGJyPg0KJmd0OyZndDsgY29udGV4dCBpbiB0aGlzIGVtYWlsLjxi cj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgSUVURiBJUHY2IHdvcmtp bmcgZ3JvdXAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlwdjZAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyBBZG1pbmlz dHJhdGl2ZSBSZXF1ZXN0czogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9pcHY2IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lwdjY8L2E+PGJyPg0KJmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsgPGJy Pg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86aXB2NkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsi PmlwdjZAaWV0Zi5vcmc8L2E+PGJyPg0KQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IDxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2NiIgdGFyZ2V0PSJfYmxh bmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2PC9hPjxicj4N Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpJ RVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 aXB2NkBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlwdjZAaWV0Zi5vcmc8L2E+PGJyPg0KQWRt aW5pc3RyYXRpdmUgUmVxdWVzdHM6IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaXB2NiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9pcHY2PC9hPjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0g PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6IzIyMjIyMiI+PGEg aHJlZj0iaHR0cDovL3d3dy52ZXJpem9uLmNvbS8iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHls ZT0iY29sb3I6IzExNTVDQztib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5nOjBj bTt0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSI4MSIgaGVpZ2h0 PSIxOCIgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJjaWQ6aW1hZ2UwMDEuanBnQDAxRDdDNzM1LkEw MkJBRDEwIiBhbHQ9IuWbvuWDj+W3suiiq+WPkeS7tuS6uuWIoOmZpOOAgiI+PC9zcGFuPjwvYT48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luOjBjbTttYXJnaW4tYm90dG9t Oi4wMDAxcHQ7bXNvLWxpbmUtaGVpZ2h0LWFsdDo5Ljc1cHQiPjxiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5HeWFuIE1p c2hyYTwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxl PSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDttc28tbGluZS1oZWlnaHQtYWx0Ojku NzVwdCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0dlb3JnaWEmcXVvdDssc2Vy aWY7Y29sb3I6YmxhY2siPk5ldHdvcmsgU29sdXRpb25zIEFyY2hpdGVjdCZuYnNwOzwvc3Bhbj48 L2k+PHNwYW4gc3R5bGU9ImNvbG9yOiMyMjIyMjIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IHN0eWxlPSJtYXJnaW46MGNtO21hcmdpbi1ib3R0b206LjAwMDFwdDttc28tbGluZS1oZWlnaHQt YWx0OjkuNzVwdCI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7R2VvcmdpYSZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+RW1haWwNCjxhIGhyZWY9Im1h aWx0bzpneWFuLnMubWlzaHJhQHZlcml6b24uY29tIiB0YXJnZXQ9Il9ibGFuayI+Z3lhbi5zLm1p c2hyYUB2ZXJpem9uLmNvbTwvYT48L3NwYW4+PC9pPjxzcGFuIHN0eWxlPSJjb2xvcjojMjIyMjIy Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBj bTttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBjbTtt c28tbGluZS1oZWlnaHQtYWx0OjkuNzVwdCI+DQo8aT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7R2VvcmdpYSZxdW90OyxzZXJpZjtjb2xvcjpibGFjayI+TSAzMDEgNTAyLTEzNDc8L3Nw YW4+PC9pPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_838f3074802b4b67b33b7153d2f7089ehuaweicom_-- --_004_838f3074802b4b67b33b7153d2f7089ehuaweicom_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=356; creation-date="Fri, 22 Oct 2021 03:11:59 GMT"; modification-date="Fri, 22 Oct 2021 03:11:59 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_838f3074802b4b67b33b7153d2f7089ehuaweicom_-- From nobody Thu Oct 21 22:06:35 2021 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 DAE353A0603; Thu, 21 Oct 2021 22:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.585 X-Spam-Level: X-Spam-Status: No, score=-9.585 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_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=GR7tAQS2; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BZiHQ+Q7 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 VIFHs9CrF_Mo; Thu, 21 Oct 2021 22:06:14 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E05DA3A05F0; Thu, 21 Oct 2021 22:06:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33436; q=dns/txt; s=iport; t=1634879174; x=1636088774; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DqgHq3eSyTD7nJk5oFCbTDYEFhHm41eDD2hiokQMVFE=; b=GR7tAQS2zl/SPtrBjb5ADA/UEcSTuPILZWoZyF92NxrjNlgJqjNP/dcN +6FE35hU8fib4qz1yFpFOv3kl6u/uzoFu/v2iZEMDWHmvGbnHxNkDib39 3axTKLknoJ7svL3+IXS0Y44PnccH893ROF4b2lzn926AaRcWTIV3jtSzf 4=; X-IronPort-AV: E=Sophos;i="5.87,171,1631577600"; d="scan'208,217";a="926473415" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Oct 2021 05:05:47 +0000 Received: from mail.cisco.com (xbe-rcd-005.cisco.com [173.37.102.20]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 19M55lGc008843 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 22 Oct 2021 05:05:47 GMT Received: from xfe-rtp-005.cisco.com (64.101.210.235) by xbe-rcd-005.cisco.com (173.37.102.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 22 Oct 2021 00:05:47 -0500 Received: from xfe-rcd-002.cisco.com (173.37.227.250) by xfe-rtp-005.cisco.com (64.101.210.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 22 Oct 2021 01:05:46 -0400 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Fri, 22 Oct 2021 00:05:46 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kDAn54jplMWG0dH316XR60bt+ypHcY3py9/jlQpmHrQP/b4ZRVc2q5JzuMippoz9GI/4SBgVQLWjO9LI4wOQy96RWocr8JwVvnBHTHkbOpSOHK/oC/frYLazKj09CznvdMP2NDX30nnxK2jobVvHx+sQVxbFbe4W/W2NEfX0Fjsh0kypujHfvLOm2Fix/BARY7bGkDB73Pi9L8+Nyq2spL5AkkTERw+5XlsyGU6x+v8oPqx7ZmVs1EhypaOhGYa70Bg4lCatCP/N2RF/D/OrcDj44/6i1uaj/lbjJ8VaUUCY8XrNBt/4mhmgUHTukt3MSVrPmWjEI0iLbzmTlRjYlQ== 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=a0dRKd8ePUkQcJbMhvIluPp/cIDchgcPg1Oz00sMcUQ=; b=YWo+GJ78qDnbc+Lc/sGElkiuKR+XjkeuteXhFMOg1i+MxKZfhRHDKFUTkPZAUQZwTnIokax1doRWfNvkAfbC08aYemecfLYCephDGebmdbcGg/xWP9IUZ82//4Imfh8+/hBaMNB61OJI44QM0rDielTOIL5J8EeR+xPn/Z/WTVvvDwc1pw69BgsieyXTSdGRyKjZqiyZSPFIcisFLA+E2udefXw+2OlyER1SBoUo7QJ/EDr1p+LVQZ+eI59/K8q1x1DLIZL/FgtuflCbtKtpNNiRyOTDMEUcdxFp/QHx9dt5HAsCzkgCHJQ5r7vuZJwef1E7JWdcNxX8ayxskg9TcQ== 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=a0dRKd8ePUkQcJbMhvIluPp/cIDchgcPg1Oz00sMcUQ=; b=BZiHQ+Q7DlgA6AKxCeJgDGtHAoMzPDbvlEj1HxDJX4J8Y8GavM6ttKKyIQPfy3h9/gg25LXz0sBcO7Xp3iALaLR1BLW53F+2AbAl6cELp+skEF/hhMw7mSsi0FcVpGL6/k6rtEaGLCJuk80bdwYS99bX2nMK7FWhuL11eXKIvfk= Received: from BN6PR11MB4081.namprd11.prod.outlook.com (2603:10b6:405:78::38) by BN7PR11MB2723.namprd11.prod.outlook.com (2603:10b6:406:b9::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.16; Fri, 22 Oct 2021 05:05:45 +0000 Received: from BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::90c7:290e:a57c:1a39]) by BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::90c7:290e:a57c:1a39%3]) with mapi id 15.20.4628.018; Fri, 22 Oct 2021 05:05:45 +0000 From: "Darren Dukes (ddukes)" To: Gyan Mishra CC: Brian E Carpenter , Greg Mirsky , "ipv6@ietf.org" , "spring@ietf.org" Thread-Topic: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression Thread-Index: AQHXxe8+Uq3QOF5820qajRqw1QJECavdgCRCgACSI4CAAGKcbw== Date: Fri, 22 Oct 2021 05:05:44 +0000 Message-ID: References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <26d9fc32-4884-602c-975a-79fc64551727@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ca7ee096-c217-4f6f-0b36-08d995199a9f x-ms-traffictypediagnostic: BN7PR11MB2723: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IN6awdfSnDDjbBOFBsyn7roD9gIWSxCqgexhITNe0S3OhcX+z2STJ4BinoLn/A8xzf2kSod70t706oBWn1lskUNR5EPDdOSTp/a3iJw7bRMF6FKHKG5SjtX3pWK/rkp29fT7L0lA4Bb38l09l9HeuOfrRU1y2zEGRZPUl/5lR6OqAMtw6uNw2+5AS4Cd80GemS6HN/U5Uk+Tz9i3G0jExfhpCkiEFE7DOtDX1Hnsh3jL/fCaEgkdozytCozJbGyk+lhisk/ZtbhcjDlmBlbDu38PotubKr+31NMEZrO6cr3vAYF3iAkJvzh5993HFOExGnowR2YXGRcxCkztjkqCZjhTV/uiRWJyTxoLxmu+CxNNwVirmfboiTXGalaTZHru/eoATb+GiLpfWMiO/KiH7upKIQs8dy3nypoduN/ahFsUZwTiH3IenGrojcfaZrjgfJA9MBsgvQzRqoT9byCLOb3k+7DKHO5LnNQikr9fxJamIKHoJ/dfdopQmfb+f6xBODvMPWcLmrbvg+hqJMMf44ZvGoCS4cDu2HWAMyvUAcIiieGyydrx9orbGb1QoOmy1uZr1SkjFl4rmZQbWst8bOhx7ZO4d4/vMN4EJK6S+23IuYuUEF2z1NveFMmASyoDULYw/SmfzT7WqjJazO4+jWak5XzfLQQDc6lHiQU43OE6HGk4oBpeMN+4QQFCOwzSTKV8g47SJtp9o5MKScJer3dzoMOeUYO9ic3TeB+l5EupRZhTqbSmhp3pTg7bvQjg3P8rJpQVbi4C+3MxrGRP67+MkwCZZeL7ECC9s29ziBHz3lRf2mxC41sNBdrWoLtPkkNgWDac1cOcaKQz6plSKg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB4081.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(166002)(83380400001)(66556008)(66476007)(8936002)(4326008)(66574015)(6916009)(38100700002)(53546011)(26005)(2906002)(40140700001)(86362001)(4001150100001)(122000001)(6506007)(38070700005)(91956017)(7696005)(76116006)(33656002)(71200400001)(186003)(55016002)(5660300002)(9686003)(8676002)(508600001)(52536014)(30864003)(66946007)(316002)(54906003)(66446008)(966005)(64756008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?+AX5ez6B8Ml9KqX39wjwnoVVW4epsb0Ggthx3vsmq4obqnfKZ+fypA+S?= =?Windows-1252?Q?1Y6ITen8qMvomWEQsgvTKUR8ptg33TIv9B89pqnagRX330q9/XudCtJZ?= =?Windows-1252?Q?QFDRYOYItPcnPLPIGKtUu4rlxrVgEnME5x14AhApm39fAPCNE359umR0?= =?Windows-1252?Q?UqtHbeRw/L39iMRiZIF6/SJvskqVM0T5SsIcgIZ7XYXMRvbfAmRkzp5l?= =?Windows-1252?Q?Tp1IxHYUU2DtfSEYy875Cb8HvnsdQd9mzKAgOpgjGEYmeILoHMgV8FYM?= =?Windows-1252?Q?Js/+NliyiDc3XwGquFVVKpZlqu+G0iBVkSTcGZgM8CTZYPJ6cQbMgQvq?= =?Windows-1252?Q?a5baIpQo7iowzdXgwG7aHShEzYxieU40TSS9DJq/7Lwpzh/18J3g2oi6?= =?Windows-1252?Q?AZgNwzCvk638dfDkJ9KZmVYbja5veMUSCdQj2n0iUIy7b3DKWjEhUZxF?= =?Windows-1252?Q?TLlcNhEqfwqdFHe5a7FMvcyUxbEjc4ZkdDxIoeynHopezwD1rrZf3cG3?= =?Windows-1252?Q?2V4iNQ1X+gNLXEcVGH9c6J3VnX865N0eJ84+NrIuhR+Z/12nNj5mr0Ze?= =?Windows-1252?Q?OKz9w5hPzvLFm0yIiTwdeChoNKp5ZJSrci+MN3ABVqHHLzCXZVjyeXHQ?= =?Windows-1252?Q?jv4oMd9jY3TCYmUB4VvAb9T66isBgpKq4Xom4r5OmKGAvldYkWGQFFQD?= =?Windows-1252?Q?mpsx9nxEnOMwSeb4oT84rrdUaeYIiX9t2LU7ntCAQDToe4JmFqDqnWps?= =?Windows-1252?Q?e77Kq1IdERCLVpV57+MFCIcxqeY+luJggPidY9nKzIOf0u6nX7Ly0Czg?= =?Windows-1252?Q?+nNQHtXsCapvKvWDAhkpFnUt20kvk+J4o7XPfP4roV5jdHJrjZ/1gMoZ?= =?Windows-1252?Q?N9KmX4MlwjzE6Qh1We/XTUPhaDG4c7qKtjcpuVJ1WtffXAhCCBCexEWE?= =?Windows-1252?Q?nHn83go2K94ifvXkgXPQ+gMPvQMEwOZAN0CAQN6I4lrQUM+PCUs/TkEb?= =?Windows-1252?Q?eTBL+hwv15bsmnLQIBY8fbaFOxKMPCr3T+3IRgqW4rihnxFUH3GA/sjS?= =?Windows-1252?Q?aLwAOrJTLvkXbNc9Tg2L2RcGqp/Mr78DCHazEzN0krPMH8YN2nj8Lw5W?= =?Windows-1252?Q?mVPkZeALZswSKdj9xIKzDI3kE3sxpNwYUSIuoEp7WxkPZ1pDuvaLyha4?= =?Windows-1252?Q?+KX1f9NGNA39mrdMJGkAUQL81PNKC/egAUcnKb2UJ5kkLKCnOKJKiRAl?= =?Windows-1252?Q?ftNvF44B/AZ2b/5HOfr/36faZ3xQKPGiyzgZH/V+3+IaaTp+Il89ECJG?= =?Windows-1252?Q?zBIu/huIIQNG0RgjZl2A+SyWFe+QLpMThxw6vG09gWd1BxSQG2NgSSJv?= =?Windows-1252?Q?Y7ikDJUFGk100tiUkpnycSdZwv0EeS9fKuVEkx3U5R47hxO3wuN0F4FG?= =?Windows-1252?Q?+gbOAw/Oq7ic+VtX7nzvFHvqJlDlG5Jhb1geXnjBXyWavbu3i2zHQizG?= =?Windows-1252?Q?vnIOxAA94pRtYSXpqDRe8soA7WvxAV5kLhvl1F6BJ//AH8cDy9uE05Ji?= =?Windows-1252?Q?2+qg+OWuU+CUWgao?= Content-Type: multipart/alternative; boundary="_000_BN6PR11MB4081F282DF1109E1DE3B2AFBC8809BN6PR11MB4081namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN6PR11MB4081.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: ca7ee096-c217-4f6f-0b36-08d995199a9f X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2021 05:05:44.8392 (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: ddukes@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2723 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xbe-rcd-005.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 22 Oct 2021 05:06:27 -0000 --_000_BN6PR11MB4081F282DF1109E1DE3B2AFBC8809BN6PR11MB4081namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Gyan and Greg. Gyan I=92m sorry but i don=92t see a question in your email. I=92ll go back= to Greg. While I=92m not exactly sure what is being asked, I will say that Brian is = correct for every Srv6 SID behavior (not just csid flavors) when he says th= e following about their arguments (lowest 64 bits in the ipv6 Dest addr. =93They are invisible to routing (which is done based on the prefix) and in= visible to neighbor discovery (because it never happens).=94 I hope this helps. Darren ________________________________ From: Gyan Mishra Sent: Thursday, October 21, 2021 7:03 PM To: Darren Dukes (ddukes) Cc: Brian E Carpenter; Greg Mirsky; ipv6@ietf.org; spring@ietf.org Subject: Re: Typo correction Re: Question from SPRING regarding draft-filsf= ilscheng-spring-srv6-srh-compression Hi Darren What Greg is asking is if the SID is a prefix SID End and not adjacency SID= End.x, so now the common prefix is needed to ECMP steer the flow to the p= refix SID which uses the common prefix, which may in this case be mutated = due to shifting of SIDs in GSID container. Kind Regards Gyan On Thu, Oct 21, 2021 at 10:18 AM Darren Dukes (ddukes) > wrote: Hi Greg, Your question is not clear to me. Can you try to restate it with the flavors and behaviors from the draft in = question? Darren On 2021-10-20, 4:15 PM, "ipv6" > wrote: Hi Brian, I've got some questions about what you've said: For that reason, the fact that the bottom 64 bits in the "address" look funny or change is simply irrelevant. They are invisible to routing (which is done based on the prefix) and invisible to neighbor discovery (because it never happens). As I understand it, what you describe is the case of a strict explicit path= defined using one of the C-SID compression methods. But I am not sure that= your conclusion also always applies when it is a loose explicit path speci= fied in the compressed Segment List. As all C-SIDs share the same prefix, h= ow routing can be done based only on that prefix and not using a part of th= at "funny" bottom 64 bits? And if any part of the bottom 64 bits must be us= ed, how one can guarantee that CIDR still works in that domain? Regards, Greg On Mon, Oct 18, 2021 at 9:50 PM Brian E Carpenter > wrote: Hi, After reading a lot of messages, I'm going to offer my considered opinion as a direct response to Joel's OP. Firstly, I don't believe that in the end this draft raises any concerns that are *significantly* different than those raised when RFC 8986 was in draft. As Ted Hardie mentioned, section 5 of RFC 8754 explains that SIDs of any shape or size are only meaningful within an SR domain. That applies to srh-compression too. Secondly, I was concerned about how these strange looking "addresses" would potentially interfere with normal IPv6 addresses and their handling by normal IPv6 nodes. Well, I now believe that they won't. The reason is that in the SR model these "addresses" are *never used for final delivery of IPv6 packets to a host.* All SRv6 participants are routers. The last hop for a packet whose DA is set to (say) 2001:db8:a:1900:: is *not* the last hop on a LAN, mediated by neighbor discovery for 2001:db8:a:1900::. It's just a hop from one router to another, using the entry for 2001:db8:a:1900::/64 in the FIB of the last router that actually forwards the packet. 2001:db8:a:1900:: is not assigned to a physical interface so RFC 4861 is never invoked. Another way to say it is RFC 7608 is the relevant architectural standard. CIDR rules, even within an SR domain. For that reason, the fact that the bottom 64 bits in the "address" look funny or change is simply irrelevant. They are invisible to routing (which is done based on the prefix) and invisible to neighbor discovery (because it never happens). I apologise if this is all obvious to everybody, but I needed to spell it out for my own understanding. Now back to Joel's questions: On 13-Oct-21 20:37, Joel M. Halpern wrote: > There is a typo in the below which if not understood as a typo would be > quite confusing. I wrote that I raised the issue with > "with the Internet ADs and SPRING chairs". > That should have read "with the Internet ADs and 6man chairs". > The SPRING co-chairs are recused, and the charter requirement leads to > the 6man chairs. Which is who I talked to. > > Also, I am sending a courtesy copy to the routing ADs, which I should > have done originally. > > Thank you and enjoy. > Yours, > Joel > > On 10/12/2021 11:52 PM, Joel M. Halpern wrote: >> The SPRING working group is in the midst of an adoption call on >> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-com= pression/. >> >> >> The SPRING charter has text that is explicit that modifications to data >> planes and architectures standardized by other working groups may not be >> modified in SPRING unless the chairs and ADs responsible for that data >> plane and / or architecture agree. >> >> To complete the context, as my SPRING co-chairs are co-authors on the >> document in question, they have recused themselves from decisional >> activities regarding the document. Therefore, this message is coming >> just from my as the responsible SPRING co-chair managing this adoption >> call. >> >> As you have seen, multiple questions have been raised about the >> relationship of the document to the IPv6 defined data plane and >> architecture (particularly RFC 4291 and 8200). In particular the >> questions seem to revolve around what the document describes as the >> NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6 >> standards. (For those seeking more context without reading the full >> document, a paraphrase and simplification of the NEXT-C_SID flavor is >> provided as a postscript.) >> >> I raised the question of concurrence as required by the SPRING charter >> with the Internet ADs and SPRING chairs. They quite reasonably asked me >> to write a note to 6man explaining the concerns as clearly as a can, so >> that they can then determine how to proceed. >> >> The questions that prompted my inquiry are: >> >> 1) Does the placement of a list of sids in the IPv6 DA field change the >> IPv6 architectural description of that field. I think it should be noted explicitly somewhere that since the contents of the DA field are *never* used for last-hop neighbor discovery, the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942 are irrelevant. Another citation is RFC 7608: for routing, all that counts is the prefix, and it can be anything up to 128. Perhaps this should have been in section 5 of RFC 8754, but I leave that to the wordsmiths. >> 2) Does the operation of shifting information around in the IPv6 >> destination address field represent a modification or extension of the >> IPv6 data plane. No. As my text above indicates, the SRv6 DA field is only ever used by routing, where RFC 7608 rules. And of course it vanishes as soon as the packet is decapsulated. Regards Brian >> >> On a related note, the document in question also defines two other >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID >> flavor operation, so seems to be affected by the same question. >> >> From my own reading, it appears that the REPLACE-C-SID flavor does not >> raise issues requiring 6man leadership concurrence. >> >> Yours, >> Joel M. Halpern for the SPRING working group >> >> >> PS: >> Clearly, understanding the question requires some understanding of what >> the NEXT-C_SID flavor does. This explanation is a simplification for >> length and context. Really, the best place to understand it is the >> draft. However, to give you enough information to let you decide >> whether you care, I will try to provide a fair summary. My apologies in >> advance to the authors for necessary liberties for length. Also, >> discussion of the draft contents (as distinct from the interaction with >> the IPv6 data plane and architecture) belongs on the SPRING list, and >> should not clutter up 6man. >> >> SIDs are the identifiers used in segment routing. >> In SRv6, as document in the current RFCs, these are 128 bits. As >> defined in the relevant RFCs, SIDs which identify endpoints to which >> packets are directed are identified by endpoint SIDs. These can have >> behaviors (decapsulate and forward is one example). They can have >> flavors such as where the SRH is removed. >> >> The topic under discussion is means to compress these SIDs in the >> packets on the wire. The document under discussion provides three >> flavors of compression. >> >> The fundamental mechanism of the draft is to use a single SRH entry as a >> container for multiple SIDs. In the NEXT-C_SID mechanism, when it is >> first encountered the entire container is copied into the desination >> address of the IPv6 packet. The container has a common routing prefix >> used for all the NEXT-C-SID SIDs. It is followed by a sequence of >> compressed SIDs of a configured length. One could configure 16, 24, or >> 32 bits. Or whatever length. The routing advertisements are arranged >> so that the IPv6 packet is directed to the node represented by the first >> compressed SID on the basis of longest prefix match matching the >> combination of the common routing prefix and that compressed SID. >> >> When the packet arrives at that node, it looks up the configured >> portion, the compressed SID, and determines the behavior and flavor. In >> the case of the NEXT-C-SID flavor, the resulting operation is to shift >> the entire remaining contents of the IPv6 address (the bits past the >> first compressed sid) so as to over-write the first compressed SID. 0 >> bits are shifted into the low order positions. If the result is a >> non-zero new first compressed SID, then the packets is forwarded and the >> process repeats. When all that is left are 0s, if there is an SRH, it >> is consulted to find the next SRH entry, which is, per normal SRv6 >> processing, put into the IPv6 DA. >> Note that in the common case where the SIDS needed all fit in to a >> single container, the analysis also assumes the use of the reduced >> encapsulation options which omits the SRH that is not needed as it would >> have no entries. This the packet contains a normal IPv6 header, with a >> sequence of compressed SIDs (what one might or might not call a source >> route) in the IPv6 destination address field. >> >> PPS: If the authors of the NEXT-C-SID flavor feel I have mis-represented >> the work, please, send clarifications or corrections. Again, the best >> source of information is the draft itself. I was asked to provide extra >> context in this email. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email] Gyan Mishra Network Solutions Architect Email gyan.s.mishra@verizon.com M 301 502-1347 --_000_BN6PR11MB4081F282DF1109E1DE3B2AFBC8809BN6PR11MB4081namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
    Hi Gyan and Greg. 

    Gyan I=92m sorry but i don=92t see a question in your emai= l. I=92ll go back to Greg. 

    While I=92m not exactl= y sure what is being asked, I will say that Brian is correct for every Srv6= SID behavior (not just csid flavors) when he says the following about thei= r arguments (lowest 64 bits in the ipv6 Dest addr.

    =93They are invisible to r= outing (which is done based on the prefix) and invisible to neighbor discovery (because it never happens).=94

    I hope this helps. 

    Darren

    From: Gyan Mishra <hayabusagsm@gmail.com>
    Sent: Thursday, October 21, 2021 7:03 PM
    To: Darren Dukes (ddukes)
    Cc: Brian E Carpenter; Greg Mirsky; ipv6@ietf.org; spring@ietf.org Subject: Re: Typo correction Re: Question from SPRING regarding draf= t-filsfilscheng-spring-srv6-srh-compression
     


    Hi Darren 

    What Greg is asking is if the SID is a prefix SID End and= not adjacency SID End.x, so now the common prefix is needed to ECMP steer = the flow  to the prefix SID which uses the common prefix,  which = may in this case be mutated due to shifting of SIDs in GSID container.


    Kind Regards 

    Gyan 
    On Thu, Oct 21, 2021 at 10:18 AM Darr= en Dukes (ddukes) <ddukes=3D40cisco.com@dmarc.ietf.org> wrote:

    Hi Greg, <= /p>

     

    Your question is not clear to m= e.

    Can you try to restate it with = the flavors and behaviors from the draft in question?

     

    Darren

     

    On 2021-10-20, 4:15 PM,= "ipv6" <ipv6-bounces@ietf.org> wrote:

     

    Hi Brian,=

    I've got some questions= about what you've said:

    For that reason, the fa= ct that the bottom 64 bits in the

    "address" loo= k funny or change is simply irrelevant. They are

    invisible to routing (w= hich is done based on the prefix)

    and invisible to neighb= or discovery (because it never happens).

    As I understand it, wha= t you describe is the case of a strict explicit path defined using one of t= he C-SID compression methods. But I am not sure that your conclusion also a= lways applies when it is a loose explicit path specified in the compressed Segment List. As all C-SIDs share the sam= e prefix, how routing can be done based only on that prefix and not using a= part of that "funny" bottom 64 bits? And if any part of the bott= om 64 bits must be used, how one can guarantee that CIDR still works in that domain?

     

    Regards,<= /p>

    Greg

     

    On Mon, Oct 18, 2021 at= 9:50 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

    Hi,

    After reading a lot of messages, I'm going to offer my considered
    opinion as a direct response to Joel's OP.

    Firstly, I don't believe that in the end this draft raises any
    concerns that are *significantly* different than those raised
    when RFC 8986 was in draft. As Ted Hardie mentioned, section 5
    of RFC 8754 explains that SIDs of any shape or size are only
    meaningful within an SR domain. That applies to srh-compression
    too.

    Secondly, I was concerned about how these strange looking
    "addresses" would potentially interfere with normal IPv6
    addresses and their handling by normal IPv6 nodes. Well, I
    now believe that they won't. The reason is that in the SR model
    these "addresses" are *never used for final delivery of IPv6
    packets to a host.* All SRv6 participants are routers. The
    last hop for a packet whose DA is set to (say) 2001:db8:a:1900::
    is *not* the last hop on a LAN, mediated by neighbor discovery
    for 2001:db8:a:1900::. It's just a hop from one router to another,
    using the entry for 2001:db8:a:1900::/64 in the FIB of the last
    router that actually forwards the packet. 2001:db8:a:1900:: is
    not assigned to a physical interface so RFC 4861 is never invoked.

    Another way to say it is RFC 7608 is the relevant architectural
    standard. CIDR rules, even within an SR domain.

    For that reason, the fact that the bottom 64 bits in the
    "address" look funny or change is simply irrelevant. They are
    invisible to routing (which is done based on the prefix)
    and invisible to neighbor discovery (because it never happens).

    I apologise if this is all obvious to everybody, but I needed
    to spell it out for my own understanding.

    Now back to Joel's questions:


    On 13-Oct-21 20:37, Joel M. Halpern wrote:
    > There is a typo in the below which if not understood as a typo would b= e

    > quite confusing.   I wrote that I raised the issue with
    > "with the Internet ADs and SPRING chairs".
    > That should have read "with the Internet ADs and 6man chairs"= ;.
    > The SPRING co-chairs are recused, and the charter requirement leads to=
    > the 6man chairs.  Which is who I talked to.
    >
    > Also, I am sending a courtesy copy to the routing ADs, which I should =
    > have done originally.
    >
    > Thank you and enjoy.
    > Yours,
    > Joel
    >
    > On 10/12/2021 11:52 PM, Joel M. Halpern wrote:
    >> The SPRING working group is in the midst of an adoption call on >> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/.
    >>
    >>
    >> The SPRING charter has text that is explicit that modifications to= data
    >> planes and architectures standardized by other working groups may = not be
    >> modified in SPRING unless the chairs and ADs responsible for that = data

    >> plane and / or architecture agree.
    >>
    >> To complete the context, as my SPRING co-chairs are co-authors on = the
    >> document in question, they have recused themselves from decisional=
    >> activities regarding the document.  Therefore, this message i= s coming
    >> just from my as the responsible SPRING co-chair managing this adop= tion

    >> call.
    >>
    >> As you have seen, multiple questions have been raised about the >> relationship of the document to the IPv6 defined data plane and >> architecture (particularly RFC 4291 and 8200). In particular the <= br> >> questions seem to revolve around what the document describes as th= e
    >> NEXT-C-SID flavor of compressed SID, and its relationship to the I= Pv6
    >> standards.  (For those seeking more context without reading t= he full
    >> document, a paraphrase and simplification of the NEXT-C_SID flavor= is
    >> provided as a postscript.)
    >>
    >> I raised the question of concurrence as required by the SPRING cha= rter

    >> with the Internet ADs and SPRING chairs.  They quite reasonab= ly asked me
    >> to write a note to 6man explaining the concerns as clearly as a ca= n, so
    >> that they can then determine how to proceed.
    >>
    >> The questions that prompted my inquiry are:
    >>
    >> 1) Does the placement of a list of sids in the IPv6 DA field chang= e the
    >> IPv6 architectural description of that field.

    I think it should be noted explicitly somewhere that since the contents
    of the DA field are *never* used for last-hop neighbor discovery,
    the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942
    are irrelevant. Another citation is RFC 7608: for routing, all that
    counts is the prefix, and it can be anything up to 128.

    Perhaps this should have been in section 5 of RFC 8754, but I leave
    that to the wordsmiths.

    >> 2) Does the operation of shifting information around in the IPv6 <= br> >> destination address field represent a modification or extension of= the

    >> IPv6 data plane.

    No. As my text above indicates, the SRv6 DA field is only ever used
    by routing, where RFC 7608 rules. And of course it vanishes as soon
    as the packet is decapsulated.

    Regards
        Brian

    >>
    >> On a related note, the document in question also defines two other=
    >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.  The
    >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID=
    >> flavor operation, so seems to be affected by the same question. >>
    >>  From my own reading, it appears that the REPLACE-C-SID flavo= r does not
    >> raise issues requiring 6man leadership concurrence.
    >>
    >> Yours,
    >> Joel M. Halpern for the SPRING working group
    >>
    >>
    >> PS:
    >> Clearly, understanding the question requires some understanding of= what
    >> the NEXT-C_SID flavor does.   This explanation is a simp= lification for
    >> length and context.  Really, the best place to understand it = is the
    >> draft.  However, to give you enough information to let you de= cide

    >> whether you care, I will try to provide a fair summary.  My a= pologies in
    >> advance to the authors for necessary liberties for length.  A= lso,

    >> discussion of the draft contents (as distinct from the interaction= with
    >> the IPv6 data plane and architecture) belongs on the SPRING list, = and
    >> should not clutter up 6man.
    >>
    >> SIDs are the identifiers used in segment routing.
    >> In SRv6, as document in the current RFCs, these are 128 bits. = ;  As
    >> defined in the relevant RFCs, SIDs which identify endpoints to whi= ch
    >> packets are directed are identified by endpoint SIDs.  These = can have
    >> behaviors (decapsulate and forward is one example).  They can= have
    >> flavors such as where the SRH is removed.
    >>
    >> The topic under discussion is means to compress these SIDs in the =
    >> packets on the wire.  The document under discussion provides = three
    >> flavors of compression.
    >>
    >> The fundamental mechanism of the draft is to use a single SRH entr= y as
    a
    >> container for multiple SIDs.  In the NEXT-C_SID mechanism, wh= en it is
    >> first encountered the entire container is copied into the desinati= on
    >> address of the IPv6 packet.  The container has a common routi= ng prefix
    >> used for all the NEXT-C-SID SIDs.  It is followed by a sequen= ce of
    >> compressed SIDs of a configured length.  One could configure = 16, 24, or
    >> 32 bits.  Or whatever length.  The routing advertisement= s are arranged
    >> so that the IPv6 packet is directed to the node represented by the= first
    >> compressed SID on the basis of longest prefix match matching the <= br> >> combination of the common routing prefix and that compressed SID.<= br> >>
    >> When the packet arrives at that node, it looks up the configured <= br> >> portion, the compressed SID, and determines the behavior and flavo= r.  In
    >> the case of the NEXT-C-SID flavor, the resulting operation is to s= hift

    >> the entire remaining contents of the IPv6 address (the bits past t= he
    >> first compressed sid) so as to over-write the first compressed SID= .  0
    >> bits are shifted into the low order positions.  If the result= is a
    >> non-zero new first compressed SID, then the packets is forwarded a= nd the
    >> process repeats.  When all that is left are 0s, if there is a= n SRH, it
    >> is consulted to find the next SRH entry, which is, per normal SRv6=
    >> processing, put into the IPv6 DA.
    >> Note that in the common case where the SIDS needed all fit in to a=
    >> single container, the analysis also assumes the use of the reduced=
    >> encapsulation options which omits the SRH that is not needed as it= would
    >> have no entries.  This the packet contains a normal IPv6 head= er, with a
    >> sequence of compressed SIDs (what one might or might not call a so= urce

    >> route) in the IPv6 destination address field.
    >>
    >> PPS: If the authors of the NEXT-C-SID flavor feel I have mis-repre= sented
    >> the work, please, send clarifications or corrections.   = Again, the best
    >> source of information is the draft itself.  I was asked to pr= ovide extra
    >> context in this email.
    >
    > -------------------------------------------------------------------- > IETF IPv6 working group mailing list
    > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > -------------------------------------------------------------------- >

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------=

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    --
    --_000_BN6PR11MB4081F282DF1109E1DE3B2AFBC8809BN6PR11MB4081namp_-- From nobody Fri Oct 22 06:22:58 2021 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 629833A0DB8; Fri, 22 Oct 2021 06:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JlIb2hWT; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=mUPT4zGy 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 uDbgl0J0LF4m; Fri, 22 Oct 2021 06:22:43 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BD813A0DBA; Fri, 22 Oct 2021 06:22:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=65674; q=dns/txt; s=iport; t=1634908959; x=1636118559; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DYTM76pNocBjmUmA3xIAqYyr/9SpH3CxJDNHhxZjQpM=; b=JlIb2hWTsXYOAXDOo1bZSI4QNvoH+XhRr8uyNIRcqetZHwbEJItpR535 iL+82rJUpxtUTVxwgYfMuhYWNoPb/W40MOr8HfXnqzTwRwlGmh00xOAPs 3MuziCmfA37Im2+WBjSJqYGpfiostf185LNkvi/f1Qva3+Vj1/sCDOtwH k=; X-IPAS-Result: =?us-ascii?q?A0BTAACEunJh/5hdJa1aHAEBAQEBAQcBARIBAQQEAQGCB?= =?us-ascii?q?QcBAQsBgSAwIwYoB3cOTDcxhEeDRwOEWWCIDQOKdZABgS4UgREDVAsBAQENA?= =?us-ascii?q?QFBBAEBhQACgk0CJTQJDgECBAEBAQEDAgMBAQEBBQEBBQEBAQIBBgSBEROFa?= =?us-ascii?q?A2GQgEBAQEDEggHAQsTAQE3AQ8CAQgRAwEBARARAQYCAwIhERQJCAIEAQ0FC?= =?us-ascii?q?BMHglCBflcDLwGRVo82AYE6AoofdAGBNoEBgggBAQYEBIUKDQuCNQmBOgGDB?= =?us-ascii?q?YJ3VEqBIIVbJxyBSUSBFAFDgWaBAT6BUAFQQgSBKQESASMMEgYQgl86gi6Ma?= =?us-ascii?q?BBbBgI8JgRLTi14FwIEAQokER4CD5FGGoxJjVSRRmcKgzKZDoYHFYNqi26XR?= =?us-ascii?q?JUYDGgfgiCNeJA8hQkCBAIEBQIOAQEGNYEsO2lwcBU7gmlRGQ+OIAwFEYEEA?= =?us-ascii?q?QeCRIgtgjF0AjYCBgsBAQMJkEwBAQ?= IronPort-PHdr: A9a23:BuVw9BSdJJQDKJSQ5H3CAcgeJdpso6PLVj580XJvo7JTe7uu/tLpO 0mMrflujVqcW4Ld5roEjufNqKnvVCQG5orJq3ENdpFAFnpnwcUblgAtGoiJXEv8KvO5bzEzA 8lDElRi+iLzPU1cAs2rYVrUrzW75iITHROqMw1zK6z1F4fegt7x2fq1/sjYYh5Dg3y2ZrYhR Cg= IronPort-Data: A9a23:Dw3hHaoKsUERkZBfkeSdgkivOtVeBmJkZBIvgKrLsJaIsI4StFCzt garIBmDOaqKYDP3LdF/a9vjoE0Cu8fSn9dlSQs5qC03Q3tB9ePIVI+TRqvS04x+DSFioGZPt Zh2hgzodZhsJpPkS5TE3oHJ9RGQ74nQLlbHILOCan8ZqTNMEn970Es7wbRh2OaEvPDga++zk YKqyyHgEAfNNw5cagr4PIra9XuDFNyr0N8plgRWicJj5TcypFFJZH4rHpxdGlOjKmVi8kFWc M6YpF2x1juxEx7AkbpJmJ6jGqEBaua60QRjFhO6VoD66iWuqBDe3Y4LZOMQTUZrjQ6owcxej 45jvtuXalgQa/ikdOQ1C3G0EglkNqFAvbTAO3X66IqYzlbNdD3nxPAG4EMeZNJDvL0oRzAVs 6VFcljhbTjb7w6y6LG2VuBqmuwoLdLgO8UUvXQIITTxXa98HcmYHviSjTNe9AcNms8VG+vlX swAUhpOcxCHQRRjO1hCXfrSm8/t3BETaQZws1KPrKY742H7zhF30aDgKpzTd8DibcBIhVqRv mLPuW34GQoTM8Ge4TyC8XOlwOTImEvTQ5oIFbu33v9nnFPVwXYcYDUaT1K1vby4h1KwHthSM FdR4TAw8+0p+Va1T9LwRDW5rWKK+BkGVLJ4GeAh8ymMx7bapQGDCQAsVDdAbsc5s9U6AyMj0 FChn87gGjFu9raSTBqgGqy8tzi+P20eKnUPIHZCRgoe6N6lq4Y25v7Scute/GeOpoWdMVnNL /qi9UDSW517YRY36piG IronPort-HdrOrdr: A9a23:3ZOMZ6O6pMVO5MBcT23155DYdb4zR+YMi2TDiHoRdfUFSKKlfp 6V88jzjSWE9wr4WBkb6Le90dq7MA3hHP9OkMcs1NKZPDUO11HYV72KgbGSpgEIXheOitK1tp 0QMpSWaueAd2SS5PySiGLTfrpQo6jkzEnrv5ai854Hd3ANV0gU1XYANu/tKDwOeOApP+tcKL Osou584xawc3Ueacq2QlMfWfLYmtHNnJX6JTYbGh8O8mC1/HOVwY+/NyLd8gYVUjtJz7tn23 PCiRbF6qKqtOz+4gPA1lXU849dlLLau5h+7Y23+4oowwfX+0KVjbdaKvq/VfcO0aeSAWMR4Z zxStEbTp1OAj3qDzmISFDWqnjdOX4Vmg/fIBmj8CDeSQiTfkNmNyKH7rgpKCcxonBQz+1Uwe ZF2XmUuIFQCg6FlCPh58LQXxUvjUasp2E++NRjwkC3fLFuI4O5l7Zvtn+90a1wax7S+cQiCq 1jHcvc7PFZfReTaG3YpHBmxJipUm4oFhmLT0AesojNugIm00xR3g8d3ogSj30A/JUyR91N4P nFKL1hkPVLQtUNZaxwCe8dSY+8C3DLQxjLLGWOSG6XWJ0vKjbIsdr68b817OaldNgBy4Yzgo 3IVBdCuWs7ayvVeIWzNV1wg1nwqUmGLEHQI/Bllu5EU+fHNcjW2AW4OSQTr/c= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.87,172,1631577600"; d="scan'208,217";a="812413550" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Oct 2021 13:22:37 +0000 Received: from mail.cisco.com (xbe-aln-005.cisco.com [173.36.7.20]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 19MDMbNs010042 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Fri, 22 Oct 2021 13:22:37 GMT Received: from xfe-aln-003.cisco.com (173.37.135.123) by xbe-aln-005.cisco.com (173.36.7.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 22 Oct 2021 08:22:37 -0500 Received: from xfe-rtp-005.cisco.com (64.101.210.235) by xfe-aln-003.cisco.com (173.37.135.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Fri, 22 Oct 2021 08:22:36 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-005.cisco.com (64.101.210.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Fri, 22 Oct 2021 09:22:36 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lllQ6DBJSkHs45/y0nj3eH3SD4rLrDCmZYxwe/61akK2G+wX0liXoDVQXSIDDjfluc2XLgGN60CIObjm5VPwskRTCTGKAQfpqhAWSFgkGZ7zfp3woIg0tiCBH10ji/Sz4QeJClIbKpTVA5tpSUNNeBCE29NlAL5XncA7CVp6QPgP7nUS/7XCV0qwY/VYDGUVanCdwFqMjKWFGi5KQKq5tzEVMyPPoh/rHH1e77g+Ha+b/xZIquro485MsI0WbNga/aggdYAIeV2rwi41yZBBut3l9WbZGCrKE1Tsu5qvSo/5sHMSled/GFxn4pquiHkhvoEHGi6iBLHQzDQu3RXcbw== 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=oQGF3NoU4m5lo8ub9eyNmB2Hxl2IPa7mIn6PRUi97YM=; b=a6IAkpCRVvx4WDrn7LofOOnIYerceu5TjOxQvr6yvEYvaMY1fH8lTnqshELsm9OQ/BTiEVUU4v4zJt1CMmuVO+pawIeMOk9pCxK1Die0ltA1ULmo771pyDreuKkZvUV8ASzd6zajCkeRAp+IeKlDijRUyHiSK1/QQ7Y/AN3gPoCCyvcUxoUUbPkZs3Z0ByyHjBRg/qr3zwmmOT3VqI9uQOudwy3gxNCOqRYIElkYqx5Ks66lRs1ARKNC9st7gJa6q3Qz9ofRZxzk7KX4Zt4Toz5SdyPSTuCGMwtPz2m5Tob+2WqRtSHwFFtHmNYmWgQ1NZIlarTe85B7mhxBEMSeZw== 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=oQGF3NoU4m5lo8ub9eyNmB2Hxl2IPa7mIn6PRUi97YM=; b=mUPT4zGySm+BTLviXYpR1oehAdO8dFgAcw6Ecq+fIfmGqMh2XwKQfWVHmfYhjJi2gRYnof09OpqypN2XT8HJGEaQH5MqVCXdEHI0bYnbSE0P+WvOkOMlrXIHdtT+zwxam/klmPJAuUvfZQNedqv92A5ZkVMfKi4NSeTCZTZtioc= Received: from MW3PR11MB4570.namprd11.prod.outlook.com (2603:10b6:303:5f::22) by CO1PR11MB5092.namprd11.prod.outlook.com (2603:10b6:303:6e::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.16; Fri, 22 Oct 2021 13:22:35 +0000 Received: from MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::5855:1d90:e596:d998]) by MW3PR11MB4570.namprd11.prod.outlook.com ([fe80::5855:1d90:e596:d998%6]) with mapi id 15.20.4628.018; Fri, 22 Oct 2021 13:22:35 +0000 From: "Ketan Talaulikar (ketant)" To: "Wanghaibo (Rainsword)" , "bess@ietf.org" CC: "draft-ietf-bess-srv6-services@ietf.org" , "spring@ietf.org" , "Aissaoui, Mustapha (Nokia - CA/Ottawa)" , Shraddha Hegde Thread-Topic: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07) Thread-Index: Add5ZuxHtH2qrBhRQGK4/wpw+iW7/ADOgmjgAAC4i7gAAG45wACHp2JQAAGkXhAAP5xUIAACp5twAANe4IAKfvQKwAA9x5rgAAEGhpACXW/OgAS+a8SQ Date: Fri, 22 Oct 2021 13:22:35 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: huawei.com; dkim=none (message not signed) header.d=none;huawei.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4ee56340-22c8-4422-3d0a-08d9955f02da x-ms-traffictypediagnostic: CO1PR11MB5092: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: CNUFgnne+7ZCy6Z8VyS4iuBESNjaga3Ypu1ElGJrc32PhCeXkkBmnep6jNvBWQxUJ0IRAz1D8f0q3zB+01peco4NQoFAcP8v0vwtISf1rhzGJcjpmiuBQMdNB+oCc0fvFma8A3XKt4txMDnEYcpe40W7OBTn5RjjOBjfTkz9NCNZMFZ0x/pfAlLLwEPvbjiVOpRyIy4YZV9/jziZFSKQeXKIaBR1KMjrf853l7XfwSWh9f59hGyYM3RuxrfuPiN4lGNqNTnOX+F+ylPhrVy2r1W/SaLMZDywzUOhPXnjfiqvYk4dJsOA7+yl8X4io3dq/G5G+2gPrImZl+d0/AxLF8UyqBMSQfIe2TKb0UrEhPoeqm/zt75AsuEW7xncRGSCc0sAZ0c8vuEJ0PR/Gdlurr7ffpnF9IQuyOhMIwEU6MFr9QZb0HX7kkbs6B0c/hmauBYmsahqQdYYiEDtJCKXPr91+mCuByyzSJpWsE1GoBCC62zopwVbTCqW25E1G5hibjqhmjd2ZObr9tl5yeyfHAxKoCickTPkFY5b63AZvk2uoNch4EsLpHR5fcvN1BdGolhZ+gdrXvK8OhZ8j3eEXrEEPKAtvf0xNjh7KQbB/dYK4a1ulzsEtYzqclv6M6FQOv5zr9Hw+Wv0Np9bp8NMH/w3/JMPHVEeTzJfE8ukvTEjEqwFxBnGXTNpHlGZs7dtEKE4G9oYa85MZqxPGgNthQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MW3PR11MB4570.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(33656002)(316002)(53546011)(6506007)(76116006)(4326008)(54906003)(38070700005)(2906002)(52536014)(55016002)(9686003)(30864003)(38100700002)(8676002)(186003)(110136005)(8936002)(9326002)(7696005)(122000001)(5660300002)(66446008)(86362001)(508600001)(66946007)(26005)(66556008)(64756008)(66476007)(83380400001)(71200400001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-2022-jp?B?NDZLd2dVT2p0VDdHTDBIU1NGYS8wckZxU09ESk4xNUlhMW1Xd3A5TWxy?= =?iso-2022-jp?B?QU4zYXBkNzk4MFRqNlF4ak05THFldFY5SUx3U1hkRUU3R21mbFUraUlI?= =?iso-2022-jp?B?SXBxWTVubDZ1M0VCUzBuNkxMZ2FBSlVsVVg3N05JWDV1SW1BM3FXWlJG?= =?iso-2022-jp?B?bnA5KzQ0NTZwVUkzNnRqTjR4bWV2cDljdUd0Y21VR2Y4N3BLYnU0M2Jq?= =?iso-2022-jp?B?UVNlWnVwempPTG1ITGhZVk4xTG0wcjlYeHJqVFlKTWFLakx6cUc2cW5r?= =?iso-2022-jp?B?b25BMTlUZHExTkhJekRGYVRvYUtnMWZ4NTVUSFVqazJlV0pGL0lob25i?= =?iso-2022-jp?B?Y3Q1ZUt1V3d6Z25Tb1lVbjhXWlEreWovRnhXRWZiTzJWOGxzbHBlQnRi?= =?iso-2022-jp?B?d3ZaME9hRFZtSE4zMU1VR1ozempOOG01RHBEbXQ2QnB1M0hMc0xudE5o?= =?iso-2022-jp?B?RUVTaUIxZHVlVDlaMXZRMWJNUDNaQ0ZTcThHMThSMytmNkhsejk3ZlpX?= =?iso-2022-jp?B?TWJ0K2hYT09xeld3T2ROY0VVTnQwV3N2M0JBalgybGJPMWRWck9aOXBH?= =?iso-2022-jp?B?eHdyM0J5a2hDcWo0ajhPVTY4SVoyRHMwNVZ0WXRJb3JiRk80UXJjaUVy?= =?iso-2022-jp?B?TkNBRmVhNHZhRWJxMUdNa1EyMVpReVJ0THQxaVk0RDR6aHBQZlV3RENt?= =?iso-2022-jp?B?cmttRFllOEYzSXJxb2tlNDJKMlk3N1RIT05BV1llbHRmSEY3b1BIZmdV?= =?iso-2022-jp?B?THMrdEpxL3d5NVRORzhwNVI2SmhjU2F0K0pRTjY1MUFOenpsWnBURkR1?= =?iso-2022-jp?B?UWMwNDBGVlFuRWJvQmhWQ0NwSHFVbVB3SjcveUdiUVk1d2I1OWNHTjdE?= =?iso-2022-jp?B?VURZU1diQjZCRnRqNnZ3a3paMSsrU2pXY2JmN2JUcjcvb0g4MDZHVEZE?= =?iso-2022-jp?B?Mnh5MEpTeTZFdU91MHVJdWEya0VYV3h0alMrV05XUG54bFI2YVFtclBZ?= =?iso-2022-jp?B?amhFRXJnTnF3T2p1cVdaZDBJY2hGWkpHM0gvQ3FWVytkOHQwR2lqazhs?= =?iso-2022-jp?B?L2o0ZlpDSnlWQnRpci9zR0tkdDBYRzdMQnZMUkFNRDYydWt0ZEtCbnJ2?= =?iso-2022-jp?B?YmpSa29ZbUltZEdXMGd4K1Y4WSt2d3lrcjlncEM0RUc2VXdpOFJPTFRa?= =?iso-2022-jp?B?VHdZbStXWjJIMkYxakhEemg5RzMyeHNHOEdDWkI1aFlKczZ0WXIxaU5r?= =?iso-2022-jp?B?eXdIVHlESXpRK1lXczEvWTREay9uYUJ2dHlHZU5EUmo0T1RrK1pDVWFT?= =?iso-2022-jp?B?cjhIQ09BZno5cmwzMEJpZy9hbFliUktENHVPS1BjYjh6SGdMaUlWY0xk?= =?iso-2022-jp?B?cVBOc2hCMEkyYWxPZEhFeGN2dWM1dllDVk1KM0FxV3M3Qit4VlVXQ1VV?= =?iso-2022-jp?B?YUhXVkJDaDlUclhXbGZ4K1JJTWJ0MHZxMTVWT0xXbXQ5MlVoUEJwaXhV?= =?iso-2022-jp?B?VWdVZ2k2ck40clVzU3FleHlablZmWlY5aFJSYXFOd21ITTBUOTlQdjVl?= =?iso-2022-jp?B?U2pWeEJYcURqMHRYQ0cwK0tFejdEM0EreGRsSHV2S3FZRTk3UDJTRldU?= =?iso-2022-jp?B?Qys5cUxHeWtJS2FoYkp4Y0tETE9UNjRDZEx1SUNDaFZZbS9HUGJGckhQ?= =?iso-2022-jp?B?V25HejJxekR5TmpjYUQ4TlM2SFBNZFRiaVcya1FjRitaM0s4WlBIQTRM?= =?iso-2022-jp?B?Z3FYWGc2Y0lZVmZxcWhISWFMQ1EvdGQ5em9qbU9OU0xFbm1ScjZtOGFi?= =?iso-2022-jp?B?eW9Qc2FreWdLaFBFOFF2OVVMSnR0VFJ4U2pMeXpOZyttM0t4R3VraDhY?= =?iso-2022-jp?B?cVlwbkV0SHhVcTV6SW1YVW1GVlZ3SlhIbnRWYTlzckkyU2JLV28yYklV?= =?iso-2022-jp?B?RE5ZbHpSdFA1dGNIY1plc2twdVNEYnB1a1QyYjRRRzN0eU0zSEwyaXhN?= =?iso-2022-jp?B?MnI4NGpUTmxIeWlSWTV2NldVYVhic1VOZThkV3VqU01sdjNOSitVU0N0?= =?iso-2022-jp?B?b3FiOGsvSnZ2R293NDFYd2NFS2ZvNkk9?= Content-Type: multipart/alternative; boundary="_000_MW3PR11MB4570414BEDE5659015F89733C1809MW3PR11MB4570namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MW3PR11MB4570.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4ee56340-22c8-4422-3d0a-08d9955f02da X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2021 13:22:35.1366 (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: ketant@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB5092 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xbe-aln-005.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services-07) 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, 22 Oct 2021 13:22:52 -0000 --_000_MW3PR11MB4570414BEDE5659015F89733C1809MW3PR11MB4570namp_ Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable Hi Haibo, Thanks for your feedback and confirmation. Indeed the =1B$B!H=1B(Balternate= steering mechanism=1B$B!I=1B(B is better. Will push this change in the nex= t revision. Thanks, Ketan From: Wanghaibo (Rainsword) Sent: 28 September 2021 15:31 To: Ketan Talaulikar (ketant) ; bess@ietf.org Cc: draft-ietf-bess-srv6-services@ietf.org; spring@ietf.org; Aissaoui, Must= apha (Nokia - CA/Ottawa) ; Shraddha Hegde Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services= -07) Hi Ketan, I=1B$B!G=1B(Bm sorry I have missed your reply. For SRv6 services, we may have two choice for service. Use SRv6 SID to do b= est effort, or use to steering to a SRv6 Policy=1B$B!#=1B(B Also we may use both of them, but most time we are priority to use the SRv6= Policy than fall-back to SRv6 best effort, while SRv6 Policy is down. So I think maybe use =1B$B!H=1B(Balternate steering mechanism=1B$B!I=1B(B i= s better. Or maybe I misunderstood the sentence? Regards, Haibo From: Ketan Talaulikar (ketant) [mailto:ketant@cisco.com] Sent: Thursday, September 16, 2021 4:55 PM To: Wanghaibo (Rainsword) >; bess@ietf.org Cc: draft-ietf-bess-srv6-services@ietf.org; spring@ietf.org; Aissaoui, Mustapha= (Nokia - CA/Ottawa) >; Shraddha Hegde > Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services= -07) Hi Haibo, Since the discussion on the list was related to fallback mechanisms, we hav= e those words. How about s/fallback mechanism /alternate steering mechanism ? Or please su= ggest if you had something else in your mind. Thanks, Ketan From: Wanghaibo (Rainsword) > Sent: 16 September 2021 14:13 To: Ketan Talaulikar (ketant) >; = bess@ietf.org Cc: draft-ietf-bess-srv6-services@ietf.org; spring@ietf.org; Aissaoui, Mustapha= (Nokia - CA/Ottawa) >; Shraddha Hegde > Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services= -07) Hi Ketan, I think the overall description is OK. But is it appropriate to use = the word =1B$B!H=1B(Bfallback mechanism=1B$B!I=1B(B? Regards, Haibo From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Ketan Talaulikar= (ketant) Sent: Wednesday, September 15, 2021 11:00 AM To: bess@ietf.org Cc: draft-ietf-bess-srv6-services@ietf.org; spring@ietf.org; Aissaoui, Mustapha= (Nokia - CA/Ottawa) >; Shraddha Hegde > Subject: Re: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6= -services-07) Hello All, Getting back on this topic with a text update proposal for sec 5 and 6 of t= he draft. The objective of this change is to clarify the use of the SHOULD that is us= ed in this text. OLD/CURRENT When providing best-effort connectivity to the egress PE, the ingress PE encapsulates the payload in an outer IPv6 header where the destination address is the SRv6 Service SID associated with the related BGP route update. Therefore, the ingress PE SHOULD perform resolvability check for the SRv6 Service SID before considering the received prefix for the BGP best path computation. NEW When the steering for SRv6 services is based on shortest path forwarding= (e.g., best-effort or IGP Flexible Algorithm [I-D.ietf-lsr-flex-algo]) to = the egress PE, the ingress PE encapsulates the payload in an outer IPv6 header where the destination address is the SRv6 Service SID associated with the related BGP route update. Therefore, the ingress PE SHOULD perform resolvability check for the SRv6 Service SID before considering the received prefix for the BGP best path computation. The result of an SRv6 Service SID reachability (e.g. when provided via IGP Flexible Algorithm) can be ignored if the ingress PE has a local policy that allows a fallback mechanism to reach the egress PE. The details of such fallback mechanisms is outside the scope of this document. Please let know your feedback. The authors will look to incorporate this ch= ange along with any other comments as part of the AD review updates. Thanks, Ketan From: Aissaoui, Mustapha (Nokia - CA/Ottawa) > Sent: 23 July 2021 22:10 To: Ketan Talaulikar (ketant) > Cc: spring@ietf.org; Shraddha Hegde >; bess@ietf.org; = draft-ietf-bess-srv6-services@ietf.org Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services= -07) That is great. Thank you. Mustapha. From: Ketan Talaulikar (ketant) > Sent: Friday, July 23, 2021 11:08 AM To: Aissaoui, Mustapha (Nokia - CA/Ottawa) > Cc: spring@ietf.org; Shraddha Hegde >; bess@ietf.org; = draft-ietf-bess-srv6-services@ietf.org Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services= -07) < trimming list to mostly mailers > Hi Mustapha, I agree. Also after seeing Shraddha=1B$B!G=1B(Bs latest email, the coverage and deta= ils for the fallback mechanisms that she seems to be looking for is quite v= ast and better tackled in a separate document since this one has completed = its WGLC. Some of those concepts are applicable for MPLS as well and not SR= v6 specific. We (authors) will work on some text proposal and get back to the WG next we= ek. Thanks, Ketan From: Aissaoui, Mustapha (Nokia - CA/Ottawa) > Sent: 23 July 2021 19:20 To: Ketan Talaulikar (ketant) >; = Rajesh M >; Rajesh M >; Rabadan, Jorge (Nokia - US/Mou= ntain View) >; gdaw= ra.ietf@gmail.com; Clarence Filsfils (cfilsfi= l) >; robert@raszuk.net; bruno.decraene@orange.com Cc: spring@ietf.org; bgp@ans.net; Srihari Sangli >; Shradd= ha Hegde >; bess@ietf.org= Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services= -07) Hi Ketan, I believe it will be worth expanding the text in draft-ietf-bess-srv6-servi= ces to describe the two types of transport more consistently and along the = lines of what you wrote below. Also, I would propose that we move away from= terminology like best-effort service and instead just mention shortest pat= h forwarding in base topology or in flex-algo topology. Mustapha. From: spring > On B= ehalf Of Ketan Talaulikar (ketant) Sent: Thursday, July 22, 2021 3:43 AM To: Rajesh M >; Rajesh M >; Rabadan, Jorge (Nokia - US/Mountain View) >; gdawra.ietf@gmail.com; Clarence Filsfils (cfilsfil) >; robert@raszuk.net; bruno.decra= ene@orange.com Cc: spring@ietf.org; bgp@ans.net; Srihari Sangli >; Shradd= ha Hegde >; bess@ietf.org= Subject: Re: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6= -services-07) Hi Rajesh, My apologies for the delay in my response. However, some of my co-authors a= nd other WG members have already clarified this point. Let me try to summar= ize. The draft covers two SRv6 based mechanisms for the transport of services be= tween SRv6 PEs. (1) using SR Policy based steering (i.e. for service routes= with Color Extended Communities) using the H.encap construct along with a = list of SRv6 segments and the other (2) using H.encap with just the SRv6 S= ervice SID in the IPv6 DA. As mentioned in the draft, it is required to verify the reachability of the= SRv6 Service SID before the mechanism (2) can be used. This is an explicit= clarification for verification of reachability. In an MPLS-VPN scenario, i= f the egress PE NH=1B$B!G=1B(Bs IP route is reachable at the ingress PE but= without an MPLS label, such a path cannot be used. This is semantically si= milar. The mechanism (1) is different since the routing to the egress PE is via SR= Policy and hence the requirement for verification of reachability of the S= Rv6 Service SID is not there. There is no mandate for the setting of the NH since that is left to deploym= ent design. I hope this helps in addition to the various clarifications already provide= d by others. Thanks, Ketan From: Rajesh M > Sent: 22 July 2021 12:09 To: Rajesh M >; Rabadan, Jorge (Nokia - US/Mountain View) >; Ketan Talaulikar (keta= nt) >; gdawra.ietf@gmail.com; Clarence Filsfils (cfilsfil) >; robert@raszuk.net; = bruno.decraene@orange.com Cc: spring@ietf.org; bgp@ans.net; Shraddha Hegde >; bess= @ietf.org; Srihari Sangli > Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services= -07) Could Authors respond to this ? Juniper Business Use Only From: Rajesh M > Sent: Monday, July 19, 2021 7:28 PM To: Rabadan, Jorge (Nokia - US/Mountain View) >; Rajesh M >; Ketan Talaulikar (ketant) >; gdawra.ietf@gmail.com; Clarence Fi= lsfils (cfilsfil) >; robert@r= aszuk.net; bruno.decraene@orange.com Cc: spring@ietf.org; bgp@ans.net; Shraddha Hegde >; bess= @ietf.org; Srihari Sangli > Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services= -07) [External Email. Be cautious of content] Hi All, For best effort service, flex algo - Resolve SRv6 Service SID for forwardin= g. For SR-TE, CAR/CT - Resolve BGP next hop for forwarding. There is no unification here, it=1B$B!G=1B(Bs better to unify. Any other solution is OK. Thanks Rajesh Juniper Business Use Only From: Rabadan, Jorge (Nokia - US/Mountain View) > Sent: Monday, July 19, 2021 7:17 PM To: Rajesh M >; Rajesh M >; Ketan Talaulikar (ketant) >; gdawra.ietf@gmail.com; Clarence Filsf= ils (cfilsfil) >; robert@rasz= uk.net; bruno.decraene@orange.com Cc: spring@ietf.org; bgp@ans.net; Shraddha Hegde >; bess= @ietf.org; Srihari Sangli > Subject: Re: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services= -07) [External Email. Be cautious of content] Hi Rajesh, The draft is written so that the next-hop address MAY be covered by the loc= ator, but there are cases in which the next-hop address is not part of the = locator prefix, and there are implementations already allowing that, so I d= on=1B$B!G=1B(Bt agree the document should mandate what you are suggesting. Thanks. Jorge From: Rajesh M > Date: Monday, July 19, 2021 at 3:24 PM To: Rajesh M >, Ketan Talaulikar (ketant) >, gdawra.ietf@gmail.com = >, Clarence Filsfils (c= filsfil) >, robert@raszuk.net= >, b= runo.decraene@orange.com >, Rabadan, Jorge (Nokia - US/M= ountain View) > Cc: spring@ietf.org >, bgp@ans.net >, Shraddha Hegde >, bes= s@ietf.org >, Sri= hari Sangli > Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-services= -07) Hi Authors, Please respond. Thanks Rajesh Juniper Business Use Only From: spring > On B= ehalf Of Rajesh M Sent: Thursday, July 15, 2021 4:36 PM To: Ketan Talaulikar (ketant) >; = gdawra.ietf@gmail.com; Clarence Filsfils (cfi= lsfil) >; robert@raszuk.net; bruno.decraene@orange.com; jorge.rabadan@nokia.com Cc: spring@ietf.org; bgp@ans.net; Shraddha Hegde >; bess= @ietf.org Subject: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-ser= vices-07) [External Email. Be cautious of content] Hi All, As per this draft, this is how resolution must work. 1)For Non Intent service Route: if BGP next hop is not reachable return. Resolve SRv6 Service SID for forwarding. 2)For Intent service Route (IGP Flex-Algo first then BGP CAR then SR Policy= ): BGP next hop is not reachable return. Resolve SRv6 Service SID for forwarding(To find IGP flex algo).if successfu= lly resolves then return. Resolve BGP next hop for forwarding (in case above is not success). Using Service SID (overlay),for resolution is definitely not recommended. Instead in case of srv6, we always resolve on BGP nexthop. This will be in = line with BGP legacy. In case of best effort/flex algo we must mandate user to set corresponding = locator as BGP nexthop for srv6 routes. I think this is a reasonable mandate. Thanks Rajesh Juniper Business Use Only --_000_MW3PR11MB4570414BEDE5659015F89733C1809MW3PR11MB4570namp_ Content-Type: text/html; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable

    Hi Haibo,=

    &nbs= p;

    Thanks fo= r your feedback and confirmation. Indeed the =1B$B!H=1B(Balternate steering= mechanism=1B$B!I=1B(B is better. Will push this change in the next revisio= n.

    &nbs= p;

    Thanks,

    Ketan

    &nbs= p;

    From: Wanghaibo (Rainsword) <rainsword.wang@huawei.com>
    Sent: 28 September 2021 15:31
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; bess@ietf.or= g
    Cc: draft-ietf-bess-srv6-services@ietf.org; spring@ietf.org; Aissaou= i, Mustapha (Nokia - CA/Ottawa) <mustapha.aissaoui@nokia.com>; Shradd= ha Hegde <shraddha@juniper.net>
    Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-s= ervices-07)

     

    Hi Ketan,=

    &nbs= p;

    I=1B$B!G= =1B(Bm sorry I have missed your reply.

    &nbs= p;

    For SRv6 = services, we may have two choice for service. Use SRv6 SID to do best effor= t, or use <N,C> to steering to a SRv6 Policy=1B$B!#=1B(B

    Also we m= ay use both of them, but most time we are priority to use the SRv6 Policy t= han fall-back to SRv6 best effort, while SRv6 Policy is down.

    So I thin= k maybe use =1B$B!H=1B(Ba= lternate steering mechanism=1B$B!I=1B(B is better.  Or maybe I misunde= rstood the sentence?

    &nbs= p;

    Regards,<= o:p>

    Haibo

     

    From: Ketan Talaulikar (ketant) [= mailto:ketant@cisco.com]
    Sent: Thursday, September 16, 2021 4:55 PM
    To: Wanghaibo (Rainsword) <rainsword.wang@huawei.com>; bess@ietf.org
    Cc: draft-= ietf-bess-srv6-services@ietf.org; spring@ietf.org; Aissaoui, Mustapha = (Nokia - CA/Ottawa) <must= apha.aissaoui@nokia.com>; Shraddha Hegde <shraddha@juniper.net>
    Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-s= ervices-07)

     

    Hi Haibo,=

    &nbs= p;

    Since the= discussion on the list was related to fallback mechanisms, we have those w= ords.

    &nbs= p;

    How about= s/fallback mechanism /alternate steering mechanism ? Or please suggest if = you had something else in your mind.

    &nbs= p;

    Thanks,

    Ketan

    &nbs= p;

    From: Wanghaibo (Rainsword) <rainsword.wang@huawei.com>
    Sent: 16 September 2021 14:13
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; bess@ietf.org
    Cc: draft-= ietf-bess-srv6-services@ietf.org; spring@ietf.org; Aissaoui, Mustapha = (Nokia - CA/Ottawa) <must= apha.aissaoui@nokia.com>; Shraddha Hegde <shraddha@juniper.net>
    Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-s= ervices-07)

     

    Hi Ketan,

     

      &nbs= p;    I think the overall description is OK. But is it appro= priate to use the word =1B$B!H=1B(Bf= allback mechanism=1B$B!I=1B(= B?

     

    Regards,

    Haibo=

     

    From: spring [mailto:sprin= g-bounces@ietf.org] On Behalf Of Ketan Talaulikar (ketant)
    Sent: Wednesday, September 15, 2021 11:00 AM
    To: bess@ietf.org
    Cc: draft-= ietf-bess-srv6-services@ietf.org; spring@ietf.org; Aissaoui, Mustapha = (Nokia - CA/Ottawa) <must= apha.aissaoui@nokia.com>; Shraddha Hegde <shraddha@juniper.net>
    Subject: Re: [spring] SRv6 BGP based Overlay Services (draft-ietf-be= ss-srv6-services-07)

     

    Hello All= ,

    &nbs= p;

    Getting b= ack on this topic with a text update proposal for sec 5 and 6 of the draft.=

    &nbs= p;

    The objec= tive of this change is to clarify the use of the SHOULD that is used in thi= s text.

    &nbs= p;

    OLD/CURRE= NT

       When providing best-effort connec= tivity to the egress PE, the ingress

       PE encapsulates the payload in an= outer IPv6 header where the

       destination address is the SRv6 S= ervice SID associated with the

       related BGP route update.  T= herefore, the ingress PE SHOULD perform

       resolvability check for the SRv6 = Service SID before considering the

       received prefix for the BGP best = path computation.

     

    NEW

       When the steering for SRv6 services is based on shortest path forwarding (e.g= ., best-effort or IGP Flexible Algorithm [I-D.ietf-lsr-flex-algo]) to t= he egress PE, the ingress

       PE encapsulates the paylo= ad in an outer IPv6 header where the

       destination address is the SRv= 6 Service SID associated with the

       related BGP route update. = ; Therefore, the ingress PE SHOULD perform

       resolvability check for the SR= v6 Service SID before considering the

       received prefix for the BGP be= st path computation.  The result of an

       SRv6 Service SID reachabili= ty (e.g. when provided via IGP Flexible

       Algorithm) can be ignored i= f the ingress PE has a local policy that

       allows a fallback mech= anism to reach the egress PE. The details of

       such fallback mechanis= ms is outside the scope of this document.

    &nbs= p;

    Please le= t know your feedback. The authors will look to incorporate this change alon= g with any other comments as part of the AD review updates.

    &nbs= p;

    Thanks,

    Ketan

    &nbs= p;

    From: Aissaoui, Mustapha (Nokia - CA/Ottawa) <mustapha.aissaoui@nokia.com>
    Sent: 23 July 2021 22:10
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Cc: spring@ietf.org; Shraddha= Hegde <shraddha@juniper.net= >; bess@ietf.org; draft-ietf-bess-srv6-services@ietf.org
    Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-s= ervices-07)

     

    That is gre= at. Thank you.

     =

    Mustapha.

     =

    From: Ketan Talaulikar (ketant) <ketant@cisco.com>
    Sent: Friday, July 23, 2021 11:08 AM
    To: Aissaoui, Mustapha (Nokia - CA/Ottawa) <mustapha.aissaoui@nokia.com>
    Cc: spring@ietf.org; Shraddha= Hegde <shraddha@juniper.net= >; bess@ietf.org; draft-ietf-bess-srv6-services@ietf.org
    Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-s= ervices-07)

     

    < trim= ming list to mostly mailers >

    &nbs= p;

    Hi Mustap= ha,

    &nbs= p;

    I agree. =

    &nbs= p;

    Also afte= r seeing Shraddha=1B$B!G=1B(Bs latest email, the coverage and details for t= he fallback mechanisms that she seems to be looking for is quite vast and b= etter tackled in a separate document since this one has completed its WGLC. Some of those concepts are applicable for MPLS= as well and not SRv6 specific.

    &nbs= p;

    We (autho= rs) will work on some text proposal and get back to the WG next week.<= /o:p>

    &nbs= p;

    Thanks,

    Ketan

    &nbs= p;

    From: Aissaoui, Mustapha (Nokia - CA/Ottawa) <mustapha.aissaoui@nokia.com>
    Sent: 23 July 2021 19:20
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; Rajesh M <mrajesh@juniper.net>; Rajesh M <mrajesh@juniper.net>; Rabadan, Jorge (Nokia - US/Mountain View) <jorge.r= abadan@nokia.com>; gdawra.ietf@gmail.com; Clarenc= e Filsfils (cfilsfil) <cfilsfil@ci= sco.com>; robert@raszuk.net; bruno.decraene@orange.com
    Cc: spring@ietf.org; bgp@ans.net; Srihari Sangli <= ssangli@juniper.net>; Shraddha Hegde <shraddha@juniper.net>; bess@ietf.org
    Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-s= ervices-07)

     

    Hi Ketan,

    I believe i= t will be worth expanding the text in draft-ietf-bess-srv6-services to desc= ribe the two types of transport more consistently and along the lines of what you wrote below. Also, I would propose that we= move away from terminology like best-effort service and instead just menti= on shortest path forwarding in base topology or in flex-algo topology.=

     =

    Mustapha.

     =

    From: spring <spring-bo= unces@ietf.org> On Behalf Of Ketan Talaulikar (ketant)
    Sent: Thursday, July 22, 2021 3:43 AM
    To: Rajesh M <mrajesh@juni= per.net>; Rajesh M <mrajesh=3D40juniper.net@dmarc.ietf.org>; Rabadan, Jorge= (Nokia - US/Mountain View) <= jorge.rabadan@nokia.com>; gdawra.ietf@gmail.com; Clarenc= e Filsfils (cfilsfil) <cfilsfil@ci= sco.com>; robert@raszuk.net; bruno.decraene@orange.com
    Cc: spring@ietf.org; bgp@ans.net; Srihari Sangli <= ssangli@juniper.net>; Shraddha Hegde <shraddha@juniper.net>; bess@ietf.org
    Subject: Re: [spring] SRv6 BGP based Overlay Services (draft-ietf-be= ss-srv6-services-07)

     

    Hi Rajesh= ,

    &nbs= p;

    My apolog= ies for the delay in my response. However, some of my co-authors and other = WG members have already clarified this point. Let me try to summarize.=

    &nbs= p;

    The draft= covers two SRv6 based mechanisms for the transport of services between SRv= 6 PEs. (1) using SR Policy based steering (i.e. for service routes with Col= or Extended Communities) using the H.encap construct along with a list of SRv6 segments  and the other (2) using= H.encap with just the SRv6 Service SID in the IPv6 DA.

    &nbs= p;

    As mentio= ned in the draft, it is required to verify the reachability of the SRv6 Ser= vice SID before the mechanism (2) can be used. This is an explicit clarific= ation for verification of reachability. In an MPLS-VPN scenario, if the egress PE NH=1B$B!G=1B(Bs IP route is reac= hable at the ingress PE but without an MPLS label, such a path cannot be us= ed. This is semantically similar.

    &nbs= p;

    The mecha= nism (1) is different since the routing to the egress PE is via SR Policy a= nd hence the requirement for verification of reachability of the SRv6 Servi= ce SID is not there.

    &nbs= p;

    There is = no mandate for the setting of the NH since that is left to deployment desig= n.

    &nbs= p;

    I hope th= is helps in addition to the various clarifications already provided by othe= rs.

    &nbs= p;

    Thanks,

    Ketan

    &nbs= p;

    From: Rajesh M <mrajesh@jun= iper.net>
    Sent: 22 July 2021 12:09
    To: Rajesh M <mrajesh=3D40juniper.net@dmarc.ietf.org>; Rabadan, Jorge (Noki= a - US/Mountain View) <jorge.= rabadan@nokia.com>; Ketan Talaulikar (ketant) <ketant@cisco.com>; gdawra.ietf@gmail.com; Clarence Filsfils (cfilsfil) <cfilsfil@cisco.com>; robert@raszuk.net; bruno.decraene@orange.com
    Cc: spring@ietf.org; bgp@ans.net; Shraddha Hegde <shraddha@juniper.net>; bess@ietf.org; Srihari Sangli <ssangli@juniper.net>
    Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-s= ervices-07)

     

    Could Authors respond to this ?

     

     

    Juniper Business= Use Only

    From: Rajesh M <mrajesh=3D40juniper.net@dmarc.ietf.org>
    Sent: Monday, July 19, 2021 7:28 PM
    To: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>; Rajesh M <mrajesh@juniper.net>; Ketan Talau= likar (ketant) <ketant@cisco.com= >; gdawra.ietf@gmail.com; Clarenc= e Filsfils (cfilsfil) <cfilsfil@ci= sco.com>; robert@raszuk.net; bruno.decraene@orange.com
    Cc: spring@ietf.org; bgp@ans.net; Shraddha Hegde <shraddha@juniper.net>; bess@ietf.org; Srihari Sangli <ssangli@juniper.net>
    Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-s= ervices-07)

     

    <= span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:"Lato",= sans-serif;color:black">[External Email. Be cautious of content]=

     

    Hi All,

     

    For best effort service, flex algo – R= esolve SRv6 Service SID for forwarding.

    For SR-TE, CAR/CT - Resolve BGP next hop for forwarding.

     

    There is no unification here, it=1B$B!G=1B(Bs better to unif= y.

    Any other solution is OK.

     

    Thanks

    Rajesh

     

     

    Juniper Business= Use Only

    From: Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>
    Sent: Monday, July 19, 2021 7:17 PM
    To: Rajesh M <mrajesh@juni= per.net>; Rajesh M <mrajesh=3D40juniper.net@dmarc.ietf.org>; Ketan Talaulik= ar (ketant) <ketant@cisco.com>= ;; gdawra.ietf@gmail.com; Clarenc= e Filsfils (cfilsfil) <cfilsfil@ci= sco.com>; robert@raszuk.net; bruno.decraene@orange.com
    Cc: spring@ietf.org; bgp@ans.net; Shraddha Hegde <shraddha@juniper.net>; bess@ietf.org; Srihari Sangli <ssangli@juniper.net>
    Subject: Re: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-s= ervices-07)

     

    <= span lang=3D"EN-US" style=3D"font-size:10.5pt;font-family:"Lato",= sans-serif;color:black">[External Email. Be cautious of content]=

     

    Hi Rajesh,

     

    The draft is written so that the next-hop address MAY be c= overed by the locator, but there are cases in which the next-hop address is= not part of the locator prefix, and there are implementations already allowing that, so I don=1B$B!G=1B(Bt agree the= document should mandate what you are suggesting.

     

    Thanks.

    Jorge

     

    From: Rajesh M &= lt;mrajesh@juniper.net>
    Date: Monday, July 19, 2021 at 3:24 PM
    To: Rajesh M <mrajesh=3D40juniper.net@dmarc.ietf.org>, Ketan Talaulikar (ke= tant) <ketant@cisco.com>, gdawra.ietf@gmail.com <gdawra.ietf@gmail.com>, Clarenc= e Filsfils (cfilsfil) <cfilsfil@ci= sco.com>, robert@raszuk.net <robert@raszuk.net>, bruno.decraene@orange.com = <bruno.decraene@orange.com<= /a>>, Rabadan, Jorge (Nokia - US/Mountain View) <jorge.rabadan@nokia.com>
    Cc: spring@ietf.org <spring@ietf.org>, bgp@ans.net <bgp@ans.net>, Shraddha Hegde <shraddha@juniper.net>, bess@ietf.org <bess@ietf.org>, Srihari Sangli <ssangli@juniper.net>
    Subject: RE: SRv6 BGP based Overlay Services (draft-ietf-bess-srv6-s= ervices-07)

    Hi= Authors,

     

    Pl= ease respond.

     

    Th= anks

    Ra= jesh

     

     

    Juniper Business= Use Only

    From: spring <spring-bounces@ietf.org> On Behalf Of Rajesh M
    Sent: Thursday, July 15, 2021 4:36 PM
    To: Ketan Talaulikar (ketant) <ketant@cisco.com>; gdawra.ietf@gmail.com; Clarenc= e Filsfils (cfilsfil) <cfilsfil@ci= sco.com>; robert@raszuk.net; bruno.decraene@orange.com; j= orge.rabadan@nokia.com
    Cc: spring@ietf.org; bgp@ans.net; Shraddha Hegde <shraddha@juniper.net>; bess@ietf.org
    Subject: [spring] SRv6 BGP based Overlay Services (draft-ietf-bess-s= rv6-services-07)

     

    [External Email. Be cautious of content]

     

    Hi All,

     

    As per this draft, this is how = resolution must work.

     

    1)For Non Intent service Route:=

    if BGP next hop is not reachabl= e return.

    Resolve SRv6 Service SID for fo= rwarding.

     

    2)For Intent service Route (IGP= Flex-Algo first then BGP CAR then SR Policy):

    BGP next hop is not reachable r= eturn.

    Resolve SRv6 Service SID for fo= rwarding(To find IGP flex algo).if successfully resolves then return.<= /o:p>

    Resolve BGP next hop for forwar= ding (in case above is not success).

     

     

    Using Service SID (overlay),= for resolution is definitely not recommended.

     =

    Instead in case of srv6, we = always resolve on BGP nexthop. This will be in line with BGP legacy.

    In case of best effort/flex = algo we must mandate user to set corresponding locator as BGP nexthop for s= rv6 routes.

    I think this is a reasonable= mandate.

     

    Thanks

    Rajesh

     

    Juniper Business= Use Only

    --_000_MW3PR11MB4570414BEDE5659015F89733C1809MW3PR11MB4570namp_-- From nobody Fri Oct 22 09:38:02 2021 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 46C843A1129; Fri, 22 Oct 2021 09:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.452, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=By33UKmq; dkim=pass (1024-bit key) header.d=juniper.net header.b=KHQR91uI 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 7xDPTK0w0Dwe; Fri, 22 Oct 2021 09:36:15 -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 49EE53A1123; Fri, 22 Oct 2021 09:36:15 -0700 (PDT) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19MEmtrY017657; Fri, 22 Oct 2021 09:36:10 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=Rsrls+clzAiY9ltAmRRAFjiFQf3AuW2v/g3ueW0y39Q=; b=By33UKmqEssOZOYpzVOYn4JbrfmTDJLpER89w8NDWasTvOs5+FUi1QcIC62iq037AVkl LAuIKzybw0wOLHxJi6BMFM0e0OS0+sXK8QspkkDNtu9EeDNk+LyOlmCI+wvPqjZTEia0 gDkqPUaUmbHx1PV7+BwlF1ioENIIES3tPFFoP7pKv7vcJRnFoEqaLaDbl/pXF8nFuXsA af9/bAHglACtP7Pu3IN8X6Pi9Kwzs8W+tHJbq9uD/HPhakgBawYqd/LYqf8scHmzD2FQ i+rO63+QX0RAOGmiHEexWvAJjSlN1zYAfh1lhLeQkLPBgq9C2apBT6jrFYv4GYI5YEgM 7A== Received: from nam04-mw2-obe.outbound.protection.outlook.com (mail-mw2nam08lp2168.outbound.protection.outlook.com [104.47.73.168]) by mx0b-00273201.pphosted.com with ESMTP id 3buyd3060p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 22 Oct 2021 09:36:07 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=apEqyHH7hFbpqp6JUHxQomT7LfumUpdNZUlKJbBvOfNziu8ZclAn2mpaH/N/Qgzn0YRB0dcJqHW06rCBD1KKPuy4K+YMNfvFe9coEkS8Oshlg5faYsnyNvSTtgBQJXzo4I/MLHAhXgDHCIih4c78yjwJ54ZsjdURX/pMDDY1xxlYbTDL08KllXgDkh29meKb+HlYX3iud1wqzmKNZsSasYI1j4RwTHAjPf1R7hsskOrCxNE/qtjim8vI9PFi8dFPP5id2pVMVO0TJuB/8PhKTz5Yt/Zizs22FypTa0Wue2ySg2GGQX4nFmvUtSHBQ5Mhj0lhwyh2yuktLVqDthkOzg== 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=Rsrls+clzAiY9ltAmRRAFjiFQf3AuW2v/g3ueW0y39Q=; b=CNY0etinCJIahr5FPV15QInyFHzAbPE1r2ZauvaJjvpMilWG2KSpV/fanS2b2MY8nBDsUgIFBUkY1TxZQVkAU0lynT9G+rKJVD400aFXoKmgTt4R7AVHoOixBNEh6hRg6JxHICWFPfYbTR53+j9ahFdDgpOSGKD2Rzujxkwkc85AX2aJtuxK4pNDLTtUp34Ak6EKxbsIAqSO2JF81x4fw9fQjGlun+f93JlAtnnNi3B1K1hh0wUEo/6B3LuzSz88sZRFCAebhMqzYGNR0+EUSOF/Ke1baglLkVcvpLOywTp8sdQLtfyD0efHWszL1gbtcHg7r33LIUqwWM7qxUvojg== 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=Rsrls+clzAiY9ltAmRRAFjiFQf3AuW2v/g3ueW0y39Q=; b=KHQR91uIG7IW3q2/hXiae86B/+Ldcqw64kK8x8/eD5blL0FVSNIhDABktdc89/QT8P/Y9DsA8rgDAq5zbgw732umDtw/HcONsvVLu2JGaVXIqvSjUGX+YjQf2DD1YW0cZ6WF1jIkcq8+l+YOMqGdctzrVe6zoCbpK/q50aGbed0= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by BL0PR05MB5012.namprd05.prod.outlook.com (2603:10b6:208:86::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.13; Fri, 22 Oct 2021 16:35:55 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4628.018; Fri, 22 Oct 2021 16:35:54 +0000 From: Ron Bonica To: "Darren Dukes (ddukes)" , SPRING WG , 6MAN <6man@ietf.org> Thread-Topic: CSID proposed clarifications Thread-Index: AQHXwPmD76WD43ON70uWpO9ECDy+ZqvfQvYg Date: Fri, 22 Oct 2021 16:35:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.100.41 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-22T16:32:51Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=aaae35be-1da9-4e29-a022-f3f73cf08b29; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_enabled: true msip_label_0633b888-ae0d-4341-a75f-06e04137d755_setdate: 2021-10-22T16:35:52Z msip_label_0633b888-ae0d-4341-a75f-06e04137d755_method: Standard msip_label_0633b888-ae0d-4341-a75f-06e04137d755_name: 0633b888-ae0d-4341-a75f-06e04137d755 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_siteid: bea78b3c-4cdb-4130-854a-1d193232e5f4 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_actionid: 2cd23363-fcef-4f85-8015-95b7e238e430 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_contentbits: 0 authentication-results: dmarc.ietf.org; dkim=none (message not signed) header.d=none; dmarc.ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eba72253-32e6-4f58-5d7e-08d9957a04c0 x-ms-traffictypediagnostic: BL0PR05MB5012: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: mVE4Z+GAf0JLg8sj4VkiZthFnzZGk/9HshWGUBWvIpgY0vDwLnzujGxgQXDXs2K8g2j/Adfh2pJU/jnv3iFz9xdWr+uJXTMRYwChMi0JiP6snvxDhe6RSc2pjksRtG+LCw1w1Qx/uZ1+Lyj8M/nqNVcmpzaH9bUwqzWUL+mgBt2WPQV4RKtpIfqmoQ2pI/CiF9uo0REkxGu/vBZwva1BV/j3GnK0wJ/B03C4t+RIQYDiWWQE+SkcEZ6gZ/uPolUTxeJrxPF+fK572qFOk5RE9S5iTSMfseoUXhbL0bI6/oUuDtcOOfndYNRSWbSeiZk32Fv5qT8MaOVEjNKArj3Eqb8N0rpwhLGolPj5qOshxGcc3IPsELYBM3kTl9MMuJvvMjisk4Y+RUwSb+7tkGABF4PbOPgfvfOuzLSX52DxImDCUqBBoK7pamEzYXzoIL30mWFrEXC8GWnTEUJcC3w+X1G3+iceLANaTUu34R7Vt9l3EkrqZo1urfJFsEcNWN0bNt1Ipi7Gb1nGMExlRZBsusjUWfhfFrgXbC52QhMmsrz4VO7SkU8AjRCPt1xhiXFdujq+ZaJeiNoUlLjf5OyQPTxacMCPVL+P4ixfyfaoNhXAwajZ/vss+E22Nmcr8oZOUcU1Tk0E2bax624qFUHA+zpQpV3IHrQj3+wwPi0yH7s/NV+fcVZhSYAmAhAFi4idXO01AfmeOoJYShlFg1hhDA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(6506007)(66476007)(66556008)(110136005)(53546011)(7696005)(3480700007)(5660300002)(2906002)(66446008)(64756008)(55016002)(83380400001)(9686003)(38070700005)(66946007)(8676002)(7116003)(71200400001)(508600001)(86362001)(26005)(38100700002)(76116006)(52536014)(8936002)(122000001)(186003)(33656002)(316002); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?PhiLnlKAYibNxnd9Q3ImYKNb1ykfTfh5nO4sLUBrSyXFrY/j/gpWVh1z4/BY?= =?us-ascii?Q?eZTXrXc+6hfTuDG2u/ES+ni6DBj+dlpHElykxElCtnIzxctS8PthJJcGow0f?= =?us-ascii?Q?rhdyzHNBFjGOawhBrTTBuffelXN6YxCOpPpeKyFOEGXI8TF7WZnZZSy3hBLb?= =?us-ascii?Q?Ikp41nuDhUzj2RdqIJEi0Uclu7t0KfwaeJbhzHTQW/uSk8muh3qd7qtucptu?= =?us-ascii?Q?7bcTD+Uo2BpCV8aVGbq/pqOBEnayZbgNSTieqAPzQZ79kiPJw5iHwuCgyOLC?= =?us-ascii?Q?s7Hm7kiCd/ZSZnLG4/jIaqFcGTsvgbCqFupIVbA+9zYuF4F5ooSr8VAis+jj?= =?us-ascii?Q?2oFvXj+t+Il/ZgZcUV6+tYn8ZZB8Cqc0i1T2+El/Gu3ZQmtL0iaR8OrsY+xe?= =?us-ascii?Q?PvN2wgTEW3Ny0yRxPyU8/twBMRWXmphKdZ6qmIbpk8V5JeW5iKwXYSh0Xoo0?= =?us-ascii?Q?Ika+Ld5czjN2IynJtleHGoDVHN7UaB6/PmlM7YLCbv+Tn5wUXby2PT7c/HlT?= =?us-ascii?Q?CePsg4Pqqyva6m4BTtT30waxfEjLnZGXNtAz1uuFJSrpenpIjRC33A6KaACP?= =?us-ascii?Q?xPPqcAOBthzq5iziNKenE8fRyb4E2eQwOr77URqXfyRXeZ//Ec6zmkxB4kMA?= =?us-ascii?Q?nPTN+I55jj6Oq0jS3G1n8RoW2kbZApGgfCVSOv1dVJpD0npvgglgJhe+/lIu?= =?us-ascii?Q?INQEDdJSlzEkW/8KT3iUNsQ9ICHHx7zHjqCOHzbtNJjsPszbJmMPgCY3g5Lm?= =?us-ascii?Q?XXTu69icuS6qtXbwPeuonvNWfM6W2lRZs+Mvca6zyFqoCL8rJlfIkXtVhTwk?= =?us-ascii?Q?mVHMLXhO4DBw/I6BIdXq+SuvTFrobiLsQeyG/zUO8bh/2dVXVVHUhInmAeTT?= =?us-ascii?Q?FbS1XsqVTGydnyWia2Cu+LoxOONZ4HToo2zH82YJVHWphAYEHqOrZR9djJhG?= =?us-ascii?Q?mrFxReD2HkrY80wfflUZDsJnftMnzzfHgqOdUxhod3E+O3F4TCOr/lhSm+/D?= =?us-ascii?Q?2c6xoWMjAy4PKW4fO9XPyE+2wEJ/7nMlcAF2p2l22Duv5hue+CDksR9QDDKL?= =?us-ascii?Q?1YFCNjM8TWSSi7eCtto9eFv+j3qxHaIRcX5JsRwcxA3u7SLJmQzLVnunBzqa?= =?us-ascii?Q?pMB3NgBYnBnfuMWajY0dNv0GnK2JTjkabvz/cqu53Kvyaw11L/0iH0+OHemo?= =?us-ascii?Q?1CtXodBJJrP07Ky89WyqBRj0rZiHNgqqKC9VJTEReK2rO89d89ckNxl00Br5?= =?us-ascii?Q?MqpT19WR8SAbhapgf+ON84sRmo8zsI4ZXM/FU6pnPahSitTq3ZKvn+1Mor72?= =?us-ascii?Q?ECeHayU+S3dvXzrDPlRwLDJ7lQbOGNBmMdQKkycP3BPpiY+DFirEuhslNnQT?= =?us-ascii?Q?hkzYXEGdNyVCiS6iuhRQ24zWzFfaPIa1UZIl3MKOGCVFf2LxQQw+Mb1kaKpw?= =?us-ascii?Q?/8IFBk3f/zw=3D?= Content-Type: multipart/alternative; boundary="_000_BL0PR05MB53165EC96ADCD9349D339A6CAE809BL0PR05MB5316namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: eba72253-32e6-4f58-5d7e-08d9957a04c0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Oct 2021 16:35:54.6041 (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: rbonica@juniper.net X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5012 X-Proofpoint-GUID: SMQHPUzAM_IR2VYx_uK4ovfBYnSYtUGy X-Proofpoint-ORIG-GUID: SMQHPUzAM_IR2VYx_uK4ovfBYnSYtUGy X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-22_04,2021-10-22_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 malwarescore=0 priorityscore=1501 mlxscore=0 clxscore=1015 impostorscore=0 bulkscore=0 spamscore=0 mlxlogscore=999 adultscore=0 phishscore=0 lowpriorityscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109230001 definitions=main-2110220095 Archived-At: Subject: Re: [spring] CSID proposed clarifications 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, 22 Oct 2021 16:36:22 -0000 --_000_BL0PR05MB53165EC96ADCD9349D339A6CAE809BL0PR05MB5316namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, Could you update the draft to reflect the new pseudocode, below. It is esse= ntial to the 6man review. = Ron Juniper Business Use Only From: spring On Behalf Of Darren Dukes (ddukes) Sent: Thursday, October 14, 2021 8:54 AM To: SPRING WG Subject: [spring] CSID proposed clarifications [External Email. Be cautious of content] The NEXT-C-SID and REPLACE-C-SID flavors are functionally very similar. In both cases the SID in the IPv6 Destination Address (DA) contains an argu= ment, that argument is used to construct the next SID from the active segment in the SRH Segment List. I believe the following pseudocode is a much better description of their segment endpoint processing. You'll notice there is no manipulation of the bits in the IPv6 DA. I propose we replace the pseudocode in the draft with the following, stand-alone pseudocode, for the NEXT-C-SID and REPLACE-C-SID flavors of the END behavior (sections 4.1.1 and 4.2.1 respectively). Equivalent changes can be completed for the NEXT-C-SID and REPLACE-C-SID flavors of the END.X behavior (sections 4.1.2 and 4.2.2 respectively) and NEXT-AND-REPLACE-C-SID flavor. Comments are appreciated. Thanks Darren 4.1.1. End with NEXT-C-SID When processing an IPv6 packet that matches a FIB entry locally instantiated as an End SID with the NEXT-C-SID flavor, the SRH processing described in Section 4.1 of [RFC8986] is replaced as follows. S.01 When an SRH is processed { S.02 If (IPv6.DA.Argument =3D=3D 0 and SRH.SegmentsLeft =3D=3D 0) { S.03 Stop processing the SRH, and proceed to process the next header in the packet, whose type is identified by the Next Header field in the routing header. S.04 } S.05 If (IPv6.HopLimit <=3D 1) { S.06 Send an ICMP Time Exceeded message to the Source Address with Code 0 (Hop limit exceeded in transit), interrupt packet processing, and discard the packet. S.07 } S.08 # Determine the maximum SRH Last Entry S.09 Set maxLE to ((SRH.HdrExtLen / 2) - 1) S.10 Initialize 128-bit buffer memory S to 0. S.11 Initialize local parameter Argument to the value of IPv6.DA.Argument S.12 If (Argument =3D=3D 0) { S.13 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)= ) { S.14 Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S.15 } S.16 Decrement SRH.SegmentsLeft by 1 S.17 Set S to the value of SRH.SegmentList[SRH.SegmentsLeft] S.18 } S.19 Else { S.20 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)= ) { S.21 Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S.22 } S.23 Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common loc= ator block) S.24 If (SRH.SegmentsLeft > SRH.LastEntry) { S.25 Initialize local parameter ActiveSegment to the value of DA S.26 } S.27 Else { S.28 Initialize local parameter ActiveSegment to the value S.29 of SRH.SegmentList[SRH.SegmentsLeft] S.30 } S.31 Initialize local parameter BitLength to (CountTrailingZeros(ActiveS= egment) + AL - CountTrailingZeros(A= rgument)) S.32 Initialize local parameter BitIndex to (128 - BitLength) S.33 Set S[B..B+BitLength-1] to the value of ActiveSegment[BitIndex..(BitIndex+BitLength-1)] S.34 } S.35 Set IPv6.DA to the value of S S.36 Decrement IPv6.HopLimit by 1 S.37 Submit the packet to the egress IPv6 FIB lookup for transmission to the new destination. S.38 } 4.1.1.1 Upper layer header processing The upper-layer header processing described in Section 4.1.1 of [RFC8986] is replaced as follows. S.01 Initialize local parameter Argument to the value of IPv6.DA.Argument S.02 If (Argument !=3D 0) { # In this case, the SRH was not added by source # The source compressed it into the active segment in IPv6.DA # Build a pseudo header from the active segment in the IPv6.DA for = use # during processing. S.03 Initialize a 24-byte local SRH in memory to 0's for use below S.04 Set SRH.MaxHdrLen to 3 S.05 Set SRH.RoutingType to 4 S.06 Set SRH.SegmentsLeft to 0 S.07 Set SRH.SegmentList[0] to the value of IPv6.DA S.08 Process the SRH as per section 4.1.1, S.09 noting such processing is limited to the pseudo SRH S.10 since Argument is not 0. S.11 } S.12 If (Upper-Layer header type is allowed by local configuration) { S.13 Proceed to process the Upper-Layer header S.14 } Else { S.15 Send an ICMP Parameter Problem to the Source Address with Code 4 (SR Upper-layer Header Error) and Pointer set to the offset of the Upper-Layer header, interrupt packet processing, and discard the packet. S.16 } 4.2.1. End with REPLACE-C-SID When processing an IPv6 packet that matches a FIB entry locally instantiated as an End SID with the REPLACE-C-SID flavor, the SRH processing described in Section 4.1 of [RFC8986] is replaced as follows. S.01 When an SRH is processed { S.02 If (IPv6.DA.Argument =3D=3D 0 and SRH.SegmentsLeft =3D=3D 0) { S.03 Stop processing the SRH, and proceed to process the next header in the packet, whose type is identified by the Next Header field in the routing header. S.04 } S.05 If (IPv6.HopLimit <=3D 1) { S.06 Send an ICMP Time Exceeded message to the Source Address with Code 0 (Hop limit exceeded in transit), interrupt packet processing, and discard the packet. S.07 } S.08 # Determine the maximum SRH Last Entry S.09 Set maxLE to ((SRH.HdrExtLen / 2) - 1) S.10 Initialize 128-bit buffer memory S to 0. S.11 Initialize local parameter Argument to the value of IPv6.DA.Argument S.12 Initialize local parameter ActiveSegment to SRH.SegmentList[SRH.Segme= ntsLeft] S.13 If (Argument =3D=3D 0) { S.14 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)= ) { S.15 Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S.16 } S.17 Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common loc= ator block) S.18 Decrement SRH.SegmentsLeft by 1 S.19 Set Argument to (128 / NF - 1) S.20 } S.21 Else { S.22 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry)) = { S.23 Send an ICMP Parameter Problem to the Source Address with Code 0 (Erroneous header field encountered) and Pointer set to the Segments Left field, interrupt packet processing, and discard the packet. S.24 } S.25 Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common loc= ator block) S.26 Decrement Argument by 1 S.27 } S.28 Initialize local parameter BitLength to the value of NF S.29 Initialize local parameter BitIndex to (Argument * NF) S.30 Set S[B..B+BitLength-1] to the value of ActiveSegment[BitIndex..(BitIndex+BitLength-1)] S.32 Set S[B+BitLength..B+BitLength+A-1] to the value of Argument S.33 Set IPv6.DA to the value of S S.34 Decrement IPv6.HopLimit by 1 S.35 Submit the packet to the egress IPv6 FIB lookup for transmission S.36 to the new destination. S.37 } 4.2.1.1. Upper layer header processing The upper-layer header processing described in Section 4.1.1 of [RFC8986] i= s unchanged and reproduced below. S.01 If (Upper-Layer header type is allowed by local configuration) { S.02 Proceed to process the Upper-Layer header S.03 } Else { S.04 Send an ICMP Parameter Problem to the Source Address with Code 4 (SR Upper-layer Header Error) and Pointer set to the offset of the Upper-Layer header, interrupt packet processing, and discard the packet. S.05 } --_000_BL0PR05MB53165EC96ADCD9349D339A6CAE809BL0PR05MB5316namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Authors,=

     

    Could you update th= e draft to reflect the new pseudocode, below. It is essential to the 6man r= eview.

     

       &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;   Ron

     

     

     

    Juniper Business Use Only

    From:= spring <spring-bounces@ietf.org> On Behalf Of Darren Dukes (ddukes)
    Sent: Thursday, October 14, 2021 8:54 AM
    To: SPRING WG <spring@ietf.org>
    Subject: [spring] CSID proposed clarifications

     

    <= span lang=3D"EN-CA" style=3D"font-size:10.5pt;font-family:"Lato",= sans-serif;color:black">[External Email. Be cautious of content]=

     

    The NEXT-C-SID and REPLACE-C-SID flavors are functionally = very similar.

    In both cases the SID in the IPv6 Destination Address (DA)= contains an argument,

    that argument is used to construct the next SID from the a= ctive segment in

    the SRH Segment List.

     

    I believe the following pseudocode is a much better descri= ption of their

    segment endpoint processing. You’ll notice there is = no manipulation of

    the bits in the IPv6 DA.

     

    I propose we replace the pseudocode in the draft with the = following,

    stand-alone pseudocode, for the NEXT-C-SID and REPLACE-C-S= ID flavors

    of the END behavior (sections 4.1.1 and 4.2.1 respectively= ).

     

    Equivalent changes can be completed for the NEXT-C-SID and= REPLACE-C-SID

    flavors of the END.X behavior (sections 4.1.2 and 4.2.2 re= spectively) and

    NEXT-AND-REPLACE-C-SID flavor.

     

    Comments are appreciated.

     

    Thanks

      Darren

     

    4.1.1.  End with NEXT-C-SID<= /p>

     

    When processing an IPv6 packet that matches a FIB entry lo= cally

    instantiated as an End SID with the NEXT-C-SID flavor, the= SRH

    processing described in Section 4.1 of [RFC8986] is replac= ed as

    follows.

     

     

    S.01 When an SRH is processed {

    S.02  If (IPv6.DA.Argument =3D=3D 0 and SRH.SegmentsL= eft =3D=3D 0) {

    S.03     Stop processing the SRH, and = proceed to process the next

             header in= the packet, whose type is identified by

             the Next = Header field in the routing header.

    S.04  }

     

    S.05  If (IPv6.HopLimit <=3D 1) {

    S.06     Send an ICMP Time Exceeded me= ssage to the Source Address

             with Code= 0 (Hop limit exceeded in transit),

             interrupt= packet processing, and discard the packet.

    S.07  }

     

    S.08  # Determine the maximum SRH Last Entry

    S.09  Set maxLE to ((SRH.HdrExtLen / 2) - 1)

     

    S.10  Initialize 128-bit buffer memory S to 0.

    S.11  Initialize local parameter Argument to the valu= e of IPv6.DA.Argument

     

    S.12  If (Argument =3D=3D 0) {

    S.13    If ((SRH.LastEntry > maxLE) or (= SRH.SegmentsLeft > SRH.LastEntry+1)) {

    S.14      Send an ICMP Parameter = Problem to the Source Address

             &nbs= p; with Code 0 (Erroneous header field encountered)

             &nbs= p; and Pointer set to the Segments Left field,

             &nbs= p; interrupt packet processing, and discard the packet.

    S.15    }

     

    S.16    Decrement SRH.SegmentsLeft by 1

     

    S.17    Set S to the value of SRH.SegmentLi= st[SRH.SegmentsLeft]

    S.18  }

    S.19  Else {

    S.20    If ((SRH.LastEntry > maxLE) or (= SRH.SegmentsLeft > SRH.LastEntry+1)) {

    S.21      Send an ICMP Parameter = Problem to the Source Address

             &nbs= p;with Code 0 (Erroneous header field encountered)

             &nbs= p; and Pointer set to the Segments Left field,

             &nbs= p; interrupt packet processing, and discard the packet.

    S.22    }

     

    S.23    Set S[0..B-1] to the value of IPv6.= DA[0..B-1] (i.e., the common locator block)

     

    S.24    If (SRH.SegmentsLeft > SRH.LastE= ntry) {

    S.25      Initialize local parame= ter ActiveSegment to the value of DA

    S.26    }

    S.27    Else {

    S.28      Initialize local parame= ter ActiveSegment to the value

    S.29       of SRH.SegmentLis= t[SRH.SegmentsLeft]

    S.30    }

     

    S.31    Initialize local parameter BitLengt= h to (CountTrailingZeros(ActiveSegment) +

             &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;  AL - CountTrailingZeros(Argument))

    S.32    Initialize local parameter BitIndex= to (128 – BitLength)

     

    S.33    Set S[B..B+BitLength-1] to the valu= e of

             Acti= veSegment[BitIndex..(BitIndex+BitLength-1)]

    S.34  }

     

    S.35  Set IPv6.DA to the value of S=

     

    S.36  Decrement IPv6.HopLimit by 1<= /p>

     

    S.37  Submit the packet to the egress IPv6 FIB lookup= for transmission

           to the new destinatio= n.

    S.38 }

     

    4.1.1.1 Upper layer header processing=

     

    The upper-layer header processing described in Section 4.1= .1 of

    [RFC8986] is replaced as follows.

     

    S.01  Initialize local parameter Argument to the valu= e of IPv6.DA.Argument

    S.02  If (Argument !=3D 0) {

            # In this case,= the SRH was not added by source

            # The sour= ce compressed it into the active segment in IPv6.DA

            # Build a = pseudo header from the active segment in the IPv6.DA for use

          # during processing.

    S.03    Initialize a 24-byte local SRH in m= emory to 0’s for use below

    S.04    Set SRH.MaxHdrLen to 3

    S.05    Set SRH.RoutingType to 4=

    S.06    Set SRH.SegmentsLeft to 0

    S.07    Set SRH.SegmentList[0] to the value= of IPv6.DA

     

    S.08    Process the SRH as per section 4.1.= 1,

    S.09     noting such processing is lim= ited to the pseudo SRH

    S.10     since Argument is not 0.=

    S.11  }

     

    S.12  If (Upper-Layer header type is allowed by local= configuration) {

    S.13    Proceed to process the Upper-Layer = header

    S.14  } Else {

    S.15    Send an ICMP Parameter Problem to t= he Source Address

             with Code= 4 (SR Upper-layer Header Error)

             and Point= er set to the offset of the Upper-Layer header,

             interrupt= packet processing, and discard the packet.

    S.16  }

     

     

     

    4.2.1.  End with REPLACE-C-SID

     

    When processing an IPv6 packet that matches a FIB entry lo= cally

    instantiated as an End SID with the REPLACE-C-SID flavor, = the SRH

    processing described in Section 4.1 of [RFC8986] is replac= ed as

    follows.

     

    S.01 When an SRH is processed {

    S.02  If (IPv6.DA.Argument =3D=3D 0 and SRH.SegmentsL= eft =3D=3D 0) {

    S.03    Stop processing the SRH, and procee= d to process the next

            header in the p= acket, whose type is identified by

            the Next Header= field in the routing header.

    S.04  }

     

    S.05  If (IPv6.HopLimit <=3D 1) {

    S.06    Send an ICMP Time Exceeded message = to the Source Address

            with Code 0 (Ho= p limit exceeded in transit),

            interrupt packe= t processing, and discard the packet.

    S.07  }

     

    S.08  # Determine the maximum SRH Last Entry

    S.09  Set maxLE to ((SRH.HdrExtLen / 2) - 1)

     

    S.10  Initialize 128-bit buffer memory S to 0.

    S.11  Initialize local parameter Argument to the valu= e of IPv6.DA.Argument

    S.12  Initialize local parameter ActiveSegment to SRH= .SegmentList[SRH.SegmentsLeft]

     

    S.13  If (Argument =3D=3D 0) {

    S.14    If ((SRH.LastEntry > maxLE) or (= SRH.SegmentsLeft > SRH.LastEntry+1)) {

    S.15      Send an ICMP Parameter = Problem to the Source Address

              wit= h Code 0 (Erroneous header field encountered)

              and= Pointer set to the Segments Left field,

              int= errupt packet processing, and discard the packet.

    S.16    }

     

    S.17    Set S[0..B-1] to the value of IPv6.= DA[0..B-1] (i.e., the common locator block)

     

    S.18    Decrement SRH.SegmentsLeft by 1

     

    S.19    Set Argument to (128 / NF - 1)=

    S.20  }

    S.21  Else {

    S.22    If ((SRH.LastEntry > maxLE) or (= SRH.SegmentsLeft > SRH.LastEntry)) {

    S.23      Send an ICMP Parameter = Problem to the Source Address

              wit= h Code 0 (Erroneous header field encountered)

              and= Pointer set to the Segments Left field,

              int= errupt packet processing, and discard the packet.

    S.24    }

     

    S.25    Set S[0..B-1] to the value of IPv6.= DA[0..B-1] (i.e., the common locator block)

     

    S.26    Decrement Argument by 1<= /span>

    S.27  }

     

    S.28  Initialize local parameter BitLength to the val= ue of NF

    S.29  Initialize local parameter BitIndex to (Argumen= t * NF)

     

    S.30  Set S[B..B+BitLength-1] to the value of

           ActiveSegment[BitInde= x..(BitIndex+BitLength-1)]

    S.32  Set S[B+BitLength..B+BitLength+A-1] to the valu= e of Argument

     

    S.33  Set IPv6.DA to the value of S=

     

    S.34  Decrement IPv6.HopLimit by 1<= /p>

     

    S.35  Submit the packet to the egress IPv6 FIB lookup= for transmission

    S.36   to the new destination.=

    S.37 }

     

    4.2.1.1.  Upper layer header processing=

     

    The upper-layer header processing described in Section 4.1= .1 of [RFC8986] is unchanged and reproduced below.

     

    S.01  If (Upper-Layer header type is allowed by local= configuration) {

    S.02    Proceed to process the Upper-Layer = header

    S.03  } Else {

    S.04    Send an ICMP Parameter Problem to t= he Source Address

            with Code 4 (SR= Upper-layer Header Error)

            and Pointer set= to the offset of the Upper-Layer header,

            interrupt packe= t processing, and discard the packet.

    S.05  }

     

     

     

    --_000_BL0PR05MB53165EC96ADCD9349D339A6CAE809BL0PR05MB5316namp_-- From nobody Fri Oct 22 13:20:38 2021 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 93EE23A0E9E; Fri, 22 Oct 2021 13:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOXDxdhJM-p3; Fri, 22 Oct 2021 13:17:43 -0700 (PDT) Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A957D3A0A90; Fri, 22 Oct 2021 13:17:40 -0700 (PDT) Received: by mail-ot1-x331.google.com with SMTP id v2-20020a05683018c200b0054e3acddd91so3246441ote.8; Fri, 22 Oct 2021 13:17:40 -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=TNO6FxPXmMrJY+1kxEVv6PnjNr01p7OROQ03VcMevB0=; b=fHm7Sns4WK2nfr6DBgcN5K8vOFvSQfmixrB7ezKuu7Iim/H5gBxhEUDjLFJm3VJBBH uzkuKA87JHs2jk+Q8LWY5cDZBZnBk1yvt3sqF33GtrcAdBLV3DEoihdS+vtDd/Fb8uK5 5QAM/S9c8ET81qubPYH0TtNFYhSJLVjTYXuEBL+FE/sgFmcRo/PcEfLZpvfXbiBM6N7I tgAaj0kjblhSKzEilpHNR8bn4w/Wj+mj4tTssLfVS6GcsNk6L5/6IfQjJQZBI4HYCU7j TGmAmWLbtmSSIemGC7D8EOuEeSx7A1rBZS97pIXVbdTH3cvmwyc46YB7WBhjbl0pBugZ erMw== 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=TNO6FxPXmMrJY+1kxEVv6PnjNr01p7OROQ03VcMevB0=; b=ijZX+UU5b4xD5kCY5KpWNwDNN5seRXFsakaxc9J17EhidCgc3nHf9IkZS24EMyCv/B MGMrbw6vh/yaKhr2TXAtKTqfqWLoAAVqBhjSJY+IACl7ImSccN3+PUJaai3O78HMrYfe a9NFBvrX3dEnovPbgYXVQdkeIfhi0UTAVzS6/c+fexvOQJkOCnDk0gGKTYaUWJTtsDYS +aYhmM5/T0cisk0GC2QWu0DGPuyr/3TVOSljqRFz/xn4Y05NIdr+pg2QMEV1ptMT5PwF YkUNuipLeDWijr2p3Yxp2ZJkhrRTt3e6CAJWGDv7LAhTJQqKPQGofeeLHZVRC7bUbPt8 nIgQ== X-Gm-Message-State: AOAM533JXSAzyByzws/azC544Gd6gESqTot40AOKw6Bxp+JZQdm3j/O8 55lAeXoHgkf9ILU58dIiR/fxwPrulcCBuYbkfo62Qmzr X-Google-Smtp-Source: ABdhPJwKDVy0TSXql5DPgFlVZF7AdzNSWG+33AO/xZCVC4Xxo8ueKWwEqVM1jb2ofoMhPhh8X72A3Urzhqb+O/m8FAg= X-Received: by 2002:a05:6830:30ba:: with SMTP id g26mr1632640ots.32.1634933855455; Fri, 22 Oct 2021 13:17:35 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> In-Reply-To: From: Erik Kline Date: Fri, 22 Oct 2021 16:17:24 -0400 Message-ID: To: "Joel M. Halpern" Cc: "ipv6@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000af8e8b05cef6b3e2" Archived-At: Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 22 Oct 2021 20:18:06 -0000 --000000000000af8e8b05cef6b3e2 Content-Type: text/plain; charset="UTF-8" Joel, I'm afraid we failed to meet this deadline, my apologies. But we should have an answer for you in the first part of next week. Thank you (and everyone) for your continued patience, -Erik, Eric, Bob, and Ole On Thu, Oct 14, 2021 at 1:04 PM Erik Kline wrote: > Joel, > > Thank you for your email. The ADs and chairs have been discussing. > > One thing that would be very helpful to our discussions would be some > worked examples of the various C-SID behaviors, showing some SRv6 datagrams > and what happens to their contents as they move across some suitable > example SR domain. > > (It would also be helpful if they showed what happens to something like an > ICMPv6 Echo Request to a representative Destination Address in these cases > when, say, an SRH is not present, i.e. to see when typical unicast > semantics are preserved or when something more like anycast or multicast > behavior is to be expected.) > > Assuming some forthcoming helpful examples, we have a goal to get a more > complete answer back to you by the latter half of next week. > > Thanks, > -Erik > > On Tue, Oct 12, 2021 at 8:53 PM Joel M. Halpern > wrote: > >> The SPRING working group is in the midst of an adoption call on >> >> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ >> . >> >> The SPRING charter has text that is explicit that modifications to data >> planes and architectures standardized by other working groups may not be >> modified in SPRING unless the chairs and ADs responsible for that data >> plane and / or architecture agree. >> >> To complete the context, as my SPRING co-chairs are co-authors on the >> document in question, they have recused themselves from decisional >> activities regarding the document. Therefore, this message is coming >> just from my as the responsible SPRING co-chair managing this adoption >> call. >> >> As you have seen, multiple questions have been raised about the >> relationship of the document to the IPv6 defined data plane and >> architecture (particularly RFC 4291 and 8200). In particular the >> questions seem to revolve around what the document describes as the >> NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6 >> standards. (For those seeking more context without reading the full >> document, a paraphrase and simplification of the NEXT-C_SID flavor is >> provided as a postscript.) >> >> I raised the question of concurrence as required by the SPRING charter >> with the Internet ADs and SPRING chairs. They quite reasonably asked me >> to write a note to 6man explaining the concerns as clearly as a can, so >> that they can then determine how to proceed. >> >> The questions that prompted my inquiry are: >> >> 1) Does the placement of a list of sids in the IPv6 DA field change the >> IPv6 architectural description of that field. >> 2) Does the operation of shifting information around in the IPv6 >> destination address field represent a modification or extension of the >> IPv6 data plane. >> >> On a related note, the document in question also defines two other >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID >> flavor operation, so seems to be affected by the same question. >> >> From my own reading, it appears that the REPLACE-C-SID flavor does not >> raise issues requiring 6man leadership concurrence. >> >> Yours, >> Joel M. Halpern for the SPRING working group >> >> >> PS: >> Clearly, understanding the question requires some understanding of what >> the NEXT-C_SID flavor does. This explanation is a simplification for >> length and context. Really, the best place to understand it is the >> draft. However, to give you enough information to let you decide >> whether you care, I will try to provide a fair summary. My apologies in >> advance to the authors for necessary liberties for length. Also, >> discussion of the draft contents (as distinct from the interaction with >> the IPv6 data plane and architecture) belongs on the SPRING list, and >> should not clutter up 6man. >> >> SIDs are the identifiers used in segment routing. >> In SRv6, as document in the current RFCs, these are 128 bits. As >> defined in the relevant RFCs, SIDs which identify endpoints to which >> packets are directed are identified by endpoint SIDs. These can have >> behaviors (decapsulate and forward is one example). They can have >> flavors such as where the SRH is removed. >> >> The topic under discussion is means to compress these SIDs in the >> packets on the wire. The document under discussion provides three >> flavors of compression. >> >> The fundamental mechanism of the draft is to use a single SRH entry as a >> container for multiple SIDs. In the NEXT-C_SID mechanism, when it is >> first encountered the entire container is copied into the desination >> address of the IPv6 packet. The container has a common routing prefix >> used for all the NEXT-C-SID SIDs. It is followed by a sequence of >> compressed SIDs of a configured length. One could configure 16, 24, or >> 32 bits. Or whatever length. The routing advertisements are arranged >> so that the IPv6 packet is directed to the node represented by the first >> compressed SID on the basis of longest prefix match matching the >> combination of the common routing prefix and that compressed SID. >> >> When the packet arrives at that node, it looks up the configured >> portion, the compressed SID, and determines the behavior and flavor. In >> the case of the NEXT-C-SID flavor, the resulting operation is to shift >> the entire remaining contents of the IPv6 address (the bits past the >> first compressed sid) so as to over-write the first compressed SID. 0 >> bits are shifted into the low order positions. If the result is a >> non-zero new first compressed SID, then the packets is forwarded and the >> process repeats. When all that is left are 0s, if there is an SRH, it >> is consulted to find the next SRH entry, which is, per normal SRv6 >> processing, put into the IPv6 DA. >> Note that in the common case where the SIDS needed all fit in to a >> single container, the analysis also assumes the use of the reduced >> encapsulation options which omits the SRH that is not needed as it would >> have no entries. This the packet contains a normal IPv6 header, with a >> sequence of compressed SIDs (what one might or might not call a source >> route) in the IPv6 destination address field. >> >> PPS: If the authors of the NEXT-C-SID flavor feel I have mis-represented >> the work, please, send clarifications or corrections. Again, the best >> source of information is the draft itself. I was asked to provide extra >> context in this email. >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> > --000000000000af8e8b05cef6b3e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Joel,

    I'm afraid we failed to meet = this deadline, my apologies.=C2=A0 But we should have an answer for you in = the first=C2=A0part of next=C2=A0week.

    Thank you (= and everyone) for your continued patience,
    -Erik, Eric, Bob, and = Ole


    On Thu, Oct 14, 2021 at 1:04 PM Erik Kline <ek.ietf@gmail.com> wrote:
    =
    Joel,
    Thank you for your email.=C2=A0 The ADs and chairs have be= en discussing.

    One thing that would be very helpfu= l to our discussions would be some worked examples of the various C-SID beh= aviors, showing some SRv6 datagrams and what happens to their contents as t= hey move across some suitable example SR domain.

    (= It would also be helpful if they showed what happens to something like an I= CMPv6 Echo Request to a representative Destination Address in these cases w= hen, say, an SRH is not present, i.e. to see when typical unicast semantics= are preserved or when something more like anycast or multicast behavior is= to be expected.)

    Assuming some forthcoming helpfu= l examples, we have a goal to get a more complete answer back to you by the= latter half of next week.

    Thanks,
    -Erik=

    On Tue, Oct 12, 2021 at 8:53 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:<= br>
    The SPRING worki= ng group is in the midst of an adoption call on
    https://datatracker= .ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/.

    The SPRING charter has text that is explicit that modifications to data planes and architectures standardized by other working groups may not be modified in SPRING unless the chairs and ADs responsible for that data
    plane and / or architecture agree.

    To complete the context, as my SPRING co-chairs are co-authors on the
    document in question, they have recused themselves from decisional
    activities regarding the document.=C2=A0 Therefore, this message is coming =
    just from my as the responsible SPRING co-chair managing this adoption call= .

    As you have seen, multiple questions have been raised about the
    relationship of the document to the IPv6 defined data plane and
    architecture (particularly RFC 4291 and 8200). In particular the
    questions seem to revolve around what the document describes as the
    NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6
    standards.=C2=A0 (For those seeking more context without reading the full <= br> document, a paraphrase and simplification of the NEXT-C_SID flavor is
    provided as a postscript.)

    I raised the question of concurrence as required by the SPRING charter
    with the Internet ADs and SPRING chairs.=C2=A0 They quite reasonably asked = me
    to write a note to 6man explaining the concerns as clearly as a can, so that they can then determine how to proceed.

    The questions that prompted my inquiry are:

    1) Does the placement of a list of sids in the IPv6 DA field change the IPv6 architectural description of that field.
    2) Does the operation of shifting information around in the IPv6
    destination address field represent a modification or extension of the
    IPv6 data plane.

    On a related note, the document in question also defines two other
    flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.=C2=A0 The
    NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID
    flavor operation, so seems to be affected by the same question.

    =C2=A0From my own reading, it appears that the REPLACE-C-SID flavor does no= t
    raise issues requiring 6man leadership concurrence.

    Yours,
    Joel M. Halpern for the SPRING working group


    PS:
    Clearly, understanding the question requires some understanding of what the NEXT-C_SID flavor does.=C2=A0 =C2=A0This explanation is a simplificatio= n for
    length and context.=C2=A0 Really, the best place to understand it is the draft.=C2=A0 However, to give you enough information to let you decide
    whether you care, I will try to provide a fair summary.=C2=A0 My apologies = in
    advance to the authors for necessary liberties for length.=C2=A0 Also,
    discussion of the draft contents (as distinct from the interaction with the IPv6 data plane and architecture) belongs on the SPRING list, and
    should not clutter up 6man.

    SIDs are the identifiers used in segment routing.
    In SRv6, as document in the current RFCs, these are 128 bits.=C2=A0 =C2=A0A= s
    defined in the relevant RFCs, SIDs which identify endpoints to which
    packets are directed are identified by endpoint SIDs.=C2=A0 These can have =
    behaviors (decapsulate and forward is one example).=C2=A0 They can have flavors such as where the SRH is removed.

    The topic under discussion is means to compress these SIDs in the
    packets on the wire.=C2=A0 The document under discussion provides three flavors of compression.

    The fundamental mechanism of the draft is to use a single SRH entry as a container for multiple SIDs.=C2=A0 In the NEXT-C_SID mechanism, when it is =
    first encountered the entire container is copied into the desination
    address of the IPv6 packet.=C2=A0 The container has a common routing prefix=
    used for all the NEXT-C-SID SIDs.=C2=A0 It is followed by a sequence of compressed SIDs of a configured length.=C2=A0 One could configure 16, 24, o= r
    32 bits.=C2=A0 Or whatever length.=C2=A0 The routing advertisements are arr= anged
    so that the IPv6 packet is directed to the node represented by the first compressed SID on the basis of longest prefix match matching the
    combination of the common routing prefix and that compressed SID.

    When the packet arrives at that node, it looks up the configured
    portion, the compressed SID, and determines the behavior and flavor.=C2=A0 = In
    the case of the NEXT-C-SID flavor, the resulting operation is to shift
    the entire remaining contents of the IPv6 address (the bits past the
    first compressed sid) so as to over-write the first compressed SID.=C2=A0 0=
    bits are shifted into the low order positions.=C2=A0 If the result is a non-zero new first compressed SID, then the packets is forwarded and the process repeats.=C2=A0 When all that is left are 0s, if there is an SRH, it=
    is consulted to find the next SRH entry, which is, per normal SRv6
    processing, put into the IPv6 DA.
    Note that in the common case where the SIDS needed all fit in to a
    single container, the analysis also assumes the use of the reduced
    encapsulation options which omits the SRH that is not needed as it would have no entries.=C2=A0 This the packet contains a normal IPv6 header, with = a
    sequence of compressed SIDs (what one might or might not call a source
    route) in the IPv6 destination address field.

    PPS: If the authors of the NEXT-C-SID flavor feel I have mis-represented the work, please, send clarifications or corrections.=C2=A0 =C2=A0Again, th= e best
    source of information is the draft itself.=C2=A0 I was asked to provide ext= ra
    context in this email.

    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --000000000000af8e8b05cef6b3e2-- From nobody Fri Oct 22 17:30:10 2021 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 5FB623A0840; Fri, 22 Oct 2021 17:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=uniroma2.it header.b=uaBsfbT5; dkim=pass (2048-bit key) header.d=uniroma2.it header.b=faYYpsYg 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 5YvkzMs4ZD_8; Fri, 22 Oct 2021 17:30:03 -0700 (PDT) Received: from smtp.uniroma2.it (smtp.uniroma2.it [160.80.6.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 7CEBF3A083F; Fri, 22 Oct 2021 17:29:59 -0700 (PDT) Received: from smtpauth-2019-1.uniroma2.it (smtpauth.uniroma2.it [160.80.5.46]) by smtp-2015.uniroma2.it (8.14.4/8.14.4/Debian-8) with ESMTP id 19N0TdvS004825; Sat, 23 Oct 2021 02:29:44 +0200 Received: from [192.168.1.116] (93-41-113-141.ip81.fastwebnet.it [93.41.113.141]) by smtpauth-2019-1.uniroma2.it (Postfix) with ESMTPSA id 0B6971205C5; Sat, 23 Oct 2021 02:29:35 +0200 (CEST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=uniroma2.it; s=ed201904; t=1634948975; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bDWwmG9/XQrbh2Gj0f0IwWTt6oViJVCoW6CxHhiIynY=; b=uaBsfbT5EKOrJy7xzF6buxb6amT3ega+wgf5ONnvinwN9MXTZXfrBDzTO+eokyDqaKEwIr hqPc9kWQDv5mSrDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uniroma2.it; s=rsa201904; t=1634948975; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bDWwmG9/XQrbh2Gj0f0IwWTt6oViJVCoW6CxHhiIynY=; b=faYYpsYg2aB3R2d8kZb42jHIZwcxcP0HgVeE2aW1ClqS/1bn8FiPBAeShJao7uPGw5zCBG yYNuYGLpgb4u3o91yPRXJTXXf3/wcgyK02RcOeAmdEqT9w/f0yizZspuUq0hfrT5kKZxoD BJE92jFkCi7MdAiwEo0mP0sNHL4FjqXWd7uDeKZXPHZ69D3LSEq4RVZ/UbZRAPNROg1lTv hKRNN7Ota+vN6YrUw/qH4RVHZL2zIMR5C/P5oGT4dp/EQNfW6sr0pcN9UJnVne9PnohxON Xjotbt4xT2ivCqduXq3JYl3GflHMoNoFFGtCy2mx7MqO2xOF3hvGU0YdNCeMfA== To: Nick Hilliard Cc: ipv6@ietf.org, SPRING WG List References: <6865E218-00B1-41F0-9386-7B8F6DB1D776@steffann.nl> <3b9416b4-be73-c1a7-9235-7e832aee1657@foobar.org> <78937788-5873-b89a-83a0-b93cc51223e9@foobar.org> From: Stefano Salsano Message-ID: <0e2c4b8a-e3b3-83f3-bf7e-8142f3c78d31@uniroma2.it> Date: Sat, 23 Oct 2021 02:29:32 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <78937788-5873-b89a-83a0-b93cc51223e9@foobar.org> Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Language: it-IT Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.0 at smtp-2015 X-Virus-Status: Clean Archived-At: Subject: Re: [spring] Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 23 Oct 2021 00:30:09 -0000 Il 2021-10-21 12:02, Nick Hilliard ha scritto: > Hi Stefano, > > [spring@ re-added to cc:] > > Stefano Salsano wrote on 20/10/2021 22:36: >> I can anticipate that it is possible to use wireshark to dissect CSID >> packets, by providing very simple configuration information. > > This is exactly the problem though - operators will need to manually > instruct a dissector how to interpret the packet contents and that > defeats the purpose of a debugging tool because the tool is supposed to > be able to objectively tell you what's going on, without the operator > having to tell it what's going on. > > In particular, if you're attempt to debug a problem relating to C-SID > length, it would be completely useless. > > For example, how would you dissect the following sequence of compressed > SIDs of different lengths? > > 0x53b7e4f4d23b > > The short answer is you can't objectively, yet this could be a valid SID > argument. Hi Nick, the draft recommends to use a single CSID length (16 bits for NEXT, 32 bits for REPLACE), and if an operator also chooses a single block length it's very easy to provide the wireshark extensions to dissect all CSID containers in your domain if an operator wants to combine CSIDs of different length, building the debug tools becomes more complex, but this actually depends on the specific choices and configurations SRv6 is confined to an operator's domain, so an operator will have to debug SRv6 packets that have been created by nodes under the control of the operator and following the configuration choices of the operator Stefano > There's an opportunity at this point to ensure that whatever compressed > SID mechanism is implemented, that it's done in such a way if difference > lengths of compressed SIDs are allowed, that the SID length is included > in the encoding. > > If this isn't done, it will create a mess which operations and support > people will be stuck with for the lifetime of SRv6. Note that this > devalues SRv6 as an infrastructure component. > > Nick -- ******************************************************************* Stefano Salsano Professore Associato Dipartimento Ingegneria Elettronica Universita' di Roma Tor Vergata Viale Politecnico, 1 - 00133 Roma - ITALY http://netgroup.uniroma2.it/Stefano_Salsano/ E-mail : stefano.salsano@uniroma2.it Cell. : +39 320 4307310 Office : (Tel.) +39 06 72597770 (Fax.) +39 06 72597435 ******************************************************************* From nobody Sat Oct 23 02:53:36 2021 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 6807C3A0C38; Sat, 23 Oct 2021 02:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 dLJt_30FFAQA; Sat, 23 Oct 2021 02:51:04 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 953FA3A0C3A; Sat, 23 Oct 2021 02:51:02 -0700 (PDT) X-Envelope-To: ipv6@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 19N9ova7079499 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Oct 2021 10:50:58 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: Stefano Salsano Cc: ipv6@ietf.org, SPRING WG List From: Nick Hilliard Message-ID: <4b39ddbe-7b49-3dd9-5c93-8bd7c4190086@foobar.org> Date: Sat, 23 Oct 2021 10:50:56 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.49 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 23 Oct 2021 09:51:11 -0000 Hi Stefano, Stefano Salsano wrote on 23/10/2021 01:29: > if an operator wants to combine CSIDs of different length, building the > debug tools becomes more complex, but this actually depends on the > specific choices and configurations Exactly. For example, problems will occur when the operator changes SID length inside their domain, or attempts to interoperate with other SRH domains (either within the same or with different administrative domains), or merges with another network which uses with a different SID length. From the point of view of operations and management of production networks, if a protocol allows for a variable length parameter, but doesn't explicitly encode the length of the parameter, then this introduces protocol ambiguity. Protocol ambiguity is toxic on production networks because it causes breakage which is difficult to diagnose and may be impossible to fix. If the SRH compression draft proposed to encode the compressed SID length for each instance of a C-SID in the header, then this problem goes away. On this basis, I'm objecting to the adoption of draft-filsfilscheng-spring-srv6-srh-compression as a WG draft, and respectfully suggest that the spring wg does not adopt any draft in future which allows for different C-SID lengths but doesn't encode C-SIDs as {length,value} tuples. Nick From nobody Sat Oct 23 12:47:30 2021 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 6A1323A08EB for ; Sat, 23 Oct 2021 12:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=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 3SUwMH8gsrB8 for ; Sat, 23 Oct 2021 12:47:21 -0700 (PDT) Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) (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 3524D3A08AE for ; Sat, 23 Oct 2021 12:47:21 -0700 (PDT) Received: by mail-pl1-x62d.google.com with SMTP id w17so5107504plg.9 for ; Sat, 23 Oct 2021 12:47:21 -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=3A71NEWbrkHtqjmI+tCttXSl2bvuAgqaGIFwFS/KTSg=; b=gA9sG5G6U14VunYJAMMmlq6LmjAlHxo/9+1R9lQ8qSrBppMVO5kE4kueASbCm/mfyE 9BPA55NIKogj6VTfrH6hkS/ED+eiUGhf4yAXt1qxpJ+kvTfnkozdbgF02FOoOzWSRhor wnZedIL/hSGhdNO4GrB2GtHeZ3BEL+7fjQbkhGQ2YuYPizjXUOv4QlbxDMAxBEN1DYmw 8f0g4eAToaBc8OIpxwhNmgxgYY10Ntq0654blHTtbCuIBLyft7UWK928Fk88A29C9Dx9 wNROtO2zL7ohtG2OLgtbwFqvdRMqaA7L1ltn/VyIOlsajxNO2zF1Se9D+CeLyEk6jV/P CWaw== 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=3A71NEWbrkHtqjmI+tCttXSl2bvuAgqaGIFwFS/KTSg=; b=sqtB55356PWvHMQwbEhZwQ2ZNGm1ztkBQRzgmxUbyYoZQOE8/CFR24aZLnZoRZA+u+ MeHTc10Ukn5Thee12zvov6QrfA3GdS38Uwu8C/ynafMQJImVnav/AQ2c2Mj0WFvYzquP J0ncae3xkz47ORj3yYi+p+OY7dGC4rH9t3NKPIE33Xje918+Pf1sTDNS2s+LbXfxAN14 NZtb3/vH7nYKJxDjrOaJHdqMv1vHlL09K2QCY8TVFbO8jOwHuck1Gj9avOSm8F+/T62v PeK0ECZDA1LvjEmWmafwUZtml1Gqq9ppdeQwB33uyjDzdLFGbdTXUv4DqgumJT88WY9B g4IA== X-Gm-Message-State: AOAM532yGIFcMxRef54SJyql+Okro6Kqc9Mvk6UGzArlbY8yHRf65uBU 5BmZ9+5grpM5duL5SzgbVXreDpG3UqqPw8gl3eAd6dDY X-Google-Smtp-Source: ABdhPJzeIhDffn+iqWAWABuDiThUEMTZoc328T3169xTzjilFBkW0smfPG8fYlASEUD3YB8wG5rKZi081TIoQm1QCuQ= X-Received: by 2002:a17:90b:1649:: with SMTP id il9mr9031388pjb.167.1635018437111; Sat, 23 Oct 2021 12:47:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gyan Mishra Date: Sat, 23 Oct 2021 15:47:05 -0400 Message-ID: To: "Darren Dukes (ddukes)" Cc: SPRING WG Content-Type: multipart/alternative; boundary="00000000000025363005cf0a6527" Archived-At: Subject: Re: [spring] CSID proposed clarifications 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, 23 Oct 2021 19:47:28 -0000 --00000000000025363005cf0a6527 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Darren & Authors The CSID proposed clarifications looks excellent. In the current draft revision it was clear that both Next and Replace use the IPv6 IID portion of the address as the container to index the C-SID using Argument portion SRv6 SID, Next having 16 bit NF and 64 bit argument, and Replace having 32 bit NF and 16 bit Argument. For Replace the Argument is 16 bit followed by 0s section 4.2, is that correct? So is the field actually 64 bit that the CSID entires reside? I agree End.x adj-sid strict path has no change to the SRv6 processing as the SID in SRH gets copied directly to DA, so no complex indexing of the SID from Argument portion of SRv6 SID in the SRH. The difference between End.x and End is End Prefix sid is global in IGP where End.x is local not in IGP. Note that the very long strict paths is what requires compression End.x versus End endpoint behaviors, although both endpoints for overall compression solution is required. I believe a lot of the contention is with End and not End.x as far as violation of IPv6 specification, indexing of the CSID within the SRH SID, argument portion of the address. The End, prefix sid SRv6 processing is more complicated as the indexed SID is copied from the SRH Argument portion of the SRv6 address to DA. Excerpt below from your pseudocode below really helps clarify the exact differences of the bits within the C-SID container that gets copied to DA for End endpoint for both Next and Replace flavors. Comparing the Next and Replace pseudocode below side by side for the critical copy function of what bits get copied from SRH Argument to DA. Replace has 1 extra step s32 which helps clearly spell out the difference between the two flavors difference in replace copying from bottom of container to top. I was referencing uSID for Next and G-SID for Replace but there are some slight differences so this updated pseudocode really helps. NEXT-C-SID S.31 Initialize local parameter BitLength to (CountTrailingZeros(ActiveSegment) + AL - CountTrailingZeros(Argument)) S.32 Initialize local parameter BitIndex to (128 =E2=80=93 BitLength) S.33 Set S[B..B+BitLength-1] to the value of ActiveSegment[BitIndex..(BitIndex+BitLength-1)] S.34 } S.35 Set IPv6.DA to the value of S REPLACE-C-SID S.29 Initialize local parameter BitIndex to (Argument * NF) S.30 Set S[B..B+BitLength-1] to the value of ActiveSegment[BitIndex..(BitIndex+BitLength-1)] S.32 Set S[B+BitLength..B+BitLength+A-1] to the value of Argument S.33 Set IPv6.DA to the value of S Kind Regards Gyan On Thu, Oct 14, 2021 at 8:54 AM Darren Dukes (ddukes) wrote: > The NEXT-C-SID and REPLACE-C-SID flavors are functionally very similar. > > In both cases the SID in the IPv6 Destination Address (DA) contains an > argument, > > that argument is used to construct the next SID from the active segment i= n > > the SRH Segment List. > > > > I believe the following pseudocode is a much better description of their > > segment endpoint processing. You=E2=80=99ll notice there is no manipulati= on of > > the bits in the IPv6 DA. > > > > I propose we replace the pseudocode in the draft with the following, > > stand-alone pseudocode, for the NEXT-C-SID and REPLACE-C-SID flavors > > of the END behavior (sections 4.1.1 and 4.2.1 respectively). > > > > Equivalent changes can be completed for the NEXT-C-SID and REPLACE-C-SID > > flavors of the END.X behavior (sections 4.1.2 and 4.2.2 respectively) and > > NEXT-AND-REPLACE-C-SID flavor. > > > > Comments are appreciated. > > > > Thanks > > Darren > > > > *4.1.1. End with NEXT-C-SID* > > > > When processing an IPv6 packet that matches a FIB entry locally > > instantiated as an End SID with the NEXT-C-SID flavor, the SRH > > processing described in Section 4.1 of [RFC8986] is replaced as > > follows. > > > > > > S.01 When an SRH is processed { > > S.02 If (IPv6.DA.Argument =3D=3D 0 and SRH.SegmentsLeft =3D=3D 0) { > > S.03 Stop processing the SRH, and proceed to process the next > > header in the packet, whose type is identified by > > the Next Header field in the routing header. > > S.04 } > > > > S.05 If (IPv6.HopLimit <=3D 1) { > > S.06 Send an ICMP Time Exceeded message to the Source Address > > with Code 0 (Hop limit exceeded in transit), > > interrupt packet processing, and discard the packet. > > S.07 } > > > > S.08 # Determine the maximum SRH Last Entry > > S.09 Set maxLE to ((SRH.HdrExtLen / 2) - 1) > > > > S.10 Initialize 128-bit buffer memory S to 0. > > S.11 Initialize local parameter Argument to the value of IPv6.DA.Argumen= t > > > > S.12 If (Argument =3D=3D 0) { > > S.13 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > > SRH.LastEntry+1)) { > > S.14 Send an ICMP Parameter Problem to the Source Address > > with Code 0 (Erroneous header field encountered) > > and Pointer set to the Segments Left field, > > interrupt packet processing, and discard the packet. > > S.15 } > > > > S.16 Decrement SRH.SegmentsLeft by 1 > > > > S.17 Set S to the value of SRH.SegmentList[SRH.SegmentsLeft] > > S.18 } > > S.19 Else { > > S.20 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > > SRH.LastEntry+1)) { > > S.21 Send an ICMP Parameter Problem to the Source Address > > with Code 0 (Erroneous header field encountered) > > and Pointer set to the Segments Left field, > > interrupt packet processing, and discard the packet. > > S.22 } > > > > S.23 Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common > locator block) > > > > S.24 If (SRH.SegmentsLeft > SRH.LastEntry) { > > S.25 Initialize local parameter ActiveSegment to the value of DA > > S.26 } > > S.27 Else { > > S.28 Initialize local parameter ActiveSegment to the value > > S.29 of SRH.SegmentList[SRH.SegmentsLeft] > > S.30 } > > > > S.31 Initialize local parameter BitLength to > (CountTrailingZeros(ActiveSegment) + > > AL - > CountTrailingZeros(Argument)) > > S.32 Initialize local parameter BitIndex to (128 =E2=80=93 BitLength) > > > > S.33 Set S[B..B+BitLength-1] to the value of > > ActiveSegment[BitIndex..(BitIndex+BitLength-1)] > > S.34 } > > > > S.35 Set IPv6.DA to the value of S > > > > S.36 Decrement IPv6.HopLimit by 1 > > > > S.37 Submit the packet to the egress IPv6 FIB lookup for transmission > > to the new destination. > > S.38 } > > > > *4.1.1.1 Upper layer header processing* > > > > The upper-layer header processing described in Section 4.1.1 of > > [RFC8986] is replaced as follows. > > > > S.01 Initialize local parameter Argument to the value of IPv6.DA.Argumen= t > > S.02 If (Argument !=3D 0) { > > # In this case, the SRH was not added by source > > # The source compressed it into the active segment in IPv6.DA > > # Build a pseudo header from the active segment in the IPv6.DA fo= r > use > > # during processing. > > S.03 Initialize a 24-byte local SRH in memory to 0=E2=80=99s for use b= elow > > S.04 Set SRH.MaxHdrLen to 3 > > S.05 Set SRH.RoutingType to 4 > > S.06 Set SRH.SegmentsLeft to 0 > > S.07 Set SRH.SegmentList[0] to the value of IPv6.DA > > > > S.08 Process the SRH as per section 4.1.1, > > S.09 noting such processing is limited to the pseudo SRH > > S.10 since Argument is not 0. > > S.11 } > > > > S.12 If (Upper-Layer header type is allowed by local configuration) { > > S.13 Proceed to process the Upper-Layer header > > S.14 } Else { > > S.15 Send an ICMP Parameter Problem to the Source Address > > with Code 4 (SR Upper-layer Header Error) > > and Pointer set to the offset of the Upper-Layer header, > > interrupt packet processing, and discard the packet. > > S.16 } > > > > > > > > *4.2.1. End with REPLACE-C-SID* > > > > When processing an IPv6 packet that matches a FIB entry locally > > instantiated as an End SID with the REPLACE-C-SID flavor, the SRH > > processing described in Section 4.1 of [RFC8986] is replaced as > > follows. > > > > S.01 When an SRH is processed { > > S.02 If (IPv6.DA.Argument =3D=3D 0 and SRH.SegmentsLeft =3D=3D 0) { > > S.03 Stop processing the SRH, and proceed to process the next > > header in the packet, whose type is identified by > > the Next Header field in the routing header. > > S.04 } > > > > S.05 If (IPv6.HopLimit <=3D 1) { > > S.06 Send an ICMP Time Exceeded message to the Source Address > > with Code 0 (Hop limit exceeded in transit), > > interrupt packet processing, and discard the packet. > > S.07 } > > > > S.08 # Determine the maximum SRH Last Entry > > S.09 Set maxLE to ((SRH.HdrExtLen / 2) - 1) > > > > S.10 Initialize 128-bit buffer memory S to 0. > > S.11 Initialize local parameter Argument to the value of IPv6.DA.Argumen= t > > S.12 Initialize local parameter ActiveSegment to > SRH.SegmentList[SRH.SegmentsLeft] > > > > S.13 If (Argument =3D=3D 0) { > > S.14 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > > SRH.LastEntry+1)) { > > S.15 Send an ICMP Parameter Problem to the Source Address > > with Code 0 (Erroneous header field encountered) > > and Pointer set to the Segments Left field, > > interrupt packet processing, and discard the packet. > > S.16 } > > > > S.17 Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common > locator block) > > > > S.18 Decrement SRH.SegmentsLeft by 1 > > > > S.19 Set Argument to (128 / NF - 1) > > S.20 } > > S.21 Else { > > S.22 If ((SRH.LastEntry > maxLE) or (SRH.SegmentsLeft > SRH.LastEntry)= ) > { > > S.23 Send an ICMP Parameter Problem to the Source Address > > with Code 0 (Erroneous header field encountered) > > and Pointer set to the Segments Left field, > > interrupt packet processing, and discard the packet. > > S.24 } > > > > S.25 Set S[0..B-1] to the value of IPv6.DA[0..B-1] (i.e., the common > locator block) > > > > S.26 Decrement Argument by 1 > > S.27 } > > > > S.28 Initialize local parameter BitLength to the value of NF > > > S.29 Initialize local parameter BitIndex to (Argument * NF) > > > > S.30 Set S[B..B+BitLength-1] to the value of > > ActiveSegment[BitIndex..(BitIndex+BitLength-1)] > > S.32 Set S[B+BitLength..B+BitLength+A-1] to the value of Argument > > > > S.33 Set IPv6.DA to the value of S > > S.34 Decrement IPv6.HopLimit by 1 > > > > S.35 Submit the packet to the egress IPv6 FIB lookup for transmission > > S.36 to the new destination. > > S.37 } > > > > *4.2.1.1. Upper layer header processing* > > > > The upper-layer header processing described in Section 4.1.1 of [RFC8986] > is unchanged and reproduced below. > > > > S.01 If (Upper-Layer header type is allowed by local configuration) { > > S.02 Proceed to process the Upper-Layer header > > S.03 } Else { > > S.04 Send an ICMP Parameter Problem to the Source Address > > with Code 4 (SR Upper-layer Header Error) > > and Pointer set to the offset of the Upper-Layer header, > > interrupt packet processing, and discard the packet. > > S.05 } > > > > > > > _______________________________________________ > 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* --00000000000025363005cf0a6527 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Darren & Authors=C2=A0

    The CSID proposed clarifications look= s excellent.

    In the curr= ent draft revision it was clear that both Next and Replace use the IPv6 IID= portion of the address as the container to index the C-SID using =C2=A0Arg= ument portion SRv6 SID, =C2=A0Next having 16 bit NF and 64 bit argument, an= d =C2=A0Replace having 32 bit NF and 16 bit Argument.

    For Replace the Argument is 16 bit followed b= y 0s section 4.2, is that correct? =C2=A0 =C2=A0So is the field actually 64= bit that the CSID entires reside?

    I agree End.x adj-sid strict path has no change to the SRv6 proc= essing as the SID in SRH gets copied directly to DA, so no complex indexing= of the SID from Argument portion of SRv6 SID in the SRH.=C2=A0

    The difference between End.x and En= d is End Prefix sid is global in IGP where End.x is local not in IGP. =C2= =A0

    Note that the very l= ong strict paths is what requires compression End.x versus End endpoint beh= aviors, although both endpoints for overall compression solution =C2=A0is = =C2=A0required.

    I believ= e a lot of the contention is with End and not End.x as far as violation of = IPv6 specification, indexing of the CSID within the SRH SID, argument porti= on of the address.

    The E= nd, prefix sid SRv6 processing is more complicated as the indexed SID is co= pied from the SRH Argument portion of the SRv6 address to DA.

    Excerpt below from your pseudocode be= low really helps clarify the exact differences of the bits within the C-SID= container that gets copied =C2=A0to DA for End endpoint for both Next and = Replace flavors.

    Compari= ng the Next and Replace pseudocode below side by side for the critical copy= function of what bits get copied from SRH Argument to DA. =C2=A0

    Replace has 1 extra step s32 whic= h helps clearly spell out the difference between the two flavors difference= in replace copying from bottom of container to top.=C2=A0

    I was referencing uSID for Next and G-SI= D for Replace but there are some slight differences so this updated pseudoc= ode really helps.

    NEXT-C= -SID

    S.31= =C2=A0=C2=A0=C2=A0 Initialize local parameter BitLength to (CountTrailingZe= ros(ActiveSegment) +

    =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0AL - CountTrailingZeros(Arg= ument))

    S.32=C2=A0=C2=A0=C2=A0 Initialize local = parameter BitIndex to (128 =E2=80=93 BitLength)


    S.33=C2=A0=C2=A0=C2=A0 Set S[B..B+BitLength-1] to the value = of= <= span lang=3D"EN-US" style=3D"font-size:10pt;font-family:"Courier New&q= uot;;border-color:rgb(0,0,0)">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0ActiveSegment[BitIndex..(BitIndex+BitLength-1)]

    S.34=C2=A0 }

    =C2=A0

    S.35=C2=A0 Set IPv6.DA to the value of S


    REPLACE-C-SID
    =

    S.29=C2=A0 Initialize local parame= ter BitIndex to (Argument * NF)

    =C2=A0

    S.30=C2=A0 Set S[B..B+BitLength-1] to the value of=

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ActiveSegment[= BitIndex..(BitIndex+BitLength-1)]

    S.32=C2=A0 Set= S[B+BitLength..B+BitLength+A-1] to the value of Argument

    =C2=A0

    S.33=C2=A0 Set IPv6.DA to the v= alue of S

    Kind Regards=C2=A0

    Gyan

    On Thu, Oct 14, 2021 at 8:54 AM Darren Dukes (ddukes) <= ;ddukes=3D40cisco.com@dmarc.i= etf.org> wrote:

    The NEXT-C-SID and REPLACE-C-SID flavors are = functionally very similar.

    In both cases the SID in the IPv6 Destination= Address (DA) contains an argument,

    that argument is used to construct the next S= ID from the active segment in

    the SRH Segment List.

    =C2=A0<= /p>

    I believe the following pseudocode is a much = better description of their

    segment endpoint processing. You=E2=80=99ll n= otice there is no manipulation of

    the bits in the IPv6 DA.

    =C2=A0<= /p>

    I propose we replace the pseudocode in the dr= aft with the following,

    stand-alone pseudocode, for the NEXT-C-SID an= d REPLACE-C-SID flavors

    of the END behavior (sections 4.1.1 and 4.2.1= respectively).

    =C2=A0<= /p>

    Equivalent changes can be completed for the N= EXT-C-SID and REPLACE-C-SID

    flavors of the END.X behavior (sections 4.1.2= and 4.2.2 respectively) and

    NEXT-AND-REPLACE-C-SID flavor.

    =C2=A0<= /p>

    Comments are appreciated.

    =C2=A0<= /p>

    Thanks<= /p>

    =C2=A0 Darren<= /span>

    =C2=A0<= /p>

    4.1.1.=C2=A0 End with NEXT-C-SID

    =C2=A0<= /p>

    When processing an IPv6 packet that matches a= FIB entry locally

    instantiated as an End SID with the NEXT-C-SI= D flavor, the SRH

    processing described in Section 4.1 of [RFC89= 86] is replaced as

    follows.

    =C2=A0<= /p>

    =C2=A0<= /p>

    S.01 When an SRH is processed {

    S.02=C2=A0 If (IPv6.DA.Argument =3D=3D 0 and = SRH.SegmentsLeft =3D=3D 0) {

    S.03=C2=A0=C2=A0=C2=A0=C2=A0 Stop processing = the SRH, and proceed to process the next

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 header in the packet, whose type is identified by

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 the Next Header field in the routing header.=

    S.04=C2=A0 }

    =C2=A0<= /p>

    S.05=C2=A0 If (IPv6.HopLimit <=3D 1) {

    S.06=C2=A0=C2=A0=C2=A0=C2=A0 Send an ICMP Tim= e Exceeded message to the Source Address

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 with Code 0 (Hop limit exceeded in transit),=

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 interrupt packet processing, and discard the packet.

    S.07=C2=A0 }

    =C2=A0<= /p>

    S.08=C2=A0 # Determine the maximum SRH Last E= ntry

    S.09=C2=A0 Set maxLE to ((SRH.HdrExtLen / 2) = - 1)

    =C2=A0<= /p>

    S.10=C2=A0 Initialize 128-bit buffer memory S= to 0.

    S.11=C2=A0 Initialize local parameter Argumen= t to the value of IPv6.DA.Argument

    =C2=A0<= /p>

    S.12=C2=A0 If (Argument =3D=3D 0) {

    S.13=C2=A0=C2=A0=C2=A0 If ((SRH.LastEntry >= ; maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)) {

    S.14=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Send an IC= MP Parameter Problem to the Source Address

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 with Code 0 (Erroneous header field encountered)

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 and Pointer set to the Segments Left field,

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 interrupt packet processing, and discard the packet.

    S.15=C2=A0=C2=A0=C2=A0 }

    =C2=A0<= /p>

    S.16=C2=A0=C2=A0=C2=A0 Decrement SRH.Segments= Left by 1

    =C2=A0<= /p>

    S.17=C2=A0=C2=A0=C2=A0 Set S to the value of = SRH.SegmentList[SRH.SegmentsLeft]

    S.18=C2=A0 }

    S.19=C2=A0 Else {<= /u>

    S.20=C2=A0=C2=A0=C2=A0 If ((SRH.LastEntry >= ; maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)) {

    S.21=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Send an IC= MP Parameter Problem to the Source Address

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0with Code 0 (Erroneous header field encountered)

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 and Pointer set to the Segments Left field,

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 interrupt packet processing, and discard the packet.

    S.22=C2=A0=C2=A0=C2=A0 }

    =C2=A0<= /p>

    S.23=C2=A0=C2=A0=C2=A0 Set S[0..B-1] to the v= alue of IPv6.DA[0..B-1] (i.e., the common locator block)

    =C2=A0<= /p>

    S.24=C2=A0=C2=A0=C2=A0 If (SRH.SegmentsLeft &= gt; SRH.LastEntry) {

    S.25=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Initialize= local parameter ActiveSegment to the value of DA

    S.26=C2=A0=C2=A0=C2=A0 }

    S.27=C2=A0=C2=A0=C2=A0 Else {

    S.28=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Initialize= local parameter ActiveSegment to the value<= /span>

    S.29=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 of S= RH.SegmentList[SRH.SegmentsLeft]

    S.30=C2=A0=C2=A0=C2=A0 }

    =C2=A0<= /p>

    S.31=C2=A0=C2=A0=C2=A0 Initialize local param= eter BitLength to (CountTrailingZeros(ActiveSegment) +

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0AL - CountTrailingZeros(Argument))

    S.32=C2=A0=C2=A0=C2=A0 Initialize local param= eter BitIndex to (128 =E2=80=93 BitLength)

    =C2=A0<= /p>

    S.33=C2=A0=C2=A0=C2=A0 Set S[B..B+BitLength-1= ] to the value of

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0ActiveSegment[BitIndex..(BitIndex+BitLength-1)]

    S.34=C2=A0 }

    =C2=A0<= /p>

    S.35=C2=A0 Set IPv6.DA to the value of S

    =C2=A0<= /p>

    S.36=C2=A0 Decrement IPv6.HopLimit by 1

    =C2=A0<= /p>

    S.37=C2=A0 Submit the packet to the egress IP= v6 FIB lookup for transmission

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to the n= ew destination.

    S.38 }<= /p>

    =C2=A0<= /p>

    4.1.1.1 Upper layer header processing

    =C2=A0<= /p>

    The upper-layer header processing described i= n Section 4.1.1 of

    [RFC8986] is replaced as follows.

    =C2=A0<= /p>

    S.01=C2=A0 Initialize local parameter Argumen= t to the value of IPv6.DA.Argument

    S.02=C2=A0 If (Argument !=3D 0) {

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 # = In this case, the SRH was not added by source

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0# The source compressed it into the active segment in IPv6.DA

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0# Build a pseudo header from the active segment in the IPv6.DA for use

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0# during = processing.

    S.03=C2=A0=C2=A0=C2=A0 Initialize a 24-byte l= ocal SRH in memory to 0=E2=80=99s for use below

    S.04=C2=A0=C2=A0=C2=A0 Set SRH.MaxHdrLen to 3=

    S.05=C2=A0=C2=A0=C2=A0 Set SRH.RoutingType to= 4

    S.06=C2=A0=C2=A0=C2=A0 Set SRH.SegmentsLeft t= o 0

    S.07=C2=A0=C2=A0=C2=A0 Set SRH.SegmentList[0]= to the value of IPv6.DA

    =C2=A0<= /p>

    S.08=C2=A0=C2=A0=C2=A0 Process the SRH as per= section 4.1.1,

    S.09=C2=A0=C2=A0=C2=A0=C2=A0 noting such proc= essing is limited to the pseudo SRH

    S.10=C2=A0=C2=A0=C2=A0=C2=A0 since Argument i= s not 0.

    S.11=C2=A0 }

    =C2=A0<= /p>

    S.12=C2=A0 If (Upper-Layer header type is all= owed by local configuration) {

    S.13=C2=A0=C2=A0=C2=A0 Proceed to process the= Upper-Layer header

    S.14=C2=A0 } Else {

    S.15=C2=A0=C2=A0=C2=A0 Send an ICMP Parameter= Problem to the Source Address

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 with Code 4 (SR Upper-layer Header Error)

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 and Pointer set to the offset of the Upper-Layer header,

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 interrupt packet processing, and discard the packet.

    S.16=C2=A0 }

    =C2=A0<= /p>

    =C2=A0<= /p>

    =C2=A0<= /p>

    4.2.1.=C2=A0 End with REPLACE-C-SID

    =C2=A0<= /p>

    When processing an IPv6 packet that matches a= FIB entry locally

    instantiated as an End SID with the REPLACE-C= -SID flavor, the SRH

    processing described in Section 4.1 of [RFC89= 86] is replaced as

    follows.

    =C2=A0<= /p>

    S.01 When an SRH is processed {

    S.02=C2=A0 If (IPv6.DA.Argument =3D=3D 0 and = SRH.SegmentsLeft =3D=3D 0) {

    S.03=C2=A0=C2=A0=C2=A0 Stop processing the SR= H, and proceed to process the next

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 he= ader in the packet, whose type is identified by<= /u>

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 th= e Next Header field in the routing header.

    S.04=C2=A0 }

    =C2=A0<= /p>

    S.05=C2=A0 If (IPv6.HopLimit <=3D 1) {

    S.06=C2=A0=C2=A0=C2=A0 Send an ICMP Time Exce= eded message to the Source Address

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 wi= th Code 0 (Hop limit exceeded in transit),

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in= terrupt packet processing, and discard the packet.S.07=C2=A0 }

    =C2=A0<= /p>

    S.08=C2=A0 # Determine the maximum SRH Last E= ntry

    S.09=C2=A0 Set maxLE to ((SRH.HdrExtLen / 2) = - 1)

    =C2=A0<= /p>

    S.10=C2=A0 Initialize 128-bit buffer memory S= to 0.

    S.11=C2=A0 Initialize local parameter Argumen= t to the value of IPv6.DA.Argument

    S.12=C2=A0 Initialize local parameter ActiveS= egment to SRH.SegmentList[SRH.SegmentsLeft]<= /span>

    =C2=A0<= /p>

    S.13=C2=A0 If (Argument =3D=3D 0) {

    S.14=C2=A0=C2=A0=C2=A0 If ((SRH.LastEntry >= ; maxLE) or (SRH.SegmentsLeft > SRH.LastEntry+1)) {

    S.15=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Send an IC= MP Parameter Problem to the Source Address

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 with Code 0 (Erroneous header field encountered)

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 and Pointer set to the Segments Left field,

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 interrupt packet processing, and discard the packet.

    S.16=C2=A0=C2=A0=C2=A0 }

    =C2=A0<= /p>

    S.17=C2=A0=C2=A0=C2=A0 Set S[0..B-1] to the v= alue of IPv6.DA[0..B-1] (i.e., the common locator block)

    =C2=A0<= /p>

    S.18=C2=A0=C2=A0=C2=A0 Decrement SRH.Segments= Left by 1

    =C2=A0<= /p>

    S.19=C2=A0=C2=A0=C2=A0 Set Argument to (128 /= NF - 1)

    S.20=C2=A0 }

    S.21=C2=A0 Else {<= /u>

    S.22=C2=A0=C2=A0=C2=A0 If ((SRH.LastEntry >= ; maxLE) or (SRH.SegmentsLeft > SRH.LastEntry)) {

    S.23=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Send an IC= MP Parameter Problem to the Source Address

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 with Code 0 (Erroneous header field encountered)

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 and Pointer set to the Segments Left field,

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 interrupt packet processing, and discard the packet.

    S.24=C2=A0=C2=A0=C2=A0 }

    =C2=A0<= /p>

    S.25=C2=A0=C2=A0=C2=A0 Set S[0..B-1] to the v= alue of IPv6.DA[0..B-1] (i.e., the common locator block)

    =C2=A0<= /p>

    S.26=C2=A0=C2=A0=C2=A0 Decrement Argument by = 1

    S.27=C2=A0 }

    =C2=A0<= /p>

    S.28=C2=A0 Initialize local parameter BitLeng= th to the value of NF<= u style=3D"font-family:"Courier New"">


    S.29=C2= =A0 Initialize local parameter BitIndex to (Argument * NF)

    =C2=A0

    S.30=C2=A0 Set S[B..B+BitLengt= h-1] to the value of

    =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 ActiveSegment[BitIndex..(BitIndex+BitLength-1)]

    S.32=C2=A0 Set S[B+BitLength..B+BitLength+A-1] to the value of Ar= gument

    =C2=A0

    S.33=C2= =A0 Set IPv6.DA to the value of S


    S.34=C2=A0 Decrement IPv6.HopLimit by 1

    =C2=A0<= /p>

    S.35=C2=A0 Submit the packet to the egress IP= v6 FIB lookup for transmission

    S.36=C2=A0=C2=A0 to the new destination.

    S.37 }<= /p>

    =C2=A0<= /p>

    4.2.1.1.=C2=A0 Upper layer header processi= ng

    =C2=A0<= /p>

    The upper-layer header processing described i= n Section 4.1.1 of [RFC8986] is unchanged and reproduced below.

    =C2=A0<= /p>

    S.01=C2=A0 If (Upper-Layer header type is all= owed by local configuration) {

    S.02=C2=A0=C2=A0=C2=A0 Proceed to process the= Upper-Layer header

    S.03=C2=A0 } Else {

    S.04=C2=A0=C2=A0=C2=A0 Send an ICMP Parameter= Problem to the Source Address

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 wi= th Code 4 (SR Upper-layer Header Error)

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 an= d Pointer set to the offset of the Upper-Layer header,

    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 in= terrupt packet processing, and discard the packet.S.05=C2=A0 }

    =C2=A0<= /p>

    =C2=A0<= /p>

    =C2=A0

    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --
    --00000000000025363005cf0a6527-- From nobody Sat Oct 23 13:24:44 2021 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 AA1FE3A0A5E; Sat, 23 Oct 2021 13:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 QNsOk6UttRNc; Sat, 23 Oct 2021 13:24:36 -0700 (PDT) Received: from mail-pj1-x102d.google.com (mail-pj1-x102d.google.com [IPv6:2607:f8b0:4864:20::102d]) (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 2734A3A0A66; Sat, 23 Oct 2021 13:24:36 -0700 (PDT) Received: by mail-pj1-x102d.google.com with SMTP id n11-20020a17090a2bcb00b001a1e7a0a6a6so4579316pje.0; Sat, 23 Oct 2021 13:24:36 -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=V8q4fZR38SQS+Nt8Ujfe7xT2BNPEB9zku/jcNXmBxWY=; b=RpTipPLg4tKUQBiwEla8rU6blma9yfK8G+qMCQR+9mU0kheY2+0LELSzVvDyN/l90h B4pm0DTNIZ5tbfLwApR6FTxg1mosrX+D5ccPn07JlN0mUFnE935nVoXmDV9TvUwTHl3j B8vgJeT7uKibetRnkdQd0uu3VIX7/fBisX4Ksxc5W4ejeufTdq10gKfNoIIABoN9wPaB STQPZ+W7cJJqVh9MMjpW/NDf1AwG4Gsq+I67BdBgKDKfGB4su2UA2Qna3Jxqm3z/vTYS UjY12NetIH70JMQVEYqy9slmDQaVAkHVpVzMgJoQudR8udEPB+8/us1l1BHbM4nPXwLF f12g== 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=V8q4fZR38SQS+Nt8Ujfe7xT2BNPEB9zku/jcNXmBxWY=; b=UGdrUW9rKt8ElYrqvDl0bi1ua6F4Ujl+g380p0jYPGoA4rzcUmLD0AG884TZm5qK/G amzSU9hFoK2X85vJwEcpin/dkOHhV8R8DDTuv2ER+DnUqhQjZiv4MN9MHR5qfPWQUynr Mi+wYvT01zLkkYOP4DHEgGzbD5eB75nepXF9sz3njfEkypJ+UpYtfoHV7hh9+qHy2xdM iEMiZwSn5bAgFwLUMj+ANpJaOdWSKnA/NGs3CRnJ7KOuARioMqniFV7SJ+h6Xnesjtgn /CR1CH7vVwnWBVso+AXjSobLketAbCQIo3zXU2e1dfw8O59sc3p/gL/a00W0N/Yt1YKO Y8jg== X-Gm-Message-State: AOAM530CTc8V6emCF8mw7W8JWfD+wV+rSBGPEz9DgxFcK0bkPLrJ6Bq+ wY1HDBXSzO9suh4Tu+3F9hb9kvAWX+wUzYXoq285rlZF X-Google-Smtp-Source: ABdhPJwsJm/S+f55eKjYtSqbN4+4mzVlzbvl+QxKwIjrXPWKu8NqA3nyy3w21IWZqlydUgHpFNu9go2eJe/6h5X3q4o= X-Received: by 2002:a17:90a:c85:: with SMTP id v5mr14000248pja.47.1635020672786; Sat, 23 Oct 2021 13:24:32 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <26d9fc32-4884-602c-975a-79fc64551727@gmail.com> <838f3074802b4b67b33b7153d2f7089e@huawei.com> In-Reply-To: <838f3074802b4b67b33b7153d2f7089e@huawei.com> From: Gyan Mishra Date: Sat, 23 Oct 2021 16:22:49 -0400 Message-ID: To: "Chengli (Cheng Li)" Cc: "Darren Dukes (ddukes)" , "ipv6@ietf.org" , "spring@ietf.org" Content-Type: multipart/related; boundary="00000000000066fe0f05cf0aeaaf" Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 23 Oct 2021 20:24:41 -0000 --00000000000066fe0f05cf0aeaaf Content-Type: multipart/alternative; boundary="00000000000066fe0d05cf0aeaae" --00000000000066fe0d05cf0aeaae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Chengli Please see my reply to Darren about the pseudocode update to the draft. I highly recommend updating the draft per Darren=E2=80=99s updates, as thi= s change will really helps us understand the next and replace pseudocode processing as most of the questions all related to indexing of the bits within the SRH SID being copied to DA. I have been referring to uSID draft for my Next and G-SID got replace which maybe slightly different then the C-SID draft. So this update will be extremely helpful to the WG. I believe what Greg and I were referring to is End versus End.x and how End.x adj-sid there is no change as to what bits are referenced in SRH SID when copied to DA, however with End prefix sid their is pseudocode change as to bits referenced in the Argument portion of the SRH C-SID and both next and replace reference different bit ranges within the Argument container. It has been mentioned on some of the threads that the 128 bit SID, argument portion IID portion of the IPv6 address may appear as funky address as it may contain multiple CSIDs. So a question to 6MAN related to RFC 8200 IPv6 specification violations is being addressed by folks in the WG. So an outstanding question is if the list of SIDs in the SRH as SID entries in the SRH per IPv6 specification do they all have to be valid IPv6 address, does it have to be a valid address in the SRH for the active SID or does only what is copied from SRH Active SID to DA, is it that only what is copied needs to follow IPv6 specification as far as IPv6 address format. Kind Regards Gyan On Thu, Oct 21, 2021 at 11:12 PM Chengli (Cheng Li) wrote: > Hi Gyan, > > > > Sorry I don=E2=80=99t understand the case you mentioned. Could you please= provide > an easy example? How a SID will be shifting in a GSID container? > > > > Respect, > > Cheng > > > > > > *From:* ipv6 [mailto:ipv6-bounces@ietf.org] *On Behalf Of *Gyan Mishra > *Sent:* Friday, October 22, 2021 6:58 AM > *To:* Darren Dukes (ddukes) > *Cc:* spring@ietf.org; ipv6@ietf.org > *Subject:* Re: Typo correction Re: Question from SPRING regarding > draft-filsfilscheng-spring-srv6-srh-compression > > > > > > > > Hi Darren > > > > What Greg is asking is if the SID is a prefix SID End and not adjacency > SID End.x, so now the common prefix is needed to ECMP steer the flow to > the prefix SID which uses the common prefix, which may in this case be > mutated due to shifting of SIDs in GSID container. > > > > > > Kind Regards > > > > Gyan > > On Thu, Oct 21, 2021 at 10:18 AM Darren Dukes (ddukes) 40cisco.com@dmarc.ietf.org> wrote: > > Hi Greg, > > > > Your question is not clear to me. > > Can you try to restate it with the flavors and behaviors from the draft i= n > question? > > > > Darren > > > > On 2021-10-20, 4:15 PM, "ipv6" wrote: > > > > Hi Brian, > > I've got some questions about what you've said: > > For that reason, the fact that the bottom 64 bits in the > > "address" look funny or change is simply irrelevant. They are > > invisible to routing (which is done based on the prefix) > > and invisible to neighbor discovery (because it never happens). > > As I understand it, what you describe is the case of a strict explicit > path defined using one of the C-SID compression methods. But I am not sur= e > that your conclusion also always applies when it is a loose explicit path > specified in the compressed Segment List. As all C-SIDs share the same > prefix, how routing can be done based only on that prefix and not using a > part of that "funny" bottom 64 bits? And if any part of the bottom 64 bit= s > must be used, how one can guarantee that CIDR still works in that domain? > > > > Regards, > > Greg > > > > On Mon, Oct 18, 2021 at 9:50 PM Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > > Hi, > > After reading a lot of messages, I'm going to offer my considered > opinion as a direct response to Joel's OP. > > Firstly, I don't believe that in the end this draft raises any > concerns that are *significantly* different than those raised > when RFC 8986 was in draft. As Ted Hardie mentioned, section 5 > of RFC 8754 explains that SIDs of any shape or size are only > meaningful within an SR domain. That applies to srh-compression > too. > > Secondly, I was concerned about how these strange looking > "addresses" would potentially interfere with normal IPv6 > addresses and their handling by normal IPv6 nodes. Well, I > now believe that they won't. The reason is that in the SR model > these "addresses" are *never used for final delivery of IPv6 > packets to a host.* All SRv6 participants are routers. The > last hop for a packet whose DA is set to (say) 2001:db8:a:1900:: > is *not* the last hop on a LAN, mediated by neighbor discovery > for 2001:db8:a:1900::. It's just a hop from one router to another, > using the entry for 2001:db8:a:1900::/64 in the FIB of the last > router that actually forwards the packet. 2001:db8:a:1900:: is > not assigned to a physical interface so RFC 4861 is never invoked. > > Another way to say it is RFC 7608 is the relevant architectural > standard. CIDR rules, even within an SR domain. > > For that reason, the fact that the bottom 64 bits in the > "address" look funny or change is simply irrelevant. They are > invisible to routing (which is done based on the prefix) > and invisible to neighbor discovery (because it never happens). > > I apologise if this is all obvious to everybody, but I needed > to spell it out for my own understanding. > > Now back to Joel's questions: > > > On 13-Oct-21 20:37, Joel M. Halpern wrote: > > There is a typo in the below which if not understood as a typo would be > > > quite confusing. I wrote that I raised the issue with > > "with the Internet ADs and SPRING chairs". > > That should have read "with the Internet ADs and 6man chairs". > > The SPRING co-chairs are recused, and the charter requirement leads to > > the 6man chairs. Which is who I talked to. > > > > Also, I am sending a courtesy copy to the routing ADs, which I should > > have done originally. > > > > Thank you and enjoy. > > Yours, > > Joel > > > > On 10/12/2021 11:52 PM, Joel M. Halpern wrote: > >> The SPRING working group is in the midst of an adoption call on > >> > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-comp= ression/. > > >> > >> > >> The SPRING charter has text that is explicit that modifications to dat= a > >> planes and architectures standardized by other working groups may not > be > >> modified in SPRING unless the chairs and ADs responsible for that data > > >> plane and / or architecture agree. > >> > >> To complete the context, as my SPRING co-chairs are co-authors on the > >> document in question, they have recused themselves from decisional > >> activities regarding the document. Therefore, this message is coming > >> just from my as the responsible SPRING co-chair managing this adoption > > >> call. > >> > >> As you have seen, multiple questions have been raised about the > >> relationship of the document to the IPv6 defined data plane and > >> architecture (particularly RFC 4291 and 8200). In particular the > >> questions seem to revolve around what the document describes as the > >> NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6 > >> standards. (For those seeking more context without reading the full > >> document, a paraphrase and simplification of the NEXT-C_SID flavor is > >> provided as a postscript.) > >> > >> I raised the question of concurrence as required by the SPRING charter > > >> with the Internet ADs and SPRING chairs. They quite reasonably asked > me > >> to write a note to 6man explaining the concerns as clearly as a can, s= o > >> that they can then determine how to proceed. > >> > >> The questions that prompted my inquiry are: > >> > >> 1) Does the placement of a list of sids in the IPv6 DA field change th= e > >> IPv6 architectural description of that field. > > I think it should be noted explicitly somewhere that since the contents > of the DA field are *never* used for last-hop neighbor discovery, > the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942 > are irrelevant. Another citation is RFC 7608: for routing, all that > counts is the prefix, and it can be anything up to 128. > > Perhaps this should have been in section 5 of RFC 8754, but I leave > that to the wordsmiths. > > >> 2) Does the operation of shifting information around in the IPv6 > >> destination address field represent a modification or extension of the > > >> IPv6 data plane. > > No. As my text above indicates, the SRv6 DA field is only ever used > by routing, where RFC 7608 rules. And of course it vanishes as soon > as the packet is decapsulated. > > Regards > Brian > > >> > >> On a related note, the document in question also defines two other > >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The > >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID > >> flavor operation, so seems to be affected by the same question. > >> > >> From my own reading, it appears that the REPLACE-C-SID flavor does no= t > >> raise issues requiring 6man leadership concurrence. > >> > >> Yours, > >> Joel M. Halpern for the SPRING working group > >> > >> > >> PS: > >> Clearly, understanding the question requires some understanding of wha= t > >> the NEXT-C_SID flavor does. This explanation is a simplification for > >> length and context. Really, the best place to understand it is the > >> draft. However, to give you enough information to let you decide > > >> whether you care, I will try to provide a fair summary. My apologies > in > >> advance to the authors for necessary liberties for length. Also, > > >> discussion of the draft contents (as distinct from the interaction wit= h > >> the IPv6 data plane and architecture) belongs on the SPRING list, and > >> should not clutter up 6man. > >> > >> SIDs are the identifiers used in segment routing. > >> In SRv6, as document in the current RFCs, these are 128 bits. As > >> defined in the relevant RFCs, SIDs which identify endpoints to which > >> packets are directed are identified by endpoint SIDs. These can have > >> behaviors (decapsulate and forward is one example). They can have > >> flavors such as where the SRH is removed. > >> > >> The topic under discussion is means to compress these SIDs in the > >> packets on the wire. The document under discussion provides three > >> flavors of compression. > >> > >> The fundamental mechanism of the draft is to use a single SRH entry as > a > >> container for multiple SIDs. In the NEXT-C_SID mechanism, when it is > >> first encountered the entire container is copied into the desination > >> address of the IPv6 packet. The container has a common routing prefix > >> used for all the NEXT-C-SID SIDs. It is followed by a sequence of > >> compressed SIDs of a configured length. One could configure 16, 24, o= r > >> 32 bits. Or whatever length. The routing advertisements are arranged > >> so that the IPv6 packet is directed to the node represented by the > first > >> compressed SID on the basis of longest prefix match matching the > >> combination of the common routing prefix and that compressed SID. > >> > >> When the packet arrives at that node, it looks up the configured > >> portion, the compressed SID, and determines the behavior and flavor. > In > >> the case of the NEXT-C-SID flavor, the resulting operation is to shift > > >> the entire remaining contents of the IPv6 address (the bits past the > >> first compressed sid) so as to over-write the first compressed SID. 0 > >> bits are shifted into the low order positions. If the result is a > >> non-zero new first compressed SID, then the packets is forwarded and > the > >> process repeats. When all that is left are 0s, if there is an SRH, it > >> is consulted to find the next SRH entry, which is, per normal SRv6 > >> processing, put into the IPv6 DA. > >> Note that in the common case where the SIDS needed all fit in to a > >> single container, the analysis also assumes the use of the reduced > >> encapsulation options which omits the SRH that is not needed as it > would > >> have no entries. This the packet contains a normal IPv6 header, with = a > >> sequence of compressed SIDs (what one might or might not call a source > > >> route) in the IPv6 destination address field. > >> > >> PPS: If the authors of the NEXT-C-SID flavor feel I have > mis-represented > >> the work, please, send clarifications or corrections. Again, the bes= t > >> source of information is the draft itself. I was asked to provide > extra > >> context in this email. > > > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > -- > > [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* > > > --=20 *Gyan Mishra* *Network Solutions A**rchitect * *Email gyan.s.mishra@verizon.com * *M 301 502-1347* --00000000000066fe0d05cf0aeaae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Hi Chengli

    Please see my reply to Darren about the pseudocode upda= te to the draft.

    I highl= y recommend updating the draft per Darren=E2=80=99s updates, =C2=A0as this = change will really helps us understand the next and replace pseudocode proc= essing as most of the questions all related to indexing of the bits within = the SRH SID being copied to DA.=C2=A0 I have been referring to uSID draft f= or my Next and G-SID got replace which maybe slightly different then the C-= SID draft.=C2=A0 So this update will be extremely helpful to the WG.
    <= div dir=3D"auto">
    I believe what Greg and I were= referring to is End versus End.x and how End.x adj-sid there is no change = as to what bits are referenced in SRH SID when copied to DA, however with E= nd prefix sid their is pseudocode change as to bits referenced in the Argum= ent portion of the SRH C-SID and both next and replace reference different = bit ranges within the Argument container. =C2=A0
    It has been mentioned on some of the threads that = the 128 bit SID, argument portion IID portion of the IPv6 address may appea= r as funky address as it may contain multiple CSIDs.=C2=A0 So a question to= 6MAN related to RFC 8200 IPv6 specification violations is being addressed = by folks in the WG. =C2=A0

    So an outstanding question is if the list of SIDs in the SRH as SID entr= ies in the SRH per IPv6 specification do they all have to be valid IPv6 add= ress, does it have to be a valid address in the SRH for the active SID or d= oes only what is copied from SRH Active SID to DA, is it that =C2=A0only wh= at is copied needs to follow IPv6 specification as far as IPv6 address form= at.=C2=A0

    Kind Regards= =C2=A0

    Gyan
    On Thu, Oct = 21, 2021 at 11:12 PM Chengli (Cheng Li) <c.l@huawei.com> wrote:

    Hi Gyan,

    =C2=A0

    Sorry I don=E2=80=99t understand the = case you mentioned. Could you please provide an easy example? How a SID wil= l be shifting in a GSID container?

    =C2=A0

    Respect,

    Cheng

    <= /div>

    =C2=A0

    =C2=A0

    From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Gyan Mishra
    Sent: Friday, October 22, 2021 6:58 AM
    To: Darren Dukes (ddukes) <ddukes=3D40cisco.com@dmarc.ietf.org>
    Cc: spring@ietf= .org; ipv6@ietf.org<= /a>
    Subject: Re: Typo correction Re: Question from SPRING regarding draf= t-filsfilscheng-spring-srv6-srh-compression

    =C2=A0

    =C2=A0

    =C2=A0

    Hi Darren=C2=A0

    =C2=A0

    What Greg is asking is if the SID is a prefix SID En= d and not adjacency SID End.x, so now the common prefix is needed to ECMP s= teer the flow =C2=A0to the prefix SID which uses the common prefix, =C2=A0w= hich may in this case be mutated due to shifting of SIDs in GSID container.

    =C2=A0

    =C2=A0

    Kind Regards=C2=A0

    =C2=A0

    Gyan=C2=A0

    Hi Greg,

    =C2=A0

    Your question is not clear to me.

    Can you try to restate it with the flavors and behav= iors from the draft in question?<= /p>

    =C2=A0

    Darren

    =C2=A0

    On 2021-10-20, 4:15 PM, "ipv6" <ipv6-bounces@ietf.org> wrote:

    =C2=A0

    Hi Brian,

    I've got some questions about what you've said= :

    For that reason, the fact that the bottom 64 bits in t= he

    "address" look funny or change is simply irr= elevant. They are

    invisible to routing (which is done based on the prefi= x)

    and invisible to neighbor discovery (because it never = happens).

    As I understand it, what you describe is the case of a= strict explicit path defined using one of the C-SID compression methods. B= ut I am not sure that your conclusion also always applies when it is a loos= e explicit path specified in the compressed Segment List. As all C-SIDs share the same prefix, how routing can be done= based only on that prefix and not using a part of that "funny" b= ottom 64 bits? And if any part of the bottom 64 bits must be used, how one= =C2=A0can guarantee that CIDR still works in that domain?

    =C2=A0

    Regards,

    Greg

    =C2=A0

    Hi,

    After reading a lot of messages, I'm going to offer my considered
    opinion as a direct response to Joel's OP.

    Firstly, I don't believe that in the end this draft raises any
    concerns that are *significantly* different than those raised
    when RFC 8986 was in draft. As Ted Hardie mentioned, section 5
    of RFC 8754 explains that SIDs of any shape or size are only
    meaningful within an SR domain. That applies to srh-compression
    too.

    Secondly, I was concerned about how these strange looking
    "addresses" would potentially interfere with normal IPv6
    addresses and their handling by normal IPv6 nodes. Well, I
    now believe that they won't. The reason is that in the SR model
    these "addresses" are *never used for final delivery of IPv6
    packets to a host.* All SRv6 participants are routers. The
    last hop for a packet whose DA is set to (say) 2001:db8:a:1900::
    is *not* the last hop on a LAN, mediated by neighbor discovery
    for 2001:db8:a:1900::. It's just a hop from one router to another,
    using the entry for 2001:db8:a:1900::/64 in the FIB of the last
    router that actually forwards the packet. 2001:db8:a:1900:: is
    not assigned to a physical interface so RFC 4861 is never invoked.

    Another way to say it is RFC 7608 is the relevant architectural
    standard. CIDR rules, even within an SR domain.

    For that reason, the fact that the bottom 64 bits in the
    "address" look funny or change is simply irrelevant. They are
    invisible to routing (which is done based on the prefix)
    and invisible to neighbor discovery (because it never happens).

    I apologise if this is all obvious to everybody, but I needed
    to spell it out for my own understanding.

    Now back to Joel's questions:


    On 13-Oct-21 20:37, Joel M. Halpern wrote:
    > There is a typo in the below which if not understood as a typo would b= e

    > quite confusing.=C2=A0 =C2=A0I wrote that I raised the issue with
    > "with the Internet ADs and SPRING chairs".
    > That should have read "with the Internet ADs and 6man chairs"= ;.
    > The SPRING co-chairs are recused, and the charter requirement leads to=
    > the 6man chairs.=C2=A0 Which is who I talked to.
    >
    > Also, I am sending a courtesy copy to the routing ADs, which I should =
    > have done originally.
    >
    > Thank you and enjoy.
    > Yours,
    > Joel
    >
    > On 10/12/2021 11:52 PM, Joel M. Halpern wrote:
    >> The SPRING working group is in the midst of an adoption call on >> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/.
    >>
    >>
    >> The SPRING charter has text that is explicit that modifications to= data
    >> planes and architectures standardized by other working groups may = not be
    >> modified in SPRING unless the chairs and ADs responsible for that = data

    >> plane and / or architecture agree.
    >>
    >> To complete the context, as my SPRING co-chairs are co-authors on = the
    >> document in question, they have recused themselves from decisional=
    >> activities regarding the document.=C2=A0 Therefore, this message i= s coming
    >> just from my as the responsible SPRING co-chair managing this adop= tion

    >> call.
    >>
    >> As you have seen, multiple questions have been raised about the >> relationship of the document to the IPv6 defined data plane and >> architecture (particularly RFC 4291 and 8200). In particular the <= br> >> questions seem to revolve around what the document describes as th= e
    >> NEXT-C-SID flavor of compressed SID, and its relationship to the I= Pv6
    >> standards.=C2=A0 (For those seeking more context without reading t= he full
    >> document, a paraphrase and simplification of the NEXT-C_SID flavor= is
    >> provided as a postscript.)
    >>
    >> I raised the question of concurrence as required by the SPRING cha= rter

    >> with the Internet ADs and SPRING chairs.=C2=A0 They quite reasonab= ly asked me
    >> to write a note to 6man explaining the concerns as clearly as a ca= n, so
    >> that they can then determine how to proceed.
    >>
    >> The questions that prompted my inquiry are:
    >>
    >> 1) Does the placement of a list of sids in the IPv6 DA field chang= e the
    >> IPv6 architectural description of that field.

    I think it should be noted explicitly somewhere that since the contents
    of the DA field are *never* used for last-hop neighbor discovery,
    the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942
    are irrelevant. Another citation is RFC 7608: for routing, all that
    counts is the prefix, and it can be anything up to 128.

    Perhaps this should have been in section 5 of RFC 8754, but I leave
    that to the wordsmiths.

    >> 2) Does the operation of shifting information around in the IPv6 <= br> >> destination address field represent a modification or extension of= the

    >> IPv6 data plane.

    No. As my text above indicates, the SRv6 DA field is only ever used
    by routing, where RFC 7608 rules. And of course it vanishes as soon
    as the packet is decapsulated.

    Regards
    =C2=A0 =C2=A0 Brian

    >>
    >> On a related note, the document in question also defines two other=
    >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.=C2=A0 The
    >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID=
    >> flavor operation, so seems to be affected by the same question. >>
    >>=C2=A0 From my own reading, it appears that the REPLACE-C-SID flavo= r does not
    >> raise issues requiring 6man leadership concurrence.
    >>
    >> Yours,
    >> Joel M. Halpern for the SPRING working group
    >>
    >>
    >> PS:
    >> Clearly, understanding the question requires some understanding of= what
    >> the NEXT-C_SID flavor does.=C2=A0=C2=A0 This explanation is a simp= lification for
    >> length and context.=C2=A0 Really, the best place to understand it = is the
    >> draft.=C2=A0 However, to give you enough information to let you de= cide

    >> whether you care, I will try to provide a fair summary.=C2=A0 My a= pologies in
    >> advance to the authors for necessary liberties for length.=C2=A0 A= lso,

    >> discussion of the draft contents (as distinct from the interaction= with
    >> the IPv6 data plane and architecture) belongs on the SPRING list, = and
    >> should not clutter up 6man.
    >>
    >> SIDs are the identifiers used in segment routing.
    >> In SRv6, as document in the current RFCs, these are 128 bits.=C2= =A0=C2=A0 As
    >> defined in the relevant RFCs, SIDs which identify endpoints to whi= ch
    >> packets are directed are identified by endpoint SIDs.=C2=A0 These = can have
    >> behaviors (decapsulate and forward is one example).=C2=A0 They can= have
    >> flavors such as where the SRH is removed.
    >>
    >> The topic under discussion is means to compress these SIDs in the =
    >> packets on the wire.=C2=A0 The document under discussion provides = three
    >> flavors of compression.
    >>
    >> The fundamental mechanism of the draft is to use a single SRH entr= y as
    a
    >> container for multiple SIDs.=C2=A0 In the NEXT-C_SID mechanism, wh= en it is
    >> first encountered the entire container is copied into the desinati= on
    >> address of the IPv6 packet.=C2=A0 The container has a common routi= ng prefix
    >> used for all the NEXT-C-SID SIDs.=C2=A0 It is followed by a sequen= ce of
    >> compressed SIDs of a configured length.=C2=A0 One could configure = 16, 24, or
    >> 32 bits.=C2=A0 Or whatever length.=C2=A0 The routing advertisement= s are arranged
    >> so that the IPv6 packet is directed to the node represented by the= first
    >> compressed SID on the basis of longest prefix match matching the <= br> >> combination of the common routing prefix and that compressed SID.<= br> >>
    >> When the packet arrives at that node, it looks up the configured <= br> >> portion, the compressed SID, and determines the behavior and flavo= r.=C2=A0 In
    >> the case of the NEXT-C-SID flavor, the resulting operation is to s= hift

    >> the entire remaining contents of the IPv6 address (the bits past t= he
    >> first compressed sid) so as to over-write the first compressed SID= .=C2=A0 0
    >> bits are shifted into the low order positions.=C2=A0 If the result= is a
    >> non-zero new first compressed SID, then the packets is forwarded a= nd the
    >> process repeats.=C2=A0 When all that is left are 0s, if there is a= n SRH, it
    >> is consulted to find the next SRH entry, which is, per normal SRv6=
    >> processing, put into the IPv6 DA.
    >> Note that in the common case where the SIDS needed all fit in to a=
    >> single container, the analysis also assumes the use of the reduced=
    >> encapsulation options which omits the SRH that is not needed as it= would
    >> have no entries.=C2=A0 This the packet contains a normal IPv6 head= er, with a
    >> sequence of compressed SIDs (what one might or might not call a so= urce

    >> route) in the IPv6 destination address field.
    >>
    >> PPS: If the authors of the NEXT-C-SID flavor feel I have mis-repre= sented
    >> the work, please, send clarifications or corrections.=C2=A0=C2=A0 = Again, the best
    >> source of information is the draft itself.=C2=A0 I was asked to pr= ovide extra
    >> context in this email.
    >
    > -------------------------------------------------------------------- > IETF IPv6 working group mailing list
    > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > -------------------------------------------------------------------- >

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------=

    ----------------------------------------------------= ----------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------=

    --

    <= div>

    Gyan Mishra

    Network Solutions Architect=C2=A0

    Email gyan.s.mishr= a@verizon.com

    M 301 = 502-1347

    =C2=A0

    --
    --00000000000066fe0d05cf0aeaae-- --00000000000066fe0f05cf0aeaaf Content-Type: image/jpeg; name="image001.jpg" Content-Disposition: inline; filename="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: <17caebee7b34cd34f0f1> X-Attachment-Id: 17caebee7b34cd34f0f1 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAASAFEBAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZqKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKK/9k= --00000000000066fe0f05cf0aeaaf-- From nobody Sat Oct 23 23:34:31 2021 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 5D93F3A12AD; Sat, 23 Oct 2021 23:31:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl 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 JzG2L-BCUdL4; Sat, 23 Oct 2021 23:31:21 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [185.54.92.22]) (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 F2E0A3A12AC; Sat, 23 Oct 2021 23:31:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 4D3E451; Sun, 24 Oct 2021 08:31:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:references:message-id:content-transfer-encoding:date :date:in-reply-to:from:from:subject:subject:mime-version :content-type:content-type:received:received; s=mail; t= 1635057073; bh=vtH3qoBrgB6RR68X99d2zxhV/niBdYGzpVvQHh77xek=; b=k NCk0JReJYJ1dBh1KTK6KpgX+WuBhO45PZrGf3K18jDEChEua8WWT5ColLfx2+BY1 e1OGyldzNFWfYmJI5ATmN+d7P7uemwuypxlazgAc1F3cQMKV/xiD32KAm9MmOZ4B KTfjndIlRDADMkKpmNjp7GeEY1cRWV9+mRjAubD210= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MXmLS3E0_Dig; Sun, 24 Oct 2021 08:31:13 +0200 (CEST) Received: from smtpclient.apple (unknown [IPv6:2001:9e0:8804:7701:8064:aac4:9171:32fc]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id AD2574A; Sun, 24 Oct 2021 08:31:13 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann In-Reply-To: <4b39ddbe-7b49-3dd9-5c93-8bd7c4190086@foobar.org> Date: Sun, 24 Oct 2021 08:31:13 +0200 Cc: Stefano Salsano , SPRING WG List , ipv6@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <06589821-19C6-4DD9-8202-ABA540609097@steffann.nl> References: <4b39ddbe-7b49-3dd9-5c93-8bd7c4190086@foobar.org> To: Nick Hilliard X-Mailer: Apple Mail (2.3654.120.0.1.13) Archived-At: Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 24 Oct 2021 06:31:48 -0000 Hi, > On this basis, I'm objecting to the adoption of = draft-filsfilscheng-spring-srv6-srh-compression as a WG draft, and = respectfully suggest that the spring wg does not adopt any draft in = future which allows for different C-SID lengths but doesn't encode = C-SIDs as {length,value} tuples. I support this argument, so +1 to the objection. Cheers, Sander From nobody Sun Oct 24 04:58:35 2021 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 4AE9B3A11D2 for ; Sun, 24 Oct 2021 04:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 hIk4XEzqhNee for ; Sun, 24 Oct 2021 04:58:13 -0700 (PDT) Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (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 16DBB3A0DD8 for ; Sun, 24 Oct 2021 04:58:12 -0700 (PDT) Received: by mail-vk1-xa35.google.com with SMTP id n201so3764292vkn.12 for ; Sun, 24 Oct 2021 04:58:12 -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=d9dy4jNEkx/zythM0NlsxRZY2gyrbBEHH/8hzUNOvgM=; b=WP3g+hvtcS6iZEip9MUUIemneF5FdewAS860bRp13ivrAO6nba/AbUZecJVWl5IHJy MwN6FS93ayBPnied2XjUKnzQr8xJUFUkDX5y6lsjj4YKbMkTqQF9jo0zmDHEC6A6xCxC UY5mrVMGWryvyvHfnEBvqbeBt4C0YOrtgPh3ojgquaidhbKgicpBzqjyS3spT0yiK+Ko hy3i1dJYJiWrqxM0sSeNnAX6vXPLHXHOrWANGuShgiioXnu6hjSVilt0cxL4MMWM4E2A +ACv72xN/wDYZTptLOLdIrJZQ29yRQ5mgcjHtrUhhCJ7iM4JrFtQYfBMLqx2sAiTLpMP DHUA== 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=d9dy4jNEkx/zythM0NlsxRZY2gyrbBEHH/8hzUNOvgM=; b=YAQrxInpmky0GUck8UzNYwGRYM/ulR3Xs6+qWbMZqUP8QVFpjHmlhXaOG4GlUBpTjt PgEybuJuZDIhg+Szx+WwTHTzDuR8/T59iSw0m04oZbF9DE33uXHh+BBwfjP1BrJrTQ08 e9pysIiAHa/dXOvoJoq229g8ZNzss6OEQ1eShppqAdAaZ+K2mRdNmK+Rhe0AfDPxnNuX 0ZovrLDn5wA8KlcIlv0Tj0hAfEbbVA1iIBNRJqVp2nCGpU82i/53gXCm8Vzi2XxZGWsD vhiAU1ss7Zp301/33sljYBvY8uheKT126CVBEshzzd11l20252TBj8drPTqTzYpbl/He uyhg== X-Gm-Message-State: AOAM533OWj8CydRT6xM/ZvZjdp9qdF6ch0+hQAjra0Cd0RF9XooXpr6U ZiPQuEGfbW3F+NJMJ2JY8ufqFCGcT08TMCUiMDfNZQ== X-Google-Smtp-Source: ABdhPJwyZ9PBCzqQ/euqk11y/P0IR2sMUYxAgd841rbBzsQjk/KkOUipI5uvt0q/4bvd6j4132Pv4W19A0WmxajvVx4= X-Received: by 2002:a05:6122:789:: with SMTP id k9mr9708816vkr.17.1635076691486; Sun, 24 Oct 2021 04:58:11 -0700 (PDT) MIME-Version: 1.0 References: <4b39ddbe-7b49-3dd9-5c93-8bd7c4190086@foobar.org> <06589821-19C6-4DD9-8202-ABA540609097@steffann.nl> In-Reply-To: <06589821-19C6-4DD9-8202-ABA540609097@steffann.nl> From: Robert Raszuk Date: Sun, 24 Oct 2021 13:58:05 +0200 Message-ID: To: Sander Steffann Cc: Nick Hilliard , SPRING WG List , 6man WG , Stefano Salsano Content-Type: multipart/alternative; boundary="00000000000060818605cf17f5d3" Archived-At: Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 24 Oct 2021 11:58:18 -0000 --00000000000060818605cf17f5d3 Content-Type: text/plain; charset="UTF-8" Nick & Sander, Just for my own understanding here. A) Are you asking to add new TLV to IPv6 SRH say called "C-SID Length" (and make SRH mandatory if used with C-SIDs) which would define the C-SID length ? or B) Are you asking to define a completely new data plane for IP networks ? By new data plane I mean either the format of IP header in the packets. or C) What else are you suggesting ? - - If this is (A) I think it could be considered. SRH already supports TLVs. That way even wireshark could read and parse C-SIDs correctly (if this is of any value when detached from rest of control plane). Thx, Robert. On Sun, Oct 24, 2021 at 8:33 AM Sander Steffann wrote: > Hi, > > > On this basis, I'm objecting to the adoption of > draft-filsfilscheng-spring-srv6-srh-compression as a WG draft, and > respectfully suggest that the spring wg does not adopt any draft in future > which allows for different C-SID lengths but doesn't encode C-SIDs as > {length,value} tuples. > > I support this argument, so +1 to the objection. > > Cheers, > Sander > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --00000000000060818605cf17f5d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Nick & Sander,

    Just for my own unde= rstanding here.=C2=A0

    A)=C2=A0 Are you asking to a= dd new=C2=A0TLV to IPv6 SRH say=C2=A0called=C2=A0"C-SID Length" (= and make SRH mandatory if used with C-SIDs) which would define the C-SID le= ngth ?=C2=A0

    or=C2=A0

    B) = Are you asking to define a completely new data plane for IP networks ? By n= ew data plane I mean either the format of IP header in the packets.=C2=A0

    or=C2=A0

    C) What else are= =C2=A0you suggesting ?=C2=A0

    - -=C2=A0
    <= br>
    If this is (A)=C2=A0 I think it could be considered. SRH alre= ady supports TLVs. That way even wireshark could read and parse C-SIDs corr= ectly=C2=A0(if this is of any value when detached from rest=C2=A0of control= plane).=C2=A0

    Thx,
    Robert.

    On Sun, Oct 24, 2021 at 8:33 AM Sander Steffann <sander@steffann.nl> wrote:
    Hi,

    > On this basis, I'm objecting to the adoption of draft-filsfilschen= g-spring-srv6-srh-compression as a WG draft, and respectfully suggest that = the spring wg does not adopt any draft in future which allows for different= C-SID lengths but doesn't encode C-SIDs as {length,value} tuples.

    I support this argument, so +1 to the objection.

    Cheers,
    Sander

    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --00000000000060818605cf17f5d3-- From nobody Sun Oct 24 08:15:19 2021 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 BBB343A096B; Sun, 24 Oct 2021 08:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl 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 DBerpDC1wBTK; Sun, 24 Oct 2021 08:15:07 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [185.54.92.22]) (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 3AFAC3A0963; Sun, 24 Oct 2021 08:15:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 68C0951; Sun, 24 Oct 2021 17:15:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:in-reply-to:references:message-id:date:date:subject :subject:mime-version:from:from:content-transfer-encoding :content-type:content-type:received:received; s=mail; t= 1635088502; bh=gRRVaUviMy2JNEwLbYfQFEdArkdd6ZEBSpG/C5h1mEg=; b=g hWldqp+FT4Yj/PykqIVXIM2fN9hYdNVjWaaJv+OSZFSV1xgsYa5x1TcXNoKndvyF gBVau9CiNbCylNNfFXPBCUYvVkz0sfotSOOagBjD9knYOXh2h1pfC3pCV7x/33kg gOL7/DULobLQBpdlGkXiTBDUvJXHCm1iUC/P0ForZ4= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1LmUKa_CPXgI; Sun, 24 Oct 2021 17:15:02 +0200 (CEST) Received: from smtpclient.apple (unknown [IPv6:2001:9e0:8804:7701:a04d:c471:87c0:bd79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id EBE064A; Sun, 24 Oct 2021 17:15:01 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Mime-Version: 1.0 (1.0) Date: Sun, 24 Oct 2021 17:15:00 +0200 Message-Id: References: Cc: Nick Hilliard , SPRING WG List , 6man WG , Stefano Salsano In-Reply-To: To: Robert Raszuk X-Mailer: iPhone Mail (19A348) Archived-At: Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 24 Oct 2021 15:15:13 -0000 Hi, > Just for my own understanding here.=20 >=20 > A) Are you asking to add new TLV to IPv6 SRH say called "C-SID Length" (a= nd make SRH mandatory if used with C-SIDs) which would define the C-SID leng= th ?=20 Yes, that would be a step in the right direction.=20 > B) Are you asking to define a completely new data plane for IP networks ? B= y new data plane I mean either the format of IP header in the packets. With the stuff being stacked on top of the basic SRv6 spec it=E2=80=99s defi= nitely starting to look like one :) But I also see the benefit of using the existing IPv6 data plane when doing S= R between administrative domains. That does require better interop facilitie= s than the current drafts provide though. > If this is (A) I think it could be considered. SRH already supports TLVs.= That way even wireshark could read and parse C-SIDs correctly (if this is o= f any value when detached from rest of control plane).=20 The tool used doesn=E2=80=99t matter. What matters that an engineer can unde= rstand and decode what=E2=80=99s going on on the wire when stuff breaks. And= that the headers contain enough information to use for interop between mult= iple admin domains for example.=20 Cheers, Sander From nobody Sun Oct 24 08:36:23 2021 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 B85233A003F; Sun, 24 Oct 2021 08:36:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.23 X-Spam-Level: X-Spam-Status: No, score=-5.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-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 ZpV2wklqcVPa; Sun, 24 Oct 2021 08:36:19 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7FD13A0029; Sun, 24 Oct 2021 08:36:16 -0700 (PDT) X-Envelope-To: spring@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 19OFa6PM095828 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Oct 2021 16:36:06 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: Sander Steffann Cc: Robert Raszuk , SPRING WG List , 6man WG , Stefano Salsano References: From: Nick Hilliard Message-ID: Date: Sun, 24 Oct 2021 16:36:02 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.49 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 24 Oct 2021 15:36:22 -0000 Sander Steffann wrote on 24/10/2021 16:15: > The tool used doesn’t matter. What matters that an engineer can > understand and decode what’s going on on the wire when stuff breaks. > And that the headers contain enough information to use for interop > between multiple admin domains for example. The issue is a good deal deeper than just debugging. As long as there's an option to specify a variable length parameter without being able to specify the length in the protocol, then the protocol is fundamentally ambiguous and its interpretation is entirely context dependent. I.e. one router might interpret a c-sid sequence completely differently to another. The fact that debugging becomes arbitrary and dependent on context is a second order issue. It doesn't matter how the length is specified: it could be a tuple; it could be a set of codepoints. What's important is that it's specified unambiguously in the protocol structure on a per-SID basis. Nick From nobody Sun Oct 24 10:17:53 2021 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 433783A03F3; Sun, 24 Oct 2021 10:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.42 X-Spam-Level: X-Spam-Status: No, score=-5.42 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, NICE_REPLY_A=-3.33, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 tgNlr12TytsZ; Sun, 24 Oct 2021 10:17:44 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 375AF3A0418; Sun, 24 Oct 2021 10:17:41 -0700 (PDT) Received: from [IPV6:2a02:aa15:4101:2a80:b41d:cff7:8894:6248] ([IPv6:2a02:aa15:4101:2a80:b41d:cff7:8894:6248]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 19OHHR2N3416530 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 24 Oct 2021 19:17:27 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1635095848; bh=bVmGOnCMwdOinGoAd321i0ija3CHAyBu7k8m4KzIkFs=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=PogeX3xSdaRZ8JfBsVI4s777Yux8cs8SiJrlmaHJgMKcSi/YYFT7qHN8PkR7iODH+ 3USwFORlYT1xRmbTX+6MDrFwC8a8jjk3LL2nM/Lt1w+eoDSUMnipZM8S9oGbK7F38I d0DHep2MbRZKmK9TY9qiyLpyfyL0QxZSQRGTkOMs= Message-ID: <89c62864-feb4-550e-2d63-264b2ecc3344@lear.ch> Date: Sun, 24 Oct 2021 19:17:26 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Content-Language: en-US To: Nick Hilliard , Sander Steffann Cc: SPRING WG List , 6man WG References: From: Eliot Lear In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------B0HjY0HTJO8U9HDRMP1ma9be" Archived-At: Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 24 Oct 2021 17:17:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------B0HjY0HTJO8U9HDRMP1ma9be Content-Type: multipart/mixed; boundary="------------kPcIPwV67E5uxuwZx1410j0K"; protected-headers="v1" From: Eliot Lear To: Nick Hilliard , Sander Steffann Cc: SPRING WG List , 6man WG Message-ID: <89c62864-feb4-550e-2d63-264b2ecc3344@lear.ch> Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) References: In-Reply-To: --------------kPcIPwV67E5uxuwZx1410j0K Content-Type: multipart/mixed; boundary="------------wt50kLtUSjdVFCMcYNlI6ttE" --------------wt50kLtUSjdVFCMcYNlI6ttE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQpPbiAyNC4xMC4yMSAxNzozNiwgTmljayBIaWxsaWFyZCB3cm90ZToNCj4gVGhlIGlzc3Vl IGlzIGEgZ29vZCBkZWFsIGRlZXBlciB0aGFuIGp1c3QgZGVidWdnaW5nLsKgIEFzIGxvbmcg YXMgDQo+IHRoZXJlJ3MgYW4gb3B0aW9uIHRvIHNwZWNpZnkgYSB2YXJpYWJsZSBsZW5ndGgg cGFyYW1ldGVyIHdpdGhvdXQgYmVpbmcgDQo+IGFibGUgdG8gc3BlY2lmeSB0aGUgbGVuZ3Ro IGluIHRoZSBwcm90b2NvbCwgdGhlbiB0aGUgcHJvdG9jb2wgaXMgDQo+IGZ1bmRhbWVudGFs bHkgYW1iaWd1b3VzIGFuZCBpdHMgaW50ZXJwcmV0YXRpb24gaXMgZW50aXJlbHkgY29udGV4 dCANCj4gZGVwZW5kZW50Lg0KDQpZb3UgbWVhbiwgbGlrZSBhIHN1Ym5ldCBtYXNrPw0KDQoN Cg== --------------wt50kLtUSjdVFCMcYNlI6ttE Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clTl= pVL ciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ9NcML= lD8 raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv5= 4oH 0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gC= tCj fvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlY= XIg PGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY0L2QR= h2w kqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCHtmtG2dJ6MyMyCACXv= tFj AYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA1U/OlZux+P/NaVMiZNZc8zw0nsx/I= NAq DOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyM= Jz+ GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0= MyS k1D5A7FdwDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM= +E5 C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMabGguI183qWgCcD= Bjq DmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxqYVx7wkYEEhECAAYFAlMfD7kAC= gkQ bSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A42U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3w= sBi BBMBCgAMBQJTIsh+BYMHhh+AAAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6Mqf= XAa hQt8ES3b9hXNKDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS= 5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc9XvabUOhC= Bb5 z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvSsIH63pw7GN5jhtURktWpm= /vX qNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucjhC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4= TTr Om5YWFbCRgQTEQIABgUCVxX/yAAKCRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMW= QCg iVjlI3bzSuDrqtOOWMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTA= QIA OAIbAwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoLAgQWA= gMB AAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVTt/GJX1CabzWSsAPO8= VAy 39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1MuU6AQBqepeAgieyaN5CMk5fyQj6T= mHe UhOWi8F6dk5cz2HbU4tPxQaMu8fi/1njRlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSy= UFh Z6Ic018VoddI0RZYNDBmfvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX42= 4Yi 9jgbZYdEEo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUCU= x8P rgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1zmVoE9701OnCD= bAf UOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJFO1KoP297EClcJRuMb2XIQCdG= q6D 9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUCUx7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSl= BST A9OAMkal7Qt4YgCdEzmwSiZOIahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AAC= gkQ xA2RF02ZCBD74ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlh= Oqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/FapcnAPZwKna= bXo zei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ/R3AMQJYmEvCFdUw8Pntm= 65U +cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoIrkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0S= c5i mFHHmb/U6j/QEvkrjCwAWYAeavOjU+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MA= AoJ EG6AD2cTbjy4Y0oAoJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUd= sLB cwQQAQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP/iaM1= GyO gKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxwjgV4MGLTRCfkKoBh5= vsF jCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0LtkkJ/rjvAnMYNNs/q6H4deNNg+yNs4X= eWX PxfGEZQxPdX58eGfY2P9OJPbxNqwX1pFkF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvY= vnt SiAC7T5Ucfe363Zp4/F1BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJH= kcN j3nKfqORMUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOtm= ZCs rf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWamTY+Wx8lOcx8X= WQQ 0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5ya0h9aTtz9cMnfCLHfVL2ZimkS= jsP o0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhdPCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gU= GUH AUhrFFdvM8gf9U/SbdS+BYzL+IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFb= Glv dCBMZWFyIDxsZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh= 7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRayV/uDnJJd= nx0 d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvRecu4R+GArK696HWes6Gr5= 8eV 9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaXXuf8r798Hl1ROJhuHRAA+U/IikuB8/93y= hiU NeaO/Sb/dh4Au0aQrdFmokNG+mnD9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFup= Jsd f/O7UBDayvtzZ+AiUhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5= /CA gDpW7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2Ekady= JJJ F3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgAtFle2HW7/ecWBj4bY= U3Q oQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQNQR+z4CxqBzojzOuTcrEaWfekUVV9= 0zX y5oRjBa+YTzhjXavsXBh1brZsD1fVO2ynlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxw= eoF bTHJF+W7iPadSt321YV3bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdW= LiC UjlgGUPSfaFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7K= 2ox YUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ0nozkrkIANu6d= q2A eyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlMH1JPDr4A3ARKyv25QwDF0M0oN= 7Ke OdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58MhACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCL= zIr o8snIzwLu8cSqZQbNfyBMJg6ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZ= oTD xTpg4SUph+eRywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7= dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------wt50kLtUSjdVFCMcYNlI6ttE-- --------------kPcIPwV67E5uxuwZx1410j0K-- --------------B0HjY0HTJO8U9HDRMP1ma9be Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmF1lSYFAwAAAAAACgkQh7ZrRtnSejO7 Fgf/RoHanUuXuMwTVbsLCwizhba3FwESHYLcHynsO4cuBZfeLb4lqU8NnK+Pkt7B+dBgmaZ/SqfH QM8bN1+dbPj/wlLhQtW4o780cGRAjclHCc4SJFBhcRIHw4hdPedGOEjLV4crVUFahmiLFTncuFgi klcvXkdQGr/QvA4fZuabfZ1aeI1ViDfavQ8XeFJWQBFwj0JIsCs2+nKhNb9QzewIk2sNAZnKcG/V DvE5iG1oWiYRzCeE6zITsaeWt9yLaJRbvZ5L0RRwBeFXhr+7sUMBwMUF4CoxRr1Cdme9VDtOUd/w 62NVPbFsJzKMSQvXLhkSHkIGX5TKpziMVKFAtIP9jA== =2Rob -----END PGP SIGNATURE----- --------------B0HjY0HTJO8U9HDRMP1ma9be-- From nobody Sun Oct 24 10:51:50 2021 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 3809A3A0863; Sun, 24 Oct 2021 10:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZedmXvRsqzs; Sun, 24 Oct 2021 10:51:39 -0700 (PDT) Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) (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 CCED73A0865; Sun, 24 Oct 2021 10:51:38 -0700 (PDT) Received: by mail-ed1-x52e.google.com with SMTP id l13so12162519edi.8; Sun, 24 Oct 2021 10:51:38 -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=GaZ/s3Jf46m/ajFX+GG9oDRVtpglKjE/YBLqB8lvFBQ=; b=il5Ayt0B7pQvZP7VvhSBGNFyz+uP/xTF2v6MlNsF6M0Zmr7B1So6zb9VcNqXTrYG3E 65e+pcThe8NsZJ5DAXcVWnIlCPZG0NWTNEfHSLpG4C+d7u0Lu/nUhmvnxZgDArNFwwMZ nvqkZ1KFO/mCKacoFYYXrE+F8h54vf2Yn9baefZOjPtDZMxOrByA2YZPLYNr/rEEiNe9 sivTC3PQm5UhcgocSaj8be78nco8NIoxyPt5NBFBI0gWSbruQOpqE6DP+rMpTJtnhbGx BwAx9t7PCZj4AB6wApM6TfiCmWeLw2AV5CxYnV6WnOZPnC8lcCPFZ+6V8wsDyTVEqnkr brOw== 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=GaZ/s3Jf46m/ajFX+GG9oDRVtpglKjE/YBLqB8lvFBQ=; b=oz05syGeLZAsicsnsu7rxLF7uQwkttZMJ425FtPm5fsL6RBEpxrxDL4hmTeh52gihc YonQoHuRcgTVf+w50oUDZpuIJ+O6XNSqlsT57kvDLHt8fiyf0l65zjWju4gd67kdXRfR 74auKi+7bwYWdxTn40W13VMp5uhhBrpnCw/GbbaMiyacc57snWbsIdvHL6E52Xbg6kv0 81Z4VEP1ni+o/cX08f8/lLy/rhycBOGwNuRYZCm3PZnPogZ/62TxLjW4BxhOdMQLAArH AHFsiwHwSDfmqzNouYZLa5Ors27p5dQj2xNun3cRI6FRRuxko3JK+PtlTU2NnjEINlzL RYEA== X-Gm-Message-State: AOAM533FbrMZER2/ZuFU7yYbmJ58RnKQr56aHq5UGUj9O+fHAwAFGfCd IZXVINgu8OULLDyChYapiHAqwCexTocVSFSf88Y= X-Google-Smtp-Source: ABdhPJxGT3H7n+ncYcc1ragYhedhMTrzyGZjUEwT8p14THehAv07g+flM/M7RALq0NmhhTsu9a6X6toBInpa8X3IqbQ= X-Received: by 2002:a17:907:868f:: with SMTP id qa15mr16743963ejc.477.1635097895804; Sun, 24 Oct 2021 10:51:35 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <26d9fc32-4884-602c-975a-79fc64551727@gmail.com> In-Reply-To: From: Greg Mirsky Date: Sun, 24 Oct 2021 10:51:15 -0700 Message-ID: To: "Darren Dukes (ddukes)" Cc: Gyan Mishra , Brian E Carpenter , "ipv6@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="00000000000040a1a905cf1ce5e5" Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 24 Oct 2021 17:51:44 -0000 --00000000000040a1a905cf1ce5e5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Daren, thank you for responding to my question. Is 64-bits routable prefix in the DA an implicit prerequisite of the C-SID solution? As to my question about what Brian referred to as a "funny" part. In Section 6 we read: The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A C-SID length of 16-bit is recommended. and then: The recommended SRv6 SID block sizes for the NEXT-C-SID flavor are 16, 32 or 48 bits. Now, it seems to me that there are many possibilities of getting the "funny" part of C-SID into a routable space of the DA. For example, an operator, following the recommendation of the C-SID specification, uses 16-bit NEXT-C-SID in combination with, for example, 32 bits block size. As a result, 16 bits of "funny" part, i.e., another NEXT-C-SID, are in the routable space. Am I missing something? Thank you for your consideration. Regards, Greg On Thu, Oct 21, 2021 at 10:06 PM Darren Dukes (ddukes) wrote: > Hi Gyan and Greg. > > Gyan I=E2=80=99m sorry but i don=E2=80=99t see a question in your email. = I=E2=80=99ll go back to > Greg. > > While I=E2=80=99m not exactly sure what is being asked, I will say that B= rian is > correct for every Srv6 SID behavior (not just csid flavors) when he says > the following about their arguments (lowest 64 bits in the ipv6 Dest addr= . > > =E2=80=9CThey are invisible to routing (which is done based on the prefix= ) and > invisible to neighbor discovery (because it never happens).=E2=80=9D > > I hope this helps. > > Darren > > ------------------------------ > *From:* Gyan Mishra > *Sent:* Thursday, October 21, 2021 7:03 PM > *To:* Darren Dukes (ddukes) > *Cc:* Brian E Carpenter; Greg Mirsky; ipv6@ietf.org; spring@ietf.org > *Subject:* Re: Typo correction Re: Question from SPRING regarding > draft-filsfilscheng-spring-srv6-srh-compression > > > > Hi Darren > > What Greg is asking is if the SID is a prefix SID End and not adjacency > SID End.x, so now the common prefix is needed to ECMP steer the flow to > the prefix SID which uses the common prefix, which may in this case be > mutated due to shifting of SIDs in GSID container. > > > Kind Regards > > Gyan > On Thu, Oct 21, 2021 at 10:18 AM Darren Dukes (ddukes) 40cisco.com@dmarc.ietf.org> wrote: > >> Hi Greg, >> >> >> >> Your question is not clear to me. >> >> Can you try to restate it with the flavors and behaviors from the draft >> in question? >> >> >> >> Darren >> >> >> >> On 2021-10-20, 4:15 PM, "ipv6" wrote: >> >> >> >> Hi Brian, >> >> I've got some questions about what you've said: >> >> For that reason, the fact that the bottom 64 bits in the >> >> "address" look funny or change is simply irrelevant. They are >> >> invisible to routing (which is done based on the prefix) >> >> and invisible to neighbor discovery (because it never happens). >> >> As I understand it, what you describe is the case of a strict explicit >> path defined using one of the C-SID compression methods. But I am not su= re >> that your conclusion also always applies when it is a loose explicit pat= h >> specified in the compressed Segment List. As all C-SIDs share the same >> prefix, how routing can be done based only on that prefix and not using = a >> part of that "funny" bottom 64 bits? And if any part of the bottom 64 bi= ts >> must be used, how one can guarantee that CIDR still works in that domain= ? >> >> >> >> Regards, >> >> Greg >> >> >> >> On Mon, Oct 18, 2021 at 9:50 PM Brian E Carpenter < >> brian.e.carpenter@gmail.com> wrote: >> >> Hi, >> >> After reading a lot of messages, I'm going to offer my considered >> opinion as a direct response to Joel's OP. >> >> Firstly, I don't believe that in the end this draft raises any >> concerns that are *significantly* different than those raised >> when RFC 8986 was in draft. As Ted Hardie mentioned, section 5 >> of RFC 8754 explains that SIDs of any shape or size are only >> meaningful within an SR domain. That applies to srh-compression >> too. >> >> Secondly, I was concerned about how these strange looking >> "addresses" would potentially interfere with normal IPv6 >> addresses and their handling by normal IPv6 nodes. Well, I >> now believe that they won't. The reason is that in the SR model >> these "addresses" are *never used for final delivery of IPv6 >> packets to a host.* All SRv6 participants are routers. The >> last hop for a packet whose DA is set to (say) 2001:db8:a:1900:: >> is *not* the last hop on a LAN, mediated by neighbor discovery >> for 2001:db8:a:1900::. It's just a hop from one router to another, >> using the entry for 2001:db8:a:1900::/64 in the FIB of the last >> router that actually forwards the packet. 2001:db8:a:1900:: is >> not assigned to a physical interface so RFC 4861 is never invoked. >> >> Another way to say it is RFC 7608 is the relevant architectural >> standard. CIDR rules, even within an SR domain. >> >> For that reason, the fact that the bottom 64 bits in the >> "address" look funny or change is simply irrelevant. They are >> invisible to routing (which is done based on the prefix) >> and invisible to neighbor discovery (because it never happens). >> >> I apologise if this is all obvious to everybody, but I needed >> to spell it out for my own understanding. >> >> Now back to Joel's questions: >> >> >> On 13-Oct-21 20:37, Joel M. Halpern wrote: >> > There is a typo in the below which if not understood as a typo would b= e >> >> > quite confusing. I wrote that I raised the issue with >> > "with the Internet ADs and SPRING chairs". >> > That should have read "with the Internet ADs and 6man chairs". >> > The SPRING co-chairs are recused, and the charter requirement leads to >> > the 6man chairs. Which is who I talked to. >> > >> > Also, I am sending a courtesy copy to the routing ADs, which I should >> > have done originally. >> > >> > Thank you and enjoy. >> > Yours, >> > Joel >> > >> > On 10/12/2021 11:52 PM, Joel M. Halpern wrote: >> >> The SPRING working group is in the midst of an adoption call on >> >> >> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-com= pression/. >> >> >> >> >> >> >> The SPRING charter has text that is explicit that modifications to >> data >> >> planes and architectures standardized by other working groups may not >> be >> >> modified in SPRING unless the chairs and ADs responsible for that dat= a >> >> >> plane and / or architecture agree. >> >> >> >> To complete the context, as my SPRING co-chairs are co-authors on the >> >> document in question, they have recused themselves from decisional >> >> activities regarding the document. Therefore, this message is coming >> >> just from my as the responsible SPRING co-chair managing this adoptio= n >> >> >> call. >> >> >> >> As you have seen, multiple questions have been raised about the >> >> relationship of the document to the IPv6 defined data plane and >> >> architecture (particularly RFC 4291 and 8200). In particular the >> >> questions seem to revolve around what the document describes as the >> >> NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6 >> >> standards. (For those seeking more context without reading the full >> >> document, a paraphrase and simplification of the NEXT-C_SID flavor is >> >> provided as a postscript.) >> >> >> >> I raised the question of concurrence as required by the SPRING charte= r >> >> >> with the Internet ADs and SPRING chairs. They quite reasonably asked >> me >> >> to write a note to 6man explaining the concerns as clearly as a can, >> so >> >> that they can then determine how to proceed. >> >> >> >> The questions that prompted my inquiry are: >> >> >> >> 1) Does the placement of a list of sids in the IPv6 DA field change >> the >> >> IPv6 architectural description of that field. >> >> I think it should be noted explicitly somewhere that since the contents >> of the DA field are *never* used for last-hop neighbor discovery, >> the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942 >> are irrelevant. Another citation is RFC 7608: for routing, all that >> counts is the prefix, and it can be anything up to 128. >> >> Perhaps this should have been in section 5 of RFC 8754, but I leave >> that to the wordsmiths. >> >> >> 2) Does the operation of shifting information around in the IPv6 >> >> destination address field represent a modification or extension of th= e >> >> >> IPv6 data plane. >> >> No. As my text above indicates, the SRv6 DA field is only ever used >> by routing, where RFC 7608 rules. And of course it vanishes as soon >> as the packet is decapsulated. >> >> Regards >> Brian >> >> >> >> >> On a related note, the document in question also defines two other >> >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The >> >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID >> >> flavor operation, so seems to be affected by the same question. >> >> >> >> From my own reading, it appears that the REPLACE-C-SID flavor does >> not >> >> raise issues requiring 6man leadership concurrence. >> >> >> >> Yours, >> >> Joel M. Halpern for the SPRING working group >> >> >> >> >> >> PS: >> >> Clearly, understanding the question requires some understanding of >> what >> >> the NEXT-C_SID flavor does. This explanation is a simplification fo= r >> >> length and context. Really, the best place to understand it is the >> >> draft. However, to give you enough information to let you decide >> >> >> whether you care, I will try to provide a fair summary. My apologies >> in >> >> advance to the authors for necessary liberties for length. Also, >> >> >> discussion of the draft contents (as distinct from the interaction >> with >> >> the IPv6 data plane and architecture) belongs on the SPRING list, and >> >> should not clutter up 6man. >> >> >> >> SIDs are the identifiers used in segment routing. >> >> In SRv6, as document in the current RFCs, these are 128 bits. As >> >> defined in the relevant RFCs, SIDs which identify endpoints to which >> >> packets are directed are identified by endpoint SIDs. These can have >> >> behaviors (decapsulate and forward is one example). They can have >> >> flavors such as where the SRH is removed. >> >> >> >> The topic under discussion is means to compress these SIDs in the >> >> packets on the wire. The document under discussion provides three >> >> flavors of compression. >> >> >> >> The fundamental mechanism of the draft is to use a single SRH entry a= s >> a >> >> container for multiple SIDs. In the NEXT-C_SID mechanism, when it is >> >> first encountered the entire container is copied into the desination >> >> address of the IPv6 packet. The container has a common routing prefi= x >> >> used for all the NEXT-C-SID SIDs. It is followed by a sequence of >> >> compressed SIDs of a configured length. One could configure 16, 24, >> or >> >> 32 bits. Or whatever length. The routing advertisements are arrange= d >> >> so that the IPv6 packet is directed to the node represented by the >> first >> >> compressed SID on the basis of longest prefix match matching the >> >> combination of the common routing prefix and that compressed SID. >> >> >> >> When the packet arrives at that node, it looks up the configured >> >> portion, the compressed SID, and determines the behavior and flavor. >> In >> >> the case of the NEXT-C-SID flavor, the resulting operation is to shif= t >> >> >> the entire remaining contents of the IPv6 address (the bits past the >> >> first compressed sid) so as to over-write the first compressed SID. = 0 >> >> bits are shifted into the low order positions. If the result is a >> >> non-zero new first compressed SID, then the packets is forwarded and >> the >> >> process repeats. When all that is left are 0s, if there is an SRH, i= t >> >> is consulted to find the next SRH entry, which is, per normal SRv6 >> >> processing, put into the IPv6 DA. >> >> Note that in the common case where the SIDS needed all fit in to a >> >> single container, the analysis also assumes the use of the reduced >> >> encapsulation options which omits the SRH that is not needed as it >> would >> >> have no entries. This the packet contains a normal IPv6 header, with >> a >> >> sequence of compressed SIDs (what one might or might not call a sourc= e >> >> >> route) in the IPv6 destination address field. >> >> >> >> PPS: If the authors of the NEXT-C-SID flavor feel I have >> mis-represented >> >> the work, please, send clarifications or corrections. Again, the >> best >> >> source of information is the draft itself. I was asked to provide >> extra >> >> context in this email. >> > >> > -------------------------------------------------------------------- >> > IETF IPv6 working group mailing list >> > ipv6@ietf.org >> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> > -------------------------------------------------------------------- >> > >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > -- > > > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mishra@verizon.com * > > > > *M 301 502-1347 * > > --00000000000040a1a905cf1ce5e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Daren,
    thank you = for responding to my question. Is 64-bits routable prefix in the DA an impl= icit=C2=A0prerequisite of the C-SID solution?=C2=A0

    As to my question about what Brian referred to as=C2=A0a "funny"= ; part. In Section 6 we read:
    =C2=A0 =C2=A0The NEXT-C-SID fl= avor supports both 16- and 32-bit C-SID lengths.=C2=A0 A
    =C2=A0 = =C2=A0C-SID length of 16-bit is recommended.
    and then:
    =C2=A0 =C2=A0The recommended SRv6 SID block sizes for the NEXT-C= -SID flavor are
    =C2=A0 =C2=A016, 32 or 48 bits.
    <= br>
    Now, it seems to me that there are many possibilities of gett= ing the "funny" part of C-SID into a routable space of the DA. Fo= r example, an operator, following the recommendation of the C-SID specifica= tion, uses 16-bit NEXT-C-SID in combination with, for example, 32 bits bloc= k size. As a result, 16 bits of "funny" part, i.e., another NEXT-= C-SID, are in the routable space.
    Am I missing something? Thank y= ou for your consideration.

    Regards,
    Greg=

    On Thu, Oct 21, 2021 at 10:06 PM Darren Dukes (ddukes) &l= t;ddukes@cisco.com> wrote:
    Hi Gyan and Greg.=C2=A0

    Gyan I=E2=80=99m sorry but i don=E2=80=99t see a question = in your email. I=E2=80=99ll go back to=C2=A0Greg.=C2=A0

    While I=E2=80=99m not ex= actly sure what is being asked, I will say that Brian is correct for every = Srv6 SID behavior (not just csid flavors) when he says the following about = their arguments (lowest 64 bits in the ipv6 Dest addr.

    =E2=80=9CThey are=C2=A0invisible to routing (which is done based on the prefix)=C2=A0= and invisible to neighbor discovery (because it never happens).=E2=80=9D

    I hope this helps.=C2=A0

    Darren

    From: Gyan Mishra <hayabusagsm@gmail.com>
    Sent: Thursday, October 21, 2021 7:03 PM
    To: Darren Dukes (ddukes)
    Cc: Brian E Carpenter; Greg Mirsky; ipv6@ietf.org; spring@ietf.org
    Subject: Re: Typo correction Re: Question from SPRING regarding draf= t-filsfilscheng-spring-srv6-srh-compression
    =C2=A0


    Hi Darren=C2=A0

    What Greg is asking is if the SID is a prefix SID End and= not adjacency SID End.x, so now the common prefix is needed to ECMP steer = the flow =C2=A0to the prefix SID which uses the common prefix, =C2=A0which = may in this case be mutated due to shifting of SIDs in GSID container.


    Kind Regards=C2=A0

    Gyan=C2=A0
    On Thu, Oct 21, 2021 at 10:18 AM Darr= en Dukes (ddukes) <ddukes=3D40cisco.com@dmarc.ietf.org> wrote:

    Hi Greg, <= /p>

    =C2=A0

    Your question is not clear to m= e.

    Can you try to restate it with = the flavors and behaviors from the draft in question?

    =C2=A0

    Darren

    =C2=A0

    On 2021-10-20, 4:15 PM, &= quot;ipv6" <ipv6-bounces@ietf.org> wrote:

    =C2=A0

    Hi Brian,

    I've got some questio= ns about what you've said:

    For that reason, the fact= that the bottom 64 bits in the

    "address" look = funny or change is simply irrelevant. They are

    invisible to routing (whi= ch is done based on the prefix)

    and invisible to neighbor= discovery (because it never happens).

    As I understand it, what = you describe is the case of a strict explicit path defined using one of the= C-SID compression methods. But I am not sure that your conclusion also alw= ays applies when it is a loose explicit path specified in the compressed Segment List. As all C-SIDs share the sam= e prefix, how routing can be done based only on that prefix and not using a= part of that "funny" bottom 64 bits? And if any part of the bott= om 64 bits must be used, how one=C2=A0can guarantee that CIDR still works in that domain?

    =C2=A0

    Regards,

    Greg

    =C2=A0

    On Mon, Oct 18, 2021 at 9= :50 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:=

    Hi,

    After reading a lot of messages, I'm going to offer my considered
    opinion as a direct response to Joel's OP.

    Firstly, I don't believe that in the end this draft raises any
    concerns that are *significantly* different than those raised
    when RFC 8986 was in draft. As Ted Hardie mentioned, section 5
    of RFC 8754 explains that SIDs of any shape or size are only
    meaningful within an SR domain. That applies to srh-compression
    too.

    Secondly, I was concerned about how these strange looking
    "addresses" would potentially interfere with normal IPv6
    addresses and their handling by normal IPv6 nodes. Well, I
    now believe that they won't. The reason is that in the SR model
    these "addresses" are *never used for final delivery of IPv6
    packets to a host.* All SRv6 participants are routers. The
    last hop for a packet whose DA is set to (say) 2001:db8:a:1900::
    is *not* the last hop on a LAN, mediated by neighbor discovery
    for 2001:db8:a:1900::. It's just a hop from one router to another,
    using the entry for 2001:db8:a:1900::/64 in the FIB of the last
    router that actually forwards the packet. 2001:db8:a:1900:: is
    not assigned to a physical interface so RFC 4861 is never invoked.

    Another way to say it is RFC 7608 is the relevant architectural
    standard. CIDR rules, even within an SR domain.

    For that reason, the fact that the bottom 64 bits in the
    "address" look funny or change is simply irrelevant. They are
    invisible to routing (which is done based on the prefix)
    and invisible to neighbor discovery (because it never happens).

    I apologise if this is all obvious to everybody, but I needed
    to spell it out for my own understanding.

    Now back to Joel's questions:


    On 13-Oct-21 20:37, Joel M. Halpern wrote:
    > There is a typo in the below which if not understood as a typo would b= e

    > quite confusing.=C2=A0 =C2=A0I wrote that I raised the issue with
    > "with the Internet ADs and SPRING chairs".
    > That should have read "with the Internet ADs and 6man chairs"= ;.
    > The SPRING co-chairs are recused, and the charter requirement leads to=
    > the 6man chairs.=C2=A0 Which is who I talked to.
    >
    > Also, I am sending a courtesy copy to the routing ADs, which I should =
    > have done originally.
    >
    > Thank you and enjoy.
    > Yours,
    > Joel
    >
    > On 10/12/2021 11:52 PM, Joel M. Halpern wrote:
    >> The SPRING working group is in the midst of an adoption call on >> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/.
    >>
    >>
    >> The SPRING charter has text that is explicit that modifications to= data
    >> planes and architectures standardized by other working groups may = not be
    >> modified in SPRING unless the chairs and ADs responsible for that = data

    >> plane and / or architecture agree.
    >>
    >> To complete the context, as my SPRING co-chairs are co-authors on = the
    >> document in question, they have recused themselves from decisional=
    >> activities regarding the document.=C2=A0 Therefore, this message i= s coming
    >> just from my as the responsible SPRING co-chair managing this adop= tion

    >> call.
    >>
    >> As you have seen, multiple questions have been raised about the >> relationship of the document to the IPv6 defined data plane and >> architecture (particularly RFC 4291 and 8200). In particular the <= br> >> questions seem to revolve around what the document describes as th= e
    >> NEXT-C-SID flavor of compressed SID, and its relationship to the I= Pv6
    >> standards.=C2=A0 (For those seeking more context without reading t= he full
    >> document, a paraphrase and simplification of the NEXT-C_SID flavor= is
    >> provided as a postscript.)
    >>
    >> I raised the question of concurrence as required by the SPRING cha= rter

    >> with the Internet ADs and SPRING chairs.=C2=A0 They quite reasonab= ly asked me
    >> to write a note to 6man explaining the concerns as clearly as a ca= n, so
    >> that they can then determine how to proceed.
    >>
    >> The questions that prompted my inquiry are:
    >>
    >> 1) Does the placement of a list of sids in the IPv6 DA field chang= e the
    >> IPv6 architectural description of that field.

    I think it should be noted explicitly somewhere that since the contents
    of the DA field are *never* used for last-hop neighbor discovery,
    the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942
    are irrelevant. Another citation is RFC 7608: for routing, all that
    counts is the prefix, and it can be anything up to 128.

    Perhaps this should have been in section 5 of RFC 8754, but I leave
    that to the wordsmiths.

    >> 2) Does the operation of shifting information around in the IPv6 <= br> >> destination address field represent a modification or extension of= the

    >> IPv6 data plane.

    No. As my text above indicates, the SRv6 DA field is only ever used
    by routing, where RFC 7608 rules. And of course it vanishes as soon
    as the packet is decapsulated.

    Regards
    =C2=A0 =C2=A0 Brian

    >>
    >> On a related note, the document in question also defines two other=
    >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.=C2=A0 The
    >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID=
    >> flavor operation, so seems to be affected by the same question. >>
    >>=C2=A0 From my own reading, it appears that the REPLACE-C-SID flavo= r does not
    >> raise issues requiring 6man leadership concurrence.
    >>
    >> Yours,
    >> Joel M. Halpern for the SPRING working group
    >>
    >>
    >> PS:
    >> Clearly, understanding the question requires some understanding of= what
    >> the NEXT-C_SID flavor does.=C2=A0=C2=A0 This explanation is a simp= lification for
    >> length and context.=C2=A0 Really, the best place to understand it = is the
    >> draft.=C2=A0 However, to give you enough information to let you de= cide

    >> whether you care, I will try to provide a fair summary.=C2=A0 My a= pologies in
    >> advance to the authors for necessary liberties for length.=C2=A0 A= lso,

    >> discussion of the draft contents (as distinct from the interaction= with
    >> the IPv6 data plane and architecture) belongs on the SPRING list, = and
    >> should not clutter up 6man.
    >>
    >> SIDs are the identifiers used in segment routing.
    >> In SRv6, as document in the current RFCs, these are 128 bits.=C2= =A0=C2=A0 As
    >> defined in the relevant RFCs, SIDs which identify endpoints to whi= ch
    >> packets are directed are identified by endpoint SIDs.=C2=A0 These = can have
    >> behaviors (decapsulate and forward is one example).=C2=A0 They can= have
    >> flavors such as where the SRH is removed.
    >>
    >> The topic under discussion is means to compress these SIDs in the =
    >> packets on the wire.=C2=A0 The document under discussion provides = three
    >> flavors of compression.
    >>
    >> The fundamental mechanism of the draft is to use a single SRH entr= y as
    a
    >> container for multiple SIDs.=C2=A0 In the NEXT-C_SID mechanism, wh= en it is
    >> first encountered the entire container is copied into the desinati= on
    >> address of the IPv6 packet.=C2=A0 The container has a common routi= ng prefix
    >> used for all the NEXT-C-SID SIDs.=C2=A0 It is followed by a sequen= ce of
    >> compressed SIDs of a configured length.=C2=A0 One could configure = 16, 24, or
    >> 32 bits.=C2=A0 Or whatever length.=C2=A0 The routing advertisement= s are arranged
    >> so that the IPv6 packet is directed to the node represented by the= first
    >> compressed SID on the basis of longest prefix match matching the <= br> >> combination of the common routing prefix and that compressed SID.<= br> >>
    >> When the packet arrives at that node, it looks up the configured <= br> >> portion, the compressed SID, and determines the behavior and flavo= r.=C2=A0 In
    >> the case of the NEXT-C-SID flavor, the resulting operation is to s= hift

    >> the entire remaining contents of the IPv6 address (the bits past t= he
    >> first compressed sid) so as to over-write the first compressed SID= .=C2=A0 0
    >> bits are shifted into the low order positions.=C2=A0 If the result= is a
    >> non-zero new first compressed SID, then the packets is forwarded a= nd the
    >> process repeats.=C2=A0 When all that is left are 0s, if there is a= n SRH, it
    >> is consulted to find the next SRH entry, which is, per normal SRv6=
    >> processing, put into the IPv6 DA.
    >> Note that in the common case where the SIDS needed all fit in to a=
    >> single container, the analysis also assumes the use of the reduced=
    >> encapsulation options which omits the SRH that is not needed as it= would
    >> have no entries.=C2=A0 This the packet contains a normal IPv6 head= er, with a
    >> sequence of compressed SIDs (what one might or might not call a so= urce

    >> route) in the IPv6 destination address field.
    >>
    >> PPS: If the authors of the NEXT-C-SID flavor feel I have mis-repre= sented
    >> the work, please, send clarifications or corrections.=C2=A0=C2=A0 = Again, the best
    >> source of information is the draft itself.=C2=A0 I was asked to pr= ovide extra
    >> context in this email.
    >
    > -------------------------------------------------------------------- > IETF IPv6 working group mailing list
    > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > -------------------------------------------------------------------- >

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------=

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    --

    Gyan Mishra

    Network Solutions A<= /i>rchitect=C2=A0=

    Email gyan.s.mishr= a@verizon.com

    M 301 502-1347


    --00000000000040a1a905cf1ce5e5-- From nobody Sun Oct 24 11:02:06 2021 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 D98653A0863; Sun, 24 Oct 2021 11:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=steffann.nl 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 DegoALtA-LUm; Sun, 24 Oct 2021 11:01:56 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2a00:8642:1000:1::22]) (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 A54953A08AE; Sun, 24 Oct 2021 11:01:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id C20B051; Sun, 24 Oct 2021 20:01:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=steffann.nl; h= x-mailer:in-reply-to:references:message-id:date:date:subject :subject:mime-version:from:from:content-transfer-encoding :content-type:content-type:received:received; s=mail; t= 1635098507; bh=OL31/qcEztQdxUB6OW90vKugi1m5hznnUUE8TxXKyfg=; b=p lTvStUri3lePMTHBgpgEGjYg96nuoT92pqmOh1Am/GjhoiZurqHwZ8YNPHXZiIpu 2atdHg8mOsNT5VWSGu1KiuyOl+yf2GPUH4ruBPlNJCQY+ufOziOCMdfDZE9cVq5/ jg2bTV29dHCuEyVswKZE5+ZAefTO3ClAl/wvDIqqYc= X-Virus-Scanned: Debian amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id RLajsBg_4GGT; Sun, 24 Oct 2021 20:01:47 +0200 (CEST) Received: from smtpclient.apple (unknown [IPv6:2001:9e0:8804:7701:a04d:c471:87c0:bd79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.sintact.nl (Postfix) with ESMTPSA id 0145C4A; Sun, 24 Oct 2021 20:01:46 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Clacks-Overhead: GNU Terry Pratchett From: Sander Steffann Mime-Version: 1.0 (1.0) Date: Sun, 24 Oct 2021 20:01:46 +0200 Message-Id: References: <89c62864-feb4-550e-2d63-264b2ecc3344@lear.ch> Cc: Nick Hilliard , SPRING WG List , 6man WG In-Reply-To: <89c62864-feb4-550e-2d63-264b2ecc3344@lear.ch> To: Eliot Lear X-Mailer: iPhone Mail (19A348) Archived-At: Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 24 Oct 2021 18:02:01 -0000 =EF=BB=BF >> On 24.10.21 17:36, Nick Hilliard wrote: >> The issue is a good deal deeper than just debugging. As long as there's a= n option to specify a variable length parameter without being able to specif= y the length in the protocol, then the protocol is fundamentally ambiguous a= nd its interpretation is entirely context dependent. >=20 > You mean, like a subnet mask? No, you can parse the addresses in a packet perfectly without knowing the su= bnet mask. More like variable length addresses without encoding what the len= gth actually is=E2=80=A6 Cheers, Sander= From nobody Sun Oct 24 13:00:06 2021 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 A8CA63A08B0; Sun, 24 Oct 2021 13:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.23 X-Spam-Level: X-Spam-Status: No, score=-5.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-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 p9tg1DjnzCEd; Sun, 24 Oct 2021 13:00:01 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 755CE3A0889; Sun, 24 Oct 2021 13:00:00 -0700 (PDT) X-Envelope-To: spring@ietf.org Received: from crumpet.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 19OJxuDg027737 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 24 Oct 2021 20:59:57 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be crumpet.local To: Eliot Lear Cc: Sander Steffann , SPRING WG List , 6man WG References: <89c62864-feb4-550e-2d63-264b2ecc3344@lear.ch> From: Nick Hilliard Message-ID: <8bf003b2-988d-6d6c-f080-519596a3b1ac@foobar.org> Date: Sun, 24 Oct 2021 20:59:52 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.49 MIME-Version: 1.0 In-Reply-To: <89c62864-feb4-550e-2d63-264b2ecc3344@lear.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 24 Oct 2021 20:00:05 -0000 Eliot Lear wrote on 24/10/2021 18:17: > On 24.10.21 17:36, Nick Hilliard wrote: >> The issue is a good deal deeper than just debugging.  As long as >> there's an option to specify a variable length parameter without being >> able to specify the length in the protocol, then the protocol is >> fundamentally ambiguous and its interpretation is entirely context >> dependent. > > You mean, like a subnet mask? There's no direct analog here. Subnet masks have both local and global significance, which is why we use a combination of EGPs and IGPs. The critical thing is that all these routing protocols encode subnet masks and the protocol signaling ensures that there's no ambiguity. This doesn't appear to be the case in the SRH compression draft. As you mention it, I'd love to see the head-scratching that would ensue if someone proposed a new routing protocol which didn't encode the subnet mask :-) Nick From nobody Sun Oct 24 13:23:44 2021 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 BF7E73A0062; Sun, 24 Oct 2021 13:23:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.42 X-Spam-Level: X-Spam-Status: No, score=-5.42 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, NICE_REPLY_A=-3.33, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch 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 Qgp_cg8wa1dk; Sun, 24 Oct 2021 13:23:38 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 37CB13A0061; Sun, 24 Oct 2021 13:23:36 -0700 (PDT) Received: from [IPV6:2a02:aa15:4101:2a80:e9f5:803c:df6f:3961] ([IPv6:2a02:aa15:4101:2a80:e9f5:803c:df6f:3961]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 19OKNK2n3507084 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 24 Oct 2021 22:23:21 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1635107001; bh=jsQ6B5VuEEcqyHypdNWfxrQ0huSfoOFsQhvYwG0wRxc=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=XJArrMS5HtooVVVFA5i0BtTRRXzckFuYm2oFHkfXcCRt44JecTzSIc2qQXMBte3Gt +BCkH38KFZ6VHLV3dq73jlT9N7QJE91vZBUvG4CqQ8g8mc5P6nU03NgEdC+qTGyFgL 6CydjeSHIaagTs0BmpZ3fEtLkhw0tsaK4fGwJjcE= Message-ID: Date: Sun, 24 Oct 2021 22:23:19 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Content-Language: en-US To: Nick Hilliard Cc: 6man WG , SPRING WG List References: <89c62864-feb4-550e-2d63-264b2ecc3344@lear.ch> <8bf003b2-988d-6d6c-f080-519596a3b1ac@foobar.org> From: Eliot Lear In-Reply-To: <8bf003b2-988d-6d6c-f080-519596a3b1ac@foobar.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------vEF4Hv5MPHv068dxOvbLMd0l" Archived-At: Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 24 Oct 2021 20:23:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------vEF4Hv5MPHv068dxOvbLMd0l Content-Type: multipart/mixed; boundary="------------3V0x0kV24uS3jTIg0AhUBP1x"; protected-headers="v1" From: Eliot Lear To: Nick Hilliard Cc: 6man WG , SPRING WG List Message-ID: Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) References: <89c62864-feb4-550e-2d63-264b2ecc3344@lear.ch> <8bf003b2-988d-6d6c-f080-519596a3b1ac@foobar.org> In-Reply-To: <8bf003b2-988d-6d6c-f080-519596a3b1ac@foobar.org> --------------3V0x0kV24uS3jTIg0AhUBP1x Content-Type: multipart/mixed; boundary="------------hLD0ReYE300l0YmcBO52ExeD" --------------hLD0ReYE300l0YmcBO52ExeD Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQpPbiAyNC4xMC4yMSAyMTo1OSwgTmljayBIaWxsaWFyZCB3cm90ZToNCj4gRWxpb3QgTGVh ciB3cm90ZSBvbiAyNC8xMC8yMDIxIDE4OjE3Og0KPj4gT24gMjQuMTAuMjEgMTc6MzYsIE5p Y2sgSGlsbGlhcmQgd3JvdGU6DQo+Pj4gVGhlIGlzc3VlIGlzIGEgZ29vZCBkZWFsIGRlZXBl ciB0aGFuIGp1c3QgZGVidWdnaW5nLsKgIEFzIGxvbmcgYXMgDQo+Pj4gdGhlcmUncyBhbiBv cHRpb24gdG8gc3BlY2lmeSBhIHZhcmlhYmxlIGxlbmd0aCBwYXJhbWV0ZXIgd2l0aG91dCAN Cj4+PiBiZWluZyBhYmxlIHRvIHNwZWNpZnkgdGhlIGxlbmd0aCBpbiB0aGUgcHJvdG9jb2ws IHRoZW4gdGhlIHByb3RvY29sIA0KPj4+IGlzIGZ1bmRhbWVudGFsbHkgYW1iaWd1b3VzIGFu ZCBpdHMgaW50ZXJwcmV0YXRpb24gaXMgZW50aXJlbHkgDQo+Pj4gY29udGV4dCBkZXBlbmRl bnQuDQo+Pg0KPj4gWW91IG1lYW4sIGxpa2UgYSBzdWJuZXQgbWFzaz8NCj4NCj4gVGhlcmUn cyBubyBkaXJlY3QgYW5hbG9nIGhlcmUuDQoNCk9mIGNvdXJzZSB0aGVyZSBpcy7CoCBZb3Ug Y2Fubm90IGRpc3Rpbmd1aXNoIHJvdXRpbmcgZnJvbSBob3N0IHdpdGhvdXQgDQpsb29raW5n IGF0IGV4dGVybmFsIGNvbnRyb2wgY2hhbm5lbHMsIHN1Y2ggYXMgYSByb3V0aW5nIG9yIGNv bmZpZ3VyYXRpb24gDQpwcm90b2NvbDsgYW5kIHlvdSBjZXJ0YWlubHkgY2Fubm90IGRldGVy bWluZSB0aGUgc3VibmV0IG1hc2sgb2YgYSANCm5ldHdvcmsgd2l0aG91dCB0aGF0IGV4dGVy bmFsIGluZm9ybWF0aW9uLCBzaW5jZSBpdCdzIG5vdCBpbiB0aGUgDQpwYWNrZXQuwqAgQW5k IGl0J3Mgbm90IGV2ZW4gaW4gdGhlIGNvbnRyb2wgcGxhbmUgaWYgdGhlIHJvdXRlIGhhcyBi ZWVuIA0KYWdncmVnYXRlZC7CoCBEb2VzIHRoYXQgbWFrZSB0aGUgaW5mb3JtYXRpb24gImFt YmlndW91cyI/wqAgVGhlIHBvaW50IGlzIA0KdGhhdCB0aGUgc3VibmV0IG1hc2sgb2YgYSBu ZXR3b3JrIGlzIHBhcnQgb2YgYSBjb250ZXh0IHRoYXQgeW91IA0KZGlzY3Vzc2VkLCBhbmQg eW91IG1pZ2h0IG5vdCBoYXZlIGl0Lg0KDQpOb3RlLSBJIGFtIG5vdCB0YWtpbmcgYSBwb3Np dGlvbiBhYm91dCBDU0lEcywgYnV0IEkgdGhpbmsgdGhpcyBsaW5lIG9mIA0KYXJndW1lbnQg aXMgb24gdGhlIHdyb25nIHRyYWNrLg0KDQpFbGlvdA0KDQoNCg0K --------------hLD0ReYE300l0YmcBO52ExeD Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clTl= pVL ciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ9NcML= lD8 raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv5= 4oH 0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gC= tCj fvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlY= XIg PGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY0L2QR= h2w kqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCHtmtG2dJ6MyMyCACXv= tFj AYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA1U/OlZux+P/NaVMiZNZc8zw0nsx/I= NAq DOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyM= Jz+ GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0= MyS k1D5A7FdwDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM= +E5 C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMabGguI183qWgCcD= Bjq DmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxqYVx7wkYEEhECAAYFAlMfD7kAC= gkQ bSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A42U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3w= sBi BBMBCgAMBQJTIsh+BYMHhh+AAAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6Mqf= XAa hQt8ES3b9hXNKDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS= 5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc9XvabUOhC= Bb5 z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvSsIH63pw7GN5jhtURktWpm= /vX qNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucjhC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4= TTr Om5YWFbCRgQTEQIABgUCVxX/yAAKCRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMW= QCg iVjlI3bzSuDrqtOOWMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTA= QIA OAIbAwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoLAgQWA= gMB AAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVTt/GJX1CabzWSsAPO8= VAy 39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1MuU6AQBqepeAgieyaN5CMk5fyQj6T= mHe UhOWi8F6dk5cz2HbU4tPxQaMu8fi/1njRlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSy= UFh Z6Ic018VoddI0RZYNDBmfvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX42= 4Yi 9jgbZYdEEo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUCU= x8P rgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1zmVoE9701OnCD= bAf UOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJFO1KoP297EClcJRuMb2XIQCdG= q6D 9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUCUx7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSl= BST A9OAMkal7Qt4YgCdEzmwSiZOIahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AAC= gkQ xA2RF02ZCBD74ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlh= Oqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/FapcnAPZwKna= bXo zei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ/R3AMQJYmEvCFdUw8Pntm= 65U +cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoIrkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0S= c5i mFHHmb/U6j/QEvkrjCwAWYAeavOjU+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MA= AoJ EG6AD2cTbjy4Y0oAoJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUd= sLB cwQQAQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP/iaM1= GyO gKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxwjgV4MGLTRCfkKoBh5= vsF jCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0LtkkJ/rjvAnMYNNs/q6H4deNNg+yNs4X= eWX PxfGEZQxPdX58eGfY2P9OJPbxNqwX1pFkF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvY= vnt SiAC7T5Ucfe363Zp4/F1BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJH= kcN j3nKfqORMUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOtm= ZCs rf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWamTY+Wx8lOcx8X= WQQ 0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5ya0h9aTtz9cMnfCLHfVL2ZimkS= jsP o0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhdPCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gU= GUH AUhrFFdvM8gf9U/SbdS+BYzL+IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFb= Glv dCBMZWFyIDxsZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh= 7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRayV/uDnJJd= nx0 d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvRecu4R+GArK696HWes6Gr5= 8eV 9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaXXuf8r798Hl1ROJhuHRAA+U/IikuB8/93y= hiU NeaO/Sb/dh4Au0aQrdFmokNG+mnD9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFup= Jsd f/O7UBDayvtzZ+AiUhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5= /CA gDpW7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2Ekady= JJJ F3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgAtFle2HW7/ecWBj4bY= U3Q oQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQNQR+z4CxqBzojzOuTcrEaWfekUVV9= 0zX y5oRjBa+YTzhjXavsXBh1brZsD1fVO2ynlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxw= eoF bTHJF+W7iPadSt321YV3bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdW= LiC UjlgGUPSfaFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7K= 2ox YUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ0nozkrkIANu6d= q2A eyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlMH1JPDr4A3ARKyv25QwDF0M0oN= 7Ke OdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58MhACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCL= zIr o8snIzwLu8cSqZQbNfyBMJg6ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZ= oTD xTpg4SUph+eRywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7= dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------hLD0ReYE300l0YmcBO52ExeD-- --------------3V0x0kV24uS3jTIg0AhUBP1x-- --------------vEF4Hv5MPHv068dxOvbLMd0l Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmF1wLcFAwAAAAAACgkQh7ZrRtnSejP/ +wf/eUkPU0vl/5QYMcyes6q2QVlLo+0tDNv7M2fLgNJviub7D8Ig4MewDcflbY3IKDRQLefC8QZE FqzmD+RPn1or886yYn6FJSuJuBBbGF91h9qK53FewWwqVHFREaOe6cDm2cWyvrmnBpWP4fM9k27c MTP/+mm9ZL0Re2XvF85M5jH+xAhwA/KsGnL1rcUWVK05LTvOczlEYdL63y4LTf/bB1Hx3OzTSsDu fFlVshzUVydzvUm6ITOhSZ0lCNYabsHYPq/aQNxsg3v0V8CbqC78JN1fQbWGw6ri/lfWhCSbD2QV b7jDAB8SkipLpQn9QFXi0uao2jgmDY9u8arqaC29ag== =4aH2 -----END PGP SIGNATURE----- --------------vEF4Hv5MPHv068dxOvbLMd0l-- From nobody Sun Oct 24 14:20:35 2021 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 EF13B3A0C86; Sun, 24 Oct 2021 14:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.428 X-Spam-Level: X-Spam-Status: No, score=-5.428 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, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCVMUNoF5kql; Sun, 24 Oct 2021 14:20:24 -0700 (PDT) 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 24D523A0C60; Sun, 24 Oct 2021 14:20:24 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id oa12-20020a17090b1bcc00b0019f715462a8so6887031pjb.3; Sun, 24 Oct 2021 14:20:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=jdFHvXEz4ibTTItnDBQqE1M1006HZll2COuc7ZOQoxI=; b=PhkKV+Pum1klMOfJd6Z9dBdSzm8jVUJqtZw5VF6SUj0kIN3jxIVx6ufqC8lCUTkH63 fnR9MLj9GPt4Tqi5VQrO+tcv9Ws/Y08KyBp3EfadDs58zlF57pYHcmk1NpCioQgKtqbw JXw0YU7IA1wXy9GKC5Dq7QFj3OugfUWFnElxCwbSPpkU4SbH/R2LWVtYfuUYUF+M1C6Z Uwb16rbfLVz0UyV2WF8Nh6w+sgu//leXsZPNGTLhQ+qMAfQdu1qFtusgbyPY0EHdEHjR EcBdkrYmvDVJoG7EIOKlhbrAVsBnaZpSp+GTfbT6fNKRG8k3Hm2N0xbHm2llYiIvPEok RPug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jdFHvXEz4ibTTItnDBQqE1M1006HZll2COuc7ZOQoxI=; b=WY1EFAwunka2HG3gXQNZZ150vi6ezoWxSxaTdBmSRRmoxCgTuq9g83CED7BMDegUxP fT8o6pOzZt0PBqovJoyw/Y1RF/HTDaDloEMDvCmpz9Dwz9bLc/P9DVz9LSiBPc/X108e 8auQjC0ikNmF12W5ppuyqbpgAD0A9NkwyM/8fEFLcI6AN1Mi/xx2Ur2rnU8O49BBA1OJ v2t5V8FRV0iu6vEdrpvHeO/HgjjwhE+sTn36c0RSNt0dOtUsydjZ6wQaOXDdwnAn2WU+ VY0k+RTjwYvUPvzpqZq4WzBK3g2Fo2sGR1MaJhLT4PYlae9SrVeBuGry02fNlBMh3NJ+ J2mw== X-Gm-Message-State: AOAM5312FjQonnAdbhJhUfxRvM92GCVPsON3BB/jghJVHu01Hu/JU5Pw DyXa1aVT0UnrJbO2B+OjybHvU8tfTZBT/g== X-Google-Smtp-Source: ABdhPJxvTBSZ6fouclHZ+khj+m0dQac/I6DQHyqgIn9NHxIkiS0nC60QXPKIg98YMA/49HqMCG0ksQ== X-Received: by 2002:a17:90a:4598:: with SMTP id v24mr15759141pjg.5.1635110422838; Sun, 24 Oct 2021 14:20:22 -0700 (PDT) Received: from ?IPv6:2406:e003:102d:e801:db7:d041:a2d:ce65? ([2406:e003:102d:e801:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id h4sm14677017pgn.6.2021.10.24.14.20.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 24 Oct 2021 14:20:22 -0700 (PDT) To: Eliot Lear , Nick Hilliard Cc: SPRING WG List , 6man WG References: <89c62864-feb4-550e-2d63-264b2ecc3344@lear.ch> <8bf003b2-988d-6d6c-f080-519596a3b1ac@foobar.org> From: Brian E Carpenter Message-ID: <5d39e7ae-531d-a821-847e-67b2c0471b24@gmail.com> Date: Mon, 25 Oct 2021 10:20:17 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 24 Oct 2021 21:20:30 -0000 On 25-Oct-21 09:23, Eliot Lear wrote: >=20 > On 24.10.21 21:59, Nick Hilliard wrote: >> Eliot Lear wrote on 24/10/2021 18:17: >>> On 24.10.21 17:36, Nick Hilliard wrote: >>>> The issue is a good deal deeper than just debugging.=C2=A0 As long a= s >>>> there's an option to specify a variable length parameter without >>>> being able to specify the length in the protocol, then the protocol >>>> is fundamentally ambiguous and its interpretation is entirely >>>> context dependent. >>> >>> You mean, like a subnet mask? >> >> There's no direct analog here. >=20 > Of course there is.=C2=A0 You cannot distinguish routing from host with= out > looking at external control channels, such as a routing or configuratio= n > protocol; and you certainly cannot determine the subnet mask of a > network without that external information, since it's not in the > packet.=C2=A0 And it's not even in the control plane if the route has b= een > aggregated.=C2=A0 Does that make the information "ambiguous"?=C2=A0 The=20 point is > that the subnet mask of a network is part of a context that you > discussed, and you might not have it. >=20 > Note- I am not taking a position about CSIDs, but I think this line of > argument is on the wrong track. My assumption has been that within the SRv6 domain, some routing protocol= will be in use (e.g. OSPF) and that (by some magic that I don't understan= d) it will be announcing the subnets currently in use, so that bog-standard routing will occur, including the final hop, because "hosts" supporting SRv6 will have to function as routers for the final hop. After all, SRv6 is an overlay, a form of VRF. Quite what the magic is that configures OSPF accordingly, I do not know. Regards Brian Thinking of the IETF standards process: https://xkcd.com/2530/ From nobody Sun Oct 24 14:48:38 2021 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 C6F4E3A0982; Sun, 24 Oct 2021 14:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.597 X-Spam-Level: X-Spam-Status: No, score=-0.597 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 q37T6zr6CYBJ; Sun, 24 Oct 2021 14:48:27 -0700 (PDT) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (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 DD1853A0983; Sun, 24 Oct 2021 14:48:27 -0700 (PDT) Received: by mail-il1-x12b.google.com with SMTP id l7so10727405iln.8; Sun, 24 Oct 2021 14:48:27 -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=DQmfYXCcrxX3adO8Xy3IghUYMsXa4+XkbSGKRygLIpY=; b=HE36iZFE8iS05JbAMzBxb3jyBGdNyETrj4/wph6s9HhjWgBzvWxPo+kcJbOlJXUcmK RseTv5mtpY37BnuOud/cyg/vWou6hKLobu73SMW2a8RCOsPyw271MMlZsYnMODYCU9gd l6phKe1zlh3NyltiXXZMVql4v08yC7/k9d01d96bzxnilC0NyDfBrhBgSFN/Gzhn7ADf D7Tr2oR7fdwAYKBjK9NQNZ0KZPhhWeoFj46mpROGmwD/2sLjHWdXoYrtXN33MR8zc8VZ TLBpq+0MRDJP81wAQi8xBCbvdAxAtEPBQD+Yha0aldd1ksf/A+3ddppBJJ3a7xYcdYTu jcKQ== 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=DQmfYXCcrxX3adO8Xy3IghUYMsXa4+XkbSGKRygLIpY=; b=YaVmS+aOqwSXy6LV1nzJCFd37H/LArMWnr+inrwrH7r7Jgqs+VVTkMvwOUgHp5E7R1 KR2RrsIZOqarumFOjOCL+JkB9k5S6nMqmwYt+KuzfRVslllhaLhHMYq69o+SSOq1qXUK 7XRNkswwS4NlFMzYHss52rmTd8tyMNlCxsR8Gs/DKmoJk7jqON0EVek2f2rMXgATEPKS jM45Z0dFEgICr7atmVT0rv4kFC9YR8kojxUBl8izOSP+g0/9oV5Nf7YdWSmuL8ipOiMw 1EiKJMyYn/ft7Yi+wvDJkyMJRPiac5IU85tXSl7CKlc1AHsAh5soNLKWZldQ5kI8KDxL MmBg== X-Gm-Message-State: AOAM530B6flVwh4UXFl6x2thm/awNM1Z0qhbGLy2TEuUaCf9rcYZLGoG 501OfX0gHOS9rDxAMJTxksBNph9JpSJCxJYJQGuxBIL6 X-Google-Smtp-Source: ABdhPJxdW+Q+2FSRksH/qc022kcG0z1V9tT4DF5uM62EvIYyK1BaJ9vI3nqInm2L0qJwCqvo+3s1MGmN33/ZoKwr7tU= X-Received: by 2002:a92:9513:: with SMTP id y19mr7557535ilh.300.1635112104872; Sun, 24 Oct 2021 14:48:24 -0700 (PDT) MIME-Version: 1.0 References: <89c62864-feb4-550e-2d63-264b2ecc3344@lear.ch> In-Reply-To: <89c62864-feb4-550e-2d63-264b2ecc3344@lear.ch> From: Mark Smith Date: Mon, 25 Oct 2021 08:48:13 +1100 Message-ID: To: Eliot Lear Cc: Nick Hilliard , Sander Steffann , SPRING WG List , 6man WG Content-Type: multipart/alternative; boundary="0000000000002dd0e705cf203449" Archived-At: Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 24 Oct 2021 21:48:33 -0000 --0000000000002dd0e705cf203449 Content-Type: text/plain; charset="UTF-8" On Mon, 25 Oct 2021, 04:18 Eliot Lear, wrote: > > On 24.10.21 17:36, Nick Hilliard wrote: > > The issue is a good deal deeper than just debugging. As long as > > there's an option to specify a variable length parameter without being > > able to specify the length in the protocol, then the protocol is > > fundamentally ambiguous and its interpretation is entirely context > > dependent. > > You mean, like a subnet mask? > Subnet masks weren't a good idea either. They, like classes and CIDR, are hacks to squeeze more addresses out of the 32 bit IPv4 address space. Have a look at the IPv4 address structure in RFC760. Couldn't be simpler. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --0000000000002dd0e705cf203449 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Mon, 25 Oct 2021, 04:18 Eliot Lear, <lear@lear.ch> wrote:

    On 24.10.21 17:36, Nick Hilliard wrote:
    > The issue is a good deal deeper than just debugging.=C2=A0 As long as =
    > there's an option to specify a variable length parameter without b= eing
    > able to specify the length in the protocol, then the protocol is
    > fundamentally ambiguous and its interpretation is entirely context > dependent.

    You mean, like a subnet mask?


    Subnet masks weren= 't a good idea either. They, like classes and CIDR, are hacks to squeez= e more addresses out of the 32 bit IPv4 address space.

    Have a look at the IPv4 address structure in= RFC760. Couldn't be simpler.




    _______________________________________________
    spring mailing list
    spr= ing@ietf.org
    https://www.ietf.org/mailman/listinfo/spring<= /a>
    --0000000000002dd0e705cf203449-- From nobody Sun Oct 24 15:18:15 2021 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 4BC883A08CC for ; Sun, 24 Oct 2021 15:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 wOVpRBJDBVrE for ; Sun, 24 Oct 2021 15:18:09 -0700 (PDT) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 A3EC33A0865 for ; Sun, 24 Oct 2021 15:18:09 -0700 (PDT) Received: by mail-ua1-x92b.google.com with SMTP id o12so14312862uap.0 for ; Sun, 24 Oct 2021 15:18:09 -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=2+yfRD6qp2B4jh/L49GVtZaFKzutS1B43i/Hy7deiuU=; b=G7ve6nVGjMIJ8/63rlOyTkZrwT3o9M7WMM9HHHhrmS2ZAWvoB6ahvBys6Qz3d+EkV1 j4B5zKUw0c7KPyAyEy/2gwPJ5K4AiNX6nwOyttpOY65J8TbqIDjIXtIJNQ1Sj03o35qn 78T3iEvNJY0XZFHd7i8bKbqnCkT2ZIG01VbvHhSdRUhK7A6y0KKfIA3wqzr3t2FX22+5 14hIoDdxhsdtGG5mbdLPlkuAnWE1EMyvL49Tvr1BJLiQ6dCORq091ck77KYCMIDzCkN5 +liexweuxQSdkKYY06dC2dbmsWDwUOTF7Z8zqKk1p88m+Jxt1m/unmvxf/HPSaN2gEXE ljFg== 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=2+yfRD6qp2B4jh/L49GVtZaFKzutS1B43i/Hy7deiuU=; b=fSL0xpmVotpRhKibFBfvvEnOLxLHbW3Y4q5nIx5ceSRpPbtHYXJZo0PcMcU6NsTfJU h9q+EQL678SUac3kFm9517TnQMcN/1o04ky9itshL6drxZn2CTtYwCjh71kckw+L8Lo5 RkrV33BNRPlOYaryc2mt8EELupiEc526kapDx4+leIpqcYlb7z5C/Isff1TqB01UwYzF oy97LYunOSdAJE6quy4Z491A3iHSgVQsHMqN5p7N5xeRgBGcHOdeISlbE/DHdmmnN+MV 5oB5Jun8LSkuoDoyDent3Na10B/gSBL6IggjtQ9bMG+FakizPyNk9+yjhF5uqxS/26aw Wawg== X-Gm-Message-State: AOAM530jTtupinuSkvilCEFi43Dkd+z96pkxdB5EX9YjPNFTzm8424GI eNDJ3t/j1eN16wHjAW1L2QHT9SZHtYVFczUUb+hWCtv9xfM= X-Google-Smtp-Source: ABdhPJw5s1BY8M9RzYsGH00LrIFeh2iuAeWvYQYZuQQnxF+g9KJ5IsWZ5GQlwCKN+hxmdkA4aQubdacvHUqSVRwmkEc= X-Received: by 2002:a67:c11e:: with SMTP id d30mr12371949vsj.1.1635113888666; Sun, 24 Oct 2021 15:18:08 -0700 (PDT) MIME-Version: 1.0 References: <89c62864-feb4-550e-2d63-264b2ecc3344@lear.ch> In-Reply-To: From: Robert Raszuk Date: Mon, 25 Oct 2021 00:18:03 +0200 Message-ID: To: Mark Smith Cc: Eliot Lear , 6man WG , SPRING WG List Content-Type: multipart/alternative; boundary="000000000000806c3005cf209e03" Archived-At: Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 24 Oct 2021 22:18:14 -0000 --000000000000806c3005cf209e03 Content-Type: text/plain; charset="UTF-8" On Sun, Oct 24, 2021 at 11:48 PM Mark Smith wrote: > Subnet masks weren't a good idea either. They, like classes and CIDR, are > hacks to squeeze more addresses out of the 32 bit IPv4 address space. > > Have a look at the IPv4 address structure in RFC760. Couldn't be simpler. > Simplicity often goes against scalability. I am afraid CIDR and VLSM is not about squeezing anything. Thay are all about improving scaling of both data plane and control plane in IP routing architecture. But if you claim that subnet masks were not a "good idea either" then are you suggesting we should propagate reachability globally using host routes and exact match at each transit hop ? Thx, R. --000000000000806c3005cf209e03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    =
    =C2=A0
    Subnet masks weren't a good idea= either. They, like classes and CIDR, are hacks to squeeze more addresses o= ut of the 32 bit IPv4 address space.

    Have a look at the IPv4 address structure in RFC760. Couldn= 9;t be simpler.


    = Simplicity often goes against scalability.=C2=A0

    I= am afraid CIDR and VLSM is not about squeezing anything. Thay=C2=A0are all= about improving scaling of both data plane and control plane in IP routing= architecture.=C2=A0

    But if you claim that subnet = masks were not a "good idea either" then are you suggesting we sh= ould propagate reachability globally using host routes and exact match at e= ach transit hop ?

    Thx,
    R.=C2=A0
    <= /div>
    --000000000000806c3005cf209e03-- From nobody Sun Oct 24 15:25:29 2021 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 689A03A090B; Sun, 24 Oct 2021 15:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fs11Dd17K3sK; Sun, 24 Oct 2021 15:25:19 -0700 (PDT) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 A7A423A0908; Sun, 24 Oct 2021 15:25:18 -0700 (PDT) Received: by mail-ed1-x530.google.com with SMTP id z20so11388446edc.13; Sun, 24 Oct 2021 15:25: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=U8UuLseJqF4pQG0lXu+VraEDCml1tQsTbW/QBjWuaUE=; b=lcbV8uh165ffqZfzuYXerQiKeAidtfeHwjh7FgjF1TN1zqoRwW0qOnFo8t8MpYhgkJ 8ELd8up+AKMeGk3cwIuWpo2j04ep9Jtadh6+xTKFI7YEwjSmwf9S6b/Rwu++4BbGGuxT XE7RE1qlCM0gEkJtKpXqUyG1i+c1eg7NhgC8AnevKSDN4Bh+QOVBPo8dgxmorlPFAAFw uBrn4NpSLJDw0Dqs7HfucKA4+yx3kFuBZ1LqbVu6/nT7Y7+zdwXaeP2oQGX5PbDWRBg/ LpOqg0i90ykWBQvgxyw0R9Me2drqFqBssWka+/Chq536kqhvjLf0DOACJen6weXxxDjJ /SwA== 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=U8UuLseJqF4pQG0lXu+VraEDCml1tQsTbW/QBjWuaUE=; b=ilI9hmev58QnGfWRFNvgQjE2CVCSLPxj6r20qMsODYyLZOqV/czY1W3W9oyojhWbj+ S7q7SSRWaMWiP1JiCYOYEDgf5LW098RqDVJK93QsFif72PBbGmSMXmhRs2iRfnnu2OSp JpBwKIP/thwMUWbyCvniBCTOs8vggD7nlQAiSHYi2wRwTYgsO8V0QYh2sksV8xuCtg36 +GpP8BNxwescfAB/H7M8CNYg0ojHwbwk3yqZfVemdmc2nd8Ca4HdpTAfSnDuszjafCwE A/GJpozY19aCOwtVJIWaGJlU7ceNN0OfgCVkea0SPMFMz3Y9q7mhlql8xJpmT03XDr8a dGjQ== X-Gm-Message-State: AOAM531vY+Wkwj8YH4CPaaNAU5aBETOQvUGU6//NRZCrVQAkW0+MMhRq ixpDO5pVnHTCmC1paS9+eY6L6BW3Qspig+41/AtWyH5C X-Google-Smtp-Source: ABdhPJwhFtRx2Rt4jExOp+uem3q39EJ+Jb6ztNiNyCeJopCyU3FkXxCOWRR35c7PC3N+Zam+alP057jTdnGN8PmaczI= X-Received: by 2002:a17:907:6e9e:: with SMTP id sh30mr17374134ejc.51.1635114315956; Sun, 24 Oct 2021 15:25:15 -0700 (PDT) MIME-Version: 1.0 References: <89c62864-feb4-550e-2d63-264b2ecc3344@lear.ch> <8bf003b2-988d-6d6c-f080-519596a3b1ac@foobar.org> <5d39e7ae-531d-a821-847e-67b2c0471b24@gmail.com> In-Reply-To: <5d39e7ae-531d-a821-847e-67b2c0471b24@gmail.com> From: Greg Mirsky Date: Sun, 24 Oct 2021 15:25:04 -0700 Message-ID: To: Brian E Carpenter Cc: Eliot Lear , Nick Hilliard , SPRING WG List , 6man WG Content-Type: multipart/alternative; boundary="000000000000f844c005cf20b727" Archived-At: Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 24 Oct 2021 22:25:24 -0000 --000000000000f844c005cf20b727 Content-Type: text/plain; charset="UTF-8" Hi Brian, so far I haven't noticed a proposal to support C-SID in IGP. I think that it brings up a legitimate question: How is it going to work? Would it C-SID be used in combination with dynamic routing protocols or only from a centralized controller? Regards, Greg On Sun, Oct 24, 2021 at 2:20 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 25-Oct-21 09:23, Eliot Lear wrote: > > > > On 24.10.21 21:59, Nick Hilliard wrote: > >> Eliot Lear wrote on 24/10/2021 18:17: > >>> On 24.10.21 17:36, Nick Hilliard wrote: > >>>> The issue is a good deal deeper than just debugging. As long as > >>>> there's an option to specify a variable length parameter without > >>>> being able to specify the length in the protocol, then the protocol > >>>> is fundamentally ambiguous and its interpretation is entirely > >>>> context dependent. > >>> > >>> You mean, like a subnet mask? > >> > >> There's no direct analog here. > > > > Of course there is. You cannot distinguish routing from host without > > looking at external control channels, such as a routing or configuration > > protocol; and you certainly cannot determine the subnet mask of a > > network without that external information, since it's not in the > > packet. And it's not even in the control plane if the route has been > > aggregated. Does that make the information "ambiguous"? The > point is > > that the subnet mask of a network is part of a context that you > > discussed, and you might not have it. > > > > Note- I am not taking a position about CSIDs, but I think this line of > > argument is on the wrong track. > > My assumption has been that within the SRv6 domain, some routing protocol > will be in use (e.g. OSPF) and that (by some magic that I don't understand) > it will be announcing the subnets currently in use, so that bog-standard > routing will occur, including the final hop, because "hosts" supporting > SRv6 will have to function as routers for the final hop. After all, SRv6 > is an overlay, a form of VRF. > > Quite what the magic is that configures OSPF accordingly, I do not know. > > Regards > Brian > Thinking of the IETF standards process: https://xkcd.com/2530/ > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000f844c005cf20b727 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi Brian,
    so far I haven't noticed a proposal to s= upport C-SID in IGP. I think that it brings up a legitimate question: How i= s it going to work? Would it C-SID be=C2=A0used in combination with=C2=A0dy= namic routing protocols or only from a centralized controller?
    Regards,
    Greg

    On Sun, Oct 24, 2021 at 2:20 PM B= rian E Carpenter <brian.e= .carpenter@gmail.com> wrote:
    On 25-Oct-21 09:23, Eliot Lear wrote:
    >
    > On 24.10.21 21:59, Nick Hilliard wrote:
    >> Eliot Lear wrote on 24/10/2021 18:17:
    >>> On 24.10.21 17:36, Nick Hilliard wrote:
    >>>> The issue is a good deal deeper than just debugging.=C2=A0= As long as
    >>>> there's an option to specify a variable length paramet= er without
    >>>> being able to specify the length in the protocol, then the= protocol
    >>>> is fundamentally ambiguous and its interpretation is entir= ely
    >>>> context dependent.
    >>>
    >>> You mean, like a subnet mask?
    >>
    >> There's no direct analog here.
    >
    > Of course there is.=C2=A0 You cannot distinguish routing from host wit= hout
    > looking at external control channels, such as a routing or configurati= on
    > protocol; and you certainly cannot determine the subnet mask of a
    > network without that external information, since it's not in the > packet.=C2=A0 And it's not even in the control plane if the route = has been
    > aggregated.=C2=A0 Does that make the information "ambiguous"= ?=C2=A0 The
    point is
    > that the subnet mask of a network is part of a context that you
    > discussed, and you might not have it.
    >
    > Note- I am not taking a position about CSIDs, but I think this line of=
    > argument is on the wrong track.

    My assumption has been that within the SRv6 domain, some routing protocol will be in use (e.g. OSPF) and that (by some magic that I don't underst= and)
    it will be announcing the subnets currently in use, so that bog-standard routing will occur, including the final hop, because "hosts" supp= orting
    SRv6 will have to function as routers for the final hop. After all, SRv6 is an overlay, a form of VRF.

    Quite what the magic is that configures OSPF accordingly, I do not know.
    Regards
    =C2=A0 =C2=A0 Brian
    =C2=A0 =C2=A0 Thinking of the IETF standards process: https://xkcd.com/2530/

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
    --------------------------------------------------------------------
    --000000000000f844c005cf20b727-- From nobody Sun Oct 24 18:18:35 2021 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 2F8B23A0972; Sun, 24 Oct 2021 18:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gRcwgVkkeJM1; Sun, 24 Oct 2021 18:18:30 -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 AC0BA3A097F; Sun, 24 Oct 2021 18:18:29 -0700 (PDT) Received: from fraeml736-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4Hcxmj1JvYz67SMr; Mon, 25 Oct 2021 09:13:57 +0800 (CST) Received: from dggeml756-chm.china.huawei.com (10.1.199.158) by fraeml736-chm.china.huawei.com (10.206.15.217) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2308.15; Mon, 25 Oct 2021 03:18:24 +0200 Received: from dggeml757-chm.china.huawei.com (10.1.199.137) by dggeml756-chm.china.huawei.com (10.1.199.158) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2308.15; Mon, 25 Oct 2021 09:18:22 +0800 Received: from dggeml757-chm.china.huawei.com ([10.1.199.137]) by dggeml757-chm.china.huawei.com ([10.1.199.137]) with mapi id 15.01.2308.015; Mon, 25 Oct 2021 09:18:22 +0800 From: "Pengshuping (Peng Shuping)" To: "spring@ietf.org" CC: "spring-chairs@ietf.org" Thread-Topic: IETF 112 Slot Requests Thread-Index: AdfD0g0gKR3MrzG+Tai60emOyxI8dAFa+gAA Date: Mon, 25 Oct 2021 01:18:22 +0000 Message-ID: References: <76441b1b77ae4aafac1d2f9894c72e55@huawei.com> In-Reply-To: <76441b1b77ae4aafac1d2f9894c72e55@huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.112.41.150] Content-Type: multipart/alternative; boundary="_000_d4ade3d8e64d4c5aa9e5e576ed4d735ahuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] IETF 112 Slot Requests 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, 25 Oct 2021 01:18:34 -0000 --_000_d4ade3d8e64d4c5aa9e5e576ed4d735ahuaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Please find the slot request link below. https://docs.google.com/forms/d/1MkWm0817Qibt1JaOQjaMEmzbWOEJZAA1XxeKvnL2NQ= Q/edit Or you can directly send to spring-chairs@ietf.org. Best regards, Shuping From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Pengshuping (Pen= g Shuping) Sent: Monday, October 18, 2021 11:44 AM To: spring@ietf.org Cc: spring-chairs@ietf.org Subject: [spring] IETF 112 Slot Requests Dear all, The IETF 112 Final Agenda is now available https://datatracker.ietf.org/mee= ting/112/agenda.html and the SPRING session is arranged on Monday as below. Monday, November 8, 2021 12:00-14:00 Monday Session I Room 5 rtg spring Source Packet Routing in Networking We will continue to using the Google Form to collect presentation slot requ= ests in the SPRING WG for this IETF112. Please fill in your request in the = following Form. https://docs.google.com/forms/d/1MkWm0817Qibt1JaOQjaMEmzbWOEJZAA1XxeKvnL2NQ= Q/edit If there is any issue for you to access this Form, please send your request= directly to spring-chairs@ietf.org. Thank you! Best regards, Shuping --_000_d4ade3d8e64d4c5aa9e5e576ed4d735ahuaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Hi all,=

    &n= bsp;

    Please = find the slot request link below.

    &n= bsp;

    https://docs= .google.com/forms/d/1MkWm0817Qibt1JaOQjaMEmzbWOEJZAA1XxeKvnL2NQQ/edit

     

    Or you = can directly send to sprin= g-chairs@ietf.org.

    &n= bsp;

    Best re= gards,

    Shuping=

    &n= bsp;

    From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Pengshuping (Peng Shuping)
    Sent: Monday, October 18, 2021 11:44 AM
    To: spring@ietf.org
    Cc: spring-chairs@ietf.org
    Subject: [spring] IETF 112 Slot Requests

     

    Dear all,

     

    The IETF 112 Final Agenda is= now available https://da= tatracker.ietf.org/meeting/112/agenda.html

    and the SPRING session is ar= ranged on Monday as below.

     

    Monday, November 8, 2021

    12:00-14:00

    Monday Session I<= /span>

    Room 5   rtg =    spring Source Packet Routing in Networking

     

    We will continue to using the G= oogle Form to collect presentation slot requests in the SPRING WG for this = IETF112. Please fill in your request in the following Form.

     

    https://docs= .google.com/forms/d/1MkWm0817Qibt1JaOQjaMEmzbWOEJZAA1XxeKvnL2NQQ/edit

     

    If there is any issue for you t= o access this Form, please send your request directly to spring-chairs@ietf.org.<= /o:p>

     

    Thank you!

     

    Best regards,=

    Shuping

    --_000_d4ade3d8e64d4c5aa9e5e576ed4d735ahuaweicom_-- From nobody Sun Oct 24 18:56:37 2021 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 74A7E3A0945; Sun, 24 Oct 2021 18:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.588 X-Spam-Level: X-Spam-Status: No, score=-9.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=GEfNEZmr; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=XnF4396h 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 Y_XtsmHw0qy3; Sun, 24 Oct 2021 18:56:29 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48E4B3A093D; Sun, 24 Oct 2021 18:56:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=39349; q=dns/txt; s=iport; t=1635126985; x=1636336585; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/wGZgTUVmjOnBKte1uG3qrCQlg+CErFUz4aBtE+xtwo=; b=GEfNEZmrciiIXGaAdrudQwH6KQj9YVOZuDkzHzEjbA/tEuR0beQzlQyT 50+WokdTppRuHZXVILpGQXMPYt+p6ZRQlgfGxGANedxd7ai1PkHkNjL5y faqrNzPmqHmNZ06I7AzmQHyHQsWjbR2KWPaPBX8jABk8WD3kLZ9lrt+uG 8=; IronPort-PHdr: =?us-ascii?q?A9a23=3AMDEqFxeodH7JfFGHDb8xeWrYlGM/r4qcDmcuA?= =?us-ascii?q?tIPhLdHc6Dl9JPnbwTT5vRo2VnOW4iTq/dJkPHfvK2oX2scqY2Av3YPfN0pN?= =?us-ascii?q?VcFhMwakhZmDJuDDkv2f/HvZi0+Ws9FUQwt83SyK0MAHsH4ahXbqWGz6jhHH?= =?us-ascii?q?BL5OEJ1K+35F5SUgd6w0rW5+obYZENDgz/uCY4=3D?= IronPort-Data: =?us-ascii?q?A9a23=3AlOtcDaB/r0T2yBVW/9zhw5YqxClBgxIJ4kV8j?= =?us-ascii?q?S/XYbTApD1z1WAEmzQbXz+Obq7bMzShfN8jaN+xp0wD7J6DyoVgOVdlrnsFo?= =?us-ascii?q?1CmBibm6XV1Fqp7Vs+rBpWroHlPsoNONbEsEOhuFiWF/0/3buC7xZVB/fjgq?= =?us-ascii?q?oTUWbas1h9ZHWeIeA954f5Ss7ZRbrxA2LBVMCvV0T/GmPAzDXf+s9JC3s343?= =?us-ascii?q?IrYwP9nlKyaVDr1JTXSb9gT1LPVvyF94J7yuciMw3XErol8RoZWRs7Zx72/u?= =?us-ascii?q?2je5RpoUJWuk63wdQsBRbu60Qqm0yUNHfP9xEkZ4HVvic7XN9JEAatTozmFg?= =?us-ascii?q?tN80/1GtIe7TkEiOaikdOE1AkUDS3smZvYXkFPACT3l2SCJ9GXda2HtxfpGD?= =?us-ascii?q?UwqM8sf4OkfKWBW66IwKT0RYFaEne3e6LihS+BqwMllJ8DxJI4Zpnx65T7cB?= =?us-ascii?q?PciB5vERs3i5dZJ1T0tnclBBvP2aM8QaD4pZxPFCzVAIFoYCZc/hvyrl1Hwd?= =?us-ascii?q?jRZrBSeoq9f3oR55GSdy5D3O9bTP9eNX8gQxACTp3nN+CLyBRRyCTBW8hLdm?= =?us-ascii?q?lrEuwMFtXqTtFouKYCF?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3Ai+eQk6m+sgdCJMz1sf6lL7fNh8XpDfOAim?= =?us-ascii?q?dD5ihNYBxZY6Wkfp+V/cjzhCWbtN9OYh4dcIi7Sda9qXO1z+8T3WBjB8bdYO?= =?us-ascii?q?CGghrnEGgG1+vfKlLbalbDH4JmpMJdmu1FeaHN5DtB/IfHCWuDYqwdKbC8mc?= =?us-ascii?q?jC74qzvhQdLz2CKZsQkjuRYTzrdHGeMTM2fabRY6Dsn/avyQDQHUg/X4CePD?= =?us-ascii?q?0oTuLDr9rEmNbNehgdHSMq7wGIkHeB9KP6OwLw5GZfbxp/hZMZtUTVmQ3w4a?= =?us-ascii?q?uu99uhzAXH6mPV55NK3PP819p4AtCWgMR9EESutu/oXvUiZ1SxhkFwnAid0i?= =?us-ascii?q?dsrDAKmWZnAy1H0QKVQohym2q15+Cv6kd315ao8y7ovZKqm72IeNt9MbsbuW?= =?us-ascii?q?qcGSGptnbJe7pHofh2NiuixulqJAKFkyLn69fSURZ20kKyvHo5iOYWy2dSSI?= =?us-ascii?q?0EddZq3MEiFW5uYdw99RjBmcoa+ShVfbbhzecTdUnfY2HSv2FpztDpVnMvHg?= =?us-ascii?q?2eSkxHvsCOyTBZkH1w0kNdnaUk7zg93YN4T4MB6/XPM6xumr0LRsgKbbhlDO?= =?us-ascii?q?NERcesEGTCTR/FLWrXK1X6E6MMPW7LtvfMkfkIzfDvfIZNwIo5mZzHXl8dvW?= =?us-ascii?q?kue1j2AcnLx5FP+gClehT0Yd0s8LAW23FUgMyIeFPbC1z0dLl1qbrTnxw2OL?= =?us-ascii?q?yuZ8qO?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AIBwBeDnZh/5ldJa1QBwMeAQELEgx?= =?us-ascii?q?AgU4LgSEwUQd3WhMkMYgOA4U5iA0DinWFIYpggS4UgREDTwULAQEBDQEBKgE?= =?us-ascii?q?MCgQBAYUAAoJOAiU0CQ4BAgQBAQESAQEFAQEBAgEGBIERE4U7CCUNhkIBAQE?= =?us-ascii?q?BAgEBARAIJgEBLAQHAQQLAgEIBwoBAwEBASABAgQHIQYLFAMGCAIEDgUIEwe?= =?us-ascii?q?CUIF+VwMOIQEOn0kBgToCih94gTOBAYIIAQEGBASBNgETQYJ/DQuCNQmBIxe?= =?us-ascii?q?DBoQVgSCFWyccgUlEgRQBQ4JnPoIhQgEBAgGBKAEHCwEHHB0CBQEGCQgJgmg?= =?us-ascii?q?ggi6McRBCGQYXGwwbCwQLFxYLCAcBBQ8MAg0sBhpRAQ0EAQwZAQEsATQQA5F?= =?us-ascii?q?WCQeCbolSjVSRCjxnCoMyikuIH4YkhgcVg2qLboZIiBOIaZYMjHGDRpAoJ4R?= =?us-ascii?q?2AgQCBAUCDgEBBoFhOys+cHAVO4JpCUgZD4cIhxgMFhWDO4UUhUp0AjYCBgs?= =?us-ascii?q?BAQMJkm8BAQ?= X-IronPort-AV: E=Sophos;i="5.87,179,1631577600"; d="scan'208,217";a="943020339" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Oct 2021 01:56:23 +0000 Received: from mail.cisco.com (xbe-aln-007.cisco.com [173.36.7.22]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 19P1uN3u000988 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Mon, 25 Oct 2021 01:56:23 GMT Received: from xfe-rcd-005.cisco.com (173.37.227.253) by xbe-aln-007.cisco.com (173.36.7.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15; Sun, 24 Oct 2021 20:56:23 -0500 Received: from xfe-rcd-002.cisco.com (173.37.227.250) 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.792.15; Sun, 24 Oct 2021 20:56:22 -0500 Received: from NAM11-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-002.cisco.com (173.37.227.250) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.792.15 via Frontend Transport; Sun, 24 Oct 2021 20:56:22 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=oMb19uaZ8JPAeqhSIwFYdPnk2BqRYvy5CE1/pgpUhGv14cb7TKR7fd0hxsxQop4btS8Slh0p5otZSgt5r9bnFH94lBuO6AbWE+ta0ZZeLwqmiFKGj5J0cI+60y0v8j3OFQJGqrPVykuwPBZDVsu80U9Vddl9Cl07jB3s7hmpKQY7VY5t8ekpfoWWXv5o94MsQGHYz4lD0QT+akxCO6Jka0d+kc0wLBwoIDJmYHlZyF4Lk3pbKW7JvS6moE6zl+1vk+fGtUkTekFjMTVkyFf/a6OzsTwbMkiyvefwq+pEbkZFJAydzFMyVDf/+2gOJFpHOJHKvHg9vh+ZryEsYvutzQ== 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=1IX8vRkAIYyr05+eZie4U2cHwdqgl17dR1krnd0ZqAI=; b=FOPfIevl97DqpbUMgqciexy0JHBvmFxLBmLU11LQ91PeuNiKvOSx68jTd+K2chFR9qL4OwVEda9uEMrkME4B9tr5G3LKG5ae/g0iWisOn8SKixVTb5MH4rHn44CgXR5V4uqwI2USDA3Agl35WeHO0bjT/KdOFpaopiAV2yQyMdf401K2f9kTn021S0ujWgYHSrVKqUiweyCmaKXwQYtrC62rLkRbTVDhwMklEJ9pnw6x5NAejG1BpFOou6z94VmQ8dx9r9T/eCDSDBiZb1MkaqagvatXqCplIRAOqxvPUxLbgi0bshtog831xkYAdIli+JRuO6+6pJL5Mcm1Adu1jA== 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=1IX8vRkAIYyr05+eZie4U2cHwdqgl17dR1krnd0ZqAI=; b=XnF4396hFx5B4zl57nBw6BSJPtDpEQbSBjHflY/qRYbHajV0qmDk8xV1Fbccxn7mzKkk1ZJNhnf3bKtb4Z+o+0CvAKtLCVEGLclPFRxhM5pMlkQICYxlsTd4qQyzGX3Q5tNKvLMG0N8/fHJqhbFF3hD1jMMQPjgSevWU78nd7P4= Received: from BN6PR11MB4081.namprd11.prod.outlook.com (2603:10b6:405:78::38) by BN6PR1101MB2099.namprd11.prod.outlook.com (2603:10b6:405:57::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.18; Mon, 25 Oct 2021 01:56:20 +0000 Received: from BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::90c7:290e:a57c:1a39]) by BN6PR11MB4081.namprd11.prod.outlook.com ([fe80::90c7:290e:a57c:1a39%3]) with mapi id 15.20.4628.020; Mon, 25 Oct 2021 01:56:20 +0000 From: "Darren Dukes (ddukes)" To: Greg Mirsky CC: Gyan Mishra , Brian E Carpenter , "ipv6@ietf.org" , "spring@ietf.org" Thread-Topic: Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression Thread-Index: AQHXxe8+Uq3QOF5820qajRqw1QJECavdgCRCgACSI4CAAGKcb4AD/rmAgACBYrU= Date: Mon, 25 Oct 2021 01:56:20 +0000 Message-ID: References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> <26d9fc32-4884-602c-975a-79fc64551727@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-CA X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 06b510df-ec20-4b74-1c92-08d9975aa423 x-ms-traffictypediagnostic: BN6PR1101MB2099: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Znka4u0uxH61mYl05v2+WuQ4ah29h7FdRGygv+Ok1ZwfcxTDxNYIK8hwf4+cnjh2JEZGDg8cFHKEWd0Vo07LBv1puFwVA+4ZXWxbDRj+Or3o6M5u9OQzFywc6DLyNiC5evRl0rcombgHzzpsiS9cdSyFXM1iETgXhaLET3ZQ5GjnuAV0rkqkJMmYuBktkAvZSvlh5Il0R7et7tLS8/A4uedn1BGZrQKek/AtwE3hRSDTUHE2+s1LAQ08NXTBnQPMW2iadWhK2c2lxp2f13/XvMGQP2GAJkWM3a5WY3vRg4PckTXAEpGJVvYbAPmHIY5ROx+Y8P3qRiIfpe9V94BJOwPyAZmekxIV1eHkyGUrwBmKRqgZwdxMKH2KVfPIfAMkF7ycEp3crz59BeyljPDBQ5dkPCzgiZcJUxwevnV4/MfNI3c5BSgpPeIbDcRhaK3Z99UDMcgiVE2An6OBXzAY9f3UlGYdMKfjGHK1o+4lOhGOJyZe15C9ge1ojOAGSPInnNyBm76+3CuqYitsbZY9M/jiNUsRAQZMUb3tCa3zYWaWxedFHQhalxpF+JroGnkecv8AMKshymBwHyxwMcu5/ESTHbv8si6o+hatGsXbIDUF54mtHJTSHpp8FKwUzdRzVz50g9xcHT6zoKzXaCd9rYo3/oxzAVKCFl23dG7OrlBat+8Lodsyt35rb6hrHlTAsZ+Qkgw/8UfWmDZlvO82xErW+wkkonpMAqpgxfPRIgQ5PcB7KFIpZ1z5alhFiuY9zMVY0JxyW+p6eKYf8bCBcLSZPs4xNfmMdYNTuNba135lRgpSX2Poy6fBfXSwqz/54nTw4Sqi/EC/9jcRikvVNA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN6PR11MB4081.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(38070700005)(122000001)(4001150100001)(53546011)(64756008)(66446008)(186003)(66556008)(4326008)(7696005)(54906003)(83380400001)(508600001)(71200400001)(9686003)(66476007)(166002)(38100700002)(66946007)(6916009)(33656002)(76116006)(5660300002)(66574015)(86362001)(91956017)(30864003)(8676002)(26005)(966005)(8936002)(40140700001)(52536014)(6506007)(55016002)(2906002)(316002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?vnXmhgKs7IvnXbcRDw1IfATGcXqzxRhWT6hH6Nxby6UU/IxBxuk8m3MR?= =?Windows-1252?Q?V5er0OJ/+JBSfx+u0bBLpLiNguBIcOJo2vpREm44o7neGQXuPIp3wxa2?= =?Windows-1252?Q?Ga7GNV1QdO4xtjEcumCDRP3WKxDy0mTWt1PLGpldWQt/dZc8ie/uPo2/?= =?Windows-1252?Q?Xzia6hRuUQW3mprdYc1q1lZr8TZOGn9W5yGLxZ/BMtUpjZcTgfXniIAc?= =?Windows-1252?Q?HZVflZ2rOxbCSCLgfFvDi7IHUGqxKNC1l3Tw95rOZC4QbftRbUA9c/tc?= =?Windows-1252?Q?ysyfxrtRg939s1kJATgKtSz8Qb/a5/xLeVo24Ki5h51aNAsj+eSg4J+X?= =?Windows-1252?Q?sF2TVW7ZZnPObfx/7Y4kLsSGR/UXdr0VUSStPgjnXTx/5WmP+EIFzw9w?= =?Windows-1252?Q?pwtC+KqxTlhLT142kFp/4JtBR8ke+eS20qgzfpSADOB/k+Yeb3jkVy5a?= =?Windows-1252?Q?lFF/ynu3fagh3ttvcA3g9JEiDQEOv/lK6w2K0hDrX/0nk9eOkXgM6EiQ?= =?Windows-1252?Q?QjGdeh+NwkvujHD0yRk77DXWM67QjLNcsWTDRUL13KHXWaDNw2ErX/Ib?= =?Windows-1252?Q?uNuPDUfAliTeA35cbe+zux54dEJBclP2198j1A9yNEgfehmUeOTwaoYT?= =?Windows-1252?Q?3UhoOYFTZwBE6ojf2BTMS9gH11uLbBB3tTgpeRmZDNfSOZ3Iah8VYD3r?= =?Windows-1252?Q?4BD4AD/4Cv6GJTWMnMx9rmyJbsqKoq34jrGOuFcF4PH/n8ll7LIXpTFL?= =?Windows-1252?Q?ir884y9hgVqPj5GYXSHmXUIwd7tlMScsMyNVj0aXWpjHpOSxXoHHrXEA?= =?Windows-1252?Q?uHs6aOuarIXzEZARGOeQe7gfmuVBDYHh6fZ8Vi16Nd/NMaD1U/lPs3m9?= =?Windows-1252?Q?oYWcy1qyNt6XLbd8PoCdG3TLQWoUKTu4FEGdf+Dwf+KHEcYgjMh1gBR3?= =?Windows-1252?Q?VpgFzE14hAcKNWgdIFhcLrsPIuVxv8sV0Df+cteU5wMHVPAKaKcl70CI?= =?Windows-1252?Q?G9R/jXmMCm66therJEwoPzaoB6sMc1rM6uJS6TCoukL1EBKhZFuh3USW?= =?Windows-1252?Q?Pp4PHuTU39AidElFO+70XpTq3H1+WjQSjikspL9Qpir/6c9hXaR3ZkYC?= =?Windows-1252?Q?d2Sr7lB8MrJ/9EMfGzMPTp5PxJyXpCzlInRcy3csCbZyodjZDrgNyHj6?= =?Windows-1252?Q?SLahTZypHYiQAYWDDPkFVNwb7hrwxlFQMZxLji9fHC4S2rvKidr/r7gc?= =?Windows-1252?Q?x1G8aCa/cskb/e3fc2yMgT7JU6E91WM2BLsn+cNTUkkLYJPsjOM6IfhE?= =?Windows-1252?Q?YHJPVOF7cdiLCwSv8aMF3l0LcVTVO3bdZgq9KkpR4FLjM7rx9YmzckVW?= =?Windows-1252?Q?C5fLCNIaOxQDKeEvYl4rIXUlhmwF4LeSDPWWEAWBPFvVylJ59v3DGtCi?= =?Windows-1252?Q?T86B3vMnhB2xdpahQhWdDcpFOkS4EVbGQwtQlX7ROaUdNGcG1SMJPm5L?= =?Windows-1252?Q?DFgFTETOxP3ZtcXqOC802cVtgF3UGaRNQCxGqjbasHuxh7D2a1duSJ+H?= =?Windows-1252?Q?wwuME5mqFoK6SaPpUpA1dwRCedxORMFmz1MbiOCH7gRqOcMeKFN+N0nS?= =?Windows-1252?Q?O+9D/KO2z3Y6zhuYNOcyvBHhoOhPJu+Ag/U8Ee5RVV6uPmaZ58/5quK8?= =?Windows-1252?Q?fgaMXk0jK5zwqR5DPrAxZnAHRPo5hBWrsvlIVB/H1ar9gNcg+t7gpznK?= =?Windows-1252?Q?nXMDwPz0wvHOZ0NTBWgQqZ0lvDzx82uLTzd5l1Ie?= Content-Type: multipart/alternative; boundary="_000_BN6PR11MB4081144010053465C8C3267BC8839BN6PR11MB4081namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BN6PR11MB4081.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 06b510df-ec20-4b74-1c92-08d9975aa423 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2021 01:56:20.4042 (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: kntSpm7Nl0KEsVuaum5s9bv18yAkO9T2r9jdBvtk83kkoJL7Uj9IMvYD4S949/cglisoD+ihf4JbJR+RGimryA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1101MB2099 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.22, xbe-aln-007.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 25 Oct 2021 01:56:36 -0000 --_000_BN6PR11MB4081144010053465C8C3267BC8839BN6PR11MB4081namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Greg. You ask =93Is 64-bits routable prefix in the DA an implicit prerequisite of= the C-SID solution?=94 The answer is no. In the rest of your query i think you are asking how IPv6 packet forwarding= works (I.e, based on prefix). Recall the compressed SIDs in the draft are SRv6 SID with a locator functio= n and arg like any other. Rfc8986 section 3 does a good job of describing t= his for all SRv6 SIDs. If you see something missing, please elaborate. Darren ________________________________ From: Greg Mirsky Sent: Sunday, October 24, 2021 1:51 PM To: Darren Dukes (ddukes) Cc: Gyan Mishra; Brian E Carpenter; ipv6@ietf.org; spring@ietf.org Subject: Re: Typo correction Re: Question from SPRING regarding draft-filsf= ilscheng-spring-srv6-srh-compression Hi Daren, thank you for responding to my question. Is 64-bits routable prefix in the = DA an implicit prerequisite of the C-SID solution? As to my question about what Brian referred to as a "funny" part. In Sectio= n 6 we read: The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A C-SID length of 16-bit is recommended. and then: The recommended SRv6 SID block sizes for the NEXT-C-SID flavor are 16, 32 or 48 bits. Now, it seems to me that there are many possibilities of getting the "funny= " part of C-SID into a routable space of the DA. For example, an operator, = following the recommendation of the C-SID specification, uses 16-bit NEXT-C= -SID in combination with, for example, 32 bits block size. As a result, 16 = bits of "funny" part, i.e., another NEXT-C-SID, are in the routable space. Am I missing something? Thank you for your consideration. Regards, Greg On Thu, Oct 21, 2021 at 10:06 PM Darren Dukes (ddukes) > wrote: Hi Gyan and Greg. Gyan I=92m sorry but i don=92t see a question in your email. I=92ll go back= to Greg. While I=92m not exactly sure what is being asked, I will say that Brian is = correct for every Srv6 SID behavior (not just csid flavors) when he says th= e following about their arguments (lowest 64 bits in the ipv6 Dest addr. =93They are invisible to routing (which is done based on the prefix) and in= visible to neighbor discovery (because it never happens).=94 I hope this helps. Darren ________________________________ From: Gyan Mishra > Sent: Thursday, October 21, 2021 7:03 PM To: Darren Dukes (ddukes) Cc: Brian E Carpenter; Greg Mirsky; ipv6@ietf.org; sp= ring@ietf.org Subject: Re: Typo correction Re: Question from SPRING regarding draft-filsf= ilscheng-spring-srv6-srh-compression Hi Darren What Greg is asking is if the SID is a prefix SID End and not adjacency SID= End.x, so now the common prefix is needed to ECMP steer the flow to the p= refix SID which uses the common prefix, which may in this case be mutated = due to shifting of SIDs in GSID container. Kind Regards Gyan On Thu, Oct 21, 2021 at 10:18 AM Darren Dukes (ddukes) > wrote: Hi Greg, Your question is not clear to me. Can you try to restate it with the flavors and behaviors from the draft in = question? Darren On 2021-10-20, 4:15 PM, "ipv6" > wrote: Hi Brian, I've got some questions about what you've said: For that reason, the fact that the bottom 64 bits in the "address" look funny or change is simply irrelevant. They are invisible to routing (which is done based on the prefix) and invisible to neighbor discovery (because it never happens). As I understand it, what you describe is the case of a strict explicit path= defined using one of the C-SID compression methods. But I am not sure that= your conclusion also always applies when it is a loose explicit path speci= fied in the compressed Segment List. As all C-SIDs share the same prefix, h= ow routing can be done based only on that prefix and not using a part of th= at "funny" bottom 64 bits? And if any part of the bottom 64 bits must be us= ed, how one can guarantee that CIDR still works in that domain? Regards, Greg On Mon, Oct 18, 2021 at 9:50 PM Brian E Carpenter > wrote: Hi, After reading a lot of messages, I'm going to offer my considered opinion as a direct response to Joel's OP. Firstly, I don't believe that in the end this draft raises any concerns that are *significantly* different than those raised when RFC 8986 was in draft. As Ted Hardie mentioned, section 5 of RFC 8754 explains that SIDs of any shape or size are only meaningful within an SR domain. That applies to srh-compression too. Secondly, I was concerned about how these strange looking "addresses" would potentially interfere with normal IPv6 addresses and their handling by normal IPv6 nodes. Well, I now believe that they won't. The reason is that in the SR model these "addresses" are *never used for final delivery of IPv6 packets to a host.* All SRv6 participants are routers. The last hop for a packet whose DA is set to (say) 2001:db8:a:1900:: is *not* the last hop on a LAN, mediated by neighbor discovery for 2001:db8:a:1900::. It's just a hop from one router to another, using the entry for 2001:db8:a:1900::/64 in the FIB of the last router that actually forwards the packet. 2001:db8:a:1900:: is not assigned to a physical interface so RFC 4861 is never invoked. Another way to say it is RFC 7608 is the relevant architectural standard. CIDR rules, even within an SR domain. For that reason, the fact that the bottom 64 bits in the "address" look funny or change is simply irrelevant. They are invisible to routing (which is done based on the prefix) and invisible to neighbor discovery (because it never happens). I apologise if this is all obvious to everybody, but I needed to spell it out for my own understanding. Now back to Joel's questions: On 13-Oct-21 20:37, Joel M. Halpern wrote: > There is a typo in the below which if not understood as a typo would be > quite confusing. I wrote that I raised the issue with > "with the Internet ADs and SPRING chairs". > That should have read "with the Internet ADs and 6man chairs". > The SPRING co-chairs are recused, and the charter requirement leads to > the 6man chairs. Which is who I talked to. > > Also, I am sending a courtesy copy to the routing ADs, which I should > have done originally. > > Thank you and enjoy. > Yours, > Joel > > On 10/12/2021 11:52 PM, Joel M. Halpern wrote: >> The SPRING working group is in the midst of an adoption call on >> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-com= pression/. >> >> >> The SPRING charter has text that is explicit that modifications to data >> planes and architectures standardized by other working groups may not be >> modified in SPRING unless the chairs and ADs responsible for that data >> plane and / or architecture agree. >> >> To complete the context, as my SPRING co-chairs are co-authors on the >> document in question, they have recused themselves from decisional >> activities regarding the document. Therefore, this message is coming >> just from my as the responsible SPRING co-chair managing this adoption >> call. >> >> As you have seen, multiple questions have been raised about the >> relationship of the document to the IPv6 defined data plane and >> architecture (particularly RFC 4291 and 8200). In particular the >> questions seem to revolve around what the document describes as the >> NEXT-C-SID flavor of compressed SID, and its relationship to the IPv6 >> standards. (For those seeking more context without reading the full >> document, a paraphrase and simplification of the NEXT-C_SID flavor is >> provided as a postscript.) >> >> I raised the question of concurrence as required by the SPRING charter >> with the Internet ADs and SPRING chairs. They quite reasonably asked me >> to write a note to 6man explaining the concerns as clearly as a can, so >> that they can then determine how to proceed. >> >> The questions that prompted my inquiry are: >> >> 1) Does the placement of a list of sids in the IPv6 DA field change the >> IPv6 architectural description of that field. I think it should be noted explicitly somewhere that since the contents of the DA field are *never* used for last-hop neighbor discovery, the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942 are irrelevant. Another citation is RFC 7608: for routing, all that counts is the prefix, and it can be anything up to 128. Perhaps this should have been in section 5 of RFC 8754, but I leave that to the wordsmiths. >> 2) Does the operation of shifting information around in the IPv6 >> destination address field represent a modification or extension of the >> IPv6 data plane. No. As my text above indicates, the SRv6 DA field is only ever used by routing, where RFC 7608 rules. And of course it vanishes as soon as the packet is decapsulated. Regards Brian >> >> On a related note, the document in question also defines two other >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID. The >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID >> flavor operation, so seems to be affected by the same question. >> >> From my own reading, it appears that the REPLACE-C-SID flavor does not >> raise issues requiring 6man leadership concurrence. >> >> Yours, >> Joel M. Halpern for the SPRING working group >> >> >> PS: >> Clearly, understanding the question requires some understanding of what >> the NEXT-C_SID flavor does. This explanation is a simplification for >> length and context. Really, the best place to understand it is the >> draft. However, to give you enough information to let you decide >> whether you care, I will try to provide a fair summary. My apologies in >> advance to the authors for necessary liberties for length. Also, >> discussion of the draft contents (as distinct from the interaction with >> the IPv6 data plane and architecture) belongs on the SPRING list, and >> should not clutter up 6man. >> >> SIDs are the identifiers used in segment routing. >> In SRv6, as document in the current RFCs, these are 128 bits. As >> defined in the relevant RFCs, SIDs which identify endpoints to which >> packets are directed are identified by endpoint SIDs. These can have >> behaviors (decapsulate and forward is one example). They can have >> flavors such as where the SRH is removed. >> >> The topic under discussion is means to compress these SIDs in the >> packets on the wire. The document under discussion provides three >> flavors of compression. >> >> The fundamental mechanism of the draft is to use a single SRH entry as a >> container for multiple SIDs. In the NEXT-C_SID mechanism, when it is >> first encountered the entire container is copied into the desination >> address of the IPv6 packet. The container has a common routing prefix >> used for all the NEXT-C-SID SIDs. It is followed by a sequence of >> compressed SIDs of a configured length. One could configure 16, 24, or >> 32 bits. Or whatever length. The routing advertisements are arranged >> so that the IPv6 packet is directed to the node represented by the first >> compressed SID on the basis of longest prefix match matching the >> combination of the common routing prefix and that compressed SID. >> >> When the packet arrives at that node, it looks up the configured >> portion, the compressed SID, and determines the behavior and flavor. In >> the case of the NEXT-C-SID flavor, the resulting operation is to shift >> the entire remaining contents of the IPv6 address (the bits past the >> first compressed sid) so as to over-write the first compressed SID. 0 >> bits are shifted into the low order positions. If the result is a >> non-zero new first compressed SID, then the packets is forwarded and the >> process repeats. When all that is left are 0s, if there is an SRH, it >> is consulted to find the next SRH entry, which is, per normal SRv6 >> processing, put into the IPv6 DA. >> Note that in the common case where the SIDS needed all fit in to a >> single container, the analysis also assumes the use of the reduced >> encapsulation options which omits the SRH that is not needed as it would >> have no entries. This the packet contains a normal IPv6 header, with a >> sequence of compressed SIDs (what one might or might not call a source >> route) in the IPv6 destination address field. >> >> PPS: If the authors of the NEXT-C-SID flavor feel I have mis-represented >> the work, please, send clarifications or corrections. Again, the best >> source of information is the draft itself. I was asked to provide extra >> context in this email. > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- -- [http://ss7.vzw.com/is/image/VerizonWireless/vz-logo-email] Gyan Mishra Network Solutions Architect Email gyan.s.mishra@verizon.com M 301 502-1347 --_000_BN6PR11MB4081144010053465C8C3267BC8839BN6PR11MB4081namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
    Hi Greg.

    You ask =93Is 64-bits routable prefix in the DA an implicit prerequisite of th= e C-SID solution?=94

    The answer is n= o.

    In the rest of = your query i think you are asking how IPv6 packet forwarding works (I.e, ba= sed on prefix). 

    Recall the comp= ressed SIDs in the draft are SRv6 SID with a locator function and arg like = any other. Rfc8986 section 3 does a good job of describing this for all SRv= 6 SIDs. If you see something missing, please elaborate.

    Darren

    From: Greg Mirsky <gregimirsky@gmail.com>
    Sent: Sunday, October 24, 2021 1:51 PM
    To: Darren Dukes (ddukes)
    Cc: Gyan Mishra; Brian E Carpenter; ipv6@ietf.org; spring@ietf.org Subject: Re: Typo correction Re: Question from SPRING regarding draf= t-filsfilscheng-spring-srv6-srh-compression
     
    Hi Daren,
    thank you for responding to my question. Is 64-bits routable prefix in= the DA an implicit prerequisite of the C-SID solution? 

    As to my question about what Brian referred to as a "funny&q= uot; part. In Section 6 we read:
       The NEXT-C-SID flavor supports both 16- and 32-bit C-SID = lengths.  A
       C-SID length of 16-bit is recommended.
    and then:
       The recommended SRv6 SID block sizes for the NEXT-C-SID f= lavor are
       16, 32 or 48 bits.

    Now, it seems to me that there are many possibilities of getting the &= quot;funny" part of C-SID into a routable space of the DA. For example= , an operator, following the recommendation of the C-SID specification, use= s 16-bit NEXT-C-SID in combination with, for example, 32 bits block size. As a result, 16 bits of "funny" par= t, i.e., another NEXT-C-SID, are in the routable space.
    Am I missing something? Thank you for your consideration.

    Regards,
    Greg

    On Thu, Oct 21, 2021 at 10:06 PM Darr= en Dukes (ddukes) <ddukes= @cisco.com> wrote:
    Hi Gyan and Greg. 

    Gyan I=92m sorry but i don=92t see a question in your emai= l. I=92ll go back to Greg. 

    While I=92m not exactly = sure what is being asked, I will say that Brian is correct for every Srv6 S= ID behavior (not just csid flavors) when he says the following about their = arguments (lowest 64 bits in the ipv6 Dest addr.

    =93They are = invisible to routing (which is done based on the prefix) and invisible to neighbor discovery (because it never happens).=94

    I hope this helps. 

    Darren

    From: Gyan Mishra <hayabusagsm@gmail.com&= gt;
    Sent: Thursday, October 21, 2021 7:03 PM
    To: Darren Dukes (ddukes)
    Cc: Brian E Carpenter; Greg Mirsky; ipv6@ietf.org; spring@ietf.org
    Subject: Re: Typo correction Re: Question from SPRING regarding draf= t-filsfilscheng-spring-srv6-srh-compression
     


    Hi Darren 

    What Greg is asking is if the SID is a prefix SID End and= not adjacency SID End.x, so now the common prefix is needed to ECMP steer = the flow  to the prefix SID which uses the common prefix,  which = may in this case be mutated due to shifting of SIDs in GSID container.


    Kind Regards 

    Gyan 
    On Thu, Oct 21, 2021 at 10:18 AM Darr= en Dukes (ddukes) <ddukes=3D40cisco.com@dmarc.ietf.org> wrote:

    Hi Greg, <= /p>

     

    Your question is not clear to m= e.

    Can you try to restate it with = the flavors and behaviors from the draft in question?

     

    Darren

     

    On 2021-10-20, 4:15 PM, &= quot;ipv6" <ipv6-bounces@ietf.org> wrote:

     

    Hi Brian,

    I've got some questions a= bout what you've said:

    For that reason, the fact= that the bottom 64 bits in the

    "address" look = funny or change is simply irrelevant. They are

    invisible to routing (whi= ch is done based on the prefix)

    and invisible to neighbor= discovery (because it never happens).

    As I understand it, what = you describe is the case of a strict explicit path defined using one of the= C-SID compression methods. But I am not sure that your conclusion also alw= ays applies when it is a loose explicit path specified in the compressed Segment List. As all C-SIDs share the sam= e prefix, how routing can be done based only on that prefix and not using a= part of that "funny" bottom 64 bits? And if any part of the bott= om 64 bits must be used, how one can guarantee that CIDR still works in that domain?

     

    Regards,

    Greg

     

    On Mon, Oct 18, 2021 at 9= :50 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:=

    Hi,

    After reading a lot of messages, I'm going to offer my considered
    opinion as a direct response to Joel's OP.

    Firstly, I don't believe that in the end this draft raises any
    concerns that are *significantly* different than those raised
    when RFC 8986 was in draft. As Ted Hardie mentioned, section 5
    of RFC 8754 explains that SIDs of any shape or size are only
    meaningful within an SR domain. That applies to srh-compression
    too.

    Secondly, I was concerned about how these strange looking
    "addresses" would potentially interfere with normal IPv6
    addresses and their handling by normal IPv6 nodes. Well, I
    now believe that they won't. The reason is that in the SR model
    these "addresses" are *never used for final delivery of IPv6
    packets to a host.* All SRv6 participants are routers. The
    last hop for a packet whose DA is set to (say) 2001:db8:a:1900::
    is *not* the last hop on a LAN, mediated by neighbor discovery
    for 2001:db8:a:1900::. It's just a hop from one router to another,
    using the entry for 2001:db8:a:1900::/64 in the FIB of the last
    router that actually forwards the packet. 2001:db8:a:1900:: is
    not assigned to a physical interface so RFC 4861 is never invoked.

    Another way to say it is RFC 7608 is the relevant architectural
    standard. CIDR rules, even within an SR domain.

    For that reason, the fact that the bottom 64 bits in the
    "address" look funny or change is simply irrelevant. They are
    invisible to routing (which is done based on the prefix)
    and invisible to neighbor discovery (because it never happens).

    I apologise if this is all obvious to everybody, but I needed
    to spell it out for my own understanding.

    Now back to Joel's questions:


    On 13-Oct-21 20:37, Joel M. Halpern wrote:
    > There is a typo in the below which if not understood as a typo would b= e

    > quite confusing.   I wrote that I raised the issue with
    > "with the Internet ADs and SPRING chairs".
    > That should have read "with the Internet ADs and 6man chairs"= ;.
    > The SPRING co-chairs are recused, and the charter requirement leads to=
    > the 6man chairs.  Which is who I talked to.
    >
    > Also, I am sending a courtesy copy to the routing ADs, which I should =
    > have done originally.
    >
    > Thank you and enjoy.
    > Yours,
    > Joel
    >
    > On 10/12/2021 11:52 PM, Joel M. Halpern wrote:
    >> The SPRING working group is in the midst of an adoption call on >> https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/.
    >>
    >>
    >> The SPRING charter has text that is explicit that modifications to= data
    >> planes and architectures standardized by other working groups may = not be
    >> modified in SPRING unless the chairs and ADs responsible for that = data

    >> plane and / or architecture agree.
    >>
    >> To complete the context, as my SPRING co-chairs are co-authors on = the
    >> document in question, they have recused themselves from decisional=
    >> activities regarding the document.  Therefore, this message i= s coming
    >> just from my as the responsible SPRING co-chair managing this adop= tion

    >> call.
    >>
    >> As you have seen, multiple questions have been raised about the >> relationship of the document to the IPv6 defined data plane and >> architecture (particularly RFC 4291 and 8200). In particular the <= br> >> questions seem to revolve around what the document describes as th= e
    >> NEXT-C-SID flavor of compressed SID, and its relationship to the I= Pv6
    >> standards.  (For those seeking more context without reading t= he full
    >> document, a paraphrase and simplification of the NEXT-C_SID flavor= is
    >> provided as a postscript.)
    >>
    >> I raised the question of concurrence as required by the SPRING cha= rter

    >> with the Internet ADs and SPRING chairs.  They quite reasonab= ly asked me
    >> to write a note to 6man explaining the concerns as clearly as a ca= n, so
    >> that they can then determine how to proceed.
    >>
    >> The questions that prompted my inquiry are:
    >>
    >> 1) Does the placement of a list of sids in the IPv6 DA field chang= e the
    >> IPv6 architectural description of that field.

    I think it should be noted explicitly somewhere that since the contents
    of the DA field are *never* used for last-hop neighbor discovery,
    the IID aspect of RFC 4291 is irrelevant, and RFC 4861 + RFC 5942
    are irrelevant. Another citation is RFC 7608: for routing, all that
    counts is the prefix, and it can be anything up to 128.

    Perhaps this should have been in section 5 of RFC 8754, but I leave
    that to the wordsmiths.

    >> 2) Does the operation of shifting information around in the IPv6 <= br> >> destination address field represent a modification or extension of= the

    >> IPv6 data plane.

    No. As my text above indicates, the SRv6 DA field is only ever used
    by routing, where RFC 7608 rules. And of course it vanishes as soon
    as the packet is decapsulated.

    Regards
        Brian

    >>
    >> On a related note, the document in question also defines two other=
    >> flavors, REPLACE-C-SID, and NEXT-and-REPLACE-C-SID.  The
    >> NEXT-and-REPLACE-C_SID flavor is defined to include the NEXT-C_SID=
    >> flavor operation, so seems to be affected by the same question. >>
    >>  From my own reading, it appears that the REPLACE-C-SID flavo= r does not
    >> raise issues requiring 6man leadership concurrence.
    >>
    >> Yours,
    >> Joel M. Halpern for the SPRING working group
    >>
    >>
    >> PS:
    >> Clearly, understanding the question requires some understanding of= what
    >> the NEXT-C_SID flavor does.   This explanation is a simp= lification for
    >> length and context.  Really, the best place to understand it = is the
    >> draft.  However, to give you enough information to let you de= cide

    >> whether you care, I will try to provide a fair summary.  My a= pologies in
    >> advance to the authors for necessary liberties for length.  A= lso,

    >> discussion of the draft contents (as distinct from the interaction= with
    >> the IPv6 data plane and architecture) belongs on the SPRING list, = and
    >> should not clutter up 6man.
    >>
    >> SIDs are the identifiers used in segment routing.
    >> In SRv6, as document in the current RFCs, these are 128 bits. = ;  As
    >> defined in the relevant RFCs, SIDs which identify endpoints to whi= ch
    >> packets are directed are identified by endpoint SIDs.  These = can have
    >> behaviors (decapsulate and forward is one example).  They can= have
    >> flavors such as where the SRH is removed.
    >>
    >> The topic under discussion is means to compress these SIDs in the =
    >> packets on the wire.  The document under discussion provides = three
    >> flavors of compression.
    >>
    >> The fundamental mechanism of the draft is to use a single SRH entr= y as
    a
    >> container for multiple SIDs.  In the NEXT-C_SID mechanism, wh= en it is
    >> first encountered the entire container is copied into the desinati= on
    >> address of the IPv6 packet.  The container has a common routi= ng prefix
    >> used for all the NEXT-C-SID SIDs.  It is followed by a sequen= ce of
    >> compressed SIDs of a configured length.  One could configure = 16, 24, or
    >> 32 bits.  Or whatever length.  The routing advertisement= s are arranged
    >> so that the IPv6 packet is directed to the node represented by the= first
    >> compressed SID on the basis of longest prefix match matching the <= br> >> combination of the common routing prefix and that compressed SID.<= br> >>
    >> When the packet arrives at that node, it looks up the configured <= br> >> portion, the compressed SID, and determines the behavior and flavo= r.  In
    >> the case of the NEXT-C-SID flavor, the resulting operation is to s= hift

    >> the entire remaining contents of the IPv6 address (the bits past t= he
    >> first compressed sid) so as to over-write the first compressed SID= .  0
    >> bits are shifted into the low order positions.  If the result= is a
    >> non-zero new first compressed SID, then the packets is forwarded a= nd the
    >> process repeats.  When all that is left are 0s, if there is a= n SRH, it
    >> is consulted to find the next SRH entry, which is, per normal SRv6=
    >> processing, put into the IPv6 DA.
    >> Note that in the common case where the SIDS needed all fit in to a=
    >> single container, the analysis also assumes the use of the reduced=
    >> encapsulation options which omits the SRH that is not needed as it= would
    >> have no entries.  This the packet contains a normal IPv6 head= er, with a
    >> sequence of compressed SIDs (what one might or might not call a so= urce

    >> route) in the IPv6 destination address field.
    >>
    >> PPS: If the authors of the NEXT-C-SID flavor feel I have mis-repre= sented
    >> the work, please, send clarifications or corrections.   = Again, the best
    >> source of information is the draft itself.  I was asked to pr= ovide extra
    >> context in this email.
    >
    > -------------------------------------------------------------------- > IETF IPv6 working group mailing list
    > ipv6@iet= f.org
    > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > -------------------------------------------------------------------- >

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org=
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------=

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org=
    Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    --------------------------------------------------------------------
    --
    --_000_BN6PR11MB4081144010053465C8C3267BC8839BN6PR11MB4081namp_-- From nobody Mon Oct 25 01:46:46 2021 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 50CB23A0867 for ; Mon, 25 Oct 2021 01:46:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=liquidtelecom.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 0vc-C_Fcwx8n for ; Mon, 25 Oct 2021 01:46:36 -0700 (PDT) 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 1E1D03A08ED for ; Mon, 25 Oct 2021 01:46:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquidtelecom.com; s=mimecast20210406; t=1635151594; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=k2PffdHUL9K5WswMS5Wo4HaA3DMhadfdREfFU/BExWY=; b=GaKJmOAsqEiieHBH1vRMnIK8+4ZxSd6Z60rcfUL1PrdSm+gXuKCSfgqVL2uQ6sRSGutpHc f/FF4Ov599PB72Ax9oEOmVGfnzo+iDfq28uwtd1vGoq6ehwOQbPZcmewETnK1pfg64cO4S McEmOwuTeaEBrMML+6A+1nmK66HRNmM= Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05lp2109.outbound.protection.outlook.com [104.47.18.109]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-142-B8-zHy8KP7ef1dy3_eMbfA-1; Mon, 25 Oct 2021 09:46:30 +0100 X-MC-Unique: B8-zHy8KP7ef1dy3_eMbfA-1 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com (2603:10a6:20b:346::6) by AS8PR03MB7937.eurprd03.prod.outlook.com (2603:10a6:20b:424::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.16; Mon, 25 Oct 2021 08:46:29 +0000 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9]) by AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9%6]) with mapi id 15.20.4628.020; Mon, 25 Oct 2021 08:46:29 +0000 From: Andrew Alston To: Eliot Lear , Nick Hilliard CC: SPRING WG List , 6man WG Thread-Topic: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) Thread-Index: AQHXx/O4amezbiLfA0mwUAzKM2wSgqvhsZOAgABbU4CAADcFAIAABeAAgAAcVQCAAC1iAIAABo2AgADOV3A= Date: Mon, 25 Oct 2021 08:46:29 +0000 Message-ID: References: <89c62864-feb4-550e-2d63-264b2ecc3344@lear.ch> <8bf003b2-988d-6d6c-f080-519596a3b1ac@foobar.org> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e802455a-c0c7-4a93-de6b-08d99793f03b x-ms-traffictypediagnostic: AS8PR03MB7937: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: EUtDJlX3DkHfZviijF2ada69ljw5JJR8eSyMqZoCEHZ43M5nEFKmR0dALrUIDE/vQjukCrAyPp4lXNLi64gE7SZn/oMsIhjEcXHp68S4HuJO2Jf2IVqMmAd5svIeXK8nd+Cmqm1sR58r7M0aR/CjU84aFyjcRLNOZBkAAF587tKxByKmlGAQOqUtOX/rzYJBtoIIBLM2QDipd4S0xxAsOR0/+Pg8QgIpFQvN1HgBx6ypI9V6d7GnCu80Avz5vk3fN+EnVeHme+VlIxGkI+5RXwoYcNu9Ri87Rwdq1r3kV9aDhLCt7+W6HK98CvUu2TkckuuLlTSONT8Z/HQl8L9dMZDPPqMab302bHM2/Ky17Yym392q8xfdw554mi7QliU7sPJZj5lESgApr3tGEwSRySPJXXK0r7UvLvTmwyrdewmo/i/+5MWkarHwroxOsBV5CIYYJaywoRsf6YSCrwj05npgZtb56wCT2X9XTSPas0SXVIQ4S1HAiASEdUvIZCbIIVow1AOo00lMHlaYRivq1EWZMJE0O4M+AF9KfRDNquOR9t6C97/bmv71+NVOzMu9vfPWn5fh9c1uujV0QB1PM1KbiIJk1ECOZaPuE5vDiWcpznTmyQ+Jk2/X/sFVBCI5wA0FmM2S1MXTFWwkti66dxKePdJX4Wfz/LnwVEkTtt4irJEYk3Aq0LizHnpMGFLTWC248vxLks7fJLBm/RazAg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR03MB7622.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(316002)(71200400001)(54906003)(55016002)(4326008)(508600001)(6506007)(122000001)(66556008)(8676002)(33656002)(186003)(66946007)(66476007)(76116006)(64756008)(66446008)(7696005)(66574015)(83380400001)(5660300002)(52536014)(38100700002)(38070700005)(8936002)(9686003)(86362001)(2906002)(110136005); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?eG5PRGE3bHNBQ0hSYVpFS0QyenlUbDFSL2ZTQU1DZElEcXRtUWI3ZnBvb2JL?= =?utf-8?B?YWthcmhiVkpTbEcyYkVMZFJNcktDWE1uZm4wT0JCMVp5UmdMbFd0Y2Z5aGN5?= =?utf-8?B?K29idEhyZGFZK1RWUlpxS08vaEVjU1BsK1lFS0xjbFNGYkFwU2kzOENLbk5t?= =?utf-8?B?UFIyaStPNlgyYWgzMEZiWk1RYk5BL2JaV25heXhZV29aTDBmZ0ZjUG9aQmVQ?= =?utf-8?B?YlpqaEdKaXhnY0tmbHRqU1Z0NlNRVVVXS1RNOFBTRzdMemtKWTYvRkEvNW1K?= =?utf-8?B?aDl1cU93Y2FBc1Q4SEZqSlpvUzdzVnQ5TE04RnFWM1JxMDJsSkM5M0JCdWhC?= =?utf-8?B?VSt1TGp3ZXI0MnIvL2NsTHRTbXJobXFRLzMwQmFmWW1pdmVDU2lGNG93RVVi?= =?utf-8?B?dUZXeDRha1V6QUJXdmFZMFpadUpBbmJtNTNuQzY4VklCeUJEWEJ4d0JrM0hV?= =?utf-8?B?dkhwVFcvaFRXSzAxUHh0WEg1cWFqZ3ZtbzY1YVVFanBjT0ltRVkrcWRrY2x1?= =?utf-8?B?SnBHN2x6MkZ0SUtUWnl2bHl2dlhpR1k5QU1GeWxFZXhkWWZPbDhXNEhHUzcv?= =?utf-8?B?WmVoWDdwR1VBUlFHRi9xOWxlZjgwc2tWeUcvSS9VTkNBcDZWQXVJNFVYdmRQ?= =?utf-8?B?ak5pcW5aYlQzZ3M3UERISi9ZTGdKMWdQQTVsYmxYUm03VDM2b1pEeVBGZS9o?= =?utf-8?B?bWhXNis1ZGF5TjRReW1lLzlkVEVjYW5TL2IyYmdTNkJsRWE5OUkxTy9xRVBv?= =?utf-8?B?VmFSMGJyMmZWenAreGE4eDNFZmNBVUU4RHYzQys3cXVxS3ZnYnNTRVRmeENs?= =?utf-8?B?QmQyallwcmNHQlZkcmRwVnVyRXI5dWNlU0lwVCtUYnlHay9MVXlZbVlaQzU1?= =?utf-8?B?aHNwVWtoVHgraEkzRnpZcHNjWXdWekZKRWNuNjRYUjFqYWFOVWFsZ05ELyto?= =?utf-8?B?N0JGOU00WGlzaHRIZXE4SVRHeDJOZ1RCdG1wUUczMVl5TUZ1ZTljOFl6TXRy?= =?utf-8?B?enJzNzJLU001MG5leVpGeHZ3ZVBCeU5yRlJXUy9CUXNXYlRRNmJqVlEvWmhs?= =?utf-8?B?WHdRZ0ROMnArSWdGUEZab0w4eWZZbmdBR2Y5a2JYK012andDUWZJNmR0dTYr?= =?utf-8?B?UGV1UnZRS1NNK000UkQ0VGRZN3VkWXQ2ZXJza2RwdGpVU3Fxa0pDOEZRNFQ0?= =?utf-8?B?ODVkWGxsa1RNdS91VzVDZmlhaHJRaDBDZnV6ZWgzYXp2Zkw4WHpjdW9RaHJW?= =?utf-8?B?WEtIMWgyUFI4dlVvMk5ZT1d2NWFMTysrdzFqc3FHMG5jNHRPOGZNWE00RXBF?= =?utf-8?B?aTVTS3hydzU1VGVMdVlmYjZTVkRSMnJBRFlYYVR3Qkhwd2hHSVJiNjRIVldx?= =?utf-8?B?SmdiNnRIdXFuQlRScHdWM3F6Q0hsY2hlTjFvcDdBQjhPN0Q4Ni9CYVZBd1o3?= =?utf-8?B?TURhS2ZhUDByUWpLOERXbWJURXd2YkpMUG9icXMxTjlXbzdaaW9kQnovczJk?= =?utf-8?B?eWVOOEhYTTZxR1d4RzF6QjVDR0ZaTGFwZVo0Y1h4azE2VTVablJXbjJwTm9U?= =?utf-8?B?MlF4YXpOVmhRNUNJeHZSQVp4TFZZMFBBZjVXOStwYU1tV213R01wYmpEZ3dz?= =?utf-8?B?SUFCL3JqWjhGL3p1OXorS3k2Wit2WnZ4L05nY3FwZlJxbzJ1Q2c3WUpBY01a?= =?utf-8?B?NFZDajZxWG0zTTR1VEQ3OFFSUUhxV3BnVE1mZGo3dDNqMm16L0xFN3llbWY5?= =?utf-8?B?UVhxZ09ieFlBaGNZa3J2bzZ4TkFLMTRzc2VzNHRUc0p3NUlHZ004WnJMeUJZ?= =?utf-8?B?Umx0dDF3TmxUL1IwRDd1L2tOSGtZUm0vcDBSaThES2dPcWxQdGZ0anBHdEtO?= =?utf-8?B?RFpReEhGd05pRzdEcFFCNXZxM3FvSDloL3JZbU1kSHp2dTF5N1JsZkt0blcx?= =?utf-8?B?c21kYWJpVTcxdm9VeElySVFIakkwS0N6MlVLVWxCNklib0JHZFBvdGJkcjFa?= =?utf-8?B?MlNPQXZ1S0JjeVVoOUtFdlJmVHdlemdOUFRReCttNyszMjdhQkYzanB2bFYy?= =?utf-8?B?bTFHNW0wUGFOa0hvbDkwWTd5QVhHeXAxTko3OGhjc2FZZXVwZjdiQWQwd01X?= =?utf-8?B?T1NIRGg2bC9Fa3creW4vTDJ2RitTVW9oQ3lIRStub0kwWG8xcStYMm85ZXBH?= =?utf-8?B?aGQ1OEpYemNYQVZ3QXJySURmTkRQWkhMdmpZK1d4L2F5VHhGZm5rVVduczRj?= =?utf-8?B?eUk0cnBIQnpjTldYMkRQV1B5OER5MFl3WFp1TFhGcENKYnlFNEdJYzBwaEUw?= =?utf-8?Q?GD4xbFdRci2lAzNJes?= MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB7622.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e802455a-c0c7-4a93-de6b-08d99793f03b X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2021 08:46:29.4813 (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: ngqZPjI0OZoN7Z/JFk0Mlbvts9/20NDkG/c26BzWwyj3lC2CgTyt4F0gR+nUze8uS+LNU89Xi2siQArTnMnZerXMzp6MQgJUR4guMP/sjIk= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7937 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquidtelecom.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 25 Oct 2021 08:46:41 -0000 PiBPZiBjb3Vyc2UgdGhlcmUgaXMuwqAgWW91IGNhbm5vdCBkaXN0aW5ndWlzaCByb3V0aW5nIGZy b20gaG9zdCB3aXRob3V0IGxvb2tpbmcgYXQgZXh0ZXJuYWwgY29udHJvbCBjaGFubmVscywgc3Vj aCBhcyBhIHJvdXRpbmcgb3IgY29uZmlndXJhdGlvbiBwcm90b2NvbDsgYW5kIHlvdSBjZXJ0YWlu bHkgY2Fubm90IGRldGVybWluZSB0aGUgc3VibmV0IG1hc2sgb2YgYSBuZXR3b3JrIHdpdGhvdXQg dGhhdCBleHRlcm5hbCBpbmZvcm1hdGlvbiwgc2luY2UgaXQncyBub3QgaW4gdGhlID8+IHBhY2tl dC7CoCBBbmQgaXQncyBub3QgZXZlbiBpbiB0aGUgY29udHJvbCBwbGFuZSBpZiB0aGUgcm91dGUg aGFzIGJlZW4gYWdncmVnYXRlZC7CoCBEb2VzIHRoYXQgbWFrZSB0aGUgaW5mb3JtYXRpb24gImFt YmlndW91cyI/wqAgVGhlIHBvaW50IGlzIHRoYXQgdGhlIHN1Ym5ldCBtYXNrIG9mIGEgbmV0d29y ayBpcyBwYXJ0IG9mIGEgY29udGV4dCB0aGF0IHlvdSBkaXNjdXNzZWQsIGFuZCB5b3UgbWlnaHQg bm90IGhhdmUgaXQuDQoNClRoaXMgYW5hbG9neSBkb2Vzbid0IHJlYWxseSB3b3JrIGZvciBtZS4g IEluIHRoZSBjYXNlIG9mIGFuIFNSSCAtIHRoZSByb3V0ZXIgYWN0cyBvbiB0aGUgcGFja2V0IGJh c2VkIG9uIGxvY2FsIGNvbmZpZ3VyYXRpb24gLSBob3cgaXQgZ2V0cyB0aGF0IGNvbmZpZyBkb2Vz bid0IHJlYWxseSBtYXR0ZXIuICBUaGUgU0lEIHNpemUgaW4gdXNlIGJ5IGVhY2ggcm91dGVyIG1h eSBvciBtYXkgbm90IGJlIGV4cG9zZWQgYnkgYW4gSUdQIGZvciByZWFkaW5nIC0gYW5kIGNvdWxk IGRpZmZlciBhdCBlYWNoIG5vZGUuICBJbiB0aGUgY2FzZSBvZiBzdGFuZGFyZCBmb3J3YXJkaW5n IHlvdSBoYXZlIGEgRklCIGVudHJ5IC0gaW5zZXJ0ZWQgZnJvbSB0aGUgUklCIC0gdGhhdCBnb2Vz IGEgY2VydGFpbiBwbGFjZS4gIEluIHRoZSBjYXNlIG9mIHRoaXMgLSBhIHJvdXRlciBjb3VsZCBi ZSB1c2luZyBlaXRoZXIgMTZiaXQgU0lEIG9yIDMyYml0IFNJRCAtIGVudGlyZWx5IGNvbmZpZ3Vy ZWQgbG9jYWxseSAtIGFuZCBkZXBlbmRlbnQgb24gdGhlIGNvbmZpZ3VyYXRpb24gLSB3aWxsIGRl dGVybWluZSBpZiB0aGUgbm9kZSBpbiBxdWVzdGlvbiBzaGlmdHMgdGhlIGluZm9ybWF0aW9uIGJ5 IDE2IG9yIDMyIGJpdHMgLSBiZWZvcmUgdGhlIEZJQiBsb29rdXAuICANCg0KVGhlcmVmb3JlIC0g aW4gYSBzdGFuZGFyZCBzY2VuYXJpbyAtIHlvdSBrbm93IHRoYXQgcGFja2V0IFggaXMgZ29pbmcg dG8gYmUgZm9yd2FyZGVkIHVzaW5nIGEgRklCIGVudHJ5IGxvb2t1cCBvZiBZIC0gaW4gdGhlIGNh c2Ugb2YgdGhpcyAtIHlvdSBoYXZlIG5vIGlkZWEgd2hhdCB0aGUgcm91dGVyIGlzIGFjdHVhbGx5 IGdvaW5nIHRvIGJlIGxvb2tpbmcgdXAgLSBiZWNhdXNlIHlvdSBkb24ndCBrbm93IGlmIGl0cyBn b2luZyB0byBiZSBkb2luZyBhIDE2IG9yIDMyIGJpdCBzaWQgd2l0aG91dCBrbm93aW5nIHRoZSBz cGVjaWZpYyBsb2NhbCBjb25maWd1cmF0aW9uIG9uIHRoZSByb3V0ZXIuICBUaGF04oCZcyBhIHZl cnkgZGlmZmVyZW50IGxldmVsIG9mIGNvbXBsZXhpdHkgaW4gdGVybXMgb2Ygb3BlcmF0aW9ucyBh bmQgZGVidWdnaW5nIG9uIGEgbGFyZ2UgbmV0d29yaw0KDQpBbmRyZXcNCg0KDQo= From nobody Mon Oct 25 03:37:58 2021 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 720EE3A09BB; Mon, 25 Oct 2021 03:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 GHs93Gyvmji0; Mon, 25 Oct 2021 03:37:49 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 134F23A0995; Mon, 25 Oct 2021 03:37:49 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id 34-20020a9d0325000000b00552cae0decbso14321595otv.0; Mon, 25 Oct 2021 03:37:49 -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=AxkSMtz2tob7UdGYaojfJL5KuuWV22rowHMxIKSlCfM=; b=Egjk1hy40CSzAqDprlF/nIif6S9HZAp/lmIhqHdTcbHxjoK7wdg6AoyEkJxomZMnY+ sLmptDtMtfAQq7/tGJ+R2gjLzcTdwBFswg4jrWzssajy69hofqlYDIUEEYKI0TvMUmK5 I3P6tlixhYlfL0NWwi1TNezXwQYd9svTS04we1BAwAQNM3Z0L+bMs4g5ZTAvt2iBhjZ8 rw8GzyCpkMx+xEI73e+B8njbmEXZ6JGMywfdHE9lNiPE6oCCVjKQIO7S1ayWOVGEUKjE rej2EOUKVSNGGtBRJfT52T+eCxsGzmmdLmTAkpo4Xk4veD3f+9W7bwOkcpfpb717GL1b O6SA== 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=AxkSMtz2tob7UdGYaojfJL5KuuWV22rowHMxIKSlCfM=; b=xtawRBFj+C7aMr4/s9Y8ozngSg5MhyIaKLf16E2GuHDgsUo3lHUM6zWP9kuMk/sA1u I/8SEb5BXoH98afSxU9+BpXaspUqiNFphGEUk7JGQII/4ir3CVgXculBiRkJ3RQftHKC XGOelLnn2WH+GYhlD6fiG5U+PDHp/JQk7nOlAUK4WibB0cc6GNRltf/nmAlQEG6PPHZi HZtuN7FEonPNZ3i7vJ9F+2VlBuDJTE+XGWSSk4A9Gw6fnpyw27CtJ/mUFRfxlNRr8Mfw Rk0PynnUvjAw8Aq/lt5lyBhFZOnF52Mqv0zQmw1R9cAy68hp6mBrPpUAI++mjRiICipZ 9qoA== X-Gm-Message-State: AOAM5306PcQCBtIdEaVWXNyiLAGZVdVnnlhnD0F2tKatwDc21Bzal/QH Y/23lB442VzI7C/pC9qi+6fgQg0qcuOc0w+tohA= X-Google-Smtp-Source: ABdhPJys3L1QF08GBrXiQfpqoN+P1kCsLINwMsQgN0ZqHN4rYxeZ9CZW3IbM2zFjxVk9C1b5otuHX9+ZHMlEkluJTxg= X-Received: by 2002:a05:6830:1045:: with SMTP id b5mr13464258otp.338.1635158267677; Mon, 25 Oct 2021 03:37:47 -0700 (PDT) MIME-Version: 1.0 References: <89c62864-feb4-550e-2d63-264b2ecc3344@lear.ch> <8bf003b2-988d-6d6c-f080-519596a3b1ac@foobar.org> In-Reply-To: From: Ted Hardie Date: Mon, 25 Oct 2021 11:37:21 +0100 Message-ID: To: Andrew Alston Cc: Eliot Lear , Nick Hilliard , SPRING WG List , 6man WG Content-Type: multipart/alternative; boundary="000000000000b24d8805cf2af33c" Archived-At: Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 25 Oct 2021 10:37:52 -0000 --000000000000b24d8805cf2af33c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 25, 2021 at 9:47 AM Andrew Alston wrote: > > Of course there is. You cannot distinguish routing from host without > looking at external control channels, such as a routing or configuration > protocol; and you certainly cannot determine the subnet mask of a network > without that external information, since it's not in the ?> packet. And > it's not even in the control plane if the route has been aggregated. Doe= s > that make the information "ambiguous"? The point is that the subnet mask > of a network is part of a context that you discussed, and you might not > have it. > > This analogy doesn't really work for me. In the case of an SRH - the > router acts on the packet based on local configuration - how it gets that > config doesn't really matter. The SID size in use by each router may or > may not be exposed by an IGP for reading - and could differ at each node. I think Eliot's main point is that there are aspects of a flow's routing through a network which are observable in a packet and there are aspects which are not. Think about a network which implements a flow-based equal-cost multipath; the determination of which flows take which path uses information in the packet but the algorithm that hashes it together and chooses a next hop is not. The practices about what to choose can vary significantly and to debug (or plan), you have to know a lot more about the network than what's in the packet itself. regards, Ted Hardie > In the case of standard forwarding you have a FIB entry - inserted from > the RIB - that goes a certain place. In the case of this - a router coul= d > be using either 16bit SID or 32bit SID - entirely configured locally - an= d > dependent on the configuration - will determine if the node in question > shifts the information by 16 or 32 bits - before the FIB lookup. > > Therefore - in a standard scenario - you know that packet X is going to b= e > forwarded using a FIB entry lookup of Y - in the case of this - you have = no > idea what the router is actually going to be looking up - because you don= 't > know if its going to be doing a 16 or 32 bit sid without knowing the > specific local configuration on the router. That=E2=80=99s a very differ= ent level > of complexity in terms of operations and debugging on a large network > > Andrew > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000b24d8805cf2af33c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Mon, Oct 25, 2021 at 9:47 AM Andrew Alston <Andrew.Alst= on=3D40liquidtelecom.= com@dmarc.ietf.org> wrote:
    > Of course there is.= =C2=A0 You cannot distinguish routing from host without looking at external= control channels, such as a routing or configuration protocol; and you cer= tainly cannot determine the subnet mask of a network without that external = information, since it's not in the ?> packet.=C2=A0 And it's not= even in the control plane if the route has been aggregated.=C2=A0 Does tha= t make the information "ambiguous"?=C2=A0 The point is that the s= ubnet mask of a network is part of a context that you discussed, and you mi= ght not have it.

    This analogy doesn't really work for me.=C2=A0 In the case of an SRH - = the router acts on the packet based on local configuration - how it gets th= at config doesn't really matter.=C2=A0 The SID size in use by each rout= er may or may not be exposed by an IGP for reading - and could differ at ea= ch node.=C2=A0

    I think Eliot's main point is that there ar= e aspects of a flow's routing through a network which are observable in= a packet and there are aspects which are not.=C2=A0 Think about a network = which implements a flow-based equal-cost multipath; the determination of wh= ich flows take which path uses information in the packet but the algorithm = that hashes it together and chooses a next hop is not.=C2=A0 The practices = about what to choose can vary significantly and to debug (or plan), you hav= e to know a lot more about the network than what's in the packet itself= .

    regards,

    =
    Ted Hardie
    =C2=A0
    In the case of standard forwarding you have a FIB entry - inserted from= the RIB - that goes a certain place.=C2=A0 In the case of this - a router = could be using either 16bit SID or 32bit SID - entirely configured locally = - and dependent on the configuration - will determine if the node in questi= on shifts the information by 16 or 32 bits - before the FIB lookup.=C2=A0 <= br>
    Therefore - in a standard scenario - you know that packet X is going to be = forwarded using a FIB entry lookup of Y - in the case of this - you have no= idea what the router is actually going to be looking up - because you don&= #39;t know if its going to be doing a 16 or 32 bit sid without knowing the = specific local configuration on the router.=C2=A0 That=E2=80=99s a very dif= ferent level of complexity in terms of operations and debugging on a large = network

    Andrew


    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
    --------------------------------------------------------------------
    --000000000000b24d8805cf2af33c-- From nobody Mon Oct 25 04:08:32 2021 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 C0B503A0BC8; Mon, 25 Oct 2021 04:08: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.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <163516010773.20576.14269466647319711952@ietfa.amsl.com> Date: Mon, 25 Oct 2021 04:08:27 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-policy-14.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, 25 Oct 2021 11:08: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 : Segment Routing Policy Architecture Authors : Clarence Filsfils Ketan Talaulikar Daniel Voyer Alex Bogdanov Paul Mattes Filename : draft-ietf-spring-segment-routing-policy-14.txt Pages : 39 Date : 2021-10-25 Abstract: Segment Routing (SR) 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. 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-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-policy-14 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 25 05:14:33 2021 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 06F653A0A26 for ; Mon, 25 Oct 2021 05:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.108 X-Spam-Level: X-Spam-Status: No, score=-3.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_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=liquidtelecom.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 d1t8u84mT49u for ; Mon, 25 Oct 2021 05:14:24 -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 AA0E13A0A3F for ; Mon, 25 Oct 2021 05:14:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquidtelecom.com; s=mimecast20210406; t=1635164060; 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=H7KrpM4QjEDgRNJenZc7eKBnHtYQXIFaqbMCAEvIqp4=; b=RNwagGxOhFjIYzLY9T6l2s7wS1Canm8RoDgHf8KCdyshH34S84tGhVy9Lk8PpY28yoLerW HoGp8ccDFxLq/Pa89vUwghRG8Ff74lCq2fH0yRc0S+hl1CAbjz0Yw3rG7ikiKLWjfBmwK2 iilfzEm0HSBDB8oYDLOE9NNYhZo+rC4= Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01lp2058.outbound.protection.outlook.com [104.47.2.58]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-257-ry0Sz11FMFmg2i9gGsHLGQ-1; Mon, 25 Oct 2021 13:14:17 +0100 X-MC-Unique: ry0Sz11FMFmg2i9gGsHLGQ-1 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com (2603:10a6:20b:346::6) by AS8PR03MB7831.eurprd03.prod.outlook.com (2603:10a6:20b:34f::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.18; Mon, 25 Oct 2021 12:14:15 +0000 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9]) by AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9%6]) with mapi id 15.20.4628.020; Mon, 25 Oct 2021 12:14:15 +0000 From: Andrew Alston To: Ted Hardie CC: Eliot Lear , Nick Hilliard , SPRING WG List , 6man WG Thread-Topic: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) Thread-Index: AQHXx/O4amezbiLfA0mwUAzKM2wSgqvhsZOAgABbU4CAADcFAIAABeAAgAAcVQCAAC1iAIAABo2AgADOV3CAACBHgIAAFsNg Date: Mon, 25 Oct 2021 12:14:14 +0000 Message-ID: References: <89c62864-feb4-550e-2d63-264b2ecc3344@lear.ch> <8bf003b2-988d-6d6c-f080-519596a3b1ac@foobar.org> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2f6c0d24-2555-42ba-f12b-08d997b0f644 x-ms-traffictypediagnostic: AS8PR03MB7831: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: 2vK/lR0faaE+2tDi+9caZ/twWwxkUMQryXk/ROROpcSx7s+FXf0uUC8RvmbGG9lKcWZHS3OpII8pVSM/5XlmgtCK2/ymhCUGDoi9jXULY07Mlrm2MS+lbxSG8Nmrg6cDsuSTxIO37tOxVLvvN+5XZC7kt4m87Yy6yifIX3m+entCpWqSZYxeMXDykFtCzttKDGlzXL9fOqW13qqf+p8Q6ADxrb/P0FduUuj+/3E1EDD63OGDjdPhgGQWkSWwSn0ZYgA7IcSyw1UigTutddMFgb+59hEVmktib78GUgVp20upe4403V4oyQjNWBPMyHxbONYVif5HpFtWitIqfzSJpHO3AS76qz4L/lTs8ishqtmOgI8wu4rvqCMGQRYkfD+9Ux/lDuyaO8nioM9iyTW8QaJu/kuL1nv+03c7NHhxMr2N3uXy010X5pZJyVc2CH+f1knhzNl12FicZbNU3KYAAyhRGHQV85U9jAaJ4fSjR4e9iuMVoArh7MCaqpTVWQM48dMhF+WQfQSl5sqbDbfastq3/k3pt6DwgI/pMNQQIKY8oIWj5y0wtaEiv6+C4YWknooTtVjBVwUrTIzagFOqv2nUNLy5A+Au4Ab6ZgpOJcQqgruExY+ZEHoU8T2+QfGPGPi7jlazXYVwBAsM0SZ7nI099cX9RxOjoU8q1d48ESGi4WOLT9DaDErka2yh92V6RY+f+m5VGzcrLBMiIXFSZY9wtKl58J1JZFqHmaieMXizKFETAEVPTJva/rzmdVGPBBBTr/fDz/pSIcCVhnF9nGQhNtn6N8Zn25rZbiqm+cM= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR03MB7622.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(186003)(508600001)(55016002)(6916009)(8676002)(66556008)(316002)(83380400001)(66574015)(6506007)(66446008)(8936002)(53546011)(966005)(71200400001)(122000001)(38100700002)(166002)(7696005)(64756008)(76116006)(4326008)(66946007)(52536014)(33656002)(9686003)(86362001)(5660300002)(2906002)(38070700005)(54906003)(66476007); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?L3FyVHF6WUJDWWtyQWV3enN4MDM0SzRYa0JXUGp2SFhZcTk1WVliYkhwWE96?= =?utf-8?B?SThPL0h4elJ4TGI3MllBTmRYdGI5bVZHMjFjejJMNitRWE5SY3ZjeTdhbjhD?= =?utf-8?B?TGx4dG9sUW9CdmRIN1dYQnlDdW9QWk5TUGxOc24xeDUwQVVYZjlMOGViU3ZT?= =?utf-8?B?cmFteExFb3VJMnJRQTZDT0RrNCs3b0NFb2JCNzVSZkh3Z1JMUmJCclRvdkFL?= =?utf-8?B?SkllRUFtOS9LcDQ5NTJ5VVUvVDVkRHZsWGNGUFgyNzhJTkdSZFdsYlV6dS9F?= =?utf-8?B?Z2JGMzliUnBSM3pXZG1wVzBJd3ZWbFpESGtXY1BQWHZVQnVCWjRycXRLL0l2?= =?utf-8?B?NUtEWW9TaXFuR255UlRObXdFS01QWEdWdFRtRW9yT0NpdXJLUXFOYzFGVG04?= =?utf-8?B?NkpZOE9VdWVJd2dTSzIyRzRBd1lLM0dJWlQ0VUd0VWRXU2llVlV1VC9kYVVZ?= =?utf-8?B?RzFzYStVb05VeFk3V3kzaTZNRHFYaGI2YjU3QTFKemhmWUhUb1RaM0lNbWpk?= =?utf-8?B?R2VVc2FrNG9JYTd5NmwvUUN1bmlkTFJIVXZUM3lVVkVDbFBqWHBOYmV2aTRQ?= =?utf-8?B?VDBCaml5aExpNjU1WkpBUHVjSzFuNm51bkNRT0V2QTRlalQ1WEhwRWFIQUdh?= =?utf-8?B?ajM3cFFWTzBTdjFJOWxLTmNqRHNtczRHTGhHR2JQS3dxOFRPdVREcGpmK0pB?= =?utf-8?B?czJSMk9jbDZPV044KzZBdzdlODdRWG1UVnMrRUlNdjdEeCtFR3BzeE1qbmRp?= =?utf-8?B?WW9yWVQxL0NVY3RySmZFVmVDNC9zam9qVjczTHdJY2Z2dVVWdVBmU2pRZU04?= =?utf-8?B?MURjS0VxR1RBVkRZSUFVWUprbEp1cXpOWTgvZEZSVHQzc0dieXN1cThOamZh?= =?utf-8?B?NzlVUlN5Z1FnN0F5QmlpWVBsaUpOTVpjN0VyQWxSZ010VXJ5SlBBeHlUc3JG?= =?utf-8?B?b0NUSkpPWmlFWUFzNEJocnVFWVlnUmNVY3pvV0VKOWJyWldqd2NGZ0h3M2NJ?= =?utf-8?B?UWJmWVJHbm54NEt1ZVpBR2tqZU45WnhxcSt5ckVMWlU5OHFVTEpPdVlNSE9C?= =?utf-8?B?d3lSWmUrdDVweWl5c25hUjRpMWJXWU83cHl3Ym1qdmhrSTZGWUc0N05xT3lP?= =?utf-8?B?TkxhZUZmWUpDT3Z0aTJhb2xxM3ZacTFDMDZsVCsxVkVKL25KbkNRbDN5U0Zi?= =?utf-8?B?RDlSbnNTd3p6SUc1NE1EV09oLytPV0JoaGI2QnJyMXFINFhrbmVIMjEvMFg4?= =?utf-8?B?NitNMUlYKzlKZGNCcmNxSGtzTUFveHZaV214SnN6QjI4SzJzdWJUdzlnU1F1?= =?utf-8?B?a1BHU0VvRVRScFRlZGZwRFluVWhyNjRMVGNRZlR5WlkvK1pKd2VVaHRTSVZU?= =?utf-8?B?REdOTGdkWXlEUm1GbWR0alh4TW1UL2J6RTFPSlQ3UkVUSW9hWmFDdlJVMjlv?= =?utf-8?B?WnozbTBzdW55ellaTWQwSk9yMHg5dWJta2ZobmJPVUJJdFc4R0xaczZZZkc1?= =?utf-8?B?dDcvdWwzWlhINUpPd04xL3o4WUgwNk1UUjRZTUhBK3RZNm00bDVTdm9yUzJX?= =?utf-8?B?NERHMWFGVXNCSzR6WjFhZU9NYUdxSUlHYzBFUFJQRnlaNjU2M1hncUgvaFdS?= =?utf-8?B?blV4am1KOG8yVjdEY2l6SndIZ1dJeEhmTC9zT21NRTNvQzVuQ2RxMXh0Y2kv?= =?utf-8?B?YWRKdDVGNVVEU3ZmQUtaU2FYRlovaGNrVTlCR1oyZmVVVEd4Nzg0LzZhT3Qx?= =?utf-8?B?azZ3WG1odWtydkc3bkFZNGVVMi94aHkva1l5SlBxODkrSEZmQ3pnWHRMQTdW?= =?utf-8?B?RlJYQ2tGby9weW9odnpETGJoQXBmMzVFdlNQWFYzZ2M5S21ZRGpkY1NZRkR1?= =?utf-8?B?clA2WjZuWWpDWFlzZXpYTmhtM2hFVEN6SUlBMkFKUUw3OGFQN3BYdmlINTRp?= =?utf-8?B?alZFU0VFdm1qWmtqUzl4MXVad1NpRWo2UGpVT3RLeU9UYU1BaWJmV282TmRL?= =?utf-8?B?TkJBY2theEN6SUVSM2xRSkc1Wlljb1NKQ3dkVk5RUEFNR1RNMVUvcE92REtZ?= =?utf-8?B?ZW5aSE1Cb0dIZVVYRmtVSzBhdlFsOFhlaWxHUStod09VMnFIdnFCR1hFeis5?= =?utf-8?B?SkN3dk4zVWp0QmJJQUhROXl5QVQ1eGsxOER2TmJEY2RvcTZNSkFOdXplYVFi?= =?utf-8?B?NkU3bXBtY3Uxb0Q1WUl3UkVvSFE4S0FTalVna2RGemZUSWZpOVIyRkNlcUxh?= =?utf-8?B?WCtjR2xVdmthUEQ1dTNPNzRvSFdnYkxhdHVRbzRCbW1KMExKVTBJU0puU3li?= =?utf-8?Q?/r/TLVZqNW/N6ElH6N?= MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB7622.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2f6c0d24-2555-42ba-f12b-08d997b0f644 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2021 12:14:15.0212 (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: qNms8jRuZ73rw9vCZBAy7jZ1GFuZ6l26rR86ZfuWn0ejFART5fmioV0wwnCbJMwuSFAUe9siOUMWP8BVe0fP2HbWyiXD3GAJBcmew/hghn8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7831 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquidtelecom.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_AS8PR03MB7622E1171919EA7717F414E7EE839AS8PR03MB7622eurp_" Archived-At: Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 25 Oct 2021 12:14:29 -0000 --_000_AS8PR03MB7622E1171919EA7717F414E7EE839AS8PR03MB7622eurp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 VGVkLA0KDQpJIGRvbuKAmXQgdGhpbmsgYW55b25lIHdvdWxkIGRpc3B1dGUgdGhhdCBzdXBwbGVt ZW50YXJ5IGluZm9ybWF0aW9uIGlzIG5lY2Vzc2FyeSBmb3IgdmFyaW91cyBwdXJwb3Nlcy4gIFRo ZSBxdWVzdGlvbiBiZWNvbWVzIOKAkyBob3cgbXVjaCBzdXBwbGVtZW50YXJ5IGluZm9ybWF0aW9u IOKAkyB3aGVyZSB0aGF0IHN1cHBsZW1lbnRhcnkgaW5mb3JtYXRpb24gaXMgY29taW5nIGZyb20g 4oCTIGFuZCBob3cgbXVjaCBjb3JyZWxhdGlvbiB5b3UgbmVlZCB0byBkbyB0byBnZXQgdG8gbWVh bmluZ2Z1bCBpbmZvcm1hdGlvbi4NCg0KRWFjaCB0aW1lIHlvdSBhZGQgYSBzdGVwIGluIHRoaXMg cHJvY2VzcyBhbmQgZm9yY2UgYW4gYWRkaXRpb25hbCBwaWVjZSBvZiBpbmZvcm1hdGlvbiBpbnRv IHRoZSBjaGFpbiB0byBtYWtlIHNvbWV0aGluZyBtb3JlIHVzZWZ1bCwgeW91IGluY3JlYXNlIGNv bXBsZXhpdHkgYW5kIHlvdSBjcmVhdGUgYSBzaXR1YXRpb24gd2hlcmUgZGVidWdnaW5nIGFuZCB0 cmFjaW5nIGFuZCBvdGhlciBzdWNoIHRoaW5ncyBiZWNvbWUgbW9yZSBhbmQgbW9yZSByZWxpYW50 IG9uIGV4dGVybmFsIHNvZnR3YXJlIGFuZCByb3V0aW5lcy4gIFRoaXMgaW4gdHVybiBpbmNyZWFz ZXMgY29zdCBhbmQgZGVjcmVhc2VzIHRoZSBhYmlsaXR5IG9mIG9wZXJhdG9ycyB0byBoYW5kbGUg dGhpcyBpbiB0aGUgYWJzZW5jZSBvZiBjb21wbGV4IHRvb2xzLiAgU28gc3VyZSwgZm9yIHRoZSB2 ZW5kb3JzLCBpdCBtYXkgYmUgaW4gdGhlaXIgYWR2YW50YWdlIHRvIGludHJvZHVjZSBtb3JlIGFu ZCBtb3JlIGNvbXBsZXhpdHkgdG8gZm9yY2UgbW9yZSBhbmQgbW9yZSBzb2Z0d2FyZSwgYnV0IHRo aXMgaXMgdmVyeSBtdWNoIG5vdCBpbiB0aGUgaW50ZXJlc3RzIG9mIHRoZSBvcGVyYXRvcnMuDQoN Ckl0J3MgaGVyZSB3aGVyZSBJIHRoaW5rIHdlIG9mdGVuIGVuZCB1cCBpbiBhIGRpdmVyZ2VuY2Ug YmV0d2VlbiBwcmFjdGljYWwgb3BlcmF0aW9uIGFuZCBmYW5jeSBpZGVhcyDigJMgYW5kIGJldHdl ZW4gdmVuZG9ycyBhbmQgb3BlcmF0b3JzLiAgRnJvbSB0aGUgb3BlcmF0b3IgcGVyc3BlY3RpdmUs IHRoYXQgd2hpY2ggaXMgc2ltcGxlciBhbmQgbWFrZXMgaXQgZWFzaWVyIHRvIGhhdmUgdGhlaXIg b3duIGVuZ2luZWVycyBvcGVyYXRlIGl0LCBkZWJ1ZyBpdCBhbmQgcnVuIGl0LCB3aXRob3V0IHNw ZW5kaW5nIG1pbGxpb25zIG9uIHRvb2xzLCBtYWtlcyBhIGxvdCBvZiBzZW5zZS4gIFRoZSByZXZl cnNlIGluIHRydWUgaW4gdGhlIHZlbmRvciB3b3JsZCDigJMgd2hlcmUgY29tcGxleGl0eSBzZXJ2 ZXMgdG8gaW5jcmVhc2UgcmV2ZW51ZXMgKHRob3VnaCBvZnRlbiBlbmRzIHVwIGluIG9wZXJhdG9y cyBoYXZpbmcgdG8gY2hvb3NlIGJldHdlZW4gaW52ZXN0bWVudCBpbiBuZXR3b3JrIGhhcmR3YXJl IHZzIGludmVzdG1lbnQgaW4gdmVuZG9yIHRvb2xzIHRvIHJ1biBzYWlkIG5ldHdvcmspDQoNCk5v dywgaXMgdGhpcyBhbiBhcmd1bWVudCB0aGF0IGlzIOKAnHRlY2huaWNhbGx5IHJlbGV2YW504oCd IGluIHRlcm1zIG9mIGFuIElFVEYgc3RhbmRhcmQg4oCTIG1hbnkgd291bGQgYXJndWUgbm8g4oCT IGJ1dCB0aGVyZSBhcmUgdmVyeSBwcmFjdGljYWwgY29uc2lkZXJhdGlvbnMgaGVyZSB3aGVuIGNv bnNpZGVyaW5nIGhvdyBhIHN0YW5kYXJkIHdpbGwgYmUgdXNlZCBhbmQgZGVwbG95ZWQuICBUaGUg bGV2ZWwgb2YgY29tcGxleGl0eSBhbmQgbGFjayBvZiBkZWJ1Z2dhYmlsaXR5IGFuZCB0aGUgb2Jm dXNjYXRpb24gdGhhdCBJIHNlZSBpbiBhbGwgb2YgdGhpcywgaXMgdGhlIHNhbWUgY29uY2VybiB0 aGF0IEkgYW0gc2VlaW5nIGVjaG9lZCBpbiBldmVyeSBOT0cgbWVldGluZyBJIGFtIGluIOKAkyBh bmQgd2hpbGUgaXQgbWF5IG5vdCBiZSBkaXJlY3RseSByZWxldmFudCB0byB0aGUgdGV4dCBpbiBh IGRvY3VtZW50LCBpdCBkb2VzIGNhcnJ5IHJlbGV2YW5jZSB0byB0aGUgZW5kIHVzZXJzIG9mIHRo ZSBwcm90b2NvbCDigJMgdGhlIG9wZXJhdG9ycy4NCg0KVGhlcmUgaXMgaW4gZXNzZW5jZSDigJMg YSBjb21tZXJjaWFsIGNvbmZsaWN0IGJldHdlZW4gdGhlc2UgdHdvIHRoaW5ncyDigJMgd2hpY2gg aXMgb3V0c2lkZSBvZiB0aGUgcmVhbG0gb2YgdGhlIElFVEYg4oCTIGJ1dCDigJMgdW5sZXNzIHdl IGNhbiBmaW5kIGhhcm1vbml6YXRpb24gYmV0d2VlbiB0aGUgb3BlcmF0b3JzIGFuZCB0aGUgdmVu ZG9ycyBvbiBzdWNoIHRoaW5ncywgd2Ugd2lsbCBlbmQgdXAgaW4gZGVlcGVyIGFuZCBkZWVwZXIg c3RhbGVtYXRlcyB0aGF0IGFyZSBub3QgaW4gYW55b25lcyBpbnRlcmVzdHMuICBUaGVyZWZvcmUs IHJlZHVjaW5nIHRoZSBjb21wbGV4aXR5IGludm9sdmVkIGluIGRlYnVnZ2luZyBhbmQgb3BlcmF0 aW5nIHNvbWV0aGluZywgd2lsbCBkZWNyZWFzZSByZXNpc3RhbmNlIGR1cmluZyB0aGUgc3RhbmRh cmRpemF0aW9uIHByb2Nlc3MuICBGdXJ0aGVybW9yZSwgdGhlIG1vcmUgb2JmdXNjYXRlZCB0aGlu Z3MgZ2V0LCBhbmQgdGhlIGRlZXBlciB0aGUgY29tcGxleGl0eSwgdGhlIG1vcmUgY2hhbmNlIG9m IHBpdGZhbGxzIHRoYXQgYXJlIG5vdCBzZWVuIHVudGlsIGl0IGlzIHRvIGxhdGUg4oCTIGFuZCB0 aGUgZ3Jvd2luZyByaXNrIG9mIHNlY3VyaXR5IHByb2JsZW1zIHRoYXQgY291bGQgbm90IGJlIGZv cmVzZWVuIHVudGlsIHdlIGhhdmUgcHVzaGVkIHNvbWV0aGluZyB3aWRlbHkgaW50byB0aGUgZmll bGQuDQoNCkFuZHJldw0KDQoNCkZyb206IFRlZCBIYXJkaWUgPHRlZC5pZXRmQGdtYWlsLmNvbT4N ClNlbnQ6IE1vbmRheSwgT2N0b2JlciAyNSwgMjAyMSAxOjM3IFBNDQpUbzogQW5kcmV3IEFsc3Rv biA8QW5kcmV3LkFsc3RvbkBsaXF1aWR0ZWxlY29tLmNvbT4NCkNjOiBFbGlvdCBMZWFyIDxsZWFy QGxlYXIuY2g+OyBOaWNrIEhpbGxpYXJkIDxuaWNrQGZvb2Jhci5vcmc+OyBTUFJJTkcgV0cgTGlz dCA8c3ByaW5nQGlldGYub3JnPjsgNm1hbiBXRyA8aXB2NkBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbc3ByaW5nXSBPYmplY3Rpb24gdG8gd2cgYWRvcHRpb24gY2FsbCBmb3IgZHJhZnQtZmlsc2Zp bHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24gKHdhczogUmU6IFF1ZXN0aW9uIGZy b20gU1BSSU5HIHJlZ2FyZGluZyBkcmFmdC1maWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1j b21wcmVzc2lvbikNCg0KT24gTW9uLCBPY3QgMjUsIDIwMjEgYXQgOTo0NyBBTSBBbmRyZXcgQWxz dG9uIDxBbmRyZXcuQWxzdG9uPTQwbGlxdWlkdGVsZWNvbS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFp bHRvOjQwbGlxdWlkdGVsZWNvbS5jb21AZG1hcmMuaWV0Zi5vcmc+PiB3cm90ZToNCj4gT2YgY291 cnNlIHRoZXJlIGlzLiAgWW91IGNhbm5vdCBkaXN0aW5ndWlzaCByb3V0aW5nIGZyb20gaG9zdCB3 aXRob3V0IGxvb2tpbmcgYXQgZXh0ZXJuYWwgY29udHJvbCBjaGFubmVscywgc3VjaCBhcyBhIHJv dXRpbmcgb3IgY29uZmlndXJhdGlvbiBwcm90b2NvbDsgYW5kIHlvdSBjZXJ0YWlubHkgY2Fubm90 IGRldGVybWluZSB0aGUgc3VibmV0IG1hc2sgb2YgYSBuZXR3b3JrIHdpdGhvdXQgdGhhdCBleHRl cm5hbCBpbmZvcm1hdGlvbiwgc2luY2UgaXQncyBub3QgaW4gdGhlID8+IHBhY2tldC4gIEFuZCBp dCdzIG5vdCBldmVuIGluIHRoZSBjb250cm9sIHBsYW5lIGlmIHRoZSByb3V0ZSBoYXMgYmVlbiBh Z2dyZWdhdGVkLiAgRG9lcyB0aGF0IG1ha2UgdGhlIGluZm9ybWF0aW9uICJhbWJpZ3VvdXMiPyAg VGhlIHBvaW50IGlzIHRoYXQgdGhlIHN1Ym5ldCBtYXNrIG9mIGEgbmV0d29yayBpcyBwYXJ0IG9m IGEgY29udGV4dCB0aGF0IHlvdSBkaXNjdXNzZWQsIGFuZCB5b3UgbWlnaHQgbm90IGhhdmUgaXQu DQoNClRoaXMgYW5hbG9neSBkb2Vzbid0IHJlYWxseSB3b3JrIGZvciBtZS4gIEluIHRoZSBjYXNl IG9mIGFuIFNSSCAtIHRoZSByb3V0ZXIgYWN0cyBvbiB0aGUgcGFja2V0IGJhc2VkIG9uIGxvY2Fs IGNvbmZpZ3VyYXRpb24gLSBob3cgaXQgZ2V0cyB0aGF0IGNvbmZpZyBkb2Vzbid0IHJlYWxseSBt YXR0ZXIuICBUaGUgU0lEIHNpemUgaW4gdXNlIGJ5IGVhY2ggcm91dGVyIG1heSBvciBtYXkgbm90 IGJlIGV4cG9zZWQgYnkgYW4gSUdQIGZvciByZWFkaW5nIC0gYW5kIGNvdWxkIGRpZmZlciBhdCBl YWNoIG5vZGUuDQoNCkkgdGhpbmsgRWxpb3QncyBtYWluIHBvaW50IGlzIHRoYXQgdGhlcmUgYXJl IGFzcGVjdHMgb2YgYSBmbG93J3Mgcm91dGluZyB0aHJvdWdoIGEgbmV0d29yayB3aGljaCBhcmUg b2JzZXJ2YWJsZSBpbiBhIHBhY2tldCBhbmQgdGhlcmUgYXJlIGFzcGVjdHMgd2hpY2ggYXJlIG5v dC4gIFRoaW5rIGFib3V0IGEgbmV0d29yayB3aGljaCBpbXBsZW1lbnRzIGEgZmxvdy1iYXNlZCBl cXVhbC1jb3N0IG11bHRpcGF0aDsgdGhlIGRldGVybWluYXRpb24gb2Ygd2hpY2ggZmxvd3MgdGFr ZSB3aGljaCBwYXRoIHVzZXMgaW5mb3JtYXRpb24gaW4gdGhlIHBhY2tldCBidXQgdGhlIGFsZ29y aXRobSB0aGF0IGhhc2hlcyBpdCB0b2dldGhlciBhbmQgY2hvb3NlcyBhIG5leHQgaG9wIGlzIG5v dC4gIFRoZSBwcmFjdGljZXMgYWJvdXQgd2hhdCB0byBjaG9vc2UgY2FuIHZhcnkgc2lnbmlmaWNh bnRseSBhbmQgdG8gZGVidWcgKG9yIHBsYW4pLCB5b3UgaGF2ZSB0byBrbm93IGEgbG90IG1vcmUg YWJvdXQgdGhlIG5ldHdvcmsgdGhhbiB3aGF0J3MgaW4gdGhlIHBhY2tldCBpdHNlbGYuDQoNCnJl Z2FyZHMsDQoNClRlZCBIYXJkaWUNCg0KDQpJbiB0aGUgY2FzZSBvZiBzdGFuZGFyZCBmb3J3YXJk aW5nIHlvdSBoYXZlIGEgRklCIGVudHJ5IC0gaW5zZXJ0ZWQgZnJvbSB0aGUgUklCIC0gdGhhdCBn b2VzIGEgY2VydGFpbiBwbGFjZS4gIEluIHRoZSBjYXNlIG9mIHRoaXMgLSBhIHJvdXRlciBjb3Vs ZCBiZSB1c2luZyBlaXRoZXIgMTZiaXQgU0lEIG9yIDMyYml0IFNJRCAtIGVudGlyZWx5IGNvbmZp Z3VyZWQgbG9jYWxseSAtIGFuZCBkZXBlbmRlbnQgb24gdGhlIGNvbmZpZ3VyYXRpb24gLSB3aWxs IGRldGVybWluZSBpZiB0aGUgbm9kZSBpbiBxdWVzdGlvbiBzaGlmdHMgdGhlIGluZm9ybWF0aW9u IGJ5IDE2IG9yIDMyIGJpdHMgLSBiZWZvcmUgdGhlIEZJQiBsb29rdXAuDQoNClRoZXJlZm9yZSAt IGluIGEgc3RhbmRhcmQgc2NlbmFyaW8gLSB5b3Uga25vdyB0aGF0IHBhY2tldCBYIGlzIGdvaW5n IHRvIGJlIGZvcndhcmRlZCB1c2luZyBhIEZJQiBlbnRyeSBsb29rdXAgb2YgWSAtIGluIHRoZSBj YXNlIG9mIHRoaXMgLSB5b3UgaGF2ZSBubyBpZGVhIHdoYXQgdGhlIHJvdXRlciBpcyBhY3R1YWxs eSBnb2luZyB0byBiZSBsb29raW5nIHVwIC0gYmVjYXVzZSB5b3UgZG9uJ3Qga25vdyBpZiBpdHMg Z29pbmcgdG8gYmUgZG9pbmcgYSAxNiBvciAzMiBiaXQgc2lkIHdpdGhvdXQga25vd2luZyB0aGUg c3BlY2lmaWMgbG9jYWwgY29uZmlndXJhdGlvbiBvbiB0aGUgcm91dGVyLiAgVGhhdOKAmXMgYSB2 ZXJ5IGRpZmZlcmVudCBsZXZlbCBvZiBjb21wbGV4aXR5IGluIHRlcm1zIG9mIG9wZXJhdGlvbnMg YW5kIGRlYnVnZ2luZyBvbiBhIGxhcmdlIG5ldHdvcmsNCg0KQW5kcmV3DQoNCg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdA0KaXB2NkBpZXRmLm9yZzxt YWlsdG86aXB2NkBpZXRmLm9yZz4NCkFkbWluaXN0cmF0aXZlIFJlcXVlc3RzOiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pcHY2Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg== --_000_AS8PR03MB7622E1171919EA7717F414E7EE839AS8PR03MB7622eurp_ 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 Tm9ybWFsIj5UZWQsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u4oCZdCB0aGluayBhbnlv bmUgd291bGQgZGlzcHV0ZSB0aGF0IHN1cHBsZW1lbnRhcnkgaW5mb3JtYXRpb24gaXMgbmVjZXNz YXJ5IGZvciB2YXJpb3VzIHB1cnBvc2VzLiZuYnNwOyBUaGUgcXVlc3Rpb24gYmVjb21lcyDigJMg aG93IG11Y2ggc3VwcGxlbWVudGFyeSBpbmZvcm1hdGlvbiDigJMgd2hlcmUgdGhhdCBzdXBwbGVt ZW50YXJ5IGluZm9ybWF0aW9uIGlzIGNvbWluZyBmcm9tIOKAkyBhbmQgaG93IG11Y2ggY29ycmVs YXRpb24NCiB5b3UgbmVlZCB0byBkbyB0byBnZXQgdG8gbWVhbmluZ2Z1bCBpbmZvcm1hdGlvbi48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RWFjaCB0aW1lIHlvdSBhZGQgYSBzdGVwIGluIHRoaXMg cHJvY2VzcyBhbmQgZm9yY2UgYW4gYWRkaXRpb25hbCBwaWVjZSBvZiBpbmZvcm1hdGlvbiBpbnRv IHRoZSBjaGFpbiB0byBtYWtlIHNvbWV0aGluZyBtb3JlIHVzZWZ1bCwgeW91IGluY3JlYXNlIGNv bXBsZXhpdHkgYW5kIHlvdSBjcmVhdGUgYSBzaXR1YXRpb24gd2hlcmUgZGVidWdnaW5nIGFuZCB0 cmFjaW5nIGFuZCBvdGhlciBzdWNoIHRoaW5ncyBiZWNvbWUNCiBtb3JlIGFuZCBtb3JlIHJlbGlh bnQgb24gZXh0ZXJuYWwgc29mdHdhcmUgYW5kIHJvdXRpbmVzLiZuYnNwOyBUaGlzIGluIHR1cm4g aW5jcmVhc2VzIGNvc3QgYW5kIGRlY3JlYXNlcyB0aGUgYWJpbGl0eSBvZiBvcGVyYXRvcnMgdG8g aGFuZGxlIHRoaXMgaW4gdGhlIGFic2VuY2Ugb2YgY29tcGxleCB0b29scy4mbmJzcDsgU28gc3Vy ZSwgZm9yIHRoZSB2ZW5kb3JzLCBpdCBtYXkgYmUgaW4gdGhlaXIgYWR2YW50YWdlIHRvIGludHJv ZHVjZSBtb3JlIGFuZCBtb3JlDQogY29tcGxleGl0eSB0byBmb3JjZSBtb3JlIGFuZCBtb3JlIHNv ZnR3YXJlLCBidXQgdGhpcyBpcyB2ZXJ5IG11Y2ggbm90IGluIHRoZSBpbnRlcmVzdHMgb2YgdGhl IG9wZXJhdG9ycy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQncyBoZXJlIHdoZXJlIEkgdGhp bmsgd2Ugb2Z0ZW4gZW5kIHVwIGluIGEgZGl2ZXJnZW5jZSBiZXR3ZWVuIHByYWN0aWNhbCBvcGVy YXRpb24gYW5kIGZhbmN5IGlkZWFzIOKAkyBhbmQgYmV0d2VlbiB2ZW5kb3JzIGFuZCBvcGVyYXRv cnMuJm5ic3A7IEZyb20gdGhlIG9wZXJhdG9yIHBlcnNwZWN0aXZlLCB0aGF0IHdoaWNoIGlzIHNp bXBsZXIgYW5kIG1ha2VzIGl0IGVhc2llciB0byBoYXZlIHRoZWlyIG93biBlbmdpbmVlcnMNCiBv cGVyYXRlIGl0LCBkZWJ1ZyBpdCBhbmQgcnVuIGl0LCB3aXRob3V0IHNwZW5kaW5nIG1pbGxpb25z IG9uIHRvb2xzLCBtYWtlcyBhIGxvdCBvZiBzZW5zZS4mbmJzcDsgVGhlIHJldmVyc2UgaW4gdHJ1 ZSBpbiB0aGUgdmVuZG9yIHdvcmxkIOKAkyB3aGVyZSBjb21wbGV4aXR5IHNlcnZlcyB0byBpbmNy ZWFzZSByZXZlbnVlcyAodGhvdWdoIG9mdGVuIGVuZHMgdXAgaW4gb3BlcmF0b3JzIGhhdmluZyB0 byBjaG9vc2UgYmV0d2VlbiBpbnZlc3RtZW50IGluIG5ldHdvcmsNCiBoYXJkd2FyZSB2cyBpbnZl c3RtZW50IGluIHZlbmRvciB0b29scyB0byBydW4gc2FpZCBuZXR3b3JrKTxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Ob3csIGlzIHRoaXMgYW4gYXJndW1lbnQgdGhhdCBpcyDigJx0ZWNobmljYWxs eSByZWxldmFudOKAnSBpbiB0ZXJtcyBvZiBhbiBJRVRGIHN0YW5kYXJkIOKAkyBtYW55IHdvdWxk IGFyZ3VlIG5vIOKAkyBidXQgdGhlcmUgYXJlIHZlcnkgcHJhY3RpY2FsIGNvbnNpZGVyYXRpb25z IGhlcmUgd2hlbiBjb25zaWRlcmluZyBob3cgYSBzdGFuZGFyZCB3aWxsIGJlIHVzZWQgYW5kIGRl cGxveWVkLiZuYnNwOyBUaGUgbGV2ZWwgb2YgY29tcGxleGl0eQ0KIGFuZCBsYWNrIG9mIGRlYnVn Z2FiaWxpdHkgYW5kIHRoZSBvYmZ1c2NhdGlvbiB0aGF0IEkgc2VlIGluIGFsbCBvZiB0aGlzLCBp cyB0aGUgc2FtZSBjb25jZXJuIHRoYXQgSSBhbSBzZWVpbmcgZWNob2VkIGluIGV2ZXJ5IE5PRyBt ZWV0aW5nIEkgYW0gaW4g4oCTIGFuZCB3aGlsZSBpdCBtYXkgbm90IGJlIGRpcmVjdGx5IHJlbGV2 YW50IHRvIHRoZSB0ZXh0IGluIGEgZG9jdW1lbnQsIGl0IGRvZXMgY2FycnkgcmVsZXZhbmNlIHRv IHRoZSBlbmQgdXNlcnMNCiBvZiB0aGUgcHJvdG9jb2wg4oCTIHRoZSBvcGVyYXRvcnMuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGlzIGluIGVzc2VuY2Ug4oCTIGEgY29tbWVyY2lhbCBj b25mbGljdCBiZXR3ZWVuIHRoZXNlIHR3byB0aGluZ3Mg4oCTIHdoaWNoIGlzIG91dHNpZGUgb2Yg dGhlIHJlYWxtIG9mIHRoZSBJRVRGIOKAkyBidXQg4oCTIHVubGVzcyB3ZSBjYW4gZmluZCBoYXJt b25pemF0aW9uIGJldHdlZW4gdGhlIG9wZXJhdG9ycyBhbmQgdGhlIHZlbmRvcnMgb24gc3VjaCB0 aGluZ3MsIHdlIHdpbGwgZW5kIHVwIGluIGRlZXBlciBhbmQNCiBkZWVwZXIgc3RhbGVtYXRlcyB0 aGF0IGFyZSBub3QgaW4gYW55b25lcyBpbnRlcmVzdHMuJm5ic3A7IFRoZXJlZm9yZSwgcmVkdWNp bmcgdGhlIGNvbXBsZXhpdHkgaW52b2x2ZWQgaW4gZGVidWdnaW5nIGFuZCBvcGVyYXRpbmcgc29t ZXRoaW5nLCB3aWxsIGRlY3JlYXNlIHJlc2lzdGFuY2UgZHVyaW5nIHRoZSBzdGFuZGFyZGl6YXRp b24gcHJvY2Vzcy4mbmJzcDsgRnVydGhlcm1vcmUsIHRoZSBtb3JlIG9iZnVzY2F0ZWQgdGhpbmdz IGdldCwgYW5kIHRoZSBkZWVwZXINCiB0aGUgY29tcGxleGl0eSwgdGhlIG1vcmUgY2hhbmNlIG9m IHBpdGZhbGxzIHRoYXQgYXJlIG5vdCBzZWVuIHVudGlsIGl0IGlzIHRvIGxhdGUg4oCTIGFuZCB0 aGUgZ3Jvd2luZyByaXNrIG9mIHNlY3VyaXR5IHByb2JsZW1zIHRoYXQgY291bGQgbm90IGJlIGZv cmVzZWVuIHVudGlsIHdlIGhhdmUgcHVzaGVkIHNvbWV0aGluZyB3aWRlbHkgaW50byB0aGUgZmll bGQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFuZHJldzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBUZWQgSGFyZGllICZsdDt0ZWQuaWV0ZkBnbWFp bC5jb20mZ3Q7IDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE9jdG9iZXIgMjUsIDIwMjEgMToz NyBQTTxicj4NCjxiPlRvOjwvYj4gQW5kcmV3IEFsc3RvbiAmbHQ7QW5kcmV3LkFsc3RvbkBsaXF1 aWR0ZWxlY29tLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IEVsaW90IExlYXIgJmx0O2xlYXJAbGVh ci5jaCZndDs7IE5pY2sgSGlsbGlhcmQgJmx0O25pY2tAZm9vYmFyLm9yZyZndDs7IFNQUklORyBX RyBMaXN0ICZsdDtzcHJpbmdAaWV0Zi5vcmcmZ3Q7OyA2bWFuIFdHICZsdDtpcHY2QGlldGYub3Jn Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NwcmluZ10gT2JqZWN0aW9uIHRvIHdnIGFk b3B0aW9uIGNhbGwgZm9yIGRyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXBy ZXNzaW9uICh3YXM6IFJlOiBRdWVzdGlvbiBmcm9tIFNQUklORyByZWdhcmRpbmcgZHJhZnQtZmls c2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24pPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxOC4wcHQiPk9uIE1vbiwgT2N0IDI1LCAyMDIxIGF0IDk6NDcgQU0gQW5kcmV3IEFsc3RvbiAm bHQ7QW5kcmV3LkFsc3Rvbj08YSBocmVmPSJtYWlsdG86NDBsaXF1aWR0ZWxlY29tLmNvbUBkbWFy Yy5pZXRmLm9yZyI+NDBsaXF1aWR0ZWxlY29tLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6 MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgT2YgY291cnNlIHRoZXJlIGlzLiZuYnNw OyBZb3UgY2Fubm90IGRpc3Rpbmd1aXNoIHJvdXRpbmcgZnJvbSBob3N0IHdpdGhvdXQgbG9va2lu ZyBhdCBleHRlcm5hbCBjb250cm9sIGNoYW5uZWxzLCBzdWNoIGFzIGEgcm91dGluZyBvciBjb25m aWd1cmF0aW9uIHByb3RvY29sOyBhbmQgeW91IGNlcnRhaW5seSBjYW5ub3QgZGV0ZXJtaW5lIHRo ZSBzdWJuZXQgbWFzayBvZiBhIG5ldHdvcmsgd2l0aG91dCB0aGF0IGV4dGVybmFsDQogaW5mb3Jt YXRpb24sIHNpbmNlIGl0J3Mgbm90IGluIHRoZSA/Jmd0OyBwYWNrZXQuJm5ic3A7IEFuZCBpdCdz IG5vdCBldmVuIGluIHRoZSBjb250cm9sIHBsYW5lIGlmIHRoZSByb3V0ZSBoYXMgYmVlbiBhZ2dy ZWdhdGVkLiZuYnNwOyBEb2VzIHRoYXQgbWFrZSB0aGUgaW5mb3JtYXRpb24gJnF1b3Q7YW1iaWd1 b3VzJnF1b3Q7PyZuYnNwOyBUaGUgcG9pbnQgaXMgdGhhdCB0aGUgc3VibmV0IG1hc2sgb2YgYSBu ZXR3b3JrIGlzIHBhcnQgb2YgYSBjb250ZXh0IHRoYXQgeW91IGRpc2N1c3NlZCwgYW5kDQogeW91 IG1pZ2h0IG5vdCBoYXZlIGl0Ljxicj4NCjxicj4NClRoaXMgYW5hbG9neSBkb2Vzbid0IHJlYWxs eSB3b3JrIGZvciBtZS4mbmJzcDsgSW4gdGhlIGNhc2Ugb2YgYW4gU1JIIC0gdGhlIHJvdXRlciBh Y3RzIG9uIHRoZSBwYWNrZXQgYmFzZWQgb24gbG9jYWwgY29uZmlndXJhdGlvbiAtIGhvdyBpdCBn ZXRzIHRoYXQgY29uZmlnIGRvZXNuJ3QgcmVhbGx5IG1hdHRlci4mbmJzcDsgVGhlIFNJRCBzaXpl IGluIHVzZSBieSBlYWNoIHJvdXRlciBtYXkgb3IgbWF5IG5vdCBiZSBleHBvc2VkIGJ5IGFuIElH UCBmb3IgcmVhZGluZw0KIC0gYW5kIGNvdWxkIGRpZmZlciBhdCBlYWNoIG5vZGUuJm5ic3A7IDxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTguMHB0Ij5JIHRoaW5rIEVsaW90J3Mg bWFpbiBwb2ludCBpcyB0aGF0IHRoZXJlIGFyZSBhc3BlY3RzIG9mIGEgZmxvdydzIHJvdXRpbmcg dGhyb3VnaCBhIG5ldHdvcmsgd2hpY2ggYXJlIG9ic2VydmFibGUgaW4gYSBwYWNrZXQgYW5kIHRo ZXJlIGFyZSBhc3BlY3RzIHdoaWNoIGFyZSBub3QuJm5ic3A7IFRoaW5rIGFib3V0IGEgbmV0d29y ayB3aGljaCBpbXBsZW1lbnRzIGEgZmxvdy1iYXNlZA0KIGVxdWFsLWNvc3QgbXVsdGlwYXRoOyB0 aGUgZGV0ZXJtaW5hdGlvbiBvZiB3aGljaCBmbG93cyB0YWtlIHdoaWNoIHBhdGggdXNlcyBpbmZv cm1hdGlvbiBpbiB0aGUgcGFja2V0IGJ1dCB0aGUgYWxnb3JpdGhtIHRoYXQgaGFzaGVzIGl0IHRv Z2V0aGVyIGFuZCBjaG9vc2VzIGEgbmV4dCBob3AgaXMgbm90LiZuYnNwOyBUaGUgcHJhY3RpY2Vz IGFib3V0IHdoYXQgdG8gY2hvb3NlIGNhbiB2YXJ5IHNpZ25pZmljYW50bHkgYW5kIHRvIGRlYnVn IChvciBwbGFuKSwNCiB5b3UgaGF2ZSB0byBrbm93IGEgbG90IG1vcmUgYWJvdXQgdGhlIG5ldHdv cmsgdGhhbiB3aGF0J3MgaW4gdGhlIHBhY2tldCBpdHNlbGYuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjE4LjBwdCI+cmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE4LjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxOC4wcHQiPlRlZCBIYXJkaWU8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J biB0aGUgY2FzZSBvZiBzdGFuZGFyZCBmb3J3YXJkaW5nIHlvdSBoYXZlIGEgRklCIGVudHJ5IC0g aW5zZXJ0ZWQgZnJvbSB0aGUgUklCIC0gdGhhdCBnb2VzIGEgY2VydGFpbiBwbGFjZS4mbmJzcDsg SW4gdGhlIGNhc2Ugb2YgdGhpcyAtIGEgcm91dGVyIGNvdWxkIGJlIHVzaW5nIGVpdGhlciAxNmJp dCBTSUQgb3IgMzJiaXQgU0lEIC0gZW50aXJlbHkgY29uZmlndXJlZCBsb2NhbGx5IC0gYW5kIGRl cGVuZGVudCBvbiB0aGUNCiBjb25maWd1cmF0aW9uIC0gd2lsbCBkZXRlcm1pbmUgaWYgdGhlIG5v ZGUgaW4gcXVlc3Rpb24gc2hpZnRzIHRoZSBpbmZvcm1hdGlvbiBieSAxNiBvciAzMiBiaXRzIC0g YmVmb3JlIHRoZSBGSUIgbG9va3VwLiZuYnNwOw0KPGJyPg0KPGJyPg0KVGhlcmVmb3JlIC0gaW4g YSBzdGFuZGFyZCBzY2VuYXJpbyAtIHlvdSBrbm93IHRoYXQgcGFja2V0IFggaXMgZ29pbmcgdG8g YmUgZm9yd2FyZGVkIHVzaW5nIGEgRklCIGVudHJ5IGxvb2t1cCBvZiBZIC0gaW4gdGhlIGNhc2Ug b2YgdGhpcyAtIHlvdSBoYXZlIG5vIGlkZWEgd2hhdCB0aGUgcm91dGVyIGlzIGFjdHVhbGx5IGdv aW5nIHRvIGJlIGxvb2tpbmcgdXAgLSBiZWNhdXNlIHlvdSBkb24ndCBrbm93IGlmIGl0cyBnb2lu ZyB0byBiZSBkb2luZw0KIGEgMTYgb3IgMzIgYml0IHNpZCB3aXRob3V0IGtub3dpbmcgdGhlIHNw ZWNpZmljIGxvY2FsIGNvbmZpZ3VyYXRpb24gb24gdGhlIHJvdXRlci4mbmJzcDsgVGhhdOKAmXMg YSB2ZXJ5IGRpZmZlcmVudCBsZXZlbCBvZiBjb21wbGV4aXR5IGluIHRlcm1zIG9mIG9wZXJhdGlv bnMgYW5kIGRlYnVnZ2luZyBvbiBhIGxhcmdlIG5ldHdvcms8YnI+DQo8YnI+DQpBbmRyZXc8YnI+ DQo8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCklFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzppcHY2QGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+aXB2NkBpZXRmLm9yZzwvYT48YnI+DQpBZG1pbmlzdHJhdGl2ZSBSZXF1ZXN0czogPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2IiB0YXJnZXQ9 Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8L2E+ PGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_AS8PR03MB7622E1171919EA7717F414E7EE839AS8PR03MB7622eurp_-- From nobody Mon Oct 25 05:35:51 2021 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 263EE3A0AC4; Mon, 25 Oct 2021 05:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-3.33, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch 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 EDqsOov50uAW; Mon, 25 Oct 2021 05:35:38 -0700 (PDT) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 98A273A0AA7; Mon, 25 Oct 2021 05:35:38 -0700 (PDT) Received: from [IPV6:2001:420:c0c0:1011::1] ([IPv6:2001:420:c0c0:1011:0:0:0:1]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 19PCZQVh3980094 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 25 Oct 2021 14:35:27 +0200 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1635165328; bh=lU+qVmKJwgKilY2B3SR502emlJcrgc7s/XE1N8y1Dtc=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=Ss5LBtSKmjPE3DGy7Ng4QIFx7f5GFW1RDmuYFXh5by7Gp9RxsR/k0ptXv8WlKMZPJ hWg1PGD3wIzG+r3CJB5nWBpxfKt49h/uXB4BqUa7aAhkN6SHEHiggKnIOeMRTCM2la kdjXszd5/m48HdZpkJhXxGlHFwszoQlQ3SD7KArE= Message-ID: Date: Mon, 25 Oct 2021 14:35:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Content-Language: en-US To: Andrew Alston , Ted Hardie Cc: Nick Hilliard , SPRING WG List , 6man WG References: <89c62864-feb4-550e-2d63-264b2ecc3344@lear.ch> <8bf003b2-988d-6d6c-f080-519596a3b1ac@foobar.org> From: Eliot Lear In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------0hOSrnZ2yNY4H00p91FEprQf" Archived-At: Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 25 Oct 2021 12:35:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------0hOSrnZ2yNY4H00p91FEprQf Content-Type: multipart/mixed; boundary="------------CcTKu5zWOibNHhSi5UEJ91El"; protected-headers="v1" From: Eliot Lear To: Andrew Alston , Ted Hardie Cc: Nick Hilliard , SPRING WG List , 6man WG Message-ID: Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) References: <89c62864-feb4-550e-2d63-264b2ecc3344@lear.ch> <8bf003b2-988d-6d6c-f080-519596a3b1ac@foobar.org> In-Reply-To: --------------CcTKu5zWOibNHhSi5UEJ91El Content-Type: multipart/mixed; boundary="------------ScKwnx4nU5xAe31qF4vPmsMv" --------------ScKwnx4nU5xAe31qF4vPmsMv Content-Type: multipart/alternative; boundary="------------8Y50GRPQP6BwgPEef28jT8sq" --------------8Y50GRPQP6BwgPEef28jT8sq Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SGkgQW5kcmV3LA0KDQpJIGRvbid0IGRpc2FncmVlIHdpdGggeW91ciBwb2ludCB0aGF0IG9w ZXJhdGlvbmFsIGNvbXBsZXhpdHkgaGluZGVycyANCmFkb3B0aW9uLsKgIEhvd2V2ZXIuLi4N Cg0KT24gMjUuMTAuMjEgMTQ6MTQsIEFuZHJldyBBbHN0b24gd3JvdGU6DQo+DQo+IEl0J3Mg aGVyZSB3aGVyZSBJIHRoaW5rIHdlIG9mdGVuIGVuZCB1cCBpbiBhIGRpdmVyZ2VuY2UgYmV0 d2VlbiANCj4gcHJhY3RpY2FsIG9wZXJhdGlvbiBhbmQgZmFuY3kgaWRlYXMNCj4NClRoZSBw cm9ibGVtIGlzIHRoYXQgb25lIG9mdGVuIGNhbid0IHRlbGwgdGhlIGRpZmZlcmVuY2UgYmV0 d2VlbiB0aGUgdHdvIA0Kd2l0aG91dCB0aGUgYmVuZWZpdCBvZiBoaW5kc2lnaHQsIGFuZCBw ZXJoYXBzIHNldmVyYWwgcmV2cyBvZiB0aGUgc3BlYy7CoCANCklQdjYgaXRzZWxmIGlzIGEg cGVyZmVjdCBleGFtcGxlIG9mIHRoYXQgdHJ1dGggKGNmLCBNSVB2Niwgc2l0ZS1sb2NhbCwg DQpJUHNlYyByZXF1aXJlbWVudHMsIGFuZCBnZW9ncmFwaGljIHJvdXRpbmcpLiBCdXQgSSB3 cml0ZSB0aGF0IHdpdGggdGhlIA0KYmVuZWZpdCBvZiBoaW5kc2lnaHQgaW4gd2hpY2ggd2Ug ZGlkIGZpbmQgdXNlIGZvciBvdGhlciB2NiBmZWF0dXJlcywgDQpsaWtlIGZsb3cgbGFiZWxz Lg0KDQpSaWdodCBub3cgd2UgaGF2ZSBhIGxvdCBvZiBzcGVjdWxhdGlvbiBhYm91dCBob3cg dG9vbHMgd29uJ3QgZXZvbHZlIHRvIA0KYXNzaXN0IG9wZXJhdG9ycywgYW5kIEknbSBzeW1w YXRoZXRpYyB0byB0aGF0IHRvIGEgcG9pbnQ6IHRvb2xzIGRldmVsb3AgDQpiZXN0IG91dCBv ZiBvcGVyYXRpb25hbCBleHBlcmllbmNlLg0KDQpFbGlvdA0KDQoNCg== --------------8Y50GRPQP6BwgPEef28jT8sq Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

    Hi Andrew,

    I don't disagree with your point that operational complexity hinders adoption.=C2=A0 However...

    On 25.10.21 14:14, Andrew Alston wrote= :

    It's here where I think we often end up in a= divergence between practical operation and fancy ideas

    The problem is that one often can't tell the difference between the two without the benefit of hindsight, and perhaps several revs of the spec.=C2=A0 IPv6 itself is a perfect example of that truth (= cf, MIPv6, site-local, IPsec requirements, and geographic routing).=C2=A0= But I write that with the benefit of hindsight in which we did find use for other v6 features, like flow labels.

    Right now we have a lot of speculation about how tools won't evolve to assist operators, and I'm sympathetic to that to a point: tools develop best out of operational experience.

    Eliot


    --------------8Y50GRPQP6BwgPEef28jT8sq-- --------------ScKwnx4nU5xAe31qF4vPmsMv Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clTl= pVL ciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ9NcML= lD8 raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv5= 4oH 0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gC= tCj fvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlY= XIg PGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY0L2QR= h2w kqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCHtmtG2dJ6MyMyCACXv= tFj AYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA1U/OlZux+P/NaVMiZNZc8zw0nsx/I= NAq DOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyM= Jz+ GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0= MyS k1D5A7FdwDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM= +E5 C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMabGguI183qWgCcD= Bjq DmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxqYVx7wkYEEhECAAYFAlMfD7kAC= gkQ bSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A42U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3w= sBi BBMBCgAMBQJTIsh+BYMHhh+AAAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6Mqf= XAa hQt8ES3b9hXNKDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS= 5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc9XvabUOhC= Bb5 z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvSsIH63pw7GN5jhtURktWpm= /vX qNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucjhC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4= TTr Om5YWFbCRgQTEQIABgUCVxX/yAAKCRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMW= QCg iVjlI3bzSuDrqtOOWMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTA= QIA OAIbAwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoLAgQWA= gMB AAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVTt/GJX1CabzWSsAPO8= VAy 39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1MuU6AQBqepeAgieyaN5CMk5fyQj6T= mHe UhOWi8F6dk5cz2HbU4tPxQaMu8fi/1njRlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSy= UFh Z6Ic018VoddI0RZYNDBmfvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX42= 4Yi 9jgbZYdEEo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUCU= x8P rgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1zmVoE9701OnCD= bAf UOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJFO1KoP297EClcJRuMb2XIQCdG= q6D 9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUCUx7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSl= BST A9OAMkal7Qt4YgCdEzmwSiZOIahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AAC= gkQ xA2RF02ZCBD74ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlh= Oqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/FapcnAPZwKna= bXo zei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ/R3AMQJYmEvCFdUw8Pntm= 65U +cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoIrkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0S= c5i mFHHmb/U6j/QEvkrjCwAWYAeavOjU+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MA= AoJ EG6AD2cTbjy4Y0oAoJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUd= sLB cwQQAQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP/iaM1= GyO gKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxwjgV4MGLTRCfkKoBh5= vsF jCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0LtkkJ/rjvAnMYNNs/q6H4deNNg+yNs4X= eWX PxfGEZQxPdX58eGfY2P9OJPbxNqwX1pFkF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvY= vnt SiAC7T5Ucfe363Zp4/F1BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJH= kcN j3nKfqORMUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOtm= ZCs rf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWamTY+Wx8lOcx8X= WQQ 0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5ya0h9aTtz9cMnfCLHfVL2ZimkS= jsP o0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhdPCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gU= GUH AUhrFFdvM8gf9U/SbdS+BYzL+IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFb= Glv dCBMZWFyIDxsZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh= 7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRayV/uDnJJd= nx0 d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvRecu4R+GArK696HWes6Gr5= 8eV 9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaXXuf8r798Hl1ROJhuHRAA+U/IikuB8/93y= hiU NeaO/Sb/dh4Au0aQrdFmokNG+mnD9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFup= Jsd f/O7UBDayvtzZ+AiUhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5= /CA gDpW7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2Ekady= JJJ F3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgAtFle2HW7/ecWBj4bY= U3Q oQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQNQR+z4CxqBzojzOuTcrEaWfekUVV9= 0zX y5oRjBa+YTzhjXavsXBh1brZsD1fVO2ynlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxw= eoF bTHJF+W7iPadSt321YV3bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdW= LiC UjlgGUPSfaFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7K= 2ox YUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ0nozkrkIANu6d= q2A eyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlMH1JPDr4A3ARKyv25QwDF0M0oN= 7Ke OdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58MhACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCL= zIr o8snIzwLu8cSqZQbNfyBMJg6ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZ= oTD xTpg4SUph+eRywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7= dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------ScKwnx4nU5xAe31qF4vPmsMv-- --------------CcTKu5zWOibNHhSi5UEJ91El-- --------------0hOSrnZ2yNY4H00p91FEprQf Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmF2pIsFAwAAAAAACgkQh7ZrRtnSejOv xgf/W7UChkWWzlDVkSvtSSfKr/Hyj5qJw0vuZRBSMydGe+Xq/2iAjEu3MfL3IELQ7MWDRKY2hlxI oaK2PkGqjnXM8ohd6A//OzelQzUGQDDyJ9t4rL5WXjtBDx0txoRk2USbDe+NULX000CuGAw8LUbC QD96nX4EnAmCzmwJ612yXq8p/9O4sthysZTXZJvbmr5aAZnnGDPkgvtf5Z/zZ9vE3x3TfQ8lq/pa 9u4fFVx7wAzM4wPLkjr1TcPoW/Nw7Uq8afM77LitmGbnsZ5kU/K6WHk7UHA55eu118RAH3WYDYES wu/zsOu5ewYvCmOOYI1rdoP/vOikkGK3k8AEGQFTlQ== =KfrB -----END PGP SIGNATURE----- --------------0hOSrnZ2yNY4H00p91FEprQf-- From nobody Mon Oct 25 05:45:20 2021 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 7FB733A0B53 for ; Mon, 25 Oct 2021 05:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.108 X-Spam-Level: X-Spam-Status: No, score=-3.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_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=liquidtelecom.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 Lh7TCniOQJEj for ; Mon, 25 Oct 2021 05:45:13 -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 E14293A0EDE for ; Mon, 25 Oct 2021 05:44:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquidtelecom.com; s=mimecast20210406; t=1635165881; 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=6MHevfWPqIGgTTiUnQQcbXPm8275jPfLk9z6VchIa04=; b=Gnk4wGQ20ZYmJZaB/8GeWTgDtuxknyngs4vXtPfYvASBUFvtlCvYQqY5Q82k3z3cQ+1Hzm yDzQ/HYRlpj+dKEskaOPRVZJOoAzD2zNaW5Ev8weDnCStczX7OoIr1R1SNdaHDHFFj0QmD 3/5W/rMDGJuw15rDjsOvFKJjYBpR6OA= Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05lp2111.outbound.protection.outlook.com [104.47.17.111]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-259-4DhroJ8pPHCZPfmI44b_rA-1; Mon, 25 Oct 2021 13:44:34 +0100 X-MC-Unique: 4DhroJ8pPHCZPfmI44b_rA-1 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com (2603:10a6:20b:346::6) by AS8PR03MB7670.eurprd03.prod.outlook.com (2603:10a6:20b:400::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.16; Mon, 25 Oct 2021 12:44:32 +0000 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9]) by AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9%6]) with mapi id 15.20.4628.020; Mon, 25 Oct 2021 12:44:32 +0000 From: Andrew Alston To: Eliot Lear , Ted Hardie CC: Nick Hilliard , SPRING WG List , 6man WG Thread-Topic: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) Thread-Index: AQHXx/O4amezbiLfA0mwUAzKM2wSgqvhsZOAgABbU4CAADcFAIAABeAAgAAcVQCAAC1iAIAABo2AgADOV3CAACBHgIAAFsNggAAKN4CAAADIgA== Date: Mon, 25 Oct 2021 12:44:32 +0000 Message-ID: References: <89c62864-feb4-550e-2d63-264b2ecc3344@lear.ch> <8bf003b2-988d-6d6c-f080-519596a3b1ac@foobar.org> In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 06ae7842-c0cd-4b0b-3313-08d997b531a2 x-ms-traffictypediagnostic: AS8PR03MB7670: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: NW6+/5hVcDloJTH97+VxDgyx34rWCfhloq596UbO4OO5DnsoJuf9M1o2nzF+7YM+DwiWUQkWAY1JkIdZtKZg916zFsFDhpTDQ/dsKl2u/S/ZmOaC+AVnPIpEDSZjdWEiP5+PDWYwlDAEK+ocqlhlKvCy48de78v2YAm9AFYnklOxyveNcb+QcseJJ4aJ4Vp9VuwcfNDpm0KlegbVxhE6/VLuJAUS3bLJztRzYR3EXp7UxfX9N8FS81LjObhnhURwMPmtL8smHa2LSnMCVW6OEKuX6p90/TdKEwlPHPEu9hFweQnAyxx45ufaRhuz1nNCRhhs+w8si1D4ykpyi6yIZGwtAckYvyDPnOxqt+m/qUW2ckVsaZKYAzy8fSqUKvRT2Cmdm6l3t2VQvtOdC2on0LwrjkZZvPPt90x2MAqQVMwv4wyVRvEovxrKZk+oBc5IKmza2TiIHsp5Y2zK19Fj7T43bawAecktyKr3Q401ztR43an7mf0r92LaYwKLuI0piDWQL5gEeSfgu/QI1ytBiw3FB1BUIt2cS4EcPc9EOyoX5HjqwPl4POaUkM00AGtihBTQ8eeAaoQ8/sVHfypjU1EUBBRxQuX23QU1v2AyqrVaPo2fHP3tvJZCL44r3yp/PZP0uHrGHxjFRsvPFnvNeXTiSHEXOjxYShbWw4Vo/UA1qw4Ul44FHFF+keL4Wh7TEh9zG8mJb7aKIpC7WrH+9Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR03MB7622.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66556008)(38070700005)(76116006)(66476007)(66446008)(64756008)(8676002)(66946007)(7696005)(8936002)(71200400001)(55016002)(316002)(66574015)(2906002)(38100700002)(53546011)(9686003)(86362001)(110136005)(122000001)(54906003)(5660300002)(83380400001)(33656002)(4326008)(52536014)(6506007)(186003)(508600001); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?T2JKL2hJNmRRSEh1eFd0SDZtTk9DeUFJWUQ4U1FnbU12S3V2eVhEOVRnblF5?= =?utf-8?B?TFg1QUdJOWZPVE85RFIrbXpYc1N3ZlMrT3kzRGpzbTR0Y1VZeHNsMThZVnYy?= =?utf-8?B?c2h3c2F4d3Vqblc4RTh4TzZ5YnRDN0xTM3VVOUZLZXJEdXpUR3BEdlZXeGxZ?= =?utf-8?B?V2xqRnlMekFMUnJvaTZ3TFRpMWM5U21aSkI4ZStVUEYyb1VVT1g1anpKRmlr?= =?utf-8?B?ZmtrcXJKZ3h6dWd3Skw5M1hZd0tmNTNVWGc3eFlzL2JjR2dTMndSZDRHSzNa?= =?utf-8?B?Z0VOcDI1c3NjaFFNcEdCOVcvbnA1OUlrS0NDR0VJUGRyWlREb2N4bVVmMy9n?= =?utf-8?B?aHdXRTlTczdBUk11dGpoU1JDbnZMbEZjb0ZiRnZyVWV0UUVjTTdxOFNJV1FF?= =?utf-8?B?US81ZDNqYTJPT05MejllN25IbE5rS3ZwYVdGQUZEd2JaQkIxVkRPMWsrQjBW?= =?utf-8?B?V2lWVk9KTk5jVlBzd2hLbFlTQVQrUXg1d0F2SEN4dWFFQktaMU5ibGRDTzBE?= =?utf-8?B?aFBmTlV1aVJPNVFRTHBpV2h6UVhoVGlzY1BYVHc0VmdHbzlIby9BWXBxeFRW?= =?utf-8?B?aXMrRlhEVWREQUt3dmUrN0hENTFwc2NjU2VPTXRYcW0zOTZ3eGdXb3JwS2Zl?= =?utf-8?B?OHVZZWFkNmE0aEpTanRaVVludkVUNmZaa1ZFQVRxeUptcmgvRHBSSFRRWUN4?= =?utf-8?B?cWkxZ3pNcFoxQVNpYUdXNjBlbHJmdzF6enVsQitWMTNzVVJZMkpqZ3g2dGhV?= =?utf-8?B?bGxORUtZU2ptS0V2VHBNVzd1NkhHUEtQWnFnT0hrUk4vck9mbXJQMmRMTzJ3?= =?utf-8?B?OHF4cVJ0UWUxM0hMOW4ybmEyZ2ovUkpFaHBTdGdxbGh1S204eUpLQzExcTJX?= =?utf-8?B?MVVmakYxb3pIZGR1NCtOSHZyMHJiSVJJOGlaMG41YzBzd1c5OW5CK2k2WFFH?= =?utf-8?B?cjdlUVgwUnpFNTBLNUlmUHBWVFpmblhwZDAvVExiRUt5a0V0Um1DVlhFdDNS?= =?utf-8?B?d1QyQWdSdXpxS24wdHN3TnV5YmZpalNBaktoTEJtOTMxc2VzMzJabXhSUDFG?= =?utf-8?B?eTFiaXh4d2hzbjd5K1JKaDdpTWlQRGVXSitNV3g4d0dLZXlRcEJPQ1h1NEo1?= =?utf-8?B?dVZtbjJ3b3FUcENOdHNRd25WZDZCVnNVSjhCeDUzWVJLa3JSdXdkbFVaVVl0?= =?utf-8?B?NkRVQUI0V0dlZnBySi8xNnRscVcvbjFPZStXK21ZOS93UEljRFBpRU1iT01H?= =?utf-8?B?VnFRWnphTDFsdDYrZUhMZmh3U2hZM1pIUHdLbWlMQUVVeEE3NCtPd01mTkt0?= =?utf-8?B?N2hvdmFxR2FBOTd5NHcyMU4yVEQrMFBsSHB0TmEzQUEzVTB3YnJ2U3lRTk9Z?= =?utf-8?B?NjBYc0syR1FGMThZTC9nZVNqTjU3cDZGdGJiSytaUUhZblBpR2xvNWF3UzlU?= =?utf-8?B?RE1BSlZ2NmwzOUx2TEtKTDhScEZldUhIT01ZakZCR3BoUktpOTdqQjlSSTZ3?= =?utf-8?B?MG5LZ3hxblF0c0tqVWIzK1daQjRBL2RKeUdPeE1YNEkveklhb1pKaklPMmxY?= =?utf-8?B?MVZkYXRvWkVvWEJ3T1BaUVNwQ0NDa1dNZjcwanZaWHNPTEM5dGNpT0laZzda?= =?utf-8?B?cGZtaHlMd2pJMWJPVzhFbnB3QUp4eTZjNDVzOG4xM1c2ZVJ0N2dBdm1RRnpW?= =?utf-8?B?OTJTcTJPUG5veFcvOWJvYVdaWlZWdlBYZXdDUnoyT0JwVlluVi9BeG1oMkNL?= =?utf-8?B?cHlOeDhhLzVqOGV3OGY3dzRDaTFPSE5NdFRuSUg1MUx2bVdJWDZUN1VVYWUw?= =?utf-8?B?UWtFMlBQZWZqV2x2c3NGNkJFTno1bm1YZStqczY4dkd4SW9ZYVpjbndHdUYy?= =?utf-8?B?bGU3ZCtycTVtRzhJZnBuUXdKQzVUNnErYmNKdmVvWTlqZVY3RE10U1VSSnh5?= =?utf-8?B?NmJjMDk5TTlqVkJqZjc4Z2cwMFhheldMaHhJSXRuZVI1ZnQvVDk2aG15TTV4?= =?utf-8?B?clNtei9jVmNkZXlzZFlWWnFmVUVmS2tBOTM1ZG1RR0xHc2lzbm9ZZ3ZPQTZ1?= =?utf-8?B?MndURVc4U1NlWFMwRmhud3h0ZkxpTythaTFqZGJaNnpGcENiYWg3akM0SXVY?= =?utf-8?B?dGoxalRKNXlWMVU3WkQ2eFdpSmNzaWhPY3FoR1ozS2x5ZTdaK01jWElCbDRz?= =?utf-8?B?dVY2S09iY3QwMjZ4YmJCSk9YdThFV3ZEZjBZRlBqZ2g1TzYyU2dBT2QxdXV0?= =?utf-8?B?UmRsaGlxMDJEMldOZXl0L2pxNm5yUHcwcktnUHM5Yng1MVE5Qm9mMlBTSlRv?= =?utf-8?Q?zKhhi/wHJ2UDOBgBQO?= MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB7622.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 06ae7842-c0cd-4b0b-3313-08d997b531a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2021 12:44:32.5889 (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: wYetWqPnBMeJDGPVYIXLR1mn6eFscqcK1NYeTnXk0MlcBcB4o+NhV/3PT6PGUmLrCU1E8FB83jQiYg/msiV+2ZXkjNSkAlUVC6QAq5mDQeQ= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7670 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquidtelecom.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_AS8PR03MB76222F69A8774BE91B63B889EE839AS8PR03MB7622eurp_" Archived-At: Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 25 Oct 2021 12:45:19 -0000 --_000_AS8PR03MB76222F69A8774BE91B63B889EE839AS8PR03MB7622eurp_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 U2VlLCBJIGRpc2FncmVlIHdpdGggdGhpcyBFbGxpb3QsDQoNCldoYXQgeW91IGhhdmUgaXMgc2V2 ZXJhbCBvcGVyYXRvcnMgd2hvIGFyZSBjbGVhcmx5IHN0YXRpbmcg4oCTIHRoZXJlIGFyZSBpc3N1 ZXMgd2l0aCB0aGlzLiAgQW5kIHRvb2wgZXZvbHV0aW9uIGlzIGV4YWN0bHkgd2hhdCBJIGFtIHJl ZmVycmluZyB0byDigJMgdGhlIHRvb2xzIG1heSBleGlzdCDigJMgYnV0IHdoYXQgd2lsbCB0aGV5 IGNvc3Q/IEZvciBteXNlbGYsIEnigJltIGluIHRoZSBsdWNreSBwb3NpdGlvbiB0aGF0IEkgaGF2 ZSBhIHRlYW0gdGhhdCBjYW4gZ28gb3V0IGFuZCB3cml0ZSB0b29saW5nIGlmIHdlIG5lZWQgaXQg 4oCTIHRoYXQgd2lsbCBzY3JhcGUgY29uZmlncyBmb3IgU0lEIGxpc3RzIOKAkyB0aGF0IHdpbGwg aW50ZWdyYXRlIHdpdGggb3VyIElHUCDigJMgd2lsbCB0YWtlIGZlZWRzIGZyb20gQk1QIOKAkyB3 aGF0ZXZlciDigJMgd2UgZG8gdGhhdCBhbGwgdGhlIHRpbWUgb24gaW50ZXJuYWwgdG9vbGluZy4g IFRoZSBxdWVzdGlvbiBoZXJlIGlzIOKAkyB3aGF0IGltcGFjdCB3aWxsIHRoaXMgaGF2ZSBvbiB0 aGUgc21hbGxlciBndXlzIHdobyBjYW5ub3QgYWZmb3JkIHRvIGVpdGhlciBidWlsZCBvciBidXkg c3VjaCB0b29saW5nLg0KDQpUaGlzIGhhcyBhIGtub2NrIG9uIGVmZmVjdCDigJMgdGhlIHNtYWxs ZXIgb3BlcmF0b3JzIGFyZSByZXN0cmljdGVkIGluIHdoYXQgdGhleSBjYW4gZGVwbG95IOKAkyB0 aGUgaW50ZXItb3Agc3RhcnRzIGdldHRpbmcgcmVzdHJpY3RlZCDigJMgdGhlIHBvdGVudGlhbCBi cmVha2FnZSBkdWUgdG8gYXZhaWxhYmxlIHNraWxscyBpbiB0aGUgbmV0d29ya3MgaW5jcmVhc2Vz IOKAkyB0aGUgcG90ZW50aWFsIGZvciBsZWFrYWdlIG9mIHdobyBrbm93cyB3aGF0IGFsc28gZ29l cyB1cCDigJMgYW5kIHdlIGVuZCB1cCB3aXRoIHNvbWV0aGluZyB0aGF0IHJ1bnMgY29udHJhcnkg dG8gdGhlIElFVEYgc3RhdGVtZW50IOKAkyB0aGF0IGlzIOKAnFRvIG1ha2UgdGhlIGludGVybmV0 IHdvcmsgYmV0dGVy4oCdLg0KDQpBZGRpbmcgY29tcGxleGl0eSB3aGVyZSBpdCBjYW4gYmUgYXZv aWRlZCB1c2luZyBUTFbigJlzIOKAkyB3aGljaCBhcmUgc3VwcG9ydGVkIGluIHRoZSBTUkgg4oCT IGRvZXMgbm90IGFzc2lzdCBhbnlvbmUuICBNb2RpZnlpbmcgYSBzcGVjIGJ5IG1pbm9yIGRlZ3Jl ZXMgc3VjaCB0aGF0IHRoZSBsaXZlcyBvZiB0aGUgc3BlY+KAmXMgY29uc3VtZXJzIGFyZSBtYWRl IGVhc2llciwgaW5jcmVhc2VzIGxpa2VsaWhvb2Qgb2YgYWRvcHRpb24gYW5kIGRlY3JlYXNlcyBy ZXNpc3RhbmNlIOKAkyB0byBtZSB0aGF0IGp1c3QgbWFrZXMgcGVyZmVjdCBzZW5zZS4NCg0KQW5k cmV3DQoNCg0KRnJvbTogRWxpb3QgTGVhciA8bGVhckBsZWFyLmNoPg0KU2VudDogTW9uZGF5LCBP Y3RvYmVyIDI1LCAyMDIxIDM6MzUgUE0NClRvOiBBbmRyZXcgQWxzdG9uIDxBbmRyZXcuQWxzdG9u QGxpcXVpZHRlbGVjb20uY29tPjsgVGVkIEhhcmRpZSA8dGVkLmlldGZAZ21haWwuY29tPg0KQ2M6 IE5pY2sgSGlsbGlhcmQgPG5pY2tAZm9vYmFyLm9yZz47IFNQUklORyBXRyBMaXN0IDxzcHJpbmdA aWV0Zi5vcmc+OyA2bWFuIFdHIDxpcHY2QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtzcHJpbmdd IE9iamVjdGlvbiB0byB3ZyBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1maWxzZmlsc2NoZW5nLXNw cmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbiAod2FzOiBSZTogUXVlc3Rpb24gZnJvbSBTUFJJTkcg cmVnYXJkaW5nIGRyYWZ0LWZpbHNmaWxzY2hlbmctc3ByaW5nLXNydjYtc3JoLWNvbXByZXNzaW9u KQ0KDQoNCkhpIEFuZHJldywNCg0KSSBkb24ndCBkaXNhZ3JlZSB3aXRoIHlvdXIgcG9pbnQgdGhh dCBvcGVyYXRpb25hbCBjb21wbGV4aXR5IGhpbmRlcnMgYWRvcHRpb24uICBIb3dldmVyLi4uDQpP biAyNS4xMC4yMSAxNDoxNCwgQW5kcmV3IEFsc3RvbiB3cm90ZToNCkl0J3MgaGVyZSB3aGVyZSBJ IHRoaW5rIHdlIG9mdGVuIGVuZCB1cCBpbiBhIGRpdmVyZ2VuY2UgYmV0d2VlbiBwcmFjdGljYWwg b3BlcmF0aW9uIGFuZCBmYW5jeSBpZGVhcw0KDQpUaGUgcHJvYmxlbSBpcyB0aGF0IG9uZSBvZnRl biBjYW4ndCB0ZWxsIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gdGhlIHR3byB3aXRob3V0IHRoZSBi ZW5lZml0IG9mIGhpbmRzaWdodCwgYW5kIHBlcmhhcHMgc2V2ZXJhbCByZXZzIG9mIHRoZSBzcGVj LiAgSVB2NiBpdHNlbGYgaXMgYSBwZXJmZWN0IGV4YW1wbGUgb2YgdGhhdCB0cnV0aCAoY2YsIE1J UHY2LCBzaXRlLWxvY2FsLCBJUHNlYyByZXF1aXJlbWVudHMsIGFuZCBnZW9ncmFwaGljIHJvdXRp bmcpLiAgQnV0IEkgd3JpdGUgdGhhdCB3aXRoIHRoZSBiZW5lZml0IG9mIGhpbmRzaWdodCBpbiB3 aGljaCB3ZSBkaWQgZmluZCB1c2UgZm9yIG90aGVyIHY2IGZlYXR1cmVzLCBsaWtlIGZsb3cgbGFi ZWxzLg0KDQpSaWdodCBub3cgd2UgaGF2ZSBhIGxvdCBvZiBzcGVjdWxhdGlvbiBhYm91dCBob3cg dG9vbHMgd29uJ3QgZXZvbHZlIHRvIGFzc2lzdCBvcGVyYXRvcnMsIGFuZCBJJ20gc3ltcGF0aGV0 aWMgdG8gdGhhdCB0byBhIHBvaW50OiB0b29scyBkZXZlbG9wIGJlc3Qgb3V0IG9mIG9wZXJhdGlv bmFsIGV4cGVyaWVuY2UuDQoNCkVsaW90DQoNCg== --_000_AS8PR03MB76222F69A8774BE91B63B889EE839AS8PR03MB7622eurp_ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29y ZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlNlZSwgSSBkaXNhZ3JlZSB3aXRoIHRoaXMgRWxsaW90LDxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5XaGF0IHlvdSBoYXZlIGlzIHNldmVyYWwgb3BlcmF0b3JzIHdobyBhcmUg Y2xlYXJseSBzdGF0aW5nIOKAkyB0aGVyZSBhcmUgaXNzdWVzIHdpdGggdGhpcy4gJm5ic3A7QW5k IHRvb2wgZXZvbHV0aW9uIGlzIGV4YWN0bHkgd2hhdCBJIGFtIHJlZmVycmluZyB0byDigJMgdGhl IHRvb2xzIG1heSBleGlzdCDigJMgYnV0IHdoYXQgd2lsbCB0aGV5IGNvc3Q/IEZvciBteXNlbGYs IEnigJltIGluIHRoZSBsdWNreSBwb3NpdGlvbiB0aGF0IEkNCiBoYXZlIGEgdGVhbSB0aGF0IGNh biBnbyBvdXQgYW5kIHdyaXRlIHRvb2xpbmcgaWYgd2UgbmVlZCBpdCDigJMgdGhhdCB3aWxsIHNj cmFwZSBjb25maWdzIGZvciBTSUQgbGlzdHMg4oCTIHRoYXQgd2lsbCBpbnRlZ3JhdGUgd2l0aCBv dXIgSUdQIOKAkyB3aWxsIHRha2UgZmVlZHMgZnJvbSBCTVAg4oCTIHdoYXRldmVyIOKAkyB3ZSBk byB0aGF0IGFsbCB0aGUgdGltZSBvbiBpbnRlcm5hbCB0b29saW5nLiZuYnNwOyBUaGUgcXVlc3Rp b24gaGVyZSBpcyDigJMgd2hhdCBpbXBhY3QNCiB3aWxsIHRoaXMgaGF2ZSBvbiB0aGUgc21hbGxl ciBndXlzIHdobyBjYW5ub3QgYWZmb3JkIHRvIGVpdGhlciBidWlsZCBvciBidXkgc3VjaCB0b29s aW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGhhcyBhIGtub2NrIG9uIGVmZmVjdCDi gJMgdGhlIHNtYWxsZXIgb3BlcmF0b3JzIGFyZSByZXN0cmljdGVkIGluIHdoYXQgdGhleSBjYW4g ZGVwbG95IOKAkyB0aGUgaW50ZXItb3Agc3RhcnRzIGdldHRpbmcgcmVzdHJpY3RlZCDigJMgdGhl IHBvdGVudGlhbCBicmVha2FnZSBkdWUgdG8gYXZhaWxhYmxlIHNraWxscyBpbiB0aGUgbmV0d29y a3MgaW5jcmVhc2VzIOKAkyB0aGUgcG90ZW50aWFsIGZvciBsZWFrYWdlIG9mDQogd2hvIGtub3dz IHdoYXQgYWxzbyBnb2VzIHVwIOKAkyBhbmQgd2UgZW5kIHVwIHdpdGggc29tZXRoaW5nIHRoYXQg cnVucyBjb250cmFyeSB0byB0aGUgSUVURiBzdGF0ZW1lbnQg4oCTIHRoYXQgaXMg4oCcVG8gbWFr ZSB0aGUgaW50ZXJuZXQgd29yayBiZXR0ZXLigJ0uJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QWRkaW5nIGNvbXBsZXhpdHkgd2hlcmUgaXQgY2FuIGJlIGF2b2lkZWQgdXNpbmcgVExW 4oCZcyDigJMgd2hpY2ggYXJlIHN1cHBvcnRlZCBpbiB0aGUgU1JIIOKAkyBkb2VzIG5vdCBhc3Np c3QgYW55b25lLiAmbmJzcDtNb2RpZnlpbmcgYSBzcGVjIGJ5IG1pbm9yIGRlZ3JlZXMgc3VjaCB0 aGF0IHRoZSBsaXZlcyBvZiB0aGUgc3BlY+KAmXMgY29uc3VtZXJzIGFyZSBtYWRlIGVhc2llciwg aW5jcmVhc2VzIGxpa2VsaWhvb2Qgb2YgYWRvcHRpb24NCiBhbmQgZGVjcmVhc2VzIHJlc2lzdGFu Y2Ug4oCTIHRvIG1lIHRoYXQganVzdCBtYWtlcyBwZXJmZWN0IHNlbnNlLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BbmRyZXc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+RnJvbTo8L2I+IEVsaW90IExlYXIgJmx0O2xlYXJAbGVhci5jaCZndDsgPGJyPg0K PGI+U2VudDo8L2I+IE1vbmRheSwgT2N0b2JlciAyNSwgMjAyMSAzOjM1IFBNPGJyPg0KPGI+VG86 PC9iPiBBbmRyZXcgQWxzdG9uICZsdDtBbmRyZXcuQWxzdG9uQGxpcXVpZHRlbGVjb20uY29tJmd0 OzsgVGVkIEhhcmRpZSAmbHQ7dGVkLmlldGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4g TmljayBIaWxsaWFyZCAmbHQ7bmlja0Bmb29iYXIub3JnJmd0OzsgU1BSSU5HIFdHIExpc3QgJmx0 O3NwcmluZ0BpZXRmLm9yZyZndDs7IDZtYW4gV0cgJmx0O2lwdjZAaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBPYmplY3Rpb24gdG8gd2cgYWRvcHRpb24gY2Fs bCBmb3IgZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24gKHdh czogUmU6IFF1ZXN0aW9uIGZyb20gU1BSSU5HIHJlZ2FyZGluZyBkcmFmdC1maWxzZmlsc2NoZW5n LXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbik8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwPkhpIEFu ZHJldyw8bzpwPjwvbzpwPjwvcD4NCjxwPkkgZG9uJ3QgZGlzYWdyZWUgd2l0aCB5b3VyIHBvaW50 IHRoYXQgb3BlcmF0aW9uYWwgY29tcGxleGl0eSBoaW5kZXJzIGFkb3B0aW9uLiZuYnNwOyBIb3dl dmVyLi4uPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjUu MTAuMjEgMTQ6MTQsIEFuZHJldyBBbHN0b24gd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JdCdzIGhlcmUgd2hlcmUgSSB0aGluayB3ZSBvZnRl biBlbmQgdXAgaW4gYSBkaXZlcmdlbmNlIGJldHdlZW4gcHJhY3RpY2FsIG9wZXJhdGlvbiBhbmQg ZmFuY3kgaWRlYXM8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwPlRoZSBwcm9ibGVt IGlzIHRoYXQgb25lIG9mdGVuIGNhbid0IHRlbGwgdGhlIGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUg dHdvIHdpdGhvdXQgdGhlIGJlbmVmaXQgb2YgaGluZHNpZ2h0LCBhbmQgcGVyaGFwcyBzZXZlcmFs IHJldnMgb2YgdGhlIHNwZWMuJm5ic3A7IElQdjYgaXRzZWxmIGlzIGEgcGVyZmVjdCBleGFtcGxl IG9mIHRoYXQgdHJ1dGggKGNmLCBNSVB2Niwgc2l0ZS1sb2NhbCwgSVBzZWMgcmVxdWlyZW1lbnRz LCBhbmQgZ2VvZ3JhcGhpYyByb3V0aW5nKS4mbmJzcDsNCiBCdXQgSSB3cml0ZSB0aGF0IHdpdGgg dGhlIGJlbmVmaXQgb2YgaGluZHNpZ2h0IGluIHdoaWNoIHdlIGRpZCBmaW5kIHVzZSBmb3Igb3Ro ZXIgdjYgZmVhdHVyZXMsIGxpa2UgZmxvdyBsYWJlbHMuPG86cD48L286cD48L3A+DQo8cD5SaWdo dCBub3cgd2UgaGF2ZSBhIGxvdCBvZiBzcGVjdWxhdGlvbiBhYm91dCBob3cgdG9vbHMgd29uJ3Qg ZXZvbHZlIHRvIGFzc2lzdCBvcGVyYXRvcnMsIGFuZCBJJ20gc3ltcGF0aGV0aWMgdG8gdGhhdCB0 byBhIHBvaW50OiB0b29scyBkZXZlbG9wIGJlc3Qgb3V0IG9mIG9wZXJhdGlvbmFsIGV4cGVyaWVu Y2UuPG86cD48L286cD48L3A+DQo8cD5FbGlvdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_AS8PR03MB76222F69A8774BE91B63B889EE839AS8PR03MB7622eurp_-- From nobody Mon Oct 25 08:51:23 2021 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 041C63A0C19; Mon, 25 Oct 2021 08:51:22 -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.39.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: spring@ietf.org Message-ID: <163517708197.22298.7796565223704781932@ietfa.amsl.com> Date: Mon, 25 Oct 2021 08:51:22 -0700 Archived-At: Subject: [spring] I-D Action: draft-ietf-spring-sr-replication-segment-06.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, 25 Oct 2021 15:51:22 -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-06.txt Pages : 13 Date : 2021-10-25 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-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-replication-segment-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Oct 25 12:41:18 2021 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 3C8A33A086C; Mon, 25 Oct 2021 12:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5As-tpBKj31L; Mon, 25 Oct 2021 12:41:06 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 9670E3A0EFC; Mon, 25 Oct 2021 12:39:22 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id l16-20020a9d6a90000000b0054e7ab56f27so16378088otq.12; Mon, 25 Oct 2021 12:39:22 -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=zl1sjgnyKlfEpNqaJfDXZSTUu3BuWYGd4GxPDw6gXcw=; b=AkcP0bnpoOyxlxLCeIXx8q8txFJnFzwi2kIAJMvzKq+XHOAbjhOWnsy+VaJa0aE48Q 8dskquzug+nx5a0z8mUYceTT/ufkfB7RBV63i61VbqUmrZyMrpY6RwHIPnqtKJOE649A b0MS7+2xw7jp/ExkBex3+sC0M3VzPuV+VlPWMZKkiDNPJtwpcGDPRnlH/wFbeiG8p8F1 FTmvEgARhK+DwJGOZUujCaiVhM479HUeCaFEld8l4Z0tPZ8eb4Is8UuBZYm0T3j9pYwS 633QZxWtZaRzSI/mRXdEfZR/mgM0FPNkFta6HcPeuYpWyPAlGwZgjZBX25wGH8TRvgkK 8z7w== 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=zl1sjgnyKlfEpNqaJfDXZSTUu3BuWYGd4GxPDw6gXcw=; b=nt+GZjMykjTjMRW6LM6oIz8K+9PKek1FIU/sDZBQzxXw5Y96UwIIuFolST/1I2JKIy 7iyRVcZAArfUUYVi84V7nHDR+XcVwyD1pT8DOBEYOJE7BTyv9NPOLs8BaQWMMYaGnInA tzMTb371UwR21vrYQZciaUR17k/3JMAlDgCWgY1TB/U3DwxfE6baWTTq+zLVKsrQp7jX upKjJoOHPUqPZrMdzb3vAQOhtqvr0HeSxAwGrY6BJXHxDgHb4YcFRD84WxsVBHJX9wd3 n4V63ZMNwyp3OYbrVCbt3xjN356luNhA5fQ5dNCZDhF412pdkOEVcVOlg/J4mXZ18Xw/ XzvQ== X-Gm-Message-State: AOAM530N5nGTC5biV+Ozty85+EHF5EAejWcWrxt5xmoDtqAHcdxZepif Psy8C/saVR4npzCSuS1hMfxJiaJxFzVH/qgSkHs= X-Google-Smtp-Source: ABdhPJwCHXXPl+f+Km11VMt6R5/yFWjb0c2nhfc07FKoSgfIiKsK/7h9BYko5CqKRT84C1rMucgb3pv+QBgS8+h3VbQ= X-Received: by 2002:a05:6830:86:: with SMTP id a6mr15470026oto.380.1635190761796; Mon, 25 Oct 2021 12:39:21 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> In-Reply-To: <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> From: Erik Kline Date: Mon, 25 Oct 2021 12:39:12 -0700 Message-ID: To: "Joel M. Halpern" Cc: "ipv6@ietf.org" , "John G. Scudder" , "spring@ietf.org" , Martin Vigoureux , Alvaro Retana Content-Type: multipart/alternative; boundary="0000000000007f3b8405cf328498" Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 25 Oct 2021 19:41:11 -0000 --0000000000007f3b8405cf328498 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable [replying on this thread as is has more folks cc'd] Joel, First: thank you to everyone who has commented, clarified, sat for meetings, and reviewed and edited text, often repeatedly. It is very much appreciated. This reply is on behalf of the 6MAN chairs and INT ADs. -- Erik, =C3=89ric, Bob, Ole [1] Does the placement of a list of SIDs in the IPv6 DA field change the IPv6 architectural description of that field? It is understood that from the perspective of an IPv6 transit node the DA field remains a valid DA, and from the perspective of an SR-aware node the DA remains a SID of the LOC:FUNC:ARG form of RFC 8986. On the surface, then, these would not appear to represent any change to the IPv6 data plane from currently published specifications. However, this new category of address seems as though it can in fact go against current specifications in certain circumstances. SIDs of the RFC 8754 and RFC 8986 form can reasonably be expected to obey general unicast semantics: RFC 8986 section 4.1.1 permits Endpoint handling of any inner payload type that is =E2=80=9Callowed by local configuration= =E2=80=9D and even explicitly gives the example of =E2=80=9Can operator might permit pinging o= f SIDs.=E2=80=9D In the case of ICMPv6 Echo Replies specifically RFC 4443 section 4.2 places requirements on the source address of the reply: it MUST be a unicast address and MUST be the same as the DA if the DA was unicast otherwise another unicast SA is chosen if the DA was an anycast or multicast address. In the SR C-SID topology A--B--C--D, sending a ping from A to D, could in theory be done two ways: (1) ping D via SR policy B,C or (2) ping LOC:FUNC:B:C:D (the SID of B with a set of CSIDs as the argument). In the first case the ping is sent to the final destination D, via an SR path. In the second case, the ping is sent to the final destination LOC:FUNC:B:C:D. The IPv6 destination address as observed on the wire between A and B (LOC:FUNC:B:C:D) and on reception at D (D::) will be the same in both cases. In the first case, the ICMP checksum based on address D is valid and an ICMP reply will be sent from D to A. In the second case though, the ICMP echo request packet will have an invalid ICMP checksum and will be dropped. Can an IPv6 destination address when it's a C-SID (an =E2=80=9CEnd with Nex= t SID arguments=E2=80=9D) behave like a normal IPv6 end-point? Based on this, we = may have some new category of addresses and we feel the characteristics of SRv6 C-SID addresses should be more clearly defined. We think that any architectural issues can be resolved with such a document as outlined in [A] below. [2] Does the operation of shifting information around in the IPv6 destination address field represent a modification or extension of the IPv6 data plane? The use of a SID with an ARG with a series of C-SIDs to generate the next SID (a.k.a. =E2=80=9Cshifting=E2=80=9D) form of compression (NEXT-C-SID) ha= s an additional deviation from the expected behavior of unicast addresses in the IPv6 data plane, primarily by introducing a mechanism that achieves the objectives of an SRH without requiring the presence of an SRH (section 4.1 of RFC 8754) or without requiring the existence of Segment List in an attached SRH (reduced SRH per section 4.1.1 of RFC 8754). With existing SIDs, with REPLACE-C-SID behavior, and with NEXT-C-SID behavior with a complete SRH, an ICMP error packet generated in response to, for example, a traceroute packet with an attached SR policy can trivially be correlated by the error receiver if the invoking packet payload contains a sufficient portion of the SRH (section 5.4 of RFC 8754). In the case of C-SIDs, the original sender can correlate the ICMP error by doing a lookup in the segment prefix list of the SRH or in the DA and finding the last SID representing the final destination as the final destination is guaranteed to always be present even in the absence of SRH. The behavior required of the original sender needs to be described in the C-SID draft. Beyond the concerns and questions raised in this response so far, within an SR domain or set of cooperating SR domains, where restrictions on behavior can be clearly defined and documented, these changes are limited to the SRv6 data plane. To summarize: we do not object to C-SID behavior work continuing in SPRING, we simply need a clarifying document described in [A]. --- Next steps for consideration: [A] A separate 6MAN document to clarify and categorize SRv6 SIDs is needed. We are happy to work to find authors for this document. The document should explain SIDs=E2=80=99 deviation from RFC 4291 (probably likening them to other addresses within prefixes handled by some virtual network function, like NAT64 prefixes, and clarify that they are not assigned to an interface) and capture many of the observations like those in Brian Carpenter=E2=80=99s recent email [BC]. We think the document shou= ld also clarify when a SID can appear in the Source Address field vs. when it can only appear in the Destination Address field, and whether such a distinction should exist. It should describe the behaviour of IPv6 addresses in the case of C-SIDs (SIDs =E2=80=9CEnd with Next SID args=E2=80= =9D). The document should also make it clear which parts are documenting existing behavior of RFC 8754 and RFC 8986 SIDs -- therefore not really up for extended debate -- and hopefully lay the framework for understanding any future categories of SIDs (like whatever is coming at us next after C-SIDs) that are in development. This proposed =E2=80=9CSRv6 SID Addressing Clarifications=E2=80=9D 6MAN doc= ument should be a normative reference for final C-SID publication. [B] We think there are also operational considerations that warrant attention prior to standardization. Primarily we are concerned that there is no analog to the SRH. SegmentsLeft field, i.e., no =E2=80=9Ccompressed s= egments left=E2=80=9D field. The definition of the SRH.SegmentsLeft field points to= the definition from RFC 8200 section 4.4, which says it=E2=80=99s the =E2=80=9C= number of explicitly listed intermediate nodes still to be visited before reaching the final destination.=E2=80=9D Previously, there was a 1:1 mapping betwee= n this text and the list of IPv6 addresses in the SegmentList array. This definition should be reviewed and updated for the compressed information case. Relatedly, the semantic intent might be restored by adding some indication in the SRH of the size and number of the compressed SIDs. We suspect this would aid the usefulness of analysis of a packet capture: a captured packet in tcpdump/wireshark could be dissected to show helpful information without additional control plane knowledge. Otherwise some means of injecting control plane information into network diagnostics would be needed. [C] We also suggest that, as SID/C-SID behaviors could be confused with existing unicast/anycast address behaviour, it might be worth considering isolating SIDs to a dedicated prefix. RFC 4291 and other documents (e.g., RFCs 6052, 7343, ...) put addresses with different properties into defined prefixes, and SIDs/C-SIDs could be similarly compartmentalized into a well-defined prefix (e.g., a /16 to be requested of the IANA). If no dedicated prefix is used then the rationale should be documented (probably in the same document mentioned in [A]). [BC] https://mailarchive.ietf.org/arch/msg/ipv6/37bH3Ag7jaNgKwnZY_mKIxWRwdM= / --0000000000007f3b8405cf328498 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    [replying on this thread as is has more folks cc'd]
    Joel,

    First: thank you to everyone who has commente= d, clarified, sat for meetings, and reviewed and edited text, often repeate= dly.=C2=A0 It is very much appreciated.

    This reply is on behalf of t= he 6MAN chairs and INT ADs.

    -- Erik, =C3=89ric, Bob, Ole

    [1] = Does the placement of a list of SIDs in the IPv6 DA field change the IPv6 a= rchitectural description of that field?

    It is understood that from t= he perspective of an IPv6 transit node the DA field remains a valid DA, and= from the perspective of an SR-aware node the DA remains a SID of the LOC:F= UNC:ARG form of RFC 8986.=C2=A0 On the surface, then, these would not appea= r to represent any change to the IPv6 data plane from currently published s= pecifications.=C2=A0 However, this new category of address seems as though = it can in fact go against current specifications in certain circumstances.<= br>
    SIDs of the RFC 8754 and RFC 8986 form can reasonably be expected to= obey general unicast semantics: RFC 8986 section 4.1.1 permits Endpoint ha= ndling of any inner payload type that is =E2=80=9Callowed by local configur= ation=E2=80=9D and even explicitly gives the example of =E2=80=9Can operato= r might permit pinging of SIDs.=E2=80=9D =C2=A0In the case of ICMPv6 Echo R= eplies specifically RFC 4443 section 4.2 places requirements on the source = address of the reply: it MUST be a unicast address and MUST be the same as = the DA if the DA was unicast otherwise another unicast SA is chosen if the = DA was an anycast or multicast address.

    In the SR C-SID topology A--= B--C--D, sending a ping from A to D, could in theory be done two ways: (1) = ping D via SR policy B,C or (2) ping LOC:FUNC:B:C:D (the SID of B with a se= t of CSIDs as the argument). In the first case the ping is sent to the fina= l destination D, via an SR path. In the second case, the ping is sent to th= e final destination LOC:FUNC:B:C:D.=C2=A0 The IPv6 destination address as o= bserved on the wire between A and B (LOC:FUNC:B:C:D) and on reception at D = (D::) will be the same in both cases.=C2=A0 In the first case, the ICMP che= cksum based on address D is valid and an ICMP reply will be sent from D to = A.=C2=A0 In the second case though, the ICMP echo request packet will have = an invalid ICMP checksum and will be dropped.

    Can an IPv6 destinati= on address when it's a C-SID (an =E2=80=9CEnd with Next SID arguments= =E2=80=9D) behave like a normal IPv6 end-point? Based on this, we may have = some new category of addresses and we feel the characteristics of SRv6 C-SI= D addresses should be more clearly defined.=C2=A0 We think that any archite= ctural issues can be resolved with such a document as outlined in [A] below= .

    [2] Does the operation of shifting information around in the IPv6 = destination address field represent a modification or extension of the IPv6= data plane?

    The use of a SID with an ARG with a series of C-SIDs to= generate the next SID (a.k.a. =E2=80=9Cshifting=E2=80=9D) form of compress= ion (NEXT-C-SID) has an additional deviation from the expected behavior of = unicast addresses in the IPv6 data plane, primarily by introducing a mechan= ism that achieves the objectives of an SRH without requiring the presence o= f an SRH (section 4.1 of RFC 8754) or without requiring the existence of Se= gment List in an attached SRH (reduced SRH per section 4.1.1 of RFC 8754).<= br>
    With existing SIDs, with REPLACE-C-SID behavior, and with NEXT-C-SID= behavior with a complete SRH, an ICMP error packet generated in response t= o, for example, a traceroute packet with an attached SR policy can triviall= y be correlated by the error receiver if the invoking packet payload contai= ns a sufficient portion of the SRH (section 5.4 of RFC 8754). =C2=A0
    In = the case of C-SIDs, the original sender can correlate the ICMP error by doi= ng a lookup in the segment prefix list of the SRH or in the DA and finding = the last SID representing the final destination as the final destination is= guaranteed to always be present even in the absence of SRH. The behavior r= equired of the original sender needs to be described in the C-SID draft.
    Beyond the concerns and questions raised in this response so far, with= in an SR domain or set of cooperating SR domains, where restrictions on beh= avior can be clearly defined and documented, these changes are limited to t= he SRv6 data plane.

    To summarize: we do not object to C-SID behavior= work continuing in SPRING, we simply need a clarifying document described = in [A].

    ---

    Next steps for consideration:

    [A] A separa= te 6MAN document to clarify and categorize SRv6 SIDs is needed.=C2=A0 We ar= e happy to work to find authors for this document.

    The document shou= ld explain SIDs=E2=80=99 deviation from RFC 4291 (probably likening them to= other addresses within prefixes handled by some virtual network function, = like NAT64 prefixes, and clarify that they are not assigned to an interface= ) and capture many of the observations like those in Brian Carpenter=E2=80= =99s recent email [BC].=C2=A0 We think the document should also clarify whe= n a SID can appear in the Source Address field vs. when it can only appear = in the Destination Address field, and whether such a distinction should exi= st. It should describe the behaviour of IPv6 addresses in the case of C-SID= s (SIDs =E2=80=9CEnd with Next SID args=E2=80=9D). The document should also= make it clear which parts are documenting existing behavior of RFC 8754 an= d RFC 8986 SIDs -- therefore not really up for extended debate -- and hopef= ully lay the framework for understanding any future categories of SIDs (lik= e whatever is coming at us next after C-SIDs) that are in development.
    <= br>This proposed =E2=80=9CSRv6 SID Addressing Clarifications=E2=80=9D 6MAN = document should be a normative reference for final C-SID publication.
    [B] We think there are also operational considerations that warrant atten= tion prior to standardization.=C2=A0 Primarily we are concerned that there = is no analog to the SRH. SegmentsLeft field, i.e., no =E2=80=9Ccompressed s= egments left=E2=80=9D field. The definition of the SRH.SegmentsLeft field p= oints to the definition from RFC 8200 section 4.4, which says it=E2=80=99s = the =E2=80=9Cnumber of explicitly listed intermediate nodes still to be vis= ited before reaching the final destination.=E2=80=9D =C2=A0Previously, ther= e was a 1:1 mapping between this text and the list of IPv6 addresses in the= SegmentList array.=C2=A0 This definition should be reviewed and updated fo= r the compressed information case.

    Relatedly, the semantic intent mi= ght be restored by adding some indication in the SRH of the size and number= of the compressed SIDs.=C2=A0 We suspect this would aid the usefulness of = analysis of a packet capture: a captured packet in tcpdump/wireshark could = be dissected to show helpful information without additional control plane k= nowledge.=C2=A0 Otherwise some means of injecting control plane information= into network diagnostics would be needed.

    [C] We also suggest that,= as SID/C-SID behaviors could be confused with existing unicast/anycast add= ress behaviour, it might be worth considering isolating SIDs to a dedicated= prefix.=C2=A0 RFC 4291 and other documents (e.g., RFCs 6052, 7343, ...) pu= t addresses with different properties into defined prefixes, and SIDs/C-SID= s could be similarly compartmentalized into a well-defined prefix (e.g., a = /16 to be requested of the IANA).=C2=A0 If no dedicated prefix is used then= the rationale should be documented (probably in the same document mentione= d in [A]).

    [BC] https://mailarchive.ietf.= org/arch/msg/ipv6/37bH3Ag7jaNgKwnZY_mKIxWRwdM/


    --0000000000007f3b8405cf328498-- From nobody Mon Oct 25 15:08:00 2021 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 662ED3A0819 for ; Mon, 25 Oct 2021 15:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.87 X-Spam-Level: X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no 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 7mGpQFgxZUN9 for ; Mon, 25 Oct 2021 15:07:55 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A6A33A1257 for ; Mon, 25 Oct 2021 15:05:55 -0700 (PDT) Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id ECE37548059 for ; Tue, 26 Oct 2021 00:05:45 +0200 (CEST) Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id E3BB74E9BD7; Tue, 26 Oct 2021 00:05:45 +0200 (CEST) Date: Tue, 26 Oct 2021 00:05:45 +0200 From: Toerless Eckert To: spring@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Archived-At: Subject: [spring] SPRING: Better base header + addresses for the future ? (draft-eckert-intarea-functional-addr-internets) 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, 25 Oct 2021 22:07:59 -0000 Dear Spring WG. Through IntArea and other WGs, some of us started to invesstigate what benefits it wouldhave to support variable long network layer addressing, and assuming we had them, how to better encode the semantics we're interested in them. I did propose at 111 via draft-eckert-intarea-functional-addr-internets one such approach, and while i didn't have time so far to better highlight in the draft itself in more details the applicability to the problems i think SPRING is working on, i would nevertheless be very happy to get feedback and thoght on it. I'll ask the chairs if they might have 5..10 minutes to give a SPRING centric presentation Q&A for IETF112 of the idea. The pitch is really: -> If we are for spring trying to have more flexible and compact addressing to steer packets and call programs along the way, why do we want to constrain ourselves with rfc8200 encoding and addressing rules ? Sure, going beyond rfc8200 miht take a while, but its not as if we're in a hurry to plan a long term evolution now. We're not as pressured as we where by the Internnet in the 90'th to "quickly" come up with IPv6 (and leave a lot of IP-NG thoughts out of the picture). -> If we would figure out a new base header to superceed/amend rfc8200, we could IMHO become better for the addressing we seemingly like to have in SPRING than what we could do under rfc8200 doctrine. -> For our subject proposal specifically, applied to SPRING, the idea is simply to have the destination address be simply a sequence of the steering hops (each with an address length as long or short as the network operator wants), followed by the hops instructions - again as short or as long as the network operator wants. Aka: no worries anymore to come up with bogus rason why we need 128 bits for a steering how when we don't need programmability, and no reason to be woried we might run out of programming addressing space when we want more. And no need to additional extension headers when it can all be as simple as putting it into a single address. Cheers Toerless P.S.: Of course, if/when we think we want to do something in that direction, SPRING itself may not be the executing body of any work, but maybe 6man or somethin with more willingness to innovate than 6man, but thats IMHO not the first step of discussion. From nobody Tue Oct 26 07:56:46 2021 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 D37803A1251; Tue, 26 Oct 2021 07:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 ouc6i4y38UBt; Tue, 26 Oct 2021 07:56:35 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 6C51D3A124D; Tue, 26 Oct 2021 07:56:35 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id e59-20020a9d01c1000000b00552c91a99f7so20188666ote.6; Tue, 26 Oct 2021 07:56:35 -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=qj70GYSq0i8aCMivup012WosAVDLGuh6+pF4v5HG7xA=; b=S98zowtdIKwbKat4u3LnfrnQvlSHEmP1eSXdvcYDD2kdBNempQx8yH0MWyJ8cyvWer p2eRW8Yf143NdfPXANaQMOyWJjrGevdpP+160RMYodc6QMbppZuHW3GqYdSscg1q57sH UvomHDWKokzYzdleIC+/As/yJzKmESLibGk9/4eSaL8Uy9Q4ZGrm0G/pJ1Z4T0if0NtU srU9s71EP+MIr8UlJPB4aphmg1SEoaHrH6GHQYszxC1p4Kvg92cE/qZk4maMKeLe6aX4 KL6lUz4P1v5ZM7o5SF4F2O+Ge1SVAtcHl9wQWIKM9jH0h4/yEJGUiHTWdrDg9FrDKza7 WhFw== 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=qj70GYSq0i8aCMivup012WosAVDLGuh6+pF4v5HG7xA=; b=VW5yCuRU9c3g+9NEcCDOS3bRJZ4vFgoAtKHIVseoo8kdVtAO7hY0vsB4lUG9Gsjli/ +eVAzeca/UxSgxMGXWneyq2er7teWbJYv5q4T7l4G9FYKI7FOODQniOjnxadyQupJw3K 08aTk8dWhIrFJXgqhIWnTqiIr+liIXZmBD7slErt4NlRMnw/PHzXaD/E/543FQEQKRSw 5cZnLPVjeCK24HOcEeRJsAmUWWSYIqYNn9fEdXVma+zaztu+VnmXhttMt7EQG2+CtT3I Tntsx8KFMmsCF0TsYVuEtCZdbEzXG1XSrLBgHBJUJPRV/Latpj7jEcTkPUD7CP8sueCw eYAg== X-Gm-Message-State: AOAM530lBAwpoq/xMD7m12geZiaG0RJM1WKMXdq8tm4XuM9lv9yNsXt8 asXLj12UnSAs3xcpcKoNPQ2uBze1EsPcZqz++Vs= X-Google-Smtp-Source: ABdhPJwwONnJOu7G5Pk1St24L3/INmTYxiDWzhv56l2D11Bt4DlDT82uXIzIJCHMIGuJRLUEyrUXFabXclEbLPwg8Dc= X-Received: by 2002:a9d:74d4:: with SMTP id a20mr32196otl.380.1635260192441; Tue, 26 Oct 2021 07:56:32 -0700 (PDT) MIME-Version: 1.0 References: <85fddbe9-4eb8-7d90-d246-a888fe8bdcd3@joelhalpern.com> <139d72fd-98de-f46a-767f-6a493c4facc9@joelhalpern.com> In-Reply-To: From: Erik Kline Date: Tue, 26 Oct 2021 10:56:21 -0400 Message-ID: To: "Joel M. Halpern" Cc: "ipv6@ietf.org" , "John G. Scudder" , "spring@ietf.org" , Martin Vigoureux , Alvaro Retana Content-Type: multipart/alternative; boundary="000000000000e2c7ad05cf42ae57" Archived-At: Subject: Re: [spring] Typo correction Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression 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, 26 Oct 2021 14:56:39 -0000 --000000000000e2c7ad05cf42ae57 Content-Type: text/plain; charset="UTF-8" Joel, One thing that could have been more clear (of many such things, no doubt)... On Mon, Oct 25, 2021 at 3:39 PM Erik Kline wrote: > [replying on this thread as is has more folks cc'd] > --- > > Next steps for consideration: > > [A] A separate 6MAN document to clarify and categorize SRv6 SIDs is > needed. We are happy to work to find authors for this document. > ... we have taken this action item to find authors for the 6MAN SRv6 SIDs document. We'll start reaching out to folks shortly. --000000000000e2c7ad05cf42ae57 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Joel,

    One thing th= at could have been more clear (of many such things, no doubt)...

    On Mo= n, Oct 25, 2021 at 3:39 PM Erik Kline <ek.ietf@gmail.com> wrote:
    [replying on this t= hread as is has more folks cc'd]
    ---

    Next steps f= or consideration:

    [A] A separate 6MAN document to clarify and catego= rize SRv6 SIDs is needed.=C2=A0 We are happy to work to find authors for th= is document.

    ... we have ta= ken this action item to find authors for the 6MAN SRv6 SIDs document.=C2=A0= We'll start reaching out to folks shortly.
    --000000000000e2c7ad05cf42ae57-- From nobody Tue Oct 26 10:55:52 2021 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 EB5AE3A15F3; Tue, 26 Oct 2021 10:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=iKTDiP8H; dkim=pass (1024-bit key) header.d=juniper.net header.b=Vc1+qgts 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 LbV4GcEuIXxp; Tue, 26 Oct 2021 10:55:34 -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 51CC83A15E6; Tue, 26 Oct 2021 10:55:34 -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 SMTP id 19QFodYN002973; Tue, 26 Oct 2021 10:55: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=MBC7rLtfDj6Iz5VI215wkdCG1TMDndnn2JEy0d6eYQU=; b=iKTDiP8HgVnU19l0GP36FfJ2w6NGXsU883nz4oDkmJjU/g2I3mYRfWB0U2O7ARI6BBqk pqT8qTcgUtKjD5Irribh1IQEHPIRjdKQTi18lrQzeUjNNwONi5eE8eLW/GmVNT0O0em7 0A6u1PMsk2To1xLKdHA49kqyAB76cE4OBEFxAIkFzEi4wtDSsOmIbSHijmKZo3pzv8n7 EttW6j/JEyJ1h0B6dCVSLgYL/hgwrr11C6Iz3fEeMoeDBgdvSd+5GT+5Jp+ygPMHl1lT dc00HFx7CZWSUi7Nz+LIIo4lBEAB7Y2+vBrsC/uTz7KK4vqckoNmw+PnyojkF3kyXUrT HQ== Received: from nam04-mw2-obe.outbound.protection.outlook.com (mail-mw2nam08lp2171.outbound.protection.outlook.com [104.47.73.171]) by mx0b-00273201.pphosted.com with ESMTP id 3bxmnx0a1r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Oct 2021 10:55:33 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PDToqtS3Uset1mN89vrKNpGhNV0rcjKCLhkxwuJeJcaCr0R4O1pmoeFqFNimT2lvhZzQziYHLWxcrgJSF3ExzO1bsHPZAeK/0Syh/rZDy4Qhz2cHST/rO4HVdeCNMhS16pI+YgT/dxi2x08ZBgNZKqV0p4z8Lhu9UcZsaCQZlzdBLeek/6p68+jhPQ8BODpJvvbyh3Aub7/XkalT+Par3qE5Zg2GpUIVMO5xnff0t2JcyI+5TgRiGhN8g5sQpEGfCXXxauRR2c2QBADmEGiwfSmQ+Xfv+Y5TOfrzUm1pWmxhzz+KH/df/sUJ+TdgF+xMBz8QLhgfzE2r5mL85btCXg== 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=MBC7rLtfDj6Iz5VI215wkdCG1TMDndnn2JEy0d6eYQU=; b=FHIsputgy2DMIDY5tqiSPeRYrWiecJgcAljIt1+/0awUFWtOGMNKVTuIO1XY8lDZ3ZSdPEBvAxJURhBjkmBTxNizaRRhGgZWVqsN2YX2XR4f/oZYatQKYqQ7LKoIasTeEpfV4Qo1qsqUWvoi7z7flwsU4yCWEb0A1T4YvdvGOVaDMrBq5J8wNyRtbU733hLQb8HeG+enEQP+g7cp9KZFodKBXC4Tf3PDOySAvMedXzgVB9qy9LJmy8ILRW3eaA3XKD0nxoKfM0xKgAWPSC63pHf44qTYsxgFR94lcYzif1wqxSVkcVRfE9AfDs0vWQagq7k8TttJkDn2nBFlVjOFQw== 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=MBC7rLtfDj6Iz5VI215wkdCG1TMDndnn2JEy0d6eYQU=; b=Vc1+qgtsPTKbfrt67Zu8uC4XNYmDn7TmNJaM+jQLcUkpi/hwOh+dTWyoftY4JHPMZDnlmCAbvGDPtgazvz+l7Wg8r9PIF+fnwRdVsOJ9YujsaY7Zo6cWZXReuJn9/jwdo7iTbF4hmE/7CeH+UHTOxoqPwtX46J5ztVG/W62KjKk= Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by MN2PR05MB6557.namprd05.prod.outlook.com (2603:10b6:208:df::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.10; Tue, 26 Oct 2021 17:55:30 +0000 Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::10b9:2bb9:11f2:6b4a]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::10b9:2bb9:11f2:6b4a%3]) with mapi id 15.20.4649.014; Tue, 26 Oct 2021 17:55:30 +0000 From: John Scudder To: "draft-filsfilscheng-spring-srv6-srh-compression@ietf.org" CC: "spring@ietf.org" Thread-Topic: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 Thread-Index: AQHXwIGtAQ5iI0HLYkm+pjy3rdbrTKvlpE+A Date: Tue, 26 Oct 2021 17:55:30 +0000 Message-ID: <1EB19A49-C12A-425D-ADB7-6E0B0F2CA66D@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.120.0.1.13) authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6b3d1141-3e24-415a-ad66-08d998a9ccfc x-ms-traffictypediagnostic: MN2PR05MB6557: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: b1xdJ4xYuDmFyLJb+p3C8piezyj+5D10vSBgaEjnf7dRraXdIYb/5Y01aj5ZVgJtLF9wNvzFsCDgwuYGTBSu77kQFeddCgvSGp0odC21YGI/DcJLHywXeX8hkhkKO9q5aPBudevcU7NBKoEyH15toyyk58+1EMM7EWRH/XXq9Bn1gnPB7f1JQZEv22NJiAvwDTmhIZrElaCqqV1VG0TCb/ZSXuLmHEsnwYoaw8atv6HNm4j/SSWVPJlwO2L75PTYO7sfU6x/1np+ft1yzbF6QnL0I9BPEWZuzzajlFxOmP0HHaup1mMBrDVeWRqi7UGExZCMk3dNJVRLBvEEZe6huZ5qhkFuObRQKugoGWv0vjzWtYR3G7OLhwgYYmSbpmY67FM0vanBr54zQKUGiVMfdS7QYyLjmX+gvcJFnOxRXYgXyEwEpZoCroys5neDpWEYgm3Bzc3rYrpwrk2ZJ0SrJ8CmObPrpaFW8q6dpCzH+SdPOO1JIywFdTwvvqqXLJbjtHrv+mluPgUFMfU0YeriRaoex1JdJ5oQZirDff4gFe9101tCIPbzV7hpuUsMUGOZq6STX2GE37YTriQLCoVtgH4KWYzeMfmMuj1UJ8jvDrD+JBgNo0iOiGmtjIXK327BNFeO5k2CAYyDyhFY2vD7gdkNQdXcdtbOboTZMCq+SVRzdEs5CuezbBmR7B514yrjwsoV3gYzMNByiOZF/Oc0eSD9/hJTPTFx9Tt4aqR7bHg4GgHPstvkqZ5pFv66XrZuZutbKX9r0b0LbAro9h5Aryzr4YMTBW3dXYDCdy1thoRuZKK5xhA5XWsSW76hDVu/ 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:(4636009)(366004)(186003)(66556008)(83380400001)(26005)(33656002)(91956017)(64756008)(5660300002)(66476007)(76116006)(8936002)(508600001)(4326008)(38070700005)(450100002)(66574015)(36756003)(6916009)(66446008)(2906002)(2616005)(966005)(6506007)(53546011)(66946007)(86362001)(38100700002)(122000001)(8676002)(71200400001)(316002)(6512007)(6486002)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?cmh0d3ZSYTNhaFpFWGRoVkVQYjQrWHRLL1QrYkdEZ2ZUUVdjSG54Y21MQXk5?= =?utf-8?B?bEVFYmdPVDhidzN0eWRybVF2bUZXSnFIdG5zS2dHWHBDWGdXcWpmMzBWaTdE?= =?utf-8?B?aGlMTEdMRTUvQmE1Z3JwWHJZM0cvMEdkZmFQdjBoMlNpb2FQL3M1TmJHd2pZ?= =?utf-8?B?ZE1zY0xmMFVzWjJGV3F4Qmtsc25qL2pJNTZCZjZRUkVqeGpjZ2oyNWNKM0pu?= =?utf-8?B?ZDZMT1JqRlpBZEJ1aWZCNm85QWIxSHZxbE1nOW9RUEY3bU9nUEROaHFEWmpy?= =?utf-8?B?bnZ1WW9HblpuTkxQUUNyMmRxNm5pVzkxRTdDYmxpYnE5SjR2d3RKbVpBeUtQ?= =?utf-8?B?bzZkUWFUWXFtc08xUlVIYXhWWWRKcTJvbE9VNUR6emtGTXR0b3A0aGpHSzBU?= =?utf-8?B?d2puYWNUQ0Z5OGIxQTljSFNqeUJDRXV4VUhGbXlNc0wwMWIreTY3ZlVWTklW?= =?utf-8?B?bkNDNzhHNGVzUGtPLzh2ZXZ5VDZtWGRnd1dmWXZ6R01SQkpNczRxMGV3SXhE?= =?utf-8?B?Q01ESU1wQVRkVURPSWt5dkY0RTRwTGtFaGV3dzZ3a1BCaXF0Q1ZmM0tNbDNZ?= =?utf-8?B?UXlsbmNpNkhaRU5QZ2Urc202STVtdi9PcEorbXk1TGpac0FnS3hHaVBDWFNr?= =?utf-8?B?RkpPUXpNS0U2bmFwU0hNSllsazVnNW9IOVpJRGNaNGFuRjhEQ2JvVzhVd2hD?= =?utf-8?B?Uk9UbTJRSFlBa2x0TW1nZUg4MTlOM0hmUmsyTGRKd2pvL1R5bFMrbXR0ZnR2?= =?utf-8?B?YUtJRURBTU5LZ0c2b0ZFZnJQdE5wM2grT015cGUvT2RFVWdmUTNWUXY4TXNu?= =?utf-8?B?dkR4UmFleGd2TEF4bml0OFJLY1U5clFsc1RmN0dTeXdCRGpjcW9tdG5UMjcx?= =?utf-8?B?eUtYODJPS3lLSkJFaFNFTEsxTGlqbGtqa2lJc1NjcW9lOU5TQ0ZjRGNneW41?= =?utf-8?B?ei9CcGdwdE1KZ3J2NEtWdC9UYnYrSmhFb2VPaXQ0Uzh5YXZFMWgxaGV5L3F0?= =?utf-8?B?b25HR0NTWGRwd2hiS1d4eGsxdnpHUGZJbzUyQVdvVStPT010S1VTR25xcm9q?= =?utf-8?B?NzdKS1F3U2F1YnFuQ1ByWUpyeTFVclJoczNPK3NWMC9wTk1rZml6MXI3UURV?= =?utf-8?B?eHJLUzNPS1hWVFNYd2R3d3RpbWdzdlRlMGFmKzdHNDFuTjlJUTJKSWFISlFu?= =?utf-8?B?VnpPQzdqSkNOT1g2WWVraHIySVdsdVhuVzFZMG9Zd05IWEl3cTZPUDd0aTlG?= =?utf-8?B?MWlYQi9JS2lxelpQNWFKTS9DOTBWTnV4S3djN0RKaGdQY1NSQ0RwQ3hTTGNQ?= =?utf-8?B?L3dvS04rM21IeEZpbWF6NUFuVG9laitKS0lvVGhBUXltKzZCeEI2OEl2WG5l?= =?utf-8?B?TkhyWGtwc0pkaFJSSXNGcnFFMVFTR3hTL0I2eXFoZnRqZFo3RCs5Yy83d0tk?= =?utf-8?B?aDU3RUo5Y3V6T09OK1R6NWloZUtXNTV0QjFtS0xxeHVrT3QzWWNJTlI3QUg5?= =?utf-8?B?VTQ1eHFPaldzckFmaStMNUlvOTlLM1Z6cDRrMmpDVnJtQUNCWVVON2RNdnlx?= =?utf-8?B?Mjc4U1hkdklsT2NsRmpndk9Zcy9lRWUzRTVVOG40NnN2RlI5YVlGeDFPZlJT?= =?utf-8?B?aW5zVVZoRFJoRXNBSjFWNVM3bUVLZmpYZXVTaTU0cTRSSjBpck5hdDBGZ2VF?= =?utf-8?B?cUJkbnF3ODg4VnAycUtZS01TRDJnTVJYcmNKUjQ5eU0xeXJlTHFjTEdGMUdu?= =?utf-8?B?OSt0ZkNrS0RKMWVyV0R4MThyckxBQlRacTg0VW5pY0VoVDZWOWM2UzBlektm?= =?utf-8?B?M0h6MVBtMElUYTlLZzY4WHF3WjBETnlmcEsySHova2c3MlJwN0JyTUF6SXRD?= =?utf-8?B?WGUxRUljN2hFb25ZeGkydkxUYjhMbnhXY3MzUFE4YzdKaGJwelh6MitFSkRs?= =?utf-8?B?c0RDRVVHaG9aL3UyVTIwTWFLcUhxcTJuWTEvWmRuSzkwUk1oVUtEVlgxY29p?= =?utf-8?B?WXk2Y0xVdFY2Y2Ftd1dCMDVVV3V3a1U5NVhLZ2xhNUZDdklTS1ZRR1MvVnln?= =?utf-8?B?c3lZWHBkNkJ5bVhIRk9nZ1Ird3NCTlhiakgwKys4bGY0ZkxxeFRaeU93Znhx?= =?utf-8?Q?UAcPhWa2c2oRGFxpPJbFyL/XY?= 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: 6b3d1141-3e24-415a-ad66-08d998a9ccfc X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2021 17:55:30.3853 (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: FFQkT6hde3GWsn6W3qe6VOwjvjYrOQSv/jW+2/cnjZWZyfhQsayDmsq1olwJyWQv X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6557 X-Proofpoint-GUID: glrnUHoSVkrM4SRPFo8o8I_R_3LfEv-l X-Proofpoint-ORIG-GUID: glrnUHoSVkrM4SRPFo8o8I_R_3LfEv-l X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-26_05,2021-10-26_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 suspectscore=0 malwarescore=0 bulkscore=0 clxscore=1015 adultscore=0 lowpriorityscore=0 impostorscore=0 priorityscore=1501 phishscore=0 mlxscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2110260099 Archived-At: Subject: Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 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, 26 Oct 2021 17:55:43 -0000 KEZvciBjbGFyaXR5OiBJ4oCZbSBub3Qgd2VhcmluZyBhbnkgaGF0cyBvdGhlciB0aGFuIOKAnFdH IGNvbnRyaWJ1dG9y4oCdLikNCg0KSGkgQWxsLA0KDQpTaW5jZSB0aGVyZSBoYXNu4oCZdCBiZWVu IGFueSBkZWZpbml0aXZlIGFuc3dlciBmcm9tIHRoZSBhdXRob3JzLCBub3IgYW55IHVwZGF0ZSB0 byB0aGUgZHJhZnQgdG8gYWRkcmVzcyB0aGUgaXNzdWUsIGFuZCBnaXZlbiB0aGF0IHRoZSBkaXNw dXRlZCBzdGF0ZW1lbnQgc2VlbXMgdG8gYmUgYW4gaW1wb3J0YW50IHByZW1pc2UgZm9yIGV2YWx1 YXRpb24gb2YgdGhlIGZpdG5lc3Mgb2YgdGhlIGRyYWZ0IGZvciBhZG9wdGlvbiAoYXQgbGVhc3Qs IHRoZSBhdXRob3JzIGNvbnNpZGVyZWQgaXQgZnVuZGFtZW50YWwgZW5vdWdoIHRvIHB1dCBpbiB0 aGUgYWJzdHJhY3QpOiBJ4oCZbSBvcHBvc2VkIHRvIGFkb3B0aW9uIG9mIHRoZSBkcmFmdCB1bnRp bCB0aGlzIHF1ZXN0aW9uIGhhcyBiZWVuIHNldHRsZWQsIG9yIGF0IGxlYXN0IG1lYW5pbmdmdWxs eSBhZGRyZXNzZWQuDQoNClJlZ2FyZHMsDQoNCuKAlEpvaG4NCg0KUC5TLjogSSB3aWxsIGFsc28g Zm9sbG93IHVwIHRvIHRoZSBtYWluIGFkb3B0aW9uIHRocmVhZCB0byBhc3Npc3Qgd2l0aCBpc3N1 ZSB0cmFja2luZy4NCg0KPiBPbiBPY3QgMTMsIDIwMjEsIGF0IDY6MjggUE0sIEpvaG4gU2N1ZGRl ciA8amdzPTQwanVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+IHdyb3RlOg0KPiANCj4gDQo+IEhp IEZvbGtzLA0KPiANCj4gSeKAmW0gc3RydWdnbGluZyB3aXRoIHRoZSBjbGFpbSByZXBlYXRlZCB0 aHJvdWdob3V0IHRoZSBiZWdpbm5pbmcgb2YgZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2 Ni1zcmgtY29tcHJlc3Npb24tMDIgKEFic3RyYWN0LCDCpzEsIMKnMykgdGhhdCDigJx0aGlzIHNv bHV0aW9uIGRvZXMgbm90IHJlcXVpcmUgYW55IFNSSCBkYXRhIHBsYW5lIGNoYW5nZeKAnS4NCj4g DQo+IEnigJltIG5vdCBhd2FyZSBvZiBhIHN0YW5kYXJkaXplZCBmb3JtYWwgZGVmaW5pdGlvbiBv ZiDigJxkYXRhIHBsYW5l4oCdLCBpdCBzZWVtcyB0byBmb2xsb3cgSnVzdGljZSBTdGV3YXJ04oCZ cyBtYXhpbSBvZiDigJxJIGtub3cgaXQgd2hlbiBJIHNlZSBpdOKAnS4gSG93ZXZlciwgaGVyZeKA mXMgYW4gYXR0ZW1wdCwgY3JpYmJlZCBmcm9tIHNvbWUgV2FzaGluZ3RvbiBVbml2ZXJzaXR5IGNv dXJzZSBzbGlkZXM6IGEg4oCcbG9jYWwsIHBlci1yb3V0ZXIgZnVuY3Rpb24gdGhhdCBkZXRlcm1p bmVzIGhvdyBhIGRhdGFncmFtIGFycml2aW5nIG9uIGEgcm91dGVyIGlucHV0IHBvcnQgaXMgZm9y d2FyZGVkIHRvIGEgcm91dGVyIG91dHB1dCBwb3J04oCdLiBTZWVtcyByZWFzb25hYmxlLg0KPiAN Cj4gSSBhbHNvIGFtIG5vdCBhd2FyZSBvZiBhIHN0YW5kYXJkaXplZCBmb3JtYWwgZGVmaW5pdGlv biBvZiB0aGUgdGVybSDigJxTUkggZGF0YSBwbGFuZeKAnSwgaW4gZmFjdCB0aGlzIGRyYWZ0LCBp dHMgcHJlZGVjZXNzb3JzLCBzb21lIGFzc29jaWF0ZWQgYmxvZyBwb3N0cywgYW5kIENsYXJlbmNl 4oCZcyBkaXNzZXJ0YXRpb24sIGFyZSB0aGUgb25seSBwbGFjZXMgYSBzZWFyY2ggZmluZHMgdGhl IHBocmFzZSAoYnV0IGl04oCZcyBub3QgZm9ybWFsbHkgZGVmaW5lZCBpbiBhbnkgb2YgdGhlbSku IFNvIEnigJltIGp1c3QgZ29pbmcgdG8gYXNzdW1lIGl0IG1lYW5zIHRoZSBkYXRhIHBsYW5lLCBh cyBhcHBsaWVkIHRvIHBhY2tldHMgdGhhdCBpbmNsdWRlIGFuIFNSSC4gKEnigJltIG5vdCBzdXJl IHdoeSB3ZSBzaG91bGQgZGlzcmVnYXJkIHBhY2tldHMgdGhhdCBhcmUgZW5jb2RlZCB1c2luZyBO RVhULUMtU0lEIHRoYXQgb21pdCB0aGUgU1JILCBidXQgbGV04oCZcyBvdmVybG9vayB0aGF0IGZv ciBub3cuKQ0KPiANCj4gSWYgdGhpcyBzb2x1dGlvbiBkb2VzIG5vdCByZXF1aXJlIGFueSBTUkgg ZGF0YSBwbGFuZSBjaGFuZ2UsIHByZXN1bWFibHkgaXQgd291bGQgYmUgdHJ1ZSB0aGF0IGlmIEkg dGFrZSBhIHBhY2tldCB0aGF0IGluY2x1ZGVzIGFuIFNSSCBhbmQgcGxhY2Ugd2l0aGluIGl0IGEg c2VyaWVzIG9mIFNJRHMgZW5jb2RlZCB3aXRoIChmb3IgZXhhbXBsZSkgdGhlIFJFUExBQ0UtQy1T SUQgZmxhdm9yLCB0aGVuIHRoYXQgcGFja2V0IHdvdWxkIGJlIGFibGUgdG8gc3VjY2Vzc2Z1bGx5 IHRyYXZlcnNlIGEgbmV0d29yayBvZiByb3V0ZXJzIHRoYXQgc3VwcG9ydCBwbGFpbiB2YW5pbGxh IFJGQyA4NzU0LiBUaGF0IGlzLCBpdCB3b3VsZCBhcnJpdmUgYXQgaXRzIGZpcnN0IGhvcCByb3V0 ZXIgd2hpY2ggYWNjb3JkaW5nIHRvIGEgbG9jYWwsIHBlci1yb3V0ZXIgZnVuY3Rpb24sIHdvdWxk IGRldGVybWluZSBob3cgdG8gdGFrZSB0aGUgZGF0YWdyYW0gYXJyaXZpbmcgb24gdGhlIHJvdXRl ciBpbnB1dCBwb3J0IGFuZCBmb3J3YXJkIGl0IHRvICh0aGUgY29ycmVjdCkgcm91dGVyIG91dHB1 dCBwb3J0LiBUaGVuIHRoYXQgcHJvY2VzcyB3b3VsZCBiZSByZXBlYXRlZCBhY3Jvc3MgdGhlIHJl c3Qgb2YgdGhlIG5ldHdvcmsuDQo+IA0KPiBCdXQgdGhhdCBpcyBwYXRlbnRseSBpbmNvcnJlY3Q6 IHdoZW4gaXTigJlzIGRlbGl2ZXJlZCB0byB0aGUgZmlyc3QgaG9wLCB0aGUgcGxhaW4gdmFuaWxs YSBSRkMgODc1NCByb3V0ZXIgd2lsbCBiZSB1bmFibGUgdG8gYXBwbHkgdGhlIFJFUExBQ0UtQy1T SUQgYmVoYXZpb3IsIGFuZCBmb3J3YXJkaW5nIHRvIHRoZSBuZXh0IGhvcCB3aWxsIGZhaWwuIEl0 IHNlZW1zIHRoYXQgYSBkaWZmZXJlbnQgbG9jYWwsIHBlci1yb3V0ZXIgZnVuY3Rpb24gaXMgcmVx dWlyZWQgKGluIGZhY3QsIHRoZSBsb2NhbCwgcGVyLXJvdXRlciBmdW5jdGlvbiBkZWZpbmVkIGlu IHRoZSBkcmFmdCkgaW4gb3JkZXIgZm9yIHRoZSBmb3J3YXJkaW5nIHRvIHN1Y2NlZWQuIEJ5IHRo ZSBkZWZpbml0aW9ucyBJ4oCZbSB1c2luZyBoZXJlLCB0aGF0IGlzIGV4YWN0bHkgYSBkYXRhIHBs YW5lIGNoYW5nZS4NCj4gDQo+IFdoYXQsIHByZWNpc2VseSwgaXMgdGhlbiBiZWluZyBjbGFpbWVk Pw0KPiANCj4gVGhhbmtzLA0KPiANCj4g4oCUSm9obg0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+IHNwcmlu Z0BpZXRmLm9yZw0KPiBodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmdfXzshIU5FdDZ5TWFPLWdrIVM3cmJuWWc2YVYy czNjeW9UQ0wzd3dXWDRicGJGb2F3UEx0NnlMZVlzbXM4MnNMbDl0VXBSVTFYNWMtRDlBJA0KDQo= From nobody Tue Oct 26 10:58:47 2021 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 CC6CE3A15EE; Tue, 26 Oct 2021 10:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=I6zpnaQ2; dkim=pass (1024-bit key) header.d=juniper.net header.b=AFETi9ED 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 Dc45ukTUPq64; Tue, 26 Oct 2021 10:58:41 -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 017463A15E6; Tue, 26 Oct 2021 10:58:40 -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 SMTP id 19Q8vP0t009057; Tue, 26 Oct 2021 10:58:38 -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=jQiwVZlkqJ9e9sJ2wGltWWHZuv+F5UE5Vg5zFoFnN8w=; b=I6zpnaQ2yMsXcfZhb3+/KLYkZo/icNJbe9EkpH4PJ58tzieVu1Sp7/HZ9ZDCQ64Sd0BD So6ey6h6E6M3A7zAeYNOxysm6ZYoYaj02BnehRGqfiii+L1+q/GsvUvXFi7juq+5ce95 t33uLa9fWia4In0PG4d6/hJNDfnoXqD7l07XYGWl3XsCbkr1ObjtvYGIav7iGu8QXAOt nF3Drl5Y++i+DmJRe5Mx3X1dQnCQTUL8VYQQVfCCdchWj+HHlYNbmfeC0xX8CaIQjK3q wBX+yd7exPAJg2Iutaf2favrUkf2yveB5coqjdlkEb4I6C9NEofTGgj6yiGxQcDMJA3m MA== Received: from nam04-bn8-obe.outbound.protection.outlook.com (mail-bn8nam08lp2043.outbound.protection.outlook.com [104.47.74.43]) by mx0b-00273201.pphosted.com with ESMTP id 3bxem7h8hh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Oct 2021 10:58:37 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PblpSmVN/Xsgt70wA0griWoOPIOVUPZevIfpGU3HSxAavM0L1Ioej0nK8iCEw5XdV1WHbPiSw1KYpFfdH6s8kVhPfdERMdLMC6P3gaVizoXqtKeIoLeM80sYDCpjAsfGe9YVQhT8aF+rzfnEkP/yESW4cRiQBCj+OMfgUtWk56BqDcmLsZHrUa5L9DyTrnMSqBIvtgsy7ukCoBQsax7kLaGBFQs4tGihfL+NYTPH0BYQ8gqo/WJkOgz0bOCxaZfQbChhgs3VwGTQDOXaW702tF8rlUiJ4qCLFriTT5Rd/B4iGAOf7mQPpvxiH4MkPfHWO8lvBt+ME+WL7dQ2Ug6uMA== 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=jQiwVZlkqJ9e9sJ2wGltWWHZuv+F5UE5Vg5zFoFnN8w=; b=JGQnhc7tUs3PHIsMc+7LhvqLmkWzVgzR3Dwm8WcHArBWC76yPm7lYim/YLSjXDnTgMCkAkto+TqixFxBoNuD/IuDbOuVbaDAtLo4I5L49Vkka7rUnsaLzBpvliM001Xw9nuOckkQt2dwOiiwMkuJ1xkE3yo4uscgoeec/Nl9UEEP/yHEMcYIuVcvt4GILD4ttdP6gpZPNSQbZiGXNPguNLpbvuPvMlcV4g+1sFQhH+d+vfVpoYth/8j1Np+7xE4F2Zq7yxgpc44AKBWI6HjwGQXfVOfGOxFmunR74mEjApl2YsWWGJzeOVj8HNoEuXuVPBKgxTOyxyBQum0mjniNXQ== 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=jQiwVZlkqJ9e9sJ2wGltWWHZuv+F5UE5Vg5zFoFnN8w=; b=AFETi9EDllO6YHmtSKJ02GTYUx+ryYkbeP7ELuI0Ucemfr4vwKRoUoX9847Walvpvjw+WMIK4+1yd3UvU1hMWm8eRTZ4y1xwauP4GWjCC7+Es0En8Y1NRm9al5uhjo3of2DM1pgUqiTC0ohammI3V6zu4OaiJqJzzV4OeQX70Ls= Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by MN2PR05MB6365.namprd05.prod.outlook.com (2603:10b6:208:dd::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.13; Tue, 26 Oct 2021 17:58:33 +0000 Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::10b9:2bb9:11f2:6b4a]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::10b9:2bb9:11f2:6b4a%3]) with mapi id 15.20.4649.014; Tue, 26 Oct 2021 17:58:33 +0000 From: John Scudder To: James Guichard CC: SPRING WG , "spring-chairs@ietf.org" Thread-Topic: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQTxzosA Date: Tue, 26 Oct 2021 17:58:33 +0000 Message-ID: <25BA4A4C-46D9-4F3C-B25C-0E8EA176139C@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3654.120.0.1.13) authentication-results: futurewei.com; dkim=none (message not signed) header.d=none;futurewei.com; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bcbd1664-e20c-46cc-a114-08d998aa39e8 x-ms-traffictypediagnostic: MN2PR05MB6365: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2MCrqXvQagOqlMeJiZ4FCPtWqg5uOXStBVURp6bwQiUtU6CBEO4afUnP+NdWFRz0wKGvWSys/dBlK3cLt1ueBFx3/or5lZsloJeJZCfgIsZNyDS+afQeD78+1Fx3uYPR9+uILhNjufCYkuBlE/K5nvA/9w0nv32TK+RG3p/N2pU1Qo+aJzTru4Uqz1TiNUs/Fhr9ypEM2nyGCHtpCQp0R84bPQoSIWzGKkE6d9B+EBEHyo9UoIUeWVuqLHH6BMGqkED0GiAgR3IFYJLxkD2g/dWoryRmPFBgZhbq8HKLzNGI+c0bXuNzAAIGlGJ250pwijIPi10pUJq/PK+IBTHrz9pzvpFDrM7PNp9SBfO8J6PWcS6VI1TTazDgZAb8k9Jvhz85wVYNexJ6R5nBQLCvOHxbfd4kKHGeVooOy3mJSgcO/HoLBp+XEaSqe1cp3I67Fg0Ufzetvx2qZAsjfQYyxNN3qM+4MwRh8BpzojsRJ2X3TvPl8EDWtvxxDDPP3J1uvA7vdMUxRE918sytyNHnHSb/I0K80VzEfLFWwS4yQmSZvXCPnkbwWQwoYRpOKIFT+JYAcE5d5UR5nFk09PVhNbeRJKcKmBPIsoqvI9Tyyve7j4K4RY6PMEILE+qQPlcbADnpQKWl5VQrmfjzzMGSTHHtHzp5tqT2kHBbUZW3JFx3C1fO0Lt+X6mE66vYwWcw/tY9O8Xukm1TgsjV3nv5irpm6dBA0wAmgBCCh30EvLbgeuFznk4ZWcrxdTfA1SfyyaGoyN+BqQBl18pccC8zBX2nruJ2S5KelzHb/f+UZRNMQSxTQiG71W+2T746IyVerb60JyAFp9udfKUkPKhpxSpBkJuDLcs+ANdz45wUd7Y= 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:(4636009)(366004)(316002)(66946007)(76116006)(66556008)(64756008)(53546011)(33656002)(6916009)(186003)(122000001)(66446008)(6486002)(6506007)(4326008)(66476007)(38100700002)(54906003)(8676002)(8936002)(2616005)(38070700005)(83380400001)(966005)(91956017)(71200400001)(36756003)(26005)(86362001)(6512007)(5660300002)(508600001)(2906002)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?QVFDc2RsZW1CVTFGdEo1eE1KTUJlYlRiZ0Z3TmpVbVpYZmwrd29YM0w1M1VI?= =?utf-8?B?aUgwR1JDa1c5NGtyL00yeWtvQUtOaUVBZ0loTklqSUtWeUx6bnZjcUxqOUtK?= =?utf-8?B?ejlLb0tpRUowcExDUU5aaFZ4YWpaUWxZdlRaN0VGZUVaVi9MbzU4WjFiRytw?= =?utf-8?B?S1h4TTBWanArNnVpcDlRUkdZN3NiZXQrSU5OdnZmanZQcGxTWjdXQzFYN3lh?= =?utf-8?B?STVZZkdFRlpDa1Q2U0p4dTNycS80VXZVNnNMQVpqS1hZQUQyTi9WNTRhcGFD?= =?utf-8?B?MlhqUXB0VkJYQU1wQnU3MC9WVWUwS090a2ZFYTF5cEJTV0t4QUF3TUNZZits?= =?utf-8?B?aGpJdmZGNGZxd2pLaGJteWtZblRLYjlQY2lCbmFzQjAzVG4wb3JWc0gzbStr?= =?utf-8?B?Q3RIblBrdHBzK1Y5enNPdmxYYWlGL3BWQmthZFBGOWpueGU5N2grN2I4MWZ3?= =?utf-8?B?bjFKTTMvU2VLUnhiRHNVT0dUY3VLKzFlcURNR1JhZkpJb3BEY0VyZlRldEEr?= =?utf-8?B?Qnp4ZmpwNVJaamdocjBRSGVoL3BnT0dqSkNpQUdGTmRsQTYvbmlvSm9UMzNZ?= =?utf-8?B?S0VUTGo3elI4UnJtVzdQQmcvQTlQcHJuTWJUVG1oVVZjM3IvVHRPL3QwazBm?= =?utf-8?B?bnRoK3hpQys3b05NcnlkTmhMUmVmYS9odzlIT1c1UzJQOWh5MFRBLzRKOTM4?= =?utf-8?B?MFhhKzQ5TjNPR0ZJb3A2aGxEdHFueTRpUkhONTZFWVJsRWkxZmdvR0dmUmlC?= =?utf-8?B?UktIc0R6V2YxOFdCMFliZEpRbGk3KzM2aWRZeFhZTFZTUVBIMVRkQy9oOVNO?= =?utf-8?B?ZldBQnQ4NG85cVZQQzFiY3YyNGpLWVpnK0hBM1I1dk5BTThTejE5QjNPUndv?= =?utf-8?B?RmVRRGsvNFVQY0x4Qk5qNVRDb2VySDJXcVdoN2JEU3A4ZVFaK1dLMm94ZU9H?= =?utf-8?B?RzBTK1VkNmkyTlhBeGpwQXc2T3pQYWlWSUVwaGd1bTN1MnNtREluakgxa1Z4?= =?utf-8?B?MS9MRGhvaHJDVUhSR0JzaklEYVB3YVMvcE1hSTBSVlZnT25OSHJzWkdoUjhE?= =?utf-8?B?WFlzNUpUSHRkaDV3WUVuTmp3UFhGU1BWVnhnbnR1WkpseURHbCtsQ01NWmVG?= =?utf-8?B?bG41WTZaYlVjNER0ZDZxdXpnOVRMVW5UMHBFOWdFTWVkYnNybWFXZzFkSWM4?= =?utf-8?B?THNrZmdhUCtNYnRwTXoyT2ZCcHY1cGlRTXVBMnlOR01VbUI0eTN2UU8rUFdI?= =?utf-8?B?UkhJdXlYeVVFbVFYSUlkNTNaVDJMdXlZcWpGU2NVUVB2dEZJbkNHaXhrclVQ?= =?utf-8?B?RDRRRUtMRWE5S2lKRmdjblE1cDB0aUh0ZWp5Rms0TTdiOEVyTVJwNmFabGd3?= =?utf-8?B?bU5Vbm04cllJY1dHYkJvOUlZNkU5dWkwNTV6U1AyYlU5YkdCQXdad3Z3VzND?= =?utf-8?B?VnpVSzljb3BFVkFLRXJPZEY4YlhXd2xEaTVtMU5rSEJvYzVBMlMxUjZlcjl5?= =?utf-8?B?WjA5czR0OVdsVmFSczV1VGtSRDRyWlZJOWdmREtHSVV5Y1pMeFNhMkh6aU1Z?= =?utf-8?B?VWlNWGh5TmltZ1N3aGZ4a0ZEVUxrMWV3WFBpbFhIbVhjMCs1Y0RkSTNWZTQx?= =?utf-8?B?SS9TT0hrYjJZV09nRFppNXd4bzByQlkzYitPc0lOK1JiaTFZU0FoYTRvTnVT?= =?utf-8?B?YTVwcVdxMzRndUFxa1pLOG5RQ3JyUWJiV0hTeFdZWjdIeXNEYjdyVnFZRU9t?= =?utf-8?B?b2lkQU54NzMrSVJqWllMZXNheVd6STYvcy9DclZNVjdHTHBxQmtzZ3NaUmoy?= =?utf-8?B?Tm9UTHM4RXJ5QjEwd0hIVUVTTHAzRWFad2x2OXowbkk3eUdJV0FXNXFEZHcz?= =?utf-8?B?NVltNUUra3Q0emhCM3hiMWpNdWRzM1pkUFd3ajNDQ3o2TXN1RFVNU1VYdE1x?= =?utf-8?B?NjB3UE9id1lDMWcrTHFobzExbWZiT2dwMmJMSEovMjY0eVBaNmx6c1VqWVZl?= =?utf-8?B?dEN6OTJDWHBWWldnYU44czlxNUdnTGh3MWVTaXgzc0lXR3lUaHhuR3lDUzhC?= =?utf-8?B?ektTY2lDNUlCOEJpRUIyUWx1MGc2aTdCejhtMUtlOEJjTTRJRWFLWk4vZHI1?= =?utf-8?Q?8VxDb7wzRYOTYasXVZkw/2cwF?= Content-Type: text/plain; charset="utf-8" Content-ID: <5390100F93E6FB46A9602474B64F44B0@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: bcbd1664-e20c-46cc-a114-08d998aa39e8 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2021 17:58:33.1365 (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: bGkYZDyPXvZk7GTvAP/Lfn6aqnkKK+jWWJ+SLDkOVbfqm4jzmAcr5uXgcjVGqcvR X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6365 X-Proofpoint-GUID: M8l8Rvlf1PPyiQWCbwhxPWtRXY6Ls5k9 X-Proofpoint-ORIG-GUID: M8l8Rvlf1PPyiQWCbwhxPWtRXY6Ls5k9 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-26_05,2021-10-26_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 adultscore=0 mlxscore=0 malwarescore=0 lowpriorityscore=0 suspectscore=0 spamscore=0 priorityscore=1501 bulkscore=0 clxscore=1011 mlxlogscore=999 phishscore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2110260100 Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 26 Oct 2021 17:58:46 -0000 KEZvciBjbGFyaXR5OiBJ4oCZbSB3ZWFyaW5nIG5vIGhhdHMgb3RoZXIgdGhhbiDigJxXRyBjb250 cmlidXRvcuKAnS4pDQoNCkFzIG5vdGVkIGluIGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcv YXJjaC9tc2cvc3ByaW5nLzVIRjR3TTVaRGN3NURlTF9rbFhtS2YxVVAwRS8sIEnigJltIG9wcG9z ZWQgdG8gYWRvcHRpb24gdW50aWwgdGhlIGlzc3VlIHJhaXNlZCB0aGVyZSBoYXMgYmVlbiBhZGRy ZXNzZWQuIChSZXBlYXRpbmcgdGhlIHBvaW50IGhlcmUgdG8gYWlkIGluIGlzc3VlIHRyYWNraW5n LikNCg0KUmVnYXJkcywNCg0K4oCUSm9obg0KDQo+IE9uIE9jdCAxLCAyMDIxLCBhdCAxMDowNCBB TSwgSmFtZXMgR3VpY2hhcmQgPGphbWVzLm4uZ3VpY2hhcmRAZnV0dXJld2VpLmNvbT4gd3JvdGU6 DQo+IA0KPiANCj4gRGVhciBXRzoNCj4gIA0KPiBUaGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gZXhw cmVzcyB0aGVpciBhcHByZWNpYXRpb24gZm9yIGFsbCB0aGUgcmVzcG9uc2VzIHJlY2VpdmVkIHRv IG91ciBlbWFpbHMgd2l0aCByZWZlcmVuY2UgdG8gaG93IHRoZSB3b3JraW5nIGdyb3VwIHdpc2hl cyB0byBtb3ZlIGZvcndhcmQgd2l0aCByZXNwZWN0IHRvIGEgc29sdXRpb24gZm9yIFNSdjYgY29t cHJlc3Npb24uDQo+ICANCj4gVGhlIGFwcGFyZW50IGluY2xpbmF0aW9uIG9mIHRoZSB3b3JraW5n IGdyb3VwIGlzIHRvIHVzZSBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1m aWxzZmlsc2NoZW5nLXNwcmluZy1zcnY2LXNyaC1jb21wcmVzc2lvbi8gYXMgdGhlIGJhc2lzIGZv ciBpdHMgY29tcHJlc3Npb24gc3RhbmRhcmRpemF0aW9uIHdvcmsuIFRoYXQgaXMgcGFydCBvZiB3 aGF0IHRoaXMgZW1haWwgYXR0ZW1wdHMgdG8gY29uZmlybS4NCj4gIA0KPiBCZWNhdXNlIG9mIHRo ZSBhYm92ZSB0aGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gaXNzdWUgYSAyLXdlZWsgV0cgY2FsbCBm b3IgYWRvcHRpb24gZW5kaW5nIE9jdG9iZXIgMTV0aCBmb3IgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Np b24vIGJ1dCB3aXRoIHNvbWUgY2xlYXIgZ3VpZGVsaW5lcyBhcyBmb2xsb3dzLiBCeSBleHByZXNz aW5nIHN1cHBvcnQgZm9yIGFkb3B0aW9uIG9mIHRoaXMgZG9jdW1lbnQgeW91IGFyZSBmdWxseSBh d2FyZSBvZiBhbmQgYXJlIGFja25vd2xlZGdpbmcgdGhhdDoNCj4gIA0KPiAJ4oCiIFRoZSBTUFJJ Tkcgd29ya2luZyBncm91cCBpcyBhZG9wdGluZyBhIGRvY3VtZW50IHRoYXQgaGFzIG11bHRpcGxl IFNSdjYgRW5kcG9pbnQgYmVoYXZpb3JzLg0KPiAJ4oCiIFRoZSBkb2N1bWVudCBpcyBhIOKAnGxp dmluZ+KAnSBkb2N1bWVudDsgaXQgbWF5IGNoYW5nZSBhcyBpdCBnb2VzIHRocm91Z2ggcmV2aWV3 IGFuZCBhbmFseXNpcyBieSB0aGUgU1BSSU5HIHdvcmtpbmcgZ3JvdXAuDQo+IAnigKIgQWxsIG9w ZW4gZGlzY3Vzc2lvbiBwb2ludHMgcmFpc2VkIG9uIG91ciBtYWlsaW5nIGxpc3QgTVVTVCBiZSBh ZGRyZXNzZWQgQkVGT1JFIHNhaWQgZG9jdW1lbnQgaXMgYWxsb3dlZCB0byBwcm9ncmVzcyBmcm9t IHRoZSB3b3JraW5nIGdyb3VwIHRvIHB1YmxpY2F0aW9uLiBBIGxpc3Qgb2YgdGhlc2UgZGlzY3Vz c2lvbiBwb2ludHMgd2lsbCBiZSBkb2N1bWVudGVkIGluIHRoZSBXRyBkb2N1bWVudCBhbmQgbWFp bnRhaW5lZCBieSB0aGUgZG9jdW1lbnQgZWRpdG9yIGluIGNvbmp1bmN0aW9uIHdpdGggdGhlIGNo YWlycy4NCj4gCeKAoiBJZiB0aGlzIGRvY3VtZW50IGlzIGFkb3B0ZWQgYnkgdGhlIHdvcmtpbmcg Z3JvdXAsIHRoZSBjaGFpcnMgc3BlY2lmeSBhcyBwYXJ0IG9mIHRoZSBhZG9wdGlvbiBjYWxsIHRo YXQgdGhlIGZvbGxvd2luZyB0ZXh0IGRlc2NyaWJpbmcgYW4gb3BlbiBpc3N1ZSBiZSBhZGRlZCB0 byB0aGUgZG9jdW1lbnQgaW4gdGhlIGFib3ZlLWRlc2NyaWJlZCBvcGVuIGlzc3VlcyBzZWN0aW9u Og0KPiAJCeKAoiAiR2l2ZW4gdGhhdCB0aGUgd29ya2luZyBncm91cCBoYXMgc2FpZCB0aGF0IGl0 IHdhbnRzIHRvIHN0YW5kYXJkaXplIG9uZSBkYXRhIHBsYW5lIHNvbHV0aW9uLCBhbmQgZ2l2ZW4g dGhhdCB0aGUgZG9jdW1lbnQgY29udGFpbnMgbXVsdGlwbGUgU1J2NiBFbmRQb2ludCBiZWhhdmlv cnMgdGhhdCBzb21lIFdHIG1lbWJlcnMgaGF2ZSBzdGF0ZWQgYXJlIG11bHRpcGxlIGRhdGEgcGxh bmUgc29sdXRpb25zLCB0aGUgd29ya2luZyBncm91cCB3aWxsIGFkZHJlc3Mgd2hldGhlciB0aGlz IGlzIHZhbGlkIGFuZCBjb2hlcmVudCB3aXRoIGl0cyBvbmUgZGF0YSBwbGFuZSBzb2x1dGlvbiBv YmplY3RpdmUuIi4NCj4gIA0KPiBQbGVhc2UgY29uc2lkZXIgdGhlIGFib3ZlIGd1aWRlbGluZXMg YXMgeW91IGRlY2lkZSBvbiB3aGV0aGVyIHRvIHN1cHBvcnQgb3Igbm90IHRoaXMgV0cgYWRvcHRp b24uIFBsZWFzZSBleHByZXNzIGNsZWFybHkgeW91ciByZWFzb25pbmcgZm9yIHN1cHBvcnQvbm9u LXN1cHBvcnQgYXMgd2VsbCBhcyBhbnkgb3BlbiBkaXNjdXNzaW9uIHBvaW50cyB5b3Ugd291bGQg bGlrZSBhZGRyZXNzZWQgc2hvdWxkIHRoZSBkb2N1bWVudCBiZSBhZG9wdGVkIGludG8gdGhlIHdv cmtpbmcgZ3JvdXAuDQo+ICANCj4gVGhhbmtzIQ0KPiAgDQo+IEppbSwgQnJ1bm8gJiBKb2VsDQo+ ICANCj4gIA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+IHNwcmluZ0BpZXRmLm9yZw0KPiBodHRwczovL3Vy bGRlZmVuc2UuY29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z cHJpbmdfXzshIU5FdDZ5TWFPLWdrIVhSWmRmUmhPaWk4OUlJOE12N2w1WUt4RkhacXNBWi1Bc3Rz VHRXYTNyemd6c2wzbHFTLU5iWE1jRWhfNG9BJA0KDQo= From nobody Tue Oct 26 12:41:25 2021 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 B27363A17BC for ; Tue, 26 Oct 2021 12:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 dqCeGI3mNuFE for ; Tue, 26 Oct 2021 12:41:18 -0700 (PDT) Received: from mail-ua1-x935.google.com (mail-ua1-x935.google.com [IPv6:2607:f8b0:4864:20::935]) (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 9D5E23A17BE for ; Tue, 26 Oct 2021 12:41:18 -0700 (PDT) Received: by mail-ua1-x935.google.com with SMTP id s4so624482uaq.0 for ; Tue, 26 Oct 2021 12:41:18 -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=HN/UaM5CzvUwJkw7QkM3W4w60ikTNWW6kKrASta4emk=; b=KmNhintXBjkLeUGJRVgItx+h/wnophvXWFW61erIz6mgMnuoBy4i8c9IRo69sV1m7Q WMd8phWAn5yWzD2WZ8o+oOmfTeaWUM7eUNiTLbGrIwxL+rvzxqKxT34jm3D7F+c49/0o aTjc0upjZHpH+B/XLBcSlp+EOVcEKPWMKDOGtuGVZLwJ9rraHu5zmGbYX6Q6TSOF8JQp DgP10/lc7JWxsOkYSJvnBSKQCIixUF2/uEMqm5L1zCu7p+pGDU86r/i0PIiIQqw1UA3y kVsQ9g0dUgkYwkngkvZlUbmEZ/5GSBlI5rd3k+EScgQRksk/VWz0uxlo4czxA4VPEC+0 B3yg== 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=HN/UaM5CzvUwJkw7QkM3W4w60ikTNWW6kKrASta4emk=; b=eejvJEDBGA00ecD44uTEsWGiSCR8qzRuhjg7NuuIv6MqCssxNxpy7Ovy4oIpkqf2dL PLhR1VEJjnHigI+LnWX7PDNbO5zXZF16TOEHJ8kgacp3xjDNFv5jBCQnPEjHp4o7CZRG 2nt9xVEEUWAtrEvSA/svl4qEKXHlB+iA0wKWJ67YB4gkRRFI9qeDgoUvKOZL3Gmzl2kK NamyXIqMO12xmykzlKmJDtGgWEH08nJmhSOZhc3Vj5OpAHM8f7zPIEoAgSeJ8tq81gLF aqJQ9Sq5Samm0M2HivsF12wg7tU2J2kmf4dBBv59VrWLzl5neH11r77X5Yok04oTwftI 4L+Q== X-Gm-Message-State: AOAM531iBlAKYCxz4M5OJap8aWNs5MPl9AyrOLK/k22qeK+BbOK+Y4xb TX54lNbWS9/L+rAAIYhvFvHcHcvS6+C8VkzDGr7cuA== X-Google-Smtp-Source: ABdhPJyTVdvuMvvlq+yi2qAXEV+zj15b1TORRts5wf9f92JAVZ3mV693PLVmWHYK/q4CYrZFNSOEk7e/7oJPl4Rct8U= X-Received: by 2002:ab0:63d7:: with SMTP id i23mr25545950uap.116.1635277277181; Tue, 26 Oct 2021 12:41:17 -0700 (PDT) MIME-Version: 1.0 References: <1EB19A49-C12A-425D-ADB7-6E0B0F2CA66D@juniper.net> In-Reply-To: <1EB19A49-C12A-425D-ADB7-6E0B0F2CA66D@juniper.net> From: Robert Raszuk Date: Tue, 26 Oct 2021 21:41:14 +0200 Message-ID: To: John Scudder Cc: "draft-filsfilscheng-spring-srv6-srh-compression@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003750d505cf46a994" Archived-At: Subject: Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 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, 26 Oct 2021 19:41:24 -0000 --0000000000003750d505cf46a994 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello John, May I inquire what was not definitive as part of my answer ? Please observe that below documents which are product of this WG go in depth to evaluate compression against the requirement not to change SRv6 data plane: https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression -requirement https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression -analysis Would your enquiry be satisfied if the draft in question s/SRH data plane/SRv6 data plane/ ? Kind regards, Robert On Tue, Oct 26, 2021 at 7:55 PM John Scudder wrote: > (For clarity: I=E2=80=99m not wearing any hats other than =E2=80=9CWG con= tributor=E2=80=9D.) > > Hi All, > > Since there hasn=E2=80=99t been any definitive answer from the authors, n= or any > update to the draft to address the issue, and given that the disputed > statement seems to be an important premise for evaluation of the fitness = of > the draft for adoption (at least, the authors considered it fundamental > enough to put in the abstract): I=E2=80=99m opposed to adoption of the dr= aft until > this question has been settled, or at least meaningfully addressed. > > Regards, > > =E2=80=94John > > P.S.: I will also follow up to the main adoption thread to assist with > issue tracking. > > > On Oct 13, 2021, at 6:28 PM, John Scudder 40juniper.net@dmarc.ietf.org> wrote: > > > > > > Hi Folks, > > > > I=E2=80=99m struggling with the claim repeated throughout the beginning= of > draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, =C2=A71, = =C2=A73) that > =E2=80=9Cthis solution does not require any SRH data plane change=E2=80= =9D. > > > > I=E2=80=99m not aware of a standardized formal definition of =E2=80=9Cd= ata plane=E2=80=9D, it > seems to follow Justice Stewart=E2=80=99s maxim of =E2=80=9CI know it whe= n I see it=E2=80=9D. > However, here=E2=80=99s an attempt, cribbed from some Washington Universi= ty course > slides: a =E2=80=9Clocal, per-router function that determines how a datag= ram > arriving on a router input port is forwarded to a router output port=E2= =80=9D. > Seems reasonable. > > > > I also am not aware of a standardized formal definition of the term =E2= =80=9CSRH > data plane=E2=80=9D, in fact this draft, its predecessors, some associate= d blog > posts, and Clarence=E2=80=99s dissertation, are the only places a search = finds the > phrase (but it=E2=80=99s not formally defined in any of them). So I=E2=80= =99m just going to > assume it means the data plane, as applied to packets that include an SRH= . > (I=E2=80=99m not sure why we should disregard packets that are encoded us= ing > NEXT-C-SID that omit the SRH, but let=E2=80=99s overlook that for now.) > > > > If this solution does not require any SRH data plane change, presumably > it would be true that if I take a packet that includes an SRH and place > within it a series of SIDs encoded with (for example) the REPLACE-C-SID > flavor, then that packet would be able to successfully traverse a network > of routers that support plain vanilla RFC 8754. That is, it would arrive = at > its first hop router which according to a local, per-router function, wou= ld > determine how to take the datagram arriving on the router input port and > forward it to (the correct) router output port. Then that process would b= e > repeated across the rest of the network. > > > > But that is patently incorrect: when it=E2=80=99s delivered to the firs= t hop, > the plain vanilla RFC 8754 router will be unable to apply the REPLACE-C-S= ID > behavior, and forwarding to the next hop will fail. It seems that a > different local, per-router function is required (in fact, the local, > per-router function defined in the draft) in order for the forwarding to > succeed. By the definitions I=E2=80=99m using here, that is exactly a dat= a plane > change. > > > > What, precisely, is then being claimed? > > > > Thanks, > > > > =E2=80=94John > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring_= _;!!NEt6yMaO-gk!S7rbnYg6aV2s3cyoTCL3wwWX4bpbFoawPLt6yLeYsms82sLl9tUpRU1X5c-= D9A$ > > --0000000000003750d505cf46a994 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hello John,

    May I inquire what was not = definitive as part of my answer ?=C2=A0

    Please obs= erve that below documents which are product of this WG go in depth to evalu= ate compression against the requirement not to change SRv6 data plane:=C2= =A0

    https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement

    https://datatracker.ietf.org/doc/html/draft-srcom= pdt-spring-compres= sion-analysis


    Would your enquiry be satisfied if the draft in question s/S= RH data plane/SRv6 data plane/ ?=C2=A0


    Kind regards,

    Robert




    <= div class=3D"gmail_quote">
    On Tue, Oct= 26, 2021 at 7:55 PM John Scudder <jg= s@juniper.net> wrote:
    (For clarity: I=E2=80=99m not wearing any hats other than =E2= =80=9CWG contributor=E2=80=9D.)

    Hi All,

    Since there hasn=E2=80=99t been any definitive answer from the authors, nor= any update to the draft to address the issue, and given that the disputed = statement seems to be an important premise for evaluation of the fitness of= the draft for adoption (at least, the authors considered it fundamental en= ough to put in the abstract): I=E2=80=99m opposed to adoption of the draft = until this question has been settled, or at least meaningfully addressed.
    Regards,

    =E2=80=94John

    P.S.: I will also follow up to the main adoption thread to assist with issu= e tracking.

    > On Oct 13, 2021, at 6:28 PM, John Scudder <jgs=3D40juniper.net@dmarc.ietf.or= g> wrote:
    >
    >
    > Hi Folks,
    >
    > I=E2=80=99m struggling with the claim repeated throughout the beginnin= g of draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, =C2=A71,= =C2=A73) that =E2=80=9Cthis solution does not require any SRH data plane c= hange=E2=80=9D.
    >
    > I=E2=80=99m not aware of a standardized formal definition of =E2=80=9C= data plane=E2=80=9D, it seems to follow Justice Stewart=E2=80=99s maxim of = =E2=80=9CI know it when I see it=E2=80=9D. However, here=E2=80=99s an attem= pt, cribbed from some Washington University course slides: a =E2=80=9Clocal= , per-router function that determines how a datagram arriving on a router i= nput port is forwarded to a router output port=E2=80=9D. Seems reasonable.<= br> >
    > I also am not aware of a standardized formal definition of the term = =E2=80=9CSRH data plane=E2=80=9D, in fact this draft, its predecessors, som= e associated blog posts, and Clarence=E2=80=99s dissertation, are the only = places a search finds the phrase (but it=E2=80=99s not formally defined in = any of them). So I=E2=80=99m just going to assume it means the data plane, = as applied to packets that include an SRH. (I=E2=80=99m not sure why we sho= uld disregard packets that are encoded using NEXT-C-SID that omit the SRH, = but let=E2=80=99s overlook that for now.)
    >
    > If this solution does not require any SRH data plane change, presumabl= y it would be true that if I take a packet that includes an SRH and place w= ithin it a series of SIDs encoded with (for example) the REPLACE-C-SID flav= or, then that packet would be able to successfully traverse a network of ro= uters that support plain vanilla RFC 8754. That is, it would arrive at its = first hop router which according to a local, per-router function, would det= ermine how to take the datagram arriving on the router input port and forwa= rd it to (the correct) router output port. Then that process would be repea= ted across the rest of the network.
    >
    > But that is patently incorrect: when it=E2=80=99s delivered to the fir= st hop, the plain vanilla RFC 8754 router will be unable to apply the REPLA= CE-C-SID behavior, and forwarding to the next hop will fail. It seems that = a different local, per-router function is required (in fact, the local, per= -router function defined in the draft) in order for the forwarding to succe= ed. By the definitions I=E2=80=99m using here, that is exactly a data plane= change.
    >
    > What, precisely, is then being claimed?
    >
    > Thanks,
    >
    > =E2=80=94John
    > _______________________________________________
    > spring mailing list
    > spring@ietf.org
    >     https://urldefense= .com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!S7rb= nYg6aV2s3cyoTCL3wwWX4bpbFoawPLt6yLeYsms82sLl9tUpRU1X5c-D9A$

    --0000000000003750d505cf46a994-- From nobody Tue Oct 26 13:01:49 2021 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 15CE03A183D; Tue, 26 Oct 2021 13:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=Q9PdYOUa; dkim=pass (1024-bit key) header.d=juniper.net header.b=eHtheZXR 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 l-nEUlOHJCgp; Tue, 26 Oct 2021 13:01:43 -0700 (PDT) Received: from mx0b-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 EFF7E3A1838; Tue, 26 Oct 2021 13:01:42 -0700 (PDT) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19QCxjj7006236; Tue, 26 Oct 2021 13:01:41 -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=QacftNz64w9FenSmQ440u7X2dw8e0z7nhHnip3HP3IA=; b=Q9PdYOUaehbJ1uARD/nMZYICpiTXYRLPlcZV+4wNoNEFYS16NmVAsBntCmT4308BoIfi yodstT17CL1lrK9uxDzKa12ukDz6ymz3Fu3GLcWiegVbga9HRLr3AkdXZ1mCNDBR15yw TF9ZW9VkZEfkbxlCoy4MvwI+cLVsTf3cK9MsGLcfzo4cfpFRFxAOWhQf76J+KfRAE1Fg svQxduSWh0IX8QB7Fbgj1gkRM3ncY+fGO+ddevh3uncyUvkDVCRtaBcf1bPJsBhUxFk4 qbPyf7U/7CzQ4wqTb0opOCOdXFur+zH5P8v0N7DshckCFN7TllTIogVVFnqP8eYE93TA ng== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1anam02lp2049.outbound.protection.outlook.com [104.47.57.49]) by mx0a-00273201.pphosted.com with ESMTP id 3bxj5tryn6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Oct 2021 13:01:40 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mVdc1AyMvTHDI5fiHaBhhQJMGRyI4ssLsBi62oX55rzkxlKCbuD0QMC1yvpOT9PnnhWyIkIthZg9e2DNKz5K39AumqTMdWMVOG9g8a8w4PDS1tONPy6WGEcbftKqvZFE7CZQ2Cwm8+2debT/AviZQD1nTqjL25YxwU9KeLy0UHRYQdEOYh07hd7mw5ReKE2f4+RXkh3SMqPkGULMTFh3DcdDJ6wV8oscbrokSt5uvJxEx3MKLWwjyDlzNSrDM8bci3DEPDkZaKs24A5WdEeL+1dA8JD2fY31yUOzXHVZNUu//566ju3o2NKFUlj9DLuFlds6A13YTzNL1FKun+P0dg== 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=QacftNz64w9FenSmQ440u7X2dw8e0z7nhHnip3HP3IA=; b=Xli2XbvNa9o5Vy9urR4Y6Xge1BfLLJsPuzV1BzVCYySa48HUZv1XpxcjKLqrT0bEUlbHRYqvE5BUj1f1M5qy+P99T72uP90hkW0jPlly20onGUH1QWqNUiW/eeKiSJOsWARphjAwg9Zr5hksPtLhn5jARvZjkADEhXt7YnnPtBtu4/2fHgw0xd52eqiBcmKswb7uJ//NZg1ACjhF4ul7JJdOIm/iLtPKDfd5xXKZaPOnUwhDFeOV0wRnkdZqpjPnmBT8pTLDVHy3DKMrVp+t1VaateqmTyLXzjF3M4gx9a6dX1N8c0UdDiCgsHlr4coLlfQQt9W0NTHzjfMj/j683g== 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=QacftNz64w9FenSmQ440u7X2dw8e0z7nhHnip3HP3IA=; b=eHtheZXRA1fBFwearnt11PiqH3DHrty0wdIlkioPs6Ie2losuB2g7C+DVo+LIyOaf1Oghmt20zYlPFArD37/hH/O6TwaDerTPAEjFobhMBVrETYwEwf3Fa3/zz6hDBliejv9OrVg/8uCulMsoWZZaMiSrUGwIgEoMmlns2oTNsY= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by BL0PR05MB5649.namprd05.prod.outlook.com (2603:10b6:208:66::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.11; Tue, 26 Oct 2021 20:01:33 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4649.014; Tue, 26 Oct 2021 20:01:33 +0000 From: Ron Bonica To: Robert Raszuk , John Scudder CC: "draft-filsfilscheng-spring-srv6-srh-compression@ietf.org" , "spring@ietf.org" Thread-Topic: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 Thread-Index: AQHXwIGtGfUetDOXlk+YPM+Rvcp8k6vlpFEAgAAdigCAAAWBsA== Date: Tue, 26 Oct 2021 20:01:32 +0000 Message-ID: References: <1EB19A49-C12A-425D-ADB7-6E0B0F2CA66D@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.300.5 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-26T20:00:55Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=71041bd6-3578-4e34-b72e-d796cd1ccd18; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_enabled: true msip_label_0633b888-ae0d-4341-a75f-06e04137d755_setdate: 2021-10-26T20:01:31Z msip_label_0633b888-ae0d-4341-a75f-06e04137d755_method: Standard msip_label_0633b888-ae0d-4341-a75f-06e04137d755_name: 0633b888-ae0d-4341-a75f-06e04137d755 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_siteid: bea78b3c-4cdb-4130-854a-1d193232e5f4 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_actionid: 413fbf51-6c66-4b0d-9ed2-46065f9496a6 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_contentbits: 0 authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2e1f607b-d48f-4d5f-0775-08d998bb6899 x-ms-traffictypediagnostic: BL0PR05MB5649: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XbvbywpzrZTuPpN7sdW1d8xlT4wY2uf/hMQ+2KTybTJz/jW3NDxIuCAJEd+Sa2MgfLG6LfMsuxdOHIJT2S/30Kw6tn8y8/xJ4nt3qXIS/EYZQdQ4t0PbP2qVdOF4l4GAKonfY5FTPW1KeY3s4d/1eI9x9LEe8T2CcrT6+pvsTZBYtI+AOaQqVqafsAR+PfP1SdW0sW0zPf4ik5fuucLNdUKUuZ+1eataQJjcOoR5K8Q8ZssyHu1akreqDBU2EzYFL7p6gBk6S0UFz6kmBLMOHXDOyFRMRC456zvz4leGWLgZSKOyyCo+6AYGq40Dnmy80rbURxBn9loOLJ0wA996f/+iHrdv3yEtbDc1aGUbv6OeXw9ztrSsNBmyiSC7vhFxETeXVKS4lY67HxcQqqwfXqBlSnKYYl1/0ok0xYrsSE11ddY3qYODG/VGiX9DFyJCd4ZrT4XC6dOiCyJG5dRs8NH2d+wBeXMKPEr7B3YSRnLnY3dL1of7e+18bShYDGh0QKD0ZliePZMP2XPttpr8nQzJYGq6UoaYhP0Z63ZDxfgsfT0BRAHtVR1as5iwjRjO2HLvCcqIoUtcaPwkCp7SqlWeebqTius9hhUbJuqsTDzw5QHMvHltJygaICt7s1vWilgbVG/lRltSGvDgbBKnRUDi7wDxLoGXEZkVwcW9UWcvE4CpSmkorYpnf4QVnkKqA5XuOKyFR9DIGu9Wrl1kZ/rxd8P1mdYp0RzpWqegQUcJxKxpHTQRHea0oexuIqTqprjLNyGZIs6QmzNcvfigHwmZTvMXbqCkBMuSTXuBVC96mBPTrUsmFAS+3aagOL1ugQmmeLktxi1YUfGZnw3M9Q== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(5660300002)(38070700005)(53546011)(7696005)(9686003)(54906003)(26005)(316002)(86362001)(52536014)(66476007)(6506007)(33656002)(66446008)(8676002)(122000001)(64756008)(66556008)(6636002)(508600001)(66574015)(4326008)(71200400001)(76116006)(110136005)(966005)(186003)(8936002)(2906002)(83380400001)(55016002)(38100700002)(166002)(66946007); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?LJjuuJFMHT35Ef2VDDvRkyuliFRzPw/rEbDy8ofoQRsVtfVbSMg//Oh65z?= =?iso-8859-1?Q?ePBEpHlpjPWfG7P6UWYTWtERMaomrCMGmnAssGE4QHl3c1vK7F0BAMqDrt?= =?iso-8859-1?Q?ipS90zYZDb04WzSLmhc1f2tRHAFEEN5tmgIdKaXGTAmzRCvfQV2btLk9Ui?= =?iso-8859-1?Q?zCcWyO8qkVa+5RE8rsvhGfSEmAtDXwz3IYw7pZOybTBrsNlbmrXZkAAAeU?= =?iso-8859-1?Q?+pIdONPc5P2dbU4fagX7FY0eklnyRB25yKyr3pILxphuqiDFmmdgW9yYFz?= =?iso-8859-1?Q?eBdFIaDs6P/XSyKxdaeG9nmbQiqOFZcs3CUFhphCz/jzLfhecKjbbIJb9l?= =?iso-8859-1?Q?Qq3mjXBbNQVGfUSB6JZirNsf1p4owHbOHi13iVziJy3hWM6vXvLHo6iiaA?= =?iso-8859-1?Q?rIpE6Xbl0kjI8qiNuYGLvFOCRAPBzFW4CnPzQXxdzenn5B/B7zWnTPaSbg?= =?iso-8859-1?Q?9V2gCncyebCr8MKrj57ogPRtOuy2nM3MTP4rbBT9RLKgI6HvAIHRy7ug0i?= =?iso-8859-1?Q?s1gM9/geFPUnFMrIuMXofCDx6PyQxLJxz3nknKB4umDj3gCoNT9vDL3bQo?= =?iso-8859-1?Q?8bzA1UHfdsMzZGHRiwh9iKlAKGog7LzKso11+vSUStVCbl57uUI6lHrPJv?= =?iso-8859-1?Q?G3Fq3XhmQRyhKuzP+NftQSvO08unLrYO+xdbRxxl8bAcRnLAS3Xxj1WWFt?= =?iso-8859-1?Q?+lmd2/fI9+NTa3pij8Z0rX5jzcun4OJrGTiNa1nW5DAlEj+bJRy61owm0G?= =?iso-8859-1?Q?dxvmMzOyW40jPpRK9papXAI5Mt7a9x6c93f61Fb/oOiMtWRW1TufUFWgI/?= =?iso-8859-1?Q?F6AB7duw9zAHjjR7AeAhxXmVoEq8KODmFv/KRXQaDTHScNG2l7r/UpMw5z?= =?iso-8859-1?Q?JWngu9AHBbNDCmhe2nDrFS1lCNrIYJhZ/YI7FcaK/k4/bUsaSQu3aqlzDh?= =?iso-8859-1?Q?8BI60dnnDYy9+x0i+c5vm74nUugE45MVZ+u3L7DPuKINuUgiImwXeh+9Fq?= =?iso-8859-1?Q?ibKatioWbvuT8UjtKG5ZPCucJXpLOGkCxunA6v6oCTGzcbj6Xl8cVvSYfj?= =?iso-8859-1?Q?6Od/5iQoGmpIQXWL3hAJFxWKdoOmkQElo9kk7OqVS7TvWE6dnKQcHY9kHh?= =?iso-8859-1?Q?DSNIlQmicWonzoOYnAWXKoY11TQYK0wVbg7Gh1mJ0uDFA/2x8zddabz6uv?= =?iso-8859-1?Q?M9o/7O6vfj5irgjD0auOLekyniT6NzXv/C4bz/a1N9taxNQQ+OVsFYEYqh?= =?iso-8859-1?Q?VdDuFF2d8ZVVcbWf8t11pVO5yeoFHPD97PiuTyhPwspAfVJak13N2chZH7?= =?iso-8859-1?Q?xveO0udi5DeHv/9KvSvA5ybTUYSm7E5ixAfJHp/1O6E87hYn6elJNHT4OF?= =?iso-8859-1?Q?R+h4bJQt/ohm8eM+35/X6VJPMSYs2N44teyTLsHGNa1wXqcDiVyV5RGULp?= =?iso-8859-1?Q?hIwjQ0u7bsMlgj7o1IB0xH5kOi/VX7vLU36DnX7M2wLt4ch8pJOvDFk323?= =?iso-8859-1?Q?9NBBDSYl8rUTHQCbo+Pp9JkyJEMEzyq6bk9b6ho72fdxIXYefVNpIfOK6P?= =?iso-8859-1?Q?OJgi0ldaww1oWL6pa8jycULReJdjA659zMU6HJUyxXmCKNUCWWt1o2PoRA?= =?iso-8859-1?Q?+a7yAL92OOfTiOn2UPLK0ao7tON7G4loCvFdeNqBubnEp5e/PMM72G4fo7?= =?iso-8859-1?Q?7cEnjPDvgkqAHfEL+es=3D?= Content-Type: multipart/alternative; boundary="_000_BL0PR05MB531669E93CE57C9C7E4FE343AE849BL0PR05MB5316namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2e1f607b-d48f-4d5f-0775-08d998bb6899 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2021 20:01:32.9212 (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: DX+Oih0TWc03pfXR6Vtb7saYCEvIRF+iTWo/PF30pad0RDyHx0vHYgrbf9meMY8WEqM6/4mdgcB7n1VE2+LsKA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5649 X-Proofpoint-GUID: 0TM4Ljmq4Bj50mkONNPy67cl0YTIIXft X-Proofpoint-ORIG-GUID: 0TM4Ljmq4Bj50mkONNPy67cl0YTIIXft X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-26_05,2021-10-26_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 clxscore=1015 malwarescore=0 lowpriorityscore=0 suspectscore=0 phishscore=0 impostorscore=0 bulkscore=0 mlxlogscore=999 adultscore=0 mlxscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2110260111 Archived-At: Subject: Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 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, 26 Oct 2021 20:01:48 -0000 --_000_BL0PR05MB531669E93CE57C9C7E4FE343AE849BL0PR05MB5316namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Robert, Which requirement was that? Ron Juniper Business Use Only From: spring On Behalf Of Robert Raszuk Sent: Tuesday, October 26, 2021 3:41 PM To: John Scudder Cc: draft-filsfilscheng-spring-srv6-srh-compression@ietf.org; spring@ietf.o= rg Subject: Re: [spring] "This solution does not require any SRH data plane ch= ange" in draft-filsfilscheng-spring-srv6-srh-compression-02 [External Email. Be cautious of content] Hello John, May I inquire what was not definitive as part of my answer ? Please observe that below documents which are product of this WG go in dept= h to evaluate compression against the requirement not to change SRv6 data p= lane: https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-req= uirement https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-ana= lysis Would your enquiry be satisfied if the draft in question s/SRH data plane/S= Rv6 data plane/ ? Kind regards, Robert On Tue, Oct 26, 2021 at 7:55 PM John Scudder > wrote: (For clarity: I'm not wearing any hats other than "WG contributor".) Hi All, Since there hasn't been any definitive answer from the authors, nor any upd= ate to the draft to address the issue, and given that the disputed statemen= t seems to be an important premise for evaluation of the fitness of the dra= ft for adoption (at least, the authors considered it fundamental enough to = put in the abstract): I'm opposed to adoption of the draft until this quest= ion has been settled, or at least meaningfully addressed. Regards, -John P.S.: I will also follow up to the main adoption thread to assist with issu= e tracking. > On Oct 13, 2021, at 6:28 PM, John Scudder > wrote: > > > Hi Folks, > > I'm struggling with the claim repeated throughout the beginning of draft-= filsfilscheng-spring-srv6-srh-compression-02 (Abstract, =A71, =A73) that "t= his solution does not require any SRH data plane change". > > I'm not aware of a standardized formal definition of "data plane", it see= ms to follow Justice Stewart's maxim of "I know it when I see it". However,= here's an attempt, cribbed from some Washington University course slides: = a "local, per-router function that determines how a datagram arriving on a = router input port is forwarded to a router output port". Seems reasonable. > > I also am not aware of a standardized formal definition of the term "SRH = data plane", in fact this draft, its predecessors, some associated blog pos= ts, and Clarence's dissertation, are the only places a search finds the phr= ase (but it's not formally defined in any of them). So I'm just going to as= sume it means the data plane, as applied to packets that include an SRH. (I= 'm not sure why we should disregard packets that are encoded using NEXT-C-S= ID that omit the SRH, but let's overlook that for now.) > > If this solution does not require any SRH data plane change, presumably i= t would be true that if I take a packet that includes an SRH and place with= in it a series of SIDs encoded with (for example) the REPLACE-C-SID flavor,= then that packet would be able to successfully traverse a network of route= rs that support plain vanilla RFC 8754. That is, it would arrive at its fir= st hop router which according to a local, per-router function, would determ= ine how to take the datagram arriving on the router input port and forward = it to (the correct) router output port. Then that process would be repeated= across the rest of the network. > > But that is patently incorrect: when it's delivered to the first hop, the= plain vanilla RFC 8754 router will be unable to apply the REPLACE-C-SID be= havior, and forwarding to the next hop will fail. It seems that a different= local, per-router function is required (in fact, the local, per-router fun= ction defined in the draft) in order for the forwarding to succeed. By the = definitions I'm using here, that is exactly a data plane change. > > What, precisely, is then being claimed? > > Thanks, > > -John > _______________________________________________ > spring mailing list > spring@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring_= _;!!NEt6yMaO-gk!S7rbnYg6aV2s3cyoTCL3wwWX4bpbFoawPLt6yLeYsms82sLl9tUpRU1X5c-= D9A$ --_000_BL0PR05MB531669E93CE57C9C7E4FE343AE849BL0PR05MB5316namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Robert,<= /span>

     

    Which requirement w= as that?

     

       &= nbsp;           &nbs= p;            &= nbsp;       Ron

     

     

     

    Juniper Business Use Only

    From: spring <spring-bounces@ietf.org> = On Behalf Of Robert Raszuk
    Sent: Tuesday, October 26, 2021 3:41 PM
    To: John Scudder <jgs@juniper.net>
    Cc: draft-filsfilscheng-spring-srv6-srh-compression@ietf.org; spring= @ietf.org
    Subject: Re: [spring] "This solution does not require any SRH d= ata plane change" in draft-filsfilscheng-spring-srv6-srh-compression-0= 2

     

    <= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

     

    Hello John,

     

    May I inquire what was not definitive as part of my = answer ? 

     

    Please observe that below documents which are produc= t of this WG go in depth to evaluate compression against the requirement no= t to change SRv6 data plane: 

     

    https://datatracker.ietf.org/doc/html/draft-srcompdt-<= span class=3D"gmail-il">spring-compression<= /span>-requirement

    https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis

     

    Would your enquiry be satisfied if the draft in question s/SRH dat= a plane/SRv6 data plane/ ? 

     

    Kind regards,

    Robert

     

     

     

    On Tue, Oct 26, 2021 at 7:55 PM John Scudder <jgs@juniper.net> wrote:

    (For clarity: I’= ;m not wearing any hats other than “WG contributor”.)

    Hi All,

    Since there hasn’t been any definitive answer from the authors, nor a= ny update to the draft to address the issue, and given that the disputed st= atement seems to be an important premise for evaluation of the fitness of t= he draft for adoption (at least, the authors considered it fundamental enough to put in the abstract): I’m oppose= d to adoption of the draft until this question has been settled, or at leas= t meaningfully addressed.

    Regards,

    —John

    P.S.: I will also follow up to the main adoption thread to assist with issu= e tracking.

    > On Oct 13, 2021, at 6:28 PM, John Scudder <jgs=3D40juniper.net@dmarc.ietf.or= g> wrote:
    >
    >
    > Hi Folks,
    >
    > I’m struggling with the claim repeated throughout the beginning = of draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, =A71, =A73= ) that “this solution does not require any SRH data plane change̶= 1;.
    >
    > I’m not aware of a standardized formal definition of “data= plane”, it seems to follow Justice Stewart’s maxim of “I= know it when I see it”. However, here’s an attempt, cribbed fr= om some Washington University course slides: a “local, per-router fun= ction that determines how a datagram arriving on a router input port is forwarded to = a router output port”. Seems reasonable.
    >
    > I also am not aware of a standardized formal definition of the term &#= 8220;SRH data plane”, in fact this draft, its predecessors, some asso= ciated blog posts, and Clarence’s dissertation, are the only places a= search finds the phrase (but it’s not formally defined in any of them). So I’m just going to assume it means the data plane= , as applied to packets that include an SRH. (I’m not sure why we sho= uld disregard packets that are encoded using NEXT-C-SID that omit the SRH, = but let’s overlook that for now.)
    >
    > If this solution does not require any SRH data plane change, presumabl= y it would be true that if I take a packet that includes an SRH and place w= ithin it a series of SIDs encoded with (for example) the REPLACE-C-SID flav= or, then that packet would be able to successfully traverse a network of routers that support plain vanilla R= FC 8754. That is, it would arrive at its first hop router which according t= o a local, per-router function, would determine how to take the datagram ar= riving on the router input port and forward it to (the correct) router output port. Then that process woul= d be repeated across the rest of the network.
    >
    > But that is patently incorrect: when it’s delivered to the first= hop, the plain vanilla RFC 8754 router will be unable to apply the REPLACE= -C-SID behavior, and forwarding to the next hop will fail. It seems that a = different local, per-router function is required (in fact, the local, per-router function defined in the draft) in order fo= r the forwarding to succeed. By the definitions I’m using here, that = is exactly a data plane change.
    >
    > What, precisely, is then being claimed?
    >
    > Thanks,
    >
    > —John
    > _______________________________________________
    > spring mailing list
    > spring@ietf.org
    >     https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;= !!NEt6yMaO-gk!S7rbnYg6aV2s3cyoTCL3wwWX4bpbFoawPLt6yLeYsms82sLl9tUpRU1X5c-D9= A$

    --_000_BL0PR05MB531669E93CE57C9C7E4FE343AE849BL0PR05MB5316namp_-- From nobody Tue Oct 26 13:10:32 2021 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 A4FD73A078C for ; Tue, 26 Oct 2021 13:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 ct8yuE0pfdO6 for ; Tue, 26 Oct 2021 13:10:24 -0700 (PDT) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 4B6B73A1440 for ; Tue, 26 Oct 2021 13:09:40 -0700 (PDT) Received: by mail-ua1-x936.google.com with SMTP id v3so593787uam.10 for ; Tue, 26 Oct 2021 13:09:40 -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=ZfznS3yjSMhUFNoI58HBzTXR0Lk5zIGfLZuZ8AYVR9o=; b=SN9SSoOOyVCxEM2PaFMxBnvL4PbE11yLKzF1KPM7CpJohFGX40DE2nnwExReLUpKRo XTk2dphK3IuCqFGyPyWMM0ywQzLy79GkWnDCqcDrac2+WnjHXdONZPuZbweM9uiweov3 5pWseXNce0jx/2RnvzILbQ17C8h68T9jDHpPoOKzAj4TQ614WOjL9dRy1uqoD4654CJ5 1r2JelN1UNfsAIDCpV7gHFBAjWTzQ6iH9f1LmG3RDon4OTxbo+JYvfL6jdyOjeIRDD+u 6YtrUvW+184jYBabIRBXGjU/A9hEYcF1gFBDZECkd9p/b6eRuKcZJcs0rp784iLxT519 lMQg== 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=ZfznS3yjSMhUFNoI58HBzTXR0Lk5zIGfLZuZ8AYVR9o=; b=Wgc8PrmaQzbjKlTETL8zAQcvsNp2QYVahwQdg8I/BK1JbSQT7YHxMpzd0nNHOIE8pe aY8b3RXKU6GcxeKHIrcD7rWrg4IX19jDKE2y5rzYE07wV0L7llyrIH1NAc13fJVTZBJr D1yk7kMZO3nRr1MWNoedT49ZmeC0cgT51oPFvoNwGCv/AYN/UCnxk/Y3VX1bHJZxfZct J71kswhtev3X5Uais591PZ/96XXWifvg1qqyhzXgIHRZhgBjGQ4z12viidIxE4DvjgOn YWH9FTcGYRlZ+MPsNbudZiz6qI3DfR1z5tFZC5LEktGWafUNrNj8j15QbMgcUYmSB2OK 3JNQ== X-Gm-Message-State: AOAM531YsDwD8OOPZVOivIIWq7P323LTol2pFMt5npkyU/AN2vWgxLom oUFJOLJvo8u3QrBmvWCIDfNNCiMTbCXJgsV9XU8MLg== X-Google-Smtp-Source: ABdhPJybCrGVAJ8Hjz5ZfEdbrE/Gg95DoVFz0QPxtiI3QQES/PmqSqqSqoq6Ls/UWmwbwps/wrjNXi3NgNjz4GSPj0c= X-Received: by 2002:ab0:7542:: with SMTP id k2mr12994699uaq.69.1635278978485; Tue, 26 Oct 2021 13:09:38 -0700 (PDT) MIME-Version: 1.0 References: <1EB19A49-C12A-425D-ADB7-6E0B0F2CA66D@juniper.net> In-Reply-To: From: Robert Raszuk Date: Tue, 26 Oct 2021 22:09:36 +0200 Message-ID: To: Ron Bonica Cc: John Scudder , "draft-filsfilscheng-spring-srv6-srh-compression@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="0000000000009f219a05cf470ea4" Archived-At: Subject: Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 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, 26 Oct 2021 20:10:31 -0000 --0000000000009f219a05cf470ea4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 4. SRv6 Specific Requirements 4.1. SRv6 Based * Description: A solution to compress SRv6 SID Lists SHOULD be based on the SRv6 architecture, control plane and data plane. * The compression solution MAY be based on a different data plane and control plane, provided that it derives sufficient benefit. It is clearly a requirement. It is not an exclusive requirement, but that does not make it of any less importance as evaluation criteria. Analysis draft provides comparison table in section 3.1 But please let's not derail this thread as I provided a specific question to John. Many thx, R. On Tue, Oct 26, 2021 at 10:01 PM Ron Bonica wrote: > Robert, > > > > Which requirement was that? > > > > Ron > > > > > > > > Juniper Business Use Only > > *From:* spring *On Behalf Of *Robert Raszuk > *Sent:* Tuesday, October 26, 2021 3:41 PM > *To:* John Scudder > *Cc:* draft-filsfilscheng-spring-srv6-srh-compression@ietf.org; > spring@ietf.org > *Subject:* Re: [spring] "This solution does not require any SRH data > plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 > > > > *[External Email. Be cautious of content]* > > > > Hello John, > > > > May I inquire what was not definitive as part of my answer ? > > > > Please observe that below documents which are product of this WG go in > depth to evaluate compression against the requirement not to change SRv6 > data plane: > > > > https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression > -requirement > > > https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression > -analysis > > > > > Would your enquiry be satisfied if the draft in question s/SRH data > plane/SRv6 data plane/ ? > > > > Kind regards, > > Robert > > > > > > > > On Tue, Oct 26, 2021 at 7:55 PM John Scudder wrote: > > (For clarity: I=E2=80=99m not wearing any hats other than =E2=80=9CWG con= tributor=E2=80=9D.) > > Hi All, > > Since there hasn=E2=80=99t been any definitive answer from the authors, n= or any > update to the draft to address the issue, and given that the disputed > statement seems to be an important premise for evaluation of the fitness = of > the draft for adoption (at least, the authors considered it fundamental > enough to put in the abstract): I=E2=80=99m opposed to adoption of the dr= aft until > this question has been settled, or at least meaningfully addressed. > > Regards, > > =E2=80=94John > > P.S.: I will also follow up to the main adoption thread to assist with > issue tracking. > > > On Oct 13, 2021, at 6:28 PM, John Scudder 40juniper.net@dmarc.ietf.org> wrote: > > > > > > Hi Folks, > > > > I=E2=80=99m struggling with the claim repeated throughout the beginning= of > draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, =C2=A71, = =C2=A73) that > =E2=80=9Cthis solution does not require any SRH data plane change=E2=80= =9D. > > > > I=E2=80=99m not aware of a standardized formal definition of =E2=80=9Cd= ata plane=E2=80=9D, it > seems to follow Justice Stewart=E2=80=99s maxim of =E2=80=9CI know it whe= n I see it=E2=80=9D. > However, here=E2=80=99s an attempt, cribbed from some Washington Universi= ty course > slides: a =E2=80=9Clocal, per-router function that determines how a datag= ram > arriving on a router input port is forwarded to a router output port=E2= =80=9D. > Seems reasonable. > > > > I also am not aware of a standardized formal definition of the term =E2= =80=9CSRH > data plane=E2=80=9D, in fact this draft, its predecessors, some associate= d blog > posts, and Clarence=E2=80=99s dissertation, are the only places a search = finds the > phrase (but it=E2=80=99s not formally defined in any of them). So I=E2=80= =99m just going to > assume it means the data plane, as applied to packets that include an SRH= . > (I=E2=80=99m not sure why we should disregard packets that are encoded us= ing > NEXT-C-SID that omit the SRH, but let=E2=80=99s overlook that for now.) > > > > If this solution does not require any SRH data plane change, presumably > it would be true that if I take a packet that includes an SRH and place > within it a series of SIDs encoded with (for example) the REPLACE-C-SID > flavor, then that packet would be able to successfully traverse a network > of routers that support plain vanilla RFC 8754. That is, it would arrive = at > its first hop router which according to a local, per-router function, wou= ld > determine how to take the datagram arriving on the router input port and > forward it to (the correct) router output port. Then that process would b= e > repeated across the rest of the network. > > > > But that is patently incorrect: when it=E2=80=99s delivered to the firs= t hop, > the plain vanilla RFC 8754 router will be unable to apply the REPLACE-C-S= ID > behavior, and forwarding to the next hop will fail. It seems that a > different local, per-router function is required (in fact, the local, > per-router function defined in the draft) in order for the forwarding to > succeed. By the definitions I=E2=80=99m using here, that is exactly a dat= a plane > change. > > > > What, precisely, is then being claimed? > > > > Thanks, > > > > =E2=80=94John > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring_= _;!!NEt6yMaO-gk!S7rbnYg6aV2s3cyoTCL3wwWX4bpbFoawPLt6yLeYsms82sLl9tUpRU1X5c-= D9A$ > > > --0000000000009f219a05cf470ea4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    4.=C2=A0 SRv6 Specific Requirements

    4.1.=C2=A0 SRv6= Based

    =C2=A0 =C2=A0Description: A solution to compress SRv6 SID = Lists SHOULD be based on
    =C2=A0 =C2=A0the SRv6 architecture, control pla= ne and data plane.     =C2=A0The compression
    =C2=A0 =C2=A0solution MAY b= e based on a different data plane and control plane,
    =C2=A0 =C2=A0provid= ed that it derives sufficient benefit.

    It is clearly= a requirement. It is not an exclusive requirement, but that does not make = it of any less importance=C2=A0as evaluation criteria. Analysis draft provi= des comparison table in section 3.1=C2=A0

    But plea= se let's not derail this thread as I provided a specific question to Jo= hn.=C2=A0

    Many thx,
    R.

    On Tue, Oct = 26, 2021 at 10:01 PM Ron Bonica <= rbonica@juniper.net> wrote:

    Robert,=

    =C2=A0<= /span>

    Which requirement was= that?

    =C2=A0<= /span>

    =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Ron

    =C2=A0<= /span>

    =C2=A0<= /span>

    =C2=A0

    Juniper Business Use Only<= u>

    From: spring <spring-bounces@ietf.org> On Beha= lf Of Robert Raszuk
    Sent: Tuesday, October 26, 2021 3:41 PM
    To: John Scudder <jgs@juniper.net>
    Cc: draft-filsfilscheng-spring-srv6-srh-compressi= on@ietf.org; sprin= g@ietf.org
    Subject: Re: [spring] "This solution does not require any SRH d= ata plane change" in draft-filsfilscheng-spring-srv6-srh-compression-0= 2

    =C2=A0

    [External Email. Be cautious of content]

    =C2=A0

    Hello John,

    =C2=A0

    May I inquire what was not definitive as part of my = answer ?=C2=A0

    =C2=A0

    Please observe that below documents which are produc= t of this WG go in depth to evaluate compression against the requirement no= t to change SRv6 data plane:=C2=A0

    =C2=A0

    https://datatracker.ietf.org/doc/html/draft-srcompdt-<= span class=3D"gmail-m_7630703716420714563gmail-il">spring-compression-requirement

    https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis

    =C2=A0

    Would your enquiry be satisfied if the draft in ques= tion s/SRH data plane/SRv6 data plane/ ?=C2=A0

    =C2=A0

    Kind regards,

    Robert

    =C2=A0

    =C2=A0

    =C2=A0

    On Tue, Oct 26, 2021 at 7:55 PM John Scudder <jgs@juniper.net> w= rote:

    (For clarity: I=E2=80= =99m not wearing any hats other than =E2=80=9CWG contributor=E2=80=9D.)

    Hi All,

    Since there hasn=E2=80=99t been any definitive answer from the authors, nor= any update to the draft to address the issue, and given that the disputed = statement seems to be an important premise for evaluation of the fitness of= the draft for adoption (at least, the authors considered it fundamental enough to put in the abstract): I=E2=80=99m oppo= sed to adoption of the draft until this question has been settled, or at le= ast meaningfully addressed.

    Regards,

    =E2=80=94John

    P.S.: I will also follow up to the main adoption thread to assist with issu= e tracking.

    > On Oct 13, 2021, at 6:28 PM, John Scudder <jgs=3D40juniper.net@dmarc.ietf.or= g> wrote:
    >
    >
    > Hi Folks,
    >
    > I=E2=80=99m struggling with the claim repeated throughout the beginnin= g of draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, =C2=A71,= =C2=A73) that =E2=80=9Cthis solution does not require any SRH data plane c= hange=E2=80=9D.
    >
    > I=E2=80=99m not aware of a standardized formal definition of =E2=80=9C= data plane=E2=80=9D, it seems to follow Justice Stewart=E2=80=99s maxim of = =E2=80=9CI know it when I see it=E2=80=9D. However, here=E2=80=99s an attem= pt, cribbed from some Washington University course slides: a =E2=80=9Clocal= , per-router function that determines how a datagram arriving on a router input port is forwarded to = a router output port=E2=80=9D. Seems reasonable.
    >
    > I also am not aware of a standardized formal definition of the term = =E2=80=9CSRH data plane=E2=80=9D, in fact this draft, its predecessors, som= e associated blog posts, and Clarence=E2=80=99s dissertation, are the only = places a search finds the phrase (but it=E2=80=99s not formally defined in any of them). So I=E2=80=99m just going to assume it means the data pla= ne, as applied to packets that include an SRH. (I=E2=80=99m not sure why we= should disregard packets that are encoded using NEXT-C-SID that omit the S= RH, but let=E2=80=99s overlook that for now.)
    >
    > If this solution does not require any SRH data plane change, presumabl= y it would be true that if I take a packet that includes an SRH and place w= ithin it a series of SIDs encoded with (for example) the REPLACE-C-SID flav= or, then that packet would be able to successfully traverse a network of routers that support plain vanilla R= FC 8754. That is, it would arrive at its first hop router which according t= o a local, per-router function, would determine how to take the datagram ar= riving on the router input port and forward it to (the correct) router output port. Then that process woul= d be repeated across the rest of the network.
    >
    > But that is patently incorrect: when it=E2=80=99s delivered to the fir= st hop, the plain vanilla RFC 8754 router will be unable to apply the REPLA= CE-C-SID behavior, and forwarding to the next hop will fail. It seems that = a different local, per-router function is required (in fact, the local, per-router function defined in the draft) in order fo= r the forwarding to succeed. By the definitions I=E2=80=99m using here, tha= t is exactly a data plane change.
    >
    > What, precisely, is then being claimed?
    >
    > Thanks,
    >
    > =E2=80=94John
    > _______________________________________________
    > spring mailing list
    > spring@ietf.org
    >     https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;= !!NEt6yMaO-gk!S7rbnYg6aV2s3cyoTCL3wwWX4bpbFoawPLt6yLeYsms82sLl9tUpRU1X5c-D9= A$

    --0000000000009f219a05cf470ea4-- From nobody Tue Oct 26 13:55:57 2021 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 8BA9A3A129C; Tue, 26 Oct 2021 13:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=1LB3XWZZ; dkim=pass (1024-bit key) header.d=juniper.net header.b=RFawvkMq 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 ExvlMMJdtQJW; Tue, 26 Oct 2021 13:55:50 -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 6B3DF3A0EE6; Tue, 26 Oct 2021 13:55:50 -0700 (PDT) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 19QKQWIn020943; Tue, 26 Oct 2021 13:55:50 -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=OJNCfnaT5nebyEBY+kiNoVogIJtxP2KFdeLNNOFq8cM=; b=1LB3XWZZq5AZzr0ksrP9dLuB90G3Ml0vFo0GPhkUV2pTXYNOhnyNJI6TE511qtIWH1kF yxzQDXkD1kHfMAq7tGznM6M2DkwKH9Z4uzWdLug2o9w+J979VqTeeHW31vmgExWNYvRP FDxV6XucfsyXNOmBIOkVV4hXAwpkcxP1zACz0VsbED9G+BTLEB6p1aVXaxBL/4J0YPda ZgTwMKPSY0/yOAvAm1rhYDvjWmTqItTUfJqHlvg7oRL5q0s50T+ExylMsQr14mBEjFh6 +rY1plWNj3fu6rWlRozy3aVHC5NXXa1Oc29UhD7NLvoyaf7139wG+n71ZMyfLstVlB69 CQ== Received: from nam04-dm6-obe.outbound.protection.outlook.com (mail-dm6nam08lp2048.outbound.protection.outlook.com [104.47.73.48]) by mx0a-00273201.pphosted.com with ESMTP id 3bxgfjsakg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Oct 2021 13:55:49 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PLH/yupa2vjmP2RhkE732VExfxJNBRyX5Y1wpANnBxdVcyqOuJUN/CGXwTw/bwWubFTttu50qf0TXpf/rg3Xxsp5Ya9hXdz9cMWvktAZqr/YoJjShf/HBrvDFEOHmvTVxQQgpl9P4SMJ9Kg0qNdCfDgwSn2GfR5XTjCeRNAfvZygaRsvISylwj08KKnGJzIkaXbiEEvsh6MOlUJ2Cw060CJw43uwRHHj1p5nHGbCrbX92eOwdi/ocgZBKzt67RiPfbIX27boWRs1jnlqZ2kZ+BXC8p5pbuC1qGH4naUUyHZ6wEgNc80FRH8eX3zmWGEYoryBHbbgIop5s0JKzWBZ6w== 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=OJNCfnaT5nebyEBY+kiNoVogIJtxP2KFdeLNNOFq8cM=; b=BOsB3/Z9BpzH5kE9cTYBZX2fqC/KXWOSOamrTTwUf1b2w7hXtuMal1gyfUhdEqj+VKF0BV/p+UNNWdd2IzZQ5tL7SEdJY602KDnvW5lSJRNzcIoekMrWOMi/7MkBa1idK5tc6hQKOWTCmacu057OnXTbd+j/2tj2uHwimMYC9OFIb3vTUkLBdMthP9X84NSkCUsR6VABD7uAi8fyVNp8DTrsDYTSQHSEhChMWoKu577nBB3LFc+K+HcIdY7SjnNSTrdXhxd8vx2ko5GgarxlIXRV9CR9bWTOIZVImcUL7WvUwhf6wLL8FXWjUzZN2NgGH4h7GoOeSHRydUosTqN4tQ== 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=OJNCfnaT5nebyEBY+kiNoVogIJtxP2KFdeLNNOFq8cM=; b=RFawvkMqAuoOyz/dyDfA6umSHcsSaBPyuy13JkNPxO05/dDwQptCurBOcrWujVw4hGUhxKhztXQ5snBbBzbhjwsr+4Y3DqoSJY7Hgc+Pe2KoSqFl3Qa+WOSwUlHAaymgqUutbs0u0I+FTEX6tiW3eFiMYnSfCv24QHf/r/MPyFU= Received: from BL0PR05MB5316.namprd05.prod.outlook.com (2603:10b6:208:2f::25) by BL0PR05MB5138.namprd05.prod.outlook.com (2603:10b6:208:86::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.12; Tue, 26 Oct 2021 20:55:47 +0000 Received: from BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2]) by BL0PR05MB5316.namprd05.prod.outlook.com ([fe80::7459:5d69:f570:55f2%7]) with mapi id 15.20.4649.014; Tue, 26 Oct 2021 20:55:47 +0000 From: Ron Bonica To: Robert Raszuk CC: John Scudder , "draft-filsfilscheng-spring-srv6-srh-compression@ietf.org" , "spring@ietf.org" Thread-Topic: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 Thread-Index: AQHXwIGtGfUetDOXlk+YPM+Rvcp8k6vlpFEAgAAdigCAAAWBsIAAAmwAgAAEDYA= Date: Tue, 26 Oct 2021 20:55:47 +0000 Message-ID: References: <1EB19A49-C12A-425D-ADB7-6E0B0F2CA66D@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.6.300.5 dlp-reaction: no-action msip_labels: MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Enabled=true; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SetDate=2021-10-26T20:24:05Z; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Method=Standard; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_Name=0633b888-ae0d-4341-a75f-06e04137d755; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_SiteId=bea78b3c-4cdb-4130-854a-1d193232e5f4; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ActionId=ba920145-cffa-4cde-907f-573fd6c29e2c; MSIP_Label_0633b888-ae0d-4341-a75f-06e04137d755_ContentBits=2 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_enabled: true msip_label_0633b888-ae0d-4341-a75f-06e04137d755_setdate: 2021-10-26T20:55:45Z msip_label_0633b888-ae0d-4341-a75f-06e04137d755_method: Standard msip_label_0633b888-ae0d-4341-a75f-06e04137d755_name: 0633b888-ae0d-4341-a75f-06e04137d755 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_siteid: bea78b3c-4cdb-4130-854a-1d193232e5f4 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_actionid: 055acfa6-cd3b-4fe6-b4fa-4346be26a178 msip_label_0633b888-ae0d-4341-a75f-06e04137d755_contentbits: 0 authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f280e869-644e-4910-9017-08d998c2fc3c x-ms-traffictypediagnostic: BL0PR05MB5138: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XtnRGZn9Ie0qWN7WYfnbFm1F5pM+5XrwWHs/34B2TJiP3y7UIeDsdXLy4yBClxDEt11m7eRxTaUDlK0C4YAClERF4rWTMxNosGvrexjmFGTzVmb9Vyvt9MSPAuZjvOISidjVB5RBsItoN/8B9JAYJ5s7PmpormhPHcTdj8SYzeQfbNdjIEGMGm/sFhPKA+tgNDcv0JiScA7HQhTN+2BT6xDyg0aTghDJ/DcR9DLFC6eAV9YQ3L4wqIyG2JLqbnTVJsJCkdfjKVkVy8p1uo8w+egMR6vrJgUiDEmNlMGSFPuz1nKTgM8CT3GbmbIHcfwJFO7AneV7HX64AP2YHcYrxJb1fcSNBCmVcwDb3WWJvIkVXA9gYghQzxsCk6D2Qz/C/Vy2mLKf6AZycZp9BAyXLzFYdAD5+2n2JBOLSKs2HUH+PWYLHgNtvhaq7h5YjY1ViZik6Lr5y4jUZkqKBRPJWc4d6+0lf4a37PZM5zhodkoU5flgUEQPpOCusbbxCmCJ46c+1GuVUassGQ+X7F/TZvF9BZf38yfwryjnOT66n9Zy2mW726WGmwxbQpiN15mA5JxSbpDuzVtzUDXmeNWRwZqQbkEi8E1Cy7BZX01LwspnEUHQuS0xsDN/+pujbtwRKRZJsVmZFw1mHtGiLj2ZUQmxKQpOP1mtMP/TFQwakzv5L7bMoqh45JMYPhV0LdgiBV8JEwlFX94q0hSE0BxnQXkp1X1PFyXIl2dKgfd4H+95FkXIKhTDZQPWQq+q9zj7TgF8syFN4eb1uUMTuu062UudP+b3srIl/BtYBU5Mct572dng7xn4ydqdCAlLbTqtAPsqf2rluRHjpkzYi2MdSg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR05MB5316.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66574015)(76116006)(966005)(53546011)(6506007)(8676002)(83380400001)(8936002)(33656002)(2906002)(5660300002)(508600001)(64756008)(71200400001)(66556008)(6916009)(86362001)(66946007)(52536014)(122000001)(7696005)(55016002)(9686003)(38100700002)(54906003)(66446008)(316002)(26005)(186003)(4326008)(166002)(66476007)(38070700005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?pG3YL92lleMO+rRq0L5XkZv5lXDUUEsOn6WVuCS5R9+bWWyndRsgSRkUTC?= =?iso-8859-1?Q?esgBY6XACcnvzvZ9ZQHNGgjnmFW8avGU/W8654MxM9JjFNjXCsUn7jJDa4?= =?iso-8859-1?Q?8/KTnPQAqFRTaI8ExLjvY5sX/CY9eeZvC2jy7llnFQw5gmvXUcE1lPcQIR?= =?iso-8859-1?Q?GF26/z1NmXnAJgZGo0fQ5Cpm80lRVeb/TpWnSGAunZWZCoFjc+8b2YqHE8?= =?iso-8859-1?Q?3P3khnwfzxqLAnRohupQTess3gslBjjay+HsRGMso8ZwvztIFfen8fmonk?= =?iso-8859-1?Q?G4dUtThzGxXWYbTGRi1NhD2wl7VGfhbDEH5Y2OsR4Ifxyswkm5ZJm+dR2i?= =?iso-8859-1?Q?twjvnWhdwf2CE5YfCZZZkrV6L15kh/+H2GIXAdYJu4g+Rh3lIS0Eeeedv1?= =?iso-8859-1?Q?agAk8geN5RDOtySck3BN0AXm2EzqS0IDcVyqfPY/GDsl39tEpb33LyKu7B?= =?iso-8859-1?Q?t7f/PNDzVnD6evn9T950vjX+/v5wdR91Z96CU9LBGUsnrnihjATzgiCmNl?= =?iso-8859-1?Q?SPOCKR8ahyj57Lzyzm9XL1FDcGLk+SebbJKgPYzpw6CyArP8lMDWk0nBar?= =?iso-8859-1?Q?H+3q9PEBS5XRnGzlNEbBYIB2Wc+k4RQ7RlPMypVqkGydFxfAfR6fbAkKsB?= =?iso-8859-1?Q?+V40flIS9tITWI4L1ybS2uctI4cIalVroIpHIO32uFOd+c4vpt6gG4EoX4?= =?iso-8859-1?Q?n0rcRfD0f7uCAzoNg0QSSGBmN0l/vpC8eJvgQRTXWNqTsV/wjxiE7c7GCW?= =?iso-8859-1?Q?U0Yc7MMH2TUJgz9pVVgvzaJ9VXoOoqq42VW0K8XSBZVW6djQecjdBoMtdo?= =?iso-8859-1?Q?uP3mPanZPW8FUIszn8/iXMFx0T4xorS0V6mMDcPIiFJmZiemu590sXOMWX?= =?iso-8859-1?Q?ahvmWiiR3f4HO+XZgwLBXjhf78Z+jFNeO4iIcSDH/XuD994gBHeAbAaLKE?= =?iso-8859-1?Q?ql2vyvSqKLomsLLfZltBguSdZbkjbgM646KfgKfvoMJTiptfcV+Pi28m+M?= =?iso-8859-1?Q?gBZl2dOpntPWSR3uAt8Vks4z9PjkfS2QSLjk+Sbq5rXnQ6pDpQ+P+9ZXnT?= =?iso-8859-1?Q?HuNVqYbwCG68T7jWbRrPWJi90DmzCnaG5q5KTvtEFit69u6+jxh1FpjdUD?= =?iso-8859-1?Q?vKh8kBXjNI8eodZ1ms/x41bHds7sw9G0oX4Wcn7nxs8EQ1UvDHDW8vj+iI?= =?iso-8859-1?Q?dmcTdgVdoTydoPGMNEJXrpe0o7aTnuXJceXixoJSMQAMeLjDadHPY38U4l?= =?iso-8859-1?Q?vGMBci6sMVsA9O2qrGIdBnuPfM4HK50DUaHqiDlRcgizSdwQcHplHAXQDb?= =?iso-8859-1?Q?L9bvr1sZr2jEG77ajftONNKfR/nDoaQiWDukiYuhBYjqGjcyDTrk77L4BP?= =?iso-8859-1?Q?qC6+kd/bkw2yFpBILeIrkJ5rdqg/bXQaHO8zidvoMj5dbVIwvafBCz7uK6?= =?iso-8859-1?Q?u19FR38ruYHIm9amIpTcCfEt79Ka42ksKStpO00VfRKpf0/vd5UwcaShhh?= =?iso-8859-1?Q?TSJz/lWMBNCT7oacDJicSgAyM3VWwE4rHk19HcfFhYz/5AcPI4FTO7dZ3p?= =?iso-8859-1?Q?TKsEI1otMnzeWYyO5M4WTnoZFNWODXsKsrChoR/hXNH3qx0DT8Rp3M5R5z?= =?iso-8859-1?Q?yEsFgqOKqph1X1K5HjfbEDC8cUviUIaZc7zIcuZEMTyQMSAFSCAQjmcirg?= =?iso-8859-1?Q?2Q1HW+n8ls1q3NkTguM=3D?= Content-Type: multipart/alternative; boundary="_000_BL0PR05MB531650A4C906A9AD92C07D18AE849BL0PR05MB5316namp_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: BL0PR05MB5316.namprd05.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: f280e869-644e-4910-9017-08d998c2fc3c X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2021 20:55:47.0941 (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: f/fXm5ifAmaTx/ddZ7ba/xLOfH3cxmuSMtI5rGrHUa84YB54862Nx2S+Cu+5arMLkooNq2P8y+arALe3kWXvDw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB5138 X-Proofpoint-ORIG-GUID: _5bEW3P3Fqj4qXKrBeF5hzFLZUDwzGK9 X-Proofpoint-GUID: _5bEW3P3Fqj4qXKrBeF5hzFLZUDwzGK9 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-26_06,2021-10-26_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 mlxscore=0 mlxlogscore=999 phishscore=0 impostorscore=0 suspectscore=0 spamscore=0 clxscore=1015 bulkscore=0 adultscore=0 lowpriorityscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2110260113 Archived-At: Subject: Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 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, 26 Oct 2021 20:55:56 -0000 --_000_BL0PR05MB531650A4C906A9AD92C07D18AE849BL0PR05MB5316namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Robert, Please read the Metric for this requirement: * Metric: The utilization metric (U) records whether a proposal utilize= s the SRv6 specifications. * A proposal can use 8404, 8986, etc and still change the SRv6 data plane. Ron Juniper Business Use Only From: Robert Raszuk Sent: Tuesday, October 26, 2021 4:10 PM To: Ron Bonica Cc: John Scudder ; draft-filsfilscheng-spring-srv6-srh-com= pression@ietf.org; spring@ietf.org Subject: Re: [spring] "This solution does not require any SRH data plane ch= ange" in draft-filsfilscheng-spring-srv6-srh-compression-02 [External Email. Be cautious of content] 4. SRv6 Specific Requirements 4.1. SRv6 Based Description: A solution to compress SRv6 SID Lists SHOULD be based on the SRv6 architecture, control plane and data plane. The compression solution MAY be based on a different data plane and control plane, provided that it derives sufficient benefit. It is clearly a requirement. It is not an exclusive requirement, but that d= oes not make it of any less importance as evaluation criteria. Analysis dra= ft provides comparison table in section 3.1 But please let's not derail this thread as I provided a specific question t= o John. On Tue, Oct 26, 2021 at 10:01 PM Ron Bonica > wrote: Many thx, R. Robert, Which requirement was that? Ron Juniper Business Use Only From: spring > On B= ehalf Of Robert Raszuk Sent: Tuesday, October 26, 2021 3:41 PM To: John Scudder > Cc: draft-filsfilscheng-spring-srv6-srh-compression@ietf.org; spring@ietf.org Subject: Re: [spring] "This solution does not require any SRH data plane ch= ange" in draft-filsfilscheng-spring-srv6-srh-compression-02 [External Email. Be cautious of content] Hello John, May I inquire what was not definitive as part of my answer ? Please observe that below documents which are product of this WG go in dept= h to evaluate compression against the requirement not to change SRv6 data p= lane: https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-req= uirement https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-ana= lysis Would your enquiry be satisfied if the draft in question s/SRH data plane/S= Rv6 data plane/ ? Kind regards, Robert On Tue, Oct 26, 2021 at 7:55 PM John Scudder > wrote: (For clarity: I'm not wearing any hats other than "WG contributor".) Hi All, Since there hasn't been any definitive answer from the authors, nor any upd= ate to the draft to address the issue, and given that the disputed statemen= t seems to be an important premise for evaluation of the fitness of the dra= ft for adoption (at least, the authors considered it fundamental enough to = put in the abstract): I'm opposed to adoption of the draft until this quest= ion has been settled, or at least meaningfully addressed. Regards, -John P.S.: I will also follow up to the main adoption thread to assist with issu= e tracking. > On Oct 13, 2021, at 6:28 PM, John Scudder > wrote: > > > Hi Folks, > > I'm struggling with the claim repeated throughout the beginning of draft-= filsfilscheng-spring-srv6-srh-compression-02 (Abstract, =A71, =A73) that "t= his solution does not require any SRH data plane change". > > I'm not aware of a standardized formal definition of "data plane", it see= ms to follow Justice Stewart's maxim of "I know it when I see it". However,= here's an attempt, cribbed from some Washington University course slides: = a "local, per-router function that determines how a datagram arriving on a = router input port is forwarded to a router output port". Seems reasonable. > > I also am not aware of a standardized formal definition of the term "SRH = data plane", in fact this draft, its predecessors, some associated blog pos= ts, and Clarence's dissertation, are the only places a search finds the phr= ase (but it's not formally defined in any of them). So I'm just going to as= sume it means the data plane, as applied to packets that include an SRH. (I= 'm not sure why we should disregard packets that are encoded using NEXT-C-S= ID that omit the SRH, but let's overlook that for now.) > > If this solution does not require any SRH data plane change, presumably i= t would be true that if I take a packet that includes an SRH and place with= in it a series of SIDs encoded with (for example) the REPLACE-C-SID flavor,= then that packet would be able to successfully traverse a network of route= rs that support plain vanilla RFC 8754. That is, it would arrive at its fir= st hop router which according to a local, per-router function, would determ= ine how to take the datagram arriving on the router input port and forward = it to (the correct) router output port. Then that process would be repeated= across the rest of the network. > > But that is patently incorrect: when it's delivered to the first hop, the= plain vanilla RFC 8754 router will be unable to apply the REPLACE-C-SID be= havior, and forwarding to the next hop will fail. It seems that a different= local, per-router function is required (in fact, the local, per-router fun= ction defined in the draft) in order for the forwarding to succeed. By the = definitions I'm using here, that is exactly a data plane change. > > What, precisely, is then being claimed? > > Thanks, > > -John > _______________________________________________ > spring mailing list > spring@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring_= _;!!NEt6yMaO-gk!S7rbnYg6aV2s3cyoTCL3wwWX4bpbFoawPLt6yLeYsms82sLl9tUpRU1X5c-= D9A$ --_000_BL0PR05MB531650A4C906A9AD92C07D18AE849BL0PR05MB5316namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

    Robert,<= /span>

     

    Please read the Met= ric for this requirement:

     

    • Metric: The utilization metric (U) r= ecords whether a proposal utilizes the SRv6 specifications.
    •  
      • =

    A proposal can use = 8404, 8986, etc and still change the SRv6 data plane.

     

       &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;             =        Ron

     

     

     

     

    Juniper Business Use Only

    From: Robert Raszuk <robert@raszuk.net>=
    Sent: Tuesday, October 26, 2021 4:10 PM
    To: Ron Bonica <rbonica@juniper.net>
    Cc: John Scudder <jgs@juniper.net>; draft-filsfilscheng-spring= -srv6-srh-compression@ietf.org; spring@ietf.org
    Subject: Re: [spring] "This solution does not require any SRH d= ata plane change" in draft-filsfilscheng-spring-srv6-srh-compression-0= 2

     

    <= span style=3D"font-size:10.5pt;font-family:"Lato",sans-serif;colo= r:black">[External Email. Be cautious of content]

     

    4.  SRv6 Specific Requirements

    4.1.  SRv6 Based

       Description: A solution to compress SRv6 SID Lists SHOULD b= e based on
       the SRv6 architecture, control plane and data plane.      = ;The compression
       solution MAY be based on a different data plane and control pl= ane,
       provided that it derives sufficient benefit.

     

    It is clearly a requirement. It is not an exclusive = requirement, but that does not make it of any less importance as evalu= ation criteria. Analysis draft provides comparison table in section 3.1&nbs= p;

     

    But please let's not derail this thread as I provide= d a specific question to John. 

     

    On Tue, Oct 26, 2021 at 10:01 PM Ron Bonica <rbonica@juniper.net> wrote:<= /o:p>

     

    Many thx,

    R.

    Robert,

     

    Which requirement was that?

     

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

     

     

     

    Juniper Business Use Only

    From: spring <spring-bounces@ietf.org> On Behalf Of Robert Raszuk
    Sent: Tuesday, October 26, 2021 3:41 PM
    To: John Scudder <jgs@juniper.net>
    Cc: draft-filsfilscheng-spring-srv6-srh-compression@ietf.org; spring@ietf.org
    Subject: Re: [spring] "This solution does not require any SRH d= ata plane change" in draft-filsfilscheng-spring-srv6-srh-compression-0= 2

     

    [External Email. Be cautious of content]=

     

    Hello John,

     

    May I inquire what was not definitive as part of my answer ? =

     

    Please observe that below documents which are product of this WG g= o in depth to evaluate compression against the requirement not to change SR= v6 data plane: 

     

     

    On Tue, Oct 26, 2021 at 7:55 PM John Scudder <jgs@juniper.net> wrote:

    (For clarity: I’m not wearing any hats other than “WG contri= butor”.)

    Hi All,

    Since there hasn’t been any definitive answer from the authors, nor a= ny update to the draft to address the issue, and given that the disputed st= atement seems to be an important premise for evaluation of the fitness of t= he draft for adoption (at least, the authors considered it fundamental enough to put in the abstract): I’m oppose= d to adoption of the draft until this question has been settled, or at leas= t meaningfully addressed.

    Regards,

    —John

    P.S.: I will also follow up to the main adoption thread to assist with issu= e tracking.

    > On Oct 13, 2021, at 6:28 PM, John Scudder <jgs=3D40juniper.net@dmarc.ietf.or= g> wrote:
    >
    >
    > Hi Folks,
    >
    > I’m struggling with the claim repeated throughout the beginning = of draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, =A71, =A73= ) that “this solution does not require any SRH data plane change̶= 1;.
    >
    > I’m not aware of a standardized formal definition of “data= plane”, it seems to follow Justice Stewart’s maxim of “I= know it when I see it”. However, here’s an attempt, cribbed fr= om some Washington University course slides: a “local, per-router fun= ction that determines how a datagram arriving on a router input port is forwarded to = a router output port”. Seems reasonable.
    >
    > I also am not aware of a standardized formal definition of the term &#= 8220;SRH data plane”, in fact this draft, its predecessors, some asso= ciated blog posts, and Clarence’s dissertation, are the only places a= search finds the phrase (but it’s not formally defined in any of them). So I’m just going to assume it means the data plane= , as applied to packets that include an SRH. (I’m not sure why we sho= uld disregard packets that are encoded using NEXT-C-SID that omit the SRH, = but let’s overlook that for now.)
    >
    > If this solution does not require any SRH data plane change, presumabl= y it would be true that if I take a packet that includes an SRH and place w= ithin it a series of SIDs encoded with (for example) the REPLACE-C-SID flav= or, then that packet would be able to successfully traverse a network of routers that support plain vanilla R= FC 8754. That is, it would arrive at its first hop router which according t= o a local, per-router function, would determine how to take the datagram ar= riving on the router input port and forward it to (the correct) router output port. Then that process woul= d be repeated across the rest of the network.
    >
    > But that is patently incorrect: when it’s delivered to the first= hop, the plain vanilla RFC 8754 router will be unable to apply the REPLACE= -C-SID behavior, and forwarding to the next hop will fail. It seems that a = different local, per-router function is required (in fact, the local, per-router function defined in the draft) in order fo= r the forwarding to succeed. By the definitions I’m using here, that = is exactly a data plane change.
    >
    > What, precisely, is then being claimed?
    >
    > Thanks,
    >
    > —John
    > _______________________________________________
    > spring mailing list
    > spring@ietf.org
    >     https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;= !!NEt6yMaO-gk!S7rbnYg6aV2s3cyoTCL3wwWX4bpbFoawPLt6yLeYsms82sLl9tUpRU1X5c-D9= A$

    --_000_BL0PR05MB531650A4C906A9AD92C07D18AE849BL0PR05MB5316namp_-- From nobody Tue Oct 26 14:23:56 2021 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 8126B3A1D6A; Tue, 26 Oct 2021 14:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=LGXcnEPa; dkim=pass (1024-bit key) header.d=juniper.net header.b=Oj5zIF7E 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 pjzprxcjYOdq; Tue, 26 Oct 2021 14:23:43 -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 788B23A1FBF; Tue, 26 Oct 2021 14:21:56 -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 SMTP id 19QFoRXx002854; Tue, 26 Oct 2021 14:21:55 -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=9rbrKTaXgfY0+D7JkwqEr6jxsseR4CtKuI93a/av1vo=; b=LGXcnEParmtD085bsHu7uf6r0bqSeCwLuL4R5ED5bL7BFKmObD38SmDHlYaKmXmOV67Z DhfNnXRpBC1XVKUWhje6qws9n74Trl3xOlb56YjMAsUSe5iVMspjdndciXFxR3rEk6Jl ir/kjdmXUOOtCMgmgjb4pFTXBZb18goikn3KawgWVgwVor+Qgy84tEl2RUcYS16FcSXo SDViFUjk0JFQ0Z2DaqhoGVpk3iexCDYwoOySNEi5aqF4jWwQEE4hwxYiZ+tyWYT2HTnd FY4S4o4hWoDA/PRnEE62n1iYr8idlhzDINIQ7n3gatxNxAHHkLGFXR2tGlBhPFbVc0jH kQ== Received: from nam11-bn8-obe.outbound.protection.outlook.com (mail-bn8nam11lp2174.outbound.protection.outlook.com [104.47.58.174]) by mx0b-00273201.pphosted.com with ESMTP id 3bxmnx0q2p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Oct 2021 14:21:55 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kRf1TfirgUpywRz0VzedTcdKjmKaUL+Mto0kfsXiLKp6YqP2Jhr409y/GgTZU41Yd9WQciMs6xoS98bFX6Fz2IOCOxfm8VIOyY+4BmMiEXF7Nj7FJgbC6o334eH0j5GdJvptkRyz8BVdpRtLrPWY/yVFtipMJ9dR59Cx8ulJm06NKCINX8xz/lKUFoIgQy660tDQulSpDps1wZ0ah9vnyLwYOKlY2/cBJhF7QpCuAqoMHriq5MvsI7QHjhufAtQ+ieTPUx2mJV6acgDXrZeQ7u4vCYiI21V9ul+CtpXVHrR2ktxtt2L/LiFdg0p9tbg23bBHUJS/BrV8y0zT3vX2jA== 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=9rbrKTaXgfY0+D7JkwqEr6jxsseR4CtKuI93a/av1vo=; b=VcBjjorkv1od4sTy+kIwa+Iawrh2SNr4+I6GwUmVrkQSbnYMpw8h73WZt4qNAzeypEh7uqovhcOWp9o8WUpLXCvwX0qJTSMqJhjo1GBhnW3R3+R3jBuWwuqFsqNfDAzmsjoFfuHqli80I4fgZ2IY9FKdXIWlvyp7diCIx8gLxKtKvoCSM6UFEyYi6rIWrWXXLcUrxJW4KmWRbqbykTd2NTVr2xjGpDWyRaGOkAr7DVFTqs8x3G+2BsSC9j7h5ionluQfeH6KQghubUpM96qO2Prs85UzQWGQaUiQSNREyLdsekq8YvtG/VkRSM5GhVYQPqfEz3wkUrSGt0/tAAqtPA== 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=9rbrKTaXgfY0+D7JkwqEr6jxsseR4CtKuI93a/av1vo=; b=Oj5zIF7Em1SR7kcDEa4X4iCwqeQVdqOtwcbUO21uZkXkgRGKpxUpPkNg3WRS52gFW4VTHD8p9bKthvI1BwBllq6k+//0Lw6Qk7TqhM0bAbb9gWNi26thErVAMDv0FqL+TpTarKnpUeYjxrrIdxqphpwGaSLSRi4WrI9AWVKGcZ0= Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by MN2PR05MB6064.namprd05.prod.outlook.com (2603:10b6:208:c4::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.14; Tue, 26 Oct 2021 21:21:49 +0000 Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::10b9:2bb9:11f2:6b4a]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::10b9:2bb9:11f2:6b4a%3]) with mapi id 15.20.4649.014; Tue, 26 Oct 2021 21:21:48 +0000 From: John Scudder To: Robert Raszuk CC: "draft-filsfilscheng-spring-srv6-srh-compression@ietf.org" , "spring@ietf.org" Thread-Topic: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 Thread-Index: AQHXwIGtAQ5iI0HLYkm+pjy3rdbrTKvlpE+AgAAdjACAABwZAA== Date: Tue, 26 Oct 2021 21:21:48 +0000 Message-ID: <39FF1295-2B0D-40B4-9BE9-CF26EB0C70AC@juniper.net> References: <1EB19A49-C12A-425D-ADB7-6E0B0F2CA66D@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.3654.120.0.1.13) authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0195dd77-8d90-49d5-1d7c-08d998c69f0e x-ms-traffictypediagnostic: MN2PR05MB6064: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: SG1IrcuNsOGn5N0APhUzGwRFi6O5Akdh6eHRPs6ZklvgKuMvpVM3zy1aGMmBbvLgdggJR3q0r6P6aRNAWtQqQ/d02xmUXS5gYeUtVy2ocdc8NmGfwNGHqtJ5FAHxo9+htbbFISgITK79ZBv6gsZyNrqvczTGXRe4cpGPy7u2pnjpowBpS3/t4CGUVMZ+7B9fzY39PbIMN/LJXdwGldjyp9sCx7cl7ykEQhiuv4NroOk8DySWnhZPBeZwRn60PaX3T04HB2OyhGfRDmFLh5olx/kxYYQmbma5fnTpP+JE7j5pVznUem7mGoucE6m5aAfBCzYbQiSPxP4IG9vF3LIk0vit8kVvc71BtGVmu375jY6aVvNs3UO050hfJN+oPCwk8XPMIzSQk8Wr7Wl985ng3nlEOZI4g7V1+XtbMF2oTVPzbPeuWxhFg4WJzLeVtcSmHkwexH+++S9ADQ5/7FQwnILFnpKn9PfPL4yRRohePSjhuSwDAxJP+onKqP9Ax5HsTntpwbmUKOY5vh1fxJW/pd9LkWCzCHtf0laXbr/I3shHnn4dKMRBQOU+M9tnMOkZ8f38obqtoe6uW42ePIw4NZH0nASFH3a8S7pqG3WPCQeW8YL7dYh77zUdJJA/+QlUgGgIOQr5B6WlBPmxdc5hMuV9Me2TrFuDR3C8hdMGXYbdDsmnvifvqIvi0gTvasT25w+uO9IpwVNdVdpJx1NeYsIZqf1JOK2+7c1HlrEHq4DJvErRgEE6acU0WucEOzxWcYubNSeZffs8UTVqGpH+tESeDNutL4WVkSevNhdK76PeNnzch5COpQr8vstWHJM/MpLihB78cMVqkKm7eby8O7ASwsHa5UaU7TzTAitAPgQ= 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:(4636009)(366004)(66556008)(64756008)(186003)(86362001)(66946007)(26005)(66476007)(38070700005)(66446008)(76116006)(91956017)(33656002)(6916009)(316002)(966005)(71200400001)(6512007)(83380400001)(38100700002)(5660300002)(8676002)(122000001)(508600001)(36756003)(6506007)(8936002)(53546011)(2906002)(4326008)(66574015)(2616005)(54906003)(6486002)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?bHNORk5rUzFWNG81cjVBVkRGMUgwdFZMWGRoTEdpZm4yZFhzTHhiTktJTGdj?= =?utf-8?B?eDAzb1F4czNka0NKSjJkNlk5UC8wamlMZ3o5TXNUODZZMi96SlRkMmd4QWUv?= =?utf-8?B?aVIvLzYrdnlDZXFXZEJjaTlGVGRDQ2NCZW1pTGZFR2xSNjF5WWVhNXR4eC9H?= =?utf-8?B?T3hlWXpKVExCUnpXTEcwY1NjcDRGRlFtd1RncHlGSTE3QUlXa2h1bUZkc2JQ?= =?utf-8?B?SDAxOWhWejQ0Q3gycDFzbmw5QThaa1o2NExPcGJFSDdGN3lUckluNzFwbzgx?= =?utf-8?B?NUNYWTY2R2FqYUV2RkdoVkVqYmV4b2MrRE5QNFBtb3FJRlF5aGVhaWtnVUhD?= =?utf-8?B?TmVxYndFa2pCUDlyVkUwMWdnOXJkUmtLOUpMN1kxOVJ1c0F6NllJNXMzZUJz?= =?utf-8?B?cmc2TnYrT3g1UXNMc2xxYXFoaU1RSmtzNWpHRHN6S05WaUY5eStaWWZZY0pu?= =?utf-8?B?RkpWeitGeFdlK3ZBbVhyOVI5cUg3eks1cUZuZFozRWZmY24rc2FRVjlWTThV?= =?utf-8?B?WGE0QWtQa0tvdVJZbkRvV2ZNd3kyVzlrTGZoelhkbThaQlg0UUttS1QxcHI2?= =?utf-8?B?a1ROMEFOVjl3OU1hR3Y3ZGZmUDQ0TFJTS0NDY2VweVY3QlN4SHEwS1Z1cnpN?= =?utf-8?B?MXYzazEzcUhwbk5ZOW1KS2ZyVGcrbWNtaUIxeXBQTVh3RHZEQVdDcUNBUFZG?= =?utf-8?B?ZDRRbnl1T3VRVXhjREFIQTVTQVd6Rkt6NHdTY0ZvRjJXS1liNU5yTUM3K2Uv?= =?utf-8?B?ckc2R0FtejhuaDU5Y05ibk5KWndUTVI2dEtreFJNNnVLV05XZ0t3SmJTZTF3?= =?utf-8?B?VWttTHJwUUxiWFpiV1RRWGhWbEp5dGJrWUFGOWFDb3pOOHJZK0xHcVNybldl?= =?utf-8?B?cjFtbE0zdENsSzNBNG9ZbHBqOUJFbE50NUl6RUhHV3lwK2pncko2KzJVVUZM?= =?utf-8?B?RC9zejRBNnZTSDZVT3BTSDRNY25OZGdzSDVNNFcycnZDMmhGdlBDaHZkQVRy?= =?utf-8?B?aWlGZ0ZTNVVjcWY5cmNEYW4zemZCZDdSL29yaUo1alNqYTZ3cTgrNHFtY0dB?= =?utf-8?B?WDlmTUhuOVIyVmpibTN0QWRaWDhxTEVsanNOcGhRRmVzNzhWZUpMVDZZVkU2?= =?utf-8?B?bXVUTVY2UU5OWnJHUU5qOHhIYTd0QVZqS2g3U0toNm9TSk1RMUQ3RnhmNGN3?= =?utf-8?B?V01DQjg4NjNHcmprZ1hOYzkyVmsxaDJTdHlmQTRwYytaeHhQN0tsamRxTTU5?= =?utf-8?B?N0Uremc3K3BwU1F4b0l0YVo4cE1jYnovajE1L1A3NUt4VlRjb0ZSV3JwemUw?= =?utf-8?B?aStRdDZSSDRnUnYwSDNSMHc2Ni8wTVRlUzI5bW9aUmN2R1Fnd1p0YWNTUUwr?= =?utf-8?B?KytaTEtiYzVZV29HTUlIM3Z4U2xGc2dicnVXM2FOSzN5WWFwSk91VFJla3RX?= =?utf-8?B?RlNkVlk1RWpMZHNwTDdkWEc1enJCcGhYT2JIMDZhR0Vtc1FyR21hZWRRV3dP?= =?utf-8?B?N2JZSlJHclUwMForNWxqdDc5U0FjdWxJaXNmY0R3WjAzY3RlSXdPVlMxa3F6?= =?utf-8?B?UXZ0dys3elc1V2JuOFhsVkw1L0N6SWIxSHNsc3NETjA0YnFpNUdramdSY0pr?= =?utf-8?B?VzdGWi9weWdrWlBxdkJkaFRlUHJvZ1pWcEFwYmEycXE4MytRT2srME9rdkJs?= =?utf-8?B?WlBFVExycVU3OTFTanVCS2hpQnIvUFVob3QwdWJPM09Nd2d2NEFQVTRYRVI0?= =?utf-8?B?M2tDdXB6V25ReWYvSEJxU3A1SHVrVU9RYXRSdXhZaUwzVHh0ekwxNTl5bDQ0?= =?utf-8?B?a2hyZjl3U3pRempBOGlVcUc4Skp1dmVYL3hzOWs0K2ZJM3B2TGxSRUJpcC9I?= =?utf-8?B?YzFjMkpSQ2Y1TVd6SnpEbUlqTm44ZUQ0Ni8rYWF2VTY1M3U5Tk1GNnBWc3g1?= =?utf-8?B?RE1uQ0hUN3BRMm56SXhnZ2JXYjhLL0w2WVVKQWxKQ1RzdEZGY0dkU0VRRDRN?= =?utf-8?B?R2Jkd1RmeXVXQm1UNGZHYnV4UFVOT0xXMUI4SzlPNjdSdCtuekhYNkZKSzdv?= =?utf-8?B?R3JXajNWNy95UmtNUlVKaDhRbE4yMGJCamZMYVJEMm9lTGROVksyVjg5RWV4?= =?utf-8?Q?P6QveuRZekYC3Mix6OEmHO9oi?= 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: 0195dd77-8d90-49d5-1d7c-08d998c69f0e X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2021 21:21:48.7195 (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: 9grE24v0pU4mi9a5t7+8Wptae4MM0IGa+78p2tuSZ3Xq7u7iFbmIpDpUkjMHKjD4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6064 X-Proofpoint-GUID: uJ0k9QbvSBtU4QsU0F7CuUngj3ZQEI66 X-Proofpoint-ORIG-GUID: uJ0k9QbvSBtU4QsU0F7CuUngj3ZQEI66 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-26_06,2021-10-26_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 suspectscore=0 malwarescore=0 bulkscore=0 clxscore=1015 adultscore=0 lowpriorityscore=0 impostorscore=0 priorityscore=1501 phishscore=0 mlxscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2110260116 Archived-At: Subject: Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 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, 26 Oct 2021 21:23:56 -0000 SGkgUm9iZXJ0LA0KDQo+IE9uIE9jdCAyNiwgMjAyMSwgYXQgMzo0MSBQTSwgUm9iZXJ0IFJhc3p1 ayA8cm9iZXJ0QHJhc3p1ay5uZXQ+IHdyb3RlOg0KPiANCj4gSGVsbG8gSm9obiwNCj4gDQo+IE1h eSBJIGlucXVpcmUgd2hhdCB3YXMgbm90IGRlZmluaXRpdmUgYXMgcGFydCBvZiBteSBhbnN3ZXIg PyANCg0KSSBhbnN3ZXJlZCB0aGF0IGluIG15IHJlc3BvbnNlIHRvIHlvdXIgZWFybGllciBtZXNz YWdlOiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3NwcmluZy9kdEtDNlVt NlVTczBKZjctTHNzUlZzWnp3VHcvDQoNCj4gUGxlYXNlIG9ic2VydmUgdGhhdCBiZWxvdyBkb2N1 bWVudHMgd2hpY2ggYXJlIHByb2R1Y3Qgb2YgdGhpcyBXRyBnbyBpbiBkZXB0aCB0byBldmFsdWF0 ZSBjb21wcmVzc2lvbiBhZ2FpbnN0IHRoZSByZXF1aXJlbWVudCBub3QgdG8gY2hhbmdlIFNSdjYg ZGF0YSBwbGFuZTogDQo+IA0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1s L2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1yZXF1aXJlbWVudA0KDQpUaGlzIG9u ZSBzYXlzICjCpzQuMSkNCg0KICAgRGVzY3JpcHRpb246IEEgc29sdXRpb24gdG8gY29tcHJlc3Mg U1J2NiBTSUQgTGlzdHMgU0hPVUxEIGJlIGJhc2VkIG9uDQogICB0aGUgU1J2NiBhcmNoaXRlY3R1 cmUsIGNvbnRyb2wgcGxhbmUgYW5kIGRhdGEgcGxhbmUuICBUaGUgY29tcHJlc3Npb24NCiAgIHNv bHV0aW9uIE1BWSBiZSBiYXNlZCBvbiBhIGRpZmZlcmVudCBkYXRhIHBsYW5lIGFuZCBjb250cm9s IHBsYW5lLA0KICAgcHJvdmlkZWQgdGhhdCBpdCBkZXJpdmVzIHN1ZmZpY2llbnQgYmVuZWZpdC4N Cg0K4oCcQmFzZWQgb27igJ0gaXMgZGlmZmVyZW50IGZyb20g4oCcZG9lcyBub3QgY2hhbmdl4oCd LiBJIGRvbuKAmXQgc2VlIGFueSBkb2N1bWVudGF0aW9uIG9yIGNsYWltIG9mIHRoZSBsYXR0ZXIu DQoNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1zcmNvbXBk dC1zcHJpbmctY29tcHJlc3Npb24tYW5hbHlzaXMNCg0KU2ltaWxhcmx5ICjCpzMuMSkNCg0KICAg QSBzb2x1dGlvbiB0byBjb21wcmVzcyBTUnY2IFNJRCBMaXN0cyBTSE9VTEQgYmUgYmFzZWQgb24g dGhlIFNSdjYNCiAgIGFyY2hpdGVjdHVyZSwgY29udHJvbCBwbGFuZSBhbmQgZGF0YSBwbGFuZS4g IFRoZSBjb21wcmVzc2lvbiBzb2x1dGlvbg0KICAgTUFZIGJlIGJhc2VkIG9uIGEgZGlmZmVyZW50 IGRhdGEgcGxhbmUgYW5kIGNvbnRyb2wgcGxhbmUsIHByb3ZpZGVkDQogICB0aGF0IGl0IGRlcml2 ZXMgc3VmZmljaWVudCBiZW5lZml0Lg0K4oCmDQogICBDb25jbHVzaW9uOiBDU0lEIGlzIFNSdjYg YmFzZWQsIHJlcXVpcmluZyBubyB1cGRhdGVzIHRvIGV4aXN0aW5nIFNSdjYNCiAgIHN0YW5kYXJk cywgVlNJRCBhbmQgVUlEU1IgcmVxdWlyZSB1cGRhdGVzLiAgQ1JIIGlzIG5vdCBzdHJpY3RseSBi YXNlZA0KICAgb24gU1J2NiBidXQgaXMgYWJsZSB0byBwcm92aWRlIGVxdWl2YWxlbnQgZnVuY3Rp b25hbGl0eS4NCg0KVGhhdCBkb2VzIG1ha2UgdGhlIHN0cm9uZ2VyIGNsYWltIOKAnG5vIHVwZGF0 ZXMgdG8gZXhpc3RpbmcgU1J2NiBzdGFuZGFyZHPigJ0uIEl04oCZcyBzdGlsbCB0aGUgY2FzZSB0 aGF0IHRoaXMgaXMgbm90IHRoZSBzYW1lIGFzIHNheWluZyBpdCBkb2VzbuKAmXQgY2hhbmdlIHRo ZSBkYXRhIHBsYW5lLCBob3dldmVyLCBmb3IgdGhlIHJlYXNvbnMgSSBnYXZlIHByZXZpb3VzbHku DQoNCj4gV291bGQgeW91ciBlbnF1aXJ5IGJlIHNhdGlzZmllZCBpZiB0aGUgZHJhZnQgaW4gcXVl c3Rpb24gcy9TUkggZGF0YSBwbGFuZS9TUnY2IGRhdGEgcGxhbmUvID8gDQoNClVzaW5nIHRoZSBt b3JlIGNvbW1vbmx5LXVzZWQgdGVybSB3b3VsZCBiZSBhIGdvb2Qgc3RhcnQuIEkgdGhpbmsgaWYg dGhlIG9ubHkgY2hhbmdlIHdlcmUgdGhhdCwgdGhvdWdoLCBpdCB3b3VsZCBzdGlsbCBiZSBwcm9i bGVtYXRpYywgZm9yIGV4YW1wbGUgdGhlIHJldmlzZWQgYWJzdHJhY3Qgd291bGQgc2F5IOKAnFRo aXMgc29sdXRpb24gZG9lcyBub3QgcmVxdWlyZSBhbnkgU1J2NiBkYXRhIHBsYW5lIGNoYW5nZeKA nS4gQUZBSUNULCB0aGF0IHN0aWxsIGZhaWxzIHRoZSB0ZXN0IEkgcHJvcG9zZWQgaW4gbXkgaW5p dGlhbCBub3RlLg0KDQpSZWdhcmRzLA0KDQrigJRKb2huDQoNCj4gDQo+IA0KPiANCj4gS2luZCBy ZWdhcmRzLA0KPiANCj4gUm9iZXJ0DQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IE9uIFR1ZSwg T2N0IDI2LCAyMDIxIGF0IDc6NTUgUE0gSm9obiBTY3VkZGVyIDxqZ3NAanVuaXBlci5uZXQ+IHdy b3RlOg0KPiAoRm9yIGNsYXJpdHk6IEnigJltIG5vdCB3ZWFyaW5nIGFueSBoYXRzIG90aGVyIHRo YW4g4oCcV0cgY29udHJpYnV0b3LigJ0uKQ0KPiANCj4gSGkgQWxsLA0KPiANCj4gU2luY2UgdGhl cmUgaGFzbuKAmXQgYmVlbiBhbnkgZGVmaW5pdGl2ZSBhbnN3ZXIgZnJvbSB0aGUgYXV0aG9ycywg bm9yIGFueSB1cGRhdGUgdG8gdGhlIGRyYWZ0IHRvIGFkZHJlc3MgdGhlIGlzc3VlLCBhbmQgZ2l2 ZW4gdGhhdCB0aGUgZGlzcHV0ZWQgc3RhdGVtZW50IHNlZW1zIHRvIGJlIGFuIGltcG9ydGFudCBw cmVtaXNlIGZvciBldmFsdWF0aW9uIG9mIHRoZSBmaXRuZXNzIG9mIHRoZSBkcmFmdCBmb3IgYWRv cHRpb24gKGF0IGxlYXN0LCB0aGUgYXV0aG9ycyBjb25zaWRlcmVkIGl0IGZ1bmRhbWVudGFsIGVu b3VnaCB0byBwdXQgaW4gdGhlIGFic3RyYWN0KTogSeKAmW0gb3Bwb3NlZCB0byBhZG9wdGlvbiBv ZiB0aGUgZHJhZnQgdW50aWwgdGhpcyBxdWVzdGlvbiBoYXMgYmVlbiBzZXR0bGVkLCBvciBhdCBs ZWFzdCBtZWFuaW5nZnVsbHkgYWRkcmVzc2VkLg0KPiANCj4gUmVnYXJkcywNCj4gDQo+IOKAlEpv aG4NCj4gDQo+IFAuUy46IEkgd2lsbCBhbHNvIGZvbGxvdyB1cCB0byB0aGUgbWFpbiBhZG9wdGlv biB0aHJlYWQgdG8gYXNzaXN0IHdpdGggaXNzdWUgdHJhY2tpbmcuDQo+IA0KPiA+IE9uIE9jdCAx MywgMjAyMSwgYXQgNjoyOCBQTSwgSm9obiBTY3VkZGVyIDxqZ3M9NDBqdW5pcGVyLm5ldEBkbWFy Yy5pZXRmLm9yZz4gd3JvdGU6DQo+ID4gDQo+ID4gDQo+ID4gSGkgRm9sa3MsDQo+ID4gDQo+ID4g SeKAmW0gc3RydWdnbGluZyB3aXRoIHRoZSBjbGFpbSByZXBlYXRlZCB0aHJvdWdob3V0IHRoZSBi ZWdpbm5pbmcgb2YgZHJhZnQtZmlsc2ZpbHNjaGVuZy1zcHJpbmctc3J2Ni1zcmgtY29tcHJlc3Np b24tMDIgKEFic3RyYWN0LCDCpzEsIMKnMykgdGhhdCDigJx0aGlzIHNvbHV0aW9uIGRvZXMgbm90 IHJlcXVpcmUgYW55IFNSSCBkYXRhIHBsYW5lIGNoYW5nZeKAnS4NCj4gPiANCj4gPiBJ4oCZbSBu b3QgYXdhcmUgb2YgYSBzdGFuZGFyZGl6ZWQgZm9ybWFsIGRlZmluaXRpb24gb2Yg4oCcZGF0YSBw bGFuZeKAnSwgaXQgc2VlbXMgdG8gZm9sbG93IEp1c3RpY2UgU3Rld2FydOKAmXMgbWF4aW0gb2Yg 4oCcSSBrbm93IGl0IHdoZW4gSSBzZWUgaXTigJ0uIEhvd2V2ZXIsIGhlcmXigJlzIGFuIGF0dGVt cHQsIGNyaWJiZWQgZnJvbSBzb21lIFdhc2hpbmd0b24gVW5pdmVyc2l0eSBjb3Vyc2Ugc2xpZGVz OiBhIOKAnGxvY2FsLCBwZXItcm91dGVyIGZ1bmN0aW9uIHRoYXQgZGV0ZXJtaW5lcyBob3cgYSBk YXRhZ3JhbSBhcnJpdmluZyBvbiBhIHJvdXRlciBpbnB1dCBwb3J0IGlzIGZvcndhcmRlZCB0byBh IHJvdXRlciBvdXRwdXQgcG9ydOKAnS4gU2VlbXMgcmVhc29uYWJsZS4NCj4gPiANCj4gPiBJIGFs c28gYW0gbm90IGF3YXJlIG9mIGEgc3RhbmRhcmRpemVkIGZvcm1hbCBkZWZpbml0aW9uIG9mIHRo ZSB0ZXJtIOKAnFNSSCBkYXRhIHBsYW5l4oCdLCBpbiBmYWN0IHRoaXMgZHJhZnQsIGl0cyBwcmVk ZWNlc3NvcnMsIHNvbWUgYXNzb2NpYXRlZCBibG9nIHBvc3RzLCBhbmQgQ2xhcmVuY2XigJlzIGRp c3NlcnRhdGlvbiwgYXJlIHRoZSBvbmx5IHBsYWNlcyBhIHNlYXJjaCBmaW5kcyB0aGUgcGhyYXNl IChidXQgaXTigJlzIG5vdCBmb3JtYWxseSBkZWZpbmVkIGluIGFueSBvZiB0aGVtKS4gU28gSeKA mW0ganVzdCBnb2luZyB0byBhc3N1bWUgaXQgbWVhbnMgdGhlIGRhdGEgcGxhbmUsIGFzIGFwcGxp ZWQgdG8gcGFja2V0cyB0aGF0IGluY2x1ZGUgYW4gU1JILiAoSeKAmW0gbm90IHN1cmUgd2h5IHdl IHNob3VsZCBkaXNyZWdhcmQgcGFja2V0cyB0aGF0IGFyZSBlbmNvZGVkIHVzaW5nIE5FWFQtQy1T SUQgdGhhdCBvbWl0IHRoZSBTUkgsIGJ1dCBsZXTigJlzIG92ZXJsb29rIHRoYXQgZm9yIG5vdy4p DQo+ID4gDQo+ID4gSWYgdGhpcyBzb2x1dGlvbiBkb2VzIG5vdCByZXF1aXJlIGFueSBTUkggZGF0 YSBwbGFuZSBjaGFuZ2UsIHByZXN1bWFibHkgaXQgd291bGQgYmUgdHJ1ZSB0aGF0IGlmIEkgdGFr ZSBhIHBhY2tldCB0aGF0IGluY2x1ZGVzIGFuIFNSSCBhbmQgcGxhY2Ugd2l0aGluIGl0IGEgc2Vy aWVzIG9mIFNJRHMgZW5jb2RlZCB3aXRoIChmb3IgZXhhbXBsZSkgdGhlIFJFUExBQ0UtQy1TSUQg Zmxhdm9yLCB0aGVuIHRoYXQgcGFja2V0IHdvdWxkIGJlIGFibGUgdG8gc3VjY2Vzc2Z1bGx5IHRy YXZlcnNlIGEgbmV0d29yayBvZiByb3V0ZXJzIHRoYXQgc3VwcG9ydCBwbGFpbiB2YW5pbGxhIFJG QyA4NzU0LiBUaGF0IGlzLCBpdCB3b3VsZCBhcnJpdmUgYXQgaXRzIGZpcnN0IGhvcCByb3V0ZXIg d2hpY2ggYWNjb3JkaW5nIHRvIGEgbG9jYWwsIHBlci1yb3V0ZXIgZnVuY3Rpb24sIHdvdWxkIGRl dGVybWluZSBob3cgdG8gdGFrZSB0aGUgZGF0YWdyYW0gYXJyaXZpbmcgb24gdGhlIHJvdXRlciBp bnB1dCBwb3J0IGFuZCBmb3J3YXJkIGl0IHRvICh0aGUgY29ycmVjdCkgcm91dGVyIG91dHB1dCBw b3J0LiBUaGVuIHRoYXQgcHJvY2VzcyB3b3VsZCBiZSByZXBlYXRlZCBhY3Jvc3MgdGhlIHJlc3Qg b2YgdGhlIG5ldHdvcmsuDQo+ID4gDQo+ID4gQnV0IHRoYXQgaXMgcGF0ZW50bHkgaW5jb3JyZWN0 OiB3aGVuIGl04oCZcyBkZWxpdmVyZWQgdG8gdGhlIGZpcnN0IGhvcCwgdGhlIHBsYWluIHZhbmls bGEgUkZDIDg3NTQgcm91dGVyIHdpbGwgYmUgdW5hYmxlIHRvIGFwcGx5IHRoZSBSRVBMQUNFLUMt U0lEIGJlaGF2aW9yLCBhbmQgZm9yd2FyZGluZyB0byB0aGUgbmV4dCBob3Agd2lsbCBmYWlsLiBJ dCBzZWVtcyB0aGF0IGEgZGlmZmVyZW50IGxvY2FsLCBwZXItcm91dGVyIGZ1bmN0aW9uIGlzIHJl cXVpcmVkIChpbiBmYWN0LCB0aGUgbG9jYWwsIHBlci1yb3V0ZXIgZnVuY3Rpb24gZGVmaW5lZCBp biB0aGUgZHJhZnQpIGluIG9yZGVyIGZvciB0aGUgZm9yd2FyZGluZyB0byBzdWNjZWVkLiBCeSB0 aGUgZGVmaW5pdGlvbnMgSeKAmW0gdXNpbmcgaGVyZSwgdGhhdCBpcyBleGFjdGx5IGEgZGF0YSBw bGFuZSBjaGFuZ2UuDQo+ID4gDQo+ID4gV2hhdCwgcHJlY2lzZWx5LCBpcyB0aGVuIGJlaW5nIGNs YWltZWQ/DQo+ID4gDQo+ID4gVGhhbmtzLA0KPiA+IA0KPiA+IOKAlEpvaG4NCj4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHNwcmluZyBtYWls aW5nIGxpc3QNCj4gPiBzcHJpbmdAaWV0Zi5vcmcNCj4gPiBodHRwczovL3VybGRlZmVuc2UuY29t L3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmdfXzshIU5F dDZ5TWFPLWdrIVM3cmJuWWc2YVYyczNjeW9UQ0wzd3dXWDRicGJGb2F3UEx0NnlMZVlzbXM4MnNM bDl0VXBSVTFYNWMtRDlBJA0KPiANCg0K From nobody Tue Oct 26 14:31:34 2021 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 4ABAC3A18D5; Tue, 26 Oct 2021 14:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 Yc65Gk8n1Qph; Tue, 26 Oct 2021 14:31:26 -0700 (PDT) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 F1E533A1935; Tue, 26 Oct 2021 14:28:37 -0700 (PDT) Received: by mail-ed1-x536.google.com with SMTP id z20so2182031edi.0; Tue, 26 Oct 2021 14:28:37 -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=yrfkmXdOIe3cazMUUcOWm5SwrkBQxJphsUv7QeM7Bpw=; b=Ukd5UyStltw5ZaOc7Vai9b8cABOnGMZ6NEPgV6dAYv35VbuIZGBTnUulM2Hgp1fVk0 y2omwUbK2cY0U6p7NPJwVVtyExyvvvYSsKUfjdmnXNlTX8WfvDj0Oli+B45emyZQtzA0 u7LA1Koz/FR5ULh/pPFbe3/YEPNZHYX2EToEi294RRNOSyE+qA5mX/rfOzUHtx+iYQ7Y HmEbxbe4gGxAChuL1ViXEXwSw+stW18wgHSgoxJq1a+XRDiyWiRN3LFcev7hrn3u3MW9 ph2Lz6IwNqbkDoKZx9hhIK5Gp3BJx5Vo4pT8/F1cpTmqmPCfH18cPdrOTyP5z0TZXD3j HqqA== 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=yrfkmXdOIe3cazMUUcOWm5SwrkBQxJphsUv7QeM7Bpw=; b=tT7+2pra+E5MUM8Nk6dHdzUgj4JRDw9+HBtsNWx2PQOIYLIDvBcRkM7IQXXDghA7D+ 8QcnxuV+D/434U3ueydvBseHhxLRDtOQN1d4jJQRCE3bAKRFkYLDOhJSoF2Dg/195txs Z0VXu5qfwDcfwvHEAdtADoNjkDgODyVG/5fcjj7oOsPn7ZBfofIbrNoz424n1J5L/trO 0Fz+OpBe4lWoeJB4h1qx3HHg8/WU85+moTxlDgAfAIWQvJuQ69UF6mmzAYoLWOkXbh5l 6nJ5jU885yYa167VcKtSV8G/GW5cvpY4oV4Tq4usuegyTLG0+5br6oB6wLItB7xEKzJk vczw== X-Gm-Message-State: AOAM533uYTJSgLCATz/nkFYvYoyDK55di3y8nAUwLpeDgpyWk5WfGXYx qQTzhomvoFhSltCV/Cp2uDKvX9qEPNfQxNGiwsMgD3g7AaE= X-Google-Smtp-Source: ABdhPJyndW7GY2S+SPrB2LQie5CPd732gGF/RbjWwlBshRBuIov84OAt2PTBSCZybmDq9b3vARFAyFUT8+B3cgBeZ1E= X-Received: by 2002:a17:907:2d06:: with SMTP id gs6mr13656357ejc.477.1635283711375; Tue, 26 Oct 2021 14:28:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Tue, 26 Oct 2021 14:28:20 -0700 Message-ID: To: "Francois Clad (fclad)" Cc: Robert Raszuk , Ron Bonica , James Guichard , SPRING WG , "spring-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000b93d7405cf48287b" Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 26 Oct 2021 21:31:32 -0000 --000000000000b93d7405cf48287b Content-Type: text/plain; charset="UTF-8" Dear Francois et al., I appreciate your consideration of the scenarios when both compression methods were used. I'll be looking for the next update of the draft. I hope the authors will add a section with a clear description of scenarios when the two compression methods can be used. But in the meantime, I am still strongly concerned that adoption of the draft in its current version would violate the decision of the WG (as I understand the result of the earlier poll) to adopt a single compression method (not a single document that defines two (at the minimum) incompatible methods to compress SRv6 SIDs. I've read multiple notes that asserted that in the testing, the ability to mix REPLACE-C-SID and NEXT-C-SID was verified and confirmed. It seems to me that sharing more information about these tests could address my concern. But at this time, I strongly object to SPRING WG's adoption of the current draft version as it would violate the earlier decision reached by the WG. Regards, Greg On Wed, Oct 13, 2021 at 3:56 AM Francois Clad (fclad) wrote: > Hi Greg, > > > > Your understanding is correct. The C-SID flavors cannot be randomly mixed > within the same C-SID container. > > > > We can clarify the details related to the combination of flavors in a > C-SID container in an upcoming version of the draft. For example, the last > entry of a C-SID container can carry a C-SID bound to any behavior, > including one with another C-SID flavor. > > > > Thanks, > > Francois > > > > *From: *Greg Mirsky > *Date: *Friday, 8 October 2021 at 22:21 > *To: *Francois Clad (fclad) > *Cc: *Robert Raszuk , Ron Bonica 40juniper.net@dmarc.ietf.org>, James Guichard < > james.n.guichard@futurewei.com>, SPRING WG , > spring-chairs@ietf.org > *Subject: *Re: [spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > Hi Francois, > you've said that different flavors of C-SID can be present not only in the > same SRH but also in the same C-SID container. The latter case got me > thinking about several potential scenarios. Have to admit that I got stuck > trying to understand how they can work. I hope you can help me out. Please > consider the two cases described below. > > Consider, for all cases, that we are handling a container with entries A, > B, C, and D, of some mix of NEXT-C-SID and REPLACE-C-SID flavors. > > Case 1: > Suppose that A was the REPLACE-C-SID flavor C-SID and B is the NEXT-C-SID > flavor. When A is processed, B will be copied into the IPv6 DA, retaining > the prefix before A in the container. So far, so good. Then, when the > packet arrives at the node that processes B, it will say "NEXT". The > remaining bits will be? I thought zero, but actually, it will presumably be > two bits with the value two? So the subsequent behavior will shift that two > up? Even if the NEXT-C-SID flavor guesses that the two should be zero, it > would skip C and D and pick up the entry from the next C-SID container in > the SRH. So it seems to either work wrong or work oddly? > > Case 2: > Suppose that A was the NEXT-C-SID flavor. So it simply shifts B, C, D > upwards in the IPv6 DA. Suppose B is the REPLACE-C-SID flavor. It will > interpret the upper bits of the C C-SID as the arg for selecting the > position in the C-SID container to pull an entry from. It will also modify > the C C-SID to perform the decrement it thinks it needs. It will then > overwrite itself with the randomly chosen entry from the container. > > It seems that neither scenario works. At least, I cannot figure out how it > can work. I would greatly appreciate it if you could have a look and > clarify it for me. > > Regards, > > Greg > > > > On Fri, Oct 8, 2021 at 10:12 AM Francois Clad (fclad) > wrote: > > Hi Greg, > > > > Thank you for the confirmation. I am glad that the matter of combining > C-SIDs of different flavors is clear now. > > > > Thanks, > > Francois > > > > *From: *Greg Mirsky > *Date: *Thursday, 7 October 2021 at 20:15 > *To: *Francois Clad (fclad) > *Cc: *Robert Raszuk , Ron Bonica 40juniper.net@dmarc.ietf.org>, James Guichard < > james.n.guichard@futurewei.com>, SPRING WG , > spring-chairs@ietf.org > *Subject: *Re: [spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > Hi Francois, > > thank you for your detailed response and confirming that C-SIDs of > different flavors/behavior may be present in the same SRH and even the same > CSID container. I've noticed Ron's proposal as I was trying to formulate my > question. His proposal highlighted what I am trying to understand - the > relationship between NEXT-C-SID and REPLACE-C-SID. I concur with Ron. The > WG has adopted the compression analysis draft > , > and the updates and an additional analysis Ron proposed will keep the > discussion and decision-making process on the firm technical foundation. > > > > Regards, > > Greg > > > > On Thu, Oct 7, 2021 at 9:17 AM Francois Clad (fclad) > wrote: > > Hi Greg, > > > > It is the role of the SR Source Node [Section 3.1 of RFC 8754] to form the > segment list in the SRH. It learns about the available SIDs in the network > with their associated behavior and flavors via control plane and/or > management plane protocols, as described in Section 8 of RFC 8986, and > selects the SIDs that are the most appropriate for the segment list. > > > > Each SR Segment Endpoint Node [Section 3.3 of RFC 8754] simply executes > the pseudocode of a locally instantiated SID when it receives a packet > matching that SID. The SR Segment Endpoint Node does not need to bother > about the behavior/flavor of the subsequent SRv6 SIDs. > > > > This SRv6 logic applies to the C-SID flavors as well. The choice of > flavors for the SIDs in the SID List is up to the SR Source Node. > > > > It is indeed possible to mix SIDs of different C-SID flavors in the same > SRH, and even in a single C-SID container. > > > > Thanks, > > Francois > > > > > > *From: *Greg Mirsky > *Date: *Wednesday, 6 October 2021 at 19:19 > *To: *Francois Clad (fclad) > *Cc: *Robert Raszuk , Ron Bonica 40juniper.net@dmarc.ietf.org>, James Guichard < > james.n.guichard@futurewei.com>, SPRING WG , > spring-chairs@ietf.org > *Subject: *Re: [spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > Hi Francois, > > thank you for the clarification. It is still not clear how a node selects > which flavor of CSID to use on the next compressed CSID that may happen > also be in the next CSID container. As I understand it, a CSID container > must use the same flavor of compression but CSID containers with different > compression flavors in the same SRH are allowed. Is that correct > understanding? > > > > Regards, > > Greg > > > > On Wed, Oct 6, 2021 at 7:05 AM Francois Clad (fclad) > wrote: > > Hi Greg, > > > > A node that supports this draft in its entirety can instantiate SRv6 SIDs > (e.g., End and End.X SIDs) with any of the three C-SID flavors. > > > > In particular, a node can instantiate multiple SRv6 SIDs bound to > different C-SID flavors, possibly with different C-SID lengths. It can also > instantiate SRv6 SIDs with behaviors and flavors defined in RFC 8986. > > > > As defined in Section 4.3 of RFC 8754 and again in Section 3 of RFC 8986, > upon receiving an IPv6 packet with a destination address matching a FIB > entry that represents one of these locally instantiated SIDs, the node > processes the packet according to the behavior (and flavor(s)) (i.e. > pseudocode) of that SID. > > > > RFC 8754 and 8986 have already standardized these mechanisms and the C-SID > draft only leverages the same SRv6 dataplane to introduce new endpoint > flavors for compression. > > > > > > Francois > > > > *From: *spring on behalf of Greg Mirsky < > gregimirsky@gmail.com> > *Date: *Tuesday, 5 October 2021 at 23:37 > *To: *Robert Raszuk > *Cc: *Ron Bonica , James Guichard < > james.n.guichard@futurewei.com>, SPRING WG , > spring-chairs@ietf.org > *Subject: *Re: [spring] WG Adoption call for > https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ > > Hi Robert, > > as I understand it, you believe everything that is written in the draft. I > hope you can help me find an answer to one simple question: > > Can a node that supports this draft in its entirety, i.e., supports all > "flavors" defined in the document, process received SRv6 packet with the > SRH encoded according to the specification? > > So far, the proponents of the draft referred to "planning" how flavors of > SRv6 SID compressed. To the best of my understanding, that is is a clear > demonstration of the incompatibility between flavors defined in the CSID > draft. Regardless of what is written in it. > > > > Regards, > > Greg > > > > On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk wrote: > > Ron & SPRING WG chairs, > > > > Through this discussion we first have seen a debate if we need one or more > data planes to compress SIDs in SRv6. WG clearly stated we need one. > > > > Following that we have observed a first terminology shift to see if asking > how many solutions should be supported will work any better. To that many > WG members clearly stated that they support one solution. > > > > Well please notice that the draft in question in its introduction states: > > > > Abstract > > This document defines a compressed SRv6 Segment List Encoding in the > Segment Routing Header (SRH). *This solution* does not require any SRH > data plane change nor any SRv6 control plane change. *This solution* > leverages the SRv6 Network Programming model. > > > > So based on my understanding of English the entire draft talks about a > single solution. > > > > Then suddenly a new question popped up: how many behaviours are > acceptable. > > > > I bet number of folks including myself said "one" keeping in mind previous > discussions and the definition of "one" meaning based on the SRv6 data > plane in compliance to [RFC8402], [RFC8754] and [RFC8986]. > > > > Interestingly enough the draft in question defines not behaviours but > flavors as new variants of the already defined behaviors in Standards Track > RFCs. Namely it defines: > > > > 4.1. NEXT-C-SID Flavor > > 4.2. REPLACE-C-SID Flavor > > > > The newly defined behaviour End.XPS is optional. > > So if there is anything to ask here is to check if WG is ok with two > flavors or not. I do not recall that question has ever been asked formally > during the WG adoption call. > > > > With that let's note that optimal compressed SID size may be different > network to network. One size does not fit all. Draft says: > > 6.1. C-SID Length > > The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengths. A > * C-SID length of 16-bit is recommended.* > > The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID lengths. > * A C-SID length of 32-bit is recommended.* > > > > While I personally think 8-bit should be an option, if we choose a single > flavor we will introduce suboptimality for no good reason. Hardware > capable of supporting any flavor clearly can do LPM on locator. Also > hardware capable of supporting one flavor can support few other flavors as > this is pretty much just an offset game. > > > > Kind regards, > > Robert > > > > > > > > On Tue, Oct 5, 2021 at 9:43 PM Ron Bonica 40juniper.net@dmarc.ietf.org> wrote: > > Pablo, > > > > Ae you sure? Please look at the question as Joel asked it ( > https://mailarchive.ietf.org/arch/msg/spring/nS2gnQ_jxvpbmcxs_d3JAbUCT1I/ > ). > > > > > Ron > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > --000000000000b93d7405cf48287b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Dear Fr= ancois et al.,
    I appreciate your consideration of the= scenarios when both compression methods were used. I'll be looking for= the next update of the draft. I hope the authors will add a section with a= clear description of scenarios when the two compression methods can be use= d.
    But in the meantime, I am still strongly concerned= that adoption of the draft in its current version would violate the decisi= on of the WG (as I understand the result of the earlier poll) to adopt a si= ngle compression method (not a single document that defines two (at the min= imum) incompatible methods to compress SRv6 SIDs. I've read multiple no= tes that asserted that in the testing, the ability to mix REPLACE-C-SID and= NEXT-C-SID was verified and confirmed. It seems to me that sharing more in= formation about these tests could address my concern.

    But at this time, I strongly object to SPRING W= G's adoption of the current draft version as it would violate the earli= er decision reached by the WG.

    Regards,
    = Greg


    On Wed, Oct 13, 2021 at 3:56 AM Francois Clad= (fclad) <fclad@cisco.com> wro= te:

    Hi Greg,

    =C2=A0

    Your understanding is correct. The C-SID flavo= rs cannot be randomly mixed within the same C-SID container.

    =C2=A0

    We can clarify the details related to the combination of flavors in a C-= SID container in an upcoming version of the draft. For example, the last en= try of a C-SID container can carry a C-SID bound to any behavior, including one with another C-SID flavor.<= /u>

    =C2=A0

    Thanks,

    Francois

    =C2=A0

    From: Greg Mirsky <gregimirsky@gmail.com= >
    Date: Friday, 8 October 2021 at 22:21
    To: Francois Clad (fclad) <fclad@cisco.com>
    Cc: Robert Raszuk <robert@raszuk.net>, Ron Bonica <rbonica=3D40juniper.net@dmarc.iet= f.org>, James Guichard <james.n.guichard@futurewei.com>, SPRING W= G <spring@ietf.org<= /a>>, spring= -chairs@ietf.org <spring-chairs@ietf.org>
    Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv= 6-srh-compression/

    Hi Francois,
    you've said that different flavors of C-SID can be present not only in = the same SRH but also in the same C-SID container. The latter case got me t= hinking about several potential scenarios. Have to admit that I got stuck t= rying to understand how they can work. I hope you can help me out. Please consider the two cases described below.=

    Consider, for all cases, that we are handling a container with entries A, B= , C, and D, of some mix of NEXT-C-SID and REPLACE-C-SID flavors.

    Case 1:
    Suppose that A was the REPLACE-C-SID flavor C-SID and B is the NEXT-C-SID f= lavor. When A is processed, B will be copied into the IPv6 DA, retaining th= e prefix before A in the container. So far, so good. Then, when the packet = arrives at the node that processes B, it will say "NEXT". The remaining bits will be? I thought zer= o, but actually, it will presumably be two bits with the value two? So the = subsequent behavior will shift that two up? Even if the NEXT-C-SID flavor g= uesses that the two should be zero, it would skip C and D and pick up the entry from the next C-SID container in the SR= H. So it seems to either work wrong or work oddly?

    Case 2:
    Suppose that A was the NEXT-C-SID flavor. So it simply shifts B, C, D upwar= ds in the IPv6 DA. Suppose B is the REPLACE-C-SID flavor. It will interpret= the upper bits of the C C-SID as the arg for selecting the position in the= C-SID container to pull an entry from. It will also modify the C C-SID to perform the decrement it thinks i= t needs. It will then overwrite itself with the randomly chosen entry from = the container.

    It seems that neither scenario works. At least, I cannot figure out how it = can work. I would greatly appreciate it if you could have a look and clarif= y it for me.

    Regards,

    Greg

    =C2=A0

    On Fri, Oct 8, 2021 at 10:12 AM Francois Clad (fclad= ) <fclad@cisco.com<= /a>> wrote:

    Hi Greg,

    =C2=A0

    Thank you for the confirmation. I am glad that the m= atter of combining C-SIDs of different flavors is clear now.<= /p>

    =C2=A0

    Thanks,

    Francois

    =C2=A0

    From: Greg Mirsky <gregimirsky@gmail.com= >
    Date: Thursday, 7 October 2021 at 20:15
    To: Francois Clad (fclad) <fclad@cisco.com>
    Cc: Robert Raszuk <robert@raszuk.net>, Ron Bonica <rbonica=3D40juniper.net@dmarc.iet= f.org>, James Guichard <james.n.guichard@futurewei.com>, SPRING WG <spring@= ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>
    Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/

    Hi Francois,

    thank you for your detailed response and confirming = that C-SIDs of different flavors/behavior=C2=A0may be present in the same S= RH and even the same CSID container. I've noticed Ron's proposal as I was trying to formulate my question. His proposal highlighte= d what I am trying to understand - the relationship=C2=A0between NEXT-C-SID= and REPLACE-C-SID. I concur with Ron. The WG has adopted the compression analysis draft, and the=C2=A0updates and an additional anal= ysis Ron proposed will keep the discussion and decision-making process on t= he firm technical foundation.

    =C2=A0

    Regards,

    Greg

    =C2=A0

    On Thu, Oct 7, 2021 at 9:17 AM Francois Clad (fclad)= <fclad@cisco.com> wrote:

    Hi Greg,

    =C2=A0

    It is the role of the SR Source Node [Section 3.1 of= RFC 8754] to form the segment list in the SRH. It learns about the availab= le SIDs in the network with their associated behavior and flavors via control plane and/or management plane protocols, as descri= bed in Section 8 of RFC 8986, and selects the SIDs that are the most approp= riate for the segment list.

    =C2=A0

    Each SR Segment Endpoint Node [Section 3.3 of RFC 87= 54] simply executes the pseudocode of a locally instantiated SID when it re= ceives a packet matching that SID. The SR Segment Endpoint Node does not need to bother about the behavior/flavor of the sub= sequent SRv6 SIDs.

    =C2=A0

    This SRv6 logic applies to the C-SID flavors as well= . The choice of flavors for the SIDs in the SID List is up to the SR Source= Node.

    =C2=A0

    It is indeed possible to mix SIDs of different C-SID= flavors in the same SRH, and even in a single C-SID container.

    =C2=A0

    Thanks,

    Francois

    =C2=A0

    =C2=A0

    From: Greg Mirsky <gregimirsky@gmail.com= >
    Date: Wednesday, 6 October 2021 at 19:19
    To: Francois Clad (fclad) <fclad@cisco.com>
    Cc: Robert Raszuk <robert@raszuk.net>, Ron Bonica <rbonica=3D40juniper.net@dmarc.iet= f.org>, James Guichard <james.n.guichard@futurewei.com>, SPRING WG <spring@= ietf.org>, spring-chairs@i= etf.org <spring-chairs@ietf.org>
    Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compre= ssion/

    Hi Francois,

    thank you for the clarification. It is still not cle= ar how a node selects which flavor of CSID to use on the next compressed CS= ID that may happen also be in the next CSID container. As I understand it, a CSID container must use the same flavor of compressi= on but CSID containers with different compression flavors in the same SRH a= re allowed. Is that correct understanding?

    =C2=A0

    Regards,

    Greg

    =C2=A0

    On Wed, Oct 6, 2021 at 7:05 AM Francois Clad (fclad)= <fclad@cisco.com> wrote:

    Hi Greg,

    =C2=A0

    A node that supports this draft in its entirety can = instantiate SRv6 SIDs (e.g., End and End.X SIDs) with any of the three C-SID flavors. <= /u>

    =C2=A0

    In particular, a node can instantiate multiple SRv6 = SIDs bound to different C-SID flavors, possibly with different C-SID length= s. It can also instantiate SRv6 SIDs with behaviors and flavors defined in RFC 8986.

    =C2=A0

    As defined in Section 4.3 of RFC 8754 and again in S= ection 3 of RFC 8986, upon receiving an IPv6 packet with a destination addr= ess matching a FIB entry that represents one of these locally instantiated SIDs, the node processes the packet according to the = behavior (and flavor(s)) (i.e. pseudocode) of that SID.

    =C2=A0

    RFC 8754 and 8986 have already standardized these me= chanisms and the C-SID draft only leverages the same SRv6 dataplane to intr= oduce new endpoint flavors for compression.

    =C2=A0

    =C2=A0

    Francois

    =C2=A0

    Hi Robert,

    as I understand it, you believe everything that is w= ritten in the draft. I hope you can help me find an answer to one simple qu= estion:

    Can a node that supports this draft in its entirety,= i.e., supports all "flavors" defined in the document, process re= ceived SRv6 packet with the SRH encoded according to the specification?<= /u>

    So far, the proponents of the draft referred to &quo= t;planning" how flavors of SRv6 SID compressed. To the best of my unde= rstanding, that is is a clear demonstration of the incompatibility between flavors defined in the CSID draft. Regardless of=C2=A0what is writ= ten in it.

    =C2=A0

    Regards,

    Greg

    =C2=A0

    On Tue, Oct 5, 2021 at 1:24 PM Robert Raszuk <robert@raszuk.net&g= t; wrote:

    Ron & SPRING WG chairs,

    =C2=A0

    Through this discussion we first have seen a debate = if we need one or more data planes=C2=A0to compress SIDs in SRv6. WG clearl= y=C2=A0stated we need one.=C2=A0

    =C2=A0

    Following that we have observed a first terminology = shift to see if asking how many solutions should be supported will work any= better. To that many WG members clearly stated that they support one solution.=C2=A0

    =C2=A0

    Well please notice that the draft in question in its= introduction states:=C2=A0

    =C2=A0

    Abstract

    =C2=A0 =C2=A0This document defines a compressed SRv6 Segment List Encoding = in the
    =C2=A0 =C2=A0Segment Routing Header (SRH). =C2=A0This solution does = not require any SRH
    =C2=A0 =C2=A0data plane change nor any SRv6 control plane change. =C2=A0= This solution
    =C2=A0 =C2=A0leverages the SRv6 Network Programming model.

    =C2=A0

    So based on my understanding of English the entire d= raft talks about a single solution.=C2=A0

    =C2=A0

    Then suddenly a new question popped=C2=A0up: how man= y behaviours are acceptable.=C2=A0

    =C2=A0

    I bet number of folks including myself said "on= e" keeping in mind previous discussions and the definition of "on= e" meaning based on the SRv6 data plane in compliance to [RFC8402], [RFC8754] and [RFC8986].

    =C2=A0

    Interestingly enough the draft in question defines n= ot behaviours but flavors as new variants of the already defined behaviors = in Standards Track RFCs. Namely it defines:=C2=A0

    =C2=A0

    4.1.=C2=A0 NEXT-C-SID Flavor

    4.2.=C2=A0 REPLACE-C-SID Flavor

    =C2=A0

    The newly defined behaviour End.XPS is optional.=C2= =A0

    So if there is anything to ask here is to check if WG is ok with two flavor= s or not. I do not recall that question has=C2=A0ever been asked formally d= uring the WG adoption call.=C2=A0

    =C2=A0

    With that let's note that optimal compressed SID= size may be different network to network. One size does not fit all. Draft= says:=C2=A0

    6.1.=C2=A0 C-SID Length

    =C2=A0 =C2=A0The NEXT-C-SID flavor supports both 16- and 32-bit C-SID lengt= hs. =C2=A0A
    =C2=A0 =C2=A0C-SID length of 16-bit is recommended.

    =C2=A0 =C2=A0The REPLACE-C-SID flavor supports both 16- and 32-bit C-SID le= ngths.
    =C2=A0 =C2=A0A C-SID length of 32-bit is recommended.<= /p>

    =C2=A0

    While I personally think 8-bit should be an option, = if we choose a single flavor we will introduce suboptimality for no good re= ason. Hardware capable=C2=A0of supporting any flavor clearly can do LPM on locator. Also hardware capable of supporting one flavor can = support few other flavors as this is pretty much just an offset game.=C2=A0=

    =C2=A0

    Kind regards,

    Robert

    =C2=A0

    =C2=A0

    =C2=A0

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

    --000000000000b93d7405cf48287b-- From nobody Tue Oct 26 14:31:53 2021 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 CA8BB3A191A for ; Tue, 26 Oct 2021 14:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 2CI3g4HYw_VW for ; Tue, 26 Oct 2021 14:31:40 -0700 (PDT) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (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 2FCA73A15EB for ; Tue, 26 Oct 2021 14:30:18 -0700 (PDT) Received: by mail-ua1-x929.google.com with SMTP id v3so976004uam.10 for ; Tue, 26 Oct 2021 14:30:18 -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=o1IOLtQJkdynH72wjcy+HPJ4n22f0/JKd3HLxa6j34o=; b=JaE5kSVAPX37WWOTAShZjt9WqavcHZJyRYYehxvoKo0X+bS/31nVBOJzvcgVJcbs/O imsogUq15Lc3nC5kvsv/tSo+RrRfV3VZzrXhLQ9FTNrFqjraPrx9s4xP/8JyAn6cCGku 6w3h7o7VCytoV8YDUqsc+eFU3gIliN04Hz1H+VclOWmSZOifkqlQPqRRUUl5hMVzNyC9 TNbX6JlUn9ZluLkfpv9HI2JkZTKuWlKSzP7ZYIAvyZdxAxl5TkZa9pEam467dioQ+VJR l3E90GhEUNO6kbfzDhIvvfLfokmslYEpthKoYA+ZHO4nu6AvWMRwcW5OshZ9LjSBX5AK l+8A== 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=o1IOLtQJkdynH72wjcy+HPJ4n22f0/JKd3HLxa6j34o=; b=QhMkCdkA+Cc8veEXYB94IgrexyyDPB1e5AFC3mn4Bn9qOmW0OjfMNe28oEojY5xFez LRJsQdXWm852jkcbz5NeZtuQ06Dy2hp4TfN+cQrddd+bWtmxAWerdXSlBtFAcRiai1Zs 30zrIyYug68xCf5oM1+WLCp6kexgrdn40ECagscmEtK46nU8d/1oNdHiOMYi3d9GYi7c vW6pBoo8LBXim7i8oVLr5Y7MHQaQ10QAZwTL+X4i0Q0IDS1Vb5UTAizZIqvdGr5DPzLi 3E99pAZHdO34Ul99X7iVj2QSczn2rtvkKQ19eCGyzzEm1W/lRteuDw8Ivn4xynT3ChF6 xuEQ== X-Gm-Message-State: AOAM530qoPIBUtjTqgNAVoxXdtTP6t3oYrvLApLF8vudGj4QS5VDOT1b axTlnPPeS/gDeOZS5hfIlrOMat6ZFnreP/fCd8bDkQ== X-Google-Smtp-Source: ABdhPJyOAs3prs6dlsW/9wkJoJszFgM31WBrYmOwMW5WNPtsA8K9L1IJq0feEq+m3WalrPu/W5/z1jjiXOGixStqE+M= X-Received: by 2002:a05:6102:a30:: with SMTP id 16mr6434360vsb.1.1635283813469; Tue, 26 Oct 2021 14:30:13 -0700 (PDT) MIME-Version: 1.0 References: <1EB19A49-C12A-425D-ADB7-6E0B0F2CA66D@juniper.net> <39FF1295-2B0D-40B4-9BE9-CF26EB0C70AC@juniper.net> In-Reply-To: <39FF1295-2B0D-40B4-9BE9-CF26EB0C70AC@juniper.net> From: Robert Raszuk Date: Tue, 26 Oct 2021 23:30:10 +0200 Message-ID: To: John Scudder Cc: "draft-filsfilscheng-spring-srv6-srh-compression@ietf.org" , "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cf307005cf482e8c" Archived-At: Subject: Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 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, 26 Oct 2021 21:31:48 -0000 --000000000000cf307005cf482e8c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi John, Many thx for your detailed clarification. > CRH is not strictly based on SRv6 but is able to provide equivalent functionality. Now it is pretty obvious that all of those endless discussions are about C-SID vs CRH. It does sound like LDP vs CR-LDP many years ago :) However the topic is IMO orthogonal to draft-filsfilscheng-spring-srv6-srh-compression and the discussion should return on the correct tracks of either revisiting single vs many data plane solutions or question the results from design team analysis draft. Many thx, R. On Tue, Oct 26, 2021 at 11:21 PM John Scudder wrote: > Hi Robert, > > > On Oct 26, 2021, at 3:41 PM, Robert Raszuk wrote: > > > > Hello John, > > > > May I inquire what was not definitive as part of my answer ? > > I answered that in my response to your earlier message: > https://mailarchive.ietf.org/arch/msg/spring/dtKC6Um6USs0Jf7-LssRVsZzwTw/ > > > Please observe that below documents which are product of this WG go in > depth to evaluate compression against the requirement not to change SRv6 > data plane: > > > > > https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-r= equirement > > This one says (=C2=A74.1) > > Description: A solution to compress SRv6 SID Lists SHOULD be based on > the SRv6 architecture, control plane and data plane. The compression > solution MAY be based on a different data plane and control plane, > provided that it derives sufficient benefit. > > =E2=80=9CBased on=E2=80=9D is different from =E2=80=9Cdoes not change=E2= =80=9D. I don=E2=80=99t see any > documentation or claim of the latter. > > > > https://datatracker.ietf.org/doc/html/draft-srcompdt-spring-compression-a= nalysis > > Similarly (=C2=A73.1) > > A solution to compress SRv6 SID Lists SHOULD be based on the SRv6 > architecture, control plane and data plane. The compression solution > MAY be based on a different data plane and control plane, provided > that it derives sufficient benefit. > =E2=80=A6 > Conclusion: CSID is SRv6 based, requiring no updates to existing SRv6 > standards, VSID and UIDSR require updates. CRH is not strictly based > on SRv6 but is able to provide equivalent functionality. > > That does make the stronger claim =E2=80=9Cno updates to existing SRv6 st= andards=E2=80=9D. > It=E2=80=99s still the case that this is not the same as saying it doesn= =E2=80=99t change > the data plane, however, for the reasons I gave previously. > > > Would your enquiry be satisfied if the draft in question s/SRH data > plane/SRv6 data plane/ ? > > Using the more commonly-used term would be a good start. I think if the > only change were that, though, it would still be problematic, for example > the revised abstract would say =E2=80=9CThis solution does not require an= y SRv6 > data plane change=E2=80=9D. AFAICT, that still fails the test I proposed = in my > initial note. > > Regards, > > =E2=80=94John > > > > > > > > > Kind regards, > > > > Robert > > > > > > > > > > > > > > On Tue, Oct 26, 2021 at 7:55 PM John Scudder wrote: > > (For clarity: I=E2=80=99m not wearing any hats other than =E2=80=9CWG c= ontributor=E2=80=9D.) > > > > Hi All, > > > > Since there hasn=E2=80=99t been any definitive answer from the authors,= nor any > update to the draft to address the issue, and given that the disputed > statement seems to be an important premise for evaluation of the fitness = of > the draft for adoption (at least, the authors considered it fundamental > enough to put in the abstract): I=E2=80=99m opposed to adoption of the dr= aft until > this question has been settled, or at least meaningfully addressed. > > > > Regards, > > > > =E2=80=94John > > > > P.S.: I will also follow up to the main adoption thread to assist with > issue tracking. > > > > > On Oct 13, 2021, at 6:28 PM, John Scudder 40juniper.net@dmarc.ietf.org> wrote: > > > > > > > > > Hi Folks, > > > > > > I=E2=80=99m struggling with the claim repeated throughout the beginni= ng of > draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, =C2=A71, = =C2=A73) that > =E2=80=9Cthis solution does not require any SRH data plane change=E2=80= =9D. > > > > > > I=E2=80=99m not aware of a standardized formal definition of =E2=80= =9Cdata plane=E2=80=9D, it > seems to follow Justice Stewart=E2=80=99s maxim of =E2=80=9CI know it whe= n I see it=E2=80=9D. > However, here=E2=80=99s an attempt, cribbed from some Washington Universi= ty course > slides: a =E2=80=9Clocal, per-router function that determines how a datag= ram > arriving on a router input port is forwarded to a router output port=E2= =80=9D. > Seems reasonable. > > > > > > I also am not aware of a standardized formal definition of the term > =E2=80=9CSRH data plane=E2=80=9D, in fact this draft, its predecessors, s= ome associated > blog posts, and Clarence=E2=80=99s dissertation, are the only places a se= arch finds > the phrase (but it=E2=80=99s not formally defined in any of them). So I= =E2=80=99m just > going to assume it means the data plane, as applied to packets that inclu= de > an SRH. (I=E2=80=99m not sure why we should disregard packets that are en= coded > using NEXT-C-SID that omit the SRH, but let=E2=80=99s overlook that for n= ow.) > > > > > > If this solution does not require any SRH data plane change, > presumably it would be true that if I take a packet that includes an SRH > and place within it a series of SIDs encoded with (for example) the > REPLACE-C-SID flavor, then that packet would be able to successfully > traverse a network of routers that support plain vanilla RFC 8754. That i= s, > it would arrive at its first hop router which according to a local, > per-router function, would determine how to take the datagram arriving on > the router input port and forward it to (the correct) router output port. > Then that process would be repeated across the rest of the network. > > > > > > But that is patently incorrect: when it=E2=80=99s delivered to the fi= rst hop, > the plain vanilla RFC 8754 router will be unable to apply the REPLACE-C-S= ID > behavior, and forwarding to the next hop will fail. It seems that a > different local, per-router function is required (in fact, the local, > per-router function defined in the draft) in order for the forwarding to > succeed. By the definitions I=E2=80=99m using here, that is exactly a dat= a plane > change. > > > > > > What, precisely, is then being claimed? > > > > > > Thanks, > > > > > > =E2=80=94John > > > _______________________________________________ > > > spring mailing list > > > spring@ietf.org > > > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/spring_= _;!!NEt6yMaO-gk!S7rbnYg6aV2s3cyoTCL3wwWX4bpbFoawPLt6yLeYsms82sLl9tUpRU1X5c-= D9A$ > > > > --000000000000cf307005cf482e8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Hi John,

    Many thx for your detailed cla= rification.=C2=A0

    > CRH is not strictly based= =C2=A0on SRv6 but is able to provide equivalent functionality.

    Now it is pretty obvious that all of those endless discuss= ions are about C-SID vs CRH.=C2=A0

    It does sound= =C2=A0like=C2=A0LDP vs CR-LDP many years ago :)=C2=A0

    <= div>However the topic is IMO orthogonal to=C2=A0draft-filsfilscheng-spring-= srv6-srh-compression=C2=A0and the discussion should return on the correct t= racks of either revisiting single vs many data plane solutions or question = the results from design team analysis draft.=C2=A0

    Many thx,
    R.


    <= div dir=3D"ltr" class=3D"gmail_attr">On Tue, Oct 26, 2021 at 11:21 PM John = Scudder <jgs@juniper.net> wrot= e:
    Hi Robert,
    > On Oct 26, 2021, at 3:41 PM, Robert Raszuk <robert@raszuk.net> wrote:
    >
    > Hello John,
    >
    > May I inquire what was not definitive as part of my answer ?

    I answered that in my response to your earlier message: https://mailarchive.ietf.org/arch/msg/spring/d= tKC6Um6USs0Jf7-LssRVsZzwTw/

    > Please observe that below documents which are product of this WG go in= depth to evaluate compression against the requirement not to change SRv6 d= ata plane:
    >
    > https://data= tracker.ietf.org/doc/html/draft-srcompdt-spring-compression-requirement=

    This one says (=C2=A74.1)

    =C2=A0 =C2=A0Description: A solution to compress SRv6 SID Lists SHOULD be b= ased on
    =C2=A0 =C2=A0the SRv6 architecture, control plane and data plane.=C2=A0 The= compression
    =C2=A0 =C2=A0solution MAY be based on a different data plane and control pl= ane,
    =C2=A0 =C2=A0provided that it derives sufficient benefit.

    =E2=80=9CBased on=E2=80=9D is different from =E2=80=9Cdoes not change=E2=80= =9D. I don=E2=80=99t see any documentation or claim of the latter.

    > https://datatra= cker.ietf.org/doc/html/draft-srcompdt-spring-compression-analysis

    Similarly (=C2=A73.1)

    =C2=A0 =C2=A0A solution to compress SRv6 SID Lists SHOULD be based on the S= Rv6
    =C2=A0 =C2=A0architecture, control plane and data plane.=C2=A0 The compress= ion solution
    =C2=A0 =C2=A0MAY be based on a different data plane and control plane, prov= ided
    =C2=A0 =C2=A0that it derives sufficient benefit.
    =E2=80=A6
    =C2=A0 =C2=A0Conclusion: CSID is SRv6 based, requiring no updates to existi= ng SRv6
    =C2=A0 =C2=A0standards, VSID and UIDSR require updates.=C2=A0 CRH is not st= rictly based
    =C2=A0 =C2=A0on SRv6 but is able to provide equivalent functionality.

    That does make the stronger claim =E2=80=9Cno updates to existing SRv6 stan= dards=E2=80=9D. It=E2=80=99s still the case that this is not the same as sa= ying it doesn=E2=80=99t change the data plane, however, for the reasons I g= ave previously.

    > Would your enquiry be satisfied if the draft in question s/SRH data pl= ane/SRv6 data plane/ ?

    Using the more commonly-used term would be a good start. I think if the onl= y change were that, though, it would still be problematic, for example the = revised abstract would say =E2=80=9CThis solution does not require any SRv6= data plane change=E2=80=9D. AFAICT, that still fails the test I proposed i= n my initial note.

    Regards,

    =E2=80=94John

    >
    >
    >
    > Kind regards,
    >
    > Robert
    >
    >
    >
    >
    >
    >
    > On Tue, Oct 26, 2021 at 7:55 PM John Scudder <jgs@juniper.net> wrote:
    > (For clarity: I=E2=80=99m not wearing any hats other than =E2=80=9CWG = contributor=E2=80=9D.)
    >
    > Hi All,
    >
    > Since there hasn=E2=80=99t been any definitive answer from the authors= , nor any update to the draft to address the issue, and given that the disp= uted statement seems to be an important premise for evaluation of the fitne= ss of the draft for adoption (at least, the authors considered it fundament= al enough to put in the abstract): I=E2=80=99m opposed to adoption of the d= raft until this question has been settled, or at least meaningfully address= ed.
    >
    > Regards,
    >
    > =E2=80=94John
    >
    > P.S.: I will also follow up to the main adoption thread to assist with= issue tracking.
    >
    > > On Oct 13, 2021, at 6:28 PM, John Scudder <jgs=3D40juniper.net@dmarc.ie= tf.org> wrote:
    > >
    > >
    > > Hi Folks,
    > >
    > > I=E2=80=99m struggling with the claim repeated throughout the beg= inning of draft-filsfilscheng-spring-srv6-srh-compression-02 (Abstract, =C2= =A71, =C2=A73) that =E2=80=9Cthis solution does not require any SRH data pl= ane change=E2=80=9D.
    > >
    > > I=E2=80=99m not aware of a standardized formal definition of =E2= =80=9Cdata plane=E2=80=9D, it seems to follow Justice Stewart=E2=80=99s max= im of =E2=80=9CI know it when I see it=E2=80=9D. However, here=E2=80=99s an= attempt, cribbed from some Washington University course slides: a =E2=80= =9Clocal, per-router function that determines how a datagram arriving on a = router input port is forwarded to a router output port=E2=80=9D. Seems reas= onable.
    > >
    > > I also am not aware of a standardized formal definition of the te= rm =E2=80=9CSRH data plane=E2=80=9D, in fact this draft, its predecessors, = some associated blog posts, and Clarence=E2=80=99s dissertation, are the on= ly places a search finds the phrase (but it=E2=80=99s not formally defined = in any of them). So I=E2=80=99m just going to assume it means the data plan= e, as applied to packets that include an SRH. (I=E2=80=99m not sure why we = should disregard packets that are encoded using NEXT-C-SID that omit the SR= H, but let=E2=80=99s overlook that for now.)
    > >
    > > If this solution does not require any SRH data plane change, pres= umably it would be true that if I take a packet that includes an SRH and pl= ace within it a series of SIDs encoded with (for example) the REPLACE-C-SID= flavor, then that packet would be able to successfully traverse a network = of routers that support plain vanilla RFC 8754. That is, it would arrive at= its first hop router which according to a local, per-router function, woul= d determine how to take the datagram arriving on the router input port and = forward it to (the correct) router output port. Then that process would be = repeated across the rest of the network.
    > >
    > > But that is patently incorrect: when it=E2=80=99s delivered to th= e first hop, the plain vanilla RFC 8754 router will be unable to apply the = REPLACE-C-SID behavior, and forwarding to the next hop will fail. It seems = that a different local, per-router function is required (in fact, the local= , per-router function defined in the draft) in order for the forwarding to = succeed. By the definitions I=E2=80=99m using here, that is exactly a data = plane change.
    > >
    > > What, precisely, is then being claimed?
    > >
    > > Thanks,
    > >
    > > =E2=80=94John
    > > _______________________________________________
    > > spring mailing list
    > > spring@ietf.= org
    > > https://urlde= fense.com/v3/__https://www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk= !S7rbnYg6aV2s3cyoTCL3wwWX4bpbFoawPLt6yLeYsms82sLl9tUpRU1X5c-D9A$
    >

    --000000000000cf307005cf482e8c-- From nobody Tue Oct 26 14:52:26 2021 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 1AC103A18BD; Tue, 26 Oct 2021 14:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=lJoO8LmH; dkim=pass (1024-bit key) header.d=juniper.net header.b=KqRrxP+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 LNzGDAHTpCeZ; Tue, 26 Oct 2021 14:52:20 -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 D1E393A11B6; Tue, 26 Oct 2021 14:52:20 -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 SMTP id 19QEINpf026835; Tue, 26 Oct 2021 14:52:19 -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=NdSq6CqAt6hGADW90b4dxgPPKdXBihRpscRjcl/LMVY=; b=lJoO8LmHoAwzjJRKvrTGnoV2e7FzDEzW/M3g1DEqh33tg6P81Dd8Bl7wTVduKTZAIyCE 3m1KhQrusOkyCx58vi/GC5yxAjnOwaN/NVOIOLYi6T4Svb83nwA53Nj78EUbuwilV9nz 3kIZfouPNYSAA1F3nK+ORRiCrofCmiwCoUwuarD3bJzwWsPOxtpzNWfjhd3ULSWFAVVR 1piMHfYqEIfMX0lBO8LsLNIf3OJpkh5NeQO18UCf2aJffVXxrLs3Ls+5ClEdPDxwQWrG 0Cj9KrlyD716MqB6liN2467hw8oBWjHbQ2lX7na7jOnaRqAtOennf+Rr+ZTwZeKdhq0B jA== Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2040.outbound.protection.outlook.com [104.47.66.40]) by mx0a-00273201.pphosted.com with ESMTP id 3bxkau0x54-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 26 Oct 2021 14:52:19 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UE1A4GnNQ0GC+0HbT+wCDYGIixw00waTilDEWDMMAivPETzYBoSwoKxG0JTDqUJ6xeI3vivFPmEpFNoGkeNYBSL65d2C0+7d2fqidQrNShzlUuJLcJDgx2+930gdpjUBHiCzTtLjXkC0BJmkh7GHkg8GL9fmexD9UGgQ8RFNpk3bbKmDruAA63XrwSO6j9HsMfW9J8vfeT5z2TRMsW3nzbNtiuDe43SkYAjl85zTd+97Bb6+z6NVboBTsL1va6I652t8glkGvBgQABs1RSKf1FSXm/jlGVhZ+tm3sb2T+ut457zDCnwsStlKxt6jOM2wcZAANeZ/rY/ULbJFyHdo5g== 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=NdSq6CqAt6hGADW90b4dxgPPKdXBihRpscRjcl/LMVY=; b=DCTNPbUHdAGv/GTmAWBANRRGBctNIH6woJ47MUeQObDlSoliCm7Cf6LfhPg6lOQYhK7xvmr8SV9m7sYKY6+v6lZiheBrnsmdwwQrT5EmZH8zh0ka66gF3W7lBRKOqQm0YZUsR+wBCPz/55kFleRwdmT6tJUFfjkEP3e6HPeKq4Cw0k7nAwmROVGPu9YJJo4Nri4rt6643iKd+MnNWeMa6DUznEfHwMxTeu6cenYYEonla8b6PtQLoJ/WrJIdu6+2i6ZG7jNvACrdayNX18+hOgwcoPAytkirCUQS7mP02mm5yvMWRDoQuAhHXUCH36BoA18svYZ4bQLiwiDmJFyMbQ== 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=NdSq6CqAt6hGADW90b4dxgPPKdXBihRpscRjcl/LMVY=; b=KqRrxP+3h+GP+M5n153ATkBdqkbxsbpEZIp5ketNb7WBkpD3L6djr6G7FB0bX0A3a4Nda27lCcQ+F8U0alXpM5p0Ma5z6OqSLdGevCi3kg/nHWVo8W1XuAYYVznlYkHvqWLsmguDqKqpzT5zO29G+iWp4zmqAH/pB2FWOH9DB58= Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by MN2PR05MB6159.namprd05.prod.outlook.com (2603:10b6:208:c7::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4649.12; Tue, 26 Oct 2021 21:52:13 +0000 Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::10b9:2bb9:11f2:6b4a]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::10b9:2bb9:11f2:6b4a%3]) with mapi id 15.20.4649.014; Tue, 26 Oct 2021 21:52:13 +0000 From: John Scudder To: Robert Raszuk CC: "draft-filsfilscheng-spring-srv6-srh-compression@ietf.org" , "spring@ietf.org" Thread-Topic: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 Thread-Index: AQHXwIGtAQ5iI0HLYkm+pjy3rdbrTKvlpE+AgAAdjACAABwZAIAAAlcAgAAGKAA= Date: Tue, 26 Oct 2021 21:52:13 +0000 Message-ID: References: <1EB19A49-C12A-425D-ADB7-6E0B0F2CA66D@juniper.net> <39FF1295-2B0D-40B4-9BE9-CF26EB0C70AC@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.3654.120.0.1.13) authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=juniper.net; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 844146c7-bc0c-4eec-8638-08d998cade78 x-ms-traffictypediagnostic: MN2PR05MB6159: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RMEF10JnPDNeAAWuYVIqYwD1f4Rli7SJWi/ahfdn4MW7Q8RI2lvPISuPG/5dmWh7L/re8uaoAXGJ5zhVdaL2jMybRR5fHAQAJxhkiqUzuykSsZImsDRGFrelywA28p5D56RyBcMysIHRDdLGFoJk9cE2YWbxepQYk+L53legxQNCbUkAw6KccDeTgLSZ4VSMG9zg3uUS+lzE9s07yKg/RDbb/VoGBjfexGaJKr6xsNZqFhjRzowyPlSKijcsLBwF78DW+BbFTKlIkN2/B8TXQaUEX+oe+3v60Ud9bGLc+GyEEMwCpFOxuqM6GsK2XNujbTWa8RGAMSO0SQcTr+qdDodne85a/wh2ED/n+3OagOfWc4cnHipFDzXp5Yx1+WPjR779BTap1INOid1O4tStxdkNf99RHjwFs01uQ77rstW0rEWx9j5Z5jonEZMXsZnbKmEfnadhstqKK5LFlUK8hB4p86n73oN8iW7/bwMOfKLz3zG3veIbFM54fve9JhqaCFcUtk24YLUZXyUU5tRyZrIq2hP+NAhwq41IoRj4TM8BhB8E5FVQ+0QpNea9TEKShxLKNNwptQSg6d2IEUHiwGB8N8gCL5+/WYMvP0F8fwe8WhT+Gf62YMk8EDPUPRqQcY/RkNpSgJHDqZo9S42PTF5aCSyqljWlTE/4j1mk70c4uPJNCuJKobL9ZKy1ibfsY0N8j5ZeJfw6M5CvVFz/2EHXWe/L7dG2Pk0gOWMzwomEYtcvwCz2GHan5cIzho8Dd3wjSiyTWp2IhYB+dk8fTxPXuIXMRAupAXW2FFixM/B7BLMC7h4ZE1dgzPph/WqSxRTgtezXVWgZ99eGuBOZV4D+aLS7p5cT2QS2c6Lt5x4= 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:(4636009)(366004)(71200400001)(33656002)(66946007)(66556008)(66476007)(966005)(38070700005)(64756008)(8676002)(122000001)(38100700002)(2906002)(66446008)(76116006)(316002)(54906003)(508600001)(26005)(186003)(4326008)(6916009)(36756003)(66574015)(5660300002)(91956017)(8936002)(6512007)(53546011)(6506007)(86362001)(6486002)(83380400001)(2616005)(45980500001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?UlRDMFJQNElaQTR5QktBSGNPTjV0dmJDVnBMaXNzRWIzbDJ0RVdhLzBJL3Qy?= =?utf-8?B?T2tJS0lrYzYrOU9tZzdXQnRuaXlGb041d3V2RjJZU0RLa3NObnNZME5LNUJT?= =?utf-8?B?TXhRNTRhcGdES0VRMExpeGVSaEx6QjU0bnI3MjFmRjIxTnVhN1ppNE95ZEtC?= =?utf-8?B?ZmZnUExkK1QwTkYyY0dmRXhrcHV1SlVVYmE4R1lpT2Z2MTFaeXljaEtPN3pF?= =?utf-8?B?RnhkbnVTM2dGNTZ4YU1ubDdKWmIrSUZuL3JESWFpWXZIMklFeVJIWlF4eXBV?= =?utf-8?B?MDVPRUcxcnlpVUNvaE85eTIwUFJoNWhmbzJzZmpKTjJvSHU1akNoemlUWjh3?= =?utf-8?B?WFY3VkxpWStZU05obEVHenY0Tlk0aEpjTWxjcnRCc1BQS2YvbnE0R3pqY3Za?= =?utf-8?B?YjFGb3ZSVmZWN09Tc1NPSVd3ZmQvbERoL0RXOXlGaWVKOTFkOFNEMVZqbWov?= =?utf-8?B?a1hMMjk4K2s3RGRxNVl2OWVaVU90QzJRSGRwemplMDdtaEt3WjVnRENhWnhB?= =?utf-8?B?VW5peHNzN2VrMTlMQ0gwd3FVTUI0SERqUHVZcWdVTWZQZHR1dlZFbWR6Q0po?= =?utf-8?B?Yk1LK1Zka2JDK1dhQWU1R01aRCs0cEMvcXFHWUt0SXhlWWhtSTlEWURjRVkv?= =?utf-8?B?bklVNEJqZTNMOVBSZERrUmpDMFphUWZQUklRNFVvVzFJUHh3UTJyMkxhYmp3?= =?utf-8?B?SjdicVFUL3JzdVRmOHJjdTFKR2JON1NNT295ajhxbEUvMTZFQVU2NG05enND?= =?utf-8?B?V2NKZXl0cHpkZGp0MkZyTk1ONk1LSWgxUUpGS1FnUGpyOTJyck92UWxONEJa?= =?utf-8?B?RXlENUtLayszbmlubHMxMy9OZy9vZUdWbWFMTjRMY0x6Y01BdkRUTzl6ajdI?= =?utf-8?B?UG1EMFdTVkd0Qkd1a0pDS0l4YmRqMUVuWHlka0g4WE1PQ2wyMzFyY1B4bStP?= =?utf-8?B?b2xKUm9kUmh4Vy9qSGxMeStMekxtcEtJUzFGVStpbklTdjlEU3ZwQ3ZqdENL?= =?utf-8?B?eCs5bVEweHRHSFhSdjlVTlFsQ2M1K3l1c0M4WEZSN2NGMTRWRVdDTG9odzcy?= =?utf-8?B?V01VYThnT2RrWkRsTEcrdWZFMHZTdU02TDdyYlJMUEJoemNaUjhTYmRrNWp6?= =?utf-8?B?SElPcG9qNytjYUVCRmptbnRYL1RYck9CdGUrTG9VRlc4OVRNanpTaVE1YnZ3?= =?utf-8?B?VWhTa3FyajhobE5qUGlpaEU3UnlSVG5PY29vTk1FZVZiZy8wQWhRZHVyUDlZ?= =?utf-8?B?OWIrM2VkMVVTT1RXVmJWZ0tZUmpjNVBpRnlqRFFiR2xjcUtEMmhlVjY5ejA2?= =?utf-8?B?cVByUnBJOTRWbTdnak5tUFJlTUN0TFp4MnBLWEluelFBcitqQm1HdUJyRmtj?= =?utf-8?B?QU1kZUw5Wjk2QWYxNkRweithQjZYWmZkVFhyT2MwUFQ0ZnBJUy9vR2ZRWUFo?= =?utf-8?B?OWRYNnIrbzg5Ukw0eW5iazlheGFEdW55aHZjYjI2dWZJQVo1YkNMMHIrcEpz?= =?utf-8?B?UjBSd2Q2T3NySnMwOVQwV1l5Zm9VSzJkdksrbjY2QUs1QVRuaHorVjZmTzNQ?= =?utf-8?B?VCtIVHFOWG1uVTJaUFZvSWZFOThDQStFclNhcGk1b21GRXRNdTdyVnRhZWFK?= =?utf-8?B?Q2Izcmlsd3dSZDg3NVptMkt6bVZqa3dMRGNueWpwNGdYSEpXOUhtSjJDaDFF?= =?utf-8?B?ZENhMmFLZkVQRkRINVhmUmxtQjRmZ2xFMEsvbStxeXBWU2syaGcwK042ZUdV?= =?utf-8?B?WjdiODJFY2ltU2VEK21qa2h5WnpZMEU3cHdGa0piSHlWN1dsdC9CclM2dSs5?= =?utf-8?B?UUhzQ3pPeHkyOHRVR0M4WnZYdjlCaWJ0b2xsejJxNUhYWjc4QldONWhhL3Bv?= =?utf-8?B?dTZVckRubGxKK2I0L3AxRHdmNTJvcnp4S2xDVUNWVXFXZW5Zb3Q3OVpnS0hD?= =?utf-8?B?OWFGdERra28vYTRIaDIwMHpqa3BYMFZUdk53TWdnanF5Wmpsc3p0U1ZiNkEx?= =?utf-8?B?R0EwU3NqL013cUptb0JJSWovZU9NMWMzS3orV0c0WkR6SDhnVlIyWU42UGt2?= =?utf-8?B?L3gyQ0NpWE1QYkhLcXJOQW9sMEE0djk2ZjlXS3VTQXJqRS8xK0lyNjlQYk02?= =?utf-8?Q?WGCCIwESqXveLaIM8iddF4R5P?= Content-Type: text/plain; charset="utf-8" Content-ID: <758583E48194B141828BDFAAF68889BE@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: 844146c7-bc0c-4eec-8638-08d998cade78 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2021 21:52:13.1742 (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: JoRk249+ACVtjBvl68Mr/hU8W9+JN/J5ZonpNTC+tAvjPhdFfE/6FVXhjtvV8JFP X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6159 X-Proofpoint-ORIG-GUID: 03wm6soN3Hk_7ZbeZSAyos1z2TVsN0tl X-Proofpoint-GUID: 03wm6soN3Hk_7ZbeZSAyos1z2TVsN0tl X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.0.607.475 definitions=2021-10-26_06,2021-10-26_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 suspectscore=0 clxscore=1015 lowpriorityscore=0 mlxlogscore=999 malwarescore=0 impostorscore=0 mlxscore=0 phishscore=0 spamscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2110260118 Archived-At: Subject: Re: [spring] "This solution does not require any SRH data plane change" in draft-filsfilscheng-spring-srv6-srh-compression-02 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, 26 Oct 2021 21:52:25 -0000 SGkgUm9iZXJ0LA0KDQo+IE9uIE9jdCAyNiwgMjAyMSwgYXQgNTozMCBQTSwgUm9iZXJ0IFJhc3p1 ayA8cm9iZXJ0QHJhc3p1ay5uZXQ+IHdyb3RlOg0KPiANCj4gSGkgSm9obiwNCj4gDQo+IE1hbnkg dGh4IGZvciB5b3VyIGRldGFpbGVkIGNsYXJpZmljYXRpb24uIA0KDQpZb3UgYXJlIHdlbGNvbWUu DQoNCj4gPiBDUkggaXMgbm90IHN0cmljdGx5IGJhc2VkIG9uIFNSdjYgYnV0IGlzIGFibGUgdG8g cHJvdmlkZSBlcXVpdmFsZW50IGZ1bmN0aW9uYWxpdHkuDQo+IA0KPiBOb3cgaXQgaXMgcHJldHR5 IG9idmlvdXMgdGhhdCBhbGwgb2YgdGhvc2UgZW5kbGVzcyBkaXNjdXNzaW9ucyBhcmUgYWJvdXQg Qy1TSUQgdnMgQ1JILiANCg0KSSB3b3VsZG7igJl0IHNheSB0aGUgdG9waWMgSSByYWlzZWQgd2Fz IOKAnGVuZGxlc3PigJ0gWypdLCBhbmQgaXQgaGFzIG5vdGhpbmcgd2hhdHNvZXZlciB0byBkbyB3 aXRoIENSSCwgaXQgcmVsYXRlcyBzb2xlbHkgdG8gdGhlIGRvY3VtZW50IGluIHF1ZXN0aW9uLiBJ ZiB5b3UgaGF2ZSBzb21lIHNwZWNpZmljIHJlYXNvbiB0byBzYXkgb3RoZXJ3aXNlLCB0aGF0IGlu dm9sdmVzIHRoaW5ncyBJIHdyb3RlIFsqKl0sIHBsZWFzZSBkbyBzaGFyZS4NCg0KPiBJdCBkb2Vz IHNvdW5kIGxpa2UgTERQIHZzIENSLUxEUCBtYW55IHllYXJzIGFnbyA6KSANCj4gDQo+IEhvd2V2 ZXIgdGhlIHRvcGljIGlzIElNTyBvcnRob2dvbmFsIHRvIGRyYWZ0LWZpbHNmaWxzY2hlbmctc3By aW5nLXNydjYtc3JoLWNvbXByZXNzaW9uIGFuZCB0aGUgZGlzY3Vzc2lvbiBzaG91bGQgcmV0dXJu IG9uIHRoZSBjb3JyZWN0IHRyYWNrcyBvZiBlaXRoZXIgcmV2aXNpdGluZyBzaW5nbGUgdnMgbWFu eSBkYXRhIHBsYW5lIHNvbHV0aW9ucyBvciBxdWVzdGlvbiB0aGUgcmVzdWx0cyBmcm9tIGRlc2ln biB0ZWFtIGFuYWx5c2lzIGRyYWZ0LiANCg0KSeKAmW0gbm90IG1ha2luZyBhbnkgYXR0ZW1wdCB0 byBkZXJhaWwgc3VjaCBkaXNjdXNzaW9uczsgaG93ZXZlciwgaXTigJlzIHN0aWxsIHRoZSBjYXNl IHRoYXQgdGhlIHRvcGljIEkgcmFpc2VkIGhhc27igJl0IGJlZW4gY2xvc2VkIGFuZCBJIHdvdWxk IGVxdWFsbHkgYXBwcmVjaWF0ZSBpdCBpZiB5b3XigJlkIHJlZnJhaW4gZnJvbSB0cnlpbmcgdG8g ZGVyYWlsIHRoaXMgbGluZSBvZiBkaXNjdXNzaW9uIHdpdGggZGlzdHJhY3Rpb25zIGxpa2UgYnJp bmdpbmcgdXAgQ1JILg0KDQpSZWdhcmRzLA0KDQrigJRKb2huDQoNClsqXSBJIGNvdW50IGZpZnRl ZW4gbWVzc2FnZXMgbm90IGluY2x1ZGluZyB0aGlzIG9uZS4NClsqKl0gT2J2aW91c2x5LCBiZXlv bmQgdGhlIGZhY3QgdGhhdCBJIHF1b3RlZCBhIHBhcmFncmFwaCBmcm9tIGEgZG9jdW1lbnQgeW91 IGNpdGVkLCB0aGF0IGluY2x1ZGVkIHRoZSBsZXR0ZXJzIEMsIFIsIGFuZCBILg0KDQo+IA0KPiBN YW55IHRoeCwNCj4gUi4NCj4gDQo+IA0KPiBPbiBUdWUsIE9jdCAyNiwgMjAyMSBhdCAxMToyMSBQ TSBKb2huIFNjdWRkZXIgPGpnc0BqdW5pcGVyLm5ldD4gd3JvdGU6DQo+IEhpIFJvYmVydCwNCj4g DQo+ID4gT24gT2N0IDI2LCAyMDIxLCBhdCAzOjQxIFBNLCBSb2JlcnQgUmFzenVrIDxyb2JlcnRA cmFzenVrLm5ldD4gd3JvdGU6DQo+ID4gDQo+ID4gSGVsbG8gSm9obiwNCj4gPiANCj4gPiBNYXkg SSBpbnF1aXJlIHdoYXQgd2FzIG5vdCBkZWZpbml0aXZlIGFzIHBhcnQgb2YgbXkgYW5zd2VyID8g DQo+IA0KPiBJIGFuc3dlcmVkIHRoYXQgaW4gbXkgcmVzcG9uc2UgdG8geW91ciBlYXJsaWVyIG1l c3NhZ2U6IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5nL2R0S0M2 VW02VVNzMEpmNy1Mc3NSVnNaendUdy8NCj4gDQo+ID4gUGxlYXNlIG9ic2VydmUgdGhhdCBiZWxv dyBkb2N1bWVudHMgd2hpY2ggYXJlIHByb2R1Y3Qgb2YgdGhpcyBXRyBnbyBpbiBkZXB0aCB0byBl dmFsdWF0ZSBjb21wcmVzc2lvbiBhZ2FpbnN0IHRoZSByZXF1aXJlbWVudCBub3QgdG8gY2hhbmdl IFNSdjYgZGF0YSBwbGFuZTogDQo+ID4gDQo+ID4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1zcmNvbXBkdC1zcHJpbmctY29tcHJlc3Npb24tcmVxdWlyZW1lbnQN Cj4gDQo+IFRoaXMgb25lIHNheXMgKMKnNC4xKQ0KPiANCj4gICAgRGVzY3JpcHRpb246IEEgc29s dXRpb24gdG8gY29tcHJlc3MgU1J2NiBTSUQgTGlzdHMgU0hPVUxEIGJlIGJhc2VkIG9uDQo+ICAg IHRoZSBTUnY2IGFyY2hpdGVjdHVyZSwgY29udHJvbCBwbGFuZSBhbmQgZGF0YSBwbGFuZS4gIFRo ZSBjb21wcmVzc2lvbg0KPiAgICBzb2x1dGlvbiBNQVkgYmUgYmFzZWQgb24gYSBkaWZmZXJlbnQg ZGF0YSBwbGFuZSBhbmQgY29udHJvbCBwbGFuZSwNCj4gICAgcHJvdmlkZWQgdGhhdCBpdCBkZXJp dmVzIHN1ZmZpY2llbnQgYmVuZWZpdC4NCj4gDQo+IOKAnEJhc2VkIG9u4oCdIGlzIGRpZmZlcmVu dCBmcm9tIOKAnGRvZXMgbm90IGNoYW5nZeKAnS4gSSBkb27igJl0IHNlZSBhbnkgZG9jdW1lbnRh dGlvbiBvciBjbGFpbSBvZiB0aGUgbGF0dGVyLg0KPiANCj4gPiBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXNyY29tcGR0LXNwcmluZy1jb21wcmVzc2lvbi1hbmFs eXNpcw0KPiANCj4gU2ltaWxhcmx5ICjCpzMuMSkNCj4gDQo+ICAgIEEgc29sdXRpb24gdG8gY29t cHJlc3MgU1J2NiBTSUQgTGlzdHMgU0hPVUxEIGJlIGJhc2VkIG9uIHRoZSBTUnY2DQo+ICAgIGFy Y2hpdGVjdHVyZSwgY29udHJvbCBwbGFuZSBhbmQgZGF0YSBwbGFuZS4gIFRoZSBjb21wcmVzc2lv biBzb2x1dGlvbg0KPiAgICBNQVkgYmUgYmFzZWQgb24gYSBkaWZmZXJlbnQgZGF0YSBwbGFuZSBh bmQgY29udHJvbCBwbGFuZSwgcHJvdmlkZWQNCj4gICAgdGhhdCBpdCBkZXJpdmVzIHN1ZmZpY2ll bnQgYmVuZWZpdC4NCj4g4oCmDQo+ICAgIENvbmNsdXNpb246IENTSUQgaXMgU1J2NiBiYXNlZCwg cmVxdWlyaW5nIG5vIHVwZGF0ZXMgdG8gZXhpc3RpbmcgU1J2Ng0KPiAgICBzdGFuZGFyZHMsIFZT SUQgYW5kIFVJRFNSIHJlcXVpcmUgdXBkYXRlcy4gIENSSCBpcyBub3Qgc3RyaWN0bHkgYmFzZWQN Cj4gICAgb24gU1J2NiBidXQgaXMgYWJsZSB0byBwcm92aWRlIGVxdWl2YWxlbnQgZnVuY3Rpb25h bGl0eS4NCj4gDQo+IFRoYXQgZG9lcyBtYWtlIHRoZSBzdHJvbmdlciBjbGFpbSDigJxubyB1cGRh dGVzIHRvIGV4aXN0aW5nIFNSdjYgc3RhbmRhcmRz4oCdLiBJdOKAmXMgc3RpbGwgdGhlIGNhc2Ug dGhhdCB0aGlzIGlzIG5vdCB0aGUgc2FtZSBhcyBzYXlpbmcgaXQgZG9lc27igJl0IGNoYW5nZSB0 aGUgZGF0YSBwbGFuZSwgaG93ZXZlciwgZm9yIHRoZSByZWFzb25zIEkgZ2F2ZSBwcmV2aW91c2x5 Lg0KPiANCj4gPiBXb3VsZCB5b3VyIGVucXVpcnkgYmUgc2F0aXNmaWVkIGlmIHRoZSBkcmFmdCBp biBxdWVzdGlvbiBzL1NSSCBkYXRhIHBsYW5lL1NSdjYgZGF0YSBwbGFuZS8gPyANCj4gDQo+IFVz aW5nIHRoZSBtb3JlIGNvbW1vbmx5LXVzZWQgdGVybSB3b3VsZCBiZSBhIGdvb2Qgc3RhcnQuIEkg dGhpbmsgaWYgdGhlIG9ubHkgY2hhbmdlIHdlcmUgdGhhdCwgdGhvdWdoLCBpdCB3b3VsZCBzdGls bCBiZSBwcm9ibGVtYXRpYywgZm9yIGV4YW1wbGUgdGhlIHJldmlzZWQgYWJzdHJhY3Qgd291bGQg c2F5IOKAnFRoaXMgc29sdXRpb24gZG9lcyBub3QgcmVxdWlyZSBhbnkgU1J2NiBkYXRhIHBsYW5l IGNoYW5nZeKAnS4gQUZBSUNULCB0aGF0IHN0aWxsIGZhaWxzIHRoZSB0ZXN0IEkgcHJvcG9zZWQg aW4gbXkgaW5pdGlhbCBub3RlLg0KPiANCj4gUmVnYXJkcywNCj4gDQo+IOKAlEpvaG4NCj4gDQo+ ID4gDQo+ID4gDQo+ID4gDQo+ID4gS2luZCByZWdhcmRzLA0KPiA+IA0KPiA+IFJvYmVydA0KPiA+ IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IE9uIFR1ZSwgT2N0IDI2LCAyMDIx IGF0IDc6NTUgUE0gSm9obiBTY3VkZGVyIDxqZ3NAanVuaXBlci5uZXQ+IHdyb3RlOg0KPiA+IChG b3IgY2xhcml0eTogSeKAmW0gbm90IHdlYXJpbmcgYW55IGhhdHMgb3RoZXIgdGhhbiDigJxXRyBj b250cmlidXRvcuKAnS4pDQo+ID4gDQo+ID4gSGkgQWxsLA0KPiA+IA0KPiA+IFNpbmNlIHRoZXJl IGhhc27igJl0IGJlZW4gYW55IGRlZmluaXRpdmUgYW5zd2VyIGZyb20gdGhlIGF1dGhvcnMsIG5v ciBhbnkgdXBkYXRlIHRvIHRoZSBkcmFmdCB0byBhZGRyZXNzIHRoZSBpc3N1ZSwgYW5kIGdpdmVu IHRoYXQgdGhlIGRpc3B1dGVkIHN0YXRlbWVudCBzZWVtcyB0byBiZSBhbiBpbXBvcnRhbnQgcHJl bWlzZSBmb3IgZXZhbHVhdGlvbiBvZiB0aGUgZml0bmVzcyBvZiB0aGUgZHJhZnQgZm9yIGFkb3B0 aW9uIChhdCBsZWFzdCwgdGhlIGF1dGhvcnMgY29uc2lkZXJlZCBpdCBmdW5kYW1lbnRhbCBlbm91 Z2ggdG8gcHV0IGluIHRoZSBhYnN0cmFjdCk6IEnigJltIG9wcG9zZWQgdG8gYWRvcHRpb24gb2Yg dGhlIGRyYWZ0IHVudGlsIHRoaXMgcXVlc3Rpb24gaGFzIGJlZW4gc2V0dGxlZCwgb3IgYXQgbGVh c3QgbWVhbmluZ2Z1bGx5IGFkZHJlc3NlZC4NCj4gPiANCj4gPiBSZWdhcmRzLA0KPiA+IA0KPiA+ IOKAlEpvaG4NCj4gPiANCj4gPiBQLlMuOiBJIHdpbGwgYWxzbyBmb2xsb3cgdXAgdG8gdGhlIG1h aW4gYWRvcHRpb24gdGhyZWFkIHRvIGFzc2lzdCB3aXRoIGlzc3VlIHRyYWNraW5nLg0KPiA+IA0K PiA+ID4gT24gT2N0IDEzLCAyMDIxLCBhdCA2OjI4IFBNLCBKb2huIFNjdWRkZXIgPGpncz00MGp1 bmlwZXIubmV0QGRtYXJjLmlldGYub3JnPiB3cm90ZToNCj4gPiA+IA0KPiA+ID4gDQo+ID4gPiBI aSBGb2xrcywNCj4gPiA+IA0KPiA+ID4gSeKAmW0gc3RydWdnbGluZyB3aXRoIHRoZSBjbGFpbSBy ZXBlYXRlZCB0aHJvdWdob3V0IHRoZSBiZWdpbm5pbmcgb2YgZHJhZnQtZmlsc2ZpbHNjaGVuZy1z cHJpbmctc3J2Ni1zcmgtY29tcHJlc3Npb24tMDIgKEFic3RyYWN0LCDCpzEsIMKnMykgdGhhdCDi gJx0aGlzIHNvbHV0aW9uIGRvZXMgbm90IHJlcXVpcmUgYW55IFNSSCBkYXRhIHBsYW5lIGNoYW5n ZeKAnS4NCj4gPiA+IA0KPiA+ID4gSeKAmW0gbm90IGF3YXJlIG9mIGEgc3RhbmRhcmRpemVkIGZv cm1hbCBkZWZpbml0aW9uIG9mIOKAnGRhdGEgcGxhbmXigJ0sIGl0IHNlZW1zIHRvIGZvbGxvdyBK dXN0aWNlIFN0ZXdhcnTigJlzIG1heGltIG9mIOKAnEkga25vdyBpdCB3aGVuIEkgc2VlIGl04oCd LiBIb3dldmVyLCBoZXJl4oCZcyBhbiBhdHRlbXB0LCBjcmliYmVkIGZyb20gc29tZSBXYXNoaW5n dG9uIFVuaXZlcnNpdHkgY291cnNlIHNsaWRlczogYSDigJxsb2NhbCwgcGVyLXJvdXRlciBmdW5j dGlvbiB0aGF0IGRldGVybWluZXMgaG93IGEgZGF0YWdyYW0gYXJyaXZpbmcgb24gYSByb3V0ZXIg aW5wdXQgcG9ydCBpcyBmb3J3YXJkZWQgdG8gYSByb3V0ZXIgb3V0cHV0IHBvcnTigJ0uIFNlZW1z IHJlYXNvbmFibGUuDQo+ID4gPiANCj4gPiA+IEkgYWxzbyBhbSBub3QgYXdhcmUgb2YgYSBzdGFu ZGFyZGl6ZWQgZm9ybWFsIGRlZmluaXRpb24gb2YgdGhlIHRlcm0g4oCcU1JIIGRhdGEgcGxhbmXi gJ0sIGluIGZhY3QgdGhpcyBkcmFmdCwgaXRzIHByZWRlY2Vzc29ycywgc29tZSBhc3NvY2lhdGVk IGJsb2cgcG9zdHMsIGFuZCBDbGFyZW5jZeKAmXMgZGlzc2VydGF0aW9uLCBhcmUgdGhlIG9ubHkg cGxhY2VzIGEgc2VhcmNoIGZpbmRzIHRoZSBwaHJhc2UgKGJ1dCBpdOKAmXMgbm90IGZvcm1hbGx5 IGRlZmluZWQgaW4gYW55IG9mIHRoZW0pLiBTbyBJ4oCZbSBqdXN0IGdvaW5nIHRvIGFzc3VtZSBp dCBtZWFucyB0aGUgZGF0YSBwbGFuZSwgYXMgYXBwbGllZCB0byBwYWNrZXRzIHRoYXQgaW5jbHVk ZSBhbiBTUkguIChJ4oCZbSBub3Qgc3VyZSB3aHkgd2Ugc2hvdWxkIGRpc3JlZ2FyZCBwYWNrZXRz IHRoYXQgYXJlIGVuY29kZWQgdXNpbmcgTkVYVC1DLVNJRCB0aGF0IG9taXQgdGhlIFNSSCwgYnV0 IGxldOKAmXMgb3Zlcmxvb2sgdGhhdCBmb3Igbm93LikNCj4gPiA+IA0KPiA+ID4gSWYgdGhpcyBz b2x1dGlvbiBkb2VzIG5vdCByZXF1aXJlIGFueSBTUkggZGF0YSBwbGFuZSBjaGFuZ2UsIHByZXN1 bWFibHkgaXQgd291bGQgYmUgdHJ1ZSB0aGF0IGlmIEkgdGFrZSBhIHBhY2tldCB0aGF0IGluY2x1 ZGVzIGFuIFNSSCBhbmQgcGxhY2Ugd2l0aGluIGl0IGEgc2VyaWVzIG9mIFNJRHMgZW5jb2RlZCB3 aXRoIChmb3IgZXhhbXBsZSkgdGhlIFJFUExBQ0UtQy1TSUQgZmxhdm9yLCB0aGVuIHRoYXQgcGFj a2V0IHdvdWxkIGJlIGFibGUgdG8gc3VjY2Vzc2Z1bGx5IHRyYXZlcnNlIGEgbmV0d29yayBvZiBy b3V0ZXJzIHRoYXQgc3VwcG9ydCBwbGFpbiB2YW5pbGxhIFJGQyA4NzU0LiBUaGF0IGlzLCBpdCB3 b3VsZCBhcnJpdmUgYXQgaXRzIGZpcnN0IGhvcCByb3V0ZXIgd2hpY2ggYWNjb3JkaW5nIHRvIGEg bG9jYWwsIHBlci1yb3V0ZXIgZnVuY3Rpb24sIHdvdWxkIGRldGVybWluZSBob3cgdG8gdGFrZSB0 aGUgZGF0YWdyYW0gYXJyaXZpbmcgb24gdGhlIHJvdXRlciBpbnB1dCBwb3J0IGFuZCBmb3J3YXJk IGl0IHRvICh0aGUgY29ycmVjdCkgcm91dGVyIG91dHB1dCBwb3J0LiBUaGVuIHRoYXQgcHJvY2Vz cyB3b3VsZCBiZSByZXBlYXRlZCBhY3Jvc3MgdGhlIHJlc3Qgb2YgdGhlIG5ldHdvcmsuDQo+ID4g PiANCj4gPiA+IEJ1dCB0aGF0IGlzIHBhdGVudGx5IGluY29ycmVjdDogd2hlbiBpdOKAmXMgZGVs aXZlcmVkIHRvIHRoZSBmaXJzdCBob3AsIHRoZSBwbGFpbiB2YW5pbGxhIFJGQyA4NzU0IHJvdXRl ciB3aWxsIGJlIHVuYWJsZSB0byBhcHBseSB0aGUgUkVQTEFDRS1DLVNJRCBiZWhhdmlvciwgYW5k IGZvcndhcmRpbmcgdG8gdGhlIG5leHQgaG9wIHdpbGwgZmFpbC4gSXQgc2VlbXMgdGhhdCBhIGRp ZmZlcmVudCBsb2NhbCwgcGVyLXJvdXRlciBmdW5jdGlvbiBpcyByZXF1aXJlZCAoaW4gZmFjdCwg dGhlIGxvY2FsLCBwZXItcm91dGVyIGZ1bmN0aW9uIGRlZmluZWQgaW4gdGhlIGRyYWZ0KSBpbiBv cmRlciBmb3IgdGhlIGZvcndhcmRpbmcgdG8gc3VjY2VlZC4gQnkgdGhlIGRlZmluaXRpb25zIEni gJltIHVzaW5nIGhlcmUsIHRoYXQgaXMgZXhhY3RseSBhIGRhdGEgcGxhbmUgY2hhbmdlLg0KPiA+ ID4gDQo+ID4gPiBXaGF0LCBwcmVjaXNlbHksIGlzIHRoZW4gYmVpbmcgY2xhaW1lZD8NCj4gPiA+ IA0KPiA+ID4gVGhhbmtzLA0KPiA+ID4gDQo+ID4gPiDigJRKb2huDQo+ID4gPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4gc3ByaW5nIG1haWxp bmcgbGlzdA0KPiA+ID4gc3ByaW5nQGlldGYub3JnDQo+ID4gPiBodHRwczovL3VybGRlZmVuc2Uu Y29tL3YzL19faHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmdfXzsh IU5FdDZ5TWFPLWdrIVM3cmJuWWc2YVYyczNjeW9UQ0wzd3dXWDRicGJGb2F3UEx0NnlMZVlzbXM4 MnNMbDl0VXBSVTFYNWMtRDlBJA0KPiA+IA0KPiANCg0K From nobody Wed Oct 27 05:42:05 2021 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 E51883A1159 for ; Wed, 27 Oct 2021 05:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.108 X-Spam-Level: X-Spam-Status: No, score=-3.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_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=liquidtelecom.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 9ln9xAD1nApw for ; Wed, 27 Oct 2021 05:41:59 -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 A6FE03A10ED for ; Wed, 27 Oct 2021 05:41:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=liquidtelecom.com; s=mimecast20210406; t=1635338516; 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=w85vKB234rg4r5ee46+/JTJal3NVMfprJRqlo+NYEHI=; b=rh0owZN67x2YAi2S1e6RMDQPYrrtP9NsMMqhY7Su5hgt0OySomZtNcghxRY4ejFPg9LaFL T06vKtNKv8LCcJJehtiHqsmNgQfbpM6es08JbJ8VOSoYYwYT0c3QmBgrBFJ9h/cvJUoEU+ 2wV51M6NhV6nVm4eVGM6YT8/VTP2NcU= Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04lp2051.outbound.protection.outlook.com [104.47.14.51]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-129-WE8eCAfuON-vP11T5Pwlxg-1; Wed, 27 Oct 2021 13:41:53 +0100 X-MC-Unique: WE8eCAfuON-vP11T5Pwlxg-1 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com (2603:10a6:20b:346::6) by AS8PR03MB7656.eurprd03.prod.outlook.com (2603:10a6:20b:400::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4628.18; Wed, 27 Oct 2021 12:41:52 +0000 Received: from AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9]) by AS8PR03MB7622.eurprd03.prod.outlook.com ([fe80::90ec:90d5:59c4:fef9%6]) with mapi id 15.20.4628.020; Wed, 27 Oct 2021 12:41:52 +0000 From: Andrew Alston To: Toerless Eckert , "spring@ietf.org" Thread-Topic: [spring] SPRING: Better base header + addresses for the future ? (draft-eckert-intarea-functional-addr-internets) Thread-Index: AQHXye1C809jMqwVY0OGsOojysOLPqvmyzvA Date: Wed, 27 Oct 2021 12:41:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3a980c6e-5d5b-4453-a202-08d99947270b x-ms-traffictypediagnostic: AS8PR03MB7656: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0 x-microsoft-antispam-message-info: gvTyUz87qrSMQyP+GF7oYZsPmlj+Y+79WzWATGa5lo/MbySv1c4kyRCjLLmR/xzvJj4C/nQAQEvWvsLohdv+Gk6P+q3cB+KJYzZqe1SyuRoTaUsvmqT/YdV2J+J/iPZsyjYtcDpAGzSrGoI2rFsGOp0GVJAwTdN7WqYHTbMpiQnqK3GIVDAe4rqXjuynGkQ8Xp5pbaCDNPqwIkE0OiaDl244aCxGxmixRH52ydzQ4xygB5fNNntsynqD3GfgR9Xf9N/+8gsxI9KniNwXnXvabyixldE4N8zEv11wQWjo/PSwaucb/dRhtoDDzBNzgtAIeJLlEUny6Fi1CmpRk2sFUFt7HNBBAIW3KVf07tZPb7ddbDM+fXEzHserZwt4EJrk8yEZcfOP2sitdYIXelT4xvbBKHrpHhdFzGpn8eIpV0Nsp9C8Fulpqhzwrccog2Ja5OrW2hDuIQ8vBmet6cj39Nti1v5kMO9UMKOi5MYQmSVJkdzNQYAPxf1/knMIVsxnDhJtd+iBOcpxbjPJNWFVi8n/w+oamytCKMLxAvmsVGIy2aBLHL2eVx5rsIcy2W8auuxSWJcClazzmKOD7FGWI+x0rcne7DjP8YMCckYkgUy44nlp8ce+5Sk4DBKQLkqwX0dacPpdDEwYWQLX2ZsrvfBtHVKisMu3Q3eBzM1vmjcn5lBbtV84r7UYG1odcfRppBvKYBy4sqcUPcsJYwBQeLTS6SV0P/Zg7thz9yJH/YyZXyw9F8l2rVbZoDpotIkQgtUB6qJfJLpn3kKjGYyCwKx28XY7j7PAgB2RLO4+/Ys= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AS8PR03MB7622.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66476007)(86362001)(53546011)(83380400001)(508600001)(966005)(186003)(316002)(66446008)(9686003)(8676002)(110136005)(5660300002)(8936002)(64756008)(6506007)(71200400001)(52536014)(66946007)(66556008)(166002)(55016002)(33656002)(38100700002)(2906002)(38070700005)(122000001)(7696005)(76116006); DIR:OUT; SFP:1102 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?VidTBvzc3tkjxNsnwMak9BtrYkgliv5pJ1wYYgKnpWBRLqOk/3T/nRNQjeBS?= =?us-ascii?Q?e0G73bMCE+6MGFPJdRBvpKHEjO9j9abHBuBsvEpqI4c+AA2DAQ7+AxhEcg4E?= =?us-ascii?Q?E+zXbt8d63nJIjirqc/ccAsHI8yYz7Z4eqXdSW7osQ1h42mBMb11IGvA36QV?= =?us-ascii?Q?SfXvhks+ml8GaeFrhqiW/DSR54j4iRO/np3VCOxOAhmFTL56VZKaS1yGJzfU?= =?us-ascii?Q?E1ApFtVbRZi/aYMzF7MC+Y9pN0ytumye3iSm3p+kP625J+co13c+SzU8h3GP?= =?us-ascii?Q?VpnOMgberViUpCcL3dg9sloEtzdzn4obZBLMyloj80PoOljIMnGGn16TtZ9+?= =?us-ascii?Q?AMkTyKAUh2eA8H3hSQxPoOING5eF2XdOKdXPsb6PcA2RCjxjE4BZxVHMfDWq?= =?us-ascii?Q?9geT8RKwA5Ew8jCv5/jCVODKYqDbrkOGphLZgf3QHa7qPX+brhcQ9XDexsvj?= =?us-ascii?Q?dttcD+c52t2YBf7G6GabaZ8O9psELRqW3Ok2HdzC07BNsYIgbPAGL7o0DYsg?= =?us-ascii?Q?b1afSL2IRtJXOSDfzpcPTvx8iQ0K3HfI1+LqKrrzsJksGe7Ye4D2/3h3a8eC?= =?us-ascii?Q?dCUxxbsC8rqEKjDfY0708wuUDLM9EaPQZ86g6UD+1YHvK80itTsk/fCf0vgy?= =?us-ascii?Q?NT5E5pLE3IJBf9f0ghoSny+RocsjEz+cVfEvcyWvqYRuQyCd3BYs3J90HuiY?= =?us-ascii?Q?BXpP4rccU5DuErLvw+0GUSkwd3Me/p/gwhRDgcDdx6R8Ib477z6o7g8C9puj?= =?us-ascii?Q?cKuizaRQKgU8bpTByKFgMJW4Dbv7YgvjW1tVAZfrWoeL/rJ+gumjbub+LdgV?= =?us-ascii?Q?qKKg4BoaOGTuG/2E0GHNitfWT7IFi3UQmVhRds73PRN7MDVCmptaoU4nj7WF?= =?us-ascii?Q?v9VuuDEk/UUTkniowUwARAJpeWqMGMDL3CTIieH5ZKogGyXmgUK5i8TWPUS5?= =?us-ascii?Q?pfMahs6nPWy2xvZ51K6txrQVRvt1gMEyJlK3cjHwnEcp5z1Trg0+lwYZxCaN?= =?us-ascii?Q?1CCf0wUFWkoZkIm1bXF9RdnpwHTpZhNRvCBGAW0+/5stjy++M4zip81/eBDc?= =?us-ascii?Q?knc9bdQ8EiB3LjE9ESM8X66o5tD8xyGz4hFHjZPCKQD4zDqP/9p/5gTpG8mV?= =?us-ascii?Q?i008QA1B2e8T+8882uF69GbqyKYQs5O1s9N7NDzAkWS2fSzzJa9OJtDPGAdJ?= =?us-ascii?Q?hORLGUhcR+WYUOphMuZGnwttePMaJB31ndecRenhFEXSpF6okN5P8d8YdS1d?= =?us-ascii?Q?N9PuD4FojELlx1hyLJkCv6sY2oEw4dQlS/gMspprM3BWbEi7atohQeKfhK3b?= =?us-ascii?Q?5qs08ZbhKAS2O0BFKdyfThm0FigeBLrRvF0AA2ZSSiBZuos0Te9JeqeNKhLo?= =?us-ascii?Q?6ib5yV1/oS0/YvU028+Lytg9ybB8mMuagf6dvJqESWLRKUl157eL7hPVN/D/?= =?us-ascii?Q?r9TIe6rP2gLtomynRnh4axLOT1iGyOPoQZLz2RyIlTTYX9hkOutxQDzxR5cD?= =?us-ascii?Q?4Sm6i481Il3cojXdL8s7PmuaJci2Hx9uyzi4mmKnulfhlbXx/nbYxWYJz92G?= =?us-ascii?Q?dxOJDLOkHo463JZ3wKBAjMTmEEJ8TLuiTDs18cjZOylhQ7ZLRFjvByt3yndG?= =?us-ascii?Q?522cEemwkqvBfB0JAuIUapyHqsci9cTfyyfXW/HfEHBdYLT/rnlOtP3YKCFq?= =?us-ascii?Q?o+R4cPZcsAodHOc/XSKkAqYweNtgAu0UavulQ3b+uoUT9RfN?= MIME-Version: 1.0 X-OriginatorOrg: liquidtelecom.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AS8PR03MB7622.eurprd03.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3a980c6e-5d5b-4453-a202-08d99947270b X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2021 12:41:52.5063 (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: Q6lY5F9ja3pLPAzYTIMJa7AfGStn0pXZgifO8cKfbx5x7Mh9kl8DhvD9iuMUk38brB71XVTZhXyePji6iN2LDypczzTZlduRCS3zSt58sDU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR03MB7656 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=C82A168 smtp.mailfrom=andrew.alston@liquidtelecom.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: liquidtelecom.com Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_AS8PR03MB76220FC6BB332ADF794C8631EE859AS8PR03MB7622eurp_" Archived-At: Subject: Re: [spring] SPRING: Better base header + addresses for the future ? (draft-eckert-intarea-functional-addr-internets) 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, 27 Oct 2021 12:42:04 -0000 --_000_AS8PR03MB76220FC6BB332ADF794C8631EE859AS8PR03MB7622eurp_ Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Toerless, I have one question - how you reconcile any of what is in the email below w= ith the spring charter. I would say - that if this line of thought were to be progressed - that the= way forward would be to call a BOF - see if there was support - and form a= working group - and at that point - if there was support to effectively in= troduce an entire new dataplane and everything it encompasses - it could go= forward leaving ipv6 alone and in its original state for those that have a= bsolutely zero interest in seeing ipv6 changed to the degree that seems to = be being proposed here. But irrespective of that - the spring charter is extremely clear - if you = wish to modify an existing data plane - it should be done inside the workin= g group that owns that data plane - or at the very least - with the permiss= ion of that working group's chairs and the AD's of that particular area. T= his is very far out of mandate in my view Andrew From: spring On Behalf Of Toerless Eckert Sent: Tuesday, October 26, 2021 1:06 AM To: spring@ietf.org Subject: [spring] SPRING: Better base header + addresses for the future ? (= draft-eckert-intarea-functional-addr-internets) Dear Spring WG. Through IntArea and other WGs, some of us started to invesstigate what benefits it wouldhave to support variable long network layer addressing, and assuming we had them, how to better encode the semantics we're interested in them. I did propose at 111 via draft-eckert-intarea-functional-addr-internets one such approach, and while i didn't have time so far to better highlight in the draft itself in more details the applicability to the problems i think SPRING is working on, i would nevertheless be very happy to get feedback and thoght on it. I'll ask the chairs if they might have 5..10 minutes to give a SPRING centr= ic presentation Q&A for IETF112 of the idea. The pitch is really: -> If we are for spring trying to have more flexible and compact addressing to steer packets and call programs along the way, why do we want to constrain ourselves with rfc8200 encoding and addressing rules ? Sure, going beyond rfc8200 miht take a while, but its not as if we're in a hurry to plan a long term evolution now. We're not as pressured as we where by the Internnet in the 90'th to "quickly" come up with IPv6 (and leave a lot of IP-NG thoughts out of the picture). -> If we would figure out a new base header to superceed/amend rfc8200, we could IMHO become better for the addressing we seemingly like to have in SPRING than what we could do under rfc8200 doctrine. -> For our subject proposal specifically, applied to SPRING, the idea is si= mply to have the destination address be simply a sequence of the steering hops (each with an address length as long or short as the network operator wants= ), followed by the hops instructions - again as short or as long as the network operator wants. Aka: no worries anymore to come up with bogus rason why we need 128 bits for a steering how when we don't need programmability, and no reason to be woried we might run out of programming addressing space when we want more. And no need to additional extension headers when it can all be as simple as putting it into a single address. Cheers Toerless P.S.: Of course, if/when we think we want to do something in that direction= , SPRING itself may not be the executing body of any work, but maybe 6man or somethin with more willingness to innovate than 6man, but thats IMHO not the first step of discussion. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_AS8PR03MB76220FC6BB332ADF794C8631EE859AS8PR03MB7622eurp_ Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable

    Toerless,

     

    I have one question – how you reconcile any of= what is in the email below with the spring charter.

     

    I would say – that if this line of thought wer= e to be progressed – that the way forward would be to call a BOF R= 11; see if there was support – and form a working group – and a= t that point – if there was support to effectively introduce an entire new dataplane and everything it encompasses – it could go for= ward leaving ipv6 alone and in its original state for those that have absol= utely zero interest in seeing ipv6 changed to the degree that seems to be b= eing proposed here.

     

    But irrespective of that – the spring charter = is extremely clear  – if you wish to modify an existing data pla= ne – it should be done inside the working group that owns that data p= lane – or at the very least – with the permission of that working group’s chairs and the AD’s of that particular area.&n= bsp; This is very far out of mandate in my view

     

    Andrew

     

     

    From: spring <spring-bounces@ietf.org> = On Behalf Of Toerless Eckert
    Sent: Tuesday, October 26, 2021 1:06 AM
    To: spring@ietf.org
    Subject: [spring] SPRING: Better base header + addresses for the fut= ure ? (draft-eckert-intarea-functional-addr-internets)

     

    Dear Spring WG.

    Through IntArea and other WGs, some of us started to invesstigate what
    benefits it wouldhave to support variable long network layer addressing, and assuming we had them, how to better encode the semantics we're
    interested in them.

    I did propose at 111 via draft-eckert-intarea-functional-addr-internets one=
    such approach, and while i didn't have time so far to better highlight
    in the draft itself in more details the applicability to the problems
    i think SPRING is working on, i would nevertheless be very happy to
    get feedback and thoght on it.

    I'll ask the chairs if they might have 5..10 minutes to give a SPRING centr= ic
    presentation Q&A for IETF112 of the idea. The pitch is really:

    -> If we are for spring trying to have more flexible and compact address= ing
    to steer packets and call programs along the way, why do we want to
    constrain ourselves with rfc8200 encoding and addressing rules ?

    Sure, going beyond rfc8200 miht take a while, but its not as if
    we're in a hurry to plan a long term evolution now. We're not as
    pressured as we where by the Internnet in the 90'th to "quickly" = come
    up with IPv6 (and leave a lot of IP-NG thoughts out of the picture).

    -> If we would figure out a new base header to superceed/amend rfc8200,<= br> we could IMHO become better for the addressing we seemingly like to
    have in SPRING than what we could do under rfc8200 doctrine.

    -> For our subject proposal specifically, applied to SPRING, the idea is= simply to
    have the destination address be simply a sequence of the steering hops
    (each with an address length as long or short as the network operator wants= ),
    followed by the hops instructions - again as short or as long as the
    network operator wants. Aka: no worries anymore to come up with bogus
    rason why we need 128 bits for a steering how when we don't need
    programmability, and no reason to be woried we might run out of programming=
    addressing space when we want more. And no need to additional extension
    headers when it can all be as simple as putting it into a single
    address.

    Cheers
    Toerless

    P.S.: Of course, if/when we think we want to do something in that direction= ,
    SPRING itself may not be the executing body of any work, but maybe
    6man or somethin with more willingness to innovate than 6man, but thats
    IMHO not the first step of discussion.

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

    --_000_AS8PR03MB76220FC6BB332ADF794C8631EE859AS8PR03MB7622eurp_-- From nobody Wed Oct 27 18:59:50 2021 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 0AB2E3A177C; Wed, 27 Oct 2021 18:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.428 X-Spam-Level: X-Spam-Status: No, score=-5.428 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, NICE_REPLY_A=-3.33, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id or6UPSFEIJvr; Wed, 27 Oct 2021 18:59:37 -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 88AB73A1778; Wed, 27 Oct 2021 18:59:37 -0700 (PDT) Received: by mail-pj1-x102a.google.com with SMTP id v10so2906298pjr.3; Wed, 27 Oct 2021 18:59:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=xwTx/+H5e/+yg1ncSJ1J3Eo0mew5tHtFUj2pa51VGxk=; b=T2rXvhVZKLLqHtdfLExjfJc6Rw5oA0q3eaYOjQClxUd5SjJTX8JOLRCoccW0BGURbg x80Ip9ZGYT1wrYtKubSKb7G04Sumufq21esKmCZVXkeylPiVvDIVZMS9T4IH6CO32Xs2 RbFFIlueb9CmmI/U9AtT4vYaA1GU6rVbUMuObl4V29chE0aTbG3NY3eOYaUSU2b9kEYv 2fZKW6e/s0roWQu7LHMcm7vthBM1HsNONTGH7M3WfrCa3db7XutF2Gfh7WCq5ofBiMzz p1pzLAt6YtYWt35V+G0k1MFw3d7ZkI5I3fIaJqJ4RhgbU3/r+TOYcAAIbpSOXCPv8jGH TRpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xwTx/+H5e/+yg1ncSJ1J3Eo0mew5tHtFUj2pa51VGxk=; b=Hs/7F5QYCGeNVMq6iVeg3/UiQu8v13Q3+lN0TDKdJgQXZ/Ui7fx2NGSbNyK4FGFtX2 4XVD282Dy0uj04cjbYWtDQJtmJ79aPFUwqC0qyoJsQqHyCaIRVi39M+2Bl+fHcb9lOy5 TXjx6rsFzg13PNhPRkihMjDmmtVEWlvCxxhdwYIYJHVDwFB3pkFAl1Jxeo6LL9gXWi1K jVjqoiQTLomtiW57xfU3F1LHlCFBfse4Q27Fk62X4FJJHNDF6ErBociuSCoaftBs3osd bQ9HY7RDZXe7eHPnnzqrsqBiTEFZYqvNLHMyhuSK10TDLlUWfVNELZ2JOcP6Bjdvf/jz fduA== X-Gm-Message-State: AOAM532VURThNutn8jVSFePdHUYTmzQFct7Vx4Ndlv16jMxgnJhym3w0 Phn3a+Ihry1qwfHZj06g7WfZupsu9qoK1w== X-Google-Smtp-Source: ABdhPJzRNBvz76LfkFt1u21If9cI6LDxRvxYms+isLSx8qH1QLKz3VJ9+uzq48x8ffD1QcaKcIqgfA== X-Received: by 2002:a17:90a:a513:: with SMTP id a19mr9756374pjq.26.1635386375348; Wed, 27 Oct 2021 18:59:35 -0700 (PDT) Received: from ?IPv6:2406:e003:102d:e801:db7:d041:a2d:ce65? ([2406:e003:102d:e801:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id f21sm1245533pfc.203.2021.10.27.18.59.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 27 Oct 2021 18:59:34 -0700 (PDT) To: Greg Mirsky Cc: Eliot Lear , Nick Hilliard , SPRING WG List , 6man WG References: <89c62864-feb4-550e-2d63-264b2ecc3344@lear.ch> <8bf003b2-988d-6d6c-f080-519596a3b1ac@foobar.org> <5d39e7ae-531d-a821-847e-67b2c0471b24@gmail.com> From: Brian E Carpenter Message-ID: Date: Thu, 28 Oct 2021 14:59:30 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] Objection to wg adoption call for draft-filsfilscheng-spring-srv6-srh-compression (was: Re: Question from SPRING regarding draft-filsfilscheng-spring-srv6-srh-compression) 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, 28 Oct 2021 01:59:42 -0000 Greg, Those are exactly my questions too. Regards Brian On 25-Oct-21 11:25, Greg Mirsky wrote: > Hi Brian, > so far I haven't noticed a proposal to support C-SID in IGP. I think th= at it brings up a legitimate question: How is it going to work? Would it = C-SID be=C2=A0used in combination with=C2=A0dynamic routing protocols or = only from a centralized controller? >=20 > Regards, > Greg >=20 > On Sun, Oct 24, 2021 at 2:20 PM Brian E Carpenter > wrote: >=20 > On 25-Oct-21 09:23, Eliot Lear wrote: > > > > On 24.10.21 21:59, Nick Hilliard wrote: > >> Eliot Lear wrote on 24/10/2021 18:17: > >>> On 24.10.21 17:36, Nick Hilliard wrote: > >>>> The issue is a good deal deeper than just debugging.=C2=A0 As=20 long as > >>>> there's an option to specify a variable length parameter with= out > >>>> being able to specify the length in the protocol, then the pr= otocol > >>>> is fundamentally ambiguous and its interpretation is entirely= > >>>> context dependent. > >>> > >>> You mean, like a subnet mask? > >> > >> There's no direct analog here. > > > > Of course there is.=C2=A0 You cannot distinguish routing from ho= st without > > looking at external control channels, such as a routing or confi= guration > > protocol; and you certainly cannot determine the subnet mask of = a > > network without that external information, since it's not in the= > > packet.=C2=A0 And it's not even in the control plane if the rout= e has been > > aggregated.=C2=A0 Does that make the information "ambiguous"?=C2= =A0 The > point is > > that the subnet mask of a network is part of a context that you > > discussed, and you might not have it. > > > > Note- I am not taking a position about CSIDs, but I think this l= ine of > > argument is on the wrong track. >=20 > My assumption has been that within the SRv6 domain, some routing pr= otocol > will be in use (e.g. OSPF) and that (by some magic that I don't und= erstand) > it will be announcing the subnets currently in use, so that bog-sta= ndard > routing will occur, including the final hop, because "hosts" suppor= ting > SRv6 will have to function as routers for the final hop. After all,=20 SRv6 > is an overlay, a form of VRF. >=20 > Quite what the magic is that configures OSPF accordingly, I do not = know. >=20 > Regards > =C2=A0 =C2=A0 Brian > =C2=A0 =C2=A0 Thinking of the IETF standards process: https://xkcd= =2Ecom/2530/ >=20 > -------------------------------------------------------------------= - > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6=20 > -------------------------------------------------------------------= - >=20 From nobody Thu Oct 28 14:26:58 2021 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 C09C43A122B; Thu, 28 Oct 2021 14:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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 EtsUqF5APhCe; Thu, 28 Oct 2021 14:26:46 -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 059DD3A1229; Thu, 28 Oct 2021 14:26:45 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4HgJXj2MVCz6G9Ls; Thu, 28 Oct 2021 14:26:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1635456405; bh=IJhD48SVl96fYyTN7ShZk99cmPGryWUQayHDPXhQunQ=; h=Date:Subject:References:To:From:In-Reply-To:From; b=Jaxlwv4ptqdvNW8ruaBtSTNAv/z/P+UxLHzNBhOfqjQoeUC9pM4ohiHnV+vTMdsJ4 MDu0p1fZHf5z6Ysszivoz0zoouR2aHQbieqUvvZvwzMxaau5nOir5Vomv5wwyPtrDv tuooAvnmG5/6tjmBZUfpya2tjuLRJfvaY2yVspnY= X-Quarantine-ID: <81A7QEHT-Amv> X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.22.111] (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 4HgJXh572qz6G9Lr; Thu, 28 Oct 2021 14:26:44 -0700 (PDT) Message-ID: Date: Thu, 28 Oct 2021 17:26:43 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Content-Language: en-US References: To: "spring@ietf.org" , "sfc@ietf.org" , "lisp@ietf.org" From: "Joel M. Halpern" In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [spring] Fwd: FW: NomCom 2021-2022 Call for Community Feedback 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, 28 Oct 2021 21:26:51 -0000 It was noted that the nomcom is still very much asking for feedback, so per suggestions from other WG chairs, I am re-posting this call for feedback. Please give the nomcom your input, Joel On 10/19/21, 10:28 AM, "NomCom Chair 2021" wrote: Hi IETF, The deadline for nominee acceptance and questionnaire submission was yesterday, Oct 18. As of today, Oct 19, NomCom is accepting feedback on nominees for IAB, IESG Area Directors, IETF Trust and LLC Board. NomCom is also accepting feedback on other topics (more on this below). You can see the list of nominees for the 2021 nomination cycle at https://urldefense.com/v3/__https://datatracker.ietf.org/nomcom/2021/feedback/__;!!GjvTz_vk!D5mgZpIvFooiJRFGiGuo5Gihs7zePpKnX2yRSM7BrSmGlgCcscNOYEmnGaRe$ [If you are a nominee and submitted a questionnaire your name should appear on that page, otherwise, please let me know.] You may provide feedback using the web form. Any submitted feedback is encrypted with a key I created and gave only to NomCom members. Without this key, your feedback cannot be seen by the secretariat, the tools people, or any of the management. Your feedback through the web form is not anonymous when shown to NomCom members as you need an IETF login to provide it. You may also send feedback directly to the NomCom via nomcom-2021 at ietf.org If you want to give more anonymous feedback, please contact one of the NomCom members that you trust directly, and ask that person to relay the feedback anonymously to the NomCom. You can also submit feedback via email to nomcom-chair-2021 at ietf.org and I will enter it in the datatracker (one email per candidate, please). Please indicate if I should share your identity with the full NomCom. The positions to be filled and the desired expertise are listed at: https://urldefense.com/v3/__https://datatracker.ietf.org/nomcom/2021/__;!!GjvTz_vk!D5mgZpIvFooiJRFGiGuo5Gihs7zePpKnX2yRSM7BrSmGlgCcscNOYHUCFqCv$ Some of you may be aware of the "360-degree reviews" of the current IESG ADs: https://urldefense.com/v3/__https://mailarchive.ietf.org/arch/msg/ietf-announce/DecFofU9c-svf_yiCPQDi6nLOQg/__;!!GjvTz_vk!D5mgZpIvFooiJRFGiGuo5Gihs7zePpKnX2yRSM7BrSmGlgCcscNOYPk9Wf6i$ I encourage you to provide that feedback as well. I wish to clarify that personnel feedback to NomCom should be limited to nominees (some of which may also be IESG incumbents). This should clarify the difference of NomCom feedback with the "360-degree reviews". NomCom also welcomes feedback on topics related to the nomination process. Please submit via email as suggested above, although some topics may start showing up in the above feedback web form at https://urldefense.com/v3/__https://datatracker.ietf.org/nomcom/2021/feedback/__;!!GjvTz_vk!D5mgZpIvFooiJRFGiGuo5Gihs7zePpKnX2yRSM7BrSmGlgCcscNOYEmnGaRe$ . Thanks in advance for your feedback - we really value it and appreciate your time taken to submit it. Gabriel Gabriel Montenegro IETF NomCom Chair 2021-22 nomcom-chair-2021 at ietf dot org _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ietf-announce__;!!GjvTz_vk!D5mgZpIvFooiJRFGiGuo5Gihs7zePpKnX2yRSM7BrSmGlgCcscNOYNYj4p_n$ From nobody Sun Oct 31 08:36:32 2021 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 89E183A0B1F for ; Sun, 31 Oct 2021 08:36:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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 Hz3GWGsjoaEw for ; Sun, 31 Oct 2021 08:36:25 -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 EE7743A0B20 for ; Sun, 31 Oct 2021 08:36:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4Hj0d51tmhz6G8p1; Sun, 31 Oct 2021 08:36:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1635694585; bh=ffaR0Mx2NAEI8UB1rgMRwawfKiDdRAd5mzqG6L80jSs=; h=Date:From:Subject:To:Cc:From; b=IV/z+eSDZ5XrCVcBTa7eTz2z20+3C+pVJfdu0UMQh+lTg6gA9eVnTi6oCnbvuG6ao 96SPk5ZC50UyMMX74erW6Q9OBmPAIiZOnvUSetHHQ2an6+wCZRWDCp4FL1gRfx4xFK PZ2Gyc/o+EWi3e/QOQ6510W2JxvyB0F3/D47pX9Y= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.22.111] (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 maila2.tigertech.net (Postfix) with ESMTPSA id 4Hj0d418mDz6G8F6; Sun, 31 Oct 2021 08:36:23 -0700 (PDT) Message-ID: <7bab18c1-7f45-3e8f-791e-2d3020303631@joelhalpern.com> Date: Sun, 31 Oct 2021 11:36:22 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 From: "Joel M. Halpern" To: "spring@ietf.org" Content-Language: en-US Cc: Martin Vigoureux , James Guichard , Bruno Decraene Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [spring] Conclusion of Adoption call for draft-filsfilscheng-spring-srv6-srh-compression 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, 31 Oct 2021 15:36:31 -0000 With apologies to the working group for the delay, this email formally ends the adoption call that was announced at https://mailarchive.ietf.org/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/ for draft-filsfilscheng-spring-srv6-srh-compression The conclusion is somewhat unusual, so please read carefully. First, let me thank all of the working group participants for their active and energetic participation in this call. That is what we need. In terms of the rough consensus of the feedback we received, the rough consensus of the working group is that we should adopt this document. Due to process concerns, I am placing two caveats on this adoption, one of which can be easily dealt with by the authors, and one of which will cause some delay. The SPRING working group chairs sent a policy statement last March https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/ which calls attention to the issue of conflict between working group efforts and existing PS or BCP RFCs. This policy applies to the subject document. It is my judgment that the issues raised regarding whether this work complies with RFC 4291 require adherence to this policy. As such, we need a draft in front of 6man (the responsible working group for RFC 4291) that addresses the raised disconnect. fortunately, we have been told that the 6man chairs and area directors are appointing authors for just such a document to address the issue of the relationship of C-SIDs with RFC 4291. Therefore, I will not be approving posting of the working group draft until the author team has posted an initial take for 6man consumption of such a draft. Once they have posted that draft, I will approve posting of a working group ID with the addition according to the next caveat. As per the statement in the adoption call, as part of adoption the document is required to have a section (an appendix seems the most appropriate, but placement will be up to the editors) on open issues. As there is a lot of controversy about the open issues, and about how to describe them, I am providing text (below) for that section. Once the draft is posted as a working group draft, the working group will of course own the text, and WG rough consensus can change the text. Also, once we have a WG draft I will arrange to get an issue tracker to make sure we keep track of all the issues, not just the major ones in the open issues section of the document. Expected text on Open Issues: Open Issues: Issues raised during and after the adoption call for this draft are tracked in an issue tracker. The remainder of this section identifies the most significant open issues, from the adoption call, for the working group to keep track of. As a reminder to those reading this section, this document is a work in progress, and subject to change by the working group. As noted at the front of this document, "It is inappropriate to use Internet-Drafts as reference material" o Given that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple SRv6 EndPoint behaviors that some WG members have stated are multiple data plane solutions, the working group will address whether this is valid and coherent with its one data plane solution objective. o As reminded in the conclusion of the adoption call, this document is subject to the policy announced by the SPRING chairs in https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/. In particular, this means that this document can not go to WG last call until 6man completes handling of an Internet Draft that deals with the relationship of C-SIDs to RFC 4291. It is hoped and expected that said resolution will be a WG last call and document approval in 6man of a document providing for the way that C-SIDs use the IPv6 destination address field. From nobody Sun Oct 31 11:19:26 2021 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 AC2253A112C for ; Sun, 31 Oct 2021 11:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 HgBkEd-PUha3 for ; Sun, 31 Oct 2021 11:19:19 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 5A0A33A112D for ; Sun, 31 Oct 2021 11:19:19 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id q13so28070015uaq.2 for ; Sun, 31 Oct 2021 11:19:19 -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=dNoKqJB/ENMcfIhP6xSoWOOGsoX2EllhhV9GETkyXa8=; b=TNgWffqQocBLaXtGVKTR1bwJqacwfVznb6HwNfNcBuCP0LAFcfmjCeIpEe7q2/ccPj J/j8g4SSv4830yvJNQgVnABLlLDESgme5K+rQzIHulc4D0awLDfRWM2qXJ9pI+OfXslz cPXKyfN72+dQc/8hJJ6F0u17eIL6KmBxJkm5tCy/786wcnYts0cogEB8hvRqVXscWB8H qhtazFYjsFyuAq6xWU0rqxrSTfBPEyrHN+upkphsqMIa/e2Q7YLzBB42BDaxqEFUyQwZ PoxqQI05tEPRuW/8X7AoSYU6NgCaekALe6kQR8diO4jd5aS4QEyX0MASgW7YSEHVYVjL vq2Q== 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=dNoKqJB/ENMcfIhP6xSoWOOGsoX2EllhhV9GETkyXa8=; b=F0HluOh3x5SN3ZNPYDDXRL2bFJisX4CHNJNnrWV90xjeD0HZRvE/SZ1K7B1bc/d/O6 WuuBkBlQi37IuHnCyh/22hX5KgelIfPnZ80O7mhH6fRXtH9jLKNTKZ/s8mbQ+Z61E4gb WolMc/iDgPjOEd0xrkNvDdTIgQDkstiDtIWhS3tjszdwkGB/kZAlXCPHb2x8Wec8FMxY tAcTkoyEMAUpA2FZWS39hhLNHRN6IawCuzDRSqngG7+owybQ7XR3UJOe3MlYCH0uNVPN ODTcl+XnngaY5oiIxdn/je4/ltqnEFgekIAgPLKowmLSYNnpi3/znVf+Q2FA72ljt02c eOxQ== X-Gm-Message-State: AOAM5339NcYM724PwBxqBVWpz7VF5kh687PN7TYKr6Q5ybL8nhaRSuRV y8OGcffYPPiPGEBzKlFOK6mUTmi9nnXMjpC7A5DuoQ== X-Google-Smtp-Source: ABdhPJwm4fiduHPoKnNZbv6R5kKbqvjpZN7Tl07wCsaFJ5+NeeCUEaqNyETzPd8ex34YO6me7eUKxPdsQk8wGbcNoB8= X-Received: by 2002:a05:6102:34ec:: with SMTP id bi12mr3202151vsb.0.1635704356109; Sun, 31 Oct 2021 11:19:16 -0700 (PDT) MIME-Version: 1.0 References: <7bab18c1-7f45-3e8f-791e-2d3020303631@joelhalpern.com> In-Reply-To: <7bab18c1-7f45-3e8f-791e-2d3020303631@joelhalpern.com> From: Robert Raszuk Date: Sun, 31 Oct 2021 19:19:19 +0100 Message-ID: To: "Joel M. Halpern" Cc: "spring@ietf.org" , James Guichard , Bruno Decraene , Martin Vigoureux Content-Type: multipart/alternative; boundary="0000000000001a93a605cfaa1932" Archived-At: Subject: Re: [spring] Conclusion of Adoption call for draft-filsfilscheng-spring-srv6-srh-compression 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, 31 Oct 2021 18:19:25 -0000 --0000000000001a93a605cfaa1932 Content-Type: text/plain; charset="UTF-8" Dear Joel, If I may, I would like to pose a clarification question in respect to the below announcement. *What makes RFC8986 compliant with RFC4291 which draft-filsfilscheng-spring-srv6-srh-compression violaties ? * Please kindly note that RFC8986 defines in sec 3.1 SID as LOC:FUNCT:ARG The only recommendation it makes for ARG is following: * In such a case, the semantics and format of the ARG bits are defined as part of the SRv6 Endpoint behavior specification. The ARG value of a routed SID SHOULD remain constant among packets in a given flow. Varying ARG values among packets in a flow may result in different ECMP hashing and cause reordering.* On the other hand please kindly observe that draft-filsfilscheng-spring-srv6-srh-compression provides set of semantics for ARG part of SID. *So that means that it entirely builds on prior art of RFC 8986. * That specific RFC went via many discussions and even appeal and was considered compliant with IETF prior documents. Now is this your judgement that the IETF process which led to standardization of SRv6 Network Programming was all fake and you can simply dismiss it ? The answer to this question is important as vendors and operators are investing in the technology especially when it comes out of IETF as Standards Track formal RFC. Kind regards, Robert Raszuk PS. I think you have perhaps accidently violated the IETF process. And not in regards to compression draft. But in respect to effectively asking 6man if RFC8986 is compliant to RFC4291 or not after it has been issued and approved. Because if it is draft-filsfilscheng-spring-srv6-srh-compression is automatically compliant. On Sun, Oct 31, 2021 at 4:36 PM Joel M. Halpern wrote: > With apologies to the working group for the delay, this email formally > ends the adoption call that was announced at > https://mailarchive.ietf.org/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/ > for draft-filsfilscheng-spring-srv6-srh-compression > > The conclusion is somewhat unusual, so please read carefully. > > First, let me thank all of the working group participants for their > active and energetic participation in this call. That is what we need. > > In terms of the rough consensus of the feedback we received, the rough > consensus of the working group is that we should adopt this document. > Due to process concerns, I am placing two caveats on this adoption, one > of which can be easily dealt with by the authors, and one of which will > cause some delay. > > The SPRING working group chairs sent a policy statement last March > https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/ > which calls attention to the issue of conflict between working group > efforts and existing PS or BCP RFCs. This policy applies to the subject > document. It is my judgment that the issues raised regarding whether > this work complies with RFC 4291 require adherence to this policy. > As such, we need a draft in front of 6man (the responsible working group > for RFC 4291) that addresses the raised disconnect. > fortunately, we have been told that the 6man chairs and area directors > are appointing authors for just such a document to address the issue of > the relationship of C-SIDs with RFC 4291. > Therefore, I will not be approving posting of the working group draft > until the author team has posted an initial take for 6man consumption of > such a draft. Once they have posted that draft, I will approve posting > of a working group ID with the addition according to the next caveat. > > As per the statement in the adoption call, as part of adoption the > document is required to have a section (an appendix seems the most > appropriate, but placement will be up to the editors) on open issues. As > there is a lot of controversy about the open issues, and about how to > describe them, I am providing text (below) for that section. Once the > draft is posted as a working group draft, the working group will of > course own the text, and WG rough consensus can change the text. Also, > once we have a WG draft I will arrange to get an issue tracker to make > sure we keep track of all the issues, not just the major ones in the > open issues section of the document. > > Expected text on Open Issues: > > Open Issues: > > Issues raised during and after the adoption call for this draft are > tracked in an issue tracker. The remainder of this section identifies > the most significant open issues, from the adoption call, for the > working group to keep track of. > > As a reminder to those reading this section, this document is a work in > progress, and subject to change by the working group. As noted at the > front of this document, "It is inappropriate to use Internet-Drafts as > reference material" > > o Given that the working group has said that it wants to standardize one > data plane solution, and given that the document contains multiple SRv6 > EndPoint behaviors that some WG members have stated are multiple data > plane solutions, the working group will address whether this is valid > and coherent with its one data plane solution objective. > > o As reminded in the conclusion of the adoption call, this document is > subject to the policy announced by the SPRING chairs in > https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/. > In particular, this means that this document can not go to WG last call > until 6man completes handling of an Internet Draft that deals with the > relationship of C-SIDs to RFC 4291. It is hoped and expected that said > resolution will be a WG last call and document approval in 6man of a > document providing for the way that C-SIDs use the IPv6 destination > address field. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --0000000000001a93a605cfaa1932 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Dear Joel,

    If I may, I would like to po= se a clarification question in respect to the below announcement.=C2=A0

    What makes RFC8986 compliant with RFC4291 which dr= aft-filsfilscheng-spring-srv6-srh-compression violaties ?=C2=A0

    Please kindly=C2=A0note that RFC8986 defines in sec 3.1 S= ID as LOC:FUNCT:ARG

    The only recommendation it= makes for ARG is following:=C2=A0

    =C2=A0 =C2= =A0In such a case, the semantics and format of the ARG bits are defined
    = =C2=A0 =C2=A0as part of the SRv6 Endpoint behavior specification.

    = =C2=A0 =C2=A0The ARG value of a routed SID SHOULD remain constant among pac= kets in
    =C2=A0 =C2=A0a given flow.=C2=A0 Varying ARG values among packet= s in a flow may result
    =C2=A0 =C2=A0in different ECMP hashing and cause = reordering.

    On the=C2=A0other hand please = kindly observe that draft-filsfilscheng-spring-srv6-srh-compression provide= s set of semantics for ARG part of SID.=C2=A0

    S= o that means that it entirely builds on prior art of RFC 8986.=C2=A0

    That specific RFC went via many discussions and even= appeal and was considered compliant with IETF prior documents. Now is this= your judgement that the IETF process which led to standardization of SRv6 = Network Programming was all fake and=C2=A0you can simply dismiss=C2=A0it ?= =C2=A0

    The answer to this question is importan= t as vendors and operators are investing in the technology especially when = it comes out of IETF as Standards Track formal RFC.=C2=A0

    Kind regards,
    Robert Raszuk

    PS.= =C2=A0

    I think you have perhaps accidently violate= d the IETF process. And not in regards to compression draft. But in respect= to effectively asking 6man if RFC8986 is compliant to RFC4291 or not after= it has been issued and approved.=C2=A0=C2=A0

    Beca= use if it is=C2=A0draft-filsfilscheng-spring-srv6-srh-compression is automa= tically compliant.=C2=A0


    On Sun, Oct 31, 2021 at 4:36 P= M Joel M. Halpern <jmh@joelhalper= n.com> wrote:
    With apologies to the working group for the delay, this email formally=
    ends the adoption call that was announced at
    https://mailarchive.ietf.or= g/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/
    for draft-filsfilscheng-spring-srv6-srh-compression

    The conclusion is somewhat unusual, so please read carefully.

    First, let me thank all of the working group participants for their
    active and energetic participation in this call.=C2=A0 That is what we need= .

    In terms of the rough consensus of the feedback we received, the rough
    consensus of the working group is that we should adopt this document.
    Due to process concerns, I am placing two caveats on this adoption, one of which can be easily dealt with by the authors, and one of which will cause some delay.

    The SPRING working group chairs sent a policy statement last March
    https://mailarchive.ietf.or= g/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/
    which calls attention to the issue of conflict between working group
    efforts and existing PS or BCP RFCs.=C2=A0 This policy applies to the subje= ct
    document.=C2=A0 It is my judgment that the issues raised regarding whether =
    this work complies with RFC 4291 require adherence to this policy.
    As such, we need a draft in front of 6man (the responsible working group for RFC 4291) that addresses the raised disconnect.
    fortunately, we have been told that the 6man chairs and area directors
    are appointing authors for just such a document to address the issue of the relationship of C-SIDs with RFC 4291.
    Therefore, I will not be approving posting of the working group draft
    until the author team has posted an initial take for 6man consumption of such a draft. Once they have posted that draft, I will approve posting
    of a working group ID with the addition according to the next caveat.

    As per the statement in the adoption call, as part of adoption the
    document is required to have a section (an appendix seems the most
    appropriate, but placement will be up to the editors) on open issues. As there is a lot of controversy about the open issues, and about how to
    describe them, I am providing text (below) for that section.=C2=A0 =C2=A0On= ce the
    draft is posted as a working group draft, the working group will of
    course own the text, and WG rough consensus can change the text.=C2=A0 Also= ,
    once we have a WG draft I will arrange to get an issue tracker to make
    sure we keep track of all the issues, not just the major ones in the
    open issues section of the document.

    Expected text on Open Issues:

    Open Issues:

    Issues raised during and after the adoption call for this draft are
    tracked in an issue tracker. The remainder of this section identifies
    the most significant open issues, from the adoption call, for the
    working group to keep track of.

    As a reminder to those reading this section, this document is a work in progress, and subject to change by the working group.=C2=A0 As noted at the=
    front of this document, "It is inappropriate to use Internet-Drafts as=
    reference material"

    o Given that the working group has said that it wants to standardize one data plane solution, and given that the document contains multiple SRv6
    EndPoint behaviors that some WG members have stated are multiple data
    plane solutions, the working group will address whether this is valid
    and coherent with its one data plane solution objective.

    o As reminded in the conclusion of the adoption call, this document is
    subject to the policy announced by the SPRING chairs in
    https://mailarchive.ietf.or= g/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/.
    In particular, this means that this document can not go to WG last call until 6man completes handling of an Internet Draft that deals with the
    relationship of C-SIDs to RFC 4291.=C2=A0 It is hoped and expected that sai= d
    resolution will be a WG last call and document approval in 6man of a
    document providing for the way that C-SIDs use the IPv6 destination
    address field.

    _______________________________________________
    spring mailing list
    spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
    --0000000000001a93a605cfaa1932-- From nobody Sun Oct 31 11:27:32 2021 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 61A443A114E for ; Sun, 31 Oct 2021 11:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.43 X-Spam-Level: X-Spam-Status: No, score=-5.43 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, NICE_REPLY_A=-3.33, SPF_PASS=-0.001, 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 MU8YnENnjOR1 for ; Sun, 31 Oct 2021 11:27:25 -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 5F6003A114D for ; Sun, 31 Oct 2021 11:27:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4Hj4QP0M8bz6G9Kd; Sun, 31 Oct 2021 11:27:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1635704845; bh=/R7G1j7qJ8Cinc56CC0HOn4ofYu2MIQwoVr01UunPhI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Mdj2ntFoQQ54MzZ3Ig3w06PCkkNPXaDQQURWksCscM0jFCQtCSZlr4m05SWMKPet0 N29o3xQsthmxSZdf/YTn5wuWPtmWqmM7/rgk/jS2QXUrYGaSYJKooNcltVgUMrPteq 32z/IFMsvw3VWUKw2bD0YyGsC1yWT2UwcCv43aKg= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.22.111] (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 maila2.tigertech.net (Postfix) with ESMTPSA id 4Hj4QN3s69z6G8CP; Sun, 31 Oct 2021 11:27:24 -0700 (PDT) Message-ID: Date: Sun, 31 Oct 2021 14:27:23 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Content-Language: en-US To: Robert Raszuk Cc: "spring@ietf.org" References: <7bab18c1-7f45-3e8f-791e-2d3020303631@joelhalpern.com> From: "Joel M. Halpern" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] Conclusion of Adoption call for draft-filsfilscheng-spring-srv6-srh-compression 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, 31 Oct 2021 18:27:31 -0000 I am not attempting to revisit the question of whether RFC 8986 complies with RFC 4191. This compression documents raises additional issues beyond those in 8986 in some aspects of the flavors it describes. Yours, Joel On 10/31/2021 2:19 PM, Robert Raszuk wrote: > Dear Joel, > > If I may, I would like to pose a clarification question in respect to > the below announcement. > > *What makes RFC8986 compliant with RFC4291 which > draft-filsfilscheng-spring-srv6-srh-compression violaties ? * > > Please kindly note that RFC8986 defines in sec 3.1 SID as LOC:FUNCT:ARG > > The only recommendation it makes for ARG is following: > > /   In such a case, the semantics and format of the ARG bits are defined >    as part of the SRv6 Endpoint behavior specification. > >    The ARG value of a routed SID SHOULD remain constant among packets in >    a given flow.  Varying ARG values among packets in a flow may result >    in different ECMP hashing and cause reordering. > / > > On the other hand please kindly observe that > draft-filsfilscheng-spring-srv6-srh-compression provides set of > semantics for ARG part of SID. > > _So that means that it entirely builds on prior art of RFC 8986. _ > > That specific RFC went via many discussions and even appeal and was > considered compliant with IETF prior documents. Now is this your > judgement that the IETF process which led to standardization of SRv6 > Network Programming was all fake and you can simply dismiss it ? > > The answer to this question is important as vendors and operators are > investing in the technology especially when it comes out of IETF as > Standards Track formal RFC. > > Kind regards, > Robert Raszuk > > PS. > > I think you have perhaps accidently violated the IETF process. And not > in regards to compression draft. But in respect to effectively asking > 6man if RFC8986 is compliant to RFC4291 or not after it has been issued > and approved. > > Because if it is draft-filsfilscheng-spring-srv6-srh-compression is > automatically compliant. > > > On Sun, Oct 31, 2021 at 4:36 PM Joel M. Halpern > wrote: > > With apologies to the working group for the delay, this email formally > ends the adoption call that was announced at > https://mailarchive.ietf.org/arch/msg/spring/-tvDZ5biRXvfLlyJ8IMtX-7EUp4/ > > for draft-filsfilscheng-spring-srv6-srh-compression > > The conclusion is somewhat unusual, so please read carefully. > > First, let me thank all of the working group participants for their > active and energetic participation in this call.  That is what we need. > > In terms of the rough consensus of the feedback we received, the rough > consensus of the working group is that we should adopt this document. > Due to process concerns, I am placing two caveats on this adoption, one > of which can be easily dealt with by the authors, and one of which will > cause some delay. > > The SPRING working group chairs sent a policy statement last March > https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/ > > which calls attention to the issue of conflict between working group > efforts and existing PS or BCP RFCs.  This policy applies to the > subject > document.  It is my judgment that the issues raised regarding whether > this work complies with RFC 4291 require adherence to this policy. > As such, we need a draft in front of 6man (the responsible working > group > for RFC 4291) that addresses the raised disconnect. > fortunately, we have been told that the 6man chairs and area directors > are appointing authors for just such a document to address the issue of > the relationship of C-SIDs with RFC 4291. > Therefore, I will not be approving posting of the working group draft > until the author team has posted an initial take for 6man > consumption of > such a draft. Once they have posted that draft, I will approve posting > of a working group ID with the addition according to the next caveat. > > As per the statement in the adoption call, as part of adoption the > document is required to have a section (an appendix seems the most > appropriate, but placement will be up to the editors) on open > issues. As > there is a lot of controversy about the open issues, and about how to > describe them, I am providing text (below) for that section.   Once the > draft is posted as a working group draft, the working group will of > course own the text, and WG rough consensus can change the text.  Also, > once we have a WG draft I will arrange to get an issue tracker to make > sure we keep track of all the issues, not just the major ones in the > open issues section of the document. > > Expected text on Open Issues: > > Open Issues: > > Issues raised during and after the adoption call for this draft are > tracked in an issue tracker. The remainder of this section identifies > the most significant open issues, from the adoption call, for the > working group to keep track of. > > As a reminder to those reading this section, this document is a work in > progress, and subject to change by the working group.  As noted at the > front of this document, "It is inappropriate to use Internet-Drafts as > reference material" > > o Given that the working group has said that it wants to standardize one > data plane solution, and given that the document contains multiple SRv6 > EndPoint behaviors that some WG members have stated are multiple data > plane solutions, the working group will address whether this is valid > and coherent with its one data plane solution objective. > > o As reminded in the conclusion of the adoption call, this document is > subject to the policy announced by the SPRING chairs in > https://mailarchive.ietf.org/arch/msg/spring/vCc9Ckvwu5HA-RCleV712dsA5OA/ > . > In particular, this means that this document can not go to WG last call > until 6man completes handling of an Internet Draft that deals with the > relationship of C-SIDs to RFC 4291.  It is hoped and expected that said > resolution will be a WG last call and document approval in 6man of a > document providing for the way that C-SIDs use the IPv6 destination > address field. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > From nobody Sun Oct 31 11:31:36 2021 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 E26CC3A1152 for ; Sun, 31 Oct 2021 11:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 rFJ2bjiu_Nss for ; Sun, 31 Oct 2021 11:31:30 -0700 (PDT) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 339CC3A1151 for ; Sun, 31 Oct 2021 11:31:30 -0700 (PDT) Received: by mail-ua1-x92a.google.com with SMTP id v3so27979503uam.10 for ; Sun, 31 Oct 2021 11:31:30 -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=6nX/QqwEsnyGqPwqqPKHIPKgVgid879FyvIGliSq7MY=; b=YX620rSGdMrCi0ZjN6C/WYDhtc+79092gYhWWatdsg2PLdwyJZFwvbIxsglpHnX1/C Adko1IuC1I6YGMBr+CkR52NhGmQ2VbrpyfRdLnQ3R7K7Xjo7XeA+CCPGVyq7gGCjeTFm Hw+vg+kzNFNH8rgcuE2vliAfBWkwblg3CgFH56R657XQoVFSsSyDufbFWXyysODJnYNg SHDVazN5F+9uMQAa3GEwxaf8Xg9jUWWvtbWsaU4QS+VEFO+PX0tLZJeZp7yIs3a20RoX DUo17UKTAKOEhHagiyxkXjbhDYF+3R6nekkr/mrFDXN1QvWyO7lY4LCRUQhSBH6vZKAT Tcww== 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=6nX/QqwEsnyGqPwqqPKHIPKgVgid879FyvIGliSq7MY=; b=mW9yadPVS1cVuPMk2g4eNbnAJjp2+33OPtP67Z9UsUS1aIqn80YVQB3dKmxxTQSCjx /bOJRoW7wahkrdO7feWIggXIuzIuW65sBPPAiadQlvRasQfypRo1sc1eGEQiCZ/PgpY7 eh00hvm4vsrojMIcXbpxKb8rRNtmsPDme1wOyy6kFrsntjgMfgmpCE3vheG8k/7G2dkC mmZuvb6hC1DO67fECoHB3lsT7OU7qXte4CARhopdvYBQCxQClksJq4jKY3MAhPWheGGE /AZ7JwkEjBrtd0CAQyuxm73sh7dUt/dAw5kzOd7vrRu6+7yX3KFjWoOM1Dffxrevrg8I MTqA== X-Gm-Message-State: AOAM5319L2sZVcu1bt46RDIPaOKuWWE0+E4YMr0hCtnnI8gU2uGAcbyU 24Xh/2Kv8qb6jue5njCr0Q5CVsurMEFVYHF0+0j2L/No/jM= X-Google-Smtp-Source: ABdhPJzQcz2PPNuyP1YWiZs20MU3sXHOihXRpMyTcIxsdZU1ftHXZUcRkxiLwMctruby8CJM9JeNX57GTCx461zVkjo= X-Received: by 2002:ab0:6354:: with SMTP id f20mr21628594uap.116.1635705088339; Sun, 31 Oct 2021 11:31:28 -0700 (PDT) MIME-Version: 1.0 References: <7bab18c1-7f45-3e8f-791e-2d3020303631@joelhalpern.com> In-Reply-To: From: Robert Raszuk Date: Sun, 31 Oct 2021 19:31:31 +0100 Message-ID: To: "Joel M. Halpern" Cc: "spring@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bf828d05cfaa4461" Archived-At: Subject: Re: [spring] Conclusion of Adoption call for draft-filsfilscheng-spring-srv6-srh-compression 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, 31 Oct 2021 18:31:35 -0000 --000000000000bf828d05cfaa4461 Content-Type: text/plain; charset="UTF-8" > I am not attempting to revisit the question of whether RFC 8986 complies > with RFC 4191. > This compression documents raises additional issues beyond those in 8986 > in some aspects of the flavors it describes. Could you be so kind and enumerate where in the draft you see *anything* crossing the line by defining new semantics for the ARG part of the SID as defined in RFC8986 ? Hint: your argument could have been sustainable if RFC8986 would put additional restrictions on the ARG field. But it does not. Many thx, Robert --000000000000bf828d05cfaa4461 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    I am not attempting to revisi= t the question of whether RFC 8986 complies
    with RFC 4191.
    This compression documents raises additional issues beyond those in 8986 in some aspects of the flavors it describes.

    Could you be so kind and enumerate=C2=A0where in the draft you see *anyth= ing* crossing the line by defining new semantics for the ARG part of the SI= D as defined in RFC8986 ?=C2=A0

    Hint: your argumen= t could have been sustainable=C2=A0if RFC8986 would=C2=A0put additional res= trictions on the ARG field. But it does not.=C2=A0

    Many=C2=A0thx,
    Robert

    --000000000000bf828d05cfaa4461-- From nobody Sun Oct 31 11:47:29 2021 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 43A593A11AB for ; Sun, 31 Oct 2021 11:47:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.43 X-Spam-Level: X-Spam-Status: No, score=-5.43 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, NICE_REPLY_A=-3.33, SPF_PASS=-0.001, 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 rNuf6Vat-bdB for ; Sun, 31 Oct 2021 11:47:22 -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 436EB3A11AA for ; Sun, 31 Oct 2021 11:47:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4Hj4sQ0xqmz6G9Kd; Sun, 31 Oct 2021 11:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1635706042; bh=uaUAs5SrdeTcXsNlF5745dPznMWoE55sPcrsy9m/oqM=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=o3yZ61dfG1/sBvVN6HTLnm12lpivOsGz+2hdho4RT+c4dh3EHLqIWBALk5AwQmVZM jEubF8QlKROljQwYHiFnw+B+n3ffz+RrFB3ioxiv+DWFYY4w1s6K9IFDa/cDvWbwUv NoHXGlEjPDDnfKdEUbQXWGW82ZnK+ED3h3C3XVsY= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.22.111] (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 maila2.tigertech.net (Postfix) with ESMTPSA id 4Hj4sP4fgvz6G8F6; Sun, 31 Oct 2021 11:47:21 -0700 (PDT) Message-ID: Date: Sun, 31 Oct 2021 14:47:20 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Content-Language: en-US To: Robert Raszuk Cc: "spring@ietf.org" References: <7bab18c1-7f45-3e8f-791e-2d3020303631@joelhalpern.com> From: "Joel M. Halpern" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] Conclusion of Adoption call for draft-filsfilscheng-spring-srv6-srh-compression 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, 31 Oct 2021 18:47:27 -0000 From my perspective the discussions as part of the adoption call in SPRING, and the discussions in 6man make it clear that there is an issue to be resolved. It may be that the issue will be resolved in saying there is nothing that needs to be specified. It may be resolved by saying that there are differences, and that they are acceptable. There are many other ways that it may be resolved. It is my job as chair, given the policy, to determine that there is an apparent discrepancy that needs to be addressed. I have done so. Yours, Joel On 10/31/2021 2:31 PM, Robert Raszuk wrote: > > I am not attempting to revisit the question of whether RFC 8986 > complies > with RFC 4191. > This compression documents raises additional issues beyond those in > 8986 > in some aspects of the flavors it describes. > > > Could you be so kind and enumerate where in the draft you see *anything* > crossing the line by defining new semantics for the ARG part of the SID > as defined in RFC8986 ? > > Hint: your argument could have been sustainable if RFC8986 would put > additional restrictions on the ARG field. But it does not. > > Many thx, > Robert > From nobody Sun Oct 31 12:04:25 2021 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 EA3153A11ED for ; Sun, 31 Oct 2021 12:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ZNSm2JMuQpPS for ; Sun, 31 Oct 2021 12:04:18 -0700 (PDT) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 06DDF3A11EC for ; Sun, 31 Oct 2021 12:04:17 -0700 (PDT) Received: by mail-ua1-x930.google.com with SMTP id o26so28127597uab.5 for ; Sun, 31 Oct 2021 12:04:17 -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=WaG9oEO33UE0H4BVJRHmQri030ogpA3rBatS+PL5n44=; b=fN141MEY2IcTSW3ZEgCuMYnN1M43M3ewwDunjHxjTP/qNsl5t/yNRkf8SRWl0haqoc pd+xvFIJUrLHAE8xcm9/ApV1+o0eVglfYWceUMpjwEpkBnpa8FHeVvQUVhz+Zq6jBvmp tOGPQr8jgrdnVsAHg8mwm7SsCO7oHfh/d4QRAEVk8X+4d0Y4JY0t2Lyg/Q+iLMBDp9eM FZaA4U7BilADcqKsFgVYMB8R9QBs9e7jsDk4cfXZMtH0k780GYzYnBdphwf0wHZ8gIFX JxUeQvlt8UFNUossbG4MMIt5Eln82ycxz18t3US+IR1DPcasGRhkimLq0mst+/+4P65f NgZw== 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=WaG9oEO33UE0H4BVJRHmQri030ogpA3rBatS+PL5n44=; b=zdsDpaOfr7dYu8OpR3PxB+xOsFT5w/mGEYLlVGGfBM9V7MwHoNY2Yi7ocyWpgSyrhE 1x/eCTGXRBvQ72N4Sx70VWSAVdBCMu+ofDXyTFk3JY9aaKaTlC+piO86mwl4htpgPQR1 epu4bmcwrDaIsKHGjB4vwJD0VdP3JIv32WlgLSP2gQt/q1tuLH/tp0xIKyix+XH1bXbt cg6hZIxn5KfATvpXNnuyHTmNHBaTAMseYeS0BL30AuwejhS9xhtA6PGRSlO5yhtO4S8n oLbNOnor7BSiOLvrjKBqeG86gEJHd3y/fAfX+SN+FNtXdmPWi1RMlxsLee5IeYpv23yQ i/pA== X-Gm-Message-State: AOAM531i4Dk80h1UEtvcDkra0dQ1EKTqqMHL3V5Ec4v1wl/FAO3HQ9yg 2TBTVBH0eT2mquoyzgQt8CFGdIDiu+RyueATHkLgyhxWk7Q= X-Google-Smtp-Source: ABdhPJz2ZnS15uajE96pu+QVqGKyy9pegBgMEY+BcyDi+Lu7a/u6csQqzuvzMKM26leJyzf30wvVizV7YHAxfacJk3o= X-Received: by 2002:a05:6102:34ec:: with SMTP id bi12mr3346856vsb.0.1635707056642; Sun, 31 Oct 2021 12:04:16 -0700 (PDT) MIME-Version: 1.0 References: <7bab18c1-7f45-3e8f-791e-2d3020303631@joelhalpern.com> In-Reply-To: From: Robert Raszuk Date: Sun, 31 Oct 2021 20:04:19 +0100 Message-ID: To: "Joel M. Halpern" Cc: "spring@ietf.org" Content-Type: multipart/alternative; boundary="00000000000011700105cfaabaaf" Archived-At: Subject: Re: [spring] Conclusion of Adoption call for draft-filsfilscheng-spring-srv6-srh-compression 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, 31 Oct 2021 19:04:23 -0000 --00000000000011700105cfaabaaf Content-Type: text/plain; charset="UTF-8" Yes, the discussions in both SPRING and 6man prove that there is a group of folks who either do not like and do not accept the existence of RFC 8986 or simply do not fully understand what it contains. I do not think that as such it is sufficient not to accept the document as a WG draft observing the amount of industry support for it as expressed on the list. At min as requested a solid list of technical issues should have been provided where text in the draft goes above to what is already written in RFC8986. Kind regards, Robert. On Sun, Oct 31, 2021 at 7:47 PM Joel M. Halpern wrote: > From my perspective the discussions as part of the adoption call in > SPRING, and the discussions in 6man make it clear that there is an issue > to be resolved. It may be that the issue will be resolved in saying > there is nothing that needs to be specified. It may be resolved by > saying that there are differences, and that they are acceptable. There > are many other ways that it may be resolved. > > It is my job as chair, given the policy, to determine that there is an > apparent discrepancy that needs to be addressed. I have done so. > > Yours, > Joel > > On 10/31/2021 2:31 PM, Robert Raszuk wrote: > > > > I am not attempting to revisit the question of whether RFC 8986 > > complies > > with RFC 4191. > > This compression documents raises additional issues beyond those in > > 8986 > > in some aspects of the flavors it describes. > > > > > > Could you be so kind and enumerate where in the draft you see *anything* > > crossing the line by defining new semantics for the ARG part of the SID > > as defined in RFC8986 ? > > > > Hint: your argument could have been sustainable if RFC8986 would put > > additional restrictions on the ARG field. But it does not. > > > > Many thx, > > Robert > > > --00000000000011700105cfaabaaf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Yes, the discussions in both SPRING and 6ma= n prove that there is a group of folks who either do not like and do not ac= cept the existence=C2=A0of RFC 8986 or simply do not fully understand=C2=A0= what it contains.=C2=A0

    I do not think that as such it i= s sufficient not to accept the document as a WG draft observing the amount = of industry support for it as expressed on the list.=C2=A0

    At min as requested a solid=C2=A0list of technical issues should hav= e been provided where text=C2=A0in the draft goes above to what is already= =C2=A0written in RFC8986.

    Kind regards,
    Robert.=C2=A0

    On Sun, Oct 31, 2021 at 7:47 PM Joel M. Halpern &l= t;jmh@joelhalpern.com> wrote:=
    =C2=A0From my p= erspective the discussions as part of the adoption call in
    SPRING, and the discussions in 6man make it clear that there is an issue to be resolved.=C2=A0 It may be that the issue will be resolved in saying <= br> there is nothing that needs to be specified.=C2=A0 It may be resolved by saying that there are differences, and that they are acceptable.=C2=A0 Ther= e
    are many other ways that it may be resolved.

    It is my job as chair, given the policy, to determine that there is an
    apparent discrepancy that needs to be addressed.=C2=A0 I have done so.

    Yours,
    Joel

    On 10/31/2021 2:31 PM, Robert Raszuk wrote:
    >
    >=C2=A0 =C2=A0 =C2=A0I am not attempting to revisit the question of whet= her RFC 8986
    >=C2=A0 =C2=A0 =C2=A0complies
    >=C2=A0 =C2=A0 =C2=A0with RFC 4191.
    >=C2=A0 =C2=A0 =C2=A0This compression documents raises additional issues= beyond those in
    >=C2=A0 =C2=A0 =C2=A08986
    >=C2=A0 =C2=A0 =C2=A0in some aspects of the flavors it describes.
    >
    >
    > Could you be so kind and enumerate=C2=A0where in the draft you see *an= ything*
    > crossing the line by defining new semantics for the ARG part of the SI= D
    > as defined in RFC8986 ?
    >
    > Hint: your argument could have been sustainable=C2=A0if RFC8986 would= =C2=A0put
    > additional restrictions on the ARG field. But it does not.
    >
    > Many=C2=A0thx,
    > Robert
    >
    --00000000000011700105cfaabaaf-- From nobody Sun Oct 31 12:10:52 2021 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 073093A1210 for ; Sun, 31 Oct 2021 12:10:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.43 X-Spam-Level: X-Spam-Status: No, score=-5.43 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, NICE_REPLY_A=-3.33, SPF_PASS=-0.001, 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 gOxNp-cwWlkp for ; Sun, 31 Oct 2021 12:10:46 -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 99C883A120B for ; Sun, 31 Oct 2021 12:10:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4Hj5NP6SjFz6G9MG; Sun, 31 Oct 2021 12:10:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1635707445; bh=Iz/M/9s6PMdVXSunvUlb1R6CB0GAv/gYqHPGnJq4V/A=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=lYJXK0UabfyWYFGlv/e0W+yLsl3F1sKQFSWg7rg8kx5MUsQxXn+MzS0JBE8hj/IgC DZzgh5DLHlECUATjsKmTmoZdJs/vuzsBQjinLcGESVZ/bsHTMDuL84QjVebECPNw0u Rvchf0OnQ9ZsiJwLeIXvYX/kOcV5hqYnPGaGyCKs= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.22.111] (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 maila2.tigertech.net (Postfix) with ESMTPSA id 4Hj5NP2XTYz6G9MF; Sun, 31 Oct 2021 12:10:45 -0700 (PDT) Message-ID: <567b8aa6-24b4-2646-b379-915cde92aaf7@joelhalpern.com> Date: Sun, 31 Oct 2021 15:10:43 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.1 Content-Language: en-US To: Robert Raszuk Cc: "spring@ietf.org" References: <7bab18c1-7f45-3e8f-791e-2d3020303631@joelhalpern.com> From: "Joel M. Halpern" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] Conclusion of Adoption call for draft-filsfilscheng-spring-srv6-srh-compression 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, 31 Oct 2021 19:10:51 -0000 You are of course welcome to your view. My understanding of what I am required to do does not match yours. Yours, Joel On 10/31/2021 3:04 PM, Robert Raszuk wrote: > > Yes, the discussions in both SPRING and 6man prove that there is a group > of folks who either do not like and do not accept the existence of RFC > 8986 or simply do not fully understand what it contains. > > I do not think that as such it is sufficient not to accept the document > as a WG draft observing the amount of industry support for it as > expressed on the list. > > At min as requested a solid list of technical issues should have been > provided where text in the draft goes above to what is already written > in RFC8986. > > Kind regards, > Robert. > > On Sun, Oct 31, 2021 at 7:47 PM Joel M. Halpern > wrote: > >  From my perspective the discussions as part of the adoption call in > SPRING, and the discussions in 6man make it clear that there is an > issue > to be resolved.  It may be that the issue will be resolved in saying > there is nothing that needs to be specified.  It may be resolved by > saying that there are differences, and that they are acceptable.  There > are many other ways that it may be resolved. > > It is my job as chair, given the policy, to determine that there is an > apparent discrepancy that needs to be addressed.  I have done so. > > Yours, > Joel > > On 10/31/2021 2:31 PM, Robert Raszuk wrote: > > > >     I am not attempting to revisit the question of whether RFC 8986 > >     complies > >     with RFC 4191. > >     This compression documents raises additional issues beyond > those in > >     8986 > >     in some aspects of the flavors it describes. > > > > > > Could you be so kind and enumerate where in the draft you see > *anything* > > crossing the line by defining new semantics for the ARG part of > the SID > > as defined in RFC8986 ? > > > > Hint: your argument could have been sustainable if RFC8986 would put > > additional restrictions on the ARG field. But it does not. > > > > Many thx, > > Robert > > >
    Frombruno.decraene<bruno.decraene@orange.com>
    Date09/07/2021 21:12
    Tospring@ietf.org<spring@ietf.org>
    Subject[spring] WG Adoption call - = draft-srcompdt-spring-compression-requirement - = draft-srcompdt-spring-compression-analysis
    I object adoption of this document as well based on c= opious amount of technical counter arguments laid out in multiple threads. = Beside that it seems that to violate IETF v6 architecture documents we seem= to be trampling on established standards more and more using increasingly = contorted sophisms (yes, you can hijack any address architecture if you _as= sume_ that only /4 will be routing table entries & the rest belongs to = your new interpretation of address being a chipmunk that by magic means wil= l never ever escape a private basement until it does).

    <= /div>
    Beside that as others already pointed out copiously the document = content does not even seem to actually match WG consensus as recorded to my= understanding

    --- tony

    On Fri, Oct 1, = 2021 at 10:37 PM Ron Bonica <rbonica=3D40juniper.net@dmarc.ietf.org> wrote:

    Folks,<= /span>

    =C2=A0<= /span>

    Draft-filsfilscheng-s= pring-srv6-srh-compression-02 introduces three new SID types that can occup= y the Destination Address field of an IPv6 header. See Sections 4.1, 4.2, a= nd 4.3 of the draft for details.

    =C2=A0<= /span>

    The SPRING WG has iss= ued a call for adoption for this draft.

    =C2=A0<= /span>

    It is not clear that = these SID types can be harmonized with the IPv6 addressing architecture.=

    =C2=A0<= /span>

    Does anyone have an o= pinion?

    =C2=A0<= /span>

    =C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0Ron

    =C2=A0<= /span>


    Juniper Business Use Only

    --------------------------------------------------------------------
    IETF IPv6 working group mailing list
    ipv6@ietf.org
    Administrative Requests: https://www.ietf.org/mailman/list= info/ipv6
    --------------------------------------------------------------------
    --0000000000002936b105cded73d7-- From nobody Sat Oct 9 09:38:37 2021 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 BC4ED3A0D9D; Sat, 9 Oct 2021 09:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tr0Cl3v4BCS4; Sat, 9 Oct 2021 09:38:16 -0700 (PDT) Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A20A93A0D7A; Sat, 9 Oct 2021 09:38:14 -0700 (PDT) X-Envelope-To: spring@ietf.org Received: from crumpet.local (admin.ibn.ie [46.182.8.8]) (authenticated bits=0) by mail.netability.ie (8.17.1/8.16.1) with ESMTPSA id 199Gc62P036617 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Oct 2021 17:38:07 +0100 (IST) (envelope-from nick@foobar.org) X-Authentication-Warning: cheesecake.ibn.ie: Host admin.ibn.ie [46.182.8.8] claimed to be crumpet.local To: Tony Przygienda Cc: SPRING WG , "6man@ietf.org" <6man@ietf.org> References: From: Nick Hilliard Message-ID: Date: Sat, 9 Oct 2021 17:38:05 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:52.0) Gecko/20100101 PostboxApp/7.0.49 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 16:38:21 -0000 I object to adoption on pretty much the same basis as what Tony wrote. IPv6 isn't some game of Jenga where the object is to see how many foundation blocks you can pull out before the whole thing collapses. Separate to this, the WG adoption call for this draft violates two sections of the spring charter (avoiding modification to existing data planes and modification of data plane without reference to other WGs. The 6man WG was not formally consulted about this and it probably ought to have been. Nick Tony Przygienda wrote on 09/10/2021 16:49: > I object adoption of this document as well based on copious amount of > technical counter arguments laid out in multiple threads. Beside that it > seems that to violate IETF v6 architecture documents we seem to be > trampling on established standards more and more using increasingly > contorted sophisms (yes, you can hijack any address architecture if you > _assume_ that only /4 will be routing table entries & the rest belongs > to your new interpretation of address being a chipmunk that by magic > means will never ever escape a private basement until it does). > > Beside that as others already pointed out copiously the document content > does not even seem to actually match WG consensus as recorded to my > understanding > > --- tony > > On Fri, Oct 1, 2021 at 10:37 PM Ron Bonica > > wrote: > > Folks,____ > > __ __ > > Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three > new SID types that can occupy the Destination Address field of an > IPv6 header. See Sections 4.1, 4.2, and 4.3 of the draft for > details.____ > > __ __ > > The SPRING WG has issued a call for adoption for this draft.____ > > __ __ > > It is not clear that these SID types can be harmonized with the IPv6 > addressing architecture.____ > > __ __ > > Does anyone have an opinion?____ > > __ __ > > >                                                                             Ron____ > > __ __ > > > Juniper Business Use Only > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From nobody Sat Oct 9 11:05:44 2021 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 F144E3A0E13 for ; Sat, 9 Oct 2021 11:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=stc.com.sa 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 Rk0TUXO9ry6n for ; Sat, 9 Oct 2021 11:05:31 -0700 (PDT) Received: from ESGRYBM03.stc.com.sa (esgrybm03.stc.com.sa [212.118.156.88]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB7B3A0E17 for ; Sat, 9 Oct 2021 11:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=stc.com.sa; s=dkim; c=relaxed/simple; q=dns/txt; i=@stc.com.sa; t=1633802725; x=1665338725; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=N2xf9YXMfintmyABmgSL1ET7wxlIfWCfftSuznT7GEs=; b=N7yIYQaUQQGmZMv0WEBxY5P6LEcFc1ZBtm+sG9rp3MnoI3l8fYS5rh9LNtHwKOPt qU9tGpn33WzepHOAq8KSQ1SarXo4D+2ZGeOjwsYMnxN5yzj7MxqZV0U83w2XVr/O phf0MkgiNDCjF6dzHVm0SNh0GLkW9tIgXvJE5kjYYDw=; X-AuditID: d4769c58-fc3ff70000006af8-4e-6161d9e4e75e From: Ahmed MostafaSaleh ElSawaf To: James Guichard , SPRING WG CC: "spring-chairs@ietf.org" Thread-Topic: WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ Thread-Index: Ade2y9x8AYyWLN0OQYGZaAvNV9N3dQGbFqsQ Date: Sat, 9 Oct 2021 18:05:24 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_b28ecfa7c8a04397a9ba248cda44754fstccomsa_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA5VUa1ATVxhlkwABsrCExNxEcMLqqEVBEqCFDmDtA6XaKRVsqUphSRaSMdnE bILoaIt0rJGqRUepIlWLGanoYFvQqtgHEa2vonRQkcpTahXxAb5AK/RuFnDT/ur+2PnmfPee 7+y5Z6+QL25AFUI9ZSUtFGHAvXwFByRbD4Z3XyWISEf5y7FHr1UKYs9VbvCO/fXiM+Q1/pzq qqQ5DscgL4W3sACJzyasean6XGpGYjxBUSYrYSWVWpLWJOCpaW8oZ7GQ3kTRuFKvTcCjcaXZ QGhII0lZE3DCbCYpLZ7oq/zPEw+X6SklSWlMWj2Vm4Anp74bHhsbExeuwhPTdKRST+WYLMas aj/d1hu3Pc37c/M3XbgjKEAG04sQoRBg0aB1ILQI8RF6YbHgctFxb6aWYPNB8bEzXkzNx2LA tdJhhKmDMBu4s67Ei12TB7bdHOKxtRq01xzmM7UAmwS+fb7RVaNYHBisvuFaI8YWgyM/PPBk ah8sAzQV1QiYGsHGgSdnD/DYWTLQ0r3LVQMMA47jF/hsLQW3rg95smuyQEVrjyfLHwjObO8W sGvkoO6bZkExIi7lUJVytpRytrD4dLC7tt+LraeBvV/f5o/W53+5zuPiuxHvSkTyVurs+R++ /k5kVARt1URoTMYImvgegWFoyitLP4JUProb4UR4QsSJrEWEPFyBItkphDgo26RdriNoXSZt yzbqaRoeNC5F7wQThNh/rGexGUgal6Anr0AYHYOzbYYlkCgUBo1DRJHLaANphWnEJ6AbJmYS YhlnCG3Wa/QmG51psxicCBDyIW1YNEOrJZavIC0mdpgT0cDj2sRXSDUmGGzKmqmKUsep1eoo tUoVF/X/YFyG9kngCCwXZnsJSZpJy+iUEpg0PARFPDw8xOMsZC6Zn6M3QOlcOwC6oBnuDuS2 WUdk6OR9DC+34zIlBK3JgR/uxsjxJRRN431EiBXuA92t4Ql9GH98FRIa/mGkhbBZoePwX82k 4c/qRAoRoQiXs8rFtJkwQpirWoLKLzG2jrZYxUGoZxNERaOoS60c3cIc7BgLR2kIOimB+ZAX A7gqzyIViLDu5M5yvrCv0gHfT5i3WECZKFIRjC4VZhFiKbNVZ6PcTVXI0C8YUzFO16VQMQ5d 1ggbAZwGIxLSiXSZ7nQvdCqUaMY0uEvuNowrtQfZA8MPz5LHxD4Q3pb/8isInckIEo10WLvE 6PuMiX4joMstgGoZbJSCY1YwujiekThGzhWg3oPAC6VeAq4eCwM3ipeCn8+dQkDb3ToesJc/ EoCBjn4vWP3kDXb+3ecDNn/e4QsODtv9QNtX9/1Afcl5ERi4dBYFbWv7/UFVy44AsK29NgA4 Gqsw4Hx4BQMPnrUHguYf68RgS1lBEGjuPSEF1xxrZeDpyYsyYC88DUDXoyo5WH/drgDfnWlX gJv29vGgpbM6GByorQ+GpPeCe5hc8V7kCl79/8lVPpnF5GqkNZqrTnUmk6sRdCRXrQw4xuKW q261K1djA7heKQp4ezIWYRXGhrCO3pWJnzX7Py3vWhD5W6Tp6PQMTc3OxqjD42dtvt+x2tIz lWrjp05p8H0emLbmdGdZi4gM2D8UMndq7bauHa0r8QfW4ZQJuilVyRd2r8lx9m6d+bB32H/e 8JDpE2r/1EJbmXLVbFvFaknM06Ht91JTBo/XRXc1/PVKGH/RZcPH7bI/5Ukl5uUlK/IGfv/g S7/qirefnC7MmE/bMx4ftU0uaTT5zlj/qkh1ateh/vRP5Rto+7qs+lueCykrHp4o3dgUOvue x3sGtDBl+6EdmiTStm9ururNl2LqkpJPLLUs6Cx+fGwVvy8u+aExfeKuiZXzBnvuSv8g1hic e/M9GiJwAa0jVGF8C038A5oe/hbhBwAA Archived-At: Subject: Re: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ 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, 09 Oct 2021 18:05:41 -0000 --_000_b28ecfa7c8a04397a9ba248cda44754fstccomsa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Happy to see the adoption call was issued after a long-term discussion. As a= n operator, we have deployed SRv6 in our network, and we are paying attentio= n to the topic of SRv6 compression all the time. Thinking as an operator, we need the compression is defined based on SRv6 da= ta plane, and CSID is. CSID defines flavors to provide efficient SRH encodin= g method that are fully compatible with SRv6 architecture (RFC8986), that is= what we want in our network. Also, I see many vendors have implemented CSID= and interop test has been made for a long time, so I support the adoption. Thanks for the Chairs to handle this, it is indeed a very difficult work. BR AS From: spring On Behalf Of James Guichard Sent: Friday, October 1, 2021 4:05 PM To: SPRING WG Cc: spring-chairs@ietf.org Subject: [spring] WG Adoption call for https://datatracker.ietf.org/doc/draf= t-filsfilscheng-spring-srv6-srh-compression/ Dear WG: The chairs would like to express their appreciation for all the responses re= ceived to our emails with reference to how the working group wishes to move= forward with respect to a solution for SRv6 compression. The apparent inclination of the working group is to use https://datatracker.= ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compression/ as the basis f= or its compression standardization work. That is part of what this email att= empts to confirm. Because of the above the chairs would like to issue a 2-week WG call for ado= ption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfil= scheng-spring-srv6-srh-compression/ but with some clear guidelines as follow= s. By expressing support for adoption of this document you are fully aware o= f and are acknowledging that: 1. The SPRING working group is adopting a document that has multiple SRv6= Endpoint behaviors. 2. The document is a "living" document; it may change as it goes through= review and analysis by the SPRING working group. 3. All open discussion points raised on our mailing list MUST be addresse= d BEFORE said document is allowed to progress from the working group to publ= ication. A list of these discussion points will be documented in the WG docu= ment and maintained by the document editor in conjunction with the chairs. 4. If this document is adopted by the working group, the chairs specify a= s part of the adoption call that the following text describing an open issue= be added to the document in the above-described open issues section: * "Given that the working group has said that it wants to standardize= one data plane solution, and given that the document contains multiple SRv6= EndPoint behaviors that some WG members have stated are multiple data plane= solutions, the working group will address whether this is valid and coheren= t with its one data plane solution objective.". Please consider the above guidelines as you decide on whether to support or= not this WG adoption. Please express clearly your reasoning for support/non= -support as well as any open discussion points you would like addressed shou= ld the document be adopted into the working group. Thanks! Jim, Bruno & Joel The information in this email may contain confidential material and it is in= tended solely for the addresses. Access to this email by anyone else is una= uthorized. If you are not the intended recipient, please delete the email an= d destroy any copies of it, any disclosure, copying, distribution is prohibi= ted and may be considered unlawful. Contents of this email and any attachmen= ts may be altered, Statement and opinions expressed in this email are those= of the sender, and do not necessarily reflect those of Saudi Telecommunica= tions Company (STC). --_000_b28ecfa7c8a04397a9ba248cda44754fstccomsa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Happy t= o see the adoption call was issued after a long-term discussion. As an opera= tor, we have deployed SRv6 in our network, and we are paying attention to th= e topic of SRv6 compression all the time.

    &n= bsp;

    Thinkin= g as an operator, we need the compression is defined based on SRv6 data plan= e, and CSID is. CSID defines flavors to provide efficient SRH encoding metho= d that are fully compatible with SRv6 architecture (RFC8986), that is what we want in our network. Also, I s= ee many vendors have implemented CSID and interop test has been made for a l= ong time, so I support the adoption.

    &n= bsp;

    Thanks= for the Chairs to handle this, it is indeed a very difficult work.

     

     

    BR

    AS

     

    From: spring <spring-bounces@ietf.org> <= b>On Behalf Of James Guichard
    Sent: Friday, October 1, 2021 4:05 PM
    To: SPRING WG <spring@ietf.org>
    Cc: spring-chairs@ietf.org
    Subject: [spring] WG Adoption call for https://datatracker.ietf.org/d= oc/draft-filsfilscheng-spring-srv6-srh-compression/

     

    Dear WG:

     

    The chairs would like to express their appreciation f= or all the responses received to our emails with reference to how the workin= g group wishes to move forward with respect to a solution for SRv6 compressi= on.

     

    The apparent inclination of the working group is to u= se https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compres= sion/ as the basis for its compression standardization work. That is par= t of what this email attempts to confirm.

     

    Because of the above the chairs would like to issue a= 2-week WG call for adoption ending October 15th for https://datatracker.ietf.org/doc/draft-filsfilscheng-spring-srv6-srh-compres= sion/ but with some clear guidelines as follows. By expressing support f= or adoption of this document you are fully aware of and are acknowledging th= at:

     

    1. The SPRING working group is adopting a document that has multiple SRv6= Endpoint behaviors.
    2. The document is a “living” document; it may= change as it goes through review and analysis by the SPRING working group.
    3. All open discussion points raised on our mailing list M= UST be addressed BEFORE said document is allowed to progress from the workin= g group to publication. A list of these discussion points will be documented in the WG document and maintained by the document= editor in conjunction with the chairs.
    4. If this document is adopted by the working group, the c= hairs specify as part of the adoption call that the following text describin= g an open issue be added to the document in the above-described open issues section:
      • "Given tha= t the working group has said that it wants to standardize one data plane sol= ution, and given that the document contains multiple SRv6 EndPoint behaviors= that some WG members have stated are multiple data plane solutions, the working group will address whether this= is valid and coherent with its one data plane solution objective.".

     

    Please consider the above guidelines as you decide on= whether to support or not this WG adoption. Please express clearly your rea= soning for support/non-support as well as any open discussion points you wou= ld like addressed should the document be adopted into the working group.

     

    Thanks!

     

    Jim, Bruno & Joel

     

     

    The information in this email may contain confidential material and it is in= tended solely for the addresses. Access to this email by anyone else is una= uthorized. If you are not the intended recipient, please delete the email an= d destroy any copies of it, any disclosure, copying, distribution is prohibi= ted and may be considered unlawful. Contents of this email and any attachmen= ts may be altered, Statement and opinions expressed in this email are those= of the sender, and do not necessarily reflect those of Saudi Telecommunica= tions Company (STC). --_000_b28ecfa7c8a04397a9ba248cda44754fstccomsa_-- From nobody Sat Oct 9 11:14:55 2021 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 8FFFA3A0E1B for ; Sat, 9 Oct 2021 11:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 iLhZV7r8_S9X for ; Sat, 9 Oct 2021 11:14:23 -0700 (PDT) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 96E953A0E1A for ; Sat, 9 Oct 2021 11:14:23 -0700 (PDT) Received: by mail-ua1-x936.google.com with SMTP id q13so9115686uaq.2 for ; Sat, 09 Oct 2021 11:14:23 -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=tFGdSs9qYz6NPJJfPZ1IjPDI7gStKfWa3aNCJWTNx5k=; b=fzVLmaBkMJCWeQYejFio2abGLhUVcc61dN21Zc49Rf7JBl6TDBBKPKDDyo3N2a3bqQ tHzksQWDDuEVOEzVH0kE8vTcba+9zJufp4xEG79ziP8NOX/k/HJs6m0JChWt+lfjdwCK jRRPfuUjDAmH2LLIIi3HSfhZ72T715o54ZQtyY3lBKuF/A7OBIZrTiGsUPIDXYQO7jpV xAat4LKQfipFv33+zBtgtEmwtviTodQnSnK1A6Yj/4fSbEKt3nD7bATaIFv3dvr+ijkt Q1gatxUC6VAHJReE9gok9B1CdvX2eZAVBilnKQHfdrsAPAyK1O2jLVb9bKhkv6JtvLXz anOw== 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=tFGdSs9qYz6NPJJfPZ1IjPDI7gStKfWa3aNCJWTNx5k=; b=mjA6FS2ZHpSRNoX8oUCuR65ZYn8paVMzjCdR0iZTO1N3afYFuXqDA83hgc+kYlWBXd yi4gl36WIYEjOg2Wy9LDLFf+UKvcnEzbNfNWh9pd4+uQaO55/sT446KdZA0GOSavH/ZL N4geLP2ecuR7V6vHpwyM569HIMf6tj+5KeM0rx60BrMTGQ3B4la0aNAVuN2uMt4McGVv ieievRdOnzNtaK578R7nOH0ddchLFzPkV7Nol7rOwtIsd0W7saEW7oOvuPY4EFDJm5tP 703wO61VTv9iRlb8KRsco9p/hTwFlz9NiLv2cKc1ub0BkRARYzfsfR85W+7AXQWMMJ7y 5q9A== X-Gm-Message-State: AOAM532PmtFSii9nWOyFFJ+SwZFNRy32z9fjgxBKxCB+skyf2brz6qdm ad2sNnqTucV3/oyJ2grVr3tQwM5CcWb3w4wUeL+6ng== X-Google-Smtp-Source: ABdhPJz5lGOkLS2D5YVZXTGEP3ktGFnUiXocEyGJdo5Bl3DQ6iP1+ZAHMbt4y5wZgmY6Gs4Y4mquMk30IpVHOx1P/sM= X-Received: by 2002:a05:6130:3a7:: with SMTP id az39mr9809246uab.8.1633803262104; Sat, 09 Oct 2021 11:14:22 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Sat, 9 Oct 2021 20:14:18 +0200 Message-ID: To: Tony Przygienda Cc: Ron Bonica , SPRING WG , "6man@ietf.org" <6man@ietf.org> Content-Type: multipart/alternative; boundary="000000000000122e5f05cdef77e0" Archived-At: Subject: Re: [spring] draft-filsfilscheng-spring-srv6-srh-compression-02 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, 09 Oct 2021 18:14:30 -0000 --000000000000122e5f05cdef77e0 Content-Type: text/plain; charset="UTF-8" Tony, *(yes, you can hijack any address architecture if you _assume_ that only /4 will be routing table entries & the rest belongs to your new interpretation of address being a chipmunk that by magic means will never ever escape a private basement until it does).* Let's try again ... as it seems this keeps coming back over and over again. Assume I got allocated /4 from RIR and I have allocated /10 blocks to my global sites connected over plain IPv6 Internet. I advertise those /10s via BGP. What technical harm will happen to anyone if I use bits 11-128 as it seems to fit and still send those packets via v6 Internet ? No basement, but public Internet. Last time I checked bits are bits and there is either 0 or 1 in the packets (at least till we get to quantum networking). It should be in no one's business in the transit to look anywhere beyond /10. Again please limit the answer to technical issues which this will cause. Kind regards, Robert On Sat, Oct 9, 2021 at 5:50 PM Tony Przygienda wrote: > I object adoption of this document as well based on copious amount of > technical counter arguments laid out in multiple threads. Beside that it > seems that to violate IETF v6 architecture documents we seem to be > trampling on established standards more and more using increasingly > contorted sophisms (yes, you can hijack any address architecture if you > _assume_ that only /4 will be routing table entries & the rest belongs to > your new interpretation of address being a chipmunk that by magic means > will never ever escape a private basement until it does). > > Beside that as others already pointed out copiously the document content > does not even seem to actually match WG consensus as recorded to my > understanding > > --- tony > > On Fri, Oct 1, 2021 at 10:37 PM Ron Bonica 40juniper.net@dmarc.ietf.org> wrote: > >> Folks, >> >> >> >> Draft-filsfilscheng-spring-srv6-srh-compression-02 introduces three new >> SID types that can occupy the Destination Address field of an IPv6 header. >> See Sections 4.1, 4.2, and 4.3 of the draft for details. >> >> >> >> The SPRING WG has issued a call for adoption for this draft. >> >> >> >> It is not clear that these SID types can be harmonized with the IPv6 >> addressing architecture. >> >> >> >> Does anyone have an opinion? >> >> >> >> >> Ron >> >> >> >> Juniper Business Use Only >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >> > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --000000000000122e5f05cdef77e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Tony,

    (yes, you can hijack any addre= ss architecture if you _assume_ that only /4 will be routing table entries = & the rest belongs to your new interpretation of address being a chipmu= nk that by magic means will never ever escape a private basement until it d= oes).

    Let's try again ... as it seems = this keeps coming back over and over=C2=A0again.=C2=A0

    =
    Assume I got allocated /4 from RIR and I have allocated /10 blocks to = my global sites connected over plain IPv6 Internet. I advertise those /10s = via BGP.=C2=A0

    What technical harm will happen to = anyone if I use bits 11-128 as it seems to fit and=C2=A0still send those pa= ckets via v6 Internet ? No basement, but public=C2=A0Internet.=C2=A0
    <= div>
    Last time I checked bits are bits and there is either 0 = or 1 in the packets (at least till we get to quantum networking). It should= be in no one's business=C2=A0in the transit to look anywhere beyond=C2= =A0/10.=C2=A0

    Again please limit=C2=A0the answer t= o technical issues which this will cause.

    Kind reg= ards,
    Robert