From nobody Mon May 2 05:37:26 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00D812D509 for ; Mon, 2 May 2016 05:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 NI74fOPb9Djm for ; Mon, 2 May 2016 05:37:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07ADD12D4FC for ; Mon, 2 May 2016 05:37:22 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 47FBA3249F6 for ; Mon, 2 May 2016 14:37:20 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 2DCEA35C060 for ; Mon, 2 May 2016 14:37:20 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0279.002; Mon, 2 May 2016 14:37:19 +0200 From: To: "spring@ietf.org" Thread-Topic: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label Thread-Index: AQHRnTVMcteLha4FPUqiNKIUGrWdS5+lo3TQ Date: Mon, 2 May 2016 12:37:19 +0000 Message-ID: <13875_1462192640_57274A00_13875_9641_1_53C29892C857584299CBF5D05346208A0F8830E6@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <571B29F8.1060301@pi.nu> In-Reply-To: <571B29F8.1060301@pi.nu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.2.110616 Archived-At: Subject: [spring] FW: [mpls] working group last call on draft-ietf-mpls-spring-entropy-label X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 12:37:24 -0000 Hi all, The MPLS WG is running a working group last call on draft-ietf-mpls-spring-= entropy-label, which is of interest to spring, for the MPLS dataplane. You may want to read and comment, on the _MPLS_ mailing list. Document is = pretty short. > working group last call ends May 12, 2016. -- Bruno -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Saturday, April 23, 2016 9:53 AM To: mpls@ietf.org Cc: draft-ietf-mpls-spring-entropy-label@tools.ietf.org; mpls-chairs@ietf.o= rg Subject: [mpls] working group last call on draft-ietf-mpls-spring-entropy-l= abel Working Group, This is to initiate a two week working group last call on draft-ietf-mpls-s= pring-entropy-label. Please send your comments to the mpls wg mailing list (mpls@ietf.org). There are no IPR disclosures against this document. All the authors and contributors (with one exception) have stated on the wo= rking group mailing list that they are not aware of any other IPRs that rel= ates to this draft. This working group last call ends May 12, 2016. /Loa for the MPLS wg chairs --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon May 2 05:41:44 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFF512D50C; Mon, 2 May 2016 05:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 1bRAB8EB8jV5; Mon, 2 May 2016 05:41:41 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87B6A12D4FC; Mon, 2 May 2016 05:41:38 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 082954061E; Mon, 2 May 2016 14:41:37 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.41]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id D1A6F120066; Mon, 2 May 2016 14:41:36 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM31.corporate.adroot.infra.ftgroup ([fe80::2cc9:4bac:7b7d:229d%19]) with mapi id 14.03.0279.002; Mon, 2 May 2016 14:41:36 +0200 From: To: "spring@ietf.org" , "draft-ietf-spring-sr-oam-requirement@ietf.org" Thread-Topic: [mpls] working group adption poll on draft-kumarkini-mpls-spring-lsp-ping Thread-Index: AQHRnJdfYi5rAhs1yEqmpSf4RHORgZ+lpZGw Date: Mon, 2 May 2016 12:41:35 +0000 Message-ID: <32275_1462192896_57274B00_32275_255_1_53C29892C857584299CBF5D05346208A0F883109@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <571A2101.9050106@pi.nu> In-Reply-To: <571A2101.9050106@pi.nu> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [spring] FW: [mpls] working group adption poll on draft-kumarkini-mpls-spring-lsp-ping X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 12:41:43 -0000 Hi all, The MPLS WG is running a poll for adoption on draft-kumarkini-mpls-spring-l= sp-ping, which is of interest to spring, for the MPLS dataplane. You may want to read and comment, on the _MPLS_ mailing list.=20=20 > working group last call ends May 12, 2016. -- Bruno -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson Sent: Friday, April 22, 2016 3:03 PM To: mpls@ietf.org; mpls-chairs@ietf.org; draft-kumarkini-mpls-spring-lsp-pi= ng@tools.ietf.org Subject: [mpls] working group adption poll on draft-kumarkini-mpls-spring-l= sp-ping Working Group, This is to start a two week poll to see if we have consensus to adopt draft= -kumarkini-mpls-spring-lsp-ping as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls@ietf.org). Please give a technical motivation for your su= pport/not support, especially if you think that the document should not be = adopted as a working group document. There are no IPR disclosures against this document. All the authors has stated that they are not aware of any IPRs that relate = to this document. In all but one case this has been done on the on the mpls= wg mailing list, in the last case this has been stated in a mail to the wg= chairs. The working group adoption poll ends May 7, 2016. /Loa MPLS wg co-chair. --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon May 2 05:44:29 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 115AB12D510; Mon, 2 May 2016 05:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 NjbtU7jyh8S0; Mon, 2 May 2016 05:44:26 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5E9712D4FC; Mon, 2 May 2016 05:44:25 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 390C122CC74; Mon, 2 May 2016 14:44:24 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.24]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 18C8135C068; Mon, 2 May 2016 14:44:24 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0279.002; Mon, 2 May 2016 14:44:23 +0200 From: To: "spring@ietf.org" , "draft-ietf-spring-sr-oam-requirement@ietf.org" Thread-Topic: [mpls] working group adption poll on draft-kumarkini-mpls-spring-lsp-ping Thread-Index: AQHRnJdfYi5rAhs1yEqmpSf4RHORgZ+lpZGwgAABvIA= Date: Mon, 2 May 2016 12:44:23 +0000 Message-ID: <25686_1462193064_57274BA8_25686_106_1_53C29892C857584299CBF5D05346208A0F883128@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <571A2101.9050106@pi.nu> <32275_1462192896_57274B00_32275_255_1_53C29892C857584299CBF5D05346208A0F883109@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <32275_1462192896_57274B00_32275_255_1_53C29892C857584299CBF5D05346208A0F883109@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.25.91516 Archived-At: Subject: Re: [spring] [mpls] working group adption poll on draft-kumarkini-mpls-spring-lsp-ping X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 12:44:28 -0000 > > working group last call ends May 12, 2016. I meant: working group adoption poll ends May 7, 2016. Sorry for the spam. --Bruno > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of > bruno.decraene@orange.com > Sent: Monday, May 02, 2016 2:42 PM > To: spring@ietf.org; draft-ietf-spring-sr-oam-requirement@ietf.org > Subject: [spring] FW: [mpls] working group adption poll on draft-kumarkin= i- > mpls-spring-lsp-ping >=20 > Hi all, >=20 > The MPLS WG is running a poll for adoption on draft-kumarkini-mpls-spring- > lsp-ping, which is of interest to spring, for the MPLS dataplane. >=20 > You may want to read and comment, on the _MPLS_ mailing list. >=20 > > working group last call ends May 12, 2016. >=20 > -- Bruno >=20 > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: Friday, April 22, 2016 3:03 PM > To: mpls@ietf.org; mpls-chairs@ietf.org; draft-kumarkini-mpls-spring-lsp- > ping@tools.ietf.org > Subject: [mpls] working group adption poll on draft-kumarkini-mpls-spring- > lsp-ping >=20 > Working Group, >=20 > This is to start a two week poll to see if we have consensus to adopt dra= ft- > kumarkini-mpls-spring-lsp-ping as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical motivation fo= r your > support/not support, especially if you think that the document should not= be > adopted as a working group document. >=20 > There are no IPR disclosures against this document. >=20 > All the authors has stated that they are not aware of any IPRs that relat= e to > this document. In all but one case this has been done on the on the mpls = wg > mailing list, in the last case this has been stated in a mail to the wg c= hairs. >=20 > The working group adoption poll ends May 7, 2016. >=20 > /Loa >=20 > MPLS wg co-chair. > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exp= loites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veu= illez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. L= es > messages electroniques etant susceptibles d'alteration, Orange decline to= ute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Mon May 2 06:35:24 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23C4012D513 for ; Mon, 2 May 2016 06:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 sfnf-nPxIIro for ; Mon, 2 May 2016 06:35:21 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 382A7128B44 for ; Mon, 2 May 2016 06:35:21 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 9930518C967 for ; Mon, 2 May 2016 15:35:19 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.72]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 7E13D27C064 for ; Mon, 2 May 2016 15:35:19 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0279.002; Mon, 2 May 2016 15:35:19 +0200 From: To: "spring@ietf.org" Thread-Topic: IETF 95 minutes Thread-Index: AdGkdvvVZA1gR/pqTnGeVwCofOeFOw== Date: Mon, 2 May 2016 13:35:19 +0000 Message-ID: <27641_1462196119_57275797_27641_3823_1_53C29892C857584299CBF5D05346208A0F883273@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.2.125416 Archived-At: Subject: [spring] IETF 95 minutes X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 May 2016 13:35:23 -0000 Hi all, Minutes have been uploaded on Apr 15, 2016 https://www.ietf.org/proceedings/95/minutes/minutes-95-spring Many thanks to the note takers. Please review and comment as needed.=20 IETF correction=A0submissions cutoff is=A0Monday, May 27th, 2016. =A0 Thanks, Regards, -- John, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Tue May 3 15:59:39 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B713E12DA20 for ; Tue, 3 May 2016 15:59:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFak0dXjxYwp for ; Tue, 3 May 2016 15:59:32 -0700 (PDT) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4224512DA15 for ; Tue, 3 May 2016 15:59:32 -0700 (PDT) X-AuditID: c6180641-f796f6d000000e1e-5c-57292d25bb57 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id EE.98.03614.52D29275; Wed, 4 May 2016 00:58:45 +0200 (CEST) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0248.002; Tue, 3 May 2016 18:59:30 -0400 From: Uma Chunduri To: "Les Ginsberg (ginsberg)" , "bruno.decraene@orange.com" , "spring@ietf.org" Thread-Topic: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call Thread-Index: AdGWIcRdLnRAPWN3Qn6eVontUw9C0AAAMhXQAqz8LVAApDM0UACH8IyQ Date: Tue, 3 May 2016 22:59:29 +0000 Message-ID: <1B502206DFA0C544B7A60469152008635BCD31AB@eusaamb106.ericsson.se> References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10411_1460620508_570F4CDC_10411_96_23_53C29892C857584299CBF5D05346208A0F86E45F@OPEXCLILM21.corporate.adroot.infra.ftgroup> <1B502206DFA0C544B7A6046915200863580C54E9@eusaamb105.ericsson.se> <0468fb2fe35841668bc35606e988074c@XCH-ALN-001.cisco.com> In-Reply-To: <0468fb2fe35841668bc35606e988074c@XCH-ALN-001.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008635BCD31ABeusaamb106erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprCIsWRmVeSWpSXmKPExsUyuXRPoK6qrma4weKNihY/dsxhttjwZyO7 xfELvxkdmD2m/N7I6rFkyU8mj5ZnJ9kCmKO4bFJSczLLUov07RK4MlZ9esVWsOoGc8WbNy+Y GxgXLmXuYuTkkBAwkfh85y4LhC0mceHeerYuRi4OIYGjjBJnN/5hgnCWMUp8Of8WrINNQE/i 49Sf7CAJEYEpjBJLjn9kAkkIC4RITLu1gLGLkQMoESrx5asoSFhEwE1i4uLrbCA2i4CKxOln LawgNq+Ar8Tyu0vA4kICrcwSlzeD2ZwCrhIvv+4Gq2EEuuj7qTVg45kFxCVuPZnPBHGpgMSS PeehPhCVePn4HyuErSixr386O0R9vkT7+U1MELsEJU7OfMIygVFkFpJRs5CUzUJSBhHXkViw +xMbhK0tsWzha2YY+8yBx0zI4gsY2VcxcpQWF+TkphsZbmIExtUxCTbHHYx7ez0PMQpwMCrx 8CqwaYQLsSaWFVfmHmKU4GBWEuHtl9cMF+JNSaysSi3Kjy8qzUktPsQozcGiJM6r/1IxXEgg PbEkNTs1tSC1CCbLxMEp1cBY/eKI5zORDytmNy/u8NORrpfK39Fx+euDLI95xUuFCtR9Kt4r TOPe7Ky7cC3z5S31ie8C5wtsPfhP4setZc22bYzbfDVlLlsyTrnOdGVT/kSexO0Xtlnc2xDG Me9Zxt2V1//9vBP79OvuyA3mDsIi+zv7T3WvnX4qqPpLxMzrBz7u2ybD76hprcRSnJFoqMVc VJwIANZwQhynAgAA Archived-At: Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 May 2016 22:59:36 -0000 --_000_1B502206DFA0C544B7A60469152008635BCD31ABeusaamb106erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Les, With all due respects, cross protocol verification of prefix and SID confl= icts as an "architectural change" and it can severely impact the existing = implementations (at least the one I work on). Also I have couple of cases where current version of the draft is not clear= about resolution. IMO, first we need clarity with in a protocol instance resolution rules bef= ore going to resolve the same across protocols (I mentioned few cases below= ) . Separation of reachability advertisements and SRMS would help "cross protoc= ol" verification of the ranges and SRMS is not applicable to all protocols. In-line [Uma]: -- Uma C. From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Saturday, April 30, 2016 10:11 PM To: Uma Chunduri; bruno.decraene@orange.com; spring@ietf.org Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution - WG adopti= on call Uma - We are indeed defining conflict resolution across all the SID advertisement= s regardless of source (protocol or SRMS) - [Uma]: While you can theoretically do anything for current implementation t= his kind of cross protocol verification is a new architectural requirement. Because it seems "a central entity" need to gather all diffe= rent protocol instances SRMS advertisements and should settle with resoluti= on. - Also note SRMS is not applicable for BGP but it seems all prefix= SIDs need to be verified with IGP instances SRMS advertisements. Is this = true? While the document mostly talks about these and compares with prefix = advertisement. - Algorithm proposed needs more clarity: Take Section 3.2.4 o " 1. Smaller range wins 2. IPv6 entry wins over IPv4 entry ... " What happens in case of prefix conflict or SID conflict wi= th only prefix advertisements (range 1). Say multiple prefixes have same S= ID in one protocol instance and in different protocols. I see 2 levels of resolution required viz., one at within = the protocol and one among the protocols. No discussion on this. Similarly in case of SID conflict (range 1), it's not spe= cified which protocol's SID need to be considered. Are you assuming some s= ort of Admin distance play a role in resolution? I don't see any discussion in the document and needs more clarity there t= oo. o Also what happens if a prefix or SID conflict happens with SRMS range 1= and a prefix advertisement (2 cases) a. of one protocol and b. multiple protocols? - On the below assumption: (Section 3.2.4) "This has the nice property that a= single misconfiguratoion of an SRMS entry with a large range will not be preferred over a larg= e number of SIDs advertised in prefix reachability advertisements." While anything can happen in theory, I found it bit odd to see why SRMS ent= ry is being advertised and for the same prefix, SID is also advertised thro= ugh reachability advertisements? This is against the spirit of SRMS advertisement, isn't it? While this can = happen, it seems we are claiming resolution solution by focusing more on t= his case in the current version of the document. This is one of the reasons of my first comment below. You got to separate t= he reachability advertisements and SRMS advertisements; as in principle the= se are defined for different purposes. I don't see we need algorithm to pr= efer reachability advertisement over SRMS advertisement (if we don't compar= e these 2 categories). as the sections you have quoted clearly state. Why? Because we need consistent use of SIDs in the forwarding plane. From f= orwarding perspective it matters not whether the SID was advertised by prot= ocol instance #1 or #2 or by an SRMS. What matters is that the SID I use to determine what label I install in my = forwarding plane is the same SID that my neighbors will use. Otherwise forw= arding will be broken. Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Uma Chunduri Sent: Wednesday, April 27, 2016 4:31 PM To: bruno.decraene@orange.com; spring@iet= f.org Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adopti= on call Dear Authors, Have few comments on the draft: 1. As I indicated during meeting - I am not sure why we have to club = verification of SIDs advertised through regular protocol reachability prefixes and the ranges advertised through 'Mapping Server'= (SRMS). I didn't see any compelling reason to do this. SIDs advertised through reachability prefixes doesn't have= ranges unlike SRMS advertisements. As SRMS advertisements are primarily for nodes which are n= ot SR capable and I feel we should not mix this with nodes which are SR ca= pable. This isolation helps restricting the resolution work primarily for = multiple SRMS entries advertised through one node or multiple nodes. SRMS advertisements are indeed little bit unique in that yo= u are advertising "configuration" on behalf of node X from node Y with ranges (both prefix ranges and SID ranges). 2. Regarding the scope of conflict resolution: Section 1 " The problem to be addressed is protocol independent i.e., se= gment related advertisements may be originated by multiple nodes using different protocols and yet the conflict resolution MUST be the sa= me on all nodes regardless of the protocol used to transport the advertisements." Section 3.2.8 " o In cases where multiple routing protocols are in use mappi= ng entries advertised by all routing protocols MUST be included." This sounds like we are seeking to resolve conflicting entries outsid= e and across the protocols? Each IGP has separate mechanism for advertising mapping entry and I t= his is not clear with the current version of the draft how we can cross ver= ify SID/Prefix conflict across the protocol. Can you clarify this? -- Uma C. -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, April 14, 2016 12:55 AM To: spring@ietf.org Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adopti= on call > From: bruno.decraene@orange.com > Sent= : Thursday, April 14, 2016 9:51 > AM > > Dear WG, > > As we discussed at our meeting last week, working group adoption has > been requested for draft-ginsberg-spring-conflict-resolution. > Please reply to the list with your comments, including although not > limited to whether or not you support adoption. We will end the call on April 29, 2016. > Thanks, > > --John and Bruno > > > > __________________________________________________________ > __________________________________________________________ > _____ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > que les pieces jointes. Les messages electroniques etant susceptibles > d'alteration, Orange decline toute responsabilite si ce message a ete alt= ere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_1B502206DFA0C544B7A60469152008635BCD31ABeusaamb106erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Les,

 <= /p>

With all due respects, cr= oss protocol verification  of prefix and SID conflicts as an “ar= chitectural change”  and it can severely impact the existing imp= lementations (at least the one I work on).

Also I have couple of cas= es where current version of the draft is not clear about resolution.

 <= /p>

IMO, first we need clarit= y with in a protocol instance resolution rules before going to resolve the = same across protocols (I mentioned few cases below) .

Separation of reachabilit= y advertisements and SRMS would help “cross protocol” verificat= ion of the ranges and SRMS is not applicable to all protocols.

 <= /p>

 <= /p>

In-line [Uma]:<= o:p>

 <= /p>

--

Uma C.<= /p>

 <= /p>

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Saturday, April 30, 2016 10:11 PM
To: Uma Chunduri; bruno.decraene@orange.com; spring@ietf.org
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution - WG= adoption call

 

Uma –

 <= /p>

We are indeed defining co= nflict resolution across all the SID advertisements regardless of source (p= rotocol or SRMS) –

 <= /p>

[Uma]: While you can theo= retically do anything for current implementation this kind of cross protoco= l verification is a new architectural requirement.  =

    &= nbsp;          Because it= seems “a central entity” need to gather all different protocol= instances SRMS advertisements and should settle with resolution. 

 <= /p>

-  &n= bsp;       Also note SRMS is= not applicable for BGP but it seems all prefix SIDs need to be verified &n= bsp;with IGP instances SRMS advertisements. Is this true? While the document mostly talks about these and compares with prefix advertiseme= nt.

 <= /p>

-  &n= bsp;       Algorithm propose= d needs more clarity: Take Section 3.2.4

 <= /span>

o    = 

   &nbs=
p;            &=
nbsp;     “   1.  Smaller r=
ange wins

=  

 = ;            2.  IPv= 6 entry wins over IPv4 entry

 = ;            …=

        “

           &nbs= p;     What happens in case of prefix conflict or SID c= onflict with only prefix advertisements (range 1).  Say multiple prefixes have same SID in one protocol instance and in different protocols= .

           &nbs= p;     I see 2 levels of resolution required viz., one = at within the protocol and one among the protocols.  No discussion on this.

           &nbs= p;     Similarly in case of SID conflict  (range 1= ), it’s not specified which protocol’s SID need to be considere= d.  Are you assuming some sort of Admin distance play a role in resolution? <= /o:p>

 I don’t see any discussion in the docum= ent  and needs more clarity there too.

o   Also what happens= if a prefix or SID conflict happens with SRMS range 1 and a prefix  a= dvertisement (2 cases)

a.  &= nbsp;    of one protocol a= nd

b.  &= nbsp;   multiple protocol= s?

 <= /span>

-  &n= bsp;       On the below assu= mption: (Section 3.2.4)

   &nbs=
p;             =
            &nb=
sp;           “This has the nice property that a single misconfiguratoion of an SRMS
      &nbs=
p;          entry with a =
large range will not be preferred over a large number of
      &nbs=
p;          SIDs advertis=
ed in prefix reachability advertisements.”

While anything can happen in theory, I found it bit odd to see = why SRMS entry is being advertised and for the same prefix, SID is also advertised through reachability advertisements?

This is against the spirit of SRMS advertisement, isn’t i= t? While this can happen, it seems we are claiming resolution solution by focusing more on  this case in the current version of the document= .

 

This is one of the reasons of my first comment below. You got t= o separate the reachability advertisements and SRMS advertisements; as in principle these are defined for different purposes. I don’t se= e we  need algorithm to prefer reachability advertisement over SRMS ad= vertisement (if we don’t compare these 2 categories).

&n=
bsp;

 

 <= /p>

 <= /p>

as the sections you have = quoted clearly state.

 <= /p>

Why? Because we need cons= istent use of SIDs in the forwarding plane. From forwarding perspective it = matters not whether the SID was advertised by protocol instance #1 or #2 or by an SRMS.

 <= /p>

What matters is that the = SID I use to determine what label I install in my forwarding plane is the s= ame SID that my neighbors will use. Otherwise forwarding will be broken.

 <= /p>

   Les

 <= /p>

 <= /p>

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Uma Chunduri
Sent: Wednesday, April 27, 2016 4:31 PM
To: bruno.decraene@oran= ge.com; spring@ietf.org
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG= adoption call

 

Dear Authors,

 

Have few comments on the draft:

 

1. 

      &nb= sp; As I indicated during meeting - I am not sure why we have to club = verification of SIDs advertised through regular protocol reachability

      &nb= sp;         prefixes and the ranges= advertised through 'Mapping Server'  (SRMS). I didn't see any compell= ing reason to do this.

      &nb= sp;          SIDs advertised t= hrough reachability prefixes doesn't have ranges unlike SRMS advertisements= . 

      &nb= sp;          As SRMS advertise= ments are primarily for nodes which are not SR capable and  I feel we = should not mix this with nodes which are SR capable.

 

      &nb= sp; This isolation helps restricting the resolution work primarily for mult= iple SRMS entries advertised through one node or multiple nodes.

      &nb= sp;         SRMS advertisements are= indeed little bit unique in that you are advertising "configuration&q= uot; on behalf of node X from node Y

      &nb= sp;         with ranges (both prefi= x ranges and SID ranges).

 

 

2. 

      &nb= sp;         Regarding  the sco= pe of conflict resolution:

 

 

       Se= ction 1

 

      &nb= sp;    "   The problem to be addressed is protocol independent i= .e., segment

      =    related advertisements may be originated by multiple nodes usi= ng

      =    different protocols and yet the conflict resolution MUST be th= e same

      =    on all nodes regardless of the protocol used to transport the<= /span>

      =    advertisements."

 

      =   Section 3.2.8

      =     "   o  In cases where multiple routi= ng protocols are in use mapping

      entri= es advertised by all routing protocols MUST be included."

 

      This sou= nds like we are seeking to resolve conflicting entries outside and across t= he protocols?

      Each IGP= has separate mechanism for advertising mapping entry and I this is not cle= ar with the current version of the draft how we can cross verify SID/Prefix= conflict across  the protocol.

     Can you clarif= y this?

 

 

--

Uma C.

 

 

-----Original Message-----
From: spring [mailto:spring-boun= ces@ietf.org] On Behalf Of bruno.decraene@orange.com<= br> Sent: Thursday, April 14, 2016 12:55 AM
To: spring@ietf.org
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adopti= on call

 

> From:  bruno.decraene@orange.com = > Sent: Thursday, April 14, 2016 9:51

> AM

>

> Dear WG,

>

> As we discussed at our meeting las= t week, working group adoption has

> been requested for draft-ginsberg-= spring-conflict-resolution.

> Please reply to the list with your= comments, including although not

> limited to whether or not you supp= ort adoption.

 

We will end the call on April 29, 2016.=

 

 

> Thanks,

>

> --John and Bruno=

>

>

>

> __________________________________= ________________________

> __________________________________= ________________________

> _____

>

> Ce message et ses pieces jointes p= euvent contenir des informations

> confidentielles ou privilegiees et= ne doivent donc pas etre diffuses,

> exploites ou copies sans autorisat= ion. Si vous avez recu ce message

> par erreur, veuillez le signaler a= l'expediteur et le detruire ainsi

> que les pieces jointes. Les messag= es electroniques etant susceptibles

> d'alteration, Orange decline toute= responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

>

> This message and its attachments m= ay contain confidential or

> privileged information that may be= protected by law; they should not

> be distributed, used or copied wit= hout authorisation.

> If you have received this email in= error, please notify the sender and

> delete this message and its attach= ments.

> As emails may be altered, Orange i= s not liable for messages that have

> been modified, changed or falsifie= d.

> Thank you.

>

> __________________________________= _____________

> spring mailing list

 

_______________________________________= ___________________________________________________________________________= _______

 

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

 

This message and its attachments may co= ntain confidential or privileged information that may be protected by law; = they should not be distributed, used or copied without authorisation.<= /o:p>

If you have received this email in erro= r, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not= liable for messages that have been modified, changed or falsified.

Thank you.

 

_______________________________________= ________

spring mailing list

 

--_000_1B502206DFA0C544B7A60469152008635BCD31ABeusaamb106erics_-- From nobody Wed May 4 09:27:58 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B66D712DB00 for ; Wed, 4 May 2016 09:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.915 X-Spam-Level: X-Spam-Status: No, score=-2.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 n-tsZtX4XM_W for ; Wed, 4 May 2016 09:27:55 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B63C612DDD1 for ; Wed, 4 May 2016 09:17:07 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 04AB7C03FD for ; Wed, 4 May 2016 18:17:06 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.27]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id D8D5C120073 for ; Wed, 4 May 2016 18:17:05 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0294.000; Wed, 4 May 2016 18:17:05 +0200 From: To: "spring@ietf.org" Thread-Topic: Working Group Last Call for OSPF Extensions for Segment Routing - draft-ietf-ospf-segment-routing-extensions Thread-Index: AdGmIF7grjskx3QsQZ+wcY6STvDhGw== Date: Wed, 4 May 2016 16:17:05 +0000 Message-ID: <30526_1462378625_572A2081_30526_882_6_53C29892C857584299CBF5D05346208A0F895B9D@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [spring] FW: Working Group Last Call for OSPF Extensions for Segment Routing - draft-ietf-ospf-segment-routing-extensions X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 16:27:56 -0000 Hi all, FYI, the OSPF extensions for Segment Routing is being last called in the OS= PF Working Group. You may want to review and comment, on the _OSPF_ mailing list. Thanks, -- Bruno -----Original Message----- From: OSPF [mailto:ospf-bounces@ietf.org] On Behalf Of Acee Lindem (acee) Sent: Wednesday, May 04, 2016 5:41 PM To: OSPF WG List Cc: draft-ietf-ospf-segment-routing-extensions@ietf.org Subject: [OSPF] Working Group Last Call for OSPF Extensions for Segment Rou= ting - draft-ietf-ospf-segment-routing-extensions (Correct Draft Authors E-= mail) The subject draft is very stable, has multiple interoperable implementations, and many (including myself) have done thorough reviews. I believe we are ready for WG last call for this very important draft. With great pleasure, this begins the WG last call for the subject draft. Please send your comments to this list prior to 12:00 AM GMT, May 19th, 2016. Here is a URL for your convenance: https://datatracker.ietf.org/doc/draft-ietf-ospf-segment-routing-extensions / Thanks, Acee _______________________________________________ OSPF mailing list OSPF@ietf.org https://www.ietf.org/mailman/listinfo/ospf ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Wed May 4 09:48:36 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D8B812DA30 for ; Wed, 4 May 2016 09:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QmCOUnRsVLTS for ; Wed, 4 May 2016 09:48:31 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCAAB12DB31 for ; Wed, 4 May 2016 09:38:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=72192; q=dns/txt; s=iport; t=1462379884; x=1463589484; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=yhm3c8WXr9Pmuh8CjM7hLISMHNPm9x4QdPfU3Lah4dE=; b=OxvbY6lcaOqyoSwT1bARDZfqpLo8FKhjiYgRtpulc1wk490oQGqrpk1q MBR3TiKtEK/lfHKoelEwT6pE6k3Vf3yx2NwT+pvBkNIU0O9xX0i9Yd45I qrJ/l3lBje33jFlq79FlVbcuwXoT9Wm7Oq9FPik02ZlWo3DtSOdyi8qN+ E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AgAgBRJCpX/5ldJa1fgmxMU30GuWMBD?= =?us-ascii?q?YFyBBcBCoUkSgKBNzgUAQEBAQEBAWUnhEEBAQEDAQEBARcTQRAHBAIBCBEEAQE?= =?us-ascii?q?hAQYHJwsUCQgBAQQBEggTiAcIDr0vAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGI?= =?us-ascii?q?IRNhBEKBwEGTIUjBZMkhHUBiHKFHoFvhE2IXo8zAR4BAUKCBRuBS2yGfgkXH38?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.24,578,1454976000"; d="scan'208,217";a="100978561" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 May 2016 16:38:02 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u44Gc2BF028628 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 4 May 2016 16:38:02 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 4 May 2016 11:38:01 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Wed, 4 May 2016 11:38:01 -0500 From: "Les Ginsberg (ginsberg)" To: Uma Chunduri , "bruno.decraene@orange.com" , "spring@ietf.org" Thread-Topic: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call Thread-Index: AdGWIcRdLnRAPWN3Qn6eVontUw9C0AAAMhXQAqz8LVAApDM0UACH8IyQACYbxPA= Date: Wed, 4 May 2016 16:38:01 +0000 Message-ID: <445eeb6f8f12480f90e941a81eeaafc7@XCH-ALN-001.cisco.com> References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10411_1460620508_570F4CDC_10411_96_23_53C29892C857584299CBF5D05346208A0F86E45F@OPEXCLILM21.corporate.adroot.infra.ftgroup> <1B502206DFA0C544B7A6046915200863580C54E9@eusaamb105.ericsson.se> <0468fb2fe35841668bc35606e988074c@XCH-ALN-001.cisco.com> <1B502206DFA0C544B7A60469152008635BCD31AB@eusaamb106.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008635BCD31AB@eusaamb106.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.110.137] Content-Type: multipart/alternative; boundary="_000_445eeb6f8f12480f90e941a81eeaafc7XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 16:48:35 -0000 --_000_445eeb6f8f12480f90e941a81eeaafc7XCHALN001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Uma - To restate, the problem being addressed here is to guarantee consistent use= of SIDs in the forwarding plane network-wide in the presence of conflictin= g advertisements. The set of advertisements includes both SIDs advertised i= n protocol prefix reachability advertisements and SRMS advertisements becau= se problems occur based upon inconsistencies in what is installed in the fo= rwarding plane of different routers. It matters not whether Router A used a= SID advertised by a protocol prefix reachability advertisement or by an SR= MS advertisement - what matter is whether the SID used is consistent with w= hat the neighbors of Router A use. So simply ensuring that OSPF (for exampl= e) resolves SIDs in a consistent way does not fully address the problem spa= ce. More inline. From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] Sent: Tuesday, May 03, 2016 3:59 PM To: Les Ginsberg (ginsberg); bruno.decraene@orange.com; spring@ietf.org Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution - WG adopti= on call Les, With all due respects, cross protocol verification of prefix and SID confl= icts as an "architectural change" and it can severely impact the existing = implementations (at least the one I work on). [Les:] It is quite correct - and I can confirm based on personal experience= - that support for conflict resolution is a significant effort. Also I have couple of cases where current version of the draft is not clear= about resolution. IMO, first we need clarity with in a protocol instance resolution rules bef= ore going to resolve the same across protocols (I mentioned few cases below= ) . Separation of reachability advertisements and SRMS would help "cross protoc= ol" verification of the ranges and SRMS is not applicable to all protocols. In-line [Uma]: -- Uma C. From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Saturday, April 30, 2016 10:11 PM To: Uma Chunduri; bruno.decraene@orange.com; spring@ietf.org Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution - WG adopti= on call Uma - We are indeed defining conflict resolution across all the SID advertisement= s regardless of source (protocol or SRMS) - [Uma]: While you can theoretically do anything for current implementation t= his kind of cross protocol verification is a new architectural requirement. Because it seems "a central entity" need to gather all diffe= rent protocol instances SRMS advertisements and should settle with resoluti= on. - Also note SRMS is not applicable for BGP but it seems all prefix= SIDs need to be verified with IGP instances SRMS advertisements. Is this = true? While the document mostly talks about these and compares with prefix = advertisement. [Les:] The issue is protocol agnostic. - Algorithm proposed needs more clarity: Take Section 3.2.4 o " 1. Smaller range wins 2. IPv6 entry wins over IPv4 entry ... " What happens in case of prefix conflict or SID conflict wi= th only prefix advertisements (range 1). Say multiple prefixes have same S= ID in one protocol instance and in different protocols. I see 2 levels of resolution required viz., one at within = the protocol and one among the protocols. No discussion on this. [Les:] The full set of rules specified in the draft provide deterministic r= esolution in all cases. You have snipped only the first two rules. If a pre= ference is not obtained based on the first two rules you continue on to rul= e #3, then rule #4, etc. Similarly in case of SID conflict (range 1), it's not spe= cified which protocol's SID need to be considered. Are you assuming some s= ort of Admin distance play a role in resolution? [Les:] No - admin distance plays no role here. I don't see any discussion in the document and needs more clarity there t= oo. o Also what happens if a prefix or SID conflict happens with SRMS range 1= and a prefix advertisement (2 cases) a. of one protocol and b. multiple protocols? [Les:] The source of the SID advertisement (what protocol/protocol instance= or whether it is SRMS based) plays no role. The tie breaker rules as defin= ed are complete and provide a deterministic answer in all cases. If you believe that is not true please provide a specific example where you= apply all the rules in the order specified and still do not determine the = preferred entry. - On the below assumption: (Section 3.2.4) "This has the nice property that a= single misconfiguratoion of an SRMS entry with a large range will not be preferred over a larg= e number of SIDs advertised in prefix reachability advertisements." While anything can happen in theory, I found it bit odd to see why SRMS ent= ry is being advertised and for the same prefix, SID is also advertised thro= ugh reachability advertisements? This is against the spirit of SRMS advertisement, isn't it? While this can = happen, it seems we are claiming resolution solution by focusing more on t= his case in the current version of the document. [Les:] There are two legitimate use cases for SRMS: 1)To advertise SIDs for non-SR capable nodes 2)As a global provisioning tool Let's examine the first case. I have an LDP enabled network and I begin int= roducing SR capable nodes. At a given moment in time Router A is NOT SR cap= able and SRMS advertisements cover prefix SIDs for the addresses associated= with Router A. I then upgrade Router A to become SR capable. Because I want to do "make-be= fore-break" I do not immediately remove the SRMS advertisements covering th= e addresses associated with Router A. I upgrade A, add configuration of SID= s locally on Router A, and verify that the advertisements originating from = protocols on Router A are correct. If an inconsistency is introduced when c= onfiguring the SIDs on Router A then I will have an SRMS advertisement and = a prefix-reachability advertisement that conflict. Until the conflict is co= rrected we use the conflict resolution rules to provide deterministic forwa= rding behavior. This to me is a normal and expected upgrade scenario. This is one of the reasons of my first comment below. You got to separate t= he reachability advertisements and SRMS advertisements; as in principle the= se are defined for different purposes. I don't see we need algorithm to pr= efer reachability advertisement over SRMS advertisement (if we don't compar= e these 2 categories). [Les:] I disagree - hopefully my comments have helped you to understand why= . Les as the sections you have quoted clearly state. Why? Because we need consistent use of SIDs in the forwarding plane. From f= orwarding perspective it matters not whether the SID was advertised by prot= ocol instance #1 or #2 or by an SRMS. What matters is that the SID I use to determine what label I install in my = forwarding plane is the same SID that my neighbors will use. Otherwise forw= arding will be broken. Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Uma Chunduri Sent: Wednesday, April 27, 2016 4:31 PM To: bruno.decraene@orange.com; spring@iet= f.org Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adopti= on call Dear Authors, Have few comments on the draft: 1. As I indicated during meeting - I am not sure why we have to club = verification of SIDs advertised through regular protocol reachability prefixes and the ranges advertised through 'Mapping Server'= (SRMS). I didn't see any compelling reason to do this. SIDs advertised through reachability prefixes doesn't have= ranges unlike SRMS advertisements. As SRMS advertisements are primarily for nodes which are n= ot SR capable and I feel we should not mix this with nodes which are SR ca= pable. This isolation helps restricting the resolution work primarily for = multiple SRMS entries advertised through one node or multiple nodes. SRMS advertisements are indeed little bit unique in that yo= u are advertising "configuration" on behalf of node X from node Y with ranges (both prefix ranges and SID ranges). 2. Regarding the scope of conflict resolution: Section 1 " The problem to be addressed is protocol independent i.e., se= gment related advertisements may be originated by multiple nodes using different protocols and yet the conflict resolution MUST be the sa= me on all nodes regardless of the protocol used to transport the advertisements." Section 3.2.8 " o In cases where multiple routing protocols are in use mappi= ng entries advertised by all routing protocols MUST be included." This sounds like we are seeking to resolve conflicting entries outsid= e and across the protocols? Each IGP has separate mechanism for advertising mapping entry and I t= his is not clear with the current version of the draft how we can cross ver= ify SID/Prefix conflict across the protocol. Can you clarify this? -- Uma C. -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, April 14, 2016 12:55 AM To: spring@ietf.org Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adopti= on call > From: bruno.decraene@orange.com > Sent= : Thursday, April 14, 2016 9:51 > AM > > Dear WG, > > As we discussed at our meeting last week, working group adoption has > been requested for draft-ginsberg-spring-conflict-resolution. > Please reply to the list with your comments, including although not > limited to whether or not you support adoption. We will end the call on April 29, 2016. > Thanks, > > --John and Bruno > > > > __________________________________________________________ > __________________________________________________________ > _____ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > que les pieces jointes. Les messages electroniques etant susceptibles > d'alteration, Orange decline toute responsabilite si ce message a ete alt= ere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_445eeb6f8f12480f90e941a81eeaafc7XCHALN001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Uma –

 <= /p>

To restate, the problem b= eing addressed here is to guarantee consistent use of SIDs in the forwardin= g plane network-wide in the presence of conflicting advertisements. The set of advertisements includes both SIDs advertised in protocol prefix= reachability advertisements and SRMS advertisements because problems occur= based upon inconsistencies in what is installed in the forwarding plane of= different routers. It matters not whether Router A used a SID advertised by a protocol prefix reachability a= dvertisement or by an SRMS advertisement – what matter is whether the= SID used is consistent with what the neighbors of Router A use. So simply = ensuring that OSPF (for example) resolves SIDs in a consistent way does not fully address the problem space.

 <= /p>

More inline.

 <= /p>

From: Uma Chun= duri [mailto:uma.chunduri@ericsson.com]
Sent: Tuesday, May 03, 2016 3:59 PM
To: Les Ginsberg (ginsberg); bruno.decraene@orange.com; spring@ietf.= org
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution - WG= adoption call

 

Les,

 <= /p>

With all due respects, cr= oss protocol verification  of prefix and SID conflicts as an “ar= chitectural change”  and it can severely impact the existing imp= lementations (at least the one I work on).

 

[Les:] It is quite = correct – and I can confirm based on personal experience – that= support for conflict resolution is a significant effort.=

 <= /p>

Also I have couple of cas= es where current version of the draft is not clear about resolution.

 <= /p>

IMO, first we need clarit= y with in a protocol instance resolution rules before going to resolve the = same across protocols (I mentioned few cases below) .

Separation of reachabilit= y advertisements and SRMS would help “cross protocol” verificat= ion of the ranges and SRMS is not applicable to all protocols.

 <= /p>

 <= /p>

In-line [Uma]:<= o:p>

 <= /p>

--

Uma C.<= /p>

 <= /p>

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisc= o.com]
Sent: Saturday, April 30, 2016 10:11 PM
To: Uma Chunduri; bruno= .decraene@orange.com; spring@ietf.org
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution - WG= adoption call

 

Uma –

 <= /p>

We are indeed defining co= nflict resolution across all the SID advertisements regardless of source (p= rotocol or SRMS) –

 <= /p>

[Uma]: While you can theo= retically do anything for current implementation this kind of cross protoco= l verification is a new architectural requirement.  =

    &= nbsp;          Because it= seems “a central entity” need to gather all different protocol= instances SRMS advertisements and should settle with resolution. 

 <= /p>

-  &n= bsp;       Also note SRMS is= not applicable for BGP but it seems all prefix SIDs need to be verified &n= bsp;with IGP instances SRMS advertisements. Is this true? While the document mostly talks about these and compares with prefix advertiseme= nt.

[Les:] The issue is= protocol agnostic.

 <= /p>

-  &n= bsp;       Algorithm propose= d needs more clarity: Take Section 3.2.4

 <= /span>

o    = 

   &nbs=
p;            &=
nbsp;     “   1.  Smaller r=
ange wins

 

    &nbs= p;        2.  IPv6 entry wins over = IPv4 entry

    = ;         …

 &nb= sp;      “

           &nbs= p;     What happens in case of prefix conflict or SID c= onflict with only prefix advertisements (range 1).  Say multiple prefixes have same SID in one protocol instance and in different protocols= .

           &nbs= p;     I see 2 levels of resolution required viz., one = at within the protocol and one among the protocols.  No discussion on this.

 

[Les:] The full set= of rules specified in the draft provide deterministic resolution in all ca= ses. You have snipped only the first two rules. If a preference is not obtained based on the first two rules you continue on to rule #3, t= hen rule #4, etc.

 <= /p>

           &nbs= p;     Similarly in case of SID conflict  (range 1= ), it’s not specified which protocol’s SID need to be considere= d.  Are you assuming some sort of Admin distance play a role in resolution? <= /o:p>

[Les:] No – a= dmin distance plays no role here.

 <= /p>

 I don’t see any discussion in the docum= ent  and needs more clarity there too.

o   Also what happens= if a prefix or SID conflict happens with SRMS range 1 and a prefix  a= dvertisement (2 cases)

a.  &= nbsp;    of one protocol a= nd

b.  &= nbsp;   multiple protocol= s?

 <= /span>

[Les:] The source of the SID advertisement (what protocol/p= rotocol instance or whether it is SRMS based) plays no role. The tie breaker rules as defined are complete and provide a deterministic = answer in all cases.

If you believe that is not true please provide a specific e= xample where you apply all the rules in the order specified and still do not determine the preferred entry.<= /p>

 

 

-  &n= bsp;       On the below assu= mption: (Section 3.2.4)

   &nbs=
p;             =
            &nb=
sp;           “This has the nice property that a single misconfiguratoion of an SRMS
      &nbs=
p;          entry with a =
large range will not be preferred over a large number of
      &nbs=
p;          SIDs advertis=
ed in prefix reachability advertisements.”

While anything can happen in theory, I found it bit odd to see = why SRMS entry is being advertised and for the same prefix, SID is also advertised through reachability advertisements?

This is against the spirit of SRMS advertisement, isn’t i= t? While this can happen, it seems we are claiming resolution solution by focusing more on  this case in the current version of the document= .

 

[Les:] There are two legitimate use cases for SRMS:

 

1)To advertise SIDs for non-SR capable nodes

2)As a global provisioning tool

 

Let’s examine the first case. I have an LDP enabled n= etwork and I begin introducing SR capable nodes. At a given moment in time Router A is NOT SR capable and SRMS advertisements cover prefix SI= Ds for the addresses associated with Router A.

I then upgrade Router A to become SR capable. Because I wan= t to do “make-before-break” I do not immediately remove the SRMS advertisements covering the addresses associated with Router A. I upg= rade A, add configuration of SIDs locally on Router A, and verify that the = advertisements originating from protocols on Router A are correct. If an in= consistency is introduced when configuring the SIDs on Router A then I will have an SRMS advertisement and a prefix-r= eachability advertisement that conflict. Until the conflict is corrected we= use the conflict resolution rules to provide deterministic forwarding beha= vior.

 

This to me is a normal and expected upgrade scenario.<= /o:p>

 

 

This is one of the reasons of my first comment below. You got t= o separate the reachability advertisements and SRMS advertisements; as in principle these are defined for different purposes. I don’t se= e we  need algorithm to prefer reachability advertisement over SRMS ad= vertisement (if we don’t compare these 2 categories).

&n=
bsp;

 

 <= /p>

[Les:] I disagree &= #8211; hopefully my comments have helped you to understand why.<= /span>

 

   Les

 <= /p>

 <= /p>

as the sections you have = quoted clearly state.

 <= /p>

Why? Because we need cons= istent use of SIDs in the forwarding plane. From forwarding perspective it = matters not whether the SID was advertised by protocol instance #1 or #2 or by an SRMS.

 <= /p>

What matters is that the = SID I use to determine what label I install in my forwarding plane is the s= ame SID that my neighbors will use. Otherwise forwarding will be broken.

 <= /p>

   Les

 <= /p>

 <= /p>

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Uma Chunduri
Sent: Wednesday, April 27, 2016 4:31 PM
To: bruno.decraene@oran= ge.com; spring@ietf.org
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG= adoption call

 

Dear Authors,

 

Have few comments on the draft:

 

1. 

      &nb= sp; As I indicated during meeting - I am not sure why we have to club = verification of SIDs advertised through regular protocol reachability

      &nb= sp;         prefixes and the ranges= advertised through 'Mapping Server'  (SRMS). I didn't see any compell= ing reason to do this.

      &nb= sp;          SIDs advertised t= hrough reachability prefixes doesn't have ranges unlike SRMS advertisements= . 

      &nb= sp;          As SRMS advertise= ments are primarily for nodes which are not SR capable and  I feel we = should not mix this with nodes which are SR capable.

 

      &nb= sp; This isolation helps restricting the resolution work primarily for mult= iple SRMS entries advertised through one node or multiple nodes.

      &nb= sp;         SRMS advertisements are= indeed little bit unique in that you are advertising "configuration&q= uot; on behalf of node X from node Y

      &nb= sp;         with ranges (both prefi= x ranges and SID ranges).

 

 

2. 

      &nb= sp;         Regarding  the sco= pe of conflict resolution:

 

 

       Se= ction 1

 

      &nb= sp;    "   The problem to be addressed is protocol independent i= .e., segment

      =    related advertisements may be originated by multiple nodes usi= ng

      =    different protocols and yet the conflict resolution MUST be th= e same

      =    on all nodes regardless of the protocol used to transport the<= /span>

      =    advertisements."

 

      =   Section 3.2.8

      =     "   o  In cases where multiple routi= ng protocols are in use mapping

      entri= es advertised by all routing protocols MUST be included."

 

      This sou= nds like we are seeking to resolve conflicting entries outside and across t= he protocols?

      Each IGP= has separate mechanism for advertising mapping entry and I this is not cle= ar with the current version of the draft how we can cross verify SID/Prefix= conflict across  the protocol.

     Can you clarif= y this?

 

 

--

Uma C.

 

 

-----Original Message-----
From: spring [mailto:spring-boun= ces@ietf.org] On Behalf Of bruno.decraene@orange.com<= br> Sent: Thursday, April 14, 2016 12:55 AM
To: spring@ietf.org
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adopti= on call

 

> From:  bruno.decraene@orange.com = > Sent: Thursday, April 14, 2016 9:51

> AM

>

> Dear WG,

>

> As we discussed at our meeting las= t week, working group adoption has

> been requested for draft-ginsberg-= spring-conflict-resolution.

> Please reply to the list with your= comments, including although not

> limited to whether or not you supp= ort adoption.

 

We will end the call on April 29, 2016.=

 

 

> Thanks,

>

> --John and Bruno=

>

>

>

> __________________________________= ________________________

> __________________________________= ________________________

> _____

>

> Ce message et ses pieces jointes p= euvent contenir des informations

> confidentielles ou privilegiees et= ne doivent donc pas etre diffuses,

> exploites ou copies sans autorisat= ion. Si vous avez recu ce message

> par erreur, veuillez le signaler a= l'expediteur et le detruire ainsi

> que les pieces jointes. Les messag= es electroniques etant susceptibles

> d'alteration, Orange decline toute= responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

>

> This message and its attachments m= ay contain confidential or

> privileged information that may be= protected by law; they should not

> be distributed, used or copied wit= hout authorisation.

> If you have received this email in= error, please notify the sender and

> delete this message and its attach= ments.

> As emails may be altered, Orange i= s not liable for messages that have

> been modified, changed or falsifie= d.

> Thank you.

>

> __________________________________= _____________

> spring mailing list

 

_______________________________________= ___________________________________________________________________________= _______

 

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

 

This message and its attachments may co= ntain confidential or privileged information that may be protected by law; = they should not be distributed, used or copied without authorisation.<= /o:p>

If you have received this email in erro= r, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not= liable for messages that have been modified, changed or falsified.

Thank you.

 

_______________________________________= ________

spring mailing list

 

--_000_445eeb6f8f12480f90e941a81eeaafc7XCHALN001ciscocom_-- From nobody Wed May 4 10:12:17 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB5512D559 for ; Wed, 4 May 2016 10:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prisazA7DJco for ; Wed, 4 May 2016 10:12:15 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 D624312D0F6 for ; Wed, 4 May 2016 10:10:51 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id u64so68083619lff.3 for ; Wed, 04 May 2016 10:10:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=wqhUyueKEjgWDM24Vymucw0eDDgVZS74NgU0uI4uI0g=; b=gtvRRgklmIT//HWiqPteUZT/HGWOdp68KQNzvBwA3YYEuNgcGzs8BKNcZ9elyh5E30 t4Ju1+Crtd+KW7d1P4fzvVMfr4WRWJ+KeSdyPdT921dZv/yzdLYBn/KQi9d4cewX6mVU qk0h/zZ65N8iCbTXbeBEDPMf2XW8OwenvQ07Eo1DWBjOqhJOwYR57Yel3HOnUjTFddcy oTDnNBR7rulcve4YCUeJXBxLrjuDRcURfrXHpRvmaeG+FEVtv6rEzyH/B49mhCATSefj 77infwsbU1nlDgGX1CAcdtzaRb3TqSigEgknyMBZBudAz8T53NM7M2qS2Ip8L1owAOC2 olSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=wqhUyueKEjgWDM24Vymucw0eDDgVZS74NgU0uI4uI0g=; b=bt71vD/1fa9cy2UKV3bdOzL2g6ETttUejk/4sIuLuZUFvAV1cT8jj48JhbxpCSf8Tt UVuOYR6NL7z/e6T+1wIgwerMNE3OcCNWN/IitEz0qFxuMD+KoJ12pfJwZyonxEfcoi+w zDjSe52W8pKNrxTGo9oRE9LMOPuqn9HMtmuTmr7VqcE0IkSpojCJ1Ya4l2dDSWddBEce OjabLrFidj1YyZdkKSGKDbyHO+9B/oVe+P/29nUMIJFA3g8+sFMFDccJ6RHvdgBpOLXq d5JmQBrbgCM3BJQAuosWP0fjfGgKpPuh5Q2FilxZsO5Tavto1Aad1u0IqmDWUHCGtSSz Zbnw== X-Gm-Message-State: AOPr4FWK9G0xrENMKWGGfcjA1AvDK46RvmhkiHID2XZOjjFe5sC3FstmOmoqJbPR4AvdyDxG5vThUF4BqweDnQ== MIME-Version: 1.0 X-Received: by 10.25.142.141 with SMTP id q135mr4914571lfd.11.1462381850039; Wed, 04 May 2016 10:10:50 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.20.21 with HTTP; Wed, 4 May 2016 10:10:49 -0700 (PDT) In-Reply-To: <0468fb2fe35841668bc35606e988074c@XCH-ALN-001.cisco.com> References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10411_1460620508_570F4CDC_10411_96_23_53C29892C857584299CBF5D05346208A0F86E45F@OPEXCLILM21.corporate.adroot.infra.ftgroup> <1B502206DFA0C544B7A6046915200863580C54E9@eusaamb105.ericsson.se> <0468fb2fe35841668bc35606e988074c@XCH-ALN-001.cisco.com> Date: Wed, 4 May 2016 19:10:49 +0200 X-Google-Sender-Auth: 3GbjdtQyArtSg8v7n64_Atpidlo Message-ID: From: Robert Raszuk To: "Les Ginsberg (ginsberg)" Content-Type: multipart/alternative; boundary=001a114014c8b29e9e0532074e85 Archived-At: Cc: "bruno.decraene@orange.com" , "spring@ietf.org" , Uma Chunduri Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 May 2016 17:12:17 -0000 --001a114014c8b29e9e0532074e85 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Les, Your draft represents a view from only a single domian perspective and a lot of wording there seems to imply that conflict resolution must be global per router and does not depend on the RIB/FIB context. Perhaps you are not considering identical SIDs to be used for example by L3VPN customers connecting to SP network with BGP or OSPF and wishing to use SR within their sites. Is this accidental or on purpose ? Can't customers connecting to a given network's different RIBs (via VRFs) use the same SIDs as other customers or for that matter SP itself ? Nothing breaks if they do - as their forwarding is hidden under the SP forwarding, but I see no place in your document to relax conflict resolution in those deployments. Same for CSC. Thx, R. On Sun, May 1, 2016 at 7:10 AM, Les Ginsberg (ginsberg) wrote: > Uma =E2=80=93 > > > > We are indeed defining conflict resolution across all the SID > advertisements regardless of source (protocol or SRMS) =E2=80=93 as the s= ections > you have quoted clearly state. > > > > Why? Because we need consistent use of SIDs in the forwarding plane. From > forwarding perspective it matters not whether the SID was advertised by > protocol instance #1 or #2 or by an SRMS. What matters is that the SID I > use to determine what label I install in my forwarding plane is the same > SID that my neighbors will use. Otherwise forwarding will be broken. > > > > Les > --001a114014c8b29e9e0532074e85 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Les,

=
Your draft represents a view from only a single domian p= erspective and a lot of wording there seems to imply that conflict resoluti= on must be global per router and does not depend on the =C2=A0RIB/FIB conte= xt.

Perhaps you are no= t considering identical SIDs to be used for example by L3VPN customers conn= ecting to SP network with BGP or OSPF and wishing to use SR within their si= tes.=C2=A0

Is this acc= idental or on purpose ?=C2=A0

Can't customers connecting to a given network's different = RIBs (via VRFs) use the same SIDs as other customers or for that matter SP = itself ? Nothing breaks if they do - as their forwarding is hidden under th= e SP forwarding, but I see no place in your document to relax conflict reso= lution in those deployments.=C2=A0

Same for CSC.

Thx,
R.


On Sun, May 1, 2016 = at 7:10 AM, Les Ginsberg (ginsberg) <ginsberg@cisco.com> wr= ote:

Uma =E2=80=93

=C2=A0

We are indeed defining co= nflict resolution across all the SID advertisements regardless of source (p= rotocol or SRMS) =E2=80=93 as the sections you have quoted clearly state.

=C2=A0

Why? Because we need cons= istent use of SIDs in the forwarding plane. From forwarding perspective it = matters not whether the SID was advertised by protocol instance #1 or #2 or by an SRMS. What matters is that the SID I use to determine wh= at label I install in my forwarding plane is the same SID that my neighbors= will use. Otherwise forwarding will be broken.

=C2=A0

=C2=A0=C2=A0 Les

--001a114014c8b29e9e0532074e85-- From nobody Fri May 6 13:25:33 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8976A12D50A for ; Fri, 6 May 2016 13:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JcF70YCgIkb for ; Fri, 6 May 2016 13:25:29 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1483012D1A5 for ; Fri, 6 May 2016 13:16:39 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-78-572cf3f93557 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 78.44.09012.9F3FC275; Fri, 6 May 2016 21:43:53 +0200 (CEST) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Fri, 6 May 2016 16:16:36 -0400 From: Uma Chunduri To: "Les Ginsberg (ginsberg)" , "bruno.decraene@orange.com" , "spring@ietf.org" Thread-Topic: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call Thread-Index: AQHRpiTSIwvtcse5JkGIWGS+IKi0Mp+sWAzg Date: Fri, 6 May 2016 20:16:35 +0000 Message-ID: <1B502206DFA0C544B7A60469152008635BCDFEFB@eusaamb106.ericsson.se> References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10411_1460620508_570F4CDC_10411_96_23_53C29892C857584299CBF5D05346208A0F86E45F@OPEXCLILM21.corporate.adroot.infra.ftgroup> <1B502206DFA0C544B7A6046915200863580C54E9@eusaamb105.ericsson.se> <0468fb2fe35841668bc35606e988074c@XCH-ALN-001.cisco.com> <1B502206DFA0C544B7A60469152008635BCD31AB@eusaamb106.ericsson.se> <445eeb6f8f12480f90e941a81eeaafc7@XCH-ALN-001.cisco.com> In-Reply-To: <445eeb6f8f12480f90e941a81eeaafc7@XCH-ALN-001.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.9] Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008635BCDFEFBeusaamb106erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyuXRPuO7PzzrhBhOPSlj82DGH2WLDn43s Fscv/GZ0YPaY8nsjq8eSJT+ZPFqenWQLYI7isklJzcksSy3St0vgyrh17S9rwYo21opv76Yz NjBOPsDSxcjJISFgInGp7QUzhC0mceHeerYuRi4OIYGjjBLtR7+yQDjLGCXOfGtmBKliE9CT +Dj1JztIQkRgCqPEkuMfmUASwgIhEs9PdgHZHECJUInry31BwiICRhJ/lt4F28YioCIxs/Ud G4jNK+ArseBIEyPEghYWiXU3F4PN4RRwlbh7dRUriM0IdNL3U2vA4swC4hK3nsxngjhVQGLJ nvNQZ4tKvHz8jxXCVpTY1z+dHeQGZoF8iSdnIiF2CUqcnPmEZQKjyCwkk2YhVM1CUgVRoiOx YPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYuQoLS7IyU03MtjECIyqYxJsujsY70/3PMQowMGo xMObcEg7XIg1say4MvcQowQHs5IIb/snnXAh3pTEyqrUovz4otKc1OJDjNIcLErivGKPFMOF BNITS1KzU1MLUotgskwcnFINjKze02P+NpUuXns1XHJBZuWjDBYjNpbKX9Uzbdi4XA+omqbV 2Fuesu+SzvC5+0T51NfjPEwS6UJR3SlrXmpWlwjeqSybaDaXNfnVXe8DKesXPz3TK2jnExPG YGuw3eL5vk0u9oIpNR2Wq30fKr1bKT7J9bP94dKn3kxSam8YlnA90N1jaLtaiaU4I9FQi7mo OBEA8x3jr6YCAAA= Archived-At: Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2016 20:25:32 -0000 --_000_1B502206DFA0C544B7A60469152008635BCDFEFBeusaamb106erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Les, 2 quick things. 1. >[Les:] There are two legitimate use cases for SRMS: >1)To advertise SIDs for non-SR = capable nodes >2)As a global provisioning tool I am hearing #2 for the first time. I don't see th= is either discussed earlier in the WG list or captured in architecture do= cument https://tools.ietf.org/html/draft-ietf-spring-segm= ent-routing-07. Even in the protocol extensions document for example https://tools.ietf.org/html/draft-ietf-isis-segmen= t-routing-extensions-06#section-2.4 we always discussed this from non-SR capable nodes PoV. So I request to add this in arc= hitecture document before factoring this for solution in conflict resolutio= n. 2. Also this is the first time ever we have a requirement for cross p= rotocols verification we ought to discuss the implications of this and protocols involved (with in AS or otherwise) in the architecture docume= nt (at least briefly). -- Uma C. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (gi= nsberg) Sent: Wednesday, May 04, 2016 9:38 AM To: Uma Chunduri; bruno.decraene@orange.com; spring@ietf.org Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adopti= on call Uma - To restate, the problem being addressed here is to guarantee consistent use= of SIDs in the forwarding plane network-wide in the presence of conflictin= g advertisements. The set of advertisements includes both SIDs advertised i= n protocol prefix reachability advertisements and SRMS advertisements becau= se problems occur based upon inconsistencies in what is installed in the fo= rwarding plane of different routers. It matters not whether Router A used a= SID advertised by a protocol prefix reachability advertisement or by an SR= MS advertisement - what matter is whether the SID used is consistent with w= hat the neighbors of Router A use. So simply ensuring that OSPF (for exampl= e) resolves SIDs in a consistent way does not fully address the problem spa= ce. More inline. From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] Sent: Tuesday, May 03, 2016 3:59 PM To: Les Ginsberg (ginsberg); bruno.decraene@orange.com; spring@ietf.org Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution - WG adopti= on call Les, With all due respects, cross protocol verification of prefix and SID confl= icts as an "architectural change" and it can severely impact the existing = implementations (at least the one I work on). [Les:] It is quite correct - and I can confirm based on personal experience= - that support for conflict resolution is a significant effort. Also I have couple of cases where current version of the draft is not clear= about resolution. IMO, first we need clarity with in a protocol instance resolution rules bef= ore going to resolve the same across protocols (I mentioned few cases below= ) . Separation of reachability advertisements and SRMS would help "cross protoc= ol" verification of the ranges and SRMS is not applicable to all protocols. In-line [Uma]: -- Uma C. From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Saturday, April 30, 2016 10:11 PM To: Uma Chunduri; bruno.decraene@orange.com; spring@ietf.org Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution - WG adopti= on call Uma - We are indeed defining conflict resolution across all the SID advertisement= s regardless of source (protocol or SRMS) - [Uma]: While you can theoretically do anything for current implementation t= his kind of cross protocol verification is a new architectural requirement. Because it seems "a central entity" need to gather all diffe= rent protocol instances SRMS advertisements and should settle with resoluti= on. - Also note SRMS is not applicable for BGP but it seems all prefix= SIDs need to be verified with IGP instances SRMS advertisements. Is this = true? While the document mostly talks about these and compares with prefix = advertisement. [Les:] The issue is protocol agnostic. - Algorithm proposed needs more clarity: Take Section 3.2.4 o " 1. Smaller range wins 2. IPv6 entry wins over IPv4 entry ... " What happens in case of prefix conflict or SID conflict wi= th only prefix advertisements (range 1). Say multiple prefixes have same S= ID in one protocol instance and in different protocols. I see 2 levels of resolution required viz., one at within = the protocol and one among the protocols. No discussion on this. [Les:] The full set of rules specified in the draft provide deterministic r= esolution in all cases. You have snipped only the first two rules. If a pre= ference is not obtained based on the first two rules you continue on to rul= e #3, then rule #4, etc. Similarly in case of SID conflict (range 1), it's not spe= cified which protocol's SID need to be considered. Are you assuming some s= ort of Admin distance play a role in resolution? [Les:] No - admin distance plays no role here. I don't see any discussion in the document and needs more clarity there t= oo. o Also what happens if a prefix or SID conflict happens with SRMS range 1= and a prefix advertisement (2 cases) a. of one protocol and b. multiple protocols? [Les:] The source of the SID advertisement (what protocol/protocol instance= or whether it is SRMS based) plays no role. The tie breaker rules as defin= ed are complete and provide a deterministic answer in all cases. If you believe that is not true please provide a specific example where you= apply all the rules in the order specified and still do not determine the = preferred entry. - On the below assumption: (Section 3.2.4) "This has the nice property that a= single misconfiguratoion of an SRMS entry with a large range will not be preferred over a larg= e number of SIDs advertised in prefix reachability advertisements." While anything can happen in theory, I found it bit odd to see why SRMS ent= ry is being advertised and for the same prefix, SID is also advertised thro= ugh reachability advertisements? This is against the spirit of SRMS advertisement, isn't it? While this can = happen, it seems we are claiming resolution solution by focusing more on t= his case in the current version of the document. [Les:] There are two legitimate use cases for SRMS: 1)To advertise SIDs for non-SR capable nodes 2)As a global provisioning tool Let's examine the first case. I have an LDP enabled network and I begin int= roducing SR capable nodes. At a given moment in time Router A is NOT SR cap= able and SRMS advertisements cover prefix SIDs for the addresses associated= with Router A. I then upgrade Router A to become SR capable. Because I want to do "make-be= fore-break" I do not immediately remove the SRMS advertisements covering th= e addresses associated with Router A. I upgrade A, add configuration of SID= s locally on Router A, and verify that the advertisements originating from = protocols on Router A are correct. If an inconsistency is introduced when c= onfiguring the SIDs on Router A then I will have an SRMS advertisement and = a prefix-reachability advertisement that conflict. Until the conflict is co= rrected we use the conflict resolution rules to provide deterministic forwa= rding behavior. This to me is a normal and expected upgrade scenario. This is one of the reasons of my first comment below. You got to separate t= he reachability advertisements and SRMS advertisements; as in principle the= se are defined for different purposes. I don't see we need algorithm to pr= efer reachability advertisement over SRMS advertisement (if we don't compar= e these 2 categories). [Les:] I disagree - hopefully my comments have helped you to understand why= . Les as the sections you have quoted clearly state. Why? Because we need consistent use of SIDs in the forwarding plane. From f= orwarding perspective it matters not whether the SID was advertised by prot= ocol instance #1 or #2 or by an SRMS. What matters is that the SID I use to determine what label I install in my = forwarding plane is the same SID that my neighbors will use. Otherwise forw= arding will be broken. Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Uma Chunduri Sent: Wednesday, April 27, 2016 4:31 PM To: bruno.decraene@orange.com; spring@iet= f.org Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adopti= on call Dear Authors, Have few comments on the draft: 1. As I indicated during meeting - I am not sure why we have to club = verification of SIDs advertised through regular protocol reachability prefixes and the ranges advertised through 'Mapping Server'= (SRMS). I didn't see any compelling reason to do this. SIDs advertised through reachability prefixes doesn't have= ranges unlike SRMS advertisements. As SRMS advertisements are primarily for nodes which are n= ot SR capable and I feel we should not mix this with nodes which are SR ca= pable. This isolation helps restricting the resolution work primarily for = multiple SRMS entries advertised through one node or multiple nodes. SRMS advertisements are indeed little bit unique in that yo= u are advertising "configuration" on behalf of node X from node Y with ranges (both prefix ranges and SID ranges). 2. Regarding the scope of conflict resolution: Section 1 " The problem to be addressed is protocol independent i.e., se= gment related advertisements may be originated by multiple nodes using different protocols and yet the conflict resolution MUST be the sa= me on all nodes regardless of the protocol used to transport the advertisements." Section 3.2.8 " o In cases where multiple routing protocols are in use mappi= ng entries advertised by all routing protocols MUST be included." This sounds like we are seeking to resolve conflicting entries outsid= e and across the protocols? Each IGP has separate mechanism for advertising mapping entry and I t= his is not clear with the current version of the draft how we can cross ver= ify SID/Prefix conflict across the protocol. Can you clarify this? -- Uma C. -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, April 14, 2016 12:55 AM To: spring@ietf.org Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adopti= on call > From: bruno.decraene@orange.com > Sent= : Thursday, April 14, 2016 9:51 > AM > > Dear WG, > > As we discussed at our meeting last week, working group adoption has > been requested for draft-ginsberg-spring-conflict-resolution. > Please reply to the list with your comments, including although not > limited to whether or not you support adoption. We will end the call on April 29, 2016. > Thanks, > > --John and Bruno > > > > __________________________________________________________ > __________________________________________________________ > _____ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi > que les pieces jointes. Les messages electroniques etant susceptibles > d'alteration, Orange decline toute responsabilite si ce message a ete alt= ere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or > privileged information that may be protected by law; they should not > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > Thank you. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou = copies sans autorisation. Si vous avez recu ce message par erreur, veuillez= le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Le= s messages electroniques etant susceptibles d'alteration, Orange decline to= ute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used= or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_1B502206DFA0C544B7A60469152008635BCDFEFBeusaamb106erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Les,

 <= /p>

2 quick things.

 <= /p>

1. = ;       =

          = ;  >[Les:] There are two legitimate use cases for SRMS:<= /span>

          = ;            &n= bsp;            &nbs= p;       >1)To advertise SIDs for non= -SR capable nodes

          = ;            &n= bsp;            &nbs= p;       >2)As a global provisioning = tool

           &= nbsp;             I = am hearing #2 for the first time. I don’t see this either  discu= ssed earlier in the WG list  or captured in architecture document

           &= nbsp;           &nbs= p; https://tools.ietf.org/html/draft-ietf-spring-segment-routing-07<= /a>. Even in the protocol extensions document for example

           &= nbsp;           &nbs= p; https://tools.ietf.org/html/draft-ietf-isis-= segment-routing-extensions-06#section-2.4 we always discussed this from non-SR

           &= nbsp;           &nbs= p; capable nodes PoV. So I request to add this in architecture documen= t before factoring this for solution in conflict resolution.       &nb= sp;            =      

 

2. = ;      Also this is the = first time ever we have a requirement for cross protocols verification we o= ught to discuss the implications of this  

and protocols invo= lved (with in AS or otherwise) in the architecture document (at least brief= ly).

 <= /p>

--

Uma C.<= /p>

 <= /p>

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Wednesday, May 04, 2016 9:38 AM
To: Uma Chunduri; bruno.decraene@orange.com; spring@ietf.org
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG= adoption call

 

Uma –

 <= /p>

To restate, the problem b= eing addressed here is to guarantee consistent use of SIDs in the forwardin= g plane network-wide in the presence of conflicting advertisements. The set of advertisements includes both SIDs advertised in protocol prefix= reachability advertisements and SRMS advertisements because problems occur= based upon inconsistencies in what is installed in the forwarding plane of= different routers. It matters not whether Router A used a SID advertised by a protocol prefix reachability a= dvertisement or by an SRMS advertisement – what matter is whether the= SID used is consistent with what the neighbors of Router A use. So simply = ensuring that OSPF (for example) resolves SIDs in a consistent way does not fully address the problem space.

 <= /p>

More inline.

 <= /p>

From: Uma Chun= duri [mailto:uma.chunduri@eric= sson.com]
Sent: Tuesday, May 03, 2016 3:59 PM
To: Les Ginsberg (ginsberg); bruno.decraene@orange.com; spring@ietf.org
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution - WG= adoption call

 

Les,

 <= /p>

With all due respects, cr= oss protocol verification  of prefix and SID conflicts as an “ar= chitectural change”  and it can severely impact the existing imp= lementations (at least the one I work on).

 

[Les:] It is quite = correct – and I can confirm based on personal experience – that= support for conflict resolution is a significant effort.=

 <= /p>

Also I have couple of cas= es where current version of the draft is not clear about resolution.

 <= /p>

IMO, first we need clarit= y with in a protocol instance resolution rules before going to resolve the = same across protocols (I mentioned few cases below) .

Separation of reachabilit= y advertisements and SRMS would help “cross protocol” verificat= ion of the ranges and SRMS is not applicable to all protocols.

 <= /p>

 <= /p>

In-line [Uma]:<= o:p>

 <= /p>

--

Uma C.<= /p>

 <= /p>

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisc= o.com]
Sent: Saturday, April 30, 2016 10:11 PM
To: Uma Chunduri; bruno= .decraene@orange.com; spring@ietf.org
Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution - WG= adoption call

 

Uma –

 <= /p>

We are indeed defining co= nflict resolution across all the SID advertisements regardless of source (p= rotocol or SRMS) –

 <= /p>

[Uma]: While you can theo= retically do anything for current implementation this kind of cross protoco= l verification is a new architectural requirement.  =

    &= nbsp;          Because it= seems “a central entity” need to gather all different protocol= instances SRMS advertisements and should settle with resolution. 

 <= /p>

-  &n= bsp;       Also note SRMS is= not applicable for BGP but it seems all prefix SIDs need to be verified &n= bsp;with IGP instances SRMS advertisements. Is this true? While the document mostly talks about these and compares with prefix advertiseme= nt.

[Les:] The issue is= protocol agnostic.

 <= /p>

-  &n= bsp;       Algorithm propose= d needs more clarity: Take Section 3.2.4

 <= /span>

o    = 

   &nbs=
p;            &=
nbsp;     “   1.  Smaller r=
ange wins

=  

 = ;            2.  IPv= 6 entry wins over IPv4 entry

 = ;            …=

        “

           &nbs= p;     What happens in case of prefix conflict or SID c= onflict with only prefix advertisements (range 1).  Say multiple prefixes have same SID in one protocol instance and in different protocols= .

           &nbs= p;     I see 2 levels of resolution required viz., one = at within the protocol and one among the protocols.  No discussion on this.

 

[Les:] The full set= of rules specified in the draft provide deterministic resolution in all ca= ses. You have snipped only the first two rules. If a preference is not obtained based on the first two rules you continue on to rule #3, t= hen rule #4, etc.

 <= /p>

           &nbs= p;     Similarly in case of SID conflict  (range 1= ), it’s not specified which protocol’s SID need to be considere= d.  Are you assuming some sort of Admin distance play a role in resolution? <= /o:p>

[Les:] No – a= dmin distance plays no role here.

 <= /p>

 I don’t see any discussion in the docum= ent  and needs more clarity there too.

o   Also what happens= if a prefix or SID conflict happens with SRMS range 1 and a prefix  a= dvertisement (2 cases)

a.  &= nbsp;    of one protocol a= nd

b.  &= nbsp;   multiple protocol= s?

 <= /span>

[Les:] The source of the SID advertisement (what protocol/p= rotocol instance or whether it is SRMS based) plays no role. The tie breaker rules as defined are complete and provide a deterministic = answer in all cases.

If you believe that is not true please provide a specific e= xample where you apply all the rules in the order specified and still do not determine the preferred entry.<= /p>

 

 

-  &n= bsp;       On the below assu= mption: (Section 3.2.4)

   &nbs=
p;             =
            &nb=
sp;           “This has the nice property that a single misconfiguratoion of an SRMS
      &nbs=
p;          entry with a =
large range will not be preferred over a large number of
      &nbs=
p;          SIDs advertis=
ed in prefix reachability advertisements.”

While anything can happen in theory, I found it bit odd to see = why SRMS entry is being advertised and for the same prefix, SID is also advertised through reachability advertisements?

This is against the spirit of SRMS advertisement, isn’t i= t? While this can happen, it seems we are claiming resolution solution by focusing more on  this case in the current version of the document= .

 

[Les:] There are two legitimate use cases for SRMS:

 

1)To advertise SIDs for non-SR capable nodes

2)As a global provisioning tool

 

Let’s examine the first case. I have an LDP enabled n= etwork and I begin introducing SR capable nodes. At a given moment in time Router A is NOT SR capable and SRMS advertisements cover prefix SI= Ds for the addresses associated with Router A.

I then upgrade Router A to become SR capable. Because I wan= t to do “make-before-break” I do not immediately remove the SRMS advertisements covering the addresses associated with Router A. I upg= rade A, add configuration of SIDs locally on Router A, and verify that the = advertisements originating from protocols on Router A are correct. If an in= consistency is introduced when configuring the SIDs on Router A then I will have an SRMS advertisement and a prefix-r= eachability advertisement that conflict. Until the conflict is corrected we= use the conflict resolution rules to provide deterministic forwarding beha= vior.

 

This to me is a normal and expected upgrade scenario.<= /o:p>

 

 

This is one of the reasons of my first comment below. You got t= o separate the reachability advertisements and SRMS advertisements; as in principle these are defined for different purposes. I don’t se= e we  need algorithm to prefer reachability advertisement over SRMS ad= vertisement (if we don’t compare these 2 categories).

&n=
bsp;

 

 <= /p>

[Les:] I disagree &= #8211; hopefully my comments have helped you to understand why.<= /span>

 

   Les

 <= /p>

 <= /p>

as the sections you have = quoted clearly state.

 <= /p>

Why? Because we need cons= istent use of SIDs in the forwarding plane. From forwarding perspective it = matters not whether the SID was advertised by protocol instance #1 or #2 or by an SRMS.

 <= /p>

What matters is that the = SID I use to determine what label I install in my forwarding plane is the s= ame SID that my neighbors will use. Otherwise forwarding will be broken.

 <= /p>

   Les

 <= /p>

 <= /p>

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Uma Chunduri
Sent: Wednesday, April 27, 2016 4:31 PM
To: bruno.decraene@oran= ge.com; spring@ietf.org
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG= adoption call

 

Dear Authors,

 

Have few comments on the draft:

 

1. 

      &nb= sp; As I indicated during meeting - I am not sure why we have to club = verification of SIDs advertised through regular protocol reachability

      &nb= sp;         prefixes and the ranges= advertised through 'Mapping Server'  (SRMS). I didn't see any compell= ing reason to do this.

      &nb= sp;          SIDs advertised t= hrough reachability prefixes doesn't have ranges unlike SRMS advertisements= . 

      &nb= sp;          As SRMS advertise= ments are primarily for nodes which are not SR capable and  I feel we = should not mix this with nodes which are SR capable.

 

      &nb= sp; This isolation helps restricting the resolution work primarily for mult= iple SRMS entries advertised through one node or multiple nodes.

      &nb= sp;         SRMS advertisements are= indeed little bit unique in that you are advertising "configuration&q= uot; on behalf of node X from node Y

      &nb= sp;         with ranges (both prefi= x ranges and SID ranges).

 

 

2. 

      &nb= sp;         Regarding  the sco= pe of conflict resolution:

 

 

       Se= ction 1

 

      &nb= sp;    "   The problem to be addressed is protocol independent i= .e., segment

      =    related advertisements may be originated by multiple nodes usi= ng

      =    different protocols and yet the conflict resolution MUST be th= e same

      =    on all nodes regardless of the protocol used to transport the<= /span>

      =    advertisements."

 

      =   Section 3.2.8

      =     "   o  In cases where multiple routi= ng protocols are in use mapping

      entri= es advertised by all routing protocols MUST be included."

 

      This sou= nds like we are seeking to resolve conflicting entries outside and across t= he protocols?

      Each IGP= has separate mechanism for advertising mapping entry and I this is not cle= ar with the current version of the draft how we can cross verify SID/Prefix= conflict across  the protocol.

     Can you clarif= y this?

 

 

--

Uma C.

 

 

-----Original Message-----
From: spring [mailto:spring-boun= ces@ietf.org] On Behalf Of bruno.decraene@orange.com<= br> Sent: Thursday, April 14, 2016 12:55 AM
To: spring@ietf.org
Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adopti= on call

 

> From:  bruno.decraene@orange.com = > Sent: Thursday, April 14, 2016 9:51

> AM

>

> Dear WG,

>

> As we discussed at our meeting las= t week, working group adoption has

> been requested for draft-ginsberg-= spring-conflict-resolution.

> Please reply to the list with your= comments, including although not

> limited to whether or not you supp= ort adoption.

 

We will end the call on April 29, 2016.=

 

 

> Thanks,

>

> --John and Bruno=

>

>

>

> __________________________________= ________________________

> __________________________________= ________________________

> _____

>

> Ce message et ses pieces jointes p= euvent contenir des informations

> confidentielles ou privilegiees et= ne doivent donc pas etre diffuses,

> exploites ou copies sans autorisat= ion. Si vous avez recu ce message

> par erreur, veuillez le signaler a= l'expediteur et le detruire ainsi

> que les pieces jointes. Les messag= es electroniques etant susceptibles

> d'alteration, Orange decline toute= responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

>

> This message and its attachments m= ay contain confidential or

> privileged information that may be= protected by law; they should not

> be distributed, used or copied wit= hout authorisation.

> If you have received this email in= error, please notify the sender and

> delete this message and its attach= ments.

> As emails may be altered, Orange i= s not liable for messages that have

> been modified, changed or falsifie= d.

> Thank you.

>

> __________________________________= _____________

> spring mailing list

 

_______________________________________= ___________________________________________________________________________= _______

 

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

 

This message and its attachments may co= ntain confidential or privileged information that may be protected by law; = they should not be distributed, used or copied without authorisation.<= /o:p>

If you have received this email in erro= r, please notify the sender and delete this message and its attachments.

As emails may be altered, Orange is not= liable for messages that have been modified, changed or falsified.

Thank you.

 

_______________________________________= ________

spring mailing list

 

--_000_1B502206DFA0C544B7A60469152008635BCDFEFBeusaamb106erics_-- From nobody Mon May 9 07:37:13 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F197812D0A5 for ; Mon, 9 May 2016 07:37:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zR9ZVwE7apEK for ; Mon, 9 May 2016 07:37:05 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0735.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:735]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D6A812D09A for ; Mon, 9 May 2016 07:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=2AkEislD8Xguifs48yT4GW1Grs6hnunyI3WjaSePK50=; b=RIZTnvx8QbW84wgEk+84lno0Vjmlv0xYPFs23tSx031j0DdVbd2/TP/xIcT5qOovW4/5A/qZUZi2FkeiRmD8BiPSzMHRCDMAhl+e4EuHM5Mx3uN9nnIQs2sbpiggdp1SqZ7Awf0BkcSr864uNO6B+hzvWCUsWVod19acLL3zI9E= Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net; Received: from [172.29.35.212] (66.129.241.13) by BLUPR05MB786.namprd05.prod.outlook.com (10.141.209.145) with Microsoft SMTP Server (TLS) id 15.1.492.11; Mon, 9 May 2016 14:36:44 +0000 To: References: <56D056A4.7020207@juniper.net> From: Eric C Rosen Message-ID: Date: Mon, 9 May 2016 10:36:39 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <56D056A4.7020207@juniper.net> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [66.129.241.13] X-ClientProxiedBy: CO2PR18CA0034.namprd18.prod.outlook.com (10.161.80.44) To BLUPR05MB786.namprd05.prod.outlook.com (10.141.209.145) X-MS-Office365-Filtering-Correlation-Id: 83deb5f1-7d7e-403b-e40d-08d378175895 X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB786; 2:gCnWmnPb6xzPTj/w2BJcEN6T+LHD1hbuIDUenkc9SFxIFhjDbx/tU1g9+VMFu50HfbtfGf4ahxJr2+JoFIO4sa8MADjeSyy8spQprPJy2ZmCHIIFOs/8BB4PaJIJPujCuC9kOtglm1/EXz2PE2klOc3av4tInFnWkCac7xnNQrx7cBuGmLmWk+oDgDKTMN7u; 3:0ZxWPYfjkdAit0kyuAVR06tji8j9QlHpjwfl6xM7MkRONieiK022SMewQUeXlo3Vw0RPXav5R/ZhOdEOuInAuRW3L/F7M7+tNvApkz+sVEEvXFIzEV/CcYk8crsBeMma X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB786; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB786; 25:Pix2Hjcupq5Sr3C7KGVf7iXUXsFPHvRJiuYuQozz45PH6Moqk3GGMQi4H16KlQ00kSxrkdw/5MazjXb/Gw9z+Lvly5oHy/lOode7oJqGRYKIE8euwD2xu+Ak6Nh8h41Gq0KdARUM3Xxef6OUZ0PkRf4+/a/bO9IuJKg+raLSm58D+Nf2WK69ycOrE845Z3CmXg8ISTKuAQ/OR96qDyF5V4JYftb6+XnMb/Wfwi8eOp+utO6AUoVx41Nf8KSEg9cSTtOTmJ/HIDvWYnd3s7M38ck75ljJsCCmUXLx/ds5EUcs8rRqkXyP7AtGSqhMCgvs+Bnu3cp2Q+Glgy3nI8xXyMd6stf1gRw6eoPRP4dOl0QgelFQgf//Uyx07m97WClIy3DgWXpYHpLXU+DLz5vNaRCRVkdSB99WjgdLgXsraaOZG+QZWwWH3o/RqLHBIOZ3lQAPWJ0b9uywKH2TKmxha8cDXA6x3R5R/0gozz/f97fhFMuwGP0qhN0zZMmXl95Y/Xu0KXnsjAAvn7PSkD4KdIJ5jKSWIXodZ/cTNcu/l4NjFOFQ8X9KiFZ6RZZIfuJwL/3DIrqr+Z/y+TWN11Vc9QUyJ8rCYnwuy9EWE9ik5v+jz/B8p4KHGFXb/QOLA1agAlui50AwbF/+nP2fN5rJrILHLoAwuZALXC6jHwc4+JEiyYeMje7PXbF0oAPn/TdZAlIyCvPRpF1J/hYus7NxlKBkzzYGGWUVrBg6/00IEsMhr8IjH0+gr2VoeR12x0m6nrjhWSULqfMJ8NX4Kb5UUA== X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB786; 20:hSm4XpamRLtJtez8THvnotzYOJwfpbWcIAP3aN9+q10SnCl8WQpK8WlK1sJ8fR8LNl1f+L6+1Jr36Mb8TjvWCaZWDpUltqyaCNp7fEu6+0wV6fv7b488PnXj9Ph0C2Nvpd6I04HuYHREgdkIDKY0SpZ0I4Zr4F2ceZ2kve1h7+r4VlneZuzexeh22fYaUhBcqyEgOaGNJ6ql8lSAfHsrrB4Jj+yHQxl4KAifbrqJeOJlYKXlN+y4GU8fcUN6jvZc1aS0Lli0iOD0H2geD0e6zl/kfhfwlNpXjFp5LHo85EhCCVMJYubBzUaMNLTe4ijdr8zhKApsVDiD1c+KEGkmF16ve/r5s5FEf3inZtiOWeCIqpbFvAI2dfu+ZKuYz4Wsn+sFBIxiXMKrDSAuVao9OgTaW9AAi+CWoIcnGYJ3aAI3BEzAKmeTL7TkgsEcP3m0zrI9Dz9pEKY5AWvQaLhVW38ZUqkyuxXO57EHgMTrLxzGSTw06MBXLabCqRqfuJer; 4:lsXBUJ/0tSsFfUVIAY/qxbE7jxuRMDJpjvopS1Zh8sKLfUMWE+kxDfFw4/ogbMlAGCM2uYgSw80MbmXpvfE4pyPM1C7H8X36Hdu9NJ9+vox0hwv1mS/tD+sDcQowcDIJVCyNnNFiVE4dc+sTTFbpOUJbSgJq9Yf2n/tAIqfDi6hdiXtg8rzHMAAdFrEBr90vaa6wwdsdcsGMAsTfJ9e3O3hD1ZyXE3rjvz3qJGnTKUqygbOiycJbz+fvzN4aOdktoXtPVlNMeuYZCj9LFsk7GlZtpbw05KR2bcQn5TH3UuPVBBQswulKSDcySxHyfztEBWZalX6WTrFsHemq25GTlVlYIWpV/PEa2K2Cr8jXDVcSWydNVEtdmnFBjVvFahtOrTyMQCKKriPNuzuNZClLlg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026); SRVR:BLUPR05MB786; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB786; X-Forefront-PRVS: 0937FB07C5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(24454002)(377454003)(9170700001)(92566002)(86362001)(4001350100001)(23676002)(36756003)(50466002)(5008740100001)(31696002)(76176999)(2906002)(110136002)(42186005)(189998001)(5004730100002)(31686004)(5890100001)(65956001)(6116002)(230700001)(3846002)(586003)(33646002)(47776003)(66066001)(54356999)(2351001)(107886002)(450100001)(77096005)(2950100001)(81166005)(50986999)(65826006); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB786; H:[172.29.35.212]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtCTFVQUjA1TUI3ODY7MjM6SGM2aVRXalBDK3VtUDZTMUtIbVhsZzFncG4y?= =?utf-8?B?UktaVHFpZXdhRlJZRi82VVh0bnZLekFJTzhKYUYzSEZyUlpvYi9WZTBScEpa?= =?utf-8?B?SlF1alVPaDBUTmxwUnBMN3FHS3VNM0Z0OFZubUg0ZWsxWFBGSDFJSm9reG4y?= =?utf-8?B?TDh3RjdBcHhYOXZubTdEam9pRnFBMksyVldGT1dVSFpmdzBHbmYvVkdKVG5o?= =?utf-8?B?RHRIa3p5d20zS0ZHMkNBRE9qVmlwYkxSbS9nMjFYbGJudnRxRWVkQlZJaU42?= =?utf-8?B?MDlUUWhzN3VBTkRwdjVCckJSc1JtVDEwR2ZhR0Rwam1zajVXVmhLZkw1eTRo?= =?utf-8?B?UzM1VWdKK1ZvYWxtVnhZbENaK0F5SUtTaEs0bVpPYms1eVRvUkFPejhLN1po?= =?utf-8?B?VFMvSHhsbk1CaHFTRWJkLzhpbm5Qcks4dWdEZEVHbTNrYmJWV29UbFZzTEFN?= =?utf-8?B?VFFqSVV6YURYTkVKZm1iZGNFRFBNSE9aR0w1aHQwamhPZEJiL2JTMnFPajdo?= =?utf-8?B?NGZpNk53UXN6RFRlc3p3bmt2ZUplL0RNTWhPblZUdTBnNmc1RjNXb1RqUXdT?= =?utf-8?B?dm9OSHB5UjJtRXJkOU1QdnVwUmFhbFJEYjVMbDE2WVFZM0t6RFFLdWc1WUFk?= =?utf-8?B?LzRac1dPZ01LL05zL2h1YW5HUUFISHVEWmRuVVNjVDdvdks5Z3kzV0lKTG5y?= =?utf-8?B?b0J3NnZ6Zi9YenpWN3lnSmxsRXhCLys4bk5KblhjV09SdEZhM1NZVWEwWmZx?= =?utf-8?B?NzQxNVdpZzBwYzQzeUdSNEZUNDBSeFNxQy8rSG5ZUm1jbXU0QXNob1lSbjlo?= =?utf-8?B?MmZ3SHdwbnNER2lWeU5mT3RFYjVYVk5KOVRxV0NJdDQwM0xiVUJlNXJsTkRZ?= =?utf-8?B?Nm01c0FqSUFiZCtzbGQrUTRRR2t1MGhOLzYwZ1Bpd1pHcW5lenV3NEVXUElm?= =?utf-8?B?VzlWQU4vanEvbVBRNkdvS1VZaTVlWDh2MVB4SDJpOUhuRGVNMGxHRlcwaTg2?= =?utf-8?B?bXNKeTVvRG1Mb1laMG40S3M1cE1SNE1RTkVQZzRqYjJndzgwVmVZNEtqaWpz?= =?utf-8?B?WG5OQ2s4a1dzWVozbERhdFUxajIyTUMzMUxyY1pQK0RlcFNGS3BBRDJmWXRK?= =?utf-8?B?U0pGR1VIZVl3WUk5NU9xTjhxVGN0TEhKUXM4WUVwT29naTZMSmNNdXZ4TDJv?= =?utf-8?B?alEwc3U1U28zQ2RKZ2lmZHJLbVdHSUVMYSt2NGVtSWd0TDkyNmN0OG9WRDUv?= =?utf-8?B?K09FYks4aElkNnk2Tnl6T2FmNGFpbjdBNHY0MkYzR2tReVZuRlVUdjc5dWxz?= =?utf-8?B?Z3k5cDczd2JHSGRoWTEvZUlMZU1DTmNmS0NJVjB0S0dWOHZJNVJBeFFpVTFW?= =?utf-8?B?bGJYMnQyaHVlZTZVQWN2WS9jR29YdHcvS0pqOW1ZU0RiVVJKN2tuSHBmaG8y?= =?utf-8?Q?98FuQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB786; 5:b9sTEkLxc17mvIkf+/bhREEwUIeYDuwbNTttv3iG3Ov+FR95rAeqETsqrn1rd2d8q6Y+8d2Q8iY6pHVV5Y0Wzk6RMVKzDd00jIXbdVpHQPgUvd1boZpfDx07Q3UGhboRdHtZNvbhzll4aXh65VoIlQ==; 24:g9SkRtOxSpg9NOgsoHKbQVN0tHkDHbn5wWPo4ILz+oqlMjUFLY0vU+OY/ce4sSxC7NdvYTvp/WgrQfnNTUMyHGO2fcd0yodRTqO9becBkzg=; 7:01O8bUZdvRcapVDXhE4uB6NlSIgrqWHtiTISFaz9A+SjBHSSgCKxjqVADfcrb5JGOVsJi9tMar/sfmFPaXD/CLT/WxdIRZDmM//B1z9eUTOV79StlzzK6S+nQtB2Du+HiLDEMo+IR0xr7GTwbffyfVNnQqHznzOy6iCYGZdyW34= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 May 2016 14:36:44.7045 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB786 Archived-At: Subject: Re: [spring] Issue re PHP specification in SPRING drafts X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 14:37:12 -0000 A few months back I pointed out a couple of small issues that I think need to be addressed in draft-ietf-spring-segment-routing. I still think they need to be addressed. On 2/26/2016 8:44 AM, Eric C Rosen wrote: > There seems to be some inconsistency in the various documents about > the way that penultimate hop popping is handled. > > When advertising a prefix-SID via OSPF, the OSPF Segment Routing > extensions associate an NP-Flag with the prefix-SID. From section 5 > of draft-ietf-ospf-segment-routing-extensions: > > If the NP-Flag is not set then any upstream neighbor of the > Prefix-SID originator MUST pop the Prefix-SID. This is equivalent > to the penultimate hop popping mechanism used in the MPLS > dataplane. > > When advertising a prefix-SID via ISIS, the ISIS Segment Routing > extensions associate a P-flag with the prefix-SID. From section > 2.1.1.2 of draft-ietf-isis-segment-routing-extensions: > > If the P-flag is not set then any upstream neighbor of the > Prefix-SID originator MUST pop the Prefix-SID. This is > equivalent to the penultimate hop popping mechanism used in > the MPLS dataplane which improves performance of the > ultimate hop. > > These specs allow a node to REQUIRE its "upstream neighbors" on a > given prefix segment to perform penultimate hop popping on any packet > whose top label corresponds to a prefix-SID that has been advertised > via ISIS or OSPF. > > The architecture document has a weaker requirement. From section > 3.2.2 of draft-ietf-spring-segment-routing: > > The IGP signaling extension for IGP-Prefix segment includes > the P-Flag. A Node N advertising a Prefix-SID SID-R for > its attached prefix R resets the P-Flag to allow its > connected neighbors to perform the NEXT operation while > processing SID-R. This behavior is equivalent to > Penultimate Hop Popping in MPLS. When set, the neighbors > of N must perform the CONTINUE operation while processing > SID-R. > > This could be interpreted as allowing the upstream neighbor to perform > the CONTINUE operation even if the P-Flag is clear, which would mean > that the choice of whether to do PHP is left to the neighbor. This > seems to contradict the statements quoted above from the IGP documents. > > Shouldn't the architecture document be modified so that it says the > same thing as the IGP documents? > > A related issue in the architecture document stems from the following > passage from section 3.2.2 of the architecture document: > > o A node N attaching a Prefix-SID SID-R to its attached prefix > R MUST maintain the following FIB entry: > > Incoming Active Segment: SID-R > Ingress Operation: NEXT > Egress interface: NULL > > If SID-R has been advertised in OSPF with the NP-flag clear, or if it > has been advertised in ISIS with the P-flag set, there is no need for > this FIB entry to be maintained. Perhaps the passage should actually > read: > > o If a node N advertises Prefix-SID SID-R for a prefix R that > is attached to N, N MUST either clear the P-Flag in the > advertisement of SID-R, or else maintain the following > FIB entry: > > Incoming Active Segment: SID-R > Ingress Operation: NEXT > Egress interface: NULL > > > > > > > > > From nobody Mon May 9 09:06:14 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F099212D0DE for ; Mon, 9 May 2016 09:06:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuLZKvGgV2nC for ; Mon, 9 May 2016 09:06:11 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 737BB12D0BB for ; Mon, 9 May 2016 09:06:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3852; q=dns/txt; s=iport; t=1462809971; x=1464019571; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1KMIoXoja4ougEoSsITTjXfzbbsyyoAtR/r0AgJZ44w=; b=Iq++E6WmGeBuP09Ej0L4409LZhZY1S+xXyEDp1jKeYPBarvxcFqS4iDN pdjIbE0uJWlw+u68abzBaPIU3NJfdA4jYYbw+l0EPBj5t/zYn/M7fMCD3 boZV1TvdCja0TGTQwAoWlzOe9WcfPQ51VrVuA6NU2f3Loqbd3Tu/X8Nkh U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAgCLtDBX/4cNJK1dgzhVfQa4fwENg?= =?us-ascii?q?XYXC4UkSgKBMjgUAQEBAQEBAWUnhEEBAQEDAQEBATc0CwULAgEIEgYeECcLFw4?= =?us-ascii?q?CBA4FiCMIDr98AQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGIIF2CIJOhD+DK4IuB?= =?us-ascii?q?ZgiAY4bgWmHeYU1jzoBHgEBQoIFG4FLbogHfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,601,1454976000"; d="scan'208";a="102382308" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 May 2016 16:06:10 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u49G6A4M003645 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 May 2016 16:06:10 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 9 May 2016 12:06:05 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Mon, 9 May 2016 12:06:05 -0400 From: "Stefano Previdi (sprevidi)" To: Eric C Rosen Thread-Topic: [spring] Issue re PHP specification in SPRING drafts Thread-Index: AQHRcJvc8lkfmYbsgUuF/oufG+elTJ+xYjqAgAAY/YA= Date: Mon, 9 May 2016 16:06:05 +0000 Message-ID: <8186C42D-D9CD-4DF0-9534-28D8105F18D5@cisco.com> References: <56D056A4.7020207@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.84.2] Content-Type: text/plain; charset="us-ascii" Content-ID: <46C516759040E64D97C5F706290AFB5C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] Issue re PHP specification in SPRING drafts X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 May 2016 16:06:13 -0000 Hi Eric, sorry, I missed that one and will look into this asap. s. > On May 9, 2016, at 4:36 PM, Eric C Rosen wrote: >=20 > A few months back I pointed out a couple of small issues that I think nee= d to be addressed in draft-ietf-spring-segment-routing. I still think they = need to be addressed. >=20 >=20 > On 2/26/2016 8:44 AM, Eric C Rosen wrote: >> There seems to be some inconsistency in the various documents about the = way that penultimate hop popping is handled. >>=20 >> When advertising a prefix-SID via OSPF, the OSPF Segment Routing extensi= ons associate an NP-Flag with the prefix-SID. From section 5 of draft-ietf= -ospf-segment-routing-extensions: >>=20 >> If the NP-Flag is not set then any upstream neighbor of the >> Prefix-SID originator MUST pop the Prefix-SID. This is equivalent >> to the penultimate hop popping mechanism used in the MPLS >> dataplane. >>=20 >> When advertising a prefix-SID via ISIS, the ISIS Segment Routing extensi= ons associate a P-flag with the prefix-SID. From section 2.1.1.2 of draft-= ietf-isis-segment-routing-extensions: >>=20 >> If the P-flag is not set then any upstream neighbor of the >> Prefix-SID originator MUST pop the Prefix-SID. This is >> equivalent to the penultimate hop popping mechanism used in >> the MPLS dataplane which improves performance of the >> ultimate hop. >>=20 >> These specs allow a node to REQUIRE its "upstream neighbors" on a given = prefix segment to perform penultimate hop popping on any packet whose top l= abel corresponds to a prefix-SID that has been advertised via ISIS or OSPF. >>=20 >> The architecture document has a weaker requirement. From section 3.2.2 = of draft-ietf-spring-segment-routing: >>=20 >> The IGP signaling extension for IGP-Prefix segment includes >> the P-Flag. A Node N advertising a Prefix-SID SID-R for >> its attached prefix R resets the P-Flag to allow its >> connected neighbors to perform the NEXT operation while >> processing SID-R. This behavior is equivalent to >> Penultimate Hop Popping in MPLS. When set, the neighbors >> of N must perform the CONTINUE operation while processing >> SID-R. >>=20 >> This could be interpreted as allowing the upstream neighbor to perform t= he CONTINUE operation even if the P-Flag is clear, which would mean that th= e choice of whether to do PHP is left to the neighbor. This seems to contr= adict the statements quoted above from the IGP documents. >>=20 >> Shouldn't the architecture document be modified so that it says the same= thing as the IGP documents? >>=20 >> A related issue in the architecture document stems from the following pa= ssage from section 3.2.2 of the architecture document: >>=20 >> o A node N attaching a Prefix-SID SID-R to its attached prefix >> R MUST maintain the following FIB entry: >>=20 >> Incoming Active Segment: SID-R >> Ingress Operation: NEXT >> Egress interface: NULL >>=20 >> If SID-R has been advertised in OSPF with the NP-flag clear, or if it ha= s been advertised in ISIS with the P-flag set, there is no need for this FI= B entry to be maintained. Perhaps the passage should actually read: >>=20 >> o If a node N advertises Prefix-SID SID-R for a prefix R that >> is attached to N, N MUST either clear the P-Flag in the >> advertisement of SID-R, or else maintain the following >> FIB entry: >>=20 >> Incoming Active Segment: SID-R >> Ingress Operation: NEXT >> Egress interface: NULL >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Tue May 10 02:37:21 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5362612D63A for ; Tue, 10 May 2016 02:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlQh44DOIy5g for ; Tue, 10 May 2016 02:37:17 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48B2C12D64C for ; Tue, 10 May 2016 02:37:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4850; q=dns/txt; s=iport; t=1462873036; x=1464082636; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=35sNmcDnS9JBJ8d+vDc8Bn1R6d/b5Gozh8OLmD7f/gA=; b=AHAAV4/YOvhpJmMbuYnRY1ZdZ8YFYDCF1Ao9wYq+/koNBRpBQcLf70TF mX4LgLvFZ5C+vkP1OqNZSSflZkP75tEHzNW7wXDnWFtdwxATOkiX1dfes Xr1BA8aX1J/DXmsAx5YpET9Wnll5AjR7Qg8aeaiqp/AQmeSsTlVa9kR1i M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AiAgAbqzFX/4wNJK1cgzhVfQa5HQENg?= =?us-ascii?q?XYXC4UkSgIcgRc4FAEBAQEBAQFlJ4RBAQEBAwEBAQEgEToLBQsCAQgSBgICJgI?= =?us-ascii?q?CAiULFQIOAgQOBYgjCA6lG5B7AQEBAQEBAQEBAQEBAQEBAQEBAQEBEQR8hSSBd?= =?us-ascii?q?giCToQ/gwArgi4FkzCEdwGOHIFph3mFNYYsiREBHgEBQoIFG4FLbogLfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,604,1454976000"; d="scan'208";a="102647534" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 10 May 2016 09:37:15 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u4A9bFl9030669 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 May 2016 09:37:15 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 10 May 2016 05:37:14 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Tue, 10 May 2016 05:37:14 -0400 From: "Stefano Previdi (sprevidi)" To: Eric C Rosen Thread-Topic: [spring] Issue re PHP specification in SPRING drafts Thread-Index: AQHRcJvc8lkfmYbsgUuF/oufG+elTJ+yoOUA Date: Tue, 10 May 2016 09:37:14 +0000 Message-ID: <143239DA-B092-4771-9C1C-497FEEE3B31E@cisco.com> References: <56D056A4.7020207@juniper.net> In-Reply-To: <56D056A4.7020207@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.195.195] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] Issue re PHP specification in SPRING drafts X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 May 2016 09:37:19 -0000 RXJpYywNCg0KDQo+IE9uIEZlYiAyNiwgMjAxNiwgYXQgMjo0NCBQTSwgRXJpYyBDIFJvc2VuIDxl cm9zZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KPiANCj4gVGhlcmUgc2VlbXMgdG8gYmUgc29tZSBp bmNvbnNpc3RlbmN5IGluIHRoZSB2YXJpb3VzIGRvY3VtZW50cyBhYm91dCB0aGUgd2F5IHRoYXQg cGVudWx0aW1hdGUgaG9wIHBvcHBpbmcgaXMgaGFuZGxlZC4NCj4gDQo+IFdoZW4gYWR2ZXJ0aXNp bmcgYSBwcmVmaXgtU0lEIHZpYSBPU1BGLCB0aGUgT1NQRiBTZWdtZW50IFJvdXRpbmcgZXh0ZW5z aW9ucyBhc3NvY2lhdGUgYW4gTlAtRmxhZyB3aXRoIHRoZSBwcmVmaXgtU0lELiAgRnJvbSBzZWN0 aW9uIDUgb2YgZHJhZnQtaWV0Zi1vc3BmLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25zOg0KPiAN Cj4gICAgICBJZiB0aGUgTlAtRmxhZyBpcyBub3Qgc2V0IHRoZW4gYW55IHVwc3RyZWFtIG5laWdo Ym9yIG9mIHRoZQ0KPiAgICAgIFByZWZpeC1TSUQgb3JpZ2luYXRvciBNVVNUIHBvcCB0aGUgUHJl Zml4LVNJRC4gIFRoaXMgaXMgZXF1aXZhbGVudA0KPiAgICAgIHRvIHRoZSBwZW51bHRpbWF0ZSBo b3AgcG9wcGluZyBtZWNoYW5pc20gdXNlZCBpbiB0aGUgTVBMUw0KPiAgICAgIGRhdGFwbGFuZS4N Cj4gDQo+IFdoZW4gYWR2ZXJ0aXNpbmcgYSBwcmVmaXgtU0lEIHZpYSBJU0lTLCB0aGUgSVNJUyBT ZWdtZW50IFJvdXRpbmcgZXh0ZW5zaW9ucyBhc3NvY2lhdGUgYSBQLWZsYWcgd2l0aCB0aGUgcHJl Zml4LVNJRC4gIEZyb20gc2VjdGlvbiAyLjEuMS4yIG9mIGRyYWZ0LWlldGYtaXNpcy1zZWdtZW50 LXJvdXRpbmctZXh0ZW5zaW9uczoNCj4gDQo+ICAgICAgSWYgdGhlIFAtZmxhZyBpcyBub3Qgc2V0 IHRoZW4gYW55IHVwc3RyZWFtIG5laWdoYm9yIG9mIHRoZQ0KPiAgICAgIFByZWZpeC1TSUQgb3Jp Z2luYXRvciBNVVNUIHBvcCB0aGUgUHJlZml4LVNJRC4gIFRoaXMgaXMNCj4gICAgICBlcXVpdmFs ZW50IHRvIHRoZSBwZW51bHRpbWF0ZSBob3AgcG9wcGluZyBtZWNoYW5pc20gdXNlZCBpbg0KPiAg ICAgIHRoZSBNUExTIGRhdGFwbGFuZSB3aGljaCBpbXByb3ZlcyBwZXJmb3JtYW5jZSBvZiB0aGUN Cj4gICAgICB1bHRpbWF0ZSBob3AuDQo+IA0KPiBUaGVzZSBzcGVjcyBhbGxvdyBhIG5vZGUgdG8g UkVRVUlSRSBpdHMgInVwc3RyZWFtIG5laWdoYm9ycyIgb24gYSBnaXZlbiBwcmVmaXggc2VnbWVu dCB0byBwZXJmb3JtIHBlbnVsdGltYXRlIGhvcCBwb3BwaW5nIG9uIGFueSBwYWNrZXQgd2hvc2Ug dG9wIGxhYmVsIGNvcnJlc3BvbmRzIHRvIGEgcHJlZml4LVNJRCB0aGF0IGhhcyBiZWVuIGFkdmVy dGlzZWQgdmlhIElTSVMgb3IgT1NQRi4NCj4gDQo+IFRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQg aGFzIGEgd2Vha2VyIHJlcXVpcmVtZW50LiAgRnJvbSBzZWN0aW9uIDMuMi4yIG9mIGRyYWZ0LWll dGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZzoNCj4gDQo+ICAgICAgVGhlIElHUCBzaWduYWxpbmcg ZXh0ZW5zaW9uIGZvciBJR1AtUHJlZml4IHNlZ21lbnQgaW5jbHVkZXMNCj4gICAgICB0aGUgUC1G bGFnLiAgQSBOb2RlIE4gYWR2ZXJ0aXNpbmcgYSBQcmVmaXgtU0lEIFNJRC1SIGZvcg0KPiAgICAg IGl0cyBhdHRhY2hlZCBwcmVmaXggUiByZXNldHMgdGhlIFAtRmxhZyB0byBhbGxvdyBpdHMNCj4g ICAgICBjb25uZWN0ZWQgbmVpZ2hib3JzIHRvIHBlcmZvcm0gdGhlIE5FWFQgb3BlcmF0aW9uIHdo aWxlDQo+ICAgICAgcHJvY2Vzc2luZyBTSUQtUi4gIFRoaXMgYmVoYXZpb3IgaXMgZXF1aXZhbGVu dCB0bw0KPiAgICAgIFBlbnVsdGltYXRlIEhvcCBQb3BwaW5nIGluIE1QTFMuICBXaGVuIHNldCwg dGhlIG5laWdoYm9ycw0KPiAgICAgIG9mIE4gbXVzdCBwZXJmb3JtIHRoZSBDT05USU5VRSBvcGVy YXRpb24gd2hpbGUgcHJvY2Vzc2luZw0KPiAgICAgIFNJRC1SLg0KPiANCj4gVGhpcyBjb3VsZCBi ZSBpbnRlcnByZXRlZCBhcyBhbGxvd2luZyB0aGUgdXBzdHJlYW0gbmVpZ2hib3IgdG8gcGVyZm9y bSB0aGUgQ09OVElOVUUgb3BlcmF0aW9uIGV2ZW4gaWYgdGhlIFAtRmxhZyBpcyBjbGVhciwNCg0K DQp3ZWxsLCB0aGF04oCZcyBub3QgdGhlIGludGVudGlvbi4gSeKAmWxsIGZpeCB0aGUgdGV4dCB0 byBtYWtlIHRoaXMgY2xlYXIuDQoNCg0KPiB3aGljaCB3b3VsZCBtZWFuIHRoYXQgdGhlIGNob2lj ZSBvZiB3aGV0aGVyIHRvIGRvIFBIUCBpcyBsZWZ0IHRvIHRoZSBuZWlnaGJvci4gIFRoaXMgc2Vl bXMgdG8gY29udHJhZGljdCB0aGUgc3RhdGVtZW50cyBxdW90ZWQgYWJvdmUgZnJvbSB0aGUgSUdQ IGRvY3VtZW50cy4NCj4gDQo+IFNob3VsZG4ndCB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IGJl IG1vZGlmaWVkIHNvIHRoYXQgaXQgc2F5cyB0aGUgc2FtZSB0aGluZyBhcyB0aGUgSUdQIGRvY3Vt ZW50cz8NCg0KDQpZZXMuDQoNCg0KPiBBIHJlbGF0ZWQgaXNzdWUgaW4gdGhlIGFyY2hpdGVjdHVy ZSBkb2N1bWVudCBzdGVtcyBmcm9tIHRoZSBmb2xsb3dpbmcgcGFzc2FnZSBmcm9tIHNlY3Rpb24g My4yLjIgb2YgdGhlIGFyY2hpdGVjdHVyZSBkb2N1bWVudDoNCj4gDQo+ICAgbyBBIG5vZGUgTiBh dHRhY2hpbmcgYSBQcmVmaXgtU0lEIFNJRC1SIHRvIGl0cyBhdHRhY2hlZCBwcmVmaXgNCj4gICAg IFIgTVVTVCBtYWludGFpbiB0aGUgZm9sbG93aW5nIEZJQiBlbnRyeToNCj4gDQo+ICAgICBJbmNv bWluZyBBY3RpdmUgU2VnbWVudDogU0lELVINCj4gICAgIEluZ3Jlc3MgT3BlcmF0aW9uOiBORVhU DQo+ICAgICBFZ3Jlc3MgaW50ZXJmYWNlOiBOVUxMDQo+IA0KPiBJZiBTSUQtUiBoYXMgYmVlbiBh ZHZlcnRpc2VkIGluIE9TUEYgd2l0aCB0aGUgTlAtZmxhZyBjbGVhciwgb3IgaWYgaXQgaGFzIGJl ZW4gYWR2ZXJ0aXNlZCBpbiBJU0lTIHdpdGggdGhlIFAtZmxhZyBzZXQsIHRoZXJlIGlzIG5vIG5l ZWQgZm9yIHRoaXMgRklCIGVudHJ5IHRvIGJlIG1haW50YWluZWQuICBQZXJoYXBzIHRoZSBwYXNz YWdlIHNob3VsZCBhY3R1YWxseSByZWFkOg0KPiANCj4gICBvIElmIGEgbm9kZSBOIGFkdmVydGlz ZXMgUHJlZml4LVNJRCBTSUQtUiBmb3IgYSBwcmVmaXggUiB0aGF0DQo+ICAgICBpcyBhdHRhY2hl ZCB0byBOLCBOIE1VU1QgZWl0aGVyIGNsZWFyIHRoZSBQLUZsYWcgaW4gdGhlDQo+ICAgICBhZHZl cnRpc2VtZW50IG9mIFNJRC1SLCBvciBlbHNlIG1haW50YWluIHRoZSBmb2xsb3dpbmcNCj4gICAg IEZJQiBlbnRyeToNCj4gDQo+ICAgICBJbmNvbWluZyBBY3RpdmUgU2VnbWVudDogU0lELVINCj4g ICAgIEluZ3Jlc3MgT3BlcmF0aW9uOiBORVhUDQo+ICAgICBFZ3Jlc3MgaW50ZXJmYWNlOiBOVUxM DQoNCg0Kb2suIA0KDQpJIHdpbGwgdXBkYXRlIHRoZSBkb2MuDQoNClRoYW5rcy4NCnMuDQoNCg0K PiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+IHNw cmluZ0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nw cmluZw0KDQo= From nobody Wed May 11 04:47:11 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D411112DA56 for ; Wed, 11 May 2016 04:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BE6E1646QnXo for ; Wed, 11 May 2016 04:47:07 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 377B812B065 for ; Wed, 11 May 2016 04:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20510; q=dns/txt; s=iport; t=1462967167; x=1464176767; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Yr/OQzSXXXeP0Go7BaLSZaHa6qglfV9fWXB685USMl0=; b=hQ5Z0qTauKyWk13j+rju0X0KVGqtwH+VBrJTbsN7HYrEoEdeHeLSikJX UIwgqoXRzK0Nho0OC8o96/rKMrqYGPGMb5uFPjoAsMS9ZBZjYoagbIbB2 nBQ7yzQ/uAvL8hkG+yFcwVwWguMGVtiwU/Xxvv8BwkP6s6ct+8S2+psgS 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CBAwAaGjNX/4UNJK1dgzhVfQaEM7R2A?= =?us-ascii?q?Q2BdhcNhSJKAhyBHjgUAQEBAQEBAWUnhEIBAQEDAQEBASAROgsFBwQCAQgRAQM?= =?us-ascii?q?BAQECAiMDAgICJQsUAQIGCAIEDgUbiAwIDqdvkHoBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQERBHyFJIF2glaEEQoHAQYtgmkrgi4FmCcBhX2CeIUogWmET4hhj0ABHgE?= =?us-ascii?q?BQoIFG4FLbgGHSwkXH38BAQE?= X-IronPort-AV: E=Sophos;i="5.24,608,1454976000"; d="scan'208";a="103116734" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 May 2016 11:46:05 +0000 Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u4BBk55u022061 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 May 2016 11:46:05 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 11 May 2016 07:46:04 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Wed, 11 May 2016 07:46:04 -0400 From: "Stefano Previdi (sprevidi)" To: Uma Chunduri Thread-Topic: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call Thread-Index: AQHRpiTU7mzHobbQgECZTb3vV/b9z5+snySAgAdNAAA= Date: Wed, 11 May 2016 11:46:04 +0000 Message-ID: References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10411_1460620508_570F4CDC_10411_96_23_53C29892C857584299CBF5D05346208A0F86E45F@OPEXCLILM21.corporate.adroot.infra.ftgroup> <1B502206DFA0C544B7A6046915200863580C54E9@eusaamb105.ericsson.se> <0468fb2fe35841668bc35606e988074c@XCH-ALN-001.cisco.com> <1B502206DFA0C544B7A60469152008635BCD31AB@eusaamb106.ericsson.se> <445eeb6f8f12480f90e941a81eeaafc7@XCH-ALN-001.cisco.com> <1B502206DFA0C544B7A60469152008635BCDFEFB@eusaamb106.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008635BCDFEFB@eusaamb106.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.89.71] Content-Type: text/plain; charset="utf-8" Content-ID: <363D547601B44C44A5EB754089E9F360@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "Les Ginsberg \(ginsberg\)" , "spring@ietf.org" , "bruno.decraene@orange.com" Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 11:47:10 -0000 DQo+IE9uIE1heSA2LCAyMDE2LCBhdCAxMDoxNiBQTSwgVW1hIENodW5kdXJpIDx1bWEuY2h1bmR1 cmlAZXJpY3Nzb24uY29tPiB3cm90ZToNCj4gDQo+IExlcywNCj4gIA0KPiAyIHF1aWNrIHRoaW5n cy4NCj4gIA0KPiAxLiAgICAgICAgDQo+ICAgICAgICAgICAgID5bTGVzOl0gVGhlcmUgYXJlIHR3 byBsZWdpdGltYXRlIHVzZSBjYXNlcyBmb3IgU1JNUzoNCj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgID4xKVRvIGFkdmVydGlzZSBTSURzIGZvciBub24tU1IgY2Fw YWJsZSBub2Rlcw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg PjIpQXMgYSBnbG9iYWwgcHJvdmlzaW9uaW5nIHRvb2wNCj4gICAgICAgICAgICAgICAgICAgICAg ICAgIEkgYW0gaGVhcmluZyAjMiBmb3IgdGhlIGZpcnN0IHRpbWUuIEkgZG9u4oCZdCBzZWUgdGhp cyBlaXRoZXIgIGRpc2N1c3NlZCBlYXJsaWVyIGluIHRoZSBXRyBsaXN0ICBvciBjYXB0dXJlZCBp biBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5n LTA3LiBFdmVuIGluIHRoZSBwcm90b2NvbCBleHRlbnNpb25zIGRvY3VtZW50IGZvciBleGFtcGxl IA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtaXNpcy1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9ucy0wNiNzZWN0aW9uLTIu NCB3ZSBhbHdheXMgZGlzY3Vzc2VkIHRoaXMgZnJvbSBub24tU1IgDQo+ICAgICAgICAgICAgICAg ICAgICAgICAgICBjYXBhYmxlIG5vZGVzIFBvVi4gU28gSSByZXF1ZXN0IHRvIGFkZCB0aGlzIGlu IGFyY2hpdGVjdHVyZSBkb2N1bWVudCBiZWZvcmUgZmFjdG9yaW5nIHRoaXMgZm9yIHNvbHV0aW9u IGluIGNvbmZsaWN0IHJlc29sdXRpb24uIA0KDQoNCnVzaW5nIGEgU1JNUyBmb3IgYWR2ZXJ0aXNp bmcgU0lEIG9uIGJlaGFsZiBvZiBTUiBjYXBhYmxlIG5vZGVzIGRvZXMgbm90IGludHJvZHVjZSBh bnkgY2hhbmdlIGluIHRoZSBTUiBhcmNoaXRlY3R1cmUgc28gbm90IHN1cmUgd2hhdCB3ZSBuZWVk IHRvIGRvY3VtZW50IGhlcmUuDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICANCj4gDQo+IDIu ICAgICAgIEFsc28gdGhpcyBpcyB0aGUgZmlyc3QgdGltZSBldmVyIHdlIGhhdmUgYSByZXF1aXJl bWVudCBmb3IgY3Jvc3MgcHJvdG9jb2xzIHZlcmlmaWNhdGlvbiB3ZSBvdWdodCB0byBkaXNjdXNz IHRoZSBpbXBsaWNhdGlvbnMgb2YgdGhpcyAgDQo+IGFuZCBwcm90b2NvbHMgaW52b2x2ZWQgKHdp dGggaW4gQVMgb3Igb3RoZXJ3aXNlKSBpbiB0aGUgYXJjaGl0ZWN0dXJlIGRvY3VtZW50IChhdCBs ZWFzdCBicmllZmx5KS4NCg0KDQp0aGUgYXJjaGl0ZWN0dXJlIGRyYWZ0IGlzIGRhdGEtcGFuZSBh Z25vc3RpYyBzbyBJIHByZXN1bWUgeW91IHJlZmVyIHRvIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21l bnQtcm91dGluZy1tcGxzLg0KDQp3aXRoIHRoZSBpcHY2IGRhdGEtcGxhbmUgU1IgY29uZmxpY3Rz IGFyZSBpbiBmYWN0IHNvbHZlZCBieSBpcHY2IGFkZHJlc3NpbmcgdGVjaG5pcXVlcyA7LSkNCg0K cy4NCg0KDQo+ICANCj4gLS0NCj4gVW1hIEMuDQo+ICANCj4gRnJvbTogc3ByaW5nIFttYWlsdG86 c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMZXMgR2luc2JlcmcgKGdpbnNi ZXJnKQ0KPiBTZW50OiBXZWRuZXNkYXksIE1heSAwNCwgMjAxNiA5OjM4IEFNDQo+IFRvOiBVbWEg Q2h1bmR1cmk7IGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb207IHNwcmluZ0BpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW3NwcmluZ10gZHJhZnQtZ2luc2Jlcmctc3ByaW5nLWNvbmZsaWN0LXJlc29s dXRpb24gLSBXRyBhZG9wdGlvbiBjYWxsDQo+ICANCj4gVW1hIOKAkw0KPiAgDQo+IFRvIHJlc3Rh dGUsIHRoZSBwcm9ibGVtIGJlaW5nIGFkZHJlc3NlZCBoZXJlIGlzIHRvIGd1YXJhbnRlZSBjb25z aXN0ZW50IHVzZSBvZiBTSURzIGluIHRoZSBmb3J3YXJkaW5nIHBsYW5lIG5ldHdvcmstd2lkZSBp biB0aGUgcHJlc2VuY2Ugb2YgY29uZmxpY3RpbmcgYWR2ZXJ0aXNlbWVudHMuIFRoZSBzZXQgb2Yg YWR2ZXJ0aXNlbWVudHMgaW5jbHVkZXMgYm90aCBTSURzIGFkdmVydGlzZWQgaW4gcHJvdG9jb2wg cHJlZml4IHJlYWNoYWJpbGl0eSBhZHZlcnRpc2VtZW50cyBhbmQgU1JNUyBhZHZlcnRpc2VtZW50 cyBiZWNhdXNlIHByb2JsZW1zIG9jY3VyIGJhc2VkIHVwb24gaW5jb25zaXN0ZW5jaWVzIGluIHdo YXQgaXMgaW5zdGFsbGVkIGluIHRoZSBmb3J3YXJkaW5nIHBsYW5lIG9mIGRpZmZlcmVudCByb3V0 ZXJzLiBJdCBtYXR0ZXJzIG5vdCB3aGV0aGVyIFJvdXRlciBBIHVzZWQgYSBTSUQgYWR2ZXJ0aXNl ZCBieSBhIHByb3RvY29sIHByZWZpeCByZWFjaGFiaWxpdHkgYWR2ZXJ0aXNlbWVudCBvciBieSBh biBTUk1TIGFkdmVydGlzZW1lbnQg4oCTIHdoYXQgbWF0dGVyIGlzIHdoZXRoZXIgdGhlIFNJRCB1 c2VkIGlzIGNvbnNpc3RlbnQgd2l0aCB3aGF0IHRoZSBuZWlnaGJvcnMgb2YgUm91dGVyIEEgdXNl LiBTbyBzaW1wbHkgZW5zdXJpbmcgdGhhdCBPU1BGIChmb3IgZXhhbXBsZSkgcmVzb2x2ZXMgU0lE cyBpbiBhIGNvbnNpc3RlbnQgd2F5IGRvZXMgbm90IGZ1bGx5IGFkZHJlc3MgdGhlIHByb2JsZW0g c3BhY2UuDQo+ICANCj4gTW9yZSBpbmxpbmUuDQo+ICANCj4gRnJvbTogVW1hIENodW5kdXJpIFtt YWlsdG86dW1hLmNodW5kdXJpQGVyaWNzc29uLmNvbV0gDQo+IFNlbnQ6IFR1ZXNkYXksIE1heSAw MywgMjAxNiAzOjU5IFBNDQo+IFRvOiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKTsgYnJ1bm8uZGVj cmFlbmVAb3JhbmdlLmNvbTsgc3ByaW5nQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbc3ByaW5n XSBkcmFmdC1naW5zYmVyZy1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbiAtIFdHIGFkb3B0aW9u IGNhbGwNCj4gIA0KPiBMZXMsDQo+ICANCj4gV2l0aCBhbGwgZHVlIHJlc3BlY3RzLCBjcm9zcyBw cm90b2NvbCB2ZXJpZmljYXRpb24gIG9mIHByZWZpeCBhbmQgU0lEIGNvbmZsaWN0cyBhcyBhbiDi gJxhcmNoaXRlY3R1cmFsIGNoYW5nZeKAnSAgYW5kIGl0IGNhbiBzZXZlcmVseSBpbXBhY3QgdGhl IGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyAoYXQgbGVhc3QgdGhlIG9uZSBJIHdvcmsgb24pLiAN Cj4gIA0KPiBbTGVzOl0gSXQgaXMgcXVpdGUgY29ycmVjdCDigJMgYW5kIEkgY2FuIGNvbmZpcm0g YmFzZWQgb24gcGVyc29uYWwgZXhwZXJpZW5jZSDigJMgdGhhdCBzdXBwb3J0IGZvciBjb25mbGlj dCByZXNvbHV0aW9uIGlzIGEgc2lnbmlmaWNhbnQgZWZmb3J0Lg0KPiAgDQo+IEFsc28gSSBoYXZl IGNvdXBsZSBvZiBjYXNlcyB3aGVyZSBjdXJyZW50IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGlzIG5v dCBjbGVhciBhYm91dCByZXNvbHV0aW9uLg0KPiAgDQo+IElNTywgZmlyc3Qgd2UgbmVlZCBjbGFy aXR5IHdpdGggaW4gYSBwcm90b2NvbCBpbnN0YW5jZSByZXNvbHV0aW9uIHJ1bGVzIGJlZm9yZSBn b2luZyB0byByZXNvbHZlIHRoZSBzYW1lIGFjcm9zcyBwcm90b2NvbHMgKEkgbWVudGlvbmVkIGZl dyBjYXNlcyBiZWxvdykgLg0KPiBTZXBhcmF0aW9uIG9mIHJlYWNoYWJpbGl0eSBhZHZlcnRpc2Vt ZW50cyBhbmQgU1JNUyB3b3VsZCBoZWxwIOKAnGNyb3NzIHByb3RvY29s4oCdIHZlcmlmaWNhdGlv biBvZiB0aGUgcmFuZ2VzIGFuZCBTUk1TIGlzIG5vdCBhcHBsaWNhYmxlIHRvIGFsbCBwcm90b2Nv bHMuDQo+ICANCj4gIA0KPiBJbi1saW5lIFtVbWFdOg0KPiAgDQo+IC0tDQo+IFVtYSBDLg0KPiAg DQo+IEZyb206IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIFttYWlsdG86Z2luc2JlcmdAY2lzY28u Y29tXSANCj4gU2VudDogU2F0dXJkYXksIEFwcmlsIDMwLCAyMDE2IDEwOjExIFBNDQo+IFRvOiBV bWEgQ2h1bmR1cmk7IGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb207IHNwcmluZ0BpZXRmLm9yZw0K PiBTdWJqZWN0OiBSRTogW3NwcmluZ10gZHJhZnQtZ2luc2Jlcmctc3ByaW5nLWNvbmZsaWN0LXJl c29sdXRpb24gLSBXRyBhZG9wdGlvbiBjYWxsDQo+ICANCj4gVW1hIOKAkw0KPiAgDQo+IFdlIGFy ZSBpbmRlZWQgZGVmaW5pbmcgY29uZmxpY3QgcmVzb2x1dGlvbiBhY3Jvc3MgYWxsIHRoZSBTSUQg YWR2ZXJ0aXNlbWVudHMgcmVnYXJkbGVzcyBvZiBzb3VyY2UgKHByb3RvY29sIG9yIFNSTVMpIOKA kw0KPiAgDQo+IFtVbWFdOiBXaGlsZSB5b3UgY2FuIHRoZW9yZXRpY2FsbHkgZG8gYW55dGhpbmcg Zm9yIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gdGhpcyBraW5kIG9mIGNyb3NzIHByb3RvY29sIHZl cmlmaWNhdGlvbiBpcyBhIG5ldyBhcmNoaXRlY3R1cmFsIHJlcXVpcmVtZW50LiAgDQo+ICAgICAg ICAgICAgICAgIEJlY2F1c2UgaXQgc2VlbXMg4oCcYSBjZW50cmFsIGVudGl0eeKAnSBuZWVkIHRv IGdhdGhlciBhbGwgZGlmZmVyZW50IHByb3RvY29sIGluc3RhbmNlcyBTUk1TIGFkdmVydGlzZW1l bnRzIGFuZCBzaG91bGQgc2V0dGxlIHdpdGggcmVzb2x1dGlvbi4gDQo+ICANCj4gLSAgICAgICAg ICBBbHNvIG5vdGUgU1JNUyBpcyBub3QgYXBwbGljYWJsZSBmb3IgQkdQIGJ1dCBpdCBzZWVtcyBh bGwgcHJlZml4IFNJRHMgbmVlZCB0byBiZSB2ZXJpZmllZCAgd2l0aCBJR1AgaW5zdGFuY2VzIFNS TVMgYWR2ZXJ0aXNlbWVudHMuIElzIHRoaXMgdHJ1ZT8gV2hpbGUgdGhlIGRvY3VtZW50IG1vc3Rs eSB0YWxrcyBhYm91dCB0aGVzZSBhbmQgY29tcGFyZXMgd2l0aCBwcmVmaXggYWR2ZXJ0aXNlbWVu dC4NCj4gW0xlczpdIFRoZSBpc3N1ZSBpcyBwcm90b2NvbCBhZ25vc3RpYy4NCj4gIA0KPiAtICAg ICAgICAgIEFsZ29yaXRobSBwcm9wb3NlZCBuZWVkcyBtb3JlIGNsYXJpdHk6IFRha2UgU2VjdGlv biAzLjIuNA0KPiAgDQo+IG8gICAgDQo+ICAgICAgICAgICAgICAgICAgICAgICDigJwgICAxLiAg U21hbGxlciByYW5nZSB3aW5zDQo+ICANCj4gICAgICAgICAgICAgIDIuICBJUHY2IGVudHJ5IHdp bnMgb3ZlciBJUHY0IGVudHJ5DQo+ICAgICAgICAgICAgICDigKYNCj4gICAgICAgICDigJwNCj4g ICAgICAgICAgICAgICAgICBXaGF0IGhhcHBlbnMgaW4gY2FzZSBvZiBwcmVmaXggY29uZmxpY3Qg b3IgU0lEIGNvbmZsaWN0IHdpdGggb25seSBwcmVmaXggYWR2ZXJ0aXNlbWVudHMgKHJhbmdlIDEp LiAgU2F5IG11bHRpcGxlIHByZWZpeGVzIGhhdmUgc2FtZSBTSUQgaW4gb25lIHByb3RvY29sIGlu c3RhbmNlIGFuZCBpbiBkaWZmZXJlbnQgcHJvdG9jb2xzLg0KPiAgICAgICAgICAgICAgICAgIEkg c2VlIDIgbGV2ZWxzIG9mIHJlc29sdXRpb24gcmVxdWlyZWQgdml6Liwgb25lIGF0IHdpdGhpbiB0 aGUgcHJvdG9jb2wgYW5kIG9uZSBhbW9uZyB0aGUgcHJvdG9jb2xzLiAgTm8gZGlzY3Vzc2lvbiBv biB0aGlzLg0KPiAgDQo+IFtMZXM6XSBUaGUgZnVsbCBzZXQgb2YgcnVsZXMgc3BlY2lmaWVkIGlu IHRoZSBkcmFmdCBwcm92aWRlIGRldGVybWluaXN0aWMgcmVzb2x1dGlvbiBpbiBhbGwgY2FzZXMu IFlvdSBoYXZlIHNuaXBwZWQgb25seSB0aGUgZmlyc3QgdHdvIHJ1bGVzLiBJZiBhIHByZWZlcmVu Y2UgaXMgbm90IG9idGFpbmVkIGJhc2VkIG9uIHRoZSBmaXJzdCB0d28gcnVsZXMgeW91IGNvbnRp bnVlIG9uIHRvIHJ1bGUgIzMsIHRoZW4gcnVsZSAjNCwgZXRjLg0KPiAgDQo+ICAgICAgICAgICAg ICAgICAgU2ltaWxhcmx5IGluIGNhc2Ugb2YgU0lEIGNvbmZsaWN0ICAocmFuZ2UgMSksIGl04oCZ cyBub3Qgc3BlY2lmaWVkIHdoaWNoIHByb3RvY29s4oCZcyBTSUQgbmVlZCB0byBiZSBjb25zaWRl cmVkLiAgQXJlIHlvdSBhc3N1bWluZyBzb21lIHNvcnQgb2YgQWRtaW4gZGlzdGFuY2UgcGxheSBh IHJvbGUgaW4gcmVzb2x1dGlvbj8gDQo+IFtMZXM6XSBObyDigJMgYWRtaW4gZGlzdGFuY2UgcGxh eXMgbm8gcm9sZSBoZXJlLg0KPiAgDQo+ICBJIGRvbuKAmXQgc2VlIGFueSBkaXNjdXNzaW9uIGlu IHRoZSBkb2N1bWVudCAgYW5kIG5lZWRzIG1vcmUgY2xhcml0eSB0aGVyZSB0b28uDQo+IG8gICBB bHNvIHdoYXQgaGFwcGVucyBpZiBhIHByZWZpeCBvciBTSUQgY29uZmxpY3QgaGFwcGVucyB3aXRo IFNSTVMgcmFuZ2UgMSBhbmQgYSBwcmVmaXggIGFkdmVydGlzZW1lbnQgKDIgY2FzZXMpDQo+IGEu ICAgICAgIG9mIG9uZSBwcm90b2NvbCBhbmQNCj4gYi4gICAgICBtdWx0aXBsZSBwcm90b2NvbHM/ DQo+ICANCj4gW0xlczpdIFRoZSBzb3VyY2Ugb2YgdGhlIFNJRCBhZHZlcnRpc2VtZW50ICh3aGF0 IHByb3RvY29sL3Byb3RvY29sIGluc3RhbmNlIG9yIHdoZXRoZXIgaXQgaXMgU1JNUyBiYXNlZCkg cGxheXMgbm8gcm9sZS4gVGhlIHRpZSBicmVha2VyIHJ1bGVzIGFzIGRlZmluZWQgYXJlIGNvbXBs ZXRlIGFuZCBwcm92aWRlIGEgZGV0ZXJtaW5pc3RpYyBhbnN3ZXIgaW4gYWxsIGNhc2VzLg0KPiBJ ZiB5b3UgYmVsaWV2ZSB0aGF0IGlzIG5vdCB0cnVlIHBsZWFzZSBwcm92aWRlIGEgc3BlY2lmaWMg ZXhhbXBsZSB3aGVyZSB5b3UgYXBwbHkgYWxsIHRoZSBydWxlcyBpbiB0aGUgb3JkZXIgc3BlY2lm aWVkIGFuZCBzdGlsbCBkbyBub3QgZGV0ZXJtaW5lIHRoZSBwcmVmZXJyZWQgZW50cnkuDQo+ICAN Cj4gIA0KPiAtICAgICAgICAgIE9uIHRoZSBiZWxvdyBhc3N1bXB0aW9uOiAoU2VjdGlvbiAzLjIu NCkNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDigJxUaGlzIGhh cyB0aGUgbmljZSBwcm9wZXJ0eSB0aGF0IGEgc2luZ2xlIG1pc2NvbmZpZ3VyYXRvaW9uIG9mIGFu IFNSTVMNCj4gICAgICAgICAgICAgICAgICBlbnRyeSB3aXRoIGEgbGFyZ2UgcmFuZ2Ugd2lsbCBu b3QgYmUgcHJlZmVycmVkIG92ZXIgYSBsYXJnZSBudW1iZXIgb2YNCj4gICAgICAgICAgICAgICAg ICBTSURzIGFkdmVydGlzZWQgaW4gcHJlZml4IHJlYWNoYWJpbGl0eSBhZHZlcnRpc2VtZW50cy7i gJ0NCj4gV2hpbGUgYW55dGhpbmcgY2FuIGhhcHBlbiBpbiB0aGVvcnksIEkgZm91bmQgaXQgYml0 IG9kZCB0byBzZWUgd2h5IFNSTVMgZW50cnkgaXMgYmVpbmcgYWR2ZXJ0aXNlZCBhbmQgZm9yIHRo ZSBzYW1lIHByZWZpeCwgU0lEIGlzIGFsc28gYWR2ZXJ0aXNlZCB0aHJvdWdoIHJlYWNoYWJpbGl0 eSBhZHZlcnRpc2VtZW50cz8gDQo+IFRoaXMgaXMgYWdhaW5zdCB0aGUgc3Bpcml0IG9mIFNSTVMg YWR2ZXJ0aXNlbWVudCwgaXNu4oCZdCBpdD8gV2hpbGUgdGhpcyBjYW4gaGFwcGVuLCBpdCBzZWVt cyB3ZSBhcmUgY2xhaW1pbmcgcmVzb2x1dGlvbiBzb2x1dGlvbiBieSBmb2N1c2luZyBtb3JlIG9u ICB0aGlzIGNhc2UgaW4gdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgZG9jdW1lbnQuDQo+ICAN Cj4gW0xlczpdIFRoZXJlIGFyZSB0d28gbGVnaXRpbWF0ZSB1c2UgY2FzZXMgZm9yIFNSTVM6DQo+ ICANCj4gMSlUbyBhZHZlcnRpc2UgU0lEcyBmb3Igbm9uLVNSIGNhcGFibGUgbm9kZXMNCj4gMilB cyBhIGdsb2JhbCBwcm92aXNpb25pbmcgdG9vbA0KPiAgDQo+IExldOKAmXMgZXhhbWluZSB0aGUg Zmlyc3QgY2FzZS4gSSBoYXZlIGFuIExEUCBlbmFibGVkIG5ldHdvcmsgYW5kIEkgYmVnaW4gaW50 cm9kdWNpbmcgU1IgY2FwYWJsZSBub2Rlcy4gQXQgYSBnaXZlbiBtb21lbnQgaW4gdGltZSBSb3V0 ZXIgQSBpcyBOT1QgU1IgY2FwYWJsZSBhbmQgU1JNUyBhZHZlcnRpc2VtZW50cyBjb3ZlciBwcmVm aXggU0lEcyBmb3IgdGhlIGFkZHJlc3NlcyBhc3NvY2lhdGVkIHdpdGggUm91dGVyIEEuDQo+IEkg dGhlbiB1cGdyYWRlIFJvdXRlciBBIHRvIGJlY29tZSBTUiBjYXBhYmxlLiBCZWNhdXNlIEkgd2Fu dCB0byBkbyDigJxtYWtlLWJlZm9yZS1icmVha+KAnSBJIGRvIG5vdCBpbW1lZGlhdGVseSByZW1v dmUgdGhlIFNSTVMgYWR2ZXJ0aXNlbWVudHMgY292ZXJpbmcgdGhlIGFkZHJlc3NlcyBhc3NvY2lh dGVkIHdpdGggUm91dGVyIEEuIEkgdXBncmFkZSBBLCBhZGQgY29uZmlndXJhdGlvbiBvZiBTSURz IGxvY2FsbHkgb24gUm91dGVyIEEsIGFuZCB2ZXJpZnkgdGhhdCB0aGUgYWR2ZXJ0aXNlbWVudHMg b3JpZ2luYXRpbmcgZnJvbSBwcm90b2NvbHMgb24gUm91dGVyIEEgYXJlIGNvcnJlY3QuIElmIGFu IGluY29uc2lzdGVuY3kgaXMgaW50cm9kdWNlZCB3aGVuIGNvbmZpZ3VyaW5nIHRoZSBTSURzIG9u IFJvdXRlciBBIHRoZW4gSSB3aWxsIGhhdmUgYW4gU1JNUyBhZHZlcnRpc2VtZW50IGFuZCBhIHBy ZWZpeC1yZWFjaGFiaWxpdHkgYWR2ZXJ0aXNlbWVudCB0aGF0IGNvbmZsaWN0LiBVbnRpbCB0aGUg Y29uZmxpY3QgaXMgY29ycmVjdGVkIHdlIHVzZSB0aGUgY29uZmxpY3QgcmVzb2x1dGlvbiBydWxl cyB0byBwcm92aWRlIGRldGVybWluaXN0aWMgZm9yd2FyZGluZyBiZWhhdmlvci4NCj4gIA0KPiBU aGlzIHRvIG1lIGlzIGEgbm9ybWFsIGFuZCBleHBlY3RlZCB1cGdyYWRlIHNjZW5hcmlvLg0KPiAg DQo+ICANCj4gVGhpcyBpcyBvbmUgb2YgdGhlIHJlYXNvbnMgb2YgbXkgZmlyc3QgY29tbWVudCBi ZWxvdy4gWW91IGdvdCB0byBzZXBhcmF0ZSB0aGUgcmVhY2hhYmlsaXR5IGFkdmVydGlzZW1lbnRz IGFuZCBTUk1TIGFkdmVydGlzZW1lbnRzOyBhcyBpbiBwcmluY2lwbGUgdGhlc2UgYXJlIGRlZmlu ZWQgZm9yIGRpZmZlcmVudCBwdXJwb3Nlcy4gSSBkb27igJl0IHNlZSB3ZSAgbmVlZCBhbGdvcml0 aG0gdG8gcHJlZmVyIHJlYWNoYWJpbGl0eSBhZHZlcnRpc2VtZW50IG92ZXIgU1JNUyBhZHZlcnRp c2VtZW50IChpZiB3ZSBkb27igJl0IGNvbXBhcmUgdGhlc2UgMiBjYXRlZ29yaWVzKS4NCj4gIA0K PiAgDQo+ICANCj4gW0xlczpdIEkgZGlzYWdyZWUg4oCTIGhvcGVmdWxseSBteSBjb21tZW50cyBo YXZlIGhlbHBlZCB5b3UgdG8gdW5kZXJzdGFuZCB3aHkuDQo+ICANCj4gICAgTGVzDQo+ICANCj4g IA0KPiBhcyB0aGUgc2VjdGlvbnMgeW91IGhhdmUgcXVvdGVkIGNsZWFybHkgc3RhdGUuDQo+ICAN Cj4gV2h5PyBCZWNhdXNlIHdlIG5lZWQgY29uc2lzdGVudCB1c2Ugb2YgU0lEcyBpbiB0aGUgZm9y d2FyZGluZyBwbGFuZS4gRnJvbSBmb3J3YXJkaW5nIHBlcnNwZWN0aXZlIGl0IG1hdHRlcnMgbm90 IHdoZXRoZXIgdGhlIFNJRCB3YXMgYWR2ZXJ0aXNlZCBieSBwcm90b2NvbCBpbnN0YW5jZSAjMSBv ciAjMiBvciBieSBhbiBTUk1TLiANCj4gIA0KPiBXaGF0IG1hdHRlcnMgaXMgdGhhdCB0aGUgU0lE IEkgdXNlIHRvIGRldGVybWluZSB3aGF0IGxhYmVsIEkgaW5zdGFsbCBpbiBteSBmb3J3YXJkaW5n IHBsYW5lIGlzIHRoZSBzYW1lIFNJRCB0aGF0IG15IG5laWdoYm9ycyB3aWxsIHVzZS4gT3RoZXJ3 aXNlIGZvcndhcmRpbmcgd2lsbCBiZSBicm9rZW4uDQo+ICANCj4gICAgTGVzDQo+ICANCj4gIA0K PiBGcm9tOiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIFVtYSBDaHVuZHVyaQ0KPiBTZW50OiBXZWRuZXNkYXksIEFwcmlsIDI3LCAyMDE2IDQ6MzEg UE0NCj4gVG86IGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb207IHNwcmluZ0BpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW3NwcmluZ10gZHJhZnQtZ2luc2Jlcmctc3ByaW5nLWNvbmZsaWN0LXJlc29s dXRpb24gLSBXRyBhZG9wdGlvbiBjYWxsDQo+ICANCj4gRGVhciBBdXRob3JzLA0KPiAgDQo+IEhh dmUgZmV3IGNvbW1lbnRzIG9uIHRoZSBkcmFmdDoNCj4gIA0KPiAxLiANCj4gICAgICAgICBBcyBJ IGluZGljYXRlZCBkdXJpbmcgbWVldGluZyAtIEkgYW0gbm90IHN1cmUgd2h5IHdlIGhhdmUgdG8g Y2x1YiAgdmVyaWZpY2F0aW9uIG9mIFNJRHMgYWR2ZXJ0aXNlZCB0aHJvdWdoIHJlZ3VsYXIgcHJv dG9jb2wgcmVhY2hhYmlsaXR5DQo+ICAgICAgICAgICAgICAgICBwcmVmaXhlcyBhbmQgdGhlIHJh bmdlcyBhZHZlcnRpc2VkIHRocm91Z2ggJ01hcHBpbmcgU2VydmVyJyAgKFNSTVMpLiBJIGRpZG4n dCBzZWUgYW55IGNvbXBlbGxpbmcgcmVhc29uIHRvIGRvIHRoaXMuDQo+ICAgICAgICAgICAgICAg ICAgU0lEcyBhZHZlcnRpc2VkIHRocm91Z2ggcmVhY2hhYmlsaXR5IHByZWZpeGVzIGRvZXNuJ3Qg aGF2ZSByYW5nZXMgdW5saWtlIFNSTVMgYWR2ZXJ0aXNlbWVudHMuIA0KPiAgICAgICAgICAgICAg ICAgIEFzIFNSTVMgYWR2ZXJ0aXNlbWVudHMgYXJlIHByaW1hcmlseSBmb3Igbm9kZXMgd2hpY2gg YXJlIG5vdCBTUiBjYXBhYmxlIGFuZCAgSSBmZWVsIHdlIHNob3VsZCBub3QgbWl4IHRoaXMgd2l0 aCBub2RlcyB3aGljaCBhcmUgU1IgY2FwYWJsZS4NCj4gIA0KPiAgICAgICAgIFRoaXMgaXNvbGF0 aW9uIGhlbHBzIHJlc3RyaWN0aW5nIHRoZSByZXNvbHV0aW9uIHdvcmsgcHJpbWFyaWx5IGZvciBt dWx0aXBsZSBTUk1TIGVudHJpZXMgYWR2ZXJ0aXNlZCB0aHJvdWdoIG9uZSBub2RlIG9yIG11bHRp cGxlIG5vZGVzLg0KPiAgICAgICAgICAgICAgICAgU1JNUyBhZHZlcnRpc2VtZW50cyBhcmUgaW5k ZWVkIGxpdHRsZSBiaXQgdW5pcXVlIGluIHRoYXQgeW91IGFyZSBhZHZlcnRpc2luZyAiY29uZmln dXJhdGlvbiIgb24gYmVoYWxmIG9mIG5vZGUgWCBmcm9tIG5vZGUgWQ0KPiAgICAgICAgICAgICAg ICAgd2l0aCByYW5nZXMgKGJvdGggcHJlZml4IHJhbmdlcyBhbmQgU0lEIHJhbmdlcykuDQo+ICAN Cj4gIA0KPiAyLiANCj4gICAgICAgICAgICAgICAgIFJlZ2FyZGluZyAgdGhlIHNjb3BlIG9mIGNv bmZsaWN0IHJlc29sdXRpb246DQo+ICANCj4gIA0KPiAgICAgICAgU2VjdGlvbiAxDQo+ICANCj4g ICAgICAgICAgICAiICAgVGhlIHByb2JsZW0gdG8gYmUgYWRkcmVzc2VkIGlzIHByb3RvY29sIGlu ZGVwZW5kZW50IGkuZS4sIHNlZ21lbnQNCj4gICAgICAgICAgcmVsYXRlZCBhZHZlcnRpc2VtZW50 cyBtYXkgYmUgb3JpZ2luYXRlZCBieSBtdWx0aXBsZSBub2RlcyB1c2luZw0KPiAgICAgICAgICBk aWZmZXJlbnQgcHJvdG9jb2xzIGFuZCB5ZXQgdGhlIGNvbmZsaWN0IHJlc29sdXRpb24gTVVTVCBi ZSB0aGUgc2FtZQ0KPiAgICAgICAgICBvbiBhbGwgbm9kZXMgcmVnYXJkbGVzcyBvZiB0aGUgcHJv dG9jb2wgdXNlZCB0byB0cmFuc3BvcnQgdGhlDQo+ICAgICAgICAgIGFkdmVydGlzZW1lbnRzLiIN Cj4gIA0KPiAgICAgICAgIFNlY3Rpb24gMy4yLjgNCj4gICAgICAgICAgICIgICBvICBJbiBjYXNl cyB3aGVyZSBtdWx0aXBsZSByb3V0aW5nIHByb3RvY29scyBhcmUgaW4gdXNlIG1hcHBpbmcNCj4g ICAgICAgZW50cmllcyBhZHZlcnRpc2VkIGJ5IGFsbCByb3V0aW5nIHByb3RvY29scyBNVVNUIGJl IGluY2x1ZGVkLiINCj4gIA0KPiAgICAgICBUaGlzIHNvdW5kcyBsaWtlIHdlIGFyZSBzZWVraW5n IHRvIHJlc29sdmUgY29uZmxpY3RpbmcgZW50cmllcyBvdXRzaWRlIGFuZCBhY3Jvc3MgdGhlIHBy b3RvY29scz8NCj4gICAgICAgRWFjaCBJR1AgaGFzIHNlcGFyYXRlIG1lY2hhbmlzbSBmb3IgYWR2 ZXJ0aXNpbmcgbWFwcGluZyBlbnRyeSBhbmQgSSB0aGlzIGlzIG5vdCBjbGVhciB3aXRoIHRoZSBj dXJyZW50IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGhvdyB3ZSBjYW4gY3Jvc3MgdmVyaWZ5IFNJRC9Q cmVmaXggY29uZmxpY3QgYWNyb3NzICB0aGUgcHJvdG9jb2wuDQo+ICAgICAgQ2FuIHlvdSBjbGFy aWZ5IHRoaXM/DQo+ICANCj4gIA0KPiAtLQ0KPiBVbWEgQy4NCj4gIA0KPiAgDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbQ0KPiBTZW50 OiBUaHVyc2RheSwgQXByaWwgMTQsIDIwMTYgMTI6NTUgQU0NCj4gVG86IHNwcmluZ0BpZXRmLm9y Zw0KPiBTdWJqZWN0OiBSZTogW3NwcmluZ10gZHJhZnQtZ2luc2Jlcmctc3ByaW5nLWNvbmZsaWN0 LXJlc29sdXRpb24gLSBXRyBhZG9wdGlvbiBjYWxsDQo+ICANCj4gPiBGcm9tOiAgYnJ1bm8uZGVj cmFlbmVAb3JhbmdlLmNvbSA+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNCwgMjAxNiA5OjUxDQo+ ID4gQU0NCj4gPg0KPiA+IERlYXIgV0csDQo+ID4NCj4gPiBBcyB3ZSBkaXNjdXNzZWQgYXQgb3Vy IG1lZXRpbmcgbGFzdCB3ZWVrLCB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIGhhcw0KPiA+IGJlZW4g cmVxdWVzdGVkIGZvciBkcmFmdC1naW5zYmVyZy1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbi4N Cj4gPiBQbGVhc2UgcmVwbHkgdG8gdGhlIGxpc3Qgd2l0aCB5b3VyIGNvbW1lbnRzLCBpbmNsdWRp bmcgYWx0aG91Z2ggbm90DQo+ID4gbGltaXRlZCB0byB3aGV0aGVyIG9yIG5vdCB5b3Ugc3VwcG9y dCBhZG9wdGlvbi4NCj4gIA0KPiBXZSB3aWxsIGVuZCB0aGUgY2FsbCBvbiBBcHJpbCAyOSwgMjAx Ni4NCj4gIA0KPiAgDQo+ID4gVGhhbmtzLA0KPiA+DQo+ID4gLS1Kb2huIGFuZCBCcnVubw0KPiA+ DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gX19fX18NCj4gPg0KPiA+IENlIG1lc3NhZ2Ug ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0K PiA+IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBh cyBldHJlIGRpZmZ1c2VzLA0KPiA+IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UNCj4gPiBwYXIgZXJyZXVyLCB2ZXVpbGxl eiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaQ0KPiA+IHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcw0KPiA+IGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9u c2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu IE1lcmNpLg0KPiA+DQo+ID4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yDQo+ID4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1h eSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QNCj4gPiBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPiA+IElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh bmQNCj4gPiBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+ID4gQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlDQo+ID4gYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+ID4g VGhhbmsgeW91Lg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+ID4gc3ByaW5nQGlldGYub3Jn DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCj4gIA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ICANCj4gQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVu dCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2ll ZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29w aWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBl cnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJl IGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJl c3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNp ZmllLiBNZXJjaS4NCj4gIA0KPiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkg Y29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBi ZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQg b3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+IEFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gVGhhbmsgeW91Lg0KPiAgDQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNwcmluZyBtYWls aW5nIGxpc3QNCj4gc3ByaW5nQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc3ByaW5nDQo+ICANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gc3ByaW5nIG1haWxpbmcgbGlzdA0KPiBzcHJpbmdAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg0K From nobody Wed May 11 08:42:57 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A3B112B008; Wed, 11 May 2016 08:42:52 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160511154252.15175.96459.idtracker@ietfa.amsl.com> Date: Wed, 11 May 2016 08:42:52 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-ldp-interop-02.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 15:42:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking of the IETF. Title : Segment Routing interworking with LDP Authors : Clarence Filsfils Stefano Previdi Ahmed Bashandy Bruno Decraene Stephane Litkowski Filename : draft-ietf-spring-segment-routing-ldp-interop-02.txt Pages : 19 Date : 2016-05-11 Abstract: A Segment Routing (SR) node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SR domain. The Segment Routing architecture can be directly applied to the MPLS data plane with no change in the forwarding plane. This drafts describes how Segment Routing operates in a network where LDP is deployed and in the case where SR-capable and non-SR-capable nodes coexist. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-ldp-interop-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 11 09:44:21 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D1712B02C; Wed, 11 May 2016 09:44:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160511164417.15295.70143.idtracker@ietfa.amsl.com> Date: Wed, 11 May 2016 09:44:17 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-08.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 16:44:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking of the IETF. Title : Segment Routing Architecture Authors : Clarence Filsfils Stefano Previdi Bruno Decraene Stephane Litkowski Rob Shakir Filename : draft-ietf-spring-segment-routing-08.txt Pages : 24 Date : 2016-05-11 Abstract: Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called segments. A segment can represent any instruction, topological or service-based. A segment can have a local semantic to an SR node or global within an SR domain. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SR domain. Segment Routing can be directly applied to the MPLS architecture with no change on the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. Segment Routing can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address of the packet. The next active segment is indicated by a pointer in the new routing header. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-08 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-08 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed May 11 09:46:11 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70AA412D4FC for ; Wed, 11 May 2016 09:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0pWBaLd3FPfC for ; Wed, 11 May 2016 09:46:08 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB7E812D11F for ; Wed, 11 May 2016 09:46:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=197; q=dns/txt; s=iport; t=1462985167; x=1464194767; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=0Z7hbKu1RPOODgjZMGTS3aq0s3gEti6vVWV0X3aCttA=; b=Mrdk+DxwFwoH4m7ZMsvVwSprTZa8rIQtx3MPzMEJUa2I8eXc0ykaw19V GkcaDMQrZMrLFI05M7VRnssmExu9NhMCWkk+wAyYM2rLJ5lnvNYq5XkvF xf8vW2dTgv6fYA2DUtbKJLAVZmsJk+xT6QJnqDn0Xg3RiK5GQrIAAeojI g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAgDPYDNX/4ENJK1egziBWLkqAQ2Bd?= =?us-ascii?q?odQOBQBAQEBAQEBZSeESTpRAT5CHwgEiEKZTKBIAQEBAQEFAQEBAQEBAQEYhiC?= =?us-ascii?q?BdgiKOIIuBZgnAY4dgVMBjUWPQAEeAQFCg2uIeX8BAQE?= X-IronPort-AV: E=Sophos;i="5.24,608,1454976000"; d="scan'208";a="106831035" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 May 2016 16:46:06 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u4BGk6Ie002340 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 11 May 2016 16:46:06 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 11 May 2016 12:46:06 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Wed, 11 May 2016 12:46:05 -0400 From: "Stefano Previdi (sprevidi)" To: SPRING WG Thread-Topic: updated drafts Thread-Index: AQHRq6ScxCEer3ZboUCQw8ZKaFKdbg== Date: Wed, 11 May 2016 16:46:05 +0000 Message-ID: <64899D50-2C3F-4991-BC29-2F18C5859975@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.161.123] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [spring] updated drafts X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2016 16:46:10 -0000 I just submitted: draft-ietf-spring-segment-routing-ldp-interop-02 and draft-ietf-spring-segment-routing-08 hopefully integrating the remaining comments from Sasha and Eric. Thanks. s. From nobody Thu May 12 00:01:21 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F5612D0E6 for ; Thu, 12 May 2016 00:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 66dKMVZIlcL8 for ; Thu, 12 May 2016 00:01:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39B2412B032 for ; Thu, 12 May 2016 00:01:18 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id BED8618C050 for ; Thu, 12 May 2016 09:01:16 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.60]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 9FBC735C06C for ; Thu, 12 May 2016 09:01:16 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0294.000; Thu, 12 May 2016 09:01:16 +0200 From: To: "spring@ietf.org" Thread-Topic: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call Thread-Index: AdGsG8svRM0KooW1SEqK78vXMpkdDA== Date: Thu, 12 May 2016 07:01:15 +0000 Message-ID: <13748_1463036476_57342A3C_13748_5186_1_53C29892C857584299CBF5D05346208A0F8A3E8F@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.12.53615 Archived-At: Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 07:01:20 -0000 Dear WG, Draft has been accepted as a WG document. Authors, please resubmit as draft-ietf-spring-conflict-resolution Thanks, --Bruno and John > From: bruno.decraene@orange.com Sent: Thursday, April 14, 2016 9:55 AM >=20 > > From: bruno.decraene@orange.com > Sent: Thursday, April 14, 2016 9:51 = AM > > > > Dear WG, > > > > As we discussed at our meeting last week, working group adoption has > been > > requested for draft-ginsberg-spring-conflict-resolution. > > Please reply to the list with your comments, including although not lim= ited > to > > whether or not you support adoption. >=20 > We will end the call on April 29, 2016. >=20 >=20 > > Thanks, > > > > --John and Bruno > > > > > > > > > __________________________________________________________ > > > __________________________________________________________ > > _____ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites > > ou copies sans autorisation. Si vous avez recu ce message par erreur, > veuillez > > le signaler a l'expediteur et le detruire ainsi que les pieces jointes.= Les > > messages electroniques etant susceptibles d'alteration, Orange decline > toute > > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged > > information that may be protected by law; they should not be distribute= d, > > used or copied without authorisation. > > If you have received this email in error, please notify the sender and = delete > > this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have b= een > > modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > spring mailing list > > spring@ietf.org > > https://www.ietf.org/mailman/listinfo/spring >=20 > __________________________________________________________ > __________________________________________________________ > _____ >=20 > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce > message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. >=20 > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From nobody Thu May 12 08:22:36 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B445512D6B0 for ; Thu, 12 May 2016 08:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 rDIumUoLmDwS for ; Thu, 12 May 2016 08:22:33 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.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 03C0F12D6A3 for ; Thu, 12 May 2016 08:22:33 -0700 (PDT) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 71131203BD for ; Thu, 12 May 2016 17:22:31 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 4A1901A007F for ; Thu, 12 May 2016 17:22:31 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0294.000; Thu, 12 May 2016 17:22:30 +0200 From: To: "spring@ietf.org" Thread-Topic: draft-ietf-spring-conflict-resolution - Preference Algorithm Thread-Index: AdGsH1sN5kVjpbgWTcWyrGraBNd0gw== Date: Thu, 12 May 2016 15:22:30 +0000 Message-ID: <9871_1463066551_57349FB7_9871_4893_2_53C29892C857584299CBF5D05346208A0F8A48CF@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F8A48CFOPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: [spring] draft-ietf-spring-conflict-resolution - Preference Algorithm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 15:22:36 -0000 --_000_53C29892C857584299CBF5D05346208A0F8A48CFOPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi authors, all As an individual contributor, please find below some feedback to trigger di= scussion on the Preference Algorithm defined in =A73.2.4. > 1. Smaller range wins Looks ok to me, as this gives preference to Prefix-SID advertisement from S= R routers which speaks for themselves/their own loopback/their own IP prefi= x advertisement; rather than SRMS advertisement which speaker for others. I= OW, to know Brian's SID, I'd rather believe Brian himself rather than Georg= e. Also, this gives preference to SR nodes rather than LDP nodes (SRMS entries= ). Over the time/SR deployment, as more nodes gets SR, the number of nodes = negatively impacted by the wrong configuration change is reduced. Alternatively, I'd be fine to prefer Prefix-SID advertisement over SRMS adv= ertisement. Actually, I'd propose to add this as rule 0. "0. Prefer Prefix-= SID Sub-TLV over SID/Label Binding TLV" I've been told OSPF can't make the distinction, but I'm not sure to see the= issue. > 4. Smaller prefix length wins I'd rather have longer prefix length wins, and move this higher in position= 3 (*). Indeed, we usually primarily care to reach a specific egress node i= .e. loopbacks destinations, which have the longest possible prefix length. (*) It needs to be after IPv6 wins, to not conflict with it, as IPv6 have l= onger prefixes. > 3. Smaller algorithm wins > 5. Smaller starting address (considered as an unsigned integer value) wins I'm fine with this order, to privilege prefix diversity (typically for algo= 0 or 1) rather than algo diversity. (on the basis that to reach a node N, = we need a SID for this node, while to follow algo N, we can use a combinati= ons of segments from other algo). So in summary, I'd propose discussing the following OLD: 1. Smaller range wins 2. IPv6 entry wins over IPv4 entry 3. Smaller algorithm wins 4. Smaller prefix length wins 5. Smaller starting address (considered as an unsigned integer value) w= ins 6. Smaller starting SID wins NEW: 0. Prefix-SID Sub-TLV wins over SID/Label Binding TLV 1. Smaller range wins 2. IPv6 entry wins over IPv4 entry 3. Longer prefix length wins 4. Smaller algorithm wins 5. Smaller starting address (considered as an unsigned integer value) w= ins 6. Smaller starting SID wins Thanks, Regards, -- Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A0F8A48CFOPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi authors, all

 

As an individual contributor, p= lease find below some feedback to trigger discussion on the Preference Algo= rithm defined in =A73.2.4.

 

>   1.  Smaller range wins=

Looks ok to me, as this gives p= reference to Prefix-SID advertisement from SR routers which speaks for them= selves/their own loopback/their own IP prefix advertisement; rather than SR= MS advertisement which speaker for others. IOW, to know Brian’s SID, I’d rather believe Brian himself rat= her than George.

 

Also, this gives preference to = SR nodes rather than LDP nodes (SRMS entries). Over the time/SR deployment,= as more nodes gets SR, the number of nodes negatively impacted by the wron= g configuration change is reduced.

 

Alternatively, =
I’d be fine to prefer Prefix-SID advertisement over SRMS advertisemen=
t. Actually, I’d propose to add this as rule 0. “0. Prefer Pref=
ix-SID Sub-TLV over SID/Label Binding TLV”

I’ve been told OSPF can&#= 8217;t make the distinction, but I’m not sure to see the issue.<= /o:p>

 

> 4.  Smaller prefix length wins

I’d rather have longer pr= efix length wins, and move this higher in position 3 (*). Indeed, we usuall= y primarily care to reach a specific egress node i.e. loopbacks destination= s, which have the longest possible prefix length.

(*) It needs to be after IPv6 w= ins, to not conflict with it, as IPv6 have longer prefixes.

  
>   3.  Smaller algorithm wins<=
o:p>
>   5.  Smaller starting addres=
s (considered as an unsigned integer
       value=
) wins
 

I’m fine with this order,= to privilege prefix diversity (typically for algo 0 or 1) rather than algo= diversity. (on the basis that to reach a node N, we need a SID for this no= de, while to follow algo N, we can use a combinations of segments from other algo).

 

 

So in summary, I’d propos= e discussing the following

OLD: 

   1.  Smaller range wins
   2.  IPv6 entry wins over IPv4 e=
ntry
   3.  Smaller algorithm wins=

   4.  Smaller prefix length wins<=
o:p>
   5.  Smaller starting address (c=
onsidered as an unsigned integer value) wins
   6.  Smaller starting SID wins

 

NEW:

 

   0.  Prefix-SID Sub-TLV wins over SID/Label Binding =
TLV
   1.  Smaller range wins

   2.  IPv6 entry wins over IPv4 e=
ntry


   3.  Longer prefix length wins


   4.  Smaller algorithm wins=



   5.  Smaller starting address (c=
onsidered as an unsigned integer value) wins


   6.  Smaller starting SID wins


 


Thanks,


Regards,


-- Bruno


______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A0F8A48CFOPEXCLILM21corp_-- From nobody Thu May 12 08:22:52 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C3F12D6B8 for ; Thu, 12 May 2016 08:22:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 IcD5yltkveBY for ; Thu, 12 May 2016 08:22:39 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 155C312D6B7 for ; Thu, 12 May 2016 08:22:39 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 815BB3B4579 for ; Thu, 12 May 2016 17:22:37 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.75]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 5ECAA4C048 for ; Thu, 12 May 2016 17:22:37 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%19]) with mapi id 14.03.0294.000; Thu, 12 May 2016 17:22:37 +0200 From: To: "spring@ietf.org" Thread-Topic: draft-ietf-spring-conflict-resolution Thread-Index: AdGsH1sLbD2noig8RN69oeD7/m3vEg== Date: Thu, 12 May 2016 15:22:36 +0000 Message-ID: <5548_1463066557_57349FBD_5548_8297_1_53C29892C857584299CBF5D05346208A0F8A48D7@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F8A48D7OPEXCLILM21corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.12.150616 Archived-At: Subject: [spring] draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 15:22:50 -0000 --_000_53C29892C857584299CBF5D05346208A0F8A48D7OPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, As an individual contributor, please find below some comments: -- Isn't this document specific to the MPLS dataplane? If so, it could be indicated in the introduction, and possibly in the abstr= act. Then this indication could be removed from the 1rst sentence of sectio= ns 2 & 3. -- =A73 "Mapping entries have an explicit context which includes the topology and t= he SR algorithm." A priori you could add "the routing protocol". -- =A73 "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". If a router chooses to use one of the conflicting entries forwarding loops and/or blackholes may result unless it can be guaranteed that all other routers in the network make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. =BB I think we agree on the technical part, but I found the formulation slightl= y biased. I would propose "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". In order to avoid forwarding loops and/or blackholes, the= re is a need for all nodes to make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. This is the purpose of this document. =BB -- =A73.1 "Various types of conflicts may occur" What about :s/Various/Two -- I agree with Robert's and Uma's comment with regards to making this confli= ct resolution an inter- protocol/routing_table issue. In particular, betwee= n SR domains, there is not requirement to have unique SIDs. Hence between P= E and CE, between ASes (both within and across organization), the same SID = could be reused independently). > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > Sent: Sunday,= May 01, 2016 7:11 AM > > We are indeed defining conflict resolution across all the SID advertiseme= nts regardless of source (protocol or SRMS) > Why? Because we need consistent use of SIDs in the forwarding plane No: in the forwarding plane, we need a consistent use of MPLS label. Plus only within an SR domain. Actually, even within a domain, this is depe= ndent on whether SRGB is configured on a per node or a per protocol basis. = I'm not sure how much the agreement has been reached on that one. -- Typo: =A72 OLD : Range 3: (500, 5990 NEW : Range 3: (500, 599) (somewhat significant as otherwise range 3 conflict with range 2) Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A0F8A48D7OPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

As an individual contributor, p= lease find below some comments:

 

--

Isn’t this document speci= fic to the MPLS dataplane?

If so, it could be indicated in= the introduction, and possibly in the abstract. Then this indication could= be removed from the 1rst sentence of sections 2 & 3.=

--

=A73

“Mapping entr= ies have an explicit context which includes the topology and the SR algorit= hm.“

A priori you could = add “the routing protocol”.

--

=A73

“When conflicts occur, it is not=

   possible for routers to know which o=
f the conflicting advertisements
   is "correct".  If a r=
outer chooses to use one of the conflicting
   entries forwarding loops and/or blac=
kholes may result unless it can
   be guaranteed that all other routers=
 in the network make the same
   choice.  Making the same choice=
 requires that all routers have
   identical sets of advertisements and=
 that they all use the same
   selection algorithm. =BB=

 
I think we agree on the technical part, but I fou=
nd the formulation slightly biased. I would propose
“When conflicts occur, it is not=

   possible for routers to know which o=
f the conflicting advertisements
   is "correct".  In ord=
er to avoid forwarding loops and/or blackholes, there is a need for all nod=
es to make the same choice.
  Making the same choice requires that all r=
outers have
   identical sets of advertisements and=
 that they all use the same
   selection algorithm. This is the pur=
pose of this document. =BB

--

=A73.1

“Various types of conflicts may occur”=
;
What about :s/Various/Two

--

I agree with Robert’s &nb= sp;and Uma’s comment with regards to making this conflict resolution = an inter- protocol/routing_table issue. In particular, between SR domains, = there is not requirement to have unique SIDs. Hence between PE and CE, between ASes (both within and across organization), the same SI= D could be reused independently).

 

> From: Les Ginsberg (ginsberg) [mailto:ginsberg= @cisco.com] > Sent: Sunday, May 01, 2016 7:11 AM

>&nbs= p;

> We are indeed defining co= nflict resolution across all the SID advertisements regardless of source (p= rotocol or SRMS)

> Why?= Because we need consistent use of SIDs in the forwarding plane

 

No: in the forwarding plane, we= need a consistent use of MPLS label.

Plus only within an SR domain. = Actually, even within a domain, this is dependent on whether SRGB is config= ured on a per node or a per protocol basis. I’m not sure how much the= agreement has been reached on that one.

 

--

Typo:

=A72

OLD : Range 3: (500, 5990

NEW : Range 3: (500, 599)

 

(somewhat significant as otherwise range 3 conflict with ra= nge 2)

 

Thanks,

Regards,

Bruno

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A0F8A48D7OPEXCLILM21corp_-- From nobody Thu May 12 08:23:05 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6BEA12D6B7 for ; Thu, 12 May 2016 08:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.914 X-Spam-Level: X-Spam-Status: No, score=-2.914 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 A2BZVw7wcJyV for ; Thu, 12 May 2016 08:22:41 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B3B412D6A3 for ; Thu, 12 May 2016 08:22:41 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 8581EC044A for ; Thu, 12 May 2016 17:22:39 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id 57550120065 for ; Thu, 12 May 2016 17:22:39 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0294.000; Thu, 12 May 2016 17:22:39 +0200 From: To: "spring@ietf.org" Thread-Topic: draft-ietf-spring-conflict-resolution - Policy Thread-Index: AdGsYbndUWczH5clSpukONRF0Kk37A== Date: Thu, 12 May 2016 15:22:38 +0000 Message-ID: <24715_1463066559_57349FBF_24715_2873_1_53C29892C857584299CBF5D05346208A0F8A48DE@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F8A48DEOPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: [spring] draft-ietf-spring-conflict-resolution - Policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 15:22:52 -0000 --_000_53C29892C857584299CBF5D05346208A0F8A48DEOPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi authors, all As an individual contributor, please find below some feedback on the policy. I'm wondering if we could address the conflict on a per FEC/Prefix basis ra= ther than on a per IGP advertisement basis. If so, this may avoid the discussion between the Quarantine vs ignore polic= y. The problem that we need to solve, is to find the SID for a prefix (P1). The algo could be: - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts // as a result, we get a list of SIDi - Pij for P1 Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID / no SID availa= ble for this prefix P1 Note that it would probably be better for the preference algo to put the= SID tie-brake before the prefix tie-break as with the prefix tie-break, we= suffer from the conflict twice (Prefix - SID mapping, then SID- prefix map= ping) which increase the diversity and hence the chance of not finding a va= lid entry. But for the below examples, I used the preference algo from dr= aft-ietf-*-00 Below are examples, running this policy on typical configuration error case= s. Examples 3.4.4. Network operation Consider the following simple network example: 1. 100 nodes: R1 to R100; 2. IP Loopbacks are from 192.0.2.1 to 192.0.2.100: 3. SID are from 1 to 100; 4. R1 to R50 are SR capable and advertised their own SID using Prefix-SID sub-TLV; 5. R51 to R100 are SR non-capable, running LDP and their SID are advertised by two redundant Mapping Server MS1 and MS2; 6. As the number of nodes which are SR capable are expected to increase and as in real deployment their Loopback addresses would no the contiguous, the Mapping servers advertisement covers all Loopbacks: (192.0.2.1/32, 1, 100); Subsequent sections evaluate the consequences of a single configuration error, for all conflict resolution options. 3.4.4.1. Example 1: SID configured on 1 node conflict with SID configured on another node Following a typo during configuration, R2 is configured with a SID of 12. That SID conflicts with the Prefix-SID advertised by R12 and the Ma= pping Server Advertisement for R12. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R12, a single SID is advertised and hence selected. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID12 is selected for R2. For R12, the algo evaluates a conflict between the following advertismen= ts: R12 - SID12 - R12 (prefix SID, prefix SID) R12 - SID12 - R2 (prefix SID, prefix SID) R12 - SID12 - R12 (prefix SID, MS) R12 - SID12 - R2 (MS, prefix SID) R12 - SID12 - R12 (MS, MS) Best one is R12 - SID12 - R2 (smaller range (prefix SID),smaller range (= prefix SID), smaller starting adresse (R2)) R12 <> R2 =3D=3D> R12 has no SID. 3.4.4.2. Example 2: SID configured on 1 node conflict with SID configured on the Mapping Server Following a typo during configuration, R2 is configured with a SID of 52. That SID conflicts with the Mapping Server advertisements of MS1 and MS2 for the loopback of R52. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R52, a single SID is advertised and hence selected. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID52 - R2 (prefix SID, prefix SID) R2 - SID52 - R52 (prefix SID, MS) R2 - SID2 - R2 (MS, MS) Best one is R2 - SID52 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID52 is selected for R2. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS, MS) R52 - SID52 - R2 (MS, prefix SID) Best one is R52 - SID52 - R2 (smaller range (prefix SID)) R52 <> R2 =3D=3D> R52 has no SID. 3.4.4.3. Example 3: wrong configuration of a MS Following a typo during configuration, MS1 is configured (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0 instead of 192.0.2.1). That advertisement conflicts with the Mapping Server advertisements of MS2 and the Prefix-SID advertised by R1...R50. We have a conflict for all routers except R100. For LDP only routers R51 to R99 we have a conflict between both MS adver= tisement. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS2, MS2) R52 - SID52 - R51 (MS2, MS1) R52 - SID53 - R52 (MS1, MS1) R52 - SID53 - R53 (MS1, MS2) Best one is R52 - SID52 - R51 (smaller starting address) R52 <> R51 =3D=3D> R52 has no SID. For SR routers, R1 to 50, we have a conflict between both MS advertiseme= nt and Prefix SID advertisements. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 - SID 2 - R2 (Prefix SID, MS2) R2 - SID 2 - R1 (Prefix SID, MS1) R2 - SID 2 - R2 (MS2, MS2) R2 - SID 2 - R2 (MS2, Prefix SID) R2 - SID 2 - R1 (MS2, MS1) R2 - SID 3 - R2 (MS1, MS1) R2 - SID 3 - R3 (MS1, MS2) R2 - SID 3 - R3 (MS1, Prefix SID) Best one is R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 =3D=3D R2 hence R2 use SID2. Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A0F8A48DEOPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi authors, all

 

As an individual contributor, p= lease find below some feedback on the policy.

 

I'm wondering if we could addre= ss the conflict on a per FEC/Prefix basis rather than on a per IGP advertis= ement basis.

If so, this may avoid the discu= ssion between the Quarantine vs ignore policy.

 

The problem that we need to sol= ve, is to find the SID for a prefix (P1).

The algo could be:

- Find all SIDi advertised for = the prefix P1          &n= bsp;            = ;            &n= bsp;            = ;           // identifica= tion of Prefix conflicts

     &= nbsp;          - For each SIDi= find all the prefix Pij associated with SIDi     =          // identification of SID c= onflicts

 

// as a result, we get a list o= f SIDi – Pij for P1

 

Get the best as per the prefere= nce algorithm.

If best Pij =3D=3D P1

     &= nbsp;          then use SIDij = for P1

     &= nbsp;          else return no = SID            =             &nb= sp; / no SID available for this prefix P1

 

     &= nbsp;         

   Note that it would= probably be better for the preference algo to put the SID tie-brake before= the prefix tie-break as with the prefix tie-break, we suffer from the conf= lict twice (Prefix - SID mapping, then SID- prefix mapping) which increase the diversity and hence the chance of not finding = a valid entry.   But for the below examples, I used the preferenc= e algo from draft-ietf-*-00

     &= nbsp;         

 

Below are examples, running thi= s policy on typical configuration error cases.   

Examples

3.4.4.  Network operation<= o:p>

 

   Consider the follo= wing simple network example:

 

   1.  100 nodes= : R1 to R100;

 

   2.  IP Loopba= cks are from 192.0.2.1 to 192.0.2.100:

 

   3.  SID are f= rom 1 to 100;

 

   4.  R1 to R50= are SR capable and advertised their own SID using

     &= nbsp; Prefix-SID sub-TLV;

 

   5.  R51 to R1= 00 are SR non-capable, running LDP and their SID are

      =  advertised by two redundant Mapping Server MS1 and MS2;

 

   6.  As the nu= mber of nodes which are SR capable are expected to

     &= nbsp; increase and as in real deployment their Loopback addresses would

     &= nbsp; no the contiguous, the Mapping servers advertisement covers all<= /o:p>

     &= nbsp; Loopbacks: (192.0.2.1/32, 1, 100);

 

   Subsequent section= s evaluate the consequences of a single

   configuration erro= r, for all conflict resolution options.

 

3.4.4.1.  Example 1: SID c= onfigured on 1 node conflict with SID

     &= nbsp;    configured on another node

 

   Following a typo d= uring configuration, R2 is configured with a SID of

   12.  That SID= conflicts with the Prefix-SID advertised by R12 and the Mapping Server Adv= ertisement for R12.

   Note: both MS adve= rtisement are the same, so we only consider one in the below analysis.=

   =

   All prefix bu= t R2 and R12, a single SID is advertised and hence selected.

   =

   For R2, the a= lgo evaluates a conflict between the following advertisments:

   R2 - SID2 - R2 (MS= , MS)

   R2 - SID12 - R12 (= prefix SID, MS)

   R2 - SID12 - = R2  (prefix SID, prefix SID)

   =

   

   Best one is R= 2 - SID12 - R2 (smaller range (prefix SID),smaller range (prefix SID))=

   =3D=3D> SID12 i= s selected for R2.

   =

   For R12, the = algo evaluates a conflict between the following advertisments:

   R12 - SID12 - R12 = (prefix SID, prefix SID)

   R12 - SID12 - R2&n= bsp; (prefix SID, prefix SID)

   R12 - SID12 - R12 = (prefix SID, MS)

   R12 - SID12 - R2&n= bsp; (MS, prefix SID)

   R12 - SID12 - R12 = (MS, MS)

   =

   Best one is R= 12 - SID12 - R2 (smaller range (prefix SID),smaller range (prefix SID), sma= ller starting adresse (R2))

   R12 <> = R2 =3D=3D> R12 has no SID.

   =

   3.4.4.2. = ; Example 2: SID configured on 1 node conflict with SID

     &= nbsp;    configured on the Mapping Server<= /p>

 

   Following a typo d= uring configuration, R2 is configured with a SID of

   52.  That SID= conflicts with the Mapping Server advertisements of MS1<= /p>

   and MS2 for the lo= opback of R52.

   Note: both MS adve= rtisement are the same, so we only consider one in the below analysis.=

   =

   All prefix bu= t R2 and R52, a single SID is advertised and hence selected.

   =

   For R2, the a= lgo evaluates a conflict between the following advertisments:

   R2 - SID52 - R2&nb= sp; (prefix SID, prefix SID)

   R2 - SID52 - R52 (= prefix SID, MS)

   R2 - SID2  - = R2  (MS, MS)

   =

   Best one is R= 2 - SID52 - R2 (smaller range (prefix SID),smaller range (prefix SID))=

   =3D=3D> SID52 i= s selected for R2.

   =

   For R52, the = algo evaluates a conflict between the following advertisments:

   R52 - SID52 - R52 = (MS, MS)

   R52 - SID52 - R2&n= bsp; (MS, prefix SID)

   =

   Best one is R= 52 - SID52 - R2 (smaller range (prefix SID))

   R52 <> R2 = =3D=3D> R52 has no SID.

   =

   

3.4.4.3.  Example 3: wrong= configuration of a MS

 

   Following a typo d= uring configuration, MS1 is configured

   (192.0.2.0/32, 1, = 100). (i.e. 192.0.2.0 instead of 192.0.2.1).  That

   advertisement conf= licts with the Mapping Server advertisements of MS2

   and the Prefix-SID= advertised by R1...R50.

   =

   We have a con= flict for all routers except R100.

   =

   For LDP only = routers R51 to R99 we have a conflict between both MS advertisement.

   For R52, the algo = evaluates a conflict between the following advertisments:=

   R52 - SID52 - R52 = (MS2, MS2)

   R52 - SID52 - R51 = (MS2, MS1)

   R52 - SID53 - R52 = (MS1, MS1)

   R52 - SID53 - R53 = (MS1, MS2)

 

   Best one is R52 - = SID52 - R51 (smaller starting address)

   R52 <> R51 = =3D=3D> R52 has no SID.

   =

   For SR router= s, R1 to 50, we have a conflict between both MS advertisement and Prefix SI= D advertisements.

   For R2, the algo e= valuates a conflict between the following advertisments:<= /p>

   R2 - SID 2 - R2 (P= refix SID, Prefix SID)

   R2 - SID 2 - R2 (P= refix SID, MS2)

   R2 - SID 2 - R1 (P= refix SID, MS1)

   R2 - SID 2 - R2 (M= S2, MS2)

   R2 - SID 2 - R2 (M= S2, Prefix SID)

   R2 - SID 2 - R1 (M= S2, MS1)

   R2 - SID 3 - R2&nb= sp; (MS1, MS1)

   R2 - SID 3 - R3&nb= sp; (MS1, MS2)

   R2 - SID 3 - R3&nb= sp; (MS1, Prefix SID)

   =

   Best one is R= 2 - SID 2 - R2 (Prefix SID, Prefix SID)

   R2 =3D=3D R2 hence= R2 use SID2.

 

Regards,

Bruno

 

______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A0F8A48DEOPEXCLILM21corp_-- From nobody Thu May 12 10:50:04 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA3412D516 for ; Thu, 12 May 2016 10:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4ojPaJekwkH for ; Thu, 12 May 2016 10:49:58 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46AC12B007 for ; Thu, 12 May 2016 10:49:57 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-65-5734ba4f4c41 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 15.59.09012.F4AB4375; Thu, 12 May 2016 19:15:59 +0200 (CEST) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0248.002; Thu, 12 May 2016 13:49:56 -0400 From: Uma Chunduri To: "Stefano Previdi (sprevidi)" Thread-Topic: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call Thread-Index: AQHRpiTSIwvtcse5JkGIWGS+IKi0Mp+sWAzggAeUHQCAAa6/4A== Date: Thu, 12 May 2016 17:49:55 +0000 Message-ID: <1B502206DFA0C544B7A60469152008635BCE586E@eusaamb106.ericsson.se> References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10411_1460620508_570F4CDC_10411_96_23_53C29892C857584299CBF5D05346208A0F86E45F@OPEXCLILM21.corporate.adroot.infra.ftgroup> <1B502206DFA0C544B7A6046915200863580C54E9@eusaamb105.ericsson.se> <0468fb2fe35841668bc35606e988074c@XCH-ALN-001.cisco.com> <1B502206DFA0C544B7A60469152008635BCD31AB@eusaamb106.ericsson.se> <445eeb6f8f12480f90e941a81eeaafc7@XCH-ALN-001.cisco.com> <1B502206DFA0C544B7A60469152008635BCDFEFB@eusaamb106.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZXLonUNd/l0m4QVeXkcWPHXOYLTb82chu sX73IyaL4xd+MzqweEz5vZHVY8mSn0weLc9OsgUwR3HZpKTmZJalFunbJXBlLJq2lLXgyAbG ik0PpjA1MDasYexi5OSQEDCR+DHlLBOELSZx4d56ti5GLg4hgaOMEls/N7OAJIQEljNKbHhk CmKzCehJfJz6kx3EFhEwlTg/4zwzSAOzwBRGibtr2sESwgIhEs9PdgFN5QAqCpW4vtwXot5J 4vuEPlYQm0VAVWLa9AlgNq+Ar8TTWc+ZIBb/ZpG4dnEhM0iCU8BW4tmrtWA2I9B130+tAbuU WUBc4taT+VBXC0gs2XOeGcIWlXj5+B8rhK0kMWnpOVaQG5gFNCXW79KHaFWUmNL9kB1ir6DE yZlPWCYwis1CMnUWQscsJB2zkHQsYGRZxchRWlyQk5tuZLCJERhFxyTYdHcw3p/ueYhRgINR iYd3wWPjcCHWxLLiytxDjBIczEoivK+BMSjEm5JYWZValB9fVJqTWnyIUZqDRUmcV+yRYriQ QHpiSWp2ampBahFMlomDU6qB8Yz2m8vu30yWqbtanK2Qn+0Qt0jO/2HA2Sw5Q9XCrQ91JlSW PI9ZL5scXG1qf7qsqnTard0NhaJ6xvVLfh0+G3X79sk9j5ucNl+VN565sL7g3gnHSesOPrIS Msn65r/cZMq0vHOGjcU7dl0u21zJd3/h1i0nCpYeWP/H+xgHk+wm6X0hK99evKTEUpyRaKjF XFScCAC9hSWDngIAAA== Archived-At: Cc: "Les Ginsberg \(ginsberg\)" , "spring@ietf.org" , "bruno.decraene@orange.com" Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 17:50:01 -0000 U3RlZmFubywNCg0KVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlLg0KDQoJPiB1c2luZyBhIFNSTVMg Zm9yIGFkdmVydGlzaW5nIFNJRCBvbiBiZWhhbGYgb2YgU1IgY2FwYWJsZSBub2RlcyBkb2VzIG5v dCBpbnRyb2R1Y2UgYW55IGNoYW5nZSBpbiB0aGUgU1IgYXJjaGl0ZWN0dXJlIHNvIG5vdCANCiAg ICAgICAgICAgICAgID4gc3VyZSB3aGF0IHdlIG5lZWQgdG8gZG9jdW1lbnQgaGVyZS4NCg0KTXkg cG9pbnQgYmVsb3c6IFdlIGFyZSBjcmVhdGluZyBhIGNvbmZsaWN0IHJlc29sdXRpb24gc29sdXRp b24gZm9yIGEgbm9uLWV4aXN0aW5nIHJlcXVpcmVtZW50IG9mIHVzaW5nICBTUk1TIHZpei4sICAi PjIpQXMgYSBnbG9iYWwgcHJvdmlzaW9uaW5nIHRvb2wiLiANCkZyb20geW91ciBzdGF0ZW1lbnQg YWJvdmUsIGl0IHNlZW1zIHlvdSBoYXZlIGxlc3MgaW50ZXJlc3QgdG8gbWFrZSB0aGlzIGFzIGEg cmVxdWlyZW1lbnQvc2NvcGUgb2YgU1JNUzsgSSBhbSBtb3JlIGFsaWduZWQgaW4gdGhhdCBwYXRo Li4uLg0KDQpPbiB0aGUgc2Vjb25kIHBvaW50Og0KDQoJPiB0aGUgYXJjaGl0ZWN0dXJlIGRyYWZ0 IGlzIGRhdGEtcGFuZSBhZ25vc3RpYyBzbyBJIHByZXN1bWUgeW91IHJlZmVyIHRvIGRyYWZ0LWll dGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLg0KDQpBRkFJUywgIGh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctMDggIHRhbGtz IGFib3V0IGJvdGggZGF0YSBwbGFuZXMgcmlnaHQgZnJvbSBhYnN0cmFjdCB0byBtdWx0aXBsZSBw bGFjZXMgKHdoaWNoIGl0IG91Z2h0IHRvKS4gDQpJIGxlYXZlIHRoaXMgdG8geW91L1dHIG9uIHdo ZXJlIHlvdSB3YW50IHRvIGRvY3VtZW50IHRoaXMgLWJ1dCBJTU8gY29uZmxpY3QgcmVzb2x1dGlv biAic29sdXRpb24gZG9jdW1lbnQiIGluIHRoZSBjdXJyZW50IGZvcm0gcG90ZW50aWFsbHkgaW50 cm9kdWNpbmcgZnVuZGFtZW50YWwgDQpyZXF1aXJlbWVudHMgIHRvIHRoZSBzeXN0ZW0gbGlrZSBj cm9zcyBwcm90b2NvbCB2ZXJpZmljYXRpb24gKHdpdGggaW4vYWNyb3NzIEFTKS4gUGVyaGFwcyBz b21lIGRpc2N1c3Npb24gc2hvdWxkIGJlIHRoZXJlIGluIGRhdGEgcGxhbmUgZG9jdW1lbnQgdGhl bi4NCg0KLS0NClVtYSBDLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBT dGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKSBbbWFpbHRvOnNwcmV2aWRpQGNpc2NvLmNvbV0gDQpT ZW50OiBXZWRuZXNkYXksIE1heSAxMSwgMjAxNiA0OjQ2IEFNDQpUbzogVW1hIENodW5kdXJpDQpD YzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZyk7IGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb207IHNw cmluZ0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzcHJpbmddIGRyYWZ0LWdpbnNiZXJnLXNwcmlu Zy1jb25mbGljdC1yZXNvbHV0aW9uIC0gV0cgYWRvcHRpb24gY2FsbA0KDQoNCj4gT24gTWF5IDYs IDIwMTYsIGF0IDEwOjE2IFBNLCBVbWEgQ2h1bmR1cmkgPHVtYS5jaHVuZHVyaUBlcmljc3Nvbi5j b20+IHdyb3RlOg0KPiANCj4gTGVzLA0KPiAgDQo+IDIgcXVpY2sgdGhpbmdzLg0KPiAgDQo+IDEu ICAgICAgICANCj4gICAgICAgICAgICAgPltMZXM6XSBUaGVyZSBhcmUgdHdvIGxlZ2l0aW1hdGUg dXNlIGNhc2VzIGZvciBTUk1TOg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgPjEpVG8gYWR2ZXJ0aXNlIFNJRHMgZm9yIG5vbi1TUiBjYXBhYmxlIG5vZGVzDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA+MilBcyBhIGdsb2Jh bCBwcm92aXNpb25pbmcgdG9vbA0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgSSBhbSBoZWFy aW5nICMyIGZvciB0aGUgZmlyc3QgdGltZS4gSSBkb27igJl0IHNlZSB0aGlzIGVpdGhlciAgZGlz Y3Vzc2VkIGVhcmxpZXIgaW4gdGhlIFdHIGxpc3QgIG9yIGNhcHR1cmVkIGluIGFyY2hpdGVjdHVy ZSBkb2N1bWVudCANCj4gICAgICAgICAgICAgICAgICAgICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctMDcuIEV2ZW4gaW4g dGhlIHByb3RvY29sIGV4dGVuc2lvbnMgZG9jdW1lbnQgZm9yIGV4YW1wbGUgDQo+ICAgICAgICAg ICAgICAgICAgICAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1p c2lzLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25zLTA2I3NlY3Rpb24tMi40IHdlIGFsd2F5cyBk aXNjdXNzZWQgdGhpcyBmcm9tIG5vbi1TUiANCj4gICAgICAgICAgICAgICAgICAgICAgICAgIGNh cGFibGUgbm9kZXMgUG9WLiBTbyBJIHJlcXVlc3QgdG8gYWRkIHRoaXMgaW4gYXJjaGl0ZWN0dXJl IGRvY3VtZW50IGJlZm9yZSBmYWN0b3JpbmcgdGhpcyBmb3Igc29sdXRpb24gaW4gY29uZmxpY3Qg cmVzb2x1dGlvbi4gDQoNCg0KdXNpbmcgYSBTUk1TIGZvciBhZHZlcnRpc2luZyBTSUQgb24gYmVo YWxmIG9mIFNSIGNhcGFibGUgbm9kZXMgZG9lcyBub3QgaW50cm9kdWNlIGFueSBjaGFuZ2UgaW4g dGhlIFNSIGFyY2hpdGVjdHVyZSBzbyBub3Qgc3VyZSB3aGF0IHdlIG5lZWQgdG8gZG9jdW1lbnQg aGVyZS4NCg0KDQogICAgICAgICAgICAgICAgICAgICAgIA0KPiANCj4gMi4gICAgICAgQWxzbyB0 aGlzIGlzIHRoZSBmaXJzdCB0aW1lIGV2ZXIgd2UgaGF2ZSBhIHJlcXVpcmVtZW50IGZvciBjcm9z cyBwcm90b2NvbHMgdmVyaWZpY2F0aW9uIHdlIG91Z2h0IHRvIGRpc2N1c3MgdGhlIGltcGxpY2F0 aW9ucyBvZiB0aGlzICANCj4gYW5kIHByb3RvY29scyBpbnZvbHZlZCAod2l0aCBpbiBBUyBvciBv dGhlcndpc2UpIGluIHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgKGF0IGxlYXN0IGJyaWVmbHkp Lg0KDQoNCnRoZSBhcmNoaXRlY3R1cmUgZHJhZnQgaXMgZGF0YS1wYW5lIGFnbm9zdGljIHNvIEkg cHJlc3VtZSB5b3UgcmVmZXIgdG8gZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1w bHMuDQoNCndpdGggdGhlIGlwdjYgZGF0YS1wbGFuZSBTUiBjb25mbGljdHMgYXJlIGluIGZhY3Qg c29sdmVkIGJ5IGlwdjYgYWRkcmVzc2luZyB0ZWNobmlxdWVzIDstKQ0KDQpzLg0KDQoNCj4gIA0K PiAtLQ0KPiBVbWEgQy4NCj4gIA0KPiBGcm9tOiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExlcyANCj4gR2luc2JlcmcgKGdpbnNiZXJnKQ0KPiBT ZW50OiBXZWRuZXNkYXksIE1heSAwNCwgMjAxNiA5OjM4IEFNDQo+IFRvOiBVbWEgQ2h1bmR1cmk7 IGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb207IHNwcmluZ0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBS ZTogW3NwcmluZ10gZHJhZnQtZ2luc2Jlcmctc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24gLSBX RyANCj4gYWRvcHRpb24gY2FsbA0KPiAgDQo+IFVtYSDigJMNCj4gIA0KPiBUbyByZXN0YXRlLCB0 aGUgcHJvYmxlbSBiZWluZyBhZGRyZXNzZWQgaGVyZSBpcyB0byBndWFyYW50ZWUgY29uc2lzdGVu dCB1c2Ugb2YgU0lEcyBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZSBuZXR3b3JrLXdpZGUgaW4gdGhl IHByZXNlbmNlIG9mIGNvbmZsaWN0aW5nIGFkdmVydGlzZW1lbnRzLiBUaGUgc2V0IG9mIGFkdmVy dGlzZW1lbnRzIGluY2x1ZGVzIGJvdGggU0lEcyBhZHZlcnRpc2VkIGluIHByb3RvY29sIHByZWZp eCByZWFjaGFiaWxpdHkgYWR2ZXJ0aXNlbWVudHMgYW5kIFNSTVMgYWR2ZXJ0aXNlbWVudHMgYmVj YXVzZSBwcm9ibGVtcyBvY2N1ciBiYXNlZCB1cG9uIGluY29uc2lzdGVuY2llcyBpbiB3aGF0IGlz IGluc3RhbGxlZCBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZSBvZiBkaWZmZXJlbnQgcm91dGVycy4g SXQgbWF0dGVycyBub3Qgd2hldGhlciBSb3V0ZXIgQSB1c2VkIGEgU0lEIGFkdmVydGlzZWQgYnkg YSBwcm90b2NvbCBwcmVmaXggcmVhY2hhYmlsaXR5IGFkdmVydGlzZW1lbnQgb3IgYnkgYW4gU1JN UyBhZHZlcnRpc2VtZW50IOKAkyB3aGF0IG1hdHRlciBpcyB3aGV0aGVyIHRoZSBTSUQgdXNlZCBp cyBjb25zaXN0ZW50IHdpdGggd2hhdCB0aGUgbmVpZ2hib3JzIG9mIFJvdXRlciBBIHVzZS4gU28g c2ltcGx5IGVuc3VyaW5nIHRoYXQgT1NQRiAoZm9yIGV4YW1wbGUpIHJlc29sdmVzIFNJRHMgaW4g YSBjb25zaXN0ZW50IHdheSBkb2VzIG5vdCBmdWxseSBhZGRyZXNzIHRoZSBwcm9ibGVtIHNwYWNl Lg0KPiAgDQo+IE1vcmUgaW5saW5lLg0KPiAgDQo+IEZyb206IFVtYSBDaHVuZHVyaSBbbWFpbHRv OnVtYS5jaHVuZHVyaUBlcmljc3Nvbi5jb21dDQo+IFNlbnQ6IFR1ZXNkYXksIE1heSAwMywgMjAx NiAzOjU5IFBNDQo+IFRvOiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKTsgYnJ1bm8uZGVjcmFlbmVA b3JhbmdlLmNvbTsgDQo+IHNwcmluZ0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW3NwcmluZ10g ZHJhZnQtZ2luc2Jlcmctc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24gLSBXRyANCj4gYWRvcHRp b24gY2FsbA0KPiAgDQo+IExlcywNCj4gIA0KPiBXaXRoIGFsbCBkdWUgcmVzcGVjdHMsIGNyb3Nz IHByb3RvY29sIHZlcmlmaWNhdGlvbiAgb2YgcHJlZml4IGFuZCBTSUQgY29uZmxpY3RzIGFzIGFu IOKAnGFyY2hpdGVjdHVyYWwgY2hhbmdl4oCdICBhbmQgaXQgY2FuIHNldmVyZWx5IGltcGFjdCB0 aGUgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIChhdCBsZWFzdCB0aGUgb25lIEkgd29yayBvbiku IA0KPiAgDQo+IFtMZXM6XSBJdCBpcyBxdWl0ZSBjb3JyZWN0IOKAkyBhbmQgSSBjYW4gY29uZmly bSBiYXNlZCBvbiBwZXJzb25hbCBleHBlcmllbmNlIOKAkyB0aGF0IHN1cHBvcnQgZm9yIGNvbmZs aWN0IHJlc29sdXRpb24gaXMgYSBzaWduaWZpY2FudCBlZmZvcnQuDQo+ICANCj4gQWxzbyBJIGhh dmUgY291cGxlIG9mIGNhc2VzIHdoZXJlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgZHJhZnQgaXMg bm90IGNsZWFyIGFib3V0IHJlc29sdXRpb24uDQo+ICANCj4gSU1PLCBmaXJzdCB3ZSBuZWVkIGNs YXJpdHkgd2l0aCBpbiBhIHByb3RvY29sIGluc3RhbmNlIHJlc29sdXRpb24gcnVsZXMgYmVmb3Jl IGdvaW5nIHRvIHJlc29sdmUgdGhlIHNhbWUgYWNyb3NzIHByb3RvY29scyAoSSBtZW50aW9uZWQg ZmV3IGNhc2VzIGJlbG93KSAuDQo+IFNlcGFyYXRpb24gb2YgcmVhY2hhYmlsaXR5IGFkdmVydGlz ZW1lbnRzIGFuZCBTUk1TIHdvdWxkIGhlbHAg4oCcY3Jvc3MgcHJvdG9jb2zigJ0gdmVyaWZpY2F0 aW9uIG9mIHRoZSByYW5nZXMgYW5kIFNSTVMgaXMgbm90IGFwcGxpY2FibGUgdG8gYWxsIHByb3Rv Y29scy4NCj4gIA0KPiAgDQo+IEluLWxpbmUgW1VtYV06DQo+ICANCj4gLS0NCj4gVW1hIEMuDQo+ ICANCj4gRnJvbTogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgW21haWx0bzpnaW5zYmVyZ0BjaXNj by5jb21dDQo+IFNlbnQ6IFNhdHVyZGF5LCBBcHJpbCAzMCwgMjAxNiAxMDoxMSBQTQ0KPiBUbzog VW1hIENodW5kdXJpOyBicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tOyBzcHJpbmdAaWV0Zi5vcmcN Cj4gU3ViamVjdDogUkU6IFtzcHJpbmddIGRyYWZ0LWdpbnNiZXJnLXNwcmluZy1jb25mbGljdC1y ZXNvbHV0aW9uIC0gV0cgDQo+IGFkb3B0aW9uIGNhbGwNCj4gIA0KPiBVbWEg4oCTDQo+ICANCj4g V2UgYXJlIGluZGVlZCBkZWZpbmluZyBjb25mbGljdCByZXNvbHV0aW9uIGFjcm9zcyBhbGwgdGhl IFNJRCANCj4gYWR2ZXJ0aXNlbWVudHMgcmVnYXJkbGVzcyBvZiBzb3VyY2UgKHByb3RvY29sIG9y IFNSTVMpIOKAkw0KPiAgDQo+IFtVbWFdOiBXaGlsZSB5b3UgY2FuIHRoZW9yZXRpY2FsbHkgZG8g YW55dGhpbmcgZm9yIGN1cnJlbnQgaW1wbGVtZW50YXRpb24gdGhpcyBraW5kIG9mIGNyb3NzIHBy b3RvY29sIHZlcmlmaWNhdGlvbiBpcyBhIG5ldyBhcmNoaXRlY3R1cmFsIHJlcXVpcmVtZW50LiAg DQo+ICAgICAgICAgICAgICAgIEJlY2F1c2UgaXQgc2VlbXMg4oCcYSBjZW50cmFsIGVudGl0eeKA nSBuZWVkIHRvIGdhdGhlciBhbGwgZGlmZmVyZW50IHByb3RvY29sIGluc3RhbmNlcyBTUk1TIGFk dmVydGlzZW1lbnRzIGFuZCBzaG91bGQgc2V0dGxlIHdpdGggcmVzb2x1dGlvbi4gDQo+ICANCj4g LSAgICAgICAgICBBbHNvIG5vdGUgU1JNUyBpcyBub3QgYXBwbGljYWJsZSBmb3IgQkdQIGJ1dCBp dCBzZWVtcyBhbGwgcHJlZml4IFNJRHMgbmVlZCB0byBiZSB2ZXJpZmllZCAgd2l0aCBJR1AgaW5z dGFuY2VzIFNSTVMgYWR2ZXJ0aXNlbWVudHMuIElzIHRoaXMgdHJ1ZT8gV2hpbGUgdGhlIGRvY3Vt ZW50IG1vc3RseSB0YWxrcyBhYm91dCB0aGVzZSBhbmQgY29tcGFyZXMgd2l0aCBwcmVmaXggYWR2 ZXJ0aXNlbWVudC4NCj4gW0xlczpdIFRoZSBpc3N1ZSBpcyBwcm90b2NvbCBhZ25vc3RpYy4NCj4g IA0KPiAtICAgICAgICAgIEFsZ29yaXRobSBwcm9wb3NlZCBuZWVkcyBtb3JlIGNsYXJpdHk6IFRh a2UgU2VjdGlvbiAzLjIuNA0KPiAgDQo+IG8gICAgDQo+ICAgICAgICAgICAgICAgICAgICAgICDi gJwgICAxLiAgU21hbGxlciByYW5nZSB3aW5zDQo+ICANCj4gICAgICAgICAgICAgIDIuICBJUHY2 IGVudHJ5IHdpbnMgb3ZlciBJUHY0IGVudHJ5DQo+ICAgICAgICAgICAgICDigKYNCj4gICAgICAg ICDigJwNCj4gICAgICAgICAgICAgICAgICBXaGF0IGhhcHBlbnMgaW4gY2FzZSBvZiBwcmVmaXgg Y29uZmxpY3Qgb3IgU0lEIGNvbmZsaWN0IHdpdGggb25seSBwcmVmaXggYWR2ZXJ0aXNlbWVudHMg KHJhbmdlIDEpLiAgU2F5IG11bHRpcGxlIHByZWZpeGVzIGhhdmUgc2FtZSBTSUQgaW4gb25lIHBy b3RvY29sIGluc3RhbmNlIGFuZCBpbiBkaWZmZXJlbnQgcHJvdG9jb2xzLg0KPiAgICAgICAgICAg ICAgICAgIEkgc2VlIDIgbGV2ZWxzIG9mIHJlc29sdXRpb24gcmVxdWlyZWQgdml6Liwgb25lIGF0 IHdpdGhpbiB0aGUgcHJvdG9jb2wgYW5kIG9uZSBhbW9uZyB0aGUgcHJvdG9jb2xzLiAgTm8gZGlz Y3Vzc2lvbiBvbiB0aGlzLg0KPiAgDQo+IFtMZXM6XSBUaGUgZnVsbCBzZXQgb2YgcnVsZXMgc3Bl Y2lmaWVkIGluIHRoZSBkcmFmdCBwcm92aWRlIGRldGVybWluaXN0aWMgcmVzb2x1dGlvbiBpbiBh bGwgY2FzZXMuIFlvdSBoYXZlIHNuaXBwZWQgb25seSB0aGUgZmlyc3QgdHdvIHJ1bGVzLiBJZiBh IHByZWZlcmVuY2UgaXMgbm90IG9idGFpbmVkIGJhc2VkIG9uIHRoZSBmaXJzdCB0d28gcnVsZXMg eW91IGNvbnRpbnVlIG9uIHRvIHJ1bGUgIzMsIHRoZW4gcnVsZSAjNCwgZXRjLg0KPiAgDQo+ICAg ICAgICAgICAgICAgICAgU2ltaWxhcmx5IGluIGNhc2Ugb2YgU0lEIGNvbmZsaWN0ICAocmFuZ2Ug MSksIGl04oCZcyBub3Qgc3BlY2lmaWVkIHdoaWNoIHByb3RvY29s4oCZcyBTSUQgbmVlZCB0byBi ZSBjb25zaWRlcmVkLiAgQXJlIHlvdSBhc3N1bWluZyBzb21lIHNvcnQgb2YgQWRtaW4gZGlzdGFu Y2UgcGxheSBhIHJvbGUgaW4gcmVzb2x1dGlvbj8gDQo+IFtMZXM6XSBObyDigJMgYWRtaW4gZGlz dGFuY2UgcGxheXMgbm8gcm9sZSBoZXJlLg0KPiAgDQo+ICBJIGRvbuKAmXQgc2VlIGFueSBkaXNj dXNzaW9uIGluIHRoZSBkb2N1bWVudCAgYW5kIG5lZWRzIG1vcmUgY2xhcml0eSB0aGVyZSB0b28u DQo+IG8gICBBbHNvIHdoYXQgaGFwcGVucyBpZiBhIHByZWZpeCBvciBTSUQgY29uZmxpY3QgaGFw cGVucyB3aXRoIFNSTVMgcmFuZ2UgMSBhbmQgYSBwcmVmaXggIGFkdmVydGlzZW1lbnQgKDIgY2Fz ZXMpDQo+IGEuICAgICAgIG9mIG9uZSBwcm90b2NvbCBhbmQNCj4gYi4gICAgICBtdWx0aXBsZSBw cm90b2NvbHM/DQo+ICANCj4gW0xlczpdIFRoZSBzb3VyY2Ugb2YgdGhlIFNJRCBhZHZlcnRpc2Vt ZW50ICh3aGF0IHByb3RvY29sL3Byb3RvY29sIGluc3RhbmNlIG9yIHdoZXRoZXIgaXQgaXMgU1JN UyBiYXNlZCkgcGxheXMgbm8gcm9sZS4gVGhlIHRpZSBicmVha2VyIHJ1bGVzIGFzIGRlZmluZWQg YXJlIGNvbXBsZXRlIGFuZCBwcm92aWRlIGEgZGV0ZXJtaW5pc3RpYyBhbnN3ZXIgaW4gYWxsIGNh c2VzLg0KPiBJZiB5b3UgYmVsaWV2ZSB0aGF0IGlzIG5vdCB0cnVlIHBsZWFzZSBwcm92aWRlIGEg c3BlY2lmaWMgZXhhbXBsZSB3aGVyZSB5b3UgYXBwbHkgYWxsIHRoZSBydWxlcyBpbiB0aGUgb3Jk ZXIgc3BlY2lmaWVkIGFuZCBzdGlsbCBkbyBub3QgZGV0ZXJtaW5lIHRoZSBwcmVmZXJyZWQgZW50 cnkuDQo+ICANCj4gIA0KPiAtICAgICAgICAgIE9uIHRoZSBiZWxvdyBhc3N1bXB0aW9uOiAoU2Vj dGlvbiAzLjIuNCkNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDi gJxUaGlzIGhhcyB0aGUgbmljZSBwcm9wZXJ0eSB0aGF0IGEgc2luZ2xlIG1pc2NvbmZpZ3VyYXRv aW9uIG9mIGFuIFNSTVMNCj4gICAgICAgICAgICAgICAgICBlbnRyeSB3aXRoIGEgbGFyZ2UgcmFu Z2Ugd2lsbCBub3QgYmUgcHJlZmVycmVkIG92ZXIgYSBsYXJnZSBudW1iZXIgb2YNCj4gICAgICAg ICAgICAgICAgICBTSURzIGFkdmVydGlzZWQgaW4gcHJlZml4IHJlYWNoYWJpbGl0eSBhZHZlcnRp c2VtZW50cy7igJ0NCj4gV2hpbGUgYW55dGhpbmcgY2FuIGhhcHBlbiBpbiB0aGVvcnksIEkgZm91 bmQgaXQgYml0IG9kZCB0byBzZWUgd2h5IFNSTVMgZW50cnkgaXMgYmVpbmcgYWR2ZXJ0aXNlZCBh bmQgZm9yIHRoZSBzYW1lIHByZWZpeCwgU0lEIGlzIGFsc28gYWR2ZXJ0aXNlZCB0aHJvdWdoIHJl YWNoYWJpbGl0eSBhZHZlcnRpc2VtZW50cz8gDQo+IFRoaXMgaXMgYWdhaW5zdCB0aGUgc3Bpcml0 IG9mIFNSTVMgYWR2ZXJ0aXNlbWVudCwgaXNu4oCZdCBpdD8gV2hpbGUgdGhpcyBjYW4gaGFwcGVu LCBpdCBzZWVtcyB3ZSBhcmUgY2xhaW1pbmcgcmVzb2x1dGlvbiBzb2x1dGlvbiBieSBmb2N1c2lu ZyBtb3JlIG9uICB0aGlzIGNhc2UgaW4gdGhlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgZG9jdW1l bnQuDQo+ICANCj4gW0xlczpdIFRoZXJlIGFyZSB0d28gbGVnaXRpbWF0ZSB1c2UgY2FzZXMgZm9y IFNSTVM6DQo+ICANCj4gMSlUbyBhZHZlcnRpc2UgU0lEcyBmb3Igbm9uLVNSIGNhcGFibGUgbm9k ZXMgMilBcyBhIGdsb2JhbCANCj4gcHJvdmlzaW9uaW5nIHRvb2wNCj4gIA0KPiBMZXTigJlzIGV4 YW1pbmUgdGhlIGZpcnN0IGNhc2UuIEkgaGF2ZSBhbiBMRFAgZW5hYmxlZCBuZXR3b3JrIGFuZCBJ IGJlZ2luIGludHJvZHVjaW5nIFNSIGNhcGFibGUgbm9kZXMuIEF0IGEgZ2l2ZW4gbW9tZW50IGlu IHRpbWUgUm91dGVyIEEgaXMgTk9UIFNSIGNhcGFibGUgYW5kIFNSTVMgYWR2ZXJ0aXNlbWVudHMg Y292ZXIgcHJlZml4IFNJRHMgZm9yIHRoZSBhZGRyZXNzZXMgYXNzb2NpYXRlZCB3aXRoIFJvdXRl ciBBLg0KPiBJIHRoZW4gdXBncmFkZSBSb3V0ZXIgQSB0byBiZWNvbWUgU1IgY2FwYWJsZS4gQmVj YXVzZSBJIHdhbnQgdG8gZG8g4oCcbWFrZS1iZWZvcmUtYnJlYWvigJ0gSSBkbyBub3QgaW1tZWRp YXRlbHkgcmVtb3ZlIHRoZSBTUk1TIGFkdmVydGlzZW1lbnRzIGNvdmVyaW5nIHRoZSBhZGRyZXNz ZXMgYXNzb2NpYXRlZCB3aXRoIFJvdXRlciBBLiBJIHVwZ3JhZGUgQSwgYWRkIGNvbmZpZ3VyYXRp b24gb2YgU0lEcyBsb2NhbGx5IG9uIFJvdXRlciBBLCBhbmQgdmVyaWZ5IHRoYXQgdGhlIGFkdmVy dGlzZW1lbnRzIG9yaWdpbmF0aW5nIGZyb20gcHJvdG9jb2xzIG9uIFJvdXRlciBBIGFyZSBjb3Jy ZWN0LiBJZiBhbiBpbmNvbnNpc3RlbmN5IGlzIGludHJvZHVjZWQgd2hlbiBjb25maWd1cmluZyB0 aGUgU0lEcyBvbiBSb3V0ZXIgQSB0aGVuIEkgd2lsbCBoYXZlIGFuIFNSTVMgYWR2ZXJ0aXNlbWVu dCBhbmQgYSBwcmVmaXgtcmVhY2hhYmlsaXR5IGFkdmVydGlzZW1lbnQgdGhhdCBjb25mbGljdC4g VW50aWwgdGhlIGNvbmZsaWN0IGlzIGNvcnJlY3RlZCB3ZSB1c2UgdGhlIGNvbmZsaWN0IHJlc29s dXRpb24gcnVsZXMgdG8gcHJvdmlkZSBkZXRlcm1pbmlzdGljIGZvcndhcmRpbmcgYmVoYXZpb3Iu DQo+ICANCj4gVGhpcyB0byBtZSBpcyBhIG5vcm1hbCBhbmQgZXhwZWN0ZWQgdXBncmFkZSBzY2Vu YXJpby4NCj4gIA0KPiAgDQo+IFRoaXMgaXMgb25lIG9mIHRoZSByZWFzb25zIG9mIG15IGZpcnN0 IGNvbW1lbnQgYmVsb3cuIFlvdSBnb3QgdG8gc2VwYXJhdGUgdGhlIHJlYWNoYWJpbGl0eSBhZHZl cnRpc2VtZW50cyBhbmQgU1JNUyBhZHZlcnRpc2VtZW50czsgYXMgaW4gcHJpbmNpcGxlIHRoZXNl IGFyZSBkZWZpbmVkIGZvciBkaWZmZXJlbnQgcHVycG9zZXMuIEkgZG9u4oCZdCBzZWUgd2UgIG5l ZWQgYWxnb3JpdGhtIHRvIHByZWZlciByZWFjaGFiaWxpdHkgYWR2ZXJ0aXNlbWVudCBvdmVyIFNS TVMgYWR2ZXJ0aXNlbWVudCAoaWYgd2UgZG9u4oCZdCBjb21wYXJlIHRoZXNlIDIgY2F0ZWdvcmll cykuDQo+ICANCj4gIA0KPiAgDQo+IFtMZXM6XSBJIGRpc2FncmVlIOKAkyBob3BlZnVsbHkgbXkg Y29tbWVudHMgaGF2ZSBoZWxwZWQgeW91IHRvIHVuZGVyc3RhbmQgd2h5Lg0KPiAgDQo+ICAgIExl cw0KPiAgDQo+ICANCj4gYXMgdGhlIHNlY3Rpb25zIHlvdSBoYXZlIHF1b3RlZCBjbGVhcmx5IHN0 YXRlLg0KPiAgDQo+IFdoeT8gQmVjYXVzZSB3ZSBuZWVkIGNvbnNpc3RlbnQgdXNlIG9mIFNJRHMg aW4gdGhlIGZvcndhcmRpbmcgcGxhbmUuIEZyb20gZm9yd2FyZGluZyBwZXJzcGVjdGl2ZSBpdCBt YXR0ZXJzIG5vdCB3aGV0aGVyIHRoZSBTSUQgd2FzIGFkdmVydGlzZWQgYnkgcHJvdG9jb2wgaW5z dGFuY2UgIzEgb3IgIzIgb3IgYnkgYW4gU1JNUy4gDQo+ICANCj4gV2hhdCBtYXR0ZXJzIGlzIHRo YXQgdGhlIFNJRCBJIHVzZSB0byBkZXRlcm1pbmUgd2hhdCBsYWJlbCBJIGluc3RhbGwgaW4gbXkg Zm9yd2FyZGluZyBwbGFuZSBpcyB0aGUgc2FtZSBTSUQgdGhhdCBteSBuZWlnaGJvcnMgd2lsbCB1 c2UuIE90aGVyd2lzZSBmb3J3YXJkaW5nIHdpbGwgYmUgYnJva2VuLg0KPiAgDQo+ICAgIExlcw0K PiAgDQo+ICANCj4gRnJvbTogc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBVbWEgDQo+IENodW5kdXJpDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwg MjcsIDIwMTYgNDozMSBQTQ0KPiBUbzogYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTsgc3ByaW5n QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBkcmFmdC1naW5zYmVyZy1zcHJpbmct Y29uZmxpY3QtcmVzb2x1dGlvbiAtIFdHIA0KPiBhZG9wdGlvbiBjYWxsDQo+ICANCj4gRGVhciBB dXRob3JzLA0KPiAgDQo+IEhhdmUgZmV3IGNvbW1lbnRzIG9uIHRoZSBkcmFmdDoNCj4gIA0KPiAx LiANCj4gICAgICAgICBBcyBJIGluZGljYXRlZCBkdXJpbmcgbWVldGluZyAtIEkgYW0gbm90IHN1 cmUgd2h5IHdlIGhhdmUgdG8gY2x1YiAgdmVyaWZpY2F0aW9uIG9mIFNJRHMgYWR2ZXJ0aXNlZCB0 aHJvdWdoIHJlZ3VsYXIgcHJvdG9jb2wgcmVhY2hhYmlsaXR5DQo+ICAgICAgICAgICAgICAgICBw cmVmaXhlcyBhbmQgdGhlIHJhbmdlcyBhZHZlcnRpc2VkIHRocm91Z2ggJ01hcHBpbmcgU2VydmVy JyAgKFNSTVMpLiBJIGRpZG4ndCBzZWUgYW55IGNvbXBlbGxpbmcgcmVhc29uIHRvIGRvIHRoaXMu DQo+ICAgICAgICAgICAgICAgICAgU0lEcyBhZHZlcnRpc2VkIHRocm91Z2ggcmVhY2hhYmlsaXR5 IHByZWZpeGVzIGRvZXNuJ3QgaGF2ZSByYW5nZXMgdW5saWtlIFNSTVMgYWR2ZXJ0aXNlbWVudHMu IA0KPiAgICAgICAgICAgICAgICAgIEFzIFNSTVMgYWR2ZXJ0aXNlbWVudHMgYXJlIHByaW1hcmls eSBmb3Igbm9kZXMgd2hpY2ggYXJlIG5vdCBTUiBjYXBhYmxlIGFuZCAgSSBmZWVsIHdlIHNob3Vs ZCBub3QgbWl4IHRoaXMgd2l0aCBub2RlcyB3aGljaCBhcmUgU1IgY2FwYWJsZS4NCj4gIA0KPiAg ICAgICAgIFRoaXMgaXNvbGF0aW9uIGhlbHBzIHJlc3RyaWN0aW5nIHRoZSByZXNvbHV0aW9uIHdv cmsgcHJpbWFyaWx5IGZvciBtdWx0aXBsZSBTUk1TIGVudHJpZXMgYWR2ZXJ0aXNlZCB0aHJvdWdo IG9uZSBub2RlIG9yIG11bHRpcGxlIG5vZGVzLg0KPiAgICAgICAgICAgICAgICAgU1JNUyBhZHZl cnRpc2VtZW50cyBhcmUgaW5kZWVkIGxpdHRsZSBiaXQgdW5pcXVlIGluIHRoYXQgeW91IGFyZSBh ZHZlcnRpc2luZyAiY29uZmlndXJhdGlvbiIgb24gYmVoYWxmIG9mIG5vZGUgWCBmcm9tIG5vZGUg WQ0KPiAgICAgICAgICAgICAgICAgd2l0aCByYW5nZXMgKGJvdGggcHJlZml4IHJhbmdlcyBhbmQg U0lEIHJhbmdlcykuDQo+ICANCj4gIA0KPiAyLiANCj4gICAgICAgICAgICAgICAgIFJlZ2FyZGlu ZyAgdGhlIHNjb3BlIG9mIGNvbmZsaWN0IHJlc29sdXRpb246DQo+ICANCj4gIA0KPiAgICAgICAg U2VjdGlvbiAxDQo+ICANCj4gICAgICAgICAgICAiICAgVGhlIHByb2JsZW0gdG8gYmUgYWRkcmVz c2VkIGlzIHByb3RvY29sIGluZGVwZW5kZW50IGkuZS4sIHNlZ21lbnQNCj4gICAgICAgICAgcmVs YXRlZCBhZHZlcnRpc2VtZW50cyBtYXkgYmUgb3JpZ2luYXRlZCBieSBtdWx0aXBsZSBub2RlcyB1 c2luZw0KPiAgICAgICAgICBkaWZmZXJlbnQgcHJvdG9jb2xzIGFuZCB5ZXQgdGhlIGNvbmZsaWN0 IHJlc29sdXRpb24gTVVTVCBiZSB0aGUgc2FtZQ0KPiAgICAgICAgICBvbiBhbGwgbm9kZXMgcmVn YXJkbGVzcyBvZiB0aGUgcHJvdG9jb2wgdXNlZCB0byB0cmFuc3BvcnQgdGhlDQo+ICAgICAgICAg IGFkdmVydGlzZW1lbnRzLiINCj4gIA0KPiAgICAgICAgIFNlY3Rpb24gMy4yLjgNCj4gICAgICAg ICAgICIgICBvICBJbiBjYXNlcyB3aGVyZSBtdWx0aXBsZSByb3V0aW5nIHByb3RvY29scyBhcmUg aW4gdXNlIG1hcHBpbmcNCj4gICAgICAgZW50cmllcyBhZHZlcnRpc2VkIGJ5IGFsbCByb3V0aW5n IHByb3RvY29scyBNVVNUIGJlIGluY2x1ZGVkLiINCj4gIA0KPiAgICAgICBUaGlzIHNvdW5kcyBs aWtlIHdlIGFyZSBzZWVraW5nIHRvIHJlc29sdmUgY29uZmxpY3RpbmcgZW50cmllcyBvdXRzaWRl IGFuZCBhY3Jvc3MgdGhlIHByb3RvY29scz8NCj4gICAgICAgRWFjaCBJR1AgaGFzIHNlcGFyYXRl IG1lY2hhbmlzbSBmb3IgYWR2ZXJ0aXNpbmcgbWFwcGluZyBlbnRyeSBhbmQgSSB0aGlzIGlzIG5v dCBjbGVhciB3aXRoIHRoZSBjdXJyZW50IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGhvdyB3ZSBjYW4g Y3Jvc3MgdmVyaWZ5IFNJRC9QcmVmaXggY29uZmxpY3QgYWNyb3NzICB0aGUgcHJvdG9jb2wuDQo+ ICAgICAgQ2FuIHlvdSBjbGFyaWZ5IHRoaXM/DQo+ICANCj4gIA0KPiAtLQ0KPiBVbWEgQy4NCj4g IA0KPiAgDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNwcmluZyBbbWFp bHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgDQo+IGJydW5vLmRlY3Jh ZW5lQG9yYW5nZS5jb20NCj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDE0LCAyMDE2IDEyOjU1IEFN DQo+IFRvOiBzcHJpbmdAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzcHJpbmddIGRyYWZ0LWdp bnNiZXJnLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uIC0gV0cgDQo+IGFkb3B0aW9uIGNhbGwN Cj4gIA0KPiA+IEZyb206ICBicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tID4gU2VudDogVGh1cnNk YXksIEFwcmlsIDE0LCAyMDE2IA0KPiA+IDk6NTEgQU0NCj4gPg0KPiA+IERlYXIgV0csDQo+ID4N Cj4gPiBBcyB3ZSBkaXNjdXNzZWQgYXQgb3VyIG1lZXRpbmcgbGFzdCB3ZWVrLCB3b3JraW5nIGdy b3VwIGFkb3B0aW9uIGhhcyANCj4gPiBiZWVuIHJlcXVlc3RlZCBmb3IgZHJhZnQtZ2luc2Jlcmct c3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24uDQo+ID4gUGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0 IHdpdGggeW91ciBjb21tZW50cywgaW5jbHVkaW5nIGFsdGhvdWdoIG5vdCANCj4gPiBsaW1pdGVk IHRvIHdoZXRoZXIgb3Igbm90IHlvdSBzdXBwb3J0IGFkb3B0aW9uLg0KPiAgDQo+IFdlIHdpbGwg ZW5kIHRoZSBjYWxsIG9uIEFwcmlsIDI5LCAyMDE2Lg0KPiAgDQo+ICANCj4gPiBUaGFua3MsDQo+ ID4NCj4gPiAtLUpvaG4gYW5kIEJydW5vDQo+ID4NCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g PiBfX19fXw0KPiA+DQo+ID4gQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVu dCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIA0KPiA+IGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIA0KPiA+IGRpZmZ1c2VzLCBleHBs b2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSANCj4g PiBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0 ZXVyIGV0IGxlIA0KPiA+IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExl cyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIA0KPiA+IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVy YXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2Ug YSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4gPg0KPiA+IFRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciAN Cj4gPiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7 IHRoZXkgc2hvdWxkIG5vdCANCj4gPiBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0 aG91dCBhdXRob3Jpc2F0aW9uLg0KPiA+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciANCj4gPiBhbmQgZGVsZXRlIHRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiA+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJl ZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgDQo+ID4gaGF2ZSBiZWVu IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gPiBUaGFuayB5b3UuDQo+ID4NCj4g PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IHNw cmluZyBtYWlsaW5nIGxpc3QNCj4gPiBzcHJpbmdAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KPiAgDQo+IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAN Cj4gQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg aW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu dCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jp c2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6 IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMg cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRp YmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNp IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4g IA0KPiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg bGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhv dXQgYXV0aG9yaXNhdGlvbi4NCj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMuDQo+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4NCj4gVGhhbmsgeW91Lg0KPiAgDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNwcmluZyBtYWlsaW5nIGxpc3QNCj4gc3By aW5nQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3By aW5nDQo+ICANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gc3ByaW5nIG1haWxpbmcgbGlzdA0KPiBzcHJpbmdAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg0K From nobody Thu May 12 11:02:58 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC0212D508 for ; Thu, 12 May 2016 11:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yh6BbfdR7kR3 for ; Thu, 12 May 2016 11:02:53 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 107BF12D4FE for ; Thu, 12 May 2016 11:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17054; q=dns/txt; s=iport; t=1463076173; x=1464285773; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=NpoDATWeqpjNozdOjogtgTEdNENYil8t2QX71JeBylo=; b=HCtl0NjBRMGj26GVxGAg6Eq1IunFdve9l1yCfyuESnTxwiR2G2Li9qqE TiaHeSTwFhNlo3MLM+Hiq/IeO9QD5miOiuTdClsc4shrI70XRUTzUxolM wlmJBYPo1Jgz3g+XlLEEo4ZXgnkmE9GV8U3Eui66m4AGwfM9BGEtVDHzM s=; X-IronPort-AV: E=Sophos;i="5.24,610,1454976000"; d="scan'208";a="634595073" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 May 2016 18:02:51 +0000 Received: from [10.60.140.52] (ams-ppsenak-nitro3.cisco.com [10.60.140.52]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u4CI2oBl031066; Thu, 12 May 2016 18:02:50 GMT Message-ID: <5734C54A.2050102@cisco.com> Date: Thu, 12 May 2016 20:02:50 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Uma Chunduri , "Stefano Previdi (sprevidi)" References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10411_1460620508_570F4CDC_10411_96_23_53C29892C857584299CBF5D05346208A0F86E45F@OPEXCLILM21.corporate.adroot.infra.ftgroup> <1B502206DFA0C544B7A6046915200863580C54E9@eusaamb105.ericsson.se> <0468fb2fe35841668bc35606e988074c@XCH-ALN-001.cisco.com> <1B502206DFA0C544B7A60469152008635BCD31AB@eusaamb106.ericsson.se> <445eeb6f8f12480f90e941a81eeaafc7@XCH-ALN-001.cisco.com> <1B502206DFA0C544B7A60469152008635BCDFEFB@eusaamb106.ericsson.se> <1B502206DFA0C544B7A60469152008635BCE586E@eusaamb106.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008635BCE586E@eusaamb106.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Les Ginsberg \(ginsberg\)" , "spring@ietf.org" , "bruno.decraene@orange.com" Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 18:02:57 -0000 Hi Uma, On 5/12/16 19:49 , Uma Chunduri wrote: > Stefano, > > Thanks for your response. > > > using a SRMS for advertising SID on behalf of SR capable nodes does not introduce any change in the SR architecture so not > > sure what we need to document here. > > My point below: We are creating a conflict resolution solution for a non-existing requirement of using SRMS viz., ">2)As a global provisioning tool". > From your statement above, it seems you have less interest to make this as a requirement/scope of SRMS; I am more aligned in that path.... as a matter of fact, SRMS is a SID provisioning tool, whether you like it or not. It provides all the functionality that is required for such provisioning tool. You can not restrict its usage to SR/LDP interop case. thanks, Peter > > On the second point: > > > the architecture draft is data-pane agnostic so I presume you refer to draft-ietf-spring-segment-routing-mpls. > > AFAIS, https://tools.ietf.org/html/draft-ietf-spring-segment-routing-08 talks about both data planes right from abstract to multiple places (which it ought to). > I leave this to you/WG on where you want to document this -but IMO conflict resolution "solution document" in the current form potentially introducing fundamental > requirements to the system like cross protocol verification (with in/across AS). Perhaps some discussion should be there in data plane document then. > > -- > Uma C. > > > -----Original Message----- > From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] > Sent: Wednesday, May 11, 2016 4:46 AM > To: Uma Chunduri > Cc: Les Ginsberg (ginsberg); bruno.decraene@orange.com; spring@ietf.org > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call > > >> On May 6, 2016, at 10:16 PM, Uma Chunduri wrote: >> >> Les, >> >> 2 quick things. >> >> 1. >> >[Les:] There are two legitimate use cases for SRMS: >> >1)To advertise SIDs for non-SR capable nodes >> >2)As a global provisioning tool >> I am hearing #2 for the first time. I don’t see this either discussed earlier in the WG list or captured in architecture document >> https://tools.ietf.org/html/draft-ietf-spring-segment-routing-07. Even in the protocol extensions document for example >> https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-06#section-2.4 we always discussed this from non-SR >> capable nodes PoV. So I request to add this in architecture document before factoring this for solution in conflict resolution. > > > using a SRMS for advertising SID on behalf of SR capable nodes does not introduce any change in the SR architecture so not sure what we need to document here. > > > >> >> 2. Also this is the first time ever we have a requirement for cross protocols verification we ought to discuss the implications of this >> and protocols involved (with in AS or otherwise) in the architecture document (at least briefly). > > > the architecture draft is data-pane agnostic so I presume you refer to draft-ietf-spring-segment-routing-mpls. > > with the ipv6 data-plane SR conflicts are in fact solved by ipv6 addressing techniques ;-) > > s. > > >> >> -- >> Uma C. >> >> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les >> Ginsberg (ginsberg) >> Sent: Wednesday, May 04, 2016 9:38 AM >> To: Uma Chunduri; bruno.decraene@orange.com; spring@ietf.org >> Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG >> adoption call >> >> Uma – >> >> To restate, the problem being addressed here is to guarantee consistent use of SIDs in the forwarding plane network-wide in the presence of conflicting advertisements. The set of advertisements includes both SIDs advertised in protocol prefix reachability advertisements and SRMS advertisements because problems occur based upon inconsistencies in what is installed in the forwarding plane of different routers. It matters not whether Router A used a SID advertised by a protocol prefix reachability advertisement or by an SRMS advertisement – what matter is whether the SID used is consistent with what the neighbors of Router A use. So simply ensuring that OSPF (for example) resolves SIDs in a consistent way does not fully address the problem space. >> >> More inline. >> >> From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] >> Sent: Tuesday, May 03, 2016 3:59 PM >> To: Les Ginsberg (ginsberg); bruno.decraene@orange.com; >> spring@ietf.org >> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution - WG >> adoption call >> >> Les, >> >> With all due respects, cross protocol verification of prefix and SID conflicts as an “architectural change” and it can severely impact the existing implementations (at least the one I work on). >> >> [Les:] It is quite correct – and I can confirm based on personal experience – that support for conflict resolution is a significant effort. >> >> Also I have couple of cases where current version of the draft is not clear about resolution. >> >> IMO, first we need clarity with in a protocol instance resolution rules before going to resolve the same across protocols (I mentioned few cases below) . >> Separation of reachability advertisements and SRMS would help “cross protocol” verification of the ranges and SRMS is not applicable to all protocols. >> >> >> In-line [Uma]: >> >> -- >> Uma C. >> >> From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] >> Sent: Saturday, April 30, 2016 10:11 PM >> To: Uma Chunduri; bruno.decraene@orange.com; spring@ietf.org >> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution - WG >> adoption call >> >> Uma – >> >> We are indeed defining conflict resolution across all the SID >> advertisements regardless of source (protocol or SRMS) – >> >> [Uma]: While you can theoretically do anything for current implementation this kind of cross protocol verification is a new architectural requirement. >> Because it seems “a central entity” need to gather all different protocol instances SRMS advertisements and should settle with resolution. >> >> - Also note SRMS is not applicable for BGP but it seems all prefix SIDs need to be verified with IGP instances SRMS advertisements. Is this true? While the document mostly talks about these and compares with prefix advertisement. >> [Les:] The issue is protocol agnostic. >> >> - Algorithm proposed needs more clarity: Take Section 3.2.4 >> >> o >> “ 1. Smaller range wins >> >> 2. IPv6 entry wins over IPv4 entry >> … >> “ >> What happens in case of prefix conflict or SID conflict with only prefix advertisements (range 1). Say multiple prefixes have same SID in one protocol instance and in different protocols. >> I see 2 levels of resolution required viz., one at within the protocol and one among the protocols. No discussion on this. >> >> [Les:] The full set of rules specified in the draft provide deterministic resolution in all cases. You have snipped only the first two rules. If a preference is not obtained based on the first two rules you continue on to rule #3, then rule #4, etc. >> >> Similarly in case of SID conflict (range 1), it’s not specified which protocol’s SID need to be considered. Are you assuming some sort of Admin distance play a role in resolution? >> [Les:] No – admin distance plays no role here. >> >> I don’t see any discussion in the document and needs more clarity there too. >> o Also what happens if a prefix or SID conflict happens with SRMS range 1 and a prefix advertisement (2 cases) >> a. of one protocol and >> b. multiple protocols? >> >> [Les:] The source of the SID advertisement (what protocol/protocol instance or whether it is SRMS based) plays no role. The tie breaker rules as defined are complete and provide a deterministic answer in all cases. >> If you believe that is not true please provide a specific example where you apply all the rules in the order specified and still do not determine the preferred entry. >> >> >> - On the below assumption: (Section 3.2.4) >> “This has the nice property that a single misconfiguratoion of an SRMS >> entry with a large range will not be preferred over a large number of >> SIDs advertised in prefix reachability advertisements.” >> While anything can happen in theory, I found it bit odd to see why SRMS entry is being advertised and for the same prefix, SID is also advertised through reachability advertisements? >> This is against the spirit of SRMS advertisement, isn’t it? While this can happen, it seems we are claiming resolution solution by focusing more on this case in the current version of the document. >> >> [Les:] There are two legitimate use cases for SRMS: >> >> 1)To advertise SIDs for non-SR capable nodes 2)As a global >> provisioning tool >> >> Let’s examine the first case. I have an LDP enabled network and I begin introducing SR capable nodes. At a given moment in time Router A is NOT SR capable and SRMS advertisements cover prefix SIDs for the addresses associated with Router A. >> I then upgrade Router A to become SR capable. Because I want to do “make-before-break” I do not immediately remove the SRMS advertisements covering the addresses associated with Router A. I upgrade A, add configuration of SIDs locally on Router A, and verify that the advertisements originating from protocols on Router A are correct. If an inconsistency is introduced when configuring the SIDs on Router A then I will have an SRMS advertisement and a prefix-reachability advertisement that conflict. Until the conflict is corrected we use the conflict resolution rules to provide deterministic forwarding behavior. >> >> This to me is a normal and expected upgrade scenario. >> >> >> This is one of the reasons of my first comment below. You got to separate the reachability advertisements and SRMS advertisements; as in principle these are defined for different purposes. I don’t see we need algorithm to prefer reachability advertisement over SRMS advertisement (if we don’t compare these 2 categories). >> >> >> >> [Les:] I disagree – hopefully my comments have helped you to understand why. >> >> Les >> >> >> as the sections you have quoted clearly state. >> >> Why? Because we need consistent use of SIDs in the forwarding plane. From forwarding perspective it matters not whether the SID was advertised by protocol instance #1 or #2 or by an SRMS. >> >> What matters is that the SID I use to determine what label I install in my forwarding plane is the same SID that my neighbors will use. Otherwise forwarding will be broken. >> >> Les >> >> >> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Uma >> Chunduri >> Sent: Wednesday, April 27, 2016 4:31 PM >> To: bruno.decraene@orange.com; spring@ietf.org >> Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG >> adoption call >> >> Dear Authors, >> >> Have few comments on the draft: >> >> 1. >> As I indicated during meeting - I am not sure why we have to club verification of SIDs advertised through regular protocol reachability >> prefixes and the ranges advertised through 'Mapping Server' (SRMS). I didn't see any compelling reason to do this. >> SIDs advertised through reachability prefixes doesn't have ranges unlike SRMS advertisements. >> As SRMS advertisements are primarily for nodes which are not SR capable and I feel we should not mix this with nodes which are SR capable. >> >> This isolation helps restricting the resolution work primarily for multiple SRMS entries advertised through one node or multiple nodes. >> SRMS advertisements are indeed little bit unique in that you are advertising "configuration" on behalf of node X from node Y >> with ranges (both prefix ranges and SID ranges). >> >> >> 2. >> Regarding the scope of conflict resolution: >> >> >> Section 1 >> >> " The problem to be addressed is protocol independent i.e., segment >> related advertisements may be originated by multiple nodes using >> different protocols and yet the conflict resolution MUST be the same >> on all nodes regardless of the protocol used to transport the >> advertisements." >> >> Section 3.2.8 >> " o In cases where multiple routing protocols are in use mapping >> entries advertised by all routing protocols MUST be included." >> >> This sounds like we are seeking to resolve conflicting entries outside and across the protocols? >> Each IGP has separate mechanism for advertising mapping entry and I this is not clear with the current version of the draft how we can cross verify SID/Prefix conflict across the protocol. >> Can you clarify this? >> >> >> -- >> Uma C. >> >> >> -----Original Message----- >> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of >> bruno.decraene@orange.com >> Sent: Thursday, April 14, 2016 12:55 AM >> To: spring@ietf.org >> Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG >> adoption call >> >>> From: bruno.decraene@orange.com > Sent: Thursday, April 14, 2016 >>> 9:51 AM >>> >>> Dear WG, >>> >>> As we discussed at our meeting last week, working group adoption has >>> been requested for draft-ginsberg-spring-conflict-resolution. >>> Please reply to the list with your comments, including although not >>> limited to whether or not you support adoption. >> >> We will end the call on April 29, 2016. >> >> >>> Thanks, >>> >>> --John and Bruno >>> >>> >>> >>> __________________________________________________________ >>> __________________________________________________________ >>> _____ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre >>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>> ce message par erreur, veuillez le signaler a l'expediteur et le >>> detruire ainsi que les pieces jointes. Les messages electroniques >>> etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not >>> be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender >>> and delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that >>> have been modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> spring mailing list >>> spring@ietf.org >>> https://www.ietf.org/mailman/listinfo/spring >> >> ______________________________________________________________________ >> ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > From nobody Thu May 12 11:24:49 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E905312D538 for ; Thu, 12 May 2016 11:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pb6ZSD6vzKed for ; Thu, 12 May 2016 11:24:44 -0700 (PDT) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8142712D0F4 for ; Thu, 12 May 2016 11:19:35 -0700 (PDT) X-AuditID: c618062d-f79886d000002334-9a-5734c140655f Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usplmg20.ericsson.net (Symantec Mail Security) with SMTP id 22.4B.09012.041C4375; Thu, 12 May 2016 19:45:37 +0200 (CEST) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0248.002; Thu, 12 May 2016 14:19:34 -0400 From: Uma Chunduri To: Peter Psenak , "Stefano Previdi (sprevidi)" Thread-Topic: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call Thread-Index: AQHRpiTSIwvtcse5JkGIWGS+IKi0Mp+sWAzggAeUHQCAAa6/4IAATNoA//+9NsA= Date: Thu, 12 May 2016 18:19:33 +0000 Message-ID: <1B502206DFA0C544B7A60469152008635BCE58AB@eusaamb106.ericsson.se> References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10411_1460620508_570F4CDC_10411_96_23_53C29892C857584299CBF5D05346208A0F86E45F@OPEXCLILM21.corporate.adroot.infra.ftgroup> <1B502206DFA0C544B7A6046915200863580C54E9@eusaamb105.ericsson.se> <0468fb2fe35841668bc35606e988074c@XCH-ALN-001.cisco.com> <1B502206DFA0C544B7A60469152008635BCD31AB@eusaamb106.ericsson.se> <445eeb6f8f12480f90e941a81eeaafc7@XCH-ALN-001.cisco.com> <1B502206DFA0C544B7A60469152008635BCDFEFB@eusaamb106.ericsson.se> <1B502206DFA0C544B7A60469152008635BCE586E@eusaamb106.ericsson.se> <5734C54A.2050102@cisco.com> In-Reply-To: <5734C54A.2050102@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A60469152008635BCE58ABeusaamb106erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJIsWRmVeSWpSXmKPExsUyuXSPn67jQZNwgwc/2C1+7JjDbLHhz0Z2 ix2729ks1u9+xGRx/MJvRgdWjym/N7J6LFnyk8mj5dlJtgDmKC6blNSczLLUIn27BK6MRU3b mQu69rFUfGv6xtjAOGM9SxcjJ4eEgInEnqaDjBC2mMSFe+vZuhi5OIQEjjJKrHtyjwnCWc4o 8ePxcTaQKjYBPYmPU3+yg9giApESl4/uYAUpYhaYxCjx8NA3VpCEsECIxPOTXUDdHEBFoRLX l/tC1PtJXNt5jhnEZhFQlXiy9RQLSAmvgK/Erb3iELvusUrMW3WMCaSGU0BT4u/kZ2C7GIGu +35qDVicWUBc4taT+UwQVwtILNlznhnCFpV4+fgfK4StJDFp6TlWiPp8iYe7j4LdzysgKHFy 5hOWCYyis5CMmoWkbBaSsllA5zEDnbF+lz5EiaLElO6H7BC2hkTrnLnsyOILGNlXMXKUFhfk 5KYbGWxiBEbgMQk23R2M96d7HmIU4GBU4uFd8Ng4XIg1say4MvcQowQHs5II7+tdJuFCvCmJ lVWpRfnxRaU5qcWHGKU5WJTEecUeKYYLCaQnlqRmp6YWpBbBZJk4OKUaGOOF1SOCDc0vMZ+U ll1mYzXvztrnJ7mfTNf9ked3T+SotZvgy8+vHpzPyDedYLC5Kduw0y1Fd25nBNfaadwb299P nD7rvrrILJHPs+OfJ7z1ETbf/2+epH2cYblibiW7puf2yf97ZIMLU1wEbHZpa7i+8Npu3rPy WsssOcWaqU92BKnmbuy/q8RSnJFoqMVcVJwIAFdfleq8AgAA Archived-At: Cc: "Les Ginsberg \(ginsberg\)" , "spring@ietf.org" , "bruno.decraene@orange.com" Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 May 2016 18:24:48 -0000 --_000_1B502206DFA0C544B7A60469152008635BCE58ABeusaamb106erics_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGV0ZXIsDQoNCiAgICAgICAgPiBhcyBhIG1hdHRlciBvZiBmYWN0LCBTUk1TIGlzIGEgU0lEIHBy b3Zpc2lvbmluZyB0b29sLCB3aGV0aGVyIHlvdSBsaWtlIGl0IG9yIG5vdC4NCg0KSXQncyBub3Qg YWJvdXQgeW91ciBvciBteSBsaW5raW5nIC0gSSB3YXMgdGFsa2luZyBhYm91dCB3aGF0J3MgdGhl IGRlZmluZWQgc2NvcGUgc28gZmFyIChhcmNoaXRlY3R1cmUgZG9jIG9yIHByb3RvY29sIGRvY3Mp DQphbmQgaG93IHlvdSB3YW50IHRvIGV4dGVuZCB0aGUgc2NvcGUuDQpXZWxsLCBpZiB5b3Ugd2Fu dCB0byBleHRlbmQgdGhlIGN1cnJlbnQgc2NvcGUgb2YgU1JNUyBhcyBhICIiPjIpQXMgYSBnbG9i YWwgcHJvdmlzaW9uaW5nIHRvb2wiIC0NClBsei4gZG8gc28gYnV0IG5vdCB3aGlsZSBwcm92aWRp bmcgY29uZmxpY3QgcmVzb2x1dGlvbiBzb2x1dGlvbi4NCg0KDQogICAgICAgICAgICAgICA+IEl0 IHByb3ZpZGVzIGFsbCB0aGUgZnVuY3Rpb25hbGl0eSB0aGF0IGlzIHJlcXVpcmVkIGZvciBzdWNo IHByb3Zpc2lvbmluZyB0b29sLg0KICAgICAgICA+WW91IGNhbiBub3QgcmVzdHJpY3QgaXRzIHVz YWdlIHRvIFNSL0xEUCBpbnRlcm9wIGNhc2UuDQoNCkkgZGlkbid0IHJlc3RyaWN0IGFueXRoaW5n IC0gUGx6LiBzZWUgU1JNUyBzdHVmZiBzbyBmYXI6DQoNCjEuIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctMDgjc2VjdGlvbi0zLjYN CiAgICAgICAgIiAzLjYuMS4gIE1hcHBpbmcgU2VydmVyDQoNCiAgICAgICAgIEEgUmVtb3RlLUJp bmRpbmcgU0lEIFMgYWR2ZXJ0aXNlZCBieSB0aGUgbWFwcGluZyBzZXJ2ZXIgTSBmb3IgcmVtb3Rl DQogICAgICAgIHByZWZpeCBSIGF0dGFjaGVkIHRvIG5vbi1TUi1jYXBhYmxlIG5vZGUgTiBzaWdu YWxzIHRoZSBzYW1lDQogICAgICAgIGluZm9ybWF0aW9uIGFzIGlmIE4gaGFkIGFkdmVydGlzZWQg UyBhcyBhIFByZWZpeC1TSUQuICBGdXJ0aGVyDQogICAgICAgIGRldGFpbHMgYXJlIGRlc2NyaWJl ZCBpbiB0aGUgU1IvTERQIGludGVyd29ya2luZyBwcm9jZWR1cmVzDQogICAgICAgICAoW0ktRC5p ZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbGRwLWludGVyb3BdLiINCg0KDQoNCjIuIElTSVM6 IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1yb3V0 aW5nLWV4dGVuc2lvbnMtMDYjc2VjdGlvbi0yLjQNCiAgICAgICAgICAgICAgICAiIFRoaXMgZnVu Y3Rpb25hbGl0eSBpcyBjYWxsZWQgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAnTWFwcGlu ZyBTZXJ2ZXInIGFuZCBpdCdzIHVzZWQgd2hlbiwgaW4gYSBoZXRlcm9nZW5lb3VzIG5ldHdvcmss DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICBub3QgYWxsIG5vZGVzIGFyZSBjYXBhYmxl IG9mIGFkdmVydGlzaW5nIHRoZWlyIG93biBTSURzL0xhYmVscy4iDQoNCg0KMy4gT1NQRjogaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3NwZi1zZWdtZW50LXJvdXRpbmct ZXh0ZW5zaW9ucy0wOCNzZWN0aW9uLTQNCiAgICAgICAgICAgICAgICAiICAgSW4gc29tZSBjYXNl cyBpdCBpcyB1c2VmdWwgdG8gYWR2ZXJ0aXNlIGF0dHJpYnV0ZXMgZm9yIGEgcmFuZ2Ugb2YNCiAg ICAgICAgICAgICAgICBwcmVmaXhlcy4gIFRoZSBTZWdtZW50IFJvdXRpbmcgTWFwcGluZyBTZXJ2 ZXIsIHdoaWNoIGlzIGRlc2NyaWJlZCBpbg0KICAgICAgICAgICAgICAgIFtJLUQuZmlsc2ZpbHMt c3ByaW5nLXNlZ21lbnQtcm91dGluZy1sZHAtaW50ZXJvcDxodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi1vc3BmLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25zLTA4Pl0sIGlz IGFuIGV4YW1wbGUNCiAgICAgICAgICAgICAgICB3aGVyZSB3ZSBuZWVkIGEgc2luZ2xlIGFkdmVy dGlzZW1lbnQgdG8gYWR2ZXJ0aXNlIFNJRHMgZm9yIG11bHRpcGxlDQogICAgICAgICAgICAgICAg cHJlZml4ZXMgZnJvbSBhIGNvbnRpZ3VvdXMgYWRkcmVzcyByYW5nZS4iDQoNCkFnYWluLCBwbHou IGV4dGVuZCB0aGUgc2NvcGUgZmlyc3QgYW5kIGNvbnNpZGVyIHRoZSBzYW1lIGluIHJlc29sdXRp b24gc29sdXRpb24uIEkgYW0gZmluZSB3aXRoIGl0Lg0KDQoNCi0tDQpVbWEgQy4NCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUGV0ZXIgUHNlbmFrIFttYWlsdG86cHBzZW5h a0BjaXNjby5jb21dDQpTZW50OiBUaHVyc2RheSwgTWF5IDEyLCAyMDE2IDExOjAzIEFNDQpUbzog VW1hIENodW5kdXJpOyBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKQ0KQ2M6IExlcyBHaW5zYmVy ZyAoZ2luc2JlcmcpOyBzcHJpbmdAaWV0Zi5vcmc7IGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20N ClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBkcmFmdC1naW5zYmVyZy1zcHJpbmctY29uZmxpY3QtcmVz b2x1dGlvbiAtIFdHIGFkb3B0aW9uIGNhbGwNCg0KSGkgVW1hLA0KDQpPbiA1LzEyLzE2IDE5OjQ5 ICwgVW1hIENodW5kdXJpIHdyb3RlOg0KPiBTdGVmYW5vLA0KPg0KPiBUaGFua3MgZm9yIHlvdXIg cmVzcG9uc2UuDQo+DQo+ICAgICAgID4gdXNpbmcgYSBTUk1TIGZvciBhZHZlcnRpc2luZyBTSUQg b24gYmVoYWxmIG9mIFNSIGNhcGFibGUgbm9kZXMgZG9lcyBub3QgaW50cm9kdWNlIGFueSBjaGFu Z2UgaW4gdGhlIFNSIGFyY2hpdGVjdHVyZSBzbyBub3QNCj4gICAgICAgICAgICAgICAgID4gc3Vy ZSB3aGF0IHdlIG5lZWQgdG8gZG9jdW1lbnQgaGVyZS4NCj4NCj4gTXkgcG9pbnQgYmVsb3c6IFdl IGFyZSBjcmVhdGluZyBhIGNvbmZsaWN0IHJlc29sdXRpb24gc29sdXRpb24gZm9yIGEgbm9uLWV4 aXN0aW5nIHJlcXVpcmVtZW50IG9mIHVzaW5nICBTUk1TIHZpei4sICAiPjIpQXMgYSBnbG9iYWwg cHJvdmlzaW9uaW5nIHRvb2wiLg0KPiAgRnJvbSB5b3VyIHN0YXRlbWVudCBhYm92ZSwgaXQgc2Vl bXMgeW91IGhhdmUgbGVzcyBpbnRlcmVzdCB0byBtYWtlIHRoaXMgYXMgYSByZXF1aXJlbWVudC9z Y29wZSBvZiBTUk1TOyBJIGFtIG1vcmUgYWxpZ25lZCBpbiB0aGF0IHBhdGguLi4uDQoNCmFzIGEg bWF0dGVyIG9mIGZhY3QsIFNSTVMgaXMgYSBTSUQgcHJvdmlzaW9uaW5nIHRvb2wsIHdoZXRoZXIg eW91IGxpa2UgaXQgb3Igbm90LiBJdCBwcm92aWRlcyBhbGwgdGhlIGZ1bmN0aW9uYWxpdHkgdGhh dCBpcyByZXF1aXJlZCBmb3Igc3VjaCBwcm92aXNpb25pbmcgdG9vbC4gWW91IGNhbiBub3QgcmVz dHJpY3QgaXRzIHVzYWdlIHRvIFNSL0xEUCBpbnRlcm9wIGNhc2UuDQoNCnRoYW5rcywNClBldGVy DQoNCj4NCj4gT24gdGhlIHNlY29uZCBwb2ludDoNCj4NCj4gICAgICAgPiB0aGUgYXJjaGl0ZWN0 dXJlIGRyYWZ0IGlzIGRhdGEtcGFuZSBhZ25vc3RpYyBzbyBJIHByZXN1bWUgeW91IHJlZmVyIHRv IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLg0KPg0KPiBBRkFJUywgIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRp bmctMDggIHRhbGtzIGFib3V0IGJvdGggZGF0YSBwbGFuZXMgcmlnaHQgZnJvbSBhYnN0cmFjdCB0 byBtdWx0aXBsZSBwbGFjZXMgKHdoaWNoIGl0IG91Z2h0IHRvKS4NCj4gSSBsZWF2ZSB0aGlzIHRv IHlvdS9XRyBvbiB3aGVyZSB5b3Ugd2FudCB0byBkb2N1bWVudCB0aGlzIC1idXQgSU1PDQo+IGNv bmZsaWN0IHJlc29sdXRpb24gInNvbHV0aW9uIGRvY3VtZW50IiBpbiB0aGUgY3VycmVudCBmb3Jt IHBvdGVudGlhbGx5IGludHJvZHVjaW5nIGZ1bmRhbWVudGFsIHJlcXVpcmVtZW50cyAgdG8gdGhl IHN5c3RlbSBsaWtlIGNyb3NzIHByb3RvY29sIHZlcmlmaWNhdGlvbiAod2l0aCBpbi9hY3Jvc3Mg QVMpLiBQZXJoYXBzIHNvbWUgZGlzY3Vzc2lvbiBzaG91bGQgYmUgdGhlcmUgaW4gZGF0YSBwbGFu ZSBkb2N1bWVudCB0aGVuLg0KPg0KPiAtLQ0KPiBVbWEgQy4NCj4NCj4NCj4gLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkgW21haWx0 bzpzcHJldmlkaUBjaXNjby5jb21dDQo+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDExLCAyMDE2IDQ6 NDYgQU0NCj4gVG86IFVtYSBDaHVuZHVyaQ0KPiBDYzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZyk7 IGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5j b20+Ow0KPiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gU3ViamVj dDogUmU6IFtzcHJpbmddIGRyYWZ0LWdpbnNiZXJnLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9u IC0gV0cNCj4gYWRvcHRpb24gY2FsbA0KPg0KPg0KPj4gT24gTWF5IDYsIDIwMTYsIGF0IDEwOjE2 IFBNLCBVbWEgQ2h1bmR1cmkgPHVtYS5jaHVuZHVyaUBlcmljc3Nvbi5jb208bWFpbHRvOnVtYS5j aHVuZHVyaUBlcmljc3Nvbi5jb20+PiB3cm90ZToNCj4+DQo+PiBMZXMsDQo+Pg0KPj4gMiBxdWlj ayB0aGluZ3MuDQo+Pg0KPj4gMS4NCj4+ICAgICAgICAgICAgICA+W0xlczpdIFRoZXJlIGFyZSB0 d28gbGVnaXRpbWF0ZSB1c2UgY2FzZXMgZm9yIFNSTVM6DQo+PiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgID4xKVRvIGFkdmVydGlzZSBTSURzIGZvciBub24tU1Ig Y2FwYWJsZSBub2Rlcw0KPj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA+MilBcyBhIGdsb2JhbCBwcm92aXNpb25pbmcgdG9vbA0KPj4gICAgICAgICAgICAgICAg ICAgICAgICAgICBJIGFtIGhlYXJpbmcgIzIgZm9yIHRoZSBmaXJzdCB0aW1lLiBJIGRvbuKAmXQg c2VlIHRoaXMgZWl0aGVyICBkaXNjdXNzZWQgZWFybGllciBpbiB0aGUgV0cgbGlzdCAgb3IgY2Fw dHVyZWQgaW4gYXJjaGl0ZWN0dXJlIGRvY3VtZW50DQo+PiAgICAgICAgICAgICAgICAgICAgICAg ICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50 LXJvdXRpbmctMDcuIEV2ZW4gaW4gdGhlIHByb3RvY29sIGV4dGVuc2lvbnMgZG9jdW1lbnQgZm9y IGV4YW1wbGUNCj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtaXNpcy1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9ucy0wNiNz ZWN0aW9uLTIuNCB3ZSBhbHdheXMgZGlzY3Vzc2VkIHRoaXMgZnJvbSBub24tU1INCj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgY2FwYWJsZSBub2RlcyBQb1YuIFNvIEkgcmVxdWVzdCB0byBh ZGQgdGhpcyBpbiBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgYmVmb3JlIGZhY3RvcmluZyB0aGlzIGZv ciBzb2x1dGlvbiBpbiBjb25mbGljdCByZXNvbHV0aW9uLg0KPg0KPg0KPiB1c2luZyBhIFNSTVMg Zm9yIGFkdmVydGlzaW5nIFNJRCBvbiBiZWhhbGYgb2YgU1IgY2FwYWJsZSBub2RlcyBkb2VzIG5v dCBpbnRyb2R1Y2UgYW55IGNoYW5nZSBpbiB0aGUgU1IgYXJjaGl0ZWN0dXJlIHNvIG5vdCBzdXJl IHdoYXQgd2UgbmVlZCB0byBkb2N1bWVudCBoZXJlLg0KPg0KPg0KPg0KPj4NCj4+IDIuICAgICAg IEFsc28gdGhpcyBpcyB0aGUgZmlyc3QgdGltZSBldmVyIHdlIGhhdmUgYSByZXF1aXJlbWVudCBm b3IgY3Jvc3MgcHJvdG9jb2xzIHZlcmlmaWNhdGlvbiB3ZSBvdWdodCB0byBkaXNjdXNzIHRoZSBp bXBsaWNhdGlvbnMgb2YgdGhpcw0KPj4gYW5kIHByb3RvY29scyBpbnZvbHZlZCAod2l0aCBpbiBB UyBvciBvdGhlcndpc2UpIGluIHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgKGF0IGxlYXN0IGJy aWVmbHkpLg0KPg0KPg0KPiB0aGUgYXJjaGl0ZWN0dXJlIGRyYWZ0IGlzIGRhdGEtcGFuZSBhZ25v c3RpYyBzbyBJIHByZXN1bWUgeW91IHJlZmVyIHRvIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQt cm91dGluZy1tcGxzLg0KPg0KPiB3aXRoIHRoZSBpcHY2IGRhdGEtcGxhbmUgU1IgY29uZmxpY3Rz IGFyZSBpbiBmYWN0IHNvbHZlZCBieSBpcHY2DQo+IGFkZHJlc3NpbmcgdGVjaG5pcXVlcyA7LSkN Cj4NCj4gcy4NCj4NCj4NCj4+DQo+PiAtLQ0KPj4gVW1hIEMuDQo+Pg0KPj4gRnJvbTogc3ByaW5n IFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBMZXMNCj4+IEdp bnNiZXJnIChnaW5zYmVyZykNCj4+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDA0LCAyMDE2IDk6Mzgg QU0NCj4+IFRvOiBVbWEgQ2h1bmR1cmk7IGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208bWFpbHRv OmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+OyBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmlu Z0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBkcmFmdC1naW5zYmVyZy1zcHJp bmctY29uZmxpY3QtcmVzb2x1dGlvbiAtIFdHDQo+PiBhZG9wdGlvbiBjYWxsDQo+Pg0KPj4gVW1h IOKAkw0KPj4NCj4+IFRvIHJlc3RhdGUsIHRoZSBwcm9ibGVtIGJlaW5nIGFkZHJlc3NlZCBoZXJl IGlzIHRvIGd1YXJhbnRlZSBjb25zaXN0ZW50IHVzZSBvZiBTSURzIGluIHRoZSBmb3J3YXJkaW5n IHBsYW5lIG5ldHdvcmstd2lkZSBpbiB0aGUgcHJlc2VuY2Ugb2YgY29uZmxpY3RpbmcgYWR2ZXJ0 aXNlbWVudHMuIFRoZSBzZXQgb2YgYWR2ZXJ0aXNlbWVudHMgaW5jbHVkZXMgYm90aCBTSURzIGFk dmVydGlzZWQgaW4gcHJvdG9jb2wgcHJlZml4IHJlYWNoYWJpbGl0eSBhZHZlcnRpc2VtZW50cyBh bmQgU1JNUyBhZHZlcnRpc2VtZW50cyBiZWNhdXNlIHByb2JsZW1zIG9jY3VyIGJhc2VkIHVwb24g aW5jb25zaXN0ZW5jaWVzIGluIHdoYXQgaXMgaW5zdGFsbGVkIGluIHRoZSBmb3J3YXJkaW5nIHBs YW5lIG9mIGRpZmZlcmVudCByb3V0ZXJzLiBJdCBtYXR0ZXJzIG5vdCB3aGV0aGVyIFJvdXRlciBB IHVzZWQgYSBTSUQgYWR2ZXJ0aXNlZCBieSBhIHByb3RvY29sIHByZWZpeCByZWFjaGFiaWxpdHkg YWR2ZXJ0aXNlbWVudCBvciBieSBhbiBTUk1TIGFkdmVydGlzZW1lbnQg4oCTIHdoYXQgbWF0dGVy IGlzIHdoZXRoZXIgdGhlIFNJRCB1c2VkIGlzIGNvbnNpc3RlbnQgd2l0aCB3aGF0IHRoZSBuZWln aGJvcnMgb2YgUm91dGVyIEEgdXNlLiBTbyBzaW1wbHkgZW5zdXJpbmcgdGhhdCBPU1BGIChmb3Ig ZXhhbXBsZSkgcmVzb2x2ZXMgU0lEcyBpbiBhIGNvbnNpc3RlbnQgd2F5IGRvZXMgbm90IGZ1bGx5 IGFkZHJlc3MgdGhlIHByb2JsZW0gc3BhY2UuDQo+Pg0KPj4gTW9yZSBpbmxpbmUuDQo+Pg0KPj4g RnJvbTogVW1hIENodW5kdXJpIFttYWlsdG86dW1hLmNodW5kdXJpQGVyaWNzc29uLmNvbV0NCj4+ IFNlbnQ6IFR1ZXNkYXksIE1heSAwMywgMjAxNiAzOjU5IFBNDQo+PiBUbzogTGVzIEdpbnNiZXJn IChnaW5zYmVyZyk7IGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208bWFpbHRvOmJydW5vLmRlY3Jh ZW5lQG9yYW5nZS5jb20+Ow0KPj4gc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5v cmc+DQo+PiBTdWJqZWN0OiBSRTogW3NwcmluZ10gZHJhZnQtZ2luc2Jlcmctc3ByaW5nLWNvbmZs aWN0LXJlc29sdXRpb24gLSBXRw0KPj4gYWRvcHRpb24gY2FsbA0KPj4NCj4+IExlcywNCj4+DQo+ PiBXaXRoIGFsbCBkdWUgcmVzcGVjdHMsIGNyb3NzIHByb3RvY29sIHZlcmlmaWNhdGlvbiAgb2Yg cHJlZml4IGFuZCBTSUQgY29uZmxpY3RzIGFzIGFuIOKAnGFyY2hpdGVjdHVyYWwgY2hhbmdl4oCd ICBhbmQgaXQgY2FuIHNldmVyZWx5IGltcGFjdCB0aGUgZXhpc3RpbmcgaW1wbGVtZW50YXRpb25z IChhdCBsZWFzdCB0aGUgb25lIEkgd29yayBvbikuDQo+Pg0KPj4gW0xlczpdIEl0IGlzIHF1aXRl IGNvcnJlY3Qg4oCTIGFuZCBJIGNhbiBjb25maXJtIGJhc2VkIG9uIHBlcnNvbmFsIGV4cGVyaWVu Y2Ug4oCTIHRoYXQgc3VwcG9ydCBmb3IgY29uZmxpY3QgcmVzb2x1dGlvbiBpcyBhIHNpZ25pZmlj YW50IGVmZm9ydC4NCj4+DQo+PiBBbHNvIEkgaGF2ZSBjb3VwbGUgb2YgY2FzZXMgd2hlcmUgY3Vy cmVudCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBpcyBub3QgY2xlYXIgYWJvdXQgcmVzb2x1dGlvbi4N Cj4+DQo+PiBJTU8sIGZpcnN0IHdlIG5lZWQgY2xhcml0eSB3aXRoIGluIGEgcHJvdG9jb2wgaW5z dGFuY2UgcmVzb2x1dGlvbiBydWxlcyBiZWZvcmUgZ29pbmcgdG8gcmVzb2x2ZSB0aGUgc2FtZSBh Y3Jvc3MgcHJvdG9jb2xzIChJIG1lbnRpb25lZCBmZXcgY2FzZXMgYmVsb3cpIC4NCj4+IFNlcGFy YXRpb24gb2YgcmVhY2hhYmlsaXR5IGFkdmVydGlzZW1lbnRzIGFuZCBTUk1TIHdvdWxkIGhlbHAg 4oCcY3Jvc3MgcHJvdG9jb2zigJ0gdmVyaWZpY2F0aW9uIG9mIHRoZSByYW5nZXMgYW5kIFNSTVMg aXMgbm90IGFwcGxpY2FibGUgdG8gYWxsIHByb3RvY29scy4NCj4+DQo+Pg0KPj4gSW4tbGluZSBb VW1hXToNCj4+DQo+PiAtLQ0KPj4gVW1hIEMuDQo+Pg0KPj4gRnJvbTogTGVzIEdpbnNiZXJnIChn aW5zYmVyZykgW21haWx0bzpnaW5zYmVyZ0BjaXNjby5jb21dDQo+PiBTZW50OiBTYXR1cmRheSwg QXByaWwgMzAsIDIwMTYgMTA6MTEgUE0NCj4+IFRvOiBVbWEgQ2h1bmR1cmk7IGJydW5vLmRlY3Jh ZW5lQG9yYW5nZS5jb208bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+OyBzcHJpbmdA aWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4+IFN1YmplY3Q6IFJFOiBbc3ByaW5n XSBkcmFmdC1naW5zYmVyZy1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbiAtIFdHDQo+PiBhZG9w dGlvbiBjYWxsDQo+Pg0KPj4gVW1hIOKAkw0KPj4NCj4+IFdlIGFyZSBpbmRlZWQgZGVmaW5pbmcg Y29uZmxpY3QgcmVzb2x1dGlvbiBhY3Jvc3MgYWxsIHRoZSBTSUQNCj4+IGFkdmVydGlzZW1lbnRz IHJlZ2FyZGxlc3Mgb2Ygc291cmNlIChwcm90b2NvbCBvciBTUk1TKSDigJMNCj4+DQo+PiBbVW1h XTogV2hpbGUgeW91IGNhbiB0aGVvcmV0aWNhbGx5IGRvIGFueXRoaW5nIGZvciBjdXJyZW50IGlt cGxlbWVudGF0aW9uIHRoaXMga2luZCBvZiBjcm9zcyBwcm90b2NvbCB2ZXJpZmljYXRpb24gaXMg YSBuZXcgYXJjaGl0ZWN0dXJhbCByZXF1aXJlbWVudC4NCj4+ICAgICAgICAgICAgICAgICBCZWNh dXNlIGl0IHNlZW1zIOKAnGEgY2VudHJhbCBlbnRpdHnigJ0gbmVlZCB0byBnYXRoZXIgYWxsIGRp ZmZlcmVudCBwcm90b2NvbCBpbnN0YW5jZXMgU1JNUyBhZHZlcnRpc2VtZW50cyBhbmQgc2hvdWxk IHNldHRsZSB3aXRoIHJlc29sdXRpb24uDQo+Pg0KPj4gLSAgICAgICAgICBBbHNvIG5vdGUgU1JN UyBpcyBub3QgYXBwbGljYWJsZSBmb3IgQkdQIGJ1dCBpdCBzZWVtcyBhbGwgcHJlZml4IFNJRHMg bmVlZCB0byBiZSB2ZXJpZmllZCAgd2l0aCBJR1AgaW5zdGFuY2VzIFNSTVMgYWR2ZXJ0aXNlbWVu dHMuIElzIHRoaXMgdHJ1ZT8gV2hpbGUgdGhlIGRvY3VtZW50IG1vc3RseSB0YWxrcyBhYm91dCB0 aGVzZSBhbmQgY29tcGFyZXMgd2l0aCBwcmVmaXggYWR2ZXJ0aXNlbWVudC4NCj4+IFtMZXM6XSBU aGUgaXNzdWUgaXMgcHJvdG9jb2wgYWdub3N0aWMuDQo+Pg0KPj4gLSAgICAgICAgICBBbGdvcml0 aG0gcHJvcG9zZWQgbmVlZHMgbW9yZSBjbGFyaXR5OiBUYWtlIFNlY3Rpb24gMy4yLjQNCj4+DQo+ PiBvDQo+PiAgICAgICAgICAgICAgICAgICAgICAgIOKAnCAgIDEuICBTbWFsbGVyIHJhbmdlIHdp bnMNCj4+DQo+PiAgICAgICAgICAgICAgIDIuICBJUHY2IGVudHJ5IHdpbnMgb3ZlciBJUHY0IGVu dHJ5DQo+PiAgICAgICAgICAgICAgIOKApg0KPj4gICAgICAgICAg4oCcDQo+PiAgICAgICAgICAg ICAgICAgICBXaGF0IGhhcHBlbnMgaW4gY2FzZSBvZiBwcmVmaXggY29uZmxpY3Qgb3IgU0lEIGNv bmZsaWN0IHdpdGggb25seSBwcmVmaXggYWR2ZXJ0aXNlbWVudHMgKHJhbmdlIDEpLiAgU2F5IG11 bHRpcGxlIHByZWZpeGVzIGhhdmUgc2FtZSBTSUQgaW4gb25lIHByb3RvY29sIGluc3RhbmNlIGFu ZCBpbiBkaWZmZXJlbnQgcHJvdG9jb2xzLg0KPj4gICAgICAgICAgICAgICAgICAgSSBzZWUgMiBs ZXZlbHMgb2YgcmVzb2x1dGlvbiByZXF1aXJlZCB2aXouLCBvbmUgYXQgd2l0aGluIHRoZSBwcm90 b2NvbCBhbmQgb25lIGFtb25nIHRoZSBwcm90b2NvbHMuICBObyBkaXNjdXNzaW9uIG9uIHRoaXMu DQo+Pg0KPj4gW0xlczpdIFRoZSBmdWxsIHNldCBvZiBydWxlcyBzcGVjaWZpZWQgaW4gdGhlIGRy YWZ0IHByb3ZpZGUgZGV0ZXJtaW5pc3RpYyByZXNvbHV0aW9uIGluIGFsbCBjYXNlcy4gWW91IGhh dmUgc25pcHBlZCBvbmx5IHRoZSBmaXJzdCB0d28gcnVsZXMuIElmIGEgcHJlZmVyZW5jZSBpcyBu b3Qgb2J0YWluZWQgYmFzZWQgb24gdGhlIGZpcnN0IHR3byBydWxlcyB5b3UgY29udGludWUgb24g dG8gcnVsZSAjMywgdGhlbiBydWxlICM0LCBldGMuDQo+Pg0KPj4gICAgICAgICAgICAgICAgICAg U2ltaWxhcmx5IGluIGNhc2Ugb2YgU0lEIGNvbmZsaWN0ICAocmFuZ2UgMSksIGl04oCZcyBub3Qg c3BlY2lmaWVkIHdoaWNoIHByb3RvY29s4oCZcyBTSUQgbmVlZCB0byBiZSBjb25zaWRlcmVkLiAg QXJlIHlvdSBhc3N1bWluZyBzb21lIHNvcnQgb2YgQWRtaW4gZGlzdGFuY2UgcGxheSBhIHJvbGUg aW4gcmVzb2x1dGlvbj8NCj4+IFtMZXM6XSBObyDigJMgYWRtaW4gZGlzdGFuY2UgcGxheXMgbm8g cm9sZSBoZXJlLg0KPj4NCj4+ICAgSSBkb27igJl0IHNlZSBhbnkgZGlzY3Vzc2lvbiBpbiB0aGUg ZG9jdW1lbnQgIGFuZCBuZWVkcyBtb3JlIGNsYXJpdHkgdGhlcmUgdG9vLg0KPj4gbyAgIEFsc28g d2hhdCBoYXBwZW5zIGlmIGEgcHJlZml4IG9yIFNJRCBjb25mbGljdCBoYXBwZW5zIHdpdGggU1JN UyByYW5nZSAxIGFuZCBhIHByZWZpeCAgYWR2ZXJ0aXNlbWVudCAoMiBjYXNlcykNCj4+IGEuICAg ICAgIG9mIG9uZSBwcm90b2NvbCBhbmQNCj4+IGIuICAgICAgbXVsdGlwbGUgcHJvdG9jb2xzPw0K Pj4NCj4+IFtMZXM6XSBUaGUgc291cmNlIG9mIHRoZSBTSUQgYWR2ZXJ0aXNlbWVudCAod2hhdCBw cm90b2NvbC9wcm90b2NvbCBpbnN0YW5jZSBvciB3aGV0aGVyIGl0IGlzIFNSTVMgYmFzZWQpIHBs YXlzIG5vIHJvbGUuIFRoZSB0aWUgYnJlYWtlciBydWxlcyBhcyBkZWZpbmVkIGFyZSBjb21wbGV0 ZSBhbmQgcHJvdmlkZSBhIGRldGVybWluaXN0aWMgYW5zd2VyIGluIGFsbCBjYXNlcy4NCj4+IElm IHlvdSBiZWxpZXZlIHRoYXQgaXMgbm90IHRydWUgcGxlYXNlIHByb3ZpZGUgYSBzcGVjaWZpYyBl eGFtcGxlIHdoZXJlIHlvdSBhcHBseSBhbGwgdGhlIHJ1bGVzIGluIHRoZSBvcmRlciBzcGVjaWZp ZWQgYW5kIHN0aWxsIGRvIG5vdCBkZXRlcm1pbmUgdGhlIHByZWZlcnJlZCBlbnRyeS4NCj4+DQo+ Pg0KPj4gLSAgICAgICAgICBPbiB0aGUgYmVsb3cgYXNzdW1wdGlvbjogKFNlY3Rpb24gMy4yLjQp DQo+PiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDigJxUaGlzIGhh cyB0aGUgbmljZSBwcm9wZXJ0eSB0aGF0IGEgc2luZ2xlIG1pc2NvbmZpZ3VyYXRvaW9uIG9mIGFu IFNSTVMNCj4+ICAgICAgICAgICAgICAgICAgIGVudHJ5IHdpdGggYSBsYXJnZSByYW5nZSB3aWxs IG5vdCBiZSBwcmVmZXJyZWQgb3ZlciBhIGxhcmdlIG51bWJlciBvZg0KPj4gICAgICAgICAgICAg ICAgICAgU0lEcyBhZHZlcnRpc2VkIGluIHByZWZpeCByZWFjaGFiaWxpdHkgYWR2ZXJ0aXNlbWVu dHMu4oCdDQo+PiBXaGlsZSBhbnl0aGluZyBjYW4gaGFwcGVuIGluIHRoZW9yeSwgSSBmb3VuZCBp dCBiaXQgb2RkIHRvIHNlZSB3aHkgU1JNUyBlbnRyeSBpcyBiZWluZyBhZHZlcnRpc2VkIGFuZCBm b3IgdGhlIHNhbWUgcHJlZml4LCBTSUQgaXMgYWxzbyBhZHZlcnRpc2VkIHRocm91Z2ggcmVhY2hh YmlsaXR5IGFkdmVydGlzZW1lbnRzPw0KPj4gVGhpcyBpcyBhZ2FpbnN0IHRoZSBzcGlyaXQgb2Yg U1JNUyBhZHZlcnRpc2VtZW50LCBpc27igJl0IGl0PyBXaGlsZSB0aGlzIGNhbiBoYXBwZW4sIGl0 IHNlZW1zIHdlIGFyZSBjbGFpbWluZyByZXNvbHV0aW9uIHNvbHV0aW9uIGJ5IGZvY3VzaW5nIG1v cmUgb24gIHRoaXMgY2FzZSBpbiB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudC4N Cj4+DQo+PiBbTGVzOl0gVGhlcmUgYXJlIHR3byBsZWdpdGltYXRlIHVzZSBjYXNlcyBmb3IgU1JN UzoNCj4+DQo+PiAxKVRvIGFkdmVydGlzZSBTSURzIGZvciBub24tU1IgY2FwYWJsZSBub2RlcyAy KUFzIGEgZ2xvYmFsDQo+PiBwcm92aXNpb25pbmcgdG9vbA0KPj4NCj4+IExldOKAmXMgZXhhbWlu ZSB0aGUgZmlyc3QgY2FzZS4gSSBoYXZlIGFuIExEUCBlbmFibGVkIG5ldHdvcmsgYW5kIEkgYmVn aW4gaW50cm9kdWNpbmcgU1IgY2FwYWJsZSBub2Rlcy4gQXQgYSBnaXZlbiBtb21lbnQgaW4gdGlt ZSBSb3V0ZXIgQSBpcyBOT1QgU1IgY2FwYWJsZSBhbmQgU1JNUyBhZHZlcnRpc2VtZW50cyBjb3Zl ciBwcmVmaXggU0lEcyBmb3IgdGhlIGFkZHJlc3NlcyBhc3NvY2lhdGVkIHdpdGggUm91dGVyIEEu DQo+PiBJIHRoZW4gdXBncmFkZSBSb3V0ZXIgQSB0byBiZWNvbWUgU1IgY2FwYWJsZS4gQmVjYXVz ZSBJIHdhbnQgdG8gZG8g4oCcbWFrZS1iZWZvcmUtYnJlYWvigJ0gSSBkbyBub3QgaW1tZWRpYXRl bHkgcmVtb3ZlIHRoZSBTUk1TIGFkdmVydGlzZW1lbnRzIGNvdmVyaW5nIHRoZSBhZGRyZXNzZXMg YXNzb2NpYXRlZCB3aXRoIFJvdXRlciBBLiBJIHVwZ3JhZGUgQSwgYWRkIGNvbmZpZ3VyYXRpb24g b2YgU0lEcyBsb2NhbGx5IG9uIFJvdXRlciBBLCBhbmQgdmVyaWZ5IHRoYXQgdGhlIGFkdmVydGlz ZW1lbnRzIG9yaWdpbmF0aW5nIGZyb20gcHJvdG9jb2xzIG9uIFJvdXRlciBBIGFyZSBjb3JyZWN0 LiBJZiBhbiBpbmNvbnNpc3RlbmN5IGlzIGludHJvZHVjZWQgd2hlbiBjb25maWd1cmluZyB0aGUg U0lEcyBvbiBSb3V0ZXIgQSB0aGVuIEkgd2lsbCBoYXZlIGFuIFNSTVMgYWR2ZXJ0aXNlbWVudCBh bmQgYSBwcmVmaXgtcmVhY2hhYmlsaXR5IGFkdmVydGlzZW1lbnQgdGhhdCBjb25mbGljdC4gVW50 aWwgdGhlIGNvbmZsaWN0IGlzIGNvcnJlY3RlZCB3ZSB1c2UgdGhlIGNvbmZsaWN0IHJlc29sdXRp b24gcnVsZXMgdG8gcHJvdmlkZSBkZXRlcm1pbmlzdGljIGZvcndhcmRpbmcgYmVoYXZpb3IuDQo+ Pg0KPj4gVGhpcyB0byBtZSBpcyBhIG5vcm1hbCBhbmQgZXhwZWN0ZWQgdXBncmFkZSBzY2VuYXJp by4NCj4+DQo+Pg0KPj4gVGhpcyBpcyBvbmUgb2YgdGhlIHJlYXNvbnMgb2YgbXkgZmlyc3QgY29t bWVudCBiZWxvdy4gWW91IGdvdCB0byBzZXBhcmF0ZSB0aGUgcmVhY2hhYmlsaXR5IGFkdmVydGlz ZW1lbnRzIGFuZCBTUk1TIGFkdmVydGlzZW1lbnRzOyBhcyBpbiBwcmluY2lwbGUgdGhlc2UgYXJl IGRlZmluZWQgZm9yIGRpZmZlcmVudCBwdXJwb3Nlcy4gSSBkb27igJl0IHNlZSB3ZSAgbmVlZCBh bGdvcml0aG0gdG8gcHJlZmVyIHJlYWNoYWJpbGl0eSBhZHZlcnRpc2VtZW50IG92ZXIgU1JNUyBh ZHZlcnRpc2VtZW50IChpZiB3ZSBkb27igJl0IGNvbXBhcmUgdGhlc2UgMiBjYXRlZ29yaWVzKS4N Cj4+DQo+Pg0KPj4NCj4+IFtMZXM6XSBJIGRpc2FncmVlIOKAkyBob3BlZnVsbHkgbXkgY29tbWVu dHMgaGF2ZSBoZWxwZWQgeW91IHRvIHVuZGVyc3RhbmQgd2h5Lg0KPj4NCj4+ICAgICBMZXMNCj4+ DQo+Pg0KPj4gYXMgdGhlIHNlY3Rpb25zIHlvdSBoYXZlIHF1b3RlZCBjbGVhcmx5IHN0YXRlLg0K Pj4NCj4+IFdoeT8gQmVjYXVzZSB3ZSBuZWVkIGNvbnNpc3RlbnQgdXNlIG9mIFNJRHMgaW4gdGhl IGZvcndhcmRpbmcgcGxhbmUuIEZyb20gZm9yd2FyZGluZyBwZXJzcGVjdGl2ZSBpdCBtYXR0ZXJz IG5vdCB3aGV0aGVyIHRoZSBTSUQgd2FzIGFkdmVydGlzZWQgYnkgcHJvdG9jb2wgaW5zdGFuY2Ug IzEgb3IgIzIgb3IgYnkgYW4gU1JNUy4NCj4+DQo+PiBXaGF0IG1hdHRlcnMgaXMgdGhhdCB0aGUg U0lEIEkgdXNlIHRvIGRldGVybWluZSB3aGF0IGxhYmVsIEkgaW5zdGFsbCBpbiBteSBmb3J3YXJk aW5nIHBsYW5lIGlzIHRoZSBzYW1lIFNJRCB0aGF0IG15IG5laWdoYm9ycyB3aWxsIHVzZS4gT3Ro ZXJ3aXNlIGZvcndhcmRpbmcgd2lsbCBiZSBicm9rZW4uDQo+Pg0KPj4gICAgIExlcw0KPj4NCj4+ DQo+PiBGcm9tOiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIFVtYQ0KPj4gQ2h1bmR1cmkNCj4+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjcsIDIw MTYgNDozMSBQTQ0KPj4gVG86IGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208bWFpbHRvOmJydW5v LmRlY3JhZW5lQG9yYW5nZS5jb20+OyBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRm Lm9yZz4NCj4+IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBkcmFmdC1naW5zYmVyZy1zcHJpbmctY29u ZmxpY3QtcmVzb2x1dGlvbiAtIFdHDQo+PiBhZG9wdGlvbiBjYWxsDQo+Pg0KPj4gRGVhciBBdXRo b3JzLA0KPj4NCj4+IEhhdmUgZmV3IGNvbW1lbnRzIG9uIHRoZSBkcmFmdDoNCj4+DQo+PiAxLg0K Pj4gICAgICAgICAgQXMgSSBpbmRpY2F0ZWQgZHVyaW5nIG1lZXRpbmcgLSBJIGFtIG5vdCBzdXJl IHdoeSB3ZSBoYXZlIHRvIGNsdWIgIHZlcmlmaWNhdGlvbiBvZiBTSURzIGFkdmVydGlzZWQgdGhy b3VnaCByZWd1bGFyIHByb3RvY29sIHJlYWNoYWJpbGl0eQ0KPj4gICAgICAgICAgICAgICAgICBw cmVmaXhlcyBhbmQgdGhlIHJhbmdlcyBhZHZlcnRpc2VkIHRocm91Z2ggJ01hcHBpbmcgU2VydmVy JyAgKFNSTVMpLiBJIGRpZG4ndCBzZWUgYW55IGNvbXBlbGxpbmcgcmVhc29uIHRvIGRvIHRoaXMu DQo+PiAgICAgICAgICAgICAgICAgICBTSURzIGFkdmVydGlzZWQgdGhyb3VnaCByZWFjaGFiaWxp dHkgcHJlZml4ZXMgZG9lc24ndCBoYXZlIHJhbmdlcyB1bmxpa2UgU1JNUyBhZHZlcnRpc2VtZW50 cy4NCj4+ICAgICAgICAgICAgICAgICAgIEFzIFNSTVMgYWR2ZXJ0aXNlbWVudHMgYXJlIHByaW1h cmlseSBmb3Igbm9kZXMgd2hpY2ggYXJlIG5vdCBTUiBjYXBhYmxlIGFuZCAgSSBmZWVsIHdlIHNo b3VsZCBub3QgbWl4IHRoaXMgd2l0aCBub2RlcyB3aGljaCBhcmUgU1IgY2FwYWJsZS4NCj4+DQo+ PiAgICAgICAgICBUaGlzIGlzb2xhdGlvbiBoZWxwcyByZXN0cmljdGluZyB0aGUgcmVzb2x1dGlv biB3b3JrIHByaW1hcmlseSBmb3IgbXVsdGlwbGUgU1JNUyBlbnRyaWVzIGFkdmVydGlzZWQgdGhy b3VnaCBvbmUgbm9kZSBvciBtdWx0aXBsZSBub2Rlcy4NCj4+ICAgICAgICAgICAgICAgICAgU1JN UyBhZHZlcnRpc2VtZW50cyBhcmUgaW5kZWVkIGxpdHRsZSBiaXQgdW5pcXVlIGluIHRoYXQgeW91 IGFyZSBhZHZlcnRpc2luZyAiY29uZmlndXJhdGlvbiIgb24gYmVoYWxmIG9mIG5vZGUgWCBmcm9t IG5vZGUgWQ0KPj4gICAgICAgICAgICAgICAgICB3aXRoIHJhbmdlcyAoYm90aCBwcmVmaXggcmFu Z2VzIGFuZCBTSUQgcmFuZ2VzKS4NCj4+DQo+Pg0KPj4gMi4NCj4+ICAgICAgICAgICAgICAgICAg UmVnYXJkaW5nICB0aGUgc2NvcGUgb2YgY29uZmxpY3QgcmVzb2x1dGlvbjoNCj4+DQo+Pg0KPj4g ICAgICAgICBTZWN0aW9uIDENCj4+DQo+PiAgICAgICAgICAgICAiICAgVGhlIHByb2JsZW0gdG8g YmUgYWRkcmVzc2VkIGlzIHByb3RvY29sIGluZGVwZW5kZW50IGkuZS4sIHNlZ21lbnQNCj4+ICAg ICAgICAgICByZWxhdGVkIGFkdmVydGlzZW1lbnRzIG1heSBiZSBvcmlnaW5hdGVkIGJ5IG11bHRp cGxlIG5vZGVzIHVzaW5nDQo+PiAgICAgICAgICAgZGlmZmVyZW50IHByb3RvY29scyBhbmQgeWV0 IHRoZSBjb25mbGljdCByZXNvbHV0aW9uIE1VU1QgYmUgdGhlIHNhbWUNCj4+ICAgICAgICAgICBv biBhbGwgbm9kZXMgcmVnYXJkbGVzcyBvZiB0aGUgcHJvdG9jb2wgdXNlZCB0byB0cmFuc3BvcnQg dGhlDQo+PiAgICAgICAgICAgYWR2ZXJ0aXNlbWVudHMuIg0KPj4NCj4+ICAgICAgICAgIFNlY3Rp b24gMy4yLjgNCj4+ICAgICAgICAgICAgIiAgIG8gIEluIGNhc2VzIHdoZXJlIG11bHRpcGxlIHJv dXRpbmcgcHJvdG9jb2xzIGFyZSBpbiB1c2UgbWFwcGluZw0KPj4gICAgICAgIGVudHJpZXMgYWR2 ZXJ0aXNlZCBieSBhbGwgcm91dGluZyBwcm90b2NvbHMgTVVTVCBiZSBpbmNsdWRlZC4iDQo+Pg0K Pj4gICAgICAgIFRoaXMgc291bmRzIGxpa2Ugd2UgYXJlIHNlZWtpbmcgdG8gcmVzb2x2ZSBjb25m bGljdGluZyBlbnRyaWVzIG91dHNpZGUgYW5kIGFjcm9zcyB0aGUgcHJvdG9jb2xzPw0KPj4gICAg ICAgIEVhY2ggSUdQIGhhcyBzZXBhcmF0ZSBtZWNoYW5pc20gZm9yIGFkdmVydGlzaW5nIG1hcHBp bmcgZW50cnkgYW5kIEkgdGhpcyBpcyBub3QgY2xlYXIgd2l0aCB0aGUgY3VycmVudCB2ZXJzaW9u IG9mIHRoZSBkcmFmdCBob3cgd2UgY2FuIGNyb3NzIHZlcmlmeSBTSUQvUHJlZml4IGNvbmZsaWN0 IGFjcm9zcyAgdGhlIHByb3RvY29sLg0KPj4gICAgICAgQ2FuIHlvdSBjbGFyaWZ5IHRoaXM/DQo+ Pg0KPj4NCj4+IC0tDQo+PiBVbWEgQy4NCj4+DQo+Pg0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4+IEZyb206IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YNCj4+IGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208bWFpbHRvOmJydW5vLmRl Y3JhZW5lQG9yYW5nZS5jb20+DQo+PiBTZW50OiBUaHVyc2RheSwgQXByaWwgMTQsIDIwMTYgMTI6 NTUgQU0NCj4+IFRvOiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4+ IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBkcmFmdC1naW5zYmVyZy1zcHJpbmctY29uZmxpY3QtcmVz b2x1dGlvbiAtIFdHDQo+PiBhZG9wdGlvbiBjYWxsDQo+Pg0KPj4+IEZyb206ICBicnVuby5kZWNy YWVuZUBvcmFuZ2UuY29tPG1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPiA+IFNlbnQ6 IFRodXJzZGF5LCBBcHJpbCAxNCwgMjAxNg0KPj4+IDk6NTEgQU0NCj4+Pg0KPj4+IERlYXIgV0cs DQo+Pj4NCj4+PiBBcyB3ZSBkaXNjdXNzZWQgYXQgb3VyIG1lZXRpbmcgbGFzdCB3ZWVrLCB3b3Jr aW5nIGdyb3VwIGFkb3B0aW9uIGhhcw0KPj4+IGJlZW4gcmVxdWVzdGVkIGZvciBkcmFmdC1naW5z YmVyZy1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbi4NCj4+PiBQbGVhc2UgcmVwbHkgdG8gdGhl IGxpc3Qgd2l0aCB5b3VyIGNvbW1lbnRzLCBpbmNsdWRpbmcgYWx0aG91Z2ggbm90DQo+Pj4gbGlt aXRlZCB0byB3aGV0aGVyIG9yIG5vdCB5b3Ugc3VwcG9ydCBhZG9wdGlvbi4NCj4+DQo+PiBXZSB3 aWxsIGVuZCB0aGUgY2FsbCBvbiBBcHJpbCAyOSwgMjAxNi4NCj4+DQo+Pg0KPj4+IFRoYW5rcywN Cj4+Pg0KPj4+IC0tSm9obiBhbmQgQnJ1bm8NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4+IF9fX19fDQo+Pj4NCj4+PiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCj4+PiBjb25maWRlbnRpZWxsZXMgb3UgcHJp dmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZQ0KPj4+IGRpZmZ1c2VzLCBleHBs b2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdQ0KPj4+ IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRl dXIgZXQgbGUNCj4+PiBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMg bWVzc2FnZXMgZWxlY3Ryb25pcXVlcw0KPj4+IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRp b24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4+Pg0KPj4+IFRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvcg0KPj4+ IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhl eSBzaG91bGQgbm90DQo+Pj4gYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi4NCj4+PiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCj4+PiBhbmQgZGVsZXRlIHRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPj4+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jh bmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQNCj4+PiBoYXZlIGJlZW4gbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPj4+IFRoYW5rIHlvdS4NCj4+Pg0KPj4+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gc3ByaW5nIG1h aWxpbmcgbGlzdA0KPj4+IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0K Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQo+Pg0KPj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+PiBfIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4NCj4+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBl dXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmls ZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRy dWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25p cXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuDQo+Pg0KPj4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMg bWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBt YXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1 c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+PiBJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4+IEFzIGVtYWlscyBtYXkg YmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBi ZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4+IFRoYW5rIHlvdS4NCj4+DQo+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gc3By aW5nIG1haWxpbmcgbGlzdA0KPj4gc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5v cmc+DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KPj4N Cj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBz cHJpbmcgbWFpbGluZyBsaXN0DQo+PiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRm Lm9yZz4NCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQo+ DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNw cmluZyBtYWlsaW5nIGxpc3QNCj4gc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5v cmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQo+DQoN Cg0K --_000_1B502206DFA0C544B7A60469152008635BCE58ABeusaamb106erics_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVu dD0iTWljcm9zb2Z0IEV4Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAt LT4NCjxzdHlsZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1s ZWZ0OiA0cHQ7IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0K PC9oZWFkPg0KPGJvZHk+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+UGV0ZXIsPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2 Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBh cyBhIG1hdHRlciBvZiBmYWN0LCBTUk1TIGlzIGEgU0lEIHByb3Zpc2lvbmluZyB0b29sLCB3aGV0 aGVyIHlvdSBsaWtlIGl0IG9yIG5vdC4gPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5J dCdzIG5vdCBhYm91dCB5b3VyIG9yIG15IGxpbmtpbmcgLSBJIHdhcyB0YWxraW5nIGFib3V0IHdo YXQncyB0aGUgZGVmaW5lZCBzY29wZSBzbyBmYXIgKGFyY2hpdGVjdHVyZSBkb2Mgb3IgcHJvdG9j b2wgZG9jcyk8L2Rpdj4NCjxkaXY+YW5kIGhvdyB5b3Ugd2FudCB0byBleHRlbmQgdGhlIHNjb3Bl LiA8L2Rpdj4NCjxkaXY+V2VsbCwgaWYgeW91IHdhbnQgdG8gZXh0ZW5kIHRoZSBjdXJyZW50IHNj b3BlIG9mIFNSTVMgYXMgYSAmcXVvdDsmcXVvdDsmZ3Q7MilBcyBhIGdsb2JhbCBwcm92aXNpb25p bmcgdG9vbCZxdW90OyAtIDwvZGl2Pg0KPGRpdj5QbHouIGRvIHNvIGJ1dCBub3Qgd2hpbGUgcHJv dmlkaW5nIGNvbmZsaWN0IHJlc29sdXRpb24gc29sdXRpb24uPC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZndDsgSXQgcHJvdmlkZXMgYWxsIHRoZSBmdW5jdGlvbmFsaXR5IHRoYXQgaXMgcmVxdWlyZWQg Zm9yIHN1Y2ggcHJvdmlzaW9uaW5nIHRvb2wuIDwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmd0O1lvdSBjYW4gbm90IHJlc3RyaWN0IGl0cyB1 c2FnZSB0byBTUi9MRFAgaW50ZXJvcCBjYXNlLjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxk aXY+SSBkaWRuJ3QgcmVzdHJpY3QgYW55dGhpbmcgLSBQbHouIHNlZSBTUk1TIHN0dWZmIHNvIGZh cjo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PjEuIDxhIGhyZWY9Imh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctMDgjc2Vj dGlvbi0zLjYiPjxmb250IGNvbG9yPSJibHVlIj48dT5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLTA4I3NlY3Rpb24tMy42PC91Pjwv Zm9udD48L2E+IDwvZGl2Pg0KPGRpdj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPGk+JnF1b3Q7IDwvaT48aT4zLjYuMS4mbmJzcDsgTWFwcGluZyBTZXJ2ZXI8L2k+ PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj48aT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9pPjxpPiBBIFJlbW90ZS1CaW5kaW5nIFNJRCBT IGFkdmVydGlzZWQgYnkgdGhlIG1hcHBpbmcgc2VydmVyIE0gZm9yIHJlbW90ZTwvaT48L2Rpdj4N CjxkaXY+PGk+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IDwvaT48aT5wcmVmaXggUiBhdHRhY2hlZCB0byBub24tU1ItY2FwYWJsZSBub2RlIE4gc2lnbmFs cyB0aGUgc2FtZTwvaT48L2Rpdj4NCjxkaXY+PGk+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvaT48aT5pbmZvcm1hdGlvbiBhcyBpZiBOIGhhZCBhZHZl cnRpc2VkIFMgYXMgYSBQcmVmaXgtU0lELiZuYnNwOyBGdXJ0aGVyPC9pPjwvZGl2Pg0KPGRpdj48 aT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9pPjxp PmRldGFpbHMgYXJlIGRlc2NyaWJlZCBpbiB0aGUgU1IvTERQIGludGVyd29ya2luZyBwcm9jZWR1 cmVzPC9pPjwvZGl2Pg0KPGRpdj48aT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPC9pPjxpPiAoW0ktRC5pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmct bGRwLWludGVyb3BdLjwvaT48aT4mcXVvdDs8L2k+PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0K PGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PjIuIElTSVM6IDxhIGhy ZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1y b3V0aW5nLWV4dGVuc2lvbnMtMDYjc2VjdGlvbi0yLjQiPjxmb250IGNvbG9yPSJibHVlIj48dT5o dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pc2lzLXNlZ21lbnQtcm91dGlu Zy1leHRlbnNpb25zLTA2I3NlY3Rpb24tMi40PC91PjwvZm9udD48L2E+IDwvZGl2Pg0KPGRpdj4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPGk+JnF1b3Q7IDwvaT48aT5UaGlzIGZ1 bmN0aW9uYWxpdHkgaXMgY2FsbGVkIHRoZTwvaT48L2Rpdj4NCjxkaXY+PGk+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvaT48aT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9pPjxpPidNYXBwaW5nIFNlcnZlcicgYW5kIGl0J3MgdXNl ZCB3aGVuLCBpbiBhIGhldGVyb2dlbmVvdXMgbmV0d29yayw8L2k+PC9kaXY+DQo8ZGl2PjxpPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L2k+PGk+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvaT48aT4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgPC9pPjxpPm5vdCBhbGwgbm9kZXMgYXJlIGNhcGFibGUgb2YgYWR2ZXJ0aXNp bmcgdGhlaXIgb3duIFNJRHMvTGFiZWxzLjwvaT48aT4mcXVvdDs8L2k+PC9kaXY+DQo8ZGl2PiZu YnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+My4gT1NQRjogPGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtb3NwZi1zZWdtZW50LXJvdXRpbmct ZXh0ZW5zaW9ucy0wOCNzZWN0aW9uLTQiPjxmb250IGNvbG9yPSJibHVlIj48dT5odHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vc3BmLXNlZ21lbnQtcm91dGluZy1leHRlbnNp b25zLTA4I3NlY3Rpb24tNDwvdT48L2ZvbnQ+PC9hPiA8L2Rpdj4NCjxkaXY+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxpPiZxdW90OzwvaT48aT4mbmJzcDsmbmJzcDsgSW4gc29t ZSBjYXNlcyBpdCBpcyB1c2VmdWwgdG8gYWR2ZXJ0aXNlIGF0dHJpYnV0ZXMgZm9yIGEgcmFuZ2Ug b2Y8L2k+PC9kaXY+DQo8ZGl2PjxpPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8L2k+PGk+cHJlZml4ZXMuJm5ic3A7IFRoZSBTZWdtZW50IFJvdXRpbmcgTWFwcGluZyBT ZXJ2ZXIsIHdoaWNoIGlzIGRlc2NyaWJlZCBpbjwvaT48L2Rpdj4NCjxkaXY+PGk+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvaT48aT5bPC9pPjxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9zcGYtc2VnbWVudC1yb3V0aW5nLWV4 dGVuc2lvbnMtMDgiPjxpPkktRC5maWxzZmlscy1zcHJpbmctc2VnbWVudC1yb3V0aW5nLWxkcC1p bnRlcm9wPC9pPjwvYT48aT5dLCBpcyBhbiBleGFtcGxlPC9pPjwvZGl2Pg0KPGRpdj48aT4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9pPjxpPndoZXJlIHdlIG5lZWQg YSBzaW5nbGUgYWR2ZXJ0aXNlbWVudCB0byBhZHZlcnRpc2UgU0lEcyBmb3IgbXVsdGlwbGU8L2k+ PC9kaXY+DQo8ZGl2PjxpPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8 L2k+PGk+cHJlZml4ZXMgZnJvbSBhIGNvbnRpZ3VvdXMgYWRkcmVzcyByYW5nZS48L2k+PGk+JnF1 b3Q7PC9pPjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0iMiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMHB0OyI+Jm5ic3A7PC9zcGFuPjwvZm9udD48L2Rpdj4NCjxk aXY+QWdhaW4sIHBsei4gZXh0ZW5kIHRoZSBzY29wZSBmaXJzdCBhbmQgY29uc2lkZXIgdGhlIHNh bWUgaW4gcmVzb2x1dGlvbiBzb2x1dGlvbi4gSSBhbSBmaW5lIHdpdGggaXQuPC9kaXY+DQo8ZGl2 PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+LS08L2Rpdj4NCjxkaXY+VW1h IEMuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQoNCkZyb206IFBldGVyIFBzZW5hayBbPGEgaHJl Zj0ibWFpbHRvOnBwc2VuYWtAY2lzY28uY29tIj5tYWlsdG86cHBzZW5ha0BjaXNjby5jb208L2E+ XQ0KPGJyPg0KDQpTZW50OiBUaHVyc2RheSwgTWF5IDEyLCAyMDE2IDExOjAzIEFNPGJyPg0KDQpU bzogVW1hIENodW5kdXJpOyBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKTxicj4NCg0KQ2M6IExl cyBHaW5zYmVyZyAoZ2luc2JlcmcpOyBzcHJpbmdAaWV0Zi5vcmc7IGJydW5vLmRlY3JhZW5lQG9y YW5nZS5jb208YnI+DQoNClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBkcmFmdC1naW5zYmVyZy1zcHJp bmctY29uZmxpY3QtcmVzb2x1dGlvbiAtIFdHIGFkb3B0aW9uIGNhbGw8L2Rpdj4NCjxkaXY+Jm5i c3A7PC9kaXY+DQo8ZGl2PkhpIFVtYSw8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2Pk9u IDUvMTIvMTYgMTk6NDkgLCBVbWEgQ2h1bmR1cmkgd3JvdGU6PC9kaXY+DQo8ZGl2PiZndDsgU3Rl ZmFubyw8L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7IFRoYW5rcyBmb3IgeW91ciBy ZXNwb25zZS48L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgdXNpbmcgYSBTUk1TIGZvciBhZHZlcnRp c2luZyBTSUQgb24gYmVoYWxmIG9mIFNSIGNhcGFibGUgbm9kZXMgZG9lcyBub3QgaW50cm9kdWNl IGFueSBjaGFuZ2UgaW4gdGhlIFNSIGFyY2hpdGVjdHVyZSBzbyBub3Q8L2Rpdj4NCjxkaXY+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IHN1cmUgd2hhdCB3 ZSBuZWVkIHRvIGRvY3VtZW50IGhlcmUuPC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0 OyBNeSBwb2ludCBiZWxvdzogV2UgYXJlIGNyZWF0aW5nIGEgY29uZmxpY3QgcmVzb2x1dGlvbiBz b2x1dGlvbiBmb3IgYSBub24tZXhpc3RpbmcgcmVxdWlyZW1lbnQgb2YgdXNpbmcmbmJzcDsgU1JN UyB2aXouLCZuYnNwOyAmcXVvdDsmZ3Q7MilBcyBhIGdsb2JhbCBwcm92aXNpb25pbmcgdG9vbCZx dW90Oy48L2Rpdj4NCjxkaXY+Jmd0OyZuYnNwOyBGcm9tIHlvdXIgc3RhdGVtZW50IGFib3ZlLCBp dCBzZWVtcyB5b3UgaGF2ZSBsZXNzIGludGVyZXN0IHRvIG1ha2UgdGhpcyBhcyBhIHJlcXVpcmVt ZW50L3Njb3BlIG9mIFNSTVM7IEkgYW0gbW9yZSBhbGlnbmVkIGluIHRoYXQgcGF0aC4uLi48L2Rp dj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PmFzIGEgbWF0dGVyIG9mIGZhY3QsIFNSTVMgaXMg YSBTSUQgcHJvdmlzaW9uaW5nIHRvb2wsIHdoZXRoZXIgeW91IGxpa2UgaXQgb3Igbm90LiBJdCBw cm92aWRlcyBhbGwgdGhlIGZ1bmN0aW9uYWxpdHkgdGhhdCBpcyByZXF1aXJlZCBmb3Igc3VjaCBw cm92aXNpb25pbmcgdG9vbC4gWW91IGNhbiBub3QgcmVzdHJpY3QgaXRzIHVzYWdlIHRvIFNSL0xE UCBpbnRlcm9wIGNhc2UuPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj50aGFua3MsPC9k aXY+DQo8ZGl2PlBldGVyPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+ DQo8ZGl2PiZndDsgT24gdGhlIHNlY29uZCBwb2ludDo8L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0K PGRpdj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg dGhlIGFyY2hpdGVjdHVyZSBkcmFmdCBpcyBkYXRhLXBhbmUgYWdub3N0aWMgc28gSSBwcmVzdW1l IHlvdSByZWZlciB0byBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscy48L2Rp dj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7IEFGQUlTLCZuYnNwOyA8YSBocmVmPSJodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5n LTA4Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVu dC1yb3V0aW5nLTA4PC9hPiZuYnNwOyB0YWxrcyBhYm91dCBib3RoIGRhdGEgcGxhbmVzIHJpZ2h0 IGZyb20gYWJzdHJhY3QgdG8gbXVsdGlwbGUgcGxhY2VzICh3aGljaCBpdCBvdWdodCB0bykuPC9k aXY+DQo8ZGl2PiZndDsgSSBsZWF2ZSB0aGlzIHRvIHlvdS9XRyBvbiB3aGVyZSB5b3Ugd2FudCB0 byBkb2N1bWVudCB0aGlzIC1idXQgSU1PIDwvZGl2Pg0KPGRpdj4mZ3Q7IGNvbmZsaWN0IHJlc29s dXRpb24gJnF1b3Q7c29sdXRpb24gZG9jdW1lbnQmcXVvdDsgaW4gdGhlIGN1cnJlbnQgZm9ybSBw b3RlbnRpYWxseSBpbnRyb2R1Y2luZyBmdW5kYW1lbnRhbCByZXF1aXJlbWVudHMmbmJzcDsgdG8g dGhlIHN5c3RlbSBsaWtlIGNyb3NzIHByb3RvY29sIHZlcmlmaWNhdGlvbiAod2l0aCBpbi9hY3Jv c3MgQVMpLiBQZXJoYXBzIHNvbWUgZGlzY3Vzc2lvbiBzaG91bGQgYmUgdGhlcmUgaW4gZGF0YSBw bGFuZSBkb2N1bWVudCB0aGVuLjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsgLS08 L2Rpdj4NCjxkaXY+Jmd0OyBVbWEgQy48L2Rpdj4NCjxkaXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7 PC9kaXY+DQo8ZGl2PiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L2Rpdj4NCjxkaXY+ Jmd0OyBGcm9tOiBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKSBbPGEgaHJlZj0ibWFpbHRvOnNw cmV2aWRpQGNpc2NvLmNvbSI+bWFpbHRvOnNwcmV2aWRpQGNpc2NvLmNvbTwvYT5dPC9kaXY+DQo8 ZGl2PiZndDsgU2VudDogV2VkbmVzZGF5LCBNYXkgMTEsIDIwMTYgNDo0NiBBTTwvZGl2Pg0KPGRp dj4mZ3Q7IFRvOiBVbWEgQ2h1bmR1cmk8L2Rpdj4NCjxkaXY+Jmd0OyBDYzogTGVzIEdpbnNiZXJn IChnaW5zYmVyZyk7IDxhIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIj5i cnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPC9hPjsgPC9kaXY+DQo8ZGl2PiZndDsgPGEgaHJlZj0i bWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYub3JnPC9hPjwvZGl2Pg0KPGRpdj4m Z3Q7IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBkcmFmdC1naW5zYmVyZy1zcHJpbmctY29uZmxpY3Qt cmVzb2x1dGlvbiAtIFdHIDwvZGl2Pg0KPGRpdj4mZ3Q7IGFkb3B0aW9uIGNhbGw8L2Rpdj4NCjxk aXY+Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IE9uIE1heSA2LCAy MDE2LCBhdCAxMDoxNiBQTSwgVW1hIENodW5kdXJpICZsdDs8YSBocmVmPSJtYWlsdG86dW1hLmNo dW5kdXJpQGVyaWNzc29uLmNvbSI+dW1hLmNodW5kdXJpQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdy b3RlOjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBMZXMsPC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IDIgcXVpY2sgdGhpbmdzLjwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAxLjwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7W0xlczpdIFRoZXJlIGFyZSB0d28gbGVnaXRp bWF0ZSB1c2UgY2FzZXMgZm9yIFNSTVM6PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsxKVRvIGFkdmVydGlzZSBTSURzIGZvciBub24t U1IgY2FwYWJsZSBub2RlczwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAmZ3Q7MilBcyBhIGdsb2JhbCBwcm92aXNpb25pbmcgdG9vbDwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyBJIGFtIGhlYXJpbmcgIzIgZm9yIHRoZSBmaXJzdCB0aW1lLiBJIGRvbuKAmXQgc2VlIHRoaXMg ZWl0aGVyJm5ic3A7IGRpc2N1c3NlZCBlYXJsaWVyIGluIHRoZSBXRyBsaXN0Jm5ic3A7IG9yIGNh cHR1cmVkIGluIGFyY2hpdGVjdHVyZSBkb2N1bWVudDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLTA3Ij5o dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0 aW5nLTA3PC9hPi4gRXZlbiBpbiB0aGUgcHJvdG9jb2wgZXh0ZW5zaW9ucyBkb2N1bWVudCBmb3Ig ZXhhbXBsZTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1pc2lzLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb25zLTA2I3NlY3Rpb24tMi40Ij5odHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pc2lzLXNlZ21lbnQtcm91dGluZy1l eHRlbnNpb25zLTA2I3NlY3Rpb24tMi40PC9hPiB3ZSBhbHdheXMgZGlzY3Vzc2VkIHRoaXMgZnJv bSBub24tU1I8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgY2FwYWJsZSBub2RlcyBQb1YuIFNvIEkgcmVxdWVzdCB0byBhZGQgdGhp cyBpbiBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgYmVmb3JlIGZhY3RvcmluZyB0aGlzIGZvciBzb2x1 dGlvbiBpbiBjb25mbGljdCByZXNvbHV0aW9uLjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2 PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyB1c2luZyBhIFNSTVMgZm9yIGFkdmVydGlzaW5nIFNJRCBv biBiZWhhbGYgb2YgU1IgY2FwYWJsZSBub2RlcyBkb2VzIG5vdCBpbnRyb2R1Y2UgYW55IGNoYW5n ZSBpbiB0aGUgU1IgYXJjaGl0ZWN0dXJlIHNvIG5vdCBzdXJlIHdoYXQgd2UgbmVlZCB0byBkb2N1 bWVudCBoZXJlLjwvZGl2Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+ Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAyLiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBbHNvIHRoaXMgaXMgdGhlIGZpcnN0IHRpbWUg ZXZlciB3ZSBoYXZlIGEgcmVxdWlyZW1lbnQgZm9yIGNyb3NzIHByb3RvY29scyB2ZXJpZmljYXRp b24gd2Ugb3VnaHQgdG8gZGlzY3VzcyB0aGUgaW1wbGljYXRpb25zIG9mIHRoaXM8L2Rpdj4NCjxk aXY+Jmd0OyZndDsgYW5kIHByb3RvY29scyBpbnZvbHZlZCAod2l0aCBpbiBBUyBvciBvdGhlcndp c2UpIGluIHRoZSBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgKGF0IGxlYXN0IGJyaWVmbHkpLjwvZGl2 Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyB0aGUgYXJjaGl0 ZWN0dXJlIGRyYWZ0IGlzIGRhdGEtcGFuZSBhZ25vc3RpYyBzbyBJIHByZXN1bWUgeW91IHJlZmVy IHRvIGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLjwvZGl2Pg0KPGRpdj4m Z3Q7PC9kaXY+DQo8ZGl2PiZndDsgd2l0aCB0aGUgaXB2NiBkYXRhLXBsYW5lIFNSIGNvbmZsaWN0 cyBhcmUgaW4gZmFjdCBzb2x2ZWQgYnkgaXB2NiA8L2Rpdj4NCjxkaXY+Jmd0OyBhZGRyZXNzaW5n IHRlY2huaXF1ZXMgOy0pPC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyBzLjwvZGl2 Pg0KPGRpdj4mZ3Q7PC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4N CjxkaXY+Jmd0OyZndDsgLS08L2Rpdj4NCjxkaXY+Jmd0OyZndDsgVW1hIEMuPC9kaXY+DQo8ZGl2 PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IEZyb206IHNwcmluZyBbPGEgaHJlZj0ibWFp bHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5v cmc8L2E+XSBPbiBCZWhhbGYgT2YgTGVzIDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBHaW5zYmVyZyAo Z2luc2JlcmcpPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDA0LCAy MDE2IDk6MzggQU08L2Rpdj4NCjxkaXY+Jmd0OyZndDsgVG86IFVtYSBDaHVuZHVyaTsgPGEgaHJl Zj0ibWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20iPmJydW5vLmRlY3JhZW5lQG9yYW5n ZS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5v cmc8L2E+PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBkcmFmdC1n aW5zYmVyZy1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbiAtIFdHIDwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyBhZG9wdGlvbiBjYWxsPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsm Z3Q7IFVtYSDigJM8L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgVG8g cmVzdGF0ZSwgdGhlIHByb2JsZW0gYmVpbmcgYWRkcmVzc2VkIGhlcmUgaXMgdG8gZ3VhcmFudGVl IGNvbnNpc3RlbnQgdXNlIG9mIFNJRHMgaW4gdGhlIGZvcndhcmRpbmcgcGxhbmUgbmV0d29yay13 aWRlIGluIHRoZSBwcmVzZW5jZSBvZiBjb25mbGljdGluZyBhZHZlcnRpc2VtZW50cy4gVGhlIHNl dCBvZiBhZHZlcnRpc2VtZW50cyBpbmNsdWRlcyBib3RoIFNJRHMgYWR2ZXJ0aXNlZCBpbiBwcm90 b2NvbCBwcmVmaXggcmVhY2hhYmlsaXR5DQphZHZlcnRpc2VtZW50cyBhbmQgU1JNUyBhZHZlcnRp c2VtZW50cyBiZWNhdXNlIHByb2JsZW1zIG9jY3VyIGJhc2VkIHVwb24gaW5jb25zaXN0ZW5jaWVz IGluIHdoYXQgaXMgaW5zdGFsbGVkIGluIHRoZSBmb3J3YXJkaW5nIHBsYW5lIG9mIGRpZmZlcmVu dCByb3V0ZXJzLiBJdCBtYXR0ZXJzIG5vdCB3aGV0aGVyIFJvdXRlciBBIHVzZWQgYSBTSUQgYWR2 ZXJ0aXNlZCBieSBhIHByb3RvY29sIHByZWZpeCByZWFjaGFiaWxpdHkgYWR2ZXJ0aXNlbWVudA0K b3IgYnkgYW4gU1JNUyBhZHZlcnRpc2VtZW50IOKAkyB3aGF0IG1hdHRlciBpcyB3aGV0aGVyIHRo ZSBTSUQgdXNlZCBpcyBjb25zaXN0ZW50IHdpdGggd2hhdCB0aGUgbmVpZ2hib3JzIG9mIFJvdXRl ciBBIHVzZS4gU28gc2ltcGx5IGVuc3VyaW5nIHRoYXQgT1NQRiAoZm9yIGV4YW1wbGUpIHJlc29s dmVzIFNJRHMgaW4gYSBjb25zaXN0ZW50IHdheSBkb2VzIG5vdCBmdWxseSBhZGRyZXNzIHRoZSBw cm9ibGVtIHNwYWNlLjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBN b3JlIGlubGluZS48L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgRnJv bTogVW1hIENodW5kdXJpIFs8YSBocmVmPSJtYWlsdG86dW1hLmNodW5kdXJpQGVyaWNzc29uLmNv bSI+bWFpbHRvOnVtYS5jaHVuZHVyaUBlcmljc3Nvbi5jb208L2E+XTwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyBTZW50OiBUdWVzZGF5LCBNYXkgMDMsIDIwMTYgMzo1OSBQTTwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyBUbzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZyk7IDxhIGhyZWY9Im1haWx0bzpicnVuby5k ZWNyYWVuZUBvcmFuZ2UuY29tIj5icnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPC9hPjsgPC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPnNwcmluZ0Bp ZXRmLm9yZzwvYT48L2Rpdj4NCjxkaXY+Jmd0OyZndDsgU3ViamVjdDogUkU6IFtzcHJpbmddIGRy YWZ0LWdpbnNiZXJnLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uIC0gV0cgPC9kaXY+DQo8ZGl2 PiZndDsmZ3Q7IGFkb3B0aW9uIGNhbGw8L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+ Jmd0OyZndDsgTGVzLDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBX aXRoIGFsbCBkdWUgcmVzcGVjdHMsIGNyb3NzIHByb3RvY29sIHZlcmlmaWNhdGlvbiZuYnNwOyBv ZiBwcmVmaXggYW5kIFNJRCBjb25mbGljdHMgYXMgYW4g4oCcYXJjaGl0ZWN0dXJhbCBjaGFuZ2Xi gJ0mbmJzcDsgYW5kIGl0IGNhbiBzZXZlcmVseSBpbXBhY3QgdGhlIGV4aXN0aW5nIGltcGxlbWVu dGF0aW9ucyAoYXQgbGVhc3QgdGhlIG9uZSBJIHdvcmsgb24pLjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0 OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBbTGVzOl0gSXQgaXMgcXVpdGUgY29ycmVjdCDigJMgYW5k IEkgY2FuIGNvbmZpcm0gYmFzZWQgb24gcGVyc29uYWwgZXhwZXJpZW5jZSDigJMgdGhhdCBzdXBw b3J0IGZvciBjb25mbGljdCByZXNvbHV0aW9uIGlzIGEgc2lnbmlmaWNhbnQgZWZmb3J0LjwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBBbHNvIEkgaGF2ZSBjb3VwbGUg b2YgY2FzZXMgd2hlcmUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBpcyBub3QgY2xlYXIg YWJvdXQgcmVzb2x1dGlvbi48L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZn dDsgSU1PLCBmaXJzdCB3ZSBuZWVkIGNsYXJpdHkgd2l0aCBpbiBhIHByb3RvY29sIGluc3RhbmNl IHJlc29sdXRpb24gcnVsZXMgYmVmb3JlIGdvaW5nIHRvIHJlc29sdmUgdGhlIHNhbWUgYWNyb3Nz IHByb3RvY29scyAoSSBtZW50aW9uZWQgZmV3IGNhc2VzIGJlbG93KSAuPC9kaXY+DQo8ZGl2PiZn dDsmZ3Q7IFNlcGFyYXRpb24gb2YgcmVhY2hhYmlsaXR5IGFkdmVydGlzZW1lbnRzIGFuZCBTUk1T IHdvdWxkIGhlbHAg4oCcY3Jvc3MgcHJvdG9jb2zigJ0gdmVyaWZpY2F0aW9uIG9mIHRoZSByYW5n ZXMgYW5kIFNSTVMgaXMgbm90IGFwcGxpY2FibGUgdG8gYWxsIHByb3RvY29scy48L2Rpdj4NCjxk aXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgSW4t bGluZSBbVW1hXTo8L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgLS08 L2Rpdj4NCjxkaXY+Jmd0OyZndDsgVW1hIEMuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8 ZGl2PiZndDsmZ3Q7IEZyb206IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIFs8YSBocmVmPSJtYWls dG86Z2luc2JlcmdAY2lzY28uY29tIj5tYWlsdG86Z2luc2JlcmdAY2lzY28uY29tPC9hPl08L2Rp dj4NCjxkaXY+Jmd0OyZndDsgU2VudDogU2F0dXJkYXksIEFwcmlsIDMwLCAyMDE2IDEwOjExIFBN PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IFRvOiBVbWEgQ2h1bmR1cmk7IDxhIGhyZWY9Im1haWx0bzpi cnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tIj5icnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPC9hPjsg PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYub3JnPC9hPjwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0OyBTdWJqZWN0OiBSRTogW3NwcmluZ10gZHJhZnQtZ2luc2Jlcmctc3By aW5nLWNvbmZsaWN0LXJlc29sdXRpb24gLSBXRyA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgYWRvcHRp b24gY2FsbDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBVbWEg4oCT PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IFdlIGFyZSBpbmRlZWQg ZGVmaW5pbmcgY29uZmxpY3QgcmVzb2x1dGlvbiBhY3Jvc3MgYWxsIHRoZSBTSUQgPC9kaXY+DQo8 ZGl2PiZndDsmZ3Q7IGFkdmVydGlzZW1lbnRzIHJlZ2FyZGxlc3Mgb2Ygc291cmNlIChwcm90b2Nv bCBvciBTUk1TKSDigJM8L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsg W1VtYV06IFdoaWxlIHlvdSBjYW4gdGhlb3JldGljYWxseSBkbyBhbnl0aGluZyBmb3IgY3VycmVu dCBpbXBsZW1lbnRhdGlvbiB0aGlzIGtpbmQgb2YgY3Jvc3MgcHJvdG9jb2wgdmVyaWZpY2F0aW9u IGlzIGEgbmV3IGFyY2hpdGVjdHVyYWwgcmVxdWlyZW1lbnQuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEJlY2F1c2UgaXQgc2VlbXMg 4oCcYSBjZW50cmFsIGVudGl0eeKAnSBuZWVkIHRvIGdhdGhlciBhbGwgZGlmZmVyZW50IHByb3Rv Y29sIGluc3RhbmNlcyBTUk1TIGFkdmVydGlzZW1lbnRzIGFuZCBzaG91bGQgc2V0dGxlIHdpdGgg cmVzb2x1dGlvbi48L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgLSZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBbHNv IG5vdGUgU1JNUyBpcyBub3QgYXBwbGljYWJsZSBmb3IgQkdQIGJ1dCBpdCBzZWVtcyBhbGwgcHJl Zml4IFNJRHMgbmVlZCB0byBiZSB2ZXJpZmllZCZuYnNwOyB3aXRoIElHUCBpbnN0YW5jZXMgU1JN UyBhZHZlcnRpc2VtZW50cy4gSXMgdGhpcyB0cnVlPyBXaGlsZSB0aGUgZG9jdW1lbnQgbW9zdGx5 IHRhbGtzIGFib3V0IHRoZXNlIGFuZCBjb21wYXJlcyB3aXRoIHByZWZpeCBhZHZlcnRpc2VtZW50 LjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBbTGVzOl0gVGhlIGlzc3VlIGlzIHByb3RvY29sIGFnbm9z dGljLjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAtJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFsZ29yaXRobSBw cm9wb3NlZCBuZWVkcyBtb3JlIGNsYXJpdHk6IFRha2UgU2VjdGlvbiAzLjIuNDwvZGl2Pg0KPGRp dj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBvPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IOKAnCZuYnNwOyZuYnNwOyAxLiZuYnNwOyBTbWFsbGVyIHJh bmdlIHdpbnM8L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMi4mbmJzcDsgSVB2NiBlbnRyeSB3aW5zIG92ZXIgSVB2NCBl bnRyeTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyDigKY8 L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsg4oCcPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFdoYXQgaGFwcGVucyBpbiBjYXNl IG9mIHByZWZpeCBjb25mbGljdCBvciBTSUQgY29uZmxpY3Qgd2l0aCBvbmx5IHByZWZpeCBhZHZl cnRpc2VtZW50cyAocmFuZ2UgMSkuJm5ic3A7IFNheSBtdWx0aXBsZSBwcmVmaXhlcyBoYXZlIHNh bWUgU0lEIGluIG9uZSBwcm90b2NvbCBpbnN0YW5jZSBhbmQgaW4gZGlmZmVyZW50IHByb3RvY29s cy48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgSSBzZWUgMiBsZXZlbHMgb2YgcmVzb2x1dGlvbiByZXF1aXJlZCB2 aXouLCBvbmUgYXQgd2l0aGluIHRoZSBwcm90b2NvbCBhbmQgb25lIGFtb25nIHRoZSBwcm90b2Nv bHMuJm5ic3A7IE5vIGRpc2N1c3Npb24gb24gdGhpcy48L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rp dj4NCjxkaXY+Jmd0OyZndDsgW0xlczpdIFRoZSBmdWxsIHNldCBvZiBydWxlcyBzcGVjaWZpZWQg aW4gdGhlIGRyYWZ0IHByb3ZpZGUgZGV0ZXJtaW5pc3RpYyByZXNvbHV0aW9uIGluIGFsbCBjYXNl cy4gWW91IGhhdmUgc25pcHBlZCBvbmx5IHRoZSBmaXJzdCB0d28gcnVsZXMuIElmIGEgcHJlZmVy ZW5jZSBpcyBub3Qgb2J0YWluZWQgYmFzZWQgb24gdGhlIGZpcnN0IHR3byBydWxlcyB5b3UgY29u dGludWUgb24gdG8gcnVsZSAjMywgdGhlbiBydWxlICM0LCBldGMuPC9kaXY+DQo8ZGl2PiZndDsm Z3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNpbWlsYXJseSBpbiBjYXNlIG9mIFNJRCBjb25mbGljdCZuYnNw OyAocmFuZ2UgMSksIGl04oCZcyBub3Qgc3BlY2lmaWVkIHdoaWNoIHByb3RvY29s4oCZcyBTSUQg bmVlZCB0byBiZSBjb25zaWRlcmVkLiZuYnNwOyBBcmUgeW91IGFzc3VtaW5nIHNvbWUgc29ydCBv ZiBBZG1pbiBkaXN0YW5jZSBwbGF5IGEgcm9sZSBpbiByZXNvbHV0aW9uPzwvZGl2Pg0KPGRpdj4m Z3Q7Jmd0OyBbTGVzOl0gTm8g4oCTIGFkbWluIGRpc3RhbmNlIHBsYXlzIG5vIHJvbGUgaGVyZS48 L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbmJzcDsmbmJzcDsgSSBk b27igJl0IHNlZSBhbnkgZGlzY3Vzc2lvbiBpbiB0aGUgZG9jdW1lbnQmbmJzcDsgYW5kIG5lZWRz IG1vcmUgY2xhcml0eSB0aGVyZSB0b28uPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IG8mbmJzcDsmbmJz cDsgQWxzbyB3aGF0IGhhcHBlbnMgaWYgYSBwcmVmaXggb3IgU0lEIGNvbmZsaWN0IGhhcHBlbnMg d2l0aCBTUk1TIHJhbmdlIDEgYW5kIGEgcHJlZml4Jm5ic3A7IGFkdmVydGlzZW1lbnQgKDIgY2Fz ZXMpPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IGEuJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IG9mIG9uZSBwcm90b2NvbCBhbmQ8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgYi4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgbXVsdGlwbGUgcHJvdG9jb2xzPzwvZGl2Pg0KPGRpdj4m Z3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBbTGVzOl0gVGhlIHNvdXJjZSBvZiB0aGUgU0lE IGFkdmVydGlzZW1lbnQgKHdoYXQgcHJvdG9jb2wvcHJvdG9jb2wgaW5zdGFuY2Ugb3Igd2hldGhl ciBpdCBpcyBTUk1TIGJhc2VkKSBwbGF5cyBubyByb2xlLiBUaGUgdGllIGJyZWFrZXIgcnVsZXMg YXMgZGVmaW5lZCBhcmUgY29tcGxldGUgYW5kIHByb3ZpZGUgYSBkZXRlcm1pbmlzdGljIGFuc3dl ciBpbiBhbGwgY2FzZXMuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IElmIHlvdSBiZWxpZXZlIHRoYXQg aXMgbm90IHRydWUgcGxlYXNlIHByb3ZpZGUgYSBzcGVjaWZpYyBleGFtcGxlIHdoZXJlIHlvdSBh cHBseSBhbGwgdGhlIHJ1bGVzIGluIHRoZSBvcmRlciBzcGVjaWZpZWQgYW5kIHN0aWxsIGRvIG5v dCBkZXRlcm1pbmUgdGhlIHByZWZlcnJlZCBlbnRyeS48L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rp dj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgLSZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBPbiB0aGUgYmVsb3cgYXNzdW1w dGlvbjogKFNlY3Rpb24gMy4yLjQpPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IOKAnFRoaXMgaGFzIHRoZSBuaWNlIHByb3BlcnR5IHRoYXQgYSBzaW5nbGUgbWlz Y29uZmlndXJhdG9pb24gb2YgYW4gU1JNUzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBlbnRyeSB3aXRoIGEgbGFy Z2UgcmFuZ2Ugd2lsbCBub3QgYmUgcHJlZmVycmVkIG92ZXIgYSBsYXJnZSBudW1iZXIgb2Y8L2Rp dj4NCjxkaXY+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgU0lEcyBhZHZlcnRpc2VkIGluIHByZWZpeCByZWFjaGFiaWxpdHkgYWR2ZXJ0 aXNlbWVudHMu4oCdPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IFdoaWxlIGFueXRoaW5nIGNhbiBoYXBw ZW4gaW4gdGhlb3J5LCBJIGZvdW5kIGl0IGJpdCBvZGQgdG8gc2VlIHdoeSBTUk1TIGVudHJ5IGlz IGJlaW5nIGFkdmVydGlzZWQgYW5kIGZvciB0aGUgc2FtZSBwcmVmaXgsIFNJRCBpcyBhbHNvIGFk dmVydGlzZWQgdGhyb3VnaCByZWFjaGFiaWxpdHkgYWR2ZXJ0aXNlbWVudHM/PC9kaXY+DQo8ZGl2 PiZndDsmZ3Q7IFRoaXMgaXMgYWdhaW5zdCB0aGUgc3Bpcml0IG9mIFNSTVMgYWR2ZXJ0aXNlbWVu dCwgaXNu4oCZdCBpdD8gV2hpbGUgdGhpcyBjYW4gaGFwcGVuLCBpdCBzZWVtcyB3ZSBhcmUgY2xh aW1pbmcgcmVzb2x1dGlvbiBzb2x1dGlvbiBieSBmb2N1c2luZyBtb3JlIG9uJm5ic3A7IHRoaXMg Y2FzZSBpbiB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudC48L2Rpdj4NCjxkaXY+ Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgW0xlczpdIFRoZXJlIGFyZSB0d28gbGVnaXRp bWF0ZSB1c2UgY2FzZXMgZm9yIFNSTVM6PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2 PiZndDsmZ3Q7IDEpVG8gYWR2ZXJ0aXNlIFNJRHMgZm9yIG5vbi1TUiBjYXBhYmxlIG5vZGVzIDIp QXMgYSBnbG9iYWwgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IHByb3Zpc2lvbmluZyB0b29sPC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IExldOKAmXMgZXhhbWluZSB0aGUg Zmlyc3QgY2FzZS4gSSBoYXZlIGFuIExEUCBlbmFibGVkIG5ldHdvcmsgYW5kIEkgYmVnaW4gaW50 cm9kdWNpbmcgU1IgY2FwYWJsZSBub2Rlcy4gQXQgYSBnaXZlbiBtb21lbnQgaW4gdGltZSBSb3V0 ZXIgQSBpcyBOT1QgU1IgY2FwYWJsZSBhbmQgU1JNUyBhZHZlcnRpc2VtZW50cyBjb3ZlciBwcmVm aXggU0lEcyBmb3IgdGhlIGFkZHJlc3NlcyBhc3NvY2lhdGVkIHdpdGggUm91dGVyIEEuPC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7IEkgdGhlbiB1cGdyYWRlIFJvdXRlciBBIHRvIGJlY29tZSBTUiBjYXBh YmxlLiBCZWNhdXNlIEkgd2FudCB0byBkbyDigJxtYWtlLWJlZm9yZS1icmVha+KAnSBJIGRvIG5v dCBpbW1lZGlhdGVseSByZW1vdmUgdGhlIFNSTVMgYWR2ZXJ0aXNlbWVudHMgY292ZXJpbmcgdGhl IGFkZHJlc3NlcyBhc3NvY2lhdGVkIHdpdGggUm91dGVyIEEuIEkgdXBncmFkZSBBLCBhZGQgY29u ZmlndXJhdGlvbiBvZiBTSURzIGxvY2FsbHkgb24gUm91dGVyIEEsIGFuZA0KdmVyaWZ5IHRoYXQg dGhlIGFkdmVydGlzZW1lbnRzIG9yaWdpbmF0aW5nIGZyb20gcHJvdG9jb2xzIG9uIFJvdXRlciBB IGFyZSBjb3JyZWN0LiBJZiBhbiBpbmNvbnNpc3RlbmN5IGlzIGludHJvZHVjZWQgd2hlbiBjb25m aWd1cmluZyB0aGUgU0lEcyBvbiBSb3V0ZXIgQSB0aGVuIEkgd2lsbCBoYXZlIGFuIFNSTVMgYWR2 ZXJ0aXNlbWVudCBhbmQgYSBwcmVmaXgtcmVhY2hhYmlsaXR5IGFkdmVydGlzZW1lbnQgdGhhdCBj b25mbGljdC4gVW50aWwgdGhlDQpjb25mbGljdCBpcyBjb3JyZWN0ZWQgd2UgdXNlIHRoZSBjb25m bGljdCByZXNvbHV0aW9uIHJ1bGVzIHRvIHByb3ZpZGUgZGV0ZXJtaW5pc3RpYyBmb3J3YXJkaW5n IGJlaGF2aW9yLjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBUaGlz IHRvIG1lIGlzIGEgbm9ybWFsIGFuZCBleHBlY3RlZCB1cGdyYWRlIHNjZW5hcmlvLjwvZGl2Pg0K PGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBU aGlzIGlzIG9uZSBvZiB0aGUgcmVhc29ucyBvZiBteSBmaXJzdCBjb21tZW50IGJlbG93LiBZb3Ug Z290IHRvIHNlcGFyYXRlIHRoZSByZWFjaGFiaWxpdHkgYWR2ZXJ0aXNlbWVudHMgYW5kIFNSTVMg YWR2ZXJ0aXNlbWVudHM7IGFzIGluIHByaW5jaXBsZSB0aGVzZSBhcmUgZGVmaW5lZCBmb3IgZGlm ZmVyZW50IHB1cnBvc2VzLiBJIGRvbuKAmXQgc2VlIHdlJm5ic3A7IG5lZWQgYWxnb3JpdGhtIHRv IHByZWZlciByZWFjaGFiaWxpdHkgYWR2ZXJ0aXNlbWVudA0Kb3ZlciBTUk1TIGFkdmVydGlzZW1l bnQgKGlmIHdlIGRvbuKAmXQgY29tcGFyZSB0aGVzZSAyIGNhdGVnb3JpZXMpLjwvZGl2Pg0KPGRp dj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0OyBbTGVzOl0gSSBkaXNhZ3JlZSDigJMgaG9wZWZ1bGx5IG15IGNvbW1l bnRzIGhhdmUgaGVscGVkIHlvdSB0byB1bmRlcnN0YW5kIHdoeS48L2Rpdj4NCjxkaXY+Jmd0OyZn dDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgTGVzPC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7 IGFzIHRoZSBzZWN0aW9ucyB5b3UgaGF2ZSBxdW90ZWQgY2xlYXJseSBzdGF0ZS48L2Rpdj4NCjxk aXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgV2h5PyBCZWNhdXNlIHdlIG5lZWQgY29u c2lzdGVudCB1c2Ugb2YgU0lEcyBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZS4gRnJvbSBmb3J3YXJk aW5nIHBlcnNwZWN0aXZlIGl0IG1hdHRlcnMgbm90IHdoZXRoZXIgdGhlIFNJRCB3YXMgYWR2ZXJ0 aXNlZCBieSBwcm90b2NvbCBpbnN0YW5jZSAjMSBvciAjMiBvciBieSBhbiBTUk1TLjwvZGl2Pg0K PGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBXaGF0IG1hdHRlcnMgaXMgdGhhdCB0 aGUgU0lEIEkgdXNlIHRvIGRldGVybWluZSB3aGF0IGxhYmVsIEkgaW5zdGFsbCBpbiBteSBmb3J3 YXJkaW5nIHBsYW5lIGlzIHRoZSBzYW1lIFNJRCB0aGF0IG15IG5laWdoYm9ycyB3aWxsIHVzZS4g T3RoZXJ3aXNlIGZvcndhcmRpbmcgd2lsbCBiZSBicm9rZW4uPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7 PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IExlczwvZGl2Pg0K PGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBG cm9tOiBzcHJpbmcgWzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZyI+bWFp bHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIFVtYSA8L2Rpdj4N CjxkaXY+Jmd0OyZndDsgQ2h1bmR1cmk8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgU2VudDogV2VkbmVz ZGF5LCBBcHJpbCAyNywgMjAxNiA0OjMxIFBNPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IFRvOiA8YSBo cmVmPSJtYWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSI+YnJ1bm8uZGVjcmFlbmVAb3Jh bmdlLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciPnNwcmluZ0BpZXRm Lm9yZzwvYT48L2Rpdj4NCjxkaXY+Jmd0OyZndDsgU3ViamVjdDogUmU6IFtzcHJpbmddIGRyYWZ0 LWdpbnNiZXJnLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uIC0gV0cgPC9kaXY+DQo8ZGl2PiZn dDsmZ3Q7IGFkb3B0aW9uIGNhbGw8L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0 OyZndDsgRGVhciBBdXRob3JzLDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyBIYXZlIGZldyBjb21tZW50cyBvbiB0aGUgZHJhZnQ6PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7 PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IDEuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFzIEkgaW5kaWNhdGVk IGR1cmluZyBtZWV0aW5nIC0gSSBhbSBub3Qgc3VyZSB3aHkgd2UgaGF2ZSB0byBjbHViJm5ic3A7 IHZlcmlmaWNhdGlvbiBvZiBTSURzIGFkdmVydGlzZWQgdGhyb3VnaCByZWd1bGFyIHByb3RvY29s IHJlYWNoYWJpbGl0eTwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwcmVmaXhlcyBhbmQgdGhlIHJhbmdlcyBhZHZlcnRpc2Vk IHRocm91Z2ggJ01hcHBpbmcgU2VydmVyJyZuYnNwOyAoU1JNUykuIEkgZGlkbid0IHNlZSBhbnkg Y29tcGVsbGluZyByZWFzb24gdG8gZG8gdGhpcy48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU0lEcyBhZHZlcnRp c2VkIHRocm91Z2ggcmVhY2hhYmlsaXR5IHByZWZpeGVzIGRvZXNuJ3QgaGF2ZSByYW5nZXMgdW5s aWtlIFNSTVMgYWR2ZXJ0aXNlbWVudHMuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEFzIFNSTVMgYWR2ZXJ0aXNl bWVudHMgYXJlIHByaW1hcmlseSBmb3Igbm9kZXMgd2hpY2ggYXJlIG5vdCBTUiBjYXBhYmxlIGFu ZCZuYnNwOyBJIGZlZWwgd2Ugc2hvdWxkIG5vdCBtaXggdGhpcyB3aXRoIG5vZGVzIHdoaWNoIGFy ZSBTUiBjYXBhYmxlLjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGlz IGlzb2xhdGlvbiBoZWxwcyByZXN0cmljdGluZyB0aGUgcmVzb2x1dGlvbiB3b3JrIHByaW1hcmls eSBmb3IgbXVsdGlwbGUgU1JNUyBlbnRyaWVzIGFkdmVydGlzZWQgdGhyb3VnaCBvbmUgbm9kZSBv ciBtdWx0aXBsZSBub2Rlcy48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgU1JNUyBhZHZlcnRpc2VtZW50cyBhcmUgaW5kZWVk IGxpdHRsZSBiaXQgdW5pcXVlIGluIHRoYXQgeW91IGFyZSBhZHZlcnRpc2luZyAmcXVvdDtjb25m aWd1cmF0aW9uJnF1b3Q7IG9uIGJlaGFsZiBvZiBub2RlIFggZnJvbSBub2RlIFk8L2Rpdj4NCjxk aXY+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg d2l0aCByYW5nZXMgKGJvdGggcHJlZml4IHJhbmdlcyBhbmQgU0lEIHJhbmdlcykuPC9kaXY+DQo8 ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IDIu PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFJlZ2FyZGluZyZuYnNwOyB0aGUgc2NvcGUgb2YgY29uZmxpY3QgcmVzb2x1dGlv bjo8L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+ Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg U2VjdGlvbiAxPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7ICZxdW90OyZuYnNwOyZuYnNwOyBUaGUgcHJvYmxlbSB0byBiZSBhZGRyZXNzZWQg aXMgcHJvdG9jb2wgaW5kZXBlbmRlbnQgaS5lLiwgc2VnbWVudDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyByZWxhdGVkIGFkdmVydGlzZW1lbnRzIG1heSBiZSBvcmlnaW5hdGVkIGJ5IG11bHRpcGxl IG5vZGVzIHVzaW5nPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRpZmZlcmVudCBwcm90b2NvbHMg YW5kIHlldCB0aGUgY29uZmxpY3QgcmVzb2x1dGlvbiBNVVNUIGJlIHRoZSBzYW1lPC9kaXY+DQo8 ZGl2PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IG9uIGFsbCBub2RlcyByZWdhcmRsZXNzIG9mIHRoZSBwcm90b2NvbCB1 c2VkIHRvIHRyYW5zcG9ydCB0aGU8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYWR2ZXJ0aXNlbWVu dHMuJnF1b3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlY3Rpb24g My4yLjg8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJnF1b3Q7Jm5ic3A7Jm5ic3A7IG8m bmJzcDsgSW4gY2FzZXMgd2hlcmUgbXVsdGlwbGUgcm91dGluZyBwcm90b2NvbHMgYXJlIGluIHVz ZSBtYXBwaW5nPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IGVudHJpZXMgYWR2ZXJ0aXNlZCBieSBhbGwgcm91dGluZyBwcm90b2Nv bHMgTVVTVCBiZSBpbmNsdWRlZC4mcXVvdDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxk aXY+Jmd0OyZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhp cyBzb3VuZHMgbGlrZSB3ZSBhcmUgc2Vla2luZyB0byByZXNvbHZlIGNvbmZsaWN0aW5nIGVudHJp ZXMgb3V0c2lkZSBhbmQgYWNyb3NzIHRoZSBwcm90b2NvbHM/PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEVhY2ggSUdQIGhhcyBz ZXBhcmF0ZSBtZWNoYW5pc20gZm9yIGFkdmVydGlzaW5nIG1hcHBpbmcgZW50cnkgYW5kIEkgdGhp cyBpcyBub3QgY2xlYXIgd2l0aCB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBkcmFmdCBob3cg d2UgY2FuIGNyb3NzIHZlcmlmeSBTSUQvUHJlZml4IGNvbmZsaWN0IGFjcm9zcyZuYnNwOyB0aGUg cHJvdG9jb2wuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7IENhbiB5b3UgY2xhcmlmeSB0aGlzPzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2 Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyAtLTwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyBVbWEgQy48L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rp dj4NCjxkaXY+Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08L2Rpdj4NCjxkaXY+ Jmd0OyZndDsgRnJvbTogc3ByaW5nIFs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0 Zi5vcmciPm1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiA8 L2Rpdj4NCjxkaXY+Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5n ZS5jb20iPmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208L2E+PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7 IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNCwgMjAxNiAxMjo1NSBBTTwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyBUbzogPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYub3Jn PC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3NwcmluZ10gZHJhZnQtZ2lu c2Jlcmctc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24gLSBXRyA8L2Rpdj4NCjxkaXY+Jmd0OyZn dDsgYWRvcHRpb24gY2FsbDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0 OyZndDsgRnJvbTombmJzcDsgPGEgaHJlZj0ibWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5j b20iPmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb208L2E+ICZndDsgU2VudDogVGh1cnNkYXksIEFw cmlsIDE0LCAyMDE2PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyA5OjUxIEFNPC9kaXY+DQo8ZGl2 PiZndDsmZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsgRGVhciBXRyw8L2Rpdj4NCjxk aXY+Jmd0OyZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyBBcyB3ZSBkaXNjdXNzZWQg YXQgb3VyIG1lZXRpbmcgbGFzdCB3ZWVrLCB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIGhhcyA8L2Rp dj4NCjxkaXY+Jmd0OyZndDsmZ3Q7IGJlZW4gcmVxdWVzdGVkIGZvciBkcmFmdC1naW5zYmVyZy1z cHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbi48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7IFBsZWFz ZSByZXBseSB0byB0aGUgbGlzdCB3aXRoIHlvdXIgY29tbWVudHMsIGluY2x1ZGluZyBhbHRob3Vn aCBub3QgPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyBsaW1pdGVkIHRvIHdoZXRoZXIgb3Igbm90 IHlvdSBzdXBwb3J0IGFkb3B0aW9uLjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4m Z3Q7Jmd0OyBXZSB3aWxsIGVuZCB0aGUgY2FsbCBvbiBBcHJpbCAyOSwgMjAxNi48L2Rpdj4NCjxk aXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7 IFRoYW5rcyw8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0 OyAtLUpvaG4gYW5kIEJydW5vPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OzwvZGl2Pg0KPGRpdj4m Z3Q7Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7 Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0 OyBfX19fXzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7 IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu Zm9ybWF0aW9ucyA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7IGNvbmZpZGVudGllbGxlcyBvdSBw cml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIDwvZGl2Pg0KPGRpdj4mZ3Q7 Jmd0OyZndDsgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24u IFNpIHZvdXMgYXZleiByZWN1IDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSA8L2Rp dj4NCjxkaXY+Jmd0OyZndDsmZ3Q7IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50 ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsg ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVz cG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lm aWUuIE1lcmNpLjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsm Z3Q7IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciA8L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7IHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IDwvZGl2Pg0KPGRp dj4mZ3Q7Jmd0OyZndDsgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0 aG9yaXNhdGlvbi48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7IElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciA8L2Rpdj4NCjxk aXY+Jmd0OyZndDsmZ3Q7IGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7Jmd0OyBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IDwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0 OyZndDsgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48L2Rpdj4NCjxk aXY+Jmd0OyZndDsmZ3Q7IFRoYW5rIHlvdS48L2Rpdj4NCjxkaXY+Jmd0OyZndDsmZ3Q7PC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsgc3ByaW5nIG1haWxpbmcgbGlzdDwv ZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+ c3ByaW5nQGlldGYub3JnPC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyZndDsgPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmciPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0Ozwv ZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2Rpdj4NCjxkaXY+Jmd0OyZndDsgXyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L2Rpdj4N CjxkaXY+Jmd0OyZndDs8L2Rpdj4NCjxkaXY+Jmd0OyZndDsgQ2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGll bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2Vz LCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVj dSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0 ZXVyDQpldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVz c2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVy ZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+ DQo8ZGl2PiZndDsmZ3Q7IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHBy b3RlY3RlZCBieSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48L2Rpdj4NCjxk aXY+Jmd0OyZndDsgQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJs ZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lm aWVkLjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyBUaGFuayB5b3UuPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7 PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IHNwcmluZyBtYWlsaW5nIGxpc3Q8L2Rp dj4NCjxkaXY+Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5n QGlldGYub3JnPC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zcHJpbmc8L2E+PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7PC9kaXY+DQo8ZGl2 PiZndDsmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PC9kaXY+DQo8ZGl2PiZndDsmZ3Q7IHNwcmluZyBtYWlsaW5nIGxpc3Q8L2Rpdj4NCjxkaXY+Jmd0 OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYub3JnPC9h PjwvZGl2Pg0KPGRpdj4mZ3Q7Jmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NwcmluZyI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zcHJpbmc8L2E+PC9kaXY+DQo8ZGl2PiZndDs8L2Rpdj4NCjxkaXY+Jmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvZGl2Pg0KPGRpdj4mZ3Q7IHNw cmluZyBtYWlsaW5nIGxpc3Q8L2Rpdj4NCjxkaXY+Jmd0OyA8YSBocmVmPSJtYWlsdG86c3ByaW5n QGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PC9kaXY+DQo8ZGl2PiZndDsgPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmciPmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nPC9hPjwvZGl2Pg0KPGRpdj4mZ3Q7PC9k aXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_1B502206DFA0C544B7A60469152008635BCE58ABeusaamb106erics_-- From nobody Thu May 12 23:55:11 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9727812D0F3; Thu, 12 May 2016 23:55:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160513065502.31676.21172.idtracker@ietfa.amsl.com> Date: Thu, 12 May 2016 23:55:02 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-conflict-resolution-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 06:55:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking of the IETF. Title : Segment Routing Conflict Resolution Authors : Les Ginsberg Peter Psenak Stefano Previdi Martin Pilka Filename : draft-ietf-spring-conflict-resolution-00.txt Pages : 13 Date : 2016-05-12 Abstract: In support of Segment Routing (SR) routing protocols advertise a variety of identifiers used to define the segments which direct forwarding of packets. In cases where the information advertised by a given protocol instance is either internally inconsistent or conflicts with advertisements from another protocol instance a means of achieving consistent forwarding behavior in the network is required. This document defines the policies used to resolve these occurrences. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-conflict-resolution/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-conflict-resolution-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri May 13 00:31:09 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231C512D12A for ; Fri, 13 May 2016 00:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.517 X-Spam-Level: X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eEjAn32USqdv for ; Fri, 13 May 2016 00:31:04 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB85D12D104 for ; Fri, 13 May 2016 00:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21174; q=dns/txt; s=iport; t=1463124664; x=1464334264; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=rs28+fg/FK8phmPMl/qROi0izgxiMrnXkWhcQI6yblY=; b=N5zfFpWL9ctiK9TWbRIagahiIEn3Oc634YDLUxmzaBemG1j+RhA1PaiD shCbtySS46Dup8+j9XDjjo3n2dftE9jpmcuePFMMXEA+ekBsOUsjcM55z fMOTsd76tdht//51Wa5Ek4nTeApwHBn1QONgBpIha1iqG1JesvHwhJcy2 s=; X-IronPort-AV: E=Sophos;i="5.24,612,1454976000"; d="scan'208";a="635622968" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 May 2016 07:31:02 +0000 Received: from [10.60.140.52] (ams-ppsenak-nitro3.cisco.com [10.60.140.52]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4D7V1wY021703; Fri, 13 May 2016 07:31:01 GMT Message-ID: <573582B5.1010803@cisco.com> Date: Fri, 13 May 2016 09:31:01 +0200 From: Peter Psenak User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Uma Chunduri , "Stefano Previdi (sprevidi)" References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10411_1460620508_570F4CDC_10411_96_23_53C29892C857584299CBF5D05346208A0F86E45F@OPEXCLILM21.corporate.adroot.infra.ftgroup> <1B502206DFA0C544B7A6046915200863580C54E9@eusaamb105.ericsson.se> <0468fb2fe35841668bc35606e988074c@XCH-ALN-001.cisco.com> <1B502206DFA0C544B7A60469152008635BCD31AB@eusaamb106.ericsson.se> <445eeb6f8f12480f90e941a81eeaafc7@XCH-ALN-001.cisco.com> <1B502206DFA0C544B7A60469152008635BCDFEFB@eusaamb106.ericsson.se> <1B502206DFA0C544B7A60469152008635BCE586E@eusaamb106.ericsson.se> <5734C54A.2050102@cisco.com> <1B502206DFA0C544B7A60469152008635BCE58AB@eusaamb106.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008635BCE58AB@eusaamb106.ericsson.se> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "Les Ginsberg \(ginsberg\)" , "spring@ietf.org" , "bruno.decraene@orange.com" Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 07:31:08 -0000 Uma, I don't know whether you need a text in the draft/RFC to use some functionality one way or the other. The fact is that SRMS is a SID provisioning tool. You can use it for SR/LDP interoperability, but you can also use it in a SR only network to provide SIDs from a central place instead of configuring them on each device. There is nothing that prevents you to use it one way or the other. The fact that SRMS is defined in the SR/LDP interop drfat does not mean it is restricted to be used for that purpose. I let authors of the SR architecture drafts to decide whether they want to add the text. As an author of the OSPF SR draft, I do not see anything in the text that you put below that would contradict what I'm saying here. thanks, Peter On 5/12/16 20:19 , Uma Chunduri wrote: > Peter, > > as a matter of fact, SRMS is a SID provisioning tool, whether > you like it or not. > It's not about your or my linking - I was talking about what's the > defined scope so far (architecture doc or protocol docs) > and how you want to extend the scope. > Well, if you want to extend the current scope of SRMS as a "">2)As a > global provisioning tool" - > Plz. do so but not while providing conflict resolution solution. > > It provides all the functionality that is required for > such provisioning tool. > >You can not restrict its usage to SR/LDP interop case. > I didn't restrict anything - Plz. see SRMS stuff so far: > 1. > _https://tools.ietf.org/html/draft-ietf-spring-segment-routing-08#section-3.6_ > > /" //3.6.1. Mapping Server/ > ///A Remote-Binding SID S advertised by the mapping server M for remote/ > ///prefix R attached to non-SR-capable node N signals the same/ > ///information as if N had advertised S as a Prefix-SID. Further/ > ///details are described in the SR/LDP interworking procedures/ > ///([I-D.ietf-spring-segment-routing-ldp-interop].//"/ > 2. ISIS: > _https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-06#section-2.4_ > > /" //This functionality is called the/ > /////'Mapping Server' and it's used when, in a heterogeneous network,/ > ///////not all nodes are capable of advertising their own SIDs/Labels.//"/ > 3. OSPF: > _https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions-08#section-4_ > > /"// In some cases it is useful to advertise attributes for a range of/ > ///prefixes. The Segment Routing Mapping Server, which is described in/ > ///[//I-D.filsfils-spring-segment-routing-ldp-interop/ > /], > is an example/ > ///where we need a single advertisement to advertise SIDs for multiple/ > ///prefixes from a contiguous address range.//"/ > Again, plz. extend the scope first and consider the same in resolution > solution. I am fine with it. > -- > Uma C. > -----Original Message----- > From: Peter Psenak [mailto:ppsenak@cisco.com] > Sent: Thursday, May 12, 2016 11:03 AM > To: Uma Chunduri; Stefano Previdi (sprevidi) > Cc: Les Ginsberg (ginsberg); spring@ietf.org; bruno.decraene@orange.com > Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG > adoption call > Hi Uma, > On 5/12/16 19:49 , Uma Chunduri wrote: >> Stefano, >> >> Thanks for your response. >> >> > using a SRMS for advertising SID on behalf of SR capable nodes does not introduce any change in the SR architecture so not >> > sure what we need to document here. >> >> My point below: We are creating a conflict resolution solution for a non-existing requirement of using SRMS viz., ">2)As a global provisioning tool". >> From your statement above, it seems you have less interest to make this as a requirement/scope of SRMS; I am more aligned in that path.... > as a matter of fact, SRMS is a SID provisioning tool, whether you like > it or not. It provides all the functionality that is required for such > provisioning tool. You can not restrict its usage to SR/LDP interop case. > thanks, > Peter >> >> On the second point: >> >> > the architecture draft is data-pane agnostic so I presume you refer to draft-ietf-spring-segment-routing-mpls. >> >> AFAIS,https://tools.ietf.org/html/draft-ietf-spring-segment-routing-08 talks > about both data planes right from abstract to multiple places (which it > ought to). >> I leave this to you/WG on where you want to document this -but IMO >> conflict resolution "solution document" in the current form potentially introducing fundamental requirements to the system like cross protocol verification (with in/across AS). Perhaps some discussion should be there in data plane document then. >> >> -- >> Uma C. >> >> >> -----Original Message----- >> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >> Sent: Wednesday, May 11, 2016 4:46 AM >> To: Uma Chunduri >> Cc: Les Ginsberg (ginsberg);bruno.decraene@orange.com ; >>spring@ietf.org >> Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG >> adoption call >> >> >>> On May 6, 2016, at 10:16 PM, Uma Chunduri > wrote: >>> >>> Les, >>> >>> 2 quick things. >>> >>> 1. >>> >[Les:] There are two legitimate use cases for SRMS: >>> >1)To advertise SIDs for non-SR capable nodes >>> >2)As a global provisioning tool >>> I am hearing #2 for the first time. I don’t see this either discussed earlier in the WG list or captured in architecture document >>>https://tools.ietf.org/html/draft-ietf-spring-segment-routing-07. Even > in the protocol extensions document for example >>>https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-06#section-2.4 > we always discussed this from non-SR >>> capable nodes PoV. So I request to add this in architecture document before factoring this for solution in conflict resolution. >> >> >> using a SRMS for advertising SID on behalf of SR capable nodes does not introduce any change in the SR architecture so not sure what we need to document here. >> >> >> >>> >>> 2. Also this is the first time ever we have a requirement for cross protocols verification we ought to discuss the implications of this >>> and protocols involved (with in AS or otherwise) in the architecture document (at least briefly). >> >> >> the architecture draft is data-pane agnostic so I presume you refer to draft-ietf-spring-segment-routing-mpls. >> >> with the ipv6 data-plane SR conflicts are in fact solved by ipv6 >> addressing techniques ;-) >> >> s. >> >> >>> >>> -- >>> Uma C. >>> >>> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les >>> Ginsberg (ginsberg) >>> Sent: Wednesday, May 04, 2016 9:38 AM >>> To: Uma Chunduri;bruno.decraene@orange.com ; > spring@ietf.org >>> Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG >>> adoption call >>> >>> Uma – >>> >>> To restate, the problem being addressed here is to guarantee consistent use of SIDs in the forwarding plane network-wide in the presence of conflicting advertisements. The set of advertisements includes both SIDs advertised in protocol prefix reachability advertisements and SRMS advertisements because problems occur based > upon inconsistencies in what is installed in the forwarding plane of > different routers. It matters not whether Router A used a SID advertised > by a protocol prefix reachability advertisement or by an SRMS > advertisement – what matter is whether the SID used is consistent with > what the neighbors of Router A use. So simply ensuring that OSPF (for > example) resolves SIDs in a consistent way does not fully address the > problem space. >>> >>> More inline. >>> >>> From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] >>> Sent: Tuesday, May 03, 2016 3:59 PM >>> To: Les Ginsberg (ginsberg);bruno.decraene@orange.com ; >>>spring@ietf.org >>> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution - WG >>> adoption call >>> >>> Les, >>> >>> With all due respects, cross protocol verification of prefix and SID conflicts as an “architectural change” and it can severely impact the existing implementations (at least the one I work on). >>> >>> [Les:] It is quite correct – and I can confirm based on personal experience – that support for conflict resolution is a significant effort. >>> >>> Also I have couple of cases where current version of the draft is not clear about resolution. >>> >>> IMO, first we need clarity with in a protocol instance resolution rules before going to resolve the same across protocols (I mentioned few cases below) . >>> Separation of reachability advertisements and SRMS would help “cross protocol” verification of the ranges and SRMS is not applicable to all protocols. >>> >>> >>> In-line [Uma]: >>> >>> -- >>> Uma C. >>> >>> From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] >>> Sent: Saturday, April 30, 2016 10:11 PM >>> To: Uma Chunduri;bruno.decraene@orange.com ; > spring@ietf.org >>> Subject: RE: [spring] draft-ginsberg-spring-conflict-resolution - WG >>> adoption call >>> >>> Uma – >>> >>> We are indeed defining conflict resolution across all the SID >>> advertisements regardless of source (protocol or SRMS) – >>> >>> [Uma]: While you can theoretically do anything for current implementation this kind of cross protocol verification is a new architectural requirement. >>> Because it seems “a central entity” need to gather all different protocol instances SRMS advertisements and should settle with resolution. >>> >>> - Also note SRMS is not applicable for BGP but it seems all prefix SIDs need to be verified with IGP instances SRMS advertisements. Is this true? While the document mostly talks about these and compares with prefix advertisement. >>> [Les:] The issue is protocol agnostic. >>> >>> - Algorithm proposed needs more clarity: Take Section 3.2.4 >>> >>> o >>> “ 1. Smaller range wins >>> >>> 2. IPv6 entry wins over IPv4 entry >>> … >>> “ >>> What happens in case of prefix conflict or SID conflict with only prefix advertisements (range 1). Say multiple prefixes have same SID in one protocol instance and in different protocols. >>> I see 2 levels of resolution required viz., one at within the protocol and one among the protocols. No discussion on this. >>> >>> [Les:] The full set of rules specified in the draft provide deterministic resolution in all cases. You have snipped only the first two rules. If a preference is not obtained based on the first two rules you continue on to rule #3, then rule #4, etc. >>> >>> Similarly in case of SID conflict (range 1), it’s not specified which protocol’s SID need to be considered. Are you assuming some sort of Admin distance play a role in resolution? >>> [Les:] No – admin distance plays no role here. >>> >>> I don’t see any discussion in the document and needs more clarity there too. >>> o Also what happens if a prefix or SID conflict happens with SRMS range 1 and a prefix advertisement (2 cases) >>> a. of one protocol and >>> b. multiple protocols? >>> >>> [Les:] The source of the SID advertisement (what protocol/protocol instance or whether it is SRMS based) plays no role. The tie breaker rules as defined are complete and provide a deterministic answer in all cases. >>> If you believe that is not true please provide a specific example where you apply all the rules in the order specified and still do not determine the preferred entry. >>> >>> >>> - On the below assumption: (Section 3.2.4) >>> “This has the nice property that a single misconfiguratoion of an SRMS >>> entry with a large range will not be preferred over a large number of >>> SIDs advertised in prefix reachability advertisements.” >>> While anything can happen in theory, I found it bit odd to see why SRMS entry is being advertised and for the same prefix, SID is also advertised through reachability advertisements? >>> This is against the spirit of SRMS advertisement, isn’t it? While this can happen, it seems we are claiming resolution solution by focusing more on this case in the current version of the document. >>> >>> [Les:] There are two legitimate use cases for SRMS: >>> >>> 1)To advertise SIDs for non-SR capable nodes 2)As a global >>> provisioning tool >>> >>> Let’s examine the first case. I have an LDP enabled network and I begin introducing SR capable nodes. At a given moment in time Router A is NOT SR capable and SRMS advertisements cover prefix SIDs for the addresses associated with Router A. >>> I then upgrade Router A to become SR capable. Because I want to do “make-before-break” I do not immediately remove the SRMS advertisements covering the addresses associated with Router A. I upgrade A, add configuration of SIDs locally on Router A, and verify that the advertisements originating from protocols on Router A > are correct. If an inconsistency is introduced when configuring the SIDs > on Router A then I will have an SRMS advertisement and a > prefix-reachability advertisement that conflict. Until the conflict is > corrected we use the conflict resolution rules to provide deterministic > forwarding behavior. >>> >>> This to me is a normal and expected upgrade scenario. >>> >>> >>> This is one of the reasons of my first comment below. You got to separate the reachability advertisements and SRMS advertisements; as in principle these are defined for different purposes. I don’t see we need algorithm to prefer reachability advertisement over SRMS advertisement (if we don’t compare these 2 categories). >>> >>> >>> >>> [Les:] I disagree – hopefully my comments have helped you to understand why. >>> >>> Les >>> >>> >>> as the sections you have quoted clearly state. >>> >>> Why? Because we need consistent use of SIDs in the forwarding plane. From forwarding perspective it matters not whether the SID was advertised by protocol instance #1 or #2 or by an SRMS. >>> >>> What matters is that the SID I use to determine what label I install in my forwarding plane is the same SID that my neighbors will use. Otherwise forwarding will be broken. >>> >>> Les >>> >>> >>> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Uma >>> Chunduri >>> Sent: Wednesday, April 27, 2016 4:31 PM >>> To:bruno.decraene@orange.com ; > spring@ietf.org >>> Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG >>> adoption call >>> >>> Dear Authors, >>> >>> Have few comments on the draft: >>> >>> 1. >>> As I indicated during meeting - I am not sure why we have to club verification of SIDs advertised through regular protocol reachability >>> prefixes and the ranges advertised through 'Mapping Server' (SRMS). I didn't see any compelling reason to do this. >>> SIDs advertised through reachability prefixes doesn't have ranges unlike SRMS advertisements. >>> As SRMS advertisements are primarily for nodes which are not SR capable and I feel we should not mix this with nodes which are SR capable. >>> >>> This isolation helps restricting the resolution work primarily for multiple SRMS entries advertised through one node or multiple nodes. >>> SRMS advertisements are indeed little bit unique in that you are advertising "configuration" on behalf of node X from node Y >>> with ranges (both prefix ranges and SID ranges). >>> >>> >>> 2. >>> Regarding the scope of conflict resolution: >>> >>> >>> Section 1 >>> >>> " The problem to be addressed is protocol independent i.e., segment >>> related advertisements may be originated by multiple nodes using >>> different protocols and yet the conflict resolution MUST be the same >>> on all nodes regardless of the protocol used to transport the >>> advertisements." >>> >>> Section 3.2.8 >>> " o In cases where multiple routing protocols are in use mapping >>> entries advertised by all routing protocols MUST be included." >>> >>> This sounds like we are seeking to resolve conflicting entries outside and across the protocols? >>> Each IGP has separate mechanism for advertising mapping entry and I this is not clear with the current version of the draft how we can cross verify SID/Prefix conflict across the protocol. >>> Can you clarify this? >>> >>> >>> -- >>> Uma C. >>> >>> >>> -----Original Message----- >>> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of >>>bruno.decraene@orange.com >>> Sent: Thursday, April 14, 2016 12:55 AM >>> To:spring@ietf.org >>> Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG >>> adoption call >>> >>>> From:bruno.decraene@orange.com > Sent: > Thursday, April 14, 2016 >>>> 9:51 AM >>>> >>>> Dear WG, >>>> >>>> As we discussed at our meeting last week, working group adoption has >>>> been requested for draft-ginsberg-spring-conflict-resolution. >>>> Please reply to the list with your comments, including although not >>>> limited to whether or not you support adoption. >>> >>> We will end the call on April 29, 2016. >>> >>> >>>> Thanks, >>>> >>>> --John and Bruno >>>> >>>> >>>> >>>> __________________________________________________________ >>>> __________________________________________________________ >>>> _____ >>>> >>>> Ce message et ses pieces jointes peuvent contenir des informations >>>> confidentielles ou privilegiees et ne doivent donc pas etre >>>> diffuses, exploites ou copies sans autorisation. Si vous avez recu >>>> ce message par erreur, veuillez le signaler a l'expediteur et le >>>> detruire ainsi que les pieces jointes. Les messages electroniques >>>> etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>>> >>>> This message and its attachments may contain confidential or >>>> privileged information that may be protected by law; they should not >>>> be distributed, used or copied without authorisation. >>>> If you have received this email in error, please notify the sender >>>> and delete this message and its attachments. >>>> As emails may be altered, Orange is not liable for messages that >>>> have been modified, changed or falsified. >>>> Thank you. >>>> >>>> _______________________________________________ >>>> spring mailing list >>>>spring@ietf.org >>>>https://www.ietf.org/mailman/listinfo/spring >>> >>> _____________________________________________________________________ >>> _ ___________________________________________________ >>> >>> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, Orange decline toute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >>> >>> This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender and delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >>> Thank you. >>> >>> _______________________________________________ >>> spring mailing list >>>spring@ietf.org >>>https://www.ietf.org/mailman/listinfo/spring >>> >>> _______________________________________________ >>> spring mailing list >>>spring@ietf.org >>>https://www.ietf.org/mailman/listinfo/spring >> >> _______________________________________________ >> spring mailing list >>spring@ietf.org >>https://www.ietf.org/mailman/listinfo/spring >> From nobody Fri May 13 00:59:19 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0DF12D149; Fri, 13 May 2016 00:59:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TssXmMNYR081; Fri, 13 May 2016 00:59:09 -0700 (PDT) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3AD012D14D; Fri, 13 May 2016 00:59:08 -0700 (PDT) Received: by mail-pf0-x22f.google.com with SMTP id c189so41286659pfb.3; Fri, 13 May 2016 00:59:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=to:from:subject:message-id:date:user-agent:mime-version; bh=KrdSGH9cHHIotRJd3SinZOFAowumH+zozTbM7nAMuWA=; b=Cm07+Ww9WFa5SHu0Hn57H+NtG1ouLgIG4JX8bf8ebs+wUxhH/YKnX1EyHBoAi42QE4 tAbFNVnxPosKI7jg/qYYbcQn8zhLXokJ/WcTSLVr7jqrHgM83IDKmLl6TzK2AkwafUgW 6R0nsdJgbAGGgwqyPTMtY+MajLs6x2twk4dvyynQzd/G8PRPtI5OZqbU8iJzFl71tLLh UZEdDU9WCbp1d1XJ+gZIzpe+Mdbn6agHc2P9kLK0fSV3WsYX2eO4/dMD0FsDzn/k+54p rKHpL3vag+5LO3DZa5YapSP0I38UfOi5sdvC2r9AvuTNsXByHJGOtzeXMC4879Lc8gfS 8bJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=KrdSGH9cHHIotRJd3SinZOFAowumH+zozTbM7nAMuWA=; b=UxjqfwyI5pSbxiiauLyzbavWzkB4x2xi9+DAUIoeb9sJ4fpFsFj8JY4inKrhTCZaXG cHuEGRR1HwYsetP13U2f8gGkAg7Ej4tMn6VmdlVqcBAeEqIVe7z4FyEX4GySjxSXhsar Mlb0804tNbl8WJs6hPC/LtiZOsj0sjBtXHrbLVUJOQsHmsa/uxVCM22x48zPVWjk4kpk Q2XbakCX/DJWNoniOSTK1QXgwXzvv2G2SEQmOQ1b8Ws6EF317r/1yM6osvnxKJxc9VS2 oW+FxBBQaGYPBNIn7wlMGGO2UEIjGjZTcpZBugELum6cg50c32RX9Ov4aFBt9f2YwPCr lPtA== X-Gm-Message-State: AOPr4FU/oQN4csgGs9DipaIzZPQVplrn+kuM5AkqD8e2kk+tz46f+YyQDTvn/bLa0z4DAg== X-Received: by 10.98.17.9 with SMTP id z9mr21093686pfi.40.1463126348073; Fri, 13 May 2016 00:59:08 -0700 (PDT) Received: from [192.168.1.235] ([103.6.157.63]) by smtp.gmail.com with ESMTPSA id h5sm25155729pat.0.2016.05.13.00.59.06 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 13 May 2016 00:59:07 -0700 (PDT) To: spring-chairs@ietf.org, draft-psarkar-spring-mpls-anycast-segments.authors@ietf.org, spring@ietf.org From: Pushpasis Sarkar Message-ID: <57358948.8060302@gmail.com> Date: Fri, 13 May 2016 13:29:04 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------090206060501040409050608" Archived-At: Subject: [spring] WG Adoption for draft-psarkar-spring-mpls-anycast-segments X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 May 2016 07:59:12 -0000 This is a multi-part message in MIME format. --------------090206060501040409050608 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi Chairs, We have presented this draft in IETF-93 and IETF-94 and have received quite a good amount of interests in it. Also the draft seems to be stable for quite a time and the authors fill that it is in good shape for WG adoption. Hence request you to consider initiating the WG Adoption call for the above draft. Thanks and Best Regards -Pushpasis --------------090206060501040409050608 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Hi Chairs,

We have presented this draft in IETF-93 and IETF-94 and have received quite a good amount of interests in it. Also the draft seems to be stable for quite a time and the authors fill that it is in good shape for WG adoption.

Hence request you to consider initiating the WG Adoption call for the above draft.

Thanks and Best Regards
-Pushpasis
--------------090206060501040409050608-- From nobody Sat May 14 10:03:55 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A023212D16B for ; Sat, 14 May 2016 10:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.047 X-Spam-Level: X-Spam-Status: No, score=-14.047 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kx5kLX6zQ4nz for ; Sat, 14 May 2016 10:03:51 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3495412D163 for ; Sat, 14 May 2016 10:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31980; q=dns/txt; s=iport; t=1463245431; x=1464455031; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zuwYLrBhqQGkiy1l9Uy3Hsdla7Thb7UgMBoR8zylv7k=; b=V5f80MA89EQnIfa/oluYFeTe9FyLzKISgbqz3VHMp9CmiB0hx0BNNikZ YzEyVlK0lud4M71DV9UNKn2y2iddvHkzqUXjchR2l9KssARnZ5/qbmePw ItuaIKHS6I6fjswtIHOQonWcM2vv1CvF+1IfL7JJAtXNaflBIGqulWzy9 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B8AgAZWjdX/4kNJK1egzdVfga5XgENg?= =?us-ascii?q?XIEFwuFJUoCHIEGOBQBAQEBAQEBZSeEQgEBAQQBAQEXCRE6CwwEAgEIEQEDAQE?= =?us-ascii?q?BAgIjAwICAiULFAECBggCBAENBQgTiBQOskqRAAEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARyBAYUkhE2EEQoHAQYtgmmCWQWYJwGFfYJ4hSGBcE6EAYhhj0ABHgEBQoI?= =?us-ascii?q?GG4FLboZICRcffwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,618,1454976000"; d="scan'208";a="272079064" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 May 2016 17:03:49 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u4EH3n92003174 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 14 May 2016 17:03:49 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 14 May 2016 12:03:48 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Sat, 14 May 2016 12:03:48 -0500 From: "Les Ginsberg (ginsberg)" To: "Peter Psenak (ppsenak)" , Uma Chunduri , "Stefano Previdi (sprevidi)" Thread-Topic: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call Thread-Index: AQHRp9QzkgSuIqgH0E6x+32lpWBGFp+z+Y4AgAH3/YCAAAOcAIAABKyAgADdIoCAAd0sgA== Date: Sat, 14 May 2016 17:03:48 +0000 Message-ID: <1d9fe3f3508d4fb28bd02b9f23460ccb@XCH-ALN-001.cisco.com> References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10411_1460620508_570F4CDC_10411_96_23_53C29892C857584299CBF5D05346208A0F86E45F@OPEXCLILM21.corporate.adroot.infra.ftgroup> <1B502206DFA0C544B7A6046915200863580C54E9@eusaamb105.ericsson.se> <0468fb2fe35841668bc35606e988074c@XCH-ALN-001.cisco.com> <1B502206DFA0C544B7A60469152008635BCD31AB@eusaamb106.ericsson.se> <445eeb6f8f12480f90e941a81eeaafc7@XCH-ALN-001.cisco.com> <1B502206DFA0C544B7A60469152008635BCDFEFB@eusaamb106.ericsson.se> <1B502206DFA0C544B7A60469152008635BCE586E@eusaamb106.ericsson.se> <5734C54A.2050102@cisco.com> <1B502206DFA0C544B7A60469152008635BCE58AB@eusaamb106.ericsson.se> <573582B5.1010803@cisco.com> In-Reply-To: <573582B5.1010803@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.107.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "bruno.decraene@orange.com" , "spring@ietf.org" Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2016 17:03:53 -0000 VW1hIC0NCg0KSSdkIGxpa2UgdG8gY2xvc2UgdGhpcyBwb2ludCBvZiBkaXNjdXNzaW9uIGFzIHJl Z2FyZHMgdGhlIGNvbmZsaWN0LXJlc29sdXRpb24gZHJhZnQuDQoNCkZvciB0aGUgcmVjb3JkLCBJ IGFncmVlIHdpdGggUGV0ZXIuIEJ1dCBmcm9tIHRoZSBzdGFuZHBvaW50IG9mIGNvbmZsaWN0IHJl c29sdXRpb24gaXQgbWF0dGVycyBub3QgZm9yIHdoYXQgcHVycG9zZSBTUk1TIGlzIGJlaW5nIHVz ZWQgLSB3ZSBoYXZlIHRvIGNvbnNpZGVyIFNSTVMgYWR2ZXJ0aXNlbWVudHMgYXMgd2VsbCBhcyBT SURzIGFzc29jaWF0ZWQgdyBwcmVmaXggYWR2ZXJ0aXNlbWVudHMuIEkgaG9wZSB0aGF0IHBvaW50 IGhhcyBiZWVuIGNsZWFybHkgZXhwbGFpbmVkLg0KDQpJZiB5b3Ugd2lzaCB0byBjb250aW51ZSB0 aGUgZGlzY3Vzc2lvbiB3aXRoIHRoZSBhcmNoaXRlY3R1cmUgZHJhZnQgYXV0aG9ycyBhcyB0byB3 aGV0aGVyIGZ1cnRoZXIgZGlzY3Vzc2lvbiBvZiBTUk1TIGFzIGEgbmV0d29yayBwcm92aXNpb25p bmcgdG9vbCBzaG91bGQvc2hvdWxkIG5vdCBiZSBhZGRlZCB0byBhIGRvY3VtZW50IHBsZWFzZSBm ZWVsIGZyZWUgdG8gZG8gc28gLSBidXQgSSB3b3VsZCBhc2sgdGhhdCB5b3UgZG8gc28gaW4gYW5v dGhlciB0aHJlYWQuDQpUaGFueC4NCg0KICAgTGVzDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBQZXRlciBQc2VuYWsgKHBwc2VuYWspDQo+IFNlbnQ6IEZyaWRheSwg TWF5IDEzLCAyMDE2IDEyOjMxIEFNDQo+IFRvOiBVbWEgQ2h1bmR1cmk7IFN0ZWZhbm8gUHJldmlk aSAoc3ByZXZpZGkpDQo+IENjOiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKTsgc3ByaW5nQGlldGYu b3JnOyBicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tDQo+IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBk cmFmdC1naW5zYmVyZy1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbiAtIFdHIGFkb3B0aW9uDQo+ IGNhbGwNCj4gDQo+IFVtYSwNCj4gDQo+IEkgZG9uJ3Qga25vdyB3aGV0aGVyIHlvdSBuZWVkIGEg dGV4dCBpbiB0aGUgZHJhZnQvUkZDIHRvIHVzZSBzb21lDQo+IGZ1bmN0aW9uYWxpdHkgb25lIHdh eSBvciB0aGUgb3RoZXIuIFRoZSBmYWN0IGlzIHRoYXQgU1JNUyBpcyBhIFNJRCBwcm92aXNpb25p bmcNCj4gdG9vbC4gWW91IGNhbiB1c2UgaXQgZm9yIFNSL0xEUCBpbnRlcm9wZXJhYmlsaXR5LCBi dXQgeW91IGNhbiBhbHNvIHVzZSBpdCBpbiBhIFNSDQo+IG9ubHkgbmV0d29yayB0byBwcm92aWRl IFNJRHMgZnJvbSBhIGNlbnRyYWwgcGxhY2UgaW5zdGVhZCBvZiBjb25maWd1cmluZyB0aGVtDQo+ IG9uIGVhY2ggZGV2aWNlLiBUaGVyZSBpcyBub3RoaW5nIHRoYXQgcHJldmVudHMgeW91IHRvIHVz ZSBpdCBvbmUgd2F5IG9yIHRoZQ0KPiBvdGhlci4gVGhlIGZhY3QgdGhhdCBTUk1TIGlzIGRlZmlu ZWQgaW4gdGhlIFNSL0xEUCBpbnRlcm9wIGRyZmF0IGRvZXMgbm90DQo+IG1lYW4gaXQgaXMgcmVz dHJpY3RlZCB0byBiZSB1c2VkIGZvciB0aGF0IHB1cnBvc2UuDQo+IA0KPiBJIGxldCBhdXRob3Jz IG9mIHRoZSBTUiBhcmNoaXRlY3R1cmUgZHJhZnRzIHRvIGRlY2lkZSB3aGV0aGVyIHRoZXkgd2Fu dCB0byBhZGQNCj4gdGhlIHRleHQuIEFzIGFuIGF1dGhvciBvZiB0aGUgT1NQRiBTUiBkcmFmdCwg SSBkbyBub3Qgc2VlIGFueXRoaW5nIGluIHRoZSB0ZXh0DQo+IHRoYXQgeW91IHB1dCBiZWxvdyB0 aGF0IHdvdWxkIGNvbnRyYWRpY3Qgd2hhdCBJJ20gc2F5aW5nIGhlcmUuDQo+IA0KPiB0aGFua3Ms DQo+IFBldGVyDQo+IA0KPiANCj4gT24gNS8xMi8xNiAyMDoxOSAsIFVtYSBDaHVuZHVyaSB3cm90 ZToNCj4gPiBQZXRlciwNCj4gPiAgICAgICAgICA+IGFzIGEgbWF0dGVyIG9mIGZhY3QsIFNSTVMg aXMgYSBTSUQgcHJvdmlzaW9uaW5nIHRvb2wsDQo+ID4gd2hldGhlciB5b3UgbGlrZSBpdCBvciBu b3QuDQo+ID4gSXQncyBub3QgYWJvdXQgeW91ciBvciBteSBsaW5raW5nIC0gSSB3YXMgdGFsa2lu ZyBhYm91dCB3aGF0J3MgdGhlDQo+ID4gZGVmaW5lZCBzY29wZSBzbyBmYXIgKGFyY2hpdGVjdHVy ZSBkb2Mgb3IgcHJvdG9jb2wgZG9jcykgYW5kIGhvdyB5b3UNCj4gPiB3YW50IHRvIGV4dGVuZCB0 aGUgc2NvcGUuDQo+ID4gV2VsbCwgaWYgeW91IHdhbnQgdG8gZXh0ZW5kIHRoZSBjdXJyZW50IHNj b3BlIG9mIFNSTVMgYXMgYSAiIj4yKUFzIGENCj4gPiBnbG9iYWwgcHJvdmlzaW9uaW5nIHRvb2wi IC0gUGx6LiBkbyBzbyBidXQgbm90IHdoaWxlIHByb3ZpZGluZw0KPiA+IGNvbmZsaWN0IHJlc29s dXRpb24gc29sdXRpb24uDQo+ID4gICAgICAgICAgICAgICAgID4gSXQgcHJvdmlkZXMgYWxsIHRo ZSBmdW5jdGlvbmFsaXR5IHRoYXQgaXMgcmVxdWlyZWQNCj4gPiBmb3Igc3VjaCBwcm92aXNpb25p bmcgdG9vbC4NCj4gPiAgICAgICAgICA+WW91IGNhbiBub3QgcmVzdHJpY3QgaXRzIHVzYWdlIHRv IFNSL0xEUCBpbnRlcm9wIGNhc2UuDQo+ID4gSSBkaWRuJ3QgcmVzdHJpY3QgYW55dGhpbmcgLSBQ bHouIHNlZSBTUk1TIHN0dWZmIHNvIGZhcjoNCj4gPiAxLg0KPiA+IF9odHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLTA4I3NlY3QNCj4g PiBpb24tMy42Xw0KPiA+DQo+ID4gLyIgLy8zLjYuMS4gIE1hcHBpbmcgU2VydmVyLw0KPiA+IC8v L0EgUmVtb3RlLUJpbmRpbmcgU0lEIFMgYWR2ZXJ0aXNlZCBieSB0aGUgbWFwcGluZyBzZXJ2ZXIg TSBmb3INCj4gPiByZW1vdGUvIC8vL3ByZWZpeCBSIGF0dGFjaGVkIHRvIG5vbi1TUi1jYXBhYmxl IG5vZGUgTiBzaWduYWxzIHRoZQ0KPiA+IHNhbWUvIC8vL2luZm9ybWF0aW9uIGFzIGlmIE4gaGFk IGFkdmVydGlzZWQgUyBhcyBhIFByZWZpeC1TSUQuDQo+ID4gRnVydGhlci8gLy8vZGV0YWlscyBh cmUgZGVzY3JpYmVkIGluIHRoZSBTUi9MRFAgaW50ZXJ3b3JraW5nDQo+ID4gcHJvY2VkdXJlcy8g Ly8vKFtJLUQuaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLWxkcC1pbnRlcm9wXS4vLyIvDQo+ ID4gMi4gSVNJUzoNCj4gPiBfaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt aXNpcy1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9uDQo+ID4gcy0wNiNzZWN0aW9uLTIuNF8NCj4g Pg0KPiA+IC8iIC8vVGhpcyBmdW5jdGlvbmFsaXR5IGlzIGNhbGxlZCB0aGUvIC8vLy8vJ01hcHBp bmcgU2VydmVyJyBhbmQgaXQncw0KPiA+IHVzZWQgd2hlbiwgaW4gYSBoZXRlcm9nZW5lb3VzIG5l dHdvcmssLyAvLy8vLy8vbm90IGFsbCBub2RlcyBhcmUNCj4gPiBjYXBhYmxlIG9mIGFkdmVydGlz aW5nIHRoZWlyIG93biBTSURzL0xhYmVscy4vLyIvIDMuIE9TUEY6DQo+ID4gX2h0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW9zcGYtc2VnbWVudC1yb3V0aW5nLWV4dGVuc2lv bg0KPiA+IHMtMDgjc2VjdGlvbi00Xw0KPiA+DQo+ID4gLyIvLyAgIEluIHNvbWUgY2FzZXMgaXQg aXMgdXNlZnVsIHRvIGFkdmVydGlzZSBhdHRyaWJ1dGVzIGZvciBhIHJhbmdlIG9mLw0KPiA+IC8v L3ByZWZpeGVzLiAgVGhlIFNlZ21lbnQgUm91dGluZyBNYXBwaW5nIFNlcnZlciwgd2hpY2ggaXMg ZGVzY3JpYmVkDQo+ID4gaW4vIC8vL1svL0ktRC5maWxzZmlscy1zcHJpbmctc2VnbWVudC1yb3V0 aW5nLWxkcC1pbnRlcm9wLw0KPiA+IDxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1vc3BmLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb24NCj4gPiBzLTA4Pi9dLA0KPiA+IGlz IGFuIGV4YW1wbGUvDQo+ID4gLy8vd2hlcmUgd2UgbmVlZCBhIHNpbmdsZSBhZHZlcnRpc2VtZW50 IHRvIGFkdmVydGlzZSBTSURzIGZvcg0KPiA+IG11bHRpcGxlLyAvLy9wcmVmaXhlcyBmcm9tIGEg Y29udGlndW91cyBhZGRyZXNzIHJhbmdlLi8vIi8gQWdhaW4sIHBsei4NCj4gPiBleHRlbmQgdGhl IHNjb3BlIGZpcnN0IGFuZCBjb25zaWRlciB0aGUgc2FtZSBpbiByZXNvbHV0aW9uIHNvbHV0aW9u LiBJDQo+ID4gYW0gZmluZSB3aXRoIGl0Lg0KPiA+IC0tDQo+ID4gVW1hIEMuDQo+ID4gLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBQZXRlciBQc2VuYWsgW21haWx0bzpwcHNl bmFrQGNpc2NvLmNvbV0NCj4gPiBTZW50OiBUaHVyc2RheSwgTWF5IDEyLCAyMDE2IDExOjAzIEFN DQo+ID4gVG86IFVtYSBDaHVuZHVyaTsgU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkNCj4gPiBD YzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZyk7IHNwcmluZ0BpZXRmLm9yZzsNCj4gPiBicnVuby5k ZWNyYWVuZUBvcmFuZ2UuY29tDQo+ID4gU3ViamVjdDogUmU6IFtzcHJpbmddIGRyYWZ0LWdpbnNi ZXJnLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uIC0gV0cNCj4gPiBhZG9wdGlvbiBjYWxsIEhp IFVtYSwgT24gNS8xMi8xNiAxOTo0OSAsIFVtYSBDaHVuZHVyaSB3cm90ZToNCj4gPj4gU3RlZmFu bywNCj4gPj4NCj4gPj4gVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlLg0KPiA+Pg0KPiA+PiAgICAg ICAgPiB1c2luZyBhIFNSTVMgZm9yIGFkdmVydGlzaW5nIFNJRCBvbiBiZWhhbGYgb2YgU1IgY2Fw YWJsZSBub2RlcyBkb2VzDQo+IG5vdCBpbnRyb2R1Y2UgYW55IGNoYW5nZSBpbiB0aGUgU1IgYXJj aGl0ZWN0dXJlIHNvIG5vdA0KPiA+PiAgICAgICAgICAgICAgICAgPiBzdXJlIHdoYXQgd2UgbmVl ZCB0byBkb2N1bWVudCBoZXJlLg0KPiA+Pg0KPiA+PiBNeSBwb2ludCBiZWxvdzogV2UgYXJlIGNy ZWF0aW5nIGEgY29uZmxpY3QgcmVzb2x1dGlvbiBzb2x1dGlvbiBmb3IgYSBub24tDQo+IGV4aXN0 aW5nIHJlcXVpcmVtZW50IG9mIHVzaW5nICBTUk1TIHZpei4sICAiPjIpQXMgYSBnbG9iYWwgcHJv dmlzaW9uaW5nIHRvb2wiLg0KPiA+PiAgRnJvbSB5b3VyIHN0YXRlbWVudCBhYm92ZSwgaXQgc2Vl bXMgeW91IGhhdmUgbGVzcyBpbnRlcmVzdCB0byBtYWtlIHRoaXMNCj4gYXMgYSByZXF1aXJlbWVu dC9zY29wZSBvZiBTUk1TOyBJIGFtIG1vcmUgYWxpZ25lZCBpbiB0aGF0IHBhdGguLi4uDQo+ID4g YXMgYSBtYXR0ZXIgb2YgZmFjdCwgU1JNUyBpcyBhIFNJRCBwcm92aXNpb25pbmcgdG9vbCwgd2hl dGhlciB5b3UgbGlrZQ0KPiA+IGl0IG9yIG5vdC4gSXQgcHJvdmlkZXMgYWxsIHRoZSBmdW5jdGlv bmFsaXR5IHRoYXQgaXMgcmVxdWlyZWQgZm9yIHN1Y2gNCj4gPiBwcm92aXNpb25pbmcgdG9vbC4g WW91IGNhbiBub3QgcmVzdHJpY3QgaXRzIHVzYWdlIHRvIFNSL0xEUCBpbnRlcm9wIGNhc2UuDQo+ ID4gdGhhbmtzLA0KPiA+IFBldGVyDQo+ID4+DQo+ID4+IE9uIHRoZSBzZWNvbmQgcG9pbnQ6DQo+ ID4+DQo+ID4+ICAgICAgICA+IHRoZSBhcmNoaXRlY3R1cmUgZHJhZnQgaXMgZGF0YS1wYW5lIGFn bm9zdGljIHNvIEkgcHJlc3VtZSB5b3UgcmVmZXINCj4gdG8gZHJhZnQtaWV0Zi1zcHJpbmctc2Vn bWVudC1yb3V0aW5nLW1wbHMuDQo+ID4+DQo+ID4+IEFGQUlTLGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctMA0KPiA+PiA4ICB0YWxr cw0KPiA+IGFib3V0IGJvdGggZGF0YSBwbGFuZXMgcmlnaHQgZnJvbSBhYnN0cmFjdCB0byBtdWx0 aXBsZSBwbGFjZXMgKHdoaWNoDQo+ID4gaXQgb3VnaHQgdG8pLg0KPiA+PiBJIGxlYXZlIHRoaXMg dG8geW91L1dHIG9uIHdoZXJlIHlvdSB3YW50IHRvIGRvY3VtZW50IHRoaXMgLWJ1dCBJTU8NCj4g Pj4gY29uZmxpY3QgcmVzb2x1dGlvbiAic29sdXRpb24gZG9jdW1lbnQiIGluIHRoZSBjdXJyZW50 IGZvcm0gcG90ZW50aWFsbHkNCj4gaW50cm9kdWNpbmcgZnVuZGFtZW50YWwgcmVxdWlyZW1lbnRz ICB0byB0aGUgc3lzdGVtIGxpa2UgY3Jvc3MgcHJvdG9jb2wNCj4gdmVyaWZpY2F0aW9uICh3aXRo IGluL2Fjcm9zcyBBUykuIFBlcmhhcHMgc29tZSBkaXNjdXNzaW9uIHNob3VsZCBiZSB0aGVyZSBp bg0KPiBkYXRhIHBsYW5lIGRvY3VtZW50IHRoZW4uDQo+ID4+DQo+ID4+IC0tDQo+ID4+IFVtYSBD Lg0KPiA+Pg0KPiA+Pg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9t OiBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKSBbbWFpbHRvOnNwcmV2aWRpQGNpc2NvLmNvbV0N Cj4gPj4gU2VudDogV2VkbmVzZGF5LCBNYXkgMTEsIDIwMTYgNDo0NiBBTQ0KPiA+PiBUbzogVW1h IENodW5kdXJpDQo+ID4+IENjOiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKTticnVuby5kZWNyYWVu ZUBvcmFuZ2UuY29tDQo+ID4+PG1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPjsNCj4g Pj5zcHJpbmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ID4+IFN1YmplY3Q6 IFJlOiBbc3ByaW5nXSBkcmFmdC1naW5zYmVyZy1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbiAt IFdHDQo+ID4+YWRvcHRpb24gY2FsbA0KPiA+Pg0KPiA+Pg0KPiA+Pj4gT24gTWF5IDYsIDIwMTYs IGF0IDEwOjE2IFBNLCBVbWEgQ2h1bmR1cmkNCj4gPHVtYS5jaHVuZHVyaUBlcmljc3Nvbi5jb20g PG1haWx0bzp1bWEuY2h1bmR1cmlAZXJpY3Nzb24uY29tPj4NCj4gd3JvdGU6DQo+ID4+Pg0KPiA+ Pj4gTGVzLA0KPiA+Pj4NCj4gPj4+IDIgcXVpY2sgdGhpbmdzLg0KPiA+Pj4NCj4gPj4+IDEuDQo+ ID4+PiAgICAgICAgICAgICAgPltMZXM6XSBUaGVyZSBhcmUgdHdvIGxlZ2l0aW1hdGUgdXNlIGNh c2VzIGZvciBTUk1TOg0KPiA+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICA+MSlUbyBhZHZlcnRpc2UgU0lEcyBmb3Igbm9uLVNSIGNhcGFibGUgbm9kZXMNCj4g Pj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPjIpQXMgYSBn bG9iYWwgcHJvdmlzaW9uaW5nIHRvb2wNCj4gPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg SSBhbSBoZWFyaW5nICMyIGZvciB0aGUgZmlyc3QgdGltZS4gSQ0KPiA+Pj5kb27igJl0IHNlZSB0 aGlzIGVpdGhlciAgZGlzY3Vzc2VkIGVhcmxpZXIgaW4gdGhlIFdHIGxpc3QgIG9yIGNhcHR1cmVk DQo+ID4+PmluIGFyY2hpdGVjdHVyZSBkb2N1bWVudA0KPiA+Pj5odHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLTA3Lg0KPiA+Pj5FdmVu DQo+ID4gaW4gdGhlIHByb3RvY29sIGV4dGVuc2lvbnMgZG9jdW1lbnQgZm9yIGV4YW1wbGUNCj4g Pj4+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtaXNpcy1zZWdtZW50LXJv dXRpbmctZXh0ZW5zaW9uDQo+ID4+PnMtMDYjc2VjdGlvbi0yLjQNCj4gPiB3ZSBhbHdheXMgZGlz Y3Vzc2VkIHRoaXMgZnJvbSBub24tU1INCj4gPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAg Y2FwYWJsZSBub2RlcyBQb1YuIFNvIEkgcmVxdWVzdCB0byBhZGQgdGhpcyBpbiBhcmNoaXRlY3R1 cmUNCj4gZG9jdW1lbnQgYmVmb3JlIGZhY3RvcmluZyB0aGlzIGZvciBzb2x1dGlvbiBpbiBjb25m bGljdCByZXNvbHV0aW9uLg0KPiA+Pg0KPiA+Pg0KPiA+PiB1c2luZyBhIFNSTVMgZm9yIGFkdmVy dGlzaW5nIFNJRCBvbiBiZWhhbGYgb2YgU1IgY2FwYWJsZSBub2RlcyBkb2VzIG5vdA0KPiBpbnRy b2R1Y2UgYW55IGNoYW5nZSBpbiB0aGUgU1IgYXJjaGl0ZWN0dXJlIHNvIG5vdCBzdXJlIHdoYXQg d2UgbmVlZCB0bw0KPiBkb2N1bWVudCBoZXJlLg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+Pj4NCj4g Pj4+IDIuICAgICAgIEFsc28gdGhpcyBpcyB0aGUgZmlyc3QgdGltZSBldmVyIHdlIGhhdmUgYSBy ZXF1aXJlbWVudCBmb3IgY3Jvc3MNCj4gcHJvdG9jb2xzIHZlcmlmaWNhdGlvbiB3ZSBvdWdodCB0 byBkaXNjdXNzIHRoZSBpbXBsaWNhdGlvbnMgb2YgdGhpcw0KPiA+Pj4gYW5kIHByb3RvY29scyBp bnZvbHZlZCAod2l0aCBpbiBBUyBvciBvdGhlcndpc2UpIGluIHRoZSBhcmNoaXRlY3R1cmUNCj4g ZG9jdW1lbnQgKGF0IGxlYXN0IGJyaWVmbHkpLg0KPiA+Pg0KPiA+Pg0KPiA+PiB0aGUgYXJjaGl0 ZWN0dXJlIGRyYWZ0IGlzIGRhdGEtcGFuZSBhZ25vc3RpYyBzbyBJIHByZXN1bWUgeW91IHJlZmVy IHRvDQo+IGRyYWZ0LWlldGYtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1tcGxzLg0KPiA+Pg0KPiA+ PiB3aXRoIHRoZSBpcHY2IGRhdGEtcGxhbmUgU1IgY29uZmxpY3RzIGFyZSBpbiBmYWN0IHNvbHZl ZCBieSBpcHY2DQo+ID4+IGFkZHJlc3NpbmcgdGVjaG5pcXVlcyA7LSkNCj4gPj4NCj4gPj4gcy4N Cj4gPj4NCj4gPj4NCj4gPj4+DQo+ID4+PiAtLQ0KPiA+Pj4gVW1hIEMuDQo+ID4+Pg0KPiA+Pj4g RnJvbTogc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBMZXMNCj4gPj4+IEdpbnNiZXJnIChnaW5zYmVyZykNCj4gPj4+IFNlbnQ6IFdlZG5lc2RheSwg TWF5IDA0LCAyMDE2IDk6MzggQU0NCj4gPj4+IFRvOiBVbWEgQ2h1bmR1cmk7YnJ1bm8uZGVjcmFl bmVAb3JhbmdlLmNvbQ0KPiA+Pj4gPG1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPjsN Cj4gPiBzcHJpbmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ID4+PiBTdWJq ZWN0OiBSZTogW3NwcmluZ10gZHJhZnQtZ2luc2Jlcmctc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRp b24gLSBXRw0KPiA+Pj4gYWRvcHRpb24gY2FsbA0KPiA+Pj4NCj4gPj4+IFVtYSDigJMNCj4gPj4+ DQo+ID4+PiBUbyByZXN0YXRlLCB0aGUgcHJvYmxlbSBiZWluZyBhZGRyZXNzZWQgaGVyZSBpcyB0 byBndWFyYW50ZWUNCj4gPj4+IGNvbnNpc3RlbnQgdXNlIG9mIFNJRHMgaW4gdGhlIGZvcndhcmRp bmcgcGxhbmUgbmV0d29yay13aWRlIGluIHRoZQ0KPiA+Pj4gcHJlc2VuY2Ugb2YgY29uZmxpY3Rp bmcgYWR2ZXJ0aXNlbWVudHMuIFRoZSBzZXQgb2YgYWR2ZXJ0aXNlbWVudHMNCj4gPj4+IGluY2x1 ZGVzIGJvdGggU0lEcyBhZHZlcnRpc2VkIGluIHByb3RvY29sIHByZWZpeCByZWFjaGFiaWxpdHkN Cj4gPj4+IGFkdmVydGlzZW1lbnRzIGFuZCBTUk1TIGFkdmVydGlzZW1lbnRzIGJlY2F1c2UgcHJv YmxlbXMgb2NjdXINCj4gYmFzZWQNCj4gPiB1cG9uIGluY29uc2lzdGVuY2llcyBpbiB3aGF0IGlz IGluc3RhbGxlZCBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZSBvZg0KPiA+IGRpZmZlcmVudCByb3V0 ZXJzLiBJdCBtYXR0ZXJzIG5vdCB3aGV0aGVyIFJvdXRlciBBIHVzZWQgYSBTSUQNCj4gPiBhZHZl cnRpc2VkIGJ5IGEgcHJvdG9jb2wgcHJlZml4IHJlYWNoYWJpbGl0eSBhZHZlcnRpc2VtZW50IG9y IGJ5IGFuDQo+ID4gU1JNUyBhZHZlcnRpc2VtZW50IOKAkyB3aGF0IG1hdHRlciBpcyB3aGV0aGVy IHRoZSBTSUQgdXNlZCBpcyBjb25zaXN0ZW50DQo+ID4gd2l0aCB3aGF0IHRoZSBuZWlnaGJvcnMg b2YgUm91dGVyIEEgdXNlLiBTbyBzaW1wbHkgZW5zdXJpbmcgdGhhdCBPU1BGDQo+ID4gKGZvcg0K PiA+IGV4YW1wbGUpIHJlc29sdmVzIFNJRHMgaW4gYSBjb25zaXN0ZW50IHdheSBkb2VzIG5vdCBm dWxseSBhZGRyZXNzIHRoZQ0KPiA+IHByb2JsZW0gc3BhY2UuDQo+ID4+Pg0KPiA+Pj4gTW9yZSBp bmxpbmUuDQo+ID4+Pg0KPiA+Pj4gRnJvbTogVW1hIENodW5kdXJpIFttYWlsdG86dW1hLmNodW5k dXJpQGVyaWNzc29uLmNvbV0NCj4gPj4+IFNlbnQ6IFR1ZXNkYXksIE1heSAwMywgMjAxNiAzOjU5 IFBNDQo+ID4+PiBUbzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZyk7YnJ1bm8uZGVjcmFlbmVAb3Jh bmdlLmNvbQ0KPiA+Pj48bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20+Ow0KPiA+Pj5z cHJpbmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ID4+PiBTdWJqZWN0OiBS RTogW3NwcmluZ10gZHJhZnQtZ2luc2Jlcmctc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24gLSBX Rw0KPiA+Pj5hZG9wdGlvbiBjYWxsDQo+ID4+Pg0KPiA+Pj4gTGVzLA0KPiA+Pj4NCj4gPj4+IFdp dGggYWxsIGR1ZSByZXNwZWN0cywgY3Jvc3MgcHJvdG9jb2wgdmVyaWZpY2F0aW9uICBvZiBwcmVm aXggYW5kIFNJRA0KPiBjb25mbGljdHMgYXMgYW4g4oCcYXJjaGl0ZWN0dXJhbCBjaGFuZ2XigJ0g IGFuZCBpdCBjYW4gc2V2ZXJlbHkgaW1wYWN0IHRoZSBleGlzdGluZw0KPiBpbXBsZW1lbnRhdGlv bnMgKGF0IGxlYXN0IHRoZSBvbmUgSSB3b3JrIG9uKS4NCj4gPj4+DQo+ID4+PiBbTGVzOl0gSXQg aXMgcXVpdGUgY29ycmVjdCDigJMgYW5kIEkgY2FuIGNvbmZpcm0gYmFzZWQgb24gcGVyc29uYWwN Cj4gZXhwZXJpZW5jZSDigJMgdGhhdCBzdXBwb3J0IGZvciBjb25mbGljdCByZXNvbHV0aW9uIGlz IGEgc2lnbmlmaWNhbnQgZWZmb3J0Lg0KPiA+Pj4NCj4gPj4+IEFsc28gSSBoYXZlIGNvdXBsZSBv ZiBjYXNlcyB3aGVyZSBjdXJyZW50IHZlcnNpb24gb2YgdGhlIGRyYWZ0IGlzIG5vdCBjbGVhcg0K PiBhYm91dCByZXNvbHV0aW9uLg0KPiA+Pj4NCj4gPj4+IElNTywgZmlyc3Qgd2UgbmVlZCBjbGFy aXR5IHdpdGggaW4gYSBwcm90b2NvbCBpbnN0YW5jZSByZXNvbHV0aW9uIHJ1bGVzDQo+IGJlZm9y ZSBnb2luZyB0byByZXNvbHZlIHRoZSBzYW1lIGFjcm9zcyBwcm90b2NvbHMgKEkgbWVudGlvbmVk IGZldyBjYXNlcw0KPiBiZWxvdykgLg0KPiA+Pj4gU2VwYXJhdGlvbiBvZiByZWFjaGFiaWxpdHkg YWR2ZXJ0aXNlbWVudHMgYW5kIFNSTVMgd291bGQgaGVscCDigJxjcm9zcw0KPiBwcm90b2NvbOKA nSB2ZXJpZmljYXRpb24gb2YgdGhlIHJhbmdlcyBhbmQgU1JNUyBpcyBub3QgYXBwbGljYWJsZSB0 byBhbGwNCj4gcHJvdG9jb2xzLg0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBJbi1saW5lIFtVbWFdOg0K PiA+Pj4NCj4gPj4+IC0tDQo+ID4+PiBVbWEgQy4NCj4gPj4+DQo+ID4+PiBGcm9tOiBMZXMgR2lu c2JlcmcgKGdpbnNiZXJnKSBbbWFpbHRvOmdpbnNiZXJnQGNpc2NvLmNvbV0NCj4gPj4+IFNlbnQ6 IFNhdHVyZGF5LCBBcHJpbCAzMCwgMjAxNiAxMDoxMSBQTQ0KPiA+Pj4gVG86IFVtYSBDaHVuZHVy aTticnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tDQo+ID4+PiA8bWFpbHRvOmJydW5vLmRlY3JhZW5l QG9yYW5nZS5jb20+Ow0KPiA+IHNwcmluZ0BpZXRmLm9yZyA8bWFpbHRvOnNwcmluZ0BpZXRmLm9y Zz4NCj4gPj4+IFN1YmplY3Q6IFJFOiBbc3ByaW5nXSBkcmFmdC1naW5zYmVyZy1zcHJpbmctY29u ZmxpY3QtcmVzb2x1dGlvbiAtIFdHDQo+ID4+PiBhZG9wdGlvbiBjYWxsDQo+ID4+Pg0KPiA+Pj4g VW1hIOKAkw0KPiA+Pj4NCj4gPj4+IFdlIGFyZSBpbmRlZWQgZGVmaW5pbmcgY29uZmxpY3QgcmVz b2x1dGlvbiBhY3Jvc3MgYWxsIHRoZSBTSUQNCj4gPj4+IGFkdmVydGlzZW1lbnRzIHJlZ2FyZGxl c3Mgb2Ygc291cmNlIChwcm90b2NvbCBvciBTUk1TKSDigJMNCj4gPj4+DQo+ID4+PiBbVW1hXTog V2hpbGUgeW91IGNhbiB0aGVvcmV0aWNhbGx5IGRvIGFueXRoaW5nIGZvciBjdXJyZW50DQo+IGlt cGxlbWVudGF0aW9uIHRoaXMga2luZCBvZiBjcm9zcyBwcm90b2NvbCB2ZXJpZmljYXRpb24gaXMg YSBuZXcgYXJjaGl0ZWN0dXJhbA0KPiByZXF1aXJlbWVudC4NCj4gPj4+ICAgICAgICAgICAgICAg ICBCZWNhdXNlIGl0IHNlZW1zIOKAnGEgY2VudHJhbCBlbnRpdHnigJ0gbmVlZCB0byBnYXRoZXIg YWxsIGRpZmZlcmVudA0KPiBwcm90b2NvbCBpbnN0YW5jZXMgU1JNUyBhZHZlcnRpc2VtZW50cyBh bmQgc2hvdWxkIHNldHRsZSB3aXRoIHJlc29sdXRpb24uDQo+ID4+Pg0KPiA+Pj4gLSAgICAgICAg ICBBbHNvIG5vdGUgU1JNUyBpcyBub3QgYXBwbGljYWJsZSBmb3IgQkdQIGJ1dCBpdCBzZWVtcyBh bGwgcHJlZml4IFNJRHMNCj4gbmVlZCB0byBiZSB2ZXJpZmllZCAgd2l0aCBJR1AgaW5zdGFuY2Vz IFNSTVMgYWR2ZXJ0aXNlbWVudHMuIElzIHRoaXMgdHJ1ZT8NCj4gV2hpbGUgdGhlIGRvY3VtZW50 IG1vc3RseSB0YWxrcyBhYm91dCB0aGVzZSBhbmQgY29tcGFyZXMgd2l0aCBwcmVmaXgNCj4gYWR2 ZXJ0aXNlbWVudC4NCj4gPj4+IFtMZXM6XSBUaGUgaXNzdWUgaXMgcHJvdG9jb2wgYWdub3N0aWMu DQo+ID4+Pg0KPiA+Pj4gLSAgICAgICAgICBBbGdvcml0aG0gcHJvcG9zZWQgbmVlZHMgbW9yZSBj bGFyaXR5OiBUYWtlIFNlY3Rpb24gMy4yLjQNCj4gPj4+DQo+ID4+PiBvDQo+ID4+PiAgICAgICAg ICAgICAgICAgICAgICAgIOKAnCAgIDEuICBTbWFsbGVyIHJhbmdlIHdpbnMNCj4gPj4+DQo+ID4+ PiAgICAgICAgICAgICAgIDIuICBJUHY2IGVudHJ5IHdpbnMgb3ZlciBJUHY0IGVudHJ5DQo+ID4+ PiAgICAgICAgICAgICAgIOKApg0KPiA+Pj4gICAgICAgICAg4oCcDQo+ID4+PiAgICAgICAgICAg ICAgICAgICBXaGF0IGhhcHBlbnMgaW4gY2FzZSBvZiBwcmVmaXggY29uZmxpY3Qgb3IgU0lEIGNv bmZsaWN0IHdpdGggb25seQ0KPiBwcmVmaXggYWR2ZXJ0aXNlbWVudHMgKHJhbmdlIDEpLiAgU2F5 IG11bHRpcGxlIHByZWZpeGVzIGhhdmUgc2FtZSBTSUQgaW4gb25lDQo+IHByb3RvY29sIGluc3Rh bmNlIGFuZCBpbiBkaWZmZXJlbnQgcHJvdG9jb2xzLg0KPiA+Pj4gICAgICAgICAgICAgICAgICAg SSBzZWUgMiBsZXZlbHMgb2YgcmVzb2x1dGlvbiByZXF1aXJlZCB2aXouLCBvbmUgYXQgd2l0aGlu IHRoZQ0KPiBwcm90b2NvbCBhbmQgb25lIGFtb25nIHRoZSBwcm90b2NvbHMuICBObyBkaXNjdXNz aW9uIG9uIHRoaXMuDQo+ID4+Pg0KPiA+Pj4gW0xlczpdIFRoZSBmdWxsIHNldCBvZiBydWxlcyBz cGVjaWZpZWQgaW4gdGhlIGRyYWZ0IHByb3ZpZGUgZGV0ZXJtaW5pc3RpYw0KPiByZXNvbHV0aW9u IGluIGFsbCBjYXNlcy4gWW91IGhhdmUgc25pcHBlZCBvbmx5IHRoZSBmaXJzdCB0d28gcnVsZXMu IElmIGENCj4gcHJlZmVyZW5jZSBpcyBub3Qgb2J0YWluZWQgYmFzZWQgb24gdGhlIGZpcnN0IHR3 byBydWxlcyB5b3UgY29udGludWUgb24gdG8NCj4gcnVsZSAjMywgdGhlbiBydWxlICM0LCBldGMu DQo+ID4+Pg0KPiA+Pj4gICAgICAgICAgICAgICAgICAgU2ltaWxhcmx5IGluIGNhc2Ugb2YgU0lE IGNvbmZsaWN0ICAocmFuZ2UgMSksIGl04oCZcyBub3Qgc3BlY2lmaWVkIHdoaWNoDQo+IHByb3Rv Y29s4oCZcyBTSUQgbmVlZCB0byBiZSBjb25zaWRlcmVkLiAgQXJlIHlvdSBhc3N1bWluZyBzb21l IHNvcnQgb2YgQWRtaW4NCj4gZGlzdGFuY2UgcGxheSBhIHJvbGUgaW4gcmVzb2x1dGlvbj8NCj4g Pj4+IFtMZXM6XSBObyDigJMgYWRtaW4gZGlzdGFuY2UgcGxheXMgbm8gcm9sZSBoZXJlLg0KPiA+ Pj4NCj4gPj4+ICAgSSBkb27igJl0IHNlZSBhbnkgZGlzY3Vzc2lvbiBpbiB0aGUgZG9jdW1lbnQg IGFuZCBuZWVkcyBtb3JlIGNsYXJpdHkNCj4gdGhlcmUgdG9vLg0KPiA+Pj4gbyAgIEFsc28gd2hh dCBoYXBwZW5zIGlmIGEgcHJlZml4IG9yIFNJRCBjb25mbGljdCBoYXBwZW5zIHdpdGggU1JNUyBy YW5nZQ0KPiAxIGFuZCBhIHByZWZpeCAgYWR2ZXJ0aXNlbWVudCAoMiBjYXNlcykNCj4gPj4+IGEu ICAgICAgIG9mIG9uZSBwcm90b2NvbCBhbmQNCj4gPj4+IGIuICAgICAgbXVsdGlwbGUgcHJvdG9j b2xzPw0KPiA+Pj4NCj4gPj4+IFtMZXM6XSBUaGUgc291cmNlIG9mIHRoZSBTSUQgYWR2ZXJ0aXNl bWVudCAod2hhdCBwcm90b2NvbC9wcm90b2NvbA0KPiBpbnN0YW5jZSBvciB3aGV0aGVyIGl0IGlz IFNSTVMgYmFzZWQpIHBsYXlzIG5vIHJvbGUuIFRoZSB0aWUgYnJlYWtlciBydWxlcyBhcw0KPiBk ZWZpbmVkIGFyZSBjb21wbGV0ZSBhbmQgcHJvdmlkZSBhIGRldGVybWluaXN0aWMgYW5zd2VyIGlu IGFsbCBjYXNlcy4NCj4gPj4+IElmIHlvdSBiZWxpZXZlIHRoYXQgaXMgbm90IHRydWUgcGxlYXNl IHByb3ZpZGUgYSBzcGVjaWZpYyBleGFtcGxlIHdoZXJlDQo+IHlvdSBhcHBseSBhbGwgdGhlIHJ1 bGVzIGluIHRoZSBvcmRlciBzcGVjaWZpZWQgYW5kIHN0aWxsIGRvIG5vdCBkZXRlcm1pbmUgdGhl DQo+IHByZWZlcnJlZCBlbnRyeS4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4gLSAgICAgICAgICBPbiB0 aGUgYmVsb3cgYXNzdW1wdGlvbjogKFNlY3Rpb24gMy4yLjQpDQo+ID4+PiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICDigJxUaGlzIGhhcyB0aGUgbmljZSBwcm9wZXJ0 eSB0aGF0IGEgc2luZ2xlDQo+IG1pc2NvbmZpZ3VyYXRvaW9uIG9mIGFuIFNSTVMNCj4gPj4+ICAg ICAgICAgICAgICAgICAgIGVudHJ5IHdpdGggYSBsYXJnZSByYW5nZSB3aWxsIG5vdCBiZSBwcmVm ZXJyZWQgb3ZlciBhIGxhcmdlDQo+IG51bWJlciBvZg0KPiA+Pj4gICAgICAgICAgICAgICAgICAg U0lEcyBhZHZlcnRpc2VkIGluIHByZWZpeCByZWFjaGFiaWxpdHkgYWR2ZXJ0aXNlbWVudHMu4oCd DQo+ID4+PiBXaGlsZSBhbnl0aGluZyBjYW4gaGFwcGVuIGluIHRoZW9yeSwgSSBmb3VuZCBpdCBi aXQgb2RkIHRvIHNlZSB3aHkgU1JNUw0KPiBlbnRyeSBpcyBiZWluZyBhZHZlcnRpc2VkIGFuZCBm b3IgdGhlIHNhbWUgcHJlZml4LCBTSUQgaXMgYWxzbyBhZHZlcnRpc2VkDQo+IHRocm91Z2ggcmVh Y2hhYmlsaXR5IGFkdmVydGlzZW1lbnRzPw0KPiA+Pj4gVGhpcyBpcyBhZ2FpbnN0IHRoZSBzcGly aXQgb2YgU1JNUyBhZHZlcnRpc2VtZW50LCBpc27igJl0IGl0PyBXaGlsZSB0aGlzIGNhbg0KPiBo YXBwZW4sIGl0IHNlZW1zIHdlIGFyZSBjbGFpbWluZyByZXNvbHV0aW9uIHNvbHV0aW9uIGJ5IGZv Y3VzaW5nIG1vcmUgb24NCj4gdGhpcyBjYXNlIGluIHRoZSBjdXJyZW50IHZlcnNpb24gb2YgdGhl IGRvY3VtZW50Lg0KPiA+Pj4NCj4gPj4+IFtMZXM6XSBUaGVyZSBhcmUgdHdvIGxlZ2l0aW1hdGUg dXNlIGNhc2VzIGZvciBTUk1TOg0KPiA+Pj4NCj4gPj4+IDEpVG8gYWR2ZXJ0aXNlIFNJRHMgZm9y IG5vbi1TUiBjYXBhYmxlIG5vZGVzIDIpQXMgYSBnbG9iYWwNCj4gPj4+IHByb3Zpc2lvbmluZyB0 b29sDQo+ID4+Pg0KPiA+Pj4gTGV04oCZcyBleGFtaW5lIHRoZSBmaXJzdCBjYXNlLiBJIGhhdmUg YW4gTERQIGVuYWJsZWQgbmV0d29yayBhbmQgSSBiZWdpbg0KPiBpbnRyb2R1Y2luZyBTUiBjYXBh YmxlIG5vZGVzLiBBdCBhIGdpdmVuIG1vbWVudCBpbiB0aW1lIFJvdXRlciBBIGlzIE5PVCBTUg0K PiBjYXBhYmxlIGFuZCBTUk1TIGFkdmVydGlzZW1lbnRzIGNvdmVyIHByZWZpeCBTSURzIGZvciB0 aGUgYWRkcmVzc2VzDQo+IGFzc29jaWF0ZWQgd2l0aCBSb3V0ZXIgQS4NCj4gPj4+IEkgdGhlbiB1 cGdyYWRlIFJvdXRlciBBIHRvIGJlY29tZSBTUiBjYXBhYmxlLiBCZWNhdXNlIEkgd2FudCB0byBk bw0KPiA+Pj4g4oCcbWFrZS1iZWZvcmUtYnJlYWvigJ0gSSBkbyBub3QgaW1tZWRpYXRlbHkgcmVt b3ZlIHRoZSBTUk1TDQo+ID4+PiBhZHZlcnRpc2VtZW50cyBjb3ZlcmluZyB0aGUgYWRkcmVzc2Vz IGFzc29jaWF0ZWQgd2l0aCBSb3V0ZXIgQS4gSQ0KPiA+Pj4gdXBncmFkZSBBLCBhZGQgY29uZmln dXJhdGlvbiBvZiBTSURzIGxvY2FsbHkgb24gUm91dGVyIEEsIGFuZA0KPiA+Pj4gdmVyaWZ5IHRo YXQgdGhlIGFkdmVydGlzZW1lbnRzIG9yaWdpbmF0aW5nIGZyb20gcHJvdG9jb2xzIG9uIFJvdXRl cg0KPiA+Pj4gQQ0KPiA+IGFyZSBjb3JyZWN0LiBJZiBhbiBpbmNvbnNpc3RlbmN5IGlzIGludHJv ZHVjZWQgd2hlbiBjb25maWd1cmluZyB0aGUNCj4gPiBTSURzIG9uIFJvdXRlciBBIHRoZW4gSSB3 aWxsIGhhdmUgYW4gU1JNUyBhZHZlcnRpc2VtZW50IGFuZCBhDQo+ID4gcHJlZml4LXJlYWNoYWJp bGl0eSBhZHZlcnRpc2VtZW50IHRoYXQgY29uZmxpY3QuIFVudGlsIHRoZSBjb25mbGljdCBpcw0K PiA+IGNvcnJlY3RlZCB3ZSB1c2UgdGhlIGNvbmZsaWN0IHJlc29sdXRpb24gcnVsZXMgdG8gcHJv dmlkZQ0KPiA+IGRldGVybWluaXN0aWMgZm9yd2FyZGluZyBiZWhhdmlvci4NCj4gPj4+DQo+ID4+ PiBUaGlzIHRvIG1lIGlzIGEgbm9ybWFsIGFuZCBleHBlY3RlZCB1cGdyYWRlIHNjZW5hcmlvLg0K PiA+Pj4NCj4gPj4+DQo+ID4+PiBUaGlzIGlzIG9uZSBvZiB0aGUgcmVhc29ucyBvZiBteSBmaXJz dCBjb21tZW50IGJlbG93LiBZb3UgZ290IHRvDQo+IHNlcGFyYXRlIHRoZSByZWFjaGFiaWxpdHkg YWR2ZXJ0aXNlbWVudHMgYW5kIFNSTVMgYWR2ZXJ0aXNlbWVudHM7IGFzIGluDQo+IHByaW5jaXBs ZSB0aGVzZSBhcmUgZGVmaW5lZCBmb3IgZGlmZmVyZW50IHB1cnBvc2VzLiBJIGRvbuKAmXQgc2Vl IHdlICBuZWVkDQo+IGFsZ29yaXRobSB0byBwcmVmZXIgcmVhY2hhYmlsaXR5IGFkdmVydGlzZW1l bnQgIG92ZXIgU1JNUyBhZHZlcnRpc2VtZW50IChpZg0KPiB3ZSBkb27igJl0IGNvbXBhcmUgdGhl c2UgMiBjYXRlZ29yaWVzKS4NCj4gPj4+DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IFtMZXM6XSBJIGRp c2FncmVlIOKAkyBob3BlZnVsbHkgbXkgY29tbWVudHMgaGF2ZSBoZWxwZWQgeW91IHRvDQo+IHVu ZGVyc3RhbmQgd2h5Lg0KPiA+Pj4NCj4gPj4+ICAgICBMZXMNCj4gPj4+DQo+ID4+Pg0KPiA+Pj4g YXMgdGhlIHNlY3Rpb25zIHlvdSBoYXZlIHF1b3RlZCBjbGVhcmx5IHN0YXRlLg0KPiA+Pj4NCj4g Pj4+IFdoeT8gQmVjYXVzZSB3ZSBuZWVkIGNvbnNpc3RlbnQgdXNlIG9mIFNJRHMgaW4gdGhlIGZv cndhcmRpbmcgcGxhbmUuDQo+IEZyb20gZm9yd2FyZGluZyBwZXJzcGVjdGl2ZSBpdCBtYXR0ZXJz IG5vdCB3aGV0aGVyIHRoZSBTSUQgd2FzIGFkdmVydGlzZWQNCj4gYnkgcHJvdG9jb2wgaW5zdGFu Y2UgIzEgb3IgIzIgb3IgYnkgYW4gU1JNUy4NCj4gPj4+DQo+ID4+PiBXaGF0IG1hdHRlcnMgaXMg dGhhdCB0aGUgU0lEIEkgdXNlIHRvIGRldGVybWluZSB3aGF0IGxhYmVsIEkgaW5zdGFsbCBpbiBt eQ0KPiBmb3J3YXJkaW5nIHBsYW5lIGlzIHRoZSBzYW1lIFNJRCB0aGF0IG15IG5laWdoYm9ycyB3 aWxsIHVzZS4gT3RoZXJ3aXNlDQo+IGZvcndhcmRpbmcgd2lsbCBiZSBicm9rZW4uDQo+ID4+Pg0K PiA+Pj4gICAgIExlcw0KPiA+Pj4NCj4gPj4+DQo+ID4+PiBGcm9tOiBzcHJpbmcgW21haWx0bzpz cHJpbmctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFVtYQ0KPiA+Pj4gQ2h1bmR1cmkN Cj4gPj4+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMjcsIDIwMTYgNDozMSBQTQ0KPiBUbzpicnVu by5kZWNyYWVuZUBvcmFuZ2UuY29tDQo+ID4+PiA8bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5n ZS5jb20+Ow0KPiA+IHNwcmluZ0BpZXRmLm9yZyA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4g Pj4+IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBkcmFmdC1naW5zYmVyZy1zcHJpbmctY29uZmxpY3Qt cmVzb2x1dGlvbiAtIFdHDQo+ID4+PiBhZG9wdGlvbiBjYWxsDQo+ID4+Pg0KPiA+Pj4gRGVhciBB dXRob3JzLA0KPiA+Pj4NCj4gPj4+IEhhdmUgZmV3IGNvbW1lbnRzIG9uIHRoZSBkcmFmdDoNCj4g Pj4+DQo+ID4+PiAxLg0KPiA+Pj4gICAgICAgICAgQXMgSSBpbmRpY2F0ZWQgZHVyaW5nIG1lZXRp bmcgLSBJIGFtIG5vdCBzdXJlIHdoeSB3ZSBoYXZlIHRvIGNsdWINCj4gdmVyaWZpY2F0aW9uIG9m IFNJRHMgYWR2ZXJ0aXNlZCB0aHJvdWdoIHJlZ3VsYXIgcHJvdG9jb2wgcmVhY2hhYmlsaXR5DQo+ ID4+PiAgICAgICAgICAgICAgICAgIHByZWZpeGVzIGFuZCB0aGUgcmFuZ2VzIGFkdmVydGlzZWQg dGhyb3VnaCAnTWFwcGluZyBTZXJ2ZXInDQo+IChTUk1TKS4gSSBkaWRuJ3Qgc2VlIGFueSBjb21w ZWxsaW5nIHJlYXNvbiB0byBkbyB0aGlzLg0KPiA+Pj4gICAgICAgICAgICAgICAgICAgU0lEcyBh ZHZlcnRpc2VkIHRocm91Z2ggcmVhY2hhYmlsaXR5IHByZWZpeGVzIGRvZXNuJ3QgaGF2ZQ0KPiBy YW5nZXMgdW5saWtlIFNSTVMgYWR2ZXJ0aXNlbWVudHMuDQo+ID4+PiAgICAgICAgICAgICAgICAg ICBBcyBTUk1TIGFkdmVydGlzZW1lbnRzIGFyZSBwcmltYXJpbHkgZm9yIG5vZGVzIHdoaWNoIGFy ZSBub3QNCj4gU1IgY2FwYWJsZSBhbmQgIEkgZmVlbCB3ZSBzaG91bGQgbm90IG1peCB0aGlzIHdp dGggbm9kZXMgd2hpY2ggYXJlIFNSDQo+IGNhcGFibGUuDQo+ID4+Pg0KPiA+Pj4gICAgICAgICAg VGhpcyBpc29sYXRpb24gaGVscHMgcmVzdHJpY3RpbmcgdGhlIHJlc29sdXRpb24gd29yayBwcmlt YXJpbHkgZm9yDQo+IG11bHRpcGxlIFNSTVMgZW50cmllcyBhZHZlcnRpc2VkIHRocm91Z2ggb25l IG5vZGUgb3IgbXVsdGlwbGUgbm9kZXMuDQo+ID4+PiAgICAgICAgICAgICAgICAgIFNSTVMgYWR2 ZXJ0aXNlbWVudHMgYXJlIGluZGVlZCBsaXR0bGUgYml0IHVuaXF1ZSBpbiB0aGF0IHlvdSBhcmUN Cj4gYWR2ZXJ0aXNpbmcgImNvbmZpZ3VyYXRpb24iIG9uIGJlaGFsZiBvZiBub2RlIFggZnJvbSBu b2RlIFkNCj4gPj4+ICAgICAgICAgICAgICAgICAgd2l0aCByYW5nZXMgKGJvdGggcHJlZml4IHJh bmdlcyBhbmQgU0lEIHJhbmdlcykuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IDIuDQo+ID4+PiAgICAg ICAgICAgICAgICAgIFJlZ2FyZGluZyAgdGhlIHNjb3BlIG9mIGNvbmZsaWN0IHJlc29sdXRpb246 DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+ICAgICAgICAgU2VjdGlvbiAxDQo+ID4+Pg0KPiA+Pj4gICAg ICAgICAgICAgIiAgIFRoZSBwcm9ibGVtIHRvIGJlIGFkZHJlc3NlZCBpcyBwcm90b2NvbCBpbmRl cGVuZGVudCBpLmUuLA0KPiBzZWdtZW50DQo+ID4+PiAgICAgICAgICAgcmVsYXRlZCBhZHZlcnRp c2VtZW50cyBtYXkgYmUgb3JpZ2luYXRlZCBieSBtdWx0aXBsZSBub2RlcyB1c2luZw0KPiA+Pj4g ICAgICAgICAgIGRpZmZlcmVudCBwcm90b2NvbHMgYW5kIHlldCB0aGUgY29uZmxpY3QgcmVzb2x1 dGlvbiBNVVNUIGJlIHRoZQ0KPiBzYW1lDQo+ID4+PiAgICAgICAgICAgb24gYWxsIG5vZGVzIHJl Z2FyZGxlc3Mgb2YgdGhlIHByb3RvY29sIHVzZWQgdG8gdHJhbnNwb3J0IHRoZQ0KPiA+Pj4gICAg ICAgICAgIGFkdmVydGlzZW1lbnRzLiINCj4gPj4+DQo+ID4+PiAgICAgICAgICBTZWN0aW9uIDMu Mi44DQo+ID4+PiAgICAgICAgICAgICIgICBvICBJbiBjYXNlcyB3aGVyZSBtdWx0aXBsZSByb3V0 aW5nIHByb3RvY29scyBhcmUgaW4gdXNlIG1hcHBpbmcNCj4gPj4+ICAgICAgICBlbnRyaWVzIGFk dmVydGlzZWQgYnkgYWxsIHJvdXRpbmcgcHJvdG9jb2xzIE1VU1QgYmUgaW5jbHVkZWQuIg0KPiA+ Pj4NCj4gPj4+ICAgICAgICBUaGlzIHNvdW5kcyBsaWtlIHdlIGFyZSBzZWVraW5nIHRvIHJlc29s dmUgY29uZmxpY3RpbmcgZW50cmllcyBvdXRzaWRlDQo+IGFuZCBhY3Jvc3MgdGhlIHByb3RvY29s cz8NCj4gPj4+ICAgICAgICBFYWNoIElHUCBoYXMgc2VwYXJhdGUgbWVjaGFuaXNtIGZvciBhZHZl cnRpc2luZyBtYXBwaW5nIGVudHJ5IGFuZA0KPiBJIHRoaXMgaXMgbm90IGNsZWFyIHdpdGggdGhl IGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgZHJhZnQgaG93IHdlIGNhbiBjcm9zcyB2ZXJpZnkNCj4g U0lEL1ByZWZpeCBjb25mbGljdCBhY3Jvc3MgIHRoZSBwcm90b2NvbC4NCj4gPj4+ICAgICAgIENh biB5b3UgY2xhcmlmeSB0aGlzPw0KPiA+Pj4NCj4gPj4+DQo+ID4+PiAtLQ0KPiA+Pj4gVW1hIEMu DQo+ID4+Pg0KPiA+Pj4NCj4gPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+PiBG cm9tOiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m DQo+ID4+PmJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20gPG1haWx0bzpicnVuby5kZWNyYWVuZUBv cmFuZ2UuY29tPg0KPiA+Pj4gU2VudDogVGh1cnNkYXksIEFwcmlsIDE0LCAyMDE2IDEyOjU1IEFN ICBUbzpzcHJpbmdAaWV0Zi5vcmcNCj4gPj4+PG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ID4+ PiBTdWJqZWN0OiBSZTogW3NwcmluZ10gZHJhZnQtZ2luc2Jlcmctc3ByaW5nLWNvbmZsaWN0LXJl c29sdXRpb24gLSBXRw0KPiA+Pj5hZG9wdGlvbiBjYWxsDQo+ID4+Pg0KPiA+Pj4+IEZyb206YnJ1 bm8uZGVjcmFlbmVAb3JhbmdlLmNvbQ0KPiA8bWFpbHRvOmJydW5vLmRlY3JhZW5lQG9yYW5nZS5j b20+ID4gU2VudDoNCj4gPiBUaHVyc2RheSwgQXByaWwgMTQsIDIwMTYNCj4gPj4+PiA5OjUxIEFN DQo+ID4+Pj4NCj4gPj4+PiBEZWFyIFdHLA0KPiA+Pj4+DQo+ID4+Pj4gQXMgd2UgZGlzY3Vzc2Vk IGF0IG91ciBtZWV0aW5nIGxhc3Qgd2Vlaywgd29ya2luZyBncm91cCBhZG9wdGlvbg0KPiA+Pj4+ IGhhcyBiZWVuIHJlcXVlc3RlZCBmb3IgZHJhZnQtZ2luc2Jlcmctc3ByaW5nLWNvbmZsaWN0LXJl c29sdXRpb24uDQo+ID4+Pj4gUGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0IHdpdGggeW91ciBjb21t ZW50cywgaW5jbHVkaW5nIGFsdGhvdWdoIG5vdA0KPiA+Pj4+IGxpbWl0ZWQgdG8gd2hldGhlciBv ciBub3QgeW91IHN1cHBvcnQgYWRvcHRpb24uDQo+ID4+Pg0KPiA+Pj4gV2Ugd2lsbCBlbmQgdGhl IGNhbGwgb24gQXByaWwgMjksIDIwMTYuDQo+ID4+Pg0KPiA+Pj4NCj4gPj4+PiBUaGFua3MsDQo+ ID4+Pj4NCj4gPj4+PiAtLUpvaG4gYW5kIEJydW5vDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ ID4+Pj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiA+Pj4+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+PiBfX19fXw0KPiA+Pj4+DQo+ID4+Pj4gQ2Ug bWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3Jt YXRpb25zDQo+ID4+Pj4gY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2 ZW50IGRvbmMgcGFzIGV0cmUNCj4gPj4+PiBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBz YW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UNCj4gPj4+PiBjZSBtZXNzYWdlIHBh ciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlDQo+ID4+ Pj4gZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVs ZWN0cm9uaXF1ZXMNCj4gPj4+PiBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaQ0KPiBjZSBtZXNzYWdlIGEgZXRlIGFs dGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+ID4+Pj4NCj4gPj4+PiBUaGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3INCj4g Pj4+PiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7 IHRoZXkgc2hvdWxkDQo+ID4+Pj4gbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3 aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+ID4+Pj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+ID4+Pj4gYW5kIGRlbGV0 ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4gPj4+PiBBcyBlbWFpbHMgbWF5 IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0DQo+ID4+ Pj4gaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gPj4+PiBUaGFu ayB5b3UuDQo+ID4+Pj4NCj4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+Pj4+IHNwcmluZyBtYWlsaW5nIGxpc3QNCj4gPj4+PnNwcmluZ0Bp ZXRmLm9yZyA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gPj4+Pmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQo+ID4+Pg0KPiA+Pj4NCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBfX19fX19f X19fDQo+ID4+PiBfIF8gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4+Pg0KPiA+Pj4gQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zDQo+ID4+PiBjb25maWRlbnRpZWxsZXMg b3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZQ0KPiA+Pj4gZGlmZnVz ZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiBy ZWN1DQo+ID4+PiBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEg bCdleHBlZGl0ZXVyICBldCBsZQ0KPiA+Pj4gZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMg am9pbnRlcy4gTGVzIG1lc3NhZ2VzDQo+ID4gZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJs ZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZQ0KPiA+IHJlc3BvbnNhYmlsaXRl IHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4N Cj4gPj4+DQo+ID4+PiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFp biBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZA0KPiBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsDQo+IHVzZWQg b3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4gPj4+IElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQNCj4g ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiA+Pj4gQXMgZW1haWxz IG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBo YXZlDQo+IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiA+Pj4gVGhhbmsg eW91Lg0KPiA+Pj4NCj4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4+PiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+ID4+PnNwcmluZ0BpZXRmLm9y ZyA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gPj4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zcHJpbmcNCj4gPj4+DQo+ID4+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gc3ByaW5nIG1haWxpbmcgbGlzdA0KPiA+ Pj5zcHJpbmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ID4+Pmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQo+ID4+DQo+ID4+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+IHNwcmluZyBtYWls aW5nIGxpc3QNCj4gPj5zcHJpbmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ ID4+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCj4gPj4NCg0K From nobody Sat May 14 11:06:57 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE7E12D1CC for ; Sat, 14 May 2016 11:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.046 X-Spam-Level: X-Spam-Status: No, score=-14.046 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8ef5b4FKu0b for ; Sat, 14 May 2016 11:06:54 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5765512D09E for ; Sat, 14 May 2016 11:06:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17007; q=dns/txt; s=iport; t=1463249214; x=1464458814; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=utyP39szIjZAL9btEzbMT+82bEfyW4WK7DzR4yHPXzA=; b=GFAUJduUZ7yY5GbXVCTRWktN7t6aGubgnDOOen42AmOtsubmFM1x0PwP r0l8JvvaEs1Zi8oMgJy+ouyi2LM8KxHEhXY3jzdLgAilmikhr2Ej2EKgm XjPC3B6i6JGYz7J2y94OtUI6VoJqons+3f/5ZnLb2qKfdSxuSUKe6W+v8 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CkAgAraDdX/4ENJK1egmxLVX4GtGeEd?= =?us-ascii?q?wENgXaGEQKBIjgUAQEBAQEBAWUnhEIBAQEDAS1RCwIBCBEEAQEoBzIUCQgBAQQ?= =?us-ascii?q?BEgiIHwjDTwEBAQEBAQEBAQEBAQEBAQEBAQEBARyGJYRNhBERAUgKhSMFjheFG?= =?us-ascii?q?YR3AYh1hSGBcIRPiGGPQAEeAQFCggYbgUtuhlE2fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,619,1454976000"; d="scan'208,217";a="272087776" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 May 2016 18:06:52 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u4EI6qhu018473 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 14 May 2016 18:06:52 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 14 May 2016 13:06:52 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Sat, 14 May 2016 13:06:52 -0500 From: "Les Ginsberg (ginsberg)" To: "bruno.decraene@orange.com" , "spring@ietf.org" Thread-Topic: [spring] draft-ietf-spring-conflict-resolution - Preference Algorithm Thread-Index: AdGsH1sN5kVjpbgWTcWyrGraBNd0gwB4zvjA Date: Sat, 14 May 2016 18:06:51 +0000 Message-ID: <2b41c4bcfe7f45bdaba9a72ea7bc9e20@XCH-ALN-001.cisco.com> References: <9871_1463066551_57349FB7_9871_4893_2_53C29892C857584299CBF5D05346208A0F8A48CF@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <9871_1463066551_57349FB7_9871_4893_2_53C29892C857584299CBF5D05346208A0F8A48CF@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.107.134] Content-Type: multipart/alternative; boundary="_000_2b41c4bcfe7f45bdaba9a72ea7bc9e20XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Preference Algorithm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2016 18:06:56 -0000 --_000_2b41c4bcfe7f45bdaba9a72ea7bc9e20XCHALN001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bruno - Thanx for your comments - inline. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution - Preference Algori= thm Hi authors, all As an individual contributor, please find below some feedback to trigger di= scussion on the Preference Algorithm defined in =A73.2.4. > 1. Smaller range wins Looks ok to me, as this gives preference to Prefix-SID advertisement from S= R routers which speaks for themselves/their own loopback/their own IP prefi= x advertisement; rather than SRMS advertisement which speaker for others. I= OW, to know Brian's SID, I'd rather believe Brian himself rather than Georg= e. Also, this gives preference to SR nodes rather than LDP nodes (SRMS entries= ). Over the time/SR deployment, as more nodes gets SR, the number of nodes = negatively impacted by the wrong configuration change is reduced. Alternatively, I'd be fine to prefer Prefix-SID advertisement over SRMS adv= ertisement. Actually, I'd propose to add this as rule 0. "0. Prefer Prefix-= SID Sub-TLV over SID/Label Binding TLV" I've been told OSPF can't make the distinction, but I'm not sure to see the= issue. [Les:] (I don't see the OSPF issue either.) This change is certainly possible. One reason we did not choose this direct= ion is because it is just as possible to misconfigure local SID configurati= on associated with a prefix advertisement as it is to misconfigure an SRMS = advertisement. In the event we are migrating nodes from being non-SR capabl= e to SR capable we could have: 1.1.1.1/32 100 range 1 !SRMS advertisement 1.1.1.1/32 1000 range 1 !Prefix advertisement - added when a Node becomes S= R capable It seems more consistent to resolve based on the attributes of the advertis= ement rather than its source. > 4. Smaller prefix length wins I'd rather have longer prefix length wins, and move this higher in position= 3 (*). Indeed, we usually primarily care to reach a specific egress node i= .e. loopbacks destinations, which have the longest possible prefix length. (*) It needs to be after IPv6 wins, to not conflict with it, as IPv6 have l= onger prefixes. [Les:] I am fine with this change. I think the existing rules just used "sm= aller" as the tie breaker in all cases, but you have a point that in this c= ase "longer" makes more sense. Les > 3. Smaller algorithm wins > 5. Smaller starting address (considered as an unsigned integer value) wins I'm fine with this order, to privilege prefix diversity (typically for algo= 0 or 1) rather than algo diversity. (on the basis that to reach a node N, = we need a SID for this node, while to follow algo N, we can use a combinati= ons of segments from other algo). So in summary, I'd propose discussing the following OLD: 1. Smaller range wins 2. IPv6 entry wins over IPv4 entry 3. Smaller algorithm wins 4. Smaller prefix length wins 5. Smaller starting address (considered as an unsigned integer value) w= ins 6. Smaller starting SID wins NEW: 0. Prefix-SID Sub-TLV wins over SID/Label Binding TLV 1. Smaller range wins 2. IPv6 entry wins over IPv4 entry 3. Longer prefix length wins 4. Smaller algorithm wins 5. Smaller starting address (considered as an unsigned integer value) w= ins 6. Smaller starting SID wins Thanks, Regards, -- Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_2b41c4bcfe7f45bdaba9a72ea7bc9e20XCHALN001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Bruno  -

 

Thanx for your comment= s – inline.

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution - Preference= Algorithm

 

Hi authors, all<= /p>

 

As an individual contributor, please find below some= feedback to trigger discussion on the Preference Algorithm defined in =A73= .2.4.

 

>   1.  Smaller range wins

Looks ok to me, as this gives preference to Prefix-S= ID advertisement from SR routers which speaks for themselves/their own loop= back/their own IP prefix advertisement; rather than SRMS advertisement whic= h speaker for others. IOW, to know Brian’s SID, I’d rather believe Brian himself rather than Geor= ge.

 

Also, this gives preference to SR nodes rather than = LDP nodes (SRMS entries). Over the time/SR deployment, as more nodes gets S= R, the number of nodes negatively impacted by the wrong configuration chang= e is reduced.

 

Alternatively, I’d be fine to prefer Prefix-SID adv=
ertisement over SRMS advertisement. Actually, I’d propose to add this=
 as rule 0. “0. Prefer Prefix-SID Sub-TLV over SID/Label Binding TLV&=
#8221;

I’ve been told OSPF can’t make the disti= nction, but I’m not sure to see the issue.

 

[Les:] (I don= 217;t see the OSPF issue either.)

This change is c= ertainly possible. One reason we did not choose this direction is because i= t is just as possible to misconfigure local SID configuration associated wi= th a prefix advertisement as it is to misconfigure an SRMS advertisement. In the event we are migrating nodes fr= om being non-SR capable to SR capable we could have:<= /b>

 

1.1.1.1/32 100 r= ange 1 !SRMS advertisement

1.1.1.1/32 1000 = range 1 !Prefix advertisement – added when a Node becomes SR capable<= o:p>

 

It seems more co= nsistent to resolve based on the attributes of the advertisement rather tha= n its source.

 

> 4.  Smaller prefix length wins

I’d rather have longer prefix length wins, and= move this higher in position 3 (*). Indeed, we usually primarily care to r= each a specific egress node i.e. loopbacks destinations, which have the lon= gest possible prefix length.

(*) It needs to be after IPv6 wins, to not conflict = with it, as IPv6 have longer prefixes.

 
[Les:] I am fine with this change. I =
think the existing rules just used “smaller” as the tie breaker=
 in all cases, but you have a point that in this case “longer” =
makes more sense.
 
   Les
  
>   3.  Smaller algorithm wins
>   5.  Smaller starting address (considered as an u=
nsigned integer
       value) wins
 

I’m fine with this order, to privilege prefix = diversity (typically for algo 0 or 1) rather than algo diversity. (on the b= asis that to reach a node N, we need a SID for this node, while to follow a= lgo N, we can use a combinations of segments from other algo).

 

 

So in summary, I’d propose discussing the foll= owing

OLD: 

   1.  Smaller range wins
   2.  IPv6 entry wins over IPv4 entry
   3.  Smaller algorithm wins
   4.  Smaller prefix length wins
   5.  Smaller starting address (considered as an unsig=
ned integer value) wins
   6.  Smaller starting SID wins

 

NEW:

 

   0.=
  Prefix-SID Sub-TLV wins over SID/Label Binding TLV=

   1.=
  Smaller range wins
   2.  IPv6 entry wins over IPv4 entry
   3.=
  Longer prefix length wins
   4.  Smaller algorithm wins
   5.  Smaller starting address (considered as an unsig=
ned integer value) wins
   6.  Smaller starting SID wins

 

Thanks,

Regards,

-- Bruno

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

Thank you.
--_000_2b41c4bcfe7f45bdaba9a72ea7bc9e20XCHALN001ciscocom_-- From nobody Sat May 14 11:29:36 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5482612D1C7 for ; Sat, 14 May 2016 11:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.046 X-Spam-Level: X-Spam-Status: No, score=-14.046 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZDz9tzfyCFd for ; Sat, 14 May 2016 11:29:33 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 507F712B008 for ; Sat, 14 May 2016 11:29:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23987; q=dns/txt; s=iport; t=1463250573; x=1464460173; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=HKSUDY/Q+zsmFJ5pTRMvV81NSxnroOgccCDr1uKbf9w=; b=kzXrSGFB/47pv4++FeXgBxp1UK0DBBb5TX72HQbuRlAMqTliCIRY/SDN tAzTdK8m5D/54q8qK9kuH8A4sogHyAGIyqJi+j6kGRL162yro+pm9RYi2 RV4HokYajhnTDzdee3bTAKE3L31zb7KLztWwUjCTbBh3Tl0MSXkIAcD6U 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAgAEbjdX/49dJa1egmxLVX4GuV4BD?= =?us-ascii?q?YF2hhECgSI4FAEBAQEBAQFlJ4RCAQEBAwEtUQsCAQgRBAEBFgsHBzIUCQgBAQQ?= =?us-ascii?q?BEgiIHwjDRAEBAQEBAQEBAQEBAQEBAQEBAQEBARyGJYRNhBEKBwFSCYUaBY4Xh?= =?us-ascii?q?QQVhHcBiHWFIYFwhE+EJYQ8j0ABHgEBQoIGG4FLboZICRcffwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,619,1454976000"; d="scan'208,217";a="272091267" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 May 2016 18:29:31 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u4EITVDA020190 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 14 May 2016 18:29:31 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 14 May 2016 13:29:30 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Sat, 14 May 2016 13:29:31 -0500 From: "Les Ginsberg (ginsberg)" To: "bruno.decraene@orange.com" , "spring@ietf.org" Thread-Topic: draft-ietf-spring-conflict-resolution Thread-Index: AdGsH1sLbD2noig8RN69oeD7/m3vEgB7FIAw Date: Sat, 14 May 2016 18:29:31 +0000 Message-ID: <963520eb14aa491f9ad01e1a834d64af@XCH-ALN-001.cisco.com> References: <5548_1463066557_57349FBD_5548_8297_1_53C29892C857584299CBF5D05346208A0F8A48D7@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <5548_1463066557_57349FBD_5548_8297_1_53C29892C857584299CBF5D05346208A0F8A48D7@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.107.134] Content-Type: multipart/alternative; boundary="_000_963520eb14aa491f9ad01e1a834d64afXCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2016 18:29:35 -0000 --_000_963520eb14aa491f9ad01e1a834d64afXCHALN001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bruno - Inline. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution Hi, As an individual contributor, please find below some comments: -- Isn't this document specific to the MPLS dataplane? If so, it could be indicated in the introduction, and possibly in the abstr= act. Then this indication could be removed from the 1rst sentence of sectio= ns 2 & 3. [Les:] Currently all discussion is regarding SR-MPLS. The draft leaves open= the possibility that if there is some SRv6 conflict resolution that needs = to be specified it could be added into this document - which is why the Int= roduction is dataplane agnostic, but each section states specifically that = it is relevant to SR-MPLS. I am not aware of any SRv6 conflict resolution that is required at this poi= nt, but I prefer to leave the possibility open if that is OK with you. -- =A73 "Mapping entries have an explicit context which includes the topology and t= he SR algorithm." A priori you could add "the routing protocol". [Les:] No - the source of advertisements is deliberately left out. It matte= rs not whether the source of the advertisement is a protocol or an SRMS - n= or does it matter which protocol provides the advertisement. You see that "= admin distance" is not mentioned at all and that is quite deliberate. This = insures that consistent choices are made on nodes regardless of which proto= col might have the best route on a given node. -- =A73 "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". If a router chooses to use one of the conflicting entries forwarding loops and/or blackholes may result unless it can be guaranteed that all other routers in the network make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. =BB I think we agree on the technical part, but I found the formulation slightl= y biased. I would propose "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". In order to avoid forwarding loops and/or blackholes, the= re is a need for all nodes to make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. This is the purpose of this document. =BB -- [Les:] I am fine with this change. =A73.1 "Various types of conflicts may occur" What about :s/Various/Two [Les:] "Two" is fine. Just means we will have to change it if we come up wi= th a third type of conflict. :) -- I agree with Robert's and Uma's comment with regards to making this confli= ct resolution an inter- protocol/routing_table issue. In particular, betwee= n SR domains, there is not requirement to have unique SIDs. Hence between P= E and CE, between ASes (both within and across organization), the same SID = could be reused independently). [Les:] There is more to be said on this topic - co-authors are actively dis= cussing this point and we'll respond more fully to Robert's post in time. B= ut, the draft is NOT trying to define conflict resolution across "SR domain= s". Perhaps we need language to make that more explicit. > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > Sent: Sunday,= May 01, 2016 7:11 AM > > We are indeed defining conflict resolution across all the SID advertiseme= nts regardless of source (protocol or SRMS) > Why? Because we need consistent use of SIDs in the forwarding plane No: in the forwarding plane, we need a consistent use of MPLS label. [Les:] As you know, SRGB range can be different for different nodes, so the= actual label that is used to send a packet for a given destination via Nod= e A may be different than the label used to send the same packet via Node B= . It is the SID that needs to be the same - not the label. It is true that SIDs are not installed in the forwarding plane - the labels= derived from the SID/SRGB are what is actually installed in the forwarding= plane - but I think my use of the word SID in this context is correct. Plus only within an SR domain. Actually, even within a domain, this is depe= ndent on whether SRGB is configured on a per node or a per protocol basis. = I'm not sure how much the agreement has been reached on that one. [Les:] The draft currently addresses deployments where a single (set of) SR= GB ranges applies to the box. This is by far the most common use case. Ther= e is a much more limited use case where protocol specific SRGBs and protoco= l specific SIDs may be required. The draft will address that in a future re= vision - but in spirit the same rules will apply - they will just have to t= ake into account "duplicate forwarding domains". Note that this will also r= equire multiple incoming label entries/prefix be supported by the routers i= n such a network. -- Typo: =A72 OLD : Range 3: (500, 5990 NEW : Range 3: (500, 599) (somewhat significant as otherwise range 3 conflict with range 2) [Les:] Agreed - thanx for spotting this. Les Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_963520eb14aa491f9ad01e1a834d64afXCHALN001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Bruno –

 

Inline.

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution

 

Hi,

 

As an individual contributor, please find below some= comments:

 

--

Isn’t this document specific to the MPLS datap= lane?

If so, it could be indicated in the introduction, an= d possibly in the abstract. Then this indication could be removed from the = 1rst sentence of sections 2 & 3.

 

[Les:] Currently= all discussion is regarding SR-MPLS. The draft leaves open the possibility= that if there is some SRv6 conflict resolution that needs to be specified = it could be added into this document – which is why the Introduction is dataplane agnostic, but each sect= ion states specifically that it is relevant to SR-MPLS.

 

I am not aware o= f any SRv6 conflict resolution that is required at this point, but I prefer= to leave the possibility open if that is OK with you.

 

--

=A73

“Mapping entries have an exp= licit context which includes the topology and the SR algorithm.“=

A priori you could add “the = routing protocol”.

 

[Les:] No – the source of advertisements is deliberately left= out. It matters not whether the source of the advertisement is a protocol = or an SRMS – nor does it matter which protocol provides the advertisement. You see that “admin distance” is n= ot mentioned at all and that is quite deliberate. This insures that consist= ent choices are made on nodes regardless of which protocol might have the b= est route on a given node.

 

--

=A73

“When conflicts occur, it is not
   possible for routers to know which of the conflicting adv=
ertisements
   is "correct".  If a router chooses to use =
one of the conflicting
   entries forwarding loops and/or blackholes may result unl=
ess it can
   be guaranteed that all other routers in the network make =
the same
   choice.  Making the same choice requires that all ro=
uters have
   identical sets of advertisements and that they all use th=
e same
   selection algorithm. =BB
 
I think we agree on the technical part, but I found the formulation sl=
ightly biased. I would propose
“When conflicts occur, it is not
   possible for routers to know which of the conflicting adv=
ertisements
   is "correct".  In order to avoid forwardin=
g loops and/or blackholes, there is a need for all nodes to make the same c=
hoice.
  Making the same choice requires that all routers have
   identical sets of advertisements and that they all use th=
e same
   selection algorithm. This is the purpose of this document=
. =BB

--

[Les:] I am fine= with this change.

 

=A73.1

“Various types of conflicts may occur”
What about :s/Various/Two

 

[Les:] “Tw= o” is fine. Just means we will have to change it if we come up with a= third type of conflict. J<= /span>

--

I agree with Robert’s  and Uma’s co= mment with regards to making this conflict resolution an inter- protocol/ro= uting_table issue. In particular, between SR domains, there is not requirem= ent to have unique SIDs. Hence between PE and CE, between ASes (both within and across organization), the same SID could be reused i= ndependently).

 

[Les:] There is = more to be said on this topic – co-authors are actively discussing th= is point and we’ll respond more fully to Robert’s post in time.= But, the draft is NOT trying to define conflict resolution across “SR domains”. Perhaps we need language to make that mor= e explicit.

 

> From: Les Ginsberg (gin= sberg) [m= ailto:ginsberg@cisco.com] > Sent: Sunday, May 01, 2016 7:11 AM

> =

> We are indeed defining conflict resoluti= on across all the SID advertisements regardless of source (protocol or SRMS= )

> Why? Because we nee= d consistent use of SIDs in the forwarding plane

 

No: in the forwarding plane, we need a consistent us= e of MPLS label.

[Les:] As you kn= ow, SRGB range can be different for different nodes, so the actual label th= at is used to send a packet for a given destination via Node A may be diffe= rent than the label used to send the same packet via Node B. It is the SID that needs to be the same – no= t the label.

It is true that = SIDs are not installed in the forwarding plane – the labels derived f= rom the SID/SRGB are what is actually installed in the forwarding plane = 211; but I think my use of the word SID in this context is correct.

 

Plus only within an SR domain. Actually, even within= a domain, this is dependent on whether SRGB is configured on a per node or= a per protocol basis. I’m not sure how much the agreement has been r= eached on that one.

 

[Les:] The draft= currently addresses deployments where a single (set of) SRGB ranges applie= s to the box. This is by far the most common use case. There is a much more= limited use case where protocol specific SRGBs and protocol specific SIDs may be required. The draft will address t= hat in a future revision – but in spirit the same rules will apply &#= 8211; they will just have to take into account “duplicate forwarding = domains”. Note that this will also require multiple incoming label entries/prefix be supported by the routers in such a networ= k.

 

--

Typo:

=A72

OLD : Range 3: (500, 5990

NEW : Range 3: (500, 599)

 

(somewhat significant as otherwise range 3 conflict with range 2)

 

[Les:] Agreed &#= 8211; thanx for spotting this.

 

   Les=

 

Thanks,

Regards,

Bruno

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

Thank you.
--_000_963520eb14aa491f9ad01e1a834d64afXCHALN001ciscocom_-- From nobody Sat May 14 12:27:15 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0477A12B01F for ; Sat, 14 May 2016 12:27:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.046 X-Spam-Level: X-Spam-Status: No, score=-14.046 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yH5OIKVc9O6L for ; Sat, 14 May 2016 12:27:12 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0392F12B04D for ; Sat, 14 May 2016 12:27:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26899; q=dns/txt; s=iport; t=1463254032; x=1464463632; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=b+I0wM75wVRGs5VycP8D3B8fEDivz4JBOGwnUdVmoX0=; b=mqsuLwn/h6KGxIPpjxK1nN57GkDjv1aTb675I3Akq6289Dvcg03jGD3O G/l2NhlfNzDB8bKE+uollUZIgU66YPuQ13RF/QMjVqUktzhfHQkPTTbSh 7Z72ufpH6NGxUmjKUCvWb7sJO3uxLOX6Q/7CRex505CVb5dsooHfTpAjO g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CzAgCdezdX/5RdJa1egmxLVX4GuV4BD?= =?us-ascii?q?YF2hhECHIEGOBQBAQEBAQEBZSeEQgEBAQMBIwpRCwIBCBEDAQEBKAMCAgIwFAk?= =?us-ascii?q?IAgQBEognCLJkkGcBAQEBAQEBAQEBAQEBAQEBAQEBAQEcinKEEREBBi0JDAqCS?= =?us-ascii?q?oJZBZMwhHcBiHWFKIFphE+IYY9AAR4BAUKCBhuBS26GUTZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,619,1454976000"; d="scan'208,217";a="273453451" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 May 2016 19:27:11 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u4EJR9N6010250 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 14 May 2016 19:27:10 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 14 May 2016 15:27:10 -0400 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1104.009; Sat, 14 May 2016 15:27:09 -0400 From: "Acee Lindem (acee)" To: "Les Ginsberg (ginsberg)" , "bruno.decraene@orange.com" , "spring@ietf.org" Thread-Topic: [spring] draft-ietf-spring-conflict-resolution - Preference Algorithm Thread-Index: AQHRrgt0iWVbCZRfYEuowlfMRWmTRJ+40R2A Date: Sat, 14 May 2016 19:27:09 +0000 Message-ID: References: <9871_1463066551_57349FB7_9871_4893_2_53C29892C857584299CBF5D05346208A0F8A48CF@OPEXCLILM21.corporate.adroot.infra.ftgroup> <2b41c4bcfe7f45bdaba9a72ea7bc9e20@XCH-ALN-001.cisco.com> In-Reply-To: <2b41c4bcfe7f45bdaba9a72ea7bc9e20@XCH-ALN-001.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.116.152.196] Content-Type: multipart/alternative; boundary="_000_D35CF21160F92aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Preference Algorithm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2016 19:27:14 -0000 --_000_D35CF21160F92aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTGVzLCBCcnVubywNCg0KU2VlIG9uZSBpbmxpbmUuDQoNCkZyb206IHNwcmluZyA8c3ByaW5n LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVo YWxmIG9mICJMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSIgPGdpbnNiZXJnQGNpc2NvLmNvbTxtYWls dG86Z2luc2JlcmdAY2lzY28uY29tPj4NCkRhdGU6IFNhdHVyZGF5LCBNYXkgMTQsIDIwMTYgYXQg MjowNiBQTQ0KVG86IEJydW5vIERlY3JhZW5lIDxicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPG1h aWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPj4sICJzcHJpbmdAaWV0Zi5vcmc8bWFpbHRv OnNwcmluZ0BpZXRmLm9yZz4iIDxzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9y Zz4+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVz b2x1dGlvbiAtIFByZWZlcmVuY2UgQWxnb3JpdGhtDQoNCkJydW5vICAtDQoNClRoYW54IGZvciB5 b3VyIGNvbW1lbnRzIOKAkyBpbmxpbmUuDQoNCkZyb206IHNwcmluZyBbbWFpbHRvOnNwcmluZy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgYnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbTxt YWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT4NClNlbnQ6IFRodXJzZGF5LCBNYXkgMTIs IDIwMTYgODoyMyBBTQ0KVG86IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3Jn Pg0KU3ViamVjdDogW3NwcmluZ10gZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlv biAtIFByZWZlcmVuY2UgQWxnb3JpdGhtDQoNCkhpIGF1dGhvcnMsIGFsbA0KDQpBcyBhbiBpbmRp dmlkdWFsIGNvbnRyaWJ1dG9yLCBwbGVhc2UgZmluZCBiZWxvdyBzb21lIGZlZWRiYWNrIHRvIHRy aWdnZXIgZGlzY3Vzc2lvbiBvbiB0aGUgUHJlZmVyZW5jZSBBbGdvcml0aG0gZGVmaW5lZCBpbiDC pzMuMi40Lg0KDQoNCj4gICAxLiAgU21hbGxlciByYW5nZSB3aW5zDQpMb29rcyBvayB0byBtZSwg YXMgdGhpcyBnaXZlcyBwcmVmZXJlbmNlIHRvIFByZWZpeC1TSUQgYWR2ZXJ0aXNlbWVudCBmcm9t IFNSIHJvdXRlcnMgd2hpY2ggc3BlYWtzIGZvciB0aGVtc2VsdmVzL3RoZWlyIG93biBsb29wYmFj ay90aGVpciBvd24gSVAgcHJlZml4IGFkdmVydGlzZW1lbnQ7IHJhdGhlciB0aGFuIFNSTVMgYWR2 ZXJ0aXNlbWVudCB3aGljaCBzcGVha2VyIGZvciBvdGhlcnMuIElPVywgdG8ga25vdyBCcmlhbuKA mXMgU0lELCBJ4oCZZCByYXRoZXIgYmVsaWV2ZSBCcmlhbiBoaW1zZWxmIHJhdGhlciB0aGFuIEdl b3JnZS4NCg0KQWxzbywgdGhpcyBnaXZlcyBwcmVmZXJlbmNlIHRvIFNSIG5vZGVzIHJhdGhlciB0 aGFuIExEUCBub2RlcyAoU1JNUyBlbnRyaWVzKS4gT3ZlciB0aGUgdGltZS9TUiBkZXBsb3ltZW50 LCBhcyBtb3JlIG5vZGVzIGdldHMgU1IsIHRoZSBudW1iZXIgb2Ygbm9kZXMgbmVnYXRpdmVseSBp bXBhY3RlZCBieSB0aGUgd3JvbmcgY29uZmlndXJhdGlvbiBjaGFuZ2UgaXMgcmVkdWNlZC4NCg0K DQpBbHRlcm5hdGl2ZWx5LCBJ4oCZZCBiZSBmaW5lIHRvIHByZWZlciBQcmVmaXgtU0lEIGFkdmVy dGlzZW1lbnQgb3ZlciBTUk1TIGFkdmVydGlzZW1lbnQuIEFjdHVhbGx5LCBJ4oCZZCBwcm9wb3Nl IHRvIGFkZCB0aGlzIGFzIHJ1bGUgMC4g4oCcMC4gUHJlZmVyIFByZWZpeC1TSUQgU3ViLVRMViBv dmVyIFNJRC9MYWJlbCBCaW5kaW5nIFRMVuKAnQ0KSeKAmXZlIGJlZW4gdG9sZCBPU1BGIGNhbuKA mXQgbWFrZSB0aGUgZGlzdGluY3Rpb24sIGJ1dCBJ4oCZbSBub3Qgc3VyZSB0byBzZWUgdGhlIGlz c3VlLg0KDQpbTGVzOl0gKEkgZG9u4oCZdCBzZWUgdGhlIE9TUEYgaXNzdWUgZWl0aGVyLikNCg0K SWYgaXQgaXMgYSByYW5nZSBhZHZlcnRpc2VtZW50LCBpdCBpcyBhY3R1YWxseSBlYXNpZXIgdG8g ZGV0ZWN0IGluIE9TUEYgc2luY2UgYSBzZXBhcmF0ZSB0b3AtbGV2ZWwgVExWIGlzIHVzZWQuIEZv ciBQcmVmaXgtU0lELCBPU1BGIGhhcyB0aGUgTS1mbGFnIGlkZW50aWZ5aW5nIG1hcHBpbmcgc2Vy dmVyIGFkdmVydGlzZW1lbnQuDQoNClRoYW5rcywNCkFjZWUNCg0KDQoNClRoaXMgY2hhbmdlIGlz IGNlcnRhaW5seSBwb3NzaWJsZS4gT25lIHJlYXNvbiB3ZSBkaWQgbm90IGNob29zZSB0aGlzIGRp cmVjdGlvbiBpcyBiZWNhdXNlIGl0IGlzIGp1c3QgYXMgcG9zc2libGUgdG8gbWlzY29uZmlndXJl IGxvY2FsIFNJRCBjb25maWd1cmF0aW9uIGFzc29jaWF0ZWQgd2l0aCBhIHByZWZpeCBhZHZlcnRp c2VtZW50IGFzIGl0IGlzIHRvIG1pc2NvbmZpZ3VyZSBhbiBTUk1TIGFkdmVydGlzZW1lbnQuIElu IHRoZSBldmVudCB3ZSBhcmUgbWlncmF0aW5nIG5vZGVzIGZyb20gYmVpbmcgbm9uLVNSIGNhcGFi bGUgdG8gU1IgY2FwYWJsZSB3ZSBjb3VsZCBoYXZlOg0KDQoxLjEuMS4xLzMyIDEwMCByYW5nZSAx ICFTUk1TIGFkdmVydGlzZW1lbnQNCjEuMS4xLjEvMzIgMTAwMCByYW5nZSAxICFQcmVmaXggYWR2 ZXJ0aXNlbWVudCDigJMgYWRkZWQgd2hlbiBhIE5vZGUgYmVjb21lcyBTUiBjYXBhYmxlDQoNCkl0 IHNlZW1zIG1vcmUgY29uc2lzdGVudCB0byByZXNvbHZlIGJhc2VkIG9uIHRoZSBhdHRyaWJ1dGVz IG9mIHRoZSBhZHZlcnRpc2VtZW50IHJhdGhlciB0aGFuIGl0cyBzb3VyY2UuDQoNCg0KPiA0LiAg U21hbGxlciBwcmVmaXggbGVuZ3RoIHdpbnMNCknigJlkIHJhdGhlciBoYXZlIGxvbmdlciBwcmVm aXggbGVuZ3RoIHdpbnMsIGFuZCBtb3ZlIHRoaXMgaGlnaGVyIGluIHBvc2l0aW9uIDMgKCopLiBJ bmRlZWQsIHdlIHVzdWFsbHkgcHJpbWFyaWx5IGNhcmUgdG8gcmVhY2ggYSBzcGVjaWZpYyBlZ3Jl c3Mgbm9kZSBpLmUuIGxvb3BiYWNrcyBkZXN0aW5hdGlvbnMsIHdoaWNoIGhhdmUgdGhlIGxvbmdl c3QgcG9zc2libGUgcHJlZml4IGxlbmd0aC4NCigqKSBJdCBuZWVkcyB0byBiZSBhZnRlciBJUHY2 IHdpbnMsIHRvIG5vdCBjb25mbGljdCB3aXRoIGl0LCBhcyBJUHY2IGhhdmUgbG9uZ2VyIHByZWZp eGVzLg0KDQoNCg0KW0xlczpdIEkgYW0gZmluZSB3aXRoIHRoaXMgY2hhbmdlLiBJIHRoaW5rIHRo ZSBleGlzdGluZyBydWxlcyBqdXN0IHVzZWQg4oCcc21hbGxlcuKAnSBhcyB0aGUgdGllIGJyZWFr ZXIgaW4gYWxsIGNhc2VzLCBidXQgeW91IGhhdmUgYSBwb2ludCB0aGF0IGluIHRoaXMgY2FzZSDi gJxsb25nZXLigJ0gbWFrZXMgbW9yZSBzZW5zZS4NCg0KDQoNCiAgIExlcw0KDQoNCg0KPiAgIDMu ICBTbWFsbGVyIGFsZ29yaXRobSB3aW5zDQoNCj4gICA1LiAgU21hbGxlciBzdGFydGluZyBhZGRy ZXNzIChjb25zaWRlcmVkIGFzIGFuIHVuc2lnbmVkIGludGVnZXINCg0KICAgICAgIHZhbHVlKSB3 aW5zDQoNCg0KSeKAmW0gZmluZSB3aXRoIHRoaXMgb3JkZXIsIHRvIHByaXZpbGVnZSBwcmVmaXgg ZGl2ZXJzaXR5ICh0eXBpY2FsbHkgZm9yIGFsZ28gMCBvciAxKSByYXRoZXIgdGhhbiBhbGdvIGRp dmVyc2l0eS4gKG9uIHRoZSBiYXNpcyB0aGF0IHRvIHJlYWNoIGEgbm9kZSBOLCB3ZSBuZWVkIGEg U0lEIGZvciB0aGlzIG5vZGUsIHdoaWxlIHRvIGZvbGxvdyBhbGdvIE4sIHdlIGNhbiB1c2UgYSBj b21iaW5hdGlvbnMgb2Ygc2VnbWVudHMgZnJvbSBvdGhlciBhbGdvKS4NCg0KDQpTbyBpbiBzdW1t YXJ5LCBJ4oCZZCBwcm9wb3NlIGRpc2N1c3NpbmcgdGhlIGZvbGxvd2luZw0KT0xEOg0KDQogICAx LiAgU21hbGxlciByYW5nZSB3aW5zDQoNCiAgIDIuICBJUHY2IGVudHJ5IHdpbnMgb3ZlciBJUHY0 IGVudHJ5DQoNCiAgIDMuICBTbWFsbGVyIGFsZ29yaXRobSB3aW5zDQoNCiAgIDQuICBTbWFsbGVy IHByZWZpeCBsZW5ndGggd2lucw0KDQogICA1LiAgU21hbGxlciBzdGFydGluZyBhZGRyZXNzIChj b25zaWRlcmVkIGFzIGFuIHVuc2lnbmVkIGludGVnZXIgdmFsdWUpIHdpbnMNCg0KICAgNi4gIFNt YWxsZXIgc3RhcnRpbmcgU0lEIHdpbnMNCg0KTkVXOg0KDQoNCiAgIDAuICBQcmVmaXgtU0lEIFN1 Yi1UTFYgd2lucyBvdmVyIFNJRC9MYWJlbCBCaW5kaW5nIFRMVg0KDQogICAxLiAgU21hbGxlciBy YW5nZSB3aW5zDQoNCiAgIDIuICBJUHY2IGVudHJ5IHdpbnMgb3ZlciBJUHY0IGVudHJ5DQoNCiAg IDMuICBMb25nZXIgcHJlZml4IGxlbmd0aCB3aW5zDQoNCiAgIDQuICBTbWFsbGVyIGFsZ29yaXRo bSB3aW5zDQoNCiAgIDUuICBTbWFsbGVyIHN0YXJ0aW5nIGFkZHJlc3MgKGNvbnNpZGVyZWQgYXMg YW4gdW5zaWduZWQgaW50ZWdlciB2YWx1ZSkgd2lucw0KDQogICA2LiAgU21hbGxlciBzdGFydGlu ZyBTSUQgd2lucw0KDQpUaGFua3MsDQpSZWdhcmRzLA0KLS0gQnJ1bm8NCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoN Cg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMg aW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVu dCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0 b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWls bGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN ZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWlu IGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3Rl Y3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVk LCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQo= --_000_D35CF21160F92aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <00E5EDDF03F9F041BBCC6F17FDD44E81@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IaSBMZXMsIEJy dW5vLCZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+U2VlIG9uZSBpbmxpbmUu Jm5ic3A7PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9T RUNUSU9OIj4NCjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0 OyB0ZXh0LWFsaWduOmxlZnQ7IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9u ZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5H LUxFRlQ6IDBpbjsgUEFERElORy1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBz b2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3Bh biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RnJvbTogPC9zcGFuPnNwcmluZyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIj5zcHJpbmctYm91bmNlc0BpZXRmLm9y ZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiAmcXVvdDtMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdpbnNiZXJnQGNpc2NvLmNvbSI+Z2luc2JlcmdAY2lzY28u Y29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9z cGFuPlNhdHVyZGF5LCBNYXkgMTQsIDIwMTYgYXQgMjowNiBQTTxicj4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPkJydW5vIERlY3JhZW5lICZsdDs8YSBocmVmPSJt YWlsdG86YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSI+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNv bTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdA aWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5z cHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5TdWJqZWN0OiA8L3NwYW4+UmU6IFtzcHJpbmddIGRyYWZ0LWlldGYtc3ByaW5nLWNvbmZsaWN0 LXJlc29sdXRpb24gLSBQcmVmZXJlbmNlIEFsZ29yaXRobTxicj4NCjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FV T1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1 OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdiB4bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQt Y29tOnZtbCIgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNl IiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczpt PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5z PSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVk LCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVk Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJ Zm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnAuUHJmb3JtYXRIVE1MLCBsaS5QcmZvcm1hdEhUTUwsIGRpdi5QcmZv cm1hdEhUTUwNCgl7bXNvLXN0eWxlLW5hbWU6IlByw6lmb3JtYXTDqSBIVE1MIjsNCgltc28tc3R5 bGUtbGluazoiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp Iiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5QcmZvcm1hdEhUTUxDYXINCgl7bXNvLXN0eWxlLW5hbWU6 IlByw6lmb3JtYXTDqSBIVE1MIENhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 IjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpGUjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcw Ljg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8ZGl2 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+QnJ1bm8gJm5ic3A7LTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ VGhhbnggZm9yIHlvdXIgY29tbWVudHMg4oCTIGlubGluZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5 OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij4gc3ByaW5nIFs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJv dW5jZXNAaWV0Zi5vcmciPm1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5P biBCZWhhbGYgT2YgPC9iPjxhIGhyZWY9Im1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29t Ij5icnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPC9hPjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2Rh eSwgTWF5IDEyLCAyMDE2IDg6MjMgQU08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzpz cHJpbmdAaWV0Zi5vcmciPnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4g W3NwcmluZ10gZHJhZnQtaWV0Zi1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbiAtIFByZWZlcmVu Y2UgQWxnb3JpdGhtPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRlIiPkhpIGF1dGhvcnMsIGFsbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBhbiBpbmRpdmlkdWFsIGNvbnRyaWJ1 dG9yLCBwbGVhc2UgZmluZCBiZWxvdyBzb21lIGZlZWRiYWNrIHRvIHRyaWdnZXIgZGlzY3Vzc2lv biBvbiB0aGUgUHJlZmVyZW5jZSBBbGdvcml0aG0gZGVmaW5lZCBpbiDCpzMuMi40LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cHJl PiZndDsmbmJzcDsmbmJzcDsgMS4mbmJzcDsgU21hbGxlciByYW5nZSB3aW5zPG86cD48L286cD48 L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxvb2tzIG9rIHRvIG1lLCBhcyB0aGlzIGdpdmVz IHByZWZlcmVuY2UgdG8gUHJlZml4LVNJRCBhZHZlcnRpc2VtZW50IGZyb20gU1Igcm91dGVycyB3 aGljaCBzcGVha3MgZm9yIHRoZW1zZWx2ZXMvdGhlaXIgb3duIGxvb3BiYWNrL3RoZWlyIG93biBJ UCBwcmVmaXggYWR2ZXJ0aXNlbWVudDsgcmF0aGVyIHRoYW4gU1JNUyBhZHZlcnRpc2VtZW50IHdo aWNoIHNwZWFrZXIgZm9yIG90aGVycy4gSU9XLCB0byBrbm93DQogQnJpYW7igJlzIFNJRCwgSeKA mWQgcmF0aGVyIGJlbGlldmUgQnJpYW4gaGltc2VsZiByYXRoZXIgdGhhbiBHZW9yZ2UuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFsc28sIHRoaXMgZ2l2ZXMgcHJlZmVyZW5jZSB0byBTUiBub2Rl cyByYXRoZXIgdGhhbiBMRFAgbm9kZXMgKFNSTVMgZW50cmllcykuIE92ZXIgdGhlIHRpbWUvU1Ig ZGVwbG95bWVudCwgYXMgbW9yZSBub2RlcyBnZXRzIFNSLCB0aGUgbnVtYmVyIG9mIG5vZGVzIG5l Z2F0aXZlbHkgaW1wYWN0ZWQgYnkgdGhlIHdyb25nIGNvbmZpZ3VyYXRpb24gY2hhbmdlIGlzIHJl ZHVjZWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7Ij5BbHRlcm5hdGl2ZWx5LCBJ4oCZZCBiZSBmaW5lIHRvIHBy ZWZlciBQcmVmaXgtU0lEIGFkdmVydGlzZW1lbnQgb3ZlciBTUk1TIGFkdmVydGlzZW1lbnQuIEFj dHVhbGx5LCBJ4oCZZCBwcm9wb3NlIHRvIGFkZCB0aGlzIGFzIHJ1bGUgMC4g4oCcMC4gUHJlZmVy IFByZWZpeC1TSUQgU3ViLVRMViBvdmVyIFNJRC9MYWJlbCBCaW5kaW5nIFRMVuKAnTxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmXZlIGJlZW4gdG9sZCBP U1BGIGNhbuKAmXQgbWFrZSB0aGUgZGlzdGluY3Rpb24sIGJ1dCBJ4oCZbSBub3Qgc3VyZSB0byBz ZWUgdGhlIGlzc3VlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bTGVzOl0g KEkgZG9u4oCZdCBzZWUgdGhlIE9TUEYgaXNzdWUgZWl0aGVyLik8L3NwYW4+PC9pPjwvYj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PklmIGl0IGlzIGEgcmFuZ2UgYWR2ZXJ0aXNlbWVudCwg aXQgaXMgYWN0dWFsbHkgZWFzaWVyIHRvIGRldGVjdCBpbiBPU1BGIHNpbmNlIGEgc2VwYXJhdGUg dG9wLWxldmVsIFRMViBpcyB1c2VkLiBGb3IgUHJlZml4LVNJRCwgT1NQRiBoYXMgdGhlIE0tZmxh ZyBpZGVudGlmeWluZyBtYXBwaW5nIHNlcnZlciBhZHZlcnRpc2VtZW50LiZuYnNwOzwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmtzLDwvZGl2Pg0KPGRpdj5BY2VlJm5ic3A7PC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGJsb2NrcXVvdGUgaWQ9Ik1B Q19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1 YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2IHht bG5zOnY9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206dm1sIiB4bWxuczpvPSJ1cm46c2NoZW1h cy1taWNyb3NvZnQtY29tOm9mZmljZTpvZmZpY2UiIHhtbG5zOnc9InVybjpzY2hlbWFzLW1pY3Jv c29mdC1jb206b2ZmaWNlOndvcmQiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGRpdiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPjwv bzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5UaGlzIGNoYW5nZSBpcyBjZXJ0YWlubHkgcG9zc2libGUu IE9uZSByZWFzb24gd2UgZGlkIG5vdCBjaG9vc2UgdGhpcyBkaXJlY3Rpb24gaXMgYmVjYXVzZSBp dCBpcyBqdXN0IGFzIHBvc3NpYmxlIHRvIG1pc2NvbmZpZ3VyZSBsb2NhbCBTSUQgY29uZmlndXJh dGlvbiBhc3NvY2lhdGVkIHdpdGggYSBwcmVmaXggYWR2ZXJ0aXNlbWVudCBhcyBpdCBpcyB0bw0K IG1pc2NvbmZpZ3VyZSBhbiBTUk1TIGFkdmVydGlzZW1lbnQuIEluIHRoZSBldmVudCB3ZSBhcmUg bWlncmF0aW5nIG5vZGVzIGZyb20gYmVpbmcgbm9uLVNSIGNhcGFibGUgdG8gU1IgY2FwYWJsZSB3 ZSBjb3VsZCBoYXZlOjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjEuMS4xLjEvMzIgMTAwIHJhbmdlIDEgIVNSTVMgYWR2ZXJ0 aXNlbWVudDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjEuMS4xLjEvMzIgMTAwMCByYW5n ZSAxICFQcmVmaXggYWR2ZXJ0aXNlbWVudCDigJMgYWRkZWQgd2hlbiBhIE5vZGUgYmVjb21lcyBT UiBjYXBhYmxlPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48aT48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+SXQgc2VlbXMgbW9yZSBjb25zaXN0ZW50IHRvIHJlc29sdmUgYmFz ZWQgb24gdGhlIGF0dHJpYnV0ZXMgb2YgdGhlIGFkdmVydGlzZW1lbnQgcmF0aGVyIHRoYW4gaXRz IHNvdXJjZS48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cHJlPiZndDsgNC4mbmJzcDsgU21hbGxlciBwcmVmaXggbGVuZ3RoIHdpbnM8bzpwPjwv bzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmWQgcmF0aGVyIGhhdmUgbG9uZ2Vy IHByZWZpeCBsZW5ndGggd2lucywgYW5kIG1vdmUgdGhpcyBoaWdoZXIgaW4gcG9zaXRpb24gMyAo KikuIEluZGVlZCwgd2UgdXN1YWxseSBwcmltYXJpbHkgY2FyZSB0byByZWFjaCBhIHNwZWNpZmlj IGVncmVzcyBub2RlIGkuZS4gbG9vcGJhY2tzIGRlc3RpbmF0aW9ucywgd2hpY2ggaGF2ZSB0aGUg bG9uZ2VzdCBwb3NzaWJsZSBwcmVmaXggbGVuZ3RoLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4oKikgSXQgbmVlZHMgdG8gYmUgYWZ0ZXIgSVB2NiB3aW5zLCB0byBub3Qg Y29uZmxpY3Qgd2l0aCBpdCwgYXMgSVB2NiBoYXZlIGxvbmdlciBwcmVmaXhlcy48bzpwPjwvbzpw PjwvcD4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 Ij5bTGVzOl0gSSBhbSBmaW5lIHdpdGggdGhpcyBjaGFuZ2UuIEkgdGhpbmsgdGhlIGV4aXN0aW5n IHJ1bGVzIGp1c3QgdXNlZCDigJxzbWFsbGVy4oCdIGFzIHRoZSB0aWUgYnJlYWtlciBpbiBhbGwg Y2FzZXMsIGJ1dCB5b3UgaGF2ZSBhIHBvaW50IHRoYXQgaW4gdGhpcyBjYXNlIOKAnGxvbmdlcuKA nSBtYWtlcyBtb3JlIHNlbnNlLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wcmU+DQo8cHJl PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBMZXM8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+Jm5ic3A7IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl PiZndDsmbmJzcDsmbmJzcDsgMy4mbmJzcDsgU21hbGxlciBhbGdvcml0aG0gd2luczxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPiZndDsgJm5ic3A7Jm5ic3A7NS4mbmJzcDsgU21hbGxlciBzdGFydGlu ZyBhZGRyZXNzIChjb25zaWRlcmVkIGFzIGFuIHVuc2lnbmVkIGludGVnZXI8bzpwPjwvbzpwPjwv cHJlPg0KPHByZT4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPHNwYW4gbGFu Zz0iRlIiPnZhbHVlKSB3aW5zPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J4oCZbSBmaW5lIHdpdGggdGhp cyBvcmRlciwgdG8gcHJpdmlsZWdlIHByZWZpeCBkaXZlcnNpdHkgKHR5cGljYWxseSBmb3IgYWxn byAwIG9yIDEpIHJhdGhlciB0aGFuIGFsZ28gZGl2ZXJzaXR5LiAob24gdGhlIGJhc2lzIHRoYXQg dG8gcmVhY2ggYSBub2RlIE4sIHdlIG5lZWQgYSBTSUQgZm9yIHRoaXMgbm9kZSwgd2hpbGUgdG8g Zm9sbG93IGFsZ28gTiwgd2UgY2FuIHVzZSBhIGNvbWJpbmF0aW9ucyBvZiBzZWdtZW50cw0KIGZy b20gb3RoZXIgYWxnbykuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gaW4gc3VtbWFyeSwgSeKAmWQgcHJvcG9zZSBk aXNjdXNzaW5nIHRoZSBmb2xsb3dpbmc8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9MRDogPG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOzEuJm5ic3A7 IFNtYWxsZXIgcmFuZ2Ugd2luczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyAy LiZuYnNwOyBJUHY2IGVudHJ5IHdpbnMgb3ZlciBJUHY0IGVudHJ5PG86cD48L286cD48L3ByZT4N CjxwcmU+Jm5ic3A7Jm5ic3A7IDMuJm5ic3A7IFNtYWxsZXIgYWxnb3JpdGhtIHdpbnM8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgNC4mbmJzcDsgU21hbGxlciBwcmVmaXggbGVu Z3RoIHdpbnM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgNS4mbmJzcDsgU21h bGxlciBzdGFydGluZyBhZGRyZXNzIChjb25zaWRlcmVkIGFzIGFuIHVuc2lnbmVkIGludGVnZXIg dmFsdWUpIHdpbnM8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgNi4mbmJzcDsg U21hbGxlciBzdGFydGluZyBTSUQgd2luczxvOnA+PC9vOnA+PC9wcmU+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5FVzo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHByZT4mbmJzcDsmbmJzcDsgPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1o aWdobGlnaHQ6eWVsbG93Ij4wLiZuYnNwOyBQcmVmaXgtU0lEIFN1Yi1UTFYgd2lucyBvdmVyIFNJ RC9MYWJlbCBCaW5kaW5nIFRMVjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsgPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93 Ij4xLiZuYnNwOyA8L3NwYW4+U21hbGxlciByYW5nZSB3aW5zPG86cD48L286cD48L3ByZT4NCjxw cmU+Jm5ic3A7Jm5ic3A7IDIuJm5ic3A7IElQdjYgZW50cnkgd2lucyBvdmVyIElQdjQgZW50cnk8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgPHNwYW4gc3R5bGU9ImJhY2tncm91 bmQ6eWVsbG93O21zby1oaWdobGlnaHQ6eWVsbG93Ij4zLiZuYnNwOyBMb25nZXIgPC9zcGFuPnBy ZWZpeCBsZW5ndGggd2luczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyA0LiZu YnNwOyBTbWFsbGVyIGFsZ29yaXRobSB3aW5zPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7 Jm5ic3A7IDUuJm5ic3A7IFNtYWxsZXIgc3RhcnRpbmcgYWRkcmVzcyAoY29uc2lkZXJlZCBhcyBh biB1bnNpZ25lZCBpbnRlZ2VyIHZhbHVlKSB3aW5zPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5i c3A7Jm5ic3A7IDYuJm5ic3A7IFNtYWxsZXIgc3RhcnRpbmcgU0lEIHdpbnM8bzpwPjwvbzpwPjwv cHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0gQnJ1bm88 bzpwPjwvbzpwPjwvcD4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBv dSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNv cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIg ZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJGUiI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNw YW4gbGFuZz0iRlIiPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1l c3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpwPjwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRp b24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRlIiPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNl ZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFu IGxhbmc9IkZSIj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxl IGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp ZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGFuayB5 b3UuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D35CF21160F92aceeciscocom_-- From nobody Sat May 14 15:40:41 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AADF12B030 for ; Sat, 14 May 2016 15:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.046 X-Spam-Level: X-Spam-Status: No, score=-14.046 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E9ZJj3vSUCRe for ; Sat, 14 May 2016 15:40:36 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DBE112B01F for ; Sat, 14 May 2016 15:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38554; q=dns/txt; s=iport; t=1463265635; x=1464475235; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=aieFKDy4AH2ACizTa7JSl/ZxuE2sRQLrxzOgGEJPfgc=; b=A5jWoKSwgN/YFrfFp15HnpGkjFdtdr04oTnzxEkHP6DqDu7ED8WLSL6d dygdCTgxyhBQh8Fc4id88pd79cCoXw3/jYCjs2hFdDXshtEnM3RhNUSk5 HjKYhx4bK2OI+aoFl+yEKrUkscVX1wPT7R9wabmj55cu+iRanVGPNTaje 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CyAgCWqDdX/4MNJK1egmxLVX4GuV4BD?= =?us-ascii?q?YF2hhECgSI4FAEBAQEBAQFlJ4RCAQEBBC1cAgEIEQQBASEBBgcyFAkIAQEEARI?= =?us-ascii?q?IiCfDLAEBAQEBAQEBAQEBAQEBAQEBAQEBARyGJYNKgQOEEREBBkIKhSMFhXCNQ?= =?us-ascii?q?IR3AYh1gm2CNIFwhE+IYY9AAR4BAUKCBhuBS26GUTZ/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,619,1454976000"; d="scan'208,217";a="272125775" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 May 2016 22:40:33 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u4EMeXMW001688 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 14 May 2016 22:40:33 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sat, 14 May 2016 17:40:32 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Sat, 14 May 2016 17:40:32 -0500 From: "Les Ginsberg (ginsberg)" To: "bruno.decraene@orange.com" , "spring@ietf.org" Thread-Topic: draft-ietf-spring-conflict-resolution - Policy Thread-Index: AdGsYbndUWczH5clSpukONRF0Kk37ABrjsLQ Date: Sat, 14 May 2016 22:40:32 +0000 Message-ID: <4bf6ef2278fd4e809203e988d8fba808@XCH-ALN-001.cisco.com> References: <24715_1463066559_57349FBF_24715_2873_1_53C29892C857584299CBF5D05346208A0F8A48DE@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <24715_1463066559_57349FBF_24715_2873_1_53C29892C857584299CBF5D05346208A0F8A48DE@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.107.134] Content-Type: multipart/alternative; boundary="_000_4bf6ef2278fd4e809203e988d8fba808XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 May 2016 22:40:39 -0000 --_000_4bf6ef2278fd4e809203e988d8fba808XCHALN001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bruno - I am having difficulty parsing the examples you provide below as they seem = to incorporate advertisement source into the description whereas the draft = deliberately omits source. So it does not matter if R2 sends an advertiseme= nt or R12 sends advertisement or both of them do (which could happen when a= n advertisement is leaked) - what matters is what unique entries are in the= database independent of source. It would be good if you could present your examples using the format define= d in the draft i.e.: Pi - Initial prefix Pe - End prefix L - Prefix length Lx - Maximum prefix length (32 for IPv4, 128 for IPv6) Si - Initial SID value Se - End SID value R - Range value T - Topology A - Algorithm A Mapping Entry is then the tuple: (Pi/L, Si, R, T, A) Pe =3D (Pi + ((R-1) << (Lx-L)) Se =3D Si + (R-1) Example: (192.0.2.120/32, 200, 1, 0, 0) As regards your proposal - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID this to me specifies an implementation - which isn't necessary. However, there is one important point which has not been specified in the d= raft which reading your post has brought to my attention - that is the orde= r in which checks are made. The draft states: "Prefix conflicts are specific to mapping entries sharing the same topolog= y and algorithm." "SID conflicts are independent of address-family, independent of prefix le= n, independent of topology, and independent of algorithm." If we consider an example where a network supports two VPNs, the significan= ce of ordering in the evaluation of conflicts will be highlighted: VPN1: (192.0.2.1/32, 100, 1, 1, 0) (192.0.2.1/32, 200, 1, 1, 0) VPN2: (192.0.2.100/32, 200, 1, 2, 0) If we evaluate prefix conflicts first, then the following entries are "acti= ve": (192.0.2.1/32, 100, 1, 1, 0) !VPN1 (192.0.2.100/32, 200, 1, 2, 0) !VPN2 If we evaluate SID conflicts first, then the following entries are "active"= : (192.0.2.1/32, 100, 1, 1, 0) !VPN1 The latter choice is suboptimal because it prevents use of the VPN2 entry u= nnecessarily. This point needs to be made explicit in the draft. Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution - Policy Hi authors, all As an individual contributor, please find below some feedback on the policy= . I'm wondering if we could address the conflict on a per FEC/Prefix basis ra= ther than on a per IGP advertisement basis. If so, this may avoid the discussion between the Quarantine vs ignore polic= y. The problem that we need to solve, is to find the SID for a prefix (P1). The algo could be: - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts // as a result, we get a list of SIDi - Pij for P1 Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID / no SID availa= ble for this prefix P1 Note that it would probably be better for the preference algo to put the= SID tie-brake before the prefix tie-break as with the prefix tie-break, we= suffer from the conflict twice (Prefix - SID mapping, then SID- prefix map= ping) which increase the diversity and hence the chance of not finding a va= lid entry. But for the below examples, I used the preference algo from dr= aft-ietf-*-00 Below are examples, running this policy on typical configuration error case= s. Examples 3.4.4. Network operation Consider the following simple network example: 1. 100 nodes: R1 to R100; 2. IP Loopbacks are from 192.0.2.1 to 192.0.2.100: 3. SID are from 1 to 100; 4. R1 to R50 are SR capable and advertised their own SID using Prefix-SID sub-TLV; 5. R51 to R100 are SR non-capable, running LDP and their SID are advertised by two redundant Mapping Server MS1 and MS2; 6. As the number of nodes which are SR capable are expected to increase and as in real deployment their Loopback addresses would no the contiguous, the Mapping servers advertisement covers all Loopbacks: (192.0.2.1/32, 1, 100); Subsequent sections evaluate the consequences of a single configuration error, for all conflict resolution options. 3.4.4.1. Example 1: SID configured on 1 node conflict with SID configured on another node Following a typo during configuration, R2 is configured with a SID of 12. That SID conflicts with the Prefix-SID advertised by R12 and the Ma= pping Server Advertisement for R12. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R12, a single SID is advertised and hence selected= . For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID12 is selected for R2. For R12, the algo evaluates a conflict between the following advertismen= ts: R12 - SID12 - R12 (prefix SID, prefix SID) R12 - SID12 - R2 (prefix SID, prefix SID) R12 - SID12 - R12 (prefix SID, MS) R12 - SID12 - R2 (MS, prefix SID) R12 - SID12 - R12 (MS, MS) Best one is R12 - SID12 - R2 (smaller range (prefix SID),smaller range (= prefix SID), smaller starting adresse (R2)) R12 <> R2 =3D=3D> R12 has no SID. 3.4.4.2. Example 2: SID configured on 1 node conflict with SID configured on the Mapping Server Following a typo during configuration, R2 is configured with a SID of 52. That SID conflicts with the Mapping Server advertisements of MS1 and MS2 for the loopback of R52. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R52, a single SID is advertised and hence selected= . For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID52 - R2 (prefix SID, prefix SID) R2 - SID52 - R52 (prefix SID, MS) R2 - SID2 - R2 (MS, MS) Best one is R2 - SID52 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID52 is selected for R2. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS, MS) R52 - SID52 - R2 (MS, prefix SID) Best one is R52 - SID52 - R2 (smaller range (prefix SID)) R52 <> R2 =3D=3D> R52 has no SID. 3.4.4.3. Example 3: wrong configuration of a MS Following a typo during configuration, MS1 is configured (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0 instead of 192.0.2.1). That advertisement conflicts with the Mapping Server advertisements of MS2 and the Prefix-SID advertised by R1...R50. We have a conflict for all routers except R100. For LDP only routers R51 to R99 we have a conflict between both MS adver= tisement. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS2, MS2) R52 - SID52 - R51 (MS2, MS1) R52 - SID53 - R52 (MS1, MS1) R52 - SID53 - R53 (MS1, MS2) Best one is R52 - SID52 - R51 (smaller starting address) R52 <> R51 =3D=3D> R52 has no SID. For SR routers, R1 to 50, we have a conflict between both MS advertiseme= nt and Prefix SID advertisements. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 - SID 2 - R2 (Prefix SID, MS2) R2 - SID 2 - R1 (Prefix SID, MS1) R2 - SID 2 - R2 (MS2, MS2) R2 - SID 2 - R2 (MS2, Prefix SID) R2 - SID 2 - R1 (MS2, MS1) R2 - SID 3 - R2 (MS1, MS1) R2 - SID 3 - R3 (MS1, MS2) R2 - SID 3 - R3 (MS1, Prefix SID) Best one is R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 =3D=3D R2 hence R2 use SID2. Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_4bf6ef2278fd4e809203e988d8fba808XCHALN001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bruno –

 

I am having difficulty= parsing the examples you provide below as they seem to incorporate adverti= sement source into the description whereas the draft deliberately omits sou= rce. So it does not matter if R2 sends an advertisement or R12 sends advertisement or both of them do (which coul= d happen when an advertisement is leaked) – what matters is what uniq= ue entries are in the database independent of source.

 

It would be good if yo= u could present your examples using the format defined in the draft i.e.:

 

    Pi - Initial prefix

     Pe - End prefix

     L -  Prefix length<= /i>

     Lx - Maximum prefix length (32 for IPv4, 1= 28 for IPv6)

     Si - Initial SID value

     Se - End SID value

     R -  Range value

     T - Topology

     A - Algorithm

 

     A Mapping Entry is then the tuple: (Pi/L, = Si, R, T, A)

     Pe =3D (Pi + ((R-1) << (Lx-L))

     Se =3D Si + (R-1)

 

Example:     (192.0.2.120/32, 200, 1, 0, 0)

 

As regards your propos= al

 

- Find all SIDi advertised for the prefix P1    = ;            &n= bsp;            = ;            &n= bsp;            = ;     // identification of Prefix conflicts<= /span>

           &= nbsp;    - For each SIDi find all the prefix Pij associated = with SIDi            = ;  // identification of SID conflicts

 

Get the best as per the preference algorithm.=

If best Pij =3D=3D P1

           &= nbsp;    then use SIDij for P1

           &= nbsp;    else return no SID           &= nbsp;           &nbs= p; 

 

this to me specifies a= n implementation – which isn’t necessary.

 

However, there is one = important point which has not been specified in the draft which reading you= r post has brought to my attention – that is the order in which check= s are made.

The draft states:=

 

“Prefix conflict= s are specific to mapping entries sharing  the same topology and algor= ithm.”

“SID conflicts a= re independent of address-family,  independent of prefix len, independ= ent of topology, and independent  of algorithm.”

 

If we consider an exam= ple where a network supports two VPNs, the significance of ordering in the = evaluation of conflicts will be highlighted:

 

VPN1:

(192.0.2.1/32, 100, 1,= 1, 0)

(192.0.2.1/32, 200, 1,= 1, 0)

 

 

VPN2:

 

(192.0.2.100/32, 200, = 1, 2, 0)

 

If we evaluate prefix = conflicts first, then the following entries are “active”:<= /o:p>

(192.0.2.1/32, 100, 1,= 1, 0) !VPN1

(192.0.2.100/32, 200, = 1, 2, 0) !VPN2

 

If we evaluate SID con= flicts first, then the following entries are “active”:

(192.0.2.1/32, 100, 1,= 1, 0) !VPN1

 

The latter choice is s= uboptimal because it prevents use of the VPN2 entry unnecessarily.

 

This point needs to be= made explicit in the draft.

 

    Les=

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution - Policy

 

Hi authors, all

 

As an individual contributor, please find below some= feedback on the policy.

 

I'm wondering if we could address the conflict on a = per FEC/Prefix basis rather than on a per IGP advertisement basis.

If so, this may avoid the discussion between the Qua= rantine vs ignore policy.

 

The problem that we need to solve, is to find the SI= D for a prefix (P1).

The algo could be:

- Find all SIDi advertised for the prefix P1 &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       // identification of Prefix confli= cts

        &nbs= p;       - For each SIDi find all the prefix = Pij associated with SIDi        &nb= sp;     // identification of SID conflicts

 

// as a result, we get a list of SIDi – Pij fo= r P1

 

Get the best as per the preference algorithm.

If best Pij =3D=3D P1

        &nbs= p;       then use SIDij for P1

        &nbs= p;       else return no SID   =             &nb= sp;          / no SID availabl= e for this prefix P1

 

        &nbs= p;      

   Note that it would probably be better f= or the preference algo to put the SID tie-brake before the prefix tie-break= as with the prefix tie-break, we suffer from the conflict twice (Prefix - = SID mapping, then SID- prefix mapping) which increase the diversity and hence the chance of not finding a valid entry.&= nbsp;  But for the below examples, I used the preference algo from dra= ft-ietf-*-00

        &nbs= p;      

 

Below are examples, running this policy on typical c= onfiguration error cases.   

Examples

3.4.4.  Network operation

 

   Consider the following simple network e= xample:

 

   1.  100 nodes: R1 to R100;

 

   2.  IP Loopbacks are from 192.0.2.= 1 to 192.0.2.100:

 

   3.  SID are from 1 to 100;

 

   4.  R1 to R50 are SR capable and a= dvertised their own SID using

       Prefix-SID sub-= TLV;

 

   5.  R51 to R100 are SR non-capable= , running LDP and their SID are

       advertised by t= wo redundant Mapping Server MS1 and MS2;

 

   6.  As the number of nodes which a= re SR capable are expected to

       increase and as= in real deployment their Loopback addresses would

       no the contiguo= us, the Mapping servers advertisement covers all

       Loopbacks: (192= .0.2.1/32, 1, 100);

 

   Subsequent sections evaluate the conseq= uences of a single

   configuration error, for all conflict r= esolution options.

 

3.4.4.1.  Example 1: SID configured on 1 node c= onflict with SID

        &nbs= p; configured on another node

 

   Following a typo during configuration, = R2 is configured with a SID of

   12.  That SID conflicts with the P= refix-SID advertised by R12 and the Mapping Server Advertisement for R12.

   Note: both MS advertisement are the sam= e, so we only consider one in the below analysis.

  

   All prefix but R2 and R12, a singl= e SID is advertised and hence selected.

  

   For R2, the algo evaluates a confl= ict between the following advertisments:

   R2 - SID2 - R2 (MS, MS)

   R2 - SID12 - R12 (prefix SID, MS) =

   R2 - SID12 - R2  (prefix SID,= prefix SID)

  

   

   Best one is R2 - SID12 - R2 (small= er range (prefix SID),smaller range (prefix SID))

   =3D=3D> SID12 is selected for R2.

  

   For R12, the algo evaluates a conf= lict between the following advertisments:

   R12 - SID12 - R12 (prefix SID, prefix S= ID)

   R12 - SID12 - R2  (prefix SID, pre= fix SID)

   R12 - SID12 - R12 (prefix SID, MS)=

   R12 - SID12 - R2  (MS, prefix SID)=

   R12 - SID12 - R12 (MS, MS)

  

   Best one is R12 - SID12 - R2 (smal= ler range (prefix SID),smaller range (prefix SID), smaller starting adresse= (R2))

   R12 <> R2 =3D=3D> R12 has= no SID.

  

   3.4.4.2.  Example 2: SID conf= igured on 1 node conflict with SID

        &nbs= p; configured on the Mapping Server

 

   Following a typo during configuration, = R2 is configured with a SID of

   52.  That SID conflicts with the M= apping Server advertisements of MS1

   and MS2 for the loopback of R52.

   Note: both MS advertisement are the sam= e, so we only consider one in the below analysis.

  

   All prefix but R2 and R52, a singl= e SID is advertised and hence selected.

  

   For R2, the algo evaluates a confl= ict between the following advertisments:

   R2 - SID52 - R2  (prefix SID, pref= ix SID)

   R2 - SID52 - R52 (prefix SID, MS)<= /o:p>

   R2 - SID2  - R2  (MS, MS)

  

   Best one is R2 - SID52 - R2 (small= er range (prefix SID),smaller range (prefix SID))

   =3D=3D> SID52 is selected for R2.

  

   For R52, the algo evaluates a conf= lict between the following advertisments:

   R52 - SID52 - R52 (MS, MS)

   R52 - SID52 - R2  (MS, prefix SID)=

  

   Best one is R52 - SID52 - R2 (smal= ler range (prefix SID))

   R52 <> R2 =3D=3D> R52 has no S= ID.

  

   

3.4.4.3.  Example 3: wrong configuration of a M= S

 

   Following a typo during configuration, = MS1 is configured

   (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0= instead of 192.0.2.1).  That

   advertisement conflicts with the Mappin= g Server advertisements of MS2

   and the Prefix-SID advertised by R1...R= 50.

  

   We have a conflict for all routers= except R100.

  

   For LDP only routers R51 to R99 we= have a conflict between both MS advertisement.

   For R52, the algo evaluates a conflict = between the following advertisments:

   R52 - SID52 - R52 (MS2, MS2)=

   R52 - SID52 - R51 (MS2, MS1)=

   R52 - SID53 - R52 (MS1, MS1)=

   R52 - SID53 - R53 (MS1, MS2)=

 

   Best one is R52 - SID52 - R51 (smaller = starting address)

   R52 <> R51 =3D=3D> R52 has no = SID.

  

   For SR routers, R1 to 50, we have = a conflict between both MS advertisement and Prefix SID advertisements.

   For R2, the algo evaluates a conflict b= etween the following advertisments:

   R2 - SID 2 - R2 (Prefix SID, Prefix SID= )

   R2 - SID 2 - R2 (Prefix SID, MS2)<= /o:p>

   R2 - SID 2 - R1 (Prefix SID, MS1)<= /o:p>

   R2 - SID 2 - R2 (MS2, MS2)

   R2 - SID 2 - R2 (MS2, Prefix SID)<= /o:p>

   R2 - SID 2 - R1 (MS2, MS1)

   R2 - SID 3 - R2  (MS1, MS1)

   R2 - SID 3 - R3  (MS1, MS2)

   R2 - SID 3 - R3  (MS1, Prefix SID)=

  

   Best one is R2 - SID 2 - R2 (Prefi= x SID, Prefix SID)

   R2 =3D=3D R2 hence R2 use SID2.

 

Regards,

Bruno

 

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

Thank you.
--_000_4bf6ef2278fd4e809203e988d8fba808XCHALN001ciscocom_-- From nobody Sat May 14 20:08:14 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E64C12B040 for ; Sat, 14 May 2016 20:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6hOM77GVZj3 for ; Sat, 14 May 2016 20:08:10 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::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 ADE9E12B011 for ; Sat, 14 May 2016 20:08:09 -0700 (PDT) Received: by mail-lb0-x236.google.com with SMTP id jj5so39411247lbc.0 for ; Sat, 14 May 2016 20:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=k5u7eqfrgxaOBew+KWnInnXi8oyzdjl0Eyuk0QlKnXo=; b=PJZEPK7T+zm7g7Fozkcipx5chaMhn52pxtC2Kh0rxYJXueTSwdtS+vd11IRCFWM42E FTi6G3LfkCFhA7tEf+E8EYlbxasy3ETPtQAwYVLbk9do1bVQpj7afOzFWglxw2zC0Ypj e9pg4PgmyVk0amQAXBQ5NQmRbw11Ft34Bmj7GhZkHpVTIVT80ICscWZcgnjtvpdJ4wIa +zizOjFjI4kSp/3Mw7D7r5OgC+Oyn1u9kowf20jBJebCj3IP2JJPZCf30Kw9QCk8zDNj +p0cRSvzN6RUz153shT2s+ddIv1PF20KqcW4U3Vg7gZkoiWCI3M0ZPWkOlp2YrE9IRaO mmZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=k5u7eqfrgxaOBew+KWnInnXi8oyzdjl0Eyuk0QlKnXo=; b=SI4xuUPeXIfJ4dOMg/9k/yb69lKzC9U/6p67C2J+VKBGK3bjExjJ6UZWvba89ccrsT +/gTDpe/P9guNulQIMBNI6XirI2HKDfssLi1OLRcWITeTf5OzOztCjrE724TwxsiEbWE 9fzuk9Bpttt4hZpAeYAnW42dNckhz9y3VGcLvpHhRXLZpvuTFr1TbSo2lNiCUr7nFfnL Vorinz+Jepsa0Po+DDxCeu9V5alqhjF0oe7l8IzkBNIqOQ0P4xDhiBNG35V5AYVXhyGN TwL+Zg4MUO/5PNMajbvDmf55Oeq1+pVZKkdBS/dnVLYZx3cULLfcsRq0hBsIeSmdWt81 3D6Q== X-Gm-Message-State: AOPr4FVQYUH5lipxsl7Op3SOhClbhXPZnVM+FZqy/88m26si5CmdSjIHVyqF89vnIY+fBB4SeELVNJokLuF6Gg== MIME-Version: 1.0 X-Received: by 10.112.150.165 with SMTP id uj5mr9301170lbb.95.1463281687749; Sat, 14 May 2016 20:08:07 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.20.21 with HTTP; Sat, 14 May 2016 20:08:07 -0700 (PDT) Received: by 10.25.20.21 with HTTP; Sat, 14 May 2016 20:08:07 -0700 (PDT) In-Reply-To: References: <24715_1463066559_57349FBF_24715_2873_1_53C29892C857584299CBF5D05346208A0F8A48DE@OPEXCLILM21.corporate.adroot.infra.ftgroup> <4bf6ef2278fd4e809203e988d8fba808@XCH-ALN-001.cisco.com> Date: Sun, 15 May 2016 05:08:07 +0200 X-Google-Sender-Auth: tCo0jMIrxWE3COPe7qGQc5aFR14 Message-ID: From: Robert Raszuk To: "Les Ginsberg (ginsberg)" Content-Type: multipart/alternative; boundary=047d7b3a8396346c000532d8d155 Archived-At: Cc: bruno.decraene@orange.com, spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 03:08:13 -0000 --047d7b3a8396346c000532d8d155 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Les Please notice that in general we have no notion of term "VPN" in protocol nor implementation. (Let's put aside vpn_id for radius authentication). What determines a VPN is intersection of import and export RTs for specific L2/3VPN case. So if you want to start relaxing the rules they must map to some protocol values or at least be scoped to given RIB ... which for L2/3VPNs again may be tricky ... example hub and spoke topologies where even same VPN does not share one RIB ;). Then there is pool of other VPNs like IPSec based or LISP or xyz ... Perhaps easiest for you at this point would be to actually narrow your draft to domain's underlay transport layer and move on. My original comment was more asking to just avoid in the text referencing to "node" or a router as one entity from perspective of SR conflicts. Best, Robert. On May 14, 2016 15:40, "Les Ginsberg (ginsberg)" wrote= : Bruno =E2=80=93 I am having difficulty parsing the examples you provide below as they seem to incorporate advertisement source into the description whereas the draft deliberately omits source. So it does not matter if R2 sends an advertisement or R12 sends advertisement or both of them do (which could happen when an advertisement is leaked) =E2=80=93 what matters is what uniq= ue entries are in the database independent of source. It would be good if you could present your examples using the format defined in the draft i.e.: * Pi - Initial prefix* * Pe - End prefix* * L - Prefix length* * Lx - Maximum prefix length (32 for IPv4, 128 for IPv6)* * Si - Initial SID value* * Se - End SID value* * R - Range value* * T - Topology* * A - Algorithm* * A Mapping Entry is then the tuple: (Pi/L, Si, R, T, A)* * Pe =3D (Pi + ((R-1) << (Lx-L))* * Se =3D Si + (R-1)* *Example: (192.0.2.120/32 , 200, 1, 0, 0)* As regards your proposal *- Find all SIDi advertised for the prefix P1 // identification of Prefix conflicts* * - For each SIDi find all the prefix Pij associated with SIDi // identification of SID conflicts* *Get the best as per the preference algorithm.* *If best Pij =3D=3D P1* * then use SIDij for P1* * else return no SID* this to me specifies an implementation =E2=80=93 which isn=E2=80=99t necess= ary. However, there is one important point which has not been specified in the draft which reading your post has brought to my attention =E2=80=93 that is= the order in which checks are made. The draft states: =E2=80=9CPrefix conflicts are specific to mapping entries sharing the same topology and algorithm.=E2=80=9D =E2=80=9CSID conflicts are independent of address-family, independent of p= refix len, independent of topology, and independent of algorithm.=E2=80=9D If we consider an example where a network supports two VPNs, the significance of ordering in the evaluation of conflicts will be highlighted= : VPN1: (192.0.2.1/32, 100, 1, 1, 0) (192.0.2.1/32, 200, 1, 1, 0) VPN2: (192.0.2.100/32, 200, 1, 2, 0) If we evaluate prefix conflicts first, then the following entries are =E2=80=9Cactive=E2=80=9D: (192.0.2.1/32, 100, 1, 1, 0) !VPN1 (192.0.2.100/32, 200, 1, 2, 0) !VPN2 If we evaluate SID conflicts first, then the following entries are =E2=80= =9Cactive=E2=80=9D: (192.0.2.1/32, 100, 1, 1, 0) !VPN1 The latter choice is suboptimal because it prevents use of the VPN2 entry unnecessarily. This point needs to be made explicit in the draft. Les *From:* spring [mailto:spring-bounces@ietf.org] *On Behalf Of * bruno.decraene@orange.com *Sent:* Thursday, May 12, 2016 8:23 AM *To:* spring@ietf.org *Subject:* [spring] draft-ietf-spring-conflict-resolution - Policy Hi authors, all As an individual contributor, please find below some feedback on the policy= . I'm wondering if we could address the conflict on a per FEC/Prefix basis rather than on a per IGP advertisement basis. If so, this may avoid the discussion between the Quarantine vs ignore policy. The problem that we need to solve, is to find the SID for a prefix (P1). The algo could be: - Find all SIDi advertised for the prefix P1 // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SIDi // identification of SID conflicts // as a result, we get a list of SIDi =E2=80=93 Pij for P1 Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID / no SID available for this prefix P1 Note that it would probably be better for the preference algo to put the SID tie-brake before the prefix tie-break as with the prefix tie-break, we suffer from the conflict twice (Prefix - SID mapping, then SID- prefix mapping) which increase the diversity and hence the chance of not finding a valid entry. But for the below examples, I used the preference algo from draft-ietf-*-00 Below are examples, running this policy on typical configuration error cases. Examples 3.4.4. Network operation Consider the following simple network example: 1. 100 nodes: R1 to R100; 2. IP Loopbacks are from 192.0.2.1 to 192.0.2.100: 3. SID are from 1 to 100; 4. R1 to R50 are SR capable and advertised their own SID using Prefix-SID sub-TLV; 5. R51 to R100 are SR non-capable, running LDP and their SID are advertised by two redundant Mapping Server MS1 and MS2; 6. As the number of nodes which are SR capable are expected to increase and as in real deployment their Loopback addresses would no the contiguous, the Mapping servers advertisement covers all Loopbacks: (192.0.2.1/32, 1, 100); Subsequent sections evaluate the consequences of a single configuration error, for all conflict resolution options. 3.4.4.1. Example 1: SID configured on 1 node conflict with SID configured on another node Following a typo during configuration, R2 is configured with a SID of 12. That SID conflicts with the Prefix-SID advertised by R12 and the Mapping Server Advertisement for R12. Note: both MS advertisement are the same, so we only consider one in the below analysis. All prefix but R2 and R12, a single SID is advertised and hence selected= . For R2, the algo evaluates a conflict between the following advertisments: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (prefix SID)) =3D=3D> SID12 is selected for R2. For R12, the algo evaluates a conflict between the following advertisments: R12 - SID12 - R12 (prefix SID, prefix SID) R12 - SID12 - R2 (prefix SID, prefix SID) R12 - SID12 - R12 (prefix SID, MS) R12 - SID12 - R2 (MS, prefix SID) R12 - SID12 - R12 (MS, MS) Best one is R12 - SID12 - R2 (smaller range (prefix SID),smaller range (prefix SID), smaller starting adresse (R2)) R12 <> R2 =3D=3D> R12 has no SID. 3.4.4.2. Example 2: SID configured on 1 node conflict with SID configured on the Mapping Server Following a typo during configuration, R2 is configured with a SID of 52. That SID conflicts with the Mapping Server advertisements of MS1 and MS2 for the loopback of R52. Note: both MS advertisement are the same, so we only consider one in the below analysis. All prefix but R2 and R52, a single SID is advertised and hence selected= . For R2, the algo evaluates a conflict between the following advertisments: R2 - SID52 - R2 (prefix SID, prefix SID) R2 - SID52 - R52 (prefix SID, MS) R2 - SID2 - R2 (MS, MS) Best one is R2 - SID52 - R2 (smaller range (prefix SID),smaller range (prefix SID)) =3D=3D> SID52 is selected for R2. For R52, the algo evaluates a conflict between the following advertisments: R52 - SID52 - R52 (MS, MS) R52 - SID52 - R2 (MS, prefix SID) Best one is R52 - SID52 - R2 (smaller range (prefix SID)) R52 <> R2 =3D=3D> R52 has no SID. 3.4.4.3. Example 3: wrong configuration of a MS Following a typo during configuration, MS1 is configured (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0 instead of 192.0.2.1). That advertisement conflicts with the Mapping Server advertisements of MS2 and the Prefix-SID advertised by R1...R50. We have a conflict for all routers except R100. For LDP only routers R51 to R99 we have a conflict between both MS advertisement. For R52, the algo evaluates a conflict between the following advertisments: R52 - SID52 - R52 (MS2, MS2) R52 - SID52 - R51 (MS2, MS1) R52 - SID53 - R52 (MS1, MS1) R52 - SID53 - R53 (MS1, MS2) Best one is R52 - SID52 - R51 (smaller starting address) R52 <> R51 =3D=3D> R52 has no SID. For SR routers, R1 to 50, we have a conflict between both MS advertisement and Prefix SID advertisements. For R2, the algo evaluates a conflict between the following advertisments: R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 - SID 2 - R2 (Prefix SID, MS2) R2 - SID 2 - R1 (Prefix SID, MS1) R2 - SID 2 - R2 (MS2, MS2) R2 - SID 2 - R2 (MS2, Prefix SID) R2 - SID 2 - R1 (MS2, MS1) R2 - SID 3 - R2 (MS1, MS1) R2 - SID 3 - R3 (MS1, MS2) R2 - SID 3 - R3 (MS1, Prefix SID) Best one is R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 =3D=3D R2 hence R2 use SID2. Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --047d7b3a8396346c000532d8d155 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Les

Please notice that in general we have no notion of term &quo= t;VPN" in protocol nor implementation. (Let's put aside vpn_id for= radius authentication). What determines a VPN is intersection of import an= d export RTs for specific L2/3VPN case.

So if you want to start relaxing the rules they must map to = some protocol values or at least be scoped to given RIB ... which for L2/3V= PNs again may be tricky ... example hub and spoke topologies where even sam= e VPN does not share one RIB ;).

Then there is pool of other VPNs like IPSec based or LISP or= xyz ...

Perhaps easiest for you at this point would be to actually n= arrow your draft to domain's underlay transport layer and move on.

My original comment was more asking to just avoid in the tex= t referencing to "node" or a router as one entity from perspectiv= e of SR conflicts.

Best,
Robert.

 --047d7b3a8396346c000532d8d155-- From nobody Sun May 15 03:04:49 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CEFC12D152; Sun, 15 May 2016 03:04:45 -0700 (PDT) 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 5rKgdxtz4QLy; Sun, 15 May 2016 03:04:44 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (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 5332B12D136; Sun, 15 May 2016 03:04:44 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u4FA1vuj012922; Sun, 15 May 2016 03:04:39 -0700 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0b-0016f401.pphosted.com with ESMTP id 22x3hj1yk8-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 15 May 2016 03:04:39 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 15 May 2016 13:04:36 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Sun, 15 May 2016 13:04:36 +0300 From: Tal Mizrahi To: "draft-ietf-6man-segment-routing-header@tools.ietf.org" Thread-Topic: L4 Checksum and draft-ietf-6man-segment-routing-header Thread-Index: AdGuiiq1HeAHjjuQREGOx9vVjNXiwQ== Date: Sun, 15 May 2016 10:04:35 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: multipart/alternative; boundary="_000_eaf5cad817624c7a8758758aa058399bILEXCH02marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-15_04:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1605150137 Archived-At: Cc: "spring@ietf.org" , "ipv6@ietf.org" Subject: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 10:04:45 -0000 --_000_eaf5cad817624c7a8758758aa058399bILEXCH02marvellcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, [Apologies if this issue has been discussed before.] According to draft-ietf-6man-segment-routing-header, an 'SR Segment Endpoin= t Node' updates the Destination IP address. Therefore, it must also update the Layer 4 Checksum, right? I wonder if there is an upper bound on the size of the SRH. Otherwise, the = L4 Checksum may be located in a pretty deep location. Speaking from a chip vendor's perspective this may be a problem. Thanks, Tal Mizrahi. --_000_eaf5cad817624c7a8758758aa058399bILEXCH02marvellcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

[Apologies if this issue has been discussed before.]=

 

According to draft-ietf-6man-segment-routing-header,= an ‘SR Segment Endpoint Node’ updates the Destination IP addre= ss.

Therefore, it must also update the Layer 4 Checksum,= right?

 

I wonder if there is an upper bound on the size of t= he SRH. Otherwise, the L4 Checksum may be located in a pretty deep location= .

Speaking from a chip vendor’s perspective this= may be a problem.

 

Thanks,

Tal Mizrahi.

 

 

 

--_000_eaf5cad817624c7a8758758aa058399bILEXCH02marvellcom_-- From nobody Sun May 15 11:06:52 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 231BA12D511; Sun, 15 May 2016 11:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.427 X-Spam-Level: X-Spam-Status: No, score=-3.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXLfOZidThDp; Sun, 15 May 2016 11:06:49 -0700 (PDT) Received: from cowbell.employees.org (cowbell.employees.org [IPv6:2001:1868:a000:17::142]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26B5012D129; Sun, 15 May 2016 11:06:48 -0700 (PDT) Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 455359CC7D; Sun, 15 May 2016 11:06:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; s=selector1; bh=EH/2uKbiZNT6T47Gz+Ug3EmXNlo=; b= OH/2lW0Ehmx9uFYF7OheObAb2QkAZFZJXKP9sNbWPEWZ9CD9vHK83KcCAhu6l/e5 V71Uld02Kh2f7YisUbYGMFeqhLNJi3ijdNxvuMqXsut1rSq0w32Myn4kZiHlOn/v 98hMaNmfjnkHnRN7W9nIptdhvvlrJKmYDXBqRKrPtYE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=employees.org; h=subject :mime-version:content-type:from:in-reply-to:date:cc:message-id :references:to; q=dns; s=selector1; b=kuAA9yZhhGSM81Ca8wdWBKSfZ9 SW6ydx9Vh8Mx9YxWsx/3SKWOnu8JhnqX6rucmakVblHklGWd+ZSwm43yAJhfdc4C baAyG/i0eAR3+U7DaVrArjNNDB4a90oCztOkZs44D2VIzc0VagjB9gSfCFZyTl/n rMPtyHASkm7mOExfY= Received: from h.hanazo.no (77.16.5.38.tmi.telenormobil.no [77.16.5.38]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id E3CBA9CC4E; Sun, 15 May 2016 11:06:46 -0700 (PDT) Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 23D84167E7B6; Sun, 15 May 2016 20:06:38 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C20840B7-3E4A-4D72-98CA-E1E30531A0D6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: otroan@employees.org In-Reply-To: Date: Sun, 15 May 2016 20:06:35 +0200 Message-Id: References: To: Tal Mizrahi X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "spring@ietf.org" , 6man WG , "draft-ietf-6man-segment-routing-header@tools.ietf.org" Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 May 2016 18:06:51 -0000 --Apple-Mail=_C20840B7-3E4A-4D72-98CA-E1E30531A0D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Tal, > [Apologies if this issue has been discussed before.] >=20 > According to draft-ietf-6man-segment-routing-header, an =E2=80=98SR = Segment Endpoint Node=E2=80=99 updates the Destination IP address. > Therefore, it must also update the Layer 4 Checksum, right? >=20 > I wonder if there is an upper bound on the size of the SRH. Otherwise, = the L4 Checksum may be located in a pretty deep location. > Speaking from a chip vendor=E2=80=99s perspective this may be a = problem. =46rom RFC2460, RH0: o If the IPv6 packet contains a Routing header, the Destination Address used in the pseudo-header is that of the final destination. At the originating node, that address will be in the last element of the Routing header; at the recipient(s), that address will be in the Destination Address field of the IPv6 header. I would expect SR would work the same. Cheers, Ole --Apple-Mail=_C20840B7-3E4A-4D72-98CA-E1E30531A0D6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJXOLqtAAoJED4aXnjSQuKWqN0H/3FPlB6LsDofJYZsVDXgTDtd hjtet6iTrPxej9Wb3BA7/VKhpkzIlvVmeC4qvarPH6p48J8966ycsAl1GOcBfd4j g4/tCz7xGx475rJ4FcwVVdAiRDfRO7RJr9QnQcXVgBsFFT4hDxtBFJI7LoT0x4mb ptdi6HjjQrthNq58t/I2mEwrb7VnWZKul4X8hqYpNEAiiYPPuNkC4GB2AyODmTw/ Nz7dVc3xFL96n+j91oPbgbxGrtsqDuF+80HMKEhvoo9+oNgEzGA3KqacmuYdeWgK KUVB3ujRYrsdEe0hBiaobGDHBiE3Pl6/DAzXOd9cE38wOE4ILf0i21UQnI/EGw4= =8GVB -----END PGP SIGNATURE----- --Apple-Mail=_C20840B7-3E4A-4D72-98CA-E1E30531A0D6-- From nobody Sun May 15 17:40:41 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B101412D57A for ; Sun, 15 May 2016 17:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NnNe4rJsc3H for ; Sun, 15 May 2016 17:40:35 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A366F12D568 for ; Sun, 15 May 2016 17:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=48359; q=dns/txt; s=iport; t=1463359235; x=1464568835; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=MjV8C9c3Pk61JkGrNkj95gpOY6OaArjnelTEejCrGZM=; b=V3qjTdh1RmaWJJVvoxPxhVVzkPCqaguMSBYxvSnWlnzTzUMtg3X2Xx+Q NMpZEp6IM7fYx7eZAKrnR2JQn5vrvtWcATCXqjoUp2jThmrtLsBxu2Rcq k2opQDlc7YKv76JSFgj0Ckp7fm4EYAK6f2bm+cWTgtumYfFPromyyHanX A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DhAgAgFjlX/5NdJa1dgmxLVX4GuV4BD?= =?us-ascii?q?YF2hhECgRk4FAEBAQEBAQFlJ4RCAQEBBBoTXAIBCBEEAQEhAQYHMhQJCAEBBAE?= =?us-ascii?q?SCIgnvRoBAQEBAQEBAQEBAQEBAQEBAQEBAQEchiWDSoEDhBEKBwEGQgqFIwWFc?= =?us-ascii?q?I1AhHcBiHWCbYI0gXCET4hhj0ABHgEBQoIGBRaBS26GSAkXH38BAQE?= X-IronPort-AV: E=Sophos;i="5.24,625,1454976000"; d="scan'208,217";a="107460729" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 May 2016 00:40:33 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u4G0eXj1001249 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 16 May 2016 00:40:33 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 15 May 2016 19:40:32 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1104.009; Sun, 15 May 2016 19:40:32 -0500 From: "Les Ginsberg (ginsberg)" To: "bruno.decraene@orange.com" , "spring@ietf.org" Thread-Topic: draft-ietf-spring-conflict-resolution - Policy Thread-Index: AdGsYbndUWczH5clSpukONRF0Kk37ABrjsLQAD42BeA= Date: Mon, 16 May 2016 00:40:32 +0000 Message-ID: References: <24715_1463066559_57349FBF_24715_2873_1_53C29892C857584299CBF5D05346208A0F8A48DE@OPEXCLILM21.corporate.adroot.infra.ftgroup> <4bf6ef2278fd4e809203e988d8fba808@XCH-ALN-001.cisco.com> In-Reply-To: <4bf6ef2278fd4e809203e988d8fba808@XCH-ALN-001.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.107.134] Content-Type: multipart/alternative; boundary="_000_a3a762ae0b7343d0b23680030dd3c902XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 00:40:40 -0000 --_000_a3a762ae0b7343d0b23680030dd3c902XCHALN001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Bruno - After rereading your post, I think I missed part of what you were trying to= say. Topology was introduced because it is expected (indeed even REQUIRED) that = the same prefix would have a different SID in different topologies. This is= why for the purposes of determining "prefix conflict" (different SIDs for = the same prefix) only entries for the same topology (and algorithm) are com= pared. However, for the purposes of determining "SID conflicts" (different= entries in the database using the same SID) we MUST compare entries in all= topologies since the label database on a router is a shared resource. This= leads to the following case: VPN1: (192.0.2.1/32, 100, 1, 1, 0) VPN2: (192.0.2.1/32, 100, 1, 2, 0) Under the current preference rule defined in the draft these two entries ar= e considered "identical" - but in fact they are not since they are differen= t topologies (i.e. different FECs). However, since (as I think Robert was p= ointing out in his recent email) topology ids/VPN IDs are not global in sco= pe they cannot be used as a tie breaker (nor does the draft suggest that sh= ould be). This leads to the following amendment to the preference rule (inc= luding some of your suggested changes): 1. Smaller range wins 2. IPv6 entry wins over IPv4 entry 3. Longer prefix length wins 4. Smaller algorithm wins 5. Smaller starting address (considered as an unsigned integer value) wins 6. Smaller starting SID wins 7. If topology IDs are NOT identical both entries MUST be ignored The additional rule (#7) is applied only when doing SID conflicts as prefix= conflicts are limited to the entries in a single topology. And since we c= annot use the topology ID as a tie-breaker because the identifier has only = local scope both entries MUST be ignored. As to your statement below that: " Note that it would probably be better for the preference algo to put the = SID tie-brake before the prefix tie-break as with the prefix tie-break, we = suffer from the conflict twice (Prefix - SID mapping, then SID- prefix mapp= ing) which increase the diversity and hence the chance of not finding a val= id entry." I disagree. Prefix conflicts MUST be determined first - otherwise we risk i= gnoring an entry in another topology because it has a SID conflict with an = entry in another topology which will be ignored based on prefix conflict - = as the example I presented below demonstrates. Are we closer to agreement now? Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (gi= nsberg) Sent: Saturday, May 14, 2016 3:41 PM To: bruno.decraene@orange.com; spring@ietf.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy Bruno - I am having difficulty parsing the examples you provide below as they seem = to incorporate advertisement source into the description whereas the draft = deliberately omits source. So it does not matter if R2 sends an advertiseme= nt or R12 sends advertisement or both of them do (which could happen when a= n advertisement is leaked) - what matters is what unique entries are in the= database independent of source. It would be good if you could present your examples using the format define= d in the draft i.e.: Pi - Initial prefix Pe - End prefix L - Prefix length Lx - Maximum prefix length (32 for IPv4, 128 for IPv6) Si - Initial SID value Se - End SID value R - Range value T - Topology A - Algorithm A Mapping Entry is then the tuple: (Pi/L, Si, R, T, A) Pe =3D (Pi + ((R-1) << (Lx-L)) Se =3D Si + (R-1) Example: (192.0.2.120/32, 200, 1, 0, 0) As regards your proposal - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID this to me specifies an implementation - which isn't necessary. However, there is one important point which has not been specified in the d= raft which reading your post has brought to my attention - that is the orde= r in which checks are made. The draft states: "Prefix conflicts are specific to mapping entries sharing the same topolog= y and algorithm." "SID conflicts are independent of address-family, independent of prefix le= n, independent of topology, and independent of algorithm." If we consider an example where a network supports two VPNs, the significan= ce of ordering in the evaluation of conflicts will be highlighted: VPN1: (192.0.2.1/32, 100, 1, 1, 0) (192.0.2.1/32, 200, 1, 1, 0) VPN2: (192.0.2.100/32, 200, 1, 2, 0) If we evaluate prefix conflicts first, then the following entries are "acti= ve": (192.0.2.1/32, 100, 1, 1, 0) !VPN1 (192.0.2.100/32, 200, 1, 2, 0) !VPN2 If we evaluate SID conflicts first, then the following entries are "active"= : (192.0.2.1/32, 100, 1, 1, 0) !VPN1 The latter choice is suboptimal because it prevents use of the VPN2 entry u= nnecessarily. This point needs to be made explicit in the draft. Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution - Policy Hi authors, all As an individual contributor, please find below some feedback on the policy= . I'm wondering if we could address the conflict on a per FEC/Prefix basis ra= ther than on a per IGP advertisement basis. If so, this may avoid the discussion between the Quarantine vs ignore polic= y. The problem that we need to solve, is to find the SID for a prefix (P1). The algo could be: - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts // as a result, we get a list of SIDi - Pij for P1 Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID / no SID availa= ble for this prefix P1 Note that it would probably be better for the preference algo to put the= SID tie-brake before the prefix tie-break as with the prefix tie-break, we= suffer from the conflict twice (Prefix - SID mapping, then SID- prefix map= ping) which increase the diversity and hence the chance of not finding a va= lid entry. But for the below examples, I used the preference algo from dr= aft-ietf-*-00 Below are examples, running this policy on typical configuration error case= s. Examples 3.4.4. Network operation Consider the following simple network example: 1. 100 nodes: R1 to R100; 2. IP Loopbacks are from 192.0.2.1 to 192.0.2.100: 3. SID are from 1 to 100; 4. R1 to R50 are SR capable and advertised their own SID using Prefix-SID sub-TLV; 5. R51 to R100 are SR non-capable, running LDP and their SID are advertised by two redundant Mapping Server MS1 and MS2; 6. As the number of nodes which are SR capable are expected to increase and as in real deployment their Loopback addresses would no the contiguous, the Mapping servers advertisement covers all Loopbacks: (192.0.2.1/32, 1, 100); Subsequent sections evaluate the consequences of a single configuration error, for all conflict resolution options. 3.4.4.1. Example 1: SID configured on 1 node conflict with SID configured on another node Following a typo during configuration, R2 is configured with a SID of 12. That SID conflicts with the Prefix-SID advertised by R12 and the Ma= pping Server Advertisement for R12. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R12, a single SID is advertised and hence selected= . For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID12 is selected for R2. For R12, the algo evaluates a conflict between the following advertismen= ts: R12 - SID12 - R12 (prefix SID, prefix SID) R12 - SID12 - R2 (prefix SID, prefix SID) R12 - SID12 - R12 (prefix SID, MS) R12 - SID12 - R2 (MS, prefix SID) R12 - SID12 - R12 (MS, MS) Best one is R12 - SID12 - R2 (smaller range (prefix SID),smaller range (= prefix SID), smaller starting adresse (R2)) R12 <> R2 =3D=3D> R12 has no SID. 3.4.4.2. Example 2: SID configured on 1 node conflict with SID configured on the Mapping Server Following a typo during configuration, R2 is configured with a SID of 52. That SID conflicts with the Mapping Server advertisements of MS1 and MS2 for the loopback of R52. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R52, a single SID is advertised and hence selected= . For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID52 - R2 (prefix SID, prefix SID) R2 - SID52 - R52 (prefix SID, MS) R2 - SID2 - R2 (MS, MS) Best one is R2 - SID52 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID52 is selected for R2. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS, MS) R52 - SID52 - R2 (MS, prefix SID) Best one is R52 - SID52 - R2 (smaller range (prefix SID)) R52 <> R2 =3D=3D> R52 has no SID. 3.4.4.3. Example 3: wrong configuration of a MS Following a typo during configuration, MS1 is configured (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0 instead of 192.0.2.1). That advertisement conflicts with the Mapping Server advertisements of MS2 and the Prefix-SID advertised by R1...R50. We have a conflict for all routers except R100. For LDP only routers R51 to R99 we have a conflict between both MS adver= tisement. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS2, MS2) R52 - SID52 - R51 (MS2, MS1) R52 - SID53 - R52 (MS1, MS1) R52 - SID53 - R53 (MS1, MS2) Best one is R52 - SID52 - R51 (smaller starting address) R52 <> R51 =3D=3D> R52 has no SID. For SR routers, R1 to 50, we have a conflict between both MS advertiseme= nt and Prefix SID advertisements. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 - SID 2 - R2 (Prefix SID, MS2) R2 - SID 2 - R1 (Prefix SID, MS1) R2 - SID 2 - R2 (MS2, MS2) R2 - SID 2 - R2 (MS2, Prefix SID) R2 - SID 2 - R1 (MS2, MS1) R2 - SID 3 - R2 (MS1, MS1) R2 - SID 3 - R3 (MS1, MS2) R2 - SID 3 - R3 (MS1, Prefix SID) Best one is R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 =3D=3D R2 hence R2 use SID2. Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_a3a762ae0b7343d0b23680030dd3c902XCHALN001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Bruno –

 

After rereading your p= ost, I think I missed part of what you were trying to say.

 

Topology was introduce= d because it is expected (indeed even REQUIRED) that the same prefix would = have a different SID in different topologies. This is why for the purposes = of determining “prefix conflict” (different SIDs for the same prefix) only entries for the same topology (and algorith= m) are compared.  However, for the purposes of determining “SID = conflicts” (different entries in the database using the same SID) we = MUST compare entries in all topologies since the label database on a router is a shared resource. This leads to the followi= ng case:

 

VPN1:

(192.0.2.1/32, 100, 1,= 1, 0)

 

VPN2:

(192.0.2.1/32, 100, 1,= 2, 0)

 

Under the current pref= erence rule defined in the draft these two entries are considered “id= entical” – but in fact they are not since they are different to= pologies (i.e. different FECs). However, since (as I think Robert was pointing out in his recent email) topology ids/VPN IDs are not = global in scope they cannot be used as a tie breaker (nor does the draft su= ggest that should be). This leads to the following amendment to the prefere= nce rule (including some of your suggested changes):

 

1.  Smaller range= wins

2.  IPv6 entry wi= ns over IPv4 entry

3.  Longer prefix= length wins

4. Smaller algorithm w= ins

5.  Smaller start= ing address (considered as an unsigned integer

   &nbs= p;   value) wins

6.  Smaller start= ing SID wins

7. If topology IDs are NOT identical both entries MUST be ig= nored

 

The additional rule (#= 7) is applied only when doing SID conflicts as prefix conflicts are limited= to the entries  in a single topology. And since we cannot use the top= ology ID as a tie-breaker because the identifier has only local scope both entries MUST be ignored.

 

As to your statement b= elow that:

 

“ Note that it would probably be better for the preference al= go to put the SID tie-brake before the prefix tie-break as with the prefix = tie-break, we suffer from the conflict twice (Prefix - SID mapping, then SID- prefix mapping) which increase the divers= ity and hence the chance of not finding a valid entry.”

 

I disagree. Prefix con= flicts MUST be determined first – otherwise we risk ignoring an entry= in another topology because it has a SID conflict with an entry in another= topology which will be ignored based on prefix conflict – as the example I presented below demonstrates.=

 

Are we closer to agree= ment now?

 

   Les<= /o:p>

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Saturday, May 14, 2016 3:41 PM
To: bruno.decraene@orange.com; spring@ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy=

 

Bruno –

 

I am having difficulty= parsing the examples you provide below as they seem to incorporate adverti= sement source into the description whereas the draft deliberately omits sou= rce. So it does not matter if R2 sends an advertisement or R12 sends advertisement or both of them do (which coul= d happen when an advertisement is leaked) – what matters is what uniq= ue entries are in the database independent of source.

 

It would be good if yo= u could present your examples using the format defined in the draft i.e.:

 

    Pi - Initial prefix

     Pe - End prefix

     L -  Prefix length<= /i>

     Lx - Maximum prefix length (32 for IPv4, 1= 28 for IPv6)

     Si - Initial SID value

     Se - End SID value

     R -  Range value

     T - Topology

     A - Algorithm

 

     A Mapping Entry is then the tuple: (Pi/L, = Si, R, T, A)

     Pe =3D (Pi + ((R-1) << (Lx-L))

     Se =3D Si + (R-1)

 

Example:     (192.0.2.120/32, 200, 1, 0, 0)

 

As regards your propos= al

 

- Find all SIDi advertised for the prefix P1    = ;            &n= bsp;            = ;            &n= bsp;            = ;     // identification of Prefix conflicts<= /span>

           &= nbsp;    - For each SIDi find all the prefix Pij associated = with SIDi            = ;  // identification of SID conflicts

 

Get the best as per the preference algorithm.=

If best Pij =3D=3D P1

           &= nbsp;    then use SIDij for P1

           &= nbsp;    else return no SID           &= nbsp;           &nbs= p; 

 

this to me specifies a= n implementation – which isn’t necessary.

 

However, there is one = important point which has not been specified in the draft which reading you= r post has brought to my attention – that is the order in which check= s are made.

The draft states:=

 

“Prefix conflict= s are specific to mapping entries sharing  the same topology and algor= ithm.”

“SID conflicts a= re independent of address-family,  independent of prefix len, independ= ent of topology, and independent  of algorithm.”

 

If we consider an exam= ple where a network supports two VPNs, the significance of ordering in the = evaluation of conflicts will be highlighted:

 

VPN1:

(192.0.2.1/32, 100, 1,= 1, 0)

(192.0.2.1/32, 200, 1,= 1, 0)

 

 

VPN2:

 

(192.0.2.100/32, 200, = 1, 2, 0)

 

If we evaluate prefix = conflicts first, then the following entries are “active”:<= /o:p>

(192.0.2.1/32, 100, 1,= 1, 0) !VPN1

(192.0.2.100/32, 200, = 1, 2, 0) !VPN2

 

If we evaluate SID con= flicts first, then the following entries are “active”:

(192.0.2.1/32, 100, 1,= 1, 0) !VPN1

 

The latter choice is s= uboptimal because it prevents use of the VPN2 entry unnecessarily.

 

This point needs to be= made explicit in the draft.

 

    Les=

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of bruno.decr= aene@orange.com
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution - Policy

 

Hi authors, all

 

As an individual contributor, please find below some= feedback on the policy.

 

I'm wondering if we could address the conflict on a = per FEC/Prefix basis rather than on a per IGP advertisement basis.

If so, this may avoid the discussion between the Qua= rantine vs ignore policy.

 

The problem that we need to solve, is to find the SI= D for a prefix (P1).

The algo could be:

- Find all SIDi advertised for the prefix P1 &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;       // identification of Prefix confli= cts

        &nbs= p;       - For each SIDi find all the prefix = Pij associated with SIDi        &nb= sp;     // identification of SID conflicts

 

// as a result, we get a list of SIDi – Pij fo= r P1

 

Get the best as per the preference algorithm.

If best Pij =3D=3D P1

        &nbs= p;       then use SIDij for P1

        &nbs= p;       else return no SID   =             &nb= sp;          / no SID availabl= e for this prefix P1

 

        &nbs= p;      

   Note that it would probably be better f= or the preference algo to put the SID tie-brake before the prefix tie-break= as with the prefix tie-break, we suffer from the conflict twice (Prefix - = SID mapping, then SID- prefix mapping) which increase the diversity and hence the chance of not finding a valid entry.&= nbsp;  But for the below examples, I used the preference algo from dra= ft-ietf-*-00

        &nbs= p;      

 

Below are examples, running this policy on typical c= onfiguration error cases.   

Examples

3.4.4.  Network operation

 

   Consider the following simple network e= xample:

 

   1.  100 nodes: R1 to R100;

 

   2.  IP Loopbacks are from 192.0.2.= 1 to 192.0.2.100:

 

   3.  SID are from 1 to 100;

 

   4.  R1 to R50 are SR capable and a= dvertised their own SID using

       Prefix-SID sub-= TLV;

 

   5.  R51 to R100 are SR non-capable= , running LDP and their SID are

       advertised by t= wo redundant Mapping Server MS1 and MS2;

 

   6.  As the number of nodes which a= re SR capable are expected to

       increase and as= in real deployment their Loopback addresses would

       no the contiguo= us, the Mapping servers advertisement covers all

       Loopbacks: (192= .0.2.1/32, 1, 100);

 

   Subsequent sections evaluate the conseq= uences of a single

   configuration error, for all conflict r= esolution options.

 

3.4.4.1.  Example 1: SID configured on 1 node c= onflict with SID

        &nbs= p; configured on another node

 

   Following a typo during configuration, = R2 is configured with a SID of

   12.  That SID conflicts with the P= refix-SID advertised by R12 and the Mapping Server Advertisement for R12.

   Note: both MS advertisement are the sam= e, so we only consider one in the below analysis.

  

   All prefix but R2 and R12, a singl= e SID is advertised and hence selected.

  

   For R2, the algo evaluates a confl= ict between the following advertisments:

   R2 - SID2 - R2 (MS, MS)

   R2 - SID12 - R12 (prefix SID, MS) =

   R2 - SID12 - R2  (prefix SID,= prefix SID)

  

   

   Best one is R2 - SID12 - R2 (small= er range (prefix SID),smaller range (prefix SID))

   =3D=3D> SID12 is selected for R2.

  

   For R12, the algo evaluates a conf= lict between the following advertisments:

   R12 - SID12 - R12 (prefix SID, prefix S= ID)

   R12 - SID12 - R2  (prefix SID, pre= fix SID)

   R12 - SID12 - R12 (prefix SID, MS)=

   R12 - SID12 - R2  (MS, prefix SID)=

   R12 - SID12 - R12 (MS, MS)

  

   Best one is R12 - SID12 - R2 (smal= ler range (prefix SID),smaller range (prefix SID), smaller starting adresse= (R2))

   R12 <> R2 =3D=3D> R12 has= no SID.

  

   3.4.4.2.  Example 2: SID conf= igured on 1 node conflict with SID

        &nbs= p; configured on the Mapping Server

 

   Following a typo during configuration, = R2 is configured with a SID of

   52.  That SID conflicts with the M= apping Server advertisements of MS1

   and MS2 for the loopback of R52.

   Note: both MS advertisement are the sam= e, so we only consider one in the below analysis.

  

   All prefix but R2 and R52, a singl= e SID is advertised and hence selected.

  

   For R2, the algo evaluates a confl= ict between the following advertisments:

   R2 - SID52 - R2  (prefix SID, pref= ix SID)

   R2 - SID52 - R52 (prefix SID, MS)<= /o:p>

   R2 - SID2  - R2  (MS, MS)

  

   Best one is R2 - SID52 - R2 (small= er range (prefix SID),smaller range (prefix SID))

   =3D=3D> SID52 is selected for R2.

  

   For R52, the algo evaluates a conf= lict between the following advertisments:

   R52 - SID52 - R52 (MS, MS)

   R52 - SID52 - R2  (MS, prefix SID)=

  

   Best one is R52 - SID52 - R2 (smal= ler range (prefix SID))

   R52 <> R2 =3D=3D> R52 has no S= ID.

  

   

3.4.4.3.  Example 3: wrong configuration of a M= S

 

   Following a typo during configuration, = MS1 is configured

   (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0= instead of 192.0.2.1).  That

   advertisement conflicts with the Mappin= g Server advertisements of MS2

   and the Prefix-SID advertised by R1...R= 50.

  

   We have a conflict for all routers= except R100.

  

   For LDP only routers R51 to R99 we= have a conflict between both MS advertisement.

   For R52, the algo evaluates a conflict = between the following advertisments:

   R52 - SID52 - R52 (MS2, MS2)=

   R52 - SID52 - R51 (MS2, MS1)=

   R52 - SID53 - R52 (MS1, MS1)=

   R52 - SID53 - R53 (MS1, MS2)=

 

   Best one is R52 - SID52 - R51 (smaller = starting address)

   R52 <> R51 =3D=3D> R52 has no = SID.

  

   For SR routers, R1 to 50, we have = a conflict between both MS advertisement and Prefix SID advertisements.

   For R2, the algo evaluates a conflict b= etween the following advertisments:

   R2 - SID 2 - R2 (Prefix SID, Prefix SID= )

   R2 - SID 2 - R2 (Prefix SID, MS2)<= /o:p>

   R2 - SID 2 - R1 (Prefix SID, MS1)<= /o:p>

   R2 - SID 2 - R2 (MS2, MS2)

   R2 - SID 2 - R2 (MS2, Prefix SID)<= /o:p>

   R2 - SID 2 - R1 (MS2, MS1)

   R2 - SID 3 - R2  (MS1, MS1)

   R2 - SID 3 - R3  (MS1, MS2)

   R2 - SID 3 - R3  (MS1, Prefix SID)=

  

   Best one is R2 - SID 2 - R2 (Prefi= x SID, Prefix SID)

   R2 =3D=3D R2 hence R2 use SID2.

 

Regards,

Bruno

 

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

Thank you.
--_000_a3a762ae0b7343d0b23680030dd3c902XCHALN001ciscocom_-- From nobody Sun May 15 23:21:35 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 072CA12D14B; Sun, 15 May 2016 23:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vXmwFJOLW6x4; Sun, 15 May 2016 23:21:31 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C977312B017; Sun, 15 May 2016 23:21:31 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u4G6HRSF003706; Sun, 15 May 2016 23:21:30 -0700 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0a-0016f401.pphosted.com with ESMTP id 22xc8c337j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 15 May 2016 23:21:30 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 16 May 2016 09:21:25 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Mon, 16 May 2016 09:21:25 +0300 From: Tal Mizrahi To: "otroan@employees.org" , "draft-ietf-6man-segment-routing-header@tools.ietf.org" Thread-Topic: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header Thread-Index: AdGuiiq1HeAHjjuQREGOx9vVjNXiwQAMTSCAAB/eFXA= Date: Mon, 16 May 2016 06:21:25 +0000 Message-ID: <6ed6834bb1e343b287f0cc32428417ff@IL-EXCH02.marvell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-16_02:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1605160088 Archived-At: Cc: "spring@ietf.org" , 6man WG Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 06:21:33 -0000 SGkgT2xlLA0KDQpUaGFua3MgZm9yIHRoZSBwcm9tcHQgcmVzcG9uc2UuIA0KDQpJdCB3b3VsZCBi ZSBoZWxwZnVsIGlmIHRoZSBhdXRob3JzIGFkZGVkIGEgY29tbWVudCBhYm91dCB0aGUgTDQgQ2hl Y2tzdW0gdG8gdGhlIGN1cnJlbnQgZHJhZnQsIGV2ZW4gdGhvdWdoIHRoaXMgZnVuY3Rpb25hbGl0 eSB3YXMgZGVmaW5lZCBpbiBSRkMgMjQ2MC4NCg0KQmVzdCByZWdhcmRzLA0KVGFsLg0KDQo+LS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBvdHJvYW5AZW1wbG95ZWVzLm9yZyBbbWFp bHRvOm90cm9hbkBlbXBsb3llZXMub3JnXQ0KPlNlbnQ6IFN1bmRheSwgTWF5IDE1LCAyMDE2IDk6 MDcgUE0NCj5UbzogVGFsIE1penJhaGkNCj5DYzogZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91 dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmc7IHNwcmluZ0BpZXRmLm9yZzsNCj42bWFuIFdHDQo+ U3ViamVjdDogUmU6IFtzcHJpbmddIEw0IENoZWNrc3VtIGFuZCBkcmFmdC1pZXRmLTZtYW4tc2Vn bWVudC1yb3V0aW5nLQ0KPmhlYWRlcg0KPg0KPlRhbCwNCj4NCj4+IFtBcG9sb2dpZXMgaWYgdGhp cyBpc3N1ZSBoYXMgYmVlbiBkaXNjdXNzZWQgYmVmb3JlLl0NCj4+DQo+PiBBY2NvcmRpbmcgdG8g ZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXIsIGFuIOKAmFNSIFNlZ21lbnQN Cj5FbmRwb2ludCBOb2Rl4oCZIHVwZGF0ZXMgdGhlIERlc3RpbmF0aW9uIElQIGFkZHJlc3MuDQo+ PiBUaGVyZWZvcmUsIGl0IG11c3QgYWxzbyB1cGRhdGUgdGhlIExheWVyIDQgQ2hlY2tzdW0sIHJp Z2h0Pw0KPj4NCj4+IEkgd29uZGVyIGlmIHRoZXJlIGlzIGFuIHVwcGVyIGJvdW5kIG9uIHRoZSBz aXplIG9mIHRoZSBTUkguIE90aGVyd2lzZSwgdGhlIEw0DQo+Q2hlY2tzdW0gbWF5IGJlIGxvY2F0 ZWQgaW4gYSBwcmV0dHkgZGVlcCBsb2NhdGlvbi4NCj4+IFNwZWFraW5nIGZyb20gYSBjaGlwIHZl bmRvcuKAmXMgcGVyc3BlY3RpdmUgdGhpcyBtYXkgYmUgYSBwcm9ibGVtLg0KPg0KPkZyb20gUkZD MjQ2MCwgUkgwOg0KPg0KPg0KPiAgICAgIG8gIElmIHRoZSBJUHY2IHBhY2tldCBjb250YWlucyBh IFJvdXRpbmcgaGVhZGVyLCB0aGUgRGVzdGluYXRpb24NCj4gICAgICAgICBBZGRyZXNzIHVzZWQg aW4gdGhlIHBzZXVkby1oZWFkZXIgaXMgdGhhdCBvZiB0aGUgZmluYWwNCj4gICAgICAgICBkZXN0 aW5hdGlvbi4gIEF0IHRoZSBvcmlnaW5hdGluZyBub2RlLCB0aGF0IGFkZHJlc3Mgd2lsbCBiZSBp bg0KPiAgICAgICAgIHRoZSBsYXN0IGVsZW1lbnQgb2YgdGhlIFJvdXRpbmcgaGVhZGVyOyBhdCB0 aGUgcmVjaXBpZW50KHMpLA0KPiAgICAgICAgIHRoYXQgYWRkcmVzcyB3aWxsIGJlIGluIHRoZSBE ZXN0aW5hdGlvbiBBZGRyZXNzIGZpZWxkIG9mIHRoZQ0KPiAgICAgICAgIElQdjYgaGVhZGVyLg0K Pg0KPkkgd291bGQgZXhwZWN0IFNSIHdvdWxkIHdvcmsgdGhlIHNhbWUuDQo+DQo+Q2hlZXJzLA0K Pk9sZQ0KDQo= From nobody Mon May 16 01:58:57 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A816612B034; Mon, 16 May 2016 01:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1sUMEe8H1sq; Mon, 16 May 2016 01:58:55 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9411612B030; Mon, 16 May 2016 01:58:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1602; q=dns/txt; s=iport; t=1463389135; x=1464598735; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=40wcBYMThDSXPHRV7cx/KiFPbKhVoH1M6+kEwzTN6Hs=; b=Mw76t6mk0UqdobDxS3PfVMbAwwMkc09GqtA/FIhp8K+eNVdOJbhSHcDJ kHEycNo2NwsCHUfA1RPhZYYhWGbXRCHM135dQHugi+R4VshgJiP2LLwOf Gn56C+T5lvJarDcxbYMjjqBHlGZR5ObkaqR3XK0QXe2mm/X1hgjuOVWLF Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAgAoizlX/4wNJK1egzeBUwa5YAENg?= =?us-ascii?q?XaGEQIcgQE4FAEBAQEBAQFlJ4RCAQEBAwEjEUUFCwIBCBgCAiYCAgIwFRABAQQ?= =?us-ascii?q?BDQWIJwisTJBRAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIEBhSSBdoJXhD+DACuCL?= =?us-ascii?q?gEEkzCEdwGOHQqBX40whi2JEwEeAQFCg2xuhwd/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,626,1454976000"; d="scan'208";a="273907936" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 May 2016 08:58:54 +0000 Received: from XCH-RTP-006.cisco.com (xch-rtp-006.cisco.com [64.101.220.146]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id u4G8ws9l013287 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 16 May 2016 08:58:54 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-006.cisco.com (64.101.220.146) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 16 May 2016 04:58:53 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Mon, 16 May 2016 04:58:53 -0400 From: "Stefano Previdi (sprevidi)" To: =?utf-8?B?T2xlIFRyw7hhbg==?= , Tal Mizrahi Thread-Topic: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header Thread-Index: AdGuiiq1HeAHjjuQREGOx9vVjNXiwQAa+DiAAB8pfIA= Date: Mon, 16 May 2016 08:58:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.197.212] Content-Type: text/plain; charset="utf-8" Content-ID: <561024D8A5193A43A30ED01F989D02B1@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , 6man WG , "draft-ietf-6man-segment-routing-header@tools.ietf.org" Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 08:58:57 -0000 DQo+IE9uIE1heSAxNSwgMjAxNiwgYXQgODowNiBQTSwgb3Ryb2FuQGVtcGxveWVlcy5vcmcgd3Jv dGU6DQo+IA0KPiBUYWwsDQo+IA0KPj4gW0Fwb2xvZ2llcyBpZiB0aGlzIGlzc3VlIGhhcyBiZWVu IGRpc2N1c3NlZCBiZWZvcmUuXQ0KPj4gDQo+PiBBY2NvcmRpbmcgdG8gZHJhZnQtaWV0Zi02bWFu LXNlZ21lbnQtcm91dGluZy1oZWFkZXIsIGFuIOKAmFNSIFNlZ21lbnQgRW5kcG9pbnQgTm9kZeKA mSB1cGRhdGVzIHRoZSBEZXN0aW5hdGlvbiBJUCBhZGRyZXNzLg0KPj4gVGhlcmVmb3JlLCBpdCBt dXN0IGFsc28gdXBkYXRlIHRoZSBMYXllciA0IENoZWNrc3VtLCByaWdodD8NCj4+IA0KPj4gSSB3 b25kZXIgaWYgdGhlcmUgaXMgYW4gdXBwZXIgYm91bmQgb24gdGhlIHNpemUgb2YgdGhlIFNSSC4g T3RoZXJ3aXNlLCB0aGUgTDQgQ2hlY2tzdW0gbWF5IGJlIGxvY2F0ZWQgaW4gYSBwcmV0dHkgZGVl cCBsb2NhdGlvbi4NCj4+IFNwZWFraW5nIGZyb20gYSBjaGlwIHZlbmRvcuKAmXMgcGVyc3BlY3Rp dmUgdGhpcyBtYXkgYmUgYSBwcm9ibGVtLg0KPiANCj4gRnJvbSBSRkMyNDYwLCBSSDA6DQo+IA0K PiANCj4gICAgICBvICBJZiB0aGUgSVB2NiBwYWNrZXQgY29udGFpbnMgYSBSb3V0aW5nIGhlYWRl ciwgdGhlIERlc3RpbmF0aW9uDQo+ICAgICAgICAgQWRkcmVzcyB1c2VkIGluIHRoZSBwc2V1ZG8t aGVhZGVyIGlzIHRoYXQgb2YgdGhlIGZpbmFsDQo+ICAgICAgICAgZGVzdGluYXRpb24uICBBdCB0 aGUgb3JpZ2luYXRpbmcgbm9kZSwgdGhhdCBhZGRyZXNzIHdpbGwgYmUgaW4NCj4gICAgICAgICB0 aGUgbGFzdCBlbGVtZW50IG9mIHRoZSBSb3V0aW5nIGhlYWRlcjsgYXQgdGhlIHJlY2lwaWVudChz KSwNCj4gICAgICAgICB0aGF0IGFkZHJlc3Mgd2lsbCBiZSBpbiB0aGUgRGVzdGluYXRpb24gQWRk cmVzcyBmaWVsZCBvZiB0aGUNCj4gICAgICAgICBJUHY2IGhlYWRlci4NCj4gDQo+IEkgd291bGQg ZXhwZWN0IFNSIHdvdWxkIHdvcmsgdGhlIHNhbWUuDQoNCg0KZXhhY3RseS4NCg0KTW9yZW92ZXIs IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyIGFzc3VtZXMgZW5jYXBzdWxh dGlvbiBzbyBjbGVhcmx5IHRoZXJl4oCZcyBubyBMNCBpbnZvbHZlZCBoZXJlLg0KDQpzLg0KDQoN Cj4gDQo+IENoZWVycywNCj4gT2xlDQo+IA0KDQo= From nobody Mon May 16 02:01:04 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E12912B02A; Mon, 16 May 2016 02:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6KYS-MzFvC0j; Mon, 16 May 2016 02:00:51 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ADA7128E19; Mon, 16 May 2016 02:00:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2706; q=dns/txt; s=iport; t=1463389251; x=1464598851; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1BwkcvdxGdqq8UboN01zHz9wH7bE7ZMAT08xB16GAo4=; b=S5pJ4Z/lvLw65/8TcYXKrsgF8bVQ4XJPC2Ww0+TyN4NhlZ/mjgc5f3Yy ZeKC6oDpBgRLIUhm1dPtcuXRQFoUsbob7qh5f+/3m1hb2ME8jQ+KIMfYl vaYEtIEvgK4wDti0Q1culbb+HGHYPknfCpYRyUKWznT8AJif+/Q+AV2m3 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAgBLizlX/5hdJa1egzeBUwa5YAENg?= =?us-ascii?q?XaGEQIcgQE4FAEBAQEBAQFlJ4RCAQEBAwEjEUUFBwQCAQgRBAEBAQICIwMCAgI?= =?us-ascii?q?wFAEICAEBBA4FiCcIrEyQUgEBAQEBAQEBAQEBAQEBAQEBAQEBARyBAYUkgXaCV?= =?us-ascii?q?4Q/gwArgi4BBJgnAY4dgWmET4MqhTeGLYkTAR4BAUKDbG6HB38BAQE?= X-IronPort-AV: E=Sophos;i="5.24,626,1454976000"; d="scan'208";a="104699737" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 May 2016 09:00:50 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u4G90o1v014714 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 16 May 2016 09:00:50 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 16 May 2016 05:00:49 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Mon, 16 May 2016 05:00:49 -0400 From: "Stefano Previdi (sprevidi)" To: Tal Mizrahi Thread-Topic: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header Thread-Index: AdGuiiq1HeAHjjuQREGOx9vVjNXiwQAa+DiAABmp7IAABZDZgA== Date: Mon, 16 May 2016 09:00:49 +0000 Message-ID: References: <6ed6834bb1e343b287f0cc32428417ff@IL-EXCH02.marvell.com> In-Reply-To: <6ed6834bb1e343b287f0cc32428417ff@IL-EXCH02.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.197.212] Content-Type: text/plain; charset="utf-8" Content-ID: <4C17617FAE8A0D4784980607D02F72E1@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "otroan@employees.org" , 6man WG , "spring@ietf.org" , "draft-ietf-6man-segment-routing-header@tools.ietf.org" Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 09:01:00 -0000 DQo+IE9uIE1heSAxNiwgMjAxNiwgYXQgODoyMSBBTSwgVGFsIE1penJhaGkgPHRhbG1pQG1hcnZl bGwuY29tPiB3cm90ZToNCj4gDQo+IEhpIE9sZSwNCj4gDQo+IFRoYW5rcyBmb3IgdGhlIHByb21w dCByZXNwb25zZS4gDQo+IA0KPiBJdCB3b3VsZCBiZSBoZWxwZnVsIGlmIHRoZSBhdXRob3JzIGFk ZGVkIGEgY29tbWVudCBhYm91dCB0aGUgTDQgQ2hlY2tzdW0gdG8gdGhlIGN1cnJlbnQgZHJhZnQs IGV2ZW4gdGhvdWdoIHRoaXMgZnVuY3Rpb25hbGl0eSB3YXMgZGVmaW5lZCBpbiBSRkMgMjQ2MC4N Cg0KDQpwbGVhc2UgcmVhZCBjYXJlZnVsbHkgZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGlu Zy1oZWFkZXIuDQoNClRoZSBtb2RlbCBkZXNjcmliZWQgYXNzdW1lcyBlbmNhcHN1bGF0aW9uIG9m IHRoZSBvcmlnaW5hbCBwYWNrZXQgaW50byBhbiBvdXRlciBpcHY2IGhlYWRlciBmb2xsb3dlZCBi eSBhIFNSSC4gV2hlbiB0aGUgcGFja2V0IGxlYXZlcyB0aGUgU1IgdHVubmVsIHRoZXJlIGFyZSBu byB0cmFjZXMgb2Ygc2VnbWVudCByb3V0aW5nIHdoYXRzb2V2ZXIuIEw0IGNsZWFybHkgZG9lcyBu b3QgYXBwbHkgaGVyZSwgaXTigJlzIGJhc2ljIHR1bm5lbGluZy4NCg0Kcy4NCg0KDQo+IA0KPiBC ZXN0IHJlZ2FyZHMsDQo+IFRhbC4NCj4gDQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4gRnJvbTogb3Ryb2FuQGVtcGxveWVlcy5vcmcgW21haWx0bzpvdHJvYW5AZW1wbG95ZWVzLm9y Z10NCj4+IFNlbnQ6IFN1bmRheSwgTWF5IDE1LCAyMDE2IDk6MDcgUE0NCj4+IFRvOiBUYWwgTWl6 cmFoaQ0KPj4gQ2M6IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyQHRvb2xz LmlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmc7DQo+PiA2bWFuIFdHDQo+PiBTdWJqZWN0OiBSZTog W3NwcmluZ10gTDQgQ2hlY2tzdW0gYW5kIGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmct DQo+PiBoZWFkZXINCj4+IA0KPj4gVGFsLA0KPj4gDQo+Pj4gW0Fwb2xvZ2llcyBpZiB0aGlzIGlz c3VlIGhhcyBiZWVuIGRpc2N1c3NlZCBiZWZvcmUuXQ0KPj4+IA0KPj4+IEFjY29yZGluZyB0byBk cmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlciwgYW4g4oCYU1IgU2VnbWVudA0K Pj4gRW5kcG9pbnQgTm9kZeKAmSB1cGRhdGVzIHRoZSBEZXN0aW5hdGlvbiBJUCBhZGRyZXNzLg0K Pj4+IFRoZXJlZm9yZSwgaXQgbXVzdCBhbHNvIHVwZGF0ZSB0aGUgTGF5ZXIgNCBDaGVja3N1bSwg cmlnaHQ/DQo+Pj4gDQo+Pj4gSSB3b25kZXIgaWYgdGhlcmUgaXMgYW4gdXBwZXIgYm91bmQgb24g dGhlIHNpemUgb2YgdGhlIFNSSC4gT3RoZXJ3aXNlLCB0aGUgTDQNCj4+IENoZWNrc3VtIG1heSBi ZSBsb2NhdGVkIGluIGEgcHJldHR5IGRlZXAgbG9jYXRpb24uDQo+Pj4gU3BlYWtpbmcgZnJvbSBh IGNoaXAgdmVuZG9y4oCZcyBwZXJzcGVjdGl2ZSB0aGlzIG1heSBiZSBhIHByb2JsZW0uDQo+PiAN Cj4+IEZyb20gUkZDMjQ2MCwgUkgwOg0KPj4gDQo+PiANCj4+ICAgICBvICBJZiB0aGUgSVB2NiBw YWNrZXQgY29udGFpbnMgYSBSb3V0aW5nIGhlYWRlciwgdGhlIERlc3RpbmF0aW9uDQo+PiAgICAg ICAgQWRkcmVzcyB1c2VkIGluIHRoZSBwc2V1ZG8taGVhZGVyIGlzIHRoYXQgb2YgdGhlIGZpbmFs DQo+PiAgICAgICAgZGVzdGluYXRpb24uICBBdCB0aGUgb3JpZ2luYXRpbmcgbm9kZSwgdGhhdCBh ZGRyZXNzIHdpbGwgYmUgaW4NCj4+ICAgICAgICB0aGUgbGFzdCBlbGVtZW50IG9mIHRoZSBSb3V0 aW5nIGhlYWRlcjsgYXQgdGhlIHJlY2lwaWVudChzKSwNCj4+ICAgICAgICB0aGF0IGFkZHJlc3Mg d2lsbCBiZSBpbiB0aGUgRGVzdGluYXRpb24gQWRkcmVzcyBmaWVsZCBvZiB0aGUNCj4+ICAgICAg ICBJUHY2IGhlYWRlci4NCj4+IA0KPj4gSSB3b3VsZCBleHBlY3QgU1Igd291bGQgd29yayB0aGUg c2FtZS4NCj4+IA0KPj4gQ2hlZXJzLA0KPj4gT2xlDQo+IA0KDQo= From nobody Mon May 16 02:29:14 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1506A128E19; Mon, 16 May 2016 02:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uniFXC17PJ92; Mon, 16 May 2016 02:29:09 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (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 B101412B064; Mon, 16 May 2016 02:29:09 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u4G93EX3017203; Mon, 16 May 2016 02:04:03 -0700 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0b-0016f401.pphosted.com with ESMTP id 22x3hj4a3p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 16 May 2016 02:04:03 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 16 May 2016 12:04:00 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Mon, 16 May 2016 12:04:00 +0300 From: Tal Mizrahi To: "Stefano Previdi (sprevidi)" , =?utf-8?B?T2xlIFRyw7hhbg==?= Thread-Topic: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header Thread-Index: AdGuiiq1HeAHjjuQREGOx9vVjNXiwQAMTSCAAB8pyYAABk9dsA== Date: Mon, 16 May 2016 09:04:00 +0000 Message-ID: <5dc56935eba94c2390120244564f9b21@IL-EXCH02.marvell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-16_03:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1605160128 Archived-At: Cc: "spring@ietf.org" , 6man WG , "draft-ietf-6man-segment-routing-header@tools.ietf.org" Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 09:29:11 -0000 SGkgU3RlZmFubywNCg0KVGhhbmtzIGZvciB0aGUgcmVzcG9uc2VzLg0KDQo+ZXhhY3RseS4NCj4N Cj5Nb3Jlb3ZlciwgZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXIgYXNzdW1l cyBlbmNhcHN1bGF0aW9uDQo+c28gY2xlYXJseSB0aGVyZeKAmXMgbm8gTDQgaW52b2x2ZWQgaGVy ZS4NCj4NCj5zLg0KDQpUd28gcXVlc3Rpb25zOg0KMS4gV2hhdCBpZiB0aGUgZW5jYXBzdWxhdGlv biBpcyBWWExBTj8gTDQgd291bGQgc3RpbGwgYmUgaW52b2x2ZWQsIHJpZ2h0Pw0KMi4gV2hlbiB5 b3Ugc2F5ICdhc3N1bWVzIGVuY2Fwc3VsYXRpb24nLCBkb2VzIGl0IG1lYW4gdGhhdCBhIGhvc3Qg Y2Fubm90IHNlbmQgYW4gSVB2NiBwYWNrZXQgd2l0aCBhbiBTUkg/IFRoZSBjdXJyZW50IGRyYWZ0 IHNheXM6DQoNCiAgIEEgU291cmNlIFNSIE5vZGUgY2FuIGJlIGFueSBub2RlIG9yaWdpbmF0aW5n IGFuIElQdjYgcGFja2V0IHdpdGggaXRzDQogICBJUHY2IGFuZCBTZWdtZW50IFJvdXRpbmcgSGVh ZGVycy4gIFRoaXMgaW5jbHVkZSBlaXRoZXI6DQoNCiAgICAgIEEgaG9zdCBvcmlnaW5hdGluZyBh biBJUHY2IHBhY2tldC4NCg0KICAgICAgQW4gU1IgZG9tYWluIGluZ3Jlc3Mgcm91dGVyIGVuY2Fw c3VsYXRpbmcgYSByZWNlaXZlZCBJUHY2IHBhY2tldA0KICAgICAgaW50byBhbiBvdXRlciBJUHY2 IGhlYWRlciBmb2xsb3dlZCBieSBhbiBTUkguDQoNCg0KDQpXaWxsIGFwcHJlY2lhdGUgaWYgeW91 IGNhbiBjbGFyaWZ5IHRoYXQuDQoNClRoYW5rcywNClRhbC4NCg0KPi0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+RnJvbTogU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkgW21haWx0bzpzcHJl dmlkaUBjaXNjby5jb21dDQo+U2VudDogTW9uZGF5LCBNYXkgMTYsIDIwMTYgMTE6NTkgQU0NCj5U bzogT2xlIFRyw7hhbjsgVGFsIE1penJhaGkNCj5DYzogZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQt cm91dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmc7IHNwcmluZ0BpZXRmLm9yZzsNCj42bWFuIFdH DQo+U3ViamVjdDogUmU6IFtzcHJpbmddIEw0IENoZWNrc3VtIGFuZCBkcmFmdC1pZXRmLTZtYW4t c2VnbWVudC1yb3V0aW5nLQ0KPmhlYWRlcg0KPg0KPg0KPj4gT24gTWF5IDE1LCAyMDE2LCBhdCA4 OjA2IFBNLCBvdHJvYW5AZW1wbG95ZWVzLm9yZyB3cm90ZToNCj4+DQo+PiBUYWwsDQo+Pg0KPj4+ IFtBcG9sb2dpZXMgaWYgdGhpcyBpc3N1ZSBoYXMgYmVlbiBkaXNjdXNzZWQgYmVmb3JlLl0NCj4+ Pg0KPj4+IEFjY29yZGluZyB0byBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRl ciwgYW4g4oCYU1IgU2VnbWVudA0KPkVuZHBvaW50IE5vZGXigJkgdXBkYXRlcyB0aGUgRGVzdGlu YXRpb24gSVAgYWRkcmVzcy4NCj4+PiBUaGVyZWZvcmUsIGl0IG11c3QgYWxzbyB1cGRhdGUgdGhl IExheWVyIDQgQ2hlY2tzdW0sIHJpZ2h0Pw0KPj4+DQo+Pj4gSSB3b25kZXIgaWYgdGhlcmUgaXMg YW4gdXBwZXIgYm91bmQgb24gdGhlIHNpemUgb2YgdGhlIFNSSC4gT3RoZXJ3aXNlLCB0aGUNCj5M NCBDaGVja3N1bSBtYXkgYmUgbG9jYXRlZCBpbiBhIHByZXR0eSBkZWVwIGxvY2F0aW9uLg0KPj4+ IFNwZWFraW5nIGZyb20gYSBjaGlwIHZlbmRvcuKAmXMgcGVyc3BlY3RpdmUgdGhpcyBtYXkgYmUg YSBwcm9ibGVtLg0KPj4NCj4+IEZyb20gUkZDMjQ2MCwgUkgwOg0KPj4NCj4+DQo+PiAgICAgIG8g IElmIHRoZSBJUHY2IHBhY2tldCBjb250YWlucyBhIFJvdXRpbmcgaGVhZGVyLCB0aGUgRGVzdGlu YXRpb24NCj4+ICAgICAgICAgQWRkcmVzcyB1c2VkIGluIHRoZSBwc2V1ZG8taGVhZGVyIGlzIHRo YXQgb2YgdGhlIGZpbmFsDQo+PiAgICAgICAgIGRlc3RpbmF0aW9uLiAgQXQgdGhlIG9yaWdpbmF0 aW5nIG5vZGUsIHRoYXQgYWRkcmVzcyB3aWxsIGJlIGluDQo+PiAgICAgICAgIHRoZSBsYXN0IGVs ZW1lbnQgb2YgdGhlIFJvdXRpbmcgaGVhZGVyOyBhdCB0aGUgcmVjaXBpZW50KHMpLA0KPj4gICAg ICAgICB0aGF0IGFkZHJlc3Mgd2lsbCBiZSBpbiB0aGUgRGVzdGluYXRpb24gQWRkcmVzcyBmaWVs ZCBvZiB0aGUNCj4+ICAgICAgICAgSVB2NiBoZWFkZXIuDQo+Pg0KPj4gSSB3b3VsZCBleHBlY3Qg U1Igd291bGQgd29yayB0aGUgc2FtZS4NCj4NCj4NCj5leGFjdGx5Lg0KPg0KPk1vcmVvdmVyLCBk cmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlciBhc3N1bWVzIGVuY2Fwc3VsYXRp b24NCj5zbyBjbGVhcmx5IHRoZXJl4oCZcyBubyBMNCBpbnZvbHZlZCBoZXJlLg0KPg0KPnMuDQo+ DQo+DQo+Pg0KPj4gQ2hlZXJzLA0KPj4gT2xlDQo+Pg0KDQo= From nobody Mon May 16 04:13:20 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2042D12D13E; Mon, 16 May 2016 04:13:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmevwZRe7qWA; Mon, 16 May 2016 04:13:14 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 620EA12D13C; Mon, 16 May 2016 04:13:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4418; q=dns/txt; s=iport; t=1463397194; x=1464606794; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mw0wd6KH1JgmK7K8/Ju/HsAw5MeRqHW3QvfHAS/sMfE=; b=iRqEuLoU9hiVv6oIKconhHZkSkjIkRKtM0mUXe5NLiID+pASUX/+ySFB 9PN3K3tuxfGrC0OEtN5FQ+69mfxwCWm0/fIBIu3fFj4E1Btnrq5sMJEL4 nCZs0RREU3+zstMGQaHPnoQk5I2maBk8DaDOqDgtEWzY7ZxgX5G4ppRfd A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BFAgCdqjlX/5hdJa1dgzeBUwa5YAENg?= =?us-ascii?q?XaGEQIcgQU4FAEBAQEBAQFlJ4RCAQEBAwEjEUUFBwQCAQgRBAEBAQICERIDAgI?= =?us-ascii?q?CMBQBCAgBAQQOBYgnCK0AkFkBAQEBAQEBAQEBAQEBAQEBAQEBAQEcgQGFJIF2g?= =?us-ascii?q?leEViiCQSuCLgWTMIR3AY4dgWmNMIYtiRMBHgEBQoNsbocHfwEBAQ?= X-IronPort-AV: E=Sophos;i="5.24,627,1454976000"; d="scan'208";a="273954033" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 May 2016 11:13:13 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u4GBDDOT008979 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 16 May 2016 11:13:13 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 16 May 2016 07:13:12 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Mon, 16 May 2016 07:13:12 -0400 From: "Stefano Previdi (sprevidi)" To: Tal Mizrahi Thread-Topic: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header Thread-Index: AdGuiiq1HeAHjjuQREGOx9vVjNXiwQAa+DiAAB8pfIAAAC4LAAAEgrGA Date: Mon, 16 May 2016 11:13:12 +0000 Message-ID: References: <5dc56935eba94c2390120244564f9b21@IL-EXCH02.marvell.com> In-Reply-To: <5dc56935eba94c2390120244564f9b21@IL-EXCH02.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.197.212] Content-Type: text/plain; charset="utf-8" Content-ID: <34BA5EBA958F084CB5EB9CA9C3211F27@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: =?utf-8?B?T2xlIFRyw7hhbg==?= , 6man WG , "spring@ietf.org" , "draft-ietf-6man-segment-routing-header@tools.ietf.org" Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 11:13:16 -0000 SGksDQoNCk9uIE1heSAxNiwgMjAxNiwgYXQgMTE6MDQgQU0sIFRhbCBNaXpyYWhpIDx0YWxtaUBt YXJ2ZWxsLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBTdGVmYW5vLA0KPiANCj4gVGhhbmtzIGZvciB0 aGUgcmVzcG9uc2VzLg0KPiANCj4+IGV4YWN0bHkuDQo+PiANCj4+IE1vcmVvdmVyLCBkcmFmdC1p ZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlciBhc3N1bWVzIGVuY2Fwc3VsYXRpb24NCj4+ IHNvIGNsZWFybHkgdGhlcmXigJlzIG5vIEw0IGludm9sdmVkIGhlcmUuDQo+PiANCj4+IHMuDQo+ IA0KPiBUd28gcXVlc3Rpb25zOg0KPiAxLiBXaGF0IGlmIHRoZSBlbmNhcHN1bGF0aW9uIGlzIFZY TEFOPyBMNCB3b3VsZCBzdGlsbCBiZSBpbnZvbHZlZCwgcmlnaHQ/DQoNCg0KU2VlIGJlbG93Lg0K DQoNCj4gMi4gV2hlbiB5b3Ugc2F5ICdhc3N1bWVzIGVuY2Fwc3VsYXRpb24nLCBkb2VzIGl0IG1l YW4gdGhhdCBhIGhvc3QgY2Fubm90IHNlbmQgYW4gSVB2NiBwYWNrZXQgd2l0aCBhbiBTUkg/IFRo ZSBjdXJyZW50IGRyYWZ0IHNheXM6DQo+IA0KPiAgIEEgU291cmNlIFNSIE5vZGUgY2FuIGJlIGFu eSBub2RlIG9yaWdpbmF0aW5nIGFuIElQdjYgcGFja2V0IHdpdGggaXRzDQo+ICAgSVB2NiBhbmQg U2VnbWVudCBSb3V0aW5nIEhlYWRlcnMuICBUaGlzIGluY2x1ZGUgZWl0aGVyOg0KPiANCj4gICAg ICBBIGhvc3Qgb3JpZ2luYXRpbmcgYW4gSVB2NiBwYWNrZXQuDQo+IA0KPiAgICAgIEFuIFNSIGRv bWFpbiBpbmdyZXNzIHJvdXRlciBlbmNhcHN1bGF0aW5nIGEgcmVjZWl2ZWQgSVB2NiBwYWNrZXQN Cj4gICAgICBpbnRvIGFuIG91dGVyIElQdjYgaGVhZGVyIGZvbGxvd2VkIGJ5IGFuIFNSSC4NCj4g DQo+IA0KPiANCj4gV2lsbCBhcHByZWNpYXRlIGlmIHlvdSBjYW4gY2xhcmlmeSB0aGF0Lg0KDQoN Cm9rLCB0d28gY2FzZXM6DQoNCjEuIHRoZSBTUkggaXMgaW5zZXJ0ZWQgYXQgdGhlIHNvdXJjZS4g DQogICB0aGUgc291cmNlIG9yaWdpbmF0ZXMgdGhlIHBhY2tldCwgdGhlIGlwdjYgaGVhZGVyIGFu ZCANCiAgIHRoZSBTUkguIFRoZSBzb3VyY2UgY29tcHV0ZXMgTDQgY2hlY2tzdW0gdGFraW5nIGlu dG8gDQogICBhY2NvdW50IHRoZSB3aG9sZSBJUHY2K1NSSC4gSGVyZSwgdGhlcmVz4oCZIG5vdGhp bmcgbmV3IA0KICAgY29tcGFyZWQgdG8gcmZjMjQ2MC4NCg0KMi4gdGhlIFNSSCBpcyBvcmlnaW5h dGVkIGJ5IHRoZSBpbmdyZXNzIG5vZGUgb2YgdGhlIFNSIGRvbWFpbi4NCiAgIFRoaXMgaXMgZG9u ZSBieSBlbmNhcHN1bGF0aW5nIHRoZSBwYWNrZXQgaW50byBhIG91dGVyIA0KICAgKGFkZGl0aW9u YWwpIGlwdjYgaGVhZGVyIGZvbGxvd2VkIGJ5IGFuIFNSSC4gVGhpcyBpcyBMMyANCiAgIGVuY2Fw c3VsYXRpb24gYW5kIG5vIEw0IGNoZWNrc3VtIGlzIGludm9sdmVkLiBXaGVuIHRoZSANCiAgIHBh Y2tldCBsZWF2ZXMgdGhlIFNSIHR1bm5lbCB0aGUgb3V0ZXIgZW5jYXBzdWxhdGlvbiANCiAgIChp bmNsdWRpbmcgdGhlIFNSSCkgaXMgcmVtb3ZlZCBhbmQgdGhlIHBhY2tldCBjb250aW51ZXMgDQog ICBpdHMgam91cm5leSBsaWtlIG5vdGhpbmcgaGFwcGVuZWQuDQoNCnMuDQoNCg0KPiANCj4gVGhh bmtzLA0KPiBUYWwuDQo+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206 IFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpIFttYWlsdG86c3ByZXZpZGlAY2lzY28uY29tXQ0K Pj4gU2VudDogTW9uZGF5LCBNYXkgMTYsIDIwMTYgMTE6NTkgQU0NCj4+IFRvOiBPbGUgVHLDuGFu OyBUYWwgTWl6cmFoaQ0KPj4gQ2M6IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVh ZGVyQHRvb2xzLmlldGYub3JnOyBzcHJpbmdAaWV0Zi5vcmc7DQo+PiA2bWFuIFdHDQo+PiBTdWJq ZWN0OiBSZTogW3NwcmluZ10gTDQgQ2hlY2tzdW0gYW5kIGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50 LXJvdXRpbmctDQo+PiBoZWFkZXINCj4+IA0KPj4gDQo+Pj4gT24gTWF5IDE1LCAyMDE2LCBhdCA4 OjA2IFBNLCBvdHJvYW5AZW1wbG95ZWVzLm9yZyB3cm90ZToNCj4+PiANCj4+PiBUYWwsDQo+Pj4g DQo+Pj4+IFtBcG9sb2dpZXMgaWYgdGhpcyBpc3N1ZSBoYXMgYmVlbiBkaXNjdXNzZWQgYmVmb3Jl Ll0NCj4+Pj4gDQo+Pj4+IEFjY29yZGluZyB0byBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0 aW5nLWhlYWRlciwgYW4g4oCYU1IgU2VnbWVudA0KPj4gRW5kcG9pbnQgTm9kZeKAmSB1cGRhdGVz IHRoZSBEZXN0aW5hdGlvbiBJUCBhZGRyZXNzLg0KPj4+PiBUaGVyZWZvcmUsIGl0IG11c3QgYWxz byB1cGRhdGUgdGhlIExheWVyIDQgQ2hlY2tzdW0sIHJpZ2h0Pw0KPj4+PiANCj4+Pj4gSSB3b25k ZXIgaWYgdGhlcmUgaXMgYW4gdXBwZXIgYm91bmQgb24gdGhlIHNpemUgb2YgdGhlIFNSSC4gT3Ro ZXJ3aXNlLCB0aGUNCj4+IEw0IENoZWNrc3VtIG1heSBiZSBsb2NhdGVkIGluIGEgcHJldHR5IGRl ZXAgbG9jYXRpb24uDQo+Pj4+IFNwZWFraW5nIGZyb20gYSBjaGlwIHZlbmRvcuKAmXMgcGVyc3Bl Y3RpdmUgdGhpcyBtYXkgYmUgYSBwcm9ibGVtLg0KPj4+IA0KPj4+IEZyb20gUkZDMjQ2MCwgUkgw Og0KPj4+IA0KPj4+IA0KPj4+ICAgICBvICBJZiB0aGUgSVB2NiBwYWNrZXQgY29udGFpbnMgYSBS b3V0aW5nIGhlYWRlciwgdGhlIERlc3RpbmF0aW9uDQo+Pj4gICAgICAgIEFkZHJlc3MgdXNlZCBp biB0aGUgcHNldWRvLWhlYWRlciBpcyB0aGF0IG9mIHRoZSBmaW5hbA0KPj4+ICAgICAgICBkZXN0 aW5hdGlvbi4gIEF0IHRoZSBvcmlnaW5hdGluZyBub2RlLCB0aGF0IGFkZHJlc3Mgd2lsbCBiZSBp bg0KPj4+ICAgICAgICB0aGUgbGFzdCBlbGVtZW50IG9mIHRoZSBSb3V0aW5nIGhlYWRlcjsgYXQg dGhlIHJlY2lwaWVudChzKSwNCj4+PiAgICAgICAgdGhhdCBhZGRyZXNzIHdpbGwgYmUgaW4gdGhl IERlc3RpbmF0aW9uIEFkZHJlc3MgZmllbGQgb2YgdGhlDQo+Pj4gICAgICAgIElQdjYgaGVhZGVy Lg0KPj4+IA0KPj4+IEkgd291bGQgZXhwZWN0IFNSIHdvdWxkIHdvcmsgdGhlIHNhbWUuDQo+PiAN Cj4+IA0KPj4gZXhhY3RseS4NCj4+IA0KPj4gTW9yZW92ZXIsIGRyYWZ0LWlldGYtNm1hbi1zZWdt ZW50LXJvdXRpbmctaGVhZGVyIGFzc3VtZXMgZW5jYXBzdWxhdGlvbg0KPj4gc28gY2xlYXJseSB0 aGVyZeKAmXMgbm8gTDQgaW52b2x2ZWQgaGVyZS4NCj4+IA0KPj4gcy4NCj4+IA0KPj4gDQo+Pj4g DQo+Pj4gQ2hlZXJzLA0KPj4+IE9sZQ0KPj4+IA0KPiANCg0K From nobody Mon May 16 04:20:01 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBEF12D149; Mon, 16 May 2016 04:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 siS_aUSdvEgr; Mon, 16 May 2016 04:19:54 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE5C127058; Mon, 16 May 2016 04:19:54 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u4GBBnBv015856; Mon, 16 May 2016 04:19:51 -0700 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0a-0016f401.pphosted.com with ESMTP id 22xc8c3rrx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 16 May 2016 04:19:51 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 16 May 2016 14:19:47 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Mon, 16 May 2016 14:19:47 +0300 From: Tal Mizrahi To: "Stefano Previdi (sprevidi)" Thread-Topic: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header Thread-Index: AdGuiiq1HeAHjjuQREGOx9vVjNXiwQAMTSCAAB8pyYAABk9dsP//8wwA///NLLA= Date: Mon, 16 May 2016 11:19:46 +0000 Message-ID: References: <5dc56935eba94c2390120244564f9b21@IL-EXCH02.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-16_05:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1605160157 Archived-At: Cc: =?utf-8?B?T2xlIFRyw7hhbg==?= , 6man WG , "spring@ietf.org" , "draft-ietf-6man-segment-routing-header@tools.ietf.org" Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 11:19:56 -0000 SGkgU3RlZmFubywNCg0KVGhhbmtzIGFnYWluIGZvciB0aGUgcHJvbXB0IHJlc3BvbnNlLg0KDQo+ Mi4gdGhlIFNSSCBpcyBvcmlnaW5hdGVkIGJ5IHRoZSBpbmdyZXNzIG5vZGUgb2YgdGhlIFNSIGRv bWFpbi4NCj4gICBUaGlzIGlzIGRvbmUgYnkgZW5jYXBzdWxhdGluZyB0aGUgcGFja2V0IGludG8g YSBvdXRlcg0KPiAgIChhZGRpdGlvbmFsKSBpcHY2IGhlYWRlciBmb2xsb3dlZCBieSBhbiBTUkgu IFRoaXMgaXMgTDMNCj4gICBlbmNhcHN1bGF0aW9uIGFuZCBubyBMNCBjaGVja3N1bSBpcyBpbnZv bHZlZC4gV2hlbiB0aGUNCj4gICBwYWNrZXQgbGVhdmVzIHRoZSBTUiB0dW5uZWwgdGhlIG91dGVy IGVuY2Fwc3VsYXRpb24NCj4gICAoaW5jbHVkaW5nIHRoZSBTUkgpIGlzIHJlbW92ZWQgYW5kIHRo ZSBwYWNrZXQgY29udGludWVzDQo+ICAgaXRzIGpvdXJuZXkgbGlrZSBub3RoaW5nIGhhcHBlbmVk Lg0KDQpTbyBWWExBTiBpcyBvZmYgdGhlIHRhYmxlPyBJdCB3b3VsZCBiZSB3b3J0aHdoaWxlIHRv IGNsYXJpZnkgdGhpcyBpbiB0aGUgZHJhZnQuIElmIHlvdSBoYXZlIGEgc3BlY2lmaWMgZW5jYXBz dWxhdGlvbiBpbiBtaW5kLCBpdCB3b3VsZCBiZSBncmVhdCBpZiB0aGUgZHJhZnQgd291bGQgc3Bl Y2lmeSBpdC4NCg0KVGhhbmtzLA0KVGFsLg0KDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPkZyb206IFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpIFttYWlsdG86c3ByZXZpZGlAY2lz Y28uY29tXQ0KPlNlbnQ6IE1vbmRheSwgTWF5IDE2LCAyMDE2IDI6MTMgUE0NCj5UbzogVGFsIE1p enJhaGkNCj5DYzogT2xlIFRyw7hhbjsgZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1o ZWFkZXJAdG9vbHMuaWV0Zi5vcmc7DQo+c3ByaW5nQGlldGYub3JnOyA2bWFuIFdHDQo+U3ViamVj dDogUmU6IFtzcHJpbmddIEw0IENoZWNrc3VtIGFuZCBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1y b3V0aW5nLQ0KPmhlYWRlcg0KPg0KPkhpLA0KPg0KPk9uIE1heSAxNiwgMjAxNiwgYXQgMTE6MDQg QU0sIFRhbCBNaXpyYWhpIDx0YWxtaUBtYXJ2ZWxsLmNvbT4gd3JvdGU6DQo+Pg0KPj4gSGkgU3Rl ZmFubywNCj4+DQo+PiBUaGFua3MgZm9yIHRoZSByZXNwb25zZXMuDQo+Pg0KPj4+IGV4YWN0bHku DQo+Pj4NCj4+PiBNb3Jlb3ZlciwgZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFk ZXIgYXNzdW1lcw0KPj4+IGVuY2Fwc3VsYXRpb24gc28gY2xlYXJseSB0aGVyZeKAmXMgbm8gTDQg aW52b2x2ZWQgaGVyZS4NCj4+Pg0KPj4+IHMuDQo+Pg0KPj4gVHdvIHF1ZXN0aW9uczoNCj4+IDEu IFdoYXQgaWYgdGhlIGVuY2Fwc3VsYXRpb24gaXMgVlhMQU4/IEw0IHdvdWxkIHN0aWxsIGJlIGlu dm9sdmVkLCByaWdodD8NCj4NCj4NCj5TZWUgYmVsb3cuDQo+DQo+DQo+PiAyLiBXaGVuIHlvdSBz YXkgJ2Fzc3VtZXMgZW5jYXBzdWxhdGlvbicsIGRvZXMgaXQgbWVhbiB0aGF0IGEgaG9zdCBjYW5u b3QNCj5zZW5kIGFuIElQdjYgcGFja2V0IHdpdGggYW4gU1JIPyBUaGUgY3VycmVudCBkcmFmdCBz YXlzOg0KPj4NCj4+ICAgQSBTb3VyY2UgU1IgTm9kZSBjYW4gYmUgYW55IG5vZGUgb3JpZ2luYXRp bmcgYW4gSVB2NiBwYWNrZXQgd2l0aCBpdHMNCj4+ICAgSVB2NiBhbmQgU2VnbWVudCBSb3V0aW5n IEhlYWRlcnMuICBUaGlzIGluY2x1ZGUgZWl0aGVyOg0KPj4NCj4+ICAgICAgQSBob3N0IG9yaWdp bmF0aW5nIGFuIElQdjYgcGFja2V0Lg0KPj4NCj4+ICAgICAgQW4gU1IgZG9tYWluIGluZ3Jlc3Mg cm91dGVyIGVuY2Fwc3VsYXRpbmcgYSByZWNlaXZlZCBJUHY2IHBhY2tldA0KPj4gICAgICBpbnRv IGFuIG91dGVyIElQdjYgaGVhZGVyIGZvbGxvd2VkIGJ5IGFuIFNSSC4NCj4+DQo+Pg0KPj4NCj4+ IFdpbGwgYXBwcmVjaWF0ZSBpZiB5b3UgY2FuIGNsYXJpZnkgdGhhdC4NCj4NCj4NCj5vaywgdHdv IGNhc2VzOg0KPg0KPjEuIHRoZSBTUkggaXMgaW5zZXJ0ZWQgYXQgdGhlIHNvdXJjZS4NCj4gICB0 aGUgc291cmNlIG9yaWdpbmF0ZXMgdGhlIHBhY2tldCwgdGhlIGlwdjYgaGVhZGVyIGFuZA0KPiAg IHRoZSBTUkguIFRoZSBzb3VyY2UgY29tcHV0ZXMgTDQgY2hlY2tzdW0gdGFraW5nIGludG8NCj4g ICBhY2NvdW50IHRoZSB3aG9sZSBJUHY2K1NSSC4gSGVyZSwgdGhlcmVz4oCZIG5vdGhpbmcgbmV3 DQo+ICAgY29tcGFyZWQgdG8gcmZjMjQ2MC4NCj4NCj4yLiB0aGUgU1JIIGlzIG9yaWdpbmF0ZWQg YnkgdGhlIGluZ3Jlc3Mgbm9kZSBvZiB0aGUgU1IgZG9tYWluLg0KPiAgIFRoaXMgaXMgZG9uZSBi eSBlbmNhcHN1bGF0aW5nIHRoZSBwYWNrZXQgaW50byBhIG91dGVyDQo+ICAgKGFkZGl0aW9uYWwp IGlwdjYgaGVhZGVyIGZvbGxvd2VkIGJ5IGFuIFNSSC4gVGhpcyBpcyBMMw0KPiAgIGVuY2Fwc3Vs YXRpb24gYW5kIG5vIEw0IGNoZWNrc3VtIGlzIGludm9sdmVkLiBXaGVuIHRoZQ0KPiAgIHBhY2tl dCBsZWF2ZXMgdGhlIFNSIHR1bm5lbCB0aGUgb3V0ZXIgZW5jYXBzdWxhdGlvbg0KPiAgIChpbmNs dWRpbmcgdGhlIFNSSCkgaXMgcmVtb3ZlZCBhbmQgdGhlIHBhY2tldCBjb250aW51ZXMNCj4gICBp dHMgam91cm5leSBsaWtlIG5vdGhpbmcgaGFwcGVuZWQuDQo+DQo+cy4NCj4NCj4NCj4+DQo+PiBU aGFua3MsDQo+PiBUYWwuDQo+Pg0KPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4g RnJvbTogU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkgW21haWx0bzpzcHJldmlkaUBjaXNjby5j b21dDQo+Pj4gU2VudDogTW9uZGF5LCBNYXkgMTYsIDIwMTYgMTE6NTkgQU0NCj4+PiBUbzogT2xl IFRyw7hhbjsgVGFsIE1penJhaGkNCj4+PiBDYzogZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91 dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmc7DQo+Pj4gc3ByaW5nQGlldGYub3JnOyA2bWFuIFdH DQo+Pj4gU3ViamVjdDogUmU6IFtzcHJpbmddIEw0IENoZWNrc3VtIGFuZA0KPj4+IGRyYWZ0LWll dGYtNm1hbi1zZWdtZW50LXJvdXRpbmctIGhlYWRlcg0KPj4+DQo+Pj4NCj4+Pj4gT24gTWF5IDE1 LCAyMDE2LCBhdCA4OjA2IFBNLCBvdHJvYW5AZW1wbG95ZWVzLm9yZyB3cm90ZToNCj4+Pj4NCj4+ Pj4gVGFsLA0KPj4+Pg0KPj4+Pj4gW0Fwb2xvZ2llcyBpZiB0aGlzIGlzc3VlIGhhcyBiZWVuIGRp c2N1c3NlZCBiZWZvcmUuXQ0KPj4+Pj4NCj4+Pj4+IEFjY29yZGluZyB0byBkcmFmdC1pZXRmLTZt YW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlciwgYW4g4oCYU1IgU2VnbWVudA0KPj4+IEVuZHBvaW50 IE5vZGXigJkgdXBkYXRlcyB0aGUgRGVzdGluYXRpb24gSVAgYWRkcmVzcy4NCj4+Pj4+IFRoZXJl Zm9yZSwgaXQgbXVzdCBhbHNvIHVwZGF0ZSB0aGUgTGF5ZXIgNCBDaGVja3N1bSwgcmlnaHQ/DQo+ Pj4+Pg0KPj4+Pj4gSSB3b25kZXIgaWYgdGhlcmUgaXMgYW4gdXBwZXIgYm91bmQgb24gdGhlIHNp emUgb2YgdGhlIFNSSC4NCj4+Pj4+IE90aGVyd2lzZSwgdGhlDQo+Pj4gTDQgQ2hlY2tzdW0gbWF5 IGJlIGxvY2F0ZWQgaW4gYSBwcmV0dHkgZGVlcCBsb2NhdGlvbi4NCj4+Pj4+IFNwZWFraW5nIGZy b20gYSBjaGlwIHZlbmRvcuKAmXMgcGVyc3BlY3RpdmUgdGhpcyBtYXkgYmUgYSBwcm9ibGVtLg0K Pj4+Pg0KPj4+PiBGcm9tIFJGQzI0NjAsIFJIMDoNCj4+Pj4NCj4+Pj4NCj4+Pj4gICAgIG8gIElm IHRoZSBJUHY2IHBhY2tldCBjb250YWlucyBhIFJvdXRpbmcgaGVhZGVyLCB0aGUgRGVzdGluYXRp b24NCj4+Pj4gICAgICAgIEFkZHJlc3MgdXNlZCBpbiB0aGUgcHNldWRvLWhlYWRlciBpcyB0aGF0 IG9mIHRoZSBmaW5hbA0KPj4+PiAgICAgICAgZGVzdGluYXRpb24uICBBdCB0aGUgb3JpZ2luYXRp bmcgbm9kZSwgdGhhdCBhZGRyZXNzIHdpbGwgYmUgaW4NCj4+Pj4gICAgICAgIHRoZSBsYXN0IGVs ZW1lbnQgb2YgdGhlIFJvdXRpbmcgaGVhZGVyOyBhdCB0aGUgcmVjaXBpZW50KHMpLA0KPj4+PiAg ICAgICAgdGhhdCBhZGRyZXNzIHdpbGwgYmUgaW4gdGhlIERlc3RpbmF0aW9uIEFkZHJlc3MgZmll bGQgb2YgdGhlDQo+Pj4+ICAgICAgICBJUHY2IGhlYWRlci4NCj4+Pj4NCj4+Pj4gSSB3b3VsZCBl eHBlY3QgU1Igd291bGQgd29yayB0aGUgc2FtZS4NCj4+Pg0KPj4+DQo+Pj4gZXhhY3RseS4NCj4+ Pg0KPj4+IE1vcmVvdmVyLCBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlciBh c3N1bWVzDQo+Pj4gZW5jYXBzdWxhdGlvbiBzbyBjbGVhcmx5IHRoZXJl4oCZcyBubyBMNCBpbnZv bHZlZCBoZXJlLg0KPj4+DQo+Pj4gcy4NCj4+Pg0KPj4+DQo+Pj4+DQo+Pj4+IENoZWVycywNCj4+ Pj4gT2xlDQo+Pj4+DQo+Pg0KDQo= From nobody Mon May 16 04:24:15 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C89512D14D; Mon, 16 May 2016 04:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NqlxjnYIk9Hb; Mon, 16 May 2016 04:24:08 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94A11127058; Mon, 16 May 2016 04:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6314; q=dns/txt; s=iport; t=1463397848; x=1464607448; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WLWoejAXhpj3o/KjUI2yPtaBTax5Y8VSlhoz5SgNEQY=; b=kGSwV3nqOhySlwwS2GolfNrYIeevCLCBcfliIDnScmC45MJ8ssHkvwx5 5QzwMx9OICbIUTIgBqmQ8Cmh4ToIq5dnh0FLfaudAPDDOK49qcJTZF3nY s2h2lRIW60sTO0MR8rbAY+yzmvQViK0/40Ev92RiSZGVaCiaK0MYD+Rds 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BFAgBtrTlX/4QNJK1dgzeBUwa5YAENg?= =?us-ascii?q?XaGEQIcgQU4FAEBAQEBAQFlJ4RCAQEBAwEjEUUFBwQCAQgRBAEBAQICERIDAgI?= =?us-ascii?q?CMBQBCAgCBA4FiCcIrQ6QWgEBAQEBAQEBAQEBAQEBAQEBAQEBARyBAYUkgXaCV?= =?us-ascii?q?4RWKIJBK4IuBZgnAY4dgWmNMIYtiRMBHgEBQoNsboZIBzh/AQEB?= X-IronPort-AV: E=Sophos;i="5.24,627,1454976000"; d="scan'208";a="272170972" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 May 2016 11:24:07 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u4GBO7Ts007432 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 16 May 2016 11:24:07 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 16 May 2016 07:24:06 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Mon, 16 May 2016 07:24:06 -0400 From: "Stefano Previdi (sprevidi)" To: Tal Mizrahi Thread-Topic: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header Thread-Index: AdGuiiq1HeAHjjuQREGOx9vVjNXiwQAa+DiAAB8pfIAAAC4LAAAEgrGAAAA7KQAAACaYgA== Date: Mon, 16 May 2016 11:24:06 +0000 Message-ID: <0551686F-F1D2-4C34-81C8-530F1BEE1BDF@cisco.com> References: <5dc56935eba94c2390120244564f9b21@IL-EXCH02.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.197.212] Content-Type: text/plain; charset="utf-8" Content-ID: <09AA67C7F67D70478E750E79BA6A3BE5@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: =?utf-8?B?T2xlIFRyw7hhbg==?= , 6man WG , "spring@ietf.org" , "draft-ietf-6man-segment-routing-header@tools.ietf.org" Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 11:24:10 -0000 DQo+IE9uIE1heSAxNiwgMjAxNiwgYXQgMToxOSBQTSwgVGFsIE1penJhaGkgPHRhbG1pQG1hcnZl bGwuY29tPiB3cm90ZToNCj4gDQo+IEhpIFN0ZWZhbm8sDQo+IA0KPiBUaGFua3MgYWdhaW4gZm9y IHRoZSBwcm9tcHQgcmVzcG9uc2UuDQo+IA0KPj4gMi4gdGhlIFNSSCBpcyBvcmlnaW5hdGVkIGJ5 IHRoZSBpbmdyZXNzIG5vZGUgb2YgdGhlIFNSIGRvbWFpbi4NCj4+ICBUaGlzIGlzIGRvbmUgYnkg ZW5jYXBzdWxhdGluZyB0aGUgcGFja2V0IGludG8gYSBvdXRlcg0KPj4gIChhZGRpdGlvbmFsKSBp cHY2IGhlYWRlciBmb2xsb3dlZCBieSBhbiBTUkguIFRoaXMgaXMgTDMNCj4+ICBlbmNhcHN1bGF0 aW9uIGFuZCBubyBMNCBjaGVja3N1bSBpcyBpbnZvbHZlZC4gV2hlbiB0aGUNCj4+ICBwYWNrZXQg bGVhdmVzIHRoZSBTUiB0dW5uZWwgdGhlIG91dGVyIGVuY2Fwc3VsYXRpb24NCj4+ICAoaW5jbHVk aW5nIHRoZSBTUkgpIGlzIHJlbW92ZWQgYW5kIHRoZSBwYWNrZXQgY29udGludWVzDQo+PiAgaXRz IGpvdXJuZXkgbGlrZSBub3RoaW5nIGhhcHBlbmVkLg0KPiANCj4gU28gVlhMQU4gaXMgb2ZmIHRo ZSB0YWJsZT8NCg0KDQppdOKAmXMgYWxsIGFib3V0IElQLCBub3QgbGF5ZXItMi4NCg0Kcy4NCg0K DQo+IEl0IHdvdWxkIGJlIHdvcnRod2hpbGUgdG8gY2xhcmlmeSB0aGlzIGluIHRoZSBkcmFmdC4g SWYgeW91IGhhdmUgYSBzcGVjaWZpYyBlbmNhcHN1bGF0aW9uIGluIG1pbmQsIGl0IHdvdWxkIGJl IGdyZWF0IGlmIHRoZSBkcmFmdCB3b3VsZCBzcGVjaWZ5IGl0Lg0KPiANCj4gVGhhbmtzLA0KPiBU YWwuDQo+IA0KPiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBTdGVm YW5vIFByZXZpZGkgKHNwcmV2aWRpKSBbbWFpbHRvOnNwcmV2aWRpQGNpc2NvLmNvbV0NCj4+IFNl bnQ6IE1vbmRheSwgTWF5IDE2LCAyMDE2IDI6MTMgUE0NCj4+IFRvOiBUYWwgTWl6cmFoaQ0KPj4g Q2M6IE9sZSBUcsO4YW47IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyQHRv b2xzLmlldGYub3JnOw0KPj4gc3ByaW5nQGlldGYub3JnOyA2bWFuIFdHDQo+PiBTdWJqZWN0OiBS ZTogW3NwcmluZ10gTDQgQ2hlY2tzdW0gYW5kIGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRp bmctDQo+PiBoZWFkZXINCj4+IA0KPj4gSGksDQo+PiANCj4+IE9uIE1heSAxNiwgMjAxNiwgYXQg MTE6MDQgQU0sIFRhbCBNaXpyYWhpIDx0YWxtaUBtYXJ2ZWxsLmNvbT4gd3JvdGU6DQo+Pj4gDQo+ Pj4gSGkgU3RlZmFubywNCj4+PiANCj4+PiBUaGFua3MgZm9yIHRoZSByZXNwb25zZXMuDQo+Pj4g DQo+Pj4+IGV4YWN0bHkuDQo+Pj4+IA0KPj4+PiBNb3Jlb3ZlciwgZHJhZnQtaWV0Zi02bWFuLXNl Z21lbnQtcm91dGluZy1oZWFkZXIgYXNzdW1lcw0KPj4+PiBlbmNhcHN1bGF0aW9uIHNvIGNsZWFy bHkgdGhlcmXigJlzIG5vIEw0IGludm9sdmVkIGhlcmUuDQo+Pj4+IA0KPj4+PiBzLg0KPj4+IA0K Pj4+IFR3byBxdWVzdGlvbnM6DQo+Pj4gMS4gV2hhdCBpZiB0aGUgZW5jYXBzdWxhdGlvbiBpcyBW WExBTj8gTDQgd291bGQgc3RpbGwgYmUgaW52b2x2ZWQsIHJpZ2h0Pw0KPj4gDQo+PiANCj4+IFNl ZSBiZWxvdy4NCj4+IA0KPj4gDQo+Pj4gMi4gV2hlbiB5b3Ugc2F5ICdhc3N1bWVzIGVuY2Fwc3Vs YXRpb24nLCBkb2VzIGl0IG1lYW4gdGhhdCBhIGhvc3QgY2Fubm90DQo+PiBzZW5kIGFuIElQdjYg cGFja2V0IHdpdGggYW4gU1JIPyBUaGUgY3VycmVudCBkcmFmdCBzYXlzOg0KPj4+IA0KPj4+ICBB IFNvdXJjZSBTUiBOb2RlIGNhbiBiZSBhbnkgbm9kZSBvcmlnaW5hdGluZyBhbiBJUHY2IHBhY2tl dCB3aXRoIGl0cw0KPj4+ICBJUHY2IGFuZCBTZWdtZW50IFJvdXRpbmcgSGVhZGVycy4gIFRoaXMg aW5jbHVkZSBlaXRoZXI6DQo+Pj4gDQo+Pj4gICAgIEEgaG9zdCBvcmlnaW5hdGluZyBhbiBJUHY2 IHBhY2tldC4NCj4+PiANCj4+PiAgICAgQW4gU1IgZG9tYWluIGluZ3Jlc3Mgcm91dGVyIGVuY2Fw c3VsYXRpbmcgYSByZWNlaXZlZCBJUHY2IHBhY2tldA0KPj4+ICAgICBpbnRvIGFuIG91dGVyIElQ djYgaGVhZGVyIGZvbGxvd2VkIGJ5IGFuIFNSSC4NCj4+PiANCj4+PiANCj4+PiANCj4+PiBXaWxs IGFwcHJlY2lhdGUgaWYgeW91IGNhbiBjbGFyaWZ5IHRoYXQuDQo+PiANCj4+IA0KPj4gb2ssIHR3 byBjYXNlczoNCj4+IA0KPj4gMS4gdGhlIFNSSCBpcyBpbnNlcnRlZCBhdCB0aGUgc291cmNlLg0K Pj4gIHRoZSBzb3VyY2Ugb3JpZ2luYXRlcyB0aGUgcGFja2V0LCB0aGUgaXB2NiBoZWFkZXIgYW5k DQo+PiAgdGhlIFNSSC4gVGhlIHNvdXJjZSBjb21wdXRlcyBMNCBjaGVja3N1bSB0YWtpbmcgaW50 bw0KPj4gIGFjY291bnQgdGhlIHdob2xlIElQdjYrU1JILiBIZXJlLCB0aGVyZXPigJkgbm90aGlu ZyBuZXcNCj4+ICBjb21wYXJlZCB0byByZmMyNDYwLg0KPj4gDQo+PiAyLiB0aGUgU1JIIGlzIG9y aWdpbmF0ZWQgYnkgdGhlIGluZ3Jlc3Mgbm9kZSBvZiB0aGUgU1IgZG9tYWluLg0KPj4gIFRoaXMg aXMgZG9uZSBieSBlbmNhcHN1bGF0aW5nIHRoZSBwYWNrZXQgaW50byBhIG91dGVyDQo+PiAgKGFk ZGl0aW9uYWwpIGlwdjYgaGVhZGVyIGZvbGxvd2VkIGJ5IGFuIFNSSC4gVGhpcyBpcyBMMw0KPj4g IGVuY2Fwc3VsYXRpb24gYW5kIG5vIEw0IGNoZWNrc3VtIGlzIGludm9sdmVkLiBXaGVuIHRoZQ0K Pj4gIHBhY2tldCBsZWF2ZXMgdGhlIFNSIHR1bm5lbCB0aGUgb3V0ZXIgZW5jYXBzdWxhdGlvbg0K Pj4gIChpbmNsdWRpbmcgdGhlIFNSSCkgaXMgcmVtb3ZlZCBhbmQgdGhlIHBhY2tldCBjb250aW51 ZXMNCj4+ICBpdHMgam91cm5leSBsaWtlIG5vdGhpbmcgaGFwcGVuZWQuDQo+PiANCj4+IHMuDQo+ PiANCj4+IA0KPj4+IA0KPj4+IFRoYW5rcywNCj4+PiBUYWwuDQo+Pj4gDQo+Pj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+IEZyb206IFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkp IFttYWlsdG86c3ByZXZpZGlAY2lzY28uY29tXQ0KPj4+PiBTZW50OiBNb25kYXksIE1heSAxNiwg MjAxNiAxMTo1OSBBTQ0KPj4+PiBUbzogT2xlIFRyw7hhbjsgVGFsIE1penJhaGkNCj4+Pj4gQ2M6 IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyQHRvb2xzLmlldGYub3JnOw0K Pj4+PiBzcHJpbmdAaWV0Zi5vcmc7IDZtYW4gV0cNCj4+Pj4gU3ViamVjdDogUmU6IFtzcHJpbmdd IEw0IENoZWNrc3VtIGFuZA0KPj4+PiBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLSBo ZWFkZXINCj4+Pj4gDQo+Pj4+IA0KPj4+Pj4gT24gTWF5IDE1LCAyMDE2LCBhdCA4OjA2IFBNLCBv dHJvYW5AZW1wbG95ZWVzLm9yZyB3cm90ZToNCj4+Pj4+IA0KPj4+Pj4gVGFsLA0KPj4+Pj4gDQo+ Pj4+Pj4gW0Fwb2xvZ2llcyBpZiB0aGlzIGlzc3VlIGhhcyBiZWVuIGRpc2N1c3NlZCBiZWZvcmUu XQ0KPj4+Pj4+IA0KPj4+Pj4+IEFjY29yZGluZyB0byBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1y b3V0aW5nLWhlYWRlciwgYW4g4oCYU1IgU2VnbWVudA0KPj4+PiBFbmRwb2ludCBOb2Rl4oCZIHVw ZGF0ZXMgdGhlIERlc3RpbmF0aW9uIElQIGFkZHJlc3MuDQo+Pj4+Pj4gVGhlcmVmb3JlLCBpdCBt dXN0IGFsc28gdXBkYXRlIHRoZSBMYXllciA0IENoZWNrc3VtLCByaWdodD8NCj4+Pj4+PiANCj4+ Pj4+PiBJIHdvbmRlciBpZiB0aGVyZSBpcyBhbiB1cHBlciBib3VuZCBvbiB0aGUgc2l6ZSBvZiB0 aGUgU1JILg0KPj4+Pj4+IE90aGVyd2lzZSwgdGhlDQo+Pj4+IEw0IENoZWNrc3VtIG1heSBiZSBs b2NhdGVkIGluIGEgcHJldHR5IGRlZXAgbG9jYXRpb24uDQo+Pj4+Pj4gU3BlYWtpbmcgZnJvbSBh IGNoaXAgdmVuZG9y4oCZcyBwZXJzcGVjdGl2ZSB0aGlzIG1heSBiZSBhIHByb2JsZW0uDQo+Pj4+ PiANCj4+Pj4+IEZyb20gUkZDMjQ2MCwgUkgwOg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+ICAgIG8g IElmIHRoZSBJUHY2IHBhY2tldCBjb250YWlucyBhIFJvdXRpbmcgaGVhZGVyLCB0aGUgRGVzdGlu YXRpb24NCj4+Pj4+ICAgICAgIEFkZHJlc3MgdXNlZCBpbiB0aGUgcHNldWRvLWhlYWRlciBpcyB0 aGF0IG9mIHRoZSBmaW5hbA0KPj4+Pj4gICAgICAgZGVzdGluYXRpb24uICBBdCB0aGUgb3JpZ2lu YXRpbmcgbm9kZSwgdGhhdCBhZGRyZXNzIHdpbGwgYmUgaW4NCj4+Pj4+ICAgICAgIHRoZSBsYXN0 IGVsZW1lbnQgb2YgdGhlIFJvdXRpbmcgaGVhZGVyOyBhdCB0aGUgcmVjaXBpZW50KHMpLA0KPj4+ Pj4gICAgICAgdGhhdCBhZGRyZXNzIHdpbGwgYmUgaW4gdGhlIERlc3RpbmF0aW9uIEFkZHJlc3Mg ZmllbGQgb2YgdGhlDQo+Pj4+PiAgICAgICBJUHY2IGhlYWRlci4NCj4+Pj4+IA0KPj4+Pj4gSSB3 b3VsZCBleHBlY3QgU1Igd291bGQgd29yayB0aGUgc2FtZS4NCj4+Pj4gDQo+Pj4+IA0KPj4+PiBl eGFjdGx5Lg0KPj4+PiANCj4+Pj4gTW9yZW92ZXIsIGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJv dXRpbmctaGVhZGVyIGFzc3VtZXMNCj4+Pj4gZW5jYXBzdWxhdGlvbiBzbyBjbGVhcmx5IHRoZXJl 4oCZcyBubyBMNCBpbnZvbHZlZCBoZXJlLg0KPj4+PiANCj4+Pj4gcy4NCj4+Pj4gDQo+Pj4+IA0K Pj4+Pj4gDQo+Pj4+PiBDaGVlcnMsDQo+Pj4+PiBPbGUNCj4+Pj4+IA0KPj4+IA0KPiANCg0K From nobody Mon May 16 04:32:29 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9053812D133; Mon, 16 May 2016 04:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 BgmY-9YXYJpz; Mon, 16 May 2016 04:32:26 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6145812D0C2; Mon, 16 May 2016 04:32:26 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u4GBW0Ji026986; Mon, 16 May 2016 04:32:25 -0700 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0a-0016f401.pphosted.com with ESMTP id 22xc8c3sp0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 16 May 2016 04:32:24 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 16 May 2016 14:32:20 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Mon, 16 May 2016 14:32:20 +0300 From: Tal Mizrahi To: "Stefano Previdi (sprevidi)" Thread-Topic: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header Thread-Index: AdGuiiq1HeAHjjuQREGOx9vVjNXiwQAMTSCAAB8pyYAABk9dsP//8wwA///NLLCAADXfAP//zJ5w Date: Mon, 16 May 2016 11:32:20 +0000 Message-ID: <5d889e7013b44b27ae1e75cf7ea2dd22@IL-EXCH02.marvell.com> References: <5dc56935eba94c2390120244564f9b21@IL-EXCH02.marvell.com> <0551686F-F1D2-4C34-81C8-530F1BEE1BDF@cisco.com> In-Reply-To: <0551686F-F1D2-4C34-81C8-530F1BEE1BDF@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-16_06:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1605160160 Archived-At: Cc: =?utf-8?B?T2xlIFRyw7hhbg==?= , 6man WG , "spring@ietf.org" , "draft-ietf-6man-segment-routing-header@tools.ietf.org" Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 11:32:28 -0000 Pml04oCZcyBhbGwgYWJvdXQgSVAsIG5vdCBsYXllci0yLg0KPg0KPnMuDQoNClJpZ2h0LiBIb3dl dmVyLCBpdCBhcHBlYXJzIHRoYXQgYXQgbGVhc3QgaW4gc29tZSBjYXNlcyBhIFZYTEFOIFZURVAg d2lsbCB1c2UgU1IuIEl0IGNlcnRhaW5seSBtYXkgYmUgdGhlIGNhc2UgaW4gU0ZDIHVzZSBjYXNl cyAoc2VlIFNlY3Rpb24gMi4zIGluIGRyYWZ0LWlldGYtc3ByaW5nLWlwdjYtdXNlLWNhc2VzKS4N Cg0KDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IFN0ZWZhbm8gUHJldmlk aSAoc3ByZXZpZGkpIFttYWlsdG86c3ByZXZpZGlAY2lzY28uY29tXQ0KPlNlbnQ6IE1vbmRheSwg TWF5IDE2LCAyMDE2IDI6MjQgUE0NCj5UbzogVGFsIE1penJhaGkNCj5DYzogT2xlIFRyw7hhbjsg ZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmc7DQo+ c3ByaW5nQGlldGYub3JnOyA2bWFuIFdHDQo+U3ViamVjdDogUmU6IFtzcHJpbmddIEw0IENoZWNr c3VtIGFuZCBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLQ0KPmhlYWRlcg0KPg0KPg0K Pj4gT24gTWF5IDE2LCAyMDE2LCBhdCAxOjE5IFBNLCBUYWwgTWl6cmFoaSA8dGFsbWlAbWFydmVs bC5jb20+IHdyb3RlOg0KPj4NCj4+IEhpIFN0ZWZhbm8sDQo+Pg0KPj4gVGhhbmtzIGFnYWluIGZv ciB0aGUgcHJvbXB0IHJlc3BvbnNlLg0KPj4NCj4+PiAyLiB0aGUgU1JIIGlzIG9yaWdpbmF0ZWQg YnkgdGhlIGluZ3Jlc3Mgbm9kZSBvZiB0aGUgU1IgZG9tYWluLg0KPj4+ICBUaGlzIGlzIGRvbmUg YnkgZW5jYXBzdWxhdGluZyB0aGUgcGFja2V0IGludG8gYSBvdXRlcg0KPj4+ICAoYWRkaXRpb25h bCkgaXB2NiBoZWFkZXIgZm9sbG93ZWQgYnkgYW4gU1JILiBUaGlzIGlzIEwzDQo+Pj4gZW5jYXBz dWxhdGlvbiBhbmQgbm8gTDQgY2hlY2tzdW0gaXMgaW52b2x2ZWQuIFdoZW4gdGhlICBwYWNrZXQg bGVhdmVzDQo+Pj4gdGhlIFNSIHR1bm5lbCB0aGUgb3V0ZXIgZW5jYXBzdWxhdGlvbiAgKGluY2x1 ZGluZyB0aGUgU1JIKSBpcyByZW1vdmVkDQo+Pj4gYW5kIHRoZSBwYWNrZXQgY29udGludWVzICBp dHMgam91cm5leSBsaWtlIG5vdGhpbmcgaGFwcGVuZWQuDQo+Pg0KPj4gU28gVlhMQU4gaXMgb2Zm IHRoZSB0YWJsZT8NCj4NCj4NCj5pdOKAmXMgYWxsIGFib3V0IElQLCBub3QgbGF5ZXItMi4NCj4N Cj5zLg0KPg0KPg0KPj4gSXQgd291bGQgYmUgd29ydGh3aGlsZSB0byBjbGFyaWZ5IHRoaXMgaW4g dGhlIGRyYWZ0LiBJZiB5b3UgaGF2ZSBhIHNwZWNpZmljDQo+ZW5jYXBzdWxhdGlvbiBpbiBtaW5k LCBpdCB3b3VsZCBiZSBncmVhdCBpZiB0aGUgZHJhZnQgd291bGQgc3BlY2lmeSBpdC4NCj4+DQo+ PiBUaGFua3MsDQo+PiBUYWwuDQo+Pg0KPj4NCj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPj4+IEZyb206IFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpIFttYWlsdG86c3ByZXZpZGlA Y2lzY28uY29tXQ0KPj4+IFNlbnQ6IE1vbmRheSwgTWF5IDE2LCAyMDE2IDI6MTMgUE0NCj4+PiBU bzogVGFsIE1penJhaGkNCj4+PiBDYzogT2xlIFRyw7hhbjsgZHJhZnQtaWV0Zi02bWFuLXNlZ21l bnQtcm91dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmc7DQo+Pj4gc3ByaW5nQGlldGYub3JnOyA2 bWFuIFdHDQo+Pj4gU3ViamVjdDogUmU6IFtzcHJpbmddIEw0IENoZWNrc3VtIGFuZA0KPj4+IGRy YWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctIGhlYWRlcg0KPj4+DQo+Pj4gSGksDQo+Pj4N Cj4+PiBPbiBNYXkgMTYsIDIwMTYsIGF0IDExOjA0IEFNLCBUYWwgTWl6cmFoaSA8dGFsbWlAbWFy dmVsbC5jb20+IHdyb3RlOg0KPj4+Pg0KPj4+PiBIaSBTdGVmYW5vLA0KPj4+Pg0KPj4+PiBUaGFu a3MgZm9yIHRoZSByZXNwb25zZXMuDQo+Pj4+DQo+Pj4+PiBleGFjdGx5Lg0KPj4+Pj4NCj4+Pj4+ IE1vcmVvdmVyLCBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlciBhc3N1bWVz DQo+Pj4+PiBlbmNhcHN1bGF0aW9uIHNvIGNsZWFybHkgdGhlcmXigJlzIG5vIEw0IGludm9sdmVk IGhlcmUuDQo+Pj4+Pg0KPj4+Pj4gcy4NCj4+Pj4NCj4+Pj4gVHdvIHF1ZXN0aW9uczoNCj4+Pj4g MS4gV2hhdCBpZiB0aGUgZW5jYXBzdWxhdGlvbiBpcyBWWExBTj8gTDQgd291bGQgc3RpbGwgYmUg aW52b2x2ZWQsIHJpZ2h0Pw0KPj4+DQo+Pj4NCj4+PiBTZWUgYmVsb3cuDQo+Pj4NCj4+Pg0KPj4+ PiAyLiBXaGVuIHlvdSBzYXkgJ2Fzc3VtZXMgZW5jYXBzdWxhdGlvbicsIGRvZXMgaXQgbWVhbiB0 aGF0IGEgaG9zdA0KPj4+PiBjYW5ub3QNCj4+PiBzZW5kIGFuIElQdjYgcGFja2V0IHdpdGggYW4g U1JIPyBUaGUgY3VycmVudCBkcmFmdCBzYXlzOg0KPj4+Pg0KPj4+PiAgQSBTb3VyY2UgU1IgTm9k ZSBjYW4gYmUgYW55IG5vZGUgb3JpZ2luYXRpbmcgYW4gSVB2NiBwYWNrZXQgd2l0aA0KPj4+PiBp dHMNCj4+Pj4gIElQdjYgYW5kIFNlZ21lbnQgUm91dGluZyBIZWFkZXJzLiAgVGhpcyBpbmNsdWRl IGVpdGhlcjoNCj4+Pj4NCj4+Pj4gICAgIEEgaG9zdCBvcmlnaW5hdGluZyBhbiBJUHY2IHBhY2tl dC4NCj4+Pj4NCj4+Pj4gICAgIEFuIFNSIGRvbWFpbiBpbmdyZXNzIHJvdXRlciBlbmNhcHN1bGF0 aW5nIGEgcmVjZWl2ZWQgSVB2NiBwYWNrZXQNCj4+Pj4gICAgIGludG8gYW4gb3V0ZXIgSVB2NiBo ZWFkZXIgZm9sbG93ZWQgYnkgYW4gU1JILg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBXaWxsIGFw cHJlY2lhdGUgaWYgeW91IGNhbiBjbGFyaWZ5IHRoYXQuDQo+Pj4NCj4+Pg0KPj4+IG9rLCB0d28g Y2FzZXM6DQo+Pj4NCj4+PiAxLiB0aGUgU1JIIGlzIGluc2VydGVkIGF0IHRoZSBzb3VyY2UuDQo+ Pj4gIHRoZSBzb3VyY2Ugb3JpZ2luYXRlcyB0aGUgcGFja2V0LCB0aGUgaXB2NiBoZWFkZXIgYW5k ICB0aGUgU1JILiBUaGUNCj4+PiBzb3VyY2UgY29tcHV0ZXMgTDQgY2hlY2tzdW0gdGFraW5nIGlu dG8gIGFjY291bnQgdGhlIHdob2xlIElQdjYrU1JILg0KPj4+IEhlcmUsIHRoZXJlc+KAmSBub3Ro aW5nIG5ldyAgY29tcGFyZWQgdG8gcmZjMjQ2MC4NCj4+Pg0KPj4+IDIuIHRoZSBTUkggaXMgb3Jp Z2luYXRlZCBieSB0aGUgaW5ncmVzcyBub2RlIG9mIHRoZSBTUiBkb21haW4uDQo+Pj4gIFRoaXMg aXMgZG9uZSBieSBlbmNhcHN1bGF0aW5nIHRoZSBwYWNrZXQgaW50byBhIG91dGVyDQo+Pj4gIChh ZGRpdGlvbmFsKSBpcHY2IGhlYWRlciBmb2xsb3dlZCBieSBhbiBTUkguIFRoaXMgaXMgTDMNCj4+ PiBlbmNhcHN1bGF0aW9uIGFuZCBubyBMNCBjaGVja3N1bSBpcyBpbnZvbHZlZC4gV2hlbiB0aGUg IHBhY2tldCBsZWF2ZXMNCj4+PiB0aGUgU1IgdHVubmVsIHRoZSBvdXRlciBlbmNhcHN1bGF0aW9u ICAoaW5jbHVkaW5nIHRoZSBTUkgpIGlzIHJlbW92ZWQNCj4+PiBhbmQgdGhlIHBhY2tldCBjb250 aW51ZXMgIGl0cyBqb3VybmV5IGxpa2Ugbm90aGluZyBoYXBwZW5lZC4NCj4+Pg0KPj4+IHMuDQo+ Pj4NCj4+Pg0KPj4+Pg0KPj4+PiBUaGFua3MsDQo+Pj4+IFRhbC4NCj4+Pj4NCj4+Pj4+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBTdGVmYW5vIFByZXZpZGkgKHNwcmV2 aWRpKSBbbWFpbHRvOnNwcmV2aWRpQGNpc2NvLmNvbV0NCj4+Pj4+IFNlbnQ6IE1vbmRheSwgTWF5 IDE2LCAyMDE2IDExOjU5IEFNDQo+Pj4+PiBUbzogT2xlIFRyw7hhbjsgVGFsIE1penJhaGkNCj4+ Pj4+IENjOiBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlckB0b29scy5pZXRm Lm9yZzsNCj4+Pj4+IHNwcmluZ0BpZXRmLm9yZzsgNm1hbiBXRw0KPj4+Pj4gU3ViamVjdDogUmU6 IFtzcHJpbmddIEw0IENoZWNrc3VtIGFuZA0KPj4+Pj4gZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQt cm91dGluZy0gaGVhZGVyDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+PiBPbiBNYXkgMTUsIDIwMTYsIGF0 IDg6MDYgUE0sIG90cm9hbkBlbXBsb3llZXMub3JnIHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4gVGFs LA0KPj4+Pj4+DQo+Pj4+Pj4+IFtBcG9sb2dpZXMgaWYgdGhpcyBpc3N1ZSBoYXMgYmVlbiBkaXNj dXNzZWQgYmVmb3JlLl0NCj4+Pj4+Pj4NCj4+Pj4+Pj4gQWNjb3JkaW5nIHRvIGRyYWZ0LWlldGYt Nm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyLCBhbiDigJhTUg0KPj4+Pj4+PiBTZWdtZW50DQo+ Pj4+PiBFbmRwb2ludCBOb2Rl4oCZIHVwZGF0ZXMgdGhlIERlc3RpbmF0aW9uIElQIGFkZHJlc3Mu DQo+Pj4+Pj4+IFRoZXJlZm9yZSwgaXQgbXVzdCBhbHNvIHVwZGF0ZSB0aGUgTGF5ZXIgNCBDaGVj a3N1bSwgcmlnaHQ/DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEkgd29uZGVyIGlmIHRoZXJlIGlzIGFuIHVw cGVyIGJvdW5kIG9uIHRoZSBzaXplIG9mIHRoZSBTUkguDQo+Pj4+Pj4+IE90aGVyd2lzZSwgdGhl DQo+Pj4+PiBMNCBDaGVja3N1bSBtYXkgYmUgbG9jYXRlZCBpbiBhIHByZXR0eSBkZWVwIGxvY2F0 aW9uLg0KPj4+Pj4+PiBTcGVha2luZyBmcm9tIGEgY2hpcCB2ZW5kb3LigJlzIHBlcnNwZWN0aXZl IHRoaXMgbWF5IGJlIGEgcHJvYmxlbS4NCj4+Pj4+Pg0KPj4+Pj4+IEZyb20gUkZDMjQ2MCwgUkgw Og0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiAgICBvICBJZiB0aGUgSVB2NiBwYWNrZXQgY29udGFp bnMgYSBSb3V0aW5nIGhlYWRlciwgdGhlIERlc3RpbmF0aW9uDQo+Pj4+Pj4gICAgICAgQWRkcmVz cyB1c2VkIGluIHRoZSBwc2V1ZG8taGVhZGVyIGlzIHRoYXQgb2YgdGhlIGZpbmFsDQo+Pj4+Pj4g ICAgICAgZGVzdGluYXRpb24uICBBdCB0aGUgb3JpZ2luYXRpbmcgbm9kZSwgdGhhdCBhZGRyZXNz IHdpbGwgYmUgaW4NCj4+Pj4+PiAgICAgICB0aGUgbGFzdCBlbGVtZW50IG9mIHRoZSBSb3V0aW5n IGhlYWRlcjsgYXQgdGhlIHJlY2lwaWVudChzKSwNCj4+Pj4+PiAgICAgICB0aGF0IGFkZHJlc3Mg d2lsbCBiZSBpbiB0aGUgRGVzdGluYXRpb24gQWRkcmVzcyBmaWVsZCBvZiB0aGUNCj4+Pj4+PiAg ICAgICBJUHY2IGhlYWRlci4NCj4+Pj4+Pg0KPj4+Pj4+IEkgd291bGQgZXhwZWN0IFNSIHdvdWxk IHdvcmsgdGhlIHNhbWUuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IGV4YWN0bHkuDQo+Pj4+Pg0KPj4+ Pj4gTW9yZW92ZXIsIGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyIGFzc3Vt ZXMNCj4+Pj4+IGVuY2Fwc3VsYXRpb24gc28gY2xlYXJseSB0aGVyZeKAmXMgbm8gTDQgaW52b2x2 ZWQgaGVyZS4NCj4+Pj4+DQo+Pj4+PiBzLg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+PiBD aGVlcnMsDQo+Pj4+Pj4gT2xlDQo+Pj4+Pj4NCj4+Pj4NCj4+DQoNCg== From nobody Mon May 16 10:10:08 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A5212D808 for ; Mon, 16 May 2016 10:10:06 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7MIom6nI1Ip for ; Mon, 16 May 2016 10:10:05 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::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 CE70C12D805 for ; Mon, 16 May 2016 10:10:04 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id i75so212477779ioa.3 for ; Mon, 16 May 2016 10:10:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=xwuMD+np3FVbrp3l1WmZQ0xoky7QCFAh5pwGFBvtGRM=; b=SF2wFEgQKVzb8Y4sdlG0CbOp8y67h3uvkc/efX/j9l4ePvYpnD96nLNXNY2vbPSi37 Op3hpMNe2n7N9/uZFulxh5vl421gR+TzPKDcEVsguxu7NS2d7AxegG7lBQzD9F1oy24J 6aATdS5WkGegdIzCVhMAA4bUgCJ/d00Gbn+/0uutXfpxHT1yBsSSsvp1peqdhDWdqfc8 5VCGx+J0N97JJ6AUj9Rlo6SZriQvV9vbPiF8LfbcwEyNWyDIodLcG6eZ33Vvz3LkepxG 9Rqfsls9p/2z1DKK4jrJcaHt90csBcr/we6x5NeNfPwBzj7W2mjTXdCjyoHF+EJX+9qZ uBeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=xwuMD+np3FVbrp3l1WmZQ0xoky7QCFAh5pwGFBvtGRM=; b=Ks6C7NrMbxHLbUpJDejK3udSKBisJEDyiMYGEStuW+UBAdFjlnJu+avTQn0iLUHFHH BfqVxE5gvfLEHRzlwxPdtEyvQE601W2NoPVgai+CnNOpEWqna3ignfLcthWA1paJQo/i g4Cf4XTsn18uFypQkf8GgKaveCUgiJhjyiHjqZ8Ros8A/1m5G+kyVE5tJB/fXFBz8AbN VBMfC96KiXqkhjspGt+/tqknxzEsfDQBgbnjFKRZEKlRg9jSkeJX8iDx4uReTbcaw1t/ hYKW+Ben2gvgKIt7xlcesWrjLqDdAEFL7J0tVOKrzcWYykUV/bMiI4uEEKf6Mt/QmkmJ qLnQ== X-Gm-Message-State: AOPr4FUQrqqg0fVSHFF2O3N9/PbRc+YAwI2nksXcBtytl7LAErw7UreA2ohLMGa9M6xZx5G5Tifey5tQg+bXqg== MIME-Version: 1.0 X-Received: by 10.36.110.143 with SMTP id w137mr10638294itc.37.1463418604053; Mon, 16 May 2016 10:10:04 -0700 (PDT) Received: by 10.107.56.67 with HTTP; Mon, 16 May 2016 10:10:03 -0700 (PDT) In-Reply-To: <5d889e7013b44b27ae1e75cf7ea2dd22@IL-EXCH02.marvell.com> References: <5dc56935eba94c2390120244564f9b21@IL-EXCH02.marvell.com> <0551686F-F1D2-4C34-81C8-530F1BEE1BDF@cisco.com> <5d889e7013b44b27ae1e75cf7ea2dd22@IL-EXCH02.marvell.com> Date: Mon, 16 May 2016 10:10:03 -0700 Message-ID: From: Tom Herbert To: Tal Mizrahi Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "spring@ietf.org" , 6man WG , "draft-ietf-6man-segment-routing-header@tools.ietf.org" , "Stefano Previdi \(sprevidi\)" Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 May 2016 17:10:07 -0000 On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi wrote: >>it=E2=80=99s all about IP, not layer-2. >> >>s. > > Right. However, it appears that at least in some cases a VXLAN VTEP will = use SR. It certainly may be the case in SFC use cases (see Section 2.3 in d= raft-ietf-spring-ipv6-use-cases). > draft-ietf-6man-segment-routing-header mentions that the packet is encapsulated, but I don't think it is explicit as to exact encapsulation format (I suppose simple ip6ip6 is implied). But, it seems like any of several encapsulation techniques could work (VXLAN, GRE/IP, ESP/IP, GUE, foo over UDP, etc.) and if a device that wants to do SR is already doing tunneling it seems reasonable to me to only have one layer of encapsulation. Maybe this should be clarified in the draft? Tom > > >>-----Original Message----- >>From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >>Sent: Monday, May 16, 2016 2:24 PM >>To: Tal Mizrahi >>Cc: Ole Tr=C3=B8an; draft-ietf-6man-segment-routing-header@tools.ietf.org= ; >>spring@ietf.org; 6man WG >>Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing- >>header >> >> >>> On May 16, 2016, at 1:19 PM, Tal Mizrahi wrote: >>> >>> Hi Stefano, >>> >>> Thanks again for the prompt response. >>> >>>> 2. the SRH is originated by the ingress node of the SR domain. >>>> This is done by encapsulating the packet into a outer >>>> (additional) ipv6 header followed by an SRH. This is L3 >>>> encapsulation and no L4 checksum is involved. When the packet leaves >>>> the SR tunnel the outer encapsulation (including the SRH) is removed >>>> and the packet continues its journey like nothing happened. >>> >>> So VXLAN is off the table? >> >> >>it=E2=80=99s all about IP, not layer-2. >> >>s. >> >> >>> It would be worthwhile to clarify this in the draft. If you have a spec= ific >>encapsulation in mind, it would be great if the draft would specify it. >>> >>> Thanks, >>> Tal. >>> >>> >>>> -----Original Message----- >>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >>>> Sent: Monday, May 16, 2016 2:13 PM >>>> To: Tal Mizrahi >>>> Cc: Ole Tr=C3=B8an; draft-ietf-6man-segment-routing-header@tools.ietf.= org; >>>> spring@ietf.org; 6man WG >>>> Subject: Re: [spring] L4 Checksum and >>>> draft-ietf-6man-segment-routing- header >>>> >>>> Hi, >>>> >>>> On May 16, 2016, at 11:04 AM, Tal Mizrahi wrote: >>>>> >>>>> Hi Stefano, >>>>> >>>>> Thanks for the responses. >>>>> >>>>>> exactly. >>>>>> >>>>>> Moreover, draft-ietf-6man-segment-routing-header assumes >>>>>> encapsulation so clearly there=E2=80=99s no L4 involved here. >>>>>> >>>>>> s. >>>>> >>>>> Two questions: >>>>> 1. What if the encapsulation is VXLAN? L4 would still be involved, ri= ght? >>>> >>>> >>>> See below. >>>> >>>> >>>>> 2. When you say 'assumes encapsulation', does it mean that a host >>>>> cannot >>>> send an IPv6 packet with an SRH? The current draft says: >>>>> >>>>> A Source SR Node can be any node originating an IPv6 packet with >>>>> its >>>>> IPv6 and Segment Routing Headers. This include either: >>>>> >>>>> A host originating an IPv6 packet. >>>>> >>>>> An SR domain ingress router encapsulating a received IPv6 packet >>>>> into an outer IPv6 header followed by an SRH. >>>>> >>>>> >>>>> >>>>> Will appreciate if you can clarify that. >>>> >>>> >>>> ok, two cases: >>>> >>>> 1. the SRH is inserted at the source. >>>> the source originates the packet, the ipv6 header and the SRH. The >>>> source computes L4 checksum taking into account the whole IPv6+SRH. >>>> Here, theres=E2=80=99 nothing new compared to rfc2460. >>>> >>>> 2. the SRH is originated by the ingress node of the SR domain. >>>> This is done by encapsulating the packet into a outer >>>> (additional) ipv6 header followed by an SRH. This is L3 >>>> encapsulation and no L4 checksum is involved. When the packet leaves >>>> the SR tunnel the outer encapsulation (including the SRH) is removed >>>> and the packet continues its journey like nothing happened. >>>> >>>> s. >>>> >>>> >>>>> >>>>> Thanks, >>>>> Tal. >>>>> >>>>>> -----Original Message----- >>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >>>>>> Sent: Monday, May 16, 2016 11:59 AM >>>>>> To: Ole Tr=C3=B8an; Tal Mizrahi >>>>>> Cc: draft-ietf-6man-segment-routing-header@tools.ietf.org; >>>>>> spring@ietf.org; 6man WG >>>>>> Subject: Re: [spring] L4 Checksum and >>>>>> draft-ietf-6man-segment-routing- header >>>>>> >>>>>> >>>>>>> On May 15, 2016, at 8:06 PM, otroan@employees.org wrote: >>>>>>> >>>>>>> Tal, >>>>>>> >>>>>>>> [Apologies if this issue has been discussed before.] >>>>>>>> >>>>>>>> According to draft-ietf-6man-segment-routing-header, an =E2=80=98S= R >>>>>>>> Segment >>>>>> Endpoint Node=E2=80=99 updates the Destination IP address. >>>>>>>> Therefore, it must also update the Layer 4 Checksum, right? >>>>>>>> >>>>>>>> I wonder if there is an upper bound on the size of the SRH. >>>>>>>> Otherwise, the >>>>>> L4 Checksum may be located in a pretty deep location. >>>>>>>> Speaking from a chip vendor=E2=80=99s perspective this may be a pr= oblem. >>>>>>> >>>>>>> From RFC2460, RH0: >>>>>>> >>>>>>> >>>>>>> o If the IPv6 packet contains a Routing header, the Destination >>>>>>> Address used in the pseudo-header is that of the final >>>>>>> destination. At the originating node, that address will be i= n >>>>>>> the last element of the Routing header; at the recipient(s), >>>>>>> that address will be in the Destination Address field of the >>>>>>> IPv6 header. >>>>>>> >>>>>>> I would expect SR would work the same. >>>>>> >>>>>> >>>>>> exactly. >>>>>> >>>>>> Moreover, draft-ietf-6man-segment-routing-header assumes >>>>>> encapsulation so clearly there=E2=80=99s no L4 involved here. >>>>>> >>>>>> s. >>>>>> >>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> Ole >>>>>>> >>>>> >>> > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From nobody Tue May 17 00:41:08 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E964112D59B; Tue, 17 May 2016 00:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NQnQhamWxy5e; Tue, 17 May 2016 00:41:05 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1912F12D589; Tue, 17 May 2016 00:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9590; q=dns/txt; s=iport; t=1463470865; x=1464680465; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=6TjoHVIqnWQz3ISn+OUC6ZbrLQ4ARgP7GpIhwhqauTQ=; b=T53llUUjvD8bl31JCQLKjqSR2wQ8kFvinoMfluWte2NvggPugE9957G9 ibHDED9zrVrUzq+eGdKo74GF7PuSkfiPFWJfUVXzlomjl28Ga9cCJFgju h361QUt0BBaCe4ZZ9oxAHROxnLcxQHijPO9c40vaw+xRU6NLkxD9limZ6 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BkAgC3yTpX/5BdJa1dgzdVfga5agENg?= =?us-ascii?q?XYXC4VvAhyBFjgUAQEBAQEBAWUnhEIBAQEDAQEBASAROgsFBwQCAQgRBAEBAQI?= =?us-ascii?q?CERIDAgICJQsUAQgIAgQOBYgnCA6xCZFxAQEBAQEBAQEBAQEBAQEBAQEBAQEBF?= =?us-ascii?q?wWBAYUkgXYIgk+EViiCQSuCLgWHfpAqAY4dgWmNMIYtiRMBHgEBQoNsboZIBzh?= =?us-ascii?q?/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,324,1459814400"; d="scan'208";a="108797071" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 May 2016 07:41:04 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u4H7f3NE032017 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 17 May 2016 07:41:03 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 17 May 2016 03:41:03 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Tue, 17 May 2016 03:41:03 -0400 From: "Stefano Previdi (sprevidi)" To: Tom Herbert Thread-Topic: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header Thread-Index: AdGuiiq1HeAHjjuQREGOx9vVjNXiwQAa+DiAAB8pfIAAAC4LAAAEgrGAAAA7KQAAACaYgAAAScIAAAvLbYAAHmtYgA== Date: Tue, 17 May 2016 07:41:02 +0000 Message-ID: <3549ABBE-9828-42D2-A056-851432487E2E@cisco.com> References: <5dc56935eba94c2390120244564f9b21@IL-EXCH02.marvell.com> <0551686F-F1D2-4C34-81C8-530F1BEE1BDF@cisco.com> <5d889e7013b44b27ae1e75cf7ea2dd22@IL-EXCH02.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.80.155] Content-Type: text/plain; charset="utf-8" Content-ID: <04F7E1B83AEA4546B7C3E96661CB11BF@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , 6man WG , "draft-ietf-6man-segment-routing-header@tools.ietf.org" , Tal Mizrahi Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 07:41:07 -0000 DQo+IE9uIE1heSAxNiwgMjAxNiwgYXQgNzoxMCBQTSwgVG9tIEhlcmJlcnQgPHRvbUBoZXJiZXJ0 bGFuZC5jb20+IHdyb3RlOg0KPiANCj4gT24gTW9uLCBNYXkgMTYsIDIwMTYgYXQgNDozMiBBTSwg VGFsIE1penJhaGkgPHRhbG1pQG1hcnZlbGwuY29tPiB3cm90ZToNCj4+PiBpdOKAmXMgYWxsIGFi b3V0IElQLCBub3QgbGF5ZXItMi4NCj4+PiANCj4+PiBzLg0KPj4gDQo+PiBSaWdodC4gSG93ZXZl ciwgaXQgYXBwZWFycyB0aGF0IGF0IGxlYXN0IGluIHNvbWUgY2FzZXMgYSBWWExBTiBWVEVQIHdp bGwgdXNlIFNSLiBJdCBjZXJ0YWlubHkgbWF5IGJlIHRoZSBjYXNlIGluIFNGQyB1c2UgY2FzZXMg KHNlZSBTZWN0aW9uIDIuMyBpbiBkcmFmdC1pZXRmLXNwcmluZy1pcHY2LXVzZS1jYXNlcykuDQo+ PiANCj4gDQo+IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyIG1lbnRpb25z IHRoYXQgdGhlIHBhY2tldCBpcw0KPiBlbmNhcHN1bGF0ZWQNCg0KDQppbnRvIGFuIG91dGVyIGlw djYgaGVhZGVyIHdoaWNoIG1ha2VzIGl0IGEgbGF5ZXItMyBlbmNhcC4NCg0KDQo+ICwgYnV0IEkg ZG9uJ3QgdGhpbmsgaXQgaXMgZXhwbGljaXQgYXMgdG8gZXhhY3QNCj4gZW5jYXBzdWxhdGlvbiBm b3JtYXQgKEkgc3VwcG9zZSBzaW1wbGUgaXA2aXA2IGlzIGltcGxpZWQpLg0KDQoNCnNlZSBzZWN0 aW9uIDIuMg0KDQoNCj4gQnV0LCBpdA0KPiBzZWVtcyBsaWtlIGFueSBvZiBzZXZlcmFsIGVuY2Fw c3VsYXRpb24gdGVjaG5pcXVlcyBjb3VsZCB3b3JrIChWWExBTiwNCg0KDQpJIGhhdmUgc29tZSBw cm9ibGVtcyB0byB1bmRlcnN0YW5kIHdoZXJlIHRvIGZpdCBhbiBleHRlbnNpb24gaGVhZGVyIGlu dG8gYSB2eGxhbiBlbmNhcOKApg0KDQoNCj4gR1JFL0lQLCBFU1AvSVAsIEdVRSwgZm9vIG92ZXIg VURQLCBldGMuKSBhbmQgaWYgYSBkZXZpY2UgdGhhdCB3YW50cyB0bw0KPiBkbyBTUiBpcyBhbHJl YWR5IGRvaW5nIHR1bm5lbGluZyBpdCBzZWVtcyByZWFzb25hYmxlIHRvIG1lIHRvIG9ubHkNCj4g aGF2ZSBvbmUgbGF5ZXIgb2YgZW5jYXBzdWxhdGlvbi4gTWF5YmUgdGhpcyBzaG91bGQgYmUgY2xh cmlmaWVkIGluIHRoZQ0KPiBkcmFmdD8NCg0KDQp0aGUgZHJhZnQgaXMgYWJvdXQgSVB2NiBleHRl bnNpb24gaGVhZGVyIGFuZCBtb3JlIHByZWNpc2VseSBhIG5ldyB0eXBlIG9mIHRoZSByb3V0aW5n IGV4dGVuc2lvbiBoZWFkZXIgZGVmaW5lZCBpbiByZmMyNDYwLiBUaGF04oCZcyB0aGUgY29udGV4 dC4NCg0KDQpzLg0KDQoNCg0KDQo+IA0KPiBUb20NCj4gDQo+PiANCj4+IA0KPj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4gRnJvbTogU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkg W21haWx0bzpzcHJldmlkaUBjaXNjby5jb21dDQo+Pj4gU2VudDogTW9uZGF5LCBNYXkgMTYsIDIw MTYgMjoyNCBQTQ0KPj4+IFRvOiBUYWwgTWl6cmFoaQ0KPj4+IENjOiBPbGUgVHLDuGFuOyBkcmFm dC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlckB0b29scy5pZXRmLm9yZzsNCj4+PiBz cHJpbmdAaWV0Zi5vcmc7IDZtYW4gV0cNCj4+PiBTdWJqZWN0OiBSZTogW3NwcmluZ10gTDQgQ2hl Y2tzdW0gYW5kIGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctDQo+Pj4gaGVhZGVyDQo+ Pj4gDQo+Pj4gDQo+Pj4+IE9uIE1heSAxNiwgMjAxNiwgYXQgMToxOSBQTSwgVGFsIE1penJhaGkg PHRhbG1pQG1hcnZlbGwuY29tPiB3cm90ZToNCj4+Pj4gDQo+Pj4+IEhpIFN0ZWZhbm8sDQo+Pj4+ IA0KPj4+PiBUaGFua3MgYWdhaW4gZm9yIHRoZSBwcm9tcHQgcmVzcG9uc2UuDQo+Pj4+IA0KPj4+ Pj4gMi4gdGhlIFNSSCBpcyBvcmlnaW5hdGVkIGJ5IHRoZSBpbmdyZXNzIG5vZGUgb2YgdGhlIFNS IGRvbWFpbi4NCj4+Pj4+IFRoaXMgaXMgZG9uZSBieSBlbmNhcHN1bGF0aW5nIHRoZSBwYWNrZXQg aW50byBhIG91dGVyDQo+Pj4+PiAoYWRkaXRpb25hbCkgaXB2NiBoZWFkZXIgZm9sbG93ZWQgYnkg YW4gU1JILiBUaGlzIGlzIEwzDQo+Pj4+PiBlbmNhcHN1bGF0aW9uIGFuZCBubyBMNCBjaGVja3N1 bSBpcyBpbnZvbHZlZC4gV2hlbiB0aGUgIHBhY2tldCBsZWF2ZXMNCj4+Pj4+IHRoZSBTUiB0dW5u ZWwgdGhlIG91dGVyIGVuY2Fwc3VsYXRpb24gIChpbmNsdWRpbmcgdGhlIFNSSCkgaXMgcmVtb3Zl ZA0KPj4+Pj4gYW5kIHRoZSBwYWNrZXQgY29udGludWVzICBpdHMgam91cm5leSBsaWtlIG5vdGhp bmcgaGFwcGVuZWQuDQo+Pj4+IA0KPj4+PiBTbyBWWExBTiBpcyBvZmYgdGhlIHRhYmxlPw0KPj4+ IA0KPj4+IA0KPj4+IGl04oCZcyBhbGwgYWJvdXQgSVAsIG5vdCBsYXllci0yLg0KPj4+IA0KPj4+ IHMuDQo+Pj4gDQo+Pj4gDQo+Pj4+IEl0IHdvdWxkIGJlIHdvcnRod2hpbGUgdG8gY2xhcmlmeSB0 aGlzIGluIHRoZSBkcmFmdC4gSWYgeW91IGhhdmUgYSBzcGVjaWZpYw0KPj4+IGVuY2Fwc3VsYXRp b24gaW4gbWluZCwgaXQgd291bGQgYmUgZ3JlYXQgaWYgdGhlIGRyYWZ0IHdvdWxkIHNwZWNpZnkg aXQuDQo+Pj4+IA0KPj4+PiBUaGFua3MsDQo+Pj4+IFRhbC4NCj4+Pj4gDQo+Pj4+IA0KPj4+Pj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+IEZyb206IFN0ZWZhbm8gUHJldmlkaSAo c3ByZXZpZGkpIFttYWlsdG86c3ByZXZpZGlAY2lzY28uY29tXQ0KPj4+Pj4gU2VudDogTW9uZGF5 LCBNYXkgMTYsIDIwMTYgMjoxMyBQTQ0KPj4+Pj4gVG86IFRhbCBNaXpyYWhpDQo+Pj4+PiBDYzog T2xlIFRyw7hhbjsgZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXJAdG9vbHMu aWV0Zi5vcmc7DQo+Pj4+PiBzcHJpbmdAaWV0Zi5vcmc7IDZtYW4gV0cNCj4+Pj4+IFN1YmplY3Q6 IFJlOiBbc3ByaW5nXSBMNCBDaGVja3N1bSBhbmQNCj4+Pj4+IGRyYWZ0LWlldGYtNm1hbi1zZWdt ZW50LXJvdXRpbmctIGhlYWRlcg0KPj4+Pj4gDQo+Pj4+PiBIaSwNCj4+Pj4+IA0KPj4+Pj4gT24g TWF5IDE2LCAyMDE2LCBhdCAxMTowNCBBTSwgVGFsIE1penJhaGkgPHRhbG1pQG1hcnZlbGwuY29t PiB3cm90ZToNCj4+Pj4+PiANCj4+Pj4+PiBIaSBTdGVmYW5vLA0KPj4+Pj4+IA0KPj4+Pj4+IFRo YW5rcyBmb3IgdGhlIHJlc3BvbnNlcy4NCj4+Pj4+PiANCj4+Pj4+Pj4gZXhhY3RseS4NCj4+Pj4+ Pj4gDQo+Pj4+Pj4+IE1vcmVvdmVyLCBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhl YWRlciBhc3N1bWVzDQo+Pj4+Pj4+IGVuY2Fwc3VsYXRpb24gc28gY2xlYXJseSB0aGVyZeKAmXMg bm8gTDQgaW52b2x2ZWQgaGVyZS4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IHMuDQo+Pj4+Pj4gDQo+Pj4+ Pj4gVHdvIHF1ZXN0aW9uczoNCj4+Pj4+PiAxLiBXaGF0IGlmIHRoZSBlbmNhcHN1bGF0aW9uIGlz IFZYTEFOPyBMNCB3b3VsZCBzdGlsbCBiZSBpbnZvbHZlZCwgcmlnaHQ/DQo+Pj4+PiANCj4+Pj4+ IA0KPj4+Pj4gU2VlIGJlbG93Lg0KPj4+Pj4gDQo+Pj4+PiANCj4+Pj4+PiAyLiBXaGVuIHlvdSBz YXkgJ2Fzc3VtZXMgZW5jYXBzdWxhdGlvbicsIGRvZXMgaXQgbWVhbiB0aGF0IGEgaG9zdA0KPj4+ Pj4+IGNhbm5vdA0KPj4+Pj4gc2VuZCBhbiBJUHY2IHBhY2tldCB3aXRoIGFuIFNSSD8gVGhlIGN1 cnJlbnQgZHJhZnQgc2F5czoNCj4+Pj4+PiANCj4+Pj4+PiBBIFNvdXJjZSBTUiBOb2RlIGNhbiBi ZSBhbnkgbm9kZSBvcmlnaW5hdGluZyBhbiBJUHY2IHBhY2tldCB3aXRoDQo+Pj4+Pj4gaXRzDQo+ Pj4+Pj4gSVB2NiBhbmQgU2VnbWVudCBSb3V0aW5nIEhlYWRlcnMuICBUaGlzIGluY2x1ZGUgZWl0 aGVyOg0KPj4+Pj4+IA0KPj4+Pj4+ICAgIEEgaG9zdCBvcmlnaW5hdGluZyBhbiBJUHY2IHBhY2tl dC4NCj4+Pj4+PiANCj4+Pj4+PiAgICBBbiBTUiBkb21haW4gaW5ncmVzcyByb3V0ZXIgZW5jYXBz dWxhdGluZyBhIHJlY2VpdmVkIElQdjYgcGFja2V0DQo+Pj4+Pj4gICAgaW50byBhbiBvdXRlciBJ UHY2IGhlYWRlciBmb2xsb3dlZCBieSBhbiBTUkguDQo+Pj4+Pj4gDQo+Pj4+Pj4gDQo+Pj4+Pj4g DQo+Pj4+Pj4gV2lsbCBhcHByZWNpYXRlIGlmIHlvdSBjYW4gY2xhcmlmeSB0aGF0Lg0KPj4+Pj4g DQo+Pj4+PiANCj4+Pj4+IG9rLCB0d28gY2FzZXM6DQo+Pj4+PiANCj4+Pj4+IDEuIHRoZSBTUkgg aXMgaW5zZXJ0ZWQgYXQgdGhlIHNvdXJjZS4NCj4+Pj4+IHRoZSBzb3VyY2Ugb3JpZ2luYXRlcyB0 aGUgcGFja2V0LCB0aGUgaXB2NiBoZWFkZXIgYW5kICB0aGUgU1JILiBUaGUNCj4+Pj4+IHNvdXJj ZSBjb21wdXRlcyBMNCBjaGVja3N1bSB0YWtpbmcgaW50byAgYWNjb3VudCB0aGUgd2hvbGUgSVB2 NitTUkguDQo+Pj4+PiBIZXJlLCB0aGVyZXPigJkgbm90aGluZyBuZXcgIGNvbXBhcmVkIHRvIHJm YzI0NjAuDQo+Pj4+PiANCj4+Pj4+IDIuIHRoZSBTUkggaXMgb3JpZ2luYXRlZCBieSB0aGUgaW5n cmVzcyBub2RlIG9mIHRoZSBTUiBkb21haW4uDQo+Pj4+PiBUaGlzIGlzIGRvbmUgYnkgZW5jYXBz dWxhdGluZyB0aGUgcGFja2V0IGludG8gYSBvdXRlcg0KPj4+Pj4gKGFkZGl0aW9uYWwpIGlwdjYg aGVhZGVyIGZvbGxvd2VkIGJ5IGFuIFNSSC4gVGhpcyBpcyBMMw0KPj4+Pj4gZW5jYXBzdWxhdGlv biBhbmQgbm8gTDQgY2hlY2tzdW0gaXMgaW52b2x2ZWQuIFdoZW4gdGhlICBwYWNrZXQgbGVhdmVz DQo+Pj4+PiB0aGUgU1IgdHVubmVsIHRoZSBvdXRlciBlbmNhcHN1bGF0aW9uICAoaW5jbHVkaW5n IHRoZSBTUkgpIGlzIHJlbW92ZWQNCj4+Pj4+IGFuZCB0aGUgcGFja2V0IGNvbnRpbnVlcyAgaXRz IGpvdXJuZXkgbGlrZSBub3RoaW5nIGhhcHBlbmVkLg0KPj4+Pj4gDQo+Pj4+PiBzLg0KPj4+Pj4g DQo+Pj4+PiANCj4+Pj4+PiANCj4+Pj4+PiBUaGFua3MsDQo+Pj4+Pj4gVGFsLg0KPj4+Pj4+IA0K Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+PiBGcm9tOiBTdGVmYW5v IFByZXZpZGkgKHNwcmV2aWRpKSBbbWFpbHRvOnNwcmV2aWRpQGNpc2NvLmNvbV0NCj4+Pj4+Pj4g U2VudDogTW9uZGF5LCBNYXkgMTYsIDIwMTYgMTE6NTkgQU0NCj4+Pj4+Pj4gVG86IE9sZSBUcsO4 YW47IFRhbCBNaXpyYWhpDQo+Pj4+Pj4+IENjOiBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0 aW5nLWhlYWRlckB0b29scy5pZXRmLm9yZzsNCj4+Pj4+Pj4gc3ByaW5nQGlldGYub3JnOyA2bWFu IFdHDQo+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBMNCBDaGVja3N1bSBhbmQNCj4+Pj4+ Pj4gZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy0gaGVhZGVyDQo+Pj4+Pj4+IA0KPj4+ Pj4+PiANCj4+Pj4+Pj4+IE9uIE1heSAxNSwgMjAxNiwgYXQgODowNiBQTSwgb3Ryb2FuQGVtcGxv eWVlcy5vcmcgd3JvdGU6DQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IFRhbCwNCj4+Pj4+Pj4+IA0KPj4+ Pj4+Pj4+IFtBcG9sb2dpZXMgaWYgdGhpcyBpc3N1ZSBoYXMgYmVlbiBkaXNjdXNzZWQgYmVmb3Jl Ll0NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBBY2NvcmRpbmcgdG8gZHJhZnQtaWV0Zi02bWFuLXNl Z21lbnQtcm91dGluZy1oZWFkZXIsIGFuIOKAmFNSDQo+Pj4+Pj4+Pj4gU2VnbWVudA0KPj4+Pj4+ PiBFbmRwb2ludCBOb2Rl4oCZIHVwZGF0ZXMgdGhlIERlc3RpbmF0aW9uIElQIGFkZHJlc3MuDQo+ Pj4+Pj4+Pj4gVGhlcmVmb3JlLCBpdCBtdXN0IGFsc28gdXBkYXRlIHRoZSBMYXllciA0IENoZWNr c3VtLCByaWdodD8NCj4+Pj4+Pj4+PiANCj4+Pj4+Pj4+PiBJIHdvbmRlciBpZiB0aGVyZSBpcyBh biB1cHBlciBib3VuZCBvbiB0aGUgc2l6ZSBvZiB0aGUgU1JILg0KPj4+Pj4+Pj4+IE90aGVyd2lz ZSwgdGhlDQo+Pj4+Pj4+IEw0IENoZWNrc3VtIG1heSBiZSBsb2NhdGVkIGluIGEgcHJldHR5IGRl ZXAgbG9jYXRpb24uDQo+Pj4+Pj4+Pj4gU3BlYWtpbmcgZnJvbSBhIGNoaXAgdmVuZG9y4oCZcyBw ZXJzcGVjdGl2ZSB0aGlzIG1heSBiZSBhIHByb2JsZW0uDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+IEZy b20gUkZDMjQ2MCwgUkgwOg0KPj4+Pj4+Pj4gDQo+Pj4+Pj4+PiANCj4+Pj4+Pj4+ICAgbyAgSWYg dGhlIElQdjYgcGFja2V0IGNvbnRhaW5zIGEgUm91dGluZyBoZWFkZXIsIHRoZSBEZXN0aW5hdGlv bg0KPj4+Pj4+Pj4gICAgICBBZGRyZXNzIHVzZWQgaW4gdGhlIHBzZXVkby1oZWFkZXIgaXMgdGhh dCBvZiB0aGUgZmluYWwNCj4+Pj4+Pj4+ICAgICAgZGVzdGluYXRpb24uICBBdCB0aGUgb3JpZ2lu YXRpbmcgbm9kZSwgdGhhdCBhZGRyZXNzIHdpbGwgYmUgaW4NCj4+Pj4+Pj4+ICAgICAgdGhlIGxh c3QgZWxlbWVudCBvZiB0aGUgUm91dGluZyBoZWFkZXI7IGF0IHRoZSByZWNpcGllbnQocyksDQo+ Pj4+Pj4+PiAgICAgIHRoYXQgYWRkcmVzcyB3aWxsIGJlIGluIHRoZSBEZXN0aW5hdGlvbiBBZGRy ZXNzIGZpZWxkIG9mIHRoZQ0KPj4+Pj4+Pj4gICAgICBJUHY2IGhlYWRlci4NCj4+Pj4+Pj4+IA0K Pj4+Pj4+Pj4gSSB3b3VsZCBleHBlY3QgU1Igd291bGQgd29yayB0aGUgc2FtZS4NCj4+Pj4+Pj4g DQo+Pj4+Pj4+IA0KPj4+Pj4+PiBleGFjdGx5Lg0KPj4+Pj4+PiANCj4+Pj4+Pj4gTW9yZW92ZXIs IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyIGFzc3VtZXMNCj4+Pj4+Pj4g ZW5jYXBzdWxhdGlvbiBzbyBjbGVhcmx5IHRoZXJl4oCZcyBubyBMNCBpbnZvbHZlZCBoZXJlLg0K Pj4+Pj4+PiANCj4+Pj4+Pj4gcy4NCj4+Pj4+Pj4gDQo+Pj4+Pj4+IA0KPj4+Pj4+Pj4gDQo+Pj4+ Pj4+PiBDaGVlcnMsDQo+Pj4+Pj4+PiBPbGUNCj4+Pj4+Pj4+IA0KPj4+Pj4+IA0KPj4+PiANCj4+ IA0KPj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCj4+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlz dA0KPj4gaXB2NkBpZXRmLm9yZw0KPj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPj4gLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K From nobody Tue May 17 02:08:53 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E948412D0B2; Tue, 17 May 2016 02:08:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YeR8OVrA51Wj; Tue, 17 May 2016 02:08:39 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16F5C12B056; Tue, 17 May 2016 02:08:39 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u4H97J0I029093; Tue, 17 May 2016 02:08:36 -0700 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0a-0016f401.pphosted.com with ESMTP id 22xc8c963k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 17 May 2016 02:08:36 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 17 May 2016 12:08:32 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Tue, 17 May 2016 12:08:32 +0300 From: Tal Mizrahi To: "Stefano Previdi (sprevidi)" , Tom Herbert , "draft-ietf-nvo3-geneve@tools.ietf.org" , "draft-ietf-nvo3-vxlan-gpe@tools.ietf.org" Thread-Topic: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header Thread-Index: AdGuiiq1HeAHjjuQREGOx9vVjNXiwQAMTSCAAB8pyYAABk9dsP//8wwA///NLLCAADXfAP//zJ5wgACUC4CAAPNZAP//xdYw Date: Tue, 17 May 2016 09:08:32 +0000 Message-ID: <1e13d2e32b2448af94bf23d5acf17740@IL-EXCH02.marvell.com> References: <5dc56935eba94c2390120244564f9b21@IL-EXCH02.marvell.com> <0551686F-F1D2-4C34-81C8-530F1BEE1BDF@cisco.com> <5d889e7013b44b27ae1e75cf7ea2dd22@IL-EXCH02.marvell.com> <3549ABBE-9828-42D2-A056-851432487E2E@cisco.com> In-Reply-To: <3549ABBE-9828-42D2-A056-851432487E2E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-17_03:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1605170115 Archived-At: Cc: "spring@ietf.org" , "nvo3@ietf.org" , 6man WG , "draft-ietf-6man-segment-routing-header@tools.ietf.org" Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 09:08:47 -0000 U3RlZmFubywNCg0KSWYgSSB1bmRlcnN0YW5kIHlvdXIgcG9pbnQgY29ycmVjdGx5Og0KSVB2NiBz ZWdtZW50IHJvdXRpbmcgZG9lcyBub3Qgd29yayB3aXRoIFZYTEFOIC8gVlhMQU4tR1BFIC8gR2Vu ZXZlLCBzaW5jZSB0aGVzZSBlbmNhcHN1bGF0aW9ucyBkbyBub3QgY3VycmVudGx5IGFsbG93IHRo ZSB1c2Ugb2YgSVB2NiBleHRlbnNpb24gaGVhZGVycy4NCg0KSSB3b25kZXIgaWYgdGhlIGF1dGhv cnMgb2YgVlhMQU4tR1BFIGFuZCBHZW5ldmUgaGF2ZSBjb25zaWRlcmVkIHRoZSB1c2Ugb2Ygc2Vn bWVudCByb3V0aW5nLg0KDQpUaGFua3MsDQpUYWwuDQoNCg0KDQo+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj5Gcm9tOiBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKSBbbWFpbHRvOnNwcmV2 aWRpQGNpc2NvLmNvbV0NCj5TZW50OiBUdWVzZGF5LCBNYXkgMTcsIDIwMTYgMTA6NDEgQU0NCj5U bzogVG9tIEhlcmJlcnQNCj5DYzogVGFsIE1penJhaGk7IDZtYW4gV0c7IHNwcmluZ0BpZXRmLm9y ZzsgZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy0NCj5oZWFkZXJAdG9vbHMuaWV0Zi5v cmcNCj5TdWJqZWN0OiBSZTogW3NwcmluZ10gTDQgQ2hlY2tzdW0gYW5kIGRyYWZ0LWlldGYtNm1h bi1zZWdtZW50LXJvdXRpbmctDQo+aGVhZGVyDQo+DQo+DQo+PiBPbiBNYXkgMTYsIDIwMTYsIGF0 IDc6MTAgUE0sIFRvbSBIZXJiZXJ0IDx0b21AaGVyYmVydGxhbmQuY29tPiB3cm90ZToNCj4+DQo+ PiBPbiBNb24sIE1heSAxNiwgMjAxNiBhdCA0OjMyIEFNLCBUYWwgTWl6cmFoaSA8dGFsbWlAbWFy dmVsbC5jb20+DQo+d3JvdGU6DQo+Pj4+IGl04oCZcyBhbGwgYWJvdXQgSVAsIG5vdCBsYXllci0y Lg0KPj4+Pg0KPj4+PiBzLg0KPj4+DQo+Pj4gUmlnaHQuIEhvd2V2ZXIsIGl0IGFwcGVhcnMgdGhh dCBhdCBsZWFzdCBpbiBzb21lIGNhc2VzIGEgVlhMQU4gVlRFUCB3aWxsDQo+dXNlIFNSLiBJdCBj ZXJ0YWlubHkgbWF5IGJlIHRoZSBjYXNlIGluIFNGQyB1c2UgY2FzZXMgKHNlZSBTZWN0aW9uIDIu MyBpbiBkcmFmdC0NCj5pZXRmLXNwcmluZy1pcHY2LXVzZS1jYXNlcykuDQo+Pj4NCj4+DQo+PiBk cmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlciBtZW50aW9ucyB0aGF0IHRoZSBw YWNrZXQgaXMNCj4+IGVuY2Fwc3VsYXRlZA0KPg0KPg0KPmludG8gYW4gb3V0ZXIgaXB2NiBoZWFk ZXIgd2hpY2ggbWFrZXMgaXQgYSBsYXllci0zIGVuY2FwLg0KPg0KPg0KPj4gLCBidXQgSSBkb24n dCB0aGluayBpdCBpcyBleHBsaWNpdCBhcyB0byBleGFjdCBlbmNhcHN1bGF0aW9uIGZvcm1hdCAo SQ0KPj4gc3VwcG9zZSBzaW1wbGUgaXA2aXA2IGlzIGltcGxpZWQpLg0KPg0KPg0KPnNlZSBzZWN0 aW9uIDIuMg0KPg0KPg0KPj4gQnV0LCBpdA0KPj4gc2VlbXMgbGlrZSBhbnkgb2Ygc2V2ZXJhbCBl bmNhcHN1bGF0aW9uIHRlY2huaXF1ZXMgY291bGQgd29yayAoVlhMQU4sDQo+DQo+DQo+SSBoYXZl IHNvbWUgcHJvYmxlbXMgdG8gdW5kZXJzdGFuZCB3aGVyZSB0byBmaXQgYW4gZXh0ZW5zaW9uIGhl YWRlciBpbnRvIGENCj52eGxhbiBlbmNhcOKApg0KPg0KPg0KPj4gR1JFL0lQLCBFU1AvSVAsIEdV RSwgZm9vIG92ZXIgVURQLCBldGMuKSBhbmQgaWYgYSBkZXZpY2UgdGhhdCB3YW50cyB0bw0KPj4g ZG8gU1IgaXMgYWxyZWFkeSBkb2luZyB0dW5uZWxpbmcgaXQgc2VlbXMgcmVhc29uYWJsZSB0byBt ZSB0byBvbmx5DQo+PiBoYXZlIG9uZSBsYXllciBvZiBlbmNhcHN1bGF0aW9uLiBNYXliZSB0aGlz IHNob3VsZCBiZSBjbGFyaWZpZWQgaW4gdGhlDQo+PiBkcmFmdD8NCj4NCj4NCj50aGUgZHJhZnQg aXMgYWJvdXQgSVB2NiBleHRlbnNpb24gaGVhZGVyIGFuZCBtb3JlIHByZWNpc2VseSBhIG5ldyB0 eXBlIG9mIHRoZQ0KPnJvdXRpbmcgZXh0ZW5zaW9uIGhlYWRlciBkZWZpbmVkIGluIHJmYzI0NjAu IFRoYXTigJlzIHRoZSBjb250ZXh0Lg0KPg0KPg0KPnMuDQo+DQo+DQo+DQo+DQo+Pg0KPj4gVG9t DQo+Pg0KPj4+DQo+Pj4NCj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4gRnJv bTogU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkgW21haWx0bzpzcHJldmlkaUBjaXNjby5jb21d DQo+Pj4+IFNlbnQ6IE1vbmRheSwgTWF5IDE2LCAyMDE2IDI6MjQgUE0NCj4+Pj4gVG86IFRhbCBN aXpyYWhpDQo+Pj4+IENjOiBPbGUgVHLDuGFuOw0KPj4+PiBkcmFmdC1pZXRmLTZtYW4tc2VnbWVu dC1yb3V0aW5nLWhlYWRlckB0b29scy5pZXRmLm9yZzsNCj4+Pj4gc3ByaW5nQGlldGYub3JnOyA2 bWFuIFdHDQo+Pj4+IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBMNCBDaGVja3N1bSBhbmQNCj4+Pj4g ZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy0gaGVhZGVyDQo+Pj4+DQo+Pj4+DQo+Pj4+ PiBPbiBNYXkgMTYsIDIwMTYsIGF0IDE6MTkgUE0sIFRhbCBNaXpyYWhpIDx0YWxtaUBtYXJ2ZWxs LmNvbT4gd3JvdGU6DQo+Pj4+Pg0KPj4+Pj4gSGkgU3RlZmFubywNCj4+Pj4+DQo+Pj4+PiBUaGFu a3MgYWdhaW4gZm9yIHRoZSBwcm9tcHQgcmVzcG9uc2UuDQo+Pj4+Pg0KPj4+Pj4+IDIuIHRoZSBT UkggaXMgb3JpZ2luYXRlZCBieSB0aGUgaW5ncmVzcyBub2RlIG9mIHRoZSBTUiBkb21haW4uDQo+ Pj4+Pj4gVGhpcyBpcyBkb25lIGJ5IGVuY2Fwc3VsYXRpbmcgdGhlIHBhY2tldCBpbnRvIGEgb3V0 ZXINCj4+Pj4+PiAoYWRkaXRpb25hbCkgaXB2NiBoZWFkZXIgZm9sbG93ZWQgYnkgYW4gU1JILiBU aGlzIGlzIEwzDQo+Pj4+Pj4gZW5jYXBzdWxhdGlvbiBhbmQgbm8gTDQgY2hlY2tzdW0gaXMgaW52 b2x2ZWQuIFdoZW4gdGhlICBwYWNrZXQNCj4+Pj4+PiBsZWF2ZXMgdGhlIFNSIHR1bm5lbCB0aGUg b3V0ZXIgZW5jYXBzdWxhdGlvbiAgKGluY2x1ZGluZyB0aGUgU1JIKQ0KPj4+Pj4+IGlzIHJlbW92 ZWQgYW5kIHRoZSBwYWNrZXQgY29udGludWVzICBpdHMgam91cm5leSBsaWtlIG5vdGhpbmcgaGFw cGVuZWQuDQo+Pj4+Pg0KPj4+Pj4gU28gVlhMQU4gaXMgb2ZmIHRoZSB0YWJsZT8NCj4+Pj4NCj4+ Pj4NCj4+Pj4gaXTigJlzIGFsbCBhYm91dCBJUCwgbm90IGxheWVyLTIuDQo+Pj4+DQo+Pj4+IHMu DQo+Pj4+DQo+Pj4+DQo+Pj4+PiBJdCB3b3VsZCBiZSB3b3J0aHdoaWxlIHRvIGNsYXJpZnkgdGhp cyBpbiB0aGUgZHJhZnQuIElmIHlvdSBoYXZlIGENCj4+Pj4+IHNwZWNpZmljDQo+Pj4+IGVuY2Fw c3VsYXRpb24gaW4gbWluZCwgaXQgd291bGQgYmUgZ3JlYXQgaWYgdGhlIGRyYWZ0IHdvdWxkIHNw ZWNpZnkgaXQuDQo+Pj4+Pg0KPj4+Pj4gVGhhbmtzLA0KPj4+Pj4gVGFsLg0KPj4+Pj4NCj4+Pj4+ DQo+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+PiBGcm9tOiBTdGVmYW5v IFByZXZpZGkgKHNwcmV2aWRpKSBbbWFpbHRvOnNwcmV2aWRpQGNpc2NvLmNvbV0NCj4+Pj4+PiBT ZW50OiBNb25kYXksIE1heSAxNiwgMjAxNiAyOjEzIFBNDQo+Pj4+Pj4gVG86IFRhbCBNaXpyYWhp DQo+Pj4+Pj4gQ2M6IE9sZSBUcsO4YW47DQo+Pj4+Pj4gZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQt cm91dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmc7DQo+Pj4+Pj4gc3ByaW5nQGlldGYub3JnOyA2 bWFuIFdHDQo+Pj4+Pj4gU3ViamVjdDogUmU6IFtzcHJpbmddIEw0IENoZWNrc3VtIGFuZA0KPj4+ Pj4+IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctIGhlYWRlcg0KPj4+Pj4+DQo+Pj4+ Pj4gSGksDQo+Pj4+Pj4NCj4+Pj4+PiBPbiBNYXkgMTYsIDIwMTYsIGF0IDExOjA0IEFNLCBUYWwg TWl6cmFoaSA8dGFsbWlAbWFydmVsbC5jb20+DQo+d3JvdGU6DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEhp IFN0ZWZhbm8sDQo+Pj4+Pj4+DQo+Pj4+Pj4+IFRoYW5rcyBmb3IgdGhlIHJlc3BvbnNlcy4NCj4+ Pj4+Pj4NCj4+Pj4+Pj4+IGV4YWN0bHkuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gTW9yZW92ZXIsIGRy YWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyIGFzc3VtZXMNCj4+Pj4+Pj4+IGVu Y2Fwc3VsYXRpb24gc28gY2xlYXJseSB0aGVyZeKAmXMgbm8gTDQgaW52b2x2ZWQgaGVyZS4NCj4+ Pj4+Pj4+DQo+Pj4+Pj4+PiBzLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBUd28gcXVlc3Rpb25zOg0KPj4+ Pj4+PiAxLiBXaGF0IGlmIHRoZSBlbmNhcHN1bGF0aW9uIGlzIFZYTEFOPyBMNCB3b3VsZCBzdGls bCBiZSBpbnZvbHZlZCwNCj5yaWdodD8NCj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+Pj4gU2VlIGJlbG93 Lg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pj4gMi4gV2hlbiB5b3Ugc2F5ICdhc3N1bWVzIGVuY2Fw c3VsYXRpb24nLCBkb2VzIGl0IG1lYW4gdGhhdCBhIGhvc3QNCj4+Pj4+Pj4gY2Fubm90DQo+Pj4+ Pj4gc2VuZCBhbiBJUHY2IHBhY2tldCB3aXRoIGFuIFNSSD8gVGhlIGN1cnJlbnQgZHJhZnQgc2F5 czoNCj4+Pj4+Pj4NCj4+Pj4+Pj4gQSBTb3VyY2UgU1IgTm9kZSBjYW4gYmUgYW55IG5vZGUgb3Jp Z2luYXRpbmcgYW4gSVB2NiBwYWNrZXQgd2l0aA0KPj4+Pj4+PiBpdHMNCj4+Pj4+Pj4gSVB2NiBh bmQgU2VnbWVudCBSb3V0aW5nIEhlYWRlcnMuICBUaGlzIGluY2x1ZGUgZWl0aGVyOg0KPj4+Pj4+ Pg0KPj4+Pj4+PiAgICBBIGhvc3Qgb3JpZ2luYXRpbmcgYW4gSVB2NiBwYWNrZXQuDQo+Pj4+Pj4+ DQo+Pj4+Pj4+ICAgIEFuIFNSIGRvbWFpbiBpbmdyZXNzIHJvdXRlciBlbmNhcHN1bGF0aW5nIGEg cmVjZWl2ZWQgSVB2NiBwYWNrZXQNCj4+Pj4+Pj4gICAgaW50byBhbiBvdXRlciBJUHY2IGhlYWRl ciBmb2xsb3dlZCBieSBhbiBTUkguDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+ IFdpbGwgYXBwcmVjaWF0ZSBpZiB5b3UgY2FuIGNsYXJpZnkgdGhhdC4NCj4+Pj4+Pg0KPj4+Pj4+ DQo+Pj4+Pj4gb2ssIHR3byBjYXNlczoNCj4+Pj4+Pg0KPj4+Pj4+IDEuIHRoZSBTUkggaXMgaW5z ZXJ0ZWQgYXQgdGhlIHNvdXJjZS4NCj4+Pj4+PiB0aGUgc291cmNlIG9yaWdpbmF0ZXMgdGhlIHBh Y2tldCwgdGhlIGlwdjYgaGVhZGVyIGFuZCAgdGhlIFNSSC4NCj4+Pj4+PiBUaGUgc291cmNlIGNv bXB1dGVzIEw0IGNoZWNrc3VtIHRha2luZyBpbnRvICBhY2NvdW50IHRoZSB3aG9sZQ0KPklQdjYr U1JILg0KPj4+Pj4+IEhlcmUsIHRoZXJlc+KAmSBub3RoaW5nIG5ldyAgY29tcGFyZWQgdG8gcmZj MjQ2MC4NCj4+Pj4+Pg0KPj4+Pj4+IDIuIHRoZSBTUkggaXMgb3JpZ2luYXRlZCBieSB0aGUgaW5n cmVzcyBub2RlIG9mIHRoZSBTUiBkb21haW4uDQo+Pj4+Pj4gVGhpcyBpcyBkb25lIGJ5IGVuY2Fw c3VsYXRpbmcgdGhlIHBhY2tldCBpbnRvIGEgb3V0ZXINCj4+Pj4+PiAoYWRkaXRpb25hbCkgaXB2 NiBoZWFkZXIgZm9sbG93ZWQgYnkgYW4gU1JILiBUaGlzIGlzIEwzDQo+Pj4+Pj4gZW5jYXBzdWxh dGlvbiBhbmQgbm8gTDQgY2hlY2tzdW0gaXMgaW52b2x2ZWQuIFdoZW4gdGhlICBwYWNrZXQNCj4+ Pj4+PiBsZWF2ZXMgdGhlIFNSIHR1bm5lbCB0aGUgb3V0ZXIgZW5jYXBzdWxhdGlvbiAgKGluY2x1 ZGluZyB0aGUgU1JIKQ0KPj4+Pj4+IGlzIHJlbW92ZWQgYW5kIHRoZSBwYWNrZXQgY29udGludWVz ICBpdHMgam91cm5leSBsaWtlIG5vdGhpbmcgaGFwcGVuZWQuDQo+Pj4+Pj4NCj4+Pj4+PiBzLg0K Pj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+PiBUYWwuDQo+ Pj4+Pj4+DQo+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4gRnJv bTogU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkgW21haWx0bzpzcHJldmlkaUBjaXNjby5jb21d DQo+Pj4+Pj4+PiBTZW50OiBNb25kYXksIE1heSAxNiwgMjAxNiAxMTo1OSBBTQ0KPj4+Pj4+Pj4g VG86IE9sZSBUcsO4YW47IFRhbCBNaXpyYWhpDQo+Pj4+Pj4+PiBDYzogZHJhZnQtaWV0Zi02bWFu LXNlZ21lbnQtcm91dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmc7DQo+Pj4+Pj4+PiBzcHJpbmdA aWV0Zi5vcmc7IDZtYW4gV0cNCj4+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBMNCBDaGVj a3N1bSBhbmQNCj4+Pj4+Pj4+IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctIGhlYWRl cg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gT24gTWF5IDE1LCAyMDE2LCBhdCA4OjA2 IFBNLCBvdHJvYW5AZW1wbG95ZWVzLm9yZyB3cm90ZToNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IFRh bCwNCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBbQXBvbG9naWVzIGlmIHRoaXMgaXNzdWUgaGFzIGJl ZW4gZGlzY3Vzc2VkIGJlZm9yZS5dDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEFjY29yZGluZyB0 byBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlciwgYW4g4oCYU1INCj4+Pj4+ Pj4+Pj4gU2VnbWVudA0KPj4+Pj4+Pj4gRW5kcG9pbnQgTm9kZeKAmSB1cGRhdGVzIHRoZSBEZXN0 aW5hdGlvbiBJUCBhZGRyZXNzLg0KPj4+Pj4+Pj4+PiBUaGVyZWZvcmUsIGl0IG11c3QgYWxzbyB1 cGRhdGUgdGhlIExheWVyIDQgQ2hlY2tzdW0sIHJpZ2h0Pw0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ PiBJIHdvbmRlciBpZiB0aGVyZSBpcyBhbiB1cHBlciBib3VuZCBvbiB0aGUgc2l6ZSBvZiB0aGUg U1JILg0KPj4+Pj4+Pj4+PiBPdGhlcndpc2UsIHRoZQ0KPj4+Pj4+Pj4gTDQgQ2hlY2tzdW0gbWF5 IGJlIGxvY2F0ZWQgaW4gYSBwcmV0dHkgZGVlcCBsb2NhdGlvbi4NCj4+Pj4+Pj4+Pj4gU3BlYWtp bmcgZnJvbSBhIGNoaXAgdmVuZG9y4oCZcyBwZXJzcGVjdGl2ZSB0aGlzIG1heSBiZSBhIHByb2Js ZW0uDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBGcm9tIFJGQzI0NjAsIFJIMDoNCj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gICBvICBJZiB0aGUgSVB2NiBwYWNrZXQgY29udGFpbnMgYSBS b3V0aW5nIGhlYWRlciwgdGhlIERlc3RpbmF0aW9uDQo+Pj4+Pj4+Pj4gICAgICBBZGRyZXNzIHVz ZWQgaW4gdGhlIHBzZXVkby1oZWFkZXIgaXMgdGhhdCBvZiB0aGUgZmluYWwNCj4+Pj4+Pj4+PiAg ICAgIGRlc3RpbmF0aW9uLiAgQXQgdGhlIG9yaWdpbmF0aW5nIG5vZGUsIHRoYXQgYWRkcmVzcyB3 aWxsIGJlIGluDQo+Pj4+Pj4+Pj4gICAgICB0aGUgbGFzdCBlbGVtZW50IG9mIHRoZSBSb3V0aW5n IGhlYWRlcjsgYXQgdGhlIHJlY2lwaWVudChzKSwNCj4+Pj4+Pj4+PiAgICAgIHRoYXQgYWRkcmVz cyB3aWxsIGJlIGluIHRoZSBEZXN0aW5hdGlvbiBBZGRyZXNzIGZpZWxkIG9mIHRoZQ0KPj4+Pj4+ Pj4+ICAgICAgSVB2NiBoZWFkZXIuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBJIHdvdWxkIGV4cGVj dCBTUiB3b3VsZCB3b3JrIHRoZSBzYW1lLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBl eGFjdGx5Lg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IE1vcmVvdmVyLCBkcmFmdC1pZXRmLTZtYW4tc2Vn bWVudC1yb3V0aW5nLWhlYWRlciBhc3N1bWVzDQo+Pj4+Pj4+PiBlbmNhcHN1bGF0aW9uIHNvIGNs ZWFybHkgdGhlcmXigJlzIG5vIEw0IGludm9sdmVkIGhlcmUuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4g cy4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4+ Pj4+Pj4+IE9sZQ0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pg0KPj4+DQo+Pj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4+PiBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4+PiBpcHY2QGll dGYub3JnDQo+Pj4gQWRtaW5pc3RyYXRpdmUgUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCg== From nobody Tue May 17 02:39:54 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC84612B061; Tue, 17 May 2016 02:39:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 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, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id anXzER3dSNKP; Tue, 17 May 2016 02:39:50 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E571212B030; Tue, 17 May 2016 02:39:49 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id f66so12629573vkh.2; Tue, 17 May 2016 02:39:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=Cg65WDz/u0M2yJZRe8MrG3Pcp1ONgS+axoc5dwXFXis=; b=p0/T+gV8Z0hE7rwTmvDD94s9V5jpEmk+HEPmcq3Tf3kmigEmUGicj0u6miw9+sxu3A cvaEJwGz5RMTw+zVxZH7LsQTgJa2tji4WbaxxL0sAvfsgYBijsv/sB0ack8xQDa1T5Y5 LnncGBg2Ir2t5U56gaAlXTPOOeV+zReHtOPC6EYcgnxlp+7D+cLo45xMau1h/UjDSrby bfQk0Df4/I964nwxEZC/YTLnbTdLFCjrxB7bvPbJ4ROfrtMv4njjBlaOMiEf48zxFnDP ZIQo2oWh5yG0cQFSpiuQwXoSO9RNwzicpFTFfTDG55ICEpe7KJHbT6D6b88Cv4ZMkOvK JoCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=Cg65WDz/u0M2yJZRe8MrG3Pcp1ONgS+axoc5dwXFXis=; b=Q8IKuijRUTg1e0wWeC9D6J6I1L3d5zqpTB4sUvbbHmwLQx0kD0fY8mtyj7sKv7qWyQ vi9OufAVwhhHX3fpNAiDS7xurn6cuOBKutA1/6S70r9gR2l62JZPcAswdIAoToWkUY/4 7tmWpJ11VC8Yh+55n8H4pEZmFJf0omeFJ0DTfRassUQHEapM7VgEak8rO3ndnVFAZpT7 h1F9MwdETyxkPHGLZTZFQ96MDwQjJgRjzrH82zZ24i6TsgvvOBB/PABROAE6dmAb2E7b nc6CHT60NUGNEIVvrxCkUQlwLBsrm5UFky7mHJZ+FcgnzO6cpkno+uYeuG+XkcD6Dx2t Hrlw== X-Gm-Message-State: AOPr4FXoH3SNQDGq0LABTw3podughYiJoiPltfoWng/QI0LfB+f+16ButmDRTYd9xRBcnlxCodKcELRC1paJCA== MIME-Version: 1.0 X-Received: by 10.159.37.100 with SMTP id 91mr98594uaz.67.1463477988977; Tue, 17 May 2016 02:39:48 -0700 (PDT) Received: by 10.176.4.55 with HTTP; Tue, 17 May 2016 02:39:48 -0700 (PDT) Received: by 10.176.4.55 with HTTP; Tue, 17 May 2016 02:39:48 -0700 (PDT) In-Reply-To: <1e13d2e32b2448af94bf23d5acf17740@IL-EXCH02.marvell.com> References: <5dc56935eba94c2390120244564f9b21@IL-EXCH02.marvell.com> <0551686F-F1D2-4C34-81C8-530F1BEE1BDF@cisco.com> <5d889e7013b44b27ae1e75cf7ea2dd22@IL-EXCH02.marvell.com> <3549ABBE-9828-42D2-A056-851432487E2E@cisco.com> <1e13d2e32b2448af94bf23d5acf17740@IL-EXCH02.marvell.com> Date: Tue, 17 May 2016 19:39:48 +1000 Message-ID: From: Mark Smith To: Tal Mizrahi Content-Type: multipart/alternative; boundary=94eb2c122da4ab742f05330685af Archived-At: Cc: "spring@ietf.org" , 6man WG , "draft-ietf-nvo3-vxlan-gpe@tools.ietf.org" , Tom Herbert , "nvo3@ietf.org" , "draft-ietf-6man-segment-routing-header@tools.ietf.org" , "draft-ietf-nvo3-geneve@tools.ietf.org" , "Stefano Previdi \(sprevidi\)" Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 09:39:53 -0000 --94eb2c122da4ab742f05330685af Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 17 May 2016 7:09 PM, "Tal Mizrahi" wrote: > > Stefano, > > If I understand your point correctly: > IPv6 segment routing does not work with VXLAN / VXLAN-GPE / Geneve, since these encapsulations do not currently allow the use of IPv6 extension headers. > Do they specifically prohibit them after the outer fixed IPv6 header? This is what I'd expect a SR+VXLAN packet to look like coming from a SR enabled VXLAN tunnel end point. [IPv6 HDR][SR EH][UDP][VXLAN][tunneled pkt.] Regards, Mark. > I wonder if the authors of VXLAN-GPE and Geneve have considered the use of segment routing. > > Thanks, > Tal. > > > > >-----Original Message----- > >From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] > >Sent: Tuesday, May 17, 2016 10:41 AM > >To: Tom Herbert > >Cc: Tal Mizrahi; 6man WG; spring@ietf.org; draft-ietf-6man-segment-routing- > >header@tools.ietf.org > >Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing- > >header > > > > > >> On May 16, 2016, at 7:10 PM, Tom Herbert wrote: > >> > >> On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi > >wrote: > >>>> it=E2=80=99s all about IP, not layer-2. > >>>> > >>>> s. > >>> > >>> Right. However, it appears that at least in some cases a VXLAN VTEP will > >use SR. It certainly may be the case in SFC use cases (see Section 2.3 in draft- > >ietf-spring-ipv6-use-cases). > >>> > >> > >> draft-ietf-6man-segment-routing-header mentions that the packet is > >> encapsulated > > > > > >into an outer ipv6 header which makes it a layer-3 encap. > > > > > >> , but I don't think it is explicit as to exact encapsulation format (I > >> suppose simple ip6ip6 is implied). > > > > > >see section 2.2 > > > > > >> But, it > >> seems like any of several encapsulation techniques could work (VXLAN, > > > > > >I have some problems to understand where to fit an extension header into a > >vxlan encap=E2=80=A6 > > > > > >> GRE/IP, ESP/IP, GUE, foo over UDP, etc.) and if a device that wants to > >> do SR is already doing tunneling it seems reasonable to me to only > >> have one layer of encapsulation. Maybe this should be clarified in the > >> draft? > > > > > >the draft is about IPv6 extension header and more precisely a new type of the > >routing extension header defined in rfc2460. That=E2=80=99s the context. > > > > > >s. > > > > > > > > > >> > >> Tom > >> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] > >>>> Sent: Monday, May 16, 2016 2:24 PM > >>>> To: Tal Mizrahi > >>>> Cc: Ole Tr=C3=B8an; > >>>> draft-ietf-6man-segment-routing-header@tools.ietf.org; > >>>> spring@ietf.org; 6man WG > >>>> Subject: Re: [spring] L4 Checksum and > >>>> draft-ietf-6man-segment-routing- header > >>>> > >>>> > >>>>> On May 16, 2016, at 1:19 PM, Tal Mizrahi wrote: > >>>>> > >>>>> Hi Stefano, > >>>>> > >>>>> Thanks again for the prompt response. > >>>>> > >>>>>> 2. the SRH is originated by the ingress node of the SR domain. > >>>>>> This is done by encapsulating the packet into a outer > >>>>>> (additional) ipv6 header followed by an SRH. This is L3 > >>>>>> encapsulation and no L4 checksum is involved. When the packet > >>>>>> leaves the SR tunnel the outer encapsulation (including the SRH) > >>>>>> is removed and the packet continues its journey like nothing happened. > >>>>> > >>>>> So VXLAN is off the table? > >>>> > >>>> > >>>> it=E2=80=99s all about IP, not layer-2. > >>>> > >>>> s. > >>>> > >>>> > >>>>> It would be worthwhile to clarify this in the draft. If you have a > >>>>> specific > >>>> encapsulation in mind, it would be great if the draft would specify it. > >>>>> > >>>>> Thanks, > >>>>> Tal. > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] > >>>>>> Sent: Monday, May 16, 2016 2:13 PM > >>>>>> To: Tal Mizrahi > >>>>>> Cc: Ole Tr=C3=B8an; > >>>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org; > >>>>>> spring@ietf.org; 6man WG > >>>>>> Subject: Re: [spring] L4 Checksum and > >>>>>> draft-ietf-6man-segment-routing- header > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> On May 16, 2016, at 11:04 AM, Tal Mizrahi > >wrote: > >>>>>>> > >>>>>>> Hi Stefano, > >>>>>>> > >>>>>>> Thanks for the responses. > >>>>>>> > >>>>>>>> exactly. > >>>>>>>> > >>>>>>>> Moreover, draft-ietf-6man-segment-routing-header assumes > >>>>>>>> encapsulation so clearly there=E2=80=99s no L4 involved here. > >>>>>>>> > >>>>>>>> s. > >>>>>>> > >>>>>>> Two questions: > >>>>>>> 1. What if the encapsulation is VXLAN? L4 would still be involved= , > >right? > >>>>>> > >>>>>> > >>>>>> See below. > >>>>>> > >>>>>> > >>>>>>> 2. When you say 'assumes encapsulation', does it mean that a host > >>>>>>> cannot > >>>>>> send an IPv6 packet with an SRH? The current draft says: > >>>>>>> > >>>>>>> A Source SR Node can be any node originating an IPv6 packet with > >>>>>>> its > >>>>>>> IPv6 and Segment Routing Headers. This include either: > >>>>>>> > >>>>>>> A host originating an IPv6 packet. > >>>>>>> > >>>>>>> An SR domain ingress router encapsulating a received IPv6 packet > >>>>>>> into an outer IPv6 header followed by an SRH. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Will appreciate if you can clarify that. > >>>>>> > >>>>>> > >>>>>> ok, two cases: > >>>>>> > >>>>>> 1. the SRH is inserted at the source. > >>>>>> the source originates the packet, the ipv6 header and the SRH. > >>>>>> The source computes L4 checksum taking into account the whole > >IPv6+SRH. > >>>>>> Here, theres=E2=80=99 nothing new compared to rfc2460. > >>>>>> > >>>>>> 2. the SRH is originated by the ingress node of the SR domain. > >>>>>> This is done by encapsulating the packet into a outer > >>>>>> (additional) ipv6 header followed by an SRH. This is L3 > >>>>>> encapsulation and no L4 checksum is involved. When the packet > >>>>>> leaves the SR tunnel the outer encapsulation (including the SRH) > >>>>>> is removed and the packet continues its journey like nothing happened. > >>>>>> > >>>>>> s. > >>>>>> > >>>>>> > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Tal. > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] > >>>>>>>> Sent: Monday, May 16, 2016 11:59 AM > >>>>>>>> To: Ole Tr=C3=B8an; Tal Mizrahi > >>>>>>>> Cc: draft-ietf-6man-segment-routing-header@tools.ietf.org; > >>>>>>>> spring@ietf.org; 6man WG > >>>>>>>> Subject: Re: [spring] L4 Checksum and > >>>>>>>> draft-ietf-6man-segment-routing- header > >>>>>>>> > >>>>>>>> > >>>>>>>>> On May 15, 2016, at 8:06 PM, otroan@employees.org wrote: > >>>>>>>>> > >>>>>>>>> Tal, > >>>>>>>>> > >>>>>>>>>> [Apologies if this issue has been discussed before.] > >>>>>>>>>> > >>>>>>>>>> According to draft-ietf-6man-segment-routing-header, an =E2=80= =98SR > >>>>>>>>>> Segment > >>>>>>>> Endpoint Node=E2=80=99 updates the Destination IP address. > >>>>>>>>>> Therefore, it must also update the Layer 4 Checksum, right? > >>>>>>>>>> > >>>>>>>>>> I wonder if there is an upper bound on the size of the SRH. > >>>>>>>>>> Otherwise, the > >>>>>>>> L4 Checksum may be located in a pretty deep location. > >>>>>>>>>> Speaking from a chip vendor=E2=80=99s perspective this may be = a problem. > >>>>>>>>> > >>>>>>>>> From RFC2460, RH0: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> o If the IPv6 packet contains a Routing header, the Destination > >>>>>>>>> Address used in the pseudo-header is that of the final > >>>>>>>>> destination. At the originating node, that address will be in > >>>>>>>>> the last element of the Routing header; at the recipient(s), > >>>>>>>>> that address will be in the Destination Address field of the > >>>>>>>>> IPv6 header. > >>>>>>>>> > >>>>>>>>> I would expect SR would work the same. > >>>>>>>> > >>>>>>>> > >>>>>>>> exactly. > >>>>>>>> > >>>>>>>> Moreover, draft-ietf-6man-segment-routing-header assumes > >>>>>>>> encapsulation so clearly there=E2=80=99s no L4 involved here. > >>>>>>>> > >>>>>>>> s. > >>>>>>>> > >>>>>>>> > >>>>>>>>> > >>>>>>>>> Cheers, > >>>>>>>>> Ole > >>>>>>>>> > >>>>>>> > >>>>> > >>> > >>> -------------------------------------------------------------------- > >>> IETF IPv6 working group mailing list > >>> ipv6@ietf.org > >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>> -------------------------------------------------------------------- > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- --94eb2c122da4ab742f05330685af Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 17 May 2016 7:09 PM, "Tal Mizrahi" <talmi@marvell.com> wrote:
>
> Stefano,
>
> If I understand your point correctly:
> IPv6 segment routing does not work with VXLAN / VXLAN-GPE / Geneve, si= nce these encapsulations do not currently allow the use of IPv6 extension h= eaders.
>

Do they specifically prohibit them after the outer fixed IPv= 6 header?

This is what I'd expect a SR+VXLAN packet to look like c= oming from a SR enabled VXLAN tunnel end point.

[IPv6 HDR][SR EH][UDP][VXLAN][tunneled pkt.]

Regards,
Mark.

> I wonder if the authors of VXLAN-GPE and Geneve have co= nsidered the use of segment routing.
>
> Thanks,
> Tal.
>
>
>
> >-----Original Message-----
> >From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
> >Sent: Tuesday, May 17, 2016 10:41 AM
> >To: Tom Herbert
> >Cc: Tal Mizrahi; 6man WG; sprin= g@ietf.org; draft-ietf-6man-segment-routing-
> >header@tools.ietf.org=
> >Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-rout= ing-
> >header
> >
> >
> >> On May 16, 2016, at 7:10 PM, Tom Herbert <tom@herbertland.com> wrote:
> >>
> >> On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi <talmi@marvell.com>
> >wrote:
> >>>> it=E2=80=99s all about IP, not layer-2.
> >>>>
> >>>> s.
> >>>
> >>> Right. However, it appears that at least in some cases a = VXLAN VTEP will
> >use SR. It certainly may be the case in SFC use cases (see Section= 2.3 in draft-
> >ietf-spring-ipv6-use-cases).
> >>>
> >>
> >> draft-ietf-6man-segment-routing-header mentions that the pack= et is
> >> encapsulated
> >
> >
> >into an outer ipv6 header which makes it a layer-3 encap.
> >
> >
> >> , but I don't think it is explicit as to exact encapsulat= ion format (I
> >> suppose simple ip6ip6 is implied).
> >
> >
> >see section 2.2
> >
> >
> >> But, it
> >> seems like any of several encapsulation techniques could work= (VXLAN,
> >
> >
> >I have some problems to understand where to fit an extension heade= r into a
> >vxlan encap=E2=80=A6
> >
> >
> >> GRE/IP, ESP/IP, GUE, foo over UDP, etc.) and if a device that= wants to
> >> do SR is already doing tunneling it seems reasonable to me to= only
> >> have one layer of encapsulation. Maybe this should be clarifi= ed in the
> >> draft?
> >
> >
> >the draft is about IPv6 extension header and more precisely a new = type of the
> >routing extension header defined in rfc2460. That=E2=80=99s the co= ntext.
> >
> >
> >s.
> >
> >
> >
> >
> >>
> >> Tom
> >>
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
> >>>> Sent: Monday, May 16, 2016 2:24 PM
> >>>> To: Tal Mizrahi
> >>>> Cc: Ole Tr=C3=B8an;
> >>>> draft-ietf-6man-segment-routing-header@tools.ietf.org;
> >>>> spring@ietf.org; 6man WG
> >>>> Subject: Re: [spring] L4 Checksum and
> >>>> draft-ietf-6man-segment-routing- header
> >>>>
> >>>>
> >>>>> On May 16, 2016, at 1:19 PM, Tal Mizrahi <talmi@marvell.com> wrote:
> >>>>>
> >>>>> Hi Stefano,
> >>>>>
> >>>>> Thanks again for the prompt response.
> >>>>>
> >>>>>> 2. the SRH is originated by the ingress node = of the SR domain.
> >>>>>> This is done by encapsulating the packet into= a outer
> >>>>>> (additional) ipv6 header followed by an SRH. = This is L3
> >>>>>> encapsulation and no L4 checksum is involved.= When the=C2=A0 packet
> >>>>>> leaves the SR tunnel the outer encapsulation= =C2=A0 (including the SRH)
> >>>>>> is removed and the packet continues=C2=A0 its= journey like nothing happened.
> >>>>>
> >>>>> So VXLAN is off the table?
> >>>>
> >>>>
> >>>> it=E2=80=99s all about IP, not layer-2.
> >>>>
> >>>> s.
> >>>>
> >>>>
> >>>>> It would be worthwhile to clarify this in the dra= ft. If you have a
> >>>>> specific
> >>>> encapsulation in mind, it would be great if the draft= would specify it.
> >>>>>
> >>>>> Thanks,
> >>>>> Tal.
> >>>>>
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
> >>>>>> Sent: Monday, May 16, 2016 2:13 PM
> >>>>>> To: Tal Mizrahi
> >>>>>> Cc: Ole Tr=C3=B8an;
> >>>>>> draft-ietf-6man-segment-routing-header@tools.ie= tf.org;
> >>>>>> spring@iet= f.org; 6man WG
> >>>>>> Subject: Re: [spring] L4 Checksum and
> >>>>>> draft-ietf-6man-segment-routing- header
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> On May 16, 2016, at 11:04 AM, Tal Mizrahi <= ;talmi@marvell.com>
> >wrote:
> >>>>>>>
> >>>>>>> Hi Stefano,
> >>>>>>>
> >>>>>>> Thanks for the responses.
> >>>>>>>
> >>>>>>>> exactly.
> >>>>>>>>
> >>>>>>>> Moreover, draft-ietf-6man-segment-rou= ting-header assumes
> >>>>>>>> encapsulation so clearly there=E2=80= =99s no L4 involved here.
> >>>>>>>>
> >>>>>>>> s.
> >>>>>>>
> >>>>>>> Two questions:
> >>>>>>> 1. What if the encapsulation is VXLAN? L4= would still be involved,
> >right?
> >>>>>>
> >>>>>>
> >>>>>> See below.
> >>>>>>
> >>>>>>
> >>>>>>> 2. When you say 'assumes encapsulatio= n', does it mean that a host
> >>>>>>> cannot
> >>>>>> send an IPv6 packet with an SRH? The current = draft says:
> >>>>>>>
> >>>>>>> A Source SR Node can be any node originat= ing an IPv6 packet with
> >>>>>>> its
> >>>>>>> IPv6 and Segment Routing Headers.=C2=A0 T= his include either:
> >>>>>>>
> >>>>>>>=C2=A0 =C2=A0 A host originating an IPv6 p= acket.
> >>>>>>>
> >>>>>>>=C2=A0 =C2=A0 An SR domain ingress router = encapsulating a received IPv6 packet
> >>>>>>>=C2=A0 =C2=A0 into an outer IPv6 header fo= llowed by an SRH.
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> Will appreciate if you can clarify that.<= br> > >>>>>>
> >>>>>>
> >>>>>> ok, two cases:
> >>>>>>
> >>>>>> 1. the SRH is inserted at the source.
> >>>>>> the source originates the packet, the ipv6 he= ader and=C2=A0 the SRH.
> >>>>>> The source computes L4 checksum taking into= =C2=A0 account the whole
> >IPv6+SRH.
> >>>>>> Here, theres=E2=80=99 nothing new=C2=A0 compa= red to rfc2460.
> >>>>>>
> >>>>>> 2. the SRH is originated by the ingress node = of the SR domain.
> >>>>>> This is done by encapsulating the packet into= a outer
> >>>>>> (additional) ipv6 header followed by an SRH. = This is L3
> >>>>>> encapsulation and no L4 checksum is involved.= When the=C2=A0 packet
> >>>>>> leaves the SR tunnel the outer encapsulation= =C2=A0 (including the SRH)
> >>>>>> is removed and the packet continues=C2=A0 its= journey like nothing happened.
> >>>>>>
> >>>>>> s.
> >>>>>>
> >>>>>>
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Tal.
> >>>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: Stefano Previdi (sprevidi) [mai= lto:sprevidi@cisco.com]
> >>>>>>>> Sent: Monday, May 16, 2016 11:59 AM > >>>>>>>> To: Ole Tr=C3=B8an; Tal Mizrahi
> >>>>>>>> Cc: draft-ietf-6man-segment-routing-hea= der@tools.ietf.org;
> >>>>>>>> sp= ring@ietf.org; 6man WG
> >>>>>>>> Subject: Re: [spring] L4 Checksum and=
> >>>>>>>> draft-ietf-6man-segment-routing- head= er
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> On May 15, 2016, at 8:06 PM, otroan@employees.org wrote:
> >>>>>>>>>
> >>>>>>>>> Tal,
> >>>>>>>>>
> >>>>>>>>>> [Apologies if this issue has = been discussed before.]
> >>>>>>>>>>
> >>>>>>>>>> According to draft-ietf-6man-= segment-routing-header, an =E2=80=98SR
> >>>>>>>>>> Segment
> >>>>>>>> Endpoint Node=E2=80=99 updates the De= stination IP address.
> >>>>>>>>>> Therefore, it must also updat= e the Layer 4 Checksum, right?
> >>>>>>>>>>
> >>>>>>>>>> I wonder if there is an upper= bound on the size of the SRH.
> >>>>>>>>>> Otherwise, the
> >>>>>>>> L4 Checksum may be located in a prett= y deep location.
> >>>>>>>>>> Speaking from a chip vendor= =E2=80=99s perspective this may be a problem.
> >>>>>>>>>
> >>>>>>>>> From RFC2460, RH0:
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>=C2=A0 =C2=A0o=C2=A0 If the IPv6 p= acket contains a Routing header, the Destination
> >>>>>>>>>=C2=A0 =C2=A0 =C2=A0 Address used = in the pseudo-header is that of the final
> >>>>>>>>>=C2=A0 =C2=A0 =C2=A0 destination.= =C2=A0 At the originating node, that address will be in
> >>>>>>>>>=C2=A0 =C2=A0 =C2=A0 the last elem= ent of the Routing header; at the recipient(s),
> >>>>>>>>>=C2=A0 =C2=A0 =C2=A0 that address = will be in the Destination Address field of the
> >>>>>>>>>=C2=A0 =C2=A0 =C2=A0 IPv6 header.<= br> > >>>>>>>>>
> >>>>>>>>> I would expect SR would work the = same.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> exactly.
> >>>>>>>>
> >>>>>>>> Moreover, draft-ietf-6man-segment-rou= ting-header assumes
> >>>>>>>> encapsulation so clearly there=E2=80= =99s no L4 involved here.
> >>>>>>>>
> >>>>>>>> s.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> Cheers,
> >>>>>>>>> Ole
> >>>>>>>>>
> >>>>>>>
> >>>>>
> >>>
> >>> ---------------------------------------------------------= -----------
> >>> IETF IPv6 working group mailing list
> >>> ipv6@ietf.org
> >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >>> ---------------------------------------------------------= -----------
>
> -------------------------------------------------------------------- > IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--94eb2c122da4ab742f05330685af-- From nobody Tue May 17 08:02:48 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE2412D0B8; Tue, 17 May 2016 08:02:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.20.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160517150243.22233.96184.idtracker@ietfa.amsl.com> Date: Tue, 17 May 2016 08:02:43 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-ldp-interop-03.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 15:02:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Source Packet Routing in Networking of the IETF. Title : Segment Routing interworking with LDP Authors : Clarence Filsfils Stefano Previdi Ahmed Bashandy Bruno Decraene Stephane Litkowski Filename : draft-ietf-spring-segment-routing-ldp-interop-03.txt Pages : 20 Date : 2016-05-17 Abstract: A Segment Routing (SR) node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. A segment can represent any instruction, topological or service-based. SR allows to enforce a flow through any topological path and service chain while maintaining per-flow state only at the ingress node to the SR domain. The Segment Routing architecture can be directly applied to the MPLS data plane with no change in the forwarding plane. This drafts describes how Segment Routing operates in a network where LDP is deployed and in the case where SR-capable and non-SR-capable nodes coexist. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-ldp-interop/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-segment-routing-ldp-interop-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-ldp-interop-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue May 17 08:37:41 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96F3812D95E for ; Tue, 17 May 2016 08:37:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 eIEodh1OV28U for ; Tue, 17 May 2016 08:37:38 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAD5B12D99B for ; Tue, 17 May 2016 08:37:37 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 1412040AE1 for ; Tue, 17 May 2016 17:37:36 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.31]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id E28FE2006D for ; Tue, 17 May 2016 17:37:35 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0294.000; Tue, 17 May 2016 17:37:35 +0200 From: To: "spring@ietf.org" Thread-Topic: New Version Notification for draft-previdi-isis-ipv6-prefix-sid-02.txt Thread-Index: AQHRsEcOs8ekbzQ9DkmW5sdzMZyylp+9cS+A///SIIA= Date: Tue, 17 May 2016 15:37:35 +0000 Message-ID: <32119_1463499456_573B3ABF_32119_8394_1_53C29892C857584299CBF5D05346208A0F8AB8AB@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <20160517141856.22249.35143.idtracker@ietfa.amsl.com> <0C7D2F1F-6BF6-4CE9-9FF1-86842739AC91@cisco.com> In-Reply-To: <0C7D2F1F-6BF6-4CE9-9FF1-86842739AC91@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [spring] FW: New Version Notification for draft-previdi-isis-ipv6-prefix-sid-02.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 May 2016 15:37:39 -0000 RllJDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBTdGVmYW5vIFByZXZpZGkg KHNwcmV2aWRpKSANClNlbnQ6IFR1ZXNkYXksIE1heSAxNywgMjAxNiA0OjIxIFBNDQpUbzogaXNp cy13Z0BpZXRmLm9yZyBsaXN0DQpTdWJqZWN0OiBSZTogW0lzaXMtd2ddIE5ldyBWZXJzaW9uIE5v dGlmaWNhdGlvbiBmb3IgZHJhZnQtcHJldmlkaS1pc2lzLWlwdjYtcHJlZml4LXNpZC0wMi50eHQN Cg0KSGksDQoNCnRoaXMgZHJhZnQgZGVmaW5lcyB0aGUgSVB2Ni1QcmVmaXgtU0lEIHN1Yi1UTFYg aW4gaXNpcyBhbmQgbm93IHN1cHBvcnRpbmcgYWRkaXRpb24gb2Ygc3ViLXN1Yi10bHbigJlzLg0K DQpUaGFua3MuDQpzLg0KDQoNCg0KPiBPbiBNYXkgMTcsIDIwMTYsIGF0IDQ6MTggUE0sIGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyB3cm90ZToNCj4gDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIG9mIEkt RCwgZHJhZnQtcHJldmlkaS1pc2lzLWlwdjYtcHJlZml4LXNpZC0wMi50eHQNCj4gaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTdGVmYW5vIFByZXZpZGkgYW5kIHBvc3RlZCB0byB0 aGUNCj4gSUVURiByZXBvc2l0b3J5Lg0KPiANCj4gTmFtZToJCWRyYWZ0LXByZXZpZGktaXNpcy1p cHY2LXByZWZpeC1zaWQNCj4gUmV2aXNpb246CTAyDQo+IFRpdGxlOgkJU2VnbWVudCBSb3V0aW5n IElQdjYgUHJlZml4LVNJRA0KPiBEb2N1bWVudCBkYXRlOgkyMDE2LTA1LTE3DQo+IEdyb3VwOgkJ SW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+IFBhZ2VzOgkJNg0KPiBVUkw6ICAgICAgICAgICAgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LXByZXZpZGktaXNpcy1pcHY2 LXByZWZpeC1zaWQtMDIudHh0DQo+IFN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1wcmV2aWRpLWlzaXMtaXB2Ni1wcmVmaXgtc2lkLw0KPiBIdG1s aXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXByZXZpZGktaXNp cy1pcHY2LXByZWZpeC1zaWQtMDINCj4gRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1wcmV2aWRpLWlzaXMtaXB2Ni1wcmVmaXgtc2lkLTAyDQo+ IA0KPiBBYnN0cmFjdDoNCj4gICBUaGlzIGRvY3VtZW50IGRlZmluZXMgdGhlIFNlZ21lbnQgUm91 dGluZyBJUHY2LVByZWZpeC1TSUQgc3ViLVRMVi4NCj4gICBUaGlzIG5ldyBzdWItVExWIGFsbG93 cyB0byBzcGVjaWZ5IHdoaWNoIG9mIHRoZSBwcmVmaXhlcyBhZHZlcnRpc2VkDQo+ICAgYnkgYSBu b2RlIGFyZSB0byBiZSB1c2VkIGFzIFNlZ21lbnQgUm91dGluZyBJZGVudGlmaWVycyAoU0lEKSBm b3IgdGhlDQo+ICAgSVB2NiBkYXRhIHBsYW5lLg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IFBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mIHN1Ym1pc3Npb24NCj4gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJl IGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gDQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0 DQo+IA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K SXNpcy13ZyBtYWlsaW5nIGxpc3QNCklzaXMtd2dAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaXNpcy13Zw0KCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2Vz IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRl bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZm dXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6 IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhw ZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMg bWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApP cmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFs dGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlz dHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBt YXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2 ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK From nobody Wed May 18 04:57:26 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93CEB12D0EA for ; Wed, 18 May 2016 04:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 G8vglqGzpoes for ; Wed, 18 May 2016 04:57:15 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4B3312D0ED for ; Wed, 18 May 2016 04:56:57 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 0E2062068B; Wed, 18 May 2016 13:56:56 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.66]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id D7C5820057; Wed, 18 May 2016 13:56:55 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf%19]) with mapi id 14.03.0294.000; Wed, 18 May 2016 13:56:55 +0200 From: To: "Les Ginsberg (ginsberg)" , "spring@ietf.org" Thread-Topic: draft-ietf-spring-conflict-resolution Thread-Index: AdGsH1sLbD2noig8RN69oeD7/m3vEgB7FIAwALK78OA= Date: Wed, 18 May 2016 11:56:55 +0000 Message-ID: <29660_1463572616_573C5887_29660_1788_1_53C29892C857584299CBF5D05346208A0F8AC57D@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <5548_1463066557_57349FBD_5548_8297_1_53C29892C857584299CBF5D05346208A0F8A48D7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <963520eb14aa491f9ad01e1a834d64af@XCH-ALN-001.cisco.com> In-Reply-To: <963520eb14aa491f9ad01e1a834d64af@XCH-ALN-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F8AC57DOPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] draft-ietf-spring-conflict-resolution X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 11:57:22 -0000 --_000_53C29892C857584299CBF5D05346208A0F8AC57DOPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Les, Thanks for your reply. Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Saturday, May 14, 2016 8:30 PM To: DECRAENE Bruno IMT/OLN; spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution Bruno - Inline. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution Hi, As an individual contributor, please find below some comments: -- Isn't this document specific to the MPLS dataplane? If so, it could be indicated in the introduction, and possibly in the abstr= act. Then this indication could be removed from the 1rst sentence of sectio= ns 2 & 3. [Les:] Currently all discussion is regarding SR-MPLS. The draft leaves open= the possibility that if there is some SRv6 conflict resolution that needs = to be specified it could be added into this document - which is why the Int= roduction is dataplane agnostic, but each section states specifically that = it is relevant to SR-MPLS. I am not aware of any SRv6 conflict resolution that is required at this poi= nt, but I prefer to leave the possibility open if that is OK with you. [Bruno] ok, great. -- =A73 "Mapping entries have an explicit context which includes the topology and t= he SR algorithm." A priori you could add "the routing protocol". [Les:] No - the source of advertisements is deliberately left out. It matte= rs not whether the source of the advertisement is a protocol or an SRMS - n= or does it matter which protocol provides the advertisement. You see that "= admin distance" is not mentioned at all and that is quite deliberate. This = insures that consistent choices are made on nodes regardless of which proto= col might have the best route on a given node. [Bruno] Well, the fact is that mapping entries do have, as explicit context= , the routing protocol used to advertise them. After, you can should to use= that information, or not. -- =A73 "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". If a router chooses to use one of the conflicting entries forwarding loops and/or blackholes may result unless it can be guaranteed that all other routers in the network make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. =BB I think we agree on the technical part, but I found the formulation slightl= y biased. I would propose "When conflicts occur, it is not possible for routers to know which of the conflicting advertisements is "correct". In order to avoid forwarding loops and/or blackholes, the= re is a need for all nodes to make the same choice. Making the same choice requires that all routers have identical sets of advertisements and that they all use the same selection algorithm. This is the purpose of this document. =BB -- [Les:] I am fine with this change. [Bruno] Thanks =A73.1 "Various types of conflicts may occur" What about :s/Various/Two [Les:] "Two" is fine. Just means we will have to change it if we come up wi= th a third type of conflict. :) [Bruno] Indeed, but in this case the change may be much larger (e.g. the wh= ole algo) -- I agree with Robert's and Uma's comment with regards to making this confli= ct resolution an inter- protocol/routing_table issue. In particular, betwee= n SR domains, there is not requirement to have unique SIDs. Hence between P= E and CE, between ASes (both within and across organization), the same SID = could be reused independently). [Les:] There is more to be said on this topic - co-authors are actively dis= cussing this point and we'll respond more fully to Robert's post in time. B= ut, the draft is NOT trying to define conflict resolution across "SR domain= s". Perhaps we need language to make that more explicit. [Bruno] ok. Regarding inter-protocol, in order to have consistency of the p= refix-SID mapping across the domain we need: a) all nodes use the same algo b) all nodes using this algo have the same data "a" requires this draft "b" requires that all nodes have the same set of SR info. This forbid that= some node are considering IS-IS + OSPF SR data, while some node are only c= onsidering IS-IS data. Otherwise, all IS-IS routers would not take the same= decision. So, unless we can guarantee that the flooding area is the same f= or IS-IS and OSPF, we can't have the algo using the SR data from multiple r= outing protocols. I don't think that we can guarantee this (nor that implem= entation will check this) e.g. when some nodes are part of multiple routing= domain or when gradually transitioning from one IGP to another. So in short, this SR-conflict algo should probably be restricted to SR info= rmation from a single protocol > From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > Sent: Sunday,= May 01, 2016 7:11 AM > > We are indeed defining conflict resolution across all the SID advertiseme= nts regardless of source (protocol or SRMS) > Why? Because we need consistent use of SIDs in the forwarding plane No: in the forwarding plane, we need a consistent use of MPLS label. [Les:] As you know, SRGB range can be different for different nodes, so the= actual label that is used to send a packet for a given destination via Nod= e A may be different than the label used to send the same packet via Node B= . It is the SID that needs to be the same - not the label. It is true that SIDs are not installed in the forwarding plane - the labels= derived from the SID/SRGB are what is actually installed in the forwarding= plane - but I think my use of the word SID in this context is correct. [Bruno] My point was that the formulation assumes that a single SRGB is use= d per nodes. In which case, we have a bijection between SID and labels. But= if we have a SRGB per protocol, we don't have a bijection any more and we = can have the same SID in IS-IS and OSPF (including for different prefix), w= hich will be mapped to different labels in the forwarding plane. Plus only within an SR domain. Actually, even within a domain, this is depe= ndent on whether SRGB is configured on a per node or a per protocol basis. = I'm not sure how much the agreement has been reached on that one. [Les:] The draft currently addresses deployments where a single (set of) SR= GB ranges applies to the box. This is by far the most common use case. Ther= e is a much more limited use case where protocol specific SRGBs and protoco= l specific SIDs may be required. The draft will address that in a future re= vision [Bruno] ok, may be this should be stated in the draft, as otherwise you'll = keep getting comments, or we may forget this point. Thanks --Bruno - but in spirit the same rules will apply - they will just have to take int= o account "duplicate forwarding domains". Note that this will also require = multiple incoming label entries/prefix be supported by the routers in such = a network. -- Typo: =A72 OLD : Range 3: (500, 5990 NEW : Range 3: (500, 599) (somewhat significant as otherwise range 3 conflict with range 2) [Les:] Agreed - thanx for spotting this. Les Thanks, Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A0F8AC57DOPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Les,

&n= bsp;

Thanks = for your reply.

Please = see inline [Bruno]

&n= bsp;

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Saturday, May 14, 2016 8:30 PM
To: DECRAENE Bruno IMT/OLN; spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution=

 

Bruno &= #8211;

&n= bsp;

Inline.=

&n= bsp;

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution

 

Hi,

 

As an individual contributor, p= lease find below some comments:

 

--

Isn’t this document speci= fic to the MPLS dataplane?

If so, it could be indicated in= the introduction, and possibly in the abstract. Then this indication could= be removed from the 1rst sentence of sections 2 & 3.=

&n= bsp;

[= Les:] Currently all discussion is regarding SR-MPLS. The draft leaves open = the possibility that if there is some SRv6 conflict resolution that needs t= o be specified it could be added into this document – which is why the Introduction is dataplane agnostic,= but each section states specifically that it is relevant to SR-MPLS.<= /o:p>

<= o:p> 

I= am not aware of any SRv6 conflict resolution that is required at this poin= t, but I prefer to leave the possibility open if that is OK with you.<= /o:p>

[Bruno]= ok, great.<= /o:p>

--

=A73

“Mapping entries have an explicit con= text which includes the topology and the SR algorithm.“

A priori you could add “the routing p= rotocol”.

 

[= Les:] No – the source of advertisements is deliberately left out. It = matters not whether the source of the advertisement is a protocol or an SRM= S – nor does it matter which protocol provides the advertisement. You see that “admin distance” is not mentio= ned at all and that is quite deliberate. This insures that consistent choic= es are made on nodes regardless of which protocol might have the best route= on a given node.

[Bruno]= Well, the fact is that mapping entries do have, as explicit context, the r= outing protocol used to advertise them. After, you can should to use that i= nformation, or not.

--

=A73

“When conflicts occur, it is not
   possible for routers to know which of the confli=
cting advertisements
   is "correct".  If a router choose=
s to use one of the conflicting
   entries forwarding loops and/or blackholes may r=
esult unless it can
   be guaranteed that all other routers in the netw=
ork make the same
   choice.  Making the same choice requires th=
at all routers have
   identical sets of advertisements and that they a=
ll use the same
   selection algorithm. =BB<=
/pre>

 


I think we agree on the technical part, but I found the formu=
lation slightly biased. I would propose


“When conflicts occur, it is not


   possible for routers to know which of the confli=
cting advertisements


   is "correct".  In order to avoid =
forwarding loops and/or blackholes, there is a need for all nodes to make t=
he same choice.


  Making the same choice requires that all routers have<=
o:p>


   identical sets of advertisements and that they a=
ll use the same


   selection algorithm. This is the purpose of this=
 document. =BB


--


[=
Les:] I am fine with this change.


[Bruno]=
 Thanks


&n=
bsp;


=A73.1


“Various types of conflicts may occur”=



What about :s/Various/Two


&n=
bsp;


[=
Les:] “Two” is fine. Just means we will have to change it if we=
 come up with a third type of conflict.
J


[Bruno]=
 Indeed, but in this case the change may be much larger (e.g. the whole alg=
o)


--


I agree with Robert’s &nb=
sp;and Uma’s comment with regards to making this conflict resolution =
an inter- protocol/routing_table issue. In particular, between SR domains, =
there is not requirement to have unique SIDs. Hence between
 PE and CE, between ASes (both within and across organization), the same SI=
D could be reused independently).



&n=
bsp;


[=
Les:] There is more to be said on this topic – co-authors are activel=
y discussing this point and we’ll respond more fully to Robert’=
s post in time. But, the draft is NOT trying to define conflict
 resolution across “SR domains”. Perhaps we need language to ma=
ke that more explicit.


[Bruno]=
 ok. Regarding inter-protocol, in order to have consistency of the prefix-S=
ID mapping across the domain we need:


a) all nodes use the same algo



b) all nodes using this algo have the same data<=
/o:p>


 


“a” requires this draft=



“b” requires that all nodes have the same=
 set of SR  info. This forbid that some node are considering IS-IS =
3; OSPF SR data, while some node are only considering IS-IS data.
 Otherwise, all IS-IS routers would not take the same decision. So, unless =
we can guarantee that the flooding area is the same for IS-IS and OSPF, we =
can't have the algo using the SR data from multiple routing protocols. I do=
n't think that we can guarantee
 this (nor that implementation will check this) e.g. when some nodes are pa=
rt of multiple routing domain or when gradually transitioning from one IGP =
to another.


 


So in s=
hort, this SR-conflict algo should probably be restricted to SR information=
 from a single protocol


&n=
bsp;


> From: Le=
s Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
 > Sent: Sunday, May 01, 2016 7:11 AM


>&nbs=
p;


>
We are indeed defining co=
nflict resolution across all the SID advertisements regardless of source (p=
rotocol or SRMS)


> Why?=
 Because we need consistent use of SIDs in the forwarding plane<=
/span>


 


No: in the forwarding plane, we=
 need a consistent use of MPLS label.


[=
Les:] As you know, SRGB range can be different for different nodes, so the =
actual label that is used to send a packet for a given destination via Node=
 A may be different than the label used
 to send the same packet via Node B. It is the SID that needs to be the sam=
e – not the label.



I=
t is true that SIDs are not installed in the forwarding plane – the l=
abels derived from the SID/SRGB are what is actually installed in the forwa=
rding plane – but I think my use of the word
 SID in this context is correct.


[Bruno]=
 My point was that the formulation assumes that a single SRGB is used per n=
odes. In which case, we have a bijection between SID and labels. But if we =
have a SRGB per protocol, we don’t have
 a bijection any more and we can have the same SID in IS-IS and OSPF (inclu=
ding for different prefix), which will be mapped to different labels in the=
 forwarding plane.


&n=
bsp;


Plus only within an SR domain. =
Actually, even within a domain, this is dependent on whether SRGB is config=
ured on a per node or a per protocol basis. I’m not sure how much the=
 agreement has been reached on that one.


&n=
bsp;


[=
Les:] The draft currently addresses deployments where a single (set of) SRG=
B ranges applies to the box. This is by far the most common use case. There=
 is a much more limited use case where
 protocol specific SRGBs and protocol specific SIDs may be required. The dr=
aft will address that in a future revision


[Bruno]=
 ok, may be this should be stated in the draft, as otherwise you’ll k=
eep getting comments, or we may forget this point.


Thanks<=
o:p>


--Bruno=



&=
#8211; but in spirit the same rules will apply – they will just have =
to take into account “duplicate forwarding domains”. Note that =
this will also require multiple incoming label entries/prefix
 be supported by the routers in such a network.

&n=
bsp;


--


Typo:


=A72


OLD : Range 3: (500, 5990


NEW : Range 3: (500, 599)


 


(somewhat significant as otherwise range 3 conflict with ra=
nge 2)


&n=
bsp;


[=
Les:] Agreed – thanx for spotting this.


<=
o:p> 


&=
nbsp;  Les<=
/b>


 


Thanks,


Regards,


Bruno


_=
___________________________________________________________________________=
_____________________________________________


<=
o:p> 


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as etre diffuses, exploites ou copies sans autorisation. Si vous avez recu =
ce message par erreur, veuillez le signaler


a=
 l'expediteur et le detruire ainsi que les pieces jointes. Les messages ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.


 


This message and its attachments may contain confidential or =
privileged information that may be protected by law;


they should not be distributed, used or copied without author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.


T=
hank you.


______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A0F8AC57DOPEXCLILM21corp_-- From nobody Wed May 18 04:57:44 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A10112D0FF for ; Wed, 18 May 2016 04:57:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 fffQT3ol5E4u for ; Wed, 18 May 2016 04:57:18 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDFFA12D116 for ; Wed, 18 May 2016 04:57:06 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 2FCCF22CECF; Wed, 18 May 2016 13:57:05 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id F04B327C059; Wed, 18 May 2016 13:57:04 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0294.000; Wed, 18 May 2016 13:57:04 +0200 From: To: "Les Ginsberg (ginsberg)" , "spring@ietf.org" Thread-Topic: [spring] draft-ietf-spring-conflict-resolution - Preference Algorithm Thread-Index: AdGsH1sN5kVjpbgWTcWyrGraBNd0gwB4zvjAAJS9fTA= Date: Wed, 18 May 2016 11:57:04 +0000 Message-ID: <8722_1463572625_573C5891_8722_1319_1_53C29892C857584299CBF5D05346208A0F8AC585@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <9871_1463066551_57349FB7_9871_4893_2_53C29892C857584299CBF5D05346208A0F8A48CF@OPEXCLILM21.corporate.adroot.infra.ftgroup> <2b41c4bcfe7f45bdaba9a72ea7bc9e20@XCH-ALN-001.cisco.com> In-Reply-To: <2b41c4bcfe7f45bdaba9a72ea7bc9e20@XCH-ALN-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F8AC585OPEXCLILM21corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.25.91516 Archived-At: Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Preference Algorithm X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 11:57:25 -0000 --_000_53C29892C857584299CBF5D05346208A0F8AC585OPEXCLILM21corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Les, Thanks for your quick replay. Inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Saturday, May 14, 2016 8:07 PM To: DECRAENE Bruno IMT/OLN; spring@ietf.org Subject: RE: [spring] draft-ietf-spring-conflict-resolution - Preference Al= gorithm Bruno - Thanx for your comments - inline. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution - Preference Algori= thm Hi authors, all As an individual contributor, please find below some feedback to trigger di= scussion on the Preference Algorithm defined in =A73.2.4. > 1. Smaller range wins Looks ok to me, as this gives preference to Prefix-SID advertisement from S= R routers which speaks for themselves/their own loopback/their own IP prefi= x advertisement; rather than SRMS advertisement which speaker for others. I= OW, to know Brian's SID, I'd rather believe Brian himself rather than Georg= e. Also, this gives preference to SR nodes rather than LDP nodes (SRMS entries= ). Over the time/SR deployment, as more nodes gets SR, the number of nodes = negatively impacted by the wrong configuration change is reduced. Alternatively, I'd be fine to prefer Prefix-SID advertisement over SRMS adv= ertisement. Actually, I'd propose to add this as rule 0. "0. Prefer Prefix-= SID Sub-TLV over SID/Label Binding TLV" I've been told OSPF can't make the distinction, but I'm not sure to see the= issue. [Les:] (I don't see the OSPF issue either.) This change is certainly possible. One reason we did not choose this direct= ion is because it is just as possible to misconfigure local SID configurati= on associated with a prefix advertisement as it is to misconfigure an SRMS = advertisement. [Bruno] Agreed. My reasoning was that: - Assuming we have a policy "ignore overlap only" or "by prefix/FEC", it se= ems better to give priority to SR nodes over LDP nodes, as the number of SR= nodes should grow and hopefully should rapidly becomes the majority. - SRMS will typically be redundant. So there is twice as much chance to mis= configure a SRMS announcement. Also, it's likely that any meaningful change= of configuration in one SRMS would conflict with the second SRMS, until th= e second SRMS configuration be updated. And both are not likely to be updat= ed atomically. (And I'm assuming that one MS may be atomically changed from= one config to another, which may not be granted for all implementations) Still to be discussed. Does not seem to make a big difference since the sma= ller range has preference. In the event we are migrating nodes from being non-SR capable to SR capable= we could have: 1.1.1.1/32 100 range 1 !SRMS advertisement 1.1.1.1/32 1000 range 1 !Prefix advertisement - added when a Node becomes S= R capable It seems more consistent to resolve based on the attributes of the advertis= ement rather than its source. > 4. Smaller prefix length wins I'd rather have longer prefix length wins, and move this higher in position= 3 (*). Indeed, we usually primarily care to reach a specific egress node i= .e. loopbacks destinations, which have the longest possible prefix length. (*) It needs to be after IPv6 wins, to not conflict with it, as IPv6 have l= onger prefixes. [Les:] I am fine with this change. I think the existing rules just used "sm= aller" as the tie breaker in all cases, but you have a point that in this c= ase "longer" makes more sense. [Bruno]Thanks -- Bruno Les > 3. Smaller algorithm wins > 5. Smaller starting address (considered as an unsigned integer value) wins I'm fine with this order, to privilege prefix diversity (typically for algo= 0 or 1) rather than algo diversity. (on the basis that to reach a node N, = we need a SID for this node, while to follow algo N, we can use a combinati= ons of segments from other algo). So in summary, I'd propose discussing the following OLD: 1. Smaller range wins 2. IPv6 entry wins over IPv4 entry 3. Smaller algorithm wins 4. Smaller prefix length wins 5. Smaller starting address (considered as an unsigned integer value) w= ins 6. Smaller starting SID wins NEW: 0. Prefix-SID Sub-TLV wins over SID/Label Binding TLV 1. Smaller range wins 2. IPv6 entry wins over IPv4 entry 3. Longer prefix length wins 4. Smaller algorithm wins 5. Smaller starting address (considered as an unsigned integer value) w= ins 6. Smaller starting SID wins Thanks, Regards, -- Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A0F8AC585OPEXCLILM21corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Les,=

&n= bsp;

Thanks = for your quick replay.

Inline = [Bruno]

&n= bsp;

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.c= om]
Sent: Saturday, May 14, 2016 8:07 PM
To: DECRAENE Bruno IMT/OLN; spring@ietf.org
Subject: RE: [spring] draft-ietf-spring-conflict-resolution - Prefer= ence Algorithm

 

Bruno &= nbsp;-

&n= bsp;

Thanx f= or your comments – inline.

&n= bsp;

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution - Preference= Algorithm

 

Hi authors, all

 

As an individual contributor, p= lease find below some feedback to trigger discussion on the Preference Algo= rithm defined in =A73.2.4.

 

>   1.  Smaller range wins

Looks ok to me, as this gives p= reference to Prefix-SID advertisement from SR routers which speaks for them= selves/their own loopback/their own IP prefix advertisement; rather than SR= MS advertisement which speaker for others. IOW, to know Brian’s SID, I’d rather believe Brian himself rat= her than George.

 

Also, this gives preference to = SR nodes rather than LDP nodes (SRMS entries). Over the time/SR deployment,= as more nodes gets SR, the number of nodes negatively impacted by the wron= g configuration change is reduced.

 

Alternatively, I’d be fine to prefer Prefix=
-SID advertisement over SRMS advertisement. Actually, I’d propose to =
add this as rule 0. “0. Prefer Prefix-SID Sub-TLV over SID/Label Bind=
ing TLV”

I’ve been told OSPF can&#= 8217;t make the distinction, but I’m not sure to see the issue.<= /o:p>

&n= bsp;

[= Les:] (I don’t see the OSPF issue either.)<= /p>

T= his change is certainly possible. One reason we did not choose this directi= on is because it is just as possible to misconfigure local SID configuratio= n associated with a prefix advertisement as it is to misconfigure an SRMS advertisement.

[Bruno]= Agreed. My reasoning was that:

- Assum= ing we have a policy “ignore overlap only” or “by prefix/= FEC”, it seems better to give priority to SR nodes over LDP nodes, as= the number of SR nodes should grow and hopefully should rapidly becomes the majority.

- SRMS = will typically be redundant. So there is twice as much chance to misconfigu= re a SRMS announcement. Also, it’s likely that any meaningful change = of configuration in one SRMS would conflict with the second SRMS, until the second SRMS configuration be updated. And = both are not likely to be updated atomically. (And I’m assuming that = one MS may be atomically changed from one config to another, which may not = be granted for all implementations)

&n= bsp;

Still t= o be discussed. Does not seem to make a big difference since the smaller ra= nge has preference.

<= o:p> 

<= o:p> 

I= n the event we are migrating nodes from being non-SR capable to SR capable = we could have:

<= o:p> 

1= .1.1.1/32 100 range 1 !SRMS advertisement

1= .1.1.1/32 1000 range 1 !Prefix advertisement – added when a Node beco= mes SR capable

<= o:p> 

I= t seems more consistent to resolve based on the attributes of the advertise= ment rather than its source.

&n= bsp;

> 4.  Smaller prefix length wins

I’d rather have longer pr=
efix length wins, and move this higher in position 3 (*). Indeed, we usuall=
y primarily care to reach a specific egress node i.e. loopbacks destination=
s, which have the longest possible prefix
 length. 


(*) It needs to be after IPv6 w=
ins, to not conflict with it, as IPv6 have longer prefixes.


 


[Les:] I am fine wi=
th this change. I think the existing rules just used “smaller” =
as the tie breaker in all cases, but you have a point that in this case =
220;longer” makes more sense.


[Bruno]Thanks


 <=
/pre>

-- Brun=
o


 <=
/pre>

   Les


  


>   3.  Smaller algorithm wins


>   5.  Smaller starting address (considere=
d as an unsigned integer


       value) wins


 


I’m fine with this order,=
 to privilege prefix diversity (typically for algo 0 or 1) rather than algo=
 diversity. (on the basis that to reach a node N, we need a SID for this no=
de, while to follow algo N, we can use a combinations
 of segments from other algo).


 


 


So in summary, I’d propos=
e discussing the following


OLD: 


   1.  Smaller range wins


   2.  IPv6 entry wins over IPv4 entry


   3.  Smaller algorithm wins


   4.  Smaller prefix length wins


   5.  Smaller starting address (considered as=
 an unsigned integer value) wins


   6.  Smaller starting SID wins


 


NEW:


 


   0.  Prefix-SID Sub-TLV wins over SID/Label Binding TLV


   1.  Smaller range wins


   2.  IPv6 entry wins over IPv4 entry


   3.  Longer prefix length wins


   4.  Smaller algorithm wins


   5.  Smaller starting address (considered as=
 an unsigned integer value) wins


   6.  Smaller starting SID wins


 


Thanks,


Regards,


-- Bruno


_=
___________________________________________________________________________=
_____________________________________________


<=
o:p> 


C=
e message et ses pieces jointes peuvent contenir des informations confident=
ielles ou privilegiees et ne doivent donc


p=
as etre diffuses, exploites ou copies sans autorisation. Si vous avez recu =
ce message par erreur, veuillez le signaler


a=
 l'expediteur et le detruire ainsi que les pieces jointes. Les messages ele=
ctroniques etant susceptibles d'alteration,


O=
range decline toute responsabilite si ce message a ete altere, deforme ou f=
alsifie. Merci.


 


This message and its attachments may contain confidential or =
privileged information that may be protected by law;


they should not be distributed, used or copied without author=
isation.


If you have received this email in error, please notify the s=
ender and delete this message and its attachments.


As emails may be altered, Orange is not liable for messages t=
hat have been modified, changed or falsified.


T=
hank you.


______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A0F8AC585OPEXCLILM21corp_-- From nobody Wed May 18 04:58:03 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72CBE12D190 for ; Wed, 18 May 2016 04:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 QzUq_nMgjBKZ for ; Wed, 18 May 2016 04:57:43 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.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 4C3F312D116 for ; Wed, 18 May 2016 04:57:26 -0700 (PDT) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr27.francetelecom.fr (ESMTP service) with ESMTP id 7E342A0A75; Wed, 18 May 2016 13:57:24 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.32]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id 45FE61A00B8; Wed, 18 May 2016 13:57:24 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0294.000; Wed, 18 May 2016 13:57:24 +0200 From: To: "Les Ginsberg (ginsberg)" , "spring@ietf.org" Thread-Topic: draft-ietf-spring-conflict-resolution - Policy Thread-Index: AdGsYbndUWczH5clSpukONRF0Kk37ABrjsLQAD42BeAAdOFqYA== Date: Wed, 18 May 2016 11:57:23 +0000 Message-ID: <30322_1463572644_573C58A4_30322_614_1_53C29892C857584299CBF5D05346208A0F8AC59E@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <24715_1463066559_57349FBF_24715_2873_1_53C29892C857584299CBF5D05346208A0F8A48DE@OPEXCLILM21.corporate.adroot.infra.ftgroup> <4bf6ef2278fd4e809203e988d8fba808@XCH-ALN-001.cisco.com> 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.168.234.1] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F8AC59EOPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 11:57:47 -0000 --_000_53C29892C857584299CBF5D05346208A0F8AC59EOPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding VPN, I will defer my comments for a next version of the draft whi= ch handles VPN/multiple FIB. In particular, - I'm not sure about using the same term "topology" for both VPN and IGP to= pology. - I disagree that "label database on a router is a shared resource". It is = a per forwarding table resource. You can use the same label multiple times = for different meaning, if they are in a different forwarding table e.g. Car= rier's Carrier VRF, context forwarding label. --Bruno From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Monday, May 16, 2016 2:41 AM To: DECRAENE Bruno IMT/OLN; spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - After rereading your post, I think I missed part of what you were trying to= say. Topology was introduced because it is expected (indeed even REQUIRED) that = the same prefix would have a different SID in different topologies. This is= why for the purposes of determining "prefix conflict" (different SIDs for = the same prefix) only entries for the same topology (and algorithm) are com= pared. However, for the purposes of determining "SID conflicts" (different= entries in the database using the same SID) we MUST compare entries in all= topologies since the label database on a router is a shared resource. This= leads to the following case: VPN1: (192.0.2.1/32, 100, 1, 1, 0) VPN2: (192.0.2.1/32, 100, 1, 2, 0) Under the current preference rule defined in the draft these two entries ar= e considered "identical" - but in fact they are not since they are differen= t topologies (i.e. different FECs). However, since (as I think Robert was p= ointing out in his recent email) topology ids/VPN IDs are not global in sco= pe they cannot be used as a tie breaker (nor does the draft suggest that sh= ould be). This leads to the following amendment to the preference rule (inc= luding some of your suggested changes): 1. Smaller range wins 2. IPv6 entry wins over IPv4 entry 3. Longer prefix length wins 4. Smaller algorithm wins 5. Smaller starting address (considered as an unsigned integer value) wins 6. Smaller starting SID wins 7. If topology IDs are NOT identical both entries MUST be ignored The additional rule (#7) is applied only when doing SID conflicts as prefix= conflicts are limited to the entries in a single topology. And since we c= annot use the topology ID as a tie-breaker because the identifier has only = local scope both entries MUST be ignored. As to your statement below that: " Note that it would probably be better for the preference algo to put the = SID tie-brake before the prefix tie-break as with the prefix tie-break, we = suffer from the conflict twice (Prefix - SID mapping, then SID- prefix mapp= ing) which increase the diversity and hence the chance of not finding a val= id entry." I disagree. Prefix conflicts MUST be determined first - otherwise we risk i= gnoring an entry in another topology because it has a SID conflict with an = entry in another topology which will be ignored based on prefix conflict - = as the example I presented below demonstrates. Are we closer to agreement now? Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (gi= nsberg) Sent: Saturday, May 14, 2016 3:41 PM To: bruno.decraene@orange.com; spring@iet= f.org Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy Bruno - I am having difficulty parsing the examples you provide below as they seem = to incorporate advertisement source into the description whereas the draft = deliberately omits source. So it does not matter if R2 sends an advertiseme= nt or R12 sends advertisement or both of them do (which could happen when a= n advertisement is leaked) - what matters is what unique entries are in the= database independent of source. It would be good if you could present your examples using the format define= d in the draft i.e.: Pi - Initial prefix Pe - End prefix L - Prefix length Lx - Maximum prefix length (32 for IPv4, 128 for IPv6) Si - Initial SID value Se - End SID value R - Range value T - Topology A - Algorithm A Mapping Entry is then the tuple: (Pi/L, Si, R, T, A) Pe =3D (Pi + ((R-1) << (Lx-L)) Se =3D Si + (R-1) Example: (192.0.2.120/32, 200, 1, 0, 0) As regards your proposal - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID this to me specifies an implementation - which isn't necessary. However, there is one important point which has not been specified in the d= raft which reading your post has brought to my attention - that is the orde= r in which checks are made. The draft states: "Prefix conflicts are specific to mapping entries sharing the same topolog= y and algorithm." "SID conflicts are independent of address-family, independent of prefix le= n, independent of topology, and independent of algorithm." If we consider an example where a network supports two VPNs, the significan= ce of ordering in the evaluation of conflicts will be highlighted: VPN1: (192.0.2.1/32, 100, 1, 1, 0) (192.0.2.1/32, 200, 1, 1, 0) VPN2: (192.0.2.100/32, 200, 1, 2, 0) If we evaluate prefix conflicts first, then the following entries are "acti= ve": (192.0.2.1/32, 100, 1, 1, 0) !VPN1 (192.0.2.100/32, 200, 1, 2, 0) !VPN2 If we evaluate SID conflicts first, then the following entries are "active": (192.0.2.1/32, 100, 1, 1, 0) !VPN1 The latter choice is suboptimal because it prevents use of the VPN2 entry u= nnecessarily. This point needs to be made explicit in the draft. Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution - Policy Hi authors, all As an individual contributor, please find below some feedback on the policy. I'm wondering if we could address the conflict on a per FEC/Prefix basis ra= ther than on a per IGP advertisement basis. If so, this may avoid the discussion between the Quarantine vs ignore polic= y. The problem that we need to solve, is to find the SID for a prefix (P1). The algo could be: - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts // as a result, we get a list of SIDi - Pij for P1 Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID / no SID availa= ble for this prefix P1 Note that it would probably be better for the preference algo to put the= SID tie-brake before the prefix tie-break as with the prefix tie-break, we= suffer from the conflict twice (Prefix - SID mapping, then SID- prefix map= ping) which increase the diversity and hence the chance of not finding a va= lid entry. But for the below examples, I used the preference algo from dr= aft-ietf-*-00 Below are examples, running this policy on typical configuration error case= s. Examples 3.4.4. Network operation Consider the following simple network example: 1. 100 nodes: R1 to R100; 2. IP Loopbacks are from 192.0.2.1 to 192.0.2.100: 3. SID are from 1 to 100; 4. R1 to R50 are SR capable and advertised their own SID using Prefix-SID sub-TLV; 5. R51 to R100 are SR non-capable, running LDP and their SID are advertised by two redundant Mapping Server MS1 and MS2; 6. As the number of nodes which are SR capable are expected to increase and as in real deployment their Loopback addresses would no the contiguous, the Mapping servers advertisement covers all Loopbacks: (192.0.2.1/32, 1, 100); Subsequent sections evaluate the consequences of a single configuration error, for all conflict resolution options. 3.4.4.1. Example 1: SID configured on 1 node conflict with SID configured on another node Following a typo during configuration, R2 is configured with a SID of 12. That SID conflicts with the Prefix-SID advertised by R12 and the Ma= pping Server Advertisement for R12. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R12, a single SID is advertised and hence selected. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID12 is selected for R2. For R12, the algo evaluates a conflict between the following advertismen= ts: R12 - SID12 - R12 (prefix SID, prefix SID) R12 - SID12 - R2 (prefix SID, prefix SID) R12 - SID12 - R12 (prefix SID, MS) R12 - SID12 - R2 (MS, prefix SID) R12 - SID12 - R12 (MS, MS) Best one is R12 - SID12 - R2 (smaller range (prefix SID),smaller range (= prefix SID), smaller starting adresse (R2)) R12 <> R2 =3D=3D> R12 has no SID. 3.4.4.2. Example 2: SID configured on 1 node conflict with SID configured on the Mapping Server Following a typo during configuration, R2 is configured with a SID of 52. That SID conflicts with the Mapping Server advertisements of MS1 and MS2 for the loopback of R52. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R52, a single SID is advertised and hence selected. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID52 - R2 (prefix SID, prefix SID) R2 - SID52 - R52 (prefix SID, MS) R2 - SID2 - R2 (MS, MS) Best one is R2 - SID52 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID52 is selected for R2. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS, MS) R52 - SID52 - R2 (MS, prefix SID) Best one is R52 - SID52 - R2 (smaller range (prefix SID)) R52 <> R2 =3D=3D> R52 has no SID. 3.4.4.3. Example 3: wrong configuration of a MS Following a typo during configuration, MS1 is configured (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0 instead of 192.0.2.1). That advertisement conflicts with the Mapping Server advertisements of MS2 and the Prefix-SID advertised by R1...R50. We have a conflict for all routers except R100. For LDP only routers R51 to R99 we have a conflict between both MS adver= tisement. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS2, MS2) R52 - SID52 - R51 (MS2, MS1) R52 - SID53 - R52 (MS1, MS1) R52 - SID53 - R53 (MS1, MS2) Best one is R52 - SID52 - R51 (smaller starting address) R52 <> R51 =3D=3D> R52 has no SID. For SR routers, R1 to 50, we have a conflict between both MS advertiseme= nt and Prefix SID advertisements. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 - SID 2 - R2 (Prefix SID, MS2) R2 - SID 2 - R1 (Prefix SID, MS1) R2 - SID 2 - R2 (MS2, MS2) R2 - SID 2 - R2 (MS2, Prefix SID) R2 - SID 2 - R1 (MS2, MS1) R2 - SID 3 - R2 (MS1, MS1) R2 - SID 3 - R3 (MS1, MS2) R2 - SID 3 - R3 (MS1, Prefix SID) Best one is R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 =3D=3D R2 hence R2 use SID2. Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A0F8AC59EOPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Regardi= ng VPN, I will defer my comments for a next version of the draft which hand= les VPN/multiple FIB. In particular,

- IR= 17;m not sure about using the same term “topology” for both VPN= and IGP topology.

- I dis= agree that “label= database on a router is a shared resource”. It is a per forwarding t= able resource. You can use the same label multiple times for different meaning, if they are in a different forwarding table e.g. Ca= rrier’s Carrier VRF, context forwarding label.

&n= bsp;

--Bruno=

&n= bsp;

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.c= om]
Sent: Monday, May 16, 2016 2:41 AM
To: DECRAENE Bruno IMT/OLN; spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno &= #8211;

&n= bsp;

After r= ereading your post, I think I missed part of what you were trying to say.

&n= bsp;

Topolog= y was introduced because it is expected (indeed even REQUIRED) that the sam= e prefix would have a different SID in different topologies. This is why fo= r the purposes of determining “prefix conflict” (different SIDs for the same prefix) only entries for the = same topology (and algorithm) are compared.  However, for the purposes= of determining “SID conflicts” (different entries in the datab= ase using the same SID) we MUST compare entries in all topologies since the label database on a router is a shared resource. This= leads to the following case:

&n= bsp;

VPN1:

(192.0.= 2.1/32, 100, 1, 1, 0)

&n= bsp;

VPN2:

(192.0.= 2.1/32, 100, 1, 2, 0)

&n= bsp;

Under t= he current preference rule defined in the draft these two entries are consi= dered “identical” – but in fact they are not since they a= re different topologies (i.e. different FECs). However, since (as I think Robert was pointing out in his recent email) topology id= s/VPN IDs are not global in scope they cannot be used as a tie breaker (nor= does the draft suggest that should be). This leads to the following amendm= ent to the preference rule (including some of your suggested changes):

&n= bsp;

1. = ; Smaller range wins

2. = ; IPv6 entry wins over IPv4 entry

3. = ; Longer prefix length wins

4. Smal= ler algorithm wins

5. = ; Smaller starting address (considered as an unsigned integer

 &= nbsp;     value) wins

6. = ; Smaller starting SID wins

7. If to= pology IDs are NOT identical both entries MUST be ignored=

&n= bsp;

The add= itional rule (#7) is applied only when doing SID conflicts as prefix confli= cts are limited to the entries  in a single topology. And since we can= not use the topology ID as a tie-breaker because the identifier has only local scope both entries MUST be ignored.

&n= bsp;

As to y= our statement below that:

&n= bsp;

“ Note that it would probably be better for = the preference algo to put the SID tie-brake before the prefix tie-break as= with the prefix tie-break, we suffer from the conflict twice (Prefix - SID mapping, then SID- prefix mapping) which incr= ease the diversity and hence the chance of not finding a valid entry.”= ;

&n= bsp;

I disag= ree. Prefix conflicts MUST be determined first – otherwise we risk ig= noring an entry in another topology because it has a SID conflict with an e= ntry in another topology which will be ignored based on prefix conflict – as the example I presented below demonstr= ates.

&n= bsp;

Are we = closer to agreement now?

&n= bsp;

 &= nbsp; Les

&n= bsp;

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Les Ginsberg (ginsberg)
Sent: Saturday, May 14, 2016 3:41 PM
To: bruno.decraene@orange.com; spring= @ietf.org
Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy=

 

Bruno &= #8211;

&n= bsp;

I am ha= ving difficulty parsing the examples you provide below as they seem to inco= rporate advertisement source into the description whereas the draft deliber= ately omits source. So it does not matter if R2 sends an advertisement or R12 sends advertisement or both of them do= (which could happen when an advertisement is leaked) – what matters = is what unique entries are in the database independent of source.

&n= bsp;

It woul= d be good if you could present your examples using the format defined in th= e draft i.e.:

&n= bsp;

    Pi - Initial prefix<= /span>

     Pe - End prefix

     L -  Prefix length

     Lx - Maximum prefix lengt= h (32 for IPv4, 128 for IPv6)

     Si - Initial SID value

     Se - End SID value

     R -  Range value

     T - Topology

     A - Algorithm<= /span>

 

     A Mapping Entry is then t= he tuple: (Pi/L, Si, R, T, A)

     Pe =3D (Pi + ((R-1) << (Lx-L= ))

     Se =3D Si + (R-1)<= /i>

 

Example:     (192.0.2.120/32, = 200, 1, 0, 0)

&n= bsp;

As rega= rds your proposal

&n= bsp;

- Find all SIDi advertised for the prefix P1 =             &nb= sp;            =             &nb= sp;            =         // identification of Prefix conf= licts

        &n= bsp;       - For each SIDi find all the prefi= x Pij associated with SIDi         =      // identification of SID conflicts=

 

Get the best as per the preference algorithm.=

If best Pij =3D=3D P1

        &n= bsp;       then use SIDij for P1

        &n= bsp;       else return no SID      = ;            &n= bsp;      

&n= bsp;

this to= me specifies an implementation – which isn’t necessary.

&n= bsp;

However= , there is one important point which has not been specified in the draft wh= ich reading your post has brought to my attention – that is the order= in which checks are made.

The dra= ft states:

&n= bsp;

“= Prefix conflicts are specific to mapping entries sharing  the same top= ology and algorithm.”

“= SID conflicts are independent of address-family,  independent of prefi= x len, independent of topology, and independent  of algorithm.”<= o:p>

&n= bsp;

If we c= onsider an example where a network supports two VPNs, the significance of o= rdering in the evaluation of conflicts will be highlighted:

&n= bsp;

VPN1:

(192.0.= 2.1/32, 100, 1, 1, 0)

(192.0.= 2.1/32, 200, 1, 1, 0)

&n= bsp;

&n= bsp;

VPN2:

&n= bsp;

(192.0.= 2.100/32, 200, 1, 2, 0)

&n= bsp;

If we e= valuate prefix conflicts first, then the following entries are “activ= e”:

(192.0.= 2.1/32, 100, 1, 1, 0) !VPN1

(192.0.= 2.100/32, 200, 1, 2, 0) !VPN2

&n= bsp;

If we e= valuate SID conflicts first, then the following entries are “active&#= 8221;:

(192.0.= 2.1/32, 100, 1, 1, 0) !VPN1

&n= bsp;

The lat= ter choice is suboptimal because it prevents use of the VPN2 entry unnecess= arily.

&n= bsp;

This po= int needs to be made explicit in the draft.

&n= bsp;

 &= nbsp;  Les

&n= bsp;

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution - Policy

 

Hi authors, all

 

As an individual contributor, p= lease find below some feedback on the policy.

 

I'm wondering if we could addre= ss the conflict on a per FEC/Prefix basis rather than on a per IGP advertis= ement basis.

If so, this may avoid the discu= ssion between the Quarantine vs ignore policy.

 

The problem that we need to sol= ve, is to find the SID for a prefix (P1).

The algo could be:

- Find all SIDi advertised for = the prefix P1          &n= bsp;            = ;            &n= bsp;            = ;           // identifica= tion of Prefix conflicts

     &= nbsp;          - For each SIDi= find all the prefix Pij associated with SIDi     =          // identification of SID c= onflicts

 

// as a result, we get a list o= f SIDi – Pij for P1

 

Get the best as per the prefere= nce algorithm.

If best Pij =3D=3D P1

     &= nbsp;          then use SIDij = for P1

     &= nbsp;          else return no = SID            =             &nb= sp; / no SID available for this prefix P1

 

     &= nbsp;         

   Note that it would= probably be better for the preference algo to put the SID tie-brake before= the prefix tie-break as with the prefix tie-break, we suffer from the conf= lict twice (Prefix - SID mapping, then SID- prefix mapping) which increase the diversity and hence the chance of not finding = a valid entry.   But for the below examples, I used the preferenc= e algo from draft-ietf-*-00

     &= nbsp;         

 

Below are examples, running thi= s policy on typical configuration error cases.   

Examples

3.4.4.  Network operation<= o:p>

 

   Consider the follo= wing simple network example:

 

   1.  100 nodes= : R1 to R100;

 

   2.  IP Loopba= cks are from 192.0.2.1 to 192.0.2.100:

 

   3.  SID are f= rom 1 to 100;

 

   4.  R1 to R50= are SR capable and advertised their own SID using

     &= nbsp; Prefix-SID sub-TLV;

 

   5.  R51 to R1= 00 are SR non-capable, running LDP and their SID are

      =  advertised by two redundant Mapping Server MS1 and MS2;

 

   6.  As the nu= mber of nodes which are SR capable are expected to

     &= nbsp; increase and as in real deployment their Loopback addresses would

     &= nbsp; no the contiguous, the Mapping servers advertisement covers all<= /o:p>

     &= nbsp; Loopbacks: (192.0.2.1/32, 1, 100);

 

   Subsequent section= s evaluate the consequences of a single

   configuration erro= r, for all conflict resolution options.

 

3.4.4.1.  Example 1: SID c= onfigured on 1 node conflict with SID

     &= nbsp;    configured on another node

 

   Following a typo d= uring configuration, R2 is configured with a SID of

   12.  That SID= conflicts with the Prefix-SID advertised by R12 and the Mapping Server Adv= ertisement for R12.

   Note: both MS adve= rtisement are the same, so we only consider one in the below analysis.=

   =

   All prefix bu= t R2 and R12, a single SID is advertised and hence selected.

   =

   For R2, the a= lgo evaluates a conflict between the following advertisments:

   R2 - SID2 - R2 (MS= , MS)

   R2 - SID12 - R12 (= prefix SID, MS)

   R2 - SID12 - = R2  (prefix SID, prefix SID)

   =

   

   Best one is R= 2 - SID12 - R2 (smaller range (prefix SID),smaller range (prefix SID))=

   =3D=3D> SID12 i= s selected for R2.

   =

   For R12, the = algo evaluates a conflict between the following advertisments:

   R12 - SID12 - R12 = (prefix SID, prefix SID)

   R12 - SID12 - R2&n= bsp; (prefix SID, prefix SID)

   R12 - SID12 - R12 = (prefix SID, MS)

   R12 - SID12 - R2&n= bsp; (MS, prefix SID)

   R12 - SID12 - R12 = (MS, MS)

   =

   Best one is R= 12 - SID12 - R2 (smaller range (prefix SID),smaller range (prefix SID), sma= ller starting adresse (R2))

   R12 <> = R2 =3D=3D> R12 has no SID.

   =

   3.4.4.2. = ; Example 2: SID configured on 1 node conflict with SID

     &= nbsp;    configured on the Mapping Server<= /p>

 

   Following a typo d= uring configuration, R2 is configured with a SID of

   52.  That SID= conflicts with the Mapping Server advertisements of MS1<= /p>

   and MS2 for the lo= opback of R52.

   Note: both MS adve= rtisement are the same, so we only consider one in the below analysis.=

   =

   All prefix bu= t R2 and R52, a single SID is advertised and hence selected.

   =

   For R2, the a= lgo evaluates a conflict between the following advertisments:

   R2 - SID52 - R2&nb= sp; (prefix SID, prefix SID)

   R2 - SID52 - R52 (= prefix SID, MS)

   R2 - SID2  - = R2  (MS, MS)

   =

   Best one is R= 2 - SID52 - R2 (smaller range (prefix SID),smaller range (prefix SID))=

   =3D=3D> SID52 i= s selected for R2.

   =

   For R52, the = algo evaluates a conflict between the following advertisments:

   R52 - SID52 - R52 = (MS, MS)

   R52 - SID52 - R2&n= bsp; (MS, prefix SID)

   =

   Best one is R= 52 - SID52 - R2 (smaller range (prefix SID))

   R52 <> R2 = =3D=3D> R52 has no SID.

   =

   

3.4.4.3.  Example 3: wrong= configuration of a MS

 

   Following a typo d= uring configuration, MS1 is configured

   (192.0.2.0/32, 1, = 100). (i.e. 192.0.2.0 instead of 192.0.2.1).  That

   advertisement conf= licts with the Mapping Server advertisements of MS2

   and the Prefix-SID= advertised by R1...R50.

   =

   We have a con= flict for all routers except R100.

   =

   For LDP only = routers R51 to R99 we have a conflict between both MS advertisement.

   For R52, the algo = evaluates a conflict between the following advertisments:=

   R52 - SID52 - R52 = (MS2, MS2)

   R52 - SID52 - R51 = (MS2, MS1)

   R52 - SID53 - R52 = (MS1, MS1)

   R52 - SID53 - R53 = (MS1, MS2)

 

   Best one is R52 - = SID52 - R51 (smaller starting address)

   R52 <> R51 = =3D=3D> R52 has no SID.

   =

   For SR router= s, R1 to 50, we have a conflict between both MS advertisement and Prefix SI= D advertisements.

   For R2, the algo e= valuates a conflict between the following advertisments:<= /p>

   R2 - SID 2 - R2 (P= refix SID, Prefix SID)

   R2 - SID 2 - R2 (P= refix SID, MS2)

   R2 - SID 2 - R1 (P= refix SID, MS1)

   R2 - SID 2 - R2 (M= S2, MS2)

   R2 - SID 2 - R2 (M= S2, Prefix SID)

   R2 - SID 2 - R1 (M= S2, MS1)

   R2 - SID 3 - R2&nb= sp; (MS1, MS1)

   R2 - SID 3 - R3&nb= sp; (MS1, MS2)

   R2 - SID 3 - R3&nb= sp; (MS1, Prefix SID)

   =

   Best one is R= 2 - SID 2 - R2 (Prefix SID, Prefix SID)

   R2 =3D=3D R2 hence= R2 use SID2.

 

Regards,

Bruno

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=

Thank you.
______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A0F8AC59EOPEXCLILM21corp_-- From nobody Wed May 18 05:05:30 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA31C12D0EF for ; Wed, 18 May 2016 05:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qdiSfOwFNxe for ; Wed, 18 May 2016 05:05:26 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor36.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 3229C12D0EA for ; Wed, 18 May 2016 04:57:29 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id A44D9C062A; Wed, 18 May 2016 13:57:27 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 6205A400B1; Wed, 18 May 2016 13:57:27 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0294.000; Wed, 18 May 2016 13:57:27 +0200 From: To: "Les Ginsberg (ginsberg)" , "Peter Psenak (ppsenak)" , Uma Chunduri , "Stefano Previdi (sprevidi)" Thread-Topic: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call Thread-Index: AQHRp9QzkgSuIqgH0E6x+32lpWBGFp+z+Y4AgAH3/YCAAAOcAIAABKyAgADdIoCAAd0sgIAEoPqA Date: Wed, 18 May 2016 11:57:27 +0000 Message-ID: <18901_1463572647_573C58A7_18901_707_1_53C29892C857584299CBF5D05346208A0F8AC5A5@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <15416_1460620235_570F4BCB_15416_2090_1_53C29892C857584299CBF5D05346208A0F86E415@OPEXCLILM21.corporate.adroot.infra.ftgroup> <10411_1460620508_570F4CDC_10411_96_23_53C29892C857584299CBF5D05346208A0F86E45F@OPEXCLILM21.corporate.adroot.infra.ftgroup> <1B502206DFA0C544B7A6046915200863580C54E9@eusaamb105.ericsson.se> <0468fb2fe35841668bc35606e988074c@XCH-ALN-001.cisco.com> <1B502206DFA0C544B7A60469152008635BCD31AB@eusaamb106.ericsson.se> <445eeb6f8f12480f90e941a81eeaafc7@XCH-ALN-001.cisco.com> <1B502206DFA0C544B7A60469152008635BCDFEFB@eusaamb106.ericsson.se> <1B502206DFA0C544B7A60469152008635BCE586E@eusaamb106.ericsson.se> <5734C54A.2050102@cisco.com> <1B502206DFA0C544B7A60469152008635BCE58AB@eusaamb106.ericsson.se> <573582B5.1010803@cisco.com> <1d9fe3f3508d4fb28bd02b9f23460ccb@XCH-ALN-001.cisco.com> In-Reply-To: <1d9fe3f3508d4fb28bd02b9f23460ccb@XCH-ALN-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] draft-ginsberg-spring-conflict-resolution - WG adoption call X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 12:05:29 -0000 SGkgTGVzLA0KDQpQbGVhc2Ugc2VlIGlubGluZS4NCg0KDQo+IEZyb206IExlcyBHaW5zYmVyZyAo Z2luc2JlcmcpIFttYWlsdG86Z2luc2JlcmdAY2lzY28uY29tXSA+IFNlbnQ6IFNhdHVyZGF5LCBN YXkgMTQsIDIwMTYgNzowNCBQTQ0KPiANCj4gVW1hIC0NCj4gDQo+IEknZCBsaWtlIHRvIGNsb3Nl IHRoaXMgcG9pbnQgb2YgZGlzY3Vzc2lvbiBhcyByZWdhcmRzIHRoZSBjb25mbGljdC1yZXNvbHV0 aW9uIGRyYWZ0Lg0KPiANCj4gRm9yIHRoZSByZWNvcmQsIEkgYWdyZWUgd2l0aCBQZXRlci4gQnV0 IGZyb20gdGhlIHN0YW5kcG9pbnQgb2YgY29uZmxpY3QNCj4gcmVzb2x1dGlvbiBpdCBtYXR0ZXJz IG5vdCBmb3Igd2hhdCBwdXJwb3NlIFNSTVMgaXMgYmVpbmcgdXNlZA0KDQpJbiBvcmRlciBmb3Ig YWxsIG5vZGVzIHRvIGNvbnNpZGVyIHRoZSBzYW1lIFNSIGRhdGEgZHVyaW5nIHRoZSBTUi1jb25m bGljdCBhbGdvLCB3aGF0IG1hdHRlcnMgaXMgd2hldGhlciBhbGwgbm9kZSB3aXRoaW4gYSBkb21h aW4gTVVTVCBzdXBwb3J0IFNSTVMgb3Igbm90LC4NClNvIDIgb3B0aW9uczoNCi0gU1JNUyBpcyBt YW5kYXRhcnkgdG8gaW1wbGVtZW50IG9yIHRvIGRlcGxveSBjb25zaXN0ZW50bHksIGFuZCB0aGlz IG5lZWQgdG8gYmUgc3RhdGVkIHNvbWV3aGVyZSwgZS5nLiBpbiBzcHJpbmctY29uZmxpY3QtcmVz b2x1dGlvbi4gKGUuZy4gaW4gdGhlIGVhcmx5IGRheXMsIHRoaXMgd2FzIG5vdCB0aGUgY2FzZSBm b3IgYWxsIGltcGxlbWVudGF0aW9ucykNCi0gdGhlIFNSLWNvbmZsaWN0IGFsZ28gaXMgZGVmaW5l ZCBpbiBhIHdheSB0byBnaXZlIHRoZSBzYW1lIHJlc3VsdCwgZm9yIGEgUHJlZml4LVNJRCwgd2l0 aCBwYXJ0aWFsIFNSTVMgZGVwbG95bWVudC4gVGhpcyBtYXkgYmUgZmVhc2libGUgaXMgU0lELVBy ZWZpeCBpbmZvIGFyZSBnaXZlbiBzdHJpY3QgcHJpb3JpdHkgb3ZlciBTUk1TLg0KDQpUaGFua3Ms DQotLUJydW5vDQoNCj4gLSB3ZSBoYXZlIHRvDQo+IGNvbnNpZGVyIFNSTVMgYWR2ZXJ0aXNlbWVu dHMgYXMgd2VsbCBhcyBTSURzIGFzc29jaWF0ZWQgdyBwcmVmaXgNCj4gYWR2ZXJ0aXNlbWVudHMu IEkgaG9wZSB0aGF0IHBvaW50IGhhcyBiZWVuIGNsZWFybHkgZXhwbGFpbmVkLg0KPiANCj4gSWYg eW91IHdpc2ggdG8gY29udGludWUgdGhlIGRpc2N1c3Npb24gd2l0aCB0aGUgYXJjaGl0ZWN0dXJl IGRyYWZ0IGF1dGhvcnMgYXMNCj4gdG8gd2hldGhlciBmdXJ0aGVyIGRpc2N1c3Npb24gb2YgU1JN UyBhcyBhIG5ldHdvcmsgcHJvdmlzaW9uaW5nIHRvb2wNCj4gc2hvdWxkL3Nob3VsZCBub3QgYmUg YWRkZWQgdG8gYSBkb2N1bWVudCBwbGVhc2UgZmVlbCBmcmVlIHRvIGRvIHNvIC0gYnV0IEkNCj4g d291bGQgYXNrIHRoYXQgeW91IGRvIHNvIGluIGFub3RoZXIgdGhyZWFkLg0KPiBUaGFueC4NCj4g DQo+ICAgIExlcw0KPiANCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBG cm9tOiBQZXRlciBQc2VuYWsgKHBwc2VuYWspDQo+ID4gU2VudDogRnJpZGF5LCBNYXkgMTMsIDIw MTYgMTI6MzEgQU0NCj4gPiBUbzogVW1hIENodW5kdXJpOyBTdGVmYW5vIFByZXZpZGkgKHNwcmV2 aWRpKQ0KPiA+IENjOiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKTsgc3ByaW5nQGlldGYub3JnOyBi cnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tDQo+ID4gU3ViamVjdDogUmU6IFtzcHJpbmddIGRyYWZ0 LWdpbnNiZXJnLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9uIC0gV0cNCj4gYWRvcHRpb24NCj4g PiBjYWxsDQo+ID4NCj4gPiBVbWEsDQo+ID4NCj4gPiBJIGRvbid0IGtub3cgd2hldGhlciB5b3Ug bmVlZCBhIHRleHQgaW4gdGhlIGRyYWZ0L1JGQyB0byB1c2Ugc29tZQ0KPiA+IGZ1bmN0aW9uYWxp dHkgb25lIHdheSBvciB0aGUgb3RoZXIuIFRoZSBmYWN0IGlzIHRoYXQgU1JNUyBpcyBhIFNJRA0K PiBwcm92aXNpb25pbmcNCj4gPiB0b29sLiBZb3UgY2FuIHVzZSBpdCBmb3IgU1IvTERQIGludGVy b3BlcmFiaWxpdHksIGJ1dCB5b3UgY2FuIGFsc28gdXNlIGl0IGluIGENCj4gU1INCj4gPiBvbmx5 IG5ldHdvcmsgdG8gcHJvdmlkZSBTSURzIGZyb20gYSBjZW50cmFsIHBsYWNlIGluc3RlYWQgb2Yg Y29uZmlndXJpbmcNCj4gdGhlbQ0KPiA+IG9uIGVhY2ggZGV2aWNlLiBUaGVyZSBpcyBub3RoaW5n IHRoYXQgcHJldmVudHMgeW91IHRvIHVzZSBpdCBvbmUgd2F5IG9yIHRoZQ0KPiA+IG90aGVyLiBU aGUgZmFjdCB0aGF0IFNSTVMgaXMgZGVmaW5lZCBpbiB0aGUgU1IvTERQIGludGVyb3AgZHJmYXQg ZG9lcyBub3QNCj4gPiBtZWFuIGl0IGlzIHJlc3RyaWN0ZWQgdG8gYmUgdXNlZCBmb3IgdGhhdCBw dXJwb3NlLg0KPiA+DQo+ID4gSSBsZXQgYXV0aG9ycyBvZiB0aGUgU1IgYXJjaGl0ZWN0dXJlIGRy YWZ0cyB0byBkZWNpZGUgd2hldGhlciB0aGV5IHdhbnQgdG8NCj4gYWRkDQo+ID4gdGhlIHRleHQu IEFzIGFuIGF1dGhvciBvZiB0aGUgT1NQRiBTUiBkcmFmdCwgSSBkbyBub3Qgc2VlIGFueXRoaW5n IGluIHRoZQ0KPiB0ZXh0DQo+ID4gdGhhdCB5b3UgcHV0IGJlbG93IHRoYXQgd291bGQgY29udHJh ZGljdCB3aGF0IEknbSBzYXlpbmcgaGVyZS4NCj4gPg0KPiA+IHRoYW5rcywNCj4gPiBQZXRlcg0K PiA+DQo+ID4NCj4gPiBPbiA1LzEyLzE2IDIwOjE5ICwgVW1hIENodW5kdXJpIHdyb3RlOg0KPiA+ ID4gUGV0ZXIsDQo+ID4gPiAgICAgICAgICA+IGFzIGEgbWF0dGVyIG9mIGZhY3QsIFNSTVMgaXMg YSBTSUQgcHJvdmlzaW9uaW5nIHRvb2wsDQo+ID4gPiB3aGV0aGVyIHlvdSBsaWtlIGl0IG9yIG5v dC4NCj4gPiA+IEl0J3Mgbm90IGFib3V0IHlvdXIgb3IgbXkgbGlua2luZyAtIEkgd2FzIHRhbGtp bmcgYWJvdXQgd2hhdCdzIHRoZQ0KPiA+ID4gZGVmaW5lZCBzY29wZSBzbyBmYXIgKGFyY2hpdGVj dHVyZSBkb2Mgb3IgcHJvdG9jb2wgZG9jcykgYW5kIGhvdyB5b3UNCj4gPiA+IHdhbnQgdG8gZXh0 ZW5kIHRoZSBzY29wZS4NCj4gPiA+IFdlbGwsIGlmIHlvdSB3YW50IHRvIGV4dGVuZCB0aGUgY3Vy cmVudCBzY29wZSBvZiBTUk1TIGFzIGEgIiI+MilBcyBhDQo+ID4gPiBnbG9iYWwgcHJvdmlzaW9u aW5nIHRvb2wiIC0gUGx6LiBkbyBzbyBidXQgbm90IHdoaWxlIHByb3ZpZGluZw0KPiA+ID4gY29u ZmxpY3QgcmVzb2x1dGlvbiBzb2x1dGlvbi4NCj4gPiA+ICAgICAgICAgICAgICAgICA+IEl0IHBy b3ZpZGVzIGFsbCB0aGUgZnVuY3Rpb25hbGl0eSB0aGF0IGlzIHJlcXVpcmVkDQo+ID4gPiBmb3Ig c3VjaCBwcm92aXNpb25pbmcgdG9vbC4NCj4gPiA+ICAgICAgICAgID5Zb3UgY2FuIG5vdCByZXN0 cmljdCBpdHMgdXNhZ2UgdG8gU1IvTERQIGludGVyb3AgY2FzZS4NCj4gPiA+IEkgZGlkbid0IHJl c3RyaWN0IGFueXRoaW5nIC0gUGx6LiBzZWUgU1JNUyBzdHVmZiBzbyBmYXI6DQo+ID4gPiAxLg0K PiA+ID4gX2h0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdt ZW50LXJvdXRpbmctMDgjc2VjdA0KPiA+ID4gaW9uLTMuNl8NCj4gPiA+DQo+ID4gPiAvIiAvLzMu Ni4xLiAgTWFwcGluZyBTZXJ2ZXIvDQo+ID4gPiAvLy9BIFJlbW90ZS1CaW5kaW5nIFNJRCBTIGFk dmVydGlzZWQgYnkgdGhlIG1hcHBpbmcgc2VydmVyIE0gZm9yDQo+ID4gPiByZW1vdGUvIC8vL3By ZWZpeCBSIGF0dGFjaGVkIHRvIG5vbi1TUi1jYXBhYmxlIG5vZGUgTiBzaWduYWxzIHRoZQ0KPiA+ ID4gc2FtZS8gLy8vaW5mb3JtYXRpb24gYXMgaWYgTiBoYWQgYWR2ZXJ0aXNlZCBTIGFzIGEgUHJl Zml4LVNJRC4NCj4gPiA+IEZ1cnRoZXIvIC8vL2RldGFpbHMgYXJlIGRlc2NyaWJlZCBpbiB0aGUg U1IvTERQIGludGVyd29ya2luZw0KPiA+ID4gcHJvY2VkdXJlcy8gLy8vKFtJLUQuaWV0Zi1zcHJp bmctc2VnbWVudC1yb3V0aW5nLWxkcC1pbnRlcm9wXS4vLyIvDQo+ID4gPiAyLiBJU0lTOg0KPiA+ ID4gX2h0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1y b3V0aW5nLWV4dGVuc2lvbg0KPiA+ID4gcy0wNiNzZWN0aW9uLTIuNF8NCj4gPiA+DQo+ID4gPiAv IiAvL1RoaXMgZnVuY3Rpb25hbGl0eSBpcyBjYWxsZWQgdGhlLyAvLy8vLydNYXBwaW5nIFNlcnZl cicgYW5kIGl0J3MNCj4gPiA+IHVzZWQgd2hlbiwgaW4gYSBoZXRlcm9nZW5lb3VzIG5ldHdvcmss LyAvLy8vLy8vbm90IGFsbCBub2RlcyBhcmUNCj4gPiA+IGNhcGFibGUgb2YgYWR2ZXJ0aXNpbmcg dGhlaXIgb3duIFNJRHMvTGFiZWxzLi8vIi8gMy4gT1NQRjoNCj4gPiA+IF9odHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1vc3BmLXNlZ21lbnQtcm91dGluZy1leHRlbnNpb24N Cj4gPiA+IHMtMDgjc2VjdGlvbi00Xw0KPiA+ID4NCj4gPiA+IC8iLy8gICBJbiBzb21lIGNhc2Vz IGl0IGlzIHVzZWZ1bCB0byBhZHZlcnRpc2UgYXR0cmlidXRlcyBmb3IgYSByYW5nZSBvZi8NCj4g PiA+IC8vL3ByZWZpeGVzLiAgVGhlIFNlZ21lbnQgUm91dGluZyBNYXBwaW5nIFNlcnZlciwgd2hp Y2ggaXMgZGVzY3JpYmVkDQo+ID4gPiBpbi8gLy8vWy8vSS1ELmZpbHNmaWxzLXNwcmluZy1zZWdt ZW50LXJvdXRpbmctbGRwLWludGVyb3AvDQo+ID4gPiA8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtb3NwZi1zZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9uDQo+ID4gPiBzLTA4 Pi9dLA0KPiA+ID4gaXMgYW4gZXhhbXBsZS8NCj4gPiA+IC8vL3doZXJlIHdlIG5lZWQgYSBzaW5n bGUgYWR2ZXJ0aXNlbWVudCB0byBhZHZlcnRpc2UgU0lEcyBmb3INCj4gPiA+IG11bHRpcGxlLyAv Ly9wcmVmaXhlcyBmcm9tIGEgY29udGlndW91cyBhZGRyZXNzIHJhbmdlLi8vIi8gQWdhaW4sIHBs ei4NCj4gPiA+IGV4dGVuZCB0aGUgc2NvcGUgZmlyc3QgYW5kIGNvbnNpZGVyIHRoZSBzYW1lIGlu IHJlc29sdXRpb24gc29sdXRpb24uIEkNCj4gPiA+IGFtIGZpbmUgd2l0aCBpdC4NCj4gPiA+IC0t DQo+ID4gPiBVbWEgQy4NCj4gPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gPiBG cm9tOiBQZXRlciBQc2VuYWsgW21haWx0bzpwcHNlbmFrQGNpc2NvLmNvbV0NCj4gPiA+IFNlbnQ6 IFRodXJzZGF5LCBNYXkgMTIsIDIwMTYgMTE6MDMgQU0NCj4gPiA+IFRvOiBVbWEgQ2h1bmR1cmk7 IFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpDQo+ID4gPiBDYzogTGVzIEdpbnNiZXJnIChnaW5z YmVyZyk7IHNwcmluZ0BpZXRmLm9yZzsNCj4gPiA+IGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20N Cj4gPiA+IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBkcmFmdC1naW5zYmVyZy1zcHJpbmctY29uZmxp Y3QtcmVzb2x1dGlvbiAtIFdHDQo+ID4gPiBhZG9wdGlvbiBjYWxsIEhpIFVtYSwgT24gNS8xMi8x NiAxOTo0OSAsIFVtYSBDaHVuZHVyaSB3cm90ZToNCj4gPiA+PiBTdGVmYW5vLA0KPiA+ID4+DQo+ ID4gPj4gVGhhbmtzIGZvciB5b3VyIHJlc3BvbnNlLg0KPiA+ID4+DQo+ID4gPj4gICAgICAgID4g dXNpbmcgYSBTUk1TIGZvciBhZHZlcnRpc2luZyBTSUQgb24gYmVoYWxmIG9mIFNSIGNhcGFibGUg bm9kZXMNCj4gZG9lcw0KPiA+IG5vdCBpbnRyb2R1Y2UgYW55IGNoYW5nZSBpbiB0aGUgU1IgYXJj aGl0ZWN0dXJlIHNvIG5vdA0KPiA+ID4+ICAgICAgICAgICAgICAgICA+IHN1cmUgd2hhdCB3ZSBu ZWVkIHRvIGRvY3VtZW50IGhlcmUuDQo+ID4gPj4NCj4gPiA+PiBNeSBwb2ludCBiZWxvdzogV2Ug YXJlIGNyZWF0aW5nIGEgY29uZmxpY3QgcmVzb2x1dGlvbiBzb2x1dGlvbiBmb3IgYSBub24tDQo+ ID4gZXhpc3RpbmcgcmVxdWlyZW1lbnQgb2YgdXNpbmcgIFNSTVMgdml6LiwgICI+MilBcyBhIGds b2JhbCBwcm92aXNpb25pbmcgdG9vbCIuDQo+ID4gPj4gIEZyb20geW91ciBzdGF0ZW1lbnQgYWJv dmUsIGl0IHNlZW1zIHlvdSBoYXZlIGxlc3MgaW50ZXJlc3QgdG8gbWFrZQ0KPiB0aGlzDQo+ID4g YXMgYSByZXF1aXJlbWVudC9zY29wZSBvZiBTUk1TOyBJIGFtIG1vcmUgYWxpZ25lZCBpbiB0aGF0 IHBhdGguLi4uDQo+ID4gPiBhcyBhIG1hdHRlciBvZiBmYWN0LCBTUk1TIGlzIGEgU0lEIHByb3Zp c2lvbmluZyB0b29sLCB3aGV0aGVyIHlvdSBsaWtlDQo+ID4gPiBpdCBvciBub3QuIEl0IHByb3Zp ZGVzIGFsbCB0aGUgZnVuY3Rpb25hbGl0eSB0aGF0IGlzIHJlcXVpcmVkIGZvciBzdWNoDQo+ID4g PiBwcm92aXNpb25pbmcgdG9vbC4gWW91IGNhbiBub3QgcmVzdHJpY3QgaXRzIHVzYWdlIHRvIFNS L0xEUCBpbnRlcm9wIGNhc2UuDQo+ID4gPiB0aGFua3MsDQo+ID4gPiBQZXRlcg0KPiA+ID4+DQo+ ID4gPj4gT24gdGhlIHNlY29uZCBwb2ludDoNCj4gPiA+Pg0KPiA+ID4+ICAgICAgICA+IHRoZSBh cmNoaXRlY3R1cmUgZHJhZnQgaXMgZGF0YS1wYW5lIGFnbm9zdGljIHNvIEkgcHJlc3VtZSB5b3Ug cmVmZXINCj4gPiB0byBkcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscy4NCj4g PiA+Pg0KPiA+ID4+IEFGQUlTLGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXNwcmluZy1zZWdtZW50LXJvdXRpbmctMA0KPiA+ID4+IDggIHRhbGtzDQo+ID4gPiBhYm91dCBi b3RoIGRhdGEgcGxhbmVzIHJpZ2h0IGZyb20gYWJzdHJhY3QgdG8gbXVsdGlwbGUgcGxhY2VzICh3 aGljaA0KPiA+ID4gaXQgb3VnaHQgdG8pLg0KPiA+ID4+IEkgbGVhdmUgdGhpcyB0byB5b3UvV0cg b24gd2hlcmUgeW91IHdhbnQgdG8gZG9jdW1lbnQgdGhpcyAtYnV0IElNTw0KPiA+ID4+IGNvbmZs aWN0IHJlc29sdXRpb24gInNvbHV0aW9uIGRvY3VtZW50IiBpbiB0aGUgY3VycmVudCBmb3JtIHBv dGVudGlhbGx5DQo+ID4gaW50cm9kdWNpbmcgZnVuZGFtZW50YWwgcmVxdWlyZW1lbnRzICB0byB0 aGUgc3lzdGVtIGxpa2UgY3Jvc3MgcHJvdG9jb2wNCj4gPiB2ZXJpZmljYXRpb24gKHdpdGggaW4v YWNyb3NzIEFTKS4gUGVyaGFwcyBzb21lIGRpc2N1c3Npb24gc2hvdWxkIGJlIHRoZXJlIGluDQo+ ID4gZGF0YSBwbGFuZSBkb2N1bWVudCB0aGVuLg0KPiA+ID4+DQo+ID4gPj4gLS0NCj4gPiA+PiBV bWEgQy4NCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gPiA+PiBGcm9tOiBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKSBbbWFpbHRvOnNwcmV2aWRp QGNpc2NvLmNvbV0NCj4gPiA+PiBTZW50OiBXZWRuZXNkYXksIE1heSAxMSwgMjAxNiA0OjQ2IEFN DQo+ID4gPj4gVG86IFVtYSBDaHVuZHVyaQ0KPiA+ID4+IENjOiBMZXMgR2luc2JlcmcgKGdpbnNi ZXJnKTticnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tDQo+ID4gPj48bWFpbHRvOmJydW5vLmRlY3Jh ZW5lQG9yYW5nZS5jb20+Ow0KPiA+ID4+c3ByaW5nQGlldGYub3JnIDxtYWlsdG86c3ByaW5nQGll dGYub3JnPg0KPiA+ID4+IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBkcmFmdC1naW5zYmVyZy1zcHJp bmctY29uZmxpY3QtcmVzb2x1dGlvbiAtIFdHDQo+ID4gPj5hZG9wdGlvbiBjYWxsDQo+ID4gPj4N Cj4gPiA+Pg0KPiA+ID4+PiBPbiBNYXkgNiwgMjAxNiwgYXQgMTA6MTYgUE0sIFVtYSBDaHVuZHVy aQ0KPiA+IDx1bWEuY2h1bmR1cmlAZXJpY3Nzb24uY29tIDxtYWlsdG86dW1hLmNodW5kdXJpQGVy aWNzc29uLmNvbT4+DQo+ID4gd3JvdGU6DQo+ID4gPj4+DQo+ID4gPj4+IExlcywNCj4gPiA+Pj4N Cj4gPiA+Pj4gMiBxdWljayB0aGluZ3MuDQo+ID4gPj4+DQo+ID4gPj4+IDEuDQo+ID4gPj4+ICAg ICAgICAgICAgICA+W0xlczpdIFRoZXJlIGFyZSB0d28gbGVnaXRpbWF0ZSB1c2UgY2FzZXMgZm9y IFNSTVM6DQo+ID4gPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgPjEpVG8gYWR2ZXJ0aXNlIFNJRHMgZm9yIG5vbi1TUiBjYXBhYmxlIG5vZGVzDQo+ID4gPj4+ ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPjIpQXMgYSBnbG9i YWwgcHJvdmlzaW9uaW5nIHRvb2wNCj4gPiA+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgICBJ IGFtIGhlYXJpbmcgIzIgZm9yIHRoZSBmaXJzdCB0aW1lLiBJDQo+ID4gPj4+ZG9u4oCZdCBzZWUg dGhpcyBlaXRoZXIgIGRpc2N1c3NlZCBlYXJsaWVyIGluIHRoZSBXRyBsaXN0ICBvciBjYXB0dXJl ZA0KPiA+ID4+PmluIGFyY2hpdGVjdHVyZSBkb2N1bWVudA0KPiA+ID4+Pmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmluZy1zZWdtZW50LXJvdXRpbmctMDcuDQo+ID4g Pj4+RXZlbg0KPiA+ID4gaW4gdGhlIHByb3RvY29sIGV4dGVuc2lvbnMgZG9jdW1lbnQgZm9yIGV4 YW1wbGUNCj4gPiA+Pj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pc2lz LXNlZ21lbnQtcm91dGluZy1leHRlbnNpb24NCj4gPiA+Pj5zLTA2I3NlY3Rpb24tMi40DQo+ID4g PiB3ZSBhbHdheXMgZGlzY3Vzc2VkIHRoaXMgZnJvbSBub24tU1INCj4gPiA+Pj4gICAgICAgICAg ICAgICAgICAgICAgICAgICBjYXBhYmxlIG5vZGVzIFBvVi4gU28gSSByZXF1ZXN0IHRvIGFkZCB0 aGlzIGluIGFyY2hpdGVjdHVyZQ0KPiA+IGRvY3VtZW50IGJlZm9yZSBmYWN0b3JpbmcgdGhpcyBm b3Igc29sdXRpb24gaW4gY29uZmxpY3QgcmVzb2x1dGlvbi4NCj4gPiA+Pg0KPiA+ID4+DQo+ID4g Pj4gdXNpbmcgYSBTUk1TIGZvciBhZHZlcnRpc2luZyBTSUQgb24gYmVoYWxmIG9mIFNSIGNhcGFi bGUgbm9kZXMgZG9lcyBub3QNCj4gPiBpbnRyb2R1Y2UgYW55IGNoYW5nZSBpbiB0aGUgU1IgYXJj aGl0ZWN0dXJlIHNvIG5vdCBzdXJlIHdoYXQgd2UgbmVlZCB0bw0KPiA+IGRvY3VtZW50IGhlcmUu DQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4+DQo+ID4gPj4+IDIuICAgICAgIEFsc28g dGhpcyBpcyB0aGUgZmlyc3QgdGltZSBldmVyIHdlIGhhdmUgYSByZXF1aXJlbWVudCBmb3IgY3Jv c3MNCj4gPiBwcm90b2NvbHMgdmVyaWZpY2F0aW9uIHdlIG91Z2h0IHRvIGRpc2N1c3MgdGhlIGlt cGxpY2F0aW9ucyBvZiB0aGlzDQo+ID4gPj4+IGFuZCBwcm90b2NvbHMgaW52b2x2ZWQgKHdpdGgg aW4gQVMgb3Igb3RoZXJ3aXNlKSBpbiB0aGUgYXJjaGl0ZWN0dXJlDQo+ID4gZG9jdW1lbnQgKGF0 IGxlYXN0IGJyaWVmbHkpLg0KPiA+ID4+DQo+ID4gPj4NCj4gPiA+PiB0aGUgYXJjaGl0ZWN0dXJl IGRyYWZ0IGlzIGRhdGEtcGFuZSBhZ25vc3RpYyBzbyBJIHByZXN1bWUgeW91IHJlZmVyIHRvDQo+ ID4gZHJhZnQtaWV0Zi1zcHJpbmctc2VnbWVudC1yb3V0aW5nLW1wbHMuDQo+ID4gPj4NCj4gPiA+ PiB3aXRoIHRoZSBpcHY2IGRhdGEtcGxhbmUgU1IgY29uZmxpY3RzIGFyZSBpbiBmYWN0IHNvbHZl ZCBieSBpcHY2DQo+ID4gPj4gYWRkcmVzc2luZyB0ZWNobmlxdWVzIDstKQ0KPiA+ID4+DQo+ID4g Pj4gcy4NCj4gPiA+Pg0KPiA+ID4+DQo+ID4gPj4+DQo+ID4gPj4+IC0tDQo+ID4gPj4+IFVtYSBD Lg0KPiA+ID4+Pg0KPiA+ID4+PiBGcm9tOiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIExlcw0KPiA+ID4+PiBHaW5zYmVyZyAoZ2luc2JlcmcpDQo+ ID4gPj4+IFNlbnQ6IFdlZG5lc2RheSwgTWF5IDA0LCAyMDE2IDk6MzggQU0NCj4gPiA+Pj4gVG86 IFVtYSBDaHVuZHVyaTticnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tDQo+ID4gPj4+IDxtYWlsdG86 YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbT47DQo+ID4gPiBzcHJpbmdAaWV0Zi5vcmcgPG1haWx0 bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ID4gPj4+IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBkcmFmdC1n aW5zYmVyZy1zcHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbiAtIFdHDQo+ID4gPj4+IGFkb3B0aW9u IGNhbGwNCj4gPiA+Pj4NCj4gPiA+Pj4gVW1hIOKAkw0KPiA+ID4+Pg0KPiA+ID4+PiBUbyByZXN0 YXRlLCB0aGUgcHJvYmxlbSBiZWluZyBhZGRyZXNzZWQgaGVyZSBpcyB0byBndWFyYW50ZWUNCj4g PiA+Pj4gY29uc2lzdGVudCB1c2Ugb2YgU0lEcyBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZSBuZXR3 b3JrLXdpZGUgaW4gdGhlDQo+ID4gPj4+IHByZXNlbmNlIG9mIGNvbmZsaWN0aW5nIGFkdmVydGlz ZW1lbnRzLiBUaGUgc2V0IG9mIGFkdmVydGlzZW1lbnRzDQo+ID4gPj4+IGluY2x1ZGVzIGJvdGgg U0lEcyBhZHZlcnRpc2VkIGluIHByb3RvY29sIHByZWZpeCByZWFjaGFiaWxpdHkNCj4gPiA+Pj4g YWR2ZXJ0aXNlbWVudHMgYW5kIFNSTVMgYWR2ZXJ0aXNlbWVudHMgYmVjYXVzZSBwcm9ibGVtcyBv Y2N1cg0KPiA+IGJhc2VkDQo+ID4gPiB1cG9uIGluY29uc2lzdGVuY2llcyBpbiB3aGF0IGlzIGlu c3RhbGxlZCBpbiB0aGUgZm9yd2FyZGluZyBwbGFuZSBvZg0KPiA+ID4gZGlmZmVyZW50IHJvdXRl cnMuIEl0IG1hdHRlcnMgbm90IHdoZXRoZXIgUm91dGVyIEEgdXNlZCBhIFNJRA0KPiA+ID4gYWR2 ZXJ0aXNlZCBieSBhIHByb3RvY29sIHByZWZpeCByZWFjaGFiaWxpdHkgYWR2ZXJ0aXNlbWVudCBv ciBieSBhbg0KPiA+ID4gU1JNUyBhZHZlcnRpc2VtZW50IOKAkyB3aGF0IG1hdHRlciBpcyB3aGV0 aGVyIHRoZSBTSUQgdXNlZCBpcyBjb25zaXN0ZW50DQo+ID4gPiB3aXRoIHdoYXQgdGhlIG5laWdo Ym9ycyBvZiBSb3V0ZXIgQSB1c2UuIFNvIHNpbXBseSBlbnN1cmluZyB0aGF0IE9TUEYNCj4gPiA+ IChmb3INCj4gPiA+IGV4YW1wbGUpIHJlc29sdmVzIFNJRHMgaW4gYSBjb25zaXN0ZW50IHdheSBk b2VzIG5vdCBmdWxseSBhZGRyZXNzIHRoZQ0KPiA+ID4gcHJvYmxlbSBzcGFjZS4NCj4gPiA+Pj4N Cj4gPiA+Pj4gTW9yZSBpbmxpbmUuDQo+ID4gPj4+DQo+ID4gPj4+IEZyb206IFVtYSBDaHVuZHVy aSBbbWFpbHRvOnVtYS5jaHVuZHVyaUBlcmljc3Nvbi5jb21dDQo+ID4gPj4+IFNlbnQ6IFR1ZXNk YXksIE1heSAwMywgMjAxNiAzOjU5IFBNDQo+ID4gPj4+IFRvOiBMZXMgR2luc2JlcmcgKGdpbnNi ZXJnKTticnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tDQo+ID4gPj4+PG1haWx0bzpicnVuby5kZWNy YWVuZUBvcmFuZ2UuY29tPjsNCj4gPiA+Pj5zcHJpbmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJpbmdA aWV0Zi5vcmc+DQo+ID4gPj4+IFN1YmplY3Q6IFJFOiBbc3ByaW5nXSBkcmFmdC1naW5zYmVyZy1z cHJpbmctY29uZmxpY3QtcmVzb2x1dGlvbiAtIFdHDQo+ID4gPj4+YWRvcHRpb24gY2FsbA0KPiA+ ID4+Pg0KPiA+ID4+PiBMZXMsDQo+ID4gPj4+DQo+ID4gPj4+IFdpdGggYWxsIGR1ZSByZXNwZWN0 cywgY3Jvc3MgcHJvdG9jb2wgdmVyaWZpY2F0aW9uICBvZiBwcmVmaXggYW5kIFNJRA0KPiA+IGNv bmZsaWN0cyBhcyBhbiDigJxhcmNoaXRlY3R1cmFsIGNoYW5nZeKAnSAgYW5kIGl0IGNhbiBzZXZl cmVseSBpbXBhY3QgdGhlIGV4aXN0aW5nDQo+ID4gaW1wbGVtZW50YXRpb25zIChhdCBsZWFzdCB0 aGUgb25lIEkgd29yayBvbikuDQo+ID4gPj4+DQo+ID4gPj4+IFtMZXM6XSBJdCBpcyBxdWl0ZSBj b3JyZWN0IOKAkyBhbmQgSSBjYW4gY29uZmlybSBiYXNlZCBvbiBwZXJzb25hbA0KPiA+IGV4cGVy aWVuY2Ug4oCTIHRoYXQgc3VwcG9ydCBmb3IgY29uZmxpY3QgcmVzb2x1dGlvbiBpcyBhIHNpZ25p ZmljYW50IGVmZm9ydC4NCj4gPiA+Pj4NCj4gPiA+Pj4gQWxzbyBJIGhhdmUgY291cGxlIG9mIGNh c2VzIHdoZXJlIGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgZHJhZnQgaXMgbm90DQo+IGNsZWFyDQo+ ID4gYWJvdXQgcmVzb2x1dGlvbi4NCj4gPiA+Pj4NCj4gPiA+Pj4gSU1PLCBmaXJzdCB3ZSBuZWVk IGNsYXJpdHkgd2l0aCBpbiBhIHByb3RvY29sIGluc3RhbmNlIHJlc29sdXRpb24gcnVsZXMNCj4g PiBiZWZvcmUgZ29pbmcgdG8gcmVzb2x2ZSB0aGUgc2FtZSBhY3Jvc3MgcHJvdG9jb2xzIChJIG1l bnRpb25lZCBmZXcgY2FzZXMNCj4gPiBiZWxvdykgLg0KPiA+ID4+PiBTZXBhcmF0aW9uIG9mIHJl YWNoYWJpbGl0eSBhZHZlcnRpc2VtZW50cyBhbmQgU1JNUyB3b3VsZCBoZWxwIOKAnGNyb3NzDQo+ ID4gcHJvdG9jb2zigJ0gdmVyaWZpY2F0aW9uIG9mIHRoZSByYW5nZXMgYW5kIFNSTVMgaXMgbm90 IGFwcGxpY2FibGUgdG8gYWxsDQo+ID4gcHJvdG9jb2xzLg0KPiA+ID4+Pg0KPiA+ID4+Pg0KPiA+ ID4+PiBJbi1saW5lIFtVbWFdOg0KPiA+ID4+Pg0KPiA+ID4+PiAtLQ0KPiA+ID4+PiBVbWEgQy4N Cj4gPiA+Pj4NCj4gPiA+Pj4gRnJvbTogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgW21haWx0bzpn aW5zYmVyZ0BjaXNjby5jb21dDQo+ID4gPj4+IFNlbnQ6IFNhdHVyZGF5LCBBcHJpbCAzMCwgMjAx NiAxMDoxMSBQTQ0KPiA+ID4+PiBUbzogVW1hIENodW5kdXJpO2JydW5vLmRlY3JhZW5lQG9yYW5n ZS5jb20NCj4gPiA+Pj4gPG1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPjsNCj4gPiA+ IHNwcmluZ0BpZXRmLm9yZyA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gPiA+Pj4gU3ViamVj dDogUkU6IFtzcHJpbmddIGRyYWZ0LWdpbnNiZXJnLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9u IC0gV0cNCj4gPiA+Pj4gYWRvcHRpb24gY2FsbA0KPiA+ID4+Pg0KPiA+ID4+PiBVbWEg4oCTDQo+ ID4gPj4+DQo+ID4gPj4+IFdlIGFyZSBpbmRlZWQgZGVmaW5pbmcgY29uZmxpY3QgcmVzb2x1dGlv biBhY3Jvc3MgYWxsIHRoZSBTSUQNCj4gPiA+Pj4gYWR2ZXJ0aXNlbWVudHMgcmVnYXJkbGVzcyBv ZiBzb3VyY2UgKHByb3RvY29sIG9yIFNSTVMpIOKAkw0KPiA+ID4+Pg0KPiA+ID4+PiBbVW1hXTog V2hpbGUgeW91IGNhbiB0aGVvcmV0aWNhbGx5IGRvIGFueXRoaW5nIGZvciBjdXJyZW50DQo+ID4g aW1wbGVtZW50YXRpb24gdGhpcyBraW5kIG9mIGNyb3NzIHByb3RvY29sIHZlcmlmaWNhdGlvbiBp cyBhIG5ldyBhcmNoaXRlY3R1cmFsDQo+ID4gcmVxdWlyZW1lbnQuDQo+ID4gPj4+ICAgICAgICAg ICAgICAgICBCZWNhdXNlIGl0IHNlZW1zIOKAnGEgY2VudHJhbCBlbnRpdHnigJ0gbmVlZCB0byBn YXRoZXIgYWxsIGRpZmZlcmVudA0KPiA+IHByb3RvY29sIGluc3RhbmNlcyBTUk1TIGFkdmVydGlz ZW1lbnRzIGFuZCBzaG91bGQgc2V0dGxlIHdpdGggcmVzb2x1dGlvbi4NCj4gPiA+Pj4NCj4gPiA+ Pj4gLSAgICAgICAgICBBbHNvIG5vdGUgU1JNUyBpcyBub3QgYXBwbGljYWJsZSBmb3IgQkdQIGJ1 dCBpdCBzZWVtcyBhbGwgcHJlZml4DQo+IFNJRHMNCj4gPiBuZWVkIHRvIGJlIHZlcmlmaWVkICB3 aXRoIElHUCBpbnN0YW5jZXMgU1JNUyBhZHZlcnRpc2VtZW50cy4gSXMgdGhpcyB0cnVlPw0KPiA+ IFdoaWxlIHRoZSBkb2N1bWVudCBtb3N0bHkgdGFsa3MgYWJvdXQgdGhlc2UgYW5kIGNvbXBhcmVz IHdpdGggcHJlZml4DQo+ID4gYWR2ZXJ0aXNlbWVudC4NCj4gPiA+Pj4gW0xlczpdIFRoZSBpc3N1 ZSBpcyBwcm90b2NvbCBhZ25vc3RpYy4NCj4gPiA+Pj4NCj4gPiA+Pj4gLSAgICAgICAgICBBbGdv cml0aG0gcHJvcG9zZWQgbmVlZHMgbW9yZSBjbGFyaXR5OiBUYWtlIFNlY3Rpb24gMy4yLjQNCj4g PiA+Pj4NCj4gPiA+Pj4gbw0KPiA+ID4+PiAgICAgICAgICAgICAgICAgICAgICAgIOKAnCAgIDEu ICBTbWFsbGVyIHJhbmdlIHdpbnMNCj4gPiA+Pj4NCj4gPiA+Pj4gICAgICAgICAgICAgICAyLiAg SVB2NiBlbnRyeSB3aW5zIG92ZXIgSVB2NCBlbnRyeQ0KPiA+ID4+PiAgICAgICAgICAgICAgIOKA pg0KPiA+ID4+PiAgICAgICAgICDigJwNCj4gPiA+Pj4gICAgICAgICAgICAgICAgICAgV2hhdCBo YXBwZW5zIGluIGNhc2Ugb2YgcHJlZml4IGNvbmZsaWN0IG9yIFNJRCBjb25mbGljdCB3aXRoDQo+ IG9ubHkNCj4gPiBwcmVmaXggYWR2ZXJ0aXNlbWVudHMgKHJhbmdlIDEpLiAgU2F5IG11bHRpcGxl IHByZWZpeGVzIGhhdmUgc2FtZSBTSUQgaW4NCj4gb25lDQo+ID4gcHJvdG9jb2wgaW5zdGFuY2Ug YW5kIGluIGRpZmZlcmVudCBwcm90b2NvbHMuDQo+ID4gPj4+ICAgICAgICAgICAgICAgICAgIEkg c2VlIDIgbGV2ZWxzIG9mIHJlc29sdXRpb24gcmVxdWlyZWQgdml6Liwgb25lIGF0IHdpdGhpbiB0 aGUNCj4gPiBwcm90b2NvbCBhbmQgb25lIGFtb25nIHRoZSBwcm90b2NvbHMuICBObyBkaXNjdXNz aW9uIG9uIHRoaXMuDQo+ID4gPj4+DQo+ID4gPj4+IFtMZXM6XSBUaGUgZnVsbCBzZXQgb2YgcnVs ZXMgc3BlY2lmaWVkIGluIHRoZSBkcmFmdCBwcm92aWRlIGRldGVybWluaXN0aWMNCj4gPiByZXNv bHV0aW9uIGluIGFsbCBjYXNlcy4gWW91IGhhdmUgc25pcHBlZCBvbmx5IHRoZSBmaXJzdCB0d28g cnVsZXMuIElmIGENCj4gPiBwcmVmZXJlbmNlIGlzIG5vdCBvYnRhaW5lZCBiYXNlZCBvbiB0aGUg Zmlyc3QgdHdvIHJ1bGVzIHlvdSBjb250aW51ZSBvbiB0bw0KPiA+IHJ1bGUgIzMsIHRoZW4gcnVs ZSAjNCwgZXRjLg0KPiA+ID4+Pg0KPiA+ID4+PiAgICAgICAgICAgICAgICAgICBTaW1pbGFybHkg aW4gY2FzZSBvZiBTSUQgY29uZmxpY3QgIChyYW5nZSAxKSwgaXTigJlzIG5vdCBzcGVjaWZpZWQN Cj4gd2hpY2gNCj4gPiBwcm90b2NvbOKAmXMgU0lEIG5lZWQgdG8gYmUgY29uc2lkZXJlZC4gIEFy ZSB5b3UgYXNzdW1pbmcgc29tZSBzb3J0IG9mDQo+IEFkbWluDQo+ID4gZGlzdGFuY2UgcGxheSBh IHJvbGUgaW4gcmVzb2x1dGlvbj8NCj4gPiA+Pj4gW0xlczpdIE5vIOKAkyBhZG1pbiBkaXN0YW5j ZSBwbGF5cyBubyByb2xlIGhlcmUuDQo+ID4gPj4+DQo+ID4gPj4+ICAgSSBkb27igJl0IHNlZSBh bnkgZGlzY3Vzc2lvbiBpbiB0aGUgZG9jdW1lbnQgIGFuZCBuZWVkcyBtb3JlIGNsYXJpdHkNCj4g PiB0aGVyZSB0b28uDQo+ID4gPj4+IG8gICBBbHNvIHdoYXQgaGFwcGVucyBpZiBhIHByZWZpeCBv ciBTSUQgY29uZmxpY3QgaGFwcGVucyB3aXRoIFNSTVMNCj4gcmFuZ2UNCj4gPiAxIGFuZCBhIHBy ZWZpeCAgYWR2ZXJ0aXNlbWVudCAoMiBjYXNlcykNCj4gPiA+Pj4gYS4gICAgICAgb2Ygb25lIHBy b3RvY29sIGFuZA0KPiA+ID4+PiBiLiAgICAgIG11bHRpcGxlIHByb3RvY29scz8NCj4gPiA+Pj4N Cj4gPiA+Pj4gW0xlczpdIFRoZSBzb3VyY2Ugb2YgdGhlIFNJRCBhZHZlcnRpc2VtZW50ICh3aGF0 IHByb3RvY29sL3Byb3RvY29sDQo+ID4gaW5zdGFuY2Ugb3Igd2hldGhlciBpdCBpcyBTUk1TIGJh c2VkKSBwbGF5cyBubyByb2xlLiBUaGUgdGllIGJyZWFrZXIgcnVsZXMgYXMNCj4gPiBkZWZpbmVk IGFyZSBjb21wbGV0ZSBhbmQgcHJvdmlkZSBhIGRldGVybWluaXN0aWMgYW5zd2VyIGluIGFsbCBj YXNlcy4NCj4gPiA+Pj4gSWYgeW91IGJlbGlldmUgdGhhdCBpcyBub3QgdHJ1ZSBwbGVhc2UgcHJv dmlkZSBhIHNwZWNpZmljIGV4YW1wbGUgd2hlcmUNCj4gPiB5b3UgYXBwbHkgYWxsIHRoZSBydWxl cyBpbiB0aGUgb3JkZXIgc3BlY2lmaWVkIGFuZCBzdGlsbCBkbyBub3QgZGV0ZXJtaW5lIHRoZQ0K PiA+IHByZWZlcnJlZCBlbnRyeS4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4gLSAgICAgICAg ICBPbiB0aGUgYmVsb3cgYXNzdW1wdGlvbjogKFNlY3Rpb24gMy4yLjQpDQo+ID4gPj4+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIOKAnFRoaXMgaGFzIHRoZSBuaWNl IHByb3BlcnR5IHRoYXQgYSBzaW5nbGUNCj4gPiBtaXNjb25maWd1cmF0b2lvbiBvZiBhbiBTUk1T DQo+ID4gPj4+ICAgICAgICAgICAgICAgICAgIGVudHJ5IHdpdGggYSBsYXJnZSByYW5nZSB3aWxs IG5vdCBiZSBwcmVmZXJyZWQgb3ZlciBhIGxhcmdlDQo+ID4gbnVtYmVyIG9mDQo+ID4gPj4+ICAg ICAgICAgICAgICAgICAgIFNJRHMgYWR2ZXJ0aXNlZCBpbiBwcmVmaXggcmVhY2hhYmlsaXR5IGFk dmVydGlzZW1lbnRzLuKAnQ0KPiA+ID4+PiBXaGlsZSBhbnl0aGluZyBjYW4gaGFwcGVuIGluIHRo ZW9yeSwgSSBmb3VuZCBpdCBiaXQgb2RkIHRvIHNlZSB3aHkNCj4gU1JNUw0KPiA+IGVudHJ5IGlz IGJlaW5nIGFkdmVydGlzZWQgYW5kIGZvciB0aGUgc2FtZSBwcmVmaXgsIFNJRCBpcyBhbHNvIGFk dmVydGlzZWQNCj4gPiB0aHJvdWdoIHJlYWNoYWJpbGl0eSBhZHZlcnRpc2VtZW50cz8NCj4gPiA+ Pj4gVGhpcyBpcyBhZ2FpbnN0IHRoZSBzcGlyaXQgb2YgU1JNUyBhZHZlcnRpc2VtZW50LCBpc27i gJl0IGl0PyBXaGlsZSB0aGlzIGNhbg0KPiA+IGhhcHBlbiwgaXQgc2VlbXMgd2UgYXJlIGNsYWlt aW5nIHJlc29sdXRpb24gc29sdXRpb24gYnkgZm9jdXNpbmcgbW9yZSBvbg0KPiA+IHRoaXMgY2Fz ZSBpbiB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudC4NCj4gPiA+Pj4NCj4gPiA+ Pj4gW0xlczpdIFRoZXJlIGFyZSB0d28gbGVnaXRpbWF0ZSB1c2UgY2FzZXMgZm9yIFNSTVM6DQo+ ID4gPj4+DQo+ID4gPj4+IDEpVG8gYWR2ZXJ0aXNlIFNJRHMgZm9yIG5vbi1TUiBjYXBhYmxlIG5v ZGVzIDIpQXMgYSBnbG9iYWwNCj4gPiA+Pj4gcHJvdmlzaW9uaW5nIHRvb2wNCj4gPiA+Pj4NCj4g PiA+Pj4gTGV04oCZcyBleGFtaW5lIHRoZSBmaXJzdCBjYXNlLiBJIGhhdmUgYW4gTERQIGVuYWJs ZWQgbmV0d29yayBhbmQgSSBiZWdpbg0KPiA+IGludHJvZHVjaW5nIFNSIGNhcGFibGUgbm9kZXMu IEF0IGEgZ2l2ZW4gbW9tZW50IGluIHRpbWUgUm91dGVyIEEgaXMgTk9UDQo+IFNSDQo+ID4gY2Fw YWJsZSBhbmQgU1JNUyBhZHZlcnRpc2VtZW50cyBjb3ZlciBwcmVmaXggU0lEcyBmb3IgdGhlIGFk ZHJlc3Nlcw0KPiA+IGFzc29jaWF0ZWQgd2l0aCBSb3V0ZXIgQS4NCj4gPiA+Pj4gSSB0aGVuIHVw Z3JhZGUgUm91dGVyIEEgdG8gYmVjb21lIFNSIGNhcGFibGUuIEJlY2F1c2UgSSB3YW50IHRvIGRv DQo+ID4gPj4+IOKAnG1ha2UtYmVmb3JlLWJyZWFr4oCdIEkgZG8gbm90IGltbWVkaWF0ZWx5IHJl bW92ZSB0aGUgU1JNUw0KPiA+ID4+PiBhZHZlcnRpc2VtZW50cyBjb3ZlcmluZyB0aGUgYWRkcmVz c2VzIGFzc29jaWF0ZWQgd2l0aCBSb3V0ZXIgQS4gSQ0KPiA+ID4+PiB1cGdyYWRlIEEsIGFkZCBj b25maWd1cmF0aW9uIG9mIFNJRHMgbG9jYWxseSBvbiBSb3V0ZXIgQSwgYW5kDQo+ID4gPj4+IHZl cmlmeSB0aGF0IHRoZSBhZHZlcnRpc2VtZW50cyBvcmlnaW5hdGluZyBmcm9tIHByb3RvY29scyBv biBSb3V0ZXINCj4gPiA+Pj4gQQ0KPiA+ID4gYXJlIGNvcnJlY3QuIElmIGFuIGluY29uc2lzdGVu Y3kgaXMgaW50cm9kdWNlZCB3aGVuIGNvbmZpZ3VyaW5nIHRoZQ0KPiA+ID4gU0lEcyBvbiBSb3V0 ZXIgQSB0aGVuIEkgd2lsbCBoYXZlIGFuIFNSTVMgYWR2ZXJ0aXNlbWVudCBhbmQgYQ0KPiA+ID4g cHJlZml4LXJlYWNoYWJpbGl0eSBhZHZlcnRpc2VtZW50IHRoYXQgY29uZmxpY3QuIFVudGlsIHRo ZSBjb25mbGljdCBpcw0KPiA+ID4gY29ycmVjdGVkIHdlIHVzZSB0aGUgY29uZmxpY3QgcmVzb2x1 dGlvbiBydWxlcyB0byBwcm92aWRlDQo+ID4gPiBkZXRlcm1pbmlzdGljIGZvcndhcmRpbmcgYmVo YXZpb3IuDQo+ID4gPj4+DQo+ID4gPj4+IFRoaXMgdG8gbWUgaXMgYSBub3JtYWwgYW5kIGV4cGVj dGVkIHVwZ3JhZGUgc2NlbmFyaW8uDQo+ID4gPj4+DQo+ID4gPj4+DQo+ID4gPj4+IFRoaXMgaXMg b25lIG9mIHRoZSByZWFzb25zIG9mIG15IGZpcnN0IGNvbW1lbnQgYmVsb3cuIFlvdSBnb3QgdG8N Cj4gPiBzZXBhcmF0ZSB0aGUgcmVhY2hhYmlsaXR5IGFkdmVydGlzZW1lbnRzIGFuZCBTUk1TIGFk dmVydGlzZW1lbnRzOyBhcyBpbg0KPiA+IHByaW5jaXBsZSB0aGVzZSBhcmUgZGVmaW5lZCBmb3Ig ZGlmZmVyZW50IHB1cnBvc2VzLiBJIGRvbuKAmXQgc2VlIHdlICBuZWVkDQo+ID4gYWxnb3JpdGht IHRvIHByZWZlciByZWFjaGFiaWxpdHkgYWR2ZXJ0aXNlbWVudCAgb3ZlciBTUk1TIGFkdmVydGlz ZW1lbnQNCj4gKGlmDQo+ID4gd2UgZG9u4oCZdCBjb21wYXJlIHRoZXNlIDIgY2F0ZWdvcmllcyku DQo+ID4gPj4+DQo+ID4gPj4+DQo+ID4gPj4+DQo+ID4gPj4+IFtMZXM6XSBJIGRpc2FncmVlIOKA kyBob3BlZnVsbHkgbXkgY29tbWVudHMgaGF2ZSBoZWxwZWQgeW91IHRvDQo+ID4gdW5kZXJzdGFu ZCB3aHkuDQo+ID4gPj4+DQo+ID4gPj4+ICAgICBMZXMNCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+ Pj4gYXMgdGhlIHNlY3Rpb25zIHlvdSBoYXZlIHF1b3RlZCBjbGVhcmx5IHN0YXRlLg0KPiA+ID4+ Pg0KPiA+ID4+PiBXaHk/IEJlY2F1c2Ugd2UgbmVlZCBjb25zaXN0ZW50IHVzZSBvZiBTSURzIGlu IHRoZSBmb3J3YXJkaW5nIHBsYW5lLg0KPiA+IEZyb20gZm9yd2FyZGluZyBwZXJzcGVjdGl2ZSBp dCBtYXR0ZXJzIG5vdCB3aGV0aGVyIHRoZSBTSUQgd2FzDQo+IGFkdmVydGlzZWQNCj4gPiBieSBw cm90b2NvbCBpbnN0YW5jZSAjMSBvciAjMiBvciBieSBhbiBTUk1TLg0KPiA+ID4+Pg0KPiA+ID4+ PiBXaGF0IG1hdHRlcnMgaXMgdGhhdCB0aGUgU0lEIEkgdXNlIHRvIGRldGVybWluZSB3aGF0IGxh YmVsIEkgaW5zdGFsbCBpbg0KPiBteQ0KPiA+IGZvcndhcmRpbmcgcGxhbmUgaXMgdGhlIHNhbWUg U0lEIHRoYXQgbXkgbmVpZ2hib3JzIHdpbGwgdXNlLiBPdGhlcndpc2UNCj4gPiBmb3J3YXJkaW5n IHdpbGwgYmUgYnJva2VuLg0KPiA+ID4+Pg0KPiA+ID4+PiAgICAgTGVzDQo+ID4gPj4+DQo+ID4g Pj4+DQo+ID4gPj4+IEZyb206IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3Jn XSBPbiBCZWhhbGYgT2YgVW1hDQo+ID4gPj4+IENodW5kdXJpDQo+ID4gPj4+IFNlbnQ6IFdlZG5l c2RheSwgQXByaWwgMjcsIDIwMTYgNDozMSBQTQ0KPiA+IFRvOmJydW5vLmRlY3JhZW5lQG9yYW5n ZS5jb20NCj4gPiA+Pj4gPG1haWx0bzpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPjsNCj4gPiA+ IHNwcmluZ0BpZXRmLm9yZyA8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCj4gPiA+Pj4gU3ViamVj dDogUmU6IFtzcHJpbmddIGRyYWZ0LWdpbnNiZXJnLXNwcmluZy1jb25mbGljdC1yZXNvbHV0aW9u IC0gV0cNCj4gPiA+Pj4gYWRvcHRpb24gY2FsbA0KPiA+ID4+Pg0KPiA+ID4+PiBEZWFyIEF1dGhv cnMsDQo+ID4gPj4+DQo+ID4gPj4+IEhhdmUgZmV3IGNvbW1lbnRzIG9uIHRoZSBkcmFmdDoNCj4g PiA+Pj4NCj4gPiA+Pj4gMS4NCj4gPiA+Pj4gICAgICAgICAgQXMgSSBpbmRpY2F0ZWQgZHVyaW5n IG1lZXRpbmcgLSBJIGFtIG5vdCBzdXJlIHdoeSB3ZSBoYXZlIHRvIGNsdWINCj4gPiB2ZXJpZmlj YXRpb24gb2YgU0lEcyBhZHZlcnRpc2VkIHRocm91Z2ggcmVndWxhciBwcm90b2NvbCByZWFjaGFi aWxpdHkNCj4gPiA+Pj4gICAgICAgICAgICAgICAgICBwcmVmaXhlcyBhbmQgdGhlIHJhbmdlcyBh ZHZlcnRpc2VkIHRocm91Z2ggJ01hcHBpbmcgU2VydmVyJw0KPiA+IChTUk1TKS4gSSBkaWRuJ3Qg c2VlIGFueSBjb21wZWxsaW5nIHJlYXNvbiB0byBkbyB0aGlzLg0KPiA+ID4+PiAgICAgICAgICAg ICAgICAgICBTSURzIGFkdmVydGlzZWQgdGhyb3VnaCByZWFjaGFiaWxpdHkgcHJlZml4ZXMgZG9l c24ndCBoYXZlDQo+ID4gcmFuZ2VzIHVubGlrZSBTUk1TIGFkdmVydGlzZW1lbnRzLg0KPiA+ID4+ PiAgICAgICAgICAgICAgICAgICBBcyBTUk1TIGFkdmVydGlzZW1lbnRzIGFyZSBwcmltYXJpbHkg Zm9yIG5vZGVzIHdoaWNoIGFyZQ0KPiBub3QNCj4gPiBTUiBjYXBhYmxlIGFuZCAgSSBmZWVsIHdl IHNob3VsZCBub3QgbWl4IHRoaXMgd2l0aCBub2RlcyB3aGljaCBhcmUgU1INCj4gPiBjYXBhYmxl Lg0KPiA+ID4+Pg0KPiA+ID4+PiAgICAgICAgICBUaGlzIGlzb2xhdGlvbiBoZWxwcyByZXN0cmlj dGluZyB0aGUgcmVzb2x1dGlvbiB3b3JrIHByaW1hcmlseSBmb3INCj4gPiBtdWx0aXBsZSBTUk1T IGVudHJpZXMgYWR2ZXJ0aXNlZCB0aHJvdWdoIG9uZSBub2RlIG9yIG11bHRpcGxlIG5vZGVzLg0K PiA+ID4+PiAgICAgICAgICAgICAgICAgIFNSTVMgYWR2ZXJ0aXNlbWVudHMgYXJlIGluZGVlZCBs aXR0bGUgYml0IHVuaXF1ZSBpbiB0aGF0IHlvdQ0KPiBhcmUNCj4gPiBhZHZlcnRpc2luZyAiY29u ZmlndXJhdGlvbiIgb24gYmVoYWxmIG9mIG5vZGUgWCBmcm9tIG5vZGUgWQ0KPiA+ID4+PiAgICAg ICAgICAgICAgICAgIHdpdGggcmFuZ2VzIChib3RoIHByZWZpeCByYW5nZXMgYW5kIFNJRCByYW5n ZXMpLg0KPiA+ID4+Pg0KPiA+ID4+Pg0KPiA+ID4+PiAyLg0KPiA+ID4+PiAgICAgICAgICAgICAg ICAgIFJlZ2FyZGluZyAgdGhlIHNjb3BlIG9mIGNvbmZsaWN0IHJlc29sdXRpb246DQo+ID4gPj4+ DQo+ID4gPj4+DQo+ID4gPj4+ICAgICAgICAgU2VjdGlvbiAxDQo+ID4gPj4+DQo+ID4gPj4+ICAg ICAgICAgICAgICIgICBUaGUgcHJvYmxlbSB0byBiZSBhZGRyZXNzZWQgaXMgcHJvdG9jb2wgaW5k ZXBlbmRlbnQgaS5lLiwNCj4gPiBzZWdtZW50DQo+ID4gPj4+ICAgICAgICAgICByZWxhdGVkIGFk dmVydGlzZW1lbnRzIG1heSBiZSBvcmlnaW5hdGVkIGJ5IG11bHRpcGxlIG5vZGVzDQo+IHVzaW5n DQo+ID4gPj4+ICAgICAgICAgICBkaWZmZXJlbnQgcHJvdG9jb2xzIGFuZCB5ZXQgdGhlIGNvbmZs aWN0IHJlc29sdXRpb24gTVVTVCBiZSB0aGUNCj4gPiBzYW1lDQo+ID4gPj4+ICAgICAgICAgICBv biBhbGwgbm9kZXMgcmVnYXJkbGVzcyBvZiB0aGUgcHJvdG9jb2wgdXNlZCB0byB0cmFuc3BvcnQg dGhlDQo+ID4gPj4+ICAgICAgICAgICBhZHZlcnRpc2VtZW50cy4iDQo+ID4gPj4+DQo+ID4gPj4+ ICAgICAgICAgIFNlY3Rpb24gMy4yLjgNCj4gPiA+Pj4gICAgICAgICAgICAiICAgbyAgSW4gY2Fz ZXMgd2hlcmUgbXVsdGlwbGUgcm91dGluZyBwcm90b2NvbHMgYXJlIGluIHVzZSBtYXBwaW5nDQo+ ID4gPj4+ICAgICAgICBlbnRyaWVzIGFkdmVydGlzZWQgYnkgYWxsIHJvdXRpbmcgcHJvdG9jb2xz IE1VU1QgYmUgaW5jbHVkZWQuIg0KPiA+ID4+Pg0KPiA+ID4+PiAgICAgICAgVGhpcyBzb3VuZHMg bGlrZSB3ZSBhcmUgc2Vla2luZyB0byByZXNvbHZlIGNvbmZsaWN0aW5nIGVudHJpZXMNCj4gb3V0 c2lkZQ0KPiA+IGFuZCBhY3Jvc3MgdGhlIHByb3RvY29scz8NCj4gPiA+Pj4gICAgICAgIEVhY2gg SUdQIGhhcyBzZXBhcmF0ZSBtZWNoYW5pc20gZm9yIGFkdmVydGlzaW5nIG1hcHBpbmcgZW50cnkN Cj4gYW5kDQo+ID4gSSB0aGlzIGlzIG5vdCBjbGVhciB3aXRoIHRoZSBjdXJyZW50IHZlcnNpb24g b2YgdGhlIGRyYWZ0IGhvdyB3ZSBjYW4gY3Jvc3MNCj4gdmVyaWZ5DQo+ID4gU0lEL1ByZWZpeCBj b25mbGljdCBhY3Jvc3MgIHRoZSBwcm90b2NvbC4NCj4gPiA+Pj4gICAgICAgQ2FuIHlvdSBjbGFy aWZ5IHRoaXM/DQo+ID4gPj4+DQo+ID4gPj4+DQo+ID4gPj4+IC0tDQo+ID4gPj4+IFVtYSBDLg0K PiA+ID4+Pg0KPiA+ID4+Pg0KPiA+ID4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ ID4+PiBGcm9tOiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mDQo+ID4gPj4+YnJ1bm8uZGVjcmFlbmVAb3JhbmdlLmNvbSA8bWFpbHRvOmJydW5vLmRl Y3JhZW5lQG9yYW5nZS5jb20+DQo+ID4gPj4+IFNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNCwgMjAx NiAxMjo1NSBBTSAgVG86c3ByaW5nQGlldGYub3JnDQo+ID4gPj4+PG1haWx0bzpzcHJpbmdAaWV0 Zi5vcmc+DQo+ID4gPj4+IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBkcmFmdC1naW5zYmVyZy1zcHJp bmctY29uZmxpY3QtcmVzb2x1dGlvbiAtIFdHDQo+ID4gPj4+YWRvcHRpb24gY2FsbA0KPiA+ID4+ Pg0KPiA+ID4+Pj4gRnJvbTpicnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tDQo+ID4gPG1haWx0bzpi cnVuby5kZWNyYWVuZUBvcmFuZ2UuY29tPiA+IFNlbnQ6DQo+ID4gPiBUaHVyc2RheSwgQXByaWwg MTQsIDIwMTYNCj4gPiA+Pj4+IDk6NTEgQU0NCj4gPiA+Pj4+DQo+ID4gPj4+PiBEZWFyIFdHLA0K PiA+ID4+Pj4NCj4gPiA+Pj4+IEFzIHdlIGRpc2N1c3NlZCBhdCBvdXIgbWVldGluZyBsYXN0IHdl ZWssIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24NCj4gPiA+Pj4+IGhhcyBiZWVuIHJlcXVlc3RlZCBm b3IgZHJhZnQtZ2luc2Jlcmctc3ByaW5nLWNvbmZsaWN0LXJlc29sdXRpb24uDQo+ID4gPj4+PiBQ bGVhc2UgcmVwbHkgdG8gdGhlIGxpc3Qgd2l0aCB5b3VyIGNvbW1lbnRzLCBpbmNsdWRpbmcgYWx0 aG91Z2ggbm90DQo+ID4gPj4+PiBsaW1pdGVkIHRvIHdoZXRoZXIgb3Igbm90IHlvdSBzdXBwb3J0 IGFkb3B0aW9uLg0KPiA+ID4+Pg0KPiA+ID4+PiBXZSB3aWxsIGVuZCB0aGUgY2FsbCBvbiBBcHJp bCAyOSwgMjAxNi4NCj4gPiA+Pj4NCj4gPiA+Pj4NCj4gPiA+Pj4+IFRoYW5rcywNCj4gPiA+Pj4+ DQo+ID4gPj4+PiAtLUpvaG4gYW5kIEJydW5vDQo+ID4gPj4+Pg0KPiA+ID4+Pj4NCj4gPiA+Pj4+ DQo+ID4gPj4+Pg0KPiA+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPiA+Pj4+DQo+ID4NCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4+Pj4gX19fX18N Cj4gPiA+Pj4+DQo+ID4gPj4+PiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2 ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCj4gPiA+Pj4+IGNvbmZpZGVudGllbGxlcyBv dSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlDQo+ID4gPj4+PiBkaWZm dXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6 IHJlY3UNCj4gPiA+Pj4+IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUNCj4gPiA+Pj4+IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMg cGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzDQo+ID4gPj4+PiBldGFu dCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25z YWJpbGl0ZSBzaQ0KPiA+IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNp ZmllLiBNZXJjaS4NCj4gPiA+Pj4+DQo+ID4gPj4+PiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3INCj4gPiA+Pj4+IHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQNCj4g PiA+Pj4+IG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jp c2F0aW9uLg0KPiA+ID4+Pj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyDQo+ID4gPj4+PiBhbmQgZGVsZXRlIHRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiA+ID4+Pj4gQXMgZW1haWxzIG1heSBiZSBhbHRl cmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdA0KPiA+ID4+Pj4gaGF2 ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gPiA+Pj4+IFRoYW5rIHlv dS4NCj4gPiA+Pj4+DQo+ID4gPj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiA+ID4+Pj4gc3ByaW5nIG1haWxpbmcgbGlzdA0KPiA+ID4+Pj5zcHJp bmdAaWV0Zi5vcmcgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ID4gPj4+Pmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQo+ID4gPj4+DQo+ID4gPj4+DQo+ID4N Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+IF9fX19fX19fX18NCj4gPiA+Pj4gXyBfIF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ID4+Pg0KPiA+ID4+PiBDZSBtZXNzYWdl IGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMN Cj4gPiA+Pj4gY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRv bmMgcGFzIGV0cmUNCj4gPiA+Pj4gZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1DQo+ID4gPj4+IGNlIG1lc3NhZ2UgcGFyIGVy cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgIGV0IGxlDQo+ID4gPj4+ IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcw0KPiA+ ID4gZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2Ug ZGVjbGluZSB0b3V0ZQ0KPiA+ID4gcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPiA+ID4+Pg0KPiA+ID4+PiBUaGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IN Cj4gcHJpdmlsZWdlZA0KPiA+IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwNCj4gPiB1c2VkIG9yIGNvcGllZCB3 aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+ID4gPj4+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg ZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQNCj4gPiBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+ID4gPj4+IEFzIGVtYWlscyBtYXkg YmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZQ0K PiA+IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiA+ID4+PiBUaGFuayB5 b3UuDQo+ID4gPj4+DQo+ID4gPj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+ID4gPj4+IHNwcmluZyBtYWlsaW5nIGxpc3QNCj4gPiA+Pj5zcHJpbmdA aWV0Zi5vcmcgPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ID4gPj4+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCj4gPiA+Pj4NCj4gPiA+Pj4gX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+Pj4gc3ByaW5nIG1h aWxpbmcgbGlzdA0KPiA+ID4+PnNwcmluZ0BpZXRmLm9yZyA8bWFpbHRvOnNwcmluZ0BpZXRmLm9y Zz4NCj4gPiA+Pj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0K PiA+ID4+DQo+ID4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiA+PiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+ID4gPj5zcHJpbmdAaWV0Zi5vcmcg PG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQo+ID4gPj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NwcmluZw0KPiA+ID4+DQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlm ZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZl eiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4 cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVz IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwK T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRp c3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMg bWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhh dmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== From nobody Wed May 18 05:05:32 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E48412D0EA for ; Wed, 18 May 2016 05:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.344 X-Spam-Level: X-Spam-Status: No, score=-3.344 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptl5XTbkLZGb for ; Wed, 18 May 2016 05:05:26 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor34.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D007112D0EC for ; Wed, 18 May 2016 04:57:22 -0700 (PDT) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 5BF9340B40; Wed, 18 May 2016 13:57:21 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.72]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 2789920057; Wed, 18 May 2016 13:57:21 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0294.000; Wed, 18 May 2016 13:57:21 +0200 From: To: "Les Ginsberg (ginsberg)" , "spring@ietf.org" Thread-Topic: draft-ietf-spring-conflict-resolution - Policy Thread-Index: AdGsYbndUWczH5clSpukONRF0Kk37ABrjsLQALp6TfA= Date: Wed, 18 May 2016 11:57:20 +0000 Message-ID: <29660_1463572641_573C58A1_29660_1816_1_53C29892C857584299CBF5D05346208A0F8AC58D@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <24715_1463066559_57349FBF_24715_2873_1_53C29892C857584299CBF5D05346208A0F8A48DE@OPEXCLILM21.corporate.adroot.infra.ftgroup> <4bf6ef2278fd4e809203e988d8fba808@XCH-ALN-001.cisco.com> In-Reply-To: <4bf6ef2278fd4e809203e988d8fba808@XCH-ALN-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F8AC58DOPEXCLILM21corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] draft-ietf-spring-conflict-resolution - Policy X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2016 12:05:29 -0000 --_000_53C29892C857584299CBF5D05346208A0F8AC58DOPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Les, Please see inline [Bruno] From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Sunday, May 15, 2016 12:41 AM To: DECRAENE Bruno IMT/OLN; spring@ietf.org Subject: RE: draft-ietf-spring-conflict-resolution - Policy Bruno - I am having difficulty parsing the examples you provide below as they seem = to incorporate advertisement source into the description whereas the draft = deliberately omits source. [Bruno] My text does not incorporate the source, but the type of source IOW= the type of sub-TLV. So it does not matter if R2 sends an advertisement or R12 sends advertiseme= nt or both of them do (which could happen when an advertisement is leaked) = - what matters is what unique entries are in the database independent of so= urce. [Bruno] It may not matter for your algorithm (pending another thread), but = it does for the one I proposed. It would be good if you could present your examples using the format define= d in the draft i.e.: [Bruno] My examples are described in plain text. Then the examples giving i= ntermediate steps of my algo uses the data that are needed i.e. the type of= advertisement (Prefix-SID vs MS). Then finally, my algo runs on a per FEC/IP Prefix basis, and not on a per I= GP advertisement basis which your format describe. So I'm sorry but I don't see how to indulge your request. Pi - Initial prefix Pe - End prefix L - Prefix length Lx - Maximum prefix length (32 for IPv4, 128 for IPv6) Si - Initial SID value Se - End SID value R - Range value T - Topology A - Algorithm A Mapping Entry is then the tuple: (Pi/L, Si, R, T, A) Pe =3D (Pi + ((R-1) << (Lx-L)) Se =3D Si + (R-1) Example: (192.0.2.120/32, 200, 1, 0, 0) As regards your proposal - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID this to me specifies an implementation - which isn't necessary. [Bruno] Well, _you_ are the one talking about implementation, and more spec= ifically implementation complexity. Assuming the above algo works, it looks relatively simple to implement, in = which case, I would not buy the argument about implementation complexity wh= ich is the only argument in favor or the "ignore" or "quarantine" policy. Bottom line, I would welcome your feedback and comments on this proposed al= go/policy. Thanks, Regards, -- Bruno However, there is one important point which has not been specified in the d= raft which reading your post has brought to my attention - that is the orde= r in which checks are made. The draft states: "Prefix conflicts are specific to mapping entries sharing the same topolog= y and algorithm." "SID conflicts are independent of address-family, independent of prefix le= n, independent of topology, and independent of algorithm." If we consider an example where a network supports two VPNs, the significan= ce of ordering in the evaluation of conflicts will be highlighted: VPN1: (192.0.2.1/32, 100, 1, 1, 0) (192.0.2.1/32, 200, 1, 1, 0) VPN2: (192.0.2.100/32, 200, 1, 2, 0) If we evaluate prefix conflicts first, then the following entries are "acti= ve": (192.0.2.1/32, 100, 1, 1, 0) !VPN1 (192.0.2.100/32, 200, 1, 2, 0) !VPN2 If we evaluate SID conflicts first, then the following entries are "active": (192.0.2.1/32, 100, 1, 1, 0) !VPN1 The latter choice is suboptimal because it prevents use of the VPN2 entry u= nnecessarily. This point needs to be made explicit in the draft. Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Thursday, May 12, 2016 8:23 AM To: spring@ietf.org Subject: [spring] draft-ietf-spring-conflict-resolution - Policy Hi authors, all As an individual contributor, please find below some feedback on the policy. I'm wondering if we could address the conflict on a per FEC/Prefix basis ra= ther than on a per IGP advertisement basis. If so, this may avoid the discussion between the Quarantine vs ignore polic= y. The problem that we need to solve, is to find the SID for a prefix (P1). The algo could be: - Find all SIDi advertised for the prefix P1 = // identification of Prefix conflicts - For each SIDi find all the prefix Pij associated with SID= i // identification of SID conflicts // as a result, we get a list of SIDi - Pij for P1 Get the best as per the preference algorithm. If best Pij =3D=3D P1 then use SIDij for P1 else return no SID / no SID availa= ble for this prefix P1 Note that it would probably be better for the preference algo to put the= SID tie-brake before the prefix tie-break as with the prefix tie-break, we= suffer from the conflict twice (Prefix - SID mapping, then SID- prefix map= ping) which increase the diversity and hence the chance of not finding a va= lid entry. But for the below examples, I used the preference algo from dr= aft-ietf-*-00 Below are examples, running this policy on typical configuration error case= s. Examples 3.4.4. Network operation Consider the following simple network example: 1. 100 nodes: R1 to R100; 2. IP Loopbacks are from 192.0.2.1 to 192.0.2.100: 3. SID are from 1 to 100; 4. R1 to R50 are SR capable and advertised their own SID using Prefix-SID sub-TLV; 5. R51 to R100 are SR non-capable, running LDP and their SID are advertised by two redundant Mapping Server MS1 and MS2; 6. As the number of nodes which are SR capable are expected to increase and as in real deployment their Loopback addresses would no the contiguous, the Mapping servers advertisement covers all Loopbacks: (192.0.2.1/32, 1, 100); Subsequent sections evaluate the consequences of a single configuration error, for all conflict resolution options. 3.4.4.1. Example 1: SID configured on 1 node conflict with SID configured on another node Following a typo during configuration, R2 is configured with a SID of 12. That SID conflicts with the Prefix-SID advertised by R12 and the Ma= pping Server Advertisement for R12. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R12, a single SID is advertised and hence selected. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID2 - R2 (MS, MS) R2 - SID12 - R12 (prefix SID, MS) R2 - SID12 - R2 (prefix SID, prefix SID) Best one is R2 - SID12 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID12 is selected for R2. For R12, the algo evaluates a conflict between the following advertismen= ts: R12 - SID12 - R12 (prefix SID, prefix SID) R12 - SID12 - R2 (prefix SID, prefix SID) R12 - SID12 - R12 (prefix SID, MS) R12 - SID12 - R2 (MS, prefix SID) R12 - SID12 - R12 (MS, MS) Best one is R12 - SID12 - R2 (smaller range (prefix SID),smaller range (= prefix SID), smaller starting adresse (R2)) R12 <> R2 =3D=3D> R12 has no SID. 3.4.4.2. Example 2: SID configured on 1 node conflict with SID configured on the Mapping Server Following a typo during configuration, R2 is configured with a SID of 52. That SID conflicts with the Mapping Server advertisements of MS1 and MS2 for the loopback of R52. Note: both MS advertisement are the same, so we only consider one in the= below analysis. All prefix but R2 and R52, a single SID is advertised and hence selected. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID52 - R2 (prefix SID, prefix SID) R2 - SID52 - R52 (prefix SID, MS) R2 - SID2 - R2 (MS, MS) Best one is R2 - SID52 - R2 (smaller range (prefix SID),smaller range (p= refix SID)) =3D=3D> SID52 is selected for R2. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS, MS) R52 - SID52 - R2 (MS, prefix SID) Best one is R52 - SID52 - R2 (smaller range (prefix SID)) R52 <> R2 =3D=3D> R52 has no SID. 3.4.4.3. Example 3: wrong configuration of a MS Following a typo during configuration, MS1 is configured (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0 instead of 192.0.2.1). That advertisement conflicts with the Mapping Server advertisements of MS2 and the Prefix-SID advertised by R1...R50. We have a conflict for all routers except R100. For LDP only routers R51 to R99 we have a conflict between both MS adver= tisement. For R52, the algo evaluates a conflict between the following advertismen= ts: R52 - SID52 - R52 (MS2, MS2) R52 - SID52 - R51 (MS2, MS1) R52 - SID53 - R52 (MS1, MS1) R52 - SID53 - R53 (MS1, MS2) Best one is R52 - SID52 - R51 (smaller starting address) R52 <> R51 =3D=3D> R52 has no SID. For SR routers, R1 to 50, we have a conflict between both MS advertiseme= nt and Prefix SID advertisements. For R2, the algo evaluates a conflict between the following advertisment= s: R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 - SID 2 - R2 (Prefix SID, MS2) R2 - SID 2 - R1 (Prefix SID, MS1) R2 - SID 2 - R2 (MS2, MS2) R2 - SID 2 - R2 (MS2, Prefix SID) R2 - SID 2 - R1 (MS2, MS1) R2 - SID 3 - R2 (MS1, MS1) R2 - SID 3 - R3 (MS1, MS2) R2 - SID 3 - R3 (MS1, Prefix SID) Best one is R2 - SID 2 - R2 (Prefix SID, Prefix SID) R2 =3D=3D R2 hence R2 use SID2. Regards, Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_53C29892C857584299CBF5D05346208A0F8AC58DOPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Les,

 

Please see inline [Bruno]<= /o:p>

&n= bsp;

From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Sunday, May 15, 2016 12:41 AM
To: DECRAENE Bruno IMT/OLN; spring@ietf.org
Subject: RE: draft-ietf-spring-conflict-resolution - Policy

 

Bruno &= #8211;

&n= bsp;

I am ha= ving difficulty parsing the examples you provide below as they seem to inco= rporate advertisement source into the description whereas the draft deliber= ately omits source.

[Bruno] My text does not incorp= orate the source, but the type of source IOW the type of sub-TLV.

&n= bsp;

So it d= oes not matter if R2 sends an advertisement or R12 sends advertisement or b= oth of them do (which could happen when an advertisement is leaked) –= what matters is what unique entries are in the database independent of source.

[Bruno] It may not matter for y= our algorithm (pending another thread), but it does for the one I proposed.=

&n= bsp;

It woul= d be good if you could present your examples using the format defined in th= e draft i.e.:

[Bruno] My examples are describ= ed in plain text. Then the examples giving intermediate steps of my algo us= es the data that are needed i.e. the type of advertisement (Prefix-SID vs M= S).

Then finally, my algo runs on a= per FEC/IP Prefix basis, and not on a per IGP advertisement basis which yo= ur format describe.

So I’m sorry but I don= 217;t see how to indulge your request.

&n= bsp;

    Pi - Initial prefix<= /span>

     Pe - End prefix

     L -  Prefix length

     Lx - Maximum prefix lengt= h (32 for IPv4, 128 for IPv6)

     Si - Initial SID value

     Se - End SID value

     R -  Range value

     T - Topology

     A - Algorithm<= /span>

 

     A Mapping Entry is then t= he tuple: (Pi/L, Si, R, T, A)

     Pe =3D (Pi + ((R-1) << (Lx-L= ))

     Se =3D Si + (R-1)<= /i>

 

Example:     (192.0.2.120/32, = 200, 1, 0, 0)

&n= bsp;

As rega= rds your proposal

&n= bsp;

- Find all SIDi advertised for the prefix P1 =             &nb= sp;            =             &nb= sp;            =         // identification of Prefix conf= licts

        &n= bsp;       - For each SIDi find all the prefi= x Pij associated with SIDi         =      // identification of SID conflicts=

 

Get the best as per the preference algorithm.=

If best Pij =3D=3D P1

        &n= bsp;       then use SIDij for P1

        &n= bsp;       else return no SID      = ;            &n= bsp;      

&n= bsp;

this to= me specifies an implementation – which isn’t necessary.

[Bruno] Well, _you_ are = the one talking about implementation, and more specifically implementation = complexity.

Assuming the above algo works, = it looks relatively simple to implement, in which case, I would not buy the= argument about implementation complexity which is the only argument in fav= or or the “ignore” or “quarantine” policy.

Bottom line, I would welcome yo= ur feedback and comments on this proposed algo/policy.

 

Thanks,

Regards,

-- Bruno

&n= bsp;

&n= bsp;

However= , there is one important point which has not been specified in the draft wh= ich reading your post has brought to my attention – that is the order= in which checks are made.

The dra= ft states:

&n= bsp;

“= Prefix conflicts are specific to mapping entries sharing  the same top= ology and algorithm.”

“= SID conflicts are independent of address-family,  independent of prefi= x len, independent of topology, and independent  of algorithm.”<= o:p>

&n= bsp;

If we c= onsider an example where a network supports two VPNs, the significance of o= rdering in the evaluation of conflicts will be highlighted:

&n= bsp;

VPN1:

(192.0.= 2.1/32, 100, 1, 1, 0)

(192.0.= 2.1/32, 200, 1, 1, 0)

&n= bsp;

&n= bsp;

VPN2:

&n= bsp;

(192.0.= 2.100/32, 200, 1, 2, 0)

&n= bsp;

If we e= valuate prefix conflicts first, then the following entries are “activ= e”:

(192.0.= 2.1/32, 100, 1, 1, 0) !VPN1

(192.0.= 2.100/32, 200, 1, 2, 0) !VPN2

&n= bsp;

If we e= valuate SID conflicts first, then the following entries are “active&#= 8221;:

(192.0.= 2.1/32, 100, 1, 1, 0) !VPN1

&n= bsp;

The lat= ter choice is suboptimal because it prevents use of the VPN2 entry unnecess= arily.

&n= bsp;

This po= int needs to be made explicit in the draft.

&n= bsp;

 &= nbsp;  Les

&n= bsp;

From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf.org
Subject: [spring] draft-ietf-spring-conflict-resolution - Policy

 

Hi authors, all

 

As an individual contributor, p= lease find below some feedback on the policy.

 

I'm wondering if we could addre= ss the conflict on a per FEC/Prefix basis rather than on a per IGP advertis= ement basis.

If so, this may avoid the discu= ssion between the Quarantine vs ignore policy.

 

The problem that we need to sol= ve, is to find the SID for a prefix (P1).

The algo could be:

- Find all SIDi advertised for = the prefix P1          &n= bsp;            = ;            &n= bsp;            = ;           // identifica= tion of Prefix conflicts

     &= nbsp;          - For each SIDi= find all the prefix Pij associated with SIDi     =          // identification of SID c= onflicts

 

// as a result, we get a list o= f SIDi – Pij for P1

 

Get the best as per the prefere= nce algorithm.

If best Pij =3D=3D P1

     &= nbsp;          then use SIDij = for P1

     &= nbsp;          else return no = SID            =             &nb= sp; / no SID available for this prefix P1

 

     &= nbsp;         

   Note that it would= probably be better for the preference algo to put the SID tie-brake before= the prefix tie-break as with the prefix tie-break, we suffer from the conf= lict twice (Prefix - SID mapping, then SID- prefix mapping) which increase the diversity and hence the chance of not finding = a valid entry.   But for the below examples, I used the preferenc= e algo from draft-ietf-*-00

     &= nbsp;         

 

Below are examples, running thi= s policy on typical configuration error cases.   

Examples

3.4.4.  Network operation<= o:p>

 

   Consider the follo= wing simple network example:

 

   1.  100 nodes= : R1 to R100;

 

   2.  IP Loopba= cks are from 192.0.2.1 to 192.0.2.100:

 

   3.  SID are f= rom 1 to 100;

 

   4.  R1 to R50= are SR capable and advertised their own SID using

     &= nbsp; Prefix-SID sub-TLV;

 

   5.  R51 to R1= 00 are SR non-capable, running LDP and their SID are

      =  advertised by two redundant Mapping Server MS1 and MS2;

 

   6.  As the nu= mber of nodes which are SR capable are expected to

     &= nbsp; increase and as in real deployment their Loopback addresses would

     &= nbsp; no the contiguous, the Mapping servers advertisement covers all<= /o:p>

     &= nbsp; Loopbacks: (192.0.2.1/32, 1, 100);

 

   Subsequent section= s evaluate the consequences of a single

   configuration erro= r, for all conflict resolution options.

 

3.4.4.1.  Example 1: SID c= onfigured on 1 node conflict with SID

     &= nbsp;    configured on another node

 

   Following a typo d= uring configuration, R2 is configured with a SID of

   12.  That SID= conflicts with the Prefix-SID advertised by R12 and the Mapping Server Adv= ertisement for R12.

   Note: both MS adve= rtisement are the same, so we only consider one in the below analysis.=

   =

   All prefix bu= t R2 and R12, a single SID is advertised and hence selected.

   =

   For R2, the a= lgo evaluates a conflict between the following advertisments:

   R2 - SID2 - R2 (MS= , MS)

   R2 - SID12 - R12 (= prefix SID, MS)

   R2 - SID12 - = R2  (prefix SID, prefix SID)

   =

   

   Best one is R= 2 - SID12 - R2 (smaller range (prefix SID),smaller range (prefix SID))=

   =3D=3D> SID12 i= s selected for R2.

   =

   For R12, the = algo evaluates a conflict between the following advertisments:

   R12 - SID12 - R12 = (prefix SID, prefix SID)

   R12 - SID12 - R2&n= bsp; (prefix SID, prefix SID)

   R12 - SID12 - R12 = (prefix SID, MS)

   R12 - SID12 - R2&n= bsp; (MS, prefix SID)

   R12 - SID12 - R12 = (MS, MS)

   =

   Best one is R= 12 - SID12 - R2 (smaller range (prefix SID),smaller range (prefix SID), sma= ller starting adresse (R2))

   R12 <> = R2 =3D=3D> R12 has no SID.

   =

   3.4.4.2. = ; Example 2: SID configured on 1 node conflict with SID

     &= nbsp;    configured on the Mapping Server<= /p>

 

   Following a typo d= uring configuration, R2 is configured with a SID of

   52.  That SID= conflicts with the Mapping Server advertisements of MS1<= /p>

   and MS2 for the lo= opback of R52.

   Note: both MS adve= rtisement are the same, so we only consider one in the below analysis.=

   =

   All prefix bu= t R2 and R52, a single SID is advertised and hence selected.

   =

   For R2, the a= lgo evaluates a conflict between the following advertisments:

   R2 - SID52 - R2&nb= sp; (prefix SID, prefix SID)

   R2 - SID52 - R52 (= prefix SID, MS)

   R2 - SID2  - = R2  (MS, MS)

   =

   Best one is R= 2 - SID52 - R2 (smaller range (prefix SID),smaller range (prefix SID))=

   =3D=3D> SID52 i= s selected for R2.

   =

   For R52, the = algo evaluates a conflict between the following advertisments:

   R52 - SID52 - R52 = (MS, MS)

   R52 - SID52 - R2&n= bsp; (MS, prefix SID)

   =

   Best one is R= 52 - SID52 - R2 (smaller range (prefix SID))

   R52 <> R2 = =3D=3D> R52 has no SID.

   =

   

3.4.4.3.  Example 3: wrong= configuration of a MS

 

   Following a typo d= uring configuration, MS1 is configured

   (192.0.2.0/32, 1, = 100). (i.e. 192.0.2.0 instead of 192.0.2.1).  That

   advertisement conf= licts with the Mapping Server advertisements of MS2

   and the Prefix-SID= advertised by R1...R50.

   =

   We have a con= flict for all routers except R100.

   =

   For LDP only = routers R51 to R99 we have a conflict between both MS advertisement.

   For R52, the algo = evaluates a conflict between the following advertisments:=

   R52 - SID52 - R52 = (MS2, MS2)

   R52 - SID52 - R51 = (MS2, MS1)

   R52 - SID53 - R52 = (MS1, MS1)

   R52 - SID53 - R53 = (MS1, MS2)

 

   Best one is R52 - = SID52 - R51 (smaller starting address)

   R52 <> R51 = =3D=3D> R52 has no SID.

   =

   For SR router= s, R1 to 50, we have a conflict between both MS advertisement and Prefix SI= D advertisements.

   For R2, the algo e= valuates a conflict between the following advertisments:<= /p>

   R2 - SID 2 - R2 (P= refix SID, Prefix SID)

   R2 - SID 2 - R2 (P= refix SID, MS2)

   R2 - SID 2 - R1 (P= refix SID, MS1)

   R2 - SID 2 - R2 (M= S2, MS2)

   R2 - SID 2 - R2 (M= S2, Prefix SID)

   R2 - SID 2 - R1 (M= S2, MS1)

   R2 - SID 3 - R2&nb= sp; (MS1, MS1)

   R2 - SID 3 - R3&nb= sp; (MS1, MS2)

   R2 - SID 3 - R3&nb= sp; (MS1, Prefix SID)

   =

   Best one is R= 2 - SID 2 - R2 (Prefix SID, Prefix SID)

   R2 =3D=3D R2 hence= R2 use SID2.

 

Regards,

Bruno

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain conf=
idential or privileged information that may be protected by law;=

they should not be distributed, used or copied wi=
thout authorisation.
If you have received this email in error, please =
notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable fo=
r messages that have been modified, changed or falsified.=

Thank you.
______________________________________________________________________=
___________________________________________________

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_53C29892C857584299CBF5D05346208A0F8AC58DOPEXCLILM21corp_-- From nobody Sun May 22 22:50:15 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0B7912D14D; Sun, 22 May 2016 22:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 EX5SbPmj_Yo8; Sun, 22 May 2016 22:50:11 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4EB612B010; Sun, 22 May 2016 22:50:11 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u4N5ktoD020604; Sun, 22 May 2016 22:50:10 -0700 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0a-0016f401.pphosted.com with ESMTP id 232n1jn3hd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 22 May 2016 22:50:10 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 23 May 2016 08:50:06 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Mon, 23 May 2016 08:50:06 +0300 From: Tal Mizrahi To: Tal Mizrahi , "draft-ietf-nvo3-geneve@tools.ietf.org" , "draft-ietf-nvo3-vxlan-gpe@tools.ietf.org" , "nvo3@ietf.org" Thread-Topic: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routing-header Thread-Index: AQHRsBu8SjhvsjgfU0qMOZhBsheu65/GDEKg Date: Mon, 23 May 2016 05:50:05 +0000 Message-ID: <569a4067fd1f45dd85d60e983be69b90@IL-EXCH02.marvell.com> References: <5dc56935eba94c2390120244564f9b21@IL-EXCH02.marvell.com> <0551686F-F1D2-4C34-81C8-530F1BEE1BDF@cisco.com> <5d889e7013b44b27ae1e75cf7ea2dd22@IL-EXCH02.marvell.com> <3549ABBE-9828-42D2-A056-851432487E2E@cisco.com> <1e13d2e32b2448af94bf23d5acf17740@IL-EXCH02.marvell.com> In-Reply-To: <1e13d2e32b2448af94bf23d5acf17740@IL-EXCH02.marvell.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-23_02:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1605230068 Archived-At: Cc: "spring@ietf.org" , 6man WG , "Stefano Previdi \(sprevidi\)" , "draft-ietf-6man-segment-routing-header@tools.ietf.org" Subject: Re: [spring] [nvo3] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 05:50:13 -0000 RGVhciBBdXRob3JzIG9mIFZYTEFOLUdQRSAvIEdlbmV2ZSwNCg0KSSBhbSByZWl0ZXJhdGluZyBv biB0aGlzIHF1ZXN0aW9uLCBhcyBJIGhhdmVuJ3Qgc2VlbiBhIHJlc3BvbnNlIHlldDoNCg0KSGF2 ZSB5b3UgY29uc2lkZXJlZCB0aGUgdXNlIG9mIFNlZ21lbnQgUm91dGluZyB3aXRoIFZYTEFOLUdQ RSAvIEdlbmV2ZT8gVGhlIGN1cnJlbnQgVlhMQU4tR1BFIC8gR2VuZXZlIGRyYWZ0cyBzZWVtIHRv IGltcGx5IHRoYXQgSVB2NiBleHRlbnNpb24gaGVhZGVycyBhcmUgY3VycmVudGx5IG5vdCBzdXBw b3J0ZWQuDQoNClRoYW5rcywNClRhbC4NCg0KDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPkZyb206IG52bzMgW21haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBP ZiBUYWwgTWl6cmFoaQ0KPlNlbnQ6IFR1ZXNkYXksIE1heSAxNywgMjAxNiAxMjowOSBQTQ0KPlRv OiBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKTsgVG9tIEhlcmJlcnQ7IGRyYWZ0LWlldGYtbnZv My0NCj5nZW5ldmVAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbnZvMy12eGxhbi1ncGVAdG9v bHMuaWV0Zi5vcmcNCj5DYzogc3ByaW5nQGlldGYub3JnOyBudm8zQGlldGYub3JnOyA2bWFuIFdH OyBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC0NCj5yb3V0aW5nLWhlYWRlckB0b29scy5pZXRmLm9y Zw0KPlN1YmplY3Q6IFJlOiBbbnZvM10gW3NwcmluZ10gTDQgQ2hlY2tzdW0gYW5kIGRyYWZ0LWll dGYtNm1hbi1zZWdtZW50LQ0KPnJvdXRpbmctaGVhZGVyDQo+DQo+U3RlZmFubywNCj4NCj5JZiBJ IHVuZGVyc3RhbmQgeW91ciBwb2ludCBjb3JyZWN0bHk6DQo+SVB2NiBzZWdtZW50IHJvdXRpbmcg ZG9lcyBub3Qgd29yayB3aXRoIFZYTEFOIC8gVlhMQU4tR1BFIC8gR2VuZXZlLCBzaW5jZQ0KPnRo ZXNlIGVuY2Fwc3VsYXRpb25zIGRvIG5vdCBjdXJyZW50bHkgYWxsb3cgdGhlIHVzZSBvZiBJUHY2 IGV4dGVuc2lvbg0KPmhlYWRlcnMuDQo+DQo+SSB3b25kZXIgaWYgdGhlIGF1dGhvcnMgb2YgVlhM QU4tR1BFIGFuZCBHZW5ldmUgaGF2ZSBjb25zaWRlcmVkIHRoZSB1c2Ugb2YNCj5zZWdtZW50IHJv dXRpbmcuDQo+DQo+VGhhbmtzLA0KPlRhbC4NCj4NCj4NCj4NCj4+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+RnJvbTogU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkgW21haWx0bzpzcHJl dmlkaUBjaXNjby5jb21dDQo+PlNlbnQ6IFR1ZXNkYXksIE1heSAxNywgMjAxNiAxMDo0MSBBTQ0K Pj5UbzogVG9tIEhlcmJlcnQNCj4+Q2M6IFRhbCBNaXpyYWhpOyA2bWFuIFdHOyBzcHJpbmdAaWV0 Zi5vcmc7DQo+PmRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctIGhlYWRlckB0b29scy5p ZXRmLm9yZw0KPj5TdWJqZWN0OiBSZTogW3NwcmluZ10gTDQgQ2hlY2tzdW0gYW5kIGRyYWZ0LWll dGYtNm1hbi1zZWdtZW50LXJvdXRpbmctDQo+PmhlYWRlcg0KPj4NCj4+DQo+Pj4gT24gTWF5IDE2 LCAyMDE2LCBhdCA3OjEwIFBNLCBUb20gSGVyYmVydCA8dG9tQGhlcmJlcnRsYW5kLmNvbT4NCj53 cm90ZToNCj4+Pg0KPj4+IE9uIE1vbiwgTWF5IDE2LCAyMDE2IGF0IDQ6MzIgQU0sIFRhbCBNaXpy YWhpIDx0YWxtaUBtYXJ2ZWxsLmNvbT4NCj4+d3JvdGU6DQo+Pj4+PiBpdOKAmXMgYWxsIGFib3V0 IElQLCBub3QgbGF5ZXItMi4NCj4+Pj4+DQo+Pj4+PiBzLg0KPj4+Pg0KPj4+PiBSaWdodC4gSG93 ZXZlciwgaXQgYXBwZWFycyB0aGF0IGF0IGxlYXN0IGluIHNvbWUgY2FzZXMgYSBWWExBTiBWVEVQ DQo+Pj4+IHdpbGwNCj4+dXNlIFNSLiBJdCBjZXJ0YWlubHkgbWF5IGJlIHRoZSBjYXNlIGluIFNG QyB1c2UgY2FzZXMgKHNlZSBTZWN0aW9uIDIuMw0KPj5pbiBkcmFmdC0gaWV0Zi1zcHJpbmctaXB2 Ni11c2UtY2FzZXMpLg0KPj4+Pg0KPj4+DQo+Pj4gZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91 dGluZy1oZWFkZXIgbWVudGlvbnMgdGhhdCB0aGUgcGFja2V0IGlzDQo+Pj4gZW5jYXBzdWxhdGVk DQo+Pg0KPj4NCj4+aW50byBhbiBvdXRlciBpcHY2IGhlYWRlciB3aGljaCBtYWtlcyBpdCBhIGxh eWVyLTMgZW5jYXAuDQo+Pg0KPj4NCj4+PiAsIGJ1dCBJIGRvbid0IHRoaW5rIGl0IGlzIGV4cGxp Y2l0IGFzIHRvIGV4YWN0IGVuY2Fwc3VsYXRpb24gZm9ybWF0DQo+Pj4gKEkgc3VwcG9zZSBzaW1w bGUgaXA2aXA2IGlzIGltcGxpZWQpLg0KPj4NCj4+DQo+PnNlZSBzZWN0aW9uIDIuMg0KPj4NCj4+ DQo+Pj4gQnV0LCBpdA0KPj4+IHNlZW1zIGxpa2UgYW55IG9mIHNldmVyYWwgZW5jYXBzdWxhdGlv biB0ZWNobmlxdWVzIGNvdWxkIHdvcmsgKFZYTEFOLA0KPj4NCj4+DQo+PkkgaGF2ZSBzb21lIHBy b2JsZW1zIHRvIHVuZGVyc3RhbmQgd2hlcmUgdG8gZml0IGFuIGV4dGVuc2lvbiBoZWFkZXINCj4+ aW50byBhIHZ4bGFuIGVuY2Fw4oCmDQo+Pg0KPj4NCj4+PiBHUkUvSVAsIEVTUC9JUCwgR1VFLCBm b28gb3ZlciBVRFAsIGV0Yy4pIGFuZCBpZiBhIGRldmljZSB0aGF0IHdhbnRzDQo+Pj4gdG8gZG8g U1IgaXMgYWxyZWFkeSBkb2luZyB0dW5uZWxpbmcgaXQgc2VlbXMgcmVhc29uYWJsZSB0byBtZSB0 byBvbmx5DQo+Pj4gaGF2ZSBvbmUgbGF5ZXIgb2YgZW5jYXBzdWxhdGlvbi4gTWF5YmUgdGhpcyBz aG91bGQgYmUgY2xhcmlmaWVkIGluDQo+Pj4gdGhlIGRyYWZ0Pw0KPj4NCj4+DQo+PnRoZSBkcmFm dCBpcyBhYm91dCBJUHY2IGV4dGVuc2lvbiBoZWFkZXIgYW5kIG1vcmUgcHJlY2lzZWx5IGEgbmV3 IHR5cGUNCj4+b2YgdGhlIHJvdXRpbmcgZXh0ZW5zaW9uIGhlYWRlciBkZWZpbmVkIGluIHJmYzI0 NjAuIFRoYXTigJlzIHRoZSBjb250ZXh0Lg0KPj4NCj4+DQo+PnMuDQo+Pg0KPj4NCj4+DQo+Pg0K Pj4+DQo+Pj4gVG9tDQo+Pj4NCj4+Pj4NCj4+Pj4NCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+Pj4+PiBGcm9tOiBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKSBbbWFpbHRvOnNw cmV2aWRpQGNpc2NvLmNvbV0NCj4+Pj4+IFNlbnQ6IE1vbmRheSwgTWF5IDE2LCAyMDE2IDI6MjQg UE0NCj4+Pj4+IFRvOiBUYWwgTWl6cmFoaQ0KPj4+Pj4gQ2M6IE9sZSBUcsO4YW47DQo+Pj4+PiBk cmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlckB0b29scy5pZXRmLm9yZzsNCj4+ Pj4+IHNwcmluZ0BpZXRmLm9yZzsgNm1hbiBXRw0KPj4+Pj4gU3ViamVjdDogUmU6IFtzcHJpbmdd IEw0IENoZWNrc3VtIGFuZA0KPj4+Pj4gZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy0g aGVhZGVyDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+PiBPbiBNYXkgMTYsIDIwMTYsIGF0IDE6MTkgUE0s IFRhbCBNaXpyYWhpIDx0YWxtaUBtYXJ2ZWxsLmNvbT4gd3JvdGU6DQo+Pj4+Pj4NCj4+Pj4+PiBI aSBTdGVmYW5vLA0KPj4+Pj4+DQo+Pj4+Pj4gVGhhbmtzIGFnYWluIGZvciB0aGUgcHJvbXB0IHJl c3BvbnNlLg0KPj4+Pj4+DQo+Pj4+Pj4+IDIuIHRoZSBTUkggaXMgb3JpZ2luYXRlZCBieSB0aGUg aW5ncmVzcyBub2RlIG9mIHRoZSBTUiBkb21haW4uDQo+Pj4+Pj4+IFRoaXMgaXMgZG9uZSBieSBl bmNhcHN1bGF0aW5nIHRoZSBwYWNrZXQgaW50byBhIG91dGVyDQo+Pj4+Pj4+IChhZGRpdGlvbmFs KSBpcHY2IGhlYWRlciBmb2xsb3dlZCBieSBhbiBTUkguIFRoaXMgaXMgTDMNCj4+Pj4+Pj4gZW5j YXBzdWxhdGlvbiBhbmQgbm8gTDQgY2hlY2tzdW0gaXMgaW52b2x2ZWQuIFdoZW4gdGhlICBwYWNr ZXQNCj4+Pj4+Pj4gbGVhdmVzIHRoZSBTUiB0dW5uZWwgdGhlIG91dGVyIGVuY2Fwc3VsYXRpb24g IChpbmNsdWRpbmcgdGhlIFNSSCkNCj4+Pj4+Pj4gaXMgcmVtb3ZlZCBhbmQgdGhlIHBhY2tldCBj b250aW51ZXMgIGl0cyBqb3VybmV5IGxpa2Ugbm90aGluZw0KPmhhcHBlbmVkLg0KPj4+Pj4+DQo+ Pj4+Pj4gU28gVlhMQU4gaXMgb2ZmIHRoZSB0YWJsZT8NCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4gaXTi gJlzIGFsbCBhYm91dCBJUCwgbm90IGxheWVyLTIuDQo+Pj4+Pg0KPj4+Pj4gcy4NCj4+Pj4+DQo+ Pj4+Pg0KPj4+Pj4+IEl0IHdvdWxkIGJlIHdvcnRod2hpbGUgdG8gY2xhcmlmeSB0aGlzIGluIHRo ZSBkcmFmdC4gSWYgeW91IGhhdmUgYQ0KPj4+Pj4+IHNwZWNpZmljDQo+Pj4+PiBlbmNhcHN1bGF0 aW9uIGluIG1pbmQsIGl0IHdvdWxkIGJlIGdyZWF0IGlmIHRoZSBkcmFmdCB3b3VsZCBzcGVjaWZ5 IGl0Lg0KPj4+Pj4+DQo+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+IFRhbC4NCj4+Pj4+Pg0KPj4+Pj4+ DQo+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+IEZyb206IFN0ZWZh bm8gUHJldmlkaSAoc3ByZXZpZGkpIFttYWlsdG86c3ByZXZpZGlAY2lzY28uY29tXQ0KPj4+Pj4+ PiBTZW50OiBNb25kYXksIE1heSAxNiwgMjAxNiAyOjEzIFBNDQo+Pj4+Pj4+IFRvOiBUYWwgTWl6 cmFoaQ0KPj4+Pj4+PiBDYzogT2xlIFRyw7hhbjsNCj4+Pj4+Pj4gZHJhZnQtaWV0Zi02bWFuLXNl Z21lbnQtcm91dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmc7DQo+Pj4+Pj4+IHNwcmluZ0BpZXRm Lm9yZzsgNm1hbiBXRw0KPj4+Pj4+PiBTdWJqZWN0OiBSZTogW3NwcmluZ10gTDQgQ2hlY2tzdW0g YW5kDQo+Pj4+Pj4+IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctIGhlYWRlcg0KPj4+ Pj4+Pg0KPj4+Pj4+PiBIaSwNCj4+Pj4+Pj4NCj4+Pj4+Pj4gT24gTWF5IDE2LCAyMDE2LCBhdCAx MTowNCBBTSwgVGFsIE1penJhaGkgPHRhbG1pQG1hcnZlbGwuY29tPg0KPj53cm90ZToNCj4+Pj4+ Pj4+DQo+Pj4+Pj4+PiBIaSBTdGVmYW5vLA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFRoYW5rcyBmb3Ig dGhlIHJlc3BvbnNlcy4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gZXhhY3RseS4NCj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+IE1vcmVvdmVyLCBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRl ciBhc3N1bWVzDQo+Pj4+Pj4+Pj4gZW5jYXBzdWxhdGlvbiBzbyBjbGVhcmx5IHRoZXJl4oCZcyBu byBMNCBpbnZvbHZlZCBoZXJlLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gcy4NCj4+Pj4+Pj4+DQo+ Pj4+Pj4+PiBUd28gcXVlc3Rpb25zOg0KPj4+Pj4+Pj4gMS4gV2hhdCBpZiB0aGUgZW5jYXBzdWxh dGlvbiBpcyBWWExBTj8gTDQgd291bGQgc3RpbGwgYmUNCj4+Pj4+Pj4+IGludm9sdmVkLA0KPj5y aWdodD8NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gU2VlIGJlbG93Lg0KPj4+Pj4+Pg0KPj4+ Pj4+Pg0KPj4+Pj4+Pj4gMi4gV2hlbiB5b3Ugc2F5ICdhc3N1bWVzIGVuY2Fwc3VsYXRpb24nLCBk b2VzIGl0IG1lYW4gdGhhdCBhDQo+Pj4+Pj4+PiBob3N0IGNhbm5vdA0KPj4+Pj4+PiBzZW5kIGFu IElQdjYgcGFja2V0IHdpdGggYW4gU1JIPyBUaGUgY3VycmVudCBkcmFmdCBzYXlzOg0KPj4+Pj4+ Pj4NCj4+Pj4+Pj4+IEEgU291cmNlIFNSIE5vZGUgY2FuIGJlIGFueSBub2RlIG9yaWdpbmF0aW5n IGFuIElQdjYgcGFja2V0IHdpdGgNCj4+Pj4+Pj4+IGl0cw0KPj4+Pj4+Pj4gSVB2NiBhbmQgU2Vn bWVudCBSb3V0aW5nIEhlYWRlcnMuICBUaGlzIGluY2x1ZGUgZWl0aGVyOg0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4+ICAgIEEgaG9zdCBvcmlnaW5hdGluZyBhbiBJUHY2IHBhY2tldC4NCj4+Pj4+Pj4+DQo+ Pj4+Pj4+PiAgICBBbiBTUiBkb21haW4gaW5ncmVzcyByb3V0ZXIgZW5jYXBzdWxhdGluZyBhIHJl Y2VpdmVkIElQdjYgcGFja2V0DQo+Pj4+Pj4+PiAgICBpbnRvIGFuIG91dGVyIElQdjYgaGVhZGVy IGZvbGxvd2VkIGJ5IGFuIFNSSC4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+ Pj4+IFdpbGwgYXBwcmVjaWF0ZSBpZiB5b3UgY2FuIGNsYXJpZnkgdGhhdC4NCj4+Pj4+Pj4NCj4+ Pj4+Pj4NCj4+Pj4+Pj4gb2ssIHR3byBjYXNlczoNCj4+Pj4+Pj4NCj4+Pj4+Pj4gMS4gdGhlIFNS SCBpcyBpbnNlcnRlZCBhdCB0aGUgc291cmNlLg0KPj4+Pj4+PiB0aGUgc291cmNlIG9yaWdpbmF0 ZXMgdGhlIHBhY2tldCwgdGhlIGlwdjYgaGVhZGVyIGFuZCAgdGhlIFNSSC4NCj4+Pj4+Pj4gVGhl IHNvdXJjZSBjb21wdXRlcyBMNCBjaGVja3N1bSB0YWtpbmcgaW50byAgYWNjb3VudCB0aGUgd2hv bGUNCj4+SVB2NitTUkguDQo+Pj4+Pj4+IEhlcmUsIHRoZXJlc+KAmSBub3RoaW5nIG5ldyAgY29t cGFyZWQgdG8gcmZjMjQ2MC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gMi4gdGhlIFNSSCBpcyBvcmlnaW5h dGVkIGJ5IHRoZSBpbmdyZXNzIG5vZGUgb2YgdGhlIFNSIGRvbWFpbi4NCj4+Pj4+Pj4gVGhpcyBp cyBkb25lIGJ5IGVuY2Fwc3VsYXRpbmcgdGhlIHBhY2tldCBpbnRvIGEgb3V0ZXINCj4+Pj4+Pj4g KGFkZGl0aW9uYWwpIGlwdjYgaGVhZGVyIGZvbGxvd2VkIGJ5IGFuIFNSSC4gVGhpcyBpcyBMMw0K Pj4+Pj4+PiBlbmNhcHN1bGF0aW9uIGFuZCBubyBMNCBjaGVja3N1bSBpcyBpbnZvbHZlZC4gV2hl biB0aGUgIHBhY2tldA0KPj4+Pj4+PiBsZWF2ZXMgdGhlIFNSIHR1bm5lbCB0aGUgb3V0ZXIgZW5j YXBzdWxhdGlvbiAgKGluY2x1ZGluZyB0aGUgU1JIKQ0KPj4+Pj4+PiBpcyByZW1vdmVkIGFuZCB0 aGUgcGFja2V0IGNvbnRpbnVlcyAgaXRzIGpvdXJuZXkgbGlrZSBub3RoaW5nDQo+aGFwcGVuZWQu DQo+Pj4+Pj4+DQo+Pj4+Pj4+IHMuDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4gVGhhbmtzLA0KPj4+Pj4+Pj4gVGFsLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+IEZyb206IFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZp ZGkpIFttYWlsdG86c3ByZXZpZGlAY2lzY28uY29tXQ0KPj4+Pj4+Pj4+IFNlbnQ6IE1vbmRheSwg TWF5IDE2LCAyMDE2IDExOjU5IEFNDQo+Pj4+Pj4+Pj4gVG86IE9sZSBUcsO4YW47IFRhbCBNaXpy YWhpDQo+Pj4+Pj4+Pj4gQ2M6IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVy QHRvb2xzLmlldGYub3JnOw0KPj4+Pj4+Pj4+IHNwcmluZ0BpZXRmLm9yZzsgNm1hbiBXRw0KPj4+ Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBMNCBDaGVja3N1bSBhbmQNCj4+Pj4+Pj4+PiBk cmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLSBoZWFkZXINCj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+DQo+Pj4+Pj4+Pj4+IE9uIE1heSAxNSwgMjAxNiwgYXQgODowNiBQTSwgb3Ryb2FuQGVtcGxv eWVlcy5vcmcgd3JvdGU6DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFRhbCwNCj4+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4+IFtBcG9sb2dpZXMgaWYgdGhpcyBpc3N1ZSBoYXMgYmVlbiBkaXNjdXNzZWQg YmVmb3JlLl0NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBBY2NvcmRpbmcgdG8gZHJhZnQtaWV0 Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXIsIGFuIOKAmFNSDQo+Pj4+Pj4+Pj4+PiBTZWdt ZW50DQo+Pj4+Pj4+Pj4gRW5kcG9pbnQgTm9kZeKAmSB1cGRhdGVzIHRoZSBEZXN0aW5hdGlvbiBJ UCBhZGRyZXNzLg0KPj4+Pj4+Pj4+Pj4gVGhlcmVmb3JlLCBpdCBtdXN0IGFsc28gdXBkYXRlIHRo ZSBMYXllciA0IENoZWNrc3VtLCByaWdodD8NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBJIHdv bmRlciBpZiB0aGVyZSBpcyBhbiB1cHBlciBib3VuZCBvbiB0aGUgc2l6ZSBvZiB0aGUgU1JILg0K Pj4+Pj4+Pj4+Pj4gT3RoZXJ3aXNlLCB0aGUNCj4+Pj4+Pj4+PiBMNCBDaGVja3N1bSBtYXkgYmUg bG9jYXRlZCBpbiBhIHByZXR0eSBkZWVwIGxvY2F0aW9uLg0KPj4+Pj4+Pj4+Pj4gU3BlYWtpbmcg ZnJvbSBhIGNoaXAgdmVuZG9y4oCZcyBwZXJzcGVjdGl2ZSB0aGlzIG1heSBiZSBhIHByb2JsZW0u DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEZyb20gUkZDMjQ2MCwgUkgwOg0KPj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiAgIG8gIElmIHRoZSBJUHY2IHBhY2tldCBjb250YWlucyBh IFJvdXRpbmcgaGVhZGVyLCB0aGUgRGVzdGluYXRpb24NCj4+Pj4+Pj4+Pj4gICAgICBBZGRyZXNz IHVzZWQgaW4gdGhlIHBzZXVkby1oZWFkZXIgaXMgdGhhdCBvZiB0aGUgZmluYWwNCj4+Pj4+Pj4+ Pj4gICAgICBkZXN0aW5hdGlvbi4gIEF0IHRoZSBvcmlnaW5hdGluZyBub2RlLCB0aGF0IGFkZHJl c3Mgd2lsbCBiZSBpbg0KPj4+Pj4+Pj4+PiAgICAgIHRoZSBsYXN0IGVsZW1lbnQgb2YgdGhlIFJv dXRpbmcgaGVhZGVyOyBhdCB0aGUgcmVjaXBpZW50KHMpLA0KPj4+Pj4+Pj4+PiAgICAgIHRoYXQg YWRkcmVzcyB3aWxsIGJlIGluIHRoZSBEZXN0aW5hdGlvbiBBZGRyZXNzIGZpZWxkIG9mIHRoZQ0K Pj4+Pj4+Pj4+PiAgICAgIElQdjYgaGVhZGVyLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBJIHdv dWxkIGV4cGVjdCBTUiB3b3VsZCB3b3JrIHRoZSBzYW1lLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+PiBleGFjdGx5Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gTW9yZW92ZXIsIGRyYWZ0 LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyIGFzc3VtZXMNCj4+Pj4+Pj4+PiBlbmNh cHN1bGF0aW9uIHNvIGNsZWFybHkgdGhlcmXigJlzIG5vIEw0IGludm9sdmVkIGhlcmUuDQo+Pj4+ Pj4+Pj4NCj4+Pj4+Pj4+PiBzLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+Pj4gQ2hlZXJzLA0KPj4+Pj4+Pj4+PiBPbGUNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+ Pj4+Pj4NCj4+Pj4NCj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4gSUVURiBJUHY2IHdvcmtpbmcgZ3Jv dXAgbWFpbGluZyBsaXN0IGlwdjZAaWV0Zi5vcmcgQWRtaW5pc3RyYXRpdmUNCj4+Pj4gUmVxdWVz dHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2Ng0KPj4+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+bnZvMyBtYWlsaW5nIGxpc3QNCj5udm8zQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zDQo= From nobody Mon May 23 00:29:18 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68FA712D0BF; Mon, 23 May 2016 00:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRGNprOEz4-z; Mon, 23 May 2016 00:29:08 -0700 (PDT) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::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 A242812D099; Mon, 23 May 2016 00:29:07 -0700 (PDT) Received: by mail-lf0-x236.google.com with SMTP id e131so20829956lfb.0; Mon, 23 May 2016 00:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=s4B5Rh9/mUUCqsmhxguw5triCijipJL/6g/nmkbOSBc=; b=ZN6s+Tet48hSnWaXaTnUIB6FU07OvforVhgr3veAul1fBMfMhTiVRwYnn7MAJBOj1q y3I2WxNsimz25cu5/ZTkrcfahFL816dV08bnou6kLwJhjMfBgyHuhuUseL2UOVOwR7LS QahDj2968LWifUmOureL3DOkuVC7kfwAyPMfTi0FthPaf7yTor0gvvgsfswQfdkU1KP8 ArzWssA0xg8a8Iv2HHbC7Um24Hj9/dKiwa5FXqpPf/XLOPCISAPMrJIFay5mvfZinR/L dPkgt4XLHIlX5xUGzXuJ83Gyk7zevYY1lwPvNoL2gMV76Tqe8F35TrKbKPwzVyQHo6VO Avfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=s4B5Rh9/mUUCqsmhxguw5triCijipJL/6g/nmkbOSBc=; b=cmjR3jZQf7biexQpzd3tqp8r8Ansdz1ZwOw+dC8OzY93w6lM6LX+C464y+gOuMaMKI XAmkwMzVJr4amUq6H2kztzxEsirfYAwy4z7tEhv1qqN9P3dROJy6NJfAV/vWoYB8yA7U 5G1Nmn3UdS1/+rbWwCB1FkqgpZzb2oqmGitAJ7PXkMt6VgiZpwcbyelbxGLY6nl/XPNm wHk91CQSPYpT8Xguow3+YGueFPF6fF/o4ei2lKJv+XLwTXh2Wym5JvQKtNPno75q7eAh zR52V+VR5+1EKEwDhQ05HvgsKUdg78YfsW9asXzOP54VaFwnKteaUk2ygoA3Dn4fMw8N lUAg== X-Gm-Message-State: AOPr4FVRzu0qoBCnZ2na0R3sEIF3j2eQW4VP0Eg40+NcfVIs6LliwSwXRHRcZ+JWmcIzoAhpD94jdH4QXO2vew== MIME-Version: 1.0 X-Received: by 10.25.21.156 with SMTP id 28mr4948594lfv.124.1463988545643; Mon, 23 May 2016 00:29:05 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.126.210 with HTTP; Mon, 23 May 2016 00:29:05 -0700 (PDT) In-Reply-To: <569a4067fd1f45dd85d60e983be69b90@IL-EXCH02.marvell.com> References: <5dc56935eba94c2390120244564f9b21@IL-EXCH02.marvell.com> <0551686F-F1D2-4C34-81C8-530F1BEE1BDF@cisco.com> <5d889e7013b44b27ae1e75cf7ea2dd22@IL-EXCH02.marvell.com> <3549ABBE-9828-42D2-A056-851432487E2E@cisco.com> <1e13d2e32b2448af94bf23d5acf17740@IL-EXCH02.marvell.com> <569a4067fd1f45dd85d60e983be69b90@IL-EXCH02.marvell.com> Date: Mon, 23 May 2016 09:29:05 +0200 X-Google-Sender-Auth: Gwlpm2S0do1YjcmM6l2AwkMR__E Message-ID: From: Robert Raszuk To: Tal Mizrahi Content-Type: multipart/alternative; boundary=001a1140677637ee3c05337d65c8 Archived-At: Cc: "spring@ietf.org" , 6man WG , "draft-ietf-nvo3-vxlan-gpe@tools.ietf.org" , "nvo3@ietf.org" , "draft-ietf-6man-segment-routing-header@tools.ietf.org" , "draft-ietf-nvo3-geneve@tools.ietf.org" , "Stefano Previdi \(sprevidi\)" Subject: Re: [spring] [nvo3] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 07:29:11 -0000 --001a1140677637ee3c05337d65c8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tal, > drafts seem to imply Where say in draft draft-quinn-vxlan-gpe do you see such statement that would imply that v6 NxtHdr must be only equal to 17 (UDP) and not be a pointer to any other type of extension header further followed by UDP ? Thx, R. On Mon, May 23, 2016 at 7:50 AM, Tal Mizrahi wrote: > Dear Authors of VXLAN-GPE / Geneve, > > I am reiterating on this question, as I haven't seen a response yet: > > Have you considered the use of Segment Routing with VXLAN-GPE / Geneve? > The current VXLAN-GPE / Geneve drafts seem to imply that IPv6 extension > headers are currently not supported. > > Thanks, > Tal. > > > > >-----Original Message----- > >From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Tal Mizrahi > >Sent: Tuesday, May 17, 2016 12:09 PM > >To: Stefano Previdi (sprevidi); Tom Herbert; draft-ietf-nvo3- > >geneve@tools.ietf.org; draft-ietf-nvo3-vxlan-gpe@tools.ietf.org > >Cc: spring@ietf.org; nvo3@ietf.org; 6man WG; draft-ietf-6man-segment- > >routing-header@tools.ietf.org > >Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment- > >routing-header > > > >Stefano, > > > >If I understand your point correctly: > >IPv6 segment routing does not work with VXLAN / VXLAN-GPE / Geneve, sinc= e > >these encapsulations do not currently allow the use of IPv6 extension > >headers. > > > >I wonder if the authors of VXLAN-GPE and Geneve have considered the use = of > >segment routing. > > > >Thanks, > >Tal. > > > > > > > >>-----Original Message----- > >>From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] > >>Sent: Tuesday, May 17, 2016 10:41 AM > >>To: Tom Herbert > >>Cc: Tal Mizrahi; 6man WG; spring@ietf.org; > >>draft-ietf-6man-segment-routing- header@tools.ietf.org > >>Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing- > >>header > >> > >> > >>> On May 16, 2016, at 7:10 PM, Tom Herbert > >wrote: > >>> > >>> On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi > >>wrote: > >>>>> it=E2=80=99s all about IP, not layer-2. > >>>>> > >>>>> s. > >>>> > >>>> Right. However, it appears that at least in some cases a VXLAN VTEP > >>>> will > >>use SR. It certainly may be the case in SFC use cases (see Section 2.3 > >>in draft- ietf-spring-ipv6-use-cases). > >>>> > >>> > >>> draft-ietf-6man-segment-routing-header mentions that the packet is > >>> encapsulated > >> > >> > >>into an outer ipv6 header which makes it a layer-3 encap. > >> > >> > >>> , but I don't think it is explicit as to exact encapsulation format > >>> (I suppose simple ip6ip6 is implied). > >> > >> > >>see section 2.2 > >> > >> > >>> But, it > >>> seems like any of several encapsulation techniques could work (VXLAN, > >> > >> > >>I have some problems to understand where to fit an extension header > >>into a vxlan encap=E2=80=A6 > >> > >> > >>> GRE/IP, ESP/IP, GUE, foo over UDP, etc.) and if a device that wants > >>> to do SR is already doing tunneling it seems reasonable to me to only > >>> have one layer of encapsulation. Maybe this should be clarified in > >>> the draft? > >> > >> > >>the draft is about IPv6 extension header and more precisely a new type > >>of the routing extension header defined in rfc2460. That=E2=80=99s the = context. > >> > >> > >>s. > >> > >> > >> > >> > >>> > >>> Tom > >>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] > >>>>> Sent: Monday, May 16, 2016 2:24 PM > >>>>> To: Tal Mizrahi > >>>>> Cc: Ole Tr=C3=B8an; > >>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org; > >>>>> spring@ietf.org; 6man WG > >>>>> Subject: Re: [spring] L4 Checksum and > >>>>> draft-ietf-6man-segment-routing- header > >>>>> > >>>>> > >>>>>> On May 16, 2016, at 1:19 PM, Tal Mizrahi wrote= : > >>>>>> > >>>>>> Hi Stefano, > >>>>>> > >>>>>> Thanks again for the prompt response. > >>>>>> > >>>>>>> 2. the SRH is originated by the ingress node of the SR domain. > >>>>>>> This is done by encapsulating the packet into a outer > >>>>>>> (additional) ipv6 header followed by an SRH. This is L3 > >>>>>>> encapsulation and no L4 checksum is involved. When the packet > >>>>>>> leaves the SR tunnel the outer encapsulation (including the SRH) > >>>>>>> is removed and the packet continues its journey like nothing > >happened. > >>>>>> > >>>>>> So VXLAN is off the table? > >>>>> > >>>>> > >>>>> it=E2=80=99s all about IP, not layer-2. > >>>>> > >>>>> s. > >>>>> > >>>>> > >>>>>> It would be worthwhile to clarify this in the draft. If you have a > >>>>>> specific > >>>>> encapsulation in mind, it would be great if the draft would specify > it. > >>>>>> > >>>>>> Thanks, > >>>>>> Tal. > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] > >>>>>>> Sent: Monday, May 16, 2016 2:13 PM > >>>>>>> To: Tal Mizrahi > >>>>>>> Cc: Ole Tr=C3=B8an; > >>>>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org; > >>>>>>> spring@ietf.org; 6man WG > >>>>>>> Subject: Re: [spring] L4 Checksum and > >>>>>>> draft-ietf-6man-segment-routing- header > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> On May 16, 2016, at 11:04 AM, Tal Mizrahi > >>wrote: > >>>>>>>> > >>>>>>>> Hi Stefano, > >>>>>>>> > >>>>>>>> Thanks for the responses. > >>>>>>>> > >>>>>>>>> exactly. > >>>>>>>>> > >>>>>>>>> Moreover, draft-ietf-6man-segment-routing-header assumes > >>>>>>>>> encapsulation so clearly there=E2=80=99s no L4 involved here. > >>>>>>>>> > >>>>>>>>> s. > >>>>>>>> > >>>>>>>> Two questions: > >>>>>>>> 1. What if the encapsulation is VXLAN? L4 would still be > >>>>>>>> involved, > >>right? > >>>>>>> > >>>>>>> > >>>>>>> See below. > >>>>>>> > >>>>>>> > >>>>>>>> 2. When you say 'assumes encapsulation', does it mean that a > >>>>>>>> host cannot > >>>>>>> send an IPv6 packet with an SRH? The current draft says: > >>>>>>>> > >>>>>>>> A Source SR Node can be any node originating an IPv6 packet with > >>>>>>>> its > >>>>>>>> IPv6 and Segment Routing Headers. This include either: > >>>>>>>> > >>>>>>>> A host originating an IPv6 packet. > >>>>>>>> > >>>>>>>> An SR domain ingress router encapsulating a received IPv6 > packet > >>>>>>>> into an outer IPv6 header followed by an SRH. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Will appreciate if you can clarify that. > >>>>>>> > >>>>>>> > >>>>>>> ok, two cases: > >>>>>>> > >>>>>>> 1. the SRH is inserted at the source. > >>>>>>> the source originates the packet, the ipv6 header and the SRH. > >>>>>>> The source computes L4 checksum taking into account the whole > >>IPv6+SRH. > >>>>>>> Here, theres=E2=80=99 nothing new compared to rfc2460. > >>>>>>> > >>>>>>> 2. the SRH is originated by the ingress node of the SR domain. > >>>>>>> This is done by encapsulating the packet into a outer > >>>>>>> (additional) ipv6 header followed by an SRH. This is L3 > >>>>>>> encapsulation and no L4 checksum is involved. When the packet > >>>>>>> leaves the SR tunnel the outer encapsulation (including the SRH) > >>>>>>> is removed and the packet continues its journey like nothing > >happened. > >>>>>>> > >>>>>>> s. > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Tal. > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] > >>>>>>>>> Sent: Monday, May 16, 2016 11:59 AM > >>>>>>>>> To: Ole Tr=C3=B8an; Tal Mizrahi > >>>>>>>>> Cc: draft-ietf-6man-segment-routing-header@tools.ietf.org; > >>>>>>>>> spring@ietf.org; 6man WG > >>>>>>>>> Subject: Re: [spring] L4 Checksum and > >>>>>>>>> draft-ietf-6man-segment-routing- header > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> On May 15, 2016, at 8:06 PM, otroan@employees.org wrote: > >>>>>>>>>> > >>>>>>>>>> Tal, > >>>>>>>>>> > >>>>>>>>>>> [Apologies if this issue has been discussed before.] > >>>>>>>>>>> > >>>>>>>>>>> According to draft-ietf-6man-segment-routing-header, an =E2= =80=98SR > >>>>>>>>>>> Segment > >>>>>>>>> Endpoint Node=E2=80=99 updates the Destination IP address. > >>>>>>>>>>> Therefore, it must also update the Layer 4 Checksum, right? > >>>>>>>>>>> > >>>>>>>>>>> I wonder if there is an upper bound on the size of the SRH. > >>>>>>>>>>> Otherwise, the > >>>>>>>>> L4 Checksum may be located in a pretty deep location. > >>>>>>>>>>> Speaking from a chip vendor=E2=80=99s perspective this may be= a > problem. > >>>>>>>>>> > >>>>>>>>>> From RFC2460, RH0: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> o If the IPv6 packet contains a Routing header, the > Destination > >>>>>>>>>> Address used in the pseudo-header is that of the final > >>>>>>>>>> destination. At the originating node, that address will > be in > >>>>>>>>>> the last element of the Routing header; at the > recipient(s), > >>>>>>>>>> that address will be in the Destination Address field of > the > >>>>>>>>>> IPv6 header. > >>>>>>>>>> > >>>>>>>>>> I would expect SR would work the same. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> exactly. > >>>>>>>>> > >>>>>>>>> Moreover, draft-ietf-6man-segment-routing-header assumes > >>>>>>>>> encapsulation so clearly there=E2=80=99s no L4 involved here. > >>>>>>>>> > >>>>>>>>> s. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Cheers, > >>>>>>>>>> Ole > >>>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >>>> -------------------------------------------------------------------- > >>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>> -------------------------------------------------------------------- > > > >_______________________________________________ > >nvo3 mailing list > >nvo3@ietf.org > >https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --001a1140677637ee3c05337d65c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a113f8f70bebf6a0533881518-- From nobody Mon May 23 13:20:11 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9491D12DB60; Mon, 23 May 2016 13:20:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.346 X-Spam-Level: X-Spam-Status: No, score=-8.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 UgO_AtcIg0l9; Mon, 23 May 2016 13:20:00 -0700 (PDT) Received: from smtp-outbound-1.vmware.com (smtp-outbound-1.vmware.com [208.91.2.12]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE09D12DB5C; Mon, 23 May 2016 13:20:00 -0700 (PDT) Received: from sc9-mailhost3.vmware.com (sc9-mailhost3.vmware.com [10.113.161.73]) by smtp-outbound-1.vmware.com (Postfix) with ESMTP id 67E0C98602; Mon, 23 May 2016 13:19:59 -0700 (PDT) Received: from EX13-CAS-002.vmware.com (ex13-cas-002.vmware.com [10.113.191.52]) by sc9-mailhost3.vmware.com (Postfix) with ESMTP id 344A4405D9; Mon, 23 May 2016 13:20:00 -0700 (PDT) Received: from EX13-MBX-005.vmware.com (10.113.191.25) by EX13-MBX-020.vmware.com (10.113.191.40) with Microsoft SMTP Server (TLS) id 15.0.1156.6; Mon, 23 May 2016 13:19:59 -0700 Received: from EX13-MBX-005.vmware.com ([fe80::e806:206:d943:a7c9]) by EX13-MBX-005.vmware.com ([fe80::e806:206:d943:a7c9%15]) with mapi id 15.00.1156.000; Mon, 23 May 2016 13:19:59 -0700 From: Jesse Gross To: Robert Raszuk , Tal Mizrahi Thread-Topic: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routing-header Thread-Index: AQHRtMWqMRO7Jj7qMECzlvUXO0D9Pp/Gmj6AgAACKYCAAARfAIAAVqIA Date: Mon, 23 May 2016 20:19:58 +0000 Message-ID: <36D9FCF0-382C-4669-85A5-C782636A85BB@vmware.com> References: <5dc56935eba94c2390120244564f9b21@IL-EXCH02.marvell.com> <0551686F-F1D2-4C34-81C8-530F1BEE1BDF@cisco.com> <5d889e7013b44b27ae1e75cf7ea2dd22@IL-EXCH02.marvell.com> <3549ABBE-9828-42D2-A056-851432487E2E@cisco.com> <1e13d2e32b2448af94bf23d5acf17740@IL-EXCH02.marvell.com> <569a4067fd1f45dd85d60e983be69b90@IL-EXCH02.marvell.com> <1c27bb3513bc48889ec310e8d143784c@IL-EXCH02.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.113.170.11] Content-Type: multipart/alternative; boundary="_000_36D9FCF0382C466985A5C782636A85BBvmwarecom_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , 6man WG , "draft-ietf-nvo3-vxlan-gpe@tools.ietf.org" , "nvo3@ietf.org" , "draft-ietf-6man-segment-routing-header@tools.ietf.org" , "draft-ietf-nvo3-geneve@tools.ietf.org" , "Stefano Previdi \(sprevidi\)" Subject: Re: [spring] [nvo3] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 20:20:04 -0000 --_000_36D9FCF0382C466985A5C782636A85BBvmwarecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB0aGF0IEkgZG9u4oCZdCBiZWxpZXZlIHRoYXQgdGhlcmUgaXMgYW55dGhpbmcgaW4g dGhlc2UgZHJhZnRzIHRoYXQgcHJlY2x1ZGVzIHRoZSB1c2Ugb2YgZXh0ZW5zaW9uIGhlYWRlcnMg b3Igc2VnbWVudCByb3V0aW5nIOKAkyBJUCBpcyBzaW1wbHkgdGhlIGxheWVyIHVuZGVybmVhdGgg dGhhdCB0aGVzZSBwcm90b2NvbHMgYXJlIGJ1aWxkaW5nIG9uLiBUaGUgZmlndXJlcyBhcmUgZGVm aW5pdGVseSBqdXN0IGV4YW1wbGVzIOKAkyB0aGV5IGFsc28gc2hvdyBvdXRlciBFdGhlcm5ldCBo ZWFkZXJzLCB3aGljaCBpcyBub3QgYSByZXF1aXJlbWVudC4NCg0KSSB3b3VsZG7igJl0IHdhbnQg dG8gYWRkIHRleHQgc3BlY2lmaWNhbGx5IHN0YXRpbmcgdGhhdCBleHRlbnNpb24gaGVhZGVycyBh cmUgcGVybWlzc2libGUuIEl0IHNlZW1zIGxpa2UgdGhhdCBjb3VsZCBsZWFkIHRvIHNpbWlsYXIg cXVlc3Rpb25zIGluIHRoZSBmdXR1cmUgd2hlcmUgb25lIG1pZ2h0IHdvbmRlciBpZiBvdGhlciBm ZWF0dXJlcyBvZiBJUCBhcmUgYWxsb3dlZCBiZWNhdXNlIG9uZSBpcyBleHBsaWNpdGx5IGxpc3Rl ZCBhbmQgb3RoZXJzIGFyZSBub3QsIGV0Yy4gSW4gbXkgb3BpbmlvbiwgdGhlIGRyYWZ0cyBhcmUg YWJvdXQgYXMgY2xlYXIgYXMgdGhleSBjYW4gYmUgb24gdGhpcyBwb2ludC4NCg0KSmVzc2UNCg0K T24gNS8yMy8xNiwgMTowOSBBTSwgInJyYXN6dWtAZ21haWwuY29tPG1haWx0bzpycmFzenVrQGdt YWlsLmNvbT4gb24gYmVoYWxmIG9mIFJvYmVydCBSYXN6dWsiIDxycmFzenVrQGdtYWlsLmNvbTxt YWlsdG86cnJhc3p1a0BnbWFpbC5jb20+IG9uIGJlaGFsZiBvZiByb2JlcnRAcmFzenVrLm5ldDxt YWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+PiB3cm90ZToNCg0KSGkgVGFsLA0KDQo+IEluIG9yZGVy IHRvIGF2b2lkIGFtYmlndWl0eSwgaXQgd291bGQgYmUgZ3JlYXQgaWYgdGhlDQo+IGF1dGhvcnMg Y291bGQgZXhwbGljaXRseSBtZW50aW9uIHRoYXQgSVB2NiBleHRlbnNpb24NCj4gaGVhZGVycyBh cmUgcGVybWl0dGVkLg0KDQpXZWxsIHRoZSBkcmFmdHMgYXJlIGNvbXBsYWludCB0byBSRkMyMTE5 IChub3JtYXRpdmUgcmVmZXJlbmNlKSBzbyB1bmxlc3MgdGhlIHRleHQgZXhjbHVkZXMgZWxlbWVu dHMgd2l0aCBNVVNUL01VU1QgTk9UIC0gZXZlcnl0aGluZyBlbHNlIGRlZmluZWQgaW4gdGhlIGJ1 aWxkaW5nIGJsb2NrcyB0aGV5IChyZSl1c2UgaXMgcGVybWl0dGVkLg0KDQpIb3dldmVyIGFzIHlv dSBzYXkgcGVyaGFwcyBmb3IgY2xhcml0eSB3aGF0IGNvdWxkIGJlIGFkZGVkIHRvIHRob3NlIGRy YWZ0cyBpcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gSVB2NCBhbmQgSVB2NiBiYXNlIFJGQ3Mu DQoNCkJlc3QsDQpSLg0KDQoNCk9uIE1vbiwgTWF5IDIzLCAyMDE2IGF0IDk6NTQgQU0sIFRhbCBN aXpyYWhpIDx0YWxtaUBtYXJ2ZWxsLmNvbTxtYWlsdG86dGFsbWlAbWFydmVsbC5jb20+PiB3cm90 ZToNCkhpIFJvYmVydCwNCg0KVGhhdCBtYWtlcyBzZW5zZS4NCkhvd2V2ZXIsIGluIHRoaXMgY2Fz ZSB0aGUgZmlndXJlcyBtYXkgYmUgYSBiaXQgY29uZnVzaW5nIFdSVCB0aGUgcG9zc2libGUgZXhp c3RlbmNlIG9mIGV4dGVuc2lvbiBoZWFkZXJzLiBUaGlzIGNvbmZ1c2lvbiBpcyB3aGF0IGxlZCB0 byB0aGUgZGlzY3Vzc2lvbiBpbiB0aGlzIHRocmVhZCBhYm91dCB3aGV0aGVyIHNlZ21lbnQgcm91 dGluZyBpcyBwb3NzaWJsZSB3aXRoIFZYTEFOL1ZYTEFOLUdQRS9HZW5ldmUgZW5jYXBzdWxhdGlv bnMuDQoNCkluIG9yZGVyIHRvIGF2b2lkIGFtYmlndWl0eSwgaXQgd291bGQgYmUgZ3JlYXQgaWYg dGhlIGF1dGhvcnMgY291bGQgZXhwbGljaXRseSBtZW50aW9uIHRoYXQgSVB2NiBleHRlbnNpb24g aGVhZGVycyBhcmUgcGVybWl0dGVkLg0KDQpSZWdhcmRzLA0KVGFsLg0KDQpGcm9tOnJyYXN6dWtA Z21haWwuY29tPG1haWx0bzpycmFzenVrQGdtYWlsLmNvbT4gW21haWx0bzpycmFzenVrQGdtYWls LmNvbTxtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20+XSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1 aw0KU2VudDogTW9uZGF5LCBNYXkgMjMsIDIwMTYgMTA6NDcgQU0NCg0KVG86IFRhbCBNaXpyYWhp DQpDYzogc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+OyA2bWFuIFdHOyBk cmFmdC1pZXRmLW52bzMtdnhsYW4tZ3BlQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRm LW52bzMtdnhsYW4tZ3BlQHRvb2xzLmlldGYub3JnPjsgbnZvM0BpZXRmLm9yZzxtYWlsdG86bnZv M0BpZXRmLm9yZz47IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyQHRvb2xz LmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlckB0 b29scy5pZXRmLm9yZz47IGRyYWZ0LWlldGYtbnZvMy1nZW5ldmVAdG9vbHMuaWV0Zi5vcmc8bWFp bHRvOmRyYWZ0LWlldGYtbnZvMy1nZW5ldmVAdG9vbHMuaWV0Zi5vcmc+OyBTdGVmYW5vIFByZXZp ZGkgKHNwcmV2aWRpKQ0KU3ViamVjdDogUmU6IFtudm8zXSBbc3ByaW5nXSBMNCBDaGVja3N1bSBh bmQgZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXINCg0KSGkgVGFsLA0KDQpJ bmRlZWQgLi4gSSBzYXcgdGhlIGZpZ3VyZXMsIGJ1dCBmaWd1cmVzIGFyZSBub24gbm9ybWF0aXZl IGluIGFueSBkcmFmdC9yZmMgdW5sZXNzIHRleHQgYmVsb3cgc3BlY2lmaWNhbGx5IHNwZWxscyBp dCBvdXQuDQoNCkZvciBleGFtcGxlIGZyb20gdnhsYW4tZ3BlOg0KDQoiV2hlbiB0aGUgb3V0ZXIg SVAgaGVhZGVyIGlzIElQdjQsIFZURVBzIE1VU1Qgc2V0IHRoZSBERiBiaXQuIg0KDQpCZXNpZGVz IGl0IGlzIHByZXR0eSBjaGFsbGVuZ2luZyB0byBhZGQgYW5pbWF0aW9uIHRvIHRoZSBjdXJyZW50 IGRyYWZ0IGZvcm1hdHMgdG8gaWxsdXN0cmF0ZSBhbGwgcG9zc2libHkgYWxsb3dlZCBmaWVsZCB2 YWx1ZXMvY29tYmluYXRpb25zIGluIGFueSBmaWd1cmUgOikgIEZpZ3VyZXMganVzdCBpbGx1c3Ry YXRlIG9uZSB1c2UgZXhhbXBsZS4NCg0KVG8gbWUgdGhlIGN1cnJlbnQgc3BlY3MgcGVybWl0IGFu eSB2YWx1ZSBvZiBJUHY2IE54dEhkciBmaWVsZCBhcyBwZXJtaXR0ZWQgaW4gYm90aCBlbmNhcHN1 bGF0aW9ucy4NCg0KQmVzdCwNClJvYmVydC4NCg0KDQpPbiBNb24sIE1heSAyMywgMjAxNiBhdCA5 OjM1IEFNLCBUYWwgTWl6cmFoaSA8dGFsbWlAbWFydmVsbC5jb208bWFpbHRvOnRhbG1pQG1hcnZl bGwuY29tPj4gd3JvdGU6DQpIaSBSb2JlcnQsDQoNCg0KPldoZXJlIHNheSBpbiBkcmFmdCBkcmFm dC1xdWlubi12eGxhbi1ncGUgZG8geW91IHNlZSBzdWNoIHN0YXRlbWVudCB0aGF0IHdvdWxkIGlt cGx5DQo+IHRoYXQgdjYgTnh0SGRyIG11c3QgYmUgb25seSBlcXVhbCB0byAxNyAoVURQKSBhbmQg bm90IGJlIGEgcG9pbnRlciB0byBhbnkgb3RoZXIgdHlwZQ0KPiBvZiBleHRlbnNpb24gaGVhZGVy IGZ1cnRoZXIgZm9sbG93ZWQgYnkgVURQID8NCg0KDQpUaGUgZm9sbG93aW5nIHRleHQgaXMgZnJv bSBGaWd1cmUgNCBpbiBkcmFmdC1pZXRmLW52bzMtdnhsYW4tZ3BlOg0KDQogICAgICBPdXRlciBJ UHY2IEhlYWRlcjoNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgICB8VmVyc2lvbnwgVHJhZmZpYyBDbGFz cyB8ICAgICAgICAgICBGbG93IExhYmVsICAgICAgICAgICAgICAgICAgfA0KICAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCiAgICAgIHwgICAgICAgICBQYXlsb2FkIExlbmd0aCAgICAgICAgfCBOeHRIZHI9MTcoVURQ KXwgICBIb3AgTGltaXQgICB8DQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgfCAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCg0KDQpU aGVyZSBpcyBhIHNpbWlsYXIgZmlndXJlIGluIGRyYWZ0LWlldGYtbnZvMy1nZW5ldmUuDQoNCkJl c3QgcmVnYXJkcywNClRhbC4NCg0KRnJvbTogbnZvMyBbbWFpbHRvOm52bzMtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIFJvYmVydCBS YXN6dWsNClNlbnQ6IE1vbmRheSwgTWF5IDIzLCAyMDE2IDEwOjI5IEFNDQpUbzogVGFsIE1penJh aGkNCkNjOiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz47IDZtYW4gV0c7 IGRyYWZ0LWlldGYtbnZvMy12eGxhbi1ncGVAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWll dGYtbnZvMy12eGxhbi1ncGVAdG9vbHMuaWV0Zi5vcmc+OyBudm8zQGlldGYub3JnPG1haWx0bzpu dm8zQGlldGYub3JnPjsgZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXJAdG9v bHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVy QHRvb2xzLmlldGYub3JnPjsgZHJhZnQtaWV0Zi1udm8zLWdlbmV2ZUB0b29scy5pZXRmLm9yZzxt YWlsdG86ZHJhZnQtaWV0Zi1udm8zLWdlbmV2ZUB0b29scy5pZXRmLm9yZz47IFN0ZWZhbm8gUHJl dmlkaSAoc3ByZXZpZGkpDQoNClN1YmplY3Q6IFJlOiBbbnZvM10gW3NwcmluZ10gTDQgQ2hlY2tz dW0gYW5kIGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyDQoNCkhpIFRhbCwN Cg0KPiBkcmFmdHMgc2VlbSB0byBpbXBseQ0KDQpXaGVyZSBzYXkgaW4gZHJhZnQgZHJhZnQtcXVp bm4tdnhsYW4tZ3BlIGRvIHlvdSBzZWUgc3VjaCBzdGF0ZW1lbnQgdGhhdCB3b3VsZCBpbXBseSB0 aGF0IHY2IE54dEhkciBtdXN0IGJlIG9ubHkgZXF1YWwgdG8gMTcgKFVEUCkgYW5kIG5vdCBiZSBh IHBvaW50ZXIgdG8gYW55IG90aGVyIHR5cGUgb2YgZXh0ZW5zaW9uIGhlYWRlciBmdXJ0aGVyIGZv bGxvd2VkIGJ5IFVEUCA/DQoNClRoeCwNClIuDQoNCg0KT24gTW9uLCBNYXkgMjMsIDIwMTYgYXQg Nzo1MCBBTSwgVGFsIE1penJhaGkgPHRhbG1pQG1hcnZlbGwuY29tPG1haWx0bzp0YWxtaUBtYXJ2 ZWxsLmNvbT4+IHdyb3RlOg0KRGVhciBBdXRob3JzIG9mIFZYTEFOLUdQRSAvIEdlbmV2ZSwNCg0K SSBhbSByZWl0ZXJhdGluZyBvbiB0aGlzIHF1ZXN0aW9uLCBhcyBJIGhhdmVuJ3Qgc2VlbiBhIHJl c3BvbnNlIHlldDoNCg0KSGF2ZSB5b3UgY29uc2lkZXJlZCB0aGUgdXNlIG9mIFNlZ21lbnQgUm91 dGluZyB3aXRoIFZYTEFOLUdQRSAvIEdlbmV2ZT8gVGhlIGN1cnJlbnQgVlhMQU4tR1BFIC8gR2Vu ZXZlIGRyYWZ0cyBzZWVtIHRvIGltcGx5IHRoYXQgSVB2NiBleHRlbnNpb24gaGVhZGVycyBhcmUg Y3VycmVudGx5IG5vdCBzdXBwb3J0ZWQuDQoNClRoYW5rcywNClRhbC4NCg0KDQoNCj4tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IG52bzMgW21haWx0bzpudm8zLWJvdW5jZXNAaWV0 Zi5vcmc8bWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBUYWwgTWl6 cmFoaQ0KPlNlbnQ6IFR1ZXNkYXksIE1heSAxNywgMjAxNiAxMjowOSBQTQ0KPlRvOiBTdGVmYW5v IFByZXZpZGkgKHNwcmV2aWRpKTsgVG9tIEhlcmJlcnQ7IGRyYWZ0LWlldGYtbnZvMy0NCj5nZW5l dmVAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmdlbmV2ZUB0b29scy5pZXRmLm9yZz47IGRyYWZ0LWll dGYtbnZvMy12eGxhbi1ncGVAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbnZvMy12 eGxhbi1ncGVAdG9vbHMuaWV0Zi5vcmc+DQo+Q2M6IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3By aW5nQGlldGYub3JnPjsgbnZvM0BpZXRmLm9yZzxtYWlsdG86bnZvM0BpZXRmLm9yZz47IDZtYW4g V0c7IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LQ0KPnJvdXRpbmctaGVhZGVyQHRvb2xzLmlldGYu b3JnPG1haWx0bzpyb3V0aW5nLWhlYWRlckB0b29scy5pZXRmLm9yZz4NCj5TdWJqZWN0OiBSZTog W252bzNdIFtzcHJpbmddIEw0IENoZWNrc3VtIGFuZCBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC0N Cj5yb3V0aW5nLWhlYWRlcg0KPg0KPlN0ZWZhbm8sDQo+DQo+SWYgSSB1bmRlcnN0YW5kIHlvdXIg cG9pbnQgY29ycmVjdGx5Og0KPklQdjYgc2VnbWVudCByb3V0aW5nIGRvZXMgbm90IHdvcmsgd2l0 aCBWWExBTiAvIFZYTEFOLUdQRSAvIEdlbmV2ZSwgc2luY2UNCj50aGVzZSBlbmNhcHN1bGF0aW9u cyBkbyBub3QgY3VycmVudGx5IGFsbG93IHRoZSB1c2Ugb2YgSVB2NiBleHRlbnNpb24NCj5oZWFk ZXJzLg0KPg0KPkkgd29uZGVyIGlmIHRoZSBhdXRob3JzIG9mIFZYTEFOLUdQRSBhbmQgR2VuZXZl IGhhdmUgY29uc2lkZXJlZCB0aGUgdXNlIG9mDQo+c2VnbWVudCByb3V0aW5nLg0KPg0KPlRoYW5r cywNCj5UYWwuDQo+DQo+DQo+DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206 IFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpIFttYWlsdG86c3ByZXZpZGlAY2lzY28uY29tPG1h aWx0bzpzcHJldmlkaUBjaXNjby5jb20+XQ0KPj5TZW50OiBUdWVzZGF5LCBNYXkgMTcsIDIwMTYg MTA6NDEgQU0NCj4+VG86IFRvbSBIZXJiZXJ0DQo+PkNjOiBUYWwgTWl6cmFoaTsgNm1hbiBXRzsg c3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+Ow0KPj5kcmFmdC1pZXRmLTZt YW4tc2VnbWVudC1yb3V0aW5nLSBoZWFkZXJAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmhlYWRlckB0 b29scy5pZXRmLm9yZz4NCj4+U3ViamVjdDogUmU6IFtzcHJpbmddIEw0IENoZWNrc3VtIGFuZCBk cmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLQ0KPj5oZWFkZXINCj4+DQo+Pg0KPj4+IE9u IE1heSAxNiwgMjAxNiwgYXQgNzoxMCBQTSwgVG9tIEhlcmJlcnQgPHRvbUBoZXJiZXJ0bGFuZC5j b208bWFpbHRvOnRvbUBoZXJiZXJ0bGFuZC5jb20+Pg0KPndyb3RlOg0KPj4+DQo+Pj4gT24gTW9u LCBNYXkgMTYsIDIwMTYgYXQgNDozMiBBTSwgVGFsIE1penJhaGkgPHRhbG1pQG1hcnZlbGwuY29t PG1haWx0bzp0YWxtaUBtYXJ2ZWxsLmNvbT4+DQo+Pndyb3RlOg0KPj4+Pj4gaXTigJlzIGFsbCBh Ym91dCBJUCwgbm90IGxheWVyLTIuDQo+Pj4+Pg0KPj4+Pj4gcy4NCj4+Pj4NCj4+Pj4gUmlnaHQu IEhvd2V2ZXIsIGl0IGFwcGVhcnMgdGhhdCBhdCBsZWFzdCBpbiBzb21lIGNhc2VzIGEgVlhMQU4g VlRFUA0KPj4+PiB3aWxsDQo+PnVzZSBTUi4gSXQgY2VydGFpbmx5IG1heSBiZSB0aGUgY2FzZSBp biBTRkMgdXNlIGNhc2VzIChzZWUgU2VjdGlvbiAyLjMNCj4+aW4gZHJhZnQtIGlldGYtc3ByaW5n LWlwdjYtdXNlLWNhc2VzKS4NCj4+Pj4NCj4+Pg0KPj4+IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50 LXJvdXRpbmctaGVhZGVyIG1lbnRpb25zIHRoYXQgdGhlIHBhY2tldCBpcw0KPj4+IGVuY2Fwc3Vs YXRlZA0KPj4NCj4+DQo+PmludG8gYW4gb3V0ZXIgaXB2NiBoZWFkZXIgd2hpY2ggbWFrZXMgaXQg YSBsYXllci0zIGVuY2FwLg0KPj4NCj4+DQo+Pj4gLCBidXQgSSBkb24ndCB0aGluayBpdCBpcyBl eHBsaWNpdCBhcyB0byBleGFjdCBlbmNhcHN1bGF0aW9uIGZvcm1hdA0KPj4+IChJIHN1cHBvc2Ug c2ltcGxlIGlwNmlwNiBpcyBpbXBsaWVkKS4NCj4+DQo+Pg0KPj5zZWUgc2VjdGlvbiAyLjINCj4+ DQo+Pg0KPj4+IEJ1dCwgaXQNCj4+PiBzZWVtcyBsaWtlIGFueSBvZiBzZXZlcmFsIGVuY2Fwc3Vs YXRpb24gdGVjaG5pcXVlcyBjb3VsZCB3b3JrIChWWExBTiwNCj4+DQo+Pg0KPj5JIGhhdmUgc29t ZSBwcm9ibGVtcyB0byB1bmRlcnN0YW5kIHdoZXJlIHRvIGZpdCBhbiBleHRlbnNpb24gaGVhZGVy DQo+PmludG8gYSB2eGxhbiBlbmNhcOKApg0KPj4NCj4+DQo+Pj4gR1JFL0lQLCBFU1AvSVAsIEdV RSwgZm9vIG92ZXIgVURQLCBldGMuKSBhbmQgaWYgYSBkZXZpY2UgdGhhdCB3YW50cw0KPj4+IHRv IGRvIFNSIGlzIGFscmVhZHkgZG9pbmcgdHVubmVsaW5nIGl0IHNlZW1zIHJlYXNvbmFibGUgdG8g bWUgdG8gb25seQ0KPj4+IGhhdmUgb25lIGxheWVyIG9mIGVuY2Fwc3VsYXRpb24uIE1heWJlIHRo aXMgc2hvdWxkIGJlIGNsYXJpZmllZCBpbg0KPj4+IHRoZSBkcmFmdD8NCj4+DQo+Pg0KPj50aGUg ZHJhZnQgaXMgYWJvdXQgSVB2NiBleHRlbnNpb24gaGVhZGVyIGFuZCBtb3JlIHByZWNpc2VseSBh IG5ldyB0eXBlDQo+Pm9mIHRoZSByb3V0aW5nIGV4dGVuc2lvbiBoZWFkZXIgZGVmaW5lZCBpbiBy ZmMyNDYwLiBUaGF04oCZcyB0aGUgY29udGV4dC4NCj4+DQo+Pg0KPj5zLg0KPj4NCj4+DQo+Pg0K Pj4NCj4+Pg0KPj4+IFRvbQ0KPj4+DQo+Pj4+DQo+Pj4+DQo+Pj4+PiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPj4+Pj4gRnJvbTogU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkgW21haWx0 bzpzcHJldmlkaUBjaXNjby5jb208bWFpbHRvOnNwcmV2aWRpQGNpc2NvLmNvbT5dDQo+Pj4+PiBT ZW50OiBNb25kYXksIE1heSAxNiwgMjAxNiAyOjI0IFBNDQo+Pj4+PiBUbzogVGFsIE1penJhaGkN Cj4+Pj4+IENjOiBPbGUgVHLDuGFuOw0KPj4+Pj4gZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91 dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtNm1hbi1zZWdtZW50 LXJvdXRpbmctaGVhZGVyQHRvb2xzLmlldGYub3JnPjsNCj4+Pj4+IHNwcmluZ0BpZXRmLm9yZzxt YWlsdG86c3ByaW5nQGlldGYub3JnPjsgNm1hbiBXRw0KPj4+Pj4gU3ViamVjdDogUmU6IFtzcHJp bmddIEw0IENoZWNrc3VtIGFuZA0KPj4+Pj4gZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGlu Zy0gaGVhZGVyDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+PiBPbiBNYXkgMTYsIDIwMTYsIGF0IDE6MTkg UE0sIFRhbCBNaXpyYWhpIDx0YWxtaUBtYXJ2ZWxsLmNvbTxtYWlsdG86dGFsbWlAbWFydmVsbC5j b20+PiB3cm90ZToNCj4+Pj4+Pg0KPj4+Pj4+IEhpIFN0ZWZhbm8sDQo+Pj4+Pj4NCj4+Pj4+PiBU aGFua3MgYWdhaW4gZm9yIHRoZSBwcm9tcHQgcmVzcG9uc2UuDQo+Pj4+Pj4NCj4+Pj4+Pj4gMi4g dGhlIFNSSCBpcyBvcmlnaW5hdGVkIGJ5IHRoZSBpbmdyZXNzIG5vZGUgb2YgdGhlIFNSIGRvbWFp bi4NCj4+Pj4+Pj4gVGhpcyBpcyBkb25lIGJ5IGVuY2Fwc3VsYXRpbmcgdGhlIHBhY2tldCBpbnRv IGEgb3V0ZXINCj4+Pj4+Pj4gKGFkZGl0aW9uYWwpIGlwdjYgaGVhZGVyIGZvbGxvd2VkIGJ5IGFu IFNSSC4gVGhpcyBpcyBMMw0KPj4+Pj4+PiBlbmNhcHN1bGF0aW9uIGFuZCBubyBMNCBjaGVja3N1 bSBpcyBpbnZvbHZlZC4gV2hlbiB0aGUgIHBhY2tldA0KPj4+Pj4+PiBsZWF2ZXMgdGhlIFNSIHR1 bm5lbCB0aGUgb3V0ZXIgZW5jYXBzdWxhdGlvbiAgKGluY2x1ZGluZyB0aGUgU1JIKQ0KPj4+Pj4+ PiBpcyByZW1vdmVkIGFuZCB0aGUgcGFja2V0IGNvbnRpbnVlcyAgaXRzIGpvdXJuZXkgbGlrZSBu b3RoaW5nDQo+aGFwcGVuZWQuDQo+Pj4+Pj4NCj4+Pj4+PiBTbyBWWExBTiBpcyBvZmYgdGhlIHRh YmxlPw0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiBpdOKAmXMgYWxsIGFib3V0IElQLCBub3QgbGF5ZXIt Mi4NCj4+Pj4+DQo+Pj4+PiBzLg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pj4gSXQgd291bGQgYmUgd29y dGh3aGlsZSB0byBjbGFyaWZ5IHRoaXMgaW4gdGhlIGRyYWZ0LiBJZiB5b3UgaGF2ZSBhDQo+Pj4+ Pj4gc3BlY2lmaWMNCj4+Pj4+IGVuY2Fwc3VsYXRpb24gaW4gbWluZCwgaXQgd291bGQgYmUgZ3Jl YXQgaWYgdGhlIGRyYWZ0IHdvdWxkIHNwZWNpZnkgaXQuDQo+Pj4+Pj4NCj4+Pj4+PiBUaGFua3Ms DQo+Pj4+Pj4gVGFsLg0KPj4+Pj4+DQo+Pj4+Pj4NCj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4+Pj4+Pj4gRnJvbTogU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkgW21haWx0 bzpzcHJldmlkaUBjaXNjby5jb208bWFpbHRvOnNwcmV2aWRpQGNpc2NvLmNvbT5dDQo+Pj4+Pj4+ IFNlbnQ6IE1vbmRheSwgTWF5IDE2LCAyMDE2IDI6MTMgUE0NCj4+Pj4+Pj4gVG86IFRhbCBNaXpy YWhpDQo+Pj4+Pj4+IENjOiBPbGUgVHLDuGFuOw0KPj4+Pj4+PiBkcmFmdC1pZXRmLTZtYW4tc2Vn bWVudC1yb3V0aW5nLWhlYWRlckB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi02bWFu LXNlZ21lbnQtcm91dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmc+Ow0KPj4+Pj4+PiBzcHJpbmdA aWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz47IDZtYW4gV0cNCj4+Pj4+Pj4gU3ViamVj dDogUmU6IFtzcHJpbmddIEw0IENoZWNrc3VtIGFuZA0KPj4+Pj4+PiBkcmFmdC1pZXRmLTZtYW4t c2VnbWVudC1yb3V0aW5nLSBoZWFkZXINCj4+Pj4+Pj4NCj4+Pj4+Pj4gSGksDQo+Pj4+Pj4+DQo+ Pj4+Pj4+IE9uIE1heSAxNiwgMjAxNiwgYXQgMTE6MDQgQU0sIFRhbCBNaXpyYWhpIDx0YWxtaUBt YXJ2ZWxsLmNvbTxtYWlsdG86dGFsbWlAbWFydmVsbC5jb20+Pg0KPj53cm90ZToNCj4+Pj4+Pj4+ DQo+Pj4+Pj4+PiBIaSBTdGVmYW5vLA0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFRoYW5rcyBmb3IgdGhl IHJlc3BvbnNlcy4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gZXhhY3RseS4NCj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+IE1vcmVvdmVyLCBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlciBh c3N1bWVzDQo+Pj4+Pj4+Pj4gZW5jYXBzdWxhdGlvbiBzbyBjbGVhcmx5IHRoZXJl4oCZcyBubyBM NCBpbnZvbHZlZCBoZXJlLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gcy4NCj4+Pj4+Pj4+DQo+Pj4+ Pj4+PiBUd28gcXVlc3Rpb25zOg0KPj4+Pj4+Pj4gMS4gV2hhdCBpZiB0aGUgZW5jYXBzdWxhdGlv biBpcyBWWExBTj8gTDQgd291bGQgc3RpbGwgYmUNCj4+Pj4+Pj4+IGludm9sdmVkLA0KPj5yaWdo dD8NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gU2VlIGJlbG93Lg0KPj4+Pj4+Pg0KPj4+Pj4+ Pg0KPj4+Pj4+Pj4gMi4gV2hlbiB5b3Ugc2F5ICdhc3N1bWVzIGVuY2Fwc3VsYXRpb24nLCBkb2Vz IGl0IG1lYW4gdGhhdCBhDQo+Pj4+Pj4+PiBob3N0IGNhbm5vdA0KPj4+Pj4+PiBzZW5kIGFuIElQ djYgcGFja2V0IHdpdGggYW4gU1JIPyBUaGUgY3VycmVudCBkcmFmdCBzYXlzOg0KPj4+Pj4+Pj4N Cj4+Pj4+Pj4+IEEgU291cmNlIFNSIE5vZGUgY2FuIGJlIGFueSBub2RlIG9yaWdpbmF0aW5nIGFu IElQdjYgcGFja2V0IHdpdGgNCj4+Pj4+Pj4+IGl0cw0KPj4+Pj4+Pj4gSVB2NiBhbmQgU2VnbWVu dCBSb3V0aW5nIEhlYWRlcnMuICBUaGlzIGluY2x1ZGUgZWl0aGVyOg0KPj4+Pj4+Pj4NCj4+Pj4+ Pj4+ICAgIEEgaG9zdCBvcmlnaW5hdGluZyBhbiBJUHY2IHBhY2tldC4NCj4+Pj4+Pj4+DQo+Pj4+ Pj4+PiAgICBBbiBTUiBkb21haW4gaW5ncmVzcyByb3V0ZXIgZW5jYXBzdWxhdGluZyBhIHJlY2Vp dmVkIElQdjYgcGFja2V0DQo+Pj4+Pj4+PiAgICBpbnRvIGFuIG91dGVyIElQdjYgaGVhZGVyIGZv bGxvd2VkIGJ5IGFuIFNSSC4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ IFdpbGwgYXBwcmVjaWF0ZSBpZiB5b3UgY2FuIGNsYXJpZnkgdGhhdC4NCj4+Pj4+Pj4NCj4+Pj4+ Pj4NCj4+Pj4+Pj4gb2ssIHR3byBjYXNlczoNCj4+Pj4+Pj4NCj4+Pj4+Pj4gMS4gdGhlIFNSSCBp cyBpbnNlcnRlZCBhdCB0aGUgc291cmNlLg0KPj4+Pj4+PiB0aGUgc291cmNlIG9yaWdpbmF0ZXMg dGhlIHBhY2tldCwgdGhlIGlwdjYgaGVhZGVyIGFuZCAgdGhlIFNSSC4NCj4+Pj4+Pj4gVGhlIHNv dXJjZSBjb21wdXRlcyBMNCBjaGVja3N1bSB0YWtpbmcgaW50byAgYWNjb3VudCB0aGUgd2hvbGUN Cj4+SVB2NitTUkguDQo+Pj4+Pj4+IEhlcmUsIHRoZXJlc+KAmSBub3RoaW5nIG5ldyAgY29tcGFy ZWQgdG8gcmZjMjQ2MC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gMi4gdGhlIFNSSCBpcyBvcmlnaW5hdGVk IGJ5IHRoZSBpbmdyZXNzIG5vZGUgb2YgdGhlIFNSIGRvbWFpbi4NCj4+Pj4+Pj4gVGhpcyBpcyBk b25lIGJ5IGVuY2Fwc3VsYXRpbmcgdGhlIHBhY2tldCBpbnRvIGEgb3V0ZXINCj4+Pj4+Pj4gKGFk ZGl0aW9uYWwpIGlwdjYgaGVhZGVyIGZvbGxvd2VkIGJ5IGFuIFNSSC4gVGhpcyBpcyBMMw0KPj4+ Pj4+PiBlbmNhcHN1bGF0aW9uIGFuZCBubyBMNCBjaGVja3N1bSBpcyBpbnZvbHZlZC4gV2hlbiB0 aGUgIHBhY2tldA0KPj4+Pj4+PiBsZWF2ZXMgdGhlIFNSIHR1bm5lbCB0aGUgb3V0ZXIgZW5jYXBz dWxhdGlvbiAgKGluY2x1ZGluZyB0aGUgU1JIKQ0KPj4+Pj4+PiBpcyByZW1vdmVkIGFuZCB0aGUg cGFja2V0IGNvbnRpbnVlcyAgaXRzIGpvdXJuZXkgbGlrZSBub3RoaW5nDQo+aGFwcGVuZWQuDQo+ Pj4+Pj4+DQo+Pj4+Pj4+IHMuDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4g VGhhbmtzLA0KPj4+Pj4+Pj4gVGFsLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+PiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+Pj4+IEZyb206IFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkp IFttYWlsdG86c3ByZXZpZGlAY2lzY28uY29tPG1haWx0bzpzcHJldmlkaUBjaXNjby5jb20+XQ0K Pj4+Pj4+Pj4+IFNlbnQ6IE1vbmRheSwgTWF5IDE2LCAyMDE2IDExOjU5IEFNDQo+Pj4+Pj4+Pj4g VG86IE9sZSBUcsO4YW47IFRhbCBNaXpyYWhpDQo+Pj4+Pj4+Pj4gQ2M6IGRyYWZ0LWlldGYtNm1h bi1zZWdtZW50LXJvdXRpbmctaGVhZGVyQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRm LTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlckB0b29scy5pZXRmLm9yZz47DQo+Pj4+Pj4+Pj4g c3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+OyA2bWFuIFdHDQo+Pj4+Pj4+ Pj4gU3ViamVjdDogUmU6IFtzcHJpbmddIEw0IENoZWNrc3VtIGFuZA0KPj4+Pj4+Pj4+IGRyYWZ0 LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctIGhlYWRlcg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+Pj4gT24gTWF5IDE1LCAyMDE2LCBhdCA4OjA2IFBNLCBvdHJvYW5AZW1wbG95ZWVz Lm9yZzxtYWlsdG86b3Ryb2FuQGVtcGxveWVlcy5vcmc+IHdyb3RlOg0KPj4+Pj4+Pj4+Pg0KPj4+ Pj4+Pj4+PiBUYWwsDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBbQXBvbG9naWVzIGlmIHRoaXMg aXNzdWUgaGFzIGJlZW4gZGlzY3Vzc2VkIGJlZm9yZS5dDQo+Pj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+ Pj4gQWNjb3JkaW5nIHRvIGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyLCBh biDigJhTUg0KPj4+Pj4+Pj4+Pj4gU2VnbWVudA0KPj4+Pj4+Pj4+IEVuZHBvaW50IE5vZGXigJkg dXBkYXRlcyB0aGUgRGVzdGluYXRpb24gSVAgYWRkcmVzcy4NCj4+Pj4+Pj4+Pj4+IFRoZXJlZm9y ZSwgaXQgbXVzdCBhbHNvIHVwZGF0ZSB0aGUgTGF5ZXIgNCBDaGVja3N1bSwgcmlnaHQ/DQo+Pj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pj4gSSB3b25kZXIgaWYgdGhlcmUgaXMgYW4gdXBwZXIgYm91bmQg b24gdGhlIHNpemUgb2YgdGhlIFNSSC4NCj4+Pj4+Pj4+Pj4+IE90aGVyd2lzZSwgdGhlDQo+Pj4+ Pj4+Pj4gTDQgQ2hlY2tzdW0gbWF5IGJlIGxvY2F0ZWQgaW4gYSBwcmV0dHkgZGVlcCBsb2NhdGlv bi4NCj4+Pj4+Pj4+Pj4+IFNwZWFraW5nIGZyb20gYSBjaGlwIHZlbmRvcuKAmXMgcGVyc3BlY3Rp dmUgdGhpcyBtYXkgYmUgYSBwcm9ibGVtLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBGcm9tIFJG QzI0NjAsIFJIMDoNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gICBvICBJZiB0 aGUgSVB2NiBwYWNrZXQgY29udGFpbnMgYSBSb3V0aW5nIGhlYWRlciwgdGhlIERlc3RpbmF0aW9u DQo+Pj4+Pj4+Pj4+ICAgICAgQWRkcmVzcyB1c2VkIGluIHRoZSBwc2V1ZG8taGVhZGVyIGlzIHRo YXQgb2YgdGhlIGZpbmFsDQo+Pj4+Pj4+Pj4+ICAgICAgZGVzdGluYXRpb24uICBBdCB0aGUgb3Jp Z2luYXRpbmcgbm9kZSwgdGhhdCBhZGRyZXNzIHdpbGwgYmUgaW4NCj4+Pj4+Pj4+Pj4gICAgICB0 aGUgbGFzdCBlbGVtZW50IG9mIHRoZSBSb3V0aW5nIGhlYWRlcjsgYXQgdGhlIHJlY2lwaWVudChz KSwNCj4+Pj4+Pj4+Pj4gICAgICB0aGF0IGFkZHJlc3Mgd2lsbCBiZSBpbiB0aGUgRGVzdGluYXRp b24gQWRkcmVzcyBmaWVsZCBvZiB0aGUNCj4+Pj4+Pj4+Pj4gICAgICBJUHY2IGhlYWRlci4NCj4+ Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gSSB3b3VsZCBleHBlY3QgU1Igd291bGQgd29yayB0aGUgc2Ft ZS4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gZXhhY3RseS4NCj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+IE1vcmVvdmVyLCBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRl ciBhc3N1bWVzDQo+Pj4+Pj4+Pj4gZW5jYXBzdWxhdGlvbiBzbyBjbGVhcmx5IHRoZXJl4oCZcyBu byBMNCBpbnZvbHZlZCBoZXJlLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gcy4NCj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IENoZWVycywNCj4+Pj4+Pj4+Pj4gT2xl DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+DQo+Pj4+DQo+Pj4+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ Pj4+IElFVEYgSVB2NiB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCBpcHY2QGlldGYub3JnPG1h aWx0bzppcHY2QGlldGYub3JnPiBBZG1pbmlzdHJhdGl2ZQ0KPj4+PiBSZXF1ZXN0czogaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+Pj4+IC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5udm8z IG1haWxpbmcgbGlzdA0KPm52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+DQo+aHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9udm8zDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc3ByaW5nIG1haWxpbmcgbGlzdA0Kc3By aW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0KDQoNCg0K --_000_36D9FCF0382C466985A5C782636A85BBvmwarecom_ Content-Type: text/html; charset="utf-8" Content-ID: <6A9EBD032C29354894041B3C81807234@vmware.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkkgYWdyZWUgdGhhdCBJIGRvbuKAmXQgYmVsaWV2ZSB0aGF0IHRoZXJlIGlzIGFueXRoaW5n IGluIHRoZXNlIGRyYWZ0cyB0aGF0IHByZWNsdWRlcyB0aGUgdXNlIG9mIGV4dGVuc2lvbiBoZWFk ZXJzIG9yIHNlZ21lbnQgcm91dGluZyDigJMgSVAgaXMgc2ltcGx5IHRoZSBsYXllciB1bmRlcm5l YXRoIHRoYXQgdGhlc2UgcHJvdG9jb2xzIGFyZSBidWlsZGluZyBvbi4gVGhlIGZpZ3VyZXMgYXJl IGRlZmluaXRlbHkganVzdCBleGFtcGxlcyDigJMgdGhleQ0KIGFsc28gc2hvdyBvdXRlciBFdGhl cm5ldCBoZWFkZXJzLCB3aGljaCBpcyBub3QgYSByZXF1aXJlbWVudC48L2Rpdj4NCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2Pkkgd291bGRu4oCZdCB3YW50IHRvIGFkZCB0ZXh0IHNwZWNpZmljYWxs eSBzdGF0aW5nIHRoYXQgZXh0ZW5zaW9uIGhlYWRlcnMgYXJlIHBlcm1pc3NpYmxlLiBJdCBzZWVt cyBsaWtlIHRoYXQgY291bGQgbGVhZCB0byBzaW1pbGFyIHF1ZXN0aW9ucyBpbiB0aGUgZnV0dXJl IHdoZXJlIG9uZSBtaWdodCB3b25kZXIgaWYgb3RoZXIgZmVhdHVyZXMgb2YgSVAgYXJlIGFsbG93 ZWQgYmVjYXVzZSBvbmUgaXMgZXhwbGljaXRseSBsaXN0ZWQgYW5kIG90aGVycw0KIGFyZSBub3Qs IGV0Yy4gSW4gbXkgb3BpbmlvbiwgdGhlIGRyYWZ0cyBhcmUgYWJvdXQgYXMgY2xlYXIgYXMgdGhl eSBjYW4gYmUgb24gdGhpcyBwb2ludC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkpl c3NlPC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iTUFDX09VVExPT0tfU0lHTkFUVVJFIj48L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xL X1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdj4NCjxkaXY+T24gNS8yMy8xNiwgMTowOSBBTSwgJnF1 b3Q7PGEgaHJlZj0ibWFpbHRvOnJyYXN6dWtAZ21haWwuY29tIj5ycmFzenVrQGdtYWlsLmNvbTwv YT4gb24gYmVoYWxmIG9mIFJvYmVydCBSYXN6dWsmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpy cmFzenVrQGdtYWlsLmNvbSI+cnJhc3p1a0BnbWFpbC5jb208L2E+IG9uIGJlaGFsZiBvZg0KPGEg aHJlZj0ibWFpbHRvOnJvYmVydEByYXN6dWsubmV0Ij5yb2JlcnRAcmFzenVrLm5ldDwvYT4mZ3Q7 IHdyb3RlOjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9 Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDog I2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5 bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFs bCI+DQpIaSBUYWwsPC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9u dC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxi cj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5 OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8c3BhbiBzdHls ZT0iY29sb3I6cmdiKDMxLDczLDEyNSk7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2Zv bnQtc2l6ZToxNC42NjY3cHgiPiZndDsgSW4gb3JkZXIgdG8gYXZvaWQgYW1iaWd1aXR5LCBpdCB3 b3VsZCBiZSBncmVhdCBpZiB0aGUmbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFp bF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7 Zm9udC1zaXplOnNtYWxsIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpyZ2IoMzEsNzMsMTI1KTtmb250 LWZhbWlseTpDYWxpYnJpLHNhbnMtc2VyaWY7Zm9udC1zaXplOjE0LjY2NjdweCI+Jmd0OyBhdXRo b3JzIGNvdWxkIGV4cGxpY2l0bHkgbWVudGlvbiB0aGF0IElQdjYgZXh0ZW5zaW9uJm5ic3A7PC9z cGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5 OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQo8c3BhbiBzdHls ZT0iY29sb3I6cmdiKDMxLDczLDEyNSk7Zm9udC1mYW1pbHk6Q2FsaWJyaSxzYW5zLXNlcmlmO2Zv bnQtc2l6ZToxNC42NjY3cHgiPiZndDsgaGVhZGVycyBhcmUgcGVybWl0dGVkLjwvc3Bhbj48YnI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9ImdtYWlsX2RlZmF1bHQiIHN0eWxlPSJmb250LWZhbWlseTph cmlhbCxoZWx2ZXRpY2Esc2Fucy1zZXJpZjtmb250LXNpemU6c21hbGwiPg0KPGJyPg0KPC9kaXY+ DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJpYWwsaGVs dmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCldlbGwgdGhlIGRyYWZ0cyBhcmUg Y29tcGxhaW50IHRvIFJGQzIxMTkgKG5vcm1hdGl2ZSByZWZlcmVuY2UpIHNvIHVubGVzcyB0aGUg dGV4dCBleGNsdWRlcyBlbGVtZW50cyB3aXRoIE1VU1QvTVVTVCBOT1QgLSBldmVyeXRoaW5nIGVs c2UgZGVmaW5lZCBpbiB0aGUgYnVpbGRpbmcgYmxvY2tzIHRoZXkgKHJlKXVzZSBpcyBwZXJtaXR0 ZWQuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1m YW1pbHk6YXJpYWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4N CjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFy aWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpIb3dldmVyIGFzIHlv dSBzYXkgcGVyaGFwcyBmb3IgY2xhcml0eSB3aGF0IGNvdWxkIGJlIGFkZGVkIHRvIHRob3NlIGRy YWZ0cyBpcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2UgdG8gSVB2NCBhbmQgSVB2NiBiYXNlIFJGQ3Mu PC9kaXY+DQo8ZGl2IGNsYXNzPSJnbWFpbF9kZWZhdWx0IiBzdHlsZT0iZm9udC1mYW1pbHk6YXJp YWwsaGVsdmV0aWNhLHNhbnMtc2VyaWY7Zm9udC1zaXplOnNtYWxsIj4NCjxicj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZl dGljYSxzYW5zLXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpCZXN0LDwvZGl2Pg0KPGRpdiBjbGFz cz0iZ21haWxfZGVmYXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5z LXNlcmlmO2ZvbnQtc2l6ZTpzbWFsbCI+DQpSLjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZGVm YXVsdCIgc3R5bGU9ImZvbnQtZmFtaWx5OmFyaWFsLGhlbHZldGljYSxzYW5zLXNlcmlmO2ZvbnQt c2l6ZTpzbWFsbCI+DQo8YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0 cmEiPjxicj4NCjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBNb24sIE1heSAyMywgMjAxNiBh dCA5OjU0IEFNLCBUYWwgTWl6cmFoaSA8c3BhbiBkaXI9Imx0ciI+DQombHQ7PGEgaHJlZj0ibWFp bHRvOnRhbG1pQG1hcnZlbGwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGFsbWlAbWFydmVsbC5jb208 L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6PGJyPg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3Rl IiBzdHlsZT0ibWFyZ2luOjAgMCAwIC44ZXg7Ym9yZGVyLWxlZnQ6MXB4ICNjY2Mgc29saWQ7cGFk ZGluZy1sZWZ0OjFleCI+DQo8ZGl2IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7Ij5IaSBSb2JlcnQsPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PHU+PC91PiZuYnNw Ozx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyI+VGhhdCBtYWtlcyBzZW5zZS48dT48L3U+PHU+PC91Pjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBm b250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 Ij5Ib3dldmVyLCBpbiB0aGlzIGNhc2UgdGhlIGZpZ3VyZXMgbWF5IGJlIGEgYml0IGNvbmZ1c2lu ZyBXUlQgdGhlIHBvc3NpYmxlIGV4aXN0ZW5jZSBvZiBleHRlbnNpb24gaGVhZGVycy4gVGhpcyBj b25mdXNpb24gaXMgd2hhdCBsZWQgdG8gdGhlIGRpc2N1c3Npb24NCiBpbiB0aGlzIHRocmVhZCBh Ym91dCB3aGV0aGVyIHNlZ21lbnQgcm91dGluZyBpcyBwb3NzaWJsZSB3aXRoIFZYTEFOL1ZYTEFO LUdQRS9HZW5ldmUgZW5jYXBzdWxhdGlvbnMuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PHU+PC91 PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNv bG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+SW4gb3JkZXIgdG8gYXZvaWQgYW1iaWd1aXR5LCBpdCB3 b3VsZCBiZSBncmVhdCBpZiB0aGUgYXV0aG9ycyBjb3VsZCBleHBsaWNpdGx5IG1lbnRpb24gdGhh dCBJUHY2IGV4dGVuc2lvbiBoZWFkZXJzIGFyZSBwZXJtaXR0ZWQuPHU+PC91Pjx1PjwvdT48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFw dDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+UmVnYXJkcyw8dT48L3U+PHU+PC91 Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7Ij5UYWwuPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PHU+PC91PiZuYnNwOzx1Pjwv dT48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNiNWM0ZGYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyI+RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEs IHNhbnMtc2VyaWY7Ij48YSBocmVmPSJtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5ycmFzenVrQGdtYWlsLmNvbTwvYT4gW21haWx0bzo8YSBocmVmPSJtYWlsdG86cnJh c3p1a0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5ycmFzenVrQGdtYWlsLmNvbTwvYT5dDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5 LCBNYXkgMjMsIDIwMTYgMTA6NDcgQU08L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgY2xhc3M9Img1 Ij48YnI+DQo8Yj5Ubzo8L2I+IFRhbCBNaXpyYWhpPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJt YWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9h PjsgNm1hbiBXRzsNCjxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW52bzMtdnhsYW4tZ3BlQHRv b2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZHJhZnQtaWV0Zi1udm8zLXZ4bGFuLWdwZUB0 b29scy5pZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86bnZvM0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPm52bzNAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi02 bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij4NCmRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyQHRvb2xzLmlldGYub3Jn PC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbnZvMy1nZW5ldmVAdG9vbHMuaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LWlldGYtbnZvMy1nZW5ldmVAdG9vbHMuaWV0Zi5v cmc8L2E+OyBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKTxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW252bzNdIFtzcHJpbmddIEw0IENoZWNrc3VtIGFuZCBkcmFmdC1pZXRmLTZtYW4tc2VnbWVu dC1yb3V0aW5nLWhlYWRlcjx1PjwvdT48dT48L3U+PC9kaXY+DQo8L2Rpdj4NCjxwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iaDUiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7Ij5IaSBU YWwsPHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiPjx1 PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7Ij5J bmRlZWQgLi4gSSBzYXcgdGhlIGZpZ3VyZXMsIGJ1dCBmaWd1cmVzIGFyZSBub24gbm9ybWF0aXZl IGluIGFueSBkcmFmdC9yZmMgdW5sZXNzIHRleHQgYmVsb3cgc3BlY2lmaWNhbGx5IHNwZWxscyBp dCBvdXQuJm5ic3A7PHU+PC91Pjx1PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1z ZXJpZjsiPjx1PjwvdT4mbmJzcDs8dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMt c2VyaWY7Ij5Gb3IgZXhhbXBsZSBmcm9tIHZ4bGFuLWdwZTombmJzcDs8dT48L3U+PHU+PC91Pjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyI+PHU+PC91PiZuYnNwOzx1PjwvdT48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiPiZxdW90OzxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+V2hlbiB0aGUgb3V0ZXIgSVAgaGVhZGVyIGlzIElQdjQsIFZURVBzIE1VU1Qg c2V0IHRoZSBERiBiaXQuJnF1b3Q7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogQXJpYWwsIHNhbnMtc2VyaWY7Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6IEFyaWFsLCBzYW5zLXNlcmlmOyI+QmVzaWRlcyBpdCBpcyBwcmV0dHkgY2hhbGxlbmdpbmcg dG8gYWRkIGFuaW1hdGlvbiB0byB0aGUgY3VycmVudCBkcmFmdCBmb3JtYXRzIHRvIGlsbHVzdHJh dGUgYWxsIHBvc3NpYmx5IGFsbG93ZWQgZmllbGQgdmFsdWVzL2NvbWJpbmF0aW9ucyBpbiBhbnkg ZmlndXJlIDopICZuYnNwO0ZpZ3VyZXMganVzdCBpbGx1c3RyYXRlIG9uZSB1c2UNCiBleGFtcGxl LiZuYnNwOzx1PjwvdT48dT48L3U+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7 Ij48dT48L3U+Jm5ic3A7PHU+PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlm OyI+VG8gbWUgdGhlIGN1cnJlbnQgc3BlY3MgcGVybWl0IGFueSB2YWx1ZSBvZiBJUHY2IE54dEhk ciBmaWVsZCBhcyBwZXJtaXR0ZWQgaW4gYm90aCBlbmNhcHN1bGF0aW9ucy48dT48L3U+PHU+PC91 Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyI+PHU+PC91PiZuYnNwOzx1Pjwv dT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiPkJlc3QsPHU+PC91Pjx1Pjwv dT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiPlJvYmVydC48dT48L3U+PHU+ PC91Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyI+PHU+PC91PiZuYnNwOzx1 PjwvdT48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48dT48L3U+Jm5ic3A7PHU+PC91PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBNb24sIE1heSAyMywgMjAxNiBhdCA5OjM1IEFNLCBUYWwgTWl6cmFoaSAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnRhbG1pQG1hcnZlbGwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGFsbWlAbWFydmVs bC5jb208L2E+Jmd0OyB3cm90ZTo8dT48L3U+PHU+PC91PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1p bHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+SGkgUm9i ZXJ0LDwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91Pjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi PiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPiZndDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyI+V2hlcmUgc2F5IGluIGRyYWZ0IGRyYWZ0LXF1aW5uLXZ4bGFuLWdw ZSBkbyB5b3UNCiBzZWUgc3VjaCBzdGF0ZW1lbnQgdGhhdCB3b3VsZCBpbXBseSA8L3NwYW4+PHU+ PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigz MSwgNzMsIDEyNSk7Ij4mZ3Q7IHRoYXQgdjYgTnh0SGRyIG11c3QgYmUgb25seSBlcXVhbCB0byAx NyAoVURQKSBhbmQgbm90IGJlIGEgcG9pbnRlciB0byBhbnkgb3RoZXIgdHlwZQ0KPC9zcGFuPjx1 PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2Io MzEsIDczLCAxMjUpOyI+Jmd0OyBvZiBleHRlbnNpb24gaGVhZGVyIGZ1cnRoZXIgZm9sbG93ZWQg YnkgVURQID88L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1Pjwv dT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0 OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEy NSk7Ij4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5UaGUgZm9sbG93aW5nIHRleHQgaXMg ZnJvbSBGaWd1cmUgNCBpbiBkcmFmdC1pZXRmLW52bzMtdnhsYW4tZ3BlOjwvc3Bhbj48dT48L3U+ PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsiPiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBPdXRlciBJUHY2IEhlYWRlcjo8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMWY0OTdkIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8L3NwYW4+PHU+PC91Pjx1Pjwv dT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMWY0OTdkIj4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfFZlcnNpb258IFRyYWZmaWMgQ2xhc3MgfCZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBG bG93IExhYmVsJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHw8 L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMWY0OTdkIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0Mzs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMWY0OTdkIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQYXls b2FkIExlbmd0aCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IE54 dEhkcj0xNyhVRFApfCZuYnNwOyZuYnNwOyBIb3AgTGltaXQmbmJzcDsmbmJzcDsgfDwvc3Bhbj48 dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMx ZjQ5N2QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMxZjQ5N2QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3w8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJz cDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsg Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij5U aGVyZSBpcyBhIHNpbWlsYXIgZmlndXJlIGluIGRyYWZ0LWlldGYtbnZvMy1nZW5ldmUuPC9zcGFu Pjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyI+Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6 IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+QmVzdCByZWdh cmRzLDwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPlRhbC48L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7Ij4m bmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI2I1YzRkZiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMt c2VyaWY7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9u dC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsiPiBudm8zIFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm52bzMtYm91bmNlc0Bp ZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8Yj5T ZW50OjwvYj4gTW9uZGF5LCBNYXkgMjMsIDIwMTYgMTA6MjkgQU08YnI+DQo8Yj5Ubzo8L2I+IFRh bCBNaXpyYWhpPGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9hPjsgNm1hbiBXRzsNCjxhIGhyZWY9 Im1haWx0bzpkcmFmdC1pZXRmLW52bzMtdnhsYW4tZ3BlQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+ZHJhZnQtaWV0Zi1udm8zLXZ4bGFuLWdwZUB0b29scy5pZXRmLm9yZzwvYT47DQo8 YSBocmVmPSJtYWlsdG86bnZvM0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm52bzNAaWV0Zi5v cmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1o ZWFkZXJAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LWlldGYtNm1hbi1z ZWdtZW50LXJvdXRpbmctaGVhZGVyQHRvb2xzLmlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRv OmRyYWZ0LWlldGYtbnZvMy1nZW5ldmVAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4N CmRyYWZ0LWlldGYtbnZvMy1nZW5ldmVAdG9vbHMuaWV0Zi5vcmc8L2E+OyBTdGVmYW5vIFByZXZp ZGkgKHNwcmV2aWRpKTwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbnZvM10gW3Nwcmlu Z10gTDQgQ2hlY2tzdW0gYW5kIGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVy PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PHU+PC91Pjx1PjwvdT48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogQXJpYWwsIHNhbnMtc2VyaWY7Ij5IaSBUYWwsPC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiPiZuYnNwOzwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTogQXJpYWwsIHNhbnMtc2VyaWY7Ij4mZ3Q7Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDkuNXB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7Ij5kcmFmdHMg c2VlbSB0byBpbXBseTwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMt c2VyaWY7Ij4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5z LXNlcmlmOyI+V2hlcmUgc2F5IGluIGRyYWZ0Jm5ic3A7ZHJhZnQtcXVpbm4tdnhsYW4tZ3BlIGRv IHlvdSBzZWUgc3VjaCBzdGF0ZW1lbnQgdGhhdCB3b3VsZCBpbXBseSB0aGF0IHY2IE54dEhkciBt dXN0IGJlIG9ubHkgZXF1YWwgdG8gMTcgKFVEUCkgYW5kIG5vdCBiZSBhIHBvaW50ZXIgdG8gYW55 IG90aGVyIHR5cGUgb2YgZXh0ZW5zaW9uIGhlYWRlciBmdXJ0aGVyDQogZm9sbG93ZWQgYnkgVURQ ID8mbmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlm OyI+Jm5ic3A7PC9zcGFuPjx1PjwvdT48dT48L3U+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJp ZjsiPlRoeCw8YnI+DQpSLjwvc3Bhbj48dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNh bnMtc2VyaWY7Ij4mbmJzcDs8L3NwYW4+PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzx1PjwvdT48dT48L3U+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgTWF5IDIzLCAyMDE2IGF0IDc6NTAg QU0sIFRhbCBNaXpyYWhpICZsdDs8YSBocmVmPSJtYWlsdG86dGFsbWlAbWFydmVsbC5jb20iIHRh cmdldD0iX2JsYW5rIj50YWxtaUBtYXJ2ZWxsLmNvbTwvYT4mZ3Q7IHdyb3RlOjx1PjwvdT48dT48 L3U+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBBdXRob3JzIG9mIFZYTEFOLUdQRSAv IEdlbmV2ZSw8YnI+DQo8YnI+DQpJIGFtIHJlaXRlcmF0aW5nIG9uIHRoaXMgcXVlc3Rpb24sIGFz IEkgaGF2ZW4ndCBzZWVuIGEgcmVzcG9uc2UgeWV0Ojxicj4NCjxicj4NCkhhdmUgeW91IGNvbnNp ZGVyZWQgdGhlIHVzZSBvZiBTZWdtZW50IFJvdXRpbmcgd2l0aCBWWExBTi1HUEUgLyBHZW5ldmU/ IFRoZSBjdXJyZW50IFZYTEFOLUdQRSAvIEdlbmV2ZSBkcmFmdHMgc2VlbSB0byBpbXBseSB0aGF0 IElQdjYgZXh0ZW5zaW9uIGhlYWRlcnMgYXJlIGN1cnJlbnRseSBub3Qgc3VwcG9ydGVkLjxicj4N Cjxicj4NClRoYW5rcyw8YnI+DQpUYWwuPHU+PC91Pjx1PjwvdT48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4NCiZndDstLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLTxicj4NCiZndDtGcm9tOiBudm8zIFttYWlsdG86PGEgaHJlZj0ibWFpbHRv Om52bzMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm52bzMtYm91bmNlc0BpZXRm Lm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBUYWwgTWl6cmFoaTxicj4NCiZndDtTZW50OiBUdWVzZGF5 LCBNYXkgMTcsIDIwMTYgMTI6MDkgUE08YnI+DQomZ3Q7VG86IFN0ZWZhbm8gUHJldmlkaSAoc3By ZXZpZGkpOyBUb20gSGVyYmVydDsgZHJhZnQtaWV0Zi1udm8zLTxicj4NCiZndDs8YSBocmVmPSJt YWlsdG86Z2VuZXZlQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Z2VuZXZlQHRvb2xz LmlldGYub3JnPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW52bzMtdnhsYW4tZ3Bl QHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZHJhZnQtaWV0Zi1udm8zLXZ4bGFuLWdw ZUB0b29scy5pZXRmLm9yZzwvYT48YnI+DQomZ3Q7Q2M6IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJt YWlsdG86bnZvM0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KbnZvM0BpZXRmLm9yZzwvYT47 IDZtYW4gV0c7IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LTxicj4NCiZndDs8YSBocmVmPSJtYWls dG86cm91dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5yb3V0aW5n LWhlYWRlckB0b29scy5pZXRmLm9yZzwvYT48YnI+DQomZ3Q7U3ViamVjdDogUmU6IFtudm8zXSBb c3ByaW5nXSBMNCBDaGVja3N1bSBhbmQgZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtPGJyPg0KJmd0 O3JvdXRpbmctaGVhZGVyPGJyPg0KJmd0Ozxicj4NCiZndDtTdGVmYW5vLDxicj4NCiZndDs8YnI+ DQomZ3Q7SWYgSSB1bmRlcnN0YW5kIHlvdXIgcG9pbnQgY29ycmVjdGx5Ojxicj4NCiZndDtJUHY2 IHNlZ21lbnQgcm91dGluZyBkb2VzIG5vdCB3b3JrIHdpdGggVlhMQU4gLyBWWExBTi1HUEUgLyBH ZW5ldmUsIHNpbmNlPGJyPg0KJmd0O3RoZXNlIGVuY2Fwc3VsYXRpb25zIGRvIG5vdCBjdXJyZW50 bHkgYWxsb3cgdGhlIHVzZSBvZiBJUHY2IGV4dGVuc2lvbjxicj4NCiZndDtoZWFkZXJzLjxicj4N CiZndDs8YnI+DQomZ3Q7SSB3b25kZXIgaWYgdGhlIGF1dGhvcnMgb2YgVlhMQU4tR1BFIGFuZCBH ZW5ldmUgaGF2ZSBjb25zaWRlcmVkIHRoZSB1c2Ugb2Y8YnI+DQomZ3Q7c2VnbWVudCByb3V0aW5n Ljxicj4NCiZndDs8YnI+DQomZ3Q7VGhhbmtzLDxicj4NCiZndDtUYWwuPGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyZndDstLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCiZndDsmZ3Q7RnJvbTogU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkgW21haWx0bzo8YSBo cmVmPSJtYWlsdG86c3ByZXZpZGlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+c3ByZXZpZGlA Y2lzY28uY29tPC9hPl08YnI+DQomZ3Q7Jmd0O1NlbnQ6IFR1ZXNkYXksIE1heSAxNywgMjAxNiAx MDo0MSBBTTxicj4NCiZndDsmZ3Q7VG86IFRvbSBIZXJiZXJ0PGJyPg0KJmd0OyZndDtDYzogVGFs IE1penJhaGk7IDZtYW4gV0c7IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+Ozxicj4NCiZndDsmZ3Q7ZHJhZnQtaWV0Zi02 bWFuLXNlZ21lbnQtcm91dGluZy0gPGEgaHJlZj0ibWFpbHRvOmhlYWRlckB0b29scy5pZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPg0KaGVhZGVyQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCiZndDsm Z3Q7U3ViamVjdDogUmU6IFtzcHJpbmddIEw0IENoZWNrc3VtIGFuZCBkcmFmdC1pZXRmLTZtYW4t c2VnbWVudC1yb3V0aW5nLTxicj4NCiZndDsmZ3Q7aGVhZGVyPGJyPg0KJmd0OyZndDs8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBPbiBNYXkgMTYsIDIwMTYsIGF0IDc6MTAgUE0sIFRv bSBIZXJiZXJ0ICZsdDs8YSBocmVmPSJtYWlsdG86dG9tQGhlcmJlcnRsYW5kLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPnRvbUBoZXJiZXJ0bGFuZC5jb208L2E+Jmd0Ozxicj4NCiZndDt3cm90ZTo8YnI+ DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgT24gTW9uLCBNYXkgMTYsIDIwMTYgYXQg NDozMiBBTSwgVGFsIE1penJhaGkgJmx0OzxhIGhyZWY9Im1haWx0bzp0YWxtaUBtYXJ2ZWxsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnRhbG1pQG1hcnZlbGwuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0 O3dyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGl04oCZcyBhbGwgYWJvdXQgSVAsIG5v dCBsYXllci0yLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsgcy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBSaWdo dC4gSG93ZXZlciwgaXQgYXBwZWFycyB0aGF0IGF0IGxlYXN0IGluIHNvbWUgY2FzZXMgYSBWWExB TiBWVEVQPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyB3aWxsPGJyPg0KJmd0OyZndDt1c2UgU1IuIEl0 IGNlcnRhaW5seSBtYXkgYmUgdGhlIGNhc2UgaW4gU0ZDIHVzZSBjYXNlcyAoc2VlIFNlY3Rpb24g Mi4zPGJyPg0KJmd0OyZndDtpbiBkcmFmdC0gaWV0Zi1zcHJpbmctaXB2Ni11c2UtY2FzZXMpLjxi cj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg ZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXIgbWVudGlvbnMgdGhhdCB0aGUg cGFja2V0IGlzPGJyPg0KJmd0OyZndDsmZ3Q7IGVuY2Fwc3VsYXRlZDxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0O2ludG8gYW4gb3V0ZXIgaXB2NiBoZWFkZXIgd2hpY2gg bWFrZXMgaXQgYSBsYXllci0zIGVuY2FwLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsgLCBidXQgSSBkb24ndCB0aGluayBpdCBpcyBleHBsaWNpdCBhcyB0byBl eGFjdCBlbmNhcHN1bGF0aW9uIGZvcm1hdDxicj4NCiZndDsmZ3Q7Jmd0OyAoSSBzdXBwb3NlIHNp bXBsZSBpcDZpcDYgaXMgaW1wbGllZCkuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7c2VlIHNlY3Rpb24gMi4yPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyBCdXQsIGl0PGJyPg0KJmd0OyZndDsmZ3Q7IHNlZW1zIGxpa2UgYW55IG9m IHNldmVyYWwgZW5jYXBzdWxhdGlvbiB0ZWNobmlxdWVzIGNvdWxkIHdvcmsgKFZYTEFOLDxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0O0kgaGF2ZSBzb21lIHByb2JsZW1z IHRvIHVuZGVyc3RhbmQgd2hlcmUgdG8gZml0IGFuIGV4dGVuc2lvbiBoZWFkZXI8YnI+DQomZ3Q7 Jmd0O2ludG8gYSB2eGxhbiBlbmNhcOKApjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsgR1JFL0lQLCBFU1AvSVAsIEdVRSwgZm9vIG92ZXIgVURQLCBldGMuKSBh bmQgaWYgYSBkZXZpY2UgdGhhdCB3YW50czxicj4NCiZndDsmZ3Q7Jmd0OyB0byBkbyBTUiBpcyBh bHJlYWR5IGRvaW5nIHR1bm5lbGluZyBpdCBzZWVtcyByZWFzb25hYmxlIHRvIG1lIHRvIG9ubHk8 YnI+DQomZ3Q7Jmd0OyZndDsgaGF2ZSBvbmUgbGF5ZXIgb2YgZW5jYXBzdWxhdGlvbi4gTWF5YmUg dGhpcyBzaG91bGQgYmUgY2xhcmlmaWVkIGluPGJyPg0KJmd0OyZndDsmZ3Q7IHRoZSBkcmFmdD88 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDt0aGUgZHJhZnQgaXMgYWJv dXQgSVB2NiBleHRlbnNpb24gaGVhZGVyIGFuZCBtb3JlIHByZWNpc2VseSBhIG5ldyB0eXBlPGJy Pg0KJmd0OyZndDtvZiB0aGUgcm91dGluZyBleHRlbnNpb24gaGVhZGVyIGRlZmluZWQgaW4gcmZj MjQ2MC4gVGhhdOKAmXMgdGhlIGNvbnRleHQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7cy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUb208YnI+ DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgRnJvbTogU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkg W21haWx0bzo8YSBocmVmPSJtYWlsdG86c3ByZXZpZGlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFu ayI+c3ByZXZpZGlAY2lzY28uY29tPC9hPl08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTZW50 OiBNb25kYXksIE1heSAxNiwgMjAxNiAyOjI0IFBNPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsg VG86IFRhbCBNaXpyYWhpPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2M6IE9sZSBUcsO4YW47 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtNm1h bi1zZWdtZW50LXJvdXRpbmctaGVhZGVyQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ DQpkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlckB0b29scy5pZXRmLm9yZzwv YT47PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT47IDZtYW4gV0c8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3NwcmluZ10gTDQgQ2hlY2tzdW0gYW5k PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGlu Zy0gaGVhZGVyPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBNYXkgMTYsIDIwMTYsIGF0IDE6 MTkgUE0sIFRhbCBNaXpyYWhpICZsdDs8YSBocmVmPSJtYWlsdG86dGFsbWlAbWFydmVsbC5jb20i IHRhcmdldD0iX2JsYW5rIj50YWxtaUBtYXJ2ZWxsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIaSBT dGVmYW5vLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBUaGFua3MgYWdhaW4gZm9yIHRoZSBwcm9tcHQgcmVzcG9uc2UuPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAy LiB0aGUgU1JIIGlzIG9yaWdpbmF0ZWQgYnkgdGhlIGluZ3Jlc3Mgbm9kZSBvZiB0aGUgU1IgZG9t YWluLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhpcyBpcyBkb25lIGJ5IGVu Y2Fwc3VsYXRpbmcgdGhlIHBhY2tldCBpbnRvIGEgb3V0ZXI8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IChhZGRpdGlvbmFsKSBpcHY2IGhlYWRlciBmb2xsb3dlZCBieSBhbiBTUkgu IFRoaXMgaXMgTDM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGVuY2Fwc3VsYXRp b24gYW5kIG5vIEw0IGNoZWNrc3VtIGlzIGludm9sdmVkLiBXaGVuIHRoZSZuYnNwOyBwYWNrZXQ8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxlYXZlcyB0aGUgU1IgdHVubmVsIHRo ZSBvdXRlciBlbmNhcHN1bGF0aW9uJm5ic3A7IChpbmNsdWRpbmcgdGhlIFNSSCk8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlzIHJlbW92ZWQgYW5kIHRoZSBwYWNrZXQgY29udGlu dWVzJm5ic3A7IGl0cyBqb3VybmV5IGxpa2Ugbm90aGluZzxicj4NCiZndDtoYXBwZW5lZC48YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg U28gVlhMQU4gaXMgb2ZmIHRoZSB0YWJsZT88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXTigJlzIGFs bCBhYm91dCBJUCwgbm90IGxheWVyLTIuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXQgd291bGQg YmUgd29ydGh3aGlsZSB0byBjbGFyaWZ5IHRoaXMgaW4gdGhlIGRyYWZ0LiBJZiB5b3UgaGF2ZSBh PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHNwZWNpZmljPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgZW5jYXBzdWxhdGlvbiBpbiBtaW5kLCBpdCB3b3VsZCBiZSBncmVhdCBpZiB0aGUg ZHJhZnQgd291bGQgc3BlY2lmeSBpdC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBUYWwuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRnJv bTogU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkgW21haWx0bzo8YSBocmVmPSJtYWlsdG86c3By ZXZpZGlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+c3ByZXZpZGlAY2lzY28uY29tPC9hPl08 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNlbnQ6IE1vbmRheSwgTWF5IDE2LCAy MDE2IDI6MTMgUE08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiBUYWwgTWl6 cmFoaTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2M6IE9sZSBUcsO4YW47PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0 Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj4NCmRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyQHRvb2xzLmlldGYu b3JnPC9hPjs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0 bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+OyA2 bWFuIFdHPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3Nw cmluZ10gTDQgQ2hlY2tzdW0gYW5kPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBk cmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLSBoZWFkZXI8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIaSw8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBPbiBNYXkgMTYsIDIwMTYsIGF0IDExOjA0IEFNLCBUYWwgTWl6cmFoaSAmbHQ7PGEg aHJlZj0ibWFpbHRvOnRhbG1pQG1hcnZlbGwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGFsbWlAbWFy dmVsbC5jb208L2E+Jmd0Ozxicj4NCiZndDsmZ3Q7d3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBI aSBTdGVmYW5vLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzIGZvciB0aGUgcmVzcG9uc2VzLjxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGV4YWN0bHkuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IE1vcmVvdmVyLCBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlciBhc3N1bWVz PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGVuY2Fwc3VsYXRpb24g c28gY2xlYXJseSB0aGVyZeKAmXMgbm8gTDQgaW52b2x2ZWQgaGVyZS48YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgcy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFR3byBxdWVzdGlvbnM6PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgMS4gV2hhdCBpZiB0aGUgZW5jYXBzdWxhdGlv biBpcyBWWExBTj8gTDQgd291bGQgc3RpbGwgYmU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBpbnZvbHZlZCw8YnI+DQomZ3Q7Jmd0O3JpZ2h0Pzxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTZWUgYmVsb3cuPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAyLiBXaGVuIHlvdSBzYXkgJ2Fzc3VtZXMg ZW5jYXBzdWxhdGlvbicsIGRvZXMgaXQgbWVhbiB0aGF0IGE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBob3N0IGNhbm5vdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgc2VuZCBhbiBJUHY2IHBhY2tldCB3aXRoIGFuIFNSSD8gVGhlIGN1cnJlbnQgZHJhZnQg c2F5czo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEEgU291cmNlIFNSIE5vZGUgY2FuIGJlIGFueSBub2Rl IG9yaWdpbmF0aW5nIGFuIElQdjYgcGFja2V0IHdpdGg8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBpdHM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJ UHY2IGFuZCBTZWdtZW50IFJvdXRpbmcgSGVhZGVycy4mbmJzcDsgVGhpcyBpbmNsdWRlIGVpdGhl cjo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBBIGhvc3Qgb3JpZ2luYXRpbmcgYW4g SVB2NiBwYWNrZXQuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgQW4gU1IgZG9tYWlu IGluZ3Jlc3Mgcm91dGVyIGVuY2Fwc3VsYXRpbmcgYSByZWNlaXZlZCBJUHY2IHBhY2tldDxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBpbnRvIGFuIG91 dGVyIElQdjYgaGVhZGVyIGZvbGxvd2VkIGJ5IGFuIFNSSC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBXaWxsIGFwcHJlY2lhdGUgaWYgeW91IGNhbiBjbGFyaWZ5IHRoYXQu PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9rLCB0d28gY2Fz ZXM6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgMS4gdGhlIFNSSCBpcyBpbnNlcnRlZCBhdCB0aGUgc291cmNlLjxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhlIHNvdXJjZSBvcmlnaW5hdGVzIHRoZSBw YWNrZXQsIHRoZSBpcHY2IGhlYWRlciBhbmQmbmJzcDsgdGhlIFNSSC48YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBzb3VyY2UgY29tcHV0ZXMgTDQgY2hlY2tzdW0gdGFraW5n IGludG8mbmJzcDsgYWNjb3VudCB0aGUgd2hvbGU8YnI+DQomZ3Q7Jmd0O0lQdjYmIzQzO1NSSC48 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhlcmUsIHRoZXJlc+KAmSBub3RoaW5n IG5ldyZuYnNwOyBjb21wYXJlZCB0byByZmMyNDYwLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDIuIHRoZSBTUkggaXMg b3JpZ2luYXRlZCBieSB0aGUgaW5ncmVzcyBub2RlIG9mIHRoZSBTUiBkb21haW4uPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGlzIGlzIGRvbmUgYnkgZW5jYXBzdWxhdGluZyB0 aGUgcGFja2V0IGludG8gYSBvdXRlcjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg KGFkZGl0aW9uYWwpIGlwdjYgaGVhZGVyIGZvbGxvd2VkIGJ5IGFuIFNSSC4gVGhpcyBpcyBMMzxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZW5jYXBzdWxhdGlvbiBhbmQgbm8gTDQg Y2hlY2tzdW0gaXMgaW52b2x2ZWQuIFdoZW4gdGhlJm5ic3A7IHBhY2tldDxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbGVhdmVzIHRoZSBTUiB0dW5uZWwgdGhlIG91dGVyIGVuY2Fw c3VsYXRpb24mbmJzcDsgKGluY2x1ZGluZyB0aGUgU1JIKTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgaXMgcmVtb3ZlZCBhbmQgdGhlIHBhY2tldCBjb250aW51ZXMmbmJzcDsgaXRz IGpvdXJuZXkgbGlrZSBub3RoaW5nPGJyPg0KJmd0O2hhcHBlbmVkLjxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHMuPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBUYWwuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg RnJvbTogU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkgW21haWx0bzo8YSBocmVmPSJtYWlsdG86 c3ByZXZpZGlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+c3ByZXZpZGlAY2lzY28uY29tPC9h Pl08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2VudDogTW9uZGF5 LCBNYXkgMTYsIDIwMTYgMTE6NTkgQU08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgVG86IE9sZSBUcsO4YW47IFRhbCBNaXpyYWhpPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi02bWFu LXNlZ21lbnQtcm91dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4N CmRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyQHRvb2xzLmlldGYub3JnPC9h Pjs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFp bHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT47 IDZtYW4gV0c8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU3ViamVj dDogUmU6IFtzcHJpbmddIEw0IENoZWNrc3VtIGFuZDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLSBoZWFkZXI8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IE9uIE1heSAxNSwgMjAxNiwgYXQgODowNiBQTSwgPGEgaHJlZj0ibWFp bHRvOm90cm9hbkBlbXBsb3llZXMub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpvdHJvYW5AZW1wbG95 ZWVzLm9yZzwvYT4gd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGFs LDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBbQXBvbG9naWVzIGlmIHRo aXMgaXNzdWUgaGFzIGJlZW4gZGlzY3Vzc2VkIGJlZm9yZS5dPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBY2NvcmRpbmcgdG8gZHJhZnQtaWV0Zi02bWFuLXNlZ21l bnQtcm91dGluZy1oZWFkZXIsIGFuIOKAmFNSPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2VnbWVudDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBFbmRwb2ludCBOb2Rl4oCZIHVwZGF0ZXMgdGhlIERlc3RpbmF0aW9uIElQ IGFkZHJlc3MuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgVGhlcmVmb3JlLCBpdCBtdXN0IGFsc28gdXBkYXRlIHRoZSBMYXllciA0IENoZWNrc3VtLCBy aWdodD88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgd29uZGVy IGlmIHRoZXJlIGlzIGFuIHVwcGVyIGJvdW5kIG9uIHRoZSBzaXplIG9mIHRoZSBTUkguPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT3RoZXJ3aXNlLCB0 aGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTDQgQ2hlY2tzdW0g bWF5IGJlIGxvY2F0ZWQgaW4gYSBwcmV0dHkgZGVlcCBsb2NhdGlvbi48YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTcGVha2luZyBmcm9tIGEgY2hpcCB2 ZW5kb3LigJlzIHBlcnNwZWN0aXZlIHRoaXMgbWF5IGJlIGEgcHJvYmxlbS48YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBGcm9tIFJGQzI0NjAsIFJIMDo8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmbmJzcDsgJm5ic3A7byZuYnNwOyBJZiB0aGUgSVB2NiBwYWNrZXQgY29udGFpbnMg YSBSb3V0aW5nIGhlYWRlciwgdGhlIERlc3RpbmF0aW9uPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IEFkZHJlc3MgdXNlZCBp biB0aGUgcHNldWRvLWhlYWRlciBpcyB0aGF0IG9mIHRoZSBmaW5hbDxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBkZXN0aW5h dGlvbi4mbmJzcDsgQXQgdGhlIG9yaWdpbmF0aW5nIG5vZGUsIHRoYXQgYWRkcmVzcyB3aWxsIGJl IGluPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7IHRoZSBsYXN0IGVsZW1lbnQgb2YgdGhlIFJvdXRpbmcgaGVhZGVyOyBhdCB0 aGUgcmVjaXBpZW50KHMpLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGF0IGFkZHJlc3Mgd2lsbCBiZSBpbiB0aGUgRGVz dGluYXRpb24gQWRkcmVzcyBmaWVsZCBvZiB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgSVB2NiBoZWFkZXIuPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSB3b3VsZCBleHBlY3QgU1Igd291bGQgd29y ayB0aGUgc2FtZS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZXhhY3RseS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgTW9yZW92ZXIsIGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyIGFzc3Vt ZXM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZW5jYXBzdWxhdGlv biBzbyBjbGVhcmx5IHRoZXJl4oCZcyBubyBMNCBpbnZvbHZlZCBoZXJlLjxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBzLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IENoZWVycyw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9sZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBJRVRGIElQdjYgd29y a2luZyBncm91cCBtYWlsaW5nIGxpc3QgPGEgaHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmciIHRh cmdldD0iX2JsYW5rIj4NCmlwdjZAaWV0Zi5vcmc8L2E+IEFkbWluaXN0cmF0aXZlPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyBSZXF1ZXN0czogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pcHY2IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2lwdjY8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLTxicj4NCiZndDs8YnI+DQomZ3Q7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188YnI+DQomZ3Q7bnZvMyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7PGEgaHJl Zj0ibWFpbHRvOm52bzNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5udm8zQGlldGYub3JnPC9h Pjxicj4NCiZndDs8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L252bzMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL252bzM8L2E+PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXzxicj4NCnNwcmluZyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJt YWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+c3ByaW5nQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3By aW5nIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zcHJpbmc8L2E+PHU+PC91Pjx1PjwvdT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8dT48L3U+PHU+PC91PjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHU+PC91PiZuYnNwOzx1PjwvdT48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_36D9FCF0382C466985A5C782636A85BBvmwarecom_-- From nobody Mon May 23 13:55:35 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66BDF12DBC7; Mon, 23 May 2016 13:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16OOq_86cGVA; Mon, 23 May 2016 13:55:15 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27BA12DBC4; Mon, 23 May 2016 13:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57395; q=dns/txt; s=iport; t=1464036914; x=1465246514; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=PLenvxdbG4nPwZf8epfCRAqRUNJP8G4ISd07LKf8Lyw=; b=KEJFX+0fB7crAx21kfxZcdPyr1OQpZUg4g4tWA8OJ17wYGFbAp5VW6MP LFD3JBcbKyP21NMvxNAp7mu3F0b78uakve2WMo2jo+oLYrGM+9B6bfejj CW+GyYJ0Rvrp7+VCTTfimvg4vbHs/UUMiVJPHE3hdwEGbCYMfkwRQ3Dwv Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAgB6bUNX/4QNJK1cgmxLVn0GrgyLb?= =?us-ascii?q?wENgXMEFwEKhSVKAoE2OBQBAQEBAQEBZSeEQgEBAQMBAQEBF1QLBQcEAgEIEQM?= =?us-ascii?q?BAQEBFQsBBgchBgsUCQgCBA4FiBUDDwcBDr88DYQmAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBFwWJcYEDgkOBWUMWCYUbBYgEizOETTMBiHeDL4F5gWmNM4YzgTGHZwE?= =?us-ascii?q?eAQFCg21uiBMBBhkfAX4BAQE?= X-IronPort-AV: E=Sophos;i="5.26,357,1459814400"; d="scan'208,217";a="110219371" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 May 2016 20:55:12 +0000 Received: from XCH-RTP-007.cisco.com (xch-rtp-007.cisco.com [64.101.220.147]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u4NKtCs4011481 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 23 May 2016 20:55:12 GMT Received: from xch-rtp-007.cisco.com (64.101.220.147) by XCH-RTP-007.cisco.com (64.101.220.147) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 23 May 2016 16:55:11 -0400 Received: from xch-rtp-007.cisco.com ([64.101.220.147]) by XCH-RTP-007.cisco.com ([64.101.220.147]) with mapi id 15.00.1104.009; Mon, 23 May 2016 16:55:11 -0400 From: "Larry Kreeger (kreeger)" To: Tal Mizrahi Thread-Topic: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routing-header Thread-Index: AQHRtMWtEanFs1cLO0Wbr2+S/VrgGZ/GZ/OAgAACKYCAAARgAIAAy/oA//+UdAA= Date: Mon, 23 May 2016 20:55:11 +0000 Message-ID: References: <5dc56935eba94c2390120244564f9b21@IL-EXCH02.marvell.com> <0551686F-F1D2-4C34-81C8-530F1BEE1BDF@cisco.com> <5d889e7013b44b27ae1e75cf7ea2dd22@IL-EXCH02.marvell.com> <3549ABBE-9828-42D2-A056-851432487E2E@cisco.com> <1e13d2e32b2448af94bf23d5acf17740@IL-EXCH02.marvell.com> <569a4067fd1f45dd85d60e983be69b90@IL-EXCH02.marvell.com> <1c27bb3513bc48889ec310e8d143784c@IL-EXCH02.marvell.com> <36D9FCF0-382C-4669-85A5-C782636A85BB@vmware.com> In-Reply-To: <36D9FCF0-382C-4669-85A5-C782636A85BB@vmware.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.2.160219 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [171.71.35.113] Content-Type: multipart/alternative; boundary="_000_D368BC0419BA29kreegerciscocom_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , 6man WG , "draft-ietf-nvo3-vxlan-gpe@tools.ietf.org" , "nvo3@ietf.org" , "draft-ietf-6man-segment-routing-header@tools.ietf.org" , "draft-ietf-nvo3-geneve@tools.ietf.org" , "Stefano Previdi \(sprevidi\)" Subject: Re: [spring] [nvo3] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 20:55:18 -0000 --_000_D368BC0419BA29kreegerciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree with Robert and Jesse. - Larry From: Jesse Gross > Date: Monday, May 23, 2016 at 1:19 PM To: Robert Raszuk >, Tal Mizrah= i > Cc: "draft-ietf-nvo3-geneve@tools.ietf.org" >, "draft-ietf-nvo3-vxlan-gpe@tools.ietf.org" >, "spring@ietf.= org" >, 6ma= n WG >, "nvo3@ietf.org" >, "draft-ietf-6man-segment-rout= ing-header@tools.ietf.org" >, "Stefano Previdi = (sprevidi)" > Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routin= g-header Resent-From: >, > Resent-To: Larry Kreeger >, >, > Resent-Date: Monday, May 23, 2016 at 1:20 PM I agree that I don=92t believe that there is anything in these drafts that = precludes the use of extension headers or segment routing =96 IP is simply = the layer underneath that these protocols are building on. The figures are = definitely just examples =96 they also show outer Ethernet headers, which i= s not a requirement. I wouldn=92t want to add text specifically stating that extension headers a= re permissible. It seems like that could lead to similar questions in the f= uture where one might wonder if other features of IP are allowed because on= e is explicitly listed and others are not, etc. In my opinion, the drafts a= re about as clear as they can be on this point. Jesse On 5/23/16, 1:09 AM, "rraszuk@gmail.com on behalf= of Robert Raszuk" on behalf o= f robert@raszuk.net> wrote: Hi Tal, > In order to avoid ambiguity, it would be great if the > authors could explicitly mention that IPv6 extension > headers are permitted. Well the drafts are complaint to RFC2119 (normative reference) so unless th= e text excludes elements with MUST/MUST NOT - everything else defined in th= e building blocks they (re)use is permitted. However as you say perhaps for clarity what could be added to those drafts = is a normative reference to IPv4 and IPv6 base RFCs. Best, R. On Mon, May 23, 2016 at 9:54 AM, Tal Mizrahi > wrote: Hi Robert, That makes sense. However, in this case the figures may be a bit confusing WRT the possible e= xistence of extension headers. This confusion is what led to the discussion= in this thread about whether segment routing is possible with VXLAN/VXLAN-= GPE/Geneve encapsulations. In order to avoid ambiguity, it would be great if the authors could explici= tly mention that IPv6 extension headers are permitted. Regards, Tal. From:rraszuk@gmail.com [mailto:rraszuk@gmail.com<= mailto:rraszuk@gmail.com>] On Behalf Of Robert Raszuk Sent: Monday, May 23, 2016 10:47 AM To: Tal Mizrahi Cc: spring@ietf.org; 6man WG; draft-ietf-nvo3-vxlan= -gpe@tools.ietf.org; nvo3@= ietf.org; draft-ietf-6man-segment-routing-header@tool= s.ietf.org; d= raft-ietf-nvo3-geneve@tools.ietf.org; Stefano Previdi (sprevidi) Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routin= g-header Hi Tal, Indeed .. I saw the figures, but figures are non normative in any draft/rfc= unless text below specifically spells it out. For example from vxlan-gpe: "When the outer IP header is IPv4, VTEPs MUST set the DF bit." Besides it is pretty challenging to add animation to the current draft form= ats to illustrate all possibly allowed field values/combinations in any fig= ure :) Figures just illustrate one use example. To me the current specs permit any value of IPv6 NxtHdr field as permitted = in both encapsulations. Best, Robert. On Mon, May 23, 2016 at 9:35 AM, Tal Mizrahi > wrote: Hi Robert, >Where say in draft draft-quinn-vxlan-gpe do you see such statement that wo= uld imply > that v6 NxtHdr must be only equal to 17 (UDP) and not be a pointer to any= other type > of extension header further followed by UDP ? The following text is from Figure 4 in draft-ietf-nvo3-vxlan-gpe: Outer IPv6 Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | NxtHdr=3D17(UDP)| Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | There is a similar figure in draft-ietf-nvo3-geneve. Best regards, Tal. From: nvo3 [mailto:nvo3-bounces@ietf.org] On = Behalf Of Robert Raszuk Sent: Monday, May 23, 2016 10:29 AM To: Tal Mizrahi Cc: spring@ietf.org; 6man WG; draft-ietf-nvo3-vxlan= -gpe@tools.ietf.org; nvo3@= ietf.org; draft-ietf-6man-segment-routing-header@tool= s.ietf.org; d= raft-ietf-nvo3-geneve@tools.ietf.org; Stefano Previdi (sprevidi) Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routin= g-header Hi Tal, > drafts seem to imply Where say in draft draft-quinn-vxlan-gpe do you see such statement that wou= ld imply that v6 NxtHdr must be only equal to 17 (UDP) and not be a pointer= to any other type of extension header further followed by UDP ? Thx, R. On Mon, May 23, 2016 at 7:50 AM, Tal Mizrahi > wrote: Dear Authors of VXLAN-GPE / Geneve, I am reiterating on this question, as I haven't seen a response yet: Have you considered the use of Segment Routing with VXLAN-GPE / Geneve? The= current VXLAN-GPE / Geneve drafts seem to imply that IPv6 extension header= s are currently not supported. Thanks, Tal. >-----Original Message----- >From: nvo3 [mailto:nvo3-bounces@ietf.org] On= Behalf Of Tal Mizrahi >Sent: Tuesday, May 17, 2016 12:09 PM >To: Stefano Previdi (sprevidi); Tom Herbert; draft-ietf-nvo3- >geneve@tools.ietf.org; draft-ietf-nvo3-vxlan= -gpe@tools.ietf.org >Cc: spring@ietf.org; nvo3@ietf.org; 6man WG; draft-ietf-6man-segment- >routing-header@tools.ietf.org >Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment- >routing-header > >Stefano, > >If I understand your point correctly: >IPv6 segment routing does not work with VXLAN / VXLAN-GPE / Geneve, since >these encapsulations do not currently allow the use of IPv6 extension >headers. > >I wonder if the authors of VXLAN-GPE and Geneve have considered the use of >segment routing. > >Thanks, >Tal. > > > >>-----Original Message----- >>From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >>Sent: Tuesday, May 17, 2016 10:41 AM >>To: Tom Herbert >>Cc: Tal Mizrahi; 6man WG; spring@ietf.org; >>draft-ietf-6man-segment-routing- header@tools.ietf.org >>Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing- >>header >> >> >>> On May 16, 2016, at 7:10 PM, Tom Herbert > >wrote: >>> >>> On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi > >>wrote: >>>>> it=92s all about IP, not layer-2. >>>>> >>>>> s. >>>> >>>> Right. However, it appears that at least in some cases a VXLAN VTEP >>>> will >>use SR. It certainly may be the case in SFC use cases (see Section 2.3 >>in draft- ietf-spring-ipv6-use-cases). >>>> >>> >>> draft-ietf-6man-segment-routing-header mentions that the packet is >>> encapsulated >> >> >>into an outer ipv6 header which makes it a layer-3 encap. >> >> >>> , but I don't think it is explicit as to exact encapsulation format >>> (I suppose simple ip6ip6 is implied). >> >> >>see section 2.2 >> >> >>> But, it >>> seems like any of several encapsulation techniques could work (VXLAN, >> >> >>I have some problems to understand where to fit an extension header >>into a vxlan encap=85 >> >> >>> GRE/IP, ESP/IP, GUE, foo over UDP, etc.) and if a device that wants >>> to do SR is already doing tunneling it seems reasonable to me to only >>> have one layer of encapsulation. Maybe this should be clarified in >>> the draft? >> >> >>the draft is about IPv6 extension header and more precisely a new type >>of the routing extension header defined in rfc2460. That=92s the context. >> >> >>s. >> >> >> >> >>> >>> Tom >>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >>>>> Sent: Monday, May 16, 2016 2:24 PM >>>>> To: Tal Mizrahi >>>>> Cc: Ole Tr=F8an; >>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org; >>>>> spring@ietf.org; 6man WG >>>>> Subject: Re: [spring] L4 Checksum and >>>>> draft-ietf-6man-segment-routing- header >>>>> >>>>> >>>>>> On May 16, 2016, at 1:19 PM, Tal Mizrahi > wrote: >>>>>> >>>>>> Hi Stefano, >>>>>> >>>>>> Thanks again for the prompt response. >>>>>> >>>>>>> 2. the SRH is originated by the ingress node of the SR domain. >>>>>>> This is done by encapsulating the packet into a outer >>>>>>> (additional) ipv6 header followed by an SRH. This is L3 >>>>>>> encapsulation and no L4 checksum is involved. When the packet >>>>>>> leaves the SR tunnel the outer encapsulation (including the SRH) >>>>>>> is removed and the packet continues its journey like nothing >happened. >>>>>> >>>>>> So VXLAN is off the table? >>>>> >>>>> >>>>> it=92s all about IP, not layer-2. >>>>> >>>>> s. >>>>> >>>>> >>>>>> It would be worthwhile to clarify this in the draft. If you have a >>>>>> specific >>>>> encapsulation in mind, it would be great if the draft would specify i= t. >>>>>> >>>>>> Thanks, >>>>>> Tal. >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >>>>>>> Sent: Monday, May 16, 2016 2:13 PM >>>>>>> To: Tal Mizrahi >>>>>>> Cc: Ole Tr=F8an; >>>>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org; >>>>>>> spring@ietf.org; 6man WG >>>>>>> Subject: Re: [spring] L4 Checksum and >>>>>>> draft-ietf-6man-segment-routing- header >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On May 16, 2016, at 11:04 AM, Tal Mizrahi > >>wrote: >>>>>>>> >>>>>>>> Hi Stefano, >>>>>>>> >>>>>>>> Thanks for the responses. >>>>>>>> >>>>>>>>> exactly. >>>>>>>>> >>>>>>>>> Moreover, draft-ietf-6man-segment-routing-header assumes >>>>>>>>> encapsulation so clearly there=92s no L4 involved here. >>>>>>>>> >>>>>>>>> s. >>>>>>>> >>>>>>>> Two questions: >>>>>>>> 1. What if the encapsulation is VXLAN? L4 would still be >>>>>>>> involved, >>right? >>>>>>> >>>>>>> >>>>>>> See below. >>>>>>> >>>>>>> >>>>>>>> 2. When you say 'assumes encapsulation', does it mean that a >>>>>>>> host cannot >>>>>>> send an IPv6 packet with an SRH? The current draft says: >>>>>>>> >>>>>>>> A Source SR Node can be any node originating an IPv6 packet with >>>>>>>> its >>>>>>>> IPv6 and Segment Routing Headers. This include either: >>>>>>>> >>>>>>>> A host originating an IPv6 packet. >>>>>>>> >>>>>>>> An SR domain ingress router encapsulating a received IPv6 packe= t >>>>>>>> into an outer IPv6 header followed by an SRH. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Will appreciate if you can clarify that. >>>>>>> >>>>>>> >>>>>>> ok, two cases: >>>>>>> >>>>>>> 1. the SRH is inserted at the source. >>>>>>> the source originates the packet, the ipv6 header and the SRH. >>>>>>> The source computes L4 checksum taking into account the whole >>IPv6+SRH. >>>>>>> Here, theres=92 nothing new compared to rfc2460. >>>>>>> >>>>>>> 2. the SRH is originated by the ingress node of the SR domain. >>>>>>> This is done by encapsulating the packet into a outer >>>>>>> (additional) ipv6 header followed by an SRH. This is L3 >>>>>>> encapsulation and no L4 checksum is involved. When the packet >>>>>>> leaves the SR tunnel the outer encapsulation (including the SRH) >>>>>>> is removed and the packet continues its journey like nothing >happened. >>>>>>> >>>>>>> s. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tal. >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >>>>>>>>> Sent: Monday, May 16, 2016 11:59 AM >>>>>>>>> To: Ole Tr=F8an; Tal Mizrahi >>>>>>>>> Cc: draft-ietf-6man-segment-routing-header@tools.ietf.org; >>>>>>>>> spring@ietf.org; 6man WG >>>>>>>>> Subject: Re: [spring] L4 Checksum and >>>>>>>>> draft-ietf-6man-segment-routing- header >>>>>>>>> >>>>>>>>> >>>>>>>>>> On May 15, 2016, at 8:06 PM, otroan@employees.org wrote: >>>>>>>>>> >>>>>>>>>> Tal, >>>>>>>>>> >>>>>>>>>>> [Apologies if this issue has been discussed before.] >>>>>>>>>>> >>>>>>>>>>> According to draft-ietf-6man-segment-routing-header, an =91SR >>>>>>>>>>> Segment >>>>>>>>> Endpoint Node=92 updates the Destination IP address. >>>>>>>>>>> Therefore, it must also update the Layer 4 Checksum, right? >>>>>>>>>>> >>>>>>>>>>> I wonder if there is an upper bound on the size of the SRH. >>>>>>>>>>> Otherwise, the >>>>>>>>> L4 Checksum may be located in a pretty deep location. >>>>>>>>>>> Speaking from a chip vendor=92s perspective this may be a probl= em. >>>>>>>>>> >>>>>>>>>> From RFC2460, RH0: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> o If the IPv6 packet contains a Routing header, the Destinati= on >>>>>>>>>> Address used in the pseudo-header is that of the final >>>>>>>>>> destination. At the originating node, that address will be= in >>>>>>>>>> the last element of the Routing header; at the recipient(s)= , >>>>>>>>>> that address will be in the Destination Address field of th= e >>>>>>>>>> IPv6 header. >>>>>>>>>> >>>>>>>>>> I would expect SR would work the same. >>>>>>>>> >>>>>>>>> >>>>>>>>> exactly. >>>>>>>>> >>>>>>>>> Moreover, draft-ietf-6man-segment-routing-header assumes >>>>>>>>> encapsulation so clearly there=92s no L4 involved here. >>>>>>>>> >>>>>>>>> s. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Ole >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_D368BC0419BA29kreegerciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1478E4122B4C8841A17A302DFFF113C3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
I agree with Robert and Jesse. - Larry

From: Jesse Gross <jgross@vmware.com>
Date: Monday, May 23, 2016 at 1:19 = PM
To: Robert Raszuk <robert@raszuk.net>, Tal Mizrahi <talmi@marvell.com>
Cc: "draft-ietf-nvo3-geneve@tools.ietf.org&q= uot; <draft-iet= f-nvo3-geneve@tools.ietf.org>, "draft-ietf-nvo3-vxlan-gpe@tools.ietf.org&q= uot; <draft-ietf= -nvo3-vxlan-gpe@tools.ietf.org>, "spring@ietf.org" <spri= ng@ietf.org>, 6man WG <ipv6@ietf= .org>, "nvo3@ietf.org" <nvo3@ietf.org>, "draft-ietf-6man-segmen= t-routing-header@tools.ietf.org" <draft-ietf-6man-segment-routing= -header@tools.ietf.org>, "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
Subject: Re: [nvo3] [spring] L4 Che= cksum and draft-ietf-6man-segment-routing-header
Resent-From: <alias-bounces@ietf.org>, <jgross@vmware.com>
Resent-To: Larry Kreeger <kreeger@cisco.com>, <uri.elzur@intel.com>, <draft-ietf-6man-segment-= routing-header@ietf.org>
Resent-Date: Monday, May 23, 2016 a= t 1:20 PM

I agree that I don=92t believe that there is anything in these drafts = that precludes the use of extension headers or segment routing =96 IP is si= mply the layer underneath that these protocols are building on. The figures= are definitely just examples =96 they also show outer Ethernet headers, which is not a requirement.

I wouldn=92t want to add text specifically stating that extension head= ers are permissible. It seems like that could lead to similar questions in = the future where one might wonder if other features of IP are allowed becau= se one is explicitly listed and others are not, etc. In my opinion, the drafts are about as clear as they can be = on this point.

Jesse

On 5/23/16, 1:09 AM, "rraszu= k@gmail.com on behalf of Robert Raszuk" <rraszuk@gmail.com on behalf of robert@raszuk.net> wrote:

Hi Tal,

> In order to avoid ambiguity, it would be great i= f the 
> authors could explicitly mention that IPv6 exten= sion 
> headers are permitted.

Well the drafts are complaint to RFC2119 (normative reference) so unless th= e text excludes elements with MUST/MUST NOT - everything else defined in th= e building blocks they (re)use is permitted. 

However as you say perhaps for clarity what could be added to those drafts = is a normative reference to IPv4 and IPv6 base RFCs.

Best,
R.


On Mon, May 23, 2016 at 9:54 AM, Tal Mizrahi <talmi@marvell.co= m> wrote:

Hi Robert,

 

That makes sense.

However, in this case the figures m= ay be a bit confusing WRT the possible existence of extension headers. This= confusion is what led to the discussion in this thread about whether segment routing is possible with VXLAN/VXLAN-= GPE/Geneve encapsulations.

 

In order to avoid ambiguity, it wou= ld be great if the authors could explicitly mention that IPv6 extension hea= ders are permitted.

 

Regards,

Tal.

 

From:rraszuk@gmail.com [mailto:rraszuk@gmail.com] On Behalf Of Robert Raszuk
Sent: Monday, May 23, 2016 10:47 AM


To: Tal Mizrahi
Cc: spring@ietf= .org; 6man WG; draft-ietf-nvo3-vxlan-gpe@tools.ietf.org; nvo3@ietf.org; draft-ietf-6man-segment-routing-header@tools.ietf.org; draft-ietf-nvo3-geneve@tools.ietf.org; Stefano Previdi (sprevidi)
Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment= -routing-header

 

Hi T= al,

<= /u> 

Inde= ed .. I saw the figures, but figures are non normative in any draft/rfc unl= ess text below specifically spells it out. 

<= /u> 

For = example from vxlan-gpe: 

<= /u> 

&quo= t;When the outer IP header is IPv4, VTEPs MUST = set the DF bit."

<= /u> 

Besi= des it is pretty challenging to add animation to the current draft formats = to illustrate all possibly allowed field values/combinations in any figure = :)  Figures just illustrate one use example. 

<= /u> 

To m= e the current specs permit any value of IPv6 NxtHdr field as permitted in b= oth encapsulations.

<= /u> 

Best= ,

Robe= rt.

<= /u> 

 

On Mon, May 23, 2016 at 9:35 AM, Tal Mizrahi <talmi@marvell.com&g= t; wrote:

Hi Robert,

 

 

>Where s= ay in draft draft-quinn-vxlan-gpe do you see such statement that would imply

> that v6 NxtHdr must be only eq= ual to 17 (UDP) and not be a pointer to any other type

> of extension header further fo= llowed by UDP ?

 

 

The following text is from Figure 4= in draft-ietf-nvo3-vxlan-gpe:

 

      Outer IPv6= Header:

      +-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+

      |Version| = Traffic Class |          = Flow Label          &nbs= p;       |

      +-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+

      | &nb= sp;       Payload Length   &nb= sp;    | NxtHdr=3D17(UDP)|   Hop Limit  = |

      +-+= ;-+-+-+-+-+-+-+-+-+-+-+-+-&= #43;-+-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+

      | &nb= sp;            =             &nb= sp;             = ;            &n= bsp;          |=

 

 

There is a similar figure in draft-= ietf-nvo3-geneve.

 

Best regards,<= /p>

Tal.

 

From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Monday, May 23, 2016 10:29 AM
To: Tal Mizrahi
Cc: spring@ietf= .org; 6man WG; draft-ietf-nvo3-vxlan-gpe@tools.ietf.org; nvo3@ietf.org; draft-ietf-6man-segment-routing-header@tools.ietf.org; draft-ietf-nvo3-geneve@tools.ietf.org; Stefano Previdi (sprevidi)


Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment= -routing-header

 

Hi T= al,

&nbs= p;

>=  drafts seem to imply

&nbs= p;

Wher= e say in draft draft-quinn-vxlan-gpe do you see such statement that wo= uld imply that v6 NxtHdr must be only equal to 17 (UDP) and not be a pointe= r to any other type of extension header further followed by UDP ? 

&nbs= p;

Thx,=
R.

&nbs= p;

 

On Mon, May 23, 2016 at 7:50 AM, Tal Mizrahi <talmi@marvell.com&g= t; wrote:

Dear Authors of VXLAN-GPE / Geneve,

I am reiterating on this question, as I haven't seen a response yet:

Have you considered the use of Segment Routing with VXLAN-GPE / Geneve? The= current VXLAN-GPE / Geneve drafts seem to imply that IPv6 extension header= s are currently not supported.

Thanks,
Tal.




>-----Original Message-----
>From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Tal Mizrahi
>Sent: Tuesday, May 17, 2016 12:09 PM
>To: Stefano Previdi (sprevidi); Tom Herbert; draft-ietf-nvo3-
>geneve@tools= .ietf.org; draft-ietf-nvo3-vxlan-gpe@tools.ietf.org
>Cc: spring@ietf.or= g; nvo3@ietf.org; 6man WG; draft-ietf-6man-segment-
>rout= ing-header@tools.ietf.org
>Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment- >routing-header
>
>Stefano,
>
>If I understand your point correctly:
>IPv6 segment routing does not work with VXLAN / VXLAN-GPE / Geneve, sin= ce
>these encapsulations do not currently allow the use of IPv6 extension >headers.
>
>I wonder if the authors of VXLAN-GPE and Geneve have considered the use= of
>segment routing.
>
>Thanks,
>Tal.
>
>
>
>>-----Original Message-----
>>From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
>>Sent: Tuesday, May 17, 2016 10:41 AM
>>To: Tom Herbert
>>Cc: Tal Mizrahi; 6man WG; spring@ietf.org;
>>draft-ietf-6man-segment-routing- header@tools.ietf.org
>>Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routi= ng-
>>header
>>
>>
>>> On May 16, 2016, at 7:10 PM, Tom Herbert <tom@herbertland.com>
>wrote:
>>>
>>> On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi <talmi@marvell.com>
>>wrote:
>>>>> it=92s all about IP, not layer-2.
>>>>>
>>>>> s.
>>>>
>>>> Right. However, it appears that at least in some cases a V= XLAN VTEP
>>>> will
>>use SR. It certainly may be the case in SFC use cases (see Section = 2.3
>>in draft- ietf-spring-ipv6-use-cases).
>>>>
>>>
>>> draft-ietf-6man-segment-routing-header mentions that the packe= t is
>>> encapsulated
>>
>>
>>into an outer ipv6 header which makes it a layer-3 encap.
>>
>>
>>> , but I don't think it is explicit as to exact encapsulation f= ormat
>>> (I suppose simple ip6ip6 is implied).
>>
>>
>>see section 2.2
>>
>>
>>> But, it
>>> seems like any of several encapsulation techniques could work = (VXLAN,
>>
>>
>>I have some problems to understand where to fit an extension header=
>>into a vxlan encap=85
>>
>>
>>> GRE/IP, ESP/IP, GUE, foo over UDP, etc.) and if a device that = wants
>>> to do SR is already doing tunneling it seems reasonable to me = to only
>>> have one layer of encapsulation. Maybe this should be clarifie= d in
>>> the draft?
>>
>>
>>the draft is about IPv6 extension header and more precisely a new t= ype
>>of the routing extension header defined in rfc2460. That=92s the co= ntext.
>>
>>
>>s.
>>
>>
>>
>>
>>>
>>> Tom
>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
>>>>> Sent: Monday, May 16, 2016 2:24 PM
>>>>> To: Tal Mizrahi
>>>>> Cc: Ole Tr=F8an;
>>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org;
>>>>> s= pring@ietf.org; 6man WG
>>>>> Subject: Re: [spring] L4 Checksum and
>>>>> draft-ietf-6man-segment-routing- header
>>>>>
>>>>>
>>>>>> On May 16, 2016, at 1:19 PM, Tal Mizrahi <talmi@marvell.com>= wrote:
>>>>>>
>>>>>> Hi Stefano,
>>>>>>
>>>>>> Thanks again for the prompt response.
>>>>>>
>>>>>>> 2. the SRH is originated by the ingress node o= f the SR domain.
>>>>>>> This is done by encapsulating the packet into = a outer
>>>>>>> (additional) ipv6 header followed by an SRH. T= his is L3
>>>>>>> encapsulation and no L4 checksum is involved. = When the  packet
>>>>>>> leaves the SR tunnel the outer encapsulation&n= bsp; (including the SRH)
>>>>>>> is removed and the packet continues  its = journey like nothing
>happened.
>>>>>>
>>>>>> So VXLAN is off the table?
>>>>>
>>>>>
>>>>> it=92s all about IP, not layer-2.
>>>>>
>>>>> s.
>>>>>
>>>>>
>>>>>> It would be worthwhile to clarify this in the draf= t. If you have a
>>>>>> specific
>>>>> encapsulation in mind, it would be great if the draft = would specify it.
>>>>>>
>>>>>> Thanks,
>>>>>> Tal.
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]<= br> >>>>>>> Sent: Monday, May 16, 2016 2:13 PM
>>>>>>> To: Tal Mizrahi
>>>>>>> Cc: Ole Tr=F8an;
>>>>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org;
>>>>>>> spring@ietf.org; 6man WG
>>>>>>> Subject: Re: [spring] L4 Checksum and
>>>>>>> draft-ietf-6man-segment-routing- header
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On May 16, 2016, at 11:04 AM, Tal Mizrahi <= talmi@marvell.com>
>>wrote:
>>>>>>>>
>>>>>>>> Hi Stefano,
>>>>>>>>
>>>>>>>> Thanks for the responses.
>>>>>>>>
>>>>>>>>> exactly.
>>>>>>>>>
>>>>>>>>> Moreover, draft-ietf-6man-segment-rout= ing-header assumes
>>>>>>>>> encapsulation so clearly there=92s no = L4 involved here.
>>>>>>>>>
>>>>>>>>> s.
>>>>>>>>
>>>>>>>> Two questions:
>>>>>>>> 1. What if the encapsulation is VXLAN? L4 = would still be
>>>>>>>> involved,
>>right?
>>>>>>>
>>>>>>>
>>>>>>> See below.
>>>>>>>
>>>>>>>
>>>>>>>> 2. When you say 'assumes encapsulation', d= oes it mean that a
>>>>>>>> host cannot
>>>>>>> send an IPv6 packet with an SRH? The current d= raft says:
>>>>>>>>
>>>>>>>> A Source SR Node can be any node originati= ng an IPv6 packet with
>>>>>>>> its
>>>>>>>> IPv6 and Segment Routing Headers.  Th= is include either:
>>>>>>>>
>>>>>>>>    A host originating an IPv6 pa= cket.
>>>>>>>>
>>>>>>>>    An SR domain ingress router e= ncapsulating a received IPv6 packet
>>>>>>>>    into an outer IPv6 header fol= lowed by an SRH.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Will appreciate if you can clarify that. >>>>>>>
>>>>>>>
>>>>>>> ok, two cases:
>>>>>>>
>>>>>>> 1. the SRH is inserted at the source.
>>>>>>> the source originates the packet, the ipv6 hea= der and  the SRH.
>>>>>>> The source computes L4 checksum taking into&nb= sp; account the whole
>>IPv6+SRH.
>>>>>>> Here, theres=92 nothing new  compared to = rfc2460.
>>>>>>>
>>>>>>> 2. the SRH is originated by the ingress node o= f the SR domain.
>>>>>>> This is done by encapsulating the packet into = a outer
>>>>>>> (additional) ipv6 header followed by an SRH. T= his is L3
>>>>>>> encapsulation and no L4 checksum is involved. = When the  packet
>>>>>>> leaves the SR tunnel the outer encapsulation&n= bsp; (including the SRH)
>>>>>>> is removed and the packet continues  its = journey like nothing
>happened.
>>>>>>>
>>>>>>> s.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Tal.
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Stefano Previdi (sprevidi) [mail= to:sprevidi@cisco.c= om]
>>>>>>>>> Sent: Monday, May 16, 2016 11:59 AM >>>>>>>>> To: Ole Tr=F8an; Tal Mizrahi
>>>>>>>>> Cc: draft-ietf-6man-segment-routing-header@tools.ietf.org;
>>>>>>>>> spring@ietf.org; 6man WG
>>>>>>>>> Subject: Re: [spring] L4 Checksum and<= br> >>>>>>>>> draft-ietf-6man-segment-routing- heade= r
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On May 15, 2016, at 8:06 PM, otroan@employees.org wrote:
>>>>>>>>>>
>>>>>>>>>> Tal,
>>>>>>>>>>
>>>>>>>>>>> [Apologies if this issue has b= een discussed before.]
>>>>>>>>>>>
>>>>>>>>>>> According to draft-ietf-6man-s= egment-routing-header, an =91SR
>>>>>>>>>>> Segment
>>>>>>>>> Endpoint Node=92 updates the Destinati= on IP address.
>>>>>>>>>>> Therefore, it must also update= the Layer 4 Checksum, right?
>>>>>>>>>>>
>>>>>>>>>>> I wonder if there is an upper = bound on the size of the SRH.
>>>>>>>>>>> Otherwise, the
>>>>>>>>> L4 Checksum may be located in a pretty= deep location.
>>>>>>>>>>> Speaking from a chip vendor=92= s perspective this may be a problem.
>>>>>>>>>>
>>>>>>>>>> From RFC2460, RH0:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>   o  If the IPv6 pa= cket contains a Routing header, the Destination
>>>>>>>>>>      Address used i= n the pseudo-header is that of the final
>>>>>>>>>>      destination.&n= bsp; At the originating node, that address will be in
>>>>>>>>>>      the last eleme= nt of the Routing header; at the recipient(s),
>>>>>>>>>>      that address w= ill be in the Destination Address field of the
>>>>>>>>>>      IPv6 header. >>>>>>>>>>
>>>>>>>>>> I would expect SR would work the s= ame.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> exactly.
>>>>>>>>>
>>>>>>>>> Moreover, draft-ietf-6man-segment-rout= ing-header assumes
>>>>>>>>> encapsulation so clearly there=92s no = L4 involved here.
>>>>>>>>>
>>>>>>>>> s.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Ole
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>> ----------------------------------------------------------= ----------
>>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> ----------------------------------------------------------= ----------
>
>_______________________________________________
>nvo3 mailing list
>nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3

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

 

 


 --_000_D368BC0419BA29kreegerciscocom_-- From nobody Tue May 24 14:09:06 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C71312D1EA; Tue, 24 May 2016 14:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SG1HbE_uIsIx; Tue, 24 May 2016 14:08:59 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0104.outbound.protection.outlook.com [207.46.100.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3444112D13D; Tue, 24 May 2016 14:08:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6djPsqTyaLl6Iq1NCwN9AwITj8OW9K5fJZ15SOmyXsY=; b=hgLWalueJ94MRp6nMvpnOHudssH1G0oFcGxyT3aOJRm33UaaP05uhxTfHPGjOc6VgS/iqYrTkEfS4fCqJCLKHTBj7gl2p3jcrr2pokQs9GLB2LGQHqnjE//SziG/X0nfjTTsM6LufeCPqADM+6sXpgfwsiOlb+24vot3W2M796E= Received: from SN1PR0501MB1709.namprd05.prod.outlook.com (10.163.130.155) by SN1PR0501MB1711.namprd05.prod.outlook.com (10.163.130.157) with Microsoft SMTP Server (TLS) id 15.1.501.7; Tue, 24 May 2016 21:08:58 +0000 Received: from SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) by SN1PR0501MB1709.namprd05.prod.outlook.com ([10.163.130.155]) with mapi id 15.01.0501.013; Tue, 24 May 2016 21:08:57 +0000 From: John E Drake To: Robert Raszuk , Adrian Farrel Thread-Topic: [spring] [Idr] New draft for data center gateways Thread-Index: AdG1GnjM0FP4vAcnRKiZoSNePCQ+mQABH+CAAAQtdQAAMre9gA== Date: Tue, 24 May 2016 21:08:57 +0000 Message-ID: References: <01ea01d1b51a$7cf31e60$76d95b20$@olddog.co.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: raszuk.net; dkim=none (message not signed) header.d=none;raszuk.net; dmarc=none action=none header.from=juniper.net; x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: 5f049879-7ad1-4dac-da47-08d384179f30 x-microsoft-exchange-diagnostics: 1; SN1PR0501MB1711; 5:xVA+hysUdUNqtpzZQCRgqvBtPw6LN2h50L25Y3LlRfVccIeKlX4dJ7ljSxWVnqJnEkWDBz8aHJ4Ni/HgN4pJWNGxPu5oxjPIkMDwxj21O2EBLMAZToSk7TPiWICyEWnsWCR7mcvtEm4gwnq9db8ksA==; 24:QhGdqWehIJx5mITr1BWWeFdqLhNnITpVhBFw3nPCZZCs8rKtl3sPIJTBYzKjzIFKY24Zypo+8UwZjJB7Ei6xppvMsENXwxeo9qBRdlcuSAg=; 7:ztNjjJLMkdYspHIhQY1RNDIeCJcCuudctBvn2hVKwzMxhcRG4ZEbNmq52pZ3/h0Wq0AvjFJ6KJ832Saug1KRzcpowVLk76FAfl6pkg6ZoRbGFQezJ+fMkpnIQgER/PKpNfSOJFpqhyvkMj5oRgEF6A7r2MqKs8Ib6Qu1uVzBOeRH0MFKrS00vi81BYFqC0ce x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1711; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:SN1PR0501MB1711; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1711; x-forefront-prvs: 09525C61DB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(5008740100001)(16236675004)(66066001)(2950100001)(5001770100001)(2900100001)(86362001)(15975445007)(77096005)(4326007)(19609705001)(3660700001)(2906002)(19580405001)(189998001)(3280700002)(3846002)(76576001)(19625215002)(19580395003)(586003)(92566002)(9686002)(87936001)(1220700001)(790700001)(19300405004)(102836003)(6116002)(122556002)(5004730100002)(5003600100002)(19617315012)(81166006)(5002640100001)(99286002)(10400500002)(50986999)(54356999)(76176999)(8936002)(74316001)(33656002)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1711; H:SN1PR0501MB1709.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0501MB1709C670BFB005BDB241845DC74F0SN1PR0501MB1709_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 24 May 2016 21:08:57.7233 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1711 Archived-At: Cc: idr wg , "spring@ietf.org" Subject: Re: [spring] [Idr] New draft for data center gateways X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 21:09:01 -0000 --_000_SN1PR0501MB1709C670BFB005BDB241845DC74F0SN1PR0501MB1709_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9iZXJ0LA0KDQpDb21tZW50cyBpbmxpbmUNCg0KWW91cnMgSXJyZXNwZWN0aXZlbHksDQoNCkpv aG4NCg0KRnJvbTogc3ByaW5nIFttYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZiBSb2JlcnQgUmFzenVrDQpTZW50OiBNb25kYXksIE1heSAyMywgMjAxNiA0OjE0IFBN DQpUbzogQWRyaWFuIEZhcnJlbA0KQ2M6IGlkciB3Zzsgc3ByaW5nQGlldGYub3JnDQpTdWJqZWN0 OiBSZTogW3NwcmluZ10gW0lkcl0gTmV3IGRyYWZ0IGZvciBkYXRhIGNlbnRlciBnYXRld2F5cw0K DQpEZWFyIEF1dGhvcnMsDQoNClF1ZXN0aW9uIDE6DQoNCkFzc3VtZSB0aGF0IHByZWZpeCBYIGhh cyBiZWVuIGFkdmVydGlzZWQgd2l0aCB0dW5uZWwgYXR0cmlidXRlIGFzIGRlc2NyaWJlZCBpbiB0 aGUgZHJhZnQgd2l0aCBib3RoIEdXMSBhbmQgR1cyIGVudHJ5IHBvaW50cyB0byBFZ3Jlc3MgREMg c2l0ZS4NCg0KU28gcmVtb3RlIEdXIGluIEluZ3Jlc3MgREMgc2l0ZSByZWNlaXZlcyBhdCBsZWFz dCBvbmUgc3VjaCBhZHZlcnRpc2VtZW50IGFuZCBhcyBlYWNoIGNvbnRhaW5zIGJvdGggR1cxIGFu ZCBHVzIgZW50cmllcyBpdCBjYW4gZW5naW5lZXIgZmxvd3MgdG8gdGhvc2UuDQoNClNvIGZhciBz byBnb29kIC4uLiBidXQgd2hhdCBoYXBwZW5zIHdoZW4gbGluayBiZXR3ZWVuIFBFIChvbiBsZWZ0 IHNpZGUpIGFuZCBHVzEgZ29lcyBkb3duID8NCg0KQkdQIHdpbGwgYWZ0ZXIgc29tZSB0aW1lIHJl bW92ZSB0aGF0IHBhdGggdmlhIGFsbCBBU2VzLCBidXQgR1cyIHdpbGwga2VlcCBhZHZlcnRzaW5n IHByZWZpeCBYIGFzIHN0aWxsIHJlYWNoYWJsZSB2aWEgYm90aCBHVzEgYW5kIEdXMiB3aXRoaW4g dHVubmVsIGVuY2Fwc3VsYXRpb24gYXR0cmlidXRlIGFzIGZyb20gaGlzIHBlcnNwZWN0aXZlIG5v dGhpbmcgd2lsbCBiZSB3cm9uZy4NCg0KSG93IHJlbW90ZSBHVyBpbiBJbmdyZXNzIERDIHNpdGUg aXMgbm93IHN1cHBvc2VkIHRvIGtub3cgdGhhdCBHVzEgbGluayB0byBQRSBpbiBBUzIgd2VudCBk b3duIGFuZCBzdG9wIHB1c2hpbmcgdHJhZmZpYyB0b3dhcmRzIGl0ID8NCg0KDQpbSkRdICBXZSB3 ZXJlIGFzc3VtaW5nIHRoYXQgYSkgR1cvYmFja2JvbmUgbGlua3Mgd291bGQgYmUgYWR2ZXJ0aXNl ZCBpbiBCR1AgTFMgKG9wdGlvbmFsbHkgdy8gRVBFKSBhbmQgYikgYSBHVyB0aGF0IGlzIGRpc2Nv bm5lY3RlZCBmcm9tIHRoZSBiYWNrYm9uZSBkb2VzIG5vdCBhZHZlcnRpc2UgYW4gYXV0by1kaXNj b3Zlcnkgcm91dGUuICBUaGlzIHdpbGwgYmUgbWFkZSBleHBsaWNpdCBpbiB0aGUgbmV4dCByZXZp c2lvbi4NCg0KDQotIC0gLQ0KDQpRdWVzdGlvbiAyOg0KDQpXaGF0IGhhcHBlbnMgaWYgYWxsIEwz IERDIENMT1MgSVAgRmFicmljcyB1c2UgZUJHUCBub3QgSUdQID8NCg0KDQpbSkRdICAgV2UgbWFr ZSBubyBhc3N1bXB0aW9ucyBhYm91dCB3aGF0IGNvbnRyb2wgcGxhbmUgaXMgdXNlZCB3aXRoaW4g YSBEQy4gIEFmdGVyIGFsbCwgdGhlIGRyYWZ0IGlzIGFib3V0IERDIOKAnGludGVyY29ubmVjdOKA nS4gIChCdHcsIGl0IHNob3VsZCBiZSBzcGVsbGVkIOKAmENsb3PigJkgc2luY2UgaXTigJlzIGEg cGVyc29u4oCZcyBsYXN0IG5hbWUuKQ0KDQoNCi0gLSAtDQoNClF1ZXN0aW9uIDM6DQoNCklzIHBl ciBwcmVmaXggdHVubmVsIGF0dHJpYnV0ZSB3aGVyZSBzYXkgLzMyIHJvdXRlcyBtYXkgYmUgZXhj aGFuZ2VzIGZsYXQgKHJlZiBjYWxpY28gYXBwcm9hY2ggLSBodHRwczovL3d3dy5wcm9qZWN0Y2Fs aWNvLm9yZy8pIHJlYWxseSBhIHNjYWxhYmxlIHNvbHV0aW9uID8NCg0KDQpbSkRdICAgQXJlIHlv dSBzaW1wbHkgcmVwZWF0aW5nIHRoZSBvcGluaW9uIHlvdSBleHByZXNzZWQgd2hlbiB0aGUgdHVu bmVsLWVuY2FwcyBkcmFmdCBmaXJzdCBjYW1lIG91dCwgb3IgZG8geW91IGhhdmUgYSBzY2FsYWJp bGl0eSBjb25jZXJuIHRoYXQgaGFzbid0IGFscmVhZHkgYmVlbiBkaXNjdXNzZWQ/DQoNCg0KQmVz dCwNClJvYmVydC4NCg0KUFMuIEp1c3QgcHVyZWx5IGFzIGluZm9ybWF0aW9uIHlvdXIgaW50ZXIg REMgdHJhZmZpYyBzdGVlcmluZyBwcm9ibGVtIGRlc2NyaXB0aW9uIGlzIGVhc2lseSBzb2x2ZWQg YWxyZWFkeSB0b2RheSB3aXRoIG9uZSBsZXZlbCBvZiBpbmRpcmVjdGlvbiAtIEV4YW1wbGU6IExJ U1AuIE5vdCBzdXJlIGlmIHdlIG5lZWQgYWRkaXRpb25hbCBmbGF0IHByb3RvY29sIGV4dGVuc2lv bnMgaGVyZS4NCg0KDQoNCg== --_000_SN1PR0501MB1709C670BFB005BDB241845DC74F0SN1PR0501MB1709_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Um9iZXJ0 LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Q29tbWVudHMgaW5s aW5lPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Zb3VycyBJcnJl c3BlY3RpdmVseSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkpv aG48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiBzcHJpbmcgW21haWx0bzpzcHJpbmctYm91bmNlc0BpZXRmLm9yZ10NCjxi Pk9uIEJlaGFsZiBPZiA8L2I+Um9iZXJ0IFJhc3p1azxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXks IE1heSAyMywgMjAxNiA0OjE0IFBNPGJyPg0KPGI+VG86PC9iPiBBZHJpYW4gRmFycmVsPGJyPg0K PGI+Q2M6PC9iPiBpZHIgd2c7IHNwcmluZ0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW3NwcmluZ10gW0lkcl0gTmV3IGRyYWZ0IGZvciBkYXRhIGNlbnRlciBnYXRld2F5czxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkRl YXIgQXV0aG9ycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPlF1ZXN0aW9uIDE6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Bc3N1bWUgdGhhdCBwcmVmaXgg WCBoYXMgYmVlbiBhZHZlcnRpc2VkIHdpdGggdHVubmVsIGF0dHJpYnV0ZSBhcyBkZXNjcmliZWQg aW4gdGhlIGRyYWZ0IHdpdGggYm90aCBHVzEgYW5kIEdXMiBlbnRyeSBwb2ludHMgdG8gRWdyZXNz IERDIHNpdGUuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj5TbyByZW1vdGUgR1cgaW4gSW5ncmVzcyBEQyBzaXRlIHJl Y2VpdmVzIGF0IGxlYXN0IG9uZSBzdWNoIGFkdmVydGlzZW1lbnQgYW5kIGFzIGVhY2ggY29udGFp bnMgYm90aCBHVzEgYW5kIEdXMiBlbnRyaWVzIGl0IGNhbiBlbmdpbmVlciBmbG93cyB0byB0aG9z ZS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPlNvIGZhciBzbyBnb29kIC4uLiBidXQgd2hhdCBoYXBwZW5zIHdoZW4g bGluayBiZXR3ZWVuIFBFIChvbiBsZWZ0IHNpZGUpIGFuZCBHVzEgZ29lcyBkb3duID8mbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPkJHUCB3aWxsIGFmdGVyIHNvbWUgdGltZSByZW1vdmUgdGhhdCBwYXRoIHZpYSBhbGwg QVNlcywgYnV0IEdXMiB3aWxsIGtlZXAgYWR2ZXJ0c2luZyBwcmVmaXggWCBhcyBzdGlsbCByZWFj aGFibGUgdmlhIGJvdGggR1cxIGFuZCBHVzIgd2l0aGluIHR1bm5lbCBlbmNhcHN1bGF0aW9uIGF0 dHJpYnV0ZSBhcyBmcm9tIGhpcyBwZXJzcGVjdGl2ZQ0KIG5vdGhpbmcgd2lsbCBiZSB3cm9uZy4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPkhvdyByZW1vdGUgR1cgaW4gSW5ncmVzcyBEQyBzaXRlIGlzIG5vdyBzdXBw b3NlZCB0byBrbm93IHRoYXQgR1cxIGxpbmsgdG8gUEUgaW4gQVMyIHdlbnQgZG93biBhbmQgc3Rv cCBwdXNoaW5nIHRyYWZmaWMgdG93YXJkcyBpdCA/Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMjVwdCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMjVwdCI+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltKRF0mbmJzcDsgV2Ugd2VyZSBhc3N1bWluZyB0aGF0IGEp IEdXL2JhY2tib25lIGxpbmtzIHdvdWxkIGJlIGFkdmVydGlzZWQgaW4gQkdQIExTIChvcHRpb25h bGx5IHcvIEVQRSkgYW5kIGIpIGEgR1cgdGhhdCBpcyBkaXNjb25uZWN0ZWQNCiBmcm9tIHRoZSBi YWNrYm9uZSBkb2VzIG5vdCBhZHZlcnRpc2UgYW4gYXV0by1kaXNjb3Zlcnkgcm91dGUuJm5ic3A7 IFRoaXMgd2lsbCBiZSBtYWRlIGV4cGxpY2l0IGluIHRoZSBuZXh0IHJldmlzaW9uLiAmbmJzcDs8 bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDo1LjI1cHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjI1cHQiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj4tIC0gLSZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+UXVlc3Rpb24gMjom bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LHNhbnMtc2VyaWYiPldoYXQgaGFwcGVucyBpZiBhbGwgTDMgREMgQ0xPUyBJUCBGYWJyaWNzIHVz ZSBlQkdQIG5vdCBJR1AgPyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+ PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj5bSkRdJm5ic3A7Jm5ic3A7IFdlIG1ha2Ugbm8gYXNzdW1wdGlvbnMgYWJvdXQg d2hhdCBjb250cm9sIHBsYW5lIGlzIHVzZWQgd2l0aGluIGEgREMuJm5ic3A7IEFmdGVyIGFsbCwg dGhlIGRyYWZ0IGlzIGFib3V0IERDIOKAnGludGVyY29ubmVjdOKAnS4mbmJzcDsgKEJ0dywgaXQg c2hvdWxkIGJlIHNwZWxsZWQNCiDigJhDbG9z4oCZIHNpbmNlIGl04oCZcyBhIHBlcnNvbuKAmXMg bGFzdCBuYW1lLik8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPi0gLSAt Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmIj5RdWVzdGlvbiAzOiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SXMgcGVyIHByZWZpeCB0dW5u ZWwgYXR0cmlidXRlIHdoZXJlIHNheSAvMzIgcm91dGVzIG1heSBiZSBleGNoYW5nZXMgZmxhdCAo cmVmIGNhbGljbyBhcHByb2FjaCAtDQo8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cucHJvamVj dGNhbGljby5vcmcvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+aHR0cHM6Ly93d3cucHJvamVjdGNhbGljby5vcmcvPC9zcGFuPjwvYT48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+KSByZWFs bHkgYSBzY2FsYWJsZSBzb2x1dGlvbiA/Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PltKRF0mbmJzcDsmbmJzcDsgQXJlIHlvdSBzaW1wbHkgcmVwZWF0aW5nIHRoZSBvcGluaW9uIHlv dSBleHByZXNzZWQgd2hlbiB0aGUgdHVubmVsLWVuY2FwcyBkcmFmdCBmaXJzdCBjYW1lIG91dCwg b3IgZG8geW91IGhhdmUgYSBzY2FsYWJpbGl0eSBjb25jZXJuIHRoYXQgaGFzbid0DQogYWxyZWFk eSBiZWVuIGRpc2N1c3NlZD88L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5CZXN0 LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5Sb2JlcnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OyxzYW5zLXNlcmlmIj5QUy4gSnVzdCBwdXJlbHkgYXMgaW5mb3JtYXRpb24geW91ciBpbnRl ciBEQyB0cmFmZmljIHN0ZWVyaW5nIHByb2JsZW0gZGVzY3JpcHRpb24gaXMgZWFzaWx5IHNvbHZl ZCBhbHJlYWR5IHRvZGF5IHdpdGggb25lIGxldmVsIG9mIGluZGlyZWN0aW9uIC0gRXhhbXBsZTog TElTUC4gTm90IHN1cmUgaWYgd2UgbmVlZCBhZGRpdGlvbmFsDQogZmxhdCBwcm90b2NvbCBleHRl bnNpb25zIGhlcmUuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_SN1PR0501MB1709C670BFB005BDB241845DC74F0SN1PR0501MB1709_-- From nobody Tue May 24 14:27:50 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B21C12D1D3; Tue, 24 May 2016 14:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGSxdJg8-r9r; Tue, 24 May 2016 14:27:47 -0700 (PDT) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 CF26612B056; Tue, 24 May 2016 14:27:46 -0700 (PDT) Received: by mail-lf0-x22b.google.com with SMTP id e130so11057456lfe.3; Tue, 24 May 2016 14:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=+wH+dW75cWZOaEtx7iA+VUmuhENNtnwYfRf2hUzJQ2g=; b=rpUBiUycCK4gxoTEQZtUvLiAjGw7kEzsDnPPPKvUsMXF8XiU2zUkTNe/wuKDxUAPq/ uY9wHUVVm2FvNa+N/A8xLoJR4a6u8luMRqD8UEvFzcMnZ13uyQk0xmP5lEsbcSKe8uDM Xp8UbULh2y9KLejFhbbc28y4AtzVcTQd54jBJrJa1HFm5ev+HBBJ74R6fY9zyTTuoXQ+ Pwk8fsfkpUWOJ+HmrCiyda6vvuv+sc7wN5lovEsC/aTwOppVCazQkqIheYnvvg5+VNUr 9FhdZMGfKVhw2nOzKY1K/CcILHaqBQt2kxQeqnfgACEnbf3/v3nIzUUbSijs2JmKzJaq 8CQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=+wH+dW75cWZOaEtx7iA+VUmuhENNtnwYfRf2hUzJQ2g=; b=S6IaMwheKzTzJAgUuX59ip/6/yrBPPNUonR3ldeVI7bzeo+acsS5qfJW5SuyjwdZ7s /paXhsAVn5TAbbEN8xs6oRfSa0BuKGlblVB4HHtatFkhJ6Uj9hAngpMIEY327ZtAv+WM musAYGPakzzUIIF7ni0baGqGo9hC7EM4FYWd8fV2X6vpDeALdXvyQlY8cki2fcwlRDtN k9qQKseUoRsmtB6JVftUWt4wMhAnVb0sBignurQAcK8mEg28k160n6Mb4QgkZMGIIsKw UCUa2vX8KFoe0f+bxWH/M6DpT30sYsnC2c/HTzbtgR3dyf1mBQa4npKzj0ScUlY/Wm8l 2UlA== X-Gm-Message-State: ALyK8tL0kAzJpkERaIV2iE3ApFU1LTd2atufvTyOMK4pjj+4SVPFRwhNvMZvRXo1WqPbAe7ChD3ab+1ufx8kIQ== MIME-Version: 1.0 X-Received: by 10.25.16.219 with SMTP id 88mr59684lfq.21.1464125264904; Tue, 24 May 2016 14:27:44 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.134.196 with HTTP; Tue, 24 May 2016 14:27:44 -0700 (PDT) In-Reply-To: References: <01ea01d1b51a$7cf31e60$76d95b20$@olddog.co.uk> Date: Tue, 24 May 2016 23:27:44 +0200 X-Google-Sender-Auth: CSYEoyOCmzv9GZdQ9zY_2GE8CCs Message-ID: From: Robert Raszuk To: John E Drake Content-Type: multipart/alternative; boundary=001a11402d9c524b2305339d3ad3 Archived-At: Cc: Adrian Farrel , "spring@ietf.org" , idr wg Subject: Re: [spring] [Idr] New draft for data center gateways X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 21:27:48 -0000 --001a11402d9c524b2305339d3ad3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi John, *[JD] We were assuming that a) GW/backbone links would be advertised in > BGP LS (optionally w/ EPE) and b) a GW that is disconnected from the > backbone does not advertise an auto-discovery route. This will be made > explicit in the next revision. * > =E2=80=8BAd a) - EPE works fine with next hop self on the ASBRs of the bacb= one. So if your proposal requires external links to be passive in the backbone IGP then the draft needs to state it well. Besides it may not be sufficient if more then one backbone instance is used to interconnect DCs. Ad b) - The current set of procedures described in section 2 for constructing auto discovery routes is not sufficient. GW may be interconnected to more then one backbone each serving different set of prefixes within each DC (you call it X). So much more would need to go into the auto-discovery to make this work in practice. And even if you would go that way it will be slow to re-advertise all prefixes with different tunnel attribute content. *[JD] Are you simply repeating the opinion you expressed when the > tunnel-encaps draft first came out, or do you have a scalability concern > that hasn't already been discussed?* > > =E2=80=8BI am expressing the observation that tunnel-encaps may work well t= o pass static information or information which may change by configiration. Here you are using it to pass remote reachability info embedded into it. I find it far from optimal which as combined with possible DC prefix scale is likely to cause more issues then benefits. That's why I suggest use of indirection layer to solve this overall problem. As mentioned one could be LISP or any other SD-WAN solutions. Thx, R. --001a11402d9c524b2305339d3ad3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi John,

[J= D]=C2=A0 We were assuming that a) GW/backbone links would be advertised in = BGP LS (optionally w/ EPE) and b) a GW that is disconnected from the backbone does not advertise an auto-discovery route.=C2=A0 This w= ill be made explicit in the next revision. =C2=A0

=

=E2=80=8BAd a) - EPE works fine with next hop self on the ASBRs of= the bacbone. So if your proposal requires external links to be passive in = the backbone IGP then the draft needs to state it well. Besides it may not = be sufficient if more then one backbone instance is used to interconnect DC= s.=C2=A0

Ad b) - The c= urrent set of procedures described in section 2 for constructing auto disco= very routes is not sufficient. GW may be interconnected to more then one ba= ckbone each serving different set of prefixes within each DC (you call it X= ). So much more would need to go into the auto-discovery to make this work = in practice. And even if you would go that way it will be slow to re-advert= ise all prefixes with different tunnel attribute content.=C2=A0
=

[JD]=C2=A0=C2=A0 Are you simply= repeating the opinion you expressed when the tunnel-encaps draft first cam= e out, or do you have a scalability concern that hasn't already been discussed?=

<= /blockquote>

=E2=80=8BI am expressing the observation that tunnel-encaps may= work well to pass static information or information which may change by co= nfigiration.=C2=A0

Here you are using it to pass remote reachability info embedd= ed into it. I find it far from optimal which as combined with possible DC p= refix scale is likely to cause more issues then benefits.=C2=A0

That's why I suggest use of i= ndirection layer to solve this overall problem. As mentioned one could be L= ISP or any other SD-WAN solutions.=C2=A0

=
Thx,
R.

--001a11402d9c524b2305339d3ad3-- From nobody Tue May 24 14:59:10 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 157DC12D817; Tue, 24 May 2016 14:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaBAYkm4IL85; Tue, 24 May 2016 14:59:06 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24FBA12D9D5; Tue, 24 May 2016 14:59:06 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id k98so11305826lfi.1; Tue, 24 May 2016 14:59:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=GKn8aaixS6J6nllQucGsIHvgSMJjxgFU9c5Hxw3BZVo=; b=0KeQL2MRbNL6IcVAP8IxEp8lXFMpsFBarVu7NhK89TVW9fp+PQtNH+Xcw6NRaVHhNB 6/REbpdm2bWWXdqwxa5Rc46rTQJ+EEXeBCDzq1QnKjJJZIk8+7u2wG+VjnV66hYw20sl bYUfaoCm9k1SNhPgyVVc0RBHrgBcWrLbHqUX6cEXM/FwjABRQ73H4jLMLISWNkHmXsTT 1KAKUigZX44MZQIH4Iymk3v4AwaKHMce2QXG3WWnpJxtWCXCP9XPabJ7rB3vfzbl8ACm 2IoBB9f4owSkrawxB56ImdVSEGMfYq3GfoVageDXpTvIsJ/iUxQw4WEi+1pa+0ED93EG jUSg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=GKn8aaixS6J6nllQucGsIHvgSMJjxgFU9c5Hxw3BZVo=; b=EJQsL3gnbXeO686y1CY0DKLh6lUnVmMabPns38gxd1ZWJo18Z8+pXBMMtlTh8s4Iol CqN8YuXQDfZIimqAQuunvK4/8qgcwlp/rLlDUh5Xzy6NUlnyZr/8h1kVCH3jz28Gqh1u ZDkQqZUMNy6k1MhyRFNxcoVZnJedDIdynXhwAwWSSjRly9sQbfluJNCSeDgyfVLyoDVR laFGdda6ekZ5s2nFsBozy6bW29ABlXyVlRL684VRzdYSrP1KIdJSMRJT9d67tEP0E8fK k1s/1CbjnIgtZq9VWly5kmwQdVLYlkjP/9kLwTYBzc1dsEuRLuDS+qxsVYljMuiwsF4S oBDw== X-Gm-Message-State: ALyK8tKFaJcnRCXxxBpCtd0yIpYuDldY7qkC7ErNWtVJT4aglf+W0D/Bin3odfWul7XGDKU53FcUllxoeo+xSw== MIME-Version: 1.0 X-Received: by 10.25.33.133 with SMTP id h127mr78927lfh.82.1464127144268; Tue, 24 May 2016 14:59:04 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.134.196 with HTTP; Tue, 24 May 2016 14:59:04 -0700 (PDT) In-Reply-To: References: <01ea01d1b51a$7cf31e60$76d95b20$@olddog.co.uk> Date: Tue, 24 May 2016 23:59:04 +0200 X-Google-Sender-Auth: g6oeAjEeJDQmqDS7VcF-hKapOqo Message-ID: From: Robert Raszuk To: John E Drake Content-Type: multipart/alternative; boundary=001a113f1888571bf205339daac7 Archived-At: Cc: Adrian Farrel , "spring@ietf.org" , idr wg Subject: Re: [spring] [Idr] New draft for data center gateways X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2016 21:59:08 -0000 --001a113f1888571bf205339daac7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable John, Adrian & Eric, Btw .. indirection I am suggesting may not only be realized by choice of a new overlay system. Alternative design would be to only encode a given's DC "COLOR" or "ID" into the tunnel encapsulation attribute which would not change for each X then to establish full mesh EBGP multihop sessions between interesting GWs with each again carrying the tunnel attribute with same set of "IDs" or "COLORS" as would do atomic prefixes. - If such full eBGP mesh would be getting large use of stock BGP Route Server may be used at any DC or in the backbone. - Over such sessions single prefixes would be exchanged - something what you refer to auto discovery routes in current document but those would be only send over EBGP not IBGP. - This would also remove any need to run intra-DC auto discovery. - The connectivity restoration time would be significantly reduced as multihop BFD may be used (directly or to RS). The above described proposal changes your current architecture however I believe it significantly simplifies things, removes the concern of scale and simplifies or even eliminates any new development needed to deploy it today provided that given's vendor policy already allows to match routes with specific attribute payload. Cheers, R. PS. If this game is under same administration (which I think it is based on the requirements) then to mark the routes use of standard or extended community can be used instead of tunnel encapsulation attribute. On Tue, May 24, 2016 at 11:27 PM, Robert Raszuk wrote: > Hi John, > > *[JD] We were assuming that a) GW/backbone links would be advertised in >> BGP LS (optionally w/ EPE) and b) a GW that is disconnected from the >> backbone does not advertise an auto-discovery route. This will be made >> explicit in the next revision. * >> > > =E2=80=8BAd a) - EPE works fine with next hop self on the ASBRs of the ba= cbone. So > if your proposal requires external links to be passive in the backbone IG= P > then the draft needs to state it well. Besides it may not be sufficient i= f > more then one backbone instance is used to interconnect DCs. > > Ad b) - The current set of procedures described in section 2 for > constructing auto discovery routes is not sufficient. GW may be > interconnected to more then one backbone each serving different set of > prefixes within each DC (you call it X). So much more would need to go in= to > the auto-discovery to make this work in practice. And even if you would g= o > that way it will be slow to re-advertise all prefixes with different tunn= el > attribute content. > > *[JD] Are you simply repeating the opinion you expressed when the >> tunnel-encaps draft first came out, or do you have a scalability concern >> that hasn't already been discussed?* >> >> > =E2=80=8BI am expressing the observation that tunnel-encaps may work well= to pass > static information or information which may change by configiration. > > Here you are using it to pass remote reachability info embedded into it. = I > find it far from optimal which as combined with possible DC prefix scale = is > likely to cause more issues then benefits. > > That's why I suggest use of indirection layer to solve this overall > problem. As mentioned one could be LISP or any other SD-WAN solutions. > > Thx, > R. > > --001a113f1888571bf205339daac7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
John, Adrian & Eric,

Btw .. indirection I am suggesting m= ay not only be realized by choice of a new overlay system.=C2=A0

Alternative design would be to o= nly encode a given's DC "COLOR" or "ID" into the tu= nnel encapsulation attribute which would not change for each X then to esta= blish full mesh EBGP multihop sessions between interesting GWs with each ag= ain carrying the tunnel attribute with same set of "IDs" or "= ;COLORS" as would do atomic prefixes.=C2=A0
- If such full eBGP mesh would be getting large = use of stock BGP Route Server may be used at any DC or in the backbone.=C2= =A0

- Over such sessio= ns single prefixes would be exchanged - something what you refer to auto di= scovery routes in current document but those would be only send over EBGP n= ot IBGP.=C2=A0

- This = would also remove any need to run intra-DC auto discovery.=C2=A0

- The connectivity restoration t= ime would be significantly reduced as multihop BFD may be used (directly or= to RS).


The above described proposal changes your current architect= ure however I believe it significantly simplifies things, removes the conce= rn of scale and simplifies or even eliminates any new development needed to= deploy it today provided that given's vendor policy already allows to = match routes with specific attribute payload.
<= br>
Cheers,
R.

PS. If this game is under same= administration (which I think it is based on the requirements) then to mar= k the routes use of standard or extended community can be used instead of t= unnel encapsulation attribute.=C2=A0









On Tue, = May 24, 2016 at 11:27 PM, Robert Raszuk <robert@raszuk.net> = wrote:
Hi John,

[J= D]=C2=A0 We were assuming that a) GW/backbone links would be advertised in = BGP LS (optionally w/ EPE) and b) a GW that is disconnected from the backbone does not advertise an auto-discovery route.=C2=A0 This w= ill be made explicit in the next revision. =C2=A0

=

=E2=80=8BAd a) - EPE works fine with next hop self on the ASB= Rs of the bacbone. So if your proposal requires external links to be passiv= e in the backbone IGP then the draft needs to state it well. Besides it may= not be sufficient if more then one backbone instance is used to interconne= ct DCs.=C2=A0

Ad b) - = The current set of procedures described in section 2 for constructing auto = discovery routes is not sufficient. GW may be interconnected to more then o= ne backbone each serving different set of prefixes within each DC (you call= it X). So much more would need to go into the auto-discovery to make this = work in practice. And even if you would go that way it will be slow to re-a= dvertise all prefixes with different tunnel attribute content.=C2=A0
<= /div>

[JD]=C2=A0=C2=A0 Are you simply= repeating the opinion you expressed when the tunnel-encaps draft first cam= e out, or do you have a scalability concern that hasn't already been discussed?=

<= /blockquote>

=E2=80=8BI am expressing the observation that tunnel-enc= aps may work well to pass static information or information which may chang= e by configiration.=C2=A0

Here you are using it to pass remote reachability info = embedded into it. I find it far from optimal which as combined with possibl= e DC prefix scale is likely to cause more issues then benefits.=C2=A0
=

That's why I suggest us= e of indirection layer to solve this overall problem. As mentioned one coul= d be LISP or any other SD-WAN solutions.=C2=A0

=
Thx,
R.


--001a113f1888571bf205339daac7-- From nobody Wed May 25 16:49:32 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F32CD12DE3E; Wed, 25 May 2016 16:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.328 X-Spam-Level: X-Spam-Status: No, score=-108.328 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 k1vZj4oUnIKv; Wed, 25 May 2016 16:49:14 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EB2F12DE4D; Wed, 25 May 2016 16:49:07 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 943B3180006; Wed, 25 May 2016 16:48:31 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20160525234831.943B3180006@rfc-editor.org> Date: Wed, 25 May 2016 16:48:31 -0700 (PDT) Archived-At: Cc: spring@ietf.org, rfc-editor@rfc-editor.org Subject: [spring] RFC 7855 on Source Packet Routing in Networking (SPRING) Problem Statement and Requirements X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2016 23:49:23 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7855 Title: Source Packet Routing in Networking (SPRING) Problem Statement and Requirements Author: S. Previdi, Ed., C. Filsfils, Ed., B. Decraene, S. Litkowski, M. Horneffer, R. Shakir Status: Informational Stream: IETF Date: May 2016 Mailbox: sprevidi@cisco.com, cfilsfil@cisco.com, bruno.decraene@orange.com, stephane.litkowski@orange.com, Martin.Horneffer@telekom.de, rjs@rob.sh Pages: 19 Characters: 38006 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-spring-problem-statement-08.txt URL: https://www.rfc-editor.org/info/rfc7855 DOI: http://dx.doi.org/10.17487/RFC7855 The ability for a node to specify a forwarding path, other than the normal shortest path, that a particular packet will traverse, benefits a number of network functions. Source-based routing mechanisms have previously been specified for network protocols but have not seen widespread adoption. In this context, the term "source" means "the point at which the explicit route is imposed"; therefore, it is not limited to the originator of the packet (i.e., the node imposing the explicit route may be the ingress node of an operator's network). This document outlines various use cases, with their requirements, that need to be taken into account by the Source Packet Routing in Networking (SPRING) architecture for unicast traffic. Multicast use cases and requirements are out of scope for this document. This document is a product of the Source Packet Routing in Networking Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Thu May 26 03:03:06 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3750312D932 for ; Thu, 26 May 2016 03:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GapdWQic8flv for ; Thu, 26 May 2016 03:03:02 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C18512D91B for ; Thu, 26 May 2016 03:03:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4542; q=dns/txt; s=iport; t=1464256981; x=1465466581; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=9ruHw5vgDTRDotnBk5F3yYspGueyEZELBPJ7CbgzAu0=; b=dwlE7PC5iYlV5PNHAmgg8IkQV6rIFRG9K+PJSH0ut2N8KVlkmq4nODi5 j+/3N6wNHPetuILK8a1lDnfvDFuNIo+ljSIQnEWg86eJFf3zH8fR7AL11 sm+J1LaaVyOVlczglF2P1m3mXev1NAT+S+7b6funu9r/W2wdIXW6FS6nF o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvAgBtyUZX/4cNJK1cgzlWfQa5dgENg?= =?us-ascii?q?XgXC4UlSgIcgRU4FAEBAQEBAQFlJ4RDAQEBAwEBAQEgERogEAsCAQgSAgQCAgg?= =?us-ascii?q?JDgcCAgIlCgEVAg4CBBMUBwIEiAYIDrE+kUMBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEcgQGFJoF2CIJOgTmCYgUfP4JCK4IuBZg3AYV/iCAKjxKPSwEeAQFCghMlgTV?= =?us-ascii?q?uAYhWCRcffwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,367,1459814400"; d="scan'208";a="278160831" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 26 May 2016 10:02:39 +0000 Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u4QA2d0n001945 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 26 May 2016 10:02:39 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 26 May 2016 06:02:38 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Thu, 26 May 2016 06:02:38 -0400 From: "Stefano Previdi (sprevidi)" To: SPRING WG Thread-Topic: [spring] RFC 7855 on Source Packet Routing in Networking (SPRING) Problem Statement and Requirements Thread-Index: AQHRtuBgQDomY/3NR0uXgKVISfkIVZ/LQMQA Date: Thu, 26 May 2016 10:02:38 +0000 Message-ID: References: <20160525234831.943B3180006@rfc-editor.org> In-Reply-To: <20160525234831.943B3180006@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.76.85] Content-Type: text/plain; charset="utf-8" Content-ID: <364385CA2DD011478C94ADC561F0FDC8@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] RFC 7855 on Source Packet Routing in Networking (SPRING) Problem Statement and Requirements X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2016 10:03:04 -0000 U1BSSU5H4oCZZXJzLA0KDQpUaGlzIGlzIG91ciBmaXJzdCByZmMuIA0KDQpOb3cgdGhhdCB3ZSBo YXZlIGEgcHJvYmxlbSBzdGF0ZW1lbnQgYW5kIHJlcXVpcmVtZW50cyBkb2N1bWVudHMsIHdlIGtu b3cgd2hhdCB3ZSBoYXZlIHRvIGRvIDstKQ0KDQpUaGFua3MgdG8gZXZlcnlvbmUgZm9yIHRoZSBz dXBwb3J0Lg0KDQoNClRoYW5rcy4NCnMuDQoNCg0KPiBPbiBNYXkgMjYsIDIwMTYsIGF0IDE6NDgg QU0sIHJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmcgd3JvdGU6DQo+IA0KPiBBIG5ldyBSZXF1ZXN0 IGZvciBDb21tZW50cyBpcyBub3cgYXZhaWxhYmxlIGluIG9ubGluZSBSRkMgbGlicmFyaWVzLg0K PiANCj4gDQo+ICAgICAgICBSRkMgNzg1NQ0KPiANCj4gICAgICAgIFRpdGxlOiAgICAgIFNvdXJj ZSBQYWNrZXQgUm91dGluZyBpbiBOZXR3b3JraW5nIA0KPiAgICAgICAgICAgICAgICAgICAgKFNQ UklORykgUHJvYmxlbSBTdGF0ZW1lbnQgYW5kIFJlcXVpcmVtZW50cyANCj4gICAgICAgIEF1dGhv cjogICAgIFMuIFByZXZpZGksIEVkLiwNCj4gICAgICAgICAgICAgICAgICAgIEMuIEZpbHNmaWxz LCBFZC4sDQo+ICAgICAgICAgICAgICAgICAgICBCLiBEZWNyYWVuZSwgUy4gTGl0a293c2tpLA0K PiAgICAgICAgICAgICAgICAgICAgTS4gSG9ybmVmZmVyLCBSLiBTaGFraXINCj4gICAgICAgIFN0 YXR1czogICAgIEluZm9ybWF0aW9uYWwNCj4gICAgICAgIFN0cmVhbTogICAgIElFVEYNCj4gICAg ICAgIERhdGU6ICAgICAgIE1heSAyMDE2DQo+ICAgICAgICBNYWlsYm94OiAgICBzcHJldmlkaUBj aXNjby5jb20sIA0KPiAgICAgICAgICAgICAgICAgICAgY2ZpbHNmaWxAY2lzY28uY29tLCANCj4g ICAgICAgICAgICAgICAgICAgIGJydW5vLmRlY3JhZW5lQG9yYW5nZS5jb20sIA0KPiAgICAgICAg ICAgICAgICAgICAgc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20sIA0KPiAgICAgICAgICAg ICAgICAgICAgTWFydGluLkhvcm5lZmZlckB0ZWxla29tLmRlLA0KPiAgICAgICAgICAgICAgICAg ICAgcmpzQHJvYi5zaA0KPiAgICAgICAgUGFnZXM6ICAgICAgMTkNCj4gICAgICAgIENoYXJhY3Rl cnM6IDM4MDA2DQo+ICAgICAgICBVcGRhdGVzL09ic29sZXRlcy9TZWVBbHNvOiAgIE5vbmUNCj4g DQo+ICAgICAgICBJLUQgVGFnOiAgICBkcmFmdC1pZXRmLXNwcmluZy1wcm9ibGVtLXN0YXRlbWVu dC0wOC50eHQNCj4gDQo+ICAgICAgICBVUkw6ICAgICAgICBodHRwczovL3d3dy5yZmMtZWRpdG9y Lm9yZy9pbmZvL3JmYzc4NTUNCj4gDQo+ICAgICAgICBET0k6ICAgICAgICBodHRwOi8vZHguZG9p Lm9yZy8xMC4xNzQ4Ny9SRkM3ODU1DQo+IA0KPiBUaGUgYWJpbGl0eSBmb3IgYSBub2RlIHRvIHNw ZWNpZnkgYSBmb3J3YXJkaW5nIHBhdGgsIG90aGVyIHRoYW4gdGhlDQo+IG5vcm1hbCBzaG9ydGVz dCBwYXRoLCB0aGF0IGEgcGFydGljdWxhciBwYWNrZXQgd2lsbCB0cmF2ZXJzZSwNCj4gYmVuZWZp dHMgYSBudW1iZXIgb2YgbmV0d29yayBmdW5jdGlvbnMuICBTb3VyY2UtYmFzZWQgcm91dGluZw0K PiBtZWNoYW5pc21zIGhhdmUgcHJldmlvdXNseSBiZWVuIHNwZWNpZmllZCBmb3IgbmV0d29yayBw cm90b2NvbHMgYnV0DQo+IGhhdmUgbm90IHNlZW4gd2lkZXNwcmVhZCBhZG9wdGlvbi4gIEluIHRo aXMgY29udGV4dCwgdGhlIHRlcm0NCj4gInNvdXJjZSIgbWVhbnMgInRoZSBwb2ludCBhdCB3aGlj aCB0aGUgZXhwbGljaXQgcm91dGUgaXMgaW1wb3NlZCI7DQo+IHRoZXJlZm9yZSwgaXQgaXMgbm90 IGxpbWl0ZWQgdG8gdGhlIG9yaWdpbmF0b3Igb2YgdGhlIHBhY2tldCAoaS5lLiwNCj4gdGhlIG5v ZGUgaW1wb3NpbmcgdGhlIGV4cGxpY2l0IHJvdXRlIG1heSBiZSB0aGUgaW5ncmVzcyBub2RlIG9m IGFuDQo+IG9wZXJhdG9yJ3MgbmV0d29yaykuDQo+IA0KPiBUaGlzIGRvY3VtZW50IG91dGxpbmVz IHZhcmlvdXMgdXNlIGNhc2VzLCB3aXRoIHRoZWlyIHJlcXVpcmVtZW50cywNCj4gdGhhdCBuZWVk IHRvIGJlIHRha2VuIGludG8gYWNjb3VudCBieSB0aGUgU291cmNlIFBhY2tldCBSb3V0aW5nIGlu DQo+IE5ldHdvcmtpbmcgKFNQUklORykgYXJjaGl0ZWN0dXJlIGZvciB1bmljYXN0IHRyYWZmaWMu ICBNdWx0aWNhc3QgdXNlDQo+IGNhc2VzIGFuZCByZXF1aXJlbWVudHMgYXJlIG91dCBvZiBzY29w ZSBmb3IgdGhpcyBkb2N1bWVudC4NCj4gDQo+IFRoaXMgZG9jdW1lbnQgaXMgYSBwcm9kdWN0IG9m IHRoZSBTb3VyY2UgUGFja2V0IFJvdXRpbmcgaW4gTmV0d29ya2luZyBXb3JraW5nIEdyb3VwIG9m IHRoZSBJRVRGLg0KPiANCj4gDQo+IElORk9STUFUSU9OQUw6IFRoaXMgbWVtbyBwcm92aWRlcyBp bmZvcm1hdGlvbiBmb3IgdGhlIEludGVybmV0IGNvbW11bml0eS4NCj4gSXQgZG9lcyBub3Qgc3Bl Y2lmeSBhbiBJbnRlcm5ldCBzdGFuZGFyZCBvZiBhbnkga2luZC4gRGlzdHJpYnV0aW9uIG9mDQo+ IHRoaXMgbWVtbyBpcyB1bmxpbWl0ZWQuDQo+IA0KPiBUaGlzIGFubm91bmNlbWVudCBpcyBzZW50 IHRvIHRoZSBJRVRGLUFubm91bmNlIGFuZCByZmMtZGlzdCBsaXN0cy4NCj4gVG8gc3Vic2NyaWJl IG9yIHVuc3Vic2NyaWJlLCBzZWUNCj4gIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vaWV0Zi1hbm5vdW5jZQ0KPiAgaHR0cHM6Ly9tYWlsbWFuLnJmYy1lZGl0b3Iub3JnL21h aWxtYW4vbGlzdGluZm8vcmZjLWRpc3QNCj4gDQo+IEZvciBzZWFyY2hpbmcgdGhlIFJGQyBzZXJp ZXMsIHNlZSBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9zZWFyY2gNCj4gRm9yIGRvd25sb2Fk aW5nIFJGQ3MsIHNlZSBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9yZXRyaWV2ZS9idWxrDQo+ IA0KPiBSZXF1ZXN0cyBmb3Igc3BlY2lhbCBkaXN0cmlidXRpb24gc2hvdWxkIGJlIGFkZHJlc3Nl ZCB0byBlaXRoZXIgdGhlDQo+IGF1dGhvciBvZiB0aGUgUkZDIGluIHF1ZXN0aW9uLCBvciB0byBy ZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnLiAgVW5sZXNzDQo+IHNwZWNpZmljYWxseSBub3RlZCBv dGhlcndpc2Ugb24gdGhlIFJGQyBpdHNlbGYsIGFsbCBSRkNzIGFyZSBmb3INCj4gdW5saW1pdGVk IGRpc3RyaWJ1dGlvbi4NCj4gDQo+IA0KPiBUaGUgUkZDIEVkaXRvciBUZWFtDQo+IEFzc29jaWF0 aW9uIE1hbmFnZW1lbnQgU29sdXRpb25zLCBMTEMNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+ IHNwcmluZ0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NwcmluZw0KDQo= From nobody Mon May 30 01:46:18 2016 Return-Path: X-Original-To: spring@ietf.org Delivered-To: spring@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A555B12D120; Mon, 30 May 2016 01:46:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160530084616.29287.86357.idtracker@ietfa.amsl.com> Date: Mon, 30 May 2016 01:46:16 -0700 Archived-At: Cc: aretana@cisco.com, spring@ietf.org, spring-chairs@ietf.org, bruno.decraene@orange.com Subject: [spring] spring - New Meeting Session Request for IETF 96 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2016 08:46:17 -0000 A new meeting session request has just been submitted by Bruno Decraene, a Chair of the spring working group. --------------------------------------------------------- Working Group Name: Source Packet Routing in Networking Area Name: Routing Area Session Requester: Bruno Decraene Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 90 Conflicts to Avoid: First Priority: idr isis ospf Second Priority: 6man mpls rtgwg Third Priority: pce sfc teas ccamp Special Requests: --------------------------------------------------------- From nobody Tue May 31 08:55:08 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDF7F12B03F; Tue, 31 May 2016 08:55:06 -0700 (PDT) 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 LeYVwcYQP--w; Tue, 31 May 2016 08:54:58 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (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 32ABC12B053; Tue, 31 May 2016 08:54:58 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u4VFpQiS028005; Tue, 31 May 2016 08:54:56 -0700 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0b-0016f401.pphosted.com with ESMTP id 237aumsvq1-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 31 May 2016 08:54:55 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 31 May 2016 18:54:53 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Tue, 31 May 2016 18:54:53 +0300 From: Tal Mizrahi To: "Stefano Previdi (sprevidi)" , "draft-ietf-6man-segment-routing-header@tools.ietf.org" Thread-Topic: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routing-header Thread-Index: AQHRtMThJCvw5mf6XUe954CmH3IV2Z/GIJVA///SB4CAADJs4P//1B0AgADL+gCAAAnXgIAMbgIA Date: Tue, 31 May 2016 15:54:52 +0000 Message-ID: References: <5dc56935eba94c2390120244564f9b21@IL-EXCH02.marvell.com> <0551686F-F1D2-4C34-81C8-530F1BEE1BDF@cisco.com> <5d889e7013b44b27ae1e75cf7ea2dd22@IL-EXCH02.marvell.com> <3549ABBE-9828-42D2-A056-851432487E2E@cisco.com> <1e13d2e32b2448af94bf23d5acf17740@IL-EXCH02.marvell.com> <569a4067fd1f45dd85d60e983be69b90@IL-EXCH02.marvell.com> <1c27bb3513bc48889ec310e8d143784c@IL-EXCH02.marvell.com> <36D9FCF0-382C-4669-85A5-C782636A85BB@vmware.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: multipart/alternative; boundary="_000_d5f75f2fc2dd4e72a0de3e581667b9f6ILEXCH02marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-31_09:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1605310181 Archived-At: Cc: "spring@ietf.org" , 6man WG Subject: Re: [spring] [nvo3] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 15:55:07 -0000 --_000_d5f75f2fc2dd4e72a0de3e581667b9f6ILEXCH02marvellcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Stefano, Going back to our original discussion, I believe we can conclude that the L= 4 Checksum may be interesting in two possible scenarios: 1. The SRH is generated by the host. In this case the L4 Checksum is = computed by the host based on the IP address of the last hop. 2. The SRH is generated by the ingress node of the SR domain using an= IP tunnel. Specifically, if the tunnel encapsulation includes an L4 header= (e.g., VXLAN, VXLAN-GPE, Geneve, GUE), then (again) the ingress node compu= tes the L4 Checksum based on the IP address of the last hop. In both cases intermediate routers in the SR domain do not need to update t= he Checksum, even though they update the destination IP address. It would be great if some text would be added to the draft to clarify these= observations. Cheers, Tal. From: Larry Kreeger (kreeger) [mailto:kreeger@cisco.com] Sent: Monday, May 23, 2016 11:55 PM To: Tal Mizrahi Cc: draft-ietf-nvo3-geneve@tools.ietf.org; draft-ietf-nvo3-vxlan-gpe@tools.= ietf.org; spring@ietf.org; 6man WG; nvo3@ietf.org; draft-ietf-6man-segment-= routing-header@tools.ietf.org; Stefano Previdi (sprevidi) Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routin= g-header I agree with Robert and Jesse. - Larry From: Jesse Gross > Date: Monday, May 23, 2016 at 1:19 PM To: Robert Raszuk >, Tal Mizrah= i > Cc: "draft-ietf-nvo3-geneve@tools.ietf.org" >, "draft-ietf-nvo3-vxlan-gpe@tools.ietf.org" >, "spring@ietf.= org" >, 6ma= n WG >, "nvo3@ietf.org" >, "draft-ietf-6man-segment-rout= ing-header@tools.ietf.org" >, "Stefano Previdi = (sprevidi)" > Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routin= g-header Resent-From: >, > Resent-To: Larry Kreeger >, >, > Resent-Date: Monday, May 23, 2016 at 1:20 PM I agree that I don't believe that there is anything in these drafts that pr= ecludes the use of extension headers or segment routing - IP is simply the = layer underneath that these protocols are building on. The figures are defi= nitely just examples - they also show outer Ethernet headers, which is not = a requirement. I wouldn't want to add text specifically stating that extension headers are= permissible. It seems like that could lead to similar questions in the fut= ure where one might wonder if other features of IP are allowed because one = is explicitly listed and others are not, etc. In my opinion, the drafts are= about as clear as they can be on this point. Jesse On 5/23/16, 1:09 AM, "rraszuk@gmail.com on behalf= of Robert Raszuk" on behalf o= f robert@raszuk.net> wrote: Hi Tal, > In order to avoid ambiguity, it would be great if the > authors could explicitly mention that IPv6 extension > headers are permitted. Well the drafts are complaint to RFC2119 (normative reference) so unless th= e text excludes elements with MUST/MUST NOT - everything else defined in th= e building blocks they (re)use is permitted. However as you say perhaps for clarity what could be added to those drafts = is a normative reference to IPv4 and IPv6 base RFCs. Best, R. On Mon, May 23, 2016 at 9:54 AM, Tal Mizrahi > wrote: Hi Robert, That makes sense. However, in this case the figures may be a bit confusing WRT the possible e= xistence of extension headers. This confusion is what led to the discussion= in this thread about whether segment routing is possible with VXLAN/VXLAN-= GPE/Geneve encapsulations. In order to avoid ambiguity, it would be great if the authors could explici= tly mention that IPv6 extension headers are permitted. Regards, Tal. From:rraszuk@gmail.com [mailto:rraszuk@gmail.com<= mailto:rraszuk@gmail.com>] On Behalf Of Robert Raszuk Sent: Monday, May 23, 2016 10:47 AM To: Tal Mizrahi Cc: spring@ietf.org; 6man WG; draft-ietf-nvo3-vxlan= -gpe@tools.ietf.org; nvo3@= ietf.org; draft-ietf-6man-segment-routing-header@tool= s.ietf.org; d= raft-ietf-nvo3-geneve@tools.ietf.org; Stefano Previdi (sprevidi) Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routin= g-header Hi Tal, Indeed .. I saw the figures, but figures are non normative in any draft/rfc= unless text below specifically spells it out. For example from vxlan-gpe: "When the outer IP header is IPv4, VTEPs MUST set the DF bit." Besides it is pretty challenging to add animation to the current draft form= ats to illustrate all possibly allowed field values/combinations in any fig= ure :) Figures just illustrate one use example. To me the current specs permit any value of IPv6 NxtHdr field as permitted = in both encapsulations. Best, Robert. On Mon, May 23, 2016 at 9:35 AM, Tal Mizrahi > wrote: Hi Robert, >Where say in draft draft-quinn-vxlan-gpe do you see such statement that wo= uld imply > that v6 NxtHdr must be only equal to 17 (UDP) and not be a pointer to any= other type > of extension header further followed by UDP ? The following text is from Figure 4 in draft-ietf-nvo3-vxlan-gpe: Outer IPv6 Header: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Traffic Class | Flow Label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload Length | NxtHdr=3D17(UDP)| Hop Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | There is a similar figure in draft-ietf-nvo3-geneve. Best regards, Tal. From: nvo3 [mailto:nvo3-bounces@ietf.org] On = Behalf Of Robert Raszuk Sent: Monday, May 23, 2016 10:29 AM To: Tal Mizrahi Cc: spring@ietf.org; 6man WG; draft-ietf-nvo3-vxlan= -gpe@tools.ietf.org; nvo3@= ietf.org; draft-ietf-6man-segment-routing-header@tool= s.ietf.org; d= raft-ietf-nvo3-geneve@tools.ietf.org; Stefano Previdi (sprevidi) Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routin= g-header Hi Tal, > drafts seem to imply Where say in draft draft-quinn-vxlan-gpe do you see such statement that wou= ld imply that v6 NxtHdr must be only equal to 17 (UDP) and not be a pointer= to any other type of extension header further followed by UDP ? Thx, R. On Mon, May 23, 2016 at 7:50 AM, Tal Mizrahi > wrote: Dear Authors of VXLAN-GPE / Geneve, I am reiterating on this question, as I haven't seen a response yet: Have you considered the use of Segment Routing with VXLAN-GPE / Geneve? The= current VXLAN-GPE / Geneve drafts seem to imply that IPv6 extension header= s are currently not supported. Thanks, Tal. >-----Original Message----- >From: nvo3 [mailto:nvo3-bounces@ietf.org] On= Behalf Of Tal Mizrahi >Sent: Tuesday, May 17, 2016 12:09 PM >To: Stefano Previdi (sprevidi); Tom Herbert; draft-ietf-nvo3- >geneve@tools.ietf.org; draft-ietf-nvo3-vxlan= -gpe@tools.ietf.org >Cc: spring@ietf.org; nvo3@ietf.org; 6man WG; draft-ietf-6man-segment- >routing-header@tools.ietf.org >Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment- >routing-header > >Stefano, > >If I understand your point correctly: >IPv6 segment routing does not work with VXLAN / VXLAN-GPE / Geneve, since >these encapsulations do not currently allow the use of IPv6 extension >headers. > >I wonder if the authors of VXLAN-GPE and Geneve have considered the use of >segment routing. > >Thanks, >Tal. > > > >>-----Original Message----- >>From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >>Sent: Tuesday, May 17, 2016 10:41 AM >>To: Tom Herbert >>Cc: Tal Mizrahi; 6man WG; spring@ietf.org; >>draft-ietf-6man-segment-routing- header@tools.ietf.org >>Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing- >>header >> >> >>> On May 16, 2016, at 7:10 PM, Tom Herbert > >wrote: >>> >>> On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi > >>wrote: >>>>> it's all about IP, not layer-2. >>>>> >>>>> s. >>>> >>>> Right. However, it appears that at least in some cases a VXLAN VTEP >>>> will >>use SR. It certainly may be the case in SFC use cases (see Section 2.3 >>in draft- ietf-spring-ipv6-use-cases). >>>> >>> >>> draft-ietf-6man-segment-routing-header mentions that the packet is >>> encapsulated >> >> >>into an outer ipv6 header which makes it a layer-3 encap. >> >> >>> , but I don't think it is explicit as to exact encapsulation format >>> (I suppose simple ip6ip6 is implied). >> >> >>see section 2.2 >> >> >>> But, it >>> seems like any of several encapsulation techniques could work (VXLAN, >> >> >>I have some problems to understand where to fit an extension header >>into a vxlan encap... >> >> >>> GRE/IP, ESP/IP, GUE, foo over UDP, etc.) and if a device that wants >>> to do SR is already doing tunneling it seems reasonable to me to only >>> have one layer of encapsulation. Maybe this should be clarified in >>> the draft? >> >> >>the draft is about IPv6 extension header and more precisely a new type >>of the routing extension header defined in rfc2460. That's the context. >> >> >>s. >> >> >> >> >>> >>> Tom >>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >>>>> Sent: Monday, May 16, 2016 2:24 PM >>>>> To: Tal Mizrahi >>>>> Cc: Ole Tr=F8an; >>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org; >>>>> spring@ietf.org; 6man WG >>>>> Subject: Re: [spring] L4 Checksum and >>>>> draft-ietf-6man-segment-routing- header >>>>> >>>>> >>>>>> On May 16, 2016, at 1:19 PM, Tal Mizrahi > wrote: >>>>>> >>>>>> Hi Stefano, >>>>>> >>>>>> Thanks again for the prompt response. >>>>>> >>>>>>> 2. the SRH is originated by the ingress node of the SR domain. >>>>>>> This is done by encapsulating the packet into a outer >>>>>>> (additional) ipv6 header followed by an SRH. This is L3 >>>>>>> encapsulation and no L4 checksum is involved. When the packet >>>>>>> leaves the SR tunnel the outer encapsulation (including the SRH) >>>>>>> is removed and the packet continues its journey like nothing >happened. >>>>>> >>>>>> So VXLAN is off the table? >>>>> >>>>> >>>>> it's all about IP, not layer-2. >>>>> >>>>> s. >>>>> >>>>> >>>>>> It would be worthwhile to clarify this in the draft. If you have a >>>>>> specific >>>>> encapsulation in mind, it would be great if the draft would specify i= t. >>>>>> >>>>>> Thanks, >>>>>> Tal. >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >>>>>>> Sent: Monday, May 16, 2016 2:13 PM >>>>>>> To: Tal Mizrahi >>>>>>> Cc: Ole Tr=F8an; >>>>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org; >>>>>>> spring@ietf.org; 6man WG >>>>>>> Subject: Re: [spring] L4 Checksum and >>>>>>> draft-ietf-6man-segment-routing- header >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> On May 16, 2016, at 11:04 AM, Tal Mizrahi > >>wrote: >>>>>>>> >>>>>>>> Hi Stefano, >>>>>>>> >>>>>>>> Thanks for the responses. >>>>>>>> >>>>>>>>> exactly. >>>>>>>>> >>>>>>>>> Moreover, draft-ietf-6man-segment-routing-header assumes >>>>>>>>> encapsulation so clearly there's no L4 involved here. >>>>>>>>> >>>>>>>>> s. >>>>>>>> >>>>>>>> Two questions: >>>>>>>> 1. What if the encapsulation is VXLAN? L4 would still be >>>>>>>> involved, >>right? >>>>>>> >>>>>>> >>>>>>> See below. >>>>>>> >>>>>>> >>>>>>>> 2. When you say 'assumes encapsulation', does it mean that a >>>>>>>> host cannot >>>>>>> send an IPv6 packet with an SRH? The current draft says: >>>>>>>> >>>>>>>> A Source SR Node can be any node originating an IPv6 packet with >>>>>>>> its >>>>>>>> IPv6 and Segment Routing Headers. This include either: >>>>>>>> >>>>>>>> A host originating an IPv6 packet. >>>>>>>> >>>>>>>> An SR domain ingress router encapsulating a received IPv6 packe= t >>>>>>>> into an outer IPv6 header followed by an SRH. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Will appreciate if you can clarify that. >>>>>>> >>>>>>> >>>>>>> ok, two cases: >>>>>>> >>>>>>> 1. the SRH is inserted at the source. >>>>>>> the source originates the packet, the ipv6 header and the SRH. >>>>>>> The source computes L4 checksum taking into account the whole >>IPv6+SRH. >>>>>>> Here, theres' nothing new compared to rfc2460. >>>>>>> >>>>>>> 2. the SRH is originated by the ingress node of the SR domain. >>>>>>> This is done by encapsulating the packet into a outer >>>>>>> (additional) ipv6 header followed by an SRH. This is L3 >>>>>>> encapsulation and no L4 checksum is involved. When the packet >>>>>>> leaves the SR tunnel the outer encapsulation (including the SRH) >>>>>>> is removed and the packet continues its journey like nothing >happened. >>>>>>> >>>>>>> s. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Tal. >>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >>>>>>>>> Sent: Monday, May 16, 2016 11:59 AM >>>>>>>>> To: Ole Tr=F8an; Tal Mizrahi >>>>>>>>> Cc: draft-ietf-6man-segment-routing-header@tools.ietf.org; >>>>>>>>> spring@ietf.org; 6man WG >>>>>>>>> Subject: Re: [spring] L4 Checksum and >>>>>>>>> draft-ietf-6man-segment-routing- header >>>>>>>>> >>>>>>>>> >>>>>>>>>> On May 15, 2016, at 8:06 PM, otroan@employees.org wrote: >>>>>>>>>> >>>>>>>>>> Tal, >>>>>>>>>> >>>>>>>>>>> [Apologies if this issue has been discussed before.] >>>>>>>>>>> >>>>>>>>>>> According to draft-ietf-6man-segment-routing-header, an 'SR >>>>>>>>>>> Segment >>>>>>>>> Endpoint Node' updates the Destination IP address. >>>>>>>>>>> Therefore, it must also update the Layer 4 Checksum, right? >>>>>>>>>>> >>>>>>>>>>> I wonder if there is an upper bound on the size of the SRH. >>>>>>>>>>> Otherwise, the >>>>>>>>> L4 Checksum may be located in a pretty deep location. >>>>>>>>>>> Speaking from a chip vendor's perspective this may be a problem= . >>>>>>>>>> >>>>>>>>>> From RFC2460, RH0: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> o If the IPv6 packet contains a Routing header, the Destinati= on >>>>>>>>>> Address used in the pseudo-header is that of the final >>>>>>>>>> destination. At the originating node, that address will be= in >>>>>>>>>> the last element of the Routing header; at the recipient(s)= , >>>>>>>>>> that address will be in the Destination Address field of th= e >>>>>>>>>> IPv6 header. >>>>>>>>>> >>>>>>>>>> I would expect SR would work the same. >>>>>>>>> >>>>>>>>> >>>>>>>>> exactly. >>>>>>>>> >>>>>>>>> Moreover, draft-ietf-6man-segment-routing-header assumes >>>>>>>>> encapsulation so clearly there's no L4 involved here. >>>>>>>>> >>>>>>>>> s. >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> Ole >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- > >_______________________________________________ >nvo3 mailing list >nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_d5f75f2fc2dd4e72a0de3e581667b9f6ILEXCH02marvellcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Stefano,

 <= /p>

Going back to our origina= l discussion, I believe we can conclude that the L4 Checksum may be interes= ting in two possible scenarios:

 <= /p>

1.&nbs= p;      The SRH is generated by the host. In this case the L4 Checksum is c= omputed by the host based on the IP address of the last hop.

2.&nbs= p;      The SRH is generated by the ingress node of the SR domain using an = IP tunnel. Specifically, if the tunnel encapsulation includes an L4 header (e.g., VXLAN, VXLAN-GPE, Geneve, GUE), then (again) the ingre= ss node computes the L4 Checksum based on the IP address of the last hop.

 <= /p>

In both cases intermediat= e routers in the SR domain do not need to update the Checksum, even though = they update the destination IP address.

 <= /p>

It would be great if some= text would be added to the draft to clarify these observations.=

 <= /p>

Cheers,=

Tal.

 <= /p>

 <= /p>

 <= /p>

From: Larry Kr= eeger (kreeger) [mailto:kreeger@cisco.com]
Sent: Monday, May 23, 2016 11:55 PM
To: Tal Mizrahi
Cc: draft-ietf-nvo3-geneve@tools.ietf.org; draft-ietf-nvo3-vxlan-gpe= @tools.ietf.org; spring@ietf.org; 6man WG; nvo3@ietf.org; draft-ietf-6man-s= egment-routing-header@tools.ietf.org; Stefano Previdi (sprevidi)
Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment= -routing-header

 

I agree with Robert and Jes= se. - Larry

 

From: Jesse Gross <jgross@vmware.com>
Date: Monday, May 23, 2016 at 1:19 PM
To: Robert Raszuk <robert@ra= szuk.net>, Tal Mizrahi <talm= i@marvell.com>
Cc: "d= raft-ietf-nvo3-geneve@tools.ietf.org" <draft-ietf-nvo3-geneve@tools.ietf.org&= gt;, "draf= t-ietf-nvo3-vxlan-gpe@tools.ietf.org" <draft-ietf= -nvo3-vxlan-gpe@tools.ietf.org>, "spring@ietf.org" <spri= ng@ietf.org>, 6man WG <ipv6@ietf= .org>, "nvo3@ietf.org" <nvo3@ietf.org>, "draft-ietf-6man-segmen= t-routing-header@tools.ietf.org" <draft-ietf-6man-segment-routing= -header@tools.ietf.org>, "Stefano Previdi (sprevidi)" <sprevidi@cisco.com>
Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment= -routing-header
Resent-From: <alias-bou= nces@ietf.org>, <jgross@vmwa= re.com>
Resent-To: Larry Kreeger <kr= eeger@cisco.com>, <uri.elz= ur@intel.com>, <draft-ietf-6man-segment-routing-header@ietf.org> Resent-Date: Monday, May 23, 2016 at 1:20 PM

 

I agree that I don’t = believe that there is anything in these drafts that precludes the use of ex= tension headers or segment routing – IP is simply the layer underneat= h that these protocols are building on. The figures are definitely just exam= ples – they also show outer Ethernet headers, which is not a requirem= ent.

 

I wouldn’t want to ad= d text specifically stating that extension headers are permissible. It seem= s like that could lead to similar questions in the future where one might wonder if other features of IP are allowed because one is explic= itly listed and others are not, etc. In my opinion, the drafts are about as= clear as they can be on this point.

 

Jesse

 

On 5/23/16, 1:09 AM, "= rraszuk@gmail.com on behalf of Rob= ert Raszuk" <rraszuk@gmail.com= on behalf of robert@raszuk.net>= ; wrote:

 

Hi Tal,

 

> In order to avoid am= biguity, it would be great if the 

> authors could explic= itly mention that IPv6 extension 

> headers are permitte= d.

 

Well the drafts are complaint to RFC2119 (norm= ative reference) so unless the text excludes elements with MUST/MUST NOT - = everything else defined in the building blocks they (re)use is permitted. 

 

However as you say perhaps for clarity what co= uld be added to those drafts is a normative reference to IPv4 and IPv6 base= RFCs.

 

Best,

R.

 

 

On Mon, May 23, 2016 at 9:5= 4 AM, Tal Mizrahi <talmi@marvell.com> wrote:

Hi Robert,

 

That makes sense.

However, in this case the figures may b= e a bit confusing WRT the possible existence of extension headers. This confusion is what led to the discussion in this thread about= whether segment routing is possible with VXLAN/VXLAN-GPE/Geneve encapsulat= ions.

 

In order to avoid ambiguity, it would b= e great if the authors could explicitly mention that IPv6 extension headers are permitted.

 

Regards,

Tal.=

 

From:rraszuk@gmail.com [mailto:rraszuk@gma= il.com] On Behalf Of Robert Raszuk
Sent: Monday, May 23, 2016 10:47 AM


To: Tal Mizrahi
Cc: spring@ietf= .org; 6man WG; draft-ietf-nvo3-vxlan-gpe@tools.ietf.org; nvo3@ietf.org; draft-ietf-6man-segment-routing-header@tools.ietf.org; draft-ietf-nvo3-geneve@tools.ietf.org; Stefano Previdi (sprevidi)
Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment= -routing-header

 

Hi Tal,=

 <= /p>

Indeed .. I saw the figures, but figures are non normative i= n any draft/rfc unless text below specifically spells it out. <= span style=3D"color:black">

 <= /p>

For example from vxlan-gpe: 

 <= /p>

"When the outer IP header is IPv4, VTEPs MUST set the D= F bit."

 <= /p>

Besides it is pretty challenging to add animation to the cur= rent draft formats to illustrate all possibly allowed field values/combinations in any figure :)  Figures just illustrate one use= example. 

 <= /p>

To me the current specs permit any value of IPv6 NxtHdr fiel= d as permitted in both encapsulations.

 <= /p>

Best,

Robert.=

 <= /p>

 

On Mon, May 23, 2016 at 9:35 AM, Tal M= izrahi <talmi@mar= vell.com> wrote:

Hi Robert,

 

 

>Where say in draft draft-quinn-vxla= n-gpe do you see such statement that would imply

> that v6 NxtHdr must be only equal = to 17 (UDP) and not be a pointer to any other type

> of extension header further follow= ed by UDP ?

 

 

The following text is from Figure 4 in = draft-ietf-nvo3-vxlan-gpe:

 

      Outer IPv6 Header:

      +-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+

      |Version| Traffic Class |&n= bsp;          Flow Label =             &nb= sp;    |

      +-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+

      |    &n= bsp;    Payload Length      &n= bsp; | NxtHdr=3D17(UDP)|   Hop Limit   |

      +-+-+-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+

      |    &n= bsp;            = ;            &n= bsp;            &nbs= p;            &= nbsp;       |

 

 

There is a similar figure in draft-ietf= -nvo3-geneve.

 

Best regards,

Tal.=

 

From: nvo3 [mailto:nvo3-bo= unces@ietf.org] On Behalf Of Robert Raszuk
Sent: Monday, May 23, 2016 10:29 AM
To: Tal Mizrahi
Cc: spring@ietf= .org; 6man WG; draft-ietf-nvo3-vxlan-gpe@tools.ietf.org; nvo3@ietf.org; draft-ietf-6man-segment-routing-header@tools.ietf.org; draft-ietf-nvo3-geneve@tools.ietf.org; Stefano Previdi (sprevidi)


Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment= -routing-header

 

Hi Tal,=

 <= /p>

> drafts seem to imply<= /span>

 <= /p>

Where say in draft draft-quinn-vxlan-gpe do you see suc= h statement that would imply that v6 NxtHdr must be only equal to 17 (UDP) and not be a pointer to any other type of extension header fur= ther followed by UDP ? <= /span>

 <= /p>

Thx,
R.

 <= /p>

 

On Mon, May 23, 2016 at 7:50 AM, Tal M= izrahi <talmi@mar= vell.com> wrote:

Dear Authors of VXLAN-GPE / Geneve,
I am reiterating on this question, as I haven't seen a response yet:

Have you considered the use of Segment Routing with VXLAN-GPE / Geneve? The= current VXLAN-GPE / Geneve drafts seem to imply that IPv6 extension header= s are currently not supported.

Thanks,
Tal.




>-----Original Message-----
>From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Tal Mizrahi
>Sent: Tuesday, May 17, 2016 12:09 PM
>To: Stefano Previdi (sprevidi); Tom Herbert; draft-ietf-nvo3-
>geneve@tools= .ietf.org; draft-ietf-nvo3-vxlan-gpe@tools.ietf.org
>Cc: spring@ietf.or= g; nvo3@ietf.org; 6man WG; draft-ietf-6man-segment-
>rout= ing-header@tools.ietf.org
>Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment- >routing-header
>
>Stefano,
>
>If I understand your point correctly:
>IPv6 segment routing does not work with VXLAN / VXLAN-GPE / Geneve, sin= ce
>these encapsulations do not currently allow the use of IPv6 extension >headers.
>
>I wonder if the authors of VXLAN-GPE and Geneve have considered the use= of
>segment routing.
>
>Thanks,
>Tal.
>
>
>
>>-----Original Message-----
>>From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
>>Sent: Tuesday, May 17, 2016 10:41 AM
>>To: Tom Herbert
>>Cc: Tal Mizrahi; 6man WG; spring@ietf.org;
>>draft-ietf-6man-segment-routing- header@tools.ietf.org
>>Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routi= ng-
>>header
>>
>>
>>> On May 16, 2016, at 7:10 PM, Tom Herbert <tom@herbertland.com>
>wrote:
>>>
>>> On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi <talmi@marvell.com>
>>wrote:
>>>>> it’s all about IP, not layer-2.
>>>>>
>>>>> s.
>>>>
>>>> Right. However, it appears that at least in some cases a V= XLAN VTEP
>>>> will
>>use SR. It certainly may be the case in SFC use cases (see Section = 2.3
>>in draft- ietf-spring-ipv6-use-cases).
>>>>
>>>
>>> draft-ietf-6man-segment-routing-header mentions that the packe= t is
>>> encapsulated
>>
>>
>>into an outer ipv6 header which makes it a layer-3 encap.
>>
>>
>>> , but I don't think it is explicit as to exact encapsulation f= ormat
>>> (I suppose simple ip6ip6 is implied).
>>
>>
>>see section 2.2
>>
>>
>>> But, it
>>> seems like any of several encapsulation techniques could work = (VXLAN,
>>
>>
>>I have some problems to understand where to fit an extension header=
>>into a vxlan encap…
>>
>>
>>> GRE/IP, ESP/IP, GUE, foo over UDP, etc.) and if a device that = wants
>>> to do SR is already doing tunneling it seems reasonable to me = to only
>>> have one layer of encapsulation. Maybe this should be clarifie= d in
>>> the draft?
>>
>>
>>the draft is about IPv6 extension header and more precisely a new t= ype
>>of the routing extension header defined in rfc2460. That’s th= e context.
>>
>>
>>s.
>>
>>
>>
>>
>>>
>>> Tom
>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
>>>>> Sent: Monday, May 16, 2016 2:24 PM
>>>>> To: Tal Mizrahi
>>>>> Cc: Ole Tr=F8an;
>>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org;
>>>>> s= pring@ietf.org; 6man WG
>>>>> Subject: Re: [spring] L4 Checksum and
>>>>> draft-ietf-6man-segment-routing- header
>>>>>
>>>>>
>>>>>> On May 16, 2016, at 1:19 PM, Tal Mizrahi <talmi@marvell.com>= wrote:
>>>>>>
>>>>>> Hi Stefano,
>>>>>>
>>>>>> Thanks again for the prompt response.
>>>>>>
>>>>>>> 2. the SRH is originated by the ingress node o= f the SR domain.
>>>>>>> This is done by encapsulating the packet into = a outer
>>>>>>> (additional) ipv6 header followed by an SRH. T= his is L3
>>>>>>> encapsulation and no L4 checksum is involved. = When the  packet
>>>>>>> leaves the SR tunnel the outer encapsulation&n= bsp; (including the SRH)
>>>>>>> is removed and the packet continues  its = journey like nothing
>happened.
>>>>>>
>>>>>> So VXLAN is off the table?
>>>>>
>>>>>
>>>>> it’s all about IP, not layer-2.
>>>>>
>>>>> s.
>>>>>
>>>>>
>>>>>> It would be worthwhile to clarify this in the draf= t. If you have a
>>>>>> specific
>>>>> encapsulation in mind, it would be great if the draft = would specify it.
>>>>>>
>>>>>> Thanks,
>>>>>> Tal.
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]<= br> >>>>>>> Sent: Monday, May 16, 2016 2:13 PM
>>>>>>> To: Tal Mizrahi
>>>>>>> Cc: Ole Tr=F8an;
>>>>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org;
>>>>>>> spring@ietf.org; 6man WG
>>>>>>> Subject: Re: [spring] L4 Checksum and
>>>>>>> draft-ietf-6man-segment-routing- header
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On May 16, 2016, at 11:04 AM, Tal Mizrahi <= talmi@marvell.com>
>>wrote:
>>>>>>>>
>>>>>>>> Hi Stefano,
>>>>>>>>
>>>>>>>> Thanks for the responses.
>>>>>>>>
>>>>>>>>> exactly.
>>>>>>>>>
>>>>>>>>> Moreover, draft-ietf-6man-segment-rout= ing-header assumes
>>>>>>>>> encapsulation so clearly there’s= no L4 involved here.
>>>>>>>>>
>>>>>>>>> s.
>>>>>>>>
>>>>>>>> Two questions:
>>>>>>>> 1. What if the encapsulation is VXLAN? L4 = would still be
>>>>>>>> involved,
>>right?
>>>>>>>
>>>>>>>
>>>>>>> See below.
>>>>>>>
>>>>>>>
>>>>>>>> 2. When you say 'assumes encapsulation', d= oes it mean that a
>>>>>>>> host cannot
>>>>>>> send an IPv6 packet with an SRH? The current d= raft says:
>>>>>>>>
>>>>>>>> A Source SR Node can be any node originati= ng an IPv6 packet with
>>>>>>>> its
>>>>>>>> IPv6 and Segment Routing Headers.  Th= is include either:
>>>>>>>>
>>>>>>>>    A host originating an IPv6 pa= cket.
>>>>>>>>
>>>>>>>>    An SR domain ingress router e= ncapsulating a received IPv6 packet
>>>>>>>>    into an outer IPv6 header fol= lowed by an SRH.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Will appreciate if you can clarify that. >>>>>>>
>>>>>>>
>>>>>>> ok, two cases:
>>>>>>>
>>>>>>> 1. the SRH is inserted at the source.
>>>>>>> the source originates the packet, the ipv6 hea= der and  the SRH.
>>>>>>> The source computes L4 checksum taking into&nb= sp; account the whole
>>IPv6+SRH.
>>>>>>> Here, theres’ nothing new  compared= to rfc2460.
>>>>>>>
>>>>>>> 2. the SRH is originated by the ingress node o= f the SR domain.
>>>>>>> This is done by encapsulating the packet into = a outer
>>>>>>> (additional) ipv6 header followed by an SRH. T= his is L3
>>>>>>> encapsulation and no L4 checksum is involved. = When the  packet
>>>>>>> leaves the SR tunnel the outer encapsulation&n= bsp; (including the SRH)
>>>>>>> is removed and the packet continues  its = journey like nothing
>happened.
>>>>>>>
>>>>>>> s.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Tal.
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Stefano Previdi (sprevidi) [mail= to:sprevidi@cisco.c= om]
>>>>>>>>> Sent: Monday, May 16, 2016 11:59 AM >>>>>>>>> To: Ole Tr=F8an; Tal Mizrahi
>>>>>>>>> Cc: draft-ietf-6man-segment-routing-header@tools.ietf.org;
>>>>>>>>> spring@ietf.org; 6man WG
>>>>>>>>> Subject: Re: [spring] L4 Checksum and<= br> >>>>>>>>> draft-ietf-6man-segment-routing- heade= r
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On May 15, 2016, at 8:06 PM, otroan@employees.org wrote:
>>>>>>>>>>
>>>>>>>>>> Tal,
>>>>>>>>>>
>>>>>>>>>>> [Apologies if this issue has b= een discussed before.]
>>>>>>>>>>>
>>>>>>>>>>> According to draft-ietf-6man-s= egment-routing-header, an ‘SR
>>>>>>>>>>> Segment
>>>>>>>>> Endpoint Node’ updates the Desti= nation IP address.
>>>>>>>>>>> Therefore, it must also update= the Layer 4 Checksum, right?
>>>>>>>>>>>
>>>>>>>>>>> I wonder if there is an upper = bound on the size of the SRH.
>>>>>>>>>>> Otherwise, the
>>>>>>>>> L4 Checksum may be located in a pretty= deep location.
>>>>>>>>>>> Speaking from a chip vendor= 217;s perspective this may be a problem.
>>>>>>>>>>
>>>>>>>>>> From RFC2460, RH0:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>   o  If the IPv6 pa= cket contains a Routing header, the Destination
>>>>>>>>>>      Address used i= n the pseudo-header is that of the final
>>>>>>>>>>      destination.&n= bsp; At the originating node, that address will be in
>>>>>>>>>>      the last eleme= nt of the Routing header; at the recipient(s),
>>>>>>>>>>      that address w= ill be in the Destination Address field of the
>>>>>>>>>>      IPv6 header. >>>>>>>>>>
>>>>>>>>>> I would expect SR would work the s= ame.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> exactly.
>>>>>>>>>
>>>>>>>>> Moreover, draft-ietf-6man-segment-rout= ing-header assumes
>>>>>>>>> encapsulation so clearly there’s= no L4 involved here.
>>>>>>>>>
>>>>>>>>> s.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Ole
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>> ----------------------------------------------------------= ----------
>>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> ----------------------------------------------------------= ----------
>
>_______________________________________________
>nvo3 mailing list
>nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3

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

 

 

 

--_000_d5f75f2fc2dd4e72a0de3e581667b9f6ILEXCH02marvellcom_-- From nobody Tue May 31 09:02:46 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 474D712D7FE; Tue, 31 May 2016 09:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.947 X-Spam-Level: X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bq2kzmSywLVr; Tue, 31 May 2016 09:02:42 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1713412D610; Tue, 31 May 2016 09:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18065; q=dns/txt; s=iport; t=1464710561; x=1465920161; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QfQPj7a+Zde9BvekMbL0revFNBqgy5slxPLuRdoysYg=; b=G6tY9hoE+U2o8cLrouwAeVYKdS+NuW8Ak1Yd9mzfoWEXGT2gvs/y00Qd +oKLutoIDtV9hEU/Tb4ZBHmHpdu0+4nEOnEe0VP0dPjx6mtOVYpQONo2J z5Vi/ngb8wKezk9xv9eb4oz2f5UvAarMvvAWZaH/8A/w5c3VDoQF16uxo Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQBftE1X/4oNJK1bgzyBUwauFYtvA?= =?us-ascii?q?Q2BeoYRAoE+OBQBAQEBAQEBZSeERQEBAQMBeQUHBAIBCBEDAQEBARUSByERFAk?= =?us-ascii?q?IAgQOBYgVAw8IuXMNhB8BAQEBAQEBAQEBAQEBAQEBAQEBAQEchieBdwiBS4EDg?= =?us-ascii?q?kOBWiM/gnWCLgWOHYlnMwGId4MvgXmBaY0zhjOBMYdnAR4BAUKDbW6IcwEGIB9?= =?us-ascii?q?/AQEB?= X-IronPort-AV: E=Sophos;i="5.26,396,1459814400"; d="scan'208";a="279981446" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 31 May 2016 16:02:39 +0000 Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u4VG2dDo020533 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 31 May 2016 16:02:39 GMT Received: from xch-rtp-010.cisco.com (64.101.220.150) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 31 May 2016 12:02:38 -0400 Received: from xch-rtp-010.cisco.com ([64.101.220.150]) by XCH-RTP-010.cisco.com ([64.101.220.150]) with mapi id 15.00.1104.009; Tue, 31 May 2016 12:02:38 -0400 From: "Stefano Previdi (sprevidi)" To: Tal Mizrahi Thread-Topic: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routing-header Thread-Index: AQHRtMWkQ84SBd4Z00OPA2d5Y/ic9p/GZ/OAgAACKoCAAARfAIAAy/oAgAAJ14CADD6+AIAAAh4A Date: Tue, 31 May 2016 16:02:38 +0000 Message-ID: <5A098FFC-5D34-4E4C-9231-4783077B7D05@cisco.com> References: <5dc56935eba94c2390120244564f9b21@IL-EXCH02.marvell.com> <0551686F-F1D2-4C34-81C8-530F1BEE1BDF@cisco.com> <5d889e7013b44b27ae1e75cf7ea2dd22@IL-EXCH02.marvell.com> <3549ABBE-9828-42D2-A056-851432487E2E@cisco.com> <1e13d2e32b2448af94bf23d5acf17740@IL-EXCH02.marvell.com> <569a4067fd1f45dd85d60e983be69b90@IL-EXCH02.marvell.com> <1c27bb3513bc48889ec310e8d143784c@IL-EXCH02.marvell.com> <36D9FCF0-382C-4669-85A5-C782636A85BB@vmware.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.201.156] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <764A43FFFC5A82498A4729D56E40B12D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" , 6man WG , "draft-ietf-6man-segment-routing-header@tools.ietf.org" Subject: Re: [spring] [nvo3] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2016 16:02:46 -0000 > On May 31, 2016, at 5:54 PM, Tal Mizrahi wrote: >=20 > Hi Stefano, >=20 > Going back to our original discussion, I believe we can conclude that the= L4 Checksum may be interesting in two possible scenarios: >=20 >=20 > 1. The SRH is generated by the host. In this case the L4 Checksum i= s computed by the host based on the IP address of the last hop. >=20 > 2. The SRH is generated by the ingress node of the SR domain using = an IP tunnel. Specifically, if the tunnel encapsulation includes an L4 head= er (e.g., VXLAN, VXLAN-GPE, Geneve, GUE), then (again) the ingress node com= putes the L4 Checksum based on the IP address of the last hop. >=20 > In both cases intermediate routers in the SR domain do not need to update= the Checksum, even though they update the destination IP address. it can be simplified by stating that any SRH that is inserted in transit MU= ST be removed prior to deliver the packet to the final destination. All other cases implies that the source is inserting the SRH, in which case= the checksum is consistent. s. >=20 > It would be great if some text would be added to the draft to clarify the= se observations. >=20 > Cheers, > Tal. >=20 >=20 >=20 > From: Larry Kreeger (kreeger) [mailto:kreeger@cisco.com] > Sent: Monday, May 23, 2016 11:55 PM > To: Tal Mizrahi > Cc: draft-ietf-nvo3-geneve@tools.ietf.org; draft-ietf-nvo3-vxlan-gpe@tool= s.ietf.org; spring@ietf.org; 6man WG; nvo3@ietf.org; draft-ietf-6man-segmen= t-routing-header@tools.ietf.org; Stefano Previdi (sprevidi) > Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-rout= ing-header >=20 > I agree with Robert and Jesse. - Larry >=20 > From: Jesse Gross > > Date: Monday, May 23, 2016 at 1:19 PM > To: Robert Raszuk >, Tal Mizr= ahi > > Cc: "draft-ietf-nvo3-geneve@tools.ietf.org" >, "draft-ietf-nvo3-vxlan-gpe@tools.ietf.org" >, "spring@iet= f.org" >, 6= man WG >, "nvo3@ietf.org" >, "draft-ietf-6man-segment-ro= uting-header@tools.ietf.org" >, "Stefano Previd= i (sprevidi)" > > Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-rout= ing-header > Resent-From: >, > > Resent-To: Larry Kreeger >, <= uri.elzur@intel.com>, > > Resent-Date: Monday, May 23, 2016 at 1:20 PM >=20 > I agree that I don't believe that there is anything in these drafts that = precludes the use of extension headers or segment routing - IP is simply th= e layer underneath that these protocols are building on. The figures are de= finitely just examples - they also show outer Ethernet headers, which is no= t a requirement. >=20 > I wouldn't want to add text specifically stating that extension headers a= re permissible. It seems like that could lead to similar questions in the f= uture where one might wonder if other features of IP are allowed because on= e is explicitly listed and others are not, etc. In my opinion, the drafts a= re about as clear as they can be on this point. >=20 > Jesse >=20 > On 5/23/16, 1:09 AM, "rraszuk@gmail.com on beha= lf of Robert Raszuk" on behalf= of robert@raszuk.net> wrote: >=20 > Hi Tal, >=20 >> In order to avoid ambiguity, it would be great if the >> authors could explicitly mention that IPv6 extension >> headers are permitted. >=20 > Well the drafts are complaint to RFC2119 (normative reference) so unless = the text excludes elements with MUST/MUST NOT - everything else defined in = the building blocks they (re)use is permitted. >=20 > However as you say perhaps for clarity what could be added to those draft= s is a normative reference to IPv4 and IPv6 base RFCs. >=20 > Best, > R. >=20 >=20 > On Mon, May 23, 2016 at 9:54 AM, Tal Mizrahi > wrote: > Hi Robert, >=20 > That makes sense. > However, in this case the figures may be a bit confusing WRT the possible= existence of extension headers. This confusion is what led to the discussi= on in this thread about whether segment routing is possible with VXLAN/VXLA= N-GPE/Geneve encapsulations. >=20 > In order to avoid ambiguity, it would be great if the authors could expli= citly mention that IPv6 extension headers are permitted. >=20 > Regards, > Tal. >=20 > From:rraszuk@gmail.com [mailto:rraszuk@gmail.co= m] On Behalf Of Robert Raszuk > Sent: Monday, May 23, 2016 10:47 AM >=20 > To: Tal Mizrahi > Cc: spring@ietf.org; 6man WG; draft-ietf-nvo3-vxl= an-gpe@tools.ietf.org; nvo= 3@ietf.org; draft-ietf-6man-segment-routing-header@to= ols.ietf.org;= draft-ietf-nvo3-geneve@tools.ietf.org; Stefano Previdi (sprevidi) > Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-rout= ing-header >=20 > Hi Tal, >=20 > Indeed .. I saw the figures, but figures are non normative in any draft/r= fc unless text below specifically spells it out. >=20 > For example from vxlan-gpe: >=20 > "When the outer IP header is IPv4, VTEPs MUST set the DF bit." >=20 > Besides it is pretty challenging to add animation to the current draft fo= rmats to illustrate all possibly allowed field values/combinations in any f= igure :) Figures just illustrate one use example. >=20 > To me the current specs permit any value of IPv6 NxtHdr field as permitte= d in both encapsulations. >=20 > Best, > Robert. >=20 >=20 > On Mon, May 23, 2016 at 9:35 AM, Tal Mizrahi > wrote: > Hi Robert, >=20 >=20 >> Where say in draft draft-quinn-vxlan-gpe do you see such statement that = would imply >> that v6 NxtHdr must be only equal to 17 (UDP) and not be a pointer to an= y other type >> of extension header further followed by UDP ? >=20 >=20 > The following text is from Figure 4 in draft-ietf-nvo3-vxlan-gpe: >=20 > Outer IPv6 Header: > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |Version| Traffic Class | Flow Label | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload Length | NxtHdr=3D17(UDP)| Hop Limit | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | >=20 >=20 > There is a similar figure in draft-ietf-nvo3-geneve. >=20 > Best regards, > Tal. >=20 > From: nvo3 [mailto:nvo3-bounces@ietf.org] O= n Behalf Of Robert Raszuk > Sent: Monday, May 23, 2016 10:29 AM > To: Tal Mizrahi > Cc: spring@ietf.org; 6man WG; draft-ietf-nvo3-vxl= an-gpe@tools.ietf.org; nvo= 3@ietf.org; draft-ietf-6man-segment-routing-header@to= ols.ietf.org;= draft-ietf-nvo3-geneve@tools.ietf.org; Stefano Previdi (sprevidi) >=20 > Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-rout= ing-header >=20 > Hi Tal, >=20 >> drafts seem to imply >=20 > Where say in draft draft-quinn-vxlan-gpe do you see such statement that w= ould imply that v6 NxtHdr must be only equal to 17 (UDP) and not be a point= er to any other type of extension header further followed by UDP ? >=20 > Thx, > R. >=20 >=20 > On Mon, May 23, 2016 at 7:50 AM, Tal Mizrahi > wrote: > Dear Authors of VXLAN-GPE / Geneve, >=20 > I am reiterating on this question, as I haven't seen a response yet: >=20 > Have you considered the use of Segment Routing with VXLAN-GPE / Geneve? T= he current VXLAN-GPE / Geneve drafts seem to imply that IPv6 extension head= ers are currently not supported. >=20 > Thanks, > Tal. >=20 >=20 >=20 >> -----Original Message----- >> From: nvo3 [mailto:nvo3-bounces@ietf.org] = On Behalf Of Tal Mizrahi >> Sent: Tuesday, May 17, 2016 12:09 PM >> To: Stefano Previdi (sprevidi); Tom Herbert; draft-ietf-nvo3- >> geneve@tools.ietf.org; draft-ietf-nvo3-vxl= an-gpe@tools.ietf.org >> Cc: spring@ietf.org; nvo3@ietf.org; 6man WG; draft-ietf-6man-segment- >> routing-header@tools.ietf.org >> Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment- >> routing-header >>=20 >> Stefano, >>=20 >> If I understand your point correctly: >> IPv6 segment routing does not work with VXLAN / VXLAN-GPE / Geneve, sinc= e >> these encapsulations do not currently allow the use of IPv6 extension >> headers. >>=20 >> I wonder if the authors of VXLAN-GPE and Geneve have considered the use = of >> segment routing. >>=20 >> Thanks, >> Tal. >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >>> Sent: Tuesday, May 17, 2016 10:41 AM >>> To: Tom Herbert >>> Cc: Tal Mizrahi; 6man WG; spring@ietf.org; >>> draft-ietf-6man-segment-routing- header@tools.ietf.org >>> Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing- >>> header >>>=20 >>>=20 >>>> On May 16, 2016, at 7:10 PM, Tom Herbert > >> wrote: >>>>=20 >>>> On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi > >>> wrote: >>>>>> it's all about IP, not layer-2. >>>>>>=20 >>>>>> s. >>>>>=20 >>>>> Right. However, it appears that at least in some cases a VXLAN VTEP >>>>> will >>> use SR. It certainly may be the case in SFC use cases (see Section 2.3 >>> in draft- ietf-spring-ipv6-use-cases). >>>>>=20 >>>>=20 >>>> draft-ietf-6man-segment-routing-header mentions that the packet is >>>> encapsulated >>>=20 >>>=20 >>> into an outer ipv6 header which makes it a layer-3 encap. >>>=20 >>>=20 >>>> , but I don't think it is explicit as to exact encapsulation format >>>> (I suppose simple ip6ip6 is implied). >>>=20 >>>=20 >>> see section 2.2 >>>=20 >>>=20 >>>> But, it >>>> seems like any of several encapsulation techniques could work (VXLAN, >>>=20 >>>=20 >>> I have some problems to understand where to fit an extension header >>> into a vxlan encap... >>>=20 >>>=20 >>>> GRE/IP, ESP/IP, GUE, foo over UDP, etc.) and if a device that wants >>>> to do SR is already doing tunneling it seems reasonable to me to only >>>> have one layer of encapsulation. Maybe this should be clarified in >>>> the draft? >>>=20 >>>=20 >>> the draft is about IPv6 extension header and more precisely a new type >>> of the routing extension header defined in rfc2460. That's the context. >>>=20 >>>=20 >>> s. >>>=20 >>>=20 >>>=20 >>>=20 >>>>=20 >>>> Tom >>>>=20 >>>>>=20 >>>>>=20 >>>>>> -----Original Message----- >>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >>>>>> Sent: Monday, May 16, 2016 2:24 PM >>>>>> To: Tal Mizrahi >>>>>> Cc: Ole Tr=F8an; >>>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org; >>>>>> spring@ietf.org; 6man WG >>>>>> Subject: Re: [spring] L4 Checksum and >>>>>> draft-ietf-6man-segment-routing- header >>>>>>=20 >>>>>>=20 >>>>>>> On May 16, 2016, at 1:19 PM, Tal Mizrahi > wrote: >>>>>>>=20 >>>>>>> Hi Stefano, >>>>>>>=20 >>>>>>> Thanks again for the prompt response. >>>>>>>=20 >>>>>>>> 2. the SRH is originated by the ingress node of the SR domain. >>>>>>>> This is done by encapsulating the packet into a outer >>>>>>>> (additional) ipv6 header followed by an SRH. This is L3 >>>>>>>> encapsulation and no L4 checksum is involved. When the packet >>>>>>>> leaves the SR tunnel the outer encapsulation (including the SRH) >>>>>>>> is removed and the packet continues its journey like nothing >> happened. >>>>>>>=20 >>>>>>> So VXLAN is off the table? >>>>>>=20 >>>>>>=20 >>>>>> it's all about IP, not layer-2. >>>>>>=20 >>>>>> s. >>>>>>=20 >>>>>>=20 >>>>>>> It would be worthwhile to clarify this in the draft. If you have a >>>>>>> specific >>>>>> encapsulation in mind, it would be great if the draft would specify = it. >>>>>>>=20 >>>>>>> Thanks, >>>>>>> Tal. >>>>>>>=20 >>>>>>>=20 >>>>>>>> -----Original Message----- >>>>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >>>>>>>> Sent: Monday, May 16, 2016 2:13 PM >>>>>>>> To: Tal Mizrahi >>>>>>>> Cc: Ole Tr=F8an; >>>>>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org; >>>>>>>> spring@ietf.org; 6man WG >>>>>>>> Subject: Re: [spring] L4 Checksum and >>>>>>>> draft-ietf-6man-segment-routing- header >>>>>>>>=20 >>>>>>>> Hi, >>>>>>>>=20 >>>>>>>> On May 16, 2016, at 11:04 AM, Tal Mizrahi > >>> wrote: >>>>>>>>>=20 >>>>>>>>> Hi Stefano, >>>>>>>>>=20 >>>>>>>>> Thanks for the responses. >>>>>>>>>=20 >>>>>>>>>> exactly. >>>>>>>>>>=20 >>>>>>>>>> Moreover, draft-ietf-6man-segment-routing-header assumes >>>>>>>>>> encapsulation so clearly there's no L4 involved here. >>>>>>>>>>=20 >>>>>>>>>> s. >>>>>>>>>=20 >>>>>>>>> Two questions: >>>>>>>>> 1. What if the encapsulation is VXLAN? L4 would still be >>>>>>>>> involved, >>> right? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> See below. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> 2. When you say 'assumes encapsulation', does it mean that a >>>>>>>>> host cannot >>>>>>>> send an IPv6 packet with an SRH? The current draft says: >>>>>>>>>=20 >>>>>>>>> A Source SR Node can be any node originating an IPv6 packet with >>>>>>>>> its >>>>>>>>> IPv6 and Segment Routing Headers. This include either: >>>>>>>>>=20 >>>>>>>>> A host originating an IPv6 packet. >>>>>>>>>=20 >>>>>>>>> An SR domain ingress router encapsulating a received IPv6 packe= t >>>>>>>>> into an outer IPv6 header followed by an SRH. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Will appreciate if you can clarify that. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> ok, two cases: >>>>>>>>=20 >>>>>>>> 1. the SRH is inserted at the source. >>>>>>>> the source originates the packet, the ipv6 header and the SRH. >>>>>>>> The source computes L4 checksum taking into account the whole >>> IPv6+SRH. >>>>>>>> Here, theres' nothing new compared to rfc2460. >>>>>>>>=20 >>>>>>>> 2. the SRH is originated by the ingress node of the SR domain. >>>>>>>> This is done by encapsulating the packet into a outer >>>>>>>> (additional) ipv6 header followed by an SRH. This is L3 >>>>>>>> encapsulation and no L4 checksum is involved. When the packet >>>>>>>> leaves the SR tunnel the outer encapsulation (including the SRH) >>>>>>>> is removed and the packet continues its journey like nothing >> happened. >>>>>>>>=20 >>>>>>>> s. >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> Tal. >>>>>>>>>=20 >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >>>>>>>>>> Sent: Monday, May 16, 2016 11:59 AM >>>>>>>>>> To: Ole Tr=F8an; Tal Mizrahi >>>>>>>>>> Cc: draft-ietf-6man-segment-routing-header@tools.ietf.org; >>>>>>>>>> spring@ietf.org; 6man WG >>>>>>>>>> Subject: Re: [spring] L4 Checksum and >>>>>>>>>> draft-ietf-6man-segment-routing- header >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>> On May 15, 2016, at 8:06 PM, otroan@employees.org wrote: >>>>>>>>>>>=20 >>>>>>>>>>> Tal, >>>>>>>>>>>=20 >>>>>>>>>>>> [Apologies if this issue has been discussed before.] >>>>>>>>>>>>=20 >>>>>>>>>>>> According to draft-ietf-6man-segment-routing-header, an 'SR >>>>>>>>>>>> Segment >>>>>>>>>> Endpoint Node' updates the Destination IP address. >>>>>>>>>>>> Therefore, it must also update the Layer 4 Checksum, right? >>>>>>>>>>>>=20 >>>>>>>>>>>> I wonder if there is an upper bound on the size of the SRH. >>>>>>>>>>>> Otherwise, the >>>>>>>>>> L4 Checksum may be located in a pretty deep location. >>>>>>>>>>>> Speaking from a chip vendor's perspective this may be a proble= m
Hi Tal,

>=C2=A0drafts seem to imply

=
Where say in draft=C2=A0draft-quinn-vxlan-gpe do y= ou see such statement that would imply that v6 NxtHdr must be only equal to= 17 (UDP) and not be a pointer to any other type of extension header furthe= r followed by UDP ?=C2=A0

Thx,
R.


On Mon, May 23, 2016 at 7:50 AM, Tal = Mizrahi <talmi@marvell.com> wrote:
Dear Authors of VXLAN-GPE / Geneve,

I am reiterating on this question, as I haven't seen a response yet:
Have you considered the use of Segment Routing with VXLAN-GPE / Geneve? The= current VXLAN-GPE / Geneve drafts seem to imply that IPv6 extension header= s are currently not supported.

Thanks,
Tal.



>-----Original Message-----
>From: nvo3 [mailto:nvo3-bounce= s@ietf.org] On Behalf Of Tal Mizrahi
>Sent: Tuesday, May 17, 2016 12:09 PM
>To: Stefano Previdi (sprevidi); Tom Herbert; draft-ietf-nvo3-
>geneve@tools.ietf.org; draft-ietf-nvo3-vx= lan-gpe@tools.ietf.org
>Cc: spring@ietf.org; nvo3@ietf.org; 6man WG; draft-ietf-6man-segment-<= br> >routing-header@tools.i= etf.org
>Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment- >routing-header
>
>Stefano,
>
>If I understand your point correctly:
>IPv6 segment routing does not work with VXLAN / VXLAN-GPE / Geneve, sin= ce
>these encapsulations do not currently allow the use of IPv6 extension >headers.
>
>I wonder if the authors of VXLAN-GPE and Geneve have considered the use= of
>segment routing.
>
>Thanks,
>Tal.
>
>
>
>>-----Original Message-----
>>From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
>>Sent: Tuesday, May 17, 2016 10:41 AM
>>To: Tom Herbert
>>Cc: Tal Mizrahi; 6man WG; spring= @ietf.org;
>>draft-ietf-6man-segment-routing- header@tools.ietf.org
>>Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routi= ng-
>>header
>>
>>
>>> On May 16, 2016, at 7:10 PM, Tom Herbert <tom@herbertland.com>
>wrote:
>>>
>>> On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi <talmi@marvell.com>
>>wrote:
>>>>> it=E2=80=99s all about IP, not layer-2.
>>>>>
>>>>> s.
>>>>
>>>> Right. However, it appears that at least in some cases a V= XLAN VTEP
>>>> will
>>use SR. It certainly may be the case in SFC use cases (see Section = 2.3
>>in draft- ietf-spring-ipv6-use-cases).
>>>>
>>>
>>> draft-ietf-6man-segment-routing-header mentions that the packe= t is
>>> encapsulated
>>
>>
>>into an outer ipv6 header which makes it a layer-3 encap.
>>
>>
>>> , but I don't think it is explicit as to exact encapsulati= on format
>>> (I suppose simple ip6ip6 is implied).
>>
>>
>>see section 2.2
>>
>>
>>> But, it
>>> seems like any of several encapsulation techniques could work = (VXLAN,
>>
>>
>>I have some problems to understand where to fit an extension header=
>>into a vxlan encap=E2=80=A6
>>
>>
>>> GRE/IP, ESP/IP, GUE, foo over UDP, etc.) and if a device that = wants
>>> to do SR is already doing tunneling it seems reasonable to me = to only
>>> have one layer of encapsulation. Maybe this should be clarifie= d in
>>> the draft?
>>
>>
>>the draft is about IPv6 extension header and more precisely a new t= ype
>>of the routing extension header defined in rfc2460. That=E2=80=99s = the context.
>>
>>
>>s.
>>
>>
>>
>>
>>>
>>> Tom
>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
>>>>> Sent: Monday, May 16, 2016 2:24 PM
>>>>> To: Tal Mizrahi
>>>>> Cc: Ole Tr=C3=B8an;
>>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org;
>>>>> spring@ietf.org= ; 6man WG
>>>>> Subject: Re: [spring] L4 Checksum and
>>>>> draft-ietf-6man-segment-routing- header
>>>>>
>>>>>
>>>>>> On May 16, 2016, at 1:19 PM, Tal Mizrahi <talmi@marvell.com> wrote:
>>>>>>
>>>>>> Hi Stefano,
>>>>>>
>>>>>> Thanks again for the prompt response.
>>>>>>
>>>>>>> 2. the SRH is originated by the ingress node o= f the SR domain.
>>>>>>> This is done by encapsulating the packet into = a outer
>>>>>>> (additional) ipv6 header followed by an SRH. T= his is L3
>>>>>>> encapsulation and no L4 checksum is involved. = When the=C2=A0 packet
>>>>>>> leaves the SR tunnel the outer encapsulation= =C2=A0 (including the SRH)
>>>>>>> is removed and the packet continues=C2=A0 its = journey like nothing
>happened.
>>>>>>
>>>>>> So VXLAN is off the table?
>>>>>
>>>>>
>>>>> it=E2=80=99s all about IP, not layer-2.
>>>>>
>>>>> s.
>>>>>
>>>>>
>>>>>> It would be worthwhile to clarify this in the draf= t. If you have a
>>>>>> specific
>>>>> encapsulation in mind, it would be great if the draft = would specify it.
>>>>>>
>>>>>> Thanks,
>>>>>> Tal.
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
>>>>>>> Sent: Monday, May 16, 2016 2:13 PM
>>>>>>> To: Tal Mizrahi
>>>>>>> Cc: Ole Tr=C3=B8an;
>>>>>>> draft-ietf-6man-segment-routing-header@tools.iet= f.org;
>>>>>>> spring@ietf= .org; 6man WG
>>>>>>> Subject: Re: [spring] L4 Checksum and
>>>>>>> draft-ietf-6man-segment-routing- header
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On May 16, 2016, at 11:04 AM, Tal Mizrahi <= talmi@marvell.com>
>>wrote:
>>>>>>>>
>>>>>>>> Hi Stefano,
>>>>>>>>
>>>>>>>> Thanks for the responses.
>>>>>>>>
>>>>>>>>> exactly.
>>>>>>>>>
>>>>>>>>> Moreover, draft-ietf-6man-segment-rout= ing-header assumes
>>>>>>>>> encapsulation so clearly there=E2=80= =99s no L4 involved here.
>>>>>>>>>
>>>>>>>>> s.
>>>>>>>>
>>>>>>>> Two questions:
>>>>>>>> 1. What if the encapsulation is VXLAN? L4 = would still be
>>>>>>>> involved,
>>right?
>>>>>>>
>>>>>>>
>>>>>>> See below.
>>>>>>>
>>>>>>>
>>>>>>>> 2. When you say 'assumes encapsulation= ', does it mean that a
>>>>>>>> host cannot
>>>>>>> send an IPv6 packet with an SRH? The current d= raft says:
>>>>>>>>
>>>>>>>> A Source SR Node can be any node originati= ng an IPv6 packet with
>>>>>>>> its
>>>>>>>> IPv6 and Segment Routing Headers.=C2=A0 Th= is include either:
>>>>>>>>
>>>>>>>>=C2=A0 =C2=A0 A host originating an IPv6 pa= cket.
>>>>>>>>
>>>>>>>>=C2=A0 =C2=A0 An SR domain ingress router e= ncapsulating a received IPv6 packet
>>>>>>>>=C2=A0 =C2=A0 into an outer IPv6 header fol= lowed by an SRH.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Will appreciate if you can clarify that. >>>>>>>
>>>>>>>
>>>>>>> ok, two cases:
>>>>>>>
>>>>>>> 1. the SRH is inserted at the source.
>>>>>>> the source originates the packet, the ipv6 hea= der and=C2=A0 the SRH.
>>>>>>> The source computes L4 checksum taking into=C2= =A0 account the whole
>>IPv6+SRH.
>>>>>>> Here, theres=E2=80=99 nothing new=C2=A0 compar= ed to rfc2460.
>>>>>>>
>>>>>>> 2. the SRH is originated by the ingress node o= f the SR domain.
>>>>>>> This is done by encapsulating the packet into = a outer
>>>>>>> (additional) ipv6 header followed by an SRH. T= his is L3
>>>>>>> encapsulation and no L4 checksum is involved. = When the=C2=A0 packet
>>>>>>> leaves the SR tunnel the outer encapsulation= =C2=A0 (including the SRH)
>>>>>>> is removed and the packet continues=C2=A0 its = journey like nothing
>happened.
>>>>>>>
>>>>>>> s.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Tal.
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Stefano Previdi (sprevidi) [mail= to:sprevidi@cisco.com]
>>>>>>>>> Sent: Monday, May 16, 2016 11:59 AM >>>>>>>>> To: Ole Tr=C3=B8an; Tal Mizrahi
>>>>>>>>> Cc: draft-ietf-6man-segment-routing-head= er@tools.ietf.org;
>>>>>>>>> spr= ing@ietf.org; 6man WG
>>>>>>>>> Subject: Re: [spring] L4 Checksum and<= br> >>>>>>>>> draft-ietf-6man-segment-routing- heade= r
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On May 15, 2016, at 8:06 PM, otroan@employees.org wrote:
>>>>>>>>>>
>>>>>>>>>> Tal,
>>>>>>>>>>
>>>>>>>>>>> [Apologies if this issue has b= een discussed before.]
>>>>>>>>>>>
>>>>>>>>>>> According to draft-ietf-6man-s= egment-routing-header, an =E2=80=98SR
>>>>>>>>>>> Segment
>>>>>>>>> Endpoint Node=E2=80=99 updates the Des= tination IP address.
>>>>>>>>>>> Therefore, it must also update= the Layer 4 Checksum, right?
>>>>>>>>>>>
>>>>>>>>>>> I wonder if there is an upper = bound on the size of the SRH.
>>>>>>>>>>> Otherwise, the
>>>>>>>>> L4 Checksum may be located in a pretty= deep location.
>>>>>>>>>>> Speaking from a chip vendor=E2= =80=99s perspective this may be a problem.
>>>>>>>>>>
>>>>>>>>>> From RFC2460, RH0:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>=C2=A0 =C2=A0o=C2=A0 If the IPv6 pa= cket contains a Routing header, the Destination
>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 Address used i= n the pseudo-header is that of the final
>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 destination.= =C2=A0 At the originating node, that address will be in
>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 the last eleme= nt of the Routing header; at the recipient(s),
>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 that address w= ill be in the Destination Address field of the
>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 IPv6 header. >>>>>>>>>>
>>>>>>>>>> I would expect SR would work the s= ame.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> exactly.
>>>>>>>>>
>>>>>>>>> Moreover, draft-ietf-6man-segment-rout= ing-header assumes
>>>>>>>>> encapsulation so clearly there=E2=80= =99s no L4 involved here.
>>>>>>>>>
>>>>>>>>> s.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Ole
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>> ----------------------------------------------------------= ----------
>>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
>>>> Requests: https://www.ietf.org/mailman/li= stinfo/ipv6
>>>> ----------------------------------------------------------= ----------
>
>_______________________________________________
>nvo3 mailing list
>nvo3@ietf.org
>https://www.ietf.org/mailman/listinfo/nvo3
_______________________= ________________________
spring mailing list
spring@ietf.org
https://www.ietf.org/mailman/listinfo/spring

--001a1140677637ee3c05337d65c8-- From nobody Mon May 23 00:35:21 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BF9612D567; Mon, 23 May 2016 00:35:17 -0700 (PDT) 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 xO9Pt7FwYQnR; Mon, 23 May 2016 00:35:10 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (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 82A9812B032; Mon, 23 May 2016 00:35:10 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u4N7VJ1v017327; Mon, 23 May 2016 00:35:09 -0700 Received: from il-exch02.marvell.com ([199.203.130.102]) by mx0b-0016f401.pphosted.com with ESMTP id 232q6e4vap-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 23 May 2016 00:35:08 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH02.marvell.com (10.4.102.221) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 23 May 2016 10:35:05 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Mon, 23 May 2016 10:35:05 +0300 From: Tal Mizrahi To: Robert Raszuk Thread-Topic: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routing-header Thread-Index: AQHRtMThJCvw5mf6XUe954CmH3IV2Z/GIJVA Date: Mon, 23 May 2016 07:35:04 +0000 Message-ID: References: <5dc56935eba94c2390120244564f9b21@IL-EXCH02.marvell.com> <0551686F-F1D2-4C34-81C8-530F1BEE1BDF@cisco.com> <5d889e7013b44b27ae1e75cf7ea2dd22@IL-EXCH02.marvell.com> <3549ABBE-9828-42D2-A056-851432487E2E@cisco.com> <1e13d2e32b2448af94bf23d5acf17740@IL-EXCH02.marvell.com> <569a4067fd1f45dd85d60e983be69b90@IL-EXCH02.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: multipart/alternative; boundary="_000_bb99730deb8348bcac4f5c433e88d435ILEXCH02marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-23_02:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1605230091 Archived-At: Cc: "spring@ietf.org" , 6man WG , "draft-ietf-nvo3-vxlan-gpe@tools.ietf.org" , "nvo3@ietf.org" , "draft-ietf-6man-segment-routing-header@tools.ietf.org" , "draft-ietf-nvo3-geneve@tools.ietf.org" , "Stefano Previdi \(sprevidi\)" Subject: Re: [spring] [nvo3] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 07:35:17 -0000 --_000_bb99730deb8348bcac4f5c433e88d435ILEXCH02marvellcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQoNCj4gV2hlcmUgc2F5IGluIGRyYWZ0IGRyYWZ0LXF1aW5uLXZ4bGFuLWdw ZSBkbyB5b3Ugc2VlIHN1Y2ggc3RhdGVtZW50IHRoYXQgd291bGQgaW1wbHkNCj4gdGhhdCB2NiBO eHRIZHIgbXVzdCBiZSBvbmx5IGVxdWFsIHRvIDE3IChVRFApIGFuZCBub3QgYmUgYSBwb2ludGVy IHRvIGFueSBvdGhlciB0eXBlDQo+IG9mIGV4dGVuc2lvbiBoZWFkZXIgZnVydGhlciBmb2xsb3dl ZCBieSBVRFAgPw0KDQoNClRoZSBmb2xsb3dpbmcgdGV4dCBpcyBmcm9tIEZpZ3VyZSA0IGluIGRy YWZ0LWlldGYtbnZvMy12eGxhbi1ncGU6DQoNCiAgICAgIE91dGVyIElQdjYgSGVhZGVyOg0KICAg ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCiAgICAgIHxWZXJzaW9ufCBUcmFmZmljIENsYXNzIHwgICAgICAgICAgIEZs b3cgTGFiZWwgICAgICAgICAgICAgICAgICB8DQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgfCAgICAg ICAgIFBheWxvYWQgTGVuZ3RoICAgICAgICB8IE54dEhkcj0xNyhVRFApfCAgIEhvcCBMaW1pdCAg IHwNCiAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KDQoNClRoZXJlIGlzIGEgc2ltaWxh ciBmaWd1cmUgaW4gZHJhZnQtaWV0Zi1udm8zLWdlbmV2ZS4NCg0KQmVzdCByZWdhcmRzLA0KVGFs Lg0KDQpGcm9tOiBudm8zIFttYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgUm9iZXJ0IFJhc3p1aw0KU2VudDogTW9uZGF5LCBNYXkgMjMsIDIwMTYgMTA6MjkgQU0NClRv OiBUYWwgTWl6cmFoaQ0KQ2M6IHNwcmluZ0BpZXRmLm9yZzsgNm1hbiBXRzsgZHJhZnQtaWV0Zi1u dm8zLXZ4bGFuLWdwZUB0b29scy5pZXRmLm9yZzsgbnZvM0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi02 bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbnZv My1nZW5ldmVAdG9vbHMuaWV0Zi5vcmc7IFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpDQpTdWJq ZWN0OiBSZTogW252bzNdIFtzcHJpbmddIEw0IENoZWNrc3VtIGFuZCBkcmFmdC1pZXRmLTZtYW4t c2VnbWVudC1yb3V0aW5nLWhlYWRlcg0KDQpIaSBUYWwsDQoNCj4gZHJhZnRzIHNlZW0gdG8gaW1w bHkNCg0KV2hlcmUgc2F5IGluIGRyYWZ0IGRyYWZ0LXF1aW5uLXZ4bGFuLWdwZSBkbyB5b3Ugc2Vl IHN1Y2ggc3RhdGVtZW50IHRoYXQgd291bGQgaW1wbHkgdGhhdCB2NiBOeHRIZHIgbXVzdCBiZSBv bmx5IGVxdWFsIHRvIDE3IChVRFApIGFuZCBub3QgYmUgYSBwb2ludGVyIHRvIGFueSBvdGhlciB0 eXBlIG9mIGV4dGVuc2lvbiBoZWFkZXIgZnVydGhlciBmb2xsb3dlZCBieSBVRFAgPw0KDQpUaHgs DQpSLg0KDQoNCk9uIE1vbiwgTWF5IDIzLCAyMDE2IGF0IDc6NTAgQU0sIFRhbCBNaXpyYWhpIDx0 YWxtaUBtYXJ2ZWxsLmNvbTxtYWlsdG86dGFsbWlAbWFydmVsbC5jb20+PiB3cm90ZToNCkRlYXIg QXV0aG9ycyBvZiBWWExBTi1HUEUgLyBHZW5ldmUsDQoNCkkgYW0gcmVpdGVyYXRpbmcgb24gdGhp cyBxdWVzdGlvbiwgYXMgSSBoYXZlbid0IHNlZW4gYSByZXNwb25zZSB5ZXQ6DQoNCkhhdmUgeW91 IGNvbnNpZGVyZWQgdGhlIHVzZSBvZiBTZWdtZW50IFJvdXRpbmcgd2l0aCBWWExBTi1HUEUgLyBH ZW5ldmU/IFRoZSBjdXJyZW50IFZYTEFOLUdQRSAvIEdlbmV2ZSBkcmFmdHMgc2VlbSB0byBpbXBs eSB0aGF0IElQdjYgZXh0ZW5zaW9uIGhlYWRlcnMgYXJlIGN1cnJlbnRseSBub3Qgc3VwcG9ydGVk Lg0KDQpUaGFua3MsDQpUYWwuDQoNCg0KDQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5G cm9tOiBudm8zIFttYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpudm8zLWJvdW5j ZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgVGFsIE1penJhaGkNCj5TZW50OiBUdWVzZGF5LCBN YXkgMTcsIDIwMTYgMTI6MDkgUE0NCj5UbzogU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSk7IFRv bSBIZXJiZXJ0OyBkcmFmdC1pZXRmLW52bzMtDQo+Z2VuZXZlQHRvb2xzLmlldGYub3JnPG1haWx0 bzpnZW5ldmVAdG9vbHMuaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLW52bzMtdnhsYW4tZ3BlQHRvb2xz LmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW52bzMtdnhsYW4tZ3BlQHRvb2xzLmlldGYub3Jn Pg0KPkNjOiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz47IG52bzNAaWV0 Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+OyA2bWFuIFdHOyBkcmFmdC1pZXRmLTZtYW4tc2Vn bWVudC0NCj5yb3V0aW5nLWhlYWRlckB0b29scy5pZXRmLm9yZzxtYWlsdG86cm91dGluZy1oZWFk ZXJAdG9vbHMuaWV0Zi5vcmc+DQo+U3ViamVjdDogUmU6IFtudm8zXSBbc3ByaW5nXSBMNCBDaGVj a3N1bSBhbmQgZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtDQo+cm91dGluZy1oZWFkZXINCj4NCj5T dGVmYW5vLA0KPg0KPklmIEkgdW5kZXJzdGFuZCB5b3VyIHBvaW50IGNvcnJlY3RseToNCj5JUHY2 IHNlZ21lbnQgcm91dGluZyBkb2VzIG5vdCB3b3JrIHdpdGggVlhMQU4gLyBWWExBTi1HUEUgLyBH ZW5ldmUsIHNpbmNlDQo+dGhlc2UgZW5jYXBzdWxhdGlvbnMgZG8gbm90IGN1cnJlbnRseSBhbGxv dyB0aGUgdXNlIG9mIElQdjYgZXh0ZW5zaW9uDQo+aGVhZGVycy4NCj4NCj5JIHdvbmRlciBpZiB0 aGUgYXV0aG9ycyBvZiBWWExBTi1HUEUgYW5kIEdlbmV2ZSBoYXZlIGNvbnNpZGVyZWQgdGhlIHVz ZSBvZg0KPnNlZ21lbnQgcm91dGluZy4NCj4NCj5UaGFua3MsDQo+VGFsLg0KPg0KPg0KPg0KPj4t LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj5Gcm9tOiBTdGVmYW5vIFByZXZpZGkgKHNwcmV2 aWRpKSBbbWFpbHRvOnNwcmV2aWRpQGNpc2NvLmNvbTxtYWlsdG86c3ByZXZpZGlAY2lzY28uY29t Pl0NCj4+U2VudDogVHVlc2RheSwgTWF5IDE3LCAyMDE2IDEwOjQxIEFNDQo+PlRvOiBUb20gSGVy YmVydA0KPj5DYzogVGFsIE1penJhaGk7IDZtYW4gV0c7IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86 c3ByaW5nQGlldGYub3JnPjsNCj4+ZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy0gaGVh ZGVyQHRvb2xzLmlldGYub3JnPG1haWx0bzpoZWFkZXJAdG9vbHMuaWV0Zi5vcmc+DQo+PlN1Ympl Y3Q6IFJlOiBbc3ByaW5nXSBMNCBDaGVja3N1bSBhbmQgZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQt cm91dGluZy0NCj4+aGVhZGVyDQo+Pg0KPj4NCj4+PiBPbiBNYXkgMTYsIDIwMTYsIGF0IDc6MTAg UE0sIFRvbSBIZXJiZXJ0IDx0b21AaGVyYmVydGxhbmQuY29tPG1haWx0bzp0b21AaGVyYmVydGxh bmQuY29tPj4NCj53cm90ZToNCj4+Pg0KPj4+IE9uIE1vbiwgTWF5IDE2LCAyMDE2IGF0IDQ6MzIg QU0sIFRhbCBNaXpyYWhpIDx0YWxtaUBtYXJ2ZWxsLmNvbTxtYWlsdG86dGFsbWlAbWFydmVsbC5j b20+Pg0KPj53cm90ZToNCj4+Pj4+IGl04oCZcyBhbGwgYWJvdXQgSVAsIG5vdCBsYXllci0yLg0K Pj4+Pj4NCj4+Pj4+IHMuDQo+Pj4+DQo+Pj4+IFJpZ2h0LiBIb3dldmVyLCBpdCBhcHBlYXJzIHRo YXQgYXQgbGVhc3QgaW4gc29tZSBjYXNlcyBhIFZYTEFOIFZURVANCj4+Pj4gd2lsbA0KPj51c2Ug U1IuIEl0IGNlcnRhaW5seSBtYXkgYmUgdGhlIGNhc2UgaW4gU0ZDIHVzZSBjYXNlcyAoc2VlIFNl Y3Rpb24gMi4zDQo+PmluIGRyYWZ0LSBpZXRmLXNwcmluZy1pcHY2LXVzZS1jYXNlcykuDQo+Pj4+ DQo+Pj4NCj4+PiBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlciBtZW50aW9u cyB0aGF0IHRoZSBwYWNrZXQgaXMNCj4+PiBlbmNhcHN1bGF0ZWQNCj4+DQo+Pg0KPj5pbnRvIGFu IG91dGVyIGlwdjYgaGVhZGVyIHdoaWNoIG1ha2VzIGl0IGEgbGF5ZXItMyBlbmNhcC4NCj4+DQo+ Pg0KPj4+ICwgYnV0IEkgZG9uJ3QgdGhpbmsgaXQgaXMgZXhwbGljaXQgYXMgdG8gZXhhY3QgZW5j YXBzdWxhdGlvbiBmb3JtYXQNCj4+PiAoSSBzdXBwb3NlIHNpbXBsZSBpcDZpcDYgaXMgaW1wbGll ZCkuDQo+Pg0KPj4NCj4+c2VlIHNlY3Rpb24gMi4yDQo+Pg0KPj4NCj4+PiBCdXQsIGl0DQo+Pj4g c2VlbXMgbGlrZSBhbnkgb2Ygc2V2ZXJhbCBlbmNhcHN1bGF0aW9uIHRlY2huaXF1ZXMgY291bGQg d29yayAoVlhMQU4sDQo+Pg0KPj4NCj4+SSBoYXZlIHNvbWUgcHJvYmxlbXMgdG8gdW5kZXJzdGFu ZCB3aGVyZSB0byBmaXQgYW4gZXh0ZW5zaW9uIGhlYWRlcg0KPj5pbnRvIGEgdnhsYW4gZW5jYXDi gKYNCj4+DQo+Pg0KPj4+IEdSRS9JUCwgRVNQL0lQLCBHVUUsIGZvbyBvdmVyIFVEUCwgZXRjLikg YW5kIGlmIGEgZGV2aWNlIHRoYXQgd2FudHMNCj4+PiB0byBkbyBTUiBpcyBhbHJlYWR5IGRvaW5n IHR1bm5lbGluZyBpdCBzZWVtcyByZWFzb25hYmxlIHRvIG1lIHRvIG9ubHkNCj4+PiBoYXZlIG9u ZSBsYXllciBvZiBlbmNhcHN1bGF0aW9uLiBNYXliZSB0aGlzIHNob3VsZCBiZSBjbGFyaWZpZWQg aW4NCj4+PiB0aGUgZHJhZnQ/DQo+Pg0KPj4NCj4+dGhlIGRyYWZ0IGlzIGFib3V0IElQdjYgZXh0 ZW5zaW9uIGhlYWRlciBhbmQgbW9yZSBwcmVjaXNlbHkgYSBuZXcgdHlwZQ0KPj5vZiB0aGUgcm91 dGluZyBleHRlbnNpb24gaGVhZGVyIGRlZmluZWQgaW4gcmZjMjQ2MC4gVGhhdOKAmXMgdGhlIGNv bnRleHQuDQo+Pg0KPj4NCj4+cy4NCj4+DQo+Pg0KPj4NCj4+DQo+Pj4NCj4+PiBUb20NCj4+Pg0K Pj4+Pg0KPj4+Pg0KPj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+IEZyb206 IFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpIFttYWlsdG86c3ByZXZpZGlAY2lzY28uY29tPG1h aWx0bzpzcHJldmlkaUBjaXNjby5jb20+XQ0KPj4+Pj4gU2VudDogTW9uZGF5LCBNYXkgMTYsIDIw MTYgMjoyNCBQTQ0KPj4+Pj4gVG86IFRhbCBNaXpyYWhpDQo+Pj4+PiBDYzogT2xlIFRyw7hhbjsN Cj4+Pj4+IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyQHRvb2xzLmlldGYu b3JnPG1haWx0bzpkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlckB0b29scy5p ZXRmLm9yZz47DQo+Pj4+PiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz47 IDZtYW4gV0cNCj4+Pj4+IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBMNCBDaGVja3N1bSBhbmQNCj4+ Pj4+IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctIGhlYWRlcg0KPj4+Pj4NCj4+Pj4+ DQo+Pj4+Pj4gT24gTWF5IDE2LCAyMDE2LCBhdCAxOjE5IFBNLCBUYWwgTWl6cmFoaSA8dGFsbWlA bWFydmVsbC5jb208bWFpbHRvOnRhbG1pQG1hcnZlbGwuY29tPj4gd3JvdGU6DQo+Pj4+Pj4NCj4+ Pj4+PiBIaSBTdGVmYW5vLA0KPj4+Pj4+DQo+Pj4+Pj4gVGhhbmtzIGFnYWluIGZvciB0aGUgcHJv bXB0IHJlc3BvbnNlLg0KPj4+Pj4+DQo+Pj4+Pj4+IDIuIHRoZSBTUkggaXMgb3JpZ2luYXRlZCBi eSB0aGUgaW5ncmVzcyBub2RlIG9mIHRoZSBTUiBkb21haW4uDQo+Pj4+Pj4+IFRoaXMgaXMgZG9u ZSBieSBlbmNhcHN1bGF0aW5nIHRoZSBwYWNrZXQgaW50byBhIG91dGVyDQo+Pj4+Pj4+IChhZGRp dGlvbmFsKSBpcHY2IGhlYWRlciBmb2xsb3dlZCBieSBhbiBTUkguIFRoaXMgaXMgTDMNCj4+Pj4+ Pj4gZW5jYXBzdWxhdGlvbiBhbmQgbm8gTDQgY2hlY2tzdW0gaXMgaW52b2x2ZWQuIFdoZW4gdGhl ICBwYWNrZXQNCj4+Pj4+Pj4gbGVhdmVzIHRoZSBTUiB0dW5uZWwgdGhlIG91dGVyIGVuY2Fwc3Vs YXRpb24gIChpbmNsdWRpbmcgdGhlIFNSSCkNCj4+Pj4+Pj4gaXMgcmVtb3ZlZCBhbmQgdGhlIHBh Y2tldCBjb250aW51ZXMgIGl0cyBqb3VybmV5IGxpa2Ugbm90aGluZw0KPmhhcHBlbmVkLg0KPj4+ Pj4+DQo+Pj4+Pj4gU28gVlhMQU4gaXMgb2ZmIHRoZSB0YWJsZT8NCj4+Pj4+DQo+Pj4+Pg0KPj4+ Pj4gaXTigJlzIGFsbCBhYm91dCBJUCwgbm90IGxheWVyLTIuDQo+Pj4+Pg0KPj4+Pj4gcy4NCj4+ Pj4+DQo+Pj4+Pg0KPj4+Pj4+IEl0IHdvdWxkIGJlIHdvcnRod2hpbGUgdG8gY2xhcmlmeSB0aGlz IGluIHRoZSBkcmFmdC4gSWYgeW91IGhhdmUgYQ0KPj4+Pj4+IHNwZWNpZmljDQo+Pj4+PiBlbmNh cHN1bGF0aW9uIGluIG1pbmQsIGl0IHdvdWxkIGJlIGdyZWF0IGlmIHRoZSBkcmFmdCB3b3VsZCBz cGVjaWZ5IGl0Lg0KPj4+Pj4+DQo+Pj4+Pj4gVGhhbmtzLA0KPj4+Pj4+IFRhbC4NCj4+Pj4+Pg0K Pj4+Pj4+DQo+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+IEZyb206 IFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpIFttYWlsdG86c3ByZXZpZGlAY2lzY28uY29tPG1h aWx0bzpzcHJldmlkaUBjaXNjby5jb20+XQ0KPj4+Pj4+PiBTZW50OiBNb25kYXksIE1heSAxNiwg MjAxNiAyOjEzIFBNDQo+Pj4+Pj4+IFRvOiBUYWwgTWl6cmFoaQ0KPj4+Pj4+PiBDYzogT2xlIFRy w7hhbjsNCj4+Pj4+Pj4gZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXJAdG9v bHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVy QHRvb2xzLmlldGYub3JnPjsNCj4+Pj4+Pj4gc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdA aWV0Zi5vcmc+OyA2bWFuIFdHDQo+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBMNCBDaGVj a3N1bSBhbmQNCj4+Pj4+Pj4gZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy0gaGVhZGVy DQo+Pj4+Pj4+DQo+Pj4+Pj4+IEhpLA0KPj4+Pj4+Pg0KPj4+Pj4+PiBPbiBNYXkgMTYsIDIwMTYs IGF0IDExOjA0IEFNLCBUYWwgTWl6cmFoaSA8dGFsbWlAbWFydmVsbC5jb208bWFpbHRvOnRhbG1p QG1hcnZlbGwuY29tPj4NCj4+d3JvdGU6DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gSGkgU3RlZmFubywN Cj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaGFua3MgZm9yIHRoZSByZXNwb25zZXMuDQo+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+IGV4YWN0bHkuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBNb3Jlb3ZlciwgZHJhZnQt aWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXIgYXNzdW1lcw0KPj4+Pj4+Pj4+IGVuY2Fw c3VsYXRpb24gc28gY2xlYXJseSB0aGVyZeKAmXMgbm8gTDQgaW52b2x2ZWQgaGVyZS4NCj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+IHMuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gVHdvIHF1ZXN0aW9uczoNCj4+ Pj4+Pj4+IDEuIFdoYXQgaWYgdGhlIGVuY2Fwc3VsYXRpb24gaXMgVlhMQU4/IEw0IHdvdWxkIHN0 aWxsIGJlDQo+Pj4+Pj4+PiBpbnZvbHZlZCwNCj4+cmlnaHQ/DQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+ Pj4+Pj4+IFNlZSBiZWxvdy4NCj4+Pj4+Pj4NCj4+Pj4+Pj4NCj4+Pj4+Pj4+IDIuIFdoZW4geW91 IHNheSAnYXNzdW1lcyBlbmNhcHN1bGF0aW9uJywgZG9lcyBpdCBtZWFuIHRoYXQgYQ0KPj4+Pj4+ Pj4gaG9zdCBjYW5ub3QNCj4+Pj4+Pj4gc2VuZCBhbiBJUHY2IHBhY2tldCB3aXRoIGFuIFNSSD8g VGhlIGN1cnJlbnQgZHJhZnQgc2F5czoNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBBIFNvdXJjZSBTUiBO b2RlIGNhbiBiZSBhbnkgbm9kZSBvcmlnaW5hdGluZyBhbiBJUHY2IHBhY2tldCB3aXRoDQo+Pj4+ Pj4+PiBpdHMNCj4+Pj4+Pj4+IElQdjYgYW5kIFNlZ21lbnQgUm91dGluZyBIZWFkZXJzLiAgVGhp cyBpbmNsdWRlIGVpdGhlcjoNCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiAgICBBIGhvc3Qgb3JpZ2luYXRp bmcgYW4gSVB2NiBwYWNrZXQuDQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gICAgQW4gU1IgZG9tYWluIGlu Z3Jlc3Mgcm91dGVyIGVuY2Fwc3VsYXRpbmcgYSByZWNlaXZlZCBJUHY2IHBhY2tldA0KPj4+Pj4+ Pj4gICAgaW50byBhbiBvdXRlciBJUHY2IGhlYWRlciBmb2xsb3dlZCBieSBhbiBTUkguDQo+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBXaWxsIGFwcHJlY2lhdGUgaWYgeW91 IGNhbiBjbGFyaWZ5IHRoYXQuDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+IG9rLCB0d28gY2Fz ZXM6DQo+Pj4+Pj4+DQo+Pj4+Pj4+IDEuIHRoZSBTUkggaXMgaW5zZXJ0ZWQgYXQgdGhlIHNvdXJj ZS4NCj4+Pj4+Pj4gdGhlIHNvdXJjZSBvcmlnaW5hdGVzIHRoZSBwYWNrZXQsIHRoZSBpcHY2IGhl YWRlciBhbmQgIHRoZSBTUkguDQo+Pj4+Pj4+IFRoZSBzb3VyY2UgY29tcHV0ZXMgTDQgY2hlY2tz dW0gdGFraW5nIGludG8gIGFjY291bnQgdGhlIHdob2xlDQo+PklQdjYrU1JILg0KPj4+Pj4+PiBI ZXJlLCB0aGVyZXPigJkgbm90aGluZyBuZXcgIGNvbXBhcmVkIHRvIHJmYzI0NjAuDQo+Pj4+Pj4+ DQo+Pj4+Pj4+IDIuIHRoZSBTUkggaXMgb3JpZ2luYXRlZCBieSB0aGUgaW5ncmVzcyBub2RlIG9m IHRoZSBTUiBkb21haW4uDQo+Pj4+Pj4+IFRoaXMgaXMgZG9uZSBieSBlbmNhcHN1bGF0aW5nIHRo ZSBwYWNrZXQgaW50byBhIG91dGVyDQo+Pj4+Pj4+IChhZGRpdGlvbmFsKSBpcHY2IGhlYWRlciBm b2xsb3dlZCBieSBhbiBTUkguIFRoaXMgaXMgTDMNCj4+Pj4+Pj4gZW5jYXBzdWxhdGlvbiBhbmQg bm8gTDQgY2hlY2tzdW0gaXMgaW52b2x2ZWQuIFdoZW4gdGhlICBwYWNrZXQNCj4+Pj4+Pj4gbGVh dmVzIHRoZSBTUiB0dW5uZWwgdGhlIG91dGVyIGVuY2Fwc3VsYXRpb24gIChpbmNsdWRpbmcgdGhl IFNSSCkNCj4+Pj4+Pj4gaXMgcmVtb3ZlZCBhbmQgdGhlIHBhY2tldCBjb250aW51ZXMgIGl0cyBq b3VybmV5IGxpa2Ugbm90aGluZw0KPmhhcHBlbmVkLg0KPj4+Pj4+Pg0KPj4+Pj4+PiBzLg0KPj4+ Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFRoYW5rcywNCj4+Pj4+Pj4+IFRhbC4N Cj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+Pj4+Pj4+ PiBGcm9tOiBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKSBbbWFpbHRvOnNwcmV2aWRpQGNpc2Nv LmNvbTxtYWlsdG86c3ByZXZpZGlAY2lzY28uY29tPl0NCj4+Pj4+Pj4+PiBTZW50OiBNb25kYXks IE1heSAxNiwgMjAxNiAxMTo1OSBBTQ0KPj4+Pj4+Pj4+IFRvOiBPbGUgVHLDuGFuOyBUYWwgTWl6 cmFoaQ0KPj4+Pj4+Pj4+IENjOiBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRl ckB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1o ZWFkZXJAdG9vbHMuaWV0Zi5vcmc+Ow0KPj4+Pj4+Pj4+IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86 c3ByaW5nQGlldGYub3JnPjsgNm1hbiBXRw0KPj4+Pj4+Pj4+IFN1YmplY3Q6IFJlOiBbc3ByaW5n XSBMNCBDaGVja3N1bSBhbmQNCj4+Pj4+Pj4+PiBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0 aW5nLSBoZWFkZXINCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IE9uIE1heSAxNSwg MjAxNiwgYXQgODowNiBQTSwgb3Ryb2FuQGVtcGxveWVlcy5vcmc8bWFpbHRvOm90cm9hbkBlbXBs b3llZXMub3JnPiB3cm90ZToNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gVGFsLA0KPj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+Pj4gW0Fwb2xvZ2llcyBpZiB0aGlzIGlzc3VlIGhhcyBiZWVuIGRpc2N1c3Nl ZCBiZWZvcmUuXQ0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IEFjY29yZGluZyB0byBkcmFmdC1p ZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlciwgYW4g4oCYU1INCj4+Pj4+Pj4+Pj4+IFNl Z21lbnQNCj4+Pj4+Pj4+PiBFbmRwb2ludCBOb2Rl4oCZIHVwZGF0ZXMgdGhlIERlc3RpbmF0aW9u IElQIGFkZHJlc3MuDQo+Pj4+Pj4+Pj4+PiBUaGVyZWZvcmUsIGl0IG11c3QgYWxzbyB1cGRhdGUg dGhlIExheWVyIDQgQ2hlY2tzdW0sIHJpZ2h0Pw0KPj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4+IEkg d29uZGVyIGlmIHRoZXJlIGlzIGFuIHVwcGVyIGJvdW5kIG9uIHRoZSBzaXplIG9mIHRoZSBTUkgu DQo+Pj4+Pj4+Pj4+PiBPdGhlcndpc2UsIHRoZQ0KPj4+Pj4+Pj4+IEw0IENoZWNrc3VtIG1heSBi ZSBsb2NhdGVkIGluIGEgcHJldHR5IGRlZXAgbG9jYXRpb24uDQo+Pj4+Pj4+Pj4+PiBTcGVha2lu ZyBmcm9tIGEgY2hpcCB2ZW5kb3LigJlzIHBlcnNwZWN0aXZlIHRoaXMgbWF5IGJlIGEgcHJvYmxl bS4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4gRnJvbSBSRkMyNDYwLCBSSDA6DQo+Pj4+Pj4+Pj4+ DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+ICAgbyAgSWYgdGhlIElQdjYgcGFja2V0IGNvbnRhaW5z IGEgUm91dGluZyBoZWFkZXIsIHRoZSBEZXN0aW5hdGlvbg0KPj4+Pj4+Pj4+PiAgICAgIEFkZHJl c3MgdXNlZCBpbiB0aGUgcHNldWRvLWhlYWRlciBpcyB0aGF0IG9mIHRoZSBmaW5hbA0KPj4+Pj4+ Pj4+PiAgICAgIGRlc3RpbmF0aW9uLiAgQXQgdGhlIG9yaWdpbmF0aW5nIG5vZGUsIHRoYXQgYWRk cmVzcyB3aWxsIGJlIGluDQo+Pj4+Pj4+Pj4+ICAgICAgdGhlIGxhc3QgZWxlbWVudCBvZiB0aGUg Um91dGluZyBoZWFkZXI7IGF0IHRoZSByZWNpcGllbnQocyksDQo+Pj4+Pj4+Pj4+ICAgICAgdGhh dCBhZGRyZXNzIHdpbGwgYmUgaW4gdGhlIERlc3RpbmF0aW9uIEFkZHJlc3MgZmllbGQgb2YgdGhl DQo+Pj4+Pj4+Pj4+ICAgICAgSVB2NiBoZWFkZXIuDQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEkg d291bGQgZXhwZWN0IFNSIHdvdWxkIHdvcmsgdGhlIHNhbWUuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+IGV4YWN0bHkuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+PiBNb3Jlb3ZlciwgZHJh ZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXIgYXNzdW1lcw0KPj4+Pj4+Pj4+IGVu Y2Fwc3VsYXRpb24gc28gY2xlYXJseSB0aGVyZeKAmXMgbm8gTDQgaW52b2x2ZWQgaGVyZS4NCj4+ Pj4+Pj4+Pg0KPj4+Pj4+Pj4+IHMuDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+Pg0K Pj4+Pj4+Pj4+PiBDaGVlcnMsDQo+Pj4+Pj4+Pj4+IE9sZQ0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4N Cj4+Pj4+Pg0KPj4+Pg0KPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+PiBJRVRGIElQdjYgd29ya2luZyBn cm91cCBtYWlsaW5nIGxpc3QgaXB2NkBpZXRmLm9yZzxtYWlsdG86aXB2NkBpZXRmLm9yZz4gQWRt aW5pc3RyYXRpdmUNCj4+Pj4gUmVxdWVzdHM6IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vaXB2Ng0KPj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bnZvMyBtYWlsaW5nIGxpc3QNCj5udm8zQGll dGYub3JnPG1haWx0bzpudm8zQGlldGYub3JnPg0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbnZvMw0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3By aW5nQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJp bmcNCg0K --_000_bb99730deb8348bcac4f5c433e88d435ILEXCH02marvellcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4w cHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFJvYmVy dCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7PC9z cGFuPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPldoZXJlIHNh eSBpbiBkcmFmdCBkcmFmdC1xdWlubi12eGxhbi1ncGUgZG8geW91IHNlZSBzdWNoIHN0YXRlbWVu dCB0aGF0IHdvdWxkIGltcGx5DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0OyB0 aGF0IHY2IE54dEhkciBtdXN0IGJlIG9ubHkgZXF1YWwgdG8gMTcgKFVEUCkgYW5kIG5vdCBiZSBh IHBvaW50ZXIgdG8gYW55IG90aGVyIHR5cGUNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mZ3Q7IG9mIGV4dGVuc2lvbiBoZWFkZXIgZnVydGhlciBmb2xsb3dlZCBieSBVRFAgPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBmb2xsb3dpbmcg dGV4dCBpcyBmcm9tIEZpZ3VyZSA0IGluIGRyYWZ0LWlldGYtbnZvMy12eGxhbi1ncGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBPdXRlciBJUHY2IEhlYWRlcjo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfFZlcnNpb258IFRyYWZmaWMgQ2xhc3Mg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBGbG93IExhYmVsJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0Mzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQYXls b2FkIExlbmd0aCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IE54 dEhkcj0xNyhVRFApfCZuYnNwOyZuYnNwOyBIb3AgTGltaXQmbmJzcDsmbmJzcDsgfDxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQz Oy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0mIzQzOy0m IzQzOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO3w8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5UaGVyZSBpcyBhIHNpbWlsYXIgZmlndXJlIGluIGRyYWZ0LWlldGYtbnZv My1nZW5ldmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlRhbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g bnZvMyBbbWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ Um9iZXJ0IFJhc3p1azxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1heSAyMywgMjAxNiAxMDoy OSBBTTxicj4NCjxiPlRvOjwvYj4gVGFsIE1penJhaGk8YnI+DQo8Yj5DYzo8L2I+IHNwcmluZ0Bp ZXRmLm9yZzsgNm1hbiBXRzsgZHJhZnQtaWV0Zi1udm8zLXZ4bGFuLWdwZUB0b29scy5pZXRmLm9y ZzsgbnZvM0BpZXRmLm9yZzsgZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXJA dG9vbHMuaWV0Zi5vcmc7IGRyYWZ0LWlldGYtbnZvMy1nZW5ldmVAdG9vbHMuaWV0Zi5vcmc7IFN0 ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbnZvM10g W3NwcmluZ10gTDQgQ2hlY2tzdW0gYW5kIGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmct aGVhZGVyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGkgVGFsLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jmd0OyZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmRyYWZ0cyBzZWVt IHRvIGltcGx5PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PldoZXJlIHNheSBpbiBkcmFmdCZuYnNwO2RyYWZ0LXF1aW5uLXZ4bGFuLWdwZSBkbyB5b3Ugc2Vl IHN1Y2ggc3RhdGVtZW50IHRoYXQgd291bGQgaW1wbHkgdGhhdCB2NiBOeHRIZHIgbXVzdCBiZSBv bmx5IGVxdWFsIHRvIDE3IChVRFApIGFuZCBub3QgYmUgYSBwb2ludGVyIHRvIGFueSBvdGhlciB0 eXBlIG9mIGV4dGVuc2lvbiBoZWFkZXINCiBmdXJ0aGVyIGZvbGxvd2VkIGJ5IFVEUCA/Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaHgsPGJyPg0KUi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBNb24sIE1heSAyMywgMjAxNiBhdCA3OjUwIEFNLCBUYWwgTWl6cmFoaSAm bHQ7PGEgaHJlZj0ibWFpbHRvOnRhbG1pQG1hcnZlbGwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGFs bWlAbWFydmVsbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkRlYXIgQXV0aG9ycyBvZiBWWExBTi1HUEUgLyBHZW5ldmUsPGJyPg0KPGJyPg0K SSBhbSByZWl0ZXJhdGluZyBvbiB0aGlzIHF1ZXN0aW9uLCBhcyBJIGhhdmVuJ3Qgc2VlbiBhIHJl c3BvbnNlIHlldDo8YnI+DQo8YnI+DQpIYXZlIHlvdSBjb25zaWRlcmVkIHRoZSB1c2Ugb2YgU2Vn bWVudCBSb3V0aW5nIHdpdGggVlhMQU4tR1BFIC8gR2VuZXZlPyBUaGUgY3VycmVudCBWWExBTi1H UEUgLyBHZW5ldmUgZHJhZnRzIHNlZW0gdG8gaW1wbHkgdGhhdCBJUHY2IGV4dGVuc2lvbiBoZWFk ZXJzIGFyZSBjdXJyZW50bHkgbm90IHN1cHBvcnRlZC48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0K VGFsLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 YnI+DQo8YnI+DQo8YnI+DQomZ3Q7LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7 RnJvbTogbnZvMyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5vcmci Pm52bzMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBUYWwgTWl6cmFoaTxicj4N CiZndDtTZW50OiBUdWVzZGF5LCBNYXkgMTcsIDIwMTYgMTI6MDkgUE08YnI+DQomZ3Q7VG86IFN0 ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpOyBUb20gSGVyYmVydDsgZHJhZnQtaWV0Zi1udm8zLTxi cj4NCiZndDs8YSBocmVmPSJtYWlsdG86Z2VuZXZlQHRvb2xzLmlldGYub3JnIj5nZW5ldmVAdG9v bHMuaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1udm8zLXZ4bGFuLWdw ZUB0b29scy5pZXRmLm9yZyI+DQpkcmFmdC1pZXRmLW52bzMtdnhsYW4tZ3BlQHRvb2xzLmlldGYu b3JnPC9hPjxicj4NCiZndDtDYzogPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3By aW5nQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOm52bzNAaWV0Zi5vcmciPg0KbnZvM0Bp ZXRmLm9yZzwvYT47IDZtYW4gV0c7IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LTxicj4NCiZndDs8 YSBocmVmPSJtYWlsdG86cm91dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmciPnJvdXRpbmctaGVh ZGVyQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCiZndDtTdWJqZWN0OiBSZTogW252bzNdIFtzcHJp bmddIEw0IENoZWNrc3VtIGFuZCBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC08YnI+DQomZ3Q7cm91 dGluZy1oZWFkZXI8YnI+DQomZ3Q7PGJyPg0KJmd0O1N0ZWZhbm8sPGJyPg0KJmd0Ozxicj4NCiZn dDtJZiBJIHVuZGVyc3RhbmQgeW91ciBwb2ludCBjb3JyZWN0bHk6PGJyPg0KJmd0O0lQdjYgc2Vn bWVudCByb3V0aW5nIGRvZXMgbm90IHdvcmsgd2l0aCBWWExBTiAvIFZYTEFOLUdQRSAvIEdlbmV2 ZSwgc2luY2U8YnI+DQomZ3Q7dGhlc2UgZW5jYXBzdWxhdGlvbnMgZG8gbm90IGN1cnJlbnRseSBh bGxvdyB0aGUgdXNlIG9mIElQdjYgZXh0ZW5zaW9uPGJyPg0KJmd0O2hlYWRlcnMuPGJyPg0KJmd0 Ozxicj4NCiZndDtJIHdvbmRlciBpZiB0aGUgYXV0aG9ycyBvZiBWWExBTi1HUEUgYW5kIEdlbmV2 ZSBoYXZlIGNvbnNpZGVyZWQgdGhlIHVzZSBvZjxicj4NCiZndDtzZWdtZW50IHJvdXRpbmcuPGJy Pg0KJmd0Ozxicj4NCiZndDtUaGFua3MsPGJyPg0KJmd0O1RhbC48YnI+DQomZ3Q7PGJyPg0KJmd0 Ozxicj4NCiZndDs8YnI+DQomZ3Q7Jmd0Oy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0K Jmd0OyZndDtGcm9tOiBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKSBbbWFpbHRvOjxhIGhyZWY9 Im1haWx0bzpzcHJldmlkaUBjaXNjby5jb20iPnNwcmV2aWRpQGNpc2NvLmNvbTwvYT5dPGJyPg0K Jmd0OyZndDtTZW50OiBUdWVzZGF5LCBNYXkgMTcsIDIwMTYgMTA6NDEgQU08YnI+DQomZ3Q7Jmd0 O1RvOiBUb20gSGVyYmVydDxicj4NCiZndDsmZ3Q7Q2M6IFRhbCBNaXpyYWhpOyA2bWFuIFdHOyA8 YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+Ozxicj4N CiZndDsmZ3Q7ZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy0gPGEgaHJlZj0ibWFpbHRv OmhlYWRlckB0b29scy5pZXRmLm9yZyI+aGVhZGVyQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCiZn dDsmZ3Q7U3ViamVjdDogUmU6IFtzcHJpbmddIEw0IENoZWNrc3VtIGFuZCBkcmFmdC1pZXRmLTZt YW4tc2VnbWVudC1yb3V0aW5nLTxicj4NCiZndDsmZ3Q7aGVhZGVyPGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBPbiBNYXkgMTYsIDIwMTYsIGF0IDc6MTAgUE0s IFRvbSBIZXJiZXJ0ICZsdDs8YSBocmVmPSJtYWlsdG86dG9tQGhlcmJlcnRsYW5kLmNvbSI+dG9t QGhlcmJlcnRsYW5kLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0O3dyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyBPbiBNb24sIE1heSAxNiwgMjAxNiBhdCA0OjMyIEFNLCBUYWwg TWl6cmFoaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRhbG1pQG1hcnZlbGwuY29tIj50YWxtaUBtYXJ2 ZWxsLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyZndDt3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBpdOKAmXMgYWxsIGFib3V0IElQLCBub3QgbGF5ZXItMi48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHMuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgUmlnaHQuIEhvd2V2ZXIsIGl0IGFwcGVhcnMgdGhhdCBh dCBsZWFzdCBpbiBzb21lIGNhc2VzIGEgVlhMQU4gVlRFUDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsg d2lsbDxicj4NCiZndDsmZ3Q7dXNlIFNSLiBJdCBjZXJ0YWlubHkgbWF5IGJlIHRoZSBjYXNlIGlu IFNGQyB1c2UgY2FzZXMgKHNlZSBTZWN0aW9uIDIuMzxicj4NCiZndDsmZ3Q7aW4gZHJhZnQtIGll dGYtc3ByaW5nLWlwdjYtdXNlLWNhc2VzKS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRp bmctaGVhZGVyIG1lbnRpb25zIHRoYXQgdGhlIHBhY2tldCBpczxicj4NCiZndDsmZ3Q7Jmd0OyBl bmNhcHN1bGF0ZWQ8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtpbnRv IGFuIG91dGVyIGlwdjYgaGVhZGVyIHdoaWNoIG1ha2VzIGl0IGEgbGF5ZXItMyBlbmNhcC48YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7ICwgYnV0IEkgZG9uJ3Qg dGhpbmsgaXQgaXMgZXhwbGljaXQgYXMgdG8gZXhhY3QgZW5jYXBzdWxhdGlvbiBmb3JtYXQ8YnI+ DQomZ3Q7Jmd0OyZndDsgKEkgc3VwcG9zZSBzaW1wbGUgaXA2aXA2IGlzIGltcGxpZWQpLjxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0O3NlZSBzZWN0aW9uIDIuMjxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgQnV0LCBpdDxicj4NCiZn dDsmZ3Q7Jmd0OyBzZWVtcyBsaWtlIGFueSBvZiBzZXZlcmFsIGVuY2Fwc3VsYXRpb24gdGVjaG5p cXVlcyBjb3VsZCB3b3JrIChWWExBTiw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDtJIGhhdmUgc29tZSBwcm9ibGVtcyB0byB1bmRlcnN0YW5kIHdoZXJlIHRvIGZpdCBh biBleHRlbnNpb24gaGVhZGVyPGJyPg0KJmd0OyZndDtpbnRvIGEgdnhsYW4gZW5jYXDigKY8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEdSRS9JUCwgRVNQL0lQ LCBHVUUsIGZvbyBvdmVyIFVEUCwgZXRjLikgYW5kIGlmIGEgZGV2aWNlIHRoYXQgd2FudHM8YnI+ DQomZ3Q7Jmd0OyZndDsgdG8gZG8gU1IgaXMgYWxyZWFkeSBkb2luZyB0dW5uZWxpbmcgaXQgc2Vl bXMgcmVhc29uYWJsZSB0byBtZSB0byBvbmx5PGJyPg0KJmd0OyZndDsmZ3Q7IGhhdmUgb25lIGxh eWVyIG9mIGVuY2Fwc3VsYXRpb24uIE1heWJlIHRoaXMgc2hvdWxkIGJlIGNsYXJpZmllZCBpbjxi cj4NCiZndDsmZ3Q7Jmd0OyB0aGUgZHJhZnQ/PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7dGhlIGRyYWZ0IGlzIGFib3V0IElQdjYgZXh0ZW5zaW9uIGhlYWRlciBhbmQg bW9yZSBwcmVjaXNlbHkgYSBuZXcgdHlwZTxicj4NCiZndDsmZ3Q7b2YgdGhlIHJvdXRpbmcgZXh0 ZW5zaW9uIGhlYWRlciBkZWZpbmVkIGluIHJmYzI0NjAuIFRoYXTigJlzIHRoZSBjb250ZXh0Ljxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0O3MuPGJyPg0KJmd0OyZndDs8 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsgVG9tPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEZyb206 IFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnNwcmV2 aWRpQGNpc2NvLmNvbSI+c3ByZXZpZGlAY2lzY28uY29tPC9hPl08YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBTZW50OiBNb25kYXksIE1heSAxNiwgMjAxNiAyOjI0IFBNPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsgVG86IFRhbCBNaXpyYWhpPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2M6 IE9sZSBUcsO4YW47PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOmRy YWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyQHRvb2xzLmlldGYub3JnIj5kcmFm dC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlckB0b29scy5pZXRmLm9yZzwvYT47PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+ c3ByaW5nQGlldGYub3JnPC9hPjsgNm1hbiBXRzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFN1 YmplY3Q6IFJlOiBbc3ByaW5nXSBMNCBDaGVja3N1bSBhbmQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLSBoZWFkZXI8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IE9uIE1heSAxNiwgMjAxNiwgYXQgMToxOSBQTSwgVGFsIE1penJhaGkgJmx0 OzxhIGhyZWY9Im1haWx0bzp0YWxtaUBtYXJ2ZWxsLmNvbSI+dGFsbWlAbWFydmVsbC5jb208L2E+ Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgSGkgU3RlZmFubyw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhhbmtzIGFnYWluIGZvciB0aGUgcHJvbXB0 IHJlc3BvbnNlLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgMi4gdGhlIFNSSCBpcyBvcmlnaW5hdGVkIGJ5IHRoZSBpbmdyZXNz IG5vZGUgb2YgdGhlIFNSIGRvbWFpbi48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IFRoaXMgaXMgZG9uZSBieSBlbmNhcHN1bGF0aW5nIHRoZSBwYWNrZXQgaW50byBhIG91dGVyPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAoYWRkaXRpb25hbCkgaXB2NiBoZWFkZXIg Zm9sbG93ZWQgYnkgYW4gU1JILiBUaGlzIGlzIEwzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBlbmNhcHN1bGF0aW9uIGFuZCBubyBMNCBjaGVja3N1bSBpcyBpbnZvbHZlZC4gV2hl biB0aGUmbmJzcDsgcGFja2V0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBsZWF2 ZXMgdGhlIFNSIHR1bm5lbCB0aGUgb3V0ZXIgZW5jYXBzdWxhdGlvbiZuYnNwOyAoaW5jbHVkaW5n IHRoZSBTUkgpPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpcyByZW1vdmVkIGFu ZCB0aGUgcGFja2V0IGNvbnRpbnVlcyZuYnNwOyBpdHMgam91cm5leSBsaWtlIG5vdGhpbmc8YnI+ DQomZ3Q7aGFwcGVuZWQuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNvIFZYTEFOIGlzIG9mZiB0aGUgdGFibGU/PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGl04oCZcyBhbGwgYWJvdXQgSVAsIG5vdCBsYXllci0yLjxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcy48YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEl0IHdvdWxkIGJlIHdvcnRod2hpbGUgdG8gY2xhcmlmeSB0aGlzIGluIHRoZSBk cmFmdC4gSWYgeW91IGhhdmUgYTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzcGVjaWZp Yzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGVuY2Fwc3VsYXRpb24gaW4gbWluZCwgaXQgd291 bGQgYmUgZ3JlYXQgaWYgdGhlIGRyYWZ0IHdvdWxkIHNwZWNpZnkgaXQuPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rcyw8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGFsLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IEZyb206IFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpIFttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOnNwcmV2aWRpQGNpc2NvLmNvbSI+c3ByZXZpZGlAY2lzY28uY29tPC9h Pl08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNlbnQ6IE1vbmRheSwgTWF5IDE2 LCAyMDE2IDI6MTMgUE08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiBUYWwg TWl6cmFoaTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2M6IE9sZSBUcsO4YW47 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQt aWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWll dGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyQHRvb2xzLmlldGYub3JnPC9hPjs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5v cmciPnNwcmluZ0BpZXRmLm9yZzwvYT47IDZtYW4gV0c8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBMNCBDaGVja3N1bSBhbmQ8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmct IGhlYWRlcjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhpLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE9uIE1heSAxNiwgMjAxNiwgYXQgMTE6 MDQgQU0sIFRhbCBNaXpyYWhpICZsdDs8YSBocmVmPSJtYWlsdG86dGFsbWlAbWFydmVsbC5jb20i PnRhbG1pQG1hcnZlbGwuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0O3dyb3RlOjxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgSGkgU3RlZmFubyw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rcyBmb3IgdGhlIHJl c3BvbnNlcy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBleGFjdGx5Ljxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBNb3Jlb3ZlciwgZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFk ZXIgYXNzdW1lczxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBlbmNh cHN1bGF0aW9uIHNvIGNsZWFybHkgdGhlcmXigJlzIG5vIEw0IGludm9sdmVkIGhlcmUuPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHMuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUd28gcXVlc3Rpb25z Ojxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDEuIFdoYXQgaWYgdGhlIGVu Y2Fwc3VsYXRpb24gaXMgVlhMQU4/IEw0IHdvdWxkIHN0aWxsIGJlPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaW52b2x2ZWQsPGJyPg0KJmd0OyZndDtyaWdodD88YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2VlIGJlbG93Ljxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgMi4gV2hlbiB5b3Ugc2F5 ICdhc3N1bWVzIGVuY2Fwc3VsYXRpb24nLCBkb2VzIGl0IG1lYW4gdGhhdCBhPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaG9zdCBjYW5ub3Q8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHNlbmQgYW4gSVB2NiBwYWNrZXQgd2l0aCBhbiBTUkg/IFRoZSBjdXJy ZW50IGRyYWZ0IHNheXM6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBIFNvdXJjZSBTUiBOb2RlIGNhbiBi ZSBhbnkgbm9kZSBvcmlnaW5hdGluZyBhbiBJUHY2IHBhY2tldCB3aXRoPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXRzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgSVB2NiBhbmQgU2VnbWVudCBSb3V0aW5nIEhlYWRlcnMuJm5ic3A7IFRoaXMgaW5j bHVkZSBlaXRoZXI6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgQSBob3N0IG9yaWdp bmF0aW5nIGFuIElQdjYgcGFja2V0Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7IEFu IFNSIGRvbWFpbiBpbmdyZXNzIHJvdXRlciBlbmNhcHN1bGF0aW5nIGEgcmVjZWl2ZWQgSVB2NiBw YWNrZXQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsg aW50byBhbiBvdXRlciBJUHY2IGhlYWRlciBmb2xsb3dlZCBieSBhbiBTUkguPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgV2lsbCBhcHByZWNpYXRlIGlmIHlvdSBjYW4gY2xh cmlmeSB0aGF0Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBv aywgdHdvIGNhc2VzOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDEuIHRoZSBTUkggaXMgaW5zZXJ0ZWQgYXQgdGhlIHNv dXJjZS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBzb3VyY2Ugb3JpZ2lu YXRlcyB0aGUgcGFja2V0LCB0aGUgaXB2NiBoZWFkZXIgYW5kJm5ic3A7IHRoZSBTUkguPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgc291cmNlIGNvbXB1dGVzIEw0IGNoZWNr c3VtIHRha2luZyBpbnRvJm5ic3A7IGFjY291bnQgdGhlIHdob2xlPGJyPg0KJmd0OyZndDtJUHY2 JiM0MztTUkguPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIZXJlLCB0aGVyZXPi gJkgbm90aGluZyBuZXcmbmJzcDsgY29tcGFyZWQgdG8gcmZjMjQ2MC48YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAyLiB0 aGUgU1JIIGlzIG9yaWdpbmF0ZWQgYnkgdGhlIGluZ3Jlc3Mgbm9kZSBvZiB0aGUgU1IgZG9tYWlu Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhpcyBpcyBkb25lIGJ5IGVuY2Fw c3VsYXRpbmcgdGhlIHBhY2tldCBpbnRvIGEgb3V0ZXI8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IChhZGRpdGlvbmFsKSBpcHY2IGhlYWRlciBmb2xsb3dlZCBieSBhbiBTUkguIFRo aXMgaXMgTDM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGVuY2Fwc3VsYXRpb24g YW5kIG5vIEw0IGNoZWNrc3VtIGlzIGludm9sdmVkLiBXaGVuIHRoZSZuYnNwOyBwYWNrZXQ8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxlYXZlcyB0aGUgU1IgdHVubmVsIHRoZSBv dXRlciBlbmNhcHN1bGF0aW9uJm5ic3A7IChpbmNsdWRpbmcgdGhlIFNSSCk8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlzIHJlbW92ZWQgYW5kIHRoZSBwYWNrZXQgY29udGludWVz Jm5ic3A7IGl0cyBqb3VybmV5IGxpa2Ugbm90aGluZzxicj4NCiZndDtoYXBwZW5lZC48YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBzLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGFua3MsPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGFsLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEZyb206IFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpIFttYWlsdG86PGEgaHJl Zj0ibWFpbHRvOnNwcmV2aWRpQGNpc2NvLmNvbSI+c3ByZXZpZGlAY2lzY28uY29tPC9hPl08YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2VudDogTW9uZGF5LCBNYXkg MTYsIDIwMTYgMTE6NTkgQU08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgVG86IE9sZSBUcsO4YW47IFRhbCBNaXpyYWhpPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi02bWFuLXNlZ21l bnQtcm91dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmciPg0KZHJhZnQtaWV0Zi02bWFuLXNlZ21l bnQtcm91dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmc8L2E+Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5z cHJpbmdAaWV0Zi5vcmc8L2E+OyA2bWFuIFdHPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFN1YmplY3Q6IFJlOiBbc3ByaW5nXSBMNCBDaGVja3N1bSBhbmQ8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZHJhZnQtaWV0Zi02bWFuLXNlZ21l bnQtcm91dGluZy0gaGVhZGVyPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBNYXkgMTUsIDIwMTYsIGF0IDg6 MDYgUE0sIDxhIGhyZWY9Im1haWx0bzpvdHJvYW5AZW1wbG95ZWVzLm9yZyI+b3Ryb2FuQGVtcGxv eWVlcy5vcmc8L2E+IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRh bCw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgW0Fwb2xvZ2llcyBpZiB0 aGlzIGlzc3VlIGhhcyBiZWVuIGRpc2N1c3NlZCBiZWZvcmUuXTxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQWNjb3JkaW5nIHRvIGRyYWZ0LWlldGYtNm1hbi1zZWdt ZW50LXJvdXRpbmctaGVhZGVyLCBhbiDigJhTUjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNlZ21lbnQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgRW5kcG9pbnQgTm9kZeKAmSB1cGRhdGVzIHRoZSBEZXN0aW5hdGlvbiBJ UCBhZGRyZXNzLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IFRoZXJlZm9yZSwgaXQgbXVzdCBhbHNvIHVwZGF0ZSB0aGUgTGF5ZXIgNCBDaGVja3N1bSwg cmlnaHQ/PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIHdvbmRl ciBpZiB0aGVyZSBpcyBhbiB1cHBlciBib3VuZCBvbiB0aGUgc2l6ZSBvZiB0aGUgU1JILjxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE90aGVyd2lzZSwg dGhlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEw0IENoZWNrc3Vt IG1heSBiZSBsb2NhdGVkIGluIGEgcHJldHR5IGRlZXAgbG9jYXRpb24uPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU3BlYWtpbmcgZnJvbSBhIGNoaXAg dmVuZG9y4oCZcyBwZXJzcGVjdGl2ZSB0aGlzIG1heSBiZSBhIHByb2JsZW0uPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRnJvbSBSRkMyNDYwLCBSSDA6PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwO28mbmJzcDsgSWYgdGhlIElQdjYgcGFja2V0IGNvbnRhaW5z IGEgUm91dGluZyBoZWFkZXIsIHRoZSBEZXN0aW5hdGlvbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBBZGRyZXNzIHVzZWQg aW4gdGhlIHBzZXVkby1oZWFkZXIgaXMgdGhhdCBvZiB0aGUgZmluYWw8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgZGVzdGlu YXRpb24uJm5ic3A7IEF0IHRoZSBvcmlnaW5hdGluZyBub2RlLCB0aGF0IGFkZHJlc3Mgd2lsbCBi ZSBpbjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsg Jm5ic3A7ICZuYnNwOyB0aGUgbGFzdCBlbGVtZW50IG9mIHRoZSBSb3V0aW5nIGhlYWRlcjsgYXQg dGhlIHJlY2lwaWVudChzKSw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdGhhdCBhZGRyZXNzIHdpbGwgYmUgaW4gdGhlIERl c3RpbmF0aW9uIEFkZHJlc3MgZmllbGQgb2YgdGhlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IElQdjYgaGVhZGVyLjxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgd291bGQgZXhwZWN0IFNSIHdvdWxkIHdv cmsgdGhlIHNhbWUuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGV4YWN0bHkuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IE1vcmVvdmVyLCBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlciBhc3N1 bWVzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGVuY2Fwc3VsYXRp b24gc28gY2xlYXJseSB0aGVyZeKAmXMgbm8gTDQgaW52b2x2ZWQgaGVyZS48YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgcy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBDaGVlcnMsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgSUVURiBJUHY2IHdv cmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0IDxhIGhyZWY9Im1haWx0bzppcHY2QGlldGYub3JnIj5p cHY2QGlldGYub3JnPC9hPiBBZG1pbmlzdHJhdGl2ZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgUmVx dWVzdHM6IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXB2 NiIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9pcHY2PC9hPjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7PGJy Pg0KJmd0O19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJy Pg0KJmd0O252bzMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OzxhIGhyZWY9Im1haWx0bzpudm8zQGll dGYub3JnIj5udm8zQGlldGYub3JnPC9hPjxicj4NCiZndDs8YSBocmVmPSJodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzM8L2E+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNwcmluZyBtYWlsaW5n IGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5v cmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zcHJpbmciIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NwcmluZzwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_bb99730deb8348bcac4f5c433e88d435ILEXCH02marvellcom_-- From nobody Mon May 23 00:46:44 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF3F812B032; Mon, 23 May 2016 00:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZ_tsxR_DKrj; Mon, 23 May 2016 00:46:34 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (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 DB2E112B026; Mon, 23 May 2016 00:46:33 -0700 (PDT) Received: by mail-lb0-x234.google.com with SMTP id ww9so52598159lbc.2; Mon, 23 May 2016 00:46:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=B4oxaX6DRA2r9VJn2xToxGDH+AIs3ZwxTXd5Wm/5SCM=; b=rUsdE4UUJU0oNg6KEhcFaoVzf3tApsDaJZZ0XSj4UAXrJW+zf7N8raNhud9DOucz1v XuhwhPSeUXx9c45UlSanaK9cDQnBkTl+YDgNlnAn5cnyIwuipjVhHkBRXfiyrDs4NDEo Qwa+3Yb06BeKAy8qIeidkzWE3gzuR8nvA0YkWaMdrQfSdDBClc/U/UDa1fxRSV2/samc MnapYDiOF3M74xtEP+gvO4D0rseyoLs193JjVa2Y5TIHr7/AjS4vNGGdtopgBw0y/EPy RuUpj5gPQO597dK9tWJNnDGvFG9a/qg9weuXPcIM9uq4VUHdoCTxJHJgkFIyYAuImMKz j6lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=B4oxaX6DRA2r9VJn2xToxGDH+AIs3ZwxTXd5Wm/5SCM=; b=fSvwCwQzaiT2AQhQ7Q9l8V+Ifo/S3GBxM9piQYYgGim4WemLtDU9Q7e+8X/WIY5Sz5 /HaPEwHJdovRGO3TMI7IgalQMebuyO2+GE14Ho2pdssnIHMWHaoo0SC+NMq4DdfADJYZ flossFydGhGgDMCg2W7/dv3HnbthUmwzvyPKww6c3OU5LJa3EmHRpVdTA6XaMOaVTeSH iZ0OmffnF9be648ukjpC2rmAD31IJd8E1Ze7MZQFYRXhGX6siHjfNvEI5a9bMnVZ6GOb lVt7+1E6H56nuqI+9yNfwv8AS0ZtccuN9U6jUBxkkX1fGg+AZc84fFgPkbECJzDnXY3a KjbQ== X-Gm-Message-State: AOPr4FVxC56GBYkiV7f2pE/zY6WK0acJWJvleQS8Cp9ZJeplS/x9srC/PRDCzbWFJK/KqEeG+aIuXeYTAhIIgg== MIME-Version: 1.0 X-Received: by 10.112.171.229 with SMTP id ax5mr5252428lbc.115.1463989591915; Mon, 23 May 2016 00:46:31 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.126.210 with HTTP; Mon, 23 May 2016 00:46:31 -0700 (PDT) In-Reply-To: References: <5dc56935eba94c2390120244564f9b21@IL-EXCH02.marvell.com> <0551686F-F1D2-4C34-81C8-530F1BEE1BDF@cisco.com> <5d889e7013b44b27ae1e75cf7ea2dd22@IL-EXCH02.marvell.com> <3549ABBE-9828-42D2-A056-851432487E2E@cisco.com> <1e13d2e32b2448af94bf23d5acf17740@IL-EXCH02.marvell.com> <569a4067fd1f45dd85d60e983be69b90@IL-EXCH02.marvell.com> Date: Mon, 23 May 2016 09:46:31 +0200 X-Google-Sender-Auth: S03UTLdSiksFcXh_oSiaaMUB0lg Message-ID: From: Robert Raszuk To: Tal Mizrahi Content-Type: multipart/alternative; boundary=001a11c36ed694c48705337da31d Archived-At: Cc: "spring@ietf.org" , 6man WG , "draft-ietf-nvo3-vxlan-gpe@tools.ietf.org" , "nvo3@ietf.org" , "draft-ietf-6man-segment-routing-header@tools.ietf.org" , "draft-ietf-nvo3-geneve@tools.ietf.org" , "Stefano Previdi \(sprevidi\)" Subject: Re: [spring] [nvo3] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 07:46:38 -0000 --001a11c36ed694c48705337da31d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tal, Indeed .. I saw the figures, but figures are non normative in any draft/rfc unless text below specifically spells it out. For example from vxlan-gpe: "When the outer IP header is IPv4, VTEPs MUST set the DF bit." Besides it is pretty challenging to add animation to the current draft formats to illustrate all possibly allowed field values/combinations in any figure :) Figures just illustrate one use example. To me the current specs permit any value of IPv6 NxtHdr field as permitted in both encapsulations. Best, Robert. On Mon, May 23, 2016 at 9:35 AM, Tal Mizrahi wrote: > Hi Robert, > > > > > > > Where say in draft draft-quinn-vxlan-gpe do you see such statement that > would imply > > > that v6 NxtHdr must be only equal to 17 (UDP) and not be a pointer to > any other type > > > of extension header further followed by UDP ? > > > > > > The following text is from Figure 4 in draft-ietf-nvo3-vxlan-gpe: > > > > Outer IPv6 Header: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |Version| Traffic Class | Flow Label | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Payload Length | NxtHdr=3D17(UDP)| Hop Limit | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > > > > > There is a similar figure in draft-ietf-nvo3-geneve. > > > > Best regards, > > Tal. > > > > *From:* nvo3 [mailto:nvo3-bounces@ietf.org] *On Behalf Of *Robert Raszuk > *Sent:* Monday, May 23, 2016 10:29 AM > *To:* Tal Mizrahi > *Cc:* spring@ietf.org; 6man WG; draft-ietf-nvo3-vxlan-gpe@tools.ietf.org; > nvo3@ietf.org; draft-ietf-6man-segment-routing-header@tools.ietf.org; > draft-ietf-nvo3-geneve@tools.ietf.org; Stefano Previdi (sprevidi) > > *Subject:* Re: [nvo3] [spring] L4 Checksum and > draft-ietf-6man-segment-routing-header > > > > Hi Tal, > > > > > drafts seem to imply > > > > Where say in draft draft-quinn-vxlan-gpe do you see such statement that > would imply that v6 NxtHdr must be only equal to 17 (UDP) and not be a > pointer to any other type of extension header further followed by UDP ? > > > > Thx, > R. > > > > > > On Mon, May 23, 2016 at 7:50 AM, Tal Mizrahi wrote: > > Dear Authors of VXLAN-GPE / Geneve, > > I am reiterating on this question, as I haven't seen a response yet: > > Have you considered the use of Segment Routing with VXLAN-GPE / Geneve? > The current VXLAN-GPE / Geneve drafts seem to imply that IPv6 extension > headers are currently not supported. > > Thanks, > Tal. > > > > > >-----Original Message----- > >From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Tal Mizrahi > >Sent: Tuesday, May 17, 2016 12:09 PM > >To: Stefano Previdi (sprevidi); Tom Herbert; draft-ietf-nvo3- > >geneve@tools.ietf.org; draft-ietf-nvo3-vxlan-gpe@tools.ietf.org > >Cc: spring@ietf.org; nvo3@ietf.org; 6man WG; draft-ietf-6man-segment- > >routing-header@tools.ietf.org > >Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment- > >routing-header > > > >Stefano, > > > >If I understand your point correctly: > >IPv6 segment routing does not work with VXLAN / VXLAN-GPE / Geneve, sinc= e > >these encapsulations do not currently allow the use of IPv6 extension > >headers. > > > >I wonder if the authors of VXLAN-GPE and Geneve have considered the use = of > >segment routing. > > > >Thanks, > >Tal. > > > > > > > >>-----Original Message----- > >>From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] > >>Sent: Tuesday, May 17, 2016 10:41 AM > >>To: Tom Herbert > >>Cc: Tal Mizrahi; 6man WG; spring@ietf.org; > >>draft-ietf-6man-segment-routing- header@tools.ietf.org > >>Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing- > >>header > >> > >> > >>> On May 16, 2016, at 7:10 PM, Tom Herbert > >wrote: > >>> > >>> On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi > >>wrote: > >>>>> it=E2=80=99s all about IP, not layer-2. > >>>>> > >>>>> s. > >>>> > >>>> Right. However, it appears that at least in some cases a VXLAN VTEP > >>>> will > >>use SR. It certainly may be the case in SFC use cases (see Section 2.3 > >>in draft- ietf-spring-ipv6-use-cases). > >>>> > >>> > >>> draft-ietf-6man-segment-routing-header mentions that the packet is > >>> encapsulated > >> > >> > >>into an outer ipv6 header which makes it a layer-3 encap. > >> > >> > >>> , but I don't think it is explicit as to exact encapsulation format > >>> (I suppose simple ip6ip6 is implied). > >> > >> > >>see section 2.2 > >> > >> > >>> But, it > >>> seems like any of several encapsulation techniques could work (VXLAN, > >> > >> > >>I have some problems to understand where to fit an extension header > >>into a vxlan encap=E2=80=A6 > >> > >> > >>> GRE/IP, ESP/IP, GUE, foo over UDP, etc.) and if a device that wants > >>> to do SR is already doing tunneling it seems reasonable to me to only > >>> have one layer of encapsulation. Maybe this should be clarified in > >>> the draft? > >> > >> > >>the draft is about IPv6 extension header and more precisely a new type > >>of the routing extension header defined in rfc2460. That=E2=80=99s the = context. > >> > >> > >>s. > >> > >> > >> > >> > >>> > >>> Tom > >>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] > >>>>> Sent: Monday, May 16, 2016 2:24 PM > >>>>> To: Tal Mizrahi > >>>>> Cc: Ole Tr=C3=B8an; > >>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org; > >>>>> spring@ietf.org; 6man WG > >>>>> Subject: Re: [spring] L4 Checksum and > >>>>> draft-ietf-6man-segment-routing- header > >>>>> > >>>>> > >>>>>> On May 16, 2016, at 1:19 PM, Tal Mizrahi wrote= : > >>>>>> > >>>>>> Hi Stefano, > >>>>>> > >>>>>> Thanks again for the prompt response. > >>>>>> > >>>>>>> 2. the SRH is originated by the ingress node of the SR domain. > >>>>>>> This is done by encapsulating the packet into a outer > >>>>>>> (additional) ipv6 header followed by an SRH. This is L3 > >>>>>>> encapsulation and no L4 checksum is involved. When the packet > >>>>>>> leaves the SR tunnel the outer encapsulation (including the SRH) > >>>>>>> is removed and the packet continues its journey like nothing > >happened. > >>>>>> > >>>>>> So VXLAN is off the table? > >>>>> > >>>>> > >>>>> it=E2=80=99s all about IP, not layer-2. > >>>>> > >>>>> s. > >>>>> > >>>>> > >>>>>> It would be worthwhile to clarify this in the draft. If you have a > >>>>>> specific > >>>>> encapsulation in mind, it would be great if the draft would specify > it. > >>>>>> > >>>>>> Thanks, > >>>>>> Tal. > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] > >>>>>>> Sent: Monday, May 16, 2016 2:13 PM > >>>>>>> To: Tal Mizrahi > >>>>>>> Cc: Ole Tr=C3=B8an; > >>>>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org; > >>>>>>> spring@ietf.org; 6man WG > >>>>>>> Subject: Re: [spring] L4 Checksum and > >>>>>>> draft-ietf-6man-segment-routing- header > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> On May 16, 2016, at 11:04 AM, Tal Mizrahi > >>wrote: > >>>>>>>> > >>>>>>>> Hi Stefano, > >>>>>>>> > >>>>>>>> Thanks for the responses. > >>>>>>>> > >>>>>>>>> exactly. > >>>>>>>>> > >>>>>>>>> Moreover, draft-ietf-6man-segment-routing-header assumes > >>>>>>>>> encapsulation so clearly there=E2=80=99s no L4 involved here. > >>>>>>>>> > >>>>>>>>> s. > >>>>>>>> > >>>>>>>> Two questions: > >>>>>>>> 1. What if the encapsulation is VXLAN? L4 would still be > >>>>>>>> involved, > >>right? > >>>>>>> > >>>>>>> > >>>>>>> See below. > >>>>>>> > >>>>>>> > >>>>>>>> 2. When you say 'assumes encapsulation', does it mean that a > >>>>>>>> host cannot > >>>>>>> send an IPv6 packet with an SRH? The current draft says: > >>>>>>>> > >>>>>>>> A Source SR Node can be any node originating an IPv6 packet with > >>>>>>>> its > >>>>>>>> IPv6 and Segment Routing Headers. This include either: > >>>>>>>> > >>>>>>>> A host originating an IPv6 packet. > >>>>>>>> > >>>>>>>> An SR domain ingress router encapsulating a received IPv6 > packet > >>>>>>>> into an outer IPv6 header followed by an SRH. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Will appreciate if you can clarify that. > >>>>>>> > >>>>>>> > >>>>>>> ok, two cases: > >>>>>>> > >>>>>>> 1. the SRH is inserted at the source. > >>>>>>> the source originates the packet, the ipv6 header and the SRH. > >>>>>>> The source computes L4 checksum taking into account the whole > >>IPv6+SRH. > >>>>>>> Here, theres=E2=80=99 nothing new compared to rfc2460. > >>>>>>> > >>>>>>> 2. the SRH is originated by the ingress node of the SR domain. > >>>>>>> This is done by encapsulating the packet into a outer > >>>>>>> (additional) ipv6 header followed by an SRH. This is L3 > >>>>>>> encapsulation and no L4 checksum is involved. When the packet > >>>>>>> leaves the SR tunnel the outer encapsulation (including the SRH) > >>>>>>> is removed and the packet continues its journey like nothing > >happened. > >>>>>>> > >>>>>>> s. > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Tal. > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] > >>>>>>>>> Sent: Monday, May 16, 2016 11:59 AM > >>>>>>>>> To: Ole Tr=C3=B8an; Tal Mizrahi > >>>>>>>>> Cc: draft-ietf-6man-segment-routing-header@tools.ietf.org; > >>>>>>>>> spring@ietf.org; 6man WG > >>>>>>>>> Subject: Re: [spring] L4 Checksum and > >>>>>>>>> draft-ietf-6man-segment-routing- header > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> On May 15, 2016, at 8:06 PM, otroan@employees.org wrote: > >>>>>>>>>> > >>>>>>>>>> Tal, > >>>>>>>>>> > >>>>>>>>>>> [Apologies if this issue has been discussed before.] > >>>>>>>>>>> > >>>>>>>>>>> According to draft-ietf-6man-segment-routing-header, an =E2= =80=98SR > >>>>>>>>>>> Segment > >>>>>>>>> Endpoint Node=E2=80=99 updates the Destination IP address. > >>>>>>>>>>> Therefore, it must also update the Layer 4 Checksum, right? > >>>>>>>>>>> > >>>>>>>>>>> I wonder if there is an upper bound on the size of the SRH. > >>>>>>>>>>> Otherwise, the > >>>>>>>>> L4 Checksum may be located in a pretty deep location. > >>>>>>>>>>> Speaking from a chip vendor=E2=80=99s perspective this may be= a > problem. > >>>>>>>>>> > >>>>>>>>>> From RFC2460, RH0: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> o If the IPv6 packet contains a Routing header, the > Destination > >>>>>>>>>> Address used in the pseudo-header is that of the final > >>>>>>>>>> destination. At the originating node, that address will > be in > >>>>>>>>>> the last element of the Routing header; at the > recipient(s), > >>>>>>>>>> that address will be in the Destination Address field of > the > >>>>>>>>>> IPv6 header. > >>>>>>>>>> > >>>>>>>>>> I would expect SR would work the same. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> exactly. > >>>>>>>>> > >>>>>>>>> Moreover, draft-ietf-6man-segment-routing-header assumes > >>>>>>>>> encapsulation so clearly there=E2=80=99s no L4 involved here. > >>>>>>>>> > >>>>>>>>> s. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Cheers, > >>>>>>>>>> Ole > >>>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >>>> -------------------------------------------------------------------- > >>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>> -------------------------------------------------------------------- > > > >_______________________________________________ > >nvo3 mailing list > >nvo3@ietf.org > >https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > --001a11c36ed694c48705337da31d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tal,

Indeed .. I saw the figures, but figures are non norm= ative in any draft/rfc unless text below specifically spells it out.=C2=A0<= /div>

For example from vxlan= -gpe:=C2=A0

"When the outer IP header is IPv4, VTEPs MUST set the DF bit."

Besides it is prett= y challenging to add animation to the current draft formats to illustrate a= ll possibly allowed field values/combinations in any figure :) =C2=A0Figure= s just illustrate one use example.=C2=A0

To me the current specs permit any value of IPv6 Nxt= Hdr field as permitted in both encapsulations.

=
Best,
Robert.


On Mon, May 23, 2016 at 9:35 AM, Tal Mizrahi &= lt;talmi@marvell.com= > wrote:

Hi Robert,<= /span>

=C2=A0

=C2=A0

> Where say in draft draft-quinn-vxlan-gpe do you = see such statement that would imply

> that v6 NxtHdr must = be only equal to 17 (UDP) and not be a pointer to any other type

> of extension header = further followed by UDP ?

=C2=A0

=C2=A0

The following text= is from Figure 4 in draft-ietf-nvo3-vxlan-gpe:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Outer IPv6 He= ader:

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

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |Version| Tra= ffic Class |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Fl= ow Label=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

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

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Payload Length=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 | NxtHdr=3D17(UDP)|=C2=A0=C2=A0 Hop Limit=C2=A0=C2=A0 |<= u>

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

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|<= /u>

=C2=A0

=C2=A0

There is a similar figure= in draft-ietf-nvo3-geneve.

=C2=A0

Best regards,

Tal.=

=C2=A0

From: nvo3 [ma= ilto:nvo3-bounce= s@ietf.org] On Behalf Of Robert Raszuk
Sent: Monday, May 23, 2016 10:29 AM
To: Tal Mizrahi
Cc: spring@ietf= .org; 6man WG; draft-ietf-nvo3-vxlan-gpe@tools.ietf.org; nvo3@ietf.org; draft-ietf-6man-segment-routing-header@tools.ietf.org; draft-ietf-n= vo3-geneve@tools.ietf.org; Stefano Previdi (sprevidi)


Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment= -routing-header

=C2=A0

Hi Tal,

=C2=A0

>=C2=A0drafts seem to imply=

=C2=A0

Where say in draft=C2=A0draft-quinn-vxlan-gpe do you see s= uch statement that would imply that v6 NxtHdr must be only equal to 17 (UDP= ) and not be a pointer to any other type of extension header further followed by UDP ?=C2=A0

=C2=A0

Thx,
R.

=C2=A0

=C2=A0

On Mon, May 23, 2016 at 7:50 AM, Tal Mizrahi <talmi@marvell.com&g= t; wrote:

Dear Authors of VXLAN-GPE / Geneve,

I am reiterating on this question, as I haven't seen a response yet:
Have you considered the use of Segment Routing with VXLAN-GPE / Geneve? The= current VXLAN-GPE / Geneve drafts seem to imply that IPv6 extension header= s are currently not supported.

Thanks,
Tal.




>-----Original Message-----
>From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Tal Mizrahi
>Sent: Tuesday, May 17, 2016 12:09 PM
>To: Stefano Previdi (sprevidi); Tom Herbert; draft-ietf-nvo3-
>geneve@tools= .ietf.org; draft-ietf-nvo3-vxlan-gpe@tools.ietf.org
>Cc: spring@ietf.or= g; nvo3@ietf.org; 6man WG; draft-ietf-6man-segment-
>rout= ing-header@tools.ietf.org
>Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment- >routing-header
>
>Stefano,
>
>If I understand your point correctly:
>IPv6 segment routing does not work with VXLAN / VXLAN-GPE / Geneve, sin= ce
>these encapsulations do not currently allow the use of IPv6 extension >headers.
>
>I wonder if the authors of VXLAN-GPE and Geneve have considered the use= of
>segment routing.
>
>Thanks,
>Tal.
>
>
>
>>-----Original Message-----
>>From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
>>Sent: Tuesday, May 17, 2016 10:41 AM
>>To: Tom Herbert
>>Cc: Tal Mizrahi; 6man WG; spring@ietf.org;
>>draft-ietf-6man-segment-routing- header@tools.ietf.org
>>Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routi= ng-
>>header
>>
>>
>>> On May 16, 2016, at 7:10 PM, Tom Herbert <tom@herbertland.com>
>wrote:
>>>
>>> On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi <talmi@marvell.com>
>>wrote:
>>>>> it=E2=80=99s all about IP, not layer-2.
>>>>>
>>>>> s.
>>>>
>>>> Right. However, it appears that at least in some cases a V= XLAN VTEP
>>>> will
>>use SR. It certainly may be the case in SFC use cases (see Section = 2.3
>>in draft- ietf-spring-ipv6-use-cases).
>>>>
>>>
>>> draft-ietf-6man-segment-routing-header mentions that the packe= t is
>>> encapsulated
>>
>>
>>into an outer ipv6 header which makes it a layer-3 encap.
>>
>>
>>> , but I don't think it is explicit as to exact encapsulati= on format
>>> (I suppose simple ip6ip6 is implied).
>>
>>
>>see section 2.2
>>
>>
>>> But, it
>>> seems like any of several encapsulation techniques could work = (VXLAN,
>>
>>
>>I have some problems to understand where to fit an extension header=
>>into a vxlan encap=E2=80=A6
>>
>>
>>> GRE/IP, ESP/IP, GUE, foo over UDP, etc.) and if a device that = wants
>>> to do SR is already doing tunneling it seems reasonable to me = to only
>>> have one layer of encapsulation. Maybe this should be clarifie= d in
>>> the draft?
>>
>>
>>the draft is about IPv6 extension header and more precisely a new t= ype
>>of the routing extension header defined in rfc2460. That=E2=80=99s = the context.
>>
>>
>>s.
>>
>>
>>
>>
>>>
>>> Tom
>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
>>>>> Sent: Monday, May 16, 2016 2:24 PM
>>>>> To: Tal Mizrahi
>>>>> Cc: Ole Tr=C3=B8an;
>>>>> draft-ietf-6man-segment-routing-header= @tools.ietf.org;
>>>>> s= pring@ietf.org; 6man WG
>>>>> Subject: Re: [spring] L4 Checksum and
>>>>> draft-ietf-6man-segment-routing- header
>>>>>
>>>>>
>>>>>> On May 16, 2016, at 1:19 PM, Tal Mizrahi <talmi@marvell.com>= wrote:
>>>>>>
>>>>>> Hi Stefano,
>>>>>>
>>>>>> Thanks again for the prompt response.
>>>>>>
>>>>>>> 2. the SRH is originated by the ingress node o= f the SR domain.
>>>>>>> This is done by encapsulating the packet into = a outer
>>>>>>> (additional) ipv6 header followed by an SRH. T= his is L3
>>>>>>> encapsulation and no L4 checksum is involved. = When the=C2=A0 packet
>>>>>>> leaves the SR tunnel the outer encapsulation= =C2=A0 (including the SRH)
>>>>>>> is removed and the packet continues=C2=A0 its = journey like nothing
>happened.
>>>>>>
>>>>>> So VXLAN is off the table?
>>>>>
>>>>>
>>>>> it=E2=80=99s all about IP, not layer-2.
>>>>>
>>>>> s.
>>>>>
>>>>>
>>>>>> It would be worthwhile to clarify this in the draf= t. If you have a
>>>>>> specific
>>>>> encapsulation in mind, it would be great if the draft = would specify it.
>>>>>>
>>>>>> Thanks,
>>>>>> Tal.
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]<= br> >>>>>>> Sent: Monday, May 16, 2016 2:13 PM
>>>>>>> To: Tal Mizrahi
>>>>>>> Cc: Ole Tr=C3=B8an;
>>>>>>> draft-ietf-6man-segment-routin= g-header@tools.ietf.org;
>>>>>>> spring@ietf.org; 6man WG
>>>>>>> Subject: Re: [spring] L4 Checksum and
>>>>>>> draft-ietf-6man-segment-routing- header
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On May 16, 2016, at 11:04 AM, Tal Mizrahi <= talmi@marvell.com>
>>wrote:
>>>>>>>>
>>>>>>>> Hi Stefano,
>>>>>>>>
>>>>>>>> Thanks for the responses.
>>>>>>>>
>>>>>>>>> exactly.
>>>>>>>>>
>>>>>>>>> Moreover, draft-ietf-6man-segment-rout= ing-header assumes
>>>>>>>>> encapsulation so clearly there=E2=80= =99s no L4 involved here.
>>>>>>>>>
>>>>>>>>> s.
>>>>>>>>
>>>>>>>> Two questions:
>>>>>>>> 1. What if the encapsulation is VXLAN? L4 = would still be
>>>>>>>> involved,
>>right?
>>>>>>>
>>>>>>>
>>>>>>> See below.
>>>>>>>
>>>>>>>
>>>>>>>> 2. When you say 'assumes encapsulation= ', does it mean that a
>>>>>>>> host cannot
>>>>>>> send an IPv6 packet with an SRH? The current d= raft says:
>>>>>>>>
>>>>>>>> A Source SR Node can be any node originati= ng an IPv6 packet with
>>>>>>>> its
>>>>>>>> IPv6 and Segment Routing Headers.=C2=A0 Th= is include either:
>>>>>>>>
>>>>>>>>=C2=A0 =C2=A0 A host originating an IPv6 pa= cket.
>>>>>>>>
>>>>>>>>=C2=A0 =C2=A0 An SR domain ingress router e= ncapsulating a received IPv6 packet
>>>>>>>>=C2=A0 =C2=A0 into an outer IPv6 header fol= lowed by an SRH.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Will appreciate if you can clarify that. >>>>>>>
>>>>>>>
>>>>>>> ok, two cases:
>>>>>>>
>>>>>>> 1. the SRH is inserted at the source.
>>>>>>> the source originates the packet, the ipv6 hea= der and=C2=A0 the SRH.
>>>>>>> The source computes L4 checksum taking into=C2= =A0 account the whole
>>IPv6+SRH.
>>>>>>> Here, theres=E2=80=99 nothing new=C2=A0 compar= ed to rfc2460.
>>>>>>>
>>>>>>> 2. the SRH is originated by the ingress node o= f the SR domain.
>>>>>>> This is done by encapsulating the packet into = a outer
>>>>>>> (additional) ipv6 header followed by an SRH. T= his is L3
>>>>>>> encapsulation and no L4 checksum is involved. = When the=C2=A0 packet
>>>>>>> leaves the SR tunnel the outer encapsulation= =C2=A0 (including the SRH)
>>>>>>> is removed and the packet continues=C2=A0 its = journey like nothing
>happened.
>>>>>>>
>>>>>>> s.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Tal.
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Stefano Previdi (sprevidi) [mail= to:sprevidi@cisco.c= om]
>>>>>>>>> Sent: Monday, May 16, 2016 11:59 AM >>>>>>>>> To: Ole Tr=C3=B8an; Tal Mizrahi
>>>>>>>>> Cc: draft-ietf-6man-segment-routing-header@tools.ietf.org;
>>>>>>>>> spring@ietf.org; 6man WG
>>>>>>>>> Subject: Re: [spring] L4 Checksum and<= br> >>>>>>>>> draft-ietf-6man-segment-routing- heade= r
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On May 15, 2016, at 8:06 PM, otroan@employees.org wrote:
>>>>>>>>>>
>>>>>>>>>> Tal,
>>>>>>>>>>
>>>>>>>>>>> [Apologies if this issue has b= een discussed before.]
>>>>>>>>>>>
>>>>>>>>>>> According to draft-ietf-6man-s= egment-routing-header, an =E2=80=98SR
>>>>>>>>>>> Segment
>>>>>>>>> Endpoint Node=E2=80=99 updates the Des= tination IP address.
>>>>>>>>>>> Therefore, it must also update= the Layer 4 Checksum, right?
>>>>>>>>>>>
>>>>>>>>>>> I wonder if there is an upper = bound on the size of the SRH.
>>>>>>>>>>> Otherwise, the
>>>>>>>>> L4 Checksum may be located in a pretty= deep location.
>>>>>>>>>>> Speaking from a chip vendor=E2= =80=99s perspective this may be a problem.
>>>>>>>>>>
>>>>>>>>>> From RFC2460, RH0:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>=C2=A0 =C2=A0o=C2=A0 If the IPv6 pa= cket contains a Routing header, the Destination
>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 Address used i= n the pseudo-header is that of the final
>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 destination.= =C2=A0 At the originating node, that address will be in
>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 the last eleme= nt of the Routing header; at the recipient(s),
>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 that address w= ill be in the Destination Address field of the
>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 IPv6 header. >>>>>>>>>>
>>>>>>>>>> I would expect SR would work the s= ame.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> exactly.
>>>>>>>>>
>>>>>>>>> Moreover, draft-ietf-6man-segment-rout= ing-header assumes
>>>>>>>>> encapsulation so clearly there=E2=80= =99s no L4 involved here.
>>>>>>>>>
>>>>>>>>> s.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Ole
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>> ----------------------------------------------------------= ----------
>>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> ----------------------------------------------------------= ----------
>
>_______________________________________________
>nvo3 mailing list
>nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3

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

=C2=A0


--001a11c36ed694c48705337da31d-- From nobody Mon May 23 00:54:35 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CBC12D61D; Mon, 23 May 2016 00:54:28 -0700 (PDT) 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 7gWHX8jgo45X; Mon, 23 May 2016 00:54:25 -0700 (PDT) Received: from mx0a-0016f401.pphosted.com (mx0a-0016f401.pphosted.com [67.231.148.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1472112B00E; Mon, 23 May 2016 00:54:25 -0700 (PDT) Received: from pps.filterd (m0045849.ppops.net [127.0.0.1]) by mx0a-0016f401.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u4N7pb10005541; Mon, 23 May 2016 00:54:24 -0700 Received: from il-exch01.marvell.com ([199.203.130.101]) by mx0a-0016f401.pphosted.com with ESMTP id 232n1jncr3-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 23 May 2016 00:54:23 -0700 Received: from IL-EXCH02.marvell.com (10.4.102.221) by IL-EXCH01.marvell.com (10.4.102.220) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 23 May 2016 10:54:16 +0300 Received: from IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f]) by IL-EXCH02.marvell.com ([fe80::7dee:c960:1ac6:8c1f%20]) with mapi id 15.00.1104.000; Mon, 23 May 2016 10:54:16 +0300 From: Tal Mizrahi To: Robert Raszuk , "draft-ietf-nvo3-geneve@tools.ietf.org" , "draft-ietf-nvo3-vxlan-gpe@tools.ietf.org" Thread-Topic: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment-routing-header Thread-Index: AQHRtMThJCvw5mf6XUe954CmH3IV2Z/GIJVA///SB4CAADJs4A== Date: Mon, 23 May 2016 07:54:15 +0000 Message-ID: <1c27bb3513bc48889ec310e8d143784c@IL-EXCH02.marvell.com> References: <5dc56935eba94c2390120244564f9b21@IL-EXCH02.marvell.com> <0551686F-F1D2-4C34-81C8-530F1BEE1BDF@cisco.com> <5d889e7013b44b27ae1e75cf7ea2dd22@IL-EXCH02.marvell.com> <3549ABBE-9828-42D2-A056-851432487E2E@cisco.com> <1e13d2e32b2448af94bf23d5acf17740@IL-EXCH02.marvell.com> <569a4067fd1f45dd85d60e983be69b90@IL-EXCH02.marvell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.4.102.210] Content-Type: multipart/alternative; boundary="_000_1c27bb3513bc48889ec310e8d143784cILEXCH02marvellcom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-05-23_02:, , signatures=0 X-Proofpoint-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1605230094 Archived-At: Cc: "spring@ietf.org" , "nvo3@ietf.org" , 6man WG , "Stefano Previdi \(sprevidi\)" , "draft-ietf-6man-segment-routing-header@tools.ietf.org" Subject: Re: [spring] [nvo3] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 07:54:28 -0000 --_000_1c27bb3513bc48889ec310e8d143784cILEXCH02marvellcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpUaGF0IG1ha2VzIHNlbnNlLg0KSG93ZXZlciwgaW4gdGhpcyBjYXNlIHRo ZSBmaWd1cmVzIG1heSBiZSBhIGJpdCBjb25mdXNpbmcgV1JUIHRoZSBwb3NzaWJsZSBleGlzdGVu Y2Ugb2YgZXh0ZW5zaW9uIGhlYWRlcnMuIFRoaXMgY29uZnVzaW9uIGlzIHdoYXQgbGVkIHRvIHRo ZSBkaXNjdXNzaW9uIGluIHRoaXMgdGhyZWFkIGFib3V0IHdoZXRoZXIgc2VnbWVudCByb3V0aW5n IGlzIHBvc3NpYmxlIHdpdGggVlhMQU4vVlhMQU4tR1BFL0dlbmV2ZSBlbmNhcHN1bGF0aW9ucy4N Cg0KSW4gb3JkZXIgdG8gYXZvaWQgYW1iaWd1aXR5LCBpdCB3b3VsZCBiZSBncmVhdCBpZiB0aGUg YXV0aG9ycyBjb3VsZCBleHBsaWNpdGx5IG1lbnRpb24gdGhhdCBJUHY2IGV4dGVuc2lvbiBoZWFk ZXJzIGFyZSBwZXJtaXR0ZWQuDQoNClJlZ2FyZHMsDQpUYWwuDQoNCkZyb206IHJyYXN6dWtAZ21h aWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBSb2JlcnQgUmFz enVrDQpTZW50OiBNb25kYXksIE1heSAyMywgMjAxNiAxMDo0NyBBTQ0KVG86IFRhbCBNaXpyYWhp DQpDYzogc3ByaW5nQGlldGYub3JnOyA2bWFuIFdHOyBkcmFmdC1pZXRmLW52bzMtdnhsYW4tZ3Bl QHRvb2xzLmlldGYub3JnOyBudm8zQGlldGYub3JnOyBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1y b3V0aW5nLWhlYWRlckB0b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi1udm8zLWdlbmV2ZUB0b29s cy5pZXRmLm9yZzsgU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkNClN1YmplY3Q6IFJlOiBbbnZv M10gW3NwcmluZ10gTDQgQ2hlY2tzdW0gYW5kIGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRp bmctaGVhZGVyDQoNCkhpIFRhbCwNCg0KSW5kZWVkIC4uIEkgc2F3IHRoZSBmaWd1cmVzLCBidXQg ZmlndXJlcyBhcmUgbm9uIG5vcm1hdGl2ZSBpbiBhbnkgZHJhZnQvcmZjIHVubGVzcyB0ZXh0IGJl bG93IHNwZWNpZmljYWxseSBzcGVsbHMgaXQgb3V0Lg0KDQpGb3IgZXhhbXBsZSBmcm9tIHZ4bGFu LWdwZToNCg0KIldoZW4gdGhlIG91dGVyIElQIGhlYWRlciBpcyBJUHY0LCBWVEVQcyBNVVNUIHNl dCB0aGUgREYgYml0LiINCg0KQmVzaWRlcyBpdCBpcyBwcmV0dHkgY2hhbGxlbmdpbmcgdG8gYWRk IGFuaW1hdGlvbiB0byB0aGUgY3VycmVudCBkcmFmdCBmb3JtYXRzIHRvIGlsbHVzdHJhdGUgYWxs IHBvc3NpYmx5IGFsbG93ZWQgZmllbGQgdmFsdWVzL2NvbWJpbmF0aW9ucyBpbiBhbnkgZmlndXJl IDopICBGaWd1cmVzIGp1c3QgaWxsdXN0cmF0ZSBvbmUgdXNlIGV4YW1wbGUuDQoNClRvIG1lIHRo ZSBjdXJyZW50IHNwZWNzIHBlcm1pdCBhbnkgdmFsdWUgb2YgSVB2NiBOeHRIZHIgZmllbGQgYXMg cGVybWl0dGVkIGluIGJvdGggZW5jYXBzdWxhdGlvbnMuDQoNCkJlc3QsDQpSb2JlcnQuDQoNCg0K T24gTW9uLCBNYXkgMjMsIDIwMTYgYXQgOTozNSBBTSwgVGFsIE1penJhaGkgPHRhbG1pQG1hcnZl bGwuY29tPG1haWx0bzp0YWxtaUBtYXJ2ZWxsLmNvbT4+IHdyb3RlOg0KSGkgUm9iZXJ0LA0KDQoN Cj4gV2hlcmUgc2F5IGluIGRyYWZ0IGRyYWZ0LXF1aW5uLXZ4bGFuLWdwZSBkbyB5b3Ugc2VlIHN1 Y2ggc3RhdGVtZW50IHRoYXQgd291bGQgaW1wbHkNCj4gdGhhdCB2NiBOeHRIZHIgbXVzdCBiZSBv bmx5IGVxdWFsIHRvIDE3IChVRFApIGFuZCBub3QgYmUgYSBwb2ludGVyIHRvIGFueSBvdGhlciB0 eXBlDQo+IG9mIGV4dGVuc2lvbiBoZWFkZXIgZnVydGhlciBmb2xsb3dlZCBieSBVRFAgPw0KDQoN ClRoZSBmb2xsb3dpbmcgdGV4dCBpcyBmcm9tIEZpZ3VyZSA0IGluIGRyYWZ0LWlldGYtbnZvMy12 eGxhbi1ncGU6DQoNCiAgICAgIE91dGVyIElQdjYgSGVhZGVyOg0KICAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAg ICAgIHxWZXJzaW9ufCBUcmFmZmljIENsYXNzIHwgICAgICAgICAgIEZsb3cgTGFiZWwgICAgICAg ICAgICAgICAgICB8DQogICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgICAgfCAgICAgICAgIFBheWxvYWQgTGVu Z3RoICAgICAgICB8IE54dEhkcj0xNyhVRFApfCAgIEhvcCBMaW1pdCAgIHwNCiAgICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQogICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgfA0KDQoNClRoZXJlIGlzIGEgc2ltaWxhciBmaWd1cmUgaW4gZHJh ZnQtaWV0Zi1udm8zLWdlbmV2ZS4NCg0KQmVzdCByZWdhcmRzLA0KVGFsLg0KDQpGcm9tOiBudm8z IFttYWlsdG86bnZvMy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpudm8zLWJvdW5jZXNAaWV0Zi5v cmc+XSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0KU2VudDogTW9uZGF5LCBNYXkgMjMsIDIw MTYgMTA6MjkgQU0NClRvOiBUYWwgTWl6cmFoaQ0KQ2M6IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86 c3ByaW5nQGlldGYub3JnPjsgNm1hbiBXRzsgZHJhZnQtaWV0Zi1udm8zLXZ4bGFuLWdwZUB0b29s cy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi1udm8zLXZ4bGFuLWdwZUB0b29scy5pZXRmLm9y Zz47IG52bzNAaWV0Zi5vcmc8bWFpbHRvOm52bzNAaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLTZtYW4t c2VnbWVudC1yb3V0aW5nLWhlYWRlckB0b29scy5pZXRmLm9yZzxtYWlsdG86ZHJhZnQtaWV0Zi02 bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmc+OyBkcmFmdC1pZXRmLW52 bzMtZ2VuZXZlQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLW52bzMtZ2VuZXZlQHRv b2xzLmlldGYub3JnPjsgU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkNCg0KU3ViamVjdDogUmU6 IFtudm8zXSBbc3ByaW5nXSBMNCBDaGVja3N1bSBhbmQgZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQt cm91dGluZy1oZWFkZXINCg0KSGkgVGFsLA0KDQo+IGRyYWZ0cyBzZWVtIHRvIGltcGx5DQoNCldo ZXJlIHNheSBpbiBkcmFmdCBkcmFmdC1xdWlubi12eGxhbi1ncGUgZG8geW91IHNlZSBzdWNoIHN0 YXRlbWVudCB0aGF0IHdvdWxkIGltcGx5IHRoYXQgdjYgTnh0SGRyIG11c3QgYmUgb25seSBlcXVh bCB0byAxNyAoVURQKSBhbmQgbm90IGJlIGEgcG9pbnRlciB0byBhbnkgb3RoZXIgdHlwZSBvZiBl eHRlbnNpb24gaGVhZGVyIGZ1cnRoZXIgZm9sbG93ZWQgYnkgVURQID8NCg0KVGh4LA0KUi4NCg0K DQpPbiBNb24sIE1heSAyMywgMjAxNiBhdCA3OjUwIEFNLCBUYWwgTWl6cmFoaSA8dGFsbWlAbWFy dmVsbC5jb208bWFpbHRvOnRhbG1pQG1hcnZlbGwuY29tPj4gd3JvdGU6DQpEZWFyIEF1dGhvcnMg b2YgVlhMQU4tR1BFIC8gR2VuZXZlLA0KDQpJIGFtIHJlaXRlcmF0aW5nIG9uIHRoaXMgcXVlc3Rp b24sIGFzIEkgaGF2ZW4ndCBzZWVuIGEgcmVzcG9uc2UgeWV0Og0KDQpIYXZlIHlvdSBjb25zaWRl cmVkIHRoZSB1c2Ugb2YgU2VnbWVudCBSb3V0aW5nIHdpdGggVlhMQU4tR1BFIC8gR2VuZXZlPyBU aGUgY3VycmVudCBWWExBTi1HUEUgLyBHZW5ldmUgZHJhZnRzIHNlZW0gdG8gaW1wbHkgdGhhdCBJ UHY2IGV4dGVuc2lvbiBoZWFkZXJzIGFyZSBjdXJyZW50bHkgbm90IHN1cHBvcnRlZC4NCg0KVGhh bmtzLA0KVGFsLg0KDQoNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogbnZv MyBbbWFpbHRvOm52bzMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bnZvMy1ib3VuY2VzQGlldGYu b3JnPl0gT24gQmVoYWxmIE9mIFRhbCBNaXpyYWhpDQo+U2VudDogVHVlc2RheSwgTWF5IDE3LCAy MDE2IDEyOjA5IFBNDQo+VG86IFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpOyBUb20gSGVyYmVy dDsgZHJhZnQtaWV0Zi1udm8zLQ0KPmdlbmV2ZUB0b29scy5pZXRmLm9yZzxtYWlsdG86Z2VuZXZl QHRvb2xzLmlldGYub3JnPjsgZHJhZnQtaWV0Zi1udm8zLXZ4bGFuLWdwZUB0b29scy5pZXRmLm9y ZzxtYWlsdG86ZHJhZnQtaWV0Zi1udm8zLXZ4bGFuLWdwZUB0b29scy5pZXRmLm9yZz4NCj5DYzog c3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+OyBudm8zQGlldGYub3JnPG1h aWx0bzpudm8zQGlldGYub3JnPjsgNm1hbiBXRzsgZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtDQo+ cm91dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOnJvdXRpbmctaGVhZGVyQHRvb2xz LmlldGYub3JnPg0KPlN1YmplY3Q6IFJlOiBbbnZvM10gW3NwcmluZ10gTDQgQ2hlY2tzdW0gYW5k IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LQ0KPnJvdXRpbmctaGVhZGVyDQo+DQo+U3RlZmFubywN Cj4NCj5JZiBJIHVuZGVyc3RhbmQgeW91ciBwb2ludCBjb3JyZWN0bHk6DQo+SVB2NiBzZWdtZW50 IHJvdXRpbmcgZG9lcyBub3Qgd29yayB3aXRoIFZYTEFOIC8gVlhMQU4tR1BFIC8gR2VuZXZlLCBz aW5jZQ0KPnRoZXNlIGVuY2Fwc3VsYXRpb25zIGRvIG5vdCBjdXJyZW50bHkgYWxsb3cgdGhlIHVz ZSBvZiBJUHY2IGV4dGVuc2lvbg0KPmhlYWRlcnMuDQo+DQo+SSB3b25kZXIgaWYgdGhlIGF1dGhv cnMgb2YgVlhMQU4tR1BFIGFuZCBHZW5ldmUgaGF2ZSBjb25zaWRlcmVkIHRoZSB1c2Ugb2YNCj5z ZWdtZW50IHJvdXRpbmcuDQo+DQo+VGhhbmtzLA0KPlRhbC4NCj4NCj4NCj4NCj4+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj4+RnJvbTogU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkgW21h aWx0bzpzcHJldmlkaUBjaXNjby5jb208bWFpbHRvOnNwcmV2aWRpQGNpc2NvLmNvbT5dDQo+PlNl bnQ6IFR1ZXNkYXksIE1heSAxNywgMjAxNiAxMDo0MSBBTQ0KPj5UbzogVG9tIEhlcmJlcnQNCj4+ Q2M6IFRhbCBNaXpyYWhpOyA2bWFuIFdHOyBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZz47DQo+PmRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctIGhlYWRlckB0b29s cy5pZXRmLm9yZzxtYWlsdG86aGVhZGVyQHRvb2xzLmlldGYub3JnPg0KPj5TdWJqZWN0OiBSZTog W3NwcmluZ10gTDQgQ2hlY2tzdW0gYW5kIGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmct DQo+PmhlYWRlcg0KPj4NCj4+DQo+Pj4gT24gTWF5IDE2LCAyMDE2LCBhdCA3OjEwIFBNLCBUb20g SGVyYmVydCA8dG9tQGhlcmJlcnRsYW5kLmNvbTxtYWlsdG86dG9tQGhlcmJlcnRsYW5kLmNvbT4+ DQo+d3JvdGU6DQo+Pj4NCj4+PiBPbiBNb24sIE1heSAxNiwgMjAxNiBhdCA0OjMyIEFNLCBUYWwg TWl6cmFoaSA8dGFsbWlAbWFydmVsbC5jb208bWFpbHRvOnRhbG1pQG1hcnZlbGwuY29tPj4NCj4+ d3JvdGU6DQo+Pj4+PiBpdOKAmXMgYWxsIGFib3V0IElQLCBub3QgbGF5ZXItMi4NCj4+Pj4+DQo+ Pj4+PiBzLg0KPj4+Pg0KPj4+PiBSaWdodC4gSG93ZXZlciwgaXQgYXBwZWFycyB0aGF0IGF0IGxl YXN0IGluIHNvbWUgY2FzZXMgYSBWWExBTiBWVEVQDQo+Pj4+IHdpbGwNCj4+dXNlIFNSLiBJdCBj ZXJ0YWlubHkgbWF5IGJlIHRoZSBjYXNlIGluIFNGQyB1c2UgY2FzZXMgKHNlZSBTZWN0aW9uIDIu Mw0KPj5pbiBkcmFmdC0gaWV0Zi1zcHJpbmctaXB2Ni11c2UtY2FzZXMpLg0KPj4+Pg0KPj4+DQo+ Pj4gZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXIgbWVudGlvbnMgdGhhdCB0 aGUgcGFja2V0IGlzDQo+Pj4gZW5jYXBzdWxhdGVkDQo+Pg0KPj4NCj4+aW50byBhbiBvdXRlciBp cHY2IGhlYWRlciB3aGljaCBtYWtlcyBpdCBhIGxheWVyLTMgZW5jYXAuDQo+Pg0KPj4NCj4+PiAs IGJ1dCBJIGRvbid0IHRoaW5rIGl0IGlzIGV4cGxpY2l0IGFzIHRvIGV4YWN0IGVuY2Fwc3VsYXRp b24gZm9ybWF0DQo+Pj4gKEkgc3VwcG9zZSBzaW1wbGUgaXA2aXA2IGlzIGltcGxpZWQpLg0KPj4N Cj4+DQo+PnNlZSBzZWN0aW9uIDIuMg0KPj4NCj4+DQo+Pj4gQnV0LCBpdA0KPj4+IHNlZW1zIGxp a2UgYW55IG9mIHNldmVyYWwgZW5jYXBzdWxhdGlvbiB0ZWNobmlxdWVzIGNvdWxkIHdvcmsgKFZY TEFOLA0KPj4NCj4+DQo+PkkgaGF2ZSBzb21lIHByb2JsZW1zIHRvIHVuZGVyc3RhbmQgd2hlcmUg dG8gZml0IGFuIGV4dGVuc2lvbiBoZWFkZXINCj4+aW50byBhIHZ4bGFuIGVuY2Fw4oCmDQo+Pg0K Pj4NCj4+PiBHUkUvSVAsIEVTUC9JUCwgR1VFLCBmb28gb3ZlciBVRFAsIGV0Yy4pIGFuZCBpZiBh IGRldmljZSB0aGF0IHdhbnRzDQo+Pj4gdG8gZG8gU1IgaXMgYWxyZWFkeSBkb2luZyB0dW5uZWxp bmcgaXQgc2VlbXMgcmVhc29uYWJsZSB0byBtZSB0byBvbmx5DQo+Pj4gaGF2ZSBvbmUgbGF5ZXIg b2YgZW5jYXBzdWxhdGlvbi4gTWF5YmUgdGhpcyBzaG91bGQgYmUgY2xhcmlmaWVkIGluDQo+Pj4g dGhlIGRyYWZ0Pw0KPj4NCj4+DQo+PnRoZSBkcmFmdCBpcyBhYm91dCBJUHY2IGV4dGVuc2lvbiBo ZWFkZXIgYW5kIG1vcmUgcHJlY2lzZWx5IGEgbmV3IHR5cGUNCj4+b2YgdGhlIHJvdXRpbmcgZXh0 ZW5zaW9uIGhlYWRlciBkZWZpbmVkIGluIHJmYzI0NjAuIFRoYXTigJlzIHRoZSBjb250ZXh0Lg0K Pj4NCj4+DQo+PnMuDQo+Pg0KPj4NCj4+DQo+Pg0KPj4+DQo+Pj4gVG9tDQo+Pj4NCj4+Pj4NCj4+ Pj4NCj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+PiBGcm9tOiBTdGVmYW5v IFByZXZpZGkgKHNwcmV2aWRpKSBbbWFpbHRvOnNwcmV2aWRpQGNpc2NvLmNvbTxtYWlsdG86c3By ZXZpZGlAY2lzY28uY29tPl0NCj4+Pj4+IFNlbnQ6IE1vbmRheSwgTWF5IDE2LCAyMDE2IDI6MjQg UE0NCj4+Pj4+IFRvOiBUYWwgTWl6cmFoaQ0KPj4+Pj4gQ2M6IE9sZSBUcsO4YW47DQo+Pj4+PiBk cmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlckB0b29scy5pZXRmLm9yZzxtYWls dG86ZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmc+ Ow0KPj4+Pj4gc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+OyA2bWFuIFdH DQo+Pj4+PiBTdWJqZWN0OiBSZTogW3NwcmluZ10gTDQgQ2hlY2tzdW0gYW5kDQo+Pj4+PiBkcmFm dC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLSBoZWFkZXINCj4+Pj4+DQo+Pj4+Pg0KPj4+Pj4+ IE9uIE1heSAxNiwgMjAxNiwgYXQgMToxOSBQTSwgVGFsIE1penJhaGkgPHRhbG1pQG1hcnZlbGwu Y29tPG1haWx0bzp0YWxtaUBtYXJ2ZWxsLmNvbT4+IHdyb3RlOg0KPj4+Pj4+DQo+Pj4+Pj4gSGkg U3RlZmFubywNCj4+Pj4+Pg0KPj4+Pj4+IFRoYW5rcyBhZ2FpbiBmb3IgdGhlIHByb21wdCByZXNw b25zZS4NCj4+Pj4+Pg0KPj4+Pj4+PiAyLiB0aGUgU1JIIGlzIG9yaWdpbmF0ZWQgYnkgdGhlIGlu Z3Jlc3Mgbm9kZSBvZiB0aGUgU1IgZG9tYWluLg0KPj4+Pj4+PiBUaGlzIGlzIGRvbmUgYnkgZW5j YXBzdWxhdGluZyB0aGUgcGFja2V0IGludG8gYSBvdXRlcg0KPj4+Pj4+PiAoYWRkaXRpb25hbCkg aXB2NiBoZWFkZXIgZm9sbG93ZWQgYnkgYW4gU1JILiBUaGlzIGlzIEwzDQo+Pj4+Pj4+IGVuY2Fw c3VsYXRpb24gYW5kIG5vIEw0IGNoZWNrc3VtIGlzIGludm9sdmVkLiBXaGVuIHRoZSAgcGFja2V0 DQo+Pj4+Pj4+IGxlYXZlcyB0aGUgU1IgdHVubmVsIHRoZSBvdXRlciBlbmNhcHN1bGF0aW9uICAo aW5jbHVkaW5nIHRoZSBTUkgpDQo+Pj4+Pj4+IGlzIHJlbW92ZWQgYW5kIHRoZSBwYWNrZXQgY29u dGludWVzICBpdHMgam91cm5leSBsaWtlIG5vdGhpbmcNCj5oYXBwZW5lZC4NCj4+Pj4+Pg0KPj4+ Pj4+IFNvIFZYTEFOIGlzIG9mZiB0aGUgdGFibGU/DQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+IGl04oCZ cyBhbGwgYWJvdXQgSVAsIG5vdCBsYXllci0yLg0KPj4+Pj4NCj4+Pj4+IHMuDQo+Pj4+Pg0KPj4+ Pj4NCj4+Pj4+PiBJdCB3b3VsZCBiZSB3b3J0aHdoaWxlIHRvIGNsYXJpZnkgdGhpcyBpbiB0aGUg ZHJhZnQuIElmIHlvdSBoYXZlIGENCj4+Pj4+PiBzcGVjaWZpYw0KPj4+Pj4gZW5jYXBzdWxhdGlv biBpbiBtaW5kLCBpdCB3b3VsZCBiZSBncmVhdCBpZiB0aGUgZHJhZnQgd291bGQgc3BlY2lmeSBp dC4NCj4+Pj4+Pg0KPj4+Pj4+IFRoYW5rcywNCj4+Pj4+PiBUYWwuDQo+Pj4+Pj4NCj4+Pj4+Pg0K Pj4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4+Pj4+PiBGcm9tOiBTdGVmYW5v IFByZXZpZGkgKHNwcmV2aWRpKSBbbWFpbHRvOnNwcmV2aWRpQGNpc2NvLmNvbTxtYWlsdG86c3By ZXZpZGlAY2lzY28uY29tPl0NCj4+Pj4+Pj4gU2VudDogTW9uZGF5LCBNYXkgMTYsIDIwMTYgMjox MyBQTQ0KPj4+Pj4+PiBUbzogVGFsIE1penJhaGkNCj4+Pj4+Pj4gQ2M6IE9sZSBUcsO4YW47DQo+ Pj4+Pj4+IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyQHRvb2xzLmlldGYu b3JnPG1haWx0bzpkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlckB0b29scy5p ZXRmLm9yZz47DQo+Pj4+Pj4+IHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3Jn PjsgNm1hbiBXRw0KPj4+Pj4+PiBTdWJqZWN0OiBSZTogW3NwcmluZ10gTDQgQ2hlY2tzdW0gYW5k DQo+Pj4+Pj4+IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctIGhlYWRlcg0KPj4+Pj4+ Pg0KPj4+Pj4+PiBIaSwNCj4+Pj4+Pj4NCj4+Pj4+Pj4gT24gTWF5IDE2LCAyMDE2LCBhdCAxMTow NCBBTSwgVGFsIE1penJhaGkgPHRhbG1pQG1hcnZlbGwuY29tPG1haWx0bzp0YWxtaUBtYXJ2ZWxs LmNvbT4+DQo+Pndyb3RlOg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IEhpIFN0ZWZhbm8sDQo+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4gVGhhbmtzIGZvciB0aGUgcmVzcG9uc2VzLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ PiBleGFjdGx5Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gTW9yZW92ZXIsIGRyYWZ0LWlldGYtNm1h bi1zZWdtZW50LXJvdXRpbmctaGVhZGVyIGFzc3VtZXMNCj4+Pj4+Pj4+PiBlbmNhcHN1bGF0aW9u IHNvIGNsZWFybHkgdGhlcmXigJlzIG5vIEw0IGludm9sdmVkIGhlcmUuDQo+Pj4+Pj4+Pj4NCj4+ Pj4+Pj4+PiBzLg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+IFR3byBxdWVzdGlvbnM6DQo+Pj4+Pj4+PiAx LiBXaGF0IGlmIHRoZSBlbmNhcHN1bGF0aW9uIGlzIFZYTEFOPyBMNCB3b3VsZCBzdGlsbCBiZQ0K Pj4+Pj4+Pj4gaW52b2x2ZWQsDQo+PnJpZ2h0Pw0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBT ZWUgYmVsb3cuDQo+Pj4+Pj4+DQo+Pj4+Pj4+DQo+Pj4+Pj4+PiAyLiBXaGVuIHlvdSBzYXkgJ2Fz c3VtZXMgZW5jYXBzdWxhdGlvbicsIGRvZXMgaXQgbWVhbiB0aGF0IGENCj4+Pj4+Pj4+IGhvc3Qg Y2Fubm90DQo+Pj4+Pj4+IHNlbmQgYW4gSVB2NiBwYWNrZXQgd2l0aCBhbiBTUkg/IFRoZSBjdXJy ZW50IGRyYWZ0IHNheXM6DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gQSBTb3VyY2UgU1IgTm9kZSBjYW4g YmUgYW55IG5vZGUgb3JpZ2luYXRpbmcgYW4gSVB2NiBwYWNrZXQgd2l0aA0KPj4+Pj4+Pj4gaXRz DQo+Pj4+Pj4+PiBJUHY2IGFuZCBTZWdtZW50IFJvdXRpbmcgSGVhZGVycy4gIFRoaXMgaW5jbHVk ZSBlaXRoZXI6DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gICAgQSBob3N0IG9yaWdpbmF0aW5nIGFuIElQ djYgcGFja2V0Lg0KPj4+Pj4+Pj4NCj4+Pj4+Pj4+ICAgIEFuIFNSIGRvbWFpbiBpbmdyZXNzIHJv dXRlciBlbmNhcHN1bGF0aW5nIGEgcmVjZWl2ZWQgSVB2NiBwYWNrZXQNCj4+Pj4+Pj4+ICAgIGlu dG8gYW4gb3V0ZXIgSVB2NiBoZWFkZXIgZm9sbG93ZWQgYnkgYW4gU1JILg0KPj4+Pj4+Pj4NCj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pg0KPj4+Pj4+Pj4gV2lsbCBhcHByZWNpYXRlIGlmIHlvdSBjYW4gY2xh cmlmeSB0aGF0Lg0KPj4+Pj4+Pg0KPj4+Pj4+Pg0KPj4+Pj4+PiBvaywgdHdvIGNhc2VzOg0KPj4+ Pj4+Pg0KPj4+Pj4+PiAxLiB0aGUgU1JIIGlzIGluc2VydGVkIGF0IHRoZSBzb3VyY2UuDQo+Pj4+ Pj4+IHRoZSBzb3VyY2Ugb3JpZ2luYXRlcyB0aGUgcGFja2V0LCB0aGUgaXB2NiBoZWFkZXIgYW5k ICB0aGUgU1JILg0KPj4+Pj4+PiBUaGUgc291cmNlIGNvbXB1dGVzIEw0IGNoZWNrc3VtIHRha2lu ZyBpbnRvICBhY2NvdW50IHRoZSB3aG9sZQ0KPj5JUHY2K1NSSC4NCj4+Pj4+Pj4gSGVyZSwgdGhl cmVz4oCZIG5vdGhpbmcgbmV3ICBjb21wYXJlZCB0byByZmMyNDYwLg0KPj4+Pj4+Pg0KPj4+Pj4+ PiAyLiB0aGUgU1JIIGlzIG9yaWdpbmF0ZWQgYnkgdGhlIGluZ3Jlc3Mgbm9kZSBvZiB0aGUgU1Ig ZG9tYWluLg0KPj4+Pj4+PiBUaGlzIGlzIGRvbmUgYnkgZW5jYXBzdWxhdGluZyB0aGUgcGFja2V0 IGludG8gYSBvdXRlcg0KPj4+Pj4+PiAoYWRkaXRpb25hbCkgaXB2NiBoZWFkZXIgZm9sbG93ZWQg YnkgYW4gU1JILiBUaGlzIGlzIEwzDQo+Pj4+Pj4+IGVuY2Fwc3VsYXRpb24gYW5kIG5vIEw0IGNo ZWNrc3VtIGlzIGludm9sdmVkLiBXaGVuIHRoZSAgcGFja2V0DQo+Pj4+Pj4+IGxlYXZlcyB0aGUg U1IgdHVubmVsIHRoZSBvdXRlciBlbmNhcHN1bGF0aW9uICAoaW5jbHVkaW5nIHRoZSBTUkgpDQo+ Pj4+Pj4+IGlzIHJlbW92ZWQgYW5kIHRoZSBwYWNrZXQgY29udGludWVzICBpdHMgam91cm5leSBs aWtlIG5vdGhpbmcNCj5oYXBwZW5lZC4NCj4+Pj4+Pj4NCj4+Pj4+Pj4gcy4NCj4+Pj4+Pj4NCj4+ Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4+PiBUaGFua3MsDQo+Pj4+Pj4+PiBUYWwuDQo+Pj4+Pj4+ Pg0KPj4+Pj4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+Pj4+Pj4+Pj4gRnJvbTog U3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkgW21haWx0bzpzcHJldmlkaUBjaXNjby5jb208bWFp bHRvOnNwcmV2aWRpQGNpc2NvLmNvbT5dDQo+Pj4+Pj4+Pj4gU2VudDogTW9uZGF5LCBNYXkgMTYs IDIwMTYgMTE6NTkgQU0NCj4+Pj4+Pj4+PiBUbzogT2xlIFRyw7hhbjsgVGFsIE1penJhaGkNCj4+ Pj4+Pj4+PiBDYzogZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXJAdG9vbHMu aWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyQHRv b2xzLmlldGYub3JnPjsNCj4+Pj4+Pj4+PiBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZz47IDZtYW4gV0cNCj4+Pj4+Pj4+PiBTdWJqZWN0OiBSZTogW3NwcmluZ10gTDQgQ2hl Y2tzdW0gYW5kDQo+Pj4+Pj4+Pj4gZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy0gaGVh ZGVyDQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBPbiBNYXkgMTUsIDIwMTYsIGF0 IDg6MDYgUE0sIG90cm9hbkBlbXBsb3llZXMub3JnPG1haWx0bzpvdHJvYW5AZW1wbG95ZWVzLm9y Zz4gd3JvdGU6DQo+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IFRhbCwNCj4+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+Pj4+IFtBcG9sb2dpZXMgaWYgdGhpcyBpc3N1ZSBoYXMgYmVlbiBkaXNjdXNzZWQgYmVmb3Jl Ll0NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBBY2NvcmRpbmcgdG8gZHJhZnQtaWV0Zi02bWFu LXNlZ21lbnQtcm91dGluZy1oZWFkZXIsIGFuIOKAmFNSDQo+Pj4+Pj4+Pj4+PiBTZWdtZW50DQo+ Pj4+Pj4+Pj4gRW5kcG9pbnQgTm9kZeKAmSB1cGRhdGVzIHRoZSBEZXN0aW5hdGlvbiBJUCBhZGRy ZXNzLg0KPj4+Pj4+Pj4+Pj4gVGhlcmVmb3JlLCBpdCBtdXN0IGFsc28gdXBkYXRlIHRoZSBMYXll ciA0IENoZWNrc3VtLCByaWdodD8NCj4+Pj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4+PiBJIHdvbmRlciBp ZiB0aGVyZSBpcyBhbiB1cHBlciBib3VuZCBvbiB0aGUgc2l6ZSBvZiB0aGUgU1JILg0KPj4+Pj4+ Pj4+Pj4gT3RoZXJ3aXNlLCB0aGUNCj4+Pj4+Pj4+PiBMNCBDaGVja3N1bSBtYXkgYmUgbG9jYXRl ZCBpbiBhIHByZXR0eSBkZWVwIGxvY2F0aW9uLg0KPj4+Pj4+Pj4+Pj4gU3BlYWtpbmcgZnJvbSBh IGNoaXAgdmVuZG9y4oCZcyBwZXJzcGVjdGl2ZSB0aGlzIG1heSBiZSBhIHByb2JsZW0uDQo+Pj4+ Pj4+Pj4+DQo+Pj4+Pj4+Pj4+IEZyb20gUkZDMjQ2MCwgUkgwOg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+ Pj4+Pg0KPj4+Pj4+Pj4+PiAgIG8gIElmIHRoZSBJUHY2IHBhY2tldCBjb250YWlucyBhIFJvdXRp bmcgaGVhZGVyLCB0aGUgRGVzdGluYXRpb24NCj4+Pj4+Pj4+Pj4gICAgICBBZGRyZXNzIHVzZWQg aW4gdGhlIHBzZXVkby1oZWFkZXIgaXMgdGhhdCBvZiB0aGUgZmluYWwNCj4+Pj4+Pj4+Pj4gICAg ICBkZXN0aW5hdGlvbi4gIEF0IHRoZSBvcmlnaW5hdGluZyBub2RlLCB0aGF0IGFkZHJlc3Mgd2ls bCBiZSBpbg0KPj4+Pj4+Pj4+PiAgICAgIHRoZSBsYXN0IGVsZW1lbnQgb2YgdGhlIFJvdXRpbmcg aGVhZGVyOyBhdCB0aGUgcmVjaXBpZW50KHMpLA0KPj4+Pj4+Pj4+PiAgICAgIHRoYXQgYWRkcmVz cyB3aWxsIGJlIGluIHRoZSBEZXN0aW5hdGlvbiBBZGRyZXNzIGZpZWxkIG9mIHRoZQ0KPj4+Pj4+ Pj4+PiAgICAgIElQdjYgaGVhZGVyLg0KPj4+Pj4+Pj4+Pg0KPj4+Pj4+Pj4+PiBJIHdvdWxkIGV4 cGVjdCBTUiB3b3VsZCB3b3JrIHRoZSBzYW1lLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+ Pj4+PiBleGFjdGx5Lg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4gTW9yZW92ZXIsIGRyYWZ0LWlldGYt Nm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyIGFzc3VtZXMNCj4+Pj4+Pj4+PiBlbmNhcHN1bGF0 aW9uIHNvIGNsZWFybHkgdGhlcmXigJlzIG5vIEw0IGludm9sdmVkIGhlcmUuDQo+Pj4+Pj4+Pj4N Cj4+Pj4+Pj4+PiBzLg0KPj4+Pj4+Pj4+DQo+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+ Pj4gQ2hlZXJzLA0KPj4+Pj4+Pj4+PiBPbGUNCj4+Pj4+Pj4+Pj4NCj4+Pj4+Pj4+DQo+Pj4+Pj4N Cj4+Pj4NCj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4gSUVURiBJUHY2IHdvcmtpbmcgZ3JvdXAgbWFp bGluZyBsaXN0IGlwdjZAaWV0Zi5vcmc8bWFpbHRvOmlwdjZAaWV0Zi5vcmc+IEFkbWluaXN0cmF0 aXZlDQo+Pj4+IFJlcXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2lwdjYNCj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPm52bzMgbWFpbGluZyBsaXN0DQo+bnZvM0BpZXRmLm9yZzxt YWlsdG86bnZvM0BpZXRmLm9yZz4NCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL252bzMNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQoNCg0K --_000_1c27bb3513bc48889ec310e8d143784cILEXCH02marvellcom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4w cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIFJvYmVydCw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYXQgbWFr ZXMgc2Vuc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhvd2V2ZXIsIGluIHRoaXMg Y2FzZSB0aGUgZmlndXJlcyBtYXkgYmUgYSBiaXQgY29uZnVzaW5nIFdSVCB0aGUgcG9zc2libGUg ZXhpc3RlbmNlIG9mIGV4dGVuc2lvbiBoZWFkZXJzLiBUaGlzIGNvbmZ1c2lvbiBpcyB3aGF0IGxl ZCB0byB0aGUgZGlzY3Vzc2lvbiBpbiB0aGlzDQogdGhyZWFkIGFib3V0IHdoZXRoZXIgc2VnbWVu dCByb3V0aW5nIGlzIHBvc3NpYmxlIHdpdGggVlhMQU4vVlhMQU4tR1BFL0dlbmV2ZSBlbmNhcHN1 bGF0aW9ucy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkluIG9yZGVyIHRvIGF2b2lkIGFtYmlndWl0eSwgaXQgd291bGQg YmUgZ3JlYXQgaWYgdGhlIGF1dGhvcnMgY291bGQgZXhwbGljaXRseSBtZW50aW9uIHRoYXQgSVB2 NiBleHRlbnNpb24gaGVhZGVycyBhcmUgcGVybWl0dGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+UmVnYXJkcyw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGFsLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQi Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21h aWwuY29tXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb2JlcnQgUmFzenVrPGJyPg0KPGI+U2VudDo8 L2I+IE1vbmRheSwgTWF5IDIzLCAyMDE2IDEwOjQ3IEFNPGJyPg0KPGI+VG86PC9iPiBUYWwgTWl6 cmFoaTxicj4NCjxiPkNjOjwvYj4gc3ByaW5nQGlldGYub3JnOyA2bWFuIFdHOyBkcmFmdC1pZXRm LW52bzMtdnhsYW4tZ3BlQHRvb2xzLmlldGYub3JnOyBudm8zQGlldGYub3JnOyBkcmFmdC1pZXRm LTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlckB0b29scy5pZXRmLm9yZzsgZHJhZnQtaWV0Zi1u dm8zLWdlbmV2ZUB0b29scy5pZXRmLm9yZzsgU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSk8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtudm8zXSBbc3ByaW5nXSBMNCBDaGVja3N1bSBhbmQgZHJh ZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5IaSBUYWws PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5JbmRlZWQgLi4gSSBzYXcgdGhlIGZpZ3Vy ZXMsIGJ1dCBmaWd1cmVzIGFyZSBub24gbm9ybWF0aXZlIGluIGFueSBkcmFmdC9yZmMgdW5sZXNz IHRleHQgYmVsb3cgc3BlY2lmaWNhbGx5IHNwZWxscyBpdCBvdXQuJm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gb3IgZXhhbXBsZSBmcm9tIHZ4bGFuLWdwZTombmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZxdW90OzxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+V2hlbiB0aGUgb3V0ZXIgSVAgaGVhZGVyIGlzIElQdjQsIFZURVBzIE1VU1Qgc2V0IHRoZSBE RiBiaXQuJnF1b3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QmVzaWRl cyBpdCBpcyBwcmV0dHkgY2hhbGxlbmdpbmcgdG8gYWRkIGFuaW1hdGlvbiB0byB0aGUgY3VycmVu dCBkcmFmdCBmb3JtYXRzIHRvIGlsbHVzdHJhdGUgYWxsIHBvc3NpYmx5IGFsbG93ZWQgZmllbGQg dmFsdWVzL2NvbWJpbmF0aW9ucyBpbiBhbnkgZmlndXJlIDopICZuYnNwO0ZpZ3VyZXMganVzdCBp bGx1c3RyYXRlIG9uZSB1c2UNCiBleGFtcGxlLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+VG8gbWUgdGhlIGN1cnJlbnQgc3BlY3MgcGVybWl0IGFueSB2YWx1ZSBvZiBJUHY2 IE54dEhkciBmaWVsZCBhcyBwZXJtaXR0ZWQgaW4gYm90aCBlbmNhcHN1bGF0aW9ucy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkJlc3QsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlJvYmVydC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE1heSAyMywgMjAxNiBhdCA5OjM1IEFNLCBUYWwgTWl6 cmFoaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRhbG1pQG1hcnZlbGwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+dGFsbWlAbWFydmVsbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+SGkgUm9iZXJ0LDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDs8L3NwYW4+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2hlcmUgc2F5IGluIGRyYWZ0IGRyYWZ0LXF1aW5uLXZ4 bGFuLWdwZSBkbyB5b3Ugc2VlIHN1Y2ggc3RhdGVtZW50IHRoYXQgd291bGQgaW1wbHkNCjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsgdGhhdCB2NiBOeHRIZHIgbXVzdCBiZSBv bmx5IGVxdWFsIHRvIDE3IChVRFApIGFuZCBub3QgYmUgYSBwb2ludGVyIHRvIGFueSBvdGhlciB0 eXBlDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mZ3Q7IG9mIGV4dGVuc2lvbiBo ZWFkZXIgZnVydGhlciBmb2xsb3dlZCBieSBVRFAgPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBmb2xsb3dpbmcgdGV4dCBpcyBmcm9tIEZp Z3VyZSA0IGluIGRyYWZ0LWlldGYtbnZvMy12eGxhbi1ncGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgT3V0ZXIgSVB2NiBIZWFkZXI6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzst JiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0 MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0MzstJiM0Mzs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8VmVyc2lvbnwgVHJhZmZpYyBDbGFzcyB8Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZs b3cgTGFiZWwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfDwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg fCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQYXlsb2Fk IExlbmd0aCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8IE54dEhk cj0xNyhVRFApfCZuYnNwOyZuYnNwOyBIb3AgTGltaXQmbmJzcDsmbmJzcDsgfDwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7 LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYjNDM7LSYj NDM7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt8PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhlcmUgaXMgYSBzaW1pbGFyIGZpZ3VyZSBpbiBkcmFmdC1p ZXRmLW52bzMtZ2VuZXZlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJlc3QgcmVnYXJkcyw8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5UYWwuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPiBudm8zIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm52bzMtYm91bmNl c0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm52bzMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8 Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5 LCBNYXkgMjMsIDIwMTYgMTA6MjkgQU08YnI+DQo8Yj5Ubzo8L2I+IFRhbCBNaXpyYWhpPGJyPg0K PGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+c3ByaW5nQGlldGYub3JnPC9hPjsgNm1hbiBXRzsNCjxhIGhyZWY9Im1haWx0bzpkcmFmdC1p ZXRmLW52bzMtdnhsYW4tZ3BlQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZHJhZnQt aWV0Zi1udm8zLXZ4bGFuLWdwZUB0b29scy5pZXRmLm9yZzwvYT47DQo8YSBocmVmPSJtYWlsdG86 bnZvM0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm52bzNAaWV0Zi5vcmc8L2E+OyA8YSBocmVm PSJtYWlsdG86ZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFkZXJAdG9vbHMuaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmct aGVhZGVyQHRvb2xzLmlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtbnZv My1nZW5ldmVAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LWlldGYtbnZv My1nZW5ldmVAdG9vbHMuaWV0Zi5vcmc8L2E+OyBTdGVmYW5vIFByZXZpZGkgKHNwcmV2aWRpKTwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbbnZvM10gW3NwcmluZ10gTDQgQ2hlY2tzdW0gYW5k IGRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGkgVGFsLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiZndDsmbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdDtm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5kcmFm dHMgc2VlbSB0byBpbXBseTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldoZXJl IHNheSBpbiBkcmFmdCZuYnNwO2RyYWZ0LXF1aW5uLXZ4bGFuLWdwZSBkbyB5b3Ugc2VlIHN1Y2gg c3RhdGVtZW50IHRoYXQgd291bGQgaW1wbHkgdGhhdCB2NiBOeHRIZHIgbXVzdCBiZSBvbmx5IGVx dWFsIHRvIDE3IChVRFApDQogYW5kIG5vdCBiZSBhIHBvaW50ZXIgdG8gYW55IG90aGVyIHR5cGUg b2YgZXh0ZW5zaW9uIGhlYWRlciBmdXJ0aGVyIGZvbGxvd2VkIGJ5IFVEUCA/Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGh4LDxicj4NClIuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+T24gTW9uLCBNYXkgMjMsIDIwMTYgYXQgNzo1MCBBTSwgVGFsIE1penJh aGkgJmx0OzxhIGhyZWY9Im1haWx0bzp0YWxtaUBtYXJ2ZWxsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnRhbG1pQG1hcnZlbGwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkRlYXIgQXV0aG9ycyBvZiBWWExBTi1HUEUgLyBHZW5ldmUsPGJyPg0K PGJyPg0KSSBhbSByZWl0ZXJhdGluZyBvbiB0aGlzIHF1ZXN0aW9uLCBhcyBJIGhhdmVuJ3Qgc2Vl biBhIHJlc3BvbnNlIHlldDo8YnI+DQo8YnI+DQpIYXZlIHlvdSBjb25zaWRlcmVkIHRoZSB1c2Ug b2YgU2VnbWVudCBSb3V0aW5nIHdpdGggVlhMQU4tR1BFIC8gR2VuZXZlPyBUaGUgY3VycmVudCBW WExBTi1HUEUgLyBHZW5ldmUgZHJhZnRzIHNlZW0gdG8gaW1wbHkgdGhhdCBJUHY2IGV4dGVuc2lv biBoZWFkZXJzIGFyZSBjdXJyZW50bHkgbm90IHN1cHBvcnRlZC48YnI+DQo8YnI+DQpUaGFua3Ms PGJyPg0KVGFsLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxicj4NCjxicj4NCjxicj4NCiZndDstLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxi cj4NCiZndDtGcm9tOiBudm8zIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm52bzMtYm91bmNlc0Bp ZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm52bzMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJl aGFsZiBPZiBUYWwgTWl6cmFoaTxicj4NCiZndDtTZW50OiBUdWVzZGF5LCBNYXkgMTcsIDIwMTYg MTI6MDkgUE08YnI+DQomZ3Q7VG86IFN0ZWZhbm8gUHJldmlkaSAoc3ByZXZpZGkpOyBUb20gSGVy YmVydDsgZHJhZnQtaWV0Zi1udm8zLTxicj4NCiZndDs8YSBocmVmPSJtYWlsdG86Z2VuZXZlQHRv b2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Z2VuZXZlQHRvb2xzLmlldGYub3JnPC9hPjsN CjxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLW52bzMtdnhsYW4tZ3BlQHRvb2xzLmlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+ZHJhZnQtaWV0Zi1udm8zLXZ4bGFuLWdwZUB0b29scy5pZXRmLm9y ZzwvYT48YnI+DQomZ3Q7Q2M6IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJtYWlsdG86bnZvM0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0KbnZvM0BpZXRmLm9yZzwvYT47IDZtYW4gV0c7IGRyYWZ0 LWlldGYtNm1hbi1zZWdtZW50LTxicj4NCiZndDs8YSBocmVmPSJtYWlsdG86cm91dGluZy1oZWFk ZXJAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5yb3V0aW5nLWhlYWRlckB0b29scy5p ZXRmLm9yZzwvYT48YnI+DQomZ3Q7U3ViamVjdDogUmU6IFtudm8zXSBbc3ByaW5nXSBMNCBDaGVj a3N1bSBhbmQgZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtPGJyPg0KJmd0O3JvdXRpbmctaGVhZGVy PGJyPg0KJmd0Ozxicj4NCiZndDtTdGVmYW5vLDxicj4NCiZndDs8YnI+DQomZ3Q7SWYgSSB1bmRl cnN0YW5kIHlvdXIgcG9pbnQgY29ycmVjdGx5Ojxicj4NCiZndDtJUHY2IHNlZ21lbnQgcm91dGlu ZyBkb2VzIG5vdCB3b3JrIHdpdGggVlhMQU4gLyBWWExBTi1HUEUgLyBHZW5ldmUsIHNpbmNlPGJy Pg0KJmd0O3RoZXNlIGVuY2Fwc3VsYXRpb25zIGRvIG5vdCBjdXJyZW50bHkgYWxsb3cgdGhlIHVz ZSBvZiBJUHY2IGV4dGVuc2lvbjxicj4NCiZndDtoZWFkZXJzLjxicj4NCiZndDs8YnI+DQomZ3Q7 SSB3b25kZXIgaWYgdGhlIGF1dGhvcnMgb2YgVlhMQU4tR1BFIGFuZCBHZW5ldmUgaGF2ZSBjb25z aWRlcmVkIHRoZSB1c2Ugb2Y8YnI+DQomZ3Q7c2VnbWVudCByb3V0aW5nLjxicj4NCiZndDs8YnI+ DQomZ3Q7VGhhbmtzLDxicj4NCiZndDtUYWwuPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 PGJyPg0KJmd0OyZndDstLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsmZ3Q7RnJv bTogU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkgW21haWx0bzo8YSBocmVmPSJtYWlsdG86c3By ZXZpZGlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+c3ByZXZpZGlAY2lzY28uY29tPC9hPl08 YnI+DQomZ3Q7Jmd0O1NlbnQ6IFR1ZXNkYXksIE1heSAxNywgMjAxNiAxMDo0MSBBTTxicj4NCiZn dDsmZ3Q7VG86IFRvbSBIZXJiZXJ0PGJyPg0KJmd0OyZndDtDYzogVGFsIE1penJhaGk7IDZtYW4g V0c7IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJp bmdAaWV0Zi5vcmc8L2E+Ozxicj4NCiZndDsmZ3Q7ZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91 dGluZy0gPGEgaHJlZj0ibWFpbHRvOmhlYWRlckB0b29scy5pZXRmLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPg0KaGVhZGVyQHRvb2xzLmlldGYub3JnPC9hPjxicj4NCiZndDsmZ3Q7U3ViamVjdDogUmU6 IFtzcHJpbmddIEw0IENoZWNrc3VtIGFuZCBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5n LTxicj4NCiZndDsmZ3Q7aGVhZGVyPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyBPbiBNYXkgMTYsIDIwMTYsIGF0IDc6MTAgUE0sIFRvbSBIZXJiZXJ0ICZsdDs8 YSBocmVmPSJtYWlsdG86dG9tQGhlcmJlcnRsYW5kLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnRvbUBo ZXJiZXJ0bGFuZC5jb208L2E+Jmd0Ozxicj4NCiZndDt3cm90ZTo8YnI+DQomZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsgT24gTW9uLCBNYXkgMTYsIDIwMTYgYXQgNDozMiBBTSwgVGFsIE1p enJhaGkgJmx0OzxhIGhyZWY9Im1haWx0bzp0YWxtaUBtYXJ2ZWxsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPnRhbG1pQG1hcnZlbGwuY29tPC9hPiZndDs8YnI+DQomZ3Q7Jmd0O3dyb3RlOjxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGl04oCZcyBhbGwgYWJvdXQgSVAsIG5vdCBsYXllci0yLjxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcy48YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBSaWdodC4gSG93ZXZlciwgaXQg YXBwZWFycyB0aGF0IGF0IGxlYXN0IGluIHNvbWUgY2FzZXMgYSBWWExBTiBWVEVQPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyB3aWxsPGJyPg0KJmd0OyZndDt1c2UgU1IuIEl0IGNlcnRhaW5seSBtYXkg YmUgdGhlIGNhc2UgaW4gU0ZDIHVzZSBjYXNlcyAoc2VlIFNlY3Rpb24gMi4zPGJyPg0KJmd0OyZn dDtpbiBkcmFmdC0gaWV0Zi1zcHJpbmctaXB2Ni11c2UtY2FzZXMpLjxicj4NCiZndDsmZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgZHJhZnQtaWV0Zi02bWFu LXNlZ21lbnQtcm91dGluZy1oZWFkZXIgbWVudGlvbnMgdGhhdCB0aGUgcGFja2V0IGlzPGJyPg0K Jmd0OyZndDsmZ3Q7IGVuY2Fwc3VsYXRlZDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+ DQomZ3Q7Jmd0O2ludG8gYW4gb3V0ZXIgaXB2NiBoZWFkZXIgd2hpY2ggbWFrZXMgaXQgYSBsYXll ci0zIGVuY2FwLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg LCBidXQgSSBkb24ndCB0aGluayBpdCBpcyBleHBsaWNpdCBhcyB0byBleGFjdCBlbmNhcHN1bGF0 aW9uIGZvcm1hdDxicj4NCiZndDsmZ3Q7Jmd0OyAoSSBzdXBwb3NlIHNpbXBsZSBpcDZpcDYgaXMg aW1wbGllZCkuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7c2VlIHNl Y3Rpb24gMi4yPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBC dXQsIGl0PGJyPg0KJmd0OyZndDsmZ3Q7IHNlZW1zIGxpa2UgYW55IG9mIHNldmVyYWwgZW5jYXBz dWxhdGlvbiB0ZWNobmlxdWVzIGNvdWxkIHdvcmsgKFZYTEFOLDxicj4NCiZndDsmZ3Q7PGJyPg0K Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0O0kgaGF2ZSBzb21lIHByb2JsZW1zIHRvIHVuZGVyc3RhbmQg d2hlcmUgdG8gZml0IGFuIGV4dGVuc2lvbiBoZWFkZXI8YnI+DQomZ3Q7Jmd0O2ludG8gYSB2eGxh biBlbmNhcOKApjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsg R1JFL0lQLCBFU1AvSVAsIEdVRSwgZm9vIG92ZXIgVURQLCBldGMuKSBhbmQgaWYgYSBkZXZpY2Ug dGhhdCB3YW50czxicj4NCiZndDsmZ3Q7Jmd0OyB0byBkbyBTUiBpcyBhbHJlYWR5IGRvaW5nIHR1 bm5lbGluZyBpdCBzZWVtcyByZWFzb25hYmxlIHRvIG1lIHRvIG9ubHk8YnI+DQomZ3Q7Jmd0OyZn dDsgaGF2ZSBvbmUgbGF5ZXIgb2YgZW5jYXBzdWxhdGlvbi4gTWF5YmUgdGhpcyBzaG91bGQgYmUg Y2xhcmlmaWVkIGluPGJyPg0KJmd0OyZndDsmZ3Q7IHRoZSBkcmFmdD88YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDt0aGUgZHJhZnQgaXMgYWJvdXQgSVB2NiBleHRlbnNp b24gaGVhZGVyIGFuZCBtb3JlIHByZWNpc2VseSBhIG5ldyB0eXBlPGJyPg0KJmd0OyZndDtvZiB0 aGUgcm91dGluZyBleHRlbnNpb24gaGVhZGVyIGRlZmluZWQgaW4gcmZjMjQ2MC4gVGhhdOKAmXMg dGhlIGNvbnRleHQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7cy48 YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUb208YnI+DQomZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgRnJvbTogU3RlZmFubyBQcmV2aWRpIChzcHJldmlkaSkgW21haWx0bzo8YSBocmVm PSJtYWlsdG86c3ByZXZpZGlAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+c3ByZXZpZGlAY2lz Y28uY29tPC9hPl08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTZW50OiBNb25kYXksIE1heSAx NiwgMjAxNiAyOjI0IFBNPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVG86IFRhbCBNaXpyYWhp PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2M6IE9sZSBUcsO4YW47PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOmRyYWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRp bmctaGVhZGVyQHRvb2xzLmlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpkcmFmdC1pZXRmLTZt YW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlckB0b29scy5pZXRmLm9yZzwvYT47PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT47IDZtYW4gV0c8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBTdWJqZWN0OiBSZTogW3NwcmluZ10gTDQgQ2hlY2tzdW0gYW5kPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsgZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy0gaGVhZGVyPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBNYXkgMTYsIDIwMTYsIGF0IDE6MTkgUE0sIFRhbCBNaXpy YWhpICZsdDs8YSBocmVmPSJtYWlsdG86dGFsbWlAbWFydmVsbC5jb20iIHRhcmdldD0iX2JsYW5r Ij50YWxtaUBtYXJ2ZWxsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIaSBTdGVmYW5vLDxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGFu a3MgYWdhaW4gZm9yIHRoZSBwcm9tcHQgcmVzcG9uc2UuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAyLiB0aGUgU1JIIGlzIG9y aWdpbmF0ZWQgYnkgdGhlIGluZ3Jlc3Mgbm9kZSBvZiB0aGUgU1IgZG9tYWluLjxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhpcyBpcyBkb25lIGJ5IGVuY2Fwc3VsYXRpbmcgdGhl IHBhY2tldCBpbnRvIGEgb3V0ZXI8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IChh ZGRpdGlvbmFsKSBpcHY2IGhlYWRlciBmb2xsb3dlZCBieSBhbiBTUkguIFRoaXMgaXMgTDM8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGVuY2Fwc3VsYXRpb24gYW5kIG5vIEw0IGNo ZWNrc3VtIGlzIGludm9sdmVkLiBXaGVuIHRoZSZuYnNwOyBwYWNrZXQ8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGxlYXZlcyB0aGUgU1IgdHVubmVsIHRoZSBvdXRlciBlbmNhcHN1 bGF0aW9uJm5ic3A7IChpbmNsdWRpbmcgdGhlIFNSSCk8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IGlzIHJlbW92ZWQgYW5kIHRoZSBwYWNrZXQgY29udGludWVzJm5ic3A7IGl0cyBq b3VybmV5IGxpa2Ugbm90aGluZzxicj4NCiZndDtoYXBwZW5lZC48YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU28gVlhMQU4gaXMgb2Zm IHRoZSB0YWJsZT88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXTigJlzIGFsbCBhYm91dCBJUCwgbm90 IGxheWVyLTIuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBzLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSXQgd291bGQgYmUgd29ydGh3aGlsZSB0 byBjbGFyaWZ5IHRoaXMgaW4gdGhlIGRyYWZ0LiBJZiB5b3UgaGF2ZSBhPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHNwZWNpZmljPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgZW5jYXBz dWxhdGlvbiBpbiBtaW5kLCBpdCB3b3VsZCBiZSBncmVhdCBpZiB0aGUgZHJhZnQgd291bGQgc3Bl Y2lmeSBpdC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgVGhhbmtzLDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUYWwuPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRnJvbTogU3RlZmFubyBQcmV2 aWRpIChzcHJldmlkaSkgW21haWx0bzo8YSBocmVmPSJtYWlsdG86c3ByZXZpZGlAY2lzY28uY29t IiB0YXJnZXQ9Il9ibGFuayI+c3ByZXZpZGlAY2lzY28uY29tPC9hPl08YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNlbnQ6IE1vbmRheSwgTWF5IDE2LCAyMDE2IDI6MTMgUE08YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRvOiBUYWwgTWl6cmFoaTxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQ2M6IE9sZSBUcsO4YW47PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQt cm91dGluZy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LWll dGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyQHRvb2xzLmlldGYub3JnPC9hPjs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5v cmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+OyA2bWFuIFdHPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogW3NwcmluZ10gTDQgQ2hlY2tz dW0gYW5kPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBkcmFmdC1pZXRmLTZtYW4t c2VnbWVudC1yb3V0aW5nLSBoZWFkZXI8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIaSw8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBPbiBNYXkg MTYsIDIwMTYsIGF0IDExOjA0IEFNLCBUYWwgTWl6cmFoaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRh bG1pQG1hcnZlbGwuY29tIiB0YXJnZXQ9Il9ibGFuayI+dGFsbWlAbWFydmVsbC5jb208L2E+Jmd0 Ozxicj4NCiZndDsmZ3Q7d3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBIaSBTdGVmYW5vLDxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgVGhhbmtzIGZvciB0aGUgcmVzcG9uc2VzLjxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGV4YWN0bHkuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IE1vcmVvdmVyLCBkcmFm dC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLWhlYWRlciBhc3N1bWVzPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGVuY2Fwc3VsYXRpb24gc28gY2xlYXJseSB0aGVy ZeKAmXMgbm8gTDQgaW52b2x2ZWQgaGVyZS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcy48 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IFR3byBxdWVzdGlvbnM6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgMS4gV2hhdCBpZiB0aGUgZW5jYXBzdWxhdGlvbiBpcyBWWExBTj8gTDQg d291bGQgc3RpbGwgYmU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbnZv bHZlZCw8YnI+DQomZ3Q7Jmd0O3JpZ2h0Pzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBTZWUgYmVsb3cuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyAyLiBXaGVuIHlvdSBzYXkgJ2Fzc3VtZXMgZW5jYXBzdWxhdGlvbics IGRvZXMgaXQgbWVhbiB0aGF0IGE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBob3N0IGNhbm5vdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VuZCBhbiBJ UHY2IHBhY2tldCB3aXRoIGFuIFNSSD8gVGhlIGN1cnJlbnQgZHJhZnQgc2F5czo8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEEgU291cmNlIFNSIE5vZGUgY2FuIGJlIGFueSBub2RlIG9yaWdpbmF0aW5nIGFu IElQdjYgcGFja2V0IHdpdGg8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBp dHM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJUHY2IGFuZCBTZWdtZW50 IFJvdXRpbmcgSGVhZGVycy4mbmJzcDsgVGhpcyBpbmNsdWRlIGVpdGhlcjo8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jm5ic3A7ICZuYnNwOyBBIGhvc3Qgb3JpZ2luYXRpbmcgYW4gSVB2NiBwYWNrZXQuPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgQW4gU1IgZG9tYWluIGluZ3Jlc3Mgcm91dGVy IGVuY2Fwc3VsYXRpbmcgYSByZWNlaXZlZCBJUHY2IHBhY2tldDxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jm5ic3A7ICZuYnNwOyBpbnRvIGFuIG91dGVyIElQdjYgaGVhZGVy IGZvbGxvd2VkIGJ5IGFuIFNSSC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBXaWxsIGFwcHJlY2lhdGUgaWYgeW91IGNhbiBjbGFyaWZ5IHRoYXQuPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9rLCB0d28gY2FzZXM6PGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg MS4gdGhlIFNSSCBpcyBpbnNlcnRlZCBhdCB0aGUgc291cmNlLjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgdGhlIHNvdXJjZSBvcmlnaW5hdGVzIHRoZSBwYWNrZXQsIHRoZSBpcHY2 IGhlYWRlciBhbmQmbmJzcDsgdGhlIFNSSC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IFRoZSBzb3VyY2UgY29tcHV0ZXMgTDQgY2hlY2tzdW0gdGFraW5nIGludG8mbmJzcDsgYWNj b3VudCB0aGUgd2hvbGU8YnI+DQomZ3Q7Jmd0O0lQdjYmIzQzO1NSSC48YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhlcmUsIHRoZXJlc+KAmSBub3RoaW5nIG5ldyZuYnNwOyBjb21w YXJlZCB0byByZmMyNDYwLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDIuIHRoZSBTUkggaXMgb3JpZ2luYXRlZCBieSB0 aGUgaW5ncmVzcyBub2RlIG9mIHRoZSBTUiBkb21haW4uPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBUaGlzIGlzIGRvbmUgYnkgZW5jYXBzdWxhdGluZyB0aGUgcGFja2V0IGludG8g YSBvdXRlcjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgKGFkZGl0aW9uYWwpIGlw djYgaGVhZGVyIGZvbGxvd2VkIGJ5IGFuIFNSSC4gVGhpcyBpcyBMMzxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgZW5jYXBzdWxhdGlvbiBhbmQgbm8gTDQgY2hlY2tzdW0gaXMgaW52 b2x2ZWQuIFdoZW4gdGhlJm5ic3A7IHBhY2tldDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgbGVhdmVzIHRoZSBTUiB0dW5uZWwgdGhlIG91dGVyIGVuY2Fwc3VsYXRpb24mbmJzcDsg KGluY2x1ZGluZyB0aGUgU1JIKTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXMg cmVtb3ZlZCBhbmQgdGhlIHBhY2tldCBjb250aW51ZXMmbmJzcDsgaXRzIGpvdXJuZXkgbGlrZSBu b3RoaW5nPGJyPg0KJmd0O2hhcHBlbmVkLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHMuPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBUYWwuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgRnJvbTogU3RlZmFubyBQ cmV2aWRpIChzcHJldmlkaSkgW21haWx0bzo8YSBocmVmPSJtYWlsdG86c3ByZXZpZGlAY2lzY28u Y29tIiB0YXJnZXQ9Il9ibGFuayI+c3ByZXZpZGlAY2lzY28uY29tPC9hPl08YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2VudDogTW9uZGF5LCBNYXkgMTYsIDIwMTYg MTE6NTkgQU08YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVG86IE9s ZSBUcsO4YW47IFRhbCBNaXpyYWhpPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IENjOiA8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGlu Zy1oZWFkZXJAdG9vbHMuaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4NCmRyYWZ0LWlldGYtNm1h bi1zZWdtZW50LXJvdXRpbmctaGVhZGVyQHRvb2xzLmlldGYub3JnPC9hPjs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT47IDZtYW4gV0c8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU3ViamVjdDogUmU6IFtzcHJpbmdd IEw0IENoZWNrc3VtIGFuZDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBkcmFmdC1pZXRmLTZtYW4tc2VnbWVudC1yb3V0aW5nLSBoZWFkZXI8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IE9uIE1heSAxNSwgMjAxNiwgYXQgODowNiBQTSwgPGEgaHJlZj0ibWFpbHRvOm90cm9hbkBlbXBs b3llZXMub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpvdHJvYW5AZW1wbG95ZWVzLm9yZzwvYT4gd3Jv dGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGFsLDxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBbQXBvbG9naWVzIGlmIHRoaXMgaXNzdWUgaGFzIGJl ZW4gZGlzY3Vzc2VkIGJlZm9yZS5dPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBBY2NvcmRpbmcgdG8gZHJhZnQtaWV0Zi02bWFuLXNlZ21lbnQtcm91dGluZy1oZWFk ZXIsIGFuIOKAmFNSPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgU2VnbWVudDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBF bmRwb2ludCBOb2Rl4oCZIHVwZGF0ZXMgdGhlIERlc3RpbmF0aW9uIElQIGFkZHJlc3MuPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlcmVmb3JlLCBp dCBtdXN0IGFsc28gdXBkYXRlIHRoZSBMYXllciA0IENoZWNrc3VtLCByaWdodD88YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkgd29uZGVyIGlmIHRoZXJlIGlzIGFu IHVwcGVyIGJvdW5kIG9uIHRoZSBzaXplIG9mIHRoZSBTUkguPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgT3RoZXJ3aXNlLCB0aGU8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTDQgQ2hlY2tzdW0gbWF5IGJlIGxvY2F0ZWQg aW4gYSBwcmV0dHkgZGVlcCBsb2NhdGlvbi48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTcGVha2luZyBmcm9tIGEgY2hpcCB2ZW5kb3LigJlzIHBlcnNw ZWN0aXZlIHRoaXMgbWF5IGJlIGEgcHJvYmxlbS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBGcm9tIFJGQzI0NjAsIFJIMDo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsg Jm5ic3A7byZuYnNwOyBJZiB0aGUgSVB2NiBwYWNrZXQgY29udGFpbnMgYSBSb3V0aW5nIGhlYWRl ciwgdGhlIERlc3RpbmF0aW9uPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IEFkZHJlc3MgdXNlZCBpbiB0aGUgcHNldWRvLWhl YWRlciBpcyB0aGF0IG9mIHRoZSBmaW5hbDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyBkZXN0aW5hdGlvbi4mbmJzcDsgQXQg dGhlIG9yaWdpbmF0aW5nIG5vZGUsIHRoYXQgYWRkcmVzcyB3aWxsIGJlIGluPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZuYnNwOyAmbmJzcDsgJm5ic3A7IHRo ZSBsYXN0IGVsZW1lbnQgb2YgdGhlIFJvdXRpbmcgaGVhZGVyOyBhdCB0aGUgcmVjaXBpZW50KHMp LDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmbmJzcDsgJm5i c3A7ICZuYnNwOyB0aGF0IGFkZHJlc3Mgd2lsbCBiZSBpbiB0aGUgRGVzdGluYXRpb24gQWRkcmVz cyBmaWVsZCBvZiB0aGU8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jm5ic3A7ICZuYnNwOyAmbmJzcDsgSVB2NiBoZWFkZXIuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgSSB3b3VsZCBleHBlY3QgU1Igd291bGQgd29yayB0aGUgc2FtZS48YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgZXhhY3RseS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgTW9yZW92ZXIsIGRy YWZ0LWlldGYtNm1hbi1zZWdtZW50LXJvdXRpbmctaGVhZGVyIGFzc3VtZXM8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgZW5jYXBzdWxhdGlvbiBzbyBjbGVhcmx5IHRo ZXJl4oCZcyBubyBMNCBpbnZvbHZlZCBoZXJlLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBz Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IENoZWVycyw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IE9sZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBJRVRGIElQdjYgd29ya2luZyBncm91cCBtYWls aW5nIGxpc3QgPGEgaHJlZj0ibWFpbHRvOmlwdjZAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj4N CmlwdjZAaWV0Zi5vcmc8L2E+IEFkbWluaXN0cmF0aXZlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBS ZXF1ZXN0czogPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9p cHY2IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2lwdjY8L2E+PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NCiZndDs8 YnI+DQomZ3Q7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQomZ3Q7bnZvMyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7PGEgaHJlZj0ibWFpbHRvOm52bzNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5udm8zQGlldGYub3JnPC9hPjxicj4NCiZndDs8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzMiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL252bzM8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0Kc3ByaW5nIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0i aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmciIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_1c27bb3513bc48889ec310e8d143784cILEXCH02marvellcom_-- From nobody Mon May 23 01:10:08 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3BD212D656; Mon, 23 May 2016 01:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ABO1pXu2Z_1; Mon, 23 May 2016 01:09:57 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 980C212D64D; Mon, 23 May 2016 01:09:56 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id e126so44207777lfg.2; Mon, 23 May 2016 01:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=NhDnD1GyBvFkk7+CJsCHm+pJ0i0/uudnKCMtzcQnHAc=; b=tQ1wW2hrNHibAUZKT/Jg8JwIYp5RZ4ktiRf0stkGP1xoX0MHlsKVk+78uODRyiqylY jzJ+/7Iw39olhskrbz6zTxSTAKsJryYN1/hrNvcKmeZqkzqzswwA3LtJCjafBBl84U9U EE7o9BfEuI/MxwZ4aA7JH7Z0KSuMpiNOs79q6YW5uoqt8LJN0BlSBh0xfSjOHYDyQYoD CSw7oUNcqR2xmEpxs5k2wbenTmfdBDunv3hSx55k3klWmjyR5H57HkpHOBD3hkcm/Qc+ 4+OZaAD60aVPgIUaX2MUUHjZRUQ0/5oD9RZp/l+rIu2NlFaURIhnvGsGo9ZHKFMVYMWt IeAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=NhDnD1GyBvFkk7+CJsCHm+pJ0i0/uudnKCMtzcQnHAc=; b=M349/Q5HOpfq/5TffQMQZPlTuqoczRC1YyBsMmjg2+Uata6cVRs3NFVKg3ZnhEyew1 k8Y7MTjJqxbf6inL1hqgNdZKnVoko7nPR7nTzGuZ1VnaF9DQ52PS/1sbT1q03ZJEQ+Hx SSgcy6UBWg7FAmLaWQNb7tD6FJ0JSqNwZUbZt0pxk12k18iP4MmMpyzIYYt4Az6nmx8O 1RNxnHIEKIxdo3GA0536l+6/9LmDq7/Mjth8dZLHOYpkunbD0wugWEsZL74NDyPRKMZe GcH8p9ijCJQhfLzxM5uTgxN6aE9CMnnP20Iws8SeFflCTEkrZJgrQI6sYf6MwRTTuXyg Xjdw== X-Gm-Message-State: AOPr4FXsVJUdAYPXSn7dXaaGxHRSIRCNx4GtzWCuFH96mtrlyz9FZ5pNn9IuyFFAgJ5KChg6xQa1WPw026Gl5w== MIME-Version: 1.0 X-Received: by 10.25.152.136 with SMTP id a130mr4597765lfe.104.1463990994609; Mon, 23 May 2016 01:09:54 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.126.210 with HTTP; Mon, 23 May 2016 01:09:54 -0700 (PDT) In-Reply-To: <1c27bb3513bc48889ec310e8d143784c@IL-EXCH02.marvell.com> References: <5dc56935eba94c2390120244564f9b21@IL-EXCH02.marvell.com> <0551686F-F1D2-4C34-81C8-530F1BEE1BDF@cisco.com> <5d889e7013b44b27ae1e75cf7ea2dd22@IL-EXCH02.marvell.com> <3549ABBE-9828-42D2-A056-851432487E2E@cisco.com> <1e13d2e32b2448af94bf23d5acf17740@IL-EXCH02.marvell.com> <569a4067fd1f45dd85d60e983be69b90@IL-EXCH02.marvell.com> <1c27bb3513bc48889ec310e8d143784c@IL-EXCH02.marvell.com> Date: Mon, 23 May 2016 10:09:54 +0200 X-Google-Sender-Auth: aIS4qnwx_37XzLTxkimaoLI7LWQ Message-ID: From: Robert Raszuk To: Tal Mizrahi Content-Type: multipart/alternative; boundary=001a11402cb830354505337df7cc Archived-At: Cc: "spring@ietf.org" , 6man WG , "draft-ietf-nvo3-vxlan-gpe@tools.ietf.org" , "nvo3@ietf.org" , "draft-ietf-6man-segment-routing-header@tools.ietf.org" , "draft-ietf-nvo3-geneve@tools.ietf.org" , "Stefano Previdi \(sprevidi\)" Subject: Re: [spring] [nvo3] L4 Checksum and draft-ietf-6man-segment-routing-header X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 08:10:01 -0000 --001a11402cb830354505337df7cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Tal, > In order to avoid ambiguity, it would be great if the > authors could explicitly mention that IPv6 extension > headers are permitted. Well the drafts are complaint to RFC2119 (normative reference) so unless the text excludes elements with MUST/MUST NOT - everything else defined in the building blocks they (re)use is permitted. However as you say perhaps for clarity what could be added to those drafts is a normative reference to IPv4 and IPv6 base RFCs. Best, R. On Mon, May 23, 2016 at 9:54 AM, Tal Mizrahi wrote: > Hi Robert, > > > > That makes sense. > > However, in this case the figures may be a bit confusing WRT the possible > existence of extension headers. This confusion is what led to the > discussion in this thread about whether segment routing is possible with > VXLAN/VXLAN-GPE/Geneve encapsulations. > > > > In order to avoid ambiguity, it would be great if the authors could > explicitly mention that IPv6 extension headers are permitted. > > > > Regards, > > Tal. > > > > *From:* rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of *Rober= t > Raszuk > *Sent:* Monday, May 23, 2016 10:47 AM > > *To:* Tal Mizrahi > *Cc:* spring@ietf.org; 6man WG; draft-ietf-nvo3-vxlan-gpe@tools.ietf.org; > nvo3@ietf.org; draft-ietf-6man-segment-routing-header@tools.ietf.org; > draft-ietf-nvo3-geneve@tools.ietf.org; Stefano Previdi (sprevidi) > *Subject:* Re: [nvo3] [spring] L4 Checksum and > draft-ietf-6man-segment-routing-header > > > > Hi Tal, > > > > Indeed .. I saw the figures, but figures are non normative in any > draft/rfc unless text below specifically spells it out. > > > > For example from vxlan-gpe: > > > > "When the outer IP header is IPv4, VTEPs MUST set the DF bit." > > > > Besides it is pretty challenging to add animation to the current draft > formats to illustrate all possibly allowed field values/combinations in a= ny > figure :) Figures just illustrate one use example. > > > > To me the current specs permit any value of IPv6 NxtHdr field as permitte= d > in both encapsulations. > > > > Best, > > Robert. > > > > > > On Mon, May 23, 2016 at 9:35 AM, Tal Mizrahi wrote: > > Hi Robert, > > > > > > > Where say in draft draft-quinn-vxlan-gpe do you see such statement that > would imply > > > that v6 NxtHdr must be only equal to 17 (UDP) and not be a pointer to > any other type > > > of extension header further followed by UDP ? > > > > > > The following text is from Figure 4 in draft-ietf-nvo3-vxlan-gpe: > > > > Outer IPv6 Header: > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > |Version| Traffic Class | Flow Label | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Payload Length | NxtHdr=3D17(UDP)| Hop Limit | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > > > > > There is a similar figure in draft-ietf-nvo3-geneve. > > > > Best regards, > > Tal. > > > > *From:* nvo3 [mailto:nvo3-bounces@ietf.org] *On Behalf Of *Robert Raszuk > *Sent:* Monday, May 23, 2016 10:29 AM > *To:* Tal Mizrahi > *Cc:* spring@ietf.org; 6man WG; draft-ietf-nvo3-vxlan-gpe@tools.ietf.org; > nvo3@ietf.org; draft-ietf-6man-segment-routing-header@tools.ietf.org; > draft-ietf-nvo3-geneve@tools.ietf.org; Stefano Previdi (sprevidi) > > > *Subject:* Re: [nvo3] [spring] L4 Checksum and > draft-ietf-6man-segment-routing-header > > > > Hi Tal, > > > > > drafts seem to imply > > > > Where say in draft draft-quinn-vxlan-gpe do you see such statement that > would imply that v6 NxtHdr must be only equal to 17 (UDP) and not be a > pointer to any other type of extension header further followed by UDP ? > > > > Thx, > R. > > > > > > On Mon, May 23, 2016 at 7:50 AM, Tal Mizrahi wrote: > > Dear Authors of VXLAN-GPE / Geneve, > > I am reiterating on this question, as I haven't seen a response yet: > > Have you considered the use of Segment Routing with VXLAN-GPE / Geneve? > The current VXLAN-GPE / Geneve drafts seem to imply that IPv6 extension > headers are currently not supported. > > Thanks, > Tal. > > > > > >-----Original Message----- > >From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Tal Mizrahi > >Sent: Tuesday, May 17, 2016 12:09 PM > >To: Stefano Previdi (sprevidi); Tom Herbert; draft-ietf-nvo3- > >geneve@tools.ietf.org; draft-ietf-nvo3-vxlan-gpe@tools.ietf.org > >Cc: spring@ietf.org; nvo3@ietf.org; 6man WG; draft-ietf-6man-segment- > >routing-header@tools.ietf.org > >Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment- > >routing-header > > > >Stefano, > > > >If I understand your point correctly: > >IPv6 segment routing does not work with VXLAN / VXLAN-GPE / Geneve, sinc= e > >these encapsulations do not currently allow the use of IPv6 extension > >headers. > > > >I wonder if the authors of VXLAN-GPE and Geneve have considered the use = of > >segment routing. > > > >Thanks, > >Tal. > > > > > > > >>-----Original Message----- > >>From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] > >>Sent: Tuesday, May 17, 2016 10:41 AM > >>To: Tom Herbert > >>Cc: Tal Mizrahi; 6man WG; spring@ietf.org; > >>draft-ietf-6man-segment-routing- header@tools.ietf.org > >>Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routing- > >>header > >> > >> > >>> On May 16, 2016, at 7:10 PM, Tom Herbert > >wrote: > >>> > >>> On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi > >>wrote: > >>>>> it=E2=80=99s all about IP, not layer-2. > >>>>> > >>>>> s. > >>>> > >>>> Right. However, it appears that at least in some cases a VXLAN VTEP > >>>> will > >>use SR. It certainly may be the case in SFC use cases (see Section 2.3 > >>in draft- ietf-spring-ipv6-use-cases). > >>>> > >>> > >>> draft-ietf-6man-segment-routing-header mentions that the packet is > >>> encapsulated > >> > >> > >>into an outer ipv6 header which makes it a layer-3 encap. > >> > >> > >>> , but I don't think it is explicit as to exact encapsulation format > >>> (I suppose simple ip6ip6 is implied). > >> > >> > >>see section 2.2 > >> > >> > >>> But, it > >>> seems like any of several encapsulation techniques could work (VXLAN, > >> > >> > >>I have some problems to understand where to fit an extension header > >>into a vxlan encap=E2=80=A6 > >> > >> > >>> GRE/IP, ESP/IP, GUE, foo over UDP, etc.) and if a device that wants > >>> to do SR is already doing tunneling it seems reasonable to me to only > >>> have one layer of encapsulation. Maybe this should be clarified in > >>> the draft? > >> > >> > >>the draft is about IPv6 extension header and more precisely a new type > >>of the routing extension header defined in rfc2460. That=E2=80=99s the = context. > >> > >> > >>s. > >> > >> > >> > >> > >>> > >>> Tom > >>> > >>>> > >>>> > >>>>> -----Original Message----- > >>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] > >>>>> Sent: Monday, May 16, 2016 2:24 PM > >>>>> To: Tal Mizrahi > >>>>> Cc: Ole Tr=C3=B8an; > >>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org; > >>>>> spring@ietf.org; 6man WG > >>>>> Subject: Re: [spring] L4 Checksum and > >>>>> draft-ietf-6man-segment-routing- header > >>>>> > >>>>> > >>>>>> On May 16, 2016, at 1:19 PM, Tal Mizrahi wrote= : > >>>>>> > >>>>>> Hi Stefano, > >>>>>> > >>>>>> Thanks again for the prompt response. > >>>>>> > >>>>>>> 2. the SRH is originated by the ingress node of the SR domain. > >>>>>>> This is done by encapsulating the packet into a outer > >>>>>>> (additional) ipv6 header followed by an SRH. This is L3 > >>>>>>> encapsulation and no L4 checksum is involved. When the packet > >>>>>>> leaves the SR tunnel the outer encapsulation (including the SRH) > >>>>>>> is removed and the packet continues its journey like nothing > >happened. > >>>>>> > >>>>>> So VXLAN is off the table? > >>>>> > >>>>> > >>>>> it=E2=80=99s all about IP, not layer-2. > >>>>> > >>>>> s. > >>>>> > >>>>> > >>>>>> It would be worthwhile to clarify this in the draft. If you have a > >>>>>> specific > >>>>> encapsulation in mind, it would be great if the draft would specify > it. > >>>>>> > >>>>>> Thanks, > >>>>>> Tal. > >>>>>> > >>>>>> > >>>>>>> -----Original Message----- > >>>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] > >>>>>>> Sent: Monday, May 16, 2016 2:13 PM > >>>>>>> To: Tal Mizrahi > >>>>>>> Cc: Ole Tr=C3=B8an; > >>>>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org; > >>>>>>> spring@ietf.org; 6man WG > >>>>>>> Subject: Re: [spring] L4 Checksum and > >>>>>>> draft-ietf-6man-segment-routing- header > >>>>>>> > >>>>>>> Hi, > >>>>>>> > >>>>>>> On May 16, 2016, at 11:04 AM, Tal Mizrahi > >>wrote: > >>>>>>>> > >>>>>>>> Hi Stefano, > >>>>>>>> > >>>>>>>> Thanks for the responses. > >>>>>>>> > >>>>>>>>> exactly. > >>>>>>>>> > >>>>>>>>> Moreover, draft-ietf-6man-segment-routing-header assumes > >>>>>>>>> encapsulation so clearly there=E2=80=99s no L4 involved here. > >>>>>>>>> > >>>>>>>>> s. > >>>>>>>> > >>>>>>>> Two questions: > >>>>>>>> 1. What if the encapsulation is VXLAN? L4 would still be > >>>>>>>> involved, > >>right? > >>>>>>> > >>>>>>> > >>>>>>> See below. > >>>>>>> > >>>>>>> > >>>>>>>> 2. When you say 'assumes encapsulation', does it mean that a > >>>>>>>> host cannot > >>>>>>> send an IPv6 packet with an SRH? The current draft says: > >>>>>>>> > >>>>>>>> A Source SR Node can be any node originating an IPv6 packet with > >>>>>>>> its > >>>>>>>> IPv6 and Segment Routing Headers. This include either: > >>>>>>>> > >>>>>>>> A host originating an IPv6 packet. > >>>>>>>> > >>>>>>>> An SR domain ingress router encapsulating a received IPv6 > packet > >>>>>>>> into an outer IPv6 header followed by an SRH. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> Will appreciate if you can clarify that. > >>>>>>> > >>>>>>> > >>>>>>> ok, two cases: > >>>>>>> > >>>>>>> 1. the SRH is inserted at the source. > >>>>>>> the source originates the packet, the ipv6 header and the SRH. > >>>>>>> The source computes L4 checksum taking into account the whole > >>IPv6+SRH. > >>>>>>> Here, theres=E2=80=99 nothing new compared to rfc2460. > >>>>>>> > >>>>>>> 2. the SRH is originated by the ingress node of the SR domain. > >>>>>>> This is done by encapsulating the packet into a outer > >>>>>>> (additional) ipv6 header followed by an SRH. This is L3 > >>>>>>> encapsulation and no L4 checksum is involved. When the packet > >>>>>>> leaves the SR tunnel the outer encapsulation (including the SRH) > >>>>>>> is removed and the packet continues its journey like nothing > >happened. > >>>>>>> > >>>>>>> s. > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> Tal. > >>>>>>>> > >>>>>>>>> -----Original Message----- > >>>>>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] > >>>>>>>>> Sent: Monday, May 16, 2016 11:59 AM > >>>>>>>>> To: Ole Tr=C3=B8an; Tal Mizrahi > >>>>>>>>> Cc: draft-ietf-6man-segment-routing-header@tools.ietf.org; > >>>>>>>>> spring@ietf.org; 6man WG > >>>>>>>>> Subject: Re: [spring] L4 Checksum and > >>>>>>>>> draft-ietf-6man-segment-routing- header > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> On May 15, 2016, at 8:06 PM, otroan@employees.org wrote: > >>>>>>>>>> > >>>>>>>>>> Tal, > >>>>>>>>>> > >>>>>>>>>>> [Apologies if this issue has been discussed before.] > >>>>>>>>>>> > >>>>>>>>>>> According to draft-ietf-6man-segment-routing-header, an =E2= =80=98SR > >>>>>>>>>>> Segment > >>>>>>>>> Endpoint Node=E2=80=99 updates the Destination IP address. > >>>>>>>>>>> Therefore, it must also update the Layer 4 Checksum, right? > >>>>>>>>>>> > >>>>>>>>>>> I wonder if there is an upper bound on the size of the SRH. > >>>>>>>>>>> Otherwise, the > >>>>>>>>> L4 Checksum may be located in a pretty deep location. > >>>>>>>>>>> Speaking from a chip vendor=E2=80=99s perspective this may be= a > problem. > >>>>>>>>>> > >>>>>>>>>> From RFC2460, RH0: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> o If the IPv6 packet contains a Routing header, the > Destination > >>>>>>>>>> Address used in the pseudo-header is that of the final > >>>>>>>>>> destination. At the originating node, that address will > be in > >>>>>>>>>> the last element of the Routing header; at the > recipient(s), > >>>>>>>>>> that address will be in the Destination Address field of > the > >>>>>>>>>> IPv6 header. > >>>>>>>>>> > >>>>>>>>>> I would expect SR would work the same. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> exactly. > >>>>>>>>> > >>>>>>>>> Moreover, draft-ietf-6man-segment-routing-header assumes > >>>>>>>>> encapsulation so clearly there=E2=80=99s no L4 involved here. > >>>>>>>>> > >>>>>>>>> s. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Cheers, > >>>>>>>>>> Ole > >>>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >>>> -------------------------------------------------------------------- > >>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative > >>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >>>> -------------------------------------------------------------------- > > > >_______________________________________________ > >nvo3 mailing list > >nvo3@ietf.org > >https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > > > > --001a11402cb830354505337df7cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Tal,

> In order to avoid ambiguity, it wou= ld be great if the=C2=A0
> a= uthors could explicitly mention that IPv6 extension=C2=A0
> headers are permitted.

Well the drafts are complaint t= o RFC2119 (normative reference) so unless the text excludes elements with M= UST/MUST NOT - everything else defined in the building blocks they (re)use = is permitted.=C2=A0

Ho= wever as you say perhaps for clarity what could be added to those drafts is= a normative reference to IPv4 and IPv6 base RFCs.
=
Best,
R.


On Mon, May 23, 2016 at 9:54 AM, Tal Mizrahi &= lt;talmi@marvell.com= > wrote:

Hi Robert,<= /span>

=C2=A0

That makes sense.<= u>

However, in this case the= figures may be a bit confusing WRT the possible existence of extension hea= ders. This confusion is what led to the discussion in this thread about whether segment routing is possible with VXLAN/VXLAN-GPE/Gene= ve encapsulations.

=C2=A0

In order to avoid ambigui= ty, it would be great if the authors could explicitly mention that IPv6 ext= ension headers are permitted.

=C2=A0

Regards,

Tal.=

=C2=A0

From: rraszuk@gmail.com [mail= to:rraszuk@gmail.com= ] On Behalf Of Robert Raszuk
Sent: Monday, May 23, 2016 10:47 AM


To: Tal Mizrahi
Cc: spring@ietf= .org; 6man WG; draft-ietf-nvo3-vxlan-gpe@tools.ietf.org; nvo3@ietf.org; draft-ietf-6man-segment-routing-header@tools.ietf.org; draft-ietf-n= vo3-geneve@tools.ietf.org; Stefano Previdi (sprevidi)
Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment= -routing-header

=C2=A0

Hi Tal,

=C2=A0

Indeed .. I saw the figures, but figures are non normative= in any draft/rfc unless text below specifically spells it out.=C2=A0

=C2=A0

For example from vxlan-gpe:=C2=A0

=C2=A0

"When the outer IP header= is IPv4, VTEPs MUST set the DF bit."

=C2=A0

Besides it is pretty challenging to add animation to the c= urrent draft formats to illustrate all possibly allowed field values/combin= ations in any figure :) =C2=A0Figures just illustrate one use example.=C2=A0

=C2=A0

To me the current specs permit any value of IPv6 NxtHdr fi= eld as permitted in both encapsulations.

=C2=A0

Best,

Robert.

=C2=A0

=C2=A0

On Mon, May 23, 2016 at 9:35 AM, Tal Mizrahi <talmi@marvell.com&g= t; wrote:

Hi Robert,<= u>

=C2=A0

=C2=A0

> Where say in draft draft-quinn-vxlan-gpe do you = see such statement that would imply

> that v6 NxtHdr must = be only equal to 17 (UDP) and not be a pointer to any other type

> of extension header = further followed by UDP ?

=C2=A0

=C2=A0

The following text is fro= m Figure 4 in draft-ietf-nvo3-vxlan-gpe:

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Outer IPv6 He= ader:

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

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |Version| Tra= ffic Class |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Fl= ow Label=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |

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

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Payload Length=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 | NxtHdr=3D17(UDP)|=C2=A0=C2=A0 Hop Limit=C2=A0=C2=A0 |<= /span>

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

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|<= /u>

=C2=A0

=C2=A0

There is a similar figure= in draft-ietf-nvo3-geneve.

=C2=A0

Best regards,

Tal.=

=C2=A0

From: nvo3 [ma= ilto:nvo3-bounce= s@ietf.org] On Behalf Of Robert Raszuk
Sent: Monday, May 23, 2016 10:29 AM
To: Tal Mizrahi
Cc: spring@ietf= .org; 6man WG; draft-ietf-nvo3-vxlan-gpe@tools.ietf.org; nvo3@ietf.org; draft-ietf-6man-segment-routing-header@tools.ietf.org; draft-ietf-nvo3-geneve@tools.ietf.org; Stefano Previdi (sprevidi)


Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment= -routing-header

=C2=A0

Hi Tal,

=C2=A0

>=C2=A0drafts seem to imply<= /u>

=C2=A0

Where say in draft=C2=A0draft-quinn-vxlan-gpe do you see s= uch statement that would imply that v6 NxtHdr must be only equal to 17 (UDP= ) and not be a pointer to any other type of extension header further followe= d by UDP ?=C2=A0

=C2=A0

Thx,
R.

=C2=A0

=C2=A0

On Mon, May 23, 2016 at 7:50 AM, Tal Mizrahi <talmi@marvell.com&g= t; wrote:

Dear Authors of VXLAN-GPE / Geneve,

I am reiterating on this question, as I haven't seen a response yet:
Have you considered the use of Segment Routing with VXLAN-GPE / Geneve? The= current VXLAN-GPE / Geneve drafts seem to imply that IPv6 extension header= s are currently not supported.

Thanks,
Tal.




>-----Original Message-----
>From: nvo3 [mailto:nvo3-bounces@ietf.org] On Behalf Of Tal Mizrahi
>Sent: Tuesday, May 17, 2016 12:09 PM
>To: Stefano Previdi (sprevidi); Tom Herbert; draft-ietf-nvo3-
>geneve@tools= .ietf.org; draft-ietf-nvo3-vxlan-gpe@tools.ietf.org
>Cc: spring@ietf.or= g; nvo3@ietf.org; 6man WG; draft-ietf-6man-segment-
>rout= ing-header@tools.ietf.org
>Subject: Re: [nvo3] [spring] L4 Checksum and draft-ietf-6man-segment- >routing-header
>
>Stefano,
>
>If I understand your point correctly:
>IPv6 segment routing does not work with VXLAN / VXLAN-GPE / Geneve, sin= ce
>these encapsulations do not currently allow the use of IPv6 extension >headers.
>
>I wonder if the authors of VXLAN-GPE and Geneve have considered the use= of
>segment routing.
>
>Thanks,
>Tal.
>
>
>
>>-----Original Message-----
>>From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
>>Sent: Tuesday, May 17, 2016 10:41 AM
>>To: Tom Herbert
>>Cc: Tal Mizrahi; 6man WG; spring@ietf.org;
>>draft-ietf-6man-segment-routing- header@tools.ietf.org
>>Subject: Re: [spring] L4 Checksum and draft-ietf-6man-segment-routi= ng-
>>header
>>
>>
>>> On May 16, 2016, at 7:10 PM, Tom Herbert <tom@herbertland.com>
>wrote:
>>>
>>> On Mon, May 16, 2016 at 4:32 AM, Tal Mizrahi <talmi@marvell.com>
>>wrote:
>>>>> it=E2=80=99s all about IP, not layer-2.
>>>>>
>>>>> s.
>>>>
>>>> Right. However, it appears that at least in some cases a V= XLAN VTEP
>>>> will
>>use SR. It certainly may be the case in SFC use cases (see Section = 2.3
>>in draft- ietf-spring-ipv6-use-cases).
>>>>
>>>
>>> draft-ietf-6man-segment-routing-header mentions that the packe= t is
>>> encapsulated
>>
>>
>>into an outer ipv6 header which makes it a layer-3 encap.
>>
>>
>>> , but I don't think it is explicit as to exact encapsulati= on format
>>> (I suppose simple ip6ip6 is implied).
>>
>>
>>see section 2.2
>>
>>
>>> But, it
>>> seems like any of several encapsulation techniques could work = (VXLAN,
>>
>>
>>I have some problems to understand where to fit an extension header=
>>into a vxlan encap=E2=80=A6
>>
>>
>>> GRE/IP, ESP/IP, GUE, foo over UDP, etc.) and if a device that = wants
>>> to do SR is already doing tunneling it seems reasonable to me = to only
>>> have one layer of encapsulation. Maybe this should be clarifie= d in
>>> the draft?
>>
>>
>>the draft is about IPv6 extension header and more precisely a new t= ype
>>of the routing extension header defined in rfc2460. That=E2=80=99s = the context.
>>
>>
>>s.
>>
>>
>>
>>
>>>
>>> Tom
>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
>>>>> Sent: Monday, May 16, 2016 2:24 PM
>>>>> To: Tal Mizrahi
>>>>> Cc: Ole Tr=C3=B8an;
>>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org;
>>>>> s= pring@ietf.org; 6man WG
>>>>> Subject: Re: [spring] L4 Checksum and
>>>>> draft-ietf-6man-segment-routing- header
>>>>>
>>>>>
>>>>>> On May 16, 2016, at 1:19 PM, Tal Mizrahi <talmi@marvell.com>= wrote:
>>>>>>
>>>>>> Hi Stefano,
>>>>>>
>>>>>> Thanks again for the prompt response.
>>>>>>
>>>>>>> 2. the SRH is originated by the ingress node o= f the SR domain.
>>>>>>> This is done by encapsulating the packet into = a outer
>>>>>>> (additional) ipv6 header followed by an SRH. T= his is L3
>>>>>>> encapsulation and no L4 checksum is involved. = When the=C2=A0 packet
>>>>>>> leaves the SR tunnel the outer encapsulation= =C2=A0 (including the SRH)
>>>>>>> is removed and the packet continues=C2=A0 its = journey like nothing
>happened.
>>>>>>
>>>>>> So VXLAN is off the table?
>>>>>
>>>>>
>>>>> it=E2=80=99s all about IP, not layer-2.
>>>>>
>>>>> s.
>>>>>
>>>>>
>>>>>> It would be worthwhile to clarify this in the draf= t. If you have a
>>>>>> specific
>>>>> encapsulation in mind, it would be great if the draft = would specify it.
>>>>>>
>>>>>> Thanks,
>>>>>> Tal.
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]<= br> >>>>>>> Sent: Monday, May 16, 2016 2:13 PM
>>>>>>> To: Tal Mizrahi
>>>>>>> Cc: Ole Tr=C3=B8an;
>>>>>>> draft-ietf-6man-segment-routing-header@tools.ietf.org;
>>>>>>> spring@ietf.org; 6man WG
>>>>>>> Subject: Re: [spring] L4 Checksum and
>>>>>>> draft-ietf-6man-segment-routing- header
>>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> On May 16, 2016, at 11:04 AM, Tal Mizrahi <= talmi@marvell.com>
>>wrote:
>>>>>>>>
>>>>>>>> Hi Stefano,
>>>>>>>>
>>>>>>>> Thanks for the responses.
>>>>>>>>
>>>>>>>>> exactly.
>>>>>>>>>
>>>>>>>>> Moreover, draft-ietf-6man-segment-rout= ing-header assumes
>>>>>>>>> encapsulation so clearly there=E2=80= =99s no L4 involved here.
>>>>>>>>>
>>>>>>>>> s.
>>>>>>>>
>>>>>>>> Two questions:
>>>>>>>> 1. What if the encapsulation is VXLAN? L4 = would still be
>>>>>>>> involved,
>>right?
>>>>>>>
>>>>>>>
>>>>>>> See below.
>>>>>>>
>>>>>>>
>>>>>>>> 2. When you say 'assumes encapsulation= ', does it mean that a
>>>>>>>> host cannot
>>>>>>> send an IPv6 packet with an SRH? The current d= raft says:
>>>>>>>>
>>>>>>>> A Source SR Node can be any node originati= ng an IPv6 packet with
>>>>>>>> its
>>>>>>>> IPv6 and Segment Routing Headers.=C2=A0 Th= is include either:
>>>>>>>>
>>>>>>>>=C2=A0 =C2=A0 A host originating an IPv6 pa= cket.
>>>>>>>>
>>>>>>>>=C2=A0 =C2=A0 An SR domain ingress router e= ncapsulating a received IPv6 packet
>>>>>>>>=C2=A0 =C2=A0 into an outer IPv6 header fol= lowed by an SRH.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Will appreciate if you can clarify that. >>>>>>>
>>>>>>>
>>>>>>> ok, two cases:
>>>>>>>
>>>>>>> 1. the SRH is inserted at the source.
>>>>>>> the source originates the packet, the ipv6 hea= der and=C2=A0 the SRH.
>>>>>>> The source computes L4 checksum taking into=C2= =A0 account the whole
>>IPv6+SRH.
>>>>>>> Here, theres=E2=80=99 nothing new=C2=A0 compar= ed to rfc2460.
>>>>>>>
>>>>>>> 2. the SRH is originated by the ingress node o= f the SR domain.
>>>>>>> This is done by encapsulating the packet into = a outer
>>>>>>> (additional) ipv6 header followed by an SRH. T= his is L3
>>>>>>> encapsulation and no L4 checksum is involved. = When the=C2=A0 packet
>>>>>>> leaves the SR tunnel the outer encapsulation= =C2=A0 (including the SRH)
>>>>>>> is removed and the packet continues=C2=A0 its = journey like nothing
>happened.
>>>>>>>
>>>>>>> s.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Tal.
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Stefano Previdi (sprevidi) [mail= to:sprevidi@cisco.c= om]
>>>>>>>>> Sent: Monday, May 16, 2016 11:59 AM >>>>>>>>> To: Ole Tr=C3=B8an; Tal Mizrahi
>>>>>>>>> Cc: draft-ietf-6man-segment-routing-header@tools.ietf.org;
>>>>>>>>> spring@ietf.org; 6man WG
>>>>>>>>> Subject: Re: [spring] L4 Checksum and<= br> >>>>>>>>> draft-ietf-6man-segment-routing- heade= r
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> On May 15, 2016, at 8:06 PM, otroan@employees.org wrote:
>>>>>>>>>>
>>>>>>>>>> Tal,
>>>>>>>>>>
>>>>>>>>>>> [Apologies if this issue has b= een discussed before.]
>>>>>>>>>>>
>>>>>>>>>>> According to draft-ietf-6man-s= egment-routing-header, an =E2=80=98SR
>>>>>>>>>>> Segment
>>>>>>>>> Endpoint Node=E2=80=99 updates the Des= tination IP address.
>>>>>>>>>>> Therefore, it must also update= the Layer 4 Checksum, right?
>>>>>>>>>>>
>>>>>>>>>>> I wonder if there is an upper = bound on the size of the SRH.
>>>>>>>>>>> Otherwise, the
>>>>>>>>> L4 Checksum may be located in a pretty= deep location.
>>>>>>>>>>> Speaking from a chip vendor=E2= =80=99s perspective this may be a problem.
>>>>>>>>>>
>>>>>>>>>> From RFC2460, RH0:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>=C2=A0 =C2=A0o=C2=A0 If the IPv6 pa= cket contains a Routing header, the Destination
>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 Address used i= n the pseudo-header is that of the final
>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 destination.= =C2=A0 At the originating node, that address will be in
>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 the last eleme= nt of the Routing header; at the recipient(s),
>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 that address w= ill be in the Destination Address field of the
>>>>>>>>>>=C2=A0 =C2=A0 =C2=A0 IPv6 header. >>>>>>>>>>
>>>>>>>>>> I would expect SR would work the s= ame.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> exactly.
>>>>>>>>>
>>>>>>>>> Moreover, draft-ietf-6man-segment-rout= ing-header assumes
>>>>>>>>> encapsulation so clearly there=E2=80= =99s no L4 involved here.
>>>>>>>>>
>>>>>>>>> s.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Cheers,
>>>>>>>>>> Ole
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>> ----------------------------------------------------------= ----------
>>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> ----------------------------------------------------------= ----------
>
>_______________________________________________
>nvo3 mailing list
>nvo3@ietf.org >https://www.ietf.org/mailman/listinfo/nvo3

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

=C2=A0

=C2=A0


--001a11402cb830354505337df7cc-- From nobody Mon May 23 10:42:45 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A24D12D9EE for ; Mon, 23 May 2016 10:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klO7A-c-QBbA for ; Mon, 23 May 2016 10:42:39 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A17B12D9D0 for ; Mon, 23 May 2016 10:42:38 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4NHgZg0027609 for ; Mon, 23 May 2016 18:42:35 +0100 Received: from 950129200 (jplon-nat13.juniper.net [193.110.55.13]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id u4NHgX2H027585 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Mon, 23 May 2016 18:42:35 +0100 From: "Adrian Farrel" To: Date: Mon, 23 May 2016 18:42:32 +0100 Message-ID: <01eb01d1b51a$7d44c0d0$77ce4270$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdG1GmJe5prYHLXcRbmV+j0zNVN/6g== Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22342.001 X-TM-AS-Result: No--1.259-10.0-31-10 X-imss-scan-details: No--1.259-10.0-31-10 X-TMASE-MatchedRID: UNHYJMizeW6cJAW1zaJMCnBRIrj8R47Fu2rcU2ygxCDPG88r4cu+5DLk 8G2qhCWTeAd/PTpyYH8Uc5C62VlM+XQg3fSSAxs4KWuiyZLRI4CYZJKiXhR6LQzvg1/q1MH2eDg I4iMaw3IhJ/ufappeEpGTpe1iiCJqtD9qpBlNF8rQLWxBF9DMQcRB0bsfrpPIcSqbxBgG0w7OeU hYDpKLDTlm879hveZWNw0xttaZNeBLmHwea/if6Z1t3K32SzMkDV6DA7GniOWFbxXgRQBZyRvQc Ths494OBQb0fpm0/XGl1O/WvQ0mLI9NJFPyrFBRLg4B6mj6omcF5vvBn7Kcsw== Archived-At: Subject: [spring] New draft for data center gateways X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 17:42:41 -0000 Hi, Just posted https://datatracker.ietf.org/doc/draft-drake-bess-datacenter-gateway/ We think this covers an important hole. The document defines a mechanism using the BGP Tunnel Encapsulation attribute to allow each gateway router to advertise the routes to the prefixes in the data center site to which it provides access, and also to advertise on behalf of each other gateway to the same data center site. We posted this as BESS draft, so discussion there, please until such time that the various chairs tell us to move the discussion somewhere else. Thanks, Adrian From nobody Mon May 23 11:14:49 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11CB312DA5B; Mon, 23 May 2016 11:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cp0J98LVTWpX; Mon, 23 May 2016 11:14:42 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (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 BE82612D0DE; Mon, 23 May 2016 11:14:41 -0700 (PDT) Received: by mail-lb0-x233.google.com with SMTP id ww9so58073851lbc.2; Mon, 23 May 2016 11:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=fOjztvU2+CFyeUxiW+I6PSvV3Swo6RwMC0qvvMwWS3Y=; b=XKCd4oXiiulLzIm1CYLLvXujAIlhp7YnrrUGvdmQT+wLoHNGi1oUNK5fI/242/02hq kuBT58Seq83auB0r9xusm50DfoWmlnuU2T6+d+wbpT6Rc2AGCnCo2wjZsBYibRGZ7mp+ r7HUBnErjro1x36LsBHi3NVJVniNbRc0wHEnX07Ktmqu9bCLzckrz7Kl+I9c1vu/gqm4 rKAvcYtpaHaEc5/e/8RJUWhGny18iqGoGmMsWGEx4tgza1SnVrgmG+fWrnUlAcHmmAr+ 1JHXQfWg++n0ZJdHl4uRsZoZ2fmr9wh75+jNNa4p8koMkTiUH+s/qZSlfwIU2qDiyfVg ZlXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=fOjztvU2+CFyeUxiW+I6PSvV3Swo6RwMC0qvvMwWS3Y=; b=iY0Qmwzmy3HfDvR54lsPkqnISQusFxa+O4DrGsXJLNmkuVsqnycfu6JCNhx+J9mlMn 0YyBH7Qqy0O02b022QoiEm875AagJxeGGEeLi/h5mgNZpU2c6/ANh0MHAq1crpCXxLR/ AtWnYsWpPUSevl8D6cdtoTvMk/DPhgDa/otAm/By3S8UqjnXmgAWESlfKKhorCjC9BKJ Li8Jwm1TaeAzb4wdDqNnJhDk1VUXD571pdOtsemqMWJk+puS91f5679FkQcJjezOEbyx awXALJLkPJXhvU+lh+lCy3tCoKyXW2nR0iYNxS+l738RJXIyEI60igJNXJVKDhKa4Rvf 5Xjw== X-Gm-Message-State: AOPr4FU7Nrm5oasCvintQSEJm18wodvx21l7yRX/8Gx5yrFZD533q9CD2uMrnIiX/cdr/hwNsnOooCzcBA4agQ== MIME-Version: 1.0 X-Received: by 10.112.171.229 with SMTP id ax5mr6361704lbc.115.1464027279811; Mon, 23 May 2016 11:14:39 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.126.210 with HTTP; Mon, 23 May 2016 11:14:39 -0700 (PDT) In-Reply-To: <01ea01d1b51a$7cf31e60$76d95b20$@olddog.co.uk> References: <01ea01d1b51a$7cf31e60$76d95b20$@olddog.co.uk> Date: Mon, 23 May 2016 20:14:39 +0200 X-Google-Sender-Auth: Z9SdVtFWHNYgaik99yYZjvUtN34 Message-ID: From: Robert Raszuk To: Adrian Farrel Content-Type: multipart/alternative; boundary=001a11c36ed6f46cf505338669e7 Archived-At: Cc: idr wg , "spring@ietf.org" Subject: Re: [spring] [Idr] New draft for data center gateways X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 18:14:45 -0000 --001a11c36ed6f46cf505338669e7 Content-Type: text/plain; charset=UTF-8 Hi Adrian, Many thx for sharing the document. Just starting to read it one assertion repeated at least twice got my attention: "Segment routing (SR) [I-D.ietf-spring-segment-routing] is a popular protocol mechanism for operating within a DC" By "popular protocol mechanism" when building non blocking L3 CLOS IP fabric are you referring to the below proposal or something else ? https://tools.ietf.org/html/draft-filsfils-spring-large-scale-interconnect-02 Also by "popular" do you mean something which is perhaps deployed in production to any level or author's definition of "popular" refers to something real deployment are yet to see ? Honestly having been involved in building large scale data centers for the last few years I have not see SR being anywhere close to be used there. Especially MPLS flavor of it :) If anything within DCs draft-lapukhov-bgp-sdn-00 is easy to use and provides more then sufficient flexibility within properly constructed intra-dc fabric in terms of traffic engineering. Many thx, Robert. On Mon, May 23, 2016 at 7:42 PM, Adrian Farrel wrote: > Hi, > > Just posted > https://datatracker.ietf.org/doc/draft-drake-bess-datacenter-gateway/ > > We think this covers an important hole. The document defines a mechanism > using > the BGP Tunnel Encapsulation attribute to allow each gateway router to > advertise > the routes to the prefixes in the data center site to which it provides > access, > and also to advertise on behalf of each other gateway to the same data > center > site. > > We posted this as BESS draft, so discussion there, please until such time > that > the various chairs tell us to move the discussion somewhere else. > > Thanks, > Adrian > > _______________________________________________ > Idr mailing list > Idr@ietf.org > https://www.ietf.org/mailman/listinfo/idr > --001a11c36ed6f46cf505338669e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Adrian,

=
Many thx for sharing the document. Just starting t= o read it one assertion repeated at least twice got my attention:=C2=A0

"Segment routing (SR= ) [I-D.ietf-spring-segment-routing] is a popular
protocol mechanism= for operating within a DC"

By "popular protocol mechanism" when building non bloc= king L3 CLOS IP fabric are you referring to the below proposal or something= else ?=C2=A0

htt= ps://tools.ietf.org/html/draft-filsfils-spring-large-scale-interconnect-02<= /a>

Also by "popula= r" do you mean something which is perhaps deployed in production to an= y level or author's definition of "popular" refers to somethi= ng real deployment are yet to see ?

<= div class=3D"gmail_default" style=3D"">Honestly having been involved in building large scale data centers = for the last few years I have not see SR being anywhere close to be used th= ere. Especially MPLS flavor of it :)=C2=A0

=
If anything within DCs=C2=A0draft-lapukhov-bgp-sdn-00 is eas= y to use and provides more then sufficient flexibility within properly cons= tructed intra-dc fabric in terms of traffic engineering.=C2=A0
=

Many thx,
Robert.


On Mon, May 23, 2016 at 7= :42 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi,

Just posted
https://datatracker.ietf.org/do= c/draft-drake-bess-datacenter-gateway/

We think this covers an important hole. The document defines a mechanism us= ing
the BGP Tunnel Encapsulation attribute to allow each gateway router to adve= rtise
the routes to the prefixes in the data center site to which it provides acc= ess,
and also to advertise on behalf of each other gateway to the same data cent= er
site.

We posted this as=C2=A0 BESS draft, so discussion there, please until such = time that
the various chairs tell us to move the discussion somewhere else.

Thanks,
Adrian

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

--001a11c36ed6f46cf505338669e7-- From nobody Mon May 23 13:14:27 2016 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78BF212DB4B; Mon, 23 May 2016 13:14:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 60k_ee88fKW2; Mon, 23 May 2016 13:14:19 -0700 (PDT) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E308D12DB4E; Mon, 23 May 2016 13:14:18 -0700 (PDT) Received: by mail-lf0-x22f.google.com with SMTP id k98so18772483lfi.1; Mon, 23 May 2016 13:14:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=2kDeyHDSc7khB8jmY/f0GyF3Mjuhy7QoH9ycjxxxals=; b=aYNSRIaKcexjiRCvvV2fYVZnCZJHDHnKmv50Bwl69kP6028nKgxadstLeiu7XqquRO JQEkbAWhQQYTwaumbdBi72mHfKO6dNF0C7s0OpJH/bu/bQ9irpQ+mRXW8jFwhUXWcbzz BQW/1oT5378SA7mDT7QD+O+G25PyMR6WILH//u1vv68wliIFxAT5RxswynXMgpE1sJXD YXFJOmteeucEwD3qaYzPtM82UYzHvSR9sD3n/S/SqM5Mu2RwHPGJgvC4/QlJcpvp6/yT kbaiwgPZFsimL5WeE/JuVmG3HyY1N14hlQJkzlm8J4jGPYXNDDejlVM3VRH8SeE6BrbJ PehA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=2kDeyHDSc7khB8jmY/f0GyF3Mjuhy7QoH9ycjxxxals=; b=kOfdm8XtwE24/bbr9MRVXQPuBmim/jSbdm9nIt7fKAMtb7mSa8UIPkOue7bWdh+hSV GO22yrKBEtNYeHQfUPqS5upwLjukMKsBmuQEsTDI6nkT7oqVjr0jfdQGU4LTmQWkJSwI BxtIMBB6wfVJi7IN79UCdGACUU+dQmVyJHYgliS006vT13mYeUYU/oadjFTqG66+du2R o8lNyWS4epsJU5S9hgHD6u0WRHgOnar+io51EnDw/Zm73B5jKwYKlHgeNyKp1xjspIrB Nd+m/b/GLkOzuKMaeDJWJH87mBVEcHofsh4FB1xf9lf5sgSedMgr4KZBiXftuJZiJRl+ U2IA== X-Gm-Message-State: AOPr4FX0OOjw/mDGuF4EX4VGhOVv1VzOTekNAJJ3ACZCW3YBndH0ip/ei0bzka04y3L536kMmWxM6Jj8od6SBw== MIME-Version: 1.0 X-Received: by 10.25.18.26 with SMTP id h26mr5800553lfi.110.1464034456942; Mon, 23 May 2016 13:14:16 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.25.126.210 with HTTP; Mon, 23 May 2016 13:14:16 -0700 (PDT) In-Reply-To: References: <01ea01d1b51a$7cf31e60$76d95b20$@olddog.co.uk> Date: Mon, 23 May 2016 22:14:16 +0200 X-Google-Sender-Auth: _qjQmktN64d7CqR4Y63_zC14EUc Message-ID: From: Robert Raszuk To: Adrian Farrel Content-Type: multipart/alternative; boundary=001a113f8f70bebf6a0533881518 Archived-At: Cc: idr wg , "spring@ietf.org" Subject: Re: [spring] [Idr] New draft for data center gateways X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2016 20:14:25 -0000 --001a113f8f70bebf6a0533881518 Content-Type: text/plain; charset=UTF-8 Dear Authors, Question 1: Assume that prefix X has been advertised with tunnel attribute as described in the draft with both GW1 and GW2 entry points to Egress DC site. So remote GW in Ingress DC site receives at least one such advertisement and as each contains both GW1 and GW2 entries it can engineer flows to those. So far so good ... but what happens when link between PE (on left side) and GW1 goes down ? BGP will after some time remove that path via all ASes, but GW2 will keep advertsing prefix X as still reachable via both GW1 and GW2 within tunnel encapsulation attribute as from his perspective nothing will be wrong. How remote GW in Ingress DC site is now supposed to know that GW1 link to PE in AS2 went down and stop pushing traffic towards it ? - - - Question 2: What happens if all L3 DC CLOS IP Fabrics use eBGP not IGP ? - - - Question 3: Is per prefix tunnel attribute where say /32 routes may be exchanges flat (ref calico approach - https://www.projectcalico.org/) really a scalable solution ? Best, Robert. PS. Just purely as information your inter DC traffic steering problem description is easily solved already today with one level of indirection - Example: LISP. Not sure if we need additional flat protocol extensions here. On Mon, May 23, 2016 at 8:14 PM, Robert Raszuk wrote: > Hi Adrian, > > Many thx for sharing the document. Just starting to read it one assertion > repeated at least twice got my attention: > > "Segment routing (SR) [I-D.ietf-spring-segment-routing] is a popular > protocol mechanism for operating within a DC" > > By "popular protocol mechanism" when building non blocking L3 CLOS IP > fabric are you referring to the below proposal or something else ? > > > https://tools.ietf.org/html/draft-filsfils-spring-large-scale-interconnect-02 > > Also by "popular" do you mean something which is perhaps deployed in > production to any level or author's definition of "popular" refers to > something real deployment are yet to see ? > > Honestly having been involved in building large scale data centers for the > last few years I have not see SR being anywhere close to be used there. > Especially MPLS flavor of it :) > > If anything within DCs draft-lapukhov-bgp-sdn-00 is easy to use and > provides more then sufficient flexibility within properly constructed > intra-dc fabric in terms of traffic engineering. > > Many thx, > Robert. > > > On Mon, May 23, 2016 at 7:42 PM, Adrian Farrel > wrote: > >> Hi, >> >> Just posted >> https://datatracker.ietf.org/doc/draft-drake-bess-datacenter-gateway/ >> >> We think this covers an important hole. The document defines a mechanism >> using >> the BGP Tunnel Encapsulation attribute to allow each gateway router to >> advertise >> the routes to the prefixes in the data center site to which it provides >> access, >> and also to advertise on behalf of each other gateway to the same data >> center >> site. >> >> We posted this as BESS draft, so discussion there, please until such >> time that >> the various chairs tell us to move the discussion somewhere else. >> >> Thanks, >> Adrian >> >> _______________________________________________ >> Idr mailing list >> Idr@ietf.org >> https://www.ietf.org/mailman/listinfo/idr >> > > --001a113f8f70bebf6a0533881518 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear Authors,
<= br>
Question 1:

<= div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif= ;font-size:small">Assume that prefix X has been advertised with tunnel attr= ibute as described in the draft with both GW1 and GW2 entry points to Egres= s DC site.=C2=A0

So re= mote GW in Ingress DC site receives at least one such advertisement and as = each contains both GW1 and GW2 entries it can engineer flows to those.=C2= =A0

So far so good ...= but what happens when link between PE (on left side) and GW1 goes down ?= =C2=A0

BGP will after = some time remove that path via all ASes, but GW2 will keep advertsing prefi= x X as still reachable via both GW1 and GW2 within tunnel encapsulation att= ribute as from his perspective nothing will be wrong.=C2=A0

How remote GW in Ingress DC site is n= ow supposed to know that GW1 link to PE in AS2 went down and stop pushing t= raffic towards it ?=C2=A0

- - -=C2=A0

Questi= on 2:=C2=A0

What happe= ns if all L3 DC CLOS IP Fabrics use eBGP not IGP ?=C2=A0

- - -=C2=A0

=
Question 3:=C2=A0

Is per prefix tunnel attribute where say /32 routes ma= y be exchanges flat (ref calico approach - https://www.projectcalico.org/) really a scalable solution ?= =C2=A0


Best,
Robert.

PS. Just purely as information your inter DC = traffic steering problem description is easily solved already today with on= e level of indirection - Example: LISP. Not sure if we need additional flat= protocol extensions here.=C2=A0



On Mon, May 23, 2016 at 8:14 PM, Robert Raszuk= <robert@raszuk.net> wrote:
= Hi Adrian,

Many thx for sharing the document. Just starting to read it= one assertion repeated at least twice got my attention:=C2=A0

"S= egment routing (SR) [I-D.ietf-spring-segment-routing] is a popular
protocol mechanism for o= perating within a DC"

By "popular protocol mechanism" w= hen building non blocking L3 CLOS IP fabric are you referring to the below = proposal or something else ?=C2=A0

=

Also by "popular" do you = mean something which is perhaps deployed in production to any level or auth= or's definition of "popular" refers to something real deploym= ent are yet to see ?

Ho= nestly having been involved in building large scale data centers for the la= st few years I have not see SR being anywhere close to be used there. Espec= ially MPLS flavor of it :)=C2=A0

If anything within DCs=C2=A0draft-lapukhov-bgp-sdn-00 is easy to = use and provides more then sufficient flexibility within properly construct= ed intra-dc fabric in terms of traffic engineering.=C2=A0
=
Many thx,
Robert.


On Mon, May 23, 2016 at 7:42 PM, Adrian Farrel <adrian@old= dog.co.uk> wrote:
Hi,

Just posted
https://datatracker.ietf.org/do= c/draft-drake-bess-datacenter-gateway/

We think this covers an important hole. The document defines a mechanism us= ing
the BGP Tunnel Encapsulation attribute to allow each gateway router to adve= rtise
the routes to the prefixes in the data center site to which it provides acc= ess,
and also to advertise on behalf of each other gateway to the same data cent= er
site.

We posted this as=C2=A0 BESS draft, so discussion there, please until such = time that
the various chairs tell us to move the discussion somewhere else.

Thanks,
Adrian

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


On May 14, 2016 15:40, "Les Ginsberg (ginsb= erg)" <ginsberg@cisco.com= > wrote:

Bruno =E2=80=93=

=C2=A0

I am having difficulty= parsing the examples you provide below as they seem to incorporate adverti= sement source into the description whereas the draft deliberately omits sou= rce. So it does not matter if R2 sends an advertisement or R12 sends advertisement or both of them do (which coul= d happen when an advertisement is leaked) =E2=80=93 what matters is what un= ique entries are in the database independent of source.

=C2=A0

It would be good if yo= u could present your examples using the format defined in the draft i.e.:

=C2=A0

=C2=A0=C2=A0=C2=A0 Pi - Initial prefix

=C2=A0=C2=A0=C2=A0=C2=A0 Pe - End prefix

=C2=A0=C2=A0=C2=A0=C2=A0 L -=C2=A0 Prefix length

=C2=A0=C2=A0=C2=A0=C2=A0 Lx - Maximum prefix length (32 for IPv4, 1= 28 for IPv6)

=C2=A0=C2=A0=C2=A0=C2=A0 Si - Initial SID value

=C2=A0=C2=A0=C2=A0=C2=A0 Se - End SID value

=C2=A0=C2=A0=C2=A0=C2=A0 R -=C2=A0 Range value=

=C2=A0=C2=A0=C2=A0=C2=A0 T - Topology

=C2=A0=C2=A0=C2=A0=C2=A0 A - Algorithm

=C2=A0

=C2=A0=C2=A0=C2=A0=C2=A0 A Mapping Entry is then the tuple: (Pi/L, = Si, R, T, A)

=C2=A0=C2=A0=C2=A0=C2=A0 Pe =3D (Pi + ((R-1) << (Lx-L))

=C2=A0=C2=A0=C2=A0=C2=A0 Se =3D Si + (R-1)=

=C2=A0

Example:=C2=A0 =C2=A0=C2=A0=C2=A0(192.0.2.120/32, 200, 1, 0, 0)

=C2=A0

As regards your propos= al

=C2=A0

- Find all SIDi advertised for the prefix P1=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 // identification of Prefix conflicts=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 - For each SIDi find all the prefix Pij associated= with SIDi=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0// identification of SID conflicts<= /p>

=C2=A0

Get the best as per the preference algorithm.

If best Pij =3D=3D P1

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 then use SIDij for P1

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0 else return no SID=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0

=C2=A0

this to me speci= fies an implementation =E2=80=93 which isn=E2=80=99t necessary.

=C2=A0

However, there is one = important point which has not been specified in the draft which reading you= r post has brought to my attention =E2=80=93 that is the order in which che= cks are made.

The draft states:

=C2=A0

=E2=80=9CPrefix confli= cts are specific to mapping entries sharing=C2=A0 the same topology and alg= orithm.=E2=80=9D

=E2=80=9CSID conflicts= are independent of address-family,=C2=A0 independent of prefix len, indepe= ndent of topology, and independent=C2=A0 of algorithm.=E2=80=9D

=C2=A0

If we consider an exam= ple where a network supports two VPNs, the significance of ordering in the = evaluation of conflicts will be highlighted:

=C2=A0

VPN1:

(192.0.2.1/32, 100, 1, 1, 0)<= /span>

(192.0.2.1/32, 200, 1, 1, 0)<= /span>

=C2=A0

=C2=A0

VPN2:

=C2=A0

(192.0.2.100/32, 200, 1, 2, 0)<= /u>

=C2=A0

If we evaluate prefix = conflicts first, then the following entries are =E2=80=9Cactive=E2=80=9D:

(192.0.2.1/32, 100, 1, 1, 0) !VPN1

(192.0.2.100/32, 200, 1, 2, 0) !VPN2

=C2=A0

If we evaluate SID con= flicts first, then the following entries are =E2=80=9Cactive=E2=80=9D:

(192.0.2.1/32, 100, 1, 1, 0) !VPN1

=C2=A0

The latter choice is s= uboptimal because it prevents use of the VPN2 entry unnecessarily.

=C2=A0

This point needs to be= made explicit in the draft.

=C2=A0

=C2=A0=C2=A0=C2=A0 Les=

=C2=A0

From: spring [= mailto:spring-= bounces@ietf.org] On Behalf Of bruno.decraene@orange.com
Sent: Thursday, May 12, 2016 8:23 AM
To: spring@ietf= .org
Subject: [spring] draft-ietf-spring-conflict-resolution - Policy<= /u>

=C2=A0

Hi authors, all

=C2=A0

As an individual contributor, please find below some= feedback on the policy.

=C2=A0

I'm wondering if we could address the conflict o= n a per FEC/Prefix basis rather than on a per IGP advertisement basis.

If so, this may avoid the discussion between the Qua= rantine vs ignore policy.

=C2=A0

The problem that we need to solve, is to find the SI= D for a prefix (P1).

The algo could be:

- Find all SIDi advertised for the prefix P1=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // identification of Prefix conf= licts

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 - For each SIDi find all the prefix= Pij associated with SIDi=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // identification of SID conflicts=

=C2=A0

// as a result, we get a list of SIDi =E2=80=93 Pij = for P1

=C2=A0

Get the best as per the preference algorithm.=

If best Pij =3D=3D P1

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 then use SIDij for P1=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 else return no SID=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 / no SID avail= able for this prefix P1

=C2=A0

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

=C2=A0=C2=A0 Note that it would probably be better f= or the preference algo to put the SID tie-brake before the prefix tie-break= as with the prefix tie-break, we suffer from the conflict twice (Prefix - = SID mapping, then SID- prefix mapping) which increase the diversity and hence the chance of not finding a valid entry.= =C2=A0=C2=A0 But for the below examples, I used the preference algo from dr= aft-ietf-*-00

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

=C2=A0

Below are examples, running this policy on typical c= onfiguration error cases.=C2=A0=C2=A0=C2=A0

Examples

3.4.4.=C2=A0 Network operation

=C2=A0

=C2=A0=C2=A0 Consider the following simple network e= xample:

=C2=A0

=C2=A0=C2=A0 1.=C2=A0 100 nodes: R1 to R100;<= u>

=C2=A0

=C2=A0=C2=A0 2.=C2=A0 IP Loopbacks are from 192.0.2.= 1 to 192.0.2.100:

=C2=A0

=C2=A0=C2=A0 3.=C2=A0 SID are from 1 to 100;<= u>

=C2=A0

=C2=A0=C2=A0 4.=C2=A0 R1 to R50 are SR capable and a= dvertised their own SID using

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Prefix-SID sub-= TLV;

=C2=A0

=C2=A0=C2=A0 5.=C2=A0 R51 to R100 are SR non-capable= , running LDP and their SID are

=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0advertised by t= wo redundant Mapping Server MS1 and MS2;

=C2=A0

=C2=A0=C2=A0 6.=C2=A0 As the number of nodes which a= re SR capable are expected to

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 increase and as= in real deployment their Loopback addresses would

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 no the contiguo= us, the Mapping servers advertisement covers all

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Loopbacks: (192.0.2.1/32, 1, 100);

=C2=A0

=C2=A0=C2=A0 Subsequent sections evaluate the conseq= uences of a single

=C2=A0=C2=A0 configuration error, for all conflict r= esolution options.

=C2=A0

3.4.4.1.=C2=A0 Example 1: SID configured on 1 node c= onflict with SID

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 configured on another node

=C2=A0

=C2=A0=C2=A0 Following a typo during configuration, = R2 is configured with a SID of

=C2=A0=C2=A0 12.=C2=A0 That SID conflicts with the P= refix-SID advertised by R12 and the Mapping Server Advertisement for R12.

=C2=A0=C2=A0 Note: both MS advertisement are the sam= e, so we only consider one in the below analysis.

=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0All prefix but R2 and R12, a singl= e SID is advertised and hence selected.

=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0For R2, the algo evaluates a confl= ict between the following advertisments:

=C2=A0=C2=A0 R2 - SID2 - R2 (MS, MS)

=C2=A0=C2=A0 R2 - SID12 - R12 (prefix SID, MS)

=C2=A0=C2=A0=C2=A0R2 - SID12 - R2=C2=A0 (prefix SID,= prefix SID)

=C2=A0=C2=A0

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

=C2=A0=C2=A0=C2=A0Best one is R2 - SID12 - R2 (small= er range (prefix SID),smaller range (prefix SID))

=C2=A0=C2=A0 =3D=3D> SID12 is selected for R2.=

=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0For R12, the algo evaluates a conf= lict between the following advertisments:

=C2=A0=C2=A0 R12 - SID12 - R12 (prefix SID, prefix S= ID)

=C2=A0=C2=A0 R12 - SID12 - R2=C2=A0 (prefix SID, pre= fix SID)

=C2=A0=C2=A0 R12 - SID12 - R12 (prefix SID, MS)

=C2=A0=C2=A0 R12 - SID12 - R2=C2=A0 (MS, prefix SID)=

=C2=A0=C2=A0 R12 - SID12 - R12 (MS, MS)

=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0Best one is R12 - SID12 - R2 (smal= ler range (prefix SID),smaller range (prefix SID), smaller starting adresse= (R2))

=C2=A0=C2=A0=C2=A0R12 <> R2 =3D=3D> R12 has= no SID.

=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A03.4.4.2.=C2=A0 Example 2: SID conf= igured on 1 node conflict with SID

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 configured on the Mapping Server

=C2=A0

=C2=A0=C2=A0 Following a typo during configuration, = R2 is configured with a SID of

=C2=A0=C2=A0 52.=C2=A0 That SID conflicts with the M= apping Server advertisements of MS1

=C2=A0=C2=A0 and MS2 for the loopback of R52.=

=C2=A0=C2=A0 Note: both MS advertisement are the sam= e, so we only consider one in the below analysis.

=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0All prefix but R2 and R52, a singl= e SID is advertised and hence selected.

=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0For R2, the algo evaluates a confl= ict between the following advertisments:

=C2=A0=C2=A0 R2 - SID52 - R2=C2=A0 (prefix SID, pref= ix SID)

=C2=A0=C2=A0 R2 - SID52 - R52 (prefix SID, MS)

=C2=A0=C2=A0 R2 - SID2=C2=A0 - R2=C2=A0 (MS, MS)<= /u>

=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0Best one is R2 - SID52 - R2 (small= er range (prefix SID),smaller range (prefix SID))

=C2=A0=C2=A0 =3D=3D> SID52 is selected for R2.=

=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0For R52, the algo evaluates a conf= lict between the following advertisments:

=C2=A0=C2=A0 R52 - SID52 - R52 (MS, MS)

=C2=A0=C2=A0 R52 - SID52 - R2=C2=A0 (MS, prefix SID)=

=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0Best one is R52 - SID52 - R2 (smal= ler range (prefix SID))

=C2=A0=C2=A0 R52 <> R2 =3D=3D> R52 has no S= ID.

=C2=A0=C2=A0

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

3.4.4.3.=C2=A0 Example 3: wrong configuration of a M= S

=C2=A0

=C2=A0=C2=A0 Following a typo during configuration, = MS1 is configured

=C2=A0=C2=A0 (192.0.2.0/32, 1, 100). (i.e. 192.0.2.0 instead of 192.0.2.1= ).=C2=A0 That

=C2=A0=C2=A0 advertisement conflicts with the Mappin= g Server advertisements of MS2

=C2=A0=C2=A0 and the Prefix-SID advertised by R1...R= 50.

=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0We have a conflict for all routers= except R100.

=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0For LDP only routers R51 to R99 we= have a conflict between both MS advertisement.

=C2=A0=C2=A0 For R52, the algo evaluates a conflict = between the following advertisments:

=C2=A0=C2=A0 R52 - SID52 - R52 (MS2, MS2)<= /u>

=C2=A0=C2=A0 R52 - SID52 - R51 (MS2, MS1)<= /u>

=C2=A0=C2=A0 R52 - SID53 - R52 (MS1, MS1)<= /u>

=C2=A0=C2=A0 R52 - SID53 - R53 (MS1, MS2)<= /u>

=C2=A0

=C2=A0=C2=A0 Best one is R52 - SID52 - R51 (smaller = starting address)

=C2=A0=C2=A0 R52 <> R51 =3D=3D> R52 has no = SID.

=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0For SR routers, R1 to 50, we have = a conflict between both MS advertisement and Prefix SID advertisements.<= /u>

=C2=A0=C2=A0 For R2, the algo evaluates a conflict b= etween the following advertisments:

=C2=A0=C2=A0 R2 - SID 2 - R2 (Prefix SID, Prefix SID= )

=C2=A0=C2=A0 R2 - SID 2 - R2 (Prefix SID, MS2)

=C2=A0=C2=A0 R2 - SID 2 - R1 (Prefix SID, MS1)

=C2=A0=C2=A0 R2 - SID 2 - R2 (MS2, MS2)

=C2=A0=C2=A0 R2 - SID 2 - R2 (MS2, Prefix SID)

=C2=A0=C2=A0 R2 - SID 2 - R1 (MS2, MS1)

=C2=A0=C2=A0 R2 - SID 3 - R2=C2=A0 (MS1, MS1)=

=C2=A0=C2=A0 R2 - SID 3 - R3=C2=A0 (MS1, MS2)=

=C2=A0=C2=A0 R2 - SID 3 - R3=C2=A0 (MS1, Prefix SID)=

=C2=A0=C2=A0

=C2=A0=C2=A0=C2=A0Best one is R2 - SID 2 - R2 (Prefi= x SID, Prefix SID)

=C2=A0=C2=A0 R2 =3D=3D R2 hence R2 use SID2.<= u>

=C2=A0

Regards,

Bruno

=C2=A0

____________________________________________________=
_____________________________________________________________________
=C2=A0
Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc=

pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler<=
u>
a l'expediteur et le detruire ainsi que les piec=
es jointes. Les messages electroniques etant susceptibles d'alteration,=

Orange decline toute responsabilite si ce message a =
ete altere, deforme ou falsifie. Merci.
=C2=A0
This message and its attachments may contain confide=
ntial or privileged information that may be protected by law;=

they should not be distributed, used or copied witho=
ut authorisation.
If you have received this email in error, please not=
ify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.=

Thank you.

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