From nobody Tue Feb 4 10:44:14 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E8921208B3; Tue, 4 Feb 2020 10:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (1024-bit key) header.d=nist.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BCMiVZJypek2; Tue, 4 Feb 2020 10:21:59 -0800 (PST) Received: from GCC02-BL0-obe.outbound.protection.outlook.com (mail-bl2gcc02on2127.outbound.protection.outlook.com [40.107.89.127]) (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 4746C12087D; Tue, 4 Feb 2020 10:21:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZYAmcYhOWQObuAvx1r0TWA3tO2ofIZQaOHw/LppviFz9lv1uO6Tz9C6BT8EHjs2O8+GKw76Ev3e/L3mbUNZiYIvYdg1Dz4V+HNcywE99XroerbdBI+xSPaTrCJUel99TCnRwnJislkKTAoWhq6mQlLmtfYPmhneWd273O5X139AGvXvpo9d4ufYOYeuHBk0lM2cSljrIQSv4L7a/xrkYXgQnOljmY8c0C+KBIrBCwyAJPYvAB0ZR7xzstFkMlH3hYEFvMrmsXStla2jw2bqbUhVVuUID3jHpMuPGZ13ezKGhup9BJT+1PRgXZ34/nfCatibPXrShoJyjpC8ngh6F5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0ULjIXoT8Z1NI02e1PW93cCQNdzFMSbRhEpaHE4Gqv8=; b=FYoxFOLkM84+OBW9aCKWnE4Oz6WaYIepXhL6VuG+cDhU2A5tNtJbTH8i6dgRZ/sZLjsKI5sO/AUK743P7G8KaNsdpkHbPb7r1WmQt+A/UqLAGPeAZTa8/tXFIqxa8AElEXQY+dmt9zNZqtaI6gGg8C4+EWpa8fhdJDHIe4UN0mL2cnZN6jj1zwanTp40GTYoRRuP9d4pHH0Xe1z8kZe1/Dl3NqWaCqttZqqAMAtoFNBVqaDvD4IVBPmPQwxaGRcRr9ecS+ofBPaVVOrTlOH8g+DnzV0wZHpIH0embjke0fQeCa1q7YxP48ZgjJikrffysId8F7HZnvK87Sje8KmA1g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=0ULjIXoT8Z1NI02e1PW93cCQNdzFMSbRhEpaHE4Gqv8=; b=zi7iYtcK0O5CvveY8v4ABxJRFN/hGJGZ0X+chzOUrkWTaZ9uaHfCsMfX7jrZ8dw7WHlpa/68/IULUg6J3XeyABTuK9Cdz7SRVaSUGTiU6mfGD5BHHgl/grDPGayVkxB88uUO0E5PEfLgiKCkNeMPiVRlyi2pwnE7DF6bAtwz4/w= Received: from DM6PR09MB5448.namprd09.prod.outlook.com (20.180.61.9) by DM6PR09MB5749.namprd09.prod.outlook.com (20.180.62.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.26; Tue, 4 Feb 2020 18:21:57 +0000 Received: from DM6PR09MB5448.namprd09.prod.outlook.com ([fe80::6430:ee45:4fc4:f468]) by DM6PR09MB5448.namprd09.prod.outlook.com ([fe80::6430:ee45:4fc4:f468%6]) with mapi id 15.20.2707.020; Tue, 4 Feb 2020 18:21:57 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "Jakob Heitz (jheitz)" , Job Snijders , Nick Hilliard , John Heasly CC: "idr@ietf.org" , "grow@ietf.org" , "idr-chairs@ietf.org" , "grow-chairs@ietf.org" , "a.e.azimov@gmail.com" , Brian Dickson Thread-Topic: Question about BGP Large Communities Thread-Index: AdXbeNI4t0SppYFnSky8PqLGmuct1g== Date: Tue, 4 Feb 2020 18:21:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.140.161] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f2fc4d4d-c0ea-4dba-2594-08d7a99f1ea3 x-ms-traffictypediagnostic: DM6PR09MB5749: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(366004)(346002)(136003)(376002)(199004)(189003)(7416002)(966005)(33656002)(2906002)(8936002)(86362001)(55016002)(316002)(7696005)(478600001)(4326008)(66556008)(66476007)(9686003)(66946007)(76116006)(52536014)(5660300002)(81156014)(110136005)(186003)(71200400001)(8676002)(81166006)(26005)(54906003)(6506007)(66446008)(64756008); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR09MB5749; H:DM6PR09MB5448.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MV0nyewhDSqs0fokvNJoBvdZWW/Zpy8hIgBvKhFpSo/1TavdC1fM2yr1qqqB+97jT841URA5ikwLUB6zBCtMfqgxtX42ydgf3XsimyEj37lCT4Q0EUmpYEdFpAvjE648RKnh93v6uMV1vUvH5Xwi6kkAVEYwWtTUCgn+M446YcqETVSABRfVSqIqCdtBWK2RgSqmY784kFGe5BGNPapHbKw7PgGSttes26adhOBowL/JBn1Mt9yEhcj5i2/ffU6BBhn4Zm2ZEDgokW56UvHQ6GP/S6jAhlRGtaYNqqfpfKKBjT1E2Y6ZXOlS5Ly2usJ95Q/dNLGyA+tI5+qn0FRh0XPdSB1oA33tX5jt1bRkAzmS/K6AimqznX+Z2e1EucEqmop6pTz/zkz07kVCtRySEeyiFcN2piJWm/HA6IQuRhCU3st5fJefblj4TDcJH77yNz5js8XbiiIwVKGETYWrM7DwG3KZMK6Ur6pBpHYzgYsFyQ2SoH6SyMadup11Gwc9FuwFvJZ40qV0M0tAyi39Mg== x-ms-exchange-antispam-messagedata: Sf9jqwTi5oRelSRe0GVSjvgb/BIaYoGmjRD/mQbCB9uPziIwJ1R5FbrxQ99cqinSU5HF0XnppBYAX6UL3WN0otFW+Cg52eIzkMN67K/2Ac0rTn0hH1wctrEGWcq7nqD90pkFxxFNPfip5YOdQaj09A== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR09MB54489301E52DD711E031400984030DM6PR09MB5448namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: f2fc4d4d-c0ea-4dba-2594-08d7a99f1ea3 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2020 18:21:57.3962 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: nzvI9vlPMmzOf5NDMIG0HNXyQtLAeIZiUQklHHUObBm0zkyXdJk50I7VAXelJlTcFbFLDPQXewa5TfDe2Voqfw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR09MB5749 Archived-At: X-Mailman-Approved-At: Tue, 04 Feb 2020 10:44:13 -0800 Subject: [Idr] Question about BGP Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 18:22:03 -0000 --_000_DM6PR09MB54489301E52DD711E031400984030DM6PR09MB5448namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In the route leaks solution draft, https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation= -02 we (the authors) have proposed using BGP Large Community. We specify this to be a "well-known transitive Large Community". Question: Can the draft simply make an IANA request for a Global Administrator ASN value for Route Leaks Protection (RLP) type and request that it be published in IANA registry as a "well-known Transitive Large Community"? There is no IANA registry for Large Communities yet; we have requested IDR and GROW Chairs to facilitate that. ---------------- Details/background: We've read the following RFCs related to Large Communities: https://tools.ietf.org/html/rfc8092 https://tools.ietf.org/html/rfc8195 RFC 8195 has this table: +-------------------------------+-------------------------= + | RFC8092 | RFC 8195 = | +-------------------------------+-------------------------= -+ | Global Administrator | ASN | | Local Data Part 1 | Function = | | Local Data Part 2 | Parameter | +--------------------------------+------------------------= -+ which is instructive. In the examples that RFC 8195 offers, it appears it is *assumed* that the Large Communities are transitive. For comparison, in Extended Communities (RFC 7153), there are explicit Type values assigned for Transitive, Non-transitive, etc. https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-comm= unities.xhtml However, there is no such explicit Type specification for Large Communities (in RFC 8092 or elsewhere). Thank you. Sriram --_000_DM6PR09MB54489301E52DD711E031400984030DM6PR09MB5448namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

In the route leaks solution draft,

https://tools.ietf.org/html/draft= -ietf-grow-route-leak-detection-mitigation-02

we (the authors) have proposed using BGP Large Co= mmunity.

We specify this to be a "well-known transiti= ve Large Community".

 

Question:

Can the draft simply make an IANA request for

a Global Administrator ASN value for Route Leaks = Protection (RLP) type

and request that it be published in IANA registry=

as a "well-known Transitive Large Community&= quot;?

 

There is no IANA registry for Large Communities y= et;

we have requested IDR and GROW Chairs to facilita= te that.

 

----------------

Details/background:

 

We've read the following RFCs related to Large Co= mmunities:

<= span style=3D"color:windowtext;text-decoration:none">https://tools.ietf.org= /html/rfc8092

<= span style=3D"color:windowtext;text-decoration:none">https://tools.ietf.org= /html/rfc8195

 

RFC 8195 has this table:

        &= nbsp;        +-----------------= --------------+-------------------------+

        &= nbsp;        |    &n= bsp;  RFC8092         &nb= sp;          | RFC 8195 &= nbsp;           &nbs= p;  |

        &= nbsp;        +----------------------= ---------+--------------------------+

        &= nbsp;        | Global Administrator = ;   |      ASN    &n= bsp;            = ;    |

        &= nbsp;        |  Local Data Part 1&n= bsp;          |  &nb= sp; Function          &nb= sp;   |

        &= nbsp;        |  Local Data Part 2&n= bsp;          |   Pa= rameter            |=

        &= nbsp;        +----------------------= ----------+-------------------------+

which is instructive. In the examples that RFC 81= 95 offers,

it appears it is *assumed* that the Large Communi= ties are transitive.

 

For comparison, in Extended Communities (RFC 7153= ), there are

explicit Type values assigned for Transitive, Non= -transitive, etc.

https://www.iana.org/assignments/bgp-extended-communities/bgp-extended= -communities.xhtml

However, there is no such explicit Type specifica= tion

for Large Communities (in RFC 8092 or elsewhere).=

 

Thank you.

Sriram

 

 

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

--_000_DM6PR09MB54489301E52DD711E031400984030DM6PR09MB5448namp_-- From nobody Tue Feb 4 11:09:06 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34C06120113; Tue, 4 Feb 2020 11:09:06 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 B8-QOgx2aV28; Tue, 4 Feb 2020 11:09:04 -0800 (PST) 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 83EF21201A3; Tue, 4 Feb 2020 11:09:04 -0800 (PST) Received: by mail-ed1-x536.google.com with SMTP id g19so20885757eds.11; Tue, 04 Feb 2020 11:09:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=cWD+Qxp4p29FJPcKHN0kuKMOKXT+Am69NNvKzVl+r8M=; b=mglXjORsh4qiWEz1FqrF3CSDAiOM6Szoia2xTqChiPK1Aaf7Hu+Ee+4owXzMNIr9cQ NJJ0NhPeYWI1Mq8bPqeqRC5wzs/Ok7pPljfTIdypQPfrZhnXg6oTAeKliiPRFdidqSs8 WyWXuO7E+LOWM/pDqEhSkZiQGwCmUGg03Ez9X2B+qMrsxwimqF6iLHVKI/wjCTbGJt54 QFBcK8/jMXJW4x8I+Jyx9ImXeZGUjXJ5z/pfWk6wv9v0xYTeQ9OkHNPAgwwnAE40kOxa FQM2kuF3kb5X+50XHEiQumN9KLaok4aHREaFElA25aOaft0LhbfVte/lXZGXAGps5Er1 +ofg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=cWD+Qxp4p29FJPcKHN0kuKMOKXT+Am69NNvKzVl+r8M=; b=asugfypGpx1q+0ulRMAPJZ2yZwGzbxnUWtPbd8LnfDQNPF7TH/ijy1RFvW2H5cSD3j 7fFFNvAp6IEdUCr2leZSDVlhwlHzN0KKOh+QC0ArrHfIEr1vvKXgX50XWwOACO/HJRZr yK/+sZD9gj7G4NIuZTfeMyw4vBj3VmF+KOPKsqSt1Tb3HMUjezQxlYPGiNM5GTNDcL1/ +gEX+9dA7Ats9YC0Ou7/khwIiPeo0KCHf6J1Rlo5E/O3llBmFzPJG7dJvq2Ryt+D/+lu 1RFE8yYQ9UVLc6+tsC4ifGCXQd2oi3ND74tkJkDyC0SEW9q547Sz9XCHg9283nPgAA7g wIbg== X-Gm-Message-State: APjAAAWxSFL4Ljn4KBbTYuuSTKhuml1J4bT6sYjSHLQCEzEdi7xhqwFe pAOG30s8LU9msatdr/+S+x8X0GhhWZmocwSpzuY= X-Google-Smtp-Source: APXvYqyqquCcnWZYE+jZXnE/YPlBKz+unPOpXVR0VDGBMVx/1f87CmCCEN2RvxdsqAQnoEMBx6NlcGqCMCX+ZwO13Bo= X-Received: by 2002:a17:906:cf8f:: with SMTP id um15mr26922415ejb.289.1580843343025; Tue, 04 Feb 2020 11:09:03 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 4 Feb 2020 11:09:01 -0800 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Tue, 4 Feb 2020 11:09:01 -0800 Message-ID: To: "Sriram, Kotikalapudi (Fed)" Cc: "idr-chairs@ietf.org" , "grow-chairs@ietf.org" , "Jakob Heitz (jheitz)" , "grow@ietf.org" , John Heasly , "idr@ietf.org" , Job Snijders , Nick Hilliard Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Idr] [GROW] Question about BGP Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 19:09:06 -0000 On February 4, 2020 at 1:22:11 PM, Sriram, Kotikalapudi (Fed) wrote: [Speaking as a WG participant.] Sriram: Hi! ... > Question: > > Can the draft simply make an IANA request for > a Global Administrator ASN value for Route Leaks Protection (RLP) type > and request that it be published in IANA registry > as a "well-known Transitive Large Community"? No. There is no IANA registry for Global Administrator because it is simply a "four-octet namespace identifier...SHOULD be an ASN" [rfc8092], but it doesn't have to be. Skimming through draft-ietf-grow-route-leak-detection-mitigation, I would say (personal opinion) that you have two options: (1) Describe the Local Data Parts so that they are well-known when used by any ASN (Global Administrator). =C2=A0This has the disadvantage that the values may collide with existing policies (?). (2) Request IANA to assign an ASN for this application. =C2=A0Take a look at rfc7249/=C2=A72.1, which talks about the allocation of special-purpose AS Numbers. =C2=A0The advantage is obviously that collisions can be avoided, but it seems to me that it may be too much (an ASN) for just this application. So...if an ASN is requested, it would be independent of Large Communities. ... > it appears it is *assumed* that the Large Communities are transitive. rfc8092 "defines the BGP Large Communities attribute as an optional transitive path attribute". Regards, Alvaro. From nobody Tue Feb 4 11:22:04 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02144120865 for ; Tue, 4 Feb 2020 11:22:03 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 91q96yiyr1yS for ; Tue, 4 Feb 2020 11:21:59 -0800 (PST) Received: from mail-oi1-x230.google.com (mail-oi1-x230.google.com [IPv6:2607:f8b0:4864:20::230]) (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 D6C54120827 for ; Tue, 4 Feb 2020 11:21:58 -0800 (PST) Received: by mail-oi1-x230.google.com with SMTP id l136so19643765oig.1 for ; Tue, 04 Feb 2020 11:21:58 -0800 (PST) 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=86J8yU2V/vE16WjOwEXZxplNVLzUam4DfxGJYOKBjnQ=; b=c2eitoMBN785OmtWV7KcflqQBFoVFXocpjyHT0LQoRi/yCw828eFP1Wa/A/m08TUES feXH0li5nXRtEjMWxGLoFvv+XnAXKCpq2QeyxqykiIhGWhQ/XDpbu04n5YKsk11DCAac 2fcFrqhuO34q9886wxKrwgw7X5nmEB51QTCKhc0cqECwjUqy/YKj1DWYlBDkErZOd/SM pNcGTnEAeShD6E7goua1gxT6sGRnWJRA8OgdXVJDHqGbzoZABHnAtRGCXUnnyze0HaP3 aX2tlFSFELL44QZPc6R16tJApQ5+HshPZZ+vE2yUSeZw9yYZ0q+6Hy7EiC1FzGx8Fe8j 3yUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=86J8yU2V/vE16WjOwEXZxplNVLzUam4DfxGJYOKBjnQ=; b=EKVm+6qJDTtL6Crq3EVRE3iiI7DLh8Wo1qKFLEtIY8x6GB0nWgAcc77Si1c/dwD4/l DAqs0KLIAbI2bm5xPkvUZcdfmq+IF9FH4YDli71Jw6dC6O1KkDqZFNd+2JTd+Pc3WomY 6eUMSk8ep0CoDLLMWT+Xwh0Inpm+3a0bcYL419NQBDRl9O14x79Rpo/olJwYTHYJKIQA 6jX1XlqjV8cjyPymp9f/Wr+b4pW/Tl1i1yh76TH9EKjY71F4ng5o9vVCEHzREAtZ3doY 50mlmINUqcEACYZgx3iO7Le03+6VWjVNdSPBUmQeY0HGnfebfbVg3o/i408mkrblqkeZ f8hw== X-Gm-Message-State: APjAAAUN4vVQ6U70Vmt6cab14Hkzg4zxNfkUK0WLO6d2URfu+i4U2jAP XhtyIosF9uPtemLlDi/Qr76BqFbV7jz0jQSUaAC2Hw== X-Google-Smtp-Source: APXvYqwJWQMsh9T/Cg5veOqxfs40uHSiSmHUpjJ4Ujj80OxS/gMF23Q32vKwy0CEOtu2SlDHlRAd/ZmnMD++ELJkgAo= X-Received: by 2002:aca:4106:: with SMTP id o6mr345222oia.173.1580844118157; Tue, 04 Feb 2020 11:21:58 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Tue, 4 Feb 2020 20:21:48 +0100 Message-ID: To: Alvaro Retana , "Sriram, Kotikalapudi (Fed)" Cc: "idr@ietf.org" , "grow-chairs@ietf.org" , "idr-chairs@ietf.org" , "grow@ietf.org" , John Heasly Content-Type: multipart/alternative; boundary="0000000000001bbdd1059dc4f44f" Archived-At: Subject: Re: [Idr] [GROW] Question about BGP Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 19:22:03 -0000 --0000000000001bbdd1059dc4f44f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Sriram, Just to add to what Alvaro said what you are looking for seems to be a new type for the information required. Large Communities are really unstructured from the perspective of types like Extended Communities are. But please observe that proposed Wide Communities do have support for types: https://tools.ietf.org/html/draft-ietf-idr-wide-bgp-communities-05 so perhaps you may want to take a look into this type of carrier as well. Of course this assumes that more and more vendors will bring support of Wide Communities to their BGP code at some point :). Rgs, Robert. On Tue, Feb 4, 2020 at 8:09 PM Alvaro Retana wrote= : > On February 4, 2020 at 1:22:11 PM, Sriram, Kotikalapudi (Fed) wrote: > > [Speaking as a WG participant.] > > > Sriram: > > Hi! > > > ... > > Question: > > > > Can the draft simply make an IANA request for > > a Global Administrator ASN value for Route Leaks Protection (RLP) type > > and request that it be published in IANA registry > > as a "well-known Transitive Large Community"? > > No. > > There is no IANA registry for Global Administrator because it is > simply a "four-octet namespace identifier...SHOULD be an ASN" > [rfc8092], but it doesn't have to be. > > Skimming through draft-ietf-grow-route-leak-detection-mitigation, I > would say (personal opinion) that you have two options: > > (1) Describe the Local Data Parts so that they are well-known when > used by any ASN (Global Administrator). This has the disadvantage > that the values may collide with existing policies (?). > > (2) Request IANA to assign an ASN for this application. Take a look > at rfc7249/=C2=A72.1, which talks about the allocation of special-purpose > AS Numbers. The advantage is obviously that collisions can be > avoided, but it seems to me that it may be too much (an ASN) for just > this application. > > So...if an ASN is requested, it would be independent of Large Communities= . > > > ... > > it appears it is *assumed* that the Large Communities are transitive. > > rfc8092 "defines the BGP Large Communities attribute as an optional > transitive path attribute". > > Regards, > > Alvaro. > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --0000000000001bbdd1059dc4f44f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Sriram,

Just to add to what Alvaro s= aid what you are looking for seems to be a new type for the information req= uired.=C2=A0

Large Communities are really unstruct= ured from the perspective of types like Extended Communities are.=C2=A0

But please observe that=C2=A0proposed Wide Communitie= s do have support for types:=C2=A0


so perhaps you may want to take a look into this type of ca= rrier as well. Of course this assumes that more and more vendors will bring= support of Wide Communities to their BGP code at some=C2=A0point :).

Rgs,
Robert.



On Tue, Feb 4, 2020 at 8:09 PM Alvaro Retana <aretana.ietf@gmail.com> wrote:=
On February 4, = 2020 at 1:22:11 PM, Sriram, Kotikalapudi (Fed) wrote:

[Speaking as a WG participant.]


Sriram:

Hi!


...
> Question:
>
> Can the draft simply make an IANA request for
> a Global Administrator ASN value for Route Leaks Protection (RLP) type=
> and request that it be published in IANA registry
> as a "well-known Transitive Large Community"?

No.

There is no IANA registry for Global Administrator because it is
simply a "four-octet namespace identifier...SHOULD be an ASN"
[rfc8092], but it doesn't have to be.

Skimming through draft-ietf-grow-route-leak-detection-mitigation, I
would say (personal opinion) that you have two options:

(1) Describe the Local Data Parts so that they are well-known when
used by any ASN (Global Administrator).=C2=A0 This has the disadvantage
that the values may collide with existing policies (?).

(2) Request IANA to assign an ASN for this application.=C2=A0 Take a look at rfc7249/=C2=A72.1, which talks about the allocation of special-purpose AS Numbers.=C2=A0 The advantage is obviously that collisions can be
avoided, but it seems to me that it may be too much (an ASN) for just
this application.

So...if an ASN is requested, it would be independent of Large Communities.<= br>

...
> it appears it is *assumed* that the Large Communities are transitive.<= br>
rfc8092 "defines the BGP Large Communities attribute as an optional transitive path attribute".

Regards,

Alvaro.

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--0000000000001bbdd1059dc4f44f-- From nobody Tue Feb 4 14:18:53 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4CE1200B7 for ; Tue, 4 Feb 2020 14:18:50 -0800 (PST) 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, BODY_ENHANCEMENT=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (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 iSHD5JalEVIX for ; Tue, 4 Feb 2020 14:18:49 -0800 (PST) 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 E726012003F for ; Tue, 4 Feb 2020 14:18:48 -0800 (PST) Received: by mail-ot1-x331.google.com with SMTP id 66so17877otd.9 for ; Tue, 04 Feb 2020 14:18:48 -0800 (PST) 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=PFbi91tRiNGXeEmIHuQX11q7VviZ0SmNfg0DFyyfcmA=; b=YQmMhpohM1W2euZrlrQZcirBz5VhojwHY1Limobr8xyVGY3YZpJNSZkA8cOJHRp8eV j6YrnlGLYav6ZlN5JP/Z0qzTIKvr0BUDmKYCanmIiGQV49z/eZGpIU5z2EKeQhMpdGbK mKDiWHj44L234Oaw/XQck4wNc0Up8c1WLGd2WvCKYQaYKceZb9V1xIekopyo78/6RRm2 KM+SVnlR6Hu2qjxHEASnqKqL/zdf86nlgOi0FvnfJIfLJ4A9JZeCwOCwvs69t8hU9BOH jNZzgPrcgjTepGoijXDc7go2wkekQd89X/EqRpsIc5LYN0WLOK0fQOJY3qr/nwcMxKQK YcIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PFbi91tRiNGXeEmIHuQX11q7VviZ0SmNfg0DFyyfcmA=; b=crCZ8YKD8uowtXN2opZiG9zCuyuCBJavzunL2nZwnzqZ6nF5t/j+Ojp3btnv+VjGy6 Dv+c7qNycrXKcYvlg340LTDgFYr6bR3S8tEY4L11Z/QO2qil0NVjySigRkDhI4XR/AuN vXCYCeDcuTCN0i/O9rhkn1B6m+2Ej5xtQLOj8dOX7jC2nWDr8egf/IAfyexCzcrGC72S 3O0/eX15o82Q9bqhUsgi04NNHesyc4ZjDj+mQHWVEXDjAh3XY7rhqzhdor7zD8l9nqXC 5suyLLywS+wDdiks5uVBiDwHIKzyG8Vlgvx06PYaDIGnzzhVPkR/TSl0PiVaS6seSxSG PdbQ== X-Gm-Message-State: APjAAAUo2FXMSmfnsnrWfidPR8hoIZMPystIoTkchg8ZwphxeimNlf1M livCRIB7+cTxG1i8A3tzjghW5RmpFCxDrcjVSWDflQ== X-Google-Smtp-Source: APXvYqxEGiLqL/mHWYiYXOK5RmaH69paUsa45OKbuE6qs+TWsyzsFypnQAktWjrnNClceu+BddUPXayRQKAAwPUJvPI= X-Received: by 2002:a9d:7083:: with SMTP id l3mr22692044otj.193.1580854728157; Tue, 04 Feb 2020 14:18:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Tue, 4 Feb 2020 23:18:37 +0100 Message-ID: To: "Jakob Heitz (jheitz)" Cc: "Sriram, Kotikalapudi (Fed)" , Job Snijders , Nick Hilliard , John Heasly , "idr@ietf.org" , "grow-chairs@ietf.org" , "idr-chairs@ietf.org" , "grow@ietf.org" Content-Type: multipart/alternative; boundary="000000000000838225059dc76c9c" Archived-At: Subject: Re: [Idr] [GROW] Question about BGP Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 22:18:50 -0000 --000000000000838225059dc76c9c Content-Type: text/plain; charset="UTF-8" And you think 255 such known large communities will be sufficient ? Thx, R. On Tue, Feb 4, 2020 at 9:45 PM Jakob Heitz (jheitz) wrote: > A set of well known large communities could be useful. > > I have a draft that I never submitted attached to this email. > > Does anyone want to co-author and suggest changes? > > > > Regards, > > Jakob. > > > > *From:* Sriram, Kotikalapudi (Fed) > *Sent:* Tuesday, February 4, 2020 10:22 AM > *To:* Jakob Heitz (jheitz) ; Job Snijders ; > Nick Hilliard ; John Heasly > *Cc:* idr@ietf.org; grow@ietf.org; idr-chairs@ietf.org; > grow-chairs@ietf.org; a.e.azimov@gmail.com; Brian Dickson < > brian.peter.dickson@gmail.com> > *Subject:* Question about BGP Large Communities > > > > In the route leaks solution draft, > > > https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-02 > > we (the authors) have proposed using BGP Large Community. > > We specify this to be a "well-known transitive Large Community". > > > > Question: > > Can the draft simply make an IANA request for > > a Global Administrator ASN value for Route Leaks Protection (RLP) type > > and request that it be published in IANA registry > > as a "well-known Transitive Large Community"? > > > > There is no IANA registry for Large Communities yet; > > we have requested IDR and GROW Chairs to facilitate that. > > > > ---------------- > > Details/background: > > > > We've read the following RFCs related to Large Communities: > > https://tools.ietf.org/html/rfc8092 > > https://tools.ietf.org/html/rfc8195 > > > > RFC 8195 has this table: > > > +-------------------------------+-------------------------+ > > | RFC8092 | RFC > 8195 | > > > +-------------------------------+--------------------------+ > > | Global Administrator | ASN | > > | Local Data Part 1 | Function > | > > | Local Data Part 2 | Parameter | > > > +--------------------------------+-------------------------+ > > which is instructive. In the examples that RFC 8195 offers, > > it appears it is *assumed* that the Large Communities are transitive. > > > > For comparison, in Extended Communities (RFC 7153), there are > > explicit Type values assigned for Transitive, Non-transitive, etc. > > > https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml > > However, there is no such explicit Type specification > > for Large Communities (in RFC 8092 or elsewhere). > > > > Thank you. > > Sriram > > > > > > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > --000000000000838225059dc76c9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
And you think 255 such known large communities will be suf= ficient ?

Thx,
R.

On Tue, Feb 4, 2020 at = 9:45 PM Jakob Heitz (jheitz) <jheitz= @cisco.com> wrote:

A set of well known large communities = could be useful.

I have a draft that I never submitted = attached to this email.

Does anyone want to co-author and sugg= est changes?

=C2=A0

Regards,

Jakob.

=C2=A0

From: Sriram, Kotikalapudi (Fed) <kotikalapudi.sri= ram@nist.gov>
Sent: Tuesday, February 4, 2020 10:22 AM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>; Job Snijders <job@ntt.net>; Nick Hilliard <nick@foobar.org>; J= ohn Heasly <heas= @shrubbery.net>
Cc: idr@ietf.org; grow@ietf.org; <= a href=3D"mailto:idr-chairs@ietf.org" target=3D"_blank">idr-chairs@ietf.org= ; grow-chairs= @ietf.org; a.= e.azimov@gmail.com; Brian Dickson <brian.peter.dickson@gmail.com>
Subject: Question about BGP Large Communities

=C2=A0

In the route leaks solution draft,

https://tools.ietf.org/html/draft-ietf= -grow-route-leak-detection-mitigation-02

we (the authors) have proposed using BGP Large Community.<= /p>

We specify this to be a "well-known transitive Large Community"= ;.

=C2=A0

Question:

Can the draft simply make an IANA request for

a Global Administrator ASN value for Route Leaks Protection (RLP) type

and request that it be published in IANA registry

as a "well-known Transitive Large Community"?

=C2=A0

There is no IANA registry for Large Communities yet;

we have requested IDR and GROW Chairs to facilitate that.<= /p>

=C2=A0

----------------

Details/background:

=C2=A0

We've read the following RFCs related to Large Communities:

https://tools.ietf.org/html= /rfc8092

https://tools.ietf.org/html= /rfc8195

=C2=A0

RFC 8195 has this table:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+-------------------------------+------------= -------------+

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC8092=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | RFC 8195=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +-------------------------------+-----------------= ---------+

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 | Global Administrator=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 ASN=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 Local Data Part 1=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 Function=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 Local Data Part 2=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 Parameter=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0=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 is instructive. In the examples that RFC 8195 offers,

it appears it is *assumed* that the Large Communities are transitive.=

=C2=A0

For comparison, in Extended Communities (RFC 7153), there are

explicit Type values assigned for Transitive, Non-transitive, etc.

= https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-comm= unities.xhtml

However, there is no such explicit Type specification

for Large Communities (in RFC 8092 or elsewhere).

=C2=A0

Thank you.

Sriram

=C2=A0

=C2=A0

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

_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
--000000000000838225059dc76c9c-- From nobody Tue Feb 4 14:34:31 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC9D12001E; Tue, 4 Feb 2020 14:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.486 X-Spam-Level: X-Spam-Status: No, score=-14.486 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_ENHANCEMENT=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=M9deWVHn; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=b6+eIRjX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuLkvgu-CV6O; Tue, 4 Feb 2020 14:34:24 -0800 (PST) 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 954D412003F; Tue, 4 Feb 2020 14:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16763; q=dns/txt; s=iport; t=1580855664; x=1582065264; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=kbfrVR2mTykF0DmN0RTqdWlv/vWcTWEXuwZo4BEx4Fk=; b=M9deWVHn+cnpsr0OhZ8BKHM0u7+dpcREbUuT8bLkfmO9yIN4OtjCnjOe CiOGLBf8L7fOmQjwlWiGoITU5WyXS28xrV+xqv2fr/Oii2df7qh0LWJja UoSuH7KJ4Y2xi3VeIZzpbofthXxVR5P3HtVv/3C8y/TVek3c2NtHigqbp g=; IronPort-PHdr: =?us-ascii?q?9a23=3A5zXl2R9El6is8/9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/bR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVcyFBEznPtbhbjcxG4JJU1o2t3w=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D1EAD18Dle/5pdJa1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBJS9QBWxYIAQLKgqECoNGA4sCToIRgQGIYIlMhGKBQoEQA1Q?= =?us-ascii?q?JAQEBDAEBGAEMCAIBAYRAAheCICQ4EwIDDQEBBAEBAQIBBQRthTcMhWYBAQE?= =?us-ascii?q?BAwEBEBEdAQEsCwEPAgEIEQQBASgDAgICHwYLFAkIAQEEDgUUBweDBAGBfU0?= =?us-ascii?q?DLgEOohQCgTmIYnWBMoJ/AQEFgTMCg3gNC4IMAwaBOIwiGoFBP4ERJyCCFzU?= =?us-ascii?q?+ghtJAQEDgS0BEgFOCYJaMoIsjVASgjo7hWGJeY5yRAqCO4dJilCEKhuCSIx?= =?us-ascii?q?WhUCGKpdIgiiQCwIEAgQFAg4BAQWBaSJncXAVOyoBgkFQGA2OHQeDbIUUhT9?= =?us-ascii?q?0AoEninKBIgGBDwEB?= X-IronPort-AV: E=Sophos;i="5.70,403,1574121600"; d="scan'208,217";a="716686635" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Feb 2020 22:34:23 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 014MYN8D020136 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 4 Feb 2020 22:34:23 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 4 Feb 2020 16:34:22 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 4 Feb 2020 16:34:22 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 4 Feb 2020 16:34:22 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f04t++/ylwJLmxeu8FK2Z6PUJUpg9Xx9+/NPG6AibZUiZarGIVZ9wki/71cAcB6N5oqW6qYtIM5+1LsET3odEA+1qIf1xfnGYL9+wzqtSX1afHOhEHhlsFCNEUfi4F4T1HT/7pV/qliD6yq9LhljOKGqw5W+iWL+ZgnfeRyMVkHnwoZmUkRqV0lFfnpWDSGo+verjV7iSMZosnT68QpFF5yhvGpUzmO0oVKdsIpJmeQKbD4SUMxpr7JibLsHVeP0gacdtrQin5jmuenJqLOT99XhwUC9vL2uCBeDdlxunlvhzCx/d2NiwmULkXs3evM4B2s+3BI51IP1zG98SFWW4g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kbfrVR2mTykF0DmN0RTqdWlv/vWcTWEXuwZo4BEx4Fk=; b=iYjnMcIcyeSh313p01OpU8BvEsVs679p5gYZfVaU+mD0H0z0TM63EhV/LHvIN1/7c4zyDbSOFTsfjTsTlA9dJliyAo4FtsUzeb7hDOeaCk/0o5NCHMnZXPjxor9meIg5PP4RX7qf28tyz44Eu8N8dZ8yfQzM7Ufws+yOlYd9XrgEPxFglzF81eVDyPzhXHQ1lArGZ6IZ0QV+bKw7KrqGgMHx5m+SX44sONuTlUHft+392l40UIuBUMQqjbiRNnbtkEYGMG9ZyUn0KN/GYBxbKTHzTDxjmSD12CFg4sCeJN+Rec0DhvOf/Mtjjq9gPDy/UpZn8p5o7YzUlVlrA5YQrA== 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=kbfrVR2mTykF0DmN0RTqdWlv/vWcTWEXuwZo4BEx4Fk=; b=b6+eIRjXC8cHxg35y1nMQ9baH7mSzFL9MLMvONsLL65so570+jO2CZiO/v9ooEmoB0cKEtEfbagCBlzYjGedEoGLEpO+8sF1t23KRC4QWBNMtcnXK+kNgWfPWJaFwuSO5O6DgZuj5X40PsM3tPod6LphAVxQhretR+I1tXu48rc= Received: from MWHPR11MB1901.namprd11.prod.outlook.com (10.175.54.12) by MWHPR11MB1790.namprd11.prod.outlook.com (10.175.53.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.21; Tue, 4 Feb 2020 22:31:34 +0000 Received: from MWHPR11MB1901.namprd11.prod.outlook.com ([fe80::5109:65e6:5d:db41]) by MWHPR11MB1901.namprd11.prod.outlook.com ([fe80::5109:65e6:5d:db41%3]) with mapi id 15.20.2707.020; Tue, 4 Feb 2020 22:31:32 +0000 From: "Jakob Heitz (jheitz)" To: Robert Raszuk CC: "Sriram, Kotikalapudi (Fed)" , Job Snijders , Nick Hilliard , John Heasly , "idr@ietf.org" , "grow-chairs@ietf.org" , "idr-chairs@ietf.org" , "grow@ietf.org" Thread-Topic: [GROW] Question about BGP Large Communities Thread-Index: AdXbeNI4t0SppYFnSky8PqLGmuct1gAIu5NAAANSzYAAAHMiyg== Date: Tue, 4 Feb 2020 22:31:32 +0000 Message-ID: <5603F4C9-7ECD-4A9C-AF81-49AE292CEE83@cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jheitz@cisco.com; x-originating-ip: [128.107.241.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4526c5ea-8fb7-4924-6e21-08d7a9c1fca7 x-ms-traffictypediagnostic: MWHPR11MB1790: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(199004)(189003)(2906002)(186003)(2616005)(8936002)(8676002)(6486002)(81156014)(81166006)(76116006)(91956017)(66946007)(64756008)(66446008)(66476007)(66556008)(6512007)(966005)(26005)(498600001)(71200400001)(5660300002)(6506007)(53546011)(6916009)(4326008)(33656002)(86362001)(36756003)(54906003); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1790; H:MWHPR11MB1901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 66caOe0ZzO28AZVAgD8rlIg/reozS/KAJP6E3+V4mQITH4HgvoHMizgJ+OCqBc/INUUB/uHOSoB0fJtYENWFjGR6msMSNXq0ujIEsyuLmWHwbrUcK4g9WICA/mtsCtX6MgqCEHFExfJT/UYYD2a3e5H03rK3BW+xrMLHuzvu0Xgf5yWSKXP7bIje4Ak1PTlgygybc3BL/i7TZxqI2OQlc+O9IosIGM7fcEnavIxE9Bl4EPeQkHWONfiy4uWOMXpudS/XtQD+BN31MpMTRA5DbFIzUyXxpVb8nSv/LcH2UJj9XT/xDrL5v01M4g1YT6SfpgujVALM08N0DfBBHCLr7mVni9P0Ix+3quOfA3WAkX4BrBSHeN0XMRy1GGoebsbecWsH8j+lpG9Rl//r86NdVDCUOwtrL0PHxgpClIu3wRtNrBCfIRv1uXHk/b7u0MjU9OY571fOAFazl69n3M6hIz991ryoCWKxJwDxhNBIimgDjFaqruMccDjRDm91BbwCx6SHDaORGLOsB/hXPtUvDw== x-ms-exchange-antispam-messagedata: BMlT3vuislrOHRWubFpzcLf7YQ47foIeyVGTeejCU92ZszHaoB6fwFqdgIc38MnCH4HigcnSp1dnXEsutkyxl58KTbNSqt2L8VwpvTnOxiHZzL+ssFRHkNFAexsulYktQTcgeoAsa61U31dZFo7hlw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_5603F4C97ECD4A9CAF8149AE292CEE83ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4526c5ea-8fb7-4924-6e21-08d7a9c1fca7 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2020 22:31:32.0341 (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: tY1KygRoj2HruKYAtfqotvgqiAAId7GXNWHqmyu1ywCEOI5W6zzBF9NkPpRpnZIDvpYecn0MwE+fhcWbFr/Rcg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1790 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [Idr] [GROW] Question about BGP Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 22:34:28 -0000 --_000_5603F4C97ECD4A9CAF8149AE292CEE83ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIG51bWJlcnMgYXJlIGEgdHJhZGUgb2ZmLiBIb3cgd291bGQgeW91IGRpdmlkZSB0aGUgbnVt YmVycz8NCg0KVGhhbmtzLA0KSmFrb2IuDQoNCk9uIEZlYiA0LCAyMDIwLCBhdCAyOjE5IFBNLCBS b2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldD4gd3JvdGU6DQoNCu+7vw0KQW5kIHlvdSB0 aGluayAyNTUgc3VjaCBrbm93biBsYXJnZSBjb21tdW5pdGllcyB3aWxsIGJlIHN1ZmZpY2llbnQg Pw0KDQpUaHgsDQpSLg0KDQpPbiBUdWUsIEZlYiA0LCAyMDIwIGF0IDk6NDUgUE0gSmFrb2IgSGVp dHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb208bWFpbHRvOmpoZWl0ekBjaXNjby5jb20+PiB3 cm90ZToNCkEgc2V0IG9mIHdlbGwga25vd24gbGFyZ2UgY29tbXVuaXRpZXMgY291bGQgYmUgdXNl ZnVsLg0KSSBoYXZlIGEgZHJhZnQgdGhhdCBJIG5ldmVyIHN1Ym1pdHRlZCBhdHRhY2hlZCB0byB0 aGlzIGVtYWlsLg0KRG9lcyBhbnlvbmUgd2FudCB0byBjby1hdXRob3IgYW5kIHN1Z2dlc3QgY2hh bmdlcz8NCg0KUmVnYXJkcywNCkpha29iLg0KDQpGcm9tOiBTcmlyYW0sIEtvdGlrYWxhcHVkaSAo RmVkKSA8a290aWthbGFwdWRpLnNyaXJhbUBuaXN0LmdvdjxtYWlsdG86a290aWthbGFwdWRpLnNy aXJhbUBuaXN0Lmdvdj4+DQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSA0LCAyMDIwIDEwOjIyIEFN DQpUbzogSmFrb2IgSGVpdHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb208bWFpbHRvOmpoZWl0 ekBjaXNjby5jb20+PjsgSm9iIFNuaWpkZXJzIDxqb2JAbnR0Lm5ldDxtYWlsdG86am9iQG50dC5u ZXQ+PjsgTmljayBIaWxsaWFyZCA8bmlja0Bmb29iYXIub3JnPG1haWx0bzpuaWNrQGZvb2Jhci5v cmc+PjsgSm9obiBIZWFzbHkgPGhlYXNAc2hydWJiZXJ5Lm5ldDxtYWlsdG86aGVhc0BzaHJ1YmJl cnkubmV0Pj4NCkNjOiBpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz47IGdyb3dAaWV0 Zi5vcmc8bWFpbHRvOmdyb3dAaWV0Zi5vcmc+OyBpZHItY2hhaXJzQGlldGYub3JnPG1haWx0bzpp ZHItY2hhaXJzQGlldGYub3JnPjsgZ3Jvdy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmdyb3ctY2hh aXJzQGlldGYub3JnPjsgYS5lLmF6aW1vdkBnbWFpbC5jb208bWFpbHRvOmEuZS5hemltb3ZAZ21h aWwuY29tPjsgQnJpYW4gRGlja3NvbiA8YnJpYW4ucGV0ZXIuZGlja3NvbkBnbWFpbC5jb208bWFp bHRvOmJyaWFuLnBldGVyLmRpY2tzb25AZ21haWwuY29tPj4NClN1YmplY3Q6IFF1ZXN0aW9uIGFi b3V0IEJHUCBMYXJnZSBDb21tdW5pdGllcw0KDQoNCkluIHRoZSByb3V0ZSBsZWFrcyBzb2x1dGlv biBkcmFmdCwNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZ3Jvdy1y b3V0ZS1sZWFrLWRldGVjdGlvbi1taXRpZ2F0aW9uLTAyDQoNCndlICh0aGUgYXV0aG9ycykgaGF2 ZSBwcm9wb3NlZCB1c2luZyBCR1AgTGFyZ2UgQ29tbXVuaXR5Lg0KDQpXZSBzcGVjaWZ5IHRoaXMg dG8gYmUgYSAid2VsbC1rbm93biB0cmFuc2l0aXZlIExhcmdlIENvbW11bml0eSIuDQoNCg0KDQpR dWVzdGlvbjoNCg0KQ2FuIHRoZSBkcmFmdCBzaW1wbHkgbWFrZSBhbiBJQU5BIHJlcXVlc3QgZm9y DQoNCmEgR2xvYmFsIEFkbWluaXN0cmF0b3IgQVNOIHZhbHVlIGZvciBSb3V0ZSBMZWFrcyBQcm90 ZWN0aW9uIChSTFApIHR5cGUNCg0KYW5kIHJlcXVlc3QgdGhhdCBpdCBiZSBwdWJsaXNoZWQgaW4g SUFOQSByZWdpc3RyeQ0KDQphcyBhICJ3ZWxsLWtub3duIFRyYW5zaXRpdmUgTGFyZ2UgQ29tbXVu aXR5Ij8NCg0KDQoNClRoZXJlIGlzIG5vIElBTkEgcmVnaXN0cnkgZm9yIExhcmdlIENvbW11bml0 aWVzIHlldDsNCg0Kd2UgaGF2ZSByZXF1ZXN0ZWQgSURSIGFuZCBHUk9XIENoYWlycyB0byBmYWNp bGl0YXRlIHRoYXQuDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tDQoNCkRldGFpbHMvYmFja2dyb3Vu ZDoNCg0KDQoNCldlJ3ZlIHJlYWQgdGhlIGZvbGxvd2luZyBSRkNzIHJlbGF0ZWQgdG8gTGFyZ2Ug Q29tbXVuaXRpZXM6DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MDkyDQoNCmh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MTk1DQoNCg0KDQpSRkMgODE5NSBoYXMgdGhp cyB0YWJsZToNCg0KICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0KDQogICAgICAgICAgICAgICAgIHwgICAg ICAgUkZDODA5MiAgICAgICAgICAgICAgICAgICAgfCBSRkMgODE5NSAgICAgICAgICAgICAgICB8 DQoNCiAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCiAgICAgICAgICAgICAgICAgfCBHbG9iYWwgQWRt aW5pc3RyYXRvciAgICB8ICAgICAgQVNOICAgICAgICAgICAgICAgICAgICAgfA0KDQogICAgICAg ICAgICAgICAgIHwgIExvY2FsIERhdGEgUGFydCAxICAgICAgICAgICB8ICAgIEZ1bmN0aW9uICAg ICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICAgICAgfCAgTG9jYWwgRGF0YSBQYXJ0IDIgICAg ICAgICAgIHwgICBQYXJhbWV0ZXIgICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICAgICAgKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0r DQoNCndoaWNoIGlzIGluc3RydWN0aXZlLiBJbiB0aGUgZXhhbXBsZXMgdGhhdCBSRkMgODE5NSBv ZmZlcnMsDQoNCml0IGFwcGVhcnMgaXQgaXMgKmFzc3VtZWQqIHRoYXQgdGhlIExhcmdlIENvbW11 bml0aWVzIGFyZSB0cmFuc2l0aXZlLg0KDQoNCg0KRm9yIGNvbXBhcmlzb24sIGluIEV4dGVuZGVk IENvbW11bml0aWVzIChSRkMgNzE1MyksIHRoZXJlIGFyZQ0KDQpleHBsaWNpdCBUeXBlIHZhbHVl cyBhc3NpZ25lZCBmb3IgVHJhbnNpdGl2ZSwgTm9uLXRyYW5zaXRpdmUsIGV0Yy4NCg0KaHR0cHM6 Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvYmdwLWV4dGVuZGVkLWNvbW11bml0aWVzL2JncC1l eHRlbmRlZC1jb21tdW5pdGllcy54aHRtbA0KDQpIb3dldmVyLCB0aGVyZSBpcyBubyBzdWNoIGV4 cGxpY2l0IFR5cGUgc3BlY2lmaWNhdGlvbg0KDQpmb3IgTGFyZ2UgQ29tbXVuaXRpZXMgKGluIFJG QyA4MDkyIG9yIGVsc2V3aGVyZSkuDQoNCg0KDQpUaGFuayB5b3UuDQoNClNyaXJhbQ0KDQoNCg0K DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K R1JPVyBtYWlsaW5nIGxpc3QNCkdST1dAaWV0Zi5vcmc8bWFpbHRvOkdST1dAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2dyb3cNCg== --_000_5603F4C97ECD4A9CAF8149AE292CEE83ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpU aGUgbnVtYmVycyBhcmUgYSB0cmFkZSBvZmYuIEhvdyB3b3VsZCB5b3UgZGl2aWRlIHRoZSBudW1i ZXJzPzxicj4NCjxicj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj5UaGFua3MsPC9kaXY+DQpKYWtv Yi48L2Rpdj4NCjxkaXYgZGlyPSJsdHIiPjxicj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPk9u IEZlYiA0LCAyMDIwLCBhdCAyOjE5IFBNLCBSb2JlcnQgUmFzenVrICZsdDtyb2JlcnRAcmFzenVr Lm5ldCZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSB0eXBlPSJjaXRlIj4NCjxkaXYgZGlyPSJsdHIiPu+7vw0KPGRpdiBkaXI9Imx0ciI+QW5k IHlvdSB0aGluayAyNTUgc3VjaCBrbm93biBsYXJnZSBjb21tdW5pdGllcyB3aWxsIGJlIHN1ZmZp Y2llbnQgPw0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGh4LDwvZGl2Pg0KPGRpdj5SLjwvZGl2 Pg0KPC9kaXY+DQo8YnI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+DQo8ZGl2IGRpcj0ibHRy IiBjbGFzcz0iZ21haWxfYXR0ciI+T24gVHVlLCBGZWIgNCwgMjAyMCBhdCA5OjQ1IFBNIEpha29i IEhlaXR6IChqaGVpdHopICZsdDs8YSBocmVmPSJtYWlsdG86amhlaXR6QGNpc2NvLmNvbSI+amhl aXR6QGNpc2NvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgY2xh c3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4O2JvcmRlci1s ZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBs YW5nPSJFTi1VUyI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJn YigxMTIsNDgsMTYwKSI+QSBzZXQgb2Ygd2VsbCBrbm93biBsYXJnZSBjb21tdW5pdGllcyBjb3Vs ZCBiZSB1c2VmdWwuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOnJnYigxMTIsNDgsMTYwKSI+SSBoYXZlIGEgZHJhZnQgdGhhdCBJIG5l dmVyIHN1Ym1pdHRlZCBhdHRhY2hlZCB0byB0aGlzIGVtYWlsLjx1PjwvdT48dT48L3U+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpyZ2IoMTEyLDQ4LDE2MCki PkRvZXMgYW55b25lIHdhbnQgdG8gY28tYXV0aG9yIGFuZCBzdWdnZXN0IGNoYW5nZXM/PHU+PC91 Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOnJn YigxMTIsNDgsMTYwKSI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpyZ2IoMTEyLDQ4LDE2MCkiPlJlZ2FyZHMs PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOnJnYigxMTIsNDgsMTYwKSI+SmFrb2IuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6cmdiKDExMiw0OCwxNjApIj48 dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy LXJpZ2h0Om5vbmU7Ym9yZGVyLWJvdHRvbTpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLXRv cDoxcHQgc29saWQgcmdiKDIyNSwyMjUsMjI1KTtwYWRkaW5nOjNwdCAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBTcmlyYW0sIEtvdGlrYWxhcHVkaSAoRmVkKSAm bHQ7PGEgaHJlZj0ibWFpbHRvOmtvdGlrYWxhcHVkaS5zcmlyYW1AbmlzdC5nb3YiIHRhcmdldD0i X2JsYW5rIj5rb3Rpa2FsYXB1ZGkuc3JpcmFtQG5pc3QuZ292PC9hPiZndDsNCjxicj4NCjxiPlNl bnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSA0LCAyMDIwIDEwOjIyIEFNPGJyPg0KPGI+VG86PC9i PiBKYWtvYiBIZWl0eiAoamhlaXR6KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpoZWl0ekBjaXNjby5j b20iIHRhcmdldD0iX2JsYW5rIj5qaGVpdHpAY2lzY28uY29tPC9hPiZndDs7IEpvYiBTbmlqZGVy cyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvYkBudHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+am9iQG50 dC5uZXQ8L2E+Jmd0OzsgTmljayBIaWxsaWFyZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5pY2tAZm9v YmFyLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm5pY2tAZm9vYmFyLm9yZzwvYT4mZ3Q7Ow0KIEpvaG4g SGVhc2x5ICZsdDs8YSBocmVmPSJtYWlsdG86aGVhc0BzaHJ1YmJlcnkubmV0IiB0YXJnZXQ9Il9i bGFuayI+aGVhc0BzaHJ1YmJlcnkubmV0PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9 Im1haWx0bzppZHJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZHJAaWV0Zi5vcmc8L2E+OyA8 YSBocmVmPSJtYWlsdG86Z3Jvd0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZ3Jvd0BpZXRm Lm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzppZHItY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+aWRyLWNoYWlyc0BpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86Z3Jvdy1jaGFp cnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5ncm93LWNoYWlyc0BpZXRmLm9yZzwvYT47IDxh IGhyZWY9Im1haWx0bzphLmUuYXppbW92QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KYS5l LmF6aW1vdkBnbWFpbC5jb208L2E+OyBCcmlhbiBEaWNrc29uICZsdDs8YSBocmVmPSJtYWlsdG86 YnJpYW4ucGV0ZXIuZGlja3NvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5icmlhbi5wZXRl ci5kaWNrc29uQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFF1ZXN0aW9u IGFib3V0IEJHUCBMYXJnZSBDb21tdW5pdGllczx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9wPg0KPHA+ SW4gdGhlIHJvdXRlIGxlYWtzIHNvbHV0aW9uIGRyYWZ0LCA8dT48L3U+PHU+PC91PjwvcD4NCjxw PjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWdyb3ctcm91 dGUtbGVhay1kZXRlY3Rpb24tbWl0aWdhdGlvbi0wMiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWdyb3ctcm91dGUtbGVhay1kZXRlY3Rpb24t bWl0aWdhdGlvbi0wMjwvYT48dT48L3U+PHU+PC91PjwvcD4NCjxwPndlICh0aGUgYXV0aG9ycykg aGF2ZSBwcm9wb3NlZCB1c2luZyBCR1AgTGFyZ2UgQ29tbXVuaXR5Ljx1PjwvdT48dT48L3U+PC9w Pg0KPHA+V2Ugc3BlY2lmeSB0aGlzIHRvIGJlIGEgJnF1b3Q7d2VsbC1rbm93biB0cmFuc2l0aXZl IExhcmdlIENvbW11bml0eSZxdW90Oy48dT48L3U+PHU+PC91PjwvcD4NCjxwPjx1PjwvdT4mbmJz cDs8dT48L3U+PC9wPg0KPHA+UXVlc3Rpb246IDx1PjwvdT48dT48L3U+PC9wPg0KPHA+Q2FuIHRo ZSBkcmFmdCBzaW1wbHkgbWFrZSBhbiBJQU5BIHJlcXVlc3QgZm9yIDx1PjwvdT48dT48L3U+PC9w Pg0KPHA+YSBHbG9iYWwgQWRtaW5pc3RyYXRvciBBU04gdmFsdWUgZm9yIFJvdXRlIExlYWtzIFBy b3RlY3Rpb24gKFJMUCkgdHlwZSA8dT48L3U+PHU+PC91PjwvcD4NCjxwPmFuZCByZXF1ZXN0IHRo YXQgaXQgYmUgcHVibGlzaGVkIGluIElBTkEgcmVnaXN0cnkgPHU+PC91Pjx1PjwvdT48L3A+DQo8 cD5hcyBhICZxdW90O3dlbGwta25vd24gVHJhbnNpdGl2ZSBMYXJnZSBDb21tdW5pdHkmcXVvdDs/ PHU+PC91Pjx1PjwvdT48L3A+DQo8cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjxwPlRoZXJl IGlzIG5vIElBTkEgcmVnaXN0cnkgZm9yIExhcmdlIENvbW11bml0aWVzIHlldDs8dT48L3U+PHU+ PC91PjwvcD4NCjxwPndlIGhhdmUgcmVxdWVzdGVkIElEUiBhbmQgR1JPVyBDaGFpcnMgdG8gZmFj aWxpdGF0ZSB0aGF0Ljx1PjwvdT48dT48L3U+PC9wPg0KPHA+PHU+PC91PiZuYnNwOzx1PjwvdT48 L3A+DQo8cD4tLS0tLS0tLS0tLS0tLS0tPHU+PC91Pjx1PjwvdT48L3A+DQo8cD5EZXRhaWxzL2Jh Y2tncm91bmQ6PHU+PC91Pjx1PjwvdT48L3A+DQo8cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4N CjxwPldlJ3ZlIHJlYWQgdGhlIGZvbGxvd2luZyBSRkNzIHJlbGF0ZWQgdG8gTGFyZ2UgQ29tbXVu aXRpZXM6PHU+PC91Pjx1PjwvdT48L3A+DQo8cD48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjODA5MiIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjODA5Mjwvc3Bhbj48L2E+PHU+PC91Pjx1PjwvdT48L3A+DQo8cD48YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODE5NSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxl PSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjODE5NTwvc3Bhbj48L2E+PHU+PC91Pjx1PjwvdT48L3A+DQo8cD48dT48 L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjxwPlJGQyA4MTk1IGhhcyB0aGlzIHRhYmxlOiA8dT48L3U+ PHU+PC91PjwvcD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSYjNDM7PHU+PC91Pjx1PjwvdT48L3A+DQo8cD4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBSRkM4MDkyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHwgUkZDIDgxOTUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fDx1PjwvdT48dT48L3U+PC9wPg0KPHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0mIzQzOzx1PjwvdT48dT48L3U+PC9wPg0KPHA+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwgR2xvYmFsIEFkbWluaXN0cmF0b3ImbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBU04mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDx1 PjwvdT48dT48L3U+PC9wPg0KPHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsgTG9jYWwgRGF0YSBQYXJ0IDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyBGdW5j dGlvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PHU+PC91Pjx1PjwvdT48L3A+DQo8cD4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBMb2NhbCBEYXRhIFBhcnQg MiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8Jm5ic3A7Jm5ic3A7IFBhcmFtZXRlciZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PHU+PC91Pjx1PjwvdT48L3A+ DQo8cD4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYj NDM7PHU+PC91Pjx1PjwvdT48L3A+DQo8cD53aGljaCBpcyBpbnN0cnVjdGl2ZS4gSW4gdGhlIGV4 YW1wbGVzIHRoYXQgUkZDIDgxOTUgb2ZmZXJzLDx1PjwvdT48dT48L3U+PC9wPg0KPHA+aXQgYXBw ZWFycyBpdCBpcyAqYXNzdW1lZCogdGhhdCB0aGUgTGFyZ2UgQ29tbXVuaXRpZXMgYXJlIHRyYW5z aXRpdmUuPHU+PC91Pjx1PjwvdT48L3A+DQo8cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjxw PkZvciBjb21wYXJpc29uLCBpbiBFeHRlbmRlZCBDb21tdW5pdGllcyAoUkZDIDcxNTMpLCB0aGVy ZSBhcmUgPHU+PC91Pjx1PjwvdT48L3A+DQo8cD5leHBsaWNpdCBUeXBlIHZhbHVlcyBhc3NpZ25l ZCBmb3IgVHJhbnNpdGl2ZSwgTm9uLXRyYW5zaXRpdmUsIGV0Yy48dT48L3U+PHU+PC91PjwvcD4N CjxwPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWFuYS5v cmcvYXNzaWdubWVudHMvYmdwLWV4dGVuZGVkLWNvbW11bml0aWVzL2JncC1leHRlbmRlZC1jb21t dW5pdGllcy54aHRtbCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2ln bm1lbnRzL2JncC1leHRlbmRlZC1jb21tdW5pdGllcy9iZ3AtZXh0ZW5kZWQtY29tbXVuaXRpZXMu eGh0bWw8L2E+PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHA+SG93ZXZlciwgdGhlcmUgaXMg bm8gc3VjaCBleHBsaWNpdCBUeXBlIHNwZWNpZmljYXRpb24gPHU+PC91Pjx1PjwvdT48L3A+DQo8 cD5mb3IgTGFyZ2UgQ29tbXVuaXRpZXMgKGluIFJGQyA4MDkyIG9yIGVsc2V3aGVyZSkuPHU+PC91 Pjx1PjwvdT48L3A+DQo8cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjxwPlRoYW5rIHlvdS48 dT48L3U+PHU+PC91PjwvcD4NCjxwPlNyaXJhbTx1PjwvdT48dT48L3U+PC9wPg0KPHA+PHU+PC91 PiZuYnNwOzx1PjwvdT48L3A+DQo8cD48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjxwPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkdST1cgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkdST1dAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5HUk9XQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZ3JvdyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ncm93PC9hPjxicj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_5603F4C97ECD4A9CAF8149AE292CEE83ciscocom_-- From nobody Tue Feb 4 14:37:58 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4CC120143 for ; Tue, 4 Feb 2020 14:37:54 -0800 (PST) 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, BODY_ENHANCEMENT=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (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 qsZivfnXaldh for ; Tue, 4 Feb 2020 14:37:52 -0800 (PST) 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 58DBB12013C for ; Tue, 4 Feb 2020 14:37:52 -0800 (PST) Received: by mail-ot1-x336.google.com with SMTP id g64so42048otb.13 for ; Tue, 04 Feb 2020 14:37:52 -0800 (PST) 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=qP6dtK41LqVx/9UQP7UmWU30oeno3hj6pqm/PUjx/jk=; b=ZfuWgJvYehYo+AJpkcrtqcQ9vYnr0qHCV8TvL2r4yhxRyFq5adzSQVDSWJ3xDJXL9z QYFmfD1tDMwIzQDYmUy47LNCgZNxZo4+76B5ZDwXVs8Z36kVWY7feJ/7nfGtuWo+LDut lJiBVKKXyb9Ni1wxSD3XGMcDBVq2+XrEx+/sLE7TypeIHXH1qC9pXpXZG72TMpFnsFC2 rUvopPUIt9XhAuXT7cu5LbXsJbI9e0NQElNgZh1qyG8Tey2sqVLrTaBYSQLJsLxPSkS7 jIuawlcjRSYG059st2RM3Q17+G9+NZbpEbpdQAy54lTz4VX3HJROZgRvJPwm8Vaxot2t 7k0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qP6dtK41LqVx/9UQP7UmWU30oeno3hj6pqm/PUjx/jk=; b=oyWnTFlbCZBgwYfn0KhT9MA0F5/Wrv0q12jDjGvnmdUZ1K4E3G38VuxDREU+NamcU3 7LLWqMr12iYAUWQbF2tclds8+3yHecK1clywMjbaksTazv0XJwr5ypVPeXbWThM4U5KE avxskMHTsBexeAlBpplB8162M64dLZM7UTSZuF/I5urM42+ljZ1h8OZTYTzICdGNmLfc sX5I40LBA0N/d/NYiY7vgoU9Ry40THTT0dAbVeyn5PXFlBXRlJCXpohCoyA29uC/RapA 9mogj77C1+pGaQz6JxiVV4YO/O7iIUM81YO9jRd1qFUBpjYrWxAKiCwFxWqoWn2Ti6l7 sjRA== X-Gm-Message-State: APjAAAVOTVDayyUVZCgDVchD6CkhckvJBBAZvyuAH4zqzmQ/qJUJJ92s pdMUNok5Bs60JokeV4h9gkMJ/BuKaL/QX5Qm8OD4jw== X-Google-Smtp-Source: APXvYqyuWmLDN997Aws7lKql7bC7vr4TPFVfOScWPfS2oVjp/zKGAFrm0H6X9hy/sXYBnInjDbzV3uu9cP9sbfzhcqk= X-Received: by 2002:a9d:6a06:: with SMTP id g6mr1523598otn.305.1580855871668; Tue, 04 Feb 2020 14:37:51 -0800 (PST) MIME-Version: 1.0 References: <5603F4C9-7ECD-4A9C-AF81-49AE292CEE83@cisco.com> In-Reply-To: <5603F4C9-7ECD-4A9C-AF81-49AE292CEE83@cisco.com> From: Robert Raszuk Date: Tue, 4 Feb 2020 23:37:41 +0100 Message-ID: To: "Jakob Heitz (jheitz)" Cc: "Sriram, Kotikalapudi (Fed)" , Job Snijders , Nick Hilliard , John Heasly , "idr@ietf.org" , "grow-chairs@ietf.org" , "idr-chairs@ietf.org" , "grow@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ac14b2059dc7b064" Archived-At: Subject: Re: [Idr] [GROW] Question about BGP Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 22:37:55 -0000 --000000000000ac14b2059dc7b064 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > How would you divide the numbers? I would not divide them at all in LCs. I would either define new type in extended communities or use wide communities. But I am a bit biased here ;-) Best, R, On Tue, Feb 4, 2020 at 11:34 PM Jakob Heitz (jheitz) wrote: > The numbers are a trade off. How would you divide the numbers? > > Thanks, > Jakob. > > On Feb 4, 2020, at 2:19 PM, Robert Raszuk wrote: > > =EF=BB=BF > And you think 255 such known large communities will be sufficient ? > > Thx, > R. > > On Tue, Feb 4, 2020 at 9:45 PM Jakob Heitz (jheitz) > wrote: > >> A set of well known large communities could be useful. >> >> I have a draft that I never submitted attached to this email. >> >> Does anyone want to co-author and suggest changes? >> >> >> >> Regards, >> >> Jakob. >> >> >> >> *From:* Sriram, Kotikalapudi (Fed) >> *Sent:* Tuesday, February 4, 2020 10:22 AM >> *To:* Jakob Heitz (jheitz) ; Job Snijders ; >> Nick Hilliard ; John Heasly >> *Cc:* idr@ietf.org; grow@ietf.org; idr-chairs@ietf.org; >> grow-chairs@ietf.org; a.e.azimov@gmail.com; Brian Dickson < >> brian.peter.dickson@gmail.com> >> *Subject:* Question about BGP Large Communities >> >> >> >> In the route leaks solution draft, >> >> >> https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigat= ion-02 >> >> we (the authors) have proposed using BGP Large Community. >> >> We specify this to be a "well-known transitive Large Community". >> >> >> >> Question: >> >> Can the draft simply make an IANA request for >> >> a Global Administrator ASN value for Route Leaks Protection (RLP) type >> >> and request that it be published in IANA registry >> >> as a "well-known Transitive Large Community"? >> >> >> >> There is no IANA registry for Large Communities yet; >> >> we have requested IDR and GROW Chairs to facilitate that. >> >> >> >> ---------------- >> >> Details/background: >> >> >> >> We've read the following RFCs related to Large Communities: >> >> https://tools.ietf.org/html/rfc8092 >> >> https://tools.ietf.org/html/rfc8195 >> >> >> >> RFC 8195 has this table: >> >> >> +-------------------------------+----------------------= ---+ >> >> | RFC8092 | RFC >> 8195 | >> >> >> +-------------------------------+--------------------------+ >> >> | Global Administrator | ASN >> | >> >> | Local Data Part 1 | >> Function | >> >> | Local Data Part 2 | Parameter = | >> >> >> +--------------------------------+-------------------------+ >> >> which is instructive. In the examples that RFC 8195 offers, >> >> it appears it is *assumed* that the Large Communities are transitive. >> >> >> >> For comparison, in Extended Communities (RFC 7153), there are >> >> explicit Type values assigned for Transitive, Non-transitive, etc. >> >> >> https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-c= ommunities.xhtml >> >> However, there is no such explicit Type specification >> >> for Large Communities (in RFC 8092 or elsewhere). >> >> >> >> Thank you. >> >> Sriram >> >> >> >> >> >> >> _______________________________________________ >> GROW mailing list >> GROW@ietf.org >> https://www.ietf.org/mailman/listinfo/grow >> > --000000000000ac14b2059dc7b064 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> How would you divide the numbers?=C2= =A0=C2=A0

I would not divide them at all in=C2=A0LCs. I = would either define new type in extended communities or use wide communitie= s.=C2=A0

But I am a bit biased here ;-)
=
Best,
R,

On Tue, Feb 4, 2020 at 11:34 PM Jako= b Heitz (jheitz) <jheitz@cisco.com> wrote:
The numbers are a trade off. How would you divide the numbers?

Thanks,
Jakob.
=EF=BB=BF
And you think 255 such known large communities will be suf= ficient ?

Thx,
R.

On Tue, Feb 4, 2020 at 9:45 PM Jakob = Heitz (jheitz) <jh= eitz@cisco.com> wrote:

A set of well known large communities = could be useful.

I have a draft that I never submitted = attached to this email.

Does anyone want to co-author and sugg= est changes?

=C2=A0

Regards,

Jakob.

=C2=A0

From: Sriram, Kotikalapudi (Fed) <kotikalapudi.sri= ram@nist.gov>
Sent: Tuesday, February 4, 2020 10:22 AM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>; Job Snijders <job@ntt.net>; Nick Hilliard <nick@foobar.org>; John Heasly <he= as@shrubbery.net>
Cc: idr@ietf.org; grow@ietf.org; idr-chairs@ietf.org; grow-chairs@ietf.= org; a.e.azimov@gmail.com; Brian Dickson <brian.peter.dickson@gmail.com> Subject: Question about BGP Large Communities

=C2=A0

In the route leaks solution draft,

https://tools.ietf.org/html/draft-ietf= -grow-route-leak-detection-mitigation-02

we (the authors) have proposed using BGP Large Community.<= /p>

We specify this to be a "well-known transitive Large Community"= ;.

=C2=A0

Question:

Can the draft simply make an IANA request for

a Global Administrator ASN value for Route Leaks Protection (RLP) type <= u>

and request that it be published in IANA registry

as a "well-known Transitive Large Community"?

=C2=A0

There is no IANA registry for Large Communities yet;

we have requested IDR and GROW Chairs to facilitate that.<= /p>

=C2=A0

----------------

Details/background:

=C2=A0

We've read the following RFCs related to Large Communities:

https://tools.ietf.org/html= /rfc8092

https://tools.ietf.org/html= /rfc8195

=C2=A0

RFC 8195 has this table:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+-------------------------------+------------= -------------+

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC8092=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | RFC 8195=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 +-------------------------------+-----------------= ---------+

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 | Global Administrator=C2=A0=C2=A0=C2=A0 |=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 ASN=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 Local Data Part 1=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 Function=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 Local Data Part 2=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 Parameter=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0=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 is instructive. In the examples that RFC 8195 offers,

it appears it is *assumed* that the Large Communities are transitive.=

=C2=A0

For comparison, in Extended Communities (RFC 7153), there are =

explicit Type values assigned for Transitive, Non-transitive, etc.

= https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-comm= unities.xhtml

However, there is no such explicit Type specification

for Large Communities (in RFC 8092 or elsewhere).

=C2=A0

Thank you.

Sriram

=C2=A0

=C2=A0

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

_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
--000000000000ac14b2059dc7b064-- From nobody Tue Feb 4 14:51:04 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368F3120152; Tue, 4 Feb 2020 12:45:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.488 X-Spam-Level: X-Spam-Status: No, score=-14.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_ENHANCEMENT=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=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=R+uNP7wU; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QkISP9sJ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocV3cBXkqJRe; Tue, 4 Feb 2020 12:45:46 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A5D812011A; Tue, 4 Feb 2020 12:45:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24754; q=dns/txt; s=iport; t=1580849145; x=1582058745; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=w3bXyPOzk7bG/slkkNM1lEcM66eTFE4uP/fYEOvJ2+g=; b=R+uNP7wUuvL3lAoYPnMB7wBWPKojr2kWSJxFEpBJX0caiRyQli0nW7l/ /4+Z+JWJ7NvorVearaYVxPcpjuLyvzleBrGmoU2vsM54wVMDbAo7DhuZi hBSM36R3q9/48dZIKz9eMHAmuEjxSyNT65838qf9CVOQ5fLK9hrSVcxHm M=; X-Files: draft-heitz-idr-wklc-00.txt : 8102 X-IPAS-Result: =?us-ascii?q?A0BMAABM1zle/5pdJa1lGgEBAQEBAQEBAQMBAQEBEQEBA?= =?us-ascii?q?QICAQEBAYFqAgEBAQELAYEkLyQFJwVsWCAECyoKh1ADiwGCX4lhiUyEYoFCg?= =?us-ascii?q?RADVAIHAQEBDAEBJQgCAQGBTIJ0AoI3JDcGDgIDAQEBAwIDAQEBAQQBAQECA?= =?us-ascii?q?QUEbYU3DIVmAQEBAQMSGxMBATIFAQ8CAQgRBAEBLwIfER0IAQEEAQkEBQgGB?= =?us-ascii?q?gcHgwUqAYIfAy4BDqIlAoE5iGKCJ4J/AQEFgTMCg2MNC4IFBwMGgTgBjCEag?= =?us-ascii?q?UE/gRFHgkw+ghtJAQEDgSUIARIBIxUWgxWCLI1QEoI6hhyBEohnjnJECoI7g?= =?us-ascii?q?2yCOYEkiXRchEWCSDCHXoRIigSBZo5hgUuHHIIokAsCBAIEBQIOAQEFgWgjZ?= =?us-ascii?q?3FwFTuCbFAYDY4dB4NshRSFP3QCMHeKYQUMF4ELAYEPAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AnWMMiBQw3bgZBUtdUTgpe94vp9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESUDNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOi46EcVeRndu/mqwNg5eH8OtLwSI8Ge/5jMTBB?= =?us-ascii?q?jzcBFtKLSpSKjVicn/l/io/IHeaBlJgzz7Zq5uKBKxrkPascxEyYBjMa02jB?= =?us-ascii?q?DOpzNEfOlNjWVvORqfkg396cG54JMGkWxItugk9tJcXKmyZKk+QbFCRDQhKH?= =?us-ascii?q?wupcA=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.70,403,1574121600"; d="txt'?scan'208,217";a="406697543" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Feb 2020 20:45:44 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 014Kji8E002742 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 4 Feb 2020 20:45:44 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 4 Feb 2020 14:45:43 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 4 Feb 2020 14:45:43 -0600 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 4 Feb 2020 14:45:43 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=f+jdDFS6uVDo+ciVQtyaclcQiaygK1s8eQJGQlKKTKOYRp7N48fGXwuqegF3tyypkzicQkV3CPFG2gOJSOi8ZA7rFRa87sLvwLhAf+j6T3qoOvy6VlUnuUoDcHSvsjurGrO6ZfdOhVvj/ljHmhWFDvxEe693rk7vPOBG+2NNDUECCpnZxjXsCYbHrDgzv5HLeSTHwBlo5NHxXCz1Lo9MF6268aDak7GWx8o1Rf+FSrcy1f6vWO7/wP/RJbid9LOeeHhlFMBbwZe5ejSS621iNhEStP7uUMPb3gFcXL8SIeg2xxuyv3n9VXsad2KBXbUKAVbg4mW4WzMhkSN/JNO4zw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=bzPzlOIer4ABXXn0OamNoshU84Yk6Vnuo9NdpjNNwFI=; b=SgYVNB0vN+iRSdRJSAxgAQF8IubRpEyVIPvMsyIMB74BgEMP9Wx6nAz7LHFpeyevcG5oztL3sfx8UpE4ZVZsLJUAEHJVp4mZtMzHPMDni3SxbSkD9ifD5ywDyj7eHioZyrfzCTC/CEWHMDpoGeANmQgQWT4PJAs3YaLpIbhAVs1xdsxL0ZFVxNW1Iof59qr770WxMDDsFrCsuSVTzKILAt5O7GbSY1I6bKbtK7wiJh1jgidUphDSkl7XE+kZFnxmtxNiPxZ+yWvJJiReUVYXi+X0Z6aN0duB18np14aZ598wNcgJl7bhkhezDe1nU2cGM7ULIYqkxcxQ+L66RUHyeQ== 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=bzPzlOIer4ABXXn0OamNoshU84Yk6Vnuo9NdpjNNwFI=; b=QkISP9sJEVfpC53ulnUXK1P26GD1bafvH4RVhBLHA5IqBOex9Y8j6Bg1kt46UZeaqjEOWV4rWvyR/thPMCZpikhBVWrUT1KPaSLGPIo4fQ8lR9WTcqHxCB/zSheCimejiBzy7Z2uaMKWhpbkB09Avh1eyBmxAGUDyVfv/VpoHs0= Received: from BN6PR11MB1890.namprd11.prod.outlook.com (10.175.101.13) by BN6PR11MB4019.namprd11.prod.outlook.com (10.255.128.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.29; Tue, 4 Feb 2020 20:45:41 +0000 Received: from BN6PR11MB1890.namprd11.prod.outlook.com ([fe80::249a:1b6:689d:3fcf]) by BN6PR11MB1890.namprd11.prod.outlook.com ([fe80::249a:1b6:689d:3fcf%5]) with mapi id 15.20.2686.030; Tue, 4 Feb 2020 20:45:41 +0000 From: "Jakob Heitz (jheitz)" To: "Sriram, Kotikalapudi (Fed)" , Job Snijders , Nick Hilliard , John Heasly CC: "idr@ietf.org" , "grow@ietf.org" , "idr-chairs@ietf.org" , "grow-chairs@ietf.org" , "a.e.azimov@gmail.com" , "Brian Dickson" Thread-Topic: Question about BGP Large Communities Thread-Index: AdXbeNI4t0SppYFnSky8PqLGmuct1gAIu5NA Date: Tue, 4 Feb 2020 20:45:40 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jheitz@cisco.com; x-originating-ip: [128.107.241.189] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 768f456c-d545-498b-d4d4-08d7a9b332bf x-ms-traffictypediagnostic: BN6PR11MB4019: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 03030B9493 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(136003)(376002)(396003)(39860400002)(199004)(189003)(86362001)(4326008)(76116006)(7416002)(71200400001)(81166006)(81156014)(8676002)(966005)(478600001)(66616009)(9686003)(55016002)(66946007)(6506007)(53546011)(33656002)(26005)(2906002)(186003)(8936002)(7696005)(316002)(110136005)(54906003)(64756008)(66446008)(52536014)(66556008)(66476007)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR11MB4019; H:BN6PR11MB1890.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 1DWj+4SBqhZrOdfRBbfpH4gN680xRW/06Wt9rhgsiZ+dl79VX4QbjuV+sk3233VI3XvQ7AgENWP0pHeCLecTaDCOvKJw7gwSM0O6RqqxVLKwGDoffaUsVJ1QAvwwCAYt6i/X8nek6XXPYzlYCqLg1BAc3YM+C5rHj1dOm3aa3cWW7ubgUKVmsLzblT+5NZqYe/t7WzIagxZEQ9GUmW09VktNS+OIa/EG0lIUSw3iwLPJialJhSHscb7WbcXabDjpGPKRVPqjgHBTu7TqFKZu/8Lr4cfTsK1bGE+IMpcEQgyiqMwb9JByjA3zJQg9UpF0a5lnPY95Dmzun93265RkPamS6fzZ9U/Tm+XeVu/G1U7uYgOdYPD4NntyRAI1AvgpwHpbKEfefw0mWw+m3tS6G0nf0rxT4qM6KH0UnZuxXbgr9c/pUibYqM24LFc5gpk44CRZVvsNTfZMgzhmbUSfbKLrdNN/DPIYI94clJuOZyGRjXxjIGa4RXE2ZOE923mLQq3PbIsIPPMhaGOczYTTxQ== x-ms-exchange-antispam-messagedata: WnxfSCWD84SPv2R9ZTwXdkPqSVcaQ71OK9QjDOlJwpg9nJyPT/x0sEfnvSL5F39zAErb/SihfXYXD2abVNG/coBUfboukcixMCo64ebHa8E5MZo8ZlDreMqI7x+2ziGVQUOPEIiipFl8AiMYJwCVDA== x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_004_BN6PR11MB1890AA431F63030DFE310902C0030BN6PR11MB1890namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 768f456c-d545-498b-d4d4-08d7a9b332bf X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Feb 2020 20:45:41.0737 (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: whVzcPfNShY9kMO71YyAyIC1xzVLYeMcryL7LamzFNzkF7+vZMVxoX8oAYFZJc71acd6oBJGeUv+FwGbt0xeFQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB4019 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: X-Mailman-Approved-At: Tue, 04 Feb 2020 14:51:03 -0800 Subject: Re: [Idr] Question about BGP Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 20:45:49 -0000 --_004_BN6PR11MB1890AA431F63030DFE310902C0030BN6PR11MB1890namp_ Content-Type: multipart/alternative; boundary="_000_BN6PR11MB1890AA431F63030DFE310902C0030BN6PR11MB1890namp_" --_000_BN6PR11MB1890AA431F63030DFE310902C0030BN6PR11MB1890namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A set of well known large communities could be useful. I have a draft that I never submitted attached to this email. Does anyone want to co-author and suggest changes? Regards, Jakob. From: Sriram, Kotikalapudi (Fed) Sent: Tuesday, February 4, 2020 10:22 AM To: Jakob Heitz (jheitz) ; Job Snijders ; Ni= ck Hilliard ; John Heasly Cc: idr@ietf.org; grow@ietf.org; idr-chairs@ietf.org; grow-chairs@ietf.org;= a.e.azimov@gmail.com; Brian Dickson Subject: Question about BGP Large Communities In the route leaks solution draft, https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation= -02 we (the authors) have proposed using BGP Large Community. We specify this to be a "well-known transitive Large Community". Question: Can the draft simply make an IANA request for a Global Administrator ASN value for Route Leaks Protection (RLP) type and request that it be published in IANA registry as a "well-known Transitive Large Community"? There is no IANA registry for Large Communities yet; we have requested IDR and GROW Chairs to facilitate that. ---------------- Details/background: We've read the following RFCs related to Large Communities: https://tools.ietf.org/html/rfc8092 https://tools.ietf.org/html/rfc8195 RFC 8195 has this table: +-------------------------------+-------------------------= + | RFC8092 | RFC 8195 = | +-------------------------------+-------------------------= -+ | Global Administrator | ASN | | Local Data Part 1 | Function = | | Local Data Part 2 | Parameter | +--------------------------------+------------------------= -+ which is instructive. In the examples that RFC 8195 offers, it appears it is *assumed* that the Large Communities are transitive. For comparison, in Extended Communities (RFC 7153), there are explicit Type values assigned for Transitive, Non-transitive, etc. https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-comm= unities.xhtml However, there is no such explicit Type specification for Large Communities (in RFC 8092 or elsewhere). Thank you. Sriram --_000_BN6PR11MB1890AA431F63030DFE310902C0030BN6PR11MB1890namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

A set of well known large communities could = be useful.

I have a draft that I never submitted attach= ed to this email.

Does anyone want to co-author and suggest ch= anges?

 

Regards,

Jakob.

 

From: Sriram, Kotikalapudi (Fed) <kotikala= pudi.sriram@nist.gov>
Sent: Tuesday, February 4, 2020 10:22 AM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>; Job Snijders <= job@ntt.net>; Nick Hilliard <nick@foobar.org>; John Heasly <hea= s@shrubbery.net>
Cc: idr@ietf.org; grow@ietf.org; idr-chairs@ietf.org; grow-chairs@ie= tf.org; a.e.azimov@gmail.com; Brian Dickson <brian.peter.dickson@gmail.c= om>
Subject: Question about BGP Large Communities

 

In the route leaks solution draft,

https://tools.ietf.org/html/draft= -ietf-grow-route-leak-detection-mitigation-02

we (the authors) have proposed using BGP Large Co= mmunity.

We specify this to be a "well-known transiti= ve Large Community".

 

Question:

Can the draft simply make an IANA request for

a Global Administrator ASN value for Route Leaks = Protection (RLP) type

and request that it be published in IANA registry=

as a "well-known Transitive Large Community&= quot;?

 

There is no IANA registry for Large Communities y= et;

we have requested IDR and GROW Chairs to facilita= te that.

 

----------------

Details/background:

 

We've read the following RFCs related to Large Co= mmunities:

<= span style=3D"color:windowtext;text-decoration:none">https://tools.ietf.org= /html/rfc8092

<= span style=3D"color:windowtext;text-decoration:none">https://tools.ietf.org= /html/rfc8195

 

RFC 8195 has this table:

        &= nbsp;        +-----------------= --------------+-------------------------+

        &= nbsp;        |    &n= bsp;  RFC8092         &nb= sp;          | RFC 8195 &= nbsp;           &nbs= p;  |

        &= nbsp;        +----------------------= ---------+--------------------------+

        &= nbsp;        | Global Administrator = ;   |      ASN    &n= bsp;            = ;    |

        &= nbsp;        |  Local Data Part 1&n= bsp;          |  &nb= sp; Function          &nb= sp;   |

        &= nbsp;        |  Local Data Part 2&n= bsp;          |   Pa= rameter            |=

        &= nbsp;        +----------------------= ----------+-------------------------+

which is instructive. In the examples that RFC 81= 95 offers,

it appears it is *assumed* that the Large Communi= ties are transitive.

 

For comparison, in Extended Communities (RFC 7153= ), there are

explicit Type values assigned for Transitive, Non= -transitive, etc.

https://www.iana.org/assignments/bgp-extended-communities/bgp-extended= -communities.xhtml

However, there is no such explicit Type specifica= tion

for Large Communities (in RFC 8092 or elsewhere).=

 

Thank you.

Sriram

 

 

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

--_000_BN6PR11MB1890AA431F63030DFE310902C0030BN6PR11MB1890namp_-- --_004_BN6PR11MB1890AA431F63030DFE310902C0030BN6PR11MB1890namp_ Content-Type: text/plain; name="draft-heitz-idr-wklc-00.txt" Content-Description: draft-heitz-idr-wklc-00.txt Content-Disposition: attachment; filename="draft-heitz-idr-wklc-00.txt"; size=8102; creation-date="Tue, 04 Feb 2020 20:42:09 GMT"; modification-date="Tue, 04 Feb 2020 20:42:09 GMT" Content-Transfer-Encoding: base64 SURSICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIEouIEhlaXR6CkludGVybmV0LURyYWZ0ICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBDaXNjbwpJbnRlbmRlZCBzdGF0dXM6IFN0YW5kYXJk cyBUcmFjayAgICAgICAgICAgICAgICAgICAgICAgIEZlYnJ1YXJ5IDQsIDIwMjAKRXhwaXJlczog QXVndXN0IDcsIDIwMjAKCgogICAgICAgICAgICAgICAgICAgICBCR1AgV2VsbCBLbm93biBMYXJn ZSBDb21tdW5pdHkKICAgICAgICAgICAgICAgICAgICAgICAgZHJhZnQtaGVpdHotaWRyLXdrbGMt MDAKCkFic3RyYWN0CgogICBBIHJhbmdlIG9mIEJHUCBBdXRvbm9tb3VzIFN5c3RlbSBOdW1iZXJz IGlzIHJlc2VydmVkIHRvIGNyZWF0ZSBhIHNldAogICBvZiBCR1AgV2VsbCBLbm93biBMYXJnZSBD b21tdW5pdGllcy4KClJlcXVpcmVtZW50cyBMYW5ndWFnZQoKICAgVGhlIGtleSB3b3JkcyAiTVVT VCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLAogICAiU0hP VUxEIiwgIlNIT1VMRCBOT1QiLCAiUkVDT01NRU5ERUQiLCAiTUFZIiwgYW5kICJPUFRJT05BTCIg aW4gdGhpcwogICBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgZGVzY3JpYmVkIGlu IFtSRkMyMTE5XS4KClN0YXR1cyBvZiBUaGlzIE1lbW8KCiAgIFRoaXMgSW50ZXJuZXQtRHJhZnQg aXMgc3VibWl0dGVkIGluIGZ1bGwgY29uZm9ybWFuY2Ugd2l0aCB0aGUKICAgcHJvdmlzaW9ucyBv ZiBCQ1AgNzggYW5kIEJDUCA3OS4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgd29ya2luZyBkb2N1 bWVudHMgb2YgdGhlIEludGVybmV0IEVuZ2luZWVyaW5nCiAgIFRhc2sgRm9yY2UgKElFVEYpLiAg Tm90ZSB0aGF0IG90aGVyIGdyb3VwcyBtYXkgYWxzbyBkaXN0cmlidXRlCiAgIHdvcmtpbmcgZG9j dW1lbnRzIGFzIEludGVybmV0LURyYWZ0cy4gIFRoZSBsaXN0IG9mIGN1cnJlbnQgSW50ZXJuZXQt CiAgIERyYWZ0cyBpcyBhdCBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RyYWZ0cy9jdXJy ZW50Ly4KCiAgIEludGVybmV0LURyYWZ0cyBhcmUgZHJhZnQgZG9jdW1lbnRzIHZhbGlkIGZvciBh IG1heGltdW0gb2Ygc2l4IG1vbnRocwogICBhbmQgbWF5IGJlIHVwZGF0ZWQsIHJlcGxhY2VkLCBv ciBvYnNvbGV0ZWQgYnkgb3RoZXIgZG9jdW1lbnRzIGF0IGFueQogICB0aW1lLiAgSXQgaXMgaW5h cHByb3ByaWF0ZSB0byB1c2UgSW50ZXJuZXQtRHJhZnRzIGFzIHJlZmVyZW5jZQogICBtYXRlcmlh bCBvciB0byBjaXRlIHRoZW0gb3RoZXIgdGhhbiBhcyAid29yayBpbiBwcm9ncmVzcy4iCgogICBU aGlzIEludGVybmV0LURyYWZ0IHdpbGwgZXhwaXJlIG9uIEF1Z3VzdCA3LCAyMDIwLgoKQ29weXJp Z2h0IE5vdGljZQoKICAgQ29weXJpZ2h0IChjKSAyMDIwIElFVEYgVHJ1c3QgYW5kIHRoZSBwZXJz b25zIGlkZW50aWZpZWQgYXMgdGhlCiAgIGRvY3VtZW50IGF1dGhvcnMuICBBbGwgcmlnaHRzIHJl c2VydmVkLgoKICAgVGhpcyBkb2N1bWVudCBpcyBzdWJqZWN0IHRvIEJDUCA3OCBhbmQgdGhlIElF VEYgVHJ1c3QncyBMZWdhbAogICBQcm92aXNpb25zIFJlbGF0aW5nIHRvIElFVEYgRG9jdW1lbnRz CiAgIChodHRwczovL3RydXN0ZWUuaWV0Zi5vcmcvbGljZW5zZS1pbmZvKSBpbiBlZmZlY3Qgb24g dGhlIGRhdGUgb2YKICAgcHVibGljYXRpb24gb2YgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSByZXZp ZXcgdGhlc2UgZG9jdW1lbnRzCiAgIGNhcmVmdWxseSwgYXMgdGhleSBkZXNjcmliZSB5b3VyIHJp Z2h0cyBhbmQgcmVzdHJpY3Rpb25zIHdpdGggcmVzcGVjdAogICB0byB0aGlzIGRvY3VtZW50LiAg Q29kZSBDb21wb25lbnRzIGV4dHJhY3RlZCBmcm9tIHRoaXMgZG9jdW1lbnQgbXVzdAoKCgpIZWl0 eiAgICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgNywgMjAyMCAgICAgICAgICAgICAg ICAgW1BhZ2UgMV0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIFdlbGwgS25vd24gTGFyZ2UgQ29t bXVuaXR5ICAgICAgICAgIEZlYnJ1YXJ5IDIwMjAKCgogICBpbmNsdWRlIFNpbXBsaWZpZWQgQlNE IExpY2Vuc2UgdGV4dCBhcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA0LmUgb2YKICAgdGhlIFRydXN0 IExlZ2FsIFByb3Zpc2lvbnMgYW5kIGFyZSBwcm92aWRlZCB3aXRob3V0IHdhcnJhbnR5IGFzCiAg IGRlc2NyaWJlZCBpbiB0aGUgU2ltcGxpZmllZCBCU0QgTGljZW5zZS4KClRhYmxlIG9mIENvbnRl bnRzCgogICAxLiAgSW50cm9kdWN0aW9uICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAgIDIKICAgMi4gIEVuY29kaW5nICAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAyCiAgIDMuICBUcmFuc2l0aXZpdHkg IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgMwogICA0 LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAgIDMKICAgNS4gIElBTkEgQ29uc2lkZXJhdGlvbnMgLiAuIC4gLiAuIC4gLiAuIC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gICAzCiAgIDYuICBOb3JtYXRpdmUgUmVmZXJlbmNlcyAg LiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuICAgNAogICBBdXRob3IncyBB ZGRyZXNzICAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAg IDQKCjEuICBJbnRyb2R1Y3Rpb24KCiAgIFRoZSBHbG9iYWwgQWRtaW5pc3RyYXRvciBmaWVsZCBv ZiB0aGUgQkdQIExhcmdlIGNvbW11bml0eSBbUkZDODA5Ml0KICAgaXMgYW4gQXV0b25vbW91cyBT eXN0ZW0gTnVtYmVyIChBU04pLiAgVG8gY3JlYXRlIGEgc2V0IG9mIFdlbGwgS25vd24KICAgTGFy Z2UgQ29tbXVuaXRpZXMsIGEgc2V0IG9mIEFTTnMgaXMgcmVxdWlyZWQgdG8gYmUgcmVzZXJ2ZWQg Zm9yIHRoZW0sCiAgIHN1Y2ggdGhhdCBhIHJlYWwgQVNOIGluIHRoZSBHbG9iYWwgQWRtaW5pc3Ry YXRvciBmaWVsZCBjYW5ub3QgYmUKICAgbWlzdGFrZW4gZm9yIGEgV2VsbCBLbm93biBMYXJnZSBD b21tdW5pdHkuCgoyLiAgRW5jb2RpbmcKCiAgIEVhY2ggQkdQIFdlbGwgS25vd24gTGFyZ2UgQ29t bXVuaXR5IHZhbHVlIGlzIGVuY29kZWQgYXMgYSAxMi1vY3RldAogICBxdWFudGl0eSwgYXMgZm9s bG93czoKCiAgICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAg ICAgICAgICAgICAgICAgIDMKICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxCiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsKICAgICB8MSAxIDEg MSAwIDEgMHwgVCB8ICAgIFdLTEMgSUQgICAgfCAgICAgICAgICBEYXRhIDEgICAgICAgICAgICAg fAogICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rCiAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERhdGEg MiAgICAgICAgICAgICAgICAgICAgICAgICAgIHwKICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKwogICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBEYXRhIDMgICAgICAgICAgICAgICAgICAgICAgICAgICB8 CiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsKCiAgIFRoZSBmaWVsZHMgYXJlIGFzIHNob3duIGJlbG93OgoKICAgICAg ICBUICAgICAgICAgIC0gVHJhbnNpdGl2aXR5IGZpZWxkICgyIGJpdHMpLiAgVGhpcyBpcyBmdXJ0 aGVyCiAgICAgICAgICAgICAgICAgICAgIGRlc2NyaWJlZCBiZWxvdy4KCiAgICAgICAgV0tMQyBJ RCAgICAtIFdlbGwgS25vd24gTGFyZ2UgQ29tbXVuaXR5IElkZW50aWZpZXIgKDEgb2N0ZXQpLgog ICAgICAgICAgICAgICAgICAgICBTZWUgSUFOQSBDb25zaWRlcmF0aW9ucy4gIElmIGFuIGV4cGVy aW1lbnRhbCB0eXBlCiAgICAgICAgICAgICAgICAgICAgIGlzIHVzZWQsIHRoZW4gaXQgTVVTVCBO T1QgYmUgaGFyZCBjb2RlZCBpbiB0aGUgQkdQCiAgICAgICAgICAgICAgICAgICAgIHNwZWFrZXIg c29mdHdhcmU7IGl0IE1VU1QgYmUgY29uZmlndXJhYmxlLgogICAgICAgICAgICAgICAgICAgICBE aWZmZXJlbnQgZXhwZXJpbWVudHMgY2FuIHRoZW4gcnVuIGluIHRoZSBzYW1lCgoKCgpIZWl0eiAg ICAgICAgICAgICAgICAgICAgRXhwaXJlcyBBdWd1c3QgNywgMjAyMCAgICAgICAgICAgICAgICAg W1BhZ2UgMl0KDApJbnRlcm5ldC1EcmFmdCAgICAgICAgIFdlbGwgS25vd24gTGFyZ2UgQ29tbXVu aXR5ICAgICAgICAgIEZlYnJ1YXJ5IDIwMjAKCgogICAgICAgICAgICAgICAgICAgICBuZXR3b3Jr IHdpdGhvdXQgaGF2aW5nIHRvIGNvb3JkaW5hdGUgaWRlbnRpZmllcgogICAgICAgICAgICAgICAg ICAgICBhc3NpZ25tZW50IGR1cmluZyB0aGUgY29kaW5nIHN0YWdlLgoKICAgICAgICBEYXRhIDEs MiwzIC0gQSAxMCBvY3RldCB2YWx1ZSBzcGVjaWZpYyB0byB0aGUgV0tMQy4KCjMuICBUcmFuc2l0 aXZpdHkKCiAgIFRoZSB0cmFuc2l0aXZpdHkgZmllbGQgZGV0ZXJtaW5lcyBob3cgQkdQIHNwZWFr ZXJzIHRyYW5zZmVyIHRoZSBXS0xDCiAgIGFjcm9zcyByZWFsIEF1dG9ub21vdXMgU3lzdGVtIChB UykgYm91bmRhcmllcy4gIFRoZSB0cmFuc2l0aXZpdHkgaXMKICAgYWR2aXNvcnkuICBJZiBhIEJH UCBzcGVha2VyIHdpc2hlcyBub3QgdG8gcmVjZWl2ZSBhIHBhcnRpY3VsYXIgbGFyZ2UKICAgY29t bXVuaXR5LCBpdCBNVVNUIGZpbHRlciBpdCBvdXQgdXNpbmcgbG9jYWwgcG9saWN5LiAgVGhlIHZh bHVlcyBhcmU6CgogICAgICAgIDAgLSBUcmFuc2l0aXZlOiBUaGUgV0tMQyBpcyB0cmFuc2l0aXZl IGFjcm9zcyBBU2VzLgoKICAgICAgICAxIC0gTm9uLXRyYW5zaXRpdmU6IFRoZSBXS0xDIGlzIG5v dCB0cmFuc2l0aXZlIGFjcm9zcyBBU2VzLgoKICAgICAgICAyIC0gQWRtaW5pc3RyYXRpb24gVHJh bnNpdGl2ZTogVGhlIFdLTEMgaXMgdHJhbnNpdGl2ZSBhY3Jvc3MKICAgICAgICAgICAgQVNlcyB1 bmRlciB0aGUgc2FtZSBhZG1pbmlzdHJhdGlvbiBvbmx5LiAgQnkgZGVmYXVsdCwgZXZlcnkKICAg ICAgICAgICAgQVMgYm91bmRhcnkgaXMgYWxzbyBhbiBhZG1pbmlzdHJhdGlvbiBib3VuZGFyeS4g IElmIGFuCiAgICAgICAgICAgIGV4dGVybmFsIEJHUCBzZXNzaW9uIGlzIGNvbmZpZ3VyZWQgYXMg YSBub24tYWRtaW5pc3RyYXRpdmUKICAgICAgICAgICAgYm91bmRhcnksIHRoZW4gaXQgd2lsbCBz ZW5kIGFuZCByZWNlaXZlIFdLTENzIHdpdGgKICAgICAgICAgICAgdHJhbnNpdGl2aXR5IDIsIGVs c2UgaXQgd2lsbCBkaXNjYXJkIHRoZSBXS0xDIGZyb20gdGhlCiAgICAgICAgICAgIFVQREFURSBt ZXNzYWdlLgoKICAgICAgICAzIC0gT25lLXRpbWUgVHJhbnNpdGl2ZTogVGhlIFdLTEMgaXMgdHJh bnNpdGl2ZSBhY3Jvc3MgQVNlcwogICAgICAgICAgICB1bmRlciB0aGUgc2FtZSBhZG1pbmlzdHJh dGlvbiBhbmQgaW50byBhbiBBUyB1bmRlciB0aGUKICAgICAgICAgICAgbmVpZ2hib3JpbmcgYWRt aW5pc3RyYXRpb24sIGJ1dCBub3QgaW50byBhbiBBUyB1bmRlciBhCiAgICAgICAgICAgIGZ1cnRo ZXIgYWRtaW5pc3RyYXRpb24uICBBIEJHUCBzcGVha2VyIHRoYXQgcmVjZWl2ZXMgYSBXS0xDCiAg ICAgICAgICAgIHdpdGggdHJhbnNpdGl2aXR5IDMgb24gYW4gZXh0ZXJuYWwgQkdQIHNlc3Npb24g b24gYW4KICAgICAgICAgICAgYWRtaW5pc3RyYXRpdmUgYm91bmRhcnkgU0hPVUxEIGNoYW5nZSB0 aGUgdHJhbnNpdGl2aXR5IHRvIDIuCgo0LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKCiAgIFRo ZSBCR1AgTGFyZ2UgQ29tbXVuaXR5IFBhdGggYXR0cmlidXRlIGlzIHRyYW5zaXRpdmUuICBUaHVz IGEgQkdQCiAgIHNwZWFrZXIgdGhhdCBkb2VzIG5vdCByZWNvZ25pemUgdGhlIHRyYW5zaXRpdml0 eSBmaWVsZCBtYXkgdHJhbnNtaXQKICAgdGhlIFdLTEMgY29udHJhcnkgdG8gdGhlIGFkdmlzZW1l bnQgb2YgdGhlIHRyYW5zaXRpdml0eSBmaWVsZC4gIElmIGEKICAgQkdQIHNwZWFrZXIgd2lzaGVz IG5vdCB0byByZWNlaXZlIGFueSBMYXJnZSBDb21tdW5pdHksIGl0IG11c3QKICAgY29udGludWUg dG8gZmlsdGVyIGl0IGluIHRoZSBzYW1lIHdheSBpdCB3YXMgZG9pbmcgYmVmb3JlIHRoZQogICB0 cmFuc2l0aXZpdHkgZmllbGQgd2FzIGludHJvZHVjZWQuCgo1LiAgSUFOQSBDb25zaWRlcmF0aW9u cwoKICAgSUFOQSBpcyByZXF1ZXN0ZWQgdG8gYXNzaWduIHRoZSByYW5nZSA0MDkzNjQwNzA0ICgw eEY0MDAwMDAwKSB0bwogICA0MTI3MTk1MTM1ICgweEY1RkZGRkZGKSBmcm9tIHRoZSBCR1AgQVNO IHJlZ2lzdHJ5IGZvciBCR1AgV2VsbCBLbm93bgogICBMYXJnZSBDb21tdW5pdGllcy4KCiAgIElB TkEgaXMgcmVxdWVzdGVkIHRvIGNyZWF0ZSBhIHJlZ2lzdHJ5IG9mIFdlbGwgS25vd24gTGFyZ2UK ICAgQ29tbXVuaXRpZXMgaW4gdGhlIHJhbmdlIDAgdG8gMjU1LiAgTnVtYmVycyBmcm9tIHRoaXMg cmVnaXN0cnkgYXJlIHRvCgoKCkhlaXR6ICAgICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3Vz dCA3LCAyMDIwICAgICAgICAgICAgICAgICBbUGFnZSAzXQoMCkludGVybmV0LURyYWZ0ICAgICAg ICAgV2VsbCBLbm93biBMYXJnZSBDb21tdW5pdHkgICAgICAgICAgRmVicnVhcnkgMjAyMAoKCiAg IGJlIGFzc2lnbmVkIGluIGFjY29yZGFuY2Ugd2l0aCB0aGUgcG9saWNpZXMgZGVmaW5lZCBpbiBb UkZDODEyNl0uCiAgIFRoZSBwb2xpY2llcyBmb3IgdGhlIGZvbG93aW5nIG51bWJlciByYW5nZXMg YXJlOgoKICAgICAgICAwLTYzICAgIC0gUkZDIFJlcXVpcmVkCgogICAgICAgIDY0LTIyMyAgLSBG aXJzdCBDb21lIEZpcnN0IFNlcnZlZAoKICAgICAgICAyMjQtMjU1IC0gRXhwZXJpbWVudGFsCgo2 LiAgTm9ybWF0aXZlIFJlZmVyZW5jZXMKCiAgIFtSRkMyMTE5XSAgQnJhZG5lciwgUy4sICJLZXkg d29yZHMgZm9yIHVzZSBpbiBSRkNzIHRvIEluZGljYXRlCiAgICAgICAgICAgICAgUmVxdWlyZW1l bnQgTGV2ZWxzIiwgQkNQIDE0LCBSRkMgMjExOSwKICAgICAgICAgICAgICBET0kgMTAuMTc0ODcv UkZDMjExOSwgTWFyY2ggMTk5NywKICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRv ci5vcmcvaW5mby9yZmMyMTE5Pi4KCiAgIFtSRkM4MDkyXSAgSGVpdHosIEouLCBFZC4sIFNuaWpk ZXJzLCBKLiwgRWQuLCBQYXRlbCwgSy4sIEJhZ2RvbmFzLAogICAgICAgICAgICAgIEkuLCBhbmQg Ti4gSGlsbGlhcmQsICJCR1AgTGFyZ2UgQ29tbXVuaXRpZXMgQXR0cmlidXRlIiwKICAgICAgICAg ICAgICBSRkMgODA5MiwgRE9JIDEwLjE3NDg3L1JGQzgwOTIsIEZlYnJ1YXJ5IDIwMTcsCiAgICAg ICAgICAgICAgPGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2luZm8vcmZjODA5Mj4uCgogICBb UkZDODEyNl0gIENvdHRvbiwgTS4sIExlaWJhLCBCLiwgYW5kIFQuIE5hcnRlbiwgIkd1aWRlbGlu ZXMgZm9yCiAgICAgICAgICAgICAgV3JpdGluZyBhbiBJQU5BIENvbnNpZGVyYXRpb25zIFNlY3Rp b24gaW4gUkZDcyIsIEJDUCAyNiwKICAgICAgICAgICAgICBSRkMgODEyNiwgRE9JIDEwLjE3NDg3 L1JGQzgxMjYsIEp1bmUgMjAxNywKICAgICAgICAgICAgICA8aHR0cHM6Ly93d3cucmZjLWVkaXRv ci5vcmcvaW5mby9yZmM4MTI2Pi4KCkF1dGhvcidzIEFkZHJlc3MKCiAgIEpha29iIEhlaXR6CiAg IENpc2NvCiAgIDE3MCBXZXN0IFRhc21hbiBEcml2ZQogICBTYW4gSm9zZSwgQ0EgIDk1MTM0CiAg IFVTQQoKICAgRW1haWw6IGpoZWl0ekBjaXNjby5jb20KCgoKCgoKCgoKCgoKCgoKCkhlaXR6ICAg ICAgICAgICAgICAgICAgICBFeHBpcmVzIEF1Z3VzdCA3LCAyMDIwICAgICAgICAgICAgICAgICBb UGFnZSA0XQo= --_004_BN6PR11MB1890AA431F63030DFE310902C0030BN6PR11MB1890namp_-- From nobody Tue Feb 4 15:54:51 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F5F12008D; Tue, 4 Feb 2020 14:55:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tWG0T1t-VHtI; Tue, 4 Feb 2020 14:54:58 -0800 (PST) Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA4B12001E; Tue, 4 Feb 2020 14:54:58 -0800 (PST) Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 2329023D01E; Tue, 4 Feb 2020 22:54:58 +0000 (UTC) Date: Tue, 4 Feb 2020 22:54:58 +0000 From: John Heasly To: "Jakob Heitz (jheitz)" Cc: "Sriram, Kotikalapudi (Fed)" , Job Snijders , Nick Hilliard , John Heasly , "idr@ietf.org" , "grow@ietf.org" , "idr-chairs@ietf.org" , "grow-chairs@ietf.org" , "a.e.azimov@gmail.com" , Brian Dickson Message-ID: <20200204225458.GB57481@shrubbery.net> References: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="mYCpIKhGyMATD0i+" Content-Disposition: inline In-Reply-To: X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc X-note: live free, or die! X-homer: i just want to have a beer while i am caring. X-Claimation: an engineer needs a manager like a fish needs a bicycle X-reality: only YOU can put an end to the embarrassment that is Tom Cruise User-Agent: Mutt/1.12.2 (2019-09-21) Archived-At: X-Mailman-Approved-At: Tue, 04 Feb 2020 15:54:49 -0800 Subject: Re: [Idr] Question about BGP Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 22:55:03 -0000 --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Tue, Feb 04, 2020 at 08:45:40PM +0000, Jakob Heitz (jheitz): > A set of well known large communities could be useful. > I have a draft that I never submitted attached to this email. > Does anyone want to co-author and suggest changes? Hey Jacob, I'd work on that with you. Job, Morrow and I also started a draft for Large WKCs, but we have not submitted anything - nor made any recent progress. IIRC, the direction we were intending to use 0 (zero) as the ASN, then define local data part 1 as WKC itself, and local data part 2 to be a value associated. I've attached that I have written so far. Job and Morrow may or may not endorse this approach at this point. -heas --mYCpIKhGyMATD0i+ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="draft-snjiders-bgp-wk-lc-00.txt" Global Routing Operations J. Snijders Internet-Draft NTT Communications Intended status: Standards Track June 4, 2019 Expires: December 6, 2019 BGP Well-known Large Communities draft-snjiders-bgp-wk-lc-00 Abstract This document describes well-known BGP Large Communities [RFC8092] akin to those of BGP Communities [RFC1997]. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 6, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Snijders Expires December 6, 2019 [Page 1] Internet-Draft BGP Well-known Large Communities June 2019 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Taxonomy of Well-known BGP Large Communities . . . . . . . . 2 2.1. Well-known Global Administrator . . . . . . . . . . . . . 2 2.2. Local Data Part 1 . . . . . . . . . . . . . . . . . . . . 3 2.3. Local Data Part 2 . . . . . . . . . . . . . . . . . . . . 3 3. Well-known BGP Large Communities . . . . . . . . . . . . . . 3 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Applicable Uses . . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.2. Informative References . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction This document describes Well-known BGP Large Communities [RFC8092]. Well-known BGP Communities [RFC1997] have proven utility and Well- known BGP Large Communities have supplemental benefit because their greater capacity allows for an accompanying argument, such as a four- octet BGP ASN [RFC6793]. Furthermore, an IANA registry is created for these new Well-known Communities. 2. Taxonomy of Well-known BGP Large Communities BGP Large Communities [RFC8092] are entities of three four-octet values known as the Global Administrator, and Local Data Part 1 and 2. The use of each is defined below. 2.1. Well-known Global Administrator The Global Administrator (GA), or namespace identifier, is the BGP Autonomous System Number (ASN) that defined the significance of the subsequent Local Data Parts. Because ASN 0 is otherwise proscribed from use by [RFC7607] and discouraged by [RFC8092], it is opportune for prescription as the Well-known Community namespace identifier in Snijders Expires December 6, 2019 [Page 2] Internet-Draft BGP Well-known Large Communities June 2019 the GA field, and this document reserves it for this purpose. It is also an easily typed and obvious value for operator convenience. One might be inclined to suggest the use of 65535 or 4294967295 ([RFC7300]), which are also taboo. An Private Use ASN [RFC6996] or 23456 (AS_TRANS, [RFC4893]) might also come to mind. The authors feel that zero is more convenient than the first two and avoids conflict within an AS that might use the latter ASNs. 2.2. Local Data Part 1 This, the second field, is the Well-known Community value itself. In the parlance of [RFC8092], it is the function by which Local Data Part 2 is evaluated. 2.3. Local Data Part 2 This, the third field, is the argument of or to the Well-known Community. 3. Well-known BGP Large Communities This document defines the following Well-known BGP Large Communities, further described below. In all cases, the Global Administrator is zero. +-------------------+-------------------+-------------------------+ | Local Data Part 1 | Local Data Part 2 | description | +-------------------+-------------------+-------------------------+ | 0 | ASN | no-export from AS ASN | +-------------------+-------------------+-------------------------+ | 1 | ASN | do not export to AS ASN | +-------------------+-------------------+-------------------------+ Table 1: Well-known BGP Large Communities 3.1. Examples +---------------+---------------------------+ | Community | description | +---------------+---------------------------+ | 0:0:64496 | no-export from AS 64496 | +---------------+---------------------------+ | 0:1:65551 | do not export to AS 65551 | +---------------+---------------------------+ Table 2: Well-known BGP Large Community Examples Snijders Expires December 6, 2019 [Page 3] Internet-Draft BGP Well-known Large Communities June 2019 4. Applicable Uses Well-known BGP Large Communities are not intended to replace Well- known BGP Communities [RFC1997], nor well-known communities of other BGP community types that may evolve. Use the correct tool for the problem. By example, a routing policy concept that requires an argument that can be represented in 4-octets is appropriate, while replicating the [RFC1997] NO_EXPORT community would not. 5. Security Considerations This document does not change any existing security issues associated with BGP Large Communities nor of other BGP Community Attributes. In addition to the considerations expressed in [RFC8092], an Autonomous System (AS) that accepts, sends or forwards NLRI with Well-known BGP Large Communities must itself be aware of how these communities will implicitly or explicitly affect route selection. 6. IANA Considerations IANA is requested to create a new registry for Well-known BGP Large Communities [RFC8092] by the name "BGP Well-known Large Communities". The registry MUST have two fields, Local Data Part 1 and Local Data Part 2, and MUST be seeded with the values defined by this document in Table 1 of Section 3. The allocation policy for new entries is first come, first served for Local Data Part 1 values of 0 through 2147483647 (0 - 0x7fffffff) and "Standards Action" for 2147483648 through 4294967295 (0x80000000 - 0xffffffff). The Local Data Part 2 is an argument associated with a particular Local Data Part 1, whose value can be unspecified (any value), a single or range of values, or have an allocation policy set forth by a separate "Standards Action." Allocation of a large swath of Local Data Part 1 values to a single function or concept is NOT RECOMMENDED. Non-consecutive Allocation is NOT RECOMMENDED. 7. References 7.1. Normative References [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, . Snijders Expires December 6, 2019 [Page 4] Internet-Draft BGP Well-known Large Communities June 2019 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS Number Space", RFC 4893, DOI 10.17487/RFC4893, May 2007, . [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet Autonomous System (AS) Number Space", RFC 6793, DOI 10.17487/RFC6793, December 2012, . [RFC6996] Mitchell, J., "Autonomous System (AS) Reservation for Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July 2013, . [RFC7300] Haas, J. and J. Mitchell, "Reservation of Last Autonomous System (AS) Numbers", BCP 6, RFC 7300, DOI 10.17487/RFC7300, July 2014, . [RFC7607] Kumari, W., Bush, R., Schiller, H., and K. Patel, "Codification of AS 0 Processing", RFC 7607, DOI 10.17487/RFC7607, August 2015, . [RFC8092] Heitz, J., Ed., Snijders, J., Ed., Patel, K., Bagdonas, I., and N. Hilliard, "BGP Large Communities Attribute", RFC 8092, DOI 10.17487/RFC8092, February 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [RFC8195] Snijders, J., Heasley, J., and M. Schmidt, "Use of BGP Large Communities", RFC 8195, DOI 10.17487/RFC8195, June 2017, . Author's Address Snijders Expires December 6, 2019 [Page 5] Internet-Draft BGP Well-known Large Communities June 2019 Job Snijders NTT Communications Theodorus Majofskistraat 100 Amsterdam 1065 SZ The Netherlands Email: job@ntt.net Snijders Expires December 6, 2019 [Page 6] --mYCpIKhGyMATD0i+-- From nobody Tue Feb 4 15:54:53 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6599120170; Tue, 4 Feb 2020 15:20:18 -0800 (PST) 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, BODY_ENHANCEMENT=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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, 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 (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 2AOs2pjbSnHq; Tue, 4 Feb 2020 15:20:16 -0800 (PST) Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 BDFD3120164; Tue, 4 Feb 2020 15:20:16 -0800 (PST) Received: by mail-ua1-x933.google.com with SMTP id f7so150716uaa.8; Tue, 04 Feb 2020 15:20:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WH37kYZhMD2Gs6m3RenwO6jC06x/FBn4NA6AFtf2Ur0=; b=tpedFj/x2E82nKztO/iCsgcDU94Y+j2bE+Jqs6TK5ueESgvN4c4t9w+ZctZRz9ZCQ6 alxmN4Iie7/sL6W2QHCRX13/EOwLo98ud3NRDfrqAaunxcB3m0bv03Y4QReci6/AevuH IH86yxrrTJbOga6HSGgLTArSVEaGReT84PlhB6kWqkjuaTBhGUfFG45L1YfQppOf1xNt T6McipqzUAG+O7W5/CyKi7L2X+wd8tj6wgCY2GD+5S8Olz3H9YfqfkK7Y0qbcodPRw2K F14AcLkuvRogUCxUPtmdz4IRUzf+oFDCYMLdKo+zKbC8+iXMXnxTixsVNHF9vuLSWint a+2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WH37kYZhMD2Gs6m3RenwO6jC06x/FBn4NA6AFtf2Ur0=; b=EVUIYz58pDOuhT8xf5nOyDJBejFY0wIeEeROWPHYwS4iugAFy6Ou6ZT9WpkOedkyX7 PxkxmtK/Ol1/o8oTM1isuBD9gcwvKP28KG+lFxaGCUOx/AUji4sVROSQOfSkzhNRkgYs gP5eijDXtnBRN/x7JEnnDE1Zsj/3FKIn/dvGRaV2UM96bsYillpxnX+NzwSE5dicbo/b SLLrj9WXw/Gl1GFnpyxiLQqVKy/hL2/eeaipmQuZKwaZLjPpjCUfqY+GSNNlXTOHnkCz QxMw1N8ASWOr629fE5aCGUdTTaaDECjxYkree5rkwumHh8EUclqTo1DrUV4OW3t57mhz 3otA== X-Gm-Message-State: APjAAAXPawXpnkNRfbgvRXY+v4DeflbZ8b7mAhg3M/Z7jJiHZbvLI3EZ I56aGmhTFpRARp5dNxgyyPX7gB1Tr+Nwf6hH+a8= X-Google-Smtp-Source: APXvYqxh6MH22SuyU9tIqNFdSAyFP04Pxeaa+MsxRdQ05ANRZuZmBN42IAnEgabNGtErauYQBLnPBJ2UYHvJaOKYc0A= X-Received: by 2002:ab0:63cb:: with SMTP id i11mr10737867uap.87.1580858415800; Tue, 04 Feb 2020 15:20:15 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brian Dickson Date: Tue, 4 Feb 2020 15:20:04 -0800 Message-ID: To: "Jakob Heitz (jheitz)" Cc: "Sriram, Kotikalapudi (Fed)" , Job Snijders , Nick Hilliard , John Heasly , "idr@ietf.org" , "grow@ietf.org" , "idr-chairs@ietf.org" , "grow-chairs@ietf.org" , "a.e.azimov@gmail.com" Content-Type: multipart/alternative; boundary="0000000000005068ea059dc8482a" Archived-At: X-Mailman-Approved-At: Tue, 04 Feb 2020 15:54:49 -0800 Subject: Re: [Idr] Question about BGP Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Feb 2020 23:20:19 -0000 --0000000000005068ea059dc8482a Content-Type: text/plain; charset="UTF-8" Hi, Jakob, I'm interested/willing to co-author and/or review as needed. (FYI: it looks like your bit field is mis-aligned, there should be 6 bits above the 2-bit T value, then 8 bits of WKC.) I agree that 256 (0-255) is more than enough WKC values, given that like 3 or 4 have been used in old community space. Brian On Tue, Feb 4, 2020 at 12:45 PM Jakob Heitz (jheitz) wrote: > A set of well known large communities could be useful. > > I have a draft that I never submitted attached to this email. > > Does anyone want to co-author and suggest changes? > > > > Regards, > > Jakob. > > > > *From:* Sriram, Kotikalapudi (Fed) > *Sent:* Tuesday, February 4, 2020 10:22 AM > *To:* Jakob Heitz (jheitz) ; Job Snijders ; > Nick Hilliard ; John Heasly > *Cc:* idr@ietf.org; grow@ietf.org; idr-chairs@ietf.org; > grow-chairs@ietf.org; a.e.azimov@gmail.com; Brian Dickson < > brian.peter.dickson@gmail.com> > *Subject:* Question about BGP Large Communities > > > > In the route leaks solution draft, > > > https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigation-02 > > we (the authors) have proposed using BGP Large Community. > > We specify this to be a "well-known transitive Large Community". > > > > Question: > > Can the draft simply make an IANA request for > > a Global Administrator ASN value for Route Leaks Protection (RLP) type > > and request that it be published in IANA registry > > as a "well-known Transitive Large Community"? > > > > There is no IANA registry for Large Communities yet; > > we have requested IDR and GROW Chairs to facilitate that. > > > > ---------------- > > Details/background: > > > > We've read the following RFCs related to Large Communities: > > https://tools.ietf.org/html/rfc8092 > > https://tools.ietf.org/html/rfc8195 > > > > RFC 8195 has this table: > > > +-------------------------------+-------------------------+ > > | RFC8092 | RFC > 8195 | > > > +-------------------------------+--------------------------+ > > | Global Administrator | ASN | > > | Local Data Part 1 | Function > | > > | Local Data Part 2 | Parameter | > > > +--------------------------------+-------------------------+ > > which is instructive. In the examples that RFC 8195 offers, > > it appears it is *assumed* that the Large Communities are transitive. > > > > For comparison, in Extended Communities (RFC 7153), there are > > explicit Type values assigned for Transitive, Non-transitive, etc. > > > https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml > > However, there is no such explicit Type specification > > for Large Communities (in RFC 8092 or elsewhere). > > > > Thank you. > > Sriram > > > > > > > --0000000000005068ea059dc8482a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi, Jakob,
I'm interested/willing to co-author and= /or review as needed.
(FYI: it looks like your bit field is mis-a= ligned, there should be 6 bits above the 2-bit T value, then 8 bits of WKC.= )

I agree that 256 (0-255) is more than enough WKC= values, given that like 3 or 4 have been used in old community space.

Brian

On Tue, Feb 4, 2020 at 12:45 PM Jakob Heitz= (jheitz) <jheitz@cisco.com> = wrote:

A set of well known large communities = could be useful.

I have a draft that I never submitted = attached to this email.

Does anyone want to co-author and sugg= est changes?

=C2=A0

Regards,

Jakob.

=C2=A0

From: Sriram, Kotikalapudi (Fed) <kotikalapudi.sri= ram@nist.gov>
Sent: Tuesday, February 4, 2020 10:22 AM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>; Job Snijders <job@ntt.net>; Nick Hilliard <nick@foobar.org>; J= ohn Heasly <heas= @shrubbery.net>
Cc: idr@ietf.org; grow@ietf.org; <= a href=3D"mailto:idr-chairs@ietf.org" target=3D"_blank">idr-chairs@ietf.org= ; grow-chairs= @ietf.org; a.= e.azimov@gmail.com; Brian Dickson <brian.peter.dickson@gmail.com>
Subject: Question about BGP Large Communities

=C2=A0

In the route leaks so= lution draft,

https://tools.ietf.org/html/draft-ietf-grow-route-leak-detecti= on-mitigation-02

we (the authors) have= proposed using BGP Large Community.

We specify this to be= a "well-known transitive Large Community".

=C2=A0<= /p>

Question: <= /u>

Can the draft simply = make an IANA request for

a Global Administrato= r ASN value for Route Leaks Protection (RLP) type

and request that it b= e published in IANA registry

as a "well-known= Transitive Large Community"?

=C2=A0<= /p>

There is no IANA regi= stry for Large Communities yet;

we have requested IDR= and GROW Chairs to facilitate that.

=C2=A0<= /p>

----------------

Details/background:

=C2=A0<= /p>

We've read the fo= llowing RFCs related to Large Communities:

https://tools.ietf.org/html/rfc8092

https://tools.ietf.org/html/rfc8195

=C2=A0<= /p>

RFC 8195 has this tab= le:

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0+-------------------------------+-------------------------+=

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC8092=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 | RFC 8195=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= +-------------------------------+--------------------------+=

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= | Global Administrator=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A= SN=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0 Local Data Part 1=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0 Function=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= |=C2=A0 Local Data Part 2=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0 Parameter=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2= =A0=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 is instructive.= In the examples that RFC 8195 offers,

it appears it is *ass= umed* that the Large Communities are transitive.

=C2=A0<= /p>

For comparison, in Ex= tended Communities (RFC 7153), there are

explicit Type values = assigned for Transitive, Non-transitive, etc.

https://www.iana.org/ass= ignments/bgp-extended-communities/bgp-extended-communities.xhtml=

However, there is no = such explicit Type specification

for Large Communities= (in RFC 8092 or elsewhere).

=C2=A0<= /p>

Thank you.<= /u>

Sriram<= /p>

=C2=A0<= /p>

=C2=A0<= /p>

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

--0000000000005068ea059dc8482a-- From nobody Tue Feb 4 17:28:49 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28F68120072; Tue, 4 Feb 2020 17:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_ENHANCEMENT=0.001, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nB6-Tfet79hW; Tue, 4 Feb 2020 17:28:43 -0800 (PST) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2095.outbound.protection.outlook.com [40.107.91.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6848A120058; Tue, 4 Feb 2020 17:28:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=B4JzgHOTMOTsn5A+5siBZhwEXJPgT+9nuQ3SSHbuyli/bIWTrToB06TQW3pjNRebB6cTc2ZfezqXB5nyUxbvMeJDMJRaUlaiXkjiiV6TntGrvEWzF+oUreUN0TiHMQhpRaKlum2a5EMqLBuyhFxkxvK61/Yh7GarEbBdD3vfR1dY2XJd3+em72tIC4qjsKO9nejSY7bc0D73P3ohh0DDprMG5l2shcuOq1Pb3UIZaizr26GlDt84bBky8ggeUy9ZR+b4ChYHMkI1SRAd+xnK/PuRN9pTYU26xq3cNgXnS8klftrXvKRfdKwWz6TCnoHXJM02JDX4Y/bi3F/PFz6hig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U3gWDpkKF4JSuewHAJFRgwkyBSNWDSQOTiCLX9YfmII=; b=UhkHKjA7zhM1qysvSIWUDeV86Zxn4C04RBA6sFtYDNEIbOCzk9oGIIhGI8pqC362wOFlOIER/QElAPZtdNx5SpOv2/vE6eJWWlQibSATy7YCg5xMnm0F3f/2vJVXIzhfKKdKmwopKm2kcXeVFVGt5f7dvSH7K4MxVt4gwqR0weu+zbxNP2B3WT3zMgQTlQy1gluNpqQsO31jEEwNW+KmR4R5zXSYw7Pk3HcLrYQSZDufLbCOrVdhUs5IVgpBVCqJZ/Nt1nJXoytqHdOhprRMPIDGc/nWUesgDK4ompFbjFrZtsZ5BtSzCOA6bfCg8C4QSWQ5bpG6hXlB9zf0Py0zPw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U3gWDpkKF4JSuewHAJFRgwkyBSNWDSQOTiCLX9YfmII=; b=bxvkRCTMRE8Ox2pyreCXtyyD76/mQuPZy3gDcC5MWpPZ3EGBQJ75Gb+2B5Kesh3kS/Qj5vxZkHbAogCI42aQl4U8dEXpe19H/eNcS/ff5U3zQL0wHGFGgOYIkJerwMDzJNmeZBlkKh8LYDt8C9AGhKn+A8mckJ9j/KgzqaOc5Ik= Received: from DM6PR09MB5448.namprd09.prod.outlook.com (20.180.61.9) by DM6PR09MB4191.namprd09.prod.outlook.com (20.179.167.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.21; Wed, 5 Feb 2020 01:28:41 +0000 Received: from DM6PR09MB5448.namprd09.prod.outlook.com ([fe80::6430:ee45:4fc4:f468]) by DM6PR09MB5448.namprd09.prod.outlook.com ([fe80::6430:ee45:4fc4:f468%6]) with mapi id 15.20.2707.020; Wed, 5 Feb 2020 01:28:41 +0000 From: "Sriram, Kotikalapudi (Fed)" To: John Heasly , "Jakob Heitz (jheitz)" CC: "idr@ietf.org" , "grow@ietf.org" Thread-Topic: Question about BGP Large Communities Thread-Index: AdXbeNI4t0SppYFnSky8PqLGmuct1gAIu5NAAASXzAAAA08B8A== Date: Wed, 5 Feb 2020 01:28:41 +0000 Message-ID: References: <20200204225458.GB57481@shrubbery.net> In-Reply-To: <20200204225458.GB57481@shrubbery.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.140.161] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ce750baa-21e7-480d-566b-08d7a9dabbe6 x-ms-traffictypediagnostic: DM6PR09MB4191: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(39860400002)(366004)(136003)(199004)(189003)(186003)(86362001)(81166006)(5660300002)(81156014)(8676002)(8936002)(66946007)(66556008)(316002)(54906003)(66476007)(9686003)(110136005)(66446008)(64756008)(53546011)(6506007)(33656002)(4326008)(26005)(52536014)(76116006)(55016002)(2906002)(7696005)(71200400001)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR09MB4191; H:DM6PR09MB5448.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 5YtHMeFA6u0jv+YJVwOhZFj1SfjTP2uX8RL9AvMMUS4aetJndRUbIyP2SX+4DVrFAhWejTWSU85/kfJjDe3H6aKPEGgI3Djpz5NjZ+29YQWKhWNWtukTm1zc/M6wAyzKQhKqStM4iazpCVvcAD8qofc8p4keGrw45qALo0C0ivjuWOQvW/WGgrFd7QHKxnyt9Uz02RbuSqL9uLmPjR6nRYESnCO/PZNK+MYM1z9MJoUvZ2cZycB3H1ayQBqzyclMp29CaKJqvRfveytwztiv91T2wuH9VYODxjfEIC1ztUIIrBz6SUk3fdTdaoqtkOy9bADWxT8WCzdH40kyrCYABJXbC9b6d9WewBw9wtOsX0qROJkIGT/j0yLxUiVmwoJaRCnukGZFHFuzCDQfM+MrXp/V3sW+0jM6+Hj3Cr00hCgmfKVIWqyeDkGkG25wW3E5 x-ms-exchange-antispam-messagedata: IasWMK31R02JCiRFJWmusKTUnQda7CnPnTBp4AC/yFtSA1MicSkysZ5RRGB65mvSlhbmkWOEzFUyVtMFfzAb5DeNKT7TWRHV1gxpfkKQ1m2VNS8/s2yGKoTE1BrYirAWiFXQEzdT5HQNBkwuyk8O0A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: ce750baa-21e7-480d-566b-08d7a9dabbe6 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2020 01:28:41.5469 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: qB1dQquXhrGOU+bjjHUD48qgZGBmBaBKO6jcRggXzsJf52lyjKB1A9m9Dp2UW6sf1FhLbqz5p5/VU8P/JMpCsA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR09MB4191 Archived-At: Subject: Re: [Idr] Question about BGP Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 01:28:45 -0000 > > Does anyone want to co-author and suggest changes? I would also be glad to participate in that effort. I have looked at the proposals in the two drafts (Jacob and John H). =20 There are a few observations I would like to share. As Alvaro pointed out, RFC 8092 says: This document defines the BGP Large Communities attribute as an optional transitive path attribute of variable length. That means *all* BGP Large Communities are transitive. Do you agree? RFC 8195 seems to be written in that spirit as well.=20 The first 32 bits together are a Global Administrator (GA) ID. So, it seems it would not be possible to use any part of it as data. Otherwise, collisions (ambiguity) could happen when=20 other LCs use 4-octet ASNs in the Global Administrator field. Agree? I see Jacob's draft proposes using some portion of the first 32 bits as dat= a. The draft that John Heasly shared sets the first 32-bits to ASN value 0 to designate WK-LC; so no part of the first 32-bits is data. Another idea to consider:=20 Why not request IANA to assign a range of 256 or 1024 or some number (?)=20 of 4-byte ASN values to be allocated and used as GA ID for transitive WK-LC= s? A function (e.g., route-leak protection) that requires transitive WK-LC=20 will be allocated one these ASN values. Then we don't waste any part of the first 32-bits to designate "type" of LC= . That cleanly leaves 64 bits for local data (as RFC 8092 specifies) which can accommodate two 4-byte ASNs if needed. Sriram > -----Original Message----- > From: John Heasly > Sent: Tuesday, February 4, 2020 5:55 PM > To: Jakob Heitz (jheitz) > Cc: Sriram, Kotikalapudi (Fed) ; Job Snijde= rs > ; Nick Hilliard ; John Heasly > ; idr@ietf.org; grow@ietf.org; idr-chairs@ietf.org; > grow-chairs@ietf.org; a.e.azimov@gmail.com; Brian Dickson > > Subject: Re: Question about BGP Large Communities >=20 > Tue, Feb 04, 2020 at 08:45:40PM +0000, Jakob Heitz (jheitz): > > A set of well known large communities could be useful. > > I have a draft that I never submitted attached to this email. > > Does anyone want to co-author and suggest changes? >=20 > Hey Jacob, > I'd work on that with you. Job, Morrow and I also started a draft for > Large WKCs, but we have not submitted anything - nor made any recent > progress. >=20 > IIRC, the direction we were intending to use 0 (zero) as the ASN, then > define local data part 1 as WKC itself, and local data part 2 to be a > value associated. >=20 > I've attached that I have written so far. Job and Morrow may or may not > endorse this approach at this point. >=20 > -heas From nobody Tue Feb 4 17:43:21 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 013291200E7; Tue, 4 Feb 2020 17:43:20 -0800 (PST) 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, BODY_ENHANCEMENT=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=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 R20j8jtOHewT; Tue, 4 Feb 2020 17:43:18 -0800 (PST) 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 C0E9A12006E; Tue, 4 Feb 2020 17:43:17 -0800 (PST) Received: by mail-ua1-x935.google.com with SMTP id y3so273252uae.3; Tue, 04 Feb 2020 17:43:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=afpvOZkNeu5eMwkryo4b6KYw1VzAJKEek0W5yctJGsk=; b=O5PMXagRIhMqvNp5sjIbfpx/tBdfIDjdDkkERiE613yTJcjxip0pOLLu1nBgT3brr0 Cfq6ZVvsKCpIdc0WJO1bAvh0365qYYvdLppBBEnWfjUnc8PzwS2wxxU8NI6tj6+OCzQ7 mIv+5W6XWu4wX9htUcmG3OFYVBFbkcbDeEPUWuAnOXKwEwesURNEvMnPaZIvewqFu2xe yzUyARFH/mopGkYi6zVqxETF5LA4ZATVRtLIweBA09xM4evotP7Gr7u0q9G0sFPElMOt 5iVDNBTZDRSE/1njugGIeLdkVxVwTweaFutN91FvcpvDZG9iRwdXFS+dFseuJ1W+J8ll 9p9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=afpvOZkNeu5eMwkryo4b6KYw1VzAJKEek0W5yctJGsk=; b=XD0PymXrnBcAPmKkOO6ufw0/x5NrAvFNZwghUuyXX/ClY4QTObymyxJ1pWZETiw4gv zIbCs7KE43BOpZqa0Dfb7DNbXcXQuQ2kqDuAcRgEDHEO1pTSvqztz7Xz2zLQ158YaEGr I41PIQ7IZ9SUGuj7VJ9MUCA935txYcGkEWsDprPwsiZa6oAnRgE27c6ifqePaf8wwqlf RCsR+F4SUivLvW64/b+xFCboKa2NauJZBpEETzJ4aJk98ETsw+Zlmvo33O9S2e936bgo I1omGnQol7aIasj0yECWq28taUd+JzojkaadsLd5VmYtqzmjlM6eVqyHIQRxU5ker48C 1wsw== X-Gm-Message-State: APjAAAXC+7evyxh6T7Z5dJBgmNQx1ZlMaZyyIy6zJuZv7EAn7KroNpV9 8fXNIEsY9JGciPUHwfE+f5ECcQj/4Zg5RWiwoe8= X-Google-Smtp-Source: APXvYqyxP25FR78tfiYP7Ugf4NbRPm3nJHqjBuxpthzHfwy9bjQO1B4Mnm7wNGi3X4aZdLOTdud2cevtUFcWyUQ7l9k= X-Received: by 2002:ab0:634c:: with SMTP id f12mr19074905uap.48.1580866996778; Tue, 04 Feb 2020 17:43:16 -0800 (PST) MIME-Version: 1.0 References: <20200204225458.GB57481@shrubbery.net> In-Reply-To: From: Brian Dickson Date: Tue, 4 Feb 2020 17:43:05 -0800 Message-ID: To: "Sriram, Kotikalapudi (Fed)" Cc: John Heasly , "Jakob Heitz (jheitz)" , "idr@ietf.org" , "grow@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c7bddc059dca473b" Archived-At: Subject: Re: [Idr] Question about BGP Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 01:43:20 -0000 --000000000000c7bddc059dca473b Content-Type: text/plain; charset="UTF-8" On Tue, Feb 4, 2020 at 5:28 PM Sriram, Kotikalapudi (Fed) < kotikalapudi.sriram@nist.gov> wrote: > > > Does anyone want to co-author and suggest changes? > I would also be glad to participate in that effort. > > I have looked at the proposals in the two drafts (Jacob and John H). > There are a few observations I would like to share. > > As Alvaro pointed out, RFC 8092 says: > This document defines the BGP Large Communities attribute as an > optional transitive path attribute of variable length. > > That means *all* BGP Large Communities are transitive. Do you agree? > RFC 8195 seems to be written in that spirit as well. > They are, by default, transitive, unless local policy is to either strip them or filter updates based on the values (or some portion out of the values, like bits 6-7). > > The first 32 bits together are a Global Administrator (GA) ID. > So, it seems it would not be possible to use any part of it as data. > Otherwise, collisions (ambiguity) could happen when > other LCs use 4-octet ASNs in the Global Administrator field. Agree? > Only real ASNs have any reasonable expectation of collision protection and uniqueness, i.e. ASN values <4,000,000,000 > I see Jacob's draft proposes using some portion of the first 32 bits as > data. > The draft that John Heasly shared sets the first 32-bits to ASN value 0 > to designate WK-LC; so no part of the first 32-bits is data. > > Another idea to consider: > Why not request IANA to assign a range of 256 or 1024 or some number (?) > of 4-byte ASN values to be allocated and used as GA ID for transitive > WK-LCs? > A function (e.g., route-leak protection) that requires transitive WK-LC > will be allocated one these ASN values. > Then we don't waste any part of the first 32-bits to designate "type" of > LC. > Jakob's proposal is quite reasonable. The 32-bit ASN RFC (don't recall it offhand) reserves all values >4,000,000,000 as private values. Reserving only those that start (binary) 111110 is a very small slice off that range, near the top but not the very top. Having an extra 16 bits to play with, for every WKC, plus 2 bits per the T field, is plenty and very useful. Only having two 32-bit values is overly limiting, IMHO. Brian > That cleanly leaves 64 bits for local data (as RFC 8092 specifies) > which can accommodate two 4-byte ASNs if needed. > > Sriram > > > -----Original Message----- > > From: John Heasly > > Sent: Tuesday, February 4, 2020 5:55 PM > > To: Jakob Heitz (jheitz) > > Cc: Sriram, Kotikalapudi (Fed) ; Job > Snijders > > ; Nick Hilliard ; John Heasly > > ; idr@ietf.org; grow@ietf.org; idr-chairs@ietf.org; > > grow-chairs@ietf.org; a.e.azimov@gmail.com; Brian Dickson > > > > Subject: Re: Question about BGP Large Communities > > > > Tue, Feb 04, 2020 at 08:45:40PM +0000, Jakob Heitz (jheitz): > > > A set of well known large communities could be useful. > > > I have a draft that I never submitted attached to this email. > > > Does anyone want to co-author and suggest changes? > > > > Hey Jacob, > > I'd work on that with you. Job, Morrow and I also started a draft for > > Large WKCs, but we have not submitted anything - nor made any recent > > progress. > > > > IIRC, the direction we were intending to use 0 (zero) as the ASN, then > > define local data part 1 as WKC itself, and local data part 2 to be a > > value associated. > > > > I've attached that I have written so far. Job and Morrow may or may not > > endorse this approach at this point. > > > > -heas > --000000000000c7bddc059dca473b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Feb 4, 2020 at 5:28 PM Sriram= , Kotikalapudi (Fed) <ko= tikalapudi.sriram@nist.gov> wrote:
> > Does anyone want to co-author and sugge= st changes?
I would also be glad to participate in that effort.

I have looked at the proposals in the two drafts (Jacob and John H).=C2=A0 =
There are a few observations I would like to share.

As Alvaro pointed out, RFC 8092 says:
=C2=A0 =C2=A0This document defines the BGP Large Communities attribute as a= n
=C2=A0 =C2=A0optional transitive path attribute of variable length.

That means *all* BGP Large Communities are transitive. Do you agree?
RFC 8195 seems to be written in that spirit as well.
=
They are, by default, transitive, unless local policy is to = either strip them or filter updates based on the values (or some portion ou= t of the values, like bits 6-7).
=C2=A0

The first 32 bits together are a Global Administrator (GA) ID.
So, it seems it would not be possible to use any part of it as data.
Otherwise, collisions (ambiguity) could happen when
other LCs use 4-octet ASNs in the Global Administrator field. Agree?

Only real ASNs have any reasonable expectatio= n of collision protection and uniqueness, i.e. ASN values <4,000,000,000=
=C2=A0
I see Jacob's draft proposes using some portion of the first 32 bits as= data.
The draft that John Heasly shared sets the first 32-bits to ASN value 0
to designate WK-LC;=C2=A0 so no part of the first 32-bits is data.

Another idea to consider:
Why not request IANA to assign a range of 256 or 1024 or some number (?) of 4-byte ASN values to be allocated and used as GA ID for transitive WK-LC= s?
A function (e.g., route-leak protection) that requires transitive WK-LC will be allocated one these ASN values.
Then we don't waste any part of the first 32-bits to designate "ty= pe" of LC.

Jakob's proposal is= quite reasonable.
The 32-bit ASN RFC (don't recall it offhan= d) reserves all values >4,000,000,000 as private values.
Reser= ving only those that start (binary) 111110 is a very small slice off that r= ange, near the top but not the very top.
Having an extra 16 bits = to play with, for every WKC, plus 2 bits per the T field, is plenty and ver= y useful.
Only having two 32-bit values is overly limiting, IMHO.=

Brian

=C2=A0
That cleanly leaves 64 bits for local data (as RFC 8092 specifies)
which can accommodate two 4-byte ASNs if needed.

Sriram

> -----Original Message-----
> From: John Heasly <heas@shrubbery.net>
> Sent: Tuesday, February 4, 2020 5:55 PM
> To: Jakob Heitz (jheitz) <jheitz@cisco.com>
> Cc: Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram@nist.gov>; Job Sn= ijders
> <job@ntt.net&g= t;; Nick Hilliard <= nick@foobar.org>; John Heasly
> <heas@shrub= bery.net>; idr@iet= f.org; grow@ietf.org= ; idr-chairs@i= etf.org;
> grow-chairs@= ietf.org; a.e= .azimov@gmail.com; Brian Dickson
> <brian.peter.dickson@gmail.com>
> Subject: Re: Question about BGP Large Communities
>
> Tue, Feb 04, 2020 at 08:45:40PM +0000, Jakob Heitz (jheitz):
> > A set of well known large communities could be useful.
> > I have a draft that I never submitted attached to this email.
> > Does anyone want to co-author and suggest changes?
>
> Hey Jacob,
> I'd work on that with you.=C2=A0 Job, Morrow and I also started a = draft for
> Large WKCs, but we have not submitted anything - nor made any recent > progress.
>
> IIRC, the direction we were intending to use 0 (zero) as the ASN, then=
> define local data part 1 as WKC itself, and local data part 2 to be a<= br> > value associated.
>
> I've attached that I have written so far.=C2=A0 Job and Morrow may= or may not
> endorse this approach at this point.
>
> -heas
--000000000000c7bddc059dca473b-- From nobody Tue Feb 4 17:44:08 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D681120115; Tue, 4 Feb 2020 17:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_ENHANCEMENT=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-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=Q+8dzA2i; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=sd0HBd/p Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hnFA5TN179yt; Tue, 4 Feb 2020 17:44:04 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B335112006E; Tue, 4 Feb 2020 17:44:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3331; q=dns/txt; s=iport; t=1580867044; x=1582076644; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eDD9TQdOdOJ3X72lUch180UGxbvRqMsbnAR4NO9GL88=; b=Q+8dzA2iQjEMeMHE34+rh9JOD+HM6s2rqqI23i9cnQd+nmzAySn94L+v 2o8JZ3Z8H6PRkJF95rgKGbegdV9O6BxRmx069lMRCrr8Dg2gYzO4JF8Kl lHCN6dXc1w0eapCFjw3qHVFsnx330DDuqyN5jRrnKLZH2x6y+9XA3Ij1r E=; IronPort-PHdr: =?us-ascii?q?9a23=3A4V6bXR+rc0Ej7/9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/bR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVcyFBEznPtbhbjcxG4JJU1o2t3w=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AmAAC/HDpe/5tdJa1lGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBaAUBAQELAYFTKScFgUQgBAsqCodRA4sCgl+JYY4ugS4?= =?us-ascii?q?UgRADVAkBAQEMAQEtAgEBhEACgjckNQgOAgMNAQEEAQEBAgEFBG2FNwyFZgE?= =?us-ascii?q?BAQECARIoBgEBNwELBAIBCBEEAQEfECERHQgBAQQBDQUIGoMvAYIfAw4gAaF?= =?us-ascii?q?GAoE5iGKCJ4J/AQEFhTENC4IMCYE4AYwhGoFBP4EQAUeCTD6CG4F7ARIBIyS?= =?us-ascii?q?DHIIsryNECoI7khmERZsIjmGLD5ALAgQCBAUCDgEBBYFUAzRncXAVgydQGA2?= =?us-ascii?q?OHQeDbIpTdAKBJ4pggSIBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.70,404,1574121600"; d="scan'208";a="443992171" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Feb 2020 01:44:03 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 0151i3FY027316 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2020 01:44:03 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 4 Feb 2020 19:44:03 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 4 Feb 2020 19:44:02 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 4 Feb 2020 19:44:02 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PbBlk/9iJ48YxQsKoTP6LloPToOg5zWbz3gB26/ApaTS9dmvNAdRK1NiOEPLAXrBKn1DMv/v/U6hBMZZXIieAaWBoYeZQxgmdx+/K0k3SlNYvmShEfzI+MzYM9rnl7v5/gWJxlJNoRZnH5at1MtzcIrZ4moJ8WEDUCZ0hn75hJb2BmeDwM6mEy3HzJXRujbg6t5E8jZSk+2KXgqX3eB5KOBR5gb/TVySY0+S39yuabRK3EpkMe5tswf4J/h+OBZw5hXo3kztGiLMlGSooIcl/SEZLEYG4bcO4gDsCoWBVI4LJwKsBDVgk2Bhx162heVjx7Jjj/ZEc5ZXr1GUhqmSag== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rivuql42d1o3OcjdBs8cUYAyZS9qlUacMsRDICAgABQ=; b=EMPH8vF1pFAv/Cdp+EjgIwR9N9Pb96bKNu6ueqe09PW0H5kF4a802ClE+fMjK4nc0u1bxwVd/u4g2mx4xsA16pDOAtDCja8r+Q5cTwwa1v/nbMpIKnNYF0IkzGKdsQZvkoQVqTafac1Ll+D6cVCn6tH1HHLm8seNMma5dAAgcFgeKoMWmmU9512VTdn7yYklwXMLM2PWx6zSEeUAqvnMS94MtYglfNqRPcL8Xj3DlN/KavrBLLyeLRCm+aKAWFUXBJ8xwW9bRhi0ZI9iTg7Pi70b5QBBjMQIThWK6ikgmxugT6rlpF/XQfXN0qjbUhUOi+gn6aI/L7vAaGyzUGX37A== 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=Rivuql42d1o3OcjdBs8cUYAyZS9qlUacMsRDICAgABQ=; b=sd0HBd/p1HqIw+39M0YTEdI+NSUxn4M/lU8/TyBeDgoh2pNe/9qmOYknnygcSTeHF9K3HosCh0CUKX0DxuoY6KJelZ45vN9X8VHh+36vCNbWzxKAGiSPCjt0VrO7pkzhAwZHytgBWSsDWe/KlvksI18UHK/QRnBKSgnxMPgqNe8= Received: from MWHPR11MB1901.namprd11.prod.outlook.com (10.175.54.12) by MWHPR11MB2047.namprd11.prod.outlook.com (10.169.237.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.27; Wed, 5 Feb 2020 01:44:01 +0000 Received: from MWHPR11MB1901.namprd11.prod.outlook.com ([fe80::5109:65e6:5d:db41]) by MWHPR11MB1901.namprd11.prod.outlook.com ([fe80::5109:65e6:5d:db41%3]) with mapi id 15.20.2707.020; Wed, 5 Feb 2020 01:44:01 +0000 From: "Jakob Heitz (jheitz)" To: "Sriram, Kotikalapudi (Fed)" , John Heasly CC: "idr@ietf.org" , "grow@ietf.org" Thread-Topic: Question about BGP Large Communities Thread-Index: AdXbeNI4t0SppYFnSky8PqLGmuct1gAIu5NAAASXzAAAA08B8AACeZhw Date: Wed, 5 Feb 2020 01:44:01 +0000 Message-ID: References: <20200204225458.GB57481@shrubbery.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jheitz@cisco.com; x-originating-ip: [128.107.241.189] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fd2dda23-0e45-46b8-5f07-08d7a9dce016 x-ms-traffictypediagnostic: MWHPR11MB2047: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(346002)(39860400002)(136003)(366004)(396003)(189003)(199004)(66446008)(66946007)(66556008)(66476007)(26005)(64756008)(76116006)(2906002)(110136005)(33656002)(316002)(4326008)(478600001)(55016002)(54906003)(9686003)(186003)(8936002)(81166006)(81156014)(53546011)(86362001)(6506007)(8676002)(5660300002)(71200400001)(52536014)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB2047; H:MWHPR11MB1901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: UHeSiqWmaJwrrxe+8Q8ywCIEjzUdUnMQmsjJxiUeLlKNF17/91oya/1AH3W79Ik8PK+D2+CsUBTHgxKtZ0znLrcgSt2LvGhb3ea+n7NJzXH7UtCI5dJNIhKDQCQCkp21oMgqLKMnONxxCFJ88No+P7dNxtv762VG1hW5ELoFz4CmSLBiIaIbicNMUwd6FEVygs2q/QwLWv0IVHo8sPoossAg6dydVJJlt36ehmKjwcQEYdyFEaK/X5TYqrc8xVCnfDCKkhNFQk4GMMCuOxMEQLfGuyTjryy6plwiZOGyDpjO/loUctC84GGWhYkZ/b8DMO2zBa+75kTepTYHUG3qDYtSatVGl5EzG4q7UlD/oZZgUF6+5PTWhZYzLhbrosCdoC/MXLDhoGU4plmx7zJA8yRXZzmaMtv7oGPGwQryr6gN6WTfxBm6Et3Fyy33D6lw x-ms-exchange-antispam-messagedata: gCKfe1CVtqxG2FXBw0Rvufp3Z/dlPJ2XLCZWVB/JNYiGCcmKW6hNmlv/O9aNl+KkwuOQ14TawXq9wgZ7kNr0RYUi9f7DvzbdRS+Bj4gEj1nu4zVC829YBOuSQrXyL/cWcbjUPz8D+FSUE27zCUkD+A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fd2dda23-0e45-46b8-5f07-08d7a9dce016 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2020 01:44:01.2466 (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: 9kA+q5ZOWf0QM3MhPJNWemXyE4bYchRwr50DbpwmKEd3AskEGM4waI2hR+dflIYXaRmjJU9mmJYkjZWbXGAsWA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB2047 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [Idr] Question about BGP Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 01:44:07 -0000 I'm asking for 67 million AS numbers, after which there will still be over = 4 billion AS numbers, not including the nearly 95 million private AS numbers. That's not much more than your 1024. Regards, Jakob. -----Original Message----- From: Sriram, Kotikalapudi (Fed) =20 Sent: Tuesday, February 4, 2020 5:29 PM To: John Heasly ; Jakob Heitz (jheitz) Cc: idr@ietf.org; grow@ietf.org Subject: RE: Question about BGP Large Communities > > Does anyone want to co-author and suggest changes? I would also be glad to participate in that effort. I have looked at the proposals in the two drafts (Jacob and John H). =20 There are a few observations I would like to share. As Alvaro pointed out, RFC 8092 says: This document defines the BGP Large Communities attribute as an optional transitive path attribute of variable length. That means *all* BGP Large Communities are transitive. Do you agree? RFC 8195 seems to be written in that spirit as well.=20 The first 32 bits together are a Global Administrator (GA) ID. So, it seems it would not be possible to use any part of it as data. Otherwise, collisions (ambiguity) could happen when=20 other LCs use 4-octet ASNs in the Global Administrator field. Agree? I see Jacob's draft proposes using some portion of the first 32 bits as dat= a. The draft that John Heasly shared sets the first 32-bits to ASN value 0 to designate WK-LC; so no part of the first 32-bits is data. Another idea to consider:=20 Why not request IANA to assign a range of 256 or 1024 or some number (?)=20 of 4-byte ASN values to be allocated and used as GA ID for transitive WK-LC= s? A function (e.g., route-leak protection) that requires transitive WK-LC=20 will be allocated one these ASN values. Then we don't waste any part of the first 32-bits to designate "type" of LC= . That cleanly leaves 64 bits for local data (as RFC 8092 specifies) which can accommodate two 4-byte ASNs if needed. Sriram > -----Original Message----- > From: John Heasly > Sent: Tuesday, February 4, 2020 5:55 PM > To: Jakob Heitz (jheitz) > Cc: Sriram, Kotikalapudi (Fed) ; Job Snijde= rs > ; Nick Hilliard ; John Heasly > ; idr@ietf.org; grow@ietf.org; idr-chairs@ietf.org; > grow-chairs@ietf.org; a.e.azimov@gmail.com; Brian Dickson > > Subject: Re: Question about BGP Large Communities >=20 > Tue, Feb 04, 2020 at 08:45:40PM +0000, Jakob Heitz (jheitz): > > A set of well known large communities could be useful. > > I have a draft that I never submitted attached to this email. > > Does anyone want to co-author and suggest changes? >=20 > Hey Jacob, > I'd work on that with you. Job, Morrow and I also started a draft for > Large WKCs, but we have not submitted anything - nor made any recent > progress. >=20 > IIRC, the direction we were intending to use 0 (zero) as the ASN, then > define local data part 1 as WKC itself, and local data part 2 to be a > value associated. >=20 > I've attached that I have written so far. Job and Morrow may or may not > endorse this approach at this point. >=20 > -heas From nobody Tue Feb 4 17:45:09 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBE41200E7; Tue, 4 Feb 2020 17:45:05 -0800 (PST) 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, BODY_ENHANCEMENT=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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, T_KAM_HTML_FONT_INVALID=0.01] 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 mjj-uchf2fTt; Tue, 4 Feb 2020 17:45:03 -0800 (PST) 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 76A4B12006E; Tue, 4 Feb 2020 17:45:03 -0800 (PST) Received: by mail-ua1-x935.google.com with SMTP id c7so270163uaf.5; Tue, 04 Feb 2020 17:45:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JHJ8cNsVGo/8tydYvLsCT+OzwLT2Q9jx58D5nPSCwh4=; b=DuaIW8XzqP9L14ZSXZsaFlTwN5jEIr07t87XyWDrJysnEliC67xIbDvXXzJpJuK74s RRYKf9BUvXdbvUv9sOjMaJphXA/pWZPCniIoSB1OunbLHTMx0P+OVvqHFeOhN+oJ0TAk Wv/ATSsQgjOuVkH+XIkg8oMBqvLlkQzZbrIaogu6dV6Wgk1zHfcnPJZwVYo7SmK5upId q/v/2cCOYPln7QkeDqikAZQiRV0l2gmmqSZggXMtDD3ZY8kptfkZW3c53zFBQMdLrWrZ pDXT/tIixqctwrmw2TiwIVvhyTxcgxaMOeavTvXs23LV4g5cD2k9mTWas7b6hKIgWuPT 0pHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JHJ8cNsVGo/8tydYvLsCT+OzwLT2Q9jx58D5nPSCwh4=; b=CP64CXE2QODlJWMScko6SRY9SA6vJEoVDUnRquABPWSdkIWABs68Q4dLuwXp/ZU+Qc m2wOFaRMBmImcbaEf3I/tEc+WU/+5o7iuqC/VpUuewvihupbNnMBmv/nHL5MTZjPlGOS 60LBIMJNmqBJYNvT1YcNx5sI+PL6TsXG+TJhrVgLvQ+JO9h11y0PZ5GBnILlaZaAeYvn B4ebtfscF1PdnkHJkQCIQ2gTOO9GKwMOif18YAEimv2GU/Q4NBVMCjf1TS/Vj3r4PrvV iq5BitkixA42YVlnPGxKEy4/Sj35W6c1fdbyGWByKZ7NptlJQop5s8w8J7BqKbFsQQIz Azaw== X-Gm-Message-State: APjAAAVkHBsEu7mtO8qUVr3D9362pWvqp5EHrxgk9TIXtimQopY8oPu4 w8sv0Z7V/ZDJBjWhdcEGTpFmv9DyH+EXGgIHfuk= X-Google-Smtp-Source: APXvYqxEvPRil03YFFDtK52/V87suqhgUXNa8yFwmoPxMvW38zSmKAbLsQEvl+5Q7YKCxdXJSplqaTHxMPXGh0umD8E= X-Received: by 2002:ab0:74c8:: with SMTP id f8mr18432339uaq.114.1580867102592; Tue, 04 Feb 2020 17:45:02 -0800 (PST) MIME-Version: 1.0 References: <5603F4C9-7ECD-4A9C-AF81-49AE292CEE83@cisco.com> <90fab3d5ec794e95be0d86cae2d4a235@huawei.com> In-Reply-To: <90fab3d5ec794e95be0d86cae2d4a235@huawei.com> From: Brian Dickson Date: Tue, 4 Feb 2020 17:44:51 -0800 Message-ID: To: "Dongjie (Jimmy)" Cc: Robert Raszuk , "Jakob Heitz (jheitz)" , "idr@ietf.org" , "grow-chairs@ietf.org" , "idr-chairs@ietf.org" , "grow@ietf.org" Content-Type: multipart/alternative; boundary="000000000000165362059dca4eb5" Archived-At: Subject: Re: [Idr] [GROW] Question about BGP Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 01:45:05 -0000 --000000000000165362059dca4eb5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Disagree, we want something deployed (large) and deployable (requiring only IANA action, no vendor activity) immediately. IMHO, any special handling or new code points or upgrades are non-starters. This particularly applies to wide and extended Brian On Tue, Feb 4, 2020 at 5:41 PM Dongjie (Jimmy) wrote: > Agree that for this case it may be more convenient to just use extended > community with a new type, this could avoid any possible collision with > existing deployments, and save the effort of assigning a set of ASNs. Wid= e > community may be too powerful for this:) > > > > Best regards, > > Jie > > > > *From:* Robert Raszuk [mailto:robert@raszuk.net] > *Sent:* Wednesday, February 5, 2020 6:38 AM > *To:* Jakob Heitz (jheitz) > *Cc:* Sriram, Kotikalapudi (Fed) ; Job > Snijders ; Nick Hilliard ; John Heasly < > heas@shrubbery.net>; idr@ietf.org; grow-chairs@ietf.org; > idr-chairs@ietf.org; grow@ietf.org > *Subject:* Re: [GROW] Question about BGP Large Communities > > > > > > > How would you divide the numbers? > > > > I would not divide them at all in LCs. I would either define new type in > extended communities or use wide communities. > > > > But I am a bit biased here ;-) > > > > Best, > > R, > > > > On Tue, Feb 4, 2020 at 11:34 PM Jakob Heitz (jheitz) > wrote: > > The numbers are a trade off. How would you divide the numbers? > > Thanks, > > Jakob. > > > > On Feb 4, 2020, at 2:19 PM, Robert Raszuk wrote: > > =EF=BB=BF > > And you think 255 such known large communities will be sufficient ? > > > > Thx, > > R. > > > > On Tue, Feb 4, 2020 at 9:45 PM Jakob Heitz (jheitz) > wrote: > > A set of well known large communities could be useful. > > I have a draft that I never submitted attached to this email. > > Does anyone want to co-author and suggest changes? > > > > Regards, > > Jakob. > > > > *From:* Sriram, Kotikalapudi (Fed) > *Sent:* Tuesday, February 4, 2020 10:22 AM > *To:* Jakob Heitz (jheitz) ; Job Snijders = ; > Nick Hilliard ; John Heasly > *Cc:* idr@ietf.org; grow@ietf.org; idr-chairs@ietf.org; > grow-chairs@ietf.org; a.e.azimov@gmail.com; Brian Dickson < > brian.peter.dickson@gmail.com> > *Subject:* Question about BGP Large Communities > > > > In the route leaks solution draft, > > > https://tools.ietf.org/html/draft-ietf-grow-route-leak-detection-mitigati= on-02 > > we (the authors) have proposed using BGP Large Community. > > We specify this to be a "well-known transitive Large Community". > > > > Question: > > Can the draft simply make an IANA request for > > a Global Administrator ASN value for Route Leaks Protection (RLP) type > > and request that it be published in IANA registry > > as a "well-known Transitive Large Community"? > > > > There is no IANA registry for Large Communities yet; > > we have requested IDR and GROW Chairs to facilitate that. > > > > ---------------- > > Details/background: > > > > We've read the following RFCs related to Large Communities: > > https://tools.ietf.org/html/rfc8092 > > https://tools.ietf.org/html/rfc8195 > > > > RFC 8195 has this table: > > > +-------------------------------+-----------------------= --+ > > | RFC8092 | RFC > 8195 | > > > +-------------------------------+--------------------------+ > > | Global Administrator | ASN = | > > | Local Data Part 1 | Function > | > > | Local Data Part 2 | Parameter = | > > > +--------------------------------+-------------------------+ > > which is instructive. In the examples that RFC 8195 offers, > > it appears it is *assumed* that the Large Communities are transitive. > > > > For comparison, in Extended Communities (RFC 7153), there are > > explicit Type values assigned for Transitive, Non-transitive, etc. > > > https://www.iana.org/assignments/bgp-extended-communities/bgp-extended-co= mmunities.xhtml > > However, there is no such explicit Type specification > > for Large Communities (in RFC 8092 or elsewhere). > > > > Thank you. > > Sriram > > > > > > > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow > --000000000000165362059dca4eb5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Disagree, we want something deployed (large) and deployabl= e (requiring only IANA action, no vendor activity) immediately.
IMHO, a= ny special handling or new code points or upgrades are non-starters.
<= div>This particularly applies to wide and extended
Brian

On = Tue, Feb 4, 2020 at 5:41 PM Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Agree that for this case it= may be more convenient to just use extended community with a new type, thi= s could avoid any possible collision with existing deployments, and save the effort of assigning a set of ASNs. Wide communit= y may be too powerful for this:)

=C2=A0=

Best regards,=

Jie

=C2=A0=

From: Robert Raszuk [mailto:robert@raszuk.net]
Sent: Wednesday, February 5, 2020 6:38 AM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>
Cc: Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram@nist.gov>; Job = Snijders <job@ntt.net>; Nick Hilliard <nick@foobar.org>; John Heasly <heas@shrubbery.net>; idr@ietf.org; grow-chairs@ietf.org; idr-chairs@ietf.org; grow@ietf.org
Subject: Re: [GROW] Question about BGP Large Communities

=C2=A0

=C2=A0

> How would you divide the n= umbers?=C2=A0=C2=A0

=C2=A0

I would not divide them at all = in=C2=A0LCs. I would either define new type in extended communities or use = wide communities.=C2=A0

=C2=A0

But I am a bit biased here ;-)<= u>

=C2=A0

Best,

R,

=C2=A0

On Tue, Feb 4, 2020 at 11:34 PM= Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:

Th= e numbers are a trade off. How would you divide the numbers?<= /span>

Thanks,

Jakob.



On= Feb 4, 2020, at 2:19 PM, Robert Raszuk <robert@raszuk.net> wrote:

=EF=BB=BF

And you think 255 such known la= rge communities will be sufficient ?

=C2=A0

Thx,

R.

=C2=A0

On Tue, Feb 4, 2020 at 9:45 PM = Jakob Heitz (jheitz) <jheitz@cisco.com> wrote:

A set of well known lar= ge communities could be useful.

I have a draft that I n= ever submitted attached to this email.

Does anyone want to co-= author and suggest changes?

=C2=A0

Regards,

Jakob.

=C2=A0

From: Sriram, Kotikalapudi (Fed) <kotikalapudi.sriram@nist.gov>
Sent: Tuesday, February 4, 2020 10:22 AM
To: Jakob Heitz (jheitz) <jheitz@cisco.com>; Job Snijders <job@ntt.net>; Nick Hilliard <nick@foobar.org>; John Heasly <he= as@shrubbery.net>
Cc: idr@ietf.org; grow@ietf.org; idr-chairs@ietf.org; grow-chairs@ietf.= org; a.e.azimov@gmail.com; Brian Dickson <brian.peter.dickson@gmail.com> Subject: Question about BGP Large Communities

=C2=A0

In the route leaks solution draft,

https://tools.iet= f.org/html/draft-ietf-grow-route-leak-detection-mitigation-02=

we (the authors) have proposed using BGP Large Comm= unity.

We specify this to be a "well-known transitive= Large Community".

=C2=A0

Question:

Can the draft simply make an IANA request for

a Global Administrator ASN value for Route Leaks Pr= otection (RLP) type

and request that it be published in IANA registry <= u>

as a "well-known Transitive Large Community&qu= ot;?

=C2=A0

There is no IANA registry for Large Communities yet= ;

we have requested IDR and GROW Chairs to facilitate= that.

=C2=A0

----------------

Details/background:

=C2=A0

We've read the following RFCs related to Large = Communities:

https:= //tools.ietf.org/html/rfc8092

https:= //tools.ietf.org/html/rfc8195

=C2=A0

RFC 8195 has this table:

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0+-----------------------= --------+-------------------------+

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 RFC8092=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | RFC 8195=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +----------------------------= ---+--------------------------+

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Global Administrator=C2=A0= =C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ASN=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 Local Data Part 1=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2= =A0 Function=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 |

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 Local Data Part 2=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0 Par= ameter=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=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 +----------------------------= ----+-------------------------+

which is instructive. In the examples that RFC 8195= offers,

it appears it is *assumed* that the Large Communiti= es are transitive.

=C2=A0

For comparison, in Extended Communities (RFC 7153),= there are

explicit Type values assigned for Transitive, Non-t= ransitive, etc.

https://www.iana.org/assignments/bgp-extended-communities/bg= p-extended-communities.xhtml<= /span>

However, there is no such explicit Type specificati= on

for Large Communities (in RFC 8092 or elsewhere).

=C2=A0

Thank you.

Sriram

=C2=A0

=C2=A0

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

_______________________________= ________________
GROW mailing list
GROW@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/grow

_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
--000000000000165362059dca4eb5-- From nobody Tue Feb 4 17:58:28 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B08512006E; Tue, 4 Feb 2020 17:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_ENHANCEMENT=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 imq7DCOj8-uQ; Tue, 4 Feb 2020 17:40:31 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 74DE11200E7; Tue, 4 Feb 2020 17:40:31 -0800 (PST) Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id EC9B565FDFC3A7813ABB; Wed, 5 Feb 2020 01:40:25 +0000 (GMT) Received: from nkgeml701-chm.china.huawei.com (10.98.57.156) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 5 Feb 2020 01:40:24 +0000 Received: from nkgeml701-chm.china.huawei.com (10.98.57.156) by nkgeml701-chm.china.huawei.com (10.98.57.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 5 Feb 2020 09:40:22 +0800 Received: from nkgeml701-chm.china.huawei.com ([10.98.57.156]) by nkgeml701-chm.china.huawei.com ([10.98.57.156]) with mapi id 15.01.1713.004; Wed, 5 Feb 2020 09:40:22 +0800 From: "Dongjie (Jimmy)" To: Robert Raszuk , "Jakob Heitz (jheitz)" CC: "Sriram, Kotikalapudi (Fed)" , Job Snijders , Nick Hilliard , John Heasly , "idr@ietf.org" , "grow-chairs@ietf.org" , "idr-chairs@ietf.org" , "grow@ietf.org" Thread-Topic: [GROW] Question about BGP Large Communities Thread-Index: AdXbeNI4t0SppYFnSky8PqLGmuct1gAIu5NA//+UeoCAAAOcAIAAAbeA//9KBuA= Date: Wed, 5 Feb 2020 01:40:22 +0000 Message-ID: <90fab3d5ec794e95be0d86cae2d4a235@huawei.com> References: <5603F4C9-7ECD-4A9C-AF81-49AE292CEE83@cisco.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.45.220.187] Content-Type: multipart/alternative; boundary="_000_90fab3d5ec794e95be0d86cae2d4a235huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Tue, 04 Feb 2020 17:58:26 -0800 Subject: Re: [Idr] [GROW] Question about BGP Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 01:40:34 -0000 --_000_90fab3d5ec794e95be0d86cae2d4a235huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWUgdGhhdCBmb3IgdGhpcyBjYXNlIGl0IG1heSBiZSBtb3JlIGNvbnZlbmllbnQgdG8ganVz dCB1c2UgZXh0ZW5kZWQgY29tbXVuaXR5IHdpdGggYSBuZXcgdHlwZSwgdGhpcyBjb3VsZCBhdm9p ZCBhbnkgcG9zc2libGUgY29sbGlzaW9uIHdpdGggZXhpc3RpbmcgZGVwbG95bWVudHMsIGFuZCBz YXZlIHRoZSBlZmZvcnQgb2YgYXNzaWduaW5nIGEgc2V0IG9mIEFTTnMuIFdpZGUgY29tbXVuaXR5 IG1heSBiZSB0b28gcG93ZXJmdWwgZm9yIHRoaXM6KQ0KDQpCZXN0IHJlZ2FyZHMsDQpKaWUNCg0K RnJvbTogUm9iZXJ0IFJhc3p1ayBbbWFpbHRvOnJvYmVydEByYXN6dWsubmV0XQ0KU2VudDogV2Vk bmVzZGF5LCBGZWJydWFyeSA1LCAyMDIwIDY6MzggQU0NClRvOiBKYWtvYiBIZWl0eiAoamhlaXR6 KSA8amhlaXR6QGNpc2NvLmNvbT4NCkNjOiBTcmlyYW0sIEtvdGlrYWxhcHVkaSAoRmVkKSA8a290 aWthbGFwdWRpLnNyaXJhbUBuaXN0Lmdvdj47IEpvYiBTbmlqZGVycyA8am9iQG50dC5uZXQ+OyBO aWNrIEhpbGxpYXJkIDxuaWNrQGZvb2Jhci5vcmc+OyBKb2huIEhlYXNseSA8aGVhc0BzaHJ1YmJl cnkubmV0PjsgaWRyQGlldGYub3JnOyBncm93LWNoYWlyc0BpZXRmLm9yZzsgaWRyLWNoYWlyc0Bp ZXRmLm9yZzsgZ3Jvd0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtHUk9XXSBRdWVzdGlvbiBhYm91 dCBCR1AgTGFyZ2UgQ29tbXVuaXRpZXMNCg0KDQo+IEhvdyB3b3VsZCB5b3UgZGl2aWRlIHRoZSBu dW1iZXJzPw0KDQpJIHdvdWxkIG5vdCBkaXZpZGUgdGhlbSBhdCBhbGwgaW4gTENzLiBJIHdvdWxk IGVpdGhlciBkZWZpbmUgbmV3IHR5cGUgaW4gZXh0ZW5kZWQgY29tbXVuaXRpZXMgb3IgdXNlIHdp ZGUgY29tbXVuaXRpZXMuDQoNCkJ1dCBJIGFtIGEgYml0IGJpYXNlZCBoZXJlIDstKQ0KDQpCZXN0 LA0KUiwNCg0KT24gVHVlLCBGZWIgNCwgMjAyMCBhdCAxMTozNCBQTSBKYWtvYiBIZWl0eiAoamhl aXR6KSA8amhlaXR6QGNpc2NvLmNvbTxtYWlsdG86amhlaXR6QGNpc2NvLmNvbT4+IHdyb3RlOg0K VGhlIG51bWJlcnMgYXJlIGEgdHJhZGUgb2ZmLiBIb3cgd291bGQgeW91IGRpdmlkZSB0aGUgbnVt YmVycz8NClRoYW5rcywNCkpha29iLg0KDQoNCk9uIEZlYiA0LCAyMDIwLCBhdCAyOjE5IFBNLCBS b2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+ PiB3cm90ZToNCu+7vw0KQW5kIHlvdSB0aGluayAyNTUgc3VjaCBrbm93biBsYXJnZSBjb21tdW5p dGllcyB3aWxsIGJlIHN1ZmZpY2llbnQgPw0KDQpUaHgsDQpSLg0KDQpPbiBUdWUsIEZlYiA0LCAy MDIwIGF0IDk6NDUgUE0gSmFrb2IgSGVpdHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb208bWFp bHRvOmpoZWl0ekBjaXNjby5jb20+PiB3cm90ZToNCkEgc2V0IG9mIHdlbGwga25vd24gbGFyZ2Ug Y29tbXVuaXRpZXMgY291bGQgYmUgdXNlZnVsLg0KSSBoYXZlIGEgZHJhZnQgdGhhdCBJIG5ldmVy IHN1Ym1pdHRlZCBhdHRhY2hlZCB0byB0aGlzIGVtYWlsLg0KRG9lcyBhbnlvbmUgd2FudCB0byBj by1hdXRob3IgYW5kIHN1Z2dlc3QgY2hhbmdlcz8NCg0KUmVnYXJkcywNCkpha29iLg0KDQpGcm9t OiBTcmlyYW0sIEtvdGlrYWxhcHVkaSAoRmVkKSA8a290aWthbGFwdWRpLnNyaXJhbUBuaXN0Lmdv djxtYWlsdG86a290aWthbGFwdWRpLnNyaXJhbUBuaXN0Lmdvdj4+DQpTZW50OiBUdWVzZGF5LCBG ZWJydWFyeSA0LCAyMDIwIDEwOjIyIEFNDQpUbzogSmFrb2IgSGVpdHogKGpoZWl0eikgPGpoZWl0 ekBjaXNjby5jb208bWFpbHRvOmpoZWl0ekBjaXNjby5jb20+PjsgSm9iIFNuaWpkZXJzIDxqb2JA bnR0Lm5ldDxtYWlsdG86am9iQG50dC5uZXQ+PjsgTmljayBIaWxsaWFyZCA8bmlja0Bmb29iYXIu b3JnPG1haWx0bzpuaWNrQGZvb2Jhci5vcmc+PjsgSm9obiBIZWFzbHkgPGhlYXNAc2hydWJiZXJ5 Lm5ldDxtYWlsdG86aGVhc0BzaHJ1YmJlcnkubmV0Pj4NCkNjOiBpZHJAaWV0Zi5vcmc8bWFpbHRv OmlkckBpZXRmLm9yZz47IGdyb3dAaWV0Zi5vcmc8bWFpbHRvOmdyb3dAaWV0Zi5vcmc+OyBpZHIt Y2hhaXJzQGlldGYub3JnPG1haWx0bzppZHItY2hhaXJzQGlldGYub3JnPjsgZ3Jvdy1jaGFpcnNA aWV0Zi5vcmc8bWFpbHRvOmdyb3ctY2hhaXJzQGlldGYub3JnPjsgYS5lLmF6aW1vdkBnbWFpbC5j b208bWFpbHRvOmEuZS5hemltb3ZAZ21haWwuY29tPjsgQnJpYW4gRGlja3NvbiA8YnJpYW4ucGV0 ZXIuZGlja3NvbkBnbWFpbC5jb208bWFpbHRvOmJyaWFuLnBldGVyLmRpY2tzb25AZ21haWwuY29t Pj4NClN1YmplY3Q6IFF1ZXN0aW9uIGFib3V0IEJHUCBMYXJnZSBDb21tdW5pdGllcw0KDQoNCklu IHRoZSByb3V0ZSBsZWFrcyBzb2x1dGlvbiBkcmFmdCwNCg0KaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtZ3Jvdy1yb3V0ZS1sZWFrLWRldGVjdGlvbi1taXRpZ2F0aW9uLTAy DQoNCndlICh0aGUgYXV0aG9ycykgaGF2ZSBwcm9wb3NlZCB1c2luZyBCR1AgTGFyZ2UgQ29tbXVu aXR5Lg0KDQpXZSBzcGVjaWZ5IHRoaXMgdG8gYmUgYSAid2VsbC1rbm93biB0cmFuc2l0aXZlIExh cmdlIENvbW11bml0eSIuDQoNCg0KDQpRdWVzdGlvbjoNCg0KQ2FuIHRoZSBkcmFmdCBzaW1wbHkg bWFrZSBhbiBJQU5BIHJlcXVlc3QgZm9yDQoNCmEgR2xvYmFsIEFkbWluaXN0cmF0b3IgQVNOIHZh bHVlIGZvciBSb3V0ZSBMZWFrcyBQcm90ZWN0aW9uIChSTFApIHR5cGUNCg0KYW5kIHJlcXVlc3Qg dGhhdCBpdCBiZSBwdWJsaXNoZWQgaW4gSUFOQSByZWdpc3RyeQ0KDQphcyBhICJ3ZWxsLWtub3du IFRyYW5zaXRpdmUgTGFyZ2UgQ29tbXVuaXR5Ij8NCg0KDQoNClRoZXJlIGlzIG5vIElBTkEgcmVn aXN0cnkgZm9yIExhcmdlIENvbW11bml0aWVzIHlldDsNCg0Kd2UgaGF2ZSByZXF1ZXN0ZWQgSURS IGFuZCBHUk9XIENoYWlycyB0byBmYWNpbGl0YXRlIHRoYXQuDQoNCg0KDQotLS0tLS0tLS0tLS0t LS0tDQoNCkRldGFpbHMvYmFja2dyb3VuZDoNCg0KDQoNCldlJ3ZlIHJlYWQgdGhlIGZvbGxvd2lu ZyBSRkNzIHJlbGF0ZWQgdG8gTGFyZ2UgQ29tbXVuaXRpZXM6DQoNCmh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9yZmM4MDkyDQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MTk1 DQoNCg0KDQpSRkMgODE5NSBoYXMgdGhpcyB0YWJsZToNCg0KICAgICAgICAgICAgICAgICArLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKw0K DQogICAgICAgICAgICAgICAgIHwgICAgICAgUkZDODA5MiAgICAgICAgICAgICAgICAgICAgfCBS RkMgODE5NSAgICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCiAgICAg ICAgICAgICAgICAgfCBHbG9iYWwgQWRtaW5pc3RyYXRvciAgICB8ICAgICAgQVNOICAgICAgICAg ICAgICAgICAgICAgfA0KDQogICAgICAgICAgICAgICAgIHwgIExvY2FsIERhdGEgUGFydCAxICAg ICAgICAgICB8ICAgIEZ1bmN0aW9uICAgICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICAgICAg fCAgTG9jYWwgRGF0YSBQYXJ0IDIgICAgICAgICAgIHwgICBQYXJhbWV0ZXIgICAgICAgICAgICB8 DQoNCiAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tKy0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCndoaWNoIGlzIGluc3RydWN0aXZlLiBJbiB0aGUg ZXhhbXBsZXMgdGhhdCBSRkMgODE5NSBvZmZlcnMsDQoNCml0IGFwcGVhcnMgaXQgaXMgKmFzc3Vt ZWQqIHRoYXQgdGhlIExhcmdlIENvbW11bml0aWVzIGFyZSB0cmFuc2l0aXZlLg0KDQoNCg0KRm9y IGNvbXBhcmlzb24sIGluIEV4dGVuZGVkIENvbW11bml0aWVzIChSRkMgNzE1MyksIHRoZXJlIGFy ZQ0KDQpleHBsaWNpdCBUeXBlIHZhbHVlcyBhc3NpZ25lZCBmb3IgVHJhbnNpdGl2ZSwgTm9uLXRy YW5zaXRpdmUsIGV0Yy4NCg0KaHR0cHM6Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvYmdwLWV4 dGVuZGVkLWNvbW11bml0aWVzL2JncC1leHRlbmRlZC1jb21tdW5pdGllcy54aHRtbA0KDQpIb3dl dmVyLCB0aGVyZSBpcyBubyBzdWNoIGV4cGxpY2l0IFR5cGUgc3BlY2lmaWNhdGlvbg0KDQpmb3Ig TGFyZ2UgQ29tbXVuaXRpZXMgKGluIFJGQyA4MDkyIG9yIGVsc2V3aGVyZSkuDQoNCg0KDQpUaGFu ayB5b3UuDQoNClNyaXJhbQ0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCkdST1cgbWFpbGluZyBsaXN0DQpHUk9XQGlldGYub3JnPG1h aWx0bzpHUk9XQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9ncm93DQo= --_000_90fab3d5ec794e95be0d86cae2d4a235huaweicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgt Q04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+QWdyZWUgdGhhdCBmb3IgdGhpcyBjYXNlIGl0IG1heSBiZSBtb3JlIGNvbnZl bmllbnQgdG8ganVzdCB1c2UgZXh0ZW5kZWQgY29tbXVuaXR5IHdpdGggYSBuZXcgdHlwZSwgdGhp cyBjb3VsZCBhdm9pZCBhbnkgcG9zc2libGUgY29sbGlzaW9uIHdpdGggZXhpc3RpbmcNCiBkZXBs b3ltZW50cywgYW5kIHNhdmUgdGhlIGVmZm9ydCBvZiBhc3NpZ25pbmcgYSBzZXQgb2YgQVNOcy4g V2lkZSBjb21tdW5pdHkgbWF5IGJlIHRvbyBwb3dlcmZ1bCBmb3IgdGhpczopPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkppZTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5n OjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFJvYmVydCBSYXN6dWsg W21haWx0bzpyb2JlcnRAcmFzenVrLm5ldF0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXks IEZlYnJ1YXJ5IDUsIDIwMjAgNjozOCBBTTxicj4NCjxiPlRvOjwvYj4gSmFrb2IgSGVpdHogKGpo ZWl0eikgJmx0O2poZWl0ekBjaXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBTcmlyYW0sIEtv dGlrYWxhcHVkaSAoRmVkKSAmbHQ7a290aWthbGFwdWRpLnNyaXJhbUBuaXN0LmdvdiZndDs7IEpv YiBTbmlqZGVycyAmbHQ7am9iQG50dC5uZXQmZ3Q7OyBOaWNrIEhpbGxpYXJkICZsdDtuaWNrQGZv b2Jhci5vcmcmZ3Q7OyBKb2huIEhlYXNseSAmbHQ7aGVhc0BzaHJ1YmJlcnkubmV0Jmd0OzsgaWRy QGlldGYub3JnOyBncm93LWNoYWlyc0BpZXRmLm9yZzsgaWRyLWNoYWlyc0BpZXRmLm9yZzsgZ3Jv d0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0dST1ddIFF1ZXN0aW9uIGFib3V0 IEJHUCBMYXJnZSBDb21tdW5pdGllczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBIb3cgd291bGQgeW91IGRp dmlkZSB0aGUgbnVtYmVycz8mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5JIHdvdWxkIG5vdCBkaXZpZGUgdGhlbSBhdCBhbGwgaW4mbmJzcDtMQ3Mu IEkgd291bGQgZWl0aGVyIGRlZmluZSBuZXcgdHlwZSBpbiBleHRlbmRlZCBjb21tdW5pdGllcyBv ciB1c2Ugd2lkZSBjb21tdW5pdGllcy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPkJ1dCBJIGFtIGEgYml0IGJpYXNlZCBoZXJlIDstKTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+QmVzdCw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+Uiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPk9uIFR1ZSwgRmViIDQsIDIwMjAgYXQgMTE6MzQgUE0gSmFrb2IgSGVpdHogKGpo ZWl0eikgJmx0OzxhIGhyZWY9Im1haWx0bzpqaGVpdHpAY2lzY28uY29tIj5qaGVpdHpAY2lzY28u Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBudW1iZXJzIGFyZSBhIHRyYWRlIG9mZi4gSG93 IHdvdWxkIHlvdSBkaXZpZGUgdGhlIG51bWJlcnM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkpha29iLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIEZlYiA0LCAyMDIwLCBhdCAy OjE5IFBNLCBSb2JlcnQgUmFzenVrICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0QHJhc3p1ay5u ZXQiIHRhcmdldD0iX2JsYW5rIj5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+77u/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+QW5kIHlvdSB0aGluayAyNTUgc3VjaCBrbm93biBsYXJnZSBjb21tdW5p dGllcyB3aWxsIGJlIHN1ZmZpY2llbnQgPw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+VGh4LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5SLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+T24gVHVlLCBGZWIgNCwgMjAyMCBhdCA5 OjQ1IFBNIEpha29iIEhlaXR6IChqaGVpdHopICZsdDs8YSBocmVmPSJtYWlsdG86amhlaXR6QGNp c2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpoZWl0ekBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20g Ni4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMw QTAiPkEgc2V0IG9mIHdlbGwga25vd24gbGFyZ2UgY29tbXVuaXRpZXMgY291bGQgYmUgdXNlZnVs Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+SSBo YXZlIGEgZHJhZnQgdGhhdCBJIG5ldmVyIHN1Ym1pdHRlZCBhdHRhY2hlZCB0byB0aGlzIGVtYWls Ljwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+RG9l cyBhbnlvbmUgd2FudCB0byBjby1hdXRob3IgYW5kIHN1Z2dlc3QgY2hhbmdlcz88L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPlJlZ2Fy ZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj5K YWtvYi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 IzcwMzBBMCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj RTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIj4gU3JpcmFtLCBLb3Rpa2FsYXB1ZGkgKEZlZCkgJmx0OzxhIGhyZWY9Im1haWx0bzpr b3Rpa2FsYXB1ZGkuc3JpcmFtQG5pc3QuZ292IiB0YXJnZXQ9Il9ibGFuayI+a290aWthbGFwdWRp LnNyaXJhbUBuaXN0LmdvdjwvYT4mZ3Q7DQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRmVi cnVhcnkgNCwgMjAyMCAxMDoyMiBBTTxicj4NCjxiPlRvOjwvYj4gSmFrb2IgSGVpdHogKGpoZWl0 eikgJmx0OzxhIGhyZWY9Im1haWx0bzpqaGVpdHpAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+ amhlaXR6QGNpc2NvLmNvbTwvYT4mZ3Q7OyBKb2IgU25pamRlcnMgJmx0OzxhIGhyZWY9Im1haWx0 bzpqb2JAbnR0Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmpvYkBudHQubmV0PC9hPiZndDs7IE5pY2sg SGlsbGlhcmQgJmx0OzxhIGhyZWY9Im1haWx0bzpuaWNrQGZvb2Jhci5vcmciIHRhcmdldD0iX2Js YW5rIj5uaWNrQGZvb2Jhci5vcmc8L2E+Jmd0OzsNCiBKb2huIEhlYXNseSAmbHQ7PGEgaHJlZj0i bWFpbHRvOmhlYXNAc2hydWJiZXJ5Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmhlYXNAc2hydWJiZXJ5 Lm5ldDwvYT4mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86aWRyQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+aWRyQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmdyb3dA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmdyb3dAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJt YWlsdG86aWRyLWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmlkci1jaGFpcnNAaWV0 Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmdyb3ctY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+Z3Jvdy1jaGFpcnNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86YS5lLmF6 aW1vdkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj4NCmEuZS5hemltb3ZAZ21haWwuY29tPC9h PjsgQnJpYW4gRGlja3NvbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyaWFuLnBldGVyLmRpY2tzb25A Z21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+YnJpYW4ucGV0ZXIuZGlja3NvbkBnbWFpbC5jb208 L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBRdWVzdGlvbiBhYm91dCBCR1AgTGFyZ2UgQ29t bXVuaXRpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkluIHRoZSByb3V0ZSBsZWFrcyBzb2x1dGlvbiBk cmFmdCwgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPjxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWdyb3ctcm91dGUtbGVh ay1kZXRlY3Rpb24tbWl0aWdhdGlvbi0wMiIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWdyb3ctcm91dGUtbGVhay1kZXRlY3Rpb24tbWl0aWdh dGlvbi0wMjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+ d2UgKHRoZSBhdXRob3JzKSBoYXZlIHByb3Bvc2VkIHVzaW5nIEJHUCBMYXJnZSBDb21tdW5pdHku PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPldlIHNwZWNpZnkg dGhpcyB0byBiZSBhICZxdW90O3dlbGwta25vd24gdHJhbnNpdGl2ZSBMYXJnZSBDb21tdW5pdHkm cXVvdDsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5RdWVzdGlvbjog PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkNhbiB0aGUgZHJh ZnQgc2ltcGx5IG1ha2UgYW4gSUFOQSByZXF1ZXN0IGZvciA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+YSBHbG9iYWwgQWRtaW5pc3RyYXRvciBBU04gdmFsdWUg Zm9yIFJvdXRlIExlYWtzIFByb3RlY3Rpb24gKFJMUCkgdHlwZQ0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPmFuZCByZXF1ZXN0IHRoYXQgaXQgYmUgcHVibGlz aGVkIGluIElBTkEgcmVnaXN0cnkgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFu Zz0iRU4tVVMiPmFzIGEgJnF1b3Q7d2VsbC1rbm93biBUcmFuc2l0aXZlIExhcmdlIENvbW11bml0 eSZxdW90Oz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZXJlIGlz IG5vIElBTkEgcmVnaXN0cnkgZm9yIExhcmdlIENvbW11bml0aWVzIHlldDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+d2UgaGF2ZSByZXF1ZXN0ZWQgSURSIGFu ZCBHUk9XIENoYWlycyB0byBmYWNpbGl0YXRlIHRoYXQuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxz cGFuIGxhbmc9IkVOLVVTIj4tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiPkRldGFpbHMvYmFja2dyb3VuZDo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPldlJ3ZlIHJlYWQgdGhlIGZvbGxvd2luZyBSRkNzIHJl bGF0ZWQgdG8gTGFyZ2UgQ29tbXVuaXRpZXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tVVMiPjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4 MDkyIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1k ZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MDkyPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJl Zj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgxOTUiIHRhcmdldD0iX2JsYW5rIj48 c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgxOTU8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+UkZDIDgxOTUgaGFzIHRoaXMgdGFibGU6IDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSRkM4MDky Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IHwgUkZDIDgxOTUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0 MzstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PG86cD48L286cD48L3NwYW4+PC9wPg0K PHA+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyB8IEdsb2JhbCBBZG1pbmlzdHJhdG9yJm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgQVNOJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHwmbmJzcDsgTG9jYWwgRGF0YSBQYXJ0IDEmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyBGdW5j dGlvbiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNw YW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 Jm5ic3A7IExvY2FsIERhdGEgUGFydCAyJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsgUGFyYW1ldGVyJm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0mIzQzOzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj53aGljaCBpcyBpbnN0cnVjdGl2 ZS4gSW4gdGhlIGV4YW1wbGVzIHRoYXQgUkZDIDgxOTUgb2ZmZXJzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5pdCBhcHBlYXJzIGl0IGlzICphc3N1bWVkKiB0 aGF0IHRoZSBMYXJnZSBDb21tdW5pdGllcyBhcmUgdHJhbnNpdGl2ZS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkZvciBjb21wYXJpc29uLCBpbiBFeHRlbmRlZCBDb21t dW5pdGllcyAoUkZDIDcxNTMpLCB0aGVyZSBhcmUNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLVVTIj5leHBsaWNpdCBUeXBlIHZhbHVlcyBhc3NpZ25lZCBmb3IgVHJh bnNpdGl2ZSwgTm9uLXRyYW5zaXRpdmUsIGV0Yy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwczovL3d3 dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9iZ3AtZXh0ZW5kZWQtY29tbXVuaXRpZXMvYmdwLWV4dGVu ZGVkLWNvbW11bml0aWVzLnhodG1sIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWFuYS5v cmcvYXNzaWdubWVudHMvYmdwLWV4dGVuZGVkLWNvbW11bml0aWVzL2JncC1leHRlbmRlZC1jb21t dW5pdGllcy54aHRtbDwvYT48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5Ib3dldmVyLCB0aGVyZSBpcyBubyBzdWNo IGV4cGxpY2l0IFR5cGUgc3BlY2lmaWNhdGlvbiA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxw PjxzcGFuIGxhbmc9IkVOLVVTIj5mb3IgTGFyZ2UgQ29tbXVuaXRpZXMgKGluIFJGQyA4MDkyIG9y IGVsc2V3aGVyZSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFu ayB5b3UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPlNyaXJh bTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPGJyPg0KR1JPVyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWls dG86R1JPV0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkdST1dAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ncm93IiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ncm93PC9h PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_90fab3d5ec794e95be0d86cae2d4a235huaweicom_-- From nobody Tue Feb 4 18:03:08 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C76120152; Tue, 4 Feb 2020 18:03:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.497 X-Spam-Level: X-Spam-Status: No, score=-14.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_ENHANCEMENT=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-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=Ye+3Yd88; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=S6TAC4iX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rx-1qz3CK5SR; Tue, 4 Feb 2020 18:03:01 -0800 (PST) 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 EC62112006E; Tue, 4 Feb 2020 18:03:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19874; q=dns/txt; s=iport; t=1580868180; x=1582077780; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=iK5sWqF7haEwHSiDe0IEb38XLgYfvVPf5ZtMyeci02c=; b=Ye+3Yd88HyW4T5uucAmLYBvQac3kK6G+ePJK2aVu6SWISLYgAdht3hwb VZkM37iT+5RL/LIQD0i9JRjoX9+L0k6Kx42VgRcOzhRpb6WkPN+KEmemA WrJYLupcjdGIpOWZtJ7KSMDw5FoB3iLZEOf07GDEqQfn9h5AOdzejGRda 8=; IronPort-PHdr: =?us-ascii?q?9a23=3AK2mLGBFVQ9dV04Suo1f3h51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w3Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+efzqYi0mDuxJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C9AABFITpe/5JdJa1lGwEBAQEBAQE?= =?us-ascii?q?FAQEBEQEBAwMBAQGBagMBAQELAYEkL1AFbFggBAsqCoQLg0YDiwKCX4lhiUy?= =?us-ascii?q?EYoFCgRADVAkBAQEMAQEtAgEBhEACF4IgJDcGDgIDDQEBBAEBAQIBBQRthTc?= =?us-ascii?q?MhWYBAQEBAgESEQoTAQE3AQsEAgEIEQQBAQEnAwICAh8RFAkIAQEEDgUIGoM?= =?us-ascii?q?FgX1NAw4gAaFHAoE5iGJ1gTKCfwEBBYUxDQuCDAmBOAGMIRqBQT+BEAFHgkw?= =?us-ascii?q?+ghuBewESASMVDxCCWjKCLJBXhWGJeY5yRAqCO5IZhEWbCI5hiw+QCwIEAgQ?= =?us-ascii?q?FAg4BAQWBaCNncXAVgydQGA2OHQeDbIpTdAKBJ4pggSIBgQ8BAQ?= X-IronPort-AV: E=Sophos;i="5.70,404,1574121600"; d="scan'208,217";a="716793649" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Feb 2020 02:02:59 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 01522wFp030311 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 5 Feb 2020 02:02:59 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 4 Feb 2020 20:02:58 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 4 Feb 2020 20:02:57 -0600 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 4 Feb 2020 20:02:57 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mSDteqZkjX5uP3MFw3crDFjdlda1azhp1vIIAdtIoVgn1N1llqNheAQITl2hG9UgPTf+2xYZsHovPFCPJYpePlzU/DXXLuag/7y4z1KcYBUEnNmSYVKsP2kjVtBhtslFuCe96dhpX3JnRGx4c+O4iYrSiuBs6Xhyw9fCU2QdyiTNSyYiA9sJW9hrCDkYJNxQNda0hzC0fLfI3ZnwSRbiS4x7bBjgWmaQOsEKiKmn5pAhuAX9aSw07HIYg6sRcbNLUNHxaAwodN7dRrYXSx0mftR7+9/NmkHv3zx97bNx12oVxWfs0V39BI/+JgIkZGZGFVQA2BGUhGCvC/h9x6shrA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iK5sWqF7haEwHSiDe0IEb38XLgYfvVPf5ZtMyeci02c=; b=S5bYBjqaj63n5H0z5ypMQonqI5+blGSuspQwjr3crAeLC/R6Jb9BRxhhBn3J92gMkD7T+iOCb0koyTbQbGofbW+mVohmfw8NFu+zBsd2hNf1RO4wq/E7+pLUW5yOsL+HS3ZJJlcfa6alO1y137k/XQniI4YPYjp+tR63yn6ZOzlbI2MBAyu6O30C+MRNRfINLIndovihnvMIFZj+9JuI8ShTgfdUxL6Ax1KhNsMOr/ulRS9Exke7/m5H3YP9puqT4ant7lKOpNYpBeDI+B3U/zN3K41irG4h+18L2FpkX2lsOSJcmToDqW03AC/ewxtlVPr3yL/uugmhECWAcq3/fA== 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=iK5sWqF7haEwHSiDe0IEb38XLgYfvVPf5ZtMyeci02c=; b=S6TAC4iXSPjJxr1dLc2Ts7N8sTkYSlE5dbqwf1FALxcmgbufpS8u/iexU8M34e6C+xAGkDTtbj8miebiYoKhWiiz8T2MhEvOUftnRx5gSsVe7E0CUPDnf477NBGYtH8xcEOd1ixfvZT80BEZMgdoIhWdHr6VeOiI6y+laeOEo+c= Received: from MWHPR11MB1901.namprd11.prod.outlook.com (10.175.54.12) by MWHPR11MB1840.namprd11.prod.outlook.com (10.175.55.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2686.26; Wed, 5 Feb 2020 02:02:56 +0000 Received: from MWHPR11MB1901.namprd11.prod.outlook.com ([fe80::5109:65e6:5d:db41]) by MWHPR11MB1901.namprd11.prod.outlook.com ([fe80::5109:65e6:5d:db41%3]) with mapi id 15.20.2707.020; Wed, 5 Feb 2020 02:02:56 +0000 From: "Jakob Heitz (jheitz)" To: Brian Dickson , "Sriram, Kotikalapudi (Fed)" CC: John Heasly , "idr@ietf.org" , "grow@ietf.org" Thread-Topic: Question about BGP Large Communities Thread-Index: AdXbeNI4t0SppYFnSky8PqLGmuct1gAIu5NAAASXzAAAA08B8AACkBOAAACpoRA= Date: Wed, 5 Feb 2020 02:02:56 +0000 Message-ID: References: <20200204225458.GB57481@shrubbery.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jheitz@cisco.com; x-originating-ip: [128.107.241.189] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d2164cee-cd6e-40b7-212e-08d7a9df84e1 x-ms-traffictypediagnostic: MWHPR11MB1840: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0304E36CA3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(136003)(396003)(366004)(39860400002)(199004)(189003)(186003)(4326008)(7696005)(26005)(66446008)(66556008)(76116006)(64756008)(52536014)(66476007)(66946007)(5660300002)(86362001)(81166006)(8936002)(81156014)(8676002)(55016002)(53546011)(33656002)(478600001)(71200400001)(9686003)(110136005)(54906003)(316002)(6506007)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1840; H:MWHPR11MB1901.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xfCv94MR3W07CQDatGtPtKhsh4vQXRqjZLe/pxbgm83P87dWtto8PqZ9dB96GhEvgGLeu8A18ihtm0ha58kAPOXumJbl2dhmbd9/9tInac1pihApBXG/+jdgU3ouzC7Y8SrgpptCDw/FWnCN3QTE0LxRgu7Beo9pCHJbia71xgwRM4ZRlpeFlDwtRfPWQv/BpRobl5Bh1TIsSeRB0/Kih1/i/8653lmcyd/ZvgP4EwRW0zRhZzyoQ9yFYNLZ5Gsqu9WHxXkd4157Zc9zpMIhjbDQxt4RCl4CRkP6G8Dyl41/MAcxUrPXEdfUy7FP1EI83UDtzhqHGpLJqMfRzRKEOpFCmkVpNy5zi4YU4bo/quVrx39kOMrT2il0EnKVuAYtpwL5nu0mbHn5FxZKBqzqssSs0QNQrDXoIA6LHlhBFhbxdzRPV0i8f0oQ367t8P+M x-ms-exchange-antispam-messagedata: pjapuwFV7xpxfSdlHD1K9l7G8pTRITn/iQOi1r41X0C4ohTlV1/sDhW6vUhhKq6ODC1BFJO8AMP0gVf+Ll00RsIt0umVyOlTu4/t5h1ilqXGHXkLVgk4bKhMozREMEnJjREKlRCk8B9wQhEyMLkEVA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR11MB19018E354D89D83551027175C0020MWHPR11MB1901namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d2164cee-cd6e-40b7-212e-08d7a9df84e1 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Feb 2020 02:02:56.5923 (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: Tj7UgPvxxeCggzZ2rytATSC8PME2ckYBH77bikpXijrUJu0jIB2jRclqs9MVseH905zK7kb74Va655WGVVXCOw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1840 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [Idr] Question about BGP Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 02:03:04 -0000 --_000_MWHPR11MB19018E354D89D83551027175C0020MWHPR11MB1901namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UHJpdmF0ZSBBU05zIGFyZSA0LDIwMCwwMDAsMDAwIHVwd2FyZHMuDQpJIGFtIHJlcXVlc3Rpbmcg YSBibG9jayBqdXN0IGJlbG93IHRoYXQgPiA0LDAwMCwwMDAsMDAwLg0KDQpSZWdhcmRzLA0KSmFr b2IuDQoNCkZyb206IEJyaWFuIERpY2tzb24gPGJyaWFuLnBldGVyLmRpY2tzb25AZ21haWwuY29t Pg0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgNCwgMjAyMCA1OjQzIFBNDQpUbzogU3JpcmFtLCBL b3Rpa2FsYXB1ZGkgKEZlZCkgPGtvdGlrYWxhcHVkaS5zcmlyYW1AbmlzdC5nb3Y+DQpDYzogSm9o biBIZWFzbHkgPGhlYXNAc2hydWJiZXJ5Lm5ldD47IEpha29iIEhlaXR6IChqaGVpdHopIDxqaGVp dHpAY2lzY28uY29tPjsgaWRyQGlldGYub3JnOyBncm93QGlldGYub3JnDQpTdWJqZWN0OiBSZTog UXVlc3Rpb24gYWJvdXQgQkdQIExhcmdlIENvbW11bml0aWVzDQoNCg0KDQpPbiBUdWUsIEZlYiA0 LCAyMDIwIGF0IDU6MjggUE0gU3JpcmFtLCBLb3Rpa2FsYXB1ZGkgKEZlZCkgPGtvdGlrYWxhcHVk aS5zcmlyYW1AbmlzdC5nb3Y8bWFpbHRvOmtvdGlrYWxhcHVkaS5zcmlyYW1AbmlzdC5nb3Y+PiB3 cm90ZToNCj4gPiBEb2VzIGFueW9uZSB3YW50IHRvIGNvLWF1dGhvciBhbmQgc3VnZ2VzdCBjaGFu Z2VzPw0KSSB3b3VsZCBhbHNvIGJlIGdsYWQgdG8gcGFydGljaXBhdGUgaW4gdGhhdCBlZmZvcnQu DQoNCkkgaGF2ZSBsb29rZWQgYXQgdGhlIHByb3Bvc2FscyBpbiB0aGUgdHdvIGRyYWZ0cyAoSmFj b2IgYW5kIEpvaG4gSCkuDQpUaGVyZSBhcmUgYSBmZXcgb2JzZXJ2YXRpb25zIEkgd291bGQgbGlr ZSB0byBzaGFyZS4NCg0KQXMgQWx2YXJvIHBvaW50ZWQgb3V0LCBSRkMgODA5MiBzYXlzOg0KICAg VGhpcyBkb2N1bWVudCBkZWZpbmVzIHRoZSBCR1AgTGFyZ2UgQ29tbXVuaXRpZXMgYXR0cmlidXRl IGFzIGFuDQogICBvcHRpb25hbCB0cmFuc2l0aXZlIHBhdGggYXR0cmlidXRlIG9mIHZhcmlhYmxl IGxlbmd0aC4NCg0KVGhhdCBtZWFucyAqYWxsKiBCR1AgTGFyZ2UgQ29tbXVuaXRpZXMgYXJlIHRy YW5zaXRpdmUuIERvIHlvdSBhZ3JlZT8NClJGQyA4MTk1IHNlZW1zIHRvIGJlIHdyaXR0ZW4gaW4g dGhhdCBzcGlyaXQgYXMgd2VsbC4NCg0KVGhleSBhcmUsIGJ5IGRlZmF1bHQsIHRyYW5zaXRpdmUs IHVubGVzcyBsb2NhbCBwb2xpY3kgaXMgdG8gZWl0aGVyIHN0cmlwIHRoZW0gb3IgZmlsdGVyIHVw ZGF0ZXMgYmFzZWQgb24gdGhlIHZhbHVlcyAob3Igc29tZSBwb3J0aW9uIG91dCBvZiB0aGUgdmFs dWVzLCBsaWtlIGJpdHMgNi03KS4NCg0KDQpUaGUgZmlyc3QgMzIgYml0cyB0b2dldGhlciBhcmUg YSBHbG9iYWwgQWRtaW5pc3RyYXRvciAoR0EpIElELg0KU28sIGl0IHNlZW1zIGl0IHdvdWxkIG5v dCBiZSBwb3NzaWJsZSB0byB1c2UgYW55IHBhcnQgb2YgaXQgYXMgZGF0YS4NCk90aGVyd2lzZSwg Y29sbGlzaW9ucyAoYW1iaWd1aXR5KSBjb3VsZCBoYXBwZW4gd2hlbg0Kb3RoZXIgTENzIHVzZSA0 LW9jdGV0IEFTTnMgaW4gdGhlIEdsb2JhbCBBZG1pbmlzdHJhdG9yIGZpZWxkLiBBZ3JlZT8NCg0K T25seSByZWFsIEFTTnMgaGF2ZSBhbnkgcmVhc29uYWJsZSBleHBlY3RhdGlvbiBvZiBjb2xsaXNp b24gcHJvdGVjdGlvbiBhbmQgdW5pcXVlbmVzcywgaS5lLiBBU04gdmFsdWVzIDw0LDAwMCwwMDAs MDAwDQoNCkkgc2VlIEphY29iJ3MgZHJhZnQgcHJvcG9zZXMgdXNpbmcgc29tZSBwb3J0aW9uIG9m IHRoZSBmaXJzdCAzMiBiaXRzIGFzIGRhdGEuDQpUaGUgZHJhZnQgdGhhdCBKb2huIEhlYXNseSBz aGFyZWQgc2V0cyB0aGUgZmlyc3QgMzItYml0cyB0byBBU04gdmFsdWUgMA0KdG8gZGVzaWduYXRl IFdLLUxDOyAgc28gbm8gcGFydCBvZiB0aGUgZmlyc3QgMzItYml0cyBpcyBkYXRhLg0KDQpBbm90 aGVyIGlkZWEgdG8gY29uc2lkZXI6DQpXaHkgbm90IHJlcXVlc3QgSUFOQSB0byBhc3NpZ24gYSBy YW5nZSBvZiAyNTYgb3IgMTAyNCBvciBzb21lIG51bWJlciAoPykNCm9mIDQtYnl0ZSBBU04gdmFs dWVzIHRvIGJlIGFsbG9jYXRlZCBhbmQgdXNlZCBhcyBHQSBJRCBmb3IgdHJhbnNpdGl2ZSBXSy1M Q3M/DQpBIGZ1bmN0aW9uIChlLmcuLCByb3V0ZS1sZWFrIHByb3RlY3Rpb24pIHRoYXQgcmVxdWly ZXMgdHJhbnNpdGl2ZSBXSy1MQw0Kd2lsbCBiZSBhbGxvY2F0ZWQgb25lIHRoZXNlIEFTTiB2YWx1 ZXMuDQpUaGVuIHdlIGRvbid0IHdhc3RlIGFueSBwYXJ0IG9mIHRoZSBmaXJzdCAzMi1iaXRzIHRv IGRlc2lnbmF0ZSAidHlwZSIgb2YgTEMuDQoNCkpha29iJ3MgcHJvcG9zYWwgaXMgcXVpdGUgcmVh c29uYWJsZS4NClRoZSAzMi1iaXQgQVNOIFJGQyAoZG9uJ3QgcmVjYWxsIGl0IG9mZmhhbmQpIHJl c2VydmVzIGFsbCB2YWx1ZXMgPjQsMDAwLDAwMCwwMDAgYXMgcHJpdmF0ZSB2YWx1ZXMuDQpSZXNl cnZpbmcgb25seSB0aG9zZSB0aGF0IHN0YXJ0IChiaW5hcnkpIDExMTExMCBpcyBhIHZlcnkgc21h bGwgc2xpY2Ugb2ZmIHRoYXQgcmFuZ2UsIG5lYXIgdGhlIHRvcCBidXQgbm90IHRoZSB2ZXJ5IHRv cC4NCkhhdmluZyBhbiBleHRyYSAxNiBiaXRzIHRvIHBsYXkgd2l0aCwgZm9yIGV2ZXJ5IFdLQywg cGx1cyAyIGJpdHMgcGVyIHRoZSBUIGZpZWxkLCBpcyBwbGVudHkgYW5kIHZlcnkgdXNlZnVsLg0K T25seSBoYXZpbmcgdHdvIDMyLWJpdCB2YWx1ZXMgaXMgb3Zlcmx5IGxpbWl0aW5nLCBJTUhPLg0K DQpCcmlhbg0KDQoNClRoYXQgY2xlYW5seSBsZWF2ZXMgNjQgYml0cyBmb3IgbG9jYWwgZGF0YSAo YXMgUkZDIDgwOTIgc3BlY2lmaWVzKQ0Kd2hpY2ggY2FuIGFjY29tbW9kYXRlIHR3byA0LWJ5dGUg QVNOcyBpZiBuZWVkZWQuDQoNClNyaXJhbQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IEpvaG4gSGVhc2x5IDxoZWFzQHNocnViYmVyeS5uZXQ8bWFpbHRvOmhlYXNAc2hy dWJiZXJ5Lm5ldD4+DQo+IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDQsIDIwMjAgNTo1NSBQTQ0K PiBUbzogSmFrb2IgSGVpdHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb208bWFpbHRvOmpoZWl0 ekBjaXNjby5jb20+Pg0KPiBDYzogU3JpcmFtLCBLb3Rpa2FsYXB1ZGkgKEZlZCkgPGtvdGlrYWxh cHVkaS5zcmlyYW1AbmlzdC5nb3Y8bWFpbHRvOmtvdGlrYWxhcHVkaS5zcmlyYW1AbmlzdC5nb3Y+ PjsgSm9iIFNuaWpkZXJzDQo+IDxqb2JAbnR0Lm5ldDxtYWlsdG86am9iQG50dC5uZXQ+PjsgTmlj ayBIaWxsaWFyZCA8bmlja0Bmb29iYXIub3JnPG1haWx0bzpuaWNrQGZvb2Jhci5vcmc+PjsgSm9o biBIZWFzbHkNCj4gPGhlYXNAc2hydWJiZXJ5Lm5ldDxtYWlsdG86aGVhc0BzaHJ1YmJlcnkubmV0 Pj47IGlkckBpZXRmLm9yZzxtYWlsdG86aWRyQGlldGYub3JnPjsgZ3Jvd0BpZXRmLm9yZzxtYWls dG86Z3Jvd0BpZXRmLm9yZz47IGlkci1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmlkci1jaGFpcnNA aWV0Zi5vcmc+Ow0KPiBncm93LWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86Z3Jvdy1jaGFpcnNAaWV0 Zi5vcmc+OyBhLmUuYXppbW92QGdtYWlsLmNvbTxtYWlsdG86YS5lLmF6aW1vdkBnbWFpbC5jb20+ OyBCcmlhbiBEaWNrc29uDQo+IDxicmlhbi5wZXRlci5kaWNrc29uQGdtYWlsLmNvbTxtYWlsdG86 YnJpYW4ucGV0ZXIuZGlja3NvbkBnbWFpbC5jb20+Pg0KPiBTdWJqZWN0OiBSZTogUXVlc3Rpb24g YWJvdXQgQkdQIExhcmdlIENvbW11bml0aWVzDQo+DQo+IFR1ZSwgRmViIDA0LCAyMDIwIGF0IDA4 OjQ1OjQwUE0gKzAwMDAsIEpha29iIEhlaXR6IChqaGVpdHopOg0KPiA+IEEgc2V0IG9mIHdlbGwg a25vd24gbGFyZ2UgY29tbXVuaXRpZXMgY291bGQgYmUgdXNlZnVsLg0KPiA+IEkgaGF2ZSBhIGRy YWZ0IHRoYXQgSSBuZXZlciBzdWJtaXR0ZWQgYXR0YWNoZWQgdG8gdGhpcyBlbWFpbC4NCj4gPiBE b2VzIGFueW9uZSB3YW50IHRvIGNvLWF1dGhvciBhbmQgc3VnZ2VzdCBjaGFuZ2VzPw0KPg0KPiBI ZXkgSmFjb2IsDQo+IEknZCB3b3JrIG9uIHRoYXQgd2l0aCB5b3UuICBKb2IsIE1vcnJvdyBhbmQg SSBhbHNvIHN0YXJ0ZWQgYSBkcmFmdCBmb3INCj4gTGFyZ2UgV0tDcywgYnV0IHdlIGhhdmUgbm90 IHN1Ym1pdHRlZCBhbnl0aGluZyAtIG5vciBtYWRlIGFueSByZWNlbnQNCj4gcHJvZ3Jlc3MuDQo+ DQo+IElJUkMsIHRoZSBkaXJlY3Rpb24gd2Ugd2VyZSBpbnRlbmRpbmcgdG8gdXNlIDAgKHplcm8p IGFzIHRoZSBBU04sIHRoZW4NCj4gZGVmaW5lIGxvY2FsIGRhdGEgcGFydCAxIGFzIFdLQyBpdHNl bGYsIGFuZCBsb2NhbCBkYXRhIHBhcnQgMiB0byBiZSBhDQo+IHZhbHVlIGFzc29jaWF0ZWQuDQo+ DQo+IEkndmUgYXR0YWNoZWQgdGhhdCBJIGhhdmUgd3JpdHRlbiBzbyBmYXIuICBKb2IgYW5kIE1v cnJvdyBtYXkgb3IgbWF5IG5vdA0KPiBlbmRvcnNlIHRoaXMgYXBwcm9hY2ggYXQgdGhpcyBwb2lu dC4NCj4NCj4gLWhlYXMNCg== --_000_MWHPR11MB19018E354D89D83551027175C0020MWHPR11MB1901namp_ 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 bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6IzcwMzBBMDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPlByaXZhdGUgQVNOcyBh cmUgNCwyMDAsMDAwLDAwMCB1cHdhcmRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM3MDMwQTAiPkkgYW0gcmVxdWVzdGluZyBhIGJs b2NrIGp1c3QgYmVsb3cgdGhhdCAmZ3Q7IDQsMDAwLDAwMCwwMDAuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzcwMzBBMCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj5KYWtvYi48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNzAzMEEwIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4g QnJpYW4gRGlja3NvbiAmbHQ7YnJpYW4ucGV0ZXIuZGlja3NvbkBnbWFpbC5jb20mZ3Q7IDxicj4N CjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSA0LCAyMDIwIDU6NDMgUE08YnI+DQo8Yj5U bzo8L2I+IFNyaXJhbSwgS290aWthbGFwdWRpIChGZWQpICZsdDtrb3Rpa2FsYXB1ZGkuc3JpcmFt QG5pc3QuZ292Jmd0Ozxicj4NCjxiPkNjOjwvYj4gSm9obiBIZWFzbHkgJmx0O2hlYXNAc2hydWJi ZXJ5Lm5ldCZndDs7IEpha29iIEhlaXR6IChqaGVpdHopICZsdDtqaGVpdHpAY2lzY28uY29tJmd0 OzsgaWRyQGlldGYub3JnOyBncm93QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBR dWVzdGlvbiBhYm91dCBCR1AgTGFyZ2UgQ29tbXVuaXRpZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIFR1ZSwgRmViIDQsIDIwMjAgYXQgNToyOCBQTSBTcmlyYW0sIEtvdGlr YWxhcHVkaSAoRmVkKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmtvdGlrYWxhcHVkaS5zcmlyYW1Abmlz dC5nb3YiPmtvdGlrYWxhcHVkaS5zcmlyYW1AbmlzdC5nb3Y8L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsg Jmd0OyBEb2VzIGFueW9uZSB3YW50IHRvIGNvLWF1dGhvciBhbmQgc3VnZ2VzdCBjaGFuZ2VzPzxi cj4NCkkgd291bGQgYWxzbyBiZSBnbGFkIHRvIHBhcnRpY2lwYXRlIGluIHRoYXQgZWZmb3J0Ljxi cj4NCjxicj4NCkkgaGF2ZSBsb29rZWQgYXQgdGhlIHByb3Bvc2FscyBpbiB0aGUgdHdvIGRyYWZ0 cyAoSmFjb2IgYW5kIEpvaG4gSCkuJm5ic3A7IDxicj4NClRoZXJlIGFyZSBhIGZldyBvYnNlcnZh dGlvbnMgSSB3b3VsZCBsaWtlIHRvIHNoYXJlLjxicj4NCjxicj4NCkFzIEFsdmFybyBwb2ludGVk IG91dCwgUkZDIDgwOTIgc2F5czo8YnI+DQombmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBkZWZp bmVzIHRoZSBCR1AgTGFyZ2UgQ29tbXVuaXRpZXMgYXR0cmlidXRlIGFzIGFuPGJyPg0KJm5ic3A7 ICZuYnNwO29wdGlvbmFsIHRyYW5zaXRpdmUgcGF0aCBhdHRyaWJ1dGUgb2YgdmFyaWFibGUgbGVu Z3RoLjxicj4NCjxicj4NClRoYXQgbWVhbnMgKmFsbCogQkdQIExhcmdlIENvbW11bml0aWVzIGFy ZSB0cmFuc2l0aXZlLiBEbyB5b3UgYWdyZWU/PGJyPg0KUkZDIDgxOTUgc2VlbXMgdG8gYmUgd3Jp dHRlbiBpbiB0aGF0IHNwaXJpdCBhcyB3ZWxsLiA8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXkgYXJlLCBieSBkZWZhdWx0LCB0 cmFuc2l0aXZlLCB1bmxlc3MgbG9jYWwgcG9saWN5IGlzIHRvIGVpdGhlciBzdHJpcCB0aGVtIG9y IGZpbHRlciB1cGRhdGVzIGJhc2VkIG9uIHRoZSB2YWx1ZXMgKG9yIHNvbWUgcG9ydGlvbiBvdXQg b2YgdGhlIHZhbHVlcywgbGlrZSBiaXRzIDYtNykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRoZSBmaXJzdCAzMiBiaXRz IHRvZ2V0aGVyIGFyZSBhIEdsb2JhbCBBZG1pbmlzdHJhdG9yIChHQSkgSUQuPGJyPg0KU28sIGl0 IHNlZW1zIGl0IHdvdWxkIG5vdCBiZSBwb3NzaWJsZSB0byB1c2UgYW55IHBhcnQgb2YgaXQgYXMg ZGF0YS48YnI+DQpPdGhlcndpc2UsIGNvbGxpc2lvbnMgKGFtYmlndWl0eSkgY291bGQgaGFwcGVu IHdoZW4gPGJyPg0Kb3RoZXIgTENzIHVzZSA0LW9jdGV0IEFTTnMgaW4gdGhlIEdsb2JhbCBBZG1p bmlzdHJhdG9yIGZpZWxkLiBBZ3JlZT88bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9ubHkgcmVhbCBBU05zIGhhdmUgYW55IHJlYXNv bmFibGUgZXhwZWN0YXRpb24gb2YgY29sbGlzaW9uIHByb3RlY3Rpb24gYW5kIHVuaXF1ZW5lc3Ms IGkuZS4gQVNOIHZhbHVlcyAmbHQ7NCwwMDAsMDAwLDAwMDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHNlZSBKYWNvYidzIGRyYWZ0 IHByb3Bvc2VzIHVzaW5nIHNvbWUgcG9ydGlvbiBvZiB0aGUgZmlyc3QgMzIgYml0cyBhcyBkYXRh Ljxicj4NClRoZSBkcmFmdCB0aGF0IEpvaG4gSGVhc2x5IHNoYXJlZCBzZXRzIHRoZSBmaXJzdCAz Mi1iaXRzIHRvIEFTTiB2YWx1ZSAwPGJyPg0KdG8gZGVzaWduYXRlIFdLLUxDOyZuYnNwOyBzbyBu byBwYXJ0IG9mIHRoZSBmaXJzdCAzMi1iaXRzIGlzIGRhdGEuPGJyPg0KPGJyPg0KQW5vdGhlciBp ZGVhIHRvIGNvbnNpZGVyOiA8YnI+DQpXaHkgbm90IHJlcXVlc3QgSUFOQSB0byBhc3NpZ24gYSBy YW5nZSBvZiAyNTYgb3IgMTAyNCBvciBzb21lIG51bWJlciAoPykgPGJyPg0Kb2YgNC1ieXRlIEFT TiB2YWx1ZXMgdG8gYmUgYWxsb2NhdGVkIGFuZCB1c2VkIGFzIEdBIElEIGZvciB0cmFuc2l0aXZl IFdLLUxDcz88YnI+DQpBIGZ1bmN0aW9uIChlLmcuLCByb3V0ZS1sZWFrIHByb3RlY3Rpb24pIHRo YXQgcmVxdWlyZXMgdHJhbnNpdGl2ZSBXSy1MQyA8YnI+DQp3aWxsIGJlIGFsbG9jYXRlZCBvbmUg dGhlc2UgQVNOIHZhbHVlcy48YnI+DQpUaGVuIHdlIGRvbid0IHdhc3RlIGFueSBwYXJ0IG9mIHRo ZSBmaXJzdCAzMi1iaXRzIHRvIGRlc2lnbmF0ZSAmcXVvdDt0eXBlJnF1b3Q7IG9mIExDLjxvOnA+ PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SmFrb2IncyBwcm9wb3NhbCBpcyBxdWl0ZSByZWFzb25hYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIDMyLWJpdCBBU04gUkZDIChkb24n dCByZWNhbGwgaXQgb2ZmaGFuZCkgcmVzZXJ2ZXMgYWxsIHZhbHVlcyAmZ3Q7NCwwMDAsMDAwLDAw MCBhcyBwcml2YXRlIHZhbHVlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlJlc2VydmluZyBvbmx5IHRob3NlIHRoYXQgc3RhcnQgKGJpbmFyeSkg MTExMTEwIGlzIGEgdmVyeSBzbWFsbCBzbGljZSBvZmYgdGhhdCByYW5nZSwgbmVhciB0aGUgdG9w IGJ1dCBub3QgdGhlIHZlcnkgdG9wLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SGF2aW5nIGFuIGV4dHJhIDE2IGJpdHMgdG8gcGxheSB3aXRoLCBm b3IgZXZlcnkgV0tDLCBwbHVzIDIgYml0cyBwZXIgdGhlIFQgZmllbGQsIGlzIHBsZW50eSBhbmQg dmVyeSB1c2VmdWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5Pbmx5IGhhdmluZyB0d28gMzItYml0IHZhbHVlcyBpcyBvdmVybHkgbGltaXRpbmcs IElNSE8uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkJyaWFuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhdCBjbGVhbmx5IGxlYXZlcyA2NCBiaXRzIGZvciBsb2NhbCBkYXRh IChhcyBSRkMgODA5MiBzcGVjaWZpZXMpPGJyPg0Kd2hpY2ggY2FuIGFjY29tbW9kYXRlIHR3byA0 LWJ5dGUgQVNOcyBpZiBuZWVkZWQuPGJyPg0KPGJyPg0KU3JpcmFtPGJyPg0KPGJyPg0KJmd0OyAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogSm9obiBIZWFzbHkgJmx0 OzxhIGhyZWY9Im1haWx0bzpoZWFzQHNocnViYmVyeS5uZXQiIHRhcmdldD0iX2JsYW5rIj5oZWFz QHNocnViYmVyeS5uZXQ8L2E+Jmd0Ozxicj4NCiZndDsgU2VudDogVHVlc2RheSwgRmVicnVhcnkg NCwgMjAyMCA1OjU1IFBNPGJyPg0KJmd0OyBUbzogSmFrb2IgSGVpdHogKGpoZWl0eikgJmx0Ozxh IGhyZWY9Im1haWx0bzpqaGVpdHpAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+amhlaXR6QGNp c2NvLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyBDYzogU3JpcmFtLCBLb3Rpa2FsYXB1ZGkgKEZlZCkg Jmx0OzxhIGhyZWY9Im1haWx0bzprb3Rpa2FsYXB1ZGkuc3JpcmFtQG5pc3QuZ292IiB0YXJnZXQ9 Il9ibGFuayI+a290aWthbGFwdWRpLnNyaXJhbUBuaXN0LmdvdjwvYT4mZ3Q7OyBKb2IgU25pamRl cnM8YnI+DQomZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86am9iQG50dC5uZXQiIHRhcmdldD0iX2Js YW5rIj5qb2JAbnR0Lm5ldDwvYT4mZ3Q7OyBOaWNrIEhpbGxpYXJkICZsdDs8YSBocmVmPSJtYWls dG86bmlja0Bmb29iYXIub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmlja0Bmb29iYXIub3JnPC9hPiZn dDs7IEpvaG4gSGVhc2x5PGJyPg0KJmd0OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhlYXNAc2hydWJi ZXJ5Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmhlYXNAc2hydWJiZXJ5Lm5ldDwvYT4mZ3Q7OyA8YSBo cmVmPSJtYWlsdG86aWRyQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQppZHJAaWV0Zi5vcmc8 L2E+OyA8YSBocmVmPSJtYWlsdG86Z3Jvd0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmdyb3dA aWV0Zi5vcmc8L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmlkci1jaGFpcnNAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5pZHItY2hhaXJzQGlldGYub3JnPC9hPjs8YnI+DQomZ3Q7IDxhIGhyZWY9Im1h aWx0bzpncm93LWNoYWlyc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmdyb3ctY2hhaXJzQGll dGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzphLmUuYXppbW92QGdtYWlsLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmEuZS5hemltb3ZAZ21haWwuY29tPC9hPjsgQnJpYW4gRGlja3Nvbjxicj4NCiZn dDsgJmx0OzxhIGhyZWY9Im1haWx0bzpicmlhbi5wZXRlci5kaWNrc29uQGdtYWlsLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmJyaWFuLnBldGVyLmRpY2tzb25AZ21haWwuY29tPC9hPiZndDs8YnI+DQom Z3Q7IFN1YmplY3Q6IFJlOiBRdWVzdGlvbiBhYm91dCBCR1AgTGFyZ2UgQ29tbXVuaXRpZXM8YnI+ DQomZ3Q7IDxicj4NCiZndDsgVHVlLCBGZWIgMDQsIDIwMjAgYXQgMDg6NDU6NDBQTSAmIzQzOzAw MDAsIEpha29iIEhlaXR6IChqaGVpdHopOjxicj4NCiZndDsgJmd0OyBBIHNldCBvZiB3ZWxsIGtu b3duIGxhcmdlIGNvbW11bml0aWVzIGNvdWxkIGJlIHVzZWZ1bC48YnI+DQomZ3Q7ICZndDsgSSBo YXZlIGEgZHJhZnQgdGhhdCBJIG5ldmVyIHN1Ym1pdHRlZCBhdHRhY2hlZCB0byB0aGlzIGVtYWls Ljxicj4NCiZndDsgJmd0OyBEb2VzIGFueW9uZSB3YW50IHRvIGNvLWF1dGhvciBhbmQgc3VnZ2Vz dCBjaGFuZ2VzPzxicj4NCiZndDsgPGJyPg0KJmd0OyBIZXkgSmFjb2IsPGJyPg0KJmd0OyBJJ2Qg d29yayBvbiB0aGF0IHdpdGggeW91LiZuYnNwOyBKb2IsIE1vcnJvdyBhbmQgSSBhbHNvIHN0YXJ0 ZWQgYSBkcmFmdCBmb3I8YnI+DQomZ3Q7IExhcmdlIFdLQ3MsIGJ1dCB3ZSBoYXZlIG5vdCBzdWJt aXR0ZWQgYW55dGhpbmcgLSBub3IgbWFkZSBhbnkgcmVjZW50PGJyPg0KJmd0OyBwcm9ncmVzcy48 YnI+DQomZ3Q7IDxicj4NCiZndDsgSUlSQywgdGhlIGRpcmVjdGlvbiB3ZSB3ZXJlIGludGVuZGlu ZyB0byB1c2UgMCAoemVybykgYXMgdGhlIEFTTiwgdGhlbjxicj4NCiZndDsgZGVmaW5lIGxvY2Fs IGRhdGEgcGFydCAxIGFzIFdLQyBpdHNlbGYsIGFuZCBsb2NhbCBkYXRhIHBhcnQgMiB0byBiZSBh PGJyPg0KJmd0OyB2YWx1ZSBhc3NvY2lhdGVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJJ3ZlIGF0 dGFjaGVkIHRoYXQgSSBoYXZlIHdyaXR0ZW4gc28gZmFyLiZuYnNwOyBKb2IgYW5kIE1vcnJvdyBt YXkgb3IgbWF5IG5vdDxicj4NCiZndDsgZW5kb3JzZSB0aGlzIGFwcHJvYWNoIGF0IHRoaXMgcG9p bnQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC1oZWFzPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MWHPR11MB19018E354D89D83551027175C0020MWHPR11MB1901namp_-- From nobody Wed Feb 5 01:01:06 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB217120288; Wed, 5 Feb 2020 01:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_ENHANCEMENT=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 idh3fqBL1CHG; Wed, 5 Feb 2020 01:00:58 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 2C20F12026E; Wed, 5 Feb 2020 01:00:58 -0800 (PST) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id CD9F3675DE6966935DD4; Wed, 5 Feb 2020 09:00:55 +0000 (GMT) Received: from NKGEML413-HUB.china.huawei.com (10.98.56.74) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 5 Feb 2020 09:00:54 +0000 Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by NKGEML413-HUB.china.huawei.com ([10.98.56.74]) with mapi id 14.03.0439.000; Wed, 5 Feb 2020 17:00:36 +0800 From: Zhuangshunwan To: Brian Dickson , "Dongjie (Jimmy)" CC: "idr@ietf.org" , "grow-chairs@ietf.org" , "idr-chairs@ietf.org" , "grow@ietf.org" Thread-Topic: [GROW] Question about BGP Large Communities Thread-Index: AdXbeNI4t0SppYFnSky8PqLGmuct1gAIu5NA//+UeoCAAAOcAIAAAbeA//9KBuCAAOpGgP//BMRg Date: Wed, 5 Feb 2020 09:00:35 +0000 Message-ID: <19AB2A007F56DB4E8257F949A2FB9858E5FFFD27@NKGEML515-MBX.china.huawei.com> References: <5603F4C9-7ECD-4A9C-AF81-49AE292CEE83@cisco.com> <90fab3d5ec794e95be0d86cae2d4a235@huawei.com> 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.202.109] Content-Type: multipart/alternative; boundary="_000_19AB2A007F56DB4E8257F949A2FB9858E5FFFD27NKGEML515MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] [GROW] Question about BGP Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 09:01:02 -0000 --_000_19AB2A007F56DB4E8257F949A2FB9858E5FFFD27NKGEML515MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkluIG15IG9waW5pb24sIHdoZW4gd2UgYXBwbHkgYSBuZXcgZnVuY3Rpb24gZnJvbSBJ QU5BLCB3ZSB3aWxsIGhhdmUgdG8gZGVwbG95IHNvbWUgZXh0cmEgcm91dGUgcG9saWNpZXMgdG8g c2V0IGFuZCBwYXJzZSB0aGUgc3BlY2lmaWMgZnVuY3Rpb24gYXMgeW91ciBzdWdnZXN0ZWQgd2F5 Lg0KV2l0aCB0aGUgaW5jcmVhc2Ugb2YgbmV3IGZ1bmN0aW9ucywgdGhlIHJvdXRlIHBvbGljaWVz IGRlcGxveWVkIHdpbGwgYmVjb21lIG1vcmUgYW5kIG1vcmUgY29tcGxpY2F0ZWQuDQoNCkJlc3Qg cmVnYXJkcywNClNodW53YW4NCg0KRnJvbTogR1JPVyBbbWFpbHRvOmdyb3ctYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEJyaWFuIERpY2tzb24NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVh cnkgNSwgMjAyMCA5OjQ1IEFNDQpUbzogRG9uZ2ppZSAoSmltbXkpIDxqaWUuZG9uZ0BodWF3ZWku Y29tPg0KQ2M6IGlkckBpZXRmLm9yZzsgZ3Jvdy1jaGFpcnNAaWV0Zi5vcmc7IGlkci1jaGFpcnNA aWV0Zi5vcmc7IGdyb3dAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbR1JPV10gUXVlc3Rpb24gYWJv dXQgQkdQIExhcmdlIENvbW11bml0aWVzDQoNCkRpc2FncmVlLCB3ZSB3YW50IHNvbWV0aGluZyBk ZXBsb3llZCAobGFyZ2UpIGFuZCBkZXBsb3lhYmxlIChyZXF1aXJpbmcgb25seSBJQU5BIGFjdGlv biwgbm8gdmVuZG9yIGFjdGl2aXR5KSBpbW1lZGlhdGVseS4NCklNSE8sIGFueSBzcGVjaWFsIGhh bmRsaW5nIG9yIG5ldyBjb2RlIHBvaW50cyBvciB1cGdyYWRlcyBhcmUgbm9uLXN0YXJ0ZXJzLg0K VGhpcyBwYXJ0aWN1bGFybHkgYXBwbGllcyB0byB3aWRlIGFuZCBleHRlbmRlZA0KQnJpYW4NCg0K T24gVHVlLCBGZWIgNCwgMjAyMCBhdCA1OjQxIFBNIERvbmdqaWUgKEppbW15KSA8amllLmRvbmdA aHVhd2VpLmNvbTxtYWlsdG86amllLmRvbmdAaHVhd2VpLmNvbT4+IHdyb3RlOg0KQWdyZWUgdGhh dCBmb3IgdGhpcyBjYXNlIGl0IG1heSBiZSBtb3JlIGNvbnZlbmllbnQgdG8ganVzdCB1c2UgZXh0 ZW5kZWQgY29tbXVuaXR5IHdpdGggYSBuZXcgdHlwZSwgdGhpcyBjb3VsZCBhdm9pZCBhbnkgcG9z c2libGUgY29sbGlzaW9uIHdpdGggZXhpc3RpbmcgZGVwbG95bWVudHMsIGFuZCBzYXZlIHRoZSBl ZmZvcnQgb2YgYXNzaWduaW5nIGEgc2V0IG9mIEFTTnMuIFdpZGUgY29tbXVuaXR5IG1heSBiZSB0 b28gcG93ZXJmdWwgZm9yIHRoaXM6KQ0KDQpCZXN0IHJlZ2FyZHMsDQpKaWUNCg0KRnJvbTogUm9i ZXJ0IFJhc3p1ayBbbWFpbHRvOnJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVr Lm5ldD5dDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDUsIDIwMjAgNjozOCBBTQ0KVG86IEph a29iIEhlaXR6IChqaGVpdHopIDxqaGVpdHpAY2lzY28uY29tPG1haWx0bzpqaGVpdHpAY2lzY28u Y29tPj4NCkNjOiBTcmlyYW0sIEtvdGlrYWxhcHVkaSAoRmVkKSA8a290aWthbGFwdWRpLnNyaXJh bUBuaXN0LmdvdjxtYWlsdG86a290aWthbGFwdWRpLnNyaXJhbUBuaXN0Lmdvdj4+OyBKb2IgU25p amRlcnMgPGpvYkBudHQubmV0PG1haWx0bzpqb2JAbnR0Lm5ldD4+OyBOaWNrIEhpbGxpYXJkIDxu aWNrQGZvb2Jhci5vcmc8bWFpbHRvOm5pY2tAZm9vYmFyLm9yZz4+OyBKb2huIEhlYXNseSA8aGVh c0BzaHJ1YmJlcnkubmV0PG1haWx0bzpoZWFzQHNocnViYmVyeS5uZXQ+PjsgaWRyQGlldGYub3Jn PG1haWx0bzppZHJAaWV0Zi5vcmc+OyBncm93LWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86Z3Jvdy1j aGFpcnNAaWV0Zi5vcmc+OyBpZHItY2hhaXJzQGlldGYub3JnPG1haWx0bzppZHItY2hhaXJzQGll dGYub3JnPjsgZ3Jvd0BpZXRmLm9yZzxtYWlsdG86Z3Jvd0BpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbR1JPV10gUXVlc3Rpb24gYWJvdXQgQkdQIExhcmdlIENvbW11bml0aWVzDQoNCg0KPiBIb3cg d291bGQgeW91IGRpdmlkZSB0aGUgbnVtYmVycz8NCg0KSSB3b3VsZCBub3QgZGl2aWRlIHRoZW0g YXQgYWxsIGluIExDcy4gSSB3b3VsZCBlaXRoZXIgZGVmaW5lIG5ldyB0eXBlIGluIGV4dGVuZGVk IGNvbW11bml0aWVzIG9yIHVzZSB3aWRlIGNvbW11bml0aWVzLg0KDQpCdXQgSSBhbSBhIGJpdCBi aWFzZWQgaGVyZSA7LSkNCg0KQmVzdCwNClIsDQoNCk9uIFR1ZSwgRmViIDQsIDIwMjAgYXQgMTE6 MzQgUE0gSmFrb2IgSGVpdHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb208bWFpbHRvOmpoZWl0 ekBjaXNjby5jb20+PiB3cm90ZToNClRoZSBudW1iZXJzIGFyZSBhIHRyYWRlIG9mZi4gSG93IHdv dWxkIHlvdSBkaXZpZGUgdGhlIG51bWJlcnM/DQpUaGFua3MsDQpKYWtvYi4NCg0KT24gRmViIDQs IDIwMjAsIGF0IDI6MTkgUE0sIFJvYmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PG1haWx0 bzpyb2JlcnRAcmFzenVrLi5uZXQ+PiB3cm90ZToNCu+7vw0KQW5kIHlvdSB0aGluayAyNTUgc3Vj aCBrbm93biBsYXJnZSBjb21tdW5pdGllcyB3aWxsIGJlIHN1ZmZpY2llbnQgPw0KDQpUaHgsDQpS Lg0KDQpPbiBUdWUsIEZlYiA0LCAyMDIwIGF0IDk6NDUgUE0gSmFrb2IgSGVpdHogKGpoZWl0eikg PGpoZWl0ekBjaXNjby5jb208bWFpbHRvOmpoZWl0ekBjaXNjby5jb20+PiB3cm90ZToNCkEgc2V0 IG9mIHdlbGwga25vd24gbGFyZ2UgY29tbXVuaXRpZXMgY291bGQgYmUgdXNlZnVsLg0KSSBoYXZl IGEgZHJhZnQgdGhhdCBJIG5ldmVyIHN1Ym1pdHRlZCBhdHRhY2hlZCB0byB0aGlzIGVtYWlsLg0K RG9lcyBhbnlvbmUgd2FudCB0byBjby1hdXRob3IgYW5kIHN1Z2dlc3QgY2hhbmdlcz8NCg0KUmVn YXJkcywNCkpha29iLg0KDQpGcm9tOiBTcmlyYW0sIEtvdGlrYWxhcHVkaSAoRmVkKSA8a290aWth bGFwdWRpLnNyaXJhbUBuaXN0LmdvdjxtYWlsdG86a290aWthbGFwdWRpLnNyaXJhbUBuaXN0Lmdv dj4+DQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSA0LCAyMDIwIDEwOjIyIEFNDQpUbzogSmFrb2Ig SGVpdHogKGpoZWl0eikgPGpoZWl0ekBjaXNjby5jb208bWFpbHRvOmpoZWl0ekBjaXNjby5jb20+ PjsgSm9iIFNuaWpkZXJzIDxqb2JAbnR0Lm5ldDxtYWlsdG86am9iQG50dC5uZXQ+PjsgTmljayBI aWxsaWFyZCA8bmlja0Bmb29iYXIub3JnPG1haWx0bzpuaWNrQGZvb2Jhci5vcmc+PjsgSm9obiBI ZWFzbHkgPGhlYXNAc2hydWJiZXJ5Lm5ldDxtYWlsdG86aGVhc0BzaHJ1YmJlcnkubmV0Pj4NCkNj OiBpZHJAaWV0Zi5vcmc8bWFpbHRvOmlkckBpZXRmLm9yZz47IGdyb3dAaWV0Zi5vcmc8bWFpbHRv Omdyb3dAaWV0Zi5vcmc+OyBpZHItY2hhaXJzQGlldGYub3JnPG1haWx0bzppZHItY2hhaXJzQGll dGYub3JnPjsgZ3Jvdy1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOmdyb3ctY2hhaXJzQGlldGYub3Jn PjsgYS5lLmF6aW1vdkBnbWFpbC5jb208bWFpbHRvOmEuZS5hemltb3ZAZ21haWwuY29tPjsgQnJp YW4gRGlja3NvbiA8YnJpYW4ucGV0ZXIuZGlja3NvbkBnbWFpbC5jb208bWFpbHRvOmJyaWFuLnBl dGVyLmRpY2tzb25AZ21haWwuY29tPj4NClN1YmplY3Q6IFF1ZXN0aW9uIGFib3V0IEJHUCBMYXJn ZSBDb21tdW5pdGllcw0KDQoNCkluIHRoZSByb3V0ZSBsZWFrcyBzb2x1dGlvbiBkcmFmdCwNCg0K aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZ3Jvdy1yb3V0ZS1sZWFrLWRl dGVjdGlvbi1taXRpZ2F0aW9uLTAyDQoNCndlICh0aGUgYXV0aG9ycykgaGF2ZSBwcm9wb3NlZCB1 c2luZyBCR1AgTGFyZ2UgQ29tbXVuaXR5Lg0KDQpXZSBzcGVjaWZ5IHRoaXMgdG8gYmUgYSAid2Vs bC1rbm93biB0cmFuc2l0aXZlIExhcmdlIENvbW11bml0eSIuDQoNCg0KDQpRdWVzdGlvbjoNCg0K Q2FuIHRoZSBkcmFmdCBzaW1wbHkgbWFrZSBhbiBJQU5BIHJlcXVlc3QgZm9yDQoNCmEgR2xvYmFs IEFkbWluaXN0cmF0b3IgQVNOIHZhbHVlIGZvciBSb3V0ZSBMZWFrcyBQcm90ZWN0aW9uIChSTFAp IHR5cGUNCg0KYW5kIHJlcXVlc3QgdGhhdCBpdCBiZSBwdWJsaXNoZWQgaW4gSUFOQSByZWdpc3Ry eQ0KDQphcyBhICJ3ZWxsLWtub3duIFRyYW5zaXRpdmUgTGFyZ2UgQ29tbXVuaXR5Ij8NCg0KDQoN ClRoZXJlIGlzIG5vIElBTkEgcmVnaXN0cnkgZm9yIExhcmdlIENvbW11bml0aWVzIHlldDsNCg0K d2UgaGF2ZSByZXF1ZXN0ZWQgSURSIGFuZCBHUk9XIENoYWlycyB0byBmYWNpbGl0YXRlIHRoYXQu DQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tDQoNCkRldGFpbHMvYmFja2dyb3VuZDoNCg0KDQoNCldl J3ZlIHJlYWQgdGhlIGZvbGxvd2luZyBSRkNzIHJlbGF0ZWQgdG8gTGFyZ2UgQ29tbXVuaXRpZXM6 DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MDkyDQoNCmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9yZmM4MTk1DQoNCg0KDQpSRkMgODE5NSBoYXMgdGhpcyB0YWJsZToNCg0K ICAgICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKw0KDQogICAgICAgICAgICAgICAgIHwgICAgICAgUkZDODA5MiAg ICAgICAgICAgICAgICAgICAgfCBSRkMgODE5NSAgICAgICAgICAgICAgICB8DQoNCiAgICAgICAg ICAgICAgICAgKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0rDQoNCiAgICAgICAgICAgICAgICAgfCBHbG9iYWwgQWRtaW5pc3RyYXRvciAg ICB8ICAgICAgQVNOICAgICAgICAgICAgICAgICAgICAgfA0KDQogICAgICAgICAgICAgICAgIHwg IExvY2FsIERhdGEgUGFydCAxICAgICAgICAgICB8ICAgIEZ1bmN0aW9uICAgICAgICAgICAgICB8 DQoNCiAgICAgICAgICAgICAgICAgfCAgTG9jYWwgRGF0YSBQYXJ0IDIgICAgICAgICAgIHwgICBQ YXJhbWV0ZXIgICAgICAgICAgICB8DQoNCiAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQoNCndoaWNoIGlz IGluc3RydWN0aXZlLiBJbiB0aGUgZXhhbXBsZXMgdGhhdCBSRkMgODE5NSBvZmZlcnMsDQoNCml0 IGFwcGVhcnMgaXQgaXMgKmFzc3VtZWQqIHRoYXQgdGhlIExhcmdlIENvbW11bml0aWVzIGFyZSB0 cmFuc2l0aXZlLg0KDQoNCg0KRm9yIGNvbXBhcmlzb24sIGluIEV4dGVuZGVkIENvbW11bml0aWVz IChSRkMgNzE1MyksIHRoZXJlIGFyZQ0KDQpleHBsaWNpdCBUeXBlIHZhbHVlcyBhc3NpZ25lZCBm b3IgVHJhbnNpdGl2ZSwgTm9uLXRyYW5zaXRpdmUsIGV0Yy4NCg0KaHR0cHM6Ly93d3cuaWFuYS5v cmcvYXNzaWdubWVudHMvYmdwLWV4dGVuZGVkLWNvbW11bml0aWVzL2JncC1leHRlbmRlZC1jb21t dW5pdGllcy54aHRtbA0KDQpIb3dldmVyLCB0aGVyZSBpcyBubyBzdWNoIGV4cGxpY2l0IFR5cGUg c3BlY2lmaWNhdGlvbg0KDQpmb3IgTGFyZ2UgQ29tbXVuaXRpZXMgKGluIFJGQyA4MDkyIG9yIGVs c2V3aGVyZSkuDQoNCg0KDQpUaGFuayB5b3UuDQoNClNyaXJhbQ0KDQoNCg0KDQoNCg0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkdST1cgbWFpbGluZyBs aXN0DQpHUk9XQGlldGYub3JnPG1haWx0bzpHUk9XQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9ncm93DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KR1JPVyBtYWlsaW5nIGxpc3QNCkdST1dAaWV0Zi5vcmc8bWFp bHRvOkdST1dAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2dyb3cNCg== --_000_19AB2A007F56DB4E8257F949A2FB9858E5FFFD27NKGEML515MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OuWui+S9kzt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OuWui+S9kzt9DQpz cGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+ DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5 b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9v OnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgt Q04iIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkluIG15IG9waW5pb24sIHdoZW4gd2UgYXBwbHkg YSBuZXcgZnVuY3Rpb24gZnJvbSBJQU5BLCB3ZSB3aWxsIGhhdmUgdG8gZGVwbG95IHNvbWUgZXh0 cmEgcm91dGUgcG9saWNpZXMgdG8gc2V0IGFuZCBwYXJzZSB0aGUgc3BlY2lmaWMgZnVuY3Rpb24g YXMNCiB5b3VyIHN1Z2dlc3RlZCB3YXkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5X aXRoIHRoZSBpbmNyZWFzZSBvZiBuZXcgZnVuY3Rpb25zLCB0aGUgcm91dGUgcG9saWNpZXMgZGVw bG95ZWQgd2lsbCBiZWNvbWUgbW9yZSBhbmQgbW9yZSBjb21wbGljYXRlZC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+U2h1bndhbjwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBHUk9XIFttYWlsdG86Z3Jvdy1i b3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CcmlhbiBEaWNrc29uPGJyPg0K PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVicnVhcnkgNSwgMjAyMCA5OjQ1IEFNPGJyPg0KPGI+ VG86PC9iPiBEb25namllIChKaW1teSkgJmx0O2ppZS5kb25nQGh1YXdlaS5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBpZHJAaWV0Zi5vcmc7IGdyb3ctY2hhaXJzQGlldGYub3JnOyBpZHItY2hhaXJz QGlldGYub3JnOyBncm93QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbR1JPV10g UXVlc3Rpb24gYWJvdXQgQkdQIExhcmdlIENvbW11bml0aWVzPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+RGlzYWdyZWUsIHdlIHdhbnQgc29tZXRoaW5nIGRlcGxveWVkIChsYXJnZSkgYW5kIGRl cGxveWFibGUgKHJlcXVpcmluZyBvbmx5IElBTkEgYWN0aW9uLCBubyB2ZW5kb3IgYWN0aXZpdHkp IGltbWVkaWF0ZWx5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SU1ITywgYW55IHNwZWNpYWwgaGFuZGxpbmcgb3Ig bmV3IGNvZGUgcG9pbnRzIG9yIHVwZ3JhZGVzIGFyZSBub24tc3RhcnRlcnMuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiPlRoaXMgcGFydGljdWxhcmx5IGFwcGxpZXMgdG8gd2lkZSBhbmQgZXh0ZW5kZWQ8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+QnJpYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFR1ZSwgRmViIDQsIDIwMjAgYXQgNTo0MSBQTSBEb25namll IChKaW1teSkgJmx0OzxhIGhyZWY9Im1haWx0bzpqaWUuZG9uZ0BodWF3ZWkuY29tIj5qaWUuZG9u Z0BodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QWdyZWUgdGhhdCBmb3IgdGhp cyBjYXNlIGl0IG1heSBiZSBtb3JlIGNvbnZlbmllbnQgdG8ganVzdCB1c2UgZXh0ZW5kZWQgY29t bXVuaXR5IHdpdGgNCiBhIG5ldyB0eXBlLCB0aGlzIGNvdWxkIGF2b2lkIGFueSBwb3NzaWJsZSBj b2xsaXNpb24gd2l0aCBleGlzdGluZyBkZXBsb3ltZW50cywgYW5kIHNhdmUgdGhlIGVmZm9ydCBv ZiBhc3NpZ25pbmcgYSBzZXQgb2YgQVNOcy4gV2lkZSBjb21tdW5pdHkgbWF5IGJlIHRvbyBwb3dl cmZ1bCBmb3IgdGhpczopPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkppZTwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUm9iZXJ0DQogUmFzenVrIFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0IiB0YXJnZXQ9Il9ibGFuayI+ cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgRmVi cnVhcnkgNSwgMjAyMCA2OjM4IEFNPGJyPg0KPGI+VG86PC9iPiBKYWtvYiBIZWl0eiAoamhlaXR6 KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpoZWl0ekBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5q aGVpdHpAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IFNyaXJhbSwgS290aWthbGFw dWRpIChGZWQpICZsdDs8YSBocmVmPSJtYWlsdG86a290aWthbGFwdWRpLnNyaXJhbUBuaXN0Lmdv diIgdGFyZ2V0PSJfYmxhbmsiPmtvdGlrYWxhcHVkaS5zcmlyYW1AbmlzdC5nb3Y8L2E+Jmd0Ozsg Sm9iIFNuaWpkZXJzICZsdDs8YSBocmVmPSJtYWlsdG86am9iQG50dC5uZXQiIHRhcmdldD0iX2Js YW5rIj5qb2JAbnR0Lm5ldDwvYT4mZ3Q7OyBOaWNrIEhpbGxpYXJkICZsdDs8YSBocmVmPSJtYWls dG86bmlja0Bmb29iYXIub3JnIiB0YXJnZXQ9Il9ibGFuayI+bmlja0Bmb29iYXIub3JnPC9hPiZn dDs7DQogSm9obiBIZWFzbHkgJmx0OzxhIGhyZWY9Im1haWx0bzpoZWFzQHNocnViYmVyeS5uZXQi IHRhcmdldD0iX2JsYW5rIj5oZWFzQHNocnViYmVyeS5uZXQ8L2E+Jmd0OzsNCjxhIGhyZWY9Im1h aWx0bzppZHJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZHJAaWV0Zi5vcmc8L2E+OyA8YSBo cmVmPSJtYWlsdG86Z3Jvdy1jaGFpcnNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmdyb3ct Y2hhaXJzQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmlkci1jaGFpcnNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5pZHItY2hhaXJzQGlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0 bzpncm93QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Z3Jvd0BpZXRmLm9yZzwvYT48YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtHUk9XXSBRdWVzdGlvbiBhYm91dCBCR1AgTGFyZ2UgQ29tbXVu aXRpZXM8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jmd0OyBI b3cgd291bGQgeW91IGRpdmlkZSB0aGUgbnVtYmVycz8mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+SSB3b3VsZCBub3QgZGl2aWRlIHRoZW0g YXQgYWxsIGluJm5ic3A7TENzLiBJIHdvdWxkIGVpdGhlciBkZWZpbmUgbmV3IHR5cGUgaW4gZXh0 ZW5kZWQgY29tbXVuaXRpZXMgb3IgdXNlIHdpZGUgY29tbXVuaXRpZXMuJm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+QnV0IEkgYW0gYSBi aXQgYmlhc2VkIGhlcmUgOy0pPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyI+QmVzdCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5SLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFR1ZSwgRmViIDQs IDIwMjAgYXQgMTE6MzQgUE0gSmFrb2IgSGVpdHogKGpoZWl0eikgJmx0OzxhIGhyZWY9Im1haWx0 bzpqaGVpdHpAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+amhlaXR6QGNpc2NvLmNvbTwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow Y20gMGNtIDBjbSA2LjBwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2lu LWJvdHRvbTo1LjBwdDttYXJnaW4tbGVmdDo0Li44cHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gbGFuZz0iRU4tVVMiPlRoZSBudW1iZXJzIGFyZSBhIHRyYWRlIG9mZi4gSG93IHdv dWxkIHlvdSBkaXZpZGUgdGhlIG51bWJlcnM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3Ms PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIj5KYWtvYi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIEZl YiA0LCAyMDIwLCBhdCAyOjE5IFBNLCBSb2JlcnQgUmFzenVrICZsdDs8YSBocmVmPSJtYWlsdG86 cm9iZXJ0QHJhc3p1ay4ubmV0IiB0YXJnZXQ9Il9ibGFuayI+cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+ Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+77u/PC9zcGFuPjxz cGFuIGxhbmc9IkVOLVVTIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5BbmQgeW91IHRoaW5rIDI1NSBzdWNo IGtub3duIGxhcmdlIGNvbW11bml0aWVzIHdpbGwgYmUgc3VmZmljaWVudCA/DQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+VGh4LDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0i RU4tVVMiPlIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+T24gVHVlLCBGZWIgNCwgMjAyMCBhdCA5OjQ1IFBNIEpha29iIEhlaXR6IChqaGVpdHop ICZsdDs8YSBocmVmPSJtYWlsdG86amhlaXR6QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmpo ZWl0ekBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6NC4uOHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6IzcwMzBBMCI+QSBzZXQgb2Ygd2VsbCBrbm93biBsYXJnZSBjb21tdW5pdGllcyBjb3Vs ZCBiZSB1c2VmdWwuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj NzAzMEEwIj5JIGhhdmUgYSBkcmFmdCB0aGF0IEkgbmV2ZXIgc3VibWl0dGVkIGF0dGFjaGVkIHRv IHRoaXMgZW1haWwuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjoj NzAzMEEwIj5Eb2VzIGFueW9uZSB3YW50IHRvIGNvLWF1dGhvciBhbmQgc3VnZ2VzdCBjaGFuZ2Vz Pzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzcwMzBBMCI+Jm5i c3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Izcw MzBBMCI+UmVnYXJkcyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OiM3MDMwQTAiPkpha29iLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjojNzAzMEEwIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiPiBTcmlyYW0sIEtvdGlrYWxhcHVkaSAoRmVkKSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmtvdGlrYWxhcHVkaS5zcmlyYW1AbmlzdC5nb3YiIHRhcmdldD0iX2JsYW5rIj5r b3Rpa2FsYXB1ZGkuc3JpcmFtQG5pc3QuZ292PC9hPiZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBU dWVzZGF5LCBGZWJydWFyeSA0LCAyMDIwIDEwOjIyIEFNPGJyPg0KPGI+VG86PC9iPiBKYWtvYiBI ZWl0eiAoamhlaXR6KSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpoZWl0ekBjaXNjby5jb20iIHRhcmdl dD0iX2JsYW5rIj5qaGVpdHpAY2lzY28uY29tPC9hPiZndDs7IEpvYiBTbmlqZGVycyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmpvYkBudHQubmV0IiB0YXJnZXQ9Il9ibGFuayI+am9iQG50dC5uZXQ8L2E+ Jmd0OzsgTmljayBIaWxsaWFyZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5pY2tAZm9vYmFyLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm5pY2tAZm9vYmFyLm9yZzwvYT4mZ3Q7Ow0KIEpvaG4gSGVhc2x5ICZs dDs8YSBocmVmPSJtYWlsdG86aGVhc0BzaHJ1YmJlcnkubmV0IiB0YXJnZXQ9Il9ibGFuayI+aGVh c0BzaHJ1YmJlcnkubmV0PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IDxhIGhyZWY9Im1haWx0bzpp ZHJAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pZHJAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJt YWlsdG86Z3Jvd0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KZ3Jvd0BpZXRmLm9yZzwvYT47 IDxhIGhyZWY9Im1haWx0bzppZHItY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aWRy LWNoYWlyc0BpZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86Z3Jvdy1jaGFpcnNAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5ncm93LWNoYWlyc0BpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1h aWx0bzphLmUuYXppbW92QGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KYS5lLmF6aW1vdkBn bWFpbC5jb208L2E+OyBCcmlhbiBEaWNrc29uICZsdDs8YSBocmVmPSJtYWlsdG86YnJpYW4ucGV0 ZXIuZGlja3NvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5icmlhbi5wZXRlci5kaWNrc29u QGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFF1ZXN0aW9uIGFib3V0IEJH UCBMYXJnZSBDb21tdW5pdGllczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+SW4gdGhlIHJvdXRlIGxlYWtz IHNvbHV0aW9uIGRyYWZ0LCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJF Ti1VUyI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZ3Jv dy1yb3V0ZS1sZWFrLWRldGVjdGlvbi1taXRpZ2F0aW9uLTAyIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZ3Jvdy1yb3V0ZS1sZWFrLWRldGVj dGlvbi1taXRpZ2F0aW9uLTAyPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxh bmc9IkVOLVVTIj53ZSAodGhlIGF1dGhvcnMpIGhhdmUgcHJvcG9zZWQgdXNpbmcgQkdQIExhcmdl IENvbW11bml0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+ V2Ugc3BlY2lmeSB0aGlzIHRvIGJlIGEgJnF1b3Q7d2VsbC1rbm93biB0cmFuc2l0aXZlIExhcmdl IENvbW11bml0eSZxdW90Oy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi PlF1ZXN0aW9uOiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+ Q2FuIHRoZSBkcmFmdCBzaW1wbHkgbWFrZSBhbiBJQU5BIHJlcXVlc3QgZm9yIDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5hIEdsb2JhbCBBZG1pbmlzdHJhdG9y IEFTTiB2YWx1ZSBmb3IgUm91dGUgTGVha3MgUHJvdGVjdGlvbiAoUkxQKSB0eXBlDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+YW5kIHJlcXVlc3QgdGhhdCBp dCBiZSBwdWJsaXNoZWQgaW4gSUFOQSByZWdpc3RyeSA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cD48c3BhbiBsYW5nPSJFTi1VUyI+YXMgYSAmcXVvdDt3ZWxsLWtub3duIFRyYW5zaXRpdmUgTGFy Z2UgQ29tbXVuaXR5JnF1b3Q7PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9 IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1V UyI+VGhlcmUgaXMgbm8gSUFOQSByZWdpc3RyeSBmb3IgTGFyZ2UgQ29tbXVuaXRpZXMgeWV0Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj53ZSBoYXZlIHJlcXVl c3RlZCBJRFIgYW5kIEdST1cgQ2hhaXJzIHRvIGZhY2lsaXRhdGUgdGhhdC48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPi0tLS0tLS0tLS0tLS0tLS08bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+RGV0YWlscy9iYWNrZ3JvdW5kOjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+V2UndmUgcmVhZCB0aGUgZm9sbG93 aW5nIFJGQ3MgcmVsYXRlZCB0byBMYXJnZSBDb21tdW5pdGllczo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL3JmYzgwOTIiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93 dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzgwOTI8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LVVTIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODE5NSIgdGFyZ2V0 PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpu b25lIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODE5NTwvc3Bhbj48L2E+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj5SRkMgODE5NSBoYXMgdGhpcyB0YWJs ZTogPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyYjNDM7LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IFJGQzgwOTImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgfCBSRkMgODE5NSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0mIzQzOy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tJiM0Mzs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IHwgR2xvYmFsIEFkbWluaXN0cmF0b3ImbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBU04mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfCZuYnNwOyBMb2NhbCBEYXRhIFBhcnQgMSZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7 Jm5ic3A7IEZ1bmN0aW9uJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IHwmbmJzcDsgTG9jYWwgRGF0YSBQYXJ0IDImbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyBQYXJh bWV0ZXImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVO LVVTIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYjNDM7LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSYj NDM7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPndoaWNoIGlz IGluc3RydWN0aXZlLiBJbiB0aGUgZXhhbXBsZXMgdGhhdCBSRkMgODE5NSBvZmZlcnMsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPml0IGFwcGVhcnMgaXQgaXMg KmFzc3VtZWQqIHRoYXQgdGhlIExhcmdlIENvbW11bml0aWVzIGFyZSB0cmFuc2l0aXZlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Rm9yIGNvbXBhcmlzb24sIGluIEV4 dGVuZGVkIENvbW11bml0aWVzIChSRkMgNzE1MyksIHRoZXJlIGFyZQ0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPmV4cGxpY2l0IFR5cGUgdmFsdWVzIGFzc2ln bmVkIGZvciBUcmFuc2l0aXZlLCBOb24tdHJhbnNpdGl2ZSwgZXRjLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9 Imh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL2JncC1leHRlbmRlZC1jb21tdW5pdGll cy9iZ3AtZXh0ZW5kZWQtY29tbXVuaXRpZXMueGh0bWwiIHRhcmdldD0iX2JsYW5rIj5odHRwczov L3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9iZ3AtZXh0ZW5kZWQtY29tbXVuaXRpZXMvYmdwLWV4 dGVuZGVkLWNvbW11bml0aWVzLnhodG1sPC9hPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPkhvd2V2ZXIsIHRoZXJl IGlzIG5vIHN1Y2ggZXhwbGljaXQgVHlwZSBzcGVjaWZpY2F0aW9uIDxvOnA+DQo8L286cD48L3Nw YW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMiPmZvciBMYXJnZSBDb21tdW5pdGllcyAoaW4g UkZDIDgwOTIgb3IgZWxzZXdoZXJlKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBs YW5nPSJFTi1VUyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0i RU4tVVMiPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJF Ti1VUyI+U3JpcmFtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gbGFuZz0iRU4tVVMi PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkdST1cgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOkdST1dAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5HUk9XQGlldGYu b3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZ3JvdyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vZ3JvdzwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCkdST1cgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOkdST1dAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5HUk9XQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ3JvdyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZ3JvdzwvYT48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_19AB2A007F56DB4E8257F949A2FB9858E5FFFD27NKGEML515MBXchi_-- From nobody Wed Feb 5 01:01:50 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110BD1202A0 for ; Wed, 5 Feb 2020 01:01:49 -0800 (PST) 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, 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=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 2Y4crFaKItDN for ; Wed, 5 Feb 2020 01:01:47 -0800 (PST) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (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 71EE612029C for ; Wed, 5 Feb 2020 01:01:47 -0800 (PST) Received: by mail-oi1-x22b.google.com with SMTP id l9so12575oii.5 for ; Wed, 05 Feb 2020 01:01:47 -0800 (PST) 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=VEL2ORiR/VfxeuTBlmzRplBOQ7/a/1dJZd+LeRF5R9M=; b=befkKOx+q7UMHEnimGHHlcjLYd0DL1mjGItYglPsRhEaKkJjFUgeb2xCx2/zHO1OAx cyfUv4uF0RuZQRlGALliBgo1hiwGZRpdUuCpoPoj+/fTa6nMQzuGRmBc0pADha6Ioda2 IjOMnIeYcKm0gZfne/NpY1Y/ym9m9Gwb8/9nFS6WwG90DRQb+UCPUcb3kR4cEQGQcHi2 Yy6I0Wvrp3daxla1Zas1AqSmKri1QZ8UL6pMef5JTMzlbvJv3t6ZXkGAYbENoUXICj/h nhFCtn8RmbcRodQXr9/8wm6EY6/o9LPT8mnaxY8Bh3jUhcszaFckzYGvzQR8Tjs77JFq 4syA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VEL2ORiR/VfxeuTBlmzRplBOQ7/a/1dJZd+LeRF5R9M=; b=p1oe4cpuHM9N8Iv0LLC7teRNE+KFMmDXNVoDuhnH8PE2+sQAFQyTExsGJM9OykNpiL 4nhMMM5fh5SyHPWGFyLO/2eW293vfy/IRGtCoXrOqXlnZnkiRmT86YnO+PTc2tJ0Xs7J NfErWM0Vxg/ALNp/2UNj87hTXTZpCTG8HHoTmGjk0snLgGajCuVsH22Lsot9ruGZK3F0 cRwaaEcOaSuQAKNlY5OjVM/N3nQEQW0Sn1OcABZXgWGHi087GMhYG/Q3O9YXL5fFY+pY w3tsHihXv0ackLM2fmVhe00VFWahtzPtAIVFpo0QUwIFOgdiUsXfIHAdOiw+uKY23+p3 eAmg== X-Gm-Message-State: APjAAAV59F+IB/Duivzf0Z+mXDYYEk81prD4FTwOdlNyoT8R5wmveNEl ZSvdbgHQqRjfzPol7rcih+ptMFus3+QltOEJ1TP0Pg== X-Google-Smtp-Source: APXvYqwDHAoDVAZpj3KIHahrIFamCgJbou00hTpQLaIHfvkCt5CT1RJXkP4UIgRrM9DMCWj5qOtseSb4Au8NQ/6HRUE= X-Received: by 2002:aca:4306:: with SMTP id q6mr2195413oia.54.1580893306642; Wed, 05 Feb 2020 01:01:46 -0800 (PST) MIME-Version: 1.0 References: <5603F4C9-7ECD-4A9C-AF81-49AE292CEE83@cisco.com> <90fab3d5ec794e95be0d86cae2d4a235@huawei.com> In-Reply-To: From: Robert Raszuk Date: Wed, 5 Feb 2020 10:01:37 +0100 Message-ID: To: Brian Dickson Cc: "Dongjie (Jimmy)" , "Jakob Heitz (jheitz)" , "idr@ietf.org" , "grow-chairs@ietf.org" , "idr-chairs@ietf.org" , "grow@ietf.org" Content-Type: multipart/alternative; boundary="000000000000f87679059dd067f2" Archived-At: Subject: Re: [Idr] [GROW] Question about BGP Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 09:01:49 -0000 --000000000000f87679059dd067f2 Content-Type: text/plain; charset="UTF-8" Just to clarify one subtle point. In wide communities types are either operator assigned or IANA driven - no new code from vendor is required in contrast to extended community. That along with variable length is what makes wide communities universal. Sure that some vendors or individuals are scared about policy aspect of wide communities processing - but implementing policy handling any arbitrary types (irrespective of IANA or local assignment) is optional. - - - To the topic of using Large Communities - I do recommend whichever encoding is chosen to always be able to insert and carry originator's ASN. All zeros are meaningless read: anonymous. Thx, R. On Wed, Feb 5, 2020 at 2:45 AM Brian Dickson wrote: > Disagree, we want something deployed (large) and deployable (requiring > only IANA action, no vendor activity) immediately. > IMHO, any special handling or new code points or upgrades are non-starters. > This particularly applies to wide and extended > Brian > > On Tue, Feb 4, 2020 at 5:41 PM Dongjie (Jimmy) > wrote: > >> Agree that for this case it may be more convenient to just use extended >> community with a new type, this could avoid any possible collision with >> existing deployments, and save the effort of assigning a set of ASNs. Wide >> community may be too powerful for this:) >> >> >> >> Best regards, >> >> Jie >> > --000000000000f87679059dd067f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Just to clarify=C2=A0one subtle point.= =C2=A0

In wide communities=C2=A0types = are either operator assigned or IANA driven - no new code from vendor is=C2= =A0required in contrast to extended community. That along with variable len= gth is what makes wide communities universal.=C2=A0

Sure that some vendors or individuals are scared about policy aspect of w= ide communities processing - but implementing policy handling any arbitrary= types (irrespective of IANA or local assignment) is optional.=C2=A0=C2=A0<= /div>

- - -=C2=A0

To the topic = of using Large Communities - I do recommend whichever encoding is chosen to= always be able to insert and carry originator's ASN. All zeros are mea= ningless read: anonymous.=C2=A0

Thx,
R.


On Wed, Feb 5, 2020 at 2:45 AM Brian Dickson <brian.peter.dickson@gmail.com> wrote:<= br>
Disagree, we want something deployed (large) and deployable (requiring onl= y IANA action, no vendor activity) immediately.
IMHO, any special handl= ing or new code points or upgrades are non-starters.
This particu= larly applies to wide and extended
Brian

On Tue, Feb 4, 2020= at 5:41 PM Dongjie (Jimmy) <jie.dong@huawei.com> wrote:

Agree that for this case it= may be more convenient to just use extended community with a new type, thi= s could avoid any possible collision with existing deployments, and save the effort of assigning a set of ASNs. Wide communit= y may be too powerful for this:)

=C2=A0=

Best regards,=

Jie

--000000000000f87679059dd067f2-- From nobody Wed Feb 5 02:15:23 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55DC31207FD; Wed, 5 Feb 2020 02:15:18 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 pmWbNFJwa5Rb; Wed, 5 Feb 2020 02:15:14 -0800 (PST) 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 2DAA71207FC; Wed, 5 Feb 2020 02:15:13 -0800 (PST) X-Envelope-To: idr@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.15.2/8.15.2) with ESMTPSA id 015AErJH030031 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 5 Feb 2020 10:14:55 GMT (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: Zhuangshunwan Cc: "idr@ietf.org" , "grow@ietf.org" References: <5603F4C9-7ECD-4A9C-AF81-49AE292CEE83@cisco.com> <90fab3d5ec794e95be0d86cae2d4a235@huawei.com> <19AB2A007F56DB4E8257F949A2FB9858E5FFFD27@NKGEML515-MBX.china.huawei.com> From: Nick Hilliard Message-ID: <5bdaf912-5fa7-0bab-6f4d-b18f5a2ee016@foobar.org> Date: Wed, 5 Feb 2020 10:14:52 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.11 MIME-Version: 1.0 In-Reply-To: <19AB2A007F56DB4E8257F949A2FB9858E5FFFD27@NKGEML515-MBX.china.huawei.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Idr] [GROW] Question about BGP Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 10:15:19 -0000 Zhuangshunwan wrote on 05/02/2020 09:00: > In my opinion, when we apply a new function from IANA, we will have to > deploy some extra route policies to set and parse the specific function > as your suggested way. > > With the increase of new functions, the route policies deployed will > become more and more complicated. A WKC will generally describe a specific function or set of actions to be applied to a prefix. If the WKC also encodes an administrator ASN or a target ASN, then it becomes a domain-specific community rather than a well-known community. I'm not against the idea of LC WKCs in theory, but there would need to be compelling reasons as to why the existing rfc1997 wkc range didn't work. IOW, we should think twice about setting aside a range unless there are specific deployment cases which need LCs, and where rfc 1997 communities wouldn't work. Nick From nobody Wed Feb 5 02:42:33 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D72C12029C; Wed, 5 Feb 2020 02:42:31 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 2Lcup20yhy3Q; Wed, 5 Feb 2020 02:42:28 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 C6CA912012D; Wed, 5 Feb 2020 02:42:28 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1izI8Y-00034o-8t; Wed, 05 Feb 2020 10:42:26 +0000 Date: Wed, 05 Feb 2020 02:42:25 -0800 Message-ID: From: Randy Bush To: "Jakob Heitz (jheitz)" Cc: Interminable Discussions on Routing , GMO Crops In-Reply-To: References: <20200204225458.GB57481@shrubbery.net> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Idr] Question about BGP Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 10:42:31 -0000 > I'm asking for 67 million AS numbers, after which there will still be > over 4 billion AS numbers, > not including the nearly 95 million private AS numbers. should be enough. after all, ipv6 only had 4096 possible providers From nobody Wed Feb 5 02:46:44 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72DA41207FC; Wed, 5 Feb 2020 02:46:43 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 IpGJi9eAg1zx; Wed, 5 Feb 2020 02:46:42 -0800 (PST) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 26A2012012D; Wed, 5 Feb 2020 02:46:42 -0800 (PST) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1izICe-00035O-Gc; Wed, 05 Feb 2020 10:46:40 +0000 Date: Wed, 05 Feb 2020 02:46:39 -0800 Message-ID: From: Randy Bush To: Robert Raszuk Cc: Interminable Discussions on Routing , GMO Crops In-Reply-To: References: <5603F4C9-7ECD-4A9C-AF81-49AE292CEE83@cisco.com> <90fab3d5ec794e95be0d86cae2d4a235@huawei.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Idr] [GROW] Question about BGP Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Feb 2020 10:46:44 -0000 > To the topic of using Large Communities - I do recommend whichever encoding > is chosen to always be able to insert and carry originator's ASN. All zeros > are meaningless read: anonymous. one can no longer assume all actors have good intent. communities are arbitrary graffiti whose beauty lies in the eyes of the beholder. one can not assume rigor. randy From nobody Thu Feb 6 01:58:57 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE205120288; Thu, 6 Feb 2020 01:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, BODY_ENHANCEMENT=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 8_j7GwfdE66U; Thu, 6 Feb 2020 01:58:50 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 509B6120271; Thu, 6 Feb 2020 01:58:50 -0800 (PST) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 9350699842B9A3E7E848; Thu, 6 Feb 2020 09:58:48 +0000 (GMT) Received: from nkgeml702-chm.china.huawei.com (10.98.57.155) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 6 Feb 2020 09:58:48 +0000 Received: from nkgeml701-chm.china.huawei.com (10.98.57.156) by nkgeml702-chm.china.huawei.com (10.98.57.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 6 Feb 2020 17:58:45 +0800 Received: from nkgeml701-chm.china.huawei.com ([10.98.57.156]) by nkgeml701-chm.china.huawei.com ([10.98.57.156]) with mapi id 15.01.1713.004; Thu, 6 Feb 2020 17:58:45 +0800 From: "Dongjie (Jimmy)" To: "Sriram, Kotikalapudi (Fed)" , John Heasly , "Jakob Heitz (jheitz)" CC: "idr@ietf.org" , "grow@ietf.org" Thread-Topic: Question about BGP Large Communities Thread-Index: AdXbeNI4t0SppYFnSky8PqLGmuct1gAIu5NA//+eogCAACrygP/9XlgQ Date: Thu, 6 Feb 2020 09:58:45 +0000 Message-ID: <402069c4103c4a4783972e3803327c85@huawei.com> References: <20200204225458.GB57481@shrubbery.net> 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.45.182.24] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] Question about BGP Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 09:58:53 -0000 If I understand it correctly, the proposed mechanism in Jakob's draft requi= res to change the encoding of Global Administrator in Large community. In g= eneral I like this change, it gives LC a structural encoding, which may be = useful for future use cases. OTOH, this change typically would require new = code and upgrade of devices, which may not meet the requirement mentioned i= n Brian's mail... Best regards, Jie > -----Original Message----- > From: GROW [mailto:grow-bounces@ietf.org] On Behalf Of Sriram, > Kotikalapudi (Fed) > Sent: Wednesday, February 5, 2020 9:29 AM > To: John Heasly ; Jakob Heitz (jheitz) > Cc: idr@ietf.org; grow@ietf.org > Subject: Re: [GROW] Question about BGP Large Communities >=20 > > > Does anyone want to co-author and suggest changes? > I would also be glad to participate in that effort. >=20 > I have looked at the proposals in the two drafts (Jacob and John H). > There are a few observations I would like to share. >=20 > As Alvaro pointed out, RFC 8092 says: > This document defines the BGP Large Communities attribute as an > optional transitive path attribute of variable length. >=20 > That means *all* BGP Large Communities are transitive. Do you agree? > RFC 8195 seems to be written in that spirit as well. >=20 > The first 32 bits together are a Global Administrator (GA) ID. > So, it seems it would not be possible to use any part of it as data. > Otherwise, collisions (ambiguity) could happen when other LCs use 4-octet > ASNs in the Global Administrator field. Agree? > I see Jacob's draft proposes using some portion of the first 32 bits as d= ata. > The draft that John Heasly shared sets the first 32-bits to ASN value 0 t= o > designate WK-LC; so no part of the first 32-bits is data. >=20 > Another idea to consider: > Why not request IANA to assign a range of 256 or 1024 or some number (?) = of > 4-byte ASN values to be allocated and used as GA ID for transitive WK-LCs= ? > A function (e.g., route-leak protection) that requires transitive WK-LC w= ill be > allocated one these ASN values. > Then we don't waste any part of the first 32-bits to designate "type" of = LC. > That cleanly leaves 64 bits for local data (as RFC 8092 specifies) which = can > accommodate two 4-byte ASNs if needed. >=20 > Sriram >=20 > > -----Original Message----- > > From: John Heasly > > Sent: Tuesday, February 4, 2020 5:55 PM > > To: Jakob Heitz (jheitz) > > Cc: Sriram, Kotikalapudi (Fed) ; Job > > Snijders ; Nick Hilliard ; John Heasly > > ; idr@ietf.org; grow@ietf.org; > > idr-chairs@ietf.org; grow-chairs@ietf.org; a.e.azimov@gmail.com; Brian > > Dickson > > Subject: Re: Question about BGP Large Communities > > > > Tue, Feb 04, 2020 at 08:45:40PM +0000, Jakob Heitz (jheitz): > > > A set of well known large communities could be useful. > > > I have a draft that I never submitted attached to this email. > > > Does anyone want to co-author and suggest changes? > > > > Hey Jacob, > > I'd work on that with you. Job, Morrow and I also started a draft for > > Large WKCs, but we have not submitted anything - nor made any recent > > progress. > > > > IIRC, the direction we were intending to use 0 (zero) as the ASN, then > > define local data part 1 as WKC itself, and local data part 2 to be a > > value associated. > > > > I've attached that I have written so far. Job and Morrow may or may > > not endorse this approach at this point. > > > > -heas >=20 > _______________________________________________ > GROW mailing list > GROW@ietf.org > https://www.ietf.org/mailman/listinfo/grow From nobody Thu Feb 6 05:01:28 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E54C12089E for ; Thu, 6 Feb 2020 05:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.923 X-Spam-Level: *** X-Spam-Status: No, score=3.923 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.275, SPF_HELO_NONE=0.001, SPF_NONE=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 8cfLJn927M3v for ; Thu, 6 Feb 2020 05:01:25 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 D48CD1201B7 for ; Thu, 6 Feb 2020 05:01:24 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=107.92.122.151; From: "Susan Hares" To: Date: Thu, 6 Feb 2020 08:01:21 -0500 Message-ID: <009701d5dced$882650f0$9872f2d0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0098_01D5DCC3.9F5048F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdXc7WI8wxWTveucSwmQaTeiTUzQiA== Content-Language: en-us X-Antivirus: AVG (VPS 200205-0, 02/05/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] Request for aid - remind of WG adoptions and WG LCs X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 13:01:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0098_01D5DCC3.9F5048F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings IDR: I have been out of touch since early December due to surgery on my left hand. I am just returning to my IETF email and IETF work this week. John Scudder and Jie Dong have done a wonderful job handling things in my absence. I would like to request aid from those who have requested WG adoptions or WG LCs. Since we have about 6 weeks until IETF, I would like to make sure I start all WG adoption or LCs as soon as possible. Thank you, Susan Hares ------=_NextPart_000_0098_01D5DCC3.9F5048F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings = IDR:

 

I have been out of touch since early December due to = surgery on my left hand.   I am just returning to my IETF = email and IETF work this week.   John Scudder and Jie Dong = have done a wonderful job handling things in my absence. =

 

I would like to request aid from those who have = requested WG adoptions or WG LCs.    Since we have about = 6 weeks until IETF, I would like to make sure I start all WG adoption or = LCs as soon as possible.

 

Thank you, =

 

Susan Hares

 

------=_NextPart_000_0098_01D5DCC3.9F5048F0-- From nobody Thu Feb 6 08:03:04 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E961200F1; Thu, 6 Feb 2020 08:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpeGMIyWeWQ0; Thu, 6 Feb 2020 08:02:56 -0800 (PST) Received: from GCC02-DM3-obe.outbound.protection.outlook.com (mail-dm3gcc02on2129.outbound.protection.outlook.com [40.107.91.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 110631200C4; Thu, 6 Feb 2020 08:02:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fOSOoXL5RMIsaIddyohM7rbd8R+txgfAUV6pFDhTDFBxMAkpL6UgSSPvfR9IFAVNJ17a28+vPXGXXo3ai/VKOt8hnNwLVWiG6j5fOLYJTl1x0WpZZrmg5plNfMGdhe6FLrMNgRarrXN6l+YLogrNUcHk40e+sgiWfNnKPJWJVOwTZQl1v2dKOyut8WoNa/ZbdxU7RD5saQH6+m+kUziLwIN+5ES1rHhK2AXx3xIR6Nm2O1yn8ttKsb3m4xegaBAZqV2fjIwHooxUaeMRigT+ju5hIlBAtyvtiioagSxuaO9cNC6zY0FwTWWYf+lXOl/SXRFrB97cgyryGXIuzAS3DA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IhoELAsiG5EEcrAV2OLJsJkFTSqkLuqScl7HD6lRJm8=; b=HSeYtawmucUt4NUf+d+Bi8g+homwkMaaJnslEyQXJFqwbDFfmCuB/KwPhu0Fuo2b/BO91tTRQv/xVy0+7bRFppo4OBkIh00NbbsXBuJZsZvbxXqrtNJlSahHfVNU9f5puhnd/5St0dLagz6lTQ8c1Ft31nCSyfIKo1a96aruY4yh+OWxTd760NOU9yvkVasE9km1U729GJTSFir/u/Jdoi1GWl69LlB/oZw7eematlFb8rnoy9brlApUl5FQlDeb97vJ+XzvhfqqaXG13BytPhJ6H44qc70QBwJ4gr4iJQB7SvQs/7LhfFNhS/VN4FQ0pZZBQnfHW2muBBAH6BVNEQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nist.gov; dmarc=pass action=none header.from=nist.gov; dkim=pass header.d=nist.gov; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IhoELAsiG5EEcrAV2OLJsJkFTSqkLuqScl7HD6lRJm8=; b=m088fTt3uy2pgVSWBxK0YGymLJmUrzjN00XHi6SHsdNovi12ZS7Iqmf32s1kRK705jRbamNcCtPWJeXad9IH+wMbdiccTpXGBVJxLBXBQJQ8IL1G1S6q2hUyunxipnFHrGg3nxewpWSj7xC1XPSl3jivpL/OlGzKzclMgIspsi4= Received: from DM6PR09MB5847.namprd09.prod.outlook.com (20.180.63.204) by DM6PR09MB4631.namprd09.prod.outlook.com (20.180.62.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2707.23; Thu, 6 Feb 2020 16:02:54 +0000 Received: from DM6PR09MB5847.namprd09.prod.outlook.com ([fe80::b5b6:be35:62fe:acfd]) by DM6PR09MB5847.namprd09.prod.outlook.com ([fe80::b5b6:be35:62fe:acfd%6]) with mapi id 15.20.2707.023; Thu, 6 Feb 2020 16:02:54 +0000 From: "Sriram, Kotikalapudi (Fed)" To: "Jakob Heitz (jheitz)" , Brian Dickson CC: John Heasly , "idr@ietf.org" , "grow@ietf.org" Thread-Topic: Question about BGP Large Communities Thread-Index: AdXbeNI4t0SppYFnSky8PqLGmuct1gAIu5NAAASXzAAAA08B8AACkBOAAACpoRAATrUpAA== Date: Thu, 6 Feb 2020 16:02:54 +0000 Message-ID: References: <20200204225458.GB57481@shrubbery.net> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=kotikalapudi.sriram@nist.gov; x-originating-ip: [129.6.219.234] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f9ccde55-c2b6-4294-7dbe-08d7ab1e067b x-ms-traffictypediagnostic: DM6PR09MB4631: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:972; x-forefront-prvs: 0305463112 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(366004)(39860400002)(376002)(346002)(189003)(199004)(66476007)(76116006)(91956017)(66946007)(64756008)(66556008)(66446008)(33656002)(71200400001)(9686003)(86362001)(2906002)(7696005)(478600001)(558084003)(110136005)(54906003)(26005)(6506007)(4326008)(186003)(81156014)(8676002)(5660300002)(81166006)(55016002)(8936002)(52536014)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM6PR09MB4631; H:DM6PR09MB5847.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: uGYDyNB17IDy/COpwynntKVxFBdi21zDvie+JYe3A92xywDzwVro0c/CAYQj5rUKnslcrc8eJKEI03FF3SD3FlEKrSHVNtWtlOxHrICGrG2Ip722nHp4CksuhSNmyocUnYF/y1LXmCFOehYS9edNj0p2DP3KzUJ45DUD7aUQEiLhPFyREhA//0kGtIEvdcE7yKyYE0KgcFJMy5VMlusubbsk2DI/HhLoQQEqI2I9/85Sl73+FFtd156lgMNZS1MqdCbXcllRFuAv+epFBkrdr0ZbfBZXuM73BQN2VSevngs+jgqy5W89DbDXg3l18cOO3mheeggSctH4GOwP+S48Vl1ayLalEsbyhJ5NMA5dTybqF11thMG9bU1qe/20rqAHgm+A1Y6KEBreEpjhiI17aVGA21/2Nm7286EH0ekE7iHOXQu50OMa4F8ORp3mVn1V x-ms-exchange-antispam-messagedata: ZU99pUBPKM65CPcxNIEkI5jPuvy4x7fxWcycs7z0wf1EJvGZq9YN/0uc97MfY1+Kw48LJYsZHlN6JtWvTpOfmE894596WjPw+oRvIojkOPOegKW7A0Km5+KgHRXlBw8uk5nNo9Z73jpFFokTktlInw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: f9ccde55-c2b6-4294-7dbe-08d7ab1e067b X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Feb 2020 16:02:54.2060 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Z7SDSwjL3XYZNnAGxS823Yr44Cftn6kv7EByRvV65wilFxN2dokJBPQAZJs9SnwV0K+jjbF2DSgGfNWr6uey7w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR09MB4631 Archived-At: Subject: Re: [Idr] Question about BGP Large Communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2020 16:02:59 -0000 Jakob,=0A= =0A= >Private ASNs are 4,200,000,000 upwards.=0A= >I am requesting a block just below that > 4,000,000,000.=0A= =0A= That sounds reasonable.=0A= We can discuss trading off some bits between WKLC ID and Data 1=0A= to possibly give room for more than 256 WKLCs.=0A= =0A= Sriram =0A= From nobody Tue Feb 11 08:32:01 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0667B12023E; Tue, 11 Feb 2020 08:31:59 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 nQucAr4HZBwg; Tue, 11 Feb 2020 08:31:56 -0800 (PST) Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450: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 6894F120122; Tue, 11 Feb 2020 08:31:33 -0800 (PST) Received: by mail-ed1-x52f.google.com with SMTP id r21so5415738edq.0; Tue, 11 Feb 2020 08:31:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=EU3ooiCe0ZSjhgRUi+pdoIsHG4Nl0bU+VntU5rTzAKs=; b=Db8v8gaQpm9CdwdyO3AKANy7XxpN4gw5m3WuriAWgwnPfjE5my1d6/qn5DTz7OvUdx rB3OQ+Ytw19VMYAafxWNZQD8l7Qhi3ca+Vq9uwX0U/IlCNnIsAWfKZUqtIZFqKobNArw g4ipA3BMFIo7xjuBRPbnS3s8uw9afxULeDXqUESpTtXaCEymbjioPvHQesZuADq+7zXh LD1rFCE6fvDEo3euWCEwSRxulEs0CxgOy8I3JCWqhQIrS7H8kN5GkU8cKwV4QN/pAVxc Y+qMzKAqPBTzoD0BzcVOTTbAV/Vb4KQRMRiQvyUgchMhGmCIMmb48dLkxyZ3dt+Qd3uC rIRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=EU3ooiCe0ZSjhgRUi+pdoIsHG4Nl0bU+VntU5rTzAKs=; b=SHBDovp3qZuo+u0dU8n/gmu0LUbvovKP1A2wq7FHlMXQW0S3lqhcxv4NiUEo0rcGsz 9FaC2V8pvcip3R/FCJh/D3xCpHB4n7HnCfiElB3qokuuXs3tQGcYhM3RJSU3ZMlwNAtl vFiDKIgvBKrT0vZ/JOybUScx97OZM7dqzbNsC3e9+5wmCKLMXi5Ezn0hGRrMyZ2dDqCU z4jNw1XpJVIk0qbIkkz4q9Ev16cFHkOpzuOCMzWW8I4n8z1Ojvy9livm3NcBqoDEc5KH 6bTXShjmkWNhjGE/bO9ptdWHaeh5zTUKL1O4Sy83d0utnxqiyw0e3FPH5fkqLnsLWpeL jpRg== X-Gm-Message-State: APjAAAVi/eEYkawbSAiILT3kYA9PBjMNjpF8vaqQc7HOo0gt/zTWesKn baFDruXNJ9e23MxxfHWVJhVYIEoiW4eqh3UO6Lv8NQ== X-Google-Smtp-Source: APXvYqzWWIHIvkMe4yy8rrrAf7HZ6y6L3UQwq7oGKy5YqZvydCwNoNGIcnr+HP3kxCvHllB+WAmCTMaJP4omF6l0qcU= X-Received: by 2002:a17:906:9458:: with SMTP id z24mr6950812ejx.155.1581438691526; Tue, 11 Feb 2020 08:31:31 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 11 Feb 2020 16:31:30 +0000 From: Alvaro Retana MIME-Version: 1.0 Date: Tue, 11 Feb 2020 16:31:30 +0000 Message-ID: To: draft-ietf-idr-capabilities-registry-change@ietf.org Cc: Susan Hares , idr-chairs@ietf.org, "idr@ietf. org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Idr] AD Review of draft-ietf-idr-capabilities-registry-change-06 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 16:31:59 -0000 John: Hi! =C2=A0Thanks for your work on this document! I have a couple of important items that need to be addressed before moving this document forward, specifically about change control and a couple more values that should be deprecated. =C2=A0Please see in-line. I will wait for an update before starting the IETF LC. Thanks!! Alvaro. [Line numbers from idnits.] ... 11 =C2=A0 =C2=A0Abstract 13 =C2=A0 =C2=A0 =C2=A0 This document updates RFC 5492 by making a change t= o the registration 14 =C2=A0 =C2=A0 =C2=A0 procedures for BGP Capability Codes. =C2=A0Specific= ally, the range 15 =C2=A0 =C2=A0 =C2=A0 formerly designated "Reserved for Private Use" is d= ivided into three 16 =C2=A0 =C2=A0 =C2=A0 new ranges, respectively designated as "First Come = First Served", 17 =C2=A0 =C2=A0 =C2=A0 "Experimental" and "Reserved". [nit] s/Experimental/Experimental Use ... 63 =C2=A0 =C2=A01. =C2=A0Introduction 65 =C2=A0 =C2=A0 =C2=A0 [RFC5492] designates the range of Capability Codes = 128-255 as 66 =C2=A0 =C2=A0 =C2=A0 "Reserved for Private Use". =C2=A0Subsequent experi= ence has shown this to 67 =C2=A0 =C2=A0 =C2=A0 be not only useless, but actively confusing to impl= ementors. =C2=A0BGP 68 =C2=A0 =C2=A0 =C2=A0 Capability Codes do not meet the criteria for "Priv= ate Use" described 69 =C2=A0 =C2=A0 =C2=A0 in [RFC8126] section 4.1. =C2=A0An example of a leg= itimate "private use" 70 =C2=A0 =C2=A0 =C2=A0 code point might be a BGP community [RFC1997] value= assigned for use 71 =C2=A0 =C2=A0 =C2=A0 within a given Autonomous System, but no analogous = use of 72 =C2=A0 =C2=A0 =C2=A0 Capabilities exists. [nit/potential rathole] I don=E2=80=99t see why Capabilities Advertisement can=E2=80=99t meet the =E2=80=9Cfor private or local use only=E2=80=9D crit= eria in rfc8126. =C2=A0I guess we just don=E2=80=99t know of any local-only capability! =C2=A0;-) Seriously, I=E2=80=99m not going to object the justification, or strongly a= sk you to change it, but others in the IESG might. =C2=A0Suggestion: Leave just the first two sentences. ... 85 =C2=A0 =C2=A02. =C2=A0Discussion ... 100 =C2=A0 =C2=A0 =C2=A0 The reason for designating "IESG" as the change co= ntroller for all 101 =C2=A0 =C2=A0 =C2=A0 registrations is that while it should be easy to o= btain a Capability 102 =C2=A0 =C2=A0 =C2=A0 Code, once registered it's not a trivial matter to= safely and 103 =C2=A0 =C2=A0 =C2=A0 interoperably change the use of that code, and thu= s working group 104 =C2=A0 =C2=A0 =C2=A0 consensus should be sought before changes are made= to existing 105 =C2=A0 =C2=A0 =C2=A0 registrations. [minor] I don=E2=80=99t think this paragraph is needed because =E2=80=9CFor= registries created by RFCs in the IETF stream, change control for the registry lies by default with the IETF, via the IESG.=E2=80=9D [rfc8126] [] I think it is confusing (at least to me) the text about =E2=80=9Cworking group consensus=E2=80=9D if the change controller is the IESG, and we're dealing with FCFS. =C2=A0Again, I don=E2=80=99t think this paragraph is nee= ded. 107 =C2=A0 =C2=A0 =C2=A0 Finally, we invite implementors who have used valu= es in the range 108 =C2=A0 =C2=A0 =C2=A0 128-255 to contribute to this draft, so that the v= alues can be 109 =C2=A0 =C2=A0 =C2=A0 included in the registry. =C2=A0Values that have b= een reported, are 110 =C2=A0 =C2=A0 =C2=A0 included. [nit] The invitation is not needed, since the draft is now =E2=80=9Cdone=E2= =80=9D and the values are already included... 112 =C2=A0 =C2=A03. =C2=A0IANA Considerations ... 119 =C2=A0 =C2=A0 =C2=A0 Registry Owner/Change Controller: IESG [] See above. 121 =C2=A0 =C2=A0 =C2=A0 Registration procedures: 123 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 +---------+-------------------------+ 124 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0Range =C2=A0| Registration Procedures | 125 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 +---------+-------------------------+ 126 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0 1-63 =C2=A0| IETF Review =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 | 127 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A064-238 | First Come First Served | 128 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | 239-254 | Experimental =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 129 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 +---------+-------------------------+ [minor] Please add Figure/Table numbers. 131 =C2=A0 =C2=A0 =C2=A0 Note: a separate "owner" column is not provided be= cause the owner of 132 =C2=A0 =C2=A0 =C2=A0 all registrations, once made, is "IESG". [major] The IANA review (which I now notice was only sent to Sue and me), says: "Since part of the registry will be First Come First Served, we'll be adding a change controller column, per RFC 8126." [That is the full review...] =C2=A0"Change controller" and "owner" are the same thing; I think it would be ok to rename the "Reference" column (below) to "Reference / Change Controller". 134 =C2=A0 =C2=A0 =C2=A0 IANA is requested to perform the following new all= ocations within the 135 =C2=A0 =C2=A0 =C2=A0 "Capability Codes" registry: 137 =C2=A0 =C2=A0 =C2=A0 +-------+-----------------------------------------= ------+-----------+ 138 =C2=A0 =C2=A0 =C2=A0 | Value | Description =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | Reference | 139 =C2=A0 =C2=A0 =C2=A0 +-------+-----------------------------------------= ------+-----------+ 140 =C2=A0 =C2=A0 =C2=A0 | =C2=A0128 =C2=A0| Prestandard Route Refresh (dep= recated) =C2=A0 =C2=A0 =C2=A0 =C2=A0| (this =C2=A0 =C2=A0 | 141 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | document) = | 142 =C2=A0 =C2=A0 =C2=A0 +-------+-----------------------------------------= ------+-----------+ 143 =C2=A0 =C2=A0 =C2=A0 | =C2=A0129 =C2=A0| Prestandard Outbound Route Fil= tering =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| (this =C2=A0 =C2=A0 | 144 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | (deprecated), prestandard= draft-li-idr- =C2=A0 =C2=A0 =C2=A0 | document) | 145 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | flowspec-rpd-04 (deprecat= ed) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 146 =C2=A0 =C2=A0 =C2=A0 +-------+-----------------------------------------= ------+-----------+ 147 =C2=A0 =C2=A0 =C2=A0 | =C2=A0130 =C2=A0| Prestandard Outbound Route Fil= tering =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| (this =C2=A0 =C2=A0 | 148 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | (deprecated) =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| document) | 149 =C2=A0 =C2=A0 =C2=A0 +-------+-----------------------------------------= ------+-----------+ 150 =C2=A0 =C2=A0 =C2=A0 | =C2=A0255 =C2=A0| Reserved =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| (this =C2=A0 =C2=A0 | 151 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | document) = | 152 =C2=A0 =C2=A0 =C2=A0 +-------+-----------------------------------------= ------+-----------+ [major] There is mention in the mail archive of other values that should also be deprecated [1]. - "131 (CISCO multi-session)" - "184, cumulus hostname draft" - "185, operational draft" [1] https://mailarchive.ietf.org/arch/msg/idr/eIoTAz3wS6dJMKBoIxwrAk98lxM From nobody Tue Feb 11 14:39:24 2020 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 69763120826; Tue, 11 Feb 2020 14:39:22 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: idr-chairs@ietf.org, aretana.ietf@gmail.com, lflynn@amsl.com, idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.117.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158146076239.20006.16460862095203255139.idtracker@ietfa.amsl.com> Date: Tue, 11 Feb 2020 14:39:22 -0800 Archived-At: Subject: [Idr] idr - Update to a Meeting Session Request for IETF 107 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Feb 2020 22:39:22 -0000 An update to a meeting session request has just been submitted by Liz Flynn, on behalf of the idr working group. --------------------------------------------------------- Working Group Name: Inter-Domain Routing Area Name: Routing Area Session Requester: Liz Flynn Number of Sessions: 2 Length of Session(s): 2 Hours, 1.5 Hours Number of Attendees: 75 Conflicts to Avoid: Chair Conflict: i2rs grow lsvr bess Technology Overlap: sidrops lsr spring rtgwg People who must be present: Susan Hares John Scudder Alvaro Retana Resources Requested: Special Requests: Schedule on Monday or Tuesday due to chair conflict. --------------------------------------------------------- From nobody Wed Feb 12 15:11:43 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 478E2120013; Wed, 12 Feb 2020 15:11:42 -0800 (PST) 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, 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 eRYWypqXU9Kb; Wed, 12 Feb 2020 15:11:40 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id A5557120033; Wed, 12 Feb 2020 15:11:40 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 5A32C1E2F6; Wed, 12 Feb 2020 18:17:12 -0500 (EST) Date: Wed, 12 Feb 2020 18:17:12 -0500 From: Jeffrey Haas To: draft-ietf-idr-segment-routing-te-policy@ietf.org, idr@ietf.org Message-ID: <20200212231711.GB32507@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Idr] draft-ietf-idr-segment-routing-te-policy Policy Name Sub-TLV considerations X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 23:11:42 -0000 Authors, In draft-ietf-idr-segment-routing-te-policy-08, Section 2.4.6 we have a TLV for Policy Name. Its text is: : 2.4.6. Policy Name Sub-TLV : : An operator MAY set the Policy Name sub-TLV to attach a symbolic name : to the SR Policy candidate path. : : Usage of Policy Name sub-TLV is described in section 2 in : [I-D.ietf-spring-segment-routing-policy]. : : The Policy Name sub-TLV may exceed 255 bytes length due to long : policy name. Therefore a 2-octet length is required. According to : [I-D.ietf-idr-tunnel-encaps], the first bit of the sub-TLV codepoint : defines the size of the length field. Therefore, for the Policy Name : sub-TLV a code point of 128 or higher is used. : : The Policy Name sub-TLV is optional and it MUST NOT appear more than : once in the SR Policy TLV. : : The Policy Name sub-TLV has following format: : : 0 1 2 3 : 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : | Type | Length | RESERVED | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : // Policy Name // : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : Where: : : Type: 129. : : Length: Variable. : : RESERVED: 1 octet of reserved bits. SHOULD be set to zero on : transmission and MUST be ignored on receipt. : : Policy Name: Symbolic name for the policy. It SHOULD be a string : of printable ASCII characters, without a NULL terminator. draft-ietf-spring-segment-routing-policy-06, Section 2.1 discusses this Sub-TLV: : An implementation MAY allow assignment of a symbolic name comprising : of printable ASCII characters to an SR Policy to serve as a user- : friendly attribute for debug and troubleshooting purposes. Such : symbolic names may identify an SR Policy when the naming scheme : ensures uniqueness. There are two observations I'd like to make: 1. A 65K length isn't very likely in BGP. :-) I suggest that greater guidance for shorter names should be offered. For example, perhaps limit the length to 1K. Alternatively, offer advice such as: "Implementations may choose to truncate long Policy Names". 2. The guidance about "printable ASCII" is rather old-style and likely to run askance of IESG review for internationalization considerations. I'd suggest that the field be encoded in UTF-8 and make reference to print-safety similar to RFC 8203 (BGP Administrative Shutdown) in its Security Considerations. -- Jeff From nobody Wed Feb 12 15:36:08 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8B312001A; Wed, 12 Feb 2020 15:36:06 -0800 (PST) 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, 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 uJnznKc9vV7C; Wed, 12 Feb 2020 15:36:05 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1D63E120045; Wed, 12 Feb 2020 15:36:05 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 046961E2F6; Wed, 12 Feb 2020 18:41:36 -0500 (EST) Date: Wed, 12 Feb 2020 18:41:36 -0500 From: Jeffrey Haas To: draft-ietf-idr-rfc5575bis@ietf.org, idr@ietf.org Message-ID: <20200212234136.GC32507@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: [Idr] 5575bis nit - ASes in extended communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Feb 2020 23:36:07 -0000 In RFC 5575 and 5575-bis, we have several extended communities defined. : +-----------+----------------------+--------------------------------+ : | community | action | encoding | : +-----------+----------------------+--------------------------------+ : | 0x8006 | traffic-rate-bytes | 2-byte ASN, 4-byte float | : | TBD | traffic-rate-packets | 2-byte ASN, 4-byte float | : | 0x8007 | traffic-action | bitmask | : | 0x8008 | rt-redirect AS-2byte | 2-octet AS, 4-octet value | : | 0x8108 | rt-redirect IPv4 | 4-octet IPv4 addres, 2-octet | : | | | value | : | 0x8208 | rt-redirect AS-4byte | 4-octet AS, 2-octet value | : | 0x8009 | traffic-marking | DSCP value | : +-----------+----------------------+--------------------------------+ : : Table 2: Traffic Action Extended Communities Nits: We use byte in some spots for AS, octet in others. "addres" is a typo. A question came up from a customer, else I would have let this question lay idle: When you're running flowspec within a BGP Confederation (RFC 5065), whose AS do you stick in there? The Member-AS, or the AS Confederation Identifier? I could make a few weak arguments that the Member-AS makes sense. (And, is in fact, what Juniper's code currently does.) However, I think the general intent is such that consistent action within the Confederation is what is desired, similar to what it'd be like if the behavior is iBGP. While the AS number is largely an advisory number for the features in question, it does potentially have impact on policy. My recommendation would be we add some text roughly like the following: Add "In the circumstance that this specification is utilized in a BGP Confederation [RFC 5065], AS Numbers used by these Traffic Action Extended Communities SHOULD be the BGP speaker's Confederation Identifier AS." -- Jeff From nobody Thu Feb 13 03:49:23 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287041200EF; Thu, 13 Feb 2020 03:49:22 -0800 (PST) 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, 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 H1RKM3Cg71e6; Thu, 13 Feb 2020 03:49:20 -0800 (PST) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id AD6DF120013; Thu, 13 Feb 2020 03:49:20 -0800 (PST) Received: by slice.pfrc.org (Postfix, from userid 1001) id 4C21F1E2F7; Thu, 13 Feb 2020 06:54:52 -0500 (EST) Date: Thu, 13 Feb 2020 06:54:51 -0500 From: Jeffrey Haas To: draft-ietf-idr-rfc5575bis@ietf.org, idr@ietf.org Message-ID: <20200213115451.GD32507@pfrc.org> References: <20200212234136.GC32507@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200212234136.GC32507@pfrc.org> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Idr] 5575bis nit - ASes in extended communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 11:49:22 -0000 On Wed, Feb 12, 2020 at 06:41:36PM -0500, Jeffrey Haas wrote: > In RFC 5575 and 5575-bis, we have several extended communities defined. > > : +-----------+----------------------+--------------------------------+ > : | community | action | encoding | > : +-----------+----------------------+--------------------------------+ > : | 0x8006 | traffic-rate-bytes | 2-byte ASN, 4-byte float | > : | TBD | traffic-rate-packets | 2-byte ASN, 4-byte float | > : | 0x8007 | traffic-action | bitmask | > : | 0x8008 | rt-redirect AS-2byte | 2-octet AS, 4-octet value | > : | 0x8108 | rt-redirect IPv4 | 4-octet IPv4 addres, 2-octet | > : | | | value | > : | 0x8208 | rt-redirect AS-4byte | 4-octet AS, 2-octet value | > : | 0x8009 | traffic-marking | DSCP value | > : +-----------+----------------------+--------------------------------+ > : > : Table 2: Traffic Action Extended Communities > [...] > While the AS number is largely an advisory number for the features in > question, it does potentially have impact on policy. > > My recommendation would be we add some text roughly like the following: > Add "In the circumstance that this specification is utilized in a BGP > Confederation [RFC 5065], AS Numbers used by these Traffic Action Extended > Communities SHOULD be the BGP speaker's Confederation Identifier AS." Thinking slightly further, the text should be: "In the circumstance that this specification is utilized in a BGP Confederation [RFC 5065], AS Numbers used by the Traffic Rate Extended Communities SHOULD be the BGP speaker's Confederation Identifier AS." The AS numbers for redirect are provisioned from VRF import policy and wouldn't be touched. -- Jeff From nobody Thu Feb 13 05:24:09 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63B61200F7; Thu, 13 Feb 2020 05:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 umv8dwlJYJ2b; Thu, 13 Feb 2020 05:24:04 -0800 (PST) Received: from mail.hated.at (mail.hated.at [IPv6:2001:858:2:8::235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D69F1200F8; Thu, 13 Feb 2020 05:24:04 -0800 (PST) Received: from 80-110-104-164.cgn.dynamic.surfer.at ([80.110.104.164] helo=[192.168.66.207]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1j2ETJ-0004bc-2V; Thu, 13 Feb 2020 14:24:01 +0100 From: Christoph Loibl Message-Id: <36B17AE5-3405-4284-ADF6-D599B4F9C6F4@tix.at> Content-Type: multipart/alternative; boundary="Apple-Mail=_93E98559-6877-4544-AE95-ABEAA2E1982A" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) Date: Thu, 13 Feb 2020 14:24:00 +0100 In-Reply-To: <20200212234136.GC32507@pfrc.org> Cc: draft-ietf-idr-rfc5575bis@ietf.org, idr@ietf.org To: Jeffrey Haas References: <20200212234136.GC32507@pfrc.org> X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Idr] 5575bis nit - ASes in extended communities X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 13:24:08 -0000 --Apple-Mail=_93E98559-6877-4544-AE95-ABEAA2E1982A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Jeff, I opened 2 issues for tracking that (also including your thoughts from = the second mail) on github: https://github.com/stoffi92/rfc5575bis/issues/160 = https://github.com/stoffi92/rfc5575bis/issues/161 = I came across the second issue a while back when I was writing import = policies and saw what juniper does (thanks for sharing the details), but = I haven=E2=80=99t checked what other implementations actually put there. Cheers Christoph --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > On 13.02.2020, at 00:41, Jeffrey Haas wrote: >=20 > In RFC 5575 and 5575-bis, we have several extended communities = defined. >=20 > : = +-----------+----------------------+--------------------------------+ > : | community | action | encoding = | > : = +-----------+----------------------+--------------------------------+ > : | 0x8006 | traffic-rate-bytes | 2-byte ASN, 4-byte float = | > : | TBD | traffic-rate-packets | 2-byte ASN, 4-byte float = | > : | 0x8007 | traffic-action | bitmask = | > : | 0x8008 | rt-redirect AS-2byte | 2-octet AS, 4-octet value = | > : | 0x8108 | rt-redirect IPv4 | 4-octet IPv4 addres, 2-octet = | > : | | | value = | > : | 0x8208 | rt-redirect AS-4byte | 4-octet AS, 2-octet value = | > : | 0x8009 | traffic-marking | DSCP value = | > : = +-----------+----------------------+--------------------------------+ > :=20 > : Table 2: Traffic Action Extended Communities >=20 > Nits: We use byte in some spots for AS, octet in others. "addres" is = a > typo. >=20 > A question came up from a customer, else I would have let this = question > lay idle: When you're running flowspec within a BGP Confederation = (RFC 5065), > whose AS do you stick in there? The Member-AS, or the AS = Confederation > Identifier? >=20 > I could make a few weak arguments that the Member-AS makes sense. = (And, is > in fact, what Juniper's code currently does.) However, I think the = general > intent is such that consistent action within the Confederation is what = is > desired, similar to what it'd be like if the behavior is iBGP. >=20 > While the AS number is largely an advisory number for the features in > question, it does potentially have impact on policy. >=20 > My recommendation would be we add some text roughly like the = following: > Add "In the circumstance that this specification is utilized in a BGP > Confederation [RFC 5065], AS Numbers used by these Traffic Action = Extended > Communities SHOULD be the BGP speaker's Confederation Identifier AS." >=20 > -- Jeff >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr --Apple-Mail=_93E98559-6877-4544-AE95-ABEAA2E1982A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Jeff,

I opened 2 = issues for tracking that (also including your thoughts from the second = mail) on github:

https://github.com/stoffi92/rfc5575bis/issues/160

https://github.com/stoffi92/rfc5575bis/issues/161

I came across the = second issue a while back when I was writing import policies and saw = what juniper does (thanks for sharing the details), but I haven=E2=80=99t = checked what other implementations actually put there.

Cheers

Christoph

-- 
Christoph = Loibl
c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 = | http://www.nextlayer.at



On 13.02.2020, at 00:41, Jeffrey Haas <jhaas@pfrc.org> = wrote:

In RFC 5575 and 5575-bis, we have several extended = communities defined.

: =    +-----------+----------------------+--------------------= ------------+
:    | community | action =             &n= bsp; | encoding =             &n= bsp;         |
: =    +-----------+----------------------+--------------------= ------------+
:    | 0x8006 =    | traffic-rate-bytes   | 2-byte ASN, 4-byte = float       |
: =    | TBD       | = traffic-rate-packets | 2-byte ASN, 4-byte float =       |
: =    | 0x8007    | traffic-action =       | bitmask =             &n= bsp;          |
:    | 0x8008    | rt-redirect = AS-2byte | 2-octet AS, 4-octet value      |
:    | 0x8108    | rt-redirect = IPv4     | 4-octet IPv4 addres, 2-octet =   |
:    | =           | =             &n= bsp;        | value =             &n= bsp;           &nbs= p;|
:    | 0x8208    | = rt-redirect AS-4byte | 4-octet AS, 2-octet value =      |
:    | = 0x8009    | traffic-marking =      | DSCP value =             &n= bsp;       |
: =    +-----------+----------------------+--------------------= ------------+
:
: =             &n= bsp;  Table 2: Traffic Action Extended Communities

Nits: We use byte in some spots for AS, octet = in others.  "addres" is a
typo.

A question came up from a customer, else I would have let = this question
lay idle:  When you're running flowspec = within a BGP Confederation (RFC 5065),
whose AS do you = stick in there?  The Member-AS, or the AS Confederation
Identifier?

I could make a few = weak arguments that the Member-AS makes sense. (And, is
in = fact, what Juniper's code currently does.)  However, I think the = general
intent is such that consistent action within the = Confederation is what is
desired, similar to what it'd be = like if the behavior is iBGP.

While the AS = number is largely an advisory number for the features in
question, it does potentially have impact on policy.

My recommendation would be we add some text = roughly like the following:
Add "In the circumstance that = this specification is utilized in a BGP
Confederation [RFC = 5065], AS Numbers used by these Traffic Action Extended
Communities SHOULD be the BGP speaker's Confederation = Identifier AS."

-- Jeff

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

= --Apple-Mail=_93E98559-6877-4544-AE95-ABEAA2E1982A-- From nobody Thu Feb 13 10:08:27 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2511201A3; Thu, 13 Feb 2020 10:08:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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=BkodmExI; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=fYDFybG3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H6XlqEfmrblm; Thu, 13 Feb 2020 10:08:23 -0800 (PST) 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 E747A1200B8; Thu, 13 Feb 2020 10:08:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3399; q=dns/txt; s=iport; t=1581617302; x=1582826902; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=IUN0jGUrHraHrmlAjsPRXdKw1lZpp4FzwgRu9qNbk1g=; b=BkodmExIsNMO21aQ3lXWxRXcA2TgL3I2gEroFWRsL0RlXAre6ye+e4/7 iahMAb8U4xosukXRxtbRdTQM+olDvLEGXpQC0p/1ToMflw+bKmx7/iHZW XUYKBrAHKKznUFaU1mr+cgze1iw4kEbbu5dCsTbJ9szPqVF3ByR3DbYSP U=; IronPort-PHdr: =?us-ascii?q?9a23=3AZYPynxM4+YI1frJ+rMMl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEuKQ/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj4IeLjaTASF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CMDAA0j0Ve/5JdJa1cChwBAQEBAQc?= =?us-ascii?q?BAREBBAQBAYF7gVQkLAVsWCAECyoKh1ADindOghGYEYJSA1QJAQEBDAEBIwo?= =?us-ascii?q?CBAEBhEACgkwkOBMCAw0BAQUBAQECAQUEbYU3DIVmAQEBAQMSKAYBATgLBAI?= =?us-ascii?q?BCA4DBAEBHxAyHQgCBAESCBqDBYJKAy4BDqIXAoE5iGKCJ4J/AQEFhR8Yggw?= =?us-ascii?q?DBoE4jCQagUE/gRFHgkw+gmQBAQIBgTUFKoNAgiyWZZgfdgqCOodNjyCbF45?= =?us-ascii?q?oiG6SPwIEAgQFAg4BAQWBaSKBWHAVgydQGA2OHQkag1CFFIU/dAIBgSaLNoE?= =?us-ascii?q?yAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.70,437,1574121600"; d="scan'208";a="725449245" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 13 Feb 2020 18:08:21 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 01DI8L9h012012 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 13 Feb 2020 18:08:21 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 13 Feb 2020 12:08:21 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 13 Feb 2020 13:08:20 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 13 Feb 2020 12:08:19 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h+uwcPvhYSV8ygPPBKWZKqHUVDy5r0dVxyC7ubAIP3wA3T+btf1+sx2EPd3tS9+fT/51KNacKGYOlvx2rhWiaB0AHS4HWcdyQaCLwLse6rv9VWmnbCsEXMxwm1uMSe4LRvaN674Z9pDg0viEQu3I3/lXMn/VRjwJiZOCpy1qHdJ5IfNY43ANlFWX+mISbaziFPpy0dtFDvnOtNtQNaztCA+M1vr8WD62A+WBh71vcMonwG8RriRApo5FBs3mYEdKkcgQTId7dmh4DU2bvDdqqRnIrytXuGx8ONrOPX5lJ6qS8BCqbPn3I9yAZ5vf1J/AxP9jmHri/eIcvjeRKVhzoQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o5e8eP/pmY9gaQlKGgM24HR0QVAlC9qyOirageIuP74=; b=KrZPxSSqOatue5hiINLBZdeHPitYVo+Vsy1Xojg+nNF2N+M5sUZ7m76GmQUcCz4gXvvx1bXfDCWSejo5PfmiimFVfX5ZmXDNkoYJqg3oRIGpUpMSnvV0+8eIMf04Lo/Tc3N473a8vmONQjc11ItGZoyEO2GnF00KNbEX/jHbxCJaj7p35z95MaN4x5h0UOg6oVV5nWwkSHn5SHdAXBtP68PVlKM0oHsdXIH6gdszHc1EgIKy8fLo/FtmIuIbQM/gaHbaR6JCz7yYiFccBW9EftIkgc4TzAINOfM2NNDVTRmeq+kLdOeXrFnfKKqLPbzn8HajMDCr9SQD6zbuwrGN6A== 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=o5e8eP/pmY9gaQlKGgM24HR0QVAlC9qyOirageIuP74=; b=fYDFybG3mT4TAQ3kdQS5miGIJlapP4JUJquhG3IoHea/ly5ee/Xcvi/YWEhmWfea/+DV7n9ZymbYA4fVvPkgC49qW4LhwTjVMmg4bGG4O+cFy/EJCrAL2GBjddT3km3qOukB1JkRJxORgHldDJb9uFYQ3okID9PqnArBUW2RS24= Received: from CY4PR11MB1589.namprd11.prod.outlook.com (10.172.71.13) by CY4PR11MB1816.namprd11.prod.outlook.com (10.175.63.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2729.23; Thu, 13 Feb 2020 18:08:19 +0000 Received: from CY4PR11MB1589.namprd11.prod.outlook.com ([fe80::140e:e5e7:62e5:2a4c]) by CY4PR11MB1589.namprd11.prod.outlook.com ([fe80::140e:e5e7:62e5:2a4c%6]) with mapi id 15.20.2729.025; Thu, 13 Feb 2020 18:08:19 +0000 From: "Ketan Talaulikar (ketant)" To: Jeffrey Haas , "draft-ietf-idr-segment-routing-te-policy@ietf.org" , "idr@ietf.org" Thread-Topic: draft-ietf-idr-segment-routing-te-policy Policy Name Sub-TLV considerations Thread-Index: AQHV4fnX9GqjNaH+OECMSUudeTzukagZZg2A Date: Thu, 13 Feb 2020 18:08:18 +0000 Message-ID: References: <20200212231711.GB32507@pfrc.org> In-Reply-To: <20200212231711.GB32507@pfrc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ketant@cisco.com; x-originating-ip: [128.107.241.187] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5825ef8f-9dd8-4946-ad0f-08d7b0afb484 x-ms-traffictypediagnostic: CY4PR11MB1816: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 031257FE13 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(346002)(396003)(376002)(366004)(39860400002)(199004)(189003)(52536014)(316002)(26005)(2906002)(186003)(7696005)(5660300002)(66446008)(966005)(64756008)(53546011)(6506007)(110136005)(478600001)(66476007)(71200400001)(33656002)(66946007)(76116006)(66556008)(86362001)(81166006)(81156014)(8676002)(8936002)(9686003)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR11MB1816; H:CY4PR11MB1589.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 83mHLhQbOXau6Je0E1jp9okDmIsTezF2dPUUww6ht7on2pOmVe5JZ9ov2P1LOuu4tP2Y6+c3wNi31ZAsxWSH76dS6TS1+rlRbnhyM/5cGBz8L3JstVhfzc4ARu2oBUctxWziAk7gMGBWUx++8AUQ1ADEBcz8mcmi+iWnseX48avBrEGWvLgu2WHTkoZK8+XGZUebVH9PMNd1AWHKdXhaxZ5XJ44Tel55LsBNHWXJODe5239EpsdCD8/fFIDphoEdfvPcoo52UeLgn0uDHC3Ql3UiWk4eOlTlRx7blw8zNvnXGoBMRGC0+39YFo3fDb163egYUnlYFIykkb606n/pyOnC9PKyT8wYORCBENZNy+SRjkTdBay3xDlZZHI4PDoh73mk9/X3wmDAZol1PK5T97xy6LAMI/R34rxQv3AGHHgPDw27Cf+GCF5e9X+tcA0y8F7iMQuU1eAnosdjYrR8GOhTJQocsIBPnZRqR0X9S+cxcbBNIwGT/R/RB/hSWR9KcjeRwqsYOEa+dM5CU3GvYA== x-ms-exchange-antispam-messagedata: PNZ41JkW1vNm5dCGM4imNPIY7/z9Fl2NYM/K63e/+G/gmMGA5l+VCezD4J8aBH3Q1E5hlZPmw41KZemaxeXAteOBOd8mcB9WcWgZTtZXX+gB9QorYToHBJJBYJfMgG35wsJPTwGMCpdFwPKPfA2btA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5825ef8f-9dd8-4946-ad0f-08d7b0afb484 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2020 18:08:18.4446 (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: 5AMkOeZ8v2Dh6ywws4L/TXQEF6pJTo88VubI0fTiVfOegkffUmDsAdF28hgEePvJkRSp4K8OEjgNkG7W/glndA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1816 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-10.cisco.com Archived-At: Subject: Re: [Idr] draft-ietf-idr-segment-routing-te-policy Policy Name Sub-TLV considerations X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2020 18:08:25 -0000 Hi Jeff, I agree with you about the limits on the policy name size.=20 I am not aware of any IETF standard that mandates the use of UTF-8 for enco= ding of string for names. The similar object in PCEP is encoded in ASCII - = https://tools.ietf.org/html/rfc8231#section-7.3.2=20 Thanks, Ketan -----Original Message----- From: Jeffrey Haas =20 Sent: 12 February 2020 15:17 To: draft-ietf-idr-segment-routing-te-policy@ietf.org; idr@ietf.org Subject: draft-ietf-idr-segment-routing-te-policy Policy Name Sub-TLV consi= derations Authors, In draft-ietf-idr-segment-routing-te-policy-08, Section 2.4.6 we have a TLV= for Policy Name. Its text is: : 2.4.6. Policy Name Sub-TLV :=20 : An operator MAY set the Policy Name sub-TLV to attach a symbolic name : to the SR Policy candidate path. :=20 : Usage of Policy Name sub-TLV is described in section 2 in : [I-D.ietf-spring-segment-routing-policy]. :=20 : The Policy Name sub-TLV may exceed 255 bytes length due to long : policy name. Therefore a 2-octet length is required. According to : [I-D.ietf-idr-tunnel-encaps], the first bit of the sub-TLV codepoint : defines the size of the length field. Therefore, for the Policy Name : sub-TLV a code point of 128 or higher is used. :=20 : The Policy Name sub-TLV is optional and it MUST NOT appear more than : once in the SR Policy TLV. :=20 : The Policy Name sub-TLV has following format: :=20 : 0 1 2 3 : 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : | Type | Length | RESERVED | : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : // Policy Name // : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ :=20 : Where: :=20 : Type: 129. :=20 : Length: Variable. :=20 : RESERVED: 1 octet of reserved bits. SHOULD be set to zero on : transmission and MUST be ignored on receipt. :=20 : Policy Name: Symbolic name for the policy. It SHOULD be a string : of printable ASCII characters, without a NULL terminator. draft-ietf-spring-segment-routing-policy-06, Section 2.1 discusses this Sub-TLV: : An implementation MAY allow assignment of a symbolic name comprising : of printable ASCII characters to an SR Policy to serve as a user- : friendly attribute for debug and troubleshooting purposes. Such : symbolic names may identify an SR Policy when the naming scheme : ensures uniqueness. There are two observations I'd like to make: 1. A 65K length isn't very likely in BGP. :-) I suggest that greater guida= nce for shorter names should be offered. For example, perhaps limit the len= gth to 1K. Alternatively, offer advice such as: "Implementations may choos= e to truncate long Policy Names". 2. The guidance about "printable ASCII" is rather old-style and likely to r= un askance of IESG review for internationalization considerations. I'd sug= gest that the field be encoded in UTF-8 and make reference to print-safety = similar to RFC 8203 (BGP Administrative Shutdown) in its Security Considera= tions. -- Jeff From nobody Fri Feb 14 05:47:44 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F85120041 for ; Fri, 14 Feb 2020 05:47:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9mmuBDrE4PGE for ; Fri, 14 Feb 2020 05:47:38 -0800 (PST) Received: from mail.benocs.com (mx-01.benocs.com [91.102.13.130]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E5F9120074 for ; Fri, 14 Feb 2020 05:47:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.benocs.com (Postfix) with ESMTP id D7AB264E8DA; Fri, 14 Feb 2020 14:41:00 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at benocs.com Received: from mail.benocs.com ([127.0.0.1]) by localhost (mail.benocs.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szfWLsJuY50C; Fri, 14 Feb 2020 14:40:58 +0100 (CET) Received: from [192.168.78.138] (ip-95-223-72-134.hsi16.unitymediagroup.de [95.223.72.134]) by mail.benocs.com (Postfix) with ESMTPSA id C96E864E6A2 for ; Fri, 14 Feb 2020 14:40:58 +0100 (CET) Reply-To: deniz.bahadir@benocs.com From: Deniz Bahadir Organization: BENOCS GmbH To: idr@ietf.org Message-ID: <84569374-e908-2a3d-07f9-8b4560364cf0@benocs.com> Date: Fri, 14 Feb 2020 14:47:32 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [Idr] May a single UPDATE message carry multiple different AFI/SAFI combinations? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Feb 2020 13:47:42 -0000 Hi everyone, I have a question which is probably easy to answer for you experts but I am struggling to find the RFCs which completely answer it. The question reads: Can a single BGP UPDATE message carry NLRI with different AFI/SAFI combinations (and still be valid)? On the search for an answer I found some RFCs that partially answer it but not entirely and which made me come up with even more questions... RFC 7606 ("Revised Error Handling for BGP UPDATE Messages") states in section 3 g): ``` If the MP_REACH_NLRI attribute or the MP_UNREACH_NLRI [RFC4760] attribute appears more than once in the UPDATE message, then a NOTIFICATION message MUST be sent with the Error Subcode "Malformed Attribute List". [...] ``` This clearly states that multiple MP_REACH_NLRI in a single UPDATE message are not allowed and so only one explicit AFI/SAFI combination can be carried in an UPDATE message which advertises new routes. Similar, it states that multiple MP_UNREACH_NLRI are not allowed in a single UPDATE message and therefore only one explicit AFI/SAFI combination can be carried in an UPDATE message which are advertised as withdrawn. However, it leaves me wondering if a) a single UPDATE message may carry an MP_REACH_NLRI as well as an MP_UNREACH_NLRI and b) if these may then carry different AFI/SAFI combinations? Additionally, this section does not say anything about the traditional fields of an UPDATE message (which carry implicit AFI/SAFI combination of IPv4/unicast): May these carry (added or withdrawn) NLRI in the presence of MP_REACH_NLRI or MP_UNREACH_NLRI? And may the MP_REACH_NLRI (or MP_UNREACH_NLRI) then carry other AFI/SAFI than IPv4/Unicast? RFC 4760 ("Multiprotocol Extensions for BGP-4") says in section 3: ``` An UPDATE message that carries no NLRI, other than the one encoded in the MP_REACH_NLRI attribute, SHOULD NOT carry the NEXT_HOP attribute. If such a message contains the NEXT_HOP attribute, the BGP speaker that receives the message SHOULD ignore this attribute. ``` This seems to imply that a single UPDATE message _can_ carry an MP_REACH_NLRI for a specific AFI/SAFI combination as well as IPv4/unicast NLRI using the traditional UPDATE fields described in RFC 4271. Is this really the intention and therefore allowed? So, my original question pretty much unfolds into the following questions: - May in the presence of MP_REACH_NLRI (or MP_UNREACH_NLRI) the traditional fields of an UPDATE message carry NLRI (or withdrawn NLRI), too? - Does any RFC explicitly say whether that is allowed or not? - Or might this only be allowed if the MP_REACH_NLRI (or MP_UNREACH_NLRI) contains the same AFI/SAFI combination of IPv4/unicast? - What do the different existing implementations for BGP do? What do they accept in receiving UPDATE messages? - Is carrying both, added as well as withdrawn NLRI (either using the traditional fields or with MP_REACH_NLRI and MP_UNREACH_NLRI) in a single UPDATE message still allowed? - Does any implementation still do this? While writing this e-mail the questions became more and more. I hope that some of you can still help me answering these. Thanks in advance, Deniz Bahadir -- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Reuchlinstr. 10 D 10553 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: deniz.bahadir@benocs.com www.benocs.com Board of Management: Stephan Schröder, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378 From nobody Tue Feb 18 01:46:23 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24F6120129 for ; Tue, 18 Feb 2020 01:46:13 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 uNNVN7-NjCCb for ; Tue, 18 Feb 2020 01:46:11 -0800 (PST) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 F321412012A for ; Tue, 18 Feb 2020 01:46:10 -0800 (PST) Received: by mail-ot1-x329.google.com with SMTP id w23so2492603otj.4 for ; Tue, 18 Feb 2020 01:46:10 -0800 (PST) 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; bh=rQTtxNUZCMf32gIlYmec3W8Lo+nhSzRSKegA6Y0MbTY=; b=IkOgUPbBjEfT0wUQsF/9CLU6ojKfQrtQwc+cKnxM+k4F/ZxYEgjtQGafS3D6G3ugiv VkpUaMFHzBlMaM6BSX/xynYCvb732io5zIriF4/OOiEZUCP3KVKrAdB6X44brASpm/EX 0n+mQ3qAt1IfgttCn2gWIBYUy4ws8jzmricuZDxnuU6aOy+jRsXhsJ31KFxa2jhCN5Za ZdzcXsG2veT3YMq9KZ8ipYVP9qmkWmB2gzgQKwOspa1DQTMArnAgtpRKn4AKnZs/qu8S ceTPV/fB61oSB3d29nRZTT3TouoKywRieP1SptdeKnB9q2X+KoaS7EcnEXR5Y13JtV4G CHpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=rQTtxNUZCMf32gIlYmec3W8Lo+nhSzRSKegA6Y0MbTY=; b=iMKQjCnAHUK2e9ESEm0ncpcIkJpx2QtJjHLx3sPExfuebjxa0tV2NkjBVncQiWapM5 BHBeJLufVbqWY1Tx4TfRuqxmOBDBoII12JgHQ39kQvZnFQ6rOHm3KTBZp3YyzgMhLFTU OPY/mWdJwEcq7VqR9V3syWAGTovPnFHCNc5USPWb9hcDwjgKxmk1ccc6DXnC709NtO9j 9OWlY9py4t0Ct1mNcYF59PcuMzqxJIIn2DGLDkm9KeT6+0xZqaizzkVbNklVKJ5nCCXb nQs9XgqAMNprhzvYH0d1fdeYlb14foKDNS1tHlEI9D0uUwKl1TC1IsHskQ9pF33+N3Je 3yWQ== X-Gm-Message-State: APjAAAX+8b5eXaKEr8FfiCnNo30SCEuPZnk4VwqsH0uAfYCw+vbEhATO CQwYz/UktWiuyY6SnFuBixDoXwuw3miEHYL9mQaofWe6RuE= X-Google-Smtp-Source: APXvYqyRCx5UCXjTOLhxdR7OokuO6favvVxhkWYnSCKA6p8Xu/5vtN636UQI0zYlCKjXi2/Jg6sIe5g+EHQ/fbVQ6rM= X-Received: by 2002:a9d:6a06:: with SMTP id g6mr13989229otn.305.1582019169867; Tue, 18 Feb 2020 01:46:09 -0800 (PST) MIME-Version: 1.0 References: <158201848456.14101.16035956666195497310@ietfa.amsl.com> In-Reply-To: <158201848456.14101.16035956666195497310@ietfa.amsl.com> From: Robert Raszuk Date: Tue, 18 Feb 2020 10:45:59 +0100 Message-ID: To: "idr@ietf. org" , SPRING WG Content-Type: multipart/alternative; boundary="000000000000a5eb53059ed68af2" Archived-At: Subject: [Idr] Fwd: I-D Action: draft-zhou-idr-inter-domain-lcu-01.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 09:46:14 -0000 --000000000000a5eb53059ed68af2 Content-Type: text/plain; charset="UTF-8" Dear Authors of "Inter-domain Network Slicing via BGP-LU" draft, Can you kindly elaborate why your ultimate goal can not be accomplished using SR-MPLS and flexible algorithm ? Is having N solutions to the same problem a good thing ? See writing a draft is easy, publishing it as RFC a bit harder but doable, but the real challenge is to support it in all products as well as struggle with interoperability issues between completely disjointed solutions. As to your proposal why is this a standards track vs information ? AFAIK you are not defining any BGP extension - just using add-paths and community. How receiver interprets the community is a local matter. Many thx, R. ---------- Forwarded message --------- From: Date: Tue, Feb 18, 2020 at 10:35 AM Subject: I-D Action: draft-zhou-idr-inter-domain-lcu-01.txt To: A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Inter-domain Network Slicing via BGP-LU Authors : Jin Zhou Chunning Dai Shaofu Peng Filename : draft-zhou-idr-inter-domain-lcu-01.txt Pages : 7 Date : 2020-02-18 Abstract: This document aims to solve inter-domain network slicing problems using existing technologies. It attempts to establish multiple BGP- LU LSPs of different colors for a prefix to stitch multiple network segments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-zhou-idr-inter-domain-lcu/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-zhou-idr-inter-domain-lcu-01 https://datatracker.ietf.org/doc/html/draft-zhou-idr-inter-domain-lcu-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-zhou-idr-inter-domain-lcu-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --000000000000a5eb53059ed68af2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Authors of=C2=A0=C2=A0"Inter-domain Network Slic= ing via BGP-LU" draft,

Can you kindly elaborate why= your ultimate goal can not be accomplished=C2=A0using SR-MPLS and flexible= algorithm ?=C2=A0

Is having N solutions to the sa= me problem a good thing ? See writing a draft is easy, publishing it as RFC= a bit harder but doable, but the real challenge=C2=A0is to support it in a= ll products as well as struggle with interoperability issues between comple= tely=C2=A0disjointed solutions.=C2=A0

As to your p= roposal why is this a standards track vs information ? AFAIK you are not de= fining any BGP extension - just using add-paths and community. How receiver= interprets the community is a local=C2=A0matter.=C2=A0

Many thx,
R.

---------- Forwarded message --= -------
From: <internet-drafts@ietf.org>
Date: Tue, Feb 18, 2020= at 10:35 AM
Subject: I-D Action: draft-zhou-idr-inter-domain-lcu-01.txt=
To: <i-d-announce@ietf.org= >



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


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Inter-domain Network Slicing via BGP-LU
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Jin = Zhou
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Chunning Dai
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Shaofu Peng
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-zho= u-idr-inter-domain-lcu-01.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 7
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2020-02-18

Abstract:
=C2=A0 =C2=A0This document aims to solve inter-domain network slicing probl= ems
=C2=A0 =C2=A0using existing technologies.=C2=A0 It attempts to establish mu= ltiple BGP-
=C2=A0 =C2=A0LU LSPs of different colors for a prefix to stitch multiple ne= twork
=C2=A0 =C2=A0segments.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/dr= aft-zhou-idr-inter-domain-lcu/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-zhou= -idr-inter-domain-lcu-01
https://datatracker.ietf.org= /doc/html/draft-zhou-idr-inter-domain-lcu-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?u= rl2=3Ddraft-zhou-idr-inter-domain-lcu-01


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce=
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
--000000000000a5eb53059ed68af2-- From nobody Tue Feb 18 14:37:19 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3BB120830; Tue, 18 Feb 2020 14:37:17 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 affi5WsTF9rC; Tue, 18 Feb 2020 14:37:15 -0800 (PST) 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 8764D120145; Tue, 18 Feb 2020 14:37:15 -0800 (PST) Received: by mail-ed1-x536.google.com with SMTP id r18so26732109edl.1; Tue, 18 Feb 2020 14:37:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=pBZlsfCtGL/iuEJJpgx5nIHZO1mTnPHULlbU6HweUVE=; b=Q6bHRWyVoipKnVM0D3Zx4md2AC+U6SYbbwjvDF4AMKcOTR0d3O/m/UKv8JC0QHZFhF XPyk1HpVjbmA0gGiQfsfdG0gSnynjQ9H/WKki9TJg2o+h2RmZFKSCdxUrl0LLj0oRczH BIgEdsexv8JVCBzjMPwTHNNzloia5vqxdU3KsBpPLcCMYmQ5p/rNtU3s8WuGHbS4aAtJ w1Y1HuI9epv52DE1xDGy+JMI4JTemy3keZMntOyxZ5KblaG81NfZ626PsnNcmTVu7XwF dI9GKye8qGA8Sx9qHA6NLcMb9n/m1r4OnzCKvXvD+7kd2pOR40bdNefATHk2AQ/H1EAp Cgpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=pBZlsfCtGL/iuEJJpgx5nIHZO1mTnPHULlbU6HweUVE=; b=JzovHX0YCFF6jtpaEvC4wMxxA7m37n6cqVy/njotrsU0keTBQn5h5G94oZmMkUbp1p jUXPHx6948sfUlpBcJREuN38pMxpFo43eeYRAiueyZzGcp62ZJDMWbo+OsqanVZipaSC yYb1j+nkk8+3OPWA0IlsxA7K6Uk1YAKxe/ij4/A70+Ju8VAYuURM4/KreXBf7Qll0004 r54XXR0B7C75t3z3xF/Hg0rHbkLRgXe5X1vNJDlDdI3OwgCVbXiVcr0nakzkicFExrR7 Wd//pJ1Pp8fq9McCLGSs5opkf+4JKao+bGFjpVmPRgSo7KDcFzr+O60lcbH+1FJpvQeX hMTw== X-Gm-Message-State: APjAAAX7wqui3CXIic/CVsneu1ObMBsab6goMS7QZB/3hGa+Tk3fChwY 8ri7djO3hbc0Y/IhdQmD8yR2yviUx5mZ4SO1FU4= X-Google-Smtp-Source: APXvYqzAAMrHV1Iu8VrH8LeWAK2vLsuuRnprjVi9PwNw86do9bJLj/HAtM6490U4uUznWBOyyH20iPlhRtEmfOGGvC4= X-Received: by 2002:aa7:c915:: with SMTP id b21mr21698723edt.174.1582065434077; Tue, 18 Feb 2020 14:37:14 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 18 Feb 2020 14:37:13 -0800 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Tue, 18 Feb 2020 14:37:13 -0800 Message-ID: To: "Ketan Talaulikar (ketant)" , "draft-ietf-idr-tunnel-encaps@ietf.org" Cc: idr wg , "draft-ietf-idr-segment-routing-te-policy@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Idr] Regarding Color Extended Communities Reserved bits (draft-ietf-idr-tunnel-encaps) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Feb 2020 22:37:18 -0000 On November 14, 2019 at 3:28:51 AM, Ketan Talaulikar wrote: Ketan: Hi! I'm in the process of reviewing draft-ietf-idr-tunnel-encaps, so I ran into this message. > The Color Extended Communities is specified in > https://tools.ietf.org/html/draft-ietf-idr-tunnel-encaps-14#section-4.3 a= nd > in it we have a RESERVED field. Now two bits in this field are specified = by > https://tools.ietf.org/html/draft-ietf-idr-segment-routing-te-policy-07#s= ection- > 3. However, we don't have an IANA registry for this field/bits and neithe= r is > one requested by either of these drafts. > > I am wondering in which draft we should make the IANA request for this fi= eld > and if done in the BGP SRTE draft, would it end up updating the Tunnel En= caps > draft? > > Any suggestion on how to proceed with this? With so many other drafts > leveraging tunnel encaps, my concern is that we should not end up with a > collision. I would prefer it if this registry was defined in draft-ietf-idr-tunnel-encaps. =C2=A0I'll add a note in my review about it. Thanks!! Alvaro. From nobody Thu Feb 20 00:42:30 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C22DA120855; Thu, 20 Feb 2020 00:42:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 fpP7M6pz0qKy; Thu, 20 Feb 2020 00:42:16 -0800 (PST) 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 65E2B120850; Thu, 20 Feb 2020 00:42:13 -0800 (PST) Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id C13D273AAA4E7AA6351D; Thu, 20 Feb 2020 16:42:09 +0800 (CST) Received: from mse-fl2.zte.com.cn (unknown [10.30.14.239]) by Forcepoint Email with ESMTPS id A3A44C9406E568089245; Thu, 20 Feb 2020 16:42:09 +0800 (CST) Received: from kjyxapp01.zte.com.cn ([10.30.12.200]) by mse-fl2.zte.com.cn with SMTP id 01K8dHNl009121; Thu, 20 Feb 2020 16:41:45 +0800 (GMT-8) (envelope-from zhou.jin6@zte.com.cn) Received: from mapi (kjyxapp05[null]) by mapi (Zmail) with MAPI id mid14; Thu, 20 Feb 2020 16:41:44 +0800 (CST) Date: Thu, 20 Feb 2020 16:41:44 +0800 (CST) X-Zmail-TransId: 2b075e4e4648fc1ddd6d X-Mailer: Zmail v1.0 Message-ID: <202002201641448239938@zte.com.cn> In-Reply-To: References: mailman.95.1582056020.16172.idr@ietf.org Mime-Version: 1.0 From: To: Cc: , , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse-fl2.zte.com.cn 01K8dHNl009121 Archived-At: Subject: Re: [Idr] =?utf-8?q?Fwd=3A_I-D_Action=3A_draft-zhou-idr-inter-domain?= =?utf-8?q?-lcu-01=2Etxt?= X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2020 08:42:21 -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 RGVhciBSb2JlcnQsDQoNCg0KDQoNCg0KDQoNCg0KDQpGaXJzdGx5LCB3ZSBzdHJvbmdseSBhZ3Jl ZSB0aGF0IHRoZSBTUi1NUExTICYgRkEgc29sdXRpb24gY2FuIGFjaGlldmUgdGhlIHVsdGltYXRl IGdvYWwuIEFjY29yZGluZyB0byBvdXIgdW5kZXJzdGFuZGluZywgZm9yIGFuIEUyRSBpbnRlci1k b21haW4gU1IgcG9saWN5LCBjb2xvciBpcyB1c2VkIHRvIGRlZmluZSB0aGUgY29ycmVzcG9uZGlu ZyBURSBwdXJwb3NlLiBUaGUgY29udHJvbGxlciBjYW4gY2VudHJhbGx5IGNhbGN1bGF0ZSB0aGUg RTJFIHBhdGggdGhhdCBtZWV0cyB0aGUgVEUgcHVycG9zZS4gVGhlbiBmb3IgdGhlIHNlZ21lbnQg bGlzdCBpbiBlYWNoIGRvbWFpbiwgRkEgY2FuIGJlIHVzZWQgZm9yIHN0YWNrIGRlcHRoIG9wdGlt aXphdGlvbi4gSW4gYWRkaXRpb24sIHRoZSBjb250cm9sbGVyIGNhbiBhbHNvIHNlbGVjdCBpbnRl ci1kb21haW4gbGluayByZXNvdXJjZXMgYWNjb3JkaW5nIHRvIHRoZSBURSBwdXJwb3NlLiBOb3Rl IHRoYXQsIGFsdGhvdWdoIEZBIHVzZXMgZGlzdHJpYnV0ZWQgQ1NQRiwgdGhlIGVudGlyZSBFMkUg U1IgcG9saWN5IGlzIGNhbGN1bGF0ZWQgY2VudHJhbGx5Lg0KDQoNCg0KDQpUaGlzIGRyYWZ0IGRp c2N1c3NlcyBob3cgdG8gdXNlIEJHUC1MVSB0byBjYWxjdWxhdGUgYW4gRTJFIGludGVyLUFTIExV IExTUCBpbiBhIGRpc3RyaWJ1dGVkIG1hbm5lciwgd2hpY2ggaXMgZGlmZmVyZW50IGZyb20gdGhl IGFib3ZlIHNjaGVtZS4gVGhlIHVuZGVybGF5IHBhdGggaW5zaWRlIGVhY2ggZG9tYWluIChzdWNo IGFzIHRoZSBTUi1GQSwgU1ItVEUgdHVubmVsLCBTUiBwb2xpY3kgaW4gdGhlIGRvbWFpbikgd2ls bCBiZSBpdGVyYXRlZCBiYXNlZCBvbiB0aGUgQkdQLUxVIGNvbG9yIHBsdXMgbmV4dC1ob3AuVGhl IGxpbmsgcmVzb3VyY2VzIGJldHdlZW4gdGhlIGRvbWFpbnMgd2lsbCBhbHNvIGJlIHNlbGVjdGVk IGJhc2VkIG9uIHRoZSBCR1AtTFUgY29sb3IuIFRoZXNlIGFyZSBhbGwgZG9uZSBieSB0aGUgZXF1 aXBtZW50IGl0c2VsZi4NCg0KDQoNCg0KV2UgdGhpbmsgdGhhdCBib3RoIHNvbHV0aW9ucyBjYW4g Y29leGlzdCwgZWFjaCB3aXRoIGl0cyBvd24gYXBwbGljYXRpb24gc2NlbmFyaW8uIFRoaXMgZHJh ZnQgaXMgbWFpbmx5IHVzZWQgZm9yIHNlYW1sZXNzIE1QTFMgSVBSQU4gbmV0d29ya3MgY29uZmln dXJlZCB3aXRoIEJHUC1MVS4gU29tZSBzZXJ2aWNlcyB3aWxsIGJlIGNhcnJpZWQgdXNpbmcgRTJF IFNSIHBvbGljeSwgYnV0IHNvbWUgb3RoZXIgc2VydmljZSB3aWxsIGJlIGNhcnJpZWQgdXNpbmcg RTJFIEJHUC1MVSBMU1AuDQoNCg0KDQoNClRoZSBleGlzdGVkIEJHUCBtZWNoYW5pc20gaXMgZW5v dWdoIHRvIGFjaGlldmUgdGhlIGdvYWwsIGFuZCB3ZSBkb24ndCB0aGluayBleHRyYSBleHRlbnNp b25zIGFyZSBuZWNlc3NhcnkuICBBZG1pdHRlZGx5LCBhcyB1IHNhaWQsIGl0J3MgcmVhbGx5IGEg bG9jYWwgc3RyYXRlZ3kuIEFTQlIgZGV0ZXJtaW5lcyB3aGV0aGVyIHRvIGFkdmVydGlzZSBtdWx0 aXBhdGhzIGJhc2VkIG9uIDxwcmVmaXgsIGNvbG9yPiwgd2hldGhlciB0byBnZW5lcmF0ZSBsYWJl bCBzd2l0Y2hpbmcgZW50cmllcyBiYXNlZCBvbiA8cHJlZml4LCBjb2xvcj4sIGFuZCB3aGV0aGVy IHRvIGdlbmVyYXRlIEJHUC1MU1AgZW50cmllcyBiYXNlZCBvbiA8cHJlZml4LCBjb2xvcj4uICBU aGVzZSBsb2NhbCBkZXRlcm1pbmF0aW9ucyBoYXZlIGltcGxlbWV0ZWQgaW4gb3VyIHByb2R1Y3Qu IA0KDQoNCg0KDQpUaGFua3MgZm9yIHlvdXIgYXR0ZW50aW9uIGFuZCBhZHZpY2UuIA0KDQoNCg0K DQpKaW4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCuWRqOeRviBKaW4gWmhvdQ0KDQoN Cg0KDQoNCg0K5oqA5pyv6aKE56CU5bel56iL5biIIFRlY2hub2xvZ3kgUHJlLXJlc2VhcmNoIEVu Z2luZWVyDQrmnrbmnoTlm6LpmJ8v5pyJ57q/6KeE5YiS6YOoL+aciee6v+S6p+WTgee7j+iQpemD qCBBcmNoaXRlY3R1cmUgVGVhbS9XaXJlbGluZSBQcm9kdWN0IFBsYW5uaW5nIERpdmlzaW9uDQoN Cg0KDQoNCg0KDQoNCg0KDQozMy9GLCBSJkQgQnVpbGRpbmcsIFpURQpDb3Jwb3JhdGlvbiBIaS10 ZWNoIFJvYWQgU291dGgsIA0KSGktdGVjaApJbmR1c3RyaWFsIFBhcmsgTmFuc2hhbiBEaXN0cmlj dCwgU2hlbnpoZW4sIFAuLlIuQ2hpbmEsIDUxODA1NyANClQ6ICs4NiA3NTUgeHh4eHh4eHggRjor ODYgNzU1IHh4eHh4eHh4IA0KTTogKzg2IDE4NTc1NTY1MTM1DQpFOiB6aG91LmppbjZAenRlLmNv bS5jbiANCnd3dy56dGUuY29tLmNuDQoNCg0KDQoNCuWOn+Wni+mCruS7tg0KDQoNCg0K5Y+R5Lu2 5Lq677yaaWRyLXJlcXVlc3RAaWV0Zi5vcmcgPGlkci1yZXF1ZXN0QGlldGYub3JnPg0K5pS25Lu2 5Lq677yaaWRyQGlldGYub3JnIDxpZHJAaWV0Zi5vcmc+Ow0K5pelIOacnyDvvJoyMDIw5bm0MDLm nIgxOeaXpSAwNDowMQ0K5Li7IOmimCDvvJpJZHIgRGlnZXN0LCBWb2wgMTkwLCBJc3N1ZSAxNA0K DQoNClNlbmQgSWRyIG1haWxpbmcgbGlzdCBzdWJtaXNzaW9ucyB0bw0KICAgIGlkckBpZXRmLm9y Zw0KDQpUbyBzdWJzY3JpYmUgb3IgdW5zdWJzY3JpYmUgdmlhIHRoZSBXb3JsZCBXaWRlIFdlYiwg dmlzaXQNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lkcg0Kb3Is IHZpYSBlbWFpbCwgc2VuZCBhIG1lc3NhZ2Ugd2l0aCBzdWJqZWN0IG9yIGJvZHkgJ2hlbHAnIHRv DQogICAgaWRyLXJlcXVlc3RAaWV0Zi5vcmcNCg0KWW91IGNhbiByZWFjaCB0aGUgcGVyc29uIG1h bmFnaW5nIHRoZSBsaXN0IGF0DQogICAgaWRyLW93bmVyQGlldGYub3JnDQoNCldoZW4gcmVwbHlp bmcsIHBsZWFzZSBlZGl0IHlvdXIgU3ViamVjdCBsaW5lIHNvIGl0IGlzIG1vcmUgc3BlY2lmaWMN CnRoYW4gIlJlOiBDb250ZW50cyBvZiBJZHIgZGlnZXN0Li4uIg0KDQoNClRvZGF5J3MgVG9waWNz Og0KDQogICAxLiBGd2Q6IEktRCBBY3Rpb246IGRyYWZ0LXpob3UtaWRyLWludGVyLWRvbWFpbi1s Y3UtMDEudHh0DQogICAgICAoUm9iZXJ0IFJhc3p1aykNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCk1l c3NhZ2U6IDENCkRhdGU6IFR1ZSwgMTggRmViIDIwMjAgMTA6NDU6NTkgKzAxMDANCkZyb206IFJv YmVydCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0Pg0KVG86ICJpZHJAaWV0Zi4gb3JnIiA8aWRy QGlldGYub3JnPiwgU1BSSU5HIFdHIDxzcHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbSWRyXSBG d2Q6IEktRCBBY3Rpb246IGRyYWZ0LXpob3UtaWRyLWludGVyLWRvbWFpbi1sY3UtMDEudHh0DQpN ZXNzYWdlLUlEOg0KICAgIDxDQU9qK01NR2hqMW1Sb3ZHTmNRN2tteG5XU3ZVclZnWnV4TDF5N3lu U21CaXVwTHM1NUFAbWFpbC5nbWFpbC5jb20+DQpDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNo YXJzZXQ9InV0Zi04Ig0KDQpEZWFyIEF1dGhvcnMgb2YgICJJbnRlci1kb21haW4gTmV0d29yayBT bGljaW5nIHZpYSBCR1AtTFUiIGRyYWZ0LA0KDQpDYW4geW91IGtpbmRseSBlbGFib3JhdGUgd2h5 IHlvdXIgdWx0aW1hdGUgZ29hbCBjYW4gbm90IGJlDQphY2NvbXBsaXNoZWQgdXNpbmcgU1ItTVBM UyBhbmQgZmxleGlibGUgYWxnb3JpdGhtID8NCg0KSXMgaGF2aW5nIE4gc29sdXRpb25zIHRvIHRo ZSBzYW1lIHByb2JsZW0gYSBnb29kIHRoaW5nID8gU2VlIHdyaXRpbmcgYQ0KZHJhZnQgaXMgZWFz eSwgcHVibGlzaGluZyBpdCBhcyBSRkMgYSBiaXQgaGFyZGVyIGJ1dCBkb2FibGUsIGJ1dCB0aGUg cmVhbA0KY2hhbGxlbmdlIGlzIHRvIHN1cHBvcnQgaXQgaW4gYWxsIHByb2R1Y3RzIGFzIHdlbGwg YXMgc3RydWdnbGUgd2l0aA0KaW50ZXJvcGVyYWJpbGl0eSBpc3N1ZXMgYmV0d2VlbiBjb21wbGV0 ZWx5IGRpc2pvaW50ZWQgc29sdXRpb25zLg0KDQpBcyB0byB5b3VyIHByb3Bvc2FsIHdoeSBpcyB0 aGlzIGEgc3RhbmRhcmRzIHRyYWNrIHZzIGluZm9ybWF0aW9uID8gQUZBSUsNCnlvdSBhcmUgbm90 IGRlZmluaW5nIGFueSBCR1AgZXh0ZW5zaW9uIC0ganVzdCB1c2luZyBhZGQtcGF0aHMgYW5kDQpj b21tdW5pdHkuIEhvdyByZWNlaXZlciBpbnRlcnByZXRzIHRoZSBjb21tdW5pdHkgaXMgYSBsb2Nh bCBtYXR0ZXIuDQoNCk1hbnkgdGh4LA0KUi4NCg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2Fn ZSAtLS0tLS0tLS0NCkZyb206IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQpEYXRlOiBUdWUs IEZlYiAxOCwgMjAyMCBhdCAxMDozNSBBTQ0KU3ViamVjdDogSS1EIEFjdGlvbjogZHJhZnQtemhv dS1pZHItaW50ZXItZG9tYWluLWxjdS0wMS50eHQNClRvOiA8aS1kLWFubm91bmNlQGlldGYub3Jn Pg0KDQoNCg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxp bmUgSW50ZXJuZXQtRHJhZnRzDQpkaXJlY3Rvcmllcy4NCg0KDQogICAgICAgIFRpdGxlICAgICAg ICAgICA6IEludGVyLWRvbWFpbiBOZXR3b3JrIFNsaWNpbmcgdmlhIEJHUC1MVQ0KICAgICAgICBB dXRob3JzICAgICAgICAgOiBKaW4gWmhvdQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBDaHVu bmluZyBEYWkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgU2hhb2Z1IFBlbmcNCiAgICAgICAg RmlsZW5hbWUgICAgICAgIDogZHJhZnQtemhvdS1pZHItaW50ZXItZG9tYWluLWxjdS0wMS50eHQN CiAgICAgICAgUGFnZXMgICAgICAgICAgIDogNw0KICAgICAgICBEYXRlICAgICAgICAgICAgOiAy MDIwLTAyLTE4DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBhaW1zIHRvIHNvbHZlIGlu dGVyLWRvbWFpbiBuZXR3b3JrIHNsaWNpbmcgcHJvYmxlbXMNCiAgIHVzaW5nIGV4aXN0aW5nIHRl Y2hub2xvZ2llcy4gIEl0IGF0dGVtcHRzIHRvIGVzdGFibGlzaCBtdWx0aXBsZSBCR1AtDQogICBM VSBMU1BzIG9mIGRpZmZlcmVudCBjb2xvcnMgZm9yIGEgcHJlZml4IHRvIHN0aXRjaCBtdWx0aXBs ZSBuZXR3b3JrDQogICBzZWdtZW50cy4NCg0KDQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMg cGFnZSBmb3IgdGhpcyBkcmFmdCBpczoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LXpob3UtaWRyLWludGVyLWRvbWFpbi1sY3UvDQoNClRoZXJlIGFyZSBhbHNvIGh0bWxp emVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC16aG91LWlkci1pbnRlci1kb21haW4tbGN1LTAxDQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9odG1sL2RyYWZ0LXpob3UtaWRyLWludGVyLWRvbWFpbi1sY3UtMDENCg0KQSBk aWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LXpob3UtaWRyLWludGVyLWRvbWFpbi1sY3Ut MDENCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMg ZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQp1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpJbnRlcm5ldC1EcmFm dHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KSS1ELUFubm91bmNl QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5v dW5jZQ0KSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hh ZG93Lmh0bWwNCm9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQot LS0tLS0tLS0tLS0tLSBuZXh0IHBhcnQgLS0tLS0tLS0tLS0tLS0NCkFuIEhUTUwgYXR0YWNobWVu dCB3YXMgc2NydWJiZWQuLi4NClVSTDogPGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJj aC9icm93c2UvaWRyL2F0dGFjaG1lbnRzLzIwMjAwMjE4LzNlMGJkYmUxL2F0dGFjaG1lbnQuaHRt bD4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNClN1YmplY3Q6IERpZ2VzdCBG b290ZXINCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N CklkciBtYWlsaW5nIGxpc3QNCklkckBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pZHINCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K RW5kIG9mIElkciBEaWdlc3QsIFZvbCAxOTAsIElzc3VlIDE0DQoqKioqKioqKioqKioqKioqKioq KioqKioqKioqKioqKioqKio= --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZh bWlseTphcmlhbDsiPkRlYXIgUm9iZXJ0LDwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9u dC1mYW1pbHk6YXJpYWw7Ij48YnI+PC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZh bWlseTphcmlhbDsiPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6YXJp YWw7Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IHNhbnMtc2VyaWY7Ij5GaXJzdGx5LCB3ZSBz dHJvbmdseSBhZ3JlZSB0aGF0IHRoZSBTUi1NUExTICZhbXA7IEZBIHNvbHV0aW9uIGNhbiBhY2hp ZXZlIHRoZSB1bHRpbWF0ZSBnb2FsLiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IHNhbnMtc2VyaWY7Ij5BY2NvcmRpbmcgdG8gb3VyIHVuZGVyc3RhbmRpbmcsIGZvciBhbiBF MkUgaW50ZXItZG9tYWluIFNSIHBvbGljeSwgY29sb3IgaXMgdXNlZCB0byBkZWZpbmUgdGhlIGNv cnJlc3BvbmRpbmcgVEUgcHVycG9zZS4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiBzYW5zLXNlcmlmOyI+VGhlIGNvbnRyb2xsZXIgY2FuIGNlbnRyYWxseSBjYWxjdWxhdGUg dGhlIEUyRSBwYXRoIHRoYXQgbWVldHMgdGhlIFRFIHB1cnBvc2UuIFRoZW4gZm9yIHRoZSBzZWdt ZW50IGxpc3QgaW4gZWFjaCBkb21haW4sIEZBIGNhbiBiZSB1c2VkIGZvciBzdGFjayBkZXB0aCBv cHRpbWl6YXRpb24uIEluIGFkZGl0aW9uLCB0aGUgY29udHJvbGxlciBjYW4gYWxzbyBzZWxlY3Qg aW50ZXItZG9tYWluIGxpbmsgcmVzb3VyY2VzIGFjY29yZGluZyB0byB0aGUgVEUgcHVycG9zZS4g Tm90ZSB0aGF0LCBhbHRob3VnaCBGQSB1c2VzIGRpc3RyaWJ1dGVkIENTUEYsIHRoZSBlbnRpcmUg RTJFIFNSIHBvbGljeSBpcyBjYWxjdWxhdGVkIGNlbnRyYWxseS48L3NwYW4+PC9wPjxwPjxicj48 L3A+PHA+VGhpcyBkcmFmdCBkaXNjdXNzZXMgaG93IHRvIHVzZSBCR1AtTFUgdG8gY2FsY3VsYXRl IGFuIEUyRSBpbnRlci1BUyBMVSBMU1AgaW4gYSBkaXN0cmlidXRlZCBtYW5uZXIsIHdoaWNoIGlz IGRpZmZlcmVudCBmcm9tIHRoZSBhYm92ZSBzY2hlbWUuIFRoZSB1bmRlcmxheSBwYXRoIGluc2lk ZSBlYWNoIGRvbWFpbiAoc3VjaCBhcyB0aGUgU1ItRkEsIFNSLVRFIHR1bm5lbCwgU1IgcG9saWN5 IGluIHRoZSBkb21haW4pIHdpbGwgYmUgaXRlcmF0ZWQgYmFzZWQgb24gdGhlIEJHUC1MVSBjb2xv ciBwbHVzIG5leHQtaG9wLlRoZSBsaW5rIHJlc291cmNlcyBiZXR3ZWVuIHRoZSBkb21haW5zIHdp bGwgYWxzbyBiZSBzZWxlY3RlZCBiYXNlZCBvbiB0aGUgQkdQLUxVIGNvbG9yLiBUaGVzZSBhcmUg YWxsIGRvbmUgYnkgdGhlIGVxdWlwbWVudCBpdHNlbGYuPC9wPjxwPjxicj48L3A+PHA+V2UgdGhp bmsgdGhhdCBib3RoIHNvbHV0aW9ucyBjYW4gY29leGlzdCwgZWFjaCB3aXRoIGl0cyBvd24gYXBw bGljYXRpb24gc2NlbmFyaW8uIFRoaXMgZHJhZnQgaXMgbWFpbmx5IHVzZWQgZm9yIHNlYW1sZXNz IE1QTFMgSVBSQU4gbmV0d29ya3MgY29uZmlndXJlZCB3aXRoIEJHUC1MVS4gU29tZSBzZXJ2aWNl cyB3aWxsIGJlIGNhcnJpZWQgdXNpbmcgRTJFIFNSIHBvbGljeSwgYnV0IHNvbWUgb3RoZXIgc2Vy dmljZSB3aWxsIGJlIGNhcnJpZWQgdXNpbmcgRTJFIEJHUC1MVSBMU1AuPC9wPjxwPjxicj48L3A+ PHA+PHNwYW4gc3R5bGU9ImxpbmUtaGVpZ2h0OiAyMXB4OyI+VGhlIGV4aXN0ZWQgQkdQIG1lY2hh bmlzbSBpcyBlbm91Z2ggdG8gYWNoaWV2ZSB0aGUgZ29hbCwgYW5kIHdlIGRvbid0IHRoaW5rIGV4 dHJhIGV4dGVuc2lvbnMgYXJlIG5lY2Vzc2FyeS4gJm5ic3A7PC9zcGFuPkFkbWl0dGVkbHksIGFz IHUgc2FpZCwgaXQncyByZWFsbHkgYSBsb2NhbCBzdHJhdGVneS4gQVNCUiBkZXRlcm1pbmVzIHdo ZXRoZXIgdG8gYWR2ZXJ0aXNlIG11bHRpcGF0aHMgYmFzZWQgb24gJmx0O3ByZWZpeCwgY29sb3Im Z3Q7LCB3aGV0aGVyIHRvIGdlbmVyYXRlIGxhYmVsIHN3aXRjaGluZyBlbnRyaWVzIGJhc2VkIG9u ICZsdDtwcmVmaXgsIGNvbG9yJmd0OywgYW5kIHdoZXRoZXIgdG8gZ2VuZXJhdGUgQkdQLUxTUCBl bnRyaWVzIGJhc2VkIG9uICZsdDtwcmVmaXgsIGNvbG9yJmd0Oy4gPHNwYW4gc3R5bGU9ImxpbmUt aGVpZ2h0OiAyMXB4OyI+Jm5ic3A7PC9zcGFuPlRoZXNlIGxvY2FsIGRldGVybWluYXRpb25zIGhh dmUgaW1wbGVtZXRlZCBpbiBvdXIgcHJvZHVjdC4mbmJzcDs8L3A+PHA+PGJyPjwvcD48cD5UaGFu a3MgZm9yIHlvdXIgYXR0ZW50aW9uIGFuZCBhZHZpY2UuJm5ic3A7PC9wPjxwPjxicj48L3A+PHA+ SmluPC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZhbWlseTphcmlhbDsiPjxicj48 L3A+PGRpdiBjbGFzcz0iek1haWxTaWduIiB1bm9uYW1lY2g9IuWRqOeRvjAwMTExNzUzIiB1bm9u YW1lZW49Inpob3UgamluMDAxMTE3NTMiPjxwIGNsYXNzPSJ6TWFpbFNpZ25UaXRsZSIgdW5vbmFt ZWNoPSLlkajnkb4wMDExMTc1MyIgdW5vbmFtZWVuPSJ6aG91IGppbjAwMTExNzUzIiBzdHlsZT0i ZGlzcGxheTogbm9uZTsiPjxsYWJlbCBjbGFzcz0ic2lnbl9uYW1lVW5vIj48L2xhYmVsPjxzcGFu IGNsYXNzPSJzaWduX2Fycm93Ij48L3NwYW4+PC9wPjxkaXYgY2xhc3M9InpNYWlsU2lnbkNvbnRl bnQiPjxkaXY+PHAgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZM7IGZvbnQtc2l6ZToxNHB4OyBs aW5lLWhlaWdodDogbm9ybWFsOyB3aWRvd3M6IDE7Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0 cHg7Y29sb3I6IzU4NTk1Qjtmb250LWZhbWlseTrlvq7ova/pm4Xpu5E7Zm9udC1zaXplOjE0cHg7 Ij48c3BhbiBjbGFzcz0ic2lnbmVkaXQiPjxicj48L3NwYW4+PC9zcGFuPjwvcD48cCBzdHlsZT0i Zm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOjE0cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IHdpZG93czogMTsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTRweDtjb2xvcjojNTg1OTVCO2Zv bnQtZmFtaWx5OuW+rui9r+mbhem7kSI+PHNwYW4gY2xhc3M9InNpZ25lZGl0IiBpZD0ic2lnbl9u YW1lIj7lkajnkb48L3NwYW4+Jm5ic3A7SmluIFpob3U8L3NwYW4+PC9wPjxwIHN0eWxlPSJmb250 LXNpemU6MTRweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgd2lkb3dzOiAxOyI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxNHB4O2NvbG9yOiM1ODU5NUI7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buRO2Zv bnQtc2l6ZToxNHB4OyI+PHNwYW4gc3R5bGU9IiI+PHNwYW4gY2xhc3M9InNpZ25lZGl0Ij48YnI+ PC9zcGFuPjwvc3Bhbj48L3NwYW4+PC9wPjxwIHN0eWxlPSJmb250LWZhbWlseTog5a6L5L2TOyBm b250LXNpemU6MTRweDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgd2lkb3dzOiAxOyI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxNHB4O2NvbG9yOiM1ODU5NUI7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buR Ij48c3BhbiBjbGFzcz0ic2lnbmVkaXQiIGlkPSJzaWduX3Bvc2l0aW9uIj48L3NwYW4+PHNwYW4g Y2xhc3M9InNpZ25lZGl0IiBpZD0ic2lnbl9wb3NpdGlvbiIgc3R5bGU9ImJveC1zaXppbmc6IGJv cmRlci1ib3g7IGNvbG9yOiByZ2IoODgsIDg5LCA5MSk7IGZvbnQtZmFtaWx5OiDlvq7ova/pm4Xp u5E7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG91dGxpbmU6IDBweCAhaW1wb3J0YW50OyBiYWNrZ3Jv dW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij7mioDmnK/pooTnoJTlt6XnqIvluIg8L3Nw YW4+PHNwYW4gc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IGNvbG9yOiByZ2IoODgsIDg5 LCA5MSk7IGZvbnQtZmFtaWx5OiDlvq7ova/pm4Xpu5E7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG91 dGxpbmU6IDBweCAhaW1wb3J0YW50OyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1 NSk7Ij4mbmJzcDs8c3BhbiBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgZm9udC1mYW1p bHk6IGFyaWFsLCBoZWx2ZXRpY2EsIHNhbnMtc2VyaWY7IG91dGxpbmU6IDBweCAhaW1wb3J0YW50 OyI+VGVjaG5vbG9neSBQcmUtcmVzZWFyY2ggRW5naW5lZXI8L3NwYW4+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTpBcmlhbCI+PHNwYW4gY2xhc3M9InNpZ25lZGl0IiBpZD0ic2lnbl9w b3NpdGlvbl9lbmciPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjxicj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjE0cHg7Y29sb3I6IzU4NTk1Qjtmb250LWZhbWlseTrlvq7ova/pm4Xpu5EiPjxzcGFuIGNs YXNzPSJzaWduZWRpdCIgaWQ9InNpZ25fZGVwdCIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1i b3g7IGNvbG9yOiByZ2IoODgsIDg5LCA5MSk7IGZvbnQtZmFtaWx5OiDlvq7ova/pm4Xpu5E7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IG91dGxpbmU6IDBweCAhaW1wb3J0YW50OyBiYWNrZ3JvdW5kLWNv bG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij7mnrbmnoTlm6LpmJ8v5pyJ57q/6KeE5YiS6YOoL+ac iee6v+S6p+WTgee7j+iQpemDqDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6IHJnYig4OCwgODks IDkxKTsgZm9udC1mYW1pbHk6IOW+rui9r+mbhem7kTsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgYmFj a2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+Jm5ic3A7QXJjaGl0ZWN0dXJlIFRl YW08L3NwYW4+PHNwYW4gc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IGNvbG9yOiByZ2Io ODgsIDg5LCA5MSk7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IGZvbnQtZmFtaWx5OiBBcmlhbDsgb3V0 bGluZTogMHB4ICFpbXBvcnRhbnQ7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1 KTsiPjxzcGFuIGNsYXNzPSJzaWduZWRpdCIgaWQ9InNpZ25fZGVwdF9lbmciIHN0eWxlPSJib3gt c2l6aW5nOiBib3JkZXItYm94OyBvdXRsaW5lOiAwcHggIWltcG9ydGFudDsiPi9XaXJlbGluZSBQ cm9kdWN0IFBsYW5uaW5nIERpdmlzaW9uPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6QXJpYWwiPjxzcGFuIGNsYXNzPSJzaWduZWRpdCIgaWQ9InNpZ25fZGVwdF9lbmciPjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7IGxpbmUtaGVp Z2h0OiBub3JtYWw7IHdpZG93czogMTsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTRweDtjb2xv cjojNTg1OTVCO2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTtmb250LXNpemU6MTRweDsiPjxzcGFu IHN0eWxlPSIiPjxzcGFuIGNsYXNzPSJzaWduZWRpdCI+PGJyPjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IHdpZG93 czogMTsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTRweDtjb2xvcjojNTg1OTVCO2ZvbnQtZmFt aWx5OuW+rui9r+mbhem7kTtmb250LXNpemU6MTRweDsiPjwvc3Bhbj48L3A+PHRhYmxlIHN0eWxl PSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTog5a6L5L2TOyB3aWRvd3M6IDE7Ij48 dGJvZHk+PHRyIGNsYXNzPSJmaXJzdFJvdyI+PHRkIHZhbGlnbj0idG9wIiB3aWR0aD0iMTAwIj48 aW1nIGlkPSJzaWduLWljb24iIHNyYz0iY2lkOjgzZTRkYmFlM2RjNTQzYjJhMWUwZWI4OGZkYmVj ZjZiIiB3aWR0aD0iMTMwIiBoZWlnaHQ9IjEyMCIgc2lnbj0ic2lnbjo4M2U0ZGJhZTNkYzU0M2Iy YTFlMGViODhmZGJlY2Y2YiI+PC90ZD48dGQgdmFsaWduPSJ0b3AiIHdpZHRoPSI1MDAiIHN0eWxl PSJ3b3JkLWJyZWFrOiBicmVhay1hbGw7Ij48aW1nIGlkPSJzaWduLWxvZ28iIHNyYz0iY2lkOjI0 MjQyZTU2MzdhZjQyODg5MWM0ZGI3MzFlNzc2NWFkIiB3aWR0aD0iMTE1IiBoZWlnaHQ9IjM4IiBz aWduPSJzaWduOjI0MjQyZTU2MzdhZjQyODg5MWM0ZGI3MzFlNzc2NWFkIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjE0cHg7Y29sb3I6IzU4NTk1Qjtmb250LWZhbWlseTrlvq7ova/pm4Xpu5EiPjxi cj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWwiPjxzcGFuIGNsYXNzPSJzaWduZWRpdCIg aWQ9InNpZ25fYWRkcl9lbmdfMSI+MzMvRiwgUiZhbXA7RCBCdWlsZGluZywgWlRFCkNvcnBvcmF0 aW9uIEhpLXRlY2ggUm9hZCBTb3V0aDwvc3Bhbj4sIDxicj48c3BhbiBjbGFzcz0ic2lnbmVkaXQi IGlkPSJzaWduX2FkZHJfZW5nXzIiPkhpLXRlY2gKSW5kdXN0cmlhbCBQYXJrIE5hbnNoYW4gRGlz dHJpY3QsIFNoZW56aGVuLCBQLi5SLkNoaW5hLCA1MTgwNTc8L3NwYW4+IDxicj48c3BhbiBzdHls ZT0iY29sb3I6IzAwOEZENCI+VDwvc3Bhbj46IDxzcGFuIGNsYXNzPSJzaWduZWRpdCIgaWQ9InNp Z25fZml4X3Bob25lIj4rODYgNzU1IHh4eHh4eHh4PC9zcGFuPiA8c3BhbiBzdHlsZT0iY29sb3I6 IzAwOEZENCI+Rjwvc3Bhbj46PHNwYW4gY2xhc3M9InNpZ25lZGl0IiBpZD0ic2lnbl9mYXgiPis4 NiA3NTUgeHh4eHh4eHg8L3NwYW4+IDxicj48c3BhbiBzdHlsZT0iY29sb3I6IzAwOEZENCI+TTwv c3Bhbj46IDxzcGFuIGNsYXNzPSJzaWduZWRpdCIgaWQ9InNpZ25fcGhvbmUiPjxhIGhyZWY9InRl bDorODYgMTg1NzU1NjUxMzUiIHRhcmdldD0iX2JsYW5rIiBjbGFzcz0ic2lnbmhyZWYiPis4NiAx ODU3NTU2NTEzNTwvYT48L3NwYW4+PGJyPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA4RkQ0Ij5FPC9z cGFuPjogPHNwYW4gY2xhc3M9InNpZ25lZGl0IiBpZD0ic2lnbl9lbWFpbCI+emhvdS5qaW42QHp0 ZS5jb20uY248L3NwYW4+IDxicj48c3BhbiBzdHlsZT0iY29sb3I6IzAwOEZENCI+PGEgaHJlZj0i aHR0cDovL3d3dy56dGUuY29tLmNuLyIgdGFyZ2V0PSJfYmxhbmsiPnd3dy56dGUuY29tLmNuPC9h Pjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvdGQ+PC90cj48L3Rib2R5PjwvdGFibGU+PHNwYW4gc3R5 bGU9ImxpbmUtaGVpZ2h0OiBub3JtYWw7IHdpZG93czogMTsgZm9udC1zaXplOjE0cHg7O2NvbG9y OiM1ODU5NWI7Zm9udC1zaXplOjEwcHgiPjwvc3Bhbj48L2Rpdj48L2Rpdj48L2Rpdj48ZGl2Pjxk aXYgY2xhc3M9InpoaXN0b3J5Um93IiBzdHlsZT0iZGlzcGxheTpibG9jayI+PGRpdiBjbGFzcz0i emhpc3RvcnlEZXMiIHN0eWxlPSJ3aWR0aDogMTAwJTsgaGVpZ2h0OiAyOHB4OyBsaW5lLWhlaWdo dDogMjhweDsgYmFja2dyb3VuZC1jb2xvcjogI0UwRTVFOTsgY29sb3I6ICMxMzg4RkY7IHRleHQt YWxpZ246IGNlbnRlcjsiIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlPcmdUeHQiPuWOn+Wni+mCruS7 tjwvZGl2PjxkaXYgaWQ9Inp3cml0ZUhpc3RvcnlDb250YWluZXIiPjxkaXYgY2xhc3M9ImNvbnRy b2wtZ3JvdXAgemhpc3RvcnlQYW5lbCI+PGRpdiBjbGFzcz0iemhpc3RvcnlIZWFkZXIiIHN0eWxl PSJwYWRkaW5nOiA4cHg7IGJhY2tncm91bmQtY29sb3I6ICNGNUY2Rjg7Ij48ZGl2PjxzdHJvbmcg bGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeVNlbmRlclR4dCI+5Y+R5Lu25Lq677yaPC9zdHJvbmc+PHNw YW4gY2xhc3M9InpyZWFkVXNlck5hbWUiPmlkci1yZXF1ZXN0QGlldGYub3JnICZsdDtpZHItcmVx dWVzdEBpZXRmLm9yZyZndDs8L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9 Ikhpc3RvcnlUT1R4dCI+5pS25Lu25Lq677yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVXNl ck5hbWUiIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7Ij5pZHJAaWV0Zi5vcmcgJmx0O2lkckBpZXRm Lm9yZyZndDs7PC9zcGFuPjwvZGl2PjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5 RGF0ZVR4dCI+5pelIOacnyDvvJo8L3N0cm9uZz48c3BhbiBjbGFzcz0iIj4yMDIw5bm0MDLmnIgx OeaXpSAwNDowMTwvc3Bhbj48L2Rpdj48ZGl2PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9y eVN1YmplY3RUeHQiPuS4uyDpopgg77yaPC9zdHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVGl0bGUi PjxzdHJvbmc+SWRyIERpZ2VzdCwgVm9sIDE5MCwgSXNzdWUgMTQ8L3N0cm9uZz48L3NwYW4+PC9k aXY+PC9kaXY+PGRpdiBjbGFzcz0iemhpc3RvcnlDb250ZW50Ij48ZGl2PlNlbmQmbmJzcDtJZHIm bmJzcDttYWlsaW5nJm5ic3A7bGlzdCZuYnNwO3N1Ym1pc3Npb25zJm5ic3A7dG88YnI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7aWRyQGlldGYub3JnPGJyPjxicj5UbyZuYnNwO3N1YnNjcmliZSZu YnNwO29yJm5ic3A7dW5zdWJzY3JpYmUmbmJzcDt2aWEmbmJzcDt0aGUmbmJzcDtXb3JsZCZuYnNw O1dpZGUmbmJzcDtXZWIsJm5ic3A7dmlzaXQ8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pZHI8YnI+b3IsJm5ic3A7dmlhJm5i c3A7ZW1haWwsJm5ic3A7c2VuZCZuYnNwO2EmbmJzcDttZXNzYWdlJm5ic3A7d2l0aCZuYnNwO3N1 YmplY3QmbmJzcDtvciZuYnNwO2JvZHkmbmJzcDsnaGVscCcmbmJzcDt0bzxicj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDtpZHItcmVxdWVzdEBpZXRmLm9yZzxicj48YnI+WW91Jm5ic3A7Y2FuJm5i c3A7cmVhY2gmbmJzcDt0aGUmbmJzcDtwZXJzb24mbmJzcDttYW5hZ2luZyZuYnNwO3RoZSZuYnNw O2xpc3QmbmJzcDthdDxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtpZHItb3duZXJAaWV0Zi5v cmc8YnI+PGJyPldoZW4mbmJzcDtyZXBseWluZywmbmJzcDtwbGVhc2UmbmJzcDtlZGl0Jm5ic3A7 eW91ciZuYnNwO1N1YmplY3QmbmJzcDtsaW5lJm5ic3A7c28mbmJzcDtpdCZuYnNwO2lzJm5ic3A7 bW9yZSZuYnNwO3NwZWNpZmljPGJyPnRoYW4mbmJzcDsiUmU6Jm5ic3A7Q29udGVudHMmbmJzcDtv ZiZuYnNwO0lkciZuYnNwO2RpZ2VzdC4uLiI8YnI+PGJyPjxicj5Ub2RheSdzJm5ic3A7VG9waWNz Ojxicj48YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7MS4mbmJzcDtGd2Q6Jm5ic3A7SS1EJm5ic3A7QWN0 aW9uOiZuYnNwO2RyYWZ0LXpob3UtaWRyLWludGVyLWRvbWFpbi1sY3UtMDEudHh0PGJyPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyhSb2JlcnQmbmJzcDtSYXN6dWspPGJyPjxi cj48YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLTxicj48YnI+TWVzc2FnZTombmJzcDsxPGJyPkRhdGU6Jm5ic3A7 VHVlLCZuYnNwOzE4Jm5ic3A7RmViJm5ic3A7MjAyMCZuYnNwOzEwOjQ1OjU5Jm5ic3A7KzAxMDA8 YnI+RnJvbTombmJzcDtSb2JlcnQmbmJzcDtSYXN6dWsmbmJzcDsmbHQ7cm9iZXJ0QHJhc3p1ay5u ZXQmZ3Q7PGJyPlRvOiZuYnNwOyJpZHJAaWV0Zi4mbmJzcDtvcmciJm5ic3A7Jmx0O2lkckBpZXRm Lm9yZyZndDssJm5ic3A7U1BSSU5HJm5ic3A7V0cmbmJzcDsmbHQ7c3ByaW5nQGlldGYub3JnJmd0 Ozxicj5TdWJqZWN0OiZuYnNwO1tJZHJdJm5ic3A7RndkOiZuYnNwO0ktRCZuYnNwO0FjdGlvbjom bmJzcDtkcmFmdC16aG91LWlkci1pbnRlci1kb21haW4tbGN1LTAxLnR4dDxicj5NZXNzYWdlLUlE Ojxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7Q0FPaitNTUdoajFtUm92R05jUTdrbXhu V1N2VXJWZ1p1eEwxeTd5blNtQml1cExzNTVBQG1haWwuZ21haWwuY29tJmd0Ozxicj5Db250ZW50 LVR5cGU6Jm5ic3A7dGV4dC9wbGFpbjsmbmJzcDtjaGFyc2V0PSJ1dGYtOCI8YnI+PGJyPkRlYXIm bmJzcDtBdXRob3JzJm5ic3A7b2YmbmJzcDsmbmJzcDsiSW50ZXItZG9tYWluJm5ic3A7TmV0d29y ayZuYnNwO1NsaWNpbmcmbmJzcDt2aWEmbmJzcDtCR1AtTFUiJm5ic3A7ZHJhZnQsPGJyPjxicj5D YW4mbmJzcDt5b3UmbmJzcDtraW5kbHkmbmJzcDtlbGFib3JhdGUmbmJzcDt3aHkmbmJzcDt5b3Vy Jm5ic3A7dWx0aW1hdGUmbmJzcDtnb2FsJm5ic3A7Y2FuJm5ic3A7bm90Jm5ic3A7YmU8YnI+YWNj b21wbGlzaGVkJm5ic3A7dXNpbmcmbmJzcDtTUi1NUExTJm5ic3A7YW5kJm5ic3A7ZmxleGlibGUm bmJzcDthbGdvcml0aG0mbmJzcDs/PGJyPjxicj5JcyZuYnNwO2hhdmluZyZuYnNwO04mbmJzcDtz b2x1dGlvbnMmbmJzcDt0byZuYnNwO3RoZSZuYnNwO3NhbWUmbmJzcDtwcm9ibGVtJm5ic3A7YSZu YnNwO2dvb2QmbmJzcDt0aGluZyZuYnNwOz8mbmJzcDtTZWUmbmJzcDt3cml0aW5nJm5ic3A7YTxi cj5kcmFmdCZuYnNwO2lzJm5ic3A7ZWFzeSwmbmJzcDtwdWJsaXNoaW5nJm5ic3A7aXQmbmJzcDth cyZuYnNwO1JGQyZuYnNwO2EmbmJzcDtiaXQmbmJzcDtoYXJkZXImbmJzcDtidXQmbmJzcDtkb2Fi bGUsJm5ic3A7YnV0Jm5ic3A7dGhlJm5ic3A7cmVhbDxicj5jaGFsbGVuZ2UmbmJzcDtpcyZuYnNw O3RvJm5ic3A7c3VwcG9ydCZuYnNwO2l0Jm5ic3A7aW4mbmJzcDthbGwmbmJzcDtwcm9kdWN0cyZu YnNwO2FzJm5ic3A7d2VsbCZuYnNwO2FzJm5ic3A7c3RydWdnbGUmbmJzcDt3aXRoPGJyPmludGVy b3BlcmFiaWxpdHkmbmJzcDtpc3N1ZXMmbmJzcDtiZXR3ZWVuJm5ic3A7Y29tcGxldGVseSZuYnNw O2Rpc2pvaW50ZWQmbmJzcDtzb2x1dGlvbnMuPGJyPjxicj5BcyZuYnNwO3RvJm5ic3A7eW91ciZu YnNwO3Byb3Bvc2FsJm5ic3A7d2h5Jm5ic3A7aXMmbmJzcDt0aGlzJm5ic3A7YSZuYnNwO3N0YW5k YXJkcyZuYnNwO3RyYWNrJm5ic3A7dnMmbmJzcDtpbmZvcm1hdGlvbiZuYnNwOz8mbmJzcDtBRkFJ Szxicj55b3UmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtkZWZpbmluZyZuYnNwO2FueSZuYnNwO0JH UCZuYnNwO2V4dGVuc2lvbiZuYnNwOy0mbmJzcDtqdXN0Jm5ic3A7dXNpbmcmbmJzcDthZGQtcGF0 aHMmbmJzcDthbmQ8YnI+Y29tbXVuaXR5LiZuYnNwO0hvdyZuYnNwO3JlY2VpdmVyJm5ic3A7aW50 ZXJwcmV0cyZuYnNwO3RoZSZuYnNwO2NvbW11bml0eSZuYnNwO2lzJm5ic3A7YSZuYnNwO2xvY2Fs Jm5ic3A7bWF0dGVyLjxicj48YnI+TWFueSZuYnNwO3RoeCw8YnI+Ui48YnI+PGJyPi0tLS0tLS0t LS0mbmJzcDtGb3J3YXJkZWQmbmJzcDttZXNzYWdlJm5ic3A7LS0tLS0tLS0tPGJyPkZyb206Jm5i c3A7Jmx0O2ludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyZndDs8YnI+RGF0ZTombmJzcDtUdWUsJm5i c3A7RmViJm5ic3A7MTgsJm5ic3A7MjAyMCZuYnNwO2F0Jm5ic3A7MTA6MzUmbmJzcDtBTTxicj5T dWJqZWN0OiZuYnNwO0ktRCZuYnNwO0FjdGlvbjombmJzcDtkcmFmdC16aG91LWlkci1pbnRlci1k b21haW4tbGN1LTAxLnR4dDxicj5UbzombmJzcDsmbHQ7aS1kLWFubm91bmNlQGlldGYub3JnJmd0 Ozxicj48YnI+PGJyPjxicj5BJm5ic3A7TmV3Jm5ic3A7SW50ZXJuZXQtRHJhZnQmbmJzcDtpcyZu YnNwO2F2YWlsYWJsZSZuYnNwO2Zyb20mbmJzcDt0aGUmbmJzcDtvbi1saW5lJm5ic3A7SW50ZXJu ZXQtRHJhZnRzPGJyPmRpcmVjdG9yaWVzLjxicj48YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1RpdGxlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiZuYnNwO0ludGVyLWRv bWFpbiZuYnNwO05ldHdvcmsmbmJzcDtTbGljaW5nJm5ic3A7dmlhJm5ic3A7QkdQLUxVPGJyPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0F1dGhvcnMmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6Jm5ic3A7 SmluJm5ic3A7WmhvdTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtDaHVubmluZyZuYnNwO0RhaTxicj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtTaGFvZnUmbmJzcDtQZW5nPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO0ZpbGVuYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7OiZuYnNwO2RyYWZ0LXpob3UtaWRyLWludGVyLWRvbWFpbi1sY3Ut MDEudHh0PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O1BhZ2VzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7OiZuYnNwOzc8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7RGF0ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzombmJzcDsyMDIwLTAyLTE4PGJy Pjxicj5BYnN0cmFjdDo8YnI+Jm5ic3A7Jm5ic3A7Jm5ic3A7VGhpcyZuYnNwO2RvY3VtZW50Jm5i c3A7YWltcyZuYnNwO3RvJm5ic3A7c29sdmUmbmJzcDtpbnRlci1kb21haW4mbmJzcDtuZXR3b3Jr Jm5ic3A7c2xpY2luZyZuYnNwO3Byb2JsZW1zPGJyPiZuYnNwOyZuYnNwOyZuYnNwO3VzaW5nJm5i c3A7ZXhpc3RpbmcmbmJzcDt0ZWNobm9sb2dpZXMuJm5ic3A7Jm5ic3A7SXQmbmJzcDthdHRlbXB0 cyZuYnNwO3RvJm5ic3A7ZXN0YWJsaXNoJm5ic3A7bXVsdGlwbGUmbmJzcDtCR1AtPGJyPiZuYnNw OyZuYnNwOyZuYnNwO0xVJm5ic3A7TFNQcyZuYnNwO29mJm5ic3A7ZGlmZmVyZW50Jm5ic3A7Y29s b3JzJm5ic3A7Zm9yJm5ic3A7YSZuYnNwO3ByZWZpeCZuYnNwO3RvJm5ic3A7c3RpdGNoJm5ic3A7 bXVsdGlwbGUmbmJzcDtuZXR3b3JrPGJyPiZuYnNwOyZuYnNwOyZuYnNwO3NlZ21lbnRzLjxicj48 YnI+PGJyPlRoZSZuYnNwO0lFVEYmbmJzcDtkYXRhdHJhY2tlciZuYnNwO3N0YXR1cyZuYnNwO3Bh Z2UmbmJzcDtmb3ImbmJzcDt0aGlzJm5ic3A7ZHJhZnQmbmJzcDtpczo8YnI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtemhvdS1pZHItaW50ZXItZG9tYWluLWxjdS88YnI+ PGJyPlRoZXJlJm5ic3A7YXJlJm5ic3A7YWxzbyZuYnNwO2h0bWxpemVkJm5ic3A7dmVyc2lvbnMm bmJzcDthdmFpbGFibGUmbmJzcDthdDo8YnI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXpob3UtaWRyLWludGVyLWRvbWFpbi1sY3UtMDE8YnI+aHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC16aG91LWlkci1pbnRlci1kb21haW4tbGN1LTAxPGJyPjxi cj5BJm5ic3A7ZGlmZiZuYnNwO2Zyb20mbmJzcDt0aGUmbmJzcDtwcmV2aW91cyZuYnNwO3ZlcnNp b24mbmJzcDtpcyZuYnNwO2F2YWlsYWJsZSZuYnNwO2F0Ojxicj5odHRwczovL3d3dy5pZXRmLm9y Zy9yZmNkaWZmP3VybDI9ZHJhZnQtemhvdS1pZHItaW50ZXItZG9tYWluLWxjdS0wMTxicj48YnI+ PGJyPlBsZWFzZSZuYnNwO25vdGUmbmJzcDt0aGF0Jm5ic3A7aXQmbmJzcDttYXkmbmJzcDt0YWtl Jm5ic3A7YSZuYnNwO2NvdXBsZSZuYnNwO29mJm5ic3A7bWludXRlcyZuYnNwO2Zyb20mbmJzcDt0 aGUmbmJzcDt0aW1lJm5ic3A7b2YmbmJzcDtzdWJtaXNzaW9uPGJyPnVudGlsJm5ic3A7dGhlJm5i c3A7aHRtbGl6ZWQmbmJzcDt2ZXJzaW9uJm5ic3A7YW5kJm5ic3A7ZGlmZiZuYnNwO2FyZSZuYnNw O2F2YWlsYWJsZSZuYnNwO2F0Jm5ic3A7dG9vbHMuaWV0Zi5vcmcuPGJyPjxicj5JbnRlcm5ldC1E cmFmdHMmbmJzcDthcmUmbmJzcDthbHNvJm5ic3A7YXZhaWxhYmxlJm5ic3A7YnkmbmJzcDthbm9u eW1vdXMmbmJzcDtGVFAmbmJzcDthdDo8YnI+ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy88YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPkktRC1Bbm5vdW5jZSZuYnNwO21haWxpbmcmbmJzcDtsaXN0PGJyPkktRC1Bbm5vdW5j ZUBpZXRmLm9yZzxicj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1h bm5vdW5jZTxicj5JbnRlcm5ldC1EcmFmdCZuYnNwO2RpcmVjdG9yaWVzOiZuYnNwO2h0dHA6Ly93 d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWw8YnI+b3ImbmJzcDtmdHA6Ly9mdHAuaWV0Zi5vcmcvaWV0 Zi8xc2hhZG93LXNpdGVzLnR4dDxicj4tLS0tLS0tLS0tLS0tLSZuYnNwO25leHQmbmJzcDtwYXJ0 Jm5ic3A7LS0tLS0tLS0tLS0tLS08YnI+QW4mbmJzcDtIVE1MJm5ic3A7YXR0YWNobWVudCZuYnNw O3dhcyZuYnNwO3NjcnViYmVkLi4uPGJyPlVSTDombmJzcDsmbHQ7aHR0cHM6Ly9tYWlsYXJjaGl2 ZS5pZXRmLm9yZy9hcmNoL2Jyb3dzZS9pZHIvYXR0YWNobWVudHMvMjAyMDAyMTgvM2UwYmRiZTEv YXR0YWNobWVudC5odG1sJmd0Ozxicj48YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPjxicj5TdWJqZWN0OiZuYnNwO0RpZ2VzdCZuYnNwO0Zvb3Rlcjxicj48YnI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+SWRyJm5ic3A7bWFpbGlu ZyZuYnNwO2xpc3Q8YnI+SWRyQGlldGYub3JnPGJyPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vaWRyPGJyPjxicj48YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPjxicj5FbmQmbmJzcDtvZiZuYnNwO0lkciZuYnNwO0RpZ2VzdCwmbmJzcDtWb2wmbmJzcDsx OTAsJm5ic3A7SXNzdWUmbmJzcDsxNDxicj4qKioqKioqKioqKioqKioqKioqKioqKioqKioqKioq KioqKio8L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48cD48YnI+PC9wPjwvZGl2 Pg== --=====_003_next=====-- --=====_002_next===== Content-Type: image/jpeg; name="=?UTF-8?B?MjQyNDJlNTYzN2FmNDI4ODkxYzRkYjczMWU3NzY1YWQuanBn?=" Content-Disposition: inline; filename="=?UTF-8?B?MjQyNDJlNTYzN2FmNDI4ODkxYzRkYjczMWU3NzY1YWQuanBn?=" Content-Transfer-Encoding: base64 Content-ID: <24242e5637af428891c4db731e7765ad> R0lGODlhcwAmAPcAAAAAAP///wCP1QCP1Pf7/vL5/QCP1gWR1gqT1gyU2AyU1w6V1xWY2BeZ2R6c 2iGd2iyi3C6j3TOl3Tqo3kWt4Emv4Uyw4U2x4lOz4ly35F645GO65WW75me85m6/53XC6IHH64XJ 64bK7IzM7I/N7JXQ7ZfR7pnS7pzT7p3U76PW8KPW76XX8K7b8bDc8rff87vh9Lzh9L7i9cnn9tLr +Nnu+eDx+uf0++n1++33/PD4/PT6/fj8/gKQ1AWR1QeS1QiT1QmT1g+W1xCW1xOX1xia2Bub2Ryb 2R+d2SCd2SKe2iSf2iag2ymh2yqh2yui3DSm3Tio3Typ3j2q3j6q3kCr30Os30eu4Euw4U6x4U+y 4k+y4VGz4lCy4Va141W04li241q341245F+55GW75Ga85Wm95mi95Gq+5Wu+5m2/5m/A53HB6HDA 53HB5nLB53PC53XC53bD53nE6HvF6X3G6X/H6YHI6oHI6YLI6oLI6YbK64TJ6YnL64rM64zM65HP 7JPQ7ZbR7ZrT7qXX76bY8KfY76jZ8Kra8azb8a/c8bDc8bHd8rLd8rXe8rXe8bjg87zi9Lzh873i 88Dj9MPl9cXm9cfm9cnn9c3p9s/q987p9tHr99Lr99Xt+Nbt+Nrv+d/x+eDx+eX0++Tz+u/4/OHy +ePz+ur2+/b7/fr9/vz+/v7//////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAK0ALAAAAABzACYA Rwj/AAMIHEiwoMGDCBMqXMiwoUOGiti0mUhxopcBAgZoHKAglcATFaVg3DgAC0U2hgKsKkJyiZqK FUV4bHijx4AHDFmN0BiJ4A2NRFYRJKAAo6WFKzJibOCQEclMB1WxxOgDUQEeqbKm2sEDoQaMhAqS sonE4B2MeQ7WmGlwj0YKCv0oHeDkIUGnAvJCNShVowA7dgXyyXKhsGEJG6kYNqxFUEImGSsQDJFR gOSClUj61cx5wAmEBKJk9JIwTefTaxzaGNnQxhIBex0WAUPwRZoOZnLr3q27Q6CBKXgL742mhUBW e3AP771HlcNSaDjQCVwwByQc1A2+9vtbodONsQn2/8UI2O6F03lP+/1QcEpeJgMbabwyMEzeOQuJ bBSAyC5ejeENNN5GQzBAxIEHNgAGAQZ9JQAlBvUggBIGlYDWQBtYoKGGW1yw4YZacPGhBVjsIRAB B4xEV3YCfZdRgAKNJ0ATLBo01gBlOXSIARgpohAEeQkgSo1EFmnkkUgmqeSSCKkxl3qaMRUBZ5V1 llcHAaQ40lxP+uXQWALkmB0HGplhECYHWADDQ24oJYAVClHilwCgRMVSXiYGhgIZG/TZZxlXaNTD F2X4+adxA+Fg0wBkEGTfACkQhNgAKzR0iop0MvQdgHZu5EdgXw0AYUE2UViQhQKkVdAcQZYSAA9D GP/xxQ4B1KHRFg1h4OYYDzHiJowBDKgiSZXlSZAGeYVFEJhiDnRHXnoM5EOXxO7HmQMGdRJkRtj5 txmwMqoRWBZPplftuXEkxIUJBj2CxUJSVPkGi5sOAO5UA6hqJCql2sVKEBilcRCyAxhQB0GFqEet X3IglAhJlxzEAwPoaSaABV+S1VAmQ+RlREOTBHkGkySXbPLJKKes8sosC6TJllCS9JshC8NsbSUB eFAzZ244FIpSNfrRxADsGoRKQS/ETCWWIShspSMBUGyteu82dGOzCr3AR0EyaESFQU4OAJdDcBC7 SEJjuJmuQTzg+0SSNmG7ECuQDZBAQUlo9AlBg2D/BMVDm2wpQA4KOUISJ53mpa9DJVRmLkZcUgv1 QDRjRMNAI2SUmkAzYDSEcw3xMVcEmj7VqUblPSRGRl2ooMIKK6hAh0Y/kMBC7K9PkBceBeGwUaUB gLKRc/xqZIpD7vkFR0Obwna6AGiAqlEhBY1iUxIG5YFRtAZh1IYOAh090AIY9cRQAUBALsBRzM91 734CICDEAvQvoMAQGNBaELICKDvQ1Wa5kEBi4IJGNMITmTCgAhvhgg8o5QsvMKALcHaQSKRHAAro SlO+ZafHQQ5mAuhDg8AiFo0VBAQCDAAIMWWuKlWGKQZJg5vg5C2/vI92LujKKna4CtAdRAwa8QIL 7YY4xLPErwREHGIVMMI7km0nL4CgjovsdboBiNAumbPYsKpkLUQZRAZ5+dtAOrEAAXwtITjgkiey U68bDiB1RSKARo4QmEOkR3wDOUNlMnCQQrgJPvQyHV+KUCwkAfAhYMjLD4RyECxUJhEESeRmBCAB mMCkBAlpnhsHwAQPWHIifWCQ1UzIEFAEqQsLwQEQ8gIBgWiBS0qbI0JeMJcaHGQV04plXr6kEbkp hBVTEkAPjtcQOWSEVwGQxBw+wMxmOvOZHxiEQnIAgj1o8JZ/gKY2SeDDhejgDW1YnEI+AUm7fIKR LUunOtfJThYFBAA7 --=====_002_next===== Content-Type: image/jpeg; name="=?UTF-8?B?ODNlNGRiYWUzZGM1NDNiMmExZTBlYjg4ZmRiZWNmNmIuanBn?=" Content-Disposition: inline; filename="=?UTF-8?B?ODNlNGRiYWUzZGM1NDNiMmExZTBlYjg4ZmRiZWNmNmIuanBn?=" Content-Transfer-Encoding: base64 Content-ID: <83e4dbae3dc543b2a1e0eb88fdbecf6b> R0lGODlhhQC+APcAAP//////AP8A//8AAAD//wD/AAAA/wAAAPb1+vX0+vPy+fLx+O7t9vDv91tU rIuGxY6Jxrm23Ly53b+838G+4MPA4dHP6NPR6erp9ezr9g8GhhYNihwUjiUdkSkglCwklTEpmDUt mTgwmzw1nT84n0M8oEY/oklCo0pDpEtFpUxGpU9Jp1JMqFZQql5YrmJcsGdhs2pktW5ptnJtuHVw unhzvHt2vX56voJ+wIaBwpGNyJWRypqWzJ2ZzqGe0KSh0aek06qn1K6r1rGu2MXD4sbE48nH5MvJ 5c3L5s7M5t3c7tzb7eDf7+Lh8Obl8+Tj8ejn9LOx2bWz2ra02tTT6tbV69jX7NrZ7Pj4/Pf3+/v7 /f7+//39/gFTwANdww5mxip3zQBkxQtpxxx0yzCN6UiM1F6c2myl3oO89wFpxw1tyRJxyiuD0TeI 0kqS1k+W2IO045O+5gBsyQp0yxt8zkOS11Oc2nSu33q044y95prG6qbT+QF0yxJ8ziSE0SuL1DyT 1z2W2EOW2Euc2l2k3Wat4YO85oi+6JXI8KPN7LTW78Pe89Hm9gB1xwF6zgt8zheD0SSL1DOW2DST 10Sc2lOj3Vup32yz43O144G/6YrA54zD6ZPF6aDP8avT7rPc+bPX8bvc8uHv+QeE0RyN1CqT1zub 2kmj3VOr4Fyu4WSz43y85oTD6YXB55TK65vM7KTS7qzW8Mvl9drs9zGb2juj3XS75bPb8sTj9dTq 99vu+QGO1WG55W285nrC6YTJ64zL7J3S7qbY8aza8bvi9Mzp99Xt+Ov2+53Y8cfp983s+ePz+tzy +tXx+u35/fT7/eb5/d74/CiNUITAlHe8JpbLWL/fmrbaiOfz2H2/H4jEMavUcszlqdLostfru9vt w+r03PP56+Hwy+Xx0+724ujy1/H35vf68f712f745P2+Df3CGv3EI/3GK/3IL/3HMv3JNP3KO/3M Q/3OS/3QT/7PUP3SWP7UY/7Wa/3Ybf7aeP7eh/7jmP7nqP7vxf///yH5BAEAAP8ALAAAAACFAL4A AAj/AAEIHEiwoMGDCBMqXMiwocOHEA8+22RqEYBNlHABYHUK17NVlHI9szUoFwBMp3I5u3Rq1rFL lZYBuGTJZSFLx5alQuXsmaVCy5hVKvRM108AyypdWqbrFCYAjE7ZAmDs1KpnsiitAoCLkiEAWVk9 I0aJE4BQp1wBuGXq1VpTwSI69HQK1rNCcjwBIMQnFoBKfDw5OzXHoyk+FgE9CrUs0BpZyyY9Mgbg DyRZzP6AWZYLEqRjziD5ydW5zTFZkCIVfVRKV7I+dZ6FckSLK59Bx27NqfTME59TABTJ4Q1LTiEA nPioAuBKDqaJcr6+OnVLbsJVci6BTSSKKyyZuL5z//V07Cys8qE8yUx/THasZ2tjtQ+l6NkzRaAE egJlH1QoAMd4Ul1vtzzjjCcWBfjfMbD8twyCSMFCDFKJaPSgLADokgiGusCCYS6JzDLTKG5ZR1Ao nOTCiCsamejiizAy9Awqo4SSyyrVmZiKIyXG6OOPPhrjhxzDwOLIcSa+Ysl/QDbp5EOy3FLMGW6E Issq+cklCy7lPenlMvB5WVBTfiTCVJjP3MKkQ8+cEolFYjZ5CyGcdBknAKvwEV2YAoUyiil8ykjI JC3eGeMzl3Txhy6GGvMHH7QkU1BW2kH0DJiG/giLKbbY6eVEjvAoUaAMMeJRpj9e6oyhy5zCRymU Gf90jDA5NmTHGlmiCmMoqLDi6ZOohaHKqgaFskYdD9liSqG6mohoGm2IGGdSkfh1UC6XmOVQTqQ2 G9ExqcgBq6HMiJSQfVCG8qu3EIELaaxi3pIKLAkt80quDNkxBr66MuOLL4xua0kYf5j0ECy9MKvQ MYV0Mcm6ffIByENw2KEwqrHIkYZebHLCBiEyOcRMG10gKWMiZoiFUC6FaMKudaGUUQYxy0B80DHE wMvQMs3cAcYmECVDrI+4gGLznc8UU0wohNgSckHPGHOLK9XpoocnRQUDCy5PFwQLncpwyWYoZ7zS rUDLuGJtQ64q8vJAhoTBh9MEMTMMSJC8aq8Xfuj/YggfjkhSSDDKBCpMJF4AovPOA5fS9Yl8TPIQ SBc3e0spcjjSqUC5EOKInnysIYguiwCyVB50zAF6KYkMdAspcjziy9EHLYMKpI8PNMslQL9t4uV8 8OHKMs7AAkYYpJzSiyuSIrXqMsP4gkopc4RByDPHFIP5I3RDZDsftdAOkSzq+u56KZCcIogtxRhS yC1DI/SMMtKrWckppEAyu1zf15I72vd6yCDWsDbzGaMYmOCbLNAlEHTwYx/70Mc98KEPfvhDIPY5 Bh66EIlhmIt/t6PF/4JzrIcYohIYMh/njCELTGzCTv24RzzYAY992GMd62DHOtphj34MJBR2GJ4x /862s1SEYRIjnMUqeiQj8aHqcn+AX5j8cY92sKMd7aihPuDRjnjEg4vrsMcFkbKMQrCBFfF7SCwq wQkiAsCNB8FFLEbYr1NkbhgN1Mc7aPhFeMTjHfZ4oD32wQ992COLPnwjIMIACTxahxlprBsr6OWQ QczBbb6bSPBUIZN08EMe64CHPOIxSHzcQx/7yIc9TDkPCOaQHwJJBCTScApmROQZX2sjQkIRuYfk gRApfJssMDcuAPRjH/jAByjlwQ9+2AOV8eiiDuWxj37YQx3t8OEzUjGHR6ilXZXogiRspgs8MFGF DHEGKwDHCoFYk5T8wMcgZXhFeWBRlM/Uhz7jof+OeKCDK6Wg5eIWIhtzwhEioRDP22wXhtYAwB/z 0CE8UNkPfezQHvaQhz4D6Ux4BHKLg0zHTNLQyIgsY6AEWQYnONaQwzjybbFIi0D2wQ551AMe8LhH FeGRj2OKkR/z0Ck81hEPVEIwm1yxwyVs+RCdCGJNBrmFHCTnkFWcIpjsWkYxmAqAe6yDgjO8Ij7i iY95xIMfVcxhPMzKw2OuQx9oMwYzDkqQYfAhDSo7yO56h86GYKIP7QQAOm6oD2vOwx73eCA8+KjR Qn5RHvOAxzseuI55/DMrJXGITuQACagahK4EiZITYdQTgTjjGKhlxhm8wBuBeFUeyeRHP/DxxXj/ yGOU7bhHBA0pynjQYx87vSAwvgAGUJwWNPAxEACYkQyZHIMVo+ADKtwoCk5Q0lZraJ0sEsGYZ8xi P8vAlItwcQpVHAMXqKBFLWiRikQoolD8yKEo57FPUd72tvGo7Gy7qFF7eBEePlSGK/Swilqcoha1 cMUzpgOLSwB2JcEjRa0OYqzYOIQThXDFlUiBCmLI4hWSoA4spGUiPXhhDrnQwxrSwAe5qSIaBcEH DtfRT9q24774/aoz3XFbs3rRHYl8xjDYIDc5hGEQzTADaynhBUwsww5eIMU3EzILQ7SOTcctxjC4 dAxd3IJm4jWRLAhxidMUghKVsIQpRiGICaej/6I6TeY8rEjDxU7UH/2YM35tG00fLgMTkaAFISpB iUG8whmJsIOENoGhUGgiFKBF6CtG+6KaxVUXy0DGI+QQWIKk49PoQAeebdgO+uIjgjak4X3z244L 4mJIvWCKMXSR3Lm+cSCgFcUmrssQSszBs7rCRST44AuHoOOYwJVHTSMYzSzOI6j/DMWjftEkXpri IRj2iH0YmCliRMIRxX4IOiL6Di4WdoKGRCUsATCMb1MbSLpYokmZQW+5BnsSfOBFRPhxRbPKA7GE lOc8EgmMUTwiLuYLhStyEd6G60oXgwiDCCNiUXb8eK32VMc9BqKKMPhhwjHy25Vbygdgo+oZeP9Y QyUoPZB06MOKOLWiOsIoUoFgQgyD4KqPbsGHQDxkE6lghO+KwYoJWSeG8sApPOjBj5oLRBa94LWP dJGJcxKUT5H2kX2WAQusmQjP/ejHP3F9C4U6idsMWYQraEbvZtjaUPFmhSbUQIdiOMkYbeB01h0i 8ofYQQ1mc0ZQ6AikZahCDn5IxR9MQXjrtMoRo6BOtUvoEFdcwmC60okj5GAKyBQDFwHz0TJk0SE/ EEzqlQYGS2W0dx/hQQ5yoIXRE+GHUzReYH+glyY2XYqXsisWmwg9qsIlCaM/wxAsvkqMWOGIMDzl GKt4RBgAYfcY5QITU2aIIORgtqC4HUa6cIX/L1jBin91fxVrD4bRny4Jzrri7daJBSTExSTo94ES OneRVEvxkFfcAReCxwzfxz+rUAgdsmmhoid0QAyvEAZ9gHkE8TqOkDzvAzOlwAejwGuzUnaFgHoR oWsj1yzFMAde8Aq4AAh0EAkqSAd1oGVgQH0I4QujECqxVzkKoQuUEAaa0y3OQAldQAmtByOg8Aq3 pxC5cAuyUAhVAgDJgAzDcAvDIAwY8gzCQAxERAykMAq7MIN85RCzMCScdDOGUAZ5EIQE0XcOYQp5 4SJN0Qeu4AzQYIZP921bOAra0hDLQAy44ArdIxHNIIc/JAcTU3moAD9BwQxFiEHrlAbK9yKI/9IH n1MJELgQm7AbgAgRs8AKCOcQAUhvypB/N3gYpVB9MPJc5TWJCnF8XtAGiXgoWXcLRGgifgJulwg1 AxFe8OEMTHUM9MYMuoALxEAMu/Zw6PcQb4ArJhIMkOd7P7IMrEALpWA2q1AKBXIJpUAL2AgJfdAK tQgRt6AGFtYQr4AJJiF4q7J17UFEz8AJmQNyMcIMqPAIaRAGhcAMbtAFm7AMfyA3wSM3meAt9oJJ bAKMqzAJl6CHsDAIlnALwgCKAnELkFBMQLIKnxMJhQBpr3AGHvEKhGAJvWALthCLfZUQnsAKt8AM noAJryBXuGAIjCY2EoELqAgjs6CGtDAMIf9zKRgUXqARSZmiC5hwh73WFxiEdQe1DMEgGE1SDJHg fOziDdYwDuEgDtbQDeZgDtYQlecwDtwwDXxwbQ7xCqswkw2RCGGwBibnIi/RZs1yDt+wDdsgDuHg DdtgDeAADtewDd8QDt9wDdfACfwSJzHzBkLXJMxQDJxwBu/hCbbwL75gC6uwQIkQmS8SDt3QDeLg Dd9wDgAQDuBADgJBDuAQDp0JDuYQEZ5wCMVgIKflkwmBiF7iDHXQBarADIDgBcGjJ2FgCLnQBl7Q TnJoDdXADRBhDEH5EJQgB28ogMrwh5rlCpP2JMdXB99hRqVwnX/QBomgC2fQBsFwC4ZAihD/kZWk +RC6gSwOkQjs80at2X+xk5YwwifLgAv0CYyruVwntUhTERHjIA784wqrJyPO4goYWECiFwwsQlfa IwepEBHkwA3jYB2lNReaIHwQ8QqQ544v4gyqEF2Q0IUI8Tp8UCkPwQ3V4J8RMQuFAKIK8QZqQEnb 1n8Z2iSwAAmOsAuRg1UGoQupwAeQYHULAZXgIBehAI4PoQi2cJLMCX8LgaGjoKEuwgqPoIWOEEUK kSdygAosF5pDyj+eAJ+j4gxiChoP0Rx8wIwwcgt0OAqkoAqv4JDPQAheEAnr9xDkMA6caSivYAsk FhG4IAh20KeH4gp5Uwuo0Ad0UAu+EAw4/wkAwHAK3GUIaNoQ3XANERoRuWAJX+EQ7RegEKEMKBWf tjAJDfIHaSAHPgoGeMAMptAFhOCaDcEN23Cp3thLDgELeWChD2EMtpCPT6JV8EEMJOEHm5dzr2AG iQCI4+AN5ek9AQQRuoiIQQGrBfEKXiAHcNIkvMgnUgMMvpAjcViZzXonnmAIxCCAbmcMibgIdkAI ZPkihqCddyIO3TCuDsEyefAQ21dAexcN0OAleAAGenAn1jCrRDoH6NkQsAAwJuI3dfKrxrClclGp Xeo9sACl8uMir/CeT9Jl3agQ4ECr35J1sGALAHiIrUigT/okrFAKnXAn31AO1pGpm9oQb/8gBoFH b63opBjrIrYwCogQJwVbsd44B4IQaZ7ACboaljPaJOCwDdVgDfb6I09rDSZyDO91cq4AeZ/QJONQ DdqgDdmwDVNbmZm5mbpieaHKEM3RCNbgDaCJDdywl3zZDeBwDuTQDXvplt0QoXnrDeYQDuPQDduQ DdpQDdSgDXYLoeHwt6RJr37rDYALAFzpn3NplQDQDdVwDaDpIrmAClvhEMkZeIO3q5dwB3m5l3R5 DXdZsHv5lpZKDgXLDeYAu+MADrIatoerDdTwtttgt7ArDrK7DdxADuLgl8Irq8U7DnkpvJUqsjDj CD7nELewCScrgA6ZEII3Dt8AmuTgDeL/cA5T2b0AQA7fIJeC+w1Dar5yeQ7gIA7bQA2Ga7jd8L13 aw7iIA7msJXqew61277g4A13O777W7ZyoSBysW17xwh3gAet2BBPmw2Gew0GPJKVR45Jcq1gah3g MA3SMA0VbD6MQAg1O5SB6RCygApL8SR7QAZoYMEFYSxuoEabIBJiSjwQ0QwP/BBdRq3mcwxb9hCX gq7N8IlQMhQ7/BCLoAgSiyqo9RB6cHlFmXWukAZz0LMuwgxlAAY2aD6ycAokyhAuesINobJYfLWY YIAw3CcI+xChEAxJLBA8KyaopQue8K4vc16FycOk8woneQzGsB/0RkRzHCecsAZ3sMYR/7EJGYYL vTAKhbiHpVALsRAMS/sMKjupQAIKduAWmNZXsjAIT5GGwnNeVIOIucCoupALNvMKLLbB8QkmstAG hdDEDCEvqnDGZxE4DwEKnBDHSIEJToYqs4wToXAJDsI1y0UM5cEMAJghYvOL8CHNSBEMkhAqbVAd LMQ5p1IMC3QMsQDLokcMhaMrzyCTAGALafAVecAGrZMHYGAXq8AGboMJ9AwAeNAGkGZGGGIIkLiF I8ow0fIXbSALzmAGZSB0e4dhewwRnEAHhGDLu3IJGpEH8hoHbYA1hnDP+ew2cKDPzlAIBQ0AhkAH NzqDmCDQIkIIdcAIB+0GpFEJeGCMav8gkFiWB1/wB2uLKsugDOVxDOaiVc8zREhRzieVXNYcPJNQ HT0tEMxA1M3QDACwCG1ACOb5pjyZE8SiXG9UM/O5CRUCDMKgyL+DCoXYELnRxbXzCqmQCqqgCqlw CcVwDJtwCaIwEZagCtMTBnSgy2TtI7lQCaHbEDG1acGzeWqwCsoABl7gCcXQBvzIB3PQeX+NKotA B4PwENxUCqaAjbRACqWgHm7CJagA2rSACq+wtJUtnbggnguRUOrai7pga0yBNrqAaRK92nIxoUL8 sbrdJLpACGWAxwbBCYAQgr+NTjh4GRCxCm6Y3DBMPns3CyfJ29D9MsuwCYYg0dxZhtf//TaO8ghq rRChAAZvcI7ffXK4ABmu0ArAbC+3cAyvYAgyEV5OHTKwiZ/3LRCf/Az53d8ALhNFUR5RUx7OoAsE HrFvRNRd9tMMzuC0BiC2Bsjw4bFIEeG1feEAMAttgH8/gndgUAzLQAgRHadAMeLHoQtK8QyiUAkp nQuDMNOhPNMwfhWh/BWh4BVcQQmbIBuC4BaxQAkDewuBYDaeUAd68QqC0DqJEAj0ouT/wQmCkB+c QAkFsgmC0M+BYBGGQAmLcHyDQGuFEAiMIApvQAiqfcCvADS6wAasCA1t0Aa5oAttUAZYAQmxkQvm PZ9gYAZnMQZ2wBVgENHlfQYAAAtj/2DoigAGhVA8YAAHAKAHYzDTiTAGV6EHYGAWhjAG+RoHY9Dj hgAGrXMHY9A6eFDqz+Az/0EIY+A2ZzAGWHMGYPDldkAH/yF4n6KH8EGf9kGfb6SHAuFh9kEMdocz djcWxU4MJrEMNgIgOePsy34LlLEMt8Ao1C4TzFDtSHEL2M7tVEEzGQLuUrMqxRDf314eR1geruHb 6d3u7v7u8B7v8j7v9F7v9v4yWwAFUSAECqAQWlAFRfAEXOAiXEABOZAAALAFA88QWGAFQSADLAAE CIAQWMAERKAEWGAQXNAADbDwCpEATOAEWhAjWtAEQXACGuABUXAQWPAEFZADHqABKf+wBAaBABcg 8AmvEEYgAxOABfuOAQmRAElQATfAAiDAARzgARZQEFrwBEQAASGgASCQBAaRATTQAlbAEEggAihw AQpgBUTgBFtgHU0AAxoQAjAgBBNvEE0gAxqgARugAj3QAAbhBA6QAxNvARGwAEx/BTRfBT/gBC5g AkaAEFvwAx7wAS1gAzegAxJQBQhPEBlwAxvw9iXwAEBvEDjQAUggEArgBAow9gXxBCJAAlJABW4P A/0eEfkuBDzQA0tP8RNAAh2gAyOPED2wA1CwADhgAjRPEApQAyvQABLQA1AQBBJw+waxADFQAkXA AC5AA0eQ+QXBBRbAAhyQA9RvEED/QAJLgAVHsAMucANPIBBcMPJbUAQgwAJJoAAwoAIPsPYR0QBJ oAU3QAJXoARL4PECARBYIsSA0AAAFAZcACxk6AMHkAcEK1hRuJDLkA0uXECoMQMJQ5ALFxRpkOCC jxshVmAICYBLkhk3WDKAoiWkFh0edOy4cYNDhyQLEVQIwsOBhhsApDxw0tKpUy4TPFCRsoFEiRsK Fm5ZqATCER0wHqhYESTBQixPhJCF4AAFDxg9bDLMMOIEBBgynrb8IcRFjQ4nWIZcoEMIEAcP3OrQ CmCBkQcjPJQgQcOGhxxZ0EpwESPngy1P9o4GmYNDDxceUMyQgGXrAiYSduwgoUHE/wkSMhceiZG3 xQsWLWT4aBIyAwQlQmz4uCCk4l4hNEak0DAkJAImRnbooB5CRYkXTbkUyWtDhAMWIT54mBCyikEj Vp48YcCVtFMFRTpwcMEiR2OQlrCBhcRoIAEIDJxwwjUAmIhAiR4+0OADB3IIwoLntliCByN6cKIH B26wb68GYGAhhhGqCAmKBwi0IbIdoHCiCc22cMIIBXw4bQcRvFOxpQSY4KEFEVaIgsH7GOLiCBM8 eIAqGYowAkkAFCBCiCSwkGAFCpx6ogcTOPCABRmO4AECDKBwTQsqIDABBgCCCGGK0RA4y4gf8nrg gSoqwuKCII5owImynGIAgg5CSP9iCRNUIOIpI2aYAS8NakAgSZC2gOIH0SyowYEeSJgBiqekQIHO kBiooQYfZpCBBgiKQCCDIHy4tIEpgkDBAS2CAMGIvSy4IYolrshhgwdg0MA5p5Q4oYeWnHghNxaO 7EEIIn4AAgkqofChBiUk4CCC5zB1iYpvZ/jBBicg0ACHp4QgQYqWEDhCChpwiEICC3wgagQgFMoR OB6SyMEBHWwqd6EKbtCBhyGKXOAFEZhwagsqSOChJW8nMMK/IXK4YYUPrLogpB5AuIIGE5oyV8kL OsoBAhfeqyGHuULSoYMInirCgxka0IILC9bVwSAAbISAhxspqEKGHwCgEq0FqmD/wgcPkqiCgyBG zDQCDnxoiQstGrDhAw6jmKACCXrwMCQhdhCCAx2mNpeLBBCYogMTMnAMioW1kAAEESx4CgsiMLSo gZpCwkKLshWKogUIlniKqwkggIBCv8cu4gQO2oNKiBuUILsiLrjwGoMcYCD8x5eBFEKIOmXYoAa7 Y29JCx86kAHAm7ZAYIQPDHdKCwg2aGGBvbBQYGGnFrCAggmugF73rUgr2nLsSUMgAiGAd2qKPi9/ Agjju1d/ffZ197p9+OOXf37667f/fvzz139//vvnHwvN+E+AAxzNBXZwlidIgQdUIOBzGhAFl7HP CRY4y/qw4ITrmUsKI9CBDcKE/xTxkUYLRrhBDxKQBQW8jzTjsYEVABCxIyxgCbl7SupCMoERECGD SUoADlQAO0xpQQFMiMIDWqAaF9jgWke41Msi0AHloaAGpLobDTQQhAbIwAZTcFUE76OFHTANC1yp wgYmsEPSOOEGGjhB58yFBI7cAAg5IAELaODFl2EhCCLQwAZM0APmmcsIHujADyLAgwlIYQpEaGKS tnADFOgACAaxAAhOFrst4MoBIECb7pxQhAs0gQq+CgEEKhg7KsyABB54QREahykFbMkEPoCAD6yw E+wdAQY4yIEFLhAFELgQk0YQAQ0mkAIJqA8BPoiBB2igBOxJgAU1iMIMfHBKTP89QWQzUgELdDCE K6jwPgmAwQeW9oIoiECYscuADnQQhRXg8WVLIkEIepADHCguSVGhgRQWgAMTvMABqApiSQBABRtw UAJGyBkPjWCDDZRgCXuUwAgYqDsuVIAELYiBfbZgQ3NhIQoxWIEEkheDAN4HAUCwwQ9oEIIb7MAD N6DhaKBQtI18YAXYvI8VThCCFJDJCLYsQRLEKcIIyKAHMqggFpowGExxwQkPEEEQkseDhpImA0LA QQ9+4IMdoOABKY0qFXigAxc4IAUExVQDImAFJHTAAU7YwhZMMAU0PmUBEPiBAm4ALKkl7mVbwAIQ esSBlXTvCDRggQj+ozssrKX/Ax+gXfci4AEcJEEzKPhBVu/DBSS44AmFfcAToGAEHIgOUwuQwANS YIIaWOCoK6TA0koAAzc6sgFHuMEMYoCDGAQBAzV9ihasIAUHuMBiLfCBZ0VYgZ4BoAk4gAFJdWMu BhCBCDTQQSOxZ1YL0MABxTGX3h5AhCfcoF8eMIENWmOuuUTBBBUAgAOE4NzRbIGsTgjCO5F2t4Xk 4AHexR4TdMCBFlARU1hgQlOo4ABgBYEEIKjBf1+2hCdYIIez7d8FVJADnmJvAizYAXGbp4MQFEEk TmgAh0mDAw+Ql4AgAUIIpJBXTCHAxHvRwhF6ANX2jZLAM3ZCBUI4YyQnWclL/2Zyk538ZCirjwtK OIJFGDBc3T2BoSKBwpCj7D8uCIEFTZjCS0MQBd1RoAVGKMIDTtCBEs8TCkhYAo4vlgUGaKEJQbik +hJQhB8wEXtbSIAVJDADD7SABCRIQQyigN+QELYJRsgBCFZgghHsCpAv69UHSlCrKByZx0JwQBEq sAEYQHovGUDAS3DwAg5soAc7do8UdFADGagABEpNiOqS9AQJ8OAGjAVBYpQwNDuDhAtEKEEfOSAD Bf86TG/1gF5OZ64J+IAKNRCBFE6gAR2QNUkU0MEPKrCEH3Tgw6puSRLCGAFgk2AEMZBnkhQQBRd0 AAQ3mAADXpaFGmhgBwCwQP+1j+ADHaTvPhgYzpAgGoMQm6sBOpABB2gQ7TwGwQYdYIHCzZXeFtCg BdCKXa8srgUM6CgELigBC1SbpCPkYAQrIEEH1ok9BvRABAeawhFEXacInAAE3yRCfaK6hBzUgAoS eIESgXifJHSgBFm4wA9Mo4JtvdJcOEhUCn6AASYsAeOYSoAPSuCACLguarGLygpOEIWzZSbHPZiB ESLWghl04AHJfmFlhMCEKvxATDewGDt/UAOx7sAFkpkB9hZQTRYg4QEC190IcVCCbGlgBrQGgBaS AAHfxuAHEsYB5wHAgA/pBQA+gAFrArnPLGhhAZ+f+QvS2oIHdA8BOPiAC0L/UIJ6J8kHIFi8B5Dg 4hVd4EavLoEpYzeBHVThqUaIwBHGvpfHtC0HOQgBDmLYeXZfbAEVsAEn14q9P+lglSLoAd9DUgTg foAGr3dkuyCwAx9MYeMu8LJTslCFCGABCHCCFhCCgeiBn8uvJgACHnABpnA/hsCAKfiBF4gt02sJ IoAAC5gBFwi+vUAAGYAACXAAK+ABDXCBCzyCEEABKWCBH7ACGdAAucAeBGAAJlgO9cGCBViAHEiY 9VEACviBE3AA0bgbT0mCBLgBG2i2yjKXJYAAITgwCJA9HagACASJJoiBgVufLKABEGMf3tmAGEjA lgiNCxgaI9CBIJACIEsSVC24FCtQgftyiStkCAXIgQ94OewBAg/ggQt8igZAAiaAwBERIuRLo4ir PAoYMPZJggcovC+LREmcREqsREu8REzMRE3cRE7sRE/8RFAMRVEcRfYJCAA7 --=====_002_next=====-- --=====_001_next=====-- From nobody Fri Feb 21 04:47:32 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7271200BA; Fri, 21 Feb 2020 04:47:30 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 OHGgsYb1PtlJ; Fri, 21 Feb 2020 04:47:22 -0800 (PST) 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 1CE941200D6; Fri, 21 Feb 2020 04:47:21 -0800 (PST) Received: by mail-ed1-x532.google.com with SMTP id c26so2168408eds.8; Fri, 21 Feb 2020 04:47:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=UX/F0RX2w53CjID7c44a8QPrvsNqYqUUQmMXk/ruZhE=; b=nglEJQvqUfYVRZ5NPb0IDqmUKyQ8xtLzbwNDCXacNZd3TF+hKOQHm7eDzDXEPPFeqk XyUpI9kqeN6nkcIFB4dWyCfUHDTriFVWE/AyPzEgQHK6AJwlvmSPSQWOk93tzYVA8kS4 RBNt2s79vIG5XG2sl7GT6yN+x+ZafkDfECtA69sOqCQFJN2m6fCMwrt32NQAjDGmclMj 6hiLR+SxNm1M7LtHGUI82/KUsd5W81Bxr4NE0nI/9fdLKOAdrbf9sXqlaBnBBipey97U nB/sgknrWWh45BIWWoAwviEBcqsgXm5tCTTYgf1VCjffXFXBmQYAr+JEpU/v1WPqOJah Hncw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=UX/F0RX2w53CjID7c44a8QPrvsNqYqUUQmMXk/ruZhE=; b=IZ4Z9MPzfHY4siTxqq8o45PBnheVfNRTu2gBwwS0l3DfL85Tj5WKpdjptKES7j3pVx 8oZ4dU2itBlSMX++1NQPMAQ2jneq44EqfyUi5g5EMMKQSD6QL9FgAc635PXfpM17Fxt9 pTMuIbAwa7fDvi3QSLOcHqVFqPGqf/A6p3aMiOOVbdFn0fFtcQKvkgFKUK5Pga02A0U9 spe+4IM6cy+cIh55QwqcaVyqpwnKV8w7fBgYPENkP+kOiA5XJzyVM7efN9KrFyhn/jZe DRmSX4lGn5/uNVXCGzecZlBcX1hLPoQV6UhlQVA25HIdgkUN2hMH+J35gr3g81mQk939 B89w== X-Gm-Message-State: APjAAAVqUOsSap5ehY9ZhKqEiZZIqU8ka/I1donSpRY8kPCUxkhuZJJd YR+zbCuxhhu3E5wDSDOgHSVrwE8foZxFv78udRmGOxoI X-Google-Smtp-Source: APXvYqy4BWvLLRnRBarko+FJXdW/5A4sGcXiZtknr3j5+7tVhxm6Vgawhd99EkKkmgZYYL/MNdMmWaxMhcHCBw0ig54= X-Received: by 2002:a17:906:1cd0:: with SMTP id i16mr33026694ejh.186.1582289235441; Fri, 21 Feb 2020 04:47:15 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 21 Feb 2020 04:47:14 -0800 From: Alvaro Retana MIME-Version: 1.0 Date: Fri, 21 Feb 2020 04:47:14 -0800 Message-ID: To: "draft-ietf-idr-tunnel-encaps@ietf.org" Cc: John Scudder , idr-chairs@ietf.org, "idr@ietf. org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 12:47:31 -0000 Dear authors: Here is my review of draft-ietf-idr-tunnel-encaps-15. =C2=A0Thank you for all the work that you and the WG have put into it. While this is a good document, I do have a significant number of comments (see details in-line below). =C2=A0I want to highlight a few of them up front. I will wait for the major issues to be addressed before starting the IETF L= C. Thanks!! Alvaro. (1) Obsoleting other work This document deprecates the Encapsulation SAFI because it "has never been used in production". =C2=A0What about other work that specifies the use of the Encapsulation SAFI? =C2=A0Should they also be Obsoleted by this document? =C2=A0[Yes, I know there was a long discussion on the list, which resulted in the text in =C2=A71.4.] Both rfc5566 (mentioned in =C2=A71.4) and rfc5640 specify the use of the Encapsulation SAFI. =C2=A0Is there interest in Updating those RFCs? =C2=A0I= f not, then it seems like the easy thing to do is to Obsolete that work with this document. =C2=A0If there is, then I agree with the text in =C2=A7= 1.4 in that the effort would be out of scope of this document. =C2=A0In either case, I think that =C2=A71.4 raises more questions than it answers and is not needed in this document. John: As Shepherd, can you please ping the WG (you may have to reach out to bess as well) about potential interest in Updating rfc5566/rfc5640. =C2=A0I won't hold this document waiting for the resolution, but having an idea of any interest would be nice. Interest has been expressed for rfc5566bis [1], but didn't see anything related to rfc5640. =C2=A0BTW, the mailing list contains discussion about other IPsec-related drafts that use tunnel-encap; I'm not sure of their relationship (if any) to rfc5566. [1] https://mailarchive.ietf.org/arch/msg/idr/yuIXr3HpPEp7v_k08XpdhXRN6GM (2) Underspecification. A big part of this document is dedicated to specifying sub-TLVs...but in none of those descriptions is the Type of the sub-TLV indicated! Please add all the basic description of a sub-TLV in one place, and don't force the user to search for the types elsewhere: in the IANA Considerations sometimes, but in the registry in others. =C2=A0Please don't forget that this document Obsoletes rfc5512, so anything that was specified there needs to be re-specified here. (3) Use of Normative Language. While using rfc2119 keywords is not always necessary, they help clarify the behavior required for interoperability. =C2=A0Cases where the keywords are not used (e.g. rfc8200) often result in multiple interpretations. =C2=A0This document is inconsistent in the use of Normative Language: it is used sometimes, but not always. =C2=A0Please be consistent! =C2=A0Recommendation: use it! =C2=A0I pointed out some cases, b= ut the whole document would benefit from a re-read. (4) Use Cases rfc5512 gave an overview of the use case (mostly intra-AS), but this document doesn't mention use cases either as an introduction to the problem being solved or in the form of Operational Considerations. Sections 9 and 10 would be a good start for that type of section, but having a general description of the problem upfront (in the Introduction maybe) would be ideal. =C2=A0Again, because this document Obsoletes rfc5512, then we can't really rely on the information there. I'm looking for a few paragraphs, mostly directed at readers that may not be familiar with rfc5512 and the potential applications. (5) When does an IP address "belong" to an AS? =C2=A73.1 uses this condition as a way to determine if the Tunnel Endpoint sub-TLV is malformed: =C2=A0 =C2=A0o =C2=A0It can be determined that the IP address in the sub-TL= V's address =C2=A0 =C2=A0 =C2=A0 subfield does not belong to the non-zero AS whose numb= er is in the =C2=A0 =C2=A0 =C2=A0 its Autonomous System subfield. =C2=A0(See section Sec= tion 13 for =C2=A0 =C2=A0 =C2=A0 discussion of one way to determine this.) IOW, for the Tunnel Endpoint sub-TLV to be formed correctly the IP address has to "belong" to the AS listed. =C2=A713 (Security Considerations) is very tentative about how to determine if an IP address "belongs" to the AS listed. =C2=A0In fact, the text there starts by suggesting that "BGP Origin Validation [RFC6811] can be used to obtain assurance that the given IP address belongs to the given AS", but after pointing at some flaws concludes that: =C2=A0 =C2=A0For these reasons, BGP Origin Validation should not be relied = upon =C2=A0 =C2=A0exclusively, and the filtering procedures of Section 10 should= always =C2=A0 =C2=A0be in place. =C2=A710 (Scoping) says that "any BGP speaker that understands the attribute MUST be able to filter the attribute from incoming/outgoing BGP UPDATE messages"...but it doesn't say anything about the topic of "belonging", or what these filters should consider when active. Presumably, the filters can be used to avoid receiving Tunnel Endpoint sub-TLV with IP addresses that don't belong to the AS listed...but that is not mentioned anywhere, much less which would be the criteria to make that filtering decision. The effect of the above is that the document doesn't really specify how to determine that the Tunnel Endpoint sub-TLV is not malformed. My suggestion is to not make "belonging" part of the criteria for a well-formed sub-TLV. =C2=A0The validity of the address in terms of "belonging" is important and should be highlighted as it is in =C2=A713. Consider a stronger requirement for using Origin Validation (SHOULD ?). =C2=A0Also, the deployment models (and use cases, as mentioned above), including the "well-defined scope" from =C2=A710 should be clear throughout. [Line numbers from idnits.] ... 13 Abstract 15 =C2=A0 RFC 5512 defines a BGP Path Attribute known as the "Tunnel 16 =C2=A0 Encapsulation Attribute". =C2=A0This attribute allows one to spe= cify a set 17 =C2=A0 of tunnels. =C2=A0For each such tunnel, the attribute can provid= e the 18 =C2=A0 information needed to create the tunnel and the corresponding 19 =C2=A0 encapsulation header. =C2=A0The attribute can also provide infor= mation 20 =C2=A0 that aids in choosing whether a particular packet is to be sent 21 =C2=A0 through a particular tunnel. =C2=A0RFC 5512 states that the attr= ibute is 22 =C2=A0 only carried in BGP UPDATEs that have the "Encapsulation Subsequ= ent 23 =C2=A0 Address Family (Encapsulation SAFI)". =C2=A0This document deprec= ates the 24 =C2=A0 Encapsulation SAFI (which has never been used in production), an= d 25 =C2=A0 specifies semantics for the attribute when it is carried in UPDA= TEs 26 =C2=A0 of certain other SAFIs. =C2=A0This document adds support for add= itional 27 =C2=A0 tunnel types, and allows a remote tunnel endpoint address to be 28 =C2=A0 specified for each tunnel. =C2=A0This document also provides sup= port for 29 =C2=A0 specifying fields of any inner or outer encapsulations that may = be 30 =C2=A0 used by a particular tunnel. [nit] s/that have the "Encapsulation/that use the "Encapsulation ... 142 1.1. =C2=A0Brief Summary of RFC 5512 ... 161 =C2=A0 o =C2=A0BGP speaker R1 has received and installed UPDATE U; [minor] To be consistent with rfc4271: s/installed UPDATE U/selected UPDATE U for local use ... 171 =C2=A0 o =C2=A0R1's best path to D is a BGP route that has R2 as its n= ext hop; [minor] rfc4271 consistency: s/best path/best route/g ... 179 1.2. =C2=A0Deficiencies in RFC 5512 ... 191 =C2=A0 o =C2=A0There is no way to use the Tunnel Encapsulation attribu= te to 192 =C2=A0 =C2=A0 =C2=A0specify the tunnel egress endpoint address of a gi= ven tunnel; 193 =C2=A0 =C2=A0 =C2=A0[RFC5512] assumes that the tunnel egress endpoint = of each tunnel 194 =C2=A0 =C2=A0 =C2=A0is specified as the NLRI of an UPDATE of the Encap= sulation-SAFI. [nit] s/Encapsulation-SAFI/Encapsulation SAFI ... 209 1.3. =C2=A0Brief Summary of Changes from RFC 5512 [minor] It would be very nice if forward references were provided below -- to the section where the changes/enhancements are specified. 211 =C2=A0 In this document we address these deficiencies by: [style nit] Please don't write in first person. =C2=A0Instead: "This document addresses these deficiencies by:". =C2=A0There is similar text in other places. ... 233 =C2=A0 One of the sub-TLVs defined in [RFC5512] is the "Encapsulation = sub- 234 =C2=A0 TLV". =C2=A0For a given tunnel, the encapsulation sub-TLV speci= fies some 235 =C2=A0 of the information needed to construct the encapsulation header= used 236 =C2=A0 when sending packets through that tunnel. =C2=A0This document d= efines 237 =C2=A0 encapsulation sub-TLVs for a number of tunnel types not discuss= ed in 238 =C2=A0 [RFC5512]: VXLAN (Virtual Extensible Local Area Network, [RFC73= 48]), 239 =C2=A0 VXLAN-GPE (Generic Protocol Extension for VXLAN, 240 =C2=A0 [I-D.ietf-nvo3-vxlan-gpe]), NVGRE (Network Virtualization Using 241 =C2=A0 Generic Routing Encapsulation [RFC7637]), and MPLS-in-GRE (MPLS= in 242 =C2=A0 Generic Routing Encapsulation [RFC2784], [RFC2890], [RFC4023]). 243 =C2=A0 MPLS-in-UDP [RFC7510] is also supported, but an Encapsulation s= ub-TLV 244 =C2=A0 for it is not needed. [nit] s/encapsulation sub-TLV/Encapsulation sub-TLV/g ... 265 =C2=A0 [RFC5512] defines a Tunnel Encapsulation Extended Community, th= at can 266 =C2=A0 be used instead of the Tunnel Encapsulation attribute under cer= tain 267 =C2=A0 circumstances. =C2=A0This document addresses the issue of how t= o handle a 268 =C2=A0 BGP UPDATE that carries both a Tunnel Encapsulation attribute a= nd one 269 =C2=A0 or more Tunnel Encapsulation Extended Communities. [nit] s/Community, that/Community that 271 1.4. =C2=A0Impact on RFC 5566 273 =C2=A0 [RFC5566] uses the mechanisms defined in [RFC5512]. =C2=A0While= this 274 =C2=A0 document obsoletes [RFC5512], it does not address the issue of = how to 275 =C2=A0 use the mechanisms of [RFC5566] without also using the Encapsul= ation 276 =C2=A0 SAFI. =C2=A0Those issues are considered to be outside the scope= of this 277 =C2=A0 document. [major] See my related comments up front. =C2=A0This section is not needed. 279 2. =C2=A0The Tunnel Encapsulation Attribute ... 287 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3 288 =C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 7 8 9 0 1 289 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ 290 =C2=A0 =C2=A0 | =C2=A0 =C2=A0Tunnel Type (2 Octets) =C2=A0 =C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0Length (2 Octets) =C2=A0 =C2=A0 =C2=A0| 291 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ 292 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | 293 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Value =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 | 294 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | 295 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ 297 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 1: Tunnel Encap= sulation TLV Value Field [minor] This TLV is called the Tunnel TLV all over the text...except here, where it is not given a name in the description text. =C2=A0Note that besides the title of the figure above, "Tunnel Encapsulation TLV" is used in one other place too... 299 =C2=A0 o =C2=A0Tunnel Type (2 octets): identifies a type of tunnel. = =C2=A0The field 300 =C2=A0 =C2=A0 =C2=A0contains values from the IANA Registry "BGP Tunnel= Encapsulation 301 =C2=A0 =C2=A0 =C2=A0Attribute Tunnel Types". 303 =C2=A0 =C2=A0 =C2=A0Note that for tunnel types whose names are of the = form "X-in-Y", 304 =C2=A0 =C2=A0 =C2=A0e.g., "MPLS-in-GRE", only packets of the specified= payload type 305 =C2=A0 =C2=A0 =C2=A0"X" are to be carried through the tunnel of type "= Y". =C2=A0This is the 306 =C2=A0 =C2=A0 =C2=A0equivalent of specifying a tunnel type "Y" and inc= luding in its 307 =C2=A0 =C2=A0 =C2=A0TLV a Protocol Type sub-TLV (see Section 3.4.1) sp= ecifying 308 =C2=A0 =C2=A0 =C2=A0protocol "X". =C2=A0If the tunnel type is "X-in-Y"= , it is unnecessary, 309 =C2=A0 =C2=A0 =C2=A0though harmless, to include a Protocol Type sub-TL= V specifying 310 =C2=A0 =C2=A0 =C2=A0"X". [minor] This is a good paragraph, but it may be more relevant in =C2=A73.4.= 1. [major] "...only packets of the specified payload type "X" are to be carried through the tunnel of type "Y"." =C2=A0Is this intended to be a Normative statement? =C2=A0Note that =C2=A73.4.1 says that the "protocol ty= pe sub-TLV...indicate the type of the payload packets that may be encapsulated with the tunnel parameters that are being signaled in the TLV." =C2=A0 In neither case are rfc2119 keywords used, but given that both mechanisms are intended to be equivalent, it would be great if the text was also equivalent. [major] rfc5512 said that "Unknown types are to be ignored and skipped upon receipt." =C2=A0Is that still the case? ... 320 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+= --------------------------------+ 321 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= Sub-TLV Type (1 Octet) =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 322 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+= --------------------------------+ 323 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= Sub-TLV Length (1 or 2 Octets) | 324 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+= --------------------------------+ 325 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|= Sub-TLV Value (Variable) =C2=A0 =C2=A0 =C2=A0 | 326 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+= --------------------------------+ 328 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Table 1: Tunnel Encap= sulation Sub-TLV Format [minor] s/Table 1/Figure 2 =C2=A0 Please renumber the other Figures. 330 =C2=A0 o =C2=A0Sub-TLV Type (1 octet): each sub-TLV type defines a cer= tain 331 =C2=A0 =C2=A0 =C2=A0property about the tunnel TLV that contains this s= ub-TLV. [major] Does this text from rfc5512 apply? =C2=A0 =C2=A0When the TLV is being processed by a BGP speaker that will be =C2=A0 =C2=A0performing encapsulation, any unknown sub-TLVs MUST be ignored= and =C2=A0 =C2=A0skipped. =C2=A0However, if the TLV is understood, the entire T= LV MUST =C2=A0 =C2=A0NOT be ignored just because it contains an unknown sub-TLV. This text uses rfc2119 keywords, but the text about unknown TLVs (above, also from rfc5512) doesn't. =C2=A0If adding the text back in, please be consistent on the wording. ... 348 3.1. =C2=A0The Tunnel Endpoint Sub-TLV [major] The Type of this sub-TLV is not specified anywhere. =C2=A0Note that =C2=A712.4 talks about "Tunnel Egress Endpoint"...the names are obviously inconsistent. :-( [major] The length of a sub-TLV is specified above, but it would be ideal if a general statement for *this* sub-TLV was made; something along the lines of "the length MUST be 6 + length of the AF...". This would make the specification of the sub-TLV being malformed easier to do later (and for future extensions). 350 =C2=A0 The Tunnel Endpoint sub-TLV specifies the address of the endpoi= nt of 351 =C2=A0 the tunnel, that is, the address of the router that will decaps= ulate 352 =C2=A0 the payload. =C2=A0It is a sub-TLV whose value field contains t= hree sub- 353 =C2=A0 fields: [nit] "sub-field" is used here (and in a couple of other places), but "subfield" is used the most. =C2=A0Please be consistent. ... 359 =C2=A0 3. =C2=A0an address sub-field, whose length depends upon the Ad= dress 360 =C2=A0 =C2=A0 =C2=A0 Family. [nit] s/address/Address/g =C2=A0 Capitalize to denote the name of the field, and not simply an address. 362 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3 363 =C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 7 8 9 0 1 364 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ 365 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0Autonomous System Number =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | 366 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ 367 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0Address Family =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Address =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ~ 368 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 + 369 =C2=A0 =C2=A0 ~ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 ~ 370 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 | 371 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ 373 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 2: Tunnel Endp= oint Sub-TLV Value Field [minor] Please reorder the text below to specify the fields in order. [suggestion] Some parts of the text talk about a "tunnel endpoint address", but it may not be obvious to everyone that the Address field of the Tunnel Endpoint sub-TLV is that "tunnel endpoint address". Suggestion: rename the field to "Tunnel Endpoint Address". 375 =C2=A0 The Address Family subfield contains a value from IANA's "Addre= ss 376 =C2=A0 Family Numbers" registry. =C2=A0In this document, we assume tha= t the 377 =C2=A0 Address Family is either IPv4 or IPv6; use of other address fam= ilies 378 =C2=A0 is outside the scope of this document. [major] Given that EVPN (AFI/SAFI 25/70) is valid according to =C2=A75, and this document assumes only IPv4/IPv6, does that mean that the tunnel endpoint cannot be a MAC address, ESI, etc..? =C2=A0That is not specified anywhere. =C2=A0 [Warning: my EVPN is rusty.] [major] Because there are special considerations depending on the AF, consider adding something along the lines of: "Documents specifying the use of other AFs are expected to..." [major] If only IPv4/IPv6 are in scope, what should a receiver do if another AF is received? =C2=A0Should the sub-TLV be considered malformed? 380 =C2=A0 If the Address Family subfield contains the value for IPv4, the 381 =C2=A0 address subfield must contain an IPv4 address (a /32 IPv4 prefi= x). [major] s/must/MUST ?? 383 =C2=A0 In this case, the length field of Tunnel Endpoint sub-TLV must 384 =C2=A0 contain the value 10 (0xa). [major] s/must/MUST ?? 386 =C2=A0 If the Address Family subfield contains the value for IPv6, the 387 =C2=A0 address sub-field must contain an IPv6 address (a /128 IPv6 pre= fix). 388 =C2=A0 In this case, the length field of Tunnel Endpoint sub-TLV must 389 =C2=A0 contain the value 22 (0x16). =C2=A0IPv6 link local addresses ar= e not valid 390 =C2=A0 values of the IP address field. [major] s/must/MUST ?? [major] What if a link local address is received? 392 =C2=A0 In a given BGP UPDATE, the address family (IPv4 or IPv6) of a T= unnel 393 =C2=A0 Endpoint sub-TLV is independent of the address family of the UP= DATE 394 =C2=A0 itself. =C2=A0For example, an UPDATE whose NLRI is an IPv4 addr= ess may 395 =C2=A0 have a Tunnel Encapsulation attribute containing Tunnel Endpoin= t sub- 396 =C2=A0 TLVs that contain IPv6 addresses. =C2=A0Also, different tunnels 397 =C2=A0 represented in the Tunnel Encapsulation attribute may have Tunn= el 398 =C2=A0 Endpoints of different address families. [nit] In this case "Tunnel Endpoints" is used to refer to the Address field in the sub-TLV, which is described as "the address of the endpoint of the tunnel" (in the first paragraph of this section). This section mostly used "address" to refer to the same field, which is called Address anyway. =C2=A0Please be consistent. =C2=A0I would prefer = it if s/Tunnel Endpoint/address of the endpoint of the tunnel -- if you rather use "Tunnel Endpoint", then perhaps consider changing the name of the field. ... 404 =C2=A0 The AS number in the sub-TLV MUST be the number of the AS to wh= ich 405 =C2=A0 the IP address in the sub-TLV belongs. [major] What if it doesn't? =C2=A0What does "belong" mean? =C2=A0Please put= a forward reference to =C2=A713. [major] Should the UPDATE with the Tunnel Encapsulation Attribute be originated by the same AS that originated the route to the destination reflected in the Address field? =C2=A0Should the UPDATE with the Tunnel Encapsulation Attribute be originated by the same ASN in this sub-TLV? =C2=A0Are there valid cases where other ASes would/should originate a Tunnel Encapsulation Attribute used to send traffic somewhere else? 407 =C2=A0 There is one special case: the Tunnel Endpoint sub-TLV MAY have= a 408 =C2=A0 value field whose Address Family subfield contains 0. =C2=A0Thi= s means 409 =C2=A0 that the tunnel's egress endpoint is the UPDATE's BGP next hop.= =C2=A0If 410 =C2=A0 the Address Family subfield contains 0, the Address subfield is 411 =C2=A0 omitted, and the Autonomous System number field is set to 0. [major] rfc4271/rfc4760 consistency: s/UPDATE's BGP next hop/address of the next hop [minor] To keep consistent with the text above, please specify the length (= 6). [major] Why isn't the ASN kept to indicate the AS to which the address in the NEXT_HOP belongs to? =C2=A0I ask mostly because the specification above about the ASN says that it "MUST be the number of the AS...", which implies that there are no exceptions. =C2=A0If at this point (assuming implementations) the ASN has to be 0, then please use "SHOULD" in the initial specification. 413 =C2=A0 If any of the following conditions hold, the Tunnel Endpoint su= b-TLV 414 =C2=A0 is considered to be "malformed": 416 =C2=A0 o =C2=A0The sub-TLV contains the value for IPv4 in its Address = Family 417 =C2=A0 =C2=A0 =C2=A0subfield, but the length of the sub-TLV's value fi= eld is other 418 =C2=A0 =C2=A0 =C2=A0than 10 (0xa). 420 =C2=A0 o =C2=A0The sub-TLV contains the value for IPv6 in its Address = Family 421 =C2=A0 =C2=A0 =C2=A0subfield, but the length of the sub-TLV's value fi= eld is other 422 =C2=A0 =C2=A0 =C2=A0than 22 (0x16). 424 =C2=A0 o =C2=A0The sub-TLV contains the value zero in its Address Fami= ly field, 425 =C2=A0 =C2=A0 =C2=A0but the length of the sub-TLV's value field is oth= er than 6, or 426 =C2=A0 =C2=A0 =C2=A0the Autonomous System subfield is not set to zero. [minor] Is there any way to generalize these conditions? =C2=A0If general, then we don't need to worry about future AFs clearly specifying what a malformed sub-TLV is. Suggestion> =C2=A0 =C2=A0...the Length of the sub-TLV is not 6 + the length of the AF..= .as specified =C2=A0 =C2=A0above. 428 =C2=A0 o =C2=A0The IP address in the sub-TLV's address subfield is not= a valid IP 429 =C2=A0 =C2=A0 =C2=A0address (e.g., it's an IPv4 broadcast address). [major] What is a "valid IP address"? =C2=A0The text above says that link-local are not allowed...and that a host address is expected...and that the address must "belong"...now you added broadcast addresses. Anything else? =C2=A0Is a multicast destination "valid"? =C2=A0Is there a reference that can be added here to avoid having to define it? 431 =C2=A0 o =C2=A0It can be determined that the IP address in the sub-TLV= 's address 432 =C2=A0 =C2=A0 =C2=A0subfield does not belong to the non-zero AS whose = number is in the 433 =C2=A0 =C2=A0 =C2=A0its Autonomous System subfield. =C2=A0(See section= Section 13 for 434 =C2=A0 =C2=A0 =C2=A0discussion of one way to determine this.) [major] "one way" =C2=A0I hope that it is the MTI way -- otherwise, the determination of the sub-TLV being malformed is not deterministic. 436 =C2=A0 If the Tunnel Endpoint sub-TLV is malformed, the TLV containing= it is 437 =C2=A0 also considered to be malformed, and the entire TLV MUST be ign= ored. 438 =C2=A0 However, the Tunnel Encapsulation attribute MUST NOT be conside= red to 439 =C2=A0 be malformed in this case; other TLVs in the attribute MUST be 440 =C2=A0 processed (if they can be parsed correctly). [major] "sub-TLV is malformed, the TLV containing it is also considered to be malformed, and the entire TLV MUST be ignored." =C2=A0=C2= =A711 adds: "the entire TLV MUST be ignored, and MUST be removed from the Tunnel Encapsulation attribute". =C2=A0Please specify things only once! Instead of specifying what to do in this section, put a reference to =C2=A711 and take care of it there. 442 =C2=A0 When redistributing a route that is carrying a Tunnel Encapsula= tion 443 =C2=A0 attribute containing a TLV that itself contains a malformed Tun= nel 444 =C2=A0 Endpoint sub-TLV, the TLV MUST be removed from the attribute be= fore 445 =C2=A0 redistribution. [minor] This paragraph seems to say the same thing as =C2=A711, but please take it out and specify things only once. [nit] rfc4271 consistency =C2=A0s/redistribute/distribute/g 447 =C2=A0 See Section 11 for further discussion of how to handle errors t= hat 448 =C2=A0 are encountered when parsing the Tunnel Encapsulation attribute= . NEW> =C2=A0 =C2=A0Error Handling is detailed in Section 11. ... 454 3.2. =C2=A0Encapsulation Sub-TLVs for Particular Tunnel Types 456 =C2=A0 This section defines Tunnel Encapsulation sub-TLVs for the foll= owing 457 =C2=A0 tunnel types: VXLAN ([RFC7348]), VXLAN-GPE 458 =C2=A0 ([I-D.ietf-nvo3-vxlan-gpe]), NVGRE ([RFC7637]), MPLS-in-GRE 459 =C2=A0 ([RFC2784], [RFC2890], [RFC4023]), L2TPv3 ([RFC3931]), and GRE 460 =C2=A0 ([RFC2784], [RFC2890], [RFC4023]). [minor] The sub-TLV is called "Tunnel Encapsulation" here, but simply "Encapsulation" almost everywhere else. =C2=A0Please be consistent. [minor] It looks like the only reference for MPLS-in-GRE should be rfc4023...which should then not be a reference for GRE. ... 465 =C2=A0 There are also tunnel types for which it is not necessary to de= fine 466 =C2=A0 an Encapsulation sub-TLV, because there are no fields in the 467 =C2=A0 encapsulation header whose values need to be signaled from the = tunnel 468 =C2=A0 egress endpoint. [minor] If I'm following...all Encapsulation sub-TLVs have the same Type; the indication of the encapsulation itself is indicated by the Tunnel Type of the TLV, right? =C2=A0Please remind people at this point of that fact. [major] The Type of this sub-TLV is not specified anywhere. 470 3.2.1. =C2=A0VXLAN [major] The Length of this version of the sub-TLV is fixed, please indicate so in this section. 472 =C2=A0 This document defines an encapsulation sub-TLV for VXLAN tunnel= s. 473 =C2=A0 When the tunnel type is VXLAN, the following is the structure o= f the 474 =C2=A0 value field in the encapsulation sub-TLV: [nit] "When the tunnel type is VXLAN..." It would be nice to remind the reader what the value is. =C2=A0If you add the value here, please do so in the other sections as well. 476 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3 477 =C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 7 8 9 0 1 478 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ 479 =C2=A0 =C2=A0 |V|M|R|R|R|R|R|R| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0VN-I= D (3 Octets) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 | 480 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ 481 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 MAC Address (4 Octets) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 482 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ 483 =C2=A0 =C2=A0 | =C2=A0MAC Address (2 Octets) =C2=A0 =C2=A0 =C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Reserved =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 | 484 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ 486 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure = 3: VXLAN Encapsulation Sub-TLV 488 =C2=A0 =C2=A0 =C2=A0V: This bit is set to 1 to indicate that a "valid"= VN-ID (Virtual 489 =C2=A0 =C2=A0 =C2=A0Network Identifier) is present in the encapsulatio= n sub-TLV. 490 =C2=A0 =C2=A0 =C2=A0Please see Section 8. [minor] The use of "valid" (specially as above in quotations) is misleading/confusing as the validity (as in the VN-ID being correct, etc.) is not guaranteed. =C2=A0It seems to me that, at best, this bit is simply indicating the fact that the sender intended to include a VN-ID (vs some random bits). 492 =C2=A0 =C2=A0 =C2=A0M: This bit is set to 1 to indicate that a valid M= AC Address is 493 =C2=A0 =C2=A0 =C2=A0present in the encapsulation sub-TLV. [minor] The use of "valid" is misleading/confusing as the validity (as in the MAC address being correct, or even existing!) is not guaranteed. =C2=A0It seems to me that, at best, this bit is simply indicating the fact that the sender intended to include a MAC address (vs some random bits). [major] It is not clear to me whether setting both the V and M bits is a valid configuration. ... 501 =C2=A0 =C2=A0 =C2=A0VN-ID: If the V bit is set, the VN-id field contai= ns a 3 octet VN- 502 =C2=A0 =C2=A0 =C2=A0ID value. =C2=A0If the V bit is not set, the VN-id= field MUST be set to 503 =C2=A0 =C2=A0 =C2=A0zero. [nit] s/VN-id/VN-ID/g [minor] "MUST be set to zero." =C2=A0 To avoid errors, add "...and ignored by the receiver." 505 =C2=A0 =C2=A0 =C2=A0MAC Address: If the M bit is set, this field conta= ins a 6 octet 506 =C2=A0 =C2=A0 =C2=A0Ethernet MAC address. =C2=A0If the M bit is not se= t, this field MUST be 507 =C2=A0 =C2=A0 =C2=A0set to all zeroes. [minor] "MUST be set to all zeroes." =C2=A0 To avoid errors, add "...and ignored by the receiver." ... 529 =C2=A0 o =C2=A0See Section 8 to see how the VNI field of the VXLAN enc= apsulation 530 =C2=A0 =C2=A0 =C2=A0header is set. [minor] Suggestion> =C2=A0 =C2=A0Section 8 describes how the VNI field of the VXLAN encapsulati= on header is =C2=A0 =C2=A0set. ... 538 3.2.2. =C2=A0VXLAN-GPE [major] The Length of this version of the sub-TLV is fixed, please indicate so in this section. 540 =C2=A0 This document defines an encapsulation sub-TLV for VXLAN tunnel= s. 541 =C2=A0 When the tunnel type is VXLAN-GPE, the following is the structu= re of 542 =C2=A0 the value field in the encapsulation sub-TLV: [minor] s/VXLAN tunnels/VXLAN-GPE tunnels 544 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3 545 =C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 7 8 9 0 1 546 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ 547 =C2=A0 =C2=A0 |Ver|V|R|R|R|R|R| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Reserved =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0| 548 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ 549 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 VN-ID =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | =C2=A0 Reserved =C2=A0 =C2=A0| 550 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ 552 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure 4: VXLA= N GPE Encapsulation Sub-TLV [minor] Most of the document uses "VXLAN-GPE". =C2=A0Please be consistent with the form used in I-D.ietf-nvo3-vxlan-gpe. [minor] Please explain the content of the fields in order. 554 =C2=A0 =C2=A0 =C2=A0V: This bit is set to 1 to indicate that a "valid"= VN-ID is 555 =C2=A0 =C2=A0 =C2=A0present in the encapsulation sub-TLV. =C2=A0Please= see Section 8. [minor] The use of "valid" (specially as above in quotations) is misleading/confusing as the validity (as in the VN-ID being correct, etc.) is not guaranteed. =C2=A0It seems to me that, at best, this bit is simply indicating the fact that the sender intended to include a VN-ID (vs some random bits). ... 570 =C2=A0 =C2=A0 =C2=A0VN-ID: If the V bit is set, this field contains a = 3 octet VN-ID 571 =C2=A0 =C2=A0 =C2=A0value. =C2=A0If the V bit is not set, this field M= UST be set to zero. [minor] "MUST be set to zero." =C2=A0 To avoid errors, add "...and ignored by the receiver." [major] The Reserved field is not described. ... 580 =C2=A0 o =C2=A0See Section 8 to see how the VNI field of the VXLAN-GPE 581 =C2=A0 =C2=A0 =C2=A0encapsulation header is set. [minor] Suggestion> =C2=A0 =C2=A0Section 8 describes how the VNI field of the VXLAN-GPE encapsu= lation header =C2=A0 =C2=A0is set. 583 3.2.3. =C2=A0NVGRE [major] The Length of this version of the sub-TLV is fixed, please indicate so in this section. ... 589 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3 590 =C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 7 8 9 0 1 591 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ 592 =C2=A0 =C2=A0 |V|M|R|R|R|R|R|R| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0VN-I= D (3 Octets) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 | 593 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ 594 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 MAC Address (4 Octets) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 595 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ 596 =C2=A0 =C2=A0 | =C2=A0MAC Address (2 Octets) =C2=A0 =C2=A0 =C2=A0 | = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Reserved =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| 597 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ 599 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Figure = 5: NVGRE Encapsulation Sub-TLV 601 =C2=A0 =C2=A0 =C2=A0V: This bit is set to 1 to indicate that a "valid"= VN-ID is 602 =C2=A0 =C2=A0 =C2=A0present in the encapsulation sub-TLV. =C2=A0Please= see Section 8. [minor] The use of "valid" (specially as above in quotations) is misleading/confusing as the validity (as in the VN-ID being correct, etc.) is not guaranteed. =C2=A0It seems to me that, at best, this bit is simply indicating the fact that the sender intended to include a VN-ID (vs some random bits). 604 =C2=A0 =C2=A0 =C2=A0M: This bit is set to 1 to indicate that a valid M= AC Address is 605 =C2=A0 =C2=A0 =C2=A0present in the encapsulation sub-TLV. [minor] The use of "valid" is misleading/confusing as the validity (as in the MAC address being correct, or even existing!) is not guaranteed. =C2=A0It seems to me that, at best, this bit is simply indicating the fact that the sender intended to include a MAC address (vs some random bits). [major] It is not clear to me whether setting both the V and M bits is a valid configuration. ... 613 =C2=A0 =C2=A0 =C2=A0VN-ID: If the V bit is set, the VN-id field contai= ns a 3 octet VN- 614 =C2=A0 =C2=A0 =C2=A0ID value. =C2=A0If the V bit is not set, the VN-id= field MUST be set to 615 =C2=A0 =C2=A0 =C2=A0zero. [minor] "MUST be set to zero." =C2=A0 To avoid errors, add "...and ignored by the receiver." 617 =C2=A0 =C2=A0 =C2=A0MAC Address: If the M bit is set, this field conta= ins a 6 octet 618 =C2=A0 =C2=A0 =C2=A0Ethernet MAC address. =C2=A0If the M bit is not se= t, this field MUST be 619 =C2=A0 =C2=A0 =C2=A0set to all zeroes. [minor] "MUST be set to all zeroes." =C2=A0 To avoid errors, add "...and ignored by the receiver." ... 641 =C2=A0 o =C2=A0See Section 8 to see how the VSID (Virtual Subnet Ident= ifier) 642 =C2=A0 =C2=A0 =C2=A0field of the NVGRE encapsulation header is set. [minor] Suggestion> =C2=A0 =C2=A0Section 8 describes how the VSID (Virtual Subnet Identifier) f= ield of the =C2=A0 =C2=A0NVGRE encapsulation header is set. 644 3.2.4. =C2=A0L2TPv3 [major] The Length of this version of the sub-TLV is not fixed but known (4-12), please indicate so in this section. ... 671 =C2=A0 =C2=A0 =C2=A0The length of the cookie is not encoded explicitly= , but can be 672 =C2=A0 =C2=A0 =C2=A0calculated as (sub-TLV length - 4). 674 3.2.5. =C2=A0GRE [major] The Length of this version of the sub-TLV is fixed, please indicate so in this section. ... 687 =C2=A0 =C2=A0 =C2=A0GRE Key: 4-octet field [RFC2890] that is generated= by the 688 =C2=A0 =C2=A0 =C2=A0advertising router. =C2=A0The actual method by whi= ch the key is 689 =C2=A0 =C2=A0 =C2=A0obtained is beyond the scope of this document. =C2= =A0The key is 690 =C2=A0 =C2=A0 =C2=A0inserted into the GRE encapsulation header of the = payload packets 691 =C2=A0 =C2=A0 =C2=A0sent by ingress routers to the advertising router.= =C2=A0It is intended 692 =C2=A0 =C2=A0 =C2=A0to be used for identifying extra context informati= on about the 693 =C2=A0 =C2=A0 =C2=A0received payload. [minor] "The actual method by which the key is obtained is beyond the scope of this document." =C2=A0That is a true statement, but I think that the right thing to do here is to simply point at rfc2890 and leave the burden there (I know that document says that it is out of scope too). ... 698 3.2.6. =C2=A0MPLS-in-GRE [major] The Length of this version of the sub-TLV is fixed, please indicate so in this section. ... 711 =C2=A0 =C2=A0 =C2=A0GRE-Key: 4-octet field [RFC2890] that is generated= by the 712 =C2=A0 =C2=A0 =C2=A0advertising router. =C2=A0The actual method by whi= ch the key is 713 =C2=A0 =C2=A0 =C2=A0obtained is beyond the scope of this document. =C2= =A0The key is 714 =C2=A0 =C2=A0 =C2=A0inserted into the GRE encapsulation header of the = payload packets 715 =C2=A0 =C2=A0 =C2=A0sent by ingress routers to the advertising router.= =C2=A0It is intended 716 =C2=A0 =C2=A0 =C2=A0to be used for identifying extra context informati= on about the 717 =C2=A0 =C2=A0 =C2=A0received payload. =C2=A0Note that the key is optio= nal. =C2=A0Unless a key 718 =C2=A0 =C2=A0 =C2=A0value is being advertised, the MPLS-in-GRE encapsu= lation sub-TLV 719 =C2=A0 =C2=A0 =C2=A0MUST NOT be present. [minor] "The actual method by which the key is obtained is beyond the scope of this document." =C2=A0That is a true statement, but I think that the right thing to do here is to simply point at rfc2890 and leave the burden there (I know that document says that it is out of scope too). 721 =C2=A0 Note that the GRE tunnel type defined in Section 3.2.5 can be u= sed 722 =C2=A0 instead of the MPLS-in-GRE tunnel type when it is necessary to 723 =C2=A0 encapsulate MPLS in GRE. =C2=A0Including a TLV of the MPLS-in-G= RE tunnel 724 =C2=A0 type is equivalent to including a TLV of the GRE tunnel type th= at 725 =C2=A0 also includes a Protocol Type sub-TLV (Section 3.4.1) specifyin= g MPLS 726 =C2=A0 as the protocol to be encapsulated. =C2=A0That is, if a TLV spe= cifies 727 =C2=A0 MPLS-in-GRE or if it includes a Protocol Type sub-TLV specifyin= g 728 =C2=A0 MPLS, the GRE tunnel advertised in that TLV MUST NOT be used fo= r 729 =C2=A0 carrying IP packets. [major] "...if it includes a Protocol Type sub-TLV specifying MPLS, the GRE tunnel...MUST NOT be used for carrying IP packets." =C2=A0The example in =C2=A73.4.1 is along the same lines as this phrase (3 TLVs, 1 Protocol Type sub-TLV in each, 3 tunnels); but =C2=A711 says that this sub-TLV "may appear zero or more times in a given Tunnel TLV". =C2=A0IOW, a second Protocol Type sub-TLV could indicate IP. =C2=A0Which one is correct? ... 735 3.2.7. =C2=A0IP-in-IP 737 =C2=A0 When the tunnel type of the TLV is IP-in-IP, it does not have V= irtual 738 =C2=A0 Network Identifier. =C2=A0See for Section 8.1 Embedded Label ha= ndling on 739 =C2=A0 IP-in-IP tunnels. [nit] s/have Virtual Network Identifier/have a Virtual Network Identifier [] This sub-section seems to be out of place: =C2=A73.2 defines the Tunnel Encapsulation sub-TLVs, but the IP-in-IP encapsulation doesn't seem to need one (?). =C2=A0Also, I'm not sure what the paragraph is about anyway... 741 3.3. =C2=A0Outer Encapsulation Sub-TLVs ... 753 =C2=A0 If an outer encapsulation sub-TLV occurs in a TLV for a tunnel = type 754 =C2=A0 that does not use the corresponding outer encapsulation, the su= b-TLV 755 =C2=A0 is treated as if it were an unknown type of sub-TLV. [major] Should this behavior be Normative? 757 3.3.1. =C2=A0IPv4 DS Field 759 =C2=A0 Most of the tunnel types that can be specified in the Tunnel 760 =C2=A0 Encapsulation attribute require an outer IP encapsulation. =C2= =A0The IPv4 761 =C2=A0 Differentiated Services (DS) Field sub-TLV can be carried in th= e TLV 762 =C2=A0 of any such tunnel type. =C2=A0It specifies the setting of the = one-octet 763 =C2=A0 Differentiated Services field in the outer IP encapsulation (se= e 764 =C2=A0 [RFC2474]). =C2=A0The value field is always a single octet. [major] What is the type?? [major] What about IPv6? =C2=A0Can this same sub-TLV be used in the IPv6 case? =C2=A0It would need to be renamed... =C2=A0Note that rfc2474 is appli= cable to both. =C2=A0[This point is bound to be noticed by other IESG members.] [] Note also that draft-ietf-ospf-encapsulation-cap, which specifies the same functionality as this document for OSPF (both OSPFv2 and OSPFv3), relies heavily on the sub-TLVs defined here, including this one...which seems to be expected to be used for both IPv4/IPv6 endpoints. 766 3.3.2. =C2=A0UDP Destination Port 768 =C2=A0 Some of the tunnel types that can be specified in the Tunnel 769 =C2=A0 Encapsulation attribute require an outer UDP encapsulation. 770 =C2=A0 Generally there is a standard UDP Destination Port value for a 771 =C2=A0 particular tunnel type. =C2=A0However, sometimes it is useful t= o be able 772 =C2=A0 to use a non-standard UDP destination port. =C2=A0If a particul= ar tunnel 773 =C2=A0 type requires an outer UDP encapsulation, and it is desired to = use a 774 =C2=A0 UDP destination port other than the standard one, the port to b= e used 775 =C2=A0 can be specified by including a UDP Destination Port sub-TLV. = =C2=A0The 776 =C2=A0 value field of this sub-TLV is always a two-octet field, contai= ning 777 =C2=A0 the port value. [major] What is the type?? ... 781 3.4.1. =C2=A0Protocol Type Sub-TLV [major] What is the type?? 783 =C2=A0 The protocol type sub-TLV MAY be included in a given TLV to ind= icate 784 =C2=A0 the type of the payload packets that may be encapsulated with t= he 785 =C2=A0 tunnel parameters that are being signaled in the TLV. =C2=A0The= value 786 =C2=A0 field of the sub-TLV contains a 2-octet value from IANA's ether= type 787 =C2=A0 registry [Ethertypes]. [minor] The name of the registry is "ETHER TYPES" (written in all caps). ... 801 3.4.2. =C2=A0Color Sub-TLV [major] What is the type?? 803 =C2=A0 The color sub-TLV MAY be encoded as a way to "color" the 804 =C2=A0 corresponding tunnel TLV. =C2=A0The value field of the sub-TLV = is eight 805 =C2=A0 octets long, and consists of a Color Extended Community, as def= ined 806 =C2=A0 in Section 4.3. =C2=A0For the use of this sub-TLV and Extended = Community, 807 =C2=A0 please see Section 7. [major] s/color sub-TLV MAY be encoded/color sub-TLV MAY be used 809 =C2=A0 Note that the high-order octet of this sub-TLV's value field MU= ST be 810 =C2=A0 set to 3, and the next octet MUST be set to 0x0b. =C2=A0(Otherw= ise the 811 =C2=A0 value field is not identical to a Color Extended Community.) [minor] The first paragraph already says that the "value field of the sub-TLV is eight octets long, and consists of a Color Extended Community"; it is not necessary to repeat the value of the first two octets because they area defined in =C2=A74.3. 813 =C2=A0 If a Color sub-TLV is not of the proper length, or the first tw= o 814 =C2=A0 octets of its value field are not 0x030b, the sub-TLV should be 815 =C2=A0 treated as if it were an unrecognized sub-TLV (see Section 11). [minor] "is not of the proper length" =C2=A0Do you mean that the Length field of the sub-TLV and the actual length of the Value fields don't match, or that the Length field is set to anything else besides 8? Please be specific. [major] In either case, do you trust the Length field, or how do you know where the sub-TLV ends so it can be ignored? =C2=A0See the comments in =C2=A711. 817 3.5. =C2=A0Embedded Label Handling Sub-TLV ... 831 =C2=A0 Suppose a Tunnel Encapsulation attribute is attached to an UPDA= TE of 832 =C2=A0 an embedded address family, and it is decided to use a particul= ar 833 =C2=A0 tunnel (specified in one of the attribute's TLVs) for transmitt= ing a 834 =C2=A0 packet that is being forwarded according to that UPDATE. =C2=A0= When 835 =C2=A0 forming the encapsulation header for that packet, different 836 =C2=A0 deployment scenarios require different handling of the embedded= label 837 =C2=A0 and/or the virtual network identifier. =C2=A0The Embedded Label= Handling 838 =C2=A0 sub-TLV can be used to control the placement of the embedded la= bel 839 =C2=A0 and/or the virtual network identifier in the encapsulation. [minor] s/embedded address family/labeled address family 841 =C2=A0 The Embedded Label Handling sub-TLV may be included in any TLV = of the 842 =C2=A0 Tunnel Encapsulation attribute. =C2=A0If the Tunnel Encapsulati= on 843 =C2=A0 attribute is attached to an UPDATE of a non-labeled address fam= ily, 844 =C2=A0 the sub-TLV is treated as a no-op. =C2=A0If the sub-TLV is cont= ained in a 845 =C2=A0 TLV whose tunnel type does not have a virtual network identifie= r in 846 =C2=A0 its encapsulation header, the sub-TLV is treated as a no-op. = =C2=A0In 847 =C2=A0 those cases where the sub-TLV is treated as a no-op, it SHOULD = NOT be 848 =C2=A0 stripped from the TLV before the UPDATE is forwarded. [minor] s/treated as a no-op/ignored/g =C2=A0(It may be clearer.) [major] What is the type? ... 864 3.6. =C2=A0MPLS Label Stack Sub-TLV 866 =C2=A0 This sub-TLV allows an MPLS label stack ([RFC3032]) to be assoc= iated 867 =C2=A0 with a particular tunnel. [major] What is the type? 869 =C2=A0 The value field of this sub-TLV is a sequence of MPLS label sta= ck 870 =C2=A0 entries. =C2=A0The first entry in the sequence is the "topmost"= label, the 871 =C2=A0 final entry in the sequence is the "bottommost" label. =C2=A0Wh= en this 872 =C2=A0 label stack is pushed onto a packet, this ordering MUST be pres= erved. [minor] "topmost" and "bottommost" are not mentioned in rfc3032. Please be consistent with the terminology. =C2=A0It is ok to introduce new terminology, if needed, but please explain that as well. 874 =C2=A0 Each label stack entry has the following format: 876 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3 877 =C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 = 5 6 7 8 9 0 1 878 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ 879 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Label =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = =C2=A0TC |S| =C2=A0 =C2=A0 =C2=A0TTL =C2=A0 =C2=A0 =C2=A0| 880 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+ 882 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0F= igure 9: MPLS Label Stack Sub-TLV [major] The fields of the sub-TLV are not explained...but the text below simply starts talking about them. =C2=A0I realize these fields are described elsewhere. =C2=A0Please include text pointing to where the fields are defined. =C2=A0Note that rfc3032/rfc5462 are used below, but it seems to me that the definition itself is done in rfc3270/rfc5129. =C2=A0These references should be Normative. 884 =C2=A0 If a packet is to be sent through the tunnel identified in a 885 =C2=A0 particular TLV, and if that TLV contains an MPLS Label Stack su= b-TLV, 886 =C2=A0 then the label stack appearing in the sub-TLV MUST be pushed on= to the 887 =C2=A0 packet. =C2=A0This label stack MUST be pushed onto the packet b= efore any 888 =C2=A0 other labels are pushed onto the packet. [minor] (redundant text) s/the label stack appearing in the sub-TLV MUST be pushed onto the packet. =C2=A0This label stack MUST be pushed onto the packet before any other labels are pushed onto the packet./the label stack appearing in the sub-TLV MUST be pushed onto the packet before any other labels are pushed onto the packet. ... 895 =C2=A0 If the MPLS label stack sub-TLV is included in a TLV identifyin= g a 896 =C2=A0 tunnel type that uses virtual network identifiers (see Section = 8), 897 =C2=A0 the contents of the MPLS label stack sub-TLV MUST be pushed ont= o the 898 =C2=A0 packet before the procedures of Section 8 are applied. [nit] s/MPLS label stack sub-TLV/MPLS Label Stack sub-TLV/g 900 =C2=A0 The number of label stack entries in the sub-TLV MUST be determ= ined 901 =C2=A0 from the sub-TLV length field. =C2=A0Thus it is not necessary t= o set the S 902 =C2=A0 bit in any of the label stack entries of the sub-TLV, and the s= etting 903 =C2=A0 of the S bit is ignored when parsing the sub-TLV. =C2=A0When th= e label 904 =C2=A0 stack entries are pushed onto a packet that already has a label 905 =C2=A0 stack, the S bits of all the entries MUST be cleared. =C2=A0Whe= n the label 906 =C2=A0 stack entries are pushed onto a packet that does not already ha= ve a 907 =C2=A0 label stack, the S bit of the bottommost label stack entry MUST= be 908 =C2=A0 set, and the S bit of all the other label stack entries MUST be 909 =C2=A0 cleared. [minor] This paragraph would ideally follow the description of the S bit. [major] "When the label stack entries are pushed onto a packet that already has a label stack, the S bits of all the entries MUST be cleared." =C2=A0I'm assuming you mean all entries from the sub-TLV, and not all entries in the resulting stack, right? =C2=A0I think that the text as is could be misinterpreted. 911 =C2=A0 By default, the TC (Traffic Class) field ([RFC3032], [RFC5462])= of 912 =C2=A0 each label stack entry is set to 0. =C2=A0This may of course be= changed by 913 =C2=A0 policy at the originator of the sub-TLV. =C2=A0When pushing the= label 914 =C2=A0 stack onto a packet, the TC of the label stack entries is prese= rved 915 =C2=A0 by default. =C2=A0However, local policy at the router that is p= ushing on 916 =C2=A0 the stack MAY cause modification of the TC values. [major] "([RFC3032], [RFC5462])" =C2=A0I think the correct references may be rfc3270/rfc5129, and should be Normative. [] While it is ok to not use rfc2119 keywords, the single use of "MAY" to indicate an option without similar language for the rest isn't great, specially starting with "by default". =C2=A0Consider something like this: Suggestion> =C2=A0 =C2=A0The TC (Traffic Class) field of each label stack entry SHOULD = be set to 0, =C2=A0 =C2=A0unless changed by policy at the originator of the sub-TLV. =C2= =A0When pushing the =C2=A0 =C2=A0label stack onto a packet, the TC of each label stack SHOULD b= e preserved, =C2=A0 =C2=A0unless local policy results in a modification. 918 =C2=A0 By default, the TTL (Time to Live) field of each label stack en= try is 919 =C2=A0 set to 255. =C2=A0This may be changed by policy at the originat= or of the 920 =C2=A0 sub-TLV. =C2=A0When pushing the label stack onto a packet, the = TTL of the 921 =C2=A0 label stack entries is preserved by default. =C2=A0However, loc= al policy 922 =C2=A0 at the router that is pushing on the stack MAY cause modificati= on of 923 =C2=A0 the TTL values. =C2=A0If any label stack entry in the sub-TLV h= as a TTL 924 =C2=A0 value of zero, the router that is pushing the stack on a packet= MUST 925 =C2=A0 change the value to a non-zero value. [] by default... Suggestion> =C2=A0 =C2=A0The TTL (Time to Live) field of each label stack entry SHOULD = be set to 255, =C2=A0 =C2=A0unless changed by policy at the originator of the sub-TLV. =C2= =A0When pushing the =C2=A0 =C2=A0label stack onto a packet, the TTL of each label stack entry S= HOULD be =C2=A0 =C2=A0preserved, unless local policy results in a modification. =C2= =A0If any label =C2=A0 =C2=A0stack entry has a TTL value of zero, the router that is pushin= g the stack on =C2=A0 =C2=A0a packet MUST change the value to a non-zero value. [major] "If any label stack entry in the sub-TLV has a TTL value of zero, the router that is pushing the stack on a packet MUST change the value to a non-zero value." =C2=A0From the rest of the paragraph, it could be concluded that the value SHOULD be 255 -- is that a proper conclusion? =C2=A0Given that local policy can change the value, is setting the TTL to 0 a valid policy? ... 934 3.7. =C2=A0Prefix-SID Sub-TLV ... 942 =C2=A0 In this document, we define a Prefix-SID sub-TLV. =C2=A0The val= ue field of 943 =C2=A0 the Prefix-SID sub-TLV can be set to any valid value of the val= ue 944 =C2=A0 field of a BGP Prefix-SID attribute, as defined in 945 =C2=A0 [I-D.ietf-idr-bgp-prefix-sid]. [major] "set to any valid value of the value field of a BGP Prefix-SID attribute" =C2=A0I read this phrase to mean that the contents of the sub-TLV are only valid in the same cases where the BGP Prefix-SID attribute would be. =C2=A0Is that the intent? =C2=A0If so, rfc8669 says tha= t the "BGP Prefix-SID attribute...can be attached to prefixes from Multiprotocol BGP IPv4/IPv6 Labeled Unicast...other Address Family Identifier (AFI) / Subsequent Address Family Identifier (SAFI) combinations is not defined herein but may be specified in future specifications", while this document mentions other AFI/SAFI combinations (in =C2=A75) as allowed to carry the BGP Tunnel Encapsulation attribute, and doesn't limit where this sub-TLV can exist (see the first sentence in the next paragraph)... =C2=A0If the Prefix-SID Sub-TLV is included in any AFI/SAFI other than IPv4/IPv6 Labeled Unicast, what action should the receiver take? 947 =C2=A0 The Prefix-SID sub-TLV can occur in a TLV identifying any type = of 948 =C2=A0 tunnel. =C2=A0If an Originator SRGB is specified in the sub-TLV= , that SRGB 949 =C2=A0 MUST be interpreted to be the SRGB used by the tunnel's egress 950 =C2=A0 endpoint. =C2=A0The Label-Index, if present, is the Segment Rou= ting SID 951 =C2=A0 that the tunnel's egress endpoint uses to represent the prefix 952 =C2=A0 appearing in the NLRI field of the BGP UPDATE to which the Tunn= el 953 =C2=A0 Encapsulation attribute is attached. [major] Except for the first sentence, this paragraph says the same thing as rfc8669. =C2=A0Please don't re-specify the behavior here (unless it changes, of course); instead, point at the source. 955 =C2=A0 If a Label-Index is present in the prefix-SID sub-TLV, then whe= n a 956 =C2=A0 packet is sent through the tunnel identified by the TLV, the 957 =C2=A0 corresponding MPLS label MUST be pushed on the packet's label s= tack. 958 =C2=A0 The corresponding MPLS label is computed from the Label-Index v= alue 959 =C2=A0 and the SRGB of the route's originator. [minor] Please point at rfc8669 as the place where the computation of the MPLS label is specified. 961 =C2=A0 If the Originator SRGB is not present, it is assumed that the 962 =C2=A0 originator's SRGB is known by other means. =C2=A0Such "other me= ans" are 963 =C2=A0 outside the scope of this document. [minor] This paragraph is part of what rfc8669 already specifies ("MAY contain the Originator SRGB TLV"), so it is not needed. 965 =C2=A0 The corresponding MPLS label is pushed on after the processing = of the 966 =C2=A0 MPLS Label Stack sub-TLV, if present, as specified in Section 3= .6. 967 =C2=A0 It is pushed on before any other labels (e.g., a label embedded= in 968 =C2=A0 UPDATE's NLRI, or a label determined by the procedures of Secti= on 8 969 =C2=A0 are pushed on the stack. [minor] It would be very nice to have an example of the most complex case. 971 =C2=A0 The Prefix-SID sub-TLV has slightly different semantics than th= e 972 =C2=A0 Prefix-SID attribute. =C2=A0When the Prefix-SID attribute is at= tached to a 973 =C2=A0 given route, the BGP speaker that originally attached the attri= bute 974 =C2=A0 is expected to be in the same Segment Routing domain as the BGP 975 =C2=A0 speakers who receive the route with the attached attribute. =C2= =A0The 976 =C2=A0 Label-Index tells the receiving BGP speakers that the prefix-SI= D is 977 =C2=A0 for the advertised prefix in that Segment Routing domain. =C2= =A0When the 978 =C2=A0 Prefix-SID sub-TLV is used, the BGP speaker at the head end of = the 979 =C2=A0 tunnel need even not be in the same Segment Routing Domain as t= he 980 =C2=A0 tunnel's egress endpoint, and there is no implication that the 981 =C2=A0 prefix-SID for the advertised prefix is the same in the Segment 982 =C2=A0 Routing domains of the BGP speaker that originated the sub-TLV = and 983 =C2=A0 the BGP speaker that received it. [minor] s/that the prefix-SID/what the prefix-SID [nit] s/the BGP speaker at the head end of the tunnel/the receiving BGP spe= aker This is the only place where "head end" is used. 985 4. =C2=A0Extended Communities Related to the Tunnel Encapsulation Attri= bute 987 4.1. =C2=A0Encapsulation Extended Community [major] Please indicate the Type/sub-type, format, etc. =C2=A0Keep in mind that this document is obsoleting rfc5512, so even if this community was defined there, it needs to be fully specified here as well. 989 =C2=A0 The Encapsulation Extended Community is a Transitive Opaque Ext= ended 990 =C2=A0 Community. =C2=A0This Extended Community may be attached to a r= oute of any 991 =C2=A0 AFI/SAFI to which the Tunnel Encapsulation attribute may be att= ached. 992 =C2=A0 Each such Extended Community identifies a particular tunnel typ= e. =C2=A0If 993 =C2=A0 the Encapsulation Extended Community identifies a particular tu= nnel 994 =C2=A0 type, its semantics are exactly equivalent to the semantics of = a 995 =C2=A0 Tunnel Encapsulation attribute Tunnel TLV for which the followi= ng 996 =C2=A0 three conditions all hold: [minor] (redundant text) s/Each such Extended Community identifies a particular tunnel type. =C2=A0If the Encapsulation Extended Community identifies a particular tunnel type,/Each such Extended Community identifies a particular tunnel type, [nit] "exactly equivalent" sounds redundant =C2=A0s/its semantics are exactly equivalent to/its semantics are the same as 998 =C2=A0 1. =C2=A0it identifies the same tunnel type, [nit] s/tunnel type/Tunnel Type ... 1004 =C2=A0 =C2=A0 =C2=A0 B. =C2=A0its "Address" subfield contains the sam= e IP address that 1005 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 appears in the next hop field of t= he route to which the 1006 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Tunnel Encapsulation attribute is = attached [major] rfc4271/rfc4760 consistency: s/same IP address that appears in the next hop field/address of the next hop 1008 =C2=A0 3. =C2=A0it has no other sub-TLVs. 1010 =C2=A0 We will refer to such a Tunnel TLV as a "barebones" Tunnel TLV= . 1012 =C2=A0 The Encapsulation Extended Community was first defined in [RFC= 5512]. 1013 =C2=A0 While it provides only a small subset of the functionality of = the 1014 =C2=A0 Tunnel Encapsulation attribute, it is used in a number of depl= oyed 1015 =C2=A0 applications, and is still needed for backwards compatibility.= =C2=A0To 1016 =C2=A0 ensure backwards compatibility, this specification establishes= the 1017 =C2=A0 following rules: 1019 =C2=A0 1. =C2=A0If the Tunnel Encapsulation attribute of a given rout= e contains a 1020 =C2=A0 =C2=A0 =C2=A0 barebones Tunnel TLV identifying a particular tu= nnel type, an 1021 =C2=A0 =C2=A0 =C2=A0 Encapsulation Extended Community identifying the= same tunnel type 1022 =C2=A0 =C2=A0 =C2=A0 SHOULD be attached to the route. 1024 =C2=A0 2. =C2=A0If the Encapsulation Extended Community identifying a= particular 1025 =C2=A0 =C2=A0 =C2=A0 tunnel type is attached to a given route, the co= rresponding 1026 =C2=A0 =C2=A0 =C2=A0 barebones Tunnel TLV MAY be omitted from the Tun= nel Encapsulation 1027 =C2=A0 =C2=A0 =C2=A0 attribute. 1029 =C2=A0 3. =C2=A0Suppose a particular route has both (a) an Encapsulat= ion Extended 1030 =C2=A0 =C2=A0 =C2=A0 Community specifying a particular tunnel type, a= nd (b) a Tunnel 1031 =C2=A0 =C2=A0 =C2=A0 Encapsulation attribute with a barebones Tunnel = TLV specifying 1032 =C2=A0 =C2=A0 =C2=A0 that same tunnel type. =C2=A0Both (a) and (b) MU= ST be interpreted as 1033 =C2=A0 =C2=A0 =C2=A0 denoting the same tunnel. [major] "MUST be interpreted" =C2=A0First of all, "interpreted" is not something that can be Normatively enforced. =C2=A0Second, what does that mean? =C2=A0I guess that the intent is that both community/TLV are expected to represent the same tunnel. =C2=A0Is that it? =C2=A0If so, then it seems = like an action that the sender should ensure -- what should the receiver do if it is not the case? =C2=A0 The next paragraph says that the community is preferred...so maybe that should be "3." and the text above should be taken out. 1035 =C2=A0 In short, in situations where one could use either the Encapsu= lation 1036 =C2=A0 Extended Community or a barebones Tunnel TLV, one may use eith= er or 1037 =C2=A0 both. =C2=A0However, to ensure backwards compatibility with ap= plications 1038 =C2=A0 that do not support the Tunnel Encapsulation attribute, it is 1039 =C2=A0 preferable to use the Encapsulation Extended Community. =C2=A0= If the 1040 =C2=A0 Extended Community (identifying a particular tunnel type) is p= resent, 1041 =C2=A0 the corresponding Tunnel TLV is optional. [major] "However, to ensure backwards compatibility with applications that do not support the Tunnel Encapsulation attribute, it is preferable to use the Encapsulation Extended Community." =C2=A0I'm not sure if that text is referring only to the barebones Tunnel TLV, or the general case. (1) This is one of those cases where using Normative language would be clearer. =C2=A0Perhaps: =C2=A0 =C2=A0To ensure backwards compatibility with implementations that do= not support =C2=A0 =C2=A0the Tunnel Encapsulation attribute, it is RECOMMENDED to use t= he =C2=A0 =C2=A0Encapsulation Extended Community. This text is, I think, weak because the door is open to not use the Extended Community. =C2=A0Should the "SHOULD/RECOMMENDED" be replaced by "MUST/REQUIRED"? (2) This section talks about the case where the barebones Tunnel TLV and the Encapsulation Extended Community are the same. =C2=A0What about the case where they are not? =C2=A0Should using the Tunnel TLV be preferred? What about interoperability? ... 1054 4.2. =C2=A0Router's MAC Extended Community 1056 =C2=A0 [I-D.ietf-bess-evpn-inter-subnet-forwarding] defines a Router'= s MAC 1057 =C2=A0 Extended Community. =C2=A0This Extended Community provides inf= ormation 1058 =C2=A0 that may conflict with information in one or more of the 1059 =C2=A0 Encapsulation Sub-TLVs of a Tunnel Encapsulation attribute. = =C2=A0In case 1060 =C2=A0 of such a conflict, the information in the Encapsulation Sub-T= LV 1061 =C2=A0 takes precedence. [major] You're going to have to be more specific! =C2=A0Please explicitly point out which is the "information that may conflict", and how the conflict can happen. [major] It seems to me that the last sentence may be ideal for Normative language. =C2=A0For instance: "In case of such a conflict, the information in the Encapsulation Sub-TLV MUST be used." [] These are comments for both this document and draft-ietf-bess-evpn-inter-subnet-forwarding -- I'm putting them here because I'm reading this document (and have only skimmed draft-ietf-bess-evpn-inter-subnet-forwarding), but to not forget them later... (1) It would be ideal if this document talked about the result of using the Router's MAC Extended Community in the context of this specification. =C2=A0IOW, if an Encapsulation sub-TLV is not present, then is the result equivalent to including one? =C2=A0At first glance, it looks like what is specified in this document and what is described in =C2=A76.1.1 (draft-ietf-bess-evpn-inter-subnet-forwarding) is not consistent. (2) =C2=A76.1 (draft-ietf-bess-evpn-inter-subnet-forwarding) talks about GENEVE, but this document doesn't, and there's no Tunnel Type for it assigned... =C2=A0I'm not suggesting you need to cover GENEVE, just that there seems to be an expectation in draft-ietf-bess-evpn-inter-subnet-forwarding that cannot be satisfied. (3) This may be a chicken-and-egg problem... draft-ietf-bess-evpn-inter-subnet-forwarding talks about the use of the Router's MAC Extended Community without considering cases when it may be ignored (according to this section), or potentially other ways of doing the same thing (using Encapsulation sub-TLVs). =C2=A0OTOH, this section specifies not using the Router's MAC Extended Community without accounting to the effect, or offering alternate mechanisms. It seems to me that one of the two documents should maybe Update the other, or at least consider the rest of the specification -- at first glance, this document could serve as the base... 1063 4.3. =C2=A0Color Extended Community ... 1068 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3 1069 =C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4= 5 6 7 8 9 0 1 1070 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+ 1071 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 0x03 =C2=A0 =C2=A0| =C2=A0 =C2= =A0 0x0b =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Reserved = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 1072 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+ 1073 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Color Value =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| 1074 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+ 1076 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Figure 10: Color Extended Community [minor] Please add some text related to how the Reserved field should be handled: "MUST be set to zero by the sender and ignored by the receiver", or something like that. [major] Please ask IANA to create a registry for the Reserved bits. Please take a look at this note: https://mailarchive.ietf.org/arch/msg/idr/-45ujNcRzWFWTRnBL1NBcbPoKgo [] Related: =C2=A0I haven't asked for other registries related to Reserved fields. =C2=A0It might be a good idea to at least consider the likelihood of potential requests/assignments and create registries where appropriate. [major] Please specify what the Color Value is. =C2=A0Note that "color value" is not used anywhere else in the text...not even =C2=A77. 1078 =C2=A0 For the use of this Extended Community please see Section 7. 1080 5. =C2=A0Semantics and Usage of the Tunnel Encapsulation attribute 1082 =C2=A0 [RFC5512] specifies the use of the Tunnel Encapsulation attrib= ute in 1083 =C2=A0 BGP UPDATE messages of AFI/SAFI 1/7 and 2/7. =C2=A0That docume= nt restricts 1084 =C2=A0 the use of this attribute to UPDATE messsages of those SAFIs. = =C2=A0This 1085 =C2=A0 document removes that restriction. [nit] s/messsages/messages ... 1095 =C2=A0 It has been suggested that it may sometimes be useful to attac= h a 1096 =C2=A0 Tunnel Encapsulation attribute to a BGP UPDATE message that is= also 1097 =C2=A0 carrying a PMSI (Provider Multicast Service Interface) Tunnel 1098 =C2=A0 attribute [RFC6514]. =C2=A0If the PMSI Tunnel attribute specif= ies an IP 1099 =C2=A0 tunnel, the Tunnel Encapsulation attribute could be used to pr= ovide 1100 =C2=A0 additional information about the IP tunnel. =C2=A0The usage of= the Tunnel 1101 =C2=A0 Encapsulation attribute in combination with the PMSI Tunnel at= tribute 1102 =C2=A0 is outside the scope of this document. [minor] It seems to me that identifying this relationship as out of scope is not necessary: anything that is not specified in this document is, by definition, out of scope. =C2=A0If not removed, then this paragraph really doesn't provide useful information because it is based on a suggestion, and it even provides a potential use, but then it declares the use out of scope...why even mention it? ... 1108 =C2=A0 When the Tunnel Encapsulation attribute is carried in an UPDAT= E of 1109 =C2=A0 one of the AFI/SAFIs specified in the previous paragraph, each= TLV 1110 =C2=A0 MUST have a Tunnel Endpoint sub-TLV. =C2=A0If a TLV that does = not have a 1111 =C2=A0 Tunnel Endpoint sub-TLV, that TLV should be treated as if it h= ad a 1112 =C2=A0 malformed Tunnel Endpoint sub-TLV (see Section 3.1). [nit] s/in the previous paragraph/above [major] "each TLV MUST have a Tunnel Endpoint sub-TLV" =C2=A0Is there any reason not to specify the sub-TLV as mandatory when it is defined (=C2=A73.1)? =C2=A0I think that would be a better place. ... 1130 =C2=A0 =C2=A0 =C2=A0* =C2=A0The tunnel is of a type that can be used = to carry packet P 1131 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (e.g., an MPLS-in-UDP tunnel would not be= a feasible tunnel for 1132 =C2=A0 =C2=A0 =C2=A0 =C2=A0 carrying an IP packet, UNLESS the IP pack= et can first be 1133 =C2=A0 =C2=A0 =C2=A0 =C2=A0 converted to an MPLS packet). [nit] s/converted to/encapsulated in 1135 =C2=A0 =C2=A0 =C2=A0* =C2=A0The tunnel is specified in a TLV whose Tu= nnel Endpoint sub-TLV 1136 =C2=A0 =C2=A0 =C2=A0 =C2=A0 identifies an IP address that is reachabl= e. [major] How is reachability determined? =C2=A0Where (which table) should the address be looked up in? =C2=A0In the sequence above, the destination address of P and the address of the endpoint may be resolvable in different tables... [BTW, please also take a look at draft-ietf-idr-bgp-bestpath-selection-criteria, which I think tries to define a related, if not the same, concept.] ... 1141 =C2=A0 If the Tunnel Encapsulation attribute contains several TLVs (i= .e., if 1142 =C2=A0 it specifies several tunnels), router R may choose any one of = those 1143 =C2=A0 tunnels, based upon local policy. =C2=A0If any tunnel TLV cont= ains one or 1144 =C2=A0 more Color sub-TLVs (Section 3.4.2) and/or the Protocol Type s= ub-TLV 1145 =C2=A0 (Section 3.4.1), the choice of tunnel may be influenced by the= se sub- 1146 =C2=A0 TLVs. [minor] s/several tunnels/several feasible tunnels 1148 =C2=A0 If a particular tunnel is not feasible at some moment because = its 1149 =C2=A0 Tunnel Endpoint cannot be reached at that moment, the tunnel m= ay 1150 =C2=A0 become feasible at a later time (when its endpoint becomes 1151 =C2=A0 reachable). =C2=A0Router R should take note of this. =C2=A0If = router R is 1152 =C2=A0 already using a different tunnel, it MAY switch to the tunnel = that 1153 =C2=A0 just became feasible, or it MAY decide to continue using the t= unnel 1154 =C2=A0 that it is already using. =C2=A0How this decision is made is o= utside the 1155 =C2=A0 scope of this document. [minor] "Router R should take note of this." =C2=A0I'm not sure what the router is expected to do from that sentence...also, the use of a Normative "MAY" seems out of place since the behavior is our of scope anyway. Suggestion> =C2=A0 =C2=A0Reachability to the address of the endpoint of the tunnel may = change over =C2=A0 =C2=A0time, directly impacting the feasibility of the tunnel. =C2=A0= A router may start =C2=A0 =C2=A0using a newly feasible tunnel instead of an existing one. =C2= =A0How this decision =C2=A0 =C2=A0is made is outside the scope of this document. 1157 =C2=A0 In addition to the sub-TLVs already defined, additional sub-TL= Vs may 1158 =C2=A0 be defined that affect the choice of tunnel to be used, or tha= t 1159 =C2=A0 affect the contents of the tunnel encapsulation header. =C2=A0= The 1160 =C2=A0 documents that define any such additional sub-TLVs must specif= y the 1161 =C2=A0 effect that including the sub-TLV is to have. [minor] This paragraph sounds out of place. =C2=A0Maybe it fits better in = =C2=A73. [major] "must specify the effect that including the sub-TLV is to have" (1) Should this phrase be Normative? (2) "the effect" with respect to what? =C2=A0It seems to me that defining a new sub-TLV to have a specific role in the selection of which tunnel to use already would include its effect (in that selection). =C2=A0 IOW, I don't think this paragraph is needed. 1163 =C2=A0 Once it is determined to send a packet through the tunnel spec= ified 1164 =C2=A0 in a particular TLV of a particular Tunnel Encapsulation attri= bute, 1165 =C2=A0 then the tunnel's egress endpoint address is the IP address co= ntained 1166 =C2=A0 in the sub-TLV. =C2=A0If the TLV contains a Tunnel Endpoint su= b-TLV whose 1167 =C2=A0 value field is all zeroes, then the tunnel's egress endpoint i= s the 1168 =C2=A0 IP address specified as the Next Hop of the BGP Update contain= ing the 1169 =C2=A0 Tunnel Encapsulation attribute. =C2=A0The address of the tunne= l egress 1170 =C2=A0 endpoint generally appears in a "destination address" field of= the 1171 =C2=A0 encapsulation. [minor] s/particular TLV/particular Tunnel TLV =C2=A0 Please make sure the TLV is always identified... [major] rfc4271/rfc4760 consistency: s/IP address specified as the Next Hop /address of the next hop ... 1180 =C2=A0 Sending a packet through a tunnel always requires that the pac= ket be 1181 =C2=A0 encapsulated, with an encapsulation header that is appropriate= for 1182 =C2=A0 the tunnel type. =C2=A0The contents of the tunnel encapsulatio= n header MAY 1183 =C2=A0 be influenced by the Encapsulation sub-TLV. =C2=A0If there is = no 1184 =C2=A0 Encapsulation sub-TLV present, the router transmitting the pac= ket 1185 =C2=A0 through the tunnel must have a priori knowledge (e.g., by 1186 =C2=A0 provisioning) of how to fill in the various fields in the 1187 =C2=A0 encapsulation header. [major] "The contents of the tunnel encapsulation header MAY be influenced by the Encapsulation sub-TLV." =C2=A0Why is Normative language used here? =C2=A0If the Encapsulation sub-TLV is present, I thought it always plays a part. =C2=A0I think that the Normative MAY is out of place because of the rest of the paragraph. =C2=A0s/MAY/may [minor] "If there is no Encapsulation sub-TLV present..." =C2=A0I know this section is talking about the Tunnel Encapsulation Attribute, but the statement is true also if only the Encapsulation Extended Community is included in the UPDATE. 1189 =C2=A0 Whenever a new Tunnel Type TLV is defined, the specification o= f that 1190 =C2=A0 TLV should describe (or reference) the procedures for creating= the 1191 =C2=A0 encapsulation header used to forward packets through that tunn= el 1192 =C2=A0 type. =C2=A0If a tunnel type codepoint is assigned in the IANA= "BGP Tunnel 1193 =C2=A0 Encapsulation Tunnel Types" registry, but there is no correspo= nding 1194 =C2=A0 specification that defines an Encapsulation sub-TLV for that t= unnel 1195 =C2=A0 type, the transmitting endpoint of such a tunnel is presumed t= o know 1196 =C2=A0 a priori how to form the encapsulation header for that tunnel = type. [nit] s/Tunnel Type TLV/Tunnel Type [major] The registry is defined as FCFS, so there is no requirement to have anything more than a message to IANA; expecting (or suggesting) a specification here is not appropriate. =C2=A0Unless a change in the registration policy is considered. =C2=A0I think this paragraph is then not needed. 1198 =C2=A0 If a Tunnel Encapsulation attribute specifies several tunnels,= the 1199 =C2=A0 way in which a router chooses which one to use is a matter of = policy, 1200 =C2=A0 subject to the following constraint: if a router can determine= that a 1201 =C2=A0 given tunnel is not functional, it MUST NOT use that tunnel. = =C2=A0In 1202 =C2=A0 particular, if the tunnel is identified in a TLV that has a Tu= nnel 1203 =C2=A0 Endpoint sub-TLV, and if the IP address specified in the sub-T= LV is 1204 =C2=A0 not reachable from router R, then the tunnel MUST be considere= d non- 1205 =C2=A0 functional. =C2=A0Other means of determining whether a given t= unnel is 1206 =C2=A0 functional MAY be used; specification of such means is outside= the 1207 =C2=A0 scope of this specification. =C2=A0Of course, if a non-functio= nal tunnel 1208 =C2=A0 later becomes functional, router R SHOULD reevaluate its choic= e of 1209 =C2=A0 tunnels. [major] "not functional" =C2=A0What does that mean? =C2=A0How can that be determined? =C2=A0Is a "functional" tunnel the same as "feasible tunnel" (from earlier in this section)? =C2=A0If so, please use consistent terminology. [major] The paragraph specifies the same thing as about 6-7 paragraphs above (but calling it feasible). =C2=A0Please specify things only once. IOW, this paragraph seems redundant (if functional and feasible are in fact the same thing). ... 1241 6.1. =C2=A0Impact on BGP Decision Process [nit] s/Impact on BGP Decision Process/Impact on the BGP Decision Process 1243 =C2=A0 The presence of the Tunnel Encapsulation attribute affects the= BGP 1244 =C2=A0 bestpath selection algorithm. =C2=A0For all the tunnels descri= bed in the 1245 =C2=A0 Tunnel Encapsulation attribute for a path, if no Tunnel Endpoi= nt 1246 =C2=A0 address is feasible, then that path MUST NOT be considered res= olvable 1247 =C2=A0 for the purposes of Route Resolvability Condition [RFC4271] se= ction 1248 =C2=A0 9.1.2.1. [minor] rfc4271 consistency: s/bestpath/best route/ [minor] rfc4271 consistency: s/path/route/g [major] "Tunnel Endpoint address is feasible" =C2=A0What does feasible mean in this case? =C2=A0Is it the same thing as "valid" (=C2=A73.1)...or is it "reachable" (=C2=A73.1/=C2=A75)? =C2=A0=C2=A75 talks about a feasible tunne= l, but not a feasible address... =C2=A0 I'm assuming that in this case the feasibility of the address is related to it being reachable (which is defined as one of the criteria for a feasible tunnel)-- if that is the case, where (which table) should it be resolved in? =C2=A0[This comment is closely related to a similar one in =C2=A75.] 1250 6.2. =C2=A0Looping, Infinite Stacking, Etc. 1252 =C2=A0 Consider a packet destined for address X. =C2=A0Suppose a BGP = UPDATE for 1253 =C2=A0 address prefix X carries a Tunnel Encapsulation attribute that 1254 =C2=A0 specifies a tunnel egress endpoint of Y. =C2=A0And suppose tha= t a BGP 1255 =C2=A0 UPDATE for address prefix Y carries a Tunnel Encapsulation att= ribute 1256 =C2=A0 that specifies a Tunnel Endpoint of X. =C2=A0It is easy to see= that this 1257 =C2=A0 will cause an infinite number of encapsulation headers to be p= ut on 1258 =C2=A0 the given packet. [major] This case is an example of what rfc4271 calls a "mutually recursive route": =C2=A0 =C2=A0Mutually recursive routes (routes resolving each other or them= selves) also =C2=A0 =C2=A0fail the resolvability check. [rfc4271/=C2=A79.1.2.1] IOW, that fact should be used here. 1260 =C2=A0 This could happen as a result of misconfiguration, either acci= dental 1261 =C2=A0 or intentional. =C2=A0It could also happen if the Tunnel Encap= sulation 1262 =C2=A0 attribute were altered by a malicious agent. =C2=A0Implementat= ions should 1263 =C2=A0 be aware of this. =C2=A0This document does not specify a maxim= um number of 1264 =C2=A0 recursions; that is an implementation-specific matter. [major] The potential attack is not an infinite number of headers, but simply UPDATES that cannot be used because they are mutually recursive. 1266 =C2=A0 Improper setting (or malicious altering) of the Tunnel Encapsu= lation 1267 =C2=A0 attribute could also cause data packets to loop. =C2=A0Suppose= a BGP 1268 =C2=A0 UPDATE for address prefix X carries a Tunnel Encapsulation att= ribute 1269 =C2=A0 that specifies a tunnel egress endpoint of Y. =C2=A0Suppose ro= uter R 1270 =C2=A0 receives and processes the update. =C2=A0When router R receive= s a packet 1271 =C2=A0 destined for X, it will apply the encapsulation and send the 1272 =C2=A0 encapsulated packet to Y. =C2=A0Y will decapsulate the packet = and forward 1273 =C2=A0 it further. =C2=A0If Y is further away from X than is router R= , it is 1274 =C2=A0 possible that the path from Y to X will traverse R. =C2=A0This= would cause 1275 =C2=A0 a long-lasting routing loop. =C2=A0The control plane itself ca= nnot detect 1276 =C2=A0 this situation, though a TTL field in the payload packets woul= d 1277 =C2=A0 presumably prevent any given packet from looping infinitely. [nit] s/processes the update/processes the advertisement [minor] s/presumably prevent/prevent [minor] This paragraph would be better suited for the Security Considerations section. 1279 =C2=A0 These possibilities must also be kept in mind whenever the Tun= nel 1280 =C2=A0 Endpoint for a given prefix differs from the BGP next hop for = that 1281 =C2=A0 prefix. [major] rfc4271/rfc4760 consistency: s/BGP next hop/address of the next hop [minor] "must also be kept in mind" =C2=A0This phrase is not Normative, but it seems to want to indicate that the router should do something...what is it? 1283 7. =C2=A0Recursive Next Hop Resolution ... 1294 =C2=A0 o =C2=A0the next hop of UPDATE U1 is router R2; [major] rfc4271/rfc4760 consistency: s/next hop/address of the next hop ... 1305 =C2=A0 However, suppose that one of the TLVs in U2's Tunnel Encapsula= tion 1306 =C2=A0 attribute contains the Color Sub-TLV. =C2=A0In that case, pack= et P MUST 1307 =C2=A0 NOT be sent through the tunnel identified in that TLV, unless = U1 is 1308 =C2=A0 carrying the Color Extended Community that is identified in U2= 's 1309 =C2=A0 Color Sub-TLV. [minor] s/identified/contained ... 1319 =C2=A0 The procedures in this section presuppose that U1's next hop r= esolves 1320 =C2=A0 to a BGP route, and that U2's next hop resolves (perhaps after 1321 =C2=A0 further recursion) to a non-BGP route. [major] rfc4271/rfc4760 consistency: s/next hop/address of the next hop ... 1336 8.1. =C2=A0Tunnel Types without a Virtual Network Identifier Field ... 1346 =C2=A0 o =C2=A0If the TLV does not contain an Embedded Label Handling= sub-TLV, or 1347 =C2=A0 =C2=A0 =C2=A0if it contains an Embedded Label Handling sub-TLV= whose value is 1348 =C2=A0 =C2=A0 =C2=A02, the embedded label is ignored completely. =C2= =A0The tunnel is 1349 =C2=A0 =C2=A0 =C2=A0assumed to have terminated at the corresponding V= RF. [] Hmmm...this is the only place where a VRF is mentioned...so the "corresponding VRF" may not be clear. =C2=A0At least, please expand VRF, and add a short explanation. ... 1376 8.2.1. =C2=A0Unlabeled Address Families ... 1389 =C2=A0 If the TLV identifying the tunnel contains an Encapsulation su= b-TLV 1390 =C2=A0 whose V bit is set, the virtual network identifier field of th= e 1391 =C2=A0 encapsulation header is set to the value of the virtual networ= k 1392 =C2=A0 identifier field of the Encapsulation sub-TLV. [major] =C2=A73.2.* talk about the VNI in the sub-TLV being "valid", but there is no guarantee/check to confirm that. =C2=A0IOW, the receiver has to trust the sender. =C2=A0There's an attack vector where a rogue sender, for example, can send an invalid/nonexistent VNI (with the V bit set) and result in mis-delivery or loss of the traffic. =C2=A0Please include something to the effect in the Security Considerations section. =C2=A0[Note that this applies to other places where the same information is used.] ... 1411 8.2.2.1. =C2=A0When a Valid VNI has been Signaled ... 1417 =C2=A0 o =C2=A0If the TLV contains an Embedded Label Handling sub-TLV= whose value 1418 =C2=A0 =C2=A0 =C2=A0is 1, then the virtual network identifier field o= f the 1419 =C2=A0 =C2=A0 =C2=A0encapsulation header is set to the value of the v= irtual network 1420 =C2=A0 =C2=A0 =C2=A0identifier field of the Encapsulation sub-TLV. 1422 =C2=A0 =C2=A0 =C2=A0The embedded label (from the NLRI of the route th= at is carrying 1423 =C2=A0 =C2=A0 =C2=A0the Tunnel Encapsulation attribute) appears at th= e top of the MPLS 1424 =C2=A0 =C2=A0 =C2=A0label stack in the encapsulation payload. 1426 =C2=A0 o =C2=A0If the TLV does not contain an Embedded Label Handling= sub-TLV, or 1427 =C2=A0 =C2=A0 =C2=A0if contains an Embedded Label Handling sub-TLV wh= ose value is 2, 1428 =C2=A0 =C2=A0 =C2=A0the embedded label is ignored entirely, and the v= irtual network 1429 =C2=A0 =C2=A0 =C2=A0identifier field of the encapsulation header is s= et to the value 1430 =C2=A0 =C2=A0 =C2=A0of the virtual network identifier field of the En= capsulation sub- 1431 =C2=A0 =C2=A0 =C2=A0TLV. [nit] s/or if contains/or it contains [major] Both options above result in the same action: "...the virtual network identifier field of the encapsulation header is set to the value of the virtual network identifier field of the Encapsulation sub-TLV." 1433 8.2.2.2. =C2=A0When a Valid VNI has not been Signaled ... 1449 =C2=A0 o =C2=A0If the TLV does not contain an Embedded Label Handling= sub-TLV, or 1450 =C2=A0 =C2=A0 =C2=A0if it contains an Embedded Label Handling sub-TLV= whose value is 1451 =C2=A0 =C2=A0 =C2=A02, the embedded label is copied into the virtual = network 1452 =C2=A0 =C2=A0 =C2=A0identifier field of the encapsulation header. [major] The length of the label and the VNI are different. =C2=A0How should the label be encoded in the bigger field? =C2=A0I'm assuming that the specification is in the encapsulation RFCs, right? ... 1459 9. =C2=A0Applicability Restrictions 1461 =C2=A0 In a given UPDATE of a labeled address family, the label embed= ded in 1462 =C2=A0 the NLRI is generally a label that is meaningful only to the r= outer 1463 =C2=A0 whose address appears as the next hop. =C2=A0Certain of the pr= ocedures of 1464 =C2=A0 Section 8.2.2.1 or Section 8.2.2.2 cause the embedded label to= be 1465 =C2=A0 carried by a data packet to the router whose address appears i= n the 1466 =C2=A0 Tunnel Endpoint sub-TLV. =C2=A0If the Tunnel Endpoint sub-TLV = does not 1467 =C2=A0 identify the same router that is the next hop, sending the pac= ket 1468 =C2=A0 through the tunnel may cause the label to be misinterpreted at= the 1469 =C2=A0 tunnel's egress endpoint. =C2=A0This may cause misdelivery of = the packet. [major] rfc4271/rfc4760 consistency: s/whose address appears as the next hop/represented by the address of the next hop [major] rfc4271/rfc4760 consistency: s/that is the next hop/represented by the address of the next hop 1471 =C2=A0 Therefore the embedded label MUST NOT be carried by a data pac= ket 1472 =C2=A0 traveling through a tunnel unless it is known that the label w= ill be 1473 =C2=A0 properly interpreted at the tunnel's egress endpoint. =C2=A0Ho= w this is 1474 =C2=A0 known is outside the scope of this document. [major] "the embedded label MUST NOT be carried...unless it is known that the label will be properly interpreted...[which is] outside the scope of this document." =C2=A0If outside the scope, then how can it be Normatively enforced? =C2=A0IOW, the text can't mandate something (MUST NOT) and then not offer a way to achieve it -- there's no way to test for interoperability. Is the only safe behavior if the Address field in the Tunnel Endpoint sub-TLV and the address of the next hop are the same? =C2=A0Should that be the Normative part of the specification? 1476 =C2=A0 Note that if the Tunnel Encapsulation attribute is attached to= a VPN- 1477 =C2=A0 IP route [RFC4364], and if Inter-AS "option b" (see section 10= of 1478 =C2=A0 [RFC4364]) is being used, and if the Tunnel Endpoint sub-TLV c= ontains 1479 =C2=A0 an IP address that is not in same AS as the router receiving t= he 1480 =C2=A0 route, it is very likely that the embedded label has been chan= ged. 1481 =C2=A0 Therefore use of the Tunnel Encapsulation attribute in an "Int= er-AS 1482 =C2=A0 option b" scenario is not supported. [major] "the Tunnel Endpoint sub-TLV contains an IP address that is not in same AS as the router receiving the route" =C2=A0This phrase sounds like a common scenario: tunnel endpoint is in a different AS. =C2=A0If this is an issue for this case, why isn't it for other cases? =C2=A0What am I missing? =C2=A0Is there a profile of use cases (where the ones above are good examples of)? [] "is not supported" =C2=A0What does that mean? =C2=A0Does it mean that th= e attribute won't work in that scenario (there are a lot of "if"s in the description)? =C2=A0Does it mean that the use is not recommended? =C2=A0Doe= s it mean that a specific implementation doesn't support it? =C2=A0... 1484 10. =C2=A0Scoping 1486 =C2=A0 The Tunnel Encapsulation attribute is defined as a transitive 1487 =C2=A0 attribute, so that it may be passed along by BGP speakers that= do not 1488 =C2=A0 recognize it. =C2=A0However, it is intended that the Tunnel En= capsulation 1489 =C2=A0 attribute be used only within a well-defined scope, e.g., with= in a 1490 =C2=A0 set of Autonomous Systems that belong to a single administrati= ve 1491 =C2=A0 entity. =C2=A0If the attribute is distributed beyond its inten= ded scope, 1492 =C2=A0 packets may be sent through tunnels in a manner that is not in= tended. 1494 =C2=A0 To prevent the Tunnel Encapsulation attribute from being distr= ibuted 1495 =C2=A0 beyond its intended scope, any BGP speaker that understands th= e 1496 =C2=A0 attribute MUST be able to filter the attribute from incoming B= GP 1497 =C2=A0 UPDATE messages. =C2=A0When the attribute is filtered from an = incoming 1498 =C2=A0 UPDATE, the attribute is neither processed nor redistributed. = =C2=A0This 1499 =C2=A0 filtering SHOULD be possible on a per-BGP-session basis. =C2= =A0For each 1500 =C2=A0 session, filtering of the attribute on incoming UPDATEs MUST b= e 1501 =C2=A0 enabled by default. 1503 =C2=A0 In addition, any BGP speaker that understands the attribute MU= ST be 1504 =C2=A0 able to filter the attribute from outgoing BGP UPDATE messages= . =C2=A0This 1505 =C2=A0 filtering SHOULD be possible on a per-BGP-session basis. =C2= =A0For each 1506 =C2=A0 session, filtering of the attribute on outgoing UPDATEs MUST b= e 1507 =C2=A0 enabled by default. [major] The filtering described on this section implies a contiguous set of ASes within the well-defined scope; the filters implied above seem to be an all-or-nothing proposition. =C2=A0IOW, there doesn't seem to be a possibility to accept the attribute in some updates and not others, or to conditionally do so...maybe based on recommendations from Origin Validation, for example. =C2=A0But then the example used (a single administrative entity) seems to not require Origin Validation anyway. I find the deployment models to be contradicting...not clear...if I trust my neighboring AS enough to accept the Tunnel Encapsulation attribute, then maybe I don't need to verify that the address of the endpoint belongs to them... 1509 11. =C2=A0Error Handling [major] A significant portion of this section is not about error handling, but about normal processing: for example "no significance to the order in which the TLVs occur"... =C2=A0That part of the specification belongs to the section where the TLV (in this case) is described. Please move text to the appropriate sections. 1511 =C2=A0 The Tunnel Encapsulation attribute is a sequence of TLVs, each= of 1512 =C2=A0 which is a sequence of sub-TLVs. =C2=A0The final octet of a TL= V is 1513 =C2=A0 determined by its length field. =C2=A0Similarly, the final oct= et of a sub- 1514 =C2=A0 TLV is determined by its length field. =C2=A0The final octet o= f a TLV MUST 1515 =C2=A0 also be the final octet of its final sub-TLV. =C2=A0If this is= not the 1516 =C2=A0 case, the TLV MUST be considered to be malformed. =C2=A0A TLV = that is 1517 =C2=A0 found to be malformed for this reason MUST NOT be processed, a= nd MUST 1518 =C2=A0 be stripped from the Tunnel Encapsulation attribute before the 1519 =C2=A0 attribute is propagated. =C2=A0Subsequent TLVs in the Tunnel E= ncapsulation 1520 =C2=A0 attribute may still be valid, in which case they MUST be proce= ssed 1521 =C2=A0 and redistributed normally. [major] "The final octet of a TLV MUST also be the final octet of its final sub-TLV. =C2=A0If this is not the case...MUST be stripped from the Tunnel Encapsulation attribute before the attribute is propagated." Wait! =C2=A0To remove it, how do you know where the end of the TLV is: at the end of the TLV length, or at the end of what seems to be the final sub-TLV? =C2=A0It sounds that the assumption is that the Length of the TLV is always correct...but that is clearly just an assumption that could result in not removing the proper number of bits, and the next TLV (if present) might not be able to be processed... rfc7606/=C2=A74 (Attribute Length Fields) specifies that, when dealing with errors in attribute length fields, "the "treat-as-withdraw" approach MUST be used". 1523 =C2=A0 If a Tunnel Encapsulation attribute does not have any valid TL= Vs, or 1524 =C2=A0 it does not have the transitive bit set, the "Attribute Discar= d" 1525 =C2=A0 procedure of [RFC7606] is applied. [major] "does not have any valid TLVs" =C2=A0This is not a valid use of Attribute Discard. =C2=A0This is the definition from rfc7606: =C2=A0 =C2=A0o =C2=A0Attribute discard: In this approach, the malformed att= ribute MUST =C2=A0 =C2=A0 =C2=A0 be discarded and the UPDATE message continues to be pr= ocessed. =C2=A0 =C2=A0 =C2=A0 This approach MUST NOT be used except in the case of a= n attribute =C2=A0 =C2=A0 =C2=A0 that has no effect on route selection or installation. It is clear to me, because of the specification in =C2=A76.1 (Impact on BGP Decision Process), that the TLVs directly impact route selection/installation. [] "does not have the transitive bit set" =C2=A0The use of Attribute Discard in this case is ok...from rfc7607/=C2=A73: =C2=A0 =C2=A0 =C2=A0If the value of either the Optional or Transitive bits = in =C2=A0 =C2=A0 =C2=A0the Attribute Flags is in conflict with their specified =C2=A0 =C2=A0 =C2=A0values, then the attribute MUST be treated as malformed= and =C2=A0 =C2=A0 =C2=A0the "treat-as-withdraw" approach used, unless the =C2=A0 =C2=A0 =C2=A0specification for the attribute mandates different hand= ling =C2=A0 =C2=A0 =C2=A0for incorrect Attribute Flags. 1527 =C2=A0 If a Tunnel Encapsulation attribute can be parsed correctly, b= ut 1528 =C2=A0 contains a TLV whose tunnel type is not recognized by a partic= ular 1529 =C2=A0 BGP speaker, that BGP speaker MUST NOT consider the attribute = to be 1530 =C2=A0 malformed. =C2=A0Rather, the TLV with the unrecognized tunnel = type MUST be 1531 =C2=A0 ignored, and the BGP speaker MUST interpret the attribute as i= f that 1532 =C2=A0 TLV had not been present. =C2=A0If the route carrying the Tunn= el 1533 =C2=A0 Encapsulation attribute is propagated with the attribute, the 1534 =C2=A0 unrecognized TLV MUST remain in the attribute. [minor] "the unrecognized tunnel type MUST be ignored, and the BGP speaker MUST interpret the attribute as if that TLV had not been present." =C2=A0 This sounds redundant to me...or is there a difference between ignore and "interpret the attribute as if that TLV had not been present"? [] the handling of unrecognized stuff is not an error condition...it may simply be a new/unknown thing... =C2=A0Please move the specification to =C2=A72-3. 1536 =C2=A0 If a TLV of a Tunnel Encapsulation attribute contains a sub-TL= V that 1537 =C2=A0 is not recognized by a particular BGP speaker, the BGP speaker= MUST 1538 =C2=A0 process that TLV as if the unrecognized sub-TLV had not been p= resent. 1539 =C2=A0 If the route carrying the Tunnel Encapsulation attribute is 1540 =C2=A0 propagated with the attribute, the unrecognized TLV MUST remai= n in 1541 =C2=A0 the attribute. [minor] s/unrecognized TLV MUST remain/unrecognized sub-TLV MUST remain [??] Is there a case where the result could be different tunnels? For example, one router interprets one thing (partially) and another a different result given the additional information? =C2=A0I would assume the answer is yes given that we don't know the nature of the new sub-TLV. We need text about the introduction of new sub-TLVs. 1543 =C2=A0 If the type code of a sub-TLV appears as "reserved" in the IAN= A "BGP 1544 =C2=A0 Tunnel Encapsulation Attribute Sub-TLVs" registry, the sub-TLV= MUST 1545 =C2=A0 be treated as an unrecognized sub-TLV. [major] How does a router check the IANA registry? =C2=A0 There is currently only one Reserved value in the registry (0) -- it is then better to simply specify what should be done if 0 is received. However, because a Reserved value could be used for something in the future [rfc8126], then I don't think it is necessary to explicitly specify what to do in this case. =C2=A0Please remove the paragraph. 1547 =C2=A0 In general, if a TLV contains a sub-TLV that is malformed (e.g= ., 1548 =C2=A0 contains a length field whose value is not legal for that sub-= TLV), 1549 =C2=A0 the sub-TLV should be treated as if it were an unrecognized su= b-TLV. 1550 =C2=A0 This document specifies one exception to this rule -- within a= tunnel 1551 =C2=A0 encapsulation attribute that is carried by a BGP UPDATE whose = AFI/ 1552 =C2=A0 SAFI is one of those explicitly listed in the second paragraph= of 1553 =C2=A0 Section 5, if a TLV contains a malformed Tunnel Endpoint sub-T= LV (as 1554 =C2=A0 defined in Section 3.1), the entire TLV MUST be ignored, and M= UST be 1555 =C2=A0 removed from the Tunnel Encapsulation attribute before the rou= te 1556 =C2=A0 carrying that attribute is redistributed. [minor] "e.g., contains a length field whose value is not legal..." The length example is a bad one. =C2=A0As I mentioned above, rfc7606/=C2=A7= 4 (Attribute Length Fields) specifies that, when dealing with errors in attribute length fields, "the "treat-as-withdraw" approach MUST be used". [major] "should be treated as..." =C2=A0Should that be a Normative statemen= t? [minor] "be treated as if it were an unrecognized sub-TLV" =C2=A0Instead of forcing the reader to check how an unrecognized sub-TLV is treated, please simply go to the point: be ignored. [nit] s/tunnel encapsulation attribute/Tunnel Encapsulation attribute/g =C2=A0 To be consistent with the rest of the text. [major] "...one exception...a BGP UPDATE whose AFI/SAFI is...listed in...Section 5, if a TLV contains a malformed Tunnel Endpoint sub-TLV...the entire TLV MUST be ignored, and MUST be removed from the Tunnel Encapsulation attribute" =C2=A0 So...the "exception" applies to all the currently supported AFI/SAFIs... =C2=A0If no other AFI/SAFIs are specified at this time, why is this "exception" not the norm? 1558 =C2=A0 Within a tunnel encapsulation attribute that is carried by a B= GP 1559 =C2=A0 UPDATE whose AFI/SAFI is one of those explicitly listed in the= second 1560 =C2=A0 paragraph of Section 5, a TLV that does not contain exactly on= e 1561 =C2=A0 Tunnel Endpoint sub-TLV MUST be treated as if it contained a 1562 =C2=A0 malformed Tunnel Endpoint sub-TLV. [major] There is text below (penultimate paragraph) that starts to specify the same thing ("sub-TLVs...MUST NOT occur more than once")...so this paragraph is really an exception to the behavior specified below. =C2=A0First, please specify the behavior only once (see =C2=A73.1). =C2=A0Also, consider structuring the specification so that gene= ral behavior is specified first and then the specifics. 1564 =C2=A0 A TLV identifying a particular tunnel type may contain a sub-T= LV that 1565 =C2=A0 is meaningless for that tunnel type. =C2=A0For example, perhap= s the TLV 1566 =C2=A0 contains a "UDP Destination Port" sub-TLV, but the identified = tunnel 1567 =C2=A0 type does not use UDP encapsulation at all. =C2=A0Sub-TLVs of = this sort 1568 =C2=A0 MUST be treated as a no-op. =C2=A0That is, they MUST NOT affec= t the 1569 =C2=A0 creation of the encapsulation header. =C2=A0However, the sub-T= LV MUST NOT 1570 =C2=A0 be considered to be malformed, and MUST NOT be removed from th= e TLV 1571 =C2=A0 before the route carrying the Tunnel Encapsulation attribute i= s 1572 =C2=A0 redistributed. =C2=A0(This allows for the possibility that suc= h sub-TLVs 1573 =C2=A0 may be given a meaning, in the context of the specified tunnel= type, 1574 =C2=A0 in the future.) [nit] s/"UDP Destination Port"/UDP Destination Port [minor] "That is, they MUST NOT affect the creation of the encapsulation header. =C2=A0However, the sub-TLV MUST NOT be considered to be malformed, and MUST NOT be removed from the TLV before the route carrying the Tunnel Encapsulation attribute is redistributed." =C2=A0It seems to me that these sentences are redundant and not needed. =C2=A0If you want to make sure that "ignored" is translated into all the rest, please specify it once and forget it. [minor] "(This allows for the possibility...in the future.)" =C2=A0Please remove this sentence and don't speculate in a Standards Track document. ... 1581 =C2=A0 The following sub-TLVs defined in this document MUST NOT occur= more 1582 =C2=A0 than once in a given Tunnel TLV: Tunnel Endpoint (discussed ab= ove), 1583 =C2=A0 Encapsulation, IPv4 DS, UDP Destination Port, Embedded Label 1584 =C2=A0 Handling, MPLS Label Stack, Prefix-SID. =C2=A0If a Tunnel TLV = has more 1585 =C2=A0 than one of any of these sub-TLVs, all but the first occurrenc= e of 1586 =C2=A0 each such sub-TLV type MUST be treated as a no-op. =C2=A0Howev= er, the 1587 =C2=A0 Tunnel TLV containing them MUST NOT be considered to be malfor= med, 1588 =C2=A0 and all the sub-TLVs MUST be propagated if the route carrying = the 1589 =C2=A0 Tunnel Encapsulation attribute is propagated. [major] "MUST NOT occur more than once in a given Tunnel TLV: Tunnel Endpoint (discussed above)...If a Tunnel TLV has more than one of any of these sub-TLVs, all but the first occurrence..." =C2=A0 Related to the comment above about the Tunnel Endpoint exception; please reorder the text, and consider moving some of the specification to the place where specific sub-TLVs are defined. ... 1597 12. =C2=A0IANA Considerations [major] Please take a look at rfc8126/=C2=A78, and use this text to introduce the section: =C2=A0 =C2=A0Because this document obsoletes RFC 5512, IANA is asked to cha= nge all =C2=A0 =C2=A0registration information that references [RFC5512] to instead = reference this =C2=A0 =C2=A0document. Adding this document as a reference (as in =C2=A712.2) is not appropriate. If adding the text above, then some of the sections below (like =C2=A712.2) are not needed. [minor] This document creates several new registries related to the sub-TLVs. =C2=A0Consider creating a new grouping (maybe "BGP Tunnel Encapsulation Parameters") to include those and the existing Tunnel Types and Sub-TLVs registries. 1599 12.1. =C2=A0Subsequent Address Family Identifiers 1601 =C2=A0 IANA is requested to modify the "Subsequent Address Family 1602 =C2=A0 Identifiers" registry to indicate that the Encapsulation SAFI = is 1603 =C2=A0 deprecated. =C2=A0This document should be the reference. [nit] Please indicate the value (7). [major] In this case "obsolete", and not "deprecated" is the right indicati= on. 1605 12.2. =C2=A0BGP Path Attributes 1607 =C2=A0 IANA has previously assigned value 23 from the "BGP Path Attri= butes" 1608 =C2=A0 Registry to "Tunnel Encapsulation Attribute". =C2=A0IANA is re= quested to 1609 =C2=A0 add this document as a reference. [] This section is not needed...assuming the introductory text suggested above is added. 1611 12.3. =C2=A0Extended Communities 1613 =C2=A0 IANA has previously assigned values from the "Transitive Opaqu= e 1614 =C2=A0 Extended Community" type Registry to the "Color Extended Commu= nity" 1615 =C2=A0 (sub-type 0x0b), and to the "Encapsulation Extended 1616 =C2=A0 Community"(0x030c). =C2=A0IANA is requested to add this docume= nt as a 1617 =C2=A0 reference for both assignments. [] This section is not needed...assuming the introductory text suggested above is added. 1619 12.4. =C2=A0BGP Tunnel Encapsulation Attribute Sub-TLVs ... 1637 =C2=A0 o =C2=A0The values in the range 64-125 and 192-252 are to be a= llocated 1638 =C2=A0 =C2=A0 =C2=A0using the "First Come, First Served" registration= procedure. [nit] s/First Come, First Served/First Come First Served 1640 =C2=A0 o =C2=A0The values in the range 126-127 and 253-254 are reserv= ed for 1641 =C2=A0 =C2=A0 =C2=A0experimental use; IANA shall not allocate values = from this range. [minor] A Table instead of the sentences above would be great. ... 1646 =C2=A0 =C2=A0 =C2=A06: Remote Endpoint 1648 =C2=A0 =C2=A0 =C2=A0IANA is requested to change the name of "Remote E= ndpoint" to 1649 =C2=A0 =C2=A0 =C2=A0"Tunnel Egress Endpoint". [major] The rest of this document calls it the "Tunnel Endpoint" sub-TLV (not Tunnel Egress Endpoint). =C2=A0Call it anything you want, but please be consistent! ... 1658 =C2=A0 =C2=A0 =C2=A011: Prefix SID [major] The rest of this document calls it the "Prefix-SID" sub-TLV (not Prefix SID). =C2=A0Note that changing the text here requires asking IANA to update the same (which I think is the right thing to do). 1660 =C2=A0 IANA has previously assigned codepoints from the "BGP Tunnel 1661 =C2=A0 Encapsulation Attribute Sub-TLVs" registry for "Encapsulation"= , 1662 =C2=A0 "Protocol Type", and "Color". =C2=A0IANA is requested to add t= his document 1663 =C2=A0 as a reference. [] This last paragraph is not needed...assuming the introductory text suggested above is added. 1665 12.5. =C2=A0Tunnel Types ... 1671 =C2=A0 IANA is requested to add this document as a reference for tunn= el 1672 =C2=A0 types 1 (L2TPv3), 2 (GRE), and 7 (IP in IP) in the "BGP Tunnel 1673 =C2=A0 Encapsulation Tunnel Types" registry. [] This last paragraph is not needed...assuming the introductory text suggested above is added. 1675 12.6. =C2=A0Flags Field of Vxlan Encapsulation sub-TLV [minor] s/Vxlan/VXLAN/g ... 1680 =C2=A0 IANA is requested to add this document as a reference for flag= bits V 1681 =C2=A0 and M in the "Flags field of Vxlan Encapsulation sub-TLV" regi= stry. [major] Suggestion> =C2=A0 =C2=A0IANA is requested to create a new registry titled "..." in the= ggg group. =C2=A0 =C2=A0The registration policy for the registry is ppp. =C2=A0 =C2=A0The initial values for this new registry are indicated below. =C2=A0 =C2=A0...Add a table showing the Bit Position, Flag Name and Referen= ce.... 1683 12.7. =C2=A0Flags Field of Vxlan-GPE Encapsulation sub-TLV ... 1688 =C2=A0 IANA is requested to add this document as a reference for flag= bit V 1689 =C2=A0 in the "Flags field of Vxlan-GPE Encapsulation sub-TLV" regist= ry. [major] Suggestion> =C2=A0 =C2=A0IANA is requested to create a new registry titled "..." in the= ggg group. =C2=A0 =C2=A0The registration policy for the registry is ppp. =C2=A0 =C2=A0The initial values for this new registry are indicated below. =C2=A0 =C2=A0...Add a table showing the Bit Position, Flag Name and Referen= ce.... 1691 12.8. =C2=A0Flags Field of NVGRE Encapsulation sub-TLV ... 1696 =C2=A0 IANA is requested to add this document as a reference for flag= bits V 1697 =C2=A0 and M in the "Flags field of NVGRE Encapsulation sub-TLV" regi= stry. [major] Suggestion> =C2=A0 =C2=A0IANA is requested to create a new registry titled "..." in the= ggg group. =C2=A0 =C2=A0The registration policy for the registry is ppp. =C2=A0 =C2=A0The initial values for this new registry are indicated below. =C2=A0 =C2=A0...Add a table showing the Bit Position, Flag Name and Referen= ce.... 1699 12.9. =C2=A0Embedded Label Handling sub-TLV ... 1705 =C2=A0 IANA is requested to add this document as a reference for valu= e of 1 1706 =C2=A0 (Payload of MPLS with embedded label) and 2 (no embedded label= in 1707 =C2=A0 payload) in the "sub-TLV's value field of the Embedded Label H= andling 1708 =C2=A0 sub-TLV" registry. [major] Suggestion> =C2=A0 =C2=A0IANA is requested to create a new registry titled "..." in the= ggg group. =C2=A0 =C2=A0The registration policy for the registry is ppp. =C2=A0 =C2=A0The initial values for this new registry are indicated below. =C2=A0 =C2=A0...Add a table showing the Values, Name and Reference.... 1710 13. =C2=A0Security Considerations 1712 =C2=A0 The Tunnel Encapsulation attribute can cause traffic to be div= erted 1713 =C2=A0 from its normal path, especially when the Tunnel Endpoint sub-= TLV is 1714 =C2=A0 used. =C2=A0This can have serious consequences if the attribut= e is added 1715 =C2=A0 or modified illegitimately, as it enables traffic to be "hijac= ked". [major] Even if the attribute is added legitimately, the contents may still divert the traffic in an undesired direction. =C2=A0This is the case of a rogue node. =C2=A0Not only can the traffic be diverted to a location the rogue router expects, but it can be sent to an unsuspecting node -- this last scenario could result in overloading it, etc. =C2=A0 Please include text related to actions that a rogue node could initiate. =C2=A0Not all of these actions have possible mitigation, but being aware of them is important. 1717 =C2=A0 The Tunnel Endpoint sub-TLV contains both an IP address and an= AS 1718 =C2=A0 number. =C2=A0BGP Origin Validation [RFC6811] can be used to o= btain 1719 =C2=A0 assurance that the given IP address belongs to the given AS. = =C2=A0While 1720 =C2=A0 this provides some protection against misconfiguration, it doe= s not 1721 =C2=A0 prevent a malicious agent from inserting a sub-TLV that will a= ppear 1722 =C2=A0 valid. [major] The text in =C2=A73.1 points to this section on the topic of the address belonging to an AS...and then that check is used Normatively to define actions. =C2=A0However, the use of BGP Origin Validation is not Normatively mandated; instead language such as "can be used" or "may be advisable" is used. =C2=A0That is justified (below) by pointing out issues...and further suggesting that BGPSEC (which is a not-deployed protocol!) could be used. The summary is that there is no Normative/mandatory mechanism to validate that an IP address belongs to an AS, which is a requirements elsewhere in the text. =C2=A0IOW, the specification is not complete and can result in implementations basically doing anything they want. :-( [major] Note also that rfc6811 talks about route validation...and not validation or any other object (like an attribute). =C2=A0If Origin Validation is in fact recommended (SHOULD), then we need a paragraph or two detailing the mapping between the fields in the Tunnel Endpoint sub-TLV and "Route Prefix" and "Route Origin ASN". 1724 =C2=A0 Before sending a packet through the tunnel identified in a par= ticular 1725 =C2=A0 TLV of a Tunnel Encapsulation attribute, it may be advisable t= o use 1726 =C2=A0 BGP Origin Validation to obtain the following additional assur= ances: 1728 =C2=A0 o =C2=A0the origin AS of the route carrying the Tunnel Encapsu= lation 1729 =C2=A0 =C2=A0 =C2=A0attribute is correct; 1731 =C2=A0 o =C2=A0the origin AS of the route to the IP address specified= in the 1732 =C2=A0 =C2=A0 =C2=A0Tunnel Endpoint sub-TLV is correct, and is the sa= me AS that is 1733 =C2=A0 =C2=A0 =C2=A0specified in the Tunnel Endpoint sub-TLV. [major] This text points at a slightly different requirement than the text in =C2=A73.1, which wants it to be "determined that the IP address in the sub-TLV's address subfield does not belong to the...Autonomous System", which somehow implies checking the validity of the IP/ASN pair in the sub-TLV. =C2=A0 The text above talks about "the route to the IP address", which is different! Validating the route to the IP address (and not the sub-TLV) is better, clearer and already specified (rfc6811). =C2=A0The issue of the Normative dependence still remains. 1735 =C2=A0 One then has some level of assurance that the tunneled traffic= is 1736 =C2=A0 going to the same destination AS that it would have gone to ha= d the 1737 =C2=A0 Tunnel Encapsulation attribute not been present. =C2=A0However= , this may 1738 =C2=A0 not suit all use cases, and in any event is not very strong 1739 =C2=A0 protection against hijacking. [major] "this may not suit all use cases" =C2=A0Like what? =C2=A0What are t= he exceptions? [major] "...is not very strong protection against hijacking." =C2=A0Do you have a reference for that? =C2=A0Seriously, this document is not the place to criticize other solutions...much less ones that seem to be necessary for the functionality described here. =C2=A0Instead, please point to the security considerations of rfc6811 and let the reader reach any conclusion they may. 1741 =C2=A0 For these reasons, BGP Origin Validation should not be relied = upon 1742 =C2=A0 exclusively, and the filtering procedures of Section 10 should= always 1743 =C2=A0 be in place. [minor] Should this text be Normative? 1745 =C2=A0 Increased protection can be obtained by using BGPSEC [RFC8205]= to 1746 =C2=A0 ensure that the route carrying the Tunnel Encapsulation attrib= ute, 1747 =C2=A0 and the routes to the Tunnel Endpoint of each specified tunnel= , have 1748 =C2=A0 not been altered illegitimately. [nit] s/BGPSEC/BGPsec [major] BGPsec does not guarantee that the route has not been altered...just just that the UPDATE traversed a path [rfc8205/=C2=A78.1]. Specifically, BGPsec doesn't protect any attributes (other than the BGPsec_PATH). 1750 =C2=A0 If BGP Origin Validation is used as specified above, and the t= unnel 1751 =C2=A0 specified in a particular TLV of a Tunnel Encapsulation attrib= ute is 1752 =C2=A0 therefore regarded as "suspicious", that tunnel should not be = used. [major] "suspicious" is not one of the states in rfc6811. [major] "tunnel should not be used" =C2=A0Should that be a Normative statement. =C2=A0If yes, are there cases when it would be ok to use the tunnel? 1754 =C2=A0 Other tunnels specified in (other TLVs of) the Tunnel Encapsul= ation 1755 =C2=A0 attribute may still be used. [nit] s/(other TLVs of)/other TLVs of ... 1795 16.1. =C2=A0Normative References 1797 =C2=A0 [I-D.ietf-idr-bgp-prefix-sid] 1798 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Previdi, S., Filsfils= , C., Lindem, A., Sreekantiah, A., 1799 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and H. Gredler, "Segm= ent Routing Prefix SID extensions for 1800 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0BGP", draft-ietf-idr-= bgp-prefix-sid-27 (work in progress), 1801 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0June 2018. [major] s/I-D.ietf-idr-bgp-prefix-sid/rfc8669 ... 1842 =C2=A0 [RFC4760] =C2=A0Bates, T., Chandra, R., Katz, D., and Y. Rekht= er, 1843 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Multiprotocol Extens= ions for BGP-4", RFC 4760, 1844 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DOI 10.17487/RFC4760,= January 2007, 1845 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0. =3D=3D Unused Reference: 'RFC4760' is defined on line 1842, but no explicit =C2=A0 =C2=A0reference was found in the text 1847 =C2=A0 [RFC5512] =C2=A0Mohapatra, P. and E. Rosen, "The BGP Encapsula= tion 1848 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Subsequent Address Fa= mily Identifier (SAFI) and the BGP 1849 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Tunnel Encapsulation = Attribute", RFC 5512, 1850 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DOI 10.17487/RFC5512,= April 2009, 1851 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0. [minor] Because this document Obsoletes rfc5512, there shouldn't be a Normative dependence. 1853 =C2=A0 [RFC5566] =C2=A0Berger, L., White, R., and E. Rosen, "BGP IPse= c Tunnel 1854 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Encapsulation Attribu= te", RFC 5566, DOI 10.17487/RFC5566, 1855 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0June 2009, . [minor] This reference can be Informative. ... 1864 =C2=A0 [RFC7510] =C2=A0Xu, X., Sheth, N., Yong, L., Callon, R., and D= . Black, 1865 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Encapsulating MPLS i= n UDP", RFC 7510, 1866 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DOI 10.17487/RFC7510,= April 2015, 1867 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0. [minor] This reference can be Informative. ... 1883 16.2. =C2=A0Informative References ... 1896 =C2=A0 [RFC2474] =C2=A0Nichols, K., Blake, S., Baker, F., and D. Blac= k, 1897 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"Definition of the Di= fferentiated Services Field (DS 1898 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Field) in the IPv4 an= d IPv6 Headers", RFC 2474, 1899 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DOI 10.17487/RFC2474,= December 1998, 1900 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0. [major] This reference should be Normative. From nobody Mon Feb 24 05:43:58 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12003A0B72 for ; Mon, 24 Feb 2020 05:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.224 X-Spam-Level: * X-Spam-Status: No, score=1.224 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=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 9E6OIOvlZDxL for ; Mon, 24 Feb 2020 05:43:55 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 7AD2C3A0B71 for ; Mon, 24 Feb 2020 05:43:55 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.177.57.99; From: "Susan Hares" To: Date: Mon, 24 Feb 2020 08:43:48 -0500 Message-ID: <000701d5eb18$71a02200$54e06600$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01D5EAEE.88CB2B70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdXrF6YefQ/aBuJURImPFwA7se+WjA== Content-Language: en-us X-Antivirus: AVG (VPS 200223-0, 02/23/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] IPR Call for draft-li-idr-flowspec-srv6 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 13:43:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0008_01D5EAEE.88CB2B70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings: This begins a IPR call for /raft-li-idr-flowspec-srv6-02.txt. The adoption call will begin after all authors have responded to this email with an IPR statement. For the authors who have responded before, you will need to respond to this email message as well. A bit thanks to the authors who have waited patiently for the IDR chairs. For the WG general discussion on IDR flow specification, this call is to inquiry if this draft's approach is useful. As has been discussed on the list, the IETF 107 IDR working group meeting will need to decide if all additions to flow specification should go into a version 2 specification. In order to have a fruitful discussion regarding the amount of additions for flow specification, we will be calling for the WG to discuss any potential Flow specification drafts. Cheers, Sue ------=_NextPart_000_0008_01D5EAEE.88CB2B70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings: =

 

This begins a IPR call for = /raft-li-idr-flowspec-srv6-02.txt.  The adoption call will begin = after all authors have responded to this email with an IPR statement. =  For the authors who have responded before, you will need to = respond to this email message as well.  

 

A bit thanks = to the authors who have waited patiently for the IDR chairs.  =

 

For the WG general discussion on IDR flow = specification,  this call is to inquiry if this draft’s = approach is useful.   As has been discussed on the list, the = IETF 107 IDR working group meeting will need to decide if all additions = to flow specification should go into  a version 2 = specification.  

 

In order to = have a fruitful discussion regarding the amount of additions for flow = specification, we will be calling for the WG to discuss any potential = Flow specification drafts.

 

Cheers, Sue =

------=_NextPart_000_0008_01D5EAEE.88CB2B70-- From nobody Mon Feb 24 05:46:00 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAD13A0B79 for ; Mon, 24 Feb 2020 05:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.123 X-Spam-Level: *** X-Spam-Status: No, score=3.123 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=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 7ff_Z9-wJo6B for ; Mon, 24 Feb 2020 05:45:58 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 F36083A0B78 for ; Mon, 24 Feb 2020 05:45:57 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.177.57.99; From: "Susan Hares" To: Date: Mon, 24 Feb 2020 08:45:54 -0500 Message-ID: <001401d5eb18$bc742b50$355c81f0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01D5EAEE.D39E2350" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdXrGLu8VdwGY2PMRAazpaejfCi/jw== Content-Language: en-us X-Antivirus: AVG (VPS 200223-0, 02/23/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] IPR for draft-li-idr-sr-policy-path-mtu-03.txt prior to WG adoptin (2/24 - 3/4) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 13:45:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0015_01D5EAEE.D39E2350 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings: This is an IPR call prior to a WG Adoption call for draft-li-idr-sr-policy-path-mtu-03.txt. The authors should respond to this message even if they have responded before. The WG group adoption call will begin as soon as all authors have responded. Cheerily, Sue ------=_NextPart_000_0015_01D5EAEE.D39E2350 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings: =

 

This is an IPR call prior to a WG Adoption call for = draft-li-idr-sr-policy-path-mtu-03.txt.  The authors should respond = to this message even if they have responded before.

 

The WG group = adoption call will begin as soon as all authors have responded. =

 

Cheerily,  Sue

------=_NextPart_000_0015_01D5EAEE.D39E2350-- From nobody Mon Feb 24 05:48:30 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C66D13A0B9E for ; Mon, 24 Feb 2020 05:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.123 X-Spam-Level: *** X-Spam-Status: No, score=3.123 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=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 ujM6Zmwola4w for ; Mon, 24 Feb 2020 05:48:28 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 825D43A0B99 for ; Mon, 24 Feb 2020 05:48:27 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.177.57.99; From: "Susan Hares" To: Date: Mon, 24 Feb 2020 08:48:19 -0500 Message-ID: <002101d5eb19$12b85e00$38291a00$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0022_01D5EAEF.29E25600" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdXrGPiwgmyjrHdoRa2SgqmdS5rX2A== Content-Language: en-us X-Antivirus: AVG (VPS 200223-0, 02/23/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] draft-wu-idr-bgp-segment-allocation-ext-04 - IPR call prior to WG adoption call (2/24 to 3/4) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 13:48:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0022_01D5EAEF.29E25600 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings: This begins an IPR call for draft-wu-idr-bgp-segment-ext-04.txt prior to WG adoption call. The WG adoption call will begin as soon as all the authors have responded to this message. For authors who have responded to an IPR call, please you will need to again respond to this IPR call. Cheers, Susan Hares ------=_NextPart_000_0022_01D5EAEF.29E25600 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings: =

 

This begins an IPR call for = draft-wu-idr-bgp-segment-ext-04.txt prior to WG adoption call. =   The WG adoption call will begin as soon as all the authors = have responded to this message. 

 

For authors = who have responded to an IPR call, please you will need to again respond = to this IPR call.

 

Cheers, = Susan Hares

 

------=_NextPart_000_0022_01D5EAEF.29E25600-- From nobody Mon Feb 24 05:55:21 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 718CD3A0B8E for ; Mon, 24 Feb 2020 05:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 z5uENlggAqVu for ; Mon, 24 Feb 2020 05:55:17 -0800 (PST) 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 BA1913A0B78 for ; Mon, 24 Feb 2020 05:55:17 -0800 (PST) Received: by mail-ot1-x331.google.com with SMTP id 59so8706461otp.12 for ; Mon, 24 Feb 2020 05:55:17 -0800 (PST) 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=nr36eDEKE7/gwVkDFdOvSSc//MwYwmdYXSqziMF+xxA=; b=Ij0o+3Uba8nHdj28XoEx2eLnZ8EZOwleB9Z6zn92b76WCdesDUZDc/LYSv84WxJx/q kx+Rw0g8Uwb03HVD/GNAy0gCerPkj3RS3nsZB8Pu5dwhmmTKfx5flaHZcE3/znHqwj59 DPSrWE9fk/Cg5TlZ7V+bt8cIIGLGJBzRlQb2VM6djL/+2BTEDpcNOoy1HijqOJo9a5vl I/nLKiRcEqGjjEKIuxaQctIr5Te1ubJrCPENvmFdgFxNba378HnfGDdOW99BMKwIrCS8 Tz/m5JqxG0slk/IlbNTr30HuE6s9pIKj+5nQ8uvF6tE7OIUKAMvw3Go3/+KBzLhqhsMT pX+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nr36eDEKE7/gwVkDFdOvSSc//MwYwmdYXSqziMF+xxA=; b=EZdVakTARC4FoQ3WAQPq/UKcJvxvZRGlURqESOwJtF8xW3LqhqJHmSoNpR15iEzlDI +cEkJZ89VviFc8P5O5BTNppuNdP7xJIrKpAMISTGuobiilopz5fXbbw9kKyaoicJPDtm a6E88MSPIRQUTHdzgriW1JWb9afLyR4kAM4epMkNoMCXERgY5DCRR2jgPh7B7UHiWhzd pa1cwKKJohvDWEPeiMyBym7oIfrtuukuAGJ+gbV+1Vl3wsy9/CogOnVhN7srnP2kw+L6 O2NgnckAN3D0y4n2z3+DyfLxlpxD97FDlHmEaDgC7yv/dsXu9oyWXhrYz/xh+axd0NTt u4Mg== X-Gm-Message-State: APjAAAXo8CSEoc3d+IXUUworGNu/B7GXyyxuJE54U8kyAdyY8srM45Gl 7HmU5+KuobBKiPuxuUMnjQphaKlWDgh+3lynfB7GPbi6 X-Google-Smtp-Source: APXvYqxgOwKNyiI/efiTosr+8tS1YAnUbNE9jSsUprpfOYyiuXC3HspFc4npCqi0XpEgTh6cIOzFN8bBIXXKdiBnkMs= X-Received: by 2002:a9d:7083:: with SMTP id l3mr38275333otj.193.1582552516695; Mon, 24 Feb 2020 05:55:16 -0800 (PST) MIME-Version: 1.0 References: <000701d5eb18$71a02200$54e06600$@ndzh.com> In-Reply-To: <000701d5eb18$71a02200$54e06600$@ndzh.com> From: Robert Raszuk Date: Mon, 24 Feb 2020 14:55:05 +0100 Message-ID: To: Susan Hares Cc: "idr@ietf. org" Content-Type: multipart/alternative; boundary="00000000000098a8f7059f52b87f" Archived-At: Subject: Re: [Idr] IPR Call for draft-li-idr-flowspec-srv6 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 13:55:20 -0000 --00000000000098a8f7059f52b87f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, I think there is an agreement in place to hold any further flow spec extensions till Flow Spec v2 (with new SAFI) base spec will be at least a WG document. Based on the above I recommend to wait with the adoption call till the draft is able to reference Flow Spec v2 or perhaps directly be used on its day one input. Thx, R. On Mon, Feb 24, 2020 at 2:44 PM Susan Hares wrote: > Greetings: > > > > This begins a IPR call for /raft-li-idr-flowspec-srv6-02.txt. The > adoption call will begin after all authors have responded to this email > with an IPR statement. For the authors who have responded before, you wi= ll > need to respond to this email message as well. > > > > A bit thanks to the authors who have waited patiently for the IDR chairs. > > > > For the WG general discussion on IDR flow specification, this call is to > inquiry if this draft=E2=80=99s approach is useful. As has been discuss= ed on the > list, the IETF 107 IDR working group meeting will need to decide if all > additions to flow specification should go into a version 2 > specification. > > > > In order to have a fruitful discussion regarding the amount of additions > for flow specification, we will be calling for the WG to discuss any > potential Flow specification drafts. > > > > Cheers, Sue > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --00000000000098a8f7059f52b87f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I think there is an agreement=C2=A0= in place to hold any further flow spec extensions till Flow Spec v2 (with n= ew SAFI) base spec will be at least a WG document.=C2=A0

Based on the above I recommend to wait with the adoption call till t= he draft is able to reference=C2=A0Flow Spec v2 or perhaps=C2=A0directly be= used on its day one input.=C2=A0

Thx,
R= .

On Mon, Feb 24, 2020 at 2:44 PM Susan Hares <shares@ndzh.com> wrote:

Greetings:

=C2=A0=

This begins a IPR call for /raft-li-idr-flowspec= -srv6-02.txt.=C2=A0 The adoption call will begin after all authors have res= ponded to this email with an IPR statement.=C2=A0 For the authors who have = responded before, you will need to respond to this email message as well. = =C2=A0

=C2=A0

A bit thanks to the authors who have waited patiently fo= r the IDR chairs.=C2=A0

=C2= =A0

For the WG general discussion on IDR f= low specification,=C2=A0 this call is to inquiry if this draft=E2=80=99s ap= proach is useful. =C2=A0=C2=A0As has been discussed on the list, the IETF 1= 07 IDR working group meeting will need to decide if all additions to flow s= pecification should go into =C2=A0a version 2 specification.=C2=A0=C2=A0

=C2=A0

In order to have a fruitful discussion regarding the amount of a= dditions for flow specification, we will be calling for the WG to discuss a= ny potential Flow specification drafts.

=C2=A0

Cheers, Sue =

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--00000000000098a8f7059f52b87f-- From nobody Mon Feb 24 05:56:59 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1D73A0BAA for ; Mon, 24 Feb 2020 05:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.225 X-Spam-Level: * X-Spam-Status: No, score=1.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, 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 1o887ni9GIYi for ; Mon, 24 Feb 2020 05:56:56 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 9E0203A0BA7 for ; Mon, 24 Feb 2020 05:56:56 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.177.57.99; From: "Susan Hares" To: Date: Mon, 24 Feb 2020 08:56:52 -0500 Message-ID: <002e01d5eb1a$45068570$cf139050$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002F_01D5EAF0.5C318EE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdXrGSJPHX14e2lcTGSVnN8coN/1ZA== Content-Language: en-us X-Antivirus: AVG (VPS 200223-0, 02/23/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] Any WG LC requested? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 13:56:58 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002F_01D5EAF0.5C318EE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Here are the potential WG LC that I have gotten: . draft-ietf-idr-bgp-open-policy-07.txt , . Draft-ietf-idr-bgp-flowspec-oid Where there others I have missed? The chairs wish to have discussions on the following topics at IETF 107: BGP flow specification, BGP auto-configuration, BGP over IP-SEC, and the latest BGP model draft. If you have additional topics, please make sure you've posted a draft or asked for the next step in WG action (adoption, review, WG LC). I will post a status message in 2 days after this query. Cheerily, Susan Hares ------=_NextPart_000_002F_01D5EAF0.5C318EE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here are = the potential WG LC that I have gotten:

·         = draft-ietf-idr-bgp-open-policy-07.txt = ,

·         = Draft-ietf-idr-bgp-flowspec-oid

 

Where = there others I have missed?  

 

The chairs = wish to have  discussions on the following topics at IETF 107: =   BGP flow specification, BGP auto-configuration,  BGP = over IP-SEC, and the latest BGP model draft.

 

If you have = additional topics, please make sure you’ve posted a draft or asked = for the next step in WG action (adoption, review, WG = LC).

 

I will post a status message in 2 days after this = query. 

 

Cheerily, Susan Hares

 

=  

 

 

 

 

 

------=_NextPart_000_002F_01D5EAF0.5C318EE0-- From nobody Mon Feb 24 06:03:16 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6D53A0BE4 for ; Mon, 24 Feb 2020 06:03:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.225 X-Spam-Level: * X-Spam-Status: No, score=1.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, 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 DzV6gty1Mm1h for ; Mon, 24 Feb 2020 06:03:13 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 3136B3A0BE3 for ; Mon, 24 Feb 2020 06:03:13 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.177.57.99; From: "Susan Hares" To: "'Robert Raszuk'" Cc: "'idr@ietf. org'" References: <000701d5eb18$71a02200$54e06600$@ndzh.com> In-Reply-To: Date: Mon, 24 Feb 2020 09:03:07 -0500 Message-ID: <005301d5eb1b$245bfbb0$6d13f310$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0054_01D5EAF1.3B894F10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFAt0LXlOPhuENPHBUN7FNDwzFqTAFzrM2vqUko0CA= Content-Language: en-us X-Antivirus: AVG (VPS 200223-0, 02/23/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] IPR Call for draft-li-idr-flowspec-srv6 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 14:03:15 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0054_01D5EAF1.3B894F10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Robert:=20 =20 My understanding matches your understanding of the next steps for Flow = Specification. However, I could not find the email from John Scudder = stating this fact. Perhaps I missed it.=20 =20 As a chair, I would like to find out whether people are interested in = addingdraft-li-idr-flowspec-srv6 capability to the flow specification = family. I also would like to find out if there is any IPR on this = technology. So, perhaps this IPR call is necessary.=20 =20 I will probably word my next call about the draft to be an = =E2=80=9Cinterest=E2=80=9D call after John Scudder sends his email . =20 =20 Cheers, Sue=20 =20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Monday, February 24, 2020 8:55 AM To: Susan Hares Cc: idr@ietf. org Subject: Re: [Idr] IPR Call for draft-li-idr-flowspec-srv6 =20 Hi, =20 I think there is an agreement in place to hold any further flow spec = extensions till Flow Spec v2 (with new SAFI) base spec will be at least = a WG document.=20 =20 Based on the above I recommend to wait with the adoption call till the = draft is able to reference Flow Spec v2 or perhaps directly be used on = its day one input.=20 =20 Thx, R.. =20 On Mon, Feb 24, 2020 at 2:44 PM Susan Hares wrote: Greetings:=20 =20 This begins a IPR call for /raft-li-idr-flowspec-srv6-02.txt. The = adoption call will begin after all authors have responded to this email = with an IPR statement. For the authors who have responded before, you = will need to respond to this email message as well. =20 =20 A bit thanks to the authors who have waited patiently for the IDR = chairs. =20 =20 For the WG general discussion on IDR flow specification, this call is = to inquiry if this draft=E2=80=99s approach is useful. As has been = discussed on the list, the IETF 107 IDR working group meeting will need = to decide if all additions to flow specification should go into a = version 2 specification. =20 =20 In order to have a fruitful discussion regarding the amount of additions = for flow specification, we will be calling for the WG to discuss any = potential Flow specification drafts.=20 =20 Cheers, Sue=20 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------=_NextPart_000_0054_01D5EAF1.3B894F10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Robert:

 

My understanding matches your understanding of the next steps for = Flow Specification. =C2=A0=C2=A0However, I could not find the email from = John Scudder stating this fact. =C2=A0=C2=A0Perhaps I missed it. =

 

As a chair, I would like to find out whether people are interested in = addingdraft-li-idr-flowspec-srv6 capability to the flow specification = family.=C2=A0 =C2=A0I also would like to find out if there is any IPR on = this technology.=C2=A0=C2=A0 So, perhaps this IPR call is necessary. =

 

I will probably word my next call about the draft to be an = =E2=80=9Cinterest=E2=80=9D call after John Scudder sends his email = .=C2=A0=C2=A0

 

Cheers, Sue

 

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert = Raszuk
Sent: Monday, February 24, 2020 8:55 AM
To: = Susan Hares
Cc: idr@ietf. org
Subject: Re: [Idr] IPR = Call for draft-li-idr-flowspec-srv6

 

Hi,

 

I = think there is an agreement in place to hold any further flow spec = extensions till Flow Spec v2 (with new SAFI) base spec will be at least = a WG document. 

 

Based on the above I recommend to wait with the = adoption call till the draft is able to reference Flow Spec v2 or = perhaps directly be used on its day one = input. 

 

Thx,

R..

 

On = Mon, Feb 24, 2020 at 2:44 PM Susan Hares <shares@ndzh.com> = wrote:

Greetings: =

 <= /o:p>

This begins = a IPR call for /raft-li-idr-flowspec-srv6-02.txt.  The adoption = call will begin after all authors have responded to this email with an = IPR statement.  For the authors who have responded before, you will = need to respond to this email message as well.  

 <= /o:p>

A bit = thanks to the authors who have waited patiently for the IDR = chairs. 

 <= /o:p>

For the WG = general discussion on IDR flow specification,  this call is to = inquiry if this draft=E2=80=99s approach is useful.   As has = been discussed on the list, the IETF 107 IDR working group meeting will = need to decide if all additions to flow specification should go into =  a version 2 specification.  

 <= /o:p>

In order to = have a fruitful discussion regarding the amount of additions for flow = specification, we will be calling for the WG to discuss any potential = Flow specification drafts.

 <= /o:p>

Cheers, Sue =

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

------=_NextPart_000_0054_01D5EAF1.3B894F10-- From nobody Mon Feb 24 06:05:25 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D6C3A0BE5 for ; Mon, 24 Feb 2020 06:05:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 CYDR7dk99zDl for ; Mon, 24 Feb 2020 06:05:21 -0800 (PST) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (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 5E3853A0A70 for ; Mon, 24 Feb 2020 06:05:21 -0800 (PST) Received: by mail-oi1-x22a.google.com with SMTP id a142so9000370oii.7 for ; Mon, 24 Feb 2020 06:05:21 -0800 (PST) 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=t+Tk2Umgke2V7oIZkX69uXgUyXLG1+QOd+EuYTwfqMc=; b=T9Lh7RIvf5k0/NZ956/obJkBpKIMietDpc0hquKKX/L5ss8lgtp1xvbY37jifZwfB4 Sz/kBXVX6DZ4b2AdGb0rxAl1t0ePOP0obF5EFsVWMivkFeKBUlBitr8wNrCPjZaweLcV 81USuFkV/8+TdKEfPkjggay3A1hV/s1+pMTh/IoDIq/N9usVNt+/l96++hReNa8zQ/H/ a3Te1o6062BudKi13Uc24r8GgzM4U+yxO49YufKIt8KMVLEw+HRoZRIJoP78Iefo7liW kUMgbadaCuAzznM7BI5famHjriUug9X8VGLKArajUf/5uwSacJANV8ibFDo7Gg6FONGf ZtJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=t+Tk2Umgke2V7oIZkX69uXgUyXLG1+QOd+EuYTwfqMc=; b=IcC349dL78GV+Nmrtw8RrVLORaONiIzLvTbTjRyQKAN17F7G+6EhilZdDzvwNn2rQT xhjkrTesFTmo0csLCVdwR59EA2KuSuJjnl9tgbje9kJbOoaTBC7Dzt+6Hp/oAegwwpdQ ZNwipTxspD2mWsh0nBX448xsv6HF1HrWGrsEgtyryLhXQH2QNncFjZ6EU5tJeG/exi7b u9s+mS0I2XzNql3PI14d91B3dDbdV1mZ67WzgCdBcxjCGUmT6jvsSYxDjGWG/xU5wMgu Ho57mKVg1rYlaCHI6ZgSy37AwlMZ6FVE6b215XkntFPbdHS3flqweEyIt734Inlj8/Dv Zy9w== X-Gm-Message-State: APjAAAWvvpKidWEl2oo8kjHtN6rEcVuEGebnDWBxK5vDOcCfPshOJEwM /qRzK9f5j56O3khaA/3kdtHhpPLm34YF3cMxeRWlB4h9Dc8= X-Google-Smtp-Source: APXvYqx7HRNfu/qRgB+PN7yNzOAtq776ed4PEl+4eTniCncUNBE/nYqx2mlHaSOWnFe9HMWweebdXIMjw8d3aBu9h6c= X-Received: by 2002:aca:4106:: with SMTP id o6mr12518882oia.173.1582553120607; Mon, 24 Feb 2020 06:05:20 -0800 (PST) MIME-Version: 1.0 References: <002101d5eb19$12b85e00$38291a00$@ndzh.com> In-Reply-To: <002101d5eb19$12b85e00$38291a00$@ndzh.com> From: Robert Raszuk Date: Mon, 24 Feb 2020 15:05:09 +0100 Message-ID: To: Susan Hares Cc: "idr@ietf. org" Content-Type: multipart/alternative; boundary="00000000000097a8f6059f52dc86" Archived-At: Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-04 - IPR call prior to WG adoption call (2/24 to 3/4) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 14:05:24 -0000 --00000000000097a8f6059f52dc86 Content-Type: text/plain; charset="UTF-8" Hi, We already had adoption call for this draft and comments received were not in favor. May I ask why are we to repeat this all over again especially as the core theme of the draft did not change ? Ref: https://mailarchive.ietf.org/arch/msg/idr/nxjbsrSAsg8TmxKqn_xlUWGbgJU/ https://mailarchive.ietf.org/arch/msg/idr/Jdv3np6vFI8gA7BKkQa1VByCuuI/ https://mailarchive.ietf.org/arch/msg/idr/H_ERZ1h1Ia6K6PR7hQrmIXaJkvI/ Thx, R. PS. Below is the original adoption call: *From:* Idr [mailto:idr-bounces@ietf.org ] *On Behalf Of *Susan Hares *Sent:* Thursday, April 18, 2019 10:05 AM *To:* idr@ietf.org *Subject:* [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call This begins a 2 week WG Adoption call for draft-wu-idr-bgp-segment- allocation-ext-02.txt. You can access the draft at: https://datatracker.ietf.org/doc/draft-wu-idr-bgp-segment-allocation-ext/ In your comments, consider: On Mon, Feb 24, 2020 at 2:48 PM Susan Hares wrote: > Greetings: > > > > This begins an IPR call for draft-wu-idr-bgp-segment-ext-04.txt prior to > WG adoption call. The WG adoption call will begin as soon as all the > authors have responded to this message. > > > > For authors who have responded to an IPR call, please you will need to > again respond to this IPR call. > > > > Cheers, Susan Hares > > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --00000000000097a8f6059f52dc86 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

We already had adopt= ion call for this draft and comments received were not in favor.=C2=A0

May I ask why are we to repeat this all over again esp= ecially as the core theme of the draft did not change ?=C2=A0
Ref:=C2=A0

https://mailarchive= .ietf.org/arch/msg/idr/nxjbsrSAsg8TmxKqn_xlUWGbgJU/=C2=A0
<= br>
Thx,
R.

PS. Below is the orig= inal=C2=A0adoption call:=C2=A0

From:=C2=A0Idr=C2=A0[mailto:idr-bounces@ietf.org]=C2=A0<= b>On Behalf Of=C2=A0Susan Hares
Sent:=C2=A0Thursday, April 18= , 2019 10:05 AM
To:=C2=A0idr@ietf.org
Subject:= =C2=A0[Idr]=C2=A0draft-wu-idr-bgp-se= gment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call<= u>

=C2=A0

Th= is begins a 2 week WG Adoption call for=C2=A0draft= -wu-idr-bgp-segment-allocation-ex= t-02.txt.=C2=A0 You can access the=C2=A0dra= ft=C2=A0at:

=C2=A0

https://datatracker.ietf.org/doc/<= span class=3D"gmail-il">draft-wu-idr-bgp-segment-allocation-ext/

=C2=A0

In your comments, consider:

=C2=A0


On Mon, Feb 24, 2020 at 2:48 PM Susan Hares <shares@ndzh.com> wrote:

Greetings:

=C2=A0

This begins an IPR call for draft-wu-idr-bg= p-segment-ext-04.txt prior to WG adoption call. =C2=A0=C2=A0The WG adoption= call will begin as soon as all the authors have responded to this message.= =C2=A0

=C2=A0

For authors who have responded to an IPR call, please y= ou will need to again respond to this IPR call.

=C2=A0

Cheers, Susan= Hares

=C2=A0

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--00000000000097a8f6059f52dc86-- From nobody Mon Feb 24 07:10:54 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F26753A0CF5 for ; Mon, 24 Feb 2020 07:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.225 X-Spam-Level: * X-Spam-Status: No, score=1.225 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, 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 JJmTvafriSnd for ; Mon, 24 Feb 2020 07:10:49 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 466C23A0CEF for ; Mon, 24 Feb 2020 07:10:49 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.177.57.99; From: "Susan Hares" To: "'Robert Raszuk'" Cc: "'idr@ietf. org'" Date: Mon, 24 Feb 2020 10:10:44 -0500 Message-ID: <001901d5eb24$96376360$c2a62a20$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01D5EAFA.AD63CC60" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdXrJGl396I3pxUlRdq6Dp5kqzHQCQ== Content-Language: en-us X-Antivirus: AVG (VPS 200223-0, 02/23/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-04 - IPR call prior to WG adoption call (2/24 to 3/4) - X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 15:10:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_001A_01D5EAFA.AD63CC60 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Robert:=20 =20 Thank you for letting me know. I will check the authors as they = indicated a change. I appreciate the aid as I=E2=80=99m coming off a = long outage with my hand (and still the pain continues).=20 =20 Susan Hares=20 =20 From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk Sent: Monday, February 24, 2020 9:05 AM To: Susan Hares Cc: idr@ietf. org Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-04 - IPR call = prior to WG adoption call (2/24 to 3/4) =20 Hi, =20 We already had adoption call for this draft and comments received were = not in favor.=20 =20 May I ask why are we to repeat this all over again especially as the = core theme of the draft did not change ?=20 =20 Ref:=20 =20 https://mailarchive..ietf.org/arch/msg/idr/nxjbsrSAsg8TmxKqn_xlUWGbgJU/ = = =20 =20 https://mailarchive.ietf.org/arch/msg/idr/Jdv3np6vFI8gA7BKkQa1VByCuuI/ =20 https://mailarchive.ietf.org/arch/msg/idr/H_ERZ1h1Ia6K6PR7hQrmIXaJkvI/ =20 Thx, R. =20 PS. Below is the original adoption call:=20 =20 From: Idr [mailto: idr-bounces@ietf.org] = On Behalf Of Susan Hares Sent: Thursday, April 18, 2019 10:05 AM To: idr@ietf.org Subject: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - = 5/2/2019] - 2 week WG adoption call =20 This begins a 2 week WG Adoption call for = draft-wu-idr-bgp-segment-allocation-ext-02.txt. You can access the = draft at: =20 https://datatracker.ietf.org/doc/ = draft-wu-idr-bgp-segment-allocation-ext/ =20 In your comments, consider: =20 =20 On Mon, Feb 24, 2020 at 2:48 PM Susan Hares wrote: Greetings:=20 =20 This begins an IPR call for draft-wu-idr-bgp-segment-ext-04.txt prior to = WG adoption call. The WG adoption call will begin as soon as all the = authors have responded to this message. =20 =20 For authors who have responded to an IPR call, please you will need to = again respond to this IPR call.=20 =20 Cheers, Susan Hares=20 =20 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------=_NextPart_000_001A_01D5EAFA.AD63CC60 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Robert:

 

Thank you for letting me know.=C2=A0 I will check the authors as they = indicated a change. =C2=A0=C2=A0I appreciate the aid as I=E2=80=99m = coming off a long outage with my hand (and still the pain continues). =

 

Susan Hares

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert = Raszuk
Sent: Monday, February 24, 2020 9:05 AM
To: = Susan Hares
Cc: idr@ietf. org
Subject: Re: [Idr] = draft-wu-idr-bgp-segment-allocation-ext-04 - IPR call prior to WG = adoption call (2/24 to 3/4)

 

Hi,

 

We already had adoption call for this draft and = comments received were not in favor. 

 

May I ask why are we to repeat this all over again = especially as the core theme of the draft did not change = ? 

 

Ref: 

 

 

Thx,

R.

 

PS. Below is the original adoption = call: 

 

From:=  Idr [mailto:idr-bounces@ietf.org] On Behalf = Of Susan Hares
Sent: Thursday, April 18, 2019 = 10:05 AM
To: idr@ietf.org
Subject: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG = adoption call

 <= /o:p>

This begins = a 2 week WG Adoption call for draft-wu-idr-bgp-segment-allocation-ext-02.txt.  You can access the draft at:

 <= /o:p>

https://datatracker.ietf.org/doc/draft-wu-idr-bgp-segment-allocation-ext/

 <= /o:p>

In your = comments, consider:

 <= /o:p>

 

On = Mon, Feb 24, 2020 at 2:48 PM Susan Hares <shares@ndzh.com> = wrote:

Greetings: =

 <= /o:p>

This begins = an IPR call for draft-wu-idr-bgp-segment-ext-04.txt prior to WG adoption = call.   The WG adoption call will begin as soon as all the = authors have responded to this message. 

 <= /o:p>

For authors = who have responded to an IPR call, please you will need to again respond = to this IPR call.

 <= /o:p>

Cheers, = Susan Hares

 <= /o:p>

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

------=_NextPart_000_001A_01D5EAFA.AD63CC60-- From nobody Mon Feb 24 09:11:46 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515DB3A0EB7 for ; Mon, 24 Feb 2020 09:11:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Aw-qyx6hNCVh for ; Mon, 24 Feb 2020 09:11:41 -0800 (PST) Received: from mail.hated.at (mail.hated.at [IPv6:2001:858:2:8::235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3DAC3A0EB6 for ; Mon, 24 Feb 2020 09:11:41 -0800 (PST) Received: from 80-110-104-164.cgn.dynamic.surfer.at ([80.110.104.164] helo=[192.168.66.207]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1j6HGZ-0004qQ-CL; Mon, 24 Feb 2020 18:11:38 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Christoph Loibl In-Reply-To: <002e01d5eb1a$45068570$cf139050$@ndzh.com> Date: Mon, 24 Feb 2020 18:11:34 +0100 Cc: idr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <1A8EDE9B-0480-4407-B047-BFE4046DAB83@tix.at> References: <002e01d5eb1a$45068570$cf139050$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Idr] Any WG LC requested? X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 17:11:45 -0000 Sue, I would like to see WG LC for: draft-ietf-idr-flow-spec-v6 This is an implemented technology for years, already (I see no value in = postponing this). It has been edited to nicely fit to rfc5575bis (which = I hope is now close to publication as well).=20 Cheers Christoph --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > On 24.02.2020, at 14:56, Susan Hares wrote: >=20 > Here are the potential WG LC that I have gotten:=20 > =C2=B7 draft-ietf-idr-bgp-open-policy-07.txt , > =C2=B7 Draft-ietf-idr-bgp-flowspec-oid > =20 > Where there others I have missed? =20 > =20 > The chairs wish to have discussions on the following topics at IETF = 107: BGP flow specification, BGP auto-configuration, BGP over IP-SEC, = and the latest BGP model draft.=20 > =20 > If you have additional topics, please make sure you=E2=80=99ve posted = a draft or asked for the next step in WG action (adoption, review, WG = LC). > =20 > I will post a status message in 2 days after this query. =20 > =20 > Cheerily, Susan Hares=20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Mon Feb 24 11:22:02 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94643A1182 for ; Mon, 24 Feb 2020 11:21:59 -0800 (PST) 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_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=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 3tW2SfPVzqEi for ; Mon, 24 Feb 2020 11:21:57 -0800 (PST) Received: from NAM12-DM6-obe.outbound.protection.outlook.com (mail-dm6nam12on2109.outbound.protection.outlook.com [40.107.243.109]) (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 956033A117D for ; Mon, 24 Feb 2020 11:21:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dLNJXjCvfxdxZmXfldyX0DqjFaFtJ//1+hC6w0HPxspfnlSjmUKvOevdRLAKZ2aT8CWD2Rg0dsHDrmVs5V176eePtmtahQiZicwppsqpsLS7eUvADSApZ080jPEAJMSIPpKuzlykaOYR+cREBzufULay9BCj11hU0YMJNC3mT/Om+vxeqHZbyi7TlGiWKGBJCH94L4xwD9AdTb3+9SLYuNzeOgQNz4bmvsouxvvbuXqgZYQhYT4t1wGn4pdcJjK2e7SIXfo4kmgWUFsc2UqxVcdeOhRfMtrDIrET638ex7N9MXBHYHWnRqDMj6NJ8IkwrhMjLSS5yqLcd9b0w1QR8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=j0Pc9irF6fXYZ0k1/9q4OSkhzlNcsG5ZpUxp82APhGo=; b=KenCKOuh0osW35hwc7l0HCcKlJlsg3z+CYxvQetJqN2NP+9TVnNUVNEGow3PrLt4G/GOG0NfL+koORuVTnEi1ASRITnYqvIvjdC3vkVU8UT6OW+7MjAdklfyymHeWdQBkvPSs3d6NwE8i0F5nLjNTTDfW83aPbiqjAweUviZOuqxcbSXkrcGmXNBO5IYKaFUTDNCXIliMLrncTeDLV+fYHaFpOdGdgZgNbet3U+R/TKaOtRO6eVLL9LmQy7xCDViBlPit0iGN5VmbD6fuz2bjHLygf1g1knzjd9p35rjMreOKenaMlEmyVZ8yl79x6FuZnhRQM/sVS/uuyrjk9mW4A== 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=j0Pc9irF6fXYZ0k1/9q4OSkhzlNcsG5ZpUxp82APhGo=; b=a35G/qUEgw/BiRTJj79Wj8MOzN7+X0LGccJbMoYOxb6hOuCjnJurl2F9csCl6FJqygwHoiP6l60sgo9URWNFFdbKgoEtxmnaNRTSEM+so2SEI8/qrwCU42RkKvosBGBauT/hoLXRwh5H2bokTWYYRHp7bPtH0SCl2hN2FBpSW1U= Received: from BY5PR13MB3651.namprd13.prod.outlook.com (2603:10b6:a03:22e::19) by BY5PR13MB3540.namprd13.prod.outlook.com (2603:10b6:a03:1ab::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2772.9; Mon, 24 Feb 2020 19:21:54 +0000 Received: from BY5PR13MB3651.namprd13.prod.outlook.com ([fe80::789b:f4a:c3e3:e921]) by BY5PR13MB3651.namprd13.prod.outlook.com ([fe80::789b:f4a:c3e3:e921%7]) with mapi id 15.20.2772.012; Mon, 24 Feb 2020 19:21:54 +0000 From: Huaimo Chen To: Robert Raszuk , Susan Hares CC: "idr@ietf. org" Thread-Topic: [Idr] draft-wu-idr-bgp-segment-allocation-ext-04 - IPR call prior to WG adoption call (2/24 to 3/4) Thread-Index: AdXrGPiwgmyjrHdoRa2SgqmdS5rX2AAAnOOAAAp/6kk= Date: Mon, 24 Feb 2020 19:21:54 +0000 Message-ID: References: <002101d5eb19$12b85e00$38291a00$@ndzh.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huaimo.chen@futurewei.com; x-originating-ip: [12.111.81.95] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f9c4330c-41cb-4836-51cd-08d7b95ecf11 x-ms-traffictypediagnostic: BY5PR13MB3540: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 032334F434 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(376002)(366004)(346002)(39850400004)(136003)(189003)(199004)(76116006)(186003)(5660300002)(9686003)(8936002)(55016002)(966005)(64756008)(86362001)(66446008)(66556008)(66946007)(66476007)(4326008)(110136005)(8676002)(26005)(71200400001)(316002)(19627405001)(2906002)(7696005)(478600001)(44832011)(81156014)(6506007)(52536014)(53546011)(81166006)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR13MB3540; H:BY5PR13MB3651.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3IwVhbBqmOAPeaJmzn0+cWD00BgtHtecSv7GyBU0yAJmIIimlajwbol7UKptApJTfVGYqXS9QhJY6bzHvmX9rLBCVKBJO0wze0Hw+6RgUeE5sNUKUgoxy6Z4wVBElLofpbpgdusW+KmhbhyhCpzFM8D4Cj8CQL9GiHABlmXKNLIRFEXYJ/6qnG0ep/vE7iN9rBnuAFimYC+0g2hiIdUailoUt6WiaG6rseZRsMOJoc7sBbn9/8equR8D59sLkCMQEy5S21NL8KmCRiL7kdTRoozIcG7Bkda8/hgZBVsFrg6IWJeoWUcACQ4CgKdXUVY6cZ48zDZmaPL5tLNi7T+xY8lPNnh3Tqr56lFd+mEsZLJZMKfR+uSdSfkldq0+q4tWDCJGzp0l5hs8YDVXgCChyvccvSmPjgps2yQNd3o6NkqkZ9/iGfGsO+09xThngB7L/trXClehUem+pUu6TTjH21D4rEgLY/916Dc4vrxDDvVnGelwIv2UBDFV1xVJZ4Gu5iwQiGxHhfM18BB6eOO4JQ== x-ms-exchange-antispam-messagedata: AKL7mKbmYg0mK7TI1DGGA3nW1RMMuSLDFsgwPXh2cIebbzLO+dMU3IDUwQgbXCwGzbTnxQVfyKiTspyY1iqL/kR9G5jkqvLIUI/oDBYNZPi7fgvpR88XI8T5LF3heACAymUDvcxb4klfz3yHnFYI2A== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BY5PR13MB3651BBA5ACA8C037B3292289F2EC0BY5PR13MB3651namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-Network-Message-Id: f9c4330c-41cb-4836-51cd-08d7b95ecf11 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2020 19:21:54.7471 (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: oANV9cWUhMrEhI1iD9U+Tm0opeX84uO5A/UNu9G8QxwSe3U6WOPCSKfTHlfWShUH1rMsoUuxVQvPgKF7Jh7Jbg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY5PR13MB3540 Archived-At: Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-04 - IPR call prior to WG adoption call (2/24 to 3/4) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 19:22:00 -0000 --_000_BY5PR13MB3651BBA5ACA8C037B3292289F2EC0BY5PR13MB3651namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Robert, We have addressed all the comments from the last adoption call [4/18 - = 5/2/2019] in the updated document/draft. For example, the extensions to BG= P-LS for SIDs are removed, and a new AFI/SAFI for SIDs is used as suggested= by some people. This seems a core change. The updated document is presented in IETF 106, and there is no objectio= n during our presentation. In addition, I have communicated with all the people who were against t= he adoption during the last adoption call and did not receive any objection= . Only one person hopes that Yang could be used for SIDs. Best Regards, Huaimo ________________________________ From: Idr on behalf of Robert Raszuk Sent: Monday, February 24, 2020 9:05 AM To: Susan Hares Cc: idr@ietf. org Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-04 - IPR call pr= ior to WG adoption call (2/24 to 3/4) Hi, We already had adoption call for this draft and comments received were not = in favor. May I ask why are we to repeat this all over again especially as the core t= heme of the draft did not change ? Ref: https://mailarchive..ietf.org/arch/msg/idr/nxjbsrSAsg8TmxKqn_xlUWGbgJU/ https://mailarchive.ietf.org/arch/msg/idr/Jdv3np6vFI8gA7BKkQa1VByCuuI/ https://mailarchive.ietf.org/arch/msg/idr/H_ERZ1h1Ia6K6PR7hQrmIXaJkvI/ Thx, R. PS. Below is the original adoption call: From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, April 18, 2019 10:05 AM To: idr@ietf.org Subject: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2= 019] - 2 week WG adoption call This begins a 2 week WG Adoption call for draft-wu-idr-bgp-segment-allocati= on-ext-02.txt. You can access the draft at: https://datatracker.ietf.org/doc/draft-wu-idr-bgp-segment-allocation-ext/ In your comments, consider: On Mon, Feb 24, 2020 at 2:48 PM Susan Hares > wrote: Greetings: This begins an IPR call for draft-wu-idr-bgp-segment-ext-04.txt prior to WG= adoption call. The WG adoption call will begin as soon as all the author= s have responded to this message. For authors who have responded to an IPR call, please you will need to agai= n respond to this IPR call. Cheers, Susan Hares _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr --_000_BY5PR13MB3651BBA5ACA8C037B3292289F2EC0BY5PR13MB3651namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Robert,
  
    We have addressed all the comments from the last adoption cal= l [4/18 - 5/2/2019] in the updated document/draft.  For example,&= nbsp;the extensions to BGP-LS for SIDs are removed, and a new AFI/SAFI for = SIDs is used as suggested by some people. This seems a core change.

    The= updated document is presented in IETF 106, and there is no objectio= n during our presentation.

    In addition, I have communicated with all the people who were= against the adoption during the last adoption call and did not receive any= objection. Only one person hopes that Yang could be used for SIDs.

Best Regards,
Huaimo
From: Idr <idr-bounces@i= etf.org> on behalf of Robert Raszuk <robert@raszuk.net>
Sent: Monday, February 24, 2020 9:05 AM
To: Susan Hares <shares@ndzh.com>
Cc: idr@ietf. org <idr@ietf.org>
Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-04 - IPR = call prior to WG adoption call (2/24 to 3/4)
 
Hi,

We already had adoption call for this draft and comments received were= not in favor. 

May I ask why are we to repeat this all over again especially as the c= ore theme of the draft did not change ? 

Ref: 

h= ttps://mailarchive..ietf.org/arch/msg/idr/nxjbsrSAsg8TmxKqn_xlUWGbgJU/&= nbsp;


Thx,
R.

PS. Below is the original adoption call: 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Thursday, April 18, 2019 10:05 AM
To: idr@ietf.org
Subject: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call

 

This begins a 2 week WG Adopt= ion call for draft-wu-idr-bgp-segment-allocation-ext-02.= txt.  You can access the draft at:

 

https://datatrack= er.ietf.org/doc/draft-wu-idr-bgp-segment-allocation-ext/

 

In your comments, consider:

 


On Mon, Feb 24, 2020 at 2:48 PM Sus= an Hares <shares@ndzh.com> wro= te:

Greetings:

 

This begins an IPR call for draft-wu-idr-bgp-segme= nt-ext-04.txt prior to WG adoption call.   The WG adoption call w= ill begin as soon as all the authors have responded to this message. 

 

For authors who have responded to an IPR call, ple= ase you will need to again respond to this IPR call.

 

Cheers, Susan Hares

 

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr=
--_000_BY5PR13MB3651BBA5ACA8C037B3292289F2EC0BY5PR13MB3651namp_-- From nobody Mon Feb 24 11:29:50 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6467A3A1191 for ; Mon, 24 Feb 2020 11:29:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.325 X-Spam-Level: * X-Spam-Status: No, score=1.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, 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 HipzTGDoWdPK for ; Mon, 24 Feb 2020 11:29:46 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 78D2C3A0D7F for ; Mon, 24 Feb 2020 11:29:46 -0800 (PST) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=166.177.57.99; From: "Susan Hares" To: "'Huaimo Chen'" , "'Robert Raszuk'" Cc: "'idr@ietf. org'" References: <002101d5eb19$12b85e00$38291a00$@ndzh.com>, In-Reply-To: Date: Mon, 24 Feb 2020 14:29:41 -0500 Message-ID: <001101d5eb48$c376c090$4a6441b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01D5EB1E.DAA23F30" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGHX67QpzVXGpvgBgADZxXZ01QUAQGa8i05AnKmZ1+op2UgYA== Content-Language: en-us X-Antivirus: AVG (VPS 200223-0, 02/23/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-04 - IPR call prior to WG adoption call (2/24 to 3/4) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Feb 2020 19:29:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0012_01D5EB1E.DAA23F30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Robert and Huaimo: Perhaps Robert has some nagging concerns. You might want to discuss this point before I start the WG adoption call (either on/off list) Cheers, Sue From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Huaimo Chen Sent: Monday, February 24, 2020 2:22 PM To: Robert Raszuk; Susan Hares Cc: idr@ietf. org Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-04 - IPR call prior to WG adoption call (2/24 to 3/4) Hi Robert, We have addressed all the comments from the last adoption call [4/18 - 5/2/2019] in the updated document/draft. For example, the extensions to BGP-LS for SIDs are removed, and a new AFI/SAFI for SIDs is used as suggested by some people. This seems a core change. The updated document is presented in IETF 106, and there is no objection during our presentation. In addition, I have communicated with all the people who were against the adoption during the last adoption call and did not receive any objection. Only one person hopes that Yang could be used for SIDs. Best Regards, Huaimo _____ From: Idr on behalf of Robert Raszuk Sent: Monday, February 24, 2020 9:05 AM To: Susan Hares Cc: idr@ietf. org Subject: Re: [Idr] draft-wu-idr-bgp-segment-allocation-ext-04 - IPR call prior to WG adoption call (2/24 to 3/4) Hi, We already had adoption call for this draft and comments received were not in favor. May I ask why are we to repeat this all over again especially as the core theme of the draft did not change ? Ref: https://mailarchive..ietf.org/arch/msg/idr/nxjbsrSAsg8TmxKqn_xlUWGbgJU/ https://mailarchive.ietf.org/arch/msg/idr/Jdv3np6vFI8gA7BKkQa1VByCuuI/ https://mailarchive.ietf.org/arch/msg/idr/H_ERZ1h1Ia6K6PR7hQrmIXaJkvI/ Thx, R. PS. Below is the original adoption call: From: Idr [mailto: idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Thursday, April 18, 2019 10:05 AM To: idr@ietf.org Subject: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG adoption call This begins a 2 week WG Adoption call for draft-wu-idr-bgp-segment-allocation-ext-02.txt. You can access the draft at: https://datatracker.ietf.org/doc/ draft-wu-idr-bgp-segment-allocation-ext/ In your comments, consider: On Mon, Feb 24, 2020 at 2:48 PM Susan Hares wrote: Greetings: This begins an IPR call for draft-wu-idr-bgp-segment-ext-04.txt prior to WG adoption call. The WG adoption call will begin as soon as all the authors have responded to this message. For authors who have responded to an IPR call, please you will need to again respond to this IPR call. Cheers, Susan Hares _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr ------=_NextPart_000_0012_01D5EB1E.DAA23F30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Robert and Huaimo:

 

Perhaps Robert has some nagging concerns.  You might want to = discuss this point before I start the WG adoption call (either on/off = list)

 

Cheers, Sue

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Huaimo = Chen
Sent: Monday, February 24, 2020 2:22 PM
To: = Robert Raszuk; Susan Hares
Cc: idr@ietf. = org
Subject: Re: [Idr] = draft-wu-idr-bgp-segment-allocation-ext-04 - IPR call prior to WG = adoption call (2/24 to 3/4)

 

Hi = Robert,

  

    = We have addressed all the comments from the last adoption = call [4/18 - 5/2/2019] in the updated document/draft.  For = example, the extensions to BGP-LS for SIDs are removed, and a new = AFI/SAFI for SIDs is used as suggested by some people. This seems a core = change.

 

    = The updated document is presented in = IETF 106, and there is no objection during our = presentation.

 

    = In addition, I have communicated with all the people who were against = the adoption during the last adoption call and did not receive any = objection. Only one person hopes that Yang could be used for = SIDs.

 

Best = Regards,

Huaimo

From: Idr <idr-bounces@ietf.org> on behalf of Robert Raszuk = <robert@raszuk.net>
Sent: Monday, February 24, 2020 9:05 = AM
To: Susan Hares <shares@ndzh.com>
Cc: = idr@ietf. org <idr@ietf.org>
Subject: Re: [Idr] = draft-wu-idr-bgp-segment-allocation-ext-04 - IPR call prior to WG = adoption call (2/24 to 3/4)

 

Hi,

 

We already had adoption call for this draft and = comments received were not in favor. 

 

May I ask why are we to repeat this all over again = especially as the core theme of the draft did not change = ? 

 

Ref: 

 

 

Thx,

R.

 

PS. Below is the original adoption = call: 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf = Of Susan Hares
Sent: Thursday, April 18, 2019 = 10:05 AM
To: idr@ietf.org
Subject: [Idr] draft-wu-idr-bgp-segment-allocation-ext-02.txt [4/18 - 5/2/2019] - 2 week WG = adoption call

 

This = begins a 2 week WG Adoption call for draft-wu-idr-bgp-segment-allocation-ext-02.txt.  You can access the draft at:

 

https://datatracker.ietf.org/doc/draft-wu-idr-bgp-segment-allocation-ext/

 

In your = comments, consider:

 

 

On = Mon, Feb 24, 2020 at 2:48 PM Susan Hares <shares@ndzh.com> = wrote:

Greetings:

 

This = begins an IPR call for draft-wu-idr-bgp-segment-ext-04.txt prior to WG = adoption call.   The WG adoption call will begin as soon as = all the authors have responded to this message. 

 

For = authors who have responded to an IPR call, please you will need to again = respond to this IPR call.

 

Cheers, = Susan Hares

 

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

------=_NextPart_000_0012_01D5EB1E.DAA23F30-- From nobody Mon Feb 24 18:01:32 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4775A3A17D4 for ; Mon, 24 Feb 2020 18:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 hV6iQVGmM64Z for ; Mon, 24 Feb 2020 18:01:30 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 E17B83A17D3 for ; Mon, 24 Feb 2020 18:01:29 -0800 (PST) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 5337D7AE9F892CDF463B for ; Tue, 25 Feb 2020 02:01:26 +0000 (GMT) Received: from lhreml740-chm.china.huawei.com (10.201.108.190) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 25 Feb 2020 02:01:23 +0000 Received: from lhreml740-chm.china.huawei.com (10.201.108.190) by lhreml740-chm.china.huawei.com (10.201.108.190) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 25 Feb 2020 02:01:23 +0000 Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by lhreml740-chm.china.huawei.com (10.201.108.190) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Tue, 25 Feb 2020 02:01:23 +0000 Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.172]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0439.000; Tue, 25 Feb 2020 10:01:15 +0800 From: "Chengli (Cheng Li)" To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] IPR for draft-li-idr-sr-policy-path-mtu-03.txt prior to WG adoptin (2/24 - 3/4) Thread-Index: AdXrGLu8VdwGY2PMRAazpaejfCi/jwAZbPBA Date: Tue, 25 Feb 2020 02:01:15 +0000 Message-ID: References: <001401d5eb18$bc742b50$355c81f0$@ndzh.com> In-Reply-To: <001401d5eb18$bc742b50$355c81f0$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.229] Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB02929F54dggeml529mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] IPR for draft-li-idr-sr-policy-path-mtu-03.txt prior to WG adoptin (2/24 - 3/4) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 02:01:31 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CB02929F54dggeml529mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Sue, I do not know any IPR related to this document. Many thanks, Cheng From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, February 24, 2020 9:46 PM To: idr@ietf.org Subject: [Idr] IPR for draft-li-idr-sr-policy-path-mtu-03.txt prior to WG a= doptin (2/24 - 3/4) Greetings: This is an IPR call prior to a WG Adoption call for draft-li-idr-sr-policy-= path-mtu-03.txt. The authors should respond to this message even if they h= ave responded before. The WG group adoption call will begin as soon as all authors have responded= . Cheerily, Sue --_000_C7C2E1C43D652C4E9E49FE7517C236CB02929F54dggeml529mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Sue,

 

I do not know any IPR = related to this document.

 

Many thanks,

Cheng

 

 

From: Idr [mailto:idr-bounces@ietf.org] On= Behalf Of Susan Hares
Sent: Monday, February 24, 2020 9:46 PM
To: idr@ietf.org
Subject: [Idr] IPR for draft-li-idr-sr-policy-path-mtu-03.txt prior = to WG adoptin (2/24 - 3/4)

 

Greetings:

 

This is an IPR call prior to a WG Adoption call for = draft-li-idr-sr-policy-path-mtu-03.txt.  The authors should respond to= this message even if they have responded before.

 

The WG group adoption call will begin as soon as all= authors have responded.

 

Cheerily,  Sue

--_000_C7C2E1C43D652C4E9E49FE7517C236CB02929F54dggeml529mbxchi_-- From nobody Mon Feb 24 18:39:03 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387D83A0415 for ; Mon, 24 Feb 2020 18:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Ll8xlnR-UGgc for ; Mon, 24 Feb 2020 18:39:01 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 85DCC3A041A for ; Mon, 24 Feb 2020 18:39:01 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 48C552D82FDD1689AF54 for ; Tue, 25 Feb 2020 02:38:58 +0000 (GMT) Received: from lhreml728-chm.china.huawei.com (10.201.108.79) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 25 Feb 2020 02:38:57 +0000 Received: from lhreml728-chm.china.huawei.com (10.201.108.79) by lhreml728-chm.china.huawei.com (10.201.108.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 25 Feb 2020 02:38:57 +0000 Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml728-chm.china.huawei.com (10.201.108.79) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Tue, 25 Feb 2020 02:38:57 +0000 Received: from DGGEMM532-MBX.china.huawei.com ([169.254.7.192]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0439.000; Tue, 25 Feb 2020 10:38:53 +0800 From: Lizhenbin To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] IPR Call for draft-li-idr-flowspec-srv6 Thread-Index: AdXrF6YefQ/aBuJURImPFwA7se+WjAAbOtuQ Date: Tue, 25 Feb 2020 02:38:52 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D936450D6@DGGEMM532-MBX.china.huawei.com> References: <000701d5eb18$71a02200$54e06600$@ndzh.com> In-Reply-To: <000701d5eb18$71a02200$54e06600$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.206.84] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D936450D6DGGEMM532MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] IPR Call for draft-li-idr-flowspec-srv6 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 02:39:03 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D936450D6DGGEMM532MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am not aware of any IPR related with the draft. Best Regards, Zhenbin (Robin) From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, February 24, 2020 9:44 PM To: idr@ietf.org Subject: [Idr] IPR Call for draft-li-idr-flowspec-srv6 Greetings: This begins a IPR call for /raft-li-idr-flowspec-srv6-02.txt. The adoption= call will begin after all authors have responded to this email with an IPR= statement. For the authors who have responded before, you will need to re= spond to this email message as well. A bit thanks to the authors who have waited patiently for the IDR chairs. For the WG general discussion on IDR flow specification, this call is to i= nquiry if this draft's approach is useful. As has been discussed on the l= ist, the IETF 107 IDR working group meeting will need to decide if all addi= tions to flow specification should go into a version 2 specification. In order to have a fruitful discussion regarding the amount of additions fo= r flow specification, we will be calling for the WG to discuss any potentia= l Flow specification drafts. Cheers, Sue --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D936450D6DGGEMM532MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am not aware of any IPR related with the draft.

 

 

Best Regards,

Zhenbin (Robin)

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, February 24, 2020 9:44 PM
To: idr@ietf.org
Subject: [Idr] IPR Call for draft-li-idr-flowspec-srv6

 

Greetings:

 

This begins a IPR call for /raf= t-li-idr-flowspec-srv6-02.txt.  The adoption call will begin after all= authors have responded to this email with an IPR statement.  For the = authors who have responded before, you will need to respond to this email message as well.  

 

A bit thanks to the authors who= have waited patiently for the IDR chairs. 

 

For the WG general discussion o= n IDR flow specification,  this call is to inquiry if this draft’= ;s approach is useful.   As has been discussed on the list, the I= ETF 107 IDR working group meeting will need to decide if all additions to flow specification should go into  a version 2 speci= fication.  

 

In order to have a fruitful dis= cussion regarding the amount of additions for flow specification, we will b= e calling for the WG to discuss any potential Flow specification drafts.

 

Cheers, Sue <= /p>

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D936450D6DGGEMM532MBXchi_-- From nobody Mon Feb 24 18:39:28 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D46AB3A053E for ; Mon, 24 Feb 2020 18:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Jb1THorQsu31 for ; Mon, 24 Feb 2020 18:39:19 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 286043A0785 for ; Mon, 24 Feb 2020 18:39:19 -0800 (PST) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id DDD008923F6CB457B377 for ; Tue, 25 Feb 2020 02:39:16 +0000 (GMT) Received: from lhreml729-chm.china.huawei.com (10.201.108.80) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 25 Feb 2020 02:39:16 +0000 Received: from lhreml729-chm.china.huawei.com (10.201.108.80) by lhreml729-chm.china.huawei.com (10.201.108.80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 25 Feb 2020 02:39:16 +0000 Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml729-chm.china.huawei.com (10.201.108.80) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Tue, 25 Feb 2020 02:39:16 +0000 Received: from DGGEMM532-MBX.china.huawei.com ([169.254.7.192]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0439.000; Tue, 25 Feb 2020 10:39:11 +0800 From: Lizhenbin To: Susan Hares , "idr@ietf.org" Thread-Topic: [Idr] IPR for draft-li-idr-sr-policy-path-mtu-03.txt prior to WG adoptin (2/24 - 3/4) Thread-Index: AdXrGLu8VdwGY2PMRAazpaejfCi/jwAa/8Gg Date: Tue, 25 Feb 2020 02:39:10 +0000 Message-ID: <5A5B4DE12C0DAC44AF501CD9A2B01A8D936450E2@DGGEMM532-MBX.china.huawei.com> References: <001401d5eb18$bc742b50$355c81f0$@ndzh.com> In-Reply-To: <001401d5eb18$bc742b50$355c81f0$@ndzh.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.206.84] Content-Type: multipart/alternative; boundary="_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D936450E2DGGEMM532MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Idr] IPR for draft-li-idr-sr-policy-path-mtu-03.txt prior to WG adoptin (2/24 - 3/4) X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 02:39:27 -0000 --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D936450E2DGGEMM532MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am not aware of any IPR related with the draft. Best Regards, Zhenbin (Robin) From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, February 24, 2020 9:46 PM To: idr@ietf.org Subject: [Idr] IPR for draft-li-idr-sr-policy-path-mtu-03.txt prior to WG a= doptin (2/24 - 3/4) Greetings: This is an IPR call prior to a WG Adoption call for draft-li-idr-sr-policy-= path-mtu-03.txt. The authors should respond to this message even if they h= ave responded before. The WG group adoption call will begin as soon as all authors have responded= . Cheerily, Sue --_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D936450E2DGGEMM532MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am not aware of any IPR related with the draft.

 

 

Best Regards,

Zhenbin (Robin)

 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, February 24, 2020 9:46 PM
To: idr@ietf.org
Subject: [Idr] IPR for draft-li-idr-sr-policy-path-mtu-03.txt prior = to WG adoptin (2/24 - 3/4)

 

Greetings:

 

This is an IPR call prior to a = WG Adoption call for draft-li-idr-sr-policy-path-mtu-03.txt.  The auth= ors should respond to this message even if they have responded before.

 

The WG group adoption call will= begin as soon as all authors have responded.

 

Cheerily,  Sue =

--_000_5A5B4DE12C0DAC44AF501CD9A2B01A8D936450E2DGGEMM532MBXchi_-- From nobody Tue Feb 25 09:09:18 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6287C3A10BA; Tue, 25 Feb 2020 09:09:15 -0800 (PST) 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, 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 mPIQBomqii1X; Tue, 25 Feb 2020 09:09:12 -0800 (PST) Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2082.outbound.protection.outlook.com [40.107.93.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 21A713A10B9; Tue, 25 Feb 2020 09:09:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MVNBqbWOaonq0urwzwADUmLb5fTSMb9t1I9hWXEQN4vk6rUNv7MsRn4NjLRrMOH9SryX30m76hBJp7A4IFl6xqHYtWEv4F6xBpCMWZebyJZGY2V35NvLbXIXrsykPRHRfgwCKFiAAXbWbnTXczq74SoJ6AE0rMJw63bfgYCwHUr+omlFN6tLHZVmGP9NM3kCx3P23i+uz7y9PJhqrfmCg5Yhpsttgl/9cO+JdLGE6UquWPhYqLW+zZ0UD9/Qj652ddahOIGV4FUosSj9+B444wyUtfnw0NzN23r5b7OJ6sx3Ee/0pltCvsZcjIwifHKR7YA4mVUD/rOt5WnsLARghQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3l4mPAD4+qrKzFPssrNVk8HnGCPkZJrFcbDlnlpoxzk=; b=J2tZ5hymx4K69X9wok8mtcBEJOZ3kWf6pGgNRCA3M9VaILwWWhtMt+KqroPG/EP5q7btNlAh7S1VP3KC1a3zgjyBSmqmzLsfkpb0W0XJp928gH6d8oTk4c3vs/ZO9//cf6nPF9gn1dCo76ASLXG2071Rw48L6j5AR5S4bZUFkfgugT1eGT5rU4C9Iwizh09wYrqqO28fhB4m4b2uw3waM8tbvCOG6TFXa0+WygXKKSvaGdopkLrCtGYE98rRaM8kpD1C5aoSqZFZ8YWsX485c1lG5VF0K9JoTvo8kPBSj3CJ6VJTYPRXAKIocI0XZTAGPqOZUUYg8J1FJl2jDXcEaQ== 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=3l4mPAD4+qrKzFPssrNVk8HnGCPkZJrFcbDlnlpoxzk=; b=P/87sRkig+mcs+JOgNGboefEo+skLpKapaFvq0xzsHsk3b5MlXIPtVr3pbLkp08eTJOKRG3MLrep0T+IP9/2LYKPbkWG7990Ad1W+aBptZtgbenLkUWFZ9MDX+O6TAUTSUINsj9yMl8TdeozFtxXrFrmEXol2WNkMe3v40MSVBc= Received: from BYAPR18MB2856.namprd18.prod.outlook.com (2603:10b6:a03:10e::30) by BYAPR18MB3047.namprd18.prod.outlook.com (2603:10b6:a03:105::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2750.21; Tue, 25 Feb 2020 17:09:08 +0000 Received: from BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::9ca8:5fd:8296:7b05]) by BYAPR18MB2856.namprd18.prod.outlook.com ([fe80::9ca8:5fd:8296:7b05%4]) with mapi id 15.20.2750.021; Tue, 25 Feb 2020 17:09:08 +0000 From: Keyur Patel To: Alvaro Retana , "draft-ietf-idr-tunnel-encaps@ietf.org" CC: John Scudder , "idr-chairs@ietf.org" , "idr@ietf. org" Thread-Topic: AD Review of draft-ietf-idr-tunnel-encaps-15 Thread-Index: AQHV6LUXjzaZiEFG+kyS9ZPP8NcJvKgrpQ4A Date: Tue, 25 Feb 2020 17:09:08 +0000 Message-ID: <8BBF5B52-4CBE-4101-8FAD-CDB50D1149E3@arrcus.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.22.0.200209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=keyur@arrcus.com; x-originating-ip: [70.234.233.187] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4f8c3d7b-f399-4ad5-7538-08d7ba156d31 x-ms-traffictypediagnostic: BYAPR18MB3047: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0324C2C0E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39830400003)(136003)(366004)(346002)(396003)(199004)(189003)(6486002)(2906002)(81166006)(8676002)(71200400001)(81156014)(508600001)(4326008)(5660300002)(2616005)(66946007)(66476007)(54906003)(110136005)(316002)(6506007)(64756008)(66446008)(66556008)(8936002)(6512007)(33656002)(30864003)(86362001)(76116006)(66574012)(26005)(966005)(36756003)(186003)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR18MB3047; H:BYAPR18MB2856.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arrcus.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ptTrxCEOFZMD70z3O+4EyC+CRmNxcM1/KVTuW3X+uK5soP5gNqcUXEj6Z6SQqAwIXFkHg39LlkUcE0x16WyqEE3RMce2YxMX0tYaQlirrrVDZRhYOob9lcPQ2euXuTpEdWUs+vAuLxMkdHj17eIAsHY9vqmyTEDSGxRuNoM8/a2ypvkOlZ5OTf4Jz0+fOrOkOJInCAH8sJTKDItzS8UIB11QPL++5yvwOg615SUdIbYPsxRQXewuOGjn1ki9L9hMpdrMQxjKa3RrQ1ZCYDRjpKtXNShWAFmpVv9USfw4nOowW7u81GvyTGbrCDS6JI4/qe2IE6JM8bZrsrO7TNMvnt65KVBaADU11DXacGRkM78o/G01PXgUQkM6oHBBsZtuWDK4CAQbImauFbBp4h4R4n2BHPCHrXUPmG5iCMwpSxYrCdSJLlfH8q63TLZjEjSoEpRYSYqWwaV7exgM98FrmCIu2vYL7Rtg3AjLiTTfeFatg78UMd2hdU7HbN6dmm3PI+LEJqn8wnhilbV6V5I/eA== x-ms-exchange-antispam-messagedata: cJQbGjXrQE2p4tZRrQWNTvPG8tb3UkcIJs5l5eOMihBAaOkIaKmXOu5VqGvnOJof9zBMsqY1uxYOGabXZ7qP6MZoUSTu/Vp6zPdFqE+aptVUjUzKcXfOyRZ5ENtUxqtYHdfTtU/6ylCJZfvUlG9bdA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <209DF51AAC49724CA9C6C0FD664B1EC4@namprd18.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: arrcus.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4f8c3d7b-f399-4ad5-7538-08d7ba156d31 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Feb 2020 17:09:08.4642 (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: hthMtSE0GNyu579LUo91mtFBLd/CI4brUZut8SJRvz3j+YthUQeUujWJSh+hShMfiO7NQg+ZPxjcJgQXohGnCg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR18MB3047 Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-tunnel-encaps-15 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Feb 2020 17:09:16 -0000 SGkgQWx2YXJvLA0KDQpUaGFua3MgZm9yIHRoZSBkZXRhaWwgcmV2aWV3IGFuZCBjb21tZW50cy4g V2Ugd2lsbCBnZXQgYmFjayB0byB5b3Ugc29vbiB3aXRoIG91ciByZXNwb25zZS4NCg0KUmVnYXJk cywNCktleXVyDQoNCu+7v09uIDIvMjEvMjAsIDQ6NDcgQU0sICJBbHZhcm8gUmV0YW5hIiA8YXJl dGFuYS5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQoNCiAgICBEZWFyIGF1dGhvcnM6DQogICAgDQog ICAgSGVyZSBpcyBteSByZXZpZXcgb2YgZHJhZnQtaWV0Zi1pZHItdHVubmVsLWVuY2Fwcy0xNS4g IFRoYW5rIHlvdSBmb3INCiAgICBhbGwgdGhlIHdvcmsgdGhhdCB5b3UgYW5kIHRoZSBXRyBoYXZl IHB1dCBpbnRvIGl0Lg0KICAgIA0KICAgIFdoaWxlIHRoaXMgaXMgYSBnb29kIGRvY3VtZW50LCBJ IGRvIGhhdmUgYSBzaWduaWZpY2FudCBudW1iZXIgb2YNCiAgICBjb21tZW50cyAoc2VlIGRldGFp bHMgaW4tbGluZSBiZWxvdykuICBJIHdhbnQgdG8gaGlnaGxpZ2h0IGEgZmV3IG9mDQogICAgdGhl bSB1cCBmcm9udC4NCiAgICANCiAgICBJIHdpbGwgd2FpdCBmb3IgdGhlIG1ham9yIGlzc3VlcyB0 byBiZSBhZGRyZXNzZWQgYmVmb3JlIHN0YXJ0aW5nIHRoZSBJRVRGIExDLg0KICAgIA0KICAgIFRo YW5rcyEhDQogICAgDQogICAgQWx2YXJvLg0KICAgIA0KICAgIA0KICAgICgxKSBPYnNvbGV0aW5n IG90aGVyIHdvcmsNCiAgICANCiAgICBUaGlzIGRvY3VtZW50IGRlcHJlY2F0ZXMgdGhlIEVuY2Fw c3VsYXRpb24gU0FGSSBiZWNhdXNlIGl0ICJoYXMgbmV2ZXINCiAgICBiZWVuIHVzZWQgaW4gcHJv ZHVjdGlvbiIuICBXaGF0IGFib3V0IG90aGVyIHdvcmsgdGhhdCBzcGVjaWZpZXMgdGhlDQogICAg dXNlIG9mIHRoZSBFbmNhcHN1bGF0aW9uIFNBRkk/ICBTaG91bGQgdGhleSBhbHNvIGJlIE9ic29s ZXRlZCBieSB0aGlzDQogICAgZG9jdW1lbnQ/ICBbWWVzLCBJIGtub3cgdGhlcmUgd2FzIGEgbG9u ZyBkaXNjdXNzaW9uIG9uIHRoZSBsaXN0LCB3aGljaA0KICAgIHJlc3VsdGVkIGluIHRoZSB0ZXh0 IGluIMKnMS40Ll0NCiAgICANCiAgICBCb3RoIHJmYzU1NjYgKG1lbnRpb25lZCBpbiDCpzEuNCkg YW5kIHJmYzU2NDAgc3BlY2lmeSB0aGUgdXNlIG9mIHRoZQ0KICAgIEVuY2Fwc3VsYXRpb24gU0FG SS4gIElzIHRoZXJlIGludGVyZXN0IGluIFVwZGF0aW5nIHRob3NlIFJGQ3M/ICBJZg0KICAgIG5v dCwgdGhlbiBpdCBzZWVtcyBsaWtlIHRoZSBlYXN5IHRoaW5nIHRvIGRvIGlzIHRvIE9ic29sZXRl IHRoYXQgd29yaw0KICAgIHdpdGggdGhpcyBkb2N1bWVudC4gIElmIHRoZXJlIGlzLCB0aGVuIEkg YWdyZWUgd2l0aCB0aGUgdGV4dCBpbiDCpzEuNA0KICAgIGluIHRoYXQgdGhlIGVmZm9ydCB3b3Vs ZCBiZSBvdXQgb2Ygc2NvcGUgb2YgdGhpcyBkb2N1bWVudC4gIEluIGVpdGhlcg0KICAgIGNhc2Us IEkgdGhpbmsgdGhhdCDCpzEuNCByYWlzZXMgbW9yZSBxdWVzdGlvbnMgdGhhbiBpdCBhbnN3ZXJz IGFuZCBpcw0KICAgIG5vdCBuZWVkZWQgaW4gdGhpcyBkb2N1bWVudC4NCiAgICANCiAgICBKb2hu OiBBcyBTaGVwaGVyZCwgY2FuIHlvdSBwbGVhc2UgcGluZyB0aGUgV0cgKHlvdSBtYXkgaGF2ZSB0 byByZWFjaA0KICAgIG91dCB0byBiZXNzIGFzIHdlbGwpIGFib3V0IHBvdGVudGlhbCBpbnRlcmVz dCBpbiBVcGRhdGluZw0KICAgIHJmYzU1NjYvcmZjNTY0MC4gIEkgd29uJ3QgaG9sZCB0aGlzIGRv Y3VtZW50IHdhaXRpbmcgZm9yIHRoZQ0KICAgIHJlc29sdXRpb24sIGJ1dCBoYXZpbmcgYW4gaWRl YSBvZiBhbnkgaW50ZXJlc3Qgd291bGQgYmUgbmljZS4NCiAgICBJbnRlcmVzdCBoYXMgYmVlbiBl eHByZXNzZWQgZm9yIHJmYzU1NjZiaXMgWzFdLCBidXQgZGlkbid0IHNlZQ0KICAgIGFueXRoaW5n IHJlbGF0ZWQgdG8gcmZjNTY0MC4gIEJUVywgdGhlIG1haWxpbmcgbGlzdCBjb250YWlucw0KICAg IGRpc2N1c3Npb24gYWJvdXQgb3RoZXIgSVBzZWMtcmVsYXRlZCBkcmFmdHMgdGhhdCB1c2UgdHVu bmVsLWVuY2FwOyBJJ20NCiAgICBub3Qgc3VyZSBvZiB0aGVpciByZWxhdGlvbnNoaXAgKGlmIGFu eSkgdG8gcmZjNTU2Ni4NCiAgICANCiAgICBbMV0gaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9y Zy9hcmNoL21zZy9pZHIveXVJWHIzSHBQRXA3dl9rMDhYcGRoWFJONkdNDQogICAgDQogICAgDQog ICAgKDIpIFVuZGVyc3BlY2lmaWNhdGlvbi4NCiAgICANCiAgICBBIGJpZyBwYXJ0IG9mIHRoaXMg ZG9jdW1lbnQgaXMgZGVkaWNhdGVkIHRvIHNwZWNpZnlpbmcgc3ViLVRMVnMuLi5idXQNCiAgICBp biBub25lIG9mIHRob3NlIGRlc2NyaXB0aW9ucyBpcyB0aGUgVHlwZSBvZiB0aGUgc3ViLVRMViBp bmRpY2F0ZWQhDQogICAgUGxlYXNlIGFkZCBhbGwgdGhlIGJhc2ljIGRlc2NyaXB0aW9uIG9mIGEg c3ViLVRMViBpbiBvbmUgcGxhY2UsIGFuZA0KICAgIGRvbid0IGZvcmNlIHRoZSB1c2VyIHRvIHNl YXJjaCBmb3IgdGhlIHR5cGVzIGVsc2V3aGVyZTogaW4gdGhlIElBTkENCiAgICBDb25zaWRlcmF0 aW9ucyBzb21ldGltZXMsIGJ1dCBpbiB0aGUgcmVnaXN0cnkgaW4gb3RoZXJzLiAgUGxlYXNlIGRv bid0DQogICAgZm9yZ2V0IHRoYXQgdGhpcyBkb2N1bWVudCBPYnNvbGV0ZXMgcmZjNTUxMiwgc28g YW55dGhpbmcgdGhhdCB3YXMNCiAgICBzcGVjaWZpZWQgdGhlcmUgbmVlZHMgdG8gYmUgcmUtc3Bl Y2lmaWVkIGhlcmUuDQogICAgDQogICAgDQogICAgKDMpIFVzZSBvZiBOb3JtYXRpdmUgTGFuZ3Vh Z2UuDQogICAgDQogICAgV2hpbGUgdXNpbmcgcmZjMjExOSBrZXl3b3JkcyBpcyBub3QgYWx3YXlz IG5lY2Vzc2FyeSwgdGhleSBoZWxwDQogICAgY2xhcmlmeSB0aGUgYmVoYXZpb3IgcmVxdWlyZWQg Zm9yIGludGVyb3BlcmFiaWxpdHkuICBDYXNlcyB3aGVyZSB0aGUNCiAgICBrZXl3b3JkcyBhcmUg bm90IHVzZWQgKGUuZy4gcmZjODIwMCkgb2Z0ZW4gcmVzdWx0IGluIG11bHRpcGxlDQogICAgaW50 ZXJwcmV0YXRpb25zLiAgVGhpcyBkb2N1bWVudCBpcyBpbmNvbnNpc3RlbnQgaW4gdGhlIHVzZSBv Zg0KICAgIE5vcm1hdGl2ZSBMYW5ndWFnZTogaXQgaXMgdXNlZCBzb21ldGltZXMsIGJ1dCBub3Qg YWx3YXlzLiAgUGxlYXNlIGJlDQogICAgY29uc2lzdGVudCEgIFJlY29tbWVuZGF0aW9uOiB1c2Ug aXQhICBJIHBvaW50ZWQgb3V0IHNvbWUgY2FzZXMsIGJ1dA0KICAgIHRoZSB3aG9sZSBkb2N1bWVu dCB3b3VsZCBiZW5lZml0IGZyb20gYSByZS1yZWFkLg0KICAgIA0KICAgIA0KICAgICg0KSBVc2Ug Q2FzZXMNCiAgICANCiAgICByZmM1NTEyIGdhdmUgYW4gb3ZlcnZpZXcgb2YgdGhlIHVzZSBjYXNl IChtb3N0bHkgaW50cmEtQVMpLCBidXQgdGhpcw0KICAgIGRvY3VtZW50IGRvZXNuJ3QgbWVudGlv biB1c2UgY2FzZXMgZWl0aGVyIGFzIGFuIGludHJvZHVjdGlvbiB0byB0aGUNCiAgICBwcm9ibGVt IGJlaW5nIHNvbHZlZCBvciBpbiB0aGUgZm9ybSBvZiBPcGVyYXRpb25hbCBDb25zaWRlcmF0aW9u cy4NCiAgICBTZWN0aW9ucyA5IGFuZCAxMCB3b3VsZCBiZSBhIGdvb2Qgc3RhcnQgZm9yIHRoYXQg dHlwZSBvZiBzZWN0aW9uLCBidXQNCiAgICBoYXZpbmcgYSBnZW5lcmFsIGRlc2NyaXB0aW9uIG9m IHRoZSBwcm9ibGVtIHVwZnJvbnQgKGluIHRoZQ0KICAgIEludHJvZHVjdGlvbiBtYXliZSkgd291 bGQgYmUgaWRlYWwuICBBZ2FpbiwgYmVjYXVzZSB0aGlzIGRvY3VtZW50DQogICAgT2Jzb2xldGVz IHJmYzU1MTIsIHRoZW4gd2UgY2FuJ3QgcmVhbGx5IHJlbHkgb24gdGhlIGluZm9ybWF0aW9uIHRo ZXJlLg0KICAgIEknbSBsb29raW5nIGZvciBhIGZldyBwYXJhZ3JhcGhzLCBtb3N0bHkgZGlyZWN0 ZWQgYXQgcmVhZGVycyB0aGF0IG1heQ0KICAgIG5vdCBiZSBmYW1pbGlhciB3aXRoIHJmYzU1MTIg YW5kIHRoZSBwb3RlbnRpYWwgYXBwbGljYXRpb25zLg0KICAgIA0KICAgIA0KICAgICg1KSBXaGVu IGRvZXMgYW4gSVAgYWRkcmVzcyAiYmVsb25nIiB0byBhbiBBUz8NCiAgICANCiAgICDCpzMuMSB1 c2VzIHRoaXMgY29uZGl0aW9uIGFzIGEgd2F5IHRvIGRldGVybWluZSBpZiB0aGUgVHVubmVsIEVu ZHBvaW50DQogICAgc3ViLVRMViBpcyBtYWxmb3JtZWQ6DQogICAgDQogICAgICAgbyAgSXQgY2Fu IGJlIGRldGVybWluZWQgdGhhdCB0aGUgSVAgYWRkcmVzcyBpbiB0aGUgc3ViLVRMVidzIGFkZHJl c3MNCiAgICAgICAgICBzdWJmaWVsZCBkb2VzIG5vdCBiZWxvbmcgdG8gdGhlIG5vbi16ZXJvIEFT IHdob3NlIG51bWJlciBpcyBpbiB0aGUNCiAgICAgICAgICBpdHMgQXV0b25vbW91cyBTeXN0ZW0g c3ViZmllbGQuICAoU2VlIHNlY3Rpb24gU2VjdGlvbiAxMyBmb3INCiAgICAgICAgICBkaXNjdXNz aW9uIG9mIG9uZSB3YXkgdG8gZGV0ZXJtaW5lIHRoaXMuKQ0KICAgIA0KICAgIElPVywgZm9yIHRo ZSBUdW5uZWwgRW5kcG9pbnQgc3ViLVRMViB0byBiZSBmb3JtZWQgY29ycmVjdGx5IHRoZSBJUA0K ICAgIGFkZHJlc3MgaGFzIHRvICJiZWxvbmciIHRvIHRoZSBBUyBsaXN0ZWQuDQogICAgDQogICAg DQogICAgwqcxMyAoU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMpIGlzIHZlcnkgdGVudGF0aXZlIGFi b3V0IGhvdyB0byBkZXRlcm1pbmUNCiAgICBpZiBhbiBJUCBhZGRyZXNzICJiZWxvbmdzIiB0byB0 aGUgQVMgbGlzdGVkLiAgSW4gZmFjdCwgdGhlIHRleHQgdGhlcmUNCiAgICBzdGFydHMgYnkgc3Vn Z2VzdGluZyB0aGF0ICJCR1AgT3JpZ2luIFZhbGlkYXRpb24gW1JGQzY4MTFdIGNhbiBiZSB1c2Vk DQogICAgdG8gb2J0YWluIGFzc3VyYW5jZSB0aGF0IHRoZSBnaXZlbiBJUCBhZGRyZXNzIGJlbG9u Z3MgdG8gdGhlIGdpdmVuDQogICAgQVMiLCBidXQgYWZ0ZXIgcG9pbnRpbmcgYXQgc29tZSBmbGF3 cyBjb25jbHVkZXMgdGhhdDoNCiAgICANCiAgICAgICBGb3IgdGhlc2UgcmVhc29ucywgQkdQIE9y aWdpbiBWYWxpZGF0aW9uIHNob3VsZCBub3QgYmUgcmVsaWVkIHVwb24NCiAgICAgICBleGNsdXNp dmVseSwgYW5kIHRoZSBmaWx0ZXJpbmcgcHJvY2VkdXJlcyBvZiBTZWN0aW9uIDEwIHNob3VsZCBh bHdheXMNCiAgICAgICBiZSBpbiBwbGFjZS4NCiAgICANCiAgICANCiAgICDCpzEwIChTY29waW5n KSBzYXlzIHRoYXQgImFueSBCR1Agc3BlYWtlciB0aGF0IHVuZGVyc3RhbmRzIHRoZQ0KICAgIGF0 dHJpYnV0ZSBNVVNUIGJlIGFibGUgdG8gZmlsdGVyIHRoZSBhdHRyaWJ1dGUgZnJvbSBpbmNvbWlu Zy9vdXRnb2luZw0KICAgIEJHUCBVUERBVEUgbWVzc2FnZXMiLi4uYnV0IGl0IGRvZXNuJ3Qgc2F5 IGFueXRoaW5nIGFib3V0IHRoZSB0b3BpYyBvZg0KICAgICJiZWxvbmdpbmciLCBvciB3aGF0IHRo ZXNlIGZpbHRlcnMgc2hvdWxkIGNvbnNpZGVyIHdoZW4gYWN0aXZlLg0KICAgIFByZXN1bWFibHks IHRoZSBmaWx0ZXJzIGNhbiBiZSB1c2VkIHRvIGF2b2lkIHJlY2VpdmluZyBUdW5uZWwgRW5kcG9p bnQNCiAgICBzdWItVExWIHdpdGggSVAgYWRkcmVzc2VzIHRoYXQgZG9uJ3QgYmVsb25nIHRvIHRo ZSBBUyBsaXN0ZWQuLi5idXQNCiAgICB0aGF0IGlzIG5vdCBtZW50aW9uZWQgYW55d2hlcmUsIG11 Y2ggbGVzcyB3aGljaCB3b3VsZCBiZSB0aGUgY3JpdGVyaWENCiAgICB0byBtYWtlIHRoYXQgZmls dGVyaW5nIGRlY2lzaW9uLg0KICAgIA0KICAgIA0KICAgIFRoZSBlZmZlY3Qgb2YgdGhlIGFib3Zl IGlzIHRoYXQgdGhlIGRvY3VtZW50IGRvZXNuJ3QgcmVhbGx5IHNwZWNpZnkNCiAgICBob3cgdG8g ZGV0ZXJtaW5lIHRoYXQgdGhlIFR1bm5lbCBFbmRwb2ludCBzdWItVExWIGlzIG5vdCBtYWxmb3Jt ZWQuDQogICAgDQogICAgTXkgc3VnZ2VzdGlvbiBpcyB0byBub3QgbWFrZSAiYmVsb25naW5nIiBw YXJ0IG9mIHRoZSBjcml0ZXJpYSBmb3IgYQ0KICAgIHdlbGwtZm9ybWVkIHN1Yi1UTFYuICBUaGUg dmFsaWRpdHkgb2YgdGhlIGFkZHJlc3MgaW4gdGVybXMgb2YNCiAgICAiYmVsb25naW5nIiBpcyBp bXBvcnRhbnQgYW5kIHNob3VsZCBiZSBoaWdobGlnaHRlZCBhcyBpdCBpcyBpbiDCpzEzLg0KICAg IENvbnNpZGVyIGEgc3Ryb25nZXIgcmVxdWlyZW1lbnQgZm9yIHVzaW5nIE9yaWdpbiBWYWxpZGF0 aW9uIChTSE9VTEQNCiAgICA/KS4gIEFsc28sIHRoZSBkZXBsb3ltZW50IG1vZGVscyAoYW5kIHVz ZSBjYXNlcywgYXMgbWVudGlvbmVkIGFib3ZlKSwNCiAgICBpbmNsdWRpbmcgdGhlICJ3ZWxsLWRl ZmluZWQgc2NvcGUiIGZyb20gwqcxMCBzaG91bGQgYmUgY2xlYXINCiAgICB0aHJvdWdob3V0Lg0K ICAgIA0KICAgIA0KICAgIA0KICAgIFtMaW5lIG51bWJlcnMgZnJvbSBpZG5pdHMuXQ0KICAgIA0K ICAgIC4uLg0KICAgIDEzCUFic3RyYWN0DQogICAgDQogICAgMTUJICAgUkZDIDU1MTIgZGVmaW5l cyBhIEJHUCBQYXRoIEF0dHJpYnV0ZSBrbm93biBhcyB0aGUgIlR1bm5lbA0KICAgIDE2CSAgIEVu Y2Fwc3VsYXRpb24gQXR0cmlidXRlIi4gIFRoaXMgYXR0cmlidXRlIGFsbG93cyBvbmUgdG8gc3Bl Y2lmeSBhIHNldA0KICAgIDE3CSAgIG9mIHR1bm5lbHMuICBGb3IgZWFjaCBzdWNoIHR1bm5lbCwg dGhlIGF0dHJpYnV0ZSBjYW4gcHJvdmlkZSB0aGUNCiAgICAxOAkgICBpbmZvcm1hdGlvbiBuZWVk ZWQgdG8gY3JlYXRlIHRoZSB0dW5uZWwgYW5kIHRoZSBjb3JyZXNwb25kaW5nDQogICAgMTkJICAg ZW5jYXBzdWxhdGlvbiBoZWFkZXIuICBUaGUgYXR0cmlidXRlIGNhbiBhbHNvIHByb3ZpZGUgaW5m b3JtYXRpb24NCiAgICAyMAkgICB0aGF0IGFpZHMgaW4gY2hvb3Npbmcgd2hldGhlciBhIHBhcnRp Y3VsYXIgcGFja2V0IGlzIHRvIGJlIHNlbnQNCiAgICAyMQkgICB0aHJvdWdoIGEgcGFydGljdWxh ciB0dW5uZWwuICBSRkMgNTUxMiBzdGF0ZXMgdGhhdCB0aGUgYXR0cmlidXRlIGlzDQogICAgMjIJ ICAgb25seSBjYXJyaWVkIGluIEJHUCBVUERBVEVzIHRoYXQgaGF2ZSB0aGUgIkVuY2Fwc3VsYXRp b24gU3Vic2VxdWVudA0KICAgIDIzCSAgIEFkZHJlc3MgRmFtaWx5IChFbmNhcHN1bGF0aW9uIFNB RkkpIi4gIFRoaXMgZG9jdW1lbnQgZGVwcmVjYXRlcyB0aGUNCiAgICAyNAkgICBFbmNhcHN1bGF0 aW9uIFNBRkkgKHdoaWNoIGhhcyBuZXZlciBiZWVuIHVzZWQgaW4gcHJvZHVjdGlvbiksIGFuZA0K ICAgIDI1CSAgIHNwZWNpZmllcyBzZW1hbnRpY3MgZm9yIHRoZSBhdHRyaWJ1dGUgd2hlbiBpdCBp cyBjYXJyaWVkIGluIFVQREFURXMNCiAgICAyNgkgICBvZiBjZXJ0YWluIG90aGVyIFNBRklzLiAg VGhpcyBkb2N1bWVudCBhZGRzIHN1cHBvcnQgZm9yIGFkZGl0aW9uYWwNCiAgICAyNwkgICB0dW5u ZWwgdHlwZXMsIGFuZCBhbGxvd3MgYSByZW1vdGUgdHVubmVsIGVuZHBvaW50IGFkZHJlc3MgdG8g YmUNCiAgICAyOAkgICBzcGVjaWZpZWQgZm9yIGVhY2ggdHVubmVsLiAgVGhpcyBkb2N1bWVudCBh bHNvIHByb3ZpZGVzIHN1cHBvcnQgZm9yDQogICAgMjkJICAgc3BlY2lmeWluZyBmaWVsZHMgb2Yg YW55IGlubmVyIG9yIG91dGVyIGVuY2Fwc3VsYXRpb25zIHRoYXQgbWF5IGJlDQogICAgMzAJICAg dXNlZCBieSBhIHBhcnRpY3VsYXIgdHVubmVsLg0KICAgIA0KICAgIFtuaXRdIHMvdGhhdCBoYXZl IHRoZSAiRW5jYXBzdWxhdGlvbi90aGF0IHVzZSB0aGUgIkVuY2Fwc3VsYXRpb24NCiAgICANCiAg ICANCiAgICAuLi4NCiAgICAxNDIJMS4xLiAgQnJpZWYgU3VtbWFyeSBvZiBSRkMgNTUxMg0KICAg IC4uLg0KICAgIDE2MQkgICBvICBCR1Agc3BlYWtlciBSMSBoYXMgcmVjZWl2ZWQgYW5kIGluc3Rh bGxlZCBVUERBVEUgVTsNCiAgICANCiAgICBbbWlub3JdIFRvIGJlIGNvbnNpc3RlbnQgd2l0aCBy ZmM0MjcxOiBzL2luc3RhbGxlZCBVUERBVEUgVS9zZWxlY3RlZA0KICAgIFVQREFURSBVIGZvciBs b2NhbCB1c2UNCiAgICANCiAgICAuLi4NCiAgICAxNzEJICAgbyAgUjEncyBiZXN0IHBhdGggdG8g RCBpcyBhIEJHUCByb3V0ZSB0aGF0IGhhcyBSMiBhcyBpdHMgbmV4dCBob3A7DQogICAgDQogICAg W21pbm9yXSByZmM0MjcxIGNvbnNpc3RlbmN5OiBzL2Jlc3QgcGF0aC9iZXN0IHJvdXRlL2cNCiAg ICANCiAgICANCiAgICAuLi4NCiAgICAxNzkJMS4yLiAgRGVmaWNpZW5jaWVzIGluIFJGQyA1NTEy DQogICAgLi4uDQogICAgMTkxCSAgIG8gIFRoZXJlIGlzIG5vIHdheSB0byB1c2UgdGhlIFR1bm5l bCBFbmNhcHN1bGF0aW9uIGF0dHJpYnV0ZSB0bw0KICAgIDE5MgkgICAgICBzcGVjaWZ5IHRoZSB0 dW5uZWwgZWdyZXNzIGVuZHBvaW50IGFkZHJlc3Mgb2YgYSBnaXZlbiB0dW5uZWw7DQogICAgMTkz CSAgICAgIFtSRkM1NTEyXSBhc3N1bWVzIHRoYXQgdGhlIHR1bm5lbCBlZ3Jlc3MgZW5kcG9pbnQg b2YgZWFjaCB0dW5uZWwNCiAgICAxOTQJICAgICAgaXMgc3BlY2lmaWVkIGFzIHRoZSBOTFJJIG9m IGFuIFVQREFURSBvZiB0aGUgRW5jYXBzdWxhdGlvbi1TQUZJLg0KICAgIA0KICAgIFtuaXRdIHMv RW5jYXBzdWxhdGlvbi1TQUZJL0VuY2Fwc3VsYXRpb24gU0FGSQ0KICAgIA0KICAgIA0KICAgIC4u Lg0KICAgIDIwOQkxLjMuICBCcmllZiBTdW1tYXJ5IG9mIENoYW5nZXMgZnJvbSBSRkMgNTUxMg0K ICAgIA0KICAgIFttaW5vcl0gSXQgd291bGQgYmUgdmVyeSBuaWNlIGlmIGZvcndhcmQgcmVmZXJl bmNlcyB3ZXJlIHByb3ZpZGVkDQogICAgYmVsb3cgLS0gdG8gdGhlIHNlY3Rpb24gd2hlcmUgdGhl IGNoYW5nZXMvZW5oYW5jZW1lbnRzIGFyZSBzcGVjaWZpZWQuDQogICAgDQogICAgDQogICAgMjEx CSAgIEluIHRoaXMgZG9jdW1lbnQgd2UgYWRkcmVzcyB0aGVzZSBkZWZpY2llbmNpZXMgYnk6DQog ICAgDQogICAgW3N0eWxlIG5pdF0gUGxlYXNlIGRvbid0IHdyaXRlIGluIGZpcnN0IHBlcnNvbi4g IEluc3RlYWQ6ICJUaGlzDQogICAgZG9jdW1lbnQgYWRkcmVzc2VzIHRoZXNlIGRlZmljaWVuY2ll cyBieToiLiAgVGhlcmUgaXMgc2ltaWxhciB0ZXh0IGluDQogICAgb3RoZXIgcGxhY2VzLg0KICAg IA0KICAgIA0KICAgIC4uLg0KICAgIDIzMwkgICBPbmUgb2YgdGhlIHN1Yi1UTFZzIGRlZmluZWQg aW4gW1JGQzU1MTJdIGlzIHRoZSAiRW5jYXBzdWxhdGlvbiBzdWItDQogICAgMjM0CSAgIFRMViIu ICBGb3IgYSBnaXZlbiB0dW5uZWwsIHRoZSBlbmNhcHN1bGF0aW9uIHN1Yi1UTFYgc3BlY2lmaWVz IHNvbWUNCiAgICAyMzUJICAgb2YgdGhlIGluZm9ybWF0aW9uIG5lZWRlZCB0byBjb25zdHJ1Y3Qg dGhlIGVuY2Fwc3VsYXRpb24gaGVhZGVyIHVzZWQNCiAgICAyMzYJICAgd2hlbiBzZW5kaW5nIHBh Y2tldHMgdGhyb3VnaCB0aGF0IHR1bm5lbC4gIFRoaXMgZG9jdW1lbnQgZGVmaW5lcw0KICAgIDIz NwkgICBlbmNhcHN1bGF0aW9uIHN1Yi1UTFZzIGZvciBhIG51bWJlciBvZiB0dW5uZWwgdHlwZXMg bm90IGRpc2N1c3NlZCBpbg0KICAgIDIzOAkgICBbUkZDNTUxMl06IFZYTEFOIChWaXJ0dWFsIEV4 dGVuc2libGUgTG9jYWwgQXJlYSBOZXR3b3JrLCBbUkZDNzM0OF0pLA0KICAgIDIzOQkgICBWWExB Ti1HUEUgKEdlbmVyaWMgUHJvdG9jb2wgRXh0ZW5zaW9uIGZvciBWWExBTiwNCiAgICAyNDAJICAg W0ktRC5pZXRmLW52bzMtdnhsYW4tZ3BlXSksIE5WR1JFIChOZXR3b3JrIFZpcnR1YWxpemF0aW9u IFVzaW5nDQogICAgMjQxCSAgIEdlbmVyaWMgUm91dGluZyBFbmNhcHN1bGF0aW9uIFtSRkM3NjM3 XSksIGFuZCBNUExTLWluLUdSRSAoTVBMUyBpbg0KICAgIDI0MgkgICBHZW5lcmljIFJvdXRpbmcg RW5jYXBzdWxhdGlvbiBbUkZDMjc4NF0sIFtSRkMyODkwXSwgW1JGQzQwMjNdKS4NCiAgICAyNDMJ ICAgTVBMUy1pbi1VRFAgW1JGQzc1MTBdIGlzIGFsc28gc3VwcG9ydGVkLCBidXQgYW4gRW5jYXBz dWxhdGlvbiBzdWItVExWDQogICAgMjQ0CSAgIGZvciBpdCBpcyBub3QgbmVlZGVkLg0KICAgIA0K ICAgIFtuaXRdIHMvZW5jYXBzdWxhdGlvbiBzdWItVExWL0VuY2Fwc3VsYXRpb24gc3ViLVRMVi9n DQogICAgDQogICAgDQogICAgLi4uDQogICAgMjY1CSAgIFtSRkM1NTEyXSBkZWZpbmVzIGEgVHVu bmVsIEVuY2Fwc3VsYXRpb24gRXh0ZW5kZWQgQ29tbXVuaXR5LCB0aGF0IGNhbg0KICAgIDI2Ngkg ICBiZSB1c2VkIGluc3RlYWQgb2YgdGhlIFR1bm5lbCBFbmNhcHN1bGF0aW9uIGF0dHJpYnV0ZSB1 bmRlciBjZXJ0YWluDQogICAgMjY3CSAgIGNpcmN1bXN0YW5jZXMuICBUaGlzIGRvY3VtZW50IGFk ZHJlc3NlcyB0aGUgaXNzdWUgb2YgaG93IHRvIGhhbmRsZSBhDQogICAgMjY4CSAgIEJHUCBVUERB VEUgdGhhdCBjYXJyaWVzIGJvdGggYSBUdW5uZWwgRW5jYXBzdWxhdGlvbiBhdHRyaWJ1dGUgYW5k IG9uZQ0KICAgIDI2OQkgICBvciBtb3JlIFR1bm5lbCBFbmNhcHN1bGF0aW9uIEV4dGVuZGVkIENv bW11bml0aWVzLg0KICAgIA0KICAgIFtuaXRdIHMvQ29tbXVuaXR5LCB0aGF0L0NvbW11bml0eSB0 aGF0DQogICAgDQogICAgDQogICAgMjcxCTEuNC4gIEltcGFjdCBvbiBSRkMgNTU2Ng0KICAgIA0K ICAgIDI3MwkgICBbUkZDNTU2Nl0gdXNlcyB0aGUgbWVjaGFuaXNtcyBkZWZpbmVkIGluIFtSRkM1 NTEyXS4gIFdoaWxlIHRoaXMNCiAgICAyNzQJICAgZG9jdW1lbnQgb2Jzb2xldGVzIFtSRkM1NTEy XSwgaXQgZG9lcyBub3QgYWRkcmVzcyB0aGUgaXNzdWUgb2YgaG93IHRvDQogICAgMjc1CSAgIHVz ZSB0aGUgbWVjaGFuaXNtcyBvZiBbUkZDNTU2Nl0gd2l0aG91dCBhbHNvIHVzaW5nIHRoZSBFbmNh cHN1bGF0aW9uDQogICAgMjc2CSAgIFNBRkkuICBUaG9zZSBpc3N1ZXMgYXJlIGNvbnNpZGVyZWQg dG8gYmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcw0KICAgIDI3NwkgICBkb2N1bWVudC4NCiAg ICANCiAgICBbbWFqb3JdIFNlZSBteSByZWxhdGVkIGNvbW1lbnRzIHVwIGZyb250LiAgVGhpcyBz ZWN0aW9uIGlzIG5vdCBuZWVkZWQuDQogICAgDQogICAgDQogICAgMjc5CTIuICBUaGUgVHVubmVs IEVuY2Fwc3VsYXRpb24gQXR0cmlidXRlDQogICAgLi4uDQogICAgMjg3CSAgICAgIDAgICAgICAg ICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCiAg ICAyODgJICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxDQogICAgMjg5CSAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAyOTAJICAgICB8 ICAgIFR1bm5lbCBUeXBlICgyIE9jdGV0cykgICAgIHwgICAgICAgIExlbmd0aCAoMiBPY3RldHMp ICAgICAgfA0KICAgIDI5MQkgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgMjkyCSAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAg ICAyOTMJICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWYWx1ZSAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfA0KICAgIDI5NAkgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAgMjk1CSAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCiAgICANCiAgICAyOTcJICAgICAgICAgICAgICBGaWd1cmUgMTogVHVubmVsIEVu Y2Fwc3VsYXRpb24gVExWIFZhbHVlIEZpZWxkDQogICAgDQogICAgW21pbm9yXSBUaGlzIFRMViBp cyBjYWxsZWQgdGhlIFR1bm5lbCBUTFYgYWxsIG92ZXIgdGhlIHRleHQuLi5leGNlcHQNCiAgICBo ZXJlLCB3aGVyZSBpdCBpcyBub3QgZ2l2ZW4gYSBuYW1lIGluIHRoZSBkZXNjcmlwdGlvbiB0ZXh0 LiAgTm90ZSB0aGF0DQogICAgYmVzaWRlcyB0aGUgdGl0bGUgb2YgdGhlIGZpZ3VyZSBhYm92ZSwg IlR1bm5lbCBFbmNhcHN1bGF0aW9uIFRMViIgaXMNCiAgICB1c2VkIGluIG9uZSBvdGhlciBwbGFj ZSB0b28uLi4NCiAgICANCiAgICANCiAgICAyOTkJICAgbyAgVHVubmVsIFR5cGUgKDIgb2N0ZXRz KTogaWRlbnRpZmllcyBhIHR5cGUgb2YgdHVubmVsLiAgVGhlIGZpZWxkDQogICAgMzAwCSAgICAg IGNvbnRhaW5zIHZhbHVlcyBmcm9tIHRoZSBJQU5BIFJlZ2lzdHJ5ICJCR1AgVHVubmVsIEVuY2Fw c3VsYXRpb24NCiAgICAzMDEJICAgICAgQXR0cmlidXRlIFR1bm5lbCBUeXBlcyIuDQogICAgDQog ICAgMzAzCSAgICAgIE5vdGUgdGhhdCBmb3IgdHVubmVsIHR5cGVzIHdob3NlIG5hbWVzIGFyZSBv ZiB0aGUgZm9ybSAiWC1pbi1ZIiwNCiAgICAzMDQJICAgICAgZS5nLiwgIk1QTFMtaW4tR1JFIiwg b25seSBwYWNrZXRzIG9mIHRoZSBzcGVjaWZpZWQgcGF5bG9hZCB0eXBlDQogICAgMzA1CSAgICAg ICJYIiBhcmUgdG8gYmUgY2FycmllZCB0aHJvdWdoIHRoZSB0dW5uZWwgb2YgdHlwZSAiWSIuICBU aGlzIGlzIHRoZQ0KICAgIDMwNgkgICAgICBlcXVpdmFsZW50IG9mIHNwZWNpZnlpbmcgYSB0dW5u ZWwgdHlwZSAiWSIgYW5kIGluY2x1ZGluZyBpbiBpdHMNCiAgICAzMDcJICAgICAgVExWIGEgUHJv dG9jb2wgVHlwZSBzdWItVExWIChzZWUgU2VjdGlvbiAzLjQuMSkgc3BlY2lmeWluZw0KICAgIDMw OAkgICAgICBwcm90b2NvbCAiWCIuICBJZiB0aGUgdHVubmVsIHR5cGUgaXMgIlgtaW4tWSIsIGl0 IGlzIHVubmVjZXNzYXJ5LA0KICAgIDMwOQkgICAgICB0aG91Z2ggaGFybWxlc3MsIHRvIGluY2x1 ZGUgYSBQcm90b2NvbCBUeXBlIHN1Yi1UTFYgc3BlY2lmeWluZw0KICAgIDMxMAkgICAgICAiWCIu DQogICAgDQogICAgW21pbm9yXSBUaGlzIGlzIGEgZ29vZCBwYXJhZ3JhcGgsIGJ1dCBpdCBtYXkg YmUgbW9yZSByZWxldmFudCBpbiDCpzMuNC4xLg0KICAgIA0KICAgIFttYWpvcl0gIi4uLm9ubHkg cGFja2V0cyBvZiB0aGUgc3BlY2lmaWVkIHBheWxvYWQgdHlwZSAiWCIgYXJlIHRvIGJlDQogICAg Y2FycmllZCB0aHJvdWdoIHRoZSB0dW5uZWwgb2YgdHlwZSAiWSIuIiAgSXMgdGhpcyBpbnRlbmRl ZCB0byBiZSBhDQogICAgTm9ybWF0aXZlIHN0YXRlbWVudD8gIE5vdGUgdGhhdCDCpzMuNC4xIHNh eXMgdGhhdCB0aGUgInByb3RvY29sIHR5cGUNCiAgICBzdWItVExWLi4uaW5kaWNhdGUgdGhlIHR5 cGUgb2YgdGhlIHBheWxvYWQgcGFja2V0cyB0aGF0IG1heSBiZQ0KICAgIGVuY2Fwc3VsYXRlZCB3 aXRoIHRoZSB0dW5uZWwgcGFyYW1ldGVycyB0aGF0IGFyZSBiZWluZyBzaWduYWxlZCBpbiB0aGUN CiAgICBUTFYuIiAgIEluIG5laXRoZXIgY2FzZSBhcmUgcmZjMjExOSBrZXl3b3JkcyB1c2VkLCBi dXQgZ2l2ZW4gdGhhdCBib3RoDQogICAgbWVjaGFuaXNtcyBhcmUgaW50ZW5kZWQgdG8gYmUgZXF1 aXZhbGVudCwgaXQgd291bGQgYmUgZ3JlYXQgaWYgdGhlDQogICAgdGV4dCB3YXMgYWxzbyBlcXVp dmFsZW50Lg0KICAgIA0KICAgIFttYWpvcl0gcmZjNTUxMiBzYWlkIHRoYXQgIlVua25vd24gdHlw ZXMgYXJlIHRvIGJlIGlnbm9yZWQgYW5kIHNraXBwZWQNCiAgICB1cG9uIHJlY2VpcHQuIiAgSXMg dGhhdCBzdGlsbCB0aGUgY2FzZT8NCiAgICANCiAgICANCiAgICAuLi4NCiAgICAzMjAJICAgICAg ICAgICAgICAgICAgICArLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgMzIx CSAgICAgICAgICAgICAgICAgICAgfCBTdWItVExWIFR5cGUgKDEgT2N0ZXQpICAgICAgICAgfA0K ICAgIDMyMgkgICAgICAgICAgICAgICAgICAgICstLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSsNCiAgICAzMjMJICAgICAgICAgICAgICAgICAgICB8IFN1Yi1UTFYgTGVuZ3RoICgxIG9y IDIgT2N0ZXRzKSB8DQogICAgMzI0CSAgICAgICAgICAgICAgICAgICAgKy0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tKw0KICAgIDMyNQkgICAgICAgICAgICAgICAgICAgIHwgU3ViLVRM ViBWYWx1ZSAoVmFyaWFibGUpICAgICAgIHwNCiAgICAzMjYJICAgICAgICAgICAgICAgICAgICAr LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQogICAgDQogICAgMzI4CSAgICAgICAg ICAgICAgIFRhYmxlIDE6IFR1bm5lbCBFbmNhcHN1bGF0aW9uIFN1Yi1UTFYgRm9ybWF0DQogICAg DQogICAgW21pbm9yXSBzL1RhYmxlIDEvRmlndXJlIDIgICBQbGVhc2UgcmVudW1iZXIgdGhlIG90 aGVyIEZpZ3VyZXMuDQogICAgDQogICAgDQogICAgMzMwCSAgIG8gIFN1Yi1UTFYgVHlwZSAoMSBv Y3RldCk6IGVhY2ggc3ViLVRMViB0eXBlIGRlZmluZXMgYSBjZXJ0YWluDQogICAgMzMxCSAgICAg IHByb3BlcnR5IGFib3V0IHRoZSB0dW5uZWwgVExWIHRoYXQgY29udGFpbnMgdGhpcyBzdWItVExW Lg0KICAgIA0KICAgIFttYWpvcl0gRG9lcyB0aGlzIHRleHQgZnJvbSByZmM1NTEyIGFwcGx5Pw0K ICAgIA0KICAgICAgIFdoZW4gdGhlIFRMViBpcyBiZWluZyBwcm9jZXNzZWQgYnkgYSBCR1Agc3Bl YWtlciB0aGF0IHdpbGwgYmUNCiAgICAgICBwZXJmb3JtaW5nIGVuY2Fwc3VsYXRpb24sIGFueSB1 bmtub3duIHN1Yi1UTFZzIE1VU1QgYmUgaWdub3JlZCBhbmQNCiAgICAgICBza2lwcGVkLiAgSG93 ZXZlciwgaWYgdGhlIFRMViBpcyB1bmRlcnN0b29kLCB0aGUgZW50aXJlIFRMViBNVVNUDQogICAg ICAgTk9UIGJlIGlnbm9yZWQganVzdCBiZWNhdXNlIGl0IGNvbnRhaW5zIGFuIHVua25vd24gc3Vi LVRMVi4NCiAgICANCiAgICBUaGlzIHRleHQgdXNlcyByZmMyMTE5IGtleXdvcmRzLCBidXQgdGhl IHRleHQgYWJvdXQgdW5rbm93biBUTFZzDQogICAgKGFib3ZlLCBhbHNvIGZyb20gcmZjNTUxMikg ZG9lc24ndC4gIElmIGFkZGluZyB0aGUgdGV4dCBiYWNrIGluLA0KICAgIHBsZWFzZSBiZSBjb25z aXN0ZW50IG9uIHRoZSB3b3JkaW5nLg0KICAgIA0KICAgIA0KICAgIC4uLg0KICAgIDM0OAkzLjEu ICBUaGUgVHVubmVsIEVuZHBvaW50IFN1Yi1UTFYNCiAgICANCiAgICBbbWFqb3JdIFRoZSBUeXBl IG9mIHRoaXMgc3ViLVRMViBpcyBub3Qgc3BlY2lmaWVkIGFueXdoZXJlLiAgTm90ZSB0aGF0DQog ICAgwqcxMi40IHRhbGtzIGFib3V0ICJUdW5uZWwgRWdyZXNzIEVuZHBvaW50Ii4uLnRoZSBuYW1l cyBhcmUgb2J2aW91c2x5DQogICAgaW5jb25zaXN0ZW50LiA6LSgNCiAgICANCiAgICBbbWFqb3Jd IFRoZSBsZW5ndGggb2YgYSBzdWItVExWIGlzIHNwZWNpZmllZCBhYm92ZSwgYnV0IGl0IHdvdWxk IGJlDQogICAgaWRlYWwgaWYgYSBnZW5lcmFsIHN0YXRlbWVudCBmb3IgKnRoaXMqIHN1Yi1UTFYg d2FzIG1hZGU7IHNvbWV0aGluZw0KICAgIGFsb25nIHRoZSBsaW5lcyBvZiAidGhlIGxlbmd0aCBN VVNUIGJlIDYgKyBsZW5ndGggb2YgdGhlIEFGLi4uIi4NCiAgICBUaGlzIHdvdWxkIG1ha2UgdGhl IHNwZWNpZmljYXRpb24gb2YgdGhlIHN1Yi1UTFYgYmVpbmcgbWFsZm9ybWVkDQogICAgZWFzaWVy IHRvIGRvIGxhdGVyIChhbmQgZm9yIGZ1dHVyZSBleHRlbnNpb25zKS4NCiAgICANCiAgICANCiAg ICAzNTAJICAgVGhlIFR1bm5lbCBFbmRwb2ludCBzdWItVExWIHNwZWNpZmllcyB0aGUgYWRkcmVz cyBvZiB0aGUgZW5kcG9pbnQgb2YNCiAgICAzNTEJICAgdGhlIHR1bm5lbCwgdGhhdCBpcywgdGhl IGFkZHJlc3Mgb2YgdGhlIHJvdXRlciB0aGF0IHdpbGwgZGVjYXBzdWxhdGUNCiAgICAzNTIJICAg dGhlIHBheWxvYWQuICBJdCBpcyBhIHN1Yi1UTFYgd2hvc2UgdmFsdWUgZmllbGQgY29udGFpbnMg dGhyZWUgc3ViLQ0KICAgIDM1MwkgICBmaWVsZHM6DQogICAgDQogICAgW25pdF0gInN1Yi1maWVs ZCIgaXMgdXNlZCBoZXJlIChhbmQgaW4gYSBjb3VwbGUgb2Ygb3RoZXIgcGxhY2VzKSwgYnV0DQog ICAgInN1YmZpZWxkIiBpcyB1c2VkIHRoZSBtb3N0LiAgUGxlYXNlIGJlIGNvbnNpc3RlbnQuDQog ICAgDQogICAgDQogICAgLi4uDQogICAgMzU5CSAgIDMuICBhbiBhZGRyZXNzIHN1Yi1maWVsZCwg d2hvc2UgbGVuZ3RoIGRlcGVuZHMgdXBvbiB0aGUgQWRkcmVzcw0KICAgIDM2MAkgICAgICAgRmFt aWx5Lg0KICAgIA0KICAgIFtuaXRdIHMvYWRkcmVzcy9BZGRyZXNzL2cgICBDYXBpdGFsaXplIHRv IGRlbm90ZSB0aGUgbmFtZSBvZiB0aGUNCiAgICBmaWVsZCwgYW5kIG5vdCBzaW1wbHkgYW4gYWRk cmVzcy4NCiAgICANCiAgICAzNjIJICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAg ICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAgIDM2MwkgICAgICAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAg ICAzNjQJICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KICAgIDM2NQkgICAgIHwgICAgICAgICAgICAgICAgICBBdXRv bm9tb3VzIFN5c3RlbSBOdW1iZXIgICAgICAgICAgICAgICAgICAgICB8DQogICAgMzY2CSAgICAg Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCiAgICAzNjcJICAgICB8ICAgICAgQWRkcmVzcyBGYW1pbHkgICAgICAgICAgIHwg ICAgICAgICAgIEFkZHJlc3MgICAgICAgICAgICAgfg0KICAgIDM2OAkgICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArDQog ICAgMzY5CSAgICAgfiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIH4NCiAgICAzNzAJICAgICB8ICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KICAgIDM3MQkgICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rDQogICAgDQogICAgMzczCSAgICAgICAgICAgICAgIEZpZ3VyZSAyOiBUdW5uZWwg RW5kcG9pbnQgU3ViLVRMViBWYWx1ZSBGaWVsZA0KICAgIA0KICAgIFttaW5vcl0gUGxlYXNlIHJl b3JkZXIgdGhlIHRleHQgYmVsb3cgdG8gc3BlY2lmeSB0aGUgZmllbGRzIGluIG9yZGVyLg0KICAg IA0KICAgIFtzdWdnZXN0aW9uXSBTb21lIHBhcnRzIG9mIHRoZSB0ZXh0IHRhbGsgYWJvdXQgYSAi dHVubmVsIGVuZHBvaW50DQogICAgYWRkcmVzcyIsIGJ1dCBpdCBtYXkgbm90IGJlIG9idmlvdXMg dG8gZXZlcnlvbmUgdGhhdCB0aGUgQWRkcmVzcyBmaWVsZA0KICAgIG9mIHRoZSBUdW5uZWwgRW5k cG9pbnQgc3ViLVRMViBpcyB0aGF0ICJ0dW5uZWwgZW5kcG9pbnQgYWRkcmVzcyIuDQogICAgU3Vn Z2VzdGlvbjogcmVuYW1lIHRoZSBmaWVsZCB0byAiVHVubmVsIEVuZHBvaW50IEFkZHJlc3MiLg0K ICAgIA0KICAgIA0KICAgIDM3NQkgICBUaGUgQWRkcmVzcyBGYW1pbHkgc3ViZmllbGQgY29udGFp bnMgYSB2YWx1ZSBmcm9tIElBTkEncyAiQWRkcmVzcw0KICAgIDM3NgkgICBGYW1pbHkgTnVtYmVy cyIgcmVnaXN0cnkuICBJbiB0aGlzIGRvY3VtZW50LCB3ZSBhc3N1bWUgdGhhdCB0aGUNCiAgICAz NzcJICAgQWRkcmVzcyBGYW1pbHkgaXMgZWl0aGVyIElQdjQgb3IgSVB2NjsgdXNlIG9mIG90aGVy IGFkZHJlc3MgZmFtaWxpZXMNCiAgICAzNzgJICAgaXMgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhp cyBkb2N1bWVudC4NCiAgICANCiAgICBbbWFqb3JdIEdpdmVuIHRoYXQgRVZQTiAoQUZJL1NBRkkg MjUvNzApIGlzIHZhbGlkIGFjY29yZGluZyB0byDCpzUsIGFuZA0KICAgIHRoaXMgZG9jdW1lbnQg YXNzdW1lcyBvbmx5IElQdjQvSVB2NiwgZG9lcyB0aGF0IG1lYW4gdGhhdCB0aGUgdHVubmVsDQog ICAgZW5kcG9pbnQgY2Fubm90IGJlIGEgTUFDIGFkZHJlc3MsIEVTSSwgZXRjLi4/ICBUaGF0IGlz IG5vdCBzcGVjaWZpZWQNCiAgICBhbnl3aGVyZS4gICBbV2FybmluZzogbXkgRVZQTiBpcyBydXN0 eS5dDQogICAgDQogICAgW21ham9yXSBCZWNhdXNlIHRoZXJlIGFyZSBzcGVjaWFsIGNvbnNpZGVy YXRpb25zIGRlcGVuZGluZyBvbiB0aGUgQUYsDQogICAgY29uc2lkZXIgYWRkaW5nIHNvbWV0aGlu ZyBhbG9uZyB0aGUgbGluZXMgb2Y6ICJEb2N1bWVudHMgc3BlY2lmeWluZw0KICAgIHRoZSB1c2Ug b2Ygb3RoZXIgQUZzIGFyZSBleHBlY3RlZCB0by4uLiINCiAgICANCiAgICBbbWFqb3JdIElmIG9u bHkgSVB2NC9JUHY2IGFyZSBpbiBzY29wZSwgd2hhdCBzaG91bGQgYSByZWNlaXZlciBkbyBpZg0K ICAgIGFub3RoZXIgQUYgaXMgcmVjZWl2ZWQ/ICBTaG91bGQgdGhlIHN1Yi1UTFYgYmUgY29uc2lk ZXJlZCBtYWxmb3JtZWQ/DQogICAgDQogICAgDQogICAgMzgwCSAgIElmIHRoZSBBZGRyZXNzIEZh bWlseSBzdWJmaWVsZCBjb250YWlucyB0aGUgdmFsdWUgZm9yIElQdjQsIHRoZQ0KICAgIDM4MQkg ICBhZGRyZXNzIHN1YmZpZWxkIG11c3QgY29udGFpbiBhbiBJUHY0IGFkZHJlc3MgKGEgLzMyIElQ djQgcHJlZml4KS4NCiAgICANCiAgICBbbWFqb3JdIHMvbXVzdC9NVVNUID8/DQogICAgDQogICAg DQogICAgMzgzCSAgIEluIHRoaXMgY2FzZSwgdGhlIGxlbmd0aCBmaWVsZCBvZiBUdW5uZWwgRW5k cG9pbnQgc3ViLVRMViBtdXN0DQogICAgMzg0CSAgIGNvbnRhaW4gdGhlIHZhbHVlIDEwICgweGEp Lg0KICAgIA0KICAgIFttYWpvcl0gcy9tdXN0L01VU1QgPz8NCiAgICANCiAgICANCiAgICAzODYJ ICAgSWYgdGhlIEFkZHJlc3MgRmFtaWx5IHN1YmZpZWxkIGNvbnRhaW5zIHRoZSB2YWx1ZSBmb3Ig SVB2NiwgdGhlDQogICAgMzg3CSAgIGFkZHJlc3Mgc3ViLWZpZWxkIG11c3QgY29udGFpbiBhbiBJ UHY2IGFkZHJlc3MgKGEgLzEyOCBJUHY2IHByZWZpeCkuDQogICAgMzg4CSAgIEluIHRoaXMgY2Fz ZSwgdGhlIGxlbmd0aCBmaWVsZCBvZiBUdW5uZWwgRW5kcG9pbnQgc3ViLVRMViBtdXN0DQogICAg Mzg5CSAgIGNvbnRhaW4gdGhlIHZhbHVlIDIyICgweDE2KS4gIElQdjYgbGluayBsb2NhbCBhZGRy ZXNzZXMgYXJlIG5vdCB2YWxpZA0KICAgIDM5MAkgICB2YWx1ZXMgb2YgdGhlIElQIGFkZHJlc3Mg ZmllbGQuDQogICAgDQogICAgW21ham9yXSBzL211c3QvTVVTVCA/Pw0KICAgIA0KICAgIFttYWpv cl0gV2hhdCBpZiBhIGxpbmsgbG9jYWwgYWRkcmVzcyBpcyByZWNlaXZlZD8NCiAgICANCiAgICAN CiAgICAzOTIJICAgSW4gYSBnaXZlbiBCR1AgVVBEQVRFLCB0aGUgYWRkcmVzcyBmYW1pbHkgKElQ djQgb3IgSVB2Nikgb2YgYSBUdW5uZWwNCiAgICAzOTMJICAgRW5kcG9pbnQgc3ViLVRMViBpcyBp bmRlcGVuZGVudCBvZiB0aGUgYWRkcmVzcyBmYW1pbHkgb2YgdGhlIFVQREFURQ0KICAgIDM5NAkg ICBpdHNlbGYuICBGb3IgZXhhbXBsZSwgYW4gVVBEQVRFIHdob3NlIE5MUkkgaXMgYW4gSVB2NCBh ZGRyZXNzIG1heQ0KICAgIDM5NQkgICBoYXZlIGEgVHVubmVsIEVuY2Fwc3VsYXRpb24gYXR0cmli dXRlIGNvbnRhaW5pbmcgVHVubmVsIEVuZHBvaW50IHN1Yi0NCiAgICAzOTYJICAgVExWcyB0aGF0 IGNvbnRhaW4gSVB2NiBhZGRyZXNzZXMuICBBbHNvLCBkaWZmZXJlbnQgdHVubmVscw0KICAgIDM5 NwkgICByZXByZXNlbnRlZCBpbiB0aGUgVHVubmVsIEVuY2Fwc3VsYXRpb24gYXR0cmlidXRlIG1h eSBoYXZlIFR1bm5lbA0KICAgIDM5OAkgICBFbmRwb2ludHMgb2YgZGlmZmVyZW50IGFkZHJlc3Mg ZmFtaWxpZXMuDQogICAgDQogICAgW25pdF0gSW4gdGhpcyBjYXNlICJUdW5uZWwgRW5kcG9pbnRz IiBpcyB1c2VkIHRvIHJlZmVyIHRvIHRoZSBBZGRyZXNzDQogICAgZmllbGQgaW4gdGhlIHN1Yi1U TFYsIHdoaWNoIGlzIGRlc2NyaWJlZCBhcyAidGhlIGFkZHJlc3Mgb2YgdGhlDQogICAgZW5kcG9p bnQgb2YgdGhlIHR1bm5lbCIgKGluIHRoZSBmaXJzdCBwYXJhZ3JhcGggb2YgdGhpcyBzZWN0aW9u KS4NCiAgICBUaGlzIHNlY3Rpb24gbW9zdGx5IHVzZWQgImFkZHJlc3MiIHRvIHJlZmVyIHRvIHRo ZSBzYW1lIGZpZWxkLCB3aGljaA0KICAgIGlzIGNhbGxlZCBBZGRyZXNzIGFueXdheS4gIFBsZWFz ZSBiZSBjb25zaXN0ZW50LiAgSSB3b3VsZCBwcmVmZXIgaXQgaWYNCiAgICBzL1R1bm5lbCBFbmRw b2ludC9hZGRyZXNzIG9mIHRoZSBlbmRwb2ludCBvZiB0aGUgdHVubmVsIC0tIGlmIHlvdQ0KICAg IHJhdGhlciB1c2UgIlR1bm5lbCBFbmRwb2ludCIsIHRoZW4gcGVyaGFwcyBjb25zaWRlciBjaGFu Z2luZyB0aGUgbmFtZQ0KICAgIG9mIHRoZSBmaWVsZC4NCiAgICANCiAgICANCiAgICAuLi4NCiAg ICA0MDQJICAgVGhlIEFTIG51bWJlciBpbiB0aGUgc3ViLVRMViBNVVNUIGJlIHRoZSBudW1iZXIg b2YgdGhlIEFTIHRvIHdoaWNoDQogICAgNDA1CSAgIHRoZSBJUCBhZGRyZXNzIGluIHRoZSBzdWIt VExWIGJlbG9uZ3MuDQogICAgDQogICAgW21ham9yXSBXaGF0IGlmIGl0IGRvZXNuJ3Q/ICBXaGF0 IGRvZXMgImJlbG9uZyIgbWVhbj8gIFBsZWFzZSBwdXQgYQ0KICAgIGZvcndhcmQgcmVmZXJlbmNl IHRvIMKnMTMuDQogICAgDQogICAgW21ham9yXSBTaG91bGQgdGhlIFVQREFURSB3aXRoIHRoZSBU dW5uZWwgRW5jYXBzdWxhdGlvbiBBdHRyaWJ1dGUgYmUNCiAgICBvcmlnaW5hdGVkIGJ5IHRoZSBz YW1lIEFTIHRoYXQgb3JpZ2luYXRlZCB0aGUgcm91dGUgdG8gdGhlIGRlc3RpbmF0aW9uDQogICAg cmVmbGVjdGVkIGluIHRoZSBBZGRyZXNzIGZpZWxkPyAgU2hvdWxkIHRoZSBVUERBVEUgd2l0aCB0 aGUgVHVubmVsDQogICAgRW5jYXBzdWxhdGlvbiBBdHRyaWJ1dGUgYmUgb3JpZ2luYXRlZCBieSB0 aGUgc2FtZSBBU04gaW4gdGhpcyBzdWItVExWPw0KICAgICBBcmUgdGhlcmUgdmFsaWQgY2FzZXMg d2hlcmUgb3RoZXIgQVNlcyB3b3VsZC9zaG91bGQgb3JpZ2luYXRlIGENCiAgICBUdW5uZWwgRW5j YXBzdWxhdGlvbiBBdHRyaWJ1dGUgdXNlZCB0byBzZW5kIHRyYWZmaWMgc29tZXdoZXJlIGVsc2U/ DQogICAgDQogICAgDQogICAgNDA3CSAgIFRoZXJlIGlzIG9uZSBzcGVjaWFsIGNhc2U6IHRoZSBU dW5uZWwgRW5kcG9pbnQgc3ViLVRMViBNQVkgaGF2ZSBhDQogICAgNDA4CSAgIHZhbHVlIGZpZWxk IHdob3NlIEFkZHJlc3MgRmFtaWx5IHN1YmZpZWxkIGNvbnRhaW5zIDAuICBUaGlzIG1lYW5zDQog ICAgNDA5CSAgIHRoYXQgdGhlIHR1bm5lbCdzIGVncmVzcyBlbmRwb2ludCBpcyB0aGUgVVBEQVRF J3MgQkdQIG5leHQgaG9wLiAgSWYNCiAgICA0MTAJICAgdGhlIEFkZHJlc3MgRmFtaWx5IHN1YmZp ZWxkIGNvbnRhaW5zIDAsIHRoZSBBZGRyZXNzIHN1YmZpZWxkIGlzDQogICAgNDExCSAgIG9taXR0 ZWQsIGFuZCB0aGUgQXV0b25vbW91cyBTeXN0ZW0gbnVtYmVyIGZpZWxkIGlzIHNldCB0byAwLg0K ICAgIA0KICAgIFttYWpvcl0gcmZjNDI3MS9yZmM0NzYwIGNvbnNpc3RlbmN5OiBzL1VQREFURSdz IEJHUCBuZXh0IGhvcC9hZGRyZXNzDQogICAgb2YgdGhlIG5leHQgaG9wDQogICAgDQogICAgW21p bm9yXSBUbyBrZWVwIGNvbnNpc3RlbnQgd2l0aCB0aGUgdGV4dCBhYm92ZSwgcGxlYXNlIHNwZWNp ZnkgdGhlIGxlbmd0aCAoNikuDQogICAgDQogICAgW21ham9yXSBXaHkgaXNuJ3QgdGhlIEFTTiBr ZXB0IHRvIGluZGljYXRlIHRoZSBBUyB0byB3aGljaCB0aGUgYWRkcmVzcw0KICAgIGluIHRoZSBO RVhUX0hPUCBiZWxvbmdzIHRvPyAgSSBhc2sgbW9zdGx5IGJlY2F1c2UgdGhlIHNwZWNpZmljYXRp b24NCiAgICBhYm92ZSBhYm91dCB0aGUgQVNOIHNheXMgdGhhdCBpdCAiTVVTVCBiZSB0aGUgbnVt YmVyIG9mIHRoZSBBUy4uLiIsDQogICAgd2hpY2ggaW1wbGllcyB0aGF0IHRoZXJlIGFyZSBubyBl eGNlcHRpb25zLiAgSWYgYXQgdGhpcyBwb2ludA0KICAgIChhc3N1bWluZyBpbXBsZW1lbnRhdGlv bnMpIHRoZSBBU04gaGFzIHRvIGJlIDAsIHRoZW4gcGxlYXNlIHVzZQ0KICAgICJTSE9VTEQiIGlu IHRoZSBpbml0aWFsIHNwZWNpZmljYXRpb24uDQogICAgDQogICAgDQogICAgNDEzCSAgIElmIGFu eSBvZiB0aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMgaG9sZCwgdGhlIFR1bm5lbCBFbmRwb2ludCBz dWItVExWDQogICAgNDE0CSAgIGlzIGNvbnNpZGVyZWQgdG8gYmUgIm1hbGZvcm1lZCI6DQogICAg DQogICAgNDE2CSAgIG8gIFRoZSBzdWItVExWIGNvbnRhaW5zIHRoZSB2YWx1ZSBmb3IgSVB2NCBp biBpdHMgQWRkcmVzcyBGYW1pbHkNCiAgICA0MTcJICAgICAgc3ViZmllbGQsIGJ1dCB0aGUgbGVu Z3RoIG9mIHRoZSBzdWItVExWJ3MgdmFsdWUgZmllbGQgaXMgb3RoZXINCiAgICA0MTgJICAgICAg dGhhbiAxMCAoMHhhKS4NCiAgICANCiAgICA0MjAJICAgbyAgVGhlIHN1Yi1UTFYgY29udGFpbnMg dGhlIHZhbHVlIGZvciBJUHY2IGluIGl0cyBBZGRyZXNzIEZhbWlseQ0KICAgIDQyMQkgICAgICBz dWJmaWVsZCwgYnV0IHRoZSBsZW5ndGggb2YgdGhlIHN1Yi1UTFYncyB2YWx1ZSBmaWVsZCBpcyBv dGhlcg0KICAgIDQyMgkgICAgICB0aGFuIDIyICgweDE2KS4NCiAgICANCiAgICA0MjQJICAgbyAg VGhlIHN1Yi1UTFYgY29udGFpbnMgdGhlIHZhbHVlIHplcm8gaW4gaXRzIEFkZHJlc3MgRmFtaWx5 IGZpZWxkLA0KICAgIDQyNQkgICAgICBidXQgdGhlIGxlbmd0aCBvZiB0aGUgc3ViLVRMVidzIHZh bHVlIGZpZWxkIGlzIG90aGVyIHRoYW4gNiwgb3INCiAgICA0MjYJICAgICAgdGhlIEF1dG9ub21v dXMgU3lzdGVtIHN1YmZpZWxkIGlzIG5vdCBzZXQgdG8gemVyby4NCiAgICANCiAgICBbbWlub3Jd IElzIHRoZXJlIGFueSB3YXkgdG8gZ2VuZXJhbGl6ZSB0aGVzZSBjb25kaXRpb25zPyAgSWYgZ2Vu ZXJhbCwNCiAgICB0aGVuIHdlIGRvbid0IG5lZWQgdG8gd29ycnkgYWJvdXQgZnV0dXJlIEFGcyBj bGVhcmx5IHNwZWNpZnlpbmcgd2hhdCBhDQogICAgbWFsZm9ybWVkIHN1Yi1UTFYgaXMuDQogICAg DQogICAgU3VnZ2VzdGlvbj4NCiAgICAgICAuLi50aGUgTGVuZ3RoIG9mIHRoZSBzdWItVExWIGlz IG5vdCA2ICsgdGhlIGxlbmd0aCBvZiB0aGUgQUYuLi5hcyBzcGVjaWZpZWQNCiAgICAgICBhYm92 ZS4NCiAgICANCiAgICANCiAgICA0MjgJICAgbyAgVGhlIElQIGFkZHJlc3MgaW4gdGhlIHN1Yi1U TFYncyBhZGRyZXNzIHN1YmZpZWxkIGlzIG5vdCBhIHZhbGlkIElQDQogICAgNDI5CSAgICAgIGFk ZHJlc3MgKGUuZy4sIGl0J3MgYW4gSVB2NCBicm9hZGNhc3QgYWRkcmVzcykuDQogICAgDQogICAg W21ham9yXSBXaGF0IGlzIGEgInZhbGlkIElQIGFkZHJlc3MiPyAgVGhlIHRleHQgYWJvdmUgc2F5 cyB0aGF0DQogICAgbGluay1sb2NhbCBhcmUgbm90IGFsbG93ZWQuLi5hbmQgdGhhdCBhIGhvc3Qg YWRkcmVzcyBpcyBleHBlY3RlZC4uLmFuZA0KICAgIHRoYXQgdGhlIGFkZHJlc3MgbXVzdCAiYmVs b25nIi4uLm5vdyB5b3UgYWRkZWQgYnJvYWRjYXN0IGFkZHJlc3Nlcy4NCiAgICBBbnl0aGluZyBl bHNlPyAgSXMgYSBtdWx0aWNhc3QgZGVzdGluYXRpb24gInZhbGlkIj8gIElzIHRoZXJlIGENCiAg ICByZWZlcmVuY2UgdGhhdCBjYW4gYmUgYWRkZWQgaGVyZSB0byBhdm9pZCBoYXZpbmcgdG8gZGVm aW5lIGl0Pw0KICAgIA0KICAgIA0KICAgIDQzMQkgICBvICBJdCBjYW4gYmUgZGV0ZXJtaW5lZCB0 aGF0IHRoZSBJUCBhZGRyZXNzIGluIHRoZSBzdWItVExWJ3MgYWRkcmVzcw0KICAgIDQzMgkgICAg ICBzdWJmaWVsZCBkb2VzIG5vdCBiZWxvbmcgdG8gdGhlIG5vbi16ZXJvIEFTIHdob3NlIG51bWJl ciBpcyBpbiB0aGUNCiAgICA0MzMJICAgICAgaXRzIEF1dG9ub21vdXMgU3lzdGVtIHN1YmZpZWxk LiAgKFNlZSBzZWN0aW9uIFNlY3Rpb24gMTMgZm9yDQogICAgNDM0CSAgICAgIGRpc2N1c3Npb24g b2Ygb25lIHdheSB0byBkZXRlcm1pbmUgdGhpcy4pDQogICAgDQogICAgW21ham9yXSAib25lIHdh eSIgIEkgaG9wZSB0aGF0IGl0IGlzIHRoZSBNVEkgd2F5IC0tIG90aGVyd2lzZSwgdGhlDQogICAg ZGV0ZXJtaW5hdGlvbiBvZiB0aGUgc3ViLVRMViBiZWluZyBtYWxmb3JtZWQgaXMgbm90IGRldGVy bWluaXN0aWMuDQogICAgDQogICAgDQogICAgNDM2CSAgIElmIHRoZSBUdW5uZWwgRW5kcG9pbnQg c3ViLVRMViBpcyBtYWxmb3JtZWQsIHRoZSBUTFYgY29udGFpbmluZyBpdCBpcw0KICAgIDQzNwkg ICBhbHNvIGNvbnNpZGVyZWQgdG8gYmUgbWFsZm9ybWVkLCBhbmQgdGhlIGVudGlyZSBUTFYgTVVT VCBiZSBpZ25vcmVkLg0KICAgIDQzOAkgICBIb3dldmVyLCB0aGUgVHVubmVsIEVuY2Fwc3VsYXRp b24gYXR0cmlidXRlIE1VU1QgTk9UIGJlIGNvbnNpZGVyZWQgdG8NCiAgICA0MzkJICAgYmUgbWFs Zm9ybWVkIGluIHRoaXMgY2FzZTsgb3RoZXIgVExWcyBpbiB0aGUgYXR0cmlidXRlIE1VU1QgYmUN CiAgICA0NDAJICAgcHJvY2Vzc2VkIChpZiB0aGV5IGNhbiBiZSBwYXJzZWQgY29ycmVjdGx5KS4N CiAgICANCiAgICBbbWFqb3JdICJzdWItVExWIGlzIG1hbGZvcm1lZCwgdGhlIFRMViBjb250YWlu aW5nIGl0IGlzIGFsc28NCiAgICBjb25zaWRlcmVkIHRvIGJlIG1hbGZvcm1lZCwgYW5kIHRoZSBl bnRpcmUgVExWIE1VU1QgYmUgaWdub3JlZC4iICDCpzExDQogICAgYWRkczogInRoZSBlbnRpcmUg VExWIE1VU1QgYmUgaWdub3JlZCwgYW5kIE1VU1QgYmUgcmVtb3ZlZCBmcm9tIHRoZQ0KICAgIFR1 bm5lbCBFbmNhcHN1bGF0aW9uIGF0dHJpYnV0ZSIuICBQbGVhc2Ugc3BlY2lmeSB0aGluZ3Mgb25s eSBvbmNlIQ0KICAgIEluc3RlYWQgb2Ygc3BlY2lmeWluZyB3aGF0IHRvIGRvIGluIHRoaXMgc2Vj dGlvbiwgcHV0IGEgcmVmZXJlbmNlIHRvDQogICAgwqcxMSBhbmQgdGFrZSBjYXJlIG9mIGl0IHRo ZXJlLg0KICAgIA0KICAgIA0KICAgIDQ0MgkgICBXaGVuIHJlZGlzdHJpYnV0aW5nIGEgcm91dGUg dGhhdCBpcyBjYXJyeWluZyBhIFR1bm5lbCBFbmNhcHN1bGF0aW9uDQogICAgNDQzCSAgIGF0dHJp YnV0ZSBjb250YWluaW5nIGEgVExWIHRoYXQgaXRzZWxmIGNvbnRhaW5zIGEgbWFsZm9ybWVkIFR1 bm5lbA0KICAgIDQ0NAkgICBFbmRwb2ludCBzdWItVExWLCB0aGUgVExWIE1VU1QgYmUgcmVtb3Zl ZCBmcm9tIHRoZSBhdHRyaWJ1dGUgYmVmb3JlDQogICAgNDQ1CSAgIHJlZGlzdHJpYnV0aW9uLg0K ICAgIA0KICAgIFttaW5vcl0gVGhpcyBwYXJhZ3JhcGggc2VlbXMgdG8gc2F5IHRoZSBzYW1lIHRo aW5nIGFzIMKnMTEsIGJ1dCBwbGVhc2UNCiAgICB0YWtlIGl0IG91dCBhbmQgc3BlY2lmeSB0aGlu Z3Mgb25seSBvbmNlLg0KICAgIA0KICAgIFtuaXRdIHJmYzQyNzEgY29uc2lzdGVuY3kgIHMvcmVk aXN0cmlidXRlL2Rpc3RyaWJ1dGUvZw0KICAgIA0KICAgIDQ0NwkgICBTZWUgU2VjdGlvbiAxMSBm b3IgZnVydGhlciBkaXNjdXNzaW9uIG9mIGhvdyB0byBoYW5kbGUgZXJyb3JzIHRoYXQNCiAgICA0 NDgJICAgYXJlIGVuY291bnRlcmVkIHdoZW4gcGFyc2luZyB0aGUgVHVubmVsIEVuY2Fwc3VsYXRp b24gYXR0cmlidXRlDQoNCg== From nobody Wed Feb 26 11:14:53 2020 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 883DB3A11B6; Wed, 26 Feb 2020 11:14:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.118.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <158274448738.22896.13879718453640904283@ietfa.amsl.com> Date: Wed, 26 Feb 2020 11:14:47 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-model-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 19:14:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : BGP YANG Model for Service Provider Networks Authors : Mahesh Jethanandani Keyur Patel Susan Hares Jeffrey Haas Filename : draft-ietf-idr-bgp-model-08.txt Pages : 134 Date : 2020-02-26 Abstract: This document defines a YANG data model for configuring and managing BGP, including protocol, policy, and operational aspects, such as RIB, based on data center, carrier and content provider operational requirements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-model-08 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-model-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 26 11:29:04 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D6283A12A5 for ; Wed, 26 Feb 2020 11:28:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlHHQR6h473p for ; Wed, 26 Feb 2020 11:28:57 -0800 (PST) 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 D356A3A126A for ; Wed, 26 Feb 2020 11:28:57 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id h8so138380pgs.9 for ; Wed, 26 Feb 2020 11:28:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=s9x5DiZ9bxx68HkavC6+QU6ATkvxOHBCEtqbWAJ7zso=; b=HTIiazucnTRoCTGC0W5vPEZxCTGFmlzPStFXk0ZzEc4LokiLKS6HuW7ZElHZSQBIah oa026pmI7ebKbFc0vY6Ai1V7nE68AqXgWFEsWCFG1YFpB9fbKKPP/6jDWVKk7XT575Ch AgQM+bCdDNuTpBYQyEF9EDYSKyn4dd7uMaoXXEObHQsoPgjxlszkFKMT7ZZINWvZZ44N w29WyWGxD6YGamR05d1kVc3nKFaSmD2Rdd8tewa6yMoEkC8AdVOvW8l0FJ5b9S/1j7Yz M6EWbd+Kr92UxmIQYw6nV5EQ7yWoxITovdYIZKImGmQuYz8V8eqNN49C3vryuiwtL8HV fi8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=s9x5DiZ9bxx68HkavC6+QU6ATkvxOHBCEtqbWAJ7zso=; b=Hw50FxlevB4tVb6q5SfTvb6FhU3yVpfS5lAZ88jh/C9ETuOPgfsw65p7qjqb3jOkPM eeGPu+e2EtbXIK+CIxKGXPe+UZm2EvBazV1D6E6EUnldO8VhP0G/zzw+jjNPnG0xJDFW KWbOJE/Qh/zBMFTp/6hhmVXEz/gB2xThkJhxEf7RrqtlgTrlPuBexviZMXRTdSZXaKPX MCKdcjXIpIhgwQ4+mJKf3WkxAX6m2Nu6ZRjlWF18q7vFn6Cy3mq15lfnh7YOPreEJWLn 4gSOd6zT27oRM9FatVADiSu+K6/DPIgx1KQIiOiNBNEGm3xTCg2iLsbI8cLEhzazOGxm n1WQ== X-Gm-Message-State: APjAAAUidzp6FBr0ybCl84WtPPEk1EjqJNu7IHokaRur8iQHxdVNx3Mi M2+yBc5eLOJmfJDPNcQvmaA/pX4C X-Google-Smtp-Source: APXvYqyMZZc4qtOFttvaQFPMt/4ZIB5DWuL86ILJTVSZNlnGV7IY1Oe+WohfmMH3jKobMKRKqjiy4Q== X-Received: by 2002:a63:aa09:: with SMTP id e9mr382700pgf.354.1582745336831; Wed, 26 Feb 2020 11:28:56 -0800 (PST) Received: from ?IPv6:2601:647:5600:5020:fc85:6a70:dcf9:1922? ([2601:647:5600:5020:fc85:6a70:dcf9:1922]) by smtp.gmail.com with ESMTPSA id t65sm4020648pfd.178.2020.02.26.11.28.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Feb 2020 11:28:55 -0800 (PST) From: Mahesh Jethanandani Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 26 Feb 2020 11:28:54 -0800 References: <158274448738.22896.13879718453640904283@ietfa.amsl.com> To: idr@ietf.org In-Reply-To: <158274448738.22896.13879718453640904283@ietfa.amsl.com> Message-Id: <01561CB6-6AE5-44E0-8269-D3BF945C21B3@gmail.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Idr] I-D Action: draft-ietf-idr-bgp-model-08.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 19:29:03 -0000 This update addresses the discussion we had in IETF 106 and the issues = that were discussed in that meeting. In particular it adds support for = securing the BGP session. Examples have now been moved to the = non-normative section of the document (in Appendix). It does not include changes to address the early YANG doctors review = comments. The errors reported by the YANG validator, are mostly open = source tool issues at this time. The module has been validated using = commercial tools. Cheers. > On Feb 26, 2020, at 11:14 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Inter-Domain Routing WG of the IETF. >=20 > Title : BGP YANG Model for Service Provider Networks > Authors : Mahesh Jethanandani > Keyur Patel > Susan Hares > Jeffrey Haas > Filename : draft-ietf-idr-bgp-model-08.txt > Pages : 134 > Date : 2020-02-26 >=20 > Abstract: > This document defines a YANG data model for configuring and managing > BGP, including protocol, policy, and operational aspects, such as > RIB, based on data center, carrier and content provider operational > requirements. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-model/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-idr-bgp-model-08 > https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-model-08 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-idr-bgp-model-08 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr From nobody Wed Feb 26 14:19:22 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B553B3A08FC; Wed, 26 Feb 2020 14:19:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.902 X-Spam-Level: ** X-Spam-Status: No, score=2.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, GB_SUMOF=5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 0oSakagC2QxI; Wed, 26 Feb 2020 14:19:18 -0800 (PST) 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 4152C3A08F3; Wed, 26 Feb 2020 14:19:15 -0800 (PST) Received: by mail-ed1-x531.google.com with SMTP id dm3so769158edb.1; Wed, 26 Feb 2020 14:19:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=UMTXTtjj9drzt9D0vXQn0lUkKaSSJy+1z6A+aJEu6eA=; b=IQRZ8x70nHCsub/VqCIV+1aj3fuVXfDeLotJh2bjuR8UAvmO+ctm3UFXOOCxBPqNMc HmKRgsedc0/JZU+sn23hC9KdWsXbjCwJAid9pA0WO18d0GeUmx6isdyjN+3M+oacYare D/AtDGA2aNvQt8mcxqFSwxC9WLEbZsuxjTTQdwd/9VP27eUUMd1yNePJWMpBkTcf7G5i k7v7ORz71qwANlUyMkMVCBaDWJiN2vrcX1w+jg6qhIc6uDnsVw0+Xx1GWuGeiu7Ztvgl q2j3wCqz044SgaqhxfPggQfaWdmkfiOUVrgQbCGM42I1+qYJFVvdlxdHNdgSqg1+ZGBY ZmQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=UMTXTtjj9drzt9D0vXQn0lUkKaSSJy+1z6A+aJEu6eA=; b=OlKCFBpPxMlv+bmrz7RsrmkKeVSCZ62bTp8d+wvqrq8zTlxZXqhU3DUXuY6zYpQ6Ni WHaqHKKLF3NEtXm1T3Y2AnS4QSw1ZpLEZQ7NEGc2DLf8wk5iW1w1K/9QFN6OjSSnrqZ9 N1eUWot3K+1rtwuEt7fIh0Hz/WRuucz6ISP8oKSH/wQ9d06n8PC4x2KPbMPaFMGlJq1T Ddn1ZL5sigtHo7g/ZhmbM6dff3iM1ofHid8moeIsmmNNryhh11hXrjN19W4+ZKryqA6N xU/wXC2Zx+dYou5PvF1OsVWnR8wLn6LsVibPdslJAlEobbrk6swr4IQqRAxEe3Cxa547 fDTw== X-Gm-Message-State: APjAAAWk2etUPRg3lukpXpQGEGkp4sh7agyCspjR39A1MgITax7ru0M8 JONgAMWdeARuNYACea9dBztUL3EQguCbldBsp79fzKfu X-Google-Smtp-Source: APXvYqw7OdKk5X26Qw5msXWaVkCRxNWNesEBtDdkTCpT+tV9E955qsmbN1GJoslFZQPZiCIeTSMCn7MkA771/X+0m28= X-Received: by 2002:a17:906:1cd0:: with SMTP id i16mr787052ejh.186.1582755552747; Wed, 26 Feb 2020 14:19:12 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 26 Feb 2020 14:19:12 -0800 From: Alvaro Retana MIME-Version: 1.0 Date: Wed, 26 Feb 2020 14:19:11 -0800 Message-ID: To: draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org Cc: Susan Hares , idr-chairs@ietf.org, "idr@ietf. org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Idr] AD Review of draft-ietf-idr-bgp-ls-segment-routing-msd-09 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Feb 2020 22:19:21 -0000 Dear authors: This is my review of draft-ietf-idr-bgp-ls-segment-routing-msd-09. =C2=A0I have put some comments in-line below which should be easy to address. This document, like many other BGP-LS specifications to carry IGP-derived information is written with that assumption: that the information will come from the IGPs. =C2=A0However, =C2=A72 reads: =C2=A0 =C2=A0 The BGP-LS speaker may also advertise the MSD information for= the local =C2=A0 =C2=A0 node and its links when not running any link-state IGP protoc= ol e.g. when =C2=A0 =C2=A0 running BGP as the only routing protocol. This case (no IGP) is not fully explained in the text. =C2=A0Borrowing from the IGP RFCs, two clear pieces of information that are missing are: =C2=A0 =C2=A0(1) A definition of what the Node/Link MSDs are. =C2=A0I borro= wed from rfc8476 =C2=A0 =C2=A0and made suggestions for =C2=A73 and =C2=A74 of this document = (in-line). =C2=A0 =C2=A0(2) "Procedures for Defining and Using Node and Link MSD Adver= tisements", =C2=A0 =C2=A0similar to =C2=A74 (in both rfc8476/rfc8491). =C2=A0Suggestion= : simply include the =C2=A0 =C2=A0text from rfc8476 after =C2=A74 of this document. The text in =C2=A72 is also not specific on how this local information should be advertised using BGP-LS. =C2=A0Should the Direct Protocol Identifier be used, or, because of "running BGP as the only routing protocol" should it be BGP? =C2=A0Please add details to the specification. One more related point. =C2=A0The deployment model for collecting IGP-derived information is that "BGP-LS is configured on a small number of nodes" [rfc8491], but the model for advertising local information is different. =C2=A0Please include some text about that too. I will wait for a revised document to primarily address this text from =C2=A72 (and the in-line comments marked as [major]) before starting the IETF LC. Thanks! Alvaro. [Line numbers from idnits.] ... 14 Signaling MSD (Maximum SID Depth) using Border Gateway Protocol Link- 15 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 State [minor] s/Border Gateway Protocol Link-State/Border Gateway Protocol - Link State/g That is the form used in rfc7752 -- in the only place where BGP-LS is expan= ded. ... 79 1. =C2=A0Introduction 81 =C2=A0 When Segment Routing (SR) [RFC8402] paths are computed by a 82 =C2=A0 centralized controller, it is critical that the controller learn= s the 83 =C2=A0 Maximum SID Depth (MSD) that can be imposed at each node/link on= a 84 =C2=A0 given SR path. =C2=A0This ensures that the Segment Identifier (S= ID) stack 85 =C2=A0 depth of a computed path doesn't exceed the number of SIDs the n= ode 86 =C2=A0 is capable of imposing. [nit] s/learns/learn ... 93 =C2=A0 However, if PCEP is not supported/configured on the head-end of = a SR 94 =C2=A0 tunnel or a Binding-SID anchor node, and controller does not 95 =C2=A0 participate in IGP routing, it has no way of learning the MSD of 96 =C2=A0 nodes and links. =C2=A0BGP-LS [RFC7752] defines a way to adverti= se 97 =C2=A0 topology and associated attributes and capabilities of the nodes= in 98 =C2=A0 that topology to a centralized controller. =C2=A0This document d= efines 99 =C2=A0 extensions to BGP-LS to advertise one or more types of MSDs at n= ode 100 =C2=A0 and/or link granularity. [nit] s/to advertise/to expose For consistency with the OSPF/ISIS documents. [minor] Including the last sentence above makes the text not flow well: it first says that extensions "to advertise one or more types of MSDs" are defined here...and then it talks about other types of MSDs. Suggestion: =C2=A0Move that sentence to be the first one in the last paragraph. 102 =C2=A0 Other types of MSD are known to be useful. =C2=A0For example, 103 =C2=A0 [I-D.ietf-ospf-mpls-elc] and [I-D.ietf-isis-mpls-elc] define Re= adable 104 =C2=A0 Label Depth Capability (RLDC) that is used by a head-end to ins= ert an 105 =C2=A0 Entropy Label (EL) at a depth that can be read by transit nodes= . 107 =C2=A0 In the future, it is expected that new MSD-Types will be define= d to 108 =C2=A0 signal additional capabilities, e.g., ELs, SIDs that can be imp= osed 109 =C2=A0 through recirculation, or SIDs associated with another data pla= ne 110 =C2=A0 such as IPv6. =C2=A0MSD advertisements MAY be useful even if SR= itself is 111 =C2=A0 not enabled. =C2=A0For example, in a non-SR MPLS network, MSD d= efines the 112 =C2=A0 maximum label depth. [major] s/MAY/may There is no Normative action in the sentence; it's just stating a fact. ... 116 1.1.1. =C2=A0Terminology 118 =C2=A0 BGP-LS: Distribution of Link-State and TE Information using Bor= der 119 =C2=A0 Gateway Protocol [minor] Don't add a definition for BGP-LS here because it was already expanded in the Abstract...to mean something else... 121 =C2=A0 MSD: Maximum SID Depth [minor] Please use the same definition as in rfc8476/rfc8491 ... 129 =C2=A0 SID: Segment Identifier [minor] Please use the same definition as in rfc8476/rfc8491 ... 140 =C2=A0 o =C2=A0pushing one or more new labels onto the label stack. = =C2=A0The number 141 =C2=A0 =C2=A0 =C2=A0of labels imposed is then the sum of the number of= labels that are 142 =C2=A0 =C2=A0 =C2=A0replaced and the number of labels that are pushed.= =C2=A0See [RFC3031] 143 =C2=A0 =C2=A0 =C2=A0for further details. [minor] Split off the last 2 sentences into their own paragraph. 145 1.1.2. =C2=A0Requirements Language 147 =C2=A0 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL N= OT", 148 =C2=A0 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY"= , and 149 =C2=A0 "OPTIONAL" in this document are to be interpreted as described = in BCP 150 =C2=A0 14 [RFC2119] [RFC8174] when, and only when, they appear in all 151 =C2=A0 capitals, as shown here . [nit] s/here ./here. 153 2. =C2=A0Advertisement of MSD via BGP-LS 155 =C2=A0 This document describes extensions that enable BGP-LS speakers = to 156 =C2=A0 signal the MSD capabilities (described in [RFC8491] ) of nodes = and 157 =C2=A0 their links in a network to a BGP-LS consumer of network topolo= gy 158 =C2=A0 such as a centralized controller. =C2=A0The centralized control= ler can 159 =C2=A0 leverage this information in computation of SR paths and their 160 =C2=A0 instantiation on network nodes based on their MSD capabilities.= =C2=A0When 161 =C2=A0 a BGP-LS speaker is originating the topology learnt via link-st= ate 162 =C2=A0 routing protocols like OSPF or IS-IS, the MSD information for t= he 163 =C2=A0 nodes and their links is sourced from the underlying extensions= as 164 =C2=A0 defined in [RFC8476] and [RFC8491] respectively. =C2=A0The BGP-= LS speaker 165 =C2=A0 may also advertise the MSD information for the local node and i= ts 166 =C2=A0 links when not running any link-state IGP protocol e.g. when ru= nning 167 =C2=A0 BGP as the only routing protocol. [nit] s/This document describes extensions that enable BGP-LS speakers to signal the MSD capabilities (described in [RFC8491] )...The centralized controller can leverage this information...instantiation on network nodes based on their MSD capabilities./This document describes extensions that enable BGP-LS speakers to signal the MSD capabilities ([RFC8491])...The centralized controller can leverage this information...instantiation on network nodes. 169 =C2=A0 The extensions introduced in this document allow for advertisem= ent of 170 =C2=A0 different MSD-Types. =C2=A0This document does not define these = MSD-Types 171 =C2=A0 but leverages the definition, guidelines and the code-point reg= istry 172 =C2=A0 specified in [RFC8491]. =C2=A0This enables sharing of MSD-Types= that may 173 =C2=A0 be defined in the future by the IGPs in BGP-LS. [minor] Other MSD-Types, beyond what is defined in rfc8491 have already been defined...so maybe simplify the paragraph; suggestion: =C2=A0 =C2=A0The extensions introduced in this document allow for advertise= ment of =C2=A0 =C2=A0different MSD-Types, which are defined elsewhere and were intr= oduced in =C2=A0 =C2=A0[RFC8491]. =C2=A0This enables sharing of MSD-Types that may be= defined in the =C2=A0 =C2=A0future by the IGPs in BGP-LS. 175 3. =C2=A0Node MSD TLV 177 =C2=A0 Node MSD is encoded in a new Node Attribute TLV [RFC7752] using= the 178 =C2=A0 following format: [major] Suggestion> =C2=A0 =C2=A0The Node MSD ([RFC8476] [RFC8491]) is encoded in a new Node At= tribute TLV =C2=A0 =C2=A0[RFC7752] to carry the provisioned SID depth of the router ide= ntified by the =C2=A0 =C2=A0corresponding Router-ID. =C2=A0Node MSD is the smallest MSD su= pported by the node =C2=A0 =C2=A0on the set of interfaces configured for use. =C2=A0MSD values = may be learned via =C2=A0 =C2=A0a hardware API or may be provisioned. =C2=A0The following form= at is used: ... 200 =C2=A0 =C2=A0 =C2=A0* =C2=A0MSD-Type : one of the values defined in th= e IANA registry 201 =C2=A0 =C2=A0 =C2=A0 =C2=A0 titled "IGP MSD-Types" under the "Interior= Gateway Protocol 202 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (IGP) Parameters" registry created by [RFC= 8491]. [nit] s/IANA registry titled "IGP MSD-Types" under the "Interior Gateway Protocol (IGP) Parameters" registry created by [RFC8491]./"IGP MSD-Types" registry defined in [RFC8491]. ... 210 4. =C2=A0Link MSD TLV 212 =C2=A0 Link MSD is encoded in a new Link Attribute TLV [RFC7752] using= the 213 =C2=A0 following format: [major] Suggestion> =C2=A0 =C2=A0 The Link MSD ([RFC8476] [RFC8491]) is defined to carry the MS= D of the =C2=A0 =C2=A0 interface associated with the link. =C2=A0It is encoded in a = new Link Attribute =C2=A0 =C2=A0 TLV [RFC7752] using the following format: ... 234 =C2=A0 =C2=A0 =C2=A0* =C2=A0MSD-Type : one of the values defined in th= e IANA registry 235 =C2=A0 =C2=A0 =C2=A0 =C2=A0 titled "IGP MSD-Types" under the "Interior= Gateway Protocol 236 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (IGP) Parameters" registry created by [RFC= 8491]. [nit] s/IANA registry titled "IGP MSD-Types" under the "Interior Gateway Protocol (IGP) Parameters" registry created by [RFC8491]./"IGP MSD-Types" registry defined in [RFC8491]. ... 243 5. =C2=A0IANA Considerations ... 250 =C2=A0 =C2=A0 =C2=A0 +------------+-----------------+-----------------= ----------+ 251 =C2=A0 =C2=A0 =C2=A0 | Code Point | =C2=A0 Description =C2=A0 | =C2=A0= =C2=A0 IS-IS TLV/Sub-TLV =C2=A0 =C2=A0 | 252 =C2=A0 =C2=A0 =C2=A0 +------------+-----------------+-----------------= ----------+ 253 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0266 =C2=A0 =C2=A0 | Node MSD =C2= =A0 =C2=A0 =C2=A0 =C2=A0| 242/23 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0| 254 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0267 =C2=A0 =C2=A0 | Link MSD =C2= =A0 =C2=A0 =C2=A0 =C2=A0| (22,23,25,141,222,223)/15 | 255 =C2=A0 =C2=A0 =C2=A0 +------------+-----------------+-----------------= ----------+ [minor] Add a "Reference" column, and include "[This Document]" in it. 257 6. =C2=A0Manageability Considerations ... 272 =C2=A0 A consumer of the BGP-LS information retrieves this information= over 273 =C2=A0 a BGP-LS session (refer Section 1 and 2 of [RFC7752]). =C2=A0Th= e handling 274 =C2=A0 of semantic or content errors by the consumer would be dictated= by 275 =C2=A0 the nature of its application usage and hence is beyond the sco= pe of 276 =C2=A0 this document. [minor] Personally, I think that pointing to rfc7752 (as has already been done) is enough...and that the detail in the last paragraph is unnecessary for this document. =C2=A0Consider removing it. 278 =C2=A0 This document only introduces new Attribute TLVs and any syntac= tic 279 =C2=A0 error in them would result in the BGP-LS Attribute being discar= ded 280 =C2=A0 with an error log. =C2=A0The MSD information introduced in BGP-= LS by this 281 =C2=A0 specification, may be used by BGP-LS consumer applications like= a SR 282 =C2=A0 path computation engine (PCE) to learn the SR SID-stack handlin= g 283 =C2=A0 capabilities of the nodes in the topology. =C2=A0This can enabl= e the SR 284 =C2=A0 PCE to perform path computations taking into consideration the = size 285 =C2=A0 of SID Stack that the specific headend node may be able to impo= se. 286 =C2=A0 Errors in the encoding or decoding of the MSD information may r= esult 287 =C2=A0 in the unavailability of such information to the SR PCE or inco= rrect 288 =C2=A0 information being made available to it. =C2=A0This may result i= n the 289 =C2=A0 headend node not being able to instantiate the desired SR path = in its 290 =C2=A0 forwarding and provide the SR based optimization functionality.= =C2=A0The 291 =C2=A0 handling of such errors by applications like SR PCE may be 292 =C2=A0 implementation specific and out of scope of this document. [major] s/any syntactic error...BGP-LS Attribute being discarded with an error log./any syntactic error...BGP-LS Attribute being discarded [RFC7752]. 294 =C2=A0 The extensions specified in this document, do not specify any n= ew 295 =C2=A0 configuration or monitoring aspects in BGP or BGP-LS. =C2=A0The 296 =C2=A0 specification of BGP models BGP and BGP-LS models is an ongoing= work 297 =C2=A0 based on the [I-D.ietf-idr-bgp-model]. =C2=A0The management of = the MSD 298 =C2=A0 features within an ietf segment-routing stack is also an ongoin= g work 299 =C2=A0 based on the [I-D.ietf-spring-sr-yang]. =C2=A0Management of the= segment 300 =C2=A0 routing in IGPs is ongoing work for ISIS [I-D.ietf-isis-sr-yang= ] , 301 =C2=A0 and OSPF [I-D.ietf-ospf-sr-yang]. [nit] "BGP models BGP and BGP-LS models" =C2=A0I think there's a comma missing somewhere or maybe too many "BGPs"... =C2=A0BTW, I-D.ietf-idr-bgp-model does not include BGP-LS. [nit] s/an ietf segment-routing stack/an SR stack [nit] s/of the segment routing/of segment routing [nit] s/[I-D.ietf-isis-sr-yang] ,/[I-D.ietf-isis-sr-yang], [minor] I don't think that pointing at all this other work is necessary in this document. =C2=A0Please consider removing the paragraph (except for maybe the first sentence). 303 7. =C2=A0Security Considerations ... 313 =C2=A0 The document does not introduce additional security issues beyo= nd 314 =C2=A0 discussed in [RFC7752], [RFC8476] and [RFC8491]. =C2=A0However,= [RFC7752] 315 =C2=A0 is being revised in [I-D.ietf-idr-rfc7752bis] to provide additi= onal 316 =C2=A0 clarification in several portions of the specification after 317 =C2=A0 receiving feedback from implementers. =C2=A0One of the places t= hat is 318 =C2=A0 being clarified is the error handling and security. =C2=A0It is= expected 319 =C2=A0 that after [I-D.ietf-idr-rfc7752bis] is released that implement= ers 320 =C2=A0 will update all BGP-LS base implementations improving the error 321 =C2=A0 handling for protocol work (including this document) that depen= d on 322 =C2=A0 this function. [major] "The document does not introduce additional security issues beyond discussed in [RFC7752], [RFC8476] and [RFC8491]." =C2=A0True, but not complete. Suggestion> =C2=A0 =C2=A0The procedures and protocol extensions defined in this documen= t do not =C2=A0 =C2=A0affect the BGP security model. =C2=A0See the "Security Conside= rations" section of =C2=A0 =C2=A0[RFC4271] for a discussion of BGP security. =C2=A0Also, refer = to [RFC4272] and =C2=A0 =C2=A0[RFC6952] for analyses of security issues for BGP. Security co= nsiderations =C2=A0 =C2=A0for acquiring and distributing BGP-LS information are discusse= d in [RFC7752]. =C2=A0 =C2=A0The TLVs introduced in this document are used to propagate the= MSD IGP =C2=A0 =C2=A0extensions defined in [RFC8476] and [RFC8491]. =C2=A0It is ass= umed that the IGP =C2=A0 =C2=A0instances originating these TLVs will support all the required= security (as =C2=A0 =C2=A0described in [RFC8476] and [RFC8491]) in order to prevent any = security =C2=A0 =C2=A0issues when propagating the TLVs into BGP-LS. =C2=A0 =C2=A0The advertisement of the node and link attribute information d= efined in this =C2=A0 =C2=A0document presents no additional risk beyond that associated wi= th the =C2=A0 =C2=A0existing node and link attribute information already supported= in [RFC7752]. The references to rfc4271, rfc4272 and rfc6952 can be Informative. [minor] Including the reference to rfc7752bis may raise unnecessary questions and potentially delay the publication of this document. Note that the conclusion that "implementers will update all BGP-LS base implementations" is the natural result of Obsoleting rfc7752. Please consider removing the references. ... 366 10.2. =C2=A0Informative References ... 401 =C2=A0 [I-D.ietf-pce-segment-routing] 402 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sivabalan, S., Filsfil= s, C., Tantsura, J., Henderickx, W., 403 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and J. Hardwick, "PCEP= Extensions for Segment Routing", 404 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-pce-segment= -routing-16 (work in progress), 405 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0March 2019. =3D=3D Outdated reference: draft-ietf-pce-segment-routing has been publishe= d as =C2=A0 =C2=A0RFC 8664 From nobody Fri Feb 28 00:42:42 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA973A1345 for ; Fri, 28 Feb 2020 00:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.123 X-Spam-Level: *** X-Spam-Status: No, score=3.123 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=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 uALk1vohkF1F for ; Fri, 28 Feb 2020 00:42:40 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 356B53A1343 for ; Fri, 28 Feb 2020 00:42:40 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.177.57.99; From: "Susan Hares" To: "'idr@ietf. org'" Date: Fri, 28 Feb 2020 03:42:36 -0500 Message-ID: <014e01d5ee13$07aac8c0$17005a40$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_014F_01D5EDE9.1ED535F0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AdXuEwIqRTk3FL7+Rt2L7zDQcomb3w== X-Antivirus: AVG (VPS 200227-0, 02/27/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Idr] draft-ietf-idr-flow-spec-v6-10 - IPR call prior to WG Last call X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 08:42:42 -0000 This is a multipart message in MIME format. ------=_NextPart_000_014F_01D5EDE9.1ED535F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Greetings: This begins an IPR poll prior to a WG last call for draft-ietf-idr-flowspec-v6-10.txt. All Authors should respond to the IPR call. Cheerily, Susan Hares ------=_NextPart_000_014F_01D5EDE9.1ED535F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greetings: =

 

This begins an IPR poll prior to a WG last call for = draft-ietf-idr-flowspec-v6-10.txt.   All Authors should = respond to the IPR call.

 

Cheerily, = Susan Hares

------=_NextPart_000_014F_01D5EDE9.1ED535F0-- From nobody Fri Feb 28 00:47:43 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 069993A1357 for ; Fri, 28 Feb 2020 00:47:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.224 X-Spam-Level: * X-Spam-Status: No, score=1.224 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001, SPF_NONE=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 h3F_-IXO3Wwq for ; Fri, 28 Feb 2020 00:47:39 -0800 (PST) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 BD83C3A1356 for ; Fri, 28 Feb 2020 00:47:39 -0800 (PST) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.177.57.99; From: "Susan Hares" To: "'idr@ietf. org'" References: <014e01d5ee13$07aac8c0$17005a40$@ndzh.com> In-Reply-To: <014e01d5ee13$07aac8c0$17005a40$@ndzh.com> Date: Fri, 28 Feb 2020 03:47:36 -0500 Message-ID: <016701d5ee13$ba40b5d0$2ec22170$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0168_01D5EDE9.D16E3040" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHLBgVO4v2IsVTaJTtZtSMpanKpmahGGxTw X-Antivirus: AVG (VPS 200227-0, 02/27/2020), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Idr] draft-ietf-idr-flow-spec-v6-10 - IPR call prior to WG Last call X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 08:47:41 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0168_01D5EDE9.D16E3040 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I do not know of any IPR related to draft-ietf-idr-flowspec-v6-10.txt other than the original IPR for RFC5575.txt. I am not the source of any IPR relating to draft-ietf-idr-flowspec-v6-10.txt. Cheerily, Susan Hares From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Friday, February 28, 2020 3:43 AM To: 'idr@ietf. org' Subject: [Idr] draft-ietf-idr-flow-spec-v6-10 - IPR call prior to WG Last call Greetings: This begins an IPR poll prior to a WG last call for draft-ietf-idr-flowspec-v6-10.txt. All Authors should respond to the IPR call. Cheerily, Susan Hares ------=_NextPart_000_0168_01D5EDE9.D16E3040 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<author hat on>

 

I do not know of any IPR = related to draft-ietf-idr-flowspec-v6-10.txt other than the original IPR = for RFC5575.txt.

 

I am not the source of = any IPR relating to draft-ietf-idr-flowspec-v6-10.txt. =

 

Cheerily, Susan Hares =

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Friday, February 28, 2020 3:43 AM
To: = 'idr@ietf. org'
Subject: [Idr] draft-ietf-idr-flow-spec-v6-10 = - IPR call prior to WG Last call

 

Greetings: =

 

This begins an IPR poll prior to a WG last call for = draft-ietf-idr-flowspec-v6-10.txt.   All Authors should = respond to the IPR call.

 

Cheerily, = Susan Hares

------=_NextPart_000_0168_01D5EDE9.D16E3040-- From nobody Fri Feb 28 01:19:12 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C20F3A13C4 for ; Fri, 28 Feb 2020 01:19:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 uhkJSr6Wvw-J for ; Fri, 28 Feb 2020 01:19:10 -0800 (PST) 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 E365A3A13C5 for ; Fri, 28 Feb 2020 01:19:09 -0800 (PST) Received: by mail-ot1-x331.google.com with SMTP id h9so1920072otj.11 for ; Fri, 28 Feb 2020 01:19:09 -0800 (PST) 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=N8c54QjRQpJpxE4zjttxgXAyhvpZjyD+WYaqpw7O5RQ=; b=Pxlm93enlikkbYVROR8UIlkaLvFTR8YzpASZaRZ1jV66205S9i8kHsgRYjYGMuxPfj k0bt/1J+6vFoPPen9wJwYdyqzCHOTHF63O1vJn7QrcRN38tZhOr9Jn/pCsjaNOjmMoBJ L/1GI9nb6x27cjP925zIrC6aVTo3sNlu6zesYYK2XoIjnZTosZUNEnbOWa46qhUPUkd0 sf1i74Kuc0xSBi4Y9X9DMey8NWDiOFLfCHGuA2fNgpMunUUxgnIgEMwxuVp6UXr6yjxb NQokrWhqxgAwEBR+uzWxSPpnokQSCqTBmPojobn4mjVJQlR4iCcc6T4RJBEYjR9oo+yi AxBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=N8c54QjRQpJpxE4zjttxgXAyhvpZjyD+WYaqpw7O5RQ=; b=EPV5y3CDpUO5cN5UsDmxdyd8XbeuS0Kx+SgXXHxUpHqHlObx0/9zzGb5WAM35GsyC/ nKDfiHh+TZ+mm09XoJVEZKOcF6qYWCQUuVxk2ziadrTGn4KPyBOkT8sxyK0dBZn+Iehv ps9yyLw0bGZwmGZhUS+45CNXIsE23pYmUNVehHds/wPGW1P1v64Ev0n80DAJK3cNYrIJ Z5Tkccw+MgqUZ9UafzpIPYPGCBh55T/bjiU+klFLcOo5fqUVwUL2VyJxG5oWldECWRQW 4gDYchrvuigJiaAG7M/bijDqyOPocrpj+i4vgo2YN2qFzpC6uWnNiEvT/I2P2luJ0AqX B0gA== X-Gm-Message-State: APjAAAU+iXsNlt3e5In2UeHJdrKkMVzT0ba8tOKvLYJ8yiXl7Z7lY3+S HcDZ3wZUVLKh8L3HPoZ/dFDMFIaoNpIDecmI6787hf17Cis= X-Google-Smtp-Source: APXvYqzFQpY3IjcHXZJUN6WTWV/tkwIko2HW3ioMZVu2jSoR7+Mjkrcak0fqkGAGwb/QSae4WxfioGWid3UFqz9bhYc= X-Received: by 2002:a9d:6a06:: with SMTP id g6mr2303585otn.305.1582881549084; Fri, 28 Feb 2020 01:19:09 -0800 (PST) MIME-Version: 1.0 References: <014e01d5ee13$07aac8c0$17005a40$@ndzh.com> In-Reply-To: <014e01d5ee13$07aac8c0$17005a40$@ndzh.com> From: Robert Raszuk Date: Fri, 28 Feb 2020 10:18:59 +0100 Message-ID: To: Susan Hares Cc: "idr@ietf. org" Content-Type: multipart/alternative; boundary="000000000000747b2f059f9f54ef" Archived-At: Subject: Re: [Idr] draft-ietf-idr-flow-spec-v6-10 - IPR call prior to WG Last call X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 09:19:12 -0000 --000000000000747b2f059f9f54ef Content-Type: text/plain; charset="UTF-8" I am not aware of any IPR related to content of draft-ietf-idr-flowspec-v6. Kind regards, R. On Fri, Feb 28, 2020 at 9:42 AM Susan Hares wrote: > Greetings: > > > > This begins an IPR poll prior to a WG last call for > draft-ietf-idr-flowspec-v6-10.txt. All Authors should respond to the IPR > call. > > > > Cheerily, Susan Hares > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --000000000000747b2f059f9f54ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


I am not aware of any IPR related to content of draft-ietf-idr-flowspec-v= 6.=C2=A0

=C2=A0

Kind regards,

R.


On Fri, Feb 28, 2020 at 9:42 AM Susan Hares <shares@ndzh.com> wrote:

Greetings:

<= /u>=C2=A0

This begins an IPR poll prior to= a WG last call for draft-ietf-idr-flowspec-v6-10.txt. =C2=A0=C2=A0All Auth= ors should respond to the IPR call.

=C2=A0

Cheerily, Susan Hares <= /u>

_______________________________________________ Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--000000000000747b2f059f9f54ef-- From nobody Fri Feb 28 14:35:08 2020 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B619F3A1F62; Fri, 28 Feb 2020 14:34:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: aretana.ietf@gmail.com, idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <158292929472.19931.16929943895646723432@ietfa.amsl.com> Date: Fri, 28 Feb 2020 14:34:54 -0800 Archived-At: Subject: [Idr] idr - Requested sessions have been scheduled for IETF 107 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Feb 2020 22:35:02 -0000 Dear Susan Hares, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. idr Session 1 (2:00 requested) Monday, 23 March 2020, Morning Session I 1000-1200 Room Name: Regency F size: 150 --------------------------------------------- idr Session 2 (1:30 requested) Tuesday, 24 March 2020, Afternoon Session II 1550-1720 Room Name: Regency D size: 300 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/107/sessions/idr.ics Request Information: --------------------------------------------------------- Working Group Name: Inter-Domain Routing Area Name: Routing Area Session Requester: Susan Hares Number of Sessions: 2 Length of Session(s): 2 Hours, 1.5 Hours Number of Attendees: 75 Conflicts to Avoid: Chair Conflict: i2rs grow lsvr bess Technology Overlap: sidrops lsr spring rtgwg People who must be present: Susan Hares John Scudder Alvaro Retana Resources Requested: Special Requests: Schedule on Monday or Tuesday due to chair conflict. --------------------------------------------------------- From nobody Fri Feb 28 17:17:47 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66D753A0874; Fri, 28 Feb 2020 17:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 URsMZElCzite; Fri, 28 Feb 2020 17:17:43 -0800 (PST) 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 6A2E13A0873; Fri, 28 Feb 2020 17:17:43 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id y8so1889343pll.13; Fri, 28 Feb 2020 17:17:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=ZWvq+jFdsnea//mUxKbLZNpeXJnmoS8lJOBYwQglqtU=; b=XEfXS1PcWzMV++/LVphp2meMm8V5EICOdD09PWk7iWLzyABDfG1ezpnbyjp+tjlxv3 Q0bOLqvXPlxHqnD2SWe+8CCITBTbD8JW6yHA7Yhtmn5TB7fTiKsoUNN023pGbxu959rI Q+z89Wua6dzXjsvet9fS+yTaOqmXf9h3jSMo1Yfq3FX0sr1s7YBToD0J3sfnrYx/g3ny MvYZX5mF88pZMdLIUHJr0RL7LcSwyraaAxNo7fRmpnbvj0qj+k48mJ2yWBNhPhMyUGGg fcw5rAVj58lOj9vz0twbzbMtSq2PoIFuoWLEZ8p6d0nbV9R/IDjfwZ6TXQK4kQg656KG Wb9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=ZWvq+jFdsnea//mUxKbLZNpeXJnmoS8lJOBYwQglqtU=; b=kzXzP8blNGrQGomfzbGi1v1hetyMYzjc/K3TTy4VTIPP9QJVf785Ka8JEU9u8XniNd giCP+Nn12kLa5lv4wdfG5NcGMgLJOqyfS5Mb760hqiIO8eQcq0lBG9q413Ff2GKsC2hf Vifgl0uh0ks+dp96KeheL5xkiANktk8nB63z3qKoU2pdoiA7MhaIoEUUJit9USi+EyuA agWwbtNH037pWwbl7R6h6WgIiXaAbl78CPpoUhj46RLdBLu53X5L0roxm6xclORWK/yU X+kVrFXFZA329+qvcC5F0Ep85rUOjCCjHP7lPGWFWqjrZr3HvYNz4iWS3DTQfdVqXH2c pNdw== X-Gm-Message-State: APjAAAXE/qWWeyX6OVm2n412NbLfseHrNJw1IW57E9e4+FunOgM2omfl OznovX0ikpmUDzI1oI+d5pRSKJRw X-Google-Smtp-Source: APXvYqw2YnIBTv/niMGmXYIFB9R1Foll+KOKDBc8yaJsvPCZA/7jpALoJOh5jMWp98h5xSPxhBprTg== X-Received: by 2002:a17:90a:a10f:: with SMTP id s15mr7116379pjp.40.1582939062263; Fri, 28 Feb 2020 17:17:42 -0800 (PST) Received: from [2601:640:102:57a9:400a:1e01:70:0] ([2601:640:102:57a9:3d6a:60c0:a092:3242]) by smtp.gmail.com with ESMTPSA id 199sm13281890pfv.81.2020.02.28.17.17.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 28 Feb 2020 17:17:41 -0800 (PST) Date: Fri, 28 Feb 2020 17:17:33 -0800 From: Jeff Tantsura To: draft-ietf-idr-bgp-ls-segment-routing-msd@ietf.org, Alvaro Retana Cc: Susan Hares , idr-chairs@ietf.org, "=?utf-8?Q?idr=40ietf._org?=" Message-ID: <66f54780-1ef3-4b1c-8e02-0680f9de38d7@Spark> In-Reply-To: References: X-Readdle-Message-ID: 66f54780-1ef3-4b1c-8e02-0680f9de38d7@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5e59bbb2_5f5e7fd0_ba8d" Archived-At: Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segment-routing-msd-09 X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 01:17:46 -0000 --5e59bbb2_5f5e7fd0_ba8d Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear Alvaro, Many thanks for your=C2=A0thorougful=C2=A0review=21 Please see inline Cheers, Jeff On =46eb 26, 2020, 2:19 PM -0800, Alvaro Retana , wrote: > Dear authors: > > This is my review of draft-ietf-idr-bgp-ls-segment-routing-msd-09. =C2=A0= I > have put some comments in-line below which should be easy to address. > > This document, like many other BGP-LS specifications to carry > IGP-derived information is written with that assumption: that the > information will come from the IGPs. =C2=A0However, =C2=A72 reads: > > =C2=A0 =C2=A0 The BGP-LS speaker may also advertise the MSD information= for the local > =C2=A0 =C2=A0 node and its links when not running any link-state IGP pr= otocol e.g. when > =C2=A0 =C2=A0 running BGP as the only routing protocol. > > This case (no IGP) is not fully explained in the text. =C2=A0Borrowing = from > the IGP R=46Cs, two clear pieces of information that are missing are: > > =C2=A0 =C2=A0(1) A definition of what the Node/Link MSDs are. =C2=A0I b= orrowed from rfc8476 > =C2=A0 =C2=A0and made suggestions for =C2=A73 and =C2=A74 of this docum= ent (in-line). > > =C2=A0 =C2=A0(2) =22Procedures for Defining and Using Node and Link MSD= Advertisements=22, > =C2=A0 =C2=A0similar to =C2=A74 (in both rfc8476/rfc8491). =C2=A0Sugges= tion: simply include the > =C2=A0 =C2=A0text from rfc8476 after =C2=A74 of this document. =5Bjeff=5DAck > > > The text in =C2=A72 is also not specific on how this local information > should be advertised using BGP-LS. =C2=A0Should the Direct Protocol > Identifier be used, or, because of =22running BGP as the only routing > protocol=22 should it be BGP=3F =C2=A0Please add details to the specifi= cation. =5Bjeff=5D Ack, it is BGP > > One more related point. =C2=A0The deployment model for collecting > IGP-derived information is that =22BGP-LS is configured on a small > number of nodes=22 =5Brfc8491=5D, but the model for advertising local > information is different. =C2=A0Please include some text about that too= . > > > I will wait for a revised document to primarily address this text from > =C2=A72 (and the in-line comments marked as =5Bmajor=5D) before startin= g the > IET=46 LC. > > Thanks=21 > > Alvaro. > > > > =5BLine numbers from idnits.=5D > > ... > 14 Signaling MSD (Maximum SID Depth) using Border Gateway Protocol Link= - > 15 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 State > > =5Bminor=5D s/Border Gateway Protocol Link-State/Border Gateway Protoco= l - > Link State/g > That is the form used in rfc7752 -- in the only place where BGP-LS is e= xpanded. =5Bjeff=5DAck > > > ... > 79 1. =C2=A0Introduction > > 81 =C2=A0 When Segment Routing (SR) =5BR=46C8402=5D paths are computed = by a > 82 =C2=A0 centralized controller, it is critical that the controller le= arns the > 83 =C2=A0 Maximum SID Depth (MSD) that can be imposed at each node/link= on a > 84 =C2=A0 given SR path. =C2=A0This ensures that the Segment Identifier= (SID) stack > 85 =C2=A0 depth of a computed path doesn't exceed the number of SIDs th= e node > 86 =C2=A0 is capable of imposing. > > =5Bnit=5D s/learns/learn =5Bjeff=5DAck > > > > ... > 93 =C2=A0 However, if PCEP is not supported/configured on the head-end = of a SR > 94 =C2=A0 tunnel or a Binding-SID anchor node, and controller does not > 95 =C2=A0 participate in IGP routing, it has no way of learning the MSD= of > 96 =C2=A0 nodes and links. =C2=A0BGP-LS =5BR=46C7752=5D defines a way t= o advertise > 97 =C2=A0 topology and associated attributes and capabilities of the no= des in > 98 =C2=A0 that topology to a centralized controller. =C2=A0This documen= t defines > 99 =C2=A0 extensions to BGP-LS to advertise one or more types of MSDs a= t node > 100 =C2=A0 and/or link granularity. > > =5Bnit=5D s/to advertise/to expose > =46or consistency with the OSP=46/ISIS documents. > > > =5Bminor=5D Including the last sentence above makes the text not flow > well: it first says that extensions =22to advertise one or more types o= f > MSDs=22 are defined here...and then it talks about other types of MSDs.= > Suggestion: =C2=A0Move that sentence to be the first one in the last > paragraph. =5Bjeff=5DAck > > > > 102 =C2=A0 Other types of MSD are known to be useful. =C2=A0=46or examp= le, > 103 =C2=A0 =5BI-D.ietf-ospf-mpls-elc=5D and =5BI-D.ietf-isis-mpls-elc=5D= define Readable > 104 =C2=A0 Label Depth Capability (RLDC) that is used by a head-end to = insert an > 105 =C2=A0 Entropy Label (EL) at a depth that can be read by transit no= des --5e59bbb2_5f5e7fd0_ba8d Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Dear Alvaro,

Many thanks for your&=23160;thorougful&=23160;revie= w=21
Please see inline

Cheers,
Jeff
On =46eb 26, 2020, 2:19 PM -0800, A= lvaro Retana <aretana.ietf=40gmail.com>, wrote:
De= ar authors:

This is my review of draft-ietf-idr-bgp-ls-segment-routing-msd-09. &=2316= 0;I
have put some comments in-line below which should be easy to address.

This document, like many other BGP-LS specifications to carry
IGP-derived information is written with that assumption: that the
information will come from the IGPs. &=23160;However, =C2=A72 reads:

&=23160; &=23160; The BGP-LS speaker may also advertise the MSD informati= on for the local
&=23160; &=23160; node and its links when not running any link-state IGP = protocol e.g. when
&=23160; &=23160; running BGP as the only routing protocol.

This case (no IGP) is not fully explained in the text. &=23160;Borrowing = from
the IGP R=46Cs, two clear pieces of information that are missing are:

&=23160; &=23160;(1) A definition of what the Node/Link MSDs are. &=23160= ;I borrowed from rfc8476
&=23160; &=23160;and made suggestions for =C2=A73 and =C2=A74 of this doc= ument (in-line).

&=23160; &=23160;(2) =22Procedures for Defining and Using Node and Link M= SD Advertisements=22,
&=23160; &=23160;similar to =C2=A74 (in both rfc8476/rfc8491). &=23160;Su= ggestion: simply include the
&=23160; &=23160;text from rfc8476 after =C2=A74 of this document.&=23160= ;
=5Bjeff=5DAck

The text in =C2=A72 is also not specific on how this local information should be advertised using BGP-LS. &=23160;Should the Direct Protocol
Identifier be used, or, because of =22running BGP as the only routing
protocol=22 should it be BGP=3F &=23160;Please add details to the specifi= cation.&=23160;
=5Bjeff=5D Ack, it is BGP
One more related point. &=23160;The deployment model for collecting
= IGP-derived information is that =22BGP-LS is configured on a small
number of nodes=22 =5Brfc8491=5D, but the model for advertising local
information is different. &=23160;Please include some text about that too= .


I will wait for a revised document to primarily address this text from =C2=A72 (and the in-line comments marked as =5Bmajor=5D) before starting = the
IET=46 LC.

Thanks=21

Alvaro.



=5BLine numbers from idnits.=5D

...
14 Signaling MSD (Maximum SID Depth) using Border Gateway Protocol Link-<= br /> 15 &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160= ; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160; &=23160;= State

=5Bminor=5D s/Border Gateway Protocol Link-State/Border Gateway Protocol = -
Link State/g
That is the form used in rfc7752 -- in the only place where BGP-LS is exp= anded.&=23160;
=5Bjeff=5DAck

...
79 1. &=23160;Introduction

81 &=23160; When Segment Routing (SR) =5BR=46C8402=5D paths are computed = by a
82 &=23160; centralized controller, it is critical that the controller le= arns the
83 &=23160; Maximum SID Depth (MSD) that can be imposed at each node/link= on a
84 &=23160; given SR path. &=23160;This ensures that the Segment Identifi= er (SID) stack
85 &=23160; depth of a computed path doesn't exceed the number of SIDs th= e node
86 &=23160; is capable of imposing.

=5Bnit=5D s/learns/learn&=23160;
=5Bjeff=5DAck


...
93 &=23160; However, if PCEP is not supported/configured on the head-end = of a SR
94 &=23160; tunnel or a Binding-SID anchor node, and controller does not<= br /> 95 &=23160; participate in IGP routing, it has no way of learning the MSD= of
96 &=23160; nodes and links. &=23160;BGP-LS =5BR=46C7752=5D defines a way= to advertise
97 &=23160; topology and associated attributes and capabilities of the no= des in
98 &=23160; that topology to a centralized controller. &=23160;This docum= ent defines
99 &=23160; extensions to BGP-LS to advertise one or more types of MSDs a= t node
100 &=23160; and/or link granularity.

=5Bnit=5D s/to advertise/to expose
=46or consistency with the OSP=46/ISIS documents.


=5Bminor=5D Including the last sentence above makes the text not flow
well: it first says that extensions =22to advertise one or more types of<= br /> MSDs=22 are defined here...and then it talks about other types of MSDs. Suggestion: &=23160;Move that sentence to be the first one in the last paragraph.&=23160;
=5Bjeff=5DAck


102 &=23160; Other types of MSD are known to be useful. &=23160;=46or exa= mple,
103 &=23160; =5BI-D.ietf-ospf-mpls-elc=5D and =5BI-D.ietf-isis-mpls-elc=5D= define Readable
104 &=23160; Label Depth Capability (RLDC) that is used by a head-end to = insert an
105 &=23160; Entropy Label (EL) at a depth that can be read by transit no= des
--5e59bbb2_5f5e7fd0_ba8d-- From nobody Fri Feb 28 17:18:13 2020 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 398353A08AF; Fri, 28 Feb 2020 17:18:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <158293908514.19879.15916583835928213600@ietfa.amsl.com> Date: Fri, 28 Feb 2020 17:18:05 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-msd-10.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 01:18:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Signaling MSD (Maximum SID Depth) using Border Gateway Protocol - Link State Authors : Jeff Tantsura Uma Chunduri Ketan Talaulikar Greg Mirsky Nikos Triantafillis Filename : draft-ietf-idr-bgp-ls-segment-routing-msd-10.txt Pages : 11 Date : 2020-02-28 Abstract: This document defines a way for a Border Gateway Protocol - Link State (BGP-LS) speaker to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-10 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-msd-10 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-segment-routing-msd-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 28 17:32:02 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5223A0895; Fri, 28 Feb 2020 17:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 zzmkmmZ6JPNX; Fri, 28 Feb 2020 17:31:59 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 06A363A089B; Fri, 28 Feb 2020 17:31:59 -0800 (PST) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 240435D0CAE8DBA0F99F; Sat, 29 Feb 2020 01:31:56 +0000 (GMT) Received: from nkgeml703-chm.china.huawei.com (10.98.57.159) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sat, 29 Feb 2020 01:31:55 +0000 Received: from nkgeml701-chm.china.huawei.com (10.98.57.156) by nkgeml703-chm.china.huawei.com (10.98.57.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Sat, 29 Feb 2020 09:31:53 +0800 Received: from nkgeml701-chm.china.huawei.com ([10.98.57.156]) by nkgeml701-chm.china.huawei.com ([10.98.57.156]) with mapi id 15.01.1713.004; Sat, 29 Feb 2020 09:31:53 +0800 From: "Dongjie (Jimmy)" To: "idr@ietf.org" CC: "idr-chairs@ietf.org" Thread-Topic: Call for IETF107 IDR agenda items Thread-Index: AdXunrcdMKoa4WeRSgShAXufYV34nw== Date: Sat, 29 Feb 2020 01:31:53 +0000 Message-ID: <0b3895973fff4bcc8ec5afdda49e4653@huawei.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.108.203.211] Content-Type: multipart/alternative; boundary="_000_0b3895973fff4bcc8ec5afdda49e4653huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Idr] Call for IETF107 IDR agenda items X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 01:32:01 -0000 --_000_0b3895973fff4bcc8ec5afdda49e4653huaweicom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, The final agenda of IETF 107 is available at https://datatracker.ietf.org/m= eeting/107/agenda.html. IDR has two sessions: Session 1: Monday, 23 March 2020, Morning Session I 1000-1200 Room Name: Regency F Session 2: Tuesday, 24 March 2020, Afternoon Session II 1550-1720 Room Name: Regency D Please start to send any IDR agenda item request to me and CC the chairs. P= lease include the name of the person who will be presenting, and the estima= te time you'll need (including Q/A). You may also indicate which session yo= u would prefer. If you plan to make a presentation, please keep in mind the IDR tradition, = "no Internet Draft - no time slot". You should also plan to send your slide= s to me and CC the chairs no later than 24 hours prior to the IDR meeting, = though earlier is better. Please number your slides for the benefit of remo= te attendees. By default your slides will be converted to PDF and presented= from the PDF. If you do need to use any fancy builds or transitions, pleas= e make sure to arrange this with us in advance to avoid any surprise. Thank= s. And potential presenters, please take a look at the checklist for presentin= g at IDR: https://trac.tools.ietf.org/wg/idr/trac/wiki/Checklist%20for%20presenting%2= 0at%20an%20IDR%20meeting Best regards, Jie --_000_0b3895973fff4bcc8ec5afdda49e4653huaweicom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

The final agenda of IETF 107 is= available at https://da= tatracker.ietf.org/meeting/107/agenda.html. IDR has two sessions:<= /o:p>

 

Session 1: Monday, 23 March 202= 0, Morning Session I 1000-1200

Room Name: Regency F

 

Session 2: Tuesday, 24 March 20= 20, Afternoon Session II 1550-1720

Room Name: Regency D

 

Please start to send any IDR ag= enda item request to me and CC the chairs. Please include the name of the p= erson who will be presenting, and the estimate time you'll need (including = Q/A). You may also indicate which session you would prefer.

 

If you plan to make a presentat= ion, please keep in mind the IDR tradition, "no Internet Draft - no ti= me slot". You should also plan to send your slides to me and CC the ch= airs no later than 24 hours prior to the IDR meeting, though earlier is better. Please number your slides for the benefit of rem= ote attendees. By default your slides will be converted to PDF and presente= d from the PDF. If you do need to use any fancy builds or transitions, plea= se make sure to arrange this with us in advance to avoid any surprise. Thanks.

 

And potential presenters, pleas= e take a look at the checklist for presenting at IDR:

https://trac.tools.ietf.org/wg/idr/trac/wiki/Checklist%20for%20presen= ting%20at%20an%20IDR%20meeting

 

 

Best regards,=

Jie

--_000_0b3895973fff4bcc8ec5afdda49e4653huaweicom_-- From nobody Fri Feb 28 17:57:36 2020 Return-Path: X-Original-To: idr@ietf.org Delivered-To: idr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A68C3A0945; Fri, 28 Feb 2020 17:57:28 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: idr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.119.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: idr@ietf.org Message-ID: <158294144810.19814.8920744605389350723@ietfa.amsl.com> Date: Fri, 28 Feb 2020 17:57:28 -0800 Archived-At: Subject: [Idr] I-D Action: draft-ietf-idr-bgp-ls-segment-routing-msd-11.txt X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 01:57:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing WG of the IETF. Title : Signaling MSD (Maximum SID Depth) using Border Gateway Protocol - Link State Authors : Jeff Tantsura Uma Chunduri Ketan Talaulikar Greg Mirsky Nikos Triantafillis Filename : draft-ietf-idr-bgp-ls-segment-routing-msd-11.txt Pages : 11 Date : 2020-02-28 Abstract: This document defines a way for a Border Gateway Protocol - Link State (BGP-LS) speaker to advertise multiple types of supported Maximum SID Depths (MSDs) at node and/or link granularity. Such advertisements allow entities (e.g., centralized controllers) to determine whether a particular Segment Identifier (SID) stack can be supported in a given network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-ls-segment-routing-msd/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-idr-bgp-ls-segment-routing-msd-11 https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-msd-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-ls-segment-routing-msd-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Feb 29 08:15:52 2020 Return-Path: X-Original-To: idr@ietfa.amsl.com Delivered-To: idr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59FB3A0DAF for ; Sat, 29 Feb 2020 08:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jNGSYTGM7Nfe for ; Sat, 29 Feb 2020 08:15:48 -0800 (PST) Received: from mail.hated.at (mail.hated.at [IPv6:2001:858:2:8::235]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B163A0DB2 for ; Sat, 29 Feb 2020 08:15:47 -0800 (PST) Received: from 80-110-104-164.cgn.dynamic.surfer.at ([80.110.104.164] helo=[192.168.66.207]) by mail.hated.at with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1j84mF-0002U6-1f; Sat, 29 Feb 2020 17:15:43 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.60.0.2.5\)) From: Christoph Loibl In-Reply-To: <014e01d5ee13$07aac8c0$17005a40$@ndzh.com> Date: Sat, 29 Feb 2020 17:15:40 +0100 Cc: "idr@ietf. org" Content-Transfer-Encoding: quoted-printable Message-Id: <81C2F530-790F-4819-93CB-91C93190F91C@tix.at> References: <014e01d5ee13$07aac8c0$17005a40$@ndzh.com> To: Susan Hares X-Mailer: Apple Mail (2.3608.60.0.2.5) Archived-At: Subject: Re: [Idr] draft-ietf-idr-flow-spec-v6-10 - IPR call prior to WG Last call X-BeenThere: idr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Inter-Domain Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Feb 2020 16:15:50 -0000 I am not aware of any IPR related to content of = draft-ietf-idr-flowspec-v6.=20 Cheers Christoph --=20 Christoph Loibl c@tix.at | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at > On 28.02.2020, at 09:42, Susan Hares wrote: >=20 > Greetings:=20 > =20 > This begins an IPR poll prior to a WG last call for = draft-ietf-idr-flowspec-v6-10.txt. All Authors should respond to the = IPR call.=20 > =20 > Cheerily, Susan Hares=20 > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr