From nobody Fri Aug 1 04:01:14 2014 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 778651A0A88 for ; Fri, 1 Aug 2014 04:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 7ywy8Y-LX1df for ; Fri, 1 Aug 2014 04:01:08 -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 979001A0A89 for ; Fri, 1 Aug 2014 04:01:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1942; q=dns/txt; s=iport; t=1406890868; x=1408100468; h=from:to:subject:date:message-id:references:content-id: content-transfer-encoding:mime-version; bh=Mekfr4peRpGodIZh4YXfS0hUnprkfK+O5LbyxYIbQxw=; b=nEjWxeeY4m7cpqlDVVWPkKhP0MunXHzQ6YmSIGAf5HgyK3GZqGc/4CNU NKt3SXAzNbvF9OyCGgO1OE24t6bntiHM197mDOKg1OtTFlewAPTbWVSMM khLXpbETki9TqyF/h9jvCkiCx2otspwg5DKU3mhtu0h96orl92tp8taX8 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAD1z21OtJV2Y/2dsb2JhbABbgw1SUwQEzAqHSYEHFneEAwEBAQMBOj0HCwIBGQECAQIfEDIXBAIIAgQTCYgxCAgFyVkXj1mDKYEcBZt1gVSTBIIDgUZsAYFE X-IronPort-AV: E=Sophos;i="5.01,779,1400025600"; d="scan'208";a="341284556" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 01 Aug 2014 11:01:06 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s71B16EA028605 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 1 Aug 2014 11:01:06 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 06:01:06 -0500 From: "Stefano Previdi (sprevidi)" To: "spring@ietf.org" Thread-Topic: New Version Notification for draft-filsfils-spring-segment-routing-mpls-03.txt Thread-Index: AQHPrXe3t1APws2YzE2nDJzE7z7ikg== Date: Fri, 1 Aug 2014 11:01:05 +0000 Message-ID: References: <20140801105943.7411.45851.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.169.93] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/q0j9B62RPhlOATyF-my-Y3g69E8 Subject: [spring] Fwd: New Version Notification for draft-filsfils-spring-segment-routing-mpls-03.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, 01 Aug 2014 11:01:13 -0000 FYI. only a minor change in the various references. s. Begin forwarded message: > From: > Subject: New Version Notification for draft-filsfils-spring-segment-routi= ng-mpls-03.txt > Date: August 1, 2014 12:59:43 PM GMT+02:00 >=20 > A new version of I-D, draft-filsfils-spring-segment-routing-mpls-03.txt > has been successfully submitted by Stefano Previdi and posted to the > IETF repository. >=20 > Name: draft-filsfils-spring-segment-routing-mpls > Revision: 03 > Title: Segment Routing with MPLS data plane > Document date: 2014-07-31 > Group: Individual Submission > Pages: 14 > URL: http://www.ietf.org/internet-drafts/draft-filsfils-spring= -segment-routing-mpls-03.txt > Status: https://datatracker.ietf.org/doc/draft-filsfils-spring-se= gment-routing-mpls/ > Htmlized: http://tools.ietf.org/html/draft-filsfils-spring-segment-= routing-mpls-03 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-filsfils-spring-= segment-routing-mpls-03 >=20 > Abstract: > Segment Routing (SR) leverages the source routing paradigm. A node > steers a packet through a controlled set of instructions, called > segments, by prepending the packet with an SR header. A segment can > represent any instruction, topological or service-based. SR allows > to enforce a flow through any topological path and service chain > while maintaining per-flow state only at the ingress node to the SR > domain. >=20 > Segment Routing can be directly applied to the MPLS architecture with > no change in the forwarding plane. This drafts describes how Segment > Routing operates on top of the MPLS data plane. >=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 Aug 1 11:02:00 2014 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 2E7AE1B2885; Fri, 1 Aug 2014 11:01:59 -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, 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 6_BvYngoRVys; Fri, 1 Aug 2014 11:01:56 -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 831BF1A0067; Fri, 1 Aug 2014 11:01:56 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-40-53db803735e5 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 43.A2.25146.7308BD35; Fri, 1 Aug 2014 13:55:35 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Fri, 1 Aug 2014 14:01:55 -0400 From: Uma Chunduri To: "Stefano Previdi (sprevidi)" Thread-Topic: [Isis-wg] comment on draft-ietf-isis-segment-routing-extensions-02 Thread-Index: AQHPrVVkEtJy2yaQVkWkZ8IXvaT02pu8CZ7Q Date: Fri, 1 Aug 2014 18:01:54 +0000 Message-ID: <1B502206DFA0C544B7A60469152008633F31A55C@eusaamb105.ericsson.se> References: <2f151ad2a667450e9e861d94458ee73f@BLUPR05MB292.namprd05.prod.outlook.com> <1B502206DFA0C544B7A60469152008633F319D19@eusaamb105.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDLMWRmVeSWpSXmKPExsUyuXSPt655w+1gg47jChY/1rtaHD30ntVi /e5HTBbHL/xmdGDxmPJ7I6vHkiU/mTyuN11lD2CO4rJJSc3JLEst0rdL4Mr4fewwW0GbQcWD r2uYGxi71LsYOTkkBEwk+h/1MELYYhIX7q1nA7GFBI4ySmw7VNzFyAVkL2OUOH54CzNIgk1A T+Lj1J/sILaIgKnE+RnngeIcHMwCJRINFxxBTGGBQInbK8whKoIkXn56wAphG0n8/3ILbDyL gIrEtge7wdbyCvhKnO2YzQKx6gyjxO1vp8FGcgrYSlzttAapYQQ67fupNUwgNrOAuMStJ/OZ IE4WkFiy5zwzhC0q8fLxP1YIW0li0tJzrBD1OhILdn9ig7C1JZYtfM0MsVdQ4uTMJywTGMVm IRk7C0nLLCQts5C0LGBkWcXIUVqcWpabbmS4iREYPcck2Bx3MC74ZHmIUYCDUYmHVyH1drAQ a2JZcWXuIUZpDhYlcV7N6nnBQgLpiSWp2ampBalF8UWlOanFhxiZODilGhjzeosdz3dfX9TT LsK34df6iCbJucJyHZVPHbVv/G582vSlcknU5VvbnxjF77bQ79kUbyd+a5NqYkPRgfW/egtk st8G5ussTphRzTWZ132bnMnOJ/yHuZdMayjcsfa8nU9ynVxKE9eZvgw7uzkX+M9EyzT2q33k UlXOVLhmvSFt2qTG9JXtWkosxRmJhlrMRcWJAJ1kqwB/AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/spring/3LrX5elZXLpTjNWMhQ9Y0E9zU8A Cc: "spring@ietf.org" , "isis-wg@ietf.org" , Chris Bowers Subject: Re: [spring] [Isis-wg] comment on draft-ietf-isis-segment-routing-extensions-02 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, 01 Aug 2014 18:01:59 -0000 Stefano, Sure. I agree. Thanks for pointing out mapping server overlap here and usage of Binding TL= Vs. IMO, it's good to refer these explicitly from the binding TLV sub-sections = of IGP documents (as things are not obvious as is with the case for node-s= id/adj-sid). -- Uma C. -----Original Message----- From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 Sent: Thursday, July 31, 2014 11:54 PM To: Uma Chunduri Cc: Chris Bowers; isis-wg@ietf.org; spring@ietf.org Subject: Re: [Isis-wg] comment on draft-ietf-isis-segment-routing-extension= s-02 Uma, I agree. I think we also explicitly stated this during our meeting in Toronto (from = the minutes): -------------------------------------------------------------------- Uma: Needed to reference use cases in Hannes' draft. Hannes: Perhaps what we could do is add some practical examples for RSVP, BGP, and LDP LSPs binding. Not formal use cases. Stefano: Would rather not go into applications in this ISIS draft. Peter Psenak: Should go into a separate document that could be referenced from both ISIS and OSPF. Alia Atlas: There is a SPRING WG for such a document. ------------------------------------------------------------------- Now, note that: draft-filsfils-spring-segment-routing draft-filsfils-spring-segment-routing-ldp-interop describe the use case of the SR Mapping Server that is implemented using th= e Binding TLV. As you suggested, Hannes drafts can be combined so to produce a use-case do= cument (in spring) for the Binding TLV RSVP-based use-cases. s. On Jul 31, 2014, at 11:55 PM, Uma Chunduri wrote: > [CC'ed Spring WG] > =20 > I agree with what Chris said below in principle. But all this should not = be obviously part of ISIS/IGP extensions WG documents.. > =20 > Use cases for binding TLVs are explained in great details in 2 key=20 > documents (had to shuffle through to get here) - > =20 > 1. http://tools.ietf.org/html/draft-gredler-rtgwg-igp-label-adverti= sement-05 > 2. http://tools.ietf.org/html/draft-gredler-spring-mpls-06 > =20 > IMO, both are very useful documents. > It would be good to combine both of these and publish as a "spring " doc= ument and eventually it should progress there. > AFAICT, Both ISIS and OSPF should refer the same eventually to get more c= larity and use of binding TLVs described currently. > =20 > -- > Uma C. > =20 > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Chris=20 > Bowers > Sent: Thursday, July 31, 2014 2:42 PM > To: isis-wg@ietf.org > Subject: [Isis-wg] comment on=20 > draft-ietf-isis-segment-routing-extensions-02 > =20 > All, > =20 > The current text of draft-ietf-isis-segment-routing-extensions-02 does no= t clearly explain the usage of the Binding TLV for advertising LSPs created= using other protocols. I would like to propose the following text to be i= ncluded as section 2.5 . > =20 > Thanks, > Chris > =20 > ---------------- > =20 > 2.5 Binding TLV usage examples > =20 > This section gives examples of using the Binding TLV to advertise SID/lab= el bindings associated with RSVP-TE, LDP, and BGP labeled-unicast LSPs. It= also includes an example of advertising a context-id for egress node prote= ction. All of the examples assume that the Binding TLV weight=3D1 and metr= ic=3D100.=20 > =20 > 2.5.1 Advertising an RSVP-TE LSP using the Binding TLV > =20 > Assume that R1 has signaled an RSVP-TE LSP to egress router (R4) with rou= ter-id=3D10.4.4.4, with ER0 =3D (192.1.2.2 [strict], 192.2.3.2 [strict], 19= 2.3.4.2 [strict]). R1 can advertise a locally significant label binding for= this LSP (with label value=3D1099) using the following values and sub-TLV= s in the Binding TLV.=20 > =20 > Binding-TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, prefix length= =3D32,=20 > FEC prefix=3D10.4.4.4 SID/Label Sub-TLV: label=3D1099 ERO Metric sub-TLV:= =20 > metric=3D100 > IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.1.2.2 > IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.2.3.2 > IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.3.4.2 > =20 > 2.5.2 Advertising an LDP LSP using the Binding TLV > =20 > Assume that R5 has learned a FEC-label binding via LDP for FEC=3D10.8.8.8= /32. R5 can advertise a locally significant label binding for this LSP (wi= th label value=3D5099) using the following values and sub-TLVs in the Bindi= ng TLV.=20 > =20 > Binding TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, prefix length= =3D32,=20 > FEC prefix=3D10.8.8.8 SID/Label Sub-TLV: label=3D5099 ERO Metric sub-TLV:= =20 > metric=3D100 > IPv4 ERO sub-TLV: L-bit=3D1, IPv4 address=3D10.8.8.8 > =20 > 2.5.3 Advertising a BGP labeled-unicast LSP using the Binding TLV > =20 > Assume that R9 has used BGP labeled-unicast to learn a label binding for = prefix 10.15.15.15/32 with BGP next-hop=3D10.12.12.12. R9 can advertise a= locally significant label binding for this LSP (with label value=3D7099) = using the following values and sub-TLVs in the Binding TLV.=20 > =20 > Binding-TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, prefix length= =3D32,=20 > FEC prefix=3D10.15.15.15 SID/Label Sub-TLV: label=3D7099 ERO Metric=20 > sub-TLV: metric=3D100 > IPv4 ERO sub-TLV: L-bit=3D1, IPv4 address=3D10.12.12.12 > =20 > 2.5.4 Advertising a context-id for egress node protection using the=20 > Binding TLV > =20 > Assume that R22 is configured in the protector role to provide egress nod= e protection for R21 using context-id=3D10.0.0.21. R22 can advertise the l= abel associated with this context-id (with label value=3D8099) using the fo= llowing values and sub-TLVs in the Binding TLV. > =20 > Binding TLV: F-bit=3D0, M-bit=3D1, weight=3D1, range=3D1, prefix length= =3D32,=20 > FEC prefix=3D10.0.0.21 SID/Label Sub-TLV: label=3D8099 > =20 > ---------------- > =20 > =20 > =20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Fri Aug 1 11:57:37 2014 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 7C4B71A0378; Fri, 1 Aug 2014 11:57:35 -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 X_RmEF93sFVU; Fri, 1 Aug 2014 11:57:30 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 673C31A0299; Fri, 1 Aug 2014 11:57:30 -0700 (PDT) Received: from BLUPR05MB292.namprd05.prod.outlook.com (10.141.23.27) by BLUPR05MB290.namprd05.prod.outlook.com (10.141.23.24) with Microsoft SMTP Server (TLS) id 15.0.995.14; Fri, 1 Aug 2014 18:57:27 +0000 Received: from BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) by BLUPR05MB292.namprd05.prod.outlook.com ([10.141.23.27]) with mapi id 15.00.0995.014; Fri, 1 Aug 2014 18:57:27 +0000 From: Chris Bowers To: "isis-wg@ietf.org" , "spring@ietf.org" , "Stefano Previdi (sprevidi)" Thread-Topic: [Isis-wg] comment on draft-ietf-isis-segment-routing-extensions-02 Thread-Index: AQHPrVVlZUhG+onF1UCfCRTemcAiVJu8GV0w Date: Fri, 1 Aug 2014 18:57:26 +0000 Message-ID: References: <2f151ad2a667450e9e861d94458ee73f@BLUPR05MB292.namprd05.prod.outlook.com> <1B502206DFA0C544B7A60469152008633F319D19@eusaamb105.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.239.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID: x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(199002)(189002)(18374002)(13464003)(51704005)(164054003)(37854004)(24454002)(377454003)(99286002)(76576001)(77982001)(95666004)(106356001)(79102001)(21056001)(106116001)(101416001)(80022001)(105586002)(50986999)(99396002)(85306004)(74662001)(64706001)(81342001)(76482001)(81542001)(76176999)(2656002)(87936001)(83322001)(4396001)(20776003)(74316001)(92566001)(54356999)(19580405001)(86362001)(107046002)(33646002)(15975445006)(74502001)(46102001)(15202345003)(66066001)(83072002)(19580395003)(31966008)(85852003)(24736002)(108616003); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR05MB290; H:BLUPR05MB292.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:3; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/spring/U25Qjz5FvdlR_WeMpJJy88YVujM Cc: Uma Chunduri Subject: Re: [spring] [Isis-wg] comment on draft-ietf-isis-segment-routing-extensions-02 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, 01 Aug 2014 18:57:35 -0000 I disagree. The proposed text contains four Binding TLV usage examples whi= ch are not qualitatively different from the two usage examples already incl= uded in section 2.4.3 of draft-ietf-isis-segment-routing-extensions-02. Ad= ditional usage examples are needed to clarify how the TLVs and sub-TLVs def= ined in this document should be used, without ambiguity. As an example of the lack of clarity in the current text, draft-ietf-isis-= segment-routing-extensions-02 contains two different sub-TLVs for specifyin= g SID/Label values in the Binding TLV. The two options are the SID/Label Su= b-TLV (section 2.3) and the Prefix-SID Sub-TLV (section 2.1). The current = text does not clearly explain under what circumstances the two different su= b-TLVs should be used in the Binding TLV. The proposed text makes the usa= ge clear by means of examples. =20 Chris -----Original Message----- From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 Sent: Friday, August 01, 2014 1:54 AM To: Uma Chunduri Cc: Chris Bowers; isis-wg@ietf.org; spring@ietf.org Subject: Re: [Isis-wg] comment on draft-ietf-isis-segment-routing-extension= s-02 Uma, I agree. I think we also explicitly stated this during our meeting in Toronto (from = the minutes): -------------------------------------------------------------------- Uma: Needed to reference use cases in Hannes' draft. Hannes: Perhaps what we could do is add some practical examples for RSVP, BGP, and LDP LSPs binding. Not formal use cases. Stefano: Would rather not go into applications in this ISIS draft. Peter Psenak: Should go into a separate document that could be referenced from both ISIS and OSPF. Alia Atlas: There is a SPRING WG for such a document. ------------------------------------------------------------------- Now, note that: draft-filsfils-spring-segment-routing draft-filsfils-spring-segment-routing-ldp-interop describe the use case of the SR Mapping Server that is implemented using th= e Binding TLV. As you suggested, Hannes drafts can be combined so to produce a use-case do= cument (in spring) for the Binding TLV RSVP-based use-cases. s. On Jul 31, 2014, at 11:55 PM, Uma Chunduri wrote: > [CC'ed Spring WG] > =20 > I agree with what Chris said below in principle. But all this should not = be obviously part of ISIS/IGP extensions WG documents.. > =20 > Use cases for binding TLVs are explained in great details in 2 key=20 > documents (had to shuffle through to get here) - > =20 > 1. http://tools.ietf.org/html/draft-gredler-rtgwg-igp-label-adverti= sement-05 > 2. http://tools.ietf.org/html/draft-gredler-spring-mpls-06 > =20 > IMO, both are very useful documents. > It would be good to combine both of these and publish as a "spring " doc= ument and eventually it should progress there. > AFAICT, Both ISIS and OSPF should refer the same eventually to get more c= larity and use of binding TLVs described currently. > =20 > -- > Uma C. > =20 > From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Chris=20 > Bowers > Sent: Thursday, July 31, 2014 2:42 PM > To: isis-wg@ietf.org > Subject: [Isis-wg] comment on=20 > draft-ietf-isis-segment-routing-extensions-02 > =20 > All, > =20 > The current text of draft-ietf-isis-segment-routing-extensions-02 does no= t clearly explain the usage of the Binding TLV for advertising LSPs created= using other protocols. I would like to propose the following text to be i= ncluded as section 2.5 . > =20 > Thanks, > Chris > =20 > ---------------- > =20 > 2.5 Binding TLV usage examples > =20 > This section gives examples of using the Binding TLV to advertise SID/lab= el bindings associated with RSVP-TE, LDP, and BGP labeled-unicast LSPs. It= also includes an example of advertising a context-id for egress node prote= ction. All of the examples assume that the Binding TLV weight=3D1 and metr= ic=3D100.=20 > =20 > 2.5.1 Advertising an RSVP-TE LSP using the Binding TLV > =20 > Assume that R1 has signaled an RSVP-TE LSP to egress router (R4) with rou= ter-id=3D10.4.4.4, with ER0 =3D (192.1.2.2 [strict], 192.2.3.2 [strict], 19= 2.3.4.2 [strict]). R1 can advertise a locally significant label binding for= this LSP (with label value=3D1099) using the following values and sub-TLV= s in the Binding TLV.=20 > =20 > Binding-TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, prefix length= =3D32,=20 > FEC prefix=3D10.4.4.4 SID/Label Sub-TLV: label=3D1099 ERO Metric sub-TLV:= =20 > metric=3D100 > IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.1.2.2 > IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.2.3.2 > IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.3.4.2 > =20 > 2.5.2 Advertising an LDP LSP using the Binding TLV > =20 > Assume that R5 has learned a FEC-label binding via LDP for FEC=3D10.8.8.8= /32. R5 can advertise a locally significant label binding for this LSP (wi= th label value=3D5099) using the following values and sub-TLVs in the Bindi= ng TLV.=20 > =20 > Binding TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, prefix length= =3D32,=20 > FEC prefix=3D10.8.8.8 SID/Label Sub-TLV: label=3D5099 ERO Metric sub-TLV:= =20 > metric=3D100 > IPv4 ERO sub-TLV: L-bit=3D1, IPv4 address=3D10.8.8.8 > =20 > 2.5.3 Advertising a BGP labeled-unicast LSP using the Binding TLV > =20 > Assume that R9 has used BGP labeled-unicast to learn a label binding for = prefix 10.15.15.15/32 with BGP next-hop=3D10.12.12.12. R9 can advertise a= locally significant label binding for this LSP (with label value=3D7099) = using the following values and sub-TLVs in the Binding TLV.=20 > =20 > Binding-TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, prefix length= =3D32,=20 > FEC prefix=3D10.15.15.15 SID/Label Sub-TLV: label=3D7099 ERO Metric=20 > sub-TLV: metric=3D100 > IPv4 ERO sub-TLV: L-bit=3D1, IPv4 address=3D10.12.12.12 > =20 > 2.5.4 Advertising a context-id for egress node protection using the=20 > Binding TLV > =20 > Assume that R22 is configured in the protector role to provide egress nod= e protection for R21 using context-id=3D10.0.0.21. R22 can advertise the l= abel associated with this context-id (with label value=3D8099) using the fo= llowing values and sub-TLVs in the Binding TLV. > =20 > Binding TLV: F-bit=3D0, M-bit=3D1, weight=3D1, range=3D1, prefix length= =3D32,=20 > FEC prefix=3D10.0.0.21 SID/Label Sub-TLV: label=3D8099 > =20 > ---------------- > =20 > =20 > =20 > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Fri Aug 1 12:49:08 2014 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 267FF1A00B2; Fri, 1 Aug 2014 12:49:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 GKWw7LiJo8r0; Fri, 1 Aug 2014 12:49:02 -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 EA1CD1B28A2; Fri, 1 Aug 2014 12:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7248; q=dns/txt; s=iport; t=1406922541; x=1408132141; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GuquXwdi/ySbkIUkRY/q1yNDh6AL6hSNIOJ2AyFIzWc=; b=hdd9QklpmOUGn+whn3AitgTL7GW06nCYh/rKsTKVFrhueDktDVM/DjpU kG0r4UhymGGY3xRaYHIkm6Zz7bURWIJPvUjg2XzwXvrCjAhMQzpiv0Q+G /aIUiYzlxk5iXWnHJC19JfvQqEEbx6vLRXsvhb+fUjK1uhrpXMcyUF3tW c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFANPu21OtJV2R/2dsb2JhbABbgw1SVwTMBwyHSgGBCxZ3hAMBAQEDAQEBATctBwsFBwQCAQgOAwQBAQEeCQcnCxQJCAIEDgWIOggNyGMXjxkzBwaDKYEcBZdPhCuBVJMGg0lsgUU X-IronPort-AV: E=Sophos;i="5.01,781,1400025600"; d="scan'208";a="344509167" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-8.cisco.com with ESMTP; 01 Aug 2014 19:49:00 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s71JmxOJ002865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 19:49:00 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 14:48:59 -0500 From: "Stefano Previdi (sprevidi)" To: Chris Bowers Thread-Topic: [Isis-wg] comment on draft-ietf-isis-segment-routing-extensions-02 Thread-Index: AQHPrbpySZRgI7acbkuj4FAs2dFrt5u8e54A Date: Fri, 1 Aug 2014 19:48:59 +0000 Message-ID: References: <2f151ad2a667450e9e861d94458ee73f@BLUPR05MB292.namprd05.prod.outlook.com> <1B502206DFA0C544B7A60469152008633F319D19@eusaamb105.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.198.6] Content-Type: text/plain; charset="us-ascii" Content-ID: <73142C6D9C20A447B117CF04FE280A1C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/Hrmyo0ZZbusvbVKLUxNUpIMXj3c Cc: "spring@ietf.org" , Uma Chunduri , "isis-wg@ietf.org" Subject: Re: [spring] [Isis-wg] comment on draft-ietf-isis-segment-routing-extensions-02 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, 01 Aug 2014 19:49:05 -0000 my point is that description of use cases should be on a=20 separate document in order to avoid replication of text=20 between isis and ospf drafts. Protocol extensions drafts should be focused on bits/bytes=20 to be carried by the protocol.=20 I think there's agreement on this. s. On Aug 1, 2014, at 8:57 PM, Chris Bowers wrote: > I disagree. The proposed text contains four Binding TLV usage examples w= hich are not qualitatively different from the two usage examples already in= cluded in section 2.4.3 of draft-ietf-isis-segment-routing-extensions-02. = Additional usage examples are needed to clarify how the TLVs and sub-TLVs d= efined in this document should be used, without ambiguity. >=20 > As an example of the lack of clarity in the current text, draft-ietf-isi= s-segment-routing-extensions-02 contains two different sub-TLVs for specify= ing SID/Label values in the Binding TLV. The two options are the SID/Label = Sub-TLV (section 2.3) and the Prefix-SID Sub-TLV (section 2.1). The curren= t text does not clearly explain under what circumstances the two different = sub-TLVs should be used in the Binding TLV. The proposed text makes the u= sage clear by means of examples. =20 >=20 > Chris >=20 > -----Original Message----- > From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]=20 > Sent: Friday, August 01, 2014 1:54 AM > To: Uma Chunduri > Cc: Chris Bowers; isis-wg@ietf.org; spring@ietf.org > Subject: Re: [Isis-wg] comment on draft-ietf-isis-segment-routing-extensi= ons-02 >=20 > Uma, >=20 > I agree. >=20 > I think we also explicitly stated this during our meeting in Toronto (fro= m the minutes): >=20 > -------------------------------------------------------------------- > Uma: Needed to reference use cases in Hannes' draft. > Hannes: Perhaps what we could do is add some practical examples for > RSVP, BGP, and LDP LSPs binding. Not formal use cases. > Stefano: Would rather not go into applications in this ISIS draft. > Peter Psenak: Should go into a separate document that could be > referenced from both ISIS and OSPF. > Alia Atlas: There is a SPRING WG for such a document. > ------------------------------------------------------------------- >=20 > Now, note that: > draft-filsfils-spring-segment-routing > draft-filsfils-spring-segment-routing-ldp-interop >=20 > describe the use case of the SR Mapping Server that is implemented using = the Binding TLV. >=20 > As you suggested, Hannes drafts can be combined so to produce a use-case = document (in spring) for the Binding TLV RSVP-based use-cases. >=20 >=20 > s. >=20 >=20 > On Jul 31, 2014, at 11:55 PM, Uma Chunduri wrote: >=20 >> [CC'ed Spring WG] >>=20 >> I agree with what Chris said below in principle. But all this should not= be obviously part of ISIS/IGP extensions WG documents.. >>=20 >> Use cases for binding TLVs are explained in great details in 2 key=20 >> documents (had to shuffle through to get here) - >>=20 >> 1. http://tools.ietf.org/html/draft-gredler-rtgwg-igp-label-advert= isement-05 >> 2. http://tools.ietf.org/html/draft-gredler-spring-mpls-06 >>=20 >> IMO, both are very useful documents. >> It would be good to combine both of these and publish as a "spring " do= cument and eventually it should progress there. >> AFAICT, Both ISIS and OSPF should refer the same eventually to get more = clarity and use of binding TLVs described currently. >>=20 >> -- >> Uma C. >>=20 >> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Chris=20 >> Bowers >> Sent: Thursday, July 31, 2014 2:42 PM >> To: isis-wg@ietf.org >> Subject: [Isis-wg] comment on=20 >> draft-ietf-isis-segment-routing-extensions-02 >>=20 >> All, >>=20 >> The current text of draft-ietf-isis-segment-routing-extensions-02 does n= ot clearly explain the usage of the Binding TLV for advertising LSPs create= d using other protocols. I would like to propose the following text to be = included as section 2.5 . >>=20 >> Thanks, >> Chris >>=20 >> ---------------- >>=20 >> 2.5 Binding TLV usage examples >>=20 >> This section gives examples of using the Binding TLV to advertise SID/la= bel bindings associated with RSVP-TE, LDP, and BGP labeled-unicast LSPs. I= t also includes an example of advertising a context-id for egress node prot= ection. All of the examples assume that the Binding TLV weight=3D1 and met= ric=3D100.=20 >>=20 >> 2.5.1 Advertising an RSVP-TE LSP using the Binding TLV >>=20 >> Assume that R1 has signaled an RSVP-TE LSP to egress router (R4) with ro= uter-id=3D10.4.4.4, with ER0 =3D (192.1.2.2 [strict], 192.2.3.2 [strict], 1= 92.3.4.2 [strict]). R1 can advertise a locally significant label binding fo= r this LSP (with label value=3D1099) using the following values and sub-TL= Vs in the Binding TLV.=20 >>=20 >> Binding-TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, prefix length= =3D32,=20 >> FEC prefix=3D10.4.4.4 SID/Label Sub-TLV: label=3D1099 ERO Metric sub-TLV= :=20 >> metric=3D100 >> IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.1.2.2 >> IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.2.3.2 >> IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.3.4.2 >>=20 >> 2.5.2 Advertising an LDP LSP using the Binding TLV >>=20 >> Assume that R5 has learned a FEC-label binding via LDP for FEC=3D10.8.8.= 8/32. R5 can advertise a locally significant label binding for this LSP (w= ith label value=3D5099) using the following values and sub-TLVs in the Bind= ing TLV.=20 >>=20 >> Binding TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, prefix length= =3D32,=20 >> FEC prefix=3D10.8.8.8 SID/Label Sub-TLV: label=3D5099 ERO Metric sub-TLV= :=20 >> metric=3D100 >> IPv4 ERO sub-TLV: L-bit=3D1, IPv4 address=3D10.8.8.8 >>=20 >> 2.5.3 Advertising a BGP labeled-unicast LSP using the Binding TLV >>=20 >> Assume that R9 has used BGP labeled-unicast to learn a label binding for= prefix 10.15.15.15/32 with BGP next-hop=3D10.12.12.12. R9 can advertise = a locally significant label binding for this LSP (with label value=3D7099) = using the following values and sub-TLVs in the Binding TLV.=20 >>=20 >> Binding-TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, prefix length= =3D32,=20 >> FEC prefix=3D10.15.15.15 SID/Label Sub-TLV: label=3D7099 ERO Metric=20 >> sub-TLV: metric=3D100 >> IPv4 ERO sub-TLV: L-bit=3D1, IPv4 address=3D10.12.12.12 >>=20 >> 2.5.4 Advertising a context-id for egress node protection using the=20 >> Binding TLV >>=20 >> Assume that R22 is configured in the protector role to provide egress no= de protection for R21 using context-id=3D10.0.0.21. R22 can advertise the = label associated with this context-id (with label value=3D8099) using the f= ollowing values and sub-TLVs in the Binding TLV. >>=20 >> Binding TLV: F-bit=3D0, M-bit=3D1, weight=3D1, range=3D1, prefix length= =3D32,=20 >> FEC prefix=3D10.0.0.21 SID/Label Sub-TLV: label=3D8099 >>=20 >> ---------------- >>=20 >>=20 >>=20 >> _______________________________________________ >> Isis-wg mailing list >> Isis-wg@ietf.org >> https://www.ietf.org/mailman/listinfo/isis-wg >=20 From nobody Fri Aug 1 14:51:24 2014 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 48C941A0107; Fri, 1 Aug 2014 14:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 ltiCNlWAx-bj; Fri, 1 Aug 2014 14:51:17 -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 0E2161A00DF; Fri, 1 Aug 2014 14:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7677; q=dns/txt; s=iport; t=1406929877; x=1408139477; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sH9Stuo2hFi0ErFAvZsdUJi/2sQ/x8XJJ8biqJ2/kiI=; b=WBjj192Gk3JVYMkzVij8FRFLZdG42e1XBU3pE3713HLyzEn7JYhC/vCx v0Q9FZaogXGYgDm7ZkJb4zgXIuO9X9NsMUyPkH53xXWhJsPRnPXj1H74I rbVMYOclBC70Cq1epigpa62Xy/9vr+CzbHSl4qdW7kgBb5XHcJOQy3RfZ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAKUK3FOtJV2d/2dsb2JhbABbgw1SVwTMBwyGd1MBgQsWd4QDAQEBBAEBATctBwsMBAIBCBEEAQEBHgkHJwsUCQgCBAENBYhCDchaF48ZMwcGhEUFl0+EK4FUkwaDSWyBRQ X-IronPort-AV: E=Sophos;i="5.01,782,1400025600"; d="scan'208";a="65911095" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP; 01 Aug 2014 21:51:15 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s71LpGTC021319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 1 Aug 2014 21:51:16 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.69]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0123.003; Fri, 1 Aug 2014 16:51:15 -0500 From: "Acee Lindem (acee)" To: "Stefano Previdi (sprevidi)" , Chris Bowers Thread-Topic: [spring] [Isis-wg] comment on draft-ietf-isis-segment-routing-extensions-02 Thread-Index: AQHPrdK3K92TJYOgt0uK26EtbeaoIg== Date: Fri, 1 Aug 2014 21:51:14 +0000 Message-ID: References: <2f151ad2a667450e9e861d94458ee73f@BLUPR05MB292.namprd05.prod.outlook.com> <1B502206DFA0C544B7A60469152008633F319D19@eusaamb105.ericsson.se> 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.195] Content-Type: text/plain; charset="us-ascii" Content-ID: <9633890EEA765C43B10D903006E26AA6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/X_YIYYDE2IcNTYQINTukZvVJjyQ Cc: "spring@ietf.org" , Uma Chunduri , "isis-wg@ietf.org" Subject: Re: [spring] [Isis-wg] comment on draft-ietf-isis-segment-routing-extensions-02 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, 01 Aug 2014 21:51:20 -0000 This is my preference for the protocol extension drafts. Thanks, Acee=20 On 8/1/14, 3:48 PM, "Stefano Previdi (sprevidi)" wrote: >my point is that description of use cases should be on a >separate document in order to avoid replication of text >between isis and ospf drafts. > >Protocol extensions drafts should be focused on bits/bytes >to be carried by the protocol. > >I think there's agreement on this. > >s. > > >On Aug 1, 2014, at 8:57 PM, Chris Bowers wrote: > >> I disagree. The proposed text contains four Binding TLV usage examples >>which are not qualitatively different from the two usage examples >>already included in section 2.4.3 of >>draft-ietf-isis-segment-routing-extensions-02. Additional usage >>examples are needed to clarify how the TLVs and sub-TLVs defined in this >>document should be used, without ambiguity. >>=20 >> As an example of the lack of clarity in the current text, >>draft-ietf-isis-segment-routing-extensions-02 contains two different >>sub-TLVs for specifying SID/Label values in the Binding TLV. The two >>options are the SID/Label Sub-TLV (section 2.3) and the Prefix-SID >>Sub-TLV (section 2.1). The current text does not clearly explain under >>what circumstances the two different sub-TLVs should be used in the >>Binding TLV. The proposed text makes the usage clear by means of >>examples. =20 >>=20 >> Chris >>=20 >> -----Original Message----- >> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >> Sent: Friday, August 01, 2014 1:54 AM >> To: Uma Chunduri >> Cc: Chris Bowers; isis-wg@ietf.org; spring@ietf.org >> Subject: Re: [Isis-wg] comment on >>draft-ietf-isis-segment-routing-extensions-02 >>=20 >> Uma, >>=20 >> I agree. >>=20 >> I think we also explicitly stated this during our meeting in Toronto >>(from the minutes): >>=20 >> -------------------------------------------------------------------- >> Uma: Needed to reference use cases in Hannes' draft. >> Hannes: Perhaps what we could do is add some practical examples for >> RSVP, BGP, and LDP LSPs binding. Not formal use cases. >> Stefano: Would rather not go into applications in this ISIS draft. >> Peter Psenak: Should go into a separate document that could be >> referenced from both ISIS and OSPF. >> Alia Atlas: There is a SPRING WG for such a document. >> ------------------------------------------------------------------- >>=20 >> Now, note that: >> draft-filsfils-spring-segment-routing >> draft-filsfils-spring-segment-routing-ldp-interop >>=20 >> describe the use case of the SR Mapping Server that is implemented >>using the Binding TLV. >>=20 >> As you suggested, Hannes drafts can be combined so to produce a >>use-case document (in spring) for the Binding TLV RSVP-based use-cases. >>=20 >>=20 >> s. >>=20 >>=20 >> On Jul 31, 2014, at 11:55 PM, Uma Chunduri wrote: >>=20 >>> [CC'ed Spring WG] >>>=20 >>> I agree with what Chris said below in principle. But all this should >>>not be obviously part of ISIS/IGP extensions WG documents.. >>>=20 >>> Use cases for binding TLVs are explained in great details in 2 key >>> documents (had to shuffle through to get here) - >>>=20 >>> 1. =20 >>>http://tools.ietf.org/html/draft-gredler-rtgwg-igp-label-advertisement-0 >>>5 >>> 2. http://tools.ietf.org/html/draft-gredler-spring-mpls-06 >>>=20 >>> IMO, both are very useful documents. >>> It would be good to combine both of these and publish as a "spring " >>>document and eventually it should progress there. >>> AFAICT, Both ISIS and OSPF should refer the same eventually to get >>>more clarity and use of binding TLVs described currently. >>>=20 >>> -- >>> Uma C. >>>=20 >>> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Chris >>> Bowers >>> Sent: Thursday, July 31, 2014 2:42 PM >>> To: isis-wg@ietf.org >>> Subject: [Isis-wg] comment on >>> draft-ietf-isis-segment-routing-extensions-02 >>>=20 >>> All, >>>=20 >>> The current text of draft-ietf-isis-segment-routing-extensions-02 does >>>not clearly explain the usage of the Binding TLV for advertising LSPs >>>created using other protocols. I would like to propose the following >>>text to be included as section 2.5 . >>>=20 >>> Thanks, >>> Chris >>>=20 >>> ---------------- >>>=20 >>> 2.5 Binding TLV usage examples >>>=20 >>> This section gives examples of using the Binding TLV to advertise >>>SID/label bindings associated with RSVP-TE, LDP, and BGP >>>labeled-unicast LSPs. It also includes an example of advertising a >>>context-id for egress node protection. All of the examples assume that >>>the Binding TLV weight=3D1 and metric=3D100. >>>=20 >>> 2.5.1 Advertising an RSVP-TE LSP using the Binding TLV >>>=20 >>> Assume that R1 has signaled an RSVP-TE LSP to egress router (R4) with >>>router-id=3D10.4.4.4, with ER0 =3D (192.1.2.2 [strict], 192.2.3.2 [stric= t], >>>192.3.4.2 [strict]). R1 can advertise a locally significant label >>>binding for this LSP (with label value=3D1099) using the following >>>values and sub-TLVs in the Binding TLV. >>>=20 >>> Binding-TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, prefix length= =3D32, >>> FEC prefix=3D10.4.4.4 SID/Label Sub-TLV: label=3D1099 ERO Metric sub-TL= V: >>> metric=3D100 >>> IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.1.2.2 >>> IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.2.3.2 >>> IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.3.4.2 >>>=20 >>> 2.5.2 Advertising an LDP LSP using the Binding TLV >>>=20 >>> Assume that R5 has learned a FEC-label binding via LDP for >>>FEC=3D10.8.8.8/32. R5 can advertise a locally significant label binding >>>for this LSP (with label value=3D5099) using the following values and >>>sub-TLVs in the Binding TLV. >>>=20 >>> Binding TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, prefix length= =3D32, >>> FEC prefix=3D10.8.8.8 SID/Label Sub-TLV: label=3D5099 ERO Metric sub-TL= V: >>> metric=3D100 >>> IPv4 ERO sub-TLV: L-bit=3D1, IPv4 address=3D10.8.8.8 >>>=20 >>> 2.5.3 Advertising a BGP labeled-unicast LSP using the Binding TLV >>>=20 >>> Assume that R9 has used BGP labeled-unicast to learn a label binding >>>for prefix 10.15.15.15/32 with BGP next-hop=3D10.12.12.12. R9 can >>>advertise a locally significant label binding for this LSP (with label >>>value=3D7099) using the following values and sub-TLVs in the Binding >>>TLV.=20 >>>=20 >>> Binding-TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, prefix length= =3D32, >>> FEC prefix=3D10.15.15.15 SID/Label Sub-TLV: label=3D7099 ERO Metric >>> sub-TLV: metric=3D100 >>> IPv4 ERO sub-TLV: L-bit=3D1, IPv4 address=3D10.12.12.12 >>>=20 >>> 2.5.4 Advertising a context-id for egress node protection using the >>> Binding TLV >>>=20 >>> Assume that R22 is configured in the protector role to provide egress >>>node protection for R21 using context-id=3D10.0.0.21. R22 can advertise >>>the label associated with this context-id (with label value=3D8099) usin= g >>>the following values and sub-TLVs in the Binding TLV. >>>=20 >>> Binding TLV: F-bit=3D0, M-bit=3D1, weight=3D1, range=3D1, prefix length= =3D32, >>> FEC prefix=3D10.0.0.21 SID/Label Sub-TLV: label=3D8099 >>>=20 >>> ---------------- >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> Isis-wg mailing list >>> Isis-wg@ietf.org >>> https://www.ietf.org/mailman/listinfo/isis-wg >>=20 > >_______________________________________________ >spring mailing list >spring@ietf.org >https://www.ietf.org/mailman/listinfo/spring From nobody Sun Aug 3 23:55:45 2014 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 D61A21B2882; Sun, 3 Aug 2014 23:55: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 545KV9kHqkCp; Sun, 3 Aug 2014 23:55:37 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0141.outbound.protection.outlook.com [207.46.163.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA1E81B2888; Sun, 3 Aug 2014 23:55:32 -0700 (PDT) Received: from hannes-mba.local (193.110.55.12) by DM2PR05MB445.namprd05.prod.outlook.com (10.141.104.154) with Microsoft SMTP Server (TLS) id 15.0.995.14; Mon, 4 Aug 2014 06:55:22 +0000 Message-ID: <53DF2E4A.9020602@juniper.net> Date: Mon, 4 Aug 2014 08:55:06 +0200 From: Hannes Gredler User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Acee Lindem (acee)" , "Stefano Previdi (sprevidi)" , Chris Bowers References: <2f151ad2a667450e9e861d94458ee73f@BLUPR05MB292.namprd05.prod.outlook.com> <1B502206DFA0C544B7A60469152008633F319D19@eusaamb105.ericsson.se> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [193.110.55.12] X-ClientProxiedBy: AM3PR05CA029.eurprd05.prod.outlook.com (10.141.192.39) To DM2PR05MB445.namprd05.prod.outlook.com (10.141.104.154) X-Microsoft-Antispam: BCL:0;PCL:0;RULEID: X-Forefront-PRVS: 0293D40691 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(6009001)(18374002)(199002)(189002)(51704005)(13464003)(377454003)(164054003)(479174003)(24454002)(37854004)(92566001)(92726001)(77096002)(76176999)(87266999)(54356999)(65816999)(99396002)(50986999)(93886004)(85306004)(107046002)(74502001)(74662001)(105586002)(106356001)(15202345003)(95666004)(79102001)(59896001)(77982001)(15975445006)(83506001)(50466002)(76482001)(64126003)(81542001)(81342001)(101416001)(64706001)(20776003)(66066001)(65956001)(80022001)(65806001)(33656002)(47776003)(86362001)(102836001)(80316001)(19580395003)(83322001)(19580405001)(87976001)(1941001)(83072002)(85852003)(36756003)(4396001)(31966008)(46102001)(42186005)(21056001)(23746002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR05MB445; H:hannes-mba.local; FPR:; PTR:InfoNoRecords; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=hannes@juniper.net; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/spring/jeLVBVwXZNy9GBDkNmZIgVmihy4 Cc: "spring@ietf.org" , "isis-wg@ietf.org" Subject: Re: [spring] [Isis-wg] comment on draft-ietf-isis-segment-routing-extensions-02 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, 04 Aug 2014 06:55:42 -0000 ok, so my understanding is: - have a standalone document which describes the usage of 'external' protocols (LDP, BGP-LU, RSVP, stacked labels, egress protection) and add it as a reference to all the SR one-the-wire protocol specs. (OSPFv2, OSPFv3, IS-IS, BGP-LS). agreed ? /hannes On 8/1/14 23:51, Acee Lindem (acee) wrote: > This is my preference for the protocol extension drafts. > Thanks, > Acee > > On 8/1/14, 3:48 PM, "Stefano Previdi (sprevidi)" > wrote: > >> my point is that description of use cases should be on a >> separate document in order to avoid replication of text >> between isis and ospf drafts. >> >> Protocol extensions drafts should be focused on bits/bytes >> to be carried by the protocol. >> >> I think there's agreement on this. >> >> s. >> >> >> On Aug 1, 2014, at 8:57 PM, Chris Bowers wrote: >> >>> I disagree. The proposed text contains four Binding TLV usage examples >>> which are not qualitatively different from the two usage examples >>> already included in section 2.4.3 of >>> draft-ietf-isis-segment-routing-extensions-02. Additional usage >>> examples are needed to clarify how the TLVs and sub-TLVs defined in this >>> document should be used, without ambiguity. >>> >>> As an example of the lack of clarity in the current text, >>> draft-ietf-isis-segment-routing-extensions-02 contains two different >>> sub-TLVs for specifying SID/Label values in the Binding TLV. The two >>> options are the SID/Label Sub-TLV (section 2.3) and the Prefix-SID >>> Sub-TLV (section 2.1). The current text does not clearly explain under >>> what circumstances the two different sub-TLVs should be used in the >>> Binding TLV. The proposed text makes the usage clear by means of >>> examples. >>> >>> Chris >>> >>> -----Original Message----- >>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >>> Sent: Friday, August 01, 2014 1:54 AM >>> To: Uma Chunduri >>> Cc: Chris Bowers; isis-wg@ietf.org; spring@ietf.org >>> Subject: Re: [Isis-wg] comment on >>> draft-ietf-isis-segment-routing-extensions-02 >>> >>> Uma, >>> >>> I agree. >>> >>> I think we also explicitly stated this during our meeting in Toronto >>> (from the minutes): >>> >>> -------------------------------------------------------------------- >>> Uma: Needed to reference use cases in Hannes' draft. >>> Hannes: Perhaps what we could do is add some practical examples for >>> RSVP, BGP, and LDP LSPs binding. Not formal use cases. >>> Stefano: Would rather not go into applications in this ISIS draft. >>> Peter Psenak: Should go into a separate document that could be >>> referenced from both ISIS and OSPF. >>> Alia Atlas: There is a SPRING WG for such a document. >>> ------------------------------------------------------------------- >>> >>> Now, note that: >>> draft-filsfils-spring-segment-routing >>> draft-filsfils-spring-segment-routing-ldp-interop >>> >>> describe the use case of the SR Mapping Server that is implemented >>> using the Binding TLV. >>> >>> As you suggested, Hannes drafts can be combined so to produce a >>> use-case document (in spring) for the Binding TLV RSVP-based use-cases. >>> >>> >>> s. >>> >>> >>> On Jul 31, 2014, at 11:55 PM, Uma Chunduri wrote: >>> >>>> [CC'ed Spring WG] >>>> >>>> I agree with what Chris said below in principle. But all this should >>>> not be obviously part of ISIS/IGP extensions WG documents.. >>>> >>>> Use cases for binding TLVs are explained in great details in 2 key >>>> documents (had to shuffle through to get here) - >>>> >>>> 1. >>>> http://tools.ietf.org/html/draft-gredler-rtgwg-igp-label-advertisement-0 >>>> 5 >>>> 2. http://tools.ietf.org/html/draft-gredler-spring-mpls-06 >>>> >>>> IMO, both are very useful documents. >>>> It would be good to combine both of these and publish as a "spring " >>>> document and eventually it should progress there. >>>> AFAICT, Both ISIS and OSPF should refer the same eventually to get >>>> more clarity and use of binding TLVs described currently. >>>> >>>> -- >>>> Uma C. >>>> >>>> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Chris >>>> Bowers >>>> Sent: Thursday, July 31, 2014 2:42 PM >>>> To: isis-wg@ietf.org >>>> Subject: [Isis-wg] comment on >>>> draft-ietf-isis-segment-routing-extensions-02 >>>> >>>> All, >>>> >>>> The current text of draft-ietf-isis-segment-routing-extensions-02 does >>>> not clearly explain the usage of the Binding TLV for advertising LSPs >>>> created using other protocols. I would like to propose the following >>>> text to be included as section 2.5 . >>>> >>>> Thanks, >>>> Chris >>>> >>>> ---------------- >>>> >>>> 2.5 Binding TLV usage examples >>>> >>>> This section gives examples of using the Binding TLV to advertise >>>> SID/label bindings associated with RSVP-TE, LDP, and BGP >>>> labeled-unicast LSPs. It also includes an example of advertising a >>>> context-id for egress node protection. All of the examples assume that >>>> the Binding TLV weight=1 and metric=100. >>>> >>>> 2.5.1 Advertising an RSVP-TE LSP using the Binding TLV >>>> >>>> Assume that R1 has signaled an RSVP-TE LSP to egress router (R4) with >>>> router-id=10.4.4.4, with ER0 = (192.1.2.2 [strict], 192.2.3.2 [strict], >>>> 192.3.4.2 [strict]). R1 can advertise a locally significant label >>>> binding for this LSP (with label value=1099) using the following >>>> values and sub-TLVs in the Binding TLV. >>>> >>>> Binding-TLV: F-bit=0, M-bit=0, weight=1, range=1, prefix length=32, >>>> FEC prefix=10.4.4.4 SID/Label Sub-TLV: label=1099 ERO Metric sub-TLV: >>>> metric=100 >>>> IPv4 ERO sub-TLV: L-bit=0, IPv4 address=192.1.2.2 >>>> IPv4 ERO sub-TLV: L-bit=0, IPv4 address=192.2.3.2 >>>> IPv4 ERO sub-TLV: L-bit=0, IPv4 address=192.3.4.2 >>>> >>>> 2.5.2 Advertising an LDP LSP using the Binding TLV >>>> >>>> Assume that R5 has learned a FEC-label binding via LDP for >>>> FEC=10.8.8.8/32. R5 can advertise a locally significant label binding >>>> for this LSP (with label value=5099) using the following values and >>>> sub-TLVs in the Binding TLV. >>>> >>>> Binding TLV: F-bit=0, M-bit=0, weight=1, range=1, prefix length=32, >>>> FEC prefix=10.8.8.8 SID/Label Sub-TLV: label=5099 ERO Metric sub-TLV: >>>> metric=100 >>>> IPv4 ERO sub-TLV: L-bit=1, IPv4 address=10.8.8.8 >>>> >>>> 2.5.3 Advertising a BGP labeled-unicast LSP using the Binding TLV >>>> >>>> Assume that R9 has used BGP labeled-unicast to learn a label binding >>>> for prefix 10.15.15.15/32 with BGP next-hop=10.12.12.12. R9 can >>>> advertise a locally significant label binding for this LSP (with label >>>> value=7099) using the following values and sub-TLVs in the Binding >>>> TLV. >>>> >>>> Binding-TLV: F-bit=0, M-bit=0, weight=1, range=1, prefix length=32, >>>> FEC prefix=10.15.15.15 SID/Label Sub-TLV: label=7099 ERO Metric >>>> sub-TLV: metric=100 >>>> IPv4 ERO sub-TLV: L-bit=1, IPv4 address=10.12.12.12 >>>> >>>> 2.5.4 Advertising a context-id for egress node protection using the >>>> Binding TLV >>>> >>>> Assume that R22 is configured in the protector role to provide egress >>>> node protection for R21 using context-id=10.0.0.21. R22 can advertise >>>> the label associated with this context-id (with label value=8099) using >>>> the following values and sub-TLVs in the Binding TLV. >>>> >>>> Binding TLV: F-bit=0, M-bit=1, weight=1, range=1, prefix length=32, >>>> FEC prefix=10.0.0.21 SID/Label Sub-TLV: label=8099 >>>> >>>> ---------------- >>>> >>>> >>>> >>>> _______________________________________________ >>>> Isis-wg mailing list >>>> Isis-wg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/isis-wg >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg From nobody Mon Aug 4 01:44:29 2014 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 483BE1B28B8; Mon, 4 Aug 2014 01:44:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 UK3CA1pVakGp; Mon, 4 Aug 2014 01:44:24 -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 415AB1B28CE; Mon, 4 Aug 2014 01:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22512; q=dns/txt; s=iport; t=1407141864; x=1408351464; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bEAntUV/2j+T4tqAF+o0+/NwzkWxVx84RBaK2TlgC7I=; b=S/dIneoah+0z2AWDT4ACLcB16hRvKnq0fZMqD5BTl1TmwYLm5LJfwIMM 1lK4yW3t6jHB7rf6ur+O8xU7L6sFmJ++AGdhbGxoMerwiT5ioYRKMqi+j 3BGKeLFKLEwp8d4shiPil+KevwoJPlU+IN4OFiQQxvZqnqaN+U4IAXJS8 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgFACNH31OtJA2E/2dsb2JhbABbgkdGUlfKQYFZAQuGd1MBgRcWd4QDAQEBBAEBASo6BwsMBAIBCBEEAQEBCh0HJwsUCQgCBAENBQiIOg3EKxePGy0EBgEGgymBHAWXWoYAkwuCB4FGbA X-IronPort-AV: E=Sophos;i="5.01,796,1400025600"; d="scan'208,217";a="341779700" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-9.cisco.com with ESMTP; 04 Aug 2014 08:44:23 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s748iMgW030000 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Aug 2014 08:44:23 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.37]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0123.003; Mon, 4 Aug 2014 03:44:22 -0500 From: "Stefano Previdi (sprevidi)" To: Hannes Gredler , "Acee Lindem (acee)" , Chris Bowers Thread-Topic: Re: [Isis-wg] [spring] comment on draft-ietf-isis-segment-routing-extensions-02 Thread-Index: AQHPr8BJGKUrASnvWEuyoKK8N1jkDQ== Date: Mon, 4 Aug 2014 08:44:22 +0000 Message-ID: <8F6D261188DF40FB70701EB0D7CE7F6A1B0B7F48@sp> References: <2f151ad2a667450e9e861d94458ee73f@BLUPR05MB292.namprd05.prod.outlook.com> <1B502206DFA0C544B7A60469152008633F319D19@eusaamb105.ericsson.se> ,<53DF2E4A.9020602@juniper.net> In-Reply-To: <53DF2E4A.9020602@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_8F6D261188DF40FB70701EB0D7CE7F6A1B0B7F48sp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/AYxrUrdSnrBBt-IPkPNHk4w3t1k Cc: "spring@ietf.org" , "isis-wg@ietf.org" Subject: Re: [spring] [Isis-wg] comment on draft-ietf-isis-segment-routing-extensions-02 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, 04 Aug 2014 08:44:28 -0000 --_000_8F6D261188DF40FB70701EB0D7CE7F6A1B0B7F48sp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Multiple use cases documents. Draft-filsfils-segment-routing-use-cases bein= g one. s. Sent from mobile -----Original Message----- From: Hannes Gredler [hannes@juniper.net] Received: Monday August 4, 2014, 08:55 To: Acee Lindem (acee) [acee@cisco.com]; Stefano Previdi (sprevidi) [sprevi= di@cisco.com]; Chris Bowers [cbowers@juniper.net] CC: spring@ietf.org [spring@ietf.org]; isis-wg@ietf.org [isis-wg@ietf.org] Subject: Re: [Isis-wg] [spring] comment on draft-ietf-isis-segment-routing-= extensions-02 ok, so my understanding is: - have a standalone document which describes the usage of 'external' protocols (LDP, BGP-LU, RSVP, stacked labels, egress protection) and add it as a reference to all the SR one-the-wire protocol specs. (OSPFv2, OSPFv3, IS-IS, BGP-LS). agreed ? /hannes On 8/1/14 23:51, Acee Lindem (acee) wrote: > This is my preference for the protocol extension drafts. > Thanks, > Acee > > On 8/1/14, 3:48 PM, "Stefano Previdi (sprevidi)" > wrote: > >> my point is that description of use cases should be on a >> separate document in order to avoid replication of text >> between isis and ospf drafts. >> >> Protocol extensions drafts should be focused on bits/bytes >> to be carried by the protocol. >> >> I think there's agreement on this. >> >> s. >> >> >> On Aug 1, 2014, at 8:57 PM, Chris Bowers wrote: >> >>> I disagree. The proposed text contains four Binding TLV usage examples >>> which are not qualitatively different from the two usage examples >>> already included in section 2.4.3 of >>> draft-ietf-isis-segment-routing-extensions-02. Additional usage >>> examples are needed to clarify how the TLVs and sub-TLVs defined in thi= s >>> document should be used, without ambiguity. >>> >>> As an example of the lack of clarity in the current text, >>> draft-ietf-isis-segment-routing-extensions-02 contains two different >>> sub-TLVs for specifying SID/Label values in the Binding TLV. The two >>> options are the SID/Label Sub-TLV (section 2.3) and the Prefix-SID >>> Sub-TLV (section 2.1). The current text does not clearly explain under >>> what circumstances the two different sub-TLVs should be used in the >>> Binding TLV. The proposed text makes the usage clear by means of >>> examples. >>> >>> Chris >>> >>> -----Original Message----- >>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com] >>> Sent: Friday, August 01, 2014 1:54 AM >>> To: Uma Chunduri >>> Cc: Chris Bowers; isis-wg@ietf.org; spring@ietf.org >>> Subject: Re: [Isis-wg] comment on >>> draft-ietf-isis-segment-routing-extensions-02 >>> >>> Uma, >>> >>> I agree. >>> >>> I think we also explicitly stated this during our meeting in Toronto >>> (from the minutes): >>> >>> -------------------------------------------------------------------- >>> Uma: Needed to reference use cases in Hannes' draft. >>> Hannes: Perhaps what we could do is add some practical examples for >>> RSVP, BGP, and LDP LSPs binding. Not formal use cases. >>> Stefano: Would rather not go into applications in this ISIS draft. >>> Peter Psenak: Should go into a separate document that could be >>> referenced from both ISIS and OSPF. >>> Alia Atlas: There is a SPRING WG for such a document. >>> ------------------------------------------------------------------- >>> >>> Now, note that: >>> draft-filsfils-spring-segment-routing >>> draft-filsfils-spring-segment-routing-ldp-interop >>> >>> describe the use case of the SR Mapping Server that is implemented >>> using the Binding TLV. >>> >>> As you suggested, Hannes drafts can be combined so to produce a >>> use-case document (in spring) for the Binding TLV RSVP-based use-cases. >>> >>> >>> s. >>> >>> >>> On Jul 31, 2014, at 11:55 PM, Uma Chunduri wrote: >>> >>>> [CC'ed Spring WG] >>>> >>>> I agree with what Chris said below in principle. But all this should >>>> not be obviously part of ISIS/IGP extensions WG documents.. >>>> >>>> Use cases for binding TLVs are explained in great details in 2 key >>>> documents (had to shuffle through to get here) - >>>> >>>> 1. >>>> http://tools.ietf.org/html/draft-gredler-rtgwg-igp-label-advertisement= -0 >>>> 5 >>>> 2. http://tools.ietf.org/html/draft-gredler-spring-mpls-06 >>>> >>>> IMO, both are very useful documents. >>>> It would be good to combine both of these and publish as a "spring " >>>> document and eventually it should progress there. >>>> AFAICT, Both ISIS and OSPF should refer the same eventually to get >>>> more clarity and use of binding TLVs described currently. >>>> >>>> -- >>>> Uma C. >>>> >>>> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Chris >>>> Bowers >>>> Sent: Thursday, July 31, 2014 2:42 PM >>>> To: isis-wg@ietf.org >>>> Subject: [Isis-wg] comment on >>>> draft-ietf-isis-segment-routing-extensions-02 >>>> >>>> All, >>>> >>>> The current text of draft-ietf-isis-segment-routing-extensions-02 does >>>> not clearly explain the usage of the Binding TLV for advertising LSPs >>>> created using other protocols. I would like to propose the following >>>> text to be included as section 2.5 . >>>> >>>> Thanks, >>>> Chris >>>> >>>> ---------------- >>>> >>>> 2.5 Binding TLV usage examples >>>> >>>> This section gives examples of using the Binding TLV to advertise >>>> SID/label bindings associated with RSVP-TE, LDP, and BGP >>>> labeled-unicast LSPs. It also includes an example of advertising a >>>> context-id for egress node protection. All of the examples assume tha= t >>>> the Binding TLV weight=3D1 and metric=3D100. >>>> >>>> 2.5.1 Advertising an RSVP-TE LSP using the Binding TLV >>>> >>>> Assume that R1 has signaled an RSVP-TE LSP to egress router (R4) with >>>> router-id=3D10.4.4.4, with ER0 =3D (192.1.2.2 [strict], 192.2.3.2 [str= ict], >>>> 192.3.4.2 [strict]). R1 can advertise a locally significant label >>>> binding for this LSP (with label value=3D1099) using the following >>>> values and sub-TLVs in the Binding TLV. >>>> >>>> Binding-TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, prefix lengt= h=3D32, >>>> FEC prefix=3D10.4.4.4 SID/Label Sub-TLV: label=3D1099 ERO Metric sub-T= LV: >>>> metric=3D100 >>>> IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.1.2.2 >>>> IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.2.3.2 >>>> IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.3.4.2 >>>> >>>> 2.5.2 Advertising an LDP LSP using the Binding TLV >>>> >>>> Assume that R5 has learned a FEC-label binding via LDP for >>>> FEC=3D10.8.8.8/32. R5 can advertise a locally significant label bindi= ng >>>> for this LSP (with label value=3D5099) using the following values and >>>> sub-TLVs in the Binding TLV. >>>> >>>> Binding TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, prefix lengt= h=3D32, >>>> FEC prefix=3D10.8.8.8 SID/Label Sub-TLV: label=3D5099 ERO Metric sub-T= LV: >>>> metric=3D100 >>>> IPv4 ERO sub-TLV: L-bit=3D1, IPv4 address=3D10.8.8.8 >>>> >>>> 2.5.3 Advertising a BGP labeled-unicast LSP using the Binding TLV >>>> >>>> Assume that R9 has used BGP labeled-unicast to learn a label binding >>>> for prefix 10.15.15.15/32 with BGP next-hop=3D10.12.12.12. R9 can >>>> advertise a locally significant label binding for this LSP (with label >>>> value=3D7099) using the following values and sub-TLVs in the Binding >>>> TLV. >>>> >>>> Binding-TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, prefix lengt= h=3D32, >>>> FEC prefix=3D10.15.15.15 SID/Label Sub-TLV: label=3D7099 ERO Metric >>>> sub-TLV: metric=3D100 >>>> IPv4 ERO sub-TLV: L-bit=3D1, IPv4 address=3D10.12.12.12 >>>> >>>> 2.5.4 Advertising a context-id for egress node protection using the >>>> Binding TLV >>>> >>>> Assume that R22 is configured in the protector role to provide egress >>>> node protection for R21 using context-id=3D10.0.0.21. R22 can adverti= se >>>> the label associated with this context-id (with label value=3D8099) us= ing >>>> the following values and sub-TLVs in the Binding TLV. >>>> >>>> Binding TLV: F-bit=3D0, M-bit=3D1, weight=3D1, range=3D1, prefix lengt= h=3D32, >>>> FEC prefix=3D10.0.0.21 SID/Label Sub-TLV: label=3D8099 >>>> >>>> ---------------- >>>> >>>> >>>> >>>> _______________________________________________ >>>> Isis-wg mailing list >>>> Isis-wg@ietf.org >>>> https://www.ietf.org/mailman/listinfo/isis-wg >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring > _______________________________________________ > Isis-wg mailing list > Isis-wg@ietf.org > https://www.ietf.org/mailman/listinfo/isis-wg --_000_8F6D261188DF40FB70701EB0D7CE7F6A1B0B7F48sp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Multipl= e use cases documents. Draft-filsfils-segment-routing-use-cases being one.

s. 


Sent from mobile


-----= Original Message-----
From: Hannes Gredler [hannes@juniper.net]
Received: Monday August 4, 2014, 08:55
To: Acee Lindem (acee) [acee@cisco.com]; Stefano Previdi (sprevidi) = [sprevidi@cisco.com]; Chris Bowers [cbowers@juniper.net]
CC: spring@ietf.org [spring@ietf.org]; isis-wg@ietf.org [isis-wg@iet= f.org]
Subject: Re: [Isis-wg] [spring] comment on draft-ietf-isis-segment-r= outing-extensions-02


ok, so my understanding is:

- have a standalone document which describes the usage of 'external'
protocols (LDP, BGP-LU, RSVP, stacked labels, egress protection)
and add it as a reference to all the SR one-the-wire protocol specs.
(OSPFv2, OSPFv3, IS-IS, BGP-LS).

agreed ?

/hannes

On 8/1/14 23:51, Acee Lindem (acee) wrote:
> This is my preference for the protocol extension drafts.
> Thanks,
> Acee
>
> On 8/1/14, 3:48 PM, "Stefano Previdi (sprevidi)" <sprevid= i@cisco.com>
> wrote:
>
>> my point is that description of use cases should be on a
>> separate document in order to avoid replication of text
>> between isis and ospf drafts.
>>
>> Protocol extensions drafts should be focused on bits/bytes
>> to be carried by the protocol.
>>
>> I think there's agreement on this.
>>
>> s.
>>
>>
>> On Aug 1, 2014, at 8:57 PM, Chris Bowers wrote:
>>
>>> I disagree.  The proposed text contains four Binding TLV = usage examples
>>> which are not qualitatively different from the two usage examp= les
>>> already included in section 2.4.3 of
>>> draft-ietf-isis-segment-routing-extensions-02.  Additiona= l usage
>>> examples are needed to clarify how the TLVs and sub-TLVs defin= ed in this
>>> document should be used, without ambiguity.
>>>
>>> As an example of the lack of clarity in the current text,
>>> draft-ietf-isis-segment-routing-extensions-02 contains two dif= ferent
>>> sub-TLVs for specifying SID/Label values in the Binding TLV. T= he two
>>> options are the SID/Label Sub-TLV (section 2.3) and the Prefix= -SID
>>> Sub-TLV (section 2.1).  The current text does not clearly= explain under
>>> what circumstances the two different sub-TLVs should be used i= n the
>>> Binding TLV.   The proposed text makes the usage cle= ar by means of
>>> examples.
>>>
>>> Chris
>>>
>>> -----Original Message-----
>>> From: Stefano Previdi (sprevidi) [mailto:sprevidi@cisco.com]
>>> Sent: Friday, August 01, 2014 1:54 AM
>>> To: Uma Chunduri
>>> Cc: Chris Bowers; isis-wg@ietf.org; spring@ietf.org
>>> Subject: Re: [Isis-wg] comment on
>>> draft-ietf-isis-segment-routing-extensions-02
>>>
>>> Uma,
>>>
>>> I agree.
>>>
>>> I think we also explicitly stated this during our meeting in T= oronto
>>> (from the minutes):
>>>
>>>    --------------------------------------------= ------------------------
>>>    Uma: Needed to reference use cases in Hannes= ' draft.
>>>    Hannes: Perhaps what we could do is add some= practical examples for
>>>          &nb= sp; RSVP, BGP, and LDP LSPs binding. Not formal use cases.
>>>    Stefano: Would rather not go into applicatio= ns in this ISIS draft.
>>>    Peter Psenak: Should go into a separate docu= ment that could be
>>>          &nb= sp; referenced from both ISIS and OSPF.
>>>    Alia Atlas: There is a SPRING WG for such a = document.
>>>    --------------------------------------------= -----------------------
>>>
>>> Now, note that:
>>>    draft-filsfils-spring-segment-routing
>>>    draft-filsfils-spring-segment-routing-ldp-in= terop
>>>
>>> describe the use case of the SR Mapping Server that is impleme= nted
>>> using the Binding TLV.
>>>
>>> As you suggested, Hannes drafts can be combined so to produce = a
>>> use-case document (in spring) for the Binding TLV RSVP-based u= se-cases.
>>>
>>>
>>> s.
>>>
>>>
>>> On Jul 31, 2014, at 11:55 PM, Uma Chunduri wrote:
>>>
>>>> [CC'ed Spring WG]
>>>>
>>>> I agree with what Chris said below in principle. But all t= his should
>>>> not be obviously part of ISIS/IGP extensions WG documents.= .
>>>>
>>>> Use  cases for binding TLVs are explained in great de= tails in 2 key
>>>> documents (had to shuffle through to get here) -
>>>>
>>>> 1.
>>>> http://tools.ietf.org/html/draft-gredler-rtgwg-igp-label-advertisement-0
>>>> 5
>>>> 2.       http://tools.ietf.org/html= /draft-gredler-spring-mpls-06
>>>>
>>>> IMO, both are very useful documents.
>>>> It would be good  to combine both of these and publis= h as a "spring "
>>>> document and eventually it should progress there.
>>>> AFAICT, Both ISIS and OSPF should refer the same eventuall= y to get
>>>> more clarity and use of binding TLVs described currently.<= br> >>>>
>>>> --
>>>> Uma C.
>>>>
>>>> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Chris
>>>> Bowers
>>>> Sent: Thursday, July 31, 2014 2:42 PM
>>>> To: isis-wg@ietf.org
>>>> Subject: [Isis-wg] comment on
>>>> draft-ietf-isis-segment-routing-extensions-02
>>>>
>>>> All,
>>>>
>>>> The current text of draft-ietf-isis-segment-routing-extens= ions-02 does
>>>> not clearly explain the usage of the Binding TLV for adver= tising LSPs
>>>> created using other protocols.  I would like to propo= se the following
>>>> text to be included as section 2.5 .
>>>>
>>>> Thanks,
>>>> Chris
>>>>
>>>> ----------------
>>>>
>>>> 2.5 Binding TLV usage examples
>>>>
>>>> This section gives examples of using the Binding TLV to ad= vertise
>>>> SID/label bindings associated with RSVP-TE, LDP, and BGP >>>> labeled-unicast LSPs.  It also includes an example of= advertising a
>>>> context-id for egress node protection.  All of the ex= amples assume that
>>>> the Binding TLV weight=3D1 and metric=3D100.
>>>>
>>>> 2.5.1 Advertising an RSVP-TE LSP using the Binding TLV
>>>>
>>>> Assume that R1 has signaled an RSVP-TE LSP to egress route= r (R4) with
>>>> router-id=3D10.4.4.4, with ER0 =3D (192.1.2.2 [strict], 19= 2.2.3.2 [strict],
>>>> 192.3.4.2 [strict]). R1 can advertise a locally significan= t label
>>>> binding for this LSP (with label value=3D1099)  using= the following
>>>> values and sub-TLVs in the Binding TLV.
>>>>
>>>> Binding-TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, = prefix length=3D32,
>>>> FEC prefix=3D10.4.4.4 SID/Label Sub-TLV: label=3D1099 ERO = Metric sub-TLV:
>>>> metric=3D100
>>>> IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.1.2.2
>>>> IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.2.3.2
>>>> IPv4 ERO sub-TLV: L-bit=3D0, IPv4 address=3D192.3.4.2
>>>>
>>>> 2.5.2 Advertising an LDP LSP using the Binding TLV
>>>>
>>>> Assume that R5 has learned a FEC-label binding via LDP for=
>>>> FEC=3D10.8.8.8/32.  R5 can advertise a locally signif= icant label binding
>>>> for this LSP (with label value=3D5099) using the following= values and
>>>> sub-TLVs in the Binding TLV.
>>>>
>>>> Binding TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, = prefix length=3D32,
>>>> FEC prefix=3D10.8.8.8 SID/Label Sub-TLV: label=3D5099 ERO = Metric sub-TLV:
>>>> metric=3D100
>>>> IPv4 ERO sub-TLV: L-bit=3D1, IPv4 address=3D10.8.8.8
>>>>
>>>> 2.5.3 Advertising a BGP labeled-unicast LSP using the Bind= ing TLV
>>>>
>>>> Assume that R9 has used BGP labeled-unicast to learn a lab= el binding
>>>> for prefix 10.15.15.15/32 with BGP next-hop=3D10.12.12.12.=    R9 can
>>>> advertise a locally significant label binding for this LSP= (with label
>>>> value=3D7099)  using the following values and sub-TLV= s in the Binding
>>>> TLV.
>>>>
>>>> Binding-TLV: F-bit=3D0, M-bit=3D0, weight=3D1, range=3D1, = prefix length=3D32,
>>>> FEC prefix=3D10.15.15.15 SID/Label Sub-TLV: label=3D7099 E= RO Metric
>>>> sub-TLV: metric=3D100
>>>> IPv4 ERO sub-TLV: L-bit=3D1, IPv4 address=3D10.12.12.12 >>>>
>>>> 2.5.4 Advertising a context-id for egress node protection = using the
>>>> Binding TLV
>>>>
>>>> Assume that R22 is configured in the protector role to pro= vide egress
>>>> node protection for R21 using context-id=3D10.0.0.21. = ; R22 can advertise
>>>> the label associated with this context-id (with label valu= e=3D8099) using
>>>> the following values and sub-TLVs in the Binding TLV.
>>>>
>>>> Binding TLV: F-bit=3D0, M-bit=3D1, weight=3D1, range=3D1, = prefix length=3D32,
>>>> FEC prefix=3D10.0.0.21 SID/Label Sub-TLV: label=3D8099
>>>>
>>>> ----------------
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Isis-wg mailing list
>>>> Isis-wg@ietf.org
>>>> = https://www.ietf.org/mailman/listinfo/isis-wg
>> _______________________________________________
>> spring mailing list
>> spring@ietf.org
>> https://w= ww.ietf.org/mailman/listinfo/spring
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.= ietf.org/mailman/listinfo/isis-wg

 --_000_8F6D261188DF40FB70701EB0D7CE7F6A1B0B7F48sp_-- From nobody Mon Aug 4 20:07:26 2014 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 676631B27A8 for ; Mon, 4 Aug 2014 20:07:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 z8u5nQwzo2FR for ; Mon, 4 Aug 2014 20:07:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E17D1B27A7 for ; Mon, 4 Aug 2014 20:07:20 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BKW78041; Tue, 05 Aug 2014 03:07:18 +0000 (GMT) Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Aug 2014 04:07:17 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.204]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Tue, 5 Aug 2014 11:07:13 +0800 From: Xuxiaohu To: "" Thread-Topic: New Version Notification for draft-xu-spring-islands-connection-over-ip-01.txt Thread-Index: AQHPsFjQp/hlKK5iek2BDctF4llHRZvBUsTQ Date: Tue, 5 Aug 2014 03:07:12 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A268C@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/SRMT4wu2gHbQAOxhSDb56Hr1oH0 Subject: [spring] FW: New Version Notification for draft-xu-spring-islands-connection-over-ip-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, 05 Aug 2014 03:07:23 -0000 RllJLg0KDQpCZXN0IHJlZ2FyZHMsDQpYaWFvaHUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiBGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1k cmFmdHNAaWV0Zi5vcmddDQo+IFNlbnQ6IFR1ZXNkYXksIEF1Z3VzdCAwNSwgMjAxNCAxMDo1NiBB TQ0KPiBUbzogVW1hIENodW5kdXJpOyBSb2JlcnQgUmFzenVrOyBTaXZhIFNpdmFiYWxhbjsgWHV4 aWFvaHU7IFNpdmEgU2l2YWJhbGFuOw0KPiBYdXhpYW9odTsgVmljdG9yIExvcGV6YWx2YXJlejsg VmljdG9yIExvcGV6YWx2YXJlejsgVW1hIENodW5kdXJpOyBSb2JlcnQNCj4gUmFzenVrDQo+IFN1 YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4gZHJhZnQteHUtc3ByaW5nLWlz bGFuZHMtY29ubmVjdGlvbi1vdmVyLWlwLTAxLnR4dA0KPiANCj4gDQo+IEEgbmV3IHZlcnNpb24g b2YgSS1ELCBkcmFmdC14dS1zcHJpbmctaXNsYW5kcy1jb25uZWN0aW9uLW92ZXItaXAtMDEudHh0 DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgWGlhb2h1IFh1IGFuZCBwb3N0 ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6CQlkcmFmdC14dS1zcHJpbmct aXNsYW5kcy1jb25uZWN0aW9uLW92ZXItaXANCj4gUmV2aXNpb246CTAxDQo+IFRpdGxlOgkJQ29u bmVjdGluZyBNUExTLVNQUklORyBJc2xhbmRzIG92ZXIgSVAgTmV0d29ya3MNCj4gRG9jdW1lbnQg ZGF0ZToJMjAxNC0wOC0wNA0KPiBHcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KPiBQYWdl czoJCTUNCj4gVVJMOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC14dS1zcHJpbmctaXNsYW5kcy1jb25uZWN0aW9uLW92ZXItaXAtDQo+IDAxLnR4dA0KPiBTdGF0 dXM6DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXh1LXNwcmluZy1p c2xhbmRzLWNvbm5lY3Rpb24tb3Zlci1pcC8NCj4gSHRtbGl6ZWQ6DQo+IGh0dHA6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LXh1LXNwcmluZy1pc2xhbmRzLWNvbm5lY3Rpb24tb3Zlci1pcC0w MQ0KPiBEaWZmOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC14dS1z cHJpbmctaXNsYW5kcy1jb25uZWN0aW9uLW92ZXItaXAtMDENCj4gDQo+IEFic3RyYWN0Og0KPiAg ICBNUExTLVNQUklORyBpcyBhIHNvdXJjZSByb3V0aW5nIHBhcmFkaWdtIGluIHdoaWNoIGEgc2Vu ZGVyIG9mIGENCj4gICAgcGFja2V0IGlzIGFsbG93ZWQgdG8gcGFydGlhbGx5IG9yIGNvbXBsZXRl bHkgc3BlY2lmeSB0aGUgcm91dGUgdGhlDQo+ICAgIHBhY2tldCB0YWtlcyB0aHJvdWdoIHRoZSBu ZXR3b3JrIGJ5IHVzaW5nIHN0YWNrZWQgTVBMUyBsYWJlbHMuICBUaGUNCj4gICAgY3VycmVudCBN UExTLVNSUElORyBhcmNoaXRlY3R1cmUgcmVxdWlyZXMgYW4gZW5kLXRvLWVuZCBNUExTIExhYmVs DQo+ICAgIFN3aXRjaGVkIFBhdGggKExTUCkgYmV0d2VlbiBhbnkgdHdvIE1QTFMtU1BSSU5HLWVu YWJsZWQgcm91dGVycw0KPiAgICAoZS5nLiwgdHdvIGFkamFjZW50IGhvcHMgb2YgYSBnaXZlbiBl eHBsaWNpdCBwYXRoKS4gIEluIG9yZGVyIHRvDQo+ICAgIGVuYWJsZSBNUExTLVNQUklORy1lbmFi bGVkIHJvdXRlcnMgdG8gYmUgZGVwbG95ZWQgZXZlbiB3aGVuIHRoZXJlIGFyZQ0KPiAgICBub24t TVBMUyByb3V0ZXJzIGFsb25nIHRoZSBwYXRoIGJldHdlZW4gdHdvIE1QTFMtU1BSSU5HLWVuYWJs ZWQNCj4gICAgcm91dGVycywgaXQgaXMgZGVzaXJhYmxlIHRvIGhhdmUgYW4gYWx0ZXJuYXRpdmUs IHdoaWNoIGFsbG93cyB0aGUgdXNlDQo+ICAgIG9mIElQLWJhc2VkIHR1bm5lbHMgKGUuZy4sIEdS RSB0dW5uZWxzKSB0byBjb25uZWN0IHR3byBNUExTLVNQUklORy0NCj4gICAgZW5hYmxlZCByb3V0 ZXJzLiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBtZWNoYW5pc20gZm9yIHN1Y2ggdXNhZ2Uu DQo+IA0KPiANCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxl IG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+IHVudGlsIHRoZSBodG1s aXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+ IA0KPiBUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Mon Aug 4 20:58:42 2014 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 2BE701B280E for ; Mon, 4 Aug 2014 20:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.602 X-Spam-Level: X-Spam-Status: No, score=-3.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 zVxinlygs2st for ; Mon, 4 Aug 2014 20:58:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4738C1B2807 for ; Mon, 4 Aug 2014 20:58:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BHX41182; Tue, 05 Aug 2014 03:58:37 +0000 (GMT) Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 5 Aug 2014 04:58:36 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.204]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Tue, 5 Aug 2014 11:58:32 +0800 From: Xuxiaohu To: "" Thread-Topic: Request WG adoption polling//FW: [spring] The rationale of draft-xu-spring-islands-connection-over-ip Thread-Index: AQHPsGGFlRyeeGiueUKQvGMC5cN8Xg== Date: Tue, 5 Aug 2014 03:58:31 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082A26D8@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/CzFDFu8Y80P-s-3jkPHzfVzM5mU Subject: [spring] Request WG adoption polling//FW: The rationale of draft-xu-spring-islands-connection-over-ip 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, 05 Aug 2014 03:58:42 -0000 SGkgY28tY2hhaXJzLA0KDQpXZSBoYXZlIGFkZHJlc3NlZCBhbGwgY29tbWVudHMgcmVjZWl2ZWQg c28gZmFyIGluIHRoZSBmb2xsb3dpbmcgcmV2aXNpb24gKGh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXh1LXNwcmluZy1pc2xhbmRzLWNvbm5lY3Rpb24tb3Zlci1pcC0wMSkuIE5vdGUg dGhhdCBob3cgdG8gZHluYW1pY2FsbHkgb2J0YWluIHRoZSBlbmNhcHN1bGF0aW9uIGNhcGFiaWxp dGllcyBpcyBkZWZpbmVkIGluIHNlcGFyYXRlIGRvY3MgKGUuZy4sIGh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LXh1LWlzaXMtZW5jYXBzdWxhdGlvbi1jYXAtMDApIA0KDQpXZSBjby1h dXRob3JzIGJlbGlldmUgdGhlIGN1cnJlbnQgdmVyc2lvbiBpcyByZWFkeSBmb3IgV0cgYWRvcHRp b24uDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odShvbiBiZWhhbGYgb2YgYWxsIGNvLWF1dGhvcnMp DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBycmFzenVrQGdtYWlsLmNvbSBb bWFpbHRvOnJyYXN6dWtAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgUm9iZXJ0IFJhc3p1aw0KU2Vu dDogRnJpZGF5LCBKdWx5IDA0LCAyMDE0IDU6MjkgUE0NClRvOiBYdXhpYW9odQ0KQ2M6IDxzcHJp bmdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NwcmluZ10gVGhlIHJhdGlvbmFsZSBvZiBkcmFm dC14dS1zcHJpbmctaXNsYW5kcy1jb25uZWN0aW9uLW92ZXItaXANCg0KSGkgWHUsDQoNCldlIGRp c2N1c3NlZCB0aGlzIHdvcmsgYmVmb3JlLCBob3dldmVyIEkgaGF2ZSBhIG5ldyBxdWVzdGlvbiAu Li4NCg0KSXQgaXMgYW4gaW5mb3JtYXRpb25hbCBkcmFmdCBzbyB5b3UgcmVsYXkgb24gcHJvcGVy IGNvbmZpZ3VyYXRpb24gb2YgUlMgbm9kZXMgaW4gdGhlIGlzbGFuZHMuDQoNCk5vdGUgdGhhdCB0 b2RheSB5b3UgbWF5IGhhdmUgb3V0IG9mIHRoZSBib3ggU1Igbm9kZSBzdXBwb3J0aW5nIElQdjQs DQpJUHY2IChzYXkgd2l0aG91dCBTUikgKyBNUExTLiBTbyB5b3UgbXVzdCBzZWxlY3QgeW91ciBv cGVyYXRpb25hbCBkZWZhdWx0IGVuY2Fwc3VsYXRpb24gYW5kIHZlcnkgbGlrZWx5IHN1Y2ggZW5j YXBzdWxhdGlvbiB3aWxsIGRpZmZlciBwZXIgbmV4dCBTUiBkZXN0aW5hdGlvbiAhDQoNCkkgdGhl cmVmb3IgZmluZCBpdCBub3QgcmVhbGx5IHByYWN0aWNhbCB0byByZWNvbW1lbmQgbWFudWFsL2ky cnMveG1sIGNvbmZpZ3VyYXRpb24gYW5kIGNob2ljZSBvZiBlbmNhcHN1bGF0aW9uIG9uIGEgcGVy IFNSIG5vZGUgYmFzaXMuDQoNCkkgd291bGQgdGhlcmVmb3IgYWR2aXNlIGlmIHRoZXJlIHdvdWxk IGJlIGFyY2hpdGVjdHVyYWwgY29uc2Vuc3VzIHRvIGdvIGZvcndhcmQgd2l0aCB0aGUgcHJvcG9z ZWQgaW4gdGhlIGRyYWZ0IGlkZWEgdG8gdHVybiBpdCBpbnRvIHN0YW5kYXJkcyB0cmFjayBhbmQg YWRkIGEgZmxhZyBhbmQgZW5jYXAgaW5mbyBpbiBTUiBhZHZlcnRpc2VtZW50IGl0c2VsZiBpbmRp Y2F0aW5nIHRoYXQgZ2l2ZW4gU1Igbm9kZSBtYXkgYmUgcmVhY2hhYmxlIHNheSB2aWEgR1JFLA0K TDJUUHYzIG9yIFZYTEFOIGVuY2Fwcy4NCg0KVGhhdCB3YXkgeW91ciBvYmplY3RpdmUgaXMgYWNj b21wbGlzaGVkIHZpYSBmdWxsIHByb3RvY29sIGF1dG9tYXRpb24gd2l0aCBtaW5pbWFsIG5lZWQg Zm9yIGFueSBwZXIgU1Igc3JjL2RzdCBub2RlIG1hbnVhbCBjb25maWcuDQoNCkJlc3QsDQpSLg0K DQoNCg0KDQoNCg0KDQoNCg0KDQoNCk9uIEZyaSwgSnVsIDQsIDIwMTQgYXQgNToxMiBBTSwgWHV4 aWFvaHUgPHh1eGlhb2h1QGh1YXdlaS5jb20+IHdyb3RlOg0KPiBIaSBhbGwsDQo+DQo+IFRoaXMg ZHJhZnQgKGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXh1LXNwcmluZy1pc2xhbmRz LWNvbm5lY3Rpb24tb3Zlci1pcC0wMCkgZGVzY3JpYmVzIGEgdXNlIGNhc2UgYWJvdXQgaW50ZXJj b25uZWN0aW5nIHNwcmluZyBpc2xhbmRzIG92ZXIgSVAgbmV0d29ya3MuIFRoZSByYXRpb25hbGUg Zm9yIHRoaXMgZHJhZnQgaXMgYXMgZm9sbG93czoNCj4NCj4gU3VwcG9zZSBMU1IgQSBhbmQgTFNS IEIgYXJlIHNlcGFyYXRlZCBieSBhbiBJUCBuZXR3b3JrLiBBc3N1bWUgTFNSIEEgcmVjZWl2ZXMg ZnJvbSBMU1IgQiBhIGxhYmVsIGJpbmRpbmcgTCBmb3IgYSBnaXZlbiBGRUMgKGUuZy4sIG9uZSBv ZiBMU1IgQidzIGxvb3BiYWNrIGFkZHJlc3NlcykgdmlhIFQtTERQIG9yIEwtQkdQLCB3aGVuIExT UiBBIHdhbnRzIHRvIGZvcndhcmQgYSBNUExTIHBhY2tldCB0YXJnZXRlZCBmb3IgdGhhdCBGRUMs IGl0IGNvdWxkIGZvcndhcmQgdGhhdCBNUExTIHBhY2tldCB0aHJvdWdoIGFuIElQLWJhc2VkIHR1 bm5lbCB0b3dhcmRzIExTUiBCLiBJbiBjb250cmFzdCwgaWYgTFNSIEEgcmVjZWl2ZXMgdGhlIGFi b3ZlIGxhYmVsIGJpbmRpbmcgb3JpZ2luYXRlZCBieSBMU1IgQiB2aWEgSVMtSVMgb3IgT1NQRiwg aXQgY291bGQgYmUgbG9va2VkIGFzIGlmIHRoaXMgbGFiZWwgYmluZGluZyB3YXMgbGVhcm50IGZy b20gYSByZW1vdGUgQkdQIG9yIExEUCBwZWVyLiBBcyBzdWNoLCBMU1IgQSBjb3VsZCBmb3J3YXJk IHRoZSBNUExTIHBhY2tldCB0YXJnZXRlZCBmb3IgdGhhdCBGRUMgb3ZlciBhbiBJUC1iYXNlZCB0 dW5uZWwgdG93YXJkcyBMU1IgQiBhcyB3ZWxsLg0KPg0KPiBJbiBmYWN0LCBvbmUgb2YgdGhlIGNs YWltZWQgYWR2YW50YWdlcyBvZiBJUHY2LVNSIGlzIHRoYXQgaXQgZG9lc24ndCByZXF1aXJlIHRv IHVwZ3JhZGUgYWxsIHJvdXRlcnMgaW4gdGhlIG5ldHdvcmtzLiBXaXRoIHRoZSBhYm92ZSBhcHBy b2FjaCwgd2UgY2FuIGFjaGlldmUgdGhlIHNhbWUgZWZmZWN0IGluIHRoZSBNUExTLVNSLg0KPg0K PiBCZXN0IHJlZ2FyZHMsDQo+IFhpYW9odQ0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBzcHJpbmcgbWFpbGluZyBsaXN0DQo+IHNwcmluZ0Bp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NwcmluZw0K From nobody Thu Aug 7 07:58:05 2014 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 520BE1B2ADB for ; Thu, 7 Aug 2014 07:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, 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 ivu8Hroqe09i for ; Thu, 7 Aug 2014 07:57:50 -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 283D21B2BD8 for ; Thu, 7 Aug 2014 07:57:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1282; q=dns/txt; s=iport; t=1407423465; x=1408633065; h=from:to:subject:date:message-id:mime-version; bh=mWeaJuCct5bJUIpQYKlnDekciDt4JMb2MZrTOELqJFw=; b=Pr+Yu5OGMhwEwZlpo9aK87OQCib3Qn8/fB+Qi08iTMEnlc49pHQTbevr CfKNuDEr8PqHXIY6wQ6ZjALQCMW+J0ZufQmqh81c5tz3n31IuJUjycuav IdDoNSowcc8Ol+ZjAQOyKETXYtao92PAH3uzI9iq5ONMtegnmtLo9+Gv+ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvAlAE+T41OtJA2E/2dsb2JhbABagkdGUlgDhA/GcIFTiFoWd4N6EIELAQsBdCcEHIg5DZ4wpWkXlB4FjwCNG5Rwg1eCMg X-IronPort-AV: E=Sophos; i="5.01,818,1400025600"; d="scan'208,217"; a="67324465" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-2.cisco.com with ESMTP; 07 Aug 2014 14:57:45 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s77Eviie027138 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 7 Aug 2014 14:57:44 GMT Received: from xmb-aln-x15.cisco.com ([169.254.9.192]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Thu, 7 Aug 2014 09:57:44 -0500 From: "Alvaro Retana (aretana)" To: "spring@ietf.org" Thread-Topic: spring Minutes IETF 90 Thread-Index: AQHPsk/x2dzxlLIOM0OfrKpRYI6D8w== Date: Thu, 7 Aug 2014 14:57:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.15.3] Content-Type: multipart/alternative; boundary="_000_D0090C2065C56aretanaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/O7Oks_PS6Kp9Emo3ghA2nbLIeyU Subject: [spring] spring Minutes IETF 90 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, 07 Aug 2014 14:57:57 -0000 --_000_D0090C2065C56aretanaciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi! I just posted notes from the WG meeting in Toronto. http://www.ietf.org/proceedings/90/minutes/minutes-90-spring Thanks to Jon Mitchell for stepping up and taking great notes. Alvaro. --_000_D0090C2065C56aretanaciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi!

I just posted notes from the WG meeting in Toronto.


Thanks to Jon Mitchell for stepping up and taking great notes.

Alvaro.
--_000_D0090C2065C56aretanaciscocom_-- From nobody Thu Aug 7 09:53:49 2014 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 BA36C1B2E75 for ; Thu, 7 Aug 2014 09:53:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, 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 mEfPfSUlmQhm for ; Thu, 7 Aug 2014 09:53:46 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEC6A1B2E58 for ; Thu, 7 Aug 2014 09:53:45 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id q58so4497311wes.32 for ; Thu, 07 Aug 2014 09:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=fNaL3V2CbtpdF/8cn5LtiQvTbfxrC33x2Yym9SimNLw=; b=kIQz6Karc8MexLmZQhNCf87DT7ibr1q8WTO4aaFI4BJ1e7tiPlhIwcytKLo3caEUT8 ksFaA0J4n9pSqqKB0cNig6v7uDoTJ3dikXdZGHDVApru+D3FZRj9Zxs3wAcp8gW4K+7i IyYmmkXhxbO4K3+hccupcBeF6IQEi+ySjwXzHLhudfjbI3OS7bteKDwbYFOVNtQqdmBE T5tNFIZVmgf4ojo0/BKWXM5hYupIFAY8v4MST0hBZ+7eW6NT2t9wpkYpiB6+zfVeGJFW HFCqe92s4P2MEPDWbBdMAzEAQUXjjo6LpGaUPf5B0eC2D/JIyv+8+3OBlai9rw8PYwph EHvw== MIME-Version: 1.0 X-Received: by 10.181.9.104 with SMTP id dr8mr25298417wid.26.1407430424259; Thu, 07 Aug 2014 09:53:44 -0700 (PDT) Received: by 10.217.148.10 with HTTP; Thu, 7 Aug 2014 09:53:44 -0700 (PDT) Date: Thu, 7 Aug 2014 12:53:44 -0400 Message-ID: From: "B.Khasnabish@ieee.org" To: "spring@ietf.org" Content-Type: multipart/alternative; boundary=001a1134d84c7bf49805000ceedc Archived-At: http://mailarchive.ietf.org/arch/msg/spring/KyMglmBdJJLKPW63l1oP6qI8-a4 Cc: "Cankaya, Hakki" , "hu.fangwei@zte.com.cn" Subject: [spring] Fwd: SPRING OpenFlow Interworking Use Cases draft for your review and comments. Thanks. 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, 07 Aug 2014 16:53:47 -0000 --001a1134d84c7bf49805000ceedc Content-Type: text/plain; charset=UTF-8 FYI ..we just published an early version of the SPRING OpenFlow Interworking Use Cases draft for your review and comments. Thanks. Best. Mr. Hu, Bhumip, and Hakki +++++++++++++++++++++++++++++++++++ I-D Action: draft-khc-spring-openflow-interworking-use-cases-00.txt ------------------------------ - *To*: i-d-announce at ietf.org - *Subject*: I-D Action: draft-khc-spring-openflow-interworking-use-cases-00.txt - *From*: internet-drafts at ietf.org - *Date*: Thu, 07 Aug 2014 09:38:09 -0700 - *Archived-at*: http://mailarchive.ietf.org/arch/msg/i-d-announce/4sp7xHhEbyvlDqE-Hbj6aXgQ4IM - *Auto-submitted*: auto-generated - *Delivered-to*: i-d-announce at ietfa.amsl.com - *List-archive*: - *List-help*: > - *List-id*: Internet Draft Announcements only - *List-post*: > - *List-subscribe*: , > - *List-unsubscribe*: , > - *Reply-to*: internet-drafts at ietf.org ------------------------------ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : SPRING OpenFlow Interworking Use Cases Authors : Fangwei Hu Bhumip Khasnabish Hakki Cankaya Filename : draft-khc-spring-openflow-interworking-use-cases-00.txt Pages : 8 Date : 2014-08-07 Abstract: This draft discusses interworking (IW) of OpenFlow and Segment routing. Several possible scenarios are introduced in this document. We believe that such discussion and research are helpful for both deployment/implementation and wider acceptance of the segment routing technology. The IETF datatracker status page for this draft is:https://datatracker.ietf.org/doc/draft-khc-spring-openflow-interworking-use-cases/ There's also a htmlized version available at:http://tools.ietf.org/html/draft-khc-spring-openflow-interworking-use-cases-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/ --001a1134d84c7bf49805000ceedc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI ..we just published an early version of the SPRI= NG OpenFlow
Interworking Use Cases draft for your review and comments.
=C2= =A0
Thanks.
=C2=A0
Best.
=C2=A0
Mr. Hu, Bhumip, and Hakki=C2=A0
=C2=A0
++++++++++++++= +++++++++++++++++++++
=C2=A0

I-D Action: draft-khc-spring-openflow-interworking-use-cases-= 00.txt

A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.


        Title           : SPRING OpenFlow Interworking Use Cases
        Authors         : Fangwei Hu
                          Bhumip Khasnabish
                          Hakki Cankaya
	Filename        : draft-khc-spring-openflow-interworking-use-cases-00.txt
	Pages           : 8
	Date            : 2014-08-07

Abstract:
   This draft discusses interworking (IW) of OpenFlow and Segment
   routing.  Several possible scenarios are introduced in this document.
   We believe that such discussion and research are helpful for both
   deployment/implementation and wider acceptance of the segment routing
   technology.


The IETF datatracker status page for this draft is:
https://datatr=
acker.ietf.org/doc/draft-khc-spring-openflow-interworking-use-cases/=


There's also a htmlized version available at:
http://tools.ietf.=
org/html/draft-khc-spring-openflow-interworking-use-cases-00


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
--001a1134d84c7bf49805000ceedc-- From nobody Sun Aug 24 22:15:36 2014 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 DD6FC1A8A16; Sun, 24 Aug 2014 22:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.893 X-Spam-Level: X-Spam-Status: No, score=-100.893 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, LOCALPART_IN_SUBJECT=1.107, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 FcHkN6Hy9UV1; Sun, 24 Aug 2014 22:14:51 -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 341401A8A15; Sun, 24 Aug 2014 22:14:51 -0700 (PDT) X-AuditID: c618062d-f79206d0000014d2-05-53fa71a3aa42 Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 52.D5.05330.3A17AF35; Mon, 25 Aug 2014 01:13:40 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Mon, 25 Aug 2014 01:14:48 -0400 From: Gregory Mirsky To: "'draft-tissa-netmod-oam@tools.ietf.org'" Thread-Topic: draft-tissa-netmod-oam Thread-Index: Ac+tKouGZjiF/7GjRZGwGunQsgwS9A== Date: Mon, 25 Aug 2014 05:14:47 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B82567E@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.11] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B82567Eeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLLMWRmVeSWpSXmKPExsUyuXSPn+6Swl/BBt8a+Sz2bnvJavH42yF2 i1tLV7JazL/YyGrxdL6kxec/2xgtjl/4zWgxb9cHJgcOjyVLfjJ5fLn8mS2AKYrLJiU1J7Ms tUjfLoEr4/yZ1ewFN6oqdrT/YGlg3JTVxcjJISFgIvHgxG0mCFtM4sK99WwgtpDAUUaJX4/0 IezljBJbvumA2GwCRhIvNvawg9giAuESK+7/ALK5OJgFGpkk5j5+BdYsLKAgsfndbxaIIlWJ /Y3/mSFsPYn38w+CxVmA4lc6JoIN4hXwlZjWfAaslxHoiO+n1oAdxCwgLnHryXyo4wQkluw5 zwxhi0q8fPyPFcJWkvj4ez47RH2+xJUdp1kgZgpKnJz5hGUCo/AsJKNmISmbhaQMIq4jsWD3 JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2LkKC1OLctNNzLYxAiMr2MSbLo7GPe8tDzEKMDBqMTD u2D7z2Ah1sSy4srcQ4zSHCxK4ryzaucFCwmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamBk2JL7 oOnR171K7X9yJ/8N3Gi1VcxsvsNGufZ+i3lznpjezzKb6+DSW3XFP3ey28Rp7U0+1e/WlL2N 4t280WCqyoLXKxKfak7dan3F5eXBuX1f37vMrzaasdZdfjHjTTV2Kft/r8yuH+linHP6FN83 HfN7B7o3KpqlB1jWZUQdb45PPTBlUd4aJZbijERDLeai4kQAvcFrVJACAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/spring/31qoLtekU3MMpU1h1lI5LYwrea4 Cc: "l2vpn@ietf.org" , "mpls@ietf.org" , "spring@ietf.org" , "time@ietf.org" , "'netmod@ietf.org'" , "nvo3@ietf.org" , "rtg-bfd@ietf.org" Subject: [spring] draft-tissa-netmod-oam 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, 25 Aug 2014 05:14:54 -0000 X-List-Received-Date: Mon, 25 Aug 2014 05:14:54 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B82567Eeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et.al, please kindly consider my comments and questions to this document: * Introduction o "... it is a reasonable choice to develop the unified OAM framework ba= sed on those (CFM) concepts." I agree that for packet switching connection-= oriented networks that are based on G.800 architecture CFM, but more so Y.1= 731, provides shared concepts. I think that the same cannot be said for con= nectionless packet switching networks. Thus extending CFM model onto arbitr= ary networks without consideration whether these are connection-oriented or= connectionless is very questionable approach, IMO; o "...CFM, it is a reasonable choice to develop the unified OAM framework= based on those concepts" IP OAM is not based on Ethernet Service OAM model= or principles but, IMO, OAM of overlay networks more closer resemble IP OA= M as these networks are connectionless in their architecture; o "The YANG model presented in this document is the base model and suppor= ts IP Ping and Traceroute." If only these and similar OAM tools, e.g. LSP p= ing, Loopback/Linktrace, are in scope of the document, then, I believe, the= title may say something like "YANG model of on-demand OAM tool to detect a= nd localize Loss of Continuity defect". Referring to ping/traceroute as "ge= neric OAM" comes as stretch too far; o "...initiate a performance monitoring session can do so in the same ma= nner regardless of the underlying protocol or technology" I'd point to work= of LMAP WG on informational model of performance measurements in large-sca= le access networks, work of ITU-T's SG15, MEF. Perhaps sentence can be stop= ped after "... or a Traceroute". o "In this document we define the YANG model for Generic OAM" Can you pro= vide definition or reference to the definition of the "Generic OAM"? It is = challenging to validate informational model of something that not been suff= iciently defined. * Section 3 o "This allows users to traverse between OAM of different technologies at= ease through a uniform API set." Usually relationships between OAM layers = referred and viewed as OAM interworking. There are several examples of IETF= addressing aspects of OAM interworking. I think that interworking includes= not only scenarios of nested OAM layers but peering layers and thus is bro= ader than introduced in the document "nested OAM". o Figure 1 depicts OAM of both connection-oriented and connectionless net= works. What you see common, generic in respective OAM of these networks? * Section 4 o "In IP, the MA can be per IP Subnet ..." As there's no definition of MA= in IP, is this the definition or one of examples. Can MA in IP network be = other than per IP Subnet? o "Under each MA, there can be two or more MEPs (Maintenance End Points)"= Firstly, since you adopt MA-centric terminology, MEP stands for Maintenanc= e Association End Point. Secondly, in some OAM models Down and Up MEP being= distinguished. Would your model consider that? As there's no definition of= MEP for several networks you've listed, e.g. IP, how the YANG model will a= bstract something that is not defined? And thirdly, how and where MIPs are = located in IP OAM? Thank you for your consideration of my notes and looking forward to the int= eresting discussion. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B82567Eeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Authors, et.al,

please kindly consider my comments and questions to = this document:

·         Introduction

o    “… it is a reasonable choi= ce to develop the unified OAM framework based on those (CFM) concepts.̶= 1; I agree that for packet switching connection-oriented networks that are = based on G.800 architecture CFM, but more so Y.1731, provides shared concepts. I think that the same cannot be said for connectionless p= acket switching networks. Thus extending CFM model onto arbitrary networks = without consideration whether these are connection-oriented or connectionle= ss is very questionable approach, IMO;

o   “…CFM, it is a reasonable choice= to develop the unified OAM framework based on those concepts” IP OAM= is not based on Ethernet Service OAM model or principles but, IMO, OAM of = overlay networks more closer resemble IP OAM as these networks are connectionless in their architecture;

o   “The YANG model presented in this docu= ment is the base model and supports IP Ping and Traceroute.” If only = these and similar OAM tools, e.g. LSP ping, Loopback/Linktrace, are in scop= e of the document, then, I believe, the title may say something like “YANG model of on-demand OAM tool to detect a= nd localize Loss of Continuity defect”. Referring to ping/traceroute = as “generic OAM” comes as stretch too far;

o    “…initiate a performance m= onitoring session can do so in the same manner regardless of the underlying= protocol or technology” I’d point to work of LMAP WG on inform= ational model of performance measurements in large-scale access networks, work of ITU-T’s SG15, MEF. Perhaps sentence can be stopped= after “… or a Traceroute”.

