From nobody Wed Jul 1 05:23:17 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2596F1A1BEF; Wed, 1 Jul 2015 05:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SOBNmWfJ1H8y; Wed, 1 Jul 2015 05:23:11 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4C41A21A4; Wed, 1 Jul 2015 05:23:10 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda13.si.francetelecom.fr (ESMTP service) with ESMTP id 2EE94190368; Wed, 1 Jul 2015 14:23:09 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.69]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id E0851180053; Wed, 1 Jul 2015 14:23:08 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%19]) with mapi id 14.03.0235.001; Wed, 1 Jul 2015 14:23:08 +0200 From: To: Uma Chunduri , "Aissaoui, Mustapha (Mustapha)" , DECRAENE Bruno IMT/OLN Thread-Topic: Conflicting MS entries Thread-Index: AQHQqFgIw0yxX2QFqkW6a4BJLQOJuJ2wTXowgAB4/oD///jw4IABHlUQgAABNmCAAbGpwIAAjYgwgAX9PxCAAAxH8IABIthAgABoG6CACbokEIABMpyw Date: Wed, 1 Jul 2015 12:23:07 +0000 Message-ID: <2725_1435753389_5593DBAC_2725_4827_1_3559c054-c3da-4ef9-b1f2-dc283b3f3479@OPEXCLILMA2.corporate.adroot.infra.ftgroup> References: <5862_1434530566_55813306_5862_129_1_0719486d-2955-432f-b6fd-44650477256f@OPEXCLILM24.corporate.adroot.infra.ftgroup> <885458B9-75C8-4654-9B12-EF1DC4D30277@cisco.com> <28410_1434552838_55818A06_28410_37_1_46370f62-b81b-4b0c-a50c-2e0aa0acd8c3@OPEXCLILM32.corporate.adroot.infra.ftgroup> <31285_1434612154_558271BA_31285_253_2_7f802e17-6d95-49f0-97e3-edf29a0302dd@OPEXCLILM33.corporate.adroot.infra.ftgroup> <31293_1434612559_5582734F_31293_5808_12_0e15d1df-4591-4e0e-9e6e-a894e1b560c2@OPEXCLILMA1.corporate.adroot.infra.ftgroup> <22234_1434705452_5583DE2C_22234_4536_1_0d3ef822-b1fc-49b5-85d7-ecc8c0ccc710@OPEXCLILM22.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340D94855471@US70UWXCHMBA01.zam.alcatel-lucent.com> <25992_1435067292_5589639C_25992_16719_7_be5cfe09-97ab-4548-bd46-8b1f38282e68@OPEXCLILM31.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD471A450@US70UWXCHMBA01.zam.alcatel-lucent.com> <5558_1435131462_558A5E46_5558_1532_1_5388a789-63fc-4ad3-ba41-4edc1b8ca892@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD471E4BA@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A60469152008633F746CB6@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A60469152008633F746CB6@eusaamb105.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] 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: 2015.7.1.103618 Archived-At: Cc: "spring@ietf.org" , "isis-wg@ietf.org list" , "Stefano Previdi \(sprevidi\)" Subject: Re: [spring] Conflicting MS entries X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2015 12:23:15 -0000 Hi Uma,=20 Pls find inline comments. -----Original Message----- From: Uma Chunduri [mailto:uma.chunduri@ericsson.com]=20 Sent: Tuesday, June 30, 2015 20:24 To: Aissaoui, Mustapha (Mustapha); DECRAENE Bruno IMT/OLN Cc: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org; isis-wg@ietf.org list; St= efano Previdi (sprevidi) Subject: RE: Conflicting MS entries Installing multiple SIDs for the same prefix in the FWD is bit off topic th= ough related to the point being discussed. Have few questions here to answer the "Conflicting MS Entries" 1. Is it a valid configuration to provision multiple global prefix SIDs fo= r any prefix ? It seems the consensus here is though one can do this there is no real= use case. [SLI] For local prefixes, I agree that there would be no use case for this = (for now). But two different nodes can advertise the same SID for different prefix, or= advertise mapping entries for the same prefix (using different range seman= tics) with different SIDs and it s harder to detect. 2. Is it a valid configuration to host a prefix on two nodes with different= global prefix SIDs? In the similar lines is it valid a configuration to host multiple MSes= and advertise different global SID indices for the same prefix? I failed to see any valid use case here too. [SLI] Agree, but even if there is no use case, such configuration can be do= ne by human error, so we need to have a consistent behavior. 3. Is it a valid configuration to host a connected or otherwise route on tw= o nodes with same prefix SID? To me answer for #1 and #2 is invalid.=20=20 #3 is valid and intention is to host a multi-homed prefix so that all node= s can compute ECMP path or prefer lower cost path to one of the nodes. [SLI] Agree, the inter-area case will also provide this kind of scenario. I prefer staying out of defining any mechanism which would be any ways in= deterministic for invalid configurations.=20 -- Uma C. -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Aissaoui, Mustap= ha (Mustapha) Sent: Wednesday, June 24, 2015 6:37 AM To: bruno.decraene@orange.com Cc: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org; isis-wg@ietf.org list; St= efano Previdi (sprevidi) Subject: Re: [spring] Conflicting MS entries Hi Bruno, Indeed what you are describing would be similar to having tunnels to the sa= me destination prefix resolved via two different protocols (LDP and SR). As= you said, maybe I am just not seeing a use case for allowing this. I can h= owever see that one can program two SIDs for the same prefix using two diff= erent SPF algorithms. Regards, Mustapha. > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of=20 > bruno.decraene@orange.com > Sent: Wednesday, June 24, 2015 3:38 AM > To: Aissaoui, Mustapha (Mustapha) > Cc: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org; isis-wg@ietf.org=20 > list; Stefano Previdi (sprevidi) > Subject: Re: [spring] Conflicting MS entries >=20 > Hi Mustapha, >=20 > > From: Aissaoui, Mustapha (Mustapha) > > [mailto:mustapha.aissaoui@alcatel- > > lucent.com] > > Sent: Tuesday, June 23, 2015 10:34 PM > > > > Hi Bruno, > > I can see that one can program multiple SIDs if these are for routes=20 > > of the same prefix which are advertised in multiple ISIS instances=20 > > or in multiple topologies. But within a single instance and=20 > > topology, how do you reconcile the multiple MS entries with a single=20 > > active route to that > destination prefix? >=20 > I'm probably missing something, but I don't see a need to reconcile. I=20 > see 2 LSPs and for each a (N:1) indirection between the (label, FEC > element) and the IP FIB. A bit similar to multiple BGP routes using=20 > the same IP prefix to resolve their BGP Next-Hop. >=20 > e.g. MS advertises 2 SIDs for prefix1 --> (via SRGBs) 2 incoming & 2=20 > outgoings labels. LL1, LL2 for local/incoming labels. LN1, LN2 for neighb= or/outgoing label. > IP FIB: > Prefix1 --> eth1 >=20 > NHLFE: > LFE1: eth1, swap LN1 > LFE2: eth1, swap LN2 >=20 > ILM: > LL1 --> LFE1 > LL2 --> LFE2 >=20 >=20 > Looks also similar to the case where a node(LSR) is both SR & LDP and=20 > for the same FEC element/IP prefix gets 1 label from LDP and 1 from SR/M= S. >=20 > That being said, if we are all in favor of selecting a single MS=20 > entry, the discussion is purely theoretical. >=20 > /Bruno >=20 > > Mustapha. > > > > > -----Original Message----- > > > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of=20 > > > bruno.decraene@orange.com > > > Sent: Tuesday, June 23, 2015 9:48 AM > > > To: Aissaoui, Mustapha (Mustapha) > > > Cc: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org; isis-wg@ietf.org=20 > > > list; Stefano Previdi (sprevidi) > > > Subject: Re: [spring] Conflicting MS entries > > > > > > Hi Mustapha, > > > > > > Thanks for the discussion. Please see inline. > > > > > > > From: Aissaoui, Mustapha (Mustapha)=20 > > > > [mailto:mustapha.aissaoui@alcatel-> lucent.com] > Sent: Friday,=20 > > > > June 19, 2015 8:19 PM > > > > > > > > Hi Stephane and Bruno, > > > > I do not think programming multiple SIDs makes sense. While=20 > > > > there are multiple MS prefix sub-TLVs, there is only single=20 > > > > active route for the prefix with potentially ECMP next-hops=20 > > > > which was resolved from a received IP reachability TLV. > > > > > > I don't see what prevents us from programming multiple SIDs/labels=20 > > > for a single prefix. i.e. setting up multiple LSPs for a given prefix. > > > e.g. BGP seems to specifically allow for this > > > https://tools.ietf.org/html/rfc3107#section-4 > > > > > > That being said: > > > - I'm not seeing benefit (which, may be, is what you meant by=20 > > > "makes no sense") > > > - St=E9phane expressed that from an operational point, this may make= =20 > > > things > > harder. > > > - eventually some implementation may find this harder compared to=20 > > > having a single one. > > > > > > So, so far, it looks like everyone expressed a preference to use=20 > > > only one, based on deterministic criteria. > > > > > > > I agree that selecting one of the entries is preferable to dropping= traffic. > > > Ok. > > > > > > > We > > > > could come up with selection criteria but the reality is that=20 > > > > there no way for the router to check if any of the MS entries is=20 > > > > legitimate or > not. > > > > > > What do you mean by "legitimate"? > > > In case of multiple SID advertisement for a prefix, they seem all=20 > > > equally legitimate to me. Looks like giving multiple names to=20 > > > something. e.g. we'll call this LSP/segment "A" or "R" or "Y". > > > Now we may choose to only use one, based on a criteria TBD. e.g. > > > smallest SID (which a priori improve the probability of fitting=20 > > > inside the > > SRGBs). > > > > > > /Bruno > > > > > > > As a result, I > > > > would think that once an entry is selected based on the criteria=20 > > > > and programmed, we should not be changing it unless the MS entry=20 > > > > is > > withdrawn. > > > > > > > > Mustapha. > > > > > > > > > -----Original Message----- > > > > > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of=20 > > > > > stephane.litkowski@orange.com > > > > > Sent: Friday, June 19, 2015 5:17 AM > > > > > To: DECRAENE Bruno IMT/OLN; Stefano Previdi (sprevidi) > > > > > Cc: spring@ietf.org; isis-wg@ietf.org list > > > > > Subject: Re: [spring] Conflicting MS entries > > > > > > > > > > Even if choosing any IP to MPLS entry does not break anything,=20 > > > > > I'm not sure this is a good idea from an operational point of=20 > > > > > view to let it > > > > undeterministic. > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of=20 > > > > > bruno.decraene@orange.com > > > > > Sent: Thursday, June 18, 2015 09:29 > > > > > To: LITKOWSKI Stephane SCE/IBNF; Stefano Previdi (sprevidi) > > > > > Cc: spring@ietf.org; isis-wg@ietf.org list > > > > > Subject: Re: [spring] Conflicting MS entries > > > > > > > > > > Hi St=E9phane, > > > > > > > > > > > From: stephane.litkowski@orange.com> Sent: Thursday, June=20 > > > > > > 18, > > > > > > 2015 > > > > > > 9:23 AM > > > > > > > > > > > > Hi Bruno, > > > > > > > > > > > > " 1) I don't really the issue. From a forwarding standpoint, l= ooks > > like > > > > > > we can simply program multiple SIDs in the FIB." > > > > > > > > > > > > [SLI] What about the IP to MPLS entry ? > > > > > > > > > > [Bruno] If transit LSRs install all SIDs, an ingress may use=20 > > > > > any SID, no? Local decision. > > > > > > > > > > Bruno > > > > > > > > > > > > > > > > > > > > > > > > > > ____________________________________________________________ > > > > ________ > > > > > > > > > > > ____________________________________________________________ > > ________ > > > _____________________________________________________ > > > > > > Ce message et ses pieces jointes peuvent contenir des informations=20 > > > confidentielles ou privilegiees et ne doivent donc pas etre=20 > > > diffuses, exploites ou copies sans autorisation. Si vous avez recu=20 > > > ce message par erreur, veuillez le signaler a l'expediteur et le=20 > > > detruire ainsi que les pieces jointes. Les messages electroniques=20 > > > etant susceptibles d'alteration, Orange decline toute=20 > > > responsabilite si ce message a ete altere, > > deforme ou falsifie. Merci. > > > > > > This message and its attachments may contain confidential or=20 > > > privileged information that may be protected by law; they should=20 > > > not be distributed, used or copied without authorisation. > > > If you have received this email in error, please notify the sender=20 > > > and delete this message and its attachments. > > > As emails may be altered, Orange is not liable for messages that=20 > > > have been 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=20 > confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 > exploites ou copies sans autorisation. Si vous avez recu ce message=20 > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi=20 > que les pieces jointes. Les messages electroniques etant susceptibles=20 > d'alteration, Orange decline toute responsabilite si ce message a ete alt= ere, deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or=20 > privileged information that may be protected by law; they should not=20 > be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and=20 > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have=20 > been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ 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 Jul 1 05:30:03 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56DB1A6F04 for ; Wed, 1 Jul 2015 05:30:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.86 X-Spam-Level: X-Spam-Status: No, score=-3.86 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yszo0zy_YpQi for ; Wed, 1 Jul 2015 05:29:58 -0700 (PDT) Received: from tcmail13.telekom.de (tcmail13.telekom.de [80.149.113.165]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D041A1BFF for ; Wed, 1 Jul 2015 05:29:57 -0700 (PDT) Received: from s4de8nsazdfe010.bmbg.telekom.de ([10.175.246.202]) by tcmail11.telekom.de with ESMTP; 01 Jul 2015 14:29:54 +0200 X-IronPort-AV: E=Sophos;i="5.15,385,1432591200"; d="scan'208";a="699251462" Received: from he110889.emea1.cds.t-internal.com ([10.134.92.130]) by q4de8nsa015.bmbg.telekom.de with ESMTP/TLS/AES128-SHA; 01 Jul 2015 14:29:54 +0200 Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([10.134.93.12]) by HE110889.emea1.cds.t-internal.com ([fe80::841f:f92c:15ca:8526%16]) with mapi; Wed, 1 Jul 2015 14:29:54 +0200 From: To: , Date: Wed, 1 Jul 2015 14:29:53 +0200 Thread-Topic: New Version Notification for draft-geib-spring-oam-usecase-05.txt Thread-Index: AdCz9/QlRrpP4mkmRiK/nFtsr2zHbAAAVw2g Message-ID: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: spring@ietf.org, raik.leipnitz@hft-leipzig.de Subject: [spring] WG: New Version Notification for draft-geib-spring-oam-usecase-05.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2015 12:30:00 -0000 Q2hhaXJzLA0KDQplZGl0b3JpYWwgY2hhbmdlcyBvbmx5LiBUaGUgYXV0aG9ycyBzdGlsbCB3YWl0 IGZvciBhIGRlY2lzaW9uIG9mIHRoZSBjaGFpcnMgaG93IHRvIG1ha2UgcHJvZ3Jlc3Mgb24gdGhl IGRyYWZ0LiANCg0KUmVnYXJkcywNCg0KUnVlZGlnZXINCg0KDQotLS0tLVVyc3Byw7xuZ2xpY2hl IE5hY2hyaWNodC0tLS0tDQpWb246IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpHZXNlbmRldDogTWl0dHdvY2gsIDEuIEp1bGkgMjAx NSAxNDoxNw0KQW46IE5hZ2VuZHJhIEt1bWFyOyBHZWliLCBSw7xkaWdlcjsgTmFnZW5kcmEgS3Vt YXI7IEdlaWIsIFLDvGRpZ2VyOyBDYXJsb3MgUGlnbmF0YXJvOyBDbGFyZW5jZSBGaWxzZmlsczsg Q2FybG9zIFBpZ25hdGFybzsgQ2xhcmVuY2UgRmlsc2ZpbHMNCkJldHJlZmY6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtZ2VpYi1zcHJpbmctb2FtLXVzZWNhc2UtMDUudHh0DQoN Cg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWdlaWItc3ByaW5nLW9hbS11c2VjYXNlLTA1 LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBSdWVkaWdlciBHZWliIGFu ZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWdlaWItc3By aW5nLW9hbS11c2VjYXNlDQpSZXZpc2lvbjoJMDUNClRpdGxlOgkJVXNlIGNhc2UgZm9yIGEgc2Nh bGFibGUgYW5kIHRvcG9sb2d5IGF3YXJlIE1QTFMgZGF0YSBwbGFuZSBtb25pdG9yaW5nIHN5c3Rl bQ0KRG9jdW1lbnQgZGF0ZToJMjAxNS0wNy0wMQ0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Np b24NClBhZ2VzOgkJMTINClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRl cm5ldC1kcmFmdHMvZHJhZnQtZ2VpYi1zcHJpbmctb2FtLXVzZWNhc2UtMDUudHh0DQpTdGF0dXM6 ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZ2VpYi1zcHJp bmctb2FtLXVzZWNhc2UvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWdlaWItc3ByaW5nLW9hbS11c2VjYXNlLTA1DQpEaWZmOiAgICAgICAgICAgaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWdlaWItc3ByaW5nLW9hbS11c2Vj YXNlLTA1DQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgZmVhdHVyZXMg YW5kIGEgdXNlIGNhc2Ugb2YgYSBwYXRoIG1vbml0b3JpbmcNCiAgIHN5c3RlbS4gIFNlZ21lbnQg YmFzZWQgcm91dGluZyBlbmFibGVzIGEgc2NhbGFibGUgYW5kIHNpbXBsZSBtZXRob2QNCiAgIHRv IG1vbml0b3IgZGF0YSBwbGFuZSBsaXZlbGluZXNzIG9mIHRoZSBjb21wbGV0ZSBzZXQgb2YgcGF0 aHMNCiAgIGJlbG9uZ2luZyB0byBhIHNpbmdsZSBkb21haW4uICBDb21wYXJlZCB3aXRoIGxlZ2Fj eSBNUExTIHBpbmcgYW5kDQogICBwYXRoIHRyYWNlLCBNUExTIHRvcG9sb2d5IGF3YXJlbmVzcyBy ZWR1Y2VzIG1hbmFnZW1lbnQgYW5kIGNvbnRyb2wNCiAgIHBsYW5lIGludm9sdmVtZW50IG9mIE9B TSBtZWFzdXJlbWVudHMgd2hpbGUgZW5hYmxpbmcgbmV3IE9BTQ0KICAgZmVhdHVyZXMuDQoNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtl IGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGlsIHRo ZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5v cmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Wed Jul 1 07:45:43 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A21E71A88A9 for ; Wed, 1 Jul 2015 07:45:41 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bg_8sHqKl1e7 for ; Wed, 1 Jul 2015 07:45:35 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0132.outbound.protection.outlook.com [207.46.100.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884391A8AC2 for ; Wed, 1 Jul 2015 07:45:35 -0700 (PDT) Received: from BLUPR05MB1969.namprd05.prod.outlook.com (10.162.224.23) by BLUPR05MB1970.namprd05.prod.outlook.com (10.162.224.24) with Microsoft SMTP Server (TLS) id 15.1.195.15; Wed, 1 Jul 2015 14:45:32 +0000 Received: from BLUPR05MB1969.namprd05.prod.outlook.com ([10.162.224.23]) by BLUPR05MB1969.namprd05.prod.outlook.com ([10.162.224.23]) with mapi id 15.01.0201.000; Wed, 1 Jul 2015 14:45:32 +0000 From: Pushpasis Sarkar To: "bruno.decraene@orange.com" , "spring@ietf.org" Thread-Topic: [spring] Poll for adoption: draft-litkowski-spring-sr-yang-01 Thread-Index: AQHQtAyU8Equ2PlA6EKFu4FviMBpoQ== Date: Wed, 1 Jul 2015 14:45:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 authentication-results: orange.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.184.11] x-microsoft-exchange-diagnostics: 1; BLUPR05MB1970; 5:s5x3UZrfB9Mi4Y2MJxve5ts7Rva9pLwf6Fdlj27mpQ82bqyEFMYAD+FCM9jn5eqd6/InDUG2xLs2OLW0PiSaa+r8aNT+pPt5X5SOj8lReo9hBHZqjLUEB9JkMBIUJJPS09i9GTt+I86GixbGXVSMmA==; 24:IZ50jlL38LdD/vWE1ui7xnwN0lYxKXbUs3hTZgw0cpBG/EbX5kyo5ynZqIokjLigL6UJo7vpluW5JaSf29+jF2kz/qLPD7cE/tch9NzcSW4=; 20:nDWSa8qGQhvnTyngzMk2ttU1Hc8E6oRoTU2m8htC7H69lVLDqrD/eba1hs5HAcBvmawV0sgqw3kE0pHQRwvJLg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB1970; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB1970; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1970; x-forefront-prvs: 0624A2429E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(51704005)(24454002)(479174004)(230783001)(4001350100001)(5001770100001)(66066001)(83506001)(2656002)(87936001)(92566002)(86362001)(46102003)(54356999)(50986999)(189998001)(36756003)(5002640100001)(99286002)(106116001)(5001960100002)(77096005)(2900100001)(40100003)(107886002)(102836002)(15975445007)(122556002)(2501003)(77156002)(62966003)(5890100001)(19580395003)(19580405001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1970; H:BLUPR05MB1969.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <82B06B34A5CAE445B9225348476184CD@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2015 14:45:32.5320 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1970 Archived-At: Subject: Re: [spring] Poll for adoption: draft-litkowski-spring-sr-yang-01 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2015 14:45:41 -0000 Support as co-author. Thanks -Pushpasis On 6/29/15, 10:51 PM, "spring on behalf of bruno.decraene@orange.com" wrote: >Hello working group, > >This email starts a two-week poll on adopting >draft-litkowski-spring-sr-yang-01 as a working group item. >"YANG Data Model for Segment Routing " >https://tools.ietf.org/html/draft-litkowski-spring-sr-yang-01 > >Please send comments to the list and state if you support adoption or >not. In the latter case, please also state the reasons. > >This poll runs until July 13 2015. > > >*Coincidentally*, we are also polling for knowledge of any IPR that >applies to this draft, to ensure that IPR has been disclosed in >compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for >more details). >*If you are listed as a document author or contributor* please respond to >this email and indicate whether or not you are aware of any relevant IPR. >The draft will not be adopted until a response has been received from >each author and contributor. >If you are not listed as an author or contributor, then please explicitly >respond only if you are aware of any IPR that has not yet been disclosed >in conformance with IETF rules. > >Thank you >Bruno & John > >__________________________________________________________________________ >_______________________________________________ > >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 From nobody Wed Jul 1 07:54:02 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 787E91A8BB1 for ; Wed, 1 Jul 2015 07:54: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JbDHd5OBHS8 for ; Wed, 1 Jul 2015 07:53:55 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0110.outbound.protection.outlook.com [207.46.100.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BB631A8AFA for ; Wed, 1 Jul 2015 07:53:44 -0700 (PDT) Received: from BLUPR05MB1969.namprd05.prod.outlook.com (10.162.224.23) by BLUPR05MB1972.namprd05.prod.outlook.com (10.162.224.26) with Microsoft SMTP Server (TLS) id 15.1.207.19; Wed, 1 Jul 2015 14:53:43 +0000 Received: from BLUPR05MB1969.namprd05.prod.outlook.com ([10.162.224.23]) by BLUPR05MB1969.namprd05.prod.outlook.com ([10.162.224.23]) with mapi id 15.01.0201.000; Wed, 1 Jul 2015 14:53:43 +0000 From: Pushpasis Sarkar To: Pushpasis Sarkar , "bruno.decraene@orange.com" , "spring@ietf.org" Thread-Topic: [spring] Poll for adoption: draft-litkowski-spring-sr-yang-01 Thread-Index: AQHQtA25N5eCXP3P10OnZIjot8N0TQ== Date: Wed, 1 Jul 2015 14:53:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 authentication-results: juniper.net; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.184.11] x-microsoft-exchange-diagnostics: 1; BLUPR05MB1972; 5:XBgCcD8Jx/Tez7fxlHxxTMdZcu2KO9uTi24XBLonrlcXK6uq64yuNz1GHMxEEpg1c8vy+mZDBiGxwJnQ+HpVAIc6gCMnd7t2uqj5oAG32T94woVL9sspNqwU8ktivkyVXq4ffmMCMdTXazhvOFBX+Q==; 24:52iaF221CWi21O/uyaSRye1+gzD+kxeeDJeZJf3S3vxr5Pk6Km+Hn2A3wStbHMA+8grb6gu9cED69A9oQKBOPL5u8wHFvrfhQ5GyyMyuS60=; 20:NRnDNWV47SmfAPVrQqWz2yrG2Wu/yELBd+8xccWa2HsXhPTWisG9WN/IXdVAde4Wof9bfy882J2duoSZpH28Yg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB1972; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB1972; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1972; x-forefront-prvs: 0624A2429E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(479174004)(51704005)(377454003)(102836002)(15975445007)(230783001)(2900100001)(87936001)(77156002)(62966003)(36756003)(2501003)(189998001)(2656002)(5890100001)(2950100001)(50986999)(107886002)(76176999)(5001960100002)(4001350100001)(5001770100001)(92566002)(54356999)(77096005)(5002640100001)(40100003)(19580395003)(46102003)(66066001)(122556002)(19580405001)(2201001)(106116001)(99286002)(83506001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1972; H:BLUPR05MB1969.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jul 2015 14:53:43.3761 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1972 Archived-At: Subject: Re: [spring] Poll for adoption: draft-litkowski-spring-sr-yang-01 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 01 Jul 2015 14:54:01 -0000 Sorry. Forgot to mention earlier. I am not aware of any IPR related to this draft.=20 Thanks -Pushpasis On 7/1/15, 8:15 PM, "spring on behalf of Pushpasis Sarkar" wrote: >Support as co-author. > >Thanks >-Pushpasis > >On 6/29/15, 10:51 PM, "spring on behalf of bruno.decraene@orange.com" > wrote: > >>Hello working group, >> >>This email starts a two-week poll on adopting >>draft-litkowski-spring-sr-yang-01 as a working group item. >>"YANG Data Model for Segment Routing " >>https://tools.ietf.org/html/draft-litkowski-spring-sr-yang-01 >> >>Please send comments to the list and state if you support adoption or >>not. In the latter case, please also state the reasons. >> >>This poll runs until July 13 2015. >> >> >>*Coincidentally*, we are also polling for knowledge of any IPR that >>applies to this draft, to ensure that IPR has been disclosed in >>compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for >>more details). >>*If you are listed as a document author or contributor* please respond to >>this email and indicate whether or not you are aware of any relevant IPR. >>The draft will not be adopted until a response has been received from >>each author and contributor. >>If you are not listed as an author or contributor, then please explicitly >>respond only if you are aware of any IPR that has not yet been disclosed >>in conformance with IETF rules. >> >>Thank you >>Bruno & John >> >>_________________________________________________________________________ >>_ >>_______________________________________________ >> >>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 From nobody Wed Jul 1 19:16:10 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB251A0423; Wed, 1 Jul 2015 19:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.21 X-Spam-Level: X-Spam-Status: No, score=-104.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UpcXC-w3L7U; Wed, 1 Jul 2015 19:16:02 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3681A014D; Wed, 1 Jul 2015 19:14:34 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 8E3A5989AC244; Thu, 2 Jul 2015 10:14:30 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 2161A4B26CF83; Thu, 2 Jul 2015 10:14:30 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id t622E1I3031163; Thu, 2 Jul 2015 10:14:01 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn) To: hannes@juniper.net MIME-Version: 1.0 Sensitivity: X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: peng.shaofu@zte.com.cn Date: Thu, 2 Jul 2015 10:13:57 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2015-07-02 10:14:01, Serialize complete at 2015-07-02 10:14:01 Content-Type: multipart/alternative; boundary="=_alternative 000C453348257E76_=" X-MAIL: mse01.zte.com.cn t622E1I3031163 Archived-At: Cc: idr@ietf.org, spring@ietf.org, isis-wg@ietf.org Subject: [spring] questions about draft-ietf-idr-ls-distribution-11 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 02 Jul 2015 02:16:05 -0000 This is a multipart message in MIME format. --=_alternative 000C453348257E76_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aGkgaGFubmVzICYgb3RoZXIgYXV0aG9ycw0KDQpBcyBkZXNjcmliZWQgaW4gW0xpbmstU3RhdGUg SW5mbyBEaXN0cmlidXRpb24gdXNpbmcgQkdQXSAoc2VlIFNlY3Rpb24gDQozLjIuMiwgobBMaW5r IERlc2NyaXB0b3JzobEpLCB0aGUgSVAgYWRkcmVzcyBUTFZzIChUTFYgY29kZSAyNTktMjYyKSBv ciANCnRoZSBsaW5rIGxvY2FsL3JlbW90ZSBJZGVudGlmaWVyIFRMViAoVExWIGNvZGUgMjU4KSBh cmUgaW5jbHVkZWQgaW4gdGhlIA0KbGluayBkZXNjcmlwdG9yLiANCqGwVGhlIGluZm9ybWF0aW9u IGFib3V0IGEgbGluayBwcmVzZW50IGluIHRoZSBMU0EvTFNQIG9yaWdpbmF0ZWQgYnkgdGhlIA0K bG9jYWwgbm9kZSBvZiB0aGUgbGluayBkZXRlcm1pbmVzIHRoZSBzZXQgb2YgVExWcyBpbiB0aGUg TGluayBEZXNjcmlwdG9yIA0Kb2YgdGhlIGxpbmsuDQogICAgICBJZiBpbnRlcmZhY2UgYW5kIG5l aWdoYm9yIGFkZHJlc3NlcywgZWl0aGVyIElQdjQgb3IgSVB2NiwgYXJlIA0KcHJlc2VudCwgdGhl biB0aGUgSVAgYWRkcmVzcyBUTFZzIGFyZSBpbmNsdWRlZCBpbiB0aGUgbGluayBkZXNjcmlwdG9y LCBidXQgDQpub3QgdGhlIGxpbmsgbG9jYWwvcmVtb3RlIElkZW50aWZpZXIgVExWLiAgVGhlICAg ICAgbGluayBsb2NhbC9yZW1vdGUgDQppZGVudGlmaWVycyBNQVkgYmUgaW5jbHVkZWQgaW4gdGhl IGxpbmsgYXR0cmlidXRlLg0KICAgICAgSWYgaW50ZXJmYWNlIGFuZCBuZWlnaGJvciBhZGRyZXNz ZXMgYXJlIG5vdCBwcmVzZW50IGFuZCB0aGUgbGluayANCmxvY2FsL3JlbW90ZSBpZGVudGlmaWVy cyBhcmUgcHJlc2VudCwgdGhlbiB0aGUgbGluayBsb2NhbC9yZW1vdGUgDQpJZGVudGlmaWVyIFRM ViBpcyBpbmNsdWRlZCBpbiB0aGUgbGluayBkZXNjcmlwdG9yLqGxDQoNCldoZW4gdGhlIHVuZGVy bHlpbmcgSUdQIGlzIElTLUlTLCBMU1Agb3JpZ2luYXRlZCBieSB0aGUgbG9jYWwgbm9kZSBvZiB0 aGUgDQpsaW5rIE1BWSBOT1QgaW5jbHVkZSBJUHY0IGludGVyZmFjZSBhZGRyZXNzL0lQdjQgbmVp Z2hib3IgYWRkcmVzcyBvciBMaW5rIA0KTG9jYWwvUmVtb3RlIElkZW50aWZpZXJzIHN1Yi1UTFYg aW4gdGhlIChtYWluKSBJUyByZWFjaGFiaWxpdHkgVExWIHdoZW4gDQpNUExTIFRyYWZmaWMgRW5n aW5lZXJpbmcgaXMgbm90IGNvbmZpZ3VyZWQgZm9yIElTLUlTIChzZWUgU2VjdGlvbiAzLjIsIKGw DQpTdWItVExWIDY6IElQdjQgSW50ZXJmYWNlIEFkZHJlc3OhsSwgb2YgW1JGQzUzMDVdIGFuZCBT ZWN0aW9uIDEuMSwgobBMaW5rIA0KTG9jYWwvUmVtb3RlIElkZW50aWZpZXJzobEsIG9mIFtSRkM1 MzA3XSwgcmVzcGVjdGl2ZWx5KS4gDQoNClRodXMsIEJHUC1MUyBzcGVha2VyIE1BWSBsZWFybiB0 aGUgbWVudGlvbmVkIGxpbmsgaW5mb3JtYXRpb24sIGZyb20gTFNQIA0KZmxvb2RpbmcgcHJvY2Vz cywgd2l0aG91dCBkZXRhaWxlZCBpbnRlcmZhY2UgSVAvSUQgaW5mb3JtYXRpb24gb2YgYWxsIElH UCANCm5vZGVzIGluIHRoZSBCR1AtTFMgZG9tYWluLiAgSWYgQ09OU1VNRVIgY29sbGVjdCBsaW5r LXN0YXRlIGluZm9ybWF0aW9uIG9mIA0Kd2hvbGUgZG9tYWluIG9ubHkgZnJvbSBvbmUgQkdQLUxT IHNwZWFrZXIsIGl0IGNhbiBvbmx5IGVzdGFibGlzaCBvbmUgU1BUICwgDQp3aGljaCByb290IGlz IHRoZSBCR1AtTFMgc3BlYWtlci4gSW4gc29tZSBjYXNlLCBDT05TVU1FUiBuZWVkIGNyZWF0ZSAN CmRpZmZlcmVudCBTUFQgZm9yIGRpZmZlcmVudCBkZXZpY2UuIEZvciBleGFtcGxlLCBpbiBjZW50 cmFsIHNwcmluZyANCm5ldHdvcmssIHRoZSBDT05UUk9MTEVSIG5lZWQgZG93bmxvYWQgSUxNIGVu dHJ5IGZvciBhIGdsb2JhbCBsYWJlbCB0byBlYWNoIA0Kcm91dGVyLCB0aGUgSUxNIGZvcndhcmRp bmcgaW5mb3JtYXRpb24gaXMgZGVjaWRlZCBieSBlYWNoIHJvdXRlcidzIFNQVC4gSXQgDQppcyBk aWZmZXJlbnQgZm9yIGRpZmZlcmVudCByb3V0ZXIuDQogDQpzb21lIHNvbHV0aW9ucyBjb3VsZCBi ZToNCjEpIGFsbCBJR1Agbm9kZXMgaW4gdGhlIEJHUC1MUyBkb21haW4gYXJlIEJHUC1MUyBzcGVh a2Vycywgd2hlcmUgb25seSANCmxvY2FsIGxpbmsgaW5mb3JtYXRpb24gbmVlZCB0byBiZSBjb2xs ZWN0ZWQgYW5kIHNlbnQgdG8gQ09OU1VNRVIuIA0KMikgb25lIEJHUC1MUyBzcGVha2VyLCBidXQg YWxsIGxpbmsgYXJlIGNvbmZpZ3VyZWQgTVBMUyBUcmFmZmljIA0KRW5naW5lZXJpbmcobm90IGNl cnRhaW5seSBpbmNsdWRpbmcgc2lnbmFsIGNvbmZpZ3VyYXRpb24pLg0KDQpEbyB5b3UgaGF2ZSBh bnkgc3VnZ2VzdGlvbnMgYWJvdXQgdGhpcyBpc3N1ZT8gDQoNCnRoYW5rcw0KZGVjY2FuDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpa VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgbWFpbCAoYW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBp cyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhj bHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5k ZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24g b3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWls IGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K WlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5l ZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkg aXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4 Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVu ZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9u IG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWlu ZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFp bCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0K --=_alternative 000C453348257E76_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8ZGl2Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPmhpIGhhbm5l cyAmYW1wOyBvdGhlciBhdXRob3JzPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPkFzIGRlc2NyaWJlZCBpbiBbTGluay1TdGF0ZSBJbmZvDQpEaXN0 cmlidXRpb24gdXNpbmcgQkdQXSAoc2VlIFNlY3Rpb24gMy4yLjIsIKGwTGluayBEZXNjcmlwdG9y c6GxKSwgdGhlDQpJUCBhZGRyZXNzIFRMVnMgKFRMViBjb2RlIDI1OS0yNjIpIG9yIHRoZSBsaW5r IGxvY2FsL3JlbW90ZSBJZGVudGlmaWVyDQpUTFYgKFRMViBjb2RlIDI1OCkgYXJlIGluY2x1ZGVk IGluIHRoZSBsaW5rIGRlc2NyaXB0b3IuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48aT6hsFRoZSBpbmZvcm1hdGlvbiBhYm91dCBhIGxpbmsNCnByZXNl bnQgaW4gdGhlIExTQS9MU1Agb3JpZ2luYXRlZCBieSB0aGUgbG9jYWwgbm9kZSBvZiB0aGUgbGlu ayBkZXRlcm1pbmVzDQp0aGUgc2V0IG9mIFRMVnMgaW4gdGhlIExpbmsgRGVzY3JpcHRvciBvZiB0 aGUgbGluay48L2k+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjxpPiZuYnNwOyAmbmJzcDsgJm5ic3A7IElmIGludGVyZmFjZQ0KYW5kIG5laWdoYm9yIGFk ZHJlc3NlcywgZWl0aGVyIElQdjQgb3IgSVB2NiwgYXJlIHByZXNlbnQsIHRoZW4gdGhlIElQIGFk ZHJlc3MNClRMVnMgYXJlIGluY2x1ZGVkIGluIHRoZSBsaW5rIGRlc2NyaXB0b3IsIGJ1dCBub3Qg dGhlIGxpbmsgbG9jYWwvcmVtb3RlDQpJZGVudGlmaWVyIFRMVi4gJm5ic3A7VGhlICZuYnNwOyAm bmJzcDsgJm5ic3A7bGluayBsb2NhbC9yZW1vdGUgaWRlbnRpZmllcnMNCk1BWSBiZSBpbmNsdWRl ZCBpbiB0aGUgbGluayBhdHRyaWJ1dGUuPC9pPjwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48aT4mbmJzcDsgJm5ic3A7ICZuYnNwOyBJZiBpbnRlcmZhY2UN CmFuZCBuZWlnaGJvciBhZGRyZXNzZXMgYXJlIG5vdCBwcmVzZW50IGFuZCB0aGUgbGluayBsb2Nh bC9yZW1vdGUgaWRlbnRpZmllcnMNCmFyZSBwcmVzZW50LCB0aGVuIHRoZSBsaW5rIGxvY2FsL3Jl bW90ZSBJZGVudGlmaWVyIFRMViBpcyBpbmNsdWRlZCBpbiB0aGUNCmxpbmsgZGVzY3JpcHRvci6h sTwvaT48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+V2hlbiB0aGUgdW5kZXJseWluZyBJR1AgaXMgSVMtSVMsDQpMU1Agb3JpZ2luYXRlZCBieSB0 aGUgbG9jYWwgbm9kZSBvZiB0aGUgbGluayBNQVkgTk9UIGluY2x1ZGUgSVB2NCBpbnRlcmZhY2UN CmFkZHJlc3MvSVB2NCBuZWlnaGJvciBhZGRyZXNzIG9yIExpbmsgTG9jYWwvUmVtb3RlIElkZW50 aWZpZXJzIHN1Yi1UTFYNCmluIHRoZSAobWFpbikgSVMgcmVhY2hhYmlsaXR5IFRMViB3aGVuIE1Q TFMgVHJhZmZpYyBFbmdpbmVlcmluZyBpcyBub3QNCmNvbmZpZ3VyZWQgZm9yIElTLUlTIChzZWUg U2VjdGlvbiAzLjIsIKGwU3ViLVRMViA2OiBJUHY0IEludGVyZmFjZSBBZGRyZXNzobEsDQpvZiBb UkZDNTMwNV0gYW5kIFNlY3Rpb24gMS4xLCChsExpbmsgTG9jYWwvUmVtb3RlIElkZW50aWZpZXJz obEsIG9mIFtSRkM1MzA3XSwNCnJlc3BlY3RpdmVseSkuIDwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5UaHVzLCBCR1AtTFMgc3BlYWtlciBNQVkg bGVhcm4NCnRoZSBtZW50aW9uZWQgbGluayBpbmZvcm1hdGlvbiwgZnJvbSBMU1AgZmxvb2Rpbmcg cHJvY2Vzcywgd2l0aG91dCBkZXRhaWxlZA0KaW50ZXJmYWNlIElQL0lEIGluZm9ybWF0aW9uIG9m IGFsbCBJR1Agbm9kZXMgaW4gdGhlIEJHUC1MUyBkb21haW4uICZuYnNwO0lmDQpDT05TVU1FUiBj b2xsZWN0IGxpbmstc3RhdGUgaW5mb3JtYXRpb24gb2Ygd2hvbGUgZG9tYWluIG9ubHkgZnJvbSBv bmUgQkdQLUxTDQpzcGVha2VyLCBpdCBjYW4gb25seSBlc3RhYmxpc2ggb25lIFNQVCAsIHdoaWNo IHJvb3QgaXMgdGhlIEJHUC1MUyBzcGVha2VyLg0KSW4gc29tZSBjYXNlLCBDT05TVU1FUiBuZWVk IGNyZWF0ZSBkaWZmZXJlbnQgU1BUIGZvciBkaWZmZXJlbnQgZGV2aWNlLg0KRm9yIGV4YW1wbGUs IGluIGNlbnRyYWwgc3ByaW5nIG5ldHdvcmssIHRoZSBDT05UUk9MTEVSIG5lZWQgZG93bmxvYWQg SUxNDQplbnRyeSBmb3IgYSBnbG9iYWwgbGFiZWwgdG8gZWFjaCByb3V0ZXIsIHRoZSBJTE0gZm9y d2FyZGluZyBpbmZvcm1hdGlvbg0KaXMgZGVjaWRlZCBieSBlYWNoIHJvdXRlcidzIFNQVC4gSXQg aXMgZGlmZmVyZW50IGZvciBkaWZmZXJlbnQgcm91dGVyLjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+c29tZSBzb2x1dGlvbnMgY291bGQgYmU6PC9mb250Pg0K PGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjEpIGFsbCBJR1Agbm9kZXMg aW4gdGhlIEJHUC1MUw0KZG9tYWluIGFyZSBCR1AtTFMgc3BlYWtlcnMsIHdoZXJlIG9ubHkgbG9j YWwgbGluayBpbmZvcm1hdGlvbiBuZWVkIHRvIGJlDQpjb2xsZWN0ZWQgYW5kIHNlbnQgdG8gQ09O U1VNRVIuIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4y KSBvbmUgQkdQLUxTIHNwZWFrZXIsIGJ1dCBhbGwNCmxpbmsgYXJlIGNvbmZpZ3VyZWQgTVBMUyBU cmFmZmljIEVuZ2luZWVyaW5nKG5vdCBjZXJ0YWlubHkgaW5jbHVkaW5nIHNpZ25hbA0KY29uZmln dXJhdGlvbikuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPkRvIHlvdSBoYXZlIGFueSBzdWdnZXN0aW9ucyBhYm91dA0KdGhpcyBpc3N1ZT8gPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj50aGFua3M8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmRlY2NhbjwvZm9udD4NCjxi cj48L2Rpdj4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9ImJsdWUiPg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlv biBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWls IChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQg YW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9m IHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQs IGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNz ZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5 IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBs ZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg0KPC9mb250PjwvcHJl Pjxicj4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9ImJsdWUiPg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBT ZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChh bmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5k IGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRo ZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFu eSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1p bmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHBy b2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFz ZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg0KPC9mb250PjwvcHJlPjxi cj4NCg== --=_alternative 000C453348257E76_=-- From nobody Mon Jul 6 10:23:54 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44BD91ACD88 for ; Mon, 6 Jul 2015 10:23:52 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lclWahAnJr76 for ; Mon, 6 Jul 2015 10:23:50 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0785.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::785]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79D6F1ACD82 for ; Mon, 6 Jul 2015 10:23:50 -0700 (PDT) Received: from BLUPR05MB1969.namprd05.prod.outlook.com (10.162.224.23) by BLUPR05MB1971.namprd05.prod.outlook.com (10.162.224.25) with Microsoft SMTP Server (TLS) id 15.1.207.19; Mon, 6 Jul 2015 17:23:43 +0000 Received: from BLUPR05MB1969.namprd05.prod.outlook.com ([10.162.224.23]) by BLUPR05MB1969.namprd05.prod.outlook.com ([10.162.224.23]) with mapi id 15.01.0207.004; Mon, 6 Jul 2015 17:23:43 +0000 From: Pushpasis Sarkar To: "spring@ietf.org" Thread-Topic: New Version Notification for draft-psarkar-spring-mpls-anycast-segments-00.txt Thread-Index: AQHQuBCBwSc4A8fnAE2idwm/2JAHoQ== Date: Mon, 6 Jul 2015 17:23:43 +0000 Message-ID: References: <20150706171756.32302.17375.idtracker@ietfa.amsl.com> In-Reply-To: <20150706171756.32302.17375.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.184.11] x-microsoft-exchange-diagnostics: 1; BLUPR05MB1971; 5:pGktc4LLzpsHmUFBf0bLqE9vCTil7bEmQf8Pm0DGQAH/aBpEWVRYHuj7YCZMbvE1U8oIMwI+7RAlfdrTaNJhJZpTKkFz6uXWMLjflzW0gIFJ4PTxCb0Emt/f/wyiAJYxX2V5Qvl6PjGzs8cV8y1/Og==; 24:ZrJD9YmJzq/txNDt5uiRo/NHam8KA2ZzTBVWV6XNxrL9kXcmGKPZB5UsVZZ8u8co4L1YU0+mJjErGnAGCtUc/MSAQ6nO7WElN6/VBH0tpgY=; 20:n9FPE3MOILGvQkUstVpGLQCd5okoxPGahITjAoCyA8DFW0rivxzRp5H843U5WweY3Y20dxFIesY5VX8nXVyvcQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB1971; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB1971; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1971; x-forefront-prvs: 06290ECA9D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(53754006)(377424004)(479174004)(51704005)(24454002)(83506001)(92566002)(66066001)(230783001)(561944003)(2351001)(46102003)(19580395003)(40100003)(19580405001)(77156002)(62966003)(450100001)(2656002)(122556002)(87936001)(99286002)(106116001)(2950100001)(2900100001)(110136002)(5001960100002)(189998001)(107886002)(5002640100001)(77096005)(15975445007)(102836002)(54356999)(2501003)(86362001)(76176999)(36756003)(50986999)(4001350100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1971; H:BLUPR05MB1969.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2015 17:23:43.3801 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1971 Archived-At: Subject: [spring] FW: New Version Notification for draft-psarkar-spring-mpls-anycast-segments-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 06 Jul 2015 17:23:52 -0000 Hi All, Following is a draft on implementing Anycast segments with SPRING mapped to MPLS dataplane without all routers needing to use the same SRGB label ranges. Request you all to review the draft and provide your valuable feedback. Thanks -Pushpasis On 7/6/15, 10:47 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-psarkar-spring-mpls-anycast-segments-00.txt >has been successfully submitted by Pushpasis Sarkar and posted to the >IETF repository. > >Name: draft-psarkar-spring-mpls-anycast-segments >Revision: 00 >Title: Anycast Segments in MPLS based SPRING >Document date: 2015-07-06 >Group: Individual Submission >Pages: 15 >URL: =20 >https://www.ietf.org/internet-drafts/draft-psarkar-spring-mpls-anycast-seg >ments-00.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-psarkar-spring-mpls-anycast-segment >s/ >Htmlized: =20 >https://tools.ietf.org/html/draft-psarkar-spring-mpls-anycast-segments-00 > > >Abstract: > Instead of forwarding to a specific device or to all devices in a > group, anycast addresses, let network devices forward a packet to (or > steer it through) one or more topologically nearest devices in a > specific group of network devices. [I-D.ietf-spring-segment-routing] > extended the use of anycast addresses to a SPRING network, wherein a > group of SPRING-capable devices can represent a anycast address, by > having the same SRGB label block provisioned on all the devices and > each one of them advertising the same anycast prefix segment (or > Anycast SID). > > This document describes a proposal for implementing anycast prefix > segments in SPRING, without the need to have the same SRGB block > (label ranges) provisioned across all the member devices in the > group. Each node can be provisioned with a separate SRGB from the > label range supported by the specfic hardware platform. > > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From nobody Tue Jul 7 19:29:58 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72C021B2D49 for ; Tue, 7 Jul 2015 19:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.759 X-Spam-Level: X-Spam-Status: No, score=-101.759 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qu_LJzsS2zpo for ; Tue, 7 Jul 2015 19:29:54 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id E00AD1B2D48 for ; Tue, 7 Jul 2015 19:29:53 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 81DA61D9CB4EE for ; Wed, 8 Jul 2015 10:26:05 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id B674B9676F690 for ; Wed, 8 Jul 2015 10:29:48 +0800 (CST) Received: (from root@localhost) by mse01.zte.com.cn id t682Tm9H007099 for ; Wed, 8 Jul 2015 10:29:48 +0800 (GMT-8) (envelope-from liao.ting@zte.com.cn) Message-Id: <201507080229.t682Tm9H007099@mse01.zte.com.cn> Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id t682Fxtx062832 for ; Wed, 8 Jul 2015 10:15:59 +0800 (GMT-8) (envelope-from liao.ting@zte.com.cn) To: "spring@ietf.org" MIME-Version: 1.0 X-KeepSent: A690A994:2DC6F815-48257E7C:000B6A09; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 From: liao.ting@zte.com.cn Date: Wed, 8 Jul 2015 10:15:53 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2015-07-08 10:15:39, Serialize complete at 2015-07-08 10:15:39 Content-Type: multipart/alternative; boundary="=_alternative 000C730048257E7C_=" X-MAIL: mse01.zte.com.cn t682Tm9H007099 X-MSS: AUDITRELEASE@mse01.zte.com.cn Archived-At: Subject: [spring] FW: New Version Notification for draft-lw-spring-sid-allocation-02.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 08 Jul 2015 02:29:56 -0000 This is a multipart message in MIME format. --=_alternative 000C730048257E7C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpOZXcgdmVyc2lvbiBvZiBTSUQgQWxsb2NhdGlvbiBoYXMgYmVlbiB1cGRhdGVk IGFuZCBwdWJsaXNoZWQsIHRoaXMgZHJhZnQgDQpkZXNjcmliZXMgaG93IHRvIGFjY29tcGxpc2gg emVyby10b3VjaGVkIFNSLg0KDQpBbmQgaW4gdGhpcyBkcmFmdCBpdCBkZXNjcmliZXMgdGhlIHRp ZS1icmVha2VyIGJldHdlZW4gdHdvIG9yIG1vcmUgU1JNTnMgDQpieSBTUiBDYXBhYmlsaXRpZXMg U3ViLVRMViBleHRlbnNpb24gDQp3aXRoIHRoZSBBbGxvY2F0aW9uIGJpdCBzZXQsIHRoZSB0aWUt YnJlYWtlciBpcyBkZWNpZGVkIG9uIHRoZSByZWNlaXZlcnMgDQpieSBqdWRnaW5nIHRoZSBTUk1O cycgcm91dGVyIGlkIG9yIHN5c3RlbSBpZCwgdGhlIGRldGFpbCBpbmZvcm1hdGlvbiBpcyANCmRl c2NyaWJlZCBpbiBzZWN0aW9uIDQuMi4NCg0KQ29tbWVudHMgYXJlIHdlbGNvbWUgYW5kIGRpc2N1 c3Npb25zIGluIFByYWd1ZSBhcmUgZXhwZWN0ZWQuIFRoYW5rIHlvdS4NCg0KQmVzdCBSZWdhcmRz Lg0KVGluZw0KDQotLS0tLSDXqreiyMsgwc7mwzAzODc2OC91c2VyL3p0ZV9sdGQgyrG85CAyMDE1 LTA3LTA4IDEwOjA0IC0tLS0tDQoNCmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyDQtNPaIDIwMTUt MDctMDYgMTY6MjA6MDI6DQoNCj4gDQo+IEEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1sdy1z cHJpbmctc2lkLWFsbG9jYXRpb24tMDIudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJt aXR0ZWQgYnkgVGluZyBMaWFvIGFuZCBwb3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4N Cj4gDQo+IE5hbWU6ICAgICAgZHJhZnQtbHctc3ByaW5nLXNpZC1hbGxvY2F0aW9uDQo+IFJldmlz aW9uOiAgIDAyDQo+IFRpdGxlOiAgICAgIFNQUklORyBTSUQgQWxsb2NhdGlvbg0KPiBEb2N1bWVu dCBkYXRlOiAgIDIwMTUtMDctMDYNCj4gR3JvdXA6ICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9u DQo+IFBhZ2VzOiAgICAgIDEyDQo+IFVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbHctDQo+IHNwcmluZy1zaWQtYWxsb2NhdGlvbi0wMi50 eHQNCj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWx3LXNwcmluZy0NCj4gc2lkLWFsbG9jYXRpb24vDQo+IEh0bWxpemVkOiBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbHctc3ByaW5nLXNpZC1hbGxvY2F0aW9uLTAyDQo+IERp ZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbHct c3ByaW5nLQ0KPiBzaWQtYWxsb2NhdGlvbi0wMg0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFNlZ21l bnQgUm91dGluZyAoU1IpIGFsbG93cyBmb3IgYSBmbGV4aWJsZSBkZWZpbml0aW9uIG9mIGVuZC10 by1lbmQNCj4gICAgcGF0aHMgd2l0aGluIElHUCB0b3BvbG9naWVzIGJ5IGVuY29kaW5nIHBhdGhz IGFzIHNlcXVlbmNlcyBvZg0KPiAgICB0b3BvbG9naWNhbCBzdWItcGF0aHMsIGNhbGxlZCAic2Vn bWVudHMiLiAgVGhlc2Ugc2VnbWVudHMgYXJlDQo+ICAgIGFkdmVydGlzZWQgYnkgdGhlIGxpbmst c3RhdGUgcm91dGluZyBwcm90b2NvbHMgKElTLUlTIGFuZCBPU1BGKS4gIEFuZA0KPiAgICBhIHNl Z21lbnQgaXMgaWRlbnRpZmllZCBieSBhIFNlZ21lbnQgUm91dGluZyBJRCAoU0lEKS4gIFRoaXMg ZG9jdW1lbnQNCj4gICAgcHJvcG9zZXMgYSBtZXRob2QgdG8gcmVkdWNlIHRoZSBTSUQgY29uZmln dXJhdGlvbiBpbiBhIFNSIGRvbWFpbi4NCj4gICAgT25seSB0aGUgc2VsZWN0ZWQgU1Igbm9kZXMg d2hpY2ggbmFtZWQgU2VnbWVudCBSb3V0aW5nIE1hbmFnZW1lbnQNCj4gICAgTm9kZXMgKFNSTU5z KSBhcmUgY29uZmlndXJlZCBieSBOTVMsIHdoaWxlIG90aGVyIFNScyBpbiB0aGUgZG9tYWluDQo+ ICAgIG5lZWQgemVyby1TUi1jb25maWd1cmF0aW9uLg0KPiANCj4gIA0KPiANCj4gDQo+IFBsZWFz ZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1l IG9mIA0Kc3VibWlzc2lvbg0KPiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBh cmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJp YXQNCj4gDQoNCg== --=_alternative 000C730048257E7C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGFsbCw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk5ldyB2ZXJzaW9uIG9mIFNJRCBB bGxvY2F0aW9uIGhhcyBiZWVuDQp1cGRhdGVkIGFuZCBwdWJsaXNoZWQsIHRoaXMgZHJhZnQgZGVz Y3JpYmVzIGhvdyB0byBhY2NvbXBsaXNoIHplcm8tdG91Y2hlZA0KU1IuPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5BbmQgaW4gdGhpcyBkcmFmdCBpdCBk ZXNjcmliZXMgdGhlIHRpZS1icmVha2VyDQpiZXR3ZWVuIHR3byBvciBtb3JlIFNSTU5zIGJ5IFNS IENhcGFiaWxpdGllcyBTdWItVExWIGV4dGVuc2lvbiA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPndpdGggdGhlIEFsbG9jYXRpb24gYml0IHNldCwgdGhlIHRpZS1i cmVha2VyDQppcyBkZWNpZGVkIG9uIHRoZSByZWNlaXZlcnMgPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5ieSBqdWRnaW5nIHRoZSBTUk1Ocycgcm91dGVyIGlkIG9y IHN5c3RlbQ0KaWQsIHRoZSBkZXRhaWwgaW5mb3JtYXRpb24gaXMgZGVzY3JpYmVkIGluIHNlY3Rp b24gNC4yLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ Q29tbWVudHMgYXJlIHdlbGNvbWUgYW5kIGRpc2N1c3Npb25zDQppbiBQcmFndWUgYXJlIGV4cGVj dGVkLiBUaGFuayB5b3UuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5CZXN0IFJlZ2FyZHMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5UaW5nPGJyPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jODAwMDgw IGZhY2U9InNhbnMtc2VyaWYiPi0tLS0tINeqt6LIyyDBzubDMDM4NzY4L3VzZXIvenRlX2x0ZA0K yrG85CAyMDE1LTA3LTA4IDEwOjA0IC0tLS0tPC9mb250Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBz aXplPTI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnINC009ogMjAxNS0wNy0wNiAxNjoyMDowMjo8 YnI+DQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWx3 LXNwcmluZy1zaWQtYWxsb2NhdGlvbi0wMi50eHQ8YnI+DQomZ3Q7IGhhcyBiZWVuIHN1Y2Nlc3Nm dWxseSBzdWJtaXR0ZWQgYnkgVGluZyBMaWFvIGFuZCBwb3N0ZWQgdG8gdGhlPGJyPg0KJmd0OyBJ RVRGIHJlcG9zaXRvcnkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE5hbWU6ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ZHJhZnQtbHctc3ByaW5nLXNpZC1hbGxvY2F0aW9uPGJyPg0KJmd0OyBSZXZpc2lvbjog Jm5ic3A7IDAyPGJyPg0KJmd0OyBUaXRsZTogJm5ic3A7ICZuYnNwOyAmbmJzcDtTUFJJTkcgU0lE IEFsbG9jYXRpb248YnI+DQomZ3Q7IERvY3VtZW50IGRhdGU6ICZuYnNwOyAyMDE1LTA3LTA2PGJy Pg0KJmd0OyBHcm91cDogJm5ic3A7ICZuYnNwOyAmbmJzcDtJbmRpdmlkdWFsIFN1Ym1pc3Npb248 YnI+DQomZ3Q7IFBhZ2VzOiAmbmJzcDsgJm5ic3A7ICZuYnNwOzEyPGJyPg0KJmd0OyBVUkw6ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aHR0cHM6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWx3LTxicj4NCiZndDsgc3ByaW5nLXNpZC1hbGxvY2F0 aW9uLTAyLnR4dDxicj4NCiZndDsgU3RhdHVzOiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbHctc3ByaW5nLTxicj4NCiZn dDsgc2lkLWFsbG9jYXRpb24vPGJyPg0KJmd0OyBIdG1saXplZDogJm5ic3A7ICZuYnNwOyAmbmJz cDsgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWx3LXNwcmluZy1zaWQtYWxsb2Nh dGlvbi0wMjxicj4NCiZndDsgRGlmZjogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbHctc3ByaW5nLTxicj4N CiZndDsgc2lkLWFsbG9jYXRpb24tMDI8YnI+DQomZ3Q7IDxicj4NCiZndDsgQWJzdHJhY3Q6PGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7U2VnbWVudCBSb3V0aW5nIChTUikgYWxsb3dzIGZvciBhIGZs ZXhpYmxlIGRlZmluaXRpb24NCm9mIGVuZC10by1lbmQ8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtw YXRocyB3aXRoaW4gSUdQIHRvcG9sb2dpZXMgYnkgZW5jb2RpbmcgcGF0aHMgYXMgc2VxdWVuY2Vz DQpvZjxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3RvcG9sb2dpY2FsIHN1Yi1wYXRocywgY2FsbGVk ICZxdW90O3NlZ21lbnRzJnF1b3Q7LiAmbmJzcDtUaGVzZQ0Kc2VnbWVudHMgYXJlPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7YWR2ZXJ0aXNlZCBieSB0aGUgbGluay1zdGF0ZSByb3V0aW5nIHByb3Rv Y29scyAoSVMtSVMNCmFuZCBPU1BGKS4gJm5ic3A7QW5kPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7 YSBzZWdtZW50IGlzIGlkZW50aWZpZWQgYnkgYSBTZWdtZW50IFJvdXRpbmcgSUQgKFNJRCkuDQom bmJzcDtUaGlzIGRvY3VtZW50PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7cHJvcG9zZXMgYSBtZXRo b2QgdG8gcmVkdWNlIHRoZSBTSUQgY29uZmlndXJhdGlvbiBpbg0KYSBTUiBkb21haW4uPGJyPg0K Jmd0OyAmbmJzcDsgJm5ic3A7T25seSB0aGUgc2VsZWN0ZWQgU1Igbm9kZXMgd2hpY2ggbmFtZWQg U2VnbWVudCBSb3V0aW5nDQpNYW5hZ2VtZW50PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7Tm9kZXMg KFNSTU5zKSBhcmUgY29uZmlndXJlZCBieSBOTVMsIHdoaWxlIG90aGVyIFNScw0KaW4gdGhlIGRv bWFpbjxicj4NCiZndDsgJm5ic3A7ICZuYnNwO25lZWQgemVyby1TUi1jb25maWd1cmF0aW9uLjxi cj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOzxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFBsZWFzZSBub3RlIHRo YXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mDQpzdWJt aXNzaW9uPGJyPg0KJmd0OyB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUg YXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgSUVU RiBTZWNyZXRhcmlhdDxicj4NCiZndDsgPGJyPg0KPC9mb250PjwvdHQ+DQo= --=_alternative 000C730048257E7C_=-- From nobody Thu Jul 9 10:23:40 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA791A0AF8 for ; Thu, 9 Jul 2015 10:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qy1GAvwcO9v3 for ; Thu, 9 Jul 2015 10:23:37 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2E4B1A0AC8 for ; Thu, 9 Jul 2015 10:23:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3866; q=dns/txt; s=iport; t=1436462617; x=1437672217; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=PjtmkPS1LUv2mgQ5s9/I3YkUrmhMUVtXE6EwYB32zzw=; b=fcmQQ+8Mrkwy516rc9vwCCusfA4b7GkEYTOPc/WyQROd/6cyeDV5sXEq FmccVFC9YzFzTJJcCb6goXVWQ+XhDmrME+Wc3AKxtpDaLijw/XmBLW8nl mmjAXOaFvi/6wMdpi+pLxaEjju2pY2+hddlK/1hwBQjdn/nAuWiiUrEnc c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CSAwDdrJ5V/51dJa1bgxJUYAa7HAmBZwqFLUoCgV44FAEBAQEBAQGBCoQjAQEBBAEBAWsXBAIBCBEEAQEoBycLFAkIAQEEE4guDc8tAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLS4QjEQFYBoQlBYxih0sBhGaHGYE9hBiTEiaDe2+BDTqBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,441,1432598400"; d="scan'208";a="10305388" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 09 Jul 2015 17:23:36 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t69HNacx031469 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 9 Jul 2015 17:23:36 GMT Received: from xmb-aln-x14.cisco.com ([169.254.8.172]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.03.0195.001; Thu, 9 Jul 2015 12:23:36 -0500 From: "Yingzhen Qu (yiqu)" To: "spring@ietf.org" Thread-Topic: Poll for adoption: draft-litkowski-spring-sr-yang-01 Thread-Index: AdCyj5tD1JR8vUwWRNur1cz2VajArgHs5NAAAAYDlwA= Date: Thu, 9 Jul 2015 17:22:09 +0000 Message-ID: References: <8645_1435598498_55917EA2_8645_1259_1_53C29892C857584299CBF5D05346208A0F5CBF5F@OPEXCLILM21.corporate.adroot.infra.ftgroup> <28712_1436446026_559E6D4A_28712_61_1_53C29892C857584299CBF5D05346208A0F5EA120@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <28712_1436446026_559E6D4A_28712_61_1_53C29892C857584299CBF5D05346208A0F5EA120@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [10.24.43.234] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <8AB90BACE1A21149B2128727FB223EA1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Poll for adoption: draft-litkowski-spring-sr-yang-01 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 09 Jul 2015 17:23:40 -0000 I support this as co-author, and I=B9m not aware of any IPR related to this draft. Thanks, Yingzhen > >> -----Original Message----- >> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of >> bruno.decraene@orange.com >> Sent: Monday, June 29, 2015 7:22 PM >> To: spring@ietf.org >> Subject: [spring] Poll for adoption: draft-litkowski-spring-sr-yang-01 >>=20 >> Hello working group, >>=20 >> This email starts a two-week poll on adopting >>draft-litkowski-spring-sr-yang- >> 01 as a working group item. >> "YANG Data Model for Segment Routing " >> https://tools.ietf.org/html/draft-litkowski-spring-sr-yang-01 >>=20 >> Please send comments to the list and state if you support adoption or >>not. In >> the latter case, please also state the reasons. >>=20 >> This poll runs until July 13 2015. >>=20 >>=20 >> *Coincidentally*, we are also polling for knowledge of any IPR that >>applies >> to this draft, to ensure that IPR has been disclosed in compliance with >>IETF >> IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). >> *If you are listed as a document author or contributor* please respond >>to >> this email and indicate whether or not you are aware of any relevant >>IPR. >> The draft will not be adopted until a response has been received from >>each >> author and contributor. >> If you are not listed as an author or contributor, then please >>explicitly >> respond only if you are aware of any IPR that has not yet been >>disclosed in >> conformance with IETF rules. >>=20 >> Thank you >> Bruno & John >>=20 >> ______________________________________________________________ >> ___________________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >>exploites >> ou copies sans autorisation. Si vous avez recu ce message par erreur, >> veuillez le signaler a l'expediteur et le detruire ainsi que les pieces >>jointes. >> Les messages electroniques etant susceptibles d'alteration, Orange >>decline >> toute responsabilite si ce message a ete altere, deforme ou falsifie. >>Merci. >>=20 >> This message and its attachments may contain confidential or privileged >> information that may be protected by law; they should not be >>distributed, >> used or copied without authorisation. >> If you have received this email in error, please notify the sender and >>delete >> this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have >>been >> modified, changed or falsified. >> Thank you. >>=20 >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring > >__________________________________________________________________________ >_______________________________________________ > >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. > From nobody Fri Jul 10 00:10:27 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA75A1A8911 for ; Fri, 10 Jul 2015 00:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G6083uAPFvoD for ; Fri, 10 Jul 2015 00:10:23 -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 E8FBD1A890E for ; Fri, 10 Jul 2015 00:10:22 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 1BA1E26450B for ; Fri, 10 Jul 2015 09:10:21 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.60]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id F054A35C045 for ; Fri, 10 Jul 2015 09:10:20 +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.0235.001; Fri, 10 Jul 2015 09:10:20 +0200 From: To: "spring@ietf.org" Thread-Topic: IETF 93 Agenda Thread-Index: AdC63mL7Z8R0JQAxQlO/6YeLMuEoEg== Date: Fri, 10 Jul 2015 07:10:20 +0000 Message-ID: <10287_1436512221_559F6FDD_10287_210_4_53C29892C857584299CBF5D05346208A0F5EAFE9@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: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F5EAFE9OPEXCLILM21corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.2.125417 Archived-At: Subject: [spring] IETF 93 Agenda X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 10 Jul 2015 07:10:24 -0000 --_000_53C29892C857584299CBF5D05346208A0F5EAFE9OPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, SPRING agenda has been uploaded : https://datatracker.ietf.org/meeting/93/a= genda/spring/ If we missed your request for a slot, please send us an email. Thanks, CU in Prague Bruno, John ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A0F5EAFE9OPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

SPRING agenda has been uploaded=  : https://datatracker.ietf.org/meeting/93/agenda/spring/<= /a>

 

If we missed your request for a= slot, please send us an email.

 

Thanks,

CU in Prague<= /p>

Bruno, John 

______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A0F5EAFE9OPEXCLILM21corp_-- From nobody Sun Jul 12 20:38:54 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996801A0371; Sun, 12 Jul 2015 20:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.51 X-Spam-Level: X-Spam-Status: No, score=-101.51 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6nIBunuPm5o; Sun, 12 Jul 2015 20:38:52 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id D14891A036C; Sun, 12 Jul 2015 20:38:51 -0700 (PDT) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 7C355A7E7D43B; Mon, 13 Jul 2015 11:38:48 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id t6D3cYKJ068124; Mon, 13 Jul 2015 11:38:34 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn) To: mpls@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: peng.shaofu@zte.com.cn Date: Mon, 13 Jul 2015 11:38:34 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2015-07-13 11:38:22, Serialize complete at 2015-07-13 11:38:22 Content-Type: multipart/alternative; boundary="=_alternative 0014027548257E81_=" X-MAIL: mse01.zte.com.cn t6D3cYKJ068124 Archived-At: Cc: spring@ietf.org Subject: [spring] issue about draft-kumarkini-mpls-spring-lsp-ping-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 13 Jul 2015 03:38:53 -0000 This is a multipart message in MIME format. --=_alternative 0014027548257E81_= Content-Type: text/plain; charset="US-ASCII" Hi authors for Segment ID sub-TLVs such as IPv4 Prefix Node Segment ID described in this document, the protocol value would not only be ospf or isis, but also BGP and others. Especially for central spring network, SID is allocated by controller and not distributed on device side, we need a protocol value to address this case. thanks deccan -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. --=_alternative 0014027548257E81_= Content-Type: text/html; charset="US-ASCII"
Hi authors

for Segment ID sub-TLVs such as IPv4 Prefix Node Segment ID described in this document, the protocol value would not only be ospf or isis, but also BGP and others. Especially for central spring network, SID is allocated by controller and not distributed on device side, we need a protocol value to address this case.

thanks
deccan 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

--=_alternative 0014027548257E81_=-- From nobody Tue Jul 14 00:56:36 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F293C1A902D; Tue, 14 Jul 2015 00:56:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.21 X-Spam-Level: X-Spam-Status: No, score=-104.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id viiergymh59l; Tue, 14 Jul 2015 00:56:33 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id DD12D1A8FD4; Tue, 14 Jul 2015 00:56:32 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 2B2009E601ED9; Tue, 14 Jul 2015 15:52:15 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 074D272669410; Tue, 14 Jul 2015 15:56:27 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id t6E7u6N3081855; Tue, 14 Jul 2015 15:56:06 +0800 (GMT-8) (envelope-from peng.shaofu@zte.com.cn) To: gregory.mirsky@ericsson.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: peng.shaofu@zte.com.cn Date: Tue, 14 Jul 2015 15:56:05 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2015-07-14 15:55:50, Serialize complete at 2015-07-14 15:55:50 Content-Type: multipart/alternative; boundary="=_alternative 002B973948257E82_=" X-MAIL: mse01.zte.com.cn t6E7u6N3081855 Archived-At: Cc: mpls@ietf.org, spring@ietf.org Subject: [spring] issues about draft-mirsky-mpls-bfd-directed-03 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 14 Jul 2015 07:56:35 -0000 This is a multipart message in MIME format. --=_alternative 002B973948257E82_= Content-Type: text/plain; charset="US-ASCII" hi greg As the document says: "When LSP ping is used to bootstrap BFD session this document updates this and defines that LSP Ping MUST include the FEC corresponding to the destination segment and SHOULD NOT include FECs corresponding to some or all of segment imposed by the initiator. " I think that it likes LDP BFD session establishment. The disadvantage is that at egress LSR we can not support many BFD session when many ingress LSR want to create BFD session with the same egerss LSR at the same time, if all these ingress LSR use same Local Discriminator. In fact, SR-tunnel is a special TE-tunnel, both of them can direct flow along specified forwarding path, only different in signal and label stack depth. The FEC contained in the LSP ping echo request message used to bootstrap SR-tunnel BFD should represent the flow characteristic, such as INGRESS-ID, EGRESS-ID, PATH-ID, etc. Maybe we can reuse TE FEC, such as "RSVP IPv4 LSP" as defined in RFC4379. We can create more PATHs for an SR-tunnel, we can configure SR-tunnel BFD or SR-tunnel PATH BFD. The node/adjacency segment FEC as discussed in draft-kumarkini-mpls-spring-lsp-ping are also neccessary for LSP ping/traceroute FEC validation. I would really love your opinion. thanks deccan -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s). If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited. If you have received this mail in error, please delete it and notify us immediately. --=_alternative 002B973948257E82_= Content-Type: text/html; charset="US-ASCII"
hi greg

As the document says:

"When LSP ping is used to bootstrap BFD session this document updates
   this and defines that LSP Ping MUST include the FEC corresponding to
   the destination segment and SHOULD NOT include FECs corresponding to
   some or all of segment imposed by the initiator.  "

I think that it likes LDP BFD session establishment. The disadvantage is that at egress LSR we can not support many BFD session when many ingress LSR want to create BFD session with the same egerss LSR at the same time, if all these ingress LSR use same Local Discriminator.

In fact, SR-tunnel is a special TE-tunnel, both of them can direct flow along specified forwarding path, only different in signal and label stack depth. The FEC contained in the LSP ping echo request message used to bootstrap SR-tunnel BFD should represent the flow characteristic, such as INGRESS-ID, EGRESS-ID, PATH-ID, etc. Maybe we can reuse TE FEC, such as "RSVP IPv4 LSP" as defined in RFC4379. We can create more PATHs for an SR-tunnel, we can configure SR-tunnel BFD or SR-tunnel PATH BFD.

The node/adjacency segment FEC as discussed in draft-kumarkini-mpls-spring-lsp-ping are also neccessary for LSP ping/traceroute FEC validation.

I would really love your opinion.

thanks
deccan 


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.





--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail (and any attachment transmitted herewith) is privileged and confidential and is intended for the exclusive use of the addressee(s).  If you are not an intended recipient, any disclosure, reproduction, distribution or other dissemination or use of the information contained is strictly prohibited.  If you have received this mail in error, please delete it and notify us immediately.

--=_alternative 002B973948257E82_=-- From nobody Thu Jul 16 03:32:09 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABA81B38D6 for ; Thu, 16 Jul 2015 03:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Smi_jxXWo2a for ; Thu, 16 Jul 2015 03:32:05 -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 4A8DD1B38D0 for ; Thu, 16 Jul 2015 03:32:05 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 8DD19324BDE for ; Thu, 16 Jul 2015 12:32:03 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 6EE4235C06D for ; Thu, 16 Jul 2015 12:32:03 +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.0235.001; Thu, 16 Jul 2015 12:32:03 +0200 From: To: "spring@ietf.org" Thread-Topic: Please send you presentations for Prague Thread-Index: AdC/snQkVtt7fmCbS/+p7UsJv/euEw== Date: Thu, 16 Jul 2015 10:32:02 +0000 Message-ID: <4332_1437042723_55A78823_4332_5420_1_53C29892C857584299CBF5D05346208A0F5F2D6C@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.3] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A0F5F2D6COPEXCLILM21corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.16.85415 Archived-At: Subject: [spring] Please send you presentations for Prague X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 16 Jul 2015 10:32:07 -0000 --_000_53C29892C857584299CBF5D05346208A0F5F2D6COPEXCLILM21corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, We are meeting on Tuesday 13:00. Please send your slides to the chairs by Monday 10:00 so that they may be u= ploaded before the meeting. Thanks, Bruno, John From: spring [mailto:spring-bounces@ietf.org] On Behalf Of bruno.decraene@o= range.com Sent: Friday, July 10, 2015 9:10 AM To: spring@ietf.org Subject: [spring] IETF 93 Agenda Hi all, SPRING agenda has been uploaded : https://datatracker.ietf.org/meeting/93/a= genda/spring/ If we missed your request for a slot, please send us an email. Thanks, CU in Prague Bruno, John ___________________________________________________________________________= ______________________________________________ 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_53C29892C857584299CBF5D05346208A0F5F2D6COPEXCLILM21corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,=

&n= bsp;

We are = meeting on Tuesday 13:00.

&n= bsp;

Please = send your slides to the chairs by Monday 10:00 so that they may be uploaded= before the meeting.

&n= bsp;

Thanks,=

Bruno, = John

&n= bsp;

 
______________________________________________________________________=
___________________________________________________

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_53C29892C857584299CBF5D05346208A0F5F2D6COPEXCLILM21corp_-- From nobody Mon Jul 20 00:15:20 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46A471A00CD for ; Mon, 20 Jul 2015 00:15:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aVoyUGbHtaZ8 for ; Mon, 20 Jul 2015 00:15:18 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51E961A009E for ; Mon, 20 Jul 2015 00:15:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3170; q=dns/txt; s=iport; t=1437376518; x=1438586118; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=S4U4s5iVjE3ebAVSW3VpHFeDFfNo/LdS+OXhpeVtUjY=; b=TSJ01HmItyDjeQCO8MbbxyW4ext2Wz1iGJhgcp2w7lCpHCDninSNKZhi mEO7FipDOaukBRjKSSwaZv26g3kT1QbExguBZNggtfWAKVJvaoXhG/MIc W4XvzHFgJIyLbgZXTAbxCnAbJqekriwumlPjwQopW5tE/9W5STIp4oyn8 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BIAwDSn6xV/4cNJK1cgxNUaQaDHbhECYF3hXUCHIEFOBQBAQEBAQEBgQqEIwEBAQQjEUMOBgEZBAEBAwIGHQMCBDAUAQgJAQQBEgiIJg2ua5VBAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4EiiiqEVT6CYi+BFAWMOIgaAYRuiHVGg1SPSYNhJoI+gT5vAYFGgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,507,1432598400"; d="scan'208";a="170192197" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-3.cisco.com with ESMTP; 20 Jul 2015 07:15:07 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t6K7F7iI023765 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 Jul 2015 07:15:07 GMT Received: from xmb-rcd-x05.cisco.com ([169.254.15.132]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Mon, 20 Jul 2015 02:15:06 -0500 From: "Dennis Cai (dcai)" To: "spring@ietf.org" , "bruno.decraene@orange.com" , "John G. Scudder" Thread-Topic: New Version Notification for draft-filsfils-spring-large-scale-interconnect-00.txt Thread-Index: AdDCuul+CyUxjA6vRyexYTj5h0/vNQ== Date: Mon, 20 Jul 2015 07:15:06 +0000 Message-ID: <623637051A3DC34E80FC9BA35B4629951E90EA0F@xmb-rcd-x05.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.247.131] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [spring] New Version Notification for draft-filsfils-spring-large-scale-interconnect-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jul 2015 07:15:20 -0000 SGksIEFsbCwNCg0KVGhpcyBkcmFmdCBpcyBhYm91dCBhbiBhcHBsaWNhdGlvbiBvZiBTZWdtZW50 IFJvdXRpbmcgdG8gc2NhbGUgdGhlIG5ldHdvcmsgdG8gc3VwcG9ydCBodW5kcmVkcyBvZiB0aG91 c2FuZHMgb2YgbmV0d29yayBub2RlcywgYW5kIHRlbnMgb2YgbWlsbGlvbnMgb2YgcGh5c2ljYWwg dW5kZXJsYXkgZW5kcG9pbnRzLiBSZXF1ZXN0IHlvdSBhbGwgdG8gcmV2aWV3IHRoZSBkcmFmdCBh bmQgcHJvdmlkZSB5b3VyIHZhbHVhYmxlIGZlZWRiYWNrLg0KDQpXZSBoYXZlIHJlcXVlc3RlZCBh IHNwZWFraW5nIHNsb3QgZm9yIHRoaXMgZHJhZnQuDQoNClRoYW5rcw0KRGVubmlzDQoNCg0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogTW9uZGF5LCBKdWx5 IDIwLCAyMDE1IDg6MjYgQU0NClRvOiBSb2IgU2hha2lyOyBXaW0gSGVuZGVyaWNreDsgU3RlZmFu byBQcmV2aWRpIChzcHJldmlkaSk7IEZyYW5jaXMgRmVyZ3Vzb247IFN0ZXZlbiBMaW47IFRpbSBM YUJlcmdlOyBMdWF5IEphbGlsOyBEYXZlIENvb3BlcjsgQ2xhcmVuY2UgRmlsc2ZpbHMgKGNmaWxz ZmlsKTsgRGVubmlzIENhaSAoZGNhaSk7IEx1YXkgSmFsaWw7IFN0ZWZhbm8gUHJldmlkaSAoc3By ZXZpZGkpOyBCcnVubyBEZWNyYWVuZTsgRGF2ZSBDb29wZXI7IENsYXJlbmNlIEZpbHNmaWxzIChj Zmlsc2ZpbCk7IEZyYW5jaXMgRmVyZ3Vzb247IEJydW5vIERlY3JhZW5lOyBUaW0gTGFiZXJnZTsg U3RldmVuIExpbjsgV2ltIEhlbmRlcmlja3g7IFJvYiBTaGFraXI7IERlbm5pcyBDYWkgKGRjYWkp DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWZpbHNmaWxzLXNw cmluZy1sYXJnZS1zY2FsZS1pbnRlcmNvbm5lY3QtMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWZpbHNmaWxzLXNwcmluZy1sYXJnZS1zY2FsZS1pbnRlcmNvbm5lY3QtMDAu dHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IERlbm5pcyBDYWkgYW5kIHBv c3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtZmlsc2ZpbHMtc3By aW5nLWxhcmdlLXNjYWxlLWludGVyY29ubmVjdA0KUmV2aXNpb246CTAwDQpUaXRsZToJCUludGVy Y29ubmVjdGluZyBNaWxsaW9ucyBPZiBFbmRwb2ludHMgV2l0aCBTZWdtZW50IFJvdXRpbmcNCkRv Y3VtZW50IGRhdGU6CTIwMTUtMDctMTkNCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQ YWdlczoJCTEwDQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQt ZHJhZnRzL2RyYWZ0LWZpbHNmaWxzLXNwcmluZy1sYXJnZS1zY2FsZS1pbnRlcmNvbm5lY3QtMDAu dHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtZmlsc2ZpbHMtc3ByaW5nLWxhcmdlLXNjYWxlLWludGVyY29ubmVjdC8NCkh0bWxpemVkOiAg ICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZmlsc2ZpbHMtc3ByaW5nLWxh cmdlLXNjYWxlLWludGVyY29ubmVjdC0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVu dCBkZXNjcmliZXMgYW4gYXBwbGljYXRpb24gb2YgU2VnbWVudCBSb3V0aW5nIHRvIHNjYWxlDQog ICB0aGUgbmV0d29yayB0byBzdXBwb3J0IGh1bmRyZWRzIG9mIHRob3VzYW5kcyBvZiBuZXR3b3Jr IG5vZGVzLCBhbmQNCiAgIHRlbnMgb2YgbWlsbGlvbnMgb2YgcGh5c2ljYWwgdW5kZXJsYXkgZW5k cG9pbnRzLiBUaGlzIHVzZS1jYXNlIGNhbiBiZQ0KICAgYXBwbGllZCB0byB0aGUgaW50ZXJjb25u ZWN0aW9uIG9mIG1hc3NpdmUtc2NhbGUgREMncyBhbmQvb3IgbGFyZ2UNCiAgIGFnZ3JlZ2F0aW9u IG5ldHdvcmtzLiAgRm9yd2FyZGluZyB0YWJsZXMgb2YgbWlkcG9pbnQgYW5kIGxlYWYgbm9kZXMN CiAgIG9ubHkgcmVxdWlyZSBhIGZldyB0ZW5zIG9mIHRob3VzYW5kcyBvZiBlbnRyaWVzLg0KDQoN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0 YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVudGls IHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0 Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Mon Jul 20 00:52:30 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D542F1A01F2 for ; Mon, 20 Jul 2015 00:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TWOlRmv6Mb40 for ; Mon, 20 Jul 2015 00:52:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1919A1A01C6 for ; Mon, 20 Jul 2015 00:52:27 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda09.si.francetelecom.fr (ESMTP service) with ESMTP id E20F8C0109 for ; Mon, 20 Jul 2015 09:52:25 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id C504E1800E3 for ; Mon, 20 Jul 2015 09:52:25 +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.0235.001; Mon, 20 Jul 2015 09:52:25 +0200 From: To: "spring@ietf.org" Thread-Topic: Poll for adoption: draft-litkowski-spring-sr-yang-01 Thread-Index: AdCyj5tD1JR8vUwWRNur1cz2VajArgQMOJew Date: Mon, 20 Jul 2015 07:52:25 +0000 Message-ID: <31563_1437378745_55ACA8B9_31563_18671_1_53C29892C857584299CBF5D05346208A0F5F7B77@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <8645_1435598498_55917EA2_8645_1259_1_53C29892C857584299CBF5D05346208A0F5CBF5F@OPEXCLILM21.corporate.adroot.infra.ftgroup> In-Reply-To: <8645_1435598498_55917EA2_8645_1259_1_53C29892C857584299CBF5D05346208A0F5CBF5F@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: 2015.7.20.70317 Archived-At: Subject: Re: [spring] Poll for adoption: draft-litkowski-spring-sr-yang-01 X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jul 2015 07:52:29 -0000 This draft has been adopted as a WG draft. Authors, please resubmit as draft-ietf-spring-sr-yang-00 Thank you. Bruno & John > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of > bruno.decraene@orange.com > Sent: Monday, June 29, 2015 7:22 PM > To: spring@ietf.org > Subject: [spring] Poll for adoption: draft-litkowski-spring-sr-yang-01 >=20 > Hello working group, >=20 > This email starts a two-week poll on adopting draft-litkowski-spring-sr-y= ang- > 01 as a working group item. > "YANG Data Model for Segment Routing " > https://tools.ietf.org/html/draft-litkowski-spring-sr-yang-01 >=20 > Please send comments to the list and state if you support adoption or not= . In > the latter case, please also state the reasons. >=20 > This poll runs until July 13 2015. >=20 >=20 > *Coincidentally*, we are also polling for knowledge of any IPR that appli= es > to this draft, to ensure that IPR has been disclosed in compliance with I= ETF > IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). > *If you are listed as a document author or contributor* please respond to > this email and indicate whether or not you are aware of any relevant IPR. > The draft will not be adopted until a response has been received from each > author and contributor. > If you are not listed as an author or contributor, then please explicitly > respond only if you are aware of any IPR that has not yet been disclosed = in > conformance with IETF rules. >=20 > Thank you > Bruno & John >=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, > 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. Mer= ci. >=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 Jul 20 01:23:07 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8981A0451 for ; Mon, 20 Jul 2015 01:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 zMsFNf_-fRCG for ; Mon, 20 Jul 2015 01:23:03 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 605CC1A0334 for ; Mon, 20 Jul 2015 01:23:03 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so19105235wib.1 for ; Mon, 20 Jul 2015 01:23:02 -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:content-type; bh=PijPwutqgQ/Zt6jkflyQtm5h7W/4l9egOO8o1A86fus=; b=b0y+4vVflIYO6j/pZxqAgjN9ljzRCzh7IATP2tdaTB1SoLSwQcsEYMsms5jElOu/jf 3CXB0PUN0YYiAluvb/iTs+hxcYDQIqJyEyZP3jJRutLdYRn9JDmkpbJ1cv+opV7NnbwC jqsxRgv6v+jkqCJfdDmIU/zyo4vjqLZSfo4lZC7OnxxhiOH+J4JI8a4t4y6aYalzHCFQ rnnDHuCB0c54RO6KAGqUJcOe/56SoGIeFUh9BWP71BGVFW+1QfJKD1gWZcgfzmZJWSm1 IxgkvSCpV/sX6tr4NQQiqBaldQMsYe1FwGgQWJSuQJHRVW8GR1z8wSzKekrzVvJSAgO8 aHtA== MIME-Version: 1.0 X-Received: by 10.181.13.195 with SMTP id fa3mr19243966wid.7.1437380582017; Mon, 20 Jul 2015 01:23:02 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.194.95.168 with HTTP; Mon, 20 Jul 2015 01:23:01 -0700 (PDT) In-Reply-To: <623637051A3DC34E80FC9BA35B4629951E90EA0F@xmb-rcd-x05.cisco.com> References: <623637051A3DC34E80FC9BA35B4629951E90EA0F@xmb-rcd-x05.cisco.com> Date: Mon, 20 Jul 2015 10:23:01 +0200 X-Google-Sender-Auth: B-FBK1QpXTLN7DU6Aa4pRo6mOWM Message-ID: From: Robert Raszuk To: "Dennis Cai (dcai)" Content-Type: multipart/alternative; boundary=f46d043c07d4ff93cb051b4a3e8a Archived-At: Cc: "bruno.decraene@orange.com" , "spring@ietf.org" , "John G. Scudder" Subject: Re: [spring] New Version Notification for draft-filsfils-spring-large-scale-interconnect-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 20 Jul 2015 08:23:06 -0000 --f46d043c07d4ff93cb051b4a3e8a Content-Type: text/plain; charset=UTF-8 Hi Dennis, I have read your proposal and have one major question ... It says: "It is out of the scope of this document to describe how the SID lists are computed and programmed at the source nodes. As an example, a centralized controller could be the source of the Prefix SID allocation. The controller could continuously collect the state of each domain (e.g. BGP-LS)." How do you distribute IP reachability across domains - say between L1 and L2 over C? Since you mentioned DC-interconnect use case is the plan to achieve any to any compute node to compute node interconnect via controller ? How would tenants (in their respective VMs or LXCs) practically tell "controller" that they need to talk L1 to L2 to get proper SID sequence ? Note also that it is exactly in the reachability and forwarding anchors distribution where the crux of the scalable multi domain interconnect resides. So far AFAIK both Contrail and LISP solved it. Likewise another alternative is provided in BGP Vector Routing proposal: https://tools.ietf.org/html/draft-patel-raszuk-bgp-vector-routing-00 Of course having a controller reachability and SID distribution is an option. However for the proposal to stand solid I am afraid more questions needs to be answered .. in case of interprovider - who controls such oracle, how end points signal need to reach remote destinations etc ... Many thx, R. PS. For easier reading I recommend to avoid calling as "C" both core domain and leave node :) On Mon, Jul 20, 2015 at 9:15 AM, Dennis Cai (dcai) wrote: > Hi, All, > > This draft is about an application of Segment Routing to scale the network > to support hundreds of thousands of network nodes, and tens of millions of > physical underlay endpoints. Request you all to review the draft and > provide your valuable feedback. > > We have requested a speaking slot for this draft. > > Thanks > Dennis > > > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, July 20, 2015 8:26 AM > To: Rob Shakir; Wim Henderickx; Stefano Previdi (sprevidi); Francis > Ferguson; Steven Lin; Tim LaBerge; Luay Jalil; Dave Cooper; Clarence > Filsfils (cfilsfil); Dennis Cai (dcai); Luay Jalil; Stefano Previdi > (sprevidi); Bruno Decraene; Dave Cooper; Clarence Filsfils (cfilsfil); > Francis Ferguson; Bruno Decraene; Tim Laberge; Steven Lin; Wim Henderickx; > Rob Shakir; Dennis Cai (dcai) > Subject: New Version Notification for > draft-filsfils-spring-large-scale-interconnect-00.txt > > > A new version of I-D, draft-filsfils-spring-large-scale-interconnect-00.txt > has been successfully submitted by Dennis Cai and posted to the IETF > repository. > > Name: draft-filsfils-spring-large-scale-interconnect > Revision: 00 > Title: Interconnecting Millions Of Endpoints With Segment Routing > Document date: 2015-07-19 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/internet-drafts/draft-filsfils-spring-large-scale-interconnect-00.txt > Status: > https://datatracker.ietf.org/doc/draft-filsfils-spring-large-scale-interconnect/ > Htmlized: > https://tools.ietf.org/html/draft-filsfils-spring-large-scale-interconnect-00 > > > Abstract: > This document describes an application of Segment Routing to scale > the network to support hundreds of thousands of network nodes, and > tens of millions of physical underlay endpoints. This use-case can be > applied to the interconnection of massive-scale DC's and/or large > aggregation networks. Forwarding tables of midpoint and leaf nodes > only require a few tens of thousands of entries. > > > > > > 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. > > The IETF Secretariat > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > --f46d043c07d4ff93cb051b4a3e8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Dennis,

=
I have read your proposal and have one major quest= ion ...=C2=A0

It says:=

=
"It is out of the scope of this document to describ= e how the SID lists
are computed and programmed at = the source nodes. As an example, a
centralized con= troller could be the source of the Prefix SID
alloc= ation. The controller could continuously collect the state of
each domain (e.g. BGP-LS)."

How do you distribute IP reachability across domains = - say between L1 and L2 over C?=C2=A0

Since you mentioned DC-interconnect use case is the plan to= achieve any to any compute node to compute node interconnect via controlle= r ? How would tenants (in their respective VMs or LXCs) practically tell &q= uot;controller" that they need to talk L1 to L2 to get proper SID sequ= ence ?=C2=A0

Note also= that it is exactly in the reachability and forwarding anchors distribution= where the crux of the scalable multi domain interconnect resides.=C2=A0

So far AFAIK both Contra= il and LISP solved it.=C2=A0

Likewise another alternative is provided in BGP Vector Routing pro= posal:=C2=A0
https://tools.ietf.org/html/draf= t-patel-raszuk-bgp-vector-routing-00

Of course = having a controller reachability and SID distribution is an option. However= for the proposal to stand solid I am afraid more questions needs to be ans= wered .. in case of interprovider - who controls such oracle, how end point= s signal need to reach remote destinations etc ...

Many= thx,
R.

P= S. For easier reading I recommend to avoid calling as "C" both co= re domain and leave node :)

<= div class=3D"gmail_extra">
On Mon, Jul 20, 20= 15 at 9:15 AM, Dennis Cai (dcai) <dcai@cisco.com> wrote:
Hi, All,

This draft is about an application of Segment Routing to scale the network = to support hundreds of thousands of network nodes, and tens of millions of = physical underlay endpoints. Request you all to review the draft and provid= e your valuable feedback.

We have requested a speaking slot for this draft.

Thanks
Dennis




-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Monday, July 20, 2015 8:26 AM
To: Rob Shakir; Wim Henderickx; Stefano Previdi (sprevidi); Francis Ferguso= n; Steven Lin; Tim LaBerge; Luay Jalil; Dave Cooper; Clarence Filsfils (cfi= lsfil); Dennis Cai (dcai); Luay Jalil; Stefano Previdi (sprevidi); Bruno De= craene; Dave Cooper; Clarence Filsfils (cfilsfil); Francis Ferguson; Bruno = Decraene; Tim Laberge; Steven Lin; Wim Henderickx; Rob Shakir; Dennis Cai (= dcai)
Subject: New Version Notification for draft-filsfils-spring-large-scale-int= erconnect-00.txt


A new version of I-D, draft-filsfils-spring-large-scale-interconnect-00.txt=
has been successfully submitted by Dennis Cai and posted to the IETF reposi= tory.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-filsfils-spring-large-s= cale-interconnect
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Interconnecting Millions Of Endpoi= nts With Segment Routing
Document date:=C2=A0 2015-07-19
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/dr= aft-filsfils-spring-large-scale-interconnect-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-filsfils-spring= -large-scale-interconnect/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-filsfils-spring-large-scale-= interconnect-00


Abstract:
=C2=A0 =C2=A0This document describes an application of Segment Routing to s= cale
=C2=A0 =C2=A0the network to support hundreds of thousands of network nodes,= and
=C2=A0 =C2=A0tens of millions of physical underlay endpoints. This use-case= can be
=C2=A0 =C2=A0applied to the interconnection of massive-scale DC's and/o= r large
=C2=A0 =C2=A0aggregation networks.=C2=A0 Forwarding tables of midpoint and = leaf nodes
=C2=A0 =C2=A0only require a few tens of thousands of entries.





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

The IETF Secretariat

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

--f46d043c07d4ff93cb051b4a3e8a-- From nobody Mon Jul 20 04:39:35 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A561A21C2; Mon, 20 Jul 2015 04:39:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zH34UhUgqzhM; Mon, 20 Jul 2015 04:39:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id F3A811A21BB; Mon, 20 Jul 2015 04:39:27 -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.0.4.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150720113927.24200.39759.idtracker@ietfa.amsl.com> Date: Mon, 20 Jul 2015 04:39:27 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-sr-yang-00.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 11:39:31 -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 Working Group of the IETF. Title : YANG Data Model for Segment Routing Authors : Stephane Litkowski Yingzhen Qu Pushpasis Sarkar Jeff Tantsura Filename : draft-ietf-spring-sr-yang-00.txt Pages : 21 Date : 2015-07-20 Abstract: This document defines a YANG data model ([RFC6020]) for segment routing ([I-D.ietf-spring-segment-routing]) configuration and operation. This YANG model is intended to be used on network elements to configure or operate segment routing. This document defines also generic containers that SHOULD be reused by IGP protocol modules to support segment routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-spring-sr-yang/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-spring-sr-yang-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 Tue Jul 21 05:35:04 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1078A1A1A54 for ; Tue, 21 Jul 2015 05:35:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfoucQd-ph2M for ; Tue, 21 Jul 2015 05:35:01 -0700 (PDT) Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id E7CCA1A0406 for ; Tue, 21 Jul 2015 05:35:00 -0700 (PDT) Received: by puck.nether.net (Postfix, from userid 507) id 89C155408D0; Tue, 21 Jul 2015 08:34:59 -0400 (EDT) Date: Tue, 21 Jul 2015 08:34:59 -0400 From: Jon Mitchell To: Chris Bowers Message-ID: <20150721123459.GA1274@puck.nether.net> References: <20150624230327.12191.65118.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] FW: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2015 12:35:02 -0000 On 24/06/15 23:09 +0000, Chris Bowers wrote: > This updated version of the draft includes a concrete proposal for ISIS extensions to implement per-algorithm label blocks. > Chris - As you discussed in the meeting today in option 2 (the proposal) there is a "savings" that is achieved by not allocating a large label space as is required in option 1 since we may not be able to predict the future of algorithm needs in the network. But wouldn't you agree that since you are allocating a node index in every fractured address space (whether required or not) in option 2, since address space that is partitioned typically consumes more space than unfractured space (due to loss because of imperfect planning), as you increase the number of algorithms aren't you more likely to consume more overall space with this technique? Secondly there was a statement made that there is an advantage to option 2 that it allows easier provisioning of node index value (as it's reused) per algorithm. Isn't it just as easy for an implementation to allow the user to just configure a local implementation offset for an algorithm which requires no protocol changes and has more flexiblity as it doesn't need to be configured for prefix SID's that don't require it (similar as Ahmed suggested at the mic, i.e. algorithm 2 = +1000) that could be configured at every node? Assuming OSS provisions SID's sequentially this seems to work just as well... Thanks, Jon From nobody Tue Jul 21 05:45:01 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD4B1A0334 for ; Tue, 21 Jul 2015 05:44:59 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2_BeujP-xqRa for ; Tue, 21 Jul 2015 05:44:57 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0761.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:761]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58691A1B5A for ; Tue, 21 Jul 2015 05:44:56 -0700 (PDT) Received: from BLUPR05MB433.namprd05.prod.outlook.com (10.141.27.140) by BLUPR05MB259.namprd05.prod.outlook.com (10.141.22.21) with Microsoft SMTP Server (TLS) id 15.1.219.17; Tue, 21 Jul 2015 12:44:37 +0000 Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from hannes-mba.local (193.110.55.14) by BLUPR05MB433.namprd05.prod.outlook.com (10.141.27.140) with Microsoft SMTP Server (TLS) id 15.1.219.17; Tue, 21 Jul 2015 12:44:30 +0000 Received: from hannes-mba.local (localhost [127.0.0.1]) by hannes-mba.local (Postfix) with ESMTP id C3318154CE32; Tue, 21 Jul 2015 14:44:14 +0200 (CEST) Message-ID: <55AE3E9E.7080108@juniper.net> Date: Tue, 21 Jul 2015 14:44:14 +0200 From: Hannes Gredler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Jon Mitchell , Chris Bowers References: <20150624230327.12191.65118.idtracker@ietfa.amsl.com> <20150721123459.GA1274@puck.nether.net> In-Reply-To: <20150721123459.GA1274@puck.nether.net> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [193.110.55.14] X-ClientProxiedBy: HE1PR05CA0012.eurprd05.prod.outlook.com (25.162.181.22) To BLUPR05MB433.namprd05.prod.outlook.com (10.141.27.140) X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB433; 2:lztah60LkaCaCdPdhS8KZ2c/uQy5N3+ETDyknMCWQ8kVyumFYP7lZZ/i4EkZse7d; 3:GlJmK/Rnr90WEhuP1IgU6yAMTjK+WwJ+8yJ9819xtUjeKR9Kzv7x/Fl3U0qRk3d5+qlbXbrRy1KD+9NMCxb1gRzy0pe88V7Y3r1CE4fXLLaXmkQa7KgNR0NQLZPB/qdAyL8ClhitB8+SyGmfo+A6QQ==; 25:O6z655qTPu6hKon4UXiDmFGsct2EAhngXMrUXho4HEd/M+dr8zER7CnJIoFvAWgM1BANgjlLpTqUbhfNejpXO42kkFnb9USY7ZDYyoN85vU7ti2brxGRbinOvkl/6xcKbS3YDzyeV58ndaMNkoMWwIvd5mOuN/giqA0q3aQdJbEmgptfeCcXizwhdZTQJSk6LjWz4eX+ZEhjYh0Uq4G5xYd9Il8GIF8uCC6ukUeKKGH0ZiNN5Psh3qunB2tEeQrkYQ9WTnpAg55QSroLcejypw== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB433; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB259; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB433; 20:J56kS/8UdQBKGmjUtuP8DXCMZSXQBSO9/ocl9Ach3ggjiRaNBOH89PsaeOx0tniH3b7LQI2ihIm9hucjy25Cb8hmvV3EmNjPeabEAfFs5x/77vPzWS0sDNDi3Lc1lIlQwq9ptyzCY1VymEDlJg9Sps1ZygI3sgFB5Nt1xggJIAWlA1U53cBy6fBm8wvB4EDZGqtWg3srVMiSPJ/o0G2F49hpbkWCDo769LEZvlydP7gGWoXIJgMgLQKiYGnSXh/eivdsQVqcAbPuXn0n3gQSzkHwuCbXsPNowe6ZzTASs44GA3nbvYhq670A4VGbPwuAEdjpN4ld7NBeQ16w5vKhjFT8r3xkgMUBEnnypfNxzufUqOy5WK9i69+zGS5TF/DrP5wmzjAjirTqDTulsCP7yUqojKLrr+viIKiLrlACub5z61bW3uXJ1JGkL8bMnh4s2hJ0EzwBJzDDGZYuOCwKLmhjRhN/d4Bl/vRbr+wcY5wX/zXUyQaMLiZ1N8XSZWtQ; 4:WuQFluObmg6Akm9FnO2j9Xc8SjCQb3TLwYU5J5m1+H3Bi+D3y1ungOPH9ScCgfPNz9P/4paCnHhnFMYnZGwkLkBvYGvhnFt5dTlVTNT4kzvI5qqEfCyRtCZEhlgxKpAx7n4EOJoPMogmqsjX1HbmL7Q21A+aFNbpBICogGBbvjy/lVhxjR2baVVCG7+WDLDFe9QujOzV84dsar9UMBynsWfRUbk0cl13SYGQxl9z/fsulHWVCn0PMnieN2JCnWmuOllTn7OHTknVn3gHAM4VuW+b6SRWtgZP6I2zb9mf+KQ= BLUPR05MB433: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB433; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB433; X-Forefront-PRVS: 0644578634 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(479174004)(76176999)(40100003)(46102003)(87266999)(50986999)(66066001)(54356999)(47776003)(86362001)(59896002)(230783001)(4001450100002)(65816999)(50466002)(122386002)(87976001)(122856001)(62966003)(2950100001)(5001770100001)(65956001)(64126003)(92566002)(77096005)(5001960100002)(77156002)(76506005)(23746002)(33656002)(561944003)(36756003)(189998001)(579124003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB433; H:hannes-mba.local; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1; BLUPR05MB433; 23:MxGoFx458gCh8arxRfuX1lnag++y7j/BBMNgTn?= =?Windows-1252?Q?GwoTkgIAdbLujvbhj+YEMJccmoDpKHLyvxYQ6taap3ogn7c9QYzj2Lj/?= =?Windows-1252?Q?gINQMyYr/NkUjQgP+5FskjhtBcW2oNhegsKC2LfRSR51ZRo5hwj/KZmx?= =?Windows-1252?Q?8iViwczjYIeqDN2T0x9fe9e5AMfvozgRuNnsFTowejtRkFXwJkmcRNgy?= =?Windows-1252?Q?ItzN22vsHQNlwx18bbEy8Fkfx2Zh1L7OqWHkV9FMzhlNm+9Hga/HZ2wr?= =?Windows-1252?Q?7ByOuDNMsKhL6sx5L9IuLRKrffGB6qxPre6fFJcqOTEuA4KP1r3Icg1h?= =?Windows-1252?Q?GSP1fUmvCGxPSbusCmVXtmFYff8brmgSK6c7kWkuDju9Z0xJWX9JY8BO?= =?Windows-1252?Q?Qie4gcpgK0KZCwEu0C1TgxylyCYcPanA3dlahg/odPghBQei6OgZj1ro?= =?Windows-1252?Q?bifsww27jn7ifYwY2/6WTb5MbEOqDKuHBFqwgPGSwoymgi7rVB93zO7A?= =?Windows-1252?Q?F6ItaO5Gmn6Bm7yg2Sli4BAMSs9eGcIhTkqWUMJns6ughhKQX+pR6dVq?= =?Windows-1252?Q?qOJakSLFZMUqXftwIG1NdAQSSdyjReGOweppBxXxRbylztXhY827zxXx?= =?Windows-1252?Q?t+8uWn5wM+QXagwQImHqyFwXSseOIFbGuGTVpXT9+QoGBMqLgF5Ni+7b?= =?Windows-1252?Q?K5+xDM+zdkMVwjo2MLhLT6s0NMblI/Hvw1DnGD/yaq7hatnLnJqiGqBP?= =?Windows-1252?Q?Sna9lXkoaMi+o4ruheTRqlYJkOmr/NluCVJiHbtEpUKIaLdxsOGoIUzs?= =?Windows-1252?Q?b72kNlJugzNw0HCJKe1aHLjCDOyJ7c6GtTU+J9OkLEnu8gqPXkUeGvVq?= =?Windows-1252?Q?u3dnwvfgpbJkyPp8Tk2jtOPeUOoWlEfud1q45kn/u3a9LVLFTIqFHEDR?= =?Windows-1252?Q?YwA00YcjgGb0efP9Di1GMt1mPrgyOitJxHP0khQM1w6JgNtc7uYeOfQA?= =?Windows-1252?Q?Z5D9NR1Pe5uTd87FjLx6dA8tMexIXMMjTe752E9TIA1Z1K/w=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB433; 5:erVw3Cgooi3v2cJ50ugDgYqrVejipyRfx6If0FNsT6iZo6AmcDoqSfgODT5YMLX7u7l3Cyuo+Y08SmTgvF7o32Jg52cRJNQp17kf/BBDwPzZqW1jxPgP6JfQuEZoDBmQHoqsCFchwcLee9yRHRvSpQ==; 24:QaBojh8Sq74GmwsK9rW2feKl9F8S6quABk7vHfmbGx4nN4yKPOtiDHaAkYHPvM4ZhmFHoXRV3oyfwKxOfODMzW6lOS32lxB0N+RDBEUjYt8=; 20:iTsc1tQKh3+GBfPZ6/13/rH7ZX7oMxYRLz+9NMw5pTpV1XEWe9A17sTuxeh7JQlsfNw1FRZHx6qSW+tSnbFZKQ== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Jul 2015 12:44:30.9604 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB433 X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB259; 2:XM5isbdCL+z8NH+ZeOWjZDjySxf047h9G4LIVhomYYUa5yuL02vyQUv3PrxuunUs; 3:DpEKnvswbkGeFVDvh/puYWtB+Ecp1yJZNonKvstaboTH4N/14UEx2TiEcl7vF+KoF9Bh6lBB9wvkcGdyO4b2SB9pxLJ3V1w6r10s4lvRSYW3B08EF3qz7u5Ni9dBmn1UMouspPe1R6q2kSo1rZYU+Q==; 25:KLa/Ery2pWLC6kgPkWp/5bRN3bxbU4K83L9L6cgkBnniwDkunRQwhvkPYBgX5UpEKZ22FerdfuqYFteDS85jVbxMaQgGzER/UEhX7hx1JJsRq634O5mibj6x5Xu6JIfQ2AITEeoIktLPPz8JIknz+a2Xmu3K/Tw3nlgyS02Zbyun2eb1wTa3v7QJ8wu/HiNtiyqldenzz+1/zvQnHPLDDmBWYyKiMaq7esV0mZaGdS6TJ8D9uV/a2wGBPQDpOJsjQurLWGfoj2en/2IrHkeFgQ==; 20:I3SSfCxJLJAtqG6YxX3HZM7oLzoEgBM8YXmIgGYs7Msns6dzhlwvD9rg9+d/ZVhPtAc2SJ3zh4chje6B9rsUZA==; 23:VrCFq6vCcwjha9d8uJVkzXz41QLKj8ua9bkLhFIaoJHKiP1FuuFroPJamnNvvoLB7bUOz57CGQFnBfYg0lnlWvGuri29308+mrQ8nBTlKFQsnxRqLXtwTy48fOBkaLbDScAZUy5Uci7MDIW+uqehxE9us1M0sE62NBblYRNRKrF3MElraxVuWp5er2yPoqwGgYeuhiYukXCu3iW9z9eBZb0z7BV6s0POf1pI3Bw0vLiiNozxou7iIKkMwX3fQ0F9 BLUPR05MB259: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: juniper.net Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] FW: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2015 12:44:59 -0000 hi jon, see inline - prefixed by HG> On 7/21/15 14:34, Jon Mitchell wrote: > On 24/06/15 23:09 +0000, Chris Bowers wrote: >> This updated version of the draft includes a concrete proposal for ISIS extensions to implement per-algorithm label blocks. >> > Chris - > > As you discussed in the meeting today in option 2 (the proposal) there > is a "savings" that is achieved by not allocating a large label space as > is required in option 1 since we may not be able to predict the future > of algorithm needs in the network. But wouldn't you agree that since > you are allocating a node index in every fractured address space > (whether required or not) in option 2, since address space that is > partitioned typically consumes more space than unfractured space (due to > loss because of imperfect planning), as you increase the number of > algorithms aren't you more likely to consume more overall space with > this technique? HG> i might argue that the 'unused' (='fractured') label space is not that i am much worried. what practically matters is what ends up in the forwarding plane. both option 1 and 2 have no difference in that respect. so the significant part here is really does operators want to juggle N indexes for a given node, or just 1 ? > Secondly there was a statement made that there is an advantage to option > 2 that it allows easier provisioning of node index value (as it's > reused) per algorithm. Isn't it just as easy for an implementation to > allow the user to just configure a local implementation offset for an > algorithm which requires no protocol changes and has more flexiblity as > it doesn't need to be configured for prefix SID's that don't require it > (similar as Ahmed suggested at the mic, i.e. algorithm 2 = +1000) that > could be configured at every node? Assuming OSS provisions SID's > sequentially this seems to work just as well... > HG> ahmed has got certainly a possible proposal - the practical downside is that the SRGB may grow big ... given the practical max SRGB boundaries we have seen from many implementations it may not advisable to do this on existing platforms. /hannes From nobody Tue Jul 21 05:51:54 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19871A1C06 for ; Tue, 21 Jul 2015 05:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbOOCZs4BPXn for ; Tue, 21 Jul 2015 05:51:50 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 919D01A1EEA for ; Tue, 21 Jul 2015 05:51:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2814; q=dns/txt; s=iport; t=1437483099; x=1438692699; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=S/DiQLCFEBeQujKGM289ebcC0YfoJILD6UQqrBaHNxQ=; b=CRcQSdQLd2sqwANX1OFIMvedqS6Lwi6ipe05LVN1XW7paqbS0TWr8jx/ Ai/d57DOfxroJNIZRltFaE+l2U+PD5lNe1SgNRPEN3CPOtmBOLYu4VOw7 Qbs2fFwWHknzhli2wxpnspDbvPtLOqUD9gl29en646qQ18Mbc7lq8TtLK 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A9AwCTP65V/4UNJK1cgxNUaQaDHLhsCYFrCoU3SgIcgR44FAEBAQEBAQGBCoQjAQEBBAEBASAROgkCEAIBCA4KAgIfBwICAiULFQcJAgQBDQWILg2zbpZPAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIooqhFMYGweCaIFDBZRTAYwpmQ4mgg0cFYE+b4FHgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,516,1432598400"; d="scan'208";a="11685593" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-7.cisco.com with ESMTP; 21 Jul 2015 12:51:38 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t6LCpcvq009782 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jul 2015 12:51:38 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.37]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 07:51:38 -0500 From: "Acee Lindem (acee)" To: Jon Mitchell , Chris Bowers Thread-Topic: [spring] FW: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt Thread-Index: AQHQw7Gv5gpnAnAjW0GEg6saUlFwIp3mVewA Date: Tue, 21 Jul 2015 12:51:38 +0000 Message-ID: References: <20150624230327.12191.65118.idtracker@ietfa.amsl.com> <20150721123459.GA1274@puck.nether.net> In-Reply-To: <20150721123459.GA1274@puck.nether.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.170.53] 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] FW: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2015 12:51:52 -0000 SSBhZ3JlZSB3aXRoIEpvbuKAmXMgY29tbWVudHMuIFRoZSBvbmx5IHBvc3NpYmxlIGJlbmVmaXQg aXMgdGhhdCBhIGh1bWFuDQpjb3VsZCBhc3NvY2lhdGUgYSBnaXZlbiBTSUQvbGFiZWwgd2l0aCBp dHMgdXNhZ2UuIEhvd2V2ZXIsIHRoYXQgYmVuZWZpdCBpcw0Kb25seSByZWFsaXplZCBpZiBvbmUg aGFzIGNvbnNpc3RlbnQgcGVyIGFsZ29yaXRobS90b3BvbG9neSBTUkdCcw0KdGhyb3VnaG91dCB0 aGUgcm91dGluZyBkb21haW4uDQpUaGFua3MsDQpBY2VlIA0KDQoNCk9uIDcvMjEvMTUsIDI6MzQg UE0sICJzcHJpbmcgb24gYmVoYWxmIG9mIEpvbiBNaXRjaGVsbCINCjxzcHJpbmctYm91bmNlc0Bp ZXRmLm9yZyBvbiBiZWhhbGYgb2YganJtaXRjaGVAcHVjay5uZXRoZXIubmV0PiB3cm90ZToNCg0K Pk9uIDI0LzA2LzE1IDIzOjA5ICswMDAwLCBDaHJpcyBCb3dlcnMgd3JvdGU6DQo+PiBUaGlzIHVw ZGF0ZWQgdmVyc2lvbiBvZiB0aGUgZHJhZnQgaW5jbHVkZXMgYSBjb25jcmV0ZSBwcm9wb3NhbCBm b3IgSVNJUw0KPj5leHRlbnNpb25zIHRvIGltcGxlbWVudCBwZXItYWxnb3JpdGhtIGxhYmVsIGJs b2Nrcy4NCj4+IA0KPg0KPkNocmlzIC0NCj4NCj5BcyB5b3UgZGlzY3Vzc2VkIGluIHRoZSBtZWV0 aW5nIHRvZGF5IGluIG9wdGlvbiAyICh0aGUgcHJvcG9zYWwpIHRoZXJlDQo+aXMgYSAic2F2aW5n cyIgdGhhdCBpcyBhY2hpZXZlZCBieSBub3QgYWxsb2NhdGluZyBhIGxhcmdlIGxhYmVsIHNwYWNl IGFzDQo+aXMgcmVxdWlyZWQgaW4gb3B0aW9uIDEgc2luY2Ugd2UgbWF5IG5vdCBiZSBhYmxlIHRv IHByZWRpY3QgdGhlIGZ1dHVyZQ0KPm9mIGFsZ29yaXRobSBuZWVkcyBpbiB0aGUgbmV0d29yay4g IEJ1dCB3b3VsZG4ndCB5b3UgYWdyZWUgdGhhdCBzaW5jZQ0KPnlvdSBhcmUgYWxsb2NhdGluZyBh IG5vZGUgaW5kZXggaW4gZXZlcnkgZnJhY3R1cmVkIGFkZHJlc3Mgc3BhY2UNCj4od2hldGhlciBy ZXF1aXJlZCBvciBub3QpIGluIG9wdGlvbiAyLCBzaW5jZSBhZGRyZXNzIHNwYWNlIHRoYXQgaXMN Cj5wYXJ0aXRpb25lZCB0eXBpY2FsbHkgY29uc3VtZXMgbW9yZSBzcGFjZSB0aGFuIHVuZnJhY3R1 cmVkIHNwYWNlIChkdWUgdG8NCj5sb3NzIGJlY2F1c2Ugb2YgaW1wZXJmZWN0IHBsYW5uaW5nKSwg YXMgeW91IGluY3JlYXNlIHRoZSBudW1iZXIgb2YNCj5hbGdvcml0aG1zIGFyZW4ndCB5b3UgbW9y ZSBsaWtlbHkgdG8gY29uc3VtZSBtb3JlIG92ZXJhbGwgc3BhY2Ugd2l0aA0KPnRoaXMgdGVjaG5p cXVlPw0KPg0KPlNlY29uZGx5IHRoZXJlIHdhcyBhIHN0YXRlbWVudCBtYWRlIHRoYXQgdGhlcmUg aXMgYW4gYWR2YW50YWdlIHRvIG9wdGlvbg0KPjIgdGhhdCBpdCBhbGxvd3MgZWFzaWVyIHByb3Zp c2lvbmluZyBvZiBub2RlIGluZGV4IHZhbHVlIChhcyBpdCdzDQo+cmV1c2VkKSBwZXIgYWxnb3Jp dGhtLiAgSXNuJ3QgaXQganVzdCBhcyBlYXN5IGZvciBhbiBpbXBsZW1lbnRhdGlvbiB0bw0KPmFs bG93IHRoZSB1c2VyIHRvIGp1c3QgY29uZmlndXJlIGEgbG9jYWwgaW1wbGVtZW50YXRpb24gb2Zm c2V0IGZvciBhbg0KPmFsZ29yaXRobSB3aGljaCByZXF1aXJlcyBubyBwcm90b2NvbCBjaGFuZ2Vz IGFuZCBoYXMgbW9yZSBmbGV4aWJsaXR5IGFzDQo+aXQgZG9lc24ndCBuZWVkIHRvIGJlIGNvbmZp Z3VyZWQgZm9yIHByZWZpeCBTSUQncyB0aGF0IGRvbid0IHJlcXVpcmUgaXQNCj4oc2ltaWxhciBh cyBBaG1lZCBzdWdnZXN0ZWQgYXQgdGhlIG1pYywgaS5lLiBhbGdvcml0aG0gMiA9ICsxMDAwKSB0 aGF0DQo+Y291bGQgYmUgY29uZmlndXJlZCBhdCBldmVyeSBub2RlPyAgQXNzdW1pbmcgT1NTIHBy b3Zpc2lvbnMgU0lEJ3MNCj5zZXF1ZW50aWFsbHkgdGhpcyBzZWVtcyB0byB3b3JrIGp1c3QgYXMg d2VsbC4uLg0KPg0KPlRoYW5rcywNCj4NCj5Kb24NCj4NCj5fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNwcmluZyBtYWlsaW5nIGxpc3QNCj5zcHJpbmdA aWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0K DQo= From nobody Tue Jul 21 06:04:39 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8721A8768 for ; Tue, 21 Jul 2015 06:04:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h_yBqzRf_QQ6 for ; Tue, 21 Jul 2015 06:04:37 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE2E01A9084 for ; Tue, 21 Jul 2015 06:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2163; q=dns/txt; s=iport; t=1437483876; x=1438693476; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=Klu1apTUQV1Rb/kSzcLbic8x7jB4V0mIMQ5PpAMoxDY=; b=ck1p9N+y3VmKmbcxHzdD5odU8OeI3VpSyZbaxdskPWxRL8hrpiuul1kP Qu5b88WCTJ2X5eJ2ffwXbhInGAc9ZXNLfeUa5CUl9r6Wqi63cUbrHfIyT 6KJg4717wXblJKTaQzQaqf5b95vurms4lsixf1v+wohxCe9JCCE8r6uC9 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AdAwDUQq5V/4UNJK1cgxNUaQa8CAmBd4V/AoE8OBQBAQEBAQEBgQqEIwEBAQQ6PQIMBgEIEQQBAR8JORQJCgQOBYguDcpBAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tMhQYNhCUFjDiIGwGEdIc1gUNGg1aPToNhJoI+gT5vgUeBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,516,1432598400"; d="scan'208";a="170729325" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP; 21 Jul 2015 13:04:36 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t6LD4Zk2018921 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jul 2015 13:04:36 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.83]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 08:04:35 -0500 From: "Tarek Saad (tsaad)" To: "cbowers@juniper.net" Thread-Topic: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt Thread-Index: AQHQw7XKhLyQkmAj0k2/DiUQ17d96g== Date: Tue, 21 Jul 2015 13:04:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [10.61.92.141] Content-Type: text/plain; charset="us-ascii" Content-ID: <28BF45EC9E194341B3FCBCD05380F0C1@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2015 13:04:38 -0000 Hi Chris, A possible limitation of advertizing per-alg SRGB is that a node will always assign/maintain as many SRGB-alg labels (on possibly all nodes) for a prefix without being able to control this on per-prefix if needed. Are there are any considerations for this in your proposal? Regards, Tarek -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Wednesday, June 24, 2015 6:03 PM To: Hannes Gredler; Pushpasis Sarkar; Chris Bowers; Chris Bowers; Pushpasis Sarkar; Hannes Gredler Subject: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt A new version of I-D, draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt has been successfully submitted by Chris Bowers and posted to the IETF repository. Name: draft-bowers-spring-adv-per-algorithm-label-blocks Revision: 01 Title: Advertising Per-Algorithm Label Blocks Document date: 2015-06-24 Group: Individual Submission Pages: 7 URL: =20 https://www.ietf.org/internet-drafts/draft-bowers-spring-adv-per-algorithm- label-blocks-01.txt Status: =20 https://datatracker.ietf.org/doc/draft-bowers-spring-adv-per-algorithm-labe l-blocks/ Htmlized: =20 https://tools.ietf.org/html/draft-bowers-spring-adv-per-algorithm-label-blo cks-01 Diff: =20 https://www.ietf.org/rfcdiff?url2=3Ddraft-bowers-spring-adv-per-algorithm-l= ab el-blocks-01 Abstract: Segment routing uses globally-known labels to accomplish destination- based forwarding along shortest paths computed using Dijkstra's algorithm with IGP metrics. This draft discusses how to use segment routing to accomplish destination-based forwarding along paths computed using other algorithms and metrics. In particular, the draft contrasts two different options for associating labels with different algorithms for computing forwarding next-hops. =20 =20 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Tue Jul 21 07:52:30 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320901B2EA8 for ; Tue, 21 Jul 2015 07:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKlX6Ea4fsd0 for ; Tue, 21 Jul 2015 07:52: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 D7B0F1A8904 for ; Tue, 21 Jul 2015 07:52:25 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id 2CDE73B413E; Tue, 21 Jul 2015 16:52:24 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.57]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 0AECA238048; Tue, 21 Jul 2015 16:52:24 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0235.001; Tue, 21 Jul 2015 16:52:23 +0200 From: To: Jon Mitchell , Chris Bowers Thread-Topic: [spring] FW: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt Thread-Index: AQHQrtH+T8w+upycBUSaTkC+rUFxE528R1nwgCmczICAAEbuEA== Date: Tue, 21 Jul 2015 14:52:22 +0000 Message-ID: <6740_1437490344_55AE5CA8_6740_5026_1_9E32478DFA9976438E7A22F69B08FF92166A3315@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <20150624230327.12191.65118.idtracker@ietfa.amsl.com> <20150721123459.GA1274@puck.nether.net> In-Reply-To: <20150721123459.GA1274@puck.nether.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] 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: 2015.7.21.133615 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] FW: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2015 14:52:29 -0000 Using an offset may be dangerous as if your network growth your algo1 SIDs = may collision with algo2 SIDs because the offset is no more enough ... (you= always need more ...) using an offset is similar to splitting the SRGB in = 2 SRGBs with the limitation of not being able to extend the first part. Opt= ion 2 allows this extension. You may say let's put a very very large SRGB and offset of +20000 ... yes b= ut it's wasting resources ... -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Jon Mitchell Sent: Tuesday, July 21, 2015 14:35 To: Chris Bowers Cc: spring@ietf.org Subject: Re: [spring] FW: New Version Notification for draft-bowers-spring-= adv-per-algorithm-label-blocks-01.txt On 24/06/15 23:09 +0000, Chris Bowers wrote: > This updated version of the draft includes a concrete proposal for ISIS e= xtensions to implement per-algorithm label blocks. >=20 Chris - As you discussed in the meeting today in option 2 (the proposal) there is a= "savings" that is achieved by not allocating a large label space as is req= uired in option 1 since we may not be able to predict the future of algorit= hm needs in the network. But wouldn't you agree that since you are allocat= ing a node index in every fractured address space (whether required or not)= in option 2, since address space that is partitioned typically consumes mo= re space than unfractured space (due to loss because of imperfect planning)= , as you increase the number of algorithms aren't you more likely to consum= e more overall space with this technique? Secondly there was a statement made that there is an advantage to option 2 that it allows easier provisioning of node index value (as it's reused) per algorithm. Isn't it just as easy for an implementation to allo= w the user to just configure a local implementation offset for an algorithm= which requires no protocol changes and has more flexiblity as it doesn't n= eed to be configured for prefix SID's that don't require it (similar as Ahm= ed suggested at the mic, i.e. algorithm 2 =3D +1000) that could be configur= ed at every node? Assuming OSS provisions SID's sequentially this seems to= work just as well... Thanks, Jon _______________________________________________ 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 Tue Jul 21 08:04:52 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8315A1B2E4E for ; Tue, 21 Jul 2015 08:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V1Kf-bmbYKDF for ; Tue, 21 Jul 2015 08:04:47 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14AEB1B2EC8 for ; Tue, 21 Jul 2015 08:04:46 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 692531B86B3; Tue, 21 Jul 2015 17:04:44 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.61]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 41718158052; Tue, 21 Jul 2015 17:04:44 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0235.001; Tue, 21 Jul 2015 17:04:43 +0200 From: To: "Tarek Saad (tsaad)" , "cbowers@juniper.net" Thread-Topic: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt Thread-Index: AQHQw7XKhLyQkmAj0k2/DiUQ17d96p3mA7nw Date: Tue, 21 Jul 2015 15:04:42 +0000 Message-ID: <13379_1437491084_55AE5F8C_13379_2363_1_9E32478DFA9976438E7A22F69B08FF92166A334F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] 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: 2015.7.21.142416 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2015 15:04:49 -0000 Hi Tarek, I think per-prefix granularity is still possible. Advertising a SRGB for a particular algorithm does not mean that all the pr= efixes advertised will be advertised for that particular algorithm. I mean considering you have a network with node A ,B, C, D, each one advert= ising a loopback. You want to run algo 0 between all routers, so each router advertises a SRG= B for algo 0, and loopback address with SID is advertised with Algo 0 also. Now you want to run algo 2 but only A and B requires communication between = each other using algo 2. As C and D may be on the path from A to B, all rou= ters requires supports of algo 2 and a new SRGB is provisioned on all route= rs corresponding to algo 2. But in term of SID advertisement, you may confi= gure only A and B to advertise Algo2 for Loopback address (Algo is encoded = in PrefixSID), so there would be only 2 new MPLS forwarding entries instead= of 4. Does it make sense ? Stephane -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Tarek Saad (tsaa= d) Sent: Tuesday, July 21, 2015 15:05 To: cbowers@juniper.net Cc: spring@ietf.org Subject: Re: [spring] New Version Notification for draft-bowers-spring-adv-= per-algorithm-label-blocks-01.txt Hi Chris, A possible limitation of advertizing per-alg SRGB is that a node will alway= s assign/maintain as many SRGB-alg labels (on possibly all nodes) for a pre= fix without being able to control this on per-prefix if needed. Are there are any considerations for this in your proposal? Regards, Tarek -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Wednesday, June 24, 2015 6:03 PM To: Hannes Gredler; Pushpasis Sarkar; Chris Bowers; Chris Bowers; Pushpasis= Sarkar; Hannes Gredler Subject: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt A new version of I-D, draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt has been successfully submitted by Chris Bowers and posted to the IETF repo= sitory. Name: draft-bowers-spring-adv-per-algorithm-label-blocks Revision: 01 Title: Advertising Per-Algorithm Label Blocks Document date: 2015-06-24 Group: Individual Submission Pages: 7 URL:=20=20=20=20=20=20=20=20=20=20=20=20 https://www.ietf.org/internet-drafts/draft-bowers-spring-adv-per-algorithm- label-blocks-01.txt Status:=20=20=20=20=20=20=20=20=20 https://datatracker.ietf.org/doc/draft-bowers-spring-adv-per-algorithm-labe l-blocks/ Htmlized:=20=20=20=20=20=20=20 https://tools.ietf.org/html/draft-bowers-spring-adv-per-algorithm-label-blo cks-01 Diff:=20=20=20=20=20=20=20=20=20=20=20 https://www.ietf.org/rfcdiff?url2=3Ddraft-bowers-spring-adv-per-algorithm-l= ab el-blocks-01 Abstract: Segment routing uses globally-known labels to accomplish destination- based forwarding along shortest paths computed using Dijkstra's algorithm with IGP metrics. This draft discusses how to use segment routing to accomplish destination-based forwarding along paths computed using other algorithms and metrics. In particular, the draft contrasts two different options for associating labels with different algorithms for computing forwarding next-hops. =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 =20=20=20=20=20=20=20 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat _______________________________________________ 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 Tue Jul 21 13:59:02 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8696C1B3059 for ; Tue, 21 Jul 2015 13:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJyedTbmO74e for ; Tue, 21 Jul 2015 13:58:54 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1C8A1B3057 for ; Tue, 21 Jul 2015 13:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28585; q=dns/txt; s=iport; t=1437512334; x=1438721934; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CjNCgZexQsVXdtdlMkXdrpJJpmfvRDWgqD/vf53oopM=; b=CjMS6TxN5va8Gy+uPiUfnxixs6nGUicCVbYRxJdqULE8iKi4eE+KlWEN t0Ij1dWFtsiQoJ2yVr8fxnnk18DWFNZy1whhpVBp6suCR/+BHOuqSsYNb N7Fs291fTqlawE+Bu0Zh2tLOmrvA8aojAJ1lMGyxwCM06+ohoWRDEJp6/ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AqAwDGsa5V/5tdJa1cGYIvTVRpBrwRCYFrAQmFN0oCgT84FAEBAQEBAQGBCoQjAQEBAwEBAQEqQQkCBQcEAgEIEQQBAQsWAwQHJwsUCAEIAgQBDQUIiB4IDcxRAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSKSoEChCMRASAsAQQHBoMRgRQFlFMBjWyEHI9Og2Emgg0cFYE+b4ENOoEEAQEB X-IronPort-AV: E=Sophos; i="5.15,519,1432598400"; d="scan'208,217"; a="13727628" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 21 Jul 2015 20:58:52 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t6LKwqxL031347 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jul 2015 20:58:53 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.220]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 15:58:52 -0500 From: "Les Ginsberg (ginsberg)" To: "stephane.litkowski@orange.com" , "Jon Mitchell" , Chris Bowers Thread-Topic: [spring] FW: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt Thread-Index: AQHQrtH+T8w+upycBUSaTkC+rUFxE528R1nwgCoSJICAACZjAIAABxmQ Date: Tue, 21 Jul 2015 20:58:51 +0000 Message-ID: References: <20150624230327.12191.65118.idtracker@ietfa.amsl.com> <20150721123459.GA1274@puck.nether.net> <6740_1437490344_55AE5CA8_6740_5026_1_9E32478DFA9976438E7A22F69B08FF92166A3315@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <6740_1437490344_55AE5CA8_6740_5026_1_9E32478DFA9976438E7A22F69B08FF92166A3315@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.52.132] Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F5949CF45xmbalnx02ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] FW: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2015 20:59:00 -0000 --_000_F3ADE4747C9E124B89F0ED2180CC814F5949CF45xmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stephane/Chris - Defining an offset, whether explicitly as Ahmed/Jon have suggested or impli= citly as the draft Option #2 defines can be problematic in either case. If you don't plan for as many labels as you might need in the future then w= hen the day comes when you run out of labels you need to allocate more. If I use one SRGB for all algorithms, then I have the (non-disruptive) opti= ons of: * Extending the existing SRGB space * Reserving an additional SRGB space If I use one SRGB for each algorithm, then if I run out of labels/algorithm= I have the same options - but now I have to do this for each algorithm spe= cific set of SRGBs. (There are disruptive ways to address this by completely redefining the SRG= Bs w/o regard to the existing config - but I think we all understand that t= his option is very undesirable and this is true in both options.) Of course it is better to be generous enough with your initial SRGB allocat= ion so as to avoid the need for ever having to extend an SRGB - in which ca= se the amount of label space you need to reserve initially is the same in b= oth cases. (Sorry - no free lunch!! :) ) Option #1 however avoids a number of issues which complicate Option #2: Under Option #2 support for a new algorithm now requires not only advertisi= ng support for the algorithm but also advertising a new (set of) algorithm = specific SRGB ranges. We have to check for the presence of both algorithm s= upport and the algorithm specific SRGB(s) before declaring a node as suppor= ting a given algorithm. Each of these algorithm specific set of ranges has = to be checked for both intra-algorithm consistency (no overlap within the a= lgorithm specific ranges) and inter-algorithm consistency. I would also suggest that for many implementations, any reservation of labe= l space AFTER startup can be problematic. Label space is typically managed = by declaring two types of ranges: 1)reserved for a specific use (like segment routing) 2)available for dynamic allocation (unreserved) The unreserved space is typically everything that isn't reserved. If I need= to reserve additional space after startup I face the possibility that some= of the additional range I would like to reserve may be in use via dynamic = allocation. In such a case I cannot successfully reserve the range until al= l the existing dynamic allocations are released - which can be awkward to d= o and may very well be disruptive to the entity using the dynamically alloc= ated labels. So this is best avoided. I understand why making config easier for the user is desirable - and Optio= n #2 provides that - but it is also easy to do so using Option #1. One can = imagine a syntax similar to: algorithm offset And, as described above, this does not require us to reserve more labels th= an we would need under Option #2. I am not seeing any advantage to Option #2. Though it is well motivated, ev= erything you want to achieve w Option #2 can easily be achieved using Optio= n #1. Les > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of > stephane.litkowski@orange.com > Sent: Tuesday, July 21, 2015 7:52 AM > To: Jon Mitchell; Chris Bowers > Cc: spring@ietf.org > Subject: Re: [spring] FW: New Version Notification for draft-bowers-sprin= g- > adv-per-algorithm-label-blocks-01.txt > > Using an offset may be dangerous as if your network growth your algo1 SID= s > may collision with algo2 SIDs because the offset is no more enough ... (y= ou > always need more ...) using an offset is similar to splitting the SRGB in= 2 > SRGBs with the limitation of not being able to extend the first part. Opt= ion 2 > allows this extension. > You may say let's put a very very large SRGB and offset of +20000 ... yes= but > it's wasting resources ... > > > > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Jon Mitchell > Sent: Tuesday, July 21, 2015 14:35 > To: Chris Bowers > Cc: spring@ietf.org > Subject: Re: [spring] FW: New Version Notification for draft-bowers-sprin= g- > adv-per-algorithm-label-blocks-01.txt > > On 24/06/15 23:09 +0000, Chris Bowers wrote: > > This updated version of the draft includes a concrete proposal for ISIS > extensions to implement per-algorithm label blocks. > > > > Chris - > > As you discussed in the meeting today in option 2 (the proposal) there is= a > "savings" that is achieved by not allocating a large label space as is re= quired in > option 1 since we may not be able to predict the future of algorithm need= s in > the network. But wouldn't you agree that since you are allocating a node > index in every fractured address space (whether required or not) in optio= n 2, > since address space that is partitioned typically consumes more space tha= n > unfractured space (due to loss because of imperfect planning), as you > increase the number of algorithms aren't you more likely to consume more > overall space with this technique? > > Secondly there was a statement made that there is an advantage to option > 2 that it allows easier provisioning of node index value (as it's > reused) per algorithm. Isn't it just as easy for an implementation to al= low the > user to just configure a local implementation offset for an algorithm whi= ch > requires no protocol changes and has more flexiblity as it doesn't need t= o be > configured for prefix SID's that don't require it (similar as Ahmed sugge= sted > at the mic, i.e. algorithm 2 =3D +1000) that could be configured at every= node? > Assuming OSS provisions SID's sequentially this seems to work just as wel= l... > > Thanks, > > Jon > > _______________________________________________ > 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, 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. > > 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 bee= n > modified, changed or falsified. > Thank you. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --_000_F3ADE4747C9E124B89F0ED2180CC814F5949CF45xmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stephane/Chris -

 

Defining an offset, whether explicitly as Ahmed/J= on have suggested or implicitly as the draft Option #2 defines can be probl= ematic in either case.

 

If you don't plan for as many labels as you might= need in the future then when the day comes when you run out of labels you = need to allocate more.

 

If I use one SRGB for all algorithms, then I have= the (non-disruptive) options of:

 

·         Extending the existing SRGB space=

·         Reserving an additional SRGB space

 

If I use one SRGB for each algorithm, then if I r= un out of labels/algorithm I have the same options – but now I have t= o do this for each algorithm specific set of SRGBs.

 

(There are disruptive ways to address this by com= pletely redefining the SRGBs w/o regard to the existing config – but = I think we all understand that this option is very undesirable and this is = true in both options.)

 

Of course it is better to be generous enough with= your initial SRGB allocation so as to avoid the need for ever having to ex= tend an SRGB – in which case the amount of label space you need to re= serve initially is the same in both cases.

(Sorry – no free lunch!! J )

 

Option #1 however avoids a number of issues which= complicate Option #2:

 

Under Option #2 support for a new algorithm now r= equires not only advertising support for the algorithm but also advertising= a new (set of) algorithm specific SRGB ranges. We have to check for the pr= esence of both algorithm support and the algorithm specific SRGB(s) before declaring a node as supporting a giv= en algorithm. Each of these algorithm specific set of ranges has to be chec= ked for both intra-algorithm consistency (no overlap within the algorithm s= pecific ranges) and inter-algorithm consistency.

 

I would also suggest that for many implementation= s, any reservation of label space AFTER startup can be problematic. Label s= pace is typically managed by declaring two types of ranges:

 

1)reserved for a specific use (like segment routi= ng)

2)available for dynamic allocation (unreserved)

 

The unreserved space is typically everything that= isn’t reserved. If I need to reserve additional space after startup = I face the possibility that some of the additional range I would like to re= serve may be in use via dynamic allocation. In such a case I cannot successfully reserve the range until all the exist= ing dynamic allocations are released – which can be awkward to do and= may very well be disruptive to the entity using the dynamically allocated = labels. So this is best avoided.

 

I understand why making config easier for the use= r is desirable – and Option #2 provides that – but it is also e= asy to do so using Option #1. One can imagine a syntax similar to:

 

   algorithm <n> offset <x>=

And, as described above, this does not require us= to reserve more labels than we would need under Option #2.

I am not seeing any advantage to Option #2. Thoug= h it is well motivated, everything you want to achieve w Option #2 can easi= ly be achieved using Option #1.

 

  Les

 

> -----Original Message-----

> From: spring [mailto:spring-bounces@ietf.org= ] On Behalf Of

> stephane.litkowski@orange.com

> Sent: Tuesday, July 21, 2015 7:52 AM

> To: Jon Mitchell; Chris Bowers

> Cc: spring@ietf.org

> Subject: Re: [spring] FW: New Version Notifi= cation for draft-bowers-spring-

> adv-per-algorithm-label-blocks-01.txt

>

> Using an offset may be dangerous as if your = network growth your algo1 SIDs

> may collision with algo2 SIDs because the of= fset is no more enough ... (you

> always need more ...) using an offset is sim= ilar to splitting the SRGB in 2

> SRGBs with the limitation of not being able = to extend the first part. Option 2

> allows this extension.

> You may say let's put a very very large SRGB= and offset of +20000 ... yes but

> it's wasting resources ...

>

>

>

> -----Original Message-----

> From: spring [mailto:s= pring-bounces@ietf.org] On Behalf Of Jon Mitchell

> Sent: Tuesday, July 21, 2015 14:35

> To: Chris Bowers

> Cc: spring@ietf.org=

> Subject: Re: [spring] FW: New Version Notifi= cation for draft-bowers-spring-

> adv-per-algorithm-label-blocks-01.txt

>

> On 24/06/15 23:09 +0000, Chris Bowers wr= ote:

> > This updated version of the draft inclu= des a concrete proposal for ISIS

> extensions to implement per-algorithm label = blocks.

> >

>

> Chris -

>

> As you discussed in the meeting today in opt= ion 2 (the proposal) there is a

> "savings" that is achieved by not = allocating a large label space as is required in

> option 1 since we may not be able to predict= the future of algorithm needs in

> the network.  But wouldn't you agree th= at since you are allocating a node

> index in every fractured address space (whet= her required or not) in option 2,

> since address space that is partitioned typi= cally consumes more space than

> unfractured space (due to loss because of im= perfect planning), as you

> increase the number of algorithms aren't you= more likely to consume more

> overall space with this technique?

>

> Secondly there was a statement made that the= re is an advantage to option

> 2 that it allows easier provisioning of node= index value (as it's

> reused) per algorithm.  Isn't it just a= s easy for an implementation to allow the

> user to just configure a local implementatio= n offset for an algorithm which

> requires no protocol changes and has more fl= exiblity as it doesn't need to be

> configured for prefix SID's that don't requi= re it (similar as Ahmed suggested

> at the mic, i.e. algorithm 2 =3D +1000) = that could be configured at every node?

> Assuming OSS provisions SID's sequentially t= his seems to work just as well...

>

> Thanks,

>

> Jon

>

> ____________________________________________= ___

> spring mailing list

> spring@ietf.org

> https://www.ietf.org/= mailman/listinfo/spring

>

> ____________________________________________= ______________

> ____________________________________________= ______________

> _____

>

> Ce message et ses pieces jointes peuvent con= tenir des informations

> confidentielles ou privilegiees et ne doiven= t 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 ai= nsi que les pieces jointes. Les

> messages electroniques etant susceptibles d'= alteration, Orange decline toute

> responsabilite si ce message a ete altere, d= eforme ou falsifie. Merci.

>

> This message and its attachments may contain= confidential or privileged

> information that may be protected by law; th= ey should not be distributed,

> used or copied without authorisation.

> If you have received this email in error, pl= ease notify the sender and delete

> this message and its attachments.

> As emails may be altered, Orange is not liab= le 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_F3ADE4747C9E124B89F0ED2180CC814F5949CF45xmbalnx02ciscoc_-- From nobody Tue Jul 21 14:44:54 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863FD1B30D9 for ; Tue, 21 Jul 2015 14:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpEx7pPENHlC for ; Tue, 21 Jul 2015 14:44:50 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C53D1B30D7 for ; Tue, 21 Jul 2015 14:44:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5611; q=dns/txt; s=iport; t=1437515090; x=1438724690; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=bqQnhr862rt7n78c2X0yYiWw6R9NPTLuRoMzJt64JrI=; b=A7oj6CH1H1KY/JfIFOa0eeO+NOIoMLEScCNVbDacRmTQMeS4gyZP2M4G 9yvPo8KBYzV9E1p5BcM4uZ863uD7jQaLf5lpIpdsKC6I4N9jvhZDeAepI qpk3opC7vrLt9iKzrQYqnW0qNIn6eW8P+naB/Jypze5uhyw2HIw5T0Rzv 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AoAwB1vK5V/4UNJK1cGYJ8VGkGvBEJgWsMhTVKAoFDOBQBAQEBAQEBgQqEIwEBAQQBAQFrCQIMBAIBCBEEAQEoBycLFAkIAgQBDQWILg3MTwEBAQEBAQEBAQEBAQEBAQEBAQEBAReLTIQjEQEeMwcGhCUBBIw4OIdjAYR0hzWBQ0aDVo9Og2Emgg0cFYE+b4ENOoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,519,1432598400"; d="scan'208";a="171001634" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP; 21 Jul 2015 21:44:49 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t6LLinEb025442 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 Jul 2015 21:44:49 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.83]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Tue, 21 Jul 2015 16:44:49 -0500 From: "Tarek Saad (tsaad)" To: "stephane.litkowski@orange.com" , "cbowers@juniper.net" Thread-Topic: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt Thread-Index: AQHQw7XKhLyQkmAj0k2/DiUQ17d96p3mA7nwgADnIYA= Date: Tue, 21 Jul 2015 21:44:48 +0000 Message-ID: References: <13379_1437491084_55AE5F8C_13379_2363_1_9E32478DFA9976438E7A22F69B08FF92166A334F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <13379_1437491084_55AE5F8C_13379_2363_1_9E32478DFA9976438E7A22F69B08FF92166A334F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [10.61.207.165] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <99786A1221406B479BCE9A6452E75FD8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 21 Jul 2015 21:44:52 -0000 Hi, On 2015-07-21, 5:04 PM, "stephane.litkowski@orange.com" wrote: >Hi Tarek, > >I think per-prefix granularity is still possible. >Advertising a SRGB for a particular algorithm does not mean that all the >prefixes advertised will be advertised for that particular algorithm. > >I mean considering you have a network with node A ,B, C, D, each one >advertising a loopback. >You want to run algo 0 between all routers, so each router advertises a >SRGB for algo 0, and loopback address with SID is advertised with Algo 0 >also. >Now you want to run algo 2 but only A and B requires communication >between each other using algo 2. As C and D may be on the path from A to >B, all routers requires supports of algo 2 and a new SRGB is provisioned [TS]: Yes, if a prefix is to be reachable via alg 2, it=B9s understandable every other node a will allocate/program label for alg2. >on all routers corresponding to algo 2. But in term of SID advertisement, >you may configure only A and B to advertise Algo2 for Loopback address >(Algo is encoded in PrefixSID), so there would be only 2 new MPLS [TS]: quote from draft: "In Option 2 each node advertises a single node index and a unique label block for each algorithm. " 1) it is not clear (from proposal) if alg support is to be explicitly enabled per prefix, and how? If it is to be explicitly enabled per alg2 for a prefix/loopback, wouldn't the overhead be comparable to configuring an index per algorithm? 2) also, not clear how a node announces support for multiple algs for same SID index value. Is multiple prefix-SID sub-TLVs announced with same SID index and for every algorithm it supports? If so, wondering how would a node withdraw support for a specific alg? Regards, Tarek >forwarding entries instead of 4. > >Does it make sense ? > >Stephane > > >-----Original Message----- >From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Tarek Saad >(tsaad) >Sent: Tuesday, July 21, 2015 15:05 >To: cbowers@juniper.net >Cc: spring@ietf.org >Subject: Re: [spring] New Version Notification for >draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt > >Hi Chris, > >A possible limitation of advertizing per-alg SRGB is that a node will >always assign/maintain as many SRGB-alg labels (on possibly all nodes) >for a prefix without being able to control this on per-prefix if needed. >Are there are any considerations for this in your proposal? > >Regards, >Tarek > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Wednesday, June 24, 2015 6:03 PM >To: Hannes Gredler; Pushpasis Sarkar; Chris Bowers; Chris Bowers; >Pushpasis Sarkar; Hannes Gredler >Subject: New Version Notification for >draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt > > >A new version of I-D, >draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt >has been successfully submitted by Chris Bowers and posted to the IETF >repository. > >Name: draft-bowers-spring-adv-per-algorithm-label-blocks >Revision: 01 >Title: Advertising Per-Algorithm Label Blocks >Document date: 2015-06-24 >Group: Individual Submission >Pages: 7 >URL: =20 >https://www.ietf.org/internet-drafts/draft-bowers-spring-adv-per-algorithm >- >label-blocks-01.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-bowers-spring-adv-per-algorithm-lab >e >l-blocks/ >Htmlized: =20 >https://tools.ietf.org/html/draft-bowers-spring-adv-per-algorithm-label-bl >o >cks-01 >Diff: =20 >https://www.ietf.org/rfcdiff?url2=3Ddraft-bowers-spring-adv-per-algorithm-= la >b >el-blocks-01 > >Abstract: > Segment routing uses globally-known labels to accomplish destination- > based forwarding along shortest paths computed using Dijkstra's > algorithm with IGP metrics. This draft discusses how to use segment > routing to accomplish destination-based forwarding along paths > computed using other algorithms and metrics. In particular, the > draft contrasts two different options for associating labels with > different algorithms for computing forwarding next-hops. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission until the htmlized version and diff are available at >tools.ietf.org. > >The IETF Secretariat > >_______________________________________________ >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. From nobody Wed Jul 22 01:15:26 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F04921B3020 for ; Wed, 22 Jul 2015 01:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bZCezKXMgC3 for ; Wed, 22 Jul 2015 01:15:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A7F01B29E0 for ; Wed, 22 Jul 2015 01:15:22 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 1B4143B4458; Wed, 22 Jul 2015 10:15:21 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.60]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id BD41438405A; Wed, 22 Jul 2015 10:15:20 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0235.001; Wed, 22 Jul 2015 10:15:20 +0200 From: To: "Tarek Saad (tsaad)" , "cbowers@juniper.net" Thread-Topic: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt Thread-Index: AQHQw7XKhLyQkmAj0k2/DiUQ17d96p3mA7nwgADnIYCAADmFEA== Date: Wed, 22 Jul 2015 08:15:19 +0000 Message-ID: <17034_1437552920_55AF5118_17034_2210_1_9E32478DFA9976438E7A22F69B08FF92166A3730@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <13379_1437491084_55AE5F8C_13379_2363_1_9E32478DFA9976438E7A22F69B08FF92166A334F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] 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: 2015.7.22.75717 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 08:15:25 -0000 Hi Tarek, More inline -----Original Message----- From: Tarek Saad (tsaad) [mailto:tsaad@cisco.com]=20 Sent: Tuesday, July 21, 2015 23:45 To: LITKOWSKI Stephane SCE/IBNF; cbowers@juniper.net Cc: spring@ietf.org Subject: Re: New Version Notification for draft-bowers-spring-adv-per-algor= ithm-label-blocks-01.txt Hi, On 2015-07-21, 5:04 PM, "stephane.litkowski@orange.com" wrote: >Hi Tarek, > >I think per-prefix granularity is still possible. >Advertising a SRGB for a particular algorithm does not mean that all=20 >the prefixes advertised will be advertised for that particular algorithm. > >I mean considering you have a network with node A ,B, C, D, each one=20 >advertising a loopback. >You want to run algo 0 between all routers, so each router advertises a=20 >SRGB for algo 0, and loopback address with SID is advertised with Algo=20 >0 also. >Now you want to run algo 2 but only A and B requires communication=20 >between each other using algo 2. As C and D may be on the path from A=20 >to B, all routers requires supports of algo 2 and a new SRGB is=20 >provisioned [TS]: Yes, if a prefix is to be reachable via alg 2, it=B9s understandable = every other node a will allocate/program label for alg2. >on all routers corresponding to algo 2. But in term of SID=20 >advertisement, you may configure only A and B to advertise Algo2 for=20 >Loopback address (Algo is encoded in PrefixSID), so there would be only=20 >2 new MPLS [TS]: quote from draft: "In Option 2 each node advertises a single node ind= ex and a unique label block for each algorithm. " 1) it is not clear (from proposal) if alg support is to be explicitly enabl= ed per prefix, and how? If it is to be explicitly enabled per alg2 for a pr= efix/loopback, wouldn't the overhead be comparable to configuring an index = per algorithm? [SLI] IMO, it's implementation dependant.Regarding the overhead, IMO, as a = service provider, the overhead is different. The overhead in option#1 is in= managing the unicity of the SID and so a strong requirement of interaction= with the OSS (for example) to retrieve a unique value =3D> so automation i= s harder. Here it's just another CLI command to add which is generic for al= l routers, or at least no requirement to interact with an external system t= o retrieve informations. 2) also, not clear how a node announces support for multiple algs for same = SID index value. Is multiple prefix-SID sub-TLVs announced with same SID in= dex and for every algorithm it supports? If so, wondering how would a node = withdraw support for a specific alg? [SLI] IMO, multiple prefix-SID sub-TLVs are attached to the prefix, one for= each algorithm (algorithm field changes). If you want to withdraw, remove = a subTLV. Regards, Tarek >forwarding entries instead of 4. > >Does it make sense ? > >Stephane > > >-----Original Message----- >From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Tarek Saad >(tsaad) >Sent: Tuesday, July 21, 2015 15:05 >To: cbowers@juniper.net >Cc: spring@ietf.org >Subject: Re: [spring] New Version Notification for=20 >draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt > >Hi Chris, > >A possible limitation of advertizing per-alg SRGB is that a node will=20 >always assign/maintain as many SRGB-alg labels (on possibly all nodes)=20 >for a prefix without being able to control this on per-prefix if needed. >Are there are any considerations for this in your proposal? > >Regards, >Tarek > >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Wednesday, June 24, 2015 6:03 PM >To: Hannes Gredler; Pushpasis Sarkar; Chris Bowers; Chris Bowers;=20 >Pushpasis Sarkar; Hannes Gredler >Subject: New Version Notification for >draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt > > >A new version of I-D, >draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt >has been successfully submitted by Chris Bowers and posted to the IETF=20 >repository. > >Name: draft-bowers-spring-adv-per-algorithm-label-blocks >Revision: 01 >Title: Advertising Per-Algorithm Label Blocks >Document date: 2015-06-24 >Group: Individual Submission >Pages: 7 >URL:=20=20=20=20=20=20=20=20=20=20=20=20 >https://www.ietf.org/internet-drafts/draft-bowers-spring-adv-per-algori >thm >- >label-blocks-01.txt >Status:=20=20=20=20=20=20=20=20=20 >https://datatracker.ietf.org/doc/draft-bowers-spring-adv-per-algorithm- >lab >e >l-blocks/ >Htmlized:=20=20=20=20=20=20=20 >https://tools.ietf.org/html/draft-bowers-spring-adv-per-algorithm-label >-bl >o >cks-01 >Diff:=20=20=20=20=20=20=20=20=20=20=20 >https://www.ietf.org/rfcdiff?url2=3Ddraft-bowers-spring-adv-per-algorithm >-la >b >el-blocks-01 > >Abstract: > Segment routing uses globally-known labels to accomplish destination- > based forwarding along shortest paths computed using Dijkstra's > algorithm with IGP metrics. This draft discusses how to use segment > routing to accomplish destination-based forwarding along paths > computed using other algorithms and metrics. In particular, the > draft contrasts two different options for associating labels with > different algorithms for computing forwarding next-hops. > >=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20 >=20=20=20=20=20=20=20 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >The IETF Secretariat > >_______________________________________________ >spring mailing list >spring@ietf.org >https://www.ietf.org/mailman/listinfo/spring > >_______________________________________________________________________ >___ _______________________________________________ > >Ce message et ses pieces jointes peuvent contenir des informations=20 >confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20 >exploites ou copies sans autorisation. Si vous avez recu ce message par=20 >erreur, veuillez le signaler a l'expediteur et le detruire ainsi que=20 >les pieces jointes. Les messages electroniques etant susceptibles=20 >d'alteration, Orange decline toute responsabilite si ce message a ete=20 >altere, deforme ou falsifie. Merci. > >This message and its attachments may contain confidential or privileged=20 >information that may be protected by law; they should not be=20 >distributed, used or copied without authorisation. >If you have received this email in error, please notify the sender and=20 >delete this message and its attachments. >As emails may be altered, Orange is not liable for messages that have=20 >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. From nobody Wed Jul 22 01:33:30 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3A651ACE8A for ; Wed, 22 Jul 2015 01:33:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mO-9VcJkV_sb for ; Wed, 22 Jul 2015 01:33:14 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B8E1A8A90 for ; Wed, 22 Jul 2015 01:32:51 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 78871374354; Wed, 22 Jul 2015 10:32:49 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.57]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 511E4180073; Wed, 22 Jul 2015 10:32:49 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0235.001; Wed, 22 Jul 2015 10:32:48 +0200 From: To: "Les Ginsberg (ginsberg)" , Jon Mitchell , Chris Bowers Thread-Topic: [spring] FW: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt Thread-Index: AQHQrtH+T8w+upycBUSaTkC+rUFxE528R1nwgCmczICAAEbuEIAARdmAgADevhA= Date: Wed, 22 Jul 2015 08:32:48 +0000 Message-ID: <28855_1437553969_55AF5531_28855_3459_1_9E32478DFA9976438E7A22F69B08FF92166A376C@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <20150624230327.12191.65118.idtracker@ietfa.amsl.com> <20150721123459.GA1274@puck.nether.net> <6740_1437490344_55AE5CA8_6740_5026_1_9E32478DFA9976438E7A22F69B08FF92166A3315@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92166A376COPEXCLILMA4corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.22.75717 Archived-At: Cc: "spring@ietf.org" Subject: Re: [spring] FW: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 08:33:25 -0000 --_000_9E32478DFA9976438E7A22F69B08FF92166A376COPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Les, Inline comments From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Tuesday, July 21, 2015 22:59 To: LITKOWSKI Stephane SCE/IBNF; Jon Mitchell; Chris Bowers Cc: spring@ietf.org Subject: RE: [spring] FW: New Version Notification for draft-bowers-spring-= adv-per-algorithm-label-blocks-01.txt Stephane/Chris - Defining an offset, whether explicitly as Ahmed/Jon have suggested or impli= citly as the draft Option #2 defines can be problematic in either case. [SLI] Option #2 is not really an offset ... even if we can think that it's = similar it's not. Option#1 with offset proposal : consider a SRGB [100-1100] that I split in = two parts administratively to allocate SIDs for two algos. Algo#1 from inde= x 0 to 499, Algo#2 from 500 to 1000. If you have 501 nodes, you will need to allocate a new SRGB and split again= [1101 - 2100]. So you will have some "fragmentation" in your SID allocatio= n scheme for algos while we wanted to pack SIDs for each algo. Algo#1 would= be 0-499 and 1001 - 1500; Algo#2 500-1000, 1501 - 2100. That works for sure, but it requires a good management ... as pointed, I'm = taking about using offset as proposed during the meeting, flat allocation i= s still possible (first come first served). If you don't plan for as many labels as you might need in the future then w= hen the day comes when you run out of labels you need to allocate more. [SLI] Agree , this is true in both cases. If I use one SRGB for all algorithms, then I have the (non-disruptive) opti= ons of: * Extending the existing SRGB space * Reserving an additional SRGB space [SLI] Agree If I use one SRGB for each algorithm, then if I run out of labels/algorithm= I have the same options - but now I have to do this for each algorithm spe= cific set of SRGBs. [SLI] Agree (There are disruptive ways to address this by completely redefining the SRG= Bs w/o regard to the existing config - but I think we all understand that t= his option is very undesirable and this is true in both options.) Of course it is better to be generous enough with your initial SRGB allocat= ion so as to avoid the need for ever having to extend an SRGB - in which ca= se the amount of label space you need to reserve initially is the same in b= oth cases. (Sorry - no free lunch!! :) ) [SLI] Fully agree Option #1 however avoids a number of issues which complicate Option #2: Under Option #2 support for a new algorithm now requires not only advertisi= ng support for the algorithm but also advertising a new (set of) algorithm = specific SRGB ranges. We have to check for the presence of both algorithm s= upport and the algorithm specific SRGB(s) before declaring a node as suppor= ting a given algorithm. Each of these algorithm specific set of ranges has = to be checked for both intra-algorithm consistency (no overlap within the a= lgorithm specific ranges) and inter-algorithm consistency. [SLI] Is it really different from having multiple SRGBs common from all alg= orithm ? you need to check that there is no overlap, so I think that number= of operation to perform are the same. The change is that you need to manage the list of SRGB per algorithm rather= than globally. I would also suggest that for many implementations, any reservation of labe= l space AFTER startup can be problematic. Label space is typically managed = by declaring two types of ranges: 1)reserved for a specific use (like segment routing) 2)available for dynamic allocation (unreserved) The unreserved space is typically everything that isn't reserved. If I need= to reserve additional space after startup I face the possibility that some= of the additional range I would like to reserve may be in use via dynamic = allocation. In such a case I cannot successfully reserve the range until al= l the existing dynamic allocations are released - which can be awkward to d= o and may very well be disruptive to the entity using the dynamically alloc= ated labels. So this is best avoided. [SLI] Fully agree. But both options are affected by this. I understand why making config easier for the user is desirable - and Optio= n #2 provides that - but it is also easy to do so using Option #1. One can = imagine a syntax similar to: algorithm offset [SLI] As pointed at the beginning this does not work as soon as you need an= additional SRGB or you need to bring a bit more intelligence to hide the f= ragmentation in the SID packing per algo. And, as described above, this does not require us to reserve more labels th= an we would need under Option #2. I am not seeing any advantage to Option #2. Though it is well motivated, ev= erything you want to achieve w Option #2 can easily be achieved using Optio= n #1. Les > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of > stephane.litkowski@orange.com > Sent: Tuesday, July 21, 2015 7:52 AM > To: Jon Mitchell; Chris Bowers > Cc: spring@ietf.org > Subject: Re: [spring] FW: New Version Notification for draft-bowers-sprin= g- > adv-per-algorithm-label-blocks-01.txt > > Using an offset may be dangerous as if your network growth your algo1 SIDs > may collision with algo2 SIDs because the offset is no more enough ... (y= ou > always need more ...) using an offset is similar to splitting the SRGB in= 2 > SRGBs with the limitation of not being able to extend the first part. Opt= ion 2 > allows this extension. > You may say let's put a very very large SRGB and offset of +20000 ... yes= but > it's wasting resources ... > > > > -----Original Message----- > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Jon Mitchell > Sent: Tuesday, July 21, 2015 14:35 > To: Chris Bowers > Cc: spring@ietf.org > Subject: Re: [spring] FW: New Version Notification for draft-bowers-sprin= g- > adv-per-algorithm-label-blocks-01.txt > > On 24/06/15 23:09 +0000, Chris Bowers wrote: > > This updated version of the draft includes a concrete proposal for ISIS > extensions to implement per-algorithm label blocks. > > > > Chris - > > As you discussed in the meeting today in option 2 (the proposal) there is= a > "savings" that is achieved by not allocating a large label space as is re= quired in > option 1 since we may not be able to predict the future of algorithm need= s in > the network. But wouldn't you agree that since you are allocating a node > index in every fractured address space (whether required or not) in optio= n 2, > since address space that is partitioned typically consumes more space than > unfractured space (due to loss because of imperfect planning), as you > increase the number of algorithms aren't you more likely to consume more > overall space with this technique? > > Secondly there was a statement made that there is an advantage to option > 2 that it allows easier provisioning of node index value (as it's > reused) per algorithm. Isn't it just as easy for an implementation to al= low the > user to just configure a local implementation offset for an algorithm whi= ch > requires no protocol changes and has more flexiblity as it doesn't need t= o be > configured for prefix SID's that don't require it (similar as Ahmed sugge= sted > at the mic, i.e. algorithm 2 =3D +1000) that could be configured at every= node? > Assuming OSS provisions SID's sequentially this seems to work just as wel= l... > > Thanks, > > Jon > > _______________________________________________ > 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, 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. > > 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. > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_9E32478DFA9976438E7A22F69B08FF92166A376COPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Les,

 

Inline comments

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Tuesday, July 21, 2015 22:59
To: LITKOWSKI Stephane SCE/IBNF; Jon Mitchell; Chris Bowers
Cc: spring@ietf.org
Subject: RE: [spring] FW: New Version Notification for draft-bowers-= spring-adv-per-algorithm-label-blocks-01.txt

 

Stephane/Chris -

 

Defining an offset, whether explicitly as Ahmed/J= on have suggested or implicitly as the draft Option #2 defines can be probl= ematic in either case.

[SLI] Option #2 is = not really an offset … even if we can think that it’s similar i= t’s not.

Option#1 with offse= t proposal : consider a SRGB [100-1100] that I split in two parts administr= atively to allocate SIDs for two algos. Algo#1 from index 0 to 499, Algo#2 = from 500 to 1000.

If you have 501 nod= es, you will need to allocate a new SRGB and split again [1101 – 2100= ]. So you will have some “fragmentation” in your SID allocation= scheme for algos while we wanted to pack SIDs for each algo. Algo#1 would be 0-499 and 1001 – 1500; Algo#2 500-1000, 1501 &= #8211; 2100.

 

That works for sure= , but it requires a good management … as pointed, I’m taking ab= out using offset as proposed during the meeting, flat allocation is still p= ossible (first come first served).

 

 

If you don't plan for as many labels as you might= need in the future then when the day comes when you run out of labels you = need to allocate more.

[SLI] Agree , this = is true in both cases.

 

If I use one SRGB for all algorithms, then I have= the (non-disruptive) options of:

 

·         Extending the existing SRGB space=

·         Reserving an additional SRGB space

 

[SLI] Agree

 

If I use one SRGB for each algorithm, then if I r= un out of labels/algorithm I have the same options – but now I have t= o do this for each algorithm specific set of SRGBs.

[SLI] Agree

 

(There are disruptive ways to address this by com= pletely redefining the SRGBs w/o regard to the existing config – but = I think we all understand that this option is very undesirable and this is = true in both options.)

 

Of course it is better to be generous enough with= your initial SRGB allocation so as to avoid the need for ever having to ex= tend an SRGB – in which case the amount of label space you need to re= serve initially is the same in both cases.

(Sorry – no free lunch!! J )

[SLI] Fully agree

 

Option #1 however avoids a number of issues which= complicate Option #2:

 

Under Option #2 support for a new algorithm now r= equires not only advertising support for the algorithm but also advertising= a new (set of) algorithm specific SRGB ranges. We have to check for the pr= esence of both algorithm support and the algorithm specific SRGB(s) before declaring a node as supporting a giv= en algorithm. Each of these algorithm specific set of ranges has to be chec= ked for both intra-algorithm consistency (no overlap within the algorithm s= pecific ranges) and inter-algorithm consistency.

[SLI] Is it really = different from having multiple SRGBs common from all algorithm ? you need t= o check that there is no overlap, so I think that number of operation to pe= rform are the same.

The change is that = you need to manage the list of SRGB per algorithm rather than globally.

 

I would also suggest that for many implementation= s, any reservation of label space AFTER startup can be problematic. Label s= pace is typically managed by declaring two types of ranges:

 

1)reserved for a specific use (like segment routi= ng)

2)available for dynamic allocation (unreserved)

 

The unreserved space is typically everything that= isn’t reserved. If I need to reserve additional space after startup = I face the possibility that some of the additional range I would like to re= serve may be in use via dynamic allocation. In such a case I cannot successfully reserve the range until all the exist= ing dynamic allocations are released – which can be awkward to do and= may very well be disruptive to the entity using the dynamically allocated = labels. So this is best avoided.

[SLI] Fully agree. = But both options are affected by this.

 

I understand why making config easier for the use= r is desirable – and Option #2 provides that – but it is also e= asy to do so using Option #1. One can imagine a syntax similar to:

 

   algorithm <n> offset <x>=

 

[SLI] As pointed at= the beginning this does not work as soon as you need an additional SRGB or= you need to bring a bit more intelligence to hide the fragmentation in the= SID packing per algo.

 

 

And, as described above, this does not require us= to reserve more labels than we would need under Option #2.

I am not seeing any advantage to Option #2. Thoug= h it is well motivated, everything you want to achieve w Option #2 can easi= ly be achieved using Option #1.

 

  Les

 

> -----Original Message-----

> From: spring [mailto:spring-bounces@ietf.org] On Behalf Of

> stephane.litkowski@orange.com

> Sent: Tuesday, July 21, 2015 7:52 AM

> To: Jon Mitchell; Chris Bowers

> Cc: sprin= g@ietf.org

> Subject: Re: [spring] FW: New Version Notifi= cation for draft-bowers-spring-

> adv-per-algorithm-label-blocks-01.txt

>

> Using an offset may be dangerous as if your = network growth your algo1 SIDs

> may collision with algo2 SIDs because the of= fset is no more enough ... (you

> always need more ...) using an offset is sim= ilar to splitting the SRGB in 2

> SRGBs with the limitation of not being able = to extend the first part. Option 2

> allows this extension.

> You may say let's put a very very large SRGB= and offset of +20000 ... yes but

> it's wasting resources ...

>

>

>

> -----Original Message-----

> From: spring [mailto:s= pring-bounces@ietf.org] On Behalf Of Jon Mitchell

> Sent: Tuesday, July 21, 2015 14:35

> To: Chris Bowers

> Cc: spring@ietf.org=

> Subject: Re: [spring] FW: New Version Notifi= cation for draft-bowers-spring-

> adv-per-algorithm-label-blocks-01.txt

>

> On 24/06/15 23:09 +0000, Chris Bowers wr= ote:

> > This updated version of the draft inclu= des a concrete proposal for ISIS

> extensions to implement per-algorithm label = blocks.

> >

>

> Chris -

>

> As you discussed in the meeting today in opt= ion 2 (the proposal) there is a

> "savings" that is achieved by not = allocating a large label space as is required in

> option 1 since we may not be able to predict= the future of algorithm needs in

> the network.  But wouldn't you agree th= at since you are allocating a node

> index in every fractured address space (whet= her required or not) in option 2,

> since address space that is partitioned typi= cally consumes more space than

> unfractured space (due to loss because of im= perfect planning), as you

> increase the number of algorithms aren't you= more likely to consume more

> overall space with this technique?

>

> Secondly there was a statement made that the= re is an advantage to option

> 2 that it allows easier provisioning of node= index value (as it's

> reused) per algorithm.  Isn't it just a= s easy for an implementation to allow the

> user to just configure a local implementatio= n offset for an algorithm which

> requires no protocol changes and has more fl= exiblity as it doesn't need to be

> configured for prefix SID's that don't requi= re it (similar as Ahmed suggested

> at the mic, i.e. algorithm 2 =3D +1000) = that could be configured at every node?

> Assuming OSS provisions SID's sequentially t= his seems to work just as well...

>

> Thanks,

>

> Jon

>

> ____________________________________________= ___

> spring mailing list

> spring@ietf.org

> https://www.ietf.org/= mailman/listinfo/spring

>

> ____________________________________________= ______________

> ____________________________________________= ______________

> _____

>

> Ce message et ses pieces jointes peuvent con= tenir des informations

> confidentielles ou privilegiees et ne doiven= t 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 ai= nsi que les pieces jointes. Les

> messages electroniques etant susceptibles d'= alteration, Orange decline toute

> responsabilite si ce message a ete altere, d= eforme ou falsifie. Merci.

>

> This message and its attachments may contain= confidential or privileged

> information that may be protected by law; th= ey should not be distributed,

> used or copied without authorisation.

> If you have received this email in error, pl= ease notify the sender and delete

> this message and its attachments.=

> As emails may be altered, Orange is not liab= le 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. 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_9E32478DFA9976438E7A22F69B08FF92166A376COPEXCLILMA4corp_-- From nobody Wed Jul 22 06:11:29 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602C31A1A97; Wed, 22 Jul 2015 06:11:25 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4KXuFLDOKHA; Wed, 22 Jul 2015 06:11:24 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0112.outbound.protection.outlook.com [207.46.100.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ABCC1B3366; Wed, 22 Jul 2015 06:10:37 -0700 (PDT) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from [172.29.64.169] (193.110.55.14) by CY1PR0501MB1833.namprd05.prod.outlook.com (10.163.141.147) with Microsoft SMTP Server (TLS) id 15.1.219.17; Wed, 22 Jul 2015 13:10:34 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: "John G. Scudder" Date: Wed, 22 Jul 2015 15:10:22 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <0DB3EF53-1A6B-4981-92CF-B969C1847AE0@juniper.net> To: , , , <6man@ietf.org> X-Mailer: Apple Mail (2.2102) X-Originating-IP: [193.110.55.14] X-ClientProxiedBy: DB4PR08CA0040.eurprd08.prod.outlook.com (25.161.12.50) To CY1PR0501MB1833.namprd05.prod.outlook.com (25.163.141.147) X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1833; 2:vEBfQ910GOkMHfkK2rTNMX5wCJv14H8IC6on2EQWRUYCTHP6Oi13zyJIJ8VIdWg6; 3:5hqpBkSMjexJc706kjAeecpO4/hX4tewtWOnZsiuUiabF5u8UYGBjDtgJQKkqWVdtfuiIZEOuqsOWgHrgZFtgG56kpjRHL2WmCcFZtewZNlixQZJRDr2kyfDMD/veyrg2WZtTtg7Oi+GMkU4Ni5+2Q==; 25:Qs6je5mFWXCEeoBJx9TzbAaBG1UsOTu0pEXjTgdHZoUu5aZuTvZxnbxPI1XMSNFZa9tFAKDBIcfPKusIJzbnSlGVGJS+CV3AUjuWwWdCFaXMl1kiLyqAHVl4hXivr5YVgO6WJ8ZVFXmeSa8mtgA3RyonUt5DlD6y8KrQI/hKZ5qlnk0rz1PB+W2itgy1QJeUU8jcmb61JFm90X1SCavwiTFl+Cy+xwh4yS6AI+Hkr2eC/fm39e56pSHojlv4s+nBl6qEtWocT6byuRNw3N7lWw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1833; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1833; 20:Jaon4C3cqexolOpObIgy3Jok2tYIuS4MQyvmI1uou/o58VCWgOsutRdfMLiJLEcbilRAlQqGNrVqx6MlLxc4LqKGn1WQHqijxe6wItXmSTiW13OvuhCYFnHI6IJ+iCY7GXbKhiyIQym9kVu/oC6Du/BjdOUSZx+6BRDdXCj6gUmJ2OK3W2ZFxICREo5SOC/LJw0jr/D6B5HZAJyMsLJ96siUF7gXDOyYAZMviNDzfkWmU1vr5Ukhl3qjHvNxGbXqzaPp0tOStt1CSadjzrhDK+VEtHpSWiHVnINdWzy77wTcYZwhef45y8MAbsz5Spjyxap2L6eFLL67SGt8AZaGW4ghrOR4x+ycJQBCBwFzX+GP7SjHccgivPlCdAGYC1ajTxTNcpLLr5DFSb4CA0IYywyWZvNiGMX+UFT8eauk6o3sYNprsRWLLXSMI5ama3heUvioRmAl7tq9BUfq3+Ors13dXlR8sRx5j5BCmk2Tmql4T87ou7aHB9gdjs5Q5Bls; 4:xKPF+/Mi/3eZG1WZHYptCOy0FR6xtGXttosYL4ZgCX+z6SfqDhJK5sp8QuaUy3uWInvTu3VyPPzyDSrYZS3rAu6CKmVhgWJAPmsShKLAFfb0RUKVPeWW9dxeZkA6M5bxjLIPJFXP3sV9VeGSxzn2J+j2H2jcHDb9CeGE1zJSEWOF/BuQLcyPMrnAlPM/Q3f3lKQ7DZPUcWFoD+Db1WKBk278Lp4VpeYfcONKWiUitt7/MTgGqx2BozGvIAPP18DUIhmHP5IaThb0ywrcViadBYZ8XIilp+y5XEbjYTHp7XM= CY1PR0501MB1833: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR0501MB1833; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1833; X-Forefront-PRVS: 0645BEB7AA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(52044002)(164054003)(97756001)(46406003)(86362001)(2201001)(50986999)(450100001)(62966003)(50466002)(230783001)(189998001)(53806999)(23726002)(46102003)(122386002)(5001960100002)(77156002)(77096005)(33656002)(5001770100001)(87976001)(57306001)(43066003)(40100003)(50226001)(83716003)(36756003)(66066001)(229853001)(82746002)(42186005)(47776003)(217873001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1833; H:[172.29.64.169]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB1833; 23:VQD8yT0r7JktEbhgYcQ4yT+ysk3yxqFoxtr56Yx?= =?us-ascii?Q?0SAt4f4X/lP2iNx78d5BbqYsh486fAgS33Kd3SzMWrgJPw5KfzUxAhCYrxbi?= =?us-ascii?Q?xug6m6nd42Zg24C2FeKObSU2QdqUsh1rvzpFGK7PoZjmY1DSRt5KXa0TTbtd?= =?us-ascii?Q?F8msqyfBZfOiaw4ACGE0rjSty6wKVQg0vYiREsMTNmGO51NCpsCMbLRL4QJs?= =?us-ascii?Q?snafx9UcZlgV6TsaYnWuZD89xk2hYWwNY8GYX+3PA/kIaR7RaEST5vOFW+RB?= =?us-ascii?Q?NwO8Cf9+DTQoAee0dlSt1o8Un7uVAT2hljQfVbiokMOS2dkwOq4ChN8h5Kli?= =?us-ascii?Q?rfgc0tnX+8wJsKxdkZgsFWHy1qOm69yqpIGiG3A6YLHxMIPVdTFl0dfWrnoC?= =?us-ascii?Q?3IMMblmfgYN4KC4mv/jxtLvYfjivQRzhuhr8R3e/axOUG3ns0zsLuT0lfFxV?= =?us-ascii?Q?HICNzHMIECd4DoKPUHP1RvuCPvieCztObwlCRe+yYT/YcSQhWJa0xmjgx3Pg?= =?us-ascii?Q?e6aqTdreZbgRfZg8pa9Ugt+LTo0CUpHwu9uQyPG+6UAuJ6z8QuxCHzSiF17B?= =?us-ascii?Q?YtXC6OvkD2AU6EHzYBbCXzNFjIfL2vdxATIBLa1ZYUL4SZGprpHeVh8hhOFJ?= =?us-ascii?Q?rvoLQRiJUEL0NNZO7y8L0S61vAmqosrbXprPfQ4bFeCVaibAoYwiL+eaaQYc?= =?us-ascii?Q?O6RmR6aLpUZp7s/OClmXkMxQu1PZ4msEHKqykt7tDLn7tYswvfVP/t/yuIA1?= =?us-ascii?Q?4iZ8+CMyInyEFs0sw1iFqmy/6Xe3lUUT5OaO5/269lB8B4WVBsDIObd7p1Kt?= =?us-ascii?Q?zxikVDAIO9M2dRL2/v1TgpbYwNWTlkd6RkadGvoL8Eo+kOdCR34RMOp3eCFV?= =?us-ascii?Q?tC44fCy0ylTnGuj/kKNUyrVYd7kJXtBhiVyWTW55wOX7bdCbNrdAq5WPzTgA?= =?us-ascii?Q?TiFzeA5fZMzSZmjWHq4jJFFvsOHAiRqpXCFhsxApthxj6ALKSKEh7CYnNzEH?= =?us-ascii?Q?Q2Ng=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1833; 5:6wSV+lhnWcWReG49eQvUS9j1GYzk82ARev6CppMo4JI/isqyoyg13BfrnT9UDyfkKhwXTGQxOTJzAkUZor0gK/SE70aAV6JjxoPs2EumdToKMQCZXl6r6LvurMaU3pX5NUSURRODfJbhUNAdNPKQAQ==; 24:ZgUqLDcdeRLXHkg3n52OStxOtsXE5pd7xbSXrKgxni06pk3dBd6xKX4NDLvkCWOUOn+IcHb79gHX13qoN/EVBrd1DhbOd5QJf7/HU1b38LU=; 20:fAalboODCIHc22r2VVqOlJZdn/DSztaMyvRpoewZG+kqNDOgTdbjF44S4bd37FbiOGbkPxcUrFnVClSatKtQlg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jul 2015 13:10:34.5221 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1833 Archived-At: Cc: spring@ietf.org Subject: [spring] SPRING WGLC of draft-ietf-spring-segment-routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: spring@ietf.org List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 13:11:25 -0000 Dear IS-IS, OSPF, MPLS, 6MAN Working Groups, As you probably know, SPRING's work relates to your working group, as = follows: - IS-IS & OSPF: the draft defines the basis for your WG doc IGP = extensions (draft-ietf-*-segment-routing-extensions) - MPLS: MPLS is a data plane of SPRING. The SPRING architecture should = not impact the MPLS data plane nor architecture, but does have side = impacts. e.g. OAM, signaling (e.g. entropy label), deeper label stack. - 6MAN: IPv6 is a proposed data plane of SPRING. It would require a new = routing extension header to be defined in 6MAN. (+ security implications = to be studied) Thus, we anticipate you may have an interest in the SPRING architecture = document. We are about to begin our working group last call and will cc = your WGs. This message is to encourage you to review the document and = comment as needed during the WGLC. Owing to the broad cc, out of respect = for people's inbox clutter I suggest you respect the reply-to, which = I've set to the SPRING mailing list, though if you think it's applicable = feel free to add your own WG list.=20 Thanks, --Bruno and John= From nobody Wed Jul 22 06:12:59 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA941B32E9; Wed, 22 Jul 2015 06:12:56 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgiYgidq8DGI; Wed, 22 Jul 2015 06:12:52 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0712.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::712]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C501A1A9E; Wed, 22 Jul 2015 06:12:51 -0700 (PDT) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from [172.29.64.169] (193.110.55.14) by BLUPR0501MB1826.namprd05.prod.outlook.com (10.163.121.149) with Microsoft SMTP Server (TLS) id 15.1.219.17; Wed, 22 Jul 2015 13:12:32 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: "John G. Scudder" Date: Wed, 22 Jul 2015 15:12:16 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <52A3B956-E9BD-4503-9DDD-D40314B93509@juniper.net> To: X-Mailer: Apple Mail (2.2102) X-Originating-IP: [193.110.55.14] X-ClientProxiedBy: HE1PR06CA0036.eurprd06.prod.outlook.com (25.162.181.174) To BLUPR0501MB1826.namprd05.prod.outlook.com (25.163.121.149) X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1826; 2:lEVpK7FMWDoWHKNM5JMBZBF85hKTrq3rM6leS5h8WXShkSa9FeQnZvRkg49+cSxE; 3:X2GeZLV8WbU/bkOrURoP+n9nmd+4d6APVUO1IIWQCwHUh5lPvKDgp8cQk7j42v2R1S/YiIKdUN/dYvQUif08Pnqt789fB6dr/xl0bi9RvXAOtzePigmDS5YW3H66mi2RAOY4G/4xAzO3tfVCi54WpQ==; 25:YCSTR4IVMjG/eBGCCUvPTbIMJjrqKLD0LMxfTZSxSbsDIIQREUgnqRdBW7i1zjsk3QUTxexu39STmbRZE27euwF2Zn4pAN8JU3W3Z3TqXNftAb0FAqkINSWFt+6mBCd8MEtIoQsuEU36m53aa60JFd5ewWJTfAdrZBzEGiAo4Fh7tz3IXb7DSbPVs4bxcJNhagKV2yjCqg2vndYUZg+Dmsd7Kw5+YoJBUxdqOFVJb8JP4f3QCb/ThvOd4X4h/Ptg328Yl8BFD2EcTwPTW7VP8g== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR0501MB1826; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1826; 20:oWBpy4Kl8uwwfI/km2ejBYqZ63FqydlLmlZSiKRvlRuAtswha/m+N4RzNo7XLuOKK1+Pq151m7fhN40SZ+8V1zQt0MH4dR4FOFKAcSVqZB+jJpsij67kV8IZEKTXJcZ0cFkZJvxbndQaSPZ7GZjitUcUEIgMUtyi4Ve26mbddNce7A6dq1dBi/1fygm1mwmi/SIlAkqpJm6w9U5/8bGi+ypfv1e1JACDoP4LIGAC7V7pCSvhUdFU9OHnRrWkwd4o9VGreAM/vpcaGV/ZrK20lSh3h+Nc5m8NuFTooGuk2fTBtlUI7ZpVaXZgiscfJXkOgdbHIzbqCLEZOyCS+0MY9DQNL6hzvQgq44ZVabXxQWrMTajBJlniYZg/+kgT1SbLDB5gIl+A61OWlGQf+3xhfxYRBgn/uNsBUWqaoyDzLcJBwDmQKJY/NBR+ureOJ58kpmB69CUl+zIK2qnPF2mLbbujz/Z3R1ApEs/U7b2vLv0WyUfOPX50A+HgQaWbTXsj; 4:vIB2jjYFiAb2XeZFbI/yCoGsNxRD3GFlB/7Bo6JWSVT/RfmYG3vyfAMMKsSYSaWEB3SVKBVegb3mIdvPeq9kykD7XFccj5vETLud2VzjlamrzV01/yjU2kZoeogDCatcIdbGNBu0ghJZpDoTT1h8FRBbqi2eo3el5xVAZCZ2DMsj5KEvC3T8Dh/Z8cIDJjt+aHa1v6tuIt/BrVqykYTg7zuCpnnk84acErCPPHpqugfczUF0qy8GS562yNLLqK/K7ewv83KBoLLs927BIsN3KV/NUIDYhZDYS1R79MUealI= BLUPR0501MB1826: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR0501MB1826; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB1826; X-Forefront-PRVS: 0645BEB7AA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(40764003)(164054003)(110136002)(46102003)(33656002)(46406003)(5001960100002)(83716003)(77096005)(122386002)(189998001)(50466002)(50986999)(97756001)(53806999)(42186005)(87976001)(450100001)(40100003)(57306001)(230783001)(50226001)(229853001)(47776003)(36756003)(62966003)(23726002)(2351001)(77156002)(43066003)(82746002)(66066001)(86362001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB1826; H:[172.29.64.169]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB1826; 23:6vKpdWNGVgErQwdSYUxxfq0vL6Dr4RX01QHVlGL?= =?us-ascii?Q?clYWQDTSw1GRK4H4g8nsxuW9M7bQJgOjNk5WKanetAz7KrKn2/gw5NuOSxfd?= =?us-ascii?Q?A9sIaMeP/CQsJHZB4ddY4v6WVVmKO7AVKOBliiVV/mqKoSRtROgxT+43frfu?= =?us-ascii?Q?qpSO8h77t6JivX9+apLYMC0iFG76HmIWG50rl3IvZkWDJeJhrm9GEGSjBSHw?= =?us-ascii?Q?WqiuDw+coZ5XIAwL8C6H4NBV/+HOjgFIUgFrZBk5IuqVT43xbtXHHbnYmbtT?= =?us-ascii?Q?IjgQZ+EaSZJ12KOrqE5inbWqOqC/Rmo0x5Dlvw1zg/ErPF2hwYrmIGBVKMYp?= =?us-ascii?Q?r/mcEe9aQUiRdJkZrghSH86UNg/J5hFH3kMNDchmXdAzSa6smg+R7nPtL1VV?= =?us-ascii?Q?xt77V5Fgf4MF7rO4YltVABS6zGTjWQHx8u6kLGX5JdBJ07B+awMrDQ9H8WCx?= =?us-ascii?Q?PaUqgcwCTR2nYWVyruoHFG1u6h6LJ+vzZm58TfOzP1yJRDxxz8kxMF2TlJNu?= =?us-ascii?Q?QMieDijXk661aX0vZWNK6xNPbgwXKkNlAD0NL5Y9wU6qw61QI6W4Oo4K9z8w?= =?us-ascii?Q?RPiM+2Jh+0Yka9bEX6iXe9CY/pAVkrz8erMp1XSBptlqCAeITbHIj7O21NqC?= =?us-ascii?Q?xN2ZG10Uo69GvaFVoIk68e+eOmBDD6yTdGOR0tSDXasvD/WyLi/gxGxKJkLT?= =?us-ascii?Q?0y0Xz2/SEXNxIzdMoHCaxPu+MNxLQBwN4CnnK+9MhmrQ2+eXPt7gmXQXruyo?= =?us-ascii?Q?wEBmmU6NwW5RX4MkUB93+CvWPuUGwpwEiExnjJDpkhHZUSTAPSfMWvqwl3na?= =?us-ascii?Q?YHFqO4VxoSGnp6q+eL/SsCX57BtINu5OpeqekmfDOied0ockqXgnqdXisiiJ?= =?us-ascii?Q?pCljFL/ZOdK9B2JMV+69VnoIGBPilLpgidZKE4jJ3F7ib1rtZ3qAAlRBME1x?= =?us-ascii?Q?V1saDvMbUGLiOQzeh8IZIlKRddV6kiRXDmEzu0l+qcQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB1826; 5:Diy7vPL6pIGzFDA9z+yi7ktPg24DdQHAJfrNL+ZoWbf2S8BBX102tKrTRaIcRAi8TIyqZZuWfrVeuAT4rJ1YyiXtQJi87SAkAQMqi0cvUc7vLkotoxO2pqNEcEjuiKrbRTRSnkaoDzWfI7808fuLpA==; 24:qzJvKNKJSLDObrv/AZWTViB4wJU6ArvSXNz95qm8TjACqjXEloXkyd64Pp1pMaqrixF+Ra/elij+Q/b2Mni+NH1TqtKGa6wnNB6zxVvKM80=; 20:IsQkFxqwVGZ/YMSfgYafxsVqb1DD87qXnFO1WtldwVgh4fMh755zHNVit9WqNGUR/q6ohyxTsrZMYbWAYhutew== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jul 2015 13:12:32.4465 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB1826 Archived-At: Cc: isis@ietf.org, mpls@ietf.org, 6man@ietf.org, ospf@ietf.org Subject: [spring] working group last call for draft-ietf-spring-segment-routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: spring@ietf.org List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 13:12:56 -0000 Dear SPRING WG (and cc MPLS, OSPF, IS-IS, 6MAN, please include SPRING in = replies per the reply-to): As we discussed at the SPRING meeting yesterday, working group last call = has been requested for draft-ietf-spring-segment-routing. Please reply = to the list with your comments, including although not limited to = whether or not you support advancing the document to RFC. Non-authors = are especially encouraged to comment. In consideration of the fact that a number of WG calls are going on = concurrently, we will end the call on August 31, 2015.=20 Authors, please indicate whether you are aware of any relevant IPR and = if so, whether it has been disclosed. (Please do this even if you've = done it before, thanks for your help.) Thanks, --Bruno and John From nobody Wed Jul 22 06:14:26 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEE961A1A25 for ; Wed, 22 Jul 2015 06:14:24 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdstbpvQHi_3 for ; Wed, 22 Jul 2015 06:14:23 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0148.outbound.protection.outlook.com [65.55.169.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC60C1B3365 for ; Wed, 22 Jul 2015 06:14:12 -0700 (PDT) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from [172.29.64.169] (193.110.55.14) by BY2PR0501MB1832.namprd05.prod.outlook.com (10.163.155.15) with Microsoft SMTP Server (TLS) id 15.1.219.17; Wed, 22 Jul 2015 13:14:11 +0000 From: "John G. Scudder" Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <80969761-1128-4D14-A142-BFF4C9CF1998@juniper.net> Date: Wed, 22 Jul 2015 15:13:53 +0200 To: MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) X-Originating-IP: [193.110.55.14] X-ClientProxiedBy: VI1PR04CA0039.eurprd04.prod.outlook.com (25.163.3.49) To BY2PR0501MB1832.namprd05.prod.outlook.com (25.163.155.15) X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1832; 2:HySXsALMX4qVSyYihzIqnq4GLLKCE6/RWID5GCQLQy2gHTUbShVD6RtDbi8UCx8K; 3:aABagnthHtn3xGaUgCqSMJqIYDJyrfwi0fkYegUMyvtCapHinyEGb3Wuey/BHClSlEHtjMpocK6uom0VMrZLKgIniicqJHvd2FlBIIadaRuPhYFAq7QCppxFpMw1evmXCGdKdHzJZqFhBBmpAAYPbg==; 25:G/J8R2ZzBjvu7vX2O9/f1FdilQnMHeNJHXAyG54i3NvTAs6tf87wEAJOGH7nzIL+NYlYpd5FxPD/ys74ij+j6wYu9wIySw7IN7o5DaJzQmjcfPSOMvuT6mLoirY8WSOn9rwfOq3eqCxt+ItFtB/Idd8kiZtkSoAJHa0RDHyKMmDFOeXvb7r8ZikkhfC6mxbNN7WAX/+qpCcTN6qzSXxt/AmMykNJ1VKGXri/yKVVi+K3OcyZRzMXlhGoXhULPQU/87qOgniWn5TJ6DIkxK1Hdw== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0501MB1832; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1832; 20:lTsIw/R3aLHTZxsyKhTfm/qqjPAoVovbJIonpxuRac3bAa98OepJZma1mB9YrQJ/REQIsL1V8CCRQ5yiToYBnbg21AuauRVUaf0XrFElPjoIGnWYeGCe7cD1QU26pI3XaN6OuuQTE/enbeQDbdCk5tEcNiexRbUqnpfJpOojJ0IAWsZ6NOajg+nRrVyW6BibQlS16hlvQxj5mL43oKkXevHaIY4EI8i1l2ziO9obmPDldfepLTKM4ou+F4+FSmWmx+JXsfZXNnVBGRIiSYdpyTw9DhGhsnrJBGKzE28kLd0N44TMfNvK072SQKFvp4b8mzTpOvfhV5MIzl+mkvgOi1KheBMf/b+NZ+mzwS/9baunyQuHRpwYft9ytRJydjN7rojlw2chpOIZUlI6IP5G+dYUDe6ggBNa5SRPoP+YLuT1Ucryz9HPggl5SB4U8w4l4ZcsEjwBvDs4kbat1mePKk+wwgRN8JLfx7yjhP009KJ0MaxYKBEPMbTzKi63MBJh; 4:KBCjAVO0FvYYAiWUYAEXxuWJ9UZmS8muGoxVDt34nCvXQoYL1oFIRhkNJpQ9kPwBNwuaWfV3HWV2w6k4cTSVmu6ok2LEvCGKYsqmNCO1GCVFS+otA0SwVT07R7akczRbdETIIGGHWVZz2X/CQZ3pgoQnnP7D1ckytLVI86KHHiK8DTEyFijaOirhEpwqq3LzLfW3VRzC1jE+wZXdB5RScB2N1xfkc73NVpa6iD5SOrgSwf1riz2ZmeksODjpgZkv59pcCM74cWQ/VOjZCoZPYxs3ddac42g/AFtRomtFE1A= BY2PR0501MB1832: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY2PR0501MB1832; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB1832; X-Forefront-PRVS: 0645BEB7AA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(164054003)(229853001)(66066001)(97756001)(42186005)(107886002)(82746002)(23726002)(189998001)(83716003)(36756003)(110136002)(77156002)(62966003)(33656002)(57306001)(230783001)(86362001)(77096005)(50986999)(5001960100002)(87976001)(47776003)(46102003)(92566002)(122386002)(50226001)(450100001)(50466002)(46406003)(2351001)(40100003)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB1832; H:[172.29.64.169]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1832; 23:nlhLPYHUEfgXDOzshHci+4RHxN6b8Cy5BP0trge1pJ1EH8ocURubHtKI+EVbIsELSoqPn1Q+76znPaWYHYBlFt76R5TnbmgPo7H3mOiaWgv5Tovu7DopX2DhZMKUDIDwYDjS3NLSB65kkACGLh6fQW10nGSrdVIXnltCM+LnVXEtEgCe6ecmqvLKoOP27MiJJVWwFiOkr+6hpRnyqga0n5bFo4OuIT8h2CebzujkoSxPbIv0ArAUwau96O2dgd+Eahosc4porKpPEZDKaWRSbfnWnpZeknDIBW3vwCPmrBxam0pASYhz5Nm5k4DIy4MepRFhf0kmdfM+YNxaXPzTCmIL74G7F/3Soq/QxCNDv/DGlA/HiQMoeS8sKIAuxDnljnxpBhoNWdA9ROsPOwbMVty+0xgUgf9rElttdXPA9CvXxWudh4r6grcCmviH/UeH4mJ/KSihdYXLG9ybzqA9V61PrHc/OJnQKisp5WZAtq163ml8kP/x9F/NN8gqwFUS288d7Hxg69LxqqT4OjrCHzj7DFTh0bRtvBO6eJtLvxoj5jVCYj3TNA3bUEijD5f6o/v6fYZoj5m0QuS0S748FDNCoexLkiCWkGzjRFMp0pje+oIzdsEaFxFemS1KDPacc5BspEBt0IzxMNZiY9/5EwbdGXjMSbXckeVVc1DW3+j9WVpzKK+pFOgE67FxhCkVmwiJvlPRS8GYNl7FyNYc3EmZlwEawyC/nWbg2qCl2uAqPldX8RuRrtOT0f33edeqe11mX4bakCIs0vM6VhKdLggSwH7kAhdRe8sgYfSmrjJlq61DMf6TEVPtJMDAYh8OJaRLGpS15tBxXg4QZlIp8FFuifSNC4/zgzIK7uiOjhfjw0GHEaLXXDH7m/A1goQa0Zf76ki52n275/ZAvBWYH5PhSEupCOOFPqA7WlJk5r95VMnjxaoL6J+HbBbvqRoh X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1832; 5:wcN3+tmXLF+DRaXEE3T8gAIy8AtnUlGTdLkE/bsN3MxayjjNO99hisQgh2zOIOlw012Nj2tIqw86KdB/Vne72DopiqJB2x4TriVxac5O6dS1LK9vAslaYbJZ407KnqdAvF+UHfHAEgzci+ENqwwzrA==; 24:rA6Fe6p9wLQtLTHSRkPph5dCawlbzYLWgKwQViHbOX7/b47eHQxiWgO91cw9cVXg15b7YNvmDdWS2Wb1a09ekIT+04lGY0Gh4YYPUj5aCh8=; 20:dtexZfG81v2R1t1JzAQEO4Qqc+rT++m79ICh3sFDSWz6BUGvnS1oTBv2ixpzxWygV0LWQtEJqFGUevuaHC2kGw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jul 2015 13:14:11.0782 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB1832 Archived-At: Subject: [spring] working group adoption call for draft-geib-spring-oam-usecase X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 13:14:24 -0000 Dear WG, As we discussed at our meeting yesterday, working group adoption has = been requested for draft-geib-spring-oam-usecase. Please reply to the = list with your comments, including although not limited to whether or = not you support adoption. Non-authors are especially encouraged to = comment. In consideration of the fact that a number of WG calls are going on = concurrently, we will end the call on August 31, 2015.=20 Authors, please indicate whether you are aware of any relevant IPR and = if so, whether it has been disclosed. Thanks, --Bruno and John From nobody Wed Jul 22 06:15:23 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21AAE1A1ABE for ; Wed, 22 Jul 2015 06:15:21 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wwZVdJ_XJg5G for ; Wed, 22 Jul 2015 06:15:20 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0146.outbound.protection.outlook.com [65.55.169.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F831A1AA3 for ; Wed, 22 Jul 2015 06:15:19 -0700 (PDT) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from [172.29.64.169] (193.110.55.14) by BY2PR0501MB1832.namprd05.prod.outlook.com (10.163.155.15) with Microsoft SMTP Server (TLS) id 15.1.219.17; Wed, 22 Jul 2015 13:15:17 +0000 From: John G.Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <4B9BB879-99E2-4A96-A1A6-D05A4EAE9C3D@juniper.net> Date: Wed, 22 Jul 2015 15:15:11 +0200 To: MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) X-Originating-IP: [193.110.55.14] X-ClientProxiedBy: VI1PR04CA0039.eurprd04.prod.outlook.com (25.163.3.49) To BY2PR0501MB1832.namprd05.prod.outlook.com (25.163.155.15) X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1832; 2:dEyQ5o+Lvp3RBNsGknNDyPmNgj/8Kr3nWOBzmsJ6skqiCfDZQmcDX0YaOgYBGmRi; 3:jJzVEWUW+/50AAhTJ5ej3oEDi/LWTKfulZhTkhBoj23TQW4DSmUtH54wl1bH0MkkNDBf/7UxSaQSLIo0SFFvMmgePPW1rMWzX271ThpqCu/+oLZRxHtItJ4oURgYfbKtb7g0YeGJgrCmHfrEiiJYlg==; 25:MJ3BtDeTTlvam9lSDQ8Eq/aUtqsu6J4q3ettHGCBfyqDKXa6gHGMQ2xD9ERqIX5HDdMb8Qam0rMNNS7y9LDOOPodnBUMDuul55kyDniJFOlDKIzY4+qJhjiuI3XmW9tSm3sRWYNzSdpygVwWF9eHzabDZEtxEcE2EoGg8bbLTZtmLuOEdAyKyGSbm8DhukkstpaJQXW1VL/EFRiOlhiGc+l4siTBlikFW9yWHhYkl2iv638IrzUY6hFcRGVgGzaiz7BTMqwvmM6+0wgdtv8oaA== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0501MB1832; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1832; 20:srU+zIeGbENqJm0oo2UfaNPxVPLJW4SY31YNgG/hvGqxRunTii01ZpIlRGPoIYDjgswaBXjATPOziKuVfyZbeRxzCbq9YFb79Ul8+XkV7lrvblyFlRRISwvQymyMmPShltxP4WEdjSDykGyPJtxnk7VgTFFFCpuQQXhv4tqV1byfs5XXMCLT/0pvXvz1srhVCDKIfcTnQorUv8Eh+uA566XDPk1RKs0vosFjlpL78SbiKsCH9J1HGi1xwlC/6ugtxGC94tYNKX+fVp1QfOsIVJWab68RozRCiIpdX8ejNgnZbGluvRTdInaEfHR0Tp1+faRo6kkhkkvg9ujHUFJARiJVC+gLNQ9QXJR64OwMesmjjwDw4BK+Lrg025/ViRZjFcTKn0yNlZWOxrDlzXKZ2RK7O2VNAYohdWkJcc95Kwhr+7cD1wPt57arPWaeil7eE9a5hgFax3UCFbFAMeKuZUwVx8e4zObmdgt2/nAjaKWnnn6IlFO64ZSl5P5HlYxx; 4:Bcdhg0BW12dDpZE7DOKtEpnGfiFNw6M0yoaw4lklefT51/f7L63pC2TGxBEZQclsDqroBjlKSXuORhGcKd1wF2uMpp6PRwGWfaUZVgvDViGrQRnX9wHQkU0LvnOBa6SKt8XyumiYotNZrurvQx0uIWrAdOBwZTPn/N0j6eW2WqqqW759ZAhp1izUpDxQIgOB5Dy/uObT7IAig0aJGlw9HjarqIgDPgKYj221CSbmaIg7A5PC2DSyaojQu37ugPQIT59XLWyRVh0srxxNgwIvqYGxBXzu6sTXZROh72gihPA= BY2PR0501MB1832: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY2PR0501MB1832; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB1832; X-Forefront-PRVS: 0645BEB7AA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(164054003)(229853001)(66066001)(97756001)(42186005)(107886002)(82746002)(23726002)(189998001)(83716003)(36756003)(110136002)(77156002)(62966003)(33656002)(57306001)(230783001)(86362001)(77096005)(50986999)(5001960100002)(87976001)(47776003)(46102003)(92566002)(122386002)(50226001)(450100001)(50466002)(46406003)(2351001)(40100003)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB1832; H:[172.29.64.169]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1832; 23:PC2hu5bZBsIxv3G/pzyAnSuS5MbTJsOxKwoflqg4X1yrkwc+64Ylvua2vfqgi+vH1e8WkqFepVt+Rv9/g0/hM/HZSYLJxN4Y4Smq3dkD6V8I8ERUBiwPUzWRpkJmP046KWN4LZiGxKcOGopRAXdHcZwWegfINAffolq1EuSM6V1vgHfvCZ5GRajL7Sv7GoMlOavHtCjIPhCjfWzbOHsjDDpN/dPuToZdCMp1oBA5+bUhPJoz/BfRp9wo09g+w0tx/vb6DOzSqTKJRP7DyuiZ09E42zIMTcXnk7yX/ah5mmcyk78pMgdqGQwiV4FmFyizGw5/7lRfeBYRCCgUC7LW71ojvw2C/r07hZz2NFPUxejrK+SZY61y2svDZi0o5wFDT9B89v1PQfhjBsSC48fC0qs0BZ+LGnYksxLPcBWsrZbTKMJXfnoS2GVr+KsPxUCZm/coylt7w2bki780DrqunJQ7eZ/2IUz3K6FulBDqTGj1Jf0dw4bM2AiV9gCBr3xUq7DUZ30pNwcV8cMHGd2kvuf5w0zV9ZfJTBipPfV2vMWLLGfOdXrExnKUq+opgSKZTaRLvnKaYl9sJcPfqg34EU0vn4tTCwK3kUQ7+4q3wYUePGWKz5XbC6JtV+V/WZsL4jvLBaXHZHmzZKai5gmcl1tVXMSv5HNK6uG1Kh74SEp535Xut+26gG7j25ydaQTULNyrJGFAycPXXd2IRclIUYfU+qTDdpPncTaDrxVxLvcFUyAm7O4KWj41DUVWJ6HqmdCiCWFF3fvpxbgQYZGW37fm44cmwfEoVi8KHaEJVW/4YhEm2VsSJnjYgMQAvIYbZUOakqXuk2YsaoBhKn1Bl/e5xNB0T0KTinHQlt5vbpotUNmsJ1WXYeF0+uqOKvXD8NX3SHsL/ou6iWJO+I640nCwCFFNZzQvYL4X0hcTD4vBHAJvbQMJL1bVDLwtp3A6 X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1832; 5:5v0hS0M6Sp20D+yiB5FiIf1G31s42am1bAqUeKzhgDBvbbB3csr0nmiPSGsBtd9M3b7M+s+S+rJs6gz4CTSe9fkSXMF8bGVV18nDTxpzs4N/DhRFhzcU1VTQrRoBbA0fkGm8F4twrScD9jBnaUZ00A==; 24:ji0KPAoBTkIyi13ShUEBcnbP6IsIaN7D8OT8Ti/aPQUVP7+COjhGhGC+7zrqS5SpuqOY4WtBV2NovwjOhXia523+886r6DTtaIzFLIaSO08=; 20:IAbxudF1Tq0zWczcUpoVY3FvZ3OzmS5q/KTZE1SkbC7rVn/FAeDyxP+2MFDu+uq+6W4TcKfCal7sJ0NV4orbuQ== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jul 2015 13:15:17.5686 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB1832 Archived-At: Subject: [spring] working group adoption call for draft-filsfils-spring-segment-routing-central-epe X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 13:15:21 -0000 Dear WG, As we discussed at our meeting yesterday, working group adoption has = been requested for draft-filsfils-spring-segment-routing-central-epe. = Please reply to the list with your comments, including although not = limited to whether or not you support adoption. Non-authors are = especially encouraged to comment. In consideration of the fact that a number of WG calls are going on = concurrently, we will end the call on August 31, 2015.=20 Authors, please indicate whether you are aware of any relevant IPR and = if so, whether it has been disclosed. Also, the length of the author = list for this document exceeds the maximum recommended. Assuming the = document is adopted, the authors should be prepared to correct this when = submitting as a WG document, ideally by reducing the list to simply the = active editor(s) and making use of the "contributors" section for the = full list. Thanks, --Bruno and John From nobody Wed Jul 22 06:16:11 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8BE31B335E for ; Wed, 22 Jul 2015 06:16:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GE7ZM4xuXj1E for ; Wed, 22 Jul 2015 06:16:08 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0139.outbound.protection.outlook.com [65.55.169.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDB751B3364 for ; Wed, 22 Jul 2015 06:16:04 -0700 (PDT) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from [172.29.64.169] (193.110.55.14) by BY2PR0501MB1832.namprd05.prod.outlook.com (10.163.155.15) with Microsoft SMTP Server (TLS) id 15.1.219.17; Wed, 22 Jul 2015 13:16:02 +0000 From: John G.Scudder Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message-ID: <36F65DE7-6714-41FB-8A6B-CEB373CAC111@juniper.net> Date: Wed, 22 Jul 2015 15:15:57 +0200 To: MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) X-Mailer: Apple Mail (2.2102) X-Originating-IP: [193.110.55.14] X-ClientProxiedBy: VI1PR04CA0039.eurprd04.prod.outlook.com (25.163.3.49) To BY2PR0501MB1832.namprd05.prod.outlook.com (25.163.155.15) X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1832; 2:mMgWcR26DL6qqMPPVS7qlP4tekTjjWIEV0jchnH3cr9BEviAALG5iYxhF+z+RvrC; 3:ydekDSTTXIwFdDPsD8ABcqErZKnQAV6PuCBLNnGTtwrWBWZf5OL3wcvOgvRjUkhGLNEy72RoQ1FSCbNUs099w98+wDS9fWDdVXV0kAqCkgcPYVNFrC7w3qfwW01yiPk+FlwMETLtIbKenM29/EcYvA==; 25:OJlRybQDIIhiX7jxB7QR6+YLP5QqjFobvo5+A3WDp8jNMvWaLsB39m+LaDWF7w4GUEP/VwJGUa4dcYmzOraCFV4n0EDf8HQl2gdlrNF/4fqotIqTOtBK4zrNlBSwmy5xL7nURZ5V/ytR7IxncH8D67znrm9sGouT1+f60G2Qp6M5gKSHmLhy9Glk0vqog/ttA82F2zEvJMlgau2Wr3bb4+zz+60fVXIJEy2UJscPptUlWv25YA4pDtDj8M8ti0WqtiRCzhrOCmTOKZOgfvvNLg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0501MB1832; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1832; 20:qvYd3m6t+cwgyovMVAS3Ai0pGxgYuHbQznKOwI8i2FVILY0u7/PC95D/L2UK9TZQGXynNiRGxiNHQdvWIcMfg0hxCgr/Dg4V7X2p/j2fxHemLhd5SgiCE6gPDIGymPiSlXE7yGrhKbnsaS08AkWr2S+exbBwNIKYRg7kJ+xY4i7lCO3IF1w6qW7Xq8p6wgrjAbFBfzI1C+XmZaJ9oobNUmnbSf+RpYaVro2RbcFh/X7rZ3ga1d/XvQVgDLIgwr95+sxbbh7s92frV4fykLSRsC9magPdLbO9ut/jJ7WSLvmFc1P1uFpAz039PWyDW73RGQw+UEs3tszAEc1viOUin5zDvWW4oCCFcVmRwk44RxYtFm1OlBfQL6y2rw6RmfjVqsu8J3QnF8kYWyv0Kg5C3fyMuTT+qLqj+LSLemX8ui9pNGcaYFH9q7hSMLZ7k9tHQ0vznsQH28a+UBTB/N5x+hosEQLd8HtrrBBwWcIF9RFkXh8+GQXZLjMHarevPfxP; 4:bsUJxbswWLdh6NMBf7CXI+dWx6sI/euQPBVcWJO//QsPRgV9urV2NF+zwrya+T8ETfRBlGVXg2War6/C1H7Vz8QgFkZwdqkGT8bJtaw1KTP+/aAxRd19psqCbFwZjdCeXcuJXwCh27YLGTJ8A6gavc3XoAtNgjB1bYQuHYbpsEnABMnBLPM2x3B48GOId8Xm4FXEkPWHj2+SfFBp9EKhNP5Aw+qUZw4ZehGw71y46oZesJSLg0BCG4hMum41vNOyBAvuxUyVKysWpxIejV/HzmcZ9UHo1PrVGPKYbAQbiS4= BY2PR0501MB1832: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY2PR0501MB1832; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB1832; X-Forefront-PRVS: 0645BEB7AA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(6049001)(164054003)(229853001)(66066001)(97756001)(42186005)(107886002)(82746002)(23726002)(189998001)(83716003)(36756003)(110136002)(77156002)(62966003)(33656002)(57306001)(230783001)(86362001)(77096005)(50986999)(5001960100002)(87976001)(47776003)(46102003)(92566002)(122386002)(50226001)(450100001)(50466002)(46406003)(2351001)(40100003)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB1832; H:[172.29.64.169]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1832; 23:7dg2vkzBZ4/DWNK2v6wtLn4LSVk/Tw3ClvYP3TyxCDul5au35fluZVoJGIO33gKMploi1Hk0q46E64dhDg2DkufREo8Jx5BoVefKhXm8BDQhscyDdVQMvEthri/Ebpsst9B63+khZbk6RLL/cgHaQiABDk/LmTztB8PMOK3vHBi8DiXo4arn0uqtLQt+08eoI5I8XpAfMHGslNYDmL2G8UtpfHuDfUWE1yyu8VH/LjJ0PtslZLZKnQO+zk+iTDVurog3wG7GMaY/wZqmMKd6S9NZC+leWJ7tfk/6W2F/WQBCVK+D/Cm4EJ/xWkL59UucXgGtPuZ7zepLo/deyiJGdw/zhrYGcGxf5LUuWsZfGS3eZszdoq48kIoqzvOyxnCgH768iJFgkzGASlU0rCrYFNEmjS5Nlj33wyB/wdeYjZGRApykCf57CVdXQ47Tgo9lQ72dHzR2hq6XEWgwvrSZtwRHitZtFXV5nB48q4V5wra+QqeeZRl3gsG0K4Ov5yyDALX51uaCYGvlWdDA0nVHdnWTe2sAMht5ZvCdPuKUbpfr6xVD/oMGAiH8PeKnmE+reFWWd8Sm8v9Wia7TVd47n6po1d/jQito9FFhRXJb4PMrLsV9UZLGJnX40W3gdFgBEmRo57WydmTxoVVivRE13e+q6oFXbdIx9j2+TC1kc+PoKFV8vduoxvWco6MXoGCaTHuWAxfFXQHgdbuNqfBBdmgN7w3TjDAtCZH2XfXOodO234ofAoPUQ0aGj5vkQmu+1OqzIgMEPDcdTVH/Oy+fBpd0YD3fWatVbV0x0oo8/laM7JK3P8CBkjrVi4h4tFYs/k/UDYSsannObbK4fcoZBXb4f6g7oYI0p53mbCoUCjDCL9Ps5uphXR/IunxuhUbxfQsJIppvtCHMUQBvcewyyeUtYBFtspJGieej+kPPl+oVZkCjgyHT+euxlxQrYRsM X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1832; 5:PWt1NpEM5d7wltBPEo3/O4DqHO+gUeXxFID4FK7YgZR93O7wfqr7/zK1mXVFdIEgciM8k+jBbo84z/ZkE7UWgo3AfDbAAUfmae2VGcbVimRkjREQ8XMz4BFaskQO4QTMVDojXUft7qNfeq76jK1B4g==; 24:gJxaOXcUxeulGqGaj3v6Po/4QBIVS9akBpT9KQbggdqbEUolOu8KCHyutt/2lEDsKz+BWaDU+76Zc8aI1rdbjHn+jXj9iM7ywoFRLyFH27c=; 20:HmemPOg0jBgNeZspUURHEwPzya6FjF6uQM9a9JPJElN8/AlSYk6Rgthpks/luLTYsjR1usA1pwShZTOQaQ15Sw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jul 2015 13:16:02.8527 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB1832 Archived-At: Subject: [spring] working group adoption call for draft-filsfils-spring-segment-routing-msdc X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 13:16:09 -0000 Dear WG, As we discussed at our meeting yesterday, working group adoption has = been requested for draft-filsfils-spring-segment-routing-msdc. Please = reply to the list with your comments, including although not limited to = whether or not you support adoption. Non-authors are especially = encouraged to comment. In consideration of the fact that a number of WG calls are going on = concurrently, we will end the call on August 31, 2015.=20 Authors, please indicate whether you are aware of any relevant IPR and = if so, whether it has been disclosed. Also, the length of the author = list for this document greatly exceeds the maximum recommended. Assuming = the document is adopted, the authors should be prepared to correct this = when submitting as a WG document, ideally by reducing the list to simply = the active editor(s) and making use of the "contributors" section for = the full list. Thanks, --Bruno and John From nobody Wed Jul 22 06:17:40 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285361B3355; Wed, 22 Jul 2015 06:17:38 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wbnizEewea61; Wed, 22 Jul 2015 06:17:36 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0132.outbound.protection.outlook.com [65.55.169.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F02631A1ABE; Wed, 22 Jul 2015 06:17:35 -0700 (PDT) Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from [172.29.64.169] (193.110.55.19) by BY2PR0501MB1830.namprd05.prod.outlook.com (10.163.155.148) with Microsoft SMTP Server (TLS) id 15.1.225.19; Wed, 22 Jul 2015 13:17:33 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John G.Scudder Date: Wed, 22 Jul 2015 15:17:18 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> To: X-Mailer: Apple Mail (2.2102) X-Originating-IP: [193.110.55.19] X-ClientProxiedBy: DB3PR01CA0076.eurprd01.prod.exchangelabs.com (10.242.133.179) To BY2PR0501MB1830.namprd05.prod.outlook.com (25.163.155.148) X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1830; 2:jmnu1lcsqSpFewCf2quzLIPdZW7lXil5GjS/WPPy34YbZ4wVnbagcZnCyeuQ/dhxrKw9t9jlgHXw3Z4ILpD4/rCQ7YUt6mCSHDwvTHVYVIumf6SN9A1EztNc4YfZ+kgkSrxvuWzAjg0HHp9sKCxF0pD2WL94uqORrI+vIII0PoI=; 3:IAhM6U+yGI3D74F+As6/QKCDdTSVfHhejzWriTiXRTbWbrN7FRenLzTapxZ8RbGb57ZQxfovTC6r2mNgPm1g826MsfSyF9QFCrtxeVLZYsM4Raz/equYY28qPhckSkVRebI4kXvkCzuTf3Rlbd/xKg==; 25:1RMR3RjyYSwsJj4m+5NLgGgvSNsRdU5bCLU8MwHdvt1FHqF4Zr93h2yZ1ZOAqBm6lmrw1PsmpFKRb6J+1t4wmkLOX6RiARsNidVRAJa5e/LmKweosnIK5wBRbSv1tsqXF8xB6lnTrSeVXDQ6NQWXUoyS/I6bR2ff/GkCh7g+V1MK9NMFuk1N/zq5RPvtku9Bn14LYDYBP1dzfLJmAZdNrDTeGN+e4HfAcKznAlBuYRxrqheWz7RTB7VRheBUAEx1iTGaqzWBKehQmsm6sf+OXg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR0501MB1830; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1830; 20:Xs5BjtUyaR3jZtCj32iy1OKI6feZI+FK/OOPjusOYjMZfLaWL0WUfA46L1zyl6dGjge34clavRElThUn4HNL20S4FG0WpiS7YEZ8O+zC0RvaHynXg/g/aSyaxciJku2L8uhwYSROCBDp2jJUu09Z0rbfDCS3nrr4R26EfcmeWM9iHYBMxZMYiPLWE8U2NjWV5ye7C9xogulcuy3893359P5HZiPNqsUihqq4pF1AX9sNNdhIq1mbkMv8l8Z6kA1wZijIklEiG1rP2VTIhIFt36TUItL7+WnDUhq4a4Mk4K9RMBUvzJTwwJX1xAccPhLGf7FvCUXwpUaIAcMC7vun+gMKGdQJBKFXvHJuybhAE88ra6BczHwikcvXxi812IVNkeMBRkLSVhXgHcTfb6aVZrRNSdFW/zEuMOBi6ajygmHA5VS8ltxxYiRF/IoNZ6WN8sJWiJRtOIcsxCZVD7J4lebtGIoZhCF0IHpS+N2cRvrhHI7LZylpZHHv2iECdtgZ; 4:0+GKrOWUznJ4tf6hr/yRe7TdFgz+HALnghsoyMbB6WLS2zYc3AtKCxgG/HG+UQ2GfeKZtgR/+pM09y85Nr4rr3bp/9n0EPchbdRsMCTVJq7D/iFsfkXX2EuGr9uK6ynQ0eO6gYYUNNX7JLiTV+1pt14tIJLpmM5RXxyHoMXEjZu76HMLBk1KB57CqpeEmcRuCX4MMquMqcsqL4j5eu+TyOrFDPdFV+0GGK8MpW+1Madaziow1Vzb/QsFXvBKmeEc5bCCRy3EP2E2hKkKIrU+welocrxxKhWHJb5rzoN5uzs= BY2PR0501MB1830: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY2PR0501MB1830; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0501MB1830; X-Forefront-PRVS: 0645BEB7AA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(164054003)(50226001)(189998001)(46102003)(50986999)(53806999)(23726002)(50466002)(5001960100002)(36756003)(77156002)(46406003)(86362001)(66066001)(230783001)(122386002)(82746002)(77096005)(97756001)(62966003)(33656002)(47776003)(57306001)(40100003)(83716003)(450100001)(229853001)(110136002)(42186005)(87976001)(43066003)(2351001)(42262002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0501MB1830; H:[172.29.64.169]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1830; 23:bT6Qn8oK5RtXi9if0sZrAwR7o+DHP1k0PzXOJ7B4meZEEf6eVP2moDzPwhqNojWHrqgt6IPbBobgoqps+Upv0PUJkmu8Yotyj73mnM6t+Akj6AgqtidqaOrkuwHTp+r3GUaRIu/PbdT0R77GqBny4QVoz5L83/znd6gUevSJjuQIOZBeKU5RsBuWs+IZPcDHxl9iZvDXbCDUa/1Wqpgi/HXwiqzKLspx9uangCsjN1H+jdRvYSAzSKK8Vq/Cypte0uMyVkqqCt0mdyYFeswFU1NUTWU+OFVUavTaC5/4GHu0Ko+7sUPyutQGZbKtlQ5te/xmYNF08MGq1I6aDnLBXxBaT0EY7AfezxWywaxTtyfp/h1Kz6eyd9QUxT9YPT42fVWup/7/4VUs5pCnzKTTuUkh/aZgXXEQbbwkowNQVPNmQvdpAC76AjE9EmvwFVvIVgoSpyN2qlh4PQPzU90hl+QgCWZWm4qq7LszAvkhCZqPZqe3H8wbSkA2ezM5MIweCd9Zt2qGw+MhCGJL643lQz2ugukyXIxHe35SasVUDh5eqfUh4VhfofcwVfK1LoGQW1uP8FXbr1MtY0LtRwpPRX38ytdxfEx4i3OApYsr2bwpODWJnjv6olfG60yiImItFufMKzzvSV6LikNxIdShanP2tufpco+sLELRoFXkEWthO7WwQE9uElI9k7tm/692IBDbCt1g4vYppmVI7+G2+jC2EaHzJdQS1bFJH9Md0cQKdcVaDvrBx2dbSbE45duFlQYKwCDrNbH6To1rb8p0d0zbV0nP2Psp75HU7rClTU55Hubyd/EBgi9JQNJpkcC6Bn/dQ6gqnaNBoOvIGC97SQfx46jjp95LBJTxs/L4pG2jcQfyCbqaEEx6zq/8jbP0Nz5N629DTViFsguhQLwfiW3z/7JXw1wwbU5sxhSrk5A9hwH9ITXXKappOobPKxp7 X-Microsoft-Exchange-Diagnostics: 1; BY2PR0501MB1830; 5:ki1lF/NwMNJdyql4bqj3F10b5ythgLE1OYr/zdxNUQwDBaAFQsUc5B41vC12Emf3Mw+0tlkDd1mV9GrpOhJ30xs4Ee99xY9bCKmh4NOgvCo/ePz6qPIb0FdP9scHnDvV5rSo5XaDS2vjZ2HaWJjWlg==; 24:xcgfixUREgC6ioN8AhMni6CZQMkGccaG2yHz9hcU6v4GG/RXPtsodfyPi/daiz8xB1sAjOzBrrxT+AUsnVNyB1ql4WbiLNb9jE/+RJb1WNo=; 20:l+WBssIVER3SmW+EvZd7OIttJTWnV+nHnRapGPWXL89/bjXpd2vxo11WxPi7eAushf7QDqtH2shKQztjv19SZA== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jul 2015 13:17:33.6714 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0501MB1830 Archived-At: Cc: mpls@ietf.org Subject: [spring] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: spring@ietf.org List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 13:17:38 -0000 Dear WG, As we discussed at our meeting yesterday, working group adoption has = been requested for draft-filsfils-spring-segment-routing-ldp-interop. = Please reply to the list with your comments, including although not = limited to whether or not you support adoption. Non-authors are = especially encouraged to comment. In consideration of the fact that a number of WG calls are going on = concurrently, we will end the call on August 31, 2015.=20 Authors, please indicate whether you are aware of any relevant IPR and = if so, whether it has been disclosed. Also, the length of the author = list for this document greatly exceeds the maximum recommended. Assuming = the document is adopted, the authors should be prepared to correct this = when submitting as a WG document, ideally by reducing the list to simply = the active editor(s) and making use of the "contributors" section for = the full list. Thanks, --Bruno and John P.S.: Cc MPLS owing to the LDP connection. Please respect the reply-to.= From nobody Wed Jul 22 06:18:19 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEF31A1B43 for ; Wed, 22 Jul 2015 06:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqxP0Ls9bAXq for ; Wed, 22 Jul 2015 06:18:15 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A46391A1AB9 for ; Wed, 22 Jul 2015 06:18:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1808; q=dns/txt; s=iport; t=1437571096; x=1438780696; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=j0IqBXqRkN/fYY1t3vBJyV7dy/+X8GKAtwCMrJWZthY=; b=StsJUhiBUSStnocipWmYgaGEIkVf4dujY+sf8FejFpLYqn8nylkSs4x7 +byImpmGPjBj1KmpLeG1tVBsfQ3daWU69QaEATldUbCfdM+Lne7BL2MTa f2PB15c0hmfNjOYgmH2MvaAC0GR4Q54PW7p40rJX+P53tyeCiqwxgCZ0h U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A4AwCol69V/5RdJa1bgxVUaQaDHbhaCYFrCoU3SgIcgTE4FAEBAQEBAQGBCoQkAQEEAQEBGgYROhsCAQgaAiYCAgIlCxUQAgQBEoguDbZMljgBAQEBAQEBAQEBAQEBAQEBAQEBFQSBIooqhC0mOoJogUMFlFcBjDGBQ4Qdj1GDYSaCPoE+b4EEQ4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,523,1432598400"; d="scan'208";a="17676628" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP; 22 Jul 2015 13:18:15 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t6MDIE9E030227 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 13:18:14 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.37]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 08:18:14 -0500 From: "Acee Lindem (acee)" To: "John G.Scudder" , "spring@ietf.org" Thread-Topic: [spring] working group adoption call for draft-filsfils-spring-segment-routing-msdc Thread-Index: AQHQxICrgbQbRdKzIEaWb2N+Ycd/eJ3n7g8A Date: Wed, 22 Jul 2015 13:18:13 +0000 Message-ID: References: <36F65DE7-6714-41FB-8A6B-CEB373CAC111@juniper.net> In-Reply-To: <36F65DE7-6714-41FB-8A6B-CEB373CAC111@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.210.151] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-msdc X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 13:18:17 -0000 SSBzdXBwb3J0IFdHIGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQgYXMgaXQgaXMgYW4gaW1wb3J0YW50 IHNlZ21lbnQgcm91dGluZw0KdXNlIGNhc2UuIA0KVGhhbmtzLA0KQWNlZSANCg0KT24gNy8yMi8x NSwgMzoxNSBQTSwgInNwcmluZyBvbiBiZWhhbGYgb2YgSm9obiBHLlNjdWRkZXIiDQo8c3ByaW5n LWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGpnc0BqdW5pcGVyLm5ldD4gd3JvdGU6DQoN Cj5EZWFyIFdHLA0KPg0KPkFzIHdlIGRpc2N1c3NlZCBhdCBvdXIgbWVldGluZyB5ZXN0ZXJkYXks IHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gaGFzIGJlZW4NCj5yZXF1ZXN0ZWQgZm9yIGRyYWZ0LWZp bHNmaWxzLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXNkYy4gUGxlYXNlIHJlcGx5IHRvDQo+dGhl IGxpc3Qgd2l0aCB5b3VyIGNvbW1lbnRzLCBpbmNsdWRpbmcgYWx0aG91Z2ggbm90IGxpbWl0ZWQg dG8gd2hldGhlciBvcg0KPm5vdCB5b3Ugc3VwcG9ydCBhZG9wdGlvbi4gTm9uLWF1dGhvcnMgYXJl IGVzcGVjaWFsbHkgZW5jb3VyYWdlZCB0bw0KPmNvbW1lbnQuDQo+DQo+SW4gY29uc2lkZXJhdGlv biBvZiB0aGUgZmFjdCB0aGF0IGEgbnVtYmVyIG9mIFdHIGNhbGxzIGFyZSBnb2luZyBvbg0KPmNv bmN1cnJlbnRseSwgd2Ugd2lsbCBlbmQgdGhlIGNhbGwgb24gQXVndXN0IDMxLCAyMDE1Lg0KPg0K PkF1dGhvcnMsIHBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlvdSBhcmUgYXdhcmUgb2YgYW55IHJl bGV2YW50IElQUiBhbmQgaWYNCj5zbywgd2hldGhlciBpdCBoYXMgYmVlbiBkaXNjbG9zZWQuIEFs c28sIHRoZSBsZW5ndGggb2YgdGhlIGF1dGhvciBsaXN0DQo+Zm9yIHRoaXMgZG9jdW1lbnQgZ3Jl YXRseSBleGNlZWRzIHRoZSBtYXhpbXVtIHJlY29tbWVuZGVkLiBBc3N1bWluZyB0aGUNCj5kb2N1 bWVudCBpcyBhZG9wdGVkLCB0aGUgYXV0aG9ycyBzaG91bGQgYmUgcHJlcGFyZWQgdG8gY29ycmVj dCB0aGlzIHdoZW4NCj5zdWJtaXR0aW5nIGFzIGEgV0cgZG9jdW1lbnQsIGlkZWFsbHkgYnkgcmVk dWNpbmcgdGhlIGxpc3QgdG8gc2ltcGx5IHRoZQ0KPmFjdGl2ZSBlZGl0b3IocykgYW5kIG1ha2lu ZyB1c2Ugb2YgdGhlICJjb250cmlidXRvcnMiIHNlY3Rpb24gZm9yIHRoZQ0KPmZ1bGwgbGlzdC4N Cj4NCj5UaGFua3MsDQo+DQo+LS1CcnVubyBhbmQgSm9obg0KPg0KPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+c3ByaW5nIG1haWxpbmcgbGlzdA0KPnNw cmluZ0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3By aW5nDQoNCg== From nobody Wed Jul 22 06:21:08 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409B41A1A9B; Wed, 22 Jul 2015 06:21:06 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfBM_dKRvgMJ; Wed, 22 Jul 2015 06:21:01 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.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 E84201A1BAC; Wed, 22 Jul 2015 06:21:00 -0700 (PDT) X-AuditID: c6180641-f794d6d000001dfb-f3-55af30b0082a Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 38.23.07675.0B03FA55; Wed, 22 Jul 2015 07:57:04 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0210.002; Wed, 22 Jul 2015 09:20:59 -0400 From: Jeff Tantsura To: "spring@ietf.org" Thread-Topic: [mpls] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop Thread-Index: AQHQxIDNFyTw8hj1XEKyqQkrC6+mwZ3nRy6A Date: Wed, 22 Jul 2015 13:20:58 +0000 Message-ID: References: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> In-Reply-To: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXSPt+4Gg/WhBpt+GVrcWrqS1eL4hd+M DkweS5b8ZApgjOKySUnNySxLLdK3S+DKuHvjJ3vBZJ6KvZ3HWBoYJ3F1MXJwSAiYSKy9UtPF yAlkiklcuLeerYuRi0NI4CijxImWdiYIZzmjRMvXW6wgVWwCBhL/vx1nAWkWEVCXeHY0HMRk FlCWOHVXBqRCWCBdYva/DywgtohAhsTaZx1MELaRxM+Gb2BTWARUJc6uXgFWwytgLtH+bi4j iC0kYCexeEIjM4jNKWAvceDffDCbEei276fWgM1hFhCXuPVkPhPEzQISS/acZ4awRSVePv4H Nl9UQE9i5fUmNoi4ksSc19eYIXp1JBbs/sQGcbK1xLz71RBhbYllC18zQ5wjKHFy5hOWCYwS s5Bsm4WkexZC9ywk3bOQdC9gZF3FyFFanFqWm25kuIkRGFvHJNgcdzAu+GR5iFGAg1GJh3dB x7pQIdbEsuLK3EOM0hwsSuK80n55oUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYm4NdSkq1 FkYdO7BR1itRQs4wecW5qj57dfWLweJbJuesWaa+7cuBfy/37n/fExfhzC1S8bbS5esq7/18 eSuyjfbv3/XJ5YMH474NycU2Z4ukL0hdmmN8IvBGyg3zJ3MzNRumMRbISJcq8agUv++Zs35d 6dmKg9pMsvu3/ml/8NJV790+Fu5SJZbijERDLeai4kQAzDJdRI4CAAA= Archived-At: Cc: "mpls@ietf.org" Subject: Re: [spring] [mpls] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 13:21:06 -0000 Yes/support as co-author Cheers, Jeff -----Original Message----- From: "John G.Scudder" Reply-To: "spring@ietf.org" Date: Wednesday, July 22, 2015 at 6:17 AM To: "spring@ietf.org" Cc: "mpls@ietf.org" Subject: [mpls] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop >Dear WG, > >As we discussed at our meeting yesterday, working group adoption has been >requested for draft-filsfils-spring-segment-routing-ldp-interop. Please >reply to the list with your comments, including although not limited to >whether or not you support adoption. Non-authors are especially >encouraged to comment. > >In consideration of the fact that a number of WG calls are going on >concurrently, we will end the call on August 31, 2015. > >Authors, please indicate whether you are aware of any relevant IPR and if >so, whether it has been disclosed. Also, the length of the author list >for this document greatly exceeds the maximum recommended. Assuming the >document is adopted, the authors should be prepared to correct this when >submitting as a WG document, ideally by reducing the list to simply the >active editor(s) and making use of the "contributors" section for the >full list. > >Thanks, > >--Bruno and John > >P.S.: Cc MPLS owing to the LDP connection. Please respect the reply-to. >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Jul 22 06:21:58 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 025E71A1BAC for ; Wed, 22 Jul 2015 06:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_02UmZHgwys for ; Wed, 22 Jul 2015 06:21:51 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93ADA1A1A9B for ; Wed, 22 Jul 2015 06:21:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1832; q=dns/txt; s=iport; t=1437571311; x=1438780911; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=JHX7pD+1k0zB+4ByuuthSXCit6qRPuZVZtQlq2sGErc=; b=YXvw7KmvzQK8u58DijbLuoN350KVI3zrWX3FK3V7FC1WDb8adb50jugX G7vLHOt/7cDt2X+xxIhr/6cpJfxnIz2rTSlRuyJAkkQfwT/cLYXcxHH21 GttOm88YzfjPgFyvZLtFPeo9djRXk+3lntMFb4qrofzuhpx0SotK9Lhkd s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A4AwCol69V/5FdJa1bgxVUaQaDHbhaCYFrCoU3SgIcgTE4FAEBAQEBAQGBCoQkAQEEAQEBGgYROhsCAQgaAiYCAgIlCxUQAgQBEoguDbZMljgBAQEBAQEBAQEBAQEBAQEBAQEBARQEgSKKKoQtYIJogUMFlFcBjDGBQ4Qdj1GDYSaCPoE+b4EEQ4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,523,1432598400"; d="scan'208";a="12036000" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-7.cisco.com with ESMTP; 22 Jul 2015 13:21:50 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t6MDLo0o017939 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 13:21:50 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.37]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 08:21:50 -0500 From: "Acee Lindem (acee)" To: "John G.Scudder" , "spring@ietf.org" Thread-Topic: [spring] working group adoption call for draft-filsfils-spring-segment-routing-central-epe Thread-Index: AQHQxIB7otsRytevJEytlHh42P63Bp3n7w4A Date: Wed, 22 Jul 2015 13:21:50 +0000 Message-ID: References: <4B9BB879-99E2-4A96-A1A6-D05A4EAE9C3D@juniper.net> In-Reply-To: <4B9BB879-99E2-4A96-A1A6-D05A4EAE9C3D@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.210.151] Content-Type: text/plain; charset="utf-8" Content-ID: <2DF57F8352E53D45B7420F922476B7C3@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-central-epe X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 13:21:53 -0000 SSBzdXBwb3J0IFdHIGFkb3B0aW9uIG9mIHRoaXMgZHJhZnQgYXMgdGhlcmUgaXMgYSBzdHJvbmcg cmVxdWlyZW1lbnQgZm9yDQpyb3V0aW5nIGRvbWFpbiBleGl0IHNlbGVjdGlvbi4NClRoYW5rcywN CkFjZWUgDQoNCg0KT24gNy8yMi8xNSwgMzoxNSBQTSwgInNwcmluZyBvbiBiZWhhbGYgb2YgSm9o biBHLlNjdWRkZXIiDQo8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGpnc0Bq dW5pcGVyLm5ldD4gd3JvdGU6DQoNCj5EZWFyIFdHLA0KPg0KPkFzIHdlIGRpc2N1c3NlZCBhdCBv dXIgbWVldGluZyB5ZXN0ZXJkYXksIHdvcmtpbmcgZ3JvdXAgYWRvcHRpb24gaGFzIGJlZW4NCj5y ZXF1ZXN0ZWQgZm9yIGRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zZWdtZW50LXJvdXRpbmctY2VudHJh bC1lcGUuIFBsZWFzZQ0KPnJlcGx5IHRvIHRoZSBsaXN0IHdpdGggeW91ciBjb21tZW50cywgaW5j bHVkaW5nIGFsdGhvdWdoIG5vdCBsaW1pdGVkIHRvDQo+d2hldGhlciBvciBub3QgeW91IHN1cHBv cnQgYWRvcHRpb24uIE5vbi1hdXRob3JzIGFyZSBlc3BlY2lhbGx5DQo+ZW5jb3VyYWdlZCB0byBj b21tZW50Lg0KPg0KPkluIGNvbnNpZGVyYXRpb24gb2YgdGhlIGZhY3QgdGhhdCBhIG51bWJlciBv ZiBXRyBjYWxscyBhcmUgZ29pbmcgb24NCj5jb25jdXJyZW50bHksIHdlIHdpbGwgZW5kIHRoZSBj YWxsIG9uIEF1Z3VzdCAzMSwgMjAxNS4NCj4NCj5BdXRob3JzLCBwbGVhc2UgaW5kaWNhdGUgd2hl dGhlciB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIgYW5kIGlmDQo+c28sIHdoZXRo ZXIgaXQgaGFzIGJlZW4gZGlzY2xvc2VkLiBBbHNvLCB0aGUgbGVuZ3RoIG9mIHRoZSBhdXRob3Ig bGlzdA0KPmZvciB0aGlzIGRvY3VtZW50IGV4Y2VlZHMgdGhlIG1heGltdW0gcmVjb21tZW5kZWQu IEFzc3VtaW5nIHRoZSBkb2N1bWVudA0KPmlzIGFkb3B0ZWQsIHRoZSBhdXRob3JzIHNob3VsZCBi ZSBwcmVwYXJlZCB0byBjb3JyZWN0IHRoaXMgd2hlbg0KPnN1Ym1pdHRpbmcgYXMgYSBXRyBkb2N1 bWVudCwgaWRlYWxseSBieSByZWR1Y2luZyB0aGUgbGlzdCB0byBzaW1wbHkgdGhlDQo+YWN0aXZl IGVkaXRvcihzKSBhbmQgbWFraW5nIHVzZSBvZiB0aGUgImNvbnRyaWJ1dG9ycyIgc2VjdGlvbiBm b3IgdGhlDQo+ZnVsbCBsaXN0Lg0KPg0KPlRoYW5rcywNCj4NCj4tLUJydW5vIGFuZCBKb2huDQo+ DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zcHJp bmcgbWFpbGluZyBsaXN0DQo+c3ByaW5nQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg0K From nobody Wed Jul 22 06:22:48 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F751B3356; Wed, 22 Jul 2015 06:22:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zimK6FLDKhn; Wed, 22 Jul 2015 06:22:44 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561FB1A1A9B; Wed, 22 Jul 2015 06:22:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1906; q=dns/txt; s=iport; t=1437571364; x=1438780964; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=uCCYNb5K22k7ei/zURm/Cd9HB20cfLjkZjW2A4sSMpY=; b=ESFFu0Z2QIEpYow0jQgjclmFs9vSZ/aWCgeXO74nPNiM+Qr5dOaSqHib b0EsCmDJPw4hqKOBidIvcm5rId+CnaRLxHVw5n5wl/3iOXC0cyDRPrOw2 eOrWpccFHUgvYyAcLtUOONYaFIQUSjA+46dAHNEwT3AQIZQ8Rf+mXChLL k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0A5AwDZl69V/4oNJK1bgxVUaQaDHbhaCYFrCoU3SgIcgTE4FAEBAQEBAQF/C4QkAQEEAQEBGgYROgsQAgEIGgImAgICJQsVEAIEDgWILg22TpY4AQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSBIooqhC1ZB4JogUMFlFcBjDGBQ4Qdj1GDYSaCPoE+b4EEQ4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,523,1432598400"; d="scan'208";a="171126680" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-6.cisco.com with ESMTP; 22 Jul 2015 13:22:43 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t6MDMh1M031697 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 13:22:43 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.37]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 08:22:43 -0500 From: "Acee Lindem (acee)" To: "spring@ietf.org" Thread-Topic: [spring] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop Thread-Index: AQHQxIDU8ERkTDnIVUehkvPQ7OrIQJ3n704A Date: Wed, 22 Jul 2015 13:22:43 +0000 Message-ID: References: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> In-Reply-To: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.210.151] Content-Type: text/plain; charset="utf-8" Content-ID: <39D9BDAB7FC9CE46B682D650F7DCCE74@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 13:22:46 -0000 SSBzdXBwb3J0IFdHIGFkb3B0aW9uIGFzIHRoZXJlIGlzIGEgc3Ryb25nIHJlcXVpcmVtZW50IGZv cg0KaW50ZXJvcGVyYWJpbGl0eS4gDQpUaGFua3MsDQpBY2VlIA0KDQpPbiA3LzIyLzE1LCAzOjE3 IFBNLCAic3ByaW5nIG9uIGJlaGFsZiBvZiBKb2huIEcuU2N1ZGRlciINCjxzcHJpbmctYm91bmNl c0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgamdzQGp1bmlwZXIubmV0PiB3cm90ZToNCg0KPkRlYXIg V0csDQo+DQo+QXMgd2UgZGlzY3Vzc2VkIGF0IG91ciBtZWV0aW5nIHllc3RlcmRheSwgd29ya2lu ZyBncm91cCBhZG9wdGlvbiBoYXMgYmVlbg0KPnJlcXVlc3RlZCBmb3IgZHJhZnQtZmlsc2ZpbHMt c3ByaW5nLXNlZ21lbnQtcm91dGluZy1sZHAtaW50ZXJvcC4gUGxlYXNlDQo+cmVwbHkgdG8gdGhl IGxpc3Qgd2l0aCB5b3VyIGNvbW1lbnRzLCBpbmNsdWRpbmcgYWx0aG91Z2ggbm90IGxpbWl0ZWQg dG8NCj53aGV0aGVyIG9yIG5vdCB5b3Ugc3VwcG9ydCBhZG9wdGlvbi4gTm9uLWF1dGhvcnMgYXJl IGVzcGVjaWFsbHkNCj5lbmNvdXJhZ2VkIHRvIGNvbW1lbnQuDQo+DQo+SW4gY29uc2lkZXJhdGlv biBvZiB0aGUgZmFjdCB0aGF0IGEgbnVtYmVyIG9mIFdHIGNhbGxzIGFyZSBnb2luZyBvbg0KPmNv bmN1cnJlbnRseSwgd2Ugd2lsbCBlbmQgdGhlIGNhbGwgb24gQXVndXN0IDMxLCAyMDE1Lg0KPg0K PkF1dGhvcnMsIHBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlvdSBhcmUgYXdhcmUgb2YgYW55IHJl bGV2YW50IElQUiBhbmQgaWYNCj5zbywgd2hldGhlciBpdCBoYXMgYmVlbiBkaXNjbG9zZWQuIEFs c28sIHRoZSBsZW5ndGggb2YgdGhlIGF1dGhvciBsaXN0DQo+Zm9yIHRoaXMgZG9jdW1lbnQgZ3Jl YXRseSBleGNlZWRzIHRoZSBtYXhpbXVtIHJlY29tbWVuZGVkLiBBc3N1bWluZyB0aGUNCj5kb2N1 bWVudCBpcyBhZG9wdGVkLCB0aGUgYXV0aG9ycyBzaG91bGQgYmUgcHJlcGFyZWQgdG8gY29ycmVj dCB0aGlzIHdoZW4NCj5zdWJtaXR0aW5nIGFzIGEgV0cgZG9jdW1lbnQsIGlkZWFsbHkgYnkgcmVk dWNpbmcgdGhlIGxpc3QgdG8gc2ltcGx5IHRoZQ0KPmFjdGl2ZSBlZGl0b3IocykgYW5kIG1ha2lu ZyB1c2Ugb2YgdGhlICJjb250cmlidXRvcnMiIHNlY3Rpb24gZm9yIHRoZQ0KPmZ1bGwgbGlzdC4N Cj4NCj5UaGFua3MsDQo+DQo+LS1CcnVubyBhbmQgSm9obg0KPg0KPlAuUy46IENjIE1QTFMgb3dp bmcgdG8gdGhlIExEUCBjb25uZWN0aW9uLiBQbGVhc2UgcmVzcGVjdCB0aGUgcmVwbHktdG8uDQo+ X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zcHJpbmcg bWFpbGluZyBsaXN0DQo+c3ByaW5nQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zcHJpbmcNCg0K From nobody Wed Jul 22 06:22:59 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE801A1BED; Wed, 22 Jul 2015 06:22:53 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3sJJgYQn2KP; Wed, 22 Jul 2015 06:22:47 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0781.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:781]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E61CB1A1A9B; Wed, 22 Jul 2015 06:22:46 -0700 (PDT) Received: from CY1PR0501MB1834.namprd05.prod.outlook.com (10.163.141.148) by CY1PR0501MB1356.namprd05.prod.outlook.com (10.160.226.149) with Microsoft SMTP Server (TLS) id 15.1.219.17; Wed, 22 Jul 2015 13:22:26 +0000 Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from [172.29.64.169] (193.110.55.14) by CY1PR0501MB1834.namprd05.prod.outlook.com (10.163.141.148) with Microsoft SMTP Server (TLS) id 15.1.219.17; Wed, 22 Jul 2015 13:22:25 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John G.Scudder Date: Wed, 22 Jul 2015 15:22:18 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <8DF353F0-B466-4FAF-A92F-CF1A6A541973@juniper.net> To: X-Mailer: Apple Mail (2.2102) X-Originating-IP: [193.110.55.14] X-ClientProxiedBy: CY1PR13CA0122.namprd13.prod.outlook.com (25.164.65.48) To CY1PR0501MB1834.namprd05.prod.outlook.com (25.163.141.148) X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1834; 2:hvtS8kgNuI2/63FKmb7VsLRRY6L/nDng03Q9AeOke0V/b6nQgLtUYLKFkVm2u6RL; 3:pb/CUdVuhxpR/6WQkRuZkd32dB/rZ1nneYVeXZ88b+x0QG91WrzR0MZQTGEv0m1ObE8LmvVne/EBU78f/uC/Xvmy//IjAfhT/ueZJ+QqGZH0yNpQuVxRN79zSWXvbKnKh+e7E0k8sfzPui8nVz8xRw==; 25:m1pzg6fqwyBEVn266wdCvlS+J6/nzKsR66iN+ClDzedQBQ/RhDOYlot2P5OlsuxrrtKJN7cHF+d7CEf3WNGq3nJ6NtV04qJkQ5vI3mx9azmQIX+B35p1MWjMR6iPCmBpU79CDLyWzRP/ntR24+ulabwgO3WaHCzF89yMZWziZcYeFSOgXMcsLxCBxWJ+AH/Y/brt0wdfAw73fupEtk29eJDN7Bad+uEW1LPhigAj9KtgGUbPGolQji5nTc6krCMbBX74ykSF/CvaWZo06mqCvw== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1834; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1356; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1834; 20:EobdKSX2VTMFfZXNwcCsdxh1w4uS83ZubP+D9XKBGd3JMF9MHHdUIc2pa+JP2FV3qUGzWZGju0O+h/IMyAFxk16G4v9R6/ItlUxuPDGr9rIeBIO887/YvaE3xbMSB7sTFaviPl0IQ6ywQjCiM151NwL4B8Ij/rYDIhgOAxOtoqdukmoeBTncNZm26EghpTNRBUtLRP3a2e+PaUPZ4Gtf3ax7y+yYEyxuAYsJTxY5yiSr35EPHTFCzP7Zlf2Df7hyQ81p30Ie1Y9U19Ag8SNYM7laZw2IJfWT20Sj1xuLtn6zR/GkU3q/zYEVPZYT2NK/GNv+Rd8isKcWsu5r0TVfVCXp5zJeZoGcyeL6DEqn9SA8x/+REyW+7xvo0zXb+kCnadfdV0smleB1/VHU17NVfoAPPVawmcXolEp1FD1zsN1uQfvbml5YxwTDkWrd8mwDHxX6CDjWinJvIYG5KoVCz1ZHx6am/f4p+gXlLtnv35OAbJDK1to52E/8I0QEqQ6T; 4:IJfwDHe3kkUc1vUGXnZC1nWcqOEpWEfazioeniRZ+x/vvl8xl4+PgjuUjRF6iFeF654WCI/fw/t8jMhgqd94TtS87QunAYZW/iOx59+QDO2MutRqnyE3guuE8rVVOjx9WlnKR84GQDaBpElF/eNCzU5RFVuevliuxBDnmKR+Au3fyXqjh2vlj2XsiFIyoa/xM+eONrnLG8zRX7fBI+TXHYg2F0qvnf50zQ9YsXaEN+LYnSWkzGR7hRMa5kuDOisUilpSrf+FVlutvjVmf63p7+QTs1GM85oUIgTQYAISyfE= CY1PR0501MB1834: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR0501MB1834; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1834; X-Forefront-PRVS: 0645BEB7AA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(164054003)(52044002)(97756001)(42186005)(62966003)(19580405001)(19580395003)(230783001)(2351001)(229853001)(87976001)(46406003)(50226001)(33656002)(23726002)(77156002)(83716003)(43066003)(122386002)(40100003)(450100001)(50986999)(5001920100001)(66066001)(82746002)(50466002)(46102003)(53806999)(5001960100002)(189998001)(110136002)(36756003)(57306001)(77096005)(86362001)(47776003)(104396002)(42262002)(217873001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1834; H:[172.29.64.169]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB1834; 23:pIcCBpYerjxU0xLEMhwxWRUuOhSbmkib0RQHJDm?= =?us-ascii?Q?6d/AgXxmLX2BCfeShKrfk6ZIQCyjTzF8VEMeYX8TMc5HNdS+TKNcv6ZQCtnE?= =?us-ascii?Q?Pf3JmYUrf8+X3fsLF7FF2D7eiro9XLQvuljjcYw2xIOWMHs/HvD+dIZ5COJe?= =?us-ascii?Q?+foqSZr6vSmrV5DVJP1XWoVFkjLuz9UyQJvjLPQqN6BC0SsznG6QoBa2SoG5?= =?us-ascii?Q?giqpcmoWIZIOvDVIlCcG2jY8QbG4Qd+jzJjSzUs6wYPtxHrxhHwDGsUU/S5s?= =?us-ascii?Q?gJyX5+kxopOiwFFWmzWlBiiE2uS8cFSfimvoHYeQ8QaXJlc1F3X7cwgWAw9A?= =?us-ascii?Q?PMaTjnNtNuAJ6stvAzwcGqJjIxJp13qxfMQaGhrhJBbZgQ7jb+kp4VAkz5/p?= =?us-ascii?Q?Kty6x1GntU/dwc+8FPoHSpdRmYDjHFWtFHXvpsUGuDm1FPhyS9kGrKtAg2yg?= =?us-ascii?Q?1Ji8H5bOiD+xjRRyHBVThS3qVHPwigHoNrdbDWgqzLxaEg3gnuX8IK39cP9E?= =?us-ascii?Q?L6RX0p2TPfqAxxtLZW2fUwcFpc2/si6rW/UuycPAXozDeyBsLkziRPLHsIsy?= =?us-ascii?Q?KQu8Xyqz9NAD+Xys8/NqKNFRTj7gh+Mwe9DXmFU2/z+bM+MVflNWb/1/0VUJ?= =?us-ascii?Q?RzigkULR5DKbwHOeRDn9JipqDMWAOdmrpr4/bwp28MJz969rNtnnpVvVxD44?= =?us-ascii?Q?RFbwb1Rvpa2QPfuP++Q0PSkoJRy7tEnBfpBSYt/4l0u5Nr57t/fnhMDFAhjE?= =?us-ascii?Q?LvBuymhsv5ZQL2iHSHfzcHGv4FGHpUbm1nI78rBXbPoO8QTuhySUQMO1Gd2m?= =?us-ascii?Q?J6FzOPZp9kkxhfqYuByydj/RHYyn9KfqCPBBTHExOnYp45kgyL0qEzy8F8er?= =?us-ascii?Q?OXvi+RNs0qBbIMCyiart9h8RbiRkGXCehUmwFJhQfA/Mph6/ebwfl7GKDLw6?= =?us-ascii?Q?7Hc7S8/CGOexpw38Uso/Y2gwO5nzAv1fRod2JSPC9+kGutRvABpRt5f856Hn?= =?us-ascii?Q?i9L6dK2Xx+Ds/qweUfRtX88CaRIHusNQXlzOkNHTwCcELhVhS/vuXdq9om/G?= =?us-ascii?Q?0Jfge+haMPA28TaFeyYNCO3w6EGro?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1834; 5:cjm3kKv8LCeLVX6IBjMDhvR3n8u7U9EzX+nnJvtUD8bmt2HBjgN1gTQJ1UMzgUBtdnl2tc8vcAm0RxrIo4XX1NlyrzvSFyBQhbnIDrZYPXdF2arvax+f9tQkGGW6k4IwRYvc5wPIsLk1k4gr9rGjrg==; 24:hCus84oxVuWuI0ttk/6npS67C/kA1GgEP6WHBzQPNFccpnzHtx0rl6a3LbeDhDbucmMXZ0vaKuOfHdOPLsWXZyv4M1LH5GQ4igx2xV6YI3s=; 20:Ach9lMouVBwvKa1ha8TMODWgKpnf7l6mh3xfDM2NO8M0V8VwKz9M9YI1Fd+DoNbdUss9vzVipxD078JUDVoAGg== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jul 2015 13:22:25.3086 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1834 X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1356; 2:3+2o51WoUPag3Jdqk8qqrKxtcU6PPHqwNwO1JG/Mb2fm3RQECJIj2vVsmjewlXRF; 3:oQFSbd+8qRRGhCIPMnENeVxwgatS6lu9jXFHAMtlQZN4OpxRfT+pvt2umq5uDWQ5z+7+0o9TuBAGNg+hvp3gBUHpjX9M2hSB++76xmNw0LaN66areQmoltvDKHlcRYM3Y5KKZnD5ICSBdNc72mg++w==; 25:6TbTMTE3jD9XbGIwhRpo0+T34wQgDimFhoZsJgbfjyv62RVFw535I6f5glJtcd47sw6pPPtBHHaUpA3OOWE/HKixGI4NY4oUIAh/JZrfHVNyty07nEP/daHqVuGzZNcURcA3434NEoZBVjSQiR7q62pEGUj2z13lvvSTvo0nH8jFGyumIzrks5jndn/GCaLfsLv7OfO98wqKum//foikaxhUH1iViAhFBXTBVN/d1pgpXxr8VYksCUN2ChNzD9SbuFv2ab8QkBwAhxGQyXTkPA==; 20:UOiL8MjY09Wb96Z8RVL9FLTXm6h1Ngq1GrsPF+2M+VMEWwOdsljnM8VHvYyVVk/WDIxlvKJukBxYzaMNuL1+nQ==; 23:hv9QEnQlg5YsE+/SyzAhTQKAz67IwzhFiPVUSKFMCMs8pLwpocVdVYg2cIJArXVo+PjtyDDkFpeDBFOiNt3sEDMaOVpkSLBbErDYXzfcb6RMviGahC6lceaYzNhBiVKmHlM1G3Kg1zdlykR3rgyUXR7p9wkynRLNM+0JVNQ0QylRW2Mq96okTx37WHNKXyNMz/ji1TfryvfjXLVLyX18roGCUcN5/BCm3/PX8A97N+axXwG9DvgEAy9Uwy0hUHVp CY1PR0501MB1356: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: juniper.net Archived-At: Cc: spring@ietf.org Subject: [spring] SPRING WGLC of draft-ietf-spring-segment-routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: spring@ietf.org List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 13:22:53 -0000 [Sigh, it's isis-wg@ietf.org, not isis@ietf.org. Sloppy of me. Resending = to isis-wg for this and the others, and to SPRING, but not re-cc'ing the = rest of the other WGs. Sorry about that.] Dear IS-IS, OSPF, MPLS, 6MAN Working Groups, As you probably know, SPRING's work relates to your working group, as = follows: - IS-IS & OSPF: the draft defines the basis for your WG doc IGP = extensions (draft-ietf-*-segment-routing-extensions) - MPLS: MPLS is a data plane of SPRING. The SPRING architecture should = not impact the MPLS data plane nor architecture, but does have side = impacts. e.g. OAM, signaling (e.g. entropy label), deeper label stack. - 6MAN: IPv6 is a proposed data plane of SPRING. It would require a new = routing extension header to be defined in 6MAN. (+ security implications = to be studied) Thus, we anticipate you may have an interest in the SPRING architecture = document. We are about to begin our working group last call and will cc = your WGs. This message is to encourage you to review the document and = comment as needed during the WGLC. Owing to the broad cc, out of respect = for people's inbox clutter I suggest you respect the reply-to, which = I've set to the SPRING mailing list, though if you think it's applicable = feel free to add your own WG list.=20 Thanks, --Bruno and John= From nobody Wed Jul 22 06:23:18 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22A031B3391 for ; Wed, 22 Jul 2015 06:23:10 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGxI_mKTHID4 for ; Wed, 22 Jul 2015 06:23:07 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.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 5B2901A1BED for ; Wed, 22 Jul 2015 06:22:57 -0700 (PDT) X-AuditID: c618062d-f799e6d00000329e-b9-55af3d48dbb9 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 05.13.12958.84D3FA55; Wed, 22 Jul 2015 08:50:48 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Wed, 22 Jul 2015 09:22:55 -0400 From: Jeff Tantsura To: John G.Scudder , "spring@ietf.org" Thread-Topic: [spring] working group adoption call for draft-filsfils-spring-segment-routing-msdc Thread-Index: AQHQxICqND6EDXAWJkOBKZErzSiiH53nR6+A Date: Wed, 22 Jul 2015 13:22:55 +0000 Message-ID: References: <36F65DE7-6714-41FB-8A6B-CEB373CAC111@juniper.net> In-Reply-To: <36F65DE7-6714-41FB-8A6B-CEB373CAC111@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="us-ascii" Content-ID: <0625C5DCDE3D7B41A4927F16D14AC6B3@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXRPiK6H7fpQg51PjS1m3vjKanH8wm9G ByaPJUt+Mnlcb7rKHsAUxWWTkpqTWZZapG+XwJXxbvZTtoJHXBWrnrUwNzD+4Ohi5OSQEDCR uLC9hw3CFpO4cG89kM3FISRwlFFi0uxZ7BDOckaJi9vWsoNUsQkYSPz/dpwFxBYR8JRo+rGE CcQWFkiSaJ52gREinizRvf0zE4RtJLFr2mSwXhYBVYn2ZetYQWxeAXOJ5lXbweJCAnYSEzf+ B6vnFLCXuHj+EZjNCHTR91NrwGxmAXGJW0/mM0FcKiCxZM95ZghbVOLl439gM0UF9CRWXm+C +kZJYs7ra8wQvToSC3Z/YoOwrSVmLfkFNVNbYtnC18wQ9whKnJz5hGUCo/gsJOtmIWmfhaR9 FpL2WUjaFzCyrmLkKC1OLctNNzLYxAiMq2MSbLo7GPe8tDzEKMDBqMTDu6BjXagQa2JZcWXu IUZpDhYlcV7HqLxQIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyGHyZlTLvx5/OvnW/FF3/j 2TDL+9CdSW/Xht7zClg4nX+X6vorbCsKzSaXV8zrltyovob7eLz2WcaVe0Qm+rj1Pr9cKS1b NfnC9G4H9glS5np7DINyVh2ffvunD2fQ9OlaallHHp5O7OOeM/fACykn/4fXfv0y9aj8W779 X6C+SB2DaGuEv7WpEktxRqKhFnNRcSIAxUdO24wCAAA= Archived-At: Subject: Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-msdc X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 13:23:10 -0000 Yes/support Cheers, Jeff -----Original Message----- From: "John G.Scudder" Date: Wednesday, July 22, 2015 at 6:15 AM To: "spring@ietf.org" Subject: [spring] working group adoption call for draft-filsfils-spring-segment-routing-msdc >Dear WG, > >As we discussed at our meeting yesterday, working group adoption has been >requested for draft-filsfils-spring-segment-routing-msdc. Please reply to >the list with your comments, including although not limited to whether or >not you support adoption. Non-authors are especially encouraged to >comment. > >In consideration of the fact that a number of WG calls are going on >concurrently, we will end the call on August 31, 2015. > >Authors, please indicate whether you are aware of any relevant IPR and if >so, whether it has been disclosed. Also, the length of the author list >for this document greatly exceeds the maximum recommended. Assuming the >document is adopted, the authors should be prepared to correct this when >submitting as a WG document, ideally by reducing the list to simply the >active editor(s) and making use of the "contributors" section for the >full list. > >Thanks, > >--Bruno and John > >_______________________________________________ >spring mailing list >spring@ietf.org >https://www.ietf.org/mailman/listinfo/spring From nobody Wed Jul 22 06:23:39 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1DA1A1A9B for ; Wed, 22 Jul 2015 06:23:33 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj-esWyEFHQf for ; Wed, 22 Jul 2015 06:23:27 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.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 94F351B338C for ; Wed, 22 Jul 2015 06:23:19 -0700 (PDT) X-AuditID: c618062d-f799e6d00000329e-c6-55af3d5b06f2 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id A7.13.12958.B5D3FA55; Wed, 22 Jul 2015 08:51:08 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Wed, 22 Jul 2015 09:23:15 -0400 From: Jeff Tantsura To: John G.Scudder , "spring@ietf.org" Thread-Topic: [spring] working group adoption call for draft-filsfils-spring-segment-routing-central-epe Thread-Index: AQHQxIB6/eqZ4WWHakebmFi30txGSZ3nR7uA Date: Wed, 22 Jul 2015 13:23:14 +0000 Message-ID: References: <4B9BB879-99E2-4A96-A1A6-D05A4EAE9C3D@juniper.net> In-Reply-To: <4B9BB879-99E2-4A96-A1A6-D05A4EAE9C3D@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [147.117.188.11] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyuXRPiG6M7fpQg9MvmS1m3vjKanH8wm9G ByaPJUt+Mnlcb7rKHsAUxWWTkpqTWZZapG+XwJXRuP0JU8ELrornTX+YGxj/c3QxcnJICJhI 3Nz9jRHCFpO4cG89WxcjF4eQwFFGieMnWlkhnOWMEj/2H2EDqWITMJD4/+04C4gtIuAp0fRj CROILSyQKbFg3iGgGg6geJZE+xYtiBIjiTWPm8HKWQRUJd7v/gc2hlfAXGLpkVNgcSEBO4nZ M9axg9icAvYSq5fsAoszAh30/dQasPHMAuISt57MZ4I4VEBiyZ7zzBC2qMTLx/9YQWxRAT2J ldeb2CDiShIff89nh+jVkViw+xMbhG0tMfPXGlYIW1ti2cLXzBD3CEqcnPmEZQKj+Cwk62Yh aZ+FpH0WkvZZSNoXMLKuYuQoLU4ty003MtjECIyqYxJsujsY97y0PMQowMGoxMO7oGNdqBBr YllxZe4hRmkOFiVxXseovFAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjKKNu0w/F672kd14 79CL1EvzXBnitojLfXENeRyl9Ckh+31RrtBrqfW+EfXv90juiRZapZx8jSF6Qn+Jd+at7Oa5 LXmzLOLem4bGam03l0n6nmf7k7PA9dDl2J5lNy6/9gq6UpWw4+brXO6//P4bbJjz77Mlc806 Ea7QtDU8XfbAsfsuETVflViKMxINtZiLihMB6HkvsIsCAAA= Archived-At: Subject: Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-central-epe X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 13:23:33 -0000 Yes/support Cheers, Jeff -----Original Message----- From: "John G.Scudder" Date: Wednesday, July 22, 2015 at 6:15 AM To: "spring@ietf.org" Subject: [spring] working group adoption call for draft-filsfils-spring-segment-routing-central-epe >Dear WG, > >As we discussed at our meeting yesterday, working group adoption has been >requested for draft-filsfils-spring-segment-routing-central-epe. Please >reply to the list with your comments, including although not limited to >whether or not you support adoption. Non-authors are especially >encouraged to comment. > >In consideration of the fact that a number of WG calls are going on >concurrently, we will end the call on August 31, 2015. > >Authors, please indicate whether you are aware of any relevant IPR and if >so, whether it has been disclosed. Also, the length of the author list >for this document exceeds the maximum recommended. Assuming the document >is adopted, the authors should be prepared to correct this when >submitting as a WG document, ideally by reducing the list to simply the >active editor(s) and making use of the "contributors" section for the >full list. > >Thanks, > >--Bruno and John > >_______________________________________________ >spring mailing list >spring@ietf.org >https://www.ietf.org/mailman/listinfo/spring From nobody Wed Jul 22 06:24:28 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6000E1A1A9B; Wed, 22 Jul 2015 06:24:18 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czRrE2gILrTv; Wed, 22 Jul 2015 06:24:17 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0758.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:758]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37AE21B305E; Wed, 22 Jul 2015 06:24:14 -0700 (PDT) Received: from CY1PR0501MB1834.namprd05.prod.outlook.com (10.163.141.148) by CY1PR0501MB1356.namprd05.prod.outlook.com (10.160.226.149) with Microsoft SMTP Server (TLS) id 15.1.219.17; Wed, 22 Jul 2015 13:24:02 +0000 Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none; Received: from [172.29.64.169] (193.110.55.14) by CY1PR0501MB1834.namprd05.prod.outlook.com (10.163.141.148) with Microsoft SMTP Server (TLS) id 15.1.219.17; Wed, 22 Jul 2015 13:24:00 +0000 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) From: John G.Scudder Date: Wed, 22 Jul 2015 15:23:55 +0200 Content-Transfer-Encoding: quoted-printable Message-ID: <5E1C2E18-E314-4364-8A17-A543DFF888E3@juniper.net> To: X-Mailer: Apple Mail (2.2102) X-Originating-IP: [193.110.55.14] X-ClientProxiedBy: BLUPR07CA0028.namprd07.prod.outlook.com (10.255.223.141) To CY1PR0501MB1834.namprd05.prod.outlook.com (25.163.141.148) X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1834; 2:6IZoGB+tMBTuTjb0jAVsTMRfsZE/IRW5JNrWUa1iJa6WxSdsQ8+3Ttb8syy0bO6Y; 3:DsM3dSvqEixHhDe72TyeL6P9Fhk8t7QE8l0HfhowBSCJ3KlJDGQdBZ3xNjLlsqBXgMkt52nHvBP8FSk6LbNwkgmjnForXKcBq8BG1KbpMTug3VbcZxBBS/I+pLPhJnZF6H2mOFRft+zZoCJQ7Vp2SQ==; 25:WThDYUNTngp0v7OIZWqXpXcG2iEjSm7iaOUlAt0FhroElghkoqaMc3tLIeX9cgB3LzUYfv+gCgIIqJuD2F67xYVqeuBRbNGReIU6w4uxpCrZXrEq7/mudlo3W3AHqB9JzjTs2k4tRh+zActyFD0qw4JhxKl8Tw7HNaF/+tS2dCJ0XaU9afPRU5V3trPEA6vFpCNW7E8fIKM1w0MbYiOb8xx9kOCK5owdKfU0yRNDT4j4n1Xwgx+vsIx+L4jbrdBdqjG5BdvKtybVIreZve+ckA== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1834; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1356; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1834; 20:noiLiU3khAEln2zogwhkMfVFg6WLYoVH3cRU5o8yuarcPW4to95ZUWNHgotYpfGbN5oraMQYYVd1PEs5FzxPqNMxd8+nmK67YSKvL1i3UO8yPu5wCN/9tRaZaQ4a1OB8Go0+ZVH4gK3cyL9uchWZyV9WD7pMGxC+ykR7tv+qu3uXaEs80duoQPeoKblhtBEj0l+uawfC69xndRrYd0pMRoorMvuuvLtOam30brrLhErXFOCYr1ENnrgPuvqt1MP9pqRjjQz2VmFbO+JZ+9z/kcMkmBLhwfboL0nO6aZgS5ugau16c4bvdeuIioDPlfLtCDSW/BVJF36LLOtjRRKhYV1ZGTYxetAAcM1KZVnzd93J/sKRYuoDHUtwomx3tZYiyFqE3jhGLZOaimvI48Nu18OGDMexnXv+rIpV8gqgiyy4xdt/vJfvkLASqQ+kKleJDSjbGpscYnzhQpZjUOXhyCtS/nkvjOjBvvndfmsC0KVE4bgnZeBqorHL5rITWZoH; 4:5qePusFrHB5wFozVwIHZVSbrSHXblCllgQSx1JL9oNFiUF9+3ACkCMd+2zBc4vBdr3eHqvb1XOWIA3gWTaZtSCgWFlHXvRGULOKY9Vs/eGtCRmYcLLDyL/79z40vXNK1i66OnangeRLDcWsQs/JO7I2wejgVCPhu7CpHcQIJHM7DiX/U7DwpW629/rsqWXbPmxacCl7sN61C9MGnGRA32skfOXpl6lVmoUI3LKFYjDNhR5X8DAYt49lhBypiNz8PtUNrD2mRQ9ISRbHArHb4cAB09Y5g1+a0AsrpgcvF4Eg= CY1PR0501MB1834: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CY1PR0501MB1834; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1834; X-Forefront-PRVS: 0645BEB7AA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(164054003)(40764003)(97756001)(42186005)(62966003)(230783001)(2351001)(229853001)(87976001)(46406003)(50226001)(33656002)(23726002)(77156002)(83716003)(43066003)(122386002)(40100003)(450100001)(50986999)(5001920100001)(66066001)(82746002)(50466002)(46102003)(53806999)(5001960100002)(189998001)(110136002)(36756003)(57306001)(77096005)(86362001)(47776003)(104396002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1834; H:[172.29.64.169]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB1834; 23:IvGGqUWK42YCH7h5ZwYrRO4T1lE/O4D7nEuP/u+?= =?us-ascii?Q?e4422dM6P4l0sG/L4KL6esv+w1vCWGBNMXxuYeh5duiP4fEAFvepnQCBtbJv?= =?us-ascii?Q?40BGoWHBSFZ0mvlCIEQ5r6YzMl4Ov2gmkqM8YiK9NP4KfWm8IGDMO2wvZ250?= =?us-ascii?Q?V240NkA+1Nv65UMYoXHDHbZsEKeWZS4oTZtkHxh+NzV4BXZgR4rsOtUaG9v3?= =?us-ascii?Q?QLvbyh1uTz72zi4Mh1VpMDN5ASNqK5RaQhvtAs0xpIWx6BGsF1vZR5JH02ju?= =?us-ascii?Q?h1cOPZ75WxyrOWfHu0V5lHEavuJgTDdYJah1DnVxVVK97BfzMuu0gtjrHMxe?= =?us-ascii?Q?f5RCFVVGwMKiT9xE7BbEOblD2wa6Q1SnrdvmZ8wOaCEPAXd73rI6kpvqZUFA?= =?us-ascii?Q?TzymuuluM5JoUipR3qErNPdcs4sK3uypW8xouSMiLeaLJl8lnsuACF+tBGsi?= =?us-ascii?Q?ocpK6bn4tVgTyUW4Z9ouOXZ3KotxilIjCiVjynA7qT4WqODdFJYJ0aIvoLgI?= =?us-ascii?Q?wKfhSgIMm1mXjs7ysWbWToeTcLy02swMbHa5VabG3Gt0vP73CqIK6bqQnVGz?= =?us-ascii?Q?9WKvEROgfFTCsm9RbSOVDK4EU7q0HX3JBPandx+60tsQpBezrtMq9p77358X?= =?us-ascii?Q?F3HP1yXRmIFL8k/wNuocQR4hAIpLtosITZpcVew+Mq0dCSkQvyKk+aefO/lN?= =?us-ascii?Q?ghzSssHygG6xI1dxjU6LC9ORuoqaB9WlbZPAaqsb2Z9q9X4/lVcVUMI/Rtqe?= =?us-ascii?Q?gMypStx0kw8PbKXhgb07oIQpReh7c7l5ojoJ3mFH6fxmrG8W0tk71kaPxUsG?= =?us-ascii?Q?+YOUppc3w3yuvF0jXPwIO6qs8dEot75x5JapX12GL443e9cG5Wo62SfNDJ7c?= =?us-ascii?Q?99eNXvEhaoBvawmNZoKZEnKce/1mmwjhH4ND4Fqk5D7DELCWEMMabnSEzwgI?= =?us-ascii?Q?1u33wm7UovfglyHduDbPcrvsiBPeiJXP+HJSpVxJvXJJD1zcmnagfgPce7gn?= =?us-ascii?Q?pX0I=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1834; 5:caWTCDJKE+fHa4GYFBapiAX/qzjzX7gukxsE3AFG9xKhAjdhGSpo8ebGKo/RHhaOAr9nSehEbM+Jk7/YvqV4qar3MeQy2zgB2IHHTIoBoe1LVSXvA0F6FsxDc/kMB6mH5InrbUAJPMO/cU2wacpUsw==; 24:SY4bu752K+N+gIr8KffcLj4kTJy5OvjMauiGzWFPlehZ42337RvNfPdReNfBtV65aBWqNWtIDZp3Km3grbzJp9xdo6jQaKns0JpQqxNy3KU=; 20:SRHQA6+JZnoWCL7zieTawMNYPZ+lbX4GMC8yk57d+ZXUR6OdhTsI6RFxdjL3BHo7SLA4mkj7uy6N028KCexXQA== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Jul 2015 13:24:00.8639 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1834 X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1356; 2:kBdHqUJ5rbLtINAtpT3lVZRcaFcKbR0E+Vza5HQX8j+C3ltABTbJ+t7F6p7wnl7k; 3:ykbU0MfUYpfMoQq+4oae9Rcg4GV28wA4fHf1uG/pUEM6wBgpk3SWa5HkY2YMxFginqHLLhv+XITVIMQHT5aTDQ3k/okdWK1mxHu34Uoeudu/KE9yGp8MvhohO2NgrY6H0zIHGVGHRtUMS8yo7hXWeA==; 25:4CUrwNNErbWNKMMeV7xBkhMTd+ehF/A9dO0A/CZ+Zugczs6dJmhTzISPWcVJxZBmWn+p7MktWOyoUls6UvqhgBnIT+8eu64+848hzog/PB+DVtyuHg+TWRxbsY1oYjxbKgXKl4BUqDCptYpSRFDRLnUjOw5xAWWakQabH/kB7gYf3O4nAyIbTvu02FKOttFPKTkjWCXp1aIQOQZi9DbAf7MTiJ1aK5Lwnq9yqhfVW9B8vWEcnAsvjEr8PEFRwZ7OJs1DsfclR61xmyS3SuyNsQ==; 20:hdaBuQc2hDQtuE80mBeTLNnI1Gxh6mbxEdGpO6Uk8n5f1ELVKo3US9brjYlU2MxKoS3ROtIq7NrAWhBVXaqxbQ==; 23:UWxNdvr4xJvzsUdwYjIxNb4a4EMWTv2rUDSI+l3bfyRmm4sfbnWzBCMjmx1b0OReYkBGU2QoIEMC4Zaqcse1DWTB3bwb2mIk+aC/bdxRU4qM13bID6EcHF/gS2LuGjhChCOn4UEv21Q0cjRM7lrsJXFeO792awYYTbEdDWGsW/GcZgPUzamOhufju6bpCzTtHYezh1Lo3KLTqbHSCRlC7ZhvPz0sP+S4z23xxIUk8uBPNQ07OzC+EflBlqODtlpD CY1PR0501MB1356: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: juniper.net Archived-At: Cc: isis-wg@ietf.org Subject: [spring] working group last call for draft-ietf-spring-segment-routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: spring@ietf.org List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 13:24:18 -0000 [re-send with correct address for isis-wg] Dear SPRING WG (and cc MPLS, OSPF, IS-IS, 6MAN, please include SPRING in = replies per the reply-to): As we discussed at the SPRING meeting yesterday, working group last call = has been requested for draft-ietf-spring-segment-routing. Please reply = to the list with your comments, including although not limited to = whether or not you support advancing the document to RFC. Non-authors = are especially encouraged to comment. In consideration of the fact that a number of WG calls are going on = concurrently, we will end the call on August 31, 2015.=20 Authors, please indicate whether you are aware of any relevant IPR and = if so, whether it has been disclosed. (Please do this even if you've = done it before, thanks for your help.) Thanks, --Bruno and John From nobody Wed Jul 22 08:55:07 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A4C1A06E9 for ; Wed, 22 Jul 2015 08:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90xIUHm2shTi for ; Wed, 22 Jul 2015 08:55:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 394D41A0120 for ; Wed, 22 Jul 2015 08:55:04 -0700 (PDT) Received: from omfeda05.si.francetelecom.fr (unknown [xx.xx.xx.198]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id 7A2363B483E; Wed, 22 Jul 2015 17:55:02 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.58]) by omfeda05.si.francetelecom.fr (ESMTP service) with ESMTP id 5D7B7180059; Wed, 22 Jul 2015 17:55:02 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0235.001; Wed, 22 Jul 2015 17:55:01 +0200 From: To: John G.Scudder , "spring@ietf.org" Thread-Topic: [spring] working group adoption call for draft-filsfils-spring-segment-routing-central-epe Thread-Index: AQHQxIB5HJn/ddgYLUKQhxQdicl02p3npITA Date: Wed, 22 Jul 2015 15:55:01 +0000 Message-ID: <1627_1437580502_55AFBCD6_1627_640_1_9E32478DFA9976438E7A22F69B08FF92166A3B32@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <4B9BB879-99E2-4A96-A1A6-D05A4EAE9C3D@juniper.net> In-Reply-To: <4B9BB879-99E2-4A96-A1A6-D05A4EAE9C3D@juniper.net> Accept-Language: fr-FR, en-US Content-Language: en-US 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: 2015.7.16.113616 Archived-At: Subject: Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-central-epe X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 15:55:06 -0000 Support -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of John G.Scudder Sent: Wednesday, July 22, 2015 15:15 To: spring@ietf.org Subject: [spring] working group adoption call for draft-filsfils-spring-seg= ment-routing-central-epe Dear WG, As we discussed at our meeting yesterday, working group adoption has been r= equested for draft-filsfils-spring-segment-routing-central-epe. Please repl= y to the list with your comments, including although not limited to whether= or not you support adoption. Non-authors are especially encouraged to comm= ent. In consideration of the fact that a number of WG calls are going on concurr= ently, we will end the call on August 31, 2015.=20 Authors, please indicate whether you are aware of any relevant IPR and if s= o, whether it has been disclosed. Also, the length of the author list for t= his document exceeds the maximum recommended. Assuming the document is adop= ted, the authors should be prepared to correct this when submitting as a WG= document, ideally by reducing the list to simply the active editor(s) and = making use of the "contributors" section for the full list. Thanks, --Bruno and John _______________________________________________ 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 Wed Jul 22 08:56:14 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365E11A06E9; Wed, 22 Jul 2015 08:56:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmSqi-a6j7Nj; Wed, 22 Jul 2015 08:56:06 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F0441A0120; Wed, 22 Jul 2015 08:56:06 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 667972AC2EB; Wed, 22 Jul 2015 17:56:04 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.24]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 37D8415808C; Wed, 22 Jul 2015 17:56:01 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0235.001; Wed, 22 Jul 2015 17:56:00 +0200 From: To: "spring@ietf.org" Thread-Topic: [mpls] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop Thread-Index: AQHQxIDLXUSkbbJ5d0Sls5gg52FlJ53npJgg Date: Wed, 22 Jul 2015 15:56:00 +0000 Message-ID: <4513_1437580561_55AFBD11_4513_581_1_9E32478DFA9976438E7A22F69B08FF92166A3B44@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> In-Reply-To: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> Accept-Language: fr-FR, en-US Content-Language: en-US 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: 2015.7.16.92416 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [spring] [mpls] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 15:56:11 -0000 Support, not aware of any IPR -----Original Message----- From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of John G.Scudder Sent: Wednesday, July 22, 2015 15:17 To: spring@ietf.org Cc: mpls@ietf.org Subject: [mpls] working group adoption call for draft-filsfils-spring-segme= nt-routing-ldp-interop Dear WG, As we discussed at our meeting yesterday, working group adoption has been r= equested for draft-filsfils-spring-segment-routing-ldp-interop. Please repl= y to the list with your comments, including although not limited to whether= or not you support adoption. Non-authors are especially encouraged to comm= ent. In consideration of the fact that a number of WG calls are going on concurr= ently, we will end the call on August 31, 2015.=20 Authors, please indicate whether you are aware of any relevant IPR and if s= o, whether it has been disclosed. Also, the length of the author list for t= his document greatly exceeds the maximum recommended. Assuming the document= is adopted, the authors should be prepared to correct this when submitting= as a WG document, ideally by reducing the list to simply the active editor= (s) and making use of the "contributors" section for the full list. Thanks, --Bruno and John P.S.: Cc MPLS owing to the LDP connection. Please respect the reply-to. _______________________________________________ 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 Wed Jul 22 09:14:09 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46BE21A8840; Wed, 22 Jul 2015 09:14:06 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4V5fhczaTdW; Wed, 22 Jul 2015 09:14:04 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0138.outbound.protection.outlook.com [65.55.169.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E5C91A8838; Wed, 22 Jul 2015 09:14:04 -0700 (PDT) Received: from CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) by CO1PR05MB537.namprd05.prod.outlook.com (10.141.73.16) with Microsoft SMTP Server (TLS) id 15.1.219.17; Wed, 22 Jul 2015 16:14:02 +0000 Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.1.219.17; Wed, 22 Jul 2015 16:14:00 +0000 Received: from CO1PR05MB443.namprd05.prod.outlook.com ([169.254.12.174]) by CO1PR05MB443.namprd05.prod.outlook.com ([169.254.12.174]) with mapi id 15.01.0219.018; Wed, 22 Jul 2015 16:14:02 +0000 From: Hannes Gredler To: "spring@ietf.org" Thread-Topic: [spring] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop Thread-Index: AQHQxIDSVowz9UQpuEWenozboH6f253nqdcw Date: Wed, 22 Jul 2015 16:14:02 +0000 Message-ID: References: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> In-Reply-To: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [31.133.178.142] x-microsoft-exchange-diagnostics: 1; CO1PR05MB441; 5:s0KjEvWVclHxkrAgaiOICjZthOUaaW8oyLsHcDwRZqO9YH5SE3O8rP7G9Y8bbKjaXo8QjVZciZEUSrkJc66AZDOuohS7WCXRDyNNvTTQnUpHqVrV0wduhu2sztnzihm1dapH5ln41EKtHKrWgxYVhA==; 24:BP9TFzoVpstSaJosxd4TDRiherDBczp6BHX8nH3L6ayQd8JtvDDkiZwMrOC06KF9zu0u8TUEq3/Xy6914LnkoPgnx0Tmjqp8NkKaaKOWmcU=; 20:VbaW4juOf2e+s/Taad9yldoCazR+/2tWc1b8ZGY3nwF+PA6br/2v/BvXuLPFMK7k47pW1w092DHwciZx/MlKFA== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB441; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB537; co1pr05mb441: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB441; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB441; x-forefront-prvs: 0645BEB7AA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(164054003)(24454002)(102836002)(2900100001)(15975445007)(86362001)(62966003)(76176999)(50986999)(54356999)(66066001)(2950100001)(2501003)(106116001)(99286002)(230783001)(77156002)(450100001)(189998001)(122556002)(40100003)(2656002)(5002640100001)(87936001)(2351001)(36756003)(92566002)(83716003)(33656002)(110136002)(46102003)(19580405001)(19580395003)(82746002)(5001960100002); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB441; H:CO1PR05MB443.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jul 2015 16:14:02.1815 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB441 X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB537; 2:B8UIGmnM+SCd72MR9yNoFaLKTalpjxOcJ4ig5ZD0QhTlrh8QUMZ8eXOzm4rv1UvW; 3:FaDyvXU8r/J/1u3L60CXBEXo0LCjbBGL3UIT8AVGMgrItxQ7aTnCTJeO2TZfEUR6Q42Tk3LrOmKD6Qzgq25KP11jnbM7IZMT8PJLdqU3MRSalgcBCc0xCGoRiRzu9FQS0iKXLl4ayZx0abQUKwQXZA==; 25:0FNDUDyDq0mqBkWS5U/KTusde2tchoe/9ikbKsMTh0862wZWZKQ9uDk5gJeu9E7l7vn0mQaKrrMjUM93tL+f7nTnNk/LShvMzJdTMSq/dx3uG9hWsCcawzrXaTlqTtJcLyY/vOA7JA0myYg1p4ezLOXlyDkvgP2NiX8KpsZjxQU1ZMAYBMFPjPOdzen9/LyUTMN4cjVG7MXYWsnvdxi0cLnMWkDrOSmqCFQmR7idmiEN2d9GVsTpq+xT3GDiiUa0ykzR6F7f8fH8BiwxZA2c6A==; 20:3TvkOLIp5sT3k5qOgYHLiEZbbnLhoNjnEMdC9rKyaYgACZUAPxOhm/WIh52Kib/DPkcH36WMG5KfFriOBLnJ1A==; 23:dtuOuHEFUsSBVmgR2ShXwHwL3Rkik8FnYF7z0XG6gnMIwqARhG0/w+uSL7ADrduWRm2edXyuJwZ00Rap/zhaH3IDnnTRKV3EmteDM2vGS1MM9k2ud73F69HKWBtp7ftyDkVDvQb4NLu6MuyNrvlKOBplRnoDuZrZvxn0/w49LByfD9SscCNRtxWOFEKAXYL03dqAcsRb5DTZ+U6t2v8HUzHgrSXwzL3wuMTTSmOJve6u2tt7ePEERmx1B594uIdn CO1PR05MB537: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: juniper.net Archived-At: Cc: "mpls@ietf.org" Subject: Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 16:14:07 -0000 support > On 22.07.2015, at 15:17, John G.Scudder wrote: >=20 > Dear WG, >=20 > As we discussed at our meeting yesterday, working group adoption has been= requested for draft-filsfils-spring-segment-routing-ldp-interop. Please re= ply to the list with your comments, including although not limited to wheth= er or not you support adoption. Non-authors are especially encouraged to co= mment. >=20 > In consideration of the fact that a number of WG calls are going on concu= rrently, we will end the call on August 31, 2015.=20 >=20 > Authors, please indicate whether you are aware of any relevant IPR and if= so, whether it has been disclosed. Also, the length of the author list for= this document greatly exceeds the maximum recommended. Assuming the docume= nt is adopted, the authors should be prepared to correct this when submitti= ng as a WG document, ideally by reducing the list to simply the active edit= or(s) and making use of the "contributors" section for the full list. >=20 > Thanks, >=20 > --Bruno and John >=20 > P.S.: Cc MPLS owing to the LDP connection. Please respect the reply-to. > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Wed Jul 22 09:15:36 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D851A21A6; Wed, 22 Jul 2015 09:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJa4xxAqQjx0; Wed, 22 Jul 2015 09:15:34 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 0400C1A8711; Wed, 22 Jul 2015 09:15:34 -0700 (PDT) Received: by oigd21 with SMTP id d21so104683383oig.1; Wed, 22 Jul 2015 09:15:33 -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:content-type:content-transfer-encoding; bh=rShHoSSQ19xjfDcaBSIPZI+FFpQdCJKDRKiTuq5pmkc=; b=D4+McbWSN9wWe/gHU3CtBNuSXPQD4Ui1SR3JZ033zuDveEgLhVtj2V1lEYYIXogcLd 34h8ER3s5GRKmw/7qogAkVLu0EQL3jATj94PotPkNb9rjIj3zwI+e/UCZbCRexDhPFAz /sHdDY36sBvCIiNFW7ehFMJqP2UGsR6BxkMX9ci9p8TJPrZc+gYsmy1B7uVHdFapjduq xaBDyT41Tyq6APLJu1ZJ82taP6BHq1cUDIiOQ20HtGsXom/WroGXOOlzXXtjQ3Tu4Flf iV7/A7kVFrYMP9a1s3fRjIIgT127Xs+BIH+nkq6q9wqqq71ZIhq4ISgb+qxJyIkX0bdb qLPg== MIME-Version: 1.0 X-Received: by 10.202.3.66 with SMTP id 63mr3148249oid.41.1437581733519; Wed, 22 Jul 2015 09:15:33 -0700 (PDT) Received: by 10.202.220.87 with HTTP; Wed, 22 Jul 2015 09:15:33 -0700 (PDT) In-Reply-To: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> References: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> Date: Wed, 22 Jul 2015 12:15:33 -0400 Message-ID: From: Mohan Nanduri To: spring@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "mpls@ietf.org" Subject: Re: [spring] [mpls] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 16:15:35 -0000 Support. Cheers, -Mohan On Wed, Jul 22, 2015 at 9:17 AM, John G.Scudder wrote: > Dear WG, > > As we discussed at our meeting yesterday, working group adoption has been= requested for draft-filsfils-spring-segment-routing-ldp-interop. Please re= ply to the list with your comments, including although not limited to wheth= er or not you support adoption. Non-authors are especially encouraged to co= mment. > > In consideration of the fact that a number of WG calls are going on concu= rrently, we will end the call on August 31, 2015. > > Authors, please indicate whether you are aware of any relevant IPR and if= so, whether it has been disclosed. Also, the length of the author list for= this document greatly exceeds the maximum recommended. Assuming the docume= nt is adopted, the authors should be prepared to correct this when submitti= ng as a WG document, ideally by reducing the list to simply the active edit= or(s) and making use of the "contributors" section for the full list. > > Thanks, > > --Bruno and John > > P.S.: Cc MPLS owing to the LDP connection. Please respect the reply-to. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Jul 22 09:41:09 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E22B21B2B81 for ; Wed, 22 Jul 2015 09:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] autolearn=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 D1p4hnS7sfZs for ; Wed, 22 Jul 2015 09:41:07 -0700 (PDT) Received: from smtpcmd02111.aruba.it (smtpcmd02111.aruba.it [62.149.158.111]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1C01B2B3A for ; Wed, 22 Jul 2015 09:39:52 -0700 (PDT) Received: from dell-tcastaldi ([31.130.224.109]) by smtpcmd02.ad.aruba.it with bizsmtp id vUfr1q00y2NEPrz01Ufsyw; Wed, 22 Jul 2015 18:39:52 +0200 Date: Wed, 22 Jul 2015 18:39:53 +0200 (CEST) From: Meetecho Team To: spring@ietf.org Message-ID: <166316070.9.1437583193320.JavaMail.tcastaldi@dell-tcastaldi> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_8_1470806841.1437583193319" Archived-At: Subject: [spring] Meetecho recordings of SPRING WG session X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 16:41:09 -0000 ------=_Part_8_1470806841.1437583193319 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, the full recording (synchronized video, audio, slides and jabber room) of the SPRING WG session at IETF 93 is available at the following URL: http://ietf93.conf.meetecho.com/index.php/Recorded_Sessions#SPRING In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. Cheers, the Meetecho Team ------=_Part_8_1470806841.1437583193319-- From nobody Wed Jul 22 09:49:02 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E800E1B2B8A; Wed, 22 Jul 2015 09:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKYkv0woIOEJ; Wed, 22 Jul 2015 09:49:00 -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 2BFAD1B2B3A; Wed, 22 Jul 2015 09:49:00 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id 2CA282DC5BB; Wed, 22 Jul 2015 18:48:58 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.58]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 1077F238055; Wed, 22 Jul 2015 18:48:58 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0235.001; Wed, 22 Jul 2015 18:48:57 +0200 From: To: "spring@ietf.org" Thread-Topic: [mpls] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop Thread-Index: AQHQxIDNTdFJ9ThbxkawgCOCcJnXyp3nsrKw Date: Wed, 22 Jul 2015 16:48:57 +0000 Message-ID: <4488_1437583738_55AFC97A_4488_3661_1_53C29892C857584299CBF5D05346208A0F5FD044@OPEXCLILM21.corporate.adroot.infra.ftgroup> References: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> In-Reply-To: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> 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: 2015.7.22.145717 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [spring] [mpls] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 16:49:02 -0000 I'm not aware of non-disclosed IPR.=20 (Support as co-author: this is needed for incremental deployment with incre= mental benefit in existing MPLS/LDP network) > -----Original Message----- > From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of John G.Scudder > Sent: Wednesday, July 22, 2015 3:17 PM > To: spring@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] working group adoption call for draft-filsfils-spring-seg= ment- > routing-ldp-interop >=20 > Dear WG, >=20 > As we discussed at our meeting yesterday, working group adoption has been > requested for draft-filsfils-spring-segment-routing-ldp-interop. Please r= eply > to the list with your comments, including although not limited to whether= or > not you support adoption. Non-authors are especially encouraged to > comment. >=20 > In consideration of the fact that a number of WG calls are going on > concurrently, we will end the call on August 31, 2015. >=20 > Authors, please indicate whether you are aware of any relevant IPR and if > so, whether it has been disclosed. Also, the length of the author list fo= r this > document greatly exceeds the maximum recommended. Assuming the > document is adopted, the authors should be prepared to correct this when > submitting as a WG document, ideally by reducing the list to simply the > active editor(s) and making use of the "contributors" section for the ful= l list. >=20 > Thanks, >=20 > --Bruno and John >=20 > P.S.: Cc MPLS owing to the LDP connection. Please respect the reply-to. > _______________________________________________ > 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 Wed Jul 22 09:54:49 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCEF01A8AF0; Wed, 22 Jul 2015 09:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCM_PPT-DOTQ; Wed, 22 Jul 2015 09:54:46 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 16E5F1A8A9A; Wed, 22 Jul 2015 09:54:46 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id 945E89C25EF0A; Wed, 22 Jul 2015 16:54:41 +0000 (GMT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6MGsemj001565 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 18:54:43 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.17]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 18:54:41 +0200 From: "Henderickx, Wim (Wim)" To: "spring@ietf.org" Thread-Topic: [mpls] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop Thread-Index: AQHQxJ8afYqbTUo1+USNIrGfFBdmuw== Date: Wed, 22 Jul 2015 16:54:41 +0000 Message-ID: References: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> In-Reply-To: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150701 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [spring] [mpls] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 16:54:48 -0000 c3VwcG9ydA0KDQoNCg0KDQpPbiAyMi8wNy8xNSAxNToxNywgIm1wbHMgb24gYmVoYWxmIG9mIEpv aG4gRy5TY3VkZGVyIiA8bXBscy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBqZ3NAanVu aXBlci5uZXQ+IHdyb3RlOg0KDQo+RGVhciBXRywNCj4NCj5BcyB3ZSBkaXNjdXNzZWQgYXQgb3Vy IG1lZXRpbmcgeWVzdGVyZGF5LCB3b3JraW5nIGdyb3VwIGFkb3B0aW9uIGhhcyBiZWVuIHJlcXVl c3RlZCBmb3IgZHJhZnQtZmlsc2ZpbHMtc3ByaW5nLXNlZ21lbnQtcm91dGluZy1sZHAtaW50ZXJv cC4gUGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0IHdpdGggeW91ciBjb21tZW50cywgaW5jbHVkaW5n IGFsdGhvdWdoIG5vdCBsaW1pdGVkIHRvIHdoZXRoZXIgb3Igbm90IHlvdSBzdXBwb3J0IGFkb3B0 aW9uLiBOb24tYXV0aG9ycyBhcmUgZXNwZWNpYWxseSBlbmNvdXJhZ2VkIHRvIGNvbW1lbnQuDQo+ DQo+SW4gY29uc2lkZXJhdGlvbiBvZiB0aGUgZmFjdCB0aGF0IGEgbnVtYmVyIG9mIFdHIGNhbGxz IGFyZSBnb2luZyBvbiBjb25jdXJyZW50bHksIHdlIHdpbGwgZW5kIHRoZSBjYWxsIG9uIEF1Z3Vz dCAzMSwgMjAxNS4gDQo+DQo+QXV0aG9ycywgcGxlYXNlIGluZGljYXRlIHdoZXRoZXIgeW91IGFy ZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSIGFuZCBpZiBzbywgd2hldGhlciBpdCBoYXMgYmVl biBkaXNjbG9zZWQuIEFsc28sIHRoZSBsZW5ndGggb2YgdGhlIGF1dGhvciBsaXN0IGZvciB0aGlz IGRvY3VtZW50IGdyZWF0bHkgZXhjZWVkcyB0aGUgbWF4aW11bSByZWNvbW1lbmRlZC4gQXNzdW1p bmcgdGhlIGRvY3VtZW50IGlzIGFkb3B0ZWQsIHRoZSBhdXRob3JzIHNob3VsZCBiZSBwcmVwYXJl ZCB0byBjb3JyZWN0IHRoaXMgd2hlbiBzdWJtaXR0aW5nIGFzIGEgV0cgZG9jdW1lbnQsIGlkZWFs bHkgYnkgcmVkdWNpbmcgdGhlIGxpc3QgdG8gc2ltcGx5IHRoZSBhY3RpdmUgZWRpdG9yKHMpIGFu ZCBtYWtpbmcgdXNlIG9mIHRoZSAiY29udHJpYnV0b3JzIiBzZWN0aW9uIGZvciB0aGUgZnVsbCBs aXN0Lg0KPg0KPlRoYW5rcywNCj4NCj4tLUJydW5vIGFuZCBKb2huDQo+DQo+UC5TLjogQ2MgTVBM UyBvd2luZyB0byB0aGUgTERQIGNvbm5lY3Rpb24uIFBsZWFzZSByZXNwZWN0IHRoZSByZXBseS10 by4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm1w bHMgbWFpbGluZyBsaXN0DQo+bXBsc0BpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscw0K From nobody Wed Jul 22 09:55:45 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D06731A1B28 for ; Wed, 22 Jul 2015 09:55:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Us81fUVgUgx8 for ; Wed, 22 Jul 2015 09:55:38 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BF711A9029 for ; Wed, 22 Jul 2015 09:55:38 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 49AC26D6DFF8E; Wed, 22 Jul 2015 16:55:33 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t6MGsaJM028403 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 18:55:33 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.17]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 18:55:04 +0200 From: "Henderickx, Wim (Wim)" To: "John G.Scudder" , "spring@ietf.org" Thread-Topic: [spring] working group adoption call for draft-filsfils-spring-segment-routing-msdc Thread-Index: AQHQxJ8nBwf4qGpGV0auhNSOPTmzpA== Date: Wed, 22 Jul 2015 16:55:03 +0000 Message-ID: <05B19F88-D4CC-465F-8766-6EE6FEAAC457@alcatel-lucent.com> References: <36F65DE7-6714-41FB-8A6B-CEB373CAC111@juniper.net> In-Reply-To: <36F65DE7-6714-41FB-8A6B-CEB373CAC111@juniper.net> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150701 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="utf-8" Content-ID: <6184A60E0DA4C74BA7A0D6A6DD2DB018@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-msdc X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 16:55:44 -0000 c3VwcG9ydA0KDQoNCg0KDQpPbiAyMi8wNy8xNSAxNToxNSwgInNwcmluZyBvbiBiZWhhbGYgb2Yg Sm9obiBHLlNjdWRkZXIiIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygamdz QGp1bmlwZXIubmV0PiB3cm90ZToNCg0KPkRlYXIgV0csDQo+DQo+QXMgd2UgZGlzY3Vzc2VkIGF0 IG91ciBtZWV0aW5nIHllc3RlcmRheSwgd29ya2luZyBncm91cCBhZG9wdGlvbiBoYXMgYmVlbiBy ZXF1ZXN0ZWQgZm9yIGRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXNkYy4g UGxlYXNlIHJlcGx5IHRvIHRoZSBsaXN0IHdpdGggeW91ciBjb21tZW50cywgaW5jbHVkaW5nIGFs dGhvdWdoIG5vdCBsaW1pdGVkIHRvIHdoZXRoZXIgb3Igbm90IHlvdSBzdXBwb3J0IGFkb3B0aW9u LiBOb24tYXV0aG9ycyBhcmUgZXNwZWNpYWxseSBlbmNvdXJhZ2VkIHRvIGNvbW1lbnQuDQo+DQo+ SW4gY29uc2lkZXJhdGlvbiBvZiB0aGUgZmFjdCB0aGF0IGEgbnVtYmVyIG9mIFdHIGNhbGxzIGFy ZSBnb2luZyBvbiBjb25jdXJyZW50bHksIHdlIHdpbGwgZW5kIHRoZSBjYWxsIG9uIEF1Z3VzdCAz MSwgMjAxNS4gDQo+DQo+QXV0aG9ycywgcGxlYXNlIGluZGljYXRlIHdoZXRoZXIgeW91IGFyZSBh d2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSIGFuZCBpZiBzbywgd2hldGhlciBpdCBoYXMgYmVlbiBk aXNjbG9zZWQuIEFsc28sIHRoZSBsZW5ndGggb2YgdGhlIGF1dGhvciBsaXN0IGZvciB0aGlzIGRv Y3VtZW50IGdyZWF0bHkgZXhjZWVkcyB0aGUgbWF4aW11bSByZWNvbW1lbmRlZC4gQXNzdW1pbmcg dGhlIGRvY3VtZW50IGlzIGFkb3B0ZWQsIHRoZSBhdXRob3JzIHNob3VsZCBiZSBwcmVwYXJlZCB0 byBjb3JyZWN0IHRoaXMgd2hlbiBzdWJtaXR0aW5nIGFzIGEgV0cgZG9jdW1lbnQsIGlkZWFsbHkg YnkgcmVkdWNpbmcgdGhlIGxpc3QgdG8gc2ltcGx5IHRoZSBhY3RpdmUgZWRpdG9yKHMpIGFuZCBt YWtpbmcgdXNlIG9mIHRoZSAiY29udHJpYnV0b3JzIiBzZWN0aW9uIGZvciB0aGUgZnVsbCBsaXN0 Lg0KPg0KPlRoYW5rcywNCj4NCj4tLUJydW5vIGFuZCBKb2huDQo+DQo+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5zcHJpbmcgbWFpbGluZyBsaXN0DQo+ c3ByaW5nQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z cHJpbmcNCg== From nobody Wed Jul 22 09:55:59 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70621B2B7B for ; Wed, 22 Jul 2015 09:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVF8Ax33hm9K for ; Wed, 22 Jul 2015 09:55:53 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 524651A1B28 for ; Wed, 22 Jul 2015 09:55:53 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id C1D8EC395DF65; Wed, 22 Jul 2015 16:55:48 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t6MGtpdX032488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 18:55:51 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.17]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 18:55:24 +0200 From: "Henderickx, Wim (Wim)" To: "John G.Scudder" , "spring@ietf.org" Thread-Topic: [spring] working group adoption call for draft-filsfils-spring-segment-routing-central-epe Thread-Index: AQHQxJ8zOKOHvlHhbEiNAYfIwjKhcA== Date: Wed, 22 Jul 2015 16:55:23 +0000 Message-ID: <04127DCD-D161-4AAE-9A35-80AEECEF2ED0@alcatel-lucent.com> References: <4B9BB879-99E2-4A96-A1A6-D05A4EAE9C3D@juniper.net> In-Reply-To: <4B9BB879-99E2-4A96-A1A6-D05A4EAE9C3D@juniper.net> Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150701 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="utf-8" Content-ID: <8259F0EB0C719E4DAF79983A48CD1B3E@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-central-epe X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 16:55:57 -0000 c3VwcG9ydA0KDQoNCg0KDQpPbiAyMi8wNy8xNSAxNToxNSwgInNwcmluZyBvbiBiZWhhbGYgb2Yg Sm9obiBHLlNjdWRkZXIiIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygamdz QGp1bmlwZXIubmV0PiB3cm90ZToNCg0KPkRlYXIgV0csDQo+DQo+QXMgd2UgZGlzY3Vzc2VkIGF0 IG91ciBtZWV0aW5nIHllc3RlcmRheSwgd29ya2luZyBncm91cCBhZG9wdGlvbiBoYXMgYmVlbiBy ZXF1ZXN0ZWQgZm9yIGRyYWZ0LWZpbHNmaWxzLXNwcmluZy1zZWdtZW50LXJvdXRpbmctY2VudHJh bC1lcGUuIFBsZWFzZSByZXBseSB0byB0aGUgbGlzdCB3aXRoIHlvdXIgY29tbWVudHMsIGluY2x1 ZGluZyBhbHRob3VnaCBub3QgbGltaXRlZCB0byB3aGV0aGVyIG9yIG5vdCB5b3Ugc3VwcG9ydCBh ZG9wdGlvbi4gTm9uLWF1dGhvcnMgYXJlIGVzcGVjaWFsbHkgZW5jb3VyYWdlZCB0byBjb21tZW50 Lg0KPg0KPkluIGNvbnNpZGVyYXRpb24gb2YgdGhlIGZhY3QgdGhhdCBhIG51bWJlciBvZiBXRyBj YWxscyBhcmUgZ29pbmcgb24gY29uY3VycmVudGx5LCB3ZSB3aWxsIGVuZCB0aGUgY2FsbCBvbiBB dWd1c3QgMzEsIDIwMTUuIA0KPg0KPkF1dGhvcnMsIHBsZWFzZSBpbmRpY2F0ZSB3aGV0aGVyIHlv dSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUiBhbmQgaWYgc28sIHdoZXRoZXIgaXQgaGFz IGJlZW4gZGlzY2xvc2VkLiBBbHNvLCB0aGUgbGVuZ3RoIG9mIHRoZSBhdXRob3IgbGlzdCBmb3Ig dGhpcyBkb2N1bWVudCBleGNlZWRzIHRoZSBtYXhpbXVtIHJlY29tbWVuZGVkLiBBc3N1bWluZyB0 aGUgZG9jdW1lbnQgaXMgYWRvcHRlZCwgdGhlIGF1dGhvcnMgc2hvdWxkIGJlIHByZXBhcmVkIHRv IGNvcnJlY3QgdGhpcyB3aGVuIHN1Ym1pdHRpbmcgYXMgYSBXRyBkb2N1bWVudCwgaWRlYWxseSBi eSByZWR1Y2luZyB0aGUgbGlzdCB0byBzaW1wbHkgdGhlIGFjdGl2ZSBlZGl0b3IocykgYW5kIG1h a2luZyB1c2Ugb2YgdGhlICJjb250cmlidXRvcnMiIHNlY3Rpb24gZm9yIHRoZSBmdWxsIGxpc3Qu DQo+DQo+VGhhbmtzLA0KPg0KPi0tQnJ1bm8gYW5kIEpvaG4NCj4NCj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPnNwcmluZyBtYWlsaW5nIGxpc3QNCj5z cHJpbmdAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Nw cmluZw0K From nobody Wed Jul 22 10:07:30 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEFDE1B2AAB; Wed, 22 Jul 2015 10:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hb0LFwT9Ctgx; Wed, 22 Jul 2015 10:07:28 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEEC21A8F46; Wed, 22 Jul 2015 10:07:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1216; q=dns/txt; s=iport; t=1437584845; x=1438794445; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=KocuAM6xyX/hvBngqX+syPHctW9ZQKrqGKD7Wwx1jRk=; b=hWbQusudSrfVfooflDlIrKTzfmwm6L+PgiuvBR/YXQ+0z2bvl0263bnv kJYYJEtPgt7kI3lHe2CuDsT82pkULzC76H9EVyu43RIi3RQBg/z1wzv4h XE6SLQBAIS5eGtFdvmoh7TZOHSjQ/WjOd4klAGeWz+Flh3kj72M2SdzJf M=; X-IronPort-AV: E=Sophos;i="5.15,524,1432598400"; d="scan'208";a="17744875" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-3.cisco.com with ESMTP; 22 Jul 2015 17:07:25 +0000 Received: from [10.24.238.223] ([10.24.238.223]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t6MH7NIO021224; Wed, 22 Jul 2015 17:07:24 GMT Message-ID: <55AFCDCB.9020905@cisco.com> Date: Wed, 22 Jul 2015 10:07:23 -0700 From: "Ahmed Bashandy (bashandy)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: spring@ietf.org References: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> In-Reply-To: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: mpls@ietf.org Subject: Re: [spring] [mpls] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 17:07:29 -0000 Support Ahmed On 7/22/2015 6:17 AM, John G.Scudder wrote: > Dear WG, > > As we discussed at our meeting yesterday, working group adoption has been requested for draft-filsfils-spring-segment-routing-ldp-interop. Please reply to the list with your comments, including although not limited to whether or not you support adoption. Non-authors are especially encouraged to comment. > > In consideration of the fact that a number of WG calls are going on concurrently, we will end the call on August 31, 2015. > > Authors, please indicate whether you are aware of any relevant IPR and if so, whether it has been disclosed. Also, the length of the author list for this document greatly exceeds the maximum recommended. Assuming the document is adopted, the authors should be prepared to correct this when submitting as a WG document, ideally by reducing the list to simply the active editor(s) and making use of the "contributors" section for the full list. > > Thanks, > > --Bruno and John > > P.S.: Cc MPLS owing to the LDP connection. Please respect the reply-to. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Jul 22 10:08:03 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A9B31A8F39 for ; Wed, 22 Jul 2015 10:08:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-kin86Ytaed for ; Wed, 22 Jul 2015 10:08:01 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C96E21A8BAF for ; Wed, 22 Jul 2015 10:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1159; q=dns/txt; s=iport; t=1437584881; x=1438794481; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=NG0bp+WRhzjrBACoc67+unyxKGwUgG4WtsRjU/O10vc=; b=SAN9mxmfes2+UjI2uB7fHjOekqVharpcCLcDS+NmF69LvpwVzOzHTNTu zO+mX8uAMe927WhjmKQ3QZsuSdqq9zz98PTODJheBbuRP2ex1PTI99Xpl 71AJ9x2JUxTa7EloTcS+2YD5/uq8EYmOx0Zhvks5X8xT2cQVO+dsF7STX w=; X-IronPort-AV: E=Sophos;i="5.15,524,1432598400"; d="scan'208";a="14004277" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-5.cisco.com with ESMTP; 22 Jul 2015 17:08:00 +0000 Received: from [10.24.238.223] ([10.24.238.223]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t6MH7wQJ004009; Wed, 22 Jul 2015 17:07:59 GMT Message-ID: <55AFCDEE.5000706@cisco.com> Date: Wed, 22 Jul 2015 10:07:58 -0700 From: "Ahmed Bashandy (bashandy)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "John G.Scudder" , spring@ietf.org References: <36F65DE7-6714-41FB-8A6B-CEB373CAC111@juniper.net> In-Reply-To: <36F65DE7-6714-41FB-8A6B-CEB373CAC111@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-msdc X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 17:08:02 -0000 strongly support Thanks Ahmed On 7/22/2015 6:15 AM, John G.Scudder wrote: > Dear WG, > > As we discussed at our meeting yesterday, working group adoption has been requested for draft-filsfils-spring-segment-routing-msdc. Please reply to the list with your comments, including although not limited to whether or not you support adoption. Non-authors are especially encouraged to comment. > > In consideration of the fact that a number of WG calls are going on concurrently, we will end the call on August 31, 2015. > > Authors, please indicate whether you are aware of any relevant IPR and if so, whether it has been disclosed. Also, the length of the author list for this document greatly exceeds the maximum recommended. Assuming the document is adopted, the authors should be prepared to correct this when submitting as a WG document, ideally by reducing the list to simply the active editor(s) and making use of the "contributors" section for the full list. > > Thanks, > > --Bruno and John > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Wed Jul 22 10:08:31 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300831B2BC7 for ; Wed, 22 Jul 2015 10:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsLzssg0--Dr for ; Wed, 22 Jul 2015 10:08:28 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74811B2BA4 for ; Wed, 22 Jul 2015 10:08:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1139; q=dns/txt; s=iport; t=1437584905; x=1438794505; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=ticX5+0zVWyOl/H2xDSApg9QhsG1hmi+ux10arvjsFs=; b=jbiuKCIEhllUtfrqQpib7QIN0JV1U/o2ZeWg4r6gZjfj1LTL54TSF9Uw zEUX3hR8F0xFMWGdpgPpsHvRUaTLEYbbc3ybUFRNHguKF1bGRfxlTdhrV oI/tXktj6vN0QdnPTqWwJm9AMWzpeMuJjHm74DJCo6KOjniOIxBa7T2b5 U=; X-IronPort-AV: E=Sophos;i="5.15,524,1432598400"; d="scan'208";a="12099722" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP; 22 Jul 2015 17:08:24 +0000 Received: from [10.24.238.223] ([10.24.238.223]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t6MH8NRQ027651; Wed, 22 Jul 2015 17:08:24 GMT Message-ID: <55AFCE06.3010000@cisco.com> Date: Wed, 22 Jul 2015 10:08:22 -0700 From: "Ahmed Bashandy (bashandy)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: spring@ietf.org References: <4B9BB879-99E2-4A96-A1A6-D05A4EAE9C3D@juniper.net> In-Reply-To: <4B9BB879-99E2-4A96-A1A6-D05A4EAE9C3D@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-central-epe X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 17:08:30 -0000 Support Ahmed On 7/22/2015 6:15 AM, John G.Scudder wrote: > Dear WG, > > As we discussed at our meeting yesterday, working group adoption has been requested for draft-filsfils-spring-segment-routing-central-epe. Please reply to the list with your comments, including although not limited to whether or not you support adoption. Non-authors are especially encouraged to comment. > > In consideration of the fact that a number of WG calls are going on concurrently, we will end the call on August 31, 2015. > > Authors, please indicate whether you are aware of any relevant IPR and if so, whether it has been disclosed. Also, the length of the author list for this document exceeds the maximum recommended. Assuming the document is adopted, the authors should be prepared to correct this when submitting as a WG document, ideally by reducing the list to simply the active editor(s) and making use of the "contributors" section for the full list. > > Thanks, > > --Bruno and John > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Wed Jul 22 10:12:44 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949F81B2A84 for ; Wed, 22 Jul 2015 10:12:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYz5yHUflAQy for ; Wed, 22 Jul 2015 10:12:41 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BF641A87CE for ; Wed, 22 Jul 2015 10:12:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=828; q=dns/txt; s=iport; t=1437585161; x=1438794761; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=QjcnP041Zp+Qyspo02oxQbOE3YCtn/hSoKxuJG9PK4I=; b=NBAAxor0YKuKGsYNtONV8FQfZ5aQxlr2oyr48IwakdC9B658JxoFhEqZ SfafjpuFgmiPp1BKJETv4wberRKaqXlpkzAcj7s4NForb0YLtBVGE81Kj FQVq+ucaJGcvSYH6nP0FmD+IKfAKNGIgfoZtsuKFzRiVgVIoKlBUdGpPd M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AeAwC+zq9V/4YNJK1bgxVUaQa7dwmBawqFN0oCgU44FAEBAQEBAQGBCoQkAQEEAQEBGh00HQEINjcLJQIEARKILg3NZgEBAQEBAQEDAQEBAQEBAQEWBItMhC1ghCsFkV6CeQGMMYFDhB2PUYNhJoN8b4EEQ4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,524,1432598400"; d="scan'208";a="171371980" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 22 Jul 2015 17:12:38 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t6MHCbPO026749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 17:12:37 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.176]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 12:12:37 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: "John G. Scudder" , "spring@ietf.org" Thread-Topic: [spring] working group adoption call for draft-geib-spring-oam-usecase Thread-Index: AQHQxKGbQJbK60jFS0SNqFBzMOeWMw== Date: Wed, 22 Jul 2015 17:12:36 +0000 Message-ID: In-Reply-To: <80969761-1128-4D14-A142-BFF4C9CF1998@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.244.22] Content-Type: text/plain; charset="us-ascii" Content-ID: <60072D07F739924289BA287664342D1B@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] working group adoption call for draft-geib-spring-oam-usecase X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 17:12:42 -0000 Support. Thanks, Nagendra On 7/22/15, 9:13 AM, "John G. Scudder" wrote: >Dear WG, > >As we discussed at our meeting yesterday, working group adoption has been >requested for draft-geib-spring-oam-usecase. Please reply to the list >with your comments, including although not limited to whether or not you >support adoption. Non-authors are especially encouraged to comment. > >In consideration of the fact that a number of WG calls are going on >concurrently, we will end the call on August 31, 2015. > >Authors, please indicate whether you are aware of any relevant IPR and if >so, whether it has been disclosed. > >Thanks, > >--Bruno and John > >_______________________________________________ >spring mailing list >spring@ietf.org >https://www.ietf.org/mailman/listinfo/spring From nobody Wed Jul 22 10:12:58 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 188C51B2BA4 for ; Wed, 22 Jul 2015 10:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xs6hL2IJk8Iw for ; Wed, 22 Jul 2015 10:12:51 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8BE61A8711 for ; Wed, 22 Jul 2015 10:12:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1184; q=dns/txt; s=iport; t=1437585171; x=1438794771; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=i4xlTFWgfMYw5VJjegddn63xnB736M6Mtpxu3FA9pFk=; b=lFz0/fo2H7LhsvPYhu5fbReZRdSUW+N9sVDIGiA0zTqp1hc3B6yZJxv5 GTS3sR7dWYKWa0eaiH2nDCMCNJUBVSPNQnE8bQZ6aG0A6ptAvL42fjpwj r/OVRzm1fvyTs2lr+McjTkE6NfY2o8nCK10SVH1u2J7CJgUYd5l7FDtXB M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0D/BAAHzq9V/5BdJa1bgxVUaQa8AIFrCoU3SgKBTjkTAQEBAQEBAYEKhCQBAQQBAQEaHTQdAQg2NwslAgQBEoguDc1jAQEBAQEBAQMBAQEBAQEBARYEi0yELWCEKwWRXoJ5AYwxgUOEHY9Rg2Emgj6BPm+BBEOBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,524,1432598400"; d="scan'208";a="171252407" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-8.cisco.com with ESMTP; 22 Jul 2015 17:12:51 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t6MHCo4S027417 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 17:12:50 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.176]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 12:12:50 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: "John G.Scudder" , "spring@ietf.org" Thread-Topic: [spring] working group adoption call for draft-filsfils-spring-segment-routing-central-epe Thread-Index: AQHQxIB7DWFKZh2mkUaW8uLz2l4Dw53nyvoA Date: Wed, 22 Jul 2015 17:12:50 +0000 Message-ID: In-Reply-To: <4B9BB879-99E2-4A96-A1A6-D05A4EAE9C3D@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.244.22] Content-Type: text/plain; charset="us-ascii" Content-ID: <63A9B77E70343B4FBCAC22341D68B49F@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-central-epe X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 17:12:53 -0000 Support. Thans, Nagendra On 7/22/15, 9:15 AM, "John G.Scudder" wrote: >Dear WG, > >As we discussed at our meeting yesterday, working group adoption has been >requested for draft-filsfils-spring-segment-routing-central-epe. Please >reply to the list with your comments, including although not limited to >whether or not you support adoption. Non-authors are especially >encouraged to comment. > >In consideration of the fact that a number of WG calls are going on >concurrently, we will end the call on August 31, 2015. > >Authors, please indicate whether you are aware of any relevant IPR and if >so, whether it has been disclosed. Also, the length of the author list >for this document exceeds the maximum recommended. Assuming the document >is adopted, the authors should be prepared to correct this when >submitting as a WG document, ideally by reducing the list to simply the >active editor(s) and making use of the "contributors" section for the >full list. > >Thanks, > >--Bruno and John > >_______________________________________________ >spring mailing list >spring@ietf.org >https://www.ietf.org/mailman/listinfo/spring From nobody Wed Jul 22 10:13:12 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CB21A8953 for ; Wed, 22 Jul 2015 10:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FJHJKFYgpzOH for ; Wed, 22 Jul 2015 10:13:08 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C62B71B2BA3 for ; Wed, 22 Jul 2015 10:13:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1186; q=dns/txt; s=iport; t=1437585188; x=1438794788; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=qEgk7naTKolCRJEPXgTW7MVXZowYFmvdsc8F3eO6z5c=; b=gpoECfzakRRV2x3PVyOkXTqY0/PGPgsPiA7fCZyY6VQDhx7TmGvDzsZ7 BqBYFpXphrI0/unm5XtvnNYhsa6FQNKQkUn6MCcx+ugqnJ//xZr6h4RG/ fMarfKpFgIC2FKNrSbXPORe8sPkufRAvU0r9cJpLPRhDrDqRntcARpQcM I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AeAwDtzq9V/4kNJK1bgxVUaQa7dwmBawqFN0oCgU44FAEBAQEBAQGBCoQkAQEEAQEBGh00HQEINjcLJQIEARKILg3NaQEBAQEBAQEDAQEBAQEBAQEWBItMhC1ghCsFkV6CeQGMMYFDhB2PUYNhJoI+gT5vgQRDgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,524,1432598400"; d="scan'208";a="12104698" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-7.cisco.com with ESMTP; 22 Jul 2015 17:13:08 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t6MHD8mV031169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 17:13:08 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.176]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 12:13:08 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: "John G.Scudder" , "spring@ietf.org" Thread-Topic: [spring] working group adoption call for draft-filsfils-spring-segment-routing-msdc Thread-Index: AQHQxICrdHyTbhOfzk2vqVXXI549J53nywMA Date: Wed, 22 Jul 2015 17:13:06 +0000 Message-ID: In-Reply-To: <36F65DE7-6714-41FB-8A6B-CEB373CAC111@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.244.22] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-msdc X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 17:13:10 -0000 Support. Thanks, Nagendra On 7/22/15, 9:15 AM, "John G.Scudder" wrote: >Dear WG, > >As we discussed at our meeting yesterday, working group adoption has been >requested for draft-filsfils-spring-segment-routing-msdc. Please reply to >the list with your comments, including although not limited to whether or >not you support adoption. Non-authors are especially encouraged to >comment. > >In consideration of the fact that a number of WG calls are going on >concurrently, we will end the call on August 31, 2015. > >Authors, please indicate whether you are aware of any relevant IPR and if >so, whether it has been disclosed. Also, the length of the author list >for this document greatly exceeds the maximum recommended. Assuming the >document is adopted, the authors should be prepared to correct this when >submitting as a WG document, ideally by reducing the list to simply the >active editor(s) and making use of the "contributors" section for the >full list. > >Thanks, > >--Bruno and John > >_______________________________________________ >spring mailing list >spring@ietf.org >https://www.ietf.org/mailman/listinfo/spring From nobody Wed Jul 22 10:13:23 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B471B2BD2; Wed, 22 Jul 2015 10:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YB7xTiCYd4Ah; Wed, 22 Jul 2015 10:13:18 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4531A8F3E; Wed, 22 Jul 2015 10:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1261; q=dns/txt; s=iport; t=1437585197; x=1438794797; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=Y7EeUZlXqNPuBVc2LlesZGkJMVbe9vyxi8rjla/muP0=; b=N/7kOAXYxV2x9Ou8U37MG3RkoNZm7OQe6IeD2Q2H404a77Noih89bsZG ybEhh7k8qzXlZFyTlZcdNLUtgKWCTXKvBj+VRwor1JamEld0pzp7Mrjj8 v1QjM8jMCki7mF8sKlcGBpHLovAXddIjn7N+CKAfkFo58PflQu2CRmWo6 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AeAwCmzq9V/5ldJa1bgxVUaQa7dwmBawqGAQKBTjgUAQEBAQEBAX8LhCQBAQQBAQEaHTQLEgEINjcLJQIEDgWILg3NZwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0yELVkHhCsFkV6CeQGMMYFDhB2PUYNhJoI+gT5vgQRDgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,524,1432598400"; d="scan'208";a="12100531" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP; 22 Jul 2015 17:13:17 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t6MHDHHI002919 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 17:13:17 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.176]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 12:13:17 -0500 From: "Nagendra Kumar Nainar (naikumar)" To: "spring@ietf.org" Thread-Topic: [mpls] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop Thread-Index: AQHQxIDNzuh0dlTwRESZF1Rih2twMJ3nyw8A Date: Wed, 22 Jul 2015 17:13:16 +0000 Message-ID: In-Reply-To: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.8.130913 x-originating-ip: [10.82.244.22] Content-Type: text/plain; charset="us-ascii" Content-ID: <5893D52F5A06F041A6FF93F25FE006FA@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [spring] [mpls] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 17:13:21 -0000 Support. Thanks, Nagendra On 7/22/15, 9:17 AM, "John G.Scudder" wrote: >Dear WG, > >As we discussed at our meeting yesterday, working group adoption has been >requested for draft-filsfils-spring-segment-routing-ldp-interop. Please >reply to the list with your comments, including although not limited to >whether or not you support adoption. Non-authors are especially >encouraged to comment. > >In consideration of the fact that a number of WG calls are going on >concurrently, we will end the call on August 31, 2015. > >Authors, please indicate whether you are aware of any relevant IPR and if >so, whether it has been disclosed. Also, the length of the author list >for this document greatly exceeds the maximum recommended. Assuming the >document is adopted, the authors should be prepared to correct this when >submitting as a WG document, ideally by reducing the list to simply the >active editor(s) and making use of the "contributors" section for the >full list. > >Thanks, > >--Bruno and John > >P.S.: Cc MPLS owing to the LDP connection. Please respect the reply-to. >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From nobody Wed Jul 22 10:20:36 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4B51B2C04 for ; Wed, 22 Jul 2015 10:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jmmv1-rjU1uD for ; Wed, 22 Jul 2015 10:20:24 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C7221B2A9E for ; Wed, 22 Jul 2015 10:20:06 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id EA206374646 for ; Wed, 22 Jul 2015 19:20:00 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.61]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id BF11C38404E for ; Wed, 22 Jul 2015 19:20:00 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0235.001; Wed, 22 Jul 2015 19:19:59 +0200 From: To: "spring@ietf.org" Thread-Topic: Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AdDEofPBdRxCKpYlQ2+dXaGzxZCXiA== Date: Wed, 22 Jul 2015 17:19:59 +0000 Message-ID: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: multipart/related; boundary="_004_9E32478DFA9976438E7A22F69B08FF92166A3D14OPEXCLILMA4corp_"; type="multipart/alternative" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.22.161517 Archived-At: Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 17:20:34 -0000 --_004_9E32478DFA9976438E7A22F69B08FF92166A3D14OPEXCLILMA4corp_ Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92166A3D14OPEXCLILMA4corp_" --_000_9E32478DFA9976438E7A22F69B08FF92166A3D14OPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi WG, In the current version of the config Yang model for SR, the SRGB list is co= nfigured at SR top level, so it is agnostic to the routing protocol. We had some comment in Dallas on difficulties that having common label rang= e shared between protocols could lead to. During discussion in our design team, some point was also raised on routing= protocol migrations that may be safer using a per protocol SRGB (so config= uration the SRGB at IGP level rather than globally). We would like to hear from the WG about the preference and arguments for bo= th approaches : Approach 1) keep SRGB configuration at top level, and so routing protocols = will share the same label space (today proposal) Approach 2) move SRGB configuration to protocols, each routing protocol man= ages its own label space. Thanks to provide your feedback in order to solve this issue and have a con= sensus. [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 mobile: +33 6 37 86 97 52 stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ 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_9E32478DFA9976438E7A22F69B08FF92166A3D14OPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi WG,

 

In the current version of the config Yang model for = SR, the SRGB list is configured at SR top level, so it is agnostic to the r= outing protocol.

We had some comment in Dallas on difficulties that h= aving common label range shared between protocols could lead to.=

During discussion in our design team, some point was= also raised on routing protocol migrations that may be safer using a per p= rotocol SRGB (so configuration the SRGB at IGP level rather than globally).=

 

We would like to hear from the WG about the preferen= ce and arguments for both approaches :

Approach 1) keep SRGB configuration at top level, an= d so routing protocols will share the same label space (today proposal)

Approach 2) move SRGB configuration to protocols, ea= ch routing protocol manages its own label space.

 

Thanks to provide your feedback in order to solve th= is issue and have a consensus.

 

 

3D"O=

 <= o:p>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE

Orange Expert Fut= ure Networks

phone: +33 2 23 28 49 83
mobile: +33 6 37 86 97 52
stephane.litkowski@orange.com

 

 

______________________________________________________________________=
___________________________________________________

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_9E32478DFA9976438E7A22F69B08FF92166A3D14OPEXCLILMA4corp_-- --_004_9E32478DFA9976438E7A22F69B08FF92166A3D14OPEXCLILMA4corp_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=381; creation-date="Wed, 22 Jul 2015 17:19:59 GMT"; modification-date="Wed, 22 Jul 2015 17:19:59 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhKAAoAMQAAP+MQP+zgP/17//s3/+DMP/iz/+fYP+8j/9wEP95IP/Gn/+WUP/Pr/+pcP/Z v/////9mAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAoACgAAAX6oAONZGmeaEqKauum7Cu/8Wyj9a2P+X73vhkwSCPuhkYVMolj2pbOEjTK oxatrSlVG+U6vUxwUmwkE81BtE99xGbdSjhMPgo4BAoA+wUICAR6IwQODwMNEAcOigAFhQYQDgoD DwcQBJOKBIOFDQmaCCyTB416hQcBBQuTEA8Cow8EBQINpHcGhAkrEAkPChAAD3YPCLuSDw+sIgEP wCILzK0OjY9VBJS/wYQjfwaNyRDLzRAG0AMB5wC6ENyEt8jWDAsCyA/KzJN+zLILqLlVv/OuaYPU alU9cMwuPSCl8AEDYv8EQbwRgAEABcziJFl2bMmeEQgATEwRAgA7 --_004_9E32478DFA9976438E7A22F69B08FF92166A3D14OPEXCLILMA4corp_-- From nobody Wed Jul 22 10:37:48 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9C31B2BF3; Wed, 22 Jul 2015 10:37:46 -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, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VlX4Q0LQfuU; Wed, 22 Jul 2015 10:37:44 -0700 (PDT) Received: from estafeta21.imdea.org (maquina46.madrimasd.org [193.145.15.46]) (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 2946C1B2C26; Wed, 22 Jul 2015 10:37:43 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by estafeta21.imdea.org (imdea mail daemon) with ESMTP id 8010B1B46C2; Wed, 22 Jul 2015 19:35:32 +0200 (CEST) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta21.imdea.org ([127.0.0.1]) by localhost (estafeta21.imdea.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXc-pciJgkIw; Wed, 22 Jul 2015 19:35:32 +0200 (CEST) Received: from ams3-vpn-dhcp7537.cisco.com (unknown [173.38.220.62]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pierre.francois) by estafeta21.imdea.org (imdea mail daemon) with ESMTPSA id F03421B46C1; Wed, 22 Jul 2015 19:35:31 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CF3DA9A0-FCC5-4A9D-92BE-590A99063D6A"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Pierre Francois In-Reply-To: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> Date: Wed, 22 Jul 2015 19:37:39 +0200 Message-Id: References: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> To: spring@ietf.org X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: mpls@ietf.org Subject: Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 17:37:46 -0000 --Apple-Mail=_CF3DA9A0-FCC5-4A9D-92BE-590A99063D6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Support. Pierre. > On 22 Jul 2015, at 15:17, John G.Scudder wrote: >=20 > Dear WG, >=20 > As we discussed at our meeting yesterday, working group adoption has = been requested for draft-filsfils-spring-segment-routing-ldp-interop. = Please reply to the list with your comments, including although not = limited to whether or not you support adoption. Non-authors are = especially encouraged to comment. >=20 > In consideration of the fact that a number of WG calls are going on = concurrently, we will end the call on August 31, 2015. >=20 > Authors, please indicate whether you are aware of any relevant IPR and = if so, whether it has been disclosed. Also, the length of the author = list for this document greatly exceeds the maximum recommended. Assuming = the document is adopted, the authors should be prepared to correct this = when submitting as a WG document, ideally by reducing the list to simply = the active editor(s) and making use of the "contributors" section for = the full list. >=20 > Thanks, >=20 > --Bruno and John >=20 > P.S.: Cc MPLS owing to the LDP connection. Please respect the = reply-to. > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring --Apple-Mail=_CF3DA9A0-FCC5-4A9D-92BE-590A99063D6A 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 iQIcBAEBCgAGBQJVr9TjAAoJEFVsgKhDmVUFMlAP/3b4a4P9t/ixEW6Fhq9nEaFD gnw2vWuK4tXR1r+s0X2kv5hQp3TVJXXfjeGXyq7ThNWBHegBNrr/3a55q1iUKb3y Itm4ZtT9QWyTUnqNZgPlD2ZKD3tSEWC+Tjh85Qqoz8MHg98Gzs/PSlMP+INRoE2O HXSOZoczpmbkM4zqRoI8BYvNvFi0nJlDrW0Cd63ogC413NOOWyINBJucdblqb8m8 gCrrcltv39+BjH/hC/u42aBctXKL0760vUCjYt/6x1eOoVhVVxWAD9EVtjMFnarP eVXZ3JIplq4BDfZPOhCpw1c90biDxgwF6T6ALmS41Zww/qCyykNmiRPYOV0J0cDM TLfhf8BAmoB72PU4XebOkUaFGbC5pTx7qHKxRQrzxquhIuPfzp3kZp/3xphqkOiV IrpNmLJPbX6P0r5saAEq4ZDij+9Dh5KJu4ZE2nxdk457bJgZUVCx+Mj+UKDp1CRG mOf3XipIw6UfF2wfaqg8iaw0EU+7aXO9f6NMqKuz7N9fLCcFOFPG2pi6e7Rx5kbf 5awX+A/2bJN7cK6tbC8Dixgn7Qx2bFkJc9OUgc1kVci6DtK2hYmzIiqVk0+npsOn M7STXse+sdRomSnxFpFV8Eb+bNpCJ/Mzdzw7AwMEGhyM6Xu0viNg2pX7Be2rKJXs e/zF/DjIjsBQZc9de233 =SgKf -----END PGP SIGNATURE----- --Apple-Mail=_CF3DA9A0-FCC5-4A9D-92BE-590A99063D6A-- From nobody Wed Jul 22 11:16:32 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8421A1BA9; Wed, 22 Jul 2015 11:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0avdR7DdnhGQ; Wed, 22 Jul 2015 11:16:28 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF9A1A1F04; Wed, 22 Jul 2015 11:16:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1158; q=dns/txt; s=iport; t=1437588986; x=1438798586; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8ST/dThqJRmIegvV+JNIPza3gkfe/yWMzMLp+suq810=; b=Di04gHKehuFATg+ljpHlUc0mUgH9FeX1cT5UNJIT1jPN1Oe87inihyCh KrwDJUcLhzq2Dk+7EYFXWMUQYijaKW12ySHQmYB+h3kxITrVaeiZMrDla hfFT8AOcmFoahVOhf2L/9a7ecDr50Ub0aFry0LPZBxnEFoA6rrni8Kj/Z Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AfAwAR3a9V/5FdJa1bgxVUaQatFY5iCYFrCoU3SgKBUDgUAQEBAQEBAYEKhCMBAQEDAQEBARodNAsQAgEIGB4QJwslAgQOBYgmCA3NYwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0yCFIIZJjMHgxeBFAWUVwGMMYFDhB2PUYNhJoN8b4EEQ4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,524,1432598400"; d="scan'208";a="171322495" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-4.cisco.com with ESMTP; 22 Jul 2015 18:16:25 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t6MIGOW7008946 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 18:16:24 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.72]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 13:16:24 -0500 From: "Stefano Previdi (sprevidi)" To: "" Thread-Topic: [spring] working group last call for draft-ietf-spring-segment-routing Thread-Index: AQHQxIAshL2DLlg120aA/7I81Ib0yp3oH+CA Date: Wed, 22 Jul 2015 18:16:23 +0000 Message-ID: <4CC5C40F-7C17-4117-A9EA-8FB32408E8FC@cisco.com> References: <52A3B956-E9BD-4503-9DDD-D40314B93509@juniper.net> In-Reply-To: <52A3B956-E9BD-4503-9DDD-D40314B93509@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.67.209] Content-Type: text/plain; charset="us-ascii" Content-ID: <6A17946B7468AB4C9EF036173A0967B3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" , "<6man@ietf.org>" <6man@ietf.org>, "" , "" Subject: Re: [spring] working group last call for draft-ietf-spring-segment-routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 18:16:29 -0000 On Jul 22, 2015, at 3:12 PM, John G. Scudder wrote: > Dear SPRING WG (and cc MPLS, OSPF, IS-IS, 6MAN, please include SPRING in = replies per the reply-to): >=20 > As we discussed at the SPRING meeting yesterday, working group last call = has been requested for draft-ietf-spring-segment-routing. Please reply to t= he list with your comments, including although not limited to whether or no= t you support advancing the document to RFC. Non-authors are especially enc= ouraged to comment. >=20 > In consideration of the fact that a number of WG calls are going on concu= rrently, we will end the call on August 31, 2015.=20 >=20 > Authors, please indicate whether you are aware of any relevant IPR and if= so, whether it has been disclosed. (Please do this even if you've done it = before, thanks for your help.) as co-author I confirm IPR has been already disclosed for draft-ietf-spring= -segment-routing. thanks. s. >=20 > Thanks, >=20 > --Bruno and John >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Wed Jul 22 11:17:10 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC6D1A6F0A for ; Wed, 22 Jul 2015 11:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUQPi88vyxRf for ; Wed, 22 Jul 2015 11:17:07 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F65E1A6EE1 for ; Wed, 22 Jul 2015 11:16:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=857; q=dns/txt; s=iport; t=1437589014; x=1438798614; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+k8oq0JVi72MgzK3e3wPKLYCuCJchBOtZtw9/CsKe5I=; b=dEh1AI/AKLPPf72YmCVa+iBL8FWcjX2ZeYBUkhhckF3m3DFI9cyEbP4o cH2jhx6Zk7WiaSSrDhVmD/SWCJWGgCrb3wB29mI3UvPDmYSRD2W/P/yHu lx/5SX62dWUvmAzjfQXwiG6c5NxIvKHIpAfAeJkbQbpV4qbrBGRrdfCJY E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AeAwB33a9V/4QNJK1bgxVUaQa7dwmBawqFN0oCgVA4FAEBAQEBAQGBCoQkAQEDAQEBARodNAsFCwIBCDYQJwslAgQOBYgmCA3NZQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0yELSYzB4MXgRQFkV6CeQGMMYFDhB2PUYNhJoN8b4EEQ4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,524,1432598400"; d="scan'208";a="14023927" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-5.cisco.com with ESMTP; 22 Jul 2015 18:16:54 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t6MIGqTW001522 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 18:16:52 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.72]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 13:16:52 -0500 From: "Stefano Previdi (sprevidi)" To: "John G. Scudder" Thread-Topic: [spring] working group adoption call for draft-geib-spring-oam-usecase Thread-Index: AQHQxIBZbD9/6PrcR0ejzs4ANIrzsJ3oIAQA Date: Wed, 22 Jul 2015 18:16:51 +0000 Message-ID: <45B5DC17-4DD4-4604-A19B-CBE2B742626D@cisco.com> References: <80969761-1128-4D14-A142-BFF4C9CF1998@juniper.net> In-Reply-To: <80969761-1128-4D14-A142-BFF4C9CF1998@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.67.209] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [spring] working group adoption call for draft-geib-spring-oam-usecase X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 18:17:09 -0000 support. s. On Jul 22, 2015, at 3:13 PM, John G. Scudder wrote: > Dear WG, >=20 > As we discussed at our meeting yesterday, working group adoption has been= requested for draft-geib-spring-oam-usecase. Please reply to the list with= your comments, including although not limited to whether or not you suppor= t adoption. Non-authors are especially encouraged to comment. >=20 > In consideration of the fact that a number of WG calls are going on concu= rrently, we will end the call on August 31, 2015.=20 >=20 > Authors, please indicate whether you are aware of any relevant IPR and if= so, whether it has been disclosed. >=20 > Thanks, >=20 > --Bruno and John >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Wed Jul 22 11:19:16 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAAD1A00EA for ; Wed, 22 Jul 2015 11:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjraXmUB42N5 for ; Wed, 22 Jul 2015 11:19:13 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AEF51A1F04 for ; Wed, 22 Jul 2015 11:19:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1352; q=dns/txt; s=iport; t=1437589149; x=1438798749; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Sjl6HD7hopTevnCljVV7HEFBPHFi06knKV/ZZBKOA2A=; b=C3d+YffblCznSLnYO+9Rh0DC1JxIwk5xSPI8D48rVbBc2yYLtdUeylJm TRpWztNUBzseOdENoB8bVgRU0JMyg0ZoqmEpS6yDcyBAOIsCMUhzKEAzK ZqL923P92iqUHvLHcj3vMFBZnFJ+9FEG+aKR+Q0PJoIUwrJKL/aQIe6P9 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AeAwB33a9V/5hdJa1bgxVUaQa7dwmBawqFN0oCgVA4FAEBAQEBAQGBCoQkAQEDAQEBARodNAsFCwIBCDYQJwslAgQOBYgmCA3NZQEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0yELSYzB4MXgRQFlFcBjDGBQ4Qdj1GDYSaCPoE+b4EEQ4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,524,1432598400"; d="scan'208";a="12119934" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 22 Jul 2015 18:19:08 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t6MIJ8MV014288 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 18:19:08 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.72]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 13:19:08 -0500 From: "Stefano Previdi (sprevidi)" To: "John G.Scudder" Thread-Topic: [spring] working group adoption call for draft-filsfils-spring-segment-routing-central-epe Thread-Index: AQHQxIB7xNgM/6tbd027nzLHeQ4X1J3oIKQA Date: Wed, 22 Jul 2015 18:19:07 +0000 Message-ID: <5D866628-714F-4973-A3DF-FAEAA4FDD67E@cisco.com> References: <4B9BB879-99E2-4A96-A1A6-D05A4EAE9C3D@juniper.net> In-Reply-To: <4B9BB879-99E2-4A96-A1A6-D05A4EAE9C3D@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.67.209] Content-Type: text/plain; charset="us-ascii" Content-ID: <5D351C22CB01584C8F17AF8930F87C11@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-central-epe X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 18:19:15 -0000 as co-author: . I support the adoption of this draft as WG item . I confirm IPR has been already disclosed for this document thanks. s. On Jul 22, 2015, at 3:15 PM, John G.Scudder wrote: > Dear WG, >=20 > As we discussed at our meeting yesterday, working group adoption has been= requested for draft-filsfils-spring-segment-routing-central-epe. Please re= ply to the list with your comments, including although not limited to wheth= er or not you support adoption. Non-authors are especially encouraged to co= mment. >=20 > In consideration of the fact that a number of WG calls are going on concu= rrently, we will end the call on August 31, 2015.=20 >=20 > Authors, please indicate whether you are aware of any relevant IPR and if= so, whether it has been disclosed. Also, the length of the author list for= this document exceeds the maximum recommended. Assuming the document is ad= opted, the authors should be prepared to correct this when submitting as a = WG document, ideally by reducing the list to simply the active editor(s) an= d making use of the "contributors" section for the full list. >=20 > Thanks, >=20 > --Bruno and John >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Wed Jul 22 11:22:17 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7E41A6FF8 for ; Wed, 22 Jul 2015 11:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uzaQ08CPULmQ for ; Wed, 22 Jul 2015 11:22:15 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E46451A6FEC for ; Wed, 22 Jul 2015 11:22:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1317; q=dns/txt; s=iport; t=1437589335; x=1438798935; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=wGi1dMZ/CwDWnOcvRUdNNskBj+P51csq1V2IjZ8lYYM=; b=IIZRyet6IT464ikGJmaHXeSPvuS0l0TvLdyW4EoQ3GKkPdTVKs6ldJXf bhOX2ZwxzYTiIZJOS6v/7ULa2AYB72VEcbMa0opcoiM86xgI3mUKORis/ BHAEgdTIuFBm/8nR7s76oDdtcpBvrqzVZO6qSlpcj40AHIX4VQslXWU4Y g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AeAwD23a9V/4ENJK1bgxVUaQa7dwmBawqFN0oCgVA4FAEBAQEBAQGBCoQkAQEEAQEBGh00CxACAQgYHhAnCyUCBA4FiC4NzWcBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItMhC0mMweDF4EUBZRXAYwxgUOEHY9Rg2Emgj6BPm+BBEOBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,524,1432598400"; d="scan'208";a="17766061" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-3.cisco.com with ESMTP; 22 Jul 2015 18:22:14 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t6MIMEqV001922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 18:22:14 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.72]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 13:22:13 -0500 From: "Stefano Previdi (sprevidi)" To: "John G.Scudder" Thread-Topic: [spring] working group adoption call for draft-filsfils-spring-segment-routing-msdc Thread-Index: AQHQxICrLMmJI+74gEeXvE78TVJXPZ3oIYCA Date: Wed, 22 Jul 2015 18:22:13 +0000 Message-ID: <9E5CC715-940A-473E-B0DB-854166DE08F5@cisco.com> References: <36F65DE7-6714-41FB-8A6B-CEB373CAC111@juniper.net> In-Reply-To: <36F65DE7-6714-41FB-8A6B-CEB373CAC111@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.67.209] Content-Type: text/plain; charset="us-ascii" Content-ID: <4E75F21AAC28B7459CF6ECB06F16FB45@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-msdc X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 18:22:16 -0000 As co-author I support the adoption of this document as WG item and I'm not= aware of any IPR related to it. s. On Jul 22, 2015, at 3:15 PM, John G.Scudder wrote: > Dear WG, >=20 > As we discussed at our meeting yesterday, working group adoption has been= requested for draft-filsfils-spring-segment-routing-msdc. Please reply to = the list with your comments, including although not limited to whether or n= ot you support adoption. Non-authors are especially encouraged to comment. >=20 > In consideration of the fact that a number of WG calls are going on concu= rrently, we will end the call on August 31, 2015.=20 >=20 > Authors, please indicate whether you are aware of any relevant IPR and if= so, whether it has been disclosed. Also, the length of the author list for= this document greatly exceeds the maximum recommended. Assuming the docume= nt is adopted, the authors should be prepared to correct this when submitti= ng as a WG document, ideally by reducing the list to simply the active edit= or(s) and making use of the "contributors" section for the full list. >=20 > Thanks, >=20 > --Bruno and John >=20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Wed Jul 22 11:23:16 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFDA1A6FFC; Wed, 22 Jul 2015 11:23:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPq-sSY3XZCp; Wed, 22 Jul 2015 11:23:14 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1FFD1A6FF8; Wed, 22 Jul 2015 11:23:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1400; q=dns/txt; s=iport; t=1437589394; x=1438798994; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=piGwHbl0TcCKf0wWcnOa8DFg5sAPjZJKzO4Lqjjoo58=; b=dOcKokQYmpPtsMXr+pEPgtKpqtmTBNZhP28MdgZBmxJoYiY7sgonGWPE cJoRo7s9SO2uUPb55wa4dT/Ap972cemUbVAbl2JifdVA7PSftRRag0SkI Bij0nRtEN1a0cVWnRrmY2qV+9JX7yAPV/FTUF8CIfL5QLrcmDV3w71rbk o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AfAwBX369V/51dJa1bgxVUaQatFY5iCYFrCoU3SgKBUDgUAQEBAQEBAYEKhCQBAQMBAQEBGh00CwULAgEINhAnCyUCBA4FiCYIDc1mAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLTIIUghkmMweDF4EUBZRXAYwxgUOEHY9Rg2Emgj6BPm+BBEOBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,524,1432598400"; d="scan'208";a="17766291" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 22 Jul 2015 18:23:13 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t6MINC8Q000531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 18:23:13 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.72]) by xhc-rcd-x04.cisco.com ([173.37.183.78]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 13:23:12 -0500 From: "Stefano Previdi (sprevidi)" To: "" Thread-Topic: [spring] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop Thread-Index: AQHQxIDUd+/Z9XL+f0y5z0gZK+F93p3oIceA Date: Wed, 22 Jul 2015 18:23:12 +0000 Message-ID: <09960928-4ABD-4AA5-98DC-6DD7E79CD0B5@cisco.com> References: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> In-Reply-To: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.67.209] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 18:23:15 -0000 as co-author I support the adoption of this draft a WG item and I confirm I= PR has been already disclosed. s. On Jul 22, 2015, at 3:17 PM, John G.Scudder wrote: > Dear WG, >=20 > As we discussed at our meeting yesterday, working group adoption has been= requested for draft-filsfils-spring-segment-routing-ldp-interop. Please re= ply to the list with your comments, including although not limited to wheth= er or not you support adoption. Non-authors are especially encouraged to co= mment. >=20 > In consideration of the fact that a number of WG calls are going on concu= rrently, we will end the call on August 31, 2015.=20 >=20 > Authors, please indicate whether you are aware of any relevant IPR and if= so, whether it has been disclosed. Also, the length of the author list for= this document greatly exceeds the maximum recommended. Assuming the docume= nt is adopted, the authors should be prepared to correct this when submitti= ng as a WG document, ideally by reducing the list to simply the active edit= or(s) and making use of the "contributors" section for the full list. >=20 > Thanks, >=20 > --Bruno and John >=20 > P.S.: Cc MPLS owing to the LDP connection. Please respect the reply-to. > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Wed Jul 22 13:46:51 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9D81B2DA5 for ; Wed, 22 Jul 2015 13:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dq9jgq0FCemB for ; Wed, 22 Jul 2015 13:46:48 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 336041B2E50 for ; Wed, 22 Jul 2015 13:45:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1613; q=dns/txt; s=iport; t=1437597926; x=1438807526; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=hSGETSMPgsuTzr9uHYz/euQDJCLDyphSB8yM9TxLm+U=; b=fWg8z+3N6uFo5VvGqbgpyR9AZqYkvkin3/VB+VR2MU2jDB8LJ+cuj5GD vw/XQq6HWPqCGavMaey3l8XVH55p0YuBtMrtOKE4vGFbIsv3rNbRfeoLu cBNQ0batTXo6UtXg9m3ji3spIv6mas05KFMvz3e9L1nmqI7MnmDMxeLy6 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgAwD6/69V/4sNJK1bgxVUaQa7dwmBawqFN0oCgVc4FAEBAQEBAQF/C4QjAQEBBAEBARodNBcEAgEIEQQBAQEKFAkHJwsUCQgCBBMIiCYNzXoBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItMhC0oOAaDEYEUBZRXAY10hB2PUYNhJoI+gT5vgQRDgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,525,1432598400"; d="scan'208";a="171269732" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP; 22 Jul 2015 20:45:25 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t6MKjPMp005498 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 22 Jul 2015 20:45:25 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.72]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 15:45:25 -0500 From: "Roberta Maglione (robmgl)" To: "spring@ietf.org" Thread-Topic: [spring] working group adoption call for draft-filsfils-spring-segment-routing-central-epe Thread-Index: AQHQxIB7T+uaP5X7Bk+x4D1XK0JGCp3oDNcA///oq3A= Date: Wed, 22 Jul 2015 20:45:24 +0000 Message-ID: <57C3345230A4F94C9B2F5CFA05D7F2BD26096C2F@xmb-rcd-x01.cisco.com> References: <4B9BB879-99E2-4A96-A1A6-D05A4EAE9C3D@juniper.net> <55AFCE06.3010000@cisco.com> In-Reply-To: <55AFCE06.3010000@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.93.142] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-central-epe X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 20:46:50 -0000 Support. Roberta -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Ahmed Bashandy (= bashandy) Sent: Wednesday, July 22, 2015 7:08 PM To: spring@ietf.org Subject: Re: [spring] working group adoption call for draft-filsfils-spring= -segment-routing-central-epe Support Ahmed On 7/22/2015 6:15 AM, John G.Scudder wrote: > Dear WG, > > As we discussed at our meeting yesterday, working group adoption has been= requested for draft-filsfils-spring-segment-routing-central-epe. Please re= ply to the list with your comments, including although not limited to wheth= er or not you support adoption. Non-authors are especially encouraged to co= mment. > > In consideration of the fact that a number of WG calls are going on concu= rrently, we will end the call on August 31, 2015. > > Authors, please indicate whether you are aware of any relevant IPR and if= so, whether it has been disclosed. Also, the length of the author list for= this document exceeds the maximum recommended. Assuming the document is ad= opted, the authors should be prepared to correct this when submitting as a = WG document, ideally by reducing the list to simply the active editor(s) an= d making use of the "contributors" section for the full list. > > Thanks, > > --Bruno and John > > _______________________________________________ > 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 Wed Jul 22 13:47:06 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBFE61B2BD7 for ; Wed, 22 Jul 2015 13:47:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nudrRwkzbad9 for ; Wed, 22 Jul 2015 13:47:00 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC0821B2CEB for ; Wed, 22 Jul 2015 13:46:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1639; q=dns/txt; s=iport; t=1437597991; x=1438807591; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AFesIODTdAxDKjeNKRUFhQGtcc+LxL1AyvQxKE/s6gs=; b=eCejBnU+ptzBDmpBkqaQXcw1a5UV03IFw8RFQVQWDNRPB3M6SpmCvNDi +X2caGexl/ud0CZyd2EPujiKbPJHELt6OlDPxvbI8EVvFQn/crDUYfb63 jN3Ah8Ovt4ez/0kSKIS4cY5v0csDqK4kM+orqbRmxkNDQJa4+7t8Fp65f E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgAwCrALBV/4UNJK1bgxVUaQa7dwmBawqFN0oCgVc4FAEBAQEBAQF/C4QjAQEBBAEBARodNAsMBAIBCBEEAQEBChQJBycLFAkIAgQOBQiIJg3NewEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi0yELSgxBwaDEYEUBZRXAY10hB2PUYNhJoI+gT5vgQRDgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,525,1432598400"; d="scan'208";a="171266173" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-7.cisco.com with ESMTP; 22 Jul 2015 20:46:31 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t6MKkVCR004707 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 20:46:31 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.72]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 15:46:30 -0500 From: "Roberta Maglione (robmgl)" To: "spring@ietf.org" Thread-Topic: [spring] working group adoption call for draft-filsfils-spring-segment-routing-msdc Thread-Index: AQHQxICrOwJthWG38UiLcLA0/4YuSJ3oDLoA///pIQA= Date: Wed, 22 Jul 2015 20:46:30 +0000 Message-ID: <57C3345230A4F94C9B2F5CFA05D7F2BD26096C3B@xmb-rcd-x01.cisco.com> References: <36F65DE7-6714-41FB-8A6B-CEB373CAC111@juniper.net> <55AFCDEE.5000706@cisco.com> In-Reply-To: <55AFCDEE.5000706@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.93.142] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "John G.Scudder" Subject: Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-msdc X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 20:47:02 -0000 Support. Roberta -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Ahmed Bashandy (= bashandy) Sent: Wednesday, July 22, 2015 7:08 PM To: John G.Scudder; spring@ietf.org Subject: Re: [spring] working group adoption call for draft-filsfils-spring= -segment-routing-msdc strongly support Thanks Ahmed On 7/22/2015 6:15 AM, John G.Scudder wrote: > Dear WG, > > As we discussed at our meeting yesterday, working group adoption has been= requested for draft-filsfils-spring-segment-routing-msdc. Please reply to = the list with your comments, including although not limited to whether or n= ot you support adoption. Non-authors are especially encouraged to comment. > > In consideration of the fact that a number of WG calls are going on concu= rrently, we will end the call on August 31, 2015. > > Authors, please indicate whether you are aware of any relevant IPR and if= so, whether it has been disclosed. Also, the length of the author list for= this document greatly exceeds the maximum recommended. Assuming the docume= nt is adopted, the authors should be prepared to correct this when submitti= ng as a WG document, ideally by reducing the list to simply the active edit= or(s) and making use of the "contributors" section for the full list. > > Thanks, > > --Bruno and John > > _______________________________________________ > 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 Wed Jul 22 14:55:47 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD381B2F50 for ; Wed, 22 Jul 2015 14:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSt8wq_NG-pw for ; Wed, 22 Jul 2015 14:55:43 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45DAA1B2F67 for ; Wed, 22 Jul 2015 14:55:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1345; q=dns/txt; s=iport; t=1437602128; x=1438811728; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=QEl1Q8ZuvS/8mJhmAZFQPvoB/+RoMd/d8ZJBqgCvwJE=; b=LyoXNheAbeY5ESDVXOAQF74jXofmZTOR5UlvUiHA1tmH+F0HoGMFk3xG on4CDLnos7fG0riF9CmL/secfPVy5M3QhCXViEI8m8kG2lwuM7IPpSITZ CZ5eomIxRjGbSLSfV6s5ToT4A40nyD/AxeCNi4Ngl1EYnJ8ifXhxKXEte M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AfAwCRELBV/5JdJa1bgxVUaQa7eAmBawqFN0oCgVs4FAEBAQEBAQGBCoQjAQEBBAEBARodNBcEAgEIEQQBAQsUCQcnCxQJCAIEARIIiCYNzVYBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItMhC0oOAaDEYEUBZRXAY10hB2DEIxBg2Emg3xvgQRDgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,525,1432598400"; d="scan'208";a="171289958" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by alln-iport-6.cisco.com with ESMTP; 22 Jul 2015 21:55:27 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t6MLtPWu031063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 22 Jul 2015 21:55:25 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.72]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0195.001; Wed, 22 Jul 2015 16:55:25 -0500 From: "Roberta Maglione (robmgl)" To: "John G. Scudder" , "spring@ietf.org" Thread-Topic: [spring] working group adoption call for draft-geib-spring-oam-usecase Thread-Index: AQHQxIBZ8F+baj63R0OCE2Ak030aL53oBj3A Date: Wed, 22 Jul 2015 21:55:24 +0000 Message-ID: <57C3345230A4F94C9B2F5CFA05D7F2BD26096CD8@xmb-rcd-x01.cisco.com> References: <80969761-1128-4D14-A142-BFF4C9CF1998@juniper.net> In-Reply-To: <80969761-1128-4D14-A142-BFF4C9CF1998@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.93.142] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [spring] working group adoption call for draft-geib-spring-oam-usecase X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 22 Jul 2015 21:55:45 -0000 Hello, I read the document and I support its adoption as WG item. I have just few editorial comments: - I would suggest adding a terminology section to list new acronyms (like P= MS) introduced in this document; - in section 1 where you mention ISIS as label distribution protocol for SR= , I would suggest adding a reference to OSPF as well. Thanks Roberta=20 -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of John G. Scudder Sent: Wednesday, July 22, 2015 3:14 PM To: spring@ietf.org Subject: [spring] working group adoption call for draft-geib-spring-oam-use= case Dear WG, As we discussed at our meeting yesterday, working group adoption has been r= equested for draft-geib-spring-oam-usecase. Please reply to the list with y= our comments, including although not limited to whether or not you support = adoption. Non-authors are especially encouraged to comment. In consideration of the fact that a number of WG calls are going on concurr= ently, we will end the call on August 31, 2015.=20 Authors, please indicate whether you are aware of any relevant IPR and if s= o, whether it has been disclosed. Thanks, --Bruno and John _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring From nobody Wed Jul 22 23:34:00 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAF9C1A87ED; Wed, 22 Jul 2015 23:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MdcSuqeO0vj0; Wed, 22 Jul 2015 23:33:56 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B11D51A87E8; Wed, 22 Jul 2015 23:33:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1715; q=dns/txt; s=iport; t=1437633235; x=1438842835; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LFpYcIn0zUfGBrBiJyfVhcPa05dN1UdOtTDtE/oyMyI=; b=V2RAHZsFTQ1dMpf808cauxWJrEJI/rzXBd4d1CpBrQdQQL+Ds3kzFwzZ 3yM+aZkWIHF7R9PyaxUl6DD5HbAhdnTRHPkTBeAlNrjaJb2scNEVf/U0T 3nWDFA7I4fdLdluYGWH3wJ8XOoEul5Cw6XRBpS+j7u6ZX5hiGnKxlymke I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgAwBpirBV/4gNJK1bgxVUaQa7QgmBawqFN0oCgVA4FAEBAQEBAQF/C4QjAQEBBAEBARodNAsMBAIBCBEEAQEBChQFBAcnCxQJCAIEDgUIiCYNzGsBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItMhC0oMQcGgxGBFAWUXAGNd4Qdj1eDYSaCPoE+b4EEQ4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,528,1432598400"; d="scan'208";a="171516743" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-5.cisco.com with ESMTP; 23 Jul 2015 06:33:47 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t6N6XktK025552 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jul 2015 06:33:46 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.72]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Thu, 23 Jul 2015 01:33:46 -0500 From: "Roberta Maglione (robmgl)" To: "spring@ietf.org" Thread-Topic: [spring] [mpls] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop Thread-Index: AQHQxIDL/ujrvcWFSUmrmByBxDJ8Ep3oDJCAgACNQ7A= Date: Thu, 23 Jul 2015 06:33:46 +0000 Message-ID: <57C3345230A4F94C9B2F5CFA05D7F2BD2609770B@xmb-rcd-x01.cisco.com> References: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> <55AFCDCB.9020905@cisco.com> In-Reply-To: <55AFCDCB.9020905@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.93.142] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [spring] [mpls] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2015 06:33:58 -0000 Support Roberta -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Ahmed Bashandy (= bashandy) Sent: Wednesday, July 22, 2015 7:07 PM To: spring@ietf.org Cc: mpls@ietf.org Subject: Re: [spring] [mpls] working group adoption call for draft-filsfils= -spring-segment-routing-ldp-interop Support Ahmed On 7/22/2015 6:17 AM, John G.Scudder wrote: > Dear WG, > > As we discussed at our meeting yesterday, working group adoption has been= requested for draft-filsfils-spring-segment-routing-ldp-interop. Please re= ply to the list with your comments, including although not limited to wheth= er or not you support adoption. Non-authors are especially encouraged to co= mment. > > In consideration of the fact that a number of WG calls are going on concu= rrently, we will end the call on August 31, 2015. > > Authors, please indicate whether you are aware of any relevant IPR and if= so, whether it has been disclosed. Also, the length of the author list for= this document greatly exceeds the maximum recommended. Assuming the docume= nt is adopted, the authors should be prepared to correct this when submitti= ng as a WG document, ideally by reducing the list to simply the active edit= or(s) and making use of the "contributors" section for the full list. > > Thanks, > > --Bruno and John > > P.S.: Cc MPLS owing to the LDP connection. Please respect the reply-to. > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring From nobody Thu Jul 23 00:58:25 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F7C1A8A77; Thu, 23 Jul 2015 00:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3bhBnFr69yxQ; Thu, 23 Jul 2015 00:58:07 -0700 (PDT) Received: from cappuccino.rob.sh (cappuccino.rob.sh [IPv6:2a03:9800:10:4c::cafe:b00c]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B0181A8A55; Thu, 23 Jul 2015 00:58:06 -0700 (PDT) Received: from [109.144.254.21] (helo=corretto.local) by cappuccino.rob.sh with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1ZIBO7-000255-Qs; Thu, 23 Jul 2015 08:57:55 +0100 Date: Thu, 23 Jul 2015 08:58:02 +0100 From: Rob Shakir To: "John G. Scudder" , spring@ietf.org Message-ID: In-Reply-To: <52A3B956-E9BD-4503-9DDD-D40314B93509@juniper.net> References: <52A3B956-E9BD-4503-9DDD-D40314B93509@juniper.net> X-Mailer: Airmail (303) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="55b09e8a_22de06fe_17e" Archived-At: Cc: ospf@ietf.org, isis@ietf.org, 6man@ietf.org, mpls@ietf.org Subject: Re: [spring] working group last call for draft-ietf-spring-segment-routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2015 07:58:15 -0000 --55b09e8a_22de06fe_17e Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi Bruno, John, Whilst I=E2=80=99m an author =E2=80=94 I=E2=80=99ll still comment here. I= t would be good to see the SPRING WG finalise this document. Rapid progre= ss is being made to multi-vendor implementations within live networks of = the SPRING technology. It would be good to start getting documents such a= s this one - which underpins many of the other standards for SR published= . On 22 July 2015 at 14:13:06, John G. Scudder (jgs=40juniper.net) wrote: Authors, please indicate whether you are aware of any relevant IPR and if= so, whether it has been disclosed. (Please do this even if you've done i= t before, thanks for your help.)=C2=A0 I=E2=80=99m not aware of IPR other than that which has already been discl= osed on this document. Cheers=21 r. --55b09e8a_22de06fe_17e Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

Hi Stephane and all,

The SRGB in the case of MPLS data plane i= s a dedicated label range to be assigned for global segments. So, it is par= t of label management on a router. Implementations already allow configuring the label range and assigning specific blocks for static= LSPs and other applications. Segment routing is yet another application an= d as such the SRGB should just be configured where the label management on = the router is configured. I do not see it being configured under segment routing.

 

Having said that, I think implementations= can still partition the global label sub-range assigned to the SRGB among = multiple IGP instances and manage the collisions.

 

Regards,

Mustapha.

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of stephane.litkowski@orange.com
Sent: Wednesday, July 22, 2015 1:20 PM
To: spring@ietf.org
Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-= sr-yang

 

Hi WG,

 

In the current version of the config Yang model for = SR, the SRGB list is configured at SR top level, so it is agnostic to the r= outing protocol.

We had some comment in Dallas on difficulties that h= aving common label range shared between protocols could lead to.=

During discussion in our design team, some point was= also raised on routing protocol migrations that may be safer using a per p= rotocol SRGB (so configuration the SRGB at IGP level rather than globally).=

 

We would like to hear from the WG about the preferen= ce and arguments for both approaches :

Approach 1) keep SRGB configuration at top level, an= d so routing protocols will share the same label space (today proposal)

Approach 2) move SRGB configuration to protocols, ea= ch routing protocol manages its own label space.

 

Thanks to provide your feedback in order to solve th= is issue and have a consensus.

 

 

3D"Orange

 <= o:p>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE

Orange Expert Fut= ure Networks

phone: +33 2 23 28 49 83
mobile: +33 6 37 86 97 52
stephane.litkowski@orange.com

 

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
--_000_4A79394211F1AF4EB57D998426C9340DD4734660US70UWXCHMBA01z_-- --_004_4A79394211F1AF4EB57D998426C9340DD4734660US70UWXCHMBA01z_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=381; creation-date="Thu, 23 Jul 2015 17:41:30 GMT"; modification-date="Thu, 23 Jul 2015 17:41:30 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhKAAoAMQAAP+MQP+zgP/17//s3/+DMP/iz/+fYP+8j/9wEP95IP/Gn/+WUP/Pr/+pcP/Z v/////9mAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAoACgAAAX6oAONZGmeaEqKauum7Cu/8Wyj9a2P+X73vhkwSCPuhkYVMolj2pbOEjTK oxatrSlVG+U6vUxwUmwkE81BtE99xGbdSjhMPgo4BAoA+wUICAR6IwQODwMNEAcOigAFhQYQDgoD DwcQBJOKBIOFDQmaCCyTB416hQcBBQuTEA8Cow8EBQINpHcGhAkrEAkPChAAD3YPCLuSDw+sIgEP wCILzK0OjY9VBJS/wYQjfwaNyRDLzRAG0AMB5wC6ENyEt8jWDAsCyA/KzJN+zLILqLlVv/OuaYPU alU9cMwuPSCl8AEDYv8EQbwRgAEABcziJFl2bMmeEQgATEwRAgA7 --_004_4A79394211F1AF4EB57D998426C9340DD4734660US70UWXCHMBA01z_-- From nobody Thu Jul 23 10:56:38 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE861B2A31 for ; Thu, 23 Jul 2015 10:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PqIFch-8pwX1 for ; Thu, 23 Jul 2015 10:56:33 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.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 E64321B2A3A for ; Thu, 23 Jul 2015 10:56:32 -0700 (PDT) X-AuditID: c618062d-f799e6d00000329e-96-55b0ced87f82 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F3.69.12958.8DEC0B55; Thu, 23 Jul 2015 13:24:08 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.03.0210.002; Thu, 23 Jul 2015 13:56:25 -0400 From: Uma Chunduri To: "Aissaoui, Mustapha (Mustapha)" , "stephane.litkowski@orange.com" , "spring@ietf.org" Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQxW7W7UQaSb3Ur0my0GoCc8g+MZ3pViOw Date: Thu, 23 Jul 2015 17:56:24 +0000 Message-ID: <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/related; boundary="_004_1B502206DFA0C544B7A6046915200863512A6019eusaamb105erics_"; type="multipart/alternative" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKIsWRmVeSWpSXmKPExsUyuXRPoO6NcxtCDS4v0bZombeOyeL4hd+M Fl/3PmR1YPZofbaX1WPJkp9MHi3PTrIFMEdx2aSk5mSWpRbp2yVwZRxpfspScGwWY0XLKo4G xo+djF2MnBwSAiYS/2dNZYewxSQu3FvP1sXIxSEkcJRRYuePX8wQznJGiWPvT7CBVLEJ6El8 nPqTHSQhIrCFUaL/+G+wdmGBQImD97cygdgiAkESl2asZ4SwjSQWzF4IZrMIqEocPLuVGcTm FfCV+DJ1LdS624wS71dNYAFJcArEStxeM40VxGYEuun7qTVgQ5kFxCVuPZnPBHGriMTDi6fZ IGxRiZeP/7FC2EoSk5aeYwUZyizQzSjx/E4LC8Q2QYmTM5+wTGAUmYVk1ixkdbOQ1EEU5Ut8 uNXLBmHrSCzY/QnK1pZYtvA1M4x95sBjJkxxHYnNl3ZCzVGUaOucDbVsCaPEjvszWWCKlvye yQ5TNKX7IfsCRt5VjBylxalluelGBpsYgfF+TIJNdwfjnpeWhxgFOBiVeHgThDaECrEmlhVX 5h5ilOZgURLndYzKCxUSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAqNnQ+vHJmttcdZO2i7Jd 1t0e+THbpKXmytRJR45sdprOYPj41M+uVxXX78VxMF4pbC4/cncGw/m8e5Yvf8+bwpv8Zll/ mZb3gZlNvzSLFPS+P2iQdrZbs1HtEc+M4HfTZvqanfmeHR5uYn4646JPTsYsfVYmQbcLKhOt Z7t8+zvH5gyL2I6+WCWW4oxEQy3mouJEAE0X6STYAgAA Archived-At: Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2015 17:56:36 -0000 --_004_1B502206DFA0C544B7A6046915200863512A6019eusaamb105erics_ Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A6046915200863512A6019eusaamb105erics_" --_000_1B502206DFA0C544B7A6046915200863512A6019eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >I do not see it being configured under segment routing. Precisely. >Having said that, I think implementations can still partition the global l= abel sub-range assigned to the SRGB among multiple IGP instances and manage= the collisions. And that is what would be advertised in the respective routing area/domain = through respective protocol mechanisms (a.k.a capability TLVs). -- Uma C. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Aissaoui, Mustap= ha (Mustapha) Sent: Thursday, July 23, 2015 10:42 AM To: stephane.litkowski@orange.com; spring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi Stephane and all, The SRGB in the case of MPLS data plane is a dedicated label range to be as= signed for global segments. So, it is part of label management on a router.= Implementations already allow configuring the label range and assigning sp= ecific blocks for static LSPs and other applications. Segment routing is ye= t another application and as such the SRGB should just be configured where = the label management on the router is configured. I do not see it being con= figured under segment routing. Having said that, I think implementations can still partition the global la= bel sub-range assigned to the SRGB among multiple IGP instances and manage = the collisions. Regards, Mustapha. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of stephane.litkows= ki@orange.com Sent: Wednesday, July 22, 2015 1:20 PM To: spring@ietf.org Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi WG, In the current version of the config Yang model for SR, the SRGB list is co= nfigured at SR top level, so it is agnostic to the routing protocol. We had some comment in Dallas on difficulties that having common label rang= e shared between protocols could lead to. During discussion in our design team, some point was also raised on routing= protocol migrations that may be safer using a per protocol SRGB (so config= uration the SRGB at IGP level rather than globally). We would like to hear from the WG about the preference and arguments for bo= th approaches : Approach 1) keep SRGB configuration at top level, and so routing protocols = will share the same label space (today proposal) Approach 2) move SRGB configuration to protocols, each routing protocol man= ages its own label space. Thanks to provide your feedback in order to solve this issue and have a con= sensus. [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 mobile: +33 6 37 86 97 52 stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ 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_1B502206DFA0C544B7A6046915200863512A6019eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>I do not see it being configured unde= r segment routing.

 

Precisely.<= /span>

 

>Having said that, I think implementat= ions can still partition the global label sub-range assigned to the SRGB am= ong multiple IGP instances and manage the collisions.

 

And that is what would= be advertised in the respective routing area/domain through respective pro= tocol mechanisms (a.k.a capability TLVs).

 

--

Uma C.

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Aissaoui, Mustapha (Mustapha)
Sent: Thursday, July 23, 2015 10:42 AM
To: stephane.litkowski@orange.com; spring@ietf.org
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

 

Hi Stephane and all,

The SRGB in the case of MPLS data plane i= s a dedicated label range to be assigned for global segments. So, it is par= t of label management on a router. Implementations already allow configuring the label range and assigning specific blocks for static= LSPs and other applications. Segment routing is yet another application an= d as such the SRGB should just be configured where the label management on = the router is configured. I do not see it being configured under segment routing.

 

Having said that, I think implementations= can still partition the global label sub-range assigned to the SRGB among = multiple IGP instances and manage the collisions.

 

Regards,

Mustapha.

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of stepha= ne.litkowski@orange.com
Sent: Wednesday, July 22, 2015 1:20 PM
To: spring@ietf.org
Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-= sr-yang

 

Hi WG,

 

In the current version of the config Yang model for = SR, the SRGB list is configured at SR top level, so it is agnostic to the r= outing protocol.

We had some comment in Dallas on difficulties that h= aving common label range shared between protocols could lead to.=

During discussion in our design team, some point was= also raised on routing protocol migrations that may be safer using a per p= rotocol SRGB (so configuration the SRGB at IGP level rather than globally).=

 

We would like to hear from the WG about the preferen= ce and arguments for both approaches :

Approach 1) keep SRGB configuration at top level, an= d so routing protocols will share the same label space (today proposal)

Approach 2) move SRGB configuration to protocols, ea= ch routing protocol manages its own label space.

 

Thanks to provide your feedback in order to solve th= is issue and have a consensus.

 

 

3D"Orange

 <= o:p>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE

Orange Expert Fut= ure Networks

phone: +33 2 23 28 49 83
mobile: +33 6 37 86 97 52
stephane.litkowski@orange.com

 

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
--_000_1B502206DFA0C544B7A6046915200863512A6019eusaamb105erics_-- --_004_1B502206DFA0C544B7A6046915200863512A6019eusaamb105erics_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=381; creation-date="Thu, 23 Jul 2015 17:56:23 GMT"; modification-date="Thu, 23 Jul 2015 17:56:23 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhKAAoAMQAAP+MQP+zgP/17//s3/+DMP/iz/+fYP+8j/9wEP95IP/Gn/+WUP/Pr/+pcP/Z v/////9mAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAoACgAAAX6oAONZGmeaEqKauum7Cu/8Wyj9a2P+X73vhkwSCPuhkYVMolj2pbOEjTK oxatrSlVG+U6vUxwUmwkE81BtE99xGbdSjhMPgo4BAoA+wUICAR6IwQODwMNEAcOigAFhQYQDgoD DwcQBJOKBIOFDQmaCCyTB416hQcBBQuTEA8Cow8EBQINpHcGhAkrEAkPChAAD3YPCLuSDw+sIgEP wCILzK0OjY9VBJS/wYQjfwaNyRDLzRAG0AMB5wC6ENyEt8jWDAsCyA/KzJN+zLILqLlVv/OuaYPU alU9cMwuPSCl8AEDYv8EQbwRgAEABcziJFl2bMmeEQgATEwRAgA7 --_004_1B502206DFA0C544B7A6046915200863512A6019eusaamb105erics_-- From nobody Thu Jul 23 11:01:12 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4601ACEC5 for ; Thu, 23 Jul 2015 11:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.587 X-Spam-Level: X-Spam-Status: No, score=0.587 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=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 46-z1BlpFkVU for ; Thu, 23 Jul 2015 11:01:10 -0700 (PDT) Received: from mail-wi0-f194.google.com (mail-wi0-f194.google.com [209.85.212.194]) (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 AA9071A8963 for ; Thu, 23 Jul 2015 11:01:09 -0700 (PDT) Received: by wijp15 with SMTP id p15so556301wij.0 for ; Thu, 23 Jul 2015 11:01:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=zfY2/JC8sk6HdFUKqEHT4cYE0w69NfwCMOu4xFaQV1E=; b=ccrfADSNug5Z9lhUmi8sFFLbnSNxh/xvI5RQk+490eVCaaJOsUnnZY8xEy84DQdiKA CCYsOt+LFTB6Tn1r8LR2JtEATvR5i5aHRZv/8/AeSZletgiIyH9QGX0H8UnqsEzUtQlZ I3grEsh3rviedK1+xzaUtZ2+P52VS1NTseAIZ/zPexGVp7KNagy+aPeo9jndGzHCP2Zd plgbmuEpIZtflYxZwB9NvlM/WEQnvsK/B4t+nDBA/ZVLeyTy/mD1n4xGgf7O5tBi/6LU Xzgl53tKmG8UUxjtXhfZ6iZXSg+ndiTLrykpxfaiGiQeEEOZEQ3hu22NpNoVSuho/ZCT uRMw== X-Gm-Message-State: ALoCoQnN7AxALJr/5Qgwurq5JIOYJuBwP2fcnOXZf3Xt47NPRoYPhwFRtZkTaR5GHocUN+4iyGHy MIME-Version: 1.0 X-Received: by 10.194.112.3 with SMTP id im3mr18334893wjb.54.1437674468369; Thu, 23 Jul 2015 11:01:08 -0700 (PDT) Received: by 10.27.7.11 with HTTP; Thu, 23 Jul 2015 11:01:08 -0700 (PDT) X-Originating-IP: [162.208.80.1] Date: Thu, 23 Jul 2015 14:01:08 -0400 Message-ID: From: Ida Leung To: spring@ietf.org Content-Type: multipart/alternative; boundary=001a1130ce22fd7e07051b8eab5c Archived-At: Subject: [spring] working group last call for : draft-ietf-spring-segment-routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2015 18:01:10 -0000 --001a1130ce22fd7e07051b8eab5c Content-Type: text/plain; charset=UTF-8 Support. ...Ida --001a1130ce22fd7e07051b8eab5c Content-Type: text/html; charset=UTF-8
Support.

...Ida
--001a1130ce22fd7e07051b8eab5c-- From nobody Thu Jul 23 11:01:51 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438E41B2A6D for ; Thu, 23 Jul 2015 11:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, TVD_SPACE_RATIO=0.001] autolearn=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 gY3CW1_AC9_5 for ; Thu, 23 Jul 2015 11:01:49 -0700 (PDT) Received: from mail-wi0-f196.google.com (mail-wi0-f196.google.com [209.85.212.196]) (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 62D4D1B2A6C for ; Thu, 23 Jul 2015 11:01:49 -0700 (PDT) Received: by wilm20 with SMTP id m20so544364wil.2 for ; Thu, 23 Jul 2015 11:01:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=jFMzqeFil+FfufHzZlFIZnqK4zq/LlWIlwFUc+D7aC8=; b=a1YAKSRUf3DnuNBj61ZcLWPjBPMUZdh6IfRmeEbR++M5vRYyo8C2n1eng6BbhQZywz za66C04rLkt3yNFratQnyESC+eI7CbhpeexpHS9pp6znEyNmVBUsx4k+qIe/NysZwcZP O9KgYQdXEvgMbdVDtxAN+Y1Zq9qnPagKaKJYRZkxRgnIFlgJZSEPz8MzT+sh55RfZC1t oMiLw4f7fsmsRndWSAtp6aqy8fl5mkd5I2jL6Z6rB/13REHZ7H8SOiDk4btmnO9VBcFT WUgGpiCLFnK2rmQ0gjY07I7MbzQCHhzb138yWIU9QQfOkMcbXfv/cHN7/X/2k0I3Lf1C 7hNA== X-Gm-Message-State: ALoCoQnOXLSgz/p1jW509oXiHchpyCca2dUS1HzLlCxxWyOGc+CDvuVfViwipi+xhexOtlo+ftPv MIME-Version: 1.0 X-Received: by 10.194.23.194 with SMTP id o2mr18963397wjf.63.1437674508063; Thu, 23 Jul 2015 11:01:48 -0700 (PDT) Received: by 10.27.7.11 with HTTP; Thu, 23 Jul 2015 11:01:48 -0700 (PDT) X-Originating-IP: [162.208.80.1] Date: Thu, 23 Jul 2015 14:01:48 -0400 Message-ID: From: Ida Leung To: spring@ietf.org Content-Type: multipart/alternative; boundary=047d7b5d2c585b3739051b8eae27 Archived-At: Subject: [spring] working group adoption call for : draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2015 18:01:50 -0000 --047d7b5d2c585b3739051b8eae27 Content-Type: text/plain; charset=UTF-8 Support ...Ida --047d7b5d2c585b3739051b8eae27 Content-Type: text/html; charset=UTF-8
Support


...Ida
--047d7b5d2c585b3739051b8eae27-- From nobody Thu Jul 23 11:02:38 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 901C41B2A80 for ; Thu, 23 Jul 2015 11:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.311 X-Spam-Level: X-Spam-Status: No, score=-1.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, TVD_SPACE_RATIO=0.001] autolearn=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 svR_Nhi3j0X9 for ; Thu, 23 Jul 2015 11:02:32 -0700 (PDT) Received: from mail-wi0-f196.google.com (mail-wi0-f196.google.com [209.85.212.196]) (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 B7D831B2A79 for ; Thu, 23 Jul 2015 11:02:31 -0700 (PDT) Received: by wilm20 with SMTP id m20so547054wil.2 for ; Thu, 23 Jul 2015 11:02:30 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=80ZHACGB760vGl90W7+DnXOngjKMrw1fqNNUp+xq0dA=; b=h+MdEAjlsDyXRvZwS2TTVQSm0ulczhHAcl58W+NKht/I7XXlFEi+Nd4cFQVF5Skj6P c+/kEHaJPidZSKz+jmR/Rs9WfeenYdiP/z6vwSGmiNpI8F3hHxFDFBgvrhiSc0VRgJXY o4knYvpyynQcgdASTs/YQkntSw4u51RoaCjWNOVmzQRBLLqj4QklEWs9gZCJx71u+G2x h3QPN+cC+Cdm9/UcEUFjDiwrmpO8vsS2UxyPoVDL1ywzWZZarZ8xRxDPkATBUNdI5/C1 sACGkll6n6HenVVTYKoKur6kken1SghQHR3ZoCM4pG/T8B8G4pNbEvIo7AotTFoqq3Jr rJtA== X-Gm-Message-State: ALoCoQk2nHMHvXs3GsOLett8eBaRlnMij1ikl7Y51t1eghQk7tRPsW1ZYEUSRzr76Qx72QZYnmdr MIME-Version: 1.0 X-Received: by 10.180.94.39 with SMTP id cz7mr30816452wib.17.1437674550507; Thu, 23 Jul 2015 11:02:30 -0700 (PDT) Received: by 10.27.7.11 with HTTP; Thu, 23 Jul 2015 11:02:30 -0700 (PDT) X-Originating-IP: [162.208.80.1] Date: Thu, 23 Jul 2015 14:02:30 -0400 Message-ID: From: Ida Leung To: spring@ietf.org Content-Type: multipart/alternative; boundary=f46d04426de6e2c951051b8eb0ab Archived-At: Subject: [spring] working group adoption call for draft-geib-spring-oam-usecase X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2015 18:02:32 -0000 --f46d04426de6e2c951051b8eb0ab Content-Type: text/plain; charset=UTF-8 Support ...Ida --f46d04426de6e2c951051b8eb0ab Content-Type: text/html; charset=UTF-8
Support


...Ida
--f46d04426de6e2c951051b8eb0ab-- From nobody Thu Jul 23 11:16:25 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFD4A1B2ACA for ; Thu, 23 Jul 2015 11:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPv0wKQl2NDs for ; Thu, 23 Jul 2015 11:16:21 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0113.outbound.protection.outlook.com [207.46.100.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54B011B2A1F for ; Thu, 23 Jul 2015 11:16:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YVVlHCL3KPwXTTzva3ZLN5hwBL+qPNlO7gFvkK0sD7k=; b=j2DNlZBTSisF6jEV6SygGQ8BQgKwEqB4Ynpk3IgkO5LqCS1ZBUAjUXV7hcn9sN1ojowKwul9/Yi8VPu4k6ZNN3MQovO7UKZw9WdNvG3J5FKfMIBqV1XPOnckmIxmnzxkwglZOOZyl2GJYDsK22sYz+DShfwNlw+ZsRmX9Ig0au4= Received: from BY2PR03MB457.namprd03.prod.outlook.com (10.141.141.141) by BY2PR03MB459.namprd03.prod.outlook.com (10.141.141.147) with Microsoft SMTP Server (TLS) id 15.1.213.10; Thu, 23 Jul 2015 18:16:19 +0000 Received: from BY2PR03MB457.namprd03.prod.outlook.com ([10.141.141.141]) by BY2PR03MB457.namprd03.prod.outlook.com ([10.141.141.141]) with mapi id 15.01.0213.021; Thu, 23 Jul 2015 18:16:19 +0000 From: Tim LaBerge To: "spring@ietf.org" Thread-Topic: [spring] working group last call for draft-ietf-spring-segment-routing Thread-Index: AQHQxIAq0BlOV6RiqkG724IJhJMo3Z3pXkLQ Date: Thu, 23 Jul 2015 18:16:19 +0000 Message-ID: References: <52A3B956-E9BD-4503-9DDD-D40314B93509@juniper.net> In-Reply-To: <52A3B956-E9BD-4503-9DDD-D40314B93509@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [2001:4898:80e8:5::314] x-microsoft-exchange-diagnostics: 1; BY2PR03MB459; 5:90gnq33Th3HBUd3GoGvEpLcLlntxRNvYWfbphs8U2prNJshnsoNpvySC+VNjgMRTokvlY69TuOh4SaaK1bLYA31JefWV/fZjLIlW6hdKnFspCwJVFjUaIXmQRmRjSkVCvAESlwm6JzwJKTFZmh9QZg==; 24:3Wdkb75Imf+z9NNHXMOG9W5uKwnod5uTC20/b5gIPP+y6lpgJ8qCFNdBa5S6BUF+jFcNjzVwIuHHb5HU2zDKL6tZEO0OS87By9tgYiX1pYU=; 20:eLWg4/K69Sr81/FDBaiZJe8ec9Op3fDyk4DtO60WEsiON7aTk/MZP5ZFKe/LaxKRyHLGGrTiyQTdH6FsAaTacQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB459; by2pr03mb459: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401001)(5005006)(3002001); SRVR:BY2PR03MB459; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB459; x-forefront-prvs: 06469BCC91 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(40764003)(164054003)(377454003)(19580405001)(33656002)(19580395003)(76576001)(50986999)(76176999)(86612001)(2501003)(2656002)(54356999)(87936001)(86362001)(2351001)(5003600100002)(450100001)(62966003)(40100003)(106116001)(77156002)(99286002)(15975445007)(2950100001)(2900100001)(102836002)(189998001)(77096005)(110136002)(107886002)(5002640100001)(5001960100002)(74316001)(230783001)(92566002)(46102003)(10090500001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB459; H:BY2PR03MB457.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2015 18:16:19.4329 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB459 Archived-At: Subject: Re: [spring] working group last call for draft-ietf-spring-segment-routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2015 18:16:24 -0000 Support. ---tjl -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of John G. Scudder Sent: Wednesday, July 22, 2015 6:12 AM To: spring@ietf.org Cc: isis@ietf.org; mpls@ietf.org; 6man@ietf.org; ospf@ietf.org Subject: [spring] working group last call for draft-ietf-spring-segment-rou= ting Dear SPRING WG (and cc MPLS, OSPF, IS-IS, 6MAN, please include SPRING in re= plies per the reply-to): As we discussed at the SPRING meeting yesterday, working group last call ha= s been requested for draft-ietf-spring-segment-routing. Please reply to the= list with your comments, including although not limited to whether or not = you support advancing the document to RFC. Non-authors are especially encou= raged to comment. In consideration of the fact that a number of WG calls are going on concurr= ently, we will end the call on August 31, 2015.=20 Authors, please indicate whether you are aware of any relevant IPR and if s= o, whether it has been disclosed. (Please do this even if you've done it be= fore, thanks for your help.) Thanks, --Bruno and John _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring From nobody Thu Jul 23 11:24:33 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DAA01AC42F for ; Thu, 23 Jul 2015 11:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsomWyRC-GU9 for ; Thu, 23 Jul 2015 11:24:28 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 AD18A1AC42E for ; Thu, 23 Jul 2015 11:24:27 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 6E42FF2A32A1C; Thu, 23 Jul 2015 18:24:21 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t6NIOMfH015210 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jul 2015 18:24:23 GMT Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.190]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Thu, 23 Jul 2015 14:24:23 -0400 From: "Aissaoui, Mustapha (Mustapha)" To: Uma Chunduri , "stephane.litkowski@orange.com" , "spring@ietf.org" Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQxXDwIkSQfsI45E+UJ+sMYxgMGp3pWGDw Date: Thu, 23 Jul 2015 18:24:22 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/related; boundary="_004_4A79394211F1AF4EB57D998426C9340DD47347BEUS70UWXCHMBA01z_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2015 18:24:31 -0000 --_004_4A79394211F1AF4EB57D998426C9340DD47347BEUS70UWXCHMBA01z_ Content-Type: multipart/alternative; boundary="_000_4A79394211F1AF4EB57D998426C9340DD47347BEUS70UWXCHMBA01z_" --_000_4A79394211F1AF4EB57D998426C9340DD47347BEUS70UWXCHMBA01z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Umma, I am saying that SRGB be should configured globally and under the router la= bel management since that is where one assigns label blocks to various appl= ications. If you want IGP instances to uses separate sub-ranges of the globally confi= gured SRGB, you can still achieve that without moving the SRGB configuratio= n into the IGP instance. You just need to configure within the IGP instanc= e which SID ranges and which label offset it uses and make sure you manage = any overlap when you request a label from the global SRGB. It is the SID ra= nge and the label offset parameters which are advertised by the IGP instan= ce in the router SR capabilities sub-TLV. Mustapha. From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] Sent: Thursday, July 23, 2015 1:56 PM To: Aissaoui, Mustapha (Mustapha); stephane.litkowski@orange.com; spring@ie= tf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang >I do not see it being configured under segment routing. Precisely. >Having said that, I think implementations can still partition the global l= abel sub-range assigned to the SRGB among multiple IGP instances and manage= the collisions. And that is what would be advertised in the respective routing area/domain = through respective protocol mechanisms (a.k.a capability TLVs). -- Uma C. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Aissaoui, Mustap= ha (Mustapha) Sent: Thursday, July 23, 2015 10:42 AM To: stephane.litkowski@orange.com; sp= ring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi Stephane and all, The SRGB in the case of MPLS data plane is a dedicated label range to be as= signed for global segments. So, it is part of label management on a router.= Implementations already allow configuring the label range and assigning sp= ecific blocks for static LSPs and other applications. Segment routing is ye= t another application and as such the SRGB should just be configured where = the label management on the router is configured. I do not see it being con= figured under segment routing. Having said that, I think implementations can still partition the global la= bel sub-range assigned to the SRGB among multiple IGP instances and manage = the collisions. Regards, Mustapha. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of stephane.litkows= ki@orange.com Sent: Wednesday, July 22, 2015 1:20 PM To: spring@ietf.org Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi WG, In the current version of the config Yang model for SR, the SRGB list is co= nfigured at SR top level, so it is agnostic to the routing protocol. We had some comment in Dallas on difficulties that having common label rang= e shared between protocols could lead to. During discussion in our design team, some point was also raised on routing= protocol migrations that may be safer using a per protocol SRGB (so config= uration the SRGB at IGP level rather than globally). We would like to hear from the WG about the preference and arguments for bo= th approaches : Approach 1) keep SRGB configuration at top level, and so routing protocols = will share the same label space (today proposal) Approach 2) move SRGB configuration to protocols, each routing protocol man= ages its own label space. Thanks to provide your feedback in order to solve this issue and have a con= sensus. [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 mobile: +33 6 37 86 97 52 stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ 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_4A79394211F1AF4EB57D998426C9340DD47347BEUS70UWXCHMBA01z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Umma,

I am saying that SRGB be should configure= d globally and under the router label management since that is where one as= signs label blocks to various applications.

 

If you want IGP instances to uses separat= e sub-ranges of the globally configured SRGB, you can still achieve that wi= thout moving the SRGB configuration into the IGP instance.  You just need to configure within the IGP instance which SID ranges and wh= ich label offset it uses and make sure you manage any overlap when you requ= est a label from the global SRGB. It is the SID range and the label offset =  parameters which are advertised by the IGP instance in the router SR capabilities sub-TLV.

 

Mustapha.

 

From: Uma Chun= duri [mailto:uma.chunduri@ericsson.com]
Sent: Thursday, July 23, 2015 1:56 PM
To: Aissaoui, Mustapha (Mustapha); stephane.litkowski@orange.com; sp= ring@ietf.org
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

 

>I do not see it being configured unde= r segment routing.

 

Precisely.<= /span>

 

>Having said that, I think implementat= ions can still partition the global label sub-range assigned to the SRGB am= ong multiple IGP instances and manage the collisions.

 

And that is what would= be advertised in the respective routing area/domain through respective pro= tocol mechanisms (a.k.a capability TLVs).

 

--

Uma C.

 

 

Hi Stephane and all,

The SRGB in the case of MPLS data plane i= s a dedicated label range to be assigned for global segments. So, it is par= t of label management on a router. Implementations already allow configuring the label range and assigning specific blocks for static= LSPs and other applications. Segment routing is yet another application an= d as such the SRGB should just be configured where the label management on = the router is configured. I do not see it being configured under segment routing.

 

Having said that, I think implementations= can still partition the global label sub-range assigned to the SRGB among = multiple IGP instances and manage the collisions.

 

Regards,

Mustapha.

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of stepha= ne.litkowski@orange.com
Sent: Wednesday, July 22, 2015 1:20 PM
To: spring@ietf.org
Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-= sr-yang

 

Hi WG,

 

In the current version of the config Yang model for = SR, the SRGB list is configured at SR top level, so it is agnostic to the r= outing protocol.

We had some comment in Dallas on difficulties that h= aving common label range shared between protocols could lead to.=

During discussion in our design team, some point was= also raised on routing protocol migrations that may be safer using a per p= rotocol SRGB (so configuration the SRGB at IGP level rather than globally).=

 

We would like to hear from the WG about the preferen= ce and arguments for both approaches :

Approach 1) keep SRGB configuration at top level, an= d so routing protocols will share the same label space (today proposal)

Approach 2) move SRGB configuration to protocols, ea= ch routing protocol manages its own label space.

 

Thanks to provide your feedback in order to solve th= is issue and have a consensus.

 

 

3D"Orange

 <= o:p>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE

Orange Expert Fut= ure Networks

phone: +33 2 23 28 49 83
mobile: +33 6 37 86 97 52
stephane.litkowski@orange.com

 

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
--_000_4A79394211F1AF4EB57D998426C9340DD47347BEUS70UWXCHMBA01z_-- --_004_4A79394211F1AF4EB57D998426C9340DD47347BEUS70UWXCHMBA01z_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=381; creation-date="Thu, 23 Jul 2015 18:24:22 GMT"; modification-date="Thu, 23 Jul 2015 18:24:22 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhKAAoAMQAAP+MQP+zgP/17//s3/+DMP/iz/+fYP+8j/9wEP95IP/Gn/+WUP/Pr/+pcP/Z v/////9mAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAoACgAAAX6oAONZGmeaEqKauum7Cu/8Wyj9a2P+X73vhkwSCPuhkYVMolj2pbOEjTK oxatrSlVG+U6vUxwUmwkE81BtE99xGbdSjhMPgo4BAoA+wUICAR6IwQODwMNEAcOigAFhQYQDgoD DwcQBJOKBIOFDQmaCCyTB416hQcBBQuTEA8Cow8EBQINpHcGhAkrEAkPChAAD3YPCLuSDw+sIgEP wCILzK0OjY9VBJS/wYQjfwaNyRDLzRAG0AMB5wC6ENyEt8jWDAsCyA/KzJN+zLILqLlVv/OuaYPU alU9cMwuPSCl8AEDYv8EQbwRgAEABcziJFl2bMmeEQgATEwRAgA7 --_004_4A79394211F1AF4EB57D998426C9340DD47347BEUS70UWXCHMBA01z_-- From nobody Thu Jul 23 13:26:15 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02E951A0203 for ; Thu, 23 Jul 2015 13:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyHBye5HlX3c for ; Thu, 23 Jul 2015 13:26:12 -0700 (PDT) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 5D3381A8874 for ; Thu, 23 Jul 2015 13:26:12 -0700 (PDT) Received: by oigd21 with SMTP id d21so4567013oig.1 for ; Thu, 23 Jul 2015 13:26:11 -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 :content-type:content-transfer-encoding; bh=VvBII5PHHaIlWIoWawVwoEyQ4qJUrj+5IGqDxwy7CDE=; b=EUaGxQErO6lnfJystmryL5YI+5lViBLDjo6Wu2FE3s5h+Dia4MCyfuD5x9tdky9BxD ZtFJx4oWjqnX5vBK7ZOjGAt5ZThXl19dvLSXgGnSWUrQLm4lCfuNR2awhiPIcUf3HUZf ofoH5H5dNwv1bTfEH3shhKUphmun8Ox/efFT1Z01zPzZBb0z91wMPc/aB5CvplRWzQ7S QgNihFOTdHck5lrRDxS0LU6t/MWXAdr32w6Cey22fRwyHF0yZse8ZQaeNOjVI4XGsXpc tP46/nCtdBBK2gWNMBa8RhqSPPd0EcGy2Hjz0N4OmoJFhHH7Fc4IglFu0dcB7X/p8x7G q3iw== MIME-Version: 1.0 X-Received: by 10.182.230.70 with SMTP id sw6mr11402052obc.48.1437683171885; Thu, 23 Jul 2015 13:26:11 -0700 (PDT) Received: by 10.202.220.87 with HTTP; Thu, 23 Jul 2015 13:26:11 -0700 (PDT) In-Reply-To: <52A3B956-E9BD-4503-9DDD-D40314B93509@juniper.net> References: <52A3B956-E9BD-4503-9DDD-D40314B93509@juniper.net> Date: Thu, 23 Jul 2015 16:26:11 -0400 Message-ID: From: Mohan Nanduri To: spring@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [spring] [mpls] working group last call for draft-ietf-spring-segment-routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2015 20:26:14 -0000 Support. Cheers, -Mohan On Wed, Jul 22, 2015 at 9:12 AM, John G. Scudder wrote: > Dear SPRING WG (and cc MPLS, OSPF, IS-IS, 6MAN, please include SPRING in = replies per the reply-to): > > As we discussed at the SPRING meeting yesterday, working group last call = has been requested for draft-ietf-spring-segment-routing. Please reply to t= he list with your comments, including although not limited to whether or no= t you support advancing the document to RFC. Non-authors are especially enc= ouraged to comment. > > In consideration of the fact that a number of WG calls are going on concu= rrently, we will end the call on August 31, 2015. > > Authors, please indicate whether you are aware of any relevant IPR and if= so, whether it has been disclosed. (Please do this even if you've done it = before, thanks for your help.) > > Thanks, > > --Bruno and John > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobody Thu Jul 23 14:10:39 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1A61ACDEF for ; Thu, 23 Jul 2015 14:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVGF64cgPfqd for ; Thu, 23 Jul 2015 14:10:33 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33CE01A8791 for ; Thu, 23 Jul 2015 14:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28075; q=dns/txt; s=iport; t=1437685834; x=1438895434; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=beJDq65vPbIUQs1XX1Venyt9a3eNcorr+gvtJg9LMvY=; b=clD322SHbT+Ei0+/KnOh6v43s9R05mBaeuIoo05Fq6eDGO3d2uU8I6Y7 877On3IYqDBGg1jhvMWnNkeYUBfRmxAIb0CyXl+GAjYr9E0hLxIkIoDEc cmc+SyIAwYt0WPT/A53aOfLHZy806A+SvrmIGMhbZasjKVZfKzQkJsIsv E=; X-Files: image001.gif : 381 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DpCQD1V7FV/5xdJa1bGYIvTVRpBrpyQ4IwhgQCgVg7EQEBAQEBAQGBCoQjAQEBAQMFAR8IATQCBxwCAgEIBwoEAQEGAQICFgcHAgUQAQMCCQwUCQgCBAERAQYCBogLAxINxkcDhTgBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBItIhCMRASAFERYBCgEGgxKBFAWMfYRnghhkAYQNAWeCYoYmRoNXj1mDYSZkgSocgVNvAQEBAYEJOoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,533,1432598400"; d="gif'147?scan'147,208,217,147";a="171680611" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP; 23 Jul 2015 21:10:32 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t6NLAVjN007252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jul 2015 21:10:31 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.220]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Thu, 23 Jul 2015 16:10:31 -0500 From: "Les Ginsberg (ginsberg)" To: "Aissaoui, Mustapha (Mustapha)" , Uma Chunduri , "stephane.litkowski@orange.com" , "spring@ietf.org" Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQxW7YNN4DxkRP0Eq723Br5e6m953pqrsAgAAH0AD//9bWAA== Date: Thu, 23 Jul 2015 21:10:30 +0000 Message-ID: References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.24.172.173] Content-Type: multipart/related; boundary="_004_F3ADE4747C9E124B89F0ED2180CC814F5949FA8Axmbalnx02ciscoc_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2015 21:10:38 -0000 --_004_F3ADE4747C9E124B89F0ED2180CC814F5949FA8Axmbalnx02ciscoc_ Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F5949FA8Axmbalnx02ciscoc_" --_000_F3ADE4747C9E124B89F0ED2180CC814F5949FA8Axmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mustapha/Uma - SRGB is an attribute of segment-routing - if that feature is not enabled th= ere is no need for an SRGB. Conceptually (your box is free to implement it differently of course) "Segm= ent Routing" talks to your label manager to request a reservation of the co= nfigured SRGB so none of the labels in that range can be used for a purpose= other than segment routing. That does not mean the SRGB configuration is a= ssociated w the label manager. It would be just as logical to argue that al= l objects should be owned by your memory management module because everythi= ng we configure requires a memory block to be allocated to store the attrib= ute information. Uma -labels are instructions to forwarding as to how to forward packets to = a given (set of) destination(s). In forwarding we do not care what protocol= was used to learn the path to that destination. Suggesting that the forwar= ding instruction (AKA label) needs to be different depending on what proto= col provided the instruction is completely unnecessary - it simply wastes l= abel space. Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Aissaoui, Mustap= ha (Mustapha) Sent: Thursday, July 23, 2015 11:24 AM To: Uma Chunduri; stephane.litkowski@orange.com; spring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi Umma, I am saying that SRGB be should configured globally and under the router la= bel management since that is where one assigns label blocks to various appl= ications. If you want IGP instances to uses separate sub-ranges of the globally confi= gured SRGB, you can still achieve that without moving the SRGB configuratio= n into the IGP instance. You just need to configure within the IGP instanc= e which SID ranges and which label offset it uses and make sure you manage = any overlap when you request a label from the global SRGB. It is the SID ra= nge and the label offset parameters which are advertised by the IGP instan= ce in the router SR capabilities sub-TLV. Mustapha. From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] Sent: Thursday, July 23, 2015 1:56 PM To: Aissaoui, Mustapha (Mustapha); stephane.litkowski@orange.com; spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang >I do not see it being configured under segment routing. Precisely. >Having said that, I think implementations can still partition the global l= abel sub-range assigned to the SRGB among multiple IGP instances and manage= the collisions. And that is what would be advertised in the respective routing area/domain = through respective protocol mechanisms (a.k.a capability TLVs). -- Uma C. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Aissaoui, Mustap= ha (Mustapha) Sent: Thursday, July 23, 2015 10:42 AM To: stephane.litkowski@orange.com; sp= ring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi Stephane and all, The SRGB in the case of MPLS data plane is a dedicated label range to be as= signed for global segments. So, it is part of label management on a router.= Implementations already allow configuring the label range and assigning sp= ecific blocks for static LSPs and other applications. Segment routing is ye= t another application and as such the SRGB should just be configured where = the label management on the router is configured. I do not see it being con= figured under segment routing. Having said that, I think implementations can still partition the global la= bel sub-range assigned to the SRGB among multiple IGP instances and manage = the collisions. Regards, Mustapha. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of stephane.litkows= ki@orange.com Sent: Wednesday, July 22, 2015 1:20 PM To: spring@ietf.org Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi WG, In the current version of the config Yang model for SR, the SRGB list is co= nfigured at SR top level, so it is agnostic to the routing protocol. We had some comment in Dallas on difficulties that having common label rang= e shared between protocols could lead to. During discussion in our design team, some point was also raised on routing= protocol migrations that may be safer using a per protocol SRGB (so config= uration the SRGB at IGP level rather than globally). We would like to hear from the WG about the preference and arguments for bo= th approaches : Approach 1) keep SRGB configuration at top level, and so routing protocols = will share the same label space (today proposal) Approach 2) move SRGB configuration to protocols, each routing protocol man= ages its own label space. Thanks to provide your feedback in order to solve this issue and have a con= sensus. [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 mobile: +33 6 37 86 97 52 stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ 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_F3ADE4747C9E124B89F0ED2180CC814F5949FA8Axmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mustapha/Uma –

 

SRGB is an attribute o= f segment-routing – if that feature is not enabled there is no need f= or an SRGB.

 

Conceptually (your box= is free to implement it differently of course) “Segment Routing̶= 1; talks to your label manager to request a reservation of the configured S= RGB so none of the labels in that range can be used for a purpose other than segment routing. That does not mean the SRGB conf= iguration is associated w the label manager. It would be just as logical to= argue that all objects should be owned by your memory management module be= cause everything we configure requires a memory block to be allocated to store the attribute information.

 

Uma –labels are = instructions to forwarding as to how to forward packets to a given (set of)= destination(s). In forwarding we do not care what protocol was used to lea= rn the path to that destination. Suggesting that the forwarding instruction (AKA label)  needs to be different de= pending on what protocol provided the instruction is completely unnecessary= – it simply wastes label space.

 

   Les<= /o:p>

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of Aissaoui, Mustapha (Mustapha)
Sent: Thursday, July 23, 2015 11:24 AM
To: Uma Chunduri; stephane.litkowski@orange.com; spring@ietf.org
Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

 

Hi Umma,

I am saying that SRGB be should configure= d globally and under the router label management since that is where one as= signs label blocks to various applications.

 

If you want IGP instances to uses separat= e sub-ranges of the globally configured SRGB, you can still achieve that wi= thout moving the SRGB configuration into the IGP instance.  You just need to configure within the IGP instance which SID ranges and wh= ich label offset it uses and make sure you manage any overlap when you requ= est a label from the global SRGB. It is the SID range and the label offset =  parameters which are advertised by the IGP instance in the router SR capabilities sub-TLV.

 

Mustapha.

 

From: Uma Chun= duri [mailto:uma.chunduri@eric= sson.com]
Sent: Thursday, July 23, 2015 1:56 PM
To: Aissaoui, Mustapha (Mustapha); stephane.litkowski@orange.com; sprin= g@ietf.org
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

 

>I do not see it being configured unde= r segment routing.

 

Precisely.<= /span>

 

>Having said that, I think implementat= ions can still partition the global label sub-range assigned to the SRGB am= ong multiple IGP instances and manage the collisions.

 

And that is what would= be advertised in the respective routing area/domain through respective pro= tocol mechanisms (a.k.a capability TLVs).

 

--

Uma C.

 

 

Hi Stephane and all,

The SRGB in the case of MPLS data plane i= s a dedicated label range to be assigned for global segments. So, it is par= t of label management on a router. Implementations already allow configuring the label range and assigning specific blocks for static= LSPs and other applications. Segment routing is yet another application an= d as such the SRGB should just be configured where the label management on = the router is configured. I do not see it being configured under segment routing.

 

Having said that, I think implementations= can still partition the global label sub-range assigned to the SRGB among = multiple IGP instances and manage the collisions.

 

Regards,

Mustapha.

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of stepha= ne.litkowski@orange.com
Sent: Wednesday, July 22, 2015 1:20 PM
To: spring@ietf.org
Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-= sr-yang

 

Hi WG,

 

In the current version of the config Yang model for = SR, the SRGB list is configured at SR top level, so it is agnostic to the r= outing protocol.

We had some comment in Dallas on difficulties that h= aving common label range shared between protocols could lead to.=

During discussion in our design team, some point was= also raised on routing protocol migrations that may be safer using a per p= rotocol SRGB (so configuration the SRGB at IGP level rather than globally).=

 

We would like to hear from the WG about the preferen= ce and arguments for both approaches :

Approach 1) keep SRGB configuration at top level, an= d so routing protocols will share the same label space (today proposal)

Approach 2) move SRGB configuration to protocols, ea= ch routing protocol manages its own label space.

 

Thanks to provide your feedback in order to solve th= is issue and have a consensus.

 

 

3D"Orange

 <= o:p>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE

Orange Expert Fut= ure Networks

phone: +33 2 23 28 49 83
mobile: +33 6 37 86 97 52
stephane.litkowski@orange.com

 

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
--_000_F3ADE4747C9E124B89F0ED2180CC814F5949FA8Axmbalnx02ciscoc_-- --_004_F3ADE4747C9E124B89F0ED2180CC814F5949FA8Axmbalnx02ciscoc_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=381; creation-date="Thu, 23 Jul 2015 21:10:29 GMT"; modification-date="Thu, 23 Jul 2015 21:10:29 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhKAAoAMQAAP+MQP+zgP/17//s3/+DMP/iz/+fYP+8j/9wEP95IP/Gn/+WUP/Pr/+pcP/Z v/////9mAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAoACgAAAX6oAONZGmeaEqKauum7Cu/8Wyj9a2P+X73vhkwSCPuhkYVMolj2pbOEjTK oxatrSlVG+U6vUxwUmwkE81BtE99xGbdSjhMPgo4BAoA+wUICAR6IwQODwMNEAcOigAFhQYQDgoD DwcQBJOKBIOFDQmaCCyTB416hQcBBQuTEA8Cow8EBQINpHcGhAkrEAkPChAAD3YPCLuSDw+sIgEP wCILzK0OjY9VBJS/wYQjfwaNyRDLzRAG0AMB5wC6ENyEt8jWDAsCyA/KzJN+zLILqLlVv/OuaYPU alU9cMwuPSCl8AEDYv8EQbwRgAEABcziJFl2bMmeEQgATEwRAgA7 --_004_F3ADE4747C9E124B89F0ED2180CC814F5949FA8Axmbalnx02ciscoc_-- From nobody Thu Jul 23 14:56:39 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882F51ACEAE for ; Thu, 23 Jul 2015 14:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oYcI4nHH-njA for ; Thu, 23 Jul 2015 14:56:32 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 4C46B1A711A for ; Thu, 23 Jul 2015 14:56:32 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 81D592336CB71; Thu, 23 Jul 2015 21:56:25 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id t6NLuRLn030740 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jul 2015 21:56:27 GMT Received: from US70UWXCHMBA01.zam.alcatel-lucent.com ([169.254.7.190]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Thu, 23 Jul 2015 17:56:27 -0400 From: "Aissaoui, Mustapha (Mustapha)" To: "Les Ginsberg (ginsberg)" , Uma Chunduri , "stephane.litkowski@orange.com" , "spring@ietf.org" Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQxXDwIkSQfsI45E+UJ+sMYxgMGp3pWGDwgAB3zgD//8KqgA== Date: Thu, 23 Jul 2015 21:56:27 +0000 Message-ID: <4A79394211F1AF4EB57D998426C9340DD4734A08@US70UWXCHMBA01.zam.alcatel-lucent.com> References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/related; boundary="_004_4A79394211F1AF4EB57D998426C9340DD4734A08US70UWXCHMBA01z_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2015 21:56:38 -0000 --_004_4A79394211F1AF4EB57D998426C9340DD4734A08US70UWXCHMBA01z_ Content-Type: multipart/alternative; boundary="_000_4A79394211F1AF4EB57D998426C9340DD4734A08US70UWXCHMBA01z_" --_000_4A79394211F1AF4EB57D998426C9340DD4734A08US70UWXCHMBA01z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Les, It is really for ease of management that one provides a single context wher= e the user can manage the label space for the platform. You can assign bloc= ks of labels for static labels, SRGB, and some BGP based L2 VPN. The rest o= f the range is available for assignment by signaling protocols (RSVP, LDP, = BGP, and LDP services). An implementation can certainly implement the label block assignment in eac= h context separately. Regards, Mustapha. From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Thursday, July 23, 2015 5:11 PM To: Aissaoui, Mustapha (Mustapha); Uma Chunduri; stephane.litkowski@orange.= com; spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Mustapha/Uma - SRGB is an attribute of segment-routing - if that feature is not enabled th= ere is no need for an SRGB. Conceptually (your box is free to implement it differently of course) "Segm= ent Routing" talks to your label manager to request a reservation of the co= nfigured SRGB so none of the labels in that range can be used for a purpose= other than segment routing. That does not mean the SRGB configuration is a= ssociated w the label manager. It would be just as logical to argue that al= l objects should be owned by your memory management module because everythi= ng we configure requires a memory block to be allocated to store the attrib= ute information. Uma -labels are instructions to forwarding as to how to forward packets to = a given (set of) destination(s). In forwarding we do not care what protocol= was used to learn the path to that destination. Suggesting that the forwar= ding instruction (AKA label) needs to be different depending on what proto= col provided the instruction is completely unnecessary - it simply wastes l= abel space. Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Aissaoui, Mustap= ha (Mustapha) Sent: Thursday, July 23, 2015 11:24 AM To: Uma Chunduri; stephane.litkowski@orange.com; spring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi Umma, I am saying that SRGB be should configured globally and under the router la= bel management since that is where one assigns label blocks to various appl= ications. If you want IGP instances to uses separate sub-ranges of the globally confi= gured SRGB, you can still achieve that without moving the SRGB configuratio= n into the IGP instance. You just need to configure within the IGP instanc= e which SID ranges and which label offset it uses and make sure you manage = any overlap when you request a label from the global SRGB. It is the SID ra= nge and the label offset parameters which are advertised by the IGP instan= ce in the router SR capabilities sub-TLV. Mustapha. From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] Sent: Thursday, July 23, 2015 1:56 PM To: Aissaoui, Mustapha (Mustapha); stephane.litkowski@orange.com; spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang >I do not see it being configured under segment routing. Precisely. >Having said that, I think implementations can still partition the global l= abel sub-range assigned to the SRGB among multiple IGP instances and manage= the collisions. And that is what would be advertised in the respective routing area/domain = through respective protocol mechanisms (a.k.a capability TLVs). -- Uma C. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Aissaoui, Mustap= ha (Mustapha) Sent: Thursday, July 23, 2015 10:42 AM To: stephane.litkowski@orange.com; sp= ring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi Stephane and all, The SRGB in the case of MPLS data plane is a dedicated label range to be as= signed for global segments. So, it is part of label management on a router.= Implementations already allow configuring the label range and assigning sp= ecific blocks for static LSPs and other applications. Segment routing is ye= t another application and as such the SRGB should just be configured where = the label management on the router is configured. I do not see it being con= figured under segment routing. Having said that, I think implementations can still partition the global la= bel sub-range assigned to the SRGB among multiple IGP instances and manage = the collisions. Regards, Mustapha. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of stephane.litkows= ki@orange.com Sent: Wednesday, July 22, 2015 1:20 PM To: spring@ietf.org Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi WG, In the current version of the config Yang model for SR, the SRGB list is co= nfigured at SR top level, so it is agnostic to the routing protocol. We had some comment in Dallas on difficulties that having common label rang= e shared between protocols could lead to. During discussion in our design team, some point was also raised on routing= protocol migrations that may be safer using a per protocol SRGB (so config= uration the SRGB at IGP level rather than globally). We would like to hear from the WG about the preference and arguments for bo= th approaches : Approach 1) keep SRGB configuration at top level, and so routing protocols = will share the same label space (today proposal) Approach 2) move SRGB configuration to protocols, each routing protocol man= ages its own label space. Thanks to provide your feedback in order to solve this issue and have a con= sensus. [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 mobile: +33 6 37 86 97 52 stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ 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_4A79394211F1AF4EB57D998426C9340DD4734A08US70UWXCHMBA01z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Les,

It is really for ease of management that = one provides a single context where the user can manage the label space for= the platform. You can assign blocks of labels for static labels, SRGB, and some BGP based L2 VPN. The rest of the range is availabl= e for assignment by signaling protocols (RSVP, LDP, BGP, and LDP services).

 

An implementation can certainly implement= the label block assignment in each context separately.

 

Regards,

Mustapha.

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisco.com]
Sent: Thursday, July 23, 2015 5:11 PM
To: Aissaoui, Mustapha (Mustapha); Uma Chunduri; stephane.litkowski@= orange.com; spring@ietf.org
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

 

Mustapha/Uma –

 

SRGB is an attribute o= f segment-routing – if that feature is not enabled there is no need f= or an SRGB.

 

Conceptually (your box= is free to implement it differently of course) “Segment Routing̶= 1; talks to your label manager to request a reservation of the configured S= RGB so none of the labels in that range can be used for a purpose other than segment routing. That does not mean the SRGB conf= iguration is associated w the label manager. It would be just as logical to= argue that all objects should be owned by your memory management module be= cause everything we configure requires a memory block to be allocated to store the attribute information.

 

Uma –labels are = instructions to forwarding as to how to forward packets to a given (set of)= destination(s). In forwarding we do not care what protocol was used to lea= rn the path to that destination. Suggesting that the forwarding instruction (AKA label)  needs to be different de= pending on what protocol provided the instruction is completely unnecessary= – it simply wastes label space.

 

   Les<= /o:p>

 

 

Hi Umma,

I am saying that SRGB be should configure= d globally and under the router label management since that is where one as= signs label blocks to various applications.

 

If you want IGP instances to uses separat= e sub-ranges of the globally configured SRGB, you can still achieve that wi= thout moving the SRGB configuration into the IGP instance.  You just need to configure within the IGP instance which SID ranges and wh= ich label offset it uses and make sure you manage any overlap when you requ= est a label from the global SRGB. It is the SID range and the label offset =  parameters which are advertised by the IGP instance in the router SR capabilities sub-TLV.

 

Mustapha.

 

From: Uma Chun= duri [mailto:uma.chunduri@eric= sson.com]
Sent: Thursday, July 23, 2015 1:56 PM
To: Aissaoui, Mustapha (Mustapha); stephane.litkowski@orange.com; sprin= g@ietf.org
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

 

>I do not see it being configured unde= r segment routing.

 

Precisely.<= /span>

 

>Having said that, I think implementat= ions can still partition the global label sub-range assigned to the SRGB am= ong multiple IGP instances and manage the collisions.

 

And that is what would= be advertised in the respective routing area/domain through respective pro= tocol mechanisms (a.k.a capability TLVs).

 

--

Uma C.

 

 

Hi Stephane and all,

The SRGB in the case of MPLS data plane i= s a dedicated label range to be assigned for global segments. So, it is par= t of label management on a router. Implementations already allow configuring the label range and assigning specific blocks for static= LSPs and other applications. Segment routing is yet another application an= d as such the SRGB should just be configured where the label management on = the router is configured. I do not see it being configured under segment routing.

 

Having said that, I think implementations= can still partition the global label sub-range assigned to the SRGB among = multiple IGP instances and manage the collisions.

 

Regards,

Mustapha.

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of stepha= ne.litkowski@orange.com
Sent: Wednesday, July 22, 2015 1:20 PM
To: spring@ietf.org
Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-= sr-yang

 

Hi WG,

 

In the current version of the config Yang model for = SR, the SRGB list is configured at SR top level, so it is agnostic to the r= outing protocol.

We had some comment in Dallas on difficulties that h= aving common label range shared between protocols could lead to.=

During discussion in our design team, some point was= also raised on routing protocol migrations that may be safer using a per p= rotocol SRGB (so configuration the SRGB at IGP level rather than globally).=

 

We would like to hear from the WG about the preferen= ce and arguments for both approaches :

Approach 1) keep SRGB configuration at top level, an= d so routing protocols will share the same label space (today proposal)

Approach 2) move SRGB configuration to protocols, ea= ch routing protocol manages its own label space.

 

Thanks to provide your feedback in order to solve th= is issue and have a consensus.

 

 

3D"Orange

 <= o:p>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE

Orange Expert Fut= ure Networks

phone: +33 2 23 28 49 83
mobile: +33 6 37 86 97 52
stephane.litkowski@orange.com

 

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
--_000_4A79394211F1AF4EB57D998426C9340DD4734A08US70UWXCHMBA01z_-- --_004_4A79394211F1AF4EB57D998426C9340DD4734A08US70UWXCHMBA01z_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=381; creation-date="Thu, 23 Jul 2015 21:56:27 GMT"; modification-date="Thu, 23 Jul 2015 21:56:27 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhKAAoAMQAAP+MQP+zgP/17//s3/+DMP/iz/+fYP+8j/9wEP95IP/Gn/+WUP/Pr/+pcP/Z v/////9mAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAoACgAAAX6oAONZGmeaEqKauum7Cu/8Wyj9a2P+X73vhkwSCPuhkYVMolj2pbOEjTK oxatrSlVG+U6vUxwUmwkE81BtE99xGbdSjhMPgo4BAoA+wUICAR6IwQODwMNEAcOigAFhQYQDgoD DwcQBJOKBIOFDQmaCCyTB416hQcBBQuTEA8Cow8EBQINpHcGhAkrEAkPChAAD3YPCLuSDw+sIgEP wCILzK0OjY9VBJS/wYQjfwaNyRDLzRAG0AMB5wC6ENyEt8jWDAsCyA/KzJN+zLILqLlVv/OuaYPU alU9cMwuPSCl8AEDYv8EQbwRgAEABcziJFl2bMmeEQgATEwRAgA7 --_004_4A79394211F1AF4EB57D998426C9340DD4734A08US70UWXCHMBA01z_-- From nobody Thu Jul 23 16:06:16 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652871A88F4 for ; Thu, 23 Jul 2015 16:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EUswpMBDBDj for ; Thu, 23 Jul 2015 16:06:08 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074B31A21B9 for ; Thu, 23 Jul 2015 16:06:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35063; q=dns/txt; s=iport; t=1437692769; x=1438902369; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=c3Oksy/HttZTCsm3b3635FLu6bGQlZLgVHcprWLHAL0=; b=OCmvFkPldVpc91uVqta6l8KU194RtivJljKWJLgyE5NBfDPXfgZgxQM6 Vbg/maSdTY0qh0NoaXSuT8gtS2l2QDEnsw+nVJqhHBYOC9jWi4XE+oagV yIg9325y8Vvn9p1dpVFN6vHtrTrcEQRFCHSjGNaKfLsg5W2GQE7JakFXU Q=; X-Files: image001.gif : 381 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ADBwC7crFV/5RdJa1cgkhNVGkGunpDgjCGBAKBUzsRAQEBAQEBAYEKhCMBAQEEBQEfCAE2BxwCAgEIBwoEAQEGAQICFgEGBwIFEAEDAgkMFAkIAgQBEQEGAgaICwMSDcRuA4U4AQEBAQEBAQEBAQEBAQEBAQEBAQEBFwSLSIQjEQEgBREWAQoBBoMSgRQFjH6EZ4IYZAGEDQFngmKGKEaDV49cg2EmZIEqBReBU28BAQEBgQk6gQQBAQE X-IronPort-AV: E=Sophos;i="5.15,534,1432598400"; d="gif'147?scan'147,208,217,147";a="171888673" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Jul 2015 23:06:07 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t6NN65lj015007 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 23 Jul 2015 23:06:05 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.220]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Thu, 23 Jul 2015 18:06:05 -0500 From: "Les Ginsberg (ginsberg)" To: "Aissaoui, Mustapha (Mustapha)" , Uma Chunduri , "stephane.litkowski@orange.com" , "spring@ietf.org" Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQxW7YNN4DxkRP0Eq723Br5e6m953pqrsAgAAH0AD//9bWAIAAZGuA//++TSA= Date: Thu, 23 Jul 2015 23:06:04 +0000 Message-ID: References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <4A79394211F1AF4EB57D998426C9340DD4734A08@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340DD4734A08@US70UWXCHMBA01.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.24.172.173] Content-Type: multipart/related; boundary="_004_F3ADE4747C9E124B89F0ED2180CC814F5949FB6Axmbalnx02ciscoc_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 23 Jul 2015 23:06:14 -0000 --_004_F3ADE4747C9E124B89F0ED2180CC814F5949FB6Axmbalnx02ciscoc_ Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F5949FB6Axmbalnx02ciscoc_" --_000_F3ADE4747C9E124B89F0ED2180CC814F5949FB6Axmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mustapha - I am not telling you what your CLI should look like - trust me - getting fo= lks within my own company to agree on CLI is difficult enough. :) We are discussing whether the placement of SRGB in the YANG model under seg= ment-routing is appropriate. IMO it absolutely is correct. Placing it anywh= ere else is wrong. That does not prevent you from using a label manager CLI in your router to = configure SRGB. Les From: Aissaoui, Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel-lucen= t.com] Sent: Thursday, July 23, 2015 2:56 PM To: Les Ginsberg (ginsberg); Uma Chunduri; stephane.litkowski@orange.com; s= pring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Les, It is really for ease of management that one provides a single context wher= e the user can manage the label space for the platform. You can assign bloc= ks of labels for static labels, SRGB, and some BGP based L2 VPN. The rest o= f the range is available for assignment by signaling protocols (RSVP, LDP, = BGP, and LDP services). An implementation can certainly implement the label block assignment in eac= h context separately. Regards, Mustapha. From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Thursday, July 23, 2015 5:11 PM To: Aissaoui, Mustapha (Mustapha); Uma Chunduri; stephane.litkowski@orange.= com; spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Mustapha/Uma - SRGB is an attribute of segment-routing - if that feature is not enabled th= ere is no need for an SRGB. Conceptually (your box is free to implement it differently of course) "Segm= ent Routing" talks to your label manager to request a reservation of the co= nfigured SRGB so none of the labels in that range can be used for a purpose= other than segment routing. That does not mean the SRGB configuration is a= ssociated w the label manager. It would be just as logical to argue that al= l objects should be owned by your memory management module because everythi= ng we configure requires a memory block to be allocated to store the attrib= ute information. Uma -labels are instructions to forwarding as to how to forward packets to = a given (set of) destination(s). In forwarding we do not care what protocol= was used to learn the path to that destination. Suggesting that the forwar= ding instruction (AKA label) needs to be different depending on what proto= col provided the instruction is completely unnecessary - it simply wastes l= abel space. Les From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Aissaoui, Mustap= ha (Mustapha) Sent: Thursday, July 23, 2015 11:24 AM To: Uma Chunduri; stephane.litkowski@orange.com; spring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi Umma, I am saying that SRGB be should configured globally and under the router la= bel management since that is where one assigns label blocks to various appl= ications. If you want IGP instances to uses separate sub-ranges of the globally confi= gured SRGB, you can still achieve that without moving the SRGB configuratio= n into the IGP instance. You just need to configure within the IGP instanc= e which SID ranges and which label offset it uses and make sure you manage = any overlap when you request a label from the global SRGB. It is the SID ra= nge and the label offset parameters which are advertised by the IGP instan= ce in the router SR capabilities sub-TLV. Mustapha. From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] Sent: Thursday, July 23, 2015 1:56 PM To: Aissaoui, Mustapha (Mustapha); stephane.litkowski@orange.com; spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang >I do not see it being configured under segment routing. Precisely. >Having said that, I think implementations can still partition the global l= abel sub-range assigned to the SRGB among multiple IGP instances and manage= the collisions. And that is what would be advertised in the respective routing area/domain = through respective protocol mechanisms (a.k.a capability TLVs). -- Uma C. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Aissaoui, Mustap= ha (Mustapha) Sent: Thursday, July 23, 2015 10:42 AM To: stephane.litkowski@orange.com; sp= ring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi Stephane and all, The SRGB in the case of MPLS data plane is a dedicated label range to be as= signed for global segments. So, it is part of label management on a router.= Implementations already allow configuring the label range and assigning sp= ecific blocks for static LSPs and other applications. Segment routing is ye= t another application and as such the SRGB should just be configured where = the label management on the router is configured. I do not see it being con= figured under segment routing. Having said that, I think implementations can still partition the global la= bel sub-range assigned to the SRGB among multiple IGP instances and manage = the collisions. Regards, Mustapha. From: spring [mailto:spring-bounces@ietf.org] On Behalf Of stephane.litkows= ki@orange.com Sent: Wednesday, July 22, 2015 1:20 PM To: spring@ietf.org Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi WG, In the current version of the config Yang model for SR, the SRGB list is co= nfigured at SR top level, so it is agnostic to the routing protocol. We had some comment in Dallas on difficulties that having common label rang= e shared between protocols could lead to. During discussion in our design team, some point was also raised on routing= protocol migrations that may be safer using a per protocol SRGB (so config= uration the SRGB at IGP level rather than globally). We would like to hear from the WG about the preference and arguments for bo= th approaches : Approach 1) keep SRGB configuration at top level, and so routing protocols = will share the same label space (today proposal) Approach 2) move SRGB configuration to protocols, each routing protocol man= ages its own label space. Thanks to provide your feedback in order to solve this issue and have a con= sensus. [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 mobile: +33 6 37 86 97 52 stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ 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_F3ADE4747C9E124B89F0ED2180CC814F5949FB6Axmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mustapha –<= /o:p>

 

I am not telling you w= hat your CLI should look like – trust me - getting folks within my ow= n company to agree on CLI is difficult enough. J

 

We are discussing whet= her the placement of SRGB in the YANG model under segment-routing is approp= riate. IMO it absolutely is correct. Placing it anywhere else is wrong.

 

That does not prevent = you from using a label manager CLI in your router to configure SRGB.

 

   Les<= /o:p>

 

 

From: Aissaoui= , Mustapha (Mustapha) [mailto:mustapha.aissaoui@alcatel-lucent.com]
Sent: Thursday, July 23, 2015 2:56 PM
To: Les Ginsberg (ginsberg); Uma Chunduri; stephane.litkowski@orange= .com; spring@ietf.org
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

 

Les,

It is really for ease of management that = one provides a single context where the user can manage the label space for= the platform. You can assign blocks of labels for static labels, SRGB, and some BGP based L2 VPN. The rest of the range is availabl= e for assignment by signaling protocols (RSVP, LDP, BGP, and LDP services).

 

An implementation can certainly implement= the label block assignment in each context separately.

 

Regards,

Mustapha.

 

From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisc= o.com]
Sent: Thursday, July 23, 2015 5:11 PM
To: Aissaoui, Mustapha (Mustapha); Uma Chunduri; stephane.litkowski@orange.com; sprin= g@ietf.org
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

 

Mustapha/Uma –

 

SRGB is an attribute o= f segment-routing – if that feature is not enabled there is no need f= or an SRGB.

 

Conceptually (your box= is free to implement it differently of course) “Segment Routing̶= 1; talks to your label manager to request a reservation of the configured S= RGB so none of the labels in that range can be used for a purpose other than segment routing. That does not mean the SRGB conf= iguration is associated w the label manager. It would be just as logical to= argue that all objects should be owned by your memory management module be= cause everything we configure requires a memory block to be allocated to store the attribute information.

 

Uma –labels are = instructions to forwarding as to how to forward packets to a given (set of)= destination(s). In forwarding we do not care what protocol was used to lea= rn the path to that destination. Suggesting that the forwarding instruction (AKA label)  needs to be different de= pending on what protocol provided the instruction is completely unnecessary= – it simply wastes label space.

 

   Les<= /o:p>

 

 

Hi Umma,

I am saying that SRGB be should configure= d globally and under the router label management since that is where one as= signs label blocks to various applications.

 

If you want IGP instances to uses separat= e sub-ranges of the globally configured SRGB, you can still achieve that wi= thout moving the SRGB configuration into the IGP instance.  You just need to configure within the IGP instance which SID ranges and wh= ich label offset it uses and make sure you manage any overlap when you requ= est a label from the global SRGB. It is the SID range and the label offset =  parameters which are advertised by the IGP instance in the router SR capabilities sub-TLV.

 

Mustapha.

 

From: Uma Chun= duri [mailto:uma.chunduri@eric= sson.com]
Sent: Thursday, July 23, 2015 1:56 PM
To: Aissaoui, Mustapha (Mustapha); stephane.litkowski@orange.com; sprin= g@ietf.org
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

 

>I do not see it being configured unde= r segment routing.

 

Precisely.<= /span>

 

>Having said that, I think implementat= ions can still partition the global label sub-range assigned to the SRGB am= ong multiple IGP instances and manage the collisions.

 

And that is what would= be advertised in the respective routing area/domain through respective pro= tocol mechanisms (a.k.a capability TLVs).

 

--

Uma C.

 

 

Hi Stephane and all,

The SRGB in the case of MPLS data plane i= s a dedicated label range to be assigned for global segments. So, it is par= t of label management on a router. Implementations already allow configuring the label range and assigning specific blocks for static= LSPs and other applications. Segment routing is yet another application an= d as such the SRGB should just be configured where the label management on = the router is configured. I do not see it being configured under segment routing.

 

Having said that, I think implementations= can still partition the global label sub-range assigned to the SRGB among = multiple IGP instances and manage the collisions.

 

Regards,

Mustapha.

 

From: spring [= mailto:spring-bounces@ietf.org] On Behalf Of stepha= ne.litkowski@orange.com
Sent: Wednesday, July 22, 2015 1:20 PM
To: spring@ietf.org
Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-= sr-yang

 

Hi WG,

 

In the current version of the config Yang model for = SR, the SRGB list is configured at SR top level, so it is agnostic to the r= outing protocol.

We had some comment in Dallas on difficulties that h= aving common label range shared between protocols could lead to.=

During discussion in our design team, some point was= also raised on routing protocol migrations that may be safer using a per p= rotocol SRGB (so configuration the SRGB at IGP level rather than globally).=

 

We would like to hear from the WG about the preferen= ce and arguments for both approaches :

Approach 1) keep SRGB configuration at top level, an= d so routing protocols will share the same label space (today proposal)

Approach 2) move SRGB configuration to protocols, ea= ch routing protocol manages its own label space.

 

Thanks to provide your feedback in order to solve th= is issue and have a consensus.

 

 

3D"Orange

 <= o:p>

Stephane Litkowski
Network Architect
Orange/SCE/EQUANT/IBNF/ENDD/NDE

Orange Expert Fut= ure Networks

phone: +33 2 23 28 49 83
mobile: +33 6 37 86 97 52
stephane.litkowski@orange.com

 

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
--_000_F3ADE4747C9E124B89F0ED2180CC814F5949FB6Axmbalnx02ciscoc_-- --_004_F3ADE4747C9E124B89F0ED2180CC814F5949FB6Axmbalnx02ciscoc_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=381; creation-date="Thu, 23 Jul 2015 23:06:03 GMT"; modification-date="Thu, 23 Jul 2015 23:06:03 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhKAAoAMQAAP+MQP+zgP/17//s3/+DMP/iz/+fYP+8j/9wEP95IP/Gn/+WUP/Pr/+pcP/Z v/////9mAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAoACgAAAX6oAONZGmeaEqKauum7Cu/8Wyj9a2P+X73vhkwSCPuhkYVMolj2pbOEjTK oxatrSlVG+U6vUxwUmwkE81BtE99xGbdSjhMPgo4BAoA+wUICAR6IwQODwMNEAcOigAFhQYQDgoD DwcQBJOKBIOFDQmaCCyTB416hQcBBQuTEA8Cow8EBQINpHcGhAkrEAkPChAAD3YPCLuSDw+sIgEP wCILzK0OjY9VBJS/wYQjfwaNyRDLzRAG0AMB5wC6ENyEt8jWDAsCyA/KzJN+zLILqLlVv/OuaYPU alU9cMwuPSCl8AEDYv8EQbwRgAEABcziJFl2bMmeEQgATEwRAgA7 --_004_F3ADE4747C9E124B89F0ED2180CC814F5949FB6Axmbalnx02ciscoc_-- From nobody Fri Jul 24 01:55:35 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39CF1A1B83; Fri, 24 Jul 2015 01:49:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0MrOQqirP9k; Fri, 24 Jul 2015 01:49:06 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::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 2E1F71A1B30; Fri, 24 Jul 2015 01:49:06 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so18843588wib.0; Fri, 24 Jul 2015 01:49:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=374ayGomFJKhw0TWUVy4wdCmv/rneoUeYGmgg3bvdt8=; b=hyTWKkCebJ64yHaJReQh50JekSdA/OT/DE84sBNqfUfogR05eCqLe26j2pTYKzbP6f hQbOiViS2eMpf9GEa2Jhh2AkGW2g98zsgGoJ4lLAq0tFimrBZxJCJwpjeiD1DF3BTSm8 iWJj5d7HYtMLFDOWeQoMI4lI4FMFyKhAxEsJu1XSnud9hsncJhhRL7IHid3JMwW8+T1q 3O/0rCNEBcaJAk/KVx2dBFFUp1YjVByObKTnVw1UWRFfIPEw71zwsjs572FCXK4ctEqL EcvrRTTNhxQB4Meb2LGLywcl4ESkGfhF60OPV+X+WKPOsO4sTOR9kW3BMzUj9RqHvrZ0 Ep/A== X-Received: by 10.194.58.69 with SMTP id o5mr24646316wjq.22.1437727744921; Fri, 24 Jul 2015 01:49:04 -0700 (PDT) Received: from ?IPv6:2001:67c:370:168:28cc:dc4c:9703:6781? ([2001:67c:370:168:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id bg6sm11512195wjc.13.2015.07.24.01.49.03 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 24 Jul 2015 01:49:04 -0700 (PDT) Message-ID: <55B1FC09.3080904@gmail.com> Date: Fri, 24 Jul 2015 20:49:13 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: spring@ietf.org References: <52A3B956-E9BD-4503-9DDD-D40314B93509@juniper.net> In-Reply-To: <52A3B956-E9BD-4503-9DDD-D40314B93509@juniper.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Fri, 24 Jul 2015 01:55:34 -0700 Cc: 6man@ietf.org Subject: Re: [spring] working group last call for draft-ietf-spring-segment-routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jul 2015 08:49:07 -0000 Hi, It seems very strange to me that [I-D.previdi-6man-segment-routing-header] is an Informative reference. Surely it is Normative (i.e., required reading for an implementer)? That leads to another comment. As we know, if 6man accepts that I-D, it will certainly be on the basis that the header is strictly confined to a "consenting adults" domain (e.g. without middleboxes that can't deal with strange extension headers, without MTU size & fragmentation problems, etc.). But in draft-ietf-spring-segment-routing, there seems to be no definition of a segment-routing domain, what happens at its boundaries, etc. The word "domain" is used but without clear definition. I believe that is of normative importance (i.e. it's not a use case issue) and is needed here so that draft-previdi- can build on it. Brian From nobody Fri Jul 24 07:49:54 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA711B3076 for ; Fri, 24 Jul 2015 07:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gn0XuIAMGo0U for ; Fri, 24 Jul 2015 07:49:51 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.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 F3EAC1B305A for ; Fri, 24 Jul 2015 07:49:50 -0700 (PDT) X-AuditID: c6180641-f794d6d000001dfb-74-55b1e867f276 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id C5.9E.07675.768E1B55; Fri, 24 Jul 2015 09:25:27 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0210.002; Fri, 24 Jul 2015 10:49:49 -0400 From: Uma Chunduri To: "Aissaoui, Mustapha (Mustapha)" , "stephane.litkowski@orange.com" , "spring@ietf.org" Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQxW7W7UQaSb3Ur0my0GoCc8g+MZ3pViOwgABLpQCAAQ89QA== Date: Fri, 24 Jul 2015 14:49:48 +0000 Message-ID: <1B502206DFA0C544B7A6046915200863512A7A0F@eusaamb105.ericsson.se> References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> In-Reply-To: <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A6046915200863512A7A0Feusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXRPiG76i42hBn9uW1u0zFvHZHH8wm9G i697H7I6MHu0PtvL6rFkyU8mj5ZnJ9kCmKO4bFJSczLLUov07RK4MiY+eMZacMOg4tvlb4wN jB+1uhg5OSQETCSOnzzKBGGLSVy4t56ti5GLQ0jgKKPEhkeHWCCc5YwSax80MYNUsQnoSXyc +pMdJCEisIVRov/4b3aQhLBAoMTB+1vBRokIBElcmrGeEcJ2kji4sRvMZhFQlbh2HsLmFfCV eLL5LNS6T0wS63+8BEtwCsRK7Lz1jxXEZgS66fupNWBDmQXEJW49mQ91q4DEkj3nmSFsUYmX jyHqJQSUJOa8vgYU5wCqz5f412YCsUtQ4uTMJywTGEVmIZk0C6FqFpIqiBIdiQW7P7FB2NoS yxa+Zoaxzxx4zIQsvoCRfRUjR2lxalluupHhJkZgTB2TYHPcwbjgk+UhRgEORiUe3gXaG0OF WBPLiitzDzFKc7AoifNK++WFCgmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBcKPlmtai5W7mE /Nz6VUf+hhr/37baIk6Ve9Uqf72c9l1pr9f/XXbw0cTZK9KMXoccDDjMdGLukZgC7dhZrPEd K5coPngWPfeEVMq+2IgVV/Jzjxw4O3vOhjTvQC3G/In6lQ0L1NYIrVqxcvVyDWGj4jSTZWXx UpdrNVOUHt5Nnnd/37I/XTFBSizFGYmGWsxFxYkAJfygY4oCAAA= Archived-At: Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jul 2015 14:49:53 -0000 --_000_1B502206DFA0C544B7A6046915200863512A7A0Feusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >You just need to configure within the IGP instance which SID ranges and wh= ich label offset it uses and make sure you manage > any overlap when you request a label from the global SRGB. I= t is the SID range and the label offset parameters which are advertised >by the IGP instance in the router SR capabilities sub-TLV. [Uma]: Mustapha, yes of course, this is the only thing that matters for re= st of the nodes in the area/domain and these are indeed SRGB descriptors. Provisioning here obviously belong to the routing protocol inst= ance. For rest of the nodes PoV this is your "global SRGB". -- Uma C. --_000_1B502206DFA0C544B7A6046915200863512A7A0Feusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= >You just need to configure within the IGP instance wh= ich SID ranges and which label offset it uses and make sure you manage

   &nbs= p;         > any overlap when you request a label from the global SRGB. It is the SI= D range and the label offset  parameters which are advertised

   &nbs= p;         >by the IGP instance in the router SR capabilities sub-TLV.

 

[Uma]: Mustapha, yes of cou= rse, this is the only thing that matters for  rest of the nodes in the= area/domain and these are indeed SRGB descriptors.

    &nb= sp;       Provisioning here obviously be= long to the routing protocol instance. For rest of the nodes PoV  this= is your “global SRGB”.

 

--

Uma C.

--_000_1B502206DFA0C544B7A6046915200863512A7A0Feusaamb105erics_-- From nobody Fri Jul 24 07:59:31 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE0E1B3091 for ; Fri, 24 Jul 2015 07:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l1Pw7-8Q-cvQ for ; Fri, 24 Jul 2015 07:59:28 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.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 61E621B308E for ; Fri, 24 Jul 2015 07:59:28 -0700 (PDT) X-AuditID: c618062d-f799e6d00000329e-de-55b1f6cc5420 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 01.A0.12958.CC6F1B55; Fri, 24 Jul 2015 10:26:52 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0210.002; Fri, 24 Jul 2015 10:59:26 -0400 From: Uma Chunduri To: "Les Ginsberg (ginsberg)" , "Aissaoui, Mustapha (Mustapha)" , "stephane.litkowski@orange.com" , "spring@ietf.org" Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQxW7W7UQaSb3Ur0my0GoCc8g+MZ3pViOwgABLpQCAAC5qAIAA4xbQ Date: Fri, 24 Jul 2015 14:59:25 +0000 Message-ID: <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> 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.12] Content-Type: multipart/alternative; boundary="_000_1B502206DFA0C544B7A6046915200863512A7A36eusaamb105erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZXLrHW/fMt42hBsv+S1hs+LOR3aJl3jom i+MXfjNafN37kNWBxaP12V5Wjym/N7J6LFnyk8mj5dlJtgCWKC6blNSczLLUIn27BK6MG5sj CjZqVyx/vZapgXGCWhcjJ4eEgInExQlvGSFsMYkL99azdTFycQgJHGWUuLD3IBOEs5xR4vzr e8wgVWwCehIfp/5kB0mICDxjlFjR+ACsXVggUOLg/a1MILaIQJDEpRnrGSFsN4kV2y6zgNgs AqoSDd9XsIHYvAK+Eit+bWYHsYUEtjJLLPzBD2JzAsU3PlwKtowR6KTvp9aAzWQWEJe49WQ+ E8SpAhJL9pxnhrBFJV4+/scKYStJzHl9jRmiPl9ixY1lLBC7BCVOznzCMoFRZBaSUbOQlM1C UgYR15FYsPsTG4StLbFs4WtmGPvMgcdMyOILGNlXMXKUFqeW5aYbGWxiBMbZMQk23R2Me15a HmIU4GBU4uF9kLwxVIg1say4MvcQozQHi5I4r2NUXqiQQHpiSWp2ampBalF8UWlOavEhRiYO TqkGRvk8yYLEA+uCF3ovYjVx4C45n3+PwTbh8THmXl+uRgm7hxonzfYKnLxStvajrcFUp18G 2eZ3bMquOK0T3SWS+U/MPODwz/esledaVuTmv/asM/OSlru3cfvNVMeHTrO+hm8reSy2Oz74 ye1fDcG8zZ+kHNhcFt4qDlj0cN4GsdP9e8+2+N0qUWIpzkg01GIuKk4EADIxPUeUAgAA Archived-At: Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 24 Jul 2015 14:59:30 -0000 --_000_1B502206DFA0C544B7A6046915200863512A7A36eusaamb105erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >Suggesting that the forwarding instruction (AKA label) needs to be differ= ent depending on what protocol provided >the instruction is completely unnecessary - it simply wastes label space. [Uma]: Les, No - I never suggested anything like that. SRGB for a routing instance to be advertised should be part of the routing = instance provisioning as far as the yang model is concerned. Carving out the label space for SR is a local matter and agree, of course, = this can be done in so many ways through CLI, dynamically, statically etc.= .. -- Uma C. --_000_1B502206DFA0C544B7A6046915200863512A7A36eusaamb105erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

>Suggesting that the forwardin= g instruction (AKA label)  needs to be different depending on what pro= tocol provided

>the instruction is completely= unnecessary – it simply wastes label space.

 

[Uma]: Les, No - I nev= er suggested anything like that.

SRGB for a routing ins= tance to be advertised should be part of the routing instance provisioning = as far as the yang model is concerned.

Carving out the label = space for SR is a local matter and agree, of course, this  can be done= in so many ways through CLI, dynamically, statically etc...

 

--

Uma C.

 

--_000_1B502206DFA0C544B7A6046915200863512A7A36eusaamb105erics_-- From nobody Mon Jul 27 00:49:40 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB411ACEE3; Mon, 27 Jul 2015 00:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NiDptGVeY1Tq; Mon, 27 Jul 2015 00:49:35 -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 945841ACE5E; Mon, 27 Jul 2015 00:49:35 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 72B5118C106; Mon, 27 Jul 2015 09:49:33 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.60]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 5429927C0AE; Mon, 27 Jul 2015 09:49:33 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0235.001; Mon, 27 Jul 2015 09:49:32 +0200 From: To: "spring@ietf.org" Thread-Topic: [spring] working group last call for draft-ietf-spring-segment-routing Thread-Index: AQHQxIG+1tUfURl7rkSupgCQMwkRVp3u9pVA Date: Mon, 27 Jul 2015 07:49:31 +0000 Message-ID: <7020_1437983373_55B5E28D_7020_3238_1_9E32478DFA9976438E7A22F69B08FF92166A4C9F@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <5E1C2E18-E314-4364-8A17-A543DFF888E3@juniper.net> In-Reply-To: <5E1C2E18-E314-4364-8A17-A543DFF888E3@juniper.net> Accept-Language: fr-FR, en-US Content-Language: en-US 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: 2015.7.27.70617 Archived-At: Cc: "isis-wg@ietf.org" Subject: Re: [spring] working group last call for draft-ietf-spring-segment-routing X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jul 2015 07:49:37 -0000 Hi Chairs, I currently have some issue with the anycast section of the draft. Based on= the discussion we had during the WG session (through Pushpasis's presenta= tion), it looks that the anycast section is not enough explained (what is t= he problem behind ...) and using a "MUST" for mandating "common SRGB" is to= o restrictive to me as it was decided by the WG to make the SR architecture= working with different SRGB per node. I'm completely in favor of using "common SRGB" between anycast nodes as sho= rt term solution if possible, but working on general solution is also neces= sary. Some more explanations are necessary, and a recommendation rather than usin= g a MUST would be better. PS : also the anycast draft refers to N-bit unset which is an encoding refe= rence and so does not really make sense in this draft, possible solutions : - move the statement to ISIS and OSPF draft - be more generic on explaining the constraint (no more reference to encodi= ng) Regards, Stephane -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of John G.Scudder Sent: Wednesday, July 22, 2015 15:24 To: spring@ietf.org Cc: isis-wg@ietf.org Subject: [spring] working group last call for draft-ietf-spring-segment-rou= ting [re-send with correct address for isis-wg] Dear SPRING WG (and cc MPLS, OSPF, IS-IS, 6MAN, please include SPRING in re= plies per the reply-to): As we discussed at the SPRING meeting yesterday, working group last call ha= s been requested for draft-ietf-spring-segment-routing. Please reply to the= list with your comments, including although not limited to whether or not = you support advancing the document to RFC. Non-authors are especially encou= raged to comment. In consideration of the fact that a number of WG calls are going on concurr= ently, we will end the call on August 31, 2015.=20 Authors, please indicate whether you are aware of any relevant IPR and if s= o, whether it has been disclosed. (Please do this even if you've done it be= fore, thanks for your help.) Thanks, --Bruno and John _______________________________________________ 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 Jul 27 01:48:30 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CA0F1AD190 for ; Mon, 27 Jul 2015 01:48:28 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XySMMQ5t2hSm for ; Mon, 27 Jul 2015 01:48:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:759]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F511AD160 for ; Mon, 27 Jul 2015 01:48:24 -0700 (PDT) Received: from BLUPR05MB434.namprd05.prod.outlook.com (10.141.27.147) by BLUPR05MB245.namprd05.prod.outlook.com (10.255.191.11) with Microsoft SMTP Server (TLS) id 15.1.225.19; Mon, 27 Jul 2015 08:48:05 +0000 Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none; Received: from hannes-mba.local (193.110.55.12) by BLUPR05MB434.namprd05.prod.outlook.com (10.141.27.147) with Microsoft SMTP Server (TLS) id 15.1.219.17; Mon, 27 Jul 2015 08:48:04 +0000 Received: from hannes-mba.local (localhost [IPv6:::1]) by hannes-mba.local (Postfix) with ESMTP id 188B915751F8; Mon, 27 Jul 2015 10:47:50 +0200 (CEST) Date: Mon, 27 Jul 2015 10:47:50 +0200 From: Hannes Gredler To: "Les Ginsberg (ginsberg)" Message-ID: <20150727084750.GB25444@hannes-mba.local> References: <20150624230327.12191.65118.idtracker@ietfa.amsl.com> <20150721123459.GA1274@puck.nether.net> <6740_1437490344_55AE5CA8_6740_5026_1_9E32478DFA9976438E7A22F69B08FF92166A3315@OPEXCLILMA4.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [193.110.55.12] X-ClientProxiedBy: DB4PR08CA0021.eurprd08.prod.outlook.com (25.161.12.31) To BLUPR05MB434.namprd05.prod.outlook.com (10.141.27.147) X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB434; 2:gJsOtw3hE+OQ6DkzMHEBsdOfmOm8nCdMD8Kt4ogdRwEYzFVpJSft38atzKUk/8E/; 3:RoMpwo0x6qxAYhqVvKa3Rtq4XsV9QH5c6Cl1mo/ZZ0ULysLmBlPG4wlQDrjIlfJmC3n2Om0/Ies4tr1AZFK7fVswLkAHsr/1jGeT3bymzBUHmYEaw46EQVXwUU6F4brYpuonXG211VDDY08DUZeK9w==; 25:9+jU7fOrmNBSZew3Tltq/6s/shezOnpwXTDcP5lrXjqCsHO9Vyhij+5oxp7sKXOKiCUWFefOXcb2if86PJRN+FMIkSRw7QbuSvKrUl7BPNhrTEShDYBTvkch4Y1Q0pO4MFYB1J5ya3+ke4AGFPJ3sOmiTkvrFJ6+upNEHtVuTuzTWZAdyEwMGgIeSgTHCYKW/G1fuNsxVH1Di4zWhn27/cQXTziQVR51jHrAvox9IWXoavKI1GJt88yRlmJL4pXYzNMsZXEdo1MR6cd7O7pxKA== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB434; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB245; X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB434; 20:xoU9ZmiwLK2Y+3fhLu3EAoTMhi/t9muW/5F7vpeprdUdbhIl/wKgltcNb4YnOzUP3OnOSGOSFVzDJXi8StHSn7Rv96Cm1GMCtWG5htOITgUc5EL+OK2bj/lQKIfc+OhqE1vS4VrUu4OFt2hc96mMpiEoWhK1kQSRbqLzyx4ZS/M+HftDK71w6T8s4+grkaO6SM8YfWP9lLpL7tCmTWLkKFTClV7Pxc5C9dPZvk9sStQMNI45hAjTRUB0fSP19D++Tho+zMrLH49zII6/VbvLbUBLCLGbmBZYYF80XAh5hiE0EtmPIZaEFBPkk14UTcFbj8SwA1su1Il8tC2Sb3dUtBDGZzQnQ+Ec8HN1Jos2wVHcvWbizGcNF+vAAc3ScJF8x6RZtwzDRYlOiFg6Qj8A84ETYYVRCeMOwrfn6vRjodAeFdI9RTOomivtDB4CK7eZqeb3l51Q9B6QWvYN9/zGnWNebgXmA9MPiOkku2hM3vP8Y5ZwlmBSz+TRv+j3rs5m; 4:HjJt28vsu50ckRc5k2Ki22+svifMurixM9mZIoKVSdcOLPZEgTu1c/9bkMIYpM/8V7SittzojE4nvE04K7L3xhKdl3pDsa0kNvslxGnRkSKEo2MB2o8/oBEfDoEbuHSp4T5DR0vMcLBGy7LTvPlg7hYkGl9wC/v6XmltLy9r35kIKEiGj6ytOrZfRgpbpqe0mYdqWAWncUemkNvXTfxueXiC8+145zt9HW2EAy6L348ANKMIwoawgpcDK9QD9I+pHx5IXCJ2szKIhOFzsVl0xyu5Co2l8IY693djwy+mcrI= BLUPR05MB434: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB434; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB434; X-Forefront-PRVS: 0650714AAA X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(24454002)(164054003)(479174004)(46406003)(50466002)(77156002)(62966003)(40100003)(122856001)(15975445007)(19580395003)(54356999)(122386002)(561944003)(92566002)(87976001)(93886004)(97756001)(46102003)(50986999)(76176999)(66066001)(83506001)(76506005)(86362001)(189998001)(98436002)(5001920100001)(110136002)(5890100001)(5001960100002)(5003600100002)(47776003)(23726002)(77096005)(230783001)(4001350100001)(33656002)(19580405001)(2950100001)(579124003); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB434; H:hannes-mba.local; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR05MB434; 23:i8k3Mc8CPzZf6bX4S/DM47naNYQwqtW1Tacl/bEdEZ?= =?us-ascii?Q?cl3QbDV++8B5daf/6Yk3H013/zBCbWIH3essW0kXFGWsE7c5ChacnJzcaPMX?= =?us-ascii?Q?xWdCpfriGyFAhLsF+mX/xPzaP8FqC9toe9pY3nhKVqNPvlXbTNcqA9gvIouS?= =?us-ascii?Q?2otvVp/S9cXoOfN518xwtm5tuqUSnxdJqYTL/yjiLUZTE+9kxnQeshljMfCV?= =?us-ascii?Q?Jc+Ezm8PFKXQRqwSe8dlvvnZDbyDRxT87PE9WPqppVySMvfUDLuLcwTT3Uqb?= =?us-ascii?Q?XWsJQWn9EHkRTAPTbB01oiDXSrNp9Z211hbDx5MrdLz0WZX7b25pcEZfBUc7?= =?us-ascii?Q?N7rvHze609I8Ou9iTVWmaU6udMchiroKNYrInbwWyXg8J/ZvJ7jJ8OHUjHkN?= =?us-ascii?Q?blO4AcBesiCkPxMzCdXjBRdtuggzZKdifm7Mb+FJ4PfNru5wWjHTlAh3qTdL?= =?us-ascii?Q?gB2fX2PFopj3+R0Cf9WdW0S80KNWKl6wxI8So6BlNWdr3t51weTAHFalKXBT?= =?us-ascii?Q?5s6uL8p3ZbIxsZLfuE1pC+kvDageoxbHL+9AAqfXcga1kL23+iQ/bB476Y/M?= =?us-ascii?Q?s7LgYs1WOhu0kdEVgmkIC/MB5xBb93RrVYf423LPMt7MCAxi/dE9YGxYLfeE?= =?us-ascii?Q?LQcPWTrdGCmh7dyvEanR8dUdkTG/9LFh/aYNApEKQxl++q5OLvEeBawLEpgV?= =?us-ascii?Q?XFsVjECGfHNQWVPV+3A62jvmDrpeNMRz55bZmFbtjBemngmks2nh18KIRV+W?= =?us-ascii?Q?eLutnZXku0B4jf6meiELJrmtTfZd85g2Gm9Qsil2IjOtWWSLS4fN0xmDbO6U?= =?us-ascii?Q?d6IYeeZtvzm7sQltRtOoZUGCgvhk7/6sZnLew2KPiJVoRvlulQXPVzgWKqP0?= =?us-ascii?Q?OGdh3xo5l3A34cciCSKBckV/5fJZMKUpGryRArMwT+j+SSPToTgA3bRsMA6L?= =?us-ascii?Q?ooCf0E0qb8lpQHuMXaug8OtnIcdBCBWCsHbMCZfTQjkLzLfd4+r0KrJrzOn8?= =?us-ascii?Q?Pp614Q3eZzhLk1sMh2/sWPrJAsqXROA9jmXXmpsP7oX8apXdqKdnYbwxiHvw?= =?us-ascii?Q?8FitBU+suspOMDAuuUksFGK6W4WcIsrn+iO4faALSEbuUdloXPBbVglNV69b?= =?us-ascii?Q?O0dDudAzXYlBJhApLW0809HFXNukJrycuvricBgkeZIBgtwX9QfeNMSGdEyj?= =?us-ascii?Q?iqk2a46/DAgqU=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB434; 5:o+L3HaX84qJ+eVtYJgR17b0QG1xgw6vC8n0qFJTpp/uL+vCoeXVBJxJwmColW/zs9P2HT1pV62fnRVK+XaV/KhCDk9qrJ7lj++sYCdHF0a740PtNeX5x089UE7BTPpMI9Mfc1AsFtlpc9i+rOLR4Aw==; 24:BLO2FqfIXG5HjlTPSp/UBX+w6kz6wU9u4xfNx5VlsIz7C059hy+Q3nOkXWnScc99ydZgrYhtYnoaBvD9TVaBxK1yrJvXACmgf0ETlvcbJpw=; 20:Rw0Z4zXw/Y/5x/KDpWSrY/ghJpQDnZxciLZf7kJUDZXaNcv07IfP89t8Wq4Q6XVaLeZtdVzkR1kNECne9eDtSg== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jul 2015 08:48:04.3614 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB434 X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB245; 2:d96zqJlE2KsDCC6EDeS8egWNeknR5qiQGlD8fK6zR30kffuLUZKy79I7MGP/1+trUkXF2W+AY70XUSrAMNFEy8PhH/KDZ0o5YguwKMK1RAR9+tKTLMkdhskDJ9c7E5k0/1tnWkWXb4sJe1vqoXtXDuWj+rcc2w1MtNqhRcplJ1I=; 3:ejvI1okiMsjT1aZxXsSmtFaEoWQx01jMts3ZvMCrw74Ik/b2B68m1WiylZLCaueq8EQTWwIzRyj6nx0k6hy/RqfP+Eo7OJxt6yTXJyVD/VkLpBxlDwGGon/4f0QQuosfUIsq9w9LDzMFZuhFO8SBPw==; 25:vVdapomoBD+j9akFD6MNtCE0DGE4NLcHulgWLlRTz7YZXeXeeOvEFQgy+73StM30nl7wKz5CWdMzCjKqrYJmGngE3Oj67VCWsTtmfGs2quNaJGZ9/J1pBBucJ8qOw+o+SCslfx4LDlFkz9hUZawszfgJccExCfuIH/ivWjXTOh8F7WXAFhxoEi+Q0Z9Lo9Nmx1Hr2qXcP3E0f/KGwkrxyDJ5RwlcOQa2JzVaf0tabaIXx1lyuMiSdiuaTmCAwMApvqs3XO4af9AntIL167ow3Q==; 20:YBTalCaxZ5JiEpAGgmiBUjwAsCiKNnliaxlSh7AK0q5KHlvoGkXB1gyvdzxNELnCyGWfXIzk1DEiMq4/pKfKnQ==; 23:1/17fn/ssWgVVJi8+muYGg6L9Y3142KoJAfPinkFPPUTjoumg1Jbk8h/BILPgD+ffFlpfxtbg5PBuF9+7atYm6X4a7UTid+cu9aAAwAFMDQlsyyiodQt7u7P2KosaOUGdFXdCoZA2ealrjkVCRh7J9pBxZSvgR8ZLnwCihyHt1eX7T/aHJvbxx7nsj0v6jSvhi1CjoDgACtJuUnCc0gTX24pwtMq4HXM34vT+/uOJc5VD24GpGD9jVod0yWqs4wp BLUPR05MB245: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: juniper.net Archived-At: Cc: "stephane.litkowski@orange.com" , "spring@ietf.org" , Chris Bowers , Jon Mitchell Subject: Re: [spring] FW: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jul 2015 08:48:28 -0000 hi les, assuming option 1 and a local knob e.g. 'algorithm offset ' as per your example below i got the following question(s): 1) how does a computing router know that a downstream router has got the 'offset per-algo knob' configured, such that it can map outgoing label values to the correct label value (SRGB + algo offset) of the downstream routers ? - 2) is the expectation that 'algorithm offset ' is configured identical on all the routers in the network ? 3) if so - isn't this considered a rather 'fragile / error prone' approach to operating a network ? /hannes On Tue, Jul 21, 2015 at 08:58:51PM +0000, Les Ginsberg (ginsberg) wrote: | Stephane/Chris - | | | | Defining an offset, whether explicitly as Ahmed/Jon have suggested or | implicitly as the draft Option #2 defines can be problematic in either | case. | | | | If you don't plan for as many labels as you might need in the future then | when the day comes when you run out of labels you need to allocate more. | | | | If I use one SRGB for all algorithms, then I have the (non-disruptive) | options of: | | | | . Extending the existing SRGB space | | . Reserving an additional SRGB space | | | | If I use one SRGB for each algorithm, then if I run out of | labels/algorithm I have the same options - but now I have to do this for | each algorithm specific set of SRGBs. | | | | (There are disruptive ways to address this by completely redefining the | SRGBs w/o regard to the existing config - but I think we all understand | that this option is very undesirable and this is true in both options.) | | | | Of course it is better to be generous enough with your initial SRGB | allocation so as to avoid the need for ever having to extend an SRGB - in | which case the amount of label space you need to reserve initially is the | same in both cases. | | (Sorry - no free lunch!! J ) | | | | Option #1 however avoids a number of issues which complicate Option #2: | | | | Under Option #2 support for a new algorithm now requires not only | advertising support for the algorithm but also advertising a new (set of) | algorithm specific SRGB ranges. We have to check for the presence of both | algorithm support and the algorithm specific SRGB(s) before declaring a | node as supporting a given algorithm. Each of these algorithm specific set | of ranges has to be checked for both intra-algorithm consistency (no | overlap within the algorithm specific ranges) and inter-algorithm | consistency. | | | | I would also suggest that for many implementations, any reservation of | label space AFTER startup can be problematic. Label space is typically | managed by declaring two types of ranges: | | | | 1)reserved for a specific use (like segment routing) | | 2)available for dynamic allocation (unreserved) | | | | The unreserved space is typically everything that isn't reserved. If I | need to reserve additional space after startup I face the possibility that | some of the additional range I would like to reserve may be in use via | dynamic allocation. In such a case I cannot successfully reserve the range | until all the existing dynamic allocations are released - which can be | awkward to do and may very well be disruptive to the entity using the | dynamically allocated labels. So this is best avoided. | | | | I understand why making config easier for the user is desirable - and | Option #2 provides that - but it is also easy to do so using Option #1. | One can imagine a syntax similar to: | | | | algorithm offset | | And, as described above, this does not require us to reserve more labels | than we would need under Option #2. | | I am not seeing any advantage to Option #2. Though it is well motivated, | everything you want to achieve w Option #2 can easily be achieved using | Option #1. | | | | Les | | | | > -----Original Message----- | | > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of | | > stephane.litkowski@orange.com | | > Sent: Tuesday, July 21, 2015 7:52 AM | | > To: Jon Mitchell; Chris Bowers | | > Cc: spring@ietf.org | | > Subject: Re: [spring] FW: New Version Notification for | draft-bowers-spring- | | > adv-per-algorithm-label-blocks-01.txt | | > | | > Using an offset may be dangerous as if your network growth your algo1 | SIDs | | > may collision with algo2 SIDs because the offset is no more enough ... | (you | | > always need more ...) using an offset is similar to splitting the SRGB | in 2 | | > SRGBs with the limitation of not being able to extend the first part. | Option 2 | | > allows this extension. | | > You may say let's put a very very large SRGB and offset of +20000 ... | yes but | | > it's wasting resources ... | | > | | > | | > | | > -----Original Message----- | | > From: spring [[1]mailto:spring-bounces@ietf.org] On Behalf Of Jon | Mitchell | | > Sent: Tuesday, July 21, 2015 14:35 | | > To: Chris Bowers | | > Cc: [2]spring@ietf.org | | > Subject: Re: [spring] FW: New Version Notification for | draft-bowers-spring- | | > adv-per-algorithm-label-blocks-01.txt | | > | | > On 24/06/15 23:09 +0000, Chris Bowers wrote: | | > > This updated version of the draft includes a concrete proposal for | ISIS | | > extensions to implement per-algorithm label blocks. | | > > | | > | | > Chris - | | > | | > As you discussed in the meeting today in option 2 (the proposal) there | is a | | > "savings" that is achieved by not allocating a large label space as is | required in | | > option 1 since we may not be able to predict the future of algorithm | needs in | | > the network. But wouldn't you agree that since you are allocating a | node | | > index in every fractured address space (whether required or not) in | option 2, | | > since address space that is partitioned typically consumes more space | than | | > unfractured space (due to loss because of imperfect planning), as you | | > increase the number of algorithms aren't you more likely to consume more | | > overall space with this technique? | | > | | > Secondly there was a statement made that there is an advantage to option | | > 2 that it allows easier provisioning of node index value (as it's | | > reused) per algorithm. Isn't it just as easy for an implementation to | allow the | | > user to just configure a local implementation offset for an algorithm | which | | > requires no protocol changes and has more flexiblity as it doesn't need | to be | | > configured for prefix SID's that don't require it (similar as Ahmed | suggested | | > at the mic, i.e. algorithm 2 = +1000) that could be configured at every | node? | | > Assuming OSS provisions SID's sequentially this seems to work just as | well... | | > | | > Thanks, | | > | | > Jon | | > | | > _______________________________________________ | | > spring mailing list | | > [3]spring@ietf.org | | > [4]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 | | > [5]spring@ietf.org | | > [6]https://www.ietf.org/mailman/listinfo/spring | | References | | Visible links | 1. mailto:spring-bounces@ietf.org | 2. mailto:spring@ietf.org | 3. mailto:spring@ietf.org | 4. https://www.ietf.org/mailman/listinfo/spring | 5. mailto:spring@ietf.org | 6. https://www.ietf.org/mailman/listinfo/spring | _______________________________________________ | spring mailing list | spring@ietf.org | https://www.ietf.org/mailman/listinfo/spring From nobody Mon Jul 27 01:58:01 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6479E1B2B62; Fri, 24 Jul 2015 22:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b62BS1xGyon3; Fri, 24 Jul 2015 22:42:12 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7B561B2B61; Fri, 24 Jul 2015 22:42:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1596; q=dns/txt; s=iport; t=1437802932; x=1439012532; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=pp9zzU3TB9GuRtVOzO2Hpm7E39ovxFEhNhdpP06lzeE=; b=OCtkSgYlDO60pHwfHgmjs0IvsCTw3yHX6tGxvJ/vpHU/NJrJfe9D8UzU 6Ojt1dV/1wZMKTSlf0jLd+eiwagx2e5f/B9ckJPuKdIirToPf5hoBS7Yw 4gDvj85K3VJetn7kKbcXxx9Dq3ocdNfeKsNIaWHajO8Au8Gy/Y0mwVhN4 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BCAwBBIbNV/5BdJa1cgxVUaQa7agmBbQqFeQKBQjgUAQEBAQEBAX8LhCMBAQEEAQEBGlELDAQCAQgRAwECLycLFAkIAgQOBYguDc8bAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLToQuWQcGhCYFlGkBjD6BRYQdj2KDYiaCP4E+b4EFQ4EEAQEB X-IronPort-AV: E=Sophos;i="5.15,542,1432598400"; d="scan'208";a="18614680" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP; 25 Jul 2015 05:42:11 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id t6P5gBrQ029613 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 25 Jul 2015 05:42:11 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.112]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Sat, 25 Jul 2015 00:42:11 -0500 From: "Zafar Ali (zali)" To: "spring@ietf.org" Thread-Topic: [mpls] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop Thread-Index: AQHQxIDNlSUgFnCczU6LeKuieu+WYZ3rwPgA Date: Sat, 25 Jul 2015 05:42:10 +0000 Message-ID: References: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> In-Reply-To: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 x-originating-ip: [10.86.241.99] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Mon, 27 Jul 2015 01:57:56 -0700 Cc: "mpls@ietf.org" Subject: Re: [spring] [mpls] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 25 Jul 2015 05:42:14 -0000 Support,=20 Thanks Regards =8A Zafar -----Original Message----- From: mpls on behalf of "John G.Scudder" Reply-To: "spring@ietf.org" Date: Wednesday, July 22, 2015 9:17 AM To: "spring@ietf.org" Cc: "mpls@ietf.org" Subject: [mpls] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop >Dear WG, > >As we discussed at our meeting yesterday, working group adoption has been >requested for draft-filsfils-spring-segment-routing-ldp-interop. Please >reply to the list with your comments, including although not limited to >whether or not you support adoption. Non-authors are especially >encouraged to comment. > >In consideration of the fact that a number of WG calls are going on >concurrently, we will end the call on August 31, 2015. > >Authors, please indicate whether you are aware of any relevant IPR and if >so, whether it has been disclosed. Also, the length of the author list >for this document greatly exceeds the maximum recommended. Assuming the >document is adopted, the authors should be prepared to correct this when >submitting as a WG document, ideally by reducing the list to simply the >active editor(s) and making use of the "contributors" section for the >full list. > >Thanks, > >--Bruno and John > >P.S.: Cc MPLS owing to the LDP connection. Please respect the reply-to. >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From nobody Mon Jul 27 02:11:38 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9201AD2F2 for ; Mon, 27 Jul 2015 02:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uwuv8wVH1U2j for ; Mon, 27 Jul 2015 02:11:33 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42131A3B9B for ; Mon, 27 Jul 2015 02:11:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10793; q=dns/txt; s=iport; t=1437988294; x=1439197894; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=gKb0hS8GULP9erlj/3bxDBWA6ffm/YakivmpnBz99pY=; b=SGVyBtW95GH78SlF3NTfV/hfVsoZv2HifARghe+sb/inm69fFSH6UQLs V29TpfvdHS83hF9jIhXEDUmKQssBFJxRxaaOlgeMV6klyysdyZ2p5OXza Umx33RTg8+Q9o4SbP6205P7n/Bum8zx36m29+VgHFNTlPD8ymVXBIRzpE o=; X-IronPort-AV: E=Sophos;i="5.15,552,1432598400"; d="scan'208";a="603140053" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 27 Jul 2015 09:11:31 +0000 Received: from [10.148.128.133] ([10.148.128.133]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t6R9BTft026373; Mon, 27 Jul 2015 09:11:29 GMT Message-ID: <55B5F5C1.9050201@cisco.com> Date: Mon, 27 Jul 2015 11:11:29 +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: Hannes Gredler , "Les Ginsberg (ginsberg)" References: <20150624230327.12191.65118.idtracker@ietfa.amsl.com> <20150721123459.GA1274@puck.nether.net> <6740_1437490344_55AE5CA8_6740_5026_1_9E32478DFA9976438E7A22F69B08FF92166A3315@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <20150727084750.GB25444@hannes-mba.local> In-Reply-To: <20150727084750.GB25444@hannes-mba.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "stephane.litkowski@orange.com" , "spring@ietf.org" , Jon Mitchell , Chris Bowers Subject: Re: [spring] FW: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 27 Jul 2015 09:11:36 -0000 Hi Hannes, On 7/27/15 10:47 , Hannes Gredler wrote: > hi les, > > assuming option 1 and a local knob e.g. 'algorithm offset ' > as per your example below i got the following question(s): > > 1) how does a computing router know that a downstream router has got > the 'offset per-algo knob' configured, such that it can map outgoing label values > to the correct label value (SRGB + algo offset) of the downstream routers ? - there is no need for the computing node to know. Let's assume we have a node N that has single SRGB (16000-23999) and it supports 4 algorithms. Internally the node splits its SRGB to 4 blocks, one per algorithm: alg 0: [16000, 17999] alg 1: [18000, 19999] alg 2: [20000, 21999] alg 3: [22000, 23999] For prefix P1 on node N, user configures single index 25. Node N then advertises: SID 16025 - alg 0 SID 18025 - alg 1 SID 20025 - alg 2 SID 22025 - alg 3 thanks, Peter > > 2) is the expectation that 'algorithm offset ' is configured identical > on all the routers in the network ? > > 3) if so - isn't this considered a rather 'fragile / error prone' > approach to operating a network ? > > /hannes > > On Tue, Jul 21, 2015 at 08:58:51PM +0000, Les Ginsberg (ginsberg) wrote: > | Stephane/Chris - > | > | > | > | Defining an offset, whether explicitly as Ahmed/Jon have suggested or > | implicitly as the draft Option #2 defines can be problematic in either > | case. > | > | > | > | If you don't plan for as many labels as you might need in the future then > | when the day comes when you run out of labels you need to allocate more. > | > | > | > | If I use one SRGB for all algorithms, then I have the (non-disruptive) > | options of: > | > | > | > | . Extending the existing SRGB space > | > | . Reserving an additional SRGB space > | > | > | > | If I use one SRGB for each algorithm, then if I run out of > | labels/algorithm I have the same options - but now I have to do this for > | each algorithm specific set of SRGBs. > | > | > | > | (There are disruptive ways to address this by completely redefining the > | SRGBs w/o regard to the existing config - but I think we all understand > | that this option is very undesirable and this is true in both options.) > | > | > | > | Of course it is better to be generous enough with your initial SRGB > | allocation so as to avoid the need for ever having to extend an SRGB - in > | which case the amount of label space you need to reserve initially is the > | same in both cases. > | > | (Sorry - no free lunch!! J ) > | > | > | > | Option #1 however avoids a number of issues which complicate Option #2: > | > | > | > | Under Option #2 support for a new algorithm now requires not only > | advertising support for the algorithm but also advertising a new (set of) > | algorithm specific SRGB ranges. We have to check for the presence of both > | algorithm support and the algorithm specific SRGB(s) before declaring a > | node as supporting a given algorithm. Each of these algorithm specific set > | of ranges has to be checked for both intra-algorithm consistency (no > | overlap within the algorithm specific ranges) and inter-algorithm > | consistency. > | > | > | > | I would also suggest that for many implementations, any reservation of > | label space AFTER startup can be problematic. Label space is typically > | managed by declaring two types of ranges: > | > | > | > | 1)reserved for a specific use (like segment routing) > | > | 2)available for dynamic allocation (unreserved) > | > | > | > | The unreserved space is typically everything that isn't reserved. If I > | need to reserve additional space after startup I face the possibility that > | some of the additional range I would like to reserve may be in use via > | dynamic allocation. In such a case I cannot successfully reserve the range > | until all the existing dynamic allocations are released - which can be > | awkward to do and may very well be disruptive to the entity using the > | dynamically allocated labels. So this is best avoided. > | > | > | > | I understand why making config easier for the user is desirable - and > | Option #2 provides that - but it is also easy to do so using Option #1. > | One can imagine a syntax similar to: > | > | > | > | algorithm offset > | > | And, as described above, this does not require us to reserve more labels > | than we would need under Option #2. > | > | I am not seeing any advantage to Option #2. Though it is well motivated, > | everything you want to achieve w Option #2 can easily be achieved using > | Option #1. > | > | > | > | Les > | > | > | > | > -----Original Message----- > | > | > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of > | > | > stephane.litkowski@orange.com > | > | > Sent: Tuesday, July 21, 2015 7:52 AM > | > | > To: Jon Mitchell; Chris Bowers > | > | > Cc: spring@ietf.org > | > | > Subject: Re: [spring] FW: New Version Notification for > | draft-bowers-spring- > | > | > adv-per-algorithm-label-blocks-01.txt > | > | > > | > | > Using an offset may be dangerous as if your network growth your algo1 > | SIDs > | > | > may collision with algo2 SIDs because the offset is no more enough ... > | (you > | > | > always need more ...) using an offset is similar to splitting the SRGB > | in 2 > | > | > SRGBs with the limitation of not being able to extend the first part. > | Option 2 > | > | > allows this extension. > | > | > You may say let's put a very very large SRGB and offset of +20000 ... > | yes but > | > | > it's wasting resources ... > | > | > > | > | > > | > | > > | > | > -----Original Message----- > | > | > From: spring [[1]mailto:spring-bounces@ietf.org] On Behalf Of Jon > | Mitchell > | > | > Sent: Tuesday, July 21, 2015 14:35 > | > | > To: Chris Bowers > | > | > Cc: [2]spring@ietf.org > | > | > Subject: Re: [spring] FW: New Version Notification for > | draft-bowers-spring- > | > | > adv-per-algorithm-label-blocks-01.txt > | > | > > | > | > On 24/06/15 23:09 +0000, Chris Bowers wrote: > | > | > > This updated version of the draft includes a concrete proposal for > | ISIS > | > | > extensions to implement per-algorithm label blocks. > | > | > > > | > | > > | > | > Chris - > | > | > > | > | > As you discussed in the meeting today in option 2 (the proposal) there > | is a > | > | > "savings" that is achieved by not allocating a large label space as is > | required in > | > | > option 1 since we may not be able to predict the future of algorithm > | needs in > | > | > the network. But wouldn't you agree that since you are allocating a > | node > | > | > index in every fractured address space (whether required or not) in > | option 2, > | > | > since address space that is partitioned typically consumes more space > | than > | > | > unfractured space (due to loss because of imperfect planning), as you > | > | > increase the number of algorithms aren't you more likely to consume more > | > | > overall space with this technique? > | > | > > | > | > Secondly there was a statement made that there is an advantage to option > | > | > 2 that it allows easier provisioning of node index value (as it's > | > | > reused) per algorithm. Isn't it just as easy for an implementation to > | allow the > | > | > user to just configure a local implementation offset for an algorithm > | which > | > | > requires no protocol changes and has more flexiblity as it doesn't need > | to be > | > | > configured for prefix SID's that don't require it (similar as Ahmed > | suggested > | > | > at the mic, i.e. algorithm 2 = +1000) that could be configured at every > | node? > | > | > Assuming OSS provisions SID's sequentially this seems to work just as > | well... > | > | > > | > | > Thanks, > | > | > > | > | > Jon > | > | > > | > | > _______________________________________________ > | > | > spring mailing list > | > | > [3]spring@ietf.org > | > | > [4]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 > | > | > [5]spring@ietf.org > | > | > [6]https://www.ietf.org/mailman/listinfo/spring > | > | References > | > | Visible links > | 1. mailto:spring-bounces@ietf.org > | 2. mailto:spring@ietf.org > | 3. mailto:spring@ietf.org > | 4. https://www.ietf.org/mailman/listinfo/spring > | 5. mailto:spring@ietf.org > | 6. 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 Tue Jul 28 09:48:08 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3460A1ACE96; Tue, 28 Jul 2015 09:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_MY_NAME_IS=0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Virb1jnAdgSq; Tue, 28 Jul 2015 09:37:27 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0797.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::797]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961731ACE80; Tue, 28 Jul 2015 09:37:13 -0700 (PDT) Received: from DB3PR03MB299.eurprd03.prod.outlook.com (10.242.131.144) by DB3PR03MB0794.eurprd03.prod.outlook.com (10.161.55.139) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 28 Jul 2015 16:36:52 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB299.eurprd03.prod.outlook.com (10.242.131.144) with Microsoft SMTP Server (TLS) id 15.1.225.19; Tue, 28 Jul 2015 16:36:51 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0225.018; Tue, 28 Jul 2015 16:36:51 +0000 From: Alexander Vainshtein To: "rtg-ads@tools.ietf.org" Thread-Topic: Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop Thread-Index: AdDJU4rozHs9zgL9Q6awOhnek/vb5w== Date: Tue, 28 Jul 2015 16:36:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tools.ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [109.66.1.206] x-microsoft-exchange-diagnostics: 1; DB3PR03MB299; 5:LuXU3qcBFkxCpaqMksnRLY9KxxecbQJde2LhOdgAWz1ljBaIkVXnCOxmQqnD1ftkFTywHZVmun1dxK/kAi2vd9OHq18pqg00X/EB179tiMp8KxL4ZmzMjMGkNSHd6KlisrjF6d4J8G7CPMoWzc42mw==; 24:+isdw1zhettUGkoNKUsxiHUjSqxBzub/Uj7xB+0NqUDkaGLlbxUxRETWgnQkJYRpAzMkvS2Y/vhfLQqsPXLuWOBkQGLg1lD/u7i3yi3qCGo=; 20:l7952jHuXANBn2vKaHunrOLaXu+3XWlcYW3REnQqnnV+hP1tt/+DDPVuhAEpS5PMCP8HZr+BofmD6Lwycd1sQw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB299; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0794; db3pr03mb299: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB3PR03MB299; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB299; x-forefront-prvs: 06515DA04B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(252514010)(377454003)(37854004)(51444003)(66654002)(122556002)(86362001)(2656002)(66066001)(2900100001)(19617315012)(19580395003)(87936001)(40100003)(54356999)(19300405004)(92566002)(555904002)(2351001)(50986999)(62966003)(46102003)(230783001)(189998001)(5003600100002)(110136002)(5002640100001)(16236675004)(77156002)(19625215002)(76576001)(5001960100002)(2501003)(19580405001)(77096005)(33656002)(102836002)(15975445007)(74316001)(7059030)(579004)(559001)(36394004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB299; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR03MB0780A7F30E35B8D04B020BE79D8D0DB3PR03MB0780eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jul 2015 16:36:51.5188 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB299 X-Microsoft-Exchange-Diagnostics: 1; DB3PR03MB0794; 2:AxLS0cb3yHFJiQjue9bbyc16tbkxQITgAtfzOUp+6be4E5UTswYaqsmJOfFGz5op2bkhGTx1S9Weu9FNxuGhCJDGZzxrPXlVZ3zGiti4U+rFRBXlSR9LKZuuUjJB8PqLBjBCSuc+jBKsHrgdJEuAqpUGLgisPS9AIyqaf2UYR9c=; 3:3hT4y0Ct7H14Q6LETIspbbaOYEWTYNrRoT9dquiFG1ipsFg+U7i4+QvkeVsu9D0encu2jKy4MK4UMnNUccnLrBNhfjNgMBbCZA7pAD4y1PrsMXKmr9v127Eqh/44EE1abxzanCcCDxU4zs4Wa0abng==; 25:Kx7LkEtX0L+B9ZHGKGCzZSvNSmUTxrh/nXogiolAxGDjPpfvxiDGW7L1xsM0mCr0w7zW6T/fLe2TQkemaVGnmS0vqJpcZ8MpNoxoJgxm5PSiHG7e2YMvf+Ho3HuSpxDak1zgi5b4LJ4btKhPALra40XVo9Regv1OJSo/YoTF0+roZPgI6TcLDYpp1y9RzZ8sBRV44geRd+Fr657/m0/UMMe6EYYYycg5Il+937/RdaxlOsBKoZ5IgiZrnAxmZpF0PkhkBptxazvUw1e3+FEAFw==; 20:Lm0L75f5tG0oBF/sMl+4B0TgWWHk7eHajJB3ytwzJKvlqJwr8bY84fIGCfbZVg78d7gGHRV+96RYgZDt4tHzHw==; 23:XqzhgXKEF+GUsghdxYbxQ8oSxBJymT/k/ZivXFICPkGFLeRW608unbOneM7BFpaF+umbTVsJK1hmxTWeml+NyT5cn4qjp8C2NE//7f4s+DP/BKMd1eQCZrhI6DRyB2pyw+YSXSVv6vstrwGV0VrB+K0GMPweWnNnyX2POHn2xpOqN2kmtU/QABNNyBVi4L8l4kmHrWwJq3neiR2I8B8yEvjz3qxrvGkCiWBnCgpQjUrpuspSEWvCyBgOdubs68gZ DB3PR03MB0794: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: ecitele.com Archived-At: X-Mailman-Approved-At: Tue, 28 Jul 2015 09:48:07 -0700 Cc: "rtg-dir@ietf.org" , "spring@ietf.org" , "Martin.Horneffer@telekom.de" , "bashandy@cisco.com" , "cfilsfil@cisco.com" , "mpls@ietf.org" , "edward.crabbe@gmail.com" , "igormilojevic@telekom.rs" , Jeff Tantsura , "bruno.decraene@orange.com" , "saku@ytti.fi" , "rob.shakir@bt.com" , "sprevidi@cisco.com" , Jonathan Hardwick , "jgs@juniper.net" , "wim.henderickx@alcatel-lucent.com" , "stephane.litkowski@orange.com" , Jon Hudson Subject: Re: [spring] Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 28 Jul 2015 16:37:33 -0000 --_000_DB3PR03MB0780A7F30E35B8D04B020BE79D8D0DB3PR03MB0780eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, My name is Sasha Vainshtein, and I have been asked to perform the QA revie= w of https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing= -ldp-interop/. Due to health problems I have been very late (but, hopefully, not too late)= with this review, and here it is. Does the draft solves a real problem? From my POV, definitely yes. 1. The problem stems from the following combination of fa= cts fact that: a. LDP distributes labels for FECs represented by IP prefixes (among = other things). b. LDP-based MPLS network are very widely deployed c. SR operating over the MPLS DP allocates labels for SIDs that can r= epresent IP prefixes (again, among other things) d. As a consequence, LDP and SR may effectively map the same IP prefix= to different labels. 2. As SR using the MPLS DP is gaining acceptance in the i= ndustry, the following deployment scenarios look as realistic to me: a. Coexistence between LDP-based and SR-based control planes in the = same network b. Partial deployment of SR in some sub-domains of a network combined = with the operators' need to use the benefits of SR where it is already depl= oyed c. Gradual transition of services (especially L2 and L3VPN) tunnelle= d over LDP-created LSPs to LSPs set up using SR (and, possibly, vice versa) Is the draft a good enough start for a WG document? From my POV, yes. 1 The draft covers multiple (if not all) realistic use cases for co= existence of LDP-based and SR-based control planes and provides what looks= to me as reasonable solutions for these scenarios. 2 At the same I would think that additional work is required to com= plete the work. Specific issues with the current draft: 1 Editorial: SR-related abbreviations (e.g., SRGB, SID etc.) are us= ed without expansion at the first use, and there is no "Abbreviation" secti= on in the draft. 2 Process/Editorial: The draft currently lists 12 authors on its ti= tle page exceeding the recommended RFC Editor maximum of 5 authors. 3. Technical: The draft does not analyse the use case of= coexistence between SR and LDP with enabled extension for multi-area LSPs = as per RFC 5283= . I think that this use case deserves special consideration in the draft be= cause: a. It mentions the use case of seamless MPLS and refers to the (expir= ed) Seamless MPLS Architecture draft b. The seamless MPLS Architecture draft, in its turn, explicitly refe= rs to RFC 5283 in Section 5.1.1 to facilitate binding of labels received vi= a the DoD LDP session while only default route is configured in the RIB of = the access node in the seamless MPLS architecture c. It is possible that this use case would not add anything to the dr= aft - but I would prefer to see it in the document with the appropriate exp= lanation 4. Technical: Section 8 "Manageability Considerations" is= currently left empty. When this section is written, I would expect at leas= t the following: a. Some level of detail regarding local policies defining whether LD= P-created or SR-created LSPs should be used etc. b. Discussion of using LSP Ping for LSPs that are produced by stitchin= g an LDP segment with an SR one. c. Alternatively, it is possible to move this section to a separate d= edicated draft 5. Technical: I think more information should be provided= in Section 5 to explain operational aspects of SR-assisted LDP FR: a. In Section 5.1 I would expect the draft to explain that: i. Node= D is selected as the RLFA using the same logic that is defined for select= ing RLFA in RFC 7490 ii. The "= bypass LSP" is set up by the SR CP automatically without any need for manag= ement intervention iii. I wou= ld like to understand why dynamically set up Targeted LDP sessions are an o= perational concern. Such sessions appear also when BGP-based auto-discovery= for L2VPN is used, and, according to the analysis in RFC 7490, the scalabi= lity problems associated with these sessions look as negligible. b. In Section 5.2 I would expect the draft to explain that: i. The = resulting solution is similar to using a bypass LSP to a manually selected = RLFA that is set up by RSVP-TE (the difference is that a Targeted LDP sessi= on to such an RLFA would be still needed) ii. Set u= p of the "traffic-engineered bypass LSP" by the SR CP is triggered by an a= ppropriate management operation iii. What = information should be provided by the Management Plane for computing the RL= FA and the traffic-engineered bypass LSP? Should it be similar to configur= ation parameters used with RSVP-TE? iv. Which k= ind of logic should be responsible for computing the RLFA and the path to b= e taken by the engineered bypass LSP: should it be similar to the CSPF used= with RSVP-TE? v. How th= e traffic-engineered bypass LSP hat is set up by the SR CP would react to a= dditional changes in the network topology (the behaviour of the bypass LSP = that is set by RSVP-TE in these situations is well known). Neither of the issues listed above should be considered as preventing adopt= ion of the draft as a WG document IMO. Actually I think that resolving thes= e issues in the context of a WG document would be more effective. Hopefully these notes will be useful. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] Sent: Wednesday, May 20, 2015 12:46 PM To: Alexander Vainshtein Cc: bruno.decraene@orange.com; jgs@juniper.net; Alvaro Retana (aretana); Jo= n Hudson Subject: Routing directorate QA review of draft-filsfils-spring-segment-rou= ting-ldp-interop Hi Sasha Please would you be the routing directorate QA reviewer for draft-filsfils-= spring-segment-routing-ldp-interop? https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing-ldp-= interop/ This initial review has been prompted by the spring WG chairs in parallel w= ith a call for WG adoption. As such, this document qualifies for "initial = QA review". Please could you provide your initial comments in the next 3 w= eeks? As per the QA process, we would also like you to stay with the docum= ent and review it again when it goes to WG last call. The following web page contains a briefing on the QA process, and guidance = for the QA reviewer. https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa Please copy your comments to the spring and rtgdir mailing lists. Please let me know whether you can do it, or not. Many thanks Jon --_000_DB3PR03MB0780A7F30E35B8D04B020BE79D8D0DB3PR03MB0780eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

My na= me is Sasha Vainshtein, and  I have been asked to perform the QA revie= w of https:/= /datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing-ldp-interop= /.

 = ;

Due t= o health problems I have been very late (but, hopefully, not too late) with= this review, and here it is.

 = ;

Do= es the draft solves a real problem? From my POV, definitely yes.

   = ;       1.  = ;       The problem stem= s from the following combination of facts fact that:

a.  &nb= sp;    LDP distributes labels for FECs represented by IP prefixes (among oth= er things).

b.  &nb= sp;   LDP-based MPLS network are very widely deployed

c.  &nb= sp;    SR operating over the MPLS DP allocates labels for SIDs that can repr= esent IP prefixes (again, among other things)

d.  &nb= sp;   As a consequence, LDP and SR may effectively map the same IP prefix t= o different labels.

   = ;       2.  = ;       As SR using the = MPLS DP is gaining acceptance in the industry, the following deployment scenarios look as realistic to me:

a.  &nb= sp;    Coexistence  between LDP-based and SR-based contr= ol planes in the same network

b.  &nb= sp;   Partial deployment of SR in some sub-domains of a netw= ork combined with the operators’ need to use the benefits of SR where it is already deployed

c.  &nb= sp;    Gradual transition of services  (especially L2 an= d L3VPN) tunnelled over LDP-created LSPs to LSPs set up using SR (and, possibly, vice versa)

 

I= s the draft a good enough start for= a WG document? From my POV, = yes.

1  &nbs= p;      The draft covers multiple (if not all) realistic use c= ases for coexistence of LDP-based and SR-based control planes and provides  what looks to me as reasonable solutions for these scen= arios.

2  &nbs= p;      At the same I would think that additional work is requ= ired to complete the work.

<= o:p> 

Sp= ecific issues with the current draft:

1  &nbs= p;      Editorial: SR-related abbreviations (e.g., SRGB, SID etc.) are used without expansion= at the first use, and there is no “Abbreviation” section in th= e draft.

2  &nbs= p;      Process/Editorial: The draft currently lists 12 authors on its title page exceeding the recom= mended RFC Editor maximum of 5 authors.

&n= bsp;         3.  = ;       Technical: The draft does not analyse the use case  of coexistence between SR an= d LDP with enabled extension for multi-area LSPs as per RFC 5283. I think t= hat this use case deserves special consideration in the draft because:

a.=        It mentions the use case of seamless MPLS and refers t= o the (expired) Seamless MPLS Architecture= draft

b.=        The seamless MPLS Architecture draft, in its tur= n, explicitly refers to RFC 5283 in Section 5.1.1 to facilitate binding of labels received via the DoD LDP session while only default rout= e is configured in the RIB of the access node in the seamless MPLS architec= ture

c.=        It is possible that this use case would not add anythi= ng to the draft – but I would prefer to see it in the document with the appropriate explanation

&n= bsp;         4.  = ;       Technical: Section 8 “Manageability Considerations” is currently left emp= ty. When this section is written, I would expect at least the following:

a.=        Some level of detail regarding local  policies de= fining whether LDP-created or SR-created LSPs should be used etc.

b.=       Discussion of using LSP Ping for LSPs that are produce= d by stitching an LDP segment with an SR one.

c.=        Alternatively, it is possible to move this section to = a separate dedicated draft

&n= bsp;         5.  = ;       Technical: I think more information= should be provided in Section 5 to explain operational aspects of SR-assis= ted LDP FR:

a.=        In Section 5.1 I would expect the draft to explain tha= t:

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            i.  = ;    Node D is selected as the RLFA usi= ng the same logic  that is defined for selecting RLFA in RFC 7490

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          ii. &nbs= p;    The “bypass LSP” is s= et up by the SR CP automatically without any need for management intervention

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;         iii. &nb= sp;    I would like to understand why d= ynamically set up Targeted LDP sessions are an operational concern. Such sessions appear also when BG= P-based auto-discovery for L2VPN is used, and, according to the analysis in= RFC 7490, the scalability problems associated with these sessions look as = negligible.

b.=       In Section 5.2 I would expect the draft to explain tha= t:

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            i.  = ;    The resulting solution is similar = to using a bypass LSP to a manually selected RLFA that is set up by RSVP-TE (the difference is t= hat a Targeted LDP session to such an RLFA would be still needed)

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          ii. &nbs= p;    Set up of the  “traffi= c-engineered bypass LSP” by the SR CP is triggered by an appropriate management operation

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;         iii. &nb= sp;    What information should be provi= ded by the Management Plane for computing the RLFA and the traffic-engineered  bypass LSP? = Should it be similar to configuration parameters used with RSVP-TE?

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;        iv. &nbs= p;    Which kind of logic should be res= ponsible for computing the RLFA and the path to be taken by the engineered bypass LSP: should it = be similar to the CSPF used with RSVP-TE?

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          v.  = ;    How the traffic-engineered bypass = LSP hat is set up by the SR CP would react to additional changes in the network topology (the b= ehaviour of the bypass LSP that is set by RSVP-TE in these situations is we= ll known).

<= o:p> 

Neith= er of the issues listed above should be considered as preventing adoption o= f the draft as a WG document IMO. Actually I think that resolving these issues in the context of a WG document would be more effective.

&n= bsp;

Hopef= ully these notes will be useful.=

 = ;

Reg= ards,

Sas= ha

&nb= sp;

Office: +972-3= 9266302

Cell:  &= nbsp;   +972-549266302

Email:  = Alexander.Vainshtein@ecitele.com

 

From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswit= ch.com]
Sent: Wednesday, May 20, 2015 12:46 PM
To: Alexander Vainshtein
Cc: bruno.decraene@orange.com; jgs@juniper.net; Alvaro Retana (areta= na); Jon Hudson
Subject: Routing directorate QA review of draft-filsfils-spring-segm= ent-routing-ldp-interop

 

Hi Sa= sha

 = ;

Pleas= e would you be the routing directorate QA reviewer for draft-filsfils-sprin= g-segment-routing-ldp-interop?

https://datatracker.ietf.org/doc/draft-filsfils-sprin= g-segment-routing-ldp-interop/

 = ;

This = initial review has been prompted by the spring WG chairs in parallel with a= call for WG adoption.  As such, this document qualifies for “initial QA review”.  Please could you provide your initi= al comments in the next 3 weeks?  As per the QA process, we would also= like you to stay with the document and review it again when it goes to WG = last call.

 = ;

The f= ollowing web page contains a briefing on the QA process, and guidance for t= he QA reviewer.

htt= ps://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa

 = ;

Pleas= e copy your comments to the spring and rtgdir mailing lists.

 = ;

Pleas= e let me know whether you can do it, or not.

 = ;

Many = thanks

Jon

 = ;

 = ;

--_000_DB3PR03MB0780A7F30E35B8D04B020BE79D8D0DB3PR03MB0780eurp_-- From nobody Wed Jul 29 00:26:50 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99DCB1B33B8 for ; Wed, 29 Jul 2015 00:26:48 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFtbZkkp1BRr for ; Wed, 29 Jul 2015 00:26:45 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0123.outbound.protection.outlook.com [65.55.169.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B73081B33B5 for ; Wed, 29 Jul 2015 00:26:44 -0700 (PDT) Received: from CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) by CO1PR05MB476.namprd05.prod.outlook.com (10.141.72.25) with Microsoft SMTP Server (TLS) id 15.1.219.17; Wed, 29 Jul 2015 07:26:42 +0000 Authentication-Results: cisco.com; dkim=none (message not signed) header.d=none; Received: from hannes-mba.local (193.110.55.13) by CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) with Microsoft SMTP Server (TLS) id 15.1.219.17; Wed, 29 Jul 2015 07:26:41 +0000 Received: from hannes-mba.local (localhost [IPv6:::1]) by hannes-mba.local (Postfix) with ESMTP id 842D7158D287; Wed, 29 Jul 2015 09:26:31 +0200 (CEST) Date: Wed, 29 Jul 2015 09:26:31 +0200 From: Hannes Gredler To: Peter Psenak Message-ID: <20150729072631.GD6710@hannes-mba.local> References: <20150624230327.12191.65118.idtracker@ietfa.amsl.com> <20150721123459.GA1274@puck.nether.net> <6740_1437490344_55AE5CA8_6740_5026_1_9E32478DFA9976438E7A22F69B08FF92166A3315@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <20150727084750.GB25444@hannes-mba.local> <55B5F5C1.9050201@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <55B5F5C1.9050201@cisco.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [193.110.55.13] X-ClientProxiedBy: DB4PR06CA0017.eurprd06.prod.outlook.com (25.160.40.145) To CO1PR05MB443.namprd05.prod.outlook.com (10.141.73.152) X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB443; 2:9DcUYeE873a/6psSvYVlhZAbTY+f+aLV5FM3KvBaBISNuYuMcGFenjvsqCyKf1cX; 3:b97NhCOQ1eKIewAlHYMBHUP0loAgsnxVQ7xaduW8iWBvG/CPVrcwqYgPNbb1Pv/F4IGiJiZk8Cs0u8FgHnrxX1iti52r0srAC9aCtuP4mLHhoofELTxzOBv1U55h+Plf5TZpMkG+YbvELRbUBaCNwA==; 25:GYIHLJ6M2tw8c3g9hxUgQy1RJ91vJsrrwpPJ7uJo7JxSYj8HlqZ6+lBLNB+JqgIghy8KVVMRxPgxzR4ivy/XLS5L+Eq2RHg3a+Bzmk5CAZEAtB4npBxzgthZRe3CBYPg5Bz1git7gQwkWt8qzZX4D6ybsEIDMyyRhAkSwNRfqwWzhemy5DdRHSofNoh5dT8e1tLrM2wknlOUlARynNz0RqiQwdMum1YymieG3jKExSG9DBrshqDl0zkvFJ7fqEaGo1NYEI55/qn71n89BkgCxg== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB443; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB476; X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB443; 20:HTHXDZQLTvNVSWJlzuNjcEDpkWedU0NXOytsGKLloOjSIZGNzIHBnpNIbkEG9vXcz897JZTWQfy0Fq1ingNnFuDUt2IA02DdhyU00ASroNtGInf8A3tmqv0e8D6FFnSz30FwJzM5RCdYd5jqsARPIIbybo9R4OYVgWVY/uvSB8GTS8GoDNwkV+HLmHr/m/J493cszbPC//1sCve10YZPak/RQMILjEDg2fPayzQs0kxo5ydRv8CTK01D8thTSY/d9Cw0aMrrk+K1QY2JpOmf8wADw/Dh19rNTL3v0euacJpa/gcFflt2fWSSuxFoamxJDVptMODBlwzH5qOBw3WM27wCtZFFlSA6YIrwfByxNmRTUB9rEwl1zlzt5LHpTnvf8L+2XBn8MP1xjQtw9/iumu0mss+3p9jqzWt8HQ7Qex0UsGQyLKCK8r6jsJbNa+zIYsmbkXHT2DaWdR4QuVTNDIrbXqbPP0+/S+qZbh3dHlIMnndImy6IeI8TV9dQ4/Qg; 4:cBwyyMHf2vitRHRZIf2hqVdAYamFl3C/44/VxWFYGyiHjJzuvxOrGrywcv4ODmXSXBU2NH/1+B2q0U+E3qMvsubNxgTOhwlP7aDEXcKWGHFEY2koWSGUPPvOMAdd32HSPN2M/3XnkkhJHhd/x6s/Xf4wJ3FtKIzN8YC32YsmVnda5fGhJEYH3cnjQOlAO7GeptHLLhG2TjwJHK3BkQ/jX9AgQW5sVwhEhDumfYgeXmWxoGpLpfaFgVJSJDayHIBE8U+IAFlsh5PsFpK1X3Tj1y2VoT24rfXgvXT60f7mvA8= CO1PR05MB443: X-MS-Exchange-Organization-RulesExecuted X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB443; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB443; X-Forefront-PRVS: 0652EA5565 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(164054003)(479174004)(13464003)(24454002)(377454003)(110136002)(81156007)(77156002)(23726002)(5001960100002)(5003600100002)(189998001)(76506005)(19580405001)(86362001)(230783001)(46406003)(93886004)(33656002)(561944003)(83506001)(98436002)(105586002)(4001350100001)(50986999)(122386002)(2950100001)(62966003)(92566002)(15975445007)(46102003)(122856001)(19580395003)(50466002)(87976001)(47776003)(40100003)(66066001)(77096005)(76176999)(97756001)(54356999)(5890100001)(579124003)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB443; H:hannes-mba.local; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CO1PR05MB443; 23:Zt2MRkcoAf1Rm1g0hx98eSSFr3WReSJ43BV7lFMYpL?= =?us-ascii?Q?RsKwATZoE897jlHvkDt4GcLksaoifsm22cF9pxWxdBa3ZI0iN9mOItIXc29g?= =?us-ascii?Q?YqNBFmnLbgkazgThSdr1ssO7sfHGMS8GQHh1mrIFQe650QrMd5JlXtoKPwdt?= =?us-ascii?Q?KpClUTrjFU0o/HFmvhs6rZ3zDzFsAWtTK6BkW+uwUdlMitvGGMps+mRFsidV?= =?us-ascii?Q?N2y0d1vDH09bufAzhWQmSczG+DnN1HckY1+LIfSncimikvWQS/VSXkl0Iyog?= =?us-ascii?Q?umoxTx1o+gh4ayQ1YbQzRzsXLQgch+p/n48yg5FGRXLHfoWwpmTpq2h8Wh5f?= =?us-ascii?Q?QVvEjo4ruPgQ1icdAVm2mLls4FP8UERaSKvjo5GaUsMevRxFU5ZhOGfZMC6y?= =?us-ascii?Q?vIvRQWcFmiJii1aLfii3KJAbfCUzrhLGOmpyJ8sjCt5sfb0tRlc6hafTbfXk?= =?us-ascii?Q?zK3Cyz7wmaspJLT+jMbgSW2N9SJvPJ1VEKrmCcC7fGbcGqMo6a5cBYSIkO1M?= =?us-ascii?Q?8l3mMuijk4j0PhiFSQbtksk3ZahCUhEw2jL1koQKwQjfov+BAn/lLgpWgubR?= =?us-ascii?Q?a1juODtS3O4hOCQGkXXjiZEh4jBGrH5/0tifv+4YCmZadR5nS5IMoBOfzL0g?= =?us-ascii?Q?3Wp7fRv/M9u7JzzLj/9fxq6TMejvNcvaQb/x9wA8iTsrYEuqAswncJdXX3m7?= =?us-ascii?Q?ocxrCnkBWWXI3G7lqD5K6MWzZeN5RNcxrXC5rCU1DF4L9lxAvAXDVfiuGpLc?= =?us-ascii?Q?o4lppkuFLvP0f3a7HCsrfrsd0TgZYC6BQ5sBu8dvii0snr2n89cDyWq57WCX?= =?us-ascii?Q?jrx/skIZBk/X7HP+4u13NhVEjUwPfgDF18jNHd+KQJ3lGh9a1OtKDREAB7X2?= =?us-ascii?Q?XOJyvzaD45rEW16I5JDo1scxZW87b/Yhy1cvkP1ZvJP48kfgZOqsIPI2+3fq?= =?us-ascii?Q?26yFJFK4Gnl1XLls+AKZKQMAZGTV/CXXhdgHe9XClBJ8zYjoMw0Unl2WWhXI?= =?us-ascii?Q?IYDEMoE3dshzXWgVgGdjQFd7OyQZ8KYPU4+qN+EARJwhMmHOh5yqyJlWW6Nr?= =?us-ascii?Q?NXBrIFkJeyrmywD0teP6za55uDTGTomICLlPsIxNy87nbbOpz5rOfKXJlFhd?= =?us-ascii?Q?sLdN0w8QDD7x8VKgxpCoXWbm//sXkqUTYogjXim2wU3kcYhQG8JOwRSUGOXn?= =?us-ascii?Q?zpoilqVkXQjVJimHm6mCSA0dmKv40zbGQNSkhTCcfU89JSMtr6VR36guhxC9?= =?us-ascii?Q?CK0k/tyuPt0fe5PSV2Izjqy2x1hZcme4A+XMh5fcMRzOLO9LiS9dBIqGAPvw?= =?us-ascii?Q?=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB443; 5:862o5QgwyTm0RyKxOJvzElvB7A14zpTzeDJ4N2nv7IHVrnsLOAV3W/w3cgc7SsQcA3y0ivN8kR8Qr1lBn0s/LjzGPvk0cGYASKiLoESm44Ispz3VgZGjAoklI8qpcyKI9exHslnnmeoF9iFHZnb46Q==; 24:wIZ0BInFWVwI8ecR+udgpOtAZbo86qDVOE6a04egpvCoDrYRoh415rWVB7ql+zfNg4Il73kYK1POYvElUjgcmQOr+0XZgzU80iJfLh6zQB8=; 20:UHJuNmO9QguLqbHBlgNlX/tfq1GAt26mUcFMpoZfbD2CGTZ+i54c3EEzVjKaFl3E2DP34oXFfq+JqK5t0u0g0Q== X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jul 2015 07:26:41.2894 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB443 X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB476; 2:qkJ8NAwEpP55N0QUvujL5hAax1JEHC+XzuJTmprGuMwOoFo5/2X7ZqpS+YmMB+ve; 3:/zTGcfTXXHiTaB7mQbSxWF/7KwtWyzZzFulF0UukDkE/0FnRkfnqYVj6jmeRDzcMyE1VUIt5B4ZO/wetnmpBhunAwcCHh0GV1uTQT5EVI7FrlhlKqcnS+XdASApZJNOKdHQXxUMUFCcMyxR8K3c6Dw==; 25:K9rptQDtIUnt1wvM/J51Z4TDiEKEvVJi2rg81QQBg1Kv3Fu+buDkwSCmvrApcYwrX5WnRDmdsjpicF/+W2nxNKF44c/LSR+ZS19BWYZGFVlgmfrao9s7UpjdhR/6SEBvIXlS/hYy2Fz8RrJWMtXWXOLUyzf2bwwVUQWEW1o2qPXs4rEwDyIQXKyhFDIaTvy4moGVq0LuS4mSbzSxexRL+3nQTBuxGZk/fnCloG3RkXxqUsNjmvuypWgqSpuoNn8cZYmT09KfmtV6XkeUwkeabw==; 20:0O3EozQ0CWf9j0bYH9rEMRc4+jZZ1xV3YbcKcY6EsCzyQKwyF9KR0vF9b0/6gHuEhHj7KznhLzBZZihzSGBEZQ==; 23:QjQ8bKs8k+DzkUjOhjlLyfAAO86/dGcdc5mCSQHB8tKNR6UoWizUMDBp2vgLzZ+pyvfDde5dcOntYHC5cmoTT53cM2wvmJ++S/58usWnlkY7PjAr15WTyfzmEhLNzFPupTswBF4sUilso8WzW0HzSi1J5gHNHU2uoWeiwStuvtETU0+j77t/PVS6jX3nn9H39irCCNA0vxfG0dHwnsUCytC7dMUPihhlU9eKEyIwIUIidLf/L5wVqt4+CHBDlVDb CO1PR05MB476: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: juniper.net Archived-At: Cc: "Les Ginsberg \(ginsberg\)" , "spring@ietf.org" , Jon Mitchell , Chris Bowers , "stephane.litkowski@orange.com" Subject: Re: [spring] FW: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jul 2015 07:26:48 -0000 hi peter, how is the computing router supposed to know that the downstream router supports this per-algo partitioning of the label-space ? i mena by looking at the downstream routers announcment, how can it "see" that the downstream router is bringing indeed the packet closer to the destination and is not just a "ordinary" router with a large SRGB space ? and how do you want to detect misconfigurations e.g. "dislike offsets for algos". lets say we have the following sample network. R1----R2----R3 each router is advertising a SRGB [16000, 17999]. we have two algorithms (0 and 2 (latency based SPF)) now there is a misconfiguration such that R2 maps the algo2 to SRGB offset 750, where everybody else does it to 500. so when R1 calculates the algo 2 destination to R3 it pushes an outgoing label of 16000+500+R3Idx which R2 does not understand (R2 has a per-algo offset of 750) result is blackhole, worst case forward somewhere where it loops. thoughts ? /hannes On Mon, Jul 27, 2015 at 11:11:29AM +0200, Peter Psenak wrote: | Hi Hannes, | | On 7/27/15 10:47 , Hannes Gredler wrote: | >hi les, | > | >assuming option 1 and a local knob e.g. 'algorithm offset ' | >as per your example below i got the following question(s): | > | >1) how does a computing router know that a downstream router has got | > the 'offset per-algo knob' configured, such that it can map outgoing label values | > to the correct label value (SRGB + algo offset) of the downstream routers ? - | | there is no need for the computing node to know. | | Let's assume we have a node N that has single SRGB (16000-23999) and it | supports 4 algorithms. Internally the node splits its SRGB to 4 blocks, one | per algorithm: | | alg 0: [16000, 17999] | alg 1: [18000, 19999] | alg 2: [20000, 21999] | alg 3: [22000, 23999] | | For prefix P1 on node N, user configures single index 25. Node N then | advertises: | | SID 16025 - alg 0 | SID 18025 - alg 1 | SID 20025 - alg 2 | SID 22025 - alg 3 | | thanks, | Peter | | > | >2) is the expectation that 'algorithm offset ' is configured identical | > on all the routers in the network ? | > | >3) if so - isn't this considered a rather 'fragile / error prone' | > approach to operating a network ? | > | >/hannes | > | >On Tue, Jul 21, 2015 at 08:58:51PM +0000, Les Ginsberg (ginsberg) wrote: | >| Stephane/Chris - | >| | >| | >| | >| Defining an offset, whether explicitly as Ahmed/Jon have suggested or | >| implicitly as the draft Option #2 defines can be problematic in either | >| case. | >| | >| | >| | >| If you don't plan for as many labels as you might need in the future then | >| when the day comes when you run out of labels you need to allocate more. | >| | >| | >| | >| If I use one SRGB for all algorithms, then I have the (non-disruptive) | >| options of: | >| | >| | >| | >| . Extending the existing SRGB space | >| | >| . Reserving an additional SRGB space | >| | >| | >| | >| If I use one SRGB for each algorithm, then if I run out of | >| labels/algorithm I have the same options - but now I have to do this for | >| each algorithm specific set of SRGBs. | >| | >| | >| | >| (There are disruptive ways to address this by completely redefining the | >| SRGBs w/o regard to the existing config - but I think we all understand | >| that this option is very undesirable and this is true in both options.) | >| | >| | >| | >| Of course it is better to be generous enough with your initial SRGB | >| allocation so as to avoid the need for ever having to extend an SRGB - in | >| which case the amount of label space you need to reserve initially is the | >| same in both cases. | >| | >| (Sorry - no free lunch!! J ) | >| | >| | >| | >| Option #1 however avoids a number of issues which complicate Option #2: | >| | >| | >| | >| Under Option #2 support for a new algorithm now requires not only | >| advertising support for the algorithm but also advertising a new (set of) | >| algorithm specific SRGB ranges. We have to check for the presence of both | >| algorithm support and the algorithm specific SRGB(s) before declaring a | >| node as supporting a given algorithm. Each of these algorithm specific set | >| of ranges has to be checked for both intra-algorithm consistency (no | >| overlap within the algorithm specific ranges) and inter-algorithm | >| consistency. | >| | >| | >| | >| I would also suggest that for many implementations, any reservation of | >| label space AFTER startup can be problematic. Label space is typically | >| managed by declaring two types of ranges: | >| | >| | >| | >| 1)reserved for a specific use (like segment routing) | >| | >| 2)available for dynamic allocation (unreserved) | >| | >| | >| | >| The unreserved space is typically everything that isn't reserved. If I | >| need to reserve additional space after startup I face the possibility that | >| some of the additional range I would like to reserve may be in use via | >| dynamic allocation. In such a case I cannot successfully reserve the range | >| until all the existing dynamic allocations are released - which can be | >| awkward to do and may very well be disruptive to the entity using the | >| dynamically allocated labels. So this is best avoided. | >| | >| | >| | >| I understand why making config easier for the user is desirable - and | >| Option #2 provides that - but it is also easy to do so using Option #1. | >| One can imagine a syntax similar to: | >| | >| | >| | >| algorithm offset | >| | >| And, as described above, this does not require us to reserve more labels | >| than we would need under Option #2. | >| | >| I am not seeing any advantage to Option #2. Though it is well motivated, | >| everything you want to achieve w Option #2 can easily be achieved using | >| Option #1. | >| | >| | >| | >| Les | >| | >| | >| | >| > -----Original Message----- | >| | >| > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of | >| | >| > stephane.litkowski@orange.com | >| | >| > Sent: Tuesday, July 21, 2015 7:52 AM | >| | >| > To: Jon Mitchell; Chris Bowers | >| | >| > Cc: spring@ietf.org | >| | >| > Subject: Re: [spring] FW: New Version Notification for | >| draft-bowers-spring- | >| | >| > adv-per-algorithm-label-blocks-01.txt | >| | >| > | >| | >| > Using an offset may be dangerous as if your network growth your algo1 | >| SIDs | >| | >| > may collision with algo2 SIDs because the offset is no more enough ... | >| (you | >| | >| > always need more ...) using an offset is similar to splitting the SRGB | >| in 2 | >| | >| > SRGBs with the limitation of not being able to extend the first part. | >| Option 2 | >| | >| > allows this extension. | >| | >| > You may say let's put a very very large SRGB and offset of +20000 ... | >| yes but | >| | >| > it's wasting resources ... | >| | >| > | >| | >| > | >| | >| > | >| | >| > -----Original Message----- | >| | >| > From: spring [[1]mailto:spring-bounces@ietf.org] On Behalf Of Jon | >| Mitchell | >| | >| > Sent: Tuesday, July 21, 2015 14:35 | >| | >| > To: Chris Bowers | >| | >| > Cc: [2]spring@ietf.org | >| | >| > Subject: Re: [spring] FW: New Version Notification for | >| draft-bowers-spring- | >| | >| > adv-per-algorithm-label-blocks-01.txt | >| | >| > | >| | >| > On 24/06/15 23:09 +0000, Chris Bowers wrote: | >| | >| > > This updated version of the draft includes a concrete proposal for | >| ISIS | >| | >| > extensions to implement per-algorithm label blocks. | >| | >| > > | >| | >| > | >| | >| > Chris - | >| | >| > | >| | >| > As you discussed in the meeting today in option 2 (the proposal) there | >| is a | >| | >| > "savings" that is achieved by not allocating a large label space as is | >| required in | >| | >| > option 1 since we may not be able to predict the future of algorithm | >| needs in | >| | >| > the network. But wouldn't you agree that since you are allocating a | >| node | >| | >| > index in every fractured address space (whether required or not) in | >| option 2, | >| | >| > since address space that is partitioned typically consumes more space | >| than | >| | >| > unfractured space (due to loss because of imperfect planning), as you | >| | >| > increase the number of algorithms aren't you more likely to consume more | >| | >| > overall space with this technique? | >| | >| > | >| | >| > Secondly there was a statement made that there is an advantage to option | >| | >| > 2 that it allows easier provisioning of node index value (as it's | >| | >| > reused) per algorithm. Isn't it just as easy for an implementation to | >| allow the | >| | >| > user to just configure a local implementation offset for an algorithm | >| which | >| | >| > requires no protocol changes and has more flexiblity as it doesn't need | >| to be | >| | >| > configured for prefix SID's that don't require it (similar as Ahmed | >| suggested | >| | >| > at the mic, i.e. algorithm 2 = +1000) that could be configured at every | >| node? | >| | >| > Assuming OSS provisions SID's sequentially this seems to work just as | >| well... | >| | >| > | >| | >| > Thanks, | >| | >| > | >| | >| > Jon | >| | >| > | >| | >| > _______________________________________________ | >| | >| > spring mailing list | >| | >| > [3]spring@ietf.org | >| | >| > [4]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 | >| | >| > [5]spring@ietf.org | >| | >| > [6]https://www.ietf.org/mailman/listinfo/spring | >| | >| References | >| | >| Visible links | >| 1. mailto:spring-bounces@ietf.org | >| 2. mailto:spring@ietf.org | >| 3. mailto:spring@ietf.org | >| 4. https://www.ietf.org/mailman/listinfo/spring | >| 5. mailto:spring@ietf.org | >| 6. 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 Wed Jul 29 00:57:11 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D8B1A6FE9 for ; Wed, 29 Jul 2015 00:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w53AgTMTgVeT for ; Wed, 29 Jul 2015 00:57:06 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 436A91A1DBC for ; Wed, 29 Jul 2015 00:57:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13875; q=dns/txt; s=iport; t=1438156625; x=1439366225; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=HVjXXlZxt9FQNZo1GSDc7i50wt967bbHs7CZ65JIaGY=; b=RjrfNS3MEjaPLe2mYc9RXhMVZ7UOwurLLFslZt2YAWmY1EV4L1g6nXTM rcmfq6jw03BYtpqAwYSHRwxz02WPAGu93a9U972cPonQH5KSvHRuSn2rY 0MG4hXL8b0PVY2y5O/CgQY8yFsCcY6Xz+/BNTVcKbksva941BVuxqBZ9j A=; X-IronPort-AV: E=Sophos;i="5.15,569,1432598400"; d="scan'208";a="606085989" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 29 Jul 2015 07:57:03 +0000 Received: from [10.60.140.60] (ams-ppsenak-nitro11.cisco.com [10.60.140.60]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t6T7v2wh004759; Wed, 29 Jul 2015 07:57:03 GMT Message-ID: <55B8874E.7070906@cisco.com> Date: Wed, 29 Jul 2015 09:57:02 +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: Hannes Gredler References: <20150624230327.12191.65118.idtracker@ietfa.amsl.com> <20150721123459.GA1274@puck.nether.net> <6740_1437490344_55AE5CA8_6740_5026_1_9E32478DFA9976438E7A22F69B08FF92166A3315@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <20150727084750.GB25444@hannes-mba.local> <55B5F5C1.9050201@cisco.com> <20150729072631.GD6710@hannes-mba.local> In-Reply-To: <20150729072631.GD6710@hannes-mba.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "Les Ginsberg \(ginsberg\)" , "spring@ietf.org" , Jon Mitchell , Chris Bowers , "stephane.litkowski@orange.com" Subject: Re: [spring] FW: New Version Notification for draft-bowers-spring-adv-per-algorithm-label-blocks-01.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jul 2015 07:57:10 -0000 Hi Hannes, please see inline: On 7/29/15 09:26 , Hannes Gredler wrote: > hi peter, > > how is the computing router supposed to know that the downstream router > supports this per-algo partitioning of the label-space ? > > i mena by looking at the downstream routers announcment, how can it "see" > that the downstream router is bringing indeed the packet closer > to the destination and is not just a "ordinary" router with a large > SRGB space ? and how do you want to detect misconfigurations e.g. > "dislike offsets for algos". there is an 'Algorithm' field in the Prefix SID Sub-TLV, so receiving router knows which algo is each SID associated with. There is no need for offsets to be consistent on all routers. The only requirement is for each SID to be unique. > > > lets say we have the following sample network. > > R1----R2----R3 > > each router is advertising a SRGB [16000, 17999]. > we have two algorithms (0 and 2 (latency based SPF)) > now there is a misconfiguration such that R2 maps the algo2 > to SRGB offset 750, where everybody else does it to 500. > > so when R1 calculates the algo 2 destination to R3 it > pushes an outgoing label of 16000+500+R3Idx which > R2 does not understand (R2 has a per-algo offset of 750) > result is blackhole, worst case forward somewhere where it > loops. R3 advertises two SIDs: 1. alg 0 25 2. alg 2 525 when R1 calculates the algo 2 destination to R3 it pushes an outgoing label of 16525, nothing changes to the regular SR with alg 0. Offset used on R2 is orthogonal to the rest of the routers. It is only used for making configuration easier on R2 (one index is configured for local prefix on R2, but 2 SIDs are advertised, one per algo) . As far as the SIDs are unique, there is no problem. thanks, Peter > > thoughts ? > > /hannes > > On Mon, Jul 27, 2015 at 11:11:29AM +0200, Peter Psenak wrote: > | Hi Hannes, > | > | On 7/27/15 10:47 , Hannes Gredler wrote: > | >hi les, > | > > | >assuming option 1 and a local knob e.g. 'algorithm offset ' > | >as per your example below i got the following question(s): > | > > | >1) how does a computing router know that a downstream router has got > | > the 'offset per-algo knob' configured, such that it can map outgoing label values > | > to the correct label value (SRGB + algo offset) of the downstream routers ? - > | > | there is no need for the computing node to know. > | > | Let's assume we have a node N that has single SRGB (16000-23999) and it > | supports 4 algorithms. Internally the node splits its SRGB to 4 blocks, one > | per algorithm: > | > | alg 0: [16000, 17999] > | alg 1: [18000, 19999] > | alg 2: [20000, 21999] > | alg 3: [22000, 23999] > | > | For prefix P1 on node N, user configures single index 25. Node N then > | advertises: > | > | SID 16025 - alg 0 > | SID 18025 - alg 1 > | SID 20025 - alg 2 > | SID 22025 - alg 3 > | > | thanks, > | Peter > | > | > > | >2) is the expectation that 'algorithm offset ' is configured identical > | > on all the routers in the network ? > | > > | >3) if so - isn't this considered a rather 'fragile / error prone' > | > approach to operating a network ? > | > > | >/hannes > | > > | >On Tue, Jul 21, 2015 at 08:58:51PM +0000, Les Ginsberg (ginsberg) wrote: > | >| Stephane/Chris - > | >| > | >| > | >| > | >| Defining an offset, whether explicitly as Ahmed/Jon have suggested or > | >| implicitly as the draft Option #2 defines can be problematic in either > | >| case. > | >| > | >| > | >| > | >| If you don't plan for as many labels as you might need in the future then > | >| when the day comes when you run out of labels you need to allocate more. > | >| > | >| > | >| > | >| If I use one SRGB for all algorithms, then I have the (non-disruptive) > | >| options of: > | >| > | >| > | >| > | >| . Extending the existing SRGB space > | >| > | >| . Reserving an additional SRGB space > | >| > | >| > | >| > | >| If I use one SRGB for each algorithm, then if I run out of > | >| labels/algorithm I have the same options - but now I have to do this for > | >| each algorithm specific set of SRGBs. > | >| > | >| > | >| > | >| (There are disruptive ways to address this by completely redefining the > | >| SRGBs w/o regard to the existing config - but I think we all understand > | >| that this option is very undesirable and this is true in both options.) > | >| > | >| > | >| > | >| Of course it is better to be generous enough with your initial SRGB > | >| allocation so as to avoid the need for ever having to extend an SRGB - in > | >| which case the amount of label space you need to reserve initially is the > | >| same in both cases. > | >| > | >| (Sorry - no free lunch!! J ) > | >| > | >| > | >| > | >| Option #1 however avoids a number of issues which complicate Option #2: > | >| > | >| > | >| > | >| Under Option #2 support for a new algorithm now requires not only > | >| advertising support for the algorithm but also advertising a new (set of) > | >| algorithm specific SRGB ranges. We have to check for the presence of both > | >| algorithm support and the algorithm specific SRGB(s) before declaring a > | >| node as supporting a given algorithm. Each of these algorithm specific set > | >| of ranges has to be checked for both intra-algorithm consistency (no > | >| overlap within the algorithm specific ranges) and inter-algorithm > | >| consistency. > | >| > | >| > | >| > | >| I would also suggest that for many implementations, any reservation of > | >| label space AFTER startup can be problematic. Label space is typically > | >| managed by declaring two types of ranges: > | >| > | >| > | >| > | >| 1)reserved for a specific use (like segment routing) > | >| > | >| 2)available for dynamic allocation (unreserved) > | >| > | >| > | >| > | >| The unreserved space is typically everything that isn't reserved. If I > | >| need to reserve additional space after startup I face the possibility that > | >| some of the additional range I would like to reserve may be in use via > | >| dynamic allocation. In such a case I cannot successfully reserve the range > | >| until all the existing dynamic allocations are released - which can be > | >| awkward to do and may very well be disruptive to the entity using the > | >| dynamically allocated labels. So this is best avoided. > | >| > | >| > | >| > | >| I understand why making config easier for the user is desirable - and > | >| Option #2 provides that - but it is also easy to do so using Option #1. > | >| One can imagine a syntax similar to: > | >| > | >| > | >| > | >| algorithm offset > | >| > | >| And, as described above, this does not require us to reserve more labels > | >| than we would need under Option #2. > | >| > | >| I am not seeing any advantage to Option #2. Though it is well motivated, > | >| everything you want to achieve w Option #2 can easily be achieved using > | >| Option #1. > | >| > | >| > | >| > | >| Les > | >| > | >| > | >| > | >| > -----Original Message----- > | >| > | >| > From: spring [mailto:spring-bounces@ietf.org] On Behalf Of > | >| > | >| > stephane.litkowski@orange.com > | >| > | >| > Sent: Tuesday, July 21, 2015 7:52 AM > | >| > | >| > To: Jon Mitchell; Chris Bowers > | >| > | >| > Cc: spring@ietf.org > | >| > | >| > Subject: Re: [spring] FW: New Version Notification for > | >| draft-bowers-spring- > | >| > | >| > adv-per-algorithm-label-blocks-01.txt > | >| > | >| > > | >| > | >| > Using an offset may be dangerous as if your network growth your algo1 > | >| SIDs > | >| > | >| > may collision with algo2 SIDs because the offset is no more enough ... > | >| (you > | >| > | >| > always need more ...) using an offset is similar to splitting the SRGB > | >| in 2 > | >| > | >| > SRGBs with the limitation of not being able to extend the first part. > | >| Option 2 > | >| > | >| > allows this extension. > | >| > | >| > You may say let's put a very very large SRGB and offset of +20000 ... > | >| yes but > | >| > | >| > it's wasting resources ... > | >| > | >| > > | >| > | >| > > | >| > | >| > > | >| > | >| > -----Original Message----- > | >| > | >| > From: spring [[1]mailto:spring-bounces@ietf.org] On Behalf Of Jon > | >| Mitchell > | >| > | >| > Sent: Tuesday, July 21, 2015 14:35 > | >| > | >| > To: Chris Bowers > | >| > | >| > Cc: [2]spring@ietf.org > | >| > | >| > Subject: Re: [spring] FW: New Version Notification for > | >| draft-bowers-spring- > | >| > | >| > adv-per-algorithm-label-blocks-01.txt > | >| > | >| > > | >| > | >| > On 24/06/15 23:09 +0000, Chris Bowers wrote: > | >| > | >| > > This updated version of the draft includes a concrete proposal for > | >| ISIS > | >| > | >| > extensions to implement per-algorithm label blocks. > | >| > | >| > > > | >| > | >| > > | >| > | >| > Chris - > | >| > | >| > > | >| > | >| > As you discussed in the meeting today in option 2 (the proposal) there > | >| is a > | >| > | >| > "savings" that is achieved by not allocating a large label space as is > | >| required in > | >| > | >| > option 1 since we may not be able to predict the future of algorithm > | >| needs in > | >| > | >| > the network. But wouldn't you agree that since you are allocating a > | >| node > | >| > | >| > index in every fractured address space (whether required or not) in > | >| option 2, > | >| > | >| > since address space that is partitioned typically consumes more space > | >| than > | >| > | >| > unfractured space (due to loss because of imperfect planning), as you > | >| > | >| > increase the number of algorithms aren't you more likely to consume more > | >| > | >| > overall space with this technique? > | >| > | >| > > | >| > | >| > Secondly there was a statement made that there is an advantage to option > | >| > | >| > 2 that it allows easier provisioning of node index value (as it's > | >| > | >| > reused) per algorithm. Isn't it just as easy for an implementation to > | >| allow the > | >| > | >| > user to just configure a local implementation offset for an algorithm > | >| which > | >| > | >| > requires no protocol changes and has more flexiblity as it doesn't need > | >| to be > | >| > | >| > configured for prefix SID's that don't require it (similar as Ahmed > | >| suggested > | >| > | >| > at the mic, i.e. algorithm 2 = +1000) that could be configured at every > | >| node? > | >| > | >| > Assuming OSS provisions SID's sequentially this seems to work just as > | >| well... > | >| > | >| > > | >| > | >| > Thanks, > | >| > | >| > > | >| > | >| > Jon > | >| > | >| > > | >| > | >| > _______________________________________________ > | >| > | >| > spring mailing list > | >| > | >| > [3]spring@ietf.org > | >| > | >| > [4]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 > | >| > | >| > [5]spring@ietf.org > | >| > | >| > [6]https://www.ietf.org/mailman/listinfo/spring > | >| > | >| References > | >| > | >| Visible links > | >| 1. mailto:spring-bounces@ietf.org > | >| 2. mailto:spring@ietf.org > | >| 3. mailto:spring@ietf.org > | >| 4. https://www.ietf.org/mailman/listinfo/spring > | >| 5. mailto:spring@ietf.org > | >| 6. 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 Wed Jul 29 05:10:49 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4D0E1A870A for ; Wed, 29 Jul 2015 05:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IC0He4Jtp2xj for ; Wed, 29 Jul 2015 05:10:44 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7C31A1B7B for ; Wed, 29 Jul 2015 05:10:44 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda12.si.francetelecom.fr (ESMTP service) with ESMTP id A5D7E3B4A18; Wed, 29 Jul 2015 14:10:42 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.2]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 7B627C80F4; Wed, 29 Jul 2015 14:10:39 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0248.002; Wed, 29 Jul 2015 14:10:39 +0200 From: To: Uma Chunduri , "Les Ginsberg (ginsberg)" , "Aissaoui, Mustapha (Mustapha)" , "spring@ietf.org" , "Shraddha Hegde (shraddha@juniper.net)" , "Pushpasis Sarkar (psarkar@juniper.net)" , "Hannes Gredler (hannes@juniper.net)" Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQxXDqt9XtTVUIwUOWTYSujokuPp3pPS4AgAAuawCAASqngIAHzVJQ Date: Wed, 29 Jul 2015 12:10:39 +0000 Message-ID: <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> In-Reply-To: <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92166B7B57OPEXCLILMA4corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.16.85415 Archived-At: Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jul 2015 12:10:48 -0000 --_000_9E32478DFA9976438E7A22F69B08FF92166B7B57OPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, What if we keep the SRGB block config in "segment-routing" global module, a= nd if we allow for YANG configuration of carving this block inside each pro= tocol (maybe as a feature) ? Stephane From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] Sent: Friday, July 24, 2015 16:59 To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI Steph= ane SCE/IBNF; spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang >Suggesting that the forwarding instruction (AKA label) needs to be differ= ent depending on what protocol provided >the instruction is completely unnecessary - it simply wastes label space. [Uma]: Les, No - I never suggested anything like that. SRGB for a routing instance to be advertised should be part of the routing = instance provisioning as far as the yang model is concerned. Carving out the label space for SR is a local matter and agree, of course, = this can be done in so many ways through CLI, dynamically, statically etc.= .. -- Uma C. ___________________________________________________________________________= ______________________________________________ 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_9E32478DFA9976438E7A22F69B08FF92166B7B57OPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

What if we keep the SR= GB block config in “segment-routing” global module, and if we a= llow for YANG configuration of carving this block inside each protocol (may= be as a feature) ?

 

Stephane

 

 

From: Uma Chun= duri [mailto:uma.chunduri@ericsson.com]
Sent: Friday, July 24, 2015 16:59
To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSK= I Stephane SCE/IBNF; spring@ietf.org
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

 

>Suggesting that the forwarding instruction (AKA label)  needs= to be different depending on what protocol provided

>the instruction is completely unnecessary – it simply wastes= label space.

 

[Uma]: Les, No - I nev= er suggested anything like that.

SRGB for a routing ins= tance to be advertised should be part of the routing instance provisioning = as far as the yang model is concerned.

Carving out the label = space for SR is a local matter and agree, of course, this  can be done= in so many ways through CLI, dynamically, statically etc...

 

--

Uma C.

 

______________________________________________________________________=
___________________________________________________

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_9E32478DFA9976438E7A22F69B08FF92166B7B57OPEXCLILMA4corp_-- From nobody Wed Jul 29 05:53:07 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F10021A8A84; Wed, 29 Jul 2015 05:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_MY_NAME_IS=0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xox39FM2MT5; Wed, 29 Jul 2015 05:52:56 -0700 (PDT) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0705.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::705]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADBF21A8A7F; Wed, 29 Jul 2015 05:52:43 -0700 (PDT) Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0779.eurprd03.prod.outlook.com (10.161.55.11) with Microsoft SMTP Server (TLS) id 15.1.225.19; Wed, 29 Jul 2015 12:52:26 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0225.018; Wed, 29 Jul 2015 12:52:27 +0000 From: Alexander Vainshtein To: "rtg-ads@tools.ietf.org" Thread-Topic: Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop Thread-Index: AdDJU4roffYaBLXOTjabFYQ9m7cUoAApb99Q Date: Wed, 29 Jul 2015 12:52:26 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tools.ietf.org; dkim=none (message not signed) header.d=none; x-originating-ip: [109.66.1.206] x-microsoft-exchange-diagnostics: 1; DB3PR03MB0779; 5:bCnfCQ6yGm8Avp5Pv3G2L6/yv0ddhft+HRVwo8FXybR4JmfJ+ujDsUFdILPgdfeK+2d6KkRgknF4grsP7YpV2ZTnDpqxUbVov1a1MLWsfogxcMJs6eo/xQpS+8U0HvT43vvdgJyUT8Jt75SXZ/WqpA==; 24:4+2nFIfuhst80kX3iWBIYABz93vCz5i0npgxdX7zHOKIbRGnvekKWsQLCBe9S++OozZTPYzcXq10DRx5Hg+H2fNuyPXV4MxPrv+M6aMcbFM=; 20:Wrtkoc3jeQw+sYZu2lH1+AfYIfM5hSkfP1KpRtHdeRPUPRaIWtZj8qRV51HDp3Fcy8+twoqlmnbpxlxbdzq2hw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0779; db3pr03mb0779: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB3PR03MB0779; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0779; x-forefront-prvs: 0652EA5565 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(37854004)(252514010)(66654002)(46102003)(76576001)(66066001)(19580405001)(86362001)(19625215002)(33656002)(54356999)(19609705001)(102836002)(50986999)(16236675004)(2656002)(230783001)(19580395003)(87936001)(74316001)(555904002)(19300405004)(5003600100002)(77156002)(122556002)(62966003)(92566002)(15975445007)(19617315012)(5002640100001)(2351001)(77096005)(5001920100001)(2501003)(189998001)(110136002)(5001960100002)(40100003)(2900100001)(559001)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0779; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB3PR03MB0780CB9ACC0130DDBDAF32919D8C0DB3PR03MB0780eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2015 12:52:26.8819 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0779 Archived-At: Cc: Jonathan Hardwick , "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" Subject: Re: [spring] Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jul 2015 12:53:04 -0000 --_000_DB3PR03MB0780CB9ACC0130DDBDAF32919D8C0DB3PR03MB0780eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, My previous message has been put on hold by the moderator of the SPRING WG = as having too many recipients. This is partially due to the draft having 12 authors - and have tried to s= end the review to each of them:). I am now re-sending it with a shorter (but, hopefully, sufficient - I belie= ve all the authors are on the SPRING mailing list anyway) list of recipient= s and with one more issue I have found in the draft - highlighted. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Alexander Vainshtein Sent: Tuesday, July 28, 2015 7:37 PM To: 'rtg-ads@tools.ietf.org' Cc: bruno.decraene@orange.com; jgs@juniper.net; Jon Hudson; 'Jonathan Hardw= ick'; 'rtg-dir@ietf.org'; 'spring@ietf.org'; mpls@ietf.org; 'cfilsfil@cisco= .com'; 'sprevidi@cisco.com'; 'bashandy@cisco.com'; 'stephane.litkowski@oran= ge.com'; 'Martin.Horneffer@telekom.de'; 'igormilojevic@telekom.rs'; 'rob.sh= akir@bt.com'; 'saku@ytti.fi'; 'wim.henderickx@alcatel-lucent.com'; 'Jeff Ta= ntsura (jeff.tantsura@ericsson.com)'; 'edward.crabbe@gmail.com' Subject: RE: Routing directorate QA review of draft-filsfils-spring-segment= -routing-ldp-interop Hi, My name is Sasha Vainshtein, and I have been asked to perform the QA revie= w of https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing= -ldp-interop/. Due to health problems I have been very late (but, hopefully, not too late)= with this review, and here it is. Does the draft solves a real problem? From my POV, definitely yes. 1. The problem stems from the following combination of fa= cts fact that: a. LDP distributes labels for FECs represented by IP prefixes (among = other things). b. LDP-based MPLS network are very widely deployed c. SR operating over the MPLS DP allocates labels for SIDs that can r= epresent IP prefixes (again, among other things) d. As a consequence, LDP and SR may effectively map the same IP prefix= to different labels. 2. As SR using the MPLS DP is gaining acceptance in the i= ndustry, the following deployment scenarios look as realistic to me: a. Coexistence between LDP-based and SR-based control planes in the = same network b. Partial deployment of SR in some sub-domains of a network combined = with the operators' need to use the benefits of SR where it is already depl= oyed c. Gradual transition of services (especially L2 and L3VPN) tunnelle= d over LDP-created LSPs to LSPs set up using SR (and, possibly, vice versa) Is the draft a good enough start for a WG document? From my POV, yes. 1 The draft covers multiple (if not all) realistic use cases for co= existence of LDP-based and SR-based control planes and provides what looks= to me as reasonable solutions for these scenarios. 2 At the same I would think that additional work is required to com= plete the work. Specific issues with the current draft: 1 Editorial: SR-related abbreviations (e.g., SRGB, SID etc.) are us= ed without expansion at the first use, and there is no "Abbreviation" secti= on in the draft. 2 Process/Editorial: The draft currently lists 12 authors on its ti= tle page exceeding the recommended RFC Editor maximum of 5 authors. 3. Technical: The draft does not analyse the use case of= coexistence between SR and LDP with enabled extension for multi-area LSPs = as per RFC 5283= . I think that this use case deserves special consideration in the draft be= cause: a. It mentions the use case of seamless MPLS and refers to the (expir= ed) Seamless MPLS Architecture draft b. The seamless MPLS Architecture draft, in its turn, explicitly refe= rs to RFC 5283 in Section 5.1.1 to facilitate binding of labels received vi= a the DoD LDP session while only default route is configured in the RIB of = the access node in the seamless MPLS architecture c. It is possible that this use case would not add anything to the dr= aft - but I would prefer to see it in the document with the appropriate exp= lanation 4. Technical: Section 8 "Manageability Considerations" is= currently left empty. When this section is written, I would expect at leas= t the following: a. Some level of detail regarding local policies defining whether LD= P-created or SR-created LSPs should be used etc. b. Discussion of using LSP Ping for LSPs that are produced by stitchin= g an LDP segment with an SR one. c. Alternatively, it is possible to move this section to a separate d= edicated draft 5. Technical: I think more information should be provided= in Section 5 to explain operational aspects of SR-assisted LDP FR: a. In Section 5.1 I would expect the draft to explain that: i. Node= D is selected as the RLFA using the same logic that is defined for select= ing RLFA in RFC 7490 ii. The "= bypass LSP" is set up by the SR CP automatically without any need for manag= ement intervention iii. I wou= ld like to understand why dynamically set up Targeted LDP sessions are an o= perational concern. Such sessions appear also when BGP-based auto-discovery= for L2VPN is used, and, according to the analysis in RFC 7490, the scalabi= lity problems associated with these sessions look as negligible. b. In Section 5.2 I would expect the draft to explain that: i. The = resulting solution is similar to using a bypass LSP to a manually selected = RLFA that is set up by RSVP-TE (the difference is that a Targeted LDP sessi= on to such an RLFA would be still needed) ii. Set u= p of the "traffic-engineered bypass LSP" by the SR CP is triggered by an a= ppropriate management operation iii. What = information should be provided by the Management Plane for computing the RL= FA and the traffic-engineered bypass LSP? Should it be similar to configur= ation parameters used with RSVP-TE? iv. Which k= ind of logic should be responsible for computing the RLFA and the path to b= e taken by the engineered bypass LSP: should it be similar to the CSPF used= with RSVP-TE? v. How th= e traffic-engineered bypass LSP hat is set up by the SR CP would react to a= dditional changes in the network topology (the behaviour of the bypass LSP = that is set by RSVP-TE in these situations is well known) c. In both cases it is not clear how the backup label and NHOP are in= stalled: i. In t= he FRR with RLFA as per RFC 7490 this is usually done by LDP that receives= the backup label as bound to the destination prefix FEC via the Targeted L= DP session, retains it and decides to us it when a route to the destination= prefix using the LSP leading to the RLFA as its NHOP is installed in the = RIB as the best route to the destination prefix by IP FRR ii. This = scheme definitely would not work if the Targeted LDP session to the selecte= d RLFA is eliminated iii. From = my POV more details are required here, and the critical question here is, o= f course, when the scheme proposed in the draft requires any changes in LDP= . Neither of the issues listed above should be considered as preventing adopt= ion of the draft as a WG document IMO. Actually I think that resolving thes= e issues in the context of a WG document would be more effective. Hopefully these notes will be useful. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com] Sent: Wednesday, May 20, 2015 12:46 PM To: Alexander Vainshtein Cc: bruno.decraene@orange.com; jgs@junipe= r.net; Alvaro Retana (aretana); Jon Hudson Subject: Routing directorate QA review of draft-filsfils-spring-segment-rou= ting-ldp-interop Hi Sasha Please would you be the routing directorate QA reviewer for draft-filsfils-= spring-segment-routing-ldp-interop? https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing-ldp-= interop/ This initial review has been prompted by the spring WG chairs in parallel w= ith a call for WG adoption. As such, this document qualifies for "initial = QA review". Please could you provide your initial comments in the next 3 w= eeks? As per the QA process, we would also like you to stay with the docum= ent and review it again when it goes to WG last call. The following web page contains a briefing on the QA process, and guidance = for the QA reviewer. https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa Please copy your comments to the spring and rtgdir mailing lists. Please let me know whether you can do it, or not. Many thanks Jon --_000_DB3PR03MB0780CB9ACC0130DDBDAF32919D8C0DB3PR03MB0780eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

My previous message has b= een put on hold by the moderator of the SPRING WG as having too many recipi= ents.

This is partially due to = the draft having 12 authors – and  have tried to send the review= to each of themJ.

 <= /p>

I am now re-sending it wi= th a shorter (but, hopefully, sufficient – I believe all the authors = are on the SPRING mailing list anyway) list of recipients and with one more issue I have found in the draft – highlighted.

 <= /p>

Regards,

Sasha

 <= /p>

Office: +972-39266302=

Cell:   &n= bsp;  +972-549266302

Email:   Alexan= der.Vainshtein@ecitele.com

 <= /p>

From: Alexande= r Vainshtein
Sent: Tuesday, July 28, 2015 7:37 PM
To: 'rtg-ads@tools.ietf.org'
Cc: bruno.decraene@orange.com; jgs@juniper.net; Jon Hudson; 'Jonatha= n Hardwick'; 'rtg-dir@ietf.org'; 'spring@ietf.org'; mpls@ietf.org; 'cfilsfi= l@cisco.com'; 'sprevidi@cisco.com'; 'bashandy@cisco.com'; 'stephane.litkows= ki@orange.com'; 'Martin.Horneffer@telekom.de'; 'igormilojevic@telekom.rs'; 'rob.shakir@bt.com'; 'saku@ytti.fi'; 'wim.hend= erickx@alcatel-lucent.com'; 'Jeff Tantsura (jeff.tantsura@ericsson.com)'; '= edward.crabbe@gmail.com'
Subject: RE: Routing directorate QA review of draft-filsfils-spring-= segment-routing-ldp-interop

 

Hi,

My na= me is Sasha Vainshtein, and  I have been asked to perform the QA revie= w of https:/= /datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing-ldp-interop= /.

 = ;

Due t= o health problems I have been very late (but, hopefully, not too late) with= this review, and here it is.

 = ;

Do= es the draft solves a real problem? From my POV, definitely yes.

   = ;       1.  = ;       The problem stem= s from the following combination of facts fact that:

a.  &nb= sp;    LDP distributes labels for FECs represented by IP prefixes (among oth= er things).

b.  &nb= sp;   LDP-based MPLS network are very widely deployed

c.  &nb= sp;    SR operating over the MPLS DP allocates labels for SIDs that can repr= esent IP prefixes (again, among other things)

d.  &nb= sp;   As a consequence, LDP and SR may effectively map the same IP prefix t= o different labels.

   = ;       2.  = ;       As SR using the = MPLS DP is gaining acceptance in the industry, the following deployment scenarios look as realistic to me:

a.  &nb= sp;    Coexistence  between LDP-based and SR-based contr= ol planes in the same network

b.  &nb= sp;   Partial deployment of SR in some sub-domains of a netw= ork combined with the operators’ need to use the benefits of SR where it is already deployed

c.  &nb= sp;    Gradual transition of services  (especially L2 an= d L3VPN) tunnelled over LDP-created LSPs to LSPs set up using SR (and, possibly, vice versa)

 

I= s the draft a good enough start for= a WG document? From my POV, = yes.

1  &nbs= p;      The draft covers multiple (if not all) realistic use c= ases for coexistence of LDP-based and SR-based control planes and provides  what looks to me as reasonable solutions for these scen= arios.

2  &nbs= p;      At the same I would think that additional work is requ= ired to complete the work.

<= o:p> 

Sp= ecific issues with the current draft:

1  &nbs= p;      Editorial: SR-related abbreviations (e.g., SRGB, SID etc.) are used without expansion= at the first use, and there is no “Abbreviation” section in th= e draft.

2  &nbs= p;      Process/Editorial: The draft currently lists 12 authors on its title page exceeding the recom= mended RFC Editor maximum of 5 authors.

&n= bsp;         3.  = ;       Technical: The draft does not analyse the use case  of coexistence between SR an= d LDP with enabled extension for multi-area LSPs as per RFC 5283. I think t= hat this use case deserves special consideration in the draft because:

a.=        It mentions the use case of seamless MPLS and refers t= o the (expired) Seamless MPLS Architecture= draft

b.=        The seamless MPLS Architecture draft, in its tur= n, explicitly refers to RFC 5283 in Section 5.1.1 to facilitate binding of labels received via the DoD LDP session while only default rout= e is configured in the RIB of the access node in the seamless MPLS architec= ture

c.=        It is possible that this use case would not add anythi= ng to the draft – but I would prefer to see it in the document with the appropriate explanation

&n= bsp;         4.  = ;       Technical: Section 8 “Manageability Considerations” is currently left emp= ty. When this section is written, I would expect at least the following:

a.=        Some level of detail regarding local  policies de= fining whether LDP-created or SR-created LSPs should be used etc.

b.=       Discussion of using LSP Ping for LSPs that are produce= d by stitching an LDP segment with an SR one.

c.=        Alternatively, it is possible to move this section to = a separate dedicated draft

&n= bsp;         5.  = ;       Technical: I think more information= should be provided in Section 5 to explain operational aspects of SR-assis= ted LDP FR:

a.=        In Section 5.1 I would expect the draft to explain tha= t:

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            i.  = ;    Node D is selected as the RLFA usi= ng the same logic  that is defined for selecting RLFA in RFC 7490

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          ii. &nbs= p;    The “bypass LSP” is s= et up by the SR CP automatically without any need for management intervention

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;         iii. &nb= sp;    I would like to understand why d= ynamically set up Targeted LDP sessions are an operational concern. Such sessions appear also when BG= P-based auto-discovery for L2VPN is used, and, according to the analysis in= RFC 7490, the scalability problems associated with these sessions look as = negligible.

b.=       In Section 5.2 I would expect the draft to explain tha= t:

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            i.  = ;    The resulting solution is similar = to using a bypass LSP to a manually selected RLFA that is set up by RSVP-TE (the difference is t= hat a Targeted LDP session to such an RLFA would be still needed)

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          ii. &nbs= p;    Set up of the  “traffi= c-engineered bypass LSP” by the SR CP is triggered by an appropriate management operation

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;         iii. &nb= sp;    What information should be provi= ded by the Management Plane for computing the RLFA and the traffic-engineered  bypass LSP? = Should it be similar to configuration parameters used with RSVP-TE?

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;        iv. &nbs= p;    Which kind of logic should be res= ponsible for computing the RLFA and the path to be taken by the engineered bypass LSP: should it = be similar to the CSPF used with RSVP-TE?

&n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;          v.  = ;    How the traffic-engineered bypass = LSP hat is set up by the SR CP would react to additional changes in the network topology (the b= ehaviour of the bypass LSP that is set by RSVP-TE in these situations is we= ll known)

c.     &= nbsp; In b= oth cases it is not clear how the backup label and NHOP are installed:

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       i.  = ;    In the FRR with RLFA  as per RFC 7490 this is usually done by LDP that recei= ves the backup label as bound to the destination prefix FEC via the Targete= d LDP session, retains it and decides to us it when a route to the destinat= ion prefix using the LSP leading to the RLFA as its NHOP is installed in  the RIB as the best route to the de= stination prefix by IP FRR

     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;     ii. &nbs= p;    <= /span>This scheme definitely would not work if the Targeted LDP session to the select= ed RLFA is eliminated

      =             &nb= sp;            =             &nb= sp;            =     iii. &nb= sp;    From my POV more details are required here, and the critical question here is, of = course, when the scheme proposed in the draft requires any changes in LDP.

 

<= o:p> 

Neith= er of the issues listed above should be considered as preventing adoption o= f the draft as a WG document IMO. Actually I think that resolving these issues in the context of a WG document would be more effective.

&n= bsp;

Hopef= ully these notes will be useful.=

 = ;

Reg= ards,

Sas= ha

&nb= sp;

Office: +972-3= 9266302

Cell:  &= nbsp;   +972-549266302

Email:   Alexander.Vainshtein@ec= itele.com

 

From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com]
Sent: Wednesday, May 20, 2015 12:46 PM
To: Alexander Vainshtein
Cc: bruno.decraene@oran= ge.com; jgs@juniper.net; Alvaro Retana (aret= ana); Jon Hudson
Subject: Routing directorate QA review of draft-filsfils-spring-segm= ent-routing-ldp-interop

 

Hi Sa= sha

 = ;

Pleas= e would you be the routing directorate QA reviewer for draft-filsfils-sprin= g-segment-routing-ldp-interop?

https://datatracker.ietf.org/doc/draft-filsfils-sprin= g-segment-routing-ldp-interop/

 = ;

This = initial review has been prompted by the spring WG chairs in parallel with a= call for WG adoption.  As such, this document qualifies for “initial QA review”.  Please could you provide your initi= al comments in the next 3 weeks?  As per the QA process, we would also= like you to stay with the document and review it again when it goes to WG = last call.

 = ;

The f= ollowing web page contains a briefing on the QA process, and guidance for t= he QA reviewer.

htt= ps://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa

 = ;

Pleas= e copy your comments to the spring and rtgdir mailing lists.

 = ;

Pleas= e let me know whether you can do it, or not.

 = ;

Many = thanks

Jon

 = ;

 = ;

--_000_DB3PR03MB0780CB9ACC0130DDBDAF32919D8C0DB3PR03MB0780eurp_-- From nobody Wed Jul 29 06:13:09 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220761A9165; Wed, 29 Jul 2015 06:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FSL_MY_NAME_IS=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7T9yz6ZzCFk3; Wed, 29 Jul 2015 06:13:05 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00C541A90D2; Wed, 29 Jul 2015 06:13:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10185; q=dns/txt; s=iport; t=1438175586; x=1439385186; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+iA6nGtVhljNNSzcCYAE9A8UWVbVfV5v00s0bZeolEQ=; b=HBzMNEs0d5J4BkVD6p2LjYHSTSw5RNZ+wfXU5Kme5sK76/wwC0YWUoAR dru296KT9umfGPYWXQ/P+BPzberBneZdStEqpRBaNXzO+b8dB/HDT4BNt Q65m5ogb9q6a55zuM76FWqbU5rRPoknTS8WcowaOQDTp0HnWPE6OM4i6m 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgAwA80LhV/4cNJK1bgxVUaQa7fgmBdwyFLUoCgVY4FAEBAQEBAQGBCoQjAQEBAwEBAQEaTwILBQkCAgEIEQEDAQEoBxYLBgsUAwYIAQEEDgUbh34DCggNyW8NhS8BAQEBAQEBAQEBAQEBAQEBAQEBAQETBASLSoJOgU0JEQEeCCsHAgSDEoEUBYcUhTSBJ4cBAYR5hWCBajmBDIQgjB2DS4NjJoIOHBWBPm8BgQ06gQQBAQE X-IronPort-AV: E=Sophos;i="5.15,570,1432598400"; d="scan'208";a="19709749" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-3.cisco.com with ESMTP; 29 Jul 2015 13:13:04 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t6TDD3VD030888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jul 2015 13:13:03 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.72]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Wed, 29 Jul 2015 08:13:03 -0500 From: "Stefano Previdi (sprevidi)" To: Alexander Vainshtein Thread-Topic: [spring] Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop Thread-Index: AdDJU4rozHs9zgL9Q6awOhnek/vb5wApb99QAAw7GIA= Date: Wed, 29 Jul 2015 13:13:02 +0000 Message-ID: <5B43AC77-1C49-407F-90ED-8A35D5D76D88@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.147.74.248] Content-Type: text/plain; charset="Windows-1252" Content-ID: <8AA1D18CF509044DABABC87124551150@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Jonathan Hardwick , "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [spring] Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jul 2015 13:13:08 -0000 Hi Sasha, Many thanks for your review and comments. I'll go through them asap. Thanks. s. On Jul 29, 2015, at 2:52 PM, Alexander Vainshtein wrote: > Hi, > My previous message has been put on hold by the moderator of the SPRING W= G as having too many recipients. > This is partially due to the draft having 12 authors =96 and have tried = to send the review to each of themJ. > =20 > I am now re-sending it with a shorter (but, hopefully, sufficient =96 I b= elieve all the authors are on the SPRING mailing list anyway) list of recip= ients andwith one more issue I have found in the draft =96 highlighted. > =20 > Regards, > Sasha > =20 > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > =20 > From: Alexander Vainshtein=20 > Sent: Tuesday, July 28, 2015 7:37 PM > To: 'rtg-ads@tools.ietf.org' > Cc: bruno.decraene@orange.com; jgs@juniper.net; Jon Hudson; 'Jonathan Har= dwick'; 'rtg-dir@ietf.org'; 'spring@ietf.org'; mpls@ietf.org; 'cfilsfil@cis= co.com'; 'sprevidi@cisco.com'; 'bashandy@cisco.com'; 'stephane.litkowski@or= ange.com'; 'Martin.Horneffer@telekom.de'; 'igormilojevic@telekom.rs'; 'rob.= shakir@bt.com'; 'saku@ytti.fi'; 'wim.henderickx@alcatel-lucent.com'; 'Jeff = Tantsura (jeff.tantsura@ericsson.com)'; 'edward.crabbe@gmail.com' > Subject: RE: Routing directorate QA review of draft-filsfils-spring-segme= nt-routing-ldp-interop > =20 > Hi, > My name is Sasha Vainshtein, and I have been asked to perform the QA rev= iew of https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routi= ng-ldp-interop/. > =20 > Due to health problems I have been very late (but, hopefully, not too lat= e) with this review, and here it is. > =20 > Does the draft solves a real problem? From my POV, definitely yes. > 1. The problem stems from the following combination of = facts fact that: > a. LDP distributes labels for FECs represented by IP prefixes (amon= g other things). > b. LDP-based MPLS network are very widely deployed > c. SR operating over the MPLS DP allocates labels for SIDs that can= represent IP prefixes (again, among other things) > d. As a consequence, LDP and SR may effectively map the same IP pref= ix to different labels. > 2. As SR using the MPLS DP is gaining acceptance in the= industry, the following deployment scenarios look as realistic to me: > a. Coexistence between LDP-based and SR-based control planes in th= e same network > b. Partial deployment of SR in some sub-domains of a network combine= d with the operators=92 need to use the benefits of SR where it is already = deployed > c. Gradual transition of services (especially L2 and L3VPN) tunnel= led over LDP-created LSPs to LSPs set up using SR (and, possibly, vice vers= a) > =20 > Is the draft a good enough start for a WG document? From my POV, yes. > 1 The draft covers multiple (if not all) realistic use cases for = coexistence of LDP-based and SR-based control planes and provides what loo= ks to me as reasonable solutions for these scenarios. > 2 At the same I would think that additional work is required to c= omplete the work. > =20 > Specific issues with the current draft: > 1 Editorial: SR-related abbreviations (e.g., SRGB, SID etc.) are = used without expansion at the first use, and there is no =93Abbreviation=94= section in the draft. > 2 Process/Editorial: The draft currently lists 12 authors on its = title page exceeding the recommended RFC Editor maximum of 5 authors. > 3. Technical: The draft does not analyse the use case = of coexistence between SR and LDP with enabled extension for multi-area LSP= s as per RFC 5283. I think that this use case deserves special consideratio= n in the draft because: > a. It mentions the use case of seamless MPLS and refers to the (exp= ired) Seamless MPLS Architecture draft > b. The seamless MPLS Architecture draft, in its turn, explicitly re= fers to RFC 5283 in Section 5.1.1 to facilitate binding of labels received = via the DoD LDP session while only default route is configured in the RIB o= f the access node in the seamless MPLS architecture > c. It is possible that this use case would not add anything to the = draft =96 but I would prefer to see it in the document with the appropriate= explanation > 4. Technical: Section 8 =93Manageability Considerations= =94 is currently left empty. When this section is written, I would expect a= t least the following: > a. Some level of detail regarding local policies defining whether = LDP-created or SR-created LSPs should be used etc. > b. Discussion of using LSP Ping for LSPs that are produced by stitch= ing an LDP segment with an SR one. > c. Alternatively, it is possible to move this section to a separate= dedicated draft > 5. Technical: I think more information should be provid= ed in Section 5 to explain operational aspects of SR-assisted LDP FR: > a. In Section 5.1 I would expect the draft to explain that: > i. No= de D is selected as the RLFA using the same logic that is defined for sele= cting RLFA in RFC 7490 > ii. The= =93bypass LSP=94 is set up by the SR CP automatically without any need for= management intervention > iii. I w= ould like to understand why dynamically set up Targeted LDP sessions are an= operational concern. Such sessions appear also when BGP-based auto-discove= ry for L2VPN is used, and, according to the analysis in RFC 7490, the scala= bility problems associated with these sessions look as negligible. > b. In Section 5.2 I would expect the draft to explain that: > i. Th= e resulting solution is similar to using a bypass LSP to a manually selecte= d RLFA that is set up by RSVP-TE (the difference is that a Targeted LDP ses= sion to such an RLFA would be still needed) > ii. Set= up of the =93traffic-engineered bypass LSP=94 by the SR CP is triggered b= y an appropriate management operation > iii. Wha= t information should be provided by the Management Plane for computing the = RLFA and the traffic-engineered bypass LSP? Should it be similar to config= uration parameters used with RSVP-TE? > iv. Which= kind of logic should be responsible for computing the RLFA and the path to= be taken by the engineered bypass LSP: should it be similar to the CSPF us= ed with RSVP-TE? > v. How = the traffic-engineered bypass LSP hat is set up by the SR CP would react to= additional changes in the network topology (the behaviour of the bypass LS= P that is set by RSVP-TE in these situations is well known) > c. In both cases it is not clear how the backup label and NHOP are = installed: > i. In= the FRR with RLFA as per RFC 7490 this is usually done by LDP that receiv= es the backup label as bound to the destination prefix FEC via the Targeted= LDP session, retains it and decides to us it when a route to the destinati= on prefix using the LSP leading to the RLFA as its NHOP is installed in th= e RIB as the best route to the destination prefix by IP FRR > ii. Thi= s scheme definitely would not work if the Targeted LDP session to the selec= ted RLFA is eliminated > iii. Fro= m my POV more details are required here, and the critical question here is,= of course, when the scheme proposed in the draft requires any changes in L= DP. > =20 > =20 > Neither of the issues listed above should be considered as preventing ado= ption of the draft as a WG document IMO. Actually I think that resolving th= ese issues in the context of a WG document would be more effective. > =20 > Hopefully these notes will be useful. > =20 > Regards, > Sasha > =20 > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > =20 > From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com]=20 > Sent: Wednesday, May 20, 2015 12:46 PM > To: Alexander Vainshtein > Cc: bruno.decraene@orange.com; jgs@juniper.net; Alvaro Retana (aretana); = Jon Hudson > Subject: Routing directorate QA review of draft-filsfils-spring-segment-r= outing-ldp-interop > =20 > Hi Sasha > =20 > Please would you be the routing directorate QA reviewer for draft-filsfil= s-spring-segment-routing-ldp-interop? > https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing-ld= p-interop/ > =20 > This initial review has been prompted by the spring WG chairs in parallel= with a call for WG adoption. As such, this document qualifies for =93init= ial QA review=94. Please could you provide your initial comments in the ne= xt 3 weeks? As per the QA process, we would also like you to stay with the= document and review it again when it goes to WG last call. > =20 > The following web page contains a briefing on the QA process, and guidanc= e for the QA reviewer. > https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa > =20 > Please copy your comments to the spring and rtgdir mailing lists. > =20 > Please let me know whether you can do it, or not. > =20 > Many thanks > Jon > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Wed Jul 29 06:18:01 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA0901AC3B6; Wed, 29 Jul 2015 06:17:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FSL_MY_NAME_IS=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KfzBa2Y4yuCy; Wed, 29 Jul 2015 06:17:55 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0706.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::706]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E760D1A9236; Wed, 29 Jul 2015 06:17:54 -0700 (PDT) Received: from DB3PR03MB0780.eurprd03.prod.outlook.com (10.161.55.12) by DB3PR03MB0779.eurprd03.prod.outlook.com (10.161.55.11) with Microsoft SMTP Server (TLS) id 15.1.225.19; Wed, 29 Jul 2015 13:17:35 +0000 Received: from DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) by DB3PR03MB0780.eurprd03.prod.outlook.com ([10.161.55.12]) with mapi id 15.01.0225.018; Wed, 29 Jul 2015 13:17:35 +0000 From: Alexander Vainshtein To: "Stefano Previdi (sprevidi)" Thread-Topic: [spring] Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop Thread-Index: AdDJU4roffYaBLXOTjabFYQ9m7cUoAApb99QAAHAcAAAACIm0A== Date: Wed, 29 Jul 2015 13:17:35 +0000 Message-ID: References: <5B43AC77-1C49-407F-90ED-8A35D5D76D88@cisco.com> In-Reply-To: <5B43AC77-1C49-407F-90ED-8A35D5D76D88@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-originating-ip: [109.66.1.206] x-microsoft-exchange-diagnostics: 1; DB3PR03MB0779; 5:WYrWBIyB7ijOI7VzC8xlwLEKjfCe9VsCngakw8NZ8a13xCdlQdwswszANs4YAhf9bfnl/fPO6AhiS6G2EwbIH0duhYJMU4bhCj1UVAn5Nkh8U3R4w/E+F2917RVo6bQG4azhcy65NmSEMJCY917VOA==; 24:gaWE/tcK3P09UO8VQP0O8u7HzlQgjniOabBvcA5tNnWL9MZ9UdxyLnK+M4mcP3RWpTpIkfG4mYhwsmlsrt9dz/U0SCZpIsjidiwg92tvKU4=; 20:56uUtRGtc/E3Yf6oaIjM8eh+gB8sm39fCbQ3iq7oQbRw7TpX4PAKnKEXiugo8IZtwBdjMoa68RY2SInYoKuhug== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB3PR03MB0779; db3pr03mb0779: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:DB3PR03MB0779; BCL:0; PCL:0; RULEID:; SRVR:DB3PR03MB0779; x-forefront-prvs: 0652EA5565 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(24454002)(37854004)(252514010)(66654002)(46102003)(76576001)(66066001)(19580405001)(86362001)(33656002)(54356999)(102836002)(50986999)(2656002)(19580395003)(230783001)(87936001)(555904002)(74316001)(5003600100002)(77156002)(122556002)(62966003)(92566002)(15975445007)(5002640100001)(77096005)(5001920100001)(189998001)(110136002)(2950100001)(5001960100002)(40100003)(76176999)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR03MB0779; H:DB3PR03MB0780.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jul 2015 13:17:35.6391 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR03MB0779 Archived-At: Cc: Jonathan Hardwick , "rtg-dir@ietf.org" , "spring@ietf.org" , "mpls@ietf.org" , "rtg-ads@tools.ietf.org" Subject: Re: [spring] Routing directorate QA review of draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jul 2015 13:17:58 -0000 Hi Stefano, OK by me. Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 Sent: Wednesday, July 29, 2015 4:13 PM To: Alexander Vainshtein Cc: rtg-ads@tools.ietf.org; Jonathan Hardwick; rtg-dir@ietf.org; spring@iet= f.org; mpls@ietf.org Subject: Re: [spring] Routing directorate QA review of draft-filsfils-sprin= g-segment-routing-ldp-interop Hi Sasha, Many thanks for your review and comments. I'll go through them asap. Thanks. s. On Jul 29, 2015, at 2:52 PM, Alexander Vainshtein wrote: > Hi, > My previous message has been put on hold by the moderator of the SPRING W= G as having too many recipients. > This is partially due to the draft having 12 authors - and have tried to= send the review to each of themJ. > =20 > I am now re-sending it with a shorter (but, hopefully, sufficient - I bel= ieve all the authors are on the SPRING mailing list anyway) list of recipie= nts andwith one more issue I have found in the draft - highlighted. > =20 > Regards, > Sasha > =20 > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > =20 > From: Alexander Vainshtein=20 > Sent: Tuesday, July 28, 2015 7:37 PM > To: 'rtg-ads@tools.ietf.org' > Cc: bruno.decraene@orange.com; jgs@juniper.net; Jon Hudson; 'Jonathan Har= dwick'; 'rtg-dir@ietf.org'; 'spring@ietf.org'; mpls@ietf.org; 'cfilsfil@cis= co.com'; 'sprevidi@cisco.com'; 'bashandy@cisco.com'; 'stephane.litkowski@or= ange.com'; 'Martin.Horneffer@telekom.de'; 'igormilojevic@telekom.rs'; 'rob.= shakir@bt.com'; 'saku@ytti.fi'; 'wim.henderickx@alcatel-lucent.com'; 'Jeff = Tantsura (jeff.tantsura@ericsson.com)'; 'edward.crabbe@gmail.com' > Subject: RE: Routing directorate QA review of draft-filsfils-spring-segme= nt-routing-ldp-interop > =20 > Hi, > My name is Sasha Vainshtein, and I have been asked to perform the QA rev= iew of https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routi= ng-ldp-interop/. > =20 > Due to health problems I have been very late (but, hopefully, not too lat= e) with this review, and here it is. > =20 > Does the draft solves a real problem? From my POV, definitely yes. > 1. The problem stems from the following combination of = facts fact that: > a. LDP distributes labels for FECs represented by IP prefixes (amon= g other things). > b. LDP-based MPLS network are very widely deployed > c. SR operating over the MPLS DP allocates labels for SIDs that can= represent IP prefixes (again, among other things) > d. As a consequence, LDP and SR may effectively map the same IP pref= ix to different labels. > 2. As SR using the MPLS DP is gaining acceptance in the= industry, the following deployment scenarios look as realistic to me: > a. Coexistence between LDP-based and SR-based control planes in th= e same network > b. Partial deployment of SR in some sub-domains of a network combine= d with the operators' need to use the benefits of SR where it is already de= ployed > c. Gradual transition of services (especially L2 and L3VPN) tunnel= led over LDP-created LSPs to LSPs set up using SR (and, possibly, vice vers= a) > =20 > Is the draft a good enough start for a WG document? From my POV, yes. > 1 The draft covers multiple (if not all) realistic use cases for = coexistence of LDP-based and SR-based control planes and provides what loo= ks to me as reasonable solutions for these scenarios. > 2 At the same I would think that additional work is required to c= omplete the work. > =20 > Specific issues with the current draft: > 1 Editorial: SR-related abbreviations (e.g., SRGB, SID etc.) are = used without expansion at the first use, and there is no "Abbreviation" sec= tion in the draft. > 2 Process/Editorial: The draft currently lists 12 authors on its = title page exceeding the recommended RFC Editor maximum of 5 authors. > 3. Technical: The draft does not analyse the use case = of coexistence between SR and LDP with enabled extension for multi-area LSP= s as per RFC 5283. I think that this use case deserves special consideratio= n in the draft because: > a. It mentions the use case of seamless MPLS and refers to the (exp= ired) Seamless MPLS Architecture draft > b. The seamless MPLS Architecture draft, in its turn, explicitly re= fers to RFC 5283 in Section 5.1.1 to facilitate binding of labels received = via the DoD LDP session while only default route is configured in the RIB o= f the access node in the seamless MPLS architecture > c. It is possible that this use case would not add anything to the = draft - but I would prefer to see it in the document with the appropriate e= xplanation > 4. Technical: Section 8 "Manageability Considerations" = is currently left empty. When this section is written, I would expect at le= ast the following: > a. Some level of detail regarding local policies defining whether = LDP-created or SR-created LSPs should be used etc. > b. Discussion of using LSP Ping for LSPs that are produced by stitch= ing an LDP segment with an SR one. > c. Alternatively, it is possible to move this section to a separate= dedicated draft > 5. Technical: I think more information should be provid= ed in Section 5 to explain operational aspects of SR-assisted LDP FR: > a. In Section 5.1 I would expect the draft to explain that: > i. No= de D is selected as the RLFA using the same logic that is defined for sele= cting RLFA in RFC 7490 > ii. The= "bypass LSP" is set up by the SR CP automatically without any need for man= agement intervention > iii. I w= ould like to understand why dynamically set up Targeted LDP sessions are an= operational concern. Such sessions appear also when BGP-based auto-discove= ry for L2VPN is used, and, according to the analysis in RFC 7490, the scala= bility problems associated with these sessions look as negligible. > b. In Section 5.2 I would expect the draft to explain that: > i. Th= e resulting solution is similar to using a bypass LSP to a manually selecte= d RLFA that is set up by RSVP-TE (the difference is that a Targeted LDP ses= sion to such an RLFA would be still needed) > ii. Set= up of the "traffic-engineered bypass LSP" by the SR CP is triggered by an= appropriate management operation > iii. Wha= t information should be provided by the Management Plane for computing the = RLFA and the traffic-engineered bypass LSP? Should it be similar to config= uration parameters used with RSVP-TE? > iv. Which= kind of logic should be responsible for computing the RLFA and the path to= be taken by the engineered bypass LSP: should it be similar to the CSPF us= ed with RSVP-TE? > v. How = the traffic-engineered bypass LSP hat is set up by the SR CP would react to= additional changes in the network topology (the behaviour of the bypass LS= P that is set by RSVP-TE in these situations is well known) > c. In both cases it is not clear how the backup label and NHOP are = installed: > i. In= the FRR with RLFA as per RFC 7490 this is usually done by LDP that receiv= es the backup label as bound to the destination prefix FEC via the Targeted= LDP session, retains it and decides to us it when a route to the destinati= on prefix using the LSP leading to the RLFA as its NHOP is installed in th= e RIB as the best route to the destination prefix by IP FRR > ii. Thi= s scheme definitely would not work if the Targeted LDP session to the selec= ted RLFA is eliminated > iii. Fro= m my POV more details are required here, and the critical question here is,= of course, when the scheme proposed in the draft requires any changes in L= DP. > =20 > =20 > Neither of the issues listed above should be considered as preventing ado= ption of the draft as a WG document IMO. Actually I think that resolving th= ese issues in the context of a WG document would be more effective. > =20 > Hopefully these notes will be useful. > =20 > Regards, > Sasha > =20 > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > =20 > From: Jonathan Hardwick [mailto:Jonathan.Hardwick@metaswitch.com]=20 > Sent: Wednesday, May 20, 2015 12:46 PM > To: Alexander Vainshtein > Cc: bruno.decraene@orange.com; jgs@juniper.net; Alvaro Retana (aretana); = Jon Hudson > Subject: Routing directorate QA review of draft-filsfils-spring-segment-r= outing-ldp-interop > =20 > Hi Sasha > =20 > Please would you be the routing directorate QA reviewer for draft-filsfil= s-spring-segment-routing-ldp-interop? > https://datatracker.ietf.org/doc/draft-filsfils-spring-segment-routing-ld= p-interop/ > =20 > This initial review has been prompted by the spring WG chairs in parallel= with a call for WG adoption. As such, this document qualifies for "initia= l QA review". Please could you provide your initial comments in the next 3= weeks? As per the QA process, we would also like you to stay with the doc= ument and review it again when it goes to WG last call. > =20 > The following web page contains a briefing on the QA process, and guidanc= e for the QA reviewer. > https://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDirDocQa > =20 > Please copy your comments to the spring and rtgdir mailing lists. > =20 > Please let me know whether you can do it, or not. > =20 > Many thanks > Jon > =20 > =20 > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring From nobody Wed Jul 29 14:01:39 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93B0A1ACE3C for ; Wed, 29 Jul 2015 14:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1zdkzMVhLwu for ; Wed, 29 Jul 2015 14:01:32 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6709A1AC3A1 for ; Wed, 29 Jul 2015 14:01:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12843; q=dns/txt; s=iport; t=1438203693; x=1439413293; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=FvDyiNT6L2+Mv7cp3ZAMQQnRj/ZX3zCaPuI0GfAmQso=; b=O0cbP1rNdm9Vfi3j+fr59xCzBKJ9mU0l5KSublc9CptigdxaaB9scLJm j3nmmU0CfrxYT6NPfGiXDNTbbZRLqoi71rgTmajxP2B61SXpWXmthv831 jkmU4y+tu6IhBLy2c9vuMC4zKxwKYWZRpYqZiWQg4tWksn8PM8GBCNj5R A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BvAwCaPrlV/4sNJK1cgk1NVGkGvAQJh3wCgVs4FAEBAQEBAQGBCoQjAQEBBC1cAgEIEQQBAQsdBzIUCQgCBAESCIgmzyABAQEBAQEBAQEBAQEBAQEBAQEBAQEXi06EJBEBIDcBBoMSgRQFkW+DAQGOCIQgk0smZIMZb4EOOoEEAQEB X-IronPort-AV: E=Sophos; i="5.15,572,1432598400"; d="scan'208,217"; a="19837723" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-3.cisco.com with ESMTP; 29 Jul 2015 21:01:32 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id t6TL1UDJ019054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jul 2015 21:01:30 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.220]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.03.0195.001; Wed, 29 Jul 2015 16:01:30 -0500 From: "Les Ginsberg (ginsberg)" To: "stephane.litkowski@orange.com" , "Uma Chunduri" , "Aissaoui, Mustapha (Mustapha)" , "spring@ietf.org" , "Shraddha Hegde (shraddha@juniper.net)" , "Pushpasis Sarkar (psarkar@juniper.net)" , "Hannes Gredler (hannes@juniper.net)" Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQxW7YNN4DxkRP0Eq723Br5e6m953pqrsAgAAH0AD//9bWAIABgjyAgAesgYCAAEAEsA== Date: Wed, 29 Jul 2015 21:01:29 +0000 Message-ID: References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.136.106] Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F594A5ED7xmbalnx02ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jul 2015 21:01:38 -0000 --_000_F3ADE4747C9E124B89F0ED2180CC814F594A5ED7xmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stephane - What is the requirement to have a per-protocol SRGB config? This makes no sense to me operationally or architecturally. (I am not talking about what may or may not have been implemented by vendor= s - the YANG model should be architecturally correct) Les From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com] Sent: Wednesday, July 29, 2015 5:11 AM To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); s= pring@ietf.org; Shraddha Hegde (shraddha@juniper.net); Pushpasis Sarkar (ps= arkar@juniper.net); Hannes Gredler (hannes@juniper.net) Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi all, What if we keep the SRGB block config in "segment-routing" global module, a= nd if we allow for YANG configuration of carving this block inside each pro= tocol (maybe as a feature) ? Stephane From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] Sent: Friday, July 24, 2015 16:59 To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI Steph= ane SCE/IBNF; spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang >Suggesting that the forwarding instruction (AKA label) needs to be differ= ent depending on what protocol provided >the instruction is completely unnecessary - it simply wastes label space. [Uma]: Les, No - I never suggested anything like that. SRGB for a routing instance to be advertised should be part of the routing = instance provisioning as far as the yang model is concerned. Carving out the label space for SR is a local matter and agree, of course, = this can be done in so many ways through CLI, dynamically, statically etc.= .. -- Uma C. ___________________________________________________________________________= ______________________________________________ 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_F3ADE4747C9E124B89F0ED2180CC814F594A5ED7xmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stephane –<= /o:p>

 

What is the requiremen= t to have a per-protocol SRGB config?

This makes no sense to= me operationally or architecturally.

 

(I am not talking abou= t what may or may not have been implemented by vendors – the YANG mod= el should be architecturally correct)

 

   Les<= /o:p>

 

 

From: stephane= .litkowski@orange.com [mailto:stephane.litkowski@orange.com]
Sent: Wednesday, July 29, 2015 5:11 AM
To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Musta= pha); spring@ietf.org; Shraddha Hegde (shraddha@juniper.net); Pushpasis Sar= kar (psarkar@juniper.net); Hannes Gredler (hannes@juniper.net)
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

 

Hi all,

 

What if we keep the SR= GB block config in “segment-routing” global module, and if we a= llow for YANG configuration of carving this block inside each protocol (may= be as a feature) ?

 

Stephane

 

 

From: Uma Chun= duri [mailto:uma.chunduri@eric= sson.com]
Sent: Friday, July 24, 2015 16:59
To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSK= I Stephane SCE/IBNF; spring@ietf.org
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

 

>Suggesting that the forwarding instruction (AKA label)  needs= to be different depending on what protocol provided

>the instruction is completely unnecessary – it simply wastes= label space.

 

[Uma]: Les, No - I nev= er suggested anything like that.

SRGB for a routing ins= tance to be advertised should be part of the routing instance provisioning = as far as the yang model is concerned.

Carving out the label = space for SR is a local matter and agree, of course, this  can be done= in so many ways through CLI, dynamically, statically etc...

 

--

Uma C.

 

______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
--_000_F3ADE4747C9E124B89F0ED2180CC814F594A5ED7xmbalnx02ciscoc_-- From nobody Wed Jul 29 14:23:02 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999461B2CA3 for ; Wed, 29 Jul 2015 14:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9KBnmK4nZKU for ; Wed, 29 Jul 2015 14:22:57 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B4881B2C9E for ; Wed, 29 Jul 2015 14:22:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15504; q=dns/txt; s=iport; t=1438204977; x=1439414577; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=YaSWVZ24eSl3W7HD+WWVApo+bZE+7qJ9NY7kc8XJdQQ=; b=Dh412HAcUwgoEPETh9Z/uMl14Q+VUH2IA1bSCYQEac/z7R0dBV/EPPIs MWo8Zu49uUJGh2EqEnr+y+P6kcntRAWI69A0Z0j2F9q4CK9dLlO4tPQw7 mZrhhHFOUkIovHnnnKl+xFK93vIANOTQL9ncJu9fiWl7K2pC74JRYR0K5 A=; X-IronPort-AV: E=Sophos;i="5.15,572,1432598400"; d="scan'208,217";a="173764796" Received: from alln-core-2.cisco.com ([173.36.13.135]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Jul 2015 21:22:57 +0000 Received: from [128.107.165.110] (dhcp-128-107-165-110.cisco.com [128.107.165.110]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t6TLMuVA014337; Wed, 29 Jul 2015 21:22:56 GMT Message-ID: <55B94430.8030001@cisco.com> Date: Wed, 29 Jul 2015 14:22:56 -0700 From: "Ahmed Bashandy (bashandy)" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: spring@ietf.org References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010402060706080707080201" Archived-At: Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jul 2015 21:23:00 -0000 This is a multi-part message in MIME format. --------------010402060706080707080201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit One of the objective of the YANG Model is to manage devices. Hence the flexibility of having a separate SRGB per protocol is necessary, at least for operational reasons Ahmed On 7/29/2015 2:01 PM, Les Ginsberg (ginsberg) wrote: > > Stephane -- > > What is the requirement to have a per-protocol SRGB config? > > This makes no sense to me operationally or architecturally. > > (I am not talking about what may or may not have been implemented by > vendors -- the YANG model should be architecturally correct) > > Les > > *From:*stephane.litkowski@orange.com > [mailto:stephane.litkowski@orange.com] > *Sent:* Wednesday, July 29, 2015 5:11 AM > *To:* Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha > (Mustapha); spring@ietf.org; Shraddha Hegde (shraddha@juniper.net); > Pushpasis Sarkar (psarkar@juniper.net); Hannes Gredler > (hannes@juniper.net) > *Subject:* RE: [spring] Modeling SRGB configuration for > draft-ietf-spring-sr-yang > > Hi all, > > What if we keep the SRGB block config in "segment-routing" global > module, and if we allow for YANG configuration of carving this block > inside each protocol (maybe as a feature) ? > > Stephane > > *From:*Uma Chunduri [mailto:uma.chunduri@ericsson.com] > *Sent:* Friday, July 24, 2015 16:59 > *To:* Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); > LITKOWSKI Stephane SCE/IBNF; spring@ietf.org > *Subject:* RE: [spring] Modeling SRGB configuration for > draft-ietf-spring-sr-yang > > >Suggesting that the forwarding instruction (AKA label) needs to be different depending on what > protocol provided > > >the instruction is completely unnecessary -- it simply wastes label space. > > [Uma]: Les, No - I never suggested anything like that. > > SRGB for a routing instance to be advertised should be part of the > routing instance provisioning as far as the yang model is concerned. > > Carving out the label space for SR is a local matter and agree, of > course, this can be done in so many ways through CLI, dynamically, > statically etc... > > -- > > Uma C. > > _________________________________________________________________________________________________________________________ > > 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 --------------010402060706080707080201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit One of the objective of the YANG Model is to manage devices. Hence the flexibility of having a separate SRGB per protocol is necessary, at least for operational reasons


Ahmed

On 7/29/2015 2:01 PM, Les Ginsberg (ginsberg) wrote:

Stephane –

 

What is the requirement to have a per-protocol SRGB config?

This makes no sense to me operationally or architecturally.

 

(I am not talking about what may or may not have been implemented by vendors – the YANG model should be architecturally correct)

 

   Les

 

 

From: stephane.litkowski@orange.com [mailto:stephane.litkowski@orange.com]
Sent: Wednesday, July 29, 2015 5:11 AM
To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); spring@ietf.org; Shraddha Hegde (shraddha@juniper.net); Pushpasis Sarkar (psarkar@juniper.net); Hannes Gredler (hannes@juniper.net)
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

 

Hi all,

 

What if we keep the SRGB block config in “segment-routing” global module, and if we allow for YANG configuration of carving this block inside each protocol (maybe as a feature) ?

 

Stephane

 

 

From: Uma Chunduri [mailto:uma.chunduri@ericsson.com]
Sent: Friday, July 24, 2015 16:59
To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI Stephane SCE/IBNF; spring@ietf.org
Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang

 

>Suggesting that the forwarding instruction (AKA label)  needs to be different depending on what protocol provided

>the instruction is completely unnecessary – it simply wastes label space.

 

[Uma]: Les, No - I never suggested anything like that.

SRGB for a routing instance to be advertised should be part of the routing instance provisioning as far as the yang model is concerned.

Carving out the label space for SR is a local matter and agree, of course, this  can be done in so many ways through CLI, dynamically, statically etc...

 

--

Uma C.

 

_________________________________________________________________________________________________________________________
 
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

--------------010402060706080707080201-- From nobody Wed Jul 29 14:45:09 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC3F1B2CC7 for ; Wed, 29 Jul 2015 14:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 7_z9ytJfrUUL for ; Wed, 29 Jul 2015 14:45:06 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (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 E831F1B2CB1 for ; Wed, 29 Jul 2015 14:45:05 -0700 (PDT) Received: by wicmv11 with SMTP id mv11so235307861wic.0 for ; Wed, 29 Jul 2015 14:45:04 -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:content-type; bh=FaA5ZpmWpfQejJAcxEVc5SrE5cKQCOya/GwwINv9xhw=; b=XHXNE7hVX7S16XasCWn2ClxCyC6v0u8TjNzzDGoYva4SLtXNTor6110VTWawM+pOTi 4cp06HXroxweWA9Us4H6diHXbzovYWGmUCKKNwYB5Y3nrYLECCUkgRSv0b2FURT3VWur Zw8ZGRjktPF1rHNvWmm13tVQ4CBP+qVOHUeWlJh7o36UvJWt/v38BK13V+JmaoIOw/G1 3he3T65dnKmELWhOuORbEDT1R4KdcB+HwvcVFTFZ6HcoICVUC2Iige/FMEyg1iMeLbGi U57jyZKM3LX7bqcshkW8eZDHpNzqaWlNIFJW/5M0xGw3IBSP6ZUkk1Hb0zGA6L7ikFwe ClRA== MIME-Version: 1.0 X-Received: by 10.194.187.170 with SMTP id ft10mr80408091wjc.26.1438206304480; Wed, 29 Jul 2015 14:45:04 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.194.95.168 with HTTP; Wed, 29 Jul 2015 14:45:04 -0700 (PDT) In-Reply-To: References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Date: Wed, 29 Jul 2015 23:45:04 +0200 X-Google-Sender-Auth: -9PlccmtB2Y3OFRrPyuJ3HdceB0 Message-ID: From: Robert Raszuk To: "Les Ginsberg (ginsberg)" Content-Type: multipart/alternative; boundary=047d7bb03a92e47606051c0a7f5e Archived-At: Cc: "stephane.litkowski@orange.com" , "spring@ietf.org" , "Shraddha Hegde \(shraddha@juniper.net\)" , Uma Chunduri , "Pushpasis Sarkar \(psarkar@juniper.net\)" , "Aissaoui, Mustapha \(Mustapha\)" , "Hannes Gredler \(hannes@juniper.net\)" Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jul 2015 21:45:07 -0000 --047d7bb03a92e47606051c0a7f5e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Les, > =E2=80=8B This makes no sense to me operationally or architecturally. Fundamentally I fully agree with you. However architecturally: However at least looking at group of folks who claim that it is impossible to get same SRGB block in *any* network between two or more vendors I think Stephane's intention would be to at least get it per one protocol even if platform wide the intersecting pool may be mission impossible. and now operationally: Another reason would be idea of dual overlapping SRGBs perhaps quite useful during migrations between protocols where the exact same SRGB is set on both then just based on admin distance one vs the other protocol is chosen. While a standard practice in protocol migrations not sure if anyone looked at that from SR perspective. Cheers, R. On Wed, Jul 29, 2015 at 11:01 PM, Les Ginsberg (ginsberg) < ginsberg@cisco.com> wrote: > Stephane =E2=80=93 > > > > What is the requirement to have a per-protocol SRGB config? > > =E2=80=8B=E2=80=8B > This makes no sense to me operationally or architecturally. > > > > (I am not talking about what may or may not have been implemented by > vendors =E2=80=93 the YANG model should be architecturally correct) > > > > Les > > > --047d7bb03a92e47606051c0a7f5e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Les,

> =E2=80=8B
This makes no sense to me operationally or= architecturally.

Fundamentally I fully agree with you.

=

However architectural= ly:=C2=A0

However at l= east looking at group of folks who claim that it is impossible to get same = SRGB block in *any* network between two or more vendors =C2=A0I think Steph= ane's intention would be to at least get it per one protocol even if pl= atform wide the intersecting pool may be mission impossible.=C2=A0


a= nd now operationally:=C2=A0

Another reason would be idea of dual overlapping SRGBs perhaps quite = useful during migrations between protocols where the exact same SRGB is set= on both then just based on admin distance one vs the other protocol is cho= sen. While a standard practice in protocol migrations not sure if anyone lo= oked at that from SR perspective.

Cheers,
R.

On Wed, J= ul 29, 2015 at 11:01 PM, Les Ginsberg (ginsberg) <ginsberg@cisco.com&= gt; wrote:

Stephane =E2=80=93<= /u>

=C2=A0

What is the requiremen= t to have a per-protocol SRGB config?

=E2=80=8B=E2=80=8B
This makes no sense to me o= perationally or architecturally.

=C2=A0

(I am not talking abou= t what may or may not have been implemented by vendors =E2=80=93 the YANG m= odel should be architecturally correct)

=C2=A0

=C2=A0 =C2=A0Les

=C2=A0

--047d7bb03a92e47606051c0a7f5e-- From nobody Wed Jul 29 15:29:01 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12A01B2F03 for ; Wed, 29 Jul 2015 15:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXKCbjfk6egQ for ; Wed, 29 Jul 2015 15:28:58 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACCC31B2EF2 for ; Wed, 29 Jul 2015 15:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17124; q=dns/txt; s=iport; t=1438208937; x=1439418537; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=65uDZzSwGmmkDmYnServJA+0f1X11c+Z9wAsbhsCPtU=; b=i5ih5mb8m1LS7HWS+OaOsPcUveiVi3qlLFoiOTUfFpXempjS4BLFKlk1 xnMB3nTTuXvNiXLZ4bnXdIRLw0uGF1wQEW2ZPZBi1fAMDgMf3OI64Re82 w2+G0G6I4JNBCnS/AGO48Qvwemh6ZqkA6Ir2RqhE6RSRPwHXWRBsG6RrI s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AaBgBwU7lV/4QNJK1bgk1NVGkGgx24cYd8AhyBPDoSAQEBAQEBAYEKhCMBAQEEIwpMEAIBBgIRBAEBCx0DAgICHxEUCQgCBA4FCBaHewMSnFWdGZBBDYUvAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tOgk6CCDEGAYJpL4EUBZRwAYpZgy+QPYNLg2MmZIMZb4FIgQQBAQE X-IronPort-AV: E=Sophos; i="5.15,573,1432598400"; d="scan'208,217"; a="14232477" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-7.cisco.com with ESMTP; 29 Jul 2015 22:28:56 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t6TMSuIN028918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 Jul 2015 22:28:56 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.220]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Wed, 29 Jul 2015 17:28:56 -0500 From: "Les Ginsberg (ginsberg)" To: Robert Raszuk Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQykfV3ULv7HC1/k68iNCsCENxip3zBalg Date: Wed, 29 Jul 2015 22:28:56 +0000 Message-ID: References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.136.106] Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F594A5FF5xmbalnx02ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "stephane.litkowski@orange.com" , "spring@ietf.org" , "Shraddha Hegde \(shraddha@juniper.net\)" , Uma Chunduri , "Pushpasis Sarkar \(psarkar@juniper.net\)" , "Aissaoui, Mustapha \(Mustapha\)" , "Hannes Gredler \(hannes@juniper.net\)" Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 29 Jul 2015 22:29:00 -0000 --_000_F3ADE4747C9E124B89F0ED2180CC814F594A5FF5xmbalnx02ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9iZXJ0IC0NCg0KRnJvbTogcnJhc3p1a0BnbWFpbC5jb20gW21haWx0bzpycmFzenVrQGdtYWls LmNvbV0gT24gQmVoYWxmIE9mIFJvYmVydCBSYXN6dWsNClNlbnQ6IFdlZG5lc2RheSwgSnVseSAy OSwgMjAxNSAyOjQ1IFBNDQpUbzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykNCkNjOiBzdGVwaGFu ZS5saXRrb3dza2lAb3JhbmdlLmNvbTsgVW1hIENodW5kdXJpOyBBaXNzYW91aSwgTXVzdGFwaGEg KE11c3RhcGhhKTsgc3ByaW5nQGlldGYub3JnOyBTaHJhZGRoYSBIZWdkZSAoc2hyYWRkaGFAanVu aXBlci5uZXQpOyBQdXNocGFzaXMgU2Fya2FyIChwc2Fya2FyQGp1bmlwZXIubmV0KTsgSGFubmVz IEdyZWRsZXIgKGhhbm5lc0BqdW5pcGVyLm5ldCkNClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBNb2Rl bGluZyBTUkdCIGNvbmZpZ3VyYXRpb24gZm9yIGRyYWZ0LWlldGYtc3ByaW5nLXNyLXlhbmcNCg0K SGkgTGVzLA0KDQo+IOKAiw0KVGhpcyBtYWtlcyBubyBzZW5zZSB0byBtZSBvcGVyYXRpb25hbGx5 IG9yIGFyY2hpdGVjdHVyYWxseS4NCg0KRnVuZGFtZW50YWxseSBJIGZ1bGx5IGFncmVlIHdpdGgg eW91Lg0KDQoNCkhvd2V2ZXIgYXJjaGl0ZWN0dXJhbGx5Og0KDQpIb3dldmVyIGF0IGxlYXN0IGxv b2tpbmcgYXQgZ3JvdXAgb2YgZm9sa3Mgd2hvIGNsYWltIHRoYXQgaXQgaXMgaW1wb3NzaWJsZSB0 byBnZXQgc2FtZSBTUkdCIGJsb2NrIGluICphbnkqIG5ldHdvcmsgYmV0d2VlbiB0d28gb3IgbW9y ZSB2ZW5kb3JzICBJIHRoaW5rIFN0ZXBoYW5lJ3MgaW50ZW50aW9uIHdvdWxkIGJlIHRvIGF0IGxl YXN0IGdldCBpdCBwZXIgb25lIHByb3RvY29sIGV2ZW4gaWYgcGxhdGZvcm0gd2lkZSB0aGUgaW50 ZXJzZWN0aW5nIHBvb2wgbWF5IGJlIG1pc3Npb24gaW1wb3NzaWJsZS4NCg0KW0xlczpdIFRoaXMg aXMgYW4gdW5yZWxhdGVkIGlzc3VlLiBQbGFjaW5nIFNSR0IgaW4gZ2xvYmFsIGNvbnRleHQgZG9l cyBub3QgbWVhbiBhbGwgcm91dGVycyBoYXZlIHRvIGhhdmUgdGhlIHNhbWUgU1JHQi4gVGhlcmUg aXMgbm8gY29udHJvdmVyc3kgaGVyZS4NCg0KDQphbmQgbm93IG9wZXJhdGlvbmFsbHk6DQoNCkFu b3RoZXIgcmVhc29uIHdvdWxkIGJlIGlkZWEgb2YgZHVhbCBvdmVybGFwcGluZyBTUkdCcyBwZXJo YXBzIHF1aXRlIHVzZWZ1bCBkdXJpbmcgbWlncmF0aW9ucyBiZXR3ZWVuIHByb3RvY29scyB3aGVy ZSB0aGUgZXhhY3Qgc2FtZSBTUkdCIGlzIHNldCBvbiBib3RoIHRoZW4ganVzdCBiYXNlZCBvbiBh ZG1pbiBkaXN0YW5jZSBvbmUgdnMgdGhlIG90aGVyIHByb3RvY29sIGlzIGNob3Nlbi4gV2hpbGUg YSBzdGFuZGFyZCBwcmFjdGljZSBpbiBwcm90b2NvbCBtaWdyYXRpb25zIG5vdCBzdXJlIGlmIGFu eW9uZSBsb29rZWQgYXQgdGhhdCBmcm9tIFNSIHBlcnNwZWN0aXZlLg0KW0xlczpdIE5vdCBzdXJl IHdoYXQgeW91IGFyZSB0cnlpbmcgdG8gc2F5LiBJZiB0aGUgdHdvIFNSR0JzIGFyZSB0aGUgc2Ft ZSDigJMgd2h5IGRvIHdlIG5lZWQgdG8gY29uZmlndXJlIHRoZW0gcGVyIHByb3RvY29sPw0KSWYg dGhlIHR3byBTUkdCcyBhcmUgbm90IHRoZSBzYW1lLCBvdGhlciByb3V0ZXJzIGluIHRoZSBuZXR3 b3JrIGhhdmUgIG5vIGlkZWEgd2hpY2ggcHJvdG9jb2wgaXMgZ29pbmcgdG8gd2luIG9uIHlvdXIg Ym94LiBTbyB5b3VyIG5laWdoYm9yIGhhcyBubyBpZGVhIHdoZXRoZXIgaXQgc2hvdWxkIHVzZSB0 aGUgU1JHQiBhZHZlcnRpc2VkIGJ5IE9TUEYgb3IgdGhlIFNSR0IgYWR2ZXJ0aXNlZCBieSBJUy1J Uy4NCg0KICAgTGVzDQoNCg0KQ2hlZXJzLA0KUi4NCg0KDQpPbiBXZWQsIEp1bCAyOSwgMjAxNSBh dCAxMTowMSBQTSwgTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgPGdpbnNiZXJnQGNpc2NvLmNvbTxt YWlsdG86Z2luc2JlcmdAY2lzY28uY29tPj4gd3JvdGU6DQpTdGVwaGFuZSDigJMNCg0KV2hhdCBp cyB0aGUgcmVxdWlyZW1lbnQgdG8gaGF2ZSBhIHBlci1wcm90b2NvbCBTUkdCIGNvbmZpZz8NCuKA i+KAiw0KVGhpcyBtYWtlcyBubyBzZW5zZSB0byBtZSBvcGVyYXRpb25hbGx5IG9yIGFyY2hpdGVj dHVyYWxseS4NCg0KKEkgYW0gbm90IHRhbGtpbmcgYWJvdXQgd2hhdCBtYXkgb3IgbWF5IG5vdCBo YXZlIGJlZW4gaW1wbGVtZW50ZWQgYnkgdmVuZG9ycyDigJMgdGhlIFlBTkcgbW9kZWwgc2hvdWxk IGJlIGFyY2hpdGVjdHVyYWxseSBjb3JyZWN0KQ0KDQogICBMZXMNCg0K --_000_F3ADE4747C9E124B89F0ED2180CC814F594A5FF5xmbalnx02ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsN CgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwh W2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9 ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlv dXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PlJvYmVydCAtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJs dWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJy YXN6dWtAZ21haWwuY29tIFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dDQo8Yj5PbiBCZWhhbGYg T2YgPC9iPlJvYmVydCBSYXN6dWs8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdWx5IDI5 LCAyMDE1IDI6NDUgUE08YnI+DQo8Yj5Ubzo8L2I+IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpPGJy Pg0KPGI+Q2M6PC9iPiBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTsgVW1hIENodW5kdXJp OyBBaXNzYW91aSwgTXVzdGFwaGEgKE11c3RhcGhhKTsgc3ByaW5nQGlldGYub3JnOyBTaHJhZGRo YSBIZWdkZSAoc2hyYWRkaGFAanVuaXBlci5uZXQpOyBQdXNocGFzaXMgU2Fya2FyIChwc2Fya2Fy QGp1bmlwZXIubmV0KTsgSGFubmVzIEdyZWRsZXIgKGhhbm5lc0BqdW5pcGVyLm5ldCk8YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFtzcHJpbmddIE1vZGVsaW5nIFNSR0IgY29uZmlndXJhdGlvbiBm b3IgZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkhpIExlcyw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsg4oCLPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5UaGlzIG1ha2VzIG5vIHNlbnNlIHRvIG1lIG9wZXJhdGlvbmFsbHkg b3IgYXJjaGl0ZWN0dXJhbGx5Ljwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5GdW5kYW1lbnRhbGx5IEkgZnVsbHkgYWdyZWUgd2l0aCB5b3UuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SG93ZXZlciBhcmNoaXRl Y3R1cmFsbHk6Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Ib3dldmVyIGF0 IGxlYXN0IGxvb2tpbmcgYXQgZ3JvdXAgb2YgZm9sa3Mgd2hvIGNsYWltIHRoYXQgaXQgaXMgaW1w b3NzaWJsZSB0byBnZXQgc2FtZSBTUkdCIGJsb2NrIGluICphbnkqIG5ldHdvcmsgYmV0d2VlbiB0 d28gb3IgbW9yZSB2ZW5kb3JzICZuYnNwO0kgdGhpbmsgU3RlcGhhbmUncyBpbnRlbnRpb24gd291 bGQgYmUgdG8gYXQgbGVhc3QNCiBnZXQgaXQgcGVyIG9uZSBwcm90b2NvbCBldmVuIGlmIHBsYXRm b3JtIHdpZGUgdGhlIGludGVyc2VjdGluZyBwb29sIG1heSBiZSBtaXNzaW9uIGltcG9zc2libGUu Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltMZXM6XSBUaGlzIGlzIGFuIHVu cmVsYXRlZCBpc3N1ZS4gUGxhY2luZyBTUkdCIGluIGdsb2JhbCBjb250ZXh0IGRvZXMgbm90IG1l YW4gYWxsIHJvdXRlcnMgaGF2ZSB0byBoYXZlIHRoZSBzYW1lIFNSR0IuIFRoZXJlIGlzIG5vIGNv bnRyb3ZlcnN5IGhlcmUuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5hbmQgbm93IG9wZXJhdGlvbmFsbHk6Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Bbm90aGVyIHJlYXNvbiB3b3VsZCBiZSBpZGVhIG9mIGR1YWwg b3ZlcmxhcHBpbmcgU1JHQnMgcGVyaGFwcyBxdWl0ZSB1c2VmdWwgZHVyaW5nIG1pZ3JhdGlvbnMg YmV0d2VlbiBwcm90b2NvbHMgd2hlcmUgdGhlIGV4YWN0IHNhbWUgU1JHQiBpcyBzZXQgb24gYm90 aCB0aGVuIGp1c3QgYmFzZWQgb24gYWRtaW4gZGlzdGFuY2Ugb25lDQogdnMgdGhlIG90aGVyIHBy b3RvY29sIGlzIGNob3Nlbi4gV2hpbGUgYSBzdGFuZGFyZCBwcmFjdGljZSBpbiBwcm90b2NvbCBt aWdyYXRpb25zIG5vdCBzdXJlIGlmIGFueW9uZSBsb29rZWQgYXQgdGhhdCBmcm9tIFNSIHBlcnNw ZWN0aXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxp PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5bTGVzOl0gTm90IHN1 cmUgd2hhdCB5b3UgYXJlIHRyeWluZyB0byBzYXkuIElmIHRoZSB0d28gU1JHQnMgYXJlIHRoZSBz YW1lIOKAkyB3aHkgZG8gd2UgbmVlZCB0byBjb25maWd1cmUgdGhlbSBwZXIgcHJvdG9jb2w/PG86 cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgdGhlIHR3byBTUkdC cyBhcmUgbm90IHRoZSBzYW1lLCBvdGhlciByb3V0ZXJzIGluIHRoZSBuZXR3b3JrIGhhdmUgJm5i c3A7bm8gaWRlYSB3aGljaCBwcm90b2NvbCBpcyBnb2luZyB0byB3aW4gb24geW91ciBib3guIFNv IHlvdXIgbmVpZ2hib3IgaGFzIG5vIGlkZWENCiB3aGV0aGVyIGl0IHNob3VsZCB1c2UgdGhlIFNS R0IgYWR2ZXJ0aXNlZCBieSBPU1BGIG9yIHRoZSBTUkdCIGFkdmVydGlzZWQgYnkgSVMtSVMuPG86 cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IExlczxvOnA+ PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5SLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBX ZWQsIEp1bCAyOSwgMjAxNSBhdCAxMTowMSBQTSwgTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgJmx0 OzxhIGhyZWY9Im1haWx0bzpnaW5zYmVyZ0BjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5naW5z YmVyZ0BjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+U3Rl cGhhbmUg4oCTPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2hhdCBp cyB0aGUgcmVxdWlyZW1lbnQgdG8gaGF2ZSBhIHBlci1wcm90b2NvbCBTUkdCIGNvbmZpZz88L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PuKAi+KAizxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+VGhpcyBtYWtlcyBubyBzZW5zZSB0byBtZSBvcGVyYXRpb25hbGx5IG9yIGFyY2hpdGVjdHVy YWxseS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPihJIGFtIG5vdCB0YWxraW5n IGFib3V0IHdoYXQgbWF5IG9yIG1heSBub3QgaGF2ZSBiZWVuIGltcGxlbWVudGVkIGJ5IHZlbmRv cnMg4oCTIHRoZSBZQU5HIG1vZGVsIHNob3VsZCBiZSBhcmNoaXRlY3R1cmFsbHkgY29ycmVjdCk8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsgJm5ic3A7TGVz PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_F3ADE4747C9E124B89F0ED2180CC814F594A5FF5xmbalnx02ciscoc_-- From nobody Wed Jul 29 17:03:43 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835201B3096 for ; Wed, 29 Jul 2015 17:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsKPMub9OiF6 for ; Wed, 29 Jul 2015 17:03:40 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24E5B1B308B for ; Wed, 29 Jul 2015 17:03:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29638; q=dns/txt; s=iport; t=1438214620; x=1439424220; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aL6MndAXn+le6E7dG4DpLbjHLmiJR5nK4K8+kAgS1gM=; b=Ge2ncMhkhCozOPy+H4uMXTbCRNSVB3nJy8MGaYnn101uvz98TD7IvPxj y/4UYNPwjwQMWpGU7EMF711z04qSUvus+VyvMFCCC8wCJX8oM6PEOheZa 6BsHsY3t3Jrvxh9+/TOstN2qiOP1CG3yf2KFw6RJUOpyS81eCOmAskVe0 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AKBgARablV/5pdJa1bgk1NVFoPBoMduGqBeQEJhS9KAhyBPDoSAQEBAQEBAYEKhCMBAQEEAQEBIEsLEAIBBgIRBAEBIQcDAgICHwYLFAkIAgQOBR6HewMSDZwFnRmQRw2FLwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi06CToI1BAYBgmkvgRQFlHIBilmBaoFFkD2DS4NjJmSBKhyBU2+BSIEEAQEB X-IronPort-AV: E=Sophos; i="5.15,573,1432598400"; d="scan'208,217"; a="14232872" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 30 Jul 2015 00:03:39 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t6U03dmW029888 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jul 2015 00:03:39 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.37]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0195.001; Wed, 29 Jul 2015 19:03:38 -0500 From: "Acee Lindem (acee)" To: "Les Ginsberg (ginsberg)" Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AdDEofPBVXKHufkve0KzevJD/YWvlQAy4ooQAAtTpAAAAPoLAAAFzVkAACVU3IAA9ZAggAASigWAAAGFqgAAAYgzAAADTmMA Date: Thu, 30 Jul 2015 00:03:38 +0000 Message-ID: References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.204] Content-Type: multipart/alternative; boundary="_000_C8FCD0697C224F3093164ACB4A501576ciscocom_" MIME-Version: 1.0 Archived-At: Cc: Stephane Litkowski , "spring@ietf.org" , Robert Raszuk , "Shraddha Hegde \(shraddha@juniper.net\)" , Uma Chunduri , "Pushpasis Sarkar \(psarkar@juniper.net\)" , "Aissaoui, Mustapha \(Mustapha\)" , Hannes Gredler Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2015 00:03:42 -0000 --_000_C8FCD0697C224F3093164ACB4A501576ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpPbiBKdWwgMjksIDIwMTUsIGF0IDY6MjggUE0sIExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIDxn aW5zYmVyZ0BjaXNjby5jb208bWFpbHRvOmdpbnNiZXJnQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQpS b2JlcnQgLQ0KDQpGcm9tOiBycmFzenVrQGdtYWlsLmNvbTxtYWlsdG86cnJhc3p1a0BnbWFpbC5j b20+IFttYWlsdG86cnJhc3p1a0BnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBSb2JlcnQgUmFzenVr DQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMjksIDIwMTUgMjo0NSBQTQ0KVG86IExlcyBHaW5zYmVy ZyAoZ2luc2JlcmcpDQpDYzogc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208bWFpbHRvOnN0 ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPjsgVW1hIENodW5kdXJpOyBBaXNzYW91aSwgTXVz dGFwaGEgKE11c3RhcGhhKTsgc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+ OyBTaHJhZGRoYSBIZWdkZSAoc2hyYWRkaGFAanVuaXBlci5uZXQ8bWFpbHRvOnNocmFkZGhhQGp1 bmlwZXIubmV0Pik7IFB1c2hwYXNpcyBTYXJrYXIgKHBzYXJrYXJAanVuaXBlci5uZXQ8bWFpbHRv OnBzYXJrYXJAanVuaXBlci5uZXQ+KTsgSGFubmVzIEdyZWRsZXIgKGhhbm5lc0BqdW5pcGVyLm5l dDxtYWlsdG86aGFubmVzQGp1bmlwZXIubmV0PikNClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBNb2Rl bGluZyBTUkdCIGNvbmZpZ3VyYXRpb24gZm9yIGRyYWZ0LWlldGYtc3ByaW5nLXNyLXlhbmcNCg0K SGkgTGVzLA0KDQo+IOKAiw0KVGhpcyBtYWtlcyBubyBzZW5zZSB0byBtZSBvcGVyYXRpb25hbGx5 IG9yIGFyY2hpdGVjdHVyYWxseS4NCg0KRnVuZGFtZW50YWxseSBJIGZ1bGx5IGFncmVlIHdpdGgg eW91Lg0KDQoNCkhvd2V2ZXIgYXJjaGl0ZWN0dXJhbGx5Og0KDQpIb3dldmVyIGF0IGxlYXN0IGxv b2tpbmcgYXQgZ3JvdXAgb2YgZm9sa3Mgd2hvIGNsYWltIHRoYXQgaXQgaXMgaW1wb3NzaWJsZSB0 byBnZXQgc2FtZSBTUkdCIGJsb2NrIGluICphbnkqIG5ldHdvcmsgYmV0d2VlbiB0d28gb3IgbW9y ZSB2ZW5kb3JzICBJIHRoaW5rIFN0ZXBoYW5lJ3MgaW50ZW50aW9uIHdvdWxkIGJlIHRvIGF0IGxl YXN0IGdldCBpdCBwZXIgb25lIHByb3RvY29sIGV2ZW4gaWYgcGxhdGZvcm0gd2lkZSB0aGUgaW50 ZXJzZWN0aW5nIHBvb2wgbWF5IGJlIG1pc3Npb24gaW1wb3NzaWJsZS4NCg0KW0xlczpdIFRoaXMg aXMgYW4gdW5yZWxhdGVkIGlzc3VlLiBQbGFjaW5nIFNSR0IgaW4gZ2xvYmFsIGNvbnRleHQgZG9l cyBub3QgbWVhbiBhbGwgcm91dGVycyBoYXZlIHRvIGhhdmUgdGhlIHNhbWUgU1JHQi4gVGhlcmUg aXMgbm8gY29udHJvdmVyc3kgaGVyZS4NCg0KDQphbmQgbm93IG9wZXJhdGlvbmFsbHk6DQoNCkFu b3RoZXIgcmVhc29uIHdvdWxkIGJlIGlkZWEgb2YgZHVhbCBvdmVybGFwcGluZyBTUkdCcyBwZXJo YXBzIHF1aXRlIHVzZWZ1bCBkdXJpbmcgbWlncmF0aW9ucyBiZXR3ZWVuIHByb3RvY29scyB3aGVy ZSB0aGUgZXhhY3Qgc2FtZSBTUkdCIGlzIHNldCBvbiBib3RoIHRoZW4ganVzdCBiYXNlZCBvbiBh ZG1pbiBkaXN0YW5jZSBvbmUgdnMgdGhlIG90aGVyIHByb3RvY29sIGlzIGNob3Nlbi4gV2hpbGUg YSBzdGFuZGFyZCBwcmFjdGljZSBpbiBwcm90b2NvbCBtaWdyYXRpb25zIG5vdCBzdXJlIGlmIGFu eW9uZSBsb29rZWQgYXQgdGhhdCBmcm9tIFNSIHBlcnNwZWN0aXZlLg0KW0xlczpdIE5vdCBzdXJl IHdoYXQgeW91IGFyZSB0cnlpbmcgdG8gc2F5LiBJZiB0aGUgdHdvIFNSR0JzIGFyZSB0aGUgc2Ft ZSDigJMgd2h5IGRvIHdlIG5lZWQgdG8gY29uZmlndXJlIHRoZW0gcGVyIHByb3RvY29sPw0KSWYg dGhlIHR3byBTUkdCcyBhcmUgbm90IHRoZSBzYW1lLCBvdGhlciByb3V0ZXJzIGluIHRoZSBuZXR3 b3JrIGhhdmUgIG5vIGlkZWEgd2hpY2ggcHJvdG9jb2wgaXMgZ29pbmcgdG8gd2luIG9uIHlvdXIg Ym94LiBTbyB5b3VyIG5laWdoYm9yIGhhcyBubyBpZGVhIHdoZXRoZXIgaXQgc2hvdWxkIHVzZSB0 aGUgU1JHQiBhZHZlcnRpc2VkIGJ5IE9TUEYgb3IgdGhlIFNSR0IgYWR2ZXJ0aXNlZCBieSBJUy1J Uy4NCg0KDQpBY3R1YWxseSwgaWYgdGhlIHNhbWUgcHJlZml4IGluIHRoZSBzYW1lIHRvcG9sb2d5 IGlzIGFkdmVydGlzZWQgYnkgdHdvIHByb3RvY29scywgSSB3b3VsZCB0aGluayB0aGF0IHRoZSBT SUQgc2hvdWxkIG1hcCB0byB0aGUgc2FtZSBsYWJlbC4gSSBzZWUgbm8gYWR2YW50YWdlIGF0IGFs bCBpbiBoYXZpbmcgc2VwYXJhdGUgbGFiZWxzLg0KDQpBY2VlDQoNCg0KDQoNCiAgIExlcw0KDQoN CkNoZWVycywNClIuDQoNCg0KT24gV2VkLCBKdWwgMjksIDIwMTUgYXQgMTE6MDEgUE0sIExlcyBH aW5zYmVyZyAoZ2luc2JlcmcpIDxnaW5zYmVyZ0BjaXNjby5jb208bWFpbHRvOmdpbnNiZXJnQGNp c2NvLmNvbT4+IHdyb3RlOg0KU3RlcGhhbmUg4oCTDQoNCldoYXQgaXMgdGhlIHJlcXVpcmVtZW50 IHRvIGhhdmUgYSBwZXItcHJvdG9jb2wgU1JHQiBjb25maWc/DQrigIvigIsNClRoaXMgbWFrZXMg bm8gc2Vuc2UgdG8gbWUgb3BlcmF0aW9uYWxseSBvciBhcmNoaXRlY3R1cmFsbHkuDQoNCihJIGFt IG5vdCB0YWxraW5nIGFib3V0IHdoYXQgbWF5IG9yIG1heSBub3QgaGF2ZSBiZWVuIGltcGxlbWVu dGVkIGJ5IHZlbmRvcnMg4oCTIHRoZSBZQU5HIG1vZGVsIHNob3VsZCBiZSBhcmNoaXRlY3R1cmFs bHkgY29ycmVjdCkNCg0KICAgTGVzDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpzcHJpbmcgbWFpbGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8bWFp bHRvOnNwcmluZ0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc3ByaW5nDQoNCg== --_000_C8FCD0697C224F3093164ACB4A501576ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4215398B9D130046BD8619D8657A60CD@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4N CjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBKdWwg MjksIDIwMTUsIGF0IDY6MjggUE0sIExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpICZsdDs8YSBocmVm PSJtYWlsdG86Z2luc2JlcmdAY2lzY28uY29tIiBjbGFzcz0iIj5naW5zYmVyZ0BjaXNjby5jb208 L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGlu ZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFn ZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyIgY2xhc3M9IiI+Um9iZXJ0IC08bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9k aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3Jk ZXItbGVmdC1jb2xvcjogYmx1ZTsgYm9yZGVyLWxlZnQtd2lkdGg6IDEuNXB0OyBwYWRkaW5nOiAw aW4gMGluIDBpbiA0cHQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJi b3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDE4MSwg MTk2LCAyMjMpOyBib3JkZXItdG9wLXdpZHRoOiAxcHQ7IHBhZGRpbmc6IDNwdCAwaW4gMGluOyIg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KPGIgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6 IFRhaG9tYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxh IGhyZWY9Im1haWx0bzpycmFzenVrQGdtYWlsLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRl eHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+cnJhc3p1a0BnbWFpbC5jb208L2E+ PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPls8YSBocmVm PSJtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRl Y29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPm1haWx0bzpycmFzenVrQGdtYWlsLmNvbTwv YT5dPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiIGNs YXNzPSIiPk9uDQogQmVoYWxmIE9mPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjwvYj5Sb2JlcnQgUmFzenVrPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+ U2VudDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PldlZG5lc2RheSwgSnVseSAyOSwgMjAxNSAyOjQ1IFBNPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9 IiI+VG86PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh bj5MZXMgR2luc2JlcmcgKGdpbnNiZXJnKTxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkNjOjwv Yj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJl Zj0ibWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIiBzdHlsZT0iY29sb3I6IHB1 cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5zdGVwaGFuZS5saXRr b3dza2lAb3JhbmdlLmNvbTwvYT47IFVtYSBDaHVuZHVyaTsgQWlzc2FvdWksIE11c3RhcGhhIChN dXN0YXBoYSk7PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu PjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0 ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPnNwcmluZ0BpZXRmLm9yZzwvYT47 DQogU2hyYWRkaGEgSGVnZGUgKDxhIGhyZWY9Im1haWx0bzpzaHJhZGRoYUBqdW5pcGVyLm5ldCIg c3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9 IiI+c2hyYWRkaGFAanVuaXBlci5uZXQ8L2E+KTsgUHVzaHBhc2lzIFNhcmthciAoPGEgaHJlZj0i bWFpbHRvOnBzYXJrYXJAanVuaXBlci5uZXQiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRl Y29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPnBzYXJrYXJAanVuaXBlci5uZXQ8L2E+KTsN CiBIYW5uZXMgR3JlZGxlciAoPGEgaHJlZj0ibWFpbHRvOmhhbm5lc0BqdW5pcGVyLm5ldCIgc3R5 bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+ aGFubmVzQGp1bmlwZXIubmV0PC9hPik8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TdWJqZWN0 OjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6 IFtzcHJpbmddIE1vZGVsaW5nIFNSR0IgY29uZmlndXJhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zcHJp bmctc3IteWFuZzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpw IGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkhpIExl cyw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7 PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1 KTsiIGNsYXNzPSIiPiZndDsg4oCLPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMx LCA3MywgMTI1KTsiIGNsYXNzPSIiPlRoaXMgbWFrZXMgbm8gc2Vuc2UgdG8gbWUgb3BlcmF0aW9u YWxseSBvciBhcmNoaXRlY3R1cmFsbHkuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog QXJpYWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48 L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBz YW5zLXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5G dW5kYW1lbnRhbGx5IEkgZnVsbHkgYWdyZWUgd2l0aCB5b3UuPG86cCBjbGFzcz0iIj48L286cD48 L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBB cmlhbCwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5Ib3dldmVyIGFyY2hpdGVj dHVyYWxseTombmJzcDs8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5Ib3dldmVyIGF0IGxlYXN0 IGxvb2tpbmcgYXQgZ3JvdXAgb2YgZm9sa3Mgd2hvIGNsYWltIHRoYXQgaXQgaXMgaW1wb3NzaWJs ZSB0byBnZXQgc2FtZSBTUkdCIGJsb2NrIGluICphbnkqIG5ldHdvcmsgYmV0d2VlbiB0d28gb3Ig bW9yZSB2ZW5kb3JzICZuYnNwO0kgdGhpbmsgU3RlcGhhbmUncyBpbnRlbnRpb24gd291bGQgYmUg dG8gYXQgbGVhc3QgZ2V0IGl0IHBlcg0KIG9uZSBwcm90b2NvbCBldmVuIGlmIHBsYXRmb3JtIHdp ZGUgdGhlIGludGVyc2VjdGluZyBwb29sIG1heSBiZSBtaXNzaW9uIGltcG9zc2libGUuJm5ic3A7 PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PGkgY2xhc3M9IiI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7 IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvaT48L2I+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0K PGIgY2xhc3M9IiI+PGkgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIg Y2xhc3M9IiI+W0xlczpdIFRoaXMgaXMgYW4gdW5yZWxhdGVkIGlzc3VlLiBQbGFjaW5nIFNSR0Ig aW4gZ2xvYmFsIGNvbnRleHQgZG9lcyBub3QgbWVhbiBhbGwgcm91dGVycyBoYXZlIHRvIGhhdmUg dGhlIHNhbWUgU1JHQi4gVGhlcmUgaXMgbm8gY29udHJvdmVyc3kNCiBoZXJlLjxvOnAgY2xhc3M9 IiI+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bh bj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGlu IDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFs LCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij5hbmQgbm93IG9wZXJhdGlvbmFsbHk6Jm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+ PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ QW5vdGhlciByZWFzb24gd291bGQgYmUgaWRlYSBvZiBkdWFsIG92ZXJsYXBwaW5nIFNSR0JzIHBl cmhhcHMgcXVpdGUgdXNlZnVsIGR1cmluZyBtaWdyYXRpb25zIGJldHdlZW4gcHJvdG9jb2xzIHdo ZXJlIHRoZSBleGFjdCBzYW1lIFNSR0IgaXMgc2V0IG9uIGJvdGggdGhlbiBqdXN0IGJhc2VkIG9u IGFkbWluIGRpc3RhbmNlIG9uZSB2cyB0aGUgb3RoZXINCiBwcm90b2NvbCBpcyBjaG9zZW4uIFdo aWxlIGEgc3RhbmRhcmQgcHJhY3RpY2UgaW4gcHJvdG9jb2wgbWlncmF0aW9ucyBub3Qgc3VyZSBp ZiBhbnlvbmUgbG9va2VkIGF0IHRoYXQgZnJvbSBTUiBwZXJzcGVjdGl2ZS48bzpwIGNsYXNzPSIi PjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj48aSBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigz MSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5bTGVzOl0gTm90IHN1cmUgd2hhdCB5b3UgYXJlIHRyeWlu ZyB0byBzYXkuIElmIHRoZSB0d28gU1JHQnMgYXJlIHRoZSBzYW1lIOKAkyB3aHkgZG8gd2UgbmVl ZCB0byBjb25maWd1cmUgdGhlbSBwZXIgcHJvdG9jb2w/PG86cCBjbGFzcz0iIj48L286cD48L3Nw YW4+PC9pPjwvYj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+DQo8YiBjbGFzcz0iIj48aSBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7IiBjbGFzcz0iIj5JZiB0aGUgdHdvIFNSR0JzIGFyZSBub3QgdGhlIHNhbWUsIG90 aGVyIHJvdXRlcnMgaW4gdGhlIG5ldHdvcmsgaGF2ZSAmbmJzcDtubyBpZGVhIHdoaWNoIHByb3Rv Y29sIGlzIGdvaW5nIHRvIHdpbiBvbiB5b3VyIGJveC4gU28geW91ciBuZWlnaGJvcg0KIGhhcyBu byBpZGVhIHdoZXRoZXIgaXQgc2hvdWxkIHVzZSB0aGUgU1JHQiBhZHZlcnRpc2VkIGJ5IE9TUEYg b3IgdGhlIFNSR0IgYWR2ZXJ0aXNlZCBieSBJUy1JUy48L3NwYW4+PC9pPjwvYj48L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+ QWN0dWFsbHksIGlmIHRoZSBzYW1lIHByZWZpeCBpbiB0aGUgc2FtZSB0b3BvbG9neSBpcyBhZHZl cnRpc2VkIGJ5IHR3byBwcm90b2NvbHMsIEkgd291bGQgdGhpbmsgdGhhdCB0aGUgU0lEIHNob3Vs ZCBtYXAgdG8gdGhlIHNhbWUgbGFiZWwuIEkgc2VlIG5vIGFkdmFudGFnZSBhdCBhbGwgaW4gaGF2 aW5nIHNlcGFyYXRlIGxhYmVscy4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9k aXY+DQo8ZGl2PkFjZWUmbmJzcDs8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7 IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0 OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDog MHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBh dXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+ DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3JkZXIt bGVmdC1jb2xvcjogYmx1ZTsgYm9yZGVyLWxlZnQtd2lkdGg6IDEuNXB0OyBwYWRkaW5nOiAwaW4g MGluIDBpbiA0cHQ7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNz PSIiPjxpIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIi PjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PGkgY2xhc3M9 IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFu PjwvaT48L2I+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPGIgY2xhc3M9IiI+PGkgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTog MTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDcz LCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7Jm5ic3A7IExlczxvOnAgY2xhc3M9IiI+PC9vOnA+PC9z cGFuPjwvaT48L2I+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5i c3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTogQXJpYWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsi IGNsYXNzPSIiPkNoZWVycyw8bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+Ui48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1z aXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9 IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xhc3M9 IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHls ZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5 OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5i c3A7PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCk9uIFdlZCwgSnVsIDI5LCAyMDE1IGF0IDExOjAxIFBN LCBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdpbnNiZXJnQGNp c2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29y YXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmdpbnNiZXJnQGNpc2NvLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFz cz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5TdGVwaGFuZSDi gJM8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5XaGF0IGlzIHRoZSBy ZXF1aXJlbWVudCB0byBoYXZlIGEgcGVyLXByb3RvY29sIFNSR0IgY29uZmlnPzwvc3Bhbj48bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+4oCL4oCLPG86cCBjbGFzcz0iIj48L286cD48 L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyIgY2xhc3M9IiI+DQpUaGlzIG1ha2VzIG5vIHNlbnNlIHRvIG1lIG9wZXJhdGlvbmFsbHkgb3Ig YXJjaGl0ZWN0dXJhbGx5LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9v OnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+KEkgYW0g bm90IHRhbGtpbmcgYWJvdXQgd2hhdCBtYXkgb3IgbWF5IG5vdCBoYXZlIGJlZW4gaW1wbGVtZW50 ZWQgYnkgdmVuZG9ycyDigJMgdGhlIFlBTkcgbW9kZWwgc2hvdWxkIGJlIGFyY2hpdGVjdHVyYWxs eSBjb3JyZWN0KTwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0i bWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjog cmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwv bzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0i Ij4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNw OyAmbmJzcDtMZXM8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PG86cCBjbGFzcz0iIj48 L286cD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IGZsb2F0OiBu b25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNzPSIiPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9zcGFuPjxiciBzdHlsZT0iZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IGZsb2F0OiBub25lOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsiIGNsYXNz PSIiPnNwcmluZw0KIG1haWxpbmcgbGlzdDwvc3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlh bnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsg bGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRl eHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFs OyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdp ZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHN0 eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgZm9udC1mYW1p bHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQt dmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFy dDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBu b3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPnNwcmluZ0BpZXRmLm9yZzwvYT48YnIgc3R5bGU9ImZv bnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4 dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRl eHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdv cmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0i Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZzwvYT48YnIgc3R5 bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTog bm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4 dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3 aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_C8FCD0697C224F3093164ACB4A501576ciscocom_-- From nobody Wed Jul 29 23:16:08 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50FB21A1B79 for ; Wed, 29 Jul 2015 23:16:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkmxmokTjHaT for ; Wed, 29 Jul 2015 23:16:02 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0768.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:768]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDB821A1B77 for ; Wed, 29 Jul 2015 23:16:01 -0700 (PDT) Received: from BLUPR05MB435.namprd05.prod.outlook.com (10.141.27.150) by BLUPR05MB545.namprd05.prod.outlook.com (10.141.202.11) with Microsoft SMTP Server (TLS) id 15.1.225.19; Thu, 30 Jul 2015 06:15:45 +0000 Received: from BLUPR05MB1969.namprd05.prod.outlook.com (10.162.224.23) by BLUPR05MB435.namprd05.prod.outlook.com (10.141.27.150) with Microsoft SMTP Server (TLS) id 15.1.219.17; Thu, 30 Jul 2015 06:15:45 +0000 Received: from BLUPR05MB1969.namprd05.prod.outlook.com ([10.162.224.23]) by BLUPR05MB1969.namprd05.prod.outlook.com ([10.162.224.23]) with mapi id 15.01.0225.018; Thu, 30 Jul 2015 06:15:44 +0000 From: Pushpasis Sarkar To: "Les Ginsberg (ginsberg)" , "stephane.litkowski@orange.com" , Uma Chunduri , "Aissaoui, Mustapha (Mustapha)" , "spring@ietf.org" , Shraddha Hegde , Hannes Gredler Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQyo8qALK1ymkqgUyhrsqJ5EqZOw== Date: Thu, 30 Jul 2015 06:15:43 +0000 Message-ID: References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.184.14] x-microsoft-exchange-diagnostics: 1; BLUPR05MB435; 5:oukr0IQOjfnKYuQKnUS65YkRtmly3uzCCfcKduG2Bss7zT8OLgfUVYZp16npWMPTo1DpHDuZYgYEygzUDzIsOk7ui7OwYW/V2mTQcucKTw1GuCdWcHs+9r4oFmA3wPYC1397Js3QEn+SxElFzOOdJQ==; 24:AaUwX2pzhMJFOZALNC0t4XX6+7noADsjvRNywBq2/CGou8mI+/88tQcBFlkcgAXwvEjwRWOyzJXhbjaX2zmkwjgdw8oIC/06QAu/C9pD4vQ=; 20:V40Vb5lIGnTF7lHWq7BqsAZ/igEXFxChcibUBdId9Bzq/VJGUTE/i5hPw3SkyhkrqviZ3pz5JLWvIgVffiVrxg== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB435; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB545; blupr05mb435: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB435; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB435; x-forefront-prvs: 06530126A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(53754006)(377454003)(37854004)(189998001)(2656002)(4001450100002)(99286002)(106116001)(2900100001)(4001350100001)(87936001)(16236675004)(5001770100001)(36756003)(122556002)(77096005)(40100003)(102836002)(54356999)(77156002)(46102003)(230783001)(62966003)(93886004)(15975445007)(50986999)(2950100001)(19300405004)(107886002)(66066001)(5002640100001)(19580405001)(5001960100002)(92566002)(83506001)(5890100001)(2501003)(76176999)(19625215002)(19580395003)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB435; H:BLUPR05MB1969.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D1DFBCF92CCA6psarkarjunipernet_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2015 06:15:43.9185 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB435 X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB545; 2:bYXKbRyqDjl29UKyaRGXoxGGy6OBbE6IOoQUhumvqeoNNFTvsTmY4EHfNYUna5VtGpG+7Zv1DxIZ8M7hiuVbZK4sYr6HM3c6H68wZS42ZBI3Eej/SCp7jbygdXcgKYw/Lc8hlF3rWhBGOpn0KVRwiiynwBkGvmHMCuEa1LrmRcQ=; 3:fM/HzVFLoJKTDIE6iA/tIFjBrGGAJe2wTObtBEIqHZmtiH/8YeB6Cqc51HGq8NujBuk8mkHQkOMBCJIAhQIlvSHDh4mUXQE2O4DRtJ/htR0S3NpD3x1a6q3osFQcPVtRWlF6FkElojfwd4U6gFfZfw==; 25:fRyifvRRztbu2eBNB5znYumF6O2Gmi4chkVciXOjJGJl1GqEf84imY+TEH/XbWkC5vPgXY/xoQEdtyG8bqN64aeWy6csxbp3wAgFezhzZ9HD7Je24Oda6aO4peABmhn4yibOgKC9hcYQwmgAbXkupcSAvEWStq/eOSOqwDZ6b4wlM1rBnxfaZ/oB6YtEPuPg5eM9e4u1eX7Uv7mkQWdNNwC/7jgGUJNwGRaeN11smBdmK9+2jQThH07iA+sOEvm44NqUAxSuSXbGh9rZEt/0CA==; 20:UL6YTBgS60ZGYA5W85w8Tz9XQ8y8QXnYu9KHsczo2w07Rk5Buxo4rphBAzZxSsXDOQbqSSJIJUrT3sSHqfTUDA==; 23:KU7uFa21TB2Figak8NJzXs36lQ77/zJ5R/TCe5azkEejWHIpxzkrLNr2iIjlveWdtpxnuUsa1sfAUssG2UqPkPXs0UBNtzwwXcev0p/cE724TVIMyIIvMk/bv6PT03wynSOuvjzh4+fRd1wuuAk1ccBFjHVJj+YUoJi43zAdOs1QC9A0zehmj0I2/2fwzzQguG34doBFoU2Yooy48cYKkh7lX36LtWBdS6Ck1fSCIUhAWV6PV6jjXtpFA5SOa72y BLUPR05MB545: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2015 06:16:06 -0000 --_000_D1DFBCF92CCA6psarkarjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Les, From: "Les Ginsberg (ginsberg)" > Date: Wednesday, July 29, 2015 at 11:01 PM To: "stephane.litkowski@orange.com" <= stephane.litkowski@orange.com>, Uma C= hunduri >, "Ais= saoui, Mustapha (Mustapha)" >, "spring@ietf.org" >, Shraddha Hegde >, Pushpasis Sarkar >, Hannes Gredler > Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Stephane - What is the requirement to have a per-protocol SRGB config? This makes no sense to me operationally or architecturally. [Pushpasis] In current MPLS architecture, the same label is not allocated b= y both RSVP and LDP in a given box. With SR mapped to MPLS data-plane, we w= ould like to retain the same behavior. For the same destination the label a= llocated by ISIS should be different than the label allocated by OSPF. This= can be achieved in two ways: 1. ISIS and OSPF using same SRGBs but different index ranges. 2. ISIS and OSPF using different SRGBs but can have the same index range= s. I prefer option 2, as the operator does not need to maintain two different = index ranges (one per-protocol). (I am not talking about what may or may not have been implemented by vendor= s - the YANG model should be architecturally correct) Les From: stephane.litkowski@orange.com [= mailto:stephane.litkowski@orange.com] Sent: Wednesday, July 29, 2015 5:11 AM To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); s= pring@ietf.org; Shraddha Hegde (shraddha@juniper.ne= t); Pushpasis Sarkar (psarkar@juniper.net); Hannes Gredler (hannes@juniper.net) Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi all, What if we keep the SRGB block config in "segment-routing" global module, a= nd if we allow for YANG configuration of carving this block inside each pro= tocol (maybe as a feature) ? Stephane From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] Sent: Friday, July 24, 2015 16:59 To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI Steph= ane SCE/IBNF; spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang >Suggesting that the forwarding instruction (AKA label) needs to be differ= ent depending on what protocol provided >the instruction is completely unnecessary - it simply wastes label space. [Uma]: Les, No - I never suggested anything like that. SRGB for a routing instance to be advertised should be part of the routing = instance provisioning as far as the yang model is concerned. Carving out the label space for SR is a local matter and agree, of course, = this can be done in so many ways through CLI, dynamically, statically etc.= .. -- Uma C. ___________________________________________________________________________= ______________________________________________ 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_D1DFBCF92CCA6psarkarjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Les,

From: "Les Ginsberg (ginsberg)= " <ginsberg@cisco.com>=
Date: Wednesday, July 29, 2015 at 1= 1:01 PM
To: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com= >, Uma Chunduri <uma.chu= nduri@ericsson.com>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com>, &= quot;spring@ietf.org" <spring@ietf.org>, Shraddha Hegde <shraddha@juniper.net>, = Pushpasis Sarkar <psarkar@juniper= .net>, Hannes Gredler <hann= es@juniper.net>
Subject: RE: [spring] Modeling SRGB= configuration for draft-ietf-spring-sr-yang

Stephane –<= /o:p>

 

What is the requiremen= t to have a per-protocol SRGB config?

This makes no sense to= me operationally or architecturally.
[Pushpasis] In current MPLS architecture, the same label is not alloca= ted by both RSVP and LDP in a given box. With SR mapped to MPLS data-plane,= we would like to retain the same behavior. For the same destination the la= bel allocated by ISIS should be different than the label allocated by OSPF. This can be achieved in two wa= ys:
  1. ISIS and OSPF using same SRGBs but different index ranges.
  2. ISIS= and OSPF using different SRGBs but can have the same index ranges.
    3. I prefer option 2, as the operator does not need to maintain two diffe= rent index ranges (one per-protocol).

     

    (I am not talking abou= t what may or may not have been implemented by vendors – the YANG mod= el should be architecturally correct)

     

       Les<= /o:p>

     

     

    From: stephane.litkowski@orange.= com [mailto:stephane.l= itkowski@orange.com]
    Sent: Wednesday, July 29, 2015 5:11 AM
    To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Musta= pha); spring@ietf.org; Shraddha Hegde (shraddha@juniper.net); Pushpasis Sarkar (psarkar@juniper.net); Hannes Gredler (hannes@juniper.net)
    Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

     

    Hi all,

     

    What if we keep the SR= GB block config in “segment-routing” global module, and if we a= llow for YANG configuration of carving this block inside each protocol (may= be as a feature) ?

     

    Stephane

     

     

    From: Uma Chunduri [mailto:uma.chunduri@ericsson.com]
    Sent: Friday, July 24, 2015 16:59
    To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSK= I Stephane SCE/IBNF; spring@ietf.org
    Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

     

    >Suggesting that the forwarding instruction (AKA label)  needs= to be different depending on what protocol provided

    >the instruction is completely unnecessary – it simply wastes= label space.

     

    [Uma]: Les, No - I nev= er suggested anything like that.

    SRGB for a routing ins= tance to be advertised should be part of the routing instance provisioning = as far as the yang model is concerned.

    Carving out the label = space for SR is a local matter and agree, of course, this  can be done= in so many ways through CLI, dynamically, statically etc...

     

    --

    Uma C.

     

    ______________________________________________________________________=
___________________________________________________
     
    Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
    pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
    a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
    Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
     
    This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
    they should not be distributed, used or copied without authorisation.<=
o:p>
    If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
    As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
    Thank you.
     --_000_D1DFBCF92CCA6psarkarjunipernet_-- From nobody Wed Jul 29 23:22:44 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4A131A1BE3 for ; Wed, 29 Jul 2015 23:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0yCKxc-betTD for ; Wed, 29 Jul 2015 23:22:40 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:710]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B15221A1BDC for ; Wed, 29 Jul 2015 23:22:39 -0700 (PDT) Received: from BLUPR05MB1969.namprd05.prod.outlook.com (10.162.224.23) by BLUPR05MB436.namprd05.prod.outlook.com (10.141.27.152) with Microsoft SMTP Server (TLS) id 15.1.219.17; Thu, 30 Jul 2015 06:22:17 +0000 Received: from BLUPR05MB1969.namprd05.prod.outlook.com ([10.162.224.23]) by BLUPR05MB1969.namprd05.prod.outlook.com ([10.162.224.23]) with mapi id 15.01.0225.018; Thu, 30 Jul 2015 06:22:17 +0000 From: Pushpasis Sarkar To: "Acee Lindem (acee)" , "Les Ginsberg (ginsberg)" Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQypAVjKtfymxgv0KenDNC8JaQLQ== Date: Thu, 30 Jul 2015 06:22:17 +0000 Message-ID: References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.184.14] x-microsoft-exchange-diagnostics: 1; BLUPR05MB436; 5:9RYtbS34f9v2RccuCEQLMRqqt0snNI7ziuZg5fcRgGshEMkR3CoyMSxRLHrzcxq47fOpuldR8XhFDkLgA45whRYlTDdhlliZ8XWTnWW4Lxxkfjo00Jz1OQRwvdWkElt7QQWT/655+CZI/Dy/zY0BBw==; 24:1p7Q8pcy23otT4FrJXMheekCWcxZ8YqyxU8zZX4vG3UZs6Ma0LdRDZjAnX2mfrsb3pm3xyI/8Nc3324kPWHMDRud8LbF3MWTUTB0bJYWPrw=; 20:umIE+ZJ2pmSvzdnsOcf+rMmEyG3vST6EoKjF5qtYXv8DDo7RPClDhR+Yuz7csYDd24pG8/j1595SzVhXnHQK9A== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB436; blupr05mb436: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB436; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB436; x-forefront-prvs: 06530126A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(37854004)(24454002)(57704003)(50986999)(2950100001)(76176999)(19580405001)(16236675004)(62966003)(86362001)(54356999)(2656002)(107886002)(93886004)(87936001)(40100003)(83506001)(19580395003)(230783001)(5002640100001)(77156002)(106116001)(5001960100002)(189998001)(92566002)(122556002)(66066001)(5001770100001)(15975445007)(77096005)(46102003)(36756003)(19617315012)(4001350100001)(2900100001)(99286002)(102836002)(4001430100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB436; H:BLUPR05MB1969.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D1DFBF742CCC8psarkarjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2015 06:22:17.4061 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB436 Archived-At: Cc: Stephane Litkowski , "spring@ietf.org" , Robert Raszuk , Shraddha Hegde , Uma Chunduri , "Aissaoui, Mustapha \(Mustapha\)" , Hannes Gredler Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2015 06:22:43 -0000 --_000_D1DFBF742CCC8psarkarjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SEkgQWNlZSwNCg0KRnJvbTogIkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lzY28uY29tPG1h aWx0bzphY2VlQGNpc2NvLmNvbT4+DQpEYXRlOiBUaHVyc2RheSwgSnVseSAzMCwgMjAxNSBhdCAy OjAzIEFNDQpUbzogIkxlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIiA8Z2luc2JlcmdAY2lzY28uY29t PG1haWx0bzpnaW5zYmVyZ0BjaXNjby5jb20+Pg0KQ2M6IFJvYmVydCBSYXN6dWsgPHJvYmVydEBy YXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD4+LCBTdGVwaGFuZSBMaXRrb3dza2kg PHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPG1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lA b3JhbmdlLmNvbT4+LCAic3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IiA8 c3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+PiwgU2hyYWRkaGEgSGVnZGUg PHNocmFkZGhhQGp1bmlwZXIubmV0PG1haWx0bzpzaHJhZGRoYUBqdW5pcGVyLm5ldD4+LCBVbWEg Q2h1bmR1cmkgPHVtYS5jaHVuZHVyaUBlcmljc3Nvbi5jb208bWFpbHRvOnVtYS5jaHVuZHVyaUBl cmljc3Nvbi5jb20+PiwgUHVzaHBhc2lzIFNhcmthciA8cHNhcmthckBqdW5pcGVyLm5ldDxtYWls dG86cHNhcmthckBqdW5pcGVyLm5ldD4+LCAiQWlzc2FvdWksIE11c3RhcGhhIChNdXN0YXBoYSki IDxtdXN0YXBoYS5haXNzYW91aUBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOm11c3RhcGhhLmFp c3Nhb3VpQGFsY2F0ZWwtbHVjZW50LmNvbT4+LCBIYW5uZXMgR3JlZGxlciA8aGFubmVzQGp1bmlw ZXIubmV0PG1haWx0bzpoYW5uZXNAanVuaXBlci5uZXQ+Pg0KU3ViamVjdDogUmU6IFtzcHJpbmdd IE1vZGVsaW5nIFNSR0IgY29uZmlndXJhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFu Zw0KDQoNCk9uIEp1bCAyOSwgMjAxNSwgYXQgNjoyOCBQTSwgTGVzIEdpbnNiZXJnIChnaW5zYmVy ZykgPGdpbnNiZXJnQGNpc2NvLmNvbTxtYWlsdG86Z2luc2JlcmdAY2lzY28uY29tPj4gd3JvdGU6 DQoNClJvYmVydCAtDQoNCkZyb206IHJyYXN6dWtAZ21haWwuY29tPG1haWx0bzpycmFzenVrQGdt YWlsLmNvbT4gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9mIFJvYmVydCBS YXN6dWsNClNlbnQ6IFdlZG5lc2RheSwgSnVseSAyOSwgMjAxNSAyOjQ1IFBNDQpUbzogTGVzIEdp bnNiZXJnIChnaW5zYmVyZykNCkNjOiBzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTxtYWls dG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+OyBVbWEgQ2h1bmR1cmk7IEFpc3Nhb3Vp LCBNdXN0YXBoYSAoTXVzdGFwaGEpOyBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRm Lm9yZz47IFNocmFkZGhhIEhlZ2RlIChzaHJhZGRoYUBqdW5pcGVyLm5ldDxtYWlsdG86c2hyYWRk aGFAanVuaXBlci5uZXQ+KTsgUHVzaHBhc2lzIFNhcmthciAocHNhcmthckBqdW5pcGVyLm5ldDxt YWlsdG86cHNhcmthckBqdW5pcGVyLm5ldD4pOyBIYW5uZXMgR3JlZGxlciAoaGFubmVzQGp1bmlw ZXIubmV0PG1haWx0bzpoYW5uZXNAanVuaXBlci5uZXQ+KQ0KU3ViamVjdDogUmU6IFtzcHJpbmdd IE1vZGVsaW5nIFNSR0IgY29uZmlndXJhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFu Zw0KDQpIaSBMZXMsDQoNCj4g4oCLDQpUaGlzIG1ha2VzIG5vIHNlbnNlIHRvIG1lIG9wZXJhdGlv bmFsbHkgb3IgYXJjaGl0ZWN0dXJhbGx5Lg0KDQpGdW5kYW1lbnRhbGx5IEkgZnVsbHkgYWdyZWUg d2l0aCB5b3UuDQoNCg0KSG93ZXZlciBhcmNoaXRlY3R1cmFsbHk6DQoNCkhvd2V2ZXIgYXQgbGVh c3QgbG9va2luZyBhdCBncm91cCBvZiBmb2xrcyB3aG8gY2xhaW0gdGhhdCBpdCBpcyBpbXBvc3Np YmxlIHRvIGdldCBzYW1lIFNSR0IgYmxvY2sgaW4gKmFueSogbmV0d29yayBiZXR3ZWVuIHR3byBv ciBtb3JlIHZlbmRvcnMgIEkgdGhpbmsgU3RlcGhhbmUncyBpbnRlbnRpb24gd291bGQgYmUgdG8g YXQgbGVhc3QgZ2V0IGl0IHBlciBvbmUgcHJvdG9jb2wgZXZlbiBpZiBwbGF0Zm9ybSB3aWRlIHRo ZSBpbnRlcnNlY3RpbmcgcG9vbCBtYXkgYmUgbWlzc2lvbiBpbXBvc3NpYmxlLg0KDQpbTGVzOl0g VGhpcyBpcyBhbiB1bnJlbGF0ZWQgaXNzdWUuIFBsYWNpbmcgU1JHQiBpbiBnbG9iYWwgY29udGV4 dCBkb2VzIG5vdCBtZWFuIGFsbCByb3V0ZXJzIGhhdmUgdG8gaGF2ZSB0aGUgc2FtZSBTUkdCLiBU aGVyZSBpcyBubyBjb250cm92ZXJzeSBoZXJlLg0KDQoNCmFuZCBub3cgb3BlcmF0aW9uYWxseToN Cg0KQW5vdGhlciByZWFzb24gd291bGQgYmUgaWRlYSBvZiBkdWFsIG92ZXJsYXBwaW5nIFNSR0Jz IHBlcmhhcHMgcXVpdGUgdXNlZnVsIGR1cmluZyBtaWdyYXRpb25zIGJldHdlZW4gcHJvdG9jb2xz IHdoZXJlIHRoZSBleGFjdCBzYW1lIFNSR0IgaXMgc2V0IG9uIGJvdGggdGhlbiBqdXN0IGJhc2Vk IG9uIGFkbWluIGRpc3RhbmNlIG9uZSB2cyB0aGUgb3RoZXIgcHJvdG9jb2wgaXMgY2hvc2VuLiBX aGlsZSBhIHN0YW5kYXJkIHByYWN0aWNlIGluIHByb3RvY29sIG1pZ3JhdGlvbnMgbm90IHN1cmUg aWYgYW55b25lIGxvb2tlZCBhdCB0aGF0IGZyb20gU1IgcGVyc3BlY3RpdmUuDQpbTGVzOl0gTm90 IHN1cmUgd2hhdCB5b3UgYXJlIHRyeWluZyB0byBzYXkuIElmIHRoZSB0d28gU1JHQnMgYXJlIHRo ZSBzYW1lIOKAkyB3aHkgZG8gd2UgbmVlZCB0byBjb25maWd1cmUgdGhlbSBwZXIgcHJvdG9jb2w/ DQpJZiB0aGUgdHdvIFNSR0JzIGFyZSBub3QgdGhlIHNhbWUsIG90aGVyIHJvdXRlcnMgaW4gdGhl IG5ldHdvcmsgaGF2ZSAgbm8gaWRlYSB3aGljaCBwcm90b2NvbCBpcyBnb2luZyB0byB3aW4gb24g eW91ciBib3guIFNvIHlvdXIgbmVpZ2hib3IgaGFzIG5vIGlkZWEgd2hldGhlciBpdCBzaG91bGQg dXNlIHRoZSBTUkdCIGFkdmVydGlzZWQgYnkgT1NQRiBvciB0aGUgU1JHQiBhZHZlcnRpc2VkIGJ5 IElTLUlTLg0KDQoNCkFjdHVhbGx5LCBpZiB0aGUgc2FtZSBwcmVmaXggaW4gdGhlIHNhbWUgdG9w b2xvZ3kgaXMgYWR2ZXJ0aXNlZCBieSB0d28gcHJvdG9jb2xzLCBJIHdvdWxkIHRoaW5rIHRoYXQg dGhlIFNJRCBzaG91bGQgbWFwIHRvIHRoZSBzYW1lIGxhYmVsLiBJIHNlZSBubyBhZHZhbnRhZ2Ug YXQgYWxsIGluIGhhdmluZyBzZXBhcmF0ZSBsYWJlbHMuDQpbUHVzaHBhc2lzXSBXZSBhcmUgdGFs a2luZyBhYm91dCB0aGUgTVBMUyB0cmFuc2l0IGxhYmVsIGZvciB0aGUgZGVzdGluYXRpb24gRkVD IGhlcmUuIExpa2UgUlNWUCBhbmQgTERQLCBpbiBNUExTIGRhdGEgcGxhbmUgdG9kYXksIHRoZSBG RUMgbWF5YmUgc2FtZSBidXQgdGhlIHRyYW5zaXQgbGFiZWwgYWxsb2NhdGVkIGJ5IGVhY2ggcHJv dG9jb2wgYXJlIGRpZmZlcmVudC4gU2ltaWxhcmx5IGZvciBTUiBtYXBwZWQgdG8gTVBMUyBkYXRh IHBsYW5lIHRoZSB0cmFuc2l0IGxhYmVsIGFsbG9jYXRlZCBieSBJU0lTIGFuZCBPU1BGIGZvciB0 aGUgc2FtZSBkZXN0aW5hdGlvbiBGRUMgc2hvdWxkIGJlIGRpZmZlcmVudC4gSGVuY2UgdGhlIG5l ZWQgb2YgcGVyLXByb3RvY29sIFNSR0IuDQoNCkFjZWUNCg0KDQoNCg0KICAgTGVzDQoNCg0KQ2hl ZXJzLA0KUi4NCg0KDQpPbiBXZWQsIEp1bCAyOSwgMjAxNSBhdCAxMTowMSBQTSwgTGVzIEdpbnNi ZXJnIChnaW5zYmVyZykgPGdpbnNiZXJnQGNpc2NvLmNvbTxtYWlsdG86Z2luc2JlcmdAY2lzY28u Y29tPj4gd3JvdGU6DQpTdGVwaGFuZSDigJMNCg0KV2hhdCBpcyB0aGUgcmVxdWlyZW1lbnQgdG8g aGF2ZSBhIHBlci1wcm90b2NvbCBTUkdCIGNvbmZpZz8NCuKAi+KAiw0KVGhpcyBtYWtlcyBubyBz ZW5zZSB0byBtZSBvcGVyYXRpb25hbGx5IG9yIGFyY2hpdGVjdHVyYWxseS4NCg0KKEkgYW0gbm90 IHRhbGtpbmcgYWJvdXQgd2hhdCBtYXkgb3IgbWF5IG5vdCBoYXZlIGJlZW4gaW1wbGVtZW50ZWQg YnkgdmVuZG9ycyDigJMgdGhlIFlBTkcgbW9kZWwgc2hvdWxkIGJlIGFyY2hpdGVjdHVyYWxseSBj b3JyZWN0KQ0KDQogICBMZXMNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCnNwcmluZyBtYWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86 c3ByaW5nQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z cHJpbmcNCg0K --_000_D1DFBF742CCC8psarkarjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <83F54C9FACBE084F8CF5CE24975134E2@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsiPkhJ IEFjZWUsPC9kaXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyI+PGJyPg0KPC9k aXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSJjb2xvcjogcmdiKDAs IDAsIDApOyI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFw dDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5v bmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElO Ry1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQg c29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj4mcXVvdDtBY2VlIExpbmRl bSAoYWNlZSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzphY2VlQGNpc2NvLmNvbSI+YWNlZUBj aXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRl OiA8L3NwYW4+VGh1cnNkYXksIEp1bHkgMzAsIDIwMTUgYXQgMjowMyBBTTxicj4NCjxzcGFuIHN0 eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90O0xlcyBHaW5zYmVyZyAoZ2lu c2JlcmcpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86Z2luc2JlcmdAY2lzY28uY29tIj5naW5z YmVyZ0BjaXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5DYzogPC9zcGFuPlJvYmVydCBSYXN6dWsgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2JlcnRAcmFz enVrLm5ldCI+cm9iZXJ0QHJhc3p1ay5uZXQ8L2E+Jmd0OywgU3RlcGhhbmUgTGl0a293c2tpICZs dDs8YSBocmVmPSJtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20iPnN0ZXBoYW5l LmxpdGtvd3NraUBvcmFuZ2UuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpzcHJp bmdAaWV0Zi5vcmciPnNwcmluZ0BpZXRmLm9yZzwvYT4mcXVvdDsNCiAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYub3JnPC9hPiZndDssIFNocmFkZGhhIEhl Z2RlICZsdDs8YSBocmVmPSJtYWlsdG86c2hyYWRkaGFAanVuaXBlci5uZXQiPnNocmFkZGhhQGp1 bmlwZXIubmV0PC9hPiZndDssIFVtYSBDaHVuZHVyaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnVtYS5j aHVuZHVyaUBlcmljc3Nvbi5jb20iPnVtYS5jaHVuZHVyaUBlcmljc3Nvbi5jb208L2E+Jmd0Oywg UHVzaHBhc2lzIFNhcmthciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBzYXJrYXJAanVuaXBlci5uZXQi PnBzYXJrYXJAanVuaXBlci5uZXQ8L2E+Jmd0OywNCiAmcXVvdDtBaXNzYW91aSwgTXVzdGFwaGEg KE11c3RhcGhhKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm11c3RhcGhhLmFpc3Nhb3VpQGFs Y2F0ZWwtbHVjZW50LmNvbSI+bXVzdGFwaGEuYWlzc2FvdWlAYWxjYXRlbC1sdWNlbnQuY29tPC9h PiZndDssIEhhbm5lcyBHcmVkbGVyICZsdDs8YSBocmVmPSJtYWlsdG86aGFubmVzQGp1bmlwZXIu bmV0Ij5oYW5uZXNAanVuaXBlci5uZXQ8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtzcHJpbmddIE1vZGVsaW5nIFNSR0IgY29u ZmlndXJhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFuZzxicj4NCjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdvcmQ7 IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13aGl0 ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBKdWwgMjksIDIwMTUsIGF0IDY6 MjggUE0sIExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpICZsdDs8YSBocmVmPSJtYWlsdG86Z2luc2Jl cmdAY2lzY28uY29tIiBjbGFzcz0iIj5naW5zYmVyZ0BjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8 L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24x OyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5v cm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQt YWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hp dGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtp dC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xh c3M9IiI+Um9iZXJ0IC08bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJn YigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXItc3R5bGU6IG5vbmUgbm9uZSBub25lIHNvbGlkOyBib3JkZXItbGVmdC1jb2xvcjog Ymx1ZTsgYm9yZGVyLWxlZnQtd2lkdGg6IDEuNXB0OyBwYWRkaW5nOiAwaW4gMGluIDBpbiA0cHQ7 IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJib3JkZXItc3R5bGU6IHNv bGlkIG5vbmUgbm9uZTsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDE4MSwgMTk2LCAyMjMpOyBib3Jk ZXItdG9wLXdpZHRoOiAxcHQ7IHBhZGRpbmc6IDNwdCAwaW4gMGluOyIgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MHB0OyBmb250LWZhbWlseTogVGFob21hLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+PHNwYW4gY2xh c3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpy cmFzenVrQGdtYWlsLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjog dW5kZXJsaW5lOyIgY2xhc3M9IiI+cnJhc3p1a0BnbWFpbC5jb208L2E+PHNwYW4gY2xhc3M9IkFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPls8YSBocmVmPSJtYWlsdG86cnJhc3p1 a0BnbWFpbC5jb20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVy bGluZTsiIGNsYXNzPSIiPm1haWx0bzpycmFzenVrQGdtYWlsLmNvbTwvYT5dPHNwYW4gY2xhc3M9 IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiIGNsYXNzPSIiPk9uDQogQmVo YWxmIE9mPHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwv Yj5Sb2JlcnQgUmFzenVrPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+U2VudDo8L2I+PHNwYW4g Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPldlZG5lc2RheSwgSnVs eSAyOSwgMjAxNSAyOjQ1IFBNPGJyIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+VG86PC9iPjxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5MZXMgR2luc2Jlcmcg KGdpbnNiZXJnKTxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPkNjOjwvYj48c3BhbiBjbGFzcz0i QXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnN0ZXBo YW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNv cmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5zdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNv bTwvYT47IFVtYSBDaHVuZHVyaTsgQWlzc2FvdWksIE11c3RhcGhhIChNdXN0YXBoYSk7PHNwYW4g Y2xhc3M9IkFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzpzcHJpbmdAaWV0Zi5vcmciIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246 IHVuZGVybGluZTsiIGNsYXNzPSIiPnNwcmluZ0BpZXRmLm9yZzwvYT47DQogU2hyYWRkaGEgSGVn ZGUgKDxhIGhyZWY9Im1haWx0bzpzaHJhZGRoYUBqdW5pcGVyLm5ldCIgc3R5bGU9ImNvbG9yOiBw dXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+c2hyYWRkaGFAanVu aXBlci5uZXQ8L2E+KTsgUHVzaHBhc2lzIFNhcmthciAoPGEgaHJlZj0ibWFpbHRvOnBzYXJrYXJA anVuaXBlci5uZXQiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVy bGluZTsiIGNsYXNzPSIiPnBzYXJrYXJAanVuaXBlci5uZXQ8L2E+KTsNCiBIYW5uZXMgR3JlZGxl ciAoPGEgaHJlZj0ibWFpbHRvOmhhbm5lc0BqdW5pcGVyLm5ldCIgc3R5bGU9ImNvbG9yOiBwdXJw bGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+aGFubmVzQGp1bmlwZXIu bmV0PC9hPik8YnIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5TdWJqZWN0OjwvYj48c3BhbiBjbGFz cz0iQXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UmU6IFtzcHJpbmddIE1vZGVs aW5nIFNSR0IgY29uZmlndXJhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFuZzxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8bzpwIGNsYXNzPSIiPiZuYnNw OzwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkhpIExlcyw8bzpwIGNsYXNzPSIi PjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9 Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0K PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZn dDsg4oCLPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5 bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls eTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNs YXNzPSIiPlRoaXMgbWFrZXMgbm8gc2Vuc2UgdG8gbWUgb3BlcmF0aW9uYWxseSBvciBhcmNoaXRl Y3R1cmFsbHkuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2Vy aWY7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0K PGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9u dC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xh c3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xh c3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFt aWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5GdW5kYW1lbnRhbGx5IEkg ZnVsbHkgYWdyZWUgd2l0aCB5b3UuPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJp ZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9z cGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJp YWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5Ib3dldmVyIGFyY2hpdGVjdHVyYWxseTombmJzcDs8 bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBm b250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7PC9z cGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJp YWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5Ib3dldmVyIGF0IGxlYXN0IGxvb2tpbmcgYXQgZ3Jv dXAgb2YgZm9sa3Mgd2hvIGNsYWltIHRoYXQgaXQgaXMgaW1wb3NzaWJsZSB0byBnZXQgc2FtZSBT UkdCIGJsb2NrIGluICphbnkqIG5ldHdvcmsgYmV0d2VlbiB0d28gb3IgbW9yZSB2ZW5kb3JzICZu YnNwO0kgdGhpbmsgU3RlcGhhbmUncyBpbnRlbnRpb24gd291bGQgYmUgdG8gYXQgbGVhc3QgZ2V0 IGl0IHBlcg0KIG9uZSBwcm90b2NvbCBldmVuIGlmIHBsYXRmb3JtIHdpZGUgdGhlIGludGVyc2Vj dGluZyBwb29sIG1heSBiZSBtaXNzaW9uIGltcG9zc2libGUuJm5ic3A7PG86cCBjbGFzcz0iIj48 L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PGkgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvaT48L2I+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PGkg Y2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+W0xlczpd IFRoaXMgaXMgYW4gdW5yZWxhdGVkIGlzc3VlLiBQbGFjaW5nIFNSR0IgaW4gZ2xvYmFsIGNvbnRl eHQgZG9lcyBub3QgbWVhbiBhbGwgcm91dGVycyBoYXZlIHRvIGhhdmUgdGhlIHNhbWUgU1JHQi4g VGhlcmUgaXMgbm8gY29udHJvdmVyc3kNCiBoZXJlLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFu PjwvaT48L2I+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiBBcmlhbCwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyIg Y2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5hbmQgbm93IG9wZXJh dGlvbmFsbHk6Jm5ic3A7PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNs YXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiIGNs YXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+QW5vdGhlciByZWFzb24g d291bGQgYmUgaWRlYSBvZiBkdWFsIG92ZXJsYXBwaW5nIFNSR0JzIHBlcmhhcHMgcXVpdGUgdXNl ZnVsIGR1cmluZyBtaWdyYXRpb25zIGJldHdlZW4gcHJvdG9jb2xzIHdoZXJlIHRoZSBleGFjdCBz YW1lIFNSR0IgaXMgc2V0IG9uIGJvdGggdGhlbiBqdXN0IGJhc2VkIG9uIGFkbWluIGRpc3RhbmNl IG9uZSB2cyB0aGUgb3RoZXINCiBwcm90b2NvbCBpcyBjaG9zZW4uIFdoaWxlIGEgc3RhbmRhcmQg cHJhY3RpY2UgaW4gcHJvdG9jb2wgbWlncmF0aW9ucyBub3Qgc3VyZSBpZiBhbnlvbmUgbG9va2Vk IGF0IHRoYXQgZnJvbSBTUiBwZXJzcGVjdGl2ZS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 YiBjbGFzcz0iIj48aSBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBj bGFzcz0iIj5bTGVzOl0gTm90IHN1cmUgd2hhdCB5b3UgYXJlIHRyeWluZyB0byBzYXkuIElmIHRo ZSB0d28gU1JHQnMgYXJlIHRoZSBzYW1lIOKAkyB3aHkgZG8gd2UgbmVlZCB0byBjb25maWd1cmUg dGhlbSBwZXIgcHJvdG9jb2w/PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9pPjwvYj48L2Rp dj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YiBj bGFzcz0iIj48aSBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZh bWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFz cz0iIj5JZiB0aGUgdHdvIFNSR0JzIGFyZSBub3QgdGhlIHNhbWUsIG90aGVyIHJvdXRlcnMgaW4g dGhlIG5ldHdvcmsgaGF2ZSAmbmJzcDtubyBpZGVhIHdoaWNoIHByb3RvY29sIGlzIGdvaW5nIHRv IHdpbiBvbiB5b3VyIGJveC4gU28geW91ciBuZWlnaGJvcg0KIGhhcyBubyBpZGVhIHdoZXRoZXIg aXQgc2hvdWxkIHVzZSB0aGUgU1JHQiBhZHZlcnRpc2VkIGJ5IE9TUEYgb3IgdGhlIFNSR0IgYWR2 ZXJ0aXNlZCBieSBJUy1JUy48L3NwYW4+PC9pPjwvYj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4N CjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+QWN0dWFsbHksIGlmIHRo ZSBzYW1lIHByZWZpeCBpbiB0aGUgc2FtZSB0b3BvbG9neSBpcyBhZHZlcnRpc2VkIGJ5IHR3byBw cm90b2NvbHMsIEkgd291bGQgdGhpbmsgdGhhdCB0aGUgU0lEIHNob3VsZCBtYXAgdG8gdGhlIHNh bWUgbGFiZWwuIEkgc2VlIG5vIGFkdmFudGFnZSBhdCBhbGwgaW4gaGF2aW5nIHNlcGFyYXRlIGxh YmVscy4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvc3Bhbj4NCjxkaXY+ PGZvbnQgY29sb3I9IiMwMDAwZmYiPjxiPltQdXNocGFzaXNdIFdlIGFyZSB0YWxraW5nIGFib3V0 IHRoZSBNUExTIHRyYW5zaXQgbGFiZWwgZm9yIHRoZSBkZXN0aW5hdGlvbiBGRUMgaGVyZS4gTGlr ZSBSU1ZQIGFuZCBMRFAsIGluIE1QTFMgZGF0YSBwbGFuZSB0b2RheSwgdGhlIEZFQyBtYXliZSBz YW1lIGJ1dCB0aGUgdHJhbnNpdCBsYWJlbCBhbGxvY2F0ZWQgYnkgZWFjaCBwcm90b2NvbCBhcmUg ZGlmZmVyZW50LiBTaW1pbGFybHkgZm9yDQogU1IgbWFwcGVkIHRvIE1QTFMgZGF0YSBwbGFuZSB0 aGUgdHJhbnNpdCBsYWJlbCBhbGxvY2F0ZWQgYnkgSVNJUyBhbmQgT1NQRiBmb3IgdGhlIHNhbWUg ZGVzdGluYXRpb24gRkVDIHNob3VsZCBiZSBkaWZmZXJlbnQuIEhlbmNlIHRoZSBuZWVkIG9mIHBl ci1wcm90b2NvbCBTUkdCLjwvYj48L2ZvbnQ+PC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZ X1NFQ1RJT04iIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJr aXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXY+DQo8ZGl2 PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5BY2VlJm5ic3A7PC9kaXY+DQo8ZGl2PjxiciBj bGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0i Ij4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsgZm9udC1m YW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZv bnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzog bm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBz dGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNl OiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDsiPg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBub25lIG5vbmUg bm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IGJsdWU7IGJvcmRlci1sZWZ0LXdpZHRoOiAx LjVwdDsgcGFkZGluZzogMGluIDBpbiAwaW4gNHB0OyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIg Y2xhc3M9IiI+DQo8YiBjbGFzcz0iIj48aSBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwg NzMsIDEyNSk7IiBjbGFzcz0iIj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxi IGNsYXNzPSIiPjxpIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNs YXNzPSIiPiZuYnNwOzwvc3Bhbj48L2k+PC9iPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxpIGNsYXNzPSIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOyZuYnNwOyBMZXM8bzpw IGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEx cHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3Mywg MTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Jm5ic3A7 PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog QXJpYWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5DaGVlcnMsPG86cCBjbGFzcz0iIj48L286cD48 L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBB cmlhbCwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPlIuPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+ PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+ DQo8bzpwIGNsYXNzPSIiPiZuYnNwOzwvbzpwPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYg c3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQpPbiBXZWQsIEp1bCAy OSwgMjAxNSBhdCAxMTowMSBQTSwgTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgJmx0OzxhIGhyZWY9 Im1haWx0bzpnaW5zYmVyZ0BjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6 IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0iIj5naW5zYmVyZ0Bj aXNjby5jb208L2E+Jmd0OyB3cm90ZTo8bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIg Y2xhc3M9IiI+U3RlcGhhbmUg4oCTPC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8 ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5 bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjxvOnAg Y2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xh c3M9IiI+V2hhdCBpcyB0aGUgcmVxdWlyZW1lbnQgdG8gaGF2ZSBhIHBlci1wcm90b2NvbCBTUkdC IGNvbmZpZz88L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPuKAi+KAizxv OnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJn aW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KVGhpcyBtYWtlcyBubyBzZW5zZSB0byBt ZSBvcGVyYXRpb25hbGx5IG9yIGFyY2hpdGVjdHVyYWxseS48bzpwIGNsYXNzPSIiPjwvbzpwPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxz cGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bh bj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGlu IDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFu Jywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1 KTsiIGNsYXNzPSIiPihJIGFtIG5vdCB0YWxraW5nIGFib3V0IHdoYXQgbWF5IG9yIG1heSBub3Qg aGF2ZSBiZWVuIGltcGxlbWVudGVkIGJ5IHZlbmRvcnMg4oCTIHRoZSBZQU5HIG1vZGVsIHNob3Vs ZCBiZSBhcmNoaXRlY3R1cmFsbHkgY29ycmVjdCk8L3NwYW4+PG86cCBjbGFzcz0iIj48L286cD48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3Nw YW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEy NSk7IiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7TGVzPC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0K PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9z cGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5lICFpbXBvcnRhbnQ7IiBjbGFz cz0iIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bh bj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9u dC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1h bDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczog YXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3Jt OiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzog MHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyBmbG9hdDogbm9uZTsgZGlzcGxheTogaW5saW5l ICFpbXBvcnRhbnQ7IiBjbGFzcz0iIj5zcHJpbmcNCiBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyIHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6 IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdl YmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86 c3ByaW5nQGlldGYub3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1 bmRlcmxpbmU7IGZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1z dHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsg bGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0 bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5zcHJpbmdAaWV0Zi5v cmc8L2E+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7 IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBu b3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhh bnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNp bmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8YSBo cmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZyIgc3R5bGU9 ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyBmb250LWZhbWlseTog SGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJp YW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7 IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0 ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1h bDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13 aWR0aDogMHB4OyIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9zcHJpbmc8L2E+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6 IDEycHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2Vp Z2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7 IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3Jk LXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D1DFBF742CCC8psarkarjunipernet_-- From nobody Wed Jul 29 23:48:51 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD181A89F5 for ; Wed, 29 Jul 2015 23:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvggPPML3AX1 for ; Wed, 29 Jul 2015 23:48:44 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0776.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:776]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5487F1AC402 for ; Wed, 29 Jul 2015 23:48:43 -0700 (PDT) Received: from CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) by CO1PR05MB491.namprd05.prod.outlook.com (10.141.71.148) with Microsoft SMTP Server (TLS) id 15.1.225.19; Thu, 30 Jul 2015 06:48:23 +0000 Received: from BY1PR0501MB1381.namprd05.prod.outlook.com (10.160.107.139) by CO1PR05MB441.namprd05.prod.outlook.com (10.141.73.147) with Microsoft SMTP Server (TLS) id 15.1.219.17; Thu, 30 Jul 2015 06:48:21 +0000 Received: from BY1PR0501MB1381.namprd05.prod.outlook.com ([10.160.107.139]) by BY1PR0501MB1381.namprd05.prod.outlook.com ([10.160.107.139]) with mapi id 15.01.0225.018; Thu, 30 Jul 2015 06:48:22 +0000 From: Shraddha Hegde To: Pushpasis Sarkar , "Les Ginsberg (ginsberg)" , "stephane.litkowski@orange.com" , Uma Chunduri , "Aissaoui, Mustapha (Mustapha)" , "spring@ietf.org" , Hannes Gredler Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQyo8s/6cl3D63y0mUE8YS/iepyp3zi3qQ Date: Thu, 30 Jul 2015 06:48:21 +0000 Message-ID: References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none; x-originating-ip: [116.197.184.11] x-microsoft-exchange-diagnostics: 1; CO1PR05MB441; 5:Jh6uZmnYN2OOkyk9vGiB6ucZZKkNuqKKeGL/zdqs9Z2cyhArcc89dNZi3sPr2qA0MXee8W420tswmpUuXgyeRM3X0c98Hd0syGyLqZFtMSAG5cYbW2I1kkVvjlvdahlFugz5bieAt2Ur7a666lWDog==; 24:Usntvw1ihP+lh/tEeXtpAC88vRJ4ubnLc3BFq+JUUQer7RLDOWtv5xPKXCasSlZoKmLC1WixuiuDV83UD6Uc/t/c1E3B/RQWD5B+/Mh/f80=; 20:t51v6BCRefOw0k3B68LJ8lVV9HHeWi2eeFB9wwDQx6xwcDXMXA//aAf2sk1T0AHQvYIjJdxmY7z31cpz7FCMxA== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB441; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB491; co1pr05mb441: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:CO1PR05MB441; BCL:0; PCL:0; RULEID:; SRVR:CO1PR05MB441; x-forefront-prvs: 06530126A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(37854004)(377454003)(53754006)(5890100001)(92566002)(66066001)(93886004)(2900100001)(5001960100002)(2501003)(46102003)(230783001)(2656002)(62966003)(40100003)(122556002)(2950100001)(76576001)(87936001)(5003600100002)(77156002)(99286002)(50986999)(86362001)(54356999)(74316001)(189998001)(19625215002)(5002640100001)(77096005)(106116001)(102836002)(107886002)(76176999)(19609705001)(19580395003)(15975445007)(5001770100001)(33656002)(19580405001)(19300405004)(4001450100002)(16236675004); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB441; H:BY1PR0501MB1381.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB1381C70CC12BAFEA0CD4DBFED58B0BY1PR0501MB1381_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2015 06:48:21.9962 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR05MB441 X-Microsoft-Exchange-Diagnostics: 1; CO1PR05MB491; 2:glk/Mx4/+ZYIyGai3/dZAWENcwfNHZ4871+9Y24BpvHleh2WdHxzym2oSb45BoqjPMbIePfh1gfx9ta/CtRs6wMohpjPgkxif+BCVVD/VWR49/EcCjPtnTBrswbDSDO8dSFPPby4lUnBTtit3GyONpDJfkRatiHM5oWodaiNTLo=; 3:rsjMqfRySshl40BqDA046IKWK75K+RYzu6VB2l7kk34zPHGNUdr8NGK3jNjarHItsa57tuj7mQTqBH9oI9+p3JeJ5Yy4hE5knEdXnjrRfYQSk5kewfgqJRlHWpzBOw953QD/7BmZHTOwSMZLkGKkfQ==; 25:lXOsxWGluNtzourGFKJbDnjvaGoc7Rh9zb9fBEnGXpxVfhWX1wRYICQL98eyoQSLVJiLG7CWQJTP11LzgBzl8eZ3ZR+fLtAEEzMj827a6K3J/yvbvQT9PrWPXHtGHIVadpP43DV6QqlE7E5eZoC17rhu+dpNciDfxFuefCgOs8HtZ+w6FUDkoCQjXJlUFZFwpaoLEygNX2ktxtX0N+Rdy0s7XAE+JUmLfRPOsO29ikabeLwBMAh7YzM4uAWN989eYFNIetxbTqOeA6mo6qIuiQ==; 20:rFQ8ldyDXT9CYnLPF1XyCtU96Xs4NWC6L7UCE8Z5fNovJ6v7B3ETJAgSKMP6fq9VXcmYSK4Xa21azmdYUqlxCg==; 23:jOIluD1yB4sM4iq8Va7zwCmCwZYENqWqz3ZiFM6mCO9WF8d1LxCDYH66dOWKq4Bs18y7sWmmTUV15t5GUnWsCFhmp+dUi5qSWyHiJFMI25SJfevJQ8iwzwWFRW34JTlCpD/zypGmiIeZtOn0IPIPMWY3kL6kWGZpdMTuLjqfPBQmb57D9VreIIQFOPtrpBhcH9fibsf3uhKo+5OHbR5B5LuAhSeDW7/1JjquFDSvKHaJRfCMn+6GfQ5ltG9IOw12 CO1PR05MB491: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2015 06:48:49 -0000 --_000_BY1PR0501MB1381C70CC12BAFEA0CD4DBFED58B0BY1PR0501MB1381_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Les/Acee, I believe that it's useful to keep the labels separate for the protocols es= pecially for operational reasons. As Robert mentioned, protocol migrations is an important operational scenar= io to be considered. Protocol migrations are generally done using "ships in the night" model wh= ere both protocols are run with One protocol being preferred over the other. Migration exercises in the pas= t have shown that the two protocols Sometimes differ in their behavior due to inconsistencies in implementation= . I think operators should have a choice of "choosing separate SRGBs for prot= ocols" if they want to and support It in the YANG data model. Rgds Shraddha From: Pushpasis Sarkar Sent: Thursday, July 30, 2015 11:46 AM To: Les Ginsberg (ginsberg) ; stephane.litkowski@orange= .com; Uma Chunduri ; Aissaoui, Mustapha (Mustaph= a) ; spring@ietf.org; Shraddha Hegde = ; Hannes Gredler Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi Les, From: "Les Ginsberg (ginsberg)" > Date: Wednesday, July 29, 2015 at 11:01 PM To: "stephane.litkowski@orange.com" <= stephane.litkowski@orange.com>, Uma C= hunduri >, "Ais= saoui, Mustapha (Mustapha)" >, "spring@ietf.org" >, Shraddha Hegde >, Pushpasis Sarkar >, Hannes Gredler > Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Stephane - What is the requirement to have a per-protocol SRGB config? This makes no sense to me operationally or architecturally. [Pushpasis] In current MPLS architecture, the same label is not allocated b= y both RSVP and LDP in a given box. With SR mapped to MPLS data-plane, we w= ould like to retain the same behavior. For the same destination the label a= llocated by ISIS should be different than the label allocated by OSPF. This= can be achieved in two ways: 1. ISIS and OSPF using same SRGBs but different index ranges. 2. ISIS and OSPF using different SRGBs but can have the same index range= s. I prefer option 2, as the operator does not need to maintain two different = index ranges (one per-protocol). (I am not talking about what may or may not have been implemented by vendor= s - the YANG model should be architecturally correct) Les From: stephane.litkowski@orange.com [= mailto:stephane.litkowski@orange.com] Sent: Wednesday, July 29, 2015 5:11 AM To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); s= pring@ietf.org; Shraddha Hegde (shraddha@juniper.ne= t); Pushpasis Sarkar (psarkar@juniper.net); Hannes Gredler (hannes@juniper.net) Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi all, What if we keep the SRGB block config in "segment-routing" global module, a= nd if we allow for YANG configuration of carving this block inside each pro= tocol (maybe as a feature) ? Stephane From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] Sent: Friday, July 24, 2015 16:59 To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI Steph= ane SCE/IBNF; spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang >Suggesting that the forwarding instruction (AKA label) needs to be differ= ent depending on what protocol provided >the instruction is completely unnecessary - it simply wastes label space. [Uma]: Les, No - I never suggested anything like that. SRGB for a routing instance to be advertised should be part of the routing = instance provisioning as far as the yang model is concerned. Carving out the label space for SR is a local matter and agree, of course, = this can be done in so many ways through CLI, dynamically, statically etc.= .. -- Uma C. ___________________________________________________________________________= ______________________________________________ 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_BY1PR0501MB1381C70CC12BAFEA0CD4DBFED58B0BY1PR0501MB1381_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Les/Acee,

     

    I believe that it̵= 7;s useful to keep the labels separate for the protocols especially for ope= rational reasons.

    As Robert mentioned, p= rotocol migrations is an important operational scenario to be considered.

     

    Protocol migrations ar= e generally done using “ships in the night”  model where b= oth protocols are run with

    One protocol being pre= ferred over the other. Migration exercises in the past  have shown tha= t the two protocols

    Sometimes differ in th= eir behavior due to inconsistencies in implementation.

     

    I think operators shou= ld have a choice of “choosing separate SRGBs for protocols” if = they want to and support

    It in the YANG data mo= del.

     

    Rgds=

    Shraddha

     

     

     

    From: Pushpasis Sarkar
    Sent: Thursday, July 30, 2015 11:46 AM
    To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; stephane.lit= kowski@orange.com; Uma Chunduri <uma.chunduri@ericsson.com>; Aissaoui= , Mustapha (Mustapha) <mustapha.aissaoui@alcatel-lucent.com>; spring@= ietf.org; Shraddha Hegde <shraddha@juniper.net>; Hannes Gredler <hannes@juniper.net>
    Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

     

    Hi Les,=

    &n= bsp;

    From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
    Date: Wednesday, July 29, 2015 at 11:01 PM
    To: "stephane.= litkowski@orange.com" <stephane.litkowski@orange.com>, Uma Chunduri <uma.chunduri@ericsson.com>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com>, &= quot;spring@ietf.org" <spring@ietf.org>, Shraddha Hegde <shraddha@juniper.net>, = Pushpasis Sarkar <psarkar@juniper= .net>, Hannes Gredler <hann= es@juniper.net>
    Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

    &n= bsp;

    Stephane –

     

    What is the requiremen= t to have a per-protocol SRGB config?

    This makes no sense to= me operationally or architecturally.

    [Pushpa= sis] In current MPLS architecture, the same label is not allocated by both = RSVP and LDP in a given box. With SR mapped to MPLS data-plane, we would li= ke to retain the same behavior. For the same destination the label allocated by ISIS should be different than = the label allocated by OSPF. This can be achieved in two ways:

    1. ISIS and OSPF using same SRGBs but differe= nt index ranges.
    2. ISIS and OSPF using different SRGBs but ca= n have the same index ranges.

    I prefe= r option 2, as the operator does not need to maintain two different index r= anges (one per-protocol).

     

    (I am not talking abou= t what may or may not have been implemented by vendors – the YANG mod= el should be architecturally correct)

     

       Les

     

     

    From: stephane.litkowski@orange.= com [mailto:stephane.l= itkowski@orange.com]
    Sent: Wednesday, July 29, 2015 5:11 AM
    To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Musta= pha); spring@ietf.org; Shraddha Hegde (shraddha@juniper.net); Pushpasis Sarkar (psarkar@juniper.net); Hannes Gredler (hannes@juniper.net)
    Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

     =

    Hi all,

     

    What if we keep the SR= GB block config in “segment-routing” global module, and if we a= llow for YANG configuration of carving this block inside each protocol (may= be as a feature) ?

     

    Stephane

     

     

    From: Uma Chun= duri [mailto:uma.chunduri@eric= sson.com]
    Sent: Friday, July 24, 2015 16:59
    To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSK= I Stephane SCE/IBNF; spring@ietf.org
    Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

     =

    >Suggesting that the forwarding instruction (AKA label)  needs= to be different depending on what protocol provided

    >the instruction is completely unnecessary – it simply wastes= label space.

     

    [Uma]: Les, No - I nev= er suggested anything like that.

    SRGB for a routing ins= tance to be advertised should be part of the routing instance provisioning = as far as the yang model is concerned.

    Carving out the label = space for SR is a local matter and agree, of course, this  can be done= in so many ways through CLI, dynamically, statically etc...

     

    --

    Uma C.

     

    __________________________________________=
___________________________________________________________________________=
____
     
    Ce message et ses pieces jointes peuvent c=
ontenir des informations confidentielles ou privilegiees et ne doivent donc=

    pas etre diffuses, exploites ou copies san=
s autorisation. Si vous avez recu ce message par erreur, veuillez le signal=
er
    a l'expediteur et le detruire ainsi que le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n,
    Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
     
    This message and its attachments may conta=
in confidential or privileged information that may be protected by law;
    they should not be distributed, used or co=
pied without authorisation.
    If you have received this email in error, =
please notify the sender and delete this message and its attachments.<=
/o:p>
    As emails may be altered, Orange is not li=
able for messages that have been modified, changed or falsified.=

    Thank you.
    --_000_BY1PR0501MB1381C70CC12BAFEA0CD4DBFED58B0BY1PR0501MB1381_-- From nobody Wed Jul 29 23:58:10 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF6D51A1C04 for ; Wed, 29 Jul 2015 23:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9u4mTpPrWSTG for ; Wed, 29 Jul 2015 23:58:06 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0119.outbound.protection.outlook.com [65.55.169.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B14B71A1C03 for ; Wed, 29 Jul 2015 23:58:05 -0700 (PDT) Received: from BY1PR0501MB1381.namprd05.prod.outlook.com (10.160.107.139) by SN1PR05MB1983.namprd05.prod.outlook.com (10.162.132.25) with Microsoft SMTP Server (TLS) id 15.1.225.19; Thu, 30 Jul 2015 06:58:02 +0000 Received: from BY1PR0501MB1381.namprd05.prod.outlook.com ([10.160.107.139]) by BY1PR0501MB1381.namprd05.prod.outlook.com ([10.160.107.139]) with mapi id 15.01.0225.018; Thu, 30 Jul 2015 06:58:02 +0000 From: Shraddha Hegde To: "Les Ginsberg (ginsberg)" , Robert Raszuk Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQykfWBiljghy0+E6Ea6P3Va1HMZ3zB1kAgACLqAA= Date: Thu, 30 Jul 2015 06:58:02 +0000 Message-ID: References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-originating-ip: [116.197.184.11] x-microsoft-exchange-diagnostics: 1; SN1PR05MB1983; 5:BDfDkOXljYEe6u3kfULg7n3KypOcVN6O8QzwlEfvCl+dQwTLsJaLg7agXlywvsOkUpLa9rhzq3ZHcBcQO5RIBjis8qU8YiO8bHQ0tk/PutpAUT39sKHzAmzRmBQiGF00PDk0vfxcOt9scNmVfYIg9w==; 24:bjBsYcIyfWzDsyInuppv5jl90iRU6ox5rqp1QStkxrndBgAf1a53OBLg969tJiWL5jLqMTR1SIkwpCWtLNhdIfaKBrnAKYdW0vESLxgIasU=; 20:7u9N8BFtxlhovGDYq9Gm9Ff60yQGceRd/ArlqR9yUUio/+oAKjCoQCGSK7MfLmBFw8oXlcpr3H9L/JnbgEqfbA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR05MB1983; sn1pr05mb1983: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:SN1PR05MB1983; BCL:0; PCL:0; RULEID:; SRVR:SN1PR05MB1983; x-forefront-prvs: 06530126A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(57704003)(377454003)(76176999)(99286002)(19580405001)(189998001)(62966003)(92566002)(5001960100002)(107886002)(76576001)(86362001)(46102003)(5003600100002)(19609705001)(5001770100001)(5002640100001)(102836002)(106116001)(33656002)(77156002)(93886004)(87936001)(50986999)(19300405004)(16236675004)(74316001)(19625215002)(122556002)(40100003)(77096005)(15975445007)(2900100001)(66066001)(230783001)(2656002)(54356999)(2950100001)(19580395003)(4001430100001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR05MB1983; H:BY1PR0501MB1381.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB138122C99E3DDA8132088D3FD58B0BY1PR0501MB1381_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2015 06:58:02.4736 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR05MB1983 Archived-At: Cc: "stephane.litkowski@orange.com" , "spring@ietf.org" , Uma Chunduri , Pushpasis Sarkar , "Aissaoui, Mustapha \(Mustapha\)" , Hannes Gredler Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2015 06:58:09 -0000 --_000_BY1PR0501MB138122C99E3DDA8132088D3FD58B0BY1PR0501MB1381_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TGVzLA0KDQpQbHMgc2VlIGlubGluZeKApg0KDQpGcm9tOiBMZXMgR2luc2JlcmcgKGdpbnNiZXJn KSBbbWFpbHRvOmdpbnNiZXJnQGNpc2NvLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBKdWx5IDMwLCAy MDE1IDM6NTkgQU0NClRvOiBSb2JlcnQgUmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldD4NCkNjOiBz dGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTsgVW1hIENodW5kdXJpIDx1bWEuY2h1bmR1cmlA ZXJpY3Nzb24uY29tPjsgQWlzc2FvdWksIE11c3RhcGhhIChNdXN0YXBoYSkgPG11c3RhcGhhLmFp c3Nhb3VpQGFsY2F0ZWwtbHVjZW50LmNvbT47IHNwcmluZ0BpZXRmLm9yZzsgU2hyYWRkaGEgSGVn ZGUgPHNocmFkZGhhQGp1bmlwZXIubmV0PjsgUHVzaHBhc2lzIFNhcmthciA8cHNhcmthckBqdW5p cGVyLm5ldD47IEhhbm5lcyBHcmVkbGVyIDxoYW5uZXNAanVuaXBlci5uZXQ+DQpTdWJqZWN0OiBS RTogW3NwcmluZ10gTW9kZWxpbmcgU1JHQiBjb25maWd1cmF0aW9uIGZvciBkcmFmdC1pZXRmLXNw cmluZy1zci15YW5nDQoNClJvYmVydCAtDQoNCkZyb206IHJyYXN6dWtAZ21haWwuY29tPG1haWx0 bzpycmFzenVrQGdtYWlsLmNvbT4gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0gT24gQmVoYWxm IE9mIFJvYmVydCBSYXN6dWsNClNlbnQ6IFdlZG5lc2RheSwgSnVseSAyOSwgMjAxNSAyOjQ1IFBN DQpUbzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykNCkNjOiBzdGVwaGFuZS5saXRrb3dza2lAb3Jh bmdlLmNvbTxtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+OyBVbWEgQ2h1bmR1 cmk7IEFpc3Nhb3VpLCBNdXN0YXBoYSAoTXVzdGFwaGEpOyBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRv OnNwcmluZ0BpZXRmLm9yZz47IFNocmFkZGhhIEhlZ2RlIChzaHJhZGRoYUBqdW5pcGVyLm5ldDxt YWlsdG86c2hyYWRkaGFAanVuaXBlci5uZXQ+KTsgUHVzaHBhc2lzIFNhcmthciAocHNhcmthckBq dW5pcGVyLm5ldDxtYWlsdG86cHNhcmthckBqdW5pcGVyLm5ldD4pOyBIYW5uZXMgR3JlZGxlciAo aGFubmVzQGp1bmlwZXIubmV0PG1haWx0bzpoYW5uZXNAanVuaXBlci5uZXQ+KQ0KU3ViamVjdDog UmU6IFtzcHJpbmddIE1vZGVsaW5nIFNSR0IgY29uZmlndXJhdGlvbiBmb3IgZHJhZnQtaWV0Zi1z cHJpbmctc3IteWFuZw0KDQpIaSBMZXMsDQoNCj4g4oCLDQpUaGlzIG1ha2VzIG5vIHNlbnNlIHRv IG1lIG9wZXJhdGlvbmFsbHkgb3IgYXJjaGl0ZWN0dXJhbGx5Lg0KDQpGdW5kYW1lbnRhbGx5IEkg ZnVsbHkgYWdyZWUgd2l0aCB5b3UuDQoNCg0KSG93ZXZlciBhcmNoaXRlY3R1cmFsbHk6DQoNCkhv d2V2ZXIgYXQgbGVhc3QgbG9va2luZyBhdCBncm91cCBvZiBmb2xrcyB3aG8gY2xhaW0gdGhhdCBp dCBpcyBpbXBvc3NpYmxlIHRvIGdldCBzYW1lIFNSR0IgYmxvY2sgaW4gKmFueSogbmV0d29yayBi ZXR3ZWVuIHR3byBvciBtb3JlIHZlbmRvcnMgIEkgdGhpbmsgU3RlcGhhbmUncyBpbnRlbnRpb24g d291bGQgYmUgdG8gYXQgbGVhc3QgZ2V0IGl0IHBlciBvbmUgcHJvdG9jb2wgZXZlbiBpZiBwbGF0 Zm9ybSB3aWRlIHRoZSBpbnRlcnNlY3RpbmcgcG9vbCBtYXkgYmUgbWlzc2lvbiBpbXBvc3NpYmxl Lg0KDQpbTGVzOl0gVGhpcyBpcyBhbiB1bnJlbGF0ZWQgaXNzdWUuIFBsYWNpbmcgU1JHQiBpbiBn bG9iYWwgY29udGV4dCBkb2VzIG5vdCBtZWFuIGFsbCByb3V0ZXJzIGhhdmUgdG8gaGF2ZSB0aGUg c2FtZSBTUkdCLiBUaGVyZSBpcyBubyBjb250cm92ZXJzeSBoZXJlLg0KDQoNCmFuZCBub3cgb3Bl cmF0aW9uYWxseToNCg0KQW5vdGhlciByZWFzb24gd291bGQgYmUgaWRlYSBvZiBkdWFsIG92ZXJs YXBwaW5nIFNSR0JzIHBlcmhhcHMgcXVpdGUgdXNlZnVsIGR1cmluZyBtaWdyYXRpb25zIGJldHdl ZW4gcHJvdG9jb2xzIHdoZXJlIHRoZSBleGFjdCBzYW1lIFNSR0IgaXMgc2V0IG9uIGJvdGggdGhl biBqdXN0IGJhc2VkIG9uIGFkbWluIGRpc3RhbmNlIG9uZSB2cyB0aGUgb3RoZXIgcHJvdG9jb2wg aXMgY2hvc2VuLiBXaGlsZSBhIHN0YW5kYXJkIHByYWN0aWNlIGluIHByb3RvY29sIG1pZ3JhdGlv bnMgbm90IHN1cmUgaWYgYW55b25lIGxvb2tlZCBhdCB0aGF0IGZyb20gU1IgcGVyc3BlY3RpdmUu DQpbTGVzOl0gTm90IHN1cmUgd2hhdCB5b3UgYXJlIHRyeWluZyB0byBzYXkuIElmIHRoZSB0d28g U1JHQnMgYXJlIHRoZSBzYW1lIOKAkyB3aHkgZG8gd2UgbmVlZCB0byBjb25maWd1cmUgdGhlbSBw ZXIgcHJvdG9jb2w/DQpJZiB0aGUgdHdvIFNSR0JzIGFyZSBub3QgdGhlIHNhbWUsIG90aGVyIHJv dXRlcnMgaW4gdGhlIG5ldHdvcmsgaGF2ZSAgbm8gaWRlYSB3aGljaCBwcm90b2NvbCBpcyBnb2lu ZyB0byB3aW4gb24geW91ciBib3guIFNvIHlvdXIgbmVpZ2hib3IgaGFzIG5vIGlkZWEgd2hldGhl ciBpdCBzaG91bGQgdXNlIHRoZSBTUkdCIGFkdmVydGlzZWQgYnkgT1NQRiBvciB0aGUgU1JHQiBh ZHZlcnRpc2VkIGJ5IElTLUlTLg0KDQpbU2hyYWRkaGFdIHJvdXRlIHByZWZlcmVuY2UgaXMgbG9j YWwgdG8gcm91dGVyIGFuZCB0aGUgbmVpZ2hib3IgbmV2ZXIga25vd3Mgd2hhdCB0aGUgb3RoZXIg aXMgZ29pbmcgdG8gY2hvb3NlLiAgSWYgdGhlcmUgYXJlIGluY29uc2lzdGVuY2llcyBpbiB0d28g cHJvdG9jb2xzLCB0aGVyZSBhcmUgZ29pbmcgdG8gYmUgbG9vcHMgZXZlbiB3aGVuIHRoZXkgdXNl IHNhbWUgU1JHQi4gS2VlcGluZyBkaWZmZXJlbnQgbGFiZWxzIG1ha2VzIGl0IGVhc2llciB0byB0 cm91Ymxlc2hvb3QuDQoNCg0KICAgTGVzDQoNCg0KQ2hlZXJzLA0KUi4NCg0KDQpPbiBXZWQsIEp1 bCAyOSwgMjAxNSBhdCAxMTowMSBQTSwgTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgPGdpbnNiZXJn QGNpc2NvLmNvbTxtYWlsdG86Z2luc2JlcmdAY2lzY28uY29tPj4gd3JvdGU6DQpTdGVwaGFuZSDi gJMNCg0KV2hhdCBpcyB0aGUgcmVxdWlyZW1lbnQgdG8gaGF2ZSBhIHBlci1wcm90b2NvbCBTUkdC IGNvbmZpZz8NCuKAi+KAiw0KVGhpcyBtYWtlcyBubyBzZW5zZSB0byBtZSBvcGVyYXRpb25hbGx5 IG9yIGFyY2hpdGVjdHVyYWxseS4NCg0KKEkgYW0gbm90IHRhbGtpbmcgYWJvdXQgd2hhdCBtYXkg b3IgbWF5IG5vdCBoYXZlIGJlZW4gaW1wbGVtZW50ZWQgYnkgdmVuZG9ycyDigJMgdGhlIFlBTkcg bW9kZWwgc2hvdWxkIGJlIGFyY2hpdGVjdHVyYWxseSBjb3JyZWN0KQ0KDQogICBMZXMNCg0K --_000_BY1PR0501MB138122C99E3DDA8132088D3FD58B0BY1PR0501MB1381_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBp bjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkxlcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPlBscyBzZWUgaW5saW5l4oCmPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSBbbWFpbHRvOmdp bnNiZXJnQGNpc2NvLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVseSAzMCwg MjAxNSAzOjU5IEFNPGJyPg0KPGI+VG86PC9iPiBSb2JlcnQgUmFzenVrICZsdDtyb2JlcnRAcmFz enVrLm5ldCZndDs8YnI+DQo8Yj5DYzo8L2I+IHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29t OyBVbWEgQ2h1bmR1cmkgJmx0O3VtYS5jaHVuZHVyaUBlcmljc3Nvbi5jb20mZ3Q7OyBBaXNzYW91 aSwgTXVzdGFwaGEgKE11c3RhcGhhKSAmbHQ7bXVzdGFwaGEuYWlzc2FvdWlAYWxjYXRlbC1sdWNl bnQuY29tJmd0Ozsgc3ByaW5nQGlldGYub3JnOyBTaHJhZGRoYSBIZWdkZSAmbHQ7c2hyYWRkaGFA anVuaXBlci5uZXQmZ3Q7OyBQdXNocGFzaXMgU2Fya2FyICZsdDtwc2Fya2FyQGp1bmlwZXIubmV0 Jmd0OzsgSGFubmVzDQogR3JlZGxlciAmbHQ7aGFubmVzQGp1bmlwZXIubmV0Jmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiBSRTogW3NwcmluZ10gTW9kZWxpbmcgU1JHQiBjb25maWd1cmF0aW9uIGZv ciBkcmFmdC1pZXRmLXNwcmluZy1zci15YW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJvYmVydCAt PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fu cy1zZXJpZiI+DQo8YSBocmVmPSJtYWlsdG86cnJhc3p1a0BnbWFpbC5jb20iPnJyYXN6dWtAZ21h aWwuY29tPC9hPiBbPGEgaHJlZj0ibWFpbHRvOnJyYXN6dWtAZ21haWwuY29tIj5tYWlsdG86cnJh c3p1a0BnbWFpbC5jb208L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb2JlcnQgUmFzenVrPGJy Pg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgSnVseSAyOSwgMjAxNSAyOjQ1IFBNPGJyPg0KPGI+ VG86PC9iPiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKTxicj4NCjxiPkNjOjwvYj4gPGEgaHJlZj0i bWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIj5zdGVwaGFuZS5saXRrb3dza2lA b3JhbmdlLmNvbTwvYT47IFVtYSBDaHVuZHVyaTsgQWlzc2FvdWksIE11c3RhcGhhIChNdXN0YXBo YSk7DQo8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+ OyBTaHJhZGRoYSBIZWdkZSAoPGEgaHJlZj0ibWFpbHRvOnNocmFkZGhhQGp1bmlwZXIubmV0Ij5z aHJhZGRoYUBqdW5pcGVyLm5ldDwvYT4pOyBQdXNocGFzaXMgU2Fya2FyICg8YSBocmVmPSJtYWls dG86cHNhcmthckBqdW5pcGVyLm5ldCI+cHNhcmthckBqdW5pcGVyLm5ldDwvYT4pOyBIYW5uZXMg R3JlZGxlciAoPGEgaHJlZj0ibWFpbHRvOmhhbm5lc0BqdW5pcGVyLm5ldCI+aGFubmVzQGp1bmlw ZXIubmV0PC9hPik8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzcHJpbmddIE1vZGVsaW5nIFNS R0IgY29uZmlndXJhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFuZzxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkhpIExlcyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZndDsg4oCLPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGlzIG1ha2VzIG5v IHNlbnNlIHRvIG1lIG9wZXJhdGlvbmFsbHkgb3IgYXJjaGl0ZWN0dXJhbGx5Ljwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5GdW5kYW1lbnRhbGx5IEkgZnVsbHkgYWdyZWUgd2l0aCB5b3UuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+SG93 ZXZlciBhcmNoaXRlY3R1cmFsbHk6Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Ib3dldmVyIGF0IGxlYXN0IGxvb2tp bmcgYXQgZ3JvdXAgb2YgZm9sa3Mgd2hvIGNsYWltIHRoYXQgaXQgaXMgaW1wb3NzaWJsZSB0byBn ZXQgc2FtZSBTUkdCIGJsb2NrIGluICphbnkqIG5ldHdvcmsgYmV0d2VlbiB0d28gb3IgbW9yZSB2 ZW5kb3JzICZuYnNwO0kgdGhpbmsgU3RlcGhhbmUncyBpbnRlbnRpb24gd291bGQgYmUgdG8gYXQg bGVhc3QNCiBnZXQgaXQgcGVyIG9uZSBwcm90b2NvbCBldmVuIGlmIHBsYXRmb3JtIHdpZGUgdGhl IGludGVyc2VjdGluZyBwb29sIG1heSBiZSBtaXNzaW9uIGltcG9zc2libGUuJm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PltMZXM6XSBUaGlzIGlzIGFuIHVucmVsYXRlZCBpc3N1ZS4gUGxhY2luZyBTUkdCIGluIGdsb2Jh bCBjb250ZXh0IGRvZXMgbm90IG1lYW4gYWxsIHJvdXRlcnMgaGF2ZSB0byBoYXZlIHRoZSBzYW1l IFNSR0IuIFRoZXJlIGlzIG5vIGNvbnRyb3ZlcnN5IGhlcmUuPG86cD48L286cD48L3NwYW4+PC9p PjwvYj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm Ij5hbmQgbm93IG9wZXJhdGlvbmFsbHk6Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmIj5Bbm90aGVyIHJlYXNvbiB3b3Vs ZCBiZSBpZGVhIG9mIGR1YWwgb3ZlcmxhcHBpbmcgU1JHQnMgcGVyaGFwcyBxdWl0ZSB1c2VmdWwg ZHVyaW5nIG1pZ3JhdGlvbnMgYmV0d2VlbiBwcm90b2NvbHMgd2hlcmUgdGhlIGV4YWN0IHNhbWUg U1JHQiBpcyBzZXQgb24gYm90aCB0aGVuIGp1c3QgYmFzZWQgb24gYWRtaW4gZGlzdGFuY2Ugb25l DQogdnMgdGhlIG90aGVyIHByb3RvY29sIGlzIGNob3Nlbi4gV2hpbGUgYSBzdGFuZGFyZCBwcmFj dGljZSBpbiBwcm90b2NvbCBtaWdyYXRpb25zIG5vdCBzdXJlIGlmIGFueW9uZSBsb29rZWQgYXQg dGhhdCBmcm9tIFNSIHBlcnNwZWN0aXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bTGVzOl0g Tm90IHN1cmUgd2hhdCB5b3UgYXJlIHRyeWluZyB0byBzYXkuIElmIHRoZSB0d28gU1JHQnMgYXJl IHRoZSBzYW1lIOKAkyB3aHkgZG8gd2UgbmVlZCB0byBjb25maWd1cmUgdGhlbSBwZXIgcHJvdG9j b2w/PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SWYgdGhlIHR3byBTUkdCcyBhcmUg bm90IHRoZSBzYW1lLCBvdGhlciByb3V0ZXJzIGluIHRoZSBuZXR3b3JrIGhhdmUgJm5ic3A7bm8g aWRlYSB3aGljaCBwcm90b2NvbCBpcyBnb2luZyB0byB3aW4gb24geW91ciBib3guIFNvIHlvdXIg bmVpZ2hib3IgaGFzIG5vIGlkZWEgd2hldGhlcg0KIGl0IHNob3VsZCB1c2UgdGhlIFNSR0IgYWR2 ZXJ0aXNlZCBieSBPU1BGIG9yIHRoZSBTUkdCIGFkdmVydGlzZWQgYnkgSVMtSVMuPG86cD48L286 cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+W1NocmFkZGhhXSByb3V0ZSBwcmVmZXJlbmNlIGlzIGxvY2FsIHRvIHJvdXRlciBhbmQg dGhlIG5laWdoYm9yIG5ldmVyIGtub3dzIHdoYXQgdGhlIG90aGVyIGlzIGdvaW5nIHRvIGNob29z ZS4gJm5ic3A7SWYgdGhlcmUgYXJlIGluY29uc2lzdGVuY2llcyBpbiB0d28gcHJvdG9jb2xzLA0K IHRoZXJlIGFyZSBnb2luZyB0byBiZSBsb29wcyBldmVuIHdoZW4gdGhleSB1c2Ugc2FtZSBTUkdC LiBLZWVwaW5nIGRpZmZlcmVudCBsYWJlbHMgbWFrZXMgaXQgZWFzaWVyIHRvIHRyb3VibGVzaG9v dC48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjxvOnA+PC9vOnA+PC9z cGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PiZuYnNwOyZuYnNwOyBMZXM8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYi PkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZiI+Ui48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gV2VkLCBKdWwgMjksIDIwMTUgYXQgMTE6MDEgUE0sIExlcyBHaW5z YmVyZyAoZ2luc2JlcmcpICZsdDs8YSBocmVmPSJtYWlsdG86Z2luc2JlcmdAY2lzY28uY29tIiB0 YXJnZXQ9Il9ibGFuayI+Z2luc2JlcmdAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPlN0ZXBoYW5lIOKAkzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPldoYXQgaXMgdGhlIHJlcXVpcmVtZW50IHRvIGhhdmUgYSBwZXItcHJvdG9j b2wgU1JHQiBjb25maWc/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmIj7igIvigIs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoaXMgbWFrZXMgbm8gc2Vuc2UgdG8gbWUgb3BlcmF0aW9uYWxseSBvciBhcmNo aXRlY3R1cmFsbHkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4oSSBhbSBub3Qg dGFsa2luZyBhYm91dCB3aGF0IG1heSBvciBtYXkgbm90IGhhdmUgYmVlbiBpbXBsZW1lbnRlZCBi eSB2ZW5kb3JzIOKAkyB0aGUgWUFORyBtb2RlbCBzaG91bGQgYmUgYXJjaGl0ZWN0dXJhbGx5IGNv cnJlY3QpPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7ICZu YnNwO0xlczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_BY1PR0501MB138122C99E3DDA8132088D3FD58B0BY1PR0501MB1381_-- From nobody Thu Jul 30 00:11:11 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D19D1A7032 for ; Thu, 30 Jul 2015 00:11:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5g8hUeVqAkRv for ; Thu, 30 Jul 2015 00:11:09 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0144.outbound.protection.outlook.com [65.55.169.144]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE28A1A854C for ; Thu, 30 Jul 2015 00:11:08 -0700 (PDT) Received: from BLUPR05MB1969.namprd05.prod.outlook.com (10.162.224.23) by BLUPR05MB436.namprd05.prod.outlook.com (10.141.27.152) with Microsoft SMTP Server (TLS) id 15.1.219.17; Thu, 30 Jul 2015 07:11:05 +0000 Received: from BLUPR05MB1969.namprd05.prod.outlook.com ([10.162.224.23]) by BLUPR05MB1969.namprd05.prod.outlook.com ([10.162.224.23]) with mapi id 15.01.0225.018; Thu, 30 Jul 2015 07:11:06 +0000 From: Pushpasis Sarkar To: Shraddha Hegde , "Les Ginsberg (ginsberg)" , Robert Raszuk Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQypbmSziz8AEX80+9OKWs1l34VQ== Date: Thu, 30 Jul 2015 07:11:06 +0000 Message-ID: References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 authentication-results: juniper.net; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.184.14] x-microsoft-exchange-diagnostics: 1; BLUPR05MB436; 5:uHVpu2pxazc1qOWDCPIXa+s66jAJkYMgal00EPwUw0udkQ3FhDnQiNq2pEkLvRNPGhucKJNiEHKURhhF58DI0htr5n/6Pbh2funPK9DDf7tqXxqmNPtM37mpDWQmdNVHSnugLYOYOTIsi1WH5/mldg==; 24:XfHHV89S0SQio/FUQjmWPRIMlXtm243L5w/PET60bHOOVLSmOCs8gT9AZoLrj7L9P6vLGpI1krdkPjyWirAPYYuhqnztjKHENxUXLlPPctE=; 20:a6uKGXiDCfDMrUM5iNbqVWi5iMO4ocAT1i5WzLSwVdWS0k49PEuepG3s11XyOMa4SxvtqMGy0lUwd4GgFTSsLQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB436; blupr05mb436: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB436; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB436; x-forefront-prvs: 06530126A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(5001770100001)(77096005)(46102003)(66066001)(92566002)(122556002)(4001350100001)(102836002)(2900100001)(99286002)(36756003)(76176999)(16236675004)(19580405001)(50986999)(2950100001)(230783001)(19580395003)(83506001)(77156002)(106116001)(5001960100002)(189998001)(5002640100001)(107886002)(93886004)(62966003)(54356999)(86362001)(2656002)(40100003)(87936001)(4001430100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB436; H:BLUPR05MB1969.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D1DFCBD92CD0Bpsarkarjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2015 07:11:06.0742 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB436 Archived-At: Cc: "Aissaoui, Mustapha \(Mustapha\)" , "stephane.litkowski@orange.com" , "spring@ietf.org" , Uma Chunduri , Hannes Gredler Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2015 07:11:10 -0000 --_000_D1DFCBD92CD0Bpsarkarjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: Shraddha Hegde > Date: Thursday, July 30, 2015 at 8:58 AM To: "Les Ginsberg (ginsberg)" >, Robert Raszuk > Cc: "stephane.litkowski@orange.com" <= stephane.litkowski@orange.com>, Uma C= hunduri >, "Ais= saoui, Mustapha (Mustapha)" >, "spring@ietf.org" >, Pushpasis Sarkar >, Hannes Gredler > Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang [Shraddha] route preference is local to router and the neighbor never knows= what the other is going to choose. If there are inconsistencies in two pr= otocols, there are going to be loops even when they use same SRGB. Keeping = different labels makes it easier to troubleshoot. --_000_D1DFCBD92CD0Bpsarkarjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
    +1

    From: Shraddha Hegde <shraddha@juniper.net>
    Date: Thursday, July 30, 2015 at 8:= 58 AM
    To: "Les Ginsberg (ginsberg)&q= uot; <ginsberg@cisco.com>, = Robert Raszuk <robert@raszuk.net>
    Cc: "    stephane.litkowski@orange.com" <stephane.litkowski@orange.com= >, Uma Chunduri <uma.chu= nduri@ericsson.com>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com>, &= quot;spring@ietf.org" <spring@ietf.org>, Pushpasis Sarkar <psarkar@juniper.net>, Ha= nnes Gredler <hannes@juniper.net>
    Subject: RE: [spring] Modeling SRGB= configuration for draft-ietf-spring-sr-yang

     

    [Shraddha] route preference is local to router and t= he neighbor never knows what the other is going to choose.  If there a= re inconsistencies in two protocols, there are going to be loops even when they use same SRGB. Keeping different labe= ls makes it easier to troubleshoot.

            &nbs= p;           =

    --_000_D1DFCBD92CD0Bpsarkarjunipernet_-- From nobody Thu Jul 30 00:46:44 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6BAA1AD0CE for ; Thu, 30 Jul 2015 00:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BqV68vINkLg for ; Thu, 30 Jul 2015 00:46:38 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E80481AD0C8 for ; Thu, 30 Jul 2015 00:46:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24345; q=dns/txt; s=iport; t=1438242397; x=1439451997; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=ij6NcNDDQt+Pi6hDebcVmiRvzy2mRo7oWLwvxMjllmo=; b=F/b0OoON6zrA+E9zDGsbTPDgG4NSRG55/XP2ZO/RF/ptgFJzjnZRPn0v xJmg4LBnxPNTZ+OvLyo4UFtDVik6zOs8oCf12Bp6f49AZRPRIyY8q+ubF blacYGvN1wVwc+mSZCOOErtEnBSQw065jI4Bpgshn5b1FvgshnaTYJAJ6 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BpAwDO1blV/5FdJa1bgk1NVGkGvAwJh3wCgVE4FAEBAQEBAQGBCoQjAQEBBC0/ChMCAQgOAwECAQEBCxYHBzIUAwYIAgQBEgiIJs8nAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tOhCQRASAgFwEGgxKBFAWRdIMCAY4NhCCPboNkJmSDGW+BDjqBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,576,1432598400"; d="scan'208,217";a="173717968" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-6.cisco.com with ESMTP; 30 Jul 2015 07:46:36 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t6U7ka5p019917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jul 2015 07:46:36 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.220]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Thu, 30 Jul 2015 02:46:36 -0500 From: "Les Ginsberg (ginsberg)" To: Pushpasis Sarkar , "stephane.litkowski@orange.com" , Uma Chunduri , "Aissaoui, Mustapha (Mustapha)" , "spring@ietf.org" , Shraddha Hegde , Hannes Gredler Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQyo8uwFjCUSCsTUyfv7l+kq1Lap3zn+CQ Date: Thu, 30 Jul 2015 07:46:35 +0000 Message-ID: References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.136.106] Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F594A62E3xmbalnx02ciscoc_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2015 07:46:42 -0000 --_000_F3ADE4747C9E124B89F0ED2180CC814F594A62E3xmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Pushpassis - It is clear to me that what you propose is more complex to implement and mo= re costly in its consumption of labels. What I do not yet appreciate is wha= t capabilities protocol specific SRGBs provide which cannot be supported us= ing a protocol independent SRGB. Could you please provide some specific exa= mples? Please do not use an RSVP/LDP analogy - please use a proposed SR dep= loyment case. BTW, why do I say your proposal is more complex/costly? On a node where redistribution of routes is occurring, the source of redist= ribution (the "best route") obviously allocates a local label based on its = SRGB. But now the destination protocol for redistribution also has to alloc= ate a local label based on its SRGB because it is expected that neighbors o= f the destination protocol will use a label from the destination protocol S= RGB. So, you now have new requirements on the destination protocol and you = have consumed twice as many local labels. Your forwarding plane now has to = deal with the added complexity/cost - and your label manager has to manage = more label ranges. What I want to know is what do we gain for this added complexity? Thanx. Les From: Pushpasis Sarkar [mailto:psarkar@juniper.net] Sent: Wednesday, July 29, 2015 11:16 PM To: Les Ginsberg (ginsberg); stephane.litkowski@orange.com; Uma Chunduri; A= issaoui, Mustapha (Mustapha); spring@ietf.org; Shraddha Hegde; Hannes Gredl= er Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi Les, From: "Les Ginsberg (ginsberg)" > Date: Wednesday, July 29, 2015 at 11:01 PM To: "stephane.litkowski@orange.com" <= stephane.litkowski@orange.com>, Uma C= hunduri >, "Ais= saoui, Mustapha (Mustapha)" >, "spring@ietf.org" >, Shraddha Hegde >, Pushpasis Sarkar >, Hannes Gredler > Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Stephane - What is the requirement to have a per-protocol SRGB config? This makes no sense to me operationally or architecturally. [Pushpasis] In current MPLS architecture, the same label is not allocated b= y both RSVP and LDP in a given box. With SR mapped to MPLS data-plane, we w= ould like to retain the same behavior. For the same destination the label a= llocated by ISIS should be different than the label allocated by OSPF. This= can be achieved in two ways: 1. ISIS and OSPF using same SRGBs but different index ranges. 2. ISIS and OSPF using different SRGBs but can have the same index range= s. I prefer option 2, as the operator does not need to maintain two different = index ranges (one per-protocol). (I am not talking about what may or may not have been implemented by vendor= s - the YANG model should be architecturally correct) Les From: stephane.litkowski@orange.com [= mailto:stephane.litkowski@orange.com] Sent: Wednesday, July 29, 2015 5:11 AM To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); s= pring@ietf.org; Shraddha Hegde (shraddha@juniper.ne= t); Pushpasis Sarkar (psarkar@juniper.net); Hannes Gredler (hannes@juniper.net) Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi all, What if we keep the SRGB block config in "segment-routing" global module, a= nd if we allow for YANG configuration of carving this block inside each pro= tocol (maybe as a feature) ? Stephane From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] Sent: Friday, July 24, 2015 16:59 To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI Steph= ane SCE/IBNF; spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang >Suggesting that the forwarding instruction (AKA label) needs to be differ= ent depending on what protocol provided >the instruction is completely unnecessary - it simply wastes label space. [Uma]: Les, No - I never suggested anything like that. SRGB for a routing instance to be advertised should be part of the routing = instance provisioning as far as the yang model is concerned. Carving out the label space for SR is a local matter and agree, of course, = this can be done in so many ways through CLI, dynamically, statically etc.= .. -- Uma C. ___________________________________________________________________________= ______________________________________________ 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_F3ADE4747C9E124B89F0ED2180CC814F594A62E3xmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Pushpassis –

     

    It is clear to me that= what you propose is more complex to implement and more costly in its consu= mption of labels. What I do not yet appreciate is what capabilities protoco= l specific SRGBs provide which cannot be supported using a protocol independent SRGB. Could you please provide s= ome specific examples? Please do not use an RSVP/LDP analogy – please= use a proposed SR deployment case.

     

    BTW, why do I say your= proposal is more complex/costly?

     

    On a node where redist= ribution of routes is occurring, the source of redistribution (the “b= est route”) obviously allocates a local label based on its SRGB. But = now the destination protocol for redistribution also has to allocate a local label based on its SRGB because it is expecte= d that neighbors of the destination protocol will use a label from the dest= ination protocol SRGB. So, you now have new requirements on the destination= protocol and you have consumed twice as many local labels. Your forwarding plane now has to deal with the= added complexity/cost – and your label manager has to manage more la= bel ranges.

     

    What I want to know is= what do we gain for this added complexity? Thanx.

     

       Les<= /o:p>

     

     

    From: Pushpasi= s Sarkar [mailto:psarkar@juniper.net]
    Sent: Wednesday, July 29, 2015 11:16 PM
    To: Les Ginsberg (ginsberg); stephane.litkowski@orange.com; Uma Chun= duri; Aissaoui, Mustapha (Mustapha); spring@ietf.org; Shraddha Hegde; Hanne= s Gredler
    Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

     

    Hi Les,=

    &n= bsp;

    From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
    Date: Wednesday, July 29, 2015 at 11:01 PM
    To: "stephane.= litkowski@orange.com" <stephane.litkowski@orange.com>, Uma Chunduri <uma.chunduri@ericsson.com>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com>, &= quot;spring@ietf.org" <spring@ietf.org>, Shraddha Hegde <shraddha@juniper.net>, = Pushpasis Sarkar <psarkar@juniper= .net>, Hannes Gredler <hann= es@juniper.net>
    Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

    &n= bsp;

    Stephane –

     

    What is the requiremen= t to have a per-protocol SRGB config?

    This makes no sense to= me operationally or architecturally.

    [Pushpa= sis] In current MPLS architecture, the same label is not allocated by both = RSVP and LDP in a given box. With SR mapped to MPLS data-plane, we would li= ke to retain the same behavior. For the same destination the label allocated by ISIS should be different than = the label allocated by OSPF. This can be achieved in two ways:

    1. ISIS and OSPF using same SRGBs but differe= nt index ranges.
    2. ISIS and OSPF using different SRGBs but ca= n have the same index ranges.

    I prefe= r option 2, as the operator does not need to maintain two different index r= anges (one per-protocol).

     

    (I am not talking abou= t what may or may not have been implemented by vendors – the YANG mod= el should be architecturally correct)

     

       Les

     

     

    From: stephane.litkowski@orange.= com [mailto:stephane.l= itkowski@orange.com]
    Sent: Wednesday, July 29, 2015 5:11 AM
    To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Musta= pha); spring@ietf.org; Shraddha Hegde (shraddha@juniper.net); Pushpasis Sarkar (psarkar@juniper.net); Hannes Gredler (hannes@juniper.net)
    Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

     =

    Hi all,

     

    What if we keep the SR= GB block config in “segment-routing” global module, and if we a= llow for YANG configuration of carving this block inside each protocol (may= be as a feature) ?

     

    Stephane

     

     

    From: Uma Chunduri [= mailto:uma.chunduri@ericsson.com]
    Sent: Friday, July 24, 2015 16:59
    To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSK= I Stephane SCE/IBNF; spring@ietf.org
    Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

     =

    >Suggesting that the forwarding instruction (AKA label)  needs= to be different depending on what protocol provided

    >the instruction is completely unnecessary – it simply wastes= label space.

     

    [Uma]: Les, No - I nev= er suggested anything like that.

    SRGB for a routing ins= tance to be advertised should be part of the routing instance provisioning = as far as the yang model is concerned.

    Carving out the label = space for SR is a local matter and agree, of course, this  can be done= in so many ways through CLI, dynamically, statically etc...

     

    --

    Uma C.

     

    __________________________________________=
___________________________________________________________________________=
____
     
    Ce message et ses pieces jointes peuvent c=
ontenir des informations confidentielles ou privilegiees et ne doivent donc=

    pas etre diffuses, exploites ou copies san=
s autorisation. Si vous avez recu ce message par erreur, veuillez le signal=
er
    a l'expediteur et le detruire ainsi que le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n,
    Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
     
    This message and its attachments may conta=
in confidential or privileged information that may be protected by law;
    they should not be distributed, used or co=
pied without authorisation.
    If you have received this email in error, =
please notify the sender and delete this message and its attachments.<=
/o:p>
    As emails may be altered, Orange is not li=
able for messages that have been modified, changed or falsified.=

    Thank you.
    --_000_F3ADE4747C9E124B89F0ED2180CC814F594A62E3xmbalnx02ciscoc_-- From nobody Thu Jul 30 01:25:10 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75FC31B2CDC for ; Thu, 30 Jul 2015 01:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 IwL4db8IOB3F for ; Thu, 30 Jul 2015 01:25:05 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0731.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1A51B2CD7 for ; Thu, 30 Jul 2015 01:25:04 -0700 (PDT) Received: from BLUPR05MB435.namprd05.prod.outlook.com (10.141.27.150) by BLUPR05MB1953.namprd05.prod.outlook.com (10.162.224.19) with Microsoft SMTP Server (TLS) id 15.1.225.19; Thu, 30 Jul 2015 08:24:47 +0000 Received: from BLUPR05MB1969.namprd05.prod.outlook.com (10.162.224.23) by BLUPR05MB435.namprd05.prod.outlook.com (10.141.27.150) with Microsoft SMTP Server (TLS) id 15.1.219.17; Thu, 30 Jul 2015 08:24:47 +0000 Received: from BLUPR05MB1969.namprd05.prod.outlook.com ([10.162.224.23]) by BLUPR05MB1969.namprd05.prod.outlook.com ([10.162.224.23]) with mapi id 15.01.0225.018; Thu, 30 Jul 2015 08:24:45 +0000 From: Pushpasis Sarkar To: "Les Ginsberg (ginsberg)" , "stephane.litkowski@orange.com" , Uma Chunduri , "Aissaoui, Mustapha (Mustapha)" , "spring@ietf.org" , Shraddha Hegde , Hannes Gredler Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQyqExbj8WyH4o6Uyeq3ZwhFtplA== Date: Thu, 30 Jul 2015 08:24:45 +0000 Message-ID: References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.184.14] x-microsoft-exchange-diagnostics: 1; BLUPR05MB435; 5:jAKW7NFsuD2WL3twgCHm9D2JN+ym5qQT50zaQTEsWus9synWpVliiz/Iz+AOQlXap/kQaKttbGXkDwNVnTgabiGLd/A5RRicC3ZcHFmJzgRJFoLOupONGvuwKPBe/79SwVWAN3ddpY6SNYmq9i8ZXg==; 24:uy2g63BP5TKHUcYECbY5H+hJGtSXSAkLz/d/TcT+94A8s++zArSjULV0C8uOhnlFpZFx4HUe/xa95c2SkKTUT3mkg3QocaesxZojhMn0UYY=; 20:CbBhO85GGqPtHBTvilfw38aGiGRhOeWfu0+Z2RXtka+4xq+1Wuv1BFP3ZEKo/qe13QrJofKFtJQh1V+agL4bvw== x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB435; UriScan:; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1953; blupr05mb435: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB435; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB435; x-forefront-prvs: 06530126A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(53754006)(377454003)(37854004)(5002640100001)(19580405001)(5001960100002)(19300405004)(50986999)(2950100001)(66066001)(107886002)(19625215002)(19580395003)(86362001)(83506001)(92566002)(76176999)(561944003)(5890100001)(2501003)(87936001)(2900100001)(4001350100001)(16236675004)(5001770100001)(5001920100001)(189998001)(99286002)(4001450100002)(106116001)(2656002)(46102003)(230783001)(54356999)(77156002)(93886004)(15975445007)(62966003)(36756003)(40100003)(102836002)(77096005)(122556002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB435; H:BLUPR05MB1969.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D1DFD7B42CD1Dpsarkarjunipernet_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2015 08:24:45.6146 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB435 X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB1953; 2:mWQ/YpqPU7dQWth0cAL0RHGflJ/seL9zzewCrFOzWH2qQ07qZUDBL5RUWsH61LOr/FKlsqYXKxRWEMWZKzloW9hrt5g89PHq8IavAVF/Ahb4IuVi+j9yK2w9rw0DS8KRP7jp33A6M9KnGr5FRHMnDFp5NZHOgB4bJ8ajrMsnbEc=; 3:pu74Ico8v5Bfjbq1b4couDc7cccJwjf7fQq5Vlgz3Apabn5f0XPAoblF7FIagKq4SbaCfGvnSR6O6Fyi5slxLV7bXxMSpIg4vMXZ2RNLWURt7F+EkEg6kB4HBcGzi/ym98rWFjI7ZlFzl9iA3dhTbg==; 25:vCLE9ehiqmOFNX4Akgw9K9WHiNjvOfXsELkDTnJDFLLhpveEoc1JWjvjf6cvsrx0jrRBGnNy1fLPum+6aveNVqIKPpjlB9aLeOPorNIdcGEC/aniEll7KyNI30EKPP/nSKFOmob3iIAr8f44AZbi1xeokoiP33PQdi61jHDYR8L6XokOyWfobsCesO/Ija77pOotipo1yT6F5w7cHH9Vgm2eXE8CvahzSBdLHfBfiniYSY+MXPCXtngW9tF8AxHJBRwJQXEm8/dLMv8Uf0Sq4g==; 20:00vw31jh+SKHZ0anHbjPivYd/A8xPF1T6X/x6B2JQ3eqZ3PtOm77N9nLLDuPP4DCm7U6P+GJUHX0te+HAmGqTQ==; 23:V5wR7RE3NhtJU8UfLiNXy/7Z1f0ODO3EGNgUI7M8PsrsI4FkrraM0m7FA5wLPWYGrdw3vAQYH3aqxIFTyB4joyxsX/uUT3x+VCv6HKWqqAIFFnbzoZRygjCgeuDDXzsXd7S7IqaUB9zZeIu6HlMwyreRsUi4+yDLSD0lUfuGYqrol/zMjX21tWj4Cl9pn1hojMNri7+Xwufbo9S5U/hum8M9BwhnMlU3RqmatodMT2u3qGGZNYdnd2OPuQC6Qosv BLUPR05MB1953: X-MS-Exchange-Organization-RulesExecuted X-OriginatorOrg: juniper.net Archived-At: Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2015 08:25:08 -0000 --_000_D1DFD7B42CD1Dpsarkarjunipernet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Les, From: "Les Ginsberg (ginsberg)" > Date: Thursday, July 30, 2015 at 9:46 AM To: Pushpasis Sarkar >, "st= ephane.litkowski@orange.com" >, Uma Chunduri= >, "Aissaoui, = Mustapha (Mustapha)" >, "spring@ietf.org" >, Shraddha Hegde >, Hannes Gredler > Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Pushpassis =96 It is clear to me that what you propose is more complex to implement and mo= re costly in its consumption of labels. [Pushpasis] I read through the entire repsponse and I still don=92t see why= you think this is complex. Also, while distributing from one protocol to a= nother you may want to attach another index with the FEC (in scenarios when= you want to keep the index-management of destination protocol independent = of the index-management of soruce protocol). Having per-protcol SRGB opens = up lots of possibilities. One more point, you are only talking about the IP= -route on the ingress box. We need to also consider the MPLS transit labels= on transit boxes downloaded by each protocol. Shraddha in a previous threa= d has already pointed out cases with =91ships in the night=92 mode of migra= tion from one protocol to another where this simplifies the micgration with= out causing any unwanted loops. What I do not yet appreciate is what capabilities protocol specific SRGBs p= rovide which cannot be supported using a protocol independent SRGB. Could y= ou please provide some specific examples? Please do not use an RSVP/LDP ana= logy =96 please use a proposed SR deployment case. [Pushpasis] One such example (migration from one protocol to another) has a= lready been mentioned by Shraddha. But I can come with another example with= BGP-LU prefix segment in Datacenter. A boundary router (between DCN and th= e DCI) will be running SR on two protocols =97 BGP-LU towards the home DCN as well as to the boubdray routers on remot= e DCNs across the DCI =97 ISIS/OSPF with all the routers within the DCI. If we have to keep the index management of DCNs independent of the index-ma= nagement of DCI (I.e. Same index can be used on DCN as well as DCI) we need= to make sure the transit label allocated on the boundary router by BGP-LU = for a destination in DCN is separate from the transit label allocated by IS= IS/OSPF for another destination in DCI network, even though BGP-LU and ISIS= may use the same index for these two different destination routers. BTW, why do I say your proposal is more complex/costly? On a node where redistribution of routes is occurring, the source of redist= ribution (the =93best route=94) obviously allocates a local label based on = its SRGB. But now the destination protocol for redistribution also has to a= llocate a local label based on its SRGB because it is expected that neighbo= rs of the destination protocol will use a label from the destination protoc= ol SRGB. So, you now have new requirements on the destination protocol and = you have consumed twice as many local labels. Your forwarding plane now has= to deal with the added complexity/cost =96 and your label manager has to m= anage more label ranges. [Pushpasis] I still don=92t get what added complexity is involved here. How= does it matter if the label-manager has to manage 1 partition or N partiti= ons? The complexity involved is same. I agree that we will need added label= s, but if you see, we will need to enable SR on multiple protocols, only in= the following cases. I cannot foresee any other scenarios as of now. =97 Migrating from IGP1to IGP2. =97 Border routers in MSDC environment running BGP-LU + some IGP. What I want to know is what do we gain for this added complexity? Thanx. [Pushpasis] 1. Index-management in a one protocol can be completely independent of t= he index-mamagement in another protocol even if the same router participate= s in multiple protocols with different topologies. 2. Eases debuggability and avoids routing loops in case of migration sce= narios Thanks -Pushpasis Les From: Pushpasis Sarkar [mailto:psarkar@juniper.net] Sent: Wednesday, July 29, 2015 11:16 PM To: Les Ginsberg (ginsberg); stephane.litkowski@orange.com; Uma Chunduri; Aissaoui, Mustapha (Mustapha); spring@= ietf.org; Shraddha Hegde; Hannes Gredler Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi Les, From: "Les Ginsberg (ginsberg)" > Date: Wednesday, July 29, 2015 at 11:01 PM To: "stephane.litkowski@orange.com" <= stephane.litkowski@orange.com>, Uma C= hunduri >, "Ais= saoui, Mustapha (Mustapha)" >, "spring@ietf.org" >, Shraddha Hegde >, Pushpasis Sarkar >, Hannes Gredler > Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Stephane =96 What is the requirement to have a per-protocol SRGB config? This makes no sense to me operationally or architecturally. [Pushpasis] In current MPLS architecture, the same label is not allocated b= y both RSVP and LDP in a given box. With SR mapped to MPLS data-plane, we w= ould like to retain the same behavior. For the same destination the label a= llocated by ISIS should be different than the label allocated by OSPF. This= can be achieved in two ways: 1. ISIS and OSPF using same SRGBs but different index ranges. 2. ISIS and OSPF using different SRGBs but can have the same index range= s. I prefer option 2, as the operator does not need to maintain two different = index ranges (one per-protocol). (I am not talking about what may or may not have been implemented by vendor= s =96 the YANG model should be architecturally correct) Les From:stephane.litkowski@orange.com [m= ailto:stephane.litkowski@orange.com] Sent: Wednesday, July 29, 2015 5:11 AM To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); s= pring@ietf.org; Shraddha Hegde (shraddha@juniper.ne= t); Pushpasis Sarkar (psarkar@juniper.net); Hannes Gredler (hannes@juniper.net) Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi all, What if we keep the SRGB block config in =93segment-routing=94 global modul= e, and if we allow for YANG configuration of carving this block inside each= protocol (maybe as a feature) ? Stephane From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] Sent: Friday, July 24, 2015 16:59 To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI Steph= ane SCE/IBNF; spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang >Suggesting that the forwarding instruction (AKA label) needs to be differ= ent depending on what protocol provided >the instruction is completely unnecessary =96 it simply wastes label space= . [Uma]: Les, No - I never suggested anything like that. SRGB for a routing instance to be advertised should be part of the routing = instance provisioning as far as the yang model is concerned. Carving out the label space for SR is a local matter and agree, of course, = this can be done in so many ways through CLI, dynamically, statically etc.= .. -- Uma C. ___________________________________________________________________________= ______________________________________________ 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_D1DFD7B42CD1Dpsarkarjunipernet_ Content-Type: text/html; charset="Windows-1252" Content-ID: <64B7701821238348B8DAA3A4EDB4C41C@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
    Hi Les,

    From: "Les Ginsberg (ginsberg)= " <ginsberg@cisco.com>=
    Date: Thursday, July 30, 2015 at 9:= 46 AM
    To: Pushpasis Sarkar <psarkar@juniper.net>, "stephane.litkowski@orange.com&quo= t; <stephane.litkowski@= orange.com>, Uma Chunduri <uma.chunduri= @ericsson.com>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel= -lucent.com>, "spring@ietf.o= rg" <spring@ietf.org>, Shraddha H= egde <shraddha@juniper.net&g= t;, Hannes Gredler <hannes@juniper= .net>
    Subject: RE: [spring] Modeling SRGB= configuration for draft-ietf-spring-sr-yang

    Pushpassis =96

     

    It is clear to me that= what you propose is more complex to implement and more costly in its consu= mption of labels.

    [Pushpasis] I read through the entire repsponse and I still don=92t se= e why you think this is complex. Also, while distributing from one protocol= to another you may want to attach another index with the FEC (in scenarios= when you want to keep the index-management of destination protocol independent of the index-management of soruce prot= ocol). Having per-protcol SRGB opens up lots of possibilities. One more poi= nt, you are only talking about the IP-route on the ingress box. We need to = also consider the MPLS transit labels on transit boxes downloaded by each protocol. Shraddha in a previous threa= d has already pointed out cases with =91ships in the night=92 mode of migra= tion from one protocol to another where this simplifies the micgration with= out causing any unwanted loops. 

    What I do not yet appr= eciate is what capabilities protocol specific SRGBs provide which cannot be= supported using a protocol independent SRGB. Could you please provide some= specific examples? Please do not use an RSVP/LDP analogy =96 please use a proposed SR deployment case.

    [Pushpasis] One such example (migration from one protocol to another) = has already been mentioned by Shraddha. But I can come with another example= with BGP-LU prefix segment in Datacenter. A boundary router (between DCN a= nd the DCI) will be running SR on two protocols 
    =97 BGP-LU towards the home DCN as well as to the boubdray routers on = remote DCNs across the DCI
    =97 ISIS/OSPF with all the routers within the DCI.
    If we have to keep the index management of DCNs independent of the ind= ex-management of DCI (I.e. Same index can be used on DCN as well as DCI) we= need to make sure the transit label allocated on the boundary router by BG= P-LU for a destination in DCN is separate from the transit label allocated by ISIS/OSPF for another destina= tion in DCI network, even though BGP-LU and ISIS may use the same index for= these two different destination routers.

     

    BTW, why do I say your= proposal is more complex/costly?

     

    On a node where redist= ribution of routes is occurring, the source of redistribution (the =93best = route=94) obviously allocates a local label based on its SRGB. But now the = destination protocol for redistribution also has to allocate a local label based on its SRGB because it is expecte= d that neighbors of the destination protocol will use a label from the dest= ination protocol SRGB. So, you now have new requirements on the destination= protocol and you have consumed twice as many local labels. Your forwarding plane now has to deal with the= added complexity/cost =96 and your label manager has to manage more label = ranges.
    [Pushpasis] I still don=92t get what added complexity is involved here= . How does it matter if the label-manager has to manage 1 partition or N pa= rtitions? The complexity involved is same. I agree that we will need added = labels, but if you see, we will need to enable SR on multiple protocols, only in the following cases. I cannot = foresee any other scenarios as of now.
    =97 Migrating from IGP1to IGP2.
    =97 Border routers in MSDC environment running BGP-LU + some IGP.<= /div>

     

    What I want to know is= what do we gain for this added complexity? Thanx.
    [Pushpasis]
    1. Index-management in a one protocol can be completely independent of the= index-mamagement in another protocol even if the same router participates = in multiple protocols with different topologies.
    2. Eases debuggabilit= y and avoids routing loops in case of migration scenarios

    Thanks
    -Pushpasis


       Les<= /o:p>

     

     

    From: Pushpasis Sarkar [mailto:psarkar@juniper.net]
    Sent: Wednesday, July 29, 2015 11:16 PM
    To: Les Ginsberg (ginsberg); stephane.litkowski@orange.com; Uma Chunduri; Aissaoui, Mustapha (Mustap= ha); spring@ietf.org; Shraddha Hegde; Hannes Gredler
    Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

     

    Hi Les,=

    &n= bsp;

    From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
    Date: Wednesday, July 29, 2015 at 11:01 PM
    To: "stephane.= litkowski@orange.com" <stephane.litkowski@orange.com>, Uma Chunduri <uma.chunduri@ericsson.com>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com>, &= quot;spring@ietf.org" <spring@ietf.org>, Shraddha Hegde <shraddha@juniper.net>, = Pushpasis Sarkar <psarkar@juniper= .net>, Hannes Gredler <hann= es@juniper.net>
    Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

    &n= bsp;

    Stephane =96

     

    What is the requiremen= t to have a per-protocol SRGB config?

    This makes no sense to= me operationally or architecturally.

    [Pushpa= sis] In current MPLS architecture, the same label is not allocated by both = RSVP and LDP in a given box. With SR mapped to MPLS data-plane, we would li= ke to retain the same behavior. For the same destination the label allocated by ISIS should be different than = the label allocated by OSPF. This can be achieved in two ways:

    1. ISIS and OSPF using same SRGBs but differe= nt index ranges.
    2. ISIS and OSPF using different SRGBs but ca= n have the same index ranges.

    I prefe= r option 2, as the operator does not need to maintain two different index r= anges (one per-protocol).

     

    (I am not talking abou= t what may or may not have been implemented by vendors =96 the YANG model s= hould be architecturally correct)

     

       Les

     

     

    From:stephane.litkowski@orange.com [mailto:stephane.litkowsk= i@orange.com]
    Sent: Wednesday, July 29, 2015 5:11 AM
    To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Musta= pha); spring@ietf.org; Shraddha Hegde (shraddha@juniper.net); Pushpasis Sarkar (psarkar@juniper.net); Hannes Gredler (hannes@juniper.net)
    Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

     =

    Hi all,

     

    What if we keep the SR= GB block config in =93segment-routing=94 global module, and if we allow for= YANG configuration of carving this block inside each protocol (maybe as a = feature) ?

     

    Stephane

     

     

    From: Uma Chunduri [mailto:uma.chunduri@ericsson.com]
    Sent: Friday, July 24, 2015 16:59
    To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSK= I Stephane SCE/IBNF; spring@ietf.org
    Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

     =

    >Suggesting that the forwarding instruction (AKA label)  needs= to be different depending on what protocol provided

    >the instruction is completely unnecessary =96 it simply wastes lab= el space.

     

    [Uma]: Les, No - I nev= er suggested anything like that.

    SRGB for a routing ins= tance to be advertised should be part of the routing instance provisioning = as far as the yang model is concerned.

    Carving out the label = space for SR is a local matter and agree, of course, this  can be done= in so many ways through CLI, dynamically, statically etc...

     

    --

    Uma C.

     

    __________________________________________=
___________________________________________________________________________=
____
     
    Ce message et ses pieces jointes peuvent c=
ontenir des informations confidentielles ou privilegiees et ne doivent donc=

    pas etre diffuses, exploites ou copies san=
s autorisation. Si vous avez recu ce message par erreur, veuillez le signal=
er
    a l'expediteur et le detruire ainsi que le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n,
    Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
     
    This message and its attachments may conta=
in confidential or privileged information that may be protected by law;
    they should not be distributed, used or co=
pied without authorisation.
    If you have received this email in error, =
please notify the sender and delete this message and its attachments.<=
/o:p>
    As emails may be altered, Orange is not li=
able for messages that have been modified, changed or falsified.=

    Thank you.
     --_000_D1DFD7B42CD1Dpsarkarjunipernet_-- From nobody Thu Jul 30 02:05:02 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06DEF1B2D65 for ; Thu, 30 Jul 2015 02:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=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 1LkJF9TmMsv8 for ; Thu, 30 Jul 2015 02:04:53 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0777.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:777]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A0991B2D62 for ; Thu, 30 Jul 2015 02:04:53 -0700 (PDT) Received: from BY1PR0501MB1381.namprd05.prod.outlook.com (10.160.107.139) by BY2PR05MB1973.namprd05.prod.outlook.com (10.163.32.151) with Microsoft SMTP Server (TLS) id 15.1.225.19; Thu, 30 Jul 2015 09:04:31 +0000 Received: from BY1PR0501MB1381.namprd05.prod.outlook.com ([10.160.107.139]) by BY1PR0501MB1381.namprd05.prod.outlook.com ([10.160.107.139]) with mapi id 15.01.0225.018; Thu, 30 Jul 2015 09:04:31 +0000 From: Shraddha Hegde To: Pushpasis Sarkar , "Les Ginsberg (ginsberg)" , "stephane.litkowski@orange.com" , Uma Chunduri , "Aissaoui, Mustapha (Mustapha)" , "spring@ietf.org" , Hannes Gredler Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQyo8s/6cl3D63y0mUE8YS/iepyp3zopmAgAAKqoCAAAdmsA== Date: Thu, 30 Jul 2015 09:04:31 +0000 Message-ID: References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: juniper.net; dkim=none (message not signed) header.d=none; x-originating-ip: [116.197.184.12] x-microsoft-exchange-diagnostics: 1; BY2PR05MB1973; 5:tSK/O20Psd1ry2/1Vx0Y/Me2lECsww+ct70bx3QZY8NirhJ4/oLxG6FdVm9y/2nsBq7VZnpO155ZapGPt4BG4Wint4e0ImoIFizXMrIX3P/94nDHKmlhZDdgZ89+2obVfqoBKDbjASQr6IptObzk3Q==; 24:TwKm+7UD4WCNYgEcUmeVwb/LmncnPyX2HaSP5LvKSXqho7EPvmL+MwJk9oeFq4CkNpoCa52xah3Ev4S9q5MPi4DLLF2XYMPg4auvRzgrxdI=; 20:5jlWqluw8jxEljkTkjTNcELl0ZMZjWK4arlqUYGS0WygZLNCEoNBaw69zr+MhdJJzDYIKRebFW4XXeocmwVCVw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR05MB1973; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BY2PR05MB1973; BCL:0; PCL:0; RULEID:; SRVR:BY2PR05MB1973; x-forefront-prvs: 06530126A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(53754006)(37854004)(377454003)(74316001)(33656002)(77096005)(1941001)(561944003)(4001450100002)(5002640100001)(2900100001)(46102003)(15975445007)(19300405004)(2950100001)(76576001)(189998001)(102836002)(230783001)(19625215002)(93886004)(50986999)(107886002)(86362001)(87936001)(54356999)(99286002)(5001920100001)(5001960100002)(19580405001)(19580395003)(5001770100001)(106356001)(106116001)(77156002)(40100003)(2656002)(16236675004)(62966003)(92566002)(122556002)(5003600100002)(19609705001)(2501003)(5890100001)(66066001)(76176999)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR05MB1973; H:BY1PR0501MB1381.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; Content-Type: multipart/alternative; boundary="_000_BY1PR0501MB13810E1D4E9E42F7DEEAF0D5D58B0BY1PR0501MB1381_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2015 09:04:31.7305 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR05MB1973 Archived-At: Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2015 09:05:01 -0000 --_000_BY1PR0501MB13810E1D4E9E42F7DEEAF0D5D58B0BY1PR0501MB1381_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Les, The example that you gave about redistribution of routes from one protocol = to another could be result of two different organizations merging into one. These networks being managed by different entities in the past may have sam= e index assigned to nodes and different SRGBs configured in their respective domains. Operationally, it is easier to configure diffe= rent SRGBs to the two different protocols that they run than mess with Indexes and SRGBs in an attempt to get same SRGB across two protocols. I don't think there is anything wrong architecturally, to have separate lab= els for different protocols. I believe there should be flexibility and choice for operators to configure= the networks. If someone wants to deploy same SRGB for Different protocols or different SRGB for different protocols, the options = should be available and providing such an option in YANG model is well jus= tified. Rgds Shraddha From: Pushpasis Sarkar Sent: Thursday, July 30, 2015 1:55 PM To: Les Ginsberg (ginsberg) ; stephane.litkowski@orange= .com; Uma Chunduri ; Aissaoui, Mustapha (Mustaph= a) ; spring@ietf.org; Shraddha Hegde = ; Hannes Gredler Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi Les, From: "Les Ginsberg (ginsberg)" > Date: Thursday, July 30, 2015 at 9:46 AM To: Pushpasis Sarkar >, "st= ephane.litkowski@orange.com" >, Uma Chunduri= >, "Aissaoui, = Mustapha (Mustapha)" >, "spring@ietf.org" >, Shraddha Hegde >, Hannes Gredler > Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Pushpassis - It is clear to me that what you propose is more complex to implement and mo= re costly in its consumption of labels. [Pushpasis] I read through the entire repsponse and I still don't see why y= ou think this is complex. Also, while distributing from one protocol to ano= ther you may want to attach another index with the FEC (in scenarios when y= ou want to keep the index-management of destination protocol independent of= the index-management of soruce protocol). Having per-protcol SRGB opens up= lots of possibilities. One more point, you are only talking about the IP-r= oute on the ingress box. We need to also consider the MPLS transit labels o= n transit boxes downloaded by each protocol. Shraddha in a previous thread = has already pointed out cases with 'ships in the night' mode of migration f= rom one protocol to another where this simplifies the micgration without ca= using any unwanted loops. What I do not yet appreciate is what capabilities protocol specific SRGBs p= rovide which cannot be supported using a protocol independent SRGB. Could y= ou please provide some specific examples? Please do not use an RSVP/LDP ana= logy - please use a proposed SR deployment case. [Pushpasis] One such example (migration from one protocol to another) has a= lready been mentioned by Shraddha. But I can come with another example with= BGP-LU prefix segment in Datacenter. A boundary router (between DCN and th= e DCI) will be running SR on two protocols - BGP-LU towards the home DCN as well as to the boubdray routers on remote = DCNs across the DCI - ISIS/OSPF with all the routers within the DCI. If we have to keep the index management of DCNs independent of the index-ma= nagement of DCI (I.e. Same index can be used on DCN as well as DCI) we need= to make sure the transit label allocated on the boundary router by BGP-LU = for a destination in DCN is separate from the transit label allocated by IS= IS/OSPF for another destination in DCI network, even though BGP-LU and ISIS= may use the same index for these two different destination routers. BTW, why do I say your proposal is more complex/costly? On a node where redistribution of routes is occurring, the source of redist= ribution (the "best route") obviously allocates a local label based on its = SRGB. But now the destination protocol for redistribution also has to alloc= ate a local label based on its SRGB because it is expected that neighbors o= f the destination protocol will use a label from the destination protocol S= RGB. So, you now have new requirements on the destination protocol and you = have consumed twice as many local labels. Your forwarding plane now has to = deal with the added complexity/cost - and your label manager has to manage = more label ranges. [Pushpasis] I still don't get what added complexity is involved here. How d= oes it matter if the label-manager has to manage 1 partition or N partition= s? The complexity involved is same. I agree that we will need added labels,= but if you see, we will need to enable SR on multiple protocols, only in t= he following cases. I cannot foresee any other scenarios as of now. - Migrating from IGP1to IGP2. - Border routers in MSDC environment running BGP-LU + some IGP. What I want to know is what do we gain for this added complexity? Thanx. [Pushpasis] 1. Index-management in a one protocol can be completely independent of t= he index-mamagement in another protocol even if the same router participate= s in multiple protocols with different topologies. 2. Eases debuggability and avoids routing loops in case of migration sce= narios Thanks -Pushpasis Les From: Pushpasis Sarkar [mailto:psarkar@juniper.net] Sent: Wednesday, July 29, 2015 11:16 PM To: Les Ginsberg (ginsberg); stephane.litkowski@orange.com; Uma Chunduri; Aissaoui, Mustapha (Mustapha); spring@= ietf.org; Shraddha Hegde; Hannes Gredler Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi Les, From: "Les Ginsberg (ginsberg)" > Date: Wednesday, July 29, 2015 at 11:01 PM To: "stephane.litkowski@orange.com" <= stephane.litkowski@orange.com>, Uma C= hunduri >, "Ais= saoui, Mustapha (Mustapha)" >, "spring@ietf.org" >, Shraddha Hegde >, Pushpasis Sarkar >, Hannes Gredler > Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Stephane - What is the requirement to have a per-protocol SRGB config? This makes no sense to me operationally or architecturally. [Pushpasis] In current MPLS architecture, the same label is not allocated b= y both RSVP and LDP in a given box. With SR mapped to MPLS data-plane, we w= ould like to retain the same behavior. For the same destination the label a= llocated by ISIS should be different than the label allocated by OSPF. This= can be achieved in two ways: 1. ISIS and OSPF using same SRGBs but different index ranges. 2. ISIS and OSPF using different SRGBs but can have the same index range= s. I prefer option 2, as the operator does not need to maintain two different = index ranges (one per-protocol). (I am not talking about what may or may not have been implemented by vendor= s - the YANG model should be architecturally correct) Les From:stephane.litkowski@orange.com [m= ailto:stephane.litkowski@orange.com] Sent: Wednesday, July 29, 2015 5:11 AM To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); s= pring@ietf.org; Shraddha Hegde (shraddha@juniper.ne= t); Pushpasis Sarkar (psarkar@juniper.net); Hannes Gredler (hannes@juniper.net) Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi all, What if we keep the SRGB block config in "segment-routing" global module, a= nd if we allow for YANG configuration of carving this block inside each pro= tocol (maybe as a feature) ? Stephane From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] Sent: Friday, July 24, 2015 16:59 To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI Steph= ane SCE/IBNF; spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang >Suggesting that the forwarding instruction (AKA label) needs to be differ= ent depending on what protocol provided >the instruction is completely unnecessary - it simply wastes label space. [Uma]: Les, No - I never suggested anything like that. SRGB for a routing instance to be advertised should be part of the routing = instance provisioning as far as the yang model is concerned. Carving out the label space for SR is a local matter and agree, of course, = this can be done in so many ways through CLI, dynamically, statically etc.= .. -- Uma C. ___________________________________________________________________________= ______________________________________________ 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_BY1PR0501MB13810E1D4E9E42F7DEEAF0D5D58B0BY1PR0501MB1381_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Les,=

     

    The example that you g= ave about redistribution of routes from one protocol to another could be re= sult of two different organizations merging into one.

    These networks being m= anaged by different entities in the past may have same index assigned to no= des and different SRGBs configured

    in their respective do= mains. Operationally, it is easier to configure different SRGBs to the two = different protocols that they run than mess with

    Indexes and SRGBs in a= n attempt to get same SRGB across two protocols.

     

    I don’t think th= ere is anything wrong architecturally, to have separate labels for differen= t protocols.

    I believe there should= be flexibility and choice for operators to configure the networks. If some= one wants to deploy same SRGB for

    Different protocols or= different SRGB for different protocols, the options should be available&nb= sp; and providing such an option in YANG model is well justified.

     

    Rgds=

    Shraddha

     

     

    From: Pushpasis Sarkar
    Sent: Thursday, July 30, 2015 1:55 PM
    To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>; stephane.lit= kowski@orange.com; Uma Chunduri <uma.chunduri@ericsson.com>; Aissaoui= , Mustapha (Mustapha) <mustapha.aissaoui@alcatel-lucent.com>; spring@= ietf.org; Shraddha Hegde <shraddha@juniper.net>; Hannes Gredler <hannes@juniper.net>
    Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

     

    Hi Les,=

    &n= bsp;

    From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
    Date: Thursday, July 30, 2015 at 9:46 AM
    To: Pushpasis Sarkar <psar= kar@juniper.net>, "stephane.litkowski@orange.com" <stephane.litkowski@orange.com>, Uma Chunduri <uma.chunduri= @ericsson.com>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel= -lucent.com>, "spring@ietf.o= rg" <spring@ietf.org>, Shraddha H= egde <shraddha@juniper.net&g= t;, Hannes Gredler <hannes@juniper= .net>
    Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

    &n= bsp;

    Pushpassis –

     

    It is clear to me that= what you propose is more complex to implement and more costly in its consu= mption of labels.

    [Pushpa= sis] I read through the entire repsponse and I still don’t see why yo= u think this is complex. Also, while distributing from one protocol to anot= her you may want to attach another index with the FEC (in scenarios when you want to keep the index-management of destin= ation protocol independent of the index-management of soruce protocol). Hav= ing per-protcol SRGB opens up lots of possibilities. One more point, you ar= e only talking about the IP-route on the ingress box. We need to also consider the MPLS transit labels on tr= ansit boxes downloaded by each protocol. Shraddha in a previous thread has = already pointed out cases with ‘ships in the night’ mode of mig= ration from one protocol to another where this simplifies the micgration without causing any unwanted loops. 

    &n= bsp;

    What I do not yet appr= eciate is what capabilities protocol specific SRGBs provide which cannot be= supported using a protocol independent SRGB. Could you please provide some= specific examples? Please do not use an RSVP/LDP analogy – please use a proposed SR deployment case.

    [Pushpa= sis] One such example (migration from one protocol to another) has already = been mentioned by Shraddha. But I can come with another example with BGP-LU= prefix segment in Datacenter. A boundary router (between DCN and the DCI) will be running SR on two protocols =

    —= BGP-LU towards the home DCN as well as to the boubdray routers on remote D= CNs across the DCI

    —= ISIS/OSPF with all the routers within the DCI.

    If we h= ave to keep the index management of DCNs independent of the index-managemen= t of DCI (I.e. Same index can be used on DCN as well as DCI) we need to mak= e sure the transit label allocated on the boundary router by BGP-LU for a destination in DCN is separate from th= e transit label allocated by ISIS/OSPF for another destination in DCI netwo= rk, even though BGP-LU and ISIS may use the same index for these two differ= ent destination routers.

     

    BTW, why do I say your= proposal is more complex/costly?

     

    On a node where redist= ribution of routes is occurring, the source of redistribution (the “b= est route”) obviously allocates a local label based on its SRGB. But = now the destination protocol for redistribution also has to allocate a local label based on its SRGB because it is expecte= d that neighbors of the destination protocol will use a label from the dest= ination protocol SRGB. So, you now have new requirements on the destination= protocol and you have consumed twice as many local labels. Your forwarding plane now has to deal with the= added complexity/cost – and your label manager has to manage more la= bel ranges.

    [Pushpa= sis] I still don’t get what added complexity is involved here. How do= es it matter if the label-manager has to manage 1 partition or N partitions= ? The complexity involved is same. I agree that we will need added labels, but if you see, we will need to enable SR = on multiple protocols, only in the following cases. I cannot foresee any ot= her scenarios as of now.

    —= Migrating from IGP1to IGP2.

    —= Border routers in MSDC environment running BGP-LU + some IGP.

    &n= bsp;

     

    What I want to know is= what do we gain for this added complexity? Thanx.

    [Pushpa= sis]

    1. Index-management in a one protocol can be = completely independent of the index-mamagement in another protocol even if = the same router participates in multiple protocols with different topologie= s.
    2. Eases debuggability and avoids routing loo= ps in case of migration scenarios

    &n= bsp;

    Thanks<= o:p>

    -Pushpa= sis

     =

       Les

     

     

    From: Pushpasi= s Sarkar [mailto:psarkar@juniper.net= ]
    Sent: Wednesday, July 29, 2015 11:16 PM
    To: Les Ginsberg (ginsberg); stephane.litkowski@orange.com; Uma Chunduri; Aissaoui, Mustapha (Mustap= ha); spring@ietf.org; Shraddha Hegde; Hannes Gredler
    Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

     =

    Hi Les,=

     <= /span>

    From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
    Date: Wednesday, July 29, 2015 at 11:01 PM
    To: "stephane.= litkowski@orange.com" <stephane.litkowski@orange.com>, Uma Chunduri <uma.chunduri@ericsson.com>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com>, &= quot;spring@ietf.org" <spring@ietf.org>, Shraddha Hegde <shraddha@juniper.net>, = Pushpasis Sarkar <psarkar@juniper= .net>, Hannes Gredler <hann= es@juniper.net>
    Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

     <= /span>

    Stephane –

     

    What is the requiremen= t to have a per-protocol SRGB config?

    This makes no sense to= me operationally or architecturally.

    [Pushpa= sis] In current MPLS architecture, the same label is not allocated by both = RSVP and LDP in a given box. With SR mapped to MPLS data-plane, we would li= ke to retain the same behavior. For the same destination the label allocated by ISIS should be different than = the label allocated by OSPF. This can be achieved in two ways:

    1. ISIS and OSPF using same SRGBs but differe= nt index ranges.
    2. ISIS and OSPF using different SRGBs but ca= n have the same index ranges.

    I prefe= r option 2, as the operator does not need to maintain two different index r= anges (one per-protocol).

     

    (I am not talking abou= t what may or may not have been implemented by vendors – the YANG mod= el should be architecturally correct)

     

       Les

     

     

    From:stephane.litkowski@orange.com [mailto:stephane.litkowsk= i@orange.com]
    Sent: Wednesday, July 29, 2015 5:11 AM
    To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Musta= pha); spring@ietf.org; Shraddha Hegde (shraddha@juniper.net); Pushpasis Sarkar (psarkar@juniper.net); Hannes Gredler (hannes@juniper.net)
    Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

     =

    Hi all,

     

    What if we keep the SR= GB block config in “segment-routing” global module, and if we a= llow for YANG configuration of carving this block inside each protocol (may= be as a feature) ?

     

    Stephane

     

     

    From: Uma Chun= duri [mailto:uma.chunduri@eric= sson.com]
    Sent: Friday, July 24, 2015 16:59
    To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSK= I Stephane SCE/IBNF; spring@ietf.org
    Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

     =

    >Suggesting that the forwarding instruction (AKA label)  needs= to be different depending on what protocol provided

    >the instruction is completely unnecessary – it simply wastes= label space.

     

    [Uma]: Les, No - I nev= er suggested anything like that.

    SRGB for a routing ins= tance to be advertised should be part of the routing instance provisioning = as far as the yang model is concerned.

    Carving out the label = space for SR is a local matter and agree, of course, this  can be done= in so many ways through CLI, dynamically, statically etc...

     

    --

    Uma C.

     

    __________________________________________=
___________________________________________________________________________=
____
     
    Ce message et ses pieces jointes peuvent c=
ontenir des informations confidentielles ou privilegiees et ne doivent donc=

    pas etre diffuses, exploites ou copies san=
s autorisation. Si vous avez recu ce message par erreur, veuillez le signal=
er
    a l'expediteur et le detruire ainsi que le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n,
    Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
     
    This message and its attachments may conta=
in confidential or privileged information that may be protected by law;
    they should not be distributed, used or co=
pied without authorisation.
    If you have received this email in error, =
please notify the sender and delete this message and its attachments.<=
/o:p>
    As emails may be altered, Orange is not li=
able for messages that have been modified, changed or falsified.=

    Thank you.
    --_000_BY1PR0501MB13810E1D4E9E42F7DEEAF0D5D58B0BY1PR0501MB1381_-- From nobody Thu Jul 30 02:19:14 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CB961B2D97 for ; Thu, 30 Jul 2015 02:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 dX4-Skqq1dvS for ; Thu, 30 Jul 2015 02:19:02 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::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 EF5C61B2DA9 for ; Thu, 30 Jul 2015 02:18:54 -0700 (PDT) Received: by wibxm9 with SMTP id xm9so235594635wib.0 for ; Thu, 30 Jul 2015 02:18:53 -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:content-type; bh=DYNELXWn6y4QWkjIePmtjzG1AvBY9t9MIS51m5ZUfoU=; b=UZSZtXeRoPxzLiC3QxoVQ3WZ9sq9aoGosP9F7tUdUyhgHWnlz44l9pm9y0Ud5PVCzA 5hJvlqH1YSqTQOmINKm9ojPyPZWZQl+kKicohbU4e7JbNgXyizTmNQRbKSkBTxu+m6AL 5pPWVFyJfnPTDrwDOMi8IYfdGlRtd1im4uGg9lDLJSzPxWCp6ZLMWH/yJnZakxXzobMt s87bbxBe0/3ecEi4/NG5c/qeH9zBrYKWAJ3x43QuLAEZOSYZYYijipaJ73oglCxpCJAI MKc51Jc3CMcr0/dKBnU4vE808N+jcDDwW813f//Wc7VMYWHDjQhKKYBL2mn29kWUUCoB pipw== MIME-Version: 1.0 X-Received: by 10.181.13.195 with SMTP id fa3mr4365864wid.7.1438247933541; Thu, 30 Jul 2015 02:18:53 -0700 (PDT) Sender: rraszuk@gmail.com Received: by 10.194.95.168 with HTTP; Thu, 30 Jul 2015 02:18:53 -0700 (PDT) In-Reply-To: References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Date: Thu, 30 Jul 2015 11:18:53 +0200 X-Google-Sender-Auth: MzNLihnHo543z6I4SaiVH04Kcik Message-ID: From: Robert Raszuk To: "Les Ginsberg (ginsberg)" Content-Type: multipart/alternative; boundary=f46d043c07d42d85a8051c143164 Archived-At: Cc: "stephane.litkowski@orange.com" , "spring@ietf.org" , Hannes Gredler , Pushpasis Sarkar , Shraddha Hegde Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2015 09:19:05 -0000 --f46d043c07d42d85a8051c143164 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Les, One additional point ... Assume I am using a virtual router with BGP module from vendor A and OSPF module from vendor B. Assume the traditinal monolithic physical or virtual router is not being used. Who and where would implement this notion of "global SRGB concept" ? How would it talk to protocols ? Why do I need to pay now for this from perhaps yet one more vendor ? As long as I have SR control plane contained within protocols and have each of them feeding dataplane (directly or via RIB) I should be fine. So I am not sure why do I need yet one more umbrella SR coordinator subsystem .... Best, Robert. On Thu, Jul 30, 2015 at 9:46 AM, Les Ginsberg (ginsberg) wrote: > Pushpassis =E2=80=93 > > > > It is clear to me that what you propose is more complex to implement and > more costly in its consumption of labels. What I do not yet appreciate is > what capabilities protocol specific SRGBs provide which cannot be support= ed > using a protocol independent SRGB. Could you please provide some specific > examples? Please do not use an RSVP/LDP analogy =E2=80=93 please use a pr= oposed SR > deployment case. > > > > BTW, why do I say your proposal is more complex/costly? > > > > On a node where redistribution of routes is occurring, the source of > redistribution (the =E2=80=9Cbest route=E2=80=9D) obviously allocates a l= ocal label based > on its SRGB. But now the destination protocol for redistribution also has > to allocate a local label based on its SRGB because it is expected that > neighbors of the destination protocol will use a label from the destinati= on > protocol SRGB. So, you now have new requirements on the destination > protocol and you have consumed twice as many local labels. Your forwardin= g > plane now has to deal with the added complexity/cost =E2=80=93 and your l= abel > manager has to manage more label ranges. > > > > What I want to know is what do we gain for this added complexity? Thanx. > > > > Les > > > > > > *From:* Pushpasis Sarkar [mailto:psarkar@juniper.net] > *Sent:* Wednesday, July 29, 2015 11:16 PM > *To:* Les Ginsberg (ginsberg); stephane.litkowski@orange.com; Uma > Chunduri; Aissaoui, Mustapha (Mustapha); spring@ietf.org; Shraddha Hegde; > Hannes Gredler > *Subject:* Re: [spring] Modeling SRGB configuration for > draft-ietf-spring-sr-yang > > > > Hi Les, > > > > *From: *"Les Ginsberg (ginsberg)" > *Date: *Wednesday, July 29, 2015 at 11:01 PM > *To: *"stephane.litkowski@orange.com" , > Uma Chunduri , "Aissaoui, Mustapha (Mustapha)" > , "spring@ietf.org" , > Shraddha Hegde , Pushpasis Sarkar < > psarkar@juniper.net>, Hannes Gredler > *Subject: *RE: [spring] Modeling SRGB configuration for > draft-ietf-spring-sr-yang > > > > Stephane =E2=80=93 > > > > What is the requirement to have a per-protocol SRGB config? > > This makes no sense to me operationally or architecturally. > > [Pushpasis] In current MPLS architecture, the same label is not allocated > by both RSVP and LDP in a given box. With SR mapped to MPLS data-plane, w= e > would like to retain the same behavior. For the same destination the labe= l > allocated by ISIS should be different than the label allocated by OSPF. > This can be achieved in two ways: > > 1. ISIS and OSPF using same SRGBs but different index ranges. > 2. ISIS and OSPF using different SRGBs but can have the same index > ranges. > > I prefer option 2, as the operator does not need to maintain two > different index ranges (one per-protocol). > > > > (I am not talking about what may or may not have been implemented by > vendors =E2=80=93 the YANG model should be architecturally correct) > > > > Les > > > > > > *From:* stephane.litkowski@orange.com [ > mailto:stephane.litkowski@orange.com ] > *Sent:* Wednesday, July 29, 2015 5:11 AM > *To:* Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha > (Mustapha); spring@ietf.org; Shraddha Hegde (shraddha@juniper.net); > Pushpasis Sarkar (psarkar@juniper.net); Hannes Gredler (hannes@juniper.ne= t > ) > *Subject:* RE: [spring] Modeling SRGB configuration for > draft-ietf-spring-sr-yang > > > > Hi all, > > > > What if we keep the SRGB block config in =E2=80=9Csegment-routing=E2=80= =9D global module, > and if we allow for YANG configuration of carving this block inside each > protocol (maybe as a feature) ? > > > > Stephane > > > > > > *From:* Uma Chunduri [mailto:uma.chunduri@ericsson.com > ] > *Sent:* Friday, July 24, 2015 16:59 > *To:* Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI > Stephane SCE/IBNF; spring@ietf.org > *Subject:* RE: [spring] Modeling SRGB configuration for > draft-ietf-spring-sr-yang > > > > >Suggesting that the forwarding instruction (AKA label) needs to be > different depending on what protocol provided > > >the instruction is completely unnecessary =E2=80=93 it simply wastes lab= el space. > > > > [Uma]: Les, No - I never suggested anything like that. > > SRGB for a routing instance to be advertised should be part of the routin= g > instance provisioning as far as the yang model is concerned. > > Carving out the label space for SR is a local matter and agree, of course= , > this can be done in so many ways through CLI, dynamically, statically > etc... > > > > -- > > Uma C. > > > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles 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 o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation 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 bee= n modified, changed or falsified. > > Thank you. > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > > --f46d043c07d42d85a8051c143164 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
    Hi Les,

    One additional point ...

    =
    Assume I am using a virtual router with BGP module= from vendor A and OSPF module from vendor B. Assume the traditinal monolit= hic physical or virtual router is not being used.
    <= br>
    Who and where would implement this notion of &q= uot;global SRGB concept" ? How would it talk to protocols ? Why do I n= eed to pay now for this from perhaps yet one more vendor ?

    As long as I have SR control plane co= ntained within protocols and have each of them feeding dataplane (directly = or via RIB) I should be fine. So I am not sure why do I need yet one more u= mbrella SR coordinator subsystem ....

    Best,
    Robert.


    On T= hu, Jul 30, 2015 at 9:46 AM, Les Ginsberg (ginsberg) <= ginsberg@cisco.com<= /a>> wrote:

    Pushpassis =E2=80=93

    =C2=A0

    It is clear to me that= what you propose is more complex to implement and more costly in its consu= mption of labels. What I do not yet appreciate is what capabilities protoco= l specific SRGBs provide which cannot be supported using a protocol independent SRGB. Could you please provide s= ome specific examples? Please do not use an RSVP/LDP analogy =E2=80=93 plea= se use a proposed SR deployment case.

    =C2=A0

    BTW, why do I say your= proposal is more complex/costly?

    =C2=A0

    On a node where redist= ribution of routes is occurring, the source of redistribution (the =E2=80= =9Cbest route=E2=80=9D) obviously allocates a local label based on its SRGB= . But now the destination protocol for redistribution also has to allocate a local label based on its SRGB because it is expecte= d that neighbors of the destination protocol will use a label from the dest= ination protocol SRGB. So, you now have new requirements on the destination= protocol and you have consumed twice as many local labels. Your forwarding plane now has to deal with the= added complexity/cost =E2=80=93 and your label manager has to manage more = label ranges.

    =C2=A0

    What I want to know is= what do we gain for this added complexity? Thanx.

    =C2=A0

    =C2=A0=C2=A0 Les

    =C2=A0

    =C2=A0

    From: Pushpasi= s Sarkar [mailto:p= sarkar@juniper.net]
    Sent: Wednesday, July 29, 2015 11:16 PM
    To: Les Ginsberg (ginsberg); stephane.litkowski@orange.com; Uma Chunduri= ; Aissaoui, Mustapha (Mustapha); spring@ietf.org; Shraddha Hegde; Hannes Gredler
    Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

    =C2=A0

    Hi Les,=

    = =C2=A0

    From: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
    Date: Wednesday, July 29, 2015 at 11:01 PM
    To: "stephane.litkowski@orange.com" <stephane.litkowski@orange.com<= /a>>, Uma Chunduri <uma.chunduri@ericsson.com>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-luc= ent.com>, "spring@ietf.org" <spring@ietf.org>, Shraddha Hegde <shraddha@jun= iper.net>, Pushpasis Sarkar <psarkar@juniper.net>, Hannes Gredler <hannes@juniper.net>= ;
    Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

    = =C2=A0

    Stephane =E2=80=93

    =C2=A0

    What is the requiremen= t to have a per-protocol SRGB config?=

    This makes no sense to= me operationally or architecturally.=

    [Pushpa= sis] In current MPLS architecture, the same label is not allocated by both = RSVP and LDP in a given box. With SR mapped to MPLS data-plane, we would li= ke to retain the same behavior. For the same destination the label allocated by ISIS should be different than = the label allocated by OSPF. This can be achieved in two ways:

    1. ISIS and OSPF using same SRGBs but differe= nt index ranges.
    2. ISIS and OSPF using different SRGBs but ca= n have the same index ranges.

    I prefe= r option 2, as the operator does not need to maintain two different index r= anges (one per-protocol).

    =C2=A0

    (I am not talking abou= t what may or may not have been implemented by vendors =E2=80=93 the YANG m= odel should be architecturally correct)<= u>

    =C2=A0

    =C2=A0 =C2=A0Les

    =C2=A0

    =C2=A0

    From: stephane= .litkowski@orange.com [mailto:stephane.litkowski@orange.com]
    Sent: Wednesday, July 29, 2015 5:11 AM
    To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Musta= pha); spring@ietf.org; Shraddha Hegde (shraddha@juniper.net); Pushpasis Sarkar (psarkar@juniper.net); Ha= nnes Gredler (hanne= s@juniper.net)
    Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

    =C2=A0

    Hi all,

    =C2=A0

    What if we keep the SR= GB block config in =E2=80=9Csegment-routing=E2=80=9D global module, and if = we allow for YANG configuration of carving this block inside each protocol = (maybe as a feature) ?

    =C2=A0

    Stephane

    =C2=A0

    =C2=A0

    From: Uma Chunduri [mailto:uma.chunduri@ericsson.com]
    Sent: Friday, July 24, 2015 16:59
    To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSK= I Stephane SCE/IBNF; spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

    =C2=A0

    >Suggesting that the forwarding instruction (AKA label) =C2=A0needs= to be different depending on what protocol provided

    >the instruction is completely unnecessary =E2=80=93 it simply wast= es label space.

    =C2=A0

    [Uma]: Les, No - I nev= er suggested anything like that.

    SRGB for a routing ins= tance to be advertised should be part of the routing instance provisioning = as far as the yang model is concerned.

    Carving out the label = space for SR is a local matter and agree, of course, this =C2=A0can be done= in so many ways through CLI, dynamically, statically etc...

    =C2=A0

    --

    Uma C.

    =C2=A0

    __________________________________________=
___________________________________________________________________________=
____
    =C2=A0
    Ce message et ses pieces jointes peuvent c=
ontenir des informations confidentielles ou privilegiees et ne doivent donc=

    pas etre diffuses, exploites ou copies san=
s autorisation. Si vous avez recu ce message par erreur, veuillez le signal=
er
    a l'expediteur et le detruire ainsi qu=
e les pieces jointes. Les messages electroniques etant susceptibles d'a=
lteration,
    Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.

    =C2=A0
    

    This message and its attachments may conta=
in confidential or privileged information that may be protected by law;<=
/u>
    

    they should not be distributed, used or co=
pied 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 li=
able for messages that have been modified, changed or falsified.<=
/u>
    

    Thank you.

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


    --f46d043c07d42d85a8051c143164-- From nobody Thu Jul 30 06:17:05 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179501A1ADF for ; Thu, 30 Jul 2015 06:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AaYvsy3Ugy3Z for ; Thu, 30 Jul 2015 06:17:01 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 287451A1A9B for ; Thu, 30 Jul 2015 06:17:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=38016; q=dns/txt; s=iport; t=1438262221; x=1439471821; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=DbC4F5DlTNRcpdgfgsumnwljs9IrEwdOWLgU0YDTjJs=; b=Qn2zzkRcRPI8PPyj+iLbIyhrBsNNeCqIXKzmcK8wqmISN5MEa6ZBF0nQ qfiqezJgG6vdHGAYb4H+2U+t8tDErIK7ZC1gB8P6A7kjzL/3RvpQ+YGVs z6+Ll01mv/lL5KJ1i4TGFiQ1HixeDBAgmpsvAVqUASEb4r3A7wkvRBAfO 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BJBQAvI7pV/4MNJK1bgk1NVGkGgx24f4F5AQmFL0oCHIEbOhIBAQEBAQEBgQqEIwEBAQQBAQEgSwsQAgEGAg4DAwEBASEBBgMCAgIfBgsUCQgCBA4FHod7AxINm0qdGZBFDYUvAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLToJOgigNBAYBgmkvgRQFlHcBil2Ba4FHkEODS4NkJoIOHIFTb4FIgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,577,1432598400"; d="scan'208,217";a="173801535" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP; 30 Jul 2015 13:17:00 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t6UDH0sR013404 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jul 2015 13:17:00 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.37]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Thu, 30 Jul 2015 08:16:59 -0500 From: "Acee Lindem (acee)" To: Pushpasis Sarkar Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQypAXR/uKel9c+E+RzWpzpPRQt530UrmA Date: Thu, 30 Jul 2015 13:16:59 +0000 Message-ID: <5364D5F4-14CC-4B2C-B96D-9A9929E843A2@cisco.com> References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.204] Content-Type: multipart/alternative; boundary="_000_5364D5F414CC4B2CB96D9A9929E843A2ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Les Ginsberg \(ginsberg\)" , "spring@ietf.org" , Robert Raszuk , Stephane Litkowski , Shraddha Hegde , Uma Chunduri , "Aissaoui, Mustapha \(Mustapha\)" , Hannes Gredler Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2015 13:17:04 -0000 --_000_5364D5F414CC4B2CB96D9A9929E843A2ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUHVzaHBhc2lzLA0KDQpPbiBKdWwgMzAsIDIwMTUsIGF0IDI6MjIgQU0sIFB1c2hwYXNpcyBT YXJrYXIgPHBzYXJrYXJAanVuaXBlci5uZXQ8bWFpbHRvOnBzYXJrYXJAanVuaXBlci5uZXQ+PiB3 cm90ZToNCg0KSEkgQWNlZSwNCg0KRnJvbTogIkFjZWUgTGluZGVtIChhY2VlKSIgPGFjZWVAY2lz Y28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+DQpEYXRlOiBUaHVyc2RheSwgSnVseSAzMCwg MjAxNSBhdCAyOjAzIEFNDQpUbzogIkxlcyBHaW5zYmVyZyAoZ2luc2JlcmcpIiA8Z2luc2JlcmdA Y2lzY28uY29tPG1haWx0bzpnaW5zYmVyZ0BjaXNjby5jb20+Pg0KQ2M6IFJvYmVydCBSYXN6dWsg PHJvYmVydEByYXN6dWsubmV0PG1haWx0bzpyb2JlcnRAcmFzenVrLm5ldD4+LCBTdGVwaGFuZSBM aXRrb3dza2kgPHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPG1haWx0bzpzdGVwaGFuZS5s aXRrb3dza2lAb3JhbmdlLmNvbT4+LCAic3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0 Zi5vcmc+IiA8c3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+PiwgU2hyYWRk aGEgSGVnZGUgPHNocmFkZGhhQGp1bmlwZXIubmV0PG1haWx0bzpzaHJhZGRoYUBqdW5pcGVyLm5l dD4+LCBVbWEgQ2h1bmR1cmkgPHVtYS5jaHVuZHVyaUBlcmljc3Nvbi5jb208bWFpbHRvOnVtYS5j aHVuZHVyaUBlcmljc3Nvbi5jb20+PiwgUHVzaHBhc2lzIFNhcmthciA8cHNhcmthckBqdW5pcGVy Lm5ldDxtYWlsdG86cHNhcmthckBqdW5pcGVyLm5ldD4+LCAiQWlzc2FvdWksIE11c3RhcGhhIChN dXN0YXBoYSkiIDxtdXN0YXBoYS5haXNzYW91aUBhbGNhdGVsLWx1Y2VudC5jb208bWFpbHRvOm11 c3RhcGhhLmFpc3Nhb3VpQGFsY2F0ZWwtbHVjZW50LmNvbT4+LCBIYW5uZXMgR3JlZGxlciA8aGFu bmVzQGp1bmlwZXIubmV0PG1haWx0bzpoYW5uZXNAanVuaXBlci5uZXQ+Pg0KU3ViamVjdDogUmU6 IFtzcHJpbmddIE1vZGVsaW5nIFNSR0IgY29uZmlndXJhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zcHJp bmctc3IteWFuZw0KDQoNCk9uIEp1bCAyOSwgMjAxNSwgYXQgNjoyOCBQTSwgTGVzIEdpbnNiZXJn IChnaW5zYmVyZykgPGdpbnNiZXJnQGNpc2NvLmNvbTxtYWlsdG86Z2luc2JlcmdAY2lzY28uY29t Pj4gd3JvdGU6DQoNClJvYmVydCAtDQoNCkZyb206IHJyYXN6dWtAZ21haWwuY29tPG1haWx0bzpy cmFzenVrQGdtYWlsLmNvbT4gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0gT24gQmVoYWxmIE9m IFJvYmVydCBSYXN6dWsNClNlbnQ6IFdlZG5lc2RheSwgSnVseSAyOSwgMjAxNSAyOjQ1IFBNDQpU bzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykNCkNjOiBzdGVwaGFuZS5saXRrb3dza2lAb3Jhbmdl LmNvbTxtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+OyBVbWEgQ2h1bmR1cmk7 IEFpc3Nhb3VpLCBNdXN0YXBoYSAoTXVzdGFwaGEpOyBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNw cmluZ0BpZXRmLm9yZz47IFNocmFkZGhhIEhlZ2RlIChzaHJhZGRoYUBqdW5pcGVyLm5ldDxtYWls dG86c2hyYWRkaGFAanVuaXBlci5uZXQ+KTsgUHVzaHBhc2lzIFNhcmthciAocHNhcmthckBqdW5p cGVyLm5ldDxtYWlsdG86cHNhcmthckBqdW5pcGVyLm5ldD4pOyBIYW5uZXMgR3JlZGxlciAoaGFu bmVzQGp1bmlwZXIubmV0PG1haWx0bzpoYW5uZXNAanVuaXBlci5uZXQ+KQ0KU3ViamVjdDogUmU6 IFtzcHJpbmddIE1vZGVsaW5nIFNSR0IgY29uZmlndXJhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zcHJp bmctc3IteWFuZw0KDQpIaSBMZXMsDQoNCj4g4oCLDQpUaGlzIG1ha2VzIG5vIHNlbnNlIHRvIG1l IG9wZXJhdGlvbmFsbHkgb3IgYXJjaGl0ZWN0dXJhbGx5Lg0KDQpGdW5kYW1lbnRhbGx5IEkgZnVs bHkgYWdyZWUgd2l0aCB5b3UuDQoNCg0KSG93ZXZlciBhcmNoaXRlY3R1cmFsbHk6DQoNCkhvd2V2 ZXIgYXQgbGVhc3QgbG9va2luZyBhdCBncm91cCBvZiBmb2xrcyB3aG8gY2xhaW0gdGhhdCBpdCBp cyBpbXBvc3NpYmxlIHRvIGdldCBzYW1lIFNSR0IgYmxvY2sgaW4gKmFueSogbmV0d29yayBiZXR3 ZWVuIHR3byBvciBtb3JlIHZlbmRvcnMgIEkgdGhpbmsgU3RlcGhhbmUncyBpbnRlbnRpb24gd291 bGQgYmUgdG8gYXQgbGVhc3QgZ2V0IGl0IHBlciBvbmUgcHJvdG9jb2wgZXZlbiBpZiBwbGF0Zm9y bSB3aWRlIHRoZSBpbnRlcnNlY3RpbmcgcG9vbCBtYXkgYmUgbWlzc2lvbiBpbXBvc3NpYmxlLg0K DQpbTGVzOl0gVGhpcyBpcyBhbiB1bnJlbGF0ZWQgaXNzdWUuIFBsYWNpbmcgU1JHQiBpbiBnbG9i YWwgY29udGV4dCBkb2VzIG5vdCBtZWFuIGFsbCByb3V0ZXJzIGhhdmUgdG8gaGF2ZSB0aGUgc2Ft ZSBTUkdCLiBUaGVyZSBpcyBubyBjb250cm92ZXJzeSBoZXJlLg0KDQoNCmFuZCBub3cgb3BlcmF0 aW9uYWxseToNCg0KQW5vdGhlciByZWFzb24gd291bGQgYmUgaWRlYSBvZiBkdWFsIG92ZXJsYXBw aW5nIFNSR0JzIHBlcmhhcHMgcXVpdGUgdXNlZnVsIGR1cmluZyBtaWdyYXRpb25zIGJldHdlZW4g cHJvdG9jb2xzIHdoZXJlIHRoZSBleGFjdCBzYW1lIFNSR0IgaXMgc2V0IG9uIGJvdGggdGhlbiBq dXN0IGJhc2VkIG9uIGFkbWluIGRpc3RhbmNlIG9uZSB2cyB0aGUgb3RoZXIgcHJvdG9jb2wgaXMg Y2hvc2VuLiBXaGlsZSBhIHN0YW5kYXJkIHByYWN0aWNlIGluIHByb3RvY29sIG1pZ3JhdGlvbnMg bm90IHN1cmUgaWYgYW55b25lIGxvb2tlZCBhdCB0aGF0IGZyb20gU1IgcGVyc3BlY3RpdmUuDQpb TGVzOl0gTm90IHN1cmUgd2hhdCB5b3UgYXJlIHRyeWluZyB0byBzYXkuIElmIHRoZSB0d28gU1JH QnMgYXJlIHRoZSBzYW1lIOKAkyB3aHkgZG8gd2UgbmVlZCB0byBjb25maWd1cmUgdGhlbSBwZXIg cHJvdG9jb2w/DQpJZiB0aGUgdHdvIFNSR0JzIGFyZSBub3QgdGhlIHNhbWUsIG90aGVyIHJvdXRl cnMgaW4gdGhlIG5ldHdvcmsgaGF2ZSAgbm8gaWRlYSB3aGljaCBwcm90b2NvbCBpcyBnb2luZyB0 byB3aW4gb24geW91ciBib3guIFNvIHlvdXIgbmVpZ2hib3IgaGFzIG5vIGlkZWEgd2hldGhlciBp dCBzaG91bGQgdXNlIHRoZSBTUkdCIGFkdmVydGlzZWQgYnkgT1NQRiBvciB0aGUgU1JHQiBhZHZl cnRpc2VkIGJ5IElTLUlTLg0KDQoNCkFjdHVhbGx5LCBpZiB0aGUgc2FtZSBwcmVmaXggaW4gdGhl IHNhbWUgdG9wb2xvZ3kgaXMgYWR2ZXJ0aXNlZCBieSB0d28gcHJvdG9jb2xzLCBJIHdvdWxkIHRo aW5rIHRoYXQgdGhlIFNJRCBzaG91bGQgbWFwIHRvIHRoZSBzYW1lIGxhYmVsLiBJIHNlZSBubyBh ZHZhbnRhZ2UgYXQgYWxsIGluIGhhdmluZyBzZXBhcmF0ZSBsYWJlbHMuDQpbUHVzaHBhc2lzXSBX ZSBhcmUgdGFsa2luZyBhYm91dCB0aGUgTVBMUyB0cmFuc2l0IGxhYmVsIGZvciB0aGUgZGVzdGlu YXRpb24gRkVDIGhlcmUuIExpa2UgUlNWUCBhbmQgTERQLCBpbiBNUExTIGRhdGEgcGxhbmUgdG9k YXksIHRoZSBGRUMgbWF5YmUgc2FtZSBidXQgdGhlIHRyYW5zaXQgbGFiZWwgYWxsb2NhdGVkIGJ5 IGVhY2ggcHJvdG9jb2wgYXJlIGRpZmZlcmVudC4NCg0KVGhpcyBpcyBub3QgIGEgZ29vZCBhbmFs b2d5LiBMRFAgbm9ybWFsbHkgZm9sbG93cyB0aGUgSVAgcm91dGVkIHBhdGggd2hpbGUgUlNWUCBp cyB1c2VkIHRvIHNldCB1cCBhIFRFIGVuZ2luZWVyZWQgcGF0aC4NCg0KDQpTaW1pbGFybHkgZm9y IFNSIG1hcHBlZCB0byBNUExTIGRhdGEgcGxhbmUgdGhlIHRyYW5zaXQgbGFiZWwgYWxsb2NhdGVk IGJ5IElTSVMgYW5kIE9TUEYgZm9yIHRoZSBzYW1lIGRlc3RpbmF0aW9uIEZFQyBzaG91bGQgYmUg ZGlmZmVyZW50LiBIZW5jZSB0aGUgbmVlZCBvZiBwZXItcHJvdG9jb2wgU1JHQi4NCg0KVGhpcyBp cyBhIGNpcmN1bGFyIGFyZ3VtZW50LiBXaHkgd291bGQgdGhlIElQIHVuaWNhc3Qgcm91dGVkIHBh dGggcmVxdWlyZSBhIGRpZmZlcmVudCBsYWJlbCBmb3IgSVNJUyB2cyBPU1BGPw0KDQpBY2VlDQoN Cg0KDQoNCkFjZWUNCg0KDQoNCg0KICAgTGVzDQoNCg0KQ2hlZXJzLA0KUi4NCg0KDQpPbiBXZWQs IEp1bCAyOSwgMjAxNSBhdCAxMTowMSBQTSwgTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgPGdpbnNi ZXJnQGNpc2NvLmNvbTxtYWlsdG86Z2luc2JlcmdAY2lzY28uY29tPj4gd3JvdGU6DQpTdGVwaGFu ZSDigJMNCg0KV2hhdCBpcyB0aGUgcmVxdWlyZW1lbnQgdG8gaGF2ZSBhIHBlci1wcm90b2NvbCBT UkdCIGNvbmZpZz8NCuKAi+KAiw0KVGhpcyBtYWtlcyBubyBzZW5zZSB0byBtZSBvcGVyYXRpb25h bGx5IG9yIGFyY2hpdGVjdHVyYWxseS4NCg0KKEkgYW0gbm90IHRhbGtpbmcgYWJvdXQgd2hhdCBt YXkgb3IgbWF5IG5vdCBoYXZlIGJlZW4gaW1wbGVtZW50ZWQgYnkgdmVuZG9ycyDigJMgdGhlIFlB TkcgbW9kZWwgc2hvdWxkIGJlIGFyY2hpdGVjdHVyYWxseSBjb3JyZWN0KQ0KDQogICBMZXMNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBt YWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg0KDQo= --_000_5364D5F414CC4B2CB96D9A9929E843A2ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <41FFCEF6D7F8BB489D6398DF965C7479@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGkgUHVzaHBhc2lzLCZuYnNwOw0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEp1bCAzMCwgMjAxNSwgYXQgMjoyMiBBTSwg UHVzaHBhc2lzIFNhcmthciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBzYXJrYXJAanVuaXBlci5uZXQi IGNsYXNzPSIiPnBzYXJrYXJAanVuaXBlci5uZXQ8L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBj bGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBz dHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13 ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IGZvbnQtc2l6ZTogMTRweDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IiIg Y2xhc3M9IiI+SEkgQWNlZSw8L2Rpdj4NCjxkaXYgc3R5bGU9IiIgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSIiIGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmk7IGZvbnQtc2l6ZTogMTFw dDsgdGV4dC1hbGlnbjogbGVmdDsgYm9yZGVyLXdpZHRoOiAxcHQgbWVkaXVtIG1lZGl1bTsgYm9y ZGVyLXN0eWxlOiBzb2xpZCBub25lIG5vbmU7IHBhZGRpbmc6IDNwdCAwaW4gMGluOyBib3JkZXIt dG9wLWNvbG9yOiByZ2IoMTgxLCAxOTYsIDIyMyk7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIiBjbGFzcz0iIj5Gcm9tOiA8L3NwYW4+JnF1b3Q7QWNlZSBMaW5kZW0g KGFjZWUpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20iIGNsYXNzPSIi PmFjZWVAY2lzY28uY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCIgY2xhc3M9IiI+RGF0ZTogPC9zcGFuPlRodXJzZGF5LCBKdWx5IDMwLCAyMDE1 IGF0IDI6MDMgQU08YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCIg Y2xhc3M9IiI+VG86IDwvc3Bhbj4mcXVvdDtMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmdpbnNiZXJnQGNpc2NvLmNvbSIgY2xhc3M9IiI+Z2luc2JlcmdA Y2lzY28uY29tPC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6 Ym9sZCIgY2xhc3M9IiI+Q2M6IDwvc3Bhbj5Sb2JlcnQgUmFzenVrICZsdDs8YSBocmVmPSJtYWls dG86cm9iZXJ0QHJhc3p1ay5uZXQiIGNsYXNzPSIiPnJvYmVydEByYXN6dWsubmV0PC9hPiZndDss IFN0ZXBoYW5lIExpdGtvd3NraSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3Nr aUBvcmFuZ2UuY29tIiBjbGFzcz0iIj5zdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTwvYT4m Z3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiBjbGFzcz0iIj5zcHJp bmdAaWV0Zi5vcmc8L2E+JnF1b3Q7DQogJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5v cmciIGNsYXNzPSIiPnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7LCBTaHJhZGRoYSBIZWdkZSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnNocmFkZGhhQGp1bmlwZXIubmV0IiBjbGFzcz0iIj5zaHJhZGRoYUBq dW5pcGVyLm5ldDwvYT4mZ3Q7LCBVbWEgQ2h1bmR1cmkgJmx0OzxhIGhyZWY9Im1haWx0bzp1bWEu Y2h1bmR1cmlAZXJpY3Nzb24uY29tIiBjbGFzcz0iIj51bWEuY2h1bmR1cmlAZXJpY3Nzb24uY29t PC9hPiZndDssIFB1c2hwYXNpcw0KIFNhcmthciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBzYXJrYXJA anVuaXBlci5uZXQiIGNsYXNzPSIiPnBzYXJrYXJAanVuaXBlci5uZXQ8L2E+Jmd0OywgJnF1b3Q7 QWlzc2FvdWksIE11c3RhcGhhIChNdXN0YXBoYSkmcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpt dXN0YXBoYS5haXNzYW91aUBhbGNhdGVsLWx1Y2VudC5jb20iIGNsYXNzPSIiPm11c3RhcGhhLmFp c3Nhb3VpQGFsY2F0ZWwtbHVjZW50LmNvbTwvYT4mZ3Q7LCBIYW5uZXMgR3JlZGxlciAmbHQ7PGEg aHJlZj0ibWFpbHRvOmhhbm5lc0BqdW5pcGVyLm5ldCIgY2xhc3M9IiI+aGFubmVzQGp1bmlwZXIu bmV0PC9hPiZndDs8YnIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCIg Y2xhc3M9IiI+U3ViamVjdDogPC9zcGFuPlJlOiBbc3ByaW5nXSBNb2RlbGluZyBTUkdCIGNvbmZp Z3VyYXRpb24gZm9yIGRyYWZ0LWlldGYtc3ByaW5nLXNyLXlhbmc8YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0K PGRpdiBzdHlsZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3Bh Y2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxi ciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFz cz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gSnVsIDI5LCAyMDE1LCBhdCA2OjI4IFBNLCBMZXMgR2lu c2JlcmcgKGdpbnNiZXJnKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmdpbnNiZXJnQGNpc2NvLmNvbSIg Y2xhc3M9IiI+Z2luc2JlcmdAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xh c3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsgZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFz cz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPlJvYmVydCAt PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUp OyIgY2xhc3M9IiI+Jm5ic3A7PC9zcGFuPjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxl OiBub25lIG5vbmUgbm9uZSBzb2xpZDsgYm9yZGVyLWxlZnQtY29sb3I6IGJsdWU7IGJvcmRlci1s ZWZ0LXdpZHRoOiAxLjVwdDsgcGFkZGluZzogMGluIDBpbiAwaW4gNHB0OyIgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iYm9yZGVyLXN0eWxlOiBzb2xpZCBub25lIG5vbmU7 IGJvcmRlci10b3AtY29sb3I6IHJnYigxODEsIDE5NiwgMjIzKTsgYm9yZGVyLXRvcC13aWR0aDog MXB0OyBwYWRkaW5nOiAzcHQgMGluIDBpbjsiIGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7IiBjbGFzcz0i Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1p bHk6IFRhaG9tYSwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252 ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86cnJhc3p1a0BnbWFpbC5j b20iIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGNs YXNzPSIiPnJyYXN6dWtAZ21haWwuY29tPC9hPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5bPGEgaHJlZj0ibWFpbHRvOnJyYXN6dWtAZ21haWwuY29tIiBz dHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0i Ij5tYWlsdG86cnJhc3p1a0BnbWFpbC5jb208L2E+XTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YiBjbGFzcz0iIj5Pbg0KIEJlaGFsZiBPZjxzcGFuIGNs YXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+Um9iZXJ0IFJhc3p1 azxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5XZWRuZXNkYXksIEp1bHkgMjksIDIwMTUgMjo0 NSBQTTxiciBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPlRvOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+TGVzIEdpbnNiZXJnIChnaW5zYmVyZyk8YnIg Y2xhc3M9IiI+DQo8YiBjbGFzcz0iIj5DYzo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lA b3JhbmdlLmNvbSIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJs aW5lOyIgY2xhc3M9IiI+c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208L2E+OyBVbWEgQ2h1 bmR1cmk7IEFpc3Nhb3VpLCBNdXN0YXBoYSAoTXVzdGFwaGEpOzxzcGFuIGNsYXNzPSJBcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYu b3JnIiBzdHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBj bGFzcz0iIj5zcHJpbmdAaWV0Zi5vcmc8L2E+Ow0KIFNocmFkZGhhIEhlZ2RlICg8YSBocmVmPSJt YWlsdG86c2hyYWRkaGFAanVuaXBlci5uZXQiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRl Y29yYXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPnNocmFkZGhhQGp1bmlwZXIubmV0PC9hPik7 IFB1c2hwYXNpcyBTYXJrYXIgKDxhIGhyZWY9Im1haWx0bzpwc2Fya2FyQGp1bmlwZXIubmV0IiBz dHlsZT0iY29sb3I6IHB1cnBsZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBjbGFzcz0i Ij5wc2Fya2FyQGp1bmlwZXIubmV0PC9hPik7DQogSGFubmVzIEdyZWRsZXIgKDxhIGhyZWY9Im1h aWx0bzpoYW5uZXNAanVuaXBlci5uZXQiIHN0eWxlPSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29y YXRpb246IHVuZGVybGluZTsiIGNsYXNzPSIiPmhhbm5lc0BqdW5pcGVyLm5ldDwvYT4pPGJyIGNs YXNzPSIiPg0KPGIgY2xhc3M9IiI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJlOiBbc3ByaW5nXSBNb2RlbGluZyBTUkdCIGNvbmZp Z3VyYXRpb24gZm9yIGRyYWZ0LWlldGYtc3ByaW5nLXNyLXlhbmc8bzpwIGNsYXNzPSIiPjwvbzpw Pjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWws IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5IaSBMZXMsPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+ PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwg c2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1z ZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mZ3Q7IOKAizxvOnAgY2xh c3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBp biAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcg Um9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlh bCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj5UaGlzIG1h a2VzIG5vIHNlbnNlIHRvIG1lIG9wZXJhdGlvbmFsbHkgb3IgYXJjaGl0ZWN0dXJhbGx5Ljwvc3Bh bj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+ PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4g c3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwv c3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFy aWFsLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+RnVuZGFtZW50YWxseSBJIGZ1bGx5IGFncmVlIHdp dGggeW91LjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4m bmJzcDs8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+SG93ZXZlciBhcmNoaXRlY3R1cmFsbHk6Jm5ic3A7PG86cCBjbGFzcz0iIj48 L286cD48L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJt YXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48L2Rpdj4NCjwv ZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlm OyIgY2xhc3M9IiI+SG93ZXZlciBhdCBsZWFzdCBsb29raW5nIGF0IGdyb3VwIG9mIGZvbGtzIHdo byBjbGFpbSB0aGF0IGl0IGlzIGltcG9zc2libGUgdG8gZ2V0IHNhbWUgU1JHQiBibG9jayBpbiAq YW55KiBuZXR3b3JrIGJldHdlZW4gdHdvIG9yIG1vcmUgdmVuZG9ycyAmbmJzcDtJIHRoaW5rIFN0 ZXBoYW5lJ3MgaW50ZW50aW9uIHdvdWxkIGJlIHRvIGF0IGxlYXN0IGdldCBpdCBwZXINCiBvbmUg cHJvdG9jb2wgZXZlbiBpZiBwbGF0Zm9ybSB3aWRlIHRoZSBpbnRlcnNlY3RpbmcgcG9vbCBtYXkg YmUgbWlzc2lvbiBpbXBvc3NpYmxlLiZuYnNwOzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwv ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxi IGNsYXNzPSIiPjxpIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNs YXNzPSIiPiZuYnNwOzwvc3Bhbj48L2k+PC9iPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAw aW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxpIGNsYXNzPSIiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPltMZXM6XSBUaGlzIGlzIGFuIHVu cmVsYXRlZCBpc3N1ZS4gUGxhY2luZyBTUkdCIGluIGdsb2JhbCBjb250ZXh0IGRvZXMgbm90IG1l YW4gYWxsIHJvdXRlcnMgaGF2ZSB0byBoYXZlIHRoZSBzYW1lIFNSR0IuIFRoZXJlIGlzIG5vIGNv bnRyb3ZlcnN5DQogaGVyZS48bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMt c2VyaWY7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNw Ozwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+YW5kIG5vdyBvcGVyYXRpb25hbGx5OiZuYnNw OzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDs8 L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46 IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBB cmlhbCwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPkFub3RoZXIgcmVhc29uIHdvdWxkIGJlIGlkZWEg b2YgZHVhbCBvdmVybGFwcGluZyBTUkdCcyBwZXJoYXBzIHF1aXRlIHVzZWZ1bCBkdXJpbmcgbWln cmF0aW9ucyBiZXR3ZWVuIHByb3RvY29scyB3aGVyZSB0aGUgZXhhY3Qgc2FtZSBTUkdCIGlzIHNl dCBvbiBib3RoIHRoZW4ganVzdCBiYXNlZCBvbiBhZG1pbiBkaXN0YW5jZSBvbmUgdnMgdGhlIG90 aGVyDQogcHJvdG9jb2wgaXMgY2hvc2VuLiBXaGlsZSBhIHN0YW5kYXJkIHByYWN0aWNlIGluIHBy b3RvY29sIG1pZ3JhdGlvbnMgbm90IHN1cmUgaWYgYW55b25lIGxvb2tlZCBhdCB0aGF0IGZyb20g U1IgcGVyc3BlY3RpdmUuPG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9kaXY+DQo8ZGl2IHN0 eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PGkg Y2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+W0xlczpd IE5vdCBzdXJlIHdoYXQgeW91IGFyZSB0cnlpbmcgdG8gc2F5LiBJZiB0aGUgdHdvIFNSR0JzIGFy ZSB0aGUgc2FtZSDigJMgd2h5IGRvIHdlIG5lZWQgdG8gY29uZmlndXJlIHRoZW0gcGVyIHByb3Rv Y29sPzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9kaXY+DQo8ZGl2IHN0eWxl PSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PGkgY2xh c3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+SWYgdGhlIHR3 byBTUkdCcyBhcmUgbm90IHRoZSBzYW1lLCBvdGhlciByb3V0ZXJzIGluIHRoZSBuZXR3b3JrIGhh dmUgJm5ic3A7bm8gaWRlYSB3aGljaCBwcm90b2NvbCBpcyBnb2luZyB0byB3aW4gb24geW91ciBi b3guIFNvIHlvdXIgbmVpZ2hib3INCiBoYXMgbm8gaWRlYSB3aGV0aGVyIGl0IHNob3VsZCB1c2Ug dGhlIFNSR0IgYWR2ZXJ0aXNlZCBieSBPU1BGIG9yIHRoZSBTUkdCIGFkdmVydGlzZWQgYnkgSVMt SVMuPC9zcGFuPjwvaT48L2I+PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkFj dHVhbGx5LCBpZiB0aGUgc2FtZSBwcmVmaXggaW4gdGhlIHNhbWUgdG9wb2xvZ3kgaXMgYWR2ZXJ0 aXNlZCBieSB0d28gcHJvdG9jb2xzLCBJIHdvdWxkIHRoaW5rIHRoYXQgdGhlIFNJRCBzaG91bGQg bWFwIHRvIHRoZSBzYW1lIGxhYmVsLiBJIHNlZSBubyBhZHZhbnRhZ2UgYXQgYWxsIGluIGhhdmlu ZyBzZXBhcmF0ZSBsYWJlbHMuJm5ic3A7PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L3NwYW4+DQo8ZGl2IGNsYXNzPSIiPjxmb250IGNvbG9yPSIjMDAwMGZmIiBjbGFzcz0iIj48YiBj bGFzcz0iIj5bUHVzaHBhc2lzXSBXZSBhcmUgdGFsa2luZyBhYm91dCB0aGUgTVBMUyB0cmFuc2l0 IGxhYmVsIGZvciB0aGUgZGVzdGluYXRpb24gRkVDIGhlcmUuIExpa2UgUlNWUCBhbmQgTERQLCBp biBNUExTIGRhdGEgcGxhbmUgdG9kYXksIHRoZSBGRUMgbWF5YmUgc2FtZSBidXQgdGhlIHRyYW5z aXQgbGFiZWwgYWxsb2NhdGVkIGJ5IGVhY2ggcHJvdG9jb2wgYXJlDQogZGlmZmVyZW50LiA8L2I+ PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8ZGl2PlRoaXMgaXMgbm90ICZuYnNwO2EgZ29vZCBhbmFsb2d5LiBM RFAgbm9ybWFsbHkgZm9sbG93cyB0aGUgSVAgcm91dGVkIHBhdGggd2hpbGUgUlNWUCBpcyB1c2Vk IHRvIHNldCB1cCBhIFRFIGVuZ2luZWVyZWQgcGF0aC4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyIGNs YXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBj bGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJ3b3JkLXdyYXA6IGJyZWFrLXdv cmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJyZWFrOiBhZnRlci13 aGl0ZS1zcGFjZTsgZm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1z ZXJpZjsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48Zm9udCBjb2xvcj0iIzAwMDBmZiIgY2xh c3M9IiI+PGIgY2xhc3M9IiI+U2ltaWxhcmx5IGZvciBTUiBtYXBwZWQgdG8gTVBMUyBkYXRhIHBs YW5lIHRoZSB0cmFuc2l0IGxhYmVsIGFsbG9jYXRlZCBieSBJU0lTIGFuZCBPU1BGIGZvciB0aGUg c2FtZSBkZXN0aW5hdGlvbiBGRUMgc2hvdWxkIGJlIGRpZmZlcmVudC4gSGVuY2UgdGhlIG5lZWQg b2YgcGVyLXByb3RvY29sIFNSR0IuPC9iPjwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5UaGlzIGlzIGEg Y2lyY3VsYXIgYXJndW1lbnQuIFdoeSB3b3VsZCB0aGUgSVAgdW5pY2FzdCByb3V0ZWQgcGF0aCBy ZXF1aXJlIGEgZGlmZmVyZW50IGxhYmVsIGZvciBJU0lTIHZzIE9TUEY/Jm5ic3A7PC9kaXY+DQo8 ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5BY2VlJm5ic3A7PC9kaXY+DQo8ZGl2Pjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFz cz0iIj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4N CjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNw YWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBmb250LXNpemU6IDE0 cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBp ZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iIHN0eWxlPSIiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6 IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+QWNlZSZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+ DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YnIgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7IGZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogMTJweDsgZm9udC1zdHlsZTogbm9ybWFsOyBm b250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6 IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjog c3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFj ZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQt c3Ryb2tlLXdpZHRoOiAwcHg7Ij4NCjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTogbm9uZSBub25l IG5vbmUgc29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOiBibHVlOyBib3JkZXItbGVmdC13aWR0aDog MS41cHQ7IHBhZGRpbmc6IDBpbiAwaW4gMGluIDRwdDsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7 IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsi IGNsYXNzPSIiPg0KPGIgY2xhc3M9IiI+PGkgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTFwdDsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyIgY2xhc3M9IiI+PG86cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9pPjwvYj48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 YiBjbGFzcz0iIj48aSBjbGFzcz0iIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBj bGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9pPjwvYj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjog MGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8YiBjbGFzcz0iIj48aSBjbGFzcz0iIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJp ZjsgY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDsmbmJzcDsgTGVzPG86 cCBjbGFzcz0iIj48L286cD48L3NwYW4+PC9pPjwvYj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOiAx MXB0OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigzMSwgNzMs IDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsiIGNsYXNzPSIiPiZuYnNw Ozwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9Im1hcmdp bjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 IEFyaWFsLCBzYW5zLXNlcmlmOyIgY2xhc3M9IiI+Q2hlZXJzLDxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2lu OiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTog QXJpYWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj5SLjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9zcGFu PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g MGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQXJpYWws IHNhbnMtc2VyaWY7IiBjbGFzcz0iIj4mbmJzcDs8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIi Pg0KPG86cCBjbGFzcz0iIj4mbmJzcDs8L286cD48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2 IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KT24gV2VkLCBKdWwg MjksIDIwMTUgYXQgMTE6MDEgUE0sIExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpICZsdDs8YSBocmVm PSJtYWlsdG86Z2luc2JlcmdAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayIgc3R5bGU9ImNvbG9y OiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgY2xhc3M9IiI+Z2luc2JlcmdA Y2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAu MDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywg c2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi IGNsYXNzPSIiPlN0ZXBoYW5lIOKAkzwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0K PGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0 eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwvc3Bhbj48bzpw IGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAw MXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IiBjbGFzcz0iIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNs YXNzPSIiPldoYXQgaXMgdGhlIHJlcXVpcmVtZW50IHRvIGhhdmUgYSBwZXItcHJvdG9jb2wgU1JH QiBjb25maWc/PC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IGNsYXNzPSIi Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NCjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IiBjbGFzcz0iIj7igIvigIs8 bzpwIGNsYXNzPSIiPjwvbzpwPjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFy Z2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGlt ZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4NClRoaXMgbWFrZXMgbm8gc2Vuc2UgdG8g bWUgb3BlcmF0aW9uYWxseSBvciBhcmNoaXRlY3R1cmFsbHkuPG86cCBjbGFzcz0iIj48L286cD48 L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8 c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IiBjbGFzcz0iIj4mbmJzcDs8L3Nw YW4+PG86cCBjbGFzcz0iIj48L286cD48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBp biAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21h bicsIHNlcmlmOyIgY2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEy NSk7IiBjbGFzcz0iIj4oSSBhbSBub3QgdGFsa2luZyBhYm91dCB3aGF0IG1heSBvciBtYXkgbm90 IGhhdmUgYmVlbiBpbXBsZW1lbnRlZCBieSB2ZW5kb3JzIOKAkyB0aGUgWUFORyBtb2RlbCBzaG91 bGQgYmUgYXJjaGl0ZWN0dXJhbGx5IGNvcnJlY3QpPC9zcGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+ PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0K PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIgY2xhc3M9IiI+Jm5ic3A7PC9z cGFuPjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAw aW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwO0xlczwvc3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpw PjwvZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IiBjbGFzcz0iIj4N CjxzcGFuIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPiZuYnNwOzwv c3Bhbj48bzpwIGNsYXNzPSIiPjwvbzpwPjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xh c3M9IiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3Nw YW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZv bnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3Jt YWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6 IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9y bTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6 IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGlu ZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+c3ByaW5nDQogbWFpbGluZyBsaXN0PC9zcGFuPjxiciBz dHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxl OiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0 ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7 IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13 ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRv OnNwcmluZ0BpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBwdXJwbGU7IHRleHQtZGVjb3JhdGlvbjog dW5kZXJsaW5lOyBmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IDEycHg7IGZvbnQt c3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7 IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IG9ycGhhbnM6IGF1 dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTog bm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIgY2xhc3M9IiI+c3ByaW5nQGlldGYu b3JnPC9hPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4 OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdodDog bm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBo YW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFu c2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0KPGEg aHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmciIHN0eWxl PSJjb2xvcjogcHVycGxlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsgZm9udC1mYW1pbHk6 IEhlbHZldGljYTsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudDogbm9ybWFsOyBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFs OyBsaW5lLWhlaWdodDogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsg dGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3Jt YWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDsiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc3ByaW5nPC9hPjxiciBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl OiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdl aWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFs OyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4 dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29y ZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIi Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0K PC9kaXY+DQo8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5364D5F414CC4B2CB96D9A9929E843A2ciscocom_-- From nobody Thu Jul 30 06:18:53 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFE651A1BDF for ; Thu, 30 Jul 2015 06:18:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5z8wZvjbqn0y for ; Thu, 30 Jul 2015 06:18:48 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50B611A1B8A for ; Thu, 30 Jul 2015 06:18:47 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 556222ACE32; Thu, 30 Jul 2015 15:18:45 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.32]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 19EEC158084; Thu, 30 Jul 2015 15:18:45 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0248.002; Thu, 30 Jul 2015 15:18:44 +0200 From: To: "Les Ginsberg (ginsberg)" , Uma Chunduri , "Aissaoui, Mustapha (Mustapha)" , "spring@ietf.org" , "Shraddha Hegde (shraddha@juniper.net)" , "Pushpasis Sarkar (psarkar@juniper.net)" , "Hannes Gredler (hannes@juniper.net)" Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQxXDqt9XtTVUIwUOWTYSujokuPp3pPS4AgAAuawCAASqngIAHzVJQgABzf4CAAS75sA== Date: Thu, 30 Jul 2015 13:18:43 +0000 Message-ID: <9950_1438262325_55BA2435_9950_8082_1_9E32478DFA9976438E7A22F69B08FF92166BA633@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92166BA633OPEXCLILMA4corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.30.115417 Archived-At: Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2015 13:18:53 -0000 --_000_9E32478DFA9976438E7A22F69B08FF92166BA633OPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable As mentioned by others, there may be some operational gain. IGP migration example given is a good example, today with pure IP, there's = some tricky cases because we need to manage it with admin distance and thei= r may be some differences in best path computation between IGPs (implementa= tion dependant, but it's a reality). Here we have the opportunity to overcome this issue by letting the possibil= ity to create two parallel forwarding planes using different labels. I agre= e that it consumes twice the number of required label, but it may be a tran= sient solution (for migration case) and also it's a design choice of the op= erator. The last comment from Robert of virtualization , especially using container= s or part of router OS running on COTS (just OSPF or ISIS or BGP code), may= require some more independency between router software components. Now from an architectural perspective, what is Segment Routing ? Segment routing is just an architecture, like MPLS is. We see that segment = routing has more and more controlplanes (ISIS and OSPF first, now BGP ...),= like MPLS does. Moreover using segment routing in an MPLS environment lead= s to adding new controlplanes to MPLS. So I like the comment from Pushpasis talking about BGP, LDP, RSVP which are= different controlplane of MPLS. Do we advertise the same label value for t= he same prefix FEC advertised in LDP, BGP and RSVP ? No ... so why doing it= with OSPF and ISIS ? From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] Sent: Wednesday, July 29, 2015 23:01 To: LITKOWSKI Stephane SCE/IBNF; Uma Chunduri; Aissaoui, Mustapha (Mustapha= ); spring@ietf.org; Shraddha Hegde (shraddha@juniper.net); Pushpasis Sarkar= (psarkar@juniper.net); Hannes Gredler (hannes@juniper.net) Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Stephane - What is the requirement to have a per-protocol SRGB config? This makes no sense to me operationally or architecturally. (I am not talking about what may or may not have been implemented by vendor= s - the YANG model should be architecturally correct) Les From: stephane.litkowski@orange.com [= mailto:stephane.litkowski@orange.com] Sent: Wednesday, July 29, 2015 5:11 AM To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); s= pring@ietf.org; Shraddha Hegde (shraddha@juniper.ne= t); Pushpasis Sarkar (psarkar@juniper.net); Hannes Gredler (hannes@juniper.net) Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi all, What if we keep the SRGB block config in "segment-routing" global module, a= nd if we allow for YANG configuration of carving this block inside each pro= tocol (maybe as a feature) ? Stephane From: Uma Chunduri [mailto:uma.chunduri@ericsson.com] Sent: Friday, July 24, 2015 16:59 To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI Steph= ane SCE/IBNF; spring@ietf.org Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang >Suggesting that the forwarding instruction (AKA label) needs to be differ= ent depending on what protocol provided >the instruction is completely unnecessary - it simply wastes label space. [Uma]: Les, No - I never suggested anything like that. SRGB for a routing instance to be advertised should be part of the routing = instance provisioning as far as the yang model is concerned. Carving out the label space for SR is a local matter and agree, of course, = this can be done in so many ways through CLI, dynamically, statically etc.= .. -- Uma C. ___________________________________________________________________________= ______________________________________________ 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_9E32478DFA9976438E7A22F69B08FF92166BA633OPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    As mentioned by others= , there may be some operational gain.

    IGP migration example = given is a good example, today with pure IP, there’s some tricky case= s because we need to manage it with admin distance and their may be some di= fferences in best path computation between IGPs (implementation dependant, but it’s a reality).

    Here we have the oppor= tunity to overcome this issue by letting the possibility to create two para= llel forwarding planes using different labels. I agree that it consumes twi= ce the number of required label, but it may be a transient solution (for migration case) and also it’s a = design choice of the operator.

    The last comment from = Robert of virtualization , especially using containers or part of router OS= running on COTS (just OSPF or ISIS or BGP code), may require some more ind= ependency between router software components.

     

     

    Now from an architectu= ral perspective, what is Segment Routing ?

    Segment routing is jus= t an architecture, like MPLS is. We see that segment routing has more and m= ore controlplanes (ISIS and OSPF first, now BGP …), like MPLS does. M= oreover using segment routing in an MPLS environment leads to adding new controlplanes to MPLS.

    So I like the comment = from Pushpasis talking about BGP, LDP, RSVP which are different controlplan= e of MPLS. Do we advertise the same label value for the same prefix FEC adv= ertised in LDP, BGP and RSVP ? No … so why doing it with OSPF and ISIS ?

     

     

    From: Les Gins= berg (ginsberg) [mailto:ginsberg@cisco.com]
    Sent: Wednesday, July 29, 2015 23:01
    To: LITKOWSKI Stephane SCE/IBNF; Uma Chunduri; Aissaoui, Mustapha (M= ustapha); spring@ietf.org; Shraddha Hegde (shraddha@juniper.net); Pushpasis= Sarkar (psarkar@juniper.net); Hannes Gredler (hannes@juniper.net)
    Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

     

    Stephane –<= /o:p>

     

    What is the requiremen= t to have a per-protocol SRGB config?

    This makes no sense to= me operationally or architecturally.

     

    (I am not talking abou= t what may or may not have been implemented by vendors – the YANG mod= el should be architecturally correct)

     

       Les<= /o:p>

     

     

    From: stephane.litkowski@orange.= com [mailto:stephane.l= itkowski@orange.com]
    Sent: Wednesday, July 29, 2015 5:11 AM
    To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Musta= pha); spring@ietf.org; Shraddha Hegde (shraddha@juniper.net); Pushpasis Sarkar (psarkar@juniper.net); Hannes Gredler (hannes@juniper.net)
    Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

     

    Hi all,

     

    What if we keep the SR= GB block config in “segment-routing” global module, and if we a= llow for YANG configuration of carving this block inside each protocol (may= be as a feature) ?

     

    Stephane

     

     

    From: Uma Chun= duri [mailto:uma.chunduri@eric= sson.com]
    Sent: Friday, July 24, 2015 16:59
    To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSK= I Stephane SCE/IBNF; spring@ietf.org
    Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

     

    >Suggesting that the forwarding instruction (AKA label)  needs= to be different depending on what protocol provided

    >the instruction is completely unnecessary – it simply wastes= label space.

     

    [Uma]: Les, No - I nev= er suggested anything like that.

    SRGB for a routing ins= tance to be advertised should be part of the routing instance provisioning = as far as the yang model is concerned.

    Carving out the label = space for SR is a local matter and agree, of course, this  can be done= in so many ways through CLI, dynamically, statically etc...

     

    --

    Uma C.

     

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

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

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
    --_000_9E32478DFA9976438E7A22F69B08FF92166BA633OPEXCLILMA4corp_-- From nobody Thu Jul 30 06:48:19 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A3551A88D1 for ; Thu, 30 Jul 2015 06:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CF3NvLXI5saT for ; Thu, 30 Jul 2015 06:48:15 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47D161A884B for ; Thu, 30 Jul 2015 06:48:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10232; q=dns/txt; s=iport; t=1438264095; x=1439473695; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=qC4kKDGcCE4X9IBSY8T0PDIbw9HCF1bPmY/9Iu+0kJ4=; b=NNyu2RPdlpP7mjlxvopMhYcVt4KAWhk+ycc/FkTbRpAdUZJkyoJ2Yp1a 1t0l2cF7z/PSKRj1OdCvlXgEnydy/8L9NWAnfw7isDu/5StRBLkzmbZU9 8e0vX3ecrlfi2EpeXlKT9L3LCQ2rY4Ak2MRhkonQRTdbKFcw6qqGjdpGG w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BJBQDHKbpV/4QNJK1aAYJNTVRpBoMduQCBeQEJhS9KAhyBHDkTAQEBAQEBAYEKhCMBAQEEAQEBIEsLEAIBCA4DAwECGgIMAwICAiULFAkIAgQOBYguDbh0lgYBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItOhHYRBgEoAYJAL4EUBZR3AYxIgUeUDoNkJoN9b4FIgQQBAQE X-IronPort-AV: E=Sophos; i="5.15,577,1432598400"; d="scan'208,217"; a="16319709" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-4.cisco.com with ESMTP; 30 Jul 2015 13:48:14 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id t6UDmE7I030562 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jul 2015 13:48:14 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.37]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.03.0195.001; Thu, 30 Jul 2015 08:48:13 -0500 From: "Acee Lindem (acee)" To: Pushpasis Sarkar Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AdDEofPBVXKHufkve0KzevJD/YWvlQAy4ooQAAtTpAAAAPoLAAAFzVkAACVU3IAA9ZAggAASigWAAAGFqgAAAYgzAAARx7UAAAB01AAADd4zgA== Date: Thu, 30 Jul 2015 13:48:13 +0000 Message-ID: <66B97186-1749-418C-A4BB-7E85BB72DB11@cisco.com> References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.204] Content-Type: multipart/alternative; boundary="_000_66B971861749418CA4BB7E85BB72DB11ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Les Ginsberg \(ginsberg\)" , "spring@ietf.org" , Robert Raszuk , Stephane Litkowski , Shraddha Hegde , Uma Chunduri , "Aissaoui, Mustapha \(Mustapha\)" , Hannes Gredler Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2015 13:48:17 -0000 --_000_66B971861749418CA4BB7E85BB72DB11ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9iZXJ0LCBQdXNocGFzaXMsIFNocmFkZGhhLA0KDQpJIGd1ZXNzIEkgZG9u4oCZdCB1bmRlcnN0 YW5kIHdoeSB0aGlzIGdpdmVzIHlvdSBhbnkgb3BlcmF0aW9uYWwgYWR2YW50YWdlIHdoZW4geW91 IGFyZSBtaWdyYXRpbmcgYmV0d2VlbiBwcm90b2NvbCAoZS5nLiwgZnJvbSBJUy1JUyB0byBPU1BG IDteKS4gSW4gZmFjdCwgaWYgeW91IGFyZSB1c2luZyBzZXBhcmF0ZSBsYWJlbCBzcGFjZXMgaXQg d2lsbCBtYWtlIG1pZ3JhdGlvbiBtb3JlIGRpZmZpY3VsdCBhbmQgeW91IHdpbGwgaGF2ZSB0byBt aWdyYXRlIHlvdXIgcm91dGluZyBkb21haW4gaW4gc2hvdCByYXRoZXIgdGhhbiBpbmNyZW1lbnRh bGx5Lg0KDQpUaGFua3MsDQpBY2VlDQoNCk9uIEp1bCAzMCwgMjAxNSwgYXQgMzoxMSBBTSwgUHVz aHBhc2lzIFNhcmthciA8cHNhcmthckBqdW5pcGVyLm5ldDxtYWlsdG86cHNhcmthckBqdW5pcGVy Lm5ldD4+IHdyb3RlOg0KDQorMQ0KDQpGcm9tOiBTaHJhZGRoYSBIZWdkZSA8c2hyYWRkaGFAanVu aXBlci5uZXQ8bWFpbHRvOnNocmFkZGhhQGp1bmlwZXIubmV0Pj4NCkRhdGU6IFRodXJzZGF5LCBK dWx5IDMwLCAyMDE1IGF0IDg6NTggQU0NClRvOiAiTGVzIEdpbnNiZXJnIChnaW5zYmVyZykiIDxn aW5zYmVyZ0BjaXNjby5jb208bWFpbHRvOmdpbnNiZXJnQGNpc2NvLmNvbT4+LCBSb2JlcnQgUmFz enVrIDxyb2JlcnRAcmFzenVrLm5ldDxtYWlsdG86cm9iZXJ0QHJhc3p1ay5uZXQ+Pg0KQ2M6ICJz dGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTxtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9y YW5nZS5jb20+IiA8c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208bWFpbHRvOnN0ZXBoYW5l LmxpdGtvd3NraUBvcmFuZ2UuY29tPj4sIFVtYSBDaHVuZHVyaSA8dW1hLmNodW5kdXJpQGVyaWNz c29uLmNvbTxtYWlsdG86dW1hLmNodW5kdXJpQGVyaWNzc29uLmNvbT4+LCAiQWlzc2FvdWksIE11 c3RhcGhhIChNdXN0YXBoYSkiIDxtdXN0YXBoYS5haXNzYW91aUBhbGNhdGVsLWx1Y2VudC5jb208 bWFpbHRvOm11c3RhcGhhLmFpc3Nhb3VpQGFsY2F0ZWwtbHVjZW50LmNvbT4+LCAic3ByaW5nQGll dGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+IiA8c3ByaW5nQGlldGYub3JnPG1haWx0bzpz cHJpbmdAaWV0Zi5vcmc+PiwgUHVzaHBhc2lzIFNhcmthciA8cHNhcmthckBqdW5pcGVyLm5ldDxt YWlsdG86cHNhcmthckBqdW5pcGVyLm5ldD4+LCBIYW5uZXMgR3JlZGxlciA8aGFubmVzQGp1bmlw ZXIubmV0PG1haWx0bzpoYW5uZXNAanVuaXBlci5uZXQ+Pg0KU3ViamVjdDogUkU6IFtzcHJpbmdd IE1vZGVsaW5nIFNSR0IgY29uZmlndXJhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFu Zw0KDQoNCltTaHJhZGRoYV0gcm91dGUgcHJlZmVyZW5jZSBpcyBsb2NhbCB0byByb3V0ZXIgYW5k IHRoZSBuZWlnaGJvciBuZXZlciBrbm93cyB3aGF0IHRoZSBvdGhlciBpcyBnb2luZyB0byBjaG9v c2UuICBJZiB0aGVyZSBhcmUgaW5jb25zaXN0ZW5jaWVzIGluIHR3byBwcm90b2NvbHMsIHRoZXJl IGFyZSBnb2luZyB0byBiZSBsb29wcyBldmVuIHdoZW4gdGhleSB1c2Ugc2FtZSBTUkdCLiBLZWVw aW5nIGRpZmZlcmVudCBsYWJlbHMgbWFrZXMgaXQgZWFzaWVyIHRvIHRyb3VibGVzaG9vdC4NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNwcmluZyBt YWlsaW5nIGxpc3QNCnNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmcNCg0K --_000_66B971861749418CA4BB7E85BB72DB11ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <717360850793E24F9AF412DBED9FC640@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5Sb2JlcnQs IFB1c2hwYXNpcywgU2hyYWRkaGEsJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjwvZGl2Pg0KSSBndWVzcyBJIGRvbuKAmXQgdW5kZXJzdGFuZCB3aHkgdGhpcyBnaXZl cyB5b3UgYW55IG9wZXJhdGlvbmFsIGFkdmFudGFnZSB3aGVuIHlvdSBhcmUgbWlncmF0aW5nIGJl dHdlZW4gcHJvdG9jb2wgKGUuZy4sIGZyb20gSVMtSVMgdG8gT1NQRiA7XikuIEluIGZhY3QsIGlm IHlvdSBhcmUgdXNpbmcgc2VwYXJhdGUgbGFiZWwgc3BhY2VzIGl0IHdpbGwgbWFrZSBtaWdyYXRp b24gbW9yZSBkaWZmaWN1bHQgYW5kIHlvdSB3aWxsIGhhdmUgdG8gbWlncmF0ZQ0KIHlvdXIgcm91 dGluZyBkb21haW4gaW4gc2hvdCByYXRoZXIgdGhhbiBpbmNyZW1lbnRhbGx5LiZuYnNwOw0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPlRoYW5rcyw8L2Rpdj4NCjxk aXYgY2xhc3M9IiI+QWNlZTxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0i Ij5PbiBKdWwgMzAsIDIwMTUsIGF0IDM6MTEgQU0sIFB1c2hwYXNpcyBTYXJrYXIgJmx0OzxhIGhy ZWY9Im1haWx0bzpwc2Fya2FyQGp1bmlwZXIubmV0IiBjbGFzcz0iIj5wc2Fya2FyQGp1bmlwZXIu bmV0PC9hPiZndDsgd3JvdGU6PC9kaXY+DQo8YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5l d2xpbmUiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29y ZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdo aXRlLXNwYWNlOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNl cmlmOyIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPiYjNDM7MTwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiIg Y2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaTsgZm9udC1zaXplOiAx MXB0OyB0ZXh0LWFsaWduOiBsZWZ0OyBib3JkZXItd2lkdGg6IDFwdCBtZWRpdW0gbWVkaXVtOyBi b3JkZXItc3R5bGU6IHNvbGlkIG5vbmUgbm9uZTsgcGFkZGluZzogM3B0IDBpbiAwaW47IGJvcmRl ci10b3AtY29sb3I6IHJnYigxODEsIDE5NiwgMjIzKTsiIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiIGNsYXNzPSIiPkZyb206IDwvc3Bhbj5TaHJhZGRoYSBIZWdkZSAm bHQ7PGEgaHJlZj0ibWFpbHRvOnNocmFkZGhhQGp1bmlwZXIubmV0IiBjbGFzcz0iIj5zaHJhZGRo YUBqdW5pcGVyLm5ldDwvYT4mZ3Q7PGJyIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiIGNsYXNzPSIiPkRhdGU6IDwvc3Bhbj5UaHVyc2RheSwgSnVseSAzMCwgMjAxNSBh dCA4OjU4IEFNPGJyIGNsYXNzPSIiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiIGNs YXNzPSIiPlRvOiA8L3NwYW4+JnF1b3Q7TGVzIEdpbnNiZXJnIChnaW5zYmVyZykmcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpnaW5zYmVyZ0BjaXNjby5jb20iIGNsYXNzPSIiPmdpbnNiZXJnQGNp c2NvLmNvbTwvYT4mZ3Q7LCBSb2JlcnQgUmFzenVrICZsdDs8YSBocmVmPSJtYWlsdG86cm9iZXJ0 QHJhc3p1ay5uZXQiIGNsYXNzPSIiPnJvYmVydEByYXN6dWsubmV0PC9hPiZndDs8YnIgY2xhc3M9 IiI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCIgY2xhc3M9IiI+Q2M6IDwvc3Bhbj4m cXVvdDs8YSBocmVmPSJtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20iIGNsYXNz PSIiPnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIiBjbGFzcz0iIj5zdGVwaGFuZS5s aXRrb3dza2lAb3JhbmdlLmNvbTwvYT4mZ3Q7LCBVbWEgQ2h1bmR1cmkgJmx0OzxhIGhyZWY9Im1h aWx0bzp1bWEuY2h1bmR1cmlAZXJpY3Nzb24uY29tIiBjbGFzcz0iIj51bWEuY2h1bmR1cmlAZXJp Y3Nzb24uY29tPC9hPiZndDssDQogJnF1b3Q7QWlzc2FvdWksIE11c3RhcGhhIChNdXN0YXBoYSkm cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptdXN0YXBoYS5haXNzYW91aUBhbGNhdGVsLWx1Y2Vu dC5jb20iIGNsYXNzPSIiPm11c3RhcGhhLmFpc3Nhb3VpQGFsY2F0ZWwtbHVjZW50LmNvbTwvYT4m Z3Q7LCAmcXVvdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIiBjbGFzcz0iIj5zcHJp bmdAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3Jn IiBjbGFzcz0iIj5zcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0OywNCiBQdXNocGFzaXMgU2Fya2FyICZs dDs8YSBocmVmPSJtYWlsdG86cHNhcmthckBqdW5pcGVyLm5ldCIgY2xhc3M9IiI+cHNhcmthckBq dW5pcGVyLm5ldDwvYT4mZ3Q7LCBIYW5uZXMgR3JlZGxlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmhh bm5lc0BqdW5pcGVyLm5ldCIgY2xhc3M9IiI+aGFubmVzQGp1bmlwZXIubmV0PC9hPiZndDs8YnIg Y2xhc3M9IiI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCIgY2xhc3M9IiI+U3ViamVj dDogPC9zcGFuPlJFOiBbc3ByaW5nXSBNb2RlbGluZyBTUkdCIGNvbmZpZ3VyYXRpb24gZm9yIGRy YWZ0LWlldGYtc3ByaW5nLXNyLXlhbmc8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBz ZXJpZjsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWln aHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsg b3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQt dHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4N CjxiIGNsYXNzPSIiPjxpIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZv bnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsi IGNsYXNzPSIiPjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9kaXY+ DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsg Zm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsgZm9udC1zdHlsZTogbm9ybWFs OyBmb250LXZhcmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNp bmc6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGln bjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1z cGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj4NCjxiIGNsYXNzPSIiPjxpIGNsYXNzPSIi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDExcHQ7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5z LXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiIGNsYXNzPSIiPltTaHJhZGRoYV0gcm91 dGUgcHJlZmVyZW5jZSBpcyBsb2NhbCB0byByb3V0ZXIgYW5kIHRoZSBuZWlnaGJvciBuZXZlciBr bm93cyB3aGF0IHRoZSBvdGhlciBpcyBnb2luZyB0byBjaG9vc2UuICZuYnNwO0lmIHRoZXJlIGFy ZSBpbmNvbnNpc3RlbmNpZXMNCiBpbiB0d28gcHJvdG9jb2xzLCB0aGVyZSBhcmUgZ29pbmcgdG8g YmUgbG9vcHMgZXZlbiB3aGVuIHRoZXkgdXNlIHNhbWUgU1JHQi4gS2VlcGluZyBkaWZmZXJlbnQg bGFiZWxzIG1ha2VzIGl0IGVhc2llciB0byB0cm91Ymxlc2hvb3QuPG86cCBjbGFzcz0iIj48L286 cD48L3NwYW4+PC9pPjwvYj48L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudDogbm9ybWFsOyBmb250LXdlaWdo dDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOyBv cnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10 cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1z cGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsiIGNsYXNzPSIiPg0K PGIgY2xhc3M9IiI+PGkgY2xhc3M9IiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTFwdDsgZm9u dC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyIg Y2xhc3M9IiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7PC9zcGFuPjwvaT48L2I+PC9kaXY+DQo8L3NwYW4+PC9kaXY+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4N CnNwcmluZyBtYWlsaW5nIGxpc3Q8YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86c3ByaW5n QGlldGYub3JnIiBjbGFzcz0iIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8YnIgY2xhc3M9IiI+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_66B971861749418CA4BB7E85BB72DB11ciscocom_-- From nobody Thu Jul 30 07:54:33 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EA71A1BDD for ; Thu, 30 Jul 2015 07:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nejlcFyz0X4r for ; Thu, 30 Jul 2015 07:54:29 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0756.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:756]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C5ED1A1BDB for ; Thu, 30 Jul 2015 07:54:28 -0700 (PDT) Received: from BLUPR05MB1969.namprd05.prod.outlook.com (10.162.224.23) by BLUPR05MB436.namprd05.prod.outlook.com (10.141.27.152) with Microsoft SMTP Server (TLS) id 15.1.219.17; Thu, 30 Jul 2015 14:54:25 +0000 Received: from BLUPR05MB1969.namprd05.prod.outlook.com ([10.162.224.23]) by BLUPR05MB1969.namprd05.prod.outlook.com ([10.162.224.23]) with mapi id 15.01.0225.018; Thu, 30 Jul 2015 14:54:23 +0000 From: Pushpasis Sarkar To: "Acee Lindem (acee)" Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQytefyeCw+p7fpUSS6Q5qSOgdUQ== Date: Thu, 30 Jul 2015 14:54:23 +0000 Message-ID: References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <66B97186-1749-418C-A4BB-7E85BB72DB11@cisco.com> In-Reply-To: <66B97186-1749-418C-A4BB-7E85BB72DB11@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.184.19] x-microsoft-exchange-diagnostics: 1; BLUPR05MB436; 5:dZ3AnZEsBevrHemt0p5mf/yxXACQS9zL5DqE9llzGWyjwvj8T09yed3dFioNLs5zRj8X5OVL9Hj+61/RcyH0X4/rI/GOD+VBFgkXtPGPJajvn5rIz2gLdMUUGgYsovmRElKiPLFRIS6rLGw51UqrdQ==; 24:LV1op5gQ1bt32OSMUD7/6u6hDcoyxywpq8FCbnnS+oOfrdTWY6666mdTirnvWfvsBmiEbPyJBRSRt+mOgTqi27XjCVXCSclD8EqTEpOsJeg=; 20:OX1JJpbZbX5TPYkPP/mMjo1grumtvIX2Pya9duNt4d59Xg4Rpgv+lS6rA9TGJEuSjG82eND+n8m5J4jVLWUuoQ== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB436; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB436; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB436; x-forefront-prvs: 06530126A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(164054003)(377454003)(86362001)(5002640100001)(93886004)(4001350100001)(46102003)(19580395003)(83506001)(2656002)(87936001)(107886002)(5001960100002)(110136002)(36756003)(106116001)(99286002)(92566002)(54356999)(50986999)(76176999)(122556002)(16236675004)(19617315012)(230783001)(189998001)(66066001)(2900100001)(102836002)(15975445007)(77096005)(2950100001)(19580405001)(62966003)(77156002)(40100003)(4001430100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB436; H:BLUPR05MB1969.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D1E036F92CDB4psarkarjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2015 14:54:23.5109 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB436 Archived-At: Cc: "Les Ginsberg \(ginsberg\)" , "spring@ietf.org" , Robert Raszuk , Stephane Litkowski , Shraddha Hegde , Uma Chunduri , "Aissaoui, Mustapha \(Mustapha\)" , Hannes Gredler Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2015 14:54:32 -0000 --_000_D1E036F92CDB4psarkarjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Acee, From: "Acee Lindem (acee)" > Date: Thursday, July 30, 2015 at 7:18 PM To: Pushpasis Sarkar > Cc: Shraddha Hegde >, "Le= s Ginsberg (ginsberg)" >, Rob= ert Raszuk >, "Aissaoui, Mustap= ha (Mustapha)" >, Stephane Litkowski >, "spring@ietf.org" >, Uma Chunduri >, Hannes Gredler > Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Robert, Pushpasis, Shraddha, I guess I don't understand why this gives you any operational advantage whe= n you are migrating between protocol (e.g., from IS-IS to OSPF ;^). In fact= , if you are using separate label spaces it will make migration more diffic= ult and you will have to migrate your routing domain in shot rather than in= crementally. [Pushpasis] All routers will program both transit mpls labels and create tw= o parallel MPLS data planes well before the last step when all the ingress = router will be instructed to switch traffic onto the new MPLS data plane (p= rogrammed by the new protocol) by changing the admin distance. That way the= migration shall become seamless. And then once all ingreess routers has be= en swicthed to the new protocol and new MPLS dataplane, the old protocol an= d old MPLS data plane can be just removed from all the routers. Hope it is = clear now... Thanks, Acee On Jul 30, 2015, at 3:11 AM, Pushpasis Sarkar > wrote: +1 From: Shraddha Hegde > Date: Thursday, July 30, 2015 at 8:58 AM To: "Les Ginsberg (ginsberg)" >, Robert Raszuk > Cc: "stephane.litkowski@orange.com" <= stephane.litkowski@orange.com>, Uma C= hunduri >, "Ais= saoui, Mustapha (Mustapha)" >, "spring@ietf.org" >, Pushpasis Sarkar >, Hannes Gredler > Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang [Shraddha] route preference is local to router and the neighbor never knows= what the other is going to choose. If there are inconsistencies in two pr= otocols, there are going to be loops even when they use same SRGB. Keeping = different labels makes it easier to troubleshoot. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_D1E036F92CDB4psarkarjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
    Hi Acee,

    From: "Acee Lindem (acee)"= ; <acee@cisco.com>
    Date: Thursday, July 30, 2015 at 7:= 18 PM
    To: Pushpasis Sarkar <psarkar@juniper.net>
    Cc: Shraddha Hegde <shraddha@juniper.net>, "Les Ginsber= g (ginsberg)" <ginsberg@cisco= .com>, Robert Raszuk <robert= @raszuk.net>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com>, S= tephane Litkowski <step= hane.litkowski@orange.com>, "spring@ietf.org" <spring@ietf.org>, Uma Chundu= ri <uma.chunduri@ericsson.c= om>, Hannes Gredler <hannes= @juniper.net>
    Subject: Re: [spring] Modeling SRGB= configuration for draft-ietf-spring-sr-yang

    Robert, Pushpasis, Shraddha, 

    I guess I don’t understand why this gives you any operational advanta= ge when you are migrating between protocol (e.g., from IS-IS to OSPF ;^). I= n fact, if you are using separate label spaces it will make migration more = difficult and you will have to migrate your routing domain in shot rather than incrementally. 
    [Pushpasis] All routers will program both t= ransit mpls labels and create two parallel MPLS data planes well before the= last step when all the ingress router will be instructed to switch traffic= onto the new MPLS data plane (programmed by the new protocol) by changing the admin distance. That way the migratio= n shall become seamless. And then once all ingreess routers has been swicth= ed to the new protocol and new MPLS dataplane, the old protocol and old MPL= S data plane can be just removed from all the routers. Hope it is clear now… 

    Thanks,
    Acee

    On Jul 30, 2015, at 3:11 AM, Pushpasis Sarkar <psarkar@juniper.net> wrot= e:

    +1

    From: Shraddha Hegde <= ;shraddha@juniper.net>
    Date: Thursday, July 30,= 2015 at 8:58 AM
    To: "Les Ginsberg (= ginsberg)" <    ginsbe= rg@cisco.com>, Robert Raszuk <robert@raszuk.net>
    Cc: "stephane.litkowski@orange.com= " <= stephane.litkowski@orange.com>, Uma Chunduri <uma.chunduri@ericsson.com>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com= >, "spring@ietf.o= rg" <spring@ietf.= org>, Pushpasis Sarkar <psa= rkar@juniper.net>, Hannes Gredler <hannes@juniper.net>
    Subject: RE: [spring] Mo= deling SRGB configuration for draft-ietf-spring-sr-yang

    &nb= sp;
    [Shraddha] route pr= eference is local to router and the neighbor never knows what the other is = going to choose.  If there are inconsistencies in two protocols, there are going to be loops even when they use same SRGB= . Keeping different labels makes it easier to troubleshoot.=
       &= nbsp;           &nbs= p;    
    _______________________________________________
    spring mailing list
    spring@ietf.org
    https://www.ietf.o= rg/mailman/listinfo/spring

     --_000_D1E036F92CDB4psarkarjunipernet_-- From nobody Thu Jul 30 08:07:34 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFE91A702A for ; Thu, 30 Jul 2015 08:07:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYdXJJfwD-ol for ; Thu, 30 Jul 2015 08:07:30 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E23181A903E for ; Thu, 30 Jul 2015 08:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14463; q=dns/txt; s=iport; t=1438268841; x=1439478441; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BK06V8Xrj9Sq87oYEkrfNgYoE3QQZ1kL9Xb0jWNYhik=; b=eTG6W1nABo+wYohDIOx+VU2Xh6ajBHftn9IkIaj4Rh4InPlPSXZ2zZ6F evtCVo0E2nkCznWSPFK90Kojv5YKcWcqNEWBEZEdwQWfjZQKgFvunFm9/ vg0/7MgvYsZ5EVXV21IthcmneJ5Sd2aL3X833u93hIgjApc6BE54vI4Uv Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AgBQC9PLpV/4oNJK1aAYJNTVRpBrwdgXkBCYUvSgKBOjoSAQEBAQEBAYEKhCMBAQEEAQEBawsQAgEIDgMDAQIaAgwHJwsUCQgCBA4FiC4NzwgBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItOhHYNBAYBKAGCb4EUBZFigxUBjEiBR4gji2uDZCaDfW+BSIEEAQEB X-IronPort-AV: E=Sophos; i="5.15,577,1432598400"; d="scan'208,217"; a="16335598" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-5.cisco.com with ESMTP; 30 Jul 2015 15:07:20 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id t6UF7IeD001667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jul 2015 15:07:18 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.37]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Thu, 30 Jul 2015 10:07:18 -0500 From: "Acee Lindem (acee)" To: Pushpasis Sarkar Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQyteht1/pu5o+G0mFGfbARvh5zZ30cPuA Date: Thu, 30 Jul 2015 15:07:18 +0000 Message-ID: References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <66B97186-1749-418C-A4BB-7E85BB72DB11@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.204] Content-Type: multipart/alternative; boundary="_000_CB760E2EC386424F9E28E537ABEF30D0ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Les Ginsberg \(ginsberg\)" , "spring@ietf.org" , Robert Raszuk , Stephane Litkowski , Shraddha Hegde , Uma Chunduri , "Aissaoui, Mustapha \(Mustapha\)" , Hannes Gredler Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2015 15:07:32 -0000 --_000_CB760E2EC386424F9E28E537ABEF30D0ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Pushpasis, On Jul 30, 2015, at 10:54 AM, Pushpasis Sarkar > wrote: Hi Acee, From: "Acee Lindem (acee)" > Date: Thursday, July 30, 2015 at 7:18 PM To: Pushpasis Sarkar > Cc: Shraddha Hegde >, "Le= s Ginsberg (ginsberg)" >, Rob= ert Raszuk >, "Aissaoui, Mustap= ha (Mustapha)" >, Stephane Litkowski >, "spring@ietf.org" >, Uma Chunduri >, Hannes Gredler > Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Robert, Pushpasis, Shraddha, I guess I don=92t understand why this gives you any operational advantage w= hen you are migrating between protocol (e.g., from IS-IS to OSPF ;^). In fa= ct, if you are using separate label spaces it will make migration more diff= icult and you will have to migrate your routing domain in shot rather than = incrementally. [Pushpasis] All routers will program both transit mpls labels and create tw= o parallel MPLS data planes well before the last step when all the ingress = router will be instructed to switch traffic onto the new MPLS data plane (p= rogrammed by the new protocol) by changing the admin distance. That way the= migration shall become seamless. And then once all ingreess routers has be= en swicthed to the new protocol and new MPLS dataplane, the old protocol an= d old MPLS data plane can be just removed from all the routers. Hope it is = clear now=85 Normally only the protocol with the lower preference or admin distance woul= d install a route to a particular prefix (including the label) into the RIB= /LIB for the base IP unicast topology. I guess you are envisioning separate= RIBs per protocol as well? Thanks, Acee Thanks, Acee On Jul 30, 2015, at 3:11 AM, Pushpasis Sarkar > wrote: +1 From: Shraddha Hegde > Date: Thursday, July 30, 2015 at 8:58 AM To: "Les Ginsberg (ginsberg)" >, Robert Raszuk > Cc: "stephane.litkowski@orange.com" <= stephane.litkowski@orange.com>, Uma C= hunduri >, "Ais= saoui, Mustapha (Mustapha)" >, "spring@ietf.org" >, Pushpasis Sarkar >, Hannes Gredler > Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang [Shraddha] route preference is local to router and the neighbor never knows= what the other is going to choose. If there are inconsistencies in two pr= otocols, there are going to be loops even when they use same SRGB. Keeping = different labels makes it easier to troubleshoot. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_CB760E2EC386424F9E28E537ABEF30D0ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Pushpasis, 

    On Jul 30, 2015, at 10:54 AM, Pushpasis Sarkar <psarkar@juniper.net> wrot= e:

    Hi Acee,

    From: "Acee Lindem = (acee)" <acee@cisco.co= m>
    Date: Thursday, July 30,= 2015 at 7:18 PM
    To: Pushpasis Sarkar <= ;psarkar@juniper.net&= gt;
    Cc: Shraddha Hegde <<= a href=3D"mailto:shraddha@juniper.net" class=3D"">shraddha@juniper.net&= gt;, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Robert Raszuk <robert@raszuk.net>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com= >, Stephane Litkowski <stephane.litkowski@orange.com>, "spring@ietf.org" <spring@ietf.org>,= Uma Chunduri <u= ma.chunduri@ericsson.com>, Hannes Gredler <hannes@juniper.net>
    Subject: Re: [spring] Mo= deling SRGB configuration for draft-ietf-spring-sr-yang

    Robert, Pushpasis, Shraddha, 

    I guess I don=92t understand why this gives you any operational advantage w= hen you are migrating between protocol (e.g., from IS-IS to OSPF ;^). In fa= ct, if you are using separate label spaces it will make migration more diff= icult and you will have to migrate your routing domain in shot rather than incrementally. 
    [Pushpasis= ] All routers will program both transit mpls labels and create two parallel= MPLS data planes well before the last step when all the ingress router wil= l be instructed to switch traffic onto the new MPLS data plane (programmed by the new protocol) by changing the admin= distance. That way the migration shall become seamless. And then once all = ingreess routers has been swicthed to the new protocol and new MPLS datapla= ne, the old protocol and old MPLS data plane can be just removed from all the routers. Hope it is clear now= =85 

    Normally only the protocol with the lower preference or admin distance= would install a route to a particular prefix (including the label) into th= e RIB/LIB for the base IP unicast topology. I guess you are envisioning sep= arate RIBs per protocol as well? 

    Thanks,
    Acee





    Thanks,
    Acee

    On Jul 30, 2015, at 3:11 AM, Pushpasis Sarkar <psarkar@juniper.net> wrot= e:

    +1

    From: Shraddha Hegde <= ;shraddha@juniper.net>
    Date: Thursday, July 30,= 2015 at 8:58 AM
    To: "Les Ginsberg (= ginsberg)" <    ginsbe= rg@cisco.com>, Robert Raszuk <robert@raszuk.net>
    Cc: "stephane.litkowski@orange.com= " <= stephane.litkowski@orange.com>, Uma Chunduri <uma.chunduri@ericsson.com>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com= >, "spring@ietf.o= rg" <spring@ietf.= org>, Pushpasis Sarkar <psa= rkar@juniper.net>, Hannes Gredler <hannes@juniper.net>
    Subject: RE: [spring] Mo= deling SRGB configuration for draft-ietf-spring-sr-yang

    &nb= sp;
    [Shraddha] route pr= eference is local to router and the neighbor never knows what the other is = going to choose.  If there are inconsistencies in two protocols, there are going to be loops even when they use same SRGB= . Keeping different labels makes it easier to troubleshoot.=
       &= nbsp;           &nbs= p;    
    _______________________________________________
    spring mailing list
    spring@ietf.org
    https:/= /www.ietf.org/mailman/listinfo/spring


    --_000_CB760E2EC386424F9E28E537ABEF30D0ciscocom_-- From nobody Thu Jul 30 08:12:22 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24ADD1A6FF9 for ; Thu, 30 Jul 2015 08:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4vS-BWzFkvs for ; Thu, 30 Jul 2015 08:12:17 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0113.outbound.protection.outlook.com [65.55.169.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CD561AC3DB for ; Thu, 30 Jul 2015 08:11:56 -0700 (PDT) Received: from BLUPR05MB1969.namprd05.prod.outlook.com (10.162.224.23) by BLUPR05MB433.namprd05.prod.outlook.com (10.141.27.140) with Microsoft SMTP Server (TLS) id 15.1.225.19; Thu, 30 Jul 2015 15:11:54 +0000 Received: from BLUPR05MB1969.namprd05.prod.outlook.com ([10.162.224.23]) by BLUPR05MB1969.namprd05.prod.outlook.com ([10.162.224.23]) with mapi id 15.01.0225.018; Thu, 30 Jul 2015 15:11:54 +0000 From: Pushpasis Sarkar To: "Acee Lindem (acee)" Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQytoRULuQGrx8QEG+G21eIOfs4w== Date: Thu, 30 Jul 2015 15:11:54 +0000 Message-ID: References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <66B97186-1749-418C-A4BB-7E85BB72DB11@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.2.150604 authentication-results: cisco.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.184.19] x-microsoft-exchange-diagnostics: 1; BLUPR05MB433; 5:rViYgnS0KHnWCainRHTYPQSuOA3tIQGE8FVDxCuBNeTdNooxqIzJQDtc0IYPUEfZdVww2THs+bnbHwUadYmrZhz1QzD/JARpwRJUcOxbFzCos7u1AEal+ScZYfkSa19vq89k+WyZZkotgj/0yVlNnQ==; 24:tXlrj59UOg1osZvfvJ/kQbkK/+wjuKbgWm4DOiAfyj3pR2jW2kmOZfbRLSgXyW/PjTWh1PX2lS55rCqLFQCBOtG1B9CwSyfwpZWeyYwR7RY=; 20:BD1RBL8loh+0FbTIBQD6ZKvLpC7CE/EMiaf95qgCtDTizbgwAleQweQU9XQEW5Am5ZzPfFyGofdmZD+26UYElg== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB433; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB433; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB433; x-forefront-prvs: 06530126A4 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(24454002)(37854004)(164054003)(377454003)(93886004)(5002640100001)(230783001)(77096005)(189998001)(102836002)(46102003)(2900100001)(15975445007)(36756003)(87936001)(2950100001)(4001350100001)(86362001)(19580395003)(5001960100002)(77156002)(50986999)(99286002)(54356999)(92566002)(76176999)(19617315012)(5001920100001)(19580405001)(107886002)(110136002)(40100003)(16236675004)(122556002)(83506001)(106116001)(62966003)(2656002)(66066001)(4001430100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB433; H:BLUPR05MB1969.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/alternative; boundary="_000_D1E03BC62CDCBpsarkarjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jul 2015 15:11:54.1068 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB433 Archived-At: Cc: "Les Ginsberg \(ginsberg\)" , "spring@ietf.org" , Robert Raszuk , Stephane Litkowski , Shraddha Hegde , Uma Chunduri , "Aissaoui, Mustapha \(Mustapha\)" , Hannes Gredler Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2015 15:12:21 -0000 --_000_D1E03BC62CDCBpsarkarjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Acee, From: "Acee Lindem (acee)" > Date: Thursday, July 30, 2015 at 8:37 PM To: Pushpasis Sarkar > Cc: Shraddha Hegde >, "Le= s Ginsberg (ginsberg)" >, Rob= ert Raszuk >, "Aissaoui, Mustap= ha (Mustapha)" >, Stephane Litkowski >, "spring@ietf.org" >, Uma Chunduri >, Hannes Gredler > Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi Pushpasis, On Jul 30, 2015, at 10:54 AM, Pushpasis Sarkar > wrote: Hi Acee, From: "Acee Lindem (acee)" > Date: Thursday, July 30, 2015 at 7:18 PM To: Pushpasis Sarkar > Cc: Shraddha Hegde >, "Le= s Ginsberg (ginsberg)" >, Rob= ert Raszuk >, "Aissaoui, Mustap= ha (Mustapha)" >, Stephane Litkowski >, "spring@ietf.org" >, Uma Chunduri >, Hannes Gredler > Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Robert, Pushpasis, Shraddha, I guess I don't understand why this gives you any operational advantage whe= n you are migrating between protocol (e.g., from IS-IS to OSPF ;^). In fact= , if you are using separate label spaces it will make migration more diffic= ult and you will have to migrate your routing domain in shot rather than in= crementally. [Pushpasis] All routers will program both transit mpls labels and create tw= o parallel MPLS data planes well before the last step when all the ingress = router will be instructed to switch traffic onto the new MPLS data plane (p= rogrammed by the new protocol) by changing the admin distance. That way the= migration shall become seamless. And then once all ingreess routers has be= en swicthed to the new protocol and new MPLS dataplane, the old protocol an= d old MPLS data plane can be just removed from all the routers. Hope it is = clear now... Normally only the protocol with the lower preference or admin distance woul= d install a route to a particular prefix (including the label) into the RIB= /LIB for the base IP unicast topology. I guess you are envisioning separate= RIBs per protocol as well? [Pushpasis] What you are saying is true for the IP/V6->MPLS route in RIB/FI= B on ingress routers. It is NOT TRUE for MPLS transit routes in LFIB. In MP= LS architecture no two protocols installs the same label in LFIB. Each prot= ocol (LDP/RSVP) uses different transit labels for the same destination IP/V= 6 FEC. Thanks, Acee Thanks, Acee On Jul 30, 2015, at 3:11 AM, Pushpasis Sarkar > wrote: +1 From: Shraddha Hegde > Date: Thursday, July 30, 2015 at 8:58 AM To: "Les Ginsberg (ginsberg)" >, Robert Raszuk > Cc: "stephane.litkowski@orange.com" <= stephane.litkowski@orange.com>, Uma C= hunduri >, "Ais= saoui, Mustapha (Mustapha)" >, "spring@ietf.org" >, Pushpasis Sarkar >, Hannes Gredler > Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang [Shraddha] route preference is local to router and the neighbor never knows= what the other is going to choose. If there are inconsistencies in two pr= otocols, there are going to be loops even when they use same SRGB. Keeping = different labels makes it easier to troubleshoot. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_D1E03BC62CDCBpsarkarjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <31B3D0E55761244484879058F15FEDCE@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
    Hi Acee,

    From: "Acee Lindem (acee)"= ; <acee@cisco.com>
    Date: Thursday, July 30, 2015 at 8:= 37 PM
    To: Pushpasis Sarkar <psarkar@juniper.net>
    Cc: Shraddha Hegde <shraddha@juniper.net>, "Les Ginsber= g (ginsberg)" <ginsberg@cisco= .com>, Robert Raszuk <robert= @raszuk.net>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com>, S= tephane Litkowski <step= hane.litkowski@orange.com>, "spring@ietf.org" <spring@ietf.org>, Uma Chundu= ri <uma.chunduri@ericsson.c= om>, Hannes Gredler <hannes= @juniper.net>
    Subject: Re: [spring] Modeling SRGB= configuration for draft-ietf-spring-sr-yang

    Hi Pushpasis, 

    On Jul 30, 2015, at 10:54 AM, Pushpasis Sarkar <psarkar@juniper.net> wrot= e:

    Hi Acee,

    From: "Acee Lindem = (acee)" <acee@cisco.co= m>
    Date: Thursday, July 30,= 2015 at 7:18 PM
    To: Pushpasis Sarkar <= ;psarkar@juniper.net&= gt;
    Cc: Shraddha Hegde <<= a href=3D"mailto:shraddha@juniper.net" class=3D"">shraddha@juniper.net&= gt;, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Robert Raszuk <robert@raszuk.net>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com= >, Stephane Litkowski <stephane.litkowski@orange.com>, "spring@ietf.org" <spring@ietf.org>,= Uma Chunduri <u= ma.chunduri@ericsson.com>, Hannes Gredler <hannes@juniper.net>
    Subject: Re: [spring] Mo= deling SRGB configuration for draft-ietf-spring-sr-yang

    Robert, Pushpasis, Shraddha, 

    I guess I don’t understand why this gives you any operational advanta= ge when you are migrating between protocol (e.g., from IS-IS to OSPF ;^). I= n fact, if you are using separate label spaces it will make migration more = difficult and you will have to migrate your routing domain in shot rather than incrementally. 
    [Pushpasis= ] All routers will program both transit mpls labels and create two parallel= MPLS data planes well before the last step when all the ingress router wil= l be instructed to switch traffic onto the new MPLS data plane (programmed by the new protocol) by changing the admin= distance. That way the migration shall become seamless. And then once all = ingreess routers has been swicthed to the new protocol and new MPLS datapla= ne, the old protocol and old MPLS data plane can be just removed from all the routers. Hope it is clear now&= #8230; 

    Normally only the protocol with the lower preference or admin distance= would install a route to a particular prefix (including the label) into th= e RIB/LIB for the base IP unicast topology. I guess you are envisioning sep= arate RIBs per protocol as well? 
    [Pushpasis] What you are saying is true for= the IP/V6—>MPLS route in RIB/FIB on ingress routers. It is NOT TR= UE for MPLS transit routes in LFIB. In MPLS architecture no two protocols i= nstalls the same label in LFIB. Each protocol (LDP/RSVP) uses different transit labels for the same destination IP/V6 FE= C.


    Thanks,
    Acee





    Thanks,
    Acee

    On Jul 30, 2015, at 3:11 AM, Pushpasis Sarkar <psarkar@juniper.net> wrot= e:

    +1

    From: Shraddha Hegde <= ;shraddha@juniper.net>
    Date: Thursday, July 30,= 2015 at 8:58 AM
    To: "Les Ginsberg (= ginsberg)" <    ginsbe= rg@cisco.com>, Robert Raszuk <robert@raszuk.net>
    Cc: "stephane.litkowski@orange.com= " <= stephane.litkowski@orange.com>, Uma Chunduri <uma.chunduri@ericsson.com>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com= >, "spring@ietf.o= rg" <spring@ietf.= org>, Pushpasis Sarkar <psa= rkar@juniper.net>, Hannes Gredler <hannes@juniper.net>
    Subject: RE: [spring] Mo= deling SRGB configuration for draft-ietf-spring-sr-yang

    &nb= sp;
    [Shraddha] route pr= eference is local to router and the neighbor never knows what the other is = going to choose.  If there are inconsistencies in two protocols, there are going to be loops even when they use same SRGB= . Keeping different labels makes it easier to troubleshoot.=
       &= nbsp;           &nbs= p;    
    _______________________________________________
    spring mailing list
    spring@ietf.org
    https:/= /www.ietf.org/mailman/listinfo/spring


     --_000_D1E03BC62CDCBpsarkarjunipernet_-- From nobody Thu Jul 30 09:14:04 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FCBF1B2E66 for ; Thu, 30 Jul 2015 09:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2VB1XbMlZlj for ; Thu, 30 Jul 2015 09:13:59 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 595161B2E6F for ; Thu, 30 Jul 2015 09:13:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20782; q=dns/txt; s=iport; t=1438272839; x=1439482439; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=heHPcqvXpcYidDbn6cxydW67/VXEmVBfUAn6UN9MStQ=; b=JOmNrvP0bNzg0LGmB0T30NgXN5Pa6bS+4A7Pf+GRvifPlCxVKHdZUnCI bf4s80qipReWBuC5ik5EqDRTilsbaTft5OpJ6uzQxwFbpq8SP0Yy8GXlB X3tJwXwb8WwE/hSVh+g0pecRI0avvFgEALqL7D25E8k38uyPKuWrT0D0G Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AzAwBSTLpV/4YNJK1aAYJNTVRpBrwYCYF5AQmFL0oCgTw4FAEBAQEBAQGBCoQjAQEBBAEBAWsLEAIBCA4DAQIBAhoCDAcnCxQDBggCBA4FiC4NzwoBAQEBAQEBAQEBAQEBAQEBAQEBAQETBItOhHYNBAYBKAGCb4EUBZFigxUBjEiBR4gji2uDZCaDfW+BSIEEAQEB X-IronPort-AV: E=Sophos;i="5.15,577,1432598400"; d="scan'208,217";a="173475954" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP; 30 Jul 2015 16:13:58 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t6UGDwjj024123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 30 Jul 2015 16:13:58 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.37]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Thu, 30 Jul 2015 11:13:58 -0500 From: "Acee Lindem (acee)" To: Pushpasis Sarkar Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQyteht1/pu5o+G0mFGfbARvh5zZ30cPuAgAABSgCAABFUgA== Date: Thu, 30 Jul 2015 16:13:57 +0000 Message-ID: References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <66B97186-1749-418C-A4BB-7E85BB72DB11@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.204] Content-Type: multipart/alternative; boundary="_000_C7B66BBFFB1341E18CD93209CD34EFD9ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Les Ginsberg \(ginsberg\)" , "spring@ietf.org" , Robert Raszuk , Stephane Litkowski , Shraddha Hegde , Uma Chunduri , "Aissaoui, Mustapha \(Mustapha\)" , Hannes Gredler Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 30 Jul 2015 16:14:02 -0000 --_000_C7B66BBFFB1341E18CD93209CD34EFD9ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Pushpasis, On Jul 30, 2015, at 11:11 AM, Pushpasis Sarkar > wrote: Hi Acee, From: "Acee Lindem (acee)" > Date: Thursday, July 30, 2015 at 8:37 PM To: Pushpasis Sarkar > Cc: Shraddha Hegde >, "Le= s Ginsberg (ginsberg)" >, Rob= ert Raszuk >, "Aissaoui, Mustap= ha (Mustapha)" >, Stephane Litkowski >, "spring@ietf.org" >, Uma Chunduri >, Hannes Gredler > Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi Pushpasis, On Jul 30, 2015, at 10:54 AM, Pushpasis Sarkar > wrote: Hi Acee, From: "Acee Lindem (acee)" > Date: Thursday, July 30, 2015 at 7:18 PM To: Pushpasis Sarkar > Cc: Shraddha Hegde >, "Le= s Ginsberg (ginsberg)" >, Rob= ert Raszuk >, "Aissaoui, Mustap= ha (Mustapha)" >, Stephane Litkowski >, "spring@ietf.org" >, Uma Chunduri >, Hannes Gredler > Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Robert, Pushpasis, Shraddha, I guess I don=92t understand why this gives you any operational advantage w= hen you are migrating between protocol (e.g., from IS-IS to OSPF ;^). In fa= ct, if you are using separate label spaces it will make migration more diff= icult and you will have to migrate your routing domain in shot rather than = incrementally. [Pushpasis] All routers will program both transit mpls labels and create tw= o parallel MPLS data planes well before the last step when all the ingress = router will be instructed to switch traffic onto the new MPLS data plane (p= rogrammed by the new protocol) by changing the admin distance. That way the= migration shall become seamless. And then once all ingreess routers has be= en swicthed to the new protocol and new MPLS dataplane, the old protocol an= d old MPLS data plane can be just removed from all the routers. Hope it is = clear now=85 Normally only the protocol with the lower preference or admin distance woul= d install a route to a particular prefix (including the label) into the RIB= /LIB for the base IP unicast topology. I guess you are envisioning separate= RIBs per protocol as well? [Pushpasis] What you are saying is true for the IP/V6=97>MPLS route in RIB/= FIB on ingress routers. It is NOT TRUE for MPLS transit routes in LFIB. In = MPLS architecture no two protocols installs the same label in LFIB. Each pr= otocol (LDP/RSVP) uses different transit labels for the same destination IP= /V6 FEC. That is one way to implement it but it makes more sense for the IGP label i= mposition and label stitching to both be dependent on the route being prefe= rred. However, in another conversation I have been convinced that the network con= solidation use case could benefit from configuration of per-protocol SRGB s= o I=92m no longer opposed to this being a feature of the YANG model. Thanks, Acee Thanks, Acee Thanks, Acee On Jul 30, 2015, at 3:11 AM, Pushpasis Sarkar > wrote: +1 From: Shraddha Hegde > Date: Thursday, July 30, 2015 at 8:58 AM To: "Les Ginsberg (ginsberg)" >, Robert Raszuk > Cc: "stephane.litkowski@orange.com" <= stephane.litkowski@orange.com>, Uma C= hunduri >, "Ais= saoui, Mustapha (Mustapha)" >, "spring@ietf.org" >, Pushpasis Sarkar >, Hannes Gredler > Subject: RE: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang [Shraddha] route preference is local to router and the neighbor never knows= what the other is going to choose. If there are inconsistencies in two pr= otocols, there are going to be loops even when they use same SRGB. Keeping = different labels makes it easier to troubleshoot. _______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring --_000_C7B66BBFFB1341E18CD93209CD34EFD9ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <1F85D9C23C4C974781DFD4AC551EC4D9@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi Pushpasis,

    On Jul 30, 2015, at 11:11 AM, Pushpasis Sarkar <psarkar@juniper.net> wrot= e:

    Hi Acee,

    From: "Acee Lindem = (acee)" <acee@cisco.co= m>
    Date: Thursday, July 30,= 2015 at 8:37 PM
    To: Pushpasis Sarkar <= ;psarkar@juniper.net&= gt;
    Cc: Shraddha Hegde <<= a href=3D"mailto:shraddha@juniper.net" class=3D"">shraddha@juniper.net&= gt;, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Robert Raszuk <robert@raszuk.net>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com= >, Stephane Litkowski <stephane.litkowski@orange.com>, "spring@ietf.org" <spring@ietf.org>,= Uma Chunduri <u= ma.chunduri@ericsson.com>, Hannes Gredler <hannes@juniper.net>
    Subject: Re: [spring] Mo= deling SRGB configuration for draft-ietf-spring-sr-yang

    Hi Pushpasis, 

    On Jul 30, 2015, at 10:54 AM, Pushpasis Sarkar <psarkar@juniper.net> wrot= e:

    Hi Acee,

    From: "Acee Lindem = (acee)" <acee@cisco.co= m>
    Date: Thursday, July 30,= 2015 at 7:18 PM
    To: Pushpasis Sarkar <= ;psarkar@juniper.net&= gt;
    Cc: Shraddha Hegde <<= a href=3D"mailto:shraddha@juniper.net" class=3D"">shraddha@juniper.net&= gt;, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Robert Raszuk <robert@raszuk.net>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com= >, Stephane Litkowski <stephane.litkowski@orange.com>, "spring@ietf.org" <spring@ietf.org>,= Uma Chunduri <u= ma.chunduri@ericsson.com>, Hannes Gredler <hannes@juniper.net>
    Subject: Re: [spring] Mo= deling SRGB configuration for draft-ietf-spring-sr-yang

    Robert, Pushpasis, Shraddha, 

    I guess I don=92t understand why this gives you any operational advantage w= hen you are migrating between protocol (e.g., from IS-IS to OSPF ;^). In fa= ct, if you are using separate label spaces it will make migration more diff= icult and you will have to migrate your routing domain in shot rather than incrementally. 
    [Pushpasis= ] All routers will program both transit mpls labels and create two parallel= MPLS data planes well before the last step when all the ingress router wil= l be instructed to switch traffic onto the new MPLS data plane (programmed by the new protocol) by changing the admin= distance. That way the migration shall become seamless. And then once all = ingreess routers has been swicthed to the new protocol and new MPLS datapla= ne, the old protocol and old MPLS data plane can be just removed from all the routers. Hope it is clear now= =85 

    Normally only the protocol with the lower preference or adm= in distance would install a route to a particular prefix (including the lab= el) into the RIB/LIB for the base IP unicast topology. I guess you are envi= sioning separate RIBs per protocol as well? 
    [Pushpasis= ] What you are saying is true for the IP/V6=97>MPLS route in RIB/FIB on = ingress routers. It is NOT TRUE for MPLS transit routes in LFIB. In MPLS ar= chitecture no two protocols installs the same label in LFIB. Each protocol (LDP/RSVP) uses different transit labels for = the same destination IP/V6 FEC.

    That is one way to implement it but it makes more sense for the IGP la= bel imposition and label stitching to both be dependent on the route being = preferred. 
    However, in another conversation I have been convinced that the networ= k consolidation use case could benefit from configuration of per-protocol S= RGB so I=92m no longer opposed to this being a feature of the YANG model.&n= bsp;

    Thanks,
    Acee 





    Thanks,
    Acee





    Thanks,
    Acee

    On Jul 30, 2015, at 3:11 AM, Pushpasis Sarkar <psarkar@juniper.net> wrot= e:

    +1

    From: Shraddha Hegde <= ;shraddha@juniper.net>
    Date: Thursday, July 30,= 2015 at 8:58 AM
    To: "Les Ginsberg (= ginsberg)" <    ginsbe= rg@cisco.com>, Robert Raszuk <robert@raszuk.net>
    Cc: "stephane.litkowski@orange.com= " <= stephane.litkowski@orange.com>, Uma Chunduri <uma.chunduri@ericsson.com>, "Aissaoui, Mustapha (Mustapha)" <mustapha.aissaoui@alcatel-lucent.com= >, "spring@ietf.o= rg" <spring@ietf.= org>, Pushpasis Sarkar <psa= rkar@juniper.net>, Hannes Gredler <hannes@juniper.net>
    Subject: RE: [spring] Mo= deling SRGB configuration for draft-ietf-spring-sr-yang

    &nb= sp;
    [Shraddha] route pr= eference is local to router and the neighbor never knows what the other is = going to choose.  If there are inconsistencies in two protocols, there are going to be loops even when they use same SRGB= . Keeping different labels makes it easier to troubleshoot.=
       &= nbsp;           &nbs= p;    
    _______________________________________________
    spring mailing list
    spring@ietf.org
    https:/= /www.ietf.org/mailman/listinfo/spring



    --_000_C7B66BBFFB1341E18CD93209CD34EFD9ciscocom_-- From nobody Thu Jul 30 22:33:14 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 279121B3103; Thu, 30 Jul 2015 22:33:14 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2KACm7gis-Vt; Thu, 30 Jul 2015 22:33:12 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0772.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::772]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C77711B30FF; Thu, 30 Jul 2015 22:33:11 -0700 (PDT) Received: from BLUPR05MB1969.namprd05.prod.outlook.com (10.162.224.23) by BLUPR05MB1970.namprd05.prod.outlook.com (10.162.224.24) with Microsoft SMTP Server (TLS) id 15.1.225.19; Fri, 31 Jul 2015 05:32:50 +0000 Received: from BLUPR05MB1969.namprd05.prod.outlook.com ([10.162.224.23]) by BLUPR05MB1969.namprd05.prod.outlook.com ([10.162.224.23]) with mapi id 15.01.0225.018; Fri, 31 Jul 2015 05:32:50 +0000 From: Pushpasis Sarkar To: "spring@ietf.org" Thread-Topic: [spring] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop Thread-Index: AQHQy1JWsuq8rfCdN0ClisLMXwUbzw== Date: Fri, 31 Jul 2015 05:32:49 +0000 Message-ID: References: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> In-Reply-To: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.184.14] x-microsoft-exchange-diagnostics: 1; BLUPR05MB1970; 5:HW+2WyIBR89eqCtJXdN+/dafKTcVnebUckaU1xdGUsmEnzmBiNerHtDIMfxBiEOxGbtNwwkIMXJ0xs3rcO0gaVrY+gNGeeH2bP6Oy6PzkaIyTbjsao98Moh+oFsg6Zr8NvtwQD/Bxza4xi7rnqMopg==; 24:jt1284dtcbP7BLx82RnWCCReYx3Nll1Tzxduo93hxL+WkkaGxK2qNAtq1qPFOypagdeoFKkDWn747j1nuH+cQeM3WxqBLfm3Dhy9hTXtfLI=; 20:rxcPofPvxorAYvG5Ad+1U7jzIES30khFnm9BD9mJ86/m0eKuQVUtHAdAif3NQUZkBldtgEPxZA+Bj+0MSqFYNw== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB1970; blupr05mb1970: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB1970; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1970; x-forefront-prvs: 0654257CF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(24454002)(164054003)(479174004)(2900100001)(19580405001)(83506001)(15975445007)(66066001)(62966003)(2656002)(2501003)(40100003)(122556002)(450100001)(189998001)(46102003)(230783001)(2950100001)(92566002)(36756003)(86362001)(102836002)(106116001)(77156002)(5002640100001)(19580395003)(50986999)(77096005)(99286002)(76176999)(87936001)(2351001)(110136002)(4001350100001)(5001960100002)(54356999); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1970; H:BLUPR05MB1969.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <3145DBA52EDAB24B87B4C800E6B28DF0@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2015 05:32:50.0429 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1970 Archived-At: Cc: "mpls@ietf.org" Subject: Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2015 05:33:14 -0000 Support. On 7/22/15, 3:17 PM, "spring on behalf of John G.Scudder" wrote: >Dear WG, > >As we discussed at our meeting yesterday, working group adoption has been >requested for draft-filsfils-spring-segment-routing-ldp-interop. Please >reply to the list with your comments, including although not limited to >whether or not you support adoption. Non-authors are especially >encouraged to comment. > >In consideration of the fact that a number of WG calls are going on >concurrently, we will end the call on August 31, 2015. > >Authors, please indicate whether you are aware of any relevant IPR and if >so, whether it has been disclosed. Also, the length of the author list >for this document greatly exceeds the maximum recommended. Assuming the >document is adopted, the authors should be prepared to correct this when >submitting as a WG document, ideally by reducing the list to simply the >active editor(s) and making use of the "contributors" section for the >full list. > >Thanks, > >--Bruno and John > >P.S.: Cc MPLS owing to the LDP connection. Please respect the reply-to. >_______________________________________________ >spring mailing list >spring@ietf.org >https://www.ietf.org/mailman/listinfo/spring From nobody Thu Jul 30 22:37:45 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7A8E1B30FF for ; Thu, 30 Jul 2015 22:37:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrNhl6_BbDKw for ; Thu, 30 Jul 2015 22:37:41 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0766.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::766]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 161D41A0354 for ; Thu, 30 Jul 2015 22:37:40 -0700 (PDT) Received: from BLUPR05MB1969.namprd05.prod.outlook.com (10.162.224.23) by BLUPR05MB1970.namprd05.prod.outlook.com (10.162.224.24) with Microsoft SMTP Server (TLS) id 15.1.225.19; Fri, 31 Jul 2015 05:37:19 +0000 Received: from BLUPR05MB1969.namprd05.prod.outlook.com ([10.162.224.23]) by BLUPR05MB1969.namprd05.prod.outlook.com ([10.162.224.23]) with mapi id 15.01.0225.018; Fri, 31 Jul 2015 05:37:18 +0000 From: Pushpasis Sarkar To: "stephane.litkowski@orange.com" , "spring@ietf.org" Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQy1L267E4kyrrfEmvSG249Y6sDA== Date: Fri, 31 Jul 2015 05:37:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 authentication-results: orange.com; dkim=none (message not signed) header.d=none; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [116.197.184.14] x-microsoft-exchange-diagnostics: 1; BLUPR05MB1970; 5:x/R1V4iZGoap5W9Gd9ofVYcqpfLu3J/sg2kPNmC/q3CD3i662+//zq9uvD2lj2L8K/gIVnpsa8TVEcTKkX1pdEHIYSIqTQ5FtyN1W6idjaAGGKJ0kS2cEJRBCy+dg9VCZ0oAmr15gAD1vPdnrDJ8PQ==; 24:7iylvMXcV5GgPbNU0+hCb9Xp+u/71zlbcBzOk3BvHsBs7CXdMpzBdjcQqm2N37JIEax9N/Njkohu/6GNkYfq/pzgWi8LRDY4xrnm6gDmHgA=; 20:FWQHtLyye5Qu3hKLPAlNdOthVk9RwQNsztEt28MuxyubMZkVSGWUJlAdnQQO7EXTxKWYXHz5Oo4J7Nd+2jJnmA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB1970; blupr05mb1970: X-MS-Exchange-Organization-RulesExecuted x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(108003899814671); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BLUPR05MB1970; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB1970; x-forefront-prvs: 0654257CF5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(2900100001)(19580405001)(83506001)(15975445007)(66066001)(19625215002)(62966003)(2656002)(2501003)(17760045003)(5001770100001)(19300405004)(561944003)(5890100001)(40100003)(122556002)(189998001)(18206015028)(46102003)(230783001)(99936001)(19617315012)(92566002)(36756003)(86362001)(102836002)(106116001)(77156002)(5002640100001)(19580395003)(50986999)(16236675004)(77096005)(107886002)(19618635001)(99286002)(87936001)(19627595001)(4001350100001)(5001960100002)(54356999)(7099028); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB1970; H:BLUPR05MB1969.namprd05.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: multipart/mixed; boundary="_004_D1E106ED2CE4Cpsarkarjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jul 2015 05:37:18.5381 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB1970 Archived-At: Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2015 05:37:44 -0000 --_004_D1E106ED2CE4Cpsarkarjunipernet_ Content-Type: multipart/alternative; boundary="_000_D1E106ED2CE4Cpsarkarjunipernet_" --_000_D1E106ED2CE4Cpsarkarjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My strong preference is Option 2. It simplifies migration and network conso= lidation usecases. Also it is very relevant in MSDC kind of use cases where= a single node can be part of two different topologies running two differen= t SR protocol. Index-management becomes much easier in each of the usecases= . From: spring > on b= ehalf of "stephane.litkowski@orange.com" > Date: Wednesday, July 22, 2015 at 10:49 PM To: "spring@ietf.org" > Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi WG, In the current version of the config Yang model for SR, the SRGB list is co= nfigured at SR top level, so it is agnostic to the routing protocol. We had some comment in Dallas on difficulties that having common label rang= e shared between protocols could lead to. During discussion in our design team, some point was also raised on routing= protocol migrations that may be safer using a per protocol SRGB (so config= uration the SRGB at IGP level rather than globally). We would like to hear from the WG about the preference and arguments for bo= th approaches : Approach 1) keep SRGB configuration at top level, and so routing protocols = will share the same label space (today proposal) Approach 2) move SRGB configuration to protocols, each routing protocol man= ages its own label space. Thanks to provide your feedback in order to solve this issue and have a con= sensus. [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 mobile: +33 6 37 86 97 52 stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ 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_D1E106ED2CE4Cpsarkarjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
    My strong preference is Option 2. It simplifies migration and network = consolidation usecases. Also it is very relevant in MSDC kind of use cases = where a single node can be part of two different topologies running two dif= ferent SR protocol. Index-management becomes much easier in each of the usecases.

    From: spring <spring-bounces@ietf.org> on behalf of "= ;stephane.litkowski@orange= .com" <stephan= e.litkowski@orange.com>
    Date: Wednesday, July 22, 2015 at 1= 0:49 PM
    To: "spring@ietf.org" <= spring@ietf.org>
    Subject: [spring] Modeling SRGB con= figuration for draft-ietf-spring-sr-yang

    Hi WG,

     

    In the current version of the config Yang model for = SR, the SRGB list is configured at SR top level, so it is agnostic to the r= outing protocol.

    We had some comment in Dallas on difficulties that h= aving common label range shared between protocols could lead to.=

    During discussion in our design team, some point was= also raised on routing protocol migrations that may be safer using a per p= rotocol SRGB (so configuration the SRGB at IGP level rather than globally).=

     

    We would like to hear from the WG about the preferen= ce and arguments for both approaches :

    Approach 1) keep SRGB configuration at top level, an= d so routing protocols will share the same label space (today proposal)

    Approach 2) move SRGB configuration to protocols, ea= ch routing protocol manages its own label space.

     

    Thanks to provide your feedback in order to solve th= is issue and have a consensus.

     

     

    3D"Orange

     

    Stephane Litkowski
    Network Architect
    Orange/SCE/EQUANT/IBNF/ENDD/NDE

    Orange Expert Future Networks=

    phone: +33 2 23 28 49 83
    mobile: +33 6 37 86 97 52
    stephane.litkowski@orange.com

     

     

    ______________________________________________________________________=
___________________________________________________

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_D1E106ED2CE4Cpsarkarjunipernet_-- --_004_D1E106ED2CE4Cpsarkarjunipernet_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: attachment; filename="image001.gif"; size=381; creation-date="Fri, 31 Jul 2015 05:37:18 GMT"; modification-date="Fri, 31 Jul 2015 05:37:18 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhKAAoAMQAAP+MQP+zgP/17//s3/+DMP/iz/+fYP+8j/9wEP95IP/Gn/+WUP/Pr/+pcP/Z v/////9mAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAoACgAAAX6oAONZGmeaEqKauum7Cu/8Wyj9a2P+X73vhkwSCPuhkYVMolj2pbOEjTK oxatrSlVG+U6vUxwUmwkE81BtE99xGbdSjhMPgo4BAoA+wUICAR6IwQODwMNEAcOigAFhQYQDgoD DwcQBJOKBIOFDQmaCCyTB416hQcBBQuTEA8Cow8EBQINpHcGhAkrEAkPChAAD3YPCLuSDw+sIgEP wCILzK0OjY9VBJS/wYQjfwaNyRDLzRAG0AMB5wC6ENyEt8jWDAsCyA/KzJN+zLILqLlVv/OuaYPU alU9cMwuPSCl8AEDYv8EQbwRgAEABcziJFl2bMmeEQgATEwRAgA7 --_004_D1E106ED2CE4Cpsarkarjunipernet_-- From nobody Thu Jul 30 22:44:51 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C0271B311D for ; Thu, 30 Jul 2015 22:44:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.909 X-Spam-Level: X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i81P9XVOTGNR for ; Thu, 30 Jul 2015 22:44:48 -0700 (PDT) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 A2AFE1B3112 for ; Thu, 30 Jul 2015 22:44:47 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id ADACD4EDA9300; Fri, 31 Jul 2015 05:44:42 +0000 (GMT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t6V5iiiN013816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Jul 2015 07:44:44 +0200 Received: from FR711WXCHMBA07.zeu.alcatel-lucent.com ([169.254.3.17]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Fri, 31 Jul 2015 07:44:43 +0200 From: "Henderickx, Wim (Wim)" To: Pushpasis Sarkar , "stephane.litkowski@orange.com" , "spring@ietf.org" Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQy1P/4HBS3W1kW0Or83TkyIB7iA== Date: Fri, 31 Jul 2015 05:44:42 +0000 Message-ID: <518ACD7C-B1EF-4C03-A2C4-4220D4FD87B7@alcatel-lucent.com> References: In-Reply-To: Accept-Language: nl-BE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.150724 x-originating-ip: [135.239.27.39] Content-Type: multipart/mixed; boundary="_004_518ACD7CB1EF4C03A2C44220D4FD87B7alcatellucentcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2015 05:44:50 -0000 --_004_518ACD7CB1EF4C03A2C44220D4FD87B7alcatellucentcom_ Content-Type: multipart/alternative; boundary="_000_518ACD7CB1EF4C03A2C44220D4FD87B7alcatellucentcom_" --_000_518ACD7CB1EF4C03A2C44220D4FD87B7alcatellucentcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0ZW5kIHRvIGFncmVlIHRoYXQgcHJvcG9zYWwgMiBpcyBmb3IgbWlncmF0aW9uLCBzbyB3b3Vs ZCB2b3RlIGZvciBvcHRpb24gMi4NCg0KRnJvbTogc3ByaW5nIG9uIGJlaGFsZiBvZiBQdXNocGFz aXMgU2Fya2FyDQpEYXRlOiBGcmlkYXkgMzEgSnVseSAyMDE1IDA3OjM3DQpUbzogU3RlcGhhbmUg TGl0a293c2tpLCAic3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+Ig0KU3Vi amVjdDogUmU6IFtzcHJpbmddIE1vZGVsaW5nIFNSR0IgY29uZmlndXJhdGlvbiBmb3IgZHJhZnQt aWV0Zi1zcHJpbmctc3IteWFuZw0KDQpNeSBzdHJvbmcgcHJlZmVyZW5jZSBpcyBPcHRpb24gMi4g SXQgc2ltcGxpZmllcyBtaWdyYXRpb24gYW5kIG5ldHdvcmsgY29uc29saWRhdGlvbiB1c2VjYXNl cy4gQWxzbyBpdCBpcyB2ZXJ5IHJlbGV2YW50IGluIE1TREMga2luZCBvZiB1c2UgY2FzZXMgd2hl cmUgYSBzaW5nbGUgbm9kZSBjYW4gYmUgcGFydCBvZiB0d28gZGlmZmVyZW50IHRvcG9sb2dpZXMg cnVubmluZyB0d28gZGlmZmVyZW50IFNSIHByb3RvY29sLiBJbmRleC1tYW5hZ2VtZW50IGJlY29t ZXMgbXVjaCBlYXNpZXIgaW4gZWFjaCBvZiB0aGUgdXNlY2FzZXMuDQoNCkZyb206IHNwcmluZyA8 c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPj4g b24gYmVoYWxmIG9mICJzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTxtYWlsdG86c3RlcGhh bmUubGl0a293c2tpQG9yYW5nZS5jb20+IiA8c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208 bWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPj4NCkRhdGU6IFdlZG5lc2RheSwg SnVseSAyMiwgMjAxNSBhdCAxMDo0OSBQTQ0KVG86ICJzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNw cmluZ0BpZXRmLm9yZz4iIDxzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4+ DQpTdWJqZWN0OiBbc3ByaW5nXSBNb2RlbGluZyBTUkdCIGNvbmZpZ3VyYXRpb24gZm9yIGRyYWZ0 LWlldGYtc3ByaW5nLXNyLXlhbmcNCg0KSGkgV0csDQoNCkluIHRoZSBjdXJyZW50IHZlcnNpb24g b2YgdGhlIGNvbmZpZyBZYW5nIG1vZGVsIGZvciBTUiwgdGhlIFNSR0IgbGlzdCBpcyBjb25maWd1 cmVkIGF0IFNSIHRvcCBsZXZlbCwgc28gaXQgaXMgYWdub3N0aWMgdG8gdGhlIHJvdXRpbmcgcHJv dG9jb2wuDQpXZSBoYWQgc29tZSBjb21tZW50IGluIERhbGxhcyBvbiBkaWZmaWN1bHRpZXMgdGhh dCBoYXZpbmcgY29tbW9uIGxhYmVsIHJhbmdlIHNoYXJlZCBiZXR3ZWVuIHByb3RvY29scyBjb3Vs ZCBsZWFkIHRvLg0KRHVyaW5nIGRpc2N1c3Npb24gaW4gb3VyIGRlc2lnbiB0ZWFtLCBzb21lIHBv aW50IHdhcyBhbHNvIHJhaXNlZCBvbiByb3V0aW5nIHByb3RvY29sIG1pZ3JhdGlvbnMgdGhhdCBt YXkgYmUgc2FmZXIgdXNpbmcgYSBwZXIgcHJvdG9jb2wgU1JHQiAoc28gY29uZmlndXJhdGlvbiB0 aGUgU1JHQiBhdCBJR1AgbGV2ZWwgcmF0aGVyIHRoYW4gZ2xvYmFsbHkpLg0KDQpXZSB3b3VsZCBs aWtlIHRvIGhlYXIgZnJvbSB0aGUgV0cgYWJvdXQgdGhlIHByZWZlcmVuY2UgYW5kIGFyZ3VtZW50 cyBmb3IgYm90aCBhcHByb2FjaGVzIDoNCkFwcHJvYWNoIDEpIGtlZXAgU1JHQiBjb25maWd1cmF0 aW9uIGF0IHRvcCBsZXZlbCwgYW5kIHNvIHJvdXRpbmcgcHJvdG9jb2xzIHdpbGwgc2hhcmUgdGhl IHNhbWUgbGFiZWwgc3BhY2UgKHRvZGF5IHByb3Bvc2FsKQ0KQXBwcm9hY2ggMikgbW92ZSBTUkdC IGNvbmZpZ3VyYXRpb24gdG8gcHJvdG9jb2xzLCBlYWNoIHJvdXRpbmcgcHJvdG9jb2wgbWFuYWdl cyBpdHMgb3duIGxhYmVsIHNwYWNlLg0KDQpUaGFua3MgdG8gcHJvdmlkZSB5b3VyIGZlZWRiYWNr IGluIG9yZGVyIHRvIHNvbHZlIHRoaXMgaXNzdWUgYW5kIGhhdmUgYSBjb25zZW5zdXMuDQoNCg0K W09yYW5nZSBsb2dvXTxodHRwOi8vd3d3Lm9yYW5nZS5jb20vPg0KDQpTdGVwaGFuZSBMaXRrb3dz a2kNCk5ldHdvcmsgQXJjaGl0ZWN0DQpPcmFuZ2UvU0NFL0VRVUFOVC9JQk5GL0VOREQvTkRFDQpP cmFuZ2UgRXhwZXJ0IEZ1dHVyZSBOZXR3b3Jrcw0KcGhvbmU6ICszMyAyIDIzIDI4IDQ5IDgzIDxo dHRwczovL21vbnNpLnNzby5mcmFuY2V0ZWxlY29tLmZyL2luZGV4LmFzcD90YXJnZXQ9aHR0cCUz QSUyRiUyRmNsaWN2b2ljZS5zc28uZnJhbmNldGVsZWNvbS5mciUyRkNsaWN2b2ljZVYyJTJGVG9v bEJhci5kbyUzRmFjdGlvbiUzRGRlZmF1bHQlMjZyb290c2VydmljZSUzRFNJR05BVFVSRSUyNnRv JTNEKzMzJTIwMiUyMDIzJTIwMjglMjA0OSUyMDgzJTIwPg0KbW9iaWxlOiArMzMgNiAzNyA4NiA5 NyA1MiA8aHR0cHM6Ly9tb25zaS5zc28uZnJhbmNldGVsZWNvbS5mci9pbmRleC5hc3A/dGFyZ2V0 PWh0dHAlM0ElMkYlMkZjbGljdm9pY2Uuc3NvLmZyYW5jZXRlbGVjb20uZnIlMkZDbGljdm9pY2VW MiUyRlRvb2xCYXIuZG8lM0ZhY3Rpb24lM0RkZWZhdWx0JTI2cm9vdHNlcnZpY2UlM0RTSUdOQVRV UkUlMjZ0byUzRCszMyUyMDYlMjAzNyUyMDg2JTIwOTclMjA1MiUyMD4NCnN0ZXBoYW5lLmxpdGtv d3NraUBvcmFuZ2UuY29tPG1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbT4NCg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBj b250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg ZXQgbmUgZG9pdmVudCBkb25jDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGll cyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJy ZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg YWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJl c3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNp ZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRh aW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJv dGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBl bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBt ZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9y YW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwg Y2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCg== --_000_518ACD7CB1EF4C03A2C44220D4FD87B7alcatellucentcom_ Content-Type: text/html; charset="utf-8" Content-ID: <461F261C6501AB4488592DDBBCA093C8@exchange.lucent.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj4NCjxkaXY+DQo8 ZGl2PkkgdGVuZCB0byBhZ3JlZSB0aGF0IHByb3Bvc2FsIDIgaXMgZm9yIG1pZ3JhdGlvbiwgc28g d291bGQgdm90ZSBmb3Igb3B0aW9uIDIuPC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iTUFDX09VVExP T0tfU0lHTkFUVVJFIj48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9u dC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjEycHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6 YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5v bmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hU OiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1 bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5Gcm9tOiA8L3NwYW4+c3ByaW5nIG9uIGJlaGFsZiBvZiBQdXNocGFzaXMgU2Fya2FyPGJyPg0K PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5GcmlkYXkgMzEgSnVs eSAyMDE1IDA3OjM3PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3Nw YW4+U3RlcGhhbmUgTGl0a293c2tpLCAmcXVvdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYu b3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+JnF1b3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW3NwcmluZ10gTW9kZWxpbmcgU1JHQiBjb25m aWd1cmF0aW9uIGZvciBkcmFmdC1pZXRmLXNwcmluZy1zci15YW5nPGJyPg0KPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5 OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+DQo8ZGl2Pk15IHN0cm9uZyBwcmVmZXJlbmNlIGlzIE9w dGlvbiAyLiBJdCBzaW1wbGlmaWVzIG1pZ3JhdGlvbiBhbmQgbmV0d29yayBjb25zb2xpZGF0aW9u IHVzZWNhc2VzLiBBbHNvIGl0IGlzIHZlcnkgcmVsZXZhbnQgaW4gTVNEQyBraW5kIG9mIHVzZSBj YXNlcyB3aGVyZSBhIHNpbmdsZSBub2RlIGNhbiBiZSBwYXJ0IG9mIHR3byBkaWZmZXJlbnQgdG9w b2xvZ2llcyBydW5uaW5nIHR3byBkaWZmZXJlbnQgU1IgcHJvdG9jb2wuIEluZGV4LW1hbmFnZW1l bnQNCiBiZWNvbWVzIG11Y2ggZWFzaWVyIGluIGVhY2ggb2YgdGhlIHVzZWNhc2VzLjwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2 IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjps ZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZU OiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBB RERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1S SUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQt d2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5zcHJpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJp bmctYm91bmNlc0BpZXRmLm9yZyI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBi ZWhhbGYgb2YgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2Uu Y29tIj5zdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSI+c3RlcGhhbmUubGl0a293c2tp QG9yYW5nZS5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5E YXRlOiA8L3NwYW4+V2VkbmVzZGF5LCBKdWx5IDIyLCAyMDE1IGF0IDEwOjQ5IFBNPGJyPg0KPHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7PGEgaHJlZj0ibWFp bHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYub3JnPC9hPiZndDs8YnI+DQo8 c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPltzcHJpbmddIE1v ZGVsaW5nIFNSR0IgY29uZmlndXJhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFuZzxi cj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXYgeG1sbnM6dj0idXJuOnNjaGVtYXMt bWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29y ZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9v bW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8bWV0YSBuYW1l PSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE0IChmaWx0ZXJlZCBtZWRpdW0p Ij4NCjwhLS1baWYgIW1zb10+PHN0eWxlPnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwp O30NCm9cOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVy bCgjZGVmYXVsdCNWTUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0K PC9zdHlsZT48IVtlbmRpZl0tLT48c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05v cm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250 LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxk aXYgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIFdHLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JbiB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBjb25maWcgWWFuZyBtb2Rl bCBmb3IgU1IsIHRoZSBTUkdCIGxpc3QgaXMgY29uZmlndXJlZCBhdCBTUiB0b3AgbGV2ZWwsIHNv IGl0IGlzIGFnbm9zdGljIHRvIHRoZSByb3V0aW5nIHByb3RvY29sLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgaGFkIHNvbWUgY29tbWVudCBpbiBEYWxsYXMgb24gZGlm ZmljdWx0aWVzIHRoYXQgaGF2aW5nIGNvbW1vbiBsYWJlbCByYW5nZSBzaGFyZWQgYmV0d2VlbiBw cm90b2NvbHMgY291bGQgbGVhZCB0by48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkR1cmluZyBkaXNjdXNzaW9uIGluIG91ciBkZXNpZ24gdGVhbSwgc29tZSBwb2ludCB3YXMg YWxzbyByYWlzZWQgb24gcm91dGluZyBwcm90b2NvbCBtaWdyYXRpb25zIHRoYXQgbWF5IGJlIHNh ZmVyIHVzaW5nIGEgcGVyIHByb3RvY29sIFNSR0IgKHNvIGNvbmZpZ3VyYXRpb24gdGhlIFNSR0Ig YXQgSUdQIGxldmVsIHJhdGhlciB0aGFuIGdsb2JhbGx5KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+V2Ugd291bGQgbGlrZSB0byBoZWFyIGZyb20gdGhlIFdHIGFib3V0IHRoZSBwcmVmZXJlbmNl IGFuZCBhcmd1bWVudHMgZm9yIGJvdGggYXBwcm9hY2hlcyA6PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5BcHByb2FjaCAxKSBrZWVwIFNSR0IgY29uZmlndXJhdGlvbiBhdCB0 b3AgbGV2ZWwsIGFuZCBzbyByb3V0aW5nIHByb3RvY29scyB3aWxsIHNoYXJlIHRoZSBzYW1lIGxh YmVsIHNwYWNlICh0b2RheSBwcm9wb3NhbCk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFwcHJvYWNoIDIpIG1vdmUgU1JHQiBjb25maWd1cmF0aW9uIHRvIHByb3RvY29scywg ZWFjaCByb3V0aW5nIHByb3RvY29sIG1hbmFnZXMgaXRzIG93biBsYWJlbCBzcGFjZS48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzIHRvIHByb3ZpZGUgeW91ciBmZWVkYmFjayBpbiBvcmRl ciB0byBzb2x2ZSB0aGlzIGlzc3VlIGFuZCBoYXZlIGEgY29uc2Vuc3VzLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxh IGhyZWY9Imh0dHA6Ly93d3cub3JhbmdlLmNvbS8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGNvbG9yOiBibHVlOyB0 ZXh0LWRlY29yYXRpb246IG5vbmU7Ij48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjQwIiBoZWlnaHQ9 IjQwIiBpZD0iUGljdHVyZV94MDAyMF8xIiBzcmM9ImNpZDppbWFnZTAwMS5naWZAMDFEMEM0QjMu NjZCQTRENjAiIGFsdD0iT3JhbmdlIGxvZ28iPjwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRlIiIHN0 eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBw dDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5TdGVwaGFu ZSBMaXRrb3dza2kNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPjxicj4NCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGNv bG9yOiBibGFjazsiPk5ldHdvcmsgQXJjaGl0ZWN0DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPjxicj4N Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWws IHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPk9yYW5nZS9TQ0UvRVFVQU5UL0lCTkYvRU5ERC9O REUNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQt ZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IGJsYWNrOyI+T3JhbmdlIEV4cGVydCBG dXR1cmUgTmV0d29ya3M8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDEy cHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv bnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxh Y2s7Ij5waG9uZToNCjxhIGhyZWY9Imh0dHBzOi8vbW9uc2kuc3NvLmZyYW5jZXRlbGVjb20uZnIv aW5kZXguYXNwP3RhcmdldD1odHRwJTNBJTJGJTJGY2xpY3ZvaWNlLnNzby5mcmFuY2V0ZWxlY29t LmZyJTJGQ2xpY3ZvaWNlVjIlMkZUb29sQmFyLmRvJTNGYWN0aW9uJTNEZGVmYXVsdCUyNnJvb3Rz ZXJ2aWNlJTNEU0lHTkFUVVJFJTI2dG8lM0QmIzQzOzMzJTIwMiUyMDIzJTIwMjglMjA0OSUyMDgz JTIwIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+JiM0 MzszMyAyIDIzIDI4IDQ5IDgzIDwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHls ZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyI+PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBm b250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPm1vYmlsZToNCjxh IGhyZWY9Imh0dHBzOi8vbW9uc2kuc3NvLmZyYW5jZXRlbGVjb20uZnIvaW5kZXguYXNwP3Rhcmdl dD1odHRwJTNBJTJGJTJGY2xpY3ZvaWNlLnNzby5mcmFuY2V0ZWxlY29tLmZyJTJGQ2xpY3ZvaWNl VjIlMkZUb29sQmFyLmRvJTNGYWN0aW9uJTNEZGVmYXVsdCUyNnJvb3RzZXJ2aWNlJTNEU0lHTkFU VVJFJTI2dG8lM0QmIzQzOzMzJTIwNiUyMDM3JTIwODYlMjA5NyUyMDUyJTIwIj4NCjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+JiM0MzszMyA2IDM3IDg2IDk3 IDUyIDwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiByZ2Io MjU1LCAxMDIsIDApOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7Ij5zdGVwaGFuZS5saXRrb3dza2lA b3JhbmdlLmNvbTwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9ImxpbmUtaGVpZ2h0OjE1LjBwdCI+PHNwYW4gbGFuZz0iRlIiIHN0eWxl PSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7 Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHByZT5fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkNlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KcGFzIGV0cmUg ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCmEg bCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMu IExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRp b24sDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEg ZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNClRoaXMgbWVzc2FnZSBh bmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2Vk IGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQp0aGV5IHNob3VsZCBu b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4N CklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0K QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KVGhhbmsg eW91Lg0KPC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9zcGFuPjwvZGl2Pg0KPC9kaXY+DQo8L3Nw YW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_518ACD7CB1EF4C03A2C44220D4FD87B7alcatellucentcom_-- --_004_518ACD7CB1EF4C03A2C44220D4FD87B7alcatellucentcom_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: attachment; filename="image001.gif"; size=381; creation-date="Fri, 31 Jul 2015 05:44:42 GMT"; modification-date="Fri, 31 Jul 2015 05:44:42 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhKAAoAMQAAP+MQP+zgP/17//s3/+DMP/iz/+fYP+8j/9wEP95IP/Gn/+WUP/Pr/+pcP/Z v/////9mAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAoACgAAAX6oAONZGmeaEqKauum7Cu/8Wyj9a2P+X73vhkwSCPuhkYVMolj2pbOEjTK oxatrSlVG+U6vUxwUmwkE81BtE99xGbdSjhMPgo4BAoA+wUICAR6IwQODwMNEAcOigAFhQYQDgoD DwcQBJOKBIOFDQmaCCyTB416hQcBBQuTEA8Cow8EBQINpHcGhAkrEAkPChAAD3YPCLuSDw+sIgEP wCILzK0OjY9VBJS/wYQjfwaNyRDLzRAG0AMB5wC6ENyEt8jWDAsCyA/KzJN+zLILqLlVv/OuaYPU alU9cMwuPSCl8AEDYv8EQbwRgAEABcziJFl2bMmeEQgATEwRAgA7 --_004_518ACD7CB1EF4C03A2C44220D4FD87B7alcatellucentcom_-- From nobody Thu Jul 30 23:04:03 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7A51B3247 for ; Thu, 30 Jul 2015 23:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPhkOTLZCd_7 for ; Thu, 30 Jul 2015 23:03:59 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.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 48FFA1B320C for ; Thu, 30 Jul 2015 23:03:40 -0700 (PDT) X-AuditID: c6180641-f79556d0000002c8-1a-55baa73e8ada Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 88.D8.00712.E37AAB55; Fri, 31 Jul 2015 00:37:50 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0210.002; Fri, 31 Jul 2015 02:03:38 -0400 From: Jeff Tantsura To: "stephane.litkowski@orange.com" , "spring@ietf.org" Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQy1akRVV+Zd6d2k61eqAHOjLC2A== Date: Fri, 31 Jul 2015 06:03:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.7.141117 x-originating-ip: [147.117.188.10] Content-Type: multipart/mixed; boundary="_004_D1E05D33A0F26jefftantsuraericssoncom_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUyuXRPlK7d8l2hBlPfSFscv/Cb0eLr3oes DkweS5b8ZPJoeXaSLYApissmJTUnsyy1SN8ugSvj149XjAXbiyu2fDjD2sD4JrWLkZNDQsBE 4uWLJlYIW0ziwr31bF2MXBxCAkcZJU7uOscK4SxnlOj8tY8FpIpNwEDi/7fjYLaIQJbEzk+X 2UFsYYFAiWkXDwLFOYDiQRJ75ltDlOhJzPh6HayERUBV4sCGM8wgNq+AucT//lVgi4UEtCWm vHvNDtLKKaAjsfV1AEiYEeie76fWMIHYzALiEreezGeCuFNE4uHF02wQtqjEy8f/wMaIAq1a eb0JKq4kMWkpyPkcQL1hEoenq0BsFZQ4OfMJywRG0VlIps5CqJqFpAqiJEZi85Op7BC2gcT7 c/OZIWxtiWULX0PZ+hIbv5xlhLCtJaYdn8aKqUZHYvOlnVAzFSXaOmczQdgrGCV2npWHqfnz eh87TM2U7ofsCxj5VjFylBanluWmGxluYgTG/TEJNscdjAs+WR5iFOBgVOLhVUjbFSrEmlhW XJl7iFGag0VJnFfaLy9USCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+PushVTXi/f+mGB21TB cI3KzfLe/CWbnxbEtt85+VKGa/1cg1WLWQUcl13u/9yz6XPQK7vT8zhtwkxygzc56Trd8Nz1 7coK1UiPLbKGYb2Xnvs8k9icOHlGZY9WJfeNtTv4O5zU9KIuSx7s4VU29b9bo8zzf0Nz/9Hu LXsP9DSdviwr+XnWrStKLMUZiYZazEXFiQC9yhQJ3AIAAA== Archived-At: Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2015 06:04:01 -0000 --_004_D1E05D33A0F26jefftantsuraericssoncom_ Content-Type: multipart/alternative; boundary="_000_D1E05D33A0F26jefftantsuraericssoncom_" --_000_D1E05D33A0F26jefftantsuraericssoncom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, Architecturally I agree =96 label manager shouldn=92t care less how labels = have been learnt Operationally I=92m strongly for #2, in case of ISIS possibly under AF. Cheers, Jeff From: spring > on b= ehalf of Stephane Litkowski > Date: Wednesday, July 22, 2015 at 7:19 PM To: "spring@ietf.org" > Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi WG, In the current version of the config Yang model for SR, the SRGB list is co= nfigured at SR top level, so it is agnostic to the routing protocol. We had some comment in Dallas on difficulties that having common label rang= e shared between protocols could lead to. During discussion in our design team, some point was also raised on routing= protocol migrations that may be safer using a per protocol SRGB (so config= uration the SRGB at IGP level rather than globally). We would like to hear from the WG about the preference and arguments for bo= th approaches : Approach 1) keep SRGB configuration at top level, and so routing protocols = will share the same label space (today proposal) Approach 2) move SRGB configuration to protocols, each routing protocol man= ages its own label space. Thanks to provide your feedback in order to solve this issue and have a con= sensus. [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 mobile: +33 6 37 86 97 52 stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ 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_D1E05D33A0F26jefftantsuraericssoncom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <6295A56263B39845BC8E5BCD81A57DCE@ericsson.com> Content-Transfer-Encoding: quoted-printable
    Hi,

    Architecturally I agree =96 label manager shouldn=92t care less how la= bels have been learnt
    Operationally I=92m strongly for #2, in case of ISIS possibly under AF= .

    Cheers,
    Jeff

    From: spring <spring-bounces@ietf.org> on behalf of Steph= ane Litkowski <stephane= .litkowski@orange.com>
    Date: Wednesday, July 22, 2015 at 7= :19 PM
    To: "spring@ietf.org" <= spring@ietf.org>
    Subject: [spring] Modeling SRGB con= figuration for draft-ietf-spring-sr-yang

    Hi WG,

     

    In the current version of the config Yang model for = SR, the SRGB list is configured at SR top level, so it is agnostic to the r= outing protocol.

    We had some comment in Dallas on difficulties that h= aving common label range shared between protocols could lead to.=

    During discussion in our design team, some point was= also raised on routing protocol migrations that may be safer using a per p= rotocol SRGB (so configuration the SRGB at IGP level rather than globally).=

     

    We would like to hear from the WG about the preferen= ce and arguments for both approaches :

    Approach 1) keep SRGB configuration at top level, an= d so routing protocols will share the same label space (today proposal)

    Approach 2) move SRGB configuration to protocols, ea= ch routing protocol manages its own label space.

     

    Thanks to provide your feedback in order to solve th= is issue and have a consensus.

     

     

    3D"Orange

     

    Stephane Litkowski
    Network Architect
    Orange/SCE/EQUANT/IBNF/ENDD/NDE

    Orange Expert Future Networks=

    phone: +33 2 23 28 49 83
    mobile: +33 6 37 86 97 52
    stephane.litkowski@orange.com

     

     

    ______________________________________________________________________=
___________________________________________________

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_D1E05D33A0F26jefftantsuraericssoncom_-- --_004_D1E05D33A0F26jefftantsuraericssoncom_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: attachment; filename="image001.gif"; size=381; creation-date="Fri, 31 Jul 2015 06:03:37 GMT"; modification-date="Fri, 31 Jul 2015 06:03:37 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhKAAoAMQAAP+MQP+zgP/17//s3/+DMP/iz/+fYP+8j/9wEP95IP/Gn/+WUP/Pr/+pcP/Z v/////9mAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAoACgAAAX6oAONZGmeaEqKauum7Cu/8Wyj9a2P+X73vhkwSCPuhkYVMolj2pbOEjTK oxatrSlVG+U6vUxwUmwkE81BtE99xGbdSjhMPgo4BAoA+wUICAR6IwQODwMNEAcOigAFhQYQDgoD DwcQBJOKBIOFDQmaCCyTB416hQcBBQuTEA8Cow8EBQINpHcGhAkrEAkPChAAD3YPCLuSDw+sIgEP wCILzK0OjY9VBJS/wYQjfwaNyRDLzRAG0AMB5wC6ENyEt8jWDAsCyA/KzJN+zLILqLlVv/OuaYPU alU9cMwuPSCl8AEDYv8EQbwRgAEABcziJFl2bMmeEQgATEwRAgA7 --_004_D1E05D33A0F26jefftantsuraericssoncom_-- From nobody Fri Jul 31 00:53:25 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB1EF1B3308; Fri, 31 Jul 2015 00:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id liPIHFQFaxeK; Fri, 31 Jul 2015 00:53:22 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF7D1A872B; Fri, 31 Jul 2015 00:53:22 -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.2.0.p3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150731075322.6158.40187.idtracker@ietfa.amsl.com> Date: Fri, 31 Jul 2015 00:53:22 -0700 Archived-At: Cc: spring@ietf.org Subject: [spring] I-D Action: draft-ietf-spring-segment-routing-04.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 List-Id: "Stacked Tunnels for Source Routing \(STATUS\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 Jul 2015 07:53:23 -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 Working Group of the IETF. Title : Segment Routing Architecture Authors : Clarence Filsfils Stefano Previdi Bruno Decraene Stephane Litkowski Rob Shakir Filename : draft-ietf-spring-segment-routing-04.txt Pages : 21 Date : 2015-07-31 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 extension 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 extension header. The segment to process is indicated by a pointer in the routing extension header. Upon completion of a segment, the pointer is incremented. 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-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-spring-segment-routing-04 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 Jul 31 00:55:00 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E301B330B for ; Fri, 31 Jul 2015 00:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yQCt5nJPMafe for ; Fri, 31 Jul 2015 00:54:57 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4176C1B3308 for ; Fri, 31 Jul 2015 00:54:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2941; q=dns/txt; s=iport; t=1438329297; x=1439538897; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=mqAu9XaIHlRYEV860+7rQhiLg5wPjX15qCPEUEGyoh4=; b=CkAUVH7c+CBsYsWasxfBGUSqgRaKchoeFIKAdsirU4D+l7rvI71WYtQW rdMpobtX4G1mq51XqqHViErHge0aNMGdsARzhHLLP5U2zXJ3UgxE6xyB+ uhkJNyaH9aMm67ZGrz9xa3FCoG3rn/Eq/RtfIXvv8+kgfuNuWnLWt1F7j 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AoAwDFKLtV/5ldJa1bgxpUaQa8KwmCBoV3AoE0OBQBAQEBAQEBfwuEIwEBAQMBOj0HCwIBGQECAQIfEDIXBAIIAgQTiCYIDcZKAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4tOhRSDEoEUBYxMiCwBhHqHToFHRoNak1gmg31vAYFHgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,582,1432598400"; d="scan'208";a="173692402" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-2.cisco.com with ESMTP; 31 Jul 2015 07:54:56 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id t6V7su5M000714 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 31 Jul 2015 07:54:56 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.72]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Fri, 31 Jul 2015 02:54:56 -0500 From: "Stefano Previdi (sprevidi)" To: "spring@ietf.org" Thread-Topic: New Version Notification for draft-ietf-spring-segment-routing-04.txt Thread-Index: AQHQy2X8FVI9+f1whkayujlIG15nsw== Date: Fri, 31 Jul 2015 07:54:55 +0000 Message-ID: <00549057-BC38-40E3-8C1A-FB1DB5F7B503@cisco.com> References: <20150731075322.6158.41111.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.93.42] Content-Type: text/plain; charset="us-ascii" Content-ID: <593146FF1D2D4E4393B28EC8CB36701A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [spring] Fwd: New Version Notification for draft-ietf-spring-segment-routing-04.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2015 07:54:59 -0000 All, in this version we added more clarifications on the anycast use-case. Thanks. s. Begin forwarded message: > From: > Subject: New Version Notification for draft-ietf-spring-segment-routing-0= 4.txt > Date: July 31, 2015 9:53:22 AM GMT+02:00 > To: Stefano Previdi , Rob Shakir , "Bruno= Decraene" , Stephane Litkowski , Clarence Filsfils , Bruno Decraene , Stefano Previdi , Clarence Fi= lsfils , "rjs@rob.sh" , Stephane Litkowski = >=20 >=20 > A new version of I-D, draft-ietf-spring-segment-routing-04.txt > has been successfully submitted by Stefano Previdi and posted to the > IETF repository. >=20 > Name: draft-ietf-spring-segment-routing > Revision: 04 > Title: Segment Routing Architecture > Document date: 2015-07-31 > Group: spring > Pages: 21 > URL: https://www.ietf.org/internet-drafts/draft-ietf-spring-se= gment-routing-04.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-spring-segmen= t-routing/ > Htmlized: https://tools.ietf.org/html/draft-ietf-spring-segment-rou= ting-04 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-seg= ment-routing-04 >=20 > 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. >=20 > 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. >=20 > Segment Routing can be applied to the IPv6 architecture, with a new > type of routing extension 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 extension header. The segment to > process is indicated by a pointer in the routing extension header. > Upon completion of a segment, the pointer is incremented. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 From nobody Fri Jul 31 01:50:40 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B681B33F3 for ; Fri, 31 Jul 2015 01:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFEBKCXM9uSN for ; Fri, 31 Jul 2015 01:50:37 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A12A1B33F1 for ; Fri, 31 Jul 2015 01:50:37 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 9DAB01B8B9B; Fri, 31 Jul 2015 10:50:35 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.58]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 7FF46384097; Fri, 31 Jul 2015 10:50:35 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM33.corporate.adroot.infra.ftgroup ([fe80::3881:fc15:b4b2:9017%19]) with mapi id 14.03.0248.002; Fri, 31 Jul 2015 10:50:35 +0200 From: To: "Stefano Previdi (sprevidi)" , "spring@ietf.org" Thread-Topic: New Version Notification for draft-ietf-spring-segment-routing-04.txt Thread-Index: AQHQy2X8BVZg7wDK2US1oVW60iPqsZ31RO6g Date: Fri, 31 Jul 2015 08:50:34 +0000 Message-ID: <16070_1438332635_55BB36DB_16070_3102_1_9E32478DFA9976438E7A22F69B08FF92166BAE65@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: <20150731075322.6158.41111.idtracker@ietfa.amsl.com> <00549057-BC38-40E3-8C1A-FB1DB5F7B503@cisco.com> In-Reply-To: <00549057-BC38-40E3-8C1A-FB1DB5F7B503@cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US 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: 2015.7.31.80316 Archived-At: Subject: Re: [spring] New Version Notification for draft-ietf-spring-segment-routing-04.txt X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2015 08:50:39 -0000 Hi Stefano, The new text for anycast fits perfectly my previous comment. Best Regards, -----Original Message----- From: spring [mailto:spring-bounces@ietf.org] On Behalf Of Stefano Previdi = (sprevidi) Sent: Friday, July 31, 2015 09:55 To: spring@ietf.org Subject: [spring] Fwd: New Version Notification for draft-ietf-spring-segme= nt-routing-04.txt All, in this version we added more clarifications on the anycast use-case. Thanks. s. Begin forwarded message: > From: > Subject: New Version Notification for=20 > draft-ietf-spring-segment-routing-04.txt > Date: July 31, 2015 9:53:22 AM GMT+02:00 > To: Stefano Previdi , Rob Shakir ,=20 > "Bruno Decraene" , Stephane Litkowski=20 > , Clarence Filsfils=20 > , Bruno Decraene ,=20 > Stefano Previdi , Clarence Filsfils=20 > , "rjs@rob.sh" , Stephane Litkowski=20 > >=20 >=20 > A new version of I-D, draft-ietf-spring-segment-routing-04.txt > has been successfully submitted by Stefano Previdi and posted to the=20 > IETF repository. >=20 > Name: draft-ietf-spring-segment-routing > Revision: 04 > Title: Segment Routing Architecture > Document date: 2015-07-31 > Group: spring > Pages: 21 > URL: https://www.ietf.org/internet-drafts/draft-ietf-spring-se= gment-routing-04.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-spring-segmen= t-routing/ > Htmlized: https://tools.ietf.org/html/draft-ietf-spring-segment-rou= ting-04 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-spring-seg= ment-routing-04 >=20 > 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. >=20 > 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. >=20 > Segment Routing can be applied to the IPv6 architecture, with a new > type of routing extension 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 extension header. The segment to > process is indicated by a pointer in the routing extension header. > Upon completion of a segment, the pointer is incremented. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of=20 > submission until the htmlized version and diff are available at tools.iet= f.org. >=20 > The IETF Secretariat >=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 Fri Jul 31 01:52:13 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C401B2D30 for ; Fri, 31 Jul 2015 01:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yVzk9lIHTpD for ; Fri, 31 Jul 2015 01:52:08 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A80D11B32DC for ; Fri, 31 Jul 2015 01:52:07 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id D8FA52AC5BF; Fri, 31 Jul 2015 10:52:05 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.27]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id AC27D158052; Fri, 31 Jul 2015 10:52:05 +0200 (CEST) Received: from OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe]) by OPEXCLILM7C.corporate.adroot.infra.ftgroup ([fe80::8007:17b:c3b4:d68b%19]) with mapi id 14.03.0248.002; Fri, 31 Jul 2015 10:52:05 +0200 From: To: Jeff Tantsura , "spring@ietf.org" Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQxUX8bOSCn6yWgUicwmRruSnwt531ATSAgABQVLA= Date: Fri, 31 Jul 2015 08:52:04 +0000 Message-ID: <4670_1438332725_55BB3735_4670_3351_1_9E32478DFA9976438E7A22F69B08FF92166BAE79@OPEXCLILMA4.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/related; boundary="_004_9E32478DFA9976438E7A22F69B08FF92166BAE79OPEXCLILMA4corp_"; type="multipart/alternative" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.31.80316 Archived-At: Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2015 08:52:12 -0000 --_004_9E32478DFA9976438E7A22F69B08FF92166BAE79OPEXCLILMA4corp_ Content-Type: multipart/alternative; boundary="_000_9E32478DFA9976438E7A22F69B08FF92166BAE79OPEXCLILMA4corp_" --_000_9E32478DFA9976438E7A22F69B08FF92166BAE79OPEXCLILMA4corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Looks that consensus is for option#2, so let's move SRGB to protocol config= uration. From: Jeff Tantsura [mailto:jeff.tantsura@ericsson.com] Sent: Friday, July 31, 2015 08:04 To: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-= yang Hi, Architecturally I agree - label manager shouldn't care less how labels have= been learnt Operationally I'm strongly for #2, in case of ISIS possibly under AF. Cheers, Jeff From: spring > on b= ehalf of Stephane Litkowski > Date: Wednesday, July 22, 2015 at 7:19 PM To: "spring@ietf.org" > Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Hi WG, In the current version of the config Yang model for SR, the SRGB list is co= nfigured at SR top level, so it is agnostic to the routing protocol. We had some comment in Dallas on difficulties that having common label rang= e shared between protocols could lead to. During discussion in our design team, some point was also raised on routing= protocol migrations that may be safer using a per protocol SRGB (so config= uration the SRGB at IGP level rather than globally). We would like to hear from the WG about the preference and arguments for bo= th approaches : Approach 1) keep SRGB configuration at top level, and so routing protocols = will share the same label space (today proposal) Approach 2) move SRGB configuration to protocols, each routing protocol man= ages its own label space. Thanks to provide your feedback in order to solve this issue and have a con= sensus. [Orange logo] Stephane Litkowski Network Architect Orange/SCE/EQUANT/IBNF/ENDD/NDE Orange Expert Future Networks phone: +33 2 23 28 49 83 mobile: +33 6 37 86 97 52 stephane.litkowski@orange.com ___________________________________________________________________________= ______________________________________________ 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_9E32478DFA9976438E7A22F69B08FF92166BAE79OPEXCLILMA4corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

    Looks that consensus i= s for option#2, so let’s move SRGB to protocol configuration.

     

     

    From: Jeff Tan= tsura [mailto:jeff.tantsura@ericsson.com]
    Sent: Friday, July 31, 2015 08:04
    To: LITKOWSKI Stephane SCE/IBNF; spring@ietf.org
    Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spr= ing-sr-yang

     

    Hi,

    &n= bsp;

    Archite= cturally I agree – label manager shouldn’t care less how labels= have been learnt

    Operati= onally I’m strongly for #2, in case of ISIS possibly under AF.

    &n= bsp;

    Cheers,=

    Jeff

    &n= bsp;

    From: spring <spring-bounces@ietf.org> on behalf of Stephane Litkowski <stephane.litkowski@orange.com<= /a>>
    Date: Wednesday, July 22, 2015 at 7:19 PM
    To: "    spring@ietf.org&quo= t; <spring@ietf.org>
    Subject: [spring] Modeling SRGB configuration for draft-ietf-spring-= sr-yang

    &n= bsp;

    Hi WG,=

     =

    In the current version o= f the config Yang model for SR, the SRGB list is configured at SR top level= , so it is agnostic to the routing protocol.

    We had some comment in D= allas on difficulties that having common label range shared between protoco= ls could lead to.

    During discussion in our= design team, some point was also raised on routing protocol migrations tha= t may be safer using a per protocol SRGB (so configuration the SRGB at IGP = level rather than globally).

     =

    We would like to hear fr= om the WG about the preference and arguments for both approaches :

    Approach 1) keep SRGB co= nfiguration at top level, and so routing protocols will share the same labe= l space (today proposal)

    Approach 2) move SRGB co= nfiguration to protocols, each routing protocol manages its own label space= .

     =

    Thanks to provide your f= eedback in order to solve this issue and have a consensus.

     =

     =

    3D"Orange

     

    Stephane Litkowski
    Network Architect
    Orange/SCE/EQUANT/IBNF/ENDD/NDE

    Orange Expert Fut= ure Networks

    phone: +33 2 23 28 49 83
    mobile: +33 6 37 86 97 52
    stephane.litkowski@orange.com

     

     = 

    __________________________________________=
___________________________________________________________________________=
____
     
    Ce message et ses pieces jointes peuvent c=
ontenir des informations confidentielles ou privilegiees et ne doivent donc=

    pas etre diffuses, exploites ou copies san=
s autorisation. Si vous avez recu ce message par erreur, veuillez le signal=
er
    a l'expediteur et le detruire ainsi que le=
s pieces jointes. Les messages electroniques etant susceptibles d'alteratio=
n,
    Orange decline toute responsabilite si ce =
message a ete altere, deforme ou falsifie. Merci.
     
    This message and its attachments may conta=
in confidential or privileged information that may be protected by law;
    they should not be distributed, used or co=
pied without authorisation.
    If you have received this email in error, =
please notify the sender and delete this message and its attachments.<=
/o:p>
    As emails may be altered, Orange is not li=
able 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_9E32478DFA9976438E7A22F69B08FF92166BAE79OPEXCLILMA4corp_-- --_004_9E32478DFA9976438E7A22F69B08FF92166BAE79OPEXCLILMA4corp_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=381; creation-date="Fri, 31 Jul 2015 08:52:04 GMT"; modification-date="Fri, 31 Jul 2015 08:52:04 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhKAAoAMQAAP+MQP+zgP/17//s3/+DMP/iz/+fYP+8j/9wEP95IP/Gn/+WUP/Pr/+pcP/Z v/////9mAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAoACgAAAX6oAONZGmeaEqKauum7Cu/8Wyj9a2P+X73vhkwSCPuhkYVMolj2pbOEjTK oxatrSlVG+U6vUxwUmwkE81BtE99xGbdSjhMPgo4BAoA+wUICAR6IwQODwMNEAcOigAFhQYQDgoD DwcQBJOKBIOFDQmaCCyTB416hQcBBQuTEA8Cow8EBQINpHcGhAkrEAkPChAAD3YPCLuSDw+sIgEP wCILzK0OjY9VBJS/wYQjfwaNyRDLzRAG0AMB5wC6ENyEt8jWDAsCyA/KzJN+zLILqLlVv/OuaYPU alU9cMwuPSCl8AEDYv8EQbwRgAEABcziJFl2bMmeEQgATEwRAgA7 --_004_9E32478DFA9976438E7A22F69B08FF92166BAE79OPEXCLILMA4corp_-- From nobody Fri Jul 31 07:02:30 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDAB1A8877 for ; Fri, 31 Jul 2015 07:02:28 -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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mt_8wdhOzUJa for ; Fri, 31 Jul 2015 07:02:25 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0744.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:744]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C1141A8855 for ; Fri, 31 Jul 2015 07:02:25 -0700 (PDT) Authentication-Results: alcatel-lucent.com; dkim=none (message not signed) header.d=none; Received: from hannes-mba.local (193.110.55.13) by BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) with Microsoft SMTP Server (TLS) id 15.1.225.19; Fri, 31 Jul 2015 14:02:08 +0000 Received: from hannes-mba.local (localhost [IPv6:::1]) by hannes-mba.local (Postfix) with ESMTP id 19D8B15CD708; Fri, 31 Jul 2015 16:01:53 +0200 (CEST) Date: Fri, 31 Jul 2015 16:01:53 +0200 From: "Hannes Gredler (hannes@juniper.net)" To: Message-ID: <20150731140153.GA17044@hannes-mba.local> References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <9950_1438262325_55BA2435_9950_8082_1_9E32478DFA9976438E7A22F69B08FF92166BA633@OPEXCLILMA4.corporate.adroot.infra.ftgroup> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <9950_1438262325_55BA2435_9950_8082_1_9E32478DFA9976438E7A22F69B08FF92166BA633@OPEXCLILMA4.corporate.adroot.infra.ftgroup> User-Agent: Mutt/1.5.23 (2014-03-12) X-Originating-IP: [193.110.55.13] X-ClientProxiedBy: HE1PR08CA0041.eurprd08.prod.outlook.com (25.161.112.51) To BN1PR05MB440.namprd05.prod.outlook.com (10.141.58.26) X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB440; 2:EOPLO0SR+gqFkUWz01xkWLqu314u4Vz3OeGCubymmCW2GE38Dpwic5V8HFCRM4PPV9p3k2MY6YzpA8EZY4+dwMycufcz0WD3wkWUX1K5BrQA94QY4NTVVk3Vx2RgpNCLir4kZLwmbevxYd4ojDAbl/NDXVJvgxkrI9V0YM2a6Dk=; 3:DcAeQ4vcbRGcRB8nIwchtkmvlLrn7vPjRn+fh1cymr8DiIY03id2IEppTOHJ4uY3MUyF0rIIoZM9XfBXrV8EpnYg7J8KdhmXHjeeqCTqP1nvt7hgzmtrSydQN1MmZB+TurZ/27PNADbgq2bgleSWiA==; 25:jG5Wz0ilMUM9eYogSOW0v7R8mEWAISM9H7dzlvj994K+9dKjH/TAwvOU5/Saxzpc0CXIMYqYlJfhBuGUxnAe2FQ2lGDD27LjeC2rxfE9aRKiTOH1TTSr074NCGDnW5zQPa+nT80bSXYA6fKXaT1KH4oORgcmBFIoiLgzqK4kqZ+sjYo4YPbduWYN7Jr7LU/mx5BcHkcCOYceHf3JmeZWBFu4jRaxn1cHltvDTK2yAenD2WMpIcBLHFNwKNadjfIrbBXAlpuY11nat7n8S0jVmg== X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB440; X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB440; 20:XF/OE/cjB6u23clBIG9aF5Se6qOwBuncs5dJJ6u93Mcn7uPi3R2dIboUdjF1G3v5Q+WD5RPEWIkvoK7HgQ6Us1P6XzkWY145x/2ymz8R0fAebV+dH3Wi/zFaOWiUgqyI+/Mm58zfgNPPnDnRcJWBr2SfL7btlxq3edISex1e/PeCKwDbH+UF6wXyn8IkgIoA8PW1vNZ4hOCes0QrWkaBUIcMdQD2vXFtncsH7/JEIji0ddENNUZnKkQ9T4bUU+G7h1B2KNTNHEB5gL1Y42lz2Mo1maz0Ce+uJOlGXTHwgu5a5jW+V4ryk1+OyoUMNlvtFg945gAAmJMC4Dg4/VveoL7v1GYW+3zfcNK4VX+2Pt9j47DzcU9mIQQaDx4A8hPZRA52o6RyJB+WzCiabX3WPNi54sOAzhN+ZbhQJ6VdrQqGvCyCY8ygcUqvljhii9Uvf9c9kSqnDh5IdrU3yKTXDykZ2g4Ssc9mX5CGDn4eOJhuIEMw0hqPS2yxWCpkWL2+; 4:HTLw1SHZHi5dV9Q1ukgB5WWfTZVuJuLNY5kfyDQkZ2jADpb5R5BOoLrakdpS0kSJ7z99WYCuJXoWCLk7PE/JWVDzXaLlr/oyAOZ1Z1UxmaIBfhprjHcwubkEMZea61CauNajT1h26pI1OkzGfa0hifASnkHCZnPfg3PM3fHhs8MPk3aoMiFWop4DOvGC9WBeLz+AmV9pF1yGegl2vVk1CzOTcJ7fgPQQ/bjnUk6sphY41U+PQzh1tmd7LcVNnbQws6VthGtwIMUarLNJY+6AtD2AQfGiZniJAJdQG7n+8lU= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(5005006)(3002001); SRVR:BN1PR05MB440; BCL:0; PCL:0; RULEID:; SRVR:BN1PR05MB440; X-Forefront-PRVS: 0654257CF5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(37854004)(53754006)(24454002)(47776003)(50466002)(230783001)(5890100001)(66066001)(76506005)(92566002)(83506001)(97756001)(19580395003)(86362001)(46102003)(19580405001)(98436002)(77156002)(122386002)(62966003)(76176999)(54356999)(93886004)(46406003)(50986999)(23726002)(5003600100002)(5001960100002)(189998001)(122856001)(77096005)(110136002)(33656002)(2351001)(107886002)(2950100001)(4001350100001)(40100003)(4001430100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB440; H:hannes-mba.local; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1PR05MB440; 23:X77t8E4NrKj8dtk60URQy8Kuyemz/fxjccJcmO+dVR?= =?us-ascii?Q?XokwRdrU7TEKeGB4ACOeUClkiUENivG9pNAXIa7gKTdhlnc2uTJ2PX0E3Jmm?= =?us-ascii?Q?LoFSMp1h023pQI+MHllFU5pPS4nSh0/Pe8i+Ff3eqQlIOz+veuse0s91x4f5?= =?us-ascii?Q?joaQzUb1PXjSmHQ3tnoCKzLDsqDy4U+QueKdxdeGJW9GwCQGqz9VKjxoTJm1?= =?us-ascii?Q?ZDzYTKjC0Leq4/S7SZ7bSAlToFDQHYuD5bpykKSdodSVvrdbBTzgplOO2ZdH?= =?us-ascii?Q?fdmaFXbN4GwAewlALC6pnFDy9Ofvtg5aPMLmg6fNsmbyaTVsDnO+kg94AxGv?= =?us-ascii?Q?RO/QN0XYuqHPG+oOAvSnYC/uzUZMireJG8fLAg+k3+paQqdkK3GG1MzfpqTb?= =?us-ascii?Q?75qSU5Jog8KiQcvJHx8lC7DgdSrxIbX8Hz7YyhJ3CfKXD5tRvzBMuCrDUy7V?= =?us-ascii?Q?3EADA5IbVEbUPhSCi1RRpYqv4TfidXLxkqk/GM/8OWqmz/ytAqrer0LdqDiw?= =?us-ascii?Q?v6QG+eY/aR9Vb8dUUmAM+rc7OxJeQex6hGWoP5XXXhTYBtVjzLSLUTZSaB1S?= =?us-ascii?Q?LoS9L0eoSqc+LHd9V5mD8J5ivKe2BfihJSNEHqncDWWi2Ze2eMtxuqNQfI1H?= =?us-ascii?Q?/PVPnhzl/AA7tqKuPPBfiazUr0oc/HjIhfCnCccNGiol6rsYjeN4/G4JfDrM?= =?us-ascii?Q?CPczE1dcNLFRnPHvuPDbwh5nOjC6nMwiegF8gQMlOo2d1o+bGv4kLePEWzJ5?= =?us-ascii?Q?WpKnIF1ArWV15HyjR5ev5b29BZ4rS8HrMKRhixzCnqjalaCbDYBjjdQdI0KG?= =?us-ascii?Q?oOVWuEKqGrDVqX1CLoB9IY5BkqUJgWMRUPSqKpNgV8SAGU8cmWaLng8mg0a7?= =?us-ascii?Q?0FgUS4VFWm/7dvt1jmqDAtlWJDLE7NVjyMPiatXxSvse8wK1okH3hFCtOBbN?= =?us-ascii?Q?I/ehj8DFz1Jf0dUoZu+MYodWwVNhbu0Zf61dg4ubQ92DCz8AYloQb2odWOKn?= =?us-ascii?Q?3XDEUYt6Pdt2uzee3DxeS2hTQWSbuB6lU9xrJTqjJ2NZ1cYSrXPG9BC1jl/R?= =?us-ascii?Q?pqtDCNjFqq5ndYYgs22jByr7EMCaiJwJXKnnQXiiIBFx97vQ=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; BN1PR05MB440; 5:93yS+foJHJukxtY/5YlvPz2reunP0Rn9DZ0NZavwMbYLLWw6uVGz7JDS7U7Y5pbIl1KVF7+LWMQcvBo6B5pe2a7ZspQWhOSuaxbi0e8F0hI7i++lQYNqDXD+P95+rp4q0wmglWcppGcedTycpHjIdQ==; 24:ynh8Ml7QFYCf4BkjXRROjmNyvOKsoL9SyXvG0yrvxdTOUIzbubGZKZthi1P+EdfWgC/E+wgTmc3F8PUCKekBdks7GCccl3W3JMVdYHkuEUM=; 20:jdtm9psOuYXUov8yg8UkE5oEXv2Z/ZlTh89nFj9YLVJwwzA8LBvzURygqE0sAXz9Ph+xTpMgQok7lPADkfczhA== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 Jul 2015 14:02:08.3003 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1PR05MB440 Archived-At: Cc: "Les Ginsberg \(ginsberg\)" , "spring@ietf.org" , "Shraddha Hegde \(shraddha@juniper.net\)" , Uma Chunduri , "Pushpasis Sarkar \(psarkar@juniper.net\)" , "Aissaoui, Mustapha \(Mustapha\)" Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2015 14:02:28 -0000 one further point is that implementations MAY reuse exisiting MPLS label-managing software for SR. label-management software has often this label-per-client (singular) and not-label-per-clients (plural) bookkeeping in the sense that it cannot track multiple 'owners' of a certain label value. it would be interesting to hear from other implementers if their software can easily track 'multiple client' ownership per label (and if not) what are the implications to non-SR code-paths e.g. graceful restart scenarios ? /hannes On Thu, Jul 30, 2015 at 01:18:43PM +0000, stephane.litkowski@orange.com wrote: | As mentioned by others, there may be some operational gain. | | IGP migration example given is a good example, today with pure IP, there's | some tricky cases because we need to manage it with admin distance and | their may be some differences in best path computation between IGPs | (implementation dependant, but it's a reality). | | Here we have the opportunity to overcome this issue by letting the | possibility to create two parallel forwarding planes using different | labels. I agree that it consumes twice the number of required label, but | it may be a transient solution (for migration case) and also it's a design | choice of the operator. | | The last comment from Robert of virtualization , especially using | containers or part of router OS running on COTS (just OSPF or ISIS or BGP | code), may require some more independency between router software | components. | | | | | | Now from an architectural perspective, what is Segment Routing ? | | Segment routing is just an architecture, like MPLS is. We see that segment | routing has more and more controlplanes (ISIS and OSPF first, now BGP | ...), like MPLS does. Moreover using segment routing in an MPLS | environment leads to adding new controlplanes to MPLS. | | So I like the comment from Pushpasis talking about BGP, LDP, RSVP which | are different controlplane of MPLS. Do we advertise the same label value | for the same prefix FEC advertised in LDP, BGP and RSVP ? No ... so why | doing it with OSPF and ISIS ? | | | | | | From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] | Sent: Wednesday, July 29, 2015 23:01 | To: LITKOWSKI Stephane SCE/IBNF; Uma Chunduri; Aissaoui, Mustapha | (Mustapha); spring@ietf.org; Shraddha Hegde (shraddha@juniper.net); | Pushpasis Sarkar (psarkar@juniper.net); Hannes Gredler | (hannes@juniper.net) | Subject: RE: [spring] Modeling SRGB configuration for | draft-ietf-spring-sr-yang | | | | Stephane - | | | | What is the requirement to have a per-protocol SRGB config? | | This makes no sense to me operationally or architecturally. | | | | (I am not talking about what may or may not have been implemented by | vendors - the YANG model should be architecturally correct) | | | | Les | | | | | | From: [1]stephane.litkowski@orange.com | [[2]mailto:stephane.litkowski@orange.com] | Sent: Wednesday, July 29, 2015 5:11 AM | To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); | [3]spring@ietf.org; Shraddha Hegde ([4]shraddha@juniper.net); Pushpasis | Sarkar ([5]psarkar@juniper.net); Hannes Gredler ([6]hannes@juniper.net) | Subject: RE: [spring] Modeling SRGB configuration for | draft-ietf-spring-sr-yang | | | | Hi all, | | | | What if we keep the SRGB block config in "segment-routing" global module, | and if we allow for YANG configuration of carving this block inside each | protocol (maybe as a feature) ? | | | | Stephane | | | | | | From: Uma Chunduri [[7]mailto:uma.chunduri@ericsson.com] | Sent: Friday, July 24, 2015 16:59 | To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSKI | Stephane SCE/IBNF; [8]spring@ietf.org | Subject: RE: [spring] Modeling SRGB configuration for | draft-ietf-spring-sr-yang | | | | >Suggesting that the forwarding instruction (AKA label) needs to be | different depending on what protocol provided | | >the instruction is completely unnecessary - it simply wastes label space. | | | | [Uma]: Les, No - I never suggested anything like that. | | SRGB for a routing instance to be advertised should be part of the routing | instance provisioning as far as the yang model is concerned. | | Carving out the label space for SR is a local matter and agree, of course, | this can be done in so many ways through CLI, dynamically, statically | etc... | | | | -- | | Uma C. | | | | _________________________________________________________________________________________________________________________ | | | | 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. | | _________________________________________________________________________________________________________________________ | | 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. | | References | | Visible links | 1. mailto:stephane.litkowski@orange.com | 2. mailto:stephane.litkowski@orange.com | 3. mailto:spring@ietf.org | 4. mailto:shraddha@juniper.net | 5. mailto:psarkar@juniper.net | 6. mailto:hannes@juniper.net | 7. mailto:uma.chunduri@ericsson.com | 8. mailto:spring@ietf.org From nobody Fri Jul 31 09:40:36 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE8F21B2E4C; Fri, 31 Jul 2015 09:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bO2iDiJDsgam; Fri, 31 Jul 2015 09:40:31 -0700 (PDT) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F9E61B2E4B; Fri, 31 Jul 2015 09:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1619; q=dns/txt; s=iport; t=1438360831; x=1439570431; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=8U5iSxajqabGN5c1AgsBDIefQeKkbqYg39XyOPYj6ck=; b=DMUr6syQphnyGXguLv3gmI6zMXvp00fh/kaEATyQEO2EXftPfVJa2THR Sbc0pcDX4CJnqlahpwvdqh1nO36W6zycvKm0/uru7BZVrb+otuxgI4Dxy 7UxaeZHzEAsPtEh+/rtI7/PmLMWCftUKS6C8L1MxpkeDEPUxOpi86owDm U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BsAwD+o7tV/49dJa1bgxpUaQa8LwmBegqFL0oCgTE4FAEBAQEBAQGBCoQkAQEEAQEBGh00CxACAQgOCh4QJwslAgQBDQWILg3HXAEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi06ELlkHhCwFkXaDAgGMSIFHhCCPc4NlJoI/gT5vgQVDgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,585,1432598400"; d="scan'208";a="174088998" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-3.cisco.com with ESMTP; 31 Jul 2015 16:40:30 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id t6VGeUkM009441 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Jul 2015 16:40:30 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.123]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Fri, 31 Jul 2015 11:40:30 -0500 From: "George Swallow (swallow)" To: Pushpasis Sarkar , "spring@ietf.org" Thread-Topic: [spring] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop Thread-Index: AQHQy1Jn1Iwx5S2h60qyivkwCJ1jEZ312VMA Date: Fri, 31 Jul 2015 16:40:29 +0000 Message-ID: References: <3E235356-D3A3-4D61-BAAC-869D35B918C8@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [10.116.212.3] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "George Swallow \(swallow\)" , "mpls@ietf.org" Subject: Re: [spring] working group adoption call for draft-filsfils-spring-segment-routing-ldp-interop X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2015 16:40:34 -0000 Support. On 7/31/15, 1:32 AM, "spring on behalf of Pushpasis Sarkar" wrote: >Support. > >On 7/22/15, 3:17 PM, "spring on behalf of John G.Scudder" > wrote: > >>Dear WG, >> >>As we discussed at our meeting yesterday, working group adoption has been >>requested for draft-filsfils-spring-segment-routing-ldp-interop. Please >>reply to the list with your comments, including although not limited to >>whether or not you support adoption. Non-authors are especially >>encouraged to comment. >> >>In consideration of the fact that a number of WG calls are going on >>concurrently, we will end the call on August 31, 2015. >> >>Authors, please indicate whether you are aware of any relevant IPR and if >>so, whether it has been disclosed. Also, the length of the author list >>for this document greatly exceeds the maximum recommended. Assuming the >>document is adopted, the authors should be prepared to correct this when >>submitting as a WG document, ideally by reducing the list to simply the >>active editor(s) and making use of the "contributors" section for the >>full list. >> >>Thanks, >> >>--Bruno and John >> >>P.S.: Cc MPLS owing to the LDP connection. Please respect the reply-to. >>_______________________________________________ >>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 Jul 31 13:40:58 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 528321ACD6B for ; Fri, 31 Jul 2015 13:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bd33JnL1kPYu for ; Fri, 31 Jul 2015 13:40:53 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EDC41ACCF2 for ; Fri, 31 Jul 2015 13:40:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31761; q=dns/txt; s=iport; t=1438375253; x=1439584853; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=hSqsrNn/BIBuGvvrhHyHgaroEK2sAlYNu7mK6MfNBB4=; b=WzMhmL06aTIWY0JgsusTVCOi9cR5T13DEhaYMPjDrixPb30i0vfGgJbj bDJluTd9HI+YHAFzE+t8Y0OvKnjS20HTPztcciOmJ5jfaIGouXPGq1MfP /DFitaJqdTf6mtg8j42VrsYlZjFMSsLacV/l6/ek6eSiaiyRdYFYFOHAs w=; X-Files: image001.gif : 381 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DuBQBz3LtV/5pdJa1bgk1NVGkGgx24HEM1CYIBhXwCHIEWOBQBAQEBAQEBgQqEIwEBAQQFAR0CCAE0AgccAgIBCAcKAwEBAQYBAhgHAwICAhUBAwIJDBQJCAIEAREBBgiICwMSDbFbkEkDhTkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBItKhCQRASURCgwBCgEGgmOBQwWNC4Rrgh1lAYI4gVkBaIJihGyBR0aDWo9zg2Umg31vAQEBAYEKOoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,586,1432598400"; d="gif'147?scan'147,208,217,147";a="174301398" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-6.cisco.com with ESMTP; 31 Jul 2015 20:40:52 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t6VKeqNv002876 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Jul 2015 20:40:52 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.37]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Fri, 31 Jul 2015 15:40:52 -0500 From: "Acee Lindem (acee)" To: "stephane.litkowski@orange.com" , "Jeff Tantsura" , "spring@ietf.org" Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQy9Ew2xJ58gLPHEmdh8LBLbdNNA== Date: Fri, 31 Jul 2015 20:40:51 +0000 Message-ID: References: <4670_1438332725_55BB3735_4670_3351_1_9E32478DFA9976438E7A22F69B08FF92166BAE79@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: <4670_1438332725_55BB3735_4670_3351_1_9E32478DFA9976438E7A22F69B08FF92166BAE79@OPEXCLILMA4.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.205] Content-Type: multipart/mixed; boundary="_004_D1E1533A29F18aceeciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2015 20:40:56 -0000 --_004_D1E1533A29F18aceeciscocom_ Content-Type: multipart/alternative; boundary="_000_D1E1533A29F18aceeciscocom_" --_000_D1E1533A29F18aceeciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgU3RlcGhhbmUsDQoNCldoaWxlIHRoZXJlIG1heSBiZSB0cmFuc2l0aW9uYWwgdXNlIGNhc2Vz IHdoZXJlIHRoZXJlIGlzIGEgcmVxdWlyZW1lbnQgdG8gYWxsb2NhdGUgZGlmZmVyZW50IFNSR0Jz IHRvIGRpZmZlcmVudCBwcm90b2NvbHMgaW5zdGFuY2VzLCBJIGRvbuKAmXQgYmVsaWV2ZSB3ZSBz aG91bGQg4oCcdGhyb3cgdGhlIGJhYnkgb3V0IHdpdGggdGhlIGJhdGh3YXRlcuKAnSBhbmQgcmVt b3ZlIHRoZSBnbG9iYWwgU1JHQiBjb25maWd1cmF0aW9uLiBUaGUgb3BlcmF0aW9uYWwgc2ltcGxp Y2l0eSBhbmQgbWFuYWdhYmlsaXR5IGFkdmFudGFnZXMgb2YgaGF2aW5nIGEgc2luZ2xlIFNSR0Ig Zm9yIHRoZSBub2RlIGFyZSB1bmRlbmlhYmxlLiBUaGUgYmVuZWZpdHMgYXJlIG11bHRpcGxpZWQg aWYgb25lIGNhbiBtYWludGFpbiBhIGNvbnNpc3RlbnQgU1JHQiB0aHJvdWdob3V0IHRoZSBzZWdt ZW50IHJvdXRpbmcgZG9tYWluIChhbHRob3VnaCBJIHVuZGVyc3RhbmQgdGhhdCB0aGlzIGlzIG5v dCBhbHdheXMgcG9zc2libGUpLg0KDQpIZW5jZSwgSSBiZWxpZXZlIHdlIHNob3VsZCByZXRhaW4g dGhlIGdsb2JhbCBTUkdCIGNvbmZpZ3VyYXRpb24gaW4gdGhlIFlBTkcgbW9kZWwuIEluIHRoZSBw cm90b2NvbHMsIHRoZSBnbG9iYWwgU1JHQiB3b3VsZCBiZSBpbmhlcml0ZWQgb3IsIGlmIGNvbmZp Z3VyZWQsIG92ZXJ3cml0dGVuIGJ5IHByb3RvY29sIGNvbmZpZ3VyYXRpb24uIElmIHdlIGNhbm5v dCBhZ3JlZSBvbiBlaXRoZXIgYmVpbmcgbWFuZGF0b3J5LCBib3RoIGNvdWxkIGJlIFlBTkcgZmVh dHVyZXMuDQoNClRoYW5rcywNCkFjZWUNCg0KRnJvbTogc3ByaW5nIDxzcHJpbmctYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgU3Rl cGhhbmUgTGl0a293c2tpIDxzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTxtYWlsdG86c3Rl cGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+Pg0KRGF0ZTogRnJpZGF5LCBKdWx5IDMxLCAyMDE1 IGF0IDM6NTIgQU0NClRvOiBKZWZmIFRhbnRzdXJhIDxqZWZmLnRhbnRzdXJhQGVyaWNzc29uLmNv bTxtYWlsdG86amVmZi50YW50c3VyYUBlcmljc3Nvbi5jb20+PiwgInNwcmluZ0BpZXRmLm9yZzxt YWlsdG86c3ByaW5nQGlldGYub3JnPiIgPHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGll dGYub3JnPj4NClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBNb2RlbGluZyBTUkdCIGNvbmZpZ3VyYXRp b24gZm9yIGRyYWZ0LWlldGYtc3ByaW5nLXNyLXlhbmcNCg0KTG9va3MgdGhhdCBjb25zZW5zdXMg aXMgZm9yIG9wdGlvbiMyLCBzbyBsZXTigJlzIG1vdmUgU1JHQiB0byBwcm90b2NvbCBjb25maWd1 cmF0aW9uLg0KDQoNCkZyb206IEplZmYgVGFudHN1cmEgW21haWx0bzpqZWZmLnRhbnRzdXJhQGVy aWNzc29uLmNvbV0NClNlbnQ6IEZyaWRheSwgSnVseSAzMSwgMjAxNSAwODowNA0KVG86IExJVEtP V1NLSSBTdGVwaGFuZSBTQ0UvSUJORjsgc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gTW9kZWxpbmcgU1JHQiBjb25maWd1cmF0aW9u IGZvciBkcmFmdC1pZXRmLXNwcmluZy1zci15YW5nDQoNCkhpLA0KDQpBcmNoaXRlY3R1cmFsbHkg SSBhZ3JlZSDigJMgbGFiZWwgbWFuYWdlciBzaG91bGRu4oCZdCBjYXJlIGxlc3MgaG93IGxhYmVs cyBoYXZlIGJlZW4gbGVhcm50DQpPcGVyYXRpb25hbGx5IEnigJltIHN0cm9uZ2x5IGZvciAjMiwg aW4gY2FzZSBvZiBJU0lTIHBvc3NpYmx5IHVuZGVyIEFGLg0KDQpDaGVlcnMsDQpKZWZmDQoNCkZy b206IHNwcmluZyA8c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZy1ib3VuY2Vz QGlldGYub3JnPj4gb24gYmVoYWxmIG9mIFN0ZXBoYW5lIExpdGtvd3NraSA8c3RlcGhhbmUubGl0 a293c2tpQG9yYW5nZS5jb208bWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPj4N CkRhdGU6IFdlZG5lc2RheSwgSnVseSAyMiwgMjAxNSBhdCA3OjE5IFBNDQpUbzogInNwcmluZ0Bp ZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPiIgPHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86 c3ByaW5nQGlldGYub3JnPj4NClN1YmplY3Q6IFtzcHJpbmddIE1vZGVsaW5nIFNSR0IgY29uZmln dXJhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFuZw0KDQpIaSBXRywNCg0KSW4gdGhl IGN1cnJlbnQgdmVyc2lvbiBvZiB0aGUgY29uZmlnIFlhbmcgbW9kZWwgZm9yIFNSLCB0aGUgU1JH QiBsaXN0IGlzIGNvbmZpZ3VyZWQgYXQgU1IgdG9wIGxldmVsLCBzbyBpdCBpcyBhZ25vc3RpYyB0 byB0aGUgcm91dGluZyBwcm90b2NvbC4NCldlIGhhZCBzb21lIGNvbW1lbnQgaW4gRGFsbGFzIG9u IGRpZmZpY3VsdGllcyB0aGF0IGhhdmluZyBjb21tb24gbGFiZWwgcmFuZ2Ugc2hhcmVkIGJldHdl ZW4gcHJvdG9jb2xzIGNvdWxkIGxlYWQgdG8uDQpEdXJpbmcgZGlzY3Vzc2lvbiBpbiBvdXIgZGVz aWduIHRlYW0sIHNvbWUgcG9pbnQgd2FzIGFsc28gcmFpc2VkIG9uIHJvdXRpbmcgcHJvdG9jb2wg bWlncmF0aW9ucyB0aGF0IG1heSBiZSBzYWZlciB1c2luZyBhIHBlciBwcm90b2NvbCBTUkdCIChz byBjb25maWd1cmF0aW9uIHRoZSBTUkdCIGF0IElHUCBsZXZlbCByYXRoZXIgdGhhbiBnbG9iYWxs eSkuDQoNCldlIHdvdWxkIGxpa2UgdG8gaGVhciBmcm9tIHRoZSBXRyBhYm91dCB0aGUgcHJlZmVy ZW5jZSBhbmQgYXJndW1lbnRzIGZvciBib3RoIGFwcHJvYWNoZXMgOg0KQXBwcm9hY2ggMSkga2Vl cCBTUkdCIGNvbmZpZ3VyYXRpb24gYXQgdG9wIGxldmVsLCBhbmQgc28gcm91dGluZyBwcm90b2Nv bHMgd2lsbCBzaGFyZSB0aGUgc2FtZSBsYWJlbCBzcGFjZSAodG9kYXkgcHJvcG9zYWwpDQpBcHBy b2FjaCAyKSBtb3ZlIFNSR0IgY29uZmlndXJhdGlvbiB0byBwcm90b2NvbHMsIGVhY2ggcm91dGlu ZyBwcm90b2NvbCBtYW5hZ2VzIGl0cyBvd24gbGFiZWwgc3BhY2UuDQoNClRoYW5rcyB0byBwcm92 aWRlIHlvdXIgZmVlZGJhY2sgaW4gb3JkZXIgdG8gc29sdmUgdGhpcyBpc3N1ZSBhbmQgaGF2ZSBh IGNvbnNlbnN1cy4NCg0KDQpbT3JhbmdlIGxvZ29dPGh0dHA6Ly93d3cub3JhbmdlLmNvbS8+DQoN ClN0ZXBoYW5lIExpdGtvd3NraQ0KTmV0d29yayBBcmNoaXRlY3QNCk9yYW5nZS9TQ0UvRVFVQU5U L0lCTkYvRU5ERC9OREUNCk9yYW5nZSBFeHBlcnQgRnV0dXJlIE5ldHdvcmtzDQpwaG9uZTogKzMz IDIgMjMgMjggNDkgODMgPGh0dHBzOi8vbW9uc2kuc3NvLmZyYW5jZXRlbGVjb20uZnIvaW5kZXgu YXNwP3RhcmdldD1odHRwJTNBJTJGJTJGY2xpY3ZvaWNlLnNzby5mcmFuY2V0ZWxlY29tLmZyJTJG Q2xpY3ZvaWNlVjIlMkZUb29sQmFyLmRvJTNGYWN0aW9uJTNEZGVmYXVsdCUyNnJvb3RzZXJ2aWNl JTNEU0lHTkFUVVJFJTI2dG8lM0QrMzMlMjAyJTIwMjMlMjAyOCUyMDQ5JTIwODMlMjA+DQptb2Jp bGU6ICszMyA2IDM3IDg2IDk3IDUyIDxodHRwczovL21vbnNpLnNzby5mcmFuY2V0ZWxlY29tLmZy L2luZGV4LmFzcD90YXJnZXQ9aHR0cCUzQSUyRiUyRmNsaWN2b2ljZS5zc28uZnJhbmNldGVsZWNv bS5mciUyRkNsaWN2b2ljZVYyJTJGVG9vbEJhci5kbyUzRmFjdGlvbiUzRGRlZmF1bHQlMjZyb290 c2VydmljZSUzRFNJR05BVFVSRSUyNnRvJTNEKzMzJTIwNiUyMDM3JTIwODYlMjA5NyUyMDUyJTIw Pg0Kc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208bWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3Nr aUBvcmFuZ2UuY29tPg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGll bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1 c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXog cmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdl eHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExl cyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24s DQoNCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBl dGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hv dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0 aW9uLg0KDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cy4NCg0KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBm b3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVk Lg0KDQpUaGFuayB5b3UuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBv dSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhw bG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2Ug bWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KYSBsJ2V4cGVkaXRldXIg ZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2Vz IGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCk9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmli dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KSWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQpBcyBlbWFpbHMgbWF5 IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUg YmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQpUaGFuayB5b3UuDQoNCg== --_000_D1E1533A29F18aceeciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <99344E8EAEEB674982EBA308D96938F8@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiPg0KPGRpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyI+SGkgU3RlcGhhbmUsPC9zcGFuPjwvZGl2Pg0K PGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD48L2Rpdj4N CjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5XaGlsZSB0aGVyZSBtYXkgYmUg dHJhbnNpdGlvbmFsIHVzZSBjYXNlcyB3aGVyZSB0aGVyZSBpcyBhIHJlcXVpcmVtZW50IHRvIGFs bG9jYXRlJm5ic3A7PC9mb250PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fu cy1zZXJpZjsiPmRpZmZlcmVudCBTUkdCcyB0byBkaWZmZXJlbnQgcHJvdG9jb2xzIGluc3RhbmNl cywgSSBkb27igJl0IGJlbGlldmUgd2UmbmJzcDs8L3NwYW4+PGZvbnQgZmFjZT0iQ2FsaWJyaSxz YW5zLXNlcmlmIj5zaG91bGQmbmJzcDvigJx0aHJvdw0KIHRoZSBiYWJ5IG91dCB3aXRoIHRoZSBi YXRod2F0ZXLigJ0gYW5kIHJlbW92ZSB0aGUgZ2xvYmFsIFNSR0IgY29uZmlndXJhdGlvbi4gVGhl IG9wZXJhdGlvbmFsIHNpbXBsaWNpdHkgYW5kIG1hbmFnYWJpbGl0eSBhZHZhbnRhZ2VzIG9mIGhh dmluZyBhIHNpbmdsZSBTUkdCIGZvciB0aGUgbm9kZSBhcmUgdW5kZW5pYWJsZS4gVGhlIGJlbmVm aXRzIGFyZSBtdWx0aXBsaWVkIGlmIG9uZSBjYW4gbWFpbnRhaW4gYSBjb25zaXN0ZW50IFNSR0Ig dGhyb3VnaG91dA0KIHRoZSBzZWdtZW50IHJvdXRpbmcgZG9tYWluIChhbHRob3VnaCZuYnNwO0kg dW5kZXJzdGFuZCB0aGF0IHRoaXMgaXMgbm90IGFsd2F5cyBwb3NzaWJsZSkuJm5ic3A7PC9mb250 PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJpLHNhbnMtc2VyaWYiPjxicj4NCjwvZm9u dD48L2Rpdj4NCjxkaXY+PGZvbnQgZmFjZT0iQ2FsaWJyaSxzYW5zLXNlcmlmIj5IZW5jZSwgSSBi ZWxpZXZlIHdlIHNob3VsZCByZXRhaW4gdGhlIGdsb2JhbCBTUkdCIGNvbmZpZ3VyYXRpb24gaTwv Zm9udD48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5uIHRo ZSBZQU5HIG1vZGVsLiBJbiB0aGUgcHJvdG9jb2xzLCB0aGUgZ2xvYmFsIFNSR0Igd291bGQgYmUg aW5oZXJpdGVkIG9yLCBpZiBjb25maWd1cmVkLCZuYnNwOzwvc3Bhbj48Zm9udCBmYWNlPSJDYWxp YnJpLHNhbnMtc2VyaWYiPm92ZXJ3cml0dGVuDQogYnkgcHJvdG9jb2wgY29uZmlndXJhdGlvbi4g SWYgd2UgY2Fubm90IGFncmVlIG9uIGVpdGhlciBiZWluZyZuYnNwOzwvZm9udD48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7Ij5tYW5kYXRvcnksIGJvdGggY291 bGQgYmUgWUFORyBmZWF0dXJlcy48L3NwYW4+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGli cmksc2Fucy1zZXJpZiI+PGJyPg0KPC9mb250PjwvZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxp YnJpLHNhbnMtc2VyaWYiPlRoYW5rcyw8L2ZvbnQ+PC9kaXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNh bGlicmksc2Fucy1zZXJpZiI+QWNlZSZuYnNwOzwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPGRpdiBz dHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTRweDsiPg0KPGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19C T0RZX1NFQ1RJT04iIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxNHB4OyI+DQo8ZGl2IHN0eWxlPSJmb250LWZh bWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFj azsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsg UEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBp bjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5v bmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZy b206IDwvc3Bhbj5zcHJpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmctYm91bmNlc0BpZXRm Lm9yZyI+c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgU3RlcGhh bmUgTGl0a293c2tpICZsdDs8YSBocmVmPSJtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5n ZS5jb20iPnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPC9hPiZndDs8YnI+DQo8c3BhbiBz dHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPkZyaWRheSwgSnVseSAzMSwgMjAx NSBhdCAzOjUyIEFNPGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3Nw YW4+SmVmZiBUYW50c3VyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmplZmYudGFudHN1cmFAZXJpY3Nz b24uY29tIj5qZWZmLnRhbnRzdXJhQGVyaWNzc29uLmNvbTwvYT4mZ3Q7LCAmcXVvdDs8YSBocmVm PSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86c3ByaW5nQGlldGYub3JnIj5zcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0Ozxi cj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0OiA8L3NwYW4+UmU6IFtz cHJpbmddIE1vZGVsaW5nIFNSR0IgY29uZmlndXJhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zcHJpbmct c3IteWFuZzxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGlkPSJN QUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9SREVSLUxFRlQ6ICNi NWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAgNTsiPg0KPGRpdiB4 bWxuczp2PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOnZtbCIgeG1sbnM6bz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQu Y29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9SRUMt aHRtbDQwIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQg MTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtpZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZp b3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7 fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1 cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwhW2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBG b250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9 DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2 Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2lu OjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2 Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9 DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBU ZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1hdHRl ZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0K CWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10 eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8ZGl2IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+TG9va3MgdGhh dCBjb25zZW5zdXMgaXMgZm9yIG9wdGlvbiMyLCBzbyBsZXTigJlzIG1vdmUgU1JHQiB0byBwcm90 b2NvbCBjb25maWd1cmF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEw cHQ7IGZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6IFRhaG9tYSwgc2Fucy1zZXJp ZjsiPiBKZWZmIFRhbnRzdXJhIFs8YSBocmVmPSJtYWlsdG86amVmZi50YW50c3VyYUBlcmljc3Nv bi5jb20iPm1haWx0bzpqZWZmLnRhbnRzdXJhQGVyaWNzc29uLmNvbTwvYT5dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gRnJpZGF5LCBKdWx5IDMxLCAyMDE1IDA4OjA0PGJyPg0KPGI+VG86PC9iPiBMSVRL T1dTS0kgU3RlcGhhbmUgU0NFL0lCTkY7IDxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmci PnNwcmluZ0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzcHJpbmddIE1v ZGVsaW5nIFNSR0IgY29uZmlndXJhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFuZzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5IaSw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkFyY2hpdGVjdHVyYWxseSBJ IGFncmVlIOKAkyBsYWJlbCBtYW5hZ2VyIHNob3VsZG7igJl0IGNhcmUgbGVzcyBob3cgbGFiZWxz IGhhdmUgYmVlbiBsZWFybnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpi bGFjayI+T3BlcmF0aW9uYWxseSBJ4oCZbSBzdHJvbmdseSBmb3IgIzIsIGluIGNhc2Ugb2YgSVNJ UyBwb3NzaWJseSB1bmRlciBBRi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Nv bG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6 YmxhY2siPkplZmY8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1 QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDtt YXJnaW4tcmlnaHQ6MGluIiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPnNwcmluZyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZy1i b3VuY2VzQGlldGYub3JnIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7IG9uIGJlaGFs ZiBvZiBTdGVwaGFuZSBMaXRrb3dza2kgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGVwaGFuZS5saXRr b3dza2lAb3JhbmdlLmNvbSI+c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb208L2E+Jmd0Ozxi cj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEp1bHkgMjIsIDIwMTUgYXQgNzoxOSBQTTxicj4N CjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5n QGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+ c3ByaW5nQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+W3NwcmluZ10gTW9k ZWxpbmcgU1JHQiBjb25maWd1cmF0aW9uIGZvciBkcmFmdC1pZXRmLXNwcmluZy1zci15YW5nPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDtt YXJnaW4tbGVmdDozLjc1cHQ7bWFyZ2luLXJpZ2h0OjBpbiIgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJ QlVUSU9OX0JMT0NLUVVPVEUiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkhpIFdHLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5JbiB0aGUgY3VycmVudCB2ZXJzaW9uIG9mIHRoZSBjb25maWcgWWFuZyBtb2RlbCBm b3IgU1IsIHRoZSBTUkdCIGxpc3QgaXMgY29uZmlndXJlZCBhdCBTUiB0b3AgbGV2ZWwsIHNvIGl0 IGlzIGFnbm9zdGljIHRvIHRoZSByb3V0aW5nIHByb3RvY29sLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+V2UgaGFk IHNvbWUgY29tbWVudCBpbiBEYWxsYXMgb24gZGlmZmljdWx0aWVzIHRoYXQgaGF2aW5nIGNvbW1v biBsYWJlbCByYW5nZSBzaGFyZWQgYmV0d2VlbiBwcm90b2NvbHMgY291bGQgbGVhZCB0by48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPkR1cmluZyBkaXNjdXNzaW9uIGluIG91ciBkZXNpZ24gdGVhbSwgc29tZSBwb2lu dCB3YXMgYWxzbyByYWlzZWQgb24gcm91dGluZyBwcm90b2NvbCBtaWdyYXRpb25zIHRoYXQgbWF5 IGJlIHNhZmVyIHVzaW5nIGEgcGVyIHByb3RvY29sIFNSR0IgKHNvIGNvbmZpZ3VyYXRpb24gdGhl IFNSR0IgYXQgSUdQIGxldmVsIHJhdGhlciB0aGFuIGdsb2JhbGx5KS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+V2Ugd291bGQgbGlrZSB0byBoZWFyIGZyb20gdGhlIFdHIGFib3V0 IHRoZSBwcmVmZXJlbmNlIGFuZCBhcmd1bWVudHMgZm9yIGJvdGggYXBwcm9hY2hlcyA6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5BcHByb2FjaCAxKSBrZWVwIFNSR0IgY29uZmlndXJhdGlvbiBhdCB0b3AgbGV2ZWws IGFuZCBzbyByb3V0aW5nIHByb3RvY29scyB3aWxsIHNoYXJlIHRoZSBzYW1lIGxhYmVsIHNwYWNl ICh0b2RheSBwcm9wb3NhbCk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkFwcHJvYWNoIDIpIG1vdmUgU1JHQiBjb25m aWd1cmF0aW9uIHRvIHByb3RvY29scywgZWFjaCByb3V0aW5nIHByb3RvY29sIG1hbmFnZXMgaXRz IG93biBsYWJlbCBzcGFjZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhhbmtz IHRvIHByb3ZpZGUgeW91ciBmZWVkYmFjayBpbiBvcmRlciB0byBzb2x2ZSB0aGlzIGlzc3VlIGFu ZCBoYXZlIGEgY29uc2Vuc3VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxhIGhyZWY9Imh0dHA6Ly93d3cub3JhbmdlLmNvbS8iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2Vy aWY7IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iNDAiIGhl aWdodD0iNDAiIGlkPSJQaWN0dXJlX3gwMDIwXzEiIHNyYz0iY2lkOmltYWdlMDAxLmdpZkAwMUQw Q0I3RS5FRjdGMjc3MCIgYWx0PSJPcmFuZ2UgbG9nbyI+PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyBjb2xvcjogYmxhY2s7Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMt c2VyaWY7IGNvbG9yOiBibGFjazsiPlN0ZXBoYW5lIExpdGtvd3NraQ0KPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyBjb2xvcjogYmxhY2s7Ij48YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZTogMTBwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogYmxhY2s7Ij5O ZXR3b3JrIEFyY2hpdGVjdA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7IGZv bnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7IGNvbG9yOiBibGFjazsiPjxicj4N Cjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWws IHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPk9yYW5nZS9TQ0UvRVFVQU5UL0lCTkYvRU5ERC9O REUNCjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl OiAxMHB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGNvbG9yOiBibGFjazsiPk9y YW5nZSBFeHBlcnQgRnV0dXJlIE5ldHdvcmtzPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1z ZXJpZjsgY29sb3I6IGJsYWNrOyI+cGhvbmU6DQo8YSBocmVmPSJodHRwczovL21vbnNpLnNzby5m cmFuY2V0ZWxlY29tLmZyL2luZGV4LmFzcD90YXJnZXQ9aHR0cCUzQSUyRiUyRmNsaWN2b2ljZS5z c28uZnJhbmNldGVsZWNvbS5mciUyRkNsaWN2b2ljZVYyJTJGVG9vbEJhci5kbyUzRmFjdGlvbiUz RGRlZmF1bHQlMjZyb290c2VydmljZSUzRFNJR05BVFVSRSUyNnRvJTNEJiM0MzszMyUyMDIlMjAy MyUyMDI4JTIwNDklMjA4MyUyMCI+DQo8c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPiYjNDM7MzMgMiAyMyAyOCA0OSA4MyA8L3NwYW4+PC9hPjwvc3Bhbj48c3Bh biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyI+PGJyPg0KPC9zcGFuPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0iZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2Vy aWY7IGNvbG9yOiBibGFjazsiPm1vYmlsZToNCjxhIGhyZWY9Imh0dHBzOi8vbW9uc2kuc3NvLmZy YW5jZXRlbGVjb20uZnIvaW5kZXguYXNwP3RhcmdldD1odHRwJTNBJTJGJTJGY2xpY3ZvaWNlLnNz by5mcmFuY2V0ZWxlY29tLmZyJTJGQ2xpY3ZvaWNlVjIlMkZUb29sQmFyLmRvJTNGYWN0aW9uJTNE ZGVmYXVsdCUyNnJvb3RzZXJ2aWNlJTNEU0lHTkFUVVJFJTI2dG8lM0QmIzQzOzMzJTIwNiUyMDM3 JTIwODYlMjA5NyUyMDUyJTIwIj4NCjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjazt0ZXh0LWRlY29y YXRpb246bm9uZSI+JiM0MzszMyA2IDM3IDg2IDk3IDUyIDwvc3Bhbj48L2E+PC9zcGFuPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyBjb2xvcjogYmxhY2s7Ij48YnI+DQo8YSBocmVmPSJtYWlsdG86c3Rl cGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEwcHQ7 IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigyNTUsIDEwMiwgMCk7 IHRleHQtZGVjb3JhdGlvbjogbm9uZTsiPnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPC9z cGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48 c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1l cyBOZXcgUm9tYW4nLCBzZXJpZjsgY29sb3I6IGJsYWNrOyI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+X19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnBhcyBl dHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2 b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVy PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRl cy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJh dGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEg ZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj50aGV5IHNob3VsZCBu b3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5J ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0 aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhhbmsgeW91Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwcmU+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpDZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMN CnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9u LiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNp Z25hbGVyDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLA0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2Ug bWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KDQpUaGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3Ig cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KdGhl eSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhv cmlzYXRpb24uDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cy4NCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUg Zm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmll ZC4NClRoYW5rIHlvdS4NCjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv c3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D1E1533A29F18aceeciscocom_-- --_004_D1E1533A29F18aceeciscocom_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: attachment; filename="image001.gif"; size=381; creation-date="Fri, 31 Jul 2015 20:40:51 GMT"; modification-date="Fri, 31 Jul 2015 20:40:51 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhKAAoAMQAAP+MQP+zgP/17//s3/+DMP/iz/+fYP+8j/9wEP95IP/Gn/+WUP/Pr/+pcP/Z v/////9mAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAoACgAAAX6oAONZGmeaEqKauum7Cu/8Wyj9a2P+X73vhkwSCPuhkYVMolj2pbOEjTK oxatrSlVG+U6vUxwUmwkE81BtE99xGbdSjhMPgo4BAoA+wUICAR6IwQODwMNEAcOigAFhQYQDgoD DwcQBJOKBIOFDQmaCCyTB416hQcBBQuTEA8Cow8EBQINpHcGhAkrEAkPChAAD3YPCLuSDw+sIgEP wCILzK0OjY9VBJS/wYQjfwaNyRDLzRAG0AMB5wC6ENyEt8jWDAsCyA/KzJN+zLILqLlVv/OuaYPU alU9cMwuPSCl8AEDYv8EQbwRgAEABcziJFl2bMmeEQgATEwRAgA7 --_004_D1E1533A29F18aceeciscocom_-- From nobody Fri Jul 31 16:15:49 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B8C1ABD3E for ; Fri, 31 Jul 2015 16:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBxEfqUngjQ1 for ; Fri, 31 Jul 2015 16:15:44 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 987781ABD3F for ; Fri, 31 Jul 2015 16:15:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43570; q=dns/txt; s=iport; t=1438384545; x=1439594145; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=6vHqzUjL46fm2vtY/9s/GxW1vJLeq+wRvGqEle7lBso=; b=b50raiWLRwSUvTiNxSX1+Wp4zouf9ETQOLoA+XouSh5qpJGFMMg4p9Ni rupHPiiSmzR7yamSDmJOHd4sw8O0HwR18A5dSVZA0oBGy9XFDs2W83+9k 0bnMezxiyObXTwWQ8qHO/Q7Hf86qdGon9qHeOZpmfg9Dqmyk9D0V4101R I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BqAwBiALxV/5hdJa1bgk1NVGkGgx25GAmBegEJhS9KAhyBFTgUAQEBAQEBAYEKhCMBAQEEAQEBIAo/AggDEAIBCBEBAgEBAQsWAQYDAgICHwYLFAMGCAIEDgUIE4d+AxINsXCQVw2FLwEBAQEBAQEBAQEBAQEBAQEBAQEBARMEi06CToFWEQEgFgoNBAYBBoJjL4EUBZF2gwIBil+DMoQgjCqDS4NkJoN9b4EOOoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,587,1432598400"; d="scan'208,217";a="174412881" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-5.cisco.com with ESMTP; 31 Jul 2015 23:15:44 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id t6VNFhI6000899 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Jul 2015 23:15:43 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.220]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Fri, 31 Jul 2015 18:15:43 -0500 From: "Les Ginsberg (ginsberg)" To: Robert Raszuk Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQyo8uwFjCUSCsTUyfv7l+kq1Lap3zn+CQgABwVICAAiIBIA== Date: Fri, 31 Jul 2015 23:15:42 +0000 Message-ID: References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.211.124] Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F594A743Fxmbalnx02ciscoc_" MIME-Version: 1.0 Archived-At: Cc: "stephane.litkowski@orange.com" , "spring@ietf.org" , Hannes Gredler , Pushpasis Sarkar , Shraddha Hegde Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2015 23:15:48 -0000 --_000_F3ADE4747C9E124B89F0ED2180CC814F594A743Fxmbalnx02ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9iZXJ0IOKAkw0KDQpMYWJlbHMgYXJlIGEgc2hhcmVkIHJlc291cmNlIOKAkyB0aGUgcHJvYmxl bSB5b3UgbWVudGlvbiBiZWxvdyBoYXMgdG8gYmUgYWRkcmVzc2VkIGluZGVwZW5kZW50IG9mIGhv dyBtYW55IFNSR0JzIGFyZSB1c2VkIGluIGFueSBzb2x1dGlvbi4gTm8gcHJvdG9jb2wgaW1wbGVt ZW50YXRpb24g4oCTIHdoZXRoZXIgcGFydCBvZiBhIG1vbm9saXRoaWMgcm91dGVyIHByb2R1Y3Qg b3IgYW4gaW5kZXBlbmRlbnQgaW1wbGVtZW50YXRpb24g4oCTIGNhbiBhc3N1bWUgdGhhdCBpdCBo YXMgZnJlZSByZWluIHRvIHVzZSB3aGF0ZXZlciBTUkdCIHJhbmdlIGl0IHdhbnRzLg0KDQogICBM ZXMNCg0KDQpGcm9tOiBycmFzenVrQGdtYWlsLmNvbSBbbWFpbHRvOnJyYXN6dWtAZ21haWwuY29t XSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0KU2VudDogVGh1cnNkYXksIEp1bHkgMzAsIDIw MTUgMjoxOSBBTQ0KVG86IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpDQpDYzogUHVzaHBhc2lzIFNh cmthcjsgc3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb207IHNwcmluZ0BpZXRmLm9yZzsgU2hy YWRkaGEgSGVnZGU7IEhhbm5lcyBHcmVkbGVyDQpTdWJqZWN0OiBSZTogW3NwcmluZ10gTW9kZWxp bmcgU1JHQiBjb25maWd1cmF0aW9uIGZvciBkcmFmdC1pZXRmLXNwcmluZy1zci15YW5nDQoNCkhp IExlcywNCg0KT25lIGFkZGl0aW9uYWwgcG9pbnQgLi4uDQoNCkFzc3VtZSBJIGFtIHVzaW5nIGEg dmlydHVhbCByb3V0ZXIgd2l0aCBCR1AgbW9kdWxlIGZyb20gdmVuZG9yIEEgYW5kIE9TUEYgbW9k dWxlIGZyb20gdmVuZG9yIEIuIEFzc3VtZSB0aGUgdHJhZGl0aW5hbCBtb25vbGl0aGljIHBoeXNp Y2FsIG9yIHZpcnR1YWwgcm91dGVyIGlzIG5vdCBiZWluZyB1c2VkLg0KDQpXaG8gYW5kIHdoZXJl IHdvdWxkIGltcGxlbWVudCB0aGlzIG5vdGlvbiBvZiAiZ2xvYmFsIFNSR0IgY29uY2VwdCIgPyBI b3cgd291bGQgaXQgdGFsayB0byBwcm90b2NvbHMgPyBXaHkgZG8gSSBuZWVkIHRvIHBheSBub3cg Zm9yIHRoaXMgZnJvbSBwZXJoYXBzIHlldCBvbmUgbW9yZSB2ZW5kb3IgPw0KDQpBcyBsb25nIGFz IEkgaGF2ZSBTUiBjb250cm9sIHBsYW5lIGNvbnRhaW5lZCB3aXRoaW4gcHJvdG9jb2xzIGFuZCBo YXZlIGVhY2ggb2YgdGhlbSBmZWVkaW5nIGRhdGFwbGFuZSAoZGlyZWN0bHkgb3IgdmlhIFJJQikg SSBzaG91bGQgYmUgZmluZS4gU28gSSBhbSBub3Qgc3VyZSB3aHkgZG8gSSBuZWVkIHlldCBvbmUg bW9yZSB1bWJyZWxsYSBTUiBjb29yZGluYXRvciBzdWJzeXN0ZW0gLi4uLg0KDQpCZXN0LA0KUm9i ZXJ0Lg0KDQoNCk9uIFRodSwgSnVsIDMwLCAyMDE1IGF0IDk6NDYgQU0sIExlcyBHaW5zYmVyZyAo Z2luc2JlcmcpIDxnaW5zYmVyZ0BjaXNjby5jb208bWFpbHRvOmdpbnNiZXJnQGNpc2NvLmNvbT4+ IHdyb3RlOg0KUHVzaHBhc3NpcyDigJMNCg0KSXQgaXMgY2xlYXIgdG8gbWUgdGhhdCB3aGF0IHlv dSBwcm9wb3NlIGlzIG1vcmUgY29tcGxleCB0byBpbXBsZW1lbnQgYW5kIG1vcmUgY29zdGx5IGlu IGl0cyBjb25zdW1wdGlvbiBvZiBsYWJlbHMuIFdoYXQgSSBkbyBub3QgeWV0IGFwcHJlY2lhdGUg aXMgd2hhdCBjYXBhYmlsaXRpZXMgcHJvdG9jb2wgc3BlY2lmaWMgU1JHQnMgcHJvdmlkZSB3aGlj aCBjYW5ub3QgYmUgc3VwcG9ydGVkIHVzaW5nIGEgcHJvdG9jb2wgaW5kZXBlbmRlbnQgU1JHQi4g Q291bGQgeW91IHBsZWFzZSBwcm92aWRlIHNvbWUgc3BlY2lmaWMgZXhhbXBsZXM/IFBsZWFzZSBk byBub3QgdXNlIGFuIFJTVlAvTERQIGFuYWxvZ3kg4oCTIHBsZWFzZSB1c2UgYSBwcm9wb3NlZCBT UiBkZXBsb3ltZW50IGNhc2UuDQoNCkJUVywgd2h5IGRvIEkgc2F5IHlvdXIgcHJvcG9zYWwgaXMg bW9yZSBjb21wbGV4L2Nvc3RseT8NCg0KT24gYSBub2RlIHdoZXJlIHJlZGlzdHJpYnV0aW9uIG9m IHJvdXRlcyBpcyBvY2N1cnJpbmcsIHRoZSBzb3VyY2Ugb2YgcmVkaXN0cmlidXRpb24gKHRoZSDi gJxiZXN0IHJvdXRl4oCdKSBvYnZpb3VzbHkgYWxsb2NhdGVzIGEgbG9jYWwgbGFiZWwgYmFzZWQg b24gaXRzIFNSR0IuIEJ1dCBub3cgdGhlIGRlc3RpbmF0aW9uIHByb3RvY29sIGZvciByZWRpc3Ry aWJ1dGlvbiBhbHNvIGhhcyB0byBhbGxvY2F0ZSBhIGxvY2FsIGxhYmVsIGJhc2VkIG9uIGl0cyBT UkdCIGJlY2F1c2UgaXQgaXMgZXhwZWN0ZWQgdGhhdCBuZWlnaGJvcnMgb2YgdGhlIGRlc3RpbmF0 aW9uIHByb3RvY29sIHdpbGwgdXNlIGEgbGFiZWwgZnJvbSB0aGUgZGVzdGluYXRpb24gcHJvdG9j b2wgU1JHQi4gU28sIHlvdSBub3cgaGF2ZSBuZXcgcmVxdWlyZW1lbnRzIG9uIHRoZSBkZXN0aW5h dGlvbiBwcm90b2NvbCBhbmQgeW91IGhhdmUgY29uc3VtZWQgdHdpY2UgYXMgbWFueSBsb2NhbCBs YWJlbHMuIFlvdXIgZm9yd2FyZGluZyBwbGFuZSBub3cgaGFzIHRvIGRlYWwgd2l0aCB0aGUgYWRk ZWQgY29tcGxleGl0eS9jb3N0IOKAkyBhbmQgeW91ciBsYWJlbCBtYW5hZ2VyIGhhcyB0byBtYW5h Z2UgbW9yZSBsYWJlbCByYW5nZXMuDQoNCldoYXQgSSB3YW50IHRvIGtub3cgaXMgd2hhdCBkbyB3 ZSBnYWluIGZvciB0aGlzIGFkZGVkIGNvbXBsZXhpdHk/IFRoYW54Lg0KDQogICBMZXMNCg0KDQpG cm9tOiBQdXNocGFzaXMgU2Fya2FyIFttYWlsdG86cHNhcmthckBqdW5pcGVyLm5ldDxtYWlsdG86 cHNhcmthckBqdW5pcGVyLm5ldD5dDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMjksIDIwMTUgMTE6 MTYgUE0NClRvOiBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKTsgc3RlcGhhbmUubGl0a293c2tpQG9y YW5nZS5jb208bWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPjsgVW1hIENodW5k dXJpOyBBaXNzYW91aSwgTXVzdGFwaGEgKE11c3RhcGhhKTsgc3ByaW5nQGlldGYub3JnPG1haWx0 bzpzcHJpbmdAaWV0Zi5vcmc+OyBTaHJhZGRoYSBIZWdkZTsgSGFubmVzIEdyZWRsZXINClN1Ympl Y3Q6IFJlOiBbc3ByaW5nXSBNb2RlbGluZyBTUkdCIGNvbmZpZ3VyYXRpb24gZm9yIGRyYWZ0LWll dGYtc3ByaW5nLXNyLXlhbmcNCg0KSGkgTGVzLA0KDQpGcm9tOiAiTGVzIEdpbnNiZXJnIChnaW5z YmVyZykiIDxnaW5zYmVyZ0BjaXNjby5jb208bWFpbHRvOmdpbnNiZXJnQGNpc2NvLmNvbT4+DQpE YXRlOiBXZWRuZXNkYXksIEp1bHkgMjksIDIwMTUgYXQgMTE6MDEgUE0NClRvOiAic3RlcGhhbmUu bGl0a293c2tpQG9yYW5nZS5jb208bWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29t PiIgPHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPG1haWx0bzpzdGVwaGFuZS5saXRrb3dz a2lAb3JhbmdlLmNvbT4+LCBVbWEgQ2h1bmR1cmkgPHVtYS5jaHVuZHVyaUBlcmljc3Nvbi5jb208 bWFpbHRvOnVtYS5jaHVuZHVyaUBlcmljc3Nvbi5jb20+PiwgIkFpc3Nhb3VpLCBNdXN0YXBoYSAo TXVzdGFwaGEpIiA8bXVzdGFwaGEuYWlzc2FvdWlAYWxjYXRlbC1sdWNlbnQuY29tPG1haWx0bzpt dXN0YXBoYS5haXNzYW91aUBhbGNhdGVsLWx1Y2VudC5jb20+PiwgInNwcmluZ0BpZXRmLm9yZzxt YWlsdG86c3ByaW5nQGlldGYub3JnPiIgPHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGll dGYub3JnPj4sIFNocmFkZGhhIEhlZ2RlIDxzaHJhZGRoYUBqdW5pcGVyLm5ldDxtYWlsdG86c2hy YWRkaGFAanVuaXBlci5uZXQ+PiwgUHVzaHBhc2lzIFNhcmthciA8cHNhcmthckBqdW5pcGVyLm5l dDxtYWlsdG86cHNhcmthckBqdW5pcGVyLm5ldD4+LCBIYW5uZXMgR3JlZGxlciA8aGFubmVzQGp1 bmlwZXIubmV0PG1haWx0bzpoYW5uZXNAanVuaXBlci5uZXQ+Pg0KU3ViamVjdDogUkU6IFtzcHJp bmddIE1vZGVsaW5nIFNSR0IgY29uZmlndXJhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zcHJpbmctc3It eWFuZw0KDQpTdGVwaGFuZSDigJMNCg0KV2hhdCBpcyB0aGUgcmVxdWlyZW1lbnQgdG8gaGF2ZSBh IHBlci1wcm90b2NvbCBTUkdCIGNvbmZpZz8NClRoaXMgbWFrZXMgbm8gc2Vuc2UgdG8gbWUgb3Bl cmF0aW9uYWxseSBvciBhcmNoaXRlY3R1cmFsbHkuDQpbUHVzaHBhc2lzXSBJbiBjdXJyZW50IE1Q TFMgYXJjaGl0ZWN0dXJlLCB0aGUgc2FtZSBsYWJlbCBpcyBub3QgYWxsb2NhdGVkIGJ5IGJvdGgg UlNWUCBhbmQgTERQIGluIGEgZ2l2ZW4gYm94LiBXaXRoIFNSIG1hcHBlZCB0byBNUExTIGRhdGEt cGxhbmUsIHdlIHdvdWxkIGxpa2UgdG8gcmV0YWluIHRoZSBzYW1lIGJlaGF2aW9yLiBGb3IgdGhl IHNhbWUgZGVzdGluYXRpb24gdGhlIGxhYmVsIGFsbG9jYXRlZCBieSBJU0lTIHNob3VsZCBiZSBk aWZmZXJlbnQgdGhhbiB0aGUgbGFiZWwgYWxsb2NhdGVkIGJ5IE9TUEYuIFRoaXMgY2FuIGJlIGFj aGlldmVkIGluIHR3byB3YXlzOg0KDQogIDEuICBJU0lTIGFuZCBPU1BGIHVzaW5nIHNhbWUgU1JH QnMgYnV0IGRpZmZlcmVudCBpbmRleCByYW5nZXMuDQogIDIuICBJU0lTIGFuZCBPU1BGIHVzaW5n IGRpZmZlcmVudCBTUkdCcyBidXQgY2FuIGhhdmUgdGhlIHNhbWUgaW5kZXggcmFuZ2VzLg0KSSBw cmVmZXIgb3B0aW9uIDIsIGFzIHRoZSBvcGVyYXRvciBkb2VzIG5vdCBuZWVkIHRvIG1haW50YWlu IHR3byBkaWZmZXJlbnQgaW5kZXggcmFuZ2VzIChvbmUgcGVyLXByb3RvY29sKS4NCg0KKEkgYW0g bm90IHRhbGtpbmcgYWJvdXQgd2hhdCBtYXkgb3IgbWF5IG5vdCBoYXZlIGJlZW4gaW1wbGVtZW50 ZWQgYnkgdmVuZG9ycyDigJMgdGhlIFlBTkcgbW9kZWwgc2hvdWxkIGJlIGFyY2hpdGVjdHVyYWxs eSBjb3JyZWN0KQ0KDQogICBMZXMNCg0KDQpGcm9tOiBzdGVwaGFuZS5saXRrb3dza2lAb3Jhbmdl LmNvbTxtYWlsdG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20+IFttYWlsdG86c3RlcGhh bmUubGl0a293c2tpQG9yYW5nZS5jb21dDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMjksIDIwMTUg NToxMSBBTQ0KVG86IFVtYSBDaHVuZHVyaTsgTGVzIEdpbnNiZXJnIChnaW5zYmVyZyk7IEFpc3Nh b3VpLCBNdXN0YXBoYSAoTXVzdGFwaGEpOyBzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0Bp ZXRmLm9yZz47IFNocmFkZGhhIEhlZ2RlIChzaHJhZGRoYUBqdW5pcGVyLm5ldDxtYWlsdG86c2hy YWRkaGFAanVuaXBlci5uZXQ+KTsgUHVzaHBhc2lzIFNhcmthciAocHNhcmthckBqdW5pcGVyLm5l dDxtYWlsdG86cHNhcmthckBqdW5pcGVyLm5ldD4pOyBIYW5uZXMgR3JlZGxlciAoaGFubmVzQGp1 bmlwZXIubmV0PG1haWx0bzpoYW5uZXNAanVuaXBlci5uZXQ+KQ0KU3ViamVjdDogUkU6IFtzcHJp bmddIE1vZGVsaW5nIFNSR0IgY29uZmlndXJhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zcHJpbmctc3It eWFuZw0KDQpIaSBhbGwsDQoNCldoYXQgaWYgd2Uga2VlcCB0aGUgU1JHQiBibG9jayBjb25maWcg aW4g4oCcc2VnbWVudC1yb3V0aW5n4oCdIGdsb2JhbCBtb2R1bGUsIGFuZCBpZiB3ZSBhbGxvdyBm b3IgWUFORyBjb25maWd1cmF0aW9uIG9mIGNhcnZpbmcgdGhpcyBibG9jayBpbnNpZGUgZWFjaCBw cm90b2NvbCAobWF5YmUgYXMgYSBmZWF0dXJlKSA/DQoNClN0ZXBoYW5lDQoNCg0KRnJvbTogVW1h IENodW5kdXJpIFttYWlsdG86dW1hLmNodW5kdXJpQGVyaWNzc29uLmNvbV0NClNlbnQ6IEZyaWRh eSwgSnVseSAyNCwgMjAxNSAxNjo1OQ0KVG86IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpOyBBaXNz YW91aSwgTXVzdGFwaGEgKE11c3RhcGhhKTsgTElUS09XU0tJIFN0ZXBoYW5lIFNDRS9JQk5GOyBz cHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBbc3By aW5nXSBNb2RlbGluZyBTUkdCIGNvbmZpZ3VyYXRpb24gZm9yIGRyYWZ0LWlldGYtc3ByaW5nLXNy LXlhbmcNCg0KPlN1Z2dlc3RpbmcgdGhhdCB0aGUgZm9yd2FyZGluZyBpbnN0cnVjdGlvbiAoQUtB IGxhYmVsKSAgbmVlZHMgdG8gYmUgZGlmZmVyZW50IGRlcGVuZGluZyBvbiB3aGF0IHByb3RvY29s IHByb3ZpZGVkDQo+dGhlIGluc3RydWN0aW9uIGlzIGNvbXBsZXRlbHkgdW5uZWNlc3Nhcnkg4oCT IGl0IHNpbXBseSB3YXN0ZXMgbGFiZWwgc3BhY2UuDQoNCltVbWFdOiBMZXMsIE5vIC0gSSBuZXZl ciBzdWdnZXN0ZWQgYW55dGhpbmcgbGlrZSB0aGF0Lg0KU1JHQiBmb3IgYSByb3V0aW5nIGluc3Rh bmNlIHRvIGJlIGFkdmVydGlzZWQgc2hvdWxkIGJlIHBhcnQgb2YgdGhlIHJvdXRpbmcgaW5zdGFu Y2UgcHJvdmlzaW9uaW5nIGFzIGZhciBhcyB0aGUgeWFuZyBtb2RlbCBpcyBjb25jZXJuZWQuDQpD YXJ2aW5nIG91dCB0aGUgbGFiZWwgc3BhY2UgZm9yIFNSIGlzIGEgbG9jYWwgbWF0dGVyIGFuZCBh Z3JlZSwgb2YgY291cnNlLCB0aGlzICBjYW4gYmUgZG9uZSBpbiBzbyBtYW55IHdheXMgdGhyb3Vn aCBDTEksIGR5bmFtaWNhbGx5LCBzdGF0aWNhbGx5IGV0Yy4uLg0KDQotLQ0KVW1hIEMuDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBj b250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg ZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29w aWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBl cnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1 aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlx dWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBkZWNsaW5lIHRv dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91 IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz IG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQg bWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3UgaGF2ZSBy ZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5k IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1haWxzIG1h eSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZl IGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3UuDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzcHJpbmcgbWFp bGluZyBsaXN0DQpzcHJpbmdAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZ0BpZXRmLm9yZz4NCmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nDQoNCg== --_000_F3ADE4747C9E124B89F0ED2180CC814F594A743Fxmbalnx02ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJz YW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJ bWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv LWxpc3QtaWQ6MTkzNzMyNjg1Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTA3NDA5Njg1MDt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJvYmVydCDigJM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkxhYmVscyBhcmUgYSBzaGFyZWQgcmVzb3VyY2Ug4oCTIHRoZSBwcm9ibGVtIHlvdSBtZW50aW9u IGJlbG93IGhhcyB0byBiZSBhZGRyZXNzZWQgaW5kZXBlbmRlbnQgb2YgaG93IG1hbnkgU1JHQnMg YXJlIHVzZWQgaW4gYW55IHNvbHV0aW9uLiBObyBwcm90b2NvbCBpbXBsZW1lbnRhdGlvbg0KIOKA kyB3aGV0aGVyIHBhcnQgb2YgYSBtb25vbGl0aGljIHJvdXRlciBwcm9kdWN0IG9yIGFuIGluZGVw ZW5kZW50IGltcGxlbWVudGF0aW9uIOKAkyBjYW4gYXNzdW1lIHRoYXQgaXQgaGFzIGZyZWUgcmVp biB0byB1c2Ugd2hhdGV2ZXIgU1JHQiByYW5nZSBpdCB3YW50cy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyBMZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IHJyYXN6dWtAZ21haWwuY29tIFttYWls dG86cnJhc3p1a0BnbWFpbC5jb21dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvYmVydCBSYXN6dWs8 YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEp1bHkgMzAsIDIwMTUgMjoxOSBBTTxicj4NCjxi PlRvOjwvYj4gTGVzIEdpbnNiZXJnIChnaW5zYmVyZyk8YnI+DQo8Yj5DYzo8L2I+IFB1c2hwYXNp cyBTYXJrYXI7IHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tOyBzcHJpbmdAaWV0Zi5vcmc7 IFNocmFkZGhhIEhlZ2RlOyBIYW5uZXMgR3JlZGxlcjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W3NwcmluZ10gTW9kZWxpbmcgU1JHQiBjb25maWd1cmF0aW9uIGZvciBkcmFmdC1pZXRmLXNwcmlu Zy1zci15YW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SGkgTGVzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+T25lIGFkZGl0aW9uYWwgcG9pbnQgLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij5Bc3N1bWUgSSBhbSB1c2luZyBhIHZpcnR1YWwgcm91dGVyIHdpdGggQkdQIG1vZHVsZSBm cm9tIHZlbmRvciBBIGFuZCBPU1BGIG1vZHVsZSBmcm9tIHZlbmRvciBCLiBBc3N1bWUgdGhlIHRy YWRpdGluYWwgbW9ub2xpdGhpYyBwaHlzaWNhbCBvciB2aXJ0dWFsIHJvdXRlciBpcyBub3QgYmVp bmcgdXNlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldobyBhbmQgd2hlcmUgd291 bGQgaW1wbGVtZW50IHRoaXMgbm90aW9uIG9mICZxdW90O2dsb2JhbCBTUkdCIGNvbmNlcHQmcXVv dDsgPyBIb3cgd291bGQgaXQgdGFsayB0byBwcm90b2NvbHMgPyBXaHkgZG8gSSBuZWVkIHRvIHBh eSBub3cgZm9yIHRoaXMgZnJvbSBwZXJoYXBzIHlldCBvbmUgbW9yZSB2ZW5kb3IgPzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QXMgbG9uZyBhcyBJIGhhdmUgU1IgY29udHJvbCBwbGFu ZSBjb250YWluZWQgd2l0aGluIHByb3RvY29scyBhbmQgaGF2ZSBlYWNoIG9mIHRoZW0gZmVlZGlu ZyBkYXRhcGxhbmUgKGRpcmVjdGx5IG9yIHZpYSBSSUIpIEkgc2hvdWxkIGJlIGZpbmUuIFNvIEkg YW0gbm90IHN1cmUgd2h5IGRvIEkgbmVlZCB5ZXQgb25lIG1vcmUgdW1icmVsbGENCiBTUiBjb29y ZGluYXRvciBzdWJzeXN0ZW0gLi4uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+QmVz dCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+Um9iZXJ0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIEp1bCAzMCwgMjAx NSBhdCA5OjQ2IEFNLCBMZXMgR2luc2JlcmcgKGdpbnNiZXJnKSAmbHQ7PGEgaHJlZj0ibWFpbHRv OmdpbnNiZXJnQGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdpbnNiZXJnQGNpc2NvLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5QdXNocGFzc2lzIOKAkzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkl0IGlzIGNsZWFyIHRvIG1lIHRo YXQgd2hhdCB5b3UgcHJvcG9zZSBpcyBtb3JlIGNvbXBsZXggdG8gaW1wbGVtZW50IGFuZCBtb3Jl IGNvc3RseSBpbiBpdHMgY29uc3VtcHRpb24gb2YgbGFiZWxzLiBXaGF0IEkgZG8gbm90IHlldCBh cHByZWNpYXRlIGlzIHdoYXQNCiBjYXBhYmlsaXRpZXMgcHJvdG9jb2wgc3BlY2lmaWMgU1JHQnMg cHJvdmlkZSB3aGljaCBjYW5ub3QgYmUgc3VwcG9ydGVkIHVzaW5nIGEgcHJvdG9jb2wgaW5kZXBl bmRlbnQgU1JHQi4gQ291bGQgeW91IHBsZWFzZSBwcm92aWRlIHNvbWUgc3BlY2lmaWMgZXhhbXBs ZXM/IFBsZWFzZSBkbyBub3QgdXNlIGFuIFJTVlAvTERQIGFuYWxvZ3kg4oCTIHBsZWFzZSB1c2Ug YSBwcm9wb3NlZCBTUiBkZXBsb3ltZW50IGNhc2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Y29sb3I6IzFGNDk3RCI+QlRXLCB3aHkgZG8gSSBzYXkgeW91ciBwcm9wb3NhbCBpcyBtb3JlIGNv bXBsZXgvY29zdGx5Pzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPk9u IGEgbm9kZSB3aGVyZSByZWRpc3RyaWJ1dGlvbiBvZiByb3V0ZXMgaXMgb2NjdXJyaW5nLCB0aGUg c291cmNlIG9mIHJlZGlzdHJpYnV0aW9uICh0aGUg4oCcYmVzdCByb3V0ZeKAnSkgb2J2aW91c2x5 IGFsbG9jYXRlcyBhIGxvY2FsIGxhYmVsIGJhc2VkIG9uIGl0cw0KIFNSR0IuIEJ1dCBub3cgdGhl IGRlc3RpbmF0aW9uIHByb3RvY29sIGZvciByZWRpc3RyaWJ1dGlvbiBhbHNvIGhhcyB0byBhbGxv Y2F0ZSBhIGxvY2FsIGxhYmVsIGJhc2VkIG9uIGl0cyBTUkdCIGJlY2F1c2UgaXQgaXMgZXhwZWN0 ZWQgdGhhdCBuZWlnaGJvcnMgb2YgdGhlIGRlc3RpbmF0aW9uIHByb3RvY29sIHdpbGwgdXNlIGEg bGFiZWwgZnJvbSB0aGUgZGVzdGluYXRpb24gcHJvdG9jb2wgU1JHQi4gU28sIHlvdSBub3cgaGF2 ZSBuZXcgcmVxdWlyZW1lbnRzDQogb24gdGhlIGRlc3RpbmF0aW9uIHByb3RvY29sIGFuZCB5b3Ug aGF2ZSBjb25zdW1lZCB0d2ljZSBhcyBtYW55IGxvY2FsIGxhYmVscy4gWW91ciBmb3J3YXJkaW5n IHBsYW5lIG5vdyBoYXMgdG8gZGVhbCB3aXRoIHRoZSBhZGRlZCBjb21wbGV4aXR5L2Nvc3Qg4oCT IGFuZCB5b3VyIGxhYmVsIG1hbmFnZXIgaGFzIHRvIG1hbmFnZSBtb3JlIGxhYmVsIHJhbmdlcy48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5XaGF0IEkgd2FudCB0byBr bm93IGlzIHdoYXQgZG8gd2UgZ2FpbiBmb3IgdGhpcyBhZGRlZCBjb21wbGV4aXR5PyBUaGFueC48 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgTGVz PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBQdXNocGFzaXMgU2Fya2FyIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnBzYXJrYXJAanVuaXBl ci5uZXQiIHRhcmdldD0iX2JsYW5rIj5wc2Fya2FyQGp1bmlwZXIubmV0PC9hPl0NCjxicj4NCjxi PlNlbnQ6PC9iPiBXZWRuZXNkYXksIEp1bHkgMjksIDIwMTUgMTE6MTYgUE08YnI+DQo8Yj5Ubzo8 L2I+IExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpOyA8YSBocmVmPSJtYWlsdG86c3RlcGhhbmUubGl0 a293c2tpQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj4NCnN0ZXBoYW5lLmxpdGtvd3NraUBv cmFuZ2UuY29tPC9hPjsgVW1hIENodW5kdXJpOyBBaXNzYW91aSwgTXVzdGFwaGEgKE11c3RhcGhh KTsgPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPg0Kc3By aW5nQGlldGYub3JnPC9hPjsgU2hyYWRkaGEgSGVnZGU7IEhhbm5lcyBHcmVkbGVyPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBbc3ByaW5nXSBNb2RlbGluZyBTUkdCIGNvbmZpZ3VyYXRpb24gZm9y IGRyYWZ0LWlldGYtc3ByaW5nLXNyLXlhbmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkhpIExlcyw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZxdW90O0xlcyBHaW5zYmVyZyAoZ2luc2JlcmcpJnF1b3Q7ICZsdDs8 YSBocmVmPSJtYWlsdG86Z2luc2JlcmdAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+Z2luc2Jl cmdAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+V2VkbmVzZGF5LCBKdWx5IDI5 LCAyMDE1IGF0IDExOjAxIFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86 c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5zdGVwaGFuZS5s aXRrb3dza2lAb3JhbmdlLmNvbTwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzdGVwaGFu ZS5saXRrb3dza2lAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXBoYW5lLmxpdGtvd3Nr aUBvcmFuZ2UuY29tPC9hPiZndDssIFVtYSBDaHVuZHVyaSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnVt YS5jaHVuZHVyaUBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj51bWEuY2h1bmR1cmlAZXJp Y3Nzb24uY29tPC9hPiZndDssDQogJnF1b3Q7QWlzc2FvdWksIE11c3RhcGhhIChNdXN0YXBoYSkm cXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzptdXN0YXBoYS5haXNzYW91aUBhbGNhdGVsLWx1Y2Vu dC5jb20iIHRhcmdldD0iX2JsYW5rIj5tdXN0YXBoYS5haXNzYW91aUBhbGNhdGVsLWx1Y2VudC5j b208L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPnNwcmluZ0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpz cHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+Jmd0OywN CiBTaHJhZGRoYSBIZWdkZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNocmFkZGhhQGp1bmlwZXIubmV0 IiB0YXJnZXQ9Il9ibGFuayI+c2hyYWRkaGFAanVuaXBlci5uZXQ8L2E+Jmd0OywgUHVzaHBhc2lz IFNhcmthciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnBzYXJrYXJAanVuaXBlci5uZXQiIHRhcmdldD0i X2JsYW5rIj5wc2Fya2FyQGp1bmlwZXIubmV0PC9hPiZndDssIEhhbm5lcyBHcmVkbGVyICZsdDs8 YSBocmVmPSJtYWlsdG86aGFubmVzQGp1bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+aGFubmVz QGp1bmlwZXIubmV0PC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UkU6IFtzcHJpbmddIE1v ZGVsaW5nIFNSR0IgY29uZmlndXJhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFuZzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TdGVwaGFuZSDigJM8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5XaGF0IGlzIHRoZSByZXF1aXJlbWVudCB0 byBoYXZlIGEgcGVyLXByb3RvY29sIFNSR0IgY29uZmlnPzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlRoaXMgbWFrZXMgbm8gc2Vuc2UgdG8gbWUgb3BlcmF0 aW9uYWxseSBvciBhcmNoaXRlY3R1cmFsbHkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5bUHVzaHBhc2lzXSBJbiBjdXJyZW50IE1QTFMgYXJj aGl0ZWN0dXJlLCB0aGUgc2FtZSBsYWJlbCBpcyBub3QgYWxsb2NhdGVkIGJ5IGJvdGggUlNWUCBh bmQgTERQIGluIGEgZ2l2ZW4gYm94LiBXaXRoIFNSIG1hcHBlZCB0byBNUExTDQogZGF0YS1wbGFu ZSwgd2Ugd291bGQgbGlrZSB0byByZXRhaW4gdGhlIHNhbWUgYmVoYXZpb3IuIEZvciB0aGUgc2Ft ZSBkZXN0aW5hdGlvbiB0aGUgbGFiZWwgYWxsb2NhdGVkIGJ5IElTSVMgc2hvdWxkIGJlIGRpZmZl cmVudCB0aGFuIHRoZSBsYWJlbCBhbGxvY2F0ZWQgYnkgT1NQRi4gVGhpcyBjYW4gYmUgYWNoaWV2 ZWQgaW4gdHdvIHdheXM6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8b2wgc3RhcnQ9 IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFjaztt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+SVNJUyBh bmQgT1NQRiB1c2luZyBzYW1lIFNSR0JzIGJ1dCBkaWZmZXJlbnQgaW5kZXggcmFuZ2VzLjwvc3Bh bj48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjpibGFj azttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+SVNJ UyBhbmQgT1NQRiB1c2luZyBkaWZmZXJlbnQgU1JHQnMgYnV0IGNhbiBoYXZlIHRoZSBzYW1lIGlu ZGV4IHJhbmdlcy48L3NwYW4+PG86cD48L286cD48L2xpPjwvb2w+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+ SSBwcmVmZXIgb3B0aW9uIDIsIGFzIHRoZSBvcGVyYXRvciBkb2VzIG5vdCBuZWVkIHRvIG1haW50 YWluIHR3byBkaWZmZXJlbnQgaW5kZXggcmFuZ2VzIChvbmUgcGVyLXByb3RvY29sKS48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ KEkgYW0gbm90IHRhbGtpbmcgYWJvdXQgd2hhdCBtYXkgb3IgbWF5IG5vdCBoYXZlIGJlZW4gaW1w bGVtZW50ZWQgYnkgdmVuZG9ycyDigJMgdGhlIFlBTkcgbW9kZWwgc2hvdWxkIGJlIGFyY2hpdGVj dHVyYWxseSBjb3JyZWN0KTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PiZuYnNwOyAmbmJzcDtMZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+DQo8YSBocmVmPSJtYWls dG86c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5zdGVwaGFu ZS5saXRrb3dza2lAb3JhbmdlLmNvbTwvYT4gWzxhIGhyZWY9Im1haWx0bzpzdGVwaGFuZS5saXRr b3dza2lAb3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpzdGVwaGFuZS5saXRrb3dz a2lAb3JhbmdlLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdWx5IDI5 LCAyMDE1IDU6MTEgQU08YnI+DQo8Yj5Ubzo8L2I+IFVtYSBDaHVuZHVyaTsgTGVzIEdpbnNiZXJn IChnaW5zYmVyZyk7IEFpc3Nhb3VpLCBNdXN0YXBoYSAoTXVzdGFwaGEpOyA8YSBocmVmPSJtYWls dG86c3ByaW5nQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+DQpzcHJpbmdAaWV0Zi5vcmc8L2E+ OyBTaHJhZGRoYSBIZWdkZSAoPGEgaHJlZj0ibWFpbHRvOnNocmFkZGhhQGp1bmlwZXIubmV0IiB0 YXJnZXQ9Il9ibGFuayI+c2hyYWRkaGFAanVuaXBlci5uZXQ8L2E+KTsgUHVzaHBhc2lzIFNhcmth ciAoPGEgaHJlZj0ibWFpbHRvOnBzYXJrYXJAanVuaXBlci5uZXQiIHRhcmdldD0iX2JsYW5rIj5w c2Fya2FyQGp1bmlwZXIubmV0PC9hPik7IEhhbm5lcyBHcmVkbGVyICg8YSBocmVmPSJtYWlsdG86 aGFubmVzQGp1bmlwZXIubmV0IiB0YXJnZXQ9Il9ibGFuayI+aGFubmVzQGp1bmlwZXIubmV0PC9h Pik8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IFtzcHJpbmddIE1vZGVsaW5nIFNSR0IgY29uZmln dXJhdGlvbiBmb3IgZHJhZnQtaWV0Zi1zcHJpbmctc3IteWFuZzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGkgYWxsLDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPldoYXQgaWYgd2Uga2VlcCB0aGUgU1JHQiBibG9j ayBjb25maWcgaW4g4oCcc2VnbWVudC1yb3V0aW5n4oCdIGdsb2JhbCBtb2R1bGUsIGFuZCBpZiB3 ZSBhbGxvdyBmb3IgWUFORyBjb25maWd1cmF0aW9uIG9mIGNhcnZpbmcgdGhpcyBibG9jayBpbnNp ZGUgZWFjaCBwcm90b2NvbA0KIChtYXliZSBhcyBhIGZlYXR1cmUpID88L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TdGVwaGFuZTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiBVbWENCiBDaHVuZHVyaSBbPGEgaHJl Zj0ibWFpbHRvOnVtYS5jaHVuZHVyaUBlcmljc3Nvbi5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWls dG86dW1hLmNodW5kdXJpQGVyaWNzc29uLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gRnJp ZGF5LCBKdWx5IDI0LCAyMDE1IDE2OjU5PGJyPg0KPGI+VG86PC9iPiBMZXMgR2luc2JlcmcgKGdp bnNiZXJnKTsgQWlzc2FvdWksIE11c3RhcGhhIChNdXN0YXBoYSk7IExJVEtPV1NLSSBTdGVwaGFu ZSBTQ0UvSUJORjsNCjxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj5zcHJpbmdAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBbc3ByaW5n XSBNb2RlbGluZyBTUkdCIGNvbmZpZ3VyYXRpb24gZm9yIGRyYWZ0LWlldGYtc3ByaW5nLXNyLXlh bmc8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzt0ZXh0LWluZGVudDouNWluIj4NCjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj4mZ3Q7U3VnZ2VzdGluZyB0aGF0IHRoZSBmb3J3YXJkaW5nIGlu c3RydWN0aW9uIChBS0EgbGFiZWwpICZuYnNwO25lZWRzIHRvIGJlIGRpZmZlcmVudCBkZXBlbmRp bmcgb24gd2hhdCBwcm90b2NvbCBwcm92aWRlZA0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO3RleHQtaW5kZW50Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZndDt0aGUgaW5zdHJ1Y3Rpb24gaXMgY29tcGxldGVseSB1bm5lY2Vzc2FyeSDi gJMgaXQgc2ltcGx5IHdhc3RlcyBsYWJlbCBzcGFjZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5bVW1hXTogTGVzLCBObyAtIEkgbmV2ZXIgc3VnZ2VzdGVkIGFueXRo aW5nIGxpa2UgdGhhdC4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPlNSR0IgZm9yIGEgcm91dGluZyBpbnN0 YW5jZSB0byBiZSBhZHZlcnRpc2VkIHNob3VsZCBiZSBwYXJ0IG9mIHRoZSByb3V0aW5nIGluc3Rh bmNlIHByb3Zpc2lvbmluZyBhcyBmYXIgYXMgdGhlIHlhbmcgbW9kZWwgaXMgY29uY2VybmVkLg0K PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iY29sb3I6IzFGNDk3RCI+Q2FydmluZyBvdXQgdGhlIGxhYmVsIHNwYWNlIGZvciBTUiBpcyBh IGxvY2FsIG1hdHRlciBhbmQgYWdyZWUsIG9mIGNvdXJzZSwgdGhpcyAmbmJzcDtjYW4gYmUgZG9u ZSBpbiBzbyBtYW55IHdheXMgdGhyb3VnaCBDTEksIGR5bmFtaWNhbGx5LCBzdGF0aWNhbGx5IGV0 Yy4uLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+LS08L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj5VbWEgQy48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkNlIG1l c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0 aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzwv c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnBh cyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT aSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h bGVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFj ayI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl IGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPC9zcGFuPjxvOnA+PC9v OnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZp bGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8L3NwYW4+PG86 cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj50aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48 L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5B cyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdl cyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+VGhhbmsgeW91 Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzcHJpbmcgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYub3JnPC9hPjxicj4NCjxh IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3ByaW5nIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zcHJpbmc8 L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_F3ADE4747C9E124B89F0ED2180CC814F594A743Fxmbalnx02ciscoc_-- From nobody Fri Jul 31 16:18:18 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051F71AC3BF for ; Fri, 31 Jul 2015 16:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mJHPGs_v_HG for ; Fri, 31 Jul 2015 16:18:14 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBBF51AC3BA for ; Fri, 31 Jul 2015 16:18:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35668; q=dns/txt; s=iport; t=1438384693; x=1439594293; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=NR1cZsL0XkCb56KfKRlMpRoSFF3JTZ0IJ2D+walorKE=; b=BqItUsS1kGj54JlmL3UTZ/+xQKMDSzT1cpYmi4pwdsZ3Osfp8AwQVnEq XGnfY3QfA2FJg9F+WOSP/uZSOMSci7qqwx5wwV/ERxoZ5u4NcSNvS/71Q 12iSL9CuC62e3iRl9Co/An64LW2P02hC4CkOWF55ukmZmAEOTC5JHoloQ Q=; X-Files: image001.gif : 381 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0BPBgC7AbxV/4YNJK1bgk1NVGkGgx24IEM1CYIBhXwCHIEVOBQBAQEBAQEBgQqEIwEBAQQFAR0CCAE2BxwCAgEIBwoDAQEBBgECAhYHAwICAgUQAQMCCQwUCQgCBAERAQYCBogLAxINsXWQVwOFOQEBAQEBAQEBAQEBAQEBAQEBAQEBARcEi0qEJBEBIAURCgwBCgEGgmMvgRQFjQuEa4IdZQGEEQFogmKGNUaDWo91g2Qmgg4cgVNvAQEBAYEKOoEEAQEB X-IronPort-AV: E=Sophos;i="5.15,587,1432598400"; d="gif'147?scan'147,208,217,147";a="16770400" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP; 31 Jul 2015 23:18:12 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id t6VNICfG023762 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Jul 2015 23:18:12 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.220]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Fri, 31 Jul 2015 18:18:12 -0500 From: "Les Ginsberg (ginsberg)" To: "Acee Lindem (acee)" , "stephane.litkowski@orange.com" , Jeff Tantsura , "spring@ietf.org" Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQxUX8bOSCn6yWgUicwmRruSnwt531do2AgAAvEACAAMYIgP//19DA Date: Fri, 31 Jul 2015 23:18:11 +0000 Message-ID: References: <4670_1438332725_55BB3735_4670_3351_1_9E32478DFA9976438E7A22F69B08FF92166BAE79@OPEXCLILMA4.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.24.211.124] Content-Type: multipart/related; boundary="_004_F3ADE4747C9E124B89F0ED2180CC814F594A7458xmbalnx02ciscoc_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2015 23:18:17 -0000 --_004_F3ADE4747C9E124B89F0ED2180CC814F594A7458xmbalnx02ciscoc_ Content-Type: multipart/alternative; boundary="_000_F3ADE4747C9E124B89F0ED2180CC814F594A7458xmbalnx02ciscoc_" --_000_F3ADE4747C9E124B89F0ED2180CC814F594A7458xmbalnx02ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSB2ZXJ5IHN0cm9uZyDigJwrMeKAnSB0byB3aGF0IEFjZWUgaGFzIHNhaWQuDQoNCiAgIExlcw0K DQoNCkZyb206IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgQWNlZSBMaW5kZW0gKGFjZWUpDQpTZW50OiBGcmlkYXksIEp1bHkgMzEsIDIwMTUgMTo0 MSBQTQ0KVG86IHN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tOyBKZWZmIFRhbnRzdXJhOyBz cHJpbmdAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc3ByaW5nXSBNb2RlbGluZyBTUkdCIGNvbmZp Z3VyYXRpb24gZm9yIGRyYWZ0LWlldGYtc3ByaW5nLXNyLXlhbmcNCg0KSGkgU3RlcGhhbmUsDQoN CldoaWxlIHRoZXJlIG1heSBiZSB0cmFuc2l0aW9uYWwgdXNlIGNhc2VzIHdoZXJlIHRoZXJlIGlz IGEgcmVxdWlyZW1lbnQgdG8gYWxsb2NhdGUgZGlmZmVyZW50IFNSR0JzIHRvIGRpZmZlcmVudCBw cm90b2NvbHMgaW5zdGFuY2VzLCBJIGRvbuKAmXQgYmVsaWV2ZSB3ZSBzaG91bGQg4oCcdGhyb3cg dGhlIGJhYnkgb3V0IHdpdGggdGhlIGJhdGh3YXRlcuKAnSBhbmQgcmVtb3ZlIHRoZSBnbG9iYWwg U1JHQiBjb25maWd1cmF0aW9uLiBUaGUgb3BlcmF0aW9uYWwgc2ltcGxpY2l0eSBhbmQgbWFuYWdh YmlsaXR5IGFkdmFudGFnZXMgb2YgaGF2aW5nIGEgc2luZ2xlIFNSR0IgZm9yIHRoZSBub2RlIGFy ZSB1bmRlbmlhYmxlLiBUaGUgYmVuZWZpdHMgYXJlIG11bHRpcGxpZWQgaWYgb25lIGNhbiBtYWlu dGFpbiBhIGNvbnNpc3RlbnQgU1JHQiB0aHJvdWdob3V0IHRoZSBzZWdtZW50IHJvdXRpbmcgZG9t YWluIChhbHRob3VnaCBJIHVuZGVyc3RhbmQgdGhhdCB0aGlzIGlzIG5vdCBhbHdheXMgcG9zc2li bGUpLg0KDQpIZW5jZSwgSSBiZWxpZXZlIHdlIHNob3VsZCByZXRhaW4gdGhlIGdsb2JhbCBTUkdC IGNvbmZpZ3VyYXRpb24gaW4gdGhlIFlBTkcgbW9kZWwuIEluIHRoZSBwcm90b2NvbHMsIHRoZSBn bG9iYWwgU1JHQiB3b3VsZCBiZSBpbmhlcml0ZWQgb3IsIGlmIGNvbmZpZ3VyZWQsIG92ZXJ3cml0 dGVuIGJ5IHByb3RvY29sIGNvbmZpZ3VyYXRpb24uIElmIHdlIGNhbm5vdCBhZ3JlZSBvbiBlaXRo ZXIgYmVpbmcgbWFuZGF0b3J5LCBib3RoIGNvdWxkIGJlIFlBTkcgZmVhdHVyZXMuDQoNClRoYW5r cywNCkFjZWUNCg0KRnJvbTogc3ByaW5nIDxzcHJpbmctYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86 c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgU3RlcGhhbmUgTGl0a293c2tp IDxzdGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbTxtYWlsdG86c3RlcGhhbmUubGl0a293c2tp QG9yYW5nZS5jb20+Pg0KRGF0ZTogRnJpZGF5LCBKdWx5IDMxLCAyMDE1IGF0IDM6NTIgQU0NClRv OiBKZWZmIFRhbnRzdXJhIDxqZWZmLnRhbnRzdXJhQGVyaWNzc29uLmNvbTxtYWlsdG86amVmZi50 YW50c3VyYUBlcmljc3Nvbi5jb20+PiwgInNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGll dGYub3JnPiIgPHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3JnPj4NClN1Ympl Y3Q6IFJlOiBbc3ByaW5nXSBNb2RlbGluZyBTUkdCIGNvbmZpZ3VyYXRpb24gZm9yIGRyYWZ0LWll dGYtc3ByaW5nLXNyLXlhbmcNCg0KTG9va3MgdGhhdCBjb25zZW5zdXMgaXMgZm9yIG9wdGlvbiMy LCBzbyBsZXTigJlzIG1vdmUgU1JHQiB0byBwcm90b2NvbCBjb25maWd1cmF0aW9uLg0KDQoNCkZy b206IEplZmYgVGFudHN1cmEgW21haWx0bzpqZWZmLnRhbnRzdXJhQGVyaWNzc29uLmNvbV0NClNl bnQ6IEZyaWRheSwgSnVseSAzMSwgMjAxNSAwODowNA0KVG86IExJVEtPV1NLSSBTdGVwaGFuZSBT Q0UvSUJORjsgc3ByaW5nQGlldGYub3JnPG1haWx0bzpzcHJpbmdAaWV0Zi5vcmc+DQpTdWJqZWN0 OiBSZTogW3NwcmluZ10gTW9kZWxpbmcgU1JHQiBjb25maWd1cmF0aW9uIGZvciBkcmFmdC1pZXRm LXNwcmluZy1zci15YW5nDQoNCkhpLA0KDQpBcmNoaXRlY3R1cmFsbHkgSSBhZ3JlZSDigJMgbGFi ZWwgbWFuYWdlciBzaG91bGRu4oCZdCBjYXJlIGxlc3MgaG93IGxhYmVscyBoYXZlIGJlZW4gbGVh cm50DQpPcGVyYXRpb25hbGx5IEnigJltIHN0cm9uZ2x5IGZvciAjMiwgaW4gY2FzZSBvZiBJU0lT IHBvc3NpYmx5IHVuZGVyIEFGLg0KDQpDaGVlcnMsDQpKZWZmDQoNCkZyb206IHNwcmluZyA8c3By aW5nLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnPj4gb24g YmVoYWxmIG9mIFN0ZXBoYW5lIExpdGtvd3NraSA8c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5j b208bWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPj4NCkRhdGU6IFdlZG5lc2Rh eSwgSnVseSAyMiwgMjAxNSBhdCA3OjE5IFBNDQpUbzogInNwcmluZ0BpZXRmLm9yZzxtYWlsdG86 c3ByaW5nQGlldGYub3JnPiIgPHNwcmluZ0BpZXRmLm9yZzxtYWlsdG86c3ByaW5nQGlldGYub3Jn Pj4NClN1YmplY3Q6IFtzcHJpbmddIE1vZGVsaW5nIFNSR0IgY29uZmlndXJhdGlvbiBmb3IgZHJh ZnQtaWV0Zi1zcHJpbmctc3IteWFuZw0KDQpIaSBXRywNCg0KSW4gdGhlIGN1cnJlbnQgdmVyc2lv biBvZiB0aGUgY29uZmlnIFlhbmcgbW9kZWwgZm9yIFNSLCB0aGUgU1JHQiBsaXN0IGlzIGNvbmZp Z3VyZWQgYXQgU1IgdG9wIGxldmVsLCBzbyBpdCBpcyBhZ25vc3RpYyB0byB0aGUgcm91dGluZyBw cm90b2NvbC4NCldlIGhhZCBzb21lIGNvbW1lbnQgaW4gRGFsbGFzIG9uIGRpZmZpY3VsdGllcyB0 aGF0IGhhdmluZyBjb21tb24gbGFiZWwgcmFuZ2Ugc2hhcmVkIGJldHdlZW4gcHJvdG9jb2xzIGNv dWxkIGxlYWQgdG8uDQpEdXJpbmcgZGlzY3Vzc2lvbiBpbiBvdXIgZGVzaWduIHRlYW0sIHNvbWUg cG9pbnQgd2FzIGFsc28gcmFpc2VkIG9uIHJvdXRpbmcgcHJvdG9jb2wgbWlncmF0aW9ucyB0aGF0 IG1heSBiZSBzYWZlciB1c2luZyBhIHBlciBwcm90b2NvbCBTUkdCIChzbyBjb25maWd1cmF0aW9u IHRoZSBTUkdCIGF0IElHUCBsZXZlbCByYXRoZXIgdGhhbiBnbG9iYWxseSkuDQoNCldlIHdvdWxk IGxpa2UgdG8gaGVhciBmcm9tIHRoZSBXRyBhYm91dCB0aGUgcHJlZmVyZW5jZSBhbmQgYXJndW1l bnRzIGZvciBib3RoIGFwcHJvYWNoZXMgOg0KQXBwcm9hY2ggMSkga2VlcCBTUkdCIGNvbmZpZ3Vy YXRpb24gYXQgdG9wIGxldmVsLCBhbmQgc28gcm91dGluZyBwcm90b2NvbHMgd2lsbCBzaGFyZSB0 aGUgc2FtZSBsYWJlbCBzcGFjZSAodG9kYXkgcHJvcG9zYWwpDQpBcHByb2FjaCAyKSBtb3ZlIFNS R0IgY29uZmlndXJhdGlvbiB0byBwcm90b2NvbHMsIGVhY2ggcm91dGluZyBwcm90b2NvbCBtYW5h Z2VzIGl0cyBvd24gbGFiZWwgc3BhY2UuDQoNClRoYW5rcyB0byBwcm92aWRlIHlvdXIgZmVlZGJh Y2sgaW4gb3JkZXIgdG8gc29sdmUgdGhpcyBpc3N1ZSBhbmQgaGF2ZSBhIGNvbnNlbnN1cy4NCg0K DQpbT3JhbmdlIGxvZ29dPGh0dHA6Ly93d3cub3JhbmdlLmNvbS8+DQoNClN0ZXBoYW5lIExpdGtv d3NraQ0KTmV0d29yayBBcmNoaXRlY3QNCk9yYW5nZS9TQ0UvRVFVQU5UL0lCTkYvRU5ERC9OREUN Ck9yYW5nZSBFeHBlcnQgRnV0dXJlIE5ldHdvcmtzDQpwaG9uZTogKzMzIDIgMjMgMjggNDkgODMg PGh0dHBzOi8vbW9uc2kuc3NvLmZyYW5jZXRlbGVjb20uZnIvaW5kZXguYXNwP3RhcmdldD1odHRw JTNBJTJGJTJGY2xpY3ZvaWNlLnNzby5mcmFuY2V0ZWxlY29tLmZyJTJGQ2xpY3ZvaWNlVjIlMkZU b29sQmFyLmRvJTNGYWN0aW9uJTNEZGVmYXVsdCUyNnJvb3RzZXJ2aWNlJTNEU0lHTkFUVVJFJTI2 dG8lM0QrMzMlMjAyJTIwMjMlMjAyOCUyMDQ5JTIwODMlMjA+DQptb2JpbGU6ICszMyA2IDM3IDg2 IDk3IDUyIDxodHRwczovL21vbnNpLnNzby5mcmFuY2V0ZWxlY29tLmZyL2luZGV4LmFzcD90YXJn ZXQ9aHR0cCUzQSUyRiUyRmNsaWN2b2ljZS5zc28uZnJhbmNldGVsZWNvbS5mciUyRkNsaWN2b2lj ZVYyJTJGVG9vbEJhci5kbyUzRmFjdGlvbiUzRGRlZmF1bHQlMjZyb290c2VydmljZSUzRFNJR05B VFVSRSUyNnRvJTNEKzMzJTIwNiUyMDM3JTIwODYlMjA5NyUyMDUyJTIwPg0Kc3RlcGhhbmUubGl0 a293c2tpQG9yYW5nZS5jb208bWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tPg0K DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1 dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxl Z2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMg b3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdl IHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0IGxl IGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVj dHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBkZWNs aW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZv cm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9u IHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0 cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMgZW1h aWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhh dCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5b3Uu DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBk ZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ry b25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGlu ZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3Jt ZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0 aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJp YnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWls cyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQg aGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0K --_000_F3ADE4747C9E124B89F0ED2180CC814F594A7458xmbalnx02ciscoc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5v c2UtMToyIDExIDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5N c29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1h cmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQ cmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAuTXNv QWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZh bWlseTpDb25zb2xhczt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToi QmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4u RW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy Mw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj5BIHZlcnkgc3Ryb25nIDwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjE4LjBwdDtjb2xvcjpyZWQiPuKAnCYjNDM7MeKAnTwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImNvbG9yOnJlZCI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPnRvIHdo YXQgQWNlZSBoYXMgc2FpZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOyZuYnNwOyBMZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IHNwcmluZyBbbWFpbHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5BY2VlIExpbmRlbSAoYWNlZSk8YnI+DQo8Yj5TZW50OjwvYj4gRnJpZGF5 LCBKdWx5IDMxLCAyMDE1IDE6NDEgUE08YnI+DQo8Yj5Ubzo8L2I+IHN0ZXBoYW5lLmxpdGtvd3Nr aUBvcmFuZ2UuY29tOyBKZWZmIFRhbnRzdXJhOyBzcHJpbmdAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IFtzcHJpbmddIE1vZGVsaW5nIFNSR0IgY29uZmlndXJhdGlvbiBmb3IgZHJh ZnQtaWV0Zi1zcHJpbmctc3IteWFuZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGkgU3RlcGhhbmUsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoaWxlIHRoZXJlIG1heSBiZSB0 cmFuc2l0aW9uYWwgdXNlIGNhc2VzIHdoZXJlIHRoZXJlIGlzIGEgcmVxdWlyZW1lbnQgdG8gYWxs b2NhdGUmbmJzcDtkaWZmZXJlbnQgU1JHQnMgdG8gZGlmZmVyZW50IHByb3RvY29scyBpbnN0YW5j ZXMsIEkgZG9u4oCZdCBiZWxpZXZlIHdlJm5ic3A7c2hvdWxkJm5ic3A74oCcdGhyb3cgdGhlIGJh Ynkgb3V0IHdpdGggdGhlIGJhdGh3YXRlcuKAnSBhbmQgcmVtb3ZlIHRoZSBnbG9iYWwgU1JHQiBj b25maWd1cmF0aW9uLg0KIFRoZSBvcGVyYXRpb25hbCBzaW1wbGljaXR5IGFuZCBtYW5hZ2FiaWxp dHkgYWR2YW50YWdlcyBvZiBoYXZpbmcgYSBzaW5nbGUgU1JHQiBmb3IgdGhlIG5vZGUgYXJlIHVu ZGVuaWFibGUuIFRoZSBiZW5lZml0cyBhcmUgbXVsdGlwbGllZCBpZiBvbmUgY2FuIG1haW50YWlu IGEgY29uc2lzdGVudCBTUkdCIHRocm91Z2hvdXQgdGhlIHNlZ21lbnQgcm91dGluZyBkb21haW4g KGFsdGhvdWdoJm5ic3A7SSB1bmRlcnN0YW5kIHRoYXQgdGhpcyBpcyBub3QgYWx3YXlzDQogcG9z c2libGUpLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5IZW5jZSwgSSBiZWxpZXZlIHdlIHNob3VsZCByZXRhaW4gdGhlIGdsb2JhbCBT UkdCIGNvbmZpZ3VyYXRpb24gaW4gdGhlIFlBTkcgbW9kZWwuIEluIHRoZSBwcm90b2NvbHMsIHRo ZSBnbG9iYWwgU1JHQiB3b3VsZCBiZSBpbmhlcml0ZWQgb3IsIGlmIGNvbmZpZ3VyZWQsJm5ic3A7 b3ZlcndyaXR0ZW4gYnkgcHJvdG9jb2wgY29uZmlndXJhdGlvbi4gSWYgd2UgY2Fubm90IGFncmVl IG9uIGVpdGhlciBiZWluZyZuYnNwO21hbmRhdG9yeSwNCiBib3RoIGNvdWxkIGJlIFlBTkcgZmVh dHVyZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkFjZWUmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQg MGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+c3ByaW5n ICZsdDs8YSBocmVmPSJtYWlsdG86c3ByaW5nLWJvdW5jZXNAaWV0Zi5vcmciPnNwcmluZy1ib3Vu Y2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIFN0ZXBoYW5lIExpdGtvd3NraSAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIj5zdGVwaGFuZS5s aXRrb3dza2lAb3JhbmdlLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPkZyaWRheSwgSnVs eSAzMSwgMjAxNSBhdCAzOjUyIEFNPGJyPg0KPGI+VG86IDwvYj5KZWZmIFRhbnRzdXJhICZsdDs8 YSBocmVmPSJtYWlsdG86amVmZi50YW50c3VyYUBlcmljc3Nvbi5jb20iPmplZmYudGFudHN1cmFA ZXJpY3Nzb24uY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdAaWV0Zi5v cmciPnNwcmluZ0BpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzcHJpbmdA aWV0Zi5vcmciPnNwcmluZ0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJl OiBbc3ByaW5nXSBNb2RlbGluZyBTUkdCIGNvbmZpZ3VyYXRpb24gZm9yIGRyYWZ0LWlldGYtc3By aW5nLXNyLXlhbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDttYXJnaW4tcmlnaHQ6MGluIiBpZD0iTUFD X09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Mb29rcyB0aGF0IGNvbnNl bnN1cyBpcyBmb3Igb3B0aW9uIzIsIHNvIGxldOKAmXMgbW92ZSBTUkdCIHRvIHByb3RvY29sIGNv bmZpZ3VyYXRpb24uPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+IEplZmYgVGFu dHN1cmEgWzxhIGhyZWY9Im1haWx0bzpqZWZmLnRhbnRzdXJhQGVyaWNzc29uLmNvbSI+bWFpbHRv OmplZmYudGFudHN1cmFAZXJpY3Nzb24uY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBGcmlk YXksIEp1bHkgMzEsIDIwMTUgMDg6MDQ8YnI+DQo8Yj5Ubzo8L2I+IExJVEtPV1NLSSBTdGVwaGFu ZSBTQ0UvSUJORjsgPGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRmLm9yZyI+c3ByaW5nQGlldGYu b3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW3NwcmluZ10gTW9kZWxpbmcgU1JHQiBj b25maWd1cmF0aW9uIGZvciBkcmFmdC1pZXRmLXNwcmluZy1zci15YW5nPC9zcGFuPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPkhpLDwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+QXJjaGl0ZWN0dXJh bGx5IEkgYWdyZWUg4oCTIGxhYmVsIG1hbmFnZXIgc2hvdWxkbuKAmXQgY2FyZSBsZXNzIGhvdyBs YWJlbHMgaGF2ZSBiZWVuIGxlYXJudDwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2NvbG9yOmJsYWNrIj5PcGVyYXRpb25hbGx5 IEnigJltIHN0cm9uZ2x5IGZvciAjMiwgaW4gY2FzZSBvZiBJU0lTIHBvc3NpYmx5IHVuZGVyIEFG Ljwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2si PkNoZWVycyw8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtjb2xvcjpibGFjayI+SmVmZjwvc3Bhbj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQjVDNERGIDQuNXB0O3BhZGRpbmc6MGluIDBp biAwaW4gNC4wcHQ7bWFyZ2luLWxlZnQ6My43NXB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJp Z2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0IiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05f QkxPQ0tRVU9URSI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTogPC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnNwcmluZyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnNwcmluZy1ib3VuY2VzQGlldGYub3JnIj5zcHJpbmctYm91bmNlc0BpZXRmLm9yZzwvYT4m Z3Q7IG9uIGJlaGFsZiBvZiBTdGVwaGFuZSBMaXRrb3dza2kgJmx0OzxhIGhyZWY9Im1haWx0bzpz dGVwaGFuZS5saXRrb3dza2lAb3JhbmdlLmNvbSI+c3RlcGhhbmUubGl0a293c2tpQG9yYW5nZS5j b208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5XZWRuZXNkYXksIEp1bHkgMjIsIDIwMTUgYXQg NzoxOSBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnNwcmluZ0BpZXRm Lm9yZyI+c3ByaW5nQGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcmlu Z0BpZXRmLm9yZyI+c3ByaW5nQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+ W3NwcmluZ10gTW9kZWxpbmcgU1JHQiBjb25maWd1cmF0aW9uIGZvciBkcmFmdC1pZXRmLXNwcmlu Zy1zci15YW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNCNUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDoz Ljc1cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4w cHQiIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5IaSBXRyw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+SW4gdGhlIGN1cnJlbnQgdmVyc2lvbiBv ZiB0aGUgY29uZmlnIFlhbmcgbW9kZWwgZm9yIFNSLCB0aGUgU1JHQiBsaXN0IGlzIGNvbmZpZ3Vy ZWQgYXQgU1IgdG9wIGxldmVsLCBzbyBpdCBpcyBhZ25vc3RpYyB0byB0aGUgcm91dGluZyBwcm90 b2NvbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPldlIGhhZCBzb21lIGNvbW1lbnQgaW4gRGFsbGFzIG9uIGRpZmZp Y3VsdGllcyB0aGF0IGhhdmluZyBjb21tb24gbGFiZWwgcmFuZ2Ugc2hhcmVkIGJldHdlZW4gcHJv dG9jb2xzIGNvdWxkIGxlYWQgdG8uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5EdXJpbmcgZGlzY3Vzc2lvbiBpbiBv dXIgZGVzaWduIHRlYW0sIHNvbWUgcG9pbnQgd2FzIGFsc28gcmFpc2VkIG9uIHJvdXRpbmcgcHJv dG9jb2wgbWlncmF0aW9ucyB0aGF0IG1heSBiZSBzYWZlciB1c2luZyBhIHBlciBwcm90b2NvbCBT UkdCIChzbyBjb25maWd1cmF0aW9uIHRoZSBTUkdCIGF0IElHUCBsZXZlbCByYXRoZXIgdGhhbiBn bG9iYWxseSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPldlIHdvdWxkIGxpa2Ug dG8gaGVhciBmcm9tIHRoZSBXRyBhYm91dCB0aGUgcHJlZmVyZW5jZSBhbmQgYXJndW1lbnRzIGZv ciBib3RoIGFwcHJvYWNoZXMgOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QXBwcm9hY2ggMSkga2VlcCBTUkdCIGNv bmZpZ3VyYXRpb24gYXQgdG9wIGxldmVsLCBhbmQgc28gcm91dGluZyBwcm90b2NvbHMgd2lsbCBz aGFyZSB0aGUgc2FtZSBsYWJlbCBzcGFjZSAodG9kYXkgcHJvcG9zYWwpPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5B cHByb2FjaCAyKSBtb3ZlIFNSR0IgY29uZmlndXJhdGlvbiB0byBwcm90b2NvbHMsIGVhY2ggcm91 dGluZyBwcm90b2NvbCBtYW5hZ2VzIGl0cyBvd24gbGFiZWwgc3BhY2UuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPlRoYW5rcyB0byBwcm92aWRlIHlvdXIgZmVlZGJhY2sgaW4gb3Jk ZXIgdG8gc29sdmUgdGhpcyBpc3N1ZSBhbmQgaGF2ZSBhIGNvbnNlbnN1cy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48YSBocmVmPSJodHRwOi8v d3d3Lm9yYW5nZS5jb20vIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7dGV4dC1kZWNv cmF0aW9uOm5vbmUiPjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iNDAiIGhlaWdodD0iNDAiIGlkPSJQ aWN0dXJlX3gwMDIwXzEiIHNyYz0iY2lkOmltYWdlMDAxLmdpZkAwMUQwQ0JBQy43RTc5NUE0MCIg YWx0PSJPcmFuZ2UgbG9nbyI+PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlN0ZXBoYW5lIExpdGtv d3NraQ0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29sb3I6Ymxh Y2siPjxicj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5O ZXR3b3JrIEFyY2hpdGVjdA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztj b2xvcjpibGFjayI+PGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPk9yYW5nZS9TQ0UvRVFVQU5UL0lCTkYvRU5ERC9OREUNCjwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5PcmFu Z2UgRXhwZXJ0IEZ1dHVyZSBOZXR3b3Jrczwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5waG9uZToNCjxhIGhyZWY9Imh0 dHBzOi8vbW9uc2kuc3NvLmZyYW5jZXRlbGVjb20uZnIvaW5kZXguYXNwP3RhcmdldD1odHRwJTNB JTJGJTJGY2xpY3ZvaWNlLnNzby5mcmFuY2V0ZWxlY29tLmZyJTJGQ2xpY3ZvaWNlVjIlMkZUb29s QmFyLmRvJTNGYWN0aW9uJTNEZGVmYXVsdCUyNnJvb3RzZXJ2aWNlJTNEU0lHTkFUVVJFJTI2dG8l M0QmIzQzOzMzJTIwMiUyMDIzJTIwMjglMjA0OSUyMDgzJTIwIj4NCjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+JiM0MzszMyAyIDIzIDI4IDQ5IDgzIDwvc3Bh bj48L2E+PC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssJnF1b3Q7c2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPjxicj4NCjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+bW9iaWxlOg0KPGEgaHJlZj0iaHR0cHM6Ly9tb25zaS5zc28uZnJhbmNl dGVsZWNvbS5mci9pbmRleC5hc3A/dGFyZ2V0PWh0dHAlM0ElMkYlMkZjbGljdm9pY2Uuc3NvLmZy YW5jZXRlbGVjb20uZnIlMkZDbGljdm9pY2VWMiUyRlRvb2xCYXIuZG8lM0ZhY3Rpb24lM0RkZWZh dWx0JTI2cm9vdHNlcnZpY2UlM0RTSUdOQVRVUkUlMjZ0byUzRCYjNDM7MzMlMjA2JTIwMzclMjA4 NiUyMDk3JTIwNTIlMjAiPg0KPHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3RleHQtZGVjb3JhdGlv bjpub25lIj4mIzQzOzMzIDYgMzcgODYgOTcgNTIgPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gbGFu Zz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l dyBSb21hbiZxdW90OywmcXVvdDtzZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOnN0ZXBoYW5lLmxpdGtvd3NraUBvcmFuZ2UuY29tIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiNGRjY2MDA7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPnN0ZXBoYW5lLmxp dGtvd3NraUBvcmFuZ2UuY29tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bGluZS1oZWlnaHQ6MTUuMHB0Ij48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LCZxdW90O3NlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwcmU+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpv aW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBv dSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxv aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1l c3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5hIGwnZXhwZWRpdGV1ciBldCBs ZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxl Y3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPk9yYW5nZSBkZWNsaW5l IHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1l IG91IGZhbHNpZmllLiBNZXJjaS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50 cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0 IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48 c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwg dXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPklmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRl IHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJl ZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlm aWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGFuayB5b3UuPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Q2Ug bWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3Jt YXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25j PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24u IFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2ln bmFsZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGlzIG1l c3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJp dmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnRoZXkgc2hv dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0 aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3Nh Z2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5UaGFuayB5 b3UuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_F3ADE4747C9E124B89F0ED2180CC814F594A7458xmbalnx02ciscoc_-- --_004_F3ADE4747C9E124B89F0ED2180CC814F594A7458xmbalnx02ciscoc_ Content-Type: image/gif; name="image001.gif" Content-Description: image001.gif Content-Disposition: inline; filename="image001.gif"; size=381; creation-date="Fri, 31 Jul 2015 23:18:11 GMT"; modification-date="Fri, 31 Jul 2015 23:18:11 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhKAAoAMQAAP+MQP+zgP/17//s3/+DMP/iz/+fYP+8j/9wEP95IP/Gn/+WUP/Pr/+pcP/Z v/////9mAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAA AAAALAAAAAAoACgAAAX6oAONZGmeaEqKauum7Cu/8Wyj9a2P+X73vhkwSCPuhkYVMolj2pbOEjTK oxatrSlVG+U6vUxwUmwkE81BtE99xGbdSjhMPgo4BAoA+wUICAR6IwQODwMNEAcOigAFhQYQDgoD DwcQBJOKBIOFDQmaCCyTB416hQcBBQuTEA8Cow8EBQINpHcGhAkrEAkPChAAD3YPCLuSDw+sIgEP wCILzK0OjY9VBJS/wYQjfwaNyRDLzRAG0AMB5wC6ENyEt8jWDAsCyA/KzJN+zLILqLlVv/OuaYPU alU9cMwuPSCl8AEDYv8EQbwRgAEABcziJFl2bMmeEQgATEwRAgA7 --_004_F3ADE4747C9E124B89F0ED2180CC814F594A7458xmbalnx02ciscoc_-- From nobody Fri Jul 31 16:27:14 2015 Return-Path: X-Original-To: spring@ietfa.amsl.com Delivered-To: spring@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A151D1A9155 for ; Fri, 31 Jul 2015 16:27:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmnsYZEwP84o for ; Fri, 31 Jul 2015 16:27:10 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4A51A914A for ; Fri, 31 Jul 2015 16:27:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9024; q=dns/txt; s=iport; t=1438385230; x=1439594830; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KE1gKwb0O2yAvHriyrC0svM2nnZkK6WPf2qMWmq1DKs=; b=SFaPCY0kAjJEnB+gk6GNSorD7C7YVHmXLFYN7FTvY4wVrI1hARjdYZWp MGeQfemMuOoo3VEkqGIk/C/R/8FABf63rGK/udgOzfM4sX/L+/R8wp0p7 /G6FbKBh5QFGW9YE9i4o+6IjRXY0zFo203XSCkGKGJAb37X2i1P6+12/j 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AzAwAJBLxV/5pdJa1bgxqBPQa8NQmER4M2AoExOBQBAQEBAQEBgQqEIwEBAQQ6MgoDDAQCAQgRAQMBAQEKFAkHMhQDBggCBAENBQgTiBPIFgEBAQEBAQEBAQEBAQEBAQEBAQEBAReLToQkEQEgMQcGgxKBFAWUeAGOEYQgj3WDZCaDfW+BDjqBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,588,1432598400"; d="scan'208";a="16781084" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 31 Jul 2015 23:26:56 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id t6VNQuTM024537 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 Jul 2015 23:26:57 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.220]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0195.001; Fri, 31 Jul 2015 18:26:56 -0500 From: "Les Ginsberg (ginsberg)" To: "Hannes Gredler (hannes@juniper.net)" , "stephane.litkowski@orange.com" Thread-Topic: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang Thread-Index: AQHQy5mFisM6+4GhS0qnRtJqXNC+g532N9Fw Date: Fri, 31 Jul 2015 23:26:56 +0000 Message-ID: References: <21093_1437585600_55AFD0C0_21093_6659_1_9E32478DFA9976438E7A22F69B08FF92166A3D14@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <4A79394211F1AF4EB57D998426C9340DD4734660@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A6019@eusaamb105.ericsson.se> <4A79394211F1AF4EB57D998426C9340DD47347BE@US70UWXCHMBA01.zam.alcatel-lucent.com> <1B502206DFA0C544B7A6046915200863512A7A36@eusaamb105.ericsson.se> <29209_1438171839_55B8C2BF_29209_1516_1_9E32478DFA9976438E7A22F69B08FF92166B7B57@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <9950_1438262325_55BA2435_9950_8082_1_9E32478DFA9976438E7A22F69B08FF92166BA633@OPEXCLILMA4.corporate.adroot.infra.ftgroup> <20150731140153.GA17044@hannes-mba.local> In-Reply-To: <20150731140153.GA17044@hannes-mba.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.211.124] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "Aissaoui, Mustapha \(Mustapha\)" , "spring@ietf.org" , Uma Chunduri , "Shraddha Hegde \(shraddha@juniper.net\)" , "Pushpasis Sarkar \(psarkar@juniper.net\)" Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-sr-yang X-BeenThere: spring@ietf.org X-Mailman-Version: 2.1.15 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, 31 Jul 2015 23:27:12 -0000 Hannes - As a datapoint, we are able to successfully manage a reserved label space a= mong multiple SR clients. As regards GR I am not sure why you think SR introduces new requirements. I= f your forwarding plane is to be persistent (NSF) then the router has to ha= ve a way of supporting label persistence across control plane restarts. In = this context SR clients should be making use of whatever infrastructure alr= eady exists to support label persistence. What do you think is new here? What is more problematic is supporting multiple labels for the same prefix = - which is one of the consequences of the per-protocol SRGB approach. I am = not saying this is unsupportable - just that it is a more difficult problem= to solve. I would be interested in other implementation experience on this= point. Les > -----Original Message----- > From: Hannes Gredler (hannes@juniper.net) [mailto:hannes@juniper.net] > Sent: Friday, July 31, 2015 7:02 AM > To: stephane.litkowski@orange.com > Cc: Les Ginsberg (ginsberg); Uma Chunduri; Aissaoui, Mustapha (Mustapha); > spring@ietf.org; Shraddha Hegde (shraddha@juniper.net); Pushpasis Sarkar > (psarkar@juniper.net) > Subject: Re: [spring] Modeling SRGB configuration for draft-ietf-spring-s= r- > yang >=20 > one further point is that implementations MAY reuse exisiting MPLS label- > managing software for SR. label-management software has often this label- > per-client (singular) and not-label-per-clients (plural) bookkeeping in t= he > sense that it cannot track multiple 'owners' of a certain label value. >=20 > it would be interesting to hear from other implementers if their software= can > easily track 'multiple client' ownership per label (and if not) what are = the > implications to non-SR code-paths e.g. graceful restart scenarios ? >=20 > /hannes >=20 > On Thu, Jul 30, 2015 at 01:18:43PM +0000, stephane.litkowski@orange.com > wrote: > | As mentioned by others, there may be some operational gain. > | > | IGP migration example given is a good example, today with pure IP, > there's > | some tricky cases because we need to manage it with admin distance a= nd > | their may be some differences in best path computation between IGPs > | (implementation dependant, but it's a reality). > | > | Here we have the opportunity to overcome this issue by letting the > | possibility to create two parallel forwarding planes using different > | labels. I agree that it consumes twice the number of required label,= but > | it may be a transient solution (for migration case) and also it's a = design > | choice of the operator. > | > | The last comment from Robert of virtualization , especially using > | containers or part of router OS running on COTS (just OSPF or ISIS o= r BGP > | code), may require some more independency between router software > | components. > | > | > | > | > | > | Now from an architectural perspective, what is Segment Routing ? > | > | Segment routing is just an architecture, like MPLS is. We see that s= egment > | routing has more and more controlplanes (ISIS and OSPF first, now BG= P > | ...), like MPLS does. Moreover using segment routing in an MPLS > | environment leads to adding new controlplanes to MPLS. > | > | So I like the comment from Pushpasis talking about BGP, LDP, RSVP wh= ich > | are different controlplane of MPLS. Do we advertise the same label v= alue > | for the same prefix FEC advertised in LDP, BGP and RSVP ? No ... so = why > | doing it with OSPF and ISIS ? > | > | > | > | > | > | From: Les Ginsberg (ginsberg) [mailto:ginsberg@cisco.com] > | Sent: Wednesday, July 29, 2015 23:01 > | To: LITKOWSKI Stephane SCE/IBNF; Uma Chunduri; Aissaoui, Mustapha > | (Mustapha); spring@ietf.org; Shraddha Hegde (shraddha@juniper.net); > | Pushpasis Sarkar (psarkar@juniper.net); Hannes Gredler > | (hannes@juniper.net) > | Subject: RE: [spring] Modeling SRGB configuration for > | draft-ietf-spring-sr-yang > | > | > | > | Stephane - > | > | > | > | What is the requirement to have a per-protocol SRGB config? > | > | This makes no sense to me operationally or architecturally. > | > | > | > | (I am not talking about what may or may not have been implemented by > | vendors - the YANG model should be architecturally correct) > | > | > | > | Les > | > | > | > | > | > | From: [1]stephane.litkowski@orange.com > | [[2]mailto:stephane.litkowski@orange.com] > | Sent: Wednesday, July 29, 2015 5:11 AM > | To: Uma Chunduri; Les Ginsberg (ginsberg); Aissaoui, Mustapha > (Mustapha); > | [3]spring@ietf.org; Shraddha Hegde ([4]shraddha@juniper.net); > Pushpasis > | Sarkar ([5]psarkar@juniper.net); Hannes Gredler > ([6]hannes@juniper.net) > | Subject: RE: [spring] Modeling SRGB configuration for > | draft-ietf-spring-sr-yang > | > | > | > | Hi all, > | > | > | > | What if we keep the SRGB block config in "segment-routing" global > module, > | and if we allow for YANG configuration of carving this block inside = each > | protocol (maybe as a feature) ? > | > | > | > | Stephane > | > | > | > | > | > | From: Uma Chunduri [[7]mailto:uma.chunduri@ericsson.com] > | Sent: Friday, July 24, 2015 16:59 > | To: Les Ginsberg (ginsberg); Aissaoui, Mustapha (Mustapha); LITKOWSK= I > | Stephane SCE/IBNF; [8]spring@ietf.org > | Subject: RE: [spring] Modeling SRGB configuration for > | draft-ietf-spring-sr-yang > | > | > | > | >Suggesting that the forwarding instruction (AKA label) needs to be > | different depending on what protocol provided > | > | >the instruction is completely unnecessary - it simply wastes label = space. > | > | > | > | [Uma]: Les, No - I never suggested anything like that. > | > | SRGB for a routing instance to be advertised should be part of the r= outing > | instance provisioning as far as the yang model is concerned. > | > | Carving out the label space for SR is a local matter and agree, of c= ourse, > | this can be done in so many ways through CLI, dynamically, statical= ly > | etc... > | > | > | > | -- > | > | Uma C. > | > | > | > | > | > __________________________________________________________ > ____________ > | ___________________________________________________ > | > | > | > | 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, deform= e 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. > | > | > | > __________________________________________________________ > ____________ > | ___________________________________________________ > | > | 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 q= ue les > pieces jointes. Les messages electroniques etant susceptibles d'alteratio= n, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > | > | This message and its attachments may contain confidential or > | privileged information that may be protected by law; they should not b= e > 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. > | > | References > | > | Visible links > | 1. mailto:stephane.litkowski@orange.com > | 2. mailto:stephane.litkowski@orange.com > | 3. mailto:spring@ietf.org > | 4. mailto:shraddha@juniper.net > | 5. mailto:psarkar@juniper.net > | 6. mailto:hannes@juniper.net > | 7. mailto:uma.chunduri@ericsson.com > | 8. mailto:spring@ietf.org