From nobody Wed Jan 2 09:15:45 2019 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4004312870E for ; Wed, 2 Jan 2019 09:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 i3Ca9iZSOdHN for ; Wed, 2 Jan 2019 09:15:42 -0800 (PST) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C68E8130EAF for ; Wed, 2 Jan 2019 09:15:41 -0800 (PST) Received: by mail-wm1-x330.google.com with SMTP id f81so28145217wmd.4 for ; Wed, 02 Jan 2019 09:15:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=wxZRTGBqdIUiEJk0kXIUg+gweqyClL6blU0TWE/24BQ=; b=mhYu8k/HOOUGDPGvGh1CgaT3STdxGJXcvOrEiFWvlxgLxCuHTV+XANOE7jpb3yYy1G QhmZXi8y1XU2QZ3aGy/zxVTCNt6VEaaJOgdjeK3woSx05PvKvPDkI5a9lFud2Vie52UX D/HPuCsdjeBCgUzhGWEKuGduSqCAMvoJZd07hH7ivNT05hPpg7zjHQ781zGktDRK06p2 A/qMTA9/eLzHEUvEntcWoNGwh6qRLAJL7LQ+UaHfygl6glnR9oHNCaRmXeeTktKIS2s0 6rtigLlvPftUfqwaLaU/gEKOMcVGzhWYnovOI0jewATm8QuW5JjMGi1xxtN/fjMyCaSb 6XSw== 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=wxZRTGBqdIUiEJk0kXIUg+gweqyClL6blU0TWE/24BQ=; b=VuRo2qPA2hiTjJBmPxYsfiqkNOP49oaGCnNhmTsoVCLxnpgw3Q+yBPL4aaJVi3ourE z1WZYc/VvzfpOPHCa7MDMSeGW4olIadaKW5A6CW85+hUTZ/1nJn19IBFtXfbr3xjV5Tj kl8s4wiwFg4wDSe6AtX8MraNnSZHLKnnWmiEmzDbNReiQ0GMv+8wCMGspWDBlID9kX+z eav67XQcSpcwKfH1ktwmsab/q0RL/ldU7GFSd6c0JB0DRKadev9VRj/Dl/e/64ytgfVB 71R4ztBzxY85RPc95kk5tEjD+esNW8zbTeYFcYE6zJ6refXWgmkVJiu6OhV2tsguRL9G t2wQ== X-Gm-Message-State: AJcUukdCvFd+QEzVjX2on7Yyf+HLk9zpq/7YkBh/0+r87tEqa752yb+K XujCE6MbcBAbaMCSZDnNQ2ZA8rf9BlV9uia6meSi+vTaJI8= X-Google-Smtp-Source: AFSGD/XHYl4PbMkl0tDVY1tDU9vuNx9eaQAvLy+o79CSEse5KjVa3FTA4UrxECIWiB0Da2w9XHAfl6NP9+nUzFgzYAw= X-Received: by 2002:a1c:ab87:: with SMTP id u129mr35988009wme.104.1546449339562; Wed, 02 Jan 2019 09:15:39 -0800 (PST) MIME-Version: 1.0 References: <154629107904.14697.13696704134446734906@ietfa.amsl.com> In-Reply-To: <154629107904.14697.13696704134446734906@ietfa.amsl.com> From: Rob Shakir Date: Wed, 2 Jan 2019 09:15:27 -0800 Message-ID: To: spring@ietf.org, draft-ietf-spring-sr-yang.all@ietf.org Content-Type: multipart/alternative; boundary="0000000000008cc59f057e7ccb32" Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-sr-yang-10.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2019 17:15:44 -0000 --0000000000008cc59f057e7ccb32 Content-Type: text/plain; charset="UTF-8" Authors, WG, One of the items that we discussed during the meeting in Bangkok was whether this draft is now ready to be progressed. We have a YANG doctor's early review from Lada: https://mailarchive.ietf.org/arch/msg/spring/OKqkt3-Fe33vJxVYpBO7tEaOoRs Is there anything else that the WG should be aware of before reviewing this document again? Are there outstanding items to be addressed? Thanks, r. On Mon, Dec 31, 2018 at 1:18 PM wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Source Packet Routing in Networking WG of > the IETF. > > Title : YANG Data Model for Segment Routing > Authors : Stephane Litkowski > Yingzhen Qu > Pushpasis Sarkar > Jeff Tantsura > Acee Lindem > Filename : draft-ietf-spring-sr-yang-10.txt > Pages : 30 > Date : 2018-12-31 > > Abstract: > This document defines a YANG data model ([RFC6020], [RFC7950]) for > segment routing ([I-D.ietf-spring-segment-routing]) configuration and > operation. This YANG model is intended to be used on network > elements to configure or operate segment routing. This document > defines also generic containers that SHOULD be reused by IGP protocol > modules to support segment routing. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-spring-sr-yang-10 > https://datatracker.ietf.org/doc/html/draft-ietf-spring-sr-yang-10 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-sr-yang-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/ > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --0000000000008cc59f057e7ccb32 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Authors, WG,

One of the items that we d= iscussed during the meeting in Bangkok was whether this draft is now ready = to be progressed.

We have a YANG doctor&= #39;s early review from Lada:=C2=A0https://mailarchive.ietf.org/a= rch/msg/spring/OKqkt3-Fe33vJxVYpBO7tEaOoRs

Is = there anything else that the WG should be aware of before reviewing this do= cument again? Are there outstanding items to be addressed?
=C2=A0=
Thanks,
r.


On Mon, Dec 31, 2018 at 1:18 PM <internet-drafts@ietf.org> wrote:

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

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= YANG Data Model for Segment Routing
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Step= hane Litkowski
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Yingzhen Qu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Pushpasis Sarkar
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Jeff Tantsura
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Acee Lindem
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-spring-sr-yang-10.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 30
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2018-12-31

Abstract:
=C2=A0 =C2=A0This document defines a YANG data model ([RFC6020], [RFC7950])= for
=C2=A0 =C2=A0segment routing ([I-D.ietf-spring-segment-routing]) configurat= ion and
=C2=A0 =C2=A0operation.=C2=A0 This YANG model is intended to be used on net= work
=C2=A0 =C2=A0elements to configure or operate segment routing.=C2=A0 This d= ocument
=C2=A0 =C2=A0defines also generic containers that SHOULD be reused by IGP p= rotocol
=C2=A0 =C2=A0modules to support segment routing.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ie= tf-spring-sr-yang/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sprin= g-sr-yang-10
https://datatracker.ietf.org/doc/h= tml/draft-ietf-spring-sr-yang-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3D= draft-ietf-spring-sr-yang-10


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/