o   “In this document we define the YANG m= odel for Generic OAM” Can you provide definition or reference to the = definition of the “Generic OAM”? It is challenging to validate = informational model of something that not been sufficiently defined.

·         Section 3

o   “This allows users to traverse between= OAM of different technologies at ease through a uniform API set.” Us= ually relationships between OAM layers referred and viewed as OAM interwork= ing. There are several examples of IETF addressing aspects of OAM interworking. I think that interworking includes not only s= cenarios of nested OAM layers but peering layers and thus is broader than i= ntroduced in the document “nested OAM”.

o   Figure 1 depicts OAM of both connection-orie= nted and connectionless networks. What you see common, generic in respectiv= e OAM of these networks?

·         Section 4

o   “In IP, the MA can be per IP Subnet &#= 8230;” As there’s no definition of MA in IP, is this the defini= tion or one of examples. Can MA in IP network be other than per IP Subnet?<= o:p>

o   “Under each MA, there can be two or mo= re MEPs (Maintenance End Points)” Firstly, since you adopt MA-centric= terminology, MEP stands for Maintenance Association End Point. Secondly, i= n some OAM models Down and Up MEP being distinguished. Would your model consider that? As there’s no definition of MEP for = several networks you’ve listed, e.g. IP, how the YANG model will abst= ract something that is not defined? And thirdly, how and where MIPs are loc= ated in IP OAM?

 