_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--0000000000008cc59f057e7ccb32-- From nobody Wed Jan 2 17:53:19 2019 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF45A128CF3; Wed, 2 Jan 2019 17:53:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 UXdwFoXJN_69; Wed, 2 Jan 2019 17:53:15 -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 63E75124BE5; Wed, 2 Jan 2019 17:53:15 -0800 (PST) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id E43FA4DC1009F; Thu, 3 Jan 2019 01:53:08 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 3 Jan 2019 01:53:10 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.179]) by SJCEML702-CHM.china.huawei.com ([169.254.4.203]) with mapi id 14.03.0415.000; Wed, 2 Jan 2019 17:53:02 -0800 From: Yingzhen Qu To: Rob Shakir , "spring@ietf.org" , "draft-ietf-spring-sr-yang.all@ietf.org" Thread-Topic: [spring] I-D Action: draft-ietf-spring-sr-yang-10.txt Thread-Index: AQHUoU54UjydDpbonk2xafyQp1T1HKWcwQGAgAAKcgA= Date: Thu, 3 Jan 2019 01:53:02 +0000 Message-ID: <20CE6179-6024-44CD-A209-5E38F4F2C815@huawei.com> References: <154629107904.14697.13696704134446734906@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.134] Content-Type: multipart/alternative; boundary="_000_20CE6179602444CDA2095E38F4F2C815huaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] I-D Action: draft-ietf-spring-sr-yang-10.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 01:53:18 -0000 --_000_20CE6179602444CDA2095E38F4F2C815huaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoaXMgdmVyc2lvbiB3YXMgc3VibWl0dGVkIGJlY2F1c2UgdGhlIG9sZCBvbmUgd2Fz IGV4cGlyZWQuIFRoZSBhdXRob3JzIGFyZSB3b3JraW5nIG9uIGFkZHJlc3NpbmcgdGhlIHJldmll dyBjb21tZW50cywgYW5kIGEgbmV3IHZlcnNpb24gc2hvdWxkIGJlIHBvc3RlZCBzb29uLg0KDQpU aGFua3MsDQpZaW5nemhlbg0KDQpGcm9tOiBSb2IgU2hha2lyIDxyb2Jqc0Bnb29nbGUuY29tPg0K RGF0ZTogV2VkbmVzZGF5LCBKYW51YXJ5IDIsIDIwMTkgYXQgOToxNiBBTQ0KVG86ICJzcHJpbmdA aWV0Zi5vcmciIDxzcHJpbmdAaWV0Zi5vcmc+LCAiZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFuZy5h bGxAaWV0Zi5vcmciIDxkcmFmdC1pZXRmLXNwcmluZy1zci15YW5nLmFsbEBpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBbc3ByaW5nXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLXNwcmluZy1zci15YW5n LTEwLnR4dA0KUmVzZW50LUZyb206IDxhbGlhcy1ib3VuY2VzQGlldGYub3JnPg0KUmVzZW50LVRv OiA8c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+LCA8eWluZ3poZW4ucXVAaHVhd2VpLmNv bT4sIDxwdXNocGFzaXMuaWV0ZkBnbWFpbC5jb20+LCA8amVmZnRhbnQuaWV0ZkBnbWFpbC5jb20+ LCA8YWNlZUBjaXNjby5jb20+LCA8cm9ianNAZ29vZ2xlLmNvbT4sIDxicnVuby5kZWNyYWVuZUBv cmFuZ2UuY29tPiwgPG1hcnRpbi52aWdvdXJldXhAbm9raWEuY29tPiwgPGRiMzU0NkBhdHQuY29t PiwgPGFyZXRhbmEuaWV0ZkBnbWFpbC5jb20+LCBSb2IgU2hha2lyIDxyb2Jqc0Bnb29nbGUuY29t Pg0KUmVzZW50LURhdGU6IFdlZG5lc2RheSwgSmFudWFyeSAyLCAyMDE5IGF0IDk6MTUgQU0NCg0K QXV0aG9ycywgV0csDQoNCk9uZSBvZiB0aGUgaXRlbXMgdGhhdCB3ZSBkaXNjdXNzZWQgZHVyaW5n IHRoZSBtZWV0aW5nIGluIEJhbmdrb2sgd2FzIHdoZXRoZXIgdGhpcyBkcmFmdCBpcyBub3cgcmVh ZHkgdG8gYmUgcHJvZ3Jlc3NlZC4NCg0KV2UgaGF2ZSBhIFlBTkcgZG9jdG9yJ3MgZWFybHkgcmV2 aWV3IGZyb20gTGFkYTogaHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9zcHJp bmcvT0txa3QzLUZlMzN2SnhWWXBCTzd0RWFPb1JzDQoNCklzIHRoZXJlIGFueXRoaW5nIGVsc2Ug dGhhdCB0aGUgV0cgc2hvdWxkIGJlIGF3YXJlIG9mIGJlZm9yZSByZXZpZXdpbmcgdGhpcyBkb2N1 bWVudCBhZ2Fpbj8gQXJlIHRoZXJlIG91dHN0YW5kaW5nIGl0ZW1zIHRvIGJlIGFkZHJlc3NlZD8N Cg0KVGhhbmtzLA0Kci4NCg0KDQpPbiBNb24sIERlYyAzMSwgMjAxOCBhdCAxOjE4IFBNIDxpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc8bWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4+IHdy b3RlOg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGlu ZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuDQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVt IG9mIHRoZSBTb3VyY2UgUGFja2V0IFJvdXRpbmcgaW4gTmV0d29ya2luZyBXRyBvZiB0aGUgSUVU Ri4NCg0KICAgICAgICBUaXRsZSAgICAgICAgICAgOiBZQU5HIERhdGEgTW9kZWwgZm9yIFNlZ21l bnQgUm91dGluZw0KICAgICAgICBBdXRob3JzICAgICAgICAgOiBTdGVwaGFuZSBMaXRrb3dza2kN CiAgICAgICAgICAgICAgICAgICAgICAgICAgWWluZ3poZW4gUXUNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgUHVzaHBhc2lzIFNhcmthcg0KICAgICAgICAgICAgICAgICAgICAgICAgICBKZWZm IFRhbnRzdXJhDQogICAgICAgICAgICAgICAgICAgICAgICAgIEFjZWUgTGluZGVtDQogICAgICAg IEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtc3ByaW5nLXNyLXlhbmctMTAudHh0DQogICAg ICAgIFBhZ2VzICAgICAgICAgICA6IDMwDQogICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTgt MTItMzENCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMgYSBZQU5HIGRhdGEg bW9kZWwgKFtSRkM2MDIwXSwgW1JGQzc5NTBdKSBmb3INCiAgIHNlZ21lbnQgcm91dGluZyAoW0kt RC5pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmddKSBjb25maWd1cmF0aW9uIGFuZA0KICAgb3Bl cmF0aW9uLiAgVGhpcyBZQU5HIG1vZGVsIGlzIGludGVuZGVkIHRvIGJlIHVzZWQgb24gbmV0d29y aw0KICAgZWxlbWVudHMgdG8gY29uZmlndXJlIG9yIG9wZXJhdGUgc2VnbWVudCByb3V0aW5nLiAg VGhpcyBkb2N1bWVudA0KICAgZGVmaW5lcyBhbHNvIGdlbmVyaWMgY29udGFpbmVycyB0aGF0IFNI T1VMRCBiZSByZXVzZWQgYnkgSUdQIHByb3RvY29sDQogICBtb2R1bGVzIHRvIHN1cHBvcnQgc2Vn bWVudCByb3V0aW5nLg0KDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9y IHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1p ZXRmLXNwcmluZy1zci15YW5nLw0KDQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2ZXJzaW9ucyBh dmFpbGFibGUgYXQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJp bmctc3IteWFuZy0xMA0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFm dC1pZXRmLXNwcmluZy1zci15YW5nLTEwDQoNCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJz aW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1k cmFmdC1pZXRmLXNwcmluZy1zci15YW5nLTEwDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50 aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5p ZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+Lg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFs c28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzLw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJp bmdAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nwcmlu Zw0K --_000_20CE6179602444CDA2095E38F4F2C815huaweicom_ Content-Type: text/html; charset="utf-8" Content-ID: <3EBB2F3C8AB7304BB0CD5CEFBC1ADC33@huawei.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6 MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBT dHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05v cm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bh bi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJ dGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5r Rm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2 Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGlzIHZlcnNpb24gd2FzIHN1Ym1pdHRlZCBiZWNhdXNlIHRoZSBvbGQgb25l IHdhcyBleHBpcmVkLiBUaGUgYXV0aG9ycyBhcmUgd29ya2luZyBvbiBhZGRyZXNzaW5nIHRoZSBy ZXZpZXcgY29tbWVudHMsIGFuZCBhIG5ldyB2ZXJzaW9uIHNob3VsZCBiZSBwb3N0ZWQgc29vbi48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+WWluZ3poZW48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPkZyb206IDwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPlJvYiBTaGFraXIgJmx0O3JvYmpzQGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTog PC9iPldlZG5lc2RheSwgSmFudWFyeSAyLCAyMDE5IGF0IDk6MTYgQU08YnI+DQo8Yj5UbzogPC9i PiZxdW90O3NwcmluZ0BpZXRmLm9yZyZxdW90OyAmbHQ7c3ByaW5nQGlldGYub3JnJmd0OywgJnF1 b3Q7ZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFuZy5hbGxAaWV0Zi5vcmcmcXVvdDsgJmx0O2RyYWZ0 LWlldGYtc3ByaW5nLXNyLXlhbmcuYWxsQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwv Yj5SZTogW3NwcmluZ10gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFuZy0xMC50 eHQ8YnI+DQo8Yj5SZXNlbnQtRnJvbTogPC9iPiZsdDthbGlhcy1ib3VuY2VzQGlldGYub3JnJmd0 Ozxicj4NCjxiPlJlc2VudC1UbzogPC9iPiZsdDtzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNv bSZndDssICZsdDt5aW5nemhlbi5xdUBodWF3ZWkuY29tJmd0OywgJmx0O3B1c2hwYXNpcy5pZXRm QGdtYWlsLmNvbSZndDssICZsdDtqZWZmdGFudC5pZXRmQGdtYWlsLmNvbSZndDssICZsdDthY2Vl QGNpc2NvLmNvbSZndDssICZsdDtyb2Jqc0Bnb29nbGUuY29tJmd0OywgJmx0O2JydW5vLmRlY3Jh ZW5lQG9yYW5nZS5jb20mZ3Q7LCAmbHQ7bWFydGluLnZpZ291cmV1eEBub2tpYS5jb20mZ3Q7LCAm bHQ7ZGIzNTQ2QGF0dC5jb20mZ3Q7LCAmbHQ7YXJldGFuYS5pZXRmQGdtYWlsLmNvbSZndDssDQog Um9iIFNoYWtpciAmbHQ7cm9ianNAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5SZXNlbnQtRGF0ZTog PC9iPldlZG5lc2RheSwgSmFudWFyeSAyLCAyMDE5IGF0IDk6MTUgQU08bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkF1dGhvcnMsIFdH LCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBvZiB0 aGUgaXRlbXMgdGhhdCB3ZSBkaXNjdXNzZWQgZHVyaW5nIHRoZSBtZWV0aW5nIGluIEJhbmdrb2sg d2FzIHdoZXRoZXIgdGhpcyBkcmFmdCBpcyBub3cgcmVhZHkgdG8gYmUgcHJvZ3Jlc3NlZC48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5XZSBoYXZlIGEgWUFORyBkb2N0b3IncyBlYXJseSByZXZpZXcgZnJvbSBMYWRhOiZu YnNwOzxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvc3ByaW5n L09LcWt0My1GZTMzdkp4VllwQk83dEVhT29ScyI+aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9y Zy9hcmNoL21zZy9zcHJpbmcvT0txa3QzLUZlMzN2SnhWWXBCTzd0RWFPb1JzPC9hPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JcyB0aGVyZSBh bnl0aGluZyBlbHNlIHRoYXQgdGhlIFdHIHNob3VsZCBiZSBhd2FyZSBvZiBiZWZvcmUgcmV2aWV3 aW5nIHRoaXMgZG9jdW1lbnQgYWdhaW4/IEFyZSB0aGVyZSBvdXRzdGFuZGluZyBpdGVtcyB0byBi ZSBhZGRyZXNzZWQ/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPnIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIE1vbiwgRGVjIDMxLCAyMDE4IGF0IDE6MTggUE0gJmx0OzxhIGhyZWY9Im1haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmciPmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzwvYT4m Z3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGJyPg0KQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20g dGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxicj4NClRoaXMgZHJhZnQg aXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFNvdXJjZSBQYWNrZXQgUm91dGluZyBpbiBOZXR3b3JraW5n IFdHIG9mIHRoZSBJRVRGLjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBU aXRsZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBZQU5HIERhdGEg TW9kZWwgZm9yIFNlZ21lbnQgUm91dGluZzxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBBdXRob3JzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogU3RlcGhhbmUgTGl0 a293c2tpPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFlpbmd6aGVuIFF1 PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFB1c2hwYXNpcyBTYXJrYXI8 YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSmVmZiBUYW50c3VyYTxicj4N CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBBY2VlIExpbmRlbTxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWxlbmFtZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyA6IGRyYWZ0LWlldGYtc3ByaW5nLXNyLXlhbmctMTAudHh0PGJyPg0KJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7IFBhZ2VzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs6IDMwPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IERhdGUmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6IDIwMTgtMTItMzE8YnI+DQo8YnI+DQpBYnN0 cmFjdDo8YnI+DQombmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCBkZWZpbmVzIGEgWUFORyBkYXRh IG1vZGVsIChbUkZDNjAyMF0sIFtSRkM3OTUwXSkgZm9yPGJyPg0KJm5ic3A7ICZuYnNwO3NlZ21l bnQgcm91dGluZyAoW0ktRC5pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmddKSBjb25maWd1cmF0 aW9uIGFuZDxicj4NCiZuYnNwOyAmbmJzcDtvcGVyYXRpb24uJm5ic3A7IFRoaXMgWUFORyBtb2Rl bCBpcyBpbnRlbmRlZCB0byBiZSB1c2VkIG9uIG5ldHdvcms8YnI+DQombmJzcDsgJm5ic3A7ZWxl bWVudHMgdG8gY29uZmlndXJlIG9yIG9wZXJhdGUgc2VnbWVudCByb3V0aW5nLiZuYnNwOyBUaGlz IGRvY3VtZW50PGJyPg0KJm5ic3A7ICZuYnNwO2RlZmluZXMgYWxzbyBnZW5lcmljIGNvbnRhaW5l cnMgdGhhdCBTSE9VTEQgYmUgcmV1c2VkIGJ5IElHUCBwcm90b2NvbDxicj4NCiZuYnNwOyAmbmJz cDttb2R1bGVzIHRvIHN1cHBvcnQgc2VnbWVudCByb3V0aW5nLjxicj4NCjxicj4NCjxicj4NCjxi cj4NClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYt c3ByaW5nLXNyLXlhbmcvIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFuZy88L2E+PGJyPg0KPGJyPg0KVGhlcmUg YXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0Ojxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zci15YW5nLTEwIiB0 YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtc3By aW5nLXNyLXlhbmctMTA8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zci15YW5nLTEwIiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRmLXNwcmlu Zy1zci15YW5nLTEwPC9hPjxicj4NCjxicj4NCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJz aW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9y ZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFuZy0xMCIgdGFyZ2V0PSJfYmxhbmsi Pmh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXNwcmluZy1zci15 YW5nLTEwPC9hPjxicj4NCjxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2Ug YSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb248YnI+DQp1bnRp bCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IDxhIGhyZWY9 Imh0dHA6Ly90b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9vbHMuaWV0Zi5vcmc8 L2E+Ljxicj4NCjxicj4NCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5v bnltb3VzIEZUUCBhdDo8YnI+DQo8YSBocmVmPSJmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzLyIgdGFyZ2V0PSJfYmxhbmsiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0Kc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpz cHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0K PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmciIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nwcmlu ZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_20CE6179602444CDA2095E38F4F2C815huaweicom_-- From nobody Thu Jan 3 00:17:01 2019 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88F04131107; Thu, 3 Jan 2019 00:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 BbMLCW7a73up; Thu, 3 Jan 2019 00:16:56 -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 6247B13110A; Thu, 3 Jan 2019 00:16:56 -0800 (PST) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 78FAABDCDD9DE; Thu, 3 Jan 2019 08:16:52 +0000 (GMT) Received: from DGGEML421-HUB.china.huawei.com (10.1.199.38) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 3 Jan 2019 08:16:53 +0000 Received: from DGGEML529-MBX.china.huawei.com ([169.254.6.240]) by dggeml421-hub.china.huawei.com ([10.1.199.38]) with mapi id 14.03.0415.000; Thu, 3 Jan 2019 16:16:42 +0800 From: "Chengli (Cheng Li)" To: Robert Raszuk , "idr@ietf. org" CC: SPRING WG , Dhruv Dhody , Huzhibo Thread-Topic: [spring] I-D Action: draft-li-idr-sr-policy-path-mtu-01.txt Thread-Index: AQHUnc9rAcKQVM15Fkas8VSbEsXN4KWdJNiQ Date: Thu, 3 Jan 2019 08:16:42 +0000 Message-ID: References: <154589870038.11942.973291084312471941@ietfa.amsl.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.130.185.75] Content-Type: multipart/alternative; boundary="_000_C7C2E1C43D652C4E9E49FE7517C236CB01AAD054dggeml529mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [spring] I-D Action: draft-li-idr-sr-policy-path-mtu-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 08:17:00 -0000 --_000_C7C2E1C43D652C4E9E49FE7517C236CB01AAD054dggeml529mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMsIGFuZCBoYXBweSBuZXcgeWVh ciENCg0KU29ycnkgZm9yIG15IGRlbGF5LCBwbGVhc2Ugc2VlIG15IHJlcGx5IGlubGluZS4NCg0K QmVzdCBSZWdhcmRzLA0KQ2hlbmcNCg0KRnJvbTogc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb2JlcnQgUmFzenVrDQpTZW50OiBUaHVyc2RheSwg RGVjZW1iZXIgMjcsIDIwMTggNjozMSBQTQ0KVG86IGlkckBpZXRmLiBvcmcgPGlkckBpZXRmLm9y Zz4NCkNjOiBTUFJJTkcgV0cgPHNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbc3ByaW5n XSBJLUQgQWN0aW9uOiBkcmFmdC1saS1pZHItc3ItcG9saWN5LXBhdGgtbXR1LTAxLnR4dA0KDQpB dXRob3JzLA0KDQpTUiBwb2xpY3kgZHJhZnQgYWltcyB0byBhZGQgbmV3IFNBRkkgdG8gZGlzdHJp YnV0ZSBTUiBwb2xpY2llcyBha2EgcGF0aHMgdmlhIEJHUC4NCg0KSG93ZXZlciBpbiBTUiAicGF0 aCIgcmVhbGx5IG1lYW5zIHNpbmdsZSBvciBzZXQgb2YgYW5jaG9yIHBvaW50cyBwYWNrZXRzIHdv dWxkIG5lZWQgdG8gdHJhdmVyc2UgdG8gbWVldCByZXF1aXJlZCBwb2xpY2llcywgSXQgbWFrZXMg bm8gYXNzdW1wdGlvbiBhYm91dCBub2RlcyBvciBsaW5rcyB3aGljaCBhcmUgbm90IG9uIHRoZSBT UiBub2RlIGxpc3QgYW5kIGFyZSBwbGFjZXMgYmV0d2VlbiBTUiBub2Rlcy4NCltDaGVuZ11ZZXMs IHlvdSBhcmUgcmlnaHQuIEFuIFNSIHBhdGggbWVhbnMgYSBzZXQgb2YgZW5kcG9pbnQgbm9kZXMg d291bGQgbmVlZCB0byB0cmF2ZXJzZSB0byBtZWV0IHJlcXVpcmVkIHBvbGljaWVzLg0KDQpDdXJy ZW50bHkgaW4gb3VyIGRvY3VtZW50LCB3ZSBhbHdheXMgYXNzdW1lIHRoYXQgdGhlIGNvbnRyb2xs ZXIgY2FsY3VsYXRlcyB0aGUgcGF0aCBNVFUgYmFzZWQgb24gQkdQL0lHUCBkYXRhIGFuZCBnaXZl cyBpdCB0byB0aGUgbm9kZS4NCldlIG1heSBuZWVkIHRvIHN0YXRlIHRoYXQgdGhpcyB3b3VsZCBi ZSDigJx0aGUgYmVzdOKAnSBhcHByb3hpbWF0ZSB2YWx1ZSBhcyBwZXIgdGhlIGluZm9ybWF0aW9u IGF0IHRoZSBjb250cm9sbGVyIHdoZXJlIGNvbnRyb2xsZXIgY2FuIGNvbnNpZGVyIHRoZSBwYXRo IE1UVSBvZiB0aGUgYmVzdCBwYXRocyAoaW4gY2FzZSBvZiBsb29zZSBob3BzIGFuZCBsb3dlciB2 YWx1ZSBpbiBjYXNlIG9mIEVDTVAoPykpLg0KDQpUaGlzIGFwcHJveGltYXRlIFBNVFUgaXMgdXNl ZnVsIGluIFNSIFRFIHNjZW5hcmlvcy4NCkZvciBTUiBCRSwgIHRoZSBQTVRVIG9mIHRoZSBJR1Ag c2hvcnRlc3QgZm9yd2FyZGluZyBwYXRoIGJldHdlZW4gZW5kcG9pbnQgbm9kZXMgY2FuIGJlIGNh bGN1bGF0ZWQgYnkgdGhlIGNvbnRyb2xsZXIgYXMgbG9uZyBhcyB0aGUgTGluayBNVFVzIGNhbiBi ZSBjb2xsZWN0ZWQsIHNvIHRoZSBjb250cm9sbGVyIGNhbiBnZXQgdGhlIFBNVFUgb2YgdGhlIFNS IEJFIHBhdGggYXMgd2VsbC4NCg0KWW91ciBkcmFmdCAod2hpbGUgcGVyaGFwcyB0aGVvcmV0aWNh bGx5IHVzZWZ1bCkgaW50cm9kdWNlcyBjb21wbGV0ZWx5IG5ldyBkeW5hbWljcyB0byB0aGUgU1Ig cG9saWN5IHByb3Bvc2FsIGFzIG5vdyB0aGUgb3JpZ2luYXRvciBvZiBTUiBwb2xpY2llcyBtdXN0 IHRyYWNrIGF0b21pYyBsaW5rIE1UVXMgb24gaG93IHRvIGdldCBmcm9tIGFueSBwb3RlbnRpYWwg cmVjaXBpZW50IG9mIHN1Y2ggcG9saWNpZXMgdG8gZ2l2ZW4gbGlzdCBvZiBhbmNob3Igbm9kZXMg KFNSIG5vZGVzKS4NCltDaGVuZ10gSW4gb3JkZXIgdG8gbWFrZSBzdXJlIHRoYXQgdGhlIFBNVFUg ZGVwaWN0IHRoZSByZWFsIE1UVSBvZiB0aGUgcGF0aCwgaXQgc2hvdWxkIGJlIGNvbGxlY3RlZCBh bmQgdXBkYXRlZCBpbiB0aW1lLg0KDQoNCkV2ZW4gZW5jb2Rpbmcgd2lzZSB0aGUgZHJhZnQgYXMg cHJvcG9zZWQgZG9lcyBub3QgbWVldCB0aGUgc3RhdGVkIHJlcXVpcmVtZW50cyBhcyBpdCBtaXN0 YWtlbmx5IGFzc3VtZXMgIHRoYXQgTVRVIHRvIHJlYWNoIGdpdmVuIHNldCBvZiBwb2xpY2llcyB3 b3VsZCBiZSBpZGVudGljYWwgZnJvbSBhbnkgaW5ncmVzcyBub2RlLg0KW0NoZW5nXSBTb3JyeSwg SSBkb24ndCByZWFsbHkgdW5kZXJzdGFuZCB0aGlzIHBvaW50LCBpZGVudGljYWwgZnJvbSBhbnkg aW5ncmVzcyBub2RlPw0KRG8geW91IG1lYW4gU1IgUG9saWN5W0UsRixHXSBjYW4gYmUgY29uZmln dXJlZCBhdCB0aGUgaGVhZGVuZCBub2RlIEEsIEIgYW5kIEMgcmVzcGVjdGl2ZWx5LCB0aGVuIHRo ZSBNVFUgb2YgW0UsRixHXSBpcyB3cm9uZ2x5IGNvbmZpZ3VyZWQgYXMgaWRlbnRpY2FsIGF0IGRp ZmZlcmVudCBpbmdyZXNzIEEsIEIgYW5kIEM/DQoNCkFjdHVhbGx5LCBpbiB0aGlzIGNhc2UsIHRo ZSBQTVRVcyBhcmUgZGlmZmVyZW50IGFtb25nIHRoZXNlIFNSIHBvbGljaWVzLCBzaW5jZSB0aGV5 IGFyZSBkaWZmZXJlbnQgU1IgcG9saWNpZXMuDQpBbiBTUiBwb2xpY3kgaXMgaWRlbnRpZmllZCBi eSA8aGVhZGVuZCwgY29sb3IsIGVuZHBvaW50Pi4gVGhlIFBNVFUgbWF5YmUgZGlmZmVyZW50IHNp bmNlIHRoZSBsaW5rIE1UVSBiZXR3ZWVuIHRoZSBoZWFkZW5kIG5vZGUgYW5kIHRoZSBmaXJzdCBl bmRwb2ludCBub2RlIG1heSBiZSBkaWZmZXJlbnQuDQoNCkxhc3QgLSBpbiBwcmFjdGljZSB0aGVy ZSBpcyBubyB3YXkgZm9yIHRoZSBjb250cm9sbGVyIG9yIGFueSBvdGhlciBvcmFjbGUgdG8ga25v dyB0aGUgcmVhbCBNVFUgc2luY2UgbWFueSBuZXR3b3JrcyB1c2VzIGVtdWxhdGVkIGNpcmN1aXRz IGFzIG5hdGl2ZSBsaW5rcyBhbmQgdGhlIHJlYWwgTVRVIG5vdCBvbmx5IG1heSBjaGFuZ2UgZXZl cnkgZGVsdGEgdGltZSwgYnV0IGlzIG9ubHkgZGV0ZWN0YWJsZSBieSBkYXRhIHBsYW5lIGVuZCB0 byBlbmQgcHJvYmVzLg0KW0NoZW5nXSBZZXMsIHRoZXJlIGFyZSBzb21lIHNjZW5hcmlvcyBsaWtl IHRoYXQuIEJ1dCBtb3N0IG9mIHRoZSBjYXNlcywgdGhlIE1UVSBzaG91bGQgYmUgc3RhYmxlLg0K QWxzbywgRTJFIHByb2JpbmcgY2FuIGJlIHVzZWQgdG8gZ2V0IHRoZSBQTVRVLiBXZSBhaW0gdG8g c2V0IHRoZSBQTVRVIGluIHRoZSBTUiBwb2xpY3kgd2hpbGUgYW55IHVzZWZ1bCBtZWNoYW5pc20g dG8gZ2V0IHRoZSBNUFRVIGNhbiBiZSB1c2VkIGZvciBzdXJlLg0KDQpXZSBjYW4gYWxzbyBhbGxv dyB0aGUgcHJvYmUvY29udHJvbGxlci9TUi1JbmdyZXNzIHRvIHVzZSBkYXRhIHBsYW5lIHBhdGgg TVRVIGRpc2NvdmVyeSB0ZWNobmlxdWUgaW5zdGVhZCBvZiDigJhiZXN04oCZIGFwcHJveGltYXRl IHZhbHVlIHdpdGggYSBmbGFnIHN0YXRpbmcgdGhlIHNvdXJjZSBvZiB0aGlzIGluZm9ybWF0aW9u IGFzIGFwcHJveGltYXRlIG9yIG1lYXN1cmVkLg0KDQpUaGFua3MgYWdhaW4hDQoNCldpdGggdGhh dCBJIHRoaW5rIHRoaXMgcHJvcG9zYWwgc2hvdWxkIG5vdCBiZSBhZGRlZCB0byBTUiBwb2xpY3kg ZG9jdW1lbnQgaW4gdGhlIGN1cnJlbnQgZm9ybS4NCg0KS2luZCByZWdhcmRzLA0KUm9iZXJ0Lg0K DQoNCk9uIFRodSwgRGVjIDI3LCAyMDE4IGF0IDk6MTggQU0gPGludGVybmV0LWRyYWZ0c0BpZXRm Lm9yZzxtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYuLm9yZz4+IHdyb3RlOg0KDQpBIE5ldyBJ bnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFm dHMgZGlyZWN0b3JpZXMuDQoNCg0KICAgICAgICBUaXRsZSAgICAgICAgICAgOiBTZWdtZW50IFJv dXRpbmcgUGF0aCBNVFUgaW4gQkdQDQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IENoZW5nIExp DQogICAgICAgICAgICAgICAgICAgICAgICAgIFpoZW5iaW4gTGkNCiAgICAgICAgRmlsZW5hbWUg ICAgICAgIDogZHJhZnQtbGktaWRyLXNyLXBvbGljeS1wYXRoLW10dS0wMS50eHQNCiAgICAgICAg UGFnZXMgICAgICAgICAgIDogNw0KICAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDE4LTEyLTI3 DQoNCkFic3RyYWN0Og0KICAgU2VnbWVudCByb3V0aW5nIGlzIGEgc291cmNlIHJvdXRpbmcgcGFy YWRpZ20gdGhhdCBleHBsaWNpdGx5DQogICBpbmRpY2F0ZXMgdGhlIGZvcndhcmRpbmcgcGF0aCBm b3IgcGFja2V0cyBhdCB0aGUgaW5ncmVzcyBub2RlLiAgQW4gU1INCiAgIHBvbGljeSBpcyBhIHNl dCBvZiBjYW5kaWRhdGUgU1IgcGF0aHMgY29uc2lzdGluZyBvZiBvbmUgb3IgbW9yZQ0KICAgc2Vn bWVudCBsaXN0cyB3aXRoIG5lY2Vzc2FyeSBwYXRoIGF0dHJpYnV0ZXMuICBIb3dldmVyLCB0aGUg cGF0aA0KICAgbWF4aW11bSB0cmFuc21pc3Npb24gdW5pdCAoTVRVKSBpbmZvcm1hdGlvbiBmb3Ig U1IgcGF0aCBpcyBub3QNCiAgIGF2YWlsYWJsZSBpbiB0aGUgU1IgcG9saWN5IHNpbmNlIHRoZSBT UiBkb2VzIG5vdCByZXF1aXJlIHNpZ25hbGluZy4NCiAgIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBl eHRlbnNpb25zIHRvIEJHUCB0byBkaXN0cmlidXRlIHBhdGggTVRVDQogICBpbmZvcm1hdGlvbiB3 aXRoaW4gU1IgcG9saWNpZXMuDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2Ug Zm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1saS1pZHItc3ItcG9saWN5LXBhdGgtbXR1Lw0KDQpUaGVyZSBhcmUgYWxzbyBodG1saXplZCB2 ZXJzaW9ucyBhdmFpbGFibGUgYXQ6DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt bGktaWRyLXNyLXBvbGljeS1wYXRoLW10dS0wMQ0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1saS1pZHItc3ItcG9saWN5LXBhdGgtbXR1LTAxDQoNCkEgZGlmZiBm cm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDoNCmh0dHBzOi8vd3d3Lmll dGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1saS1pZHItc3ItcG9saWN5LXBhdGgtbXR1LTAxDQoN Cg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20g dGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRwOi8vdG9vbHMuaWV0Zi5vcmc+ Lg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAg YXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KSS1ELUFubm91bmNlIG1haWxpbmcg bGlzdA0KSS1ELUFubm91bmNlQGlldGYub3JnPG1haWx0bzpJLUQtQW5ub3VuY2VAaWV0Zi5vcmc+ DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ktZC1hbm5vdW5jZQ0KSW50 ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwN Cm9yIGZ0cDovL2Z0cC5pZXRmLm9yZy9pZXRmLzFzaGFkb3ctc2l0ZXMudHh0DQo= --_000_C7C2E1C43D652C4E9E49FE7517C236CB01AAD054dggeml529mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhU TUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHls ZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkhUTUxDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiuvuagvOW8jyBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDkwLjBwdCA3Mi4wcHQgOTAuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5IaSBSb2Jl cnQsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGFua3MgZm9y IHlvdXIgY29tbWVudHMsIGFuZCBoYXBweSBuZXcgeWVhciE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNvcnJ5IGZvciBteSBkZWxheSwgcGxlYXNlIHNlZSBteSBy ZXBseSBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5C ZXN0IFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNoZW5nPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IHNwcmluZyBbbWFp bHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb2JlcnQg UmFzenVrPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBEZWNlbWJlciAyNywgMjAxOCA2OjMx IFBNPGJyPg0KPGI+VG86PC9iPiBpZHJAaWV0Zi4gb3JnICZsdDtpZHJAaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiBTUFJJTkcgV0cgJmx0O3NwcmluZ0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtzcHJpbmddIEktRCBBY3Rpb246IGRyYWZ0LWxpLWlkci1zci1wb2xp Y3ktcGF0aC1tdHUtMDEudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkF1dGhvcnMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlNSIHBvbGljeSBkcmFmdCBhaW1zIHRvIGFkZCBuZXcgU0FGSSB0byBkaXN0 cmlidXRlIFNSIHBvbGljaWVzIGFrYSBwYXRocyB2aWEgQkdQLiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3dldmVyIGluIFNSICZx dW90O3BhdGgmcXVvdDsgcmVhbGx5IG1lYW5zIHNpbmdsZSBvciBzZXQgb2YgYW5jaG9yIHBvaW50 cyBwYWNrZXRzIHdvdWxkIG5lZWQgdG8gdHJhdmVyc2UgdG8gbWVldCByZXF1aXJlZCBwb2xpY2ll cywgSXQgbWFrZXMgbm8gYXNzdW1wdGlvbiBhYm91dCBub2RlcyBvciBsaW5rcyB3aGljaCBhcmUg bm90IG9uIHRoZSBTUiBub2RlIGxpc3QgYW5kIGFyZSBwbGFjZXMgYmV0d2VlbiBTUiBub2Rlcy48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjRFNzki PltDaGVuZ11ZZXMsIHlvdSBhcmUgcmlnaHQuIEFuIFNSIHBhdGggbWVhbnMgYSBzZXQgb2YgZW5k cG9pbnQgbm9kZXMgd291bGQgbmVlZCB0byB0cmF2ZXJzZSB0byBtZWV0IHJlcXVpcmVkIHBvbGlj aWVzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjRFNzkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0RTc5Ij5DdXJyZW50bHkgaW4g b3VyIGRvY3VtZW50LCB3ZSBhbHdheXMgYXNzdW1lIHRoYXQgdGhlIGNvbnRyb2xsZXIgY2FsY3Vs YXRlcyB0aGUgcGF0aCBNVFUgYmFzZWQgb24gQkdQL0lHUCBkYXRhIGFuZCBnaXZlcyBpdCB0byB0 aGUgbm9kZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0RTc5Ij5XZSBtYXkgbmVlZCB0byBzdGF0ZSB0aGF0IHRoaXMg d291bGQgYmUg4oCcdGhlIGJlc3TigJ0gYXBwcm94aW1hdGUgdmFsdWUgYXMgcGVyIHRoZSBpbmZv cm1hdGlvbiBhdCB0aGUgY29udHJvbGxlciB3aGVyZSBjb250cm9sbGVyIGNhbiBjb25zaWRlciB0 aGUgcGF0aCBNVFUgb2YgdGhlIGJlc3QgcGF0aHMgKGluIGNhc2Ugb2YgbG9vc2UgaG9wcyBhbmQg bG93ZXIgdmFsdWUNCiBpbiBjYXNlIG9mIEVDTVAoPykpLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNEU3OSI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjRFNzkiPlRoaXMgYXBwcm94aW1hdGUgUE1UVSBpcyB1c2VmdWwgaW4gU1IgVEUg c2NlbmFyaW9zLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjRFNzkiPkZvciBTUiBCRSwgJm5ic3A7dGhlIFBNVFUgb2Yg dGhlIElHUCBzaG9ydGVzdCBmb3J3YXJkaW5nIHBhdGggYmV0d2VlbiBlbmRwb2ludCBub2RlcyBj YW4gYmUgY2FsY3VsYXRlZCBieSB0aGUgY29udHJvbGxlciBhcyBsb25nIGFzIHRoZSBMaW5rIE1U VXMgY2FuIGJlIGNvbGxlY3RlZCwgc28gdGhlIGNvbnRyb2xsZXIgY2FuIGdldCB0aGUgUE1UVSBv ZiB0aGUgU1IgQkUgcGF0aA0KIGFzIHdlbGwuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Zb3VyIGRyYWZ0ICh3aGlsZSBwZXJoYXBzIHRoZW9yZXRpY2FsbHkg dXNlZnVsKSBpbnRyb2R1Y2VzIGNvbXBsZXRlbHkgbmV3IGR5bmFtaWNzIHRvIHRoZSBTUiBwb2xp Y3kgcHJvcG9zYWwgYXMgbm93IHRoZSBvcmlnaW5hdG9yIG9mIFNSIHBvbGljaWVzIG11c3QgdHJh Y2sgYXRvbWljIGxpbmsgTVRVcyBvbiBob3cgdG8gZ2V0IGZyb20gYW55IHBvdGVudGlhbCByZWNp cGllbnQgb2Ygc3VjaCBwb2xpY2llcyB0bw0KIGdpdmVuIGxpc3Qgb2YgYW5jaG9yIG5vZGVzIChT UiBub2RlcykuJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNEU3OSI+W0NoZW5nXSBJbiBvcmRlciB0byBtYWtlIHN1cmUgdGhh dCB0aGUgUE1UVSBkZXBpY3QgdGhlIHJlYWwgTVRVIG9mIHRoZSBwYXRoLCBpdCBzaG91bGQgYmUg Y29sbGVjdGVkIGFuZCB1cGRhdGVkIGluIHRpbWUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+RXZlbiBlbmNvZGluZyB3aXNlIHRoZSBkcmFmdCBhcyBwcm9wb3NlZCBkb2VzIG5vdCBtZWV0 IHRoZSBzdGF0ZWQgcmVxdWlyZW1lbnRzIGFzIGl0IG1pc3Rha2VubHkgYXNzdW1lcyZuYnNwOyB0 aGF0IE1UVSB0byByZWFjaCBnaXZlbiBzZXQgb2YgcG9saWNpZXMgd291bGQgYmUgaWRlbnRpY2Fs IGZyb20gYW55IGluZ3Jlc3Mgbm9kZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0RTc5Ij5bQ2hl bmddIFNvcnJ5LCBJIGRvbid0IHJlYWxseSB1bmRlcnN0YW5kIHRoaXMgcG9pbnQsIGlkZW50aWNh bCBmcm9tIGFueSBpbmdyZXNzIG5vZGU/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNEU3OSI+RG8geW91IG1lYW4gU1Ig UG9saWN5W0UsRixHXSBjYW4gYmUgY29uZmlndXJlZCBhdCB0aGUgaGVhZGVuZCBub2RlIEEsIEIg YW5kIEMgcmVzcGVjdGl2ZWx5LCB0aGVuIHRoZSBNVFUgb2YgW0UsRixHXSBpcyB3cm9uZ2x5IGNv bmZpZ3VyZWQgYXMgaWRlbnRpY2FsIGF0IGRpZmZlcmVudCBpbmdyZXNzIEEsIEIgYW5kIEM/PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjRFNzkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0RTc5Ij5BY3R1YWxseSwgaW4gdGhpcyBjYXNl LCB0aGUgUE1UVXMgYXJlIGRpZmZlcmVudCBhbW9uZyB0aGVzZSBTUiBwb2xpY2llcywgc2luY2Ug dGhleSBhcmUgZGlmZmVyZW50IFNSIHBvbGljaWVzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjRFNzkiPkFuIFNSIHBv bGljeSBpcyBpZGVudGlmaWVkIGJ5ICZsdDtoZWFkZW5kLCBjb2xvciwgZW5kcG9pbnQmZ3Q7LiBU aGUgUE1UVSBtYXliZSBkaWZmZXJlbnQgc2luY2UgdGhlIGxpbmsgTVRVIGJldHdlZW4gdGhlIGhl YWRlbmQgbm9kZSBhbmQgdGhlIGZpcnN0IGVuZHBvaW50IG5vZGUgbWF5IGJlIGRpZmZlcmVudC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGFzdCAtIGluIHByYWN0aWNlIHRoZXJlIGlzIG5v IHdheSBmb3IgdGhlIGNvbnRyb2xsZXIgb3IgYW55IG90aGVyIG9yYWNsZSB0byBrbm93IHRoZSBy ZWFsIE1UVSBzaW5jZSBtYW55IG5ldHdvcmtzIHVzZXMgZW11bGF0ZWQgY2lyY3VpdHMgYXMgbmF0 aXZlIGxpbmtzIGFuZCB0aGUgcmVhbCBNVFUgbm90IG9ubHkgbWF5IGNoYW5nZSBldmVyeSBkZWx0 YSB0aW1lLCBidXQgaXMgb25seSBkZXRlY3RhYmxlIGJ5IGRhdGENCiBwbGFuZSBlbmQgdG8gZW5k IHByb2Jlcy4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0RTc5Ij5bQ2hlbmddIFllcywgdGhlcmUg YXJlIHNvbWUgc2NlbmFyaW9zIGxpa2UgdGhhdC4gQnV0IG1vc3Qgb2YgdGhlIGNhc2VzLCB0aGUg TVRVIHNob3VsZCBiZSBzdGFibGUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNEU3OSI+QWxzbywgRTJFIHByb2Jpbmcg Y2FuIGJlIHVzZWQgdG8gZ2V0IHRoZSBQTVRVLiBXZSBhaW0gdG8gc2V0IHRoZSBQTVRVIGluIHRo ZSBTUiBwb2xpY3kgd2hpbGUgYW55IHVzZWZ1bCBtZWNoYW5pc20gdG8gZ2V0IHRoZSBNUFRVIGNh biBiZSB1c2VkIGZvciBzdXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0RTc5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNEU3OSI+ V2UgY2FuIGFsc28gYWxsb3cgdGhlIHByb2JlL2NvbnRyb2xsZXIvU1ItSW5ncmVzcyB0byB1c2Ug ZGF0YSBwbGFuZSBwYXRoIE1UVSBkaXNjb3ZlcnkgdGVjaG5pcXVlIGluc3RlYWQgb2Yg4oCYYmVz dOKAmSBhcHByb3hpbWF0ZSB2YWx1ZSB3aXRoIGEgZmxhZyBzdGF0aW5nIHRoZSBzb3VyY2Ugb2Yg dGhpcyBpbmZvcm1hdGlvbiBhcyBhcHByb3hpbWF0ZSBvciBtZWFzdXJlZC4NCjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 RTc5Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNEU3OSI+VGhhbmtzIGFnYWluITxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2l0aCB0aGF0IEkgdGhpbmsgdGhpcyBwcm9w b3NhbCBzaG91bGQgbm90IGJlIGFkZGVkIHRvIFNSIHBvbGljeSBkb2N1bWVudCBpbiB0aGUgY3Vy cmVudCBmb3JtLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5LaW5kIHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Sb2JlcnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgRGVjIDI3LCAyMDE4 IGF0IDk6MTggQU0gJmx0OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi4ub3Jn Ij5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCkEgTmV3IElu dGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0 cyBkaXJlY3Rvcmllcy48YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgVGl0bGUmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogU2VnbWVu dCBSb3V0aW5nIFBhdGggTVRVIGluIEJHUDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBBdXRob3JzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzogQ2hlbmcgTGk8YnI+ DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgWmhlbmJpbiBMaTxicj4NCiZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBGaWxlbmFtZSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyA6IGRyYWZ0LWxpLWlkci1zci1wb2xpY3ktcGF0aC1tdHUtMDEudHh0PGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IFBhZ2VzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs6IDc8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgRGF0ZSZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogMjAxOC0xMi0yNzxicj4NCjxicj4N CkFic3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtTZWdtZW50IHJvdXRpbmcgaXMgYSBzb3VyY2Ug cm91dGluZyBwYXJhZGlnbSB0aGF0IGV4cGxpY2l0bHk8YnI+DQombmJzcDsgJm5ic3A7aW5kaWNh dGVzIHRoZSBmb3J3YXJkaW5nIHBhdGggZm9yIHBhY2tldHMgYXQgdGhlIGluZ3Jlc3Mgbm9kZS4m bmJzcDsgQW4gU1I8YnI+DQombmJzcDsgJm5ic3A7cG9saWN5IGlzIGEgc2V0IG9mIGNhbmRpZGF0 ZSBTUiBwYXRocyBjb25zaXN0aW5nIG9mIG9uZSBvciBtb3JlPGJyPg0KJm5ic3A7ICZuYnNwO3Nl Z21lbnQgbGlzdHMgd2l0aCBuZWNlc3NhcnkgcGF0aCBhdHRyaWJ1dGVzLiZuYnNwOyBIb3dldmVy LCB0aGUgcGF0aDxicj4NCiZuYnNwOyAmbmJzcDttYXhpbXVtIHRyYW5zbWlzc2lvbiB1bml0IChN VFUpIGluZm9ybWF0aW9uIGZvciBTUiBwYXRoIGlzIG5vdDxicj4NCiZuYnNwOyAmbmJzcDthdmFp bGFibGUgaW4gdGhlIFNSIHBvbGljeSBzaW5jZSB0aGUgU1IgZG9lcyBub3QgcmVxdWlyZSBzaWdu YWxpbmcuPGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgZGVmaW5lcyBleHRlbnNpb25z IHRvIEJHUCB0byBkaXN0cmlidXRlIHBhdGggTVRVPGJyPg0KJm5ic3A7ICZuYnNwO2luZm9ybWF0 aW9uIHdpdGhpbiBTUiBwb2xpY2llcy48YnI+DQo8YnI+DQo8YnI+DQpUaGUgSUVURiBkYXRhdHJh Y2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+DQo8YSBocmVmPSJodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1saS1pZHItc3ItcG9saWN5LXBhdGgtbXR1 LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWxpLWlkci1zci1wb2xpY3ktcGF0aC1tdHUvPC9hPjxicj4NCjxicj4NClRoZXJlIGFyZSBhbHNv IGh0bWxpemVkIHZlcnNpb25zIGF2YWlsYWJsZSBhdDo8YnI+DQo8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGktaWRyLXNyLXBvbGljeS1wYXRoLW10dS0wMSIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saS1pZHItc3It cG9saWN5LXBhdGgtbXR1LTAxPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbGktaWRyLXNyLXBvbGljeS1wYXRoLW10dS0wMSIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt bGktaWRyLXNyLXBvbGljeS1wYXRoLW10dS0wMTwvYT48YnI+DQo8YnI+DQpBIGRpZmYgZnJvbSB0 aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWxpLWlkci1zci1wb2xpY3ktcGF0aC1t dHUtMDEiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtbGktaWRyLXNyLXBvbGljeS1wYXRoLW10dS0wMTwvYT48YnI+DQo8YnI+DQo8YnI+DQpQ bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZiBzdWJtaXNzaW9uPGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRp ZmYgYXJlIGF2YWlsYWJsZSBhdCA8YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj4NCnRvb2xzLmlldGYub3JnPC9hPi48YnI+DQo8YnI+DQpJbnRlcm5ldC1EcmFm dHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPg0KPGEgaHJlZj0i ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8iIHRhcmdldD0iX2JsYW5rIj5mdHA6 Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzwvYT48YnI+DQo8YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkktRC1Bbm5vdW5jZSBt YWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86SS1ELUFubm91bmNlQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+SS1ELUFubm91bmNlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaS1kLWFubm91bmNlIiB0YXJnZXQ9 Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3Vu Y2U8L2E+PGJyPg0KSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IDxhIGhyZWY9Imh0dHA6Ly93 d3cuaWV0Zi5vcmcvc2hhZG93Lmh0bWwiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHA6Ly93d3cuaWV0 Zi5vcmcvc2hhZG93Lmh0bWw8L2E+PGJyPg0Kb3IgPGEgaHJlZj0iZnRwOi8vZnRwLmlldGYub3Jn L2lldGYvMXNoYWRvdy1zaXRlcy50eHQiIHRhcmdldD0iX2JsYW5rIj5mdHA6Ly9mdHAuaWV0Zi5v cmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C7C2E1C43D652C4E9E49FE7517C236CB01AAD054dggeml529mbxchi_-- From nobody Thu Jan 3 13:40:18 2019 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45002130F89; Thu, 3 Jan 2019 13:40:17 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 W7cixufxrMLA; Thu, 3 Jan 2019 13:40:14 -0800 (PST) Received: from mail-oi1-x232.google.com (mail-oi1-x232.google.com [IPv6:2607:f8b0:4864:20::232]) (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 6F559130FB7; Thu, 3 Jan 2019 13:40:14 -0800 (PST) Received: by mail-oi1-x232.google.com with SMTP id a77so28869096oii.5; Thu, 03 Jan 2019 13:40:14 -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; bh=yPuNzYH8p61/ogrG5s7LiF/ROi7XjG7lzAPBFBWSEZ4=; b=tGS9B6JhUt0Qw3riL2hdFtWpqgXedBQ1ifI/rzNW5Zie6z5JTpHcH2xqEij9XVZdR7 F5SMxSXqPS94oWpIdqV6Git4y6vSG+tmI9zcXd10KxUFUE6eW884JtuuritmKafxqIN3 w4cXTqXi2c7hpQAt9ftMWm1ynBflT1dRJhEthP727vLF68np5Q1hFYX3zmnhykhWy1zD /IY10dtYvp4CrM4RRnxz5TMp20fvHSFPMTpx+edIqYU78/Icoy+6QFmOQ6adMsyjsJSr ecKosGNTU6MBNOEdZOKOVV7Jj9L/aWxgFZC9rtFJAsM0I27WJbNnpcrZPaMjF+H7v1ha XXew== 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; bh=yPuNzYH8p61/ogrG5s7LiF/ROi7XjG7lzAPBFBWSEZ4=; b=tgl5/uM/auMfgbXJqyxZ/TOQV89+SLBqfC1k/FtZcxpK6ioaIzaKNvXrek7mv/vBhc rPZO6QGPOnlIAv3caYOO/JfyFZoWJ5bomMZqBIjAk39O7Qiil34QpSmhAWOEOnfjPW4B td/NtXj0kxI9YPfko2yfojRsKvXdrJAz37oK4+nht/Y83ZM0opyEZfX32AQVFsYLlpMX lgm6uX+1Lo5zOKzm9L2sul4XgKGSErsrwnS2pXsoI1AYasEh/gifUmIUod5HLmJt10lv xw7hrztxsgpETsmp+1o54Eg9bcx77QwHQL18yngEBNHQ1/mbSKLowl5LnnRUMF7xIb32 Tq8g== X-Gm-Message-State: AA+aEWZSQtO4VxgLXeDH8VHMD7olVQdcLBgNqhNfxvKHNaQXNHjb12FE YQ7eCtbMh6FUyGOiw73WdN1VSUgDBOWw4qgswL4= X-Google-Smtp-Source: AFSGD/X76uU1EyO0bsrHYjWwiJwlUoEpTlj/wd1WpGnK0izf+e6PtcZ/d+O+U26g9BHMxmUmheh4FLbJf+CXs4U9k48= X-Received: by 2002:aca:3cc5:: with SMTP id j188mr34040499oia.278.1546551613665; Thu, 03 Jan 2019 13:40:13 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 3 Jan 2019 13:40:13 -0800 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Thu, 3 Jan 2019 13:40:13 -0800 Message-ID: To: Rob Shakir Cc: SPRING WG , Robert Raszuk , "idr@ietf. org" Content-Type: multipart/alternative; boundary="0000000000008f3614057e949b9e" Archived-At: Subject: Re: [spring] Error Handling for BGP-LS with Segment Routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 21:40:17 -0000 --0000000000008f3614057e949b9e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Rob: Hi! I don=E2=80=99t think I said it before: speaking as a WG participant... I want to pick up on a point you make below, which I agree with: "any topology discovery mechanism (whether used in real-time or not) needs to define how it handles cases where it might end up with missing information=E2=80=9D=E2=80=A6. BGP-LS only defines a mechanism through which it may miss information, but not how to handle it =E2=80=94 or maybe it does (?): by using attribute dis= card it just accepts that the information might be missing going forward=E2=80=A6an= d doesn=E2=80=99t attempt to do anything. Maybe this quote is true: "Doing N= othing Often Leads to the Very Best Something=E2=80=9D =E2=80=94 Winnie the Pooh That action may be ok in the general case=E2=80=A6but I think that doing no= thing may not be enough/appropriate for an application like SR, because it is explicitly calculating paths=E2=80=A6. The point I=E2=80=99m trying to bring up is not necessarily treat-as-withdr= aw vs. attribute discard=E2=80=A6. But, first, is attribute discard enough/appropriate/good for a BGP-LS application such as SR? If it isn=E2= =80=99t, second, is there a different approach that would be better? Maybe we then come to a point where something can change=E2=80=A6or accept the limitation= s of the system and be clear about them. I fully realize that I may be the only one who thinks there=E2=80=99s an issue=E2=80=A6 Thanks!! Alvaro. On December 21, 2018 at 11:23:16 AM, Rob Shakir (robjs@google.com) wrote: Alvaro, I think this is one of the difficulties of overloading a protocol like BGP with different datasets -- it's not simple to say how particular attributes are actually going to be used within a protocol deployment. This was one of the things that was noted in 7606 -- i.e., I can make *any* attribute really affect forwarding if I write a policy that accepts/rejects some UPDATE based on the presence of that attribute. In general, any topology discovery mechanism (whether used in real-time or not) needs to define how it handles cases where it might end up with missing information. Let's consider what the different mechanisms for discovery we have are today: - IGP listening -- in this case, if we have some malformed IS-IS TLV, then we might end up discarding this information (whether it be at the listening node, or a device that didn't flood it earlier in the chain) -= - meaning that we know that we have some potential gap in the topology. - Streaming telemetry -- speaking particularly to gNMI for LSDB streaming encoded using the OpenConfig model, here, we are tolerant to getting as much information as can be parsed, and have a way to carry unknown TLVs (which might include those that cannot be successfully pars= ed) as binary data to the external consumer. This means that the approach is "as complete data as possible", but has the same characteristic that we = can also end up having the potential to lose data. - BGP-LS with attribute discard -- this has some information loss, since we'll have some attributes that could be malformed in the input data, an= d we discard them at the receiver. It doesn't seem to me that, given the source of the data is the IGP, and we might have information discarded there -- that we can really guarantee strong consistency of an off-box view of the network, since we can't guarantee strong consistency across the IGP domain itself. Thus, I'm not sure that the issue that is being highlighted here actually makes a difference when we're considering the overall system design -- we always need to deal with the fact that the view of the network at the path computing node might not match exactly the network's current state in the presence of malformed protocol messages. One motivation for having the LSDB via streaming telemetry is the ability to provide such validation ("do all nodes within my IGP domain, including listeners, have a consistent view of the state of the network?"). If the discussion is "should we adopt treat-as-withdraw vs. attribute discard?" -- I don't think that from the system perspective there is really any difference between the two in this situation. We still have the same potentially inconsistent view of the network. For these reasons, I'd err on leaving this unchanged in the current specification(s). Cheers, r. --0000000000008f3614057e949b9e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Rob:

Hi!

I don=E2=80=99t think I said it before: =C2=A0speaking as a= WG participant...

I want to pick up on a point you make below, which I agree with:= "any topology discovery mechanism (whether used in real-time or not) = needs to define how it handles cases where it might end up with missing inf= ormation=E2=80=9D=E2=80=A6. =C2=A0

BGP-LS only defines a mechanism through which it= may miss information, but not how to handle it =E2=80=94 or maybe it does = (?): by using attribute discard it just accepts that the information might = be missing going forward=E2=80=A6and doesn=E2=80=99t attempt to do anything= .=C2=A0 Maybe this quote is true: "Doing Nothing Often Leads to the Ve= ry Best Something=E2=80=9D =E2=80=94 Winnie the Pooh

That action may be ok in the g= eneral case=E2=80=A6but I think that doing nothing may not be enough/approp= riate for an application like SR, because it is explicitly calculating path= s=E2=80=A6. =C2=A0


The point I=E2=80=99m trying= to bring up is not necessarily treat-as-withdraw vs. attribute discard=E2= =80=A6. But, first, is attribute discard enough/appropriate/good for a BGP-= LS application such as SR?=C2=A0 If it isn=E2=80=99t, second, is there a di= fferent approach that would be better?=C2=A0 Maybe we then come to a point = where something can change=E2=80=A6or accept the limitations of the system = and be clear about them.=C2=A0 I fully realize that I may be the only one w= ho thinks there=E2=80=99s an issue=E2=80=A6
=
Thanks!!

Alvaro.


On December 21, 2018 at 11:23:16 AM, Rob Shakir (robjs@google.com) wrote:

Alvaro,

I think this is one of the difficulties of overloading a protocol like BGP with different datasets -- it's not simple to say how particular attributes are actually going to be used within a protocol deployment. This was one of the things that was noted in 7606 -- i.e., I can make *any* attribute really affect forwarding if I write a policy that accepts/rejects some UPDATE based on the presence of that attribute.

In general, any topology discovery mechanism (whether used in real-time or not) needs to define how it handles cases where it might end up with missing information. Let's consider what the different mechanisms for discovery we have are today:
  • IGP listening -- in this case, if we have some malformed IS-IS TLV, then we might end up discarding this information (whether it be at the listening node, or a device that didn't flood it earlier in the chain) -- meaning that we know that we have some potential gap in the topology.
  • Streaming telemetry -- speaking particularly to gNMI for LSDB streaming encoded using the OpenConfig model, here, we are tolerant to getting as much information as can be parsed, and have a way to carry unknown TLVs (which might include those that cannot be successfully parsed) as binary data to the external consumer. This means that the approach is "as complete data as possible", but has the same characteristic that we can also end up having the potential to lose data.
  • BGP-LS with attribute discard -- this has some information loss, since we'll have some attributes that could be malformed in the input data, and we discard them at the receiver.
It doesn't seem to me that, given the source of the data is the IGP, and we might have information discarded there -- that we can really guarantee strong consistency of an off-box view of the network, since we can't guarantee strong consistency across the IGP domain itself.=C2=A0

Thus, I'm not sure that the issue that is being highlighted here actually makes a difference when we're considering the overall system design -- we always need to deal with the fact that the view of the network at the path computing node might not match exactly the network's current state in the presence of malformed protocol messages. One motivation for having the LSDB via streaming telemetry is the ability to provide such validation ("do all nodes within my IGP domain, including listeners, have a consistent view of the state of the network?").

If the discussion is "should we adopt treat-as-withdraw vs. attribute discard?" -- I don't think that from the system perspective there is really any difference between the two in this situation. We still have the same potentially inconsistent view of the network.

For these reasons, I'd err on leaving this unchanged in the current specification(s).

Cheers,
r.
= --0000000000008f3614057e949b9e-- From nobody Thu Jan 3 14:22:57 2019 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66124131313 for ; Thu, 3 Jan 2019 14:22:55 -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_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 nx8jm-boTBoC for ; Thu, 3 Jan 2019 14:22:53 -0800 (PST) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDA7C131311 for ; Thu, 3 Jan 2019 14:22:52 -0800 (PST) Received: by mail-qt1-x835.google.com with SMTP id n32so38508680qte.11 for ; Thu, 03 Jan 2019 14:22: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=E/OQNfYMwYyKk++On9CakqeLWpfLum9LusXaqgVgc9g=; b=FxqBGsam5yGNZ5JLtTOgvrIvF4G5ZL2er4e/Y0u4KFfgJVJgXA4TDhDlphXM1mud4A wpZSRlyKrXAUNnY8DS+K5nh1sXkfeMCW69lmQ8iRsB+Swz2748noEltqW5zCbr0l/Do2 k3SJfcLVeHzMYxDIRDCSOGhpkUhMS62Cs7vmkLE2nJ0vctZEsxBRoO4Gyt17eb2gilfA HfR3ktOZK2cfGcd4YvWC1eV1lZuRi3aTny8pIEz5FhjNBNJ0WmF8xKYMXoQziuWqswA/ rLMmIpE88zzuFe8QmvKd+ZzJT2dDY0qt31bKR94JXyY1+6nVIb8iu+Y644cugFU8Q1Mz hzTw== 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=E/OQNfYMwYyKk++On9CakqeLWpfLum9LusXaqgVgc9g=; b=QljYUG5IZj98nlNlIpdmcdjUT2zs9wSXYCemfqRiWbsBWOVI9A7D6lGpqGG7MPvViu HUb3RsTUPYfJpshKUVVD1TmFfZN3WWqRCUoqUROtUudHnTufilevwlRPKuejzW2ydvHW 1y716vkEutOTMpBHDBmNdJx9xo5tku3vG6orGRo7cPpWSBQX3croKfzaomgkBt+PE5/1 7eBP6hepeFLp7Rww5sJ3m0Rh3RTSvwOUAeKMlS0tB4mgq9Ej+JukQH2oFTzKYim9ZKqV Pam087NZyvjzu48ycd+QNwyY3Gc0zIs/ABx2YzAeqmhqPRdidiz4hv/3O2RoelQOGrCG /fZw== X-Gm-Message-State: AJcUukdf1DuEpJyv08cGMt9aB4pF4fk8+cKiHONAehqucyxBRsQkb25Y 1eANiz5NEO8PlDKVOIv35IUi48HD94kZT5YnSgY6Fg== X-Google-Smtp-Source: AFSGD/X/2OkJCI+lSJCvqb3+AggRaITNSvkHDgHegM9RzCwMgZ4clcJSlakp5Bdtvbl6zo27Is8AsB5YlwZfI0HtM1s= X-Received: by 2002:ac8:4359:: with SMTP id a25mr48665394qtn.361.1546554171909; Thu, 03 Jan 2019 14:22:51 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Thu, 3 Jan 2019 23:22:41 +0100 Message-ID: To: Alvaro Retana Cc: Rob Shakir , "idr@ietf. org" , SPRING WG , Robert Raszuk Content-Type: multipart/alternative; boundary="0000000000000affd7057e9534a8" Archived-At: Subject: Re: [spring] Error Handling for BGP-LS with Segment Routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 22:22:55 -0000 --0000000000000affd7057e9534a8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alvaro, > BGP-LS only defines a mechanism through which it may miss information, but not how to handle it I think the point at least some of us are trying to indicate is that the overall application is responsible for building into it proper redundancy. BGP-LS reg error handling is not worse then BGP IPv4 or IPv6 routing - do you agree ? If so unreachability should be handled end to end say by dual homing, falling back from SR paths to "native IP path" etc ... In my view SR controller is mainly used as optimization not as critical element - well at least in the deployment models I would personally recommend to use. Regards, R. On Thu, Jan 3, 2019 at 10:40 PM Alvaro Retana wrote: > Rob: > > Hi! > > I don=E2=80=99t think I said it before: speaking as a WG participant... > > I want to pick up on a point you make below, which I agree with: "any > topology discovery mechanism (whether used in real-time or not) needs to > define how it handles cases where it might end up with missing > information=E2=80=9D=E2=80=A6. > > BGP-LS only defines a mechanism through which it may miss information, bu= t > not how to handle it =E2=80=94 or maybe it does (?): by using attribute d= iscard it > just accepts that the information might be missing going forward=E2=80=A6= and > doesn=E2=80=99t attempt to do anything.. Maybe this quote is true: "Doin= g Nothing > Often Leads to the Very Best Something=E2=80=9D =E2=80=94 Winnie the Pooh > > That action may be ok in the general case=E2=80=A6but I think that doing = nothing > may not be enough/appropriate for an application like SR, because it is > explicitly calculating paths=E2=80=A6. > > > The point I=E2=80=99m trying to bring up is not necessarily treat-as-with= draw vs. > attribute discard=E2=80=A6. But, first, is attribute discard > enough/appropriate/good for a BGP-LS application such as SR? If it isn= =E2=80=99t, > second, is there a different approach that would be better? Maybe we the= n > come to a point where something can change=E2=80=A6or accept the limitati= ons of the > system and be clear about them. I fully realize that I may be the only o= ne > who thinks there=E2=80=99s an issue=E2=80=A6 > > Thanks!! > > Alvaro. > > > On December 21, 2018 at 11:23:16 AM, Rob Shakir (robjs@google.com) wrote: > > Alvaro, > > I think this is one of the difficulties of overloading a protocol like BG= P > with different datasets -- it's not simple to say how particular attribut= es > are actually going to be used within a protocol deployment. This was one = of > the things that was noted in 7606 -- i.e., I can make *any* attribute > really affect forwarding if I write a policy that accepts/rejects some > UPDATE based on the presence of that attribute. > > In general, any topology discovery mechanism (whether used in real-time o= r > not) needs to define how it handles cases where it might end up with > missing information. Let's consider what the different mechanisms for > discovery we have are today: > > - IGP listening -- in this case, if we have some malformed IS-IS TLV, > then we might end up discarding this information (whether it be at the > listening node, or a device that didn't flood it earlier in the chain)= -- > meaning that we know that we have some potential gap in the topology. > - Streaming telemetry -- speaking particularly to gNMI for LSDB > streaming encoded using the OpenConfig model, here, we are tolerant to > getting as much information as can be parsed, and have a way to carry > unknown TLVs (which might include those that cannot be successfully pa= rsed) > as binary data to the external consumer. This means that the approach = is > "as complete data as possible", but has the same characteristic that w= e can > also end up having the potential to lose data. > - BGP-LS with attribute discard -- this has some information loss, > since we'll have some attributes that could be malformed in the input = data, > and we discard them at the receiver. > > It doesn't seem to me that, given the source of the data is the IGP, and > we might have information discarded there -- that we can really guarantee > strong consistency of an off-box view of the network, since we can't > guarantee strong consistency across the IGP domain itself. > > Thus, I'm not sure that the issue that is being highlighted here actually > makes a difference when we're considering the overall system design -- we > always need to deal with the fact that the view of the network at the pat= h > computing node might not match exactly the network's current state in the > presence of malformed protocol messages. One motivation for having the LS= DB > via streaming telemetry is the ability to provide such validation ("do al= l > nodes within my IGP domain, including listeners, have a consistent view o= f > the state of the network?"). > > If the discussion is "should we adopt treat-as-withdraw vs. attribute > discard?" -- I don't think that from the system perspective there is real= ly > any difference between the two in this situation. We still have the same > potentially inconsistent view of the network. > > For these reasons, I'd err on leaving this unchanged in the current > specification(s). > > Cheers, > r. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --0000000000000affd7057e9534a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alvaro,

> BGP-LS only defines a m= echanism through which it may miss information, but not how to handle it=C2= =A0=C2=A0

I think the point at least some of u= s are trying to indicate is that the overall application is responsible for= building into it proper redundancy.=C2=A0

BGP-LS = reg error handling is not worse then BGP IPv4 or IPv6 routing - do you agre= e ? If so unreachability should be handled end to end say by dual homing, f= alling back from SR paths to "native IP path" etc ...=C2=A0
=

In my view SR controller is mainly used as optimization= not as critical element - well at least in the deployment models I would p= ersonally recommend to use.=C2=A0

Regards,
R.


On= Thu, Jan 3, 2019 at 10:40 PM Alvaro Retana <aretana.ietf@gmail.com> wrote:
Rob:

Hi!

I don=E2=80=99t think I sa= id it before: =C2=A0speaking as a WG participant...

I want to pick up on a point yo= u make below, which I agree with: "any topology discovery mechanism (w= hether used in real-time or not) needs to define how it handles cases where= it might end up with missing information=E2=80=9D=E2=80=A6. =C2=A0

BGP-LS only def= ines a mechanism through which it may miss information, but not how to hand= le it =E2=80=94 or maybe it does (?): by using attribute discard it just ac= cepts that the information might be missing going forward=E2=80=A6and doesn= =E2=80=99t attempt to do anything..=C2=A0 Maybe this quote is true: "D= oing Nothing Often Leads to the Very Best Something=E2=80=9D =E2=80=94 Winn= ie the Pooh

That action may be ok in the general case=E2=80=A6but I think that doin= g nothing may not be enough/appropriate for an application like SR, because= it is explicitly calculating paths=E2=80=A6. =C2=A0


The point I=E2=80=99m trying to bring up is not necessarily treat-as-= withdraw vs. attribute discard=E2=80=A6. But, first, is attribute discard e= nough/appropriate/good for a BGP-LS application such as SR?=C2=A0 If it isn= =E2=80=99t, second, is there a different approach that would be better?=C2= =A0 Maybe we then come to a point where something can change=E2=80=A6or acc= ept the limitations of the system and be clear about them.=C2=A0 I fully re= alize that I may be the only one who thinks there=E2=80=99s an issue=E2=80= =A6

Than= ks!!

Alv= aro.


On December 21, 2018 at 11:23:16 AM, Rob Shakir (robjs@google.com) wrote:

=
Alvaro,

I think this is one of the difficulties of overloading a protocol like BGP with different datasets -- it's not simple to say how particular attributes are actually going to be used within a protocol deployment. This was one of the things that was noted in 7606 -- i.e., I can make *any* attribute really affect forwarding if I write a policy that accepts/rejects some UPDATE based on the presence of that attribute.

In general, any topology discovery mechanism (whether used in real-time or not) needs to define how it handles cases where it might end up with missing information. Let's consider what the different mechanisms for discovery we have are today:
  • IGP listening -- in this case, if we have some malformed IS-IS TLV, then we might end up discarding this information (whether it be at the listening node, or a device that didn't flood it earlier in the chain) -- meaning that we know that we have some potential gap in the topology.
  • Streaming telemetry -- speaking particularly to gNMI for LSDB streaming encoded using the OpenConfig model, here, we are tolerant to getting as much information as can be parsed, and have a way to carry unknown TLVs (which might include those that cannot be successfully parsed) as binary data to the external consumer. This means that the approach is "as complete data as possible", but has the same characteristic that we can also end up having the potential to lose data.
  • BGP-LS with attribute discard -- this has some information loss, since we'll have some attributes that could be malformed in the input data, and we discard them at the receiver.
It doesn't seem to me that, given the source of the data is the IGP, and we might have information discarded there -- that we can really guarantee strong consistency of an off-box view of the network, since we can't guarantee strong consistency across the IGP domain itself.=C2=A0

Thus, I'm not sure that the issue that is being highlighted here actually makes a difference when we're considering the overall system design -- we always need to deal with the fact that the view of the network at the path computing node might not match exactly the network's current state in the presence of malformed protocol messages. One motivation for having the LSDB via streaming telemetry is the ability to provide such validation ("do all nodes within my IGP domain, including listeners, have a consistent view of the state of the network?").

If the discussion is "should we adopt treat-as-withdraw vs. attribute discard?" -- I don't think that from the system perspective there is really any difference between the two in this situation. We still have the same potentially inconsistent view of the network.

For these reasons, I'd err on leaving this unchanged in the current specification(s).

Cheers,
r.
_______________________________________________
spring mailing list
spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
--0000000000000affd7057e9534a8-- From nobody Thu Jan 3 14:40:28 2019 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D42313134C for ; Thu, 3 Jan 2019 14:40:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 bVwsBRzeXAOl for ; Thu, 3 Jan 2019 14:40:24 -0800 (PST) Received: from mail-wr1-x433.google.com (mail-wr1-x433.google.com [IPv6:2a00:1450:4864:20::433]) (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 5118913134A for ; Thu, 3 Jan 2019 14:40:24 -0800 (PST) Received: by mail-wr1-x433.google.com with SMTP id s12so35004570wrt.4 for ; Thu, 03 Jan 2019 14:40:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=GMhmM06cmI1n6HQ02qABXGY1MCPBXnNBnXmbliSb+98=; b=FO0WEX9OYEVArCuk+peoBBr6CasHTUv9yxpmPJwnODDtTkk8c7c5KNdRn972QZeOqq 94YxBzqEUZ4rr2onr1N3He4IxfnCCQ9F3nsvWMLNgn3UVnzSCG+JOCljOQr+8W3qK6fu oU748/SHJsTaD7rRN+H7+bsZVkH05c20/76qorvsVH1CalliRsnsBdQhxc1ObAvnphHM 9SX/hUZoJreXvo3W6i8+Z1cIlVKvr8MTb+bOKrKiIFP4qHOToN8cLCellc9G8rnhkVx1 psO9bMpFhojcyJqmjFtSyIyXGbxInXsVLYwTsmAHBLDEyuTMn8u8vP+fW/Z53k033+Ek RCsg== 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=GMhmM06cmI1n6HQ02qABXGY1MCPBXnNBnXmbliSb+98=; b=UGLXSo1YrU6JKAA0Zp1VusxeYu4Kgm8kdQRCC3a+Nz6cPx3y+xyvMGVpPBlyyRpKGE 4XQO3Ue8k4YGqA6hSdjJ130H553/TCqaTUQM+0+MlF+RE239HSwvRRB8qxY2pxWdMZUS 3klm3WnExieXgUmO5lBWsNXqFSnGBC4bMA3UcgXBFE9cVH6yIHNt3FHW+iWyL38OYXrX iV942FneBT3OZlxVC/OFV26jP75TgHuPDcArlbkJkSTIzA09cdCOZOF5z9srug0mLMZx 5bdJzgLz3onrT83GxbJ8rHup4KVBKv7ustJ/QTGH+jSqdvKRUQtLgZ1becxlRAALsv9w 7Eog== X-Gm-Message-State: AJcUukfvbhS6jpEd6/mZo9Z6RfGy+iaQLgvLoHqqRAnu3SwidWZAgMaS 4wEGWBkwi6uiWiTa3Z73kfLc1QwIS3X6VOGP0ZrYlw== X-Google-Smtp-Source: ALg8bN4wTSMdbaddMAkHbTGrSjf89rPrFJMi+uu60qPwOJofqsLMXncbPlcPgwUb40lkEw4SX0TuaiY5JxaiThk8+Ag= X-Received: by 2002:adf:9591:: with SMTP id p17mr44810222wrp.224.1546555222186; Thu, 03 Jan 2019 14:40:22 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rob Shakir Date: Thu, 3 Jan 2019 14:40:10 -0800 Message-ID: To: Alvaro Retana Cc: SPRING WG , Robert Raszuk , "idr@ietf. org" Content-Type: multipart/alternative; boundary="000000000000a559fe057e957229" Archived-At: Subject: Re: [spring] Error Handling for BGP-LS with Segment Routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Jan 2019 22:40:27 -0000 --000000000000a559fe057e957229 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Alvaro, Also speaking as a WG participant :-) On Thu, Jan 3, 2019 at 1:40 PM Alvaro Retana wrote= : > BGP-LS only defines a mechanism through which it may miss information, bu= t > not how to handle it =E2=80=94 or maybe it does (?): by using attribute d= iscard it > just accepts that the information might be missing going forward=E2=80=A6= and > doesn=E2=80=99t attempt to do anything. Maybe this quote is true: "Doing= Nothing > Often Leads to the Very Best Something=E2=80=9D =E2=80=94 Winnie the Pooh > I think that it defines *something*, albeit not explicitly. Essentially, as I read it, we're saying "when an attribute encoded by the advertising BGP-LS source is incorrect, then BGP-LS as a system will prefer to use partial information" (partial information, since we assume that some information does get through, since the NLRI could be parsed). That action may be ok in the general case=E2=80=A6but I think that doing no= thing > may not be enough/appropriate for an application like SR, because it is > explicitly calculating paths=E2=80=A6. > > The point I=E2=80=99m trying to bring up is not necessarily treat-as-with= draw vs. > attribute discard=E2=80=A6. But, first, is attribute discard > enough/appropriate/good for a BGP-LS application such as SR? If it isn= =E2=80=99t, > second, is there a different approach that would be better? Maybe we the= n > come to a point where something can change=E2=80=A6or accept the limitati= ons of the > system and be clear about them. I fully realize that I may be the only o= ne > who thinks there=E2=80=99s an issue=E2=80=A6 > My point was really the same... The question I was trying to raise is "what is the alternative that you would suggest?". Other technologies that fulfill the same role as BGP-LS (those that I described) don't take a very different approach. Clearly, it's bad to calculate paths with incomplete information about the topology of the network. It's also bad to calculate zero paths because you discarded the entire topology based on an error. We're in-between a rock and a hard place in terms of maintaining system functionality here -- all systems that do the same as BGP-LS are having to make some form of compromise about which constraint (correctness, or connectivity) they are violating. This is why I was arguing for leaving things unchanged -- the correctness constraint seems OK to violate by default. If there are deployments where connectivity is the desirable constraint to violate, then reacting to the fact that attribute-discard did occur is possible (or not configuring 7606 error handling if the implementation supports this). Describing these compromises is, of course, a good idea. However, it's not clear where this description would go -- we don't really have a document that describes this overall system and how it might be implemented today. Cheers and HNY! r. > > Thanks!! > > Alvaro. > > > On December 21, 2018 at 11:23:16 AM, Rob Shakir (robjs@google.com) wrote: > > Alvaro, > > I think this is one of the difficulties of overloading a protocol like BG= P > with different datasets -- it's not simple to say how particular attribut= es > are actually going to be used within a protocol deployment. This was one = of > the things that was noted in 7606 -- i.e., I can make *any* attribute > really affect forwarding if I write a policy that accepts/rejects some > UPDATE based on the presence of that attribute. > > In general, any topology discovery mechanism (whether used in real-time o= r > not) needs to define how it handles cases where it might end up with > missing information. Let's consider what the different mechanisms for > discovery we have are today: > > - IGP listening -- in this case, if we have some malformed IS-IS TLV, > then we might end up discarding this information (whether it be at the > listening node, or a device that didn't flood it earlier in the chain)= -- > meaning that we know that we have some potential gap in the topology. > - Streaming telemetry -- speaking particularly to gNMI for LSDB > streaming encoded using the OpenConfig model, here, we are tolerant to > getting as much information as can be parsed, and have a way to carry > unknown TLVs (which might include those that cannot be successfully pa= rsed) > as binary data to the external consumer. This means that the approach = is > "as complete data as possible", but has the same characteristic that w= e can > also end up having the potential to lose data. > - BGP-LS with attribute discard -- this has some information loss, > since we'll have some attributes that could be malformed in the input = data, > and we discard them at the receiver. > > It doesn't seem to me that, given the source of the data is the IGP, and > we might have information discarded there -- that we can really guarantee > strong consistency of an off-box view of the network, since we can't > guarantee strong consistency across the IGP domain itself. > > Thus, I'm not sure that the issue that is being highlighted here actually > makes a difference when we're considering the overall system design -- we > always need to deal with the fact that the view of the network at the pat= h > computing node might not match exactly the network's current state in the > presence of malformed protocol messages. One motivation for having the LS= DB > via streaming telemetry is the ability to provide such validation ("do al= l > nodes within my IGP domain, including listeners, have a consistent view o= f > the state of the network?"). > > If the discussion is "should we adopt treat-as-withdraw vs. attribute > discard?" -- I don't think that from the system perspective there is real= ly > any difference between the two in this situation. We still have the same > potentially inconsistent view of the network. > > For these reasons, I'd err on leaving this unchanged in the current > specification(s). > > Cheers, > r. > > --000000000000a559fe057e957229 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Alvaro,

Also speaking as a WG partic= ipant :-)

On Thu, Jan 3,= 2019 at 1:40 PM Alvaro Retana <aretana.ietf@gmail.com> wrote:
BGP-LS only defines a mechanism through which it may miss= information, but not how to handle it =E2=80=94 or maybe it does (?): by u= sing attribute discard it just accepts that the information might be missin= g going forward=E2=80=A6and doesn=E2=80=99t attempt to do anything.=C2=A0 M= aybe this quote is true: "Doing Nothing Often Leads to the Very Best S= omething=E2=80=9D =E2=80=94 Winnie the Pooh

I think that it defines *something*, albeit not expl= icitly. Essentially, as I read it, we're saying "when an attribute= encoded by the advertising BGP-LS source is incorrect, then BGP-LS as a sy= stem will prefer to use partial information" (partial information, sin= ce we assume that some information does get through, since the NLRI could b= e parsed).

= That action may be ok in the general case=E2=80=A6but I think that doing no= thing may not be enough/appropriate for an application like SR, because it = is explicitly calculating paths=E2=80=A6.=C2=A0 =C2=A0

The point I=E2=80=99m trying to bring up is not necessarily= treat-as-withdraw vs. attribute discard=E2=80=A6. But, first, is attribute= discard enough/appropriate/good for a BGP-LS application such as SR?=C2=A0= If it isn=E2=80=99t, second, is there a different approach that would be b= etter?=C2=A0 Maybe we then come to a point where something can change=E2=80= =A6or accept the limitations of the system and be clear about them.=C2=A0 I= fully realize that I may be the only one who thinks there=E2=80=99s an iss= ue=E2=80=A6

My point was = really the same... The question I was trying to raise is "what is the = alternative that you would suggest?". Other technologies that fulfill = the same role as BGP-LS (those that I described) don't take a very diff= erent approach.

Clearly, it's bad to calculate= paths with incomplete information about the topology of the network. It= 9;s also bad to calculate zero paths because you discarded the entire topol= ogy based on an error. We're in-between a rock and a hard place in term= s of maintaining system functionality here -- all systems that do the same = as BGP-LS are having to make some form of compromise about which constraint= (correctness, or connectivity) they are violating.

This is why I was arguing for leaving things unchanged -- the correctness= constraint seems OK to violate by default. If there are deployments where = connectivity is the desirable constraint to violate, then reacting to the f= act that attribute-discard did occur is possible (or not configuring 7606 e= rror handling if the implementation supports this).

Describing these compromises is, of course, a good idea. However, it'= s not clear where this description would go -- we don't really have a d= ocument that describes this overall system and how it might be implemented = today.=C2=A0

Cheers and HNY!
r.

=C2=A0
Thanks!!
Alvaro.


On December 21, 2018 at 11:23:16 AM, Rob Shakir (robjs@google.com) wrote:

Alvaro,

I think this is one of the difficulties of overloading a protocol like BGP with different datasets -- it's not simple to say how particular attributes are actually going to be used within a protocol deployment. This was one of the things that was noted in 7606 -- i.e., I can make *any* attribute really affect forwarding if I write a policy that accepts/rejects some UPDATE based on the presence of that attribute.

In general, any topology discovery mechanism (whether used in real-time or not) needs to define how it handles cases where it might end up with missing information. Let's consider what the different mechanisms for discovery we have are today:
  • IGP listening -- in this case, if we have some malformed IS-IS TLV, then we might end up discarding this information (whether it be at the listening node, or a device that didn't flood it earlier in the chain) -- meaning that we know that we have some potential gap in the topology.
  • Streaming telemetry -- speaking particularly to gNMI for LSDB streaming encoded using the OpenConfig model, here, we are tolerant to getting as much information as can be parsed, and have a way to carry unknown TLVs (which might include those that cannot be successfully parsed) as binary data to the external consumer. This means that the approach is "as complete data as possible", but has the same characteristic that we can also end up having the potential to lose data.
  • BGP-LS with attribute discard -- this has some information loss, since we'll have some attributes that could be malformed in the input data, and we discard them at the receiver.
It doesn't seem to me that, given the source of the data is the IGP, and we might have information discarded there -- that we can really guarantee strong consistency of an off-box view of the network, since we can't guarantee strong consistency across the IGP domain itself.=C2=A0

Thus, I'm not sure that the issue that is being highlighted here actually makes a difference when we're considering the overall system design -- we always need to deal with the fact that the view of the network at the path computing node might not match exactly the network's current state in the presence of malformed protocol messages. One motivation for having the LSDB via streaming telemetry is the ability to provide such validation ("do all nodes within my IGP domain, including listeners, have a consistent view of the state of the network?").

If the discussion is "should we adopt treat-as-withdraw vs. attribute discard?" -- I don't think that from the system perspective there is really any difference between the two in this situation. We still have the same potentially inconsistent view of the network.

For these reasons, I'd err on leaving this unchanged in the current specification(s).

Cheers,
r.
--000000000000a559fe057e957229-- From nobody Fri Jan 4 08:48:31 2019 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70ABD130E33; Fri, 4 Jan 2019 08:48:24 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 CVD_LNWKIonr; Fri, 4 Jan 2019 08:48:22 -0800 (PST) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 4A6CD130DBE; Fri, 4 Jan 2019 08:48:22 -0800 (PST) Received: by mail-oi1-x236.google.com with SMTP id t204so30823800oie.7; Fri, 04 Jan 2019 08:48:22 -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; bh=rOD6qCUCB7Urqob733Jpg3TvwIrGBx1GjmHcc7M2yxQ=; b=dxdOlPr7s++yuytzwRQKmfO4R8Gr3saFmsVRAPwdtEDAcTyUXWS0H9DhOl0KHOZ6Up ApvFdLg0bG/G1B6deaA6M//HgIwdclKZOF3UukAVNF42BlO+/x/7uLciA23/IlUQGSSg a9mjGAY28TmE4HC6X1Ccrh5Ma8AaRGjPVKAvPZVzF+54AMi9DjEyY5NN75s5GkqcHy7u hDlxh8wHIRDZj0oto2TinTeQOATn1Jjm9dmL8oBAMyTXh4sjs36gKjzXKoDJ8FADEZfK D9AtbObDauXyDghbblO4dewl/koiz4lXfnK0ZhQ7lMJXUAcHpTJXc3+n/RiG+G4uOyma nE7w== 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; bh=rOD6qCUCB7Urqob733Jpg3TvwIrGBx1GjmHcc7M2yxQ=; b=bKP5WjLAU3WWPjYOu9UPmsdr/6sqB8QhcU4FBQLyfszDt6gAsDRmj8jMms/F/TzS+J XGVSnHlWXd65u9piz2huG+p64s9A0pjurvTq9JUkIKwcHeJIGsoaMpYd1cpt+YRYdMhX qw7DXJzPInZVfK/RVjXqKJXxTiEfCUztAIV0/5QyeYTorQ5sEKx3FzBoocgpUgJ2bvd1 wZlfKlVM5ypshUzG2THII9CmHMmot1DqCcrWH6gSCi+GE0B163MN+eP5pJQNdSFQoBT8 VB6c2TLK9ruW1gb5QR46Nse3veDTOp+oM/4NTkJyGWqaZvlmmp/i9PqPOBmY7iowR5Z+ O/xQ== X-Gm-Message-State: AA+aEWbreeX7T199GYql4KNdOmYcS4MPUEKXwFIrBCRWqc2lfT5Yj+Ak SIjZNGMmKy3xsJszOeeqY0x/xtOc7OT/mIPiVxY= X-Google-Smtp-Source: AFSGD/UZqq4DMm+BTEvLctfPKjWpeHPTSu1d9Y5sCmIYMzE9SiicJ0Nv73StFEpxuKuI8JXA2MuxMyHl5j/BUAs1w6c= X-Received: by 2002:aca:b6c3:: with SMTP id g186mr37164464oif.289.1546620501665; Fri, 04 Jan 2019 08:48:21 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 4 Jan 2019 08:48:20 -0800 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Fri, 4 Jan 2019 08:48:20 -0800 Message-ID: To: Robert Raszuk Cc: Rob Shakir , "idr@ietf. org" , SPRING WG , Robert Raszuk Content-Type: multipart/alternative; boundary="0000000000009aaba7057ea4a554" Archived-At: Subject: Re: [spring] Error Handling for BGP-LS with Segment Routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 16:48:24 -0000 --0000000000009aaba7057ea4a554 Content-Type: text/plain; charset="UTF-8" Very good point! :-) On January 3, 2019 at 5:22:52 PM, Robert Raszuk (robert@raszuk.net) wrote: In my view SR controller is mainly used as optimization not as critical element - well at least in the deployment models I would personally recommend to use. --0000000000009aaba7057ea4a554 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Very good point! :-)

On January 3, 2019 at 5:22:52 PM, Robert Raszuk (robert@raszuk.net) wrote:

In m= y view SR controller is mainly used as optimization not as critical element= - well at least in the deployment models I would personally recommend to u= se.=C2=A0
<= /div> --0000000000009aaba7057ea4a554-- From nobody Fri Jan 4 11:40:11 2019 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8386130E8E; Fri, 4 Jan 2019 11:40:00 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 SOMko7TUL6ok; Fri, 4 Jan 2019 11:39:58 -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 A6C16130E8D; Fri, 4 Jan 2019 11:39:58 -0800 (PST) Received: by mail-oi1-x22b.google.com with SMTP id y1so31239948oie.12; Fri, 04 Jan 2019 11:39:58 -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; bh=j2qYbxrb11VG+YQPmVuc4eO41OAL5bvFFghMv486VE0=; b=B+OkL/8USE7jlmVtio+xmVvo3ovZoMkxNtIx4QXAY8SrNDtDOcSb2qPFNAH4nGG2aw OAqdbJ2uhXxPx82s59rs0g/ta9BgCCN8/4k2KjbcVCtgR1XjBbBWc/03hLPrljIPXNkT iz8sRfR9ZEuzbLVVkQJXq49X7+trY/01N/zSPhP0pgkymJjA5ZFagQr19g8376HMtzU9 d0ZdjkZM60opQav9clmG9zdm56pIZ242Z9X0jfwycxB7aiqVtoqu/fJo4coUFzrFP8nF a1EUzkicUDLGJbffkpcj8lkaVVrgPUQlebkINZlUjqCi7BdiIszUX2GkdorrR30LvlKe Jnmg== 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; bh=j2qYbxrb11VG+YQPmVuc4eO41OAL5bvFFghMv486VE0=; b=jbwpfVEkEteVhIdYbtNKGL+96isckMBbDUzzQW+etJ/d8KOyWFZxEPYhh2LD+3Pcg3 a9HUfnCYxsMzH+IFiLXdDAlafOpDicyoc4pC4GrIQOkGAFHPyZQzPCULRotxqB5Zj9AU yXhAW9e1VwByazCqYj76L94LfqD29l5EgBtfSIgcnPKaUYvylHxm0g4AlJ2NzjWPK5H6 qJciyZL5u/QbZoKpukIaAq0pPBvoK60RfemacmcrsVIzvrXZ3Z3J5NtPQ9HYj68W4u/c zcDECcwwZ0CnztBI91lEJGmmhgROqi71g4IqkHgGPLA2piiljw1D9SbAr0q4hl7qzZAL skUQ== X-Gm-Message-State: AJcUukdCF+fCAg9xchJkmT3TETRQO8973lzZ+33L5AN8DAeSWKZ8x8pV +nB3+i1aUcUeC5zak9BwgHTqezNx+sHjBbc70is= X-Google-Smtp-Source: ALg8bN56QiEob4zis8vVfaqfykpRBB/tQqIeocv4TC7ARhrP5/4jZSfowX5JIbtxbc3SChJH4HjHqcX8/pw8PRyytPE= X-Received: by 2002:aca:aa81:: with SMTP id t123mr36850992oie.218.1546630798011; Fri, 04 Jan 2019 11:39:58 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 4 Jan 2019 11:39:57 -0800 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Fri, 4 Jan 2019 11:39:57 -0800 Message-ID: To: Rob Shakir Cc: "idr@ietf. org" , Robert Raszuk , SPRING WG Content-Type: multipart/alternative; boundary="00000000000050733d057ea70b98" Archived-At: Subject: Re: [spring] Error Handling for BGP-LS with Segment Routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 19:40:01 -0000 --00000000000050733d057ea70b98 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On January 3, 2019 at 5:40:23 PM, Rob Shakir (robjs@google.com) wrote: Describing these compromises is, of course, a good idea. However, it's not clear where this description would go -- we don't really have a document that describes this overall system and how it might be implemented today . Right=E2=80=A6 I started reviewing the documents with BGP-LS extensions for SR=E2=80=A6sta= rting with draft-ietf-idr-bgp-ls-segment-routing-ext, which is the first BGP-LS extensions document to be sent for Publication where the application is explicitly to "construct the end-to-end path (with its associated SIDs) that need to be applied to an incoming packet to achieve the desired end-to-end forwarding=E2=80=9D. All other BGP-LS extension documents have = in general followed the =E2=80=9Cinformative=E2=80=9D tone of rfc7752. I don=E2=80=99t necessarily think that the description of the system belong= s there=E2=80=A6but there=E2=80=99s no other place to put it, at least not cu= rrently. The SR Problem Statement (rfc7855) and the SR Architecture (rfc8402) both just make general statements about the need to support centralized and hybrid (and distributed, of course) control planes =E2=80=94 they don=E2=80=99t go= into more specifics=E2=80=A6 =E2=80=A6 Alvaro. --00000000000050733d057ea70b98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On January 3, 2019 at 5:40:23 PM, Rob Shakir (robjs@google.com) wrote:

Describing these compromises is, of course, a good idea. However, = it's not clear where this description would go -- we don't really h= ave a document that describes this overall system and how it might be imple= mented=C2=A0today.=C2=A0

= Right=E2=80=A6

I started reviewing the documents with BGP-L= S extensions for SR=E2=80=A6starting with draft-ietf-idr-bgp-ls-segment-rou= ting-ext, which is the first BGP-LS extensions document to be sent for Publ= ication where the application is explicitly to "construct the end-to-e= nd path (with its associated SIDs) that need to be applied to an incoming p= acket to achieve the desired end-to-end forwarding=E2=80=9D.=C2=A0 All othe= r BGP-LS extension documents have in general followed the =E2=80=9Cinformat= ive=E2=80=9D tone of rfc7752.

I don=E2=80=99t necessarily think that the description= of the system belongs there=E2=80=A6but there=E2=80=99s no other place to = put it, at least not currently.=C2=A0 The SR Problem Statement (rfc7855) an= d the SR Architecture (rfc8402) both just make general statements about the= need to support centralized and hybrid (and distributed, of course) contro= l planes =E2=80=94 they don=E2=80=99t go into more specifics=E2=80=A6

<= /div>
=E2=80=A6

=
Alvaro.
--00000000000050733d057ea70b98-- From nobody Fri Jan 4 12:48:50 2019 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 581FB124408 for ; Fri, 4 Jan 2019 12:48:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.501 X-Spam-Level: X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 UluLlLXCRerD for ; Fri, 4 Jan 2019 12:48:39 -0800 (PST) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (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 457711200D7 for ; Fri, 4 Jan 2019 12:48:39 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id c14so37733351wrr.0 for ; Fri, 04 Jan 2019 12:48:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=t0eNXsMVl6EEqxRa/LsVnX5Nun4dEIhXsNuI25GIeKE=; b=nKWmVHxJiS5OBJMaKhH+6v4w4ePHRIYUcq3jsDPAf3vInwgLeMtenf8x9IQlMnv6bK Sn3d/M84idE1U3TREkg7xXjss676tXM/ZXqpZuWhD3lDd+XmsN/mFsiLXflMScWxxTCS MquSMRExobYWs3zz81F5tNJFXEtnuxlZSkXEspMpKv/d83KcinhOTopCyzHS9Xu0Sb+r w22K0cbmQ6JOKkaMSV8M3NKOBnQ+COHRPEflUPNN9RYROapiaRw3PA2w2AoXBIao9g+R k/xf6U34Y4qFq4i6pVMdR65ZFfNacmeQbfx2y/bPeAGmutoGuqXWlB5jqe4p/YwCd2Im qJAg== 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=t0eNXsMVl6EEqxRa/LsVnX5Nun4dEIhXsNuI25GIeKE=; b=pipKkBrmcjO5gw9eJfkZtEIAmiXkfiYjI1E/irskOfrHaXWy+JjS5YQByK5YFU9R/1 UJ9CQm2NX1xQ2jAr6JoyuISOLdka7eZrc4mBGUOm0bUxqaM9bYz8j97i3/NdaQLypV0C LJvWeq3seC4Znx9YfxcWK8KZTDnZJnz9zx/EZ8K5goJ9o9mNOLvrnR+r1WjyZ/kX/+SH b0dvceZuCNr8LuMGJ0mVF3zo6GR4Fw0brRMB+KnQNqrMRgleM/0b4hpXbHlfq8oDZ+Zf Zth5vk/emcts9ZHv/P0Mu4crhKLtC9lYqNW3wfVVuMXuDGKxUSN+udseiQH3V19JUbKA FJ5Q== X-Gm-Message-State: AJcUukc0vJBMbbtihO6bb421tmwkpI3mrRSSbmpMDv7doeuRO6HtYU4b A3uCJo7CMwjm7WOHxFmyZtLC78u/B8n/EcNrZoGDXQ== X-Google-Smtp-Source: ALg8bN5kYVRHW/WIJucsQkAiP4z/wi7DWEjif50N7idxu8EhCY8k/K9EZBHHPh4hLIAuFqk6BLNFrmgyPC7etr4IbXg= X-Received: by 2002:a5d:528e:: with SMTP id c14mr44535256wrv.236.1546634917255; Fri, 04 Jan 2019 12:48:37 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rob Shakir Date: Fri, 4 Jan 2019 12:48:25 -0800 Message-ID: To: Alvaro Retana Cc: "idr@ietf. org" , Robert Raszuk , SPRING WG Content-Type: multipart/alternative; boundary="000000000000d7934e057ea800fb" Archived-At: Subject: Re: [spring] Error Handling for BGP-LS with Segment Routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 20:48:42 -0000 --000000000000d7934e057ea800fb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The alternative approach is to have an "Operational Considerations" section of draft-ietf-idr-bgp-ls-segment-routing-ext that simply points out this consideration. i.e., something like: "Since the error handling approach defined in RFC7752 specifies 'attribute discard' as the error handling mechanism for BGP-LS, systems implemented using BGP-LS for discovery of topological attributes used for path calculation MUST consider their mode of operation based on incomplete data being received (due to attribute discard). If an assumption of strong consistency between the BGP-LS receiver, and the network's topology is made, system designers and operators SHOULD consider means to detect erroneous attributes being discarded on a session and act accordingly." Taking this approach doesn't say "hey, let's change this", and also doesn't say "here's what the system should do", it just makes sure designers and operators are aware of the consideration. That said, this is rather implementation specific. r. On Fri, Jan 4, 2019 at 11:39 AM Alvaro Retana wrote: > On January 3, 2019 at 5:40:23 PM, Rob Shakir (robjs@google.com) wrote: > > Describing these compromises is, of course, a good idea. However, it's no= t > clear where this description would go -- we don't really have a document > that describes this overall system and how it might be implemented today > . > > > Right=E2=80=A6 > > I started reviewing the documents with BGP-LS extensions for SR=E2=80=A6s= tarting > with draft-ietf-idr-bgp-ls-segment-routing-ext, which is the first BGP-LS > extensions document to be sent for Publication where the application is > explicitly to "construct the end-to-end path (with its associated SIDs) > that need to be applied to an incoming packet to achieve the desired > end-to-end forwarding=E2=80=9D. All other BGP-LS extension documents hav= e in > general followed the =E2=80=9Cinformative=E2=80=9D tone of rfc7752. > > I don=E2=80=99t necessarily think that the description of the system belo= ngs > there=E2=80=A6but there=E2=80=99s no other place to put it, at least not = currently. The SR > Problem Statement (rfc7855) and the SR Architecture (rfc8402) both just > make general statements about the need to support centralized and hybrid > (and distributed, of course) control planes =E2=80=94 they don=E2=80=99t = go into more > specifics=E2=80=A6 > > =E2=80=A6 > > Alvaro. > --000000000000d7934e057ea800fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The alternative approach is to have an "Operational C= onsiderations" section of draft-ietf-idr-bgp-ls-segment-routing-ext th= at simply points out this consideration. i.e., something like:

"Since the error handling approach defined in RFC7752 specifies= 'attribute discard' as the error handling mechanism for BGP-LS, sy= stems implemented using BGP-LS for discovery of topological attributes used= for path calculation MUST consider their mode of operation based on incomp= lete data being received (due to attribute discard). If an assumption of st= rong consistency between the BGP-LS receiver, and the network's topolog= y is made, system designers and operators SHOULD consider means to detect e= rroneous attributes being discarded on a session and act accordingly."=

Taking this approach doesn't say "hey, l= et's change this", and also doesn't say "here's what = the system should do", it just makes sure designers and operators are = aware of the consideration. That said, this is rather implementation specif= ic.

r.

<= div dir=3D"ltr">On Fri, Jan 4, 2019 at 11:39 AM Alvaro Retana <aretana.ietf@gmail.com> wrote:
<= div style=3D"margin:0px">On January 3, 2019 at 5:4= 0:23 PM, Rob Shakir (= robjs@google.com) wrote:

Describing these compromises is, of course, a good idea. However, it'= ;s not clear where this description would go -- we don't really have a = document that describes this overall system and how it might be implemented= =C2=A0today= .=C2=A0

Right=E2=80=A6

I s= tarted reviewing the documents with BGP-LS extensions for SR=E2=80=A6starti= ng with draft-ietf-idr-bgp-ls-segment-routing-ext, which is the first BGP-L= S extensions document to be sent for Publication where the application is e= xplicitly to "construct the end-to-end path (with its associated SIDs)= that need to be applied to an incoming packet to achieve the desired end-t= o-end forwarding=E2=80=9D.=C2=A0 All other BGP-LS extension documents have = in general followed the =E2=80=9Cinformative=E2=80=9D tone of rfc7752.

I don=E2=80=99t necessarily think that the d= escription of the system belongs there=E2=80=A6but there=E2=80=99s no other= place to put it, at least not currently.=C2=A0 The SR Problem Statement (r= fc7855) and the SR Architecture (rfc8402) both just make general statements= about the need to support centralized and hybrid (and distributed, of cour= se) control planes =E2=80=94 they don=E2=80=99t go into more specifics=E2= =80=A6

=E2=80=A6

Alvaro.
<= /div>
--000000000000d7934e057ea800fb-- From nobody Fri Jan 4 14:05:52 2019 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FADD130E9B; Fri, 4 Jan 2019 14:05:50 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 uhwGPYuhh5ek; Fri, 4 Jan 2019 14:05:48 -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 866A9130E90; Fri, 4 Jan 2019 14:05:48 -0800 (PST) Received: by mail-oi1-x22a.google.com with SMTP id y1so31531559oie.12; Fri, 04 Jan 2019 14:05:48 -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; bh=6XALTTmsSKz1gwkA6jV+737gLK5y7ndXPqWbkPas3uA=; b=fhttuqhdGLg7ON2+OMii7wxZMFFHmK98p3VPZ/ySjQqanti9iv6858Bix012HkNSbR 3kAsHdPADVme9ltBkTpTfGH4nFVezfSUHTCVykb+LakasuWwEmwFsnwRa12QczEZQEUj 5av55VxyoaTJIBtHnfcpVPpb7WfL/TYB//c8eaKwVvEXb/ZV5RPj06yWt9qyJ1X82H7S W5s0tWtRhcWTKTVsYWS6JiCU6bUDuVaDDsZNsAgw32WJCNEQ7HaxHLFHy51aCI6GG3HC TzW8htX+was9PION3rdsAxh+mGwYn65tYigCFtBq8VGVyp3nzxHoYv+AxjbSSbj2FZud lBqw== 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; bh=6XALTTmsSKz1gwkA6jV+737gLK5y7ndXPqWbkPas3uA=; b=tWwbX8gAN0YyHZvFvPngGZSd2XOpxJhcKBAcl8YGj/9hpEaw2SVwkyrrVI6Xa1JA8S zKdfp/AozhznrcOGiV3l9oRziEUq9b5ilDLxXS0bdXgRTBeyZ1NaWXTehcjE+VAzt8OZ A/hk4wmNwOuXlIc4H/hgw9tb6+MYl+vgR3q/ngY1FlORetVg6WuROsn3dWOefXi2Kq9p 89gga+j9mx1GSNYnYt/PfY0ZLw/c+yt/Pg+BXrTw0v7EKEkBT3CFHDEBIK4aN32KhlmL f9aSHrdAHmZ3uM0ZAHmhYVf8triTtPDhkxettii1VDoePdQY4SDhu2IRgsxALkmE5KEp DV7w== X-Gm-Message-State: AA+aEWab+E+efTiY6jnSKQ6kxZZh/E0kr7gMNDmsB9iF48JdAu7m27O7 NBlCB+tYRWjbUf0lvHhTqyuryY3o98LMrT+fII4= X-Google-Smtp-Source: AFSGD/UEUPLkH9j5HaT4CA7N/Oeue7GwimoY7nD9Gb/6rLHn5xANmUTG5InaaD0t9GKMlVm+Bfts6WfX/n4E0SPg9hk= X-Received: by 2002:aca:b6c3:: with SMTP id g186mr37840978oif.289.1546639547800; Fri, 04 Jan 2019 14:05:47 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 4 Jan 2019 14:05:47 -0800 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Fri, 4 Jan 2019 14:05:47 -0800 Message-ID: To: Rob Shakir Cc: SPRING WG , "idr@ietf. org" , Robert Raszuk Content-Type: multipart/alternative; boundary="000000000000d7a3ae057ea91401" Archived-At: Subject: Re: [spring] Error Handling for BGP-LS with Segment Routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2019 22:05:50 -0000 --000000000000d7a3ae057ea91401 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On January 4, 2019 at 3:48:38 PM, Rob Shakir (robjs@google.com) wrote: The alternative approach is to have an "Operational Considerations" section of draft-ietf-idr-bgp-ls-segment-routing-ext that simply points out this consideration. i.e., something like: We would need something like it in every bgp-ls-sr draft=E2=80=A6or a point= er back to draft-ietf-idr-bgp-ls-segment-routing-ext... "Since the error handling approach defined in RFC7752 specifies 'attribute discard' as the error handling mechanism for BGP-LS, systems implemented using BGP-LS for discovery of topological attributes used for path calculation MUST consider their mode of operation based on incomplete data being received (due to attribute discard). If an assumption of strong consistency between the BGP-LS receiver, and the network's topology is made, system designers and operators SHOULD consider means to detect erroneous attributes being discarded on a session and act accordingly." Taking this approach doesn't say "hey, let's change this", and also doesn't say "here's what the system should do", it just makes sure designers and operators are aware of the consideration. That said, this is rather implementation specific. [This is probably not the right place to wordsmith, but I don=E2=80=99t kno= w how =E2=80=9CMUST/SHOULD consider=E2=80=9D can be normatively enforced.] Because it is implementation/deployment specific, some examples of the cases where there could be more (or less) potential issues would be ideal. As Robert=E2=80=99s example: "In my view SR controller is mainly used as optimization not as critical element - well at least in the deployment models I would personally recommend to use.=E2=80=9D This last part could end up making the document significantly longer=E2=80= =A6and it doesn=E2=80=99t really give me a warm fuzzy feeling adding it after WGLC=E2= =80=A6to an idr document...and without it being properly reviewed by the spring WG. But these are details we can take care of as we move forward [*]. Thanks! Alvaro. [*] I haven=E2=80=99t finished my AD Review of draft-ietf-idr-bgp-ls-segment-routing-ext. --000000000000d7a3ae057ea91401 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On January 4, 2019 at 3:48:38 PM, Rob Shakir (robjs@google.com) wrote:

The alternative approach is to have an "Operational Consid= erations" section of draft-ietf-idr-bgp-ls-segment-routing-ext that si= mply points out this consideration. i.e., something like:

We would need something like it in every bgp-ls-sr = draft=E2=80=A6or a pointer back to=C2=A0draft-ietf-idr-bgp-ls-segment-ro= uting-ext...

"Since the error h= andling approach defined in RFC7752 specifies 'attribute discard' a= s the error handling mechanism for BGP-LS, systems implemented using BGP-LS= for discovery of topological attributes used for path calculation MUST con= sider their mode of operation based on incomplete data being received (due = to attribute discard). If an assumption of strong consistency between the B= GP-LS receiver, and the network's topology is made, system designers an= d operators SHOULD consider means to detect erroneous attributes being disc= arded on a session and act accordingly."

Taking this approach doesn't say "hey, let's change this&qu= ot;, and also doesn't say "here's what the system should do&qu= ot;, it just makes sure designers and operators are aware of the considerat= ion. That said, this is rather implementation specific.

[This is probably = not the right place to wordsmith, but I don=E2=80=99t know how =E2=80=9CMUS= T/SHOULD consider=E2=80=9D can be normatively enforced.]

Because it is implementation/deployment specific, some examples of t= he cases where there could be more (or less) potential issues would be idea= l.=C2=A0 As Robert=E2=80=99s example: "In my view SR controller is mai= nly used as optimization not as critical element - well at least in the dep= loyment models I would personally recommend to use.=E2=80=9D

=
This last part could end up making the document significantly lo= nger=E2=80=A6and it doesn=E2=80=99t really give me a warm fuzzy feeling add= ing it after WGLC=E2=80=A6to an idr document...and without it being properl= y reviewed by the spring WG.=C2=A0 But these are details we can take care o= f as we move forward [*].

Thanks!

Alvaro.

[*] I haven=E2=80=99t finished my= AD Review of=C2=A0draft-ietf-idr-bgp-ls-segment-routing-ext.

--000000000000d7a3ae057ea91401-- From nobody Mon Jan 7 10:08:39 2019 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 818B8130FE8; Mon, 7 Jan 2019 10:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 3xaLau0avlwe; Mon, 7 Jan 2019 10:08:13 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 4D4841277BB; Mon, 7 Jan 2019 10:08:13 -0800 (PST) Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.22/8.16.0.22) with SMTP id x07I6v1l004806; Mon, 7 Jan 2019 13:08:11 -0500 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0083689.ppops.net-00191d01. with ESMTP id 2pvasxt4y5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 07 Jan 2019 13:08:11 -0500 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x07I8AlW027406; Mon, 7 Jan 2019 13:08:11 -0500 Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [135.66.87.52]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x07I86XA027308; Mon, 7 Jan 2019 13:08:06 -0500 Received: from zlp27125.vci.att.com (zlp27125.vci.att.com [127.0.0.1]) by zlp27125.vci.att.com (Service) with ESMTP id 59F2E16A3EE; Mon, 7 Jan 2019 18:08:06 +0000 (GMT) Received: from MISOUT7MSGHUBAG.ITServices.sbc.com (unknown [130.9.129.151]) by zlp27125.vci.att.com (Service) with ESMTPS id 46C7C16A3EB; Mon, 7 Jan 2019 18:08:06 +0000 (GMT) Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.198]) by MISOUT7MSGHUBAG.ITServices.sbc.com ([130.9.129.151]) with mapi id 14.03.0415.000; Mon, 7 Jan 2019 13:08:05 -0500 From: "UTTARO, JAMES" To: Alvaro Retana , Rob Shakir CC: "idr@ietf. org" , SPRING WG , Robert Raszuk Thread-Topic: [Idr] [spring] Error Handling for BGP-LS with Segment Routing Thread-Index: AQHUmUmKLQ3wohQ48E28zwp2F07UtqWeew+AgAAQwACAAV/7gIAESCtA Date: Mon, 7 Jan 2019 18:08:05 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.91.76.93] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F4D7E7B2BMISOUT7MSGUSRCD_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-01-07_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1901070155 Archived-At: Subject: Re: [spring] [Idr] Error Handling for BGP-LS with Segment Routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2019 18:08:16 -0000 --_000_B17A6910EEDD1F45980687268941550F4D7E7B2BMISOUT7MSGUSRCD_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSByZXF1aXJlbWVudHMgZG9jIHdvdWxkIGJlIGEgcGxhY2UgdG8gZGVzY3JpYmUgdGhlIGJlaGF2 aW9yIG9mIHRoZSDigJxzeXN0ZW3igJ0uDQoNCkppbSBVdHRhcm8NCg0KRnJvbTogSWRyIDxpZHIt Ym91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEFsdmFybyBSZXRhbmENClNlbnQ6IEZyaWRh eSwgSmFudWFyeSAwNCwgMjAxOSAyOjQwIFBNDQpUbzogUm9iIFNoYWtpciA8cm9ianNAZ29vZ2xl LmNvbT4NCkNjOiBpZHJAaWV0Zi4gb3JnIDxpZHJAaWV0Zi5vcmc+OyBTUFJJTkcgV0cgPHNwcmlu Z0BpZXRmLm9yZz47IFJvYmVydCBSYXN6dWsgPHJyYXN6dWtAZ21haWwuY29tPg0KU3ViamVjdDog UmU6IFtJZHJdIFtzcHJpbmddIEVycm9yIEhhbmRsaW5nIGZvciBCR1AtTFMgd2l0aCBTZWdtZW50 IFJvdXRpbmcNCg0KT24gSmFudWFyeSAzLCAyMDE5IGF0IDU6NDA6MjMgUE0sIFJvYiBTaGFraXIg KHJvYmpzQGdvb2dsZS5jb208bWFpbHRvOnJvYmpzQGdvb2dsZS5jb20+KSB3cm90ZToNCg0KRGVz Y3JpYmluZyB0aGVzZSBjb21wcm9taXNlcyBpcywgb2YgY291cnNlLCBhIGdvb2QgaWRlYS4gSG93 ZXZlciwgaXQncyBub3QgY2xlYXIgd2hlcmUgdGhpcyBkZXNjcmlwdGlvbiB3b3VsZCBnbyAtLSB3 ZSBkb24ndCByZWFsbHkgaGF2ZSBhIGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIHRoaXMgb3ZlcmFs bCBzeXN0ZW0gYW5kIGhvdyBpdCBtaWdodCBiZSBpbXBsZW1lbnRlZCB0b2RheTxodHRwczovL3Vy bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fYWlybWFpbC5jYWxlbmRh cl8yMDE5LTJEMDEtMkQwNC0yNTIwMTItM0EwMC0zQTAwLTI1MjBFU1QmZD1Ed01GYVEmYz1MRlla LW85X0hVTWVNVFNRaWN2aklnJnI9czdaekI0SmJQdjNuWXVvU3g1R3k4USZtPVlQa01sQXpnRW1W NlVISTRsR0hlNWRRLU45M0pmZUZ1SEFuU042R2NIbEEmcz1yT2tZeE03ZnYxRWFpYlUwWm1hWm1U OUo0ekdLRzgxS05wSEl0Um5QNUlJJmU9Pi4NCg0KUmlnaHTigKYNCg0KSSBzdGFydGVkIHJldmll d2luZyB0aGUgZG9jdW1lbnRzIHdpdGggQkdQLUxTIGV4dGVuc2lvbnMgZm9yIFNS4oCmc3RhcnRp bmcgd2l0aCBkcmFmdC1pZXRmLWlkci1iZ3AtbHMtc2VnbWVudC1yb3V0aW5nLWV4dCwgd2hpY2gg aXMgdGhlIGZpcnN0IEJHUC1MUyBleHRlbnNpb25zIGRvY3VtZW50IHRvIGJlIHNlbnQgZm9yIFB1 YmxpY2F0aW9uIHdoZXJlIHRoZSBhcHBsaWNhdGlvbiBpcyBleHBsaWNpdGx5IHRvICJjb25zdHJ1 Y3QgdGhlIGVuZC10by1lbmQgcGF0aCAod2l0aCBpdHMgYXNzb2NpYXRlZCBTSURzKSB0aGF0IG5l ZWQgdG8gYmUgYXBwbGllZCB0byBhbiBpbmNvbWluZyBwYWNrZXQgdG8gYWNoaWV2ZSB0aGUgZGVz aXJlZCBlbmQtdG8tZW5kIGZvcndhcmRpbmfigJ0uICBBbGwgb3RoZXIgQkdQLUxTIGV4dGVuc2lv biBkb2N1bWVudHMgaGF2ZSBpbiBnZW5lcmFsIGZvbGxvd2VkIHRoZSDigJxpbmZvcm1hdGl2ZeKA nSB0b25lIG9mIHJmYzc3NTIuDQoNCkkgZG9u4oCZdCBuZWNlc3NhcmlseSB0aGluayB0aGF0IHRo ZSBkZXNjcmlwdGlvbiBvZiB0aGUgc3lzdGVtIGJlbG9uZ3MgdGhlcmXigKZidXQgdGhlcmXigJlz IG5vIG90aGVyIHBsYWNlIHRvIHB1dCBpdCwgYXQgbGVhc3Qgbm90IGN1cnJlbnRseS4gIFRoZSBT UiBQcm9ibGVtIFN0YXRlbWVudCAocmZjNzg1NSkgYW5kIHRoZSBTUiBBcmNoaXRlY3R1cmUgKHJm Yzg0MDIpIGJvdGgganVzdCBtYWtlIGdlbmVyYWwgc3RhdGVtZW50cyBhYm91dCB0aGUgbmVlZCB0 byBzdXBwb3J0IGNlbnRyYWxpemVkIGFuZCBoeWJyaWQgKGFuZCBkaXN0cmlidXRlZCwgb2YgY291 cnNlKSBjb250cm9sIHBsYW5lcyDigJQgdGhleSBkb27igJl0IGdvIGludG8gbW9yZSBzcGVjaWZp Y3PigKYNCg0K4oCmDQoNCkFsdmFyby4NCg== --_000_B17A6910EEDD1F45980687268941550F4D7E7B2BMISOUT7MSGUSRCD_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uYXBw bGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFj ZTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojNDQ1NDZBOw0KCWZv bnQtd2VpZ2h0OmJvbGQ7DQoJZm9udC1zdHlsZTppdGFsaWM7DQoJdGV4dC1kZWNvcmF0aW9uOm5v bmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDU0NkEiPkEg cmVxdWlyZW1lbnRzIGRvYyB3b3VsZCBiZSBhIHBsYWNlIHRvIGRlc2NyaWJlIHRoZSBiZWhhdmlv ciBvZiB0aGUg4oCcc3lzdGVt4oCdLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDU0NkEiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiM0NDU0NkEiPkppbSBVdHRhcm88bzpwPjwvbzpwPjwvc3Bh bj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJj b2xvcjojNDQ1NDZBIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7 cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9t OjwvYj4gSWRyICZsdDtpZHItYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwv Yj4NCkFsdmFybyBSZXRhbmE8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5LCBKYW51YXJ5IDA0LCAy MDE5IDI6NDAgUE08YnI+DQo8Yj5Ubzo8L2I+IFJvYiBTaGFraXIgJmx0O3JvYmpzQGdvb2dsZS5j b20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBpZHJAaWV0Zi4gb3JnICZsdDtpZHJAaWV0Zi5vcmcmZ3Q7 OyBTUFJJTkcgV0cgJmx0O3NwcmluZ0BpZXRmLm9yZyZndDs7IFJvYmVydCBSYXN6dWsgJmx0O3Jy YXN6dWtAZ21haWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW0lkcl0gW3Nwcmlu Z10gRXJyb3IgSGFuZGxpbmcgZm9yIEJHUC1MUyB3aXRoIFNlZ21lbnQgUm91dGluZzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5PbiBKYW51YXJ5IDMsIDIwMTkgYXQgNTo0MDoyMyBQTSwgUm9iIFNoYWtpciAoPGEgaHJlZj0i bWFpbHRvOnJvYmpzQGdvb2dsZS5jb20iPnJvYmpzQGdvb2dsZS5jb208L2E+KSB3cm90ZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFj aztiYWNrZ3JvdW5kOndoaXRlIj5EZXNjcmliaW5nIHRoZXNlIGNvbXByb21pc2VzIGlzLCBvZiBj b3Vyc2UsIGEgZ29vZCBpZGVhLiBIb3dldmVyLCBpdCdzIG5vdCBjbGVhciB3aGVyZSB0aGlzIGRl c2NyaXB0aW9uIHdvdWxkIGdvIC0tIHdlIGRvbid0IHJlYWxseSBoYXZlIGEgZG9jdW1lbnQNCiB0 aGF0IGRlc2NyaWJlcyB0aGlzIG92ZXJhbGwgc3lzdGVtIGFuZCBob3cgaXQgbWlnaHQgYmUgaW1w bGVtZW50ZWQ8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cC0zQV9fYWlybWFpbC5jYWxlbmRhcl8yMDE5LTJEMDEt MkQwNC0yNTIwMTItM0EwMC0zQTAwLTI1MjBFU1QmYW1wO2Q9RHdNRmFRJmFtcDtjPUxGWVotbzlf SFVNZU1UU1FpY3ZqSWcmYW1wO3I9czdaekI0SmJQdjNuWXVvU3g1R3k4USZhbXA7bT1ZUGtNbEF6 Z0VtVjZVSEk0bEdIZTVkUS1OOTNKZmVGdUhBblNONkdjSGxBJmFtcDtzPXJPa1l4TTdmdjFFYWli VTBabWFabVQ5SjR6R0tHODFLTnBISXRSblA1SUkmYW1wO2U9Ij50b2RheTwvYT48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2s7YmFja2dyb3VuZDp3aGl0ZSI+LiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlJp Z2h04oCmPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5J IHN0YXJ0ZWQgcmV2aWV3aW5nIHRoZSBkb2N1bWVudHMgd2l0aCBCR1AtTFMgZXh0ZW5zaW9ucyBm b3IgU1LigKZzdGFydGluZyB3aXRoIGRyYWZ0LWlldGYtaWRyLWJncC1scy1zZWdtZW50LXJvdXRp bmctZXh0LCB3aGljaCBpcyB0aGUgZmlyc3QgQkdQLUxTIGV4dGVuc2lvbnMgZG9jdW1lbnQgdG8N CiBiZSBzZW50IGZvciBQdWJsaWNhdGlvbiB3aGVyZSB0aGUgYXBwbGljYXRpb24gaXMgZXhwbGlj aXRseSB0byAmcXVvdDtjb25zdHJ1Y3QgdGhlIGVuZC10by1lbmQgcGF0aCAod2l0aCBpdHMgYXNz b2NpYXRlZCBTSURzKSB0aGF0IG5lZWQgdG8gYmUgYXBwbGllZCB0byBhbiBpbmNvbWluZyBwYWNr ZXQgdG8gYWNoaWV2ZSB0aGUgZGVzaXJlZCBlbmQtdG8tZW5kIGZvcndhcmRpbmfigJ0uJm5ic3A7 IEFsbCBvdGhlciBCR1AtTFMgZXh0ZW5zaW9uIGRvY3VtZW50cyBoYXZlDQogaW4gZ2VuZXJhbCBm b2xsb3dlZCB0aGUg4oCcaW5mb3JtYXRpdmXigJ0gdG9uZSBvZiByZmM3NzUyLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSBkb27igJl0IG5lY2Vzc2Fy aWx5IHRoaW5rIHRoYXQgdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSBzeXN0ZW0gYmVsb25ncyB0aGVy ZeKApmJ1dCB0aGVyZeKAmXMgbm8gb3RoZXIgcGxhY2UgdG8gcHV0IGl0LCBhdCBsZWFzdCBub3Qg Y3VycmVudGx5LiZuYnNwOyBUaGUgU1IgUHJvYmxlbSBTdGF0ZW1lbnQgKHJmYzc4NTUpDQogYW5k IHRoZSBTUiBBcmNoaXRlY3R1cmUgKHJmYzg0MDIpIGJvdGgganVzdCBtYWtlIGdlbmVyYWwgc3Rh dGVtZW50cyBhYm91dCB0aGUgbmVlZCB0byBzdXBwb3J0IGNlbnRyYWxpemVkIGFuZCBoeWJyaWQg KGFuZCBkaXN0cmlidXRlZCwgb2YgY291cnNlKSBjb250cm9sIHBsYW5lcyDigJQgdGhleSBkb27i gJl0IGdvIGludG8gbW9yZSBzcGVjaWZpY3PigKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPuKApjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+QWx2YXJvLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B17A6910EEDD1F45980687268941550F4D7E7B2BMISOUT7MSGUSRCD_-- From nobody Tue Jan 8 06:33:54 2019 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C48C1200B3; Tue, 8 Jan 2019 06:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 Qa_Qfc9kE4YS; Tue, 8 Jan 2019 06:33:51 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AFD1124BF6; Tue, 8 Jan 2019 06:33:50 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 43Yvrs10dmzCs14; Tue, 8 Jan 2019 15:33:49 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 43Yvrr71ZszDq7C; Tue, 8 Jan 2019 15:33:48 +0100 (CET) Received: from OPEXCAUBM33.corporate.adroot.infra.ftgroup (10.114.13.70) by OPEXCLILM32.corporate.adroot.infra.ftgroup (10.114.31.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 8 Jan 2019 15:33:48 +0100 Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBM33.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0415.000; Tue, 8 Jan 2019 15:33:48 +0100 From: To: Rob Shakir , Alvaro Retana CC: "idr@ietf. org" , SPRING WG , Robert Raszuk Thread-Topic: [spring] Error Handling for BGP-LS with Segment Routing Thread-Index: AQHUo6zyYdBKbJCKj0KbT0kumtYWPqWeEnMAgAdbqMA= Date: Tue, 8 Jan 2019 14:33:48 +0000 Message-ID: <1830_1546958029_5C34B4CD_1830_110_1_53C29892C857584299CBF5D05346208A4898A07A@OPEXCAUBM43.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A4898A07AOPEXCAUBM43corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Error Handling for BGP-LS with Segment Routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 14:33:54 -0000 --_000_53C29892C857584299CBF5D05346208A4898A07AOPEXCAUBM43corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQWx2YXJvLCBhbGwNCg0KQWxzbyBzcGVha2luZyBhcyBhIFdHIHBhcnRpY2lwYW50DQoNCkZv ciB3aGF0IGl04oCZcyB3b3J0aCwgKzEgdG8gUm9i4oCZcyBlbWFpbC4NCg0KPiBGcm9tOiBzcHJp bmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFsdmFybyBS ZXRhbmENCj4gU2VudDogVGh1cnNkYXksIEphbnVhcnkgMDMsIDIwMTkgMTA6NDAgUE0NClvigKZd DQo+IEkgZnVsbHkgcmVhbGl6ZSB0aGF0IEkgbWF5IGJlIHRoZSBvbmx5IG9uZSB3aG8gdGhpbmtz IHRoZXJl4oCZcyBhbiBpc3N1ZeKApg0KDQpJIGRvbuKAmXQgdGhpbmsgc28uIEJ1dCBhdCBsZWFz dCB0aGUgc3BlY2lmaWNhdGlvbiBkb2VzIGRlZmluZSB0aGUgYmVoYXZpb3IgaW4gdGhpcyBlcnJv ciBjb25kaXRpb24uIEFuZCBJIGRvbuKAmXQgdGhpbmsgdGhhdCB0aGVyZSBpcyBhIHBlcmZlY3Qg c29sdXRpb246IFJGQyA3NjA2IGJlaGF2aW9yIHNlZW1zIGdvb2QgZW5vdWdoIHRvIG1lIGFuZCBJ TUhPLCBnb2luZyBmdXJ0aGVyIHdvdWxkIHJlcXVpcmUgZGlzY3Vzc2luZyBhbHRlcm5hdGl2ZSB0 ZWNobmljYWwgcHJvcG9zYWxzIChzb2x1dGlvbnMpIHJhdGhlciB0aGFuIGp1c3QgcmFpc2luZyB0 aGUgcHJvYmxlbS4NCg0KQnV0IEnigJltIHdvbmRlcmluZyB3aHkgZXJyb3IgaGFuZGxpbmcgaXMg dGhhdCBzcGVjaWZpYyB0byBCR1AtTFMuIFdoeSBpcyB0aGF0IHBvaW50IG5vdCBiZWVuIHJhaXNl ZCBvbiwgbGV04oCZcyBzYXksIGRyYWZ0LWlldGYtb3NwZi1vc3BmdjMtc2VnbWVudC1yb3V0aW5n LWV4dGVuc2lvbnMgd2hpY2ggaXMgY3VycmVudGx5IHVuZGVyIElFU0cgcmV2aWV3PyBJIGNhbiBz ZWUgdGhhdCB0aGUgc3BlY2lmaWMgYXJlIChhIGJpdCkgZGlmZmVyZW50LCBidXQgdGhlIGJpZyBw aWN0dXJlIHNlZW1zIHRoZSBzYW1lOiB0aGUgaW5mb3JtYXRpb24gaXMgaW5jb21wbGV0ZSwgaG93 IGRvIHdlIGhhbmRsZSB0aGlzPw0KVGhlbiwgSeKAmW0gbm90IHN1cmUgdGhhdCB0aGUgcHJvYmxl bSBpcyBzcGVjaWZpYy9saW1pdGVkIHRvIFNSL1NJRCBpbmZvcm1hdGlvbi4NCg0KVGhhbmtzLA0K Q2hlZXJzLA0KLS1CcnVubw0KDQpGcm9tOiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvYiBTaGFraXINClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5 IDAzLCAyMDE5IDExOjQwIFBNDQpUbzogQWx2YXJvIFJldGFuYQ0KQ2M6IGlkckBpZXRmLiBvcmc7 IFNQUklORyBXRzsgUm9iZXJ0IFJhc3p1aw0KU3ViamVjdDogUmU6IFtzcHJpbmddIEVycm9yIEhh bmRsaW5nIGZvciBCR1AtTFMgd2l0aCBTZWdtZW50IFJvdXRpbmcNCg0KSGkgQWx2YXJvLA0KDQpB bHNvIHNwZWFraW5nIGFzIGEgV0cgcGFydGljaXBhbnQgOi0pDQpPbiBUaHUsIEphbiAzLCAyMDE5 IGF0IDE6NDAgUE0gQWx2YXJvIFJldGFuYSA8YXJldGFuYS5pZXRmQGdtYWlsLmNvbTxtYWlsdG86 YXJldGFuYS5pZXRmQGdtYWlsLmNvbT4+IHdyb3RlOg0KQkdQLUxTIG9ubHkgZGVmaW5lcyBhIG1l Y2hhbmlzbSB0aHJvdWdoIHdoaWNoIGl0IG1heSBtaXNzIGluZm9ybWF0aW9uLCBidXQgbm90IGhv dyB0byBoYW5kbGUgaXQg4oCUIG9yIG1heWJlIGl0IGRvZXMgKD8pOiBieSB1c2luZyBhdHRyaWJ1 dGUgZGlzY2FyZCBpdCBqdXN0IGFjY2VwdHMgdGhhdCB0aGUgaW5mb3JtYXRpb24gbWlnaHQgYmUg bWlzc2luZyBnb2luZyBmb3J3YXJk4oCmYW5kIGRvZXNu4oCZdCBhdHRlbXB0IHRvIGRvIGFueXRo aW5nLiAgTWF5YmUgdGhpcyBxdW90ZSBpcyB0cnVlOiAiRG9pbmcgTm90aGluZyBPZnRlbiBMZWFk cyB0byB0aGUgVmVyeSBCZXN0IFNvbWV0aGluZ+KAnSDigJQgV2lubmllIHRoZSBQb29oDQoNCkkg dGhpbmsgdGhhdCBpdCBkZWZpbmVzICpzb21ldGhpbmcqLCBhbGJlaXQgbm90IGV4cGxpY2l0bHku IEVzc2VudGlhbGx5LCBhcyBJIHJlYWQgaXQsIHdlJ3JlIHNheWluZyAid2hlbiBhbiBhdHRyaWJ1 dGUgZW5jb2RlZCBieSB0aGUgYWR2ZXJ0aXNpbmcgQkdQLUxTIHNvdXJjZSBpcyBpbmNvcnJlY3Qs IHRoZW4gQkdQLUxTIGFzIGEgc3lzdGVtIHdpbGwgcHJlZmVyIHRvIHVzZSBwYXJ0aWFsIGluZm9y bWF0aW9uIiAocGFydGlhbCBpbmZvcm1hdGlvbiwgc2luY2Ugd2UgYXNzdW1lIHRoYXQgc29tZSBp bmZvcm1hdGlvbiBkb2VzIGdldCB0aHJvdWdoLCBzaW5jZSB0aGUgTkxSSSBjb3VsZCBiZSBwYXJz ZWQpLg0KDQpUaGF0IGFjdGlvbiBtYXkgYmUgb2sgaW4gdGhlIGdlbmVyYWwgY2FzZeKApmJ1dCBJ IHRoaW5rIHRoYXQgZG9pbmcgbm90aGluZyBtYXkgbm90IGJlIGVub3VnaC9hcHByb3ByaWF0ZSBm b3IgYW4gYXBwbGljYXRpb24gbGlrZSBTUiwgYmVjYXVzZSBpdCBpcyBleHBsaWNpdGx5IGNhbGN1 bGF0aW5nIHBhdGhz4oCmLg0KDQpUaGUgcG9pbnQgSeKAmW0gdHJ5aW5nIHRvIGJyaW5nIHVwIGlz IG5vdCBuZWNlc3NhcmlseSB0cmVhdC1hcy13aXRoZHJhdyB2cy4gYXR0cmlidXRlIGRpc2NhcmTi gKYuIEJ1dCwgZmlyc3QsIGlzIGF0dHJpYnV0ZSBkaXNjYXJkIGVub3VnaC9hcHByb3ByaWF0ZS9n b29kIGZvciBhIEJHUC1MUyBhcHBsaWNhdGlvbiBzdWNoIGFzIFNSPyAgSWYgaXQgaXNu4oCZdCwg c2Vjb25kLCBpcyB0aGVyZSBhIGRpZmZlcmVudCBhcHByb2FjaCB0aGF0IHdvdWxkIGJlIGJldHRl cj8gIE1heWJlIHdlIHRoZW4gY29tZSB0byBhIHBvaW50IHdoZXJlIHNvbWV0aGluZyBjYW4gY2hh bmdl4oCmb3IgYWNjZXB0IHRoZSBsaW1pdGF0aW9ucyBvZiB0aGUgc3lzdGVtIGFuZCBiZSBjbGVh ciBhYm91dCB0aGVtLiAgSSBmdWxseSByZWFsaXplIHRoYXQgSSBtYXkgYmUgdGhlIG9ubHkgb25l IHdobyB0aGlua3MgdGhlcmXigJlzIGFuIGlzc3Vl4oCmDQoNCk15IHBvaW50IHdhcyByZWFsbHkg dGhlIHNhbWUuLi4gVGhlIHF1ZXN0aW9uIEkgd2FzIHRyeWluZyB0byByYWlzZSBpcyAid2hhdCBp cyB0aGUgYWx0ZXJuYXRpdmUgdGhhdCB5b3Ugd291bGQgc3VnZ2VzdD8iLiBPdGhlciB0ZWNobm9s b2dpZXMgdGhhdCBmdWxmaWxsIHRoZSBzYW1lIHJvbGUgYXMgQkdQLUxTICh0aG9zZSB0aGF0IEkg ZGVzY3JpYmVkKSBkb24ndCB0YWtlIGEgdmVyeSBkaWZmZXJlbnQgYXBwcm9hY2guDQoNCkNsZWFy bHksIGl0J3MgYmFkIHRvIGNhbGN1bGF0ZSBwYXRocyB3aXRoIGluY29tcGxldGUgaW5mb3JtYXRp b24gYWJvdXQgdGhlIHRvcG9sb2d5IG9mIHRoZSBuZXR3b3JrLiBJdCdzIGFsc28gYmFkIHRvIGNh bGN1bGF0ZSB6ZXJvIHBhdGhzIGJlY2F1c2UgeW91IGRpc2NhcmRlZCB0aGUgZW50aXJlIHRvcG9s b2d5IGJhc2VkIG9uIGFuIGVycm9yLiBXZSdyZSBpbi1iZXR3ZWVuIGEgcm9jayBhbmQgYSBoYXJk IHBsYWNlIGluIHRlcm1zIG9mIG1haW50YWluaW5nIHN5c3RlbSBmdW5jdGlvbmFsaXR5IGhlcmUg LS0gYWxsIHN5c3RlbXMgdGhhdCBkbyB0aGUgc2FtZSBhcyBCR1AtTFMgYXJlIGhhdmluZyB0byBt YWtlIHNvbWUgZm9ybSBvZiBjb21wcm9taXNlIGFib3V0IHdoaWNoIGNvbnN0cmFpbnQgKGNvcnJl Y3RuZXNzLCBvciBjb25uZWN0aXZpdHkpIHRoZXkgYXJlIHZpb2xhdGluZy4NCg0KVGhpcyBpcyB3 aHkgSSB3YXMgYXJndWluZyBmb3IgbGVhdmluZyB0aGluZ3MgdW5jaGFuZ2VkIC0tIHRoZSBjb3Jy ZWN0bmVzcyBjb25zdHJhaW50IHNlZW1zIE9LIHRvIHZpb2xhdGUgYnkgZGVmYXVsdC4gSWYgdGhl cmUgYXJlIGRlcGxveW1lbnRzIHdoZXJlIGNvbm5lY3Rpdml0eSBpcyB0aGUgZGVzaXJhYmxlIGNv bnN0cmFpbnQgdG8gdmlvbGF0ZSwgdGhlbiByZWFjdGluZyB0byB0aGUgZmFjdCB0aGF0IGF0dHJp YnV0ZS1kaXNjYXJkIGRpZCBvY2N1ciBpcyBwb3NzaWJsZSAob3Igbm90IGNvbmZpZ3VyaW5nIDc2 MDYgZXJyb3IgaGFuZGxpbmcgaWYgdGhlIGltcGxlbWVudGF0aW9uIHN1cHBvcnRzIHRoaXMpLg0K DQpEZXNjcmliaW5nIHRoZXNlIGNvbXByb21pc2VzIGlzLCBvZiBjb3Vyc2UsIGEgZ29vZCBpZGVh LiBIb3dldmVyLCBpdCdzIG5vdCBjbGVhciB3aGVyZSB0aGlzIGRlc2NyaXB0aW9uIHdvdWxkIGdv IC0tIHdlIGRvbid0IHJlYWxseSBoYXZlIGEgZG9jdW1lbnQgdGhhdCBkZXNjcmliZXMgdGhpcyBv dmVyYWxsIHN5c3RlbSBhbmQgaG93IGl0IG1pZ2h0IGJlIGltcGxlbWVudGVkIHRvZGF5Lg0KDQpD aGVlcnMgYW5kIEhOWSENCnIuDQoNCg0KDQpUaGFua3MhIQ0KDQpBbHZhcm8uDQoNCg0KDQpPbiBE ZWNlbWJlciAyMSwgMjAxOCBhdCAxMToyMzoxNiBBTSwgUm9iIFNoYWtpciAocm9ianNAZ29vZ2xl LmNvbTxtYWlsdG86cm9ianNAZ29vZ2xlLmNvbT4pIHdyb3RlOg0KQWx2YXJvLA0KDQpJIHRoaW5r IHRoaXMgaXMgb25lIG9mIHRoZSBkaWZmaWN1bHRpZXMgb2Ygb3ZlcmxvYWRpbmcgYSBwcm90b2Nv bCBsaWtlIEJHUCB3aXRoIGRpZmZlcmVudCBkYXRhc2V0cyAtLSBpdCdzIG5vdCBzaW1wbGUgdG8g c2F5IGhvdyBwYXJ0aWN1bGFyIGF0dHJpYnV0ZXMgYXJlIGFjdHVhbGx5IGdvaW5nIHRvIGJlIHVz ZWQgd2l0aGluIGEgcHJvdG9jb2wgZGVwbG95bWVudC4gVGhpcyB3YXMgb25lIG9mIHRoZSB0aGlu Z3MgdGhhdCB3YXMgbm90ZWQgaW4gNzYwNiAtLSBpLmUuLCBJIGNhbiBtYWtlICphbnkqIGF0dHJp YnV0ZSByZWFsbHkgYWZmZWN0IGZvcndhcmRpbmcgaWYgSSB3cml0ZSBhIHBvbGljeSB0aGF0IGFj Y2VwdHMvcmVqZWN0cyBzb21lIFVQREFURSBiYXNlZCBvbiB0aGUgcHJlc2VuY2Ugb2YgdGhhdCBh dHRyaWJ1dGUuDQoNCkluIGdlbmVyYWwsIGFueSB0b3BvbG9neSBkaXNjb3ZlcnkgbWVjaGFuaXNt ICh3aGV0aGVyIHVzZWQgaW4gcmVhbC10aW1lIG9yIG5vdCkgbmVlZHMgdG8gZGVmaW5lIGhvdyBp dCBoYW5kbGVzIGNhc2VzIHdoZXJlIGl0IG1pZ2h0IGVuZCB1cCB3aXRoIG1pc3NpbmcgaW5mb3Jt YXRpb24uIExldCdzIGNvbnNpZGVyIHdoYXQgdGhlIGRpZmZlcmVudCBtZWNoYW5pc21zIGZvciBk aXNjb3Zlcnkgd2UgaGF2ZSBhcmUgdG9kYXk6DQoNCiAgKiAgIElHUCBsaXN0ZW5pbmcgLS0gaW4g dGhpcyBjYXNlLCBpZiB3ZSBoYXZlIHNvbWUgbWFsZm9ybWVkIElTLUlTIFRMViwgdGhlbiB3ZSBt aWdodCBlbmQgdXAgZGlzY2FyZGluZyB0aGlzIGluZm9ybWF0aW9uICh3aGV0aGVyIGl0IGJlIGF0 IHRoZSBsaXN0ZW5pbmcgbm9kZSwgb3IgYSBkZXZpY2UgdGhhdCBkaWRuJ3QgZmxvb2QgaXQgZWFy bGllciBpbiB0aGUgY2hhaW4pIC0tIG1lYW5pbmcgdGhhdCB3ZSBrbm93IHRoYXQgd2UgaGF2ZSBz b21lIHBvdGVudGlhbCBnYXAgaW4gdGhlIHRvcG9sb2d5Lg0KICAqICAgU3RyZWFtaW5nIHRlbGVt ZXRyeSAtLSBzcGVha2luZyBwYXJ0aWN1bGFybHkgdG8gZ05NSSBmb3IgTFNEQiBzdHJlYW1pbmcg ZW5jb2RlZCB1c2luZyB0aGUgT3BlbkNvbmZpZyBtb2RlbCwgaGVyZSwgd2UgYXJlIHRvbGVyYW50 IHRvIGdldHRpbmcgYXMgbXVjaCBpbmZvcm1hdGlvbiBhcyBjYW4gYmUgcGFyc2VkLCBhbmQgaGF2 ZSBhIHdheSB0byBjYXJyeSB1bmtub3duIFRMVnMgKHdoaWNoIG1pZ2h0IGluY2x1ZGUgdGhvc2Ug dGhhdCBjYW5ub3QgYmUgc3VjY2Vzc2Z1bGx5IHBhcnNlZCkgYXMgYmluYXJ5IGRhdGEgdG8gdGhl IGV4dGVybmFsIGNvbnN1bWVyLiBUaGlzIG1lYW5zIHRoYXQgdGhlIGFwcHJvYWNoIGlzICJhcyBj b21wbGV0ZSBkYXRhIGFzIHBvc3NpYmxlIiwgYnV0IGhhcyB0aGUgc2FtZSBjaGFyYWN0ZXJpc3Rp YyB0aGF0IHdlIGNhbiBhbHNvIGVuZCB1cCBoYXZpbmcgdGhlIHBvdGVudGlhbCB0byBsb3NlIGRh dGEuDQogICogICBCR1AtTFMgd2l0aCBhdHRyaWJ1dGUgZGlzY2FyZCAtLSB0aGlzIGhhcyBzb21l IGluZm9ybWF0aW9uIGxvc3MsIHNpbmNlIHdlJ2xsIGhhdmUgc29tZSBhdHRyaWJ1dGVzIHRoYXQg Y291bGQgYmUgbWFsZm9ybWVkIGluIHRoZSBpbnB1dCBkYXRhLCBhbmQgd2UgZGlzY2FyZCB0aGVt IGF0IHRoZSByZWNlaXZlci4NCkl0IGRvZXNuJ3Qgc2VlbSB0byBtZSB0aGF0LCBnaXZlbiB0aGUg c291cmNlIG9mIHRoZSBkYXRhIGlzIHRoZSBJR1AsIGFuZCB3ZSBtaWdodCBoYXZlIGluZm9ybWF0 aW9uIGRpc2NhcmRlZCB0aGVyZSAtLSB0aGF0IHdlIGNhbiByZWFsbHkgZ3VhcmFudGVlIHN0cm9u ZyBjb25zaXN0ZW5jeSBvZiBhbiBvZmYtYm94IHZpZXcgb2YgdGhlIG5ldHdvcmssIHNpbmNlIHdl IGNhbid0IGd1YXJhbnRlZSBzdHJvbmcgY29uc2lzdGVuY3kgYWNyb3NzIHRoZSBJR1AgZG9tYWlu IGl0c2VsZi4NCg0KVGh1cywgSSdtIG5vdCBzdXJlIHRoYXQgdGhlIGlzc3VlIHRoYXQgaXMgYmVp bmcgaGlnaGxpZ2h0ZWQgaGVyZSBhY3R1YWxseSBtYWtlcyBhIGRpZmZlcmVuY2Ugd2hlbiB3ZSdy ZSBjb25zaWRlcmluZyB0aGUgb3ZlcmFsbCBzeXN0ZW0gZGVzaWduIC0tIHdlIGFsd2F5cyBuZWVk IHRvIGRlYWwgd2l0aCB0aGUgZmFjdCB0aGF0IHRoZSB2aWV3IG9mIHRoZSBuZXR3b3JrIGF0IHRo ZSBwYXRoIGNvbXB1dGluZyBub2RlIG1pZ2h0IG5vdCBtYXRjaCBleGFjdGx5IHRoZSBuZXR3b3Jr J3MgY3VycmVudCBzdGF0ZSBpbiB0aGUgcHJlc2VuY2Ugb2YgbWFsZm9ybWVkIHByb3RvY29sIG1l c3NhZ2VzLiBPbmUgbW90aXZhdGlvbiBmb3IgaGF2aW5nIHRoZSBMU0RCIHZpYSBzdHJlYW1pbmcg dGVsZW1ldHJ5IGlzIHRoZSBhYmlsaXR5IHRvIHByb3ZpZGUgc3VjaCB2YWxpZGF0aW9uICgiZG8g YWxsIG5vZGVzIHdpdGhpbiBteSBJR1AgZG9tYWluLCBpbmNsdWRpbmcgbGlzdGVuZXJzLCBoYXZl IGEgY29uc2lzdGVudCB2aWV3IG9mIHRoZSBzdGF0ZSBvZiB0aGUgbmV0d29yaz8iKS4NCg0KSWYg dGhlIGRpc2N1c3Npb24gaXMgInNob3VsZCB3ZSBhZG9wdCB0cmVhdC1hcy13aXRoZHJhdyB2cy4g YXR0cmlidXRlIGRpc2NhcmQ/IiAtLSBJIGRvbid0IHRoaW5rIHRoYXQgZnJvbSB0aGUgc3lzdGVt IHBlcnNwZWN0aXZlIHRoZXJlIGlzIHJlYWxseSBhbnkgZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSB0 d28gaW4gdGhpcyBzaXR1YXRpb24uIFdlIHN0aWxsIGhhdmUgdGhlIHNhbWUgcG90ZW50aWFsbHkg aW5jb25zaXN0ZW50IHZpZXcgb2YgdGhlIG5ldHdvcmsuDQoNCkZvciB0aGVzZSByZWFzb25zLCBJ J2QgZXJyIG9uIGxlYXZpbmcgdGhpcyB1bmNoYW5nZWQgaW4gdGhlIGN1cnJlbnQgc3BlY2lmaWNh dGlvbihzKS4NCg0KQ2hlZXJzLA0Kci4NCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVj ZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVs bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3Jhbmdl IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1 dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQg ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJl IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_53C29892C857584299CBF5D05346208A4898A07AOPEXCAUBM43corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAg MCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpU YWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglm b250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnAubS00MjY4MjE3NzU0MzIzMDkzODYyYWlybWFpbG9uLCBsaS5t LTQyNjgyMTc3NTQzMjMwOTM4NjJhaXJtYWlsb24sIGRpdi5tLTQyNjgyMTc3NTQzMjMwOTM4NjJh aXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6bV8tNDI2ODIxNzc1NDMyMzA5Mzg2MmFpcm1haWxf b247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1h bDsNCglmb250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5p dGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjUwMzg1OTQxNzsNCgltc28tbGlzdC10 ZW1wbGF0ZS1pZHM6LTkxOTk4NTMyO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxODAu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGww OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0 b206MGNtO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBBbHZhcm8sIGFsbDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PkFsc28gc3BlYWtpbmcgYXMgYSBXRyBwYXJ0aWNpcGFudDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gb3Igd2hhdCBpdOKAmXMgd29ydGgsICYj NDM7MSB0byBSb2LigJlzIGVtYWlsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZndDsgRnJvbTo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHNwcmluZyBb bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5BbHZh cm8gUmV0YW5hPGJyPg0KPGI+Jmd0OyBTZW50OjwvYj4gVGh1cnNkYXksIEphbnVhcnkgMDMsIDIw MTkgMTA6NDAgUE08L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5b4oCm XTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mZ3Q7DQo8L3NwYW4+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JIGZ1bGx5IHJlYWxpemUg dGhhdCBJIG1heSBiZSB0aGUgb25seSBvbmUgd2hvIHRoaW5rcyB0aGVyZeKAmXMgYW4gaXNzdWXi gKY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkkgZG9u4oCZdCB0aGluayBzby4gQnV0IGF0 IGxlYXN0IHRoZSBzcGVjaWZpY2F0aW9uIGRvZXMgZGVmaW5lIHRoZSBiZWhhdmlvciBpbiB0aGlz IGVycm9yIGNvbmRpdGlvbi4gQW5kIEkgZG9u4oCZdCB0aGluayB0aGF0IHRoZXJlIGlzIGEgcGVy ZmVjdCBzb2x1dGlvbjoNCiBSRkMgNzYwNiBiZWhhdmlvciBzZWVtcyBnb29kIGVub3VnaCB0byBt ZSBhbmQgSU1ITywgZ29pbmcgZnVydGhlciB3b3VsZCByZXF1aXJlIGRpc2N1c3NpbmcgYWx0ZXJu YXRpdmUgdGVjaG5pY2FsIHByb3Bvc2FscyAoc29sdXRpb25zKSByYXRoZXIgdGhhbiBqdXN0IHJh aXNpbmcgdGhlIHByb2JsZW0uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5CdXQgSeKAmW0g d29uZGVyaW5nIHdoeSBlcnJvciBoYW5kbGluZyBpcyB0aGF0IHNwZWNpZmljIHRvIEJHUC1MUy4g V2h5IGlzIHRoYXQgcG9pbnQgbm90IGJlZW4gcmFpc2VkIG9uLCBsZXTigJlzIHNheSwgZHJhZnQt aWV0Zi1vc3BmLW9zcGZ2My1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9ucw0KIHdoaWNoIGlzIGN1 cnJlbnRseSB1bmRlciBJRVNHIHJldmlldz8gSSBjYW4gc2VlIHRoYXQgdGhlIHNwZWNpZmljIGFy ZSAoYSBiaXQpIGRpZmZlcmVudCwgYnV0IHRoZSBiaWcgcGljdHVyZSBzZWVtcyB0aGUgc2FtZTog dGhlIGluZm9ybWF0aW9uIGlzIGluY29tcGxldGUsIGhvdyBkbyB3ZSBoYW5kbGUgdGhpcz88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhlbiwgSeKAmW0gbm90IHN1cmUg dGhhdCB0aGUgcHJvYmxlbSBpcyBzcGVjaWZpYy9saW1pdGVkIHRvIFNSL1NJRCBpbmZvcm1hdGlv bi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2siPi0tQnJ1bm88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmdd DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYiBTaGFraXI8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNk YXksIEphbnVhcnkgMDMsIDIwMTkgMTE6NDAgUE08YnI+DQo8Yj5Ubzo8L2I+IEFsdmFybyBSZXRh bmE8YnI+DQo8Yj5DYzo8L2I+IGlkckBpZXRmLiBvcmc7IFNQUklORyBXRzsgUm9iZXJ0IFJhc3p1 azxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NwcmluZ10gRXJyb3IgSGFuZGxpbmcgZm9yIEJH UC1MUyB3aXRoIFNlZ21lbnQgUm91dGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSBBbHZhcm8sPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkFsc28g c3BlYWtpbmcgYXMgYSBXRyBwYXJ0aWNpcGFudCA6LSk8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBKYW4gMywgMjAxOSBhdCAxOjQwIFBN IEFsdmFybyBSZXRhbmEgJmx0OzxhIGhyZWY9Im1haWx0bzphcmV0YW5hLmlldGZAZ21haWwuY29t Ij5hcmV0YW5hLmlldGZAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5CR1AtTFMgb25seSBkZWZpbmVzIGEgbWVjaGFuaXNtIHRocm91Z2ggd2hpY2ggaXQgbWF5 IG1pc3MgaW5mb3JtYXRpb24sIGJ1dCBub3QgaG93IHRvIGhhbmRsZSBpdCDigJQgb3IgbWF5YmUg aXQgZG9lcyAoPyk6IGJ5IHVzaW5nIGF0dHJpYnV0ZSBkaXNjYXJkIGl0IGp1c3QgYWNjZXB0cyB0 aGF0IHRoZSBpbmZvcm1hdGlvbiBtaWdodCBiZSBtaXNzaW5nIGdvaW5nIGZvcndhcmTigKZhbmQg ZG9lc27igJl0IGF0dGVtcHQgdG8NCiBkbyBhbnl0aGluZy4mbmJzcDsgTWF5YmUgdGhpcyBxdW90 ZSBpcyB0cnVlOiAmcXVvdDtEb2luZyBOb3RoaW5nIE9mdGVuIExlYWRzIHRvIHRoZSBWZXJ5IEJl c3QgU29tZXRoaW5n4oCdIOKAlCBXaW5uaWUgdGhlIFBvb2g8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgdGhpbmsgdGhhdCBpdCBkZWZpbmVzICpzb21ldGhpbmcqLCBhbGJlaXQgbm90IGV4 cGxpY2l0bHkuIEVzc2VudGlhbGx5LCBhcyBJIHJlYWQgaXQsIHdlJ3JlIHNheWluZyAmcXVvdDt3 aGVuIGFuIGF0dHJpYnV0ZSBlbmNvZGVkIGJ5IHRoZSBhZHZlcnRpc2luZyBCR1AtTFMgc291cmNl IGlzIGluY29ycmVjdCwgdGhlbiBCR1AtTFMgYXMgYSBzeXN0ZW0gd2lsbCBwcmVmZXIgdG8gdXNl IHBhcnRpYWwgaW5mb3JtYXRpb24mcXVvdDsNCiAocGFydGlhbCBpbmZvcm1hdGlvbiwgc2luY2Ug d2UgYXNzdW1lIHRoYXQgc29tZSBpbmZvcm1hdGlvbiBkb2VzIGdldCB0aHJvdWdoLCBzaW5jZSB0 aGUgTkxSSSBjb3VsZCBiZSBwYXJzZWQpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IGFj dGlvbiBtYXkgYmUgb2sgaW4gdGhlIGdlbmVyYWwgY2FzZeKApmJ1dCBJIHRoaW5rIHRoYXQgZG9p bmcgbm90aGluZyBtYXkgbm90IGJlIGVub3VnaC9hcHByb3ByaWF0ZSBmb3IgYW4gYXBwbGljYXRp b24gbGlrZSBTUiwgYmVjYXVzZSBpdCBpcyBleHBsaWNpdGx5IGNhbGN1bGF0aW5nIHBhdGhz4oCm LiZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoZSBwb2ludCBJ4oCZbSB0cnlpbmcgdG8gYnJpbmcgdXAgaXMgbm90IG5l Y2Vzc2FyaWx5IHRyZWF0LWFzLXdpdGhkcmF3IHZzLiBhdHRyaWJ1dGUgZGlzY2FyZOKApi4gQnV0 LCBmaXJzdCwgaXMgYXR0cmlidXRlIGRpc2NhcmQgZW5vdWdoL2FwcHJvcHJpYXRlL2dvb2QgZm9y IGEgQkdQLUxTIGFwcGxpY2F0aW9uIHN1Y2ggYXMgU1I/Jm5ic3A7IElmIGl0IGlzbuKAmXQsIHNl Y29uZCwgaXMgdGhlcmUgYSBkaWZmZXJlbnQgYXBwcm9hY2gNCiB0aGF0IHdvdWxkIGJlIGJldHRl cj8mbmJzcDsgTWF5YmUgd2UgdGhlbiBjb21lIHRvIGEgcG9pbnQgd2hlcmUgc29tZXRoaW5nIGNh biBjaGFuZ2XigKZvciBhY2NlcHQgdGhlIGxpbWl0YXRpb25zIG9mIHRoZSBzeXN0ZW0gYW5kIGJl IGNsZWFyIGFib3V0IHRoZW0uJm5ic3A7IEkgZnVsbHkgcmVhbGl6ZSB0aGF0IEkgbWF5IGJlIHRo ZSBvbmx5IG9uZSB3aG8gdGhpbmtzIHRoZXJl4oCZcyBhbiBpc3N1ZeKApjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+TXkgcG9pbnQgd2FzIHJlYWxseSB0aGUgc2FtZS4uLiBUaGUgcXVlc3Rp b24gSSB3YXMgdHJ5aW5nIHRvIHJhaXNlIGlzICZxdW90O3doYXQgaXMgdGhlIGFsdGVybmF0aXZl IHRoYXQgeW91IHdvdWxkIHN1Z2dlc3Q/JnF1b3Q7LiBPdGhlciB0ZWNobm9sb2dpZXMgdGhhdCBm dWxmaWxsIHRoZSBzYW1lIHJvbGUgYXMgQkdQLUxTICh0aG9zZSB0aGF0IEkgZGVzY3JpYmVkKSBk b24ndCB0YWtlIGEgdmVyeSBkaWZmZXJlbnQgYXBwcm9hY2guPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNsZWFybHksIGl0J3MgYmFkIHRvIGNh bGN1bGF0ZSBwYXRocyB3aXRoIGluY29tcGxldGUgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHRvcG9s b2d5IG9mIHRoZSBuZXR3b3JrLiBJdCdzIGFsc28gYmFkIHRvIGNhbGN1bGF0ZSB6ZXJvIHBhdGhz IGJlY2F1c2UgeW91IGRpc2NhcmRlZCB0aGUgZW50aXJlIHRvcG9sb2d5IGJhc2VkIG9uIGFuIGVy cm9yLiBXZSdyZSBpbi1iZXR3ZWVuIGEgcm9jayBhbmQgYSBoYXJkIHBsYWNlDQogaW4gdGVybXMg b2YgbWFpbnRhaW5pbmcgc3lzdGVtIGZ1bmN0aW9uYWxpdHkgaGVyZSAtLSBhbGwgc3lzdGVtcyB0 aGF0IGRvIHRoZSBzYW1lIGFzIEJHUC1MUyBhcmUgaGF2aW5nIHRvIG1ha2Ugc29tZSBmb3JtIG9m IGNvbXByb21pc2UgYWJvdXQgd2hpY2ggY29uc3RyYWludCAoY29ycmVjdG5lc3MsIG9yIGNvbm5l Y3Rpdml0eSkgdGhleSBhcmUgdmlvbGF0aW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIHdoeSBJIHdhcyBhcmd1aW5nIGZvciBs ZWF2aW5nIHRoaW5ncyB1bmNoYW5nZWQgLS0gdGhlIGNvcnJlY3RuZXNzIGNvbnN0cmFpbnQgc2Vl bXMgT0sgdG8gdmlvbGF0ZSBieSBkZWZhdWx0LiBJZiB0aGVyZSBhcmUgZGVwbG95bWVudHMgd2hl cmUgY29ubmVjdGl2aXR5IGlzIHRoZSBkZXNpcmFibGUgY29uc3RyYWludCB0byB2aW9sYXRlLCB0 aGVuIHJlYWN0aW5nIHRvIHRoZSBmYWN0IHRoYXQgYXR0cmlidXRlLWRpc2NhcmQNCiBkaWQgb2Nj dXIgaXMgcG9zc2libGUgKG9yIG5vdCBjb25maWd1cmluZyA3NjA2IGVycm9yIGhhbmRsaW5nIGlm IHRoZSBpbXBsZW1lbnRhdGlvbiBzdXBwb3J0cyB0aGlzKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVzY3JpYmluZyB0aGVzZSBjb21wcm9t aXNlcyBpcywgb2YgY291cnNlLCBhIGdvb2QgaWRlYS4gSG93ZXZlciwgaXQncyBub3QgY2xlYXIg d2hlcmUgdGhpcyBkZXNjcmlwdGlvbiB3b3VsZCBnbyAtLSB3ZSBkb24ndCByZWFsbHkgaGF2ZSBh IGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIHRoaXMgb3ZlcmFsbCBzeXN0ZW0gYW5kIGhvdyBpdCBt aWdodCBiZSBpbXBsZW1lbnRlZCB0b2RheS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzIGFuZCBITlkhPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5yLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhbmtzISE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWx2YXJv LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTQyNjgyMTc3NTQzMjMwOTM4NjJhaXJtYWls b24iPk9uIERlY2VtYmVyIDIxLCAyMDE4IGF0IDExOjIzOjE2IEFNLCBSb2IgU2hha2lyICg8YSBo cmVmPSJtYWlsdG86cm9ianNAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJvYmpzQGdvb2ds ZS5jb208L2E+KSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+QWx2YXJvLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgdGhpcyBpcyBvbmUgb2YgdGhlIGRpZmZpY3VsdGll cyBvZiBvdmVybG9hZGluZyBhIHByb3RvY29sIGxpa2UgQkdQIHdpdGggZGlmZmVyZW50IGRhdGFz ZXRzIC0tIGl0J3Mgbm90IHNpbXBsZSB0byBzYXkgaG93IHBhcnRpY3VsYXIgYXR0cmlidXRlcyBh cmUgYWN0dWFsbHkgZ29pbmcgdG8gYmUgdXNlZCB3aXRoaW4gYSBwcm90b2NvbCBkZXBsb3ltZW50 LiBUaGlzIHdhcyBvbmUgb2YgdGhlIHRoaW5ncw0KIHRoYXQgd2FzIG5vdGVkIGluIDc2MDYgLS0g aS5lLiwgSSBjYW4gbWFrZSAqYW55KiBhdHRyaWJ1dGUgcmVhbGx5IGFmZmVjdCBmb3J3YXJkaW5n IGlmIEkgd3JpdGUgYSBwb2xpY3kgdGhhdCBhY2NlcHRzL3JlamVjdHMgc29tZSBVUERBVEUgYmFz ZWQgb24gdGhlIHByZXNlbmNlIG9mIHRoYXQgYXR0cmlidXRlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBnZW5lcmFsLCBhbnkgdG9wb2xv Z3kgZGlzY292ZXJ5IG1lY2hhbmlzbSAod2hldGhlciB1c2VkIGluIHJlYWwtdGltZSBvciBub3Qp IG5lZWRzIHRvIGRlZmluZSBob3cgaXQgaGFuZGxlcyBjYXNlcyB3aGVyZSBpdCBtaWdodCBlbmQg dXAgd2l0aCBtaXNzaW5nIGluZm9ybWF0aW9uLiBMZXQncyBjb25zaWRlciB3aGF0IHRoZSBkaWZm ZXJlbnQgbWVjaGFuaXNtcyBmb3IgZGlzY292ZXJ5IHdlIGhhdmUgYXJlDQogdG9kYXk6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0Ij5JR1AgbGlzdGVuaW5nIC0tIGluIHRoaXMgY2FzZSwgaWYgd2UgaGF2ZSBzb21l IG1hbGZvcm1lZCBJUy1JUyBUTFYsIHRoZW4gd2UgbWlnaHQgZW5kIHVwIGRpc2NhcmRpbmcgdGhp cyBpbmZvcm1hdGlvbiAod2hldGhlciBpdCBiZSBhdCB0aGUgbGlzdGVuaW5nIG5vZGUsIG9yIGEg ZGV2aWNlIHRoYXQgZGlkbid0IGZsb29kIGl0IGVhcmxpZXIgaW4gdGhlIGNoYWluKSAtLSBtZWFu aW5nIHRoYXQNCiB3ZSBrbm93IHRoYXQgd2UgaGF2ZSBzb21lIHBvdGVudGlhbCBnYXAgaW4gdGhl IHRvcG9sb2d5Ljwvc3Bhbj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztt c28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+ U3RyZWFtaW5nIHRlbGVtZXRyeSAtLSBzcGVha2luZyBwYXJ0aWN1bGFybHkgdG8gZ05NSSBmb3Ig TFNEQiBzdHJlYW1pbmcgZW5jb2RlZCB1c2luZyB0aGUgT3BlbkNvbmZpZyBtb2RlbCwgaGVyZSwg d2UgYXJlIHRvbGVyYW50IHRvIGdldHRpbmcgYXMgbXVjaCBpbmZvcm1hdGlvbiBhcyBjYW4gYmUg cGFyc2VkLCBhbmQgaGF2ZSBhIHdheSB0byBjYXJyeSB1bmtub3duIFRMVnMgKHdoaWNoIG1pZ2h0 DQogaW5jbHVkZSB0aG9zZSB0aGF0IGNhbm5vdCBiZSBzdWNjZXNzZnVsbHkgcGFyc2VkKSBhcyBi aW5hcnkgZGF0YSB0byB0aGUgZXh0ZXJuYWwgY29uc3VtZXIuIFRoaXMgbWVhbnMgdGhhdCB0aGUg YXBwcm9hY2ggaXMgJnF1b3Q7YXMgY29tcGxldGUgZGF0YSBhcyBwb3NzaWJsZSZxdW90OywgYnV0 IGhhcyB0aGUgc2FtZSBjaGFyYWN0ZXJpc3RpYyB0aGF0IHdlIGNhbiBhbHNvIGVuZCB1cCBoYXZp bmcgdGhlIHBvdGVudGlhbCB0byBsb3NlIGRhdGEuPC9zcGFuPjxvOnA+PC9vOnA+PC9saT48bGkg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0Ij5CR1AtTFMgd2l0aCBhdHRyaWJ1dGUgZGlzY2FyZCAtLSB0aGlz IGhhcyBzb21lIGluZm9ybWF0aW9uIGxvc3MsIHNpbmNlIHdlJ2xsIGhhdmUgc29tZSBhdHRyaWJ1 dGVzIHRoYXQgY291bGQgYmUgbWFsZm9ybWVkIGluIHRoZSBpbnB1dCBkYXRhLCBhbmQgd2UgZGlz Y2FyZCB0aGVtIGF0IHRoZSByZWNlaXZlci48L3NwYW4+PG86cD48L286cD48L2xpPjwvdWw+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi Pkl0IGRvZXNuJ3Qgc2VlbSB0byBtZSB0aGF0LCBnaXZlbiB0aGUgc291cmNlIG9mIHRoZSBkYXRh IGlzIHRoZSBJR1AsIGFuZCB3ZSBtaWdodCBoYXZlIGluZm9ybWF0aW9uIGRpc2NhcmRlZCB0aGVy ZSAtLSB0aGF0IHdlIGNhbiByZWFsbHkgZ3VhcmFudGVlIHN0cm9uZyBjb25zaXN0ZW5jeSBvZiBh biBvZmYtYm94IHZpZXcgb2YgdGhlIG5ldHdvcmssIHNpbmNlDQogd2UgY2FuJ3QgZ3VhcmFudGVl IHN0cm9uZyBjb25zaXN0ZW5jeSBhY3Jvc3MgdGhlIElHUCBkb21haW4gaXRzZWxmLiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaHVzLCBJJ20gbm90IHN1cmUgdGhhdCB0aGUgaXNzdWUgdGhhdCBpcyBiZWlu ZyBoaWdobGlnaHRlZCBoZXJlIGFjdHVhbGx5IG1ha2VzIGEgZGlmZmVyZW5jZSB3aGVuIHdlJ3Jl IGNvbnNpZGVyaW5nIHRoZSBvdmVyYWxsIHN5c3RlbSBkZXNpZ24gLS0gd2UgYWx3YXlzIG5lZWQg dG8gZGVhbCB3aXRoIHRoZSBmYWN0IHRoYXQgdGhlIHZpZXcgb2YgdGhlIG5ldHdvcmsgYXQgdGhl IHBhdGggY29tcHV0aW5nIG5vZGUNCiBtaWdodCBub3QgbWF0Y2ggZXhhY3RseSB0aGUgbmV0d29y aydzIGN1cnJlbnQgc3RhdGUgaW4gdGhlIHByZXNlbmNlIG9mIG1hbGZvcm1lZCBwcm90b2NvbCBt ZXNzYWdlcy4gT25lIG1vdGl2YXRpb24gZm9yIGhhdmluZyB0aGUgTFNEQiB2aWEgc3RyZWFtaW5n IHRlbGVtZXRyeSBpcyB0aGUgYWJpbGl0eSB0byBwcm92aWRlIHN1Y2ggdmFsaWRhdGlvbiAoJnF1 b3Q7ZG8gYWxsIG5vZGVzIHdpdGhpbiBteSBJR1AgZG9tYWluLCBpbmNsdWRpbmcgbGlzdGVuZXJz LA0KIGhhdmUgYSBjb25zaXN0ZW50IHZpZXcgb2YgdGhlIHN0YXRlIG9mIHRoZSBuZXR3b3JrPyZx dW90OykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPklmIHRoZSBkaXNjdXNzaW9uIGlzICZxdW90O3Nob3VsZCB3ZSBhZG9wdCB0cmVhdC1hcy13 aXRoZHJhdyB2cy4gYXR0cmlidXRlIGRpc2NhcmQ/JnF1b3Q7IC0tIEkgZG9uJ3QgdGhpbmsgdGhh dCBmcm9tIHRoZSBzeXN0ZW0gcGVyc3BlY3RpdmUgdGhlcmUgaXMgcmVhbGx5IGFueSBkaWZmZXJl bmNlIGJldHdlZW4gdGhlIHR3byBpbiB0aGlzIHNpdHVhdGlvbi4gV2Ugc3RpbGwgaGF2ZSB0aGUg c2FtZSBwb3RlbnRpYWxseSBpbmNvbnNpc3RlbnQNCiB2aWV3IG9mIHRoZSBuZXR3b3JrLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3IgdGhl c2UgcmVhc29ucywgSSdkIGVyciBvbiBsZWF2aW5nIHRoaXMgdW5jaGFuZ2VkIGluIHRoZSBjdXJy ZW50IHNwZWNpZmljYXRpb24ocykuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxQUkU+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVz c2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRp b25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBh cyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT aSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h bGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpv aW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2Fs dGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxk IG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9u LgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4K QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5 b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_53C29892C857584299CBF5D05346208A4898A07AOPEXCAUBM43corp_-- From nobody Tue Jan 8 13:15:20 2019 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB1F12D84D; Tue, 8 Jan 2019 13:15:19 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 L_Hnf6aLSJ2y; Tue, 8 Jan 2019 13:15:18 -0800 (PST) Received: from mail-oi1-x236.google.com (mail-oi1-x236.google.com [IPv6:2607:f8b0:4864:20::236]) (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 CE8B2124D68; Tue, 8 Jan 2019 13:15:17 -0800 (PST) Received: by mail-oi1-x236.google.com with SMTP id y1so4528340oie.12; Tue, 08 Jan 2019 13:15:17 -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; bh=42Wan4WoV9lf+sh9TUbCoqDD+MjzQ0vHy6l3M26FGeo=; b=nV+tCoOY59MZ5kHjhOCSstnK1OlMKbGUAPZ0bgxnVGA0+TF+5DYHal2NL1WKolOkRu NbiRty7EXtN1lsj3a/ubowyfppiVAHbGSB3UI/8FZ6BBnsJc/6YzDGwKFr+d3rvGJhib oWDlWczs6DBNINGK/rOdlLhrUM9CKIcQbe74GU+mJpJSL3PP2Ii7Yp8zHJvaquWjMoKb xE0viqiv2qEdVAhfzaSeYhbxkcUSls3KMHlHopGeQaWRw/niNUCy+g9JZA9SUzM9I63Y uhPWWhgU58Ns9TAfKuDp+YoNLCDoks6Uyf3d+lycjV5Wt4wZ8qN7Afts1F+Vk+rNrWMk r0CQ== 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; bh=42Wan4WoV9lf+sh9TUbCoqDD+MjzQ0vHy6l3M26FGeo=; b=HmX9LwKX2/+5+jf3gW70dW3LL7xWmp50c/EdOZtUIK7NNb1N4IaJ2oideiFaCHZ51J ++LAzU+In8NOZby+9o6FS5ElAcAQfGVUtcb799rDucifIyyxJlKmBN+yPai25LoM+fSD JJhNrVyy6uTzNdyxdNhoAEqwqS4q42V+bzMU1Gi0ni0t5yabdWGCPcuGRvPzygZClebD QiE2BTFnCZ8uA7/ct7MqP+l62tBQHS3DvMGZb+JWjYju4tL+53TDF9f3JcUuDXjmaBz+ 4yk8Iu8WN19aWSDBP4+ggYAqTgJYqo9dafRc3pUcokMy2tdtvLfNCwWVzdlUazwX1ola CAuQ== X-Gm-Message-State: AJcUukc1q2aCKAUhUFpLnX9RcBeGVJ9SKJS5PzMs/tlGGuHXi23w9WyR Cgiinc1qxfOM19THEkjcZV/NCIg/kdkfygdJwwk= X-Google-Smtp-Source: ALg8bN5si1LIuXbbYjbSnjH5DsOK8TfnrU8LCS+yB6PZ5cL6BEip4pMjubb/ku0rvN2MGiJmopOSVZEuguC6MmJFQYU= X-Received: by 2002:aca:3cc5:: with SMTP id j188mr2241338oia.278.1546982117070; Tue, 08 Jan 2019 13:15:17 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 8 Jan 2019 13:15:16 -0800 From: Alvaro Retana In-Reply-To: <1830_1546958029_5C34B4CD_1830_110_1_53C29892C857584299CBF5D05346208A4898A07A@OPEXCAUBM43.corporate.adroot.infra.ftgroup> References: <1830_1546958029_5C34B4CD_1830_110_1_53C29892C857584299CBF5D05346208A4898A07A@OPEXCAUBM43.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Date: Tue, 8 Jan 2019 13:15:16 -0800 Message-ID: To: bruno.decraene@orange.com Cc: Robert Raszuk , "idr@ietf. org" , SPRING WG , Rob Shakir Content-Type: multipart/alternative; boundary="0000000000008fdd09057ef8d7ec" Archived-At: Subject: Re: [spring] Error Handling for BGP-LS with Segment Routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jan 2019 21:15:20 -0000 --0000000000008fdd09057ef8d7ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On January 8, 2019 at 9:33:49 AM, bruno.decraene@orange.com ( bruno.decraene@orange.com) wrote: Bruno: Hi! ... But I=E2=80=99m wondering why error handling is that specific to BGP-LS. It is just in this thread... Why is that point not been raised on, let=E2=80=99s say, draft-ietf-ospf-ospfv3-segment-routing-extensions which is currently under IESG review? I can see that the specific are (a bit) different, but the big picture seems the same: the information is incomplete, how do we handle this? [AD Note: draft-ietf-ospf-ospfv3-segment-routing-extensions is pending a new revision to clear an outstanding DISCUSS. If you (or anyone) has specific issues about this document, please let me know as I=E2=80=99m read= y to approve the publication.] I didn=E2=80=99t specifically raise the question of error handling for BGP-= LS with SR against the current document I=E2=80=99m reviewing (draft-ietf-idr-bgp-ls-segment-routing-ext) because I don=E2=80=99t think t= he solution explicitly belongs there=E2=80=A6so I started the discussion on th= e idr/spring lists. If there are issues with the OSPFv3 transport then the solution probably doesn=E2=80=99t belong in the extensions draft. [This part of the discussion belongs on a different list=E2=80=A6] I think = that the link state protocols have different characteristics (than BGP-LS) when it comes to try to ensure common information between the nodes: reliability at the LSA/LSP level, db synchronization, etc.. That difference brought me to not bring up the question of incomplete information when I was reviewing the SR extension drafts. I may of course be missing an important piece. If this point needs to be discussed, we should move to lsr. Then, I=E2=80=99m not sure that the problem is specific/limited to SR/SID information. Right. I think it=E2=80=99s easier to discuss specific problems first and then generalize=E2=80=A6than start with the general problem. That is one of the= reasons for this thread. In the specific case of BGP-LS, rfc7752 makes assumptions about about the nature of the information, which I think are broken with SR=E2=80=A6. I think there=E2=80=99s an SR-specific issue that needs to be = addressed somewhere. As you mentioned before, other applications, like lsvr, could have the same issues. Thanks! Alvaro. --0000000000008fdd09057ef8d7ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On January 8, 2019 at 9:33:49 AM, bruno.decraene@orange.com (bruno.decraene@orange.com) wrote:
=

Bruno:

Hi!

...

But I=E2=80=99m wondering why erro= r handling is that specific to BGP-LS.=C2=A0

It is just in t= his thread...

Why is that point not been raised on, let= =E2=80=99s say, draft-ietf-ospf-ospfv3-segment-routing-extensions which is = currently under IESG review? I can see that the specific are (a bit) differ= ent, but the big picture seems the same: the information is incomplete, how= do we handle this?

[AD Note: = =C2=A0draft-ietf-ospf-ospfv3-segment-routing-extensions is pending a new re= vision to clear an outstanding DISCUSS.=C2=A0 If you (or anyone) has specif= ic issues about this document, please let me know as I=E2=80=99m ready to a= pprove the publication.]

I didn=E2=80=99t specifically raise th= e question of error handling for BGP-LS with SR against the current documen= t I=E2=80=99m reviewing (draft-ietf-idr-bgp-ls-segment-routing-ext) because= I don=E2=80=99t think the solution explicitly belongs there=E2=80=A6so I s= tarted the discussion on the idr/spring lists.=C2=A0 If there are issues wi= th the OSPFv3 transport then the solution probably doesn=E2=80=99t belong i= n the extensions draft.

[This part of the discussion belongs on a dif= ferent list=E2=80=A6] I think that the link state protocols have different = characteristics (than BGP-LS) when it comes to try to ensure common informa= tion between the nodes: reliability at the LSA/LSP level, db synchronizatio= n, etc..=C2=A0 That difference brought me to not bring up the question of i= ncomplete information when I was reviewing the SR extension drafts.=C2=A0 I= may of course be missing an important piece.=C2=A0 If this point needs to = be discussed, we should move to lsr.

Then, I=E2=80=99m not sur= e that the problem is specific/limited to SR/SID information.

Right. =C2=A0

I think it=E2=80=99s easier t= o discuss specific problems first and then generalize=E2=80=A6than start wi= th the general problem.=C2=A0 That is one of the reasons for this thread.= =C2=A0 In the specific case of BGP-LS, rfc7752 makes assumptions about=C2= =A0=C2=A0about the nature of th= e information, which I think are broken with SR=E2=80=A6. I think there=E2= =80=99s an SR-specific issue that needs to be addressed somewhere.

As you mentioned before, o= ther applications, like lsvr, could=C2=A0have the same issues.

Thanks!

Alvaro.=C2=A0




--0000000000008fdd09057ef8d7ec--