Thank you for your consideration of my notes and loo= king forward to the interesting discussion.

 

Regards,

    =     Greg

--_000_7347100B5761DC41A166AC17F22DF1121B82567Eeusaamb103erics_-- From nobody Thu Aug 28 08:31:19 2014 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 E2D9C1A030A; Thu, 28 Aug 2014 08:24:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.168 X-Spam-Level: X-Spam-Status: No, score=-13.168 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, 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 BDtdGBpeqD9G; Thu, 28 Aug 2014 08:24:33 -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 4C96D1A06FC; Thu, 28 Aug 2014 08:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29477; q=dns/txt; s=iport; t=1409239473; x=1410449073; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UUaWlJnTkIdT2jpeN2ooo6VAdPLfWpG3/ZUrZmZ7C7o=; b=haYGHHnGj4B1Y2Tx04CiPsMf2sKsQxzuhGAmkkvXrElFO6Ra94bOS4kG Ixc5ncHRZAYdoLggiZwDsm7CGKbmDBFuh2tpXZUkyqR0ctCz4DaFZjEsQ SlLkPv3Szn64ip29nnzxCJdyT1A+W37xaLUC3Jhge7MjN4QaQQTvbgU1G 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FACFJ/1OtJV2R/2dsb2JhbABbgkdGU1cE03YBgRkWd4QDAQEBBC05DAcQAgEIEQEDAQELFgcHMhQDBggBAQQBDQUIE4gnv0oXjnQnMQYBgy+BHQWRL6BIg15sgQYCHgYcgQcBAQE X-IronPort-AV: E=Sophos;i="5.04,418,1406592000"; d="scan'208,217";a="351062464" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP; 28 Aug 2014 15:24:15 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s7SFOF8Q007812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 28 Aug 2014 15:24:15 GMT Received: from xmb-rcd-x08.cisco.com ([169.254.8.110]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0195.001; Thu, 28 Aug 2014 10:24:15 -0500 From: "Tissa Senevirathne (tsenevir)" To: Gregory Mirsky , "'draft-tissa-netmod-oam@tools.ietf.org'" Thread-Topic: draft-tissa-netmod-oam Thread-Index: Ac+tKouGZjiF/7GjRZGwGunQsgwS9AVplJ1w Date: Thu, 28 Aug 2014 15:24:14 +0000 Message-ID: References: <7347100B5761DC41A166AC17F22DF1121B82567E@eusaamb103.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B82567E@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.89.14.1] Content-Type: multipart/alternative; boundary="_000_FBEA3E19AA24F847BA3AE74E2FE193562EF118C6xmbrcdx08ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/spring/stddJUorL6g1W8pjDQhxKfDdLpw X-Mailman-Approved-At: Thu, 28 Aug 2014 08:31:05 -0700 Cc: "l2vpn@ietf.org" , "mpls@ietf.org" , "spring@ietf.org" , "time@ietf.org" , "'netmod@ietf.org'" , "nvo3@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: [spring] draft-tissa-netmod-oam 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, 28 Aug 2014 15:24:39 -0000 --_000_FBEA3E19AA24F847BA3AE74E2FE193562EF118C6xmbrcdx08ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Greg Before answering the specific questions below, would like explain few aspe= cts related to the extended CFM model used here. CFM originally was design= ed exclusively for Ethernet. As part of the TRILL OAM work we decoupled CFM= model from Ethernet based addressing and made it addressing independent. T= hat is the CFM model that is referred here. CFM defines a complete fault model that include fault domains, Test point, = Layering etc. Strict definition of such is needed to develop a complete OAM= solution regardless of the underline technology. CFM does a fantastic job = in accomplishing that and AFIK there is no other model. We are leveraging t= hat model. The word generic OAM is utilized here to indicate that the model can be app= lied regardless of the underlying technology. YANG model is not a one-one copy of CFM YANG defined in MEF. Rather it is d= efined with address independent and extensibility in mind. With the above in mind, specific answers in-line: From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Sunday, August 24, 2014 10:15 PM To: 'draft-tissa-netmod-oam@tools.ietf.org' Cc: l2vpn@ietf.org; mpls@ietf.org; spring@ietf.org; time@ietf.org; 'netmod@= ietf.org'; nvo3@ietf.org; rtg-bfd@ietf.org Subject: draft-tissa-netmod-oam Dear Authors, et.al, please kindly consider my comments and questions to this document: * Introduction o "... it is a reasonable choice to develop the unified OAM framework ba= sed on those (CFM) concepts." I agree that for packet switching connection-= oriented networks that are based on G.800 architecture CFM, but more so Y.1= 731, provides shared concepts. I think that the same cannot be said for con= nectionless packet switching networks. Thus extending CFM model onto arbitr= ary networks without consideration whether these are connection-oriented or= connectionless is very questionable approach, IMO; [Answer] As stated above it is the OAM Model that is leveraged here. Regard= less of connection oriented or not the model on Fault domains, Test points = etc is valid. In theory connection oriented can be broken in to connection establishment = and data forwarding. With that in mind, one can define Fault domain and tes= t points. Followed by definition of the Fault identifications tools accordi= ngly. Do you have a preferred OAM tool for fault verification/isolation and loss= and performance monitoring for connection oriented connectuons ?. If so wo= uld like to review and map to the model. o "...CFM, it is a reasonable choice to develop the unified OAM framework= based on those concepts" IP OAM is not based on Ethernet Service OAM model= or principles but, IMO, OAM of overlay networks more closer resemble IP OA= M as these networks are connectionless in their architecture; [Answer] Please see the answer above and extended CFM model. It is the mod= el that is presented here, regardless of the connectioness, OAM tools need= fault domains and fault boundaries. Addidtionally as stated in the explana= tion above, there is nothing Ethernet in CFM, once the addressing is decoup= led. o "The YANG model presented in this document is the base model and suppor= ts IP Ping and Traceroute." If only these and similar OAM tools, e.g. LSP p= ing, Loopback/Linktrace, are in scope of the document, then, I believe, the= title may say something like "YANG model of on-demand OAM tool to detect a= nd localize Loss of Continuity defect". Referring to ping/traceroute as "ge= neric OAM" comes as stretch too far; [Answer] I think there is a miss understanding this model is not limited to= Ping and Trace route. Ping and traceroute are only examples to get the wor= k stared and discussion going. As we go along other tools will be mapped to= the model. o "...initiate a performance monitoring session can do so in the same ma= nner regardless of the underlying protocol or technology" I'd point to work= of LMAP WG on informational model of performance measurements in large-sca= le access networks, work of ITU-T's SG15, MEF. Perhaps sentence can be stop= ped after "... or a Traceroute". [Answer] I did not fully understand your point. o "In this document we define the YANG model for Generic OAM" Can you pro= vide definition or reference to the definition of the "Generic OAM"? It is = challenging to validate informational model of something that not been suff= iciently defined. [Answer] As explained earlier terminology generic OAM is used to indicate = that the presented OAM model can be applied independent of the underlying t= echnology. In section 1, we have stated the following: "..In this document,= we take the [8021Q] CFM model and extend it to a technology independent fr= amework and build the corresponding YANG model accordingly. The YANG model = presented in this document is the base model and supports IP Ping and Trace= route. The generic OAM YANG model is designed such that it can be extended = to cover various technologies. Technology dependent nodes and RPC commands = are defined in technology specific YANG models, which use and extend the ba= se model defined here. .... " * Section 3 o "This allows users to traverse between OAM of different technologies at= ease through a uniform API set." Usually relationships between OAM layers = referred and viewed as OAM interworking. There are several examples of IETF= addressing aspects of OAM interworking. I think that interworking includes= not only scenarios of nested OAM layers but peering layers and thus is bro= ader than introduced in the document "nested OAM". [Answer] Can you please provide some example here, I am not quite clear. Guessing from the word peering, if we are referring to cascaded sections of= different technologies such as IP Cloud, MPLS cloud and another IP cloud. = Then the model presented here is the answer. You can have an end end OAM se= ssion at a higher MD-Level. Each of the clouds below can have separate OAM = at a lower MD-Level. These can be utilized for fault isolation. o Figure 1 depicts OAM of both connection-oriented and connectionless net= works. What you see common, generic in respective OAM of these networks? [Answer] Please see the answers above. * Section 4 o "In IP, the MA can be per IP Subnet ..." As there's no definition of MA= in IP, is this the definition or one of examples. Can MA in IP network be = other than per IP Subnet? [Answer] It is ".. can be", so it meant to be an example and other possibil= ities are not ruled out and model does not assume any such limitation. o "Under each MA, there can be two or more MEPs (Maintenance End Points)"= Firstly, since you adopt MA-centric terminology, MEP stands for Maintenanc= e Association End Point. Secondly, in some OAM models Down and Up MEP being= distinguished. Would your model consider that? As there's no definition of= MEP for several networks you've listed, e.g. IP, how the YANG model will a= bstract something that is not defined? And thirdly, how and where MIPs are = located in IP OAM? [Answer] Yes model accept both UP/Down. One cannot say for IP there is no MEP. MEP is a functional abstraction of a= test point that generate and respond to OAM messages. In that regard IP de= vices today have an implicit MEP at the CPU. The model allow to provide mor= e semantics to the MEP and allow to create UP/Down per interface or other s= cope, hence providing more granularity in fault isolation/verification and = monitoring. Thank you for your consideration of my notes and looking forward to the int= eresting discussion. Thank you for spending time to review and comment. We are updating the next= version with comments received so far and specifically during IETF in Cana= da. We are more than happy enhance where applicable or need more clarity. Regards, Greg --_000_FBEA3E19AA24F847BA3AE74E2FE193562EF118C6xmbrcdx08ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Greg=

 

Before answering the s= pecific questions below,  would like explain few aspects related to th= e extended CFM model used here. CFM  originally was designed exclusive= ly for Ethernet. As part of the TRILL OAM work we decoupled CFM model from Ethernet based addressing and made it addressi= ng independent. That is the CFM model that is referred here.

 

CFM defines a complete= fault model that include fault domains, Test point, Layering etc. Strict d= efinition of such is needed to develop a complete OAM solution regardless o= f the underline technology. CFM does a fantastic job in accomplishing that and AFIK there is no other model. We= are leveraging that model.

 

The word generic OAM i= s utilized here to indicate that the model can be applied regardless of the= underlying technology.

 

YANG model is not a on= e-one copy of CFM YANG defined in MEF. Rather it is defined with address in= dependent and extensibility in mind.

 

With the above in mind= , specific answers in-line:

 

From: L2vpn [m= ailto:l2vpn-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Sunday, August 24, 2014 10:15 PM
To: 'draft-tissa-netmod-oam@tools.ietf.org'
Cc: l2vpn@ietf.org; mpls@ietf.org; spring@ietf.org; time@ietf.org; '= netmod@ietf.org'; nvo3@ietf.org; rtg-bfd@ietf.org
Subject: draft-tissa-netmod-oam

 

Dear Authors, et.al,

please kindly consider my comments and questions to = this document:

·         Introduction

o    “… it is a reasonable choi= ce to develop the unified OAM framework based on those (CFM) concepts.̶= 1; I agree that for packet switching connection-oriented networks that are = based on G.800 architecture CFM, but more so Y.1731, provides shared concepts. I think that the same cannot be said for connectionless p= acket switching networks. Thus extending CFM model onto arbitrary networks = without consideration whether these are connection-oriented or connectionle= ss is very questionable approach, IMO;

 

 

[Answer] As stated abo= ve it is the OAM Model that is leveraged here. Regardless of connection ori= ented or not the model on Fault domains, Test points etc is valid.

 

In theory connection o= riented can be broken in to connection establishment and data forwarding. W= ith that in mind, one can define Fault domain and test points. Followed by = definition of the Fault identifications tools accordingly.

 

Do you have a preferre= d OAM tool  for fault verification/isolation and loss and performance = monitoring for connection oriented connectuons ?. If so would like to revie= w and map to the model.

 

 

o   “…CFM, it is a reasonable choice= to develop the unified OAM framework based on those concepts” IP OAM= is not based on Ethernet Service OAM model or principles but, IMO, OAM of = overlay networks more closer resemble IP OAM as these networks are connectionless in their architecture;

 

[Answer]  Please = see the answer above and extended CFM model. It is the model that is presen= ted here, regardless of the connectioness,  OAM tools need fault domai= ns and fault boundaries. Addidtionally as stated in the explanation above, there is nothing Ethernet in CFM, once the addre= ssing is decoupled.

 

o   “The YANG model presented in this docu= ment is the base model and supports IP Ping and Traceroute.” If only = these and similar OAM tools, e.g. LSP ping, Loopback/Linktrace, are in scop= e of the document, then, I believe, the title may say something like “YANG model of on-demand OAM tool to detect a= nd localize Loss of Continuity defect”. Referring to ping/traceroute = as “generic OAM” comes as stretch too far;

 

[Answer] I think there= is a miss understanding this model is not limited to Ping and Trace route.= Ping and traceroute are only examples to get the work stared and discussio= n going. As we go along other tools will be mapped to the model.

o    “…initiate a performance m= onitoring session can do so in the same manner regardless of the underlying= protocol or technology” I’d point to work of LMAP WG on inform= ational model of performance measurements in large-scale access networks, work of ITU-T’s SG15, MEF. Perhaps sentence can be stopped= after “… or a Traceroute”.

[Answer] I did not ful= ly understand your point.

 

o   “In this document we define the YANG m= odel for Generic OAM” Can you provide definition or reference to the = definition of the “Generic OAM”? It is challenging to validate = informational model of something that not been sufficiently defined.

 

[Answer]  As expl= ained earlier terminology generic OAM is used to indicate that the presente= d OAM model can be applied independent of the underlying technology. In sec= tion 1, we have stated the following: “..In this document, we take the [8021Q] CFM model and extend it to a technology= independent framework and build the corresponding YANG model accordingly. = The YANG model presented in this document is the base model and supports IP= Ping and Traceroute. The generic OAM YANG model is designed such that it can be extended to cover various t= echnologies. Technology dependent nodes and RPC commands are defined in tec= hnology specific YANG models, which use and extend the base model defined h= ere. …. “

 

 

·         Section 3

o   “This allows users to traverse between= OAM of different technologies at ease through a uniform API set.” Us= ually relationships between OAM layers referred and viewed as OAM interwork= ing. There are several examples of IETF addressing aspects of OAM interworking. I think that interworking includes not only s= cenarios of nested OAM layers but peering layers and thus is broader than i= ntroduced in the document “nested OAM”.

[Answer]  Can you= please provide some example here, I am not quite clear.<= /p>

 

Guessing from the word= peering, if we are referring to cascaded sections of different technologie= s such as IP Cloud, MPLS cloud and another IP cloud. Then the model present= ed here is the answer. You can have an end end OAM session at a higher MD-Level. Each of the clouds below can = have separate OAM at a lower MD-Level. These can be utilized for fault isol= ation.

 

o   Figure 1 depicts OAM of both connection-orie= nted and connectionless networks. What you see common, generic in respectiv= e OAM of these networks?

 

[Answer] Please see th= e answers above.

 

·         Section 4

o   “In IP, the MA can be per IP Subnet &#= 8230;” As there’s no definition of MA in IP, is this the defini= tion or one of examples. Can MA in IP network be other than per IP Subnet?<= o:p>

[Answer] It is “= .. can be”, so it meant to be an example and other possibilities are = not ruled out and model does not assume any such limitation.

 

o   “Under each MA, there can be two or mo= re MEPs (Maintenance End Points)” Firstly, since you adopt MA-centric= terminology, MEP stands for Maintenance Association End Point. Secondly, i= n some OAM models Down and Up MEP being distinguished. Would your model consider that? As there’s no definition of MEP for = several networks you’ve listed, e.g. IP, how the YANG model will abst= ract something that is not defined? And thirdly, how and where MIPs are loc= ated in IP OAM?

 

[Answer] Yes model acc= ept both UP/Down.

 

One cannot say for IP = there is no MEP. MEP is a functional abstraction of a test point that gener= ate and respond to OAM messages. In that regard IP devices today have an im= plicit MEP at the CPU. The model allow to provide more semantics to the MEP and allow to create UP/Down per inter= face or other scope, hence providing more granularity in fault isolation/ve= rification and monitoring.

 

Thank you for your consideration of my notes and loo= king forward to the interesting discussion.

 

Thank you for spending= time to review and comment. We are updating the next version with comments= received so far and specifically during IETF in Canada. We are more than h= appy enhance where applicable or need more clarity.

 

Regards,

    =     Greg

--_000_FBEA3E19AA24F847BA3AE74E2FE193562EF118C6xmbrcdx08ciscoc_-- From nobody Sun Aug 31 20:12:43 2014 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 A9DE51A90E9 for ; Sun, 31 Aug 2014 20:12:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.269 X-Spam-Level: X-Spam-Status: No, score=-4.269 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, 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 cSzJAmXHZW2g for ; Sun, 31 Aug 2014 20:12:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8DC81A90B8 for ; Sun, 31 Aug 2014 20:12:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml401-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BIX79884; Mon, 01 Sep 2014 03:12:35 +0000 (GMT) Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 1 Sep 2014 04:12:34 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.204]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.03.0158.001; Mon, 1 Sep 2014 11:12:26 +0800 From: Xuxiaohu To: "" Thread-Topic: Request WG adoption polling//FW: [spring] The rationale of draft-xu-spring-islands-connection-over-ip Thread-Index: Ac+XNbvwgjeJ7UQ5TYug+cTuo+tEef//4xuA/82NaND/cLhiEA== Date: Mon, 1 Sep 2014 03:12:26 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE082AC6DE@NKGEML512-MBS.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.134] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/spring/LHbUq17jkRHIYEZoozopLkAcDLI Subject: Re: [spring] Request WG adoption polling//FW: The rationale of draft-xu-spring-islands-connection-over-ip 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, 01 Sep 2014 03:12:41 -0000 SGkgY28tY2hhaXJzLA0KDQpXZSBjby1hdXRob3JzIGJlbGlldmUgdGhpcyByZXZpc2lvbiAoaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUtc3ByaW5nLWlzbGFuZHMtY29ubmVjdGlv bi1vdmVyLWlwLTAyKSBpcyByZWFkeSBmb3IgV0cgYWRvcHRpb24uIFdvdWxkIHlvdSBwbGVhc2Ug c3RhcnQgYW4gYWRvcHRpb24gcG9sbCBvbiB0aGlzIGRvYz8NCg0KQmVzdCByZWdhcmRzLA0KWGlh b2h1IChvbiBiZWhhbGYgb2YgYWxsIGNvLWF1dGhvcnMpDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogWHV4aWFvaHUNCj4gU2VudDogVHVlc2RheSwgQXVndXN0IDA1LCAy MDE0IDExOjU5IEFNDQo+IFRvOiA8c3ByaW5nQGlldGYub3JnPg0KPiBTdWJqZWN0OiBSZXF1ZXN0 IFdHIGFkb3B0aW9uIHBvbGxpbmcvL0ZXOiBbc3ByaW5nXSBUaGUgcmF0aW9uYWxlIG9mDQo+IGRy YWZ0LXh1LXNwcmluZy1pc2xhbmRzLWNvbm5lY3Rpb24tb3Zlci1pcA0KPiANCj4gSGkgY28tY2hh aXJzLA0KPiANCj4gV2UgaGF2ZSBhZGRyZXNzZWQgYWxsIGNvbW1lbnRzIHJlY2VpdmVkIHNvIGZh ciBpbiB0aGUgZm9sbG93aW5nIHJldmlzaW9uDQo+IChodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC14dS1zcHJpbmctaXNsYW5kcy1jb25uZWN0aW9uLW92ZXItaXAtMDEpLiBOb3RlDQo+ IHRoYXQgaG93IHRvIGR5bmFtaWNhbGx5IG9idGFpbiB0aGUgZW5jYXBzdWxhdGlvbiBjYXBhYmls aXRpZXMgaXMgZGVmaW5lZCBpbg0KPiBzZXBhcmF0ZSBkb2NzIChlLmcuLA0KPiBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC14dS1pc2lzLWVuY2Fwc3VsYXRpb24tY2FwLTAwKQ0KPiAN Cj4gV2UgY28tYXV0aG9ycyBiZWxpZXZlIHRoZSBjdXJyZW50IHZlcnNpb24gaXMgcmVhZHkgZm9y IFdHIGFkb3B0aW9uLg0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiBYaWFvaHUob24gYmVoYWxmIG9m IGFsbCBjby1hdXRob3JzKQ0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogcnJhc3p1a0BnbWFpbC5jb20gW21haWx0bzpycmFzenVrQGdtYWlsLmNvbV0gT24gQmVoYWxm IE9mIFJvYmVydA0KPiBSYXN6dWsNCj4gU2VudDogRnJpZGF5LCBKdWx5IDA0LCAyMDE0IDU6Mjkg UE0NCj4gVG86IFh1eGlhb2h1DQo+IENjOiA8c3ByaW5nQGlldGYub3JnPg0KPiBTdWJqZWN0OiBS ZTogW3NwcmluZ10gVGhlIHJhdGlvbmFsZSBvZiBkcmFmdC14dS1zcHJpbmctaXNsYW5kcy1jb25u ZWN0aW9uLW92ZXItaXANCj4gDQo+IEhpIFh1LA0KPiANCj4gV2UgZGlzY3Vzc2VkIHRoaXMgd29y ayBiZWZvcmUsIGhvd2V2ZXIgSSBoYXZlIGEgbmV3IHF1ZXN0aW9uIC4uLg0KPiANCj4gSXQgaXMg YW4gaW5mb3JtYXRpb25hbCBkcmFmdCBzbyB5b3UgcmVsYXkgb24gcHJvcGVyIGNvbmZpZ3VyYXRp b24gb2YgUlMgbm9kZXMgaW4NCj4gdGhlIGlzbGFuZHMuDQo+IA0KPiBOb3RlIHRoYXQgdG9kYXkg eW91IG1heSBoYXZlIG91dCBvZiB0aGUgYm94IFNSIG5vZGUgc3VwcG9ydGluZyBJUHY0LA0KPiBJ UHY2IChzYXkgd2l0aG91dCBTUikgKyBNUExTLiBTbyB5b3UgbXVzdCBzZWxlY3QgeW91ciBvcGVy YXRpb25hbCBkZWZhdWx0DQo+IGVuY2Fwc3VsYXRpb24gYW5kIHZlcnkgbGlrZWx5IHN1Y2ggZW5j YXBzdWxhdGlvbiB3aWxsIGRpZmZlciBwZXIgbmV4dCBTUg0KPiBkZXN0aW5hdGlvbiAhDQo+IA0K PiBJIHRoZXJlZm9yIGZpbmQgaXQgbm90IHJlYWxseSBwcmFjdGljYWwgdG8gcmVjb21tZW5kIG1h bnVhbC9pMnJzL3htbA0KPiBjb25maWd1cmF0aW9uIGFuZCBjaG9pY2Ugb2YgZW5jYXBzdWxhdGlv biBvbiBhIHBlciBTUiBub2RlIGJhc2lzLg0KPiANCj4gSSB3b3VsZCB0aGVyZWZvciBhZHZpc2Ug aWYgdGhlcmUgd291bGQgYmUgYXJjaGl0ZWN0dXJhbCBjb25zZW5zdXMgdG8gZ28gZm9yd2FyZA0K PiB3aXRoIHRoZSBwcm9wb3NlZCBpbiB0aGUgZHJhZnQgaWRlYSB0byB0dXJuIGl0IGludG8gc3Rh bmRhcmRzIHRyYWNrIGFuZCBhZGQgYSBmbGFnDQo+IGFuZCBlbmNhcCBpbmZvIGluIFNSIGFkdmVy dGlzZW1lbnQgaXRzZWxmIGluZGljYXRpbmcgdGhhdCBnaXZlbiBTUiBub2RlIG1heSBiZQ0KPiBy ZWFjaGFibGUgc2F5IHZpYSBHUkUsDQo+IEwyVFB2MyBvciBWWExBTiBlbmNhcHMuDQo+IA0KPiBU aGF0IHdheSB5b3VyIG9iamVjdGl2ZSBpcyBhY2NvbXBsaXNoZWQgdmlhIGZ1bGwgcHJvdG9jb2wg YXV0b21hdGlvbiB3aXRoDQo+IG1pbmltYWwgbmVlZCBmb3IgYW55IHBlciBTUiBzcmMvZHN0IG5v ZGUgbWFudWFsIGNvbmZpZy4NCj4gDQo+IEJlc3QsDQo+IFIuDQo+IA0KPiANCj4gDQo+IA0KPiAN Cj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gT24gRnJpLCBKdWwgNCwgMjAxNCBhdCA1OjEyIEFN LCBYdXhpYW9odSA8eHV4aWFvaHVAaHVhd2VpLmNvbT4gd3JvdGU6DQo+ID4gSGkgYWxsLA0KPiA+ DQo+ID4gVGhpcyBkcmFmdA0KPiAoaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQteHUt c3ByaW5nLWlzbGFuZHMtY29ubmVjdGlvbi1vdmVyLWlwLTAwKQ0KPiBkZXNjcmliZXMgYSB1c2Ug Y2FzZSBhYm91dCBpbnRlcmNvbm5lY3Rpbmcgc3ByaW5nIGlzbGFuZHMgb3ZlciBJUCBuZXR3b3Jr cy4gVGhlDQo+IHJhdGlvbmFsZSBmb3IgdGhpcyBkcmFmdCBpcyBhcyBmb2xsb3dzOg0KPiA+DQo+ ID4gU3VwcG9zZSBMU1IgQSBhbmQgTFNSIEIgYXJlIHNlcGFyYXRlZCBieSBhbiBJUCBuZXR3b3Jr LiBBc3N1bWUgTFNSIEENCj4gcmVjZWl2ZXMgZnJvbSBMU1IgQiBhIGxhYmVsIGJpbmRpbmcgTCBm b3IgYSBnaXZlbiBGRUMgKGUuZy4sIG9uZSBvZiBMU1IgQidzDQo+IGxvb3BiYWNrIGFkZHJlc3Nl cykgdmlhIFQtTERQIG9yIEwtQkdQLCB3aGVuIExTUiBBIHdhbnRzIHRvIGZvcndhcmQgYSBNUExT DQo+IHBhY2tldCB0YXJnZXRlZCBmb3IgdGhhdCBGRUMsIGl0IGNvdWxkIGZvcndhcmQgdGhhdCBN UExTIHBhY2tldCB0aHJvdWdoIGFuDQo+IElQLWJhc2VkIHR1bm5lbCB0b3dhcmRzIExTUiBCLiBJ biBjb250cmFzdCwgaWYgTFNSIEEgcmVjZWl2ZXMgdGhlIGFib3ZlIGxhYmVsDQo+IGJpbmRpbmcg b3JpZ2luYXRlZCBieSBMU1IgQiB2aWEgSVMtSVMgb3IgT1NQRiwgaXQgY291bGQgYmUgbG9va2Vk IGFzIGlmIHRoaXMgbGFiZWwNCj4gYmluZGluZyB3YXMgbGVhcm50IGZyb20gYSByZW1vdGUgQkdQ IG9yIExEUCBwZWVyLiBBcyBzdWNoLCBMU1IgQSBjb3VsZCBmb3J3YXJkDQo+IHRoZSBNUExTIHBh Y2tldCB0YXJnZXRlZCBmb3IgdGhhdCBGRUMgb3ZlciBhbiBJUC1iYXNlZCB0dW5uZWwgdG93YXJk cyBMU1IgQiBhcw0KPiB3ZWxsLg0KPiA+DQo+ID4gSW4gZmFjdCwgb25lIG9mIHRoZSBjbGFpbWVk IGFkdmFudGFnZXMgb2YgSVB2Ni1TUiBpcyB0aGF0IGl0IGRvZXNuJ3QgcmVxdWlyZSB0bw0KPiB1 cGdyYWRlIGFsbCByb3V0ZXJzIGluIHRoZSBuZXR3b3Jrcy4gV2l0aCB0aGUgYWJvdmUgYXBwcm9h Y2gsIHdlIGNhbiBhY2hpZXZlDQo+IHRoZSBzYW1lIGVmZmVjdCBpbiB0aGUgTVBMUy1TUi4NCj4g Pg0KPiA+IEJlc3QgcmVnYXJkcywNCj4gPiBYaWFvaHUNCj4gPg0KPiA+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gc3ByaW5nIG1haWxpbmcgbGlz dA0KPiA+IHNwcmluZ0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc3ByaW5nDQo